В ветку net-next, в которой развиваются изменения для ядра Linux 6.8, включены изменения, добавляющие в состав ядра начальную Rust-обвязку над phylib, уровнем абстракции для поддержки сетевых плат, и использующий данную обвязку драйвер ax88796b_rust, обеспечивающий поддержку Ethernet-контроллера Asix AX88772A (100MBit). Драйвер включает 135 строк кода и позиционируется как простой рабочий пример для создания сетевых драйверов на языке Rust...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60303
> 135 строк кодаЗа сколько лет? Типичный раст в общем.
Опухоль начинается с нескольких клеток (
Ну чего так пессимистично?
Замена палки-копалки тоже начиналась с единственной медном мотыги!
> Опухоль начинается с нескольких клеток (Вы ещё её проморгали с systemd, окститесь уважаемый, это уже прогрессия болезни!
Вот uki подвезут и повсеместный корень в ro в мейнстриме, наперевес с homed и прочими "поцтеризмами", тогда наступит следующая стадия болезни.
Т.е унификация вам уже не нравится?
Системмд - это отличное решение чтобы выкинуть зоопарк инитов и собрать кучу утилит в одной.
Плюс - вас же никто не заставляет ей пользоваться, можно быть гордым пингвином и робко использовать девуан.
systemd не инит, а системный менеджер с кучей функций. Пора бы уже это знать.
> systemd не инит, а системный менеджер с кучей функций. Пора бы уже это знать.При том чаще всего про это вещают господа, юзающие для себя launchd, SVC или (раньше) SMF как раз чтобы хаотичной помойкой самим не наслаждаться - но вы там, дескать, кушайте, наши вэи, дорогие линуксоиды.
А линуксоиды вот взяли и не захотели быть лохами на которых всякие козлы с failed ways экспериментируют. И сделали и себе системный менеджер - да еще и покруче вон тех.
Оно казачковое ведь?
> Оно казачковое ведь?Оно - это кто? Когда всякие господа юзающие винду или мак показательно льют крокодиловы слезы за линух и рассказывают как там "должно" быть - это и правда вызывает подобные вопросы. Но не к линуху а к подобным господам с двойными стандартами.
Грубо говоря - если они хотели свои юниксвеи, то почему сами в результате это все не жрут, не девелопают вон те системы и вместо этого сдриснули на проприетарь, заср@в себе поляну до непригодности для жизни. Пусть теперь майкрософту и эпплу и рассказывают как надо, имхо! Ну или вон там альтернативы типа дивана - чего не юзать то, если того хотелось? А, совсем маргинальное? Ну а мне вот системда решает дохреналион системных проблем, которые по другому сложно обыграть было. И сказки что мне это "не надо" - осточертели. Я хочу юзать фичи кернела моей оси не на 20% а на 100%, сорянчик. Включая namespaces, изоляцию, приоритеты, шедулеры, фильтрацию сисколов, вот это все ...
OpenRC ничем не хуже, давайте соберемся вокруг него и выкинем остальной зоопарк?
Давай, собирайся.
Так и сделали в Alpine, Devuan и Artix. И все нормально, без systemd небо не упало.
А ноют чего?
Не нравится системмд - не пользуйся, вон сколько альтернатив.
Но нет, в каждой теме про сабдж нытье как шапка портит линукс.
Так это ноют системдэшники что их святыню обижают, для остальных это всего лишь еще одна система инициализации.
> Так это ноют системдэшники что их святыню обижают, для остальных это всего
> лишь еще одна система инициализации.Вообще-то ныть в этом топике начали явно не системдшники. А, очевидно, те которые "обижают", существование которых вы и подхайлайтили. Но вон то видимо - нормуль, а когда ответка прилетает - это оказывается "ноют". Нормальные двойные стандарты.
Да и в Gentoo по умолчанию всё ещё OpenRC.
Не вводите людей в заблуждение!
В Gentoo зависит от используемого профиля:
~ $ eselect profile list
Available profile symlink targets:
...
[9] default/linux/amd64/17.1/desktop/plasma (stable)
[10] default/linux/amd64/17.1/desktop/plasma/systemd (stable)
...
Но первый (дефолтный) профиль в Генте - OpenRC.
Предположим (именно предположим), что OpenRC ничем не хуже.
А чем он лучше?
Давайте. Я за.
Собранных в кучу по принципу NIH под предводительством красношапки. Имеющее необозримое количество строк кода, которое может содержать уязвимости.
О, энтузиаст стриггерился на слово "systemd".
С одной вообще-то. С зиготы.
Это таки не драйвер сетевой карты. А драйвер физ.интерфейса - то есть та штука, что устанавливает скорость порта, дуплекс, определяет линк и тд. Это и на питоне можно наваять. А то я уже сунулся посмотреть как это они драйвер сетевой карты в 135 строк уместили.
Можно, ваяй.
Когда его примут в ядро, напишу тут - мы за тебя порадуемся.
"add Rust Asix PHY driver" - где тут хоть слово "сетевая карта"? Где в новости "драйвер сетевой карты"? Каким местом вообще читаете?
Кстати, читал как в Zed говорят Rust очень сложный, поэтому у нас всё тормозит 😆 Аллокации делать не может из-за lifetime rules.
Это те чудаки, которые IDE на расте пишут с заточкой под эппловский Metal? Неудивительно. Похоже, что это очередные жопорукие грантососы, сильная сторона которых, это презентация, а не собственно разработка.
Они самые. В последнем блоге написали что хотели StackAllocator или BumpAllocator, но из-за того что в Rust всё сложно и время жизни, выделяют много мелких объектов глобальным аллокатором.На Zig это вообще всё не проблема.
Пусть системный аллокатор заменят. Это делается в две строки. Jemalloc или mimalloc в некоторых случаях дают сходу х2 в производительности без изменения кода вообще.Хотя это же проприетарщина под огрызок, они там небось ничего кроме SwiftUI и не умеют. Вон разрабам Lapce почему-то не помешало написать шустрый кроссплатформенный редактор на расте.
Помнится мелкомагкие по опыту работы с rust начали разрабатывать свой язык с возможностью задания времени жизни не для одного объекта, а для коллекций.Очевидно, что это очередной необходимый шаг. Можно ли сделать его с rust - не знаю. Это только разрабтчики rust'а могут сказать. Но, подозреваю, их ответ мелкомягких не устроил.
> Но, подозреваю, их ответ мелкомягких не устроил.Поэтому они отказались от своей разработки и взяли раст?
>> Но, подозреваю, их ответ мелкомягких не устроил.
> Поэтому они отказались от своей разработки и взяли раст?Новостей про Verona на слышал. Комиты идут. С чего взял, что отказались?
>>> Но, подозреваю, их ответ мелкомягких не устроил.
>> Поэтому они отказались от своей разработки и взяли раст?
> Новостей про Verona на слышал. Комиты идут. С чего взял, что отказались?Я раньше думал, что это форк раста. Оказывается нет. Комиты идут, но это research, так что пока все сильно экспериментально. Хотя typescript тоже когда-то был внутренней разработкой https://en.wikipedia.org/wiki/TypeScript#History
> Похоже, что это очередные жопорукие грантососы, сильная сторона которых, это презентация, а не собственно разработка.Из чего ты сделал такой феерический вывод?
Раст сложный потому, что в его стандартную библиотеку и ядро языка постоянно добавляют фичи, которые делают то же самое, что предыдущие версии фич. В результате язык быстро развивается, но программистам на нём приходится помнить всё это многослойное наслоение мусора. Это давно пора разгрести, но тогда придётся переписать все библиотеки. Из-за дизайна вокруг статической линковки, прибитых гвоздями зависимостей сделать это будет невозможно. Это будет уже другой язык с похожим синтаксисом и похожей станд. библиотекой. Пригодный только для хэллоу ворлдов, потому что все библиштеки останутся на старой версии раст, а программерам больше нужен не чистый язык, а чтолы поменьше работы делать.
Нет, проблема именно с базовой системой владения, borrow checker и т.п. Rust очень тупой язык, и корректный и валидный (но сложный) код просто не понимает.Например когда несколько указателей из разных потоков владеют хитрым образов куском памяти.
Rust говорит "я ничего не понимаю, что ты там написал, я тупой, ДОКАЖИ мне что это корректно". И часто сделать это из-за самого же Rust просто невозможно (именно доказать корректность для borrow checker Rust).
И все забивают и пишут unsafe на unsafe, или глобальный аллокатор, потому что объект в BumpAllocator привязан в времени жизни аллокатора (массива) и объяснить компилятору что код корректный не получается. Ну, как я понял из их описания.
Это КАТАСТРОФА.
> Нет, проблема именно с базовой системой владения, borrow checker и т.п.
> Например когда несколько указателей из разных потоков владеют хитрым образов куском памяти.Судя по описанию несколько потоков просто имеет кусок памяти, а потом где-то случается гонка и CVEшки поимеют юзера.
> И часто сделать это из-за самого же Rust просто невозможно (именно доказать корректность для borrow checker Rust).
Тут 2 варианта: ты не смог или невозможно вообще.
Если второе - то на дыряшке эта конструкция и так будет небезопасна, а мы почитаем про очередную "уязвимость с повышением привилегий".
Если первое - то не страшно, возможно ты просто неосилятор или не смог поменять парадигму программинга.
А то попривыкают писать uint32_t x = (*(struct foo *)NULL)->x
и ARM приходится бросать безусловный HardFault, потому что по другому подобные гении не учатся.> И все забивают и пишут unsafe на unsafe, или глобальный аллокатор
То что можно наовнокодить даже на Раст - это известно, но в нормальном проекте за каждый ансейф тебе придется отчитаться на кодревью.
А если это какой-то васянопроект - то сомневаюсь, что там ревью вообще будет.> Это КАТАСТРОФА.
Для Витюшка, возможно. Для linux, android, aws, windows и индутрии в целом - нет.
Возможно разница в ресурсах и опыте.
Ниже ответил
> Rust говорит "я ничего не понимаю, что ты там написал, я тупой, ДОКАЖИ мне что это корректно".Не-не, раст говорит что тупой ты, и просит использовать правильные механизмы для работы с шареной памятью, причем часто подсказывает прямо в ошибке.
> Ну, как я понял из их описания.
Т.е. ты раст не знаешь, ты на нем не пишешь, но что-то "понял" и несешь свет знания на опеннет?
Ну, не то чтобы я удивлен... Ты еще в предыдущей теме ими блистал.
Что значит я Rust не знаю? И что именно я должен знать в Rust чтобы вести дискуссии?Или я должен верить в magic великого компилятора Rust, который не позволяет ошибкам случиться прямо в compile time?)
А вот Andy Pavlo другого мнения;) У него студенты спрашивали уже насчёт Rust. Типа...а как же Rust? Разве он не безопасно работает с памятью? Откуда дедлоки и утечки памяти и все race condition берутся? Это же Rust 😆
Ты ручками, ОЧЕНЬ аккуратно, должен лочить и анлочить мьютексы, согласно протоколу синхронизации. Rust никаких существенных преимуществ не даёт.
Это уже как религия, как секта скорее всего. Свидетели безопасного Rust.
Если бы всё было именно так - я бы сам лично на него бы уже пересел, как минимум в pet project. Я его оценивал...то не умеет, это не умеет, с многопоточностью работать не умеет (ссылки на ячейку памяти а разных потоках, где всё абсолютно корректно и валидно, но Rust этого не понимает).
У Rust куууча недостатков по сравнению с Zig, лень перечислять.Например его exception при unwrap - а это hidden control flow. В Zig ошибки возвращаются только как возвращаемое значение. Ты всегда знаешь что никакого exception не будет, их и нету а языке. Никаких неявных деструкторов, defer. Никаких неявных аллокаций памяти. Ты всегда знаешь выделяет функция память или нет по сигнатуре. Никаких ошибок с alignment, в отличие от Rust. В Zig они встроены в систему типов и ты не сможешь больший alignment присвоить меньшему. Нууу и так далее.
Я в чём-то не прав? Можешь оспорить или опровергнуть мои слова?
> А вот Andy Pavlo другого мнения;)Ты уже вторую тему газифицируешь без пруфов.
Тебе что так сложно скопировать ссылку и написать "вот тут умный чел написал то-то"?> Ты ручками, ОЧЕНЬ аккуратно, должен лочить и анлочить мьютексы, согласно протоколу синхронизации. Rust никаких существенных преимуществ не даёт.
Спасибо, насмотрелись уже на "аккуратных", вот только memory ошибки как были 30+ лет, так до сих пор делаются.
> Я его оценивал...то не умеет, это не умеет, с многопоточностью работать не умеет (ссылки на ячейку памяти а разных потоках, где всё абсолютно корректно и валидно, но Rust этого не понимает)
Даааа! Конечно "коректно и валидно", и одновременное можно одну память менять, я так 100 раз делал! Звучит почти как в СИшке... а точно.
> Например его exception при unwrap - а это hidden control flow
Не уверен, что это слишком большая проблема. В каком случае это приводит к ошибке?
> Никаких неявных деструкторов, defer
С каких это пор defer это плохо?
> Никаких ошибок с alignment, в отличие от Rust. В Zig они встроены в систему типов
Сколько накладных рассходов нам это стоит в Зиге?
> Я в чём-то не прав? Можешь оспорить или опровергнуть мои слова?
Не особо собирался.
Выглядит для меня как "я пытаюсь писать на раст как на С, абсолютно плюя на работу с памятью, но оно мне мешает, а зиг такой хороший потому что у меня компилятор не ругается".
Ну, что я могу сказать, пиши свой петпроджект на Зиг, а разработчики ядра будут писать на раст. Все довольны.
Он это сказал в какой-то из 24 полуторачасовых лекций 😆 Извини, я не готов их смотреть заново ради этого.Но ты можешь убедиться сам, вот ссылка https://youtube.com/playlist?list=RDCMUCHnBsf2rH-K7pn09rb3qv...
Как тут цитаты вставлять?)Ниже я написал пример "многих указателей" на структуру данных. Можешь ткнуть меня носом в race condition, в ошибки, а то я покусился на святое. И сейчас окажется что ошибок нет 😆
Всё верно, можно 100 раз менять память безопасно, ты правильно понял.
Это очень большая проблема. У тебя критичный код, который никогда не должен падать, может всегда, в любой момент упасть 😆 Это приводит к необратимым последствиям. Но, видимо в Rust "и таааак сойдёт" ✊ В С++ это называется exception safety.
defer как раз очень круто и правильно, как и нужно делать, а бросание исключений при unwrap() нет.
Я тебе более скажу - zig более безопасный чем Rust, он отловит большинство ошибок, которые Rust отловить не может, в runtime. Потому что при Debug автоматически включает AddressSanitizer, аллокаторы с выявлением memory leaks, и тд. Те любые выходы за границы массива, утечки памяти, двойное освобождение памяти и многое другое.
Нисколько накладных ресурсов. Это проверяется в compile-time системой типов.
Я на Rust вообще не пытаюсь писать никак 😆
> Как тут цитаты вставлять?)Просто копируешь и добавляешь >
У нас тут не очень продвинутая комментировалка. (Или идешь на форум, там можно цитировать, но вообще все сообщение)> Всё верно, можно 100 раз менять память безопасно, ты правильно понял.
Ну так с помощь mutex в раст можно сделать тоже самое, не понимаю в чем у тебя трудности.
А просить код я, естественно не буду, на форуме анонимов)> У тебя критичный код, который никогда не должен падать, может всегда, в любой момент упасть
Значит тебе не ядро линукс нужно, а какое-то seL4.
> В С++ это называется exception safety.
Но я ядре плюсов нету, ладно ты бы сказал в СИ оно есть. Вон в хаскеле есть монады, а в расте тоже нету.
Будет нужно, напишут RFC и добавят в спарк. Пока у всех нормально работает (кроме тебя и еще нескольких)> а бросание исключений при unwrap() нет.
Просто делаешь правило для линтера что unwrap() запрещен.
И делай свой проект без unwrap.
Я читал разные статьи как NEVER Use `unwrap()` in Production, так и Using unwrap() in Rust is Okay. Так что feel free в своем проекте делать то что считаешь нужным.
> Ну так с помощь mutex...Point в том что Rust не даёт безопасную работу с памятью. Или то что он даёт совершенно недостаточно для чего то сложнее hello world. А вот жизнь усложняет значительно, как и загрязняет синтаксис. На это, кстати, много жалуются реальные разработчики чего-то серьезного на Rust.
> Просто делаешь правило для линтера
ВСЁ тоже самое можно сделать на С++. Написать правильно линтера, добавить move семантику к типу, добавить exception safety в кусок кода и так далее.
Использовать любую потокобезопасную очередь для передачи сообщений между потоками, например.
Всё это можно сделать, так в чём преимущество Rust?
> Но я ядре плюсов нету
Я пришёл набросить!)))
Я считаю что Rust безусловно лучше С и даже С++ для ядра Linux. Но Zig безусловно лучше (и значительно) чем Rust для того же ядра.
> Значит тебе не ядро линукс
Представляю как я прихожу и говорю что для нашей базы данных нужен seL4, а не Linux :))
> Point в том что Rust не даёт безопасную работу с памятью. Или то что он даёт совершенно недостаточно для чего то сложнее hello worldЧел, так расскажи это сотням тысяч людей в индустрии - будет сенсация! Люди прозреют, что они были идиотами, и только Витюшка сопеннета отрыл им, дерачкам, глаза.
Ну, или покрутят пальцем у виска...
Сотни тысяч... точнее 20 миллионов человек пишет на JavaScript НУ И ЧТО?Или "Чел, так расскажи это миллионам людей в индустрии - будет сенсация!" что JavaScript это г...но написанное за 2 недели на коленке?)))
А если 100 миллионов на Rust будут писать, он от этого станет лучше или безопаснее?)))
Раньше 30% всей мировой разработки было на С++. Не помешало выпустить С++11 и кардинально улучшить язык.
> Раньше 30% всей мировой разработки было на С++. Не помешало выпустить С++11 и кардинально улучшить язык.Т.е раст высечен в камне? И добавить туда RFC нельзя?
Точно так же есть Edition в который добавляют ломающее апи.ps погугли когда ядро перешло с С99
> НУ И ЧТО?То, что ты ляпнул "Rust не даёт безопасную работу с памятью" и теперь извиваешься как уж на сковороде.
Ничего я не извиваюсь. Вот когда добавят безопасную работу с памятью, вот тогда и приходи, когда твоё RFC добавят.Пока ни один язык её не добавил. Частично эту проблему решили managed языки типа Java. Но там а) память теперь течёт б) это только для простых случаев, написать многопоточный код это тебе никак не помогает.
А это основное и самое сложное. Отследить ссылки я и сам могу.
И в Rust никакой безопасной работы нет. Тот же С++ (современный), только сбоку. Принципиальной разницы нет. Ну, пока мне её никто не показал, стесняются, наверное.
Ну так я ж говорю: ты сообщи ребятам, юзающим Раст, о своих открытиях: что в нем нет безопасной работы с памятью, что это "С++, только сбоку"... Люди должны знать правду! Ты разве не видишь, что это глобальный заговор? На тебя единственного вся надежда, Витюшка - спаси индустрию!
> Всё это можно сделать, так в чём преимущество Rust?В том что сделать-то может и можно.
А тут оно уже сделано и работает в ядре.
Минуту назад ты говорил что нужно добавлять линтер чтобы не вызывать unwrap() и вообще "это не нужно" для exception safety, и бери другое ядро.
> Я считаю что Rust безусловно лучше С и даже С++ для ядра
> Linux. Но Zig безусловно лучше (и значительно) чем Rust для того же ядра.Я про зиг уже писал. Это по сути СИшка в смысле недостатков (управление памятью), затом модно-молодежно.
Ну и добавили очень странные "улучшения" аргументируя "no hidden control flow" и приводя в пример
Examples of hidden control flow:
C++, D, and Rust have operator overloading, so the + operator might call a function.
C++, D, and Go have throw/catch exceptions, so foo() might throw an exception, and prevent bar() from being called.Но дефер все таки вернули, наверное это уже не хидденфлоу) Причем errdefer тоже. (Интеренсо как оно будет работать с правилом "so foo() might throw an exception, and prevent bar() from being called")
Думаю у них цели/ценности меняются так же часто, как у некоторых генералов число ПИ.В общем сейчас это просто забавный пример СИшки, но чуть поприятнее.
> Представляю как я прихожу и говорю что для нашей базы данных нужен seL4, а не Linux :))
И? Тебя же не уволят?
Если твоя супер база работает на обычном ядре ликукса - то это консумерская штука и никакой супер надежности для нее скорее всего не нужно, все равно ядро настолько дырявое, что софт может быть и попроще.
> Я про зиг уже писал. Это по сути СИшкаТак, видимо ты не понимаешь что такое defer.
Ты пишешь сразу же
mutex.lock()
defer mutex.unlock()И компилятор автоматически везде вставляет mutex.unlock() перед ЛЮБЫМ выходом из функции. Где бы ты и как потом ни выходил.
Согласись, надо быть тупым чтобы не вставить на следующей строке unlock. Тебе не нужно по всем return бегать. Это делает компилятор автоматически.
errdefer сделает тоже самое везде, но только для ошибки. И обычный errdefer ты вызываешь в 99% случаев. Однако, если надо, ты можешь прописать значительно более хитрые и продвинутые условия. В Rust этого сделать нельзя, в С++ тоже.
Конструкторы и деструкторы это ужасные костыли.
А что если ты не хочешь вставлять unlock() и тебе не нужно "очищать ресурс"? Например, зачем тебе обнулять память, если она будет перезаписана потом? В С++ и Rust ты этого сделать не можешь.
Какие-то пустые бредовые деструкторы вызываются всегда. Это совсем не бесплатно, делать все эти вызовы. Тем более рекурсивно!
> Но дефер все таки вернули
Потому что ты явно пишешь errdefer mutex.unlock(). Ты видишь этот вызов, ты видишь что ты делаешь и как очищаешь. Это явно. Прямо в функции. Даже в язык С есть proposal добавить defer.
Более того, ты можешь делать больше чем "деструктор", например пометить объект удалённым в массиве индексов. С деструктором это невозможно. Или вызывать "очищение" только при определённом условии или при определенной ошибке.
А деструкторы вызываются неявно. И ты не знаешь что и как они делают, что они там очищают и тп. Отменить ты их не можешь.
Я опять же писал что Zig БЕЗОПАСНЕЕ чем Rust. Многие ошибки, если не большинство, в compile time невозможно отловить никогда. В Zig есть все автоматические проверки безопасности. Выхода за границы массива, безопасность выравнивания типов данных (в Rust нет), разные аллокаторы (в Rust нет) и мноооого чего ещё, я сам всё не знаю.
Он БОЛЕЕ кроссплатформенный чем Rust. Он БЫСТРЕЕ чем Rust. Он компилируется быстрее. У него лучшая интероперабельность с С и С++. Он гораздо более продвинутый в низкоуровневых возможностях.
> Так, видимо ты не понимаешь что такое defer.Ты написал целую кучу про дефер, но так и не сказал это "hidden control flow" или нет.
> Конструкторы и деструкторы это ужасные костыли.
Ого! да у нас тут гуру, ты не стесняйся продолжай что еще является костылями?
> А что если ты не хочешь вставлять unlock() и тебе не нужно "очищать ресурс"?
> Например, зачем тебе обнулять память, если она будет перезаписана потом?Такая необходимость возникает в очень редких задачах типа БД.
Для обычной разработки память должна обнуляться чтобы потому bufferoverflow тебе не прочитал пароль из строки рядом.
В Раст ты можешь всю функцию завернуть в unsafe, если уж сильно надо и по другому никак.> Я опять же писал что Zig БЕЗОПАСНЕЕ чем Rust.
Очень голословное утверждение особенно на фоне того что разрабы ЗИГа сами пишут "not fully safe".
Зато капсом, так наверное более убедительно.> Многие ошибки, если не большинство, в compile time невозможно отловить никогда.
Хм... ну так начнем с ошибок которые можно словить, а потом может что-то придумаем.
> В Zig есть все автоматические проверки безопасности. Выхода за границы массива, безопасность выравнивания типов данных (в Rust нет), разные аллокаторы (в Rust нет)...
> Выхода за границы массива// Slices have bounds checking and are therefore protected
// against this kind of undefined behavior. This is one reason
// we prefer slices to pointers.
В Раст слайсы тоже есть. Более того By default, accesses to container types such as slices and vectors involve bounds checks in Rust.
Это еще раз показывают качество твоих знаний про Раст.А что в Зиге с массивами?
https://ziglang.org/documentation/0.1.1/#undef-index-out-of-...
At runtime crashes with the message index out of bounds and a stack trace.
Т.е таки крешится... А ты рассказывал "как же в расте программа крешится? А не должна"
И в чем тут преимущество?> разные аллокаторы (в Rust нет)
А насколько это необходимо? Насколько это влияет на безопасность?
Примеры пожалуйста.Я уже молчу что в нем есть целая статья UB ziglang.org/documentation/0.1.1/#undefined-behavior
Где наверное больше половины заканчиваются
When a safety check fails, Zig crashes
А секции
Invalid Enum Cast TODO
Incorrect Pointer Alignment TODO
Memory TODO
Сразу видно уровень качества разработки, у нас будет креш по памяти, но ты об этом не узнаешь)
Я смотрю ты очень избирательно читаешь или не понимаешь написанного.Это типичные проблемы junior программистов и фанатиков.
Расскажи мне, где ты увидел что
> Это еще раз показывают качество твоих знаний про Раст.
Я говорил что проверок выхода за границы нет в Rust?
> Ты написал целую кучу про дефер, но так и не сказал это "hidden control flow" или нет.
Это не hidden control flow.
> Ого! да у нас тут гуру, ты не стесняйся продолжай что еще является костылями?
Представляешь, деструкторы часто не нужны. Понимаю, такие тайные знания не всем под силу.
Например, не вызывать деструктор на объекте после std::move(val). Понимаю, такому наверное не учили.
> Такая необходимость возникает в очень редких задачах типа БД.
Это возникает в любом высокопроизводительной задаче, HPC, браузерные движки, базы данных, и тд. Если ты гоняешь json-чики на Rust (или С++), то конечно обновляй всё подряд, что нужно и не нужно 😆
> Для обычной разработки память должна обнуляться чтобы потому bufferoverflow
Откуда у тебя там buffer overflow возникнет?) Это надо быть рукожопом. Меняешь size на 0, массив логически пустой. Индексы при вставки тоже проверять нужно. Вот такие рукожопы потом и говнокодят, что на С++, что на Rust.
Я смотрю и Rust особо от рукожопов не спасает 😆
Если ты обнуляешь данные - ты скрываешь ошибку, и на тестах хрен ты её потом отловишь, в отличии от "грязного" буфера.
Но я так понял тут у нас Rust эксперт, который в массив с обычными данными ещё и пароли записывает 😆😆😆
Вот ты и расписался в своей абсолютной некомпетентности. Ты как говнокодил на языке Н, так и на Rust продолжаешь говнокодить 😆
И как мы видим никакой Rust тебе не помог, ошибки твои не выловил, по рукам не дал. Зато "безопасно". От дураков защиты нет.
> Хм... ну так начнем с ошибок которые можно словить, а потом может что-то придумаем.
Это умеет делать одинаково хорошо и С++. И zig.
Твой borrow checker - он не находит ошибки, как ты до сих пор понять то этого не можешь. Остальное не отличается от других языков.
> Очень голословное утверждение особенно на фоне того что разрабы ЗИГа сами пишут "not fully safe".
Зато капсом, так наверное более убедительно.
Я достаточно привёл аргументов. И доказал убедительно с фактами. Понимаю, неприятно их признавать.
Твой фанатизм затмил тебе глаза, ты как сектант теперь.
Конечно Zig не полностью безопасный язык. Там есть сырые указатели. Как и в Rust, но он у тебя полностью безопасный 😆😆😆 Самому то не смешно?)))
> А насколько это необходимо? Насколько это влияет на безопасность?
Примеры пожалуйста.
Кастомный аллокатор в 30-60 раз быстрее обычного глобального, потому что он потокобезопасный, у него куча внутренних структур и локов.
Это нужно там где 1. важна скорость 2. важны гарантии - микроконтроллеры, любое критичное ПО на Linux. 3. ты можешь какому-то коду давать специальные аллокаторы
Они используются в браузерах, базах данных, языках программирования. У меня друг в мировой компании разрабатывает язык программирования - у них специальные аллокаторы в runtime.
> When a safety check fails, Zig crashes
Там где программа в состоянии, где больше ничего нельзя сделать. Например выход за границы массива. Вместо того чтобы потихому прочитать невалидные данные он упадёт. Это и есть безопасность.
> Сразу видно уровень качества разработки, у нас будет креш по памяти, но ты об этом не узнаешь)
> Memory TODOНу зачем ты так нагло и некрасиво врёшь? Я специально посмотрел документации master и 0.11. Там ничего такого нет. Все TODO - это в основном добавить документацию.
Как это не узнаешь? А все те проверки это что по твоему?) А выход за границы массива, а memory leak sanitizer???
> Или я должен верить в magic великого компилятора RustЕсли это для тебя магия, то все очень печально))
Там компилятор гарантирует выполнения некоторого количества просто элементарных правил - типа не меняй переменную с двух разных мест просто так.
И если ты не можешь осилить этот список, или понять что именно они гарантируют... то может лучше заняться какими-то языками типа питона?> Ты ручками, ОЧЕНЬ аккуратно, должен лочить и анлочить мьютексы, согласно протоколу синхронизации. Rust никаких существенных преимуществ не даёт.
Падажди? А разве в сишке ты не должен "ОЧЕНЬ аккуратно лочить и анлочить мьютексы"?
Наверное должен... но кто ж тебе запретит просто фигачить данные с каких попало потоков вообще без мьютексов!Раст тебя заставит хотя бы Arc<Mutex> использовать.
При этом rust prevents data races, но logical races and deadlocks are still possible.
Дедлоки легко сделать в любом языке. Что в си, что в расте, что в питоне.
Я не знаю ни одного языка который гарантировал бы их отсутствие. Это скорее ближе к формальной верификации, а не к языку.И встречный вопрос - раз для раста это проблема, а зиг круче раста, то зиг 146% поборол дедлоки и другие проблемы многопоточного кода? Правда ведь?))
> А вот Andy Pavlo другого мнения;)
Это очень существенно. А Линус противоположного мнения мнению Andy. Теперь будет схватка двух йокодзун?
> У Rust куууча недостатков по сравнению с Zig, лень перечислять.
> лень перечислять.Прям не сомневался в этом)))
> Никаких неявных деструкторов, defer.
И это одна из причин почему зиг такое же днище как сишка.
Нужно *всего лишь* деаллоцировать память в нужный момент и строго только один раз.
*Всего лишь*. Но вот почему-то ни один сишник еще не справился с такой элементарной задачей.
Какой смысл в еще одном языке, в котором нужно точно также следить за памятью как с сишке?> Ты всегда знаешь выделяет функция память или нет по сигнатуре.
Полезная штука, не спорю.
> Нууу и так далее.
Ну и так далее продолжаем выходить за пределы массива, писать что угодно куда угодно и ловить RCE.
> Я в чём-то не прав?
Ты считаешь это недостатками, а я считаю недостатком мнимую "простоту" Зига.
Потому что получается та же сишка, только в профиль. Еще и написанная... ну скажем так, непонятно кем с крайне сомнительными перспективами.
> Там компилятор гарантирует выполнения некоторого количества просто элементарных правилВ этом и проблема! Ничего он не гарантирует!
Если бы он говорил "этот код некорректный!", следуй этим правилам - это было бы одно. А он говорит "я ни ... не понимаю что ты написал, пиши как я сказал" и просто ОТБРАСЫВАЕТ корректный валидный безопасный код 😆 Это бреееед, ребята 🤠
Это не то что ожидаешь от СИСТЕМНОГО языка программирования.
Те он тупо слабенький и не понимает что ты пишешь. Это как если бы компилятор говорил что "многопоточная программа" небезопасна, пиши в один поток!
А почему бы и нет, а действительно супербезопасно!
> типа не меняй переменную с двух разных мест просто так
Так я и не меняю "просто так" и в С++. Но хочу менять когда мне нужно, без тонны бойлерплейта.
И когда я пишу базу данных, я делаю вещи посложнее чем "отслеживание ссылок" на несколько порядков 😆 Если бы был простоое переключение safe / unsafe вопросов бы не было. Там вообще всё начинает разваливаться, какие-то pin, transmute ещё какая-то бредятина появляется.
> И встречный вопрос - раз для раста это проблема, а зиг круче раста, то зиг 146% поборол дедлоки и другие проблемы многопоточного кода? Правда ведь?))
Ты не понял мой point. Zig - это системный язык программирования, он тебе позволяет легко сделать всё что угодно, но ЯВНО. И максимально удобно и безопасно там, где это оправдано.
Какой смысл усложнять очень сильно язык и при этом не решить основные и главные проблемы "безопасной работы памяти"?) Ты сравни код Zig и Rust на досуге. Zig читается как песня, он ПОНЯТЕН. Он делает то, что ты ожидаешь от языка и что видишь в коде.
При этом Zig БОЛЕЕ безопасный при работе с памятью. Он отлавливает всё что возможно отловить существующими средствами вообще без изменений языка.
Например, ты просто передаешь std.testing.allocator (специальный аллокатор, который отлавливает утечки памяти, аналог Valgrind) в структуру и ВСЕ вызовы всей программы будут использовать этот аллокатор. Или передаешь его только в нужный кусок кода. Неплохо иметь "Valgrind" из коробки в языке, согласись? Который вызывается одной строчкой.
Это отлавливает 99.99% ошибок с памятью на этапе первых запусков программы (даже на тестах). В runtime, ведь в compile time можно выловить только очень ограниченное количество ошибок, и все они банальные (простые).
Я несколько месяцев (когда не знал как собирать сложное приложение с их билд системой, незрелая она была тогда) писал приложение только на тестах и этом аллокаторе))) Собрал - заработало сразу.
Твой "безопасный Rust" так умеет?) Нет) Только не говори что "и таааак сойдёт" или "не очень то и нужно было". В Rust любая функция может неявно вызвать глобальный аллокатор. А может вызвать переданный как параметр (если есть такая опция), а может и тот и другой.
Ещё он включает многие санитайзеры проекта LLVM. Это, конечно, не формальная верификация, но уже очень сильно.
А планирует задействовать вообще все санитайзеры которые там есть, но руки не дошли. В том числе и ThreadSanitaizer. Это гораздо круче чем все твои проверки в Rust.
Вот их документации Zig что он УЖЕ умеет:
Reaching Unreachable Code
Index out of Bounds
Cast Negative Number to Unsigned Integer (пофиксили в Rust в 2015)
Cast Truncates Data
Integer Overflow
Exact Left Shift Overflow
Exact Right Shift Overflow
Division by Zero
Remainder Division by Zero
Exact Division Remainder
Attempt to Unwrap Null
Attempt to Unwrap Error
Invalid Error Code
Invalid Enum Cast
Invalid Error Set Cast
Incorrect Pointer Alignment (!!!) (а Rust схавает и не подавится и привет Segmentation Fault в лучшем случае, в худшем "безопасное" перезаписыаание области памяти)
Wrong Union Field Access
Out of Bounds Float to Integer Cast (!!! Читаем - https://stackoverflow.com/questions/61144957/what-happens-wh...In Rust 1.44 and earlier, if you use as to cast a floating-point number to an integer type and the floating-point number does not fit¹ in the target type, the result is an undefined value², and most things that you can do with it cause undefined behavior !!!
Очень "безопасно" для языка версии 1.44. Сравни с версией Zig 0.11 😆)
Pointer Cast Invalid Null (В zig есть null safety, чего дарт не мог получить вплоть до версии Dart 3.0 - указатели НЕ МОГУТ быть нулевыми)
Многие проверки СРАЗУ делаются и в compile time (условия которые можно проверить во время компиляции), и в runtime!
Твой "безопасный" Rust так умеет?
> Нужно *всего лишь* деаллоцировать память в нужный момент и строго только один раз.
Нет, выше я писал. Это делает КОМПИЛЯТОР. Это в С ты должен во всех return освободить всю память и ничего не забыть и помнить кто где аллоцировано, а что ещё нет.
Ты должен написать только defer allocator.free(memory) И ВСЁ. Компилятор сам вызовет освобождение памяти ВО всех точках выхода из функции!
А как в Rust НЕ вызывать деструктор? Например у меня есть память, я туда пишу и знаю что если я возвращаю ошибку, дальше в коде она полностью будет перезаписана другими данными! Мне не нужно её тут обнулять (в других местах нужно).
А, нельзя?)))
> Но вот почему-то ни один сишник еще не справился с такой элементарной задачей
Потому что в С ты должен освобождать ресурсы во всех разных сложных точках выхода из функции.
И там могут быть сложные условия - array1 уже выделился, array2 тоже, а на array3 память выделить не получилось - освобождаем array1 и array2. А в других случаях нужно освобождать только array1 (валимся на выделении array2) и так далее.
Код получается очень сложным, громоздким. Легко ошибиться. И код получается нелинейным.
> Ну и так далее продолжаем выходить за пределы массива, писать что угодно куда угодно и ловить RCE.
Ответил выше. Ни за какие пределы ты не выйдешь никуда.
> А как в Rust НЕ вызывать деструктор?Используй mem::forget.
> Например его exception при unwrap - а это hidden control flow. В Zig ошибки возвращаются только как возвращаемое значение.Ты не поверишь, но в Rust ошибки тоже возвращаются только как возвращаемое значение. Но ты даже не удосужился почитать, что такое unwrap и кинулся воевать против Раста.
Чел, ради бога, не разводи цирк. Твой уровень знания Раста все уже и так увидели в соседней новости о спутнике.
https://doc.rust-lang.org/rust-by-example/error/option_unwra...Читаем)
Далее идём сюда https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...
и читаем
> When code panics, there’s no way to recover.
Ты смотришь в книгу и что там видишь? Даже не понимаешь смысл того что процитировал.
Ну, unwrap() на None ошибку вернёт? Не вижу возврата ошибки что там должно быть Some(x) 😆 Не очень похоже на безопасный язык.
Вот в Zig все, любые ошибки возвращаются, ну если ты не вызовешь os.abort() или os.exit() явно.
> Ну, unwrap() на None ошибку вернёт? Не вижу возврата ошибки что там
> должно быть Some(x) 😆 Не очень похоже на безопасный язык.Ты несешь какую-то чушь /_-
Если приложене упало - то пусть падает.
Лучше out-of-service чем получение рута.> Вот в Zig все, любые ошибки возвращаются, ну если ты не вызовешь os.abort() или os.exit() явно.
И что же делать если программа пришла в состояние невозможное из которого исправить ничего нельзя?
> И что же делать если программа пришла в состояние невозможное из которого исправить ничего нельзяВ каком состоянии программа и что делать при "невозможном" состоянии решать... наверное программе, а не какой-то там библиотеке?
В этом весь point. А тебе тихонечко вызовут unwrap() на None 😆
Про panic() из самого (конечного) приложения естественно вопросов и претензий нет. Конечно такие состояния возможны.
В Zig есть ключевое слово unreachable. Те "никогда никогда это условие не будет выполнено".
Таааак подожди...
https://doc.rust-lang.org/stable/std/alloc/struct.Global.html
А это что ещё за хрень???В самом безопасном языке в мире можно вызвать new_uninit() которая вернёт неинициализированную переменную??? И функция даже не помечена как unsafe?
Это такая безопасность у Rust?)
Я на такую хрень натыкаюсь в Rust постоянно. Везде есть небезопасные методы которую всю эту безопасность ставят раком 😆
Вы защищаетесь от программиста-идиота, который даже с указателями корректно не может работать.
Но при этом можно создать неинициализированную переменную???
Так new_uninit() возвращает MaybeUninit<T>, для которого assume_init() как раз unsafe.
И да, rust защищает от программистов-идиотов, которые даже читать не умеют.
> В каком состоянии программа и что делать при "невозможном" состоянии решать... наверное программе, а не какой-то там библиотеке?Твоя библиотека на Ziz получает что-то из этого списка в рантайме
https://ziglang.org/documentation/0.1.1/#undefined-behavior
например Cast Negative Number to Unsigned Integer и что она делает?
Она безусловно крашится!
At runtime crashes with the message attempt to cast negative value to unsigned integer and a stack trace.Как программа на том же Zig будет обрабатывать такой случай? Ну "все ж ошибки обрабатываются" и прочие сказки венского леса.
Здаётся мне "это фиаско, братан!"> В самом безопасном языке в мире можно вызвать new_uninit() которая вернёт неинициализированную переменную??? И функция даже не помечена как unsafe?
Кажется слово MaybeUninit тебе вообще ничего не говорит? /_-
Ты бы хоть доку читал дальше заголовка.
> Далее идём сюда https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...А предыдущую главу с говорящим названием "Recoverable Errors with Result" ты решил тактично пропустить? А зря: в ней есть раздел "Shortcuts for Panic on Error: unwrap and expect" в котором ты бы мог наконец-то узнать, что такое unwrap() (собственно, ответ уже в названии).
https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...
> Не вижу возврата ошибки что там должно быть Some(x) 😆
Потому что ты читаешь о Option а не Result, не?
А "These cases can either be explicitly handled via match or implicitly with unwrap" мы тактично пропустили, да?
Что ж, Витюшка наконец-то открыл документацию Раста - уже прогресс...
Ты как-то плаваешь в Rust, друг мой.
> ты решил тактично пропустить...А что там обсуждать? Мы говорим о panic(), который вызывается при unwrap(). При чём тут обычные возвращаемые значения из функции?
Вот вызываю я функцию библиотеки, она откуда-то получает option. Вызывает на нём unwrap() и я получаю панику. При том сама функция естественно может возвращать Option (но в других случаях).
Я конечно бы обработал возвращаемое значение, только панику не обработать. Или я не прав?
Тоже самое касается Result. unwrap() на Result это паника при Err().
И почему в таком супер безопасном языке, где защищаются именно от программиста дурака, который и с указателями и индексами не может справиться, можно просто взять и вызвать unwrap() и кинуть панику? Притом случайно, непреднамеренно.
Вот они аргументы (кого-то выше) "но есть же unwrap_or()" меня умиляют.
Да, есть. Это типа "Пиши просто сразу безопасно", из такого разряда? Так и в С можно писать сразу безопасно и проверять указатель на NULL везде.
Супербезопасный язык, который позволяет кидать паники налево и направо вместо того чтобы заставить обработать ошибку (и возможно там кинуть панику - но это уже будет явно и осмысленно, а не случайно по недосмотру) и создавать неинициализированные переменные 😆 - смотри вопрос выше сообщением твоему коллеге.
Вот эти аргументы "но это же не пройдёт код ревью!" думаю понимаешь что очень слабые. В С++ тоже не пройдет 😆
При этом этот же программист должен использовать методы без паники (ой...так они ещё и не помечены как unsafe???? Это каааак так???), но не в состоянии не использовать переменную после того как она была перемещена в функцию?
Что ж ты так позоришься своим незнанием(((
Ты главное больше смайликов ставь
Это всё потому что ты и такие как ты неосиляторы пытаетесь на расте писать в стиле Си. Архитектуру приложения надо другой делать, "не Сишной". Потому что "сишные архитектуры" и приводят к "сишным проблемам". Причем раст тебе позволит писать и в сишной манере, но тогда, конечно, как ты тут упомянул, всё будет измазано в ансейф. И ошибки вернутся старые, но виноват у тебя окажется раст.
> Например когда несколько указателей из разных потоков владеют хитрым образов куском памяти.Точняк... А потом случается рэйс кондишн и вот мы уже читаем очередную новость про очередное CVE, а опеннет-иксперды вроде тебя под такой новостью пишут в комментах (в очередной раз), что и на сях можно писать безопасно (только свой "безопасный" код длинее хэлло_ворлда никогда не показывают).
Сорян, но ты не умнее борроу чекера и тех, кто его писал. Так оказывается в 100 случаях из 100. И если он с тебя требует доказать, что там корректно, значит ты написал так, что у тебя там потенциально некорректно: ты как писал свой сявый код с потенциальными UB, так и на расте его продолжаешь пытаться писать. А оно тебя по руках (кривым не из плеч растущим) лупит, да.
Некоторые не выдерживают того, что им себе в ногу стрелять не дают и убегают назад дальше CVE и прочие use-after-free плодить, некоторые - начинают пистаь более безопасный код. Не потому, что раст весь из себя какой-то такой волшебный, а потому, что не даёт писать твои любимые потенциальные CVE. Просто заставляет пистаь код лучше либо прямо объявлять с помощью unsafe секции, где ты будешь гуанокодить. И их потом хорошо видно.
Но и как правильно такое переписать на твоем святом, ты тоже не сказал.
Такое это какое? Вопрос мне? Корректность зависит от самого алгоритма и других метаданных.Например у каждого потока может быть указатель на массив в который он пишет. Параллельно. Но эти сегменты (array[x], array[y]) никогда не пересекаются. Это может быть ring buffer.
Но при этом каждый поток может читать данные других потоков.
Теперь возможно что поток прочитает недозаписанные данные другого потока. Это решается с помощью read-write mutex для каждого сегмента.
Напишите мне эти проверки с помощью borrow checker на Rust? 😆
> Проблема в том что я в 100 раз умнее borrow checker. Это только васяны с hello world на Rust рассказывают о том как там всё безопасно.Ну, кто бы сомневался. Чел, у тебя тяжелая форма Даннинга-Крюгера.
Давай, продолжай рассказывать захватывающие истории о своих воображаемых хэллоуворлдах на Zig, который и до версии 1.0 не дозрел и не используется никем в индустрии.
> Но эти сегменты (array[x], array[y]) никогда не пересекаются.А кто или что это гарантирует не в раст, а напр. в си или зиге или с++?
Оно так просто потому что "мамой клянусь, никогда не пересекаются!" А если вдруг таки пересекутся, то что?))Если да, то компилятору ты ничего не докажешь, потому что твоим словам веры нет)
Пиши unsafe и делай что нужно. Только не забудь написать коммент с обоснованием почему оно так.
Ну ты циклы писать умеешь? А if else писать умеешь? И кто гарантирует что ты их корректно и правильно написал?Rust это умеет делать???
Что же Rust вас от этого не защищает? Вы же несмышленые, вдруг напортачите?
Или ты думаешь что если ты отнимешь вместо прибавления от банковского счёта, то ничего страшного?
> Оно так просто потому что "мамой клянусь, никогда не пересекаются!" А если вдруг таки пересекутся, то что?))
Потому что ты каждому потоку выделяешь индекс в массиве и выделяешь массив с количеством потоков.
Да, сложно. Нужно num_threads() * kbytes!
> А если вдруг таки пересекутся, то что
А вдруг true false перепутал, а вдруг if else не в состоянии правильно написать?
Смотрю сильные серьезные аргументы начали заканчиваться.
Остались "великий и могучий borrow checker" которого нужно слушать, а я дурак 😆
И какая-то иррациональная вера что кто-то (например Rust) будет за вас писать (и гарантировать) корректный код 😆
> Только не забудь написать коммент с обоснованием почему оно так
Так (условный ты) ты же дурак? Откуда у тебя обоснования "почему оно так", если ты даже за указателями уследить не можешь? Как ты докажешь корректность кода, если надеешься на компилятор, что он тебе магически должен гарантировать непересечение массивов и чего-то там ещё?
unsafe будут писать дяди из С++ и С. Которые знают как работают компьютеры, знают алгоритмы и знают как выжать из компьютера максимум.
> Смотрю сильные серьезные аргументы начали заканчиваться.Аргумент "я выдумал задачу, а она в парадигму раст не влазит" - это не серьезный аргумент.
> а я дурак 😆
Тут я с тобой соглашусь.
> unsafe будут писать дяди из С++ и С. Которые знают как работают компьютеры, знают алгоритмы и знают как выжать из компьютера максимум.
Насмотрелись мы на этих дядей, которые не могут строку сплитунть без уязвимости. Или за пределы буфера выйти.
Или выжать из компа максимум ценой уязвимости прям в процессоре.
Спасибо нам такие клоуны уже надоели.
Проблема в том что я в 100 раз умнее borrow checker. Это только васяны с hello world на Rust рассказывают о том как там всё безопасно.Потому что Rust в лучшем случае делает доступ безопасным с ячейке памяти, а не к СТРУКТУРАМ ДАННЫХ. Но структуры данных то ты никогда не писал 😆 Остановился на примитивных ошибках.
Borrow checker Rust это набор простейших, примитивных правил. Ну...если ты не умнее 3х правил, которые умещаются в одном блог посте...ну что я могу тогда сказать 🤦🏻♀️🤷🏻♀️ Любители Rust даже не знают собственного языка 🤨 Они ВЕРЯТ в него и что он безопасный.
Там вся идея строится на read-write lock-ах, которые защищают конкурентные данные. Читать ты можешь параллельно сколько хочешь (multiple borrow), писать может только один (exclusive borrow/lock). Вот и весь Rust 😆
> Например когда несколько указателей из разных потоков владеют хитрым образов куском памяти.Чего? Несколько указателей владеют одним куском памяти? И Раст, сволочь, не дает тебе писать такую дичь, я правильно понял?
Совершенно верно. Это внутрянка безопасной структуры данных, например concurrent hashmap или любой многопоточной параллельной структуры данных.Я сам проверяю все инварианты и корректность кода. Там может быть несколько разных сегментов памяти (массивов). А на выходе ты получаешь абсолютно безопасную корректную структуру данных.
Rust умеет это делать? Умеет проверять инварианты за меня?Ну и что что он сделает "безопасным" доступ к одному массиву??? Это же не сделает код безопасным и потокобезопасным? Если, например, другой поток запишет в это время в другой массив или захватит на нём lock (deadlock)?
Странно что нужно объяснять такие вещи защитникам Rust.
И теперь чтобы написать что-то сложнее hello world, нужно писать кучу boilerplate, unsafe и так далее. Я лучше тогда JavaScript возьму. Будет безопаснее)
> Совершенно верно. Это внутрянка безопасной структуры данных, например concurrent hashmap или любой многопоточной параллельной структуры данных.
> Я сам проверяю все инварианты и корректность кода. Там может быть несколько разных сегментов памяти (массивов).Ну так написал "я сделяль свой велосипед, он работает корректно, мамой клянусь"
> А на выходе ты получаешь абсолютно безопасную корректную структуру данных
Громкие слова, очень громкие для кого-то, кто считает гарантии компилятора магией.
Более того Arc<T> + Mutex<T> и RwLock<T> должны позволить реализовать твою хотелку.> И теперь чтобы написать что-то сложнее hello world, нужно писать кучу boilerplate, unsafe и так далее. Я лучше тогда JavaScript возьму. Будет безопаснее)
Внезапно, я с тобой соглашусь, лучше пиши на JS. Там можно не только память пердолить со всех сторон одновременно, но даже к строке прибавлять инт.
Представь себе, велосипеды пишут потому что никаких "готовых" структур данных нет.Например тебе нужна хэш-таблица с поддержкой диска. Пишешь свою родненькую. Там пишут все лучшие величайшие программисты мира (поднимаю ставки троллинга 😆), во всех базах данных свои структуры данных, даже свои мьютексы.
Или авторы MySQL, PostgreSQL и MSSQL это васяны со своими велосипедами? 😆😆😆
Конечно для твоего hello world подойдёт и то что в стандартной библиотеке 😆
Нет, Arc<T> + Mutex<T> и RwLock<T> НИКАК не помогут. Они защищают только один объект/структуру, считай одно поле структуры.
А...ты предлагаешь лочить всю высокоуровневую структуру данных? Ну, такой ***код не пройдет 😆 Ты сейчас сделал из многопоточной однопоточную программу где все +- ждут друг друга 😆
Например это индекс базы данных. Те ч должен залочить ВЕСЬ индекс для одной операции?
Я ожидал большего от фанатиков Rust.
> Например у каждого потока может быть указатель на массив в который он пишет. Параллельно. Но эти сегменты (array[x], array[y]) никогда не пересекаются. Это может быть ring buffer.
> Но при этом каждый поток может читать данные других потоков.
> Теперь возможно что поток прочитает недозаписанные данные другого потока. Это решается с помощью read-write mutex для каждого сегмента.Ладно, возможно у тебя очень специфическая задача. Сколько таких в ядре линукса?
Нужно ли отказываться от дополнительного языка если на нем сложно/невозможно сделать такую конструкцию?> Например тебе нужна хэш-таблица с поддержкой диска. Пишешь свою родненькую. Там пишут все лучшие величайшие программисты мира (поднимаю ставки троллинга 😆), во всех базах данных свои структуры данных, даже свои мьютексы.
> Или авторы MySQL, PostgreSQL и MSSQL это васяны со своими велосипедами?Парирую троллинг пруфами)
выполнения кода при обработке в СУБД SQLite определённым образом оформленных SQL-конструкций https://www.opennet.dev/opennews/art.shtml?num=52084
Критическая root-уязвимость в MySQL https://www.opennet.dev/opennews/art.shtml?num=45127
> Я ожидал большего от фанатиков Rust.
Вот только фанатиком тут выглядишь ты.
У тебя есть супер "особенная" задача. Которая судя по описанию, мало кому нужна за пределами баз данных. И ты "мая задачка не решается языком! плак плак! Раст плохой"Причем в качестве альтернативы приводишь Зиг на сайте которого прямо пишут https://ziglang.org/learn/overview/
Please note that Zig is not a fully safe language
Multithreading safety and race detection are areas of active research.
Более того говорят что operator overloading это плохо... ну удачи им в большом проекте)
In order to accomplish this, Zig programmers must manage their own memory, and must handle memory allocation failure.А дефер-то оказывается есть? А как же "no hidden control flow"! Неужели они пошли против своих принципов.
In addition to A fresh take on error handling, Zig provides defer and errdefer to make all resource management - not only memory - simple and easily verifiable.Т.е писать ты будещь в СИ стиле, память менеджить ручками (привет ошибки), только сменится интаксиc языка. Ну и нафиг менять шило (СИ) на мыло (Зиг) ?
Думаю мейнтейнары ядра тоже так подумали.
> А дефер-то оказывается есть? А как же "no hidden control flow"!Мы про одно и тоже говорим? Кажется я уже выше подробно отвечал, возможно не тебе.
В defer нет hidden control flow. Я описал выше почему. Ты его видишь в функции, он ЯВНЫЙ. А деструкторы неявные. И пока ты туда не заглянешь - не узнаешь что и как они там освобождают.
Более того постоянно приходится туда смотреть чтобы понять что именно там он освобождает. А ещё может выкинуть exception в С++. Ну в Rust, который содран с С++, всё +- также должно быть.
> Парирую троллинг пруфами)
Я там выше накидал пруфов как в безопасном языке в стабильной версии 1.44 можно сделать
let i: i8 = -1
let k: u8 = iИ получить "переполнение" или как там правильно это назвать. Настолько он безопасный) Тихо, незаметно, без ошибок.
> Т.е писать ты будещь в СИ стиле..
Выше я ОЧЕНЬ подробно написал насколько Zig безопасный, сколько гарантий и проверок он даёт (больше чем Rust) и что он БЕЗОПАСНЕЕ чем Rust.
Добавлю ещё const по умолчанию для всех параметров функций и переменных.
Он в сотни раз безопаснее С. Но при этом более низкоуровневый чем С! Или все эти проверки для тебя "тоже самое что и С"?)
Память ты ВСЕГДА менеджишь ручками в Rust и C++, просто неявно, это не managed языки.
И очень-очень плохо 😆 По простому это говнокод и костыли.
> Думаю мейнтейнары ядра тоже так подумали
Те в ядре норм что какой-то там деструктор будет рекурсивно (!) вызываться хрен знает когда, когда его даже не просили об этом?) Это там где есть обработчики прерывания и очень важен максимальный перформанс и надёжность?
Или мне нужно освободить страницу памяти КАК МОЖНО быстрее, я пишу page.Drop(), а потом деструктор всё равно вызывается, хотя он нахрен не нужен 😆 И внутри у меня стоит if (flag) { free() } чтобы он второй раз не освободил память 😆
Это из реальной жизни. Все эти "абстракции" типа "итераторы", "конструкторы/деструкторы", перегрузка операторов, перегрузка функций, шаблонные функции и весь template код всё это лютое #@&!.
Это лютейший over engineering. Для 2000х Rust был бы неплох.
У Zig это всё сделано значительно лучше. Даже типа строка нет. Потому что никаких строк нет нигде. Есть просто набор байт и их интерпретация (кодировка). Справится любая библиотека. Нет "методов", есть только функции с "сахаром" в виде объект.функция().
> Please note that Zig is not a fully safe language
Покажи мне ХОТЬ ОДИН в мире безопасный (по-настоящему) язык программирования. Знаю 20 языков программирования, и ни одного безопасного.
> Multithreading safety and race detection are areas of active research
Аналогично. Это active research не только в языке, а вообще в мире в индустрии. Или где-то решена эта проблема?
Насколько я знаю лучшее что ты можешь делать - прогонять тесты на всём чём только можно месяцами и надеяться что бага, если она есть, выстрелит.
Lock-free алгоритмы даже в научных статьях неправильные, некорректные, с ошибками (не моё мнение, эксперта
)😆 Как говорится, welcome to real world, из однопоточного джаваскрипт-манямирка.Вообще ты должен бы это всё знать, хотя бы на уровне "active research".
Это не значит что в языке не работают мьютексы или атомики. Это значит долгое вдумчивое ВГЛЯДЫВАНИЕ в код. И никакой Rust тебе не поможет. Или лови месяцами ошибку на тестах.
Это касается любого языка программирования где есть потоки.
> Более того говорят что operator overloading это плохо...
Ядро Linux - 40 миллионов строчек кода.
Ну-ка, расскажи мне про перегрузку операторов и на что ты там перезагружаешь операцию + ? Как-то не смог найти применение в жизни этой "фичи".
Вот складываешь ты int + int и всё хорошо, а потом тебе прилетает строка в шаблонную функцию и ты сравниваешь две гигабайтные строки 😆 Надёжно, быстро, безопасно 😆
Если ты про перегрузку функции - это бесполезная и глупая фича. Но иногда бывает полезна и нужна, иногда.
В Zig ты пишешь функцию, которая принимает аргумент anytype. И проверяешь этот тип как хочешь. И вызываешь для int +, для строк concat, и ничего для остального.
Во время компиляции будут сгенериррваны супероптимизированные функции под эту задачу. Одна работает только с int (как пример), вторая только со string.
Это как если бы ты руками эти две функции написал.
Ты можешь проверить любые типы, исследовать и проверять их как угодно. Например, функция, которая принимает структуру, у которой как минимум три поля, и одно из них int.
Попробуй на Rust такое написать 😆
У С++ многие вещи только только появились, if constexpr и так далее
> In order to accomplish this, Zig programmers must manage their own memory, and must handle memory allocation failure.
А что, если у тебя памяти нет, Rust тебе как-то поможет? Или ошибки выделения памяти уже в Rust обрабатывать не нужно?)
> Нужно ли отказываться от ...
Я считаю что у Rust была хорошая задумка, а реализация полное ...
Будут лучше языки для ядра. Но Rust займёт его место, а зоопарка Торвальдс не допустит - остальные на помойку.
Если это не так, то в целом я ничего против не имею. Я так, набросил чтобы поспорить и поболтать, прокрастинация такая.
Но Zig для ядра лучше подходит.
> постоянно добавляют фичи, которые делают то же самое, что предыдущие версии фич. В результате язык быстро развивается, но программистам на нём приходится помнить всё это многослойное наслоение мусорНу ты прям Вулкан описал
> Кстати, читал как в Zed говорят Rust очень сложный, поэтому у нас всё тормозит 😆Что, прямо так и говорят "у нас все тормозит из-за Раста"? А ссылочку можно?
https://zed.dev/blog/zed-weekly-29А я прям так написал? Вроде я написал что тормозит из-за того что
не могут поменять аллокатор, где нужно (не глобальный). А не могут потому что вот эта... с lifetime rules.Поэтому проще использовать глобальный аллокатор (медленный) для вызовов многих мелких объектов.
При этом я уверен они не дурачки совсем и знают что их код был бы корректен. Но объяснить компилятору не могут.
> Кстати, читал как в Zed говорят Rust очень сложный, поэтому у нас
> всё тормозит 😆 Аллокации делать не может из-за lifetime rules.Аллокации в рантайм - источник довольно бошльшого числа проблем. И чему вы так радуетесь в wannabe-системном языке на эту тему - я не понимаю. Если zig этим стал заниматься - упс, значит как системный ЯП он станет непригоден скорее всего.
Вы всегда можете сделать одну аллокацию памяти в глобальный аллокатор вначале.Обернуть это в свой BumpAllocator, который по сути ничего не аллоцирует, только смещает указатель свободного места. И ничего не делать при free().
Всё! Абсолютно вся ваша программа работает со статической памятью. 0 динамических аллокаций памяти.
Тк у функций нет неявного доступа к аллокатору типа malloc.
> Ранее также был представлен прототип драйвера rust-e1000 для Ethernet-адаптеров Intel, переписанный на Rust.Дак он и на C прекрасно работал, в чем смысл?
Так безопаснее же
Ну ты сравнил - дырявую сишку и безопасный раст.
Плюс нужно же с чего-то начинать.
В переписывании.
Прежде чем переписывать там еще много чего нужно ДОписать, но нет.
Ты когда меняешь сантехнику (например туалет типа ʼдырка в полу и ведроʼ на нормальный компакт, или даже на японский унитаз с мойкой и mp3 плеером) тоже спрашиваешь "прекрасно работал, в чем смысл?" ?Любой ремонт, это переделка, но народ как-то не жалуется (кроме перекладывания плитки)).
Ну вот, так и с ядром, нужно немного подремотировать, заделать накопившиеся дырки.
Унитаз с мойкой встроенный в кухонную мебель.
> Унитаз с мойкой встроенный в кухонную мебель.Разводится мужик с женой.
- Судья: а чего разводитесь то?
- Да она у меня такая неряха! Представляете, встаешь среди ночи, собираешься в раковину поссать, а там - целая гора посуды!
Действительно, складывать посуду в раковине в ванной - это кем надо быть?
А кто сказал про ванную комнату?
Может чел на кухню зашел.
Только вот дырка в полу намного полезней для организма. Это вам любой врач скажет.
Это антисанитария. Ни один нормальный врач такого не скажет. Как и си - антисанитария. Не думаю, что раст - это решение, но ситуация точно пора если не закопать, то ограничить использование.
Смысл в запихивании зондов поглубже, пора бы уже понять.
Тебе же в новости написали "зачем", но у тебя что-то с глазками?"Драйвер ... позиционируется как простой рабочий пример для создания сетевых драйверов на языке Rust, готовый для использования с реальным оборудованием."
Премия за бестолковое переписывание существующего сама себя не получит.
Это такое замаскированное предложение от раст-евангелистов: мы вам сами драйвера писать не будем и не умеем, вот наш замечательный язык, пишите на нем, а мы дальше побежим Раст проповедовать. Короче рассчитано на дурачка.
Давайте лучше - драйвер NTFS и на Си.
NTFS это не лучше.
Это рак и дно.
Не зависимо, от критики или похвал, он востребован.
Рак и дно это нескучные альтернативные ФС с багами и потерей данных
уже есть же
И потом опять годами уязвимости от выходов за пределы массива вычищать?
Не, спасибо...
> Давайте лучше - драйвер NTFS и на Си.Их в линухе уже 2.5 штуки есть?! Половинка - это который на FUSE. И еще 2 ядерные. Тебе мало?!
То есть, если дадут NTFS на расте, то пользоваться принципиально не будете, даже если все будет хорошо работать?
Я вообще не понимаю хейтеров раст, если вам приносят на блюдечке (опенсорс же), вам пофиг на чем написано, главное, что бы работало. Но как же не насрать в комментарии?
Маленький ещё. ВыРАСТешь - поймёшь.
А мне - нет, не всё равно. Когда я делал сборку Миранды, я брал плагины, написанные только на C/C++, хотя были горы их на Delphi,.NET и ещё каком-то новне. Когда я ставлю кеды, я пользуюсь софтом только на Qt и даже KMail вместо Thundercrap. Всё должно иметь порядок. А у тебя весь мир на хейтеров и нехейткров делится. Не все такие полярные. Вернее, большинство.
Это шутка такая от растаманов? Где там, блин, драйвер?
Это не шутка. Это пиар.
Вот драйвер https://github.com/AsahiLinux/linux/tree/gpu/rust-wip/driver...
В каком-то левом форке, я тоже так могу "добавить в ядро" что угодно.
https://github.com/fujita/rust-realtek-phy/blob/master/rust_...
Вот драйвер)
Растоманы врут, а потом удивляются, что людям не нравится их язык. Нет никакого драйвера, потому что в 135 строк драйвер не уложить!
Это драйвер. Просто вы не поняли драйвер чего.
Отличный язык, позволяет безопасно работать с памятью. С растом Линукс станет еще безопаснее!
> Отличный язык, позволяет безопасно работать с памятью. С растом Линукс станет еще
> безопаснее!Но это не точно
С Растом Линукс станет ещё более лучше!
> С Растом Линукс станет ещё более лучше!не станет. Linux вообще с каждым годом становится только хуже. Особенно хорошо это заметно на старом железе, когда на 10 вкладках Firefox система может повиснуть намертво если выйдет за пределы оперативной памяти (при этом на бумаге более прожорливая Винда работает без проблем, если не задаться целью её повесить). ZRam может хоть как-то исправить ситуацию (но всё равно хуже). Проблема древняя, решается до сих пор костылями. Зато Rust в ядре выдаётся за достижение (какое?).
> Linux вообще с каждым годом становится только хужеА вот и адепты "раньше было лучше" подъехали)
Когда это было лучше? Сколько лет был эпичнеший баг 12309?
А я тебе напомню, его записли еще в 2008 году bugzilla kernel org/show_bug.cgi?id=12309
И починили (но это не точно) аж в 2023.
А как раз лиса именно из-за него могла тупить минутами
"Ранее, операции сброса кэша обратной записи приводили к существенному снижению отзывчивости интерфейса приложений, подобных Firefox, вплоть до невозможности нормальной работы в течение нескольких минут."
тут обсуждали https://www.opennet.dev/opennews/art.shtml?num=46035
Firefox здесь просто для примера, на его месте может быть любое другое приложение или любой другой браузер. Проблема в том, что само ядро Linux не обрабатывает корректно ситуации нехватки памяти и вешается полностью (эта тема кстати и на Opennet проскакивала, не говоря о том, что вся сеть этой проблемой пестрит), дошло уже до того, что Blender под Винду работает лучше в тяжёлых сценах, т.к. всегда есть риск просесть по памяти (даже если её предостаточно) и вся система повиснет безвозвратно. На старом железе систему (особенно из коробки, без дополнительных настроек) может повесить любой браузер (и после этого некоторые удивятся, почему Linux непопулярен на десктопах и вообще мрак на ноутах). Пользователь (даже с высокой квалификацией и потенциалом исправить ситуацию хоть частично) не обязан тратить своё ЛИЧНОЕ ВРЕМЯ на то, что разработчики десятилетиями не решают проблему (пользователь может сделать костыльные решения в виде более тонкой настройки свопа и zram). Поэтому Linux как явление уже давно плох и деградировал и совершенно пофиг, что там у него в ядре по большому счёту (хотя Rust в ядре - это отдельный вид фарса, т.к. просто концептуально мультиязычность - это плохой дизайн).
Та я понимаю что это за ошибка и как весело смотреть на "зависший" UI.
Я хотел донести, что линукс овно уже очень давно.
Так что раньше лучше не было)
А если вспомнить 200е, 90е и раньше, то там местами вообще мрак и содомия.Просто в линуксе каждый пишет то, что ему нужно, прийти к какой-то команде (интел/самсунг/и тд) и заставить их сделать что-то невозможно.
Напоминет басню про "лебедь, рак и щука" - каждый тянет на себя и куда-то уныло ползем (по сумме векторов сил).
А в проприетаре могут посадить команду и сказать ловить маловоспроизводимый баг. И они его будут ловить неделю, месяц,... на сколько денег хватит из заложенного бюджета.
И возможно найдут и поправят.
В таком случае мы с вами практически на одной стороне, но с оговоркой, что раньше Linux был не единственным проблемным софтом, особенно на фоне древней винды. И особенно цинично это выглядит, когда памяти у железа стало больше и само железо стабильнее, при этом системные ресурсы пользователь контролировать должен самостоятельно (это же нонсенс, когда не ОС контролирует системные ресурсы, а пользователь должен думать сколько памяти на что потратить, чтобы это чудище не повисло намертво). И я не думаю что что-либо изменится к лучшему. Скорее будут продолжать местечково переписывать через unsafe всякие мелочи на Rust изображая рабочую деятельность и усложняя жизнь тем, кто любит собирать всё самостоятельно. Тут уже даже плевать кто и сколько финансирует, уже больше похоже на отмывание денег.
> пользователь должен думать сколько памяти на что потратить, чтобы это чудище не повисло намертвоВозможно проблема архитектурная и для решения нужно просто переписать ядро заново.
> Скорее будут продолжать местечково переписывать через unsafe всякие мелочи на Rust изображая рабочую деятельность и усложняя жизнь тем, кто любит собирать всё самостоятельно.
Сколько ошибок в ядре вида "я тут строку распарсил криво, теперь гуляю по чужой памяти"?
Это можно исправить - уже станет лучше.А на тех "кто любит собирать всё самостоятельно" - мне объективно пофиг, любят пердолится - пусть пердолятся.
Это не линукс становится хуже, это ваше древнее железо становится всё более древним. И под ваши некрофильские потребности никто подстраиваться не должен и не будет.
Во-первых, не такое уж и старое, особенно если речь идёт про ноутбуки, где железо чаще менее мощное, чем на стационарнике, во-вторых, почему-то в Microsoft и Apple озаботились о том, чтобы из коробки без дополнительных патчей ядра менеджмент памяти и процессов был адекватен и не вешал юзерспейс в большинстве случаев. В Linux же (не *nix, в данном случае), новое железо подглючивает потому что оно новое, а старое плохо работает, потому что оно устарело и вот так в Linux во всём, принципиально важные проблемы, которым уже чуть ли не десяток лет не решаются, зато у нас тут Rust в ядре, не вносящий по факту ничего полезного и не решающий реальных задач и проблем. Так что говоря про "некрофильские потребности" - это оправдание тех, кто не может сделать стабильную систему, либо регламентировать аппаратные требования. Отдельная тема - это виртуалки, которые также успешно виснут, что нужно заранее предугадывать и обеспечивать иные средства контроля над ресурсами, потому что сама система это делает из рук вон плохо.
Юзер кейс как я понимаю такой: на П4 запустить 10 виртуалок которые не помещаются в память и параллельно смотреть ютубчик и чтобы ничего не тормозило, не падало и была отказоустойчивость. Ничего не забыл?
Забыл что на ноуте еще будет старый медленный hdd.
>Linux вообще с каждым годом становится только хуже. Особенно хорошо это заметно на старом железе, когда на 10 вкладках Firefox система может повиснуть намертво если выйдет за пределы оперативной памятиТак эта проблема всегда была... Просто Firefox начал столько жрать что эта проблема стала сильно актуальней
Стоит начать с того, что такое "старое железо"? 10 лет? На реально старом железе (то есть, 10+ лет) Винда, та которая выше XP, если и заведется, то будет ползти медленнее черепахи, не говоря о зависании. Сам в каком-то 2016 году ставил на ноут, которому тогда было лет 9, Виндовс 7 и 8: они оба работали просто жутко медленно. На той машине единственное, что нормально работало из Виндовс, была ХР. Линукс на том железе тоже работал не ахти как быстро, но тем не менее с Window manage вместо DE на нем можно было что-то делать.А продолжу я тем, что это - не Линукс тормозит, а браузеры и DE делают все более прожорливыми. То, что ты завел старую Виндовс (скорее всего ХР) на старом железе и запустил на ней старую версию браузера, которая в то время была менее прожорлива, никак не говорит в пользу Виндовс вообще, потому что если на то же старое железо установить Линукс с браузером, год выпуска которого соответствует году выпуска твоей старой машины, он тоже будет хорошо работать.
Ложь. У меня на старом нетбуке Windows 10 не только завелась, но и работает гораздо лучше, чем любой современный дистрибутив Linux (что довольно фигово, учитывая что Linux мне нужнее по иным причинам). Во-вторых, на более современном ноуте Linux всё равно показывает себя хуже под нагрузками, под другим постом я уже писала о причинах. У Linux плох менеджмент ресурсов по памяти. Он запросто может начать swap горячих данных и повиснуть на ровном месте (и здесь как раз и дошло до того, что даже Windows 10 может дать пользователю управление, либо самостоятельно убить зависший процесс, в то время как на Linux намертво виснет всё, включая доступ к Терминалу). +Ещё можно отправиться к старому спору Линуса и Таненбаума о монолитном и микроядре. На перспективу монолитное ядро Linux как раз пришло к тому, что это неуклюжая виснущая помойка, при этом Windows 10 хоть и также считают монолитным ядром, но внутри ядра есть ещё микроядро с ограниченными функциями, но максимально возможной стабильностью. У меня Linux стабильно работает только на основной железяге, у которой 64 Gb системной памяти, но это у меня. У знакомых 3Dшников, некоторые из которых идейные OpenSource гики, Blender под Linux на тяжёлых сценах к чертям вешал всю систему, что пришлось перейти на винду из-за этого. То есть в простых сценах Linux мог показывать даже лучшую производительность, но как только Linux выходит за пределы системной памяти, начинаются чудеса и зависон в один конец. Поэтому Linux как система несётся к закономерному финалу, здесь не важно какой ещё мусор добавят в ядро и на каком языке этот мусор будет написан, сама идея монолитного ядра себя не оправдала, хотя всё равно многие будут биться головой об стену и доказывать, что Linux - это годнота и стабильность. Я не знаю как из этого будут выруливать, учитывая не только технические сложности, но и толпы фанатиков у которых "всё хорошо".
Каждый выпуск Rust компиялятора обновлять разве нормально? Причем завязано все на cargo репозиторий, доступ к которому могут отрубить в Чебурнете. В качестве зависимостей ядра только тарболы подходят. Происходящее - диверсия не иначе.
В ядре какой-то не совсем такой руст. Там, вроде, карго нет, да и стандартная библиотека не совсем раст. Так что не всё так однозначно.
А потом выяснится, что и безопастности реальной нет, потому что все в ансейфы обернуто.
Хм... у гугла стало безопаснее, у амазона тоже, а у Анонима нет.
Срочно отменяйте! У нас тут непризнанный гений!> все в ансейфы обернуто.
Оно исправит высокоуровневый код, тк строки в дыряшке это просто подарок для создания уязвимостей.
А низкоуровнемый код завернкутый в анскейф, ну нет у нас гарантий, что там диды на сишке написали.
Зато искать придется не по всему проекту, а только в unsafe блоках
> доступ к которому могут отрубить в Чебурнете.Неужели ты думаешь что еще остался кто-то, кому не пофиг на проблемы индейцев на болотах?
И да - можешь засунуть компилятор в тарбол.
Блокировали же nuget.org вместо телеграмма - микросоыт никак не отреагировал. А здесь меньше разработчиков будет затронуто.
>доступ к которому могут отрубить в ЧебурнетеПросто отрубить полностью - это ещё хороший вариант. А могут ведь ещё поднять "прокси" и малварь засовывать. Перед директорами бизнеса окажется 2 кресла, на одном малварь у клиентов на машине, а на втором - банкротство компании. Перед программистами тоже окажется 2 стула: на одном соучастие в оперативно-розыскных киберпреступлениях, за которое ничего не будет, максимум ссанкции против самых видных введут, а на втором увольнение с работы. Угадай, какой стул будет выбран? Подсказываю: тот, который они уже выбирали много раз.
При этом C-версия - 131 строка. А сам драйвер полная транслитерация C->rust.
Переписывание уровня /b/
Потом ещё выяснится что он и эти жалкие 100Мбит медленнее гоняет
Если вообще работает.
Чем вы читаете?> Драйвер ... позиционируется как простой рабочий пример для создания сетевых драйверов на языке Rust, готовый для использования с реальным оборудованием.
"рабочий пример", "готовый для использования с реальным оборудованием"... Или ты думаешь, что соврали?
Утверждения фанатиков раста нужно проверять до последней буквы, обычно все не так.
Охохо, а где все растохейтеры, который зубоскалили в тебе про китайский спутник?
Рассказывали, что "никогда в ядре драйверов не будет" и тд.Если для сборки ядра добавятся зависимость, надеюсь вы гордо перейдете на винду? Или будете сидеть на старом до упора?
Я тут.
> Рассказывали, что "никогда в ядре драйверов не будет" и тд.Не рассказывал, но надеялся.
> Если для сборки ядра добавятся зависимость, надеюсь вы гордо перейдете на винду? Или будете сидеть на старом до упора?
Если станет обязательной или необязательной, но много чего нужного начнет ее требовать, то уйду на фряху или на какой-нибудь форк ядра без раста.
А пока надеюсь что раст быстрее загнется чем что-либо нужное наклепают на нем. А потом одним счастливым днем "разработка на расте оказалась не востребована, весь код на расте будет удален в будущих выпусках ядра".
Врядли он быстро загнётся, но будет где-то на задворках, как SP Forth всякие
Он и так на задворках, о нем комментариев написано больше чем на нем строк кода.
> но надеялся.Без шуток интересно, на чем надежда базировалась?
Если поддержка языка идет от
1.Линуса 2.Корпов которые пишут ядров 3.Части независимых разработчиков...
Я бы наобророт сильно удивился, если бы драйвера решили не писать.> какой-нибудь форк ядра без раста.
Звучит сомнительно. Нет особого запроса.
Большинство юзеров просто скачают собранный образ от "вендора". А гентушники - вымирающий вид.Даже для Х11 (где вроде куча народу хочет остаться и не адоптить программы к вейланду) не набралось достаточно людей и компаний, чтобы организовать поддержку самостоятельно.
По большей части жалуются всякие probonopd (которые исправленные баги не убирают из списка) и любители многооконных приложений.Из относительно успешных девуан, но требования к его поддержке существенно ниже, даже чем к Х11. Нужно просто "правильно собрать имеющееся", и можно гордиться своей борьбой с систеМДой (бадумтц))
> "разработка на расте оказалась не востребована, весь код на расте будет удален в будущих выпусках ядра"
Боюсь вероятнее будет "новый код в ядро принимается только на Rust, поддержка старого разрешается на С"
> Без шуток интересно, на чем надежда базировалась?
> Если поддержка языка идет от
> 1.Линуса 2.Корпов которые пишут ядров 3.Части независимых разработчиков...
> Я бы наобророт сильно удивился, если бы драйвера решили не писать.1. Не идёт. Моё мнение что Линус просто не может отказать, иначе это приведет к появлению форка, а это главное с чем Линус должен бороться. Лучшее что он может сделать это согласится и тормозить (что похоже и происходит).
2. Корпы это мелкософт и гугл. Оба известны тем что молниеносно прикапывают свои проекты.
3. Переписывальщики переписываемого и любители смузи. Надеялся что они в своем редоксе останутся, но увы, ломаторы тянутся к работающему.
> Звучит сомнительно. Нет особого запроса.
> Большинство юзеров просто скачают собранный образ от "вендора". А гентушники - вымирающий
> вид."Гентушники" (без привязки к генту) и есть "пользователи" ядра. Даже на опеннете есть запрос у множества пользователей.
> Даже для Х11 (где вроде куча народу хочет остаться и не адоптить
> программы к вейланду) не набралось достаточно людей и компаний, чтобы организовать
> поддержку самостоятельно.Напутаны причины и следствие. Для X11 сначала не набралось людей, которые согласны это поддерживать, а потом уже придумали вейланд. Логично что после внедрения вейленда энтузиазма в поддержку X11 не прибавилось.
> По большей части жалуются всякие probonopd (которые исправленные баги не убирают из
> списка) и любители многооконных приложений.Даже не знаю что это.
> Из относительно успешных девуан, но требования к его поддержке существенно ниже, даже
> чем к Х11. Нужно просто "правильно собрать имеющееся", и можно гордиться
> своей борьбой с систеМДой (бадумтц))Существенно ниже чем выпилить неиспользуемые дрова на расте? Это можно даже автоматически сделать.
> Боюсь вероятнее будет "новый код в ядро принимается только на Rust, поддержка
> старого разрешается на С"Файрфокс уже на раст переписали. Осталось также ядро переписать.
> 2. Корпы это мелкософт и гугл. Оба известны тем что молниеносно прикапывают свои проекты.Угу, вот только андроид вполне живой. То что у них достаточно ресурсов для экспериментов - это не повод закопать раст.
> "Гентушники" (без привязки к генту) и есть "пользователи" ядра. Даже на опеннете есть запрос у множества пользователей.
Не спорю, вопрос "а сколько их". По моему опыту большая часть моих знакомых которые пользуются линуксом таки качают образ с сайта (убунта, дебиан).
Если их несколько процентов - то на них просто забьют.
> Для X11 сначала не набралось людей, которые согласны это поддерживать, а потом уже придумали вейланд. Логично что после внедрения вейленда энтузиазма в поддержку X11 не прибавилось.Странно, а по количеству нытья тут и на лоре кажется что людей столько, что все ядро три раза переписать можно))
> Это можно даже автоматически сделать.
Это сейчас, пока не появились rust-only драйвера. А это просто вопрос времени.
Поэтому удалять конечно можно, но потом сидеть с неработающем железом. Хотя любителям всяких либр-ядер к этому не привыкать.> Файрфокс уже на раст переписали.
Максимально спорное утверждение. Я понимаю что хейтерам приятно во всем винить раст.
Но раст - это лучшее что случилось с фоксом за последние лет пять.
Он наконец-то перестал быть тормозилой хотя бы на какой-то период.
Проблема в том, что кто-то явно хочет, чтобы Rust был в ядре. При том что Rust, несмотря на огромные вливания, развивается значительно менее осмысленно, чем скажем Zig или V lang с нулевым (по сравнению с Rust) бюджетом. Здесь уже поверишь в теории заговора, что Rust - это оружие против *nix с говорящим названием.
Никсы всегда разрабатывались корпорациями. Линукс пишется корпорациями. Вот так вот.
Смешно))
Я что не так?
Ты абсолютно прав, есть целая куча компаний, которые хотят чтобы Раст. Был в ядре. И сами разработчики тоже этого хотят (судя по последнему интервью Линуса).> развивается значительно менее осмысленно, чем скажем Zig
А можно какие-то примеры неосмысленного развития?
То что из себя представляет зиг - это классный пет проджект, на котором даже что-то написано, но это не готовый язык.
На его сайте ziglang org/learn/overview/ есть такие утверждения
- Zig programmers must manage their own memory, and must handle memory allocation failure.
- Please note that Zig is not a fully safe language.
- Multithreading safety and race detection are areas of active research.
Нужен ли он в ядере если и память самому менеджить, и многопоточность еще в "active research" ?> V lang
Язык вдохновленный Го-шкой, а также под влиянием "as well as other influences including Oberon, Swift, and Rust."
Одно только упоминание Оберона уже должно отпугивать)
Более того там есть GC (по defaultʼу, но можно и ручками) - так что для Rust он если и конкурент, то не прямой.
Ну и "Autofree is still WIP. Until it stabilises and becomes the default, please avoid using it. Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready." - это хорошая Бета языка, но он явно не готов к проду.> с нулевым (по сравнению с Rust) бюджетом.
У Зиг есть Corporate sponsors - Pex, Coil, TigerBeetle и 株式会社時雨堂... кто это)?
Спонсоры V тоже не впечатляют, whatlab rip, threefold, mx, syndica.
Что будет с языком если они прекратят финансирование? Боюсь 28 донатеров на патреоне не хватит.
> Проблема в том, что кто-то явно хочет, чтобы Rust был в ядре.
> При том что Rust, несмотря на огромные вливания, развивается значительно менее
> осмысленно, чем скажем Zig или V lang с нулевым (по сравнению
> с Rust) бюджетом. Здесь уже поверишь в теории заговора, что Rust
> - это оружие против *nix с говорящим названием.Конечно. Целая куча менеджеров из майкрософта и гугла с премиями за успехи. Но также легко эти менеджеры уйдут на другие позиции похайповее и молниеносно похороняет неперспективный (теперь уже) проект.
>> Рассказывали, что "никогда в ядре драйверов не будет" и тд.
>Не рассказывал, но надеялся.На что надеялся - непонятно. Тут уже не раз приводилась эта ссылка (отчет об уменьшении ошибок в андроиде из-за растущего использоваиня раста вместо сишки/плюсов), но вот в резюме они специально для тебя упомянули и ядро:
"What’s next?
Migrating away from C/C++ is challenging, but we’re making progress. Rust use is growing in the Android platform, but that’s not the end of the story. To meet the goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers.
As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare!"
https://security.googleblog.com/2022/12/memory-safe-language...
Так что: " - Бегите, глупцы!".Но... куда ты побежишь? На фряху собрался? Ха, семена посеяны (в умы), хоть всходов еще нет, так, отдельные травинки:
"Rust in the FreeBSD Kernel
Johannes Lundberg4 created a RustKPI FreeBSD Kernel Module) and e1000 Rust FreeBSD Network Driver example and Hello World Example as part of his Masters Thesis on Safe Kernel Programming with Rust (2018, PDF).
Anatol Ulrich5 wrote a Hello world FreeBSD kernel module in Rust. (github.com, 2021)
In August 2022, David Young6 of NCCGroup posted a Writing FreeBSD Kernel Modules in Rust research article and accompanying BSD-Licensed code repository, based on Johannes Lundberg's original work, updated to target Rust 2021."
конечно, пока еще ни о чем, но лиха беда начало, сомнения (или надежды) проросли и во фряшных головах.
> На что надеялся - непонятно. Тут уже не раз приводилась эта ссылка
> (отчет об уменьшении ошибок в андроиде из-за растущего использоваиня раста вместо
> сишки/плюсов), но вот в резюме они специально для тебя упомянули и
> ядро:Отчёт гугла о безопасности в андройд (напомню, одна из худших систем с т.зр. безопасности, при этом изначально java преподносилась под соусом безопасности, также как и сейчас раст) и использовании их ручного языка. Что же тут может быть не так?
Могу прислать свой отчет о своей продуктивности, вы удивитесь насколько я супермен. Ну прям как дети малые верите всему написанному.
> Но... куда ты побежишь? На фряху собрался? Ха, семена посеяны (в умы),
> хоть всходов еще нет, так, отдельные травинки:Честно говоря особо не вижу проблемы. В ближайшие лет 5 очевидно в ядре не будет ничего стоящего на расте, далее при желании можно еще посидеть на форках/старье. А через 10 лет либо уже закопают раст, либо станет очевидно что я ошибался (но сильно в этом сомневаюсь).
Там с тех пор как раст завезли, какая-то дичь началась, едро теперь каждые 2 дня фиксят, ext4 рассыпается и вообще карма у него плохая
> едро
> ext4О нет, опять растовити сишникам в штаны подкинули!
Энергетика у раста такая.
Магическое мышление, оно такое, да...
Везде так где корпорации добра влазят.
Копро- потому что.
Как понять «перейдёте на винду»? Линукс - это же приложуха в Microsoft Store. Или его можно без стора поставить?
Что ни говорите, а Раст это будущее!
Вперёд в светлое Раст-будущее, ура, товарищи!
Пока это свелое будущее настанет, появится ещё куча новых перспективных язычков.
И все они будут щекотать твои нервишки, да?
Не мои, а тех, кому сейчас Rust щекочет.
Почему то вспомнился "Золотой теленок" Ильфа и Петрова:
— Но что бы вы ни говорили, я вам скажу откровенно — Чемберлен всё-таки тоже голова.
Пикейные жилеты поднимали плечи. Они не отрицали, что Чемберлен тоже голова.
В интервью Торвальдс сказал что Rust не оправдал ожидания но раз уж молодёжь просит будут и дальше продвигать чтобы не было застоя, старые специалисты скоро кончатся.
> В интервью Торвальдс сказал что Rust не оправдал ожидания но раз уж
> молодёжь просит будут и дальше продвигать чтобы не было застоя, старые
> специалисты скоро кончатся.Вот это на правду больше похоже. Плохо жить в эпоху перемен как гласит китайская мудрость.
Китайская глупость, а не мудрость. Только старпёры боятся всего нового.
Тогда зачем совместимость, выпустил новый процессор, новый набор команд, перекомпилировал старый софт или написал новый, по факту можно очень сберечь транзисторный лимит или потратить его на полезные вещи, но ведь так никто не делает по очевидным причинам, это к вопросу о новом-)))
Ты видимо не писал код с сохранением обратной совместимости. Думаешь все как и ты будут бросаться переписывать?Кстати, домашнее задание тебе подумать даже раст как-то старается сохранить обратную совместимость
Если ты за всё новое и не старпёр, то замени себе пестик тычинкой. Будет что-то новое в тебе)
Немного не так сказал - "Rust has not really shown itself as the next great big thing." - это совсем не "не оправдал ожидания".Зато имеет технический смысл + еще не загнивает как сишечка, что намного более важно для жизни проекта.
"To me, Rust was one of those things that made technical sense, but to me personally, even more important was that we need to not stagnate as a kernel and as developers."И на становление раста в ядре уйдут годы, но это точно произойдет:
"So it's one of those things that is going to take years before it's a big part of the kernel. But it's certainly shaping up to be one of those."Так что растохейтры могут начинать переходить на бсд)))
Годы уйдут чтобы он стал важной частью а не незаменимой и конечно он не оправдал ожиданий, через годы только малюсенький драйвер phy появился что говорит о том что в реальности он мало кому интересен - дёргать биты в 32 битном слове небезопасно просто невозможно :)
> через годы только малюсенькийЧерез какие годы? Базовая поддержка раста в ядре 6.1 появилась в Sat, 1 Oct 2022
lore.kernel .org /lkml/202210010816.1317F2C@keescook/
Прошел всего год и пара месяцев.
От этого двигать биты в слове стало безопаснее?
Двигать биты - нет. Но ядро это внезапно не только двиганье битами в словах.
Работа с буферами стала безопаснее. Так что стало лучше.
На сколько воображаемых единиц. Сколько раз поработали с буферами этим недодрайвером?
Все думают, что двигать биты это самое сложное в ядре,
А потом получают уязвимость в split string :DПросто глянь на это великолепие (уязвимость в Glibc ld.so opennet.ru/opennews/art.shtml?num=59867)
- if (p[len] != '\0')
- p += len + 1;
+ /* We reached the end while processing the tunable string. */
+ if (p[len] == '\0')
+ break;
+ p += len + 1;
пердолинг с null-терминаторами только по причине, что в дыряшке строки сделаны из той же субстанции, что и остальной язык
И что взял там поправил нет твоей дыряшки. Зачем тут раст? С ним программировать не проще.
> что в дыряшке строки сделаны из той же субстанции, что и остальной языкОк, а на чем строки сделаны в x86 ассемблере?
Кто тебе сказал, что си «загнивает»?
Вот как надо работать! Запилил язык - внедрил в ядро. А дальше уже вы будете вертеться как хотите.Ой, как удобно - теперь вы будете допиливать архитектуры расту и gccrs - а то сборочка с gcc теперь усё.
Можешь пропатчить и сделать своё ядро линукс без раста, и выложить на гитхаб. Это же опенсорс!
> и выложить на гитхабА вот и детишки в треде.
Неа. Просто я понимаю, что ядро линукса пишется исключительно корпорациями. А не любителями сишниками. Вот, чтобы было удобно писать код без уязвимостей, корпорации и продвигают раст в свой проект - линукс. А остальные - пользуются линуксом нахаляву, и решений, естественно, принимать не могут.
> а то сборочка с gcc теперь усёвраньё, этого не допустят
Все правильно.
Запилил язык, добавил туда прорывные идеи, которые другие не могли осилить 50 лет (привет СИ и ошибки памяти), сделал на его основе множество мелких и средних приложений, доказал работоспособность крупным игрокам (корпорациям), начал внедрение в крупнейшие опенсорс (андроид) и не очень (винда) проекты.
И наконец-то получил разрешение (предварительное) на драйвер в ядро.То что при этом помрет GCC - то лично я плакать не буду.
Каменный век рано или поздно заканчивается, а неандертальцы просто вымирают.
> Все правильно.
> Запилил язык, добавил туда прорывные идеи, которые другие не могли осилить 50
> лет (привет СИ и ошибки памяти), сделал на его основе множество
> мелких и средних приложений, доказал работоспособность крупным игрокам (корпорациям),
> начал внедрение в крупнейшие опенсорс (андроид) и не очень (винда) проекты.
> И наконец-то получил разрешение (предварительное) на драйвер в ядро.
> То что при этом помрет GCC - то лично я плакать не
> буду.
> Каменный век рано или поздно заканчивается, а неандертальцы просто вымирают.Это подойдет для желтой прессы. С техническими деталями все далеко не так гладко... Но ты, конечно, об этом не знаешь, потому что болтун.
> Это подойдет для желтой прессы.Хм.. Если ты под "желтой прессой" подразумеваешь опеннет.. то он не виноват что у него странички желтые!
Но даже на этих желтых страничках, можно регулярно читать про "уязвимость с проекте N из-за типичной для С ошибки double-free/out-of-bound/buffer-overflow/use-after-free".> С техническими деталями все далеко не так гладко...
Пруфы пожалуйста.
Пока я вижу, что в андроид с Растом все отлично.
Они начали его вводить и кол-во ошибок памяти уменьшилось, новый код старались писать именно на нем security googleblog com/2022/12/memory-safe-languages-in-android-13.html
Сделали некоторые bare-metal проекты security googleblog com/2023/10/bare-metal-rust-in-android.html
Более того люди очень быстро осваивают, буквально за 2 месяца - т.е язык простой для обучения. opensource googleblog com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html
> Но ты, конечно, об этом не знаешь, потому что болтун.Ну так просвети меня! Ты ж тут гуру.
Можешь скинуть какие-то статьи, а не сотрясать воздух бездоказательными утверждениями.
Я с удовольствием почитаю.
Зоопарк языков в ядре ни к чему хорошему не приведёт...
Тем более что если Раст добавят уже не будет аргументов чтобы не добавлять код на Zig, а в будущем и на других языках следующего после Rust поколения.
Наоборот. Зачем добавлять zig (это что за васяны вообще?) если уже есть раст?
Разве у zig есть хоть какие-то плюсы?
Да, какой-нибудь Вася захочет добавить код в ядро на Visual Basic, и ему Линус не сможет отказать. Крутая логика.
Прецедент есть прецедент. А если не на Visual Basic, а на Zig, например? Кстати, тут не стоит и про C++ забывать.
Не, на с++ и плюсовиков у Торвальдса то ли обида, то ли зубC++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
Он конечно стал слегка добрее, даже пальцы перестал показывать, но очень сомневаюсь.
> Он конечно стал слегка добрее, даже пальцы перестал показывать, но очень сомневаюсь.Вот это кстати и есть одно огромное лицемерие, при том, что C++ лучше как по быстродействию, так и по скорости и по простоте компиляции. В плане надёжности и на тот момент уже была масса инструментов, как языковых, так и настроек компилятора и всевозможных профилировщиков памяти и санитайзеров без которых не обходится разработка крупных проектов на плюсах. При всём что C++ идеально согласуется с Сишным кодом и позволяет без существенного вмешательства улучшать качество кода. Вместо этого в ядро врывается Rust, который ничего принципиально не меняет, зато существенно усложняет сборку. Пользуйтесь рабы готовыми дистрибутивами и не жалуйтесь.
> C++ лучше как по быстродействию, так и по скорости и по простоте компиляцииНе согласен, как раз у С++ никаких преимуществ нету.
Вспомни когда ядро перешло с С99 на что-то поновее?
И представь что до 2023 года использоваляся бы С++98.
Что бы это дало? Ни-че-го.
Стандарт 03 по большей части исправлял ошибки, существенные улучшения появились аж в C++11.> который ничего принципиально не меняет, зато существенно усложняет сборку.
т.е borrow, lifetime и это не принципиальное изменение?
вон наверху ванюшки до сих пор не могут осилить и пытаются по привычке одну память пердолить с нескольких потоков
Надо сразу добавлять JVM, CLR, HashLink (HashLink is a virtual machine for Haxe), MoarVM. Поддержки скольких языков сразу добавится!
Да-да, разработчики у которых по 15-20 лет опыта на Си побегут становится юниорами на Rust и подписывать обязательные декларации за права меньшинств на конференциях.
Разрабочтики сами уж точно разберутся, без опеннетных экспертов.
Самокритичненько.
Если "разработчики у которых по 15-20 лет опыта на Си" станут джунами на расте... то есть большие вопросы к их компетентности.
Потому что при таком опыте, если он реальный конечно, перейти на другой язык это пара недель-месяц. Ну может два, но не больше. А если ты всю жизнь штаны просиживал и уже необучаемый - то даже для си зачем ты нужен?
> Потому что при таком опыте, если он реальный конечно, перейти на другой язык это пара недель-месяц. Ну может два, но не больше.Там помимо этого нужно волосы перекрасить и пол поменять. А это, извини меня, не за неделю делается, даже если химическим путем.
Конечно нет. Ржа и пропихивается корпорациями для того, чтобы отсеить "старых" нелояльных бизнесу сишников и заменить их на преданных растаманв, в итоге взять открытые проекты, в том числе и ядро, в свои руки.
Поздравляю, вы приняты!Без шуток, хоть кто-то сечет в теме. Стоит ещё сказать про тулинг, что раст гвоздями прибит к ллвм. Бутстрапинг ядра станет очень сложной задачей
Так корпорации и пишут ядро линукс, не любитель Вася же пишет же. Они тратят деньги на написание ядра, это вполне логично.
Корпорации пришли на все готовенькое.
Хахаха!
Корпы начали вкладывать денежку в ядро в 98-200х
Причем нехило - типа 1500 инжинеров от ИБМ.Может ты слишком молод и не помнишь каким был линукс с 2000 году.
Это был хтонический ужас.
> Корпы начали вкладывать денежку в ядро в 98-200хТо, что они вкладывают в ядро - это их личная добровольная инициатива и это не даёт им никакого права как-либо претендовать на ядро!
> То, что они вкладывают в ядро - это их личная добровольная инициатива
> и это не даёт им никакого права как-либо претендовать на ядро!Вот только мир так не работает)
То что корп скажет - его работник на галере сделает.
Вот и получается, что именно они и рещают, что будет сделанно, а что нет.Сообщество™ ведь не хочет тратить силы/деньги/время на разработку?
Посмотрел исходный драйвер. Посмотрел предлагаемый. Какие преимущества использование rust в данном случае дает не понял.Перечитал: "позиционируется как простой рабочий пример".
Получается - это не драйвер. Это Холло ворд.
Hello Driver!
Включенный хеллоуворлд.
Hollow world :D Остроумное замечание.
Маленький шаг в ядре линукса, но большой шаг для индустрии.
А мне вот интересно, ядро теперь тоже будет на гигабайты из-за ржавчины? Потому что до сих пор оно пара мегабайт в сжатом виде, если вкомпилить все нужные драйвера в него. Но вообще странная тема, ядро будет собираться несколькими компиляторами одновременно? Или теперь только шлангом компилировать будут? Так шланг хуже код выдаёт. Помойку развели теперь и в ядре.
Может стоит договориться об едином названии rust драйверов? Хоть на это Линукс разработчики способны я надеюсь. А то придет инклюзивный гендерно ущемленный чернокожий и а следующий раз напишет E1ooo-rS.
Если он может написать драйвер для ядра то мне плевать на его сексуальные предпочтения
(лишь бы не как у Столмана, ЕВПОЧЯ))).И вообще идея "стоит договориться об едином" для опенсорса губительна.
"Свободные от корпов" разработчики, всякое Сообщество™ любят лепить велосипеды и для новой программы на С писать свой новый splitString
Уже сделали едины системмд - и что? они были благодарны?
Нет они, естественно, начали ныть!
> Если он может написать драйвер для ядра то мне плевать на его сексуальные предпочтенияДаже я могу написать драйвер для ядра, а тем более такой простой как E1000.
Ну если бы уже написал - то никакиех исключений, меня бы твоя личная жизнь вообще не интересовала.
Но так как ты "Даже я могу", то похоже что ты просто хвастливый г-н.
А такие господа мне не нравятся.Развговоры "я тоже так могу, просто не хочу толстый_кот.jpg" это минимально контруктивно. Хуже только нытье скаллнета по поводу Х11.
Почему в новости не указаны преимущества языка раст?
Ну, раз ты спросилМетоды работы с памятью в Rust избавляют разработчика от ошибок при манипулировании указателями и защищают от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo. Для размещения библиотек поддерживается репозиторий crates.io.
Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами, учёт времени жизни объектов (области видимости) и оценку корректности доступа к памяти во время выполнения кода. Rust также предоставляет средства для защиты от целочисленных переполнений, требует обязательной инициализации значений переменных перед использованием, лучше обрабатывает ошибки в стандартной библиотеке, применяет концепцию неизменяемости (immutable) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок.
Во, спасибо
Но аудит безопасности все равно нужен даже коду на Rust.
Ппц, теперь ядро нормально собрать будет всё труднее и труднее. Зачем?
Да не будет ничего, успокойся. Читай дальше заголовков.
Очевидно чтобы ты сам не собирал, а качал сборки с сайта Майкрософт за денюжку
Ай да Билл, ай да ... хитрец.
Сатья, Бил на пенсию свалил задолго до интереса Micro$oft к Расту.
Очередное тупое, бездумное переписывание чего полегче на «волшебный чудо–язык от всех проблем».Одно непонятно — зачем это пихать в линукс? Ну создали бы форк, переписывали бы его по–тихому, потом померились бы — кто быстрее, и у кого CVE меньше. А это какая–то лицемерная п**р–акция.
И в целом, даже неплохо бы чтобы драйвера и ядро были написаны на безопасном языке, который бьёт по рукам и не даёт делать фигню. Но на практике это выливается в привязку к совершенно омерзительному, монструозному компилятору раста и не менее омерзительной же растовой инфраструктуре, гвоздями прибитой к интернетам.
Вот у меня вопрос к растаманам: вы собственный компилятор–то пробовали собирать? Как оно, нормально, по несколько часов ждать компиляции этого бегемота?
Раньше можно было собрать ядро полностью в оффлайне, любым стандарто-совместимым компилятором, хоть tinycc. А теперь придётся разворачивать и поддерживать ДВА компилятора, gcc и llvm с растишкой. И ещё в онлайн выпускать всё хозяйство, а то вдруг cargo чего–то там не найдёт…
> Одно непонятно — зачем это пихать в линукс? Ну создали бы форк, переписывали бы его по–тихому, потом померились бы — кто быстрее, и у кого CVE меньше.Все пытаются в ядро пропихнуть, чтобы самим поддержкой не заниматься.
Вероятно они на это и надеются, но как будто попадание в ядро автоматически гарантирует больше разработчиков. Скорее наоборот, автору кода приходится бодренько тащить его или его безжалостно выкинут из ядра после долго не закрытых багов.
> Но на практике это выливается в привязку к совершенно омерзительному, монструозному компилятору раста и не менее омерзительной же растовой инфраструктуре, гвоздями прибитой к интернетам.Ты всегда можешь развернуть свой карго локально.
Боее того я знаю некоторые компании, которые так уже делают для своего не опенсорс кода.> вы собственный компилятор–то пробовали собирать? Как оно, нормально, по несколько часов ждать компиляции этого бегемота?
Ну допустим пробовал. Неужели ты не догадался поставить сборку и пойти пообедать/поужинать.
И как часто тебе приходится пересобирать компилятор? Может у тебя хобби такое ¯\_(ツ)_/¯> Раньше можно было собрать ядро полностью в оффлайне
"Раньше было лучше"
Назови реальные задачи, когда нужно без интернета собирать ядро?
Но даже так можно просто притащить все на флешке.> стандарто-совместимым компилятором, хоть tinycc.
хахаха, а потом в одном компиляторе UBшки обрабатываются по другому. Потому что у С не стандарт, а дурнопахнущая субстанция.
> А теперь придётся разворачивать и поддерживать ДВА компилятора, gcc и llvm с растишкой. И ещё в онлайн выпускать всё хозяйство, а то вдруг cargo чего–то там не найдёт…
Сиди на старой версии ядра, тебя ж никто не заставляет обновляться. И не фантазируй, онлайн выпускать ничего не обязательно, можно взять локальное карго. Почитал бы хотябу доку, возможно она тебе пригодится уже в ближайшее время.
> И как часто тебе приходится пересобирать компилятор?Каждых полтора месяца. Впрочем, мне лично — уже не приходится. Отказался от раста полностью, ибо задолбало.
> Может у тебя хобби такое ¯\_(ツ)_/¯
Мэйнтейнеры бинарных дистрибутивов, а также гентушники, бсдшники, и владельцы экзотических архитектур смотрят с презрением.
> Назови реальные задачи, когда нужно без интернета собирать ядро?
Ядро собирается в изолированном контейнере, просто потому что ему _НЕ_НУЖНО_ в интернеты. И это вроде совершенно банальный, рутинный подход к безопасности — выдавать только совершенно необходимые привелегии и не более того. И с каждым нововведением стараться уменьшать плоскость атаки, а не увеличивать. В противном случае можно и до "curl|sudo sh" дойти. Чем это чревато — надо объяснять? Или всем предлагается перейти на подвёрнутые джинсы и овощные коктейли?
> Сиди на старой версии ядра
Чтобы что? Побираться на кривых бэкпортах? Тут уже была новость про ext4.
Речь про то, что ради удовлетворения эго отдельных растаманов, всем пользователям ядра придётся поддерживать у себя локально ржавую инфраструктуру. Занимающую неплохо так дискового пространства, ресурсов процессора и памяти при сборке. То, без чего ранее вполне себе обходились. При этом нововведения не дают радикального повышения безопасности — это тупое перекатывание существующего кода. И это ещё до замеров прозводительности дело не дошло.
Отказался от раста полностью, ибо задолбало.Т.е. Линукс скоро умрёт? И Альт?
> Отказался от раста полностью, ибо задолбало.
> Т.е. Линукс скоро умрёт? И Альт?Умрёт нескоро, но это неизбежно. И вообще возвращаясь далеко назад во времени можно прийти к выводу, что знаменитом споре Линуса и Таненбаума, последний был прав, причём особенно с точки зрения безопасности, а популярность Linux в кругах разработчиков - это не более чем исторический фейл, который теперь просто входит в новую закономерную стадию.
> Мэйнтейнеры бинарных дистрибутивов, а также гентушники, бсдшники, и владельцы экзотических архитектур смотрят с презрением.Из перечисленных категорий ценность представляют только мэйнтейнеры бинарных дистрибутивов, те они делаю полезное дело. Но скорее всего у них оно и так будет.
Остальные - это может ну десять процентов от всего кол-ва юзеров десктопного линуха.
И... это их проблемы, пусть пилят себе ядро без раста, дров (бздишникам не привыкать)))> _НЕ_НУЖНО_ в интернеты. И это вроде совершенно банальный, рутинный подход к безопасности — выдавать только совершенно необходимые привелегии и не более того.
Согласен, думаю это вполне решаемо. Например ядро качается вмести с локальным карго, собственно как происходит с либами сейчас.
> Или всем предлагается перейти на подвёрнутые джинсы и овощные коктейли?
У тебя какая-то проблемма с джинсами и коктелями... Возможно стоит сходить к психологу.
Посмотри какие прически и вообще мужскую моду в штатах в 80е, когда харождалась почти весь современный опенсорс.
Можешь еще написать, что-то желчное и осудительное про этого длинноволосого пацана (справа) http://si410wiki.sites.uofmhosting.net/images/b/b8/Young_lin...> Чтобы что? Побираться на кривых бэкпортах?
Да, именно так.
Ты или делаешь вклад в ядро и имеешь некоторое влияние на принятие решений, или "кушай что дали", или пили свой вариант с преферансом и поетесами.> ради удовлетворения эго отдельных растаманов, всем пользователям ядра придётся поддерживать у себя локально ржавую инфраструктуру
Хм.. и кто у нас "отдельный растаман"? Линус, корпы которые и оплачивают разработку, некоторое кол-во разработчиков либ (тут довольно немало новостей о библиотеках на раст).
К сожалению для тебя - это именно те люди которые организуют и финансируют ядро и которые принимают решение. Так что см. выше про влияние на проект.> Занимающую неплохо так дискового пространства, ресурсов процессора и памяти при сборке.
Может для тебя это много, для меня нет. Думаю 70-80% пользователей линукса просто качают уже собранный образ, который какая-нибудь убунта или шапка собрали один раз.
> То, без чего ранее вполне себе обходились.
Раньше обходились дыркой в полу на улице и ракушками, а сейчас подавай компакт.
Раньше код писался в текстовом файле, а сейчас разработчику подавай автодополнение и нормальный дебаг.> нововведения не дают радикального повышения безопасности — это тупое перекатывание существующего кода
Без пруфов звучит как балабольство.
С другой стороны - вот результаты гугла security googleblog com/2022/12/memory-safe-languages-in-android-13.html И у них все получается)
Посмотрел сейчас, новости о возможном включении Раста в ядро несколько лет назад воспринимались намного более позитивно чем сейчас. Новый язык, безопасность, вроде никто и не против. Но с тех растаманы успели показать свои ядовитые зубы и настроить сообщество против себя, так что теперь реакция в целом средне-негативная, кроме парочки фанатиков. Да-да, новости о включении Раста в ядро выходят регулярно вот уже несколько лет и каждый раз там что-то добавили или включили.
Сложно сказать куда ты смотрел, но тут раст люто хейтили еще до выхода версии 1.0.
А потом под каждой новость была просто перепись клоунов.
Сейчас клоунов как-то немного попустило и они скорее плакаться начали. Но нытье им тоже не поможет))> растаманы успели показать свои ядовитые зубы
О нет, бедные снежинки обиделись, что их божественную дыряшку заменяют))
> Но с тех растаманы успели показать свои ядовитые зубы и настроить сообщество против себя,Хм.. и в чем же их ядовитые зубы? Они не уважают дидов-бракоделов?
> так что теперь реакция в целом средне-негативная, кроме парочки фанатиков.
Очень, очень, очень пофиг.
Линкс - за, основные спонсоры ядра - за, раст сообщество - тоже за.
Этого достаточно. Никто не бужет слушать нытье неосилторов, луддитов и прочих.
На них просто забьют и правильно сделают.
Хруст как задумка неплох. Плох он своим сообществом из убогих и юродливых. А короля, как мы знаем, играет свита.
> Хруст как задумка неплох. Плох он своим сообществом из убогих и юродливых.
> А короля, как мы знаем, играет свита.Он и как задумка плох. Во-первых, он не вносит в индустрию ничего нового, т.к. базовые идеи уже были (и есть) в C++98 (даже не C++11) стандарте в разделе move-семантика. И да, это требует какой-то квалификации, и не каждый сможет осилить, НО это в разы лучше, т.к. есть идеальная связь с Сишным кодом, а во-вторых, разработчику предоставляется ВЫБОР в каком стиле разрабатывать вместо того когда у вас семантика одна, прибитая гвоздями и долбитесь с компилятором как хотите чтобы выразить свою задачу в рамках языка. Проще говоря, лучше бы люди писали гайдлайны и дополнительные инструменты для существующих инструментов, чем плодили зоопарк языков.
Лол, и ведь огрызнулись на пост ровно те два токсичные фанатика раста о которых говорилось.
Для себя решил — пора переходить на openbsd. Пока верчу в виртуалке, очень непривычно на фоне набора команд линукса, но понимаю, что в линуксе дальше будет только хуже, и тем, кто не любит все эти корпоративные велосипеды а-ля хруст и сустемд, сваливать придется.
Я вот на Genode посматриваю. Она на плюсиках, что для меня приемлемо. Лицензия кошерная.
Что там с поддержкой железа?
На практике ещё не пробовал. Только слежу за развитием.
Лицензия кошерная.Мо снежинкой?
Что там с ; в конце строк. То они есть, то нет. В чем логика?
Гм. На правах опытного параноика, я бы рассматривал rust в ядре как новый перспективный способ внедрения "закладок".Вот даже на уровне кода. Что-то типа "if (uid = 0)" спалит очень быстро практически любой. Приходится изобретать эпические многоходовки (дальше-больше).
А здесь рраз! — и делаем ход конём (допускаем вставки на экзотическом ЯП, да ещё и с отдельной компиляцией).
Лёгким движением руки с поляны сметаются толпы таких как я. Понимающих что-то на уровне "железа", ASM, ну и сишка на правах подвинутого кросс-ассемблера.
Но разбираться в нагромождениях "крестов" (теперь вот rust) такие не полезут. А растоманы 99% спокойно сжуют "вы не понимаете, это так надо работать с регистром X вот на той микрухе". А уж закладочку в компилятор…
ПРОФИТ.
М... а ничего что раст компилируется в такие же команды что и си? И ты можешь посмотреть асм-выхлоп и сравнить.> А уж закладочку в компилятор…
gcc на сколько процентов из крестов состоит? А ведь ты и тебе подобные не полезут "разбираться в нагромождениях "крестов"". Так что уже везде где нужно закладки позакладывали
Вообще тебе наверное стоит перименоваться из PnD в ПНД, так будет честнее.
Пожалуй, этот господин прав. 🫖🫖
Ну попробуй незаметно добавить закладку в раст код. И поймешь насколько это сложно.
То ли дело сейчас в сишке - просто "забыл" проверку на null или проверку размера и готово https://www.opennet.dev/opennews/art.shtml?num=59664
А остальные пусть гадают - это закладка или типикал си.
Легко, в вермишельном коде на расте можно слона спрятать, не то что трояна. А можно вообще не прятать, а объявить троян фичей. Смузихлебы захлебнутся от восторга, а всех недовольных отменят.
Так не пиши вермишельный код!> Смузихлебы захлебнутся от восторга, а всех недовольных отменят.
🔴 возьми свой нос, ты уронил
> Что-то типа "if (uid = 0)" спалит очень быстро практически любой.А в rust не спалят?
> Лёгким движением руки с поляны сметаются толпы таких как я. Понимающих что-то на уровне "железа", ASM, ну и сишка на правах подвинутого кросс-ассемблера.
Спорим что если дать тебе штук пять коллстеков из трех сотен строк ты не сможешь хотя бы 3/5 раз угадать в какой именно ассемблерный вывод компилятор это превратит?
Офсайт раста без vpn не открывается?
Открывается.
> Драйвер включает 135 строк кода и позиционируется как простой рабочий пример для создания сетевых драйверов на языке RustУхаха, вся суть™
Все равно на каком языке пишут софт, главное чтобы этот язык был понятен, хорошо читаем, стабилен на определенном отрезке времени.Си читается дастаточно легко, Плюсы тот ещё квест, но им обоим до Раста очень далеко - уж очень вырвиглазный синтаксис, хотя идеи заложенные в язык отличные.
> Си читается дастаточно легкоСи читается легко потому что Си никак, вообще никак не выражает что автор собирался написать. Как и все сишные программисты ты таскаешь огромный ментальный багаж, о котором не задумываешь, пока не берешься учить джуна :))
Частая история в том же ядре: у тебя есть поле в структуре, в одном случае его надо защищать, а в другом не надо. Как это понять? Надо прочитать весь код! Это же так удобно, правда?
Спорно насчёт вырвиглазного синтаксиса. Вот кусок кода из проекта, на который я сейчас смотрю:```
pub fn join_path(dir: Option<&Path>, filename: &str, ext: Option<&str>) -> PathBuf {
let mut path = if let Some(dir) = dir {
dir.join(filename)
} else {
PathBuf::from(filename)
};
if let Some(ext) = ext {
path.set_extension(ext);
}
path
}
```Угловые скобки? Нужны для генериков, которых в Си нет. Амперсанды? Нужны для ссылок, которых в Си нет.
За эти символы-закорючки вообще кастрировать надо. Синтаксис должен быть максимально человеко-читабельным.
Какие закорючки?
> Амперсанды? Нужны для
> ссылок, которых в Си нет.& в C (ну и C++ тоже) - это операция взятия адреса.
/* C */
int foo;
int *foo_PTR = &foo; //указатель на существующую переменную foo
Не знаешь Си, не берись судить!
Вообще-то твой кусок кода уж больно смахивает на С++. А это - не Си.
Я тут нескучные обои на паскале написал, буду просить взять в ядро 7.0.
> Я тут нескучные обои на паскале написал, буду просить взять в ядро
> 7.0.ну дык Pascal вообще годнота как по идеям, так и по читаемости кода. Если бы не стереотипы о нём и бОльшее сообщество, был бы вполне себе популярный язык.
Хорошо, так Раст проложит дорогу в ядро модулям на C++.
И превратится ядро окончательно в помойку, где чёрт ногу сломит.
> И превратится ядро окончательно в помойку, где чёрт ногу сломит.Монолитное ядро по определению превращается в помойку, всё как и предсказывал Таненбаум. В монолитном ядре, каждый примат тянет своё Г в ядро и там по определению не может получиться ничего, кроме помойки. Это по определению плохой дизайн (но взлетел именно Linux), теперь же Linux ничего не спасёт из-за своей собственной монструозности, и здесь даже не важно Rust или нет. Сам дизайн монолитного ядра - это буллшит. Единственное преимущество монолитного ядра - это ПОТЕНЦИАЛЬНО (но не фактически) более высокая производительность, хотя на деле это не работает и того не стоит. Может быть Linux и можно было бы спасти, сломав обратную совместимость с древним железом и написать на существующей основе микроядро, при этом всё лишнее перевести в пользовательское пространство (только это уже будет не Linux, т.к. несмотря на то, что микроядро ГОРАЗДО меньше по объёму, чем монолит, это всё же огромный объём работы, особенно если хочется без лишних трудовых затрат использовать существующие наработки, НО с другим архитектурным подходом. Ключевой показатель любой системы - это управление памятью И ИМЕННО В ЭТОМ Linux ПЛОХ. То есть ни о какой производительности не может быть речи, если систему можно повесить когда один из драйверов решит запросить больше ресурсов, чем можно. Почему линуксоиды не обращают на этот откровенный фарс в своей системе - выше моего понимания, т.к. даже Винда (Windows 8.1, Windows 10 / 11) работают с памятью лучше. Микроядро же содержит в себе и фокусируется на принципиально важных для любой системы моментах: управление системной памятью, менеджмент процессорного времени и ввод-вывод (в широком смысле). Всё остальное - пользовательское пространство, где если что-то заглючит или запросит больше ресурсов, микроядру на это будет до лампочки, оно продолжит работу несмотря ни на что и убьёт глючные процессы в автоматическом режиме, если потребуется сообщив пользователю, что он долбо*б, либо то, что его железо уже старенькое для таких нагрузок. Linux way - вышли за пределы системной памяти, получите зависон из которого он не выйдет.
Продавят, продавят.
Ты веришь, что драйвер можно уложить в 135 строк??
Надо brainfuck в ядро включить... думаю майкософт этим скоро озадачиться
А ведь действительно это страшно. Неужели на *BSD переходить в скором времени? Благо опыт Linux релевантен более-менее будет.
