Comments 27
Из ядра уберут legacy-драйвер, обеспечивающий работу устройств с интерфейсом IDE/PATA
Конец дистрибутивам, ориентированным на старые ПК? Вот как после этого ставить свежий дистрибутив какого-нибудь Puppyrus (или другой) с новым ядром на относительно старое железо? Или всё же этот драйвер в виде модуля оставят?
libata же
Опускаемся на две ссылки вглубь и читаем:
Before getting too emotional over your ribbon cables, this is not the removal of IDE support from the Linux kernel. Rather, this is only about the legacy IDE driver. IDE hardware support will remain available in the Linux kernel via the libata layer. The Linux kernel for years has used libATA as its preferred library for supporting ATA controllers and devices. There are libata-based drivers for all the popular hardware of the time while it's just the previous legacy IDE driver that is set to be removed from the kernel in two years time.
Потому что не собор, а базар. В NetBSD, насколько я понимаю, обычно происходит, как вы описываете. Поэтому, имея меньше всего пользователей и разработчиков из *BSD, она до сих пор как-то ковыляет.
Также стоит отметить, что в Linux будет поддержка ARM и RISC-V благодаря компоненту rustc_codgen_gcc…
Непонятно, причем тут поддержка ARM и RISC-V. Во-первых, Linux и так поддерживает ARM. Во-вторых, это относится только к rust-коду, при чем тут Linux в целом? В третьих, данный компонент предназначен для того, чтобы код на rust можно было скомпилировать для платформ, поддерживаемых GCC. В общем, этот абзац, на мой взгляд, можно совсем выкинуть из заметки, кроме предложения о том, что в ядро скоро может будет писать на rust.
А это не снизит производительность? Ну типа Раст или как его там, все таки си довольно низкоуровневый и оптимизированный годами, а эти ваши хипстерские новомодные языки не пойми что.
Первый раз за 30 лет в ядро добавляют поддержку нового языка. Я хотя бы из любопытства посмотрел, что же это за такой хипстерский язычок.
Раст тоже *может быть* низкоуровневым и оптимизированным. Не факт, что уже таковым является, но теоретически его таким можно сделать. Он не тянет за собой виртуальных машин, сборщиков мусора, в нём нет каких-то фундаментальных ограничений. Всё или уже работает быстро, или может быть оптимизировано и работать быстро в будущем.
Тоесть получается чтобы сделать произвольное ядро от generic мне требуется знать 2 языка? Такой 20 лет патчи к ядру делал, а теперь с каждой новой версией будут добавлять новый язык который если не знаешь уволят? Охренительно, я в восторге...
Поддержка раста не такая уж и богатая, есть встраивание в систему сборки и биндинги на C реализацию функций ядра. Linux headers никто разом не выкинул. Написали пример с драйвером для GPIO https://lwn.net/Articles/863459/. Приглашают энтузиастов пробовать разрабатывать собственные драйверы.
а теперь с каждой новой версией будут добавлять новый язык который если не знаешь уволят?
это ваши отношения с работодателем.
Нет, конечно. Подавляющее большинство кода и ядра, и драйверов всё так же будет на С. Просто в определённых местах, возможно, люди захотят использовать Rust. Вот решит производитель какого-то железа, что ему важно качество продукта и потребует драйвер для него написать на Rust. Ну, в таком случае да, тот, кто 20 лет сидел в танке и писал на одном С, такой проект не получит.
Ну, так-то и на расте с помощью ансейф-магии можно получать тот же ассемблерный выход, что и на си, но предлагаю не холливарить на тему "а нафига тогда оно надо".
Главное, что это только добавит возможность писать модули на расте, поэтому производительности существующего кода ничего не будет. А производительность создаваемых расто-модулей будет зависеть только от их разработчиков.
В Си из-за aliasing'а (когда разные переменные ссылаются на один тот же участок памяти, часто с разным представлением типов) нет возможности компилятору использовать все возможные агрессивные оптимизации по максимуму, т.к. нет гарантий, что оптимизация не нарушит каких-то инвариантов. Поэтому в теории (и иногда на практике) Rust может быть быстрее Си.
Надо будет почитать что за раст такой этот, он что реально лучше чем си в плане оптимизации скорости работы?
Тут голанг не успел появится, расты всякие понапридумывали, вот же молодёжь не усидчивая, раньше было лучше: С С++ C# Java и Python для скриптов автоматизации было за глаза. А потом устроится никуда не получается ибо надо знать или 100500+ языков, но посредственно ибо не обхватить все за такое время или 3-4 и искать полтора объявления.
Так ведь пока еще не приняли PR с поддержкой Раста и эта эпопея может затянуться. Это же, блин, первый ЯП, кроме Си, на котором можно будет официально писать модули ядра.
Хм. Вангую боль и страдания пользователям генту, сидящем на старом железе, лет эдак через 5, когда без компилятора раста не получится собрать половину модулей ядра, а собрать раст не получится без 16+ Гб оперативки и 100500 ядер. Надеюсь, что будет вообще хоть какой-то способ собирать линукс без раста дальше. Пусть и не с полным клмплектом драйверов.
Не волнуйтесь вы так за нас, в генте есть бинарный дистрибутив раста :)
Есть dev-lang/rust-bin, прекомпилированный пакет с растом специально для таких, как Вы.
Собираю свои пет проекты на расте на нетбуке с intel atom n280 внутри. Не скажу, что это прям комфортно, но и особой боли не вызывает. Вот современные браузеры - вот они действительно вызывают боль)
Linux kernel 5.14 — что изменится в новом ядре