В общедоступном выпущенном компиляторе никогда не было NLL в запрещающем режиме. Т.е. это делалось в рамках разработки очередной версии с целью проверки того, собственно, можно ли его сразу в запрещающем режиме включать.
Эти предупреждения ничем от deprecation warnings не отличаются.
Дыры в soundness надо же как-то чинить.
И ни один из этих языков не пересекается по нише с Rust.
Сравнивать rustls с openssl — нормально. Когда первая достигнет объёмов использования хотя бы в 10% от openssl, можно будет увидеть, что уязвимостей там правда меньше.
При этом не стоит забывать, что поиск уязвимостей тоже не стоит на месте. Благодаря ASLR, защите стека, DEP и другим прелестям, классическое переполнение буфера уже когда сложнее превратить в эксплуатируемую уязвимость — а значит внимание смещается на "менее технические" моменты, не связанные с конкретным языком программирования. Социальная инженерия, например, сильна как никогда.
Ох уж эти оптимизаторы на ассемблере.
Вы пробовали когда-нибудь написать максимально быстрый на ваш взгляд код для функции на ассемблере, а потом сравнить с кодом, сгенерированным компилятором при хотя бы -O2? Попробуйте.
И заработает, да. Потому что тут у вас один поток исполнения.
Это хорошо, что вас заставляют специально извернуться, чтобы указать, что вы собираетесь работать с куском памяти однопоточно. Когда по умолчанию считается, что можно, получается небезопасно.
И да, тут у вас всё равно остаётся механизм защиты, который можно описать как "run-time borrowing". К Cell это не применимо, т.к. там только Copy-типы, но RefCell паникует, если вы таки взяли одновременно 2 ссылки на запись.
А у вас какие-то особые требования, по которым вам надо сидеть на одной заранее выбранной версии компилятора?
Такое бывает, например, при сертификации, но в обычном продакшене вы просто обновляетесь раз в 6 недель на новый компилятор. Максимум что он привнесёт — warning'и о deprecation чего-либо. Чините их, и на следующую версию опять обновляетесь без проблем.
Обратную совместимость уже 4 года как не ломают.
Вообще это интересно, что вы коснулись mem::uninitialized. Как раз с ним был связан недавний RFC — эта функция теперь deprecated.
А почему? А как раз потому, что, как оказалось, факт создания значения определённого типа вне области определения этого типа — уже UB.
Это всё важно в первую очередь в контексте оптимизации. Если вы компилятор, и вам говорят, что вот тут bool — допустимые значения 0 и 1, то встретив код типа
let flag = false;
let x = 100500;
...
if flag {
x += 1;
}
вы можете соптимизировать этот код, основываясь на численном представлении bool. Если bool не 0 или 1, этот код будет работать неправильно. Но не только этот код. Возможно этот bool используется уже скомпилированным кодом стандартной библиотеки, например.
Поэтому да, странные эффекты могут начаться по всей программе. Но UB всё равно именно там, где нарушили инвариант — в unsafe.
Ошибки аллокации достаточно бесполезно ловить в пользовательской программе.
Во-первых, почти вся стандартная библиотека опирается на аллокатор, но если добавить тип ошибки в возвращаемые значения всех функций, которые выделяют память, пользоваться этим будет совершенно невозможно.
Во-вторых, как минимум на десктопных Linux по умолчанию включён overcommit, который делает невозможной локальную обработку ошибки выделения памяти.
В-третьих, если вы пишете прикладную программу, близкую к системной в плане управления ресурсами (веб-сервер, сервер БД), то у вас и так весьма особенные нужды в выделении памяти. Часто используются пулы, маппинг файлов/анонимной памяти прямо от системы. Куча в первую очередь интересна "совсем прикладным" программам, которым нехватка ресурсов неинтересна.
Ну справедливости ради в первой статье тоже дурацкие причины.
"Увидеть альтернативы", "разобраться в контейнерах" и "подготовиться к будущему" это причины поковырять технологию в свободное время, а не переходить в продакшене.
Непонятно почему они не приводят как причину увеличение безопасности — контр-меру от выхода из контейнера и получение рута на хосте, т.к. демон под рутом.
С т.з. adoption хорошо что они совместимы с докером. С другой стороны, в той же vagga есть супер-полезные вещи, которых в мейнстрим-контейнерах нет и видимо ещё долго не будет:
Авто-версионирование и очистка старых образов/контейнеров. Заниматься этой уборкой в докере абсолютно осточертело.
Прокидывание прокси с хоста — зачем в докере эти пляски с такой тривиальной вещью, абсолютно непонятно.
В vagga сборка идёт серьёзно быстрее за счёт некоторых трюков, например libeatmydata.
Командно-ориентированный процесс вместо контейнеро-ориентированного. Контейнеры стартуют за миллисекунды. В конфиге описываются команды, а контейнеры под них поднимаются/опускаются автоматически.
Вот этого я вообще не понимаю.
Ну no-carrier и что? Интерфейс-то остался и когда carrier появится всё продолжит работать. Это вообще от меня не зависит, удалённый конец питание потерял.
Не могу сказать что мне они чем-то не угодили, просто из коробки в той же Ubuntu они сейчас не работают, и при отключении NetworkManager выбирая между откатом назад на них, и переходом вперед на netplan + networkd я выбрал второе. Я в целом думаю что systemd это довольно правильно, и интегрировать туда управление сетями тоже выглядит разумно.
Со стороны старых interfaces — а они поддерживают, для примера, продвинутые настройки Wi-Fi (WPA2 Enterprise)?
В общедоступном выпущенном компиляторе никогда не было NLL в запрещающем режиме. Т.е. это делалось в рамках разработки очередной версии с целью проверки того, собственно, можно ли его сразу в запрещающем режиме включать.
Эти предупреждения ничем от deprecation warnings не отличаются.
Дыры в soundness надо же как-то чинить.
Упоминать в этом разговоре суровую академию это даже неприлично.
И ни один из этих языков не пересекается по нише с Rust.
Сравнивать rustls с openssl — нормально. Когда первая достигнет объёмов использования хотя бы в 10% от openssl, можно будет увидеть, что уязвимостей там правда меньше.
При этом не стоит забывать, что поиск уязвимостей тоже не стоит на месте. Благодаря ASLR, защите стека, DEP и другим прелестям, классическое переполнение буфера уже когда сложнее превратить в эксплуатируемую уязвимость — а значит внимание смещается на "менее технические" моменты, не связанные с конкретным языком программирования. Социальная инженерия, например, сильна как никогда.
Ох уж эти оптимизаторы на ассемблере.
Вы пробовали когда-нибудь написать максимально быстрый на ваш взгляд код для функции на ассемблере, а потом сравнить с кодом, сгенерированным компилятором при хотя бы
-O2? Попробуйте.И заработает, да. Потому что тут у вас один поток исполнения.
Это хорошо, что вас заставляют специально извернуться, чтобы указать, что вы собираетесь работать с куском памяти однопоточно. Когда по умолчанию считается, что можно, получается небезопасно.
И да, тут у вас всё равно остаётся механизм защиты, который можно описать как "run-time borrowing". К
Cellэто не применимо, т.к. там толькоCopy-типы, ноRefCellпаникует, если вы таки взяли одновременно 2 ссылки на запись.А у вас какие-то особые требования, по которым вам надо сидеть на одной заранее выбранной версии компилятора?
Такое бывает, например, при сертификации, но в обычном продакшене вы просто обновляетесь раз в 6 недель на новый компилятор. Максимум что он привнесёт — warning'и о deprecation чего-либо. Чините их, и на следующую версию опять обновляетесь без проблем.
Обратную совместимость уже 4 года как не ломают.
Вообще это интересно, что вы коснулись
mem::uninitialized. Как раз с ним был связан недавний RFC — эта функция теперь deprecated.А почему? А как раз потому, что, как оказалось, факт создания значения определённого типа вне области определения этого типа — уже UB.
Это всё важно в первую очередь в контексте оптимизации. Если вы компилятор, и вам говорят, что вот тут
bool— допустимые значения0и1, то встретив код типавы можете соптимизировать этот код, основываясь на численном представлении
bool. Еслиboolне0или1, этот код будет работать неправильно. Но не только этот код. Возможно этотboolиспользуется уже скомпилированным кодом стандартной библиотеки, например.Поэтому да, странные эффекты могут начаться по всей программе. Но UB всё равно именно там, где нарушили инвариант — в unsafe.
Ошибки аллокации достаточно бесполезно ловить в пользовательской программе.
Во-первых, почти вся стандартная библиотека опирается на аллокатор, но если добавить тип ошибки в возвращаемые значения всех функций, которые выделяют память, пользоваться этим будет совершенно невозможно.
Во-вторых, как минимум на десктопных Linux по умолчанию включён overcommit, который делает невозможной локальную обработку ошибки выделения памяти.
В-третьих, если вы пишете прикладную программу, близкую к системной в плане управления ресурсами (веб-сервер, сервер БД), то у вас и так весьма особенные нужды в выделении памяти. Часто используются пулы, маппинг файлов/анонимной памяти прямо от системы. Куча в первую очередь интересна "совсем прикладным" программам, которым нехватка ресурсов неинтересна.
Вы сейчас описали практически как vagga работает — только без демонов и командной строки из 5 опций на пустом месте ;)
Понял, спасибо.
https://docs.docker.com/compose/compose-file/#restart
Это проект одного человека. В плане юзабилити для разработчика большой шаг вперёд.
В плане серьёзного продакшена это конечно большой недостаток.
Одного для одного другое для другого.
Вы ансиблом супервайзите сервисы в продакшене?
Ну справедливости ради в первой статье тоже дурацкие причины.
"Увидеть альтернативы", "разобраться в контейнерах" и "подготовиться к будущему" это причины поковырять технологию в свободное время, а не переходить в продакшене.
Непонятно почему они не приводят как причину увеличение безопасности — контр-меру от выхода из контейнера и получение рута на хосте, т.к. демон под рутом.
Они подразумевают под этим Operations, тех кто эксплуатирует систему после завершения разработки.
В этой статье пишут, что его нет
С т.з. adoption хорошо что они совместимы с докером. С другой стороны, в той же vagga есть супер-полезные вещи, которых в мейнстрим-контейнерах нет и видимо ещё долго не будет:
Много философии, мало технологии.
Вот этого я вообще не понимаю.
Ну no-carrier и что? Интерфейс-то остался и когда carrier появится всё продолжит работать. Это вообще от меня не зависит, удалённый конец питание потерял.
Не могу сказать что мне они чем-то не угодили, просто из коробки в той же Ubuntu они сейчас не работают, и при отключении NetworkManager выбирая между откатом назад на них, и переходом вперед на netplan + networkd я выбрал второе. Я в целом думаю что systemd это довольно правильно, и интегрировать туда управление сетями тоже выглядит разумно.
Со стороны старых interfaces — а они поддерживают, для примера, продвинутые настройки Wi-Fi (WPA2 Enterprise)?