Comments 17
ну почти (если не считать 9 дней на отстой):
6.10 вышел за три месяца до 6 oct
6.11 аналогично но за два до 6 nov
6.12 уже за месяц до 6 dec
подождём 6.13 с 6•9
возможность записи в исполняемые файлы
эээ, а это про что? или это только uring касается?
В юниксах исторически запрещалось менять исполняемые файлы когда они используются хоть одним процессом. Теперь это ограничение убрали под предлогом, что все равно есть ряд способов обходить такое ограничение. Я тут не эксперт, но аргументация выглядит в духе: зачем лишний раз усложнять хакерам работу?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
Почитал, вроде как верная аргументация - методы обхода запрета уже исследованы и найдены, следовательно не сильно усложнят хакерам работу.
Но зачем убирать опцию, не очень ясно. Типа просто лишняя и ненужный оверхед?
>> The deny_write_access() mechanism is causing really pointless issues such as [1]. If a thread in a thread-group opens a file writable, then writes some stuff, then closing the file descriptor and then calling execve() they can fail the execve() with ETXTBUSY because another thread in the thread-group could have concurrently called fork(). Multi-threaded libraries such as go suffer from this.
То есть мешал не столько запрет на запись в выполняемый файл, сколько запрет запускать не закрытый после записи файл. Насколько я понял, проблема была с fork'нутыми процессами, которые успевали форкнуться до того, как файл был закрыт. И страдали из-за этого, в первую очередь, go разработчики с их goрутинами, которые форкаются сами по себе.
https://github.com/golang/go/issues/22315
Есть аналогичное для Rust https://github.com/rust-lang/rust/issues/114554 . Выходит, что POSIX предлагали другой вариант решения, но линукс пошёл какой-то своей дорогой. Интересно, кому на практике нужно менять исполняемые файлы перед запуском, кроме вирусмейкеров?
У гоферов проблема с `go run`, там компилятор такой быстрый, что можно запускать из исходников. В rust есть `cargo run`, хотя оно и медленнее.
Например, это автоматическое тестирование: собрали в нужной конфигурации, запустили и так много раз. Можно еще представить что-то сервисное, когда код генерируется из шаблонов под задачу и сразу же выполняется.
Спасибо за ссылку, интересно было почитать, как люди живут. Там в POSIX пытались сделать так, чтобы дочерный процесс получал закрытые дескрипторы после fork. И не сошлись во мнении, что будет с сокетами.
Опять Растеры недовольны, что Сишники не хотят учить их язык и поддерживать его.
Как видел чей-то коммент в Твиттере - "Ну, так форканите Линукс проект и перепишите его полностью на раст". Ах ну да, в таком случае никому нафиг не сдастся их проект, а они хотят славы :)
Так и запишем: "по ссылке не переходил, статью не читал, повелся на некорректный пересказ событий в этой статье"
Я читал и изучал этот конфликт. Да, основная претензия, что "Нет документации и ее отказываются предоставить". Но там множество других областей разработки ядра обсуждается. Даже сам Алмейд Филхо оставил линк на видео, где ведущий разработчик файловой системы говорит, что он не хочет изучать раст и поддерживать его, если ему надо поменять АПИ в системе.
Собственно, если разработчикам на Расте так не нравятся "старые С разработчики", которым лень даже документацию сделать, то почему просто не форкнуть линукс проект и самим творить там что захочется?
Ключница переводила?
Предвижу возможные проблемы когда раст внутри разрастется. Тогда разработчику ядра будет необходимо знать 2 стека одновременно причем на достаточном уровне.
Релиз Linux 6.11