Комментарии 207
Линус суров, но это Линус ... ))
Уже бы портировал на Rust целиком и не парился.
всего-то 30m+ строк, которые написаны за 30+ лет тысячами разработчиков. строк, которые работают на экзотическом железе, которое сложно тестировать. строк, от корректноти которых зависит почти весь мир.
"приключение на 5 минут -- зашли и вышли"
Важно начать )
Отличный повод похоронить уже все это старое г*** и прекратить тащить за собой. Может наконец ОС станет более гибкой и быстрее будет качественно поддерживать современное
Отличный повод похоронить уже все это старое г*** и прекратить тащить за собой
Linux: похоронен.
Интернет и половина промышленности: умирают.
и быстрее будет качественно поддерживать современное
Поддержка современного железа в Linux очень быстро появляется. Интел и АМД оперативно коммитят в ядро поддержку своих будущих девайсов.
Приходишь в контору, где код контролирует человек с такими приоритетами. А так код - страашнючий! Костыль на костыле, старые велосипеды, какие-то там древние байндинги.
Потому что сколько-то миллионов (триллионов, квадриллионов) строк кода писаных десятками (сотнями, миллионами) ценнейших разработчиков. И как же такую ценность взять и зарушить в одночасье?
Приходишь в контору, где код контролирует человек с такими приоритетами [...] Потому что сколько-то миллионов (триллионов, квадриллионов) строк кода писаных десятками (сотнями, миллионами) ценнейших разработчиков. И как же такую ценность взять и зарушить в одночасье?
Так в любой нормальной индустрии. Ибо деньги считать умеют. Выкинуть == продукт сдохнет, зарплату платить нечем будет, разработчиков выкинут на мороз (и поделом).
А так код - страашнючий! Костыль на костыле, старые велосипеды, какие-то там древние байндинги.
...а потом оказывается, что большая часть "костылей, велосипедов и древностей" такова лишь в сознании йуного разработчика, у которого еще на губах молоко не обсохло и банально ни опыта, ни эрудиции.
...а потом оказывается, что большая часть "костылей, велосипедов и древностей" такова лишь в сознании йуного разработчика, у которого еще на губах молоко не обсохло и банально ни опыта, ни эрудиции.
Зачем же? Есть объективные способы оценки.
И как Вы собираетесь объективно оценивать мнение о костылях/велосипедах/легаси (это вообще распространенное обвинение в нонешнем IT), которое по определению субъективно?
Можно "задать" подозрительным частям кода пару-тройку вопросов вида:
* Выполняет ли этот код какую-либо актуальную функцию.
* Можно ли этот код упростить.
* Насколько код удовлетворительный с точки зрения лучших практик для данного языка.
И так далее.
Я согласен, критерии каждый вырабатывает сам, но их можно и нужно иметь.
Первый вопрос объективен, однако в большинстве подобных случаев он, код, таки выполняет нужную функцию.
Ответ на второй вопрос, тоже вроде бы объективный, зависит от изучения кодовой базы на предмет того, где оно может использоваться - то есть пришедший на проект новичок может попросту этого не знать, поскольку не может охватить весь проект целиком - для этого архитекторы. Соответственно, может показаться, что костыли и т.п. и можно упростить, а оно какую-то бизнес-функцию несёт где-то. Именно здесь и лежит большинство виденных мной случаев "посчитали велосипедом/легаси" - от незнания.
Третий вопрос уже не объективен - собрания "лучших практик" для языков меняются со временем, это в общем-то просто "записали текущее мнение ряда людей".
Вот именно, всё меняется со временем. Код устаревает, это факт. Функционал тоже устаревает. Часто бывает так, что о фиче уже все забыли, но не выпиливают из за зависимостей на неё или от неё.
Третий вопрос уже не объективен - собрания "лучших практик" для языков меняются со временем, это в общем-то просто "записали текущее мнение ряда людей".
Не менее объективен, чем модные нынче плейбуки.
Не вопрос, всего-то нужно будет на годы прекратить любое развитие, а потом ещё столько же лет разгребать регрессии.
Да тоже не вопрос. Сделать с чистого листа, вложив всю сумму накопленного опыта. Попробовать что-то, что есть только в голове, но существующие структурные ограничения (а они есть) не дают реализовать быстро.
Уже бы запилил с нуля новое ядро и не парился. Newnux или Rustix? Чтобы "прекратить тащить за собой всё это старое г***". Было бы честнее и сразу бы стало понятно, сколько людей готовы пройти этот путь второй раз. А так это выглядит как попытка тихой сапой пропихнуть на плечах других что-то большое и чистое, туда, где его не очень-то и ждут.
Уже давно есть ядро на расте, причем тут это?
При том, что это выглядит как попытка выдать свою доченьку за красну девицу, когда ей уже стукнет 34 годика. Для каждого возраста (проекта) характерны свои сильные и слабые стороны. Нельзя быть вечно модным молодёжным, зато некоторые умудряются набраться мудрости. Тут же, очевидно, наблюдается суета ради суеты, там, где люди согласны (пока) просто добросовестно делать своё дело, если к ним не будут до-этого-самого. Пришло бы время, естественным образом сменились и системы, и люди.
У ядра линукса есть сейчас несколько серьезных проблем и одна из самых главных как раз про "модно-молодежно" - с каждым годом число мейтенеров ядра сокращается, а их средней возраст увеличивается. Оказывается, что молодые программисты не находят для себя интересным поддерживать бесплатно миллионы строк легаси-кода на С. И можно сколько при этом рассуждать о своей "мудрости", но если сейчас не придумать стратегического решение, то дело кончится тем, что разработка ядра будет полностью поглощена коммерческими компания, например, тем же майкрософтом, который является сейчас одним из самых активных контрибьютеров в ядро. Может быть переход ядра линукса под MS и является "естественным процессом", но очевидно Линуса и многих других мейтенеров такой исход не устраивает, по-этому, как одно из решений, приняли идею обновление кодовой базы на более современный язык - Rust. У вас есть другие идеи как решить эту проблему? Озвучьте их пожалуйста.
Проблема не в языке, а в организационных подходах. Молодежь так-то на разных языках пишет, и на Си тоже. В линуксе не пишут хороший код, который бы требовал мало ресурсов для поддержки, наоборот постоянно переписывают, stable API is a nonsense - корень зла здесь.
Так может, проблема с молодёжью не в "легаси-коде на ужасном С", а в том, что молодёжь просто не хочет копаться в проекте из прошлого столетия со всем своим наследием? Не видит перспектив всего этого переписывания? Или Вы считаете, молодых переписывателей "старого г***" тайно не пускают старпёры сишники ради своей прелести?
Идея уже озвучена: вкладываться в новое ядро нацеленное изначально на использование Раста. Если это действительно надо, то будет поддержано массово естественным образом. Вы пишите, что такое ядро уже есть. Почему же с ним не работают также интенсивно? Наверное, нет такой потребности?
Т.е. вы, для решения проблемы развития ядра линукса, предлагаете вкладываться в написание ядра на расте? А можете раскрыть логику ваших рассуждений, каким именно образом работа на ядром ос на расте(оно называется Redox к слову), поможет сокращению числа мейтенеров в ядре Linux?
Нет, я предлагаю не педалировать проблему развития ядра Линукса, в плоскости того, что оно не на том языке написано. Оно уже написано на том, на чём написано. Нашли конкретную дырку в коде, обложите проверками. Это нормальная поддержка зрелого проекта. Если кому-то всё не нравится, "так жить нельзя", и это тоже нормально, но - делайте новое ядро. Переписывание старых рутин на новые языки - это не развитие.
Ну обложить проверками это здорово, а что делать то с тем, что мейнтенеров все меньше? Ничего?
Но ведь написать на расте - это и есть "обложить проверками"!
Но почему вы даже не рассматривается в качестве варианта не трогать работающий код, но создать биндинги к внутреннему API чтобы новый код можно было писать на Rust?
Как крупнейшие компании, использующие ядро Линукса, решат - так и будет. Странно было бы думать, что решения по проекту, используемому на миллиардах устройств, принимает единолично Линус.
Правительство США уже решило дав рекомендации использовать безопасные языки.
Бизнес будет подстраиваться, а значит и Linux.
Та да, походу рекомендации от "Офиса национального кибердиректора Белого дома (ONCD)", не использовать C/C++ находят поддержку. Мол 70% уязвимостей в системах связанны с неправильной работой с памятью, и нужно использовать только безопасные языки.
Но кажется тогда лучше ядро написать с нуля, хотя сложно представить, чтобы ядро системы, которое тесно взаимодействует с аппаратной частью, имела такой высокий уровень абстракции, чтобы не обращаться к памяти напрямую, и использовать безопасные языки.
Это ему ещë идея не пришла переписать всë на КОБОЛЕ.
Какая связь между высоким уровнем абстракции и безопасным языком? Rust считается безопасным языком.
Писать с нуля, это странная рекомендация. Кому по-вашему лучше взяться за то, что сделано не будет?
сложно представить, чтобы ядро системы, которое тесно взаимодействует с аппаратной частью, имела такой высокий уровень абстракции, чтобы не обращаться к памяти напрямую, и использовать безопасные языки.
В том числе этим руководствуются люди вроде Танненбаума, продвигающие концепцию микроядра.
Линус с самого начала был недоволен оным и спорил с Танненбаумом. В общем-то, весь Linux начался как пара доволнений к микроядерной Minix, и потом уже постепенно вырос в отдельную ОС.
Но кажется тогда лучше ядро написать с нуля
Ядро Linux это одна из таких гигантских вещей, которые уже невозможно переписать с нуля.
Примерно, как имперская система мер в США. Они бы и рады унифицироваться с большей частью мира, но затраты будут настолько гигантскими, что нереально.
Примерно, как имперская система мер в США. Они бы и рады унифицироваться с большей частью мира, но затраты будут настолько гигантскими, что нереально.
Дорогу осилит идущий. Ничто не мешает проводит унификацию постепенно. Небольшими шагами.
Они бы и рады унифицироваться с большей частью мира, но затраты будут настолько гигантскими
Великобритания же перешла на метрическую систему, причем не в какие-то древние времена, а в 1965 году, и не разорилась, так что аргумент про "нереальные затраты" звучит странно.
Подозреваю, что в случае США это больше организационная проблема: кто-то должен уговорить все штаты перейти на метрическую систему, договориться о том, как будет протекать процесс перехода, потом организовать подготовку процесса в каждом из штатов, следить за тем, чтобы все укладывались в сроки и так далее. И видимо никто просто не хочет этим заниматься.
Можно сделать какой-нибудь RustNux в частном порядке ))
Можно, но кому нужна система без драйверов и софта? А если включить поддержку линукса вместе с его ядром - это будет история "у нас есть 14 стандартов, давайте напишем единый который все заменит, у нас есть 15 стагдартов."
Ну, современная ОС - очень сложный продукт. Не обойтись без проблем, конечно.
Но, на мой взгляд, уменьшение количества языков, используемых в продукте, упрощает его поддержку и доработку. Потому, было бы закономерно начать пилить новый вариант "того же самого". При достижении желанием пересесть на Rust определенного масштаба )
Причины могут быть любыми. Возможно, у Торвальдса совсем крышу снесло после безнаказанного отстранения российских мейнтенеров.
Я финн. Вы думаете, что я бы *поддерживал* российскую агрессию? Очевидно, дело не только в отсутствии новостей, но и исторических знаний.
"Мы в мейнтенерах женихах как в сору роемся" - (с).
Хотелось бы надеяться, что появится linux-nonrust, как появился linux-libre.
С другой стороны, когда собираешь десктопную gentoo - раст в любом случае приезжает в систему, даже с глобальным юзом -rust. Так что какая разница?
Раст же миллион лет компилится. Если все ядро переписать, то его потом ваще собрать же невозможно будет?
А зачем вам компилить сам компилятор?
Так код на rust тоже очень долго компилируется, по сравнению с аналогичным на других языках.
Сравнивать надо с языками, на которых потенциально можно написать ядро ОС, это С и С++. По сравнению с С конечно медленнее компилится. А вот в С++ шаблоны и заголовочные файлы приводят к тому что компилятор Rust даже быстрее. Зависит от задачи, например код работы матрицами через Eigen компилируется в разы дольше чем такой же код для Nalgebra. А во многих задачах примерно одинаково.
С++ в ядро никто тащить не собирается )
У меня сложилось впечатление, что тут вообще про языки с виртуальной машиной.
Но при этом, если есть жгучее желание, то это возможно. Без шума и гама, для себя, для своего драйвера.
Согласен. Но если в C freestanding не сильно ограничивает (просто нет библиотечных функций), то в C++ оно отрезает часть фич языка (навскидку - исключения, RTTI), так что это уже немного другой язык. Хотя сам так писал (не в ядре, но в подобной ситуации, когда рантайм недоступен).
Не замечаю этого в gentoo. По-моему, то же самое плюс-минус.
А какова причина долгой компиляции на Rust? Полагал, что модульная система на порядок быстрее собирается чем include на Си.
Нахер всяких Кристофов. Молодец, Линус!
Наконец-то, какая-то хорошая новость про него. Ему, кстати, писали в письмах, о недостатке решительности конкретно в данном вопросе. Даже на хабре где-то были ссылки. Видимо, прислушался.
При работе с такой кодовой базой это стало моим худшим кошмаром
Процитирую одного своего коллегу. "Ну, не могут -- пусть увольняются".
Проблема отцов и детей в программировании. Одни на Си собаку съели, не хотят ничего менять, и разбираться в новых концепциях. Другие хотят новое, продвинутое, совершенное, не такое как у стариков. Мой прогноз: рано или поздно натравят LLM и перепишут ядро на Rust'е.
Не надо туда LLM. LLM ужаснейше переписывает с C на Rust. Просто копирует один в один, получается сишный подход, но с синтаксисом Rust. Надо думать головой иногда, а не спихивать всё на LLM
Чтобы переписать всё вручную, нужен гугол человеко-часов синьёров, одинаково хорошо понимающих как С, так и Rust. А таких во-первых, поди сыщи, во-вторых, никто их работу не оплатит. Поэтому, по мере смены поколения суппортеров так и произойдёт. Сишным синьёрам осталось 5-10 лет, и они уйдут на пенсию в любом случае.
Просто копирует один в один, получается сишный подход, но с синтаксисом Rust.
Насколько понял, сейчас у людей получается то же самое
Where Rust code doesn't just mean Rust code [1] - the bindings look nothing like idiomatic Rust code, they are very different kind of beast trying to bridge a huge semantic gap.
"продвинутое", "совершенное" это Вы про Rust? Можете пояснить в чём его продвинутость и совершенность?
Можете мысленно взять в кавычки. Я о том, как воспринимает ситуацию молодое поколение. Это банальная психология, старшее поколение в массе консервативнее, со своими сложившимися навыками и привычками. Более молодые хотят внедрить нечто новое. Линусу надо выбирать, как не потерять первых, и не отпугнуть вторых. Он же понимает, что без свежей крови проект просто будет стагнировать.
@moderator, нечитаемый машинный перевод
Скрытый текст
@moderator ну действительно, неужели так сложно автоматизировать "информационную службу хабра", если она всё равно гонит машиный шлак? Сделайте кастомный фид, из которого робот будет по набору правил брать новости, переводить, и постить на Хабр.
Вы лучше укажите, пожалуйста, где конкретно неправильно переведено или напишите про это в ЛС автору для исправления.
Денис, вы меня извините, но подход "отбраковка руками пользователей" для меня остался в прошлом веке, вместе с компанией "Рога и Копыта" с Большой Якиманки.
В этом веке я ожидаю, что ляпы будут единичными, а не мейнстримом. А от новостного редактора я ожидаю, что он хотя бы один раз прочтёт своё творение и попытается понять его смысл. А не будет ждать, когда его натыкают носом читатели.
Причём речь идёт не об отдельных ляпах типа опечаток или несогласованных предложений, а о целых абзацах или даже постах, таких как например ваше предыдущее творение, в котором 150 лет лёгким движением руки превращаются в 300.
Почему не мог ещё раньше внедрять более близкий к C С++?
А смысл? В нём также можно наломать дров с памятью, как и в C. И о близости можно поспорить. C++ -- это ООП. В Rust как и в C нет понятия объектов и классов.
Можно наломать, а можно нет.
Можно писать в стиле C, только с какими-нибудь kuniq_ptr и kshared_ptr.
А зачем тогда тащить C++, если в итоге будет C с классами? Так оно и так плюс-минус присутствует в коде ядра, местами. Если я ничего не путаю.
UPD: Ради контейнеров умных ссылок - ну не знаю, как будто бы и не стоит овчинка выделки.
А Раст там будет прям во всю свою мощь, а не лапшой с unsafe?
Мне кажется многие переносят прикладные впечатления на ядро.
В ядре нет C11, а есть GCC C с дополнительными ограничениями, нет всей стандартной библиотеки, и, например, variable length arrays были, потом эта штука стала неугодной, хотя вроде фича языка.
Мне кажется перейти с "диалекта C со своими ограничениями" на "диалект C++ со своими ограничениями" можно достаточно безболезненно, и получить какие-то преимущества. С Растом всё выглядит слишком затратным.
И, как написали, ООП в ядре уже есть, но так себе.
C++ несколько раз уже терял совместимость сам с собой. "constexpr", например, Заменили бы макросы, а потом C++ взял и запретил для них приведение типов. А что с кодом делать?
Я на этом очень сильно попал.
Аналогично с их проклятой семантикой const&. За это им вообще в аду гореть.
И самое главное: С++ не гарантирует бинарной совместимости. Причём даже там, где мог бы (то есть даже в простых структурах классах). То есть все интерфейсы вам нужно через export "C" описывать, а иначе работа пользовательского когда и внешних модулей ядра (что особенно важно), зависит от типа и версии компилятора. А ядро это сплошной импорт/экспорт, так как модули могут как встроенными, так и внешними, а многие структуры ядра используются, как внутри ядра, так и для обменя с внешним кодом.
А на хрена вам C++, еcли вам совершенно всё придётся заворачивать/разворачивать в export "C"?! Где там будут все ваши безопасные типы?
C++ несколько раз уже терял совместимость сам с собой. "constexpr", например, Заменили бы макросы, а потом C++ взял и запретил для них приведение типов. А что с кодом делать?
Опять какие-то прикладнопрограмные проблемы. Ядро вроде сейчас собирается командой gcc -std=gnu11, ну будет собираться командой g++ -std=gnu++11. И так будет собираться сколько нужно, например хоть 20 лет. Когда новая версия GCC готовиться к выходу, туда шлют коммиты, чтобы ядро собиралось. Это не ваша локальная программа, тут другой уровень.
И самое главное: С++ не гарантирует бинарной совместимости.
В ядре и сейчас это не соблюдается. И, помнится, собирая модуль ядра другой версией GCC можно поиметь проблем. То есть, как бы ничего не поменяется сильно.
А прикладные программы к ядру обращаются через отдельный механизм, системные вызовы, с вызовами extern "C" не связанные, и их API не меняются.
Ещё раз: С++ не обещает и не обеспечивает никакой бинарной совместимости. Не важной какой стандарт - во всех стандартах написано, что не обеспечивает. Как только программа собранна, то всё - вся бинарная совместимость закончилась.
И это про не стандарты C++. Это про вызов внешнего кода. Вы не можете передать С++ объект во внешнюю библиотеку (DLL/SO и т.п.) и не можете получить его оттуда. А как вы в таком случае реализуете модули ядра, которые пользователь сам собирает только из заголовочных файлов?
Раст там будет прям во всю свою мощь, а не лапшой с unsafe?
unsafe в расте даёт ровно пять вещей:
Разыменование сырого указателя
Вызов функции, помеченной unsafe
Доступ на чтение/запись мутабельной статической переменной
Реализация трейта с пометкой unsafe
Доступ к полям union
Борроу чекер и остальные гарантии языка остаются на том же уровне. Что же тут не мощного?
лапшой с unsafe
При правильно выстроенной границе между кодом на расте и остальным, кода с unsafe будет совсем немного.
То есть этот unsafe опять даже ноду в трех двусвязных списках держать не позволит?
Отчего же нет? Позволит, первый пункт.
А как это согласуется с borrow checker'ом, если непонятно, кто у ноды владелец?
Никак, у сырых указателей нет возможности отслеживать валидность, владельцев, алиасинг и прочие свойства, потому они и сидят за unsafe. Задача программиста, использующего unsafe в коде, - предоставить интерфейс без unsafe, соблюдающий гарантии раста.
Ну вот видите. То есть все преимущества раста теряются, так что нет смысла менять шило на мыло.
Один раз написав библиотеку, реализующую двусвязный список, вы получаете возможность во всем остальном коде пользоваться преимуществами Rust.
Кстати, точно так же поступают во всех других языках без сборщика мусора. В С++ например.
Проблема с системным програмимрованием (и некоторыми видами юзерского, типа графов), что оно там всё такое. Не получится такого, что "вот мы ровно одну фичу в unsafe завернули, и всё, больше таких нет", увы.
Кстати, точно так же поступают во всех других языках без сборщика мусора. В С++ например.
При использовании библиотек преимущества Раста над этими языками опять же теряются.
Вот у меня сейчас в прошивке для микроконтроллера на 50KLOC ровно 2 unsafe (можно и без них, если вынести в библиотеку). В проекте всё на прерываниях, DMA, очередях, мютексах, RTOS, lock-free аллокаторы и т.д. Так что инкапсуляция вполне позволяет строить безопасное API в огромных кодовых базах.
При использовании библиотек преимущества Раста над этими языками опять же теряются.
Если ли я в этих 50KLOC случайно напишу гонку данных, то она не скомпилируется. Как с этим в С++, С# или Python например, не подскажете?)
См. коммент с примерами участия в нескольких списках сразу, где такого в ядре много. То, что в каком-то подмножестве unsafe требуется редко (а микроконтроллеры, как и драйверы, не являются чем-то эссенциально сложным), не означает, что весь системный код будет являться таковым. И нет, 50 тысяч строк - это отнюдь не "огромная" кодовая база. Для языков типа Си или Java это довольно маленький проект, к выразительным высокоуровневым языкам Раст не относится, так что и в нём не огромная.
Если ли я в этих 50KLOC случайно напишу гонку данных, то она не скомпилируется. Как с этим в С++, С# или Python например, не подскажете?)
Не знаю, я не пишу на всех перечисленных. И само словосочетание "гонка данных" по-русски режет ухо - что именно имеется в виду? В каждый момент структуру может borrow только один тред? Так это ж сразу "привет" производительности в ряде случае - никаких атомиков, только разрешенные компилятором мьютексы (а не любые), и т.д.
То, что в каком-то подмножестве unsafe требуется редко (а микроконтроллеры, как и драйверы, не являются чем-то эссенциально сложным), не означает, что весь системный код будет являться таковым.
Микроконтроллеры и драйверы - это тот самый код, который (по общему убеждению) весь построен на unsafe. Но практика показывает, что это не так.
А весь остальной код почти не требует unsafe, т.к. выполняется поверх ОС. Вы уж сначала определитесь, что такое для вас системное программирование. Ато это переобувание в полете выглядит так себе..
к выразительным высокоуровневым языкам Раст не относится
От 2 до 4 раз меньше кода, чем в С.
Не знаю, я не пишу на всех перечисленных. И само словосочетание "гонка данных" по-русски режет ухо - что именно имеется в виду? В каждый момент структуру может borrow только один тред? Так это ж сразу "привет" производительности в ряде случае - никаких атомиков, только разрешенные компилятором мьютексы (а не любые), и т.д.
Что же вы не знаете общепринятые термины в системном программировании, про которое так смело рассуждаете? Гонки данных (data race), это один из видов состояния гонки. Приводит к багам, которые проявляются случайным образом, и которые очень трудно найти и отладить.
В Rust это решается трейтами Send и Sync, которые работают поверх концепции владения (borrow). И неверно написанный код не вызовет гонку данных, а просто не скомпилируется. В отличие от тех языков, на которых вы не пишете.
P.S. В драйвере или микроконтроллерах всего один поток. Но гонку данных вызвать очень легко из-за прерываний и DMA. И это большая проблема при разработке ядра Linux например.
А весь остальной код почти не требует unsafe, т.к. выполняется поверх ОС.
Вы уж сначала определитесь, что такое для вас системное программирование. Ато это переобувание в полете выглядит так себе..
Так вполне очевидно из приводимых мной примеров в комментариях - это прежде всего код в ядре. А ядро - оно отнюдь не только из драйверов состоит.
От 2 до 4 раз меньше кода, чем в С.
Сравнивалось небось с кодом, в котором нет соответствующий библиотечных функций, которыми уже обеспечили в Расте. Сам язык не выглядит более выразительным, чем С++ (и более того, выглядит более verbose).
Что же вы не знаете общепринятые термины в системном программировании, про которое так смело рассуждаете [...известные очевидности поскипаны...]
Общепринятым термином является race condition. А "гонка данных" режет русское ухо, напоминая "добрый морнинг, господа телевотчеры" и т.п. кальку.
В Rust это решается трейтами Send и Sync, которые работают поверх концепции владения (borrow). И неверно написанный код не вызовет гонку данных, а просто не скомпилируется.
Вопрос был не в том, как они представляются программисту, а как они реализованы внутри, под капотом. А там чудес не бывает.
P.S. В драйвере или микроконтроллерах всего один поток. Но гонку данных вызвать очень легко из-за прерываний и DMA. И это большая проблема при разработке ядра Linux например.
В микроконтроллерах - запросто, а вот в драйверах зачастую далеко не так. Взять хотя бы RSS сетевых адаптеров.
Сам язык не выглядит более выразительным, чем С++ (и более того, выглядит более verbose)
В Rust есть оператор для проброса кода ошибки выше по стеку, а в С++ его нужно писать руками (потому что исключения в ядре - низзя!). Вы уверены, что это Rust более verbose?
Вопрос был не в том, как они представляются программисту, а как они реализованы внутри, под капотом. А там чудес не бывает.
А они, чудеса, нужны? Вроде же всем примитивы синхронизации давно придуманы и работают, ошибаются в основном программисты когда их используют (или не используют).
Вы уверены, что это Rust более verbose?
Конечно, вот все эти Whooy<Qizda> ровно на том же уровне verbose, что C++, и даже больше. Достаточно сравнить с каким-нибудь действительно высокоуровневым языком типа JavaScript.
Вроде же всем примитивы синхронизации давно придуманы и работают, ошибаются в основном программисты когда их используют (или не используют).
Ну это четверть века назад всем хватало одного вида мьютексов в pthreads, но почему-то прогресс не стоит на месте, особенно в ядрах - их уже больше десятка, всяческие rm-локи, sx-локи, а если еще lockless добавить...
Достаточно сравнить с каким-нибудь действительно высокоуровневым языком типа JavaScript.
Но JavaScript в ядре использовать нельзя, в чём смысл такого сравнения? Выбирая язык для использования в ядре, надо сравнивать кандидатов друг с другом, а не с JavaScript
Ну это четверть века назад [...]
И всё же, какие такие чудеса под капотом вам нужны-то?
Так вполне очевидно из приводимых мной примеров в комментариях - это прежде всего код в ядре. А ядро - оно отнюдь не только из драйверов состоит.
Посмотрите исходники Redox OS например, и убедитесь наконец что количество unsafe в ядре ОС - это лично ваш стереотип.
Сравнивалось небось с кодом, в котором нет соответствующий библиотечных функций, которыми уже обеспечили в Расте. Сам язык не выглядит более выразительным, чем С++ (и более того, выглядит более verbose).
Вы сравнили С и Java, по-этому я написал про С. И библиотеки тут не при чем. Разве в С есть классы, итераторы, трейты/интерфейсы и прочее ООП? А в С++ сильно не хватает тип-суммы (Sum Type), в Rust это Enum. Ну и pattern matching, который завезли даже в С# уже.
Общепринятым термином является race condition. А "гонка данных" режет русское ухо, напоминая "добрый морнинг, господа телевотчеры" и т.п. кальку.
Race Condition (состояние гонки) и Data Race (гонка данных) это разные вещи, что должен бы знать каждый системный программист. Впрочем уже очевидно, что вы им не являетесь.
А перевод на русский не я придумал, он общепринятый.
Вопрос был не в том, как они представляются программисту, а как они реализованы внутри, под капотом. А там чудес не бывает.
В ассемблере будет +- одно и то же. Но вопрос именно в том, чтобы код с Data Race не мог скомпилироваться. Особенно это важно в ядре Linux, по-этому Торвальдс старается продвинуть Rust в ядро.
А вы исходите из позиции: я идеальный программист и никогда не ошибаюсь.
В микроконтроллерах - запросто, а вот в драйверах зачастую далеко не так. Взять хотя бы RSS сетевых адаптеров.
Вопрос стоит как предотвратить Data Race, а вы его замыливаете.
Посмотрите исходники Redox OS например, и убедитесь наконец что количество unsafe в ядре ОС - это лично ваш стереотип.
Вот когда оно будет уметь количество фич, сопоставимое с более-менее мейнстримными ядрами, тогда и посмотрим, сколько на самом деле. До тех пор рано.
Вы сравнили С и Java, по-этому я написал про С. И библиотеки тут не при чем. Разве в С есть классы, итераторы, трейты/интерфейсы и прочее ООП?\
Так оно не уменьшает количество кода. Давно известна шуточная поговорка: если переписать любую программу на ООП, она станет в 2 раза больше.
А в С++ сильно не хватает тип-суммы (Sum Type), в Rust это Enum. Ну и pattern matching, который завезли даже в С# уже.
И как бы эти мелочи влияли на размер кода в разы?.. Кстати, enum даже в Си есть.
Race Condition (состояние гонки) и Data Race (гонка данных) это разные вещи, что должен бы знать каждый системный программист. Впрочем уже очевидно, что вы им не являетесь. А перевод на русский не я придумал, он общепринятый.
Кем общепринятый-то? В наших учебниках в наши времена описывался race condition (который вовсе необязательно переводили "гонкой"). И описанное по Вашей ссылке "В этом примере у нас есть Data Race, но нет Race Condition". Может быть, в среде конкретно Жабы и нормально считать, что "наша программа не содержит Data Race и также не содержит Race Condition" тупым volatile, но у нас в ядре за такое будут бить по рукам, назвав race condition.
В ассемблере будет +- одно и то же.
Не факт. См. в соседнем комменте про разные виды локов.
А вы исходите из позиции: я идеальный программист и никогда не ошибаюсь.
Ровно наоборот. Принципиальным является понимание что происходит, с выбором соответствующих мер, но это как раз в Rust исходят из религиозно-фанатичной позиции "что проверил компилятор, то безошибочно, давайте всё перепишем на раст", за что их и надо бить. Мы же знаем, что ошибаются все, поэтому ревьювить и тестировать надо всё. Это особенно смешно было, кстати, когда мне в прошлом месяце пришлось пересобирать Файрфокс более старой версии (новый сломался с TST нахер), и вот банальный чекаут девятимесячной давности не работал - потому что примерно между Rust 0.78 и 0.80 (не просто минорные, а совсем минорные, каково, а!) чего-то в Линии Партии поменялось, и ранее компилировавшиеся крэйты (time что ли) комиплироваться перестали - с точки зрения раста посвежее оно уже некорректно!
Вопрос стоит как предотвратить Data Race, а вы его замыливаете.
Коим боком увеличение числа тредов в драйвере, совсем другой вопрос обсуждения, "замыливает" вопросы синхронизации? Ведите дискуссию корректно, не путайте ветки, ошиблись про число тредов в драйвере - не обвиняйте собеседника в вопросе, который обсуждается в цитате выше.
Так оно не уменьшает количество кода. Давно известна шуточная поговорка: если переписать любую программу на ООП, она станет в 2 раза больше.
Даже в С++ уменьшает, несмотря на разделение на .cpp и .h. Вы, я вижу, ничего не слышали о таких принципах ООП как наследование и композиция, которые придуманы именно для уменьшения дублирования кода.
И как бы эти мелочи влияли на размер кода в разы?.. Кстати, enum даже в Си есть.
Это просто феерическое невежество! Enum в С это надстройка над int, а enum в Rust это тип-сумма (Sum Type), и он может внутри себя содержать другие типы. И это сильно уменьшает объявление структур например. Зачем вы обсуждаете язык Rust, о котором не знаете практически ничего?
Может быть, в среде конкретно Жабы и нормально считать, что "наша программа не содержит Data Race и также не содержит Race Condition" тупым volatile, но у нас в ядре за такое будут бить по рукам, назвав race condition.
Volatile в Java и Volatile в С или С++ это разные вещи, и они дают разные гарантии. Но вы как обычно не в курсе..
Ровно наоборот. Принципиальным является понимание что происходит, с выбором соответствующих мер, но это как раз в Rust исходят из религиозно-фанатичной позиции "что проверил компилятор, то безошибочно, давайте всё перепишем на раст", за что их и надо бить. Мы же знаем, что ошибаются все, поэтому ревьювить и тестировать надо всё.
Вы не понимаете разницы между кодом библиотек и кодом, использующим эти библиотеки. Для библиотек с примитивами синхронизации в любом случае нужно ревью, тесты и т.д.
Для кода, использующего эти библиотеки, компилятор С и С++ не может проверить, что библиотеки используются правильно. Да и вообще используются, можно забыть вызвать mutex, и код скомпилируется. По-этому приходится обмазываться ubsan, статическими анализаторами и т.д.
А вот компилятор Rust может проверить, и вам с этого очень обидно, и вы специально переводите разговор на другие темы.
Коим боком увеличение числа тредов в драйвере, совсем другой вопрос обсуждения, "замыливает" вопросы синхронизации? Ведите дискуссию корректно, не путайте ветки, ошиблись про число тредов в драйвере - не обвиняйте собеседника в вопросе, который обсуждается в цитате выше.
Не выдирайте слова из контекста. Обычно в драйвере 1 поток, а смысл был в том что кроме него есть прерывания и DMA. То что там в некоторых специфичных драйверах не один поток, ничего не меняет.
Не все, и только внутри блока unsafe, который в идеале один на каждый случай реализации структуры данных или интеграции с внешним api.
Пока что этот диалог напоминает анекдот про японскую лесопилку: "Ага, если внутри unsafe подсунуть рандомное число в виде указателя, всё рухнет! Пойду дальше писать на Си с UB в каждой третьей строчке"
См. выше - такого не будет. И в отличие от анекдота, где засовывали не то, что в нормальной эксплуатации, в системном программировании как раз все эти unsafe-вещи будут типичным явлением.
Кстати, вопрос от человека незнакомого с Rust - просто положить адрес на свою структуру по заданному физическому адресу (скажем, скормить устройству через MMIO, чтобы оно потом эти данные по DMA читало/писало) это unsafe или нет?
Взять raw pointer - это не unsafe. Только разыменование такого указателя будет unsafe. Положить адрес куда-то может быть unsafe, может safe, зависит от API.
API в данном случае просто ассемблер, например ST64B.
Кстати, вопрос от человека незнакомого с Rust - просто положить адрес на свою структуру по заданному физическому адресу (скажем, скормить устройству через MMIO, чтобы оно потом эти данные по DMA читало/писало) это unsafe или нет?
Обратиться к структуре по известному физическому адресу - unsafe. Но можно 1 раз в начале программы небезопасно получить безопасную ссылку на структуру, а дальше работать через неё.
За подробностями можно почитать The Embedded Rust Book - Memory Mapped Registers
Спасибо. Но посмотрел, скажем, на упоминаемый там код для поддержки одного из контроллеров - unsafe там встречается не раз и не два.
Разумеется, ведь смысл PAC как раз и заключается в том, чтобы собрать в себе весь unsafe код, который необходим для работы с железом.
Ну так я изначально имел в виду код поддержки железа, с которым до этого никто не работал (насколько понимаю, в терминах Rust - написание PAC).
Ну, там библиотека обеспечивает некоторые дополнительные гарантии, вроде того что два разных модуля не смогут получить себе по владение одно устройство, а также что все записываемые в регистр данные будут иметь смысл.
Если вы пишете не библиотеку, а просто работаете с нестандартной железкой и достаточно доверяете самому себе, то достаточно крейта vcell либо volatile-register, и ровно одного блока unsafe для получения ссылки.
То есть этот unsafe опять даже ноду в трех двусвязных списках держать не позволит?
А, простите, зачем?
В любом графе рёбра или дуги инцидентны двум вершинам, и скорее всего будут включены в списки рёбер/дуг этой вершины. Добавляем сюда какую-нибудь очередь - и вот у нас три списка для одного ребра/дуги.
Более практический пример - система "сигнал-слот" с поддержкой очереди событий.
Ну вот реальный пример из реализации сокетов - здесь двусвязных списков (TAILQ - это где в голове еще указатель на хвост есть, кроме первого элемента) аж даже не три, а ЧЕТЫРЕ (ну точнее, две головы и два члена):
/*-
* Locking key to struct socket:
* (a) constant after allocation, no locking required.
* (b) locked by SOCK_LOCK(so).
* (c) locked by SOCKBUF_LOCK(&so->so_rcv).
* (d) locked by SOCKBUF_LOCK(&so->so_snd).
* (e) locked by ACCEPT_LOCK().
* (f) not locked since integer reads/writes are atomic.
* (g) used only as a sleep/wakeup address, no value.
* (h) locked by global mutex so_global_mtx.
*/
struct socket {
int so_count; /* (b) reference count */
short so_type; /* (a) generic type, see socket.h */
short so_options; /* from socket call, see socket.h */
short so_linger; /* time to linger while closing */
/* [...] */
/*
* Variables for connection queuing.
* Socket where accepts occur is so_head in all subsidiary sockets.
* If so_head is 0, socket is not related to an accept.
* For head socket so_incomp queues partially completed connections,
* while so_comp is a queue of connections ready to be accepted.
* If a connection is aborted and it has so_head set, then
* it has to be pulled out of either so_incomp or so_comp.
* We allow connections to queue up based on current queue lengths
* and limit on number of queued connections for this socket.
*/
struct socket *so_head; /* (e) back pointer to listen socket */
TAILQ_HEAD(, socket) so_incomp; /* (e) queue of partial unaccepted connections */
TAILQ_HEAD(, socket) so_comp; /* (e) queue of complete unaccepted connections */
TAILQ_ENTRY(socket) so_list; /* (e) list of unaccepted connections */
u_short so_qlen; /* (e) number of unaccepted connections */
u_short so_incqlen; /* (e) number of unaccepted incomplete
connections */
u_short so_qlimit; /* (e) max number queued connections */
short so_timeo; /* (g) connection timeout */
userland_cond_t timeo_cond; /* timeo_cond condition variable being used in wakeup */
u_short so_error; /* (f) error affecting connection */
struct sigio *so_sigio; /* [sg] information for async I/O or
out of band data (SIGURG) */
u_long so_oobmark; /* (c) chars to oob mark */
TAILQ_HEAD(, aiocblist) so_aiojobq; /* AIO ops waiting on socket */
/*
* Variables for socket buffering.
*/
struct sockbuf {
/* [...] */
Это не тот пример, тут TAILQ_ENTRY всего один, а не три.
OK, просматривать весь список из грепа текущей версии на предмет, есть ли четыре, мне сейчас лень, но вот несколько штук по три, и еще целая пачка встречалась по две, не буду захламлять комментарий.
sys/riscv/include/pmap.h-struct pv_chunk {
sys/riscv/include/pmap.h- struct pmap * pc_pmap;
sys/riscv/include/pmap.h: TAILQ_ENTRY(pv_chunk) pc_list;
sys/riscv/include/pmap.h- uint64_t pc_map[_NPCM]; /* bitmap; 1 = free */
sys/riscv/include/pmap.h: TAILQ_ENTRY(pv_chunk) pc_lru;
sys/riscv/include/pmap.h- struct pv_entry pc_pventry[_NPCPV];
sys/riscv/include/pmap.h-};
--
sys/fs/tmpfs/tmpfs.h- union {
sys/fs/tmpfs/tmpfs.h- /* regular and duphead entry types */
sys/fs/tmpfs/tmpfs.h: RB_ENTRY(tmpfs_dirent) td_entries;
sys/fs/tmpfs/tmpfs.h-
sys/fs/tmpfs/tmpfs.h- /* dup entry type */
sys/fs/tmpfs/tmpfs.h- struct {
sys/fs/tmpfs/tmpfs.h: LIST_ENTRY(tmpfs_dirent) entries;
sys/fs/tmpfs/tmpfs.h: LIST_ENTRY(tmpfs_dirent) index_entries;
sys/fs/tmpfs/tmpfs.h- } td_dup;
sys/fs/tmpfs/tmpfs.h- } uh;
--
sys/fs/nfs/nfsrvstate.h-struct nfsstate {
sys/fs/nfs/nfsrvstate.h: LIST_ENTRY(nfsstate) ls_hash; /* Hash list entry */
sys/fs/nfs/nfsrvstate.h: LIST_ENTRY(nfsstate) ls_list; /* List of opens/delegs */
sys/fs/nfs/nfsrvstate.h: LIST_ENTRY(nfsstate) ls_file; /* Opens/Delegs for a file */
--
sys/net/pfvar.h- u_int refs;
sys/net/pfvar.h- struct mtx *lock;
sys/net/pfvar.h: TAILQ_ENTRY(pf_kstate) sync_list;
sys/net/pfvar.h: TAILQ_ENTRY(pf_kstate) key_list[2];
sys/net/pfvar.h: LIST_ENTRY(pf_kstate) entry;
К слову, gdb примерно так перешёл на C++. Но да, размеры проектов несоизмеримы, но чисто для примера.
Ради RAII очень даже стоит. Но это имхо.
В ядре тоже ООП, только накостыленный на сишке.
В Rust как и в C нет понятия объектов и классов.
Что, впрочем, совершенно не мешает писать в ООП-стиле и на Rust и на C. Разработчики ядра Linux как раз так и поступают.
В Rust как и в C нет понятия объектов и классов.
А конструкция dyn Trait тогда что? У трейтов, которые можно использовать через dyn, даже ограничения те же самые что и у интерфейсов в ООП...
Потому что ему не нравится С++: https://harmful.cat-v.org/software/c++/linus
Тогда уж zig...
Он решил поругаться со всеми ;)
Да Линус просто троллит(или тротлит), и набрасывает на вентилятор. Они не могут на расте имплементировать какие-то совсем простые штуки, а там есть вещи куда более серьезные, типа планировщика или подсистем памяти или VFS, код на си которых просто ещё одна низкоуровневая сущность аппаратной реализации ЭВМ и CPU, как они туда на расте залезть хотят? Они вообще регистры только на картинках видели, а там буфер ассоциативной трансляции, регистры виртуализации и прочие страшные штуки. Я молчу про инициализацию процессора и памяти, про загрузку ядра и переключение контекста, там всё на асме, как он туда на расте намылились? Им кто-то запретил писать на расте в юзерспейсе? Или у них болезнь мозга редкая? Пусть напишут на расте для начала нормальный оконный композитор для вэйланда, а потом уже будут в ядро лезть, ну это же блин смешно.
как они туда на расте залезть хотят
как он туда на расте намылились
а с чего вы взяли, что они туда хотят влезть и туда намылились?
речь идет про использовании Rust в тех частях, где он хорошо подходит (драйверов устройств, например), но никто не говорит про то что его обязательно затащат вообще везде и всюду. если какие-то узкоспецифичные низкоуровневые вещи пишутся даже не на сях, а на асме, они так и будут писаться на асме.
CrossVm (Google)
Configures the GDT, IDT, and segment registers for long mode.
https://github.com/google/crosvm/blob/main/x86_64/src/regs.rs#L214
Они вообще регистры только на картинках видели, а там буфер ассоциативной трансляции, регистры виртуализации и прочие страшные штуки. Я молчу про инициализацию процессора и памяти, про загрузку ядра и переключение контекста, там всё на асме, как он туда на расте намылились?
Всё там уже в нектором роде есть:
pub extern "C" fn _start() -> ! {
use x86_64::registers::control::Cr3;
use x86_64::structures::paging::PageTable;
let level_4_table_ptr = 0xffff_ffff_ffff_f000 as *const PageTable;
let (level_4_page_table, _) = Cr3::read();
Не лучше ли Линусу и другим разработчикам ядра принять деятельное участие в доработке и внедрении нового стандарта Си?
Интересно, чью же ранимую душу я задел своим комментарием?) Действительно, разве не лучше доработать тот язык, на котором уже написан этот огромный проект, вместо того чтобы разбавлять кодовую базу совершенно другим языком?
Если это не так, было бы интересно узнать почему.
Если "доработать" язык, то получится новый язык. Итого вместо переключения на новый язык получится работа над новым языком плюс переключение на него - ещё больше работы.
Новый язык понятие растяжимое - это может быть язык сильно отличающийся от Си и требующий полного перестроения, а может быть очень близким или надмножеством.
А предложение разработчикам принять участие в доработке Си легко объяснимо - они знают на многолетней практике каким должен быть системный язык.
Скорее всего, вас заминусовали, потому что вы косвенно выразили сомнение в нужности Раста.
Сообщество любителей Rust - одно из самых агрессивных и токсичных из всех, что я встречал.
А может, потому что разработчикам одного проекта предлагают заняться работой над чем-то другим, что само по себе является токсичным поведением. А ещё потому что новый стандарт Си никак не решит проблем языка, не поломав весь старый код, т.е. либо это бесполезная работа, либо написание нового языка. Оба варианта бессмысленны.
Мог хотя бы trapc подождать.
Какого хрена он вообще там чем то занимается, проэкт полностью принадлежит комьюнити так то.
Да у старого кукуха свистит и цифровой маразм
На фоне того что в эту клоаку из смеси затхлого кода из прошлого тысячелетия и дедов которые его написали практически никто не хочет влезать (мейнтейнеров все меньше и меньше, а новых практически не прибавляется) кто-то переживает что из-за раста исходники перестанут... грепаться. Да уж.
Ничего у человека не щелкает в голове что надо что-то менять и куда-то двигаться к современности, когда навигацию по кодовой базе в 2025 году в эпоху IDE и LSP приходится осуществлять грепом.
Языки, которые требуют для работы с собой IDE или хотя бы LSP, плохо пахнут - и всегда таковыми были, начиная с Java. Об этом еще у Ruby мем с книжками был.
На C в IDE намного приятнее писать, чем без IDE =)
Мне гораздо приятнее на Си писать в vim'е, чем в тормозной IDE.
А для IDE быть тормозной - это обязательное условие?..
В теории, конечно, нет, но на практике почему-то иные не встречались.
Не знаю как в вашем Си, но в моём C# я уже много лет именно такую IDE и использую. И со временем она становится даже быстрее (в том смысле, что железо на моём рабочем компе улучшается быстрее чем студия распухает).
Запускать ей в десятке разных экземпляров = для десяти разных проектов пробовали?
Запускать ей в десятке разных экземпляров = для десяти разных проектов пробовали?
Нет, более двух экземпляров открывать не приходилось ни разу. В том числе и потому, что запускается она быстро и открытые файлы запоминает, а значит нет совершенно никаких проблем открыть её снова когда потребуется.
Если Вы про JetBrains IDE, то там конечно тормоза бывают, да и память кушает. Но иногда побаловаться можно.
Eclipse еще более тормозной.
Visual Studio Community прекрасно работает.
Segger Embedded Studio очень шустрая, одно удовольствие, если бы не посредственный редактор.
VS Code как редактор хорош (кроме очень посредственной отладки), но бывают проблемы с Makefile проектами, плюс иногда IntelliSense чудит.
VS Code не IDE, а редактор. С остальными - тот же вопрос про экземляры, что выше. Понятное дело, что на один экземпляр их более-менее точат, но запустите-ка более одной на 16 гиг ОЗУ, или хотя бы даже одну, но с браузером под сотню табов и прочими приложениями.
Про VS Code я и упомянул, что он редактор. Мне кажется, что если Вы запускается "сотню табов" в браузере, то тут проблема не в IDE. Ну и 16 гигов оперативки в 2025 это уже впритык.
Мне кажется, что если Вы запускается "сотню табов" в браузере, то тут проблема не в IDE.
Конечно, это раздутость/bloat - проблема вообще современного веба. Так-то у меня за две тыщи табов уже, но прогружены они, естественно, не все одновременно (только те, которые были тыкнуты с момента рестарта), и до сотни оно никогда не доходит - OOM killer раньше придет.
Ну и 16 гигов оперативки в 2025 это уже впритык.
Увы, это нынешний типичный ноут, и на моей позапрошлой работе некоторым выдавали ноуты вообще с 8 гигами, очень редкий работодатель Вам расщедрится на больше 16.
Eclipse вполне себе работает, если ему дать внешнюю виртуальную машину и разрешить исползовать больше памяти. Дайте ему 6 ШБ ОЗУ и он очень шустро переварит даже большие проекты. Тормозит сильно меньше JetBrains.
Вы много строчек кода из дерева исходников linux видели? Такие рассуждения, полагаю тут у нас системный разработчик уровня "понимаю механизмы планирования/знаю как работает TLB/могу написать свою реализацию slab", наверное на ассемблере и паскале до этого 16 лет писали?)
Ээээээ.... я нормально так вгружал в QtC, когда нужно было проектные драйвера писать.
Сейчас наговнокодят, а потом будут обратно переписывать :)) это уже доказанный факт. И упрутся в железку, на которую костыль надо будет мастырить :))
Есть такая очень старая поговорка обещять не значит женится. А Линус любитель что-то сказать что бы отнего отстали.
Сначала он говорит, что Rust не нужен в ядре, всё и так работает, «ищите проблемы в себе». Теперь же, наоборот, запихивает Rust в код ядра...
Что-то маэстро никак не выберет, чего хочет.
Корень проблемы - отсутствие стабильного API драйверов в ядре.
Линукс - коммунизм, а Линус - Сталин:
Всё всем бесплатно, не согласным с политикой - принуждение, решения принимает лично и однозначно, все архитектуры равны между собой и поддерживаются, интеллектуальной собственности не должно быть - всё ПО должно быть общественным, в системе у вас есть все права, она полностью принадлежит вам и вы можете делать с ней что угодно кроме перепродажи копий под наименованием своей.
Сам Торвальдс кстати живёт довольно аскетично, у него как таковой штаб-квартиры нет, он терпеть не может меркантильную закрытую зелёную кампанию.
Если согласны повысьте репутацию пж)
Да какой из него Сталин с таким-то бардаком. За отсутствие стабильного API и вообще постоянные переписывания всего Сталин был его расстрелял как за диверсию.
Сталин, расстреливающий за подкукушивание неподдерживаемого говнокода в ядро расхищение народного хозяйства?
Ню-ню
А что "ню-ню"? Именно так и было бы, в соответствии с подходом в других отраслях. Только здесь вменённая статья была бы не про "расхищение", а скорее "растрата".
А теперь смотрим предыдущий ваш коммент:
отсутствие стабильного API
и есть расстрел диверсантов за за подкукушивание неподдерживаемого говнокода в ядро
Чушь какая. Почему-то другие проекты, а уж тем более бизнесы с Long-Term Support, с задачей прекрасно справляются. И только в линуксе сначала "неподдерживаемый говнокод" почему-то проходит ревью, а потом переписывается. И так по кругу - а всему остальному миру приходится тратить ресурсы на постоянную адаптацию своего кода к этим их переписываниям (попробуйте завести что-то, написанное хотя бы лет пять назад, в современном ядре). Вполне тянет на нецелевое расходование ресурсов.
бизнесы с Long-Term Support
Используют Long-Term Support ядра, не?
почему-то проходит ревью, а потом переписывается
Это называется поддержка и развитие.
И так по кругу
Это все еще называется поддержка
всему остальному миру приходится поддерживать свой код
Не благодарите.
Причем поддерживать приходится точно так же, как и всем остальным ядерным разработчикам — это и есть упомянутый вами всуе коммунизм, никто не равнее прочих.
попробуйте завести неподдерживаемый говнокод в современном ядре
Не благодарите.
Вполне тянет на диктатуру пролетариата
Не благодарите снова
Используют Long-Term Support ядра, не?
Попробуйте окунуться в мир энтерпрайза дальше ядер. Здесь нормальные сроки - многие десятилетия, а не как "пять лет у LTS", да и то не в апстриме, а в бизнесе, которыми этим занимается для бизнесов же.
Это называется поддержка и развитие.
Нет. Нормальные проекты - и даже операционные системы - ведут себе развитие без такой фигни. Среди сравнительно распространенных ОС такая херня только в пингвинуксе.
Это все еще называется поддержка
В нормальных проектах и отраслях на неё не тратят больше сверх действительно необходимого. То есть во много раз меньше.
Не благодарите. Причем поддерживать приходится точно так же, как и всем остальным ядерным разработчикам
Под нормальные ОС - не приходится.
это и есть упомянутый вами всуе коммунизм, никто не равнее прочих.
Мной ?.. А тред перечитать? Я как раз нахожу не похожим.
"попробуйте завести неподдерживаемый говнокод в современном ядре"
Не благодарите.
"Вполне тянет на диктатуру пролетариата"
Не благодарите снова
Понятно, с таким приписываемым собеседнику враньем продолжать дискуссию не имеет смысла. Для остальных же поясню на всякий случай, что хороший код - это как раз такой, который "раз отлажен и работает (чем дольше, тем лучше)", переписывать приходится как раз говнокод.
а всему остальному миру приходится тратить ресурсы на постоянную адаптацию своего кода к этим их переписываниям
С открытым кодом таких проблем нет, его поддерживает сообщество. А с закрытым кодом вы в ядре нахрен не нужны.
Хрена с два оно там поддерживает в случае линукса. Постоянно какую-нибудь подсистему объявляют недоделанной, выкидывают, втащив новую, через несколько лет с новой повторяется то же самое, и так по кругу. А вот например у нас в BSD бинарник файрвола ipfw (не обычное приложение, то есть, а системное) от системы 15-летней давности до сих пор работает, хотя 3 версии API уже сменилось.
Постоянно какую-нибудь подсистему объявляют недоделанной, выкидывают, втащив новую, через несколько лет с новой повторяется то же самое, и так по кругу.
Толсто.
А вот например у нас в BSD бинарник файрвола ipfw (не обычное приложение, то есть, а системное) от системы 15-летней давности до сих пор работает
Ну у вас и система по возможностям и юзерфрендли примерно соответствует Линуксу 15-летней давности.
Толсто
Нет, правда жизни. Взять хотя бы тот же iptables - то xtables, то nftables, то теперь на хайпе инструменты на XDP. Или не прямо в ядре, но а-ля "заражение от эпицентра" - docker уже не соответствует последним постановлениям Партии, теперь в моде podman. И т.д.
Ну у вас и система по возможностям и юзерфрендли примерно соответствует Линуксу 15-летней давности.
А вот это как раз толсто. Прежде всего, это не годами меряется (нет одинаковых систем), но и так есть вещи, в которых мы линуксы опережаем, местами даже по user friendly.
Или не прямо в ядре, но а-ля "заражение от эпицентра" - docker уже не соответствует последним постановлениям Партии, теперь в моде podman.
Так никогда не соответствовал же, просто для молодой технологии морально допустимо "срезать углы".
Взять хотя бы тот же iptables - то xtables, то nftables, то теперь на хайпе инструменты на XDP
Появляются новые более функциональные и более удобные инструменты, вот ужас. Всё переделывать заново никто не заставляет.
Или не прямо в ядре, но
...всё равно изменения неимоверно возмущают!
есть вещи, в которых мы линуксы опережаем, местами даже по user friendly
Ага 😄
Не, я согласен, что BSD более цельны и продуманы, чем Линуксы со своим зоопарком. Но про опережение и юзерфрендли это вы лишку хватили. Юзерфрендли там выше разве что при работе с системой через консоль, благодаря однородности утилит. Но кто в 2025 году работает с системой через консоль?
*BSD по user experience это реально Linux конца 2000-х годов.
Всё переделывать заново никто не заставляет.
Конечно заставляют. В 2014 на тогдашней работе писал я модуль iptables, спустся десять лет это всё равно что не писал - не заработает, переписывать надо. В то время как засабмиченный мною кусок кода в ipfw так и остался в том же виде до нынешних обсуждений поднятия одной из сущностей с 16 до 32 бит (глобальное, не имеет отношения к этом коду по "бизнес-логике").
Появляются новые более функциональные и более удобные инструменты, вот ужас.
Это XDP-то более удобный?! Да про это говнище можно целую отдельную статью накатать! За более чем десять лет "развития" они не смогли завезти в eBPF-мапы даже элементарные средства для правильной организации conntrack. Верификатор продолжает падать на каждый чих, я багу в компиляторе заводил летом. Об этом не получается без мата говорить, тьфу.
...всё равно изменения неимоверно возмущают!
Изменения должны быть оправданы, что в рассматриваемой экосистеме - редкость. В норме в бизнесе типично, когда код для определенной фичи работает 20 лет без изменений - пока не возникла потребность бизнеса её изменить (работал я на железной дороге, там и через 30 лет могут придти потребовать внести правки, если не 50, так что там пакуется в ЗИПы весь софт для сборки начиная с операционок этой эпохи etc.). А с этими раздолбаями код приходится переписывать постоянно просто чтоб он работал ("очень быстро бежать, чтоб только остаться на месте"). Хуже только в PHP наверное (и Питон ускоренно в эту же сторону двигается). Бессмысленная работа ради работы, ИБД, трата ресурсов - за это надо наказывать, а не считать эталоном.
Но про опережение и юзерфрендли это вы лишку хватили. Юзерфрендли там выше разве что при работе с системой через консоль, благодаря однородности утилит. Но кто в 2025 году работает с системой через консоль? *BSD по user experience это реально Linux конца 2000-х годов.
Я тонко намекнул, что вообще-то сама постановка вопроса "система Y пытается догонять Linux" оскорбительна. Намек не был понят, придется сказать явно. Системы независимы и развиваются своим путем, а не "одна пытается повторить другую" (такое применимо разве что к ReactOS). Валяйте, доказывайте теперь, где и как "у линукса юзерфрендли выше" - это особенно смешно будет послушать с учетом того, что в "не-консоли", то есть графике, подавляющее большинство *nix-софта кроссплатформенно, и работает одинаково и там и там, без какой-либо разницы в UX/friendly.
Вы политотно-токсичный, чтобы вам репутацию повышать.
Напишите лучше что-нибудь полезное.
Я вроде ничего плохого не сказал, просто провёл аналогию. Сталин здесь считается плохим человеком?
Хабр считается вне политики
Сталин здесь считается плохим человеком?
А где он считается хорошим, кроме кучки полоумных сектантов?
У любых разумных людей, которые смотрят на факты (достигнутые результаты), а не полоумную пропаганду "ах как кроваво". Но политоту развивать на хабре всё же не приветствуется.
Разумные люди это которые считают, что почти 700 тысяч расстрелов за 2 года - вполне норм, можно было больше? Это не разумные люди, а именно что полоумные упыри.
достигнутые результаты
Кек. Буквально:
Какие-то шуты на потешном столбе висят
Тут нечего ловить, не задерживай беглый взгляд
Ты лучше посмотри, как там реет победный стяг
Весёлый кинофильм просто великолепно снят
Разумные люди - это те, которые смотрят на достижения страны за период, от отсталой нищей аграрной "банановой республике" к ядерной сверхдержаве в космосе. Разумные люди в курсе, например, статистики по заключенным в США, и понимают, что подобные циферки при таком проценте от населения - они даже не в топ-10 важного, чего стоило бы рассматривать в таких случаях.
P.S. Это "просто" разумные люди, нейтральные - а разобравшиеся в вопросе и знающие историю скажут, что: таки, слишком мало было - не додавили гадину, и с 1991 недобитые их потомки развалили страну с прямыми жертвами в 8 миллионов человек и косвенными на десятки миллионов, как в Великой Отечественной, но в мирное-то время. Законы биологической эволюции никто не отменял, разумные люди это нынче знают.
На самом деле всё просто решается, нужно на каждого мантейнера взять дополнительного, который понимает в подсистеме за которую отвечает и rust. Тогда легко будет поддерживать два языка.
Возможно, ему занесли, и он не отказался...
Кто у нас там главный "продвигатель" раста из крупных компаний? Майкрософт?
Первыми указаны Google, Arm, и только потом Microsoft,
https://rust-for-linux.com/industry-and-academia-support
Ну Линус мог бы и свой язык написать. С достоинствами раста и без недостатков си.
Вообще не понимаю критиков Линуса Торвальдса , они часто ленивые и не понимают что никогда не сделают того что Линус сделал, а он сделал самую великую и полезную систему для человечества.. Жалеть своё время когда ты делаешь линукс это глупо и непрактично. Уже десятки критиков Линуса Торвальдса попали в безвестность и их проекты просто пропадают. Какой смысл оправдывать свою лень тем что время не хочется тратить ? Наоборот надо сделать всё чтобы система работала или уйти в отставку и вообще не заниматься программированием. Чисто для справки Линус получает миллионы долларов компенсации от фонда и вряд ли ему кто то заносит, у него банально нет времени тратить деньги и тем более их собирать, у него итак полезное занятие есть которое круче денег.
Линус Торвальдс заявил, что продолжит интеграцию кода Rust, несмотря на возражения мейнтейнеров ядра Linux