Комментарии 34
Ну шас сделает свой форк на расте, который своим коммюнит обрастет, станет 15м стандартом
Ушел (не до конца) тот, что был против Rust, поэтому форка не будет.
Будет форк без раста
@Ratenti, Я уверен что форк будет с патчами как и с linux-libre когда Линус разрешил использование блопов в ядре. Только патчи будут откатывать драйвера на си реализацию.
За рубежом уже есть теория заговора насчет финансирования проектов которые мигрируют или поддерживают разработку на Rust, а также занимаются продвижением, рекламой. Из отчетов АНБ она тоже заинтересована в как можно быстрой замене свободных языковых реализаций на Раст. Начало теории было положено с 2022 когда белый дом вдруг неожиданно начал "отменять" кенселлить языки C/C++ и в одном из их отчетов выложенных на своем сайте, они поняли что неправильно изложили мысль о переходе на другие языки, указав только Раст как единственный для миграции и больше никаких, удалили его. Вроде как с 4ch началось расследование и доводы. Собственно удаленный отчет здесь был (вейбек используйте): https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
Не совсем понятно в чем выгода, если Rust точно так же открытый проект и разрабатывается по тем же правилам?
Моет они банально хотят что бы используемый ими софт был более надежным?
@Vedomir ну в случае открытости проекта это не гарантия отсутствия бекдора как недавно найденный XZ Backdoor (Jia Tan) https://en.m.wikipedia.org/wiki/XZ_Utils_backdoor
Нужен независимый анализ компилятора и его выходимых бинарников, для подтверждения теории.
Возможно многие просто забыли о давнем инцидиенте, что и компиляторы могут создавать исполняемые файлы с магическими линк символами, которые могут предоставлять бекдоры и другие разные механизмы скрытия закладки.
https://habr.com/ru/articles/281374/
https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/
указав только Раст как единственный для миграции и больше никаких
Насколько помню, там было много языков предложено, даже Питон в их числе.
Вот, что значит читать по диагонали, посыпаю голову ржавчиной
Напомните мне пожалуйста, разве сам Торвальдс не был против Раста в ядре?
Нет. На раннем этапе (несколько лет назад) он вполне реальные проблемы подчеркивал и на этом все. Проблемы, впрочем, были очевидные, хотя и сложные, и их с тех пор излечили. Во-вторых он был за то, чтоб не тащить в основную ветку rust, пока детские болячки не излечат. Сейчас вроде как ситуация изменилась и стоит вопрос об rust, как об обязательной зависимости для сборки.
Насколько я знаю пока этот вопрос не стоит, Раст остаётся экспериментальной фичей (но понятное дело что рано или поздно это изменится). Текущая драма началась из-за того что Хеллвиг заявил что будет блокировать мерж любого когда на расте если он использует подсистему DMA, несмотря на то что весь код на расте является экспериментальным и никак самого Хеллвига не затрагивает (более того, мейнтейнерам сейчас разрешено ломать свои API игнорируя то что ломаются растровые обвязки, т.к. Раст код вообще не собирается в CI). Но у Хеллвига баттхерт от одного наличия .rs файлов в репозитории ядра.
Он скорее говорил "такие то особенности Rust не применимы в ядре, по-этому в текущем виде я против Rust". В частности речь шла про обработку OutOfMemory error и недопустимость panic при некоторых операциях.
Сейчас эти вещи доработали (а некоторые исправили), и Торвальдс активно продвигает Rust в ядре.
Так-то panic в ядре вообще недопустим. Ядро не имеет права на аварийную остановку.
20-30 лет назад это было бы очень смешное утверждение...
Что за дичь?) Если в ядре возникла критическая ошибка, то оно обязано аварийно остановиться, чтобы не повредить пользовательские данные, например.
Разумеется недопустим. И это устранили:
1) Добавили panic_handler в библиотеку core, чтобы код с паникой без реализации panic_handler просто не скомпилировался.
2) Согласовали с Торвальдсом набор ключей компиляции для ядра, которые заменяют панику в некоторых операциях (на что-то определенное, не UB), например переполнение целых чисел.
3) Добавили в core библиотеку методы с возвратом Result, там где их не хватало.
Видимо у вас как и у меня произошёл диссонанс из за прочтения разных новостей https://www.cnews.ru/news/top/2025-02-10_problema_v_tebelinus_torvalds
Да в последнее время несколько разнополярных новостей по этой ситуации было. Нужно больше смотреть на официальные ответы, а не Линус в переписке с кем-то заявил.
Вообще если посмотреть на технические детали ситуации, то ответ Грега Кроа-Хартмана, между прочим главного мейнтейнера стабильной ветки, полностью разъясняет, что внедрение Rust только облегчает работу. Что при поддержке и ревью в новом коде не нужно обращать внимание на ошибки с памятью. https://habr.com/ru/news/884010/
Это проясняет. У человека реальные проблемы с психикой, походу. Будем надеяться, что он всё выплескивает в истериках, а не как Ханс.
ПС. Ничего оскорбительного Линус ему не сказал (что даже удивительно).
Как я понимаю, ситуация такая:
есть люди, которые хотят писать новые драйверы на Rust
есть мейнтейнеры подсистем, типа вот этого Хеллвига, которые возражают, мол, мы Rust не знаем и не хотим учить
"Окей", - говорят растописатели, "мы напишем обвязки на C, чтобы вам не пришлось прикасаться к Rust"
тут Хеллвигу возразить нечего, поэтому он встал в позу "не хочу, чтобы этот ваш рак вообще хоть как-то был и взаимодействовал с МОИМ кодом"
вмешался Линус, который указал, что "не хочу" это не серьёзно, и если конструктивных возражений нет, то сидите и не гундите, а никакого "вашего" кода, на который вы могли бы налагать выдуманные вами ограничения, в ядре нет
Я не понимаю в чем плюсы ржавчины ? Это же медленная параша , кто в здравом уме будет писать драйверы или модули ядра на ней ? Походу у ядра Linux всё совсем плохо ... Ждем раскол проекта на написанный на богоподобном С и на ржавчине )
В каком месте она медленная? Вполне на уровне сишки, порой даже быстрее: https://habr.com/ru/news/885872/
Пример не удачный, там в каментах указали, что никто и не ставил задачу сделать zlib‑ng самым быстрым, а ставили задачу обеспечить максимульную портируемость, включая всякие экзотические платформы, в том числе и 16 бит. А за доработку на Расте ещё и денег просят там нормально так.
16 бит вовсе не экзотическая платформа, и zlib-rs вполне под них компилируется.
Вообще у них обоих прямо не обозначен список поддерживаемых платформ, т.к. он зависит только от компилятора. Это значит что он примерно одинаковый, за исключением действительно экзотических платформ, натипа PowerPC или Spark.
По оптимизации в zlib-ng заявлен огромный список от SSE2 до AVX512-VNNI, а в zlib-rs пока только AVX512 и NEON. Вероятно он выигрывает на основных платформах, и проигрывает на всех старых.
P.S. Если же сравнивать чисто языки, то Rust должен быть чуть быстрее, т.к. система типов дает больше возможностей для оптимизаций. Но при этом до сих пор нет хвостовой рекурсии например, так что +- одинаково.
Не система типов, а то что может быть только одна мутабельная ссылка, что дает возможность считать почти все указатели не пересекающиммися. На си в оптимизированном коде это тоже оптимизируют просто вручную, или можно даже весь код скомпилить считая что этого нет, и если есть пересечения код просто сломается.
Причина скорее всего более банальна - в дефолтных ключах компиляции, rust использует lto по дефолту, в zlib скорее всего с системным сравнивали где ключи совсем другие. Так же для си надо включать всякие -U_FORTIFY_SOURCE иначе по дуфолту будут проверки вызовов из glibc. Если все это исключить то код на том же clang дожен быть взаимовыражаемым.
Так же в той статье уже упомянули libdeflate, коотрый быстрее zlib-ng в большинстве случаев, так что почему с ним только сравнение непонятно: https://github.com/zlib-ng/zlib-ng/issues/1486
"Пропал Калабуховский дом"...
Сопровождающий ядра Linux Кристоф Хеллвиг ушёл из части проекта после критики Торвальдса на непринятие патчей с Rust