Ник Десанье (Nick Desaulniers), занимающийся в Google обеспечением поддержки сборки ядра Linux с использованием компилятора Clang и также помогающий исправлять ошибки в компиляторе Rust, предложил провести на конференции Linux Plumbers Conference 2020 сессию для обсуждения предоставления возможности разработки компонентов ядра на языке Rust. Ник занимается проведением микро-конференции, посвящённой LLVM, и считает, что было бы неплохо обсудить технические аспекты возможной интеграции поддержки Rust в ядро (им уже подготовлен рабочий прототип для KBuild) и понять нужно ли вообще добавлять такую поддержку и какие ограничения по использованию Rust следует принять...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53331
Тогда я перехожу на OpenBSD, так и знайте.
Так и запишем - "гуся вычеркиваем"
Корпы потирая ручки: "Вот так мы и избавились от Гуся, наш план сработал. Без Гуся мы легко зОхватим все ядро"
Honk honk
пока-пока
скатертью дорога
Протрите хлоркой после него
Раст объективно хороший язык, какие проблемы?
...проприетарные драйверы на скорую руку без проведения должного аудита... - вот тебе и будут проблемы
> проприетарные драйверы на скорую руку без проведения должного аудита.можно и на си писать.
А ты глцпенький... можно, но не будут, будет расто жырно уг код. Удачи вам там на лялексах, пойду пробсдется.
> А ты глцпенький... можно, но не будут, будет расто жырно уг код.
> Удачи вам там на лялексах, пойду пробсдется.Почему вы пишете как умственно отсталый?
> Раст объективно хороший язык, какие проблемы?1. Часто меняется.
2. Контролируется по сути 1 корпой - мазилой.
3. Навороченные конструкции, гарантии применительно к которым вилами по воде писаны.
4. Вебмакаки в ядре не рулят.
1. Про аспекты языка и std::, которые могут измениться, это известно заранее.
2. К Java не имеешь претензий?
3. Конструкции лаконичные и гарантии строгие.
4. Лол.
java такой же убогий язык. Все нормальные люди пишут на C#
Вот если бы C# предложили в ядро включить.
Так разве ещё не в ядре, nt4.0 которое?
Все нормальные люди пишут на Kotlin, Scala или Java (выбирай по вкусу).
1) он небезопастный. В нем unsafe блоки отличии от Си
2) у него ужастный синтаксис
3) на нем невозможно написать ничего сложнее hello world
4) на нем пишут отвратительный, нечитаемый, кривой код
5) он никому не нужен
+1.Кроме того, все эти ужимки с "владением объектом" - полная чушь и околесица. Никто так писать не будет, а "изучать глубоко" - тем более.
И это не говоря о том, что там напрочь отсутствует ООП. Без объектов писать большие сложные системы - медленное самоубийство под тонной собственной вермишели.
> Без объектов писать большие сложные системыИ как же линуксовое ядро на pure C нашкодили-то?
Сам я не фанат этих ваших растов, но вы явно перегибаете...> там напрочь отсутствует ООП
Его поэтому и разрешают. ООП и системное программирование не встречается даже на венде. Железо понимает только структуры данных размещенные в памяти, функции и конечные автоматы всякие. Что там за классы с поведением вы наклепали железу начхать. Ваш чудесный ООП-компилятор даже не соберет это в машинный код. Сначала преобразует в структурную лапшу промежуточного представления, которую можно уже и скомпилировать.
> Без объектов писать большие сложные системы - медленное самоубийство под тонной собственной вермишели
Легко и радостно. Откройте для себя ECS, например, её даже в расте можно. Опять же, это все не про ядро и драйверы.
> все эти ужимки с "владением объектом" - полная чушь и околесица
ну все что угодно, лишь бы не GC. Если бы у раста был GC, он бы повторил судьбу D. По-правде, я тоже считаю синтаксис раста уродливым, а его решение вокруг владения не очевидным. Но всё лучше чем С++ с его виртуальными деструкторами и метапрограммированием на шаблонах, расту 30 лет еще до таких граблей.
> Сам я не фанат этих ваших растов, но вы явно перегибаете...
>> там напрочь отсутствует ООП
> Его поэтому и разрешают. ООП и системное программирование не встречается даже на
> венде.Угу. Именно потому "в венде" имеются объекты ядра https://docs.microsoft.com/en-us/windows/win32/sysinfo/kerne...
и семейство ядрёных функций с префиксом Ob* (например, nt!ObCreateObjectType).
То что это оффтопик, еще не значит, что нужно распространять ложную информацию.Наличие "объекта" не говорит об объектно ориентированном программировании. Так-то в С тоже полным-полно объектов, структуры, например, но ООП там и не пахнет.
В статье, которую скинули любую функцию откройте и убедитесь, что там С-функции. И вообще, статья описывает API доступа к открытым публичным объектам из приложений. ПРИЛОЖЕНИЙ КАРЛ! Приложение это в юзерспейсе, так-то. Они могут быть и на С++.
Настоящие драйверы пишутся там с использованием KMDF. Вот тебе дока на HelloWorld
https://docs.microsoft.com/en-us/windows-hardware/drivers/ge...
Обрати внимание на строчку: "The file name extension is .c, not .cpp."
Visual Studio такая IDE... Она как бы официально не поддерживает С, только С++, но если создать C++ проект и переименовать файлик из cpp в с, отработает C-compiler в рамках той версии стандарта С, которую он умеет (C89 + куски C99). Это как раз и нужно для KMDF и UMDF.
На сайтах MS (docs/msdn) исторически принято не разделять С от C++. Они везде пишут C++ и вводят в заблуждение неграмотных.
> Наличие "объекта" не говорит об объектно ориентированном программировании.Об этом говорят IRP, которыми объекты обмениваются. Но про эти сообщения говорить явно рановато. ;)
> В статье, которую скинули любую функцию откройте и убедитесь, что там С-функции.
> И вообще, статья описывает API доступа к открытым публичным объектам из
> приложений. ПРИЛОЖЕНИЙ КАРЛ! Приложение это в юзерспейсе, так-то. Они могут быть
> и на С++.Ну да, приложение в юзерспейсе получает хендл объекта и с ним оперирует. А в ядре хендл транслируется в указатель на объект. Это называется "сокрытие реализации". ;))
> Настоящие драйверы пишутся там с использованием KMDF.
Угу. Это для Вас они пишут-ся -- сами собой. =))) А кто-то их пишет. С использованием DDK (+IFS Kit), которое стало WDK, а не этого модно-молодёжного фреймворка. Так что с "вот тебе дока" кое-кто явно промахнулся. Читайте для начала Рихтера, или кого там принято рекомендовать по такому поводу. Только потом Уолтера Они.
> То что это оффтопик, еще не значит, что нужно распространять ложную информацию.
Согласен, не делайте этого.
> Это для Вас они пишут-ся -- сами собой. =))) А кто-то их пишет. С использованием DDK (+IFS Kit), которое стало WDK, а не этого модно-молодёжного фреймворка.._.
KMDF - это фреимворк для написания драйверов уровня ядра (в линуксе почти все такие). Эти драйверы всегда пишутся на С.
UMDF - это фреимворк для написания драйверов пространства пользователя. То есть не драйверов, на самом деле, а тех самых DLL-ок которые цепляются к какому-то специфическому API, которое ядро выставляет в юзерспейс. Исторически их можно было писать на C++, потому что они работали через шину COM. А потом случилась 8-ка. В 8.1+ наступил UMDFv2 и теперь надо писать как в KMDF на С.Это обёртки над WDM, которые существуют со времен Vista. Это слишком молодежно? А что надо VxD вспоминать? Или может быть писать на голом WDM? Так его уже тоже не рекомендуют для новых драйверов. Опять же, WDM это тоже С.
Меня так умиляет ваше желание обойти стороной самое главное, что было сказано в моем комментарии выше про поведении студии. Повторю еще раз громко и отчетливо:
Если в "Visual C++" проекте встречается файлы *.c, то они компилируются по стандарту языка С89 + куски С99. KMDF/UMDF и сама WDM - это С. С++ раньше было можно использовать для юзерспейса и то, это померло вместе с 7-кой.
> Об этом говорят IRP, которыми объекты обмениваются. Но про эти сообщения говорить явно рановато. ;)
> Ну да, приложение в юзерспейсе получает хендл объекта и с ним оперирует. А в ядре хендл транслируется в указатель на объект. Это называется "сокрытие реализации". ;))И какое отношение это имеет к изначальному утверждению, что ООП не используется для драйверов уровня ядра, они на С?
Вы точно понимаете эту фразу правильно? Речь идёт не об академической методологии "всё есть объект". Речь именно о полнофункциональных ООП-языках у которых есть инкапсуляция, полиморфизм, наследование и абстракция, позволяющая определить поведенческие модели для объектов и, как следствие, обязывающая компилировать программу в промежуточное представление, куда транслируется весь этот ООП-шный синтаксический сахар.
А если Вы, любезный, вдруг помыслили что "сокрытие реализации" ↔ "инкапсуляция" и наличие этого сокрытия порождает ООП, то вы ошибаетесь, ведь "инкапсуляция" ∈ "сокрытие реализации". ООП-шная концепция инкапсуляции - это один из методов сокрытия, который, среди прочего, подразумевает еще включение методов в объект-класс.
Во-первых, пальцем ткните где это внутри WDM, да так чтобы на C++ классом, а не объявление указателей на функции в поле структуры.
Во-вторых, наличие инкапсуляции является необходимым, НО НЕ ДОСТАТОЧНЫМ условием для появления объектно ориентированной модели, а то и С и Rust станут объектно-ориентированными языками.События, опять же, тоже не являются частью ООП. Они могут быть реализованы не только при помощи ООП, но и при помощи той же ECS или так как это делают в системном программировании, конечными автоматами,.. по-разному. И то что драйверы обмениваются друг с другом IRP-структурами (СТРУКТУРАМИ КАРЛ!) говорит о наличии шины данных. И что? Если я пропихну структуру с указателями на функции, контексты и прочее через пайп, то это у меня уже ООП появилось?! Ну тогда ядро Linux тоже на ООП (доказательство: наличие unix pipes, structs, function pointers)... тьфу.
> Читайте для начала Рихтера, или кого там принято рекомендовать по такому поводу. Только потом Уолтера Они.
Меня терзают смутные сомнения... А вы сами-то читали или просто "рекомендуете"? Покажите пальцем, где у того же Уолтера Они код на С++. А если рекомендовать, то может актуальную доку, а не учебник по написанию драйверов для 98/Me/2k/XP.
>> Это для Вас они пишут-ся -- сами собой. =))) А кто-то их пишет. С использованием DDK (+IFS Kit), которое стало WDK, а не этого модно-молодёжного фреймворка.
> ._.
> KMDF - это фреимворк для написания драйверов уровня ядра (в линуксе почти
> все такие). Эти драйверы всегда пишутся на С.Можно писать на плюсах. Как раз во времена KMDF и началось продвижение ограниченного подмножества С++ самой компанией Microsoft. Вы сами то примеры смотрели, или первым попавшимся ограничились? Мне NT давно не интересна, потому за Вас я это делать не хочу, но вот третья строчка из выдачи поисковика:
"Случайно наткнулся на примеры аудио-девайсов в WDK. В частности, src\audio\sb16. Вполне себе объектно-ориентированный вполне себе кернел-мод.
Вопрос: что это? Огрызки какого-то C++ framework-а от MS? Object-oriented miniport? Когда это появилось и почему про "C++, Kernel-Mode и Microsoft" все привыкли слышать "выберите любые 2"?" все привыкли слышать "выберите любые 2"?."
https://www.rsdn.org/forum/asm/3914290.all> WDM? Так его уже тоже не рекомендуют для новых драйверов. Опять
> же, WDM это тоже С.Кто-то даже на Дельфи писать умудрялся.
> Меня так умиляет ваше желание обойти стороной самое главное, что было сказано
> в моем комментарии выше про поведении студии. Повторю еще раз громко
> и отчетливо:
> Если в "Visual C++" проекте встречается файлы *.c, то они компилируются по
> стандарту языка С89 + куски С99. KMDF/UMDF и сама WDM -
> это С. С++ раньше было можно использовать для юзерспейса и то,
> это померло вместе с 7-кой.Мне не интересна Студия и её ограничения, никогда её под Windows не использовал. Вы не в курсе, каким образом раньше там драйвера собирали, и что изначально Студия их сборку вообще не поддерживала?
>> Об этом говорят IRP, которыми объекты обмениваются. Но про эти сообщения говорить явно рановато. ;)
>> Ну да, приложение в юзерспейсе получает хендл объекта и с ним оперирует. А в ядре хендл транслируется в указатель на объект. Это называется "сокрытие реализации". ;))
> И какое отношение это имеет к изначальному утверждению, что ООП не используется
> для драйверов уровня ядра, они на С?Напомню утверждение из #295 "ООП и системное программирование не встречается даже на венде."
На примере совокупности присущих ООП признаков мы видим, что парадигма там используется и положена в основу дизайна ядра, следовательно исходное утверждение -- не соответствует действительности.
> Вы точно понимаете эту фразу правильно? Речь идёт не об академической методологии
> "всё есть объект". Речь именно о полнофункциональных ООП-языках у которых есть
> инкапсуляция, полиморфизм, наследование и абстракция, позволяющая определить поведенческие
> модели для объектов и, как следствие, обязывающая компилировать программу в промежуточное
> представление, куда транслируется весь этот ООП-шный синтаксический сахар.Это сейчас Вы начали вкладывать в исходную фразу некие дополнительные смыслы, связывая ООП с языками. Но финт опять слегка мимо кассы. В ядре NT можно использовать С++, включая часть стандартной библиотеки, и даже dynamic_cast<> -- если сильно захотеть и никого не бояться https://code.google.com/archive/p/ontl/wikis/Compliance.wiki
>[оверквотинг удален]
> не только при помощи ООП, но и при помощи той же
> ECS или так как это делают в системном программировании, конечными автоматами,..
> по-разному. И то что драйверы обмениваются друг с другом IRP-структурами (СТРУКТУРАМИ
> КАРЛ!)В плюсах struct и class практически одно и тоже, разница лишь с видимости членов по умолчанию.
> говорит о наличии шины данных. И что? Если я пропихну
> структуру с указателями на функции, контексты и прочее через пайп, то
> это у меня уже ООП появилось?! Ну тогда ядро Linux тоже
> на ООП (доказательство: наличие unix pipes, structs, function pointers)... тьфу.
>> Читайте для начала Рихтера, или кого там принято рекомендовать по такому поводу. Только потом Уолтера Они.
> Меня терзают смутные сомнения... А вы сами-то читали или просто "рекомендуете"? Покажите
> пальцем, где у того же Уолтера Они код на С++. АСтр. 63 -- таблица "виртуальных функций" (ну да, слегка не такая, как привычная VTbl)
Стр. 65 "Объекты драйверов". "Считайте их аналогами приватных и защищённых членов классов С++". Это там прям так и напечатано.> если рекомендовать, то может актуальную доку, а не учебник по написанию
> драйверов для 98/Me/2k/XP.Актуальная мне не интересна, но вот одна из классических, и уже доступна без подписки:
C++ in an NT Driver
The NT Insider, Vol 14, Issue 2, March - April 2007
http://www.osronline.com/article.cfm^article=490.htm -- ссылка бьётся по ^, так что копируйте.и ещё https://web.archive.org/web/20101116020047/http://www.micros...
> 2) у него ужастный синтаксисВ чем ужас?
Он "хороший" только для хипстоты и смузихлёбов. Как таковой, это просто "ещё один" язык для неокрепших умов. Писать на этом г****вне всё равно никто не будет, один только хайп подымают.
А зоопарк из кучи языков - это разве не проблема?
Что-то я как опёнковод со стажем этому совсем не рад.
Представляешь, я тоже... Кто-бы мог подумать... Не застрелись там! )))
та да - во фрю, бывало, дрова из lo0nix'а тащили (некоторые копрорации в поднебесной ведь только для оного и пишут, и то за счастье!), а дрово-растию уже не потащить...
Чтобы писать недостающие драйвера на Rust? :)
вот прям раньше никак нельзя было писать эти недостающие дрова? Только достающие?
Это неизбежный процесс, слишком много преимушеств даёт Rust
Главное преимущество Rust заключается в том, что на нём сложно написать код с ошибками, поскольку на нём в принципе почти невозможно написать полезный код. Что мы и наблюдаем на примере Redox, Servo и подобных проектов.
но все же бывают и исключения в виде ripgrep, bat, fd. они просто еще мало настоялись
ripgrep, bat, fd я не против этих "из коробки"
ag вылизано чуше ripgrep
здесь проблема не в расте как таковом а в сложности упоминаемых проектов
первый - ОС
второй - браузерный движок
у мозилы точно нет денег чтобы потянуть это и раст тут ни при чем.
> здесь проблема не в расте как таковом а в сложности упоминаемых проектовЗдесь скорее проблема в очередном анонимно-диванном анализе вида "возьмем пару подходящих под выводы фактов и озвучим эти выводы с умным видом". Потому что о ржавом CSS движке, которые уже почти 3 года в лисе или том же WebRender или туевой куче ОС уровнем куда хуже RedOx, причем на всевозможных языках https://wiki.osdev.org/Projects - анонимы очень скромно умалчивают.
И с умным видом делают выводы уровня "ветер дует потому что деревья качаются - это же всем очевидно!".
Почему Си-Сипипям это не мешает??
>почти невозможно написать полезный кодРазве чтобы написать полезный или бесполезный код нужен специальный язык)?
для того что бы писать полезный код уже был С
поэтому придумали руст что бы писать исключительно бесполезный код
Си приктически идеялен, он совмещает в себе быстродействие ассемблера с удобством асемблера.
> для того что бы писать полезный код уже был СА до си уже был ассемблер. Тогда зачем этот бесполезный си? Ну а потом c++ появился, ещё более бесполезный, так как си уже был)
> А до си уже был ассемблер.У него был довольно неариятный недостаток, который совершенно случайно заметили разработчики колибри-ОС'а. Решили они как-то перейти с x86 на x86-64 - а тут оказывается вообще все переписывать надо. Представляете себе какое западло? И родили они с горя C--, чтоли, или как там его :). Чота разлюбив ассемблер...
(а знаете, прикольно когда драйвер какой-нибудь usb-клавы без изменений взлетает даже на вон том mips'овом роутере, если ему в usb клаву зачем-то подцепить охото)
C-- был ещё в начале 90х.
> C-- был ещё в начале 90х.Это 294й из параллельно-альтернативной вселенной. У него там все было по другому - потому и комменты примерно в том же духе.
Что за чушь?
>Предложение по обсуждению вопроса добавленияПредлагаю обсудить вопрос возможности изменения названия Линукс на Ксидабум-куку.
Отлично по-моему.Наконец-то первая операционная система, поддерживающая многоязычное расширение.
Кроме Rust неплохо бы ещё C++, GNAT, GFortran, Go и scheme
Я бы ещё dart предложил добавить. Canonical поможет.
Про Electron забыли.
Джаббу тогда уже сразу
> Джаббу тогда уже сразуGcj подзаброшен.
> Gcj подзаброшен.И даже вроде уже подвыброшен, не?
Не просто подвыброшен, а выброшен.
Так и Питончик тоже.
Почему Pascal забыли?
Выдаёт недостаточно объёмный размер бинарников.
WASM в ядре пргодлась бы кроме всяких шутоок.
Подобный проект был на гитхвбе, но автор его удалил. Модуль ядра исполняющий wasm.
Отсюда удалил? https://github.com/wasmerio/kernel-wasm
Это чтобы ядро в браузере исполнять?
> Это чтобы ядро в браузере исполнять?и это в netbsd уже было лет 10 назад, если не больше
Сравнил самолёт с велосипедом.
Чем ?
По сути своей, это тот же JS, который исполняется на базе движка JS, только супер-минифицированный( собсно, в «рекламных буклетах» так и говорят: «ускорение парсинга в сравнении с обычным JS». Про скорость выполнения обычно помалкивают, а то и умалчивают о существующих ограничениях )
Это ни разу не js. Это универсальный переносимый формат исполняемых файлов. Выполняется в виртуальной машине. Виртуальная машина решает куда дать доступ и как. Он свободный. Медленный потому что не настоялся.
> Это ни разу не js. Это универсальный переносимый формат исполняемых файлов. Выполняется
> в виртуальной машине. Виртуальная машина решает куда дать доступ и как.
> Он свободный. Медленный потому что не настоялся.Он исполняется на базе JS-движка, поскольку ключевое применение wasm - это веб и речь о том, применять ли существующие и неплохо работающие штуковины или придумывать совершенно новые, с кучами дыр, багов и это при примерно аналогичном JS функционале( хотя и с некоторыми нюансами ). Самое забавное, что это никто и не скрывает.
Да-да, виртуальная машина итп.
Всё это уже проходили в JS. В конечном счёте, условно-безопасным( и весьма тормозным ) оно было во времена чистого интерпретатора. С приходом норм скорости ввиду добавления JIT, появилась куча проблем, в т.ч едва ли разрешимых.
WASM - ни разу ни про JS. Это реально низкоуровневый байткод. Там нет "объектов, прототипов, массивов, уникодных строк, GC". Все, что там есть, это байтики и команды манипуляции байтиками. И это немного приправлено безопасностью.Ок, еще проковыряна дырка в js мир. Но она опциональна.
Многие проекты задумываются о поддержке плагинов на WASM. В основном такие, которым нужна скорость в обработке бинарных данных: сетевых протоколов, музыки, графики.
Ну я и говорю - супер-минифицированный JS с нюансами( нельзя напрямую работать с DOM-деревом итп - только через прослойку из «классического» JS + допданные для интерпретатора, которые могут помочь оптимизировать ему потребление ресурсов )Если говорить о чем-то условно-универсальном и низкоуровневом, то почему это касается чего угодно, кроме того же LLVM с его байткодом, хотя много где даже сборка ПО так или иначе его реально касается ?
Там не совсем про скорость обработки - там, скорее, про возможность изначально писать код на любом из языков, которые могут приводиться к wasm( насколько помню, это как минимум чуть ли все, которые норм приводятся к llvm ir ), а не только на пихоне.
> WASM в ядре пргодлась бы кроме всяких шутоок.Не надо. С BPF-то грабли на граблях, а уж WASM в kernel mode - это вообще только для камикадзе.
> Наконец-то первая операционная система, поддерживающая многоязычное расширение.у netbsd lua в ядре уже много-много лет
visual basic - индусы мелкомягка с радостью помогут
> Наконец-то первая операционная система, поддерживающая...тут в новость про ядро
Че мелочишься, давай сразу 1С диалект вкорячь. Интеллект программистов ядра Linux сразу деграднет на порядок.
Никто не вечен. Даже C.
Ничего не может работать дольше цикла for(;;) на C
Taimer dumaet inache
Забавно, что даже в этом коменте о Си закралось UB
Почему?
Тело цикла не указано и не указано, что оно пустое. Может там следующей командой return 0; написано.
А вот в Golang как-то циклы подобные оптимизируют и они там за долю секунды выполняются, а потом спать уходят =)
Интересно как будут ментейнить ОС на разных языках?
Мне кажется, что разработка ядра не упростится, а в разы усложнится.
ну ОС в принципе вещь непростая, многокомпонентная - главное, что бы бинарно она работала как надо
ОС - да, многоязычие оправдано. А тут ядро.
Причём тут "бинарно работала"? Сам-то понял, чё ляпнул?Речь идёт о том, что любой, кто попытается управлять разработкой ядра, сразу же получает граблями в виде "многоязычия". Ты сам-то много языков знаешь? Именно "знаешь" и понимаешь на 100%, а не как большинство лабухов - "писал однажды хелловорлд".
нет, немного; да, понял - ведь всё так или иначе сводится к машинному коду, верно? средство его создания может быть любым, главное - результат...
Почему? Языки ведь не смешиваются в одном контексте.
Одна система на одном языке предоставляет своего рода дополнение API для удобства разработки других систем на других языках.Никого же не волнует на чём именно написаны проприетарные драйвера.
Да пусть хоть на питоне ("влинковав" туда всё начиная с libc) пишут если вызовы API, требования к зависимостям, ограничениям на используемые ресурсы и т.д не нарушаются.Проблема может возникать если только это межсистемное API будет часто меняться в угоду той или иной стороне. Ну так вроде и стой и другой стороны достаточно профи, чтобы держать его более или менее стабильным.
А дальше уже как пойдёт, появится ли аппетит во время еды сразу или сначала будет количественное увеличение. Там уж видно будет
меняющийся в угоду чему-либо системный API есть моветон; и как мне кажется, Вы путаете API и ABI
>Никого же не волнует на чём именно написаны проприетарные драйвера.Людей, заботящихся о безопасности, волнует, чтобы драйвера были опенсорсными. А, следовательно, понятен ли им язык, на котором они написаны, им небезразлично.
> Людей, заботящихся о безопасности, волнует, чтобы драйвера были опенсорсными.
> Людей, заботящихся о безопасности,Вы совершили очень много ошибок во фразе "Людей, поехавших на столмановских идеях".
Ах ну да, студентов еще это волнует и прочих кому телефончики перешивать на кастомную прошивку.Я могу понять что вам там не всё равно, и религия обязывает, но не надо врать про безопасность. Сидите с Intel ME или аналогичными от AMD с кучей аппаратного DRM в компе и смартфоне, в котором,, кстати проприетарный модем, до которого вы SoC-ком не достанете, а он вам код в системе выполнит да так, что не заметите.
> А, следовательно, понятен ли им язык, на котором они написаны, им небезразлично.
Летели два крокодила, один зелёный второй налево. Как зовут бабушку дворника?
Ничерта не следовательно! Если студент аргументирует религиозное желание (небось, от преподов досталось) видеть код драйвера безопасностью, то это не значит что ему, вдруг, можно не учить язык. А то это удобненько получается "учить не хочу, код дай, и все бесплатно" и все это во имя "безопасности", о которой он и знать ничего не знает... ну кроме разве контрацепции, которая, как известно, у таких естественная.
Смартфончиками не пользуюсь принципиально. Поэтому и перепршивать нечего.И что с того, что мы вынуждены использовать процессоры с аппаратными уязвимостями? Это отнюдь не оправдывает наплевательское отношение к софту. При любой возможности количество уязвимостей нужно МИНИМИЗИРОВАТЬ.
Нет у меня в компе модема. И смартфона нет.
> Интересно как будут ментейнить ОС на разных языках?А вот так. Теперь, если мейнтейнер свалит, а никто в его коде на хз каком языке разбираться не захочет, модуль выкинут и всё.
Вообще паразительное по своей глупости решение.
Это круто, что ядро не держится за прошлое и продолжает эволюционировать
Раз пошла такая пьянка, то пусть лучше Л. Торваальдс запилит свой специализированный kernel-lang для ядра. В прошлый раз, с системой управлениями версиями, у него круто вышло. Взлетело и далеко за пределами ядра.
Тогда ему нужен еще один срок молодости с обнулением.
Ну Git он после 30-ти запилил, поэтому справится.
Готов отдать свою.
Она все равно у меня в пустую потратится
Ему и си хватает.
Ему-то хватает. Но его окружают инклюзивные. И их всё больше и больше. Отбиваться становится всё сложнее. Поэтому, если возможность, то лучше возглавить, взять инициативу в свои руки.44
И как это спасёт от запрета принятия других языков в ядро? Он и в текущей ситуации мог бы сказать "только си и ничего другого", но ведь не сказал.
Если сам придумает kernel-язык со всякими @safe и прочими шахматами, окружающие могут хайпануть на новинку. Нынешние модномолодёжные языки могут отодвинуться на второй план.
Он совсем недавно говорил что вообще больше не програмирует, переписка, консультация, короче бюрократия засосала
Это очень плохо что вместо замечательного, безопасного и удобного Си, будет дырявый, тормозной и убогий rust
Rust нужно запретить
Ну он не то, чтобы "убогий", но без ООП это г***вно не нужно вообще. И работа с объектами сложная - все эти "передачи владения". Никто этим заниматься не будет, а значит будут бесконечно наступать на грабли.
А между тем чтобы собрать сам компилятор Rust стабильной версии, нужен бинарник предыдущего компилятора, возможно даже из бета-ветки. То есть чтобы собрать Rust без скачивания бинарников от Mozilla, надо... Какая там версия? Скомпилировать 43+ компилятора для Rust предыдущих версий, и проблема только разрастается со временем.
кто тебе такую чушь сказал?
Я с ней столкнулся, когда собирал, по документации: https://rustc-dev-guide.rust-lang.org/building/how-to-build-...
> А между тем чтобы собрать сам компилятор Rust стабильной версии, нужен бинарник
> предыдущего компилятора, возможно даже из бета-ветки. То есть чтобы собрать Rust
> без скачивания бинарников от Mozilla, надо... Какая там версия? Скомпилировать 43+
> компилятора для Rust предыдущих версий, и проблема только разрастается со временем.Ну так gcc тоже собирается с помощью gcc.
Да, там эта проблема тоже есть, но не в таких масштабах, не 5-8 компиляторов в цепочке максимум для сборки последнего GCC
gcc можно собрать используя clang.
Сколько сторонних компиляторов есть для Rust?
Эта проблема есть у любого языка, компилятор которого пишется на нем самом. Даже у typescript она есть, а уж с Rust-то компилятор на C выглядел бы совсем глупо :-)
Зацени на досуге от куда берется компилятор gcc в LFS.
С хостовой системы. Но он там собирается 3 раза, вроде:
- host-gcc собирает target-gcc из сорцов
- target-gcc, собранный при помощи host-gcc, собирает target-gcc
- target-gcc, собранный при помощи target-gcc, собирает target-gcc
да, в LFS оно берется из хост-системы. А вот Guix, например, работает над уменьшением количества доверенных бинарников до минимума, и там новые версии gcc собираются старыми, а одна из старых компилируется tcc (tiny c compiler), а tcc компилируется их самописным компилятором на лиспе, а в начале этой цепочки GNU Mes (маленький лисп и компилятор си, вроде даже на том же лиспе). Ну и в целом как-то оно неправильно, что каждый новый компилятор у Rust написан на новом языке, для которого нужен новый компилятор. Над минимализацией количества доверенных бинарников надо работать, а то закроется static.rust-lang.org, и как вы будете без бинарников собирать Rust? Да так и будете, версия за версией, начиная с той версии, которая не на Rust. у Gcc легче, там следующая версия зависит не от предыдущей, а от какой-нибудь пред-пред-предыдущей, то есть не пытаются сразу пихать в компилятор свистелки и тут же на них писать следующий компилятор, как это делается с Rust. Безусловно, это тоже проблема и ее тоже как-то нужно решать, потому что в перспективе это оборачивается слишком большим количеством source-зависимостей
чтобы собрать компилятор rust нужен компилятор! Это фатальный недостаток языка!
> Скомпилировать 43+ компилятора для Rust предыдущих версийНет, не 43. Я не скажу в точности сколько, последний раз я наблюдал активность по бутстрапу rust'а в блоге guix[1]. Там фишка в том, что на C++ написан mrust, который неполноценный раст, он исходит из того, что ему подсовывают корректный код, и на этом экономит кучу сложности. И этот mrust может сходу скомпилировать rust-1.19, то есть уже 43-19. Если пройтись по ссылке на github mrust'а[2], то там написано, что он аж rust-1.29 может собрать сейчас. То есть 43-29 версий придётся пересобирать.
Но при этом сейчас ведь появились эдишны. Я не помню, как там разработчики rust'а сами отреагировали на своё нововведение: придерживаются ли они rust2018, когда пилят rustc, или продолжают налево и направо фишки из беты использовать.
[1] https://guix.gnu.org/blog/2018/bootstrapping-rust/
[2] https://github.com/thepowersgang/mrustc
Фанатизм. С++ в ядре им не нравится, хотя в виндовом ядре он неплохо себя чувствует в некоторых подсистемах, а инородный Rust, который не поддерживает и половины аппаратных платформ Linux, им непременно там зачем-то нужен.
А в этом, "С++ в виндовом ядре" - есть RAII? а исключения есть?
> А в этом, "С++ в виндовом ядре" - есть RAII?RAII не требует поддержки времени выполнения, так что не понятно, о чём вопрос. Есть. Микрософт в своём коде (примерах) раньше не использовали.
> а исключения есть?
Если понимать, что такое arbitrary thread context и IRQL, то местами возможно использовать.
Конечно есть RAII. И есть шаблоны. Нет исключений и фишек, обечпечиваемых рантаймом.
Точнее даже исключения ограниченно присутствуют, как заметили выше.
Я вам больше скажу, что этот аноним, что n00by врут и не краснеют.
Он в другой части треда мне пафосно воображает про С++ и драйверы. Начиная с Windows 8.1 старый API UMDFv1, который позволял писать драйверы пространства пользователя меняют на UMDFv2, где опять только С и нету С++ COM API.Вот код WRK. Ядро, которое RING 0 там на С.
https://github.com/Zer0Mem0ry/ntoskrnl
Это WRK, но недавно утекали полные сорцы десятки. Если интересуют прямо полные исходники сами их ищите, они есть.А вот примеры драйверов
https://github.com/microsoft/Windows-driver-samplesТе которые цепляются напрямую ядру без юзерспейсных прослоек тоже все на С и обязаны быть на С.
Ядро NT не настолько монолитное, как Linux. Там есть куча подсистем, которые, строго говоря, не часть ядра, но ядро с ними взаимодействует. Всё ядро написано на С. Все что сидит в юзерспейсе преимущественно на С++, но оно, блин, в юзерспейсе. Это не драйверы а одно названием. Им выдано API и дальше него они не могут выскочить. Это кстати касается всех юзерспейсных драйверов в том числе тех подсистем, которые MS-ом написаны.
Си плюс-плюс вреден в ситемщине. Пусть Майкрософт пилит своё ядро на чём ему вздумается. На божественные Юниксы Си плюс-плюс не пускать!
Ну таки здесь, вроде как, Linux не принято считать UNIX-ом?
В ядре макоси C++ давно есть, а это самый натуралный юникс. Так что мимо.
В XNU подмножество C++ (Embedded C++) и специальные компиляторы с оптимизациями именно под ембедовку. Если изначально так ядро проектировать - это одно, а прикрутить нечто подобное к Linux kernel - задача если и решаемая, то трудозатраты будут огромными.
> В XNU подмножество C++ (Embedded C++) и специальные компиляторы с оптимизациями именно
> под ембедовку.Только чего-то именно в эмбедовке этой XNU и нету как раз.
А apple watch - это не ембедовка что ли?
Осей для микроконтроллеров на с++ написано много уже давно. Работают.
Ага, специальный clang с секретными оптимизациями, а до этого был особый аненербе-гцц.>Если изначально так ядро проектировать
Изначально это антикварный MACH на С, тот же самый что и в хурде, к которому прикрутили подсистему для драйверов на плюсах.
> Фанатизм. С++ в ядре им не нравится, хотя в виндовом ядре он
> неплохо себя чувствует в некоторых подсистемах, а инородный Rust, который не
> поддерживает и половины аппаратных платформ Linux, им непременно там зачем-то нужен.Всё таки сравнение не совсем корректно. Там ядро закрытое, потому драйвера пишут кто во что горазд. Здесь код открыт, и когда всё исполнено в одном духе и стиле -- воспринимать проще.
Ну так пусть пишут дайверы там где llvm работает.
Rust использует LLVM как бэкэнд, а LLVM поддерживает все основные платформы, на которых актуально текущее ядро Linux.
наверно не хватает ещё одной надписи, ато без неё будет разрыв в построении логической цепочки:"Rust поддерживает все те же платформы которые поддерживает его бэкэнд" (я этого НЕ знаю -- просто написал что этой фразы не хватет)
>я этого НЕ знаю -- просто написал что этой фразы не хватетНе волнуйтесь, здесь ни вы ничего не знаете, ни добрых три четверти остальных комментаторов. И ничего, нормально живут.
Во многой мудрости много печали; и кто умножает познания, умножает скорбь
C++ без libstdc++ штука не особенно осмысленная, а какая может быть стандартная библиотека в ядре?Ну, да, классы - но и всё. "Си с классами" можно писать и на С, со структурами и указателями на функции - примерно то же самое получится (см. модули nginx как пример).
А Rust именно как язык, безо всяких библиотек, дает преимущества.
Стандартная библиотека в ядре - не большая проблема: есть стандартные библиотеки C++ для микроконтроллеров.
В ядре, которое изначально пишется с использованием этой библиотеки - конечно, не проблема.
А в линуксе... ну только если свою хедерную обертку вокруг уже имеющейся инфраструктуры написать
Пока фронтенд для Rust не добавят в GCC, рано говорить об его применении в разработке ядра.
Такой проект уже есть для gcc. Мимо.
Да слышал. Вот только вяло он шевелится, даже попыток принятия-включения не видно.
Думаю тянуть гигантский статический анализатор в gcc никто не будет. Если только анализатор не будет выделен в отдельный компонент, такая работа уже идёт вроде.
в здравом уме конечно никто не будет ... но не у всех ум здравый.
У gcc ворох архитектурных проблем с монолитностью, накопившихся за долгое время жизни проекта. Их понемногу решают, но это долгий путь.
Меня заставят учить раст чтобы собирать модули? Мои глаза не выдержат такого синтаксиса.
_Собрать_ модуль можно не зная ни Раста, ни Си, ни даже Бейсика, в чем проблема?
В том, что он соберется не так, как мне нужно.
Это ещё и плюсуют лол
Что не так с синтаксисом?
После C как глоток свежего воздуха на берегу океана, проще и понятнее, нет остатков многовековой совместимости
иди и пиши свою ось, захер лезть в чужую и ломать её?
> иди и пиши свою ось, захер лезть в чужую и ломать её?Месье Торвальдс собственной персоной? Или очередной аноним, ничихуахуа ядерного вообще не написавший, зато в крутой маечке с пингвинчиком?
И никакой конкретики
Посмотрим что получится, а дальше будет видно. Может пора уже на GNU/HURD валить...
Для начала его нужно допиливать/перепиливать, а потом валить.
с растом почему-то не так
Осталось изменить логотип Линукса на радугу, для полного счастья.
Не, пингвина заменять не нужно. Вот только чёрный пингвин это неполиткорректно. Радужный пингвин - самое то!
>Вот только чёрный пингвин это неполиткорректноНет, это ты расист.
Черный - это не цвет, это его отсутствие... Тоже применимо и к нашей бытовухе и то фигне, что сейчас творится в мире...
не путайте цвет и свет.
Если ты проссал всю физику в школе, то объясню: это ОДНО И ТО ЖЕ.
Стоп а разве rust не компилируемый язык ?
(еще раз перечитал заголовок ... ничего не понятно)
> Стоп а разве rust не компилируемый язык ?
> (еще раз перечитал заголовок ... ничего не понятно)Компилируемость тут ни при чём, имеет смысл говорить, "генерящие elf-объекты". (Интерпретируемые языки тоже могут генерить elf.)
Но (а) нужно согласовывать линковочные символы. Для этого кое-какая работа нужна.
И (б) вопрос ещё не только в том, чтобы писать объектники, а ещё в том, чтобы код на русте стали принимать в ядро.
Ну да давайте весь мусор в ядро тащить...
Да, палец у Линуса уже не тот...
Мусор не надо, но действительно крутые вещи вроде Раста - стоит
Мальчики, почему все постоянно забывают, что у руста есть проблема с лицензией? Все произведения на русте автоматически принадлежат компании мозилла. Почему все игнорируют лицензионное соглашение, по которому распространяется rust? Лицензия руста несовместима с gpl v2.Кроме того, есть проблема: рустовые фанбои с пеной у рта и в конвульсиях в истерике кричат, что обязательно на русте надо писать safe-код. Но в случае ядра и его модулей это технически невозможно.
И почему если поехавшим от руста срать в ядро можно, то любителям lisp, haskell и прочим это запрещено? Нужны биндинги для всех языков, а не только для тех, чьи представители отличаются диагнозом шизофрения или склонность к психозам и истерикам от обычных людей?
Прими таблетки
Иногда бывает так: читаешь комментарий и не понимаешь - то ли автор шутит, то ли со стационара сбежал.
> Мальчики, почему все постоянно забывают, что у руста есть проблема с лицензией? Все произведения на русте автоматически принадлежат компании мозилла.https://github.com/rust-lang/rust/blob/master/COPYRIGHT
Я извиняюсь, а о какой лицензии идет речь?
> Кроме того, есть проблема: рустовые фанбои с пеной у рта и в конвульсиях в истерике кричат, что обязательно на русте надо писать safe-код. Но в случае ядра и его модулей это технически невозможно.
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
"Using unsafe to take one of the five actions (superpowers) just discussed isn’t wrong or even frowned upon. But it is trickier to get unsafe code correct because the compiler can’t help uphold memory safety. When you have a reason to use unsafe code, you can do so, and having the explicit unsafe annotation makes it easier to track down the source of problems when they occur."
Примерный перевод:
"Использование unsafe обсужденного ранее не является неправильным и не считается плохим."> И почему если поехавшим от руста срать в ядро можно, то любителям lisp, haskell и прочим это запрещено? Нужны биндинги для всех языков, а не только для тех, чьи представители отличаются диагнозом шизофрения или склонность к психозам и истерикам от обычных людей?
Потому что создатель ядра и коммьюнити которое разрабатывает ядро видит смысл в добавлении поддержки rust и кто-то занимается имплементацией этой самой поддержки?
> И почему если поехавшим от руста срать в ядро можно, то любителям
> lisp, haskell и прочим это запрещено?Потому что культура. Впрочем, с ними айда к нам, будете в хорошей компании. :)
http://altlinux.org/alterator
http://altlinux.org/Haskell_Porting_Initiative
Пускай занимается в гугл и дальше
Зачем пихать и занимать место всяким ненужным компиляторам на ПК домохозяйки...
1. Небезопасный Раст - это чистый Си с проверками на безопастность. Никто, чистый Си без дополнительных инструментов не использует.2. Я против, не потому-что Раст сложен. А потому-что, на какой-то стадии появится опасная возможность использования 2 компиляторов для компиляции ядра Линукса.
3. Для компиляции ядра Линукса не используются сишные библиотеки. А если Растаманы в каких-то компонентах пожелают использовать рантайм-библиотеки?
4. Пусть Растаманы пилят свой Redox и пусть Раст не выходит за пределы экосистем Redox и Servo.
А то, что без perl ядро не соберется вас не пугает? Уже привыкли?
а разве предлагают убрать perl (в случае появления rust)?(или ты один из тех кто думает что указав на какую-то проблему ты замаскируешь текуще обсуждаемую проблему? как это любят вещать в зомпоящиках в авторитарных странах)
> а разве предлагают убрать perl (в случае появления rust)?
> (или ты один из тех кто думает что указав на какую-то проблему
> ты замаскируешь текуще обсуждаемую проблему? как это любят вещать в зомпоящиках в авторитарных странах)То ли дело обозвать набор дикой чуши (см. хотя бы первый пункт с "небезопасностью" и третий пункс с бурной фантазией "если бабушка была бы дедушкой") "обсуждаемой проблемой"?
> третий пункс с бурной фантазией "если бабушка была бы дедушкой"а как иначе?
не ясно же что им в голову придёт теперь :-) ..
им Rust разрешат и они на этой эфории понесут новые идеи
> ... и они на этой эфории понесут новые идеи ...а потом как обычно говорят такие люди -- "ой! что-то мне Open Source надаел. теперь семья/дети/работа_грузчиком -- поддерживайте сами теперь это" (после внедрения эпических костылей, реализовывающих все их сокровенные влажные фантазии!)
о каких костылях речь?
всё верно. каждый пункт по делу
> 1. Небезопасный Раст - это чистый Си с проверками на безопастность. Никто, чистый Си без дополнительных инструментов не использует.Небезопасный раст если и безпаснее Си, то только потому, что там нет UB. А безопасный раст -- это не просто статический анализатор накручен сверху C, это когда задумка программиста описывается типами и алгоритмами. То есть в типах кодируются многие ограничения на то, что можно делать, а что нет. В случае C такие ограничения могут существовать только пока программист на C о них помнит.
> 2. Я против, не потому-что Раст сложен. А потому-что, на какой-то стадии появится опасная возможность использования 2 компиляторов для компиляции ядра Линукса.
Чем же она опасна, эта возможность? Может ты хотел сказать "неприятность, в виде необходимости использования двух компиляторов", а слово "опасность" просто ассоциацией к C выскочило?
> 3. Для компиляции ядра Линукса не используются сишные библиотеки. А если Растаманы в каких-то компонентах пожелают использовать рантайм-библиотеки?
Что значит "не используются"? В ядре куча всяких разных библиотек. И написаны они на C.
> 4. Пусть Растаманы пилят свой Redox и пусть Раст не выходит за пределы экосистем Redox и Servo.
Мечтай дальше. Твои хотелки нас не остановят.
2. а про сборку ядра clangом уже забыли)?
3. в расте есть no_std. и пожелать использовать рантайм они не смогут при всём желании так как просто не скомпилируется
4. действительно, зачем этот раст вообще в продакшен пускать
>нужно ли вообще добавлять такую поддержкуНи в коем случае. Rust-программисты - это те же вебмакаки. Cargo - это тот же npm, только для rust. Даже простая сборка hello-world ядерного модуля тянет ворох зависимостей из crates. При этом для crates нет цифровых подписей, а система сборки при сборке может исполнять произвольный код, скачанный с crates в виде пакета. Большинство раст-пакетов требуют ночную версию раст, которой нет в дистрибутивах и которую предлагается ставить с помощью curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh .
Добавление этого в ядро, а также подключение и включение вебмакак и их любимых подходов в разработку ядра, приведёт к тотальной и необратимой компрометации критической инфраструктуры.
скачивание какого-то говна из интернетов для очередной компиляции ядра (при этом у каждого интернет разный -- и прилететь может разное) -- совсем не радует.поидее бы -- нужно запретить использование Cargo -- для целей компиляции ядра.
но с другой стороны Растоманы зачастую считают что cargo это неотъемлимая часть Rust.. и всячески активно его используют (создавая огромные каскады зависимостей, также как js-программиты со своими сраным npm).
это наверно как говорить "вот тебе пиши на C++ , но объектами пользоваться запрещаю!"
> Большинство раст-пакетов требуют
> ночную версию раст, которой нет в дистрибутивах и которую предлагается ставить
> с помощью curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh .
% pkg search nightl
rust-nightly-1.46.0.20200630 Language with a focus on memory safety and concurrency
Че там у вас в WSL-like нет, никому особо не интересно.
А C-программисты живут словно и 80ых, и поэтому не вебмакаки, да?
И вообще, использование современных средств - плохо!
Нужно, как и раньше, все расчеты проводить на калькуляторе! Нет, счетах, калькуляторы слишком современны.Как раз один из основных минусов C/C++ - отсутствие дефолт пакетного менеджера, который есть во всех современных актуальных языках. Это не в контексте ядра, разумеется, но факт остаётся фактом.
Дефолтный пакетный менеджер для Си/Си++ - это пакетный менеджер дистрибутива. Испокон веков всех всё устраивало, пока не народилось поколение воинствующих обезьянок.
Как раз таки никого и не устраивало, перенести приложение, а тем более проект тот ещё гемморой из НИЧЕГО.А как это сейчас. Пересобирать приложение для каждого дистрибутива, ну ок, бл*ть ещё и зависимости в другом месте лежат, ну ок, в evn наверное пути есть..нихера и началось. Тратишь время на решение никому ненужной проблемы. Пакетные менеджеры языков решают все эти проблемы.
Не нужно. Портанутые alienом пакеты прекрасно работают на чужом дистре и на его либах. Для сборки есть pkg-config и CMake - дистрибутив-нейтральные и даже платформо-нейтральные способы поиска зависимостей в системе. Используй их и о геморрое можешь забыть. Не используй их, и огреби геморроя. Пакеты должны собираться авторами дистра. Они хоть какой-никакой аудит делают, в отличие от говна, качаемого из conan/pip/cargo/npm, которое не смотрит никто и никогда, потому что никому не надо:
1. Разраб пакета? Он либо себе доверяет, что он не вставлял бэкдор, либо вставляет бэкдор, и тогда ему не надо, чтобы его нашли.
2. Контрибьютор? Да он из гита для себя соберет, пакеты из репозиториев пересобирать ему не уперлось.
3. Пользователь либы? Так даже если там и есть бэкдор, и если он его найдёт, ему придётся тогда фиксить сам пакет, и зависящие от него. Если он его найдёт. А искать бэкдоры - это сложнее, чем искать уязвимости. А для поиска уязвимостей есть специализированная компания - Zerodium, которая платит рыночную цену (выше рыночной платить не имеет смысла, ниже - тоже). Соответственно, бесплатно искать бэкдоры тоже не имеет смысла. Поэтому: херак, херак - и в продакшн. Поимеют клиентов бэкдором - ну значит force majeure, c'est la vie, вебмакака не виновата, это всё злой бэкдорер, агу-агу. Разумеется, реально серьёзные конторы так не работают.
>Исследователи из Китайского университета в Гонконге развивают проект дляобеспечения мирового доминирования Китайской Народной Республики
зачем на RUST? Давайте сразу на Python+java...
Если уж переплавлять ядро в ведро то сразу и основательно!
причём надо не просто Java -- а также написать Генератор который исходники на C превратит в Java.то есть так чтобы при этом код (Java) оказался бы похож на говно, как оно и бывает после выхода всех этих Генераторов.. (а не только жрал бы дофига памяти).
Эм. Как можно сравнить язык по производительности на уровне C/C++ с Джавой и тем более тормознейшим Питоном?
Что у вас вообще в головах, откуда такая чушь льется?
ты застрял где-то в вин95
а чё, в твоей персональной вселенной уже поди писюн без GIL да java без сборщика мусора, да? ;)прими таблетки и удались, стильный-модный-молодёжный.
> Возможность разработки драйверов на языке Rust позволила бы с минимальными усилиями создавать...Сразу видно, писал человек написавший ровно 0 реальных проектов на Rust (я писал если что, хоть и for fun)
> безопасные и более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера
лол! буквально в этом году был баг пофикшен (уж не помню во фронтенде или в llvm), из-за которого borrow checker не работал как положено. т.е. никто за ним не проверял (зачем?)) а тот не работал xD
После некоторого порога входа, какие такие особые усилия необходимо прилагать?
Пишешь и наслаждаешьсяА по поводу бага - суть в том, что в UB/UB++ это задокументированное стандартное поведение, а для Раста - лютый баг :)
> После некоторого порога входа, какие такие особые усилия необходимо прилагать?это на borrow cheker и владение намек? так то - миф, его какие-то обезьяны-теоретики форсят. программисту, который понимает как работает память (т.е. писал профессионально на C/C++/Go) нет проблем разобраться.
усилия на настоящем проекте надо прилагать огромные. именно поэтому в авангарде реального софта на Rust 7% Firefox и консольные утилиты 70-х годов> Пишешь и наслаждаешься
для этого нужен простой, незамусоренный синтаксис, богатая стандартная библиотека (чтобы проект не вставал колом каждый раз, когда какая-то истеричка удаляет свой crate + чтобы не вникать в чужой код для его починки, в стандартной библиотеке код точно хорош, а вот в crate может быть только на словах)
> А по поводу бага - суть в том, что в UB/UB++ это
> задокументированное стандартное поведение, а для Раста - лютый баг :)если бы вы писали на Си, то пользовались бы несколькими тулами для отлова граблей. в Rust она такая одна, и она не работала.
две большие разницы - стрелять себе в ногу, хотя тебя предупреждали, и стрелять себе в ногу, хотя тебя уверяли, что это вообще невозможно
>для этого нужен простой, незамусоренный синтаксис, богатая стандартная библиотекаИ этого всего в Си нет, лол!
>если бы вы писали на Си, то пользовались бы несколькими тулами для отлова граблей
Вот с этого места пожалуйста подробнее.
>>для этого нужен простой, незамусоренный синтаксис, богатая стандартная библиотека
> И этого всего в Си нет, лол!
>>если бы вы писали на Си, то пользовались бы несколькими тулами для отлова граблей
> Вот с этого места пожалуйста подробнее.анализатор clang, cppcheck, asan/ubsan ну и конечно "-Wall -Wextra -Wpedantic -Wshadow -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wconversion" для компилера - это современный стандартный набор
>буквально в этом году был баг пофикшен (уж не помню во фронтенде или в llvm), из-за которого borrow checker не работал как положеноА можно поподробнее? Друг интересуется
Всмысле не работал?:) Хрень пишете да?:)Он действительно некоторые ситуации допускал, а некоторые более простые ситуации запрещял. (при этом я не говорю что он не работал, он просто некоторые вещи допускал..)
Его просто улучшили...
Я против Rust в ядре, так как считаю что код в ядре не должен использовать каких-то встроенных в язык рантайм библиотек. Им не место в ядре. Если хотят писать модули для ядра - наверное это и сейчас можно, а в ядро пусть не лезут.
> считаю что код в ядре не должен использовать каких-то встроенных в язык рантайм библиотек.Ок, в этом есть определённый смысл.
> Я против Rust в ядре
Но при чём здесь раст?
> Я против Rust в ядре, так как считаю что код в ядре не должен использовать каких-то встроенных в язык рантайм библиотек. Им не место в ядре.Очень, очень квалифицированное мнение! Держите нас и далее в курсе ваших расчетов!
https://prev.rust-lang.org/en-US/faq.html
=
Does Rust have a runtime?Not in the typical sense used by languages such as Java, but parts of the Rust standard library can be considered a “runtime”, providing a heap, backtraces, unwinding, and stack guards. There is a small amount of initialization code that runs before the user’s main function. The Rust standard library additionally links to the C standard library, which does similar runtime initialization. Rust code can be compiled without the standard library, in which case the runtime is roughly equivalent to C’s.
=
> не должен использовать каких-то встроенных в язык рантайм библиотекА про no_std не слышали?
> Я против Rust в ядре...Опа, а ребята из новости об этом не в курсе!
Сначала добавят в ядро раст, через год С++, потом джаву, потом питон, и как вишенку на торте добавят джаваскрипт. Вот до чего это доведёт.
C++ ладно, это хороший языке, но каким тут боком языки без zero cost abstraction?
Так гугл джаваскрипт итак пытается воткнуть во всё, куда дотянется...
Чессгря есть мысль что впилить duktape в ядро будет легче, чем хруст. И дешевле - собирается всё тем же GCC.
Но зачем? :)
Раст - небезопасный, сложный ни одной проблемы с++ он не решил. Тогда какой в нем смысл?
На порядок безопаснее UB/UB++
И многие проблемы C++ решил
Складывается ощущение, что вы вообще о расте на заборе что-то краем глаза читали
> И многие проблемы C++ решилТут, между прочим, очередь из решателей всех проблем C++.
Вставайте, но передайте, чтобы больше не занимали.
То-то я смотрю везде где он есть он используется только с модулями unsafe.
Что-то подозрительно много шумихи вокруг этого чуда.Покажите компактный POC, можно было бы посмотреть.
А так: давайте всем миром вложимся в немаленькую архитектуру, а когда окажется что она ну очень немаленькая, накладывает тучу ограничений, контролируется толстым игроком и завязана на его инфраструктуру, будет аргумент "нельзя же, чтобы такие усилия пропали, надо принимать". А там демократические выборы, ущемлённые права или "имеют значение" подтянут.
Кёрниган с Ричи должны встать на колени и покаятся за сорок лет угнетения альтернативных языков в ядре.
секта разрастается, пока ещё не поют на площадят, но уже скоро, ещё будут ходить по квартирам.
Свидетели ржавчины?P.S. Как представил таких в костюмах ржавых грибов, так сразу захотелось взять и уе... ну вы поняли... :-)
Visual Studio в ядро добавьте пожалкуйста или хотя бы Visual Studio Code, IDEA и Qt Designer. А то я такой безрукий и без этих полезных вещей в ядре не могу apt install написать.
При чем тут добавление поддержки хорошего языка?
Я хочу писать на Golang. Добавьте плиз в ядро Linux средств для разработки на языке Golang!
У него ж сборщик мусора
> У него ж сборщик мусораи? да, кое-где STW даже длинной <=0,1мс - непозволительная роскошь, но кое-где норм. я уже молчу о том, что выключать сборщик и запускать его вручную или вообще юзать malloc/free в Go можно и это поддерживается
Что "и"? Ты реально не понимаешь? Если не понимаешь - в ядро не смей соваться!
> Что "и"? Ты реально не понимаешь? Если не понимаешь - в ядро
> не смей соваться!ну раз аноним запретил, то не буду xD
(на Go если что уже есть драйвера, хоть и не для Linux, чудик)
И на javascript тоже драйвера писали и что?:))) Оно надо в ядре?:) (не суйте go...)И задержки не 0.1, а такие приличные в 1с при этом все приложение будет ожидать лишь очистки..
> И на javascript тоже драйвера писали и что?:))) Оно надо в ядре?:) (не суйте go...)это for fun, а драйвера на Go есть в промышленной (хоть и неготовой пока) Фуксии
> И задержки не 0.1, а такие приличные в 1с при этом все приложение будет ожидать лишь очистки..
лоооооооооооол! ох уж эти мамкины эксперты! в общем случае задержка STW в Go меньше 0,1 мс (это как секунда, только нет, надеюсь, хоть это ты осилишь понять, друг анон?). статей с исследованием задержек полно (только ищи про новые версии). так вот, куча железа работает со значительно большей задержкой, поэтому никакой боли от GC не будет.
Большая ошибка.
Одно ядро - один язык, и чем проще язык - тем понятнее он остальным.
Поэтому таже плюсы - это уже плохо.
А раст - вообще катастрофа.
Да ладно вам. Ну будет полтора модуля на этом извращении, кому убудет-то. Главное, чтобы интерфейс был минималистичным и сильно глубоко в плане правок не лез.
Смысл в том, что теперь для правок ошибок нужно будет знать два языка.
Для сборки системы нужны будут два компилятора.
Зачем? Просто снимаются опции ядра для этого хлама в базовой поставке, и всё.
Кому надо - пересобирают со своим хрустом сами.
Затем что долбоящеров с хрустом будет всё больше и больше, в конечном итоге он начнёт требоватся не только для сборки драйверов от маргиналов с их малонужным барахлом но и для того что реально массово используется.
Если так случится, значит оно действительно полезное, и заслуживает места быть.
Но я скорее предполагаю путь staging -> small team support -> no support -> obsolete -> extinct.
С каких пор дополнительный слой илитности опеннетчикам стал мешать? Сложность это хорошо же, вебмакаки не пройдут.
Судя по обилию комментариев, сектанты раста перешли из любительской лиги троллинга в профессиональную. Коллеги, делайте обратную хуцпу, смело вносите абсурдные предложения по улучшению раста на обсуждение.
Тут скорее только неадекватные сектанты сишечки
rust-sources грядет. Это чтобы ядрышко собрать надо будет не gcc, а clang, llvm, rust и это полдня целых минимум.Calculate Linux по-моему обретает особый смысл и очарование.
Да ладно вам - ну хотят трахаться, пусть трахаются - если растоводы возьмутся это в ядре поддерживать, why not? Но они вряд ли возьмутся, там не тот уровень.
Я полагаю, здесь многоходовка с целью подмять под себя ядро.
Сейчас растоборцев задействовали.
(имеется в виду, что по умолчанию это "N", желающие - велком "Y", и тогда уже в пререквизитах весь тулкит по правилам)
Сколько ж дней оно с ним собираться будет? С временем компиляции у Раста всё плохо.
Будто у C/C++ лучше
У C лучше. У C++, мне кажется, тоже лучше, хотя не писал на нём очень давно, а на чужом коде сложно оценивать тормознутость компилятора.
Не зря этот хрен себе 32 ядра взял.(
Нет, дегродов до написания драйверов нельзя допускать, у нас уже прикладного софта с гомнокодом хватает глючного и блоатварного.И это, у нас уже есть целый дистр собраный на шланге, глючный шо пц.
> дегродов до написания драйверов нельзя допускатьА при чем тут Раст?
>> дегродов до написания драйверов нельзя допускать
> А при чем тут Раст?А при том, что главное позиционирование его и причина внедрения это почва для расцвета дегродов, профи системные инженеры и на Сях нормально прогают, потому что основательно знают с чем имеют дело, и как только дозволительно становится набирать всяких олухов, которые могут себе позволить "не делать ошибок", потому что система им не даёт "прострелить ногу", то сразу же начинается ещё большее деграданство.
По подобной же причине всякие скриптомакаки гомнокодят, потому что не надо можг напрягать.
А в итоге мы получаем приложения на электроне, JS везде и всюду, даже в DE, и лютый жор ресурсов, а глюков не то что бы убавилось, их ещё в полку прибыло.
Современных программистов вообще надо сажать за машины с 1 Гб ОЗУ и процом бюджетнопомоешным, чтобы за лимиты не вылазили.А по минусам к этому коменту мы узнаем сколько в тему забежало скриптомакак со своим суперважным протестом про инновации, развитие, на сях нельзя писать, чтобы не было решета, и прочее ко-ко-ко
> потому что не надо можг напрягать.Вообще у Rust порог вхождения намного выше, чем у Си. Он накладывает на тебя кучу ограничений, компенсируя экспрессивной системой типов и некоторыми другими zero-overhead feature-сами.
Да-да, надо всё на ассемблере писать.
Читаю эти хейт-спичи (сейчас это так называется?) по поводу раста и вспоминаю бессмертное https://ru.wikipedia.org/wiki/Настоящие_программисты_не_используют_Паскаль
Но там хоть в шутку это всё было.
в принципе уместное сранение, но даже паскаль не был настолько ущербным как руст, а ада тем более. руст - это просто набор хаков для ллвм который выдаётся за "безопасность".
C/C++ от ущербности Раста менее ущербными быть не перестанут.
руст от ущербности с++ менее ущербным тоже не станет. ну можешь на аде пописать если хочешь, тебе же никто не запрещает. там всё "очень безопасно" (на самом деле нет) и "проверено временем" (проверка провалилась), генерирует нативный код - вообще огонь. всё как ты хочешь, тебе совсем не обязательно изобретать очередной велосипед, его изобрели 40 лет назад, просто тебе забыли сказать об этом.
Просто пишущие на C/C++ боятся, что их знания потеряют цену, только и всего
Этого не случится, конечно, даже если сейчас всем внезапно придется перейти на Раст, но некоторые слишком консервативны для принятия нового
К счастью, "всем внезапно придётся" невозможно - адекватных слишком много :)
Все же резко перешли на кок. Хотя не я помню, чтобы код не принимали лишь потому, что человек *** или ***
На биг блэк кок.
Вот именно. Столько лет жили в своём уютном мирке, а тут внезапно появился годный язык общего назначения. НИБАМБИТ
Мне то же самое говорили и про го.
Где появился? Ссылку, срочно!
где-то в мурзилке
> занимающийся в Google обеспечением поддержки сборкиЧто, никому не смешно? Какой-то х. с гор.. то есть из гуглеля! что-то там сказал.
Rust пока себя особо не проявил, хотя языку уже много годков. Он уродлив и нечитабелен. Возможно, через определенной время он прекратит своё существование, дав жизнь, после переосмысления чему-то более юзабельному и красивому. Так зачем похабить ядро Linux? Я вообще считаю, что не C небезопасный, а что слишком много идиотов на нем программируют, не понимающих все плюсы и минусы языка.
Но ведь полезно же иметь язык, предотвращающий как можно больше ошибок?
в ядре?
и как хруст может предотвратить ошибки работы с железом?
Вы историю с языками т.н. 4-го поколения (4th generation languages) не знаете?
Прочитав комментарии тут, я задался простым вопросом: "Вы вообще программируете?".
"Эта нинада" "руст нинужан" - такое ощущение, что отряды Путинa клоунский колпак не снимали и отправились на opennet. Любой ЯП достоин проявления себя и раст не исключение, только время и практика покажет его практичность.
И да, если вы так много кодите на плюсах и Си, хоть оставляйте свои шедевры (собственноручно написанные) с проектами, мы заценим, как вы эффективно используете С/С++.
Если Rust сможет избавить мир от вечного бетатеста программ написанных индусами на Си - ++, то я за.
> занимающийся в GoogleНе, не, не, ни кому не в обиду, но когда крупные компании занимаются подобными вопросами, это тушите свет.
> поддержку GCC атрибутов inline, cold, alias, used и sectionА ничего, что inline появился аж в C99?
Каждый раз, когда читаю комментарии под новой статьей о Rust на opennet, в голове невольно вертится пословица "Собака лает, а караван идёт".Может уже бы сели спокойно на выходных, да изучили бы язык, помедитировали над его концепциями? Нет, конечно, это всегда морально проще с пеной у налитыми кровью глазами грудью защищать статус-кво, но чтобы двигаться вперед, увы, всегда нужно выходить из зоны комфорта и пересматривать традиции.
> Может уже бы сели спокойно на выходных, да изучили бы язык, помедитировалиДа я бы и поизучал, но вот после каждого столкновения с его синтаксисом ощущения, что я лучше китайский подучу.
Собрал хеллоуворд, оказалось 5мб весит, ну его нафиг. Те, кто такое сделал, хорошему не научат.
> Собрал хеллоуворд, оказалось 5мб весит, ну его нафиг. Те, кто такое сделал, хорошему не научат.
cat hello.rs && rustc -O hello.rs && wc -c ./hello
fn main() {
println!("Hello World!");
}
306552 ./hello% rustc -O hello.rs -C link-args=-s && wc -c ./hello
232208 ./hello% rustc -O hello.rs -C prefer-dynamic -C link-args=-s && wc -c ./hello
14856 ./hello
Криворук и ламероват - это злобный раст все виноват!
> Криворук и ламероват - это злобный раст все виноват!В оттенках коричневого разбираться нужным не считаю. Сделал как у растовиков рекомендуется пару лет назад, возможно за это время осилили уменьшить размер бинаря, но более нужным его это не делает.
>> Криворук и ламероват - это злобный раст все виноват!
> В оттенках коричневого разбираться нужным не считаю.Т.е. что такое debug/release компиляция, флаги оптимизации, что такое дебаг-инфа, статическая и динамическая линковки, strip - и как оно влияет на размер бинаря, ламерье не в курсе, не разбирается и разбираться не хочет? Впрочем, на то оно и ламерье, пусть и со звучным именем.
> Сделал как у растовиков рекомендуется пару лет назад, возможно за это время осилили уменьшить размер бинаря, но более нужным его это не делает.
> возможно за это время осилили уменьшить размер бинаря, но более нужным его это не делает.Да-да, уже лет 8 как, причем тайком от местных знатоков-экспертов.
Чего злой такой? Мне нафиг не упало задрачивать ржавый тулсет для получения приемлимых результатов. У меня и так всё хорошо, а вот у тебя похоже что-то не задалось, раз кидаешься на посторонних людей🙂
> Мне нафиг не упало задрачивать ржавый тулсет для получения приемлимых результатов.Да не задрачивай, ктож тебя заставляет? Но и ныть тогда не надо, что у тебя хеллоу-ворлд не получается приемлимо скомпилировать.
Не хватает ldd к этому выводу.
А кто им мешает-то, пусть делают, что хотят, только не под флагом kernel.org.
они по другому не могут... они только под чужими флагами гадить умеют.
>63), 14:12, 10/07/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
>>Исследователи из Китайского университета в Гонконге развивают проект для
>обеспечения мирового доминирования Китайской Народной РеспубликиСразу видим две вещи:
1) аноним реально в теме - там так и есть
2) модыратор реально куплен ККП
нет, он не куплен, всё гораздо печальнее... Он последователь этой идеологии, при чём промыты с раннего детства.
Справедливости ради, ядро написано не на Си.
Большинство из следующих используемых в ядре конструкций отсутствуют в языке СиВывод типов - typeof(x)
Ассемблерные вставки - asm volatile("pxor %xmm5,%xmm5");
Диапазоны в свитче - case 1 ... 7:
Массивы нулевой длины - some_variable_len data[0];
Адрес вызывающего - ptr = __builtin_return_address(0)
Определение константности выражения - if __builtin_constant_p(c)
Различные атрибуты функций - __attribute__((always_inline))
Подставляемые функции - inline void fun()
Имя текущей функции - my_func_name = __func__
Инструкции-выражения - ({ int a = b + 1; a; })
Переменное число параметров в макросах - __VA_ARGS__
Арифметика с указателями на void - ++void_ptr
Неконстантные инициализаторы - int arr[2] = { x, y }
Спорно.И ты этим хочешь оправдать использование Раста? Глупенький.
Что тут спорного? Это объективный факт. Ядро написано не на Си, а на Си-с-расширениями.
Компилятор, в котором нет этих расширений, такой код не соберет.
Парсер, который написан в соответствии со стандартом, такой код может не распарсить.
Человек, который учил Си по учебнику, конструкции не поймет, или подумает что это ошибка.До Раста мне дела нет, просто указываю на очевидную логическую неточность.
Так ядро же GNU-тое, все это знают. GCC - официальный компилятор, все это знают.Вот только ты решил подыграть растаманам. Расту нет места в ядре. Для экосистемы GNU/Linux язык Раст - это чужеродное образование.
>> Предполагается, что подобный подход может оказаться востребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита.Надо ещё больше говнокода! А то текущее количество миллионов строк уже никого не впечатляет.
дрова на скорую руку... проприетартные... жесть.
Так сжечь нах под корень... и в село делов...
Говно в говно! А то поразвели тут, понимаешь...
ТО ли Линус постарел, то ли гики помолодели ...
Ты тут два раза подумали и я два раза сказал... Да в ж0пу ваш раст, в ж0пу...
И надо больше жечь людей. Криворуких программеров ваще пачками...