Мигель Охеда (Miguel Ojeda), автор проекта Rust-for-Linux, предложил для рассмотрения разработчиками ядра Linux пятый вариант компонентов для разработки драйверов устройств на языке Rust. Поддержка Rust рассматривается как экспериментальная, но уже включена в ветку linux-next и достаточно развита для начала работы по созданию слоёв абстракции над подсистемами ядра, а также для написания драйверов и модулей. Разработка финансируется компанией Google и организацией ISRG (Internet Security Research Group), которая является учредителем проекта Let's Encrypt и способствует продвижению HTTPS и развитию технологий для повышения защищённости интернета...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56691
теперь память будет течь как водопад еще в самОм ядре
A до этого не текло?
Теперь будет течь безопасТно!
Нет.
Тайд. Вы ещё кипятите? Тогда мы идем к вам.Раст. У вас еще не течёт? Тогда мы идем к вам.
Точно. У вас ещё не течёт крыша? Тогда мы идём к вам!
>A до этого не текло?А что, у вас течёт? У меня серваки часто с аптаймом 300-500 дней стоят и как часики работает всё.
Сборка мусора не может предотвратить утечку памяти. Не существует способа избежать всех возможных утечек памяти, если вы используете Тьюринг-полный язык программирования. Чтобы это понять нужно знать что такое утечка памяти.Старайтесь больше так не ошибаться, если вы программист.
> Сборка мусора не может предотвратить утечку памяти.А use-after-free раст может предотвратить? А buffer overflow? А UB? Нет? Да что ж такое.
Безопасное подмножество Rust может. Это сводит к минимуму место локализации ошибки и упрощает code review.
>Безопасное подмножество Rust может.Неюзабельно. Хелловорд в вакууме безопасен, но реальная жизнь выходит за рамки хелловордов. Это может шокировать растоманов, прости.
>Это сводит к минимуму место локализации ошибки и упрощает code review.
Это с чего вдруг? Я уже скидывал тут ссылку на уязвимость use-after-free. Там рядом unsafe, но уязвимость не в unsafe. В прошлом треде, видимо какая-то эйчарка вроде сквирти или автобусника увидела там ансейф и её триггернуло что уязвимость в этом. Но нет.
Второе: посмотри на список CVE что тут скинул. Сколько из них найдено в процессе ревью?
>Неюзабельно. Хелловорд в вакууме безопасен, но реальная жизнь выходит за рамки хелловордов. Это может шокировать растоманов, прости.Юзабельно это доказывают многие проекты написанные на Rust.
Движок firefox
Микро VM https://github.com/firecracker-microvm/firecracker
JS рантайм с полсотней контрибьюторов https://github.com/denoland/deno
автор Curl переписывает его на раст.
Prime Video написали приложение на раст для 8000 устройств 35000 строк скомпилировали в 150кб https://www.amazon.science/blog/how-prime-video-updates-its-...
Операционная система, которая уже работает на устройствах https://www.redox-os.org/screens/Заметь, это не библиотеки а реальные проекты. Те кто отбразывают Rust - отбрасывают будущее.
>Там рядом unsafe, но уязвимость не в unsafe.
Уязвимость в unsafe. Если бы небыло unsafe не было бы и use-after-free. Понятно что мир UB широк и многогранен и code-review даже маленького участка unsafe (по-сути Сишного кода) требует необходимых знаний. Но это все же лучше чем 100% unsafe коим являются программы написанные на С/С++
>Заметь, это не библиотеки а реальные проектыЭто не проекты, а петпрожекты, уязвимости в которых нашли по чистой случайности, потому что никто их не использует и никому не интересно в них искать уязвимости.
> Те кто отбразывают Rust - отбрасывают будущее.
Светлое будущее хоть? :-D
> Уязвимость в unsafe.
Да фиг с тобой, пусть ансейф. Приятно видеть как ты метаешься между "идеоматичным растом" и даже хелловордом, требующим ансейф.
Это не он метается, а ты продолжаешь клоунаду в очередной теме показываю свою некомпетентность - не понимаешь (или специально пишешь фигню) про возможности языка и их ограничения.
Поэтому тебе приходится в каждой теме срать про ту самую утечку памяти и перепутанный знак. Потому что остальные аргументы сдулись. Это даже не троллинг, а какое-то уныние.
Когда говорят про ржавь, говорят, что оно безопасТно. Ультимативно безопасТно, никаких "уточнений" про возможности этой "безопастности".
Ты опять сманяврировал, получается: типа ржавь безопасТна, но есть ньюансы. Так и получится, что на практике оно не безопасТнее сишечки, а при этом жирное и ненужное.
> Когда говорят про ржавь, говорят, что оно безопасТно. Ультимативно безопасТно, никаких
> "уточнений" про возможности этой "безопастности".Кто говорит? Голоса из розеток? Не слушай!
> Ты опять сманяврировал, получается: типа ржавь безопасТна, но есть ньюансы.
Ты решил опубликовать свои ответы в споре с голосами? Зачем?
> Движок firefox
> Компания Mozilla передала движок Servo организации Linux Foundationhttps://www.opennet.ru/opennews/art.shtml?num=54102
Ахаха, вот так образец - всем образцам образец!
Остальное - эталонное петпрожектное ненужно.
>> Движок firefox
>> Компания Mozilla передала движок Servo организации Linux Foundation
> https://www.opennet.ru/opennews/art.shtml?num=54102
> Ахаха, вот так образец - всем образцам образец!https://www.opennet.ru/opennews/art.shtml?num=45385
> Проект Mozilla представил Quantum, комбинированный браузерный движок для Firefox
> 28.10.2016 13:49Образец опеннетного ыкспертуса вульгариса.
>> Firecracker was developed at Amazon Web Services to improve the customer experience of services like AWS Lambda and AWS Fargate .
> Остальное - эталонное петпрожектное ненужно.Да, зато очень нужно Ценное Мнение опеннетных оналитегов ...
> Юзабельно это доказывают многие проекты написанные на Rust.
> Движок firefoxтак себе пример, если честно.
из плюсов - почесано чсв девелоперов и удлинилось их резюмэ.
из минусов - фокс похоронен на всех платформах, кроме x86-64 и aarch64, да и на этих жив только под виндой + линукс. на остальных - до тех пор, пока мейнтейнеры портов не затрахаются. на опенке вроде уже.
на стрекозе даже не начинали, путь уже заказан.
>фокс похоронен на всех платформах, кроме x86-64 и aarch64Это ***ита. https://download.mozilla.org/?product=firefox-nightly-latest...
https://ftp.mozilla.org/pub/fenix/nightly/2022/02/2022-02-12...
> Это ***ита.Твоё второе имя.
https://web.archive.org/web/20181020135654/https://packages....
Еще 4 года ушло на +1 архитектуру:
https://packages.gentoo.org/packages/www-client/firefox
Успешный успех.
> apk
это не лиса вообще. Ты не понимаешь о чём речь опять?
> Еще 4 года ушло на +1 архитектуру:минус одну.
вот растовский tier 1 от начала до конца, и в общем, gfl собирать фокс на чем-то другом.
aarch64-unknown-linux-gnu ARM64 Linux (kernel 4.2, glibc 2.17+) 1
i686-pc-windows-gnu 32-bit MinGW (Windows 7+)
i686-pc-windows-msvc 32-bit MSVC (Windows 7+)
i686-unknown-linux-gnu 32-bit Linux (kernel 2.6.32+, glibc 2.11+)
x86_64-apple-darwin 64-bit macOS (10.7+, Lion+)
x86_64-pc-windows-gnu 64-bit MinGW (Windows 7+)
x86_64-pc-windows-msvc 64-bit MSVC (Windows 7+)
x86_64-unknown-linux-gnu 64-bit Linux (kernel 2.6.32+, glibc 2.11+)
>вот растовский tier 1Ну, так да. В генту помечено testing, и такой список багрепортов что скорее experimental.
> автор Curl переписывает его на раст.неспроста без ссылки, ага?))) А вот ссылка:
https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/
Будет один из туевой хучи бэкендов для http/1{,2}. У растаманек же поллюция уже: переписывают на расте!!! Гип-гип, ура! :-D
Забавные вы люди.
> Не существует способа избежать всех возможных утечек памяти, если вы используете Тьюринг-полный язык программирования.
> Безопасное подмноество Rust может.Отсюда вывод: безопасное подмножество не Тьюринг-полное?
> Отсюда вывод: безопасное подмножество не Тьюринг-полное?"Отсюда" - нет, такой вывод формально вообще-то сделать нельзя.
Но если и да (в смылсе - оно не Тьюринг-полное) - и чо?
Практические реализации ЯП все равно не "полные" (лента ограничена) да и интересует нас лишь то маленькое подмоножество корректно работающих и решающих реальные задачи, а не все возможные варианты программ и их ввода и вывода.
Вы невнимательны. Комментатор спрашивал о
>А use-after-free раст может предотвратить? А buffer overflow? А UB?
> use-after-freeВ rust дается "слежением за владением" не бесплатно: из-за этого нельзя создать данные с циклическими ссылками, например, банальный двусвязный список.
> buffer overflow
От этого rust не может защитить на этапе компиляции. Для этого минимум нужны зависимые типы, и то этого недостаточно.
> UB
А вот это практически упирается теорему останова.
Каким боком тут "безопасное подмножество"? И как применит к этому "безопасному подмножеству" полноту по Тьюрингу, вообще непонятно.
>В rust дается "слежением за владением" не бесплатноВерно, но он все же Тьюринг-полный. Просто части некоторого кода выгоднее делать в unsafe.
Двусвязный список на безопасном Rust (неэффективен поскольку использует подсчет ссылок) https://gist.github.com/matey-jack/3e19b6370c6f7036a9119b79a...
Естественно при использовании unsafe будет и короче и красивее, и небезопасно при многопоточном использовании. Как в Си.
>> buffer overflow
>От этого rust не может защитить на этапе компиляции.Безопасное подмножетсво Rust от этого защищает путем проверки на стадии исполнения что индекс входит в границы. В оригинальном комментарии не спрашивалось о стадии на которой происходит проверка. (Это единственный скрытый оверхед Rust'a о котором надо узнавать отдельно, известно любому программисту на C++/ Как оверхед динамической диспетчеризации, или явных счетчиков ссылок, примитивов синхронизации)
>> UB
>А вот это практически упирается теорему останова.Справедливости ради никто и не ожидал от Rust решить теорему останова.
> Верно, но он все же Тьюринг-полный.Зачем ты приплел полноту по Тьюрингу? Поток сознания без понимания?
> Двусвязный список на безопасном Rust
> pub prev: Option<Weak<RefCell<Node<T>>>>,Ааааа! Как это развидеть!
> защищает путем проверки на стадии исполнения что индекс входит в границы
Недавно кто-то говорил, что в Rust нет рантайма.
Вы же сами написали
>Отсюда вывод: безопасное подмножество не Тьюринг-полное?Я просто отвечал на ваш комментарий.
> Я просто отвечал на ваш комментарий.Ты только сейчас влез в разговор, у тебя номер анонима другой. Зачем ты это сделал?
Аноним суть многие и Аноним есть одно, каждый аноним каждому - рознь, и вместе с этим одно
Шизоид, верни мне того Анонима, который лил поток сознания про полноту по Тьюрингу, а себя запрячь глубже в сознании.
Полнота по Тьюрингу - это проклятье. Одни проблемы от неё. Если бы мы всё могли вычислять конечными автоматами - было бы вообще отлично, автоматы очень просты структурно, о них можно доказывать теоремы, всяких неразрешимых проблем для них нету в таком количестве. Но увы, увы, не все задачи решаются конечным автоматом, что печально. И магазинным автоматом тоже не все задачи решаются. Вот так и живём (хотя если жёстко по терминам итти, компьютер не машина Тьюринга, а лишь жалкое её подобие, ибо конечная лента ака ОЗУ)
> Двусвязный список на безопасном Rust
> pub prev: Option<Weak<RefCell<Node<T>>>>Ах, да, насколько я знаю RefCell использует UnsafeCell, который который использует ключевое слово unsafe, который переводится "небезопасно".
Конечно использует. А потом использует lbic, потом ядро, потом уязвимые процессоры.
У Ada/SPARK точно такая же цепочка делегирования безопасности.
> Конечно использует.О, настоящий тот самый Аноним! Привет!
Если использует unsafe, почему нужен этот цирк из каскада? Почему сразу нельзя писать простую unsafe-структуру?
>> Конечно использует.
> О, настоящий тот самый Аноним! Привет!
> Если использует unsafe, почему нужен этот цирк из каскада? Почему сразу нельзя
> писать простую unsafe-структуру?Конечно можно, но это Ты ее напишешь, а не разработчики стандартной библиотеки. Для себя, возможно даже открывать не будешь. Твой unsafe код проверят пусть 10 человек, а код стандартной библиотеки проверят во много раз больше и проектов на ней больше.
> это Ты ее напишешьОпять двадцать пять. Где я заявлял, что напишу?
Это ты заявлял, что уже написан безопасный, ещё раз по слогам, без-о-пас-ный двусвязный список.
Он безопасен с той точки зрения, что не нарушает инвариантов безопасного подмножества Rust. Я думал мы это подразумеваем в дискуссии. Каждый раз так расписывать утомительно.
> инвариантов безопасного подмножества RustМожет, сперва надо написать эти "инварианты"?
> Я думал мы это подразумеваем в дискуссии
То (не)полнота по Тьюрингу, то неведомые "инварианты". Какие ещё тайные знания скрывает Rust?
Почему самописная unsafe-структура не соблюдает эти "инварианты", а входящая стандартную библиотеку unsafe-структура - соблюдает?
> https://gist.github.com/matey-jack
> Robert Jack Will
> matey-jack
> EcmaScript modules in the browser and outside – that simplifies a lot of things.Типичный растист
> Это сводит к минимуму место локализации ошибки и упрощает code review.Упомянутый use-after-free нашли с помощью asan, написанный сишниками-цэпэпэшниками. Ни "сведение к минимуму", ни "код ревью" не помогло.
> Упомянутый use-after-free нашли с помощью asanКакую конкретно уязвимость? Есть еще вот такая вещь https://github.com/rust-lang/miri#bugs-found-by-miri с ее помощью уязвимости стандартной библиотеки находят.
>, написанный сишниками-цэпэпэшниками.И что в этом плохого?
>> Сборка мусора не может предотвратить утечку памяти.
>А use-after-free раст может предотвратить?Может. Вот, как раз, за счёт утечки он это и делает.
Корчеватель, ты?Самое забавное, что нашлось достаточно людей плюсанувших этот бессмысленный набор умных слов.
--
Ну и предвосхищая идиотов, который щас начнут "а докажи":Brainfuck - тьюринг полный язык. Утечек памяти там нет и быть не может by-design.
> Корчеватель, ты?
> Самое забавное, что нашлось достаточно людей плюсанувших этот бессмысленный набор умных слов.Ну, тебя ведь тоже кто-то плюсуют (или опять "сам, все сам!"?).
> --
> Ну и предвосхищая идиотов, который щас начнут "а докажи":
> Brainfuck - тьюринг полный язык. Утечек памяти там нет и быть не может by-design.+[>+.]
А кто мой ответ удалил?Здесь нет никаких утечек памяти. И в принципе быть не может.
> А кто мой ответ удалил?
> Здесь нет никаких утечек памяти. И в принципе быть не может.У тебя, "художника" с кучей альтернативных видений и собственной терминологией - все может быть.
Будет все падать и сыпаться. Никто не украдёт данные с жёсткого диска, если он сгорит.
Новое железо само себя не купит
Может просто стоит внедрить статический анализ в разработку на си?
Естественно эти инструменты уже используются ядро чуть ли не всем IT-миром пилят. Но они не помогают в 100% случаев, о чем могут свидетельствовать многочисленные CVE-шки ядра по работе с памятью.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rustо чем могут свидетельствовать многочисленные CVE-шки по работе с памятью.
> GCC v12.0 was discovered to contain an uncontrolled recursion via the component libiberty/rust-demangle.c. This vulnerability allows attackers to cause a Denial of Service (DoS) by consuming excessive CPU and memory resources.
>> GCC v12.0 was discovered to contain an uncontrolled recursion via the component libiberty/rust-demangle.c. This vulnerability allows attackers to cause a Denial of Service (DoS) by consuming excessive CPU and memory resources.И чо? Не было бы деманглера, не было бы и уязвимости, а значит это Раст все виноват!
Сишники и цэпэпэшники не выпрыгивают из штанов, доказывая что у них серебряная пуля. Пишут компиляторы, улучшают анализаторы. Растаманьки самие пользуются результатом их трудов. Такова жизнь.
Про серебренную пулю ни кто не пишет. Кстати, многие из создателей языка Rust это компетентные крестовики.
> Про серебренную пулю ни кто не пишет.Просто массовая галлюцинация :-D. Всем кажется. А софт, с тенденциозным именем, вроде "ripgrep" не существует.
Как там кстати, рипгреп, поддерживает какие-нибудь регекспы акромя покоцаных растовых? Или "продолжаем хоронить grep since 2010"? :-)
А при чем тут Rust? ripgrep мог родиться и на другом языке. Его основная фишка ведь не в том что он на Rust'e написан, а в скорости работы https://blog.burntsushi.net/ripgrep/
ripgrep особенно силен в поиске unicode, при поиске внутри файла, или в очень больших директориях.Он используется для поиска в большом количестве данных, а не для всех задач которые могут потребоваться в shell. Например VSCode и Atom используют ripgrep для поиска в файлах проекта.
>Как там кстати, рипгреп, поддерживает какие-нибудь регекспы акромя покоцаных растовых?
https://docs.rs/regex/*/regex/#syntax
https://docs.rs/regex/*/regex/bytes/index.html#syntax
Может с тех пор как вы смотрели в регэкс добавили новые фичи, посмотрите еще тут https://github.com/rust-lang/regex/blob/master/CHANGELOG.md#...Вот еще changelog проекта. Там тоже может быть что-нибудь интересное https://github.com/BurntSushi/ripgrep/releases
Вы не рерайтер в основной профессии?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103841
>> Uncontrolled Recursion in libiberty/rust-demangle.c
> Сишники и цэпэпэшники не выпрыгивают из штанов, доказывая что у них серебрянаяКак ты ловко перевел тему с очередного своего обсера ...
>Cишники и цэпэпэшники не выпрыгивают из штанов, доказывая что у них серебряная пуля.Поэтому я делаю вывод что ты не сишник и не цэпэпэшник.
так кто же ты? балабол?
я возразил на это:> Но они не помогают в 100% случаев, о чем могут свидетельствовать многочисленные CVE-шки ядра по работе с памятью.
этим:
>https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
.
> так кто же ты? балабол?
ок, зумер :-D
Покажите, что вы написали на Си. Держите чего стоит настоящий си программист.Пока это вы выпрыгиваете из штанов, даже всю новость застали попытками доказать какой раст плохой.
> Покажите, что вы написали на Си. Держите чего стоит настоящий си программист.
> Пока это вы выпрыгиваете из штанов, даже всю новость застали попытками доказать
> какой раст плохой.А смысл?! Все равно вы убежите, скуля что я - не я, а если и я - то вообще, вы не ожидали что в беседе я такая школьница. :-D
Ты легко можешь подтвердить что репозиторий твой.
Само собой ты ничего не подтвердишь ведь ты не можешь написать ничего сложнее тупняка в комментариях
> Ты легко можешь подтвердить что репозиторий твой.
> Само собой ты ничего не подтвердишь ведь ты не можешь написать ничего
> сложнее тупняка в комментарияхПруф так пруф.
Это не пруф. Это называется обкакался и убежал в кусты.
Си недостаточно выразителен семантически. Например, там нет borrowing. В результате, статический анализатор не в курсе как код должен работать и не может сообщит об ошибке. В теории можно просто кастомно расширить Си, его компилятор и переписать всё ядро на новый Си. Но зачем, если работа уже проделана в Rust?
Так и расту эта выразительность не помогает. Сношаться с кодом только помогает, а уязвимости как были так и есть.
Уязвимости никуда не денутся, но благодаря подходу Rust их становится меньше. А при использовании идиоматичного Rust еще и без ущерба производительности. Например итераторы по коллекциям там где существует последовательное индексирование не приводят к проверкам убежавших индексов / Парсеры (типа Nom) в подходящие струкуры где требуется работа с индексами. Опять же чтобы не пришлось индексировать и для удобства работы.
> Уязвимости никуда не денутся, но благодаря подходу современного C++ их становится меньше.Когда дело касается голого маркетинга, а не фактов, то повернуть стрелочку можно не просто, а очень просто.
Но это замедляет программу даже в простейших случаях ( https://www.youtube.com/watch?t=1061&v=rHIkrotSwcc ) , а также делает ее менее читаемой, поскольку эти инструменты не встроены в язык а являются дополнением стандартной библиотеки.
Да, благодаря подходу современного C++ их действительно становится меньше. Rust же продолжает развитие этой плюсовой линии.
>Да, благодаря подходу современного C++ их действительно становится меньше.Это как посмотреть. Можно писать сравнительно сложную систему на C с классами (пример, Джон Кармак, движок старенького Doom 3) и допускать минимум ошибок.
Также можно в современном C++ наделать висячих r-value ссылок просто где-то услышав, что ими модно пользоваться, но не разобравшись до конца как они работают и когда это вообще нужно. Причём код будет компилироваться. Rust не защитит от дурака хотя бы тем, что в любой непонятной ситуации будет заюзан unsafe (даже если объективно не нужен!), а опытные и благоразумные разработчики и так знают где подстелить соломку, а от опечаток, семантических ошибок вообще не застрахован никто и нигде. И уж тем более никто не застрахован от неверного использования legacy-c кода (при этом код на Rust будет легитимным), а ведь сложные ошибки чаще всего и возникают на стыке чего-либо.
Ну например современный С++ не предотвращает data race на стадии компиляции. Или iterator invalidation.В С++ существуют такие вещи которые нужно знать, но они создают "искусственную" сложность https://stackoverflow.com/questions/146452/what-are-pod-type...
Растаманы с регекспами вместо языка и встроенным в компилятор линтере, говорят о "искусственной сложности"... это так мило.
Сидиоты, имеющие спецификацию Плюсов в полторы тысячи страниц, которую освоить на в состоянии ни один человек в мире, рассказывают, что Плюсы не имеют никаких сложностей. Это так мило.
> Сидиоты, имеющие спецификацию Плюсов в полторы тысячи страниц, которую освоить на в
> состоянии ни один человек в мире, рассказывают, что Плюсы не имеют
> никаких сложностей. Это так мило.О, да это ж ты в треде по перлу обдристался в таком же стиле. Ну вот как ты можешь говорить о сложности чего либо, если даже ман не осилил? Ты ж стэковерфлоу-википедия-варриор. Оттуда же и про перл узнал небось. Разумеется тебе сложно. Но такова селяви, бро, никто не утверждал что цэпэпэ не имеет никаких сложностей. Сложный цэпэпэ, очень сложный. Такая у него специфика, такова его область применения. Ваш удел -- не цэпэпэ, а растомакакинг и скриптинг, как когда-то были у печатных машинок наборщики текстов, так у нынешних однотипных задачек -- вы, копипастеры.
> Уязвимости никуда не денутся, но благодаря подходу Rust их становится меньшеБлагодаря которому из? Захламлению синтаксиса спецсимволами, превращающему программу в некое подобие нечитабельных регэкспов? Или в статическую компиляцию, требующую пересборки всех проектов после фиксов дыр в функциях работы с файлами? Или в регулярные диприкейтед, которые делают предыдущий пункт невыполнимым?
А, вы о borrow checking? Ну так этого мало. К этому еще и язык должен быть поддерживаемым, а не вот это вот аджайловое лоскутное одеяло.
>Захламлению синтаксиса спецсимволами, превращающему программу в некое подобие нечитабельных регэкспов?Такова доля любого системного языка претендующего на усиленную безопасность. Либо широкий и пространный код (как в SPARK), либо плохо читаемый (Без обучения языку. Я лично читаю его довольно легко, это приходит с опытом)
Синтаксис лайфтаймов, например, взят из Haskell, который славится своей немногословностью. Дженерики из Java. Остальное из С/С++. Какая часть синтаксиса вам не нравится, что бы вы изменили?
Единственная проблема с чтением кода в Rust которую можно поставить в сильный упрек экосистеме. Это отсутствие распаковки процедурных макросов во всех IDE (все обещают, но никак не реализуют). Что может усложнить разработку если у вас код весь из них состоит.
>Или в статическую компиляцию, требующую пересборки всех проектов после фиксов дыр в функциях работы с файлами?
Не всех проектов, а только тех что использовали уязвимую функцию std::fs::remove_dir_all.
Ситуация с динамической линковкой непростая, один из серьезных недостатков. Пока не стандартизируют ABI об отделении стандартной библиотеки и размещении ее где-нибудь в системе можно забыть.
К счастью в сообществе Rust стал стандартом модуль системы сборки cargo-audit, который позволяет при сборке проекта проверить все его зависимости на наличие уязвимостей.
>Или в регулярные диприкейтед, которые делают предыдущий пункт невыполнимым?
Rust использует понятие Редакции (которые выходят раз в 3 года) для внесения в язык или стандартную библиотеку ломающих изменений, поэтому они не такие уж и регулярные как вы упомянули. В любом случае эта претензия также относится к отсутствию должным образом реализованной динамической линковки (Что в будущем изменится)
>К этому еще и язык должен быть поддерживаемым,
Он и поддерживается https://www.rust-lang.org/sponsors Помимо спонсоров есть также активное коммьюнити что подтверждается его популярностью на SO. Для него пишут библиотеки, хоть и не так активно как для top10 языков http://www.modulecounts.com/
>>Или в регулярные диприкейтед, которые делают предыдущий пункт невыполнимым?
> Rust использует понятие Редакции (которые выходят раз в 3 года) для внесенияДа забей. Его в это ужа раз 5 носом тыкали - бесполезно, в каждой новости опять нытье о "все время ломают совместимость!".
Старческий маразм, не иначе.
> Такова доля любого системного языка претендующего на усиленную безопасность.Глупости.
С# - безопасный и достаточно системный язык (на нем тоже ОСь написана, - singularity, - не менее безопасная чем почти почивший redox).
> Либо широкий и пространный код (как в SPARK), либо плохо читаемый (Без обучения
> языку.Еще раз - глупости.
> Я лично читаю его довольно легко, это приходит с опытом)А я регэкспы читаю легко (ну не так чтобы вот совсем-совсем, но легче всех кого знаю).
Но это не причина все превращать в регэкспы и тем более не причина утверждать что так и надо.
> Синтаксис лайфтаймов, например, взят из Haskell, который славится своей немногословностью.
> Дженерики из Java. Остальное из С/С++. Какая часть синтаксиса вам не
> нравится, что бы вы изменили?Все. Я бы все выкинул на помойку и сделал С++++ или C## с борроу-чекером. Без встроенного пакетного менеджера, линтера и всего остального не относящегося к понятию "язык программирования" барахла.
> Единственная проблема с чтением кода в Rust которую можно поставить в сильный
> упрек экосистеме. Это отсутствие распаковки процедурных макросов во всех IDE...Это упрек не экосистеме, а базовым библиотекам языка. И функции языка и макросы не должны требовать анализа "что же там внутри". Мы же не ходим исследовать printf, не так ли?
>>Или в статическую компиляцию, требующую пересборки всех проектов после фиксов дыр в функциях работы с файлами?
> Не всех проектов, а только тех что использовали уязвимую функцию std::fs::remove_dir_all.Вы утверждаете, что это единственная проблема и никогда не возникнет нечто подобное в используемых именно вашим большим проектом функциях?
Возникнет. Обязательно возникнет. На это можно ящик виски ставить.
И чем позже возникнет, тем дороже будет.
> Rust использует понятие Редакции (которые выходят раз в 3 года) для внесения
> в язык или стандартную библиотеку ломающих измененийНапомните пожалуйста когда возникло это понятие. Не полгода назад, случайно?
Кто мне гарантирует что за последующие 5-7 лет, на которые я рассчитываю поддержку своей поделки, в языке в очередной тысячный раз не поменяется концепция? Вот до сих пор было как обычно, тут мы одну заплатку, тут новые костыли, тут это выкинули и тут добавили - а тут внезапно все изменится к лучшему? Ха-ха три раза, только дурачки на такое поведутся.
>>К этому еще и язык должен быть поддерживаемым,
> Он и поддерживается https://www.rust-lang.org/sponsorsЭти 4 конторы и есть причина того, что раст еще не загнулся. Гугл, Майкрософт и Амазон все еще надеятся, что смогут с помощью раста исключить из кода необучаемых индусских обезьян ошибки с памятью.
Местные пропагандисты раста, за редкими исключениями, именно такие обезьянки - не имеющие никакого понятия о процессах в программировании, о цене поддержки, даже о базовых принципах построения программных комплексов.
> Помимо спонсоров есть также активное коммьюнитиУгу, помним. То активное коммьюнити, которое успешно разоcpалось с кортимом, имевшим это активное коммьюнити в одном известном месте.
> что подтверждается его популярностью на SO.Пххх. "А как мне вывести хелловорлд на печать, такой глупо-сложный язык что никак не могу понять".
Успех (с)
> Для него пишут библиотеки, хоть и не так активно как для top10 языковА толку, если технический долг активно делает все эти библиотеки мертвым грузом?
>> Rust использует понятие Редакции (которые выходят раз в 3 года) для внесения
>> в язык или стандартную библиотеку ломающих изменений
> Напомните пожалуйста когда возникло это понятие. Не полгода назад, случайно?И в это тебя уже тыкали.
https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
> July 27, 2018
> This year, we will deliver Rust 2018, marking the first major new edition of Rust since 1.0 (aka Rust 2015).
Растишечки принципиально необучаемы, правда?
https://github.com/rust-lang/rust/blob/master/RELEASES.md
>>> Напомните пожалуйста когда возникло это понятие. Не полгода назад, случайно?
>> July 27, 2018
>> This year, we will deliver Rust 2018, marking the first major new edition of Rust since 1.0 (aka Rust 2015).
> Растишечки принципиально необучаемы, правда?
> https://github.com/rust-lang/rust/blob/master/RELEASES.mdЭто такой унылый спрыг или ты опять методички попутал?
Читать не умеем?
> Растишечки принципиально необучаемы, правда?
> https://github.com/rust-lang/rust/blob/master/RELEASES.mdРжака. Причем, у них там "рак-сплошняк", а не только в том, что на новоязе зовут Compatibility Notes. Вот например, что у них в новоязе называется рефакторингом:
The implementations of vendor intrinsics in core::arch have been significantly refactored. The main user-visible changes are a 50% reduction in the size of libcore.rlib and stricter validation of constant operands passed to intrinsics. The latter is technically a breaking change, but allows Rust to more closely match the C vendor intrinsics API.
Раздел Libraries. Тобишь, техниииически это конечно ломающее изменение. Но... who cares? Кто пишет серьёзно на расте, кмон :-D
Именно так. Да.
>С# - безопасный и достаточно системный язык (на нем тоже ОСь написана, - singularity, - не менее безопасная чем почти почивший redox).И Java безопасна и при грамотном использовании выдает быстрый код, и на ней ОС написана, но ее не примут в ядро Linux по тем же причинам что и C#.
>> Либо широкий и пространный код (как в SPARK), либо плохо читаемый (Без обучения языку.
>Еще раз - глупости.Что конкретно глупости? SPARK сорсы выдают кода в 1,5 раза больше на смысловую единицу - это общеизвестный факт. За все приходится платить.
Если вы считаете что можно выдать изящный код тогда давайте контрпример. Покажите системный язык со статической типизацией, без форсированного сборщика мусора (чтобы показать его системность - скорость исполнения), с подобием трейтов (интерфейсы), возможностью написания обобщенного кода и похожими гарантиями безопасности. Мне лично кроме Ada ничего на ум не приходит.
В любом случае можно обойтись без интерфейсов и дженериков. Код будет выглядеть как на Си или Go. И будет таким же безопасным как написанный на Ada.
>Но это не причина все превращать в регэкспы и тем более не причина утверждать что так и надо.
Вы так и не показали что конкретно вы бы переделали, если бы хотели сделать Rust красивей. Дело в том что при проектировании каждую закорючку в языке обсуждали с боем на Github. Там велись дискуссии размером с маленькие справочники. Я склонен считать что они нашли золотую середину для программистов на Си/С++.
>Все. Я бы все выкинул на помойку и сделал С++++ или C## с борроу-чекером.
Вам бы пришлось вводить явные лайфтаймы. Куда запихаете? Как они будут выглядеть?
>Пххх. "А как мне вывести хелловорлд на печать, такой глупо-сложный язык что никак не могу понять". Успех (с)
Все мы похожее спрашивали. И уже тогда нас считали частью коммьюнити. Сейчас они спрашивают, потом внесут вклад.
>А толку, если технический долг активно делает все эти библиотеки мертвым грузом?
Так можно про любой язык написать. Редакции с новыми возможностями выходят и в крестах. В крайнем случае, если автор потерялся (что уже само по себе плохо для любой библиотеки) можно будет форкнуть проект и поправить там несколько строк для перехода на новую редакцию. Если не собираешься переписывать с новыми фичами. Не было пока таких изменений в Rust, которые бы потребовали серьезного глобального рефакторинга для получения совместимости с новой редакцией.
К тому же существует специльный гайд и утилита cargo --fix https://doc.rust-lang.org/edition-guide/rust-2021/prelude.ht...
Есть примеры более-менее крупных проектов которые используют Rust:
rust-lang 1.78 млн. LOC, redox 1.33 млн., diem 300 тыс., tikv 300 тыс., Veloren 200 тыс. (данные годичной давности)
Можно надеяться что чем больше будет таких проектов, тем проще будет поддержка в будущем.
>loc: Count lines of code quickly.Ох лол.
> Захламлению синтаксиса спецсимволами, превращающему программу в некое подобие нечитабельных регэкспов?Если мозги есть и немного опыта набраться, то выясняется, что синтаксис там не создаёт никаких проблем. Умение читать конкретный синтаксис — это тупо дело привычки. А вот реальные особенности языка кроются за семантикой, а не синтаксисом.
Чувствую себя даже немного неловко, когда приходится писать столь базовые вещи.
> Умение читать конкретный синтаксис — это тупо дело привычки.Само собой. Я вот брейнфак неплохо читаю. И хаскель. И даже регэкспы.
> Чувствую себя даже немного неловко, когда приходится писать столь базовые вещи.
Чувствуешь себя неловко из-за того, что настолько идиот? Ведь только полный идиот может предположить, что его оппонент может быть настолько глуп, что может не понимать настолько базовые вещи ("Умение читать конкретный синтаксис — это тупо дело привычки").
Ну поздравляю, ты еще не совсем безнадежен.
Можешь еще подумать вот о чем: язык программирования должен быть интуитивно легко читаем и понимаем. Поэтому и появились высокоуровневые языки программирования. Поэтому машинный код пишут на ассемблере (состоящем из мнемослов), а не прямо цифирьками.
Хотя лично я, например, на заре своей карьеры именно цифирьками и писал. И даже помнил огромное количество команд прямо байтиками (благо их не так много тогда было).Вот с этой позиции и была написана фраза "Захламлению синтаксиса спецсимволами, превращающему программу в некое подобие нечитабельных регэкспов".
> Так и расту эта выразительность не помогает.В смысле? Те гарантии, что хотели обеспечить — обеспечили. Что значит «не помогает»?
> Сношаться с кодом только помогает,
Что конкретно это значит?
> а уязвимости как были так и есть.
А кто говорил, что уязвимости уйдут в абсолютный ноль?
> В теории можно просто кастомно расширить Си, его компилятор и переписать всё ядро на новый Си. Но зачем, если работа уже проделана в Rust?Чтобы иметь все плюшки Си(++)? Чтобы не пришлось годами впиливать его в линукс и в гигантское количество другого софта? Чтобы не дублировать оптимизации по 100500 раз? Чтобы не плодить лишние сущности, не заставлять разработчиков выяснять различия и не раздроблять сообщество?
Но конечно си контролировать было бы сложнее, это не раст, который можно выкупить у мозиллы. Хайп было бы сложнее поднять ("очередные изменения в си" вместо "новый выдающийся язык программирования"). А зарплата "редкого специалиста" будет побольше чем "пишу на современной версии" ("Ты еще и денег за это хочешь?!").
Уже обсуждали и не раз, что просто расширить Си не получится, его придется переделывать. А тогда это будет уже и не Си.
> Уже обсуждали и не раз, что просто расширить Си не получится, его
> придется переделывать. А тогда это будет уже и не Си.И где же это уже обсудили? И в чем проблема нарушить совместимость?
В c++11, в python3, в raku, в lua это не было проблемой и никто не создавал новый язык ради переписывания стандартной либы и добавления статического анализатора в компилятор.
>И в чем проблема нарушить совместимость?Ну ты можешь считать что раст это си, просто без обартной совместимости и с другим названием.
Синтаксис другой.
Да постоянно обсуждается этот вопрос. Из недовнего, например здесь: https://www.opennet.ru/openforum/vsluhforumID3/126618.html#47
Вот именно, llvm лавочку потом тихо прикрыть
> Чтобы иметь все плюшки Си(++)?Если речь про Си (который используется в ядре), то они и в Rust есть.
> Чтобы не пришлось годами впиливать его в линукс и в гигантское количество другого софта?
Вы как-то пропустили ту часть, где я сказал «переписать всё ядро».
> Чтобы не дублировать оптимизации по 100500 раз?
Например?
> Чтобы не плодить лишние сущности, не заставлять разработчиков выяснять различия и не раздроблять сообщество?
В таком Си next gen это придётся делать так или иначе. Более того, это как раз будет лишней сущностью, ибо уже есть Rust.
> Но конечно си контролировать было бы сложнее, это не раст, который можно выкупить у мозиллы. Хайп было бы сложнее поднять ("очередные изменения в си" вместо "новый выдающийся язык программирования"). А зарплата "редкого специалиста" будет побольше чем "пишу на современной версии" ("Ты еще и денег за это хочешь?!").
Теории заговора — это на zagovor.ru
Есть такие штуки:
В полной мере это будет невозможно сделать никогда. В ядре слишком много г̶о̶в̶н̶о̶к̶о̶д̶а̶ оригинальных решений и оптимизаций, от которых даже cppcheck начинает сходить с ума. Только для отдельных модулей и то в ограниченном виде. Это как с чьим-то предложение внедрить MISRA C в ядро. Трижды ха)))
> MISRA C в ядроА что на MISRA сказали? Интересно даден
Примерно тоже самое.
Текущий код перевести слишком трудозатратно - это по сути переписать (не с нуля конечно, но это мало помогает) гигатонны кода, протестить его на всех платформах (в том числе уже подохших), найти и исправить ошибки. Плюс еще и заставить так писать всех сторонних кто коммитит в ядро (вдрайвера напр.) Это просто нереально ни по времени, ни по финансам. Намного дешевле раз в неделю исправлять CVE.
> внедрить статический анализ в разработку на сиЕсли внедрить статический анализ в разработку на си это будет раст
И близко нет. Сохранится совместимость и опыт разработчиков.
>Может просто стоит внедрить статический анализ в разработку на си?Ну и, наверное, MISRA тоже стоит.
Кстати в Rust аффинные типы, которые в некотором роде позволяют избежать утечек памяти. Выходя за пределы скоупа объект будет уделен.
> в некотором родеХах) Типа позволяют избежать, но это не точно? :) ресдох подтвердит.
Насчет "скоупа": поосторожней с этим,
https://github.com/jeromefroe/lru-rs/issues/120
Нет, просто некоторые из них позволяет. Но не все. Также как языки со сборкой мусора. Но не больше них.
>Нет, просто некоторые из них позволяет. Но не все.И провоцируют другие уязвимости.
>Также как языки со сборкой мусора. Но не больше них.
На языках с gc удобно писать, в отличие от. Там не ты выполняешь роль gc, как в расте. Потому что занимаясь этой ненужной работой, ты попутаешь лайфтаймы и допустишь use-after-free.
>И провоцируют другие уязвимости.Не провоцирует другие уязвимости. Приведите пример.
>Потому что занимаясь этой ненужной работой, ты попутаешь лайфтаймы и допустишь use-after-free.
Это не правда. Ты не можешь попутать lifetime в Rust. У тебя программа не скомпилируется.
Вся соль в том, что тебе ПРИДЕТСЯ думать о лайфтаймах в таких языках программирования как C/C++. Если ты хороший программист, и не хочешь ошибки по памяти. А тут тебе их НАДО указывать.
https://github.com/jeromefroe/lru-rs/issues/120
Коммит с фиксом вы так и не посмотрели, он относится к небрежной проверке unsafe кода.
https://github.com/jeromefroe/lru-rs/pull/121/commits/416a2d...Про аффинные типы вы так и не ответили. Они не провоцируют появление других ошибок, приведите пример.
А, так это ты с ансейфом бегаешь еще с прошлых тредов? Предупреждать надо.> Про аффинные типы вы так и не ответили.
Ответил. Просто ты как обычно в глоза долбешсо. :-D
Да и кстати, аффиные типы ток в расте есть?
> А, так это ты с ансейфом бегаешь еще с прошлых тредов? Предупреждать надо.Нет, это тебя уже несколько человек носом ткнуло - но ты, как истинный Экспертус Опеннета продолжаешь с умным видом нести пургу.
- Раст полностью заменяет С, он не допускает ошибок работы с памятью!
- Ну вот же, допускает.
- Это ансейф!!11
- Так сделайте без ансейфа, чтобы не было ошибок с памятью.
- Эммм, мммм, ммммм.
Проект где требуется скорость будет в проценте строк кода писать unsafe, проект где требуется безопасность сможет обойтись без unsafe. Это ваш выбор.
И все эти проекты никак не смогут обойтись без регэкспоподобного говносинтаксиса и встроенных прямо в компилятор говнотулзеней.> Это ваш выбор.
Мой выбор там, где требуется скорость, использовать С или С++. А там, где требуется безопасность, использовать джаву/шарп/с++.
Причем на всех этих языках мой код десятилетней давности будет собираться современным компилятором. И даже при этом работать. И даже при этом оставаться читабельным и поддерживаемым.
Так что мой выбор - не использовать гoвнoязык. С чем себя я и поздравляю.
>И все эти проекты никак не смогут обойтись без регэкспоподобного говносинтаксисаТебя уже дважды спросили, что бы ты поменял в синтаксисе Раста. Ты так и не ответил. В глазки долбишься? Или сказать нечего, но надо что-то пyкнуть в очередной раз?
>встроенных прямо в компилятор говнотулзеней.
Прямо в компилятор ничего не встроено. Тебе, сидиоту, уже несколько раз об этом говорили.
А вообще, какие у тебя проблемы с этими тулзами возникли?
> И даже при этом работать. И даже при этом оставаться читабельным и поддерживаемым.Через пень-колоду с сегфолтами и и труднонаходимыми багами в связи с UB?
Засунь свои программы куда подальше с такими "фичами".
Ты тупой, да?Я ответил, причем отвечал раз 15 уже за полтора года растофанатизма на опеннете - выкинул бы все на помойку и сделал С с борроу чекером. Это если(!) бы я делал новый раст.
А так я считаю, что он банально не нужен.> Через пень-колоду с сегфолтами и и труднонаходимыми багами в связи с UB?
Через пень-колоду с сегфолтами и и труднонаходимыми багами в связи с unsafe?
Муа-ха-ха-ха.
В данном примере имеется структура Iter<'a, ..> для которой задан лайфтайм. То есть, это ссылочная структура. Но среди ее полей нет растовых ссылок, а есть сырые указатели. Это значит, во-первых, что компилятор не будет отслеживать лайфтаймы автоматически для этих полей (сырые указатели не имеют лайфтаймов), а во-вторых, использование данных полей возможно только через unsafe (разыменование сырого указателя - это небезопасная операция в Rust).Говоря проще, указатель можно представить как ссылку, но это такая ссылка, время жизни которой компилятор знать не может. Поэтому при реализации безопасного интерфейса для ссылочного типа с лайфтаймами, которые "под капотом" используют сырые указатели, обеспечение корректности их работы ложится на программиста. Это обычная практика работы с unsafe в Rust и это то место, где вероятность допустить ошибку высока.
> Вся соль в том, что тебе ПРИДЕТСЯ думать о лайфтаймах в таких языках программирования как C/C++.Вся соль в том, что я буду брать лучшие, оттестированные на всех хардварных/софтверных платформах любы на с/с++, и буду думать над задачей в предметной области, а не мотаться по вашим крейтам и перебирать хелловорды или изоьретать велосипед с нуля. А безопасность оплатит бизнес, да еще даст заработать хакерам на баунти, да обмажемся всевозможными линтерамм и чекерами, и тд и тп. Если нужно. Если не нужно -- так я и не заплатил за это страданиями на расте.
>а не мотаться по вашим крейтамRust это не только крейты.
" В дополнение сборщику проекта (cargo build) и линтеру (cargo clippy), вы получаете Искаропки Работает™ систему документации API (cargo doc), форматировщик кода (cargo fmt) с выработанными сообществом предустановками стиля, и замечательно интегрированным стандартным фреймворком для автоматического тестирования (Аннотация #[test] чтобы указать что функция является юнит-тестом, папка "tests" для интеграционных тестов, любые кусочки кода в вашей документации будут, по-умолчанию, запущены как тесты документации, для проверки их корректности на текущей кодовой базе и для уменьшения количества тестов, которые вам требуется написать) "
>А безопасность оплатит бизнес,
На этом дискуссию можно и закрывать.
>Если не нужно -- так я и не заплатил за это страданиями на расте.
Поскольку Rust (со стандартными библиотеками и крейтами) является скорее заменой C++ а не Си, я с уверенностью заявляю что он проще в освоении чем С++, проще в использовании, и гораздо безопаснее.
>Rust это не только крейты.Так в крейтах нифига нет. Это ж хелловорды недотестированные с кучей уядвимостей. Не только крейты, лол. :-D
> " В дополнение сборщику проекта (cargo build) и линтеру (cargo clippy),
Исусья тряпка! Привязанный к одному маргинальному языку сборщик и линтер хелловордов. Выкидываю cmake/makefiles. Джайте джва!
> cargo doc
Исусья тряпка, привязанный к одному маргинальному языку аналог doxygen.
> форматировщик кода (cargo fmt)
И если дядя решил ставить фигурную скобку на строке с блоком -- ты тоже привыкнешь. :-D
> Аннотация #[test]
Видели. Смешивание тестов и кода. Прекрасно, ящетаю.
> На этом дискуссию можно и закрывать.
Ой всё?!)) Растаман, возможно для тебя будет открытием, но за всё надо платить.
> я с уверенностью заявляю
бульк :-D
Поставляемый в комплекте не значит хуже чем сторонний. Хоть и сторонние инструменты в Rust подключить сложности не возникнет.Для многих программистов учить все эти возможные системы сборки, системы документации, тестирования может быть неприятно. Ведь поставщик компилятора не предусмотрел единой экосистемы. А тут как раз изкоробки есть. Наличие таких систем приводит к единообразию инфраструктуры, ускоряет развитие экосистемы, и помогает бизнесу - им не придется обучать новичка тому, что не относится непосредственно к написанию кода.
Претензию тут можно сделать к отсутствию нужных фич. Это гораздо более прагматичный подход.
>Видели. Смешивание тестов и кода. Прекрасно, ящетаю.
В моем комменте же указана возможность создания интеграционных тестов. Будьте внимательней.
>Поставляемый в комплекте не значит хуже чем стороннийНо оказывается хуже. Как функционально, так и тем что прибит гвоздями к одному маргинальному языку.
> Для многих программистов учить все эти возможные системы сборки, системы документации, тестирования может быть неприятно.
Да учиться вообще неприятно. Больно. Да и зачем, когда можно не учиться. Или вы предлагаете что-то одно якобы, и потом учиться не придется? Дык та же джава показала что это ложь. Растаманы перепишут потом всё, и опять учить придётся недоделанное, недоработанное, кое-как работающее.
> В моем комменте же указана возможность создания интеграционных тестов.
Что это меняет? Будьте внимательнее.
>Но оказывается хуже. Как функционально, так и тем что прибит гвоздями к одному маргинальному языку.В Rust функционально-полная система сборки. Помимо множества встроенных и общепринятых подсистем https://doc.rust-lang.org/cargo/ Существуют build-скрипты написанные на самом Rust, вызываемые сборщиком. Что гораздо лучше чем учить непонятный новый язык, не относящийся никак к программированию а только лишь сборке.
К тому же к системе сборки можно подключать самописные модули, что с успехом применяется. Они устанавливаются в системе одной командной. Вот неполный список https://old.reddit.com/r/rust/comments/mifrjj/what_extra_dev.../
Также чтобы указать на функциональные недостатки системы сборки или других частей стандартной экосистемы, было бы неплохо их перечислить. И если они разумны (хоть как-то распространены в других системах), то будут обязательно включены в проект.
>Да учиться вообще неприятно. Больно.
Зачем учить больше, если можно меньше и получить тот же результат. А плюсом еще и ускорить разработку - поскольку каждый программист на Rust в той или иной степени знаком с экосистемой. Не тратится время на переобучение новичков.
>Что это меняет? Будьте внимательнее.
Ниже ответил. Сразу не понял в чем ваша претензия состоит.
Маркетинговый буллщит. Спасибо, но переписываться с копипастой из брошюрок -- ту мач. Полнимаю лапки вверх. Ты снова меня одолел.
>Маркетинговый буллщитЭто прямая экономия денег заказчика. Которые ты, как и всякий подобный тебе "конструктор из говнa и палок" считать не умеешь - "бизнес оплатит", ага.
>>Маркетинговый буллщит
> Это прямая экономия денег заказчика. Которые ты, как и всякий подобный тебе
> "конструктор из говнa и палок" считать не умеешь - "бизнес оплатит",
> ага.Вот и сэкономили: мозилла отправила растаманек на мороз. Бизнес оплатил. :-D
>Видели. Смешивание тестов и кода. Прекрасно, ящетаю.Это не совсем так. Unit-тесты пишутся в конце файла и находятся в отдельном модуле tests. Код программы не может получить к ним доступ. (Только если убрать аннотации, и сделать функцию pub'личной)
https://play.rust-lang.org/?version=stable&mode=debug&editio...
>А безопасность оплатит бизнес,Возможно бизнес выберет не переплачивать за безопасность, а получить разработчика на Rust если в проект входит требование повышенной безопасности. Мне лично кажется это единственная надежда этого языка, там где SPARK это оверкилл и нужно "что-то похожее на кресты" чтобы в крайнем случае крестовика за месяц переучить (они схватывают концепции за месяц максимум, потому что Rust под них написан в основном)
> получить разработчика на Rust если в проект входит требование повышенной безопасностиИ через полгода получит неподдерживаемый кусок непонятно чего с кучей ансейфов и собирающийся только версией компилятора х.у, которой уже нигде нет и собрать которую тоже невозможно, ибо для этого нужна версия компилятора а.б, которой уже нигде нет и собрать которую тоже невозможно, ибо для этого нужна версия компилятора ...
>> получить разработчика на Rust если в проект входит требование повышенной безопасности
> И через полгода получит неподдерживаемый кусок непонятно чего с кучей ансейфов и
> собирающийся только версией компилятора х.у, которой уже нигде нет и собрать
> которую тоже невозможно, ибо для этого нужна версия компилятора а.б, которой
> уже нигде нет и собрать которую тоже невозможно, ибо для этого
> нужна версия компилятора ...ого, я удивлен что мой коммент удалили. Там ведь ясно видно, что человек не понимает как работает этот их бизнис (с). Ставлю на фрактала, он еще на лоре любил это делать, пока не погнали оттуда ссаными тряпками :-D
И мои некоторые тоже.Забавно, неужели у людей так сильно подгорает от правды, что они начинают крысятничать - лишь бы не развиваться?
> И мои некоторые тоже.
> Забавно, неужели у людей так сильно подгорает от правды, что они начинают
> крысятничать - лишь бы не развиваться?Читать растотреды без удаленных, что пить не закусывая.
+
Уж конечно куда лучше получить такой же не поддерживаемый кусок непонятно чего с сегфолтами и UB на плюсах, которые никто не знает досконально, поэтому тащит в код то, что удалось освоить за последние десять лет безвозвратно потерянной жизни, потраченной на изучение этих самых Плюсов.
И эти люди что-то рассказывают об эффективности программирования.
> Уж конечно куда лучше получить такой же не поддерживаемый кусок непонятно чего
> с сегфолтами и UB на плюсах, которые никто не знает досконально,Ты раст что ли знаешь досконально, растамань?)))
> поэтому тащит в код то, что удалось освоить за последние десять
> лет безвозвратно потерянной жизни, потраченной на изучение этих самых Плюсов.Растамань, без плюсов нет вашего раста. Не гадь там где ешь.
> И эти люди что-то рассказывают об эффективности программирования.
кто-то же должен.
Не, ну то что вы на любом языке напишете неподдерживаемый кусок непонятно чего я даже не сомневаюсь.Но вот в реальном мире вокруг нас на нормальных языках написано огромное количество поддерживаемого софта. Настолько поддерживаемого, что код можно не трогать десятилетиями, просто пересобирая его новыми компиляторами. Настолько поддерживаемого, что когда через 10 лет находят вдруг ошибку (а ошибки есть и будут везде, даже в вашей мифической серебряной пуле), то она легко и просто исправляется (а не так как в вашей мифической серебряной пуле).
> И эти люди что-то рассказывают об эффективности программирования.
Именно. Эти люди планируют, выставляют счета, вовремя делают и качественно поддерживают сделанную работу. Они знают о чем говорят.
> удалось освоить за последние десять лет безвозвратно потерянной жизни, потраченной на изучение этих самых Плюсов.
Я уже несколько раз вижу аргумент "С++ настолько сложен, что его невозможно изучить" и в очередной раз делаю вывод: растофанатики банальные безмозглые обезьяны. Если человек не может выучить С++ в необходимом для полноценной работы объеме, что является довольно простой задачей, то ему не место в профессии. Ему место в кочегарке, например. И никакие рекламирующие себя как волшебную палочку расты ему не помогут.
> Вся соль в том, что тебе ПРИДЕТСЯ думать о лайфтаймах в таких
> языках программирования как C/C++.Сколько вы еще С++99 будете вспоминать? Уже 23 года прошло. В современных плюсах есть RAII.
Даже такое простое и базовое RAII как unique_ptr не позволяет избежать оверхеда в рантайме. https://www.youtube.com/watch?t=1061&v=rHIkrotSwcc
Не говоря уже о том, что грамотное применение этой "нашлепки" на язык делает код длиннее и запутанней.
В ролике довольно глупое выступление от человека, который понимая ассемблер совершенно не в курсе как работают современные микропроцессоры.Детально объяснять почему глупое будет довольно долго ибо очень много важных нюансов, но я уложусь в пару коротких тезисов. Эти тезисы полностью нивелируют оверхед от единичного "jne" (или je+jmp в ситуации далекого адреса перехода).
1. (и самое важное) спекулятивное выполнение,
2. задержки в доступе к памяти,
3. предсказатель переходов.Эти три пункта позволяют unique_ptr внести возможную задержку в код выполнения программы на уровне 0,00000001%. В то время как даже обычное переключение задачи вносит возможную задержку в 0,001%. А примитивнейший доступ к не выравненному адресу (например, при поиска в строке) вносит возможную задержку в 0,1%.
Так что де-факто unique_ptr добавляет ровно 0.0% (ноль целых ноль десятых процентов) оверхеда.
--
Желающие проверить лично берут и используют "sudo perf stat хелловорлд-с(и-без)-смарт-поинтерами",
желающие глубоко проанализировать - "perf --help".
> "jne" (или je+jmpНет. Это лишняя mov (регистровая) инструкция. Можете сами сравнить https://rust.godbolt.org/z/Ed69aKqah
>Желающие проверить лично берут и используют "sudo perf stat хелловорлд-с(и-без)-смарт-поинтерами",
Я лично проверять не буду, доверюсь автору видео благо он известный специалист по оптимизациям https://twitter.com/chandlerc1024
Но если вы хотите, можете сами замерить, доказать свою правоту ему в Twitter, указать на его ошибку, получить свою долю славы. Я бы тоже с интересом посмотрел на бенчмарк.
>> "jne" (или je+jmp
> Нет. Это лишняя mov (регистровая) инструкция. Можете сами сравнить https://rust.godbolt.org/z/Ed69aKqahты тоже "человек, который понимая ассемблер совершенно не в курсе как работают современные микропроцессоры." (c) Урри
>>Желающие проверить лично берут и используют "sudo perf stat хелловорлд-с(и-без)-смарт-поинтерами",
> Я лично проверять не буду, доверюсь автору видео благо он известный специалист
> по оптимизациямТак тяжело потратить 5 минут на пару элементарнейших движений? Или банально не умеешь?
Небось еще и поклонник раста, я угадал?> доверюсь автору видео благо он известный специалист по оптимизациям https://twitter.com/chandlerc1024
Ээээ. И что я там должен увидеть? Какие-то вообще не относящиеся к оптимизации бла-бла-бла?
"QT is an image of a long, largely on-point critique of how Calendly ends up asserting (somewhat viciously) the social capital power differential between two people." ?????(по секрету - я тоже известный в некоторых кругах специалист по оптимизациям. мне за это даже деньги платят, причем очень давно).
> Я бы тоже с интересом посмотрел на бенчмарк.
Возьми и сделай, это не сложно.
Впрочем ладно, так и быть. Вот тебе синтетическая рыба с тестами, ничего даже делать не надо - открыл ссылку и смотри.Ну или можешь все-таки засунуть в нее хоть какой-то не относящийся к unique_ptr код и насладится вообще сполна.
https://pastebin.com/PrY2H9qBСамое вкусное внизу - когда на одном и том же коде в совершенно идентичных условиях то "63 842 579 962 cycles", то "63 179 246 976".
Угадай, какая пара этих значений принадлежит uniq_ptr, а какая пара просто new:
17 844,46 msec task-clock
17 917,53 msec task-clock
17 986,22 msec task-clock
18 921,22 msec task-clock
Вообще, в видео показано что генерируется лишняя инструкция в моменты использования unique_ptr, а не просто при создании его и уничтожении (как в вашем примере).Он дальше в видео объясняет это существованием необходимости поддерживать различные типы соглашений о вызовах. Таким вот образом легаси замедляет современные программы на С++.
Аноним. Вы что, рассчитывали, что я засяду тратить пару часов времени чтобы полностью прослушать выступление, законспектировать его, разобрать на части, для каждой сделать пример и дать вам проигнорировать или обосрать (что вы прямо сечас и сделали)? Нет, у меня даже в мыслях этого не было.Для тех, у кого есть более одной извилины я написал три коротких тезиса, по которым хомо сапиенс само найдет, разберется и поймет. Для тех, у кого полторы - я привел рыбу, куда надо вписать нужное (можно даже не приходя в соснание) и пример как это запускается.
> Таким вот образом легаси замедляет современные программы на С++.
Впрочем вас это, очевидно, с вашей половинкой извилины, не касается.
> Даже такое простое и базовое RAII как unique_ptr не позволяет избежать оверхеда в рантайме. https://www.youtube.com/watch?t=1061&v=rHIkrotSwccТы хотел сказать что раст работает на радуге единорогов поэтому волшебные фиксики вручную правят напряжение в модулях памяти, а рантайм отдыхает? Или это в духе "а у вас негров линчуют"?
> Не говоря уже о том, что грамотное применение этой "нашлепки" на язык делает код длиннее и запутанней.
У плюсов конечно код многословный и избыточный, я и сам грущу по этому поводу. Аргумент годился бы если сравнивали с питоном. Да даже гребанная джава и та почище будет. Но у раста написанного с нуля в 2010х синтаксис еще более отвратный и не менее многословный, читать страшнее чем смотреть на макросы в си.
>Аргумент годился бы если сравнивали с питоном. Да даже гребанная джава и та почище будет.Не надо сравнивать с языками со сборкой мусора. Тем более с динамически типизированными языками. Это идет против основной парадигмы Rust, С++, Ada/SPARK - упрощения синтаксису не в ущерб производительности.
Опять же хочу спросить теперь у вас что конкретно вы бы убрали / поменяли в Rust? Наверно ни в одном ЯП не было столько обсуждения с сообществом, и столько копий сломано как при обсуждении синтаксиса Rust перед имплементацией. Этот синтаксис реально выстрадали.
> Наверно ни в одном ЯП не было
> столько обсуждения с сообществом, и столько копий сломано как при обсуждении
> синтаксиса Rust перед имплементацией. Этот синтаксис реально выстрадали.Вот в этом и проблема. Язык надо сначала хорошенько обдумать и только после этого реализовывать. А не хуяк-хуяк-в-продакшен. Тогда не будет никаких страданий. Точнее, почти не будет.
> Этот синтаксис реально выстрадали.
А сколько страданий еще впереди...
>Язык надо сначала хорошенько обдумать и только после этого реализовывать.Это плюсы-то с их двумя десятками способов инициализации хорошо продуманы? Или та же Сишка с l-value, r-value выражениями?
>>Язык надо сначала хорошенько обдумать и только после этого реализовывать.
> Это плюсы-то с их двумя десятками способов инициализации хорошо продуманы? Или та
> же Сишка с l-value, r-value выражениями?Это стандартна-обтекаемая хрень^W банальность уровня "чтобы писать код без ошибок, нужно просто писать код без ошибок!", выдаваемая местными теоретиками за откровение свыше.
Да.
Хоспаде, кого же сейчас волнует оверхед?
А причем тут с++? Новость по ядро и си. Для си RAII только в виде поделок васянов и в ядре его нет.
> А причем тут с++? Новость по ядро и си. Для си RAII
> только в виде поделок васянов и в ядре его нет.¯\_(ツ)_/¯
>> Вся соль в том, что тебе ПРИДЕТСЯ думать о лайфтаймах в таких
> Сколько вы еще С++99 будете вспоминать? Уже 23 года прошло. В современных плюсах есть RAII.если для тебя лайфтаймы и RAII это одно и тоже, то ой...
> если для тебя лайфтаймы и RAII это одно и тоже, то ой...Оу, люблю такие комментарии. В духе "если вы не знаете в чем разница, мне вас жаль" или "по вашим комментариям понятно что вы не способны уловить суть, не буду тратить на вас время".
Прошу вас, маэстро, ваш выход! Раскройте миру тайну, чем отличаются два подхода с одинаковой функциональностью, явите нам свой гений! Сделайте это не ради меня, не ради себя, а ради человечества которое жаждет узнать истину!
В чистых сях тоже есть RAII, если использовать экстеншн от gcc.
>В чистых сях тоже есть RAII, если использовать экстеншн от gcc.так всетаки в "чистых" или таки если "использовать экстеншн от gcc"?
RAII не предотвращает от aliasing, писали что Chrome от этого сильно страдал. Особенно от use-after-free багов когда некоторые части кода могут иметь указатели на уже освобожденную память. В Rust же память не может быть освобождена пока имеется хоть одна внешняя ссылка на нее. Это проверяется либо во время компиляции borrow-checker'ом. Либо на стадии исполнения при явном использовании программистом подсчета ссылок.Ни юнит-тесты (сотни тысяч строк тестов), ни ассерты, ни санитайзеры по видимости не могут избавить Chrome, Firefox от больше чем сотни багов по работе с памятью в год.
Это как сборка мусора, только без подсчета ссылок на каждый объект (без рантайма). И без "остановки мира" (остановки всех потоков) на освобождение памяти. На данный момент самые лучшие сборщики мусора и популярных языков скорее всего реализованы в Go и C#. В GO например событие остановки мира имеет дедлайн всего в 10 мс.
> дедлайн всего в 10 мс.По прерыванию таймера решает NP-полную задачу?
Нет, по прерыванию таймера освобождает объекты которые до этого, в процессе работы, пометил на освобождение. Горутины доходят до барьера, и когда все дошли происходит освобождение ресурсов.
Самый лучший - в хаскеле.
Ввиду того что хаскель чисто функциональный язык, объекты в куче располагаются всегда в одном направлении - от старших к младшим. Это позволяет эффективно проводить маркап все еще используемых объектов и не менее эффективно перемещать их уплотняя кучу (с соответствующим изменением внутренних указателей).
Тогда лучше уж Vala, какой смысл в этом Rust?
Там сборка мусора
Там подсчёт ссылок, но оно не сильно медленнее Си.
> Там подсчёт ссылок, но оно не сильно медленнее Си.У CPython, перла и PHP тоже "подсчет ссылок", если что ...
А при чём здесь скриптовые языки?
> А при чём здесь скриптовые языки?А при чем тут "Там подсчёт ссылок, но оно не сильно медленнее Си."?
Подсчет ссылок используется в том числе и для сборки мусора.
https://inst.eecs.berkeley.edu/~cs164/fa11/lectures/lecture2...
> Garbage Collection: Reference Countinghttps://devguide.python.org/garbage_collector/
> The main garbage collection algorithm used by CPython is reference counting.
Я не пойму, что сказать-то хотите? Smart pointers в С++ тоже подсчёт ссылок используют и что?
>> Там сборка мусора
> Я не пойму, что сказать-то хотите?https://wiki.gnome.org/Projects/Vala/ReferenceHandling
> Vala's memory management is based on automatic reference countinghttps://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/...
> Similarly, Vala only performs garbage collection (through reference counting) for GObject values. For plain C pointers (such as strings), the programmer has to ensure that storage is deallocated once it is no longer needed (to avoid memory leaks), and that storage is not being deallocated while it is still being used (see Section 1.3.1.1, “Use-after-free errors”)."Папа, где море?"
> Smart pointers в С++ тоже подсчёт ссылок используют и что?unique_ptr использует "подсчёт ссылок"? А плюсовики в курсе?
>unique_ptr использует "подсчёт ссылок"? А плюсовики в курсе?shared_ptr
> Vala's memory management is based on automatic reference counting
Ну и зачем мои слова повторять?
Мы его потеряли как личность^W^W.
> Мы его потеряли как личность^W^W.Тебя тоже покусали яблочные маркетологи (Swift -> ARC -> "инновационные инновации, только у нас!" https://docs.swift.org/swift-book/LanguageGuide/AutomaticRef... ) и ты теперь тоже считаешь, что сборшик мусора по счетчику ссылок вовсе и не сборщик мусора "потому что потому!"?
>сборшик мусора по счетчику ссылок вовсе и не сборщик мусораа кто говорил, что подсчёт ссылок это не сборка мусора?
>> Аноним (215) Там сборка мусора
> Аноним(10) Там подсчёт ссылок, но оно не сильно медленнее Си....
> Аноним(10) а кто говорил, что подсчёт ссылок это не сборка мусора?Не отвлекайся, крути и дальше минусики с плюсиками ...
Сильно, но с memleak ты сильнее обдристался, бро. Мне кажется, то твой потолок прям. =)
> Сильно, но с memleak ты сильнее обдристался, бро. Мне кажется, то твой потолок прям. =)Это с каким голосом в твоей голове ты сейчас споришь?
> Сильно, но с memleak ты сильнее обдристался, бро.Ну почти - не я, а ты на пару с Урри. А так все верно, ага.
Ты эта, прибереги сей "перл" до следующего срача, где нельзя будет посмотреть "как там оно было", просто поскроллив вверх - авось за прокатит.
>> (Урри) Brainfuck - тьюринг полный язык. Утечек памяти там нет и быть не может by-design.(Аноним): +[>+.]
https://arkark.github.io/brainfuck-online-simulator/
> Error: out of memory
> просто поскроллив вверх - авось за прокатитНе-не-не, я надеюсь наш с урри фейл запомнится так, что хватит одного упоминания. ;)
> (Аноним): +[>+.]
> https://arkark.github.io/brainfuck-online-simulator/
> Error: out of memoryИ что это доказывает?! ХD
>> (Аноним): +[>+.]
>> https://arkark.github.io/brainfuck-online-simulator/
>> Error: out of memory
> И что это доказывает?! ХDМестным "экспертам-усе-божья-роса" - как обычно, ничего :)
>>> (Аноним): +[>+.]
>>> https://arkark.github.io/brainfuck-online-simulator/
>>> Error: out of memory
>> И что это доказывает?! ХD
> Местным "экспертам-усе-божья-роса" - как обычно, ничего :)Так что же это доказывает? Ммм?
Или ты как с ансейфом будешь тут убегать от признания? :-D
> Так что же это доказывает? Ммм?Ммм, какой занятный юлеж пошел.
> Или ты как с ансейфом будешь тут убегать от признания? :-DОпять с голосами в своей голове диалог ведешь?
>>> Аноним (215) Там сборка мусора
>> Аноним(10) Там подсчёт ссылок, но оно не сильно медленнее Си.
> ...
>> Аноним(10) а кто говорил, что подсчёт ссылок это не сборка мусора?
> Не отвлекайся, крути и дальше минусики с плюсиками ...Коси под дурачка и дальше. Агрессия от сексуальной неудовлетворённости она такая, да.
На SPARK можно писать. Начать с прошивок оборудования.
Новость на опеннете:> Пятая редакция патчей для ядра Linux с поддержкой языка Rust
Оригинальная новость на Форониксе:
> Rust For The Linux Kernel Sent Out For Review A Fourth Time
> With this weekend's Rust for Linux v4 patches the Rust kernel modules can remove some boilerplate code with certain Crate attributes no longer needed👏
Даже счетчики текут. Как так жить?
Это просто как считать.
У них там до v1, v2, v3 была итерация с самим RFC.
Так что это обсуждение пятое по счету, но патч четвертый. Ведь сложно сделать патч без initial commit)))
В новости есть ссылки на предыдущие 4 набора патчей. Первой была нулевая версия, поэтому v4 - пятая публикация.
"Первой была нулевая версия".И это неправильно. Первой должна быть первая версия. (с) Никлаус Вирт.
Анекдот про символьные вычисления:Пусть число танков равно К. Нет, К мало, возьмём М танков.
> И это неправильно. Первой должна быть первая версия. (с) Никлаус Вирт.Обратите внимание: у Вирта своё мнение было, поэтому он говорил от своего имени.
А у вас своего мнения нет, поэтому вы вынуждены цитаты приводить.
Даже в такой мелочи, как нумерация.Поэтому пересчёт должен начинаться с нуля.
Это была отсылка к авторитету, если вы не в курсе таких элементарных вещей.И я тоже считаю, что индексация должна начинаться с 1. Потому как это, во-первых, логично. А во-вторых это естественный для человечества порядок.
--
ваш троллинг не зашел, если вы не заметили. пишу вам об этом прямо.
Так и шо получается, Си и Плюсы теперь нелогичные и противоестественные? А Паскаль единственно верный в этой троице? :)
> Так и шо получается, Си и Плюсы теперь нелогичные и противоестественные?Нет, конечно. Это вполне просто реализуется и в плюсах и в си.
> А Паскаль единственно верный в этой троице? :)
Нет. Всего лишь у паскаля единственного в этой троице изначально правильная и естественная индексация.
> Нет. Всего лишь у паскаля единственного в этой троице изначально правильная и естественная индексация.Которая или полностью задается погроммистом:
array [-10..10] of int
array [0..63] of char
array [1..100500]
array [boolean]
array ['A'..'Z'] of придумайсамили тоже начинается с 0 для дин. массивов.
Дело привычки, от математиков адресация с 1 идет. С нулем, в определенных случаях получаешь полный математический гимморой.
Не от математиков, а от естественного порядка вещей.
Когда у вас есть один предмет - он первый. Не минус мятый, не семнадцатый и не нулевой. А первый.
Когда предмета два, то второй это второй. Третий это третий и так далее.Естественный порядок счета (с)
Ура! Давно пора!
Давно пора что? Пятую попытку делать?
Я мало кого любила
Второй надоел, третьего забыла
Четвёртый исчез во вторник
О первом почти ничего не помнюНо пятый мой совсем не такой
...
(с)
Если тебе давно пора, то уходи, а то засиделся
Вот правда, я был одним из тех кто иногда даже защищал rust (мне в целом нравится синтаксис), но когда пару дней назад я чистил папки с проектами и aur-хелпераси, и увидел что даже простенькая утилита тянет за собой набор зависимостей на пару гигабайт (чего не делают даже довольно крупные проекты на java с js) я понял что слишком сыро.На мой взгляд пока раст не начнёт использовать системные библиотеки, лучше этим не пользоваться. Да безопасность, но за счёт чего? За счёт того что в один исполняемый файл по сути вшиваются библиотеки, которые уже есть могут быть в системе.
Это безусловно может быть полезно в облаке, где может быть ограниченный набор устанавливаемых пакетов, но давайте хотя бы линкеры как в сях.
Если не прав, можно конструктивную критику и поправления, а не "ты дурак ничего не знаешь".
А потом среди этой кучи либ обязательно заберется бэкдор и начнется: "ой, как так то?"
А пример какой-тотакой утилиты можно?
Не то чтобы я совсем не верил, но "пара гигабайт" звучит ну как-то очень много...
Я писал для себя простой парсер для стимовских vdf файлов, с онлайн редактированием под rocket (идея была в том, чтобы на пк-консоли все время работал steam под нативным композитором, а я редактировал библиотеку через ноут или смартфон) и выбором обложек из steamgriddb.А так тот же paru около гигабайта тянул. Vaultwarden дофига грузит.
Это зависимости для сборки, а не конечное приложение. В C это не так заметно, потому как заголовки сами по себе весят значительно меньше и размазаны по системе (если говорить про линукс).
Дискуссии на тему статической и динамической линковки это древний холивар. Rust умеет оба варианта, но статическая идёт по умолчанию.
Справедливости ради. Умеет в динамическую линковку, но без стабильного ABI скомпилированное на новом компиляторе может вызвать segfault если используется библиотека собранная старым компилятором.
Список изменений как бы намекает, что квадратное впихивают в круглое, но гугл силен, поднажмет и отверстие станет квадратным.
А что удивительного в том, что его приходится допилить для использования в ядре?
Требования к коду ядра мягко говоря специфические. Вспомните сколько пришлось сделать чтобы оно компилилось шлангом?
Откуда такой вывод? Ничего из написанного не потребовало изменений в языке или экосистеме Rust.То к чему были у Линуса претензии пока не реализовано. (Пока это не сделают Rust в ядро не пойдет)
- красивая, быстрая и удобная обработка OOM
- запрет на паники в коде (в том числе при index-out-of-bounds проверках)
> Ничего из написанного не потребовало изменений в языке или экосистеме Rust.Неужели? То есть модули ядра можно собирать Rust 1.0?
на момент старта проекта растом 1.0 можно было собирать только депрекейтет легаси код..
> депрекейтет легаси кодУтверждается, что язык не поменялся. Откуда "депрекейтет" и "легаси"
> Утверждается, что язык не поменялся.Где?
:-D
Кто здесь?
> Пук!Яснопонятно.
>> Пук!
> Яснопонятно.Ааа! Тут Аноним, влезший в чужой разговор и разговаривающий со своим задним проходом.
>>> Пук!
>> Яснопонятно.
> Ааа! Тут Аноним, влезший в чужой разговор и разговаривающий со своим задним
> проходом.Т.е. ты забыл, что влез в разговор со свом с̵о̵л̵о̵м̵е̵н̵н̵ы̵м̵ ̵ч̵у̵ч̵е̵л̵о̵м̵ фантазиями или это самокритика такая?
>Неужели? То есть модули ядра можно собирать Rust 1.0?Пока нет.
Станет возможно сразу же после того, как ядро станет возможно собирать gcc1.0
> ядро станет возможно собирать gcc1.0Где и кем это утверждалось?
примерно там где аноним (165) поинтерисовался возможностью собирать вышеупомянутые патчи при помощи rust1.0 .
я > rust1.0
ты > gcc1.0Зачем ты ведешь себя как типичный растист?
а чеВо такоВа, а как же хваленая Сишная стабильность?
> хваленая Сишная стабильностьГде я это говорил?
Где я писал про gcc?
Шизоид, перестань свои голоса в голове приписывать мне? Верни того Анонима, у него хоть бы более реалистичный поток сознания!
>Где я это говорил?Где я говорил что ты это говорил?
>Где я писал про gcc?
Где я утверждал что ты что-то писал про gcc?
Шизоид, перестань свои голоса в голове приписывать мне! Верни того Анонима, у него хоть бы более реалистичный поток сознания!
> Где я говорил что ты это говорил?Тогда зачем ты это написал?
> Где я утверждал что ты что-то писал про gcc?
Память как у золотой рыбки?
ты > ядро станет возможно собирать gcc1.0
я > Где и кем это утверждалось?
ты > примерно там где аноним (165) поинтерисовался возможностью собирать вышеупомянутые патчи при помощи rust1.0 .> Шизоид, перестань свои голоса
Ответить нечем, начал тупо копипастить слова оппонента?
>> Где я утверждал что ты что-то писал про gcc?
> Память как у золотой рыбки?
> ты > ядро станет возможно собирать gcc1.0Итак разберемся.
На мой вопрос про то где я утверждал что ты писал про gcc, ты меня в ответ спрашиваешь про мою память.И следующей же строкой указываешь что это я писал про gcc.
Чувак, с кукухой все впорядке? Ты же логически связать 2 соседних предложения не можешь, а все туда же, проблемы ядра пытаешся обсуждать.
> ты меня в ответ спрашиваешь про мою памятьИ буду спрашивать, проверять твою память.
Я писал про gcc?
Ты писал про gcc?
в этой теме тех, кто в начале не пишет вывод `uname -a`, надо банить по юзер-агенту.
"uname" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Вот и пиши на русте модули ядра, под чем ты сидишь. А то, как малолетняя шпана бегаете по чужим огородам.
> А то, как малолетняя шпана бегаете по чужим огородам.Интересно, "огород ваш", потому что не одна тысяча строк в ядре за вашим авторством или как обычно, потому что "отправил багрепорт в убунту, внимательно следил за коммит-логами и носил маечку/пижамку с пингвинчиком"?
Не останавливайтесь! Следующий! Продолжаем перепись "инноваторов безопасности в чужом огороде"!
> Не останавливайтесь! Следующий! Продолжаем перепись "инноваторов безопасности в чужом огороде"!Т.е. очередной носитель маечки с пингвинчиком, раздающий ЦУ разработчикам. Яснопонятно.
Главное, к себе не применяй свои критерии оценки, агитатор безопасности в чужом огороде.
> Главное, к себе не применяй свои критерии оценки, агитатор безопасности в чужом огороде.Главное и далее продолжай оспаривать свои фантазии, гордый носитель маечки, лучше разрабов знающий "как надо правильно!".
> лучше разрабов знающий "как надо правильно!".Продолжай приписывать себя к "разрабам". Следующий!
>> лучше разрабов знающий "как надо правильно!".
> Продолжай приписывать себя к "разрабам".Продолжай и дальше балаболить и отмазываться.
> Продолжай и дальше балаболить и отмазываться.А ты и дальше продолжаешь не применять свои отверждения к себе.
>> Продолжай и дальше балаболить и отмазываться.
> А ты и дальше продолжаешь не применять свои отверждения к себе.Ну давай сюда цитатки утверждений - расскажи, где я предписывал другим, чем им занятся и заодно решал за разработчиков, нужен им там раст в ядре или нет (а то ж они, бедолаги, сами не разбирутся).
У меня такой же офтопик, но$ uname -a
Linux THISPC 4.4.0-19041-Microsoft #1237-Microsoft Sat Sep 11 14:32:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux
> У меня такой же офтопик, но
> $ uname -a
> Linux THISPC 4.4.0-19041-Microsoft #1237-Microsoft Sat Sep 11 14:32:00 PST 2021 x86_64
> x86_64 x86_64 GNU/LinuxНу да, из-под WSL всяко виднее, как и чем лучше разрабатывать ядро линукса - а то ж разработчики глупые, сами не разберутся!
Зачем это легаси поддерживать? Пилили бы свой Redex тупо переписывая драйвера с опастного сиА коммьюнити постепенно обросло бы а так выглядит как попытка переманить закоренелых линуксойдов... Там уже маразм скоро у некоторых наступит а они пыхтят
переманить куда кого? разработчики железок хотят писать код драйверов и подсистем под свои новые устройства на расте в том числе при использовании яда линукс. и они хотят чтобы для этого не надо было иметь форкнутое ядро потому что тогда им всёравно придётся второй раз писать драйвера на сях под мейнстрим ядро. вот и вся суть этих телодвижений по обеспечению поддержки ядром кода написанного на раст. потому что можно долго бузтеть и плеваться, но раст будет системным языком будущего и чем раньше ты в него вложишься тем проще будет потом.
Палехчи, палехчи, уже не один убийца цэ/цэпэпэ закопан. Вы еще D (который получше будет) не оплакали, а уже раст толкаете.А если звёзды сойдутся, и раст когда-нибудь выстрелит, то ну так и быть, выучим ваш раст. Сейчас работать надо, а не учить очередную недоделку. А молодым тем более: работы на расте нету, всё серьёзное и фундаментальное на с/с++. Учите lingua franca, вливайтесь в разработку. Оставьте маргиналов копошиться в своём болоте.
На расте уже написано больше чем на D, и в отличие от последнего - написано что-то полезное. А собственно процесс написания настолько приятен, что пишут и матерые бывшие плюсовики, и девочки с розовыми волосами, перешедшие после JS.
Если это не успех в комьюнити, то что тогда успех?
>На расте уже написано больше чем на D, и в отличие от последнего - написано что-то полезное.Паралимпиада какая-то, вообще побоку кто там у вас победил и у кого больше. Полезных программ на расте - 0. В связке с цэпэпэ - 1. И все знают это программу, которая благодаря расту растеряла с десяток поддерживаемых архитектур.
>Если это не успех в комьюнити, то что тогда успех?
Желаю и дальше таких же успехов, бро. Нехай щастить, как говорится. :-D
Лучше бы c++ запилили в ядре.
Придется пилить c++ без исключений и rtti. Простое выключение даст примерно такой же результат, как rust с паниками.
Можно и с исключениями, если все возможные типы исключений отлавливать. А если забыли, то да kernel panic. Я бы скорее stl запретил использовать в ядре, ибо жуткий легаси со смесью безопасного и небезопасного кода, а так же куча совсем не бесплатного оверинженеринга.
Если под STL понимать библиотеку Степанова и Ли, то iostreams и т.п. в неё не входят.
Смысл менять сухое дерьмецо менять на свежее дерьмецо?
Можно спросить - а зачем?
Затем же, зачем и хруст, очевидно же.
не не нужно, ядро должно быть на одном языке, на си, плюсы они больше для бизнеслогики, ну да и для системного но все же именно для ядря, все же лучше только си
Про С++ Линус весьма однозначно высказывался.
Когда наконец народ наиграется в эзотерический раст и начнет пилить проекты на D.
Какие преимущества у D перед Rust? Например, я активно использую Rust во множестве проектов. Что должно заставить меня использовать вместо него D?
Все три столпа ООП.
Ну и зачем?
Анон_из_Восточной_Европы, похоже, имел ввиду юзерспейсные приложения, а не ядро.
> Анон_из_Восточной_Европы, похоже, имел ввиду юзерспейсные приложения, а не ядро.Да даже для прикладных программ непонятно, нужно ли оно. В Rust из привычного понимания ООП нет только наследования реализации для типов (но не для трейтов) и полиморфизма подтипов (но есть параметрический полиморфизм). То есть, имеются другие способы добиться того же. А когда говорят "нет ООП" имеют ввиду обычно что-то уж совсем лишенное высокоуровневых абстракций, но это далеко не всегда так. По хорошему нужно рассматривать не совокупно "ООП", а конкретные концепции, из которых складывается язык.
полиморфизма подтипов (но есть параметрический полиморфизм)О. Хочу оценить насколько пригоден rust.
Проблема отсутсвия стабитльного ABI, думаю с возрастом (моего или rust'а) пройдет.
Не могу пока оценить стоит ли за него браться.
Основная проблема, нужен полиморфизм. Где бы посмотреть примеры?
Желательно что-нибудь в виде двух иерархий типов. Каждая из которых использует другую (во все поля) полиморфно :)
Может кто видел проект с такой реализацией?
Сам себе отвечу. Может быть пригодится, кому-нибудь. Или все же у какого-либо растомана выступит ржавая слеза и он расщедрится на примеры.То, с чем обычно сталкиваешься в крупных проектах: какой-либо контейнер содержащий ссылки на базовый тип иерархии, и содержащий реальные объекты являющиеся подтипами из этой иерархии типов - простым способом не решить.
В плюсах мне не хватает только возможности взаимно возвращать указатели на объекты одной иерархии из соответсвующих им объектов другой иерархии.
Что то типа:
virtual B* A::create();
BC* AC::create();
BD* AD::create();
virtual A* B::create();
AC* BC::create();
AD* BD::create();
где AC и AD - классы производные от класса A
где BC и BD - классы производные от класса B.
Надеялся на появление модулей, в которой данную проблему можно решить, но зря
За модули взялись отмороженные уроды, которые сказали, что перекрестные ссылки это сложно и модули их разрешать не будут. Зачем тогда брались - не понятно.
В Rust есть 2,5 столпа (нет наследования состояния, но есть наследование поведения) так что замечательно все стоит. Хоть и доучивать новое все равно придется. Несмотря на то что язык писался с расчетом на крестовиков, в нем чаще используются другие парадигмы, некоторые вещи реализуются по-другому.
* Используется композиция вместо наследования https://en.wikipedia.org/wiki/Composition_over_inheritance
* Data-Oriented Design там где требуется работать с большим числом объектов https://scholar.afit.edu/cgi/viewcontent.cgi?article=4192&co...
* Другие дизайн паттерны https://rust-unofficial.github.io/patterns/intro.htmlНекоторые сложные проекты на Rust которые можно посмотреть (по строкам кода; данные взяты год назад):
rust-lang 1.78 млн.
redox 1.33 млн.
diem 300 тыс.
tikv 300 тыс.
Veloren 200 тыс.
есть еще интересный проект Servo, но там не считал.
В Д нет тебя и еще кучи рустеров. Уже одно это дорогого стоит.
Когда в него начнут вкладываться корпорации в расчете на армию почти бесплатных обезьян.А пока, к сожалению, селяви.
Язык со сборщиком мусора это фу
"поддерживаемого компанией Intel бота 0DAY"Это что-то про особо тоненькие фичи их процессоров?
Не Ъ: https://01.org/lkp/documentation/0-day/lkp-test-suites-descr...
Когда ядро заржавеет, для его сборки нужен будет помпьютер с 32GB RAM. Ну а нефиг ядро собирать абы где, нужно икономеку поднимать!
Дада, ведь каждый нище6род уже прикупил линию по автоматической сборке светодиодных лампочек себе в сортир. Чтобы ушлые китайцы вепку не зпихали.
Мущина, мущина, проснитесь!32GB, вот ржака-то... скоро у каждой бесполезно-pi будет столько. А если ты нище6род и у тебя меньше, какое тебе еще ведро, сиди на своей венде, у нас тут впопенсорс и требует "подбирать железо под операционку".
128TB и то в качестве минимального требования. Ну там - сборка в один поток, окончание когда-то после колонизации Марса...
Ибо нефиг, гугель лучше тебя знает какое ведро тебе собирать. А своим рабам он билдсистему подставит - где-то в облачках, чтоб ушлые индусы не сперли код.
Независимо от того хороший ли язык Rust или нет, хорошие ли его апологеты. Независимо от того выстрелит ли этот язык и проект или нет. Думаю, в любом случае, такого рода вещи положительно влияют на индустрию. Основной бич индустрии это равнодушие. Давно уже прошло время когда узнав об уязвимости какой-то системы можно было бы позволить себе не пользоваться ею. Сейчас в большинстве случаев особого и выбора то нет. Вот нашли CVE - ну и что! Система шлет куда-то данные пользователя - а мне то что! В случае пользователей это вполне объяснимо, ведь не даром самая популярная ОС - та что "проще", а не та что безопаснее. Нужен клиент для сервиса - заверните кусок вебсайта в браузера, и не важно сколько оно ест памяти. Уязвимые процессоры - да ладно такого никогда не произойдёт.
Все индейцы сейчас ходят с значками шерифов, чтобы иметь законное право не волноваться о чужих проблемах. Наверное где-то есть обоснование того, что безучастная равнодушная толпа ведет себя статистически более предсказуемо и поэтому легко управляется.
Поэтому пусть пытаются что-то изменить, переубедить, спорить. Неважно на стороне Rust или на стороне C/C++, пусть пытаются выиграть каждый байт потребления памяти, пусть спорят о Native vs Managed, UsageReport vs Privacy и т.п. Главное чтобы были не равнодушными.
Одинаково плохо как игнорирование вопросов управления памятью (типа всё что можно уже делается, надо лучше стараться и т.д.) так и "бесспорный" переход на Rust, который автоматически "сам всё улучшит".
Нет уже пусть Rust фанбои продолжают "истерить на форумах" доказывая что проблема имеет место, а C-шники продолжают также "истерить" доказывая, что мол можно и по другому решать проблему. И те и другие конечно во многом не правы, но это не позволяют просто отмахиваться от проблемы, а бэкдоры становится всё сложнее маскировать под "недоработки".
Вот бы и по другим проблемам индустрии было бы также. Пусть спорят о безопасном процессоре, о браузере на низкогигобайтной RAM-диете, о преимуществах Native приложений по сравнению с Electron и прочее.
>Поддержка Rust преподносится как опция, не активная по умолчанию и не приводящая к включению Rust в число обязательных сборочных зависимостей к ядру.Я сборщик. Ядру Линукса Раст не нужен, только усложнит сборку. Сейчас для сборки ядра требуется только GCC (только компилятор). По мере увеличения кодовой базы на Расте станут требовать не только компилятор Раста, но и его так называемое сборочное окружение. Юниксы исторически по внутренней структуре устроены очень просто, внедрение Раста только усложнит систему.
Пусть растоманы держатся подальше от ядра Линукса. Пусть лучше они допиливают свой Редокс. Все преимущества Раста относительно ядрописательства высосаны из пальца.
> Пусть растоманы держатся подальше от ядра Линукса. Пусть лучше они допиливают свой Редокс. Все преимущества Раста относительно ядрописательства высосаны из пальца.Покажи, пожалуйста, список своих патчей в Linux.
Лул, аргументПокажи свои безопасные "на расте" и рецепт сборки ядра вместе с ними
Аргумент, на самом деле, отличный. Потому что люди, не пишущие ядро и рассуждающие что там нужно, а что там не нужно, выглядят странно.
Это не аргумент, это троллинг. Хамский, тупой троллинг.
> ... станут требовать не только компилятор Раста, но и его так называемое сборочное окружение
> ... Пусть растоманы держатся подальше от ядра Линукса. Пусть лучше они допиливают свой Редокс. Все преимущества Раста относительно ядрописательства высосаны из пальца.
> Это не аргумент, это троллинг. Хамский, тупой троллинг.Довольно самокритично.
Куда больше лбдей его не пишут, а собирают и пользуют.По сути для них ядро и пишут, для сборщиков дистрибутивов, чтобы на основе ядра делался готовый продукт.
Так вот как раз тем, кто его собирает, лишний геморрой в виде твоих аргументов нах не нужен.
Особенно при кросскомпиляции и так далее
Вот это - аргумент из действительности, а не твое модное неловкое скуление человека, который никогда не занимался этим в реальной работе.
> Куда больше лбдей его не пишут, а собирают и пользуют.
> По сути для них ядро и пишут, для сборщиков дистрибутивов, чтобы на
> основе ядра делался готовый продукт.
> Так вот как раз тем, кто его собирает, лишний геморрой в виде
> твоих аргументов нах не нужен.
> Особенно при кросскомпиляции и так далее
> Вот это - аргумент из действительности, а не твое модное неловкое скуление
> человека, который никогда не занимался этим в реальной работе.+1
> Куда больше лбдей его не пишут, а собирают и пользуют.Ну не нравится, переходи на другое ядро. Ах да, других сопоставимых нет.
>> Куда больше лбдей его не пишут, а собирают и пользуют.
> Ну не нравится, переходи на другое ядро. Ах да, других сопоставимых нет.как раз-таки в текущем его виде - очень даже нравится (если нормално читать, что я написал, а не через слово)
и другие пока что не нужны
> Я сборщик.Сборщики должны страдать. Как и мейнтейнеры вообще. Всё это нытьё "мне стало сложнее выполнять мою работу", потому что программисты начали использовать новые инструменты -- это именно что нытьё. Разработка программ ведётся программистами, и программисты выбирают такие инструменты, которые им удобны, а не такие, которые делают жизнь мейнтейнеров безоблачной и не требующей никакой работы. Если бы они были бы заняты вторым и выполняли бы твою работу за тебя, то ты был бы не нужен как класс.
https://www.phoronix.com/scan.php?page=news_item&px=Debian-N...Это тандем. Хочешь не крутить педали, а чтоб за тебя их крутил один мейнтейнер? Ну, уговори, чо. =)
> https://www.phoronix.com/scan.php?page=news_item&px=Debian-N...
> Это тандем. Хочешь не крутить педали, а чтоб за тебя их крутил
> один мейнтейнер? Ну, уговори, чо. =)Зачем мне уговаривать? Уговаривать мейнтейнера -- это задача пользователя, а не программиста.
> Зачем мне уговаривать? Уговаривать мейнтейнера -- это задача пользователя, а не программиста.1. Пользователю до лампочки какие-то там qt6 с нулём пользовательских программ.
2. Пользователю если не будет возможности установить и попробовать, он так и не узнает зачем ему уговаривать мейнтейнера.
3. Пользователь установит альтернативу.Так что спускайся на землю.
Мейнтейнеры включают в свои дистрибутивы не то, что хотят программисты, а то, что нужно пользователям. Подумай об этом. Тот пользователь о котором ты говоришь -- это среднестатистический пользователь, который не существует[1]. Ты сейчас рассуждаешь в рамках мифологии, оторванной от реальности, веря в богов и демонов матстатистики, будто они часть реальности. Эти персонажи, между прочим, ещё в древнегреческой мифологии появлялись в байке о прокрустовом ложе.[1] https://uxdesign.cc/designing-for-the-extremes-9b9d6e7350a3?...
Думай о реальности, представь себе всю систему в целом и её взаимодействия. Для кого работают мейнейтеры? Для программиста или для пользователя? На чьё мнение они ориентируются, когда принимают решение о том, что заслуживает включения в дистрибутив, а что нет? Может на своё собственное? Может быть, но при таком подходе они рискуют оторваться от пользователей и создать дистрибутив для немногих таких, как они сами. Мейнтейнеры тем или иным образом выясняют, что нужно пользователю, и делают именно это.
А если мейнтейнеры не будут выяснять и делать, то другие мейнтейнеры сделают это. Нет никаких проблем упаковать кеды в appimage и распространять в таком виде. И если ортодоксальные пользователи дебиана, не приемлющие appimage, начнут завидовать кедам других, работающих из appimage, то дебиан _придётся_ искать способ опакетить кеды.
И программист тоже работает для пользователя, а не для кого-то ещё. Поэтому программисту гораздо разумнее убеждать пользователя в том, что ему нужна программа, написанная программистом, а не мейнтейнеров: какой смысл упрашивать этих вахтёров включить свою программу в дистрибутив, если можно напрямую обратиться к пользователю?
Неубедительно, не подтверждается опытом. А вот про мифологию и богов было занятно, расскажите еще. Можете углубиться не только в древнегреческую.
> А вот про мифологию и богов было занятно,
> расскажите еще. Можете углубиться не только в древнегреческую.Читай Харари. Он разбирает как трансформировались древние мифологии и чем они стали в современном мире.
Маккьюсика тока закончу, и так сразу. Спасиб.
Угадал ник по стилю повествования.
> https://www.phoronix.com/scan.php?page=news_item&px=Debian-N...
> Это тандем. Хочешь не крутить педали, а чтоб за тебя их крутил один мейнтейнер? Ну, уговори, чо. =)Уговорить мейнтенера занаться разработкой или к чему это очередная глупая и притянутая за уши аналогия (очевидно, что если разработчик не будет "крутить педали", то мейнтейнеру нечего будет собирать).
>Уговорить мейнтенера занаться разработкой или к чему это очередная глупая и притянутая за уши аналогияАналогия к тому, что и разработчик программы, и разрабы дистров связаны: одни кодят, другие собирают/интегрируют/дистрибьютят.
>очевидно, что если разработчик не будет "крутить педали", то мейнтейнеру нечего будет собирать).
Очевидно, что если разработчик софта не будет идти на сотрудничество с разработчиками дистра, то его софт останется без поддержки и выкинут из дистрибутива. Так было, есть, и будет есть.
>Очевидно, что если разработчик софта не будет идти на сотрудничество с разработчиками дистра,Ой, а почему же systemd все еще в большинстве дистров?
Потому что его банкет в большинстве дистров оплачивает красношапка. У кого есть яйки -- форкнули и выкинули. Остальные даже не включали это изделие в дистр.
> Потому что его банкет в большинстве дистров оплачивает красношапка. У кого есть
> яйки -- форкнули и выкинули. Остальные даже не включали это изделие в дистр.Это кто? Если вдруг хочешь сказать "Alpine", то они не используют systemd только по той простой причине, что он под musl плохо собирается. Кто ещё там, Gentoo? Там есть systemd. Ну вот void разве что, но они сразу по netbsd упарывались.
>> Потому что его банкет в большинстве дистров оплачивает красношапка. У кого есть
>> яйки -- форкнули и выкинули. Остальные даже не включали это изделие в дистр.
> Это кто? Если вдруг хочешь сказать "Alpine", то они не используют systemd
> только по той простой причине, что он под musl плохо собирается.
> Кто ещё там, Gentoo? Там есть systemd. Ну вот void разве
> что, но они сразу по netbsd упарывались.они не используют systemd потому-что systemd -- г--но. И то что он под масл плохо собирается -- лишь одна из причин почему он г--но.
А так: devuan, void, artix, guix, slackware, "вон те ребята" что форкнули арч: парабола/гипербола/обарун/итд, crux, pclinuxos, fsf-approved дистр вроде dragora, kiss, ну в общем гугли.
> они не используют systemd потому-что systemd -- г--ноncopa с тобой не согласен :)
> А так: devuan, void, artix, guix, slackware, "вон те ребята" что форкнули арч: парабола/гипербола/обарун/итд, crux, pclinuxos, fsf-approved дистр вроде dragora, kiss, ну в общем гугли.
Ну то есть нишевые дистры, основной посыл которых "не как у всех". Скажи мне, ты правда думаешь, что кто-то ЗАСТАВЛЯЛ мейнтейнеров использовать systemd? Просто люди не то чтобы идиоты и хотят, чтобы софт на их системах работал без лишнего пердолева.
>> они не используют systemd потому-что systemd -- г--но
> ncopa с тобой не согласен :)там кроме ncopa есть и кисснутые робяты. Впрочем, я сужу по результату, а не словам.
>> А так: devuan, void, artix, guix, slackware, "вон те ребята" что форкнули арч: парабола/гипербола/обарун/итд, crux, pclinuxos, fsf-approved дистр вроде dragora, kiss, ну в общем гугли.
> Ну то есть нишевые дистры, основной посыл которых "не как у всех".Слака появилась когда ниши не было, и смузибои не могли бы даже распарсить что такое "не как у всех". В принципе, типично что ты взялся за "маргинализацию". Свежо, одобряю. Но я как сказал, что те у кого были яйки форкнулись -- так и получилось. Форкнули дебиан и арч. Те кто не имел мейнтейнеров красношапки в дистрах или где другие критерии оценки качества -- даже не впиливали это г--но: slackware, dragora, void, guix, crux, kiss, etc.
> Скажи мне, ты правда думаешь, что кто-то ЗАСТАВЛЯЛ мейнтейнеров использовать systemd?
> Просто люди не то чтобы идиоты и хотят, чтобы софт на
> их системах работал без лишнего пердолева.Прости, но эту шарманку по новой заводить не хочу. Ты прав, поднимаю лапки вверх.
Дык он наоборот как раз - РЕШАЛ проблемы гуаноразработчиков гуанодристов - ничем не париться и не писать никакие сложные не по умишку стартапные скрипты, херак-херак, curl | sudo su и в пакетик.Те два десятка пакетов которым все равно нужны сложные скрипты для запуска и обслуживания - ну будет дописывать тот десяток майнтейнеров которые еще умеют в юникс-системы. А остальные не нужны, любое ОНО с дипломом по гендерным штудиям справится.
Это ты правильно написал - программисты выбирают инструменты, а не макаки, не понимающие как наваянный им же код работает и ждущие от системы сборки чуть ли правки их корявых алгоритмов.
ПыСы. Мне такие чудики напоминают взаимодействие "Вовки в тридевятом царстве" и "Двоих из ларца", а в результате
- "А вы че, еще и есть за меня будете?"
- "Ага"
> Это ты правильно написал - программисты выбирают инструменты, а не макаки, не
> понимающие как наваянный им же код работает и ждущие от системы
> сборкиРечь не про систему сборки и не про понимание кода. Речь про то, что код опакечивать бывает сложно.
> опакечивать бывает сложно.Знаю опакечивателей, у которых словосочетание "собрать пакет" вызывало бурную реакцию и считалось моветоном. Сначала не мог понять причин, а потом вспомнил, что по пляжам ходят люди со старой лыжной палкой и так ей ловко тюк, тюк, тюк... и всякие банки пустые, пакетики из под чипсов и прочий мусор на неё нанизываются. Вот этот труд считается низкоквалифицированным, но люди не ноют, что им тяжело наклоняться и собирать пакетики, придумали рацуху. А тут "я сборщик, ̶э̶т̶о̶ ̶з̶в̶у̶ч̶и̶т̶ ̶г̶о̶р̶д̶о̶ а растоманы мне работать мешают". Тьфу =)
А почему никто не говорит о том, что бинарники на Расте как правило имеют большие размеры. Если Раст проникнет в ядро, забудьте о быстрых и маленьких программах в стиле Юникса.
Потому что если включить нужные опции, то будут маленькие бинарники
А ты лично с каждого растамана будешь требовать чтобы он вручную включал нужные опции? Как правило, бинари на Расте огромных размеров и эту тенденцию или закономерность нам не перебороть.
Просто сборочное окружение дистрибутива может по умолчанию включать нужные опции.
> А ты лично с каждого растамана будешь требовать чтобы он вручную включал
> нужные опции? Как правило, бинари на Расте огромных размеров и эту
> тенденцию или закономерность нам не перебороть.Нет такой закономерности, есть лишь ламеризм отдельно взятых опеннетных "экспертусов", которые ни про сборочное окружение, ни про статическую линковку не слышали ...
Зачем пихать Rust в Linux,проще создать Rust Kernel
Правильно, пусть пишут "ядро ядра", чтобы мог использовать/грузить модули из основной ветки linux.
> Правильно, пусть пишут "ядро ядра", чтобы мог использовать/грузить модули из основной ветки
> linux.Здоровья усопшему (redox)
Так есть уж Rust Kernel - Resdox.
Проще, но пользы, например, лично для меня гораздо меньше.
Если это пятая редакция то видимо патчи пропустят . Это гуд.
> Использование Rust для разработки драйверов позволит с минимальными усилиями создавать безопасные и более качественные драйверы,Теперь не надо изучать нудное устройство ядра, си и прочую мишуру.
Теперь любая домохозяйка сможет легко и просто написать качественный драйвер.Сколько людей были до сих пор ограничены тем, что не могли написать нужный им драйвер для линукса.
Но теперь всё изменится! Теперь сможет каждый, и усилия его будут минимальны.
Толсто.
Да не, прям в тему.
И, главное, не надо теперь изучать само железо! Можно сразу писать драйвер на расте! И он будет безопасный! Только слегка течь и падать там, где растаманы перепутали больше-меньше при проверке вхождения в массив!
> И, главное, не надо теперь изучать само железо! Можно сразу писать драйвер
> на расте! И он будет безопасный! Только слегка течь и падать
> там, где растаманы перепутали больше-меньше при проверке вхождения в массив!На самом деле это хитрый план корпорастов, с целью создать дешевую замену элитным опеннетным изучателям железа и написателям драйверов. Ну и просто отвлечь их от разработки, заставив вместо кода строчить бесчисленные возмущенные комментарии!
> И, главное, не надо теперь изучать само железо! Можно сразу писать драйвер на расте! И он будет безопасный!вот именно!
> Только слегка течь и падать там
совершенно необязательно. Он может просто не работать до перезагрузки устройства (заодно с всем остальным железом) ресетом - это ведь - безопасно!
Одна только беда: других драйверов скоро не останется.
>> Только слегка течь и падать там
> совершенно необязательно. Он может просто не работать до перезагрузки устройства (заодно
> с всем остальным железом) ресетом - это ведь - безопасно!я слышал, сейчас модно задавать лимит процессу какой-нибудь контрол-группой, и рестартить его автоматически, до усрачки, забивая tmpdir'ы всяким мусором, чтоб системд терял связь с компонентами через свой захардкоженный дбас, до хардресета, и так по кругу во славу сатане.
> Одна только беда: других драйверов скоро не останется.
Всегда есть "маргиналы". Для меня это dflybsd. Разрабы портируют дровишки с линуха. Диллон любит сишку (есть опыт разработки компиляторов), и переписывает на сишке если вдруг что-то годное для стрекозы появилось на какой-нибудь не си :-D
Rustзицация продолжается!
Растизм. Исходный код может быть только черного цвета на белом фоне и написан только на единственно верном языке!
> Rustзицация продолжается!Rustлевание. >_<
> Rustлевание. >_<ядру в прошлом году 30 стукнуло, это уже не rustление, это уже жесткая пенетrustия во все порты, с использованием служебного положения.
Взгоготамши. Знал бы тогда, будучи красноокой и романтичной школотой, что стану свидетелем такого перфоманса, запас б юбилейную сигару с коньяком.
Ипать ты лох...Знал бы - продал бы квартиру и пошел на курсы администрирования винды.
На сигары и коньяк зарабатывал бы потом без проблева на месте. И плевал бы, что там у одичалых за забором.
> Ипать ты лох...
> Знал бы - продал бы квартиру и пошел на курсы администрирования винды.
> На сигары и коньяк зарабатывал бы потом без проблева на месте. И
> плевал бы, что там у одичалых за забором.Не, я никсоЕд по зову сердца. "Ну люююююблююююю я тебяяяяяя" (с)
Что с вами не так? Почему вы технические вопросы пытаетесь свести к какому-то странному сексуальному.
> Что с вами не так? Почему вы технические вопросы пытаетесь свести к
> какому-то странному сексуальному.отвечает автор форка FreudBSD
Greg Kroah-Hartman звали. Тоже патч делал для революции в ядре.
Прощай, NVIDIA? Оно может убить и без того жалкий драйвер
Простите, задержался на работе. Все уже успели переругаться? )
Пилили бы они своё растоядро - и всё. А то устроили битву...
>Пилили бы они своё растоядро - и всё. А то устроили битву...так они свое и пилят, не твое же.
Что-то не получается у них редокс...
наверное потому что они пилят Linux ...
Теперь и линукс будет не получаться?!
>Теперь и линукс будет не получаться?!Как будто у тебя раньше что-то получалось.
У всех растаманов не получалось.
о, так ты еще и латентный растоман у которого не получается.мои соболезнования ...
а что, бывают растоманы у которых что-то получается?> мои соболезнования ...
Ну что вы, сударь, это МНЕ вас жаль.
>а что, бывают растоманы у которых что-то получается?Вот, например, Miguel Ojeda :
Linux Kernel:
*Rust for Linux project — Web
*Compiler attributes maintainer — Tree
*Auxiliary display drivers maintainer — Tree
*.clang-format maintainer — TreeStandardization:
*ISO/IEC 9899 — C programming language: Spanish National Body representative — WG14А чего добился ты? какую подсистему ядра сопровождаешь? В комитете по стандартизации С принимаешь участие?
Как там? шаблон не трещит? Ведь, о божечки, человек способен выучить более 1-го ЯП!
И что из этого - получилось? Какой-то менежер атрибутов табличек на шкафчиках со швабрами...
> ... на шкафчиках со швабрами...Эк ты лихо Linux шкафчиком со швабрами назвал. Ты то, поди, по 2 таких ядра до обеда пишешь? Ась?
Ну и, собственно, что ж ты так распереживался то, за "шкафчик" то за этот?
> И что из этого - получилось? Какой-то менежер атрибутов табличек на шкафчиках со швабрами...Да ты не стесняйся, расскажи какие подсистемы ядра сопровождаешь, в стандартизации каких языков принимал участие?
"подистема ядреного комментирования" и "командно-матерный в отдельно взятой квартире"?
Он стал "растаманом" сугубо из-за гугловского бабла: https://techbeacon.com/security/rust-linux-google-pays-isrg-...А так, он продолжает работу над стандартизацией С: http://open-std.org/jtc1/sc22/wg14/www/docs/n2896.htm
>Он стал "растаманом" сугубо из-за гугловского баблаКак все просто с поиском причин у одноклеточных ...
Так а что, по твоему получается, что вселенский вой на опеннете против раста стоит из-за того что всем противникам завидно? Что им гугул бабла не отсыпал?
> Что-то не получается у них редокс...У кого - них?
И почему, кстати, у "не них" (и тебя) не получается Хурд?
Да хоть 25 редакция. Вас с вашим ржавым ведром видеть в ядре не хотят, это вы понять не можете.
Кек, тебе придётся страдать и видеть раст в ядре. Ты не представляешь какое глубокое удовлетворение мне доставляет эта мысль.
Есть в этом что-то патологичное, как думаешь?!
> Есть в этом что-то патологичное, как думаешь?!Не знаю, не думал об этом. Какая разница? Чувство глубокого удовлетворения стоит того.
>> Есть в этом что-то патологичное, как думаешь?!
> Не знаю, не думал об этом. Какая разница? Чувство глубокого удовлетворения стоит
> того.Быть может вы пестуете то, что нужно вылечить, ммм? ;-)
> Быть может вы пестуете то, что нужно вылечить, ммм? ;-)Не пестует, а троллит. Да и не уверен, что тебя можно вылечить.
А че из под анонима? :)
> А че из под анонима? :)Участник: Самокатофил
Тип: Аноним
А сам-то? От санитаров шифруешься?
Может быть, но и что? Мне _не_нужно_ это лечить. А если это нужно тебе, то тебе с этой нуждой придётся смириться и жить.
> Может быть, но и что? Мне _не_нужно_ это лечить. А если это
> нужно тебе, то тебе с этой нуждой придётся смириться и жить.А ты жёсткий, хлёсткий, дерзкий! Уважаю.
Знаю, знаю, тебе пох. Просто хочу чтоб ты знал. Красавчик.
> Знаю, знаю, тебе пох.Нет, не пох. Это результат целенаправленной работы над собой, я очень горжусь им. Мне пришлось отрефлексировать в себе свой образ идеального "Я", принять реального "Я" таким, какой он есть. То есть принять, что я -- это именно вот этот реальный "Я", даже если он не всегда ведёт себя образом подобающим для идеального "Я". Выудить из всей этой мешанины и положить отдельными кучками "Я" такого, каким окружающие меня видят или хотят видеть. И отработать всю эту рефлексию до полного автоматизма, чтобы всегда чётко понимать где и что. Это несколько лет работы над собой, работы которую невозможно было бы провести, если бы мне было пох.
Но любопытно, что ты об этом написал. Обычно люди, когда сталкиваются, оказываются настолько увлечены своими переживаниями, и тем как бы им ещё что-нибудь ляпнуть в текущем cpaче, что им не до того, чтобы анализировать то, с чем им пришлось столкнуться. Они удваивают активность своих попыток уязвить, или доказать, что в интернете кто-то не прав, и... Ну, в общем, им становится не до того, чтобы думать головой. Ты же смог подумать не только о себе в этой ситуации, но и обо мне тоже. Редкое явление.
>Вас с вашим ржавым ведром видеть в ядре не хотят, это вы понять не можете.Хотелки и нехотелки великих экспертов опеннета разработчикам ядра абсолютно неинтересны, это вы понять не можете.
Линукс превращается в корпорастическую помойку -
скоро придётся слезть с дохлой лошади.И найти другую.. FreeBSD, Haiku, что там ещё?
Hurd
> Линукс превращается в корпорастическую помойку -
> скоро придётся слезть с дохлой лошади.
> И найти другую.. FreeBSD, Haiku, что там ещё?DragonFly, NetBSD, OpenBSD.
Увы, мой милый Аноним, боюсь без корпораций систем юзабельных особо и нема
> скоро придётся слезть с дохлой лошади.
> И найти другую..дохлую лошадь? Их тут в избытке, как прям в моровом могильнике.
Некоторая проблема только что сильно разложились и даже заклинания неспособны даже на время заставить их нести груз.
Syllable возродить https://en.wikipedia.org/wiki/Syllable_Desktop К тому же, она под православной лицензией.
> Разработка финансируется Google и ISRG, которая является учредителем проекта Let's Encrypt и способствует продвижению HTTPSТак, это, а зачем вторая лезет с растом в ядро?!
А первая что, без Раста лезет?
Да, сначала без раста залезли: CONFIG_NET_VENDOR_GOOGLE (и многое другое).
смотрю на всю эту ахинею с растом, и и понимаю, что бы хоть хотя бы немного, эту фирму, которая проталкивает раст, унять, нужно отказаться от их браузера, все ровно, хоть на хромиум хоть на ya (если есть под линукс). или ту же оперу
>хоть на yaСовок хочет на Яндекс браузер?
Яндекс браузер написан гуглом на 99,4%, а он тоже входит в Rust Foundation.
Если в ядро Linux добавят поддержку Rust, это создаст прецедент, почему тогда нельзя будет добавить поддержку для Go, Zig, Ceylon и других системных языков?
Всё, чего в итоге добьются (если добьются) Rust'оманы при заигрывании с ядром - это раскол во всём Linux сообществе. Даже не сомневайтесь, что найдутся люди, которые просто не захотят иметь у себя в ядре прибитую гвоздями огромнейшую зависимость в виде Rust (причём единственно расово верную, т.к. никаких альтернатив всё равно нет!). Я не сомневаюсь что Google в итоге сделает так, что ядро начнёт ржаветь, насколько далеко это должно зайти - решать сообществу, но на пользу это никому не пойдёт. Здесь даже возможности языка уходят на 2-ой план. А здесь стоит только начать: если Rust начнёт активно использоваться, возбухнут сторонники C++ в ядре, которых Линус в своё время нахрен послал. Над Rust он скорее просто тихонько стебётся, чтобы инвесторов не пугать, но в итоге прогибаться придётся. В итоге вместо единого сообщества на C, получим множество более удалённых сообществ со своими самоварами и костылями.
> Всё, чего в итоге добьются (если добьются) Rust'оманы при заигрывании с ядром
> - это раскол во всём Linux сообществе. Даже не сомневайтесь, что
> найдутся люди, которые просто не захотят иметь у себя в ядреИ какая вам, Windows'ятникам, разница?