Завершение эксперимента с Rust в ядре Linux

А хороших действующих программистов на Расте много что ли?

Ну я штук 20 как-то видел в одной комнате :) Ну и сама контора Мозила с Гуглом пишет. :) Вон посмотрите на код файерфокса с хромом. У них песочница общая, на расте писана.

Так и тем более тогда таких специалистов должно быть меньше, чем тех, кто Аду осилил.

Надеюсь к тому времени сраную каргу наконец-то похоронят.

Ну задачи-то подходящие под эти языки не устарели же! Вон математику на суперкомпьютерах как писали на Фортране, так и пишут. Не, нуачо, параллелится хорошо, в два псевдокомментария, OpenMP и все такое прочее, библиотеки вон от Numeric Algorithm Group... Кстати, сишные библиотеки у них тоже есть. И чо-то на раст переползать не спешат, хотя чем черт не шутит.

Тут был срач на ЛОРе, что кто-то перешёл с Фортрана на C++, и всё прекрасно.

Обоснуй.

Ну современный фортран отличается от Си только набором ключевых слов :) Ну и прочими удобствами, типа присваивания массивов одним оператором присваивания. Тому, как фортран вообще с массивами умеет обращаться, вообще еще никто так и не научился. :) Interoperability with C полная, хошь фортан зови из Си, хошь наоборот...

Не этот Rust

тыж и сам знаешь, что не поэтому, но посыл забавен :)

Само-собой - это потому что единственный процессор с нормальной архитектурой там это как раз тот самый чип (ARCv3?) на котором minix и крутится :)

с которым очень сложно разбираться по причине самого раста.

Эта новость написана безграмотным хейтером - разбираться в коде Rust ничуть не сложнее чем с С. Если уметь программировать разумеется.

Оно действительно в ядре нужно?

С точки зрения профессиональных разработчиков ядра - нужно. С точки зрения анонимных ламеров ЛОР - не нужно.

Я не кодер, просто как обыватель спрашиваю.

Тебе как обывателю какая точка зрения кажется более значимой?

С++ - это не С.

но поддержка всё ещё экспериментальная.

certain combinations

Только для отдельных комбинаций вариантов сборки ядра. Для всех остальных случаев - нет. Попроси ИИ растолковать тебе фразу целиком раз уж английского не знаешь.

Мейнфреймов по миру больше, чем пентагоновских подрядчиков. :) Спрос несколько шире. А суперкомпов с фортраном примерно столько, сколько мейнфреймов. Ну еще какие-то научные расчеты и модели погоды.

В Intel ME например

Если уж приспичило подушнить, то там проприетарный форк minix поскольку его лицензия такое позволяет. Никакого кода от Intel в оригинальный проект не ушло, Танненбаум про использование в МЕ узнал из новостей после чего смешно истерил.

Старый разработчик ядра и драйвера на расте — https://youtube.com/shorts/_BkTgxCUVzo?si=nBD6JVDSo2qz8sZh

Ада - это далеко не только пентагоновские подрядчики.

Главное, чтобы всегда оставалась возможность отключать сборку кода ядра на Rust. Остальное не важно.

Так и сборку кода на цэ тоже можно отключить. Просто ничего работать не будет. Напишут на расте кучу драйверов, планировщик многозадачности, аллокатор памяти etc и вперёд, отключай сборку на православном расте…

Всегда было интересно, откуда берутся растофобы. Ну вот вообще мне непонятно. Есть только подозрение, что это те же самые люди, что и системдефобы, но это тогда уже не софтварный баг…

Ну ты ещё спроси смотрят-ли подростки порно :)

Если у неудачника без каких-либо достижений в жизни появляется шанс почувствовать собственную значимость, присоединившись к толпе, оживлённо хайпующей на хейте чего-то известного, то он непременно им воспользуется.

Это как рассуждения пикейных жилетов на новом технологическом уровне.

Еще есть неудачники без каких-либо достижений в жизни, которые хайпуют на модном языке программирования.

Личный опыт построения Франкенштейнов.

1. Есть нейронная сетка, которая занимается предсказанием продолжения временных рядов. Писана на фортране, зовется в две процедуры. К нейронной сетке написан интерфейс на фортране со спецификаторами __cdecl .

2. Есть объект на Корбе (С++), который зовет эту сетку через прокладку на Си (extern «C»).

3. Есть система мониторинга на перле, которая через перловый интерфейс к Си зовет сишные функции, которые зовут корбовый объект на С++.

Вот я писал все прокладки (в том числе перловые и фортрановские) и корбовый объект.

И этосукаработало! :)

Да, не только, даже на ЛОРе пару кейсов всплывало.

кто-то перешёл с Фортрана на C++, и всё прекрасно

Что, «1+1» по-прежнему вычисляется точно? ;))

Только массивы теперь приходится копировать циклом, а не присваиванием :) И размер их нихрена не понятен.

Ну, это мелочи... :))))))

Ну после появления std::format я даже готов смириться с отсутствием фортрановских спецификаторов. Не прошло и пятидесяти лет с появления С++, а уже стало удобно печатать результаты вычислений! Выдающееся достижение! :)

Зажили!!!.. :)))

приходится копировать циклом

На си что ли переписали? В цпп std::array прекрасно копируется присваиванием.

А ещё есть eigen.

Ну в С++ — да. А если многомерные массивы и нужно часть многомерного массива скопировать в другой с иной конфигурацией размерностей? Типа копируем эту размерность от сих до сих.

Фортран вот так умеет:

! Assign elements 6 through 10 of 'a' to elements 1 through 5 of 'b'
    b(1:5) = a(6:10)
    print *, "First five elements of b: ", b(1:5) 

Ядро уже превратилось в огромного плохо структурированного монстра

Оно с самого начала таким было - именно про это Торвальдс с Танненбаумом и спорили.

и заменить нормально не могут

Уже отлично заменили.

Решили бы сначала проблему относительной независимости драйверов от ядра

Давно уже решили - DKMS называется.

Да нихрена! DKMS — это только система сборки. Надо еще и сорцы апдейтить своевременно. Внутри драйвера лапшу из макросов LINUX_VERSION_CODE никто не отменял.

Из моего кода:

$ grep KERNEL_VERSION * | cut -d: -f2 
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,11,0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,14,0)
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 2, 0)
#if (LINUX_VERSION_CODE < KERNEL_VERSION(6,7,0))
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,6,0)
#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(5,6,0) */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,3,0)
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,3,0)
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,6,0)
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,7,0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,11,0)
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,17,0))
#if (LINUX_VERSION_CODE < KERNEL_VERSION(6,7,0))
#if LINUX_VERSION_CODE < KERNEL_VERSION(6,8,0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(6,8,0)

std::mdspan?

о боже, до чего докатился, защищаю цпп на лоре

Ну там много чего в std накрутили, но все равно с многомерными массивами в С не особо удобно, а в С++ с многомерными векторами еще и очень многословно получается работать. Не про расчеты язык.

И всегда непонятно, чего стоит вызов какого-то stl-ного алгоритма. Сколько там скрытого оверхеда, как с thread-safety, как это параллелить и все такое прочее.

Это множества пересекающиеся, но не тождественные.

А собственно что в этом такого ужасного?

Ничего. Наоборот, использование более безопасного и выразительного языка с более высоким порогом вхождения может только повысить качество кода ядра. Искренне надеюсь что в обозримом будущем большая часть ядра будет написана на Rust.

только его бинарные логи

Это только у админов локалхоста. Профессионалам хранение текстовых логов в удобном бинарном формате никаких проблем не доставляет.

о боже, до чего докатился, защищаю цпп на лоре

А что не так с gcc?

С бинарным файлом так не получится.

Не получится исключительно у ламера, не знакомого с базовыми инструментами. Но им и одноплатники отлаживать никто в здравом уме не доверит.

Если нужно кусок лога отправить по почте

Не нужно. Логи отправляют по https - и как раз в journal это прекрасно реализовано.

Искренне надеюсь что в обозримом будущем большая часть ядра будет написана на Rust.

Ты не надейся, а перепиши, а то привык на всем готовеньком выезжать.

Ну это же было тут уже неоднократно. Ссылку на меморандум от пяти разведок про утечки памяти я лично где-то в предыдущих срачах публиковал. И про то, как зарегистрирован rust foundation тоже тут было с подробностями. Мне сейчас искать все это ну долго очень, я тут в логах по нашим стресс-тестированиям разбираюсь, некогда.

Вот нашел:

Линус Торвальдс пояснил свою позицию в отношении приёма изменений на Rust (комментарий)

Линус Торвальдс пояснил свою позицию в отношении приёма изменений на Rust (комментарий)

на «никому не нужной» Аде уже есть написали несколько ядре ОС (наиболее известные Ironclad и Muen)

Которые примерно столь же нужны как и сама Ада.

пока растаманы дискутируют о включении своего любимого Раста в ядро Линукса

Ты новость-то прочитай под которой комментируешь. Уже не дискутируют - включили, и даже экспериментальный статус сняли.

Прежде чем вот такое писать - стоит вспомнить, сколько лет С…

В том числе поэтому его и заменяют активно на Rust, причём не только в ядре.

Он, например, может скомпилировать код на одной платформе, и не скомпилировать на другой. Может из-за нестандартного расположения директорий в системе ошибку кинуть. Он капец чувствительный

Он, например, может скомпилировать код на одной платформе, и не скомпилировать на другой

Во-первых, хорошо бы пример; во-вторых, в Си не так, что ли?

Пример - любой проект на расте компилякается только в вакуумных условиях при идеальной температуре. И да, в си такого нет, gcc идеален

Ада - это просто компилятор, фактически на базе gcc

Так и Cobol теперь тоже.

Появился язык с возможностью атомарной передачи владения, ну вот под утечки памяти это и подвязали.

Ну нельзя же до такой степени не разбираться в вопросе. Его изначально как раз Mozilla для этого и разрабатывала. Тебе роскомпозор гугл забанил что-ли?

Проблема утечек была действительно раньше, придумали язык, потом политики озаботились. Тут как раз вторая часть моего утверждения касалась реакции политиков на технические проблемы и реакция растаманов на меморандумы. Я знаю зачем и как придумывали раст. И если бы дело касалось бы только технических проблем, то половины бы хайпа не было бы. Ибо утечки памяти — это одна из проблем. Ошибки в реализации протоколов и ошибки в алгоритмах никто не отменял.