На проходящей в эти дни конференции Open-Source Summit 2022 в секции ответов на вопросы Линус Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке Rust. Не исключается, что патчи с поддержкой Rust будут приняты в ближайшем окне приёма изменений, формирующем состав ядра 5.20, намеченного на конец сентября.
Запрос на включение изменений в ядро ещё не был отправлен Торвальдсу, но набор патчей прошёл дополнительное рецензирование, избавлен от основных замечаний, уже достаточно давно тестируется в ветке linux-next и доведён до состояния, пригодного для создания слоёв абстракции над подсистемами ядра, написания драйверов и модулей. Поддержка Rust преподносится как опция, не активная по умолчанию и не приводящая к включению Rust в число обязательных сборочных зависимостей к ядру.
Предложенные изменения дают возможность использовать Rust в качестве второго языка для разработки драйверов и модулей ядра. Использование Rust для разработки драйверов позволит с минимальными усилиями создавать безопасные и более качественные драйверы, избавленные от таких проблем как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.
Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами и учёт времени жизни объектов (области видимости), а также через оценку корректности доступа к памяти во время выполнения кода. Rust также предоставляет средства для защиты от целочисленных переполнений, требует обязательной инициализации значений переменных перед использованием, лучше обрабатывает ошибки в стандартной библиотеке, применяет концепцию неизменяемости (immutable) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок.
мне лично rust нравится.
Это всё конечно хорошо, но потом же ядро будет сутками собираться, когда туда ржавых модулей понапихают. Не то что бы это меня сильно беспокоило, но всё ж.
так не тебе ж собирать. я вообще каждый раз, когда вижу сегфолт (а вижу их часто), хочу, прости, наручниками разработчиков к ржавой батарее…
Здоровья гентушникам 😁
Главное что будет меньше багов.
Вы когда последний раз ядро компилировали?
Я - лет 15 назад.
Или больше. Потому что разработчики ядра, которым приходится компилировать каждый день по многу раз, бросят это неблагодарное занятие. И останутся одни растовики, которые ничего своего ценного создавать не могут, только паразитировать на чужих сишных проектах.
Если скомпилировать ядро, пусть даже на расте, для программиста проблема - значит, у него хреновый комп. Если у программиста хреновый комп - значит, это не профессиональный программист, а нищий мамкин энтузиаст-борщехлёб. Если мамкин энтузиаст-борщехлёб не в состоянии монетизировать свой энтузиазм - значит, как программист он хуёв. А хуёвый программист генерит хуёвый код. А хуёвый программист на дырявой сишке это вообще звезда смерти для индустрии.
Отсюда следует, что багов в ядре станет меньше 😁
На одном и том же компе раст конпеляет в разы дольше, это факт. Покупкой нового компа это не исправить.
На одном и том же компе раст конпеляет в разы дольше, это факт
Если это факт, то наверное и пруфы есть. Вот бы на них поглядеть
Покупкой нового компа это не исправить
Покупкой нового компа такое и исправляют. Вон Тредрипперы на Zen 3 скоро в продажу пойдут)
И останутся одни растовики,
Тут вопрос в том, что дешевле, несколько хороших программистов на С И КАДРОВИКИ способные их отфильтровать от общей массы или куча плохих растовиков при том что каждому для работы потребуется треадрипер?
При этом надо учесть то, что во всяких ховто по ведению бизнеса написано то, что бизнес не должен зависеть от работника которого трудно заменить, а хорошие программисты на С именно такие.
Ну а клиентов вообще никто не спрашивает, если они клиенты хотят то могут вести разработку самостоятельно, но только пусть используемые патенты оплачивать не забывают, на что цена будет вообще заоблачной.
То что с вами великими гуру произойдёт это ваша расплата за ваше пренебрежение нуждами быдлокодеров, если бы вы сами сделали средство для облегчённого написания модулей ядра то предлагали бы его на своих условиях воспитав лояльных вам быдлокодеров, но теперь через эту незакрытую брешь к вам влезли проприетарщики и воспитывают лояльную ИМ молодёжь.
С другой стороны может меньше уязвимостей с переполнениями теперь будет. Но тогда надо и системдэ переписать принудительно на раст, а то получается, что ворота кованые железные, а вместо забора дрын.
я вообще от опенбздешников ждал аплодисментов. но их ответ: нельзя просто так взять и использовать rust. мы 10 лет внедряли какую-то мелкую фиговину, а тут вы хотите rust… ну нет!
я посмотрел обучающее видео по расту и мне, админу, который только процедурно может писать, очень нравится язык.
Инопланетный синтаксис не пугает? Некоторые от него прям в обморок падают)
да в том-то и дело, что я не вижу там ничего такого особенного. по крайне мере на старте. можешь привести пример, что тебе не нравится.
Да мне всё нравится, я-то не программист)
я тоже. меня куда больше напрягает, то что пишут программисты :)
в коде сайте, например, типа такого:
List<PreparedUserEvent> list = (List<PreparedUserEvent>) = blablaClass() { blabla function()... } { sdf }
Мне вот интересно, к каким выводам придёт анализ взаимодействия проприетарных рпсширений Rust и расширяемой архитектуры комманд Risk V?
Я правильно понимаю что это грядущая жопа?
Я правильно понимаю что это грядущая жопа?
Да. However, есть малая надежда на развитие растового фронтенда GCC и стандартизацию в ISO.
Проприетарные расширения Rust (что бы это ни было) попросту не станут использовать в ядре.
Но другие станут.
Будет форк ядра с кодом на проприетарных командах и он будет работать, а свободное ядро нет.Будет таже ситуация что сейчас с libre и coreboot или даже ещё хуже, вплоть до полной невозможности работать без платных расширений вообще.
Будет форк ядра с кодом на проприетарных командах и он будет работать, а свободное ядро нет.
Как это затрагивает апстрим? Никак, так что пусть делают что хотят. Закрывать исходники и привязывать к производителю можно и без раста, при чём тут язык вообще?
Будет форк ядра с кодом на проприетарных командах и он будет работать, а свободное ядро нет.
Окстись, ядро это ЖоПээЛ код, его не закрыть. Надо будет – портируют из форка.
Окстись, ядро это ЖоПээЛ код, его не закрыть.
Код будет свободным, но часть операторов языка на котором он написан будет проприетарной и требовать покупки лицензии.
Это обход GPL и его можно решить только дополнением лицензии новыми ограничениями.
Чё за платные расширения? Можно подумать их на сишечке не написать?
Чё за платные расширения?
Когда раст только появился люди отмечали что можно делать проприетарные расширения языка.
То есть можно писать СВОБОДНЫЙ код несвободными операторами и командами.Ты накурился что ли?
он по жизни такой. это же торн.
Жду падения ядра из за модуля на расте с последующими обвинениями не модуля, а его обвязки notabug =)
К слову, а где уже готовые модули которые хотят включать? Глупо же делать поддержку модулей на расте если модулей ещё нет, наверняка есть. Посмотреть бы как они выглядят.
Кстати, а gcc-то умеет нормально раст собирать? Или теперь ядро будут только неправославным clang’ом собирать? Столлман знает?
нинада, астанавитесь
