Мигель Охеда (Miguel Ojeda), автор проекта Rust-for-Linux, предложил для рассмотрения разработчиками ядра Linux выпуск v6 компонентов для разработки драйверов устройств на языке Rust. Это седьмая редакция патчей с учётом первого варианта, опубликованного без номера версии. Поддержка Rust рассматривается как экспериментальная, но уже включена в ветку linux-next и достаточно развита для начала работы по созданию слоёв абстракции над подсистемами ядра, а также для написания драйверов и модулей. Разработка финансируется компанией Google и организацией ISRG (Internet Security Research Group), которая является учредителем проекта Let's Encrypt и способствует продвижению HTTPS и развитию технологий для повышения защищённости интернета...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57153
Очень хорошо. Линукс должен перестать быть таким безбожно дырявым из-за сишки.
Скорей бы уж свет Раст озарил Линукс
Восславьте солнце друзья мои, линукс с нами!
88, линукс использовать не бросим!
Praise the Sun не относится к фашизму, это лозунг рыцаря из Dark Souls, который приходит на помощь игроку.
Режим шифрования включил?
Оно же ZlaVa_kpSS, зачем ему _здесь_и_сейчас_ какое-то там шифрование?
Посмотрим, как ты запоёшь, когда он станет безбожно дырявым из-за раста xD
Всё равно будет виновата сишка, ну что ты как маленький.
> Посмотрим, как ты запоёшь, когда он станет безбожно дырявым из-за раста xDДело даже не только в безбожной потенциальной дырявости из-за раста, дело в том, что на уровне ядра подразумевается доступ для включение вкраплений растаманского г@внокода.
Это же, те самые растаманы, которые не осилили в нормальные ЯПы, потому что не знают архитектуры железа, под которое собрались писать свой гомнокод, по сути сам раст by design это костыль для отсталых, которые неосилили писать на низком уровне, хуже только JS-макаки и прочие скриптохипсторы.
Это не для усиления секурности, это для снижения порога вхождения, чтобы по итогу не платить хорошим специалистам, а затаривать кучки "индусов", по сто баксов пучок, экономия денег ценой ресурсов конечных пользователей, а в итоге и экономия на качестве конечного продукта.
Печально всё это, линуксы катятся в хипсторскую кривую блоатварь.
> Это же, те самые растаманы, которые не осилили в нормальные ЯПыС чего такие заявления?
> Это не для усиления секурности, это для снижения порога вхождения,
Вот можно копать лопатой, а можно экскаватором. Это снижение порога вхождения? Это более удобный инструмент же, емае
> "индусов"
Вы расист?
> экономия денег
Всегда важна, как будто это плохое
>> Это же, те самые растаманы, которые не осилили в нормальные ЯПы
> С чего такие заявления?
>> Это не для усиления секурности, это для снижения порога вхождения,
> Вот можно копать лопатой, а можно экскаватором. Это снижение порога вхождения? Это
> более удобный инструмент же, емае
>> "индусов"
> Вы расист?
>> экономия денег
> Всегда важна, как будто это плохоеХотел было вам нормально ответить, но потом заметил вот это:
>> "индусов"
> Вы расист?И понял, что конструктивного диалога у нас не выйдет, а с жирнотроллями я общаться сейчас не хочу, у меня лимит на выдачу печенек для подкормки местной фауны.
> в нормальные ЯПы, потому что не знают архитектуры железаЯ знаю только один ЯП, где это требование необходимо - ассемблер. Все остальные языки в первую очередь сделаны для абстракции. Даже сишка.
>> в нормальные ЯПы, потому что не знают архитектуры железа
> Я знаю только один ЯП, где это требование необходимо - ассемблер. Все
> остальные языки в первую очередь сделаны для абстракции. Даже сишка.Вспомните пожалуйста один из основных тезисов растоманов против Си, про преимущество раста!
Под архитектурой я здесь подразумевал не сколько физическую топологию железа, возможно, здесь это понятие не совсем корректно, а принцип работы.
Очередной раз напоминаю дырявости и сишка никак не связаны.
Канеш сишка непогрешима, не волнуйся. А теперь укольчики и спать)
Что то не вижу тебя в коммитах к этой байде.
Фракталя не программист, он тролль.
Связаны, ведь в Си можно делать много UB операций с памятью, которые в Раст запрещены.
Только бездарь может считать, что дело в ЯП.
(с) Омар Сигизмундович Стэтхем
Больше не нажирайся так
Не взлетит, как сказал тео - нет экосистемы для этого вашего раст, на нем не пишут и не переписывают важный софт.
Включение Rust в ядро - это как раз и есть создание экосистемы для развития языка.
Скажи это ненужному WireGuard.
Сижу на ненужном WireGuard примерно 2 месяца. Нравится больше L2TP, роутер влёгкую 100 мегабит забивает.
Юзаю вайргада. Роутер на малохольном мипсе очень резвенько его гоняет и конфигурится просто.
Юзаю WireGuard больше года
Это убитие ядра.
Сейчас уже все на Раст переписывают
Мало переписывать, надо ещё завершать проекты, а то получается, как у Мозилы с FF: вроде что-то писали, но везде сишный код, даже в рендере, который вроде должен быть на расте.
Проекты надо не завершать, а продолжать
там продолжать некуда, разве что в чистый ноль по рынку.
Оно же ZlaVa_kpSS, зачем ему _здесь_и_сейчас_ какое-то там шифрование?
А те, кто делает патчи, пользуются Linux? Или это как у нас в современной политике "якобы делаем, а сами не пользуемся"
Делать Линукс надо, по-хорошему, на МакОС
На мой взгляд консервативно никто сейчас не делает: ни MacOS ни Windows. Linux всё же даёт свободу, но всё равно консервативного отношения не видно.
Много стандартов.
OpenBSD. Там столько консервативности, что хоть консервы заворачивай.
И хорошо. Если нужно что-то действительно железобетонное - это Опенок.
> И хорошо. Если нужно что-то действительно железобетонное - это Опенок.Местами оно таки оказывается гипсокартонным. Достаточно посмотреть на некоторые их вулны.
Откуда такая растофобия? Как будто в ядро пытаются добавить не низкоуровневый удобный язык, а javascript со смузями
Так ведь и пытаются
Сам не знал что истину написал? :))Когда-то были языки высокого уровня и низкого. А Раст и иже с ними это уже новый класс. Языки программирования среднего уровня. То есть по старой квалификации ни то и не другое.
Высокий уровень в С++ потому что умные указатели такие же как в расте. Плюс жор памяти.
Так а смысл ядро на низком уровне писать? Тонкий контроль не всегда нужен. Да и Си не особо низкого уровня, Си не отражает устройства X86, он в лучшем случае отражает условный виртуальный PDP11.
Мдаа. Молодежь еще тупее, чем я думал.
Почитай статью, вместо того чтобы измышлять
> Так а смысл ядро на низком уровне писать? Тонкий контроль не всегда
> нужен. Да и Си не особо низкого уровня, Си не отражает
> устройства X86, он в лучшем случае отражает условный виртуальный PDP11.
> https://queue.acm.org/detail.cfm?id=3212479Причем тут X86 вообще. Любой язык программирования - это абстракция от железной инфраструктуры. В этом их суть..
И на эти помои - X86 вообще никто и никогда не ориентировался...
> Любой язык программирования - это абстракция от железной инфраструктуры. В этом их сутьТак и Раст такая же абстракция.
> помои - X86
Эти т.н. "помои" победили, ибо как оказалось лучшая архитектура
> Эти т.н. "помои" победили, ибо как оказалось лучшая архитектураВ каком месте они победили? Временное преймущество из-за человеческой лени. Этой системы команд в процессорных ядрах уже тыщу лет как нет. "Эмулятор" только. И продолжают рыдать, но тащить это убожество.
Хотя Apple с 680xx отлично двинулись на PowerPC, дальше на Intel, а сейчас на ARM отлично переходят. Идут в ногу со временем.И да X86 это не архитектура - это система команд процессора. И даже MS - с подачи которой эта система команд вообще взлетела - понимают, что тащить X86 дальше - себе дороже.
> преймуществокак там... "В Тайланде войн выйграл у андройда в мозайку", не иначе, обладал каким-то тайным "преймуществом". Похоже уже пора отдельный словарь заводить.
>> преймущество
> как там... "В Тайланде войн выйграл у андройда в мозайку", не иначе,
> обладал каким-то тайным "преймуществом". Похоже уже пора отдельный словарь заводить.В обычный словарь сходи.., только не так как ты попытаешься ответить. А почитать..
Зачем анониму (в отличии от тебя) ходить в обычный словарь? Не заметил у него ошибок, кроме самой фразы стёба, может невнимательно просмотрел. Предложение не с заглавной буквы или пунктуация хромает? Но тогда причем здесь словарь? Может ты "Тайланд" считаешь правильным написанием? Другие слова вроде более "очевиднонеправильные". Огорчу тебя:
"Единственный правильный вариант написания – с буквой «и», то есть «Таиланд».
Данное слово является названием страны. В русском языке чаще всего его произносят как «Тайланд», однако это неправильно. Во всех словарях топонимов название этой страны пишется с буквой «и» и произносится точно так же. Следовательно, слово является словарным, а его правописание необходимо раз и навсегда запомнить.
Источник: https://orfographia.ru/tailand-ili-tayland-kak-pravilno"
А что ты понимаешь под средним уровнем?Основная причина (как мне видится) по которой его принимают в качестве языка написания модулей ядра -- он обеспечивает безопасность уровня управляемых языков (даже больше, потому что ни один популярный ЯП не защищает от гонок по данным) в сочетании с программированием на голом железе, как в Си. Без потери гарантий в безопасном подмножестве.
Второстепенная причина -- при создании языка уделялось внимание рекомендациям современного защитного программирования: константность по-умолчанию, отсутствие null, исчерпывающий switch (exhaustive pattern matching), требуемая обработка (или проброс дальше) ошибок программистом, базовые типы с явным указанием размерности, требование явного преобразования базовых типов (без возможности UB), отсутствие неявных блоков в циклах/ветвлениях (напр. знаменитая ошибка Apple -- https://embeddedgurus.com/barr-code/2014/03/apples-gotofail-.../ ), вместо наивной подстановки строк - макросы разбирающие дерево токенов, пространства имен для контроля видимости (в которых все по-умолчанию приватно), требование к программисту явно обрабатывать возможную ошибку при сравнении чисел с плавающей запятой, необходимость явно указывать какому полю присваивается значение при определении структуры, обобщенные типы... с поведением по белому списку, единая семантика преобразования сложных типов, времена жизни в определении функции увеличивают читаемость (нет необходимости заглядывать в тело функции, чтобы понять какой параметр окажется в выходе), безопасные и удобные обертки типов (New Type idiom), и пр.
Также и стандартная библиотека усилена, например более продуманными мьютексами ( https://habr.com/ru/post/659547/ ) или тем что HashMap использует более защищенный алгоритм хеширования.
Неявного замедления скорости исполнения почти нет. Достаточно прочитать стандартную книгу по раст где все такие места описаны чтобы ты мог сам решить, стоит ли тебе пользоваться такими языковыми конструкциями или библиотечными объектами.
https://doc.rust-lang.ru/book/ch17-02-trait-objects.html#Типаж-объекты-выполняют-динамическую-диспетчеризацию-связывание
https://doc.rust-lang.ru/async-book/02_execution/02_future.html
https://doc.rust-lang.ru/book/ch03-02-data-types.html#Некорректный-доступ-к-элементу-массиваи библиотека
https://doc.rust-lang.ru/book/ch08-03-hash-maps.html#Функция-хэширования
https://doc.rust-lang.ru/book/ch08-02-strings.html#Байты-скалярные-значения-и-кластеры-графем-Боже-мойПри написании идиоматичного раст кода применяются соответствующие наработанные практики вроде использования итераторов по срезам вместо индексирования, применения assert'ов перед индексацией чтобы убедить LLVM в ограничении длины буфера, использования enum вместо dyn, а также соответствующих паттернов проектирования которые еще даже не до конца сформировались - https://raphlinus.github.io/rust/gui/2022/05/07/ui-architect...
> А что ты понимаешь под средним уровнем?
> Основная причина (как мне видится) по которой его принимают в качестве языка
> написания модулей ядра -- он обеспечивает безопасность уровня управляемых языков (дажеНикто его не принимает, его туда пытаются вкорячить любыми путями с тыщами подпорок и костылей.
> больше, потому что ни один популярный ЯП не защищает от гонок
> по данным) в сочетании с программированием на голом железе, как вОт "racing сonditions" только мозг программиста защищает. Те тупые проверки что есть в расте на racing conditions видит и хороший программист, а в реальных, тяжелых, очень слабо продумываемых, просматриваемых racing conditions - которые в последнее время и всплывают - никаких бонусов RUST не дает.
>[оверквотинг удален]
> https://doc.rust-lang.ru/async-book/02_execution/02_future.html
> https://doc.rust-lang.ru/book/ch03-02-data-types.html#Некорректный-доступ-к-элементу-массива
> и библиотека
> https://doc.rust-lang.ru/book/ch08-03-hash-maps.html#Функция-хэширования
> https://doc.rust-lang.ru/book/ch08-02-strings.html#Байты-скалярные-значения-и-кластеры-графем-Боже-мой
> При написании идиоматичного раст кода применяются соответствующие наработанные практики
> вроде использования итераторов по срезам вместо индексирования, применения assert'ов
> перед индексацией чтобы убедить LLVM в ограничении длины буфера, использования enum
> вместо dyn, а также соответствующих паттернов проектирования которые еще даже не
> до конца сформировались - https://raphlinus.github.io/rust/gui/2022/05/07/ui-architect...А все что вышенаписано - ерунда для выпускника средней школы, в которой преподавали информатику, которого взяли на практику - "Оператором ЭВМ", а серьезный программист, ответственный за практиканта, пытается облегчить себе его воспитание, чтобы не бить практиканта часто по башке чем нибудь...
> От "racing сonditions" только мозг программиста защищает. Те тупые проверки что есть в расте на racing conditions видит и хороший программист, а в реальных, тяжелых, очень слабо продумываемых, просматриваемых racing conditions - которые в последнее время и всплывают - никаких бонусов RUST не дает.Не надо путать data race и race condition
Первое Rust сделать не даст, ты не сможешь использовать не thread-safe структуру в многопоточке
А второе с одной стороны конечно должен видеть программист, однако в Rust приняты такие идиомы, которые этот класс ошибок тоже зачастую предотвращают
>> От "racing сonditions" только мозг программиста защищает. Те тупые проверки что есть в расте на racing conditions видит и хороший программист, а в реальных, тяжелых, очень слабо продумываемых, просматриваемых racing conditions - которые в последнее время и всплывают - никаких бонусов RUST не дает.
> Не надо путать data race и race condition
> Первое Rust сделать не даст, ты не сможешь использовать не thread-safe структуру
> в многопоточкеИ именно это будет обрастать такими граблями в ядре - что скоро пальма первенства по производительности перекочует к BSD. Они в 13 Free уже ноздря в ноздрю идут почти, но качества кода в BSD выше на пару порядков.
> А второе с одной стороны конечно должен видеть программист, однако в Rust
> приняты такие идиомы, которые этот класс ошибок тоже зачастую предотвращаютТы же моешься по утрам? Или нет?
Почему в программировании на Сишке не примешь для себя идентичые идиомы, а все на Раст полагаешься?
> И именно это будет обрастать такими граблями в ядреНе понял о каких граблях речь)
Сейчас если ты хочешь использовать в драйвере какую-либо не thread-safe структуру, ты должен корректно обернуть обращения к ней в блокировку мьютекса/спинлокаВ сложном коде это достаточно просто забыть сделать, а Rust тебя спасёт от подобной ошибки, т.к не даст тебе иметь несколько мутабельных ссылок на структуру одновременно, хочешь делиться ей между потоками - пихни её в мьютекс/спинлок, и обращайся с ней через него
https://habr.com/ru/post/659547/
> Почему в программировании на Сишке не примешь для себя идентичые идиомы, а все на Раст полагаешься?
Потому что на каждом языке я стремлюсь писать идиоматичный код, и идиомы Rust совсем на сишные не похожи, а некоторые и просто нереализуемы в сях из-за более скудной семантики последних.
Это национальная забава. Когда что-то не понимаешь, надо это хейтить, а лучше запретить. Вон недавно на Форуме Безопасного Интернета дядечка высказался о запрещении этого самого интернета. Там же дети пропадают и роскомнадзорятся. А сколько от раста несчастий - и не перечесть. Теперь так просто UB и закладки не позапихивать, придётся думать.
> Теперь так просто UB и закладки не позапихивать, придётся думать.В расте есть UB. Ты, наверное, перечитал весь код компилятора и все, что тащит cargo, чтобы утверждать, что компилятор, прибитый гвозядми к llvm не тащит закладок?
> добавить не низкоуровневый удобный язык, а javascript со смузямиНа второе хруст больше похож чем на первое со своими паниками и let mut...
Ядро - как раз тот компонент, у которого работа с железом - задача. Так что ядерный язык обязан уметь прямой доступ к памяти. Когда раст научится такому - тогда и будет что предлагать в ядро.Фобии и страхи - у неграмотных, при наличии достаточно чётких аргументов - не аргумент.
>> Откуда такая растофобия?
> Ядро - как раз тот компонент, у которого работа с железом -
> задача. Так что ядерный язык обязан уметь прямой доступ к памяти.
> Когда раст научится такому - тогда и будет что предлагать в ядро.Классический образец воинственного опеннетного "растофоба" - привел "доказательства негодности" на основе своих же фантазий...
>>> Откуда такая растофобия?
>> Ядро - как раз тот компонент, у которого работа с железом -
>> задача. Так что ядерный язык обязан уметь прямой доступ к памяти.
>> Когда раст научится такому - тогда и будет что предлагать в ядро.
> Классический образец воинственного опеннетного "растофоба" - привел "доказательства
> негодности" на основе своих же фантазий...Хм, беру назад слова о том, что rust не умеет прямой доступ к памяти. Этот вывод я сделал на основе других постов. Будет время - конечно, побалуюсь, а пока только очередное подтверждение: Не брать на веру никакие опеннетные посты, проверять ВСЁ.
>А те, кто делает патчи, пользуются Linux?Так же, как и Redox.
Такое ощущение, как будто лгбтшная мозилла проводит вялотекущий перехват власти над ядром линя, вышибая старых сишников...
>Разработка финансируется компанией Google и организацией ISRG
>>Разработка финансируется компанией Google и организацией ISRGНу значит все это упадет - когда финансирование закончится. Хотя и сейчас то не особо взлетает.
> Ну значит все это упадет - когда финансирование закончится.то есть после мировой ядерной войны, но это неточно? Потому что деньги гугля и циски наверное и тогда не закончатся.
Google, вообще-то, имеет репутацию весьма крутой на развороты и метания.
Тут проект - реальный кусок пирога, не то что гугл код для хомяков держать
Скорее всего они пишут для своих облаков и своего железа (а его у Гугла много). Чтобы потом на этом деньги зарабатывать. Поэтому здесь они будут до конца.
Молодцы!
И ты тоже молодец что отметил, то что они молодцы!
Синтаксис раста страшнючий, но если кому-то нравится, почему нет
не надоело ещё мусолить тему про "страшнючий" синтаксис раста?
Правда глаза режет.
Норм синтаксис, просто кто не знает, тот не приучен
> Норм синтаксис, просто кто не знает, тот не приученА откуда, если всех знаний - паскальчик да жабкоскриптик c питончиком (ну и еще пара сишечных хелловротов в "универе")?
Ага, и во всех перечисленных языках синтаксис разрабатывался изначально дизайном, где-то больше, где-то меньше. В C++ синтаксис становится уродливым тогда, когда начинаются "новые" (они появились уже сравнительно давно) возможности. Rust же новый язык, который УЖЕ приобрёл уродливый синтаксис. И да, простое и тривиальное ПО на любом языке будет выглядеть сравнительно просто, зато когда в Rust начинает требоваться создавать сложное поведение, где-то применять unsafe, где-то контролировать время жизни (это вообще отдельная тема и иногда выглядит как удовлетворения компилятора, чтобы не ругался) в итоге всё превращается в кашу. На C (чистом) МОЖНО при желании писать уродливый и непонятный код. Можно делать хитрые "лайфхаки" в циклах, но язык не обязывает разработчика так поступать. В Rust в достаточно сложном коде запросто получается write-only не специально.
> Ага, и во всех перечисленных языках синтаксис разрабатывался изначально дизайном, где-то
> больше, где-то меньше.Да-да, особенно в JS был "дизайн", ага.
> И да, простое и тривиальное ПО на любом языке будет выглядеть сравнительно просто, зато когда в Rust начинает требоваться создавать сложное поведение, где-то применять unsafe, где-то контролировать
> время жизни (это вообще отдельная тема и иногда выглядит как удовлетворения
> компилятора, чтобы не ругался) в итоге всё превращается в кашу.Простое и тривиальное ПО на любом ЯП будет выглядеть просто, сложное ПО на расте - сложно ... Л-логика (нет).
Это в Си разрабатывался синтаксис вместе с дизайном?? Да там дизайна никакого не было! Почитайте историю его создания, хотя бы в википедии. Намекну - его разработали в 1973, а первый стандарт был аж 1989, который по факту просто зафиксиловал уже имеющийся синтаксис. А до этого были несовместимые диалекты, компиляторы и тд
До Си были A и B, так что Си был эволюцией
Вообще-то в C как раз очень продуманный дизайн, практически идеальный (хотя сложно сказать что можно было бы изменить, чтобы стало лучше, пожалуй можно было бы ещё поработать над препроцессором). И на самом деле практически любой человек, который хоть когда-нибудь программировал на ASM, схватит C на лету, потому что это тот язык, каким он и должен быть. Кстати именно поэтому он и выдержал испытание временем. И да, по поводу стандарта - де факто знаменитый труд K&R де факто был стандартом языка, более того, стандарт C11 только подпортил язык, добавив то, что ему вообще не нужно и по факту в реальной жизни почти все до сих пор и пишут на C89. Проблема в C в том, что там нет защиты от дурака (программист сам должен её реализовать в любом значимом проекте). На C можно создать ужасный и нечитаемый код, даже не специально, это зависит от квалификации. В C, особенно на ранних реализациях, можно искать лазейки, которые что-то сломают, но для этого надо СПЕЦИАЛЬНО пытаться что-то сломать, на сегодняшний день так и вовсе для 99.9% разработчиков всё пофикшено и однозначно определено.И кстати: "диалекты" C на практике были значительно сильнее похожи друг на друга, чем разные версии Rust (особенно если затронуть самые первые его версии).
Шо ж там продуманного такого? Препроцессор? Или может быть работа с указателями? Или L-value, R-value выражения? Как там работа с модулями поживает? А Юникод из коробки работает? Типизация (которой практически нет)?Чтобы понять, насколько Си устарел, достаточно вгзлянуть на новости здесь же, на этом ресурсе. Из сравнительно недавнего - какой-то перец хренову тучу времени разгребал код ядра и приводил его в порядок. Это из-за "продуманности" языка ему пришлось этим заниматься?
ИМХО, пора закапывать этого динозавра, и чем скорее, тем лучше.
А вот это вообще взаимоисключающий параграф: "На C можно создать ужасный и нечитаемый код, даже не специально". Это продуманность таким возможностям способствует? Ой...
> Это в Си разрабатывался синтаксис вместе с дизайном?Его системщики делали, а не вебмакаки. Поэтому смогли сделать компактное самодостаточное core языка достаточное для влезания в системные аспекты.
А хрустики на этом фоне - сущие бездари. Абстракций в 20 раз больше, при том когда это пытаются в системщине поюзать, лапы ломит и хвост отваливается. И там уже костылищ налепили столько что мама дорогая. А прикиньте, изначально в хрусте нельзя допустим попытаться повторить выделение памяти чуть попозже. Как вы относитесь к идее что у вас кернел #$%нется нахрен при душняке с памятью в системе по причине "не смог выделить память себе"? Многим ли юзерам падучие кернелы надо? Такая вот системщина от смузихлебов - с стабильностью win95. Теоретически это даже уже пофиксили, но конечно же на очередные костыли.
> А прикиньте, изначально в хрусте нельзя допустим попытаться повторить выделение
> памяти чуть попозже. Как вы относитесь к идее что у вас
> кернел #$%нется нахрен при душняке с памятью в системе по причине
> "не смог выделить память себе"?Как к любому твоему бреду - никак.
Потому что они срут всем, а не только себе.
Да нормальный там синтаксис, что вы как дети. Ничем не хуже С++.
Для инопланетян, возможно. Но не для вменяемых гуманоидов.
Те же скобочки, двоеточия да точки с запятой. Не то что питоны с собачками и пробелами.
> Те же скобочки, двоеточия да точки с запятой. Не то что питоны
> с собачками и пробелами.Это не так и проблема не в этом. Rust использует множество специальных символов, которые к тому же ещё иногда и можно комбинировать, получая какой-либо желаемый эффект (особенно если учесть приваренную намертво move-семантику). Простые программы с понятной и простой бизнес-логикой можно написать на любом языке и даже код получится примерно одинаковым. Проблемы то всегда начинаются в сложной бизнес-логике, когда множество сущностей каким-то образом взаимодействуют друг с другом, имеют состояние, что-то вычисляют и даже изменяют параметры друг друга по заданным правилам, а потом всё это отправляем в параллелизм и сходим с ума окончательно.
Одновременно с этим ЛЮБАЯ программа на C - это просто функции и структуры. Да, можно усложнить поведение передавая указатели или указатели на функции, можно поиграться с препроцессором, но в целом изучив вполне заурядные правила и изучив структуры данных, 90% задач с точки зрения программирования будут вполне тривиальными, сложности могут возникнуть лишь в предметной области.
>Одновременно с этим ЛЮБАЯ программа на C - это просто функции и структуры.Но ведь когда ты напишешь аналогичный код, он тоже будет работать по правилам:
">множество сущностей каким-то образом взаимодействуют друг с другом, имеют состояние, что-то вычисляют и даже изменяют параметры друг друга по заданным правилам, а потом всё это отправляем в параллелизм и сходим с ума окончательно."Я не могу привести сильной аргументации с примером, но для меня это слышится как "Си лучше потому что в нем нет лайфтаймов". Когда в Си есть объекты, и они тоже имеют свое начало и свой конец (времена их жизни). Просто в Раст есть установленные компилятором ограничения на отношения между временами жизни различных взаимодействующих объектов (напр. объект не может пережить своего владельца, или объект имеющий ссылку на другой объект может быть уверен что тот не уничтожится).
Также и в Си присутствует бойлерплейт, который может быть выражен более компактно и вместе с тем расширяемо. Да, для использования подобных конструкций нужно потратить дополнительное время на обучение. Взамен получаешь современные возможности без накладных расходов и с большей безопасностью:
-- удобные параллельные итераторы
https://play.integer32.com/?version=nightly&mode=release&edi...
-- генераторы парсеров сопоставимые по скорости с написанными вручную, влезающие на один экран монитора
https://zsiciarz.github.io/24daysofrust/book/vol2/day11.html
-- Можно построить абстракцию над портом ввода-вывода, которая во время компиляции будет проверять попадаешь ли ты в диапазон разрешенных значений, и правильную ли маску используешь при обращении к регистру.
https://blog.auxon.io/2019/10/25/type-level-registers/
> Одновременно с этим ЛЮБАЯ программа на C - это просто функции и
> структуры. Да, можно усложнить поведение передавая указатели или указатели на функции,
> можно поиграться с препроцессором, но в целом изучив вполне заурядные правила
> и изучив структуры данных, 90% задач с точки зрения программирования будут
> вполне тривиальными, сложности могут возникнуть лишь в предметной области.Это тоже раз на раз не приходится, но на хрусте наломать дров можно намного больше. Просто потому что он намного сложнее. А с изменениями которые потребовалось добавить для сабжа еще и костыльнее, многие изначальные допущения не удержались.
За си++ тебя Торвальдс пожизненно люстрирует из системного программирования - и будет прав!
Какая тебе разница? Ты все равно не пишет ни на rust, ни на си, ни на чём
>Напомним, что предложенные изменения дают возможность использовать Rust в качестве второго языка для разработки драйверов и модулей ядра.Надеюсь, не получится как всегда...
Не то процитировал
>Поддержка Rust преподносится как опция, не активная по умолчанию и не приводящая к включению Rust в число обязательных сборочных зависимостей к ядру.
Это для начала. А потом будет как обычно: модуль X на расте, софт от гугель требует модуль X (потому что так сказал гугель), поэтому в центос и бубунту проталкивают сборку раста по дефолту, поэтому его начинают использовать как либу другие компании уже со своим софтом, а переписывание модуля на си начинают студенты (которым заняться нечем) и само собой недоделывают его из-за сессии и теперь все пишут какой же модуль на си кривой, а на расте хороший, так что надо ядро на раст переписывать и т.д. и вот типичный EEE: он как бы не обязателен, а без него уже ничего не работает, проходит десяток лет и какой-нибудь "герой" предлагает его включать по дефолту потому что это уже стандарт... Много раз такое проходили.
Ну будем пользоваться ядром без раста. Это же как libre версия ядра без включения проприетарных компонентов.
> Это же как libre версия ядра без включения проприетарных компонентов.Ну и кто ей пользуется?
Ни чего не поделаешь. Всегда сидел на FF, перешёл полгода на Chromium. Без него не работает.Решает рынок, со стороны web-разработки Go порешал Rust.
> Решает рынок, со стороны web-разработки Go порешал Rust.А Rust в курсе? А то помнится мне, они немного для разных целей рекламировались.
А потом появляются статьи 'How to call Rust func from Go', потому что го тормозит
Так порешал, что дропбокс и дискорд на расте переписали часть сервисов гошных, так как из-за дурного сборщика мусора тормозило когда не надо
Интересно зачем вообще нужен раст? Для низкоуровневого уже есть Гоу который внушает больше доверия чем сомнительная поделка от неизвестно кого
В rust автоматическое управление памятью без garbage collector и его больших накладных расходов. Этим он принципиально отличается от go
> В rust автоматическое управление памятью без garbage collector и его больших накладных
> расходов. Этим он принципиально отличается от goПовторяем еще раз это есть и в C++ в умных указателях.
Тогда Rust это тот же Groovy для Java, когда уже есть Java. А Go это такой же Kotlin, но от очковых.
> Тогда Rust это тот же Groovy для Java, когда уже есть Java.
> А Go это такой же Kotlin, но от очковых.Нет, потому что синтаксис языка Rust - это полное нечитаемое гуано.
Да я не про синтаксис. Groovy не изобрели бы зная про другой язык. Это уже не ради чего-тио нужного создается, а чтобы показать новый неполный набор языка высокого уровня в более низком на замену Си. Hare хотя бы шансы имеет, но сдается мне системный софт надо писать на раст только до тех пор пока на Си не будет качественно переписаны драйвера. Штеуд вот втащил кучу денег в разработку драйверов под линукс, но не у всех есть такая возможность. Так что раст подойдет для прототипирования, а не как серебряная пуля. Языки высокого уровня куда сложнее нечитаемого раста.
> Повторяем еще раз это есть и в C++ в умных указателях.Не включены по умолчанию и всё равно полно возможностей получить UB по памяти
Хуже С++ нет ничего. Уродливое поделие робкого датчанина.
Давай, умник, расскажи мне про эффективность алокаторов.
> Давай, умник, расскажи мне про эффективность алокаторов.Самый эффективный аллокатор - это его отсутствие. А попробуй ка оспорь! :)
gcc alloca. Как говорят сами доки - _иногда_ позволяет повысить производительность (я не пробовал, поэтому более точных аргументов нет).
alloca() - это одна машинная команда, меняет регистр стека.
Менеджер кучи хранит списки свободных блоков, где выполняет поиск, это занимает некоторое время.
Если в выделенный буфер читается файл (долгая операция), то выигрыша нет.
> вариант библиотеки alloc, избавленный от возможных генераций состояния "panic" при возникновении ошибокХорошее управление памятью. И отсутствие накладных расходов интересное
Если бы ты хоть раз в жизни написал что-то сложнее hello world, то знал бы, что операция выделения памяти всегда может завершится с ошибкой. Это зависит не от языка, не от программиста, а от состояния компьютера и операционной системы.
>> panic
> ошибкаКак всегда, подмена понятий.
>>> panic
>> ошибка
> Как всегда, подмена понятий.Молодец, подтвердил что никогда не писал ничего круче Hello World.
>>> panic
>> ошибка
> Как всегда, подмена понятий.Как всегда, вопиющее невежество.
> Как всегда, подмена понятий.Лучше уж паника, чем профессиональный сишник, который забыл проверить успешность malloc.
> паника
> профессиональный сишникВсё разложил по понятиям.
>> Как всегда, подмена понятий.
> Лучше уж паника, чем профессиональный сишник, который забыл проверить успешность malloc.Где ты тут проф. сишников увидел?
Местные "знатоки" сишечку разве что в универе пару раз нюхали - а так питончик, ЖС и проч.
Иначе были бы в курсе, что такое аллокатор и не пытались бы с умным видом "критиковать" прикручивание кастомного для ядра (который, внезапно, точно так же сделали и для сишечки), как будто для этого нужно было "опять переписать раст", а не что-то типа
extern crate jemallocator;
use jemallocator::Jemalloc;#[global_allocator]
static GLOBAL: Jemalloc = Jemalloc;Тем более, не следует ожидать от них понимания, что растовая "panic" - или тупо вставка "abort" с выводом ошибки, если уж погроммист решил забить на обработку ошибок ИЛИ же тот же abort внутри "infallible" вызовов - что с точки зрения юзерспейсной разработки вполне нормальная стратегия, т.к. нормальную обработку нехватки памяти способны сделать "не только лишь все", да и повсеместный оверкоммит все равно "передает привет".
Trait std::alloc::GlobalAlloc
...
unsafe fn alloc(&self, layout: Layout) -> *mut u8
Allocate memory as described by the given layout.Returns a pointer to newly-allocated memory, or null to indicate allocation failure.
> тупо вставка "abort"Ты забыл - "неявная". Самое то для системного языка.
>> тупо вставка "abort"...
>> Result<T, E> is the type used for returning and propagating errors. It is an enum with the variants, Ok(T), representing success and containing a value, and Err(E)
>> pub fn unwrap(self) -> T
>> Returns the contained Ok value, consuming the self value.
>> Panics if the value is an Err, with a panic message provided by the Err’s value.
>> Because this function may panic, its use is generally discouraged. Instead, prefer to use pattern matching and handle the Err case explicitly, or call unwrap_or, unwrap_or_else, or unwrap_or_default.
> Ты забыл - "неявная". Самое то для системного языка.Зато ты не забыл нафантазировать что-то. Самое-то для очередного опеннетного коммента о расте.
#[stable(feature = "rust1", since = "1.0.0")]
pub fn unwrap(self) -> T
where
E: fmt::Debug,
{
match self {
Ok(t) => t,
Err(e) => unwrap_failed("called `Result::unwrap()` on an `Err` value", &e),
}
}fn unwrap_failed(msg: &str, error: &dyn fmt::Debug) -> ! {
panic!("{}: {:?}", msg, error)
}
Неявность прям "изо всех щелей", ага.
Паника кидается только из unwrap.
> Паника кидается только из unwrap.А теперь попробуй повторить выделение памяти и продолжить работать корректно с такой обработкой ощибок.
>> unsafe fn alloc(&self, layout: Layout) -> *mut u8
>> Allocate memory as described by the given layout.
>> Returns a pointer to newly-allocated memory, or null to indicate allocation failure.
> А теперь попробуй повторить выделение памяти и продолжить работать корректно с такой обработкой ощибок.А теперь попробуй вместо фантазий "как оно там на самом деле" иногда читать ветку обсуждения.
>> Как всегда, подмена понятий.
> Лучше уж паника, чем профессиональный сишник, который забыл проверить успешность malloc.Открою тайну, но профессиональные не пользуются malloc на каждом углу и относятся к выделению/освобождению памяти со всей ответственностью и ГОРАЗДО большей, чем разработчики на других языках. Само предложение "профессиональный сишник, который забыл проверить успешность malloc" - это нонсенс. И вообще во множестве проектов на C, если количество памяти (условно) "бесконечно" (а для C даже 512 мб - это ДОХРЕНА), то вся бизнес логика просто крутится в своей закрытой песочнице (часто не превышающей и 8 мб), тем более что она часто в любом случае нужна, чтобы в будущем было проще распараллелить вычисления не опасаясь за целостность данных. То есть проект может заведомо выделить из системы минимально необходимое количество памяти и освободить её непосредственно перед завершением, в то время как user-данные будут детерминированным образом обрабатываться и освобождаться и они уже могут занимать хоть гигабайты и ситуацию, когда память не выделилась потребуется написать только один раз. Проще говоря: профессиональные Сишники УМЕЮТ работать с памятью.
Определённые трудности могут быть, когда в железе скажем 1 мб памяти, но и в этом случае C тем более гораздо продуктивнее Rust будет её расходовать.
> То есть проект может заведомо выделить из системы минимально необходимое количество памяти и освободить её непосредственно перед завершениемНазывается arena allocator, можно написать на любом языке, в котором можно явно выделить память. Кто-нибудь, сообщите сишникам, что 21 век уже наступил.
Ну один-то раз надо проверить память, или я не так понял? И как раз в этом случае памяти будет выделяться довольно много, так что чекнуть надо 100%, ведь так? А что если паника в данном случае, или недостаток памяти?
А вы, как обычно заведено на этом сайте, не улавливаете жирную иронию. Да что ж это такое-то!
Есть ещё более страшная тайна: 512 байт уже дохрена и malloc нету в принципе. Но и линукса там тоже нету, к счастью.
> Лучше уж паника, чем профессиональный сишник, который забыл проверить успешность malloc.Особенно в линукскернеле, который при этом жестоко сдохнет при нехватке памяти в системе. Что совершенно не нашло понимания Торвальдса. Если вы win95 хотели, с падениями пару раз в день, она так то уже 27 лет доступна.
>> Лучше уж паника, чем профессиональный сишник, который забыл проверить успешность malloc.
> Особенно в линукскернеле, который при этом жестоко сдохнет при нехватке памяти в системе.
> линукскернеле
>> mallocО, очередного "спеца" подвезли.
> О, очередного "спеца" подвезли.Спецов было минимум 2, а у кернела таки есть свои аналоги этого самого. Называются чуть иначе, но идея та же самая - и в конце концов памяти может и не хватить. А хотя-бы и внутри ядра.
>> О, очередного "спеца" подвезли.
> Спецов было минимум 2, а у кернела таки есть свои аналоги этого
> самого. Называются чуть иначе, но идея та же самая - и в конце концов памяти может и не хватить. А хотя-бы и внутри ядра.И че? Че сказать-то хотел? Ветку не читал, сразу начал генерировать "ценное мнение"?
>> вариант библиотеки alloc, избавленный от возможных генераций состояния "panic" при возникновении ошибок
> Хорошее управление памятью. И отсутствие накладных расходов интересное
> ...
> Хорошее управление памятью.Это как?
Как в расте.
Го это ничем непримечательная поделка. Ты иди сравни быстродействие языков. Потом глянь на микроконтроллеры, хоть те же "умные" часы с несколькими мегабайтами памяти. Потом как бизнес подумай а нахрена ставить в часы гигабайты памяти вместо батарейки. Так вот там памяти как в старых роутерах, а ведь надо еще интерфейс отображать.
Ну как раз под мк поддержки раста практически и нет
Там, как ни странно, очень даже любят сишку
Да и зачем там раст, если всё ключевое там всё равно на сях
С - метрвый язык как ни крути. Пока мертвечину еще не закопали к сожалению.
Пруфы будут или как всегда?
Ага, все библиотеки по сей день пишут на чистом C (которые кстати легко адаптируются и под Rust при желании), мёртвый язык. Я уж молчу о нишевых решениях.
> низкоуровневого уже есть ГоуНастолько низкоуровневого, что в нём даже нельзя однозначно понять, когда string(bytes) скопирует байты, а когда нет? А замечательные nil это вообще песня. Или, например, нельзя дважды вызывать close(channel), а то будет паника. Никогда не думал что такое скажу, но даже JS лучше гошки.
Не понимаю, зачем пытаться пропихивать в ядро это новое, но уже ржавое, очевидно страдающее детскими болезнями, поделие, прикрываясь при этом словами о безопасности, когда уже 40+ лет как существует по-настоящему безопасный Язык Ада.
Экспансия же. Корпорации уже раскупили места у руля в цитадели зла(ещё на этапе котлована), теперь остаётся его сделать стандартом и рулить миром. Сначала ненавязчиво(прикрываясь заботой о природе, детях, безопасности, нервых клетках разработчиков, в общем всем хорошим против всего плохого), потом все более явно (как с ютубом, хромом, js, андройдом и тд). Много раз уже такое проходили, ничего хорошего в итоге не получается.
В аде гарбадж коллектор есть. В расте нет
Получается, Ада - лучше.
Не для системных задач
Про@баный Ариан 5 готов заспорить с этим храбрым утверждением.
> Ариан 5Можно пример ракетоносителя со ржавчиной?
> Про@баный Ариан 5 готов заспорить с этим храбрым утверждением.Но только у опеннетных оналитеков, прочитавших лишь желтенькие статьи вместо http://sunnyday.mit.edu/nasa-class/Ariane5-report.html
> уже 40+ лет как существует по-настоящему безопасный Язык Ада.Линус говорил что его пытались пропихнуть в ядро и что этот язык ужасен, что раст или go в сравнении с ним ещё более менее.
Для критических мест в реальном времени (АДА тут мимо, НЯЗ) в своё время придумали язык "Дракон".
Под советский "Буран", ЕМНИП. Там фишка в компиляции по блок-схемам. Т.е., под каждым типом блока лежит некая функция (хоть на сях хоть на асм), которую таки можно вылизать вплоть до доказательства сходимости и т.п. А стрелочки собирают из них нужную конструкцию.
Такая вот само-документируемая (куда уж дальше) штука.
Вот ето новость. Все ядро на Rust надо переписать!
Ооо Дааа Ruuust...
Они пытались - получилась редох. Но драйверы под неё написать, почему-то, не получается. Пишут под линух.
Для чистого Си экосистемой является GNU/Linux. А Rust - это чужеродное вкрапление. GNU/Linux прославляет копилефт и Свободу. А растаманы за разрешиловку-пермиссивщину. Растаманы не являются врагами проприетарного ПО, а линуксоиды являются врагами проприетарного ПО.Вывод: Rust Линуксу не нужен.
Зачем быть врагами ПО? Как только из ядра начали выпиливать GPLv3 начался упадок и компромиссы. Такими темпами какой-нибудь 9front состоится как замена устаревших UNIX, Linux. VESA режим там работает. Проблем с Rust никаких. Чистый Си. Офигенная скорость работы на совместимом железе.
> Для чистого Си экосистемой является GNU/Linux. А Rust - это чужеродное вкрапление.
> GNU/Linux прославляет копилефт и Свободу. А растаманы за разрешиловку-пермиссивщину.
> Растаманы не являются врагами проприетарного ПО, а линуксоиды являются врагами проприетарного
> ПО.
> Вывод: Rust Линуксу не нужен.GNU прославляет Открытость. Свободу прославляет BSD. Не стоит путать данные вещи. Свободой в GNU не пахнет от слова совсем. Ты в дофига пунктах постоянно кому то что-то должен.
>GNU прославляет Открытость. Свободу прославляет BSDКласическое перевирание: "Чёрное назвать белым, а белое чёрным".
В чём свобода GNU?
>>GNU прославляет Открытость. Свободу прославляет BSD
> Класическое перевирание: "Чёрное назвать белым, а белое чёрным".facepalmище - типичный опеннетчик-подросток с юношеским максимализмом, сам не читал - но знаю все! Налили в уши как-то.
А стоило бы попользоваться своим серым веществом то.. Если в лицензии существуют пункты в стиле "Вы не можете.." значит это вам запрещают. И где теперь свобода то?
Как-то из линукса я могу сделать многократно больше клевых ништяков чем из BSD. Вот она и свобода. А то что сорц придется дать и хрен с ним, 99.99% все-равно кодил не я...
> Как-то из линукса я могу сделать многократно больше клевых ништяков чем из
> BSD. Вот она и свобода. А то что сорц придется дать
> и хрен с ним, 99.99% все-равно кодил не я...Че за чушь от смузихлеба? Клевые ништяки?? Мдааассс..
> Че за чушь от смузихлеба? Клевые ништяки?? Мдааассс..Я предпочитаю делать то что мне самому нравится и кажется прикольным. Это так странно? В таком режиме я наиболее эффективен. Кроме всего прочего это включает мелкие одноплатные системки, чаще всего на ARM, околоуправляющей или мониторинговой тематики.
Вот линух туда лезет неплохо. Многие SoC хорошо поддерживаются майнлайном. Взял да запустил, с вполне разумными усилиями доступными для смертного. Отшлифовать острые углы - и получается клево. Нравится и себе и клиентам. К тому же с ними часто есть договоренность что я им полный пакет сорцов и доков (например кадфайлов на всякий кастом). Мне и самому так больше нравится, это нормальный современный подход.
А с BSD - дурных технические проблемы задолбают и устранить их реально толко будучи мегафирмой размером с сони. Без этого там нечего ловить. Да и их команда девов живет в каком-то своем мире.
> GNU прославляет Открытость."Сказавший такую глупость не может управлять кораблём. Ни-За-Что." (c)
Открытость без свободы - это когда можно смотреть, но нельзя использовать, распространять, изменять и т.д.
В GNU это есть, поэтому утверждение выше неверно.То, что BSD прославляет - это вседозволенность.
GNU - именно свободу. Она гарантирует, что её код всегда будет свободет во всех 4х отношениях.
Копилефт - это рабство, свобода насильно. Пермиссив - вот это истинная свобода. Свободнее только общественное достояние> линуксоиды являются врагами проприетарного ПО.
Нет, не являются, это вы себе придумали. Зачем враждовать, если можно сосуществовать?
>Пермиссив - вот это истинная свободаНет, пермиссивка это потакание проприетарщине.
> Нет, пермиссивка это потакание проприетарщине.Как пермиссив потакает проприетарщине? И почему это плохо? Он даёт другим программистам возможность использовать код как им надо, без всяких тупых ограничений на линковку с неоткрытым кодом и проч.
Это лезвие обоюдоострое. В случае с BSD лицензиями одиночный разработчик (маленький человек) может запросто и законно разрабатывать сложный проприетарный софт, некоторые элементы которого могут стать достоянием общественности (но без обязаловки). Это открывает возможность для ЗЛОУПОТРЕБЛЕНИЙ, то есть разработчики могут тупо начать воровать сколько угодно проектов, лепя своего Франкенштейна на совершенно законных основаниях, при этом добавляя немного маркетинга можно и неплохо заработать. GPL же существенно ограничивает использование кода для целей получения выгоды (по сути все, кто зарабатывают на GPL продают техническую поддержку, а не софт). GPL хорош тем, что позволяет некоторым проектам жить, например, Blender (который с переменным успехом крадут китайцы). Blender - уникальная софтина, т.к. это возможно единственный GPL-проект, который активно существует вне *nix среды в качестве готового, самостоятельного продукта. При этом ни одна проприетарная компания ничего не может ему сделать, за что Тон Розенталь (Б-г) часто всех троллит. В итоге на самом деле нужно И ТО И ДРУГОЕ! GPL эффективно защищает проекты от воровства кода (по крайней мере есть возможность законно подать в суд), BSD позволяет свободным художникам больше творить не опасаясь, что тебя ЗАСТАВЯТ раскрыть все карты. Как бы свобода свободой, но в реальном мире людям иногда надо кушать.
Слушайте, снимаю шляпу. В кой-то веки человек не просто поддержал BSD или GPL, обосрав оппонента, но расписал плюсы и минусы обеих точек зрения и указал, когда они нужны. Это здесь редкость, моё почтение вам, господин.
> Слушайте, снимаю шляпу. В кой-то веки человек не просто поддержал BSD или
> GPL, обосрав оппонента, но расписал плюсы и минусы обеих точек зрения
> и указал, когда они нужны. Это здесь редкость, моё почтение вам, господин.Вообще-то, там "Есть нюанс, Петька".
>> GPL же существенно ограничивает использование кода для целей получения выгоды (по сути все, кто зарабатывают на GPL продают техническую поддержку, а не софт).Это не относится к "толстым" SaaS-овцам (если мы не ведем речь о _A_GPL), типа амазона, гугла и прочих. Тот же Гугл с его "зажатыми" патчами для ЕXT вообще классика.
Да я хотел было раскритиковать, но потом подумал, что редко тут хотя бы такие развернутые комменты, поэтому хвалил> Это не относится к "толстым" SaaS-овцам (если мы не ведем речь о _A_GPL), типа амазона, гугла и прочих. Тот же Гугл с его "зажатыми" патчами для ЕXT вообще классика.
Да, от корпов никакие GPL не помогают. Они, если захотят, могут и сообщество просто прикорманить основное
> Слушайте, снимаю шляпу. В кой-то веки человек не просто поддержал BSD или
> GPL, обосрав оппонента, но расписал плюсы и минусы обеих точек зрения
> и указал, когда они нужны. Это здесь редкость, моё почтение вам,
> господин.Госпожа). И что важнее, я искренне считаю, что обе лицензии абсолютно необходимы:
BSD/MIT необходимы для создания базовых технологий, скажем человек уже работает на крупную корпорацию и требуется удобный алгоритм сжатия, но так, чтобы код можно было законно использовать в других проектах без юридической волокиты. Для этого разработчик пишет код под BSD-подобной лицензией в том числе для того чтобы ОН САМ мог использовать этот код В СВОИХ проектах, в том числе проприетарных. Если же код был бы написан в стенах корпорации для конкретного проекта - то возможно очень рутинные операции пришлось бы постоянно переписывать для проектов в других компаниях, а IT индустрия очень подвижна. Ну и также BSD позволяет разработчикам одиночкам не изобретать постоянно свои велосипеды и вообще не думать о том, что кто-то докопается.GPL, как уже рассказывала ранее более глобальная по смыслу лицензия. Она идеальна для законченных крупных проектов, где автор не хочет утратить над ним контроль. Другие люди могут как угодно видоизменять проект в своих ветках, но автор идеи никогда не будет лишён своего вклада. При этом вопреки распространённому мнению, это GPL вовсе не означает, что на нём нельзя зарабатывать. Если продукт полезен, то юзеры могут не просто инвестировать средства (альтруизм это утопия), а вполне из практичных и корыстных интересов направить разработчиков софтины по удобному пути. В 3D графике в случае с упомянутым Blender подобное встречается постоянно. Большинство новых фишек, что там появляются - появляются не просто так. Многие фишки - это выполнение требований/просьб инвесторов, при этом дубиноголовые "эффективные" менеджеры не могут вмешаться в процесс, они могут только сказать: хотим вот эту хрень, чтобы работала как в Maya или как в ZBrush (больные уб*@?ки в Blender скульпт почти с нуля переписали ради этого, получилось по отзывам 3D-шников очень круто). Всё это было бы невозможно под BSD лицензию, т.к. весь полезный код бы забрали конкуренты или авантюристы, выкатили бы на рынок тонны форков дешёвого хренового софта и сообщество бы не просто рухнуло, его бы и не было. GPL абсолютно бесполезна и даже вредна без активного сообщества.
Если кто делает пропретарные проекты, он очень так себе опенсорсничек, с ним дело лучше не иметь как по мне. Это я как экс-проприетарщик говорю :P. Я ж знаю за кого я держал клиентов и что я делал. И очень рад что нашел иные форматы, когда держать клиента за идиота и искусственно кидать его стало не обязательно.
>BSD позволяет свободным художникам больше творить не опасаясь, что тебя ЗАСТАВЯТ раскрыть все карты.БЗДунская лицензия прямо потакает проприетарщине. Проприетарщики любят бздуноподобные лицензии. Ты одобряешь пермиссивку и хвалишь GPL пытаяь усидеть на двух стульях. В реальной жизни ты либо за Столлмана (Добро), либо за проприетарщину (Зло).
>лепя своего Франкенштейна на совершенно законных основаниях, при этом добавляя немного маркетинга можно и неплохо заработать.
>GPL же существенно ограничивает использование кода для целей получения выгодыВот и видно гнилое нутро гпльщиков - и сам не заработаю и другим не дам. Не съем, так покусаю.
Когда человек говорит что зарабатывать/получать выгоду ЗАКОННЫМИ СРЕДСТВАМИ - плохо, то не стройте иллюзий - перед вами неудачник, коммунист, и враг прогресса.
И это видно по идолу коплефт движения Столоману - неопрятность, жизнь на подаяния, странный рацион.
Только BSD/MIT. Свобода не терпит компромиссов. Выбирающие GPL не получают ни свободы, ни заработка - если перефразировать классика.
Зароботок они получить могут - 90% писателей ядран на зп у корпов. Вот такая щвабода получилась.
А это уже не они. Те "они", кто это устроил - их могли и выкинуть. А корпы да, пришли и всем правят
>>лепя своего Франкенштейна на совершенно законных основаниях, при этом добавляя немного маркетинга можно и неплохо заработать.
>>GPL же существенно ограничивает использование кода для целей получения выгоды
> Вот и видно гнилое нутро гпльщиков - и сам не заработаю и
> другим не дам. Не съем, так покусаю.Ещё раз: GPL проекты, на подобие Blender во-первых на зарплате (сюрприз) от инвесторов, во-вторых это юридическая защита от того, чтобы ПО не было присвоено какой-либо корпорации ни за какие деньги, т.к. ПО разрабатывалось Open Source сообществом и полностью принадлежит ему. Если бы изначально Blender был BSD - корпорации бы попросту растащили весь его функционал и он бы никогда не развился так, как сейчас и не вышел бы за рамки недоделанного проекта, не говоря о серьёзной конкуренции на рынке. Причём весь производный продукт (это надо понимать), что вы делаете в Blender принадлежит исключительно автору (в этом иногда путаются даже западные художники), т.к. считается, что GPL лицензия распространяется вообще на ВСЁ, включая производимые материалы, это не так, под защитой только код самого ПО.
> Когда человек говорит что зарабатывать/получать выгоду ЗАКОННЫМИ СРЕДСТВАМИ - плохо, то
> не стройте иллюзий - перед вами неудачник, коммунист, и враг прогресса.Ключевые разработчики Blender абсолютно ничего бы не заработали на Blender, если бы работали под BSD/MIT и просто разбрелись бы по корпорациям кто куда не создав вообще ничего! Сейчас это целая индустрия, которая немало зарабатывает за счёт инвестиций, ассетов, плагинов. Это пример того когда GPL работает так, как задумано! И чтобы пояснить когда GPL может навредить, приведу другой пример.
Знаменитый Qt предоставляет лицензию GPL для opensource разработчиков, а для проприетарного софта нужно ПОДПИСЫВАТЬСЯ (то есть сейчас Qt даже купить нельзя). Казалось бы ну и что? В чём проблема купить? А проблема может быть: вы покупаете коммерческую лицензию, затем пишете своё приложение, которое плотно интегрировано в систему Qt, возможно даже с переписыванием кода в самом Qt, если это необходимо. Спустя время волею судьбы вы захотели перестать использовать Qt и расторгнуть контракт. И здесь владелец Qt подаёт на вас в суд обвиняя в том, что в вашем коде используется Qt, а у вас нет лицензии (и такие претенденты редко, но случаются). Это пример, когда уже злоупотребляют GPL.
Говоря проще: GPL лицензия идеальна для тех, кто пилит заведомо OpenSource проект (даже не обязательно, чтобы все услуги были бесплатными, как в примере с Blender). GPL защищает проекты, делая невозможным отобрать его у автора. В случае с BSD вы можете начать или раскрыть проект, который вы в одиночку осилить не в состоянии, но если это крутая идея, у вас просто забирают код, идею и выпускают проприетарный софт, а вы ВООБЩЕ НИЧЕГО НЕ ПОЛУЧАЕТЕ. И где же тут бизнес? Где мотивация вообще создавать ПОЛЕЗНЫЙ (речь не идёт о студенческих поделках и экспериментах) код под BSD/MIT, если кто угодно может его присвоить? Это приносит пользу лишь в тех случаях, когда вы создаёте или поддерживаете проект, который ИЗНАЧАЛЬНО задумывался таковым, чтобы раздать его всем (и себе тоже) бесплатно и возможностью применять где угодно, здесь хороший пример SDL2.
> Вот и видно гнилое нутро гпльщиков - и сам не заработаю и другим не дам. Не съем, так покусаю.GPL вообще совсем не запрещает зарабатывать на софте, внезапно. Прикинь?!
>это видно по идолу коплефт движения Столоману - неопрятность, жизнь на подаяния, странный рационА по лидеру (одному из) BSD движения Маккузику что видно? Жизнь через <>, другую сторону... если ты понимаешь о чем я.
Но в основном 99% этим пользуются проприетарщики
> Но в основном 99% этим пользуются проприетарщикиЭто сути Свободы не меняет.
> Это сути Свободы не меняет.Свобода быть зохаваным мегакорпом потому что он всяко сильнее меня - мне ни к чему.
> Свободнее только общественное достояниеПод принуждением государства. А так немало попыток прихватизировать произведения, перешедшие в общественное достояние.
> А так немало попыток прихватизировать произведения, перешедшие в общественное достояние.Это не запрещено и по закону можно так делать, насколько я помню. Хотя может право на имя и бессрочное, не знаю. Но имущественных прав на достояние естественно нет, можешь пользовать как хош, это точно
> Это не запрещено...И за этим следит государство, а не природа.
Так в правовой сфере везде так
> правовой сфереМожет, надо с терминологией разобраться? А то "свободу" на что только не натянули.
Например начать с того, что "свободу" заменить на "право, данное таким-то государством" (делать или не делать что-то).
Старый вы слишком. Свобода это вседозволенность и т.е. невзирая ни на что и даже на общество.
> Старый вы слишком. Свобода это вседозволенность и т.е. невзирая ни на что и даже на общество.Ну, ок, тогда давай я тебя к веслу прикую, сможешь насладиться свободой по полной? :)
Поэтому я на Фряхе под лицензией "Нате и делайте что хочите"
> Копилефт - это рабство, свобода насильно.Ещё одна чушь.
Для пользователя/контрибутора: Свобода изучать, изменять, хранить и распространять код - это именно свобода, а не обязанность.
Для глав-разраба: Никто не заставляет его пахать иначе как сторонним договором, к копилефту не относящимся.Пермиссив отличается только возможностью тырить оттуда код в закрытые проекты. За что его и любят зами знаете кто.
> а линуксоиды являются врагами проприетарного ПО.Да-да, особенно любят "враждовать" из под WSL или макоси (как например местный модератор-борец-за-GNU).
Какая это "свобода" затесалась в GNU/Linux? Это там где все решает один чел? Классная свобода...
> Инструментарий и вариант библиотеки alloc, избавленный от возможных генераций состояния "panic" при возникновении ошибок
> Добавлена блокировка NoWaitLock, которая никогда не приводит к ожиданию освобождения, а в случае занятия другим потоком приводит к выводу ошибки при попытке получения блокировки вместо остановки вызывающегокоторый год костыли и подпорки городят для растовиков, напрашивается вопрос - накой тащить язык который не подходит для ядра в ядро ?
>> https://www.kernel.org/doc/htmldocs/kernel-api/API-kmalloc.html
>> kmalloc is the normal method of allocating memory for objects smaller than page size in the kernel.
>> https://www.kernel.org/doc/htmldocs/kernel-locking/trylock-f...
>> There are functions that try to acquire a lock only once and immediately return a value telling about success or failure to acquire the lock.
> который год костыли и подпорки городят для растовиков, напрашивается вопрос - накой тащить язык который не подходит для ядра в ядро ?Который год опеннетные Воены Против Раста c умным видом несут хрень ...
> panic
> kmallochttps://lkml.org/lkml/2021/4/14/1099
> NoWaitLock
> trylock Functionsspin_trylock() и mutex_trylock() проверяют обычные спинлоки и мьютексы, для этого не нужно как в расте создавать специальную блокировку
>> panic
>> kmalloc
>> пукЯсно.
>> NoWaitLock
>> trylock Functions
> spin_trylock() и mutex_trylock() проверяют обычные спинлоки и мьютексы, для этого не нужно как в расте создавать специальную блокировкуПроверяют через либастрал, ага.
>> Инструментарий и вариант библиотеки alloc, избавленный от возможных генераций состояния "panic" при возникновении ошибок
>> Добавлена блокировка NoWaitLock, которая никогда не приводит к ожиданию освобождения, а в случае занятия другим потоком приводит к выводу ошибки при попытке получения блокировки вместо остановки вызывающего
> который год костыли и подпорки городят для растовиков, напрашивается вопрос - накой
> тащить язык который не подходит для ядра в ядро ?Чтобы "ремесленникам-программистам" уровня 1С платить в 10 раз меньше. Профи - всегда хотят много, да еще и нарасхват.
Дорогой Мигель (ты же читаешь?)!
Лучше бы занялся системами сборки (Ninja или tup). Мы бы поблагодарили, да!
https://redo.readthedocs.io/en/latest/> redo: a recursive, general-purpose build system
Пихон не нужен, совсем.
Эта страница для быстрого ознакомления что это. Оригинальный redo на (ba)sh.https://redo.readthedocs.io/en/latest/#how-does-this-redo-co...
> для быстрого ознакомления что этоЯ даже с DJB знаком, но всё равно спасибо. :)
А вот https://github.com/leahneukirchen/redo-c на Правильном и Нужном Языке.
Вarning! Автор - бывший мужик.
Как обычно, только автор отходит от дел, так набегает сообщество и превращает творение в кучу ненужного хлама.
Нет автор ушел именно потому что уже понял что это хлам.
Кому надо было - уже нафоркали достаточных сырцов.
От приведённого примера кода мои глаза снова вытекли.
На этом реально кто-то всерьёз пишет?
Нет
Гм, а чем плох код? Лаконичный и ясный. Если что, уже с год пишу разные микросервисы на Rust для связи блокчейнов с GUI-инструментами. Rust только радует, давно у меня не было такого субъективно комфортного языка (пожалуй, со времён первого Delphi).
Это методичка у них такая, забей на этих сиплюсплюснутых ботов.
А синтаксис у Rust Language наиприятнейший😋
что же ты сам себе отвечаешь-то, анонимный писака наиважнейших сервисов?
Аутотренинг по утрам?
> Гм, а чем плох код? Лаконичный и ясный.Хорошо пошутил.
> Если что, уже с год пишу разные микросервисы на Rust для связи блокчейнов с GUI-инструментами.
А, у тебя просто специфика такая, понимаешь, кому и поля Галуа как 2 * 2, но это не всем же так :)
Да, и с большим удовольствием.
Пора закрывать комментарии в темах про руст.
Пора не писать даже-не-минорщину в (главных) новостях
Когда нечего отвечать, пытаетесь закрыт людям рты
Типичная демократия.
> Когда нечего отвечать, пытаетесь закрыт людям ртыМожет он намекнул что о мертвых или хорошо, или ничего? :)
Я бы и темы эти под кат убирал, всё равно они только минорщине интересны, а остальные в них поржать ходят, и посмотреть, каких знаков препинания в этот хлам ещё насовали.
Зачем? Не нравится - не читай.
Очень печально. Руст вносит большую неразбириху. Тескты программ, как из прошлого века изобилуют разными колючими символами расставленными то тут то там, скобки, толстая система сборки, да и вообще синтаксис языка отдаёт какимто васянством.
Да нормальный синтаксис, выручите уже и успокойтесь
> толстая система сборкиТолще чем у JAVA? А вообще, наблюдая за развитием всего этого, складывается впечатление, что будущее (в прикладном софте) за скриптовыми языками и динамической компиляцией.
> Толще чем у JAVA?Жаба - образец эталонности.
> будущее за скриптовыми языками и динамической компиляцией.
Надо же как-то утилизировать слишком избыточные мощности процов.
> Жаба - образец эталонности.Эталонности громоздкости?
> образец эталонностиреспект и уважуха
> Жаба - образец эталонности.Эталон блоатвари, тормозов и энтерпрайзности. Фу таким быть.
В java отличная система сборки, один Gradle или maven которые делают всё и очень быстрая компиляция.
В java программа компилируется быстрее чем один только makefile для сборки во всяких там языках создаётся.
> один Gradle или mavenТыж назвал целых два, а их куда больше 🤦♀️ а за xml вообще надо кастрировать в 2к22 году.
А что лучше? Json, yaml, toml? Может ini файлы?)
У них всех есть свои недостаки...
Правильно пишется так: "Хруст наносит сильную ниразбириху и ваняит какимто васянством. Я у мамы иксперт."
Linux переписыввают на Rust!!!
Люди добрые, да что же это такое творится?!
> что же это такое творится?Просто растаманы не смогли дописать свою редох.
>> что же это такое творится?
> Просто растаманы не смогли дописать свою редох.Че там с Hurd?
С Hurd всё нормально - лежит и не шевелится.
>дописать ОСБыло ли такое в истории вообще - дописанная ОС?
Жаль ни кто не занимается bare-metal, полностью ring0 осей. Такое подходит Раст очень, это быстрый язык и при этом безопасный по памяти. Получается в теории потокам программы не придется переходить в ring3 вообще чтобы получить безопасность по памяти и изоляцию. Понятно что тогда придется использовать особый компилятор Раст (желательно верифицированный).
Хоть немного утопично, но звучит интересно - "Программы работающие без переключения контекста, и при этом не требующие сборщик мусора с его Остановкой Мира при очистке".
Вот чего стоит перейти в ring0, в самом низу таблицы -- http://ithare.com/wp-content/uploads/part101_infographics_v0...
... а потом еще обратно надо в ring3
Любопытно, что большая часть кода в этой "прослойке" содержит unsafe. В таком случае, какая польза от Rust? Без шуток, действительно интересно.
Ну так это в прослойке, код который с её помощью будет подключаться, будет safe
Стадии ансейфа:
- Нинини!
- Только один единственный ансэйф!
- Ну, можно и в нескольких местах... Я же контролирую себя.
- Везде-везде-везде...
- Где бы ещё ансейф сделать?
Как какая? Код помечен unsafe! Сразу видно где искать проблемы! (ну да, весь код. В нем и искать.)А на устаревшей сишечке ведь никому и в голову не придет их искать - нет меток, смузихлебы не могут так работать.
Театр безопасности аля оградительная лента.
Искать будут в unsafe, а ошибка окажется, как обычно, в другом месте.
Поэтому она и называется "прослойка" - потому что использует существующие абстракции. А всё внешнее для раста - unsafe.
Никакой пользы от Раста нет. Призыва писать на Хаскеле был бы столь же релевантен.
Польза есть - не нужно тратить годы на С++ с его стандартом на тыщу с гаком страниц и даже спустя 10 лет быть не сильно уверенным, что не налажал где-то. Есть опыт выкатки в прод пачки маложрущих рестовых сервисов с предсказуемым latency в силу отсутствия сборки мусора. Синтаксис зело проще и напоминает OCaml. Че так все взъелись на язык, который идейно отличается от большинства известных, компилирующихся в нативку, только тем, что имеет принудительное следование RAII в compile-time - решительно непонятно. Для перекладывания жысонов unsafe не нужон вообще.
> на тыщу с гаком страницРуст существует не так давно по меркам С++, а уже претендует на две тыщи с гаком страниц. По сложности эти два языка вполне могут соревноваться. Вот только нужны ли они оба?
За примерно 4 года регулярного взаимодействия с растом уверенно могу сказать, что для повседневного использования раст сильно проще. В нем нет каких-то мозговыламывающих вещей из области С++, по типу метапрограммирования, иерархию значений с точки зрения абстрактной С++-машины (rvalue, glvalue, xvalue), SFINAE, perfect forwarding и т.д.. Первое время было сложно совладать с borrow checker, но регулярно читая жалобы компилятора, "правила игры" быстро усваиваются. Все остальное - почитать пару учебников от O'Reilly и позадавать/погуглить вопросы на стаковерфлоу. Еще раз повторюсь, что есть опыт использования раста в контексте бэкендерских задач для типичной корпоративщины, не осведомлен, какие сложности возникают у тру системных прогеров, которые пишут дрова и кастомные аллокаторы памяти. Мой опыт использования только позитивный, какую-нибудь джаву или C# по производительности и жору памяти рвет в клочья, никаких NPE в силу их полного отсутствия в языке, а по сравнению с Go отсутствие необходимости инвестировать время в изучение теории работы сборщика мусора и как с ним совладать, чтобы не было stop-the-world на 10 секунд в самый неподходящий момент.
> раст сильно проще. В нем нет ... метапрограммированияАссемблер сильно проще, в нём вообще ничего нет, а блок unsafe всего один.
>> раст сильно проще. В нем нет ... метапрограммирования
> Ассемблер сильно проще, в нём вообще ничего нет, а блок unsafe всего один.Просто Воены Супротив Раста, как обычно, знакомы с матчастью лишь по комментам на опеннете ...
FASM
macro use32
{
macro push args
\{
local list,arg,status
define list
define arg
irps sym, args \\{
define status
match =dword, sym \\\{
MASM
@SaveRegs MACRO regs:VARARG
LOCAL myEnd, num, flag, regnum=0
flag=0
WHILE flag EQ 0
% IFDEF @CatStr(<RealEnd>,<%num> )
num = num + 1
ELSE
flag = 1
ENDIF
ENDM% FOR reg, <regs>
push reg
ENDMNASM
%define xyzzy(=expr,&val) expr, str
%define plugh(x) xyzzy(x,x)
db plugh(3+5), `\0` ; Expands to: db 8, "3+5", `\0`
А предельно простые mov, push, jmp не осилил? К чему эти макросы? Попытка сваять своё подобие языка высокого уровня?
>>> В нем нет ... метапрограммирования
>> <тыканье носом в лужу>
> А предельно простые mov, push, jmp не осилил? К чему эти макросы?
> Попытка сваять своё подобие языка высокого уровня?Занятный юлеж (и заодно, перепись опеннетных "Знатоков").
Btw, у очередного опеннетного теоретика^W "знатока матчасти" автор FASM (а тот кусок был из сорца самого ассемблера, реализация режимов LINUX/X64/MODES.INC, впрочем, макрос для MASM тоже был "штатный") - "неосилятор".
> Btw, у очередного опеннетного теоретика^W "знатока матчасти" автор FASM (а тот кусок
> был из сорца самого ассемблера, реализация режимов LINUX/X64/MODES.INCУже пора из fasm g публиковать _макросы_ mov, push, jmp :)
> раст сильно прощеЭто пока, а года через три будет винегрет похлеще крестов.
Ну либо пруфы в студию, какие фичи за последние лет 5 завезли в ржавый, что если сравнить "тогда" и "сейчас", то мать родная не узнает, либо утверждение голословное.
> Ну либо пруфы в студию, какие фичи за последние лет 5 завезли
> в ржавый, что если сравнить "тогда" и "сейчас", то мать родная
> не узнает, либо утверждение голословное.Так новость прочитай. Или если храбрый - вон туда в рассылку к линуксоидам сходи. Там есть фич которые вот-вот уже без пяти минут как есть в ночной версии, и вообще, идет уже пятый год стабилизца синтаксиса, только почему-то самые базовые системные вещи все-равно прикручивают на проволоку и скотч.
>> Инструментарий и вариант библиотеки alloc
>> Предложена начальная реализация модуля "net"
> Так новость прочитай. Или если храбрый - вон туда в рассылку к линуксоидам сходи. Там есть фич которые вот-вот уже без пяти минут как есть в ночной версии, и вообще, идет уже пятый год стабилизца синтаксиса,Так-так, вариант библиотеки alloc (ничего, что для сишки там тоже спец. вариант?) резко стал изменением синтаксиса. Ох уже эти опеннетные "спицы".
А также всякие боксы где аллокация таки может не получиться и все такое прочее. Хотели как лучше, а получилось как всегда - оказалось что падеж программы по панике катит далеко не всем, особенно в системщине. И получились в результате фееричные костыли. Чем оно лучше сей и плюсов в результате то? :)
> А также всякие боксы где аллокация таки может не получиться и все такое прочее.А также всякие фантазии оеннетных знатоков и прочие сравнения опы (std либы) с пальцем ...
> Хотели как лучше, а получилось как всегда - оказалось что падеж программы по панике катит далеко не всем, особенно в системщине. И получились в результате фееричные костыли.Но только в фантазиях местных "знатоков", не различающих язык и его std либу.
> Чем оно лучше сей и плюсов в результате то? :)
Стабильным припеканием пятых точек "знатоков" на опеннете.
ЗЫ: для теоретиков, слышавших лишь звон:Trait std::alloc::GlobalAlloc
...
unsafe fn alloc(&self, layout: Layout) -> *mut u8
Allocate memory as described by the given layout.
Returns a pointer to newly-allocated memory, or null to indicate allocation failure.
> ЗЫ: для теоретиков, слышавших лишь звон:
> Trait std::alloc::GlobalAllocКстати, GlobalAlloc() - функция из Win API. Там она зачастую служит маркером малообразованных буратин, не читающих документацию.
> А также всякие фантазии оеннетных знатоков и прочие сравнения опы (std либы) с пальцем ...Так там std либа активно сватается как крутая фича языка. И вообще в целом дизайн яп и стдлибы такой что деланы они явно не пальцем, а с тем с чем его сравнивали. Поэтому в той чудной рассылочке можно найти дюжины фееричных костылей, которые вот уже почти внедрили в ночнушку.
А прикольно когда создатели "типа системного" языка показательно игнорят многолетний опыт окружающих и собирают все грабли самолично, в максимально дурном формате. Еще сильнее изгаживая синтаксис. А вы думали что всякие зиги и хари появляются просто так? А вот и хрен, это попытка сделать то же самое менее черезджеппно :)
> Но только в фантазиях местных "знатоков", не различающих язык и его std либу.
В хрусте стдлиб почти прибили на гвозди. И сколь-нибудь нормального standalone режима там почти и нету, что самое интересное. Вплоть до того что эта фигня подразумевает MMU и без него вообще гарантий не дает.
> Стабильным припеканием пятых точек "знатоков" на опеннете.
А также стабильными факами системщиков в адрес рож с хрустом, расскащывающих как на нем круто системщина делается - главное чтобы это кто-то другой кодил.
> В хрусте стдлиб почти прибили на гвозди. И сколь-нибудь нормального standalone режима
> там почти и нету, что самое интересное. Вплоть до того что
> эта фигня подразумевает MMU и без него вообще гарантий не дает.Стандартная библиотека отключатеся одной строкой в главном файле модуля - "#![no_std]". При этом теряется возможность подключать имена из модуля std (стандартной библиотеки), а только остается использовать голый core - в котором нет типов использующих heap (потому не превязаных к MMU ОС). Документация по модулю, соответственно логически разделена для удобства навигации.
Для интересующихся советую вот из этой статьи промотать на параграф "Пример" и посмотреть самим как это может быть просто и безопасно в Раст https://habr.com/ru/post/495948/ (заметьте что в статье используется Cortex-M у которого нет MMU)
> Польза есть - не нужно тратить годы на С++так и без раста не нужно тратить годы на плюсы - в ядре плюсов нет, совсем. Для знакомства с растом в системном программировании намного интересней живые иллюстрации
в ядре Linux раст не нужен, он не даёт никаких преимуществ по сравнению с С
Си даёт гарантии, что какой-то указатель не будет использован повторно после free()? Си годная тема для МК, чтобы не опускаться до всяких MIPS ассемблеров и написать несложную логику на пару тысяч строк, которую, разбив по файлам, вполне можно досконально вычитать. Миллионы же строк на С - это кошмар, ничего нельзя трогать, не запуская статический анализатор каждый раз, чтобы, не дай бог, не пролез "человеческий фактор".
> Си даёт гарантии, что какой-то указатель не будет использован повторно после free()?дело в том что и раст в ядре таких гарантий не даст - буферы и блокировки используются разными подсистемами ядра, чтобы следить за ними в компилетайм надо чтобы всё было написано на расте. Вот придумали они свои реализации alloc, smutex::Mutex и NoWaitLock - а что с ними делать в сишном коде ? т.е. смысл в них есть только для растовиков, для изолированного пользования только растокодом
> С - это кошмар, ничего нельзя трогать, не запуская статический анализатор каждый раз
не надо утрировать, просто дизайн монолитного ядра ущербный изначально
Си даёт гарантии, что какой-то указатель не будет использован повторно после free()? Си годная тема для МК, чтобы не опускаться до всяких MIPS ассемблеров и написать несложную логику на пару тысяч строк, которую, разбив по файлам, вполне можно досконально вычитать. Миллионы же строк на С - это кошмар, ничего нельзя трогать, не запуская статический анализатор каждый раз, чтобы, не дай бог, не пролез "человеческий фактор".
Все это верно только если кодер модуляризацию ниасилил. Более того - на хрусте в этом случае будет точно такой же кошмар. А может и более хреновый - кто его знает как там с статическим анализом и отоловом крайвых дурных ситуаций? Вон на хрустософт уже сотни CVE так то есть.
Это называется FFI, в примере Раст-Си это место где встречается небезопасный язык с безопасным. Будь Си безопасен в том же самом смысле что и Раст - этого бы не потребовалось. И наоборот если бы Раст был небезопасным этого бы тоже не потребовалось.Многие безопасные языки не указывают явно в коде что он может вызвать сайд-эффекты, неопределенное поведение и просто краши, которые невозможны в других частях кода. В Раст это требование, поскольку растоманы сочли grep по unsafe удобным способом аудита. Лучшим чем кастомные комментарии к функциям, которые можно и забыть написать.
Кстати, Раст поддерживает LTO в FFI с Си и С++ кодом.
> Кстати, Раст поддерживает LTO в FFI с Си и С++ кодом.Приписал возможности LLVM ржавому. Скажи еще, что код оптимизирует на уровне Си.
>> Кстати, Раст поддерживает LTO в FFI с Си и С++ кодом.
> Приписал возможности LLVM ржавому. Скажи еще, что код оптимизирует на уровне Си.Приписал возможности LLVM/GIMPLE Си. Скажи еще, что tcc/cproc/Turbo C оптимизируют точно так же.
>Скажи еще, что код оптимизирует на уровне Си.Не приписывайте возможности LLVM ветхому, а то замечательный TCC обидится :)
Кстати, для Раст активно пишется gcc кодогенератор https://rust-gcc.github.io/ (спонсируемый).
> Не приписывайте возможности LLVM ветхомуВопрос: где я приписал Си оптимизацию?
Я тролльнул устоявшимся штампом, когда скорость сравнивают с Си. Сразу набежали "знатоки матчасти".
Так что с LTO у Rust?
> Кстати, для Раст активно пишется ... кодогенератор
Раньше модно было писать .net/jvm кодогенератор.
>Я тролльнул устоявшимся штампом, когда скорость сравнивают с Си.А с чем же еще сравнивать, не с ассемблером же? Да, когда люди сравнивают "скорость с Си" они подразумевают эталонные реализации. Си считается языком с самым близким уровнем к железу и с проработанными компиляторами.
И при всем этом Си довольно далек от ассемблеров. Это не низкоуровневый язык https://queue.acm.org/detail.cfm?id=3212479>Так что с LTO у Rust?
А что с ним? Над ней работали, и с 2019 года релизнули. Стоило об этом упомянуть, потому как не у всех managed языков такое есть, некоторые просто используют динамическую линковку. А Раст при этом более безопасен чем managed языки. Quite an achievement
Кстати, в контексте треда, спонсируется адаптация Раст для построения систем с особыми требованиями к безопасности (автотранспорт, мед./промышленное оборудование, космические/боевые системы, воздушные суда и т.п) https://ferrous-systems.com/ferrocene/ . Есть вероятность что наработки потом окажутся в ядре.
Тем кто укоряет Раст, якобы он не подходит для построения некоторых типов систем, вот архитектура построения UI на Раст https://raphlinus.github.io/rust/gui/2022/05/07/ui-architect... от Raph Levien. Понятно что может применяться не только для UI. Талантливые программисты находят новые паттерны проектирования подходящие под специфику Раст; можно надеяться что в будущем писать некоторые системы станет проще.
+ еще для развлечения текстовый редактор в 1024 строки кода с доп возможностями https://github.com/ilai-deutel/kibi#comparison-with-kilo
> А с чем же еще сравнивать ... ?
> А Раст при этом более безопасен чем managed языки.
> Талантливые программисты находят новые паттерны проектирования
> + еще для развлечения текстовый редактор в 1024 строки кодаСтолицу уже перенесли в Нью-Васюки?
Скоро уже ядро будет собираться сутки? А то поржать хочется.
Всё уже собрано до нас. Я ради интереса в прошлом году собрал под 4 пень со всеми оптимизациями под HT и netburst. Разницы никакой от слова совсем.
А что ты ожидал там увидеть, тем более на таком мусорном железе?
Мусор у тебя в голове.
Эт ты ща серьёзно хочешь сказать, что железо, которое едва-едва потянет h264 в 720p (в лучше случае, не больше 30 кадров в секунду), можно считать чем-либо помимо мусора? У тебя всё хорошо с головой? А про то, что разницы на таком кале не будет, это очевидно и ожидаемо.
> h264 в 720pНу точно понос в голове, раз КОМПЬЮТЕР рассматривается как мультимедийное говно для ютуб-дебилов, а не как вычислительная машина для работы)))
Какая там работа, ты не в себе. Если даже топовый проц в любом случае неэффективная кукуруза без поддержки минимальных мультимедийных инструкций, с кривым гипертредингом, и ещё не вспоминал про тормозную память… Мультимедия это пример простейшей примитивнейшей задачи на сегодня. Даже в виде печатной машинки для набора текста (только набора, в текстовом формате) такое больно использовать. Я тебе о другом говорю, ядро не рассчитано на такое железо и все улучшения софта упрутся в недостатки самого железа.
> Какая там работаБожечки!!! И как каких-то 10-15-20 лет назад люди работали за компьютером, создавали музыкальные треки, навсегда вошедшие в историю мировой музыки, монтировали видео и создавали 3D графику??? А сейчас даже на i9 вкладочка хрома тормозит, да??? Ребёнок, не позорься, для твоего рвения потреблять контент хватит любой мобилы за 100 баксов.
Дядя, ты дичь порешь. Не пори дичь, ей больно. Ты ведь вообще не в теме, о чём рассуждаешь. В то время на этих убогих пнях не решали ничего сложнее офисных задач.
> Дядя, ты дичь порешь. Не пори дичь, ей больно. Ты ведь вообще
> не в теме, о чём рассуждаешь. В то время на этих
> убогих пнях не решали ничего сложнее офисных задач.В (первом) старкрафте например музыкальные треки были с тэгами такой штуки как SoundForge. И это какие-то 90-е, чтоли. Ах да, полуспайварный полуопенсорс аудасити косит именно под эту штуку. Только вот оно реально работало на первых пнях - и без какого там еще отсыла телеметрии.
Ни о чём не говорит. Синкай тоже свое первое аниме рисовал в фотошопе, о спеках и эффективности данного процесса правда ничего не известно, это не значит, что CGI в фотошопе кто-то делал. Или там можно вспомнить, что в 2020 музыку делают на слабосильном домашнем железе из 80, нормальные синтезаторы из 70 при этом были куда мощнее и круче.
Это классическая двух ходов очка:1) Язык XXX не тормозит! Вообще! Он даже быстрее!
2) Ваше старое железо просто не рассчитано даже на примитивнейшие задачи, поэтому бесполезно пытаться что-то оптимизировать!
Быстрофикс: s/Язык XXX/XXX/
>вычислительная машина для работывот это особенно смешно было, ты его хоть запускал, или так, для красоты купил?
Да для вас все что старее месяца уже помойка и тормозит. Под вас ютупчики и оптимизируют
Для кого, "для вас"? Речь вроде была только про самый мусорный интел за всю историю, хотя, в целом применимо к любым камням тех лет. Всё, что новее ~2007, вполне можно использовать, с оговорками.И возраст это такой себе показатель, сегодня тоже делают слабые камни, но сегодня это в основном будут нормальные камни, за свои деньги.
Ютуб, кстати, неплохо оптимизирован, непонятна суть претензии, у меня вот видео в браузере потребляет ресурсов меньше чем то же самое видео в mpv. Процессору около 15 лет.
> Всё уже собрано до нас.До вас. Потому что обезьяна с гранатой - это еще не системщик.
> Я ради интереса в прошлом году собрал
> под 4 пень со всеми оптимизациями под HT и netburst. Разницы
> никакой от слова совсем.Так ты не был в курсе как ядро надо собирать чтобы разницу ощутить. Попробуй например tickless ядро с full preempt. Это сочетание экономии питания (для лаптопов) с низкой латенси для оптимального юзерэкспериенса в системе. Дистры в лучшем случае делают компромиссные настройки, даже в low latency ядрах.
Нет, это не решит все проблемы человечества. И не даст +150% в скорости. И не избавит от ВСЕХ приколов. Но это ЧАСТЬ делания системы комфортной в работе. Ну, понимаешь, кто-то воспринимает фриз мыша или там тормозную реакцию системы как данность. А кто-то хочет плавно и приятно работающую систему, которую в принципе не клинит и не надо туповэйтить если не взваливать откровенно неподъемные задачи.
Вообще, если кто лечит за производительность на десктопе - очевидно что он ничерта не смыслит в user experience. На сервере плюс-минус 100мс реакции пофиг и можно группировать операции большими батчами, поимев прибавку скорости. Но user experience на десктопе с такой системой полный кошмар. Не понимая даже вот это лезть что-то менять в настройках кернела и называется (веб)абизяной с гранатой.
Вообще растишка уже не меньше чем полгода, а то и больше собирается относительно шустро.Где то с 1.46. К тому же как тут олды писали не надо же собирать эл конфиг. В Слвке пробовал однажды с их максимальным конфигом, так и без хруста несколько часов ушло.
Thu Oct 7 11:13:34 2021 >>> dev-lang/rust-1.53.0
merge time: 1 hour, 27 minutes and 58 seconds.Sun Dec 5 16:50:19 2021 >>> dev-lang/rust-1.56.1
merge time: 1 hour, 35 minutes and 11 seconds.Wed Apr 27 15:17:23 2022 >>> dev-lang/rust-1.59.0
merge time: 1 hour, 34 minutes and 58 seconds.
Сколько собирается GCC (с бутстрапом) со всякими Fortran'ами и Ada'ми?
на той же машине как раз с фортраном gcc.
Tue Jul 20 11:53:35 2021 >>> sys-devel/gcc-10.3.0-r2
merge time: 1 hour, 6 minutes and 57 seconds.Sun Dec 5 14:41:02 2021 >>> sys-devel/gcc-11.2.0
merge time: 1 hour, 13 minutes and 57 seconds.Wed Mar 30 00:30:23 2022 >>> sys-devel/gcc-11.2.1_p20220115
merge time: 1 hour, 12 minutes and 8 seconds.
т.е. три языка + стандартные библиотеки собираются час.Надо бы отключить фортран, ну да и ладно. Перематываем обратно к расту. полтора часа собирать компилятордля пары ненужных свистоперделок - это большой перебор. Я бы вообще запретил обновлять раст, пока эти свистоперделки не требуют для сборки новой версии. В идеале отказаться от оного раста.
Не уточнили, собирается ли gcc с pgo (т.е. дважды). Если отключить Фортран, сэкономится минут 10.
> с pgo (т.е. дважды)Не дважды, а добавляется еще один этап сборки, которых при бутстрапе 3 (вроде).
3+1 раз пересобирается?На счет pgo. Но своем конфиге ядра ускоряет примерно 10-15%. Для меня показалось несущественным, поэтому отключил, так как время сборки gcc увеличивается почти в 2 раза.
>> с pgo (т.е. дважды)
> Не дважды, а добавляется еще один этап сборки, которых при бутстрапе 3
> (вроде).
> 3+1 раз пересобирается?Правильнее считать время на каждую стадию, т.к. именно оно и влияет. Т.е. мне следовало бы добавить "в первом приближении".
> На счет pgo. Но своем конфиге ядра ускоряет примерно 10-15%. Для меня
> показалось несущественным, поэтому отключил, так как время сборки gcc увеличивается почти
> в 2 раза.Ну вот и получилось на практике, что с pgo вдвое дольше собирается. Значит в №311 могло бы быть 40 минут или часа 2. Потому и интересно, с pgo ли там измерено время. Если rust собирается без pgo, корректнее сравнивать именно такой вариант.
А как получили эти 10-15%? Пересобирали весь мир, или на паре пакетов посмотрели qlop?
Не прошло еще 20 лет
Раст это пихают уже как собаке пятую ногу пришивают. Лучше бы Objective-C или D в ядро пихали - и то более вменяемые языки, да тот же C++ последних стандартов вполне нормальным стал
Скоро уже ядро перестанет собираться без подгрузки ржавых библиотек из сети прямо во время сборки?
> перестанет собираться безС системдой так же было. Сначала - нам только ускорить, потом - это только опция, получилось - прибито гвоздями намертво.
> Использование Rust для разработки драйверов позволит с минимальными усилиями создавать безопасные и более качественные бла-бла-блаСлил, нашел 108 файлов с расширением .rs, в 79-ти из них нашел конструкцию unsafe (местами более одной штуки).
Причём unsafe не гарантирует, что логическая ошибка из блока (условно) safe не ударит траблом в зависимый блок unsafe.
С++ вообще никаких гарантий не дает, т.к. RAII - паттерн, определяемый программистом, а не зашитая в семантику языка фича. Имхо, создать язык, в принципе не позволяющий написать некорректную программу, эквивалентно неразрешимости проблемы остановки.
В ядре линукс нет C++
Ога, есть С без, хотя бы, смартпоинтеров
> Ога, есть С без, хотя бы, смартпоинтеровЖирное, тормозное, малопредсказуемое ядро - немного не то что все хотят от операционки.
Всего лишь 79 мест, где надо искать ошибку.
Наивный, будто эти места абсолютно не связаны с другими.
Не та рыбка ловится, наверно слишком слишком тонкую леску взял для сети.
Не мест, а файлов, не по одной же на каждый.Собственно и не упрек вовсе, просто яростно напирать на слово "безопасность", но использовать явно небезопасные конструкции, - это как-то немного непоследовательно.
> 79-ти из них нашел конструкцию unsafeАга, и чо?
Чего только не придумают лишь бы Обероном не пользоваться...
У людей просто генетическая потребность какая-то жрать кактусы, колоться, плакать и продолжать жрать кактусы.
И через долгий долгий период потом, когда окажется что так можно было и не делать -- будут невинными удивлëнными глазами хлопать и говорить: "Ну мы же не знали! Нам никто не говорил".
Если бы меня кто-то попытался заставить писать на Обероне, я бы проявил чудеса фантазии, лишь бы этого избежать.
>Предложена начальная реализация модуля "net" с сетевыми функциямиЗначит уже можно в продакшн
> уже можно в продакшнна сервера гугла (который оплачивает банкет)
Кодинг на rust это зашквар и показатель профнепригодности. По своей убогости rust уже давно догнал java.
Настоящие программисты это только те, кто пишут на ANSI C и ASM, кодеры на скриптухе программистами считаться не могут по определению.
А программисты на SPARK?
> кодеры на скриптухе программистами считаться не могут по определению.Зарабатывать деньги им это не мешает
Не каждый зарабатывальщик денег - программист. С уважением, Ваш КЭП.
На Си не все возможно, есть оптимизированные структуры данных для которых придется писать генератор Си кода. Тогда как в языках с современными абстракциями такие структуры реализуются без использования сторонних средств и написания своих мини-ЯПов.
https://habr.com/ru/post/497114/#comment_21547936Кстати, сама статья выглядит провокационно.
> Кстати, сама статья выглядит провокационно.И правда:
"рукописный ассемблер оказывается быстрее ... на 2-5%, но и я не спец в ассемблере на этом уровне."
Разница в пределах погрешности измерений.
Я пару недель назад приводил результаты теста на Го и встроенном в Го ассемблере. В итоге -- победила векторизация встроенная в Го. В 4, Карл, грëбаных раза!! Ассемблер!!Второй вопрос: завтра код переедет на Армы и какую-нибудь экзотическую ось. Кто и когда р за чей счëт вам это будет оптимизировать?
>на Го
>коммунизмус не постирал штаны и начал писать на буржуазном языке от компанииЭто всё, что надо знать про коммунизмусов.
Rustless Fork уже кто-нибудь завёл? Как libre без блобов.
Зачем заводить форк если можно просто не пускать убогих в ядро?
Вопрос: почему растаманы форк не делают?
Потому что только части чуваков так свербит, что им не нужный удобный современный с повышенной безопасностью rust
Да вот, плили себе втихую, а потом так - ррраз! И прорубили окно в ... main.
Удивительно, на на Гнилом Западе почему-то Раст приветствуется весьма активно. В тредах по расто-ядру сплошные рукоплескания и телесные жидкости со стен оттирают. Ну, это если негатив тупо не трут и не банят :)
Потому что типичная тактика SJW - примазываться к тому, что уже сделано, а не делать своё.
Почему выбрали именно Rust, а не SPARK?
> Разработка финансируется компанией Google и организацией ISRGПродались, ой, ведут серьезный бизнес.
Растоманы настолько убогие, что за 10 лет не сумев запилить своё ядро, лезут своими грязными клешнями в божественное ядро линукса.
Растовцы настолько велики, что не стали тратить время на костыляние своего ядра с нуля, а пошли осветить светом Раста ядро Линукс!
> светом Растакоричневым потоком раста
коричневым потоком продуктов жизнедеятельности неадекватов с opennet
не ругайте растаманов, они пишут тут статьи, как могут...
> Разработка финансируется ... учредителем проекта Let's EncryptШта?!
Несколько опечаток в ZOG!!
Кто бы не расстраивался, но выходит это серьёзная проверка Rust на профпригодность. Проверка на использование в реальном проекте, заодно найдут и исправят недостатки в языке на установленных требованиях. Глядишь и язык станет лучше.
> Кто бы не расстраивался, но выходит это серьёзная проверка Rust на профпригодность.
> Проверка на использование в реальном проекте, заодно найдут и исправят недостатки
> в языке на установленных требованиях. Глядишь и язык станет лучше.Когда базовые фичи приматывают на проволоку - оно становится не "лучше" а "костыльнее".
> Когда базовые фичи приматывают на проволоку - оно становится не "лучше" а "костыльнее".Когда очередные базовые фантазии опеннетчиков притягиваются за уши - оно никак не меняется.
>Предложена начальная реализация модуля "net" с сетевыми функциями. Для кода на языке Rust предоставлен доступ к таким сетевым структурам ядра, как "Namespace" (на основе структуры ядра "struct net"), SkBuff (struct sk_buff), TcpListener, TcpStream (struct socket), Ipv4Addr (struct in_addr), SocketAddrV4 (struct sockaddr_in) и их эквивалентам для IPv6.То есть, про всё многообразие сокетов (и даже unix-сокетов) они не слышали.
