На проходящей в эти дни конференции Open-Source Summit 2022 в секции ответов на вопросы Линус Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке Rust. Не исключается, что патчи с поддержкой Rust будут приняты в ближайшем окне приёма изменений, формирующем состав ядра 5.20, намеченного на конец сентября...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57391
Прагматичный мужик, с таким лидером Linux будет успешно развиваться, вбирая в себя лучшие новшества.
А как же так, неужели не надо всё ядро выбрасывать и на расте переписывать?
Вряд ли он страдает юношеским максимализмом, тем более в его-то возрасте.
в таком-то возрасте - пора на пенсию ;)
Дедушку, здоровающегося с пустотой и падающего с велика, всё никак на пом.. пенсию не выкинут, а вы про торвальдса
К слову, не помню последнее время репортажей о том как он катался на велике. Подготовился же, чертяка
Человечек, который статистически не доживет до собственной пенсии, хохочет с 79-летнего старика.
А из вопреки всё-таки доживших много ли кто на велосипед осилит залезть.
Ну если альцгеймер прогрессирует, то может и старик на велосипед полезет.
Ваш комментарий как яркая демонстрация того, что кое-где не могут представить — как это старики на велосипедах ездят.
Пенсы-огородники на велосипедах частенько катаются.
формально управляющего сверхдержавой.
А тогда зачем он раст то внедряет? Мог бы тогда как в былые годы всем им свой фирменный жест показать!
Так его феминистками обложили.
Причём, четверо из них у него дома.
Он им наслаждается
Москва не сразу строилась
к счастью, не на расте.
На чём-то вроде бейсика.
На Бедоне же. Вот как разрослась-то!
> На Бедоне же. Вот как разрослась-то!А что, архитектура улиц и транспорта - как будто питонист макет делал. Но это примерно как с питонным битторентом: да, истошный кал, но тогда по другому и не умели же!
ну, графический пинг написали, можно и за ядро взяться.
Графическое ядро уже почти написали!
Заметь, "безопасное графическое ядро".
Графическое ядро надо писать на Electron.
А до этого ты орал чти у Торвальдса с головой не в порядке.
Когда?
- Доктор, у меня провалы в памяти.
- И давно это у вас началось?
- Что?
- Ну провалы?
- Какие провалы?
А что он будет делать кода в ядре появится свободный код на несвободных системах комманд?
Затопает ножками при полном юридическом и практическом бессилии?Почему нельзя было сделать "безопасное написание драйверов" на другом языке программирования?
Шта
Ну безопасное написание драйверов ламерами это объективная реальность, потому что никто кроме них не будет писать драйвер для девайса который купили полтора человека и сделать для них загончик где они бы бсодили только свой драйвер нужно и полезно.Но почему для этого загончика выбран инструмент с лицензией имеющей потенциальную опасность вендорлока?
Свои проприетарные системы комманд никто не сможет и не будет делать?
Как тут хорошо вспомнить о открытом процессоре RISC V в который как раз можно ставить свои расширения команд.
Я не знаю какая у него лицензия, но мой нос чувствует приближение жопы.
Шизофазия
>> почему для этого загончика выбран инструмент с лицензией имеющей потенциальную опасность вендорлокаТак уже вендерлок во всё ведро)
Форкни системду например
> Форкни системду напримерА в чем проблема? У меня свой реп с парой кастомных патчиков. Апстриму оно не сильно надо т.к. на типа-старую-версию, потому что сильно менять то что уже работало было впадлу а починить кой-что хотелось. Назыввать это форком слишом громко, но так можно было.
> Ну безопасное написание драйверов ламерами это объективная реальность, потому что никто
> кроме них не будет писать драйвер для девайса который купили полтора
> человека и сделать для них загончик где они бы бсодили только
> свой драйвер нужно и полезно.Вообще-то бсодить ядро очень так себе идея. И Торвальдс очень популярно высказался что он про panic() при всяких нехватках памяти и проч думает.
Я имею ввиду всякие ошибки когда пишут не туда и затирают не то, там ведь могут быть люди которые начнут использовать указатели вообще не понимая что это такое, просто для получения эффекта надо так то написать и поставить *.
Так что БСОД это самое малое что они могут учинить...
И объявлять этот БСОД будет точно не их драйвер(это если успеет объявить до фактического развала)
Дяди из Linux Foundation решили окончательно убить Linux как Mozilla убивает Firefox. Примечательно, что тоже переписыванием на Rust. Потом окончательно переведут всех на какое-то несвободное ПО вроде Fuchsia с тивоизацией.
Да что ты такое пишешь то?
ну так лет пять убивать будут эт точно, а там и фуксия подоспеет. то же самое, что с файрфокс произошло - как по нотам с теми же действующими лицами
> ну так лет пять убивать будут эт точно, а там и фуксия
> подоспеет. то же самое, что с файрфокс произошло - как по
> нотам с теми же действующими лицамиА фуксию и убивать не надо - там квинтэссенция корпоративного булщита сразу по максимуму забабахана. Реализация FAT на игогошечки. Веьмакаки пыжатся в системное программирование, какая милота.
> Дяди из Linux Foundation решили окончательно убить Linux как Mozilla убивает Firefox.
> Примечательно, что тоже переписыванием на Rust. Потом окончательно переведут всех на
> какое-то несвободное ПО вроде Fuchsia с тивоизацией.Всех это кого? Хомячков на андроиде? У них и так линукс довольно паршивенький, с блоботой и троянами, сливащий телеметрию. А, и секурбут конечно. Кто сказал что линукс так не может?
Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?
Дочитай новость до конца, может тогда поймёшь.
так плюсы тоже умеют это, если ручку приложить. Он на простой Ся без всякой безопасности жил до этого вполне уверенно. просто дядька невзлюбил плюсы
> плюсы тоже умеют это, если ручку приложитьЕсли ручку приложить - можно из буханки хлеба сделать троллейбус, только зачем
HaikuOS полностью написана на с++ и вот-вот нагнёт ваш линукс на десктопах!
С РеактОСом вместе)
А разве её не на ассемблере пишут?
Это KolibriOS
Ну раз Гайку пишут на нормальном языке то посмотрю, судя по коментам там у вас скоро amdgpu прикрутят.
>на нормальном языке
>C++Чел...
Одно в гайке хорошо - она работает и неплохо выглядит.
>Одно в гайке хорошо - она работает и неплохо выглядит.Посмотрел, она девушка лёгкого поведения(MIT), так что в жёны я её несмотря на красоту не буду.
Хорошая, либеральная лицензия.
$ cd /tmp
$ git clone https://github.com/haiku/haiku
Cloning into 'haiku'...
remote: Enumerating objects: 773152, done.
remote: Counting objects: 100% (2529/2529), done.
remote: Compressing objects: 100% (1078/1078), done.
remote: Total 773152 (delta 1515), reused 2315 (delta 1416), pack-reused 770623
Receiving objects: 100% (773152/773152), 429.84 MiB | 11.41 MiB/s, done.
Resolving deltas: 100% (600679/600679), done.
Updating files: 100% (32232/32232), done.
$ cd haiku/
$ cloc .26383 text files.
26144 unique files.
6584 files ignored.github.com/AlDanial/cloc v 1.82 T=32.28 s (614.6 files/s, 147654.1 lines/s)
---------------------------------------------------------------------------------------
Language files blank comment code
---------------------------------------------------------------------------------------
C++ 5845 416467 206441 1540805
C 2328 131884 213995 776295
C/C++ Header 7785 168050 174111 711176
HTML 1988 26006 27508 232928
INI 24 3264 0 30168
Jam 1316 6647 1555 28362
Assembly 258 3109 4914 11246
reStructuredText 83 3349 453 10477
Windows Module Definition 8 202 0 5186
Bourne Shell 98 1341 1201 4771
yacc 4 510 229 3525
Python 20 896 1300 2414
XML 2 329 0 2003
JavaScript 2 551 55 1968
CSS 10 377 326 1817
SVG 7 1 4 1427
Markdown 12 240 0 1018
PHP 1 136 114 660
TeX 1 83 31 500
awk 5 94 177 476
lex 3 117 86 425
Pascal 8 54 4 370
JSON 6 0 0 258
make 10 180 621 195
Bourne Again Shell 4 23 21 168
Scheme 1 27 28 131
Perl 1 13 1 128
vim script 3 10 33 63
Dockerfile 2 15 10 61
GLSL 2 15 20 42
YAML 1 1 0 35
Ruby 1 3 11 25
---------------------------------------------------------------------------------------
SUM: 19839 763994 633249 3369123
---------------------------------------------------------------------------------------
А на Rust даже голову прикладывать ненужно, не то, что ручку.
> на Rust даже голову прикладывать ненужноОно и видно, как падал FF.
> просто дядька невзлюбил плюсыда их в принципе немногие взлюбили, поэтому, при первой же реальной возможности, выкидывают их на помойку
там про то что утечки памяти пишут, так я скажу то драйвер написанный тем у кого на плюсах память течет - скорее всего студент первого курса. ну а ты раз ссылаешься безосновательно на на прочтение статьи - дичь.
Линус не любит плюсы. И правильно делает.
Так в C++ Exception и это богомерзко и нельзя.
А в Rust panic и это только ай-ай-ай.
> Так в C++ Exception и это богомерзко и нельзя.Эппл, например, в IOKit взяли и просто запретили исключения и ещё пару вещей.
> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?Потому что Линус в гробу видал C++. Его потом дебажить замучаешься. И сломается в самый неподходящий момент. А это ядро.
Так может на OCaml?
> Так может на OCaml?Так уже есть Mirage.
Ядро HaikuOS написано на c++. И работает на декстопах уже получше чем...
Сколько в нём драйверов и архитектур есть?
Ну для RISC-V64 портировали, вроде.
> Ну для RISC-V64 портировали, вроде.И на скольких железках оно реально взлетает? И хотя-бы вафлю с вон того usb свистка оно зацепит при этом? Или тем более какого-нибудь модуля, ктулху упаси, на SDIO каком? Это линукс то если в свежей версии цепляет и не очень глючит - уже за счастье.
Ну и операционка с неотрываемым гуем на большинстве RISCV нужна как собаке пятая нога примерно.
Смешная шутка, пытался запустить эту вашу гайку на не самом свежем r5 1600+rx580, дальше загрузочного фона дело не пошло. Отличная система.
Попробуй на каком-нибудь старье.
А если старья уже нет, как быть? Авито не предлагать, я найду своим деньгам более годное применение.
>если старья уже нетЖиви одним днём?
Ну, значит без хайку. С линуксами та же беда, не везде запускаются, из-за этого в своё время бросил это занятие.
А если старья уже нет, как быть? Ав*то не предлагать, я найду своим деньгам более толковое применение.
>> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?
> Потому что Линус в гробу видал C++.Линус тогда сказал именно то, что от него хотели услышать люди, писавшие ядро на Си. Действовал в интересах сообщества.
> Его потом дебажить замучаешься. И
> сломается в самый неподходящий момент. А это ядро.Это предрассудки. Но если люди привыкли писать на Си - вот тогда им будет сложно. Поэтому Линус не захотел ломать традицию.
>>> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?
>> Потому что Линус в гробу видал C++.
> Линус тогда сказал именно то, что от него хотели услышать люди, писавшие
> ядро на Си. Действовал в интересах сообщества.Ты сейчас не Линуса описываешь. Линус тебе покажет средний палец и объяснит, что у тебя в голове дepьмо. Последнее, чем он будет заниматься, это писать то, что ты от него хочешь услышать. =)
>>>> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?
>>> Потому что Линус в гробу видал C++.
>> Линус тогда сказал именно то, что от него хотели услышать люди, писавшие
>> ядро на Си. Действовал в интересах сообщества.
> Ты сейчас не Линуса описываешь. Линус тебе покажет средний палец и объяснит,
> что у тебя в голове дepьмо. Последнее, чем он будет заниматься,
> это писать то, что ты от него хочешь услышать. =)Это ты сейчас отвечаешь не на мой комментарий, а на какой-то выдуманный. Я не пишу ядро Lunux, потому не вхожу в множество людей, чьи интересы Линус учитывает. Что касается пальцев - Микрософт показывал мне однажды, официально заявляя, что Си++ невозможно у них в ядре. Но оказалось возможно. Так что и палец Линуса не оказал бы воздействия. Другое дело, что Си++ _не_нужно_ в дереве исходников ядра Linux.
Ты не понял ничего.
Я _сделал_ когда-то то, чем ныне заняты растоманы. А вот если ты не смог мне что-то объяснить - это да, потому что я туповат. ;)
> Я _сделал_ когда-то то, чем ныне заняты растоманы.Это, например, что? Прислал патчи с поддержкой другого яп в майнлайн? Да ну?! :)
>> Я _сделал_ когда-то то, чем ныне заняты растоманы.
> Это, например, что? Прислал патчи с поддержкой другого яп в майнлайн? Да
> ну?! :)Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы, что бы писать драйвера на Rust. Когда мне понадобился Си++ в ядре Виндовс, я не слал в Микрософт письма с вопросами по компилятору, а просто сел и начал писать, дальше люди помогли. При этом "сишники" никак не мешали, поскольку не было походов со своим уставом в чужой монастырь. В итоге оно заработало (при этом драйвер работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна не очень, но помогала не писать тесты, а брать готовые). У растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения?
> Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы,
> что бы писать драйвера на Rust.Ну да. А что в этом пожелании такого плохого? В лине как-то принято с апстримом кооперироваться чтобы не усложнять себе и им жизнь лишний раз. Совместная работа над проблемой с двух сторон при наличии понимания и более-менее консенсуса с обоих сторон - эффективнее.
> Когда мне понадобился Си++ в ядре Виндовс, я не слал в Микрософт письма с вопросами по
> компилятору, а просто сел и начал писать, дальше люди помогли.С майкрософтом кооперация и коллаборация по сути невозможны. Я проверял. Это вообще совсем другие экосистемы и подходы и с точки зрения R&D это вообще-то их баг а не фича.
В лучшем случае за майками можно выгрести их фекальи. В хучшем вы там %$^тесь как хотите и всем похрен. И на разработку кернела - так же. На его перфонмас. Фичи. И их отсутствие. Косяки. И даже откровенные баги. Гнилая экосистема и уж не ее адептам линуксоидов учить как надо. Просто сравнивая какие вещи напрягавшие меня и где удалось загасить и сколько усилий это от меня потребовало так и сяк. А майкрософт был отклассифицирован как "враждебный апстрим". И теперь "хорошо что это не у меня". Торвальдс предпочитает быть более конструктивным апстримом. И кроме всего прочего не собирается счастье к глотку саплгами заталкивать, кроме некоторых сильно принципиальных моментов, что выгодно отличает его от майкрософта, чей маркетинг практикует это с завидным постоянством.
> При этом "сишники" никак не мешали, поскольку не было походов со своим
> уставом в чужой монастырь. В итоге оно заработало (при этом драйвер
> работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна
> не очень, но помогала не писать тесты, а брать готовые). У
> растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения?Ну так хрустикам придется интерфейситься к овердофига сишной начинки, нравится им это или нет. Никто не будет ради них все ядро переписывать да и не смогли бы в следующие цать лет. Они это или осилят или пойдут в пень, какие еще варианты есть? Если осилят, малацца, значит на хрусте можно и правда косиить под типа этакий си до кучи :)
Что до виндовых дров - я не очень в курсе что там у них, их DDK и подходы меня всегда вымораживали оверинженерностью и сложностью, и тем что без огромной и нахреннужной мне студии шагу ступить невозможно. В паре с общей враждебностью майков к ядерным девам пусть им там кто другой дрова пишет, имхо. В _моей_ системе (где я могу _моим_ ключем влепить подпись на модуль себе) такие развлечения как-то сильно проще той порнографии которую по этому поводу предлагали майки.
>> Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы,
>> что бы писать драйвера на Rust.
> Ну да. А что в этом пожелании такого плохого?В желании писать - ничего плохого не вижу.
> В лине как-то
> принято с апстримом кооперироваться чтобы не усложнять себе и им жизнь
> лишний раз. Совместная работа над проблемой с двух сторон при наличии
> понимания и более-менее консенсуса с обоих сторон - эффективнее.А вот здесь вижу смешение понятий. Если драйвера нет, что кооперировать? Потенциальную возможность?
>[оверквотинг удален]
> совсем другие экосистемы и подходы и с точки зрения R&D это
> вообще-то их баг а не фича.
> В лучшем случае за майками можно выгрести их фекальи. В хучшем вы
> там %$^тесь как хотите и всем похрен. И на разработку кернела
> - так же. На его перфонмас. Фичи. И их отсутствие. Косяки.
> И даже откровенные баги. Гнилая экосистема и уж не ее адептам
> линуксоидов учить как надо. Просто сравнивая какие вещи напрягавшие меня и
> где удалось загасить и сколько усилий это от меня потребовало так
> и сяк. А майкрософт был отклассифицирован как "враждебный апстрим". И теперь
> "хорошо что это не у меня".Я не понял, к чему это. Они контролируют ОС, но не могут запретить использовать ЯП.
> Торвальдс предпочитает быть более конструктивным
> апстримом. И кроме всего прочего не собирается счастье к глотку саплгами
> заталкивать, кроме некоторых сильно принципиальных моментов, что выгодно отличает его
> от майкрософта, чей маркетинг практикует это с завидным постоянством.И это не понял.
>> При этом "сишники" никак не мешали, поскольку не было походов со своим
>> уставом в чужой монастырь. В итоге оно заработало (при этом драйвер
>> работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна
>> не очень, но помогала не писать тесты, а брать готовые). У
>> растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения?
> Ну так хрустикам придется интерфейситься к овердофига сишной начинки, нравится им это
> или нет.Это само собой разумеется. ZFS on Linux приходится, и Reiser 4 приходится.
> Никто не будет ради них все ядро переписывать да
> и не смогли бы в следующие цать лет. Они это или
> осилят или пойдут в пень, какие еще варианты есть? Если осилят,
> малацца, значит на хрусте можно и правда косиить под типа этакий
> си до кучи :)На самом деле сишникам придётся качать сорцы на Rust, нравится им это или нет. Судя по комментариям, не всем нравится. И потом придётся смотреть патчи на Rust. И ревьювить... ну или так принимать. ;)
> Что до виндовых дров - я не очень в курсе что там
> у них, их DDK и подходы меня всегда вымораживали оверинженерностью и
> сложностью, и тем что без огромной и нахреннужной мне студии шагу
> ступить невозможно. В паре с общей враждебностью майков к ядерным девам
> пусть им там кто другой дрова пишет, имхо. В _моей_ системе
> (где я могу _моим_ ключем влепить подпись на модуль себе) такие
> развлечения как-то сильно проще той порнографии которую по этому поводу предлагали
> майки.Ну это сейчас так всё плохо, раньше было получше, в том числе и потому что Студия не умела собирать дрова.)
> В желании писать - ничего плохого не вижу.Ну дык. И в совместной работе над проблемой по-моему тоже одни плюсы. Это эффективнее получается чем если кто-то что-то в своей норке. Русинович делал вон годные системные тулсы. Маленкие. Полезные. Крутые. Профессиональные. Решающие конкретные системные проблемы. Майки его купили. И ... чо?! Слили в унитаз? Не предложив внятной замены?! Этим они неслабо так нассали в норку весьма большому количеству народа. А продвинутые кодеры на такое скотство апстрима откровенно заагрились. Ну как, тот же dbgview допустим, полезная штука был. Но после скупки русиновича он умер. Блобик даже не то что сдох, но начиная с 2008 примерно стал работать как-то фифти-фифти. Где-то пашет, где-то нет. Зачем мне тул на который нельзя положиться? К тому же замены просто нет. Штатные средства майков это дикое оверинженернутое Г которое точно не будешь ставить чтобы заткнуть мелкую системную проблему здесь и сейчас по быстрому. ИМХО такому апстриму место в аду.
> А вот здесь вижу смешение понятий. Если драйвера нет, что кооперировать? Потенциальную
> возможность?Да, а чего? Если всерьез кодить с прицелом на надежность и безопасность, можно заметить что сишка белый, пушистый, но некоторые принципиальные тупняки в его дизайне - есть. При том настолько фундаментальные что полностью их заделать не могут даже мощные статические анализаторы. Правда насколько оно там у хрустиков лучше окажется вопрос открытый и не получится ли так что заткнув 10 проблем они поимеют 100 новых - кто ж его знает. А убогий отлов integer overflow как у них я даже на совсем обкоцаном микроконтроллере могу с урезаным ubsan на сях. Так что у меня возникло ощущение что в пиаре эти господа лучше чем в реальной системщине. А лучше бы наоборот.
> Я не понял, к чему это. Они контролируют ОС, но не могут запретить использовать ЯП.
Ну да. И наверное если очень захотеть, можно и для линукса так изгальнуться. Просто это будет именно "изгальнуться". С прошибанием всех стенок своим лбом. А оно такое надо? Если цель доказать из принципа что автомобилем можно при сильном желании сбить вертолет, ну, да, в каких-то отдельных допущениях может прокатить. А если цель без напрягов накодить драйвер, занимаясь написанием (логики) драйвера а не деланием мозга не очень связанными сложностями - ну, блин. К тому же ABI там все же наверное сишное, и для его соблюдения придется осетра местами урезать. Как и исползование фич плюсов. И получатся типа плюсы, которые как бы плюсы, но как бы не совсем плюсы. Хрустикам это тоже в принципе все светит, но там их вроде отдрессировали сделать натяг совы на глобус несколько элегантнее, хотя тоже костылями выглядит вообще-то :)
> И это не понял.
Я имел в виду что если вон та толпа народа хочет дрова на хрусте кодить, а зачем им собственно лом в вентилятор ставить? У Торвальдса же все просто - если совсем не понравится или вон те сдуются, с выпиливанием из кернела у него не ржавеет.
> Это само собой разумеется. ZFS on Linux приходится, и Reiser 4 приходится.
Ну да, только они в отличие от хрустиков выбрали сложный путь. И вот это уже сугубо их половые трудности как они там в своей норке будут с этим разгребаться. В ядре Linux это никому не интересно. И при перепашке подсистем ядра они скорее учтут интересы хрустиков чем этих. Такой вот парадокс. Можно в список еще НеБлоб драйвер нвидии добавить, если что-то не изменится будет примерно так же имхо.
> На самом деле сишникам придётся качать сорцы на Rust, нравится им это или нет.
А еще мы качаем кучу всяких self tests, опциональных утилит, скриптов и какой там еще требухи, которую я вообще не компилю и не запускаю в 95% случаев. Более того - у ядра есть достаточно нетривиальные опции, которыми пользуются не все. Кто из опеннетчиков хоть раз ядро с KASAN билдил? Или crash kernel? А качать - придется. Более того - десктопному хомяку придется скачать какие-нибудь модули infiniband-а. И даже если у тебя RISCV нету, его поддержку скачать придется. Более того - билдсистема может довольно активно пытаться предложить собрать модули для чипаков, скажем так, "довольно нехарактерных для x86 компьютеров". В теории конечно ничему не противоречит что на SPI или I2C какой-то мамки влепят именно вон то, но оно обычно в околомобилочных или эмбедовочных девайсах на ARM каком. Но это не только скачать заставят, но еще и при сборке придется осмысленно ответить на эти вопросы. Или не очень осмысленно но тогда от числа модулей можно немного офигеть.
> Судя по комментариям, не всем нравится. И потом придётся
> смотреть патчи на Rust. И ревьювить... ну или так принимать. ;)Таки да, это вызывает и у меня некоторые вопросы. Но если Торвальдс считает что может get it right - а пусть покажет, интересно посмотреть на это все.
> Ну это сейчас так всё плохо, раньше было получше, в том числе
> и потому что Студия не умела собирать дрова.)Ух, я даже не знаю когда она их не умела собирать. DDK у майков сколько я себя помню был чем-то типа нашлепки над студией чтоли. А с альтернативными тулчейнами было как-то не особо. Да еще качать DDK так просто довольно долго не давали, душась жабой. Не знаю в чем прикол, но если они хотели нагнуть системщиков, это получилось - те и нашли greener pastures где их не натягивают. А майки получили персональный привет из эпохи ARMов когда оказалось что винда на этом не работает. Точнее как-то что-то на квалкомах. А все остальное - упс. И желающих кодить дрова - около ноля. Их так и не попускает - после похорон виндофона они что-то там с UWP чтоли пыжились, но проблема с дровами довольно фундаментальная и сменой названия и перестановкой кроватей не решается :))
>> В желании писать - ничего плохого не вижу.
> Ну дык. И в совместной работе над проблемой по-моему тоже одни плюсы.Где она, эта совместная работа? Где для неё обоснованные предпосылки? Грег Кроа-Хартман собирает статистику по коммитерам. Есть данные, сколько знают Rust? Сколько готовы писать на Rust?
>> А вот здесь вижу смешение понятий. Если драйвера нет, что кооперировать? Потенциальную
>> возможность?
> Да, а чего? Если всерьез кодить с прицелом на надежность и безопасность,
> можно заметить что сишка белый, пушистый, но некоторые принципиальные тупняки в
> его дизайне - есть. При том настолько фундаментальные что полностью их
> заделать не могут даже мощные статические анализаторы. Правда насколько оно там
> у хрустиков лучше окажется вопрос открытый и не получится ли так
> что заткнув 10 проблем они поимеют 100 новых - кто ж
> его знает.Ну вот, никто не знает, никто не попробовал. Готовятся к экспериментам на живом теле. В моём понимании, это стоило развить отдельно, создать что-то уровня Reiser4 - тогда никто не сможет возразить. Придётся моча учить Rust или идти подстригать газон.
> А убогий отлов integer overflow как у них я
> даже на совсем обкоцаном микроконтроллере могу с урезаным ubsan на сях.
> Так что у меня возникло ощущение что в пиаре эти господа
> лучше чем в реальной системщине. А лучше бы наоборот.Вот к этому я и клоню. Им важен не результат, а сам процесс внедрения, шум вокруг него. Зачем Гуглю этот процесс? У них есть своё новое перспективное ядро - Фуксия. Зачем им тогда Линукс?
>> Я не понял, к чему это. Они контролируют ОС, но не могут запретить использовать ЯП.
> Ну да. И наверное если очень захотеть, можно и для линукса так
> изгальнуться. Просто это будет именно "изгальнуться". С прошибанием всех стенок своим
> лбом. А оно такое надо?В Линукс это не надо, поскольку много человек долгие годы пишут ядро на Си. В Виндосе нет такого решающего фактора, как традиция и мнение сообщества, каждый сам себе паровоз. Были Керниган и Риччи, придумали Си, создали Юникс. Был Чарльз Симони, придумал венгерскую нотацию, получился в итоге Виндос.
> Если цель доказать из принципа что
> автомобилем можно при сильном желании сбить вертолет, ну, да, в каких-то
> отдельных допущениях может прокатить. А если цель без напрягов накодить драйвер,
> занимаясь написанием (логики) драйвера а не деланием мозга не очень связанными
> сложностями - ну, блин.Вот мне и требовалось решать задачу, где слишком много логики, что для ядра в принципе не свойственно. В Виндовсе много технологических отверстий, потому антивирус из пространства пользователя мало что насканирует, надо быть в ядре. Пока я не вижу драйвера на Rust, где бы была такая логика, мне ситуация не очень понятна.
> К тому же ABI там все же
> наверное сишное, и для его соблюдения придется осетра местами урезать. Как
> и исползование фич плюсов. И получатся типа плюсы, которые как бы
> плюсы, но как бы не совсем плюсы. Хрустикам это тоже в
> принципе все светит, но там их вроде отдрессировали сделать натяг совы
> на глобус несколько элегантнее, хотя тоже костылями выглядит вообще-то :)
>> И это не понял.
> Я имел в виду что если вон та толпа народа хочет дрова
> на хрусте кодить, а зачем им собственно лом в вентилятор ставить?А они уже кодили дрова? В Виндосе самый первый драйвер, который пишут, как правило специально генерит BSOD разыменовыванием NULL. ИМХО что-то в этом есть.
> Таки да, это вызывает и у меня некоторые вопросы. Но если Торвальдс
> считает что может get it right - а пусть покажет, интересно
> посмотреть на это все.Торвальдс перед всей этой историй уходил в странный отпуск, что бы подумать.
>> Ну это сейчас так всё плохо, раньше было получше, в том числе
>> и потому что Студия не умела собирать дрова.)
> Ух, я даже не знаю когда она их не умела собирать. DDK
> у майков сколько я себя помню был чем-то типа нашлепки над
> студией чтоли.Вот во времена DDK и не умела, в DDK шел свой транслятор в комплекте, сопровождалось это религиозным убеждением, что с другой версией обязательно случится BSOD. Потом DDK стал называться WDK. Наверное, 2008я Студия научилась собирать, зачем-то же я её устанавливал посмотреть.
> А с альтернативными тулчейнами было как-то не особо. Да
> еще качать DDK так просто довольно долго не давали, душась жабой.IFS Kit не давали. Прикол был в том, что вход в файловые системы только через курсы на OSR. И дело там не в жабе - они так искали специалистов.
> Где она, эта совместная работа?В случае сабжа для этого честно говоря рано. Поэка это в виде полураздристаного экспериментального нечто, им пользуются только полтора ультра-хардкорщика. Что логично.
> Где для неё обоснованные предпосылки?
Обоснованной предпосылкой будет очевидно появление этого в ядре. Вот там станет понятнее - есть что-то кроме воплей что %s это круто, или только гнилой пиар.
> Грег Кроа-Хартман собирает статистику по коммитерам. Есть данные, сколько знают Rust?
> Сколько готовы писать на Rust?На немайнлайнутой не устаканившейся реализации заведомо готово кодить чуть более ноля. А сколько на более адекватной застабилизированой реализации, с обтоптаными уже граблями - вопрос интересный. Этот эксперимент его и покажет. А не понравится - это будет далеко не первое что вылетело из линукскернела.
> Ну вот, никто не знает, никто не попробовал. Готовятся к экспериментам на живом теле.
Синтетические эксперименты не дают объективных результатов. И в силу опциональности этой штуки каждый сам может решить, надо ли оно ему. Я как минимум первое время буду это отключать, ибо заниматься тантрами с скачкой особой уличной магии^W ночнушек хруста я точно не готов. А если это будет дистровской версией цепляться, и желательно на основе gcc, там видно будет.
> В моём понимании, это стоило развить отдельно, создать что-то
> уровня Reiser4 - тогда никто не сможет возразить. Придётся моча учить
> Rust или идти подстригать газон.В смысле? Я не думаю что ядерщики перестанут принимать сишный код в обозримом будущем. А загадывать на 50 лет вперед в таких вещах дело неблагодарное.
> Вот к этому я и клоню. Им важен не результат, а сам
> процесс внедрения, шум вокруг него.У меня тоже такое ощущение есть. Но кроме этого в хрусте все же есть парочка дельных идей.
> Зачем Гуглю этот процесс?
У них много на это завязано, CVE их потрахивают, линукс у них много где, им это не нравится.
> У них есть своё новое перспективное ядро - Фуксия. Зачем им тогда Линукс?
Я вообще не уверен что этот кусок хайпоты с FAT'ом на игого жизнеспособен. Гугл и куда более крупные проекты сливал в трэш, типа гуглоплюса и Wave, под дружный вой всех кто вляпался.
> В Линукс это не надо, поскольку много человек долгие годы пишут ядро на Си.
А кто и почему решает что надо в Linux? А, Торвальдс и его майнтайнеры? Ну так если они поскрипели и решили что вон то им оки, я им поверю. А вот конкретно я могу и не собирать хайпоту от гугля на хрусте. Что мне от них надо в ближайшее время?
> В Виндосе нет такого решающего фактора, как традиция и мнение сообщества,
> каждый сам себе паровоз.И в конечном итоге желающих кодить дрова для виндов почти и не осталось. Что при омобиливании мира и гегемонии там ARM очень хорошо нагнуло майкрософт. Так себе история успеха.
> Были Керниган и Риччи, придумали Си, создали Юникс. Был Чарльз Симони,
> придумал венгерскую нотацию, получился в итоге Виндос.Только вот я Linux использую, который GNU, а он как известно, GNU is Not Unix. И я об этом помню. И сишку я предпочитаю минимум 99-ю. За хотя-бы вменяемые типы данных. Потому что вот честно, "int" это перманентный источник грабель и брейнфака в си при попытке писать портабельно. И правила integer promotion у сей тот еще брейнфакт. А указатели это круто и эффективно, но... статический анализ на них делать в вменяемом виде - невозможно.
Так что K&R для своего времени зажгли неплохо. Получше чем разработчики раста - но даже так, кто вот ща на K&R C вообще шпрехает? А вменяемые кодеры и типы данных C99 давно освоили. И даже содрали у хайлевелеров идеи типа возврата struct и проч для нормальных апи, а не, пардон, получения выхлопа функции в указателе поданом на ВХОД (это ушлепское убиение структурирования проги, в одном ряду с goto).
> Вот мне и требовалось решать задачу, где слишком много логики, что для
> ядра в принципе не свойственно. В Виндовсе много технологических отверстий,В Linux при желании можно ... наверное вообще совсем все. Я например из юзермода регистры железа трогал. Это делать конечно нельзя, потому что рушит парадигму многозадачки. Но если я уверен что я там один - прокатывает. С ремаркой "не пытайтесь повторить это у себя дома". Это не технологическое отверстие, а, пардон, complete takeover. Конечно, только от рута. В новых ядрах можно рубануть, DRMщики "lockdown" пропихали, но он и для секурити системы катит.
> потому антивирус из пространства пользователя мало что насканирует, надо быть в ядре.
Иные антивирусы сами почти как руткит, для самозащиты. Для меня это повод не пользоваться ими. Руткитобразный блоб без сорца доверия не внушает. Почему-то.
> Пока я не вижу драйвера на Rust, где бы была такая
> логика, мне ситуация не очень понятна.Могу даже немного натянуть сову на глобус. Вот смотри, билдсистема кернела пиндит если stack frame превышает 1024 байта. Большие стэкфреймы в именно ядре с кучей всего - ведут к дурным проблемам. К сожалению это означает что дровописаки начинают любить динамическое выделение памяти. А вот с этим не поздравляют, ибо все-таки известный источник проблем.
Правда у хрустиков решение проблемы само получилось тем еще костылем, чтобы не просто паниковало, при том не особо совместимым с другим кодом на хрусте :))) и доступное только в ночнушках или типа того. В общем так себе спасители человечества.
> А они уже кодили дрова?
Ну, как минимум, что-то пытаются изобразить. Совсем без этого они бы прослойку нишмагли, как и понять какие у ванили проблемы относительно ядра. Им сразу в рассылке сказали - мол, чего фигней страдаете, пишите какой-нибудь реалистичный драйвер, узнаете свои реалистичные грабли. Здравые коменты, между прочим, и они вроде вняли.
> В Виндосе самый первый драйвер, который пишут, как правило специально
> генерит BSOD разыменовыванием NULL. ИМХО что-то в этом есть.Мне это честно говоря не очень понятно. Я даже когда фирмвари писать учился первое что было все же помигать светодиодиком, потом сказать hello world в уарт например. А вот NULL отдереференсить и поймать свой HardFault - продвинутости, точно не первая штука. Я все же пишу код не для того чтобы он валился.
> Торвальдс перед всей этой историй уходил в странный отпуск, что бы подумать.
Я честно говоря вообще не понимаю как он выживает с его режимом.
> Вот во времена DDK и не умела, в DDK шел свой транслятор в комплекте,
> сопровождалось это религиозным убеждением, что с другой версией обязательно
> случится BSOD. Потом DDK стал называться WDK. Наверное, 2008я Студия научилась
> собирать, зачем-то же я её устанавливал посмотреть.Я когда-то, в эпоху раннего реактоса, смог собрать пару NT DRIVERS обычным gcc'ом и реактосовскими обвесом кажись, но это было довольно враждебно и потом они в подписи вдарились а рекатос в 2-й раз занялся перепиской кернела и я для себя решил что такие экосистемы я видал разве что в аду. К этому моменту мне как раз удачно подвернулась какая-то ранняя убунта на бесплатном сидюке, который не пропал даром =)
> IFS Kit не давали. Прикол был в том, что вход в файловые
> системы только через курсы на OSR. И дело там не в
> жабе - они так искали специалистов.Их до сих пор так и не попустило до конца походу. Вон юзерам новых маздаек ReFS зачем-то покоцали. Довели несчастных, WinBTRFS пилят с горя :). В общем MS vs FS это проклятое место походу. Они почему-то мнят что их технологии такие офигенные что позволяют выкрутку рук. Поэтому все годное что случается в этом направлении стало почему-то в пингвине :). Иногда майкрософт в своей жабе походу начинает жрать свой же хвост.
>> В моём понимании, это стоило развить отдельно, создать что-то
>> уровня Reiser4 - тогда никто не сможет возразить. Придётся моча учить
>> Rust или идти подстригать газон.
> В смысле? Я не думаю что ядерщики перестанут принимать сишный код в
> обозримом будущем. А загадывать на 50 лет вперед в таких вещах
> дело неблагодарное.В смысле, что Окно Овертона открывается постепенно. Безопасность же. За безопасность так или иначе приходится платить. Обяжут.
>> В Виндосе нет такого решающего фактора, как традиция и мнение сообщества,
>> каждый сам себе паровоз.
> И в конечном итоге желающих кодить дрова для виндов почти и не
> осталось.Сейчас ломается традиция писать Linux на Си.
>> Пока я не вижу драйвера на Rust, где бы была такая
>> логика, мне ситуация не очень понятна.
> Могу даже немного натянуть сову на глобус. Вот смотри, билдсистема кернела пиндит
> если stack frame превышает 1024 байта. Большие стэкфреймы в именно ядре
> с кучей всего - ведут к дурным проблемам. К сожалению это
> означает что дровописаки начинают любить динамическое выделение памяти. А вот с
> этим не поздравляют, ибо все-таки известный источник проблем.Именно это много лет как решает Си++ с std::unique_ptr. И я видел proposal в ISO/IEC 9899 на тему автоматического вызова функции очистки при выходе из scope. Другое дело, что мешать RAII и goto cleanup в одном проекте - не обязательно хорошая идея.
>> В Виндосе самый первый драйвер, который пишут, как правило специально
>> генерит BSOD разыменовыванием NULL. ИМХО что-то в этом есть.
> Мне это честно говоря не очень понятно. Я даже когда фирмвари писать
> учился первое что было все же помигать светодиодиком, потом сказать hello
> world в уарт например. А вот NULL отдереференсить и поймать свой
> HardFault - продвинутости, точно не первая штука. Я все же пишу
> код не для того чтобы он валился.Фирмварь работает где-то далеко и там ошибка страницы не так наглядна, как на живой системе. Никто не хочет, что бы что-то валилось. В 19-м веке, когда принимали мост, ставили инженеров под него и сверху пускали паровоз.
> В смысле, что Окно Овертона открывается постепенно. Безопасность же.И я бы сказал что с 70х прошлого века некоторые реалии и правда изменились, _некий_ валидный пойнт я распознаю.
> За безопасность так или иначе приходится платить. Обяжут.
Безопасность мне и самому нравится. А насчет обяжут КМК если и будет то не скоро. Загадывать на ...цать лет вперед - может к тому моменту хрустики задолбаются, или очередной убийца хруста его дожмет, а может и лину(к)са уделает кто-то новый. На такие сроки я загадывать не готов.
> Сейчас ломается традиция писать Linux на Си.
Си хорошая штука но тоже со своими приколами. А навсегда утыкаться в state of art 70х без учета новых данных и идей тоже как-то так себе. Поэтому логично иногда опробовать иные опции.
Плюсеров понесло куда-то не туда и системный яп из них точно не получился, зело уж сложные отношения у их нечто с рантаймом, стартапом и прочим. D может и имел шансы но жаба производителя компилера все про#$T%ла. А кто еще? А, убийцы раста на 90% слизаные с раста? :)
> Именно это много лет как решает Си++ с std::unique_ptr.
1) В ядре/бутлоадере/фирмвари и т.п. в общем случае НЕТ stdlib. Хрустики с этим тоже откушали, но, вроде, частично замахали.
2) В лучшем случае там есть что-то свое. Сильно кастомное. И для C++ это имеет свойство выглядеть весьма мерзотно и нетривиально и делаться хтонически криво. У него сложные отношения с ABI, стартапом, рантаймом и прочим. В кастомных окружениях та еще порнография.
3) Дебаг и аби плюсоты и все такое - очень так себе радость. Если хрустики смогут лучше чем это - получат памятник при жизни. И мне похрен как оно в виндусе и вьюжлстудии, скажем прямо.
4) Хруст таки придумал довольно наглый чит по части безопасности памяти когда им в частном случае вроде удалось и рыбку схесть и на ... сесть с их borrow checker'ом.
5) Типы данных в плюсах и UB не намного лучше сей. В хрусте этим все же больше заморочились.Так что выбирая прогать системщину на плюсоте или хрусте я еще дважды подумаю. У хрустиков хватило ума на нормальные целочисленные типы так как они должны быть в системщине (кроме u128 в обязаловку) и борьбу с UB.
> И я видел proposal в ISO/IEC 9899 на тему автоматического вызова функции очистки при
> выходе из scope.Оно может даже и не есть плохо, но в сях и плюсах объективно есть вещи которые стоило бы переделать или депрекейтнуть к хренам. Например я искренне ненавижу "классические" типы целых. Так по уродски их и тоникие моменты задефайнить еще суметь надо было. А сейчас на память об этом нам легион вулнов и тупых багов вокруг integer overflow. Даже гранды иногда фекалий откушивают. Лично видел.
> Другое дело, что мешать RAII и goto cleanup в одном проекте - не обязательно хорошая идея.
Определенно. И механизм типа exceptions в кернеле - очень спорный бенефит. В том плане что там допущения сильно другие чем в приложухах. Ядро не может просто сдохнуть при ауте памяти, даже для себя любимого. А механизм рекавери... вообще хрустики с этим тоже покушали и интересно посмотреть как оно им будет.
> Фирмварь работает где-то далеко
У меня она "на кончиках пальцев". Вон, в терминалке со мной через подобие ROM-монитора чатится. Накодив работу с шаговиком - погонять его интерактивно туда-сюда с разными скоростями и числами шагов было намного прикольнее любых бсодов. Управление шаговиком в стиле Quake с клавы?
> и там ошибка страницы не так наглядна, как на живой системе.
Там нет страниц, поэтому нет и ошибок страниц. И вы же не думаете что я буду ронять себе основную систему при ядерных экспериментах? Это сейчас все нормальные люди в виртуалках делают. Там даже если ядро совсем помре, out of band дебагер qemu туда все же пролезет.
Вообще сие фирмварщики и железячники первые придумали с JTAGом, но потом и ядерщикам так захотелось, что они, не люди? На х86 так можно но у него это сложно и уродливо, виртуальная версия этого - проще заводится.
> Никто не хочет, что бы что-то валилось. В 19-м веке, когда принимали мост,
> ставили инженеров под него и сверху пускали паровоз.Мне эта идея нравится и я хочу дойти до состояния когда я реально не зассу полагаться на мои фирмвари даже зная что их отказы могут меня угробить.
>> Сейчас ломается традиция писать Linux на Си.
> Си хорошая штука но тоже со своими приколами. А навсегда утыкаться в
> state of art 70х без учета новых данных и идей тоже
> как-то так себе. Поэтому логично иногда опробовать иные опции.
> Плюсеров понесло куда-то не туда и системный яп из них точно не
> получился, зело уж сложные отношения у их нечто с рантаймом, стартапом
> и прочим.Нет там рантайма, если разобраться и написать свой.) Диспетчер исключений это аналог setjmp.h. Статические конструкторы это аналог __init. typeinfo не обязательно использовать, да и реализация уложится в сотню строк.
>> Именно это много лет как решает Си++ с std::unique_ptr.
> 1) В ядре/бутлоадере/фирмвари и т.п. в общем случае НЕТ stdlib.unique_ptr не требует что-либо из "рантайма". Упрощённо можно считать, что перед скобкой } транслятор вставляет free(ptr);
>> Фирмварь работает где-то далеко
> У меня она "на кончиках пальцев". Вон, в терминалке со мной через
> подобие ROM-монитора чатится. Накодив работу с шаговиком - погонять его интерактивно
> туда-сюда с разными скоростями и числами шагов было намного прикольнее любых
> бсодов. Управление шаговиком в стиле Quake с клавы?Ну нет смысла её ронять, в отличие от живой сиситемы, по по пальцам она не ударит и рефлекс не выработается.
>> и там ошибка страницы не так наглядна, как на живой системе.
> Там нет страниц, поэтому нет и ошибок страниц. И вы же не
> думаете что я буду ронять себе основную систему при ядерных экспериментах?
> Это сейчас все нормальные люди в виртуалках делают.На эту тему есть анекдот:
- почему ты забыл префикс lock?
- у меня на вируталке и так работает!>> Никто не хочет, что бы что-то валилось. В 19-м веке, когда принимали мост,
>> ставили инженеров под него и сверху пускали паровоз.
> Мне эта идея нравится и я хочу дойти до состояния когда я
> реально не зассу полагаться на мои фирмвари даже зная что их
> отказы могут меня угробить.А просто надо не ссать. Опыт приходит сразу после того как был нужен. :)
> Нет там рантайма, если разобраться и написать свой.)Я так понимаю что хрустики именно таким и занялись, модуляризацией стдлиб и проч и альтернативными версиями там где "обычное" не катит. Хинт: если я хотел драйвер накодить, не факт что я хотел еще и то кодить сам, может весь кернел еще?
> Диспетчер исключений это аналог setjmp.h.
Я не уверен что в ядре исключения хорошая идея. И хрустиковая паника тоже. Ну вот допустим у нас не получилось выделить память а падать не хотим. Вместо этого хотим попозже попытаться опять. Но исключения и паника это не обеспечат. Торвальц хрустикам популярно донес, до них дошло вроде. И будет у них там более сиобразный стиль... )))
> Статические конструкторы это аналог __init.
Этот __init что и где? В сях его быть не обязано, технически гнутый тулчайн оперирует entry (с любым названием). Его вызывают (кто и почему отдельный вопрос), а дальше - теоретически, там должен быть стартап, который нормальную сишную арену соберет. В стандартной программе потом main вызовет. Может быть и что-то еще, тогда это окружение отличается от стандартного си по свойствам. Сам компилер в freestanding режиме как максимум может хотеть 3 функции, это 100% документировано: memcpy, memset и memmove. Вот их он реально иногда сам втыкает при кодогенерации. У плюсоы все сильно разлапистее, конечно.
> typeinfo не обязательно использовать, да и реализация уложится в сотню строк.
Сама программная модель исключений неважно ложится на то что может реально хотеть делать кернел. Наверное можно натянуть сову на глобус но хрустики ... пошли по пути пробитому сишниками как я понял. Т.е. накодили костыль для box и т.п. который таки может FAILить без вских паник и это надо чекать в откровенно севом стиле.
> unique_ptr не требует что-либо из "рантайма". Упрощённо можно считать, что перед скобкой
> } транслятор вставляет free(ptr);Круто, кроме того что alloc/free изначально тоже нет. Их как максимум можно себе создать. Фирмвари могут на это забить ("static memory allocation"). Ядро это делает, но у него несколько кастомных функций такого плана под специфику. А вот "транслятор вставляет" означает что при случае можно будет огрести грабель.
> Ну нет смысла её ронять, в отличие от живой сиситемы, по по
> пальцам она не ударит и рефлекс не выработается.Ждать пока упадет мой код можно долго. Мой МКшный код обычно не падает никогда и никак, ибо я читал определенные guidelines и выводы сделал. Но как мне узнать что handler вообще делает то что там задумано? Пришлось накодить искусственную провокацию, посмотреть на реакцию вообще. Не ждать же годами пока шальная частица подобьет мне проц?
> - почему ты забыл префикс lock?
> - у меня на вируталке и так работает!А таки я активно VM юзаю, ядерщики тоже, и это сильно упрощает многие вещи. И разницы с VM и железом обычно минимум. Во всяком случае в qemu и линукскернелом. Как оно там у вас в чем там у вас я понятия не имею. Я даже образа ARMовых систем отстраиваю на VM которая кросс-транслирует x86 <-> arm, это неспешно, но позволяет сделать образ даже когда железки еще в руках нету. SYZBOT штука довольно крутая кст, дофига багов робот репортит. Или вон скрипт autobisect кернела в qemu, круто, чо. Почти-сам ловит бажный комит если удалось pass/fail программно сформулировать. Для вас это поди космические технологии?
> А просто надо не ссать. Опыт приходит сразу после того как был нужен. :)
Так в случае МК в ящик сыграть можно, или угробить кого-то. Поэтому я предпочитаю постепенно двигаться: по мере прокачки скилла и появления ощущения что я контролирую ситуацию я позволяю себе несколько более требовательные применения. Сейчас я развлекаюсь с power electronics с программным управлением. При фэйле никто не умрет, но серьезный фэйл достаточно заметен.
>> Диспетчер исключений это аналог setjmp.h.
> Я не уверен что в ядре исключения хорошая идея.Потому и пишу "аналоги". Оно как бы есть по стандартам языков, но вполне можно без него.
> И хрустиковая паника
> тоже. Ну вот допустим у нас не получилось выделить память а
> падать не хотим. Вместо этого хотим попозже попытаться опять. Но исключения
> и паника это не обеспечат.В Си++ это всё делается с помощью placement new, либо точно так же как и в Си.
> Торвальц хрустикам популярно донес, до них
> дошло вроде. И будет у них там более сиобразный стиль... )))Только в другом синтаксисе.
>> Статические конструкторы это аналог __init.
> Этот __init что и где? В сях его быть не обязано, технически
> гнутый тулчайн оперирует entry (с любым названием).Этот __init можно найти в коде ядра. Точно так и статические экземпляры не обязательно создавать.
> Его вызывают (кто и
> почему отдельный вопрос), а дальше - теоретически, там должен быть стартап,
> который нормальную сишную арену соберет. В стандартной программе потом main вызовет.
> Может быть и что-то еще, тогда это окружение отличается от стандартного
> си по свойствам. Сам компилер в freestanding режиме как максимум может
> хотеть 3 функции, это 100% документировано: memcpy, memset и memmove. Вот
> их он реально иногда сам втыкает при кодогенерации. У плюсоы все
> сильно разлапистее, конечно.У меня это всё практически написано в виде работающего кода. Потому я могу утверждать, что мнение "сильно разлапистее" является предрассудком, в лучшем случае после знакомства с жирными реализациями. Это примерно как сказать "Си не годится в ядро, поскольку glibc много весит". ;)
>> unique_ptr не требует что-либо из "рантайма". Упрощённо можно считать, что перед скобкой
>> } транслятор вставляет free(ptr);
> Круто, кроме того что alloc/free изначально тоже нет. Их как максимум можно
> себе создать.Потому и написано "упрощенно". Вызывается заданная программистом функций.
>> - почему ты забыл префикс lock?
>> - у меня на вируталке и так работает!
> А таки я активно VM юзаю, ядерщики тоже, и это сильно упрощает
> многие вещи. И разницы с VM и железом обычно минимум.Да, "обычно минимум". То есть разница есть.
И ещё я не понял, как найти твои коммиты в ядро. По фамилии из профиля не находит.
.
Если же у тебя нет коммитов в ядро (согласно тамошних правил, следует указывать реальную фамилию), то возникает другой вопрос: если ты не имеешь отношения к разработке ядра, то какое твоё дело, что происходит в ядре? Вот это можешь объяснить? Не мне, себе объясни, для начала.
> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?Можно. Пиши, что тебе мешает-то?
Ядро и драйвера Windows NT разве не на С++ написаны?
Нет, на Си. Если не верите посм. утекшие исходники XP
На C++ был BeOS: https://en.wikipedia.org/wiki/BeOS_API
И haiku!
Всё читал смехушечки про ужасный синтаксис Rust. Потом сам столкнулся. Да даже C++ более читаемым выглядит.fn main -> std::io::Result<()>{
Вот чем думали разработчики языка? Удобно такое набирать? Нет.
дада, тебя забыли спросить
Это комментарий, а не ответ. В следующий раз пробуй потоньше.
Меня тоже забыли спросить. Делают растоподдержку для 1,5 хипстеров из гугла и мелкософта. Первые поиграются и забьют. Вторые будут EEE'кать. А возиться все-равно придется мейнтейнерам ядра (нет, я не мейнтейнер, я мимокрокодил).
Так суть раста в ЕЕЕ и есть. На какой проект, где он внедряется, ни посмотри, везде идет раздувание сборочных зависимостей, забивание на поддержку платформ и завязывание всего на пару расто-фанатов.
Разработчики уже все для тебя придумали: use, use as, type.
Ладно, передумал не любить rust. Включайте в ядро.
Сначала в GCC включайте.
Лицензионные ограничения раста...
Название поменять.
Или совместимую, по крайней мере, сначала, независимую реализацию.
GNURust
Такое только в hello world бывает. В реальных программах обычно функции возвращают просто Result<()>, потому что подключен anyhow или свой тип Error и "type Result<T> = std::result::Result<T, Error>;"
Это кусок из примера к стандартной библиотеке вводы/вывода. Никто, находясь в своем уме, не будет выкидывать пользователю сырые ошибки ввода/вывода, хоть бы имя файла указал, с которым проблемы.
А в чём проблема, и почему неудобно? Ну и `std::` лучше убрать, импортировав `io`, тогда будетfn main() -> io::Result<()> {
}
Думаю проблема в этом <()>.
Почему этого я не заметил, а ты заметил?
Если перечислить языки, которые знает каждый из Анонимов, вероятно, станет понятно.
Если уж прям глаз режет, то можно сделать type Void = ();
typedef goatse :D
> Думаю проблема в этом <()>.Рыба камбала :))
надо просто понять что есть аналог void'а: https://doc.rust-lang.org/std/primitive.unit.html
ну и немного привыкнуть к Result, потом это не кажется чем-то страшным
Если не используется код выхода, то просто пишешь:
fn main() { ...тело функции... }Если зачем-то код выхода внезапно нужен (интересно зачем, когда есть всякие panic, uwrap и тому подобная херня), то сейчас сделали чуть более лаконичный ExitCode
use std::process::ExitCode;
fn main() -> ExitCode {
if !check_foo() {
return ExitCode::from(42);
}
ExitCode::SUCCESS
}
https://doc.rust-lang.org/stable/std/process/struct.ExitCode...
>интересно зачем, когда есть всякиеСорян, но у тебя со здоровьем всё хорошо? Большего бреда от любителей раста я ещё не встречал.
panic — это только на случай нештатной ситуации. Полно штатных ситуций, когда нужно вернуть ненулевой код возврата. Например, юзер передал в командной строке путь к несуществующему файлу, ну и т. д.
> use std::process::ExitCode;
> fn main() -> ExitCode {
> if !check_foo() {
> return ExitCode::from(42);
> }
> ExitCode::SUCCESS
> }
> https://doc.rust-lang.org/stable/std/process/struct.ExitCode...Агаблин, это вместо сишного return 42. Стало проще, красивее, удобнее... </sarcasm>
> Агаблин, это вместо сишного return 42. Стало проще, красивее, удобнее... </sarcasm>Точно красивее. И удобнее, если брать не настолько синтетический пример.
И например в C вы можете сделать `return -42;`. А POSIX говорит, что код должен быть в пределах `0 ..= 255`. И вот попробуй догадайся, 1) к чему такой код приведёт, 2) зачем язык позволяет писать это.
> Точно красивее.Я заметил. Еще не менее красив их пример с функциями в параметрах, где у assignment'ов видите ли нет value, но вы можете вот так костыльнуть, но точку с запятой дескать вот тут ставьте а вот тут нет. Вот это я понимаю - наколень в дизайне ЯП, в отличие от сей, с оправданием что г@вно в синтаксисе так и задумано...
И это, а оно может из функции несколько параметро вернуть кроме как struct'ом каким? И что за нафиг, почему имена нельзя назначать на выход? Они решили сделать все это вообще так же педальненько как в сях? :)))
За примеры с структами и типами данных им в буке тоже факоф. Половина тем тупо не раскрыты. Окей гугл, покажите как красиво и без #$%чих закорючек вернуть допустим 1) статус операции, удалась она или нет (boolean) и 2) продвинутое инфо для тех кому не пофиг детали причины облома? Некрасиво я это и на сишке могу. У них эта тема вообще не раскрыта.
Еще мне понравилось про 2's complement. Мол в дебаге ловим, в релизе нет. И чем это от ubsan в сях отличается, например? :) И почему & в референсе структов вон там надо а вон там можно не ставить? Это чо за недоделаеная ПОЛУавтоматика одного и того же? Они издеваются? :)
Или можно ли там сделать допустим тип у которого валидное значение только от 3 до 8 а если больше пытаются - лучше всего компил сломать нахрен, т.к. это явно баг?
Не, там и прикольные моменты есть, но... но вот например бук на их сайте писан явно какой-то корпоративной сволочью в программирование не способной совсем. Поэтому даже типовые кейсы и конструкции не раскрыты. Здорово конечно но прогать какие-то более-менее реалистичные программы по этому не особо научишься. Да еще везде свой карго культ гадский суют.
> И удобнее, если брать не настолько синтетический пример.
> И например в C вы можете сделать `return -42;`. А POSIX говорит,
> что код должен быть в пределах `0 ..= 255`.В позиксе про _Exit написано такое:
The value status & 0377 is returned to the parent process as the process's exit status, and can be collected using one of the wait(2) family of callsИ если вам кажется что позикс паршиво специфицирован: да, это так. Но знаете что самое досадное для хрустиков? Вы его будете жрать точно таким же кривым. А лишние абстракции над этими кривульками как максимум могут прибавить глюков и непоняток. Переписывать ради вас таких красивых тот же позикс никто не будет. А стандартная либа это прекрасно, пока не потребовалось что-то ну вот натурально системное, именно вызовами в операционку и ее начинку. Потому что на вообще совсем все стандартных либ не напишешь.
> И вот попробуй догадайся, 1) к чему такой код приведёт, 2) зачем язык
> позволяет писать это.См. выше. Язык на самом деле просто не выделывается особо а позикс что, он писан укурками. Как впрочем и олдовые сишные типы с их никакущей спецификацией. В этом хруст даже имеет некие бонусы, но требование допустим u128 ставит раком некоторые платформы. На какой-нибудь 8-битной дряни его татк то тяжко. А если кто про системщину вякал и кроссплатформенность, нехило бы и в микроконтроллеры уметь так то. Иначе вместо альтернативы сям получается какой-то стеб.
> вы можете вот так костыльнуть, но точку с запятой дескать вот тут ставьте а вот тут нет. Вот это я понимаю - наколень в дизайне ЯП, в отличие от сей, с оправданием что г@вно в синтаксисе так и задумано...Это как раз одна из самых красивых вещей. Одна из тех, пр которые давно стало понятно как надо делать правильно, и вот Rust (не считая, конечно, Haskell и т.п.) наконец воплотил.
> оно может из функции несколько параметро вернуть кроме как struct'ом каким?
Туплом.
> почему имена нельзя назначать на выход? Они решили сделать все это вообще так же педальненько как в сях?
Так и на вход нельзя. Симметрия. Ну и если уж нужны имена, то может стоит придумать ещё всего одно имя и сделать именованную структуру? Ну и почему прямо как в сях? В хаскеле тоже так, например.
> У них эта тема вообще не раскрыта.
Эта тема общая для всех языков с ADT, никакой Rust специфики в ней нет.
> И чем это от ubsan в сях отличается, например?
Тем, что здесь это не UB.
> И почему & в референсе структов вон там надо а вон там можно не ставить?
Это вопрос из серии из серии "почему в русском языке тут надо запятую ставить, а тут не надо". Потому что такие правила. Чтобы обсуждать предметно, нужна альтернатива. Только лучше не получится.
> можно ли там сделать допустим тип у которого валидное значение только от 3 до 8
Можно, но не нужно, потому что без зависимых типов ценность у таких типов нулевая (если не отрицательная), ибо при первой же арифметической операции все эти ограничения теряются и они превращаются в полноразмерный тип.
> Здорово конечно но прогать какие-то более-менее реалистичные программы по этому не особо научишься.
Потому что это учебник языка, а не учебник программирования.
> требование допустим u128 ставит раком некоторые платформы
А что, длинную арифметику отменили? Атомарности Rust не требует от такого типа.
> Так и на вход нельзя. Симметрия.Точнее так: на вход имена не может указывать вызывающая сторона (нет вызова функции с именованными параметрами), а на выход, наоборот, вызываемая (функция не может специфицировать имена для полей результата). И наоборот, функция при описании специфицирет имена входных параметров, а вызывающая сторона может декомпозировать результат в набор именованных параметров.
> Точнее так: на вход имена не может указывать вызывающая сторона (нет вызова
> функции с именованными параметрами), а на выход, наоборот, вызываемая (функция не
> может специфицировать имена для полей результата).А симметрия тут в каком месте возникает? Может, имелась в виду АНТИсимметрия? Вот в это я готов поверить :)))
Антисимметрия — это частный случай симметрии.
> Это как раз одна из самых красивых вещей.Агаблин, кроме лаконичного и унифицированного синтаксиса (== эффективный тул). В этом месте мы понимаем почему говорят что краткость сестра таланта. И нет, вот именно то в сишке обычно никаких проблем никому не создавало, так что починили то что не сломано. Хз нафига.
> Одна из тех, пр которые давно стало понятно как надо делать правильно, и вот Rust
> (не считая, конечно, Haskell и т.п.) наконец воплотил.Лично я не понимаю хаскелистов, они слишком сферически-вакуумные для написания реальных программ. Решают какие-то проблемы которые мне до 3.14-ды, а мне до того же они и их программы с яп-ом.
> Туплом.
Спасибо, если сложные вещи возвращать я и в сях struct могу нарисовать, но это не очень удобно и не очень красиво, лишние закорюки. С фига вот нельщя -> i32, i16 и return (10, 20)? И почему я должен это в тупл совать если они логически не связаны между собой?
> Так и на вход нельзя. Симметрия.
Как это? https://doc.rust-lang.org/book/ch05-02-example-structs.html
fn area(width: u32, height: u32) -> u32 {
По-моему, width и height это 2 именованых входных параметра, при том хотя дока про struct'ы, в именно этом случае оно как раз без них. А вот так же, симметрично, на выход сделать - уже фиг. И где симметрия?! Но вон то с impl'ом довольно симпатично.> Ну и если уж нужны имена, то может стоит придумать ещё всего одно имя и сделать
> именованную структуру?Ради пары integer'ов не рулит. Больше писанины и закорючек в конечном итоге. При том для эффективного референса (указатель) в хрусте как я понял тоже & надо и когда он вон там автоматически добавляет, а вот там нет - это называется костыльный и ни разу не стройный дизайн ЯП имхо. Опять же симметрия продолбана.
> Ну и почему прямо как в сях? В хаскеле тоже так, например.
Чисто практически хаскелисты - один из самых бесполезных видов програмеров которых я знаю. Развели концепций и абстракций во имя луны, но ни одной полезной программы на этом я не встречал за всю мою жизнь. Так что ценность тех брейнфартов мне не очевидна. Я в курсе что уйдя в матрицу можно не вернуться, в их случае - поголовно.
> Эта тема общая для всех языков с ADT, никакой Rust специфики в ней нет.
Если я смотрю на хруст и его синтаксис, да еще в их буке, кивать куда-то еще очень сильно не комильфо, имхо. Смысл в таком буке?
> Тем, что здесь это не UB.
Если ubsan активировать, становится defined behavior'ом, так же дает в тыкву, 1 в 1 :). Есть даже лайтовый режим когда там очень небольшой оверхед когда это вызывает хардварное исключение проца типа Bad Opcode вместо навороченого рантайма, так даже на микроконтроллерах живет (конечно же продолбав скорость и увеличив код). Могу себе представить что у него вот так оверхеда зело меньше чем у дебагбилда хруста. Не ноль конечно.
> Это вопрос из серии из серии "почему в русском языке тут надо
> запятую ставить, а тут не надо".Если уж мы об этом, русский язык уж точно не стоит брать за пример при создании ЯП. Сложный, несимметричный, кривой, с кучей "легаси". Какой % жителей РФ им нормально владеет в виде когда они могут хотя-бы писать без тупых ошибок? :)))
> Потому что такие правила. Чтобы обсуждать предметно, нужна альтернатива.
> Только лучше не получится."Убийц хруста" уже несколько штук есть. Видимо сомневаются - и имеют на то причины. Я что-то не вижу заявленной симметрии - и это в самых базовых вещах из их же бука.
> Можно, но не нужно, потому что без зависимых типов ценность у таких
> типов нулевая (если не отрицательная), ибо при первой же арифметической операции
> все эти ограничения теряются и они превращаются в полноразмерный тип.Мде. Ну например, есть некий алгоритм. Он доказуемо-валидно себя ведет "от сих до сих". А с другими значениями начинает делать бред, вплоть до out of bounds. И мне совсем не катит чтобы он out of bounds или даже панику сделал в рантайме, например. И нехило бы в компилтайме чекнуть что оно именно вот так.
Что до арифметических операций, нехило бы какой-то варнинг или типа того в таким случаях, что "невозможно пруфнуть". Как намек что я вообще-то должен пересмотреть этот код из соображений стабильности, безопасности и верификации. В этом смысле Zig с компилтайм вычислениями любопытно выглядит, там наверное такую сову на глобус даже реально.
> Потому что это учебник языка, а не учебник программирования.
Вообще-то предполагается что это учебник программирования на этом языке. С какими-то более-менее реалистичными конструкциями.
> А что, длинную арифметику отменили? Атомарности Rust не требует от такого типа.
На 8-битном уродце лестница арифметики получается такая что часто всем просто вломы это. И честно говоря я не понимаю зачем u128 делать базовым типом. Для BigInt мало, на большей части платформ не особо эффективно, мелочевку нагибает (байбай, универсальность), а в реалистичных случаях всякие там смещения в файлах и проч к 2^64 врядли приблизятся в обозримом будущем. Они там сингулярность запилили втихаря?
> И нет, вот именно то в сишке обычно никаких проблем никому не создавалоОдна из самых известных проблем, ради которой какие только костыли ни придумывали — и "сравнение наоборот" (`2 == x` вместо `x == 2`), и дополнительные скобки и чего только не придумывали. А всё что нужно — чтобы присваивание не возвращало значения.
> С фига вот нельщя -> i32, i16 и return (10, 20)?
Потому что `(10, 20)` — это и есть тупл. Поэтому `-> (i32, i16)`.
> По-моему, width и height это 2 именованых входных параметра
Но при вызове функции эти имена теряются, нельзя позвать `area(width: 1, height: 2)`. С возвращаемым значением наоборот — при вызове можно поименовать компоненты тупла: `let (width, height) = function();`, а в сигнатуре функции они безимянные.
> когда он вон там автоматически добавляет, а вот там нет
Автореференс делается в одной, строго оговорённой ситуации. Есть один реальный кейс, где это реально выливается в неприятную штуку, но тут просто нет решения лучше, нет альтернативы.
> Если я смотрю на хруст и его синтаксис, да еще в их
> буке, кивать куда-то еще очень сильно не комильфо, имхо. Смысл в
> таком буке?Смысл в том, что это не учебник программирования.
> Если ubsan активировать, становится defined behavior'ом, так же дает в тыкву,
> 1 в 1 :).Ну и в чём проблема-то?
> "Убийц хруста" уже несколько штук есть.
Они даже близко не стоят по степени готовности.
> И нехило бы в компилтайме чекнуть что оно именно вот так.
Без зависимых типов это всё паллиатив, мёртвому припарка. Но в Rust такое можно сделать, без проблем. Только ерунда это.
> какой-то варнинг
Непонятно что с этим ворнингом дальше делать. Только затыкать, но тогда это некорректный ворнинг получается, такому ворнингу в компиляторе не место, он как минимум в линтере должен быть, а то и вообще в полноценном статическом анализаторе. Но полноценный статический анализатор и без явного типа-диапазона может провести доказательство, что в нужном месте паника не возникает.
> Вообще-то предполагается что это учебник программирования на этом языке. С какими-то более-менее реалистичными конструкциями.
Я не знаю кем такое предполагается. Учебник — это совсем другая книга, другой жанр. Например, не может быть учебника без задач.
> На 8-битном уродце лестница арифметики получается такая что часто всем просто вломы
> это. И честно говоря я не понимаю зачем u128 делать базовым
> типом. Для BigInt мало, на большей части платформ не особо эффективно,
> мелочевку нагибает (байбай, универсальность), а в реалистичных случаях всякие там смещения
> в файлах и проч к 2^64 врядли приблизятся в обозримом будущем.Не могу тут ничего сказать. Не знаю. Но, например, монотонное время в наносекундах в u64 не влезает. Так, в линуксах `timespec` состоит из 64-битных секунд и 32-битных наносекунд, так что если пытаться упаковать это в одно число, то нужно u128. Но это, конечно, слабый аргумент.
> Одна из самых известных проблем, ради которой какие только костыли ни придумывали
> — и "сравнение наоборот" (`2 == x` вместо `x == 2`),Вообще-то...
1) Проблема в том что сравнение было похоже на присвоение и очевидное типо вело к факапу. На момент десигна сей такой статистики не было и это еще можно понять. А потом, вот, зная типовость граблины заворкэраундили. Сколько такого в хрусте мы узнаем... потом.
2) Эта проблема в хрусте пролечена скорее уж кейвордом let, явно сделанным из подобных соображений.
3) Паскалисты делали это лучше своим :=, меньше кноп жать (2 vs 4). Просер вдвое паскалю, вчетверо сям.
4) Обругать другой яп так себе аргумент за стройность яп... :)> и дополнительные скобки и чего только не придумывали. А всё что
> нужно — чтобы присваивание не возвращало значения.Когда 2 = x, это ошибка, ибо константе пытаются что-то присвоить, совершенно невалидно. Но к вон тому случаю относится достаточно косвенно.
> Потому что `(10, 20)` — это и есть тупл.
В моем примере это лишь визуальное выделение, return 10, 20; ничем не хуже. Туплы все же какая-то отдельная сущность и если цель вернуть пару параметров без заморочек, выглядит каким-то оверкилом. А для наворотов и так struct были. В чем их пойнт вообще?
> Поэтому `-> (i32, i16)`.
Ну да, однако декларим вход мы все же несколько иначе и получается как-то кособоко.
> Но при вызове функции эти имена теряются, нельзя позвать `area(width: 1, height: 2)`.
Да и хрен с ним, имхо. Если кто ну вот реально именно это хотел (параметров дофига?), ему, наверное, все же struct'ы хотелось на самом деле.
> С возвращаемым значением наоборот — при вызове можно поименовать компоненты
> тупла: `let (width, height) = function();`, а в сигнатуре функции они безимянные.И получается, блин, опять не симметрично.
> Автореференс делается в одной, строго оговорённой ситуации. Есть один реальный кейс, где
> это реально выливается в неприятную штуку, но тут просто нет решения
> лучше, нет альтернативы.Это еще в принципе хрен с ним, всего не предусмотришь. Мое опасение здесь что когда в 1 случае автоматика есть а в другом нет, это может привести к багам когда кодер это пробакланит.
> Смысл в том, что это не учебник программирования.
Вообще-то это именно "учебник программирования на Rust" судя по виду.
> Ну и в чём проблема-то?
На самом деле - в стандартах сей и как они написаны. Бывает так что люди срезают угол, экономя себе силы там, где это делать было вообще совсем нельзя. Это именно тот случай.
> Они даже близко не стоят по степени готовности.
Says who? Адепт яп который сабж может чуть ли не только в ночнушках? :)
> Без зависимых типов это всё паллиатив, мёртвому припарка. Но в Rust такое
> можно сделать, без проблем. Только ерунда это.Это не ерунда, это какие-то азы контрактов, чтоли, без полномасштабного залета на это. Вы правильно поняли, все хотят и рыбку съесть и косточкой не подавиться.
> Непонятно что с этим ворнингом дальше делать.
1) Там где это реально важно (safety-critical, security, reliability) и стандарты кодинга строгие, -Werror.
2) Остальным популярно рассказать фу такими быть, типа как с unsafe. Если уж кто воткнул подобие контракта то наверное имел в виду что это должно быть так.> Только затыкать, но тогда это некорректный ворнинг получается, такому ворнингу
> в компиляторе не место, он как минимум в линтере должен быть,Если так рассуждать, warning'ам вообще в компиляторе не место. Некоторые разделяют эту точку зрения и как минимум в сях и плюсах практикуют -Wall -Werror. Что так то очень на пользу качеству кода и отлову левых ситуаций.
> статическом анализаторе. Но полноценный статический анализатор и без явного типа-диапазона
> может провести доказательство, что в нужном месте паника не возникает.Вот это ну не факт. Если я моим кодом генеряю вход - может быть. А если я это с ADC прочел? Ну, докажи что он мне может дать и не может. И вот в этом случае было бы айс получить варнинг или еррор, поскольку кодер, очевидно, облажался.
> Я не знаю кем такое предполагается. Учебник — это совсем другая книга,
> другой жанр. Например, не может быть учебника без задач.В принципе они могли бы добавить и это, кмк похрустеть немного мозгом их аудитории было бы полезно :)
> Не могу тут ничего сказать. Не знаю. Но, например, монотонное время в
> наносекундах в u64 не влезает.Могу себе представить что будет если кто hi-res время в u128 начнет безбашенно считать. Там у линуксоидов и так прикол был что на часы зырить довольно дорогая операция, а если ее еще этим обвесить... :)))
> Так, в линуксах `timespec` состоит из 64-битных секунд и 32-битных наносекунд,
> так что если пытаться упаковать это в одно число, то нужно u128.Технически вон то занимает 96 битов в памяти. Это меньше. Переполнение оных происходить не обязано. А u128 это не только 2 64-бит регистра но и совершенно точно мастхэв кода который их переполнение ворочает. Это может и спасет от каких-то багов но может урыть перфоманс.
> Но это, конечно, слабый аргумент.
Ну хоть какой-то, я и на это не рассчитывал :)
Не для вас написано, молодой человек.
Тем временем C++ (орфография сохранена, ... - это именно троеточие, прямо в коде)template<class T, class... Args>
inline T& fn(Args&&... args) {
> Тем временем C++ (орфография сохранена, ... - это именно троеточие, прямо в
> коде)
> template<class T, class... Args>
> inline T& fn(Args&&... args) {Точнее, многоточие. Внезапно, в данном случае оказывается интутивно-понятно. Хотите "грузить" - налегайте на && и move semantics. Я бы уже загрузился. ;)
Это код из реального проекта, который судя по всему пишут компетентные разработчики, может поэтому и понятен. Но даже это кажется бессмысленной лапшой для человека, котрый знаком с хорошими языками.
> Это код из реального проекта, который судя по всему пишут компетентные разработчики,
> может поэтому и понятен.Не сочиняйте. Fn - это foo.
> Но даже это кажется бессмысленной лапшой для
> человека, котрый знаком с хорошими языками."Интуитивно-понятно" в моём ответе выше следует понимать как "исходя из знания грамматики русского языка".
Не сочиняю, увидел вызов fn<X>(args) и стало интересно, что за лапша. Оно мало того, что оказалось перегружено, так ещё и вот в такой форме.Нет, исходя только из грамматики русского языка, смысл этого кода понять не получится.
> Не сочиняю, увидел вызов fn<X>(args) и стало интересно, что за лапша. Оно
> мало того, что оказалось перегружено, так ещё и вот в такой
> форме.В живом проекте кто-то назвал функцию fn? Это невозможно.
> Нет, исходя только из грамматики русского языка, смысл этого кода понять не
> получится.Пишите честно: "мне не удалось понять".
Пишите честно: "мне удалось понять, зная грамматику русского языка, программирование, имея 10 лет опыта в С++, зная стандарты С++2014, С++2019 и и.д.", а то какие-то двойные стандарты, к одним словам докапываешься (fn), а С++ную лапшу - игнорируешь. Теперь понятно, откуда тёрки с росой.
Я не знаю новые стандарты плюсов и писал на них, когда variadic templates не было.Delphi / Turbo Pascal / Free Pascal:
var FilteredChars: set of [#0..#32,#127,'a'..'z'];
var CheckedItems: set of [4,10..38,241,58];https://en.wikipedia.org/wiki/Ellipsis_(computer_programming)
Вот о <()> они и думали.
больше языков в ядро, а потом удивляться тому, что ядро поддерживает только три с половиной процессора
Тоже ниасилил прочитать новость?Вообще предлагаю модераторам сделать следующие: вместо числа на картинке при отправке комментария отвечать на вопросы по содержанию новости.
> преподносится как опцияЛицемерие. Ровно до тех пор пока драйвер видео или клавиатуры не будет на нем. Ню ню.
>> преподносится как опция
> Лицемерие. Ровно до тех пор пока драйвер видео или клавиатуры не будет
> на нем. Ню ню.Ну, сперва на одну восьмую шишечки вставят, а потом и всё ядро проржавеет.
Чот мне это напомнило... ЕМНИП, нужно вроде было старый инит на более быстрый и без фатального недостатка, переделать, но это не точно, давно это было.
Ещё гарфику пытались безопасной сделать... В итоге половина прог перестали работать из-за архитектурных проблем.
То есть RedHat вместо того чтобы втихаря ночью под одеялом накопить бесценный многолетний опыт по решению проблем тысяч промышленных установок, десятки тысяч проблем с обслуживающим персоналом, обобщить это и выяснить что башпортянки и есть главный источник проблем а значит источник бабла для проходимцев мнящих себя "я такой сисадмин юникса в свитере и знаю чем отличаются "" от '' на колени предо мной платите миллиарды за мои башзнания и нелтленные башпортянки, а то уволюсь и ппц фирме" нанял Лёню и решил проблемы, причем в открытую все документировано и свободно.Но тут как солнце из за туч от Дебиановских начетчиков :
> нужно вроде было старый инит на более быстрый и без фатального недостатка
Ваш главный дебиановец кто эту мутную волну на RedHаt гнал уже не снами но дело его живет.
Вообще-то волну гнать начал еще специалист по шаттлам из убунты. Но у него апстарт получился, скажем так, и хотя идея была прикольная (реакция на эвенты) оказалось что она в комплекте с некоторыми довольно специфичными граблями.А именно
1) В этой штуке было не особо предусмотрено как притащить системные дефолты с одной стороны, дать админу их перекрыть с другой и чтобы пакетник при апдейте это все не выпилил к хренам. Об этом убунтуи просто не подумали на фазе дизайна а потом поздняк метаться было. Посмотрел на это поттеринг и сделал деление на системные дефолты притаскиваемые пакетником и более приоритетный админский оверрайд, который пакетники трогать не смеют просто по регламенту.2) Прописать СВОЮ программу "до" или "после" чьей-то еще? В СВОЕМ конфиге запускалки? Да сейчас! Это надо конфигу той программы трогать. Опачки, а это уже полный залет, надо чужую программу и ее компонент портить оказывается. Посмотрел на это все поттеринг и сделал инверсию зависимостей. И вот тогда стало хорошо. Можно вот именно своим юнитом стартануть перед или за кем-то совсем посторонним, если мы уверены что надо именно вот так. Ну например если я запускаю прогу которой надо впн - я могу запуститься после того как впн запустился, а не до того как его интерфейса даже еще нету блин, так что подвиснуть на нем точно ой -> FAILED.
А sysv init вообще подобной фигней и много чем еще - не особо парился, вы там и...сь как хотите, дескать. Ну и творился трэш, угар и содомия.
Вот, даже Microsoft это понимает.
Если позарез модуль будет нужен, придётся портировать на C. По крайней мере, пока Rust frontend не добавят в GCC.
Сам будешь портировать, сам и поддерживать. И кланяться, обязательно с подписью CLA, DCO и сдачей ДНК-биометрии в подтверждение, что в случае, если код не лицензионно чист, то что ты заранее жопу копирастам подставил. И не факт, что примут. Сопровождающие ядра там тебе ничего не должны. Захотят - вообще возможность запуска на твоем "калькуляторе" выпилят.Но давайте начистоту. Ядро и так жирное, собирается долго, и сами его из юзеров и разрабов никто не собирает. А если даже и собирает, то для той архитектуры драйвера на расте никто писать не будет, если раст её не поддерживает. Но раст даже микрухи теперь поддерживает.
А я где-нибудь сказал, что буду в апстрим проталкивать? Для себя и для того парня, и только для LTS.
На самом деле, логичным должен быть вопрос не "когда С++", а "когда Fortran, ADA, objective C".
Вот вопрос про Ada не кажется шуткой.
Это пока на нём не начнёшь писать. Вот уж где пригодится метод скоростной слепой печати.
> На самом деле, логичным должен быть вопрос не "когда С++", а "когда
> Fortran, ADA, objective C".Когда ты покажешь как на всем этом великолепии системщину делать и чтобы это не было еще более жутким чем все остальное.
новое поколение анбешных бекдорописак разучилось писать на С, вот и пихают это поделие, чтобы бекдоры не крешили систему когда работают с памятью.
Интим не предлагать?XD
без смс и рекламы :)
Ага, с OAuth говорят секьюрнее. )
То ли дело старое поколение, которое сразу пишет идеальный код, без единой ошибки на миллион строк.
через месяц жизни в gdb развивается умение делать сильно меньше ошибок на си.
Здорово. А я уже лет 6 не запускал gdb за ненадобностью, потому что перешёл с C++ на Rust.
> Здорово. А я уже лет 6 не запускал gdb за ненадобностью, потому
> что перешёл с C++ на Rust.мы же когда подходим к бармену не говорим "сделай мне смузи по такому вот рецепту".
За Rust не скажу, только неллоу ворлд запускал и примеры из растбука. А на плюсах дебаггер запускал сильно меньше, но это было очень давно и код там был тривиальный. Логику на плюсах писать сильно приятней было чем на сях. Опираясь на то что я видел в расте, логику там писать приятней чем в плюсах (я так думаю, но опыта коммерческой разработки на раст у меня нет)
> Здорово. А я уже лет 6 не запускал gdb за ненадобностью, потому
> что перешёл с C++ на Rust.Круто, оказывается, хруст как-то делает программы без багов. Нюню, пылесосы иди продавай, Кирби позавидует.
>Круто, оказывается, хруст как-то делает программы без багов.Это я сказал или ты придумал? Вопрос риторический. Rust "делает программы" без некорректных обращений к памяти. А для поиска логических ошибок я gdb практически не использую, потому что гораздо удобнее вывести структуры данных в нужном формате через println!(), нежели ковыряться в сырых данных в gdb.
Это тебе, Онаниму, нужно идти продавать пылесосы, потому что твоим навыки демагогии в программировании не только бесполезны, но ещё и вредны. В этой профессии и без тебя дураков хватает.
> практически не использую, потому что гораздо удобнее вывести структуры данных в
> нужном формате через println!(), нежели ковыряться в сырых данных в gdb.Ну надо же, а у нас это "дебажный printf" называлось лет так .. дофига. Только у вас он оверинженернутый и можно поспорить баг сие или фича. И вдруг я что-то проприетарное пишу? Тогда я не хочу чтобы тем мордам утекали сведения о внутренней начинке программы в таких объемах, особенно с именами и прочим.
> Это тебе, Онаниму, нужно идти продавать пылесосы, потому что твоим навыки демагогии
> в программировании не только бесполезны, но ещё и вредны. В этой
> профессии и без тебя дураков хватает.Просто напомноло уж очень логику продажников кирби. Мол покупайте пылесосы, смотрите, сколько пыли после вашего! Ух, а оказывается столько же и после их пылесоса будет, только про это не говорят :)
Абстрагируясь: можно КПД итогового решения?
Сетевой драйвер для 10 ГБ\с
https://github.com/ixy-languages/ixy-languages/blob/master/R...
В виде научной статьи и в сравнении с другими языками https://www.net.in.tum.de/fileadmin/bibtex/publications/pape...
p.s.: да, там есть грёбанный javascript. Нет, я не буду это спойлерить.
p.p.s.: Rust чуть хуже с "проверками" и намного быстрее без проверок, даже при банальном переводе С кода в Rust. Смысл в проверках? - Ловит баги. Подробнее - в статье =)
Ох уж эти сказочки...
Абстрагируясь? Шляпа платит Линусу бонусы, Линус ловит лулзы с сообщества.
> Подробнее - в статье =)Почти нажал. Но - нет.
Всегда мечтал собирать ядро неделю.
Первый день Rust. Впрочем, в дальнейшем может понадобиться не один день.
Кстати интересно как там инициатива по рефакторингу заголовочных файлов продвигается. Обещали неслабое ускорение сборки.
Поддерживаю интерес!
> Кстати интересно как там инициатива по рефакторингу заголовочных файлов продвигается.
> Обещали неслабое ускорение сборки.Некоторые части уже вкомитили. Но не все, оно большое и очень интрузивное чтобы его оптом и с лопаты везде впихать.
Как там успехи у дистрибутива Hyperbola с использованием ядра OpenBSD, кто знает?
Если начнут писать модули на Расте каков их будет среднестатистический бинарный размер? Только не говорите мне, что надо каждый раз отключать включёные по умолчанию функции дебага.Если начать компилировать исходные коды на Расте, сколько ждать? Половину дня? Люди говорят, что исходники на Расте и C++ компилируются очень долго.
Раст болтливый язык? Одинаковая реализация в процедурном стиле среднестатистического алгоритма на чистом Си будет занимать меньше строк чем на Расте? Чисто-сишное ядро и так раздуто, а с распространением языка Раст мы будем вынуждены в итоге скачивать гигабайтный архив исходных кодов?
Короче, в голову приходят страшные мысли. Ребята передайте Линусу пусть он пока не пускает Раст в ядро! А корпорасты, которые лоббируют продвижение Раста пусть идут лесом.
Эх, даже если мы устроим краудфандинг, чтобы компенсировать Торвальдсу упущенную выгоду, вслествие отказа от включения Rust, мы не наберём столько.
> Раст болтливый язык? Одинаковая реализация в процедурном стиле среднестатистического
> алгоритма на чистом Си будет занимать меньше строк чем на Расте?Раст, внезапно, функциональный. Так что, в общем случае, меньше. Другое дело, что железо "императивно".
> Раст, внезапно, функциональный.в расте функции - первоклассные объекты, можно ими жонглировать как душе угодно?
>> Раст, внезапно, функциональный.
> в расте функции - первоклассные объекты,Если верить Википедиям, то и Си++ они первоклассные https://en.wikipedia.org/wiki/First-class_function#Language_...
> можно ими жонглировать как душе угодно?
Он же компилируемый - так что есть нюансы с eval. Через пару лет можно будет оформить в виде llvm.ko.
Зато "переменные" иммутабельны по умолчанию, не требуется императивный return.
Вот обычные для ФЯ конструкции:
let y = {
let x = 3;
x + 1
};fn five() -> i32 {
5
}https://doc.rust-lang.org/book/ch03-03-how-functions-work.html
Осталось прикрутить к этой безусловно полезной абстракции отображенные в память регистры контроллера...
> Вот обычные для ФЯ конструкции:Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика?
>Уровень детсада.В системном программровании нужна только процедурщина.
>Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика?
А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном программировании не нужна.
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном
> программировании не нужна.Смысл функционального программирования не в этих всех замыканиях. Если процедура хранит состояние, то для одних и тех же входных данных она может давать различный результат. Отсюда следует идея чистых функций и иммутабельности: если состояние не хранить, тогда можно на этапе трансляции доказать корректность кода -- как раз это в Rust и называют "безопасность". По той же причине в императивных языках по возможности стараются писать const. Но в реальном железе имеем const volatile. =)
> в реальном железе имеем const volatile. =)Это что еще за порнография? Типа регистр RO для софта, но который может со своей стороны менять железо?
>> в реальном железе имеем const volatile. =)
> Это что еще за порнография? Типа регистр RO для софта, но который
> может со своей стороны менять железо?Это когда регистр железно выполнен как RO, софт может туда и писать, но ничего не изменит.
> Это когда регистр железно выполнен как RO, софт может туда и писать,
> но ничего не изменит.А, обычный RO регистр, что-то я тупанул тут. Вообще регистры логично референсить как адреса в памяти, то-бишь указатели, и там чуть сложнее получается - const'ов может быть ДВА. У указателя (как индикатор что адрес регистра прибит на гвозди, зачем нам баги если мы сдуру указатель сменим?!) - и потом у его типа. Как бы именно volatile const'ом регистр вообще не референсится, скорее указателем на него.
Хотя-бы потому что убедить си кинуть переменную в памяти по конкретному адресу... как бы это... ну, не предусмотрено. А с указателями пожалуйста.
Интересно как хрустики кстати volatile делают и вот это самое, раз кудахчут про системность.
> В системном программровании нужна только процедурщина.А ты уверен что даже просто ioctl какой попадает под именно такое определение? :)
А еще - в сях можно функции переназначать на лету, передавать как параметры и проч. Указателями на функцию, прикинь?! Это позволяет делать довольно забавные вещи.
Ну там например дефолтный хэндлер события, который однако юзер может перекрыть своим если оно ему надо. И много чего еще. Типа вгрузки функций на лету из .so допустим.
>>Где передача функций, как объектов, каррирование, композиция функций
>>и прочая ненизкая математика?
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном
> программировании не нужна.Они половину этой порнухи так то сами умеют делать прямо из сей каких и проч.
>> Вот обычные для ФЯ конструкции:
> Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций
> и прочая ненизкая математика?Наберите интересующие слова в поисковике и читайте. Как должно быть понятно из первой ссылки, которую Вы заботливо вырезали при цитировании, там всё это можно найти. Я лишь намекаю, что функциональное программирование это не только лямбда исчисление.
> Я лишь намекаю, что функциональное программирование это не только лямбда исчисление.Еще один невзрослый тезис. Не надо приравнивать некоторые элементы ФП и само ФП.
Функциональное программирование - это именно жонглирование функциями.Как в расте передать композицию функций, особенно вернуть как результат, особенно с захватом локальных значений?
> Функциональное программирование - это именно жонглирование функциями.Поскольку "жонглирование" не формализовано, процитированное "определение" ФП - демагогическая чушь. Поскольку цирковой термин повторяется дважды - похоже на мантру для некоей секты.
> "определение" ФП - демагогическая чушьВот именно, сегодня. Сегодня "определение" ФП - это "парадигма", что есть не формальное определение, а демагогия. Сегодня любой новый модный молодежный язык, в котором есть термин "функция" - это "язык ФП". А вот раньше трава была зеленее.
То есть предмет спора выдуман автором сообщения №258.
Вернемся к нашим баранам.
Так как вернуть композицию функций в расте?
Ответьте, пожалуйста, отдельным сообщением, когда Вам удастся с Вашими баранами разобраться. Очень интересны вопросы животноводства.
Простите, ваша фамилия случайно не Головин?
> Он же компилируемый - так что есть нюансы с eval. Через пару
> лет можно будет оформить в виде llvm.ko.Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет, за это Торвальдс таки все же прилюдно люстрирует, имхо :)
>> Он же компилируемый - так что есть нюансы с eval. Через пару
>> лет можно будет оформить в виде llvm.ko.
> Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет,
> за это Торвальдс таки все же прилюдно люстрирует, имхо :)Так это будет потом. Когда привыкнут, что Rust уже и так есть, выйдет версия 2.0. Окно Овертона же.
> Так это будет потом. Когда привыкнут, что Rust уже и так есть,
> выйдет версия 2.0. Окно Овертона же.Скорее, научат хруст eBPF какой генерить и в юзермод вывесят :))). Но между нами, вон там LLVM или кто еще GPUшке в юзермоде шейдеры как-то так и компиляет.
Теоретически, это может быть безопасно. Практически, как-то наподобие трахнули xbox360, чтоли, поклав на многоэтажную систему DRMной секурити...
Си программы меньше размером, потому что динамическая линковка.
А в расте - больше, потому что динамическая линковка с libc.
ямеюсь
> А в расте - больше, потому что динамическая линковка с libc.Господа, а вас не смущает что кернел с libc не линкуется, ни там ни там? :)
> Если начнут писать модули на Расте каков их будет среднестатистический бинарный размер?Если программа на расте будет делать тоже самое, что программа на сях, то размер будет одинаковый.
> Только не говорите мне, что надо каждый раз отключать включёные по умолчанию функции дебага.
А зачем у тебя по умолчанию включён дебаг?
> Если начать компилировать исходные коды на Расте, сколько ждать?
Без разницы - конечные пользователи устанавливают готовый бинарь. Даже если захочется самому собрать - это разовая операция.
> Одинаковая реализация в процедурном стиле среднестатистического алгоритма на чистом Си будет занимать меньше строк чем на Расте?
Прогресс в развитии языков наоборот, позволяет писать код менее громоздко, но при этом более понятно.
> Ребята передайте Линусу пусть он пока не пускает Раст в ядро!
Ты бы поинтересовался мнением программистов - за и против раста. Это более продуктивно было бы, чем, ничего самостоятельно не понимая выдумывать проблемы и обращаться за решением к диктатору, который сделает лично тебе хорошо.
> Без разницы - конечные пользователи устанавливают готовый бинарь. Даже если захочется самому собрать - это разовая операция.Особенно, когда тебе говорят попробовать найти баг с помощью git bisect.
Да и корректирующие релизы ядра выходят не раз в полгода. Так что далеко не разовая.
Ты модуль ядра решил компилировать что ли, раз тебе бисект потребовался? Тогда бы ты знал что занимаешься его разработкой и не говорил что бинарно бисектить собрался. Короче мимо парень
> Ты модуль ядра решил компилировать что ли, раз тебе бисект потребовался? Тогда
> бы ты знал что занимаешься его разработкой и не говорил что
> бинарно бисектить собрался. Короче мимо пареньА в чем прикол стандартное стоковое ядро компилить? Bisect это как раз вполне валидная причина компилежки и время оного очень даже интересует.
> Прогресс в развитии языков наоборот, позволяет писать код менее громоздко, но при этом более понятно.Ну все, Я понял, почему программы так пожирнели последнее время. ;) Это чтобы понятность не изменилась! ;) ;) ;)
Очередной любитель оптимизаций по хдд. Прогрессу плевать на твои желания, адаптируйся или деприсируй 🤣
Сначала такой
>адаптируйся или деприсируй 🤣а потом
>меня-то защооо?!!
Оптимизации люблю до определённого предела. Но, постоянная память и особенно ОЗУ они же не резиновые, что бы бросать туда всякий ненужный мусор. Но Вы же (ИМХО) гооооораздо выше таких мелочей (пока Вам этот мусор на голову не начнет сыпаться).
Дико извеняюсь, но...
Как же Я люблю это Но, оно как правило дремлет, но, как иногда бывает, вот заблудился человек в дебрях технического прогресса, потерялся, растерялся, запутался в чужой да и в собственной лжи, и тут о чудо, Но вдруг неожиданно просыпается, да как подпрыгнет как подскочит, надает заблудшему аплпеух да подзатыльников, повернет в сторону Истины и даст хорошего пинка, что бы Прогрессу было за кем гнатся! ;)
А бывает, Но не просыпается. И приходится Прогрессу плеваться и плестись, блудить и плеваться. Грустно?!? :(
НО, мы не будем, строить разлапистые теории заговоров, а просто спишем все на простую человеческую ... мудрость! ;)Если под словом деприсируй Вы имели ввиду пресс, то мне больше нравится, элиминируй, в данном контексте.
О своих желаниях Я тайно поведал в предыдущем своем посте. Об остальных, скромно умолчу ;)
> Если начать компилировать исходные коды на Расте, сколько ждать? Половину дня? Люди говорят, что исходники на Расте и C++ компилируются очень долго.А до включения Раста ядро можно было скомпилировать прям на ходу при запуске с помощью tcc (Tiny C Compiler).
Не говоря уже про время сборки самого компилятора. Ведь Раст - это не только сам Раст, но ещё и монстр LLVM.
Можно, и можно будет, но зачем? И так и так всё равно нужно будет тюнить флаги компиляции… вот правда зачем тебе то дерьмо мамонта?
> Короче, в голову приходят страшные мысли.А вот если будешь изучать язык, читать документацию и писать программы, будут приходить ещё и умные. На все твои вопросы есть очевидные ответы. Но тебе нужны не ответы, а солидарность таких же хейтерков, у которых других проблем нет в жизни, кроме Rust, который прямо-таки давит на мозги, покоя не даёт. Ну как же, придётся работать не с сырыми указателями, а со ссылками, думать, кто владеет памятью, у кого доступ на чтение, а у кого - на запись, а то же "буручекир заругаит", ещё всякие дженерики и трейты - того гляди, последняя извилина перегорит. А ещё скобочек много, глаза болят. То ли дело православная сишка, в которой скобок меньше и код красивый, как женская сися, накидал указателей, погонял немного (код, а заодно и лысого на код)... ну, раз не падает, значит багов нет. Статическая верификация - для слабаков, а настоящий программист не примет помощи от какого-то там компилятора, и вместо 100 строк unsafe кода будет читать столько кода, сколько потребуется. Заодно и наизусть выучит, чтобы потом зайти на сервер и набрать заново, потому что Git - тоже для слабаков.
>А вот если будешь изучать язык,совет на вес золота, С бы так изучали
Можно его изучать хоть 40 лет, но от ошибок в работе с памятью это не спасёт. Если даже лучшие программисты на планете их совершают, то про опеннетных экспертов я вообще молчу. К тому же, готов поспорить, что большинство из последних не знает и половины ситуаций с undefined behaviour в их любимом языке, потому что компиляторы в большинстве случаев услужливо генерят вменяемый код, а не мусор, как могли бы, согласно стандарту. А в остальных случаях эксперты вынуждены запускать отладчик и с переменным успехом искать, из какой щели сыпется мусор. Заметь, я нигде не говорю, что С - говно и т.п., как здесь принято у местной элиты по отношению к другим языкам. Я просто перечисляю объективные недостатки языка.Если вдруг непонятно, вездесущий undefined behaviour и полное отсутствие проверки указателей со стороны компилятора - это недостатки. Мы не в 80х живём, программы сейчас намного функциональнее, соответственно, их код намного больше, и уже только из-за этого становится практически невозможно писать код на C, лишённый багов, связанных с некорректным обращением к памяти. Чем больше компилятор предотвращает ошибок, тем лучше для всех - и разработчиков, и пользователей. По-моему, это очевидно. Поэтому разработчики ядра, наученные горьким опытом, и готовы включить поддержку Rust в ядро, коль уж сишные стандартизёры, мягко говоря, не очень торопятся улучшать свой ЯП.
А вот почему на техническом ресурсе ошиваются толпы луддитов-нарциссов с гипоманией и нездоровой фиксацией на C, мне совсем не очевидно. Может, это религия такая, секта? Это как если бы ты на городской улице сел перекусить бутербродом, а к тебе подбежал небритый косматый человек, одетый в шкуры, и стал бы учить, как разводить баранов и выращивать пшеницу - дескать, это азы выживания, и ты не можешь считаться мужиком, если не бегал полдня с копьём за будущим обедом.
> А вот почему на техническом ресурсе ошиваются толпы луддитов-нарциссов с гипоманией и
> нездоровой фиксацией на C, мне совсем не очевидно. Может, это религия
> такая, секта?Может им приходилось принимать участие в разработке ядра? Если они знают Си, это вероятный сценарий. Если это так, значит часть "луддитов" говорит о том, что их так или иначе касается (насколько они правы или ошибаются - это вопрос второй). А вот что делают остальные?
> Может им приходилось принимать участие в разработке ядра? Если они знают Си,
> это вероятный сценарий.Ага, а ещё у них есть руки - значит, вероятно, они маньяки-убийцы, художники, операторы бетономешалки и т.д.
А у Вас есть коммиты в ядро?
Нет. Но я и не указываю никому, на чём им писать ядрёный код. Если понадобится, буду писать на Rust, а на C - только если не будет байндингов к нужным API.
Указания уже даны https://www.kernel.org/doc/html/latest/process/submitting-pa...Одно из требований: Check your patches with the patch style checker prior to submission (scripts/checkpatch.pl).
https://www.kernel.org/doc/html/latest/process/coding-style....По сути, "указывающие" лишь ссылаются на официальную документацию.
Другой момент, это приём пачтей. Их смотрят минимум двое. Сопровождающий драйвер и ответственный за подсистему. Эти люди далеко не вчерашние студенты и всю жизнь писали на Си. С возрастом растёт такая штука, как когнитивная ригидность. Стойкость убеждений, если по простому. Часть разработчиков ядра не могут принять Rust не потому что "синтаксис плохой", а потому что он непривычен. Эти люди будут вынуждены покинуть проект.
>штука, как когнитивная ригидность. Стойкость убеждений, если по простому.нет, была бы болгарка в руках Микеланджело его бы скульптуры были бы щедевральнее чем тем же зубилом? Принял бы он болгарку, если всю жизнь учился мастерству работы с зубилом? А в чем разница он бы сразу сказал бы.
Черт его знает, но если болгарка будет маленькой и CNCшной, я могу попробовать забахать что-то прикольное. И в отличие от Микеланджело не обломлюсь повторить на бис 50 раз. Или 50 000 000 раз. Иногда это по своему прикольно.
> и CNCшнойвот тут надо задуматься, ибо ЧПУшку надо программировать (пошагово) и получается, что мы придерживаемся строгих правил движения, это как черчение. Но ведь мы не "ценим" черчение так как "ценим" изобразительное искусство (графику к примеру, без красок), вопрос - почему.
> вот тут надо задуматься, ибо ЧПУшку надо программировать (пошагово)Вообще-то вот именно мне будет надо модельку отрисовать. Опять же при помощи компьютеров. А ее втрамбовку в возможности конкретной машины можно поручить тем у кого эта машина стоит, это довольно типовой вид отношений. Ну и вручную опять же все движения програмить никто не будет, только ограничения возможностей машины обыграют и усе, а основной объем команд сгенерится автоматикой из модели.
> и получается, что мы придерживаемся строгих правил движения, это как черчение.
Зубилом тоже не любой объект сможешь. Попробуй им полость внутри сделать без изъянов? И не любой материал сможешь. Ну, отзубиль кусок титана, допустим. А какой-нибудь 3D принтер в принципе может это обойти, другая технология - другие лимиты. При том модель он сожрет в общем то ту же самую.
> Но ведь мы не "ценим" черчение так как "ценим" изобразительное искусство
> (графику к примеру, без красок), вопрос - почему.С другой стороны, лично я вполне оценил ролик про "костюм железного человека" на ютубе. Из титана, выдерживает попадание пуль, и даже летает (хоть и оказалось что есть нюансы). И хотя его можно повторить, это дорого, возни много, а смысла мало, к тому же надо с правообладателем опять согласовывать. Поэтому он такой один на всю планету. Зачетный артефакт так то. В общем то ценим мы, имхо, талант, креативность, оригинальные идеи и что-то неординарное. Вот именно черчеба в чистом виде как и рутинная трансляция команд этим не является. А оригинальная модель и проект в целом - уже вполне. Ну и когда оно масспродакшн то оно просто приедается и начинает восприниматься как должное.
>Участник 'burjui' запретил публикацию ответовожидаемо
>Можно его изучать хоть 40 лет, но от ошибок в работе с памятью это не спасёт.
если складывать все яйца в одну корзину, кто виноват? Продавец или курица которая несет ломающиеся яйца?
пс: все беды людские - от ума.
"""
В комедии «Горе от ума» кто умное действующее лицо? ответ: Грибоедов. А знаешь ли, что такое Чацкий? Пылкий, благородный и добрый малый, проведший несколько времени с очень умным человеком (именно с Грибоедовым) и напитавшийся его мыслями, остротами и сатирическими замечаниями. Все, что говорит он, очень умно. Но кому говорит он все это? Фамусову? Скалозубу? На бале московским бабушкам? Молчалину? Это непростительно. Первый признак умного человека — с первого взгляду знать, с кем имеешь дело и не метать бисера перед Репетиловыми и тому подоб.
"""Свои критические замечания о произведении высказал А. С. Пушкин в конце января 1825 года в письме А. А. Бестужеву из Михайловского в Петербург.
>Линус Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке RustА c++ ему не нравится! И в защиту плюсов скажу что HaikuOS (как и BeOS) от ядра и загрузчика и до самого юзерспейса написана на c++! И вот-вот нагнёт этот ваш линукс на декстопах! Уже сейчас почти работает vulkan-видеодрайвера для radeon карт!
Тут жеж ещё всё сильно будет зависеть от того, сможет ли весь существующий свободный софт быть собранным под Haiku.
А с этим проблемы? Компилятор си в ней есть, берёшь, собираешь.
На словах всё просто. А там то Libc не совсем такая, то ещё чего. Ну собери Qt 5.15.3, например, под неё.
Qt должно же быть уже собрано?
> от ядра и загрузчика и до самого юзерспейса написана на c++Как что-то хорошее. Приходи, когда нагнёт.
На C++ с эксепшенами или на C++ без эксепшенов? Чисто из любопытства спрашиваю. Я, правда, сравнительно немного работал с C++ продакшен кодом, но всё же работал и ни одного проекта с включёнными эксешенами и штатным RTTI не попадалось.
Ядро Windows написано на Си, но исключения там используются. Механизм Structured Exception Handling (SEH) похож на Си++ исключения и последние могут быть реализованы поверх него. Штатный RTTI есть в Qt. Судя по возрасту проекта, когда-то там был свой велосипед, но теперь внутри него чистый dynamic_cast.
Про SEH я в курсе. Интересно именно про C++ и HaikuOS / BeOS.> Штатный RTTI есть в Qt.
Ого. Пожалуй стоит сильнее прислушаться к хейтерам современного Qt. Возможно они не так уж неправы.
> Про SEH я в курсе. Интересно именно про C++ и HaikuOS /
> BeOS.Что именно интересно про Си++? Когда дизайнили ядро NT, насколько понимаю, языка С++ не было. SEH точно так же хранит некоторую информацию времени исполнения о типе ошибки. Точно так же есть проблемы, не работает на высоких IRQL. И ещё объекты ядра обмениваются сообщениями. :)
> Что именно интересно про Си++?Интересно, написаны HaikuOS/BeOS на C++ с эксепшенами или на C++ без эксепшенов.
Уже не пойму, когда шутят, а когда нет. Можно ведь поискать. https://github.com/haiku/haiku/search?q=throwВот например
inline void*
operator new(size_t size, ObjectCache* objectCache, uint32 flags) throw()
{
return object_cache_alloc(objectCache, flags);
}
https://github.com/haiku/haiku/blob/8f16317a5b6db5c672f33181...
Из приведённого вами куска кода ответ на мой вопрос не получить никак.Врочем, действительно, если поискать (для ответа на мой вопрос искать надо конечно в первую очередь `dynamic_cast`, а во вторую `catch`, в то время как наличие/отсутствие `throw` совершенно иррелевантно), то похоже что используется именно то, что называется «C++ без эксепшенов».
Я не вижу какого-либо конкретного вопроса в Ваших сообщениях. Возможно, потому что имею некторое представление, как работают диспетчер исключений и dynamic_cast. throw() это в моём понимании "с эксепшенами" (для kernel/slab/Slab.h сделано, как и должно быть). Их поддержку можно на уровне транслятора отключить.
«C++ с эксепшенами» — это стандартный C++ с RTTI. «C++ без эксепшенов» получается если компилировать с выключенным RTTI. Подход к написанию кода настолько сильно вынужденно меняется в последнем случае, что это практически другой язык. Наличие `throw` в коде (особенно в плане указания что метод не кидает эксепшенов) никак не мешает иметь выключенный RTTI. Другое дело — `dynamic_cast`. Ну и `catch` тоже.
Напишу только по поводу MSVC (у GCC исходники открыты и всё должно быть документировано без меня). Если отключить RTTI, диспетчер исключений никуда не денется и будет выполнять свои задачи, вызывать деструкторы, искать и вызывать обработчик (подходящий окажется с ...). Его следует отключать отдельно, если поддержка исключений не нужна. А подход к написанию кода меняется уже от того, что код в ядре. В ряде случаев бросать исключения никак нельзя, будь то C++ или инструкция int3. И зачем в ядре dynamic_cast<>, где его можно применить, я пока не пойму.
Это знак 😮. С сегодняшнего дня начну учить Rust.
Найду книгу хорошую и начну.
"Rust за 21 час с нуля" или "Rust для тинейджеров" ещё не написали.
> "Rust за 21 час с нуля" или "Rust для тинейджеров" ещё не написали.Жаль, хотя мне всё равно.
Вот с функциональщиной плохо - это может помешать наверно...
А мне лень учить новый ЯП... Я знаю C, буду на нём писать, не зря же учил.
лучше сначала изучите организацию ЭВМ, архитектуру железа и ядра. а потом хоть JS
> лучше сначала изучите организацию ЭВМ, архитектуру железа и ядра. а потом хоть JSУже есть. Только JS не это. Но не хочу как-то 🤷♂
JS как раз клал на жто всё, вместе с теми кто на нем "пишет".
https://doc.rust-lang.org/book/
За 30 лет могли бы лучше Pascal впилить в ядро.
На нём явно поприятнее писать, и дрова в том числе.
Что ты такое говоришь? pascal - это смерть для линукса!
>На нём явно поприятнее писатьСубъективщина же. Я в своё время с радостью свалил с Паскаля на C++, не в последнюю очередь из-за многословности синтаксиса первого. Предполагаю, большинству кодеров больше по душе C-like.
Многословность легко решается редактором/IDE с нормальным автодополнением и сниппетами. Плюс код читается чаще, чем пишется, так что тут от многословности только польза.
Автодополнение видите ли может и ложно сработать, что так то тоже бесит.И это, визуально код с парными скобками и форматированием схватывается лучше чем какой-то текст begin-end который к тому же - цуко - разной длины, что как бы FAIL т.к. блоки кода косые малость получаются. И это не круто.
А смысл? По проблемам человечкого фактора с Си он одинаков.
А синтаксис, помимо многословности, деревянный, логика исполнения неоднозначная.
Помимо begin end, в исходнике ещё круглых скобок требуется заметно больше чем на Си.За одно объявление переменных,там, далеко, где то вначале, неплохо бы автору по пальцам настучать.
Во времена Delphi приходилось переписывать с Си на Паскаль. В итоге получали, более многословный и менее читаемый код, с проблемами из за неоднозначной логики его исполнения. Битовые поля и работа с указателями зерез задницу, плюс куча костыльных пременных.
В общем, выходит только хуже.В принципе, если хочется, драйвер возможно написать и на Паскале и на Си++, но он будет в таком виде никому не нужен.
И... если человек утвержает, что на Паскале __поприятнее__ писать "дрова", то именно драйвера он точно не писал.
Как же вам печёт от begin end и объявления переменных, любо дорого посмотреть. Видимо си правда оказывает какое-то влияние на мышление.>круглых скобок требуется заметно больше чем на Си
Медитируй:
if (!((ch >= 0x0FF10) && (ch <= 0x0FF19)) ||
((ch >= 0x0FF21) && (ch <= 0x0FF3A)) ||
((ch >= 0x0FF41) && (ch <= 0x0FF5A)))Код на паскале сам осилишь.
В С89 объявление переменных было как в Паскале. При этом вложенных процедур там не было, потому и сняли ограничение. И речь тут про ядро, а не холивар языков. В Виндосе некоторые писали драйвера на Дельфи, потом, как правило, переписывали.
Про С89 интересно.Как это не холивар? А что тогда?
У гну кстати прикольное расширение есть для switch-case, с диапазонами. Но, увы, это не стандарт.
>>круглых скобок требуется заметно больше чем на Си
> Код на паскале сам осилишь.Конечно, я знаю про паскалевский case c диапазонами. В данном случае жирный плюс.
Но когда надо перенести батарею подобных и хуже конструкций:
chk_rec( get_iRec() + (i>=1 && i <= 4 ? (const uint32_t[]){ 1500, 600, 65, 8 }[i-1] : 1), skip);То плодятся временные переменные и константы, и раскидываются в разных местах, что от case блока элегантнее не становится.
В том примере прямой перевод if (без всяких case) убирает половину сишных скобок.>подобных и хуже конструкций
Почему-то не удивлён увидеть именно сишный код.
> Медитируй:
>
> if (!(ch >= 0x0FF10 && ch <= 0x0FF19 ||
> ch >= 0x0FF21 && ch <= 0x0FF3A ||
> ch >= 0x0FF41 && ch <= 0x0FF5A))Починил. У автора вашего варианта проблемы с приоритетами операторов, причём явные, раз уж он даже не знает, чей приоритет выше: логического умножения или логического сложения.
А в Паскале, да, надо везде ставить скобки, как вы и написали. Да ещё и вместо &&/|| использовать and/or.
Лучше Modula-2. Тоже паскалеподобная, но получше.
> За 30 лет могли бы лучше Pascal впилить в ядро.
> На нём явно поприятнее писать, и дрова в том числе.Да ну чего в нем приятного, особенно в системщине? Абсолютно все потуги делать на этом системщину выглядели "через ж...у в левый глаз". Чаще всего паскакалистов это задалбывало и они асм вставкой все системное делали, но вот так оно совершенно точно не вперлось.
Это ужасно, "макака-формошлёп"ы, не знающие чем фон неймановская архитектура отличается от гарвардской, добрались до ядра. Так называемые "программисты" на rust окончательно испортят линукс.
Не подскажете куда лучше переходить? FreeBSD, OpenBSD или может быть Mac OS X?
На windows.
Смищно.
> Смищно.А что плохого в этом совете?
Ядро windows не написано на rust, не имеет systemd, pulseaudio, gnome и других подобных нехороших вещей которые ненавидят эксперты с opennet, а значит подходит больше чем Linux
На самом деле да, тоже задумываюсь о том, что винда в итоге может оказаться вполне реальной альтернативой.
Прыгать с одной блоатваре на другую...
Возможно у винды в до кучи будет свой прослоечный форк ядра, не зря же они WSL2 пилят.
Из серьёзных минусов винды сейчас - там всё не просто плохо, а очень плохо с поддержкой сетевых технологий.
Изначально заточились на оффлоуд всего "лишнего", вплоть до VLAN, на сетевые платы, а оффлоуда у вендоров не случилось. В итоге чтобы банально несколько вланов принять - нужно плясать с бубном через HyperV ныне.
(под оффлоудом в данном случае понимается не собственно процессинг пакетов, который кстати местами есть, а именно возможность конфигурации данных функций, некоторые драйверы умеют, некоторые нет)
Windows гораздо больше подходит для open source чем Линукс, так как для винды больше свободных программ.
Чичиго?
Не свободных, а бесплатных. Свободная - это открытый код под лицензиями GPL, BSD, MIT и т.д.
Человек правильно написал - свободных. На том же sourceforge полно вещей с gpl, bsd, mit и так далее, но при этом они писались под winapi, а не под posix. Ну а если учесть что всякие зондофоксы, псевдолиброфисы и прочие vi с awk под винду портированы ещё с незапамятных времён, то линупcу гордиться особо и нечем
А можно два-три выдающихся примера? Таких программ, исходники которых под свободными лицензиями, и которые писались под winapi? То, что под winapi есть порты обычных линуксовых программ - и так понятно.
FAR bro :)
notepad++, mpc-hc
Вот это хорошие примеры, но для них есть FOSS аналоги. Все эти разговоры о свободе внутри проприетарной шиндошс, ну такое. FAR вообще не понимаю для кого сделан, никогда им не пользовался.
Нет в линупce аналогов. Есть жалкие пародии. Например большинство виндовых видеоплееров умеет показывать превью видео при наведении мыши на нужный момент времени без перемотки этого самого видео. Какие линупcячьи плееры так могут? И у небезызвестного mc от того же FAR хорошо если треть функционала есть (а если FAR обвесить плагинами, то на mc без желания обнять и плакать вообще смотреть не получится).
> у небезызвестного mc от того же FAR хорошо если треть функционфала
> есть (а если FAR обвесить плагинами, то на mc без желания
> обнять и плакать вообще смотреть не получится).Вообще, FAR и под линукс нынче есть... довольно своеобразный, но все же. А так - простите, но если в линухе мой проект втрое быстрее компилится, может и черт с ним с фаром, при таком раскладе и миднайт сойдет. А плагины ставить... тоже мне миранда им очередная.
Тем более что миднайт я могу даже на вон том роутере-мыльнице запустить, по ssh. Попробуй так с фарой, особенно в винде. В этом месте мы и понимаем прелесть *никсной консоли: универсальный и очень нетребовательный тул. Лезущий по сети с минимальными требованиями, по неспешным сериальным шнуркам, а по сути всему что отдаленно напоминает коммуникационный канал, даже неторопливый и базовый. А траблшутинг какой-нибудь винды которая не взлетает это вообще например очень отдельный вид жэсти. И в лине - только подумай - миднайт запустится в лысой консоли в single user mode и поможет по ФС при отскребании системы от асфальта навигировать. А в винде ... ну фар ты явно при проблемах такого уровня уже не запустишь.
Старый Free Download Manager (линупcoвый ныне мертвый d4x - жалкая пародия на него), миранда (которая не ng) со всеми ее плагинами, уже упомянутый FAR, SP Forth и так далее
Миранда для чего-то пригодна в 2022?
> Миранда для чего-то пригодна в 2022?Гм, эту стюардессу оказывается откопали - см. соседнюю новость.
Хорошо, софта накидали. Правда он для каких-то дедов, ну ладно.
Но если шиндоуз такой хороший, почему мне не хочется возвращаться? Просто интересно.
И Wayland, и snap, и flatpack, и hig
Все эти плохие программы отсутствуют на винде, а значит она лучше
Толсто.Windows сама по себе Зло!
> Это ужасно, "макака-формошлёп"ы, не знающие чем фон неймановская архитектура отличается
> от гарвардской, добрались до ядра. Так называемые "программисты" на rust окончательно
> испортят линукс.
> Не подскажете куда лучше переходить? FreeBSD, OpenBSD или может быть Mac OS
> X?Если Linux совсем загрётся и не будет новых вменяемых альтернатив, лично я ливна на опёнка, т.к. Тео не ср@ный толерастный смузибой-макакокодер, а суровый мужик старой закалки с правильным здравым подходом к ненужному.
>BSDМожешь попробовать.
> Mac OS X
Нет.
>Не подскажете куда лучше переходить? FreeBSD, OpenBSD или может быть Mac OS X?HaikuOS!
DragonflyBSD
То, что вы, по-видимому, имеете в виду, называется «DragonFly BSD». С пробелом перед «BSD» и большой «F». И там всё довольно плохо с драйверами для видеокарт.
Я на FreeBSD дано. Потому что это единственная ОС (а не набор пакетов), в свободном мире.
Ждем дополнения в виде Golang и Ziglang
Эти с флагами не ходят и всюду не пихают, полноценные люди. И в мазилла фондашион лидера-гетеросексуала не смещают.
В этом вся суть так называемых программистов на rust
Они не в состоянии понять архитектуру компьютера и систем, но лезут в ядро со своим так называемым системным, так называемым безопасным языком.
Зато местные критики - эксперты во всём: в архитектуре (могут написать 10 строчек на асме и знают про кэш), компиляторах (прочитали названия глав в книге с драконом), теории типов (лучший тип - void*), проектировании языков программирования (Rust - плохо, там закорючек много, а вот Pascal - норм, там слова) и телепатии ("они не знаю то", "они не знают это"). При этом свой код не показывают, потому что достигли просветления и поняли, что лучший код - это его отсутствие.Ну, экспертами они видят себя в зеркало. А со стороны больше напоминают потенциальных обитателей психиатрического стационара. Сами-то, поди, в ядро ни строчки не написали за всё время использования Linux, но ни дай бог там кто-то хоть строчку на Rust напишет - всё, конец света, тролльвальдс скатился, луникс пропал, валим на BSD. Ой, а там всё по-другому, разбираться надо, а ещё дров не хватает, бежим назад. Точно так же до этого верещали про systemd, хотя сейчас посади их за дистр с классическим инитом и скриптами - начнутся "вьетнамские" флэшбэки.
Специалисты по архитектуре бреда в комментариях.
> местные критики - эксперты во всёмНу так и есть, а что плохого-то? Это вы там в своём загончике пасётесь. Барин сказал systemd, значит systemd. Барин сказал rust, значит rust. Барин сказал, что нужно анализы сдавать, пошли сдавать. Всё для вашей же безопасности, главное не бухтеть, нужно немного подождать и уже скоро будет коммунизм. А пока вот котлетки на ужин.
Вам повезло, что эту информацию тут можно почитать.
Чет не сильно удобно сидеть под одним ником
Какой ещё барин? Никто никого не заставляет учить Rust, я вот учил по собственному желанию, т.к. нравятся языки ML-семейства и borrow checker. И даже пользоваться Systemd никто не заставляет, дистрибутивов Linux - гора и маленькая тележка. Мне как пользователю Systemd не мешает, конфигурация намного проще, чем с инит-скриптами, система грузится быстрее.Вы - не эксперты, а демагоги с раздутым самомнением и синдромом Даннинга-Крюгера. И то, что вы здесь генерируете - не информация, а информационный шум. На весь Опеннет хорошо если с десяток толковых разработчиков наберётся из активно комментирующих, результаты работы которых можно посмотреть в опенсорсных проектах, а остальные только и могут, что хамить, безосновательно критиковать и рассказывать сказки про то, как они без ошибок пишут на C чуть ли не для космических аппаратов. Невоспитанная школота, начитавшаяся умных книжек, но без критического мышления, которая возомнила себя экспертами.
> Я - хороший, это они плохие!Понятно.
burjui не написал что он хороший.
Ваш комментарий нужно в рамочке повесить над формой отправки сообщения
> сказки про то, как они без ошибок пишут на C чуть
> ли не для космических аппаратов. Невоспитанная школота, начитавшаяся умных книжек, но
> без критического мышления, которая возомнила себя экспертами.И тем не менее полно софта, в том числе и для космоса, писаного на си. А на эмбедовке без MMU хруст так то даже от элементарного переполнения стэка не защищает, внезапно.
Конечно, лучшая часть человечества совершенствует себя, а худшая совершенствует механизмы сопутствующие лени и ничего не деланию. Все реально видят куда это идет и даже фильмы снимают, про катострофически отупeвшее человечество. А вообще, конечно, каждый должен заниматься своим делом, нет наклонностей к программированию, не можешь элементарные "загибы" алгоритма просчитать катись в другую отрасль.
Golang - не системный язык с GC, не подходит.
Почему не добавить GC в ядро?
В принципе, есть экспериментальные реализации OS на Go. Это возможно, но вряд ли целесообразно. Хотя практика и эксперименты буйных голов покажут.
> Почему не добавить GC в ядро?Да их там есть даже, несколько разных. Только вот в игого он вообще везде и хрен от него отделаешься. Это ведет к патологическим случаям когда под нагрузкой он начинает делать черт знает что. О чем фуксики из соседней новости и узнали, чего-то полюбив хруст и чуть не плюсы.
А, самое стебное? Хруст почему-то у них можно в системщине но для приложух не заявлено. Логика.
Интересно, создатель Rustа это ж один из, трех что-ли, челов, которые в каком-то там институте делали проект безопасного надмножества C. Чому тот C не взлетел, чому на нем не пробовали писать для ядра, может постепенный переход с простого C на "не простой" а потом уже когда-нить на Rust было б проще воспринимать, хм.
Ты думаешь, тебе будут делать безопасные языки, приносить прямо в руки, пиарить на весь интернет, только возьми? Как это должно работать, по-твоему?
> Ты думаешь, тебе будут делать безопасные языки, приносить прямо в руки, пиарить
> на весь интернет, только возьми? Как это должно работать, по-твоему?Zig и Hare ... примерно как-то так и образовались. А чего в этом такого?
Интересая новость. Вот недавно Линус разрешил-таки наконец использовать С11. Через 11 лет после появления стандарта.Отсюда вопрос. Какая версия rust будет доступна в ядре?
Ты новость читал? Прочитай с места> Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке Rust. Не исключается, что патчи с поддержкой Rust будут приняты в ближайшем окне приёма изменений, формирующем состав ядра 5.20...
И? Какая версия rust?И как часто ее можно будет увеличивать?
По факту наличия стабильной версии наверняка и главное есть кому поддерживать, иначе финн бы не одобрил. Парагонцы же чуть обгадились ливнув в запой понадеясь на сообшество тысячаглаз. D В любом случае ядро очевидно форкнут в стиле нераст-кернел. рейзер4 кернел же есть и прекрасно себя чухает.XD
> По факту наличия стабильной версии наверняка и главное есть кому поддерживать, иначе финн бы не одобрил.Насколько я понимаю, он на данный момент смотрит только на "возможна ли хоть какая-то польза". На инфраструктуру внимания не обращал.
Хотя, конечно, учитывая опыт использования системы контроля версий, я был бы за такой вариант.
Посмотреть как и что, и запилить свое без cargo и бабочек.
>чухает.Переведи.
>И? Какая версия rust?Модная, модная.
> И? Какая версия rust?Ночнушка последняя поди, как обычно. В релизных видите ли много тупняков для того чтобы кернел ими билдовать.
> Использование Rust для разработки драйверов позволит с минимальными усилиями создавать безопасные и более качественные драйверы, избавленные от таких проблем как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера...Эта мантра также обязательна в любом тексте про Rust как и "<Организация> запрещена на территории РФ"?
Фанатики, сэр.
Фанатики - за идею. А тут за бабосы слухи распространяют, ой, "новости о не исключении возможности" пишут. Хотя, деньги - это тоже идея.
> обязательной инициализации значений переменных перед использованиемА разве может быть иначе?
Конечно, те же пгавославные С, С++.
Конечно. Инициализация - для слабаков. Настоящие мужики пишут такой код, который правильно работает даже со случайным мусором через нулевые указатели.
Обязательная инициализация означает необходимость тратить время процессора и память на ненужную оптимизацию переменных. Для системного программирования, где важен каждый такт, она неприемлема.
> Обязательная инициализация означает необходимость тратить время процессора и память на
> ненужную оптимизацию переменных. Для системного программирования, где важен каждый такт,
> она неприемлема.И поэтому в Rust есть переменные типа `MaybeUninit`. (Для которых, разумеется, также обязательна инициализация, но она не тратит время процессора и память (если использовать для инициализации значение `MaybeUninit::uninit()`.)
Какой ужасный синтаксис
> Какой ужасный синтаксисИменно синтаксис здесь плюсовый. И что в нюм ужасного? Двойное двоетчие? А `MaybeUninit`, `uninit` — это не синтаксис, это просто идентификаторы, имя типа и тмя метода.
В плюсовом? Да примерно всё, если взять не самый простой для парсинга синтаксис C (потому что контекстно-зависимый и не всегда однозначный), щедро обмазать абсолютно ортогональным синтаксисом темплейтов, а сверху ляпнуть новых фич C++11 и далее, с, как обычно, изобретённым заново синтаксисом для конструкций - вряд ли найдутся люди, которые осознанно и добровольно будут на нём писать и не плеваться."Синтаксис не важен!", скажут многие, окей, если синтаксис неважен, то почему его нельзя было сделать проще?
> Обязательная инициализация означает необходимость тратить время процессора и память на
> ненужную оптимизацию переменных.Если переменная в памяти, память "потрачена" независимо от инициализации.
Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения, т.е. в общем случае работать будет быстрее.> Для системного программирования, где важен каждый такт,
> она неприемлема.
> Если переменная в памяти, память "потрачена" независимо от инициализации.А вот это - совсем не факт. Оптимизатор может все пох@рить в ноль если видит что side effects от этого ровно ноль. И кода не будет вообще. И данных тоже. С железным аргументом "а если не видно разницы, зачем генерить больше?"
> Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения,
> т.е. в общем случае работать будет быстрее.С чего бы это вдруг такие гарантии вот так безаппеляционно?
>> Для системного программирования, где важен каждый такт, она неприемлема.
С другой стороны факапнуться с uninitialized variable в нем тоже так себе радость. Особенно когда все работает но раз в месяц почему-то палка все же стреляет.
>> Если переменная в памяти, память "потрачена" независимо от инициализации.
> А вот это - совсем не факт. Оптимизатор может все пох@рить в
> ноль если видит что side effects от этого ровно ноль. И
> кода не будет вообще. И данных тоже. С железным аргументом "а
> если не видно разницы, зачем генерить больше?"Так я описал худший случай, поскольку отвечал на: "Обязательная инициализация означает необходимость тратить время процессора и память на ненужную оптимизацию переменных".
>> Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения,
>> т.е. в общем случае работать будет быстрее.
> С чего бы это вдруг такие гарантии вот так безаппеляционно?Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет прочитана), а потом кеш скидывается в ОЗУ. А если нет записи, тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе придётся ждать.
> Так я описал худший случай, поскольку отвечал на: "Обязательная инициализация означает
> необходимость тратить время процессора и память на ненужную оптимизацию переменных".Не уверен что это настолько уж масштабная проблема.
> Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет
> прочитана), а потом кеш скидывается в ОЗУ. А если нет записи,
> тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе
> придётся ждать.У нормальных людей инициализация переменных не настолько частая чтобы это было проблемой. Более того - при генерации кода компилер вообще может целиком заинлайнить все. При том возможно что 90% нужного уже было в других регистрах.
А с каким-нибудь LTO зависимость вообще нелинейная. Иногда казалось бы более плохой код генерит более короткий и резвый код. В чем прикол? А вон там глобальному оптимизатору константы лучше легли. С ним вообще приходится эмпирически, на конкретном коде подбирать :). Но он круто лишнее выпиливает. Может треть кода аннулировать без какого либо изменения скорости или логики. И вот тут оно стоит того чтобы погреть проц при компиле, как минимум релизной версии.
>> Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет
>> прочитана), а потом кеш скидывается в ОЗУ. А если нет записи,
>> тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе
>> придётся ждать.
> У нормальных людей инициализация переменных не настолько частая чтобы это было проблемой.Это всё субъективно. Вон то про кеш - оно не зависит от наших убеждений. То есть инициализация переменных оправдана, как оптимизация по скорости. :)
Пока в Вилларибе дрочат на такты и дебажат код в поисках мемори лика, в Виллабаджо уже завезли многопроцессорность.
> Пока в Вилларибе дрочат на такты и дебажат код в поисках мемори
> лика, в Виллабаджо уже завезли многопроцессорность.Если ты так развлечешься в кернеле, вероятно, ты еще и не так потом будешь др@чить в дебаге внезапно падающего кернела.
>Поддержка Rust преподносится как опция, не активная по умолчанию и не приводящая к включению Rust в число обязательных сборочных зависимостей к ядруНиштяк. А то этот пакет в генте иногда напоминает маньяка своим упорным стремлением прописаться в мир.
Это ж линуксоиды. У них даже HDCP какой - опция. Хочешь жрать DRM'о, включаешь. Не хочешь - отруби и собери кернел как тебе больше нравится. Этим линуксоиды и хороши.
Нафиг раст? Надо просто пользоваться при разработке прог интерфейсами, которые менеджатся компилятором, а так же завести в православный си/си++ аналог фастмм, чтобы утечки памяти искал и доступ к освобожденной памяти. А то пишут на каких то языках из прошлого века и все время жалуются, что память течет и уязвимости на каждом шагу.
> Нафиг раст? Надо просто пользоватьсяПользуйся. А другие программисты будут пользоваться тем, что они считают более полходящим.
Вот что же все разрабы ядра такие тупые и за столько лет не догадались это сделать...
И тут пришел анон с опенька и все разложил по полочкам!
Ну так и есть, анон умный.
Там, где начинаются ненужные слои абстракции и ненужная забота о чрезмерной безопасности, там заканчивается быстродействие и качество кода. Жаль что Линус стар и ему уже все равно.
Да, C давно пора выкинуть в окно как ненужную прослойку.
Печально, что у Линуса не осталось больше аргументов, чтобы не допустить прохода экспериментального языка в промышленный проект.
Ага, ты небось до сих пор плёночным фотоаппаратом пользуешься, и почту лошадьми гоняешь? Не пользоваться же всеми этими экспериментальными технологиями.
Аналогия не твой конёк.
> плёночным фотоаппаратомНе поверишь, до сих пор есть студии проявки киноплёнки... Да, её используют профессионалы.
Таки почти все вымерли кроме очень специальных случаев, перейдя на цифру. Конечно, профессиональную и за совсем другие деньги. Как угодно но в цифре потом редактировать например куда как лучше.
Я так понимаю, ты из тех, кто уже купил электрокар с автопилотом и во время езды ...книжки читает?
Ты хочешь сказать что индусам из мелланокса, которые из сетевого драйвера общий slab портят, доверия больше?
> Ты хочешь сказать что индусам из мелланокса, которые из сетевого драйвера общий slab портят, доверия больше?Такие виды ошибки лекго отлавливаются.
Проблемы компиляторов, или если копнуть чуть глубже - поломкой совместимости в процессе их разработки, - практически не отлавливаются в таких сложных проектах.
Для их отлова нужно интенсивное использование в других - более простых проектах.
Отсюда вопрос, сколько времени должно будет пройти пред внедрением новой версии компилятора rust в ядро, если он практически нигде не используется?
> Такие виды ошибки лекго отлавливаются.Супер, отлови пожалуйста. А то её уже полтора года отловить не могут. Стектрейс скинуть?
Ты код ядра видел вообще? Там говно и костыли на каждом шагу, экспериментальный язык хуже уж точно не сделает.
Тсс, ты чего? Не разбивай хрустальные фантазии онанимов. И вообще, развели тут плюрализм... Одно ядро, один лидер, один язык! Seg fault!
> Ты код ядра видел вообще? Там говно и костыли на каждом шагу, экспериментальный язык хуже уж точно не сделает.Это ты так решил, что не сделает? И какие у тебя для таких заявлений основания?
Пруфов, как всегда не будет, да?
О, пруфов будет предостаточно. С какой подсистемой ты лучше знаком?
Пропала переносимость, пропал калабуховский дом.
И почему нельзя назвать новую версию 6.0 из-за новой функциональности? Или старый пердун опять будет ждать, когда моча в голову стукнет?
Новость про возможное прикручивание Rust. Соответственно, новая функциональность на его основе в ядре отсутствует.
Будет теперь инклюзивное ядро.
Бодипозитив.
Это конец.
> не исключил возможностьЭто надо срочно в новость!
Это начало конца...
Почему в ядро Linux включают именно:
протекающий, ненадежный, неверифицируемый Rust,
a не безопасный, надежный, верифицируемый SPARK
?!!
Вам ответить отвлечённо или прагматично?Потому что на Rust приятно писать код. А на SPARK упорешься. Потому что Rust как современный язык отвечает требованиям, предъявляемым современному языку (репозиторий пакетов, вменяемая система сборки, избавление программиста от обезъяньей работы вроде копипаста заголовков методов в интерфейсную часть модуля, и др.), а SPARK — штука древняя. Потому что Rust целенаправленно создавался и создаётся под подобные задачи, и из коробки имеет достойный FFI с Си.
Потому что есть инициативная группа (и более широкая масса менее инициативных сочуствующих), желающая видеть Rust в ядре, а для SPARK такой группы не собралось.
> репозиторий пакетов, вменяемая система сборкиПрямо перечислил априори не нужное
> избавление программиста от работы головой
Фиксанул, не благодари
>> избавление программиста от работы головой
> Фиксанул, не благодариКак что-то плохое. Хотя страх всяких сишников можно понять, ведь повторяется история с станками жаккара.
Сишники видите ли обычно системщики. А это свободный и гордый народ, знающий себе цену. Предпочитающие некую автономию и самодостаточность, без лизания ботинок гугла, майкрософта и амазона. А ваше светлое будущее с лизанием ботинок вон тем - выглядит довольно так себе.Ага, репы контролирует "некомерческий" фаундейшн с некоммерческими директорами из амазона, гугла и майкрософта. И вот это уже выглядит как годная заявка на сдачу им в рабство. Почему-то. Хотя белый человек так то давно просек что папуас на бусы ведется и активно пользовался...
> Потому что на Rust приятно писать код.Ну ты и Петросян!
Я понимаю, что хаскелистам смешно, да. Но мне на Rust приятнее во всех отношениях и проще. Хотя Хаскелл в чём-то удобнее, я согласен.
Потому что ядро --- важный и значимый ресурс. Подмять его под себя через инфраструктуру, средства разработки или как ещё --- очень логичная стратегия.
Пфф, а то, что ядро написано на протекающем, ненадёжном, неверифицируемом C, тебя не смущает? Нужно срочно переписать ядро на SPARK! Ну как срочно... на это уйдёт лет 100, учитывая многословность синтаксиса, а также сколько бойлерплейта и контрактов придётся писать к каждой функциональной строчке кода. Код будет в 10 раз больше и никому не нужен, но зато абсолютно безопасен и надёжен. Впрочем, любой код будет абсолютно безопасен, если его не запускать.
s/SPARK/Rust/gИ что, что-то по сути поменялось в месседже?
Если думать не головой, а задницей, то нет.
> Если думать не головой, а задницей, то нет.Ну так покажи эту разницу тем, кто думает задницей...
Или ты то же из таких?
А то! 4.332
Я уже задолбался кому-то что-то объяснять на этом ресурсе. Тем более бессмысленно объяснять что-то тем, кто думает задницей. Никто даже документацию прочитать не в состоянии, не то что попробовать написать что-то более-менее сложное на языке перед тем, как гадить в комменты про "вырвиглазный синтаксис" и прочую чепуху. Сами идите, пишите на обоих языках, а потом сравнивайте объём кода, трудозатраты и КПД своей работы. А заодно подумайте, почему ни один из формально верифицируемых языков даже близко не пошёл в массы.
Не нужно ничего объяснять, лучше расскажи, почему ни один из формально верифицируемых языков даже близко не пошёл в массы. Послушаем умного человека.
Потому что на них, внезапно, сложно и долго писать. Или ты думал, что там просто компиляторы очень умные, сами угадывают твои намерения, и верификация даётся бесплатно? Чтобы верифицировать твой код, ты сначала должен опписать критерии верификации - то есть, "контракты" в терминологии SPARK. И тебе придётся каждую строчку кода обложить пачкой контрактов, далеко не всегда тривиальных, и тебе это очень быстро надоест, потому что успеешь постареть, пока напишешь хоть какой-то функционал. Для космических аппаратов и ядерных электростанций это приемлемо, а для менее критичного софта - нет. Никто не будет ждать 2 года, пока ты напишешь супернадёжный медиаплеер. И даже SPARK не защитит от логических ошибок, пока контракты пишет человек.
Ответ: массового заказчика нет.SPARK уже занял свою нишу. Заказчик должен платить за надежность, безопасность и верифицируемость ПО.
Есть надежная, безопасная и верифицируемая ОС: https://muen.sk
Кажется стандарт в гражданской авиации. Даже в РФ бортовое ПО на ADA-SPARK пишут?
Кроме атомной энергетики, военные SPARK любят в своих АСУ.
Сегодня просто уникальный исторический момент. Прошло около 45 лет со дня заказа разработки этого языка программирования, сменилось несколько поколений программистов и на конец в GNU смогли написать свободный компилятор RUST. Вхождение в мир надежного, безопасного и верифицируемость ПО стоит не десятки миллиардов долларов, а 0.0$
Я категорически против зоопарка. Убежден, что Linux должен писался на C и ASM, как это было изначально. А добавление любого другого языка в ядро Linux только запустить его, затруднит поддержку и использование. А конкретно Rust вместо безопасности добавит новые классы уязвимостей.
>Вхождение в мир надежного, безопасного и верифицируемость ПО стоит не десятки миллиардов долларов, а 0.0$Из крайности - в крайность. Типичный опеннетный эксперт.
>0.0$Это если не писать контракты в том же SPARK. Правда, тогда и код не скомпилируется. А контрактов придётся писать больше, чем кода. Так что совсем не 0$.
> А конкретно Rust вместо безопасности добавит новые классы уязвимостей.На каком основании вы сделали такой вывод?
>> А конкретно Rust вместо безопасности добавит новые классы уязвимостей.
> На каком основании вы сделали такой вывод?Новый язык, другой компилятор, от других людей, новые дыры:
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
https://www.developer-tech.com/news/2022/jan/24/rust-vulnera.../
Намного усложнитса поддержка и аудит кода.
И это еще не те новые классы уязвимостей которые я иметь ввиду.Вся модель безопасности ОС держится на правеле: что исполняется не должно изменятся, а что изменяется не должно исполнятся (согласовано учеными конца 1960-тых и принято в стандарт 1983). В помощь инструкции проца NX, PAE.
С этого следуют требования к защите памяти:
CONFIG_PAX_MPROTECT=y
- changing the executable status of memory pages that were
not originally created as executable,
- making read-only executable pages writable again,
- creating executable pages from anonymous memory,
- making read-only-after-relocations (RELRO) data pages writable again.ОС в которых эти требования не соблюдаются, не имеют правильной защиты памяти и есть уязвимы.
Рассуждения: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Executable code and read-only data must not be writable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Any areas of the kernel with executable memory must not be writable. While this obviously includes the kernel text itself, we must consider all additional places too: kernel modules...
Это же относится и ко всему прикладному ПО без исключений и копромисов на JIT, PBF, ... и прочью дрянь. Принципиальный вопрос о толерантности к Rust, в прикладном ПО, зависит от строгого следования этим правилам.
Вы так и не привели ни одного примера "новых классов уязвимостей", которые якобы привнесёт именно Rust.
> Вы так и не привели ни одного примера "новых классов уязвимостей", которые
> якобы привнесёт именно Rust.Кодер подумал что безопасТно и забил на использование мозга. Маркетологи гамадрила корп сказали же что безопасТно!
Зато голословно заявлять про какие-то мифические "новые классы" (что мля?) уязвимостей - это явный признак полного использования мозга. Жаль только, что мозг используется, а результат такой, как будто нет - получается, энергия расходуется впустую. "безопасТно", "гамадрила корп" и прочие "хрусты" - это всё, на что способен мозг типичного хейтерка с Опеннета, потому что он ещё не окончил школу, но зато уделал одноклассников на уроках информатики своими обширными познаниями в разработке на Turbo Pascal и C, на котором он не делает ошибок, потому что ничего не пишет.
Не голословно. Для GNU/Linux придется использовать этот компилятор Rust: https://www.opennet.ru/opennews/art.shtml?num=57491 стандартный компилятор добавит новые классы уязвимостей.
Как может данная прослойка обеспечить безопасность, если у нее 70% кода unsafe? Т.е фактически, будет вызываться из безопасного кода, небезопасные функции из прослойки. Да о чем можно говорить, когда этому подтверждение недописанный драйвер android от гугла.
Если моя логика абсолютна не верна, то как тогда?
Там продвигаются более интернсные вещи, хотя на них обращают внимание сильно меньше. Это
- сборочная система
- легкий update компилятора
- пакетная система с автоподгрузкой из сетки by demand в процессе сборкиДемпфировать это, в принципе, можно, но en masse это неустранимо (см. npm, pip, доустановка deb-пакетов на лету в CI, аналогичное подтягивание docker'ов, ...).
> пакетная система с автоподгрузкой из сетки by demand в процессе сборкиЭто смерть безопасности.
> - сборочная системаЛизать ботинки гугла, амазона и майкрософт с их Единственно Правильной Экосистемой - вообще баг а не фича.
> - легкий update компилятора
Безопасным curl | sh? :) Где ремотным джентльменам верят на слово.
> - пакетная система с автоподгрузкой из сетки by demand
> в процессе сборкиОчень безопасно и совсем не лижет корпоративные ботинки упомянутой троицы. И совсем не разводит левый мусор в системе.
Как же вы достали уже с этим, сил нет... Неужели самим непонятно, что любой потенциальный косяк работы с памятью будет локализован в этих блоках unsafe? Весь остальной код гаратированно ни при чём. А это значит, что аудит на предмет некорректных обращений к памяти (а это основной источник уязвимостей, особенно с получением root доступа) нужно проводить только для unsafe блоков. Никто и никогда не обещал полной безопасности обращений к памяти при наличии unsafe кода, однако локализация небезопасных операций в соответствующих блоках очень сильно сужает область поиска потенциальных и актуальных багов. Практически невозможно, даже тысячей глаз, прочитать миллион строк кода и найти там все переполнения буфера и т.п.. С 10к строк это сделать гораздо проще.
> косяк работы с памятьюПроблемы квалификации программиста, а не языка как такового. Хотя, глядя на то что творится в IT и какие макаки-гуманитарии туда идут, за будущее не страшно, т.к. выдумки о скайнете так и останутся выдумками.
По твоей логике в мире нет ни одного квалифицированного программиста, потому ошибки совершают абсолютно все.
> Проблемы квалификации программиста, а не языка как таковогоА вот и снова мантры про прямые руки. Только не сильно-то они помогают, раз то в одном, то в другом сишном поделии ошибки с памятью обнаруживаются.
> Неужели самим непонятно, что любой потенциальный косяк работы с памятью будет локализован в этих блоках unsafeТебя обманули и ты вводишь в заблуждение других.
В ядро Linux, уже очень давно, лет 20 как, можно компилятором gcc собрать безопасно:
гарантии безопасной работы с памятью получить МОЖНО!!!
гарантии надежности НЕТ.
автоматической математической верификации корректности на уровне исходныых текстов НЕТ.Гарантии безопасности работы ядра Linux с памятью:
config_pax_kernexec
config_grkernsec_randstructБезопасность работы с памятью в ядрах некоторых UNIX, Linux, NetBSD, частично OpenBSD уже есть! И все на C. Она достигнута логически следуя правилу: все, что исполняется не должно изменятся, а что изменяется не должно исполнятся. Используя инструкции процессоров (постранично) или даже полностью софтварно (посегментно). Эксплуатация переполнения буфера невозможна! Цена использования C: невозможность дать гарантии надежности при дачи гарантий безопасности работы с памятью.
Еще одна большая сакральная тайна которую пропагандисты Rust скрывают, чтобы вас всех обмануть:Ядра некоторых UNIX, Linux, NetBSD, Apple OS X, частично OpenBSD и MS Windows дают гарантии безопасной работы с памятью для всего прекладного ПО! Даже, для того, что написан на дырявом C и текущем Rust:
Для Linux включите опции ядра:
config_pax_noexec
config_pax_pageexec (надеюсь ваш проц инструкцию NX держит)
config_pax_mprotectИ получаем гарантии безопасности и корректности работы с памятью сразу всего прикладного ПО, на любом языке программирования, собранного любым компилятором!!!
Цена: нет гарантий надежности. В авиации, атомной энергетике, ... необходима надежность.
Ни Rust ни C надежности и верификации вам не дадут.
>> Неужели самим непонятно, что любой потенциальный косяк работы с памятью будет локализован в этих блоках unsafe
>Тебя обманули и ты вводишь в заблуждение других.Аргументы будут или пука в лужу, по вашему мнению, достаточно?
>все, что исполняется не должно изменятся, а что изменяется не должно исполнятся.
Такой способ безопасной работы с памятью не бесплатен, а имеет накладные расходы во время выполнения кода, в отличие от статической верификации.
> Аргументы будут или пука в лужу, по вашему мнению, достаточно?В луже с растом сейчас сидишь ты.
Аргументируют:
config_pax_noexec
config_pax_pageexec (надеюсь ваш проц инструкцию NX держит)
config_pax_mprotect
config_pax_kernexec
1. Дает гарантии корректной и безопасной работы с памятью ядра Linux и всего прикладного ПО не зависимо от язака написания и используемого компилятора.2. Накладные расходы при постраничной проверке памяти равны 0 для следующих архитектур процессоров: alpha, avr32, ia64, parisc, sparc, sparc64, x86_64, i386 и старше с поддержкой инструкции NX. А для ppc, ppc64 накладные расходы мизерны.
Прочти в учебнике раздел о "Проактивной защите".
И всем обратить внимание на РЕАЛИЗАЦИЮ защиты пямяти в разных ОС.
Правильная защита памяти: Linux+PAX, NetBSD, Apple OS X, ...
Не правильная защита памяти: OpenBSD, MS Windows, ...
>Накладные расходы при постраничной проверке памяти равны 0 для следующих архитектур процессоров: alpha, avr32, ia64, parisc, sparc, sparc64, x86_64, i386 и старше с поддержкой инструкции NX.Здесь был неправ, признаю.
Тем не менее, от некорректного обращения к памяти эта технология не защищает. Она защищает от последствий некорректного обращения к памяти - то есть, вместо того, чтобы дать прочитать мусор или переписать адрес возврата, сгенерирует аппаратное исключение, а ОС, скорее всего, грохнет процесс. То есть, код по-прежнему может попытаться прочитать мусор или переполнить буфер, после чего упасть. При статической же проверке некорректных обращений к памяти вовсе не будет.
> Тем не менее, от некорректного обращения к памяти эта технология не защищает. Она защищает от последствий некорректного обращения к памяти - то есть, вместо того, чтобы дать прочитать мусор или переписать адрес возврата, сгенерирует аппаратное исключение, а ОС, скорее всего, грохнет процесс. То есть, код по-прежнему может попытаться прочитать мусор или переполнить буфер, после чего упасть.Там есть разные варианты в разных ситуациях:
1. Не убивать процессы, а только логировать ошибки.
2. Убивать процессы и логировать ошибки.
3. Убить ВСЕ процесы пользователя, запретить создание новых и логировать ошибки.
4. При угрозе изменения логов с ошибками, убивать все процесы и само ядро ОС, для сохранения лога.
> При статической же проверке некорректных обращений к памяти вовсе не будет.
Аккуратный Сишник, имея неизменненный лог ошибки проги, быстро подправит косяк при обращении к памяти и выпустит патч с "закрытием очередной сишной дырени". Все патч наложат и в этом месте "плазма" уже падать не будет.
Заметь, технология практичной защиты, обеспечила гарантии безопасности ОС, не допустила эксплуатации некорректного обращения к памяти, и способствовала передачи в логах необходимой информации программисту, для локализации и устранения ошибки в программе. А вот надежности работы программы не дает!
> А вот надежности работы программы не дает!И правильно, кому она нужна? Главное - уязвимостей нет, а то что прога падает - так это проблемы пользователя, поэтому будем фанатично упираться и продолжать писать на C. Лучше пожертвуем пользователем, но на Rust принципиально писать не будем.
> уязвимостей нет,Уязвимость есть они никуда не денутся. Криворукий сишник таки ошибку сделал. Благодаря проактивной защите реализованной в ОС и процессоре, бажную прогу убили и записали лог о ошибке.
> а то что прога падает - так это проблемы пользователя,
Да. Сишники, когда им лог падения высылаешь и пальцем показываешь на баг, иногда с патчем, так и говорят,- да пошли вы со своими проблемами и вашей "проактивной защитой"...
> на Rust принципиально писать не будем.
Я стал противником go и по инерции Rust когда увидел список зависимостей к ipfs, при компиляции мне с инета начало тянуть >1200 никем не подписаных пакетов. Также считаю Rust в ядре Linux неуместным, пусть оно остается на C и ASM.
Узри саму убогость и ущербность идеи Rust иметь частичную (ибо есть unsave) проверку во время сборки только для одной программы написанные на Rust, по сравнению с глобальной гарантией корректности и безопасности работы с памятью всех программ без любых исключений (включая даже блоки unsave) от ядра ОС и процессора. И без любых накладных расходов для x86_64.Вас обманули и повели по неверному пути. Вы пытаетесь, частично, защитить программу, когда уже как 30 лет всем доступна технология защиты памяти всразу всех программ без исключений!
Незыблимый принцип безопасности:
ГАРАНТИИ защиты и корректности работы с памятью дает ядро ОС с процессором. А не аккуратность програмиста, продвинутость компилятора (хотя это тоже очень важно) или какой-то очередной ЯП.
Да, у технологии Проактивной безопасности есть цена - отсутствие гарантий надежности работы программы. И на сегодня единственным рабочим вариантом дающим математически доказанные гарантии надежности и безопасности на уровне исходных текстов есть - SPARK.
Прочитай мой комментарий ниже со ссылками на код Muen. Надеюсь, я там наглядно показал, чего стоят "гарантии надёжности и безопасности" SPARK, которые по принципу идентичны гарантиям Rust.Даже на главной странице написано:
SPARK is a software development technology specifically designed for engineering high-reliability applications.
It consists of a programming language, a verification toolset and a design method which, taken together, ensure that ultra-low defect software can be deployed in application domains where high-reliability must be assured, for example where safety and security are key requirements.
> ultra-low defect software
Внимательно прочитал? Не defectless, а ultra-low defect. Не дают они "математическиие гарантии надёжности и безопасности", потому что это невозможно.
> Внимательно прочитал? Не defectless, а ultra-low defect. Не дают они "математическиие гарантии надёжности и безопасности", потому что это невозможно.Имеется в ввиду ОБЩЕЕ решение "ultra-low defect".
SPARK это верификатор подмножества языка программирования ADA, дающий гарантии отсутствия ошибок и корректности работы с памятью на уровне исходных текстов. Проверяются ТОЛЬКО исходные тексты, а не запускаемые бинари.
Есть еще компилятор языка програмирования ADA, который тоже разрабатывался как высоконадежный и очень безопасный.
Незабываем о CPU с его асемблером в котором тоже иногда просачиваются ошибки.
Общие решение:
исходный код на SPARK + компилятор языка программирования ADA + исполняющий бинарь процессор -- 100% гарантий не имеет,
но дает достаточные гарантии для использования в бортовых системах авиации, на критических производствах, военных АСУ, а также в обеспечении государственной информационной безопасности.
>100% гарантий не имеет,Вот именно.
>Но дает достаточные гарантии для использования в бортовых системах авиации, на критических производствах, военных АСУ, а также в обеспечении государственной информационной безопасности.
Согласен, с этим я не спорю.
Впервые за долгое время дискуссия на опеннете привела к чему-то кроме уничтожения нейронов головного мозга: кто-то признал, что 100% гарантий не даст ни один ЯП без серьёзных ограничений множества возможных программ, а я узнал о новом для себя ЯП, который имеет смысл изучить хотя бы для кругозора. Это повод принести в жертву компьютерным богам содержимое /tmp.
> кто-то признал, что 100% гарантий не даст ни один ЯПКонечно не даст. В верификаторах SPARK наверняка есть ошибки, программист может "неаккуратно что написать" и бажный верификаторах пропустит дыру. Со временем вылежут и баги.
> я узнал о новом для себя ЯП, который имеет смысл изучить хотя бы для кругозора
Мне точно известно что версия SPARK-2021 у них получилась наконец рабочая. И компилятор GNU для ADA в 2021 году так-же наконец получился рабочим и пригодным для промышленного использования. Год прошел, а я так и не решилась что-то написать, другие задачи.
Меня интересуют ответы на вопросы:
1. Насколько готовый бинарь со SPARK медленнее бинаря скомпиленого с C.
2. Задачи жесткого реального времени. В ASM и C можно рассчитать количество тактов проца необходимых для работы проги. А в SPARK можно дать гарантии исполнения бинаря за определенное количество тактов процессора?
3. Насколько долго писать на SPARK по сравнению с C или Python? Трудозатраты?
> В ASM и C можно рассчитать количество тактов проца необходимых для работы проги.А вот объясните, как специалист, каким образом можно рассчитать количество тактов в асм, если оно зависит как минимум от того как удачно бранч предиктор справится со своей задачей?
Там считают не минимум (с "предсказаниями" проца) а максимум, чтобы сказать: "вот за такое количество тактов прога гарантировано отработает".
Если с предсказаниями рассчитывать, то считаем по худшему варианту.
Лучше без предсказателя считать и работать.
> ГАРАНТИИ защиты и корректности работы с памятью дает ядро ОС с процессором. А не аккуратность програмистаОсторожно, ты оскорбляешь религиозные чувства секты свидетелей прямых рук.
> секты свидетелей прямых рукЕсть еще свидетели секты мозготраха, веруют, что он позитивно влияет на безопасность и без него ИТ безопасности не бывает.
К стати а на каком из уровней ИТ безопасности в США требуется чистка персонала?
C: DAC
B: MAC
A1: математическое доказательство корректности кода.
> Сами идите, пишите на обоих языках, а потом сравнивайте объём кода, трудозатраты и КПД своей работы.Ты правильные вопросы задал:
объем кода
трудозатраты
КПД
молодец.Теперь в твою модель добавь следующие переменные:
надежность (авиация, еретические производства, оборонка - сбой, падение программы неприемлемо)
безопасность (требуется уровень не ниже A1 - математическое доказательство корректности, отсутствия ошибок и уязвимостей на уровне исходных текстов)
И перещетай заново свои критерии оценки языка:
объем кода
трудозатраты
КПД
И где теперь Rust с C по сравнению со SPARK?> А заодно подумайте, почему ни один из формально верифицируемых языков даже близко не пошёл в массы.
Это смотря кто заказчик. Массовому заказчику надо:
быстро и дёшево
а не
надежно, безопасно, верефицируемо.
По этому пишут на Python.За SPARK стоит самый крутой заказчик, которому необхожим язык дающий сразу гарантии:
надежности
безопасности
верефицируемости
всем написанным на нем програмам. Трудозатраты на мат верификацию исходного кода на отсутствие уязвимостей и збоев работы программы на SPARK равны 0.
Как я и писал выше, опеннетовский эксперт не умеет читать [1] и мыслить критически [2]. А в вашем случае ещё и минимально грамотно писать [3] - это при наличии спеллчекера в браузере. Зато всё на свете знает. И правильно - зачем думать, если можно просто знать?[1] Выше я писал: "И тебе придётся каждую строчку кода обложить пачкой контрактов, далеко не всегда тривиальных, и тебе это очень быстро надоест, потому что успеешь постареть, пока напишешь хоть какой-то функционал. Для космических аппаратов и ядерных электростанций это приемлемо, а для менее критичного софта - нет. Никто не будет ждать 2 года, пока ты напишешь супернадёжный медиаплеер."
[2] "Трудозатраты на мат верификацию исходного кода на отсутствие уязвимостей и збоев работы программы на SPARK равны 0."
Ага, а про трудозатраты на написание нескольких контрактов на одну строчку кода мы, конечно же, забудем. Видимо, компилятор сам догадается, что ты имел ввиду и напишет контракты за тебя. Только непонятно тогда, зачем нужен программист, если компилятор такой умный.[3] Не люблю докапываться до орфографии, но это же просто ужас какой-то - "перещетай", "збоев", "верефицируемо", "програмам".
Не хами. Писал грамотно, а вражеский спелчекер поменял слова.Вот Ыксперту по безопасной работе с памятью еще:
https://www.opennet.ru/openforum/vsluhforumID3/127824.html#404
https://www.opennet.ru/openforum/vsluhforumID3/127824.html#406Могу сравнить трудозатраты по разработке ПО на Python и C как 1 к 10. Соответственно считай КПД и цену ПО как 1 к 10.
Смотри код ядра ОС на СОВРЕМЕННОМ SPARK-2014: https://git.codelabs.ch/?p=muen.git;a=tree;f=kernel/src
Он легко читаем, понятен, удобен для поддержки.
> тебе придётся каждую строчку кода обложить пачкой контрактов, далеко не всегда тривиальных, и тебе это очень быстро надоест, потому что успеешь постареть, пока напишешь хоть какой-то функционал
> Ага, а про трудозатраты на написание нескольких контрактов на одну строчку кода мы, конечно же, забудем.Тебя обманули и ты вводишь в заблуждение других. Смотри спецификации языка SPARK-2014, лучше SPARK-2021. Им таки удалось написать АВТОМАТИЧЕСКИЙ ВЕРИФИКАТОР почти всего синтаксиса языка програмирования "ADA".
Сегодня GNU уже почти всевозможные вериыикаторы написала. В общем писать верифйикаторы не придется. Смотри пример кода ядра OS на SPARK-2014:
https://git.codelabs.ch/?p=muen.git;a=blob;f=kernel/src/sk-k...
https://git.codelabs.ch/?p=muen.git;a=blob;f=kernel/src/sk-k...
Интересные ссылки ты приводишь. А я вот заглянул в другую часть сорцов, и что же я вижу?https://git.codelabs.ch/?p=muen.git;a=blob;f=common/src/sk-c...
27 procedure Cli
28 with
29 Global => (In_Out => X86_64.State),
30 Depends => (X86_64.State =>+ null),
31 Inline_Always;https://git.codelabs.ch/?p=muen.git;a=blob;f=common/src/sk-c...
37 procedure Cli
38 with
39 SPARK_Mode => Off
40 is
41 begin
42 System.Machine_Code.Asm
43 (Template => "cli",
44 Volatile => True);
45 end Cli;Итого 2 контракта на одну инструкцию "cli" и отключение режима SPARK. То есть, SPARK знать ничего не знает про инструкцию "cli" и никаких гарантий давать не может в принципе, поэтому компилируем функцию как обычную ADA. Ловко выкрутились 😁 Так это что получается, аналог unsafe? Вот тебе и хвалёная верификация. "Мамой клянусь, эта функция только X86_64.State меняет!". Ну что сказать, сильные гарантии. Прямо как в другом языке, где тоже можно из безопасного кода вызывать опасный. Но этот другой язык - плохой, потому что называется Rust, а вот SPARK намного лучше, хотя суть у него та же: разработчик в маленькой функции пообещал не хулиганить, а компилятор пожал плечами и разрешил её вызывать, полагаясь на честное слово.
1. Пока не весь код Mumen написан на SOARK-2014 и ASM, есть немного кода на неверифицируемой ADA+2012: https://git.codelabs.ch/?p=muen.git;a=blob;f=README2. Ядро OS это очень низкоуровневое ПО работающие напрямую с железом, асемблерными инструкциями процессора. На данном этапе эволюции процессоров и языков программирования пока необходимо использовать асеблерный код для написание некоторых частей OS. Да, поддержку CPU без асеблера не напишешь. Асемблерный код неверифицируется SPARK, весь Асемблерный код необходимо проверять руками, но его немного: https://git.codelabs.ch/?p=muen.git;a=tree;f=kernel/src/asm В отношении асемблерного кода нет гарантий безопасности и надежности.
3. Использование неверифицируемой ADA, влияет только на математические доказательства отсутствия ошибок и корректности работы с памятью на уровне исходных текстов. По надежности и безопасности ПО на ADA на порядок выше чем C и Rust.
4. Прикладное ПО, это не ядро ОС, можно писать на чистом SPARK без ASM.
> поэтому компилируем функцию как обычную ADA.Язык SPARK это верифицируемое подмножество языка программирования ADA.
SPARK своего компилятора не имеет, для компиляции программ на SPARK используется обычный компилятор ADA.
SPARK имеет автоматический верификации исходных текстов кода, дающий гарантии отсутствия ошибок во время работы программы, включая ошибки связанные с безопасной работой с памятью на уровне исходных текстов програм.
В автоматический верификации добавляются новые верификаторы добавляя синтаксис ADA в верифицируемое подмножество SPARK.
Clear Interrupt Flag (cli)Operation
0 → IFDescription
Clears the interrupt flag if the current privilege level is at least as privileged as IOPL;
affects no other flags. External interrupts disabled at the end of the cli instruction
or from that point on until the interrupt flag is set
Я тоже умею копипастить и знаю, что делает инструкция cli. Что сказать-то хотел этим?
> Я тоже умею копипастить и знаю, что делает инструкция cli.Я это не заметил в "Мамой клянусь, эта функция только X86_64.State меняет!".
Потому что у тебя опилки в голове.Читаем https://sites.radford.edu/~nokie/classes/320/std_lib_html/sy...:
procedure Asm (
Template : String;
Outputs : Asm_Output_Operand_List;
Inputs : Asm_Input_Operand_List;
Clobber : String := "";
Volatile : Boolean := False);procedure Asm (
Template : String;
Outputs : Asm_Output_Operand := No_Output_Operands;
Inputs : Asm_Input_Operand_List;
Clobber : String := "";
Volatile : Boolean := False);procedure Asm (
Template : String;
Outputs : Asm_Output_Operand_List;
Inputs : Asm_Input_Operand := No_Input_Operands;
Clobber : String := "";
Volatile : Boolean := False);procedure Asm (
Template : String;
Outputs : Asm_Output_Operand := No_Output_Operands;
Inputs : Asm_Input_Operand := No_Input_Operands;
Clobber : String := "";
Volatile : Boolean := False);function Asm (
Template : String;
Outputs : Asm_Output_Operand_List;
Inputs : Asm_Input_Operand_List;
Clobber : String := "";
Volatile : Boolean := False)
return Asm_Insn;function Asm (
Template : String;
Outputs : Asm_Output_Operand := No_Output_Operands;
Inputs : Asm_Input_Operand_List;
Clobber : String := "";
Volatile : Boolean := False)
return Asm_Insn;function Asm (
Template : String;
Outputs : Asm_Output_Operand_List;
Inputs : Asm_Input_Operand := No_Input_Operands;
Clobber : String := "";
Volatile : Boolean := False)
return Asm_Insn;function Asm (
Template : String;
Outputs : Asm_Output_Operand := No_Output_Operands;
Inputs : Asm_Input_Operand := No_Input_Operands;
Clobber : String := "";
Volatile : Boolean := False)
return Asm_Insn;Ты здесь видишь какие-нибудь контракты? А здесь?
procedure Cli
38 with
39 SPARK_Mode => Off
40 is
41 begin
42 System.Machine_Code.Asm
43 (Template => "cli",
44 Volatile => True);
45 end Cli;А здесь они откуда-то взялись, хотя функция System.Machine_Code.Asm контрактов не имеет:
27 procedure Cli
28 with
29 Global => (In_Out => X86_64.State),
30 Depends => (X86_64.State =>+ null),
31 Inline_Always;Ну, и откуда они взялись? А их приписал разработчик. Но мог написать другие, некорректные, или вовсе не писать. Получается "мамой клянусь". А ведь верификация на контрактах держится, без них тебе компилятор ничего за пределами Ada 2012 не гарантирует.
Я своими опилками не догоняю, как и что можно верифицировать в запрете прерываний. Посмотреть далее наличие Hlt и убедиться, что инициализируется Application Processor? У меня прям дымиться начинают опилки от этих мыслей.
Такое ощущение, что ты притворяешься дурачком ради троллинга. Не могу поверить, что до сих пор непонятно. Какая разница, запрет прерываний это или что-то ещё? Нет контрактов - нет верификации. Контракты пишутся человеком, а не компилятором. Компилятор доверяет контрактам. Чем это принципиально отличается от unsafe в Rust?
Возможно дело в том, что ты пытаешься везде разглядеть атаки на Rust. На само деле, мне интересна именно эта команда. Ты писал когда-нибудь команду cli? Если да, то зачем?
> procedure Asm (
> Template : String;
> Outputs : Asm_Output_Operand_List;
> Inputs : Asm_Input_Operand_List;
> Clobber : String := "";
> Volatile : Boolean := False);Что это за ужас? Это вроде не хруст? Они даже хрустиков по ужасному синтаксису сделали, с отрывом.
> Мамой клянусь ...Не клянись, никогда, ничем.
Тем более в вопросах языка на котором здесь никто не написал ни одной строчки кода. И никто не проверял что компилятор ADA эще с этим делает.
Клястся не хорошо.
https://kevinlynagh.com/rust-zig/
> Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun
> With Rust 1.50, a from-scratch debug build of my keyboard firmware takes 70 seconds (release, 90 seconds) and the target/ directory consumes 450MB of disk.
> Zig 0.7.1, on the other hand, compiles my firmware from-scratch in release mode in about 5 seconds and its zig-cache/ consumes 1.4MB. Nice!Эх, не тот язык выбрали добавлять в линукс
> Эх, не тот язык выбрали добавлять в линуксА откоменть в рассылку по приколу, если пользуешься им и можешь аргументировать? На первый взгляд Zig прикольнее хруста, но я активно им не пользовался и не смогу аргументировать на должном уровне :)
>When I first started using Zig, I was dismayed that it was missing so many features that I liked from other languages. No syntax for ranges. No closures. No iterator syntax.
> However, I ended up finding these absences liberating — this is where the “fun” comes in.как бы это странно ни звучало, но fun для такого проекта, как Linux в наше время неприемлем.
Хотя вот это
> Focus on debugging your application rather than debugging your programming language knowledge.
мне по душе (хотя я и не считаю, что в Zig-е такой уж удачный синтаксис)
RUST -- это БЫСТРО и БЕЗОПАСНО!
Смотрю местные анонимусы потихоньку переобуваются топить за раст, как и следовало ожидать
\cite{... избавленные от таких проблем как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.
}
Не очень понятно, зачем все это перечисленное делать.
Когда колбасу режем, пальцы же себе не отфуячиваем, так почему так аккуратно и программы не писать?
> \cite{... избавленные от таких проблем как обращение к области памяти после её
> освобождения, разыменование нулевых указателей и выход за границы буфера.
> }
> Не очень понятно, зачем все это перечисленное делать.
> Когда колбасу режем, пальцы же себе не отфуячиваем, так почему так аккуратно
> и программы не писать?У тебя проводка дома без изоляции лежит? Нет? А чо ты как лох, изоляция для слабаков которые не смотрят под ноги.
> У тебя проводка дома без изоляции лежит? Нет? А чо ты как
> лох, изоляция для слабаков которые не смотрят под ноги.Однако хватает и проводов без изоляции. Контактный рельс метро не очень заизолируешь на все сто. И вон ту высоковольтку - тоже. Слой изоляции больно уж непотребный надо.
> Однако хватает и проводов без изоляции. Контактный рельс метро не очень заизолируешь на все стоПоэтому там регулярно люди и умирают :))))