После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.1. Среди наиболее заметных изменений: поддержка разработки драйверов и модулей на языке Rust, модернизация механизма определения используемых страниц памяти, специальный менеджер памяти для BPF-программ, система диагностики проблем с памятью KMSAN, механизм защиты KCFI (Kernelk Control-Flow Integrity), внедрение структуры Maple tree...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58304
> Добавлена возможность использования языка Rust в качестве второго языка для разработки драйверов и модулей ядраДа здравствует новая эпоха!
нужно добавить поддержку кода на питоне чтобы писать модули для ядра на питоне
Лучше на электроне
Линукс повторяет судьбу редокса.
и какая у redox os судьба?
Быть повторенной линуксом
Тсс... Не подсказывай
Интерпретатор языка в духе lisp forth или tcl влез бы намного легче.
> Интерпретатор языка в духе lisp forth или tcl влез бы намного легче.Вот, кстати, ИМХО forth машина в ядре было-бы прикольно.
Не, не надо польскую обратную бесскобочную. Лучше тогда тотально скобочный Lisp.
bpf очень похож на форт машину. Возможно слегка добавлено регистров - но в целом форт машина.
Если уж хочется совсем форт - можно найти старые наброски. Реализация в ядре строк 200, дальше вопрос генератора байткода.
> 13 тысяч строк кода и обеспечивает только необходимый минимум, достаточный для сборки простого модуля ядра, написанного на языке Rust.И что делают эти 13 тыс строк, что не смог сделать раст-компилятор?
Они там по сути переписали std на абстракциях из ядра.
> переписали std на абстракциях из ядраМожет, надо пойти дальше и вообще переписать раст, заменив его сишкой, libc и прочими абстракциями?
>> переписали std на абстракциях из ядра
> Может, надо пойти дальше и вообще переписать раст, заменив его сишкой, libc и прочими абстракциями?
>> ядра
> libcопеннетный экспердизм, аз из
Чтобы собрать модуль hello_rust.ko
А как так получилось, если я на си пишу модуль - ядро менять не надо, а если на расте - даже для хеловорлда надо патчить?! Раст не умеет делать такие же бинарники, как си?
Он все умеет, но для написания помойки требуется опыт разработки чего-то серьёзного для ядра, а такие люди редко фигнёй страдают
Обеспечивают только необходимый минимум
> Да здравствует новая эпоха!посмотрел код реального драйвера на Rust - он выглядел достаточно понятно в первоначальной версии, даже подумал а не начать ли мне изучать его переписывая свой недавно написанный драйвер... и тут через какое то время снова вернулся к этой теме и офигел, после коммита
https://github.com/fujita/rust-e1000/commit/5dd7b1be844b25e5...
код превратился в нечитаемое месиво. Так что нет, я отменяю новую эпоху
это всё ради того, чтобы убратьassert!(dma != !0);
> assert!(dma != !0);в лесу родилась елочка
tx_ring: Pin<Box<SpinLock<Box<Ring<TxDesc>>>>>,
Так а-то здешние эксперты жаловались что всё через unsafe, всё небезопасно. Сделали безопасно - всё равно жалуются. Безопасность на уровне времени компиляции требует подхода.
вам всем стоит признаться себе в том, что линукс в текущем виде существует исключительно благодаря корпорациям
Интенсивно развивается за счет корпораций, но существовал бы неплохо и без них. Как существуют ядра BSD. Откуда только берутся такие корпоративные промытки.
бзди тоже не по фану развиваются
Ну да, там Аппле задонатили 5 долларов целых, вот на них все и держится.
Бзди бывают разные. Фря в этом плане тот же линукс токо в профиль. Нэтбзд вполне себе на энтузиазме держится.
> Интенсивно развивается за счет корпораций, но существовал бы неплохо и без них"Существовал" - это очень точно сказано
Да нормально все было бы. Нашлось бы кому развивать. Свободное ядро всем нужно. И частникам, и академическим кругам. Свет клином не сошелся на американских корпорациях.
> Да нормально все было бы. Нашлось бы кому развивать. Свободное ядро всем нужно. И частникам, и академическим кругам. Свет клином не сошелся на американских корпорациях.То есть, Вы абсолютно согласны с предыдущим оратором: для развития Линукса нужны корпорации.
Ну- ка, количество свободных вёдер уровня линуха, без участия корпораций, перечислишь?
> неплохо
> существуют ядра BSDВ твоём воображении если только.
>в текущем виде
>благодаря корпорациямМне, пожалуйста, один линукс в не текущем виде, спасибо.
Hurd к вашим услугам
Вот так выглядит линукс без корпораций
Ну зачем же Hurd, можно просто Linux-libre поставить. Блобов не будет. Только как выживать с таким ядром, которое не поддерживает большинства оборудования.
Вот кстати, хотел полюбопытствовать, с целью повышения уровня образованности :). Кто-то пробовал Linux-libre на основном домашнем, для примера, железе? И что из этого получилось? :) (На моём основном стационаре с Radeon RX580 сразу скопытилось видео из-за отсутствия firmware, но ssh работал, насколько я помню, давно проверял).
Например, писать драйверы к оборудованию. Быть DIY-гигачадом.
> Ну зачем же Hurd, можно просто Linux-libre поставить. Блобов не будет. Только как выживать с таким ядром, которое не поддерживает большинства оборудования.Дело-то вовсе не в блобах, корпорации большую часть и гплного кода ядра пишут. Линукс без блобов - это, в основном, тоже продукт корпораций.
Hurd юзабелен? Как его протестировать, есть дистрибутивы? Поддерживает х64?
Проблема Hurd - изначально приняты неправильные архитектурные решения.
Но хурд изначально был мертворождённым из-за отвратительного проектирования. Правильнее было бы сравнивать с нетбздой.
Мертвый, зато свободный в понимании гнутых
А вам стоит признаться себе в том что многие корпорации в принципе существуют исключительно благодаря линуксу.
например? почему говорите о ред хат во множественном числе?
> например?Microsoft. Google. Amazon. Xiaomi. Samsung. Sony. LG. Panasonic. D-link. TP-link. Uniquity. Hewlett-Packard. Dell. Lenovo. Huawei. IBM. Intel. AMD. Tesla. Acer. MSI. Asus.
Короче, я устал перечислять примеры.
Кто сказал каноникал?
> например? почему говорите о ред хат во множественном числе?Например основатели гугла сами говорили что без линукса они бы не смогли ничего сделать.
+100500
Чето вспомнился южный парк как укуреный обрыган жаловался на корпорации. Ну корпорации и что? Кто хочет тот свой вклад и вносит.
Формально да, но делают то люди. При капитализме иного быть и не может.
>...исключительно благодаря корпорациям...Да заберите уже своего Леннарда с его системдою!
>>вам всем стоит признаться...не говори что мне делать, и я не скажу куда тебе идти.
Да, корпорация Байкал Электроникс заставила Линуса Торвальдса принять драйвер к Байкалам. Линукс развивается только благодаря Байкал Электроникс.
Minix, Hurd, redox с 749$ донатов хорошие примеры ос без корпорацийВ свободное от работы время очень сложно написать что-то большое и полезное.
У вусего перечисленного есть дистрибутивы? Можно попробовать?
Есть же на сайтах соответствующей ОС.
Debian GNU/Hurd и ещё какие-то у hurd
>В файловую систему Btrfs внесены существенные оптимизации производительностиОтлично, еще бы RAID56 довели бы до стабильного состояния и добавили бы Blake3, xxHH3 128/256 bit - и ZFS больше не нужна.
btrfs уже поддерживается кем-то кроме линуха? Что там с монтированием по сети, sharefs, поддержка в CEPH? В чём она вообще выигрывает?
гуглить winbtrfs
Но он же глючит ещё чаще, чем порт ZFS и EXT под фортки, а есть ещё и другие ОС...
Лет 10 уже поддерживается всеми.
Вин - через winbtrfs
BSD - через fusefs-lkl
Мак - нативно
Скоро будет лет 10 как его из RHEL выкинули, остальное практически всё ложь
вин - бажная поделка (впрочем это классика с любым портом под форточки)
bsd - много можно понайти из серии lklfuse hangs on SIGINT, но EXT4 вроде тащило, но зачем...
мак - а пацаны то не знают https://www.reddit.com/r/btrfs/comments/p7u1ov/mount_btrfs_o.../
В btrfs нет онлайн дедубликации.
экономщики епта, а если данные надо хранить шифрованными?
Тебе есть что скрывать? Вот только не надо загонять про личные данные, стоимость которых меньше 0.004р за юзера.
> Тебе есть что скрывать? Вот только не надо загонять про личные данные,
> стоимость которых меньше 0.004р за юзера.мне есть кого бояться, и поэтому сижу и пишу из бункера.
Вова ты ли это?
> Вова ты ли это?в логе модерирования ответ :)
Если тебе нечего скрывать, выложи сюда свои паспортные данные, адрес проживания, все логины и пароли, ФИО и фото родственников. Ведь после этого никакие мошенники этими данными не воспользуются, да?
Тогда я нарушу закон, opennet нарушит закон, и я нарушу правила opennet. Это мне доставит куда больше проблем.
Храни. Внезапно, хэш всё равно совпадёт
> Храни. Внезапно, хэш всё равно совпадётрежимы шифрования, вектор инициализации - не, не слышал.
Потому что она нахрен не нужна в большинстве случаев из-за затрат ресурсов CPU и RAM. Вон, в ZFS она, вроде, и есть, но пользуется ей в проде примерно никто.
БТРФС - цыклоп на глиняных ногах, падает от каждого неосторожного чиха.
7 лет юзаю - ничего не упало ниразу. Курить мануалы надо.
Добавили бы Blake Blossom.
Ждем толпы неолуддитов, которым требуется DECNet в современных ядрах
Если мне уже скоро вполне может понадобиться nncp или uucp, то вполне может понадобиться и DECNet, особенно если он мне поможет уворачиваться от КГБ.
Мания преследования и мания величия первые признаки шизофрении.
Часто вы уворачиваетесь, соединяя два PDP-11 в peer-to-peer сеть?
в Debian 12 успеет попасть ?
надеюсь, что нет
Да, потому что это LTS, а Debian уже несколько лет как выходит с апстримными LTS-ядрами.
где написано 6.1 - LTS ?https://www.kernel.org/category/releases.html
они вроде собирались 6.2 в LTS.
когда у деби заморозка?
до 6.2 еще месяца три-четыре.
К гадалке не ходи, успеет. Они достаточно оперативно запиливают софт в testing.
Сегодня прилетело.)
Вопреки настойчивым требованиям опеннет экспертов в linux 6.2 добавляют еще больше rust https://lore.kernel.org/rust-for-linux/20221211005609.270457.../Кроме того поддержка rust модулей будет в новом meson https://mesonbuild.com/Release-notes-for-1-0-0.html
Поправка - rust поддерживается и в текущем meson (0.64.1, им mesa 23 с rusticl собирается), в 1.0.0 модуль объявят стабильным.
А для Эльбрусов ничего не добавили? Обидно...
Добавлена поддержка AHCI SATA-контроллеров, используемых в SoC Baikal-T1.Хотя они не производятся
Официально не производятся.
Но официально TSMC не может закупить неон, палладий и рубины.
Нет рубинов, пусть делают на бриллиантах
Бриллианты в лазерах не работают.
Какое отношение Байкал имеет к Эльбрусам?
А что они сделали для этого? Открыли какие-то спеки может? Патчи прислали?
зачем поддерживать сложный процессор который никогда не будет производиться?
ладно бы, если бы в зеленограде хотя бы 90нм эльбрусы освоили.
90 вроде умели, хоть и небольшая партияб сейчас небось оорудование мхом покрылось ибо "зачем покупать совковое если есть настоящее качественое западное"
А изготовленное на 90nm на купленной западной линии это типа свое? На нем и так вроде делали RFID метки и чипы "Тройка", а то что небыло больших промышленных заказов и инвестиционной программы по развитию полупроводниковой промышленности это к правительству Путина. У нас по конституции суперпрезиденская страна, и у президента было целых 20 лет на реализацию "хитрых планов".
Вон, в Японии через 20 лет после ядерных бомбардировок городов в проигранной вой наступило экономическое чудо, а у нас даже войны небыло, населения как у Японии но еще и куча ресурсов.
Зачем что-то производить если можно купить готовое, а деньги распилить, как распиливали деньги на завод Ангстрем.
Купили готовое оборудование АМД 65нм, но оно даже в Россию не доехало.
>А для Эльбрусов ничего не добавили?Я бы добавил уголовное дело по распространению ядра и binutils с асмовставками не под GPL. Это после уголовного дела по поводу картельного сговора.
>по поводу картельного сговораМне кажется это больше по части Yadro...
Ты бы хоть с правоприменением ознакомился, чтоли.
> картельного сговораКартельный сговор кого с кем?
Зачем? Это же эксперт с опеннета.
Ну что, когда сокращение списка поддерживаемых архитектур до трёх-двух с половиной?
https://doc.rust-lang.org/rustc/platform-support.html
>Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.1 - Linux-libre 6.1-gnuПочему эксперты-программисты с опеннет не могут сделать свой Linux-rust-free-6.1-opennet ?
Они же знают как надо программировать, у них руки, в отличии от современных так называемых программистов, растут из правильного места.
Наверное потому, что любители раста не могут создать rust-only-kernel.
лет 5 назад новости и подобные вбросы про раст минусовались, а теперь накручиваются (или с имиджбордов притащили анонов?), типичное окно овертона, "толпа, что ячмень в поле -- стелется по ветру" (к/ф "Фараон")
Вот вам плюсие к не страдаете. Вспоминайте архитектуру компьютеров систем и готовьтесь, марально делать Linux-rust-free-opennet-edition
Мне пофиг вообще, я от айти отстраняюсь, т.к. деградация и инволюция не интересна
Надо читать больше комментариев к новостям на опеннет. Тут что не комментарий, то образец высочайшей компетенции, кладезь знаний, остроумия и мудрости
Аноним 160 вообще пример гениальности
Страдают обычно ожидатели чего-то вот-вот грядущего, но когда оно наступит, они найдут снова о чем пострадать
> Поддержка Rust неактивна по умолчанию и не приводит к включению Rust в число обязательных сборочных зависимостей к ядру
Без ZFS не кошерно.>> Добавлена поддержка AHCI SATA-контроллеров, используемых в SoC Baikal-T1.
Вообще не понятно зачем тащить то, что не производится
>Вообще не понятно зачем тащить то, что не производитсяПотому что, по крайней мере, на это есть спеки и при правильном применении табакерки есть мизерный шанс, что производство сможет начаться? Я понимаю, в этом есть некая толика оптимизма...
А компилятор на плюсах то написан %-%
Компилятор ещё с версии 4.8 стал постепенно включать код на C++
> Вообще не понятно зачем тащить то, что не производитсяПредложи Линуксу выпилить вообще всё, что не производится. Там много чего найдётся.
> Без ZFS не кошерно.Лицензия не позволяет.
>Интегрирована первая часть изменений, обеспечивающих возможность создания драйверов для устройств ввода с интерфейсом HID (Human Interface Device), реализуемых в форме BPF-программ.Эта хрень всё разрастается. Жду новость о возможности написания BPF программ на расте. Будет хипстерский флеш рояль.
>Жду новость о возможности написания BPF программ на расте.А я не жду, ведь для этого надо уметь добавлять бэкенды в компилятор.
> Будет хипстерский флеш рояль.Согласен, надо запретить все эти хипстерские недоязыки и переписать ядро на единственно правильном КОБОЛе!
До PL/1 языки делались для разного типа применений.
Fortran для математики, COBOL для финансов, LISP для ИИ. Всё правильно было. А теперь что не язык, всё сплошной франкенштейн типа php.
… C для ядра Unix.
Флеш рояль на руках с 2019 года: https://blog.redsift.com/labs/writing-bpf-code-in-rust/
>Добавлена поддержка звуковых подсистем, реализованных в процессорах Apple Silicon, Intel SkyLake и Intel KabyLake.А какая там звуковая подсистема в SkyLake? Вот прям в проце, не на матплате?
Я не знаю откуда приходит звук в hdmi выход, из процессора или из отдельного аудио декодера.
Видео драйвер на винде содержит и аудио драйвер, может эта часть имеется в виду.
>Поддержка Rust неактивна по умолчанию и не приводит к включению Rust в число обязательных сборочных зависимостей к ядру."...да всего-то на пол-шишечки!"
Системду так же впихивали.
На 400 тыс. строк ядро стало жирнее.
Не собирай эти 400 000 строк, если ненужны.
Свершилось. Однако долго пришлось ждать, пока раст взойдет на пьедестал почета. И это еще один дополнительный плюс к репутации растоманов - к делу они подходят обстоятельно, 777 раз отмерят и только потом внедряются в ядро.
О, пусть Wayland 777 раз перепишут.
Ага, одни плюсы в репутации.
Firefox пилили, недопилили - бросили; Вроде redox запилили, вот казалось бы, где раскроются все преимущества языка - но нет, полезли в код готовых и состоявшихся проектов, где без них все хорошо было.
Про оголтелую агитацию языка вообще молчу. На моей памяти ни один язык так не пиарили и не пытались засунуть везде, где можно. И наверное, именно это и вызывает наибольшее неприятие.
Можно перестать писать полотно воды после каждого упоминания Rust?
А вдруг кто-то забудет, что раст позволяет безопасно работать с памятью?
И обязательно в первых строках, хотя на нем даже еще ничего не написано. А внизу уже мелочи типа сети, памяти...
Судя по комментариям, остальные изменения онанимусам Опеннета вообще по боку. Вероятнее всего, после слова Раст они дальше вообще не читали.
Не заметил тут такого. Где полотно?
Это ещё норм. В новостях про Electron каждый раз копипаст про его достижения и софт, который на нем написан
> "Добавлена возможность использования языка Rust"Вот видите!
Видим.
Но еще осталась надежда на BSD системы.
Что они тоже скоро включат Rust? /s
Надеюсь, что нет. Если это произойдет - то печально.
Имхо - на 99% пойдут на C++. Rust не будет там, во всяком случае в его текущей, абсолютно бестолковой инкарнации...
Видим конечно. Собственно новость не о релизе ядра ( это так - сопутствующие мелочи), а новом достижении Раста.
Почему раст не может компилировать модули так, чтобы не патчить само ядро десятками тысяч строк, и это только для возможности минимальной сборки?
Может, только это будет код в стиле сишки и в большом unsafe блоке. А его внедряют, чтобы абстрактный вася при написании своего драйвера к unsafe не прибегал вообще.
Почему clang не может/не мог компилировать ядро так чтобы не приходилось патчить ядро сотнями тысяч строк? И это несмотря на то что clang компилятор того же языка на котором якобы написано ядро.
Задай этот вопрос авторам шланга, которые не осилили стандарт Си.
Стандарт GCC C? Ссылочку, пожалуйста.
https://gcc.gnu.org/
Жду когда микрософт задонатит на поддержку C#
И на патчи в виде dll блобов
Меня удивляет негативная реакция сишников на включение раста в ядро. Ведь язык С давно уже прекратил свое развитие, ему конкуренция нужна, чтобы он не закисал. Появление раста на сцене - лишь подстигнет развитие си-экосистемы. Уверен, через 3-4 года язык С будет не узнать. Тем более сишникам надо обслуживать тулчейн раста - LLVM, линкер и огромный список сишных библиотек, от которых раст всё еще зависит. Раст, С, С++ - это все одного поля ягоды, я бы даже сказал единая экосистема. Кстати, многие растоманы очень хорошо знают С/С++. Пора бы и сишникам с плюсовиками познакомиться с растом, что-то полезное перенять может быть. Одно ведь дело теперь делаем.
https://habr.com/ru/company/otus/blog/701324/
Не надо сюда тащить эти ссылки...
Ты к нам не примазывайся, мы тебя в свою компанию не берем
Да сто лет мне сдалась твоя эта компания. Я Анонян - мне свора Анонимов не нужна. Я говорю про связку С/С++/Rust справедливости ради и объективности в том числе.
Слишком толсто
База. Но от неё, как всегда, рвутся.
>Меня удивляет негативная реакция сишниковвы с чего взяли что сишники не довольны? Если по комментам анонов то это явно не показатель.
В интернете (НЕ в опеннете) нет восторгов сишников по этому поводу. Если таковые есть, дайте ссылку - интересно будет почитать.
А так же нет восторгов явистов, иго-гошечек, перловодов ...
И что это доказывает ?
> Ведь язык С давно уже прекратил свое развитие, ему конкуренция нужна, чтобы он не закисал.https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_lo...
>> N3041
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3041.htm
>> Code of Conduct for the technical workэто все на что способны современные сишники <facepalm>
> Уверен, через 3-4 года язык С будет не узнатьУпаси Господи от такого
Никакое мы одно дело не делаем. Раст пихают в ядро для его контроля, для контроля за программистами, для бизнеса, для того, чтоб убить ядро. Потому народ его и не любит. Язык СИ - не идален, но в нем нет проблем писать программы без ошибок в памяти: для этого есть тот же Valgrind, который следит за всеми утечками памяти, неиницализованными переменными. На Расте один "Хелло волд" весит 4 мегабайта, и мне совершенно не интересно, почему так происходит, потому что на Си программы в тысячи строк весят на порядки меньше. Надеюсь, будут форки ядря без Раста: ими и собираюсь пользоваться
Зачем ждать? Пора делать свой форк ядра, ведь опеннет эксперты по Линукс знают как правильно надо делать, как правильно программировать и на чем.
А раньше говорили - вот придут корпорации, вот тогда заживём, победим винду и всё такое..
ну вот.. пришли.. и что? systemd,rust,телеметрия во все щели..
Кто говорил?
Те, кто всё это пропихивает.
> придут корпорации, вот тогда заживём, победим винду и всё такое..Закусывать надо...
> для организации питания устройств через Ethernet.Именно этого не хватало в дополнение к Ethernet через электросеть.
Не знают разрабы ядра, как у нас некоторые провайдеры организовывают питание. Просто берут и две пары из витухи отдают на 220 =).
Ну дык Ethernet-over-Power лет 10 как используется.
Ты удивишься, но эта штука существует почти 20 лет и называется PoE.
> Повышены требования к версии утилиты GNU Make - для сборки ядра теперь требуется как минимум версия 3.82.Ретрограды! Надо уже на Мезон переходить, или даже на Just (на расте).
Мезон - это система сборки. Бэкендом там ninja (ну на Виндах ещё msvc можно). Не хотят они make. Говорят проще ninja на нужную платформу собрать, чем писать генератор под make (не говоря уже про то, что Make не особо торопливый).
Надо на buck2 😀
Ну что за новости, и похоливарить негде! Пока все это полотно только заявленные фичи, а пока их не "потрогали" другие, не_разработчики, то считай что их и нет.
Вон у меня самописный менеджер паролей, на мой взгляд идеальный, а кто-то увидел и наверно вздрогнул бы))
Чел выложи куда-нибудь код посмотреть (без шуток)
на GTK?
Теперь линукс ожидает судьба редоха... Будет работать лишь иногда в виртуалках.
Хипстоту пустили в ядро. Вчерашние формошлепы будут шлепать модули ядра поуши обмазавшись безопасными конструкциями как им кажется. Что из этот выйдет увидим. Также как это может быть не первый прецедент и мы увидим зиг в ядре.
Дык пересобери! Не будь как убунтоид!
Вообще-то это эволюция. Только вот есть сложности с толкованием этого термина ;)
вам еще и zig не угодил.
Че вам надо то? Сделай себе форк, git есть свою ветку обновишь и соберешь без всякого богомерзкого.
> вам еще и zig не угодилКто сказал, что не угодил? Просто прецендент произошел. Раньше был только Си, никакие другие языки не добавлялись. Может через некоторое время и Zig добавят.
Выучи раст, начни писать правильные драйвера раньше всех. Пусть скрипят зубами. Ты же эксперт опеннета, а не формошлёп, верно?
Выучи си, начни писать правильные драйвера раньше всех. Пусть скрипят зубами. Ты же эксперт опеннета, а не формошлёп, верно?
Справедливости ради -- сишка такая же хипстота. Нормальные программаторы пишут на ассемблере.
> Нормальные программаторыА погромисты на чем пишут?
Шлепают сайты на джаве
На опеннете.
Современные так называемые программисты не способны ни на что кроме шлепанья сайтов на java.
Теперь эти фронтэндщики будут считать себя системными программистами и "программировать" модули ядра. Это конец
>>В подсистему BPF добавлена возможность создания "деструктивных" BPF-программ, специально рассчитанных на инициирование аварийного завершения работы через вызов crash_kexec()А вот это круто! Можно ронять серваки конкурентам, и никакой раст им не поможет!
а когда ntfs3 выпилят?
сделали из линукса идол-истукан вавилонский. бегом на osdev - ядро переписывать.. - без раста.
> В состав включён механизм MGLRU (Multi-Generational LRU), который заменил собой старую реализацию LRU (Least Recently Used) на основе двух очередей на многоступенчатую структуру, лучше определяющую какие страницы памяти по настоящему используются, а какие можно вытеснить в раздел подкачки.12309 это хоть уберёт?
Да, должно! Пожалуй, самое значительное изменение в ядре за последние 5 лет. Примерно 2 года Yu Zhao его делал. Ускорило всё: и серверы, и телефоны, и десктопы. И с малым количеством RAM, и с огромным. Уже применяется в Android, на Pixel 6.См. статью о похожем на MGLRU патче, годовой давности: https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/
И видео от Google: https://youtu.be/PW7XA237dgI?t=10779
Если ядро без Раста не соберется, придется его форкать и патчить.
Проблемы непокупателя вендора не волнуют.
> Если ядро без Раста не соберется, придется его форкать и патчить.Насколько я помню, возможность сборки без Раста, как зависимости, было обязательным требованием для включения в ядро.
Это пока что, лол. Очкно Овертона по-малому расшатывается, чтобы массу негодований не получить. Сейчас это в виде необязательной зависимости сделано, поэтому все побухтели и забыли, а потом, когда к gcc раст прикрутят, то уже и в обязательную зависимость добавят.
>когда к gcc раст прикрутят, то уже и в обязательную зависимость добавят.Как будто что-то плохое. Когда Rust в gcc допилят, то можно будет вообще всё переписать на раст.
> возможность сборки без Раста, как зависимости, было обязательнымА толку... Любой винтел-производитель забубенит раст-онли драйвер, без которого не заработает, допустим, браузер, и приплыли...
> А толку... Любой винтел-производитель забубенит раст-онли драйвер, без которого не заработает,
> допустим, браузер, и приплыли...Ну, есть вариант свободного выбора:
- брать железо, которое поддерживается драйвером на Си (живёт же кто-то с linux-libre)
- переписывать драйвер с Раста на Си и компилять самому
- смириться и собрать
- не выёживаться и брать <distro-name>, где ядро уже собрали за тебя. Оно всё равно в бинарном виде, какая разница, чем оно компилировалось
> переписывать драйвер с Раста на Си и компилять самомуВозможно это будет не так просто, онда из версий активного пропихивания раста - обфускация кода.
> - обфускация кода.Каким образом?
Что мешает обфусцировать код на Си (за исключением гарантированного получения тонны мата от Линуса перед тем, как отбросят сей патч)?
Это и мешает. А на расте можно использовать всякие хитрозакрученные конструкции и говорить, что "это я не специально - язык такой".
> Это и мешает. А на расте можно использовать всякие хитрозакрученные конструкции и говорить, что "это я не специально - язык такой".Ну я сомневаюсь, что все мейнтейнеры поголовно дебилы и rust-book прочитать не в состоянии.
На Си тоже можно такой макро-лапши наворотить, что даже с поллитрой не вкуришь, что хотели сказать. Собственно, достаточно открыть какой-нибудь GLib и "наслаждаться".
Пока любители Rust надувают щёки и на каждом углу кричат о безопасности, сишники просто пишут и выкатывают патчи на 50 метров...
И некоторая часть этих патчей - исправление сишных ошибок, которых не допустишь на расте
Хватит этих сказок про бещопасный язык.
Растоманы только и могут что рассказать сказки
Ну, главное, что вас с Янисом Линус не слушает, да и ладно. Да и разработчики tor, гугла и прочих разных. Вот оно всё, принятие, перед вашими глазами в реале происходит, а вы в своей сказке о б-жественном си да непогрешимых си-программистах живете. Страдайте дальше. Дальше для вас будет хуже, для индустрии лучше.
Оверсвоппинг с MGLRU так и не починили, и не починят https://www.youtube.com/watch?v=J81kwJeuW58
Возможно, дело не в MGKRU, там какая-то задница со свопингом в нынешних ядрах. Я всю жизнь использовал vm.swappiness=90, теперь с vm.swappiness=10 стало больно и своп мешает постоянно, ничего не открыть, хотя память свободна. Альттаб делаешь и ждёшь 10 минут пока окно появится. Ещё замечал что своп пжет оставаться занятым на несколько гигабайт, но после swapoff потребление памяти растёт мегабайт на 100 (выключается оооочень долго).
описанное наблюдается и на "нынешнем" ядре 3.10 (или какое там в 7 центоси)обычно выключается своп долго, если там были данные прерванных процессов и ядро на каждую вычитанную страницу ищет чья она.
Ну и еще момент, что если свободной памяти стало больше, то это не сигнал для ядра, что можно вытаскивать процессы из свора.
> возможность создания драйверов для устройств ввода с интерфейсом HID (Human Interface Device), реализуемых в форме BPF-программТанненбаум умеет ждать. Впрочем, послушай его Линус тогда, никакого Линукса не было бы.
> размер патча - 51 МБ, что примерно в 2 раза меньше размера патчей от ядер 6.0 и 5.19
> Около 45% всех представленных в 6.1 изменений связаны с драйверами устройствСтрашно подумать, сколько щас компиляется ядро.
Linux и PC-совместимые явно свернули не туда.
Если компилировать целиком со всеми модулями, то я могу так прикинуть что раз в 10 меньше ресурсов чем для 1 clang. Скажи спасибо, что это си, а не плюсы.
>Добавлена возможность использования языка Rust в качестве второго языка для разработки драйверов и модулей ядра.Ну всё через пару месяцев появятся десятки высококачественных драйверов на Rust (нет) .
> высококачественных драйверов на RustОни смогут высококачественно потреблять память и высококачественно долго собираться. Но главное не это, главное, что высококачественно БЕЗОПАСНО!
> драйверов на RustИ высококачественно содержать 99% кода на Си.
Пора опеннет экспертам собраться и написать свою rust-free ос
> Пора опеннет экспертам собраться и написать свою rust-free осХех. По факту все такие.
Ух, как корежит-то ыкспердов, понимают больненькие, что огромный интересный мир прошел мимо них.
Тут перечислялись разные linux, которых я не знаю, если я буду разворачивать компактный линух сегодня, основой возьму openwrt. Вчера я бы сказал gentoo calculate freebsd. Кстати, calculate. Всегда в тени, а я когда не знаю как сделать правильно - смотрю а как тамошние ребята думают.
Void уже давно для меня безальтернативен. Сборочная система имеется и без 15 минут лагов как в Gentoo.
OpenWRT слишком убог, хотя там musl тоже имеется.
Runit тащит, нет нужды ставить "версии" как в OpenWRT,FreeBSD, OpenBSD,
Calculate имеет какую-то свою лицензию будучи Gentoo хотя там компилировать в оригинале можно очень мало устанавливая Firefox только в бинарном виде как и офисный пакет.
Но Gentoo самоубиться может при обновлении, чего ни разу не случалось с Void Linux.
Мюсли тормозные и дырявые, о какой безальтернативности речь? Ну компилирую я проги с ними на генте, но это шляпа. Только для статических распространяемых билдов годится, но там плевать, пользователь и не узнает, что можно было сделать лучше с глибц (ну зато без нытья что не работает).
Мюсли? Прости, если бы ты хотя бы собрал ядро 6.1, то знал бы что никакая гента не спасет от необходимости вносить изменения с указанием фирмварей с номерами версий, если не стандарт через genkernel. Так вот о какой дырявости речь? Glibc версия для легкого использования wine с 32 битным комплектом скомпилированным,но тут точно также можно как и в генте указать какие пакеты собрать в 32 биттах, впрочем возможно х64 версия скоро будет такое уметь без плясок.
Так вот musl достаточно реактивен чтобы и его использовать. Glibc версия для полупадучих программ хороша. Никакихз проблем с musl у меня не было. Ну пришлось чутка руками править исходники для самбы, которая теперь в комплекте, да OpenOffice настоятельно требует glibc. Если по приколу его ставить, то можно, но это актуально разве что у тебя шрифты в иероглифах называются, а в LibreOffice кракозябры одни тебе показывают. В Void обе версии полноценны, как и в случае с OpenWRT. Что там куда лучше это еще вопрос для быстрых программ. Если код голимый, то ему конечно нужны улучшайзинги. Но на атоме я не видел нужды в glibc.
Если честно, впервые слышу об этом. Поясни, пожалуйста, в чём суть проблемы, и какое отношение ядро имеет к libc?
Ты в теме про ядро пишешь про основу. Так вот в OpenWRT и нестабильную Gentoo пихать 6.1 это надо очень сильно упороться.
А библиотека тут при том, что о ней речь. Но если у OpenWRT почему-то только старые ядра имеются, которые не имеют скажем драйверов на современные модемы, то смысла в ней ноль для тех кому это нужно.
То есть среди актуальных только дистрибутивы с полноценной поддержкой musl для относительно небыстрых компов. Быстрым что так, что эдак - 16 ядер все враз сделают.
Так вот масл он делает все прямо и потому у него программы работают часто безопаснее. Glibc больше для кривых программ на относительно среднем железе и в случае с Void также для старых игр.
Ты сначала потыкай ядро монолитное, не очень, а уже потом вещай какой масл не такой. К ядру на масл, который нужен как системная библиотека у меня претензий нет. К тому же можно мигрировать с версии на версию запросто. Но ты же не пробовал, го знаешь. Вот если в Gentoo слоупоки, значит и везде все нестабильно работает это пока что все что я понял из твоих заявлений.
В генту ядро 6.1, я не обновился на него только потому что не люблю собирать пострелизные баги, через месяц может быть. Было и рк ядро емнип. О чём ты вообще толкуешь, я не понимаю? Мюсли и глибц не имеют никакого отношения к ядру, абсолютно. Они отчасти зависят от ядра, но не ядро от них, они совершенно отдельно существуют. Остальное вообще не понял.А что до производительности мюслей, то убедиться в том, что она процентов эдак на 30 с гаком меньше, может буквально каждый. При этом, у них меньше защит и больше уязвимостей, так что о безопасности никакой речи быть просто не может. В openwrt я подозреваю мюсли только из-за того, что бинари с глибц перестали помещаться (сам через это прошёл, раньше можно было накатить софт через пм и теперь только билдить максимально урезанный образ). Интересное совпадение, что использовать нормально openwrt стало невозможно как раз после перехода на мюсли.
PS сломать генту надо уметь, у меня чаще ядро новой версии (без изменений в конфиге) перестаёт загружатся, чем гента ломается.
если всё по дефолту, то да - падает редко.но если проявить хоть чуть чуть фантазии....
короч - развивайте мЫшленье, на то вам конструктор и даден, или сразу на дебиан.
Главное, не включать LTO (ломает компиляцию и софт) или graphite (непредсказуемо меняет логику в рантайме) глобально, иначе приключения будут после каждого обновления компилятора и особенно забавные, когда bash или libz отвалятся, хотя и gawk вполне достаточно. В остальном, бывают конечно кривые ебилды, но только раз свежесобранная glibc утащила за собой всё. У меня custom-cflags и из-за перехода на libxcrypt обнаружилось, что с этой зависимостью нельзя компилировать glibc с флагом -fno-semantic-interposition, который я использую глобально для всех программ.
ну как так "не включать LTO", неспортивно от слова совсем ;-)))
Нене, я сидел на тру-лто с 4 до 10 с меня хватит. Ни разу за всё время я не получил какого либо заметного улучшения нигде, пусть этим занимаются разрабы (с месоном довольно удобно должно быть). Более бесполезной штуки не существует в природе, только бинари на диске поменьше. Есть куча флагов более полезных (вроде no-plt). А вот PGO с 9 что ли версии гцц очень годная и удобная тема стала -- можно совершенно любой пакет собрать с ним включением пары флагов, только 2 раза пересобирать приходится, я не придумал как это автоматизировать не трогая ебилды. И надо же ещё прогнать код.
ну... не знаю...у меня ноут на древнем i5, пересборка гуя шлангом да с лто заметно прибавила шустрости.
меньше кода - меньше кеш-промахов.
возможно, на многих ядрах да с жирным кешем всё выглядит иначе.
У шланга очень раздутые бинари, они оптимизирует лапшой из goto и не всегда оптимально. Возможно, это самообман. Я много раз бенчил код, производительность которого меня беспокоила. clang O3 в ряде случаев может давать производительность выше, чем у gcc O2 (т.е. без pgo), но лто не оказывает никакого влияния (и я убедился, что у обоих компиляторов это был не fat lto, так что всё правильно).
шланг -O3 ... это интересно 8-)
Я очень надеялся ускорить mediainfo, но нет, ни lto, ни шланг, ни pgo не помогают, хотя я проверял и все оптимизации использовались. А вот jq нормально ускоряется благодаря gcc с pgo. clang-O3 было 14с, gcc-O3 23с, gcc-O2 16с и gcc-pgo 12с. Браузеры компилировал и шлангом и гцц с пго лто и без. Гцц-пго чуть получше в бенчах. От arch=native ощутимая просадка в попугаях. Но в конечном счёте это всё не стоит проблем. Может быть лто и графит это из разряда компилировать всё с -Os чтобы получше в кэши попадало, что мне кажется уже лет так 25 не актуально и даёт только замедление.
проборвал -Os, субъективно -O2 быстрее.отказался от pgo, на мой глаз никакой разницы в скорости.
chromium, libreoffice, openjdk, rust - беру бинарниками,
и с последним (rust-bin) жирнолис собирается почти в два раза быстрее.
вот тебе и "самый быстрый линух".собственно держусь генту ради цельности системы.
Да, если не обновлении очередной системной фигни вылезает противоречие, которое можно бы убрать сказав пересобрать вообще все, но проще снести часть системы и обновить только что-то конкретное и когда взаимые блокировки не дают даже систему обновить приходится сносить часть и вот так можно легко систему положить. Так что это в первую очередь деятельное участие сопровождающих пакеты. Особенно когда они ломают что-то без чего не работает все остальное, а держать бекапы это расписываться в собственной никчемности ибо восстановить систему быстрее чем вот эта вся муть.
После отключения глобального лто ни разу не пересобирал вообще всё, зачем это делать без лто? И не помню, чтобы важные пакеты приходилось удалять хоть раз. Да, при обновлении циклические зависимости разруливаются принудительным удалением 1 проблемного пакета. Это бывает примерно раз в полгода-год. Но, если не обновить, то ничего не будет.
Пути раста неисповедимы!
Амэн!
А какие требования к компилятору раста будут у ядре теперь? Вряд ли в драйверах позволят последние фичи задействовать.
Главная фича - должно быть на расте. Спеки ведь нету даже на язык не говоря про стдлиб.
> требования к компилятору растаОчень правильный вопрос, на который нет ответа по причине отсутствия стандарта на раст.
Относительно раста - вот когда напишут драйвера, а не только хелло ворлд, то и посмотрим на сколько нужно. А то доделают, а окажется что раст не серебряная пуля и драйвер за тебя не напишет.
> вот когда напишут драйвераЛегко! Уже представляем, как будут писать драйвера на расте: берут готовый сишный драйвер, вставляют полторы строчки на расте (где-нибудь в получении строки-версии, где не надо думать), ... профит!
Ржавчина не уничтожает весь объект, она просто делает дырки.
Вся суть "программирования" на расте
вот объясните мне недалекому - почему на расте нельзя скомпилировать модуль ядра так, чтобы он не отличался от модуля написанного на С? Зачем нужны какие-то прослойки в ядре для "поддержки языка"?
Этот так называемый системный язык даже не способен на автоматические биндинги к си. Поэтому недалеким растоманам приходится оборачивать структуры ядра в растобиндинги вместо того чтобы сразу писать на ANSI C
> растоманам приходится оборачивать структуры ядра в растобиндингиЭто наводит на мысль, "внезапно", что структуры в расте - не просто структуры, а с излишней нагрузкой. Но растаманы хвастались, что выхлоп раста - zero-free-runtime, идентичный Си.
А растоманы готовы бить себя четырьмя пятками в грудь что у них zero-free-runtime
На самом деле у них one-free-runtime
ну дык пусть оборачивают - это же проблема программиста модуля и его компилятора. Можно даже генератор какой-то написать, если руками лениво.
на выходе то почему нельзя сделать стандартный модуль со стандартными биндингами к стандартным структурам ядра? Эдак можно дойти до того, что прогрмаммам написанным на расте нужна будет особая операционка для их запуска.
> прогрмаммам написанным на расте нужна будет особая операционкаредох что-то не особо получился. Принялись за линух, в нём пока хоть что-то работает.
> Этот так называемый системный язык даже не способен на автоматические биндинги к си.А bindgen - это тогда что, я не понял? https://docs.rs/bindgen/latest/bindgen/
Примерная схема, как всё устроено (ссыль исключительно из-за картинок): https://habr.com/ru/company/ruvds/blog/670748/> Поэтому недалеким растоманам приходится оборачивать структуры ядра в растобиндинги вместо того чтобы сразу писать на ANSI C
Как я понял, идея в том, чтобы переписать рантайм без libc (на структурах ядра) и по максимуму абстрагировать там же весь unsafe, чтобы уже в конечных драйверах его уже использовать по-минимуму (в идеале, не использовать совсем) и, соответственно, полагаться на гарантии safe-rust. К слову у unsafe тоже есть гарантии, но несколько более слабые (ссыль на русском https://doc.rust-lang.ru/book/ch19-01-unsafe-rust.html )
> Как я понял, идея в том, чтобы переписать рантайм без libcМимо. Нет никакого рантайма. Про рантайм начали говорить опеннетовские сишники, и прекратили говорить примерно тогда, когда им объяснили что если _это_ рантайм, то в си _этого_ рантайма больше, чем в любом расте.
С тех пор, они если и поднимают разговор о рантайме, то как минимум втроём, и так чтобы у каждого из них было бы своё собственное уникальное мнение о том, что такое рантайм.
У раста есть огромный компайлтайм. Ооо, его уменьшили, когда добавили параметризовать типы числами, а до этого макросами генерили имплементации для всех размеров слайсов с 0 до 32. 33 имплементации. И это только слайсы. Уж не знаю, как они там с &str выкручивались, также наверное? А diesel, ты не пробовал его компилять под таблички с 64+ столбцами? Я имею в виду до того, как параметризация значениями стала доступной. Сейчас стало лучше, но я заверяю тебя, в компайл тайме там очень много чего есть. А вот в рантайме только то, что использовал.
> по максимуму абстрагировать там же весь unsafe
Уже теплее. Но недостаточно точно.
Демаркация safe/unsafe -- это не обязательно абстракция. Абстракции могут быть накладны. C'шные строки, например, могут выйти боком, если писать на расте и этих строк много, потому что раст прежде чем работать со строками хочет убедиться, что они utf8 строки, и он не парится насчёт терминирующего нуля. Преобразовывать туда-сюда строки то ещё удовольствие.
Safe-обёртки над C нужны не для того, чтобы создать новые абстракции, а чтобы записать C'шные абстракции на расте, включая сюда и всё то знание об этих абстракциях, которые в C'шном варианте существует только в документации к API или даже только в коллективном бессознательном. Все те гласные и негласные правила о том, как API можно или нельзя использовать, должны быть описаны в самом API, чтобы попытка использовать его неправильно кончалась бы ошибкой компиляции. Например, memcpy нельзя вызывать на двух пересекающихся областях памяти, так? Но это никак не отражено в заголовке memcpy, об этом только в документации к memcpy можно вычитать. В расте это недопустимо: неправильное использование memcpy может привести к повреждению памяти, значит memcpy должен иметь такой заголовок, чтобы его можно было бы использовать только правильно.
На этом бы всё может и кончилось бы, но ядро имеет довольно вычурные правила когда и что можно, а когда и что нельзя, и тут собственно и начинается самое интересное. С преогромным любопытством я наблюдаю, как растоманы выкручиваются, и сейчас я думаю, стоит ли начинать делать ставки на то, что в дополнение к safe/unsafe демаркации, они добавят что-нибудь типа environment's, с возможностью описывать правила, как функции объявленные в одном environment можно вызывать из другого environment'а. Наверное пока не стоит делать ставок, потому что я не додумал мысль до конца, и не уверен что она удачная.
> У раста есть огромный компайлтаймОк. Не буду спорить, глубоко в тему не закапывался. Гуру Раста себя не считаю, кодил на нём пока не особо много. Было интересно, чего все так пригорают с синтаксиса. Причину возгораний не понял до сих пор: синтаксис, как синтаксис / язык, как язык, не самый плохой.
> Safe-обёртки над C нужны не для того, чтобы создать новые абстракции, а чтобы записать C'шные абстракции на расте ... и т.д.
Ну я собственно, вроде как, это же и имел ввиду. Внутри описываем все привязки и все unsafe-ы, выставляем наружу для драйверов максимально-safe API, чтобы можно было полагаться на компилятор.
> Наверное пока не стоит делать ставок, потому что я не додумал мысль до конца, и не уверен что она удачная.
Как-то вот тоже, прочитал, задумался. Подумал, что может и не будут выкручиваться. Из серии: мы вам давали гарантии memory safety на уровне языка, вот они, а "вот это вот: туда ходи, туда не ходи" мы не договаривались, "тут наши полномочия, всё" (с).
> В подсистему BPF добавлена возможность создания "деструктивных" BPF-программ.Мне казалось, они все такие были, с самого начала.
Ext4 так и не получается восстановить даже с суперблоком?
>Добавлена возможность использования языка Rust в качестве второго языка для разработки драйверов и модулей ядра.Если kernel developer не может осилить C - то ему нужно коровам хвосты крутить, а не разработкой заниматься.
Современных так называемых программистов даже к коровам нельзя подпускать
Ну тогда гусям шеи сворачивать.
Они в основном одноглазого питона душат.
> Rust в качестве второго языкаНапрасно, двоевластие до добра не доведёт...
Вот и линукс сообщества познало всю силу раста!
Зачем в ядро добавили эти костыли для раста? Если растаманам так хотелось в ядро, то пусть бы сами и довели свой драндулет до такого состояния, чтобы на нём можно было создавать модули так же и на Си, без всяких "улучшайзеров" со стороны ядра. Странно, что Линус Торвальдс на это пошёл. Стареет? Или в корпоративное рабство загремел?
Да, не решает уже.
>Да, не решает уже.Завидую вашей осведомлённости.
Хороший релиз, хорошо что руст еще не включили как осноной
Моё любимое:>В подсистему BPF добавлена возможность создания "деструктивных" BPF-программ, специально рассчитанных на инициирование аварийного завершения работы через вызов crash_kexec().
Ну всё через пару месяцев появятся десятки высококачественных драйверов на Rust!
эээ, стопэ,
только iommu в 6.0 стабилизировали!
>Добавлена поддержка AHCI SATA-контроллеров, используемых в SoC Baikal-T1.Они ещё шевелятся?