Более того, по таблице он развалится из-за того, что его невозможно прочитать без исправления-ошибок-на-лету. То есть при нормальной эксплуатации каждый scrub с вероятностью ~97% встречает ошибки, но они исправляются за счёт избыточности*, а когда массив degraded, то они ведут к потере данных**.
А если scrub не встречает ошибок? То настоящий URE гораздо ниже заявленного производителем - враньё спрятано в этом месте.
* А одиночные диски как, без массива? Полное чтение 8 ТБ тогда должно встречать ошибку в половине случаев.
** Перечисляют такие варианты: - Худший: заменили диск, запускается восстановление, контроллер решает прибить массив после встречи битого сектора. - Чуть лучше: процесс прерывается на битом секторе, успешно завершить без простоев и ручной работы с сыпящимся диском нельзя. - Лучший: битый сектор пропускается и на уровне массива тоже помечается как нечитаемый.
1.65 au до Солнца, то есть энергии там в 1.65^2 = 2.7 раза меньше. Вроде всё равно лучше реакторов и беспроблемнее (радиация, механика, хладагент, температуры, радиационно-безопасная орбита, перегрузка топлива в космосе...). Про цены ещё ничего не известно. Космический реактор - космически дорого. Новейшие тонкоплёночные панели какой-то огромной площади - космически дорого.
Если с другой стороны посмотреть, то когда-то жила идея, что C++ сможет заменить C и почти все на него перейдут. И у Страуструпа, вроде как, жила.
А потом умерла. И уже первый стандарт C++ как бы хоронил идею, требуя поддержку исключений в freestanding-режиме ("bare metal", не hosted). Можно найти высказывания Страуструпа, что C++ в ядрах ОС следует использовать именно с исключениями и в Linux тоже, он ссылался на чей-то эксперимент.
250 кг тонкоплёночных панелей на 2000 Вт/кг, выше ведь написал.
Проблема скорее в том, что спешить есть смысл только для доставки людей, а доставка людей на столь облегчённом корабле будет с кучей пересадок. Сначала пересесть на этот SEP-буксир (Solar Electric Propulsion) где-то за радиационными поясами, потом пересесть на спускаемый модуль около Марса, на обратном пути ещё две пересадки.
void memstream_done(MemStream *m) {
assert(m);
/* First, close file stream, as the buffer may be reallocated on close. */
safe_fclose(m->f);
/* Then, free buffer. */
free(m->buf);
}
Разбросано по файлам, но memstream_done переиспользуется около 40 раз.
С RAII-на-std::optional было бы что-то в духе этого:
// ...
std::optional<MemStream> m = MemStream::TryCreate();
// Вместо memstream_done - деструктор MemStream
// memstream_init пусть будет статическим методом TryCreate
if (!m)
return log_oom();
// ... (используем m->f)
Атрибут cleanup (GNU C) считают за RAII. Его используют в systemd.
Если это у вас три вызова new, то всё нормально, С++ за вами приберёт
Если мы вручную вызвали new, то нам вручную и вызывать delete. RAII нет.
Если мы как угодно получили ресурс в конструкторе RAII-контейнера, то нам его и освобождать в деструкторе, фокус на new не нужен.
Замена исключений (в конструкторе) на std::optional (в функции, создающей объект) - это, вроде как, лишь замена одного способа обработки ошибок на другой. if'ы вместо try-catch.
И ещё RAII вместо goto exit_N (но оно требует исключений, так что вероятно нет).
Основная идея RAII в освобождении ресурсов в ходе автоматического удаления объекта (поэтому, собственно, в названии идиомы нет ни освобождения, ни уничтожения...).
Почему отсутствие исключений не очень важно:
Не важно в деструкторе, потому что из него в любом случае не следует кидать исключения. Ещё RAII требует, чтобы освобождение ресурсов не могло сломаться, ядро Linux обычно тоже из этого исходит.
А что до acquisition & initialization, то придётся, например, удалить конструктор и собирать объект функцией, возвращающей std::optional (или как-нибудь погрязнее).
В два раза, на МКС 240 кВт (и Внешний Источник Тени, который уменьшил это число в 2 раза в вашем комменте)
Там стоит говно мамонта с 30 Вт/кг.
Японцы что-то себе считают исходя из 1800 Вт/кг, вообще говорят о 500-4300 Вт/кг. Это 100-1000 кг на 500 кВт. Кто-то пишет о 2200 Вт/кг как о реальном товаре.
А вот если сплошные "проверить бит -- установить бит", то на асме, как по мне, даже лучше оказаться в плане читаемости может
Стопудово.. Я иногда скучаю о асмовских командах установки/тестирования битов. Особенно на портах ввода/вывода
Вы серьёзно? Они при желании доступны через inline-ассемблер, его (или версию на C) можно завернуть в макрос, можно в функцию, можно заменить функцией или макросом из HAL-библиотеки к железке или самостоятельно написать такую (некого Аскольда Волкова интернет не помнит, а его макросы помнит).
Вряд ли. Там шаблонные скобки не возвращали вручную, их штук 50 в статье. Их не хватает только в unordered_set и в 2 случаях из 3 их можно опустить, полагаясь на вывод типов.
Там ещё вёрстка кода поехала. На его сайте статья висит исправленная (unordered_set<string>) и дополненная (I wanted Lines read as lines) и всё равно с ошибками (в скобках:{...)).
Хм, на godbolt.org нет ни одного компилятора, который бы запустил код. У msvc есть поддержка нужной фичи (__cpp_lib_containers_ranges), но в тамошней версии нет поддержки модулей и ещё from_range-конструктор unordered_set'а не берёт istream_iterator в качестве аргумента (старый компилятор или ошибка у Страуструпа - не знаю).
Для защиты прихожан от чужаков есть простой линусовский жест: "*YOU* are full of bullshit. $LangName is a horrible language". Но это не иноверцы, два креста носящие, Rust в ядро приглашён. Линус проблемы мягко обрисовывает как конфликт поколений: есть у них "old-time kernel developers", которые Rust не знают и знать не хотят (а когда закончатся - вступайте в наследство).
К тому же в этот раз могут надавить государство и корпорации. В старой истории с C++ у них интереса не было, а сейчас ОАО "Красная шляпа" и прочие могут напомнить, на чьей земле монастырь стоит.
У меня Ryzen 7800x3D, а до этого у меня был 5 1500x. Разницы нет вообще
Для какой-то видеокарты и каких-то предпочтений в играх - вполне может быть, но обобщения как в начале ветки из этого опасно делать.
Ryzen 5 1500X не лучше i7-7700, слабее последних народных зионов (там есть 6-8 более быстрых ядер, на уровне Zen+), слабее приставочных процессоров (8 ядер на уровне десктопных Zen+).
В приставках стоят процессоры в 2+ раза мощнее. Их производители что-то знают.
Игры любят 6-8 максимально быстрых ядер (и одноядерную производительность любят больше, чем переход от 6 к 8) с поправкой на то, что можно упереться в видеокарту. Видеокарта вообще важнее, но
не настолько, чтобы ставить к 4090+ процессор второй свежести
Воистину. У techpowerup есть диаграммы на тему скорости запуска игр, где два PCIe Gen5 SSD (выделены цветом), 970 EVO Plus и прочие вплоть до SATA QLC.
Может чуть подождали бы и стандарт сразу был бы лучше, уровня IP v6, без проблем с дефицитом IP адресов.
Оффтоп: если бы они сделали стандарт уровня IPv6, то его бы сейчас внедрили примерно наполовину. Да и в проблеме дефицита адресов большая часть вины на IPv6, ИМХО. Знали бы, чем обернётся принятие IPv6, смотрели бы в сторону RFC 1385 и т.д.
Более того, по таблице он развалится из-за того, что его невозможно прочитать без исправления-ошибок-на-лету. То есть при нормальной эксплуатации каждый scrub с вероятностью ~97% встречает ошибки, но они исправляются за счёт избыточности*, а когда массив degraded, то они ведут к потере данных**.
А если scrub не встречает ошибок? То настоящий URE гораздо ниже заявленного производителем - враньё спрятано в этом месте.
* А одиночные диски как, без массива? Полное чтение 8 ТБ тогда должно встречать ошибку в половине случаев.
** Перечисляют такие варианты:
- Худший: заменили диск, запускается восстановление, контроллер решает прибить массив после встречи битого сектора.
- Чуть лучше: процесс прерывается на битом секторе, успешно завершить без простоев и ручной работы с сыпящимся диском нельзя.
- Лучший: битый сектор пропускается и на уровне массива тоже помечается как нечитаемый.
1.65 au до Солнца, то есть энергии там в 1.65^2 = 2.7 раза меньше. Вроде всё равно лучше реакторов и беспроблемнее (радиация, механика, хладагент, температуры, радиационно-безопасная орбита, перегрузка топлива в космосе...). Про цены ещё ничего не известно. Космический реактор - космически дорого. Новейшие тонкоплёночные панели какой-то огромной площади - космически дорого.
Если с другой стороны посмотреть, то когда-то жила идея, что C++ сможет заменить C и почти все на него перейдут. И у Страуструпа, вроде как, жила.
А потом умерла. И уже первый стандарт C++ как бы хоронил идею, требуя поддержку исключений в freestanding-режиме ("bare metal", не hosted). Можно найти высказывания Страуструпа, что C++ в ядрах ОС следует использовать именно с исключениями и в Linux тоже, он ссылался на чей-то эксперимент.
Да им не привыкать.
Нет, с Си так и поступили. Он тоже много всякого позволяет, но договорились об определённом подмножестве.
Например: The Linux Kernel Is Now VLA (Variable-Length Array) Free
250 кг тонкоплёночных панелей на 2000 Вт/кг, выше ведь написал.
Проблема скорее в том, что спешить есть смысл только для доставки людей, а доставка людей на столь облегчённом корабле будет с кучей пересадок. Сначала пересесть на этот SEP-буксир (Solar Electric Propulsion) где-то за радиационными поясами, потом пересесть на спускаемый модуль около Марса, на обратном пути ещё две пересадки.
К слову о том, что делает systemd.
В одном файле:
В другом файле (а структура MemStream тут):
Разбросано по файлам, но
memstream_doneпереиспользуется около 40 раз.С RAII-на-std::optional было бы что-то в духе этого:
Атрибут cleanup (GNU C) считают за RAII. Его используют в systemd.
Если мы вручную вызвали new, то нам вручную и вызывать delete. RAII нет.
Если мы как угодно получили ресурс в конструкторе RAII-контейнера, то нам его и освобождать в деструкторе, фокус на new не нужен.
Замена исключений (в конструкторе) на std::optional (в функции, создающей объект) - это, вроде как, лишь замена одного способа обработки ошибок на другой. if'ы вместо try-catch.
Основная идея RAII в освобождении ресурсов в ходе автоматического удаления объекта (поэтому, собственно, в названии идиомы нет ни освобождения, ни уничтожения...).
Почему отсутствие исключений не очень важно:
Не важно в деструкторе, потому что из него в любом случае не следует кидать исключения. Ещё RAII требует, чтобы освобождение ресурсов не могло сломаться, ядро Linux обычно тоже из этого исходит.
А что до acquisition & initialization, то придётся, например, удалить конструктор и собирать объект функцией, возвращающей std::optional (или как-нибудь погрязнее).
В два раза, на МКС 240 кВт (и Внешний Источник Тени, который уменьшил это число в 2 раза в вашем комменте)
Там стоит говно мамонта с 30 Вт/кг.
Японцы что-то себе считают исходя из 1800 Вт/кг, вообще говорят о 500-4300 Вт/кг. Это 100-1000 кг на 500 кВт. Кто-то пишет о 2200 Вт/кг как о реальном товаре.
Вы серьёзно? Они при желании доступны через inline-ассемблер, его (или версию на C) можно завернуть в макрос, можно в функцию, можно заменить функцией или макросом из HAL-библиотеки к железке или самостоятельно написать такую (некого Аскольда Волкова интернет не помнит, а его макросы помнит).
Вряд ли. Там шаблонные скобки не возвращали вручную, их штук 50 в статье. Их не хватает только в unordered_set и в 2 случаях из 3 их можно опустить, полагаясь на вывод типов.
Там ещё вёрстка кода поехала. На его сайте статья висит исправленная (
unordered_set<string>) и дополненная (I wanted Lines read as lines) и всё равно с ошибками (в скобках:{...)).https://stroustrup.com/21st-Century-C++.pdf
Хм, на godbolt.org нет ни одного компилятора, который бы запустил код. У msvc есть поддержка нужной фичи (
__cpp_lib_containers_ranges), но в тамошней версии нет поддержки модулей и ещё from_range-конструктор unordered_set'а не берёт istream_iterator в качестве аргумента (старый компилятор или ошибка у Страуструпа - не знаю).Для защиты прихожан от чужаков есть простой линусовский жест: "*YOU* are full of bullshit. $LangName is a horrible language". Но это не иноверцы, два креста носящие, Rust в ядро приглашён. Линус проблемы мягко обрисовывает как конфликт поколений: есть у них "old-time kernel developers", которые Rust не знают и знать не хотят (
а когда закончатся - вступайте в наследство).К тому же в этот раз могут надавить государство и корпорации. В старой истории с C++ у них интереса не было, а сейчас ОАО "Красная шляпа" и прочие могут напомнить, на чьей земле монастырь стоит.
А еще иногда бывает, что смотришь на звук, а видишь телевизор. Иногда даже два.
15.625 кГц - строчная частота PAL
15.73426 кГц - NTSC
Для какой-то видеокарты и каких-то предпочтений в играх - вполне может быть, но обобщения как в начале ветки из этого опасно делать.
Ryzen 5 1500X не лучше i7-7700, слабее последних народных зионов (там есть 6-8 более быстрых ядер, на уровне Zen+), слабее приставочных процессоров (8 ядер на уровне десктопных Zen+).
В приставках стоят процессоры в 2+ раза мощнее. Их производители что-то знают.
Игры любят 6-8 максимально быстрых ядер (и одноядерную производительность любят больше, чем переход от 6 к 8) с поправкой на то, что можно упереться в видеокарту. Видеокарта вообще важнее, но
не настолько, чтобы ставить к 4090+ процессор второй свежести
Воистину. У techpowerup есть диаграммы на тему скорости запуска игр, где два PCIe Gen5 SSD (выделены цветом), 970 EVO Plus и прочие вплоть до SATA QLC.
Оффтоп: если бы они сделали стандарт уровня IPv6, то его бы сейчас внедрили примерно наполовину. Да и в проблеме дефицита адресов большая часть вины на IPv6, ИМХО. Знали бы, чем обернётся принятие IPv6, смотрели бы в сторону RFC 1385 и т.д.
Ниже вон про него вспомнили как про более человечный интерфейс к CRIU.
Считайте, что я этого не говорил, это глупость.
Поизучать поведение можно на тестовом файле, где I/P/B-кадры стоят на удобных timestamp'ах и на видео наложен тип и номер кадра.
Опасно
Переносы (
^) и экранирование (%->%%) виндовые, не для bash.-vfнакладывает на кадр свойства%{pict_type},%{frame_num},%{pts} через 3 вызова drawtext.ffmpeg совсем не годится для такого, выглядит и отлаживается отвратительно, это работа для vapour/avisynth, но зато без лишних зависимостей
Если кратко:
интервал работает так: [-ss; -to), -t тоже задаёт открытый интервал
но только не с
-c copy, тогда интервалы работают... как-то сложноконец интервала с
-c copyможет быть P-кадром, может быть битым (выкинул 5 B-кадров перед последним P-кадром)-noaccurate_seek -ss _ -i _делает фигню (у меня добавление опции захватывает ещё один кадр перед -ss, независимо от типа кадра)автопоиск ключевых кадров для обоих концов интервала есть разве что в
-f segment -segment_times _,_,... -c copy