В рамках работы по усилению безопасности критически важных программных компонентов платформы Android компания Google переписала на языке Rust прошивку pvmfm, используемую для организации работы виртуальных машин, запускаемых гипервизором pVM из состава Android Virtualization Framework. Ранее прошивка была написана на языке Си и реализована поверх загрузчика U-Boot, в коде которого ранее находили уязвимости, вызванные проблемами при работе с памятью...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59900
> Из недостатков также заслуживает внимания потребность в улучшенном синтаксисе для доступа к полям структур и индексам массивов через голые указатели без создания ссылок, а также ограничения в создании безопасных обвязок над unsafe-операциями, которые могут вызвать неопределённое поведение и не могут быть проверены компилятором. Например, подобные обвязки невозможно создать для операций с таблицами страниц памяти, так как маппинг страниц в одной части программы, может повлиять на другие части.В этом весь раст
> но ситуация должна измениться после стабилизации поддержки макросовНу так для этого и нужно на нем писать. Чтобы понять чего не хватает/мешает и добавить/убрать это.
Раст же развивается, а не деградирует, в отличие от))
Сейчас даже println! не могут нормально реализовать в макросах, так и пишет коментарием, что встроено глубоко в компилятор.
println можно макросами реализовать, format тоже, и вообще все такие макросы, что не должны возвращать значение зависимое от borrowed данных. Смотри все крейты для логгирования в Rust, они же представляют свои альтернативы println.А вот format_args в текущем виде действительно полагается на магию, поскольку у него скоуп заимствования шире чем возвращаемое значение, условно
let a = format_args!(...);
Должен раскрываться в
let _a = data_for_format(...);
let a = args(&data);Однако если ты делаешь свой макрос, то тебе не обязательно пытаться повторить поведение format_args, поскольку если твой макрос будет сам переменную объявлять:
my_format_args!(a, ...);
То он сможет семартику полностью повторить, пускай и с чуть другим синтаксисом.
В простых случаях его даже сейчас можно перевести на процедурный макрос:
let a = 1;
let b = 2;
let c = a + b;
format_args!("{a} + {b} = {c}")
Раскрывается в
let a = 1;
let b = 2;
let c = a + b;
Arguments::new_v1(&["", " + ", " = "],
&[Argument::new_display(&a),
Argument::new_display(&b),
Argument::new_display(&c)])
Где new_v1, new_display - обычные функции, без магии:
new_v1: https://doc.rust-lang.org/src/core/fmt/mod.rs.html#307
new_display: https://doc.rust-lang.org/src/core/fmt/rt.rs.html#82-98
Это факт. Непонятно почему коммент минусят? В исходниках println реально есть комментарий, что это магия компилятора.
Вот комментарии и код макроса println
https://doc.rust-lang.org/src/std/macros.rs.html#85
с 85 по 139 строку.
Ты не мог бы подсказать, где именно этот самый комментарий?
Наверное, здесь?
https://doc.rust-lang.org/src/core/macros/mod.rs.html#904-907
/* compiler built-in */
> Наверное, здесь?
> https://doc.rust-lang.org/src/core/macros/mod.rs.html#904-907
> /* compiler built-in */То, что оно реализованно как compiler built-in, не означает что оно не может быть реализовано процедурным макросом.
Многие интринзики компиляторов GCC/Clang же тоже можно реализовать напрямую через asm вставки, но это не сделано по разным причинам.format_args же так реализован потому что с таким синтаксисом, который у него есть, его не получится реализовать, можно только если он сам будет объявлять переменную со структурой Arguments: https://www.opennet.me/openforum/vsluhforumID3/131737.html#37.
Однако даже когда вопросы с этим разрешат (По идее это часть https://github.com/rust-lang/rust/issues/54727), не факт что стандартную реализацию переведут, поскольку специальная обработка компилятором позволяет также сильно сократить время компиляции, которое у Rust и так не маленькое.А format_args! много где используется. format!, println!, writeln! и прочее в стандартной библиотеке (Они реализованы как обычные макросы использующие format_args!, а не как built-in), и вся экосистема для логов (Крейты tracing, log) также его используют.
Просили подтверждение, что этот макрос работает на магии (вместо конкретных исходников на самом Rust) - получите. Я ж не отрицаю, что аналогичный функционал можно реализовать средствами самого языка.
Тут вопрос должен быть скорее другой: зачем это сделано именно так, а не иначе?
А фишка в том, что format_args раскрывается на этапе компиляции, а не выполнения, в отличие от других языков. Благодаря этому достигается бо́льшая скорость выполнения кода (не нужно тратить время на разбор шаблона при каждом вызове printf), но недостатком является невозможность использовать произвольный шаблон из переменной (для этого уже нужно разбирать шаблон вручную).
> А фишка в том, что format_args раскрывается на этапе компиляции, а не
> выполнения, в отличие от других языков.Это да, но это не причина по которой он является built-in. В Rust есть процедурные макросы, которые позволяют реализовать точно такой же функционал, т.е на этапе компиляции генерировать код не по шаблону, те же #[derive(...)] являются процедурными макросами.
И format_args с чуть изменённым синтаксисом можно было бы сделать тоже процедурным макросом.Вот например есть крейт ufmt, реализующий форматирование с намного меньшим количеством кода (Это полезно для embedded): https://docs.rs/ufmt/latest/ufmt/macro.uwriteln.html
И это как раз аналог writeln!(), но реализованный не через built-in format_args!, а как процедурный макрос.
Не думой, пиши!11А потом некоторые удивляются, почему это в каждом релизе раста ломают обратную совместимость, добавляя и убирая то одно, то другое.
Ну так пишите на 2021 edition. Там вообще ничего не меняется.
Вас кто-то заставляет использовать последние версии?
Stable rust nonsense. Stay unsafe!
А это ничего что раст принципиально не бекпортит фиксы на свои дыры?
А какое отношение edition имеет к версии компилятора?
Последний компилятор собирает любой edition начиная с 2015го.All Rust compiler versions support any edition that existed prior to that compiler’s release, and they can link crates of any supported editions together. Edition changes only affect the way the compiler initially parses code. Therefore, if you’re using Rust 2015 and one of your dependencies uses Rust 2018, your project will compile and be able to use that dependency. The opposite situation, where your project uses Rust 2018 and a dependency uses Rust 2015, works as well.
https://doc.rust-lang.org/book/appendix-05-editions.html
Комментаторам выше - Если zip выйдет только в С++23, то зачем на этом языке писались все эти программы столько десятилетий? Ведь zip используется в каждой программе от мала до велика.Каждый день могу мимоходом находить по программе на раст, которую можно смело использовать уже сейчас. Сегодня нашел https://github.com/orhun/systeroid пользуйтесь на здоровье, и продолжайте плевать в тех кто для вас пишет бесплатно.
Истероид и систероид? А зачем? Какой такой безопасности мне дало наличие несопровождаемой лапши в плохо оттестированной левой тулзе пытающейся мимикрировать под софт который миллионы людей десятки лет наяривают? Чтобы страдать на локалхосте в никому ненужные параметры с сомнительной документацией? Кто-то бесплатно написал для себя - ну, прикольный пэт, но мы ему ничего не должны, мы его не просили нам эту ахинеечку навязывать. А тебя и тем более.
Ну а про каждый день - тут откровенно кое-кто брехло
> наличие несопровождаемой лапшиЕсли ты чего-то не понимаешь, это совсем не означает, что это плохо.
> в плохо оттестированной левой тулзе
Из чего это следует? Или просто тебе так хочется?
> под софт который миллионы людей десятки лет наяривают
Если ты считаешь, что это весомый аргумент, спешу тебя разочаровать. Миллионам людей (обычным пользователям, другими словами), что дали, тем они и пользуются. Но это совершенно не означает то, что на какой-нибудь телеге ехать комфортней, чем в карете с рессорами.
Доступно излагаю?
А потом твой сисьтероид бросит из-за выгорания единственный разработчик и ты останешься сидеть на неподдерживаемом копролите. Я кстати почти не ерничаю, просто реально нет смысла пересаживатся на такие пачками мрущие микропроекты.
Вполне возможно, что этот микропроект и умрёт. Но также возможно, что люди, сравнив этот микропроект и то убожество, которое идёт в стандартной поставке, захотят лучшего.
Макросы это то что надо было убрать из C.
А раст не только не убрал их, так еще и сделал метаязык для макросов, который еще и сильно отличается от самого раста.
Подозреваю долгая комиляция раста в том числе благодаря этому "прексрасному" решению.
> Макросы это то что надо было убрать из CПочему? Макросы - дополнительный уровень абстракции и, следовательно, большей гибкости.
>> Макросы это то что надо было убрать из C
> Почему? Макросы - дополнительный уровень абстракции и, следовательно, большей гибкости.goto тоже дополнительный уровень абстракции и весьма гибкий, его тоже стоит использовать по вашему мнению?
Потому что
макросы надо сначала отпроцессить, это как миниум один раз пройтись по всему тексту это сильно усложняет и утяжеляет IDE и ощутимо замедляет компиляцию
макросы могут ломать логику языка (вроде #define TRUE 0) и тяжело читаются (вроде A_plus_B * C может быть совсем не тем же самым что VAR * C из-за порядка выполнения арифместических действий)
макросы выглядят чужеродно, это костыль к языку, а не функционал (в отличии от темплейтов например)
макросы не нужны. Кроме условной компиляции (которую бы стоило заменить на более подходящии конструкции) как правило применение макросов являются костылем и говорят об архитектурных проблемах в проектах (возможно есть исключения, но в целом)
>Макросы это то что надо было убрать из CНе макросы убрать, а препроцессор. Макросы обрабатывать самим компилятором, чтобы получать адекватные и вовремя сообщения о проблемах. Т.к., в таком случае, компилятор может проанализировать, в корректную ли языковую конструкцию развернётся макрос.
>>Макросы это то что надо было убрать из C
> Не макросы убрать, а препроцессор. Макросы обрабатывать самим компилятором, чтобы получать
> адекватные и вовремя сообщения о проблемах. Т.к., в таком случае, компилятор
> может проанализировать, в корректную ли языковую конструкцию развернётся макрос.Вах! Передвигаешь кровати, прям как растоманы завещали. От того что ты препроцессор (или линтер как растоманы) запихнешь в компилятор ничего не изменится. Тебе все равно придется найти все вхождения макроса и заменить на его значение. А отдельная программа это будет делать или функция в компиляторе - абсолютно без разницы.
Компилятор и так может анализировать. Он получает уже процесснутый вариант с развернутыми макросами. Вот с IDE сложнее.
>Макросы это то что надо было убрать из C.прошло 20 лет и я увидел этот комент, о великий магду :)
Не только в этом
>Из трудностей, возникающих в процессе разработки на языке Rust низкоуровневых компонентов, таких как драйверы, упоминается необходимость работы с голыми указателями в режиме unsafe, так как Rust создан с оглядкой на использование памяти, выделяемой в программе, а в коде, работающем без прослоек поверх железа, приходятся обращаться к разделяемой памяти и MMIO.
> В настоящее время возможности Rust по работе с голыми указателями оставляют желать лучшего, но ситуация должна измениться после стабилизации поддержки макросов offset_of, slice_ptr_get и slice_ptr_len.Т.е., после этого Rust будет такой же сишкой. И к чему были все эти выкрутасы с чеканием боровов?
> Т.е., после этого Rust будет такой же сишкой. И к чему были все эти выкрутасы с чеканием боровов?Да не к чему. Растаманы не понимают, чтоб работать с железом надо работать с сырыми указателями без всяких обёрток, чтоб язык позволял обращаться к памяти напрямую и т.д.
И сколько либ работают напрямую с железом?
1% или 10% ?
а сколько дырок находится в прикладном софте вида "нажал пробел 32 раза, вышел за границы массива, подарил рут"?Раст позволяет сконцентрировать все опасные операции в unsafe блоках, а не размазывать равномерным слоем по всему коду.
> Раст позволяет сконцентрировать все опасные операции в unsafe блоках и размазывать их равномерным слоем по всему коду.Поправил тебя, не благодари.
Наверное поиск в проекте слова unsafe это слишком сложный подход.
it's sad to be you((
Типичный растаман с мгновенным переходом на личности.
Типичные синяки, понятно, белые и пушистые. Просто сейчас болеют. 🤷♂️
> Наверное поиск в проекте слова unsafe это слишком сложный подход.
> it's sad to be you((Ты путаешь тёплое с мягким. Какая разница, если ансейф размазан по коду?
Так и в расте находятся уязвимости и похуже. Как-то твой unsafe не спасает. Зато даёт ложную надежду что тут магическим образом безопасно.> И сколько либ работают напрямую с железом?
А там где не нужна прямая работа с железом и раст не нужен. Есть питон, есть го, есть еще с десяток достаточно медленных но удобных запускалок сишного кода. И раст во многих случаях такая же запускалка (все эти обертки ls, htop и прочее что пишется на расте и запускают сишные системные функции).
> Есть питон, есть го, есть еще с десяток достаточно медленных но удобных запускалок сишного кода.You're pwned! В сишном коде снова забыли что-нибудь проверить.
> You're pwned! В сишном коде снова забыли что-нибудь проверить.В сишном забыли, а растомане и не знали что что-то проверять оказывается нужно было. Думали все на магии работает, а растоманская магия действует только в полнолуние на перекрестке 32 апреля.
Забавны эти Воины Супротив Раста. Сами себе что-то выдумывают про других, абсолютно незнакомых людей. И сами потом же спорят до по-си-нения со своими фантазиями.
Все растаманы по определению идиоты. Ты ведь это хотел сказать?
> Забавны эти Воины Супротив Раста. Сами себе что-то выдумывают про других, абсолютно
> незнакомых людей. И сами потом же спорят до по-си-нения со своими
> фантазиями.
> Все растаманы по определению идиоты. Ты ведь это хотел сказать?Абсолютное большинство. Не по определению, просто люди которые адекватно смотрят на вещи не верят в магию, начинают разбираться и понимают что многое в расте дутое, что язык по сути устаревший, из начала 2000ых, что "безопасность" раст обеспечивает в крайне небольших категориях и крайне спорными методами, зато за это требует довольно больших жертв. Кому-то все равно - ему зарплату в гугле платят и плевать какой язык использовать. Кто-то считает что на новом поприще меньше конкуренции и надеется побыстрее занять гору. Но абсолютное большинство просто жертвы маркетологов.
согласен, но все же начало 2000ых куда лучше конца 70-х прошлого века.
> согласен, но все же начало 2000ых куда лучше конца 70-х прошлого века.Я бы и сам не отказался от современного низкоуровневого языка. Но раст явно не из претендентов. А последние плюсы нехило осовременили по сравнению с плюсами 99. Это конечно не делает его современным языком, но от конца 70ых он отличается как небо и земля.
> Так и в расте находятся уязвимости и похуже.Что может быть хуже получение рута или порчи данных из-за банального переполнения буфера?
>> Так и в расте находятся уязвимости и похуже.
> Что может быть хуже получение рута или порчи данных из-за банального переполнения
> буфера?Порча данных в волшебной программе на расте в которой внезапно магия НЕ РАБОТАЕТ потому что раст НЕ гарантирует защиту от переполнение стека https://github.com/rust-lang/rust/issues/79935#issuecomment-...
Ну а ты то веришь в магию и уже попался. Вот такие вы растоманы. То же самое почти со всеми вашими "защитами", внезапно оказывается что они работают только в полнолуние на перекресте 32 апреля.
> магия НЕ РАБОТАЕТИменно что работает! Стек переполнился - программа крешнулась. А не получила рута))
Переполнение стека можно получить везде. Даже в java (java.lang.StackOverflow) или C# (StackOverflowException).Проблема не в расте, а таких отбитых, которые вначале сами придумывают от чего раст защищает, а потом верещать "раст низащитил!!11". Ты бы вначале документацию осилил. Хотя бы обзорную статью, если в доку не можешь.
> Именно что работает! Стек переполнился - программа крешнулась. А не получила рута))А данные все равно попорчены.
> Переполнение стека можно получить везде. Даже в java (java.lang.StackOverflow) или C# (StackOverflowException).
Так Я об этом ТЕБЕ и говорю. Излюбленный приём растоманов это взять мои факты и в виде оправдания обратно переслать мне -_- Неоднократно уже натыкался.
> Проблема не в расте, а таких отбитых, которые вначале сами придумывают от чего раст защищает, а потом верещать "раст низащитил!!11". Ты бы вначале документацию осилил. Хотя бы обзорную статью, если в доку не можешь.
Отличный план. В 2014-2016 мы все спрашивали а от чего же раст защищает, как он работает, все же не просто так эти проблемы не решены в других ЯП - есть фундаментальные ограничения.
Что сказали растоманы? Ничерта. Никто ничего не мог ответить, но со всех щелей носились со своей серебрянной пулей не спасающей только от смерти. Было дочерта статей (частично от журнализдов, частично от растоманов) где в каждом предложении было про БЕЗОПАСНОСТЬ, УДОБСТВО, СОВРЕМЕННОСТЬ и никаких подробностей (конечно все это было вранье).
На конференциях и в комментариях стековерфлоу иногда проскальзовало (в тч от авторов раста) что "от этого раст не защищает". Казалось бы самое время прервать ересь и написать в доке раста от чего он точно НЕ защищает. Этого конечно не сделали.
Я лично и куча других комментаторов предлагали написать в чем же действительно раст помогает. Конечно же растоманы ничего не ответили.
Проходят годы и вы мои же тезисы пытаетесь использовать против меня. Извини, Поттер, так не работает. Расхлебывайте свой имидж сами.Растоманы самые лицемерные и переобувающиеся разработчики которых я когда либо встречал. Как я и прогнозировл - пройдут годы и выяснится что растовый колосс на глиняных ногах. Так и происходит с каждым годом.
> Ничерта.Нет, это вы были просто не осилил зайти в доку и почитать какие гарантии дает раст!
Я когда-то давно, во времена раст 1.х, даже пытался объяснять тут, но кроме тупого "ыыыы" реакции не было.В каждой теме приходилось повторять как для болванчиков "раст не защищает от логических ошибок", "раст не 'крешится' при int overflow в релизе", "на расте можно вызвать syscall", "раст не защищает от утечек памяти, это логическая ошибка" и тд.
А потом я забил, сюда теперь прихожу поржать с очередной пачки CVE в дыряшке и как ее адепты пытаются выкручиваться.
> БЕЗОПАСНОСТЬ, УДОБСТВО, СОВРЕМЕННОСТЬ и никаких подробностей (конечно все это было вранье).
Потому что нужно было читать доку, а не фигню для домохозяек. В доке написано и про БЕЗОПАСНОСТЬ - памяти (4.1, 4.2, 10.3), потокобезопасность (16.1 и остальные 16.х), умные указатели (15.х), bounds check, про УДОБСТВО и СОВРЕМЕННОСТЬ - нормальные енамы и patterns matching, смартпоинтеры и refcount, слайсы, трейты и тд.
> написать в доке раста от чего он точно НЕ защищает.
А как ты можешь перечислить всё от чего он не защищает?
Разве не логично, что вот то, от чего он защищает, а от всего остального - нет?
Или эту логику не каждый осилить может?> Я лично и куча других комментаторов предлагали написать в чем же действительно раст помогает.
Вам писали. Причем подробно. Просто вы слушать не хотите.
Когда тебе пишут "он не дает писать с двух потоков в одну переменную без локов" этого мало?
Или когда "он запаникует при выходе за границы массива и запишет все в репорт, а не молча испортит чужую память"? Этого недостаточно?
А вы вместо этого г*г*кали и писали "будет мне компилятор еще указывать что делать, я сам лучше знаю!"Я просто не понимаю что еще нужно объяснять.
Там же простейшие правила, которые гарантирует компилятор в safe коде:
At any given time, you can have either one mutable reference or any number of immutable references.
References must always be valid.
Вот что тут непонятного?> Растоманы самые лицемерные и переобувающиеся разработчики которых я когда либо встречал
Я точно также могу написать про адептов дыряшки - как ни CVE то или "выходить за пределы массива это норма, все так делают", или "это не настоящий сишник, настоящий не допустил бы такую глупую ошибку".
Тьху...
> Нет, это вы были просто не осилил зайти в доку и почитать
> какие гарантии дает раст!
> Я когда-то давно, во времена раст 1.х, даже пытался объяснять тут, но
> кроме тупого "ыыыы" реакции не было.Я когда-то во времена раст 1.x даже пытался тут получить от растаманов вразумительный ответ чем же раст помогает и как работает, но ничего кроме тупого "ыыыы" и "на магии" не получил.
> В каждой теме приходилось повторять как для болванчиков "раст не защищает от
> логических ошибок", "раст не 'крешится' при int overflow в релизе", "на
> расте можно вызвать syscall", "раст не защищает от утечек памяти, это
> логическая ошибка" и тд.Вот то же самое делал, но с другой стороны.
> А потом я забил, сюда теперь прихожу поржать с очередной пачки CVE
> в дыряшке и как ее адепты пытаются выкручиваться.Тоже захожу поржать, но с растоманов и очередных ошибках в расте и его проектах.
> Потому что нужно было читать доку, а не фигню для домохозяек. В
> доке написано и про БЕЗОПАСНОСТЬ - памяти (4.1, 4.2, 10.3), потокобезопасность
> (16.1 и остальные 16.х), умные указатели (15.х), bounds check, про УДОБСТВО
> и СОВРЕМЕННОСТЬ - нормальные енамы и patterns matching, смартпоинтеры и refcount,
> слайсы, трейты и тд.Захожу на сайт малопопулярного zig, который не заявляется как самый безопасный и не пропагандируется. Сразу список фич с подробнейшим разбором и сравнением с кучей языков, с примерами и ссылками.
Захожу на сайт раста. БЕЗОПАСНОСТЬ, НАДЕЖНОСТЬ, ПРОДУКТИВНОСТЬ. Ноль подробностей. Вот вам книга, вот вам статьи по ансейф, вот вам статьи по нестабильным функциями языка, а начинать изучать язык вот отсюда, вот вам командная строка, как запускать в вебассембли, нетворкинг, эмбеддед, цитатки разработчиков из модных журналов, ссылки на видосы, гайд контрибьютеров, список контрибьютеров, а нужного нет. Ну о чем тут еще говорить? Очевидно, официальный сайт раста считает что цитатки разработчиков важнее чем рассказать зачем он собственно нужен.
Подробно прочитать немаленькую доку (условно выучить язык), выбрать нужные статьи для того чтобы просто понять нужно мне в это ввязываться или нет - это перебор я считаю.> А как ты можешь перечислить всё от чего он не защищает?
> Разве не логично, что вот то, от чего он защищает, а от
> всего остального - нет?
> Или эту логику не каждый осилить может?Да, это я и хотел написать. Конечно от чего он защищает, буквально список фич с подробным описанием.
> Вам писали. Причем подробно. Просто вы слушать не хотите.
Подробно мне писал всего один человек, но потом стал писать на отвались в духе "вот тебе статья про борроу чекер", открываю статью написанную максимально сухим языком и понимаю что кроме автора и рецензента вряд ли ее кто-то прочел (вероятно и комментатор ее не читал, а просто скинул чтобы я от него отвалил). Это конечно не является для меня препятствием, но совершенно не подходит для обзора фич языка за пару вечеров.
> Когда тебе пишут "он не дает писать с двух потоков в одну
> переменную без локов" этого мало?Нет, норм. Еще лучше если сравнить с другими реализациями и внезапно окажется что это конечно фича, но не киллер.
> Или когда "он запаникует при выходе за границы массива и запишет все
> в репорт, а не молча испортит чужую память"? Этого недостаточно?Достаточно, но опять же это не то чтобы "безопасность" и киллер-фича.
> А вы вместо этого г*г*кали и писали "будет мне компилятор еще указывать
> что делать, я сам лучше знаю!"Похоже вы меня путаете с кем-то. Я как раз из тех кто не против чтобы их останавливал компилятор.
> Я просто не понимаю что еще нужно объяснять.
> Там же простейшие правила, которые гарантирует компилятор в safe коде:
> At any given time, you can have either
> one mutable reference or any number of immutable references.
> References must always be valid.
> Вот что тут непонятного?И тем не менее чтобы их найти надо приложить множество усилий. Чтобы понять нужно ли становится растоманом нужно стать растоманом.
> Я точно также могу написать про адептов дыряшки - как ни CVE
> то или "выходить за пределы массива это норма, все так делают"Не встречал такого, только в шутку.
> или "это не настоящий сишник, настоящий не допустил бы такую глупую
> ошибку".Есть такое. Но встречал вариацию и у растоманов. Более того встречал и куда интереснее разновидность "карго не часть раста".
>> после стабилизации поддержки макросов offset_of, slice_ptr_get и slice_ptr_len
>Т.е., после этого Rust будет такой же сишкой.а когда в сишке слайсы появились?
ну надо же активно изображать работу и прогресс
а как до сей/плюсов допилят - так появится отличный повод придумывать по новой ЯП, который "ну теперь то уж точно ещё более безопасный"
И инвесторам очередную лапшу вешать
Иной раз лучше молчать, чем говорить. Вот же один из инвесторов (Google) использует этот ЯП напропалую. Значит, удовлетворён результатом. Но всегда найдётся опеннетный эксперт, который знает намного лучше, что нужно инвестору. Ох уж эти эксперты...
тут невольно вспоминается история какого-нибудь Дарт'аВ том и проблема, что речь о конкретной конторе
Однажды они сведут приход и расход - и выкинут на помойку с чистой совестью
Не берусь говорить конкретно по расту, но они так делали реаньше и делают постоянно
Всё то, на что вваливались гигантские бюджеты в т.ч рекламные( настолько, что даже до РФ мощно долетало ) - завтра летит в помойку на фоне сухого уведомления авторассылкиОдин из нагляднейших примеров последних лет - Гугл Штадиа. Помнишь обилию и длительность рекламы, обилие всевозможного инфомусора ?
А ты ведь в курсе, что оно уже на помойке ? "Сервис недоступен. Спасибо что участвовали"
И все таки ты кажись бот.
> И все таки ты кажись бот.но я не бот, если речь обо мне
Это потому, что структуры и массивы приходят от небезопасного (например сявого) кода. Вот, например, если сама ОСь на расте будет, это уберет эту половину этой проблемы.
А во-вторых, это потому, что работа с железом небезопасная сама по себе (и это так в любом ЯП) - ЯП (никакой) никак не может защитить от того, что тебе память отдаст неправильный байтик или винт не прочитает сектор и то ли еррор чтения выкинет, то ли мусора насыпет.
и тем не менее на си да и плюсах отчасти пишут очень даже надёжный код в лице прошивок МК для ответственных приложений
Надёжные пишут, да. На MISRA-C. Но его не знает ни 99% сишников, ни 100% опеннетчиков. Поэтому можешь тут не заливать, никто не поверит.
Кстати, а есть ли официальный мисра-раст, который бы знали 100% растовиков ?По мисре и Си, кстати, забавная ситуация
Эти стандарты и требования в принципе не могут знать 100% пейсателей тупо потому, что подавляющее большинство опенсорсных продуктов тупо не тянут этого
Линукс - не исключениеПоэтому, есть или отдельный МК или проц со встроенным МК
В МК - ответственная часть. На базе мизерной РТОСи, а то и повышенной надёжности и гарантированной максимальной длительности срабатывания обработчика( в азур-ртос, бывший тред-икс, это вроде не более 400 тактов )
В проце - жирнющий линукс( даже если урезан до 10-20-40 Мб ), который никогда не пройдёт по соотв критериям. Но это и не страшно, ведь, если он упадёт или зависнет - система на МК отработает корректно, ведь полностью состоит из кода, соответствующего требованиям повышенной надёжности и, при желании, его целиком можно проверить
Ну растоманы уже свою систему написали, только она не работает (но обещали что два года назад допилят). Теперь вот в линукс лезут. Торвальд не дурак и не стал с ними спорить, просто ждет пока раст загнется.
дружок, в ближайшем будующем раста будет больше везде где есть денежки гугла, майкрософта, физбука и других всяких амазонов.посему рекомендую тебе ознакомится со списком платиновых спонсоров Linux Foundation и валить тихонько плакать в темный уголок почитывая о GNU Hurd.
> дружок, в ближайшем будующем раста будет больше везде где есть денежки гугла,
> майкрософта, физбука и других всяких амазонов.Занятно что вся эта славная компания предает своих при первой возможности.
Гугл-купил-выкинул это уже нарицательное. Ну и остальные не менее легендарные выкидыватели.> посему рекомендую тебе ознакомится со списком платиновых спонсоров Linux Foundation и валить
> тихонько плакать в темный уголок почитывая о GNU Hurd.IBM меня беспокоит куда больше. Но пока как-то живем (хотя конечно есть о чем задуматься).
> предает своихШта? Google или кто другой из славной компании кому-то клянётся в верности?
> IBM меня беспокоит куда больше
Ты его не чеши, и беспокоить не будет.
> Но пока как-то живем
Через "не-могу". Да?
> Шта? Google или кто другой из славной компании кому-то клянётся в верности?Ну гугл в этом плане легенда. Купить/возглавить и развалить через пару лет это его конёк.
> Ты его не чеши, и беспокоить не будет.
Если бы.
> Через "не-могу". Да?
Типа того.
> только она не работаетС чего это вдруг? Redox вполне себе работает и даже на реальном железе. Даже браузер запускается)) Более того, у них в планах в 24м году зарелизить версию 1.0.
А то что у нее нет дров к большинству оборудования... ну так не удивительно, в нее не вкладывали миллионы в течение последних 30 лет.
> Теперь вот в линукс лезут.
Ну так они убедились, что можно написать ось с нуля, даже свою си-либу (relibc).
Теперь можно с уверенность улучшать линукс.> Торвальд не дурак
100% )))
> С чего это вдруг? Redox вполне себе работает и даже на реальном
> железе. Даже браузер запускается)) Более того, у них в планах в
> 24м году зарелизить версию 1.0.Но не долго, благодаря утечкам памяти в безопасном языке.
> Ну так они убедились, что можно написать ось с нуля, даже свою
> си-либу (relibc).
> Теперь можно с уверенность улучшать линукс.Прям как сова: "Стратегию я вам придумала, а дальше вы как-нибудь сами".
> Но не долго, благодаря утечкам памяти в безопасном языке.У тебя и доказательства есть? Или просто надо было что-то язвительное ляпнуть?
> Прям как сова: "Стратегию я вам придумала, а дальше вы как-нибудь сами".
А это везде так. Ну или почти везде. Сначала кто-то что-то придумывает (пишет). А потом, если людям нравится, они это подхватывают и совершенствуют. Взять ту же ОС Линукс.
> У тебя и доказательства есть? Или просто надо было что-то язвительное ляпнуть?Я время на тебя тратить не буду и просто отправлю первый попавшийся issue из их проекта (один год на минуточку, напомню первый попавшийся) https://gitlab.redox-os.org/redox-os/redox/-/issues/1360
> А это везде так. Ну или почти везде. Сначала кто-то что-то придумывает
> (пишет). А потом, если людям нравится, они это подхватывают и совершенствуют.
> Взять ту же ОС Линукс.Не, ты не путай. Линукс делал терминал для себя и случайно сделал ОС, которую и другие начали использовать.
Растоманы же обещали быстренько и безопасно сварганить новый линукс, но прошло уже много лет, а они вероятно и сами ее не используют. И судя по тому как рвутся в линукс - больше и не собираются "подхватывать и совершенствовать" редокс.
Один ничего не заявлял и сделал. Другие много чего обещали и не сделали, но уже хотят внедряться в первое.
> Растоманы же обещали быстренько и безопасно сварганить новый линуксА вот теперь давай пруфы.
> И судя по тому как рвутся в линукс
А ничего что это разные люди?
Сейчас редокс, даже при всех его крешах, может на порядки больше чем "терминал" фина тогда.
Ты можешь сравнивать редокс с другими "наколенными" ос - гайкой, колибри, реактом, или, о боже, хурдом.
Сколько его пилят? Что он умеет? А ведь написан на сишечке самим бородачом))
> А вот теперь давай пруфы.Весь опеннет тех лет был завален этими пруфами. Извини, гуглить за тебя не буду.
> А ничего что это разные люди?
Как пиариться, так это все растоманы. Как расхлебывать так это разные люди.
То же и с карго было. Сначала носились с тезисом что "раст лучше си, потому что есть современный пакетный менеджер". Потом нашли уязвимость в карго и внезапно "карго не часть раста".
То же и с бесконечными "защитами". Сначала носились с растом что "от всего защищает", опровержений от растоманов примерно ноль. Потом выяснятся что защищает то от крайне узкого класса уязвимостей и внезапно "а мы ничего не обещали". Но и не опровергали.
Вот такие вы лицемеры.> Сейчас редокс, даже при всех его крешах, может на порядки больше чем
> "терминал" фина тогда.Сейчас и не 91ый год.
> Ты можешь сравнивать редокс с другими "наколенными" ос - гайкой, колибри, реактом,
> или, о боже, хурдом.
> Сколько его пилят? Что он умеет? А ведь написан на сишечке самим
> бородачом))Ну все, уже заднюю дал, тему сменил. Теперь с линуксом не сравниваешь, теперь ищешь с кем бы сравнить, пока собственно не найдешь что-то уж совсем задрипанное и тогда сможешь торжествующе воскликнуть "ну вот раст победил!". И конечно вспомнил про сишечку, но не вспомнил про нормальные системы вроде freebsd. Типичный растоман, что.
> Сначала носились с растом что "от всего защищает", опровержений от растоманов примерно нольС какого-то момента просто перестали опровергать всяких долбней.
> выяснятся что защищает то от крайне узкого класса уязвимостей
Выясняется для неосиляторов документации.
А этот "узкий" класс уязвимостей - самый популярный класс в CVE.
Большая часть дырений проблемы с памятью. И дыряшка в ней лидер.> Ну все, уже заднюю дал, тему сменил.
Никуда я не сдал. Ты вначале сам придумываешь "обещали быстренько и безопасно сварганить новый линукс", твои пруфы сводятся "о, ну так это все знают!", а потом пытаешься меня взять на понт.
Не надо так, это уж слишком жалко выглядит со стороны))).Сравнил я с вышеперечисленными осями потому что они примерно одинаково пилятся.
Редокс сейчас пилят 5 (ПЯТЬ) человек. А ion чуть больше - целых двенадцать человек.> но не вспомнил про нормальные системы вроде freebsd
потому что freebsd пилят c 1993 года используя наработки предшественников, а редокс с 2015 с нуля.
> И конечно вспомнил про сишечку
Конечно вспомнил, хурд же на ней запилили.
> С какого-то момента просто перестали опровергать всяких долбней.Не было такого момента. С самого начала анонса и до сего дня не помню не одной публичной статьи или выступления от создателей или пропагандистов раста (были неплохие статьи от разочаровавшихся в расте, но это другое), чтобы они вышли и заявили "вокруг нашего языка столько слухов, на самом деле он сконцентрирован на вот этих проблемах, а вот эти проблемы он не решает". Ну вот и результат. В плюсах все же повзрослее подход, про те же модули уже неоднократно писали сами члены комитета что не со всем они помогут и какие есть у них проблемы в разных реализациях.
> Выясняется для неосиляторов документации.
Я и документацию по диагонали пробежал. Чего там только нет на официальном сайте раста. Курсы, книги, ансейф, анстейбл фичи, а вот просто списка чем же раст помогает нет. Уж извини, странно прочитать немаленькую документацию (условно выучить язык) для того чтобы выяснить что мне он не нужен. Открываю сайт zig (и не близко к расту по популярности). И сразу вижу фичи. Вижу подробнейший разбор фич, с примерами, с описанием чем он лучше плюсов, D и раста и какие у них есть проблемы и с ссылками. Так что нет, это не для неосиляторов, это для всех.
> А этот "узкий" класс уязвимостей - самый популярный класс в CVE.
> Большая часть дырений проблемы с памятью. И дыряшка в ней лидер.Вот про это я и говорю. Проблемы с памятью еще и разбиваются на кучу категорий. И вот среди всех этих категорий выход за пределы массива ну не факт что лидер. Решается использованием подходящих структур данных (не сишных массивов), установка опций компилятора и т.д. и без раста. А вот переполнение стека раст не решает. Но это тоже проблема с памятью. РАСТ НЕ РЕШАЕТ ПРОБЛЕМЫ С ПАМЯТЬЮ. И я так и не увидел списка какие же проблемы он все таки решает. А вот общие философствования("безопасный"), обобщения("решает проблемы с памятью"), манипулирование статистикой("лидер среди уязвимостей по версии гугла и мелкософта1111!") и прочее от растоманов слышу постоянно.
> Никуда я не сдал. Ты вначале сам придумываешь "обещали быстренько и безопасно
> сварганить новый линукс", твои пруфы сводятся "о, ну так это все
> знают!", а потом пытаешься меня взять на понт.
> Не надо так, это уж слишком жалко выглядит со стороны))).-"Обещали догнать линукс"
-"А вот хард тоже не сделали"
-"А причем тут хард, про линукс же речь, не уходи с темы"
-"Я не ухожу с темы"
Видимо нужно иметь особый склад ума чтобы белое одновременно могло быть черным.> Сравнил я с вышеперечисленными осями потому что они примерно одинаково пилятся.
> Редокс сейчас пилят 5 (ПЯТЬ) человек. А ion чуть больше - целых
> двенадцать человек.Вопрос сколько и кто пилят даже не поднимался.
Кроме того пилят тоже по-разному. Один профессиональный разработчик на полной ставке может запросто затмить и дясяток мимокрокодилов. Или наоборот один ноулайфер запросто может и за двоих таких разработчиков коммитить. Считать проекты по разработчикам ну такое.> потому что freebsd пилят c 1993 года используя наработки предшественников, а редокс
> с 2015 с нуля.Релиз раста
"В плюсах и си слишком много легаси, мы сделали новый язык, без легаси, вот"Релиз редокса
"Что это они с нуля пишут"
"Ну так небезопасно же си использовать, расторелигия не позволяет" (на самом деле используют)
"Так они и до 2077 года не допишут"
"На расте писать быстрее и 10 лет не пройдет заткнут линукс"Проходит несколько лет
"Ну Редокс линукс не заткнул, но лучше всего остального"
"А как же фряха"
"Ну фряха ж легаси использовали"Окай. Количество переобуваний просто зашкаливает.
> Растоманы же обещали быстренько и безопасно сварганить новый линукс, но прошло уже много лет, а они вероятно и сами ее не используют.Ого, это же надо настолько нагло врать!
Рассмотрим редоксовские цели:
Redox is an attempt to make a complete, fully-functioning, general-purpose operating system with a focus on safety, freedom, reliability, correctness, and pragmatism.
(https://doc.redox-os.org/book/ch01-01-our-goals.html)Что в слове attempt тебе не ясно?
Они хотят попытаться сделать альтернативу линуксу, а не его замену
We want to be able to use it, without obstructions, as an alternative to Linux on our computers. It should be able to run most Linux programs with only minimal modifications.
Я писал про растоманов, который тут на опеннете это и писали, а не конкретно про авторов редокса. Не надо перевирать мои слова.
В расте опять сломали компиляцию жырнолиса? 172 на прошлой неделе собрал норм, а 173 на этой уже не может скомпилировать из-за симд. Какой же никчёмный язык, каждый минорный апдейт отламывается часть кода. Хорошо, что на нём никто не пишет программ.
на ПК лису после 92 esr сломали.
forum mozilla russia в помощь
--
на дроиде - после 68й.
--
браузер делают под менеджеров и топов mozilla, а не под юзеров. ну их нафиг
Лиса 115.3.1 еср норм компилится со 171.1 Хрустом.
Странно, у меня все работает.
Может у тебя какие-то пробелмы с конфигом?
Ты вчера компилировал www-client/firefox-118.0.1 с dev-lang/rust-1.73.0, точно? Судя по прошлым аналогичным проблемам фф с компилятором, дело не в конфиге.
с прямотой рук у него проблема, и их постоянным расположением в одном интересном месте
Как именно ты предлагаешь исправить ошибку сборки пакета unrecognized platform-specific intrinsic function: `simd_shuffle2` (и ещё несколько похожих) прямыми руками, расположенными в другом неинтересном месте?
А у тебя компилятор какой версии?
sys-devel/llvm-17.0.2-r1 и dev-lang/rust-1.73.0, т.е. актуальные на данный момент версии из реп (без nightly).
Правда да, у фф в зависимостях прошлая версия.www-client/firefox-118.0.1 requires sys-devel/llvm:16
Но раст всегда с более новой собирался.
dev-lang/rust-1.73.0 requires sys-devel/llvm:17[
В арче файрфокс собран с 16 шлангом и 1.72.1 растом если что.
> В арче файрфокс собран с 16 шлангом и 1.72.1 растом если что.1.72.0 тоже компилировал нормально эту версию, видимо, в 1.73 совместимость и сломали.
Понимаете, хипстеры не могут по-другому. Если они неделю не будут обновлять и ломать совместимость, у них начнут дергаться конечности... А через месяц впадут в истреику, а затем кому.
> Понимаете, хипстеры не могут по-другому. Если они неделю не будут обновлять и
> ломать совместимость, у них начнут дергаться конечности... А через месяц впадут
> в истреику, а затем кому.В своей массовости IT упёрлось в технологический потолок и ничего не остаётся как имитировать бурную деятельность вечно что-то переписывая, меняя обои и перетаскивая иконки слева направо.
Технологический потолок в IT пробит появлением GPT. Джуниоры больше не нужны, хипстеры-растоманы тем более, вот они и агонизируют.
GPT не осилил ГОСТ, не самая сложная штука, тоже мне пробиватель потолков-))))
Замена топ гана на мультиблокКогда дело касается улучшения работы системы, существует множество техник, которые могут помочь в достижении такой цели. Однако, одной из эффективных техник, позволяющих значительно улучшить работу системы, является замена топ гана на мультиблок. Топ ган, иными словами, представляет собой часть программного кода, который выполняет определенную функцию в системе.
Зачастую, при использовании топ гана возникают различные проблемы, такие как длительное время выполнения задачи, большие нагрузки на процессор, а также возможности конфликтов с другими программами. Чтобы избежать этих проблем, эксперты рекомендуют использовать мультиблок вместо топ гана. Мультиблок представляет собой набор различных программных кодов, которые выполняют ту же функцию, что и топ ган, но с использованием различных алгоритмов и подходов.
ГПТ дно пробил, а не потолок
Теперь потолок есть, а дна - нет ведь скатываться с сабжем можно бесконечно
Тебе нужен свежий rust-cbindgen инфа сотка.
Ещё не написали, печаль.
> В расте опять сломали компиляцию жырнолиса?
> Хорошо, что на нём никто не пишет программ.🤦♂️
Взаимоисключающие параграфы от Воинов Супротив Раста.
Судя по количеству ворнингов, на расте не пишут даже раст. Что уж говорить об остальных.
"Хорошо,что на нём ничего не пишут, кроме Servo" Чё тут взаимоисключающее?
Попробуй прочитать новость ещё раз.
И где все крикуны "на расте ничего не написано!" ?
Подходите! Не стесняйтесь, хочелось бы услышать ваши жалкие оправдания.
А это и не написано, а переписано. Шах и мат.
Сишколюбы не понимают видимо, что переписать компонент, куда сложнее чем с нуля навалять сишкокода.
Нужно аккуратно соблюдать совместимость, баги оставленные сишкодидом, и при этом пытаться нормально структурировать бредовые макароны дидовского кода сохраняя при этом логику и совместимость.
Ого как запели.
Напомню, лет 6 назад растоманы говорили "на расте гораздо легче и безопаснее писать", "уже почти ос написали", "ещё немного и фф будет целиком на расте".
А теперь вот "сложнее" оказывается.
Писать сложнее наоборот. Там ошибки сложные.Зато отлаживать меньше
> Ого как запели.
> Напомню, лет 6 назад растоманы говорили "на расте гораздо легче и безопаснее писать"Безопаснее писать точно легче. В целом писать думаю куда удобнее и приятнее, "лёгкость" тут сложно определить. Например сишник может легко наваливать сотни строк бреда в минуту без задней мысли, вроде как то же "легко".
> "уже почти ос написали", "ещё немного и фф будет целиком
> на расте".Ну, ОС то уже давно написали, но причём тут это вообще?
> А теперь вот "сложнее" оказывается.
А почему оказывается и теперь? Всегда так было, с любым языком вообще.
> Напомню, лет 6 назад
Вы уже наверное и школу окончили, а таких простых вещей все ещё не знаете...
На расте написали вендорлок - радуйся
>И где все крикуны "на расте ничего не написано!" ?Уточним: На Rust не написано ничего, кроме:
- части Mozilla Firefox
- переписаной с C/C++ кучи ненужной мелочи, зачастую с глюками и урезанием функционала (типа exa)
- Redox
- hello world
Еще ls и cat.
А еще кусок ядра винды, куски андроида, что-то в хроме, драйвер для М1, много проприетарного софта.
Тот самый всеми известный в узких кругах проприетарный софт которого никто не видел?
Это наверное очень узкие проприетарные круги, которые видишь только ты)Андроид вполне open source, им пользуются сотни миллионов людей.
Кстати я забыл еще chromium (https://security.googleblog.com/2023/01/supporting-use-of-ru...), сколько там хромбуки занимают в распределении ОС?Да, Винда закрыта, но пользователей у нее больше, чем у всех остальных вместе взятых - порадуемся за людей, чья система стала безопаснее.
Раз Венда закрыта, то никто и не проверит, на чём там на самом деле что написано. Поэтому такое заявление про части в ней несчитово.
винда закрытая, но исходники нескол ко раз утекали
вот в след раз посмотрим, что там написали)а пока приходится довольствоваться крейтами типа https://crates.io/crates/windows-sys
Всем же известно, что win3.1 писалась сразу совершенной и на расте, но потом что-то пошло не так
Типа закрытые исходники это проблема
https://infosec.exchange/@cxiao/110562188960426172А через год-два исходники опять утекут и проверим еще раз))
В общем ничего адекватного.
- пользовательское окружение COSMIC
- код в ядре Windows 11
- 21% нового компилируемого кода в Android 13 (https://www.opennet.me/opennews/art.shtml?num=58249)
- криптографическая библиотека aws-lc-rs
- Arti 1.1 - официальная реализация Tor, от разработчиков тора (а они наверное понимают насколько опасны уязвимости дыряшки, когда ты пытаешься быть анонимным)
- драйвер Rusticl, который прошел сертификацию OpenCL 3.0 Кроноса (https://www.opennet.me/opennews/art.shtml?num=58114)а так да, сплошные хелловолды, не то что надежный дырявый код у дидов!
тор медленный, дырявый и позволяет тебя сдеанонить не потому что язык, да и что-то загибается он в последнее время
ядро линукса тоже дырявое, но за программу все равно считается)
> да и что-то загибается он в последнее времяГде же теперь хипстеры с безопастным будут дурь покупать?
Хотелось-бы уточнить, а то часто пишут про 21% нового компилируемого кода в Android, а на чём пишут 79% нового компилируемого кода в Android?
логично что на С/С++
гугл в своем блоге даже писал, что у них была проблема найти программистов на Раст
тк сишников много, а толку маловот и приходится расширять покрытие постепенно
Тебе ссылку дали. Но тебе же это не надо, правда? Там даже картинка-гистограмма нарисована с ответом на твой вопрос. И даже говорят, что сокращение кол-ва ошибок работы с памятью за три года обязано не всяким там хитрым "правильным" приемам программирования на си/плюсах и всяким стат.анализаторам/фаззинг-тестированию (которые не сильно гуглистам помогают), а постепенному увеличению кол-ва кода на расте. Они даже подчеркивают, жирным шрифтом, что в растовом коде за эти пару-тройку лет не было еще ни одной(!) ошибки работы с памятью (что намекает, что уменьшающееся кол-во ошибок остается в уменьшающемся объеме нового и старого си/плюсового кода). Там и диаграммы по годам, как увеличивается пропорция раста в новом нативном коде и уменьшается доля си/плюсов. По тем же диаграмма можно увидеть, что доли раста и плюсов (в новом коде) уже почти сранялись (пару процентов разница), бОльшая часть на плюсы сейчас приходится. Но обещают, что постепенно всё новое будут стараться только на безопасных языках писАть, сокращая долю твоих любимых Божественных Йазычков.
> что доли раста и плюсов (в новом коде) уже почти сранялисьсорри, опечатался. Доля раста и си почти сравнялись. Плюсы пока преобладают над ними обоими.
>> что доли раста и плюсов (в новом коде) уже почти сранялись
> Плюсы пока преобладают над ними обоими.вот и я об этом. Ещё раз - 21% НОВОГО кода пишется на Rust, т.е. 79% НОВОГО кода пишется на C и C++.
Да, именно так.
Потому ты не можешь вот просто так взять и дописать функцию на расте в сишный/плюсовый код. А городить кучу обвязок ради этого нерационально. Поэтому что могут - архитектурно, по времени, по капасити - пишут на расте, что не могут - продолжают дописывать на с или с++.
Ты считаешь что 21% это мало, а я считаю что офигеть как много, особенно за всего несколько лет.
> Уточним: На Rust не написано ничего, кроме:
> - части Mozilla FirefoxУточню еще точнее - небольшой части firefox (12% и это с 2018 года все пилят и пилят и то подозреваю тут статисты поработали)
https://4e6.github.io/firefox-lang-stats/
https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9e...
И с чего тебя так раздувает? Что из написанного на расте написал лично ты?
И всякой "не нужной" никому ерундой:
движок Seq
движок RavenDB
Pydantic
>движок RavenDBФантазер, в списке репозиториев даже нет Раста
https://github.com/orgs/ravendb/repositories
Переписывание ради переписывания. Если уж на то пошло, весь потенциально опасный код должен исполнятся изолированно.
> Переписывание ради переписывания.Ты вскрыл всю сущность современного IT бизнеса. Нынче не модно покорять космос и решать жизненно важные задачи с использованием вычислений. Все силы и средства пущены для заработка денег на очередном айфоне и тиктоке.
Да никто и не против переписываний. Проблема в том, что для этого нужен бюджет, который берется из инвестиций, а с этим делом сейчас туго и в ближайшие годы вряд ли станет лучше.
А для покупки рабочих эксплойтов, программ bug bounty и зарплат-времени на фиксы деньги не нужны?
Лучше один раз сделать нормально, чем годами фиксить десятки уязвимостей из-за типичных ошибок дырявых языков.
Денег на фиксы нужно меньше чем на переписывание всей кодовой базы, так что все это влажные мечты.
Так не нужно переписывать все и сразу.
Сначало то что действительно важно (типа криптолиб), а потом все остальное.
Если самое важное переписано и все работает, зачем переписывать остальное? Лучше деньги сэкономить.
Работает? Это когда дырки находят каждую неделю?
Я бы не называл это таким громким словом)
А причем тут "дырявые языки"? Ошибки допускают люди, а не ЯП. Может учиться допускать меньше ошибок надо, а не искать серебрянную пулю в виде 3.14доrust'a?
Угу, все так, но за 30+ лет как-то не научились.
Почему-то на болгарку ставят защитный кожух, заставляют одевать очки и наушники,
электроинструмент идет с двойной изоляцией.Никто не захочет пользоваться дрелью из которой торчат провода и шестеренки (ну кроме СИшников).
Язык это инструмент и он должен быть нормальный.
Так ведь разработчикам нужно чем-нить заниматься, чтобы была работа, а придумать, что ещё можно добавить в Андроид, уже особо не выходит. Вот и занимаются переписыванием на другой язык потихоньку. А через несколько лет, когда большую часть перепишут, небось и подоспеет новый, ещё более безопасный язык
Что-то я сомневаюсь что Гугл-Алфабет бухнет туда неограниченный бюджет на переписывание всего, чтобы потом выложить все в открытый доступ для китайцев и порчих хуавеев.
Придётся купить новый телефон, потому что старый станет тормозить и убивать приложения с таймаутом?
> Придётся купить новый телефонДобропорядочные граждане покупают новый телефон каждые полгода.
Ну не ври, Аноним. Два года цикл поддержки большинства устройств.
Неужели будет лучше, если через эксплойты дыряшки телефон будет ломаться прямо по сети?
Или через картинку на сайте? Или через видео?
Спасибо, за последний месяц уже начитались про "качественный код от настоящих пограммистов".Как и многие аппологеты шишки, ты предлагаешь поменять безопасность на скорость.
А в итоге останешься без своих данных.
Картинки на сайте - это не про песочницу. Уязвимости в фирмвари и, особенно, в GSM-стэке - это не редко намеренно. А вот то что оставят без возможности порутовать телефон и поставить на него свободную прошивку - это вообще лютый минус к свободкам и безопасности. Но растоманам с шишками это невдомёк
Для розжига, из новых сорцов:
```
/// The provided address and size must be to a valid address range (typically on the stack, .bss,
/// .data, or provided BCC).
#[no_mangle]
unsafe extern "C" fn DiceClearMemory(_ctx: *mut c_void, size: usize, addr: *mut c_void) {
// SAFETY: We must trust that the slice will be valid arrays/variables on the C code stack.
let region = unsafe { slice::from_raw_parts_mut(addr as *mut u8, size) };
flushed_zeroize(region)
}
```
М... а что собственно не так?
Раст коду призодится взаимодействовать с богомерзкой.
А там никаких гарантий нет, кроме "мамкой клянусь" от их погромистов.
Вот и приходится верить((
>ядро остаётся на СиИ этим все сказано.
Ну так ядро от Linux, его тоже потихоньку переписывают
Расскажи лучше сразу к 3000-какому году закончат, а то 0.00001% как-то даже не смешно
и никогда не перепишут. пока что нет ни одной софтины на расте, используемой кем-то, кроме самих переписывальщиков
Это Андроидом никто не пользуется? Очень смелое утверждение.
Чё там в ядре на Расте уже переписано, какой-то единственный dummy-драйвер?
unsafe { что; } unsafe { переписывают: } unsafe { ?; }
О, сищник снова мимо буфера записал
А крэшанулся как обычно растоман.
Если Гугл активно возьмётся за Rust, глядишь, и стандарт ISO по нему примут. Тогда можно будет его использовать.
Непонятно только зачем это гуглу. Стандартизация это долго и дорого.
Им нужен альтернативный компилятор? Вроде нет.
У них есть требования от регуляторов на стандартизацию? Тоже нет.
> зачем это гуглуКогда выяснится, что для сборки андроид 18 нужно 3 разных версии rust использовать... иначе не все собирается.
Когда выяснится, тогда и будут тратить на решение проблемы время и деньги. А так, как говорится, преждевременная оптимизация - корень всех зол. То же и про стандартизацию можно сказать, что как нельзя лучше подтверждает история развития Си.
А зачем стандарт?
Если он будет такам же калом, как стандарт С или С++ - то спасибо не надо.Вот цитата из драфта плюсов (working draft N3337)
However, if any such execution contains an undefined operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation).То есть "выполнение операций даже(!!!) предшествующих первому появлению UB не гарантируется".
Это не стандарт, а какой-то ужас.
Правильно гугл делает, языки дырявые нужно закапывать.
А как вы собираетесь сделать язык без UB?UB, же, по сути, означает "мы не знаем, как правильно".
По мере разработки языка UB в хорошо изученных местах уменьшается.
Если всё UB выкинуть заранее, получится POSIX File Locking. Вроде есть, но лучше бы не было.
> А как вы собираетесь сделать язык без UB?Раст нашел ответ на этот вопрос. Не принимать стандарты, во! Нет стандарта, нет UB! Всегда можно сделать морду кирпичом и сказать что все работает как и задумано, это вы чего-то там неверно поняли. Круто же, правда?! Проверено MS OOXML, между прочим, правда, мерзкие зануды все равно нашли расхождения между спеками на 6000 страниц и поведением офиса, индусы не очень качественно поведение офиса переписали в бумажки.
Стандарт в котором написано "мы не занем как оно должно работать, любитесь сами" это отличный стандарт!
Почти такой же отличный как и кода написанные на стандартизированных языках)
Rust community: Всё идёт по плану"
Вы плавно подбираетесь к пониманию почему Раст нравится растоманам - они прониклись идеей что код можно писать без ub с safe коде, которого больше 90 процентов(очень грубо)
> Если он будет такам же калом, как стандарт С или С++ - то спасибо не надо.Намного лучше когда стандартов вообще нет - что левая пятка манагера завтра решит, то и стандарт, а остальные реализации вообще как хотите та к и...сь. Для того чтоли инфильтрацию в совет директоров устраивали чтобы стандартизировать и альтернативные реализации позволять?!
Так сейчас если левая пятка создателя одного из 30 компиляторов решает, что теперь переполнение инта должно дропать стек - и он это просто делает!
И ему за это ничего не будет, это же зафиксированно в стандарте, что ничего не зафиксированно.Ты считаешь что такое https://en.wikipedia.org/wiki/List_of_compilers#C_compilers
это нормально?
Что стандарт С17 в 2023 поддерживает 5 (пять! всего пять) компиляторв?
(причем 4 из них проприетарные)
Имея отличный стандарт, такой как C++, я могу быть уверен, что моя написанная сегодня программа будет собираться и выполняться даже через 20 лет (причем это так есть прямо сейчас). Именно потому, что я могу обойти специально обозначенные как UB и остальное, места.Подход же раста - это когда ты вынужден вечно поддерживать и пересывать код, потому что постоянно ломается обратная совместимость. Каждый, блин, долбаный релиз.
Отсюда очень простой вывод: если ты видишь фаната раста, значит перед тобой хелловолрлдщик, который не пишет и не собирается писать программы, работающие хотя бы годами.
хахаха! ну ты юморист
код на с/с++ может перестать рабоать корректно, после
- смены железа
- смены компилятора
- смены системных библиотек
и тд
>код на с/с++ может перестать рабоать корректно, после- смены железа
- смены компилятора
- смены системных библиотекКод не может работать или не работать! Вот программа, созданная на его основе другое дело. Это раз.
Смена железа, если не радикальная, не приводит к проблемам. Был проц AMD 7XXX, стал AMD RYZEN 7XXX, если спец возможности не задействовал программа написанная на c, coo, rust, delphi, pascal и т.д. будет работать. Другое дело если поменял его на арм, но тут пересобирать под эту архитектору нужно и не важно с помощью какого языка написана программа.
Смена компилятора иногда приводит к плачевному результату на всех известных и используемых мной языках. Частично соглашусь. От языка не зависит.
От смены сис.библиотек может поломаться абсолютно любая программа, которая их использует, в не зависимости от языка.
Много текста, но вывод тот же.
Сишный стандарт ничего не гарантирует.
Ни один стандарт не может дать 100% гарантию. К стандарту нужно относиться как к набору правил, на которые хоть как-то можно опереться. Без них был бы хаос и неизвестность без возможности даже ближнего планирования.
"Хоть как-то" можно опираться на что угодно. Таким образом приходим к выводу: что есть стандарт, что его нет - разницы нет никакой.
Я лично писал на Rust разные программы (обычно это было ПО для выделения данных из больших логов) и могу сказать, что они одинаково хорошо собирались как в старой Ubuntu 16.04 так и в современных версиях Ubuntu и Debian. И ничего нигде не ломалось. Поэтому для меня ваше утверждение про "подход раста" и про "вечно ломающуюся обратную совместимость" выглядит как откровенный 3.14здежь.
Пусть Гуглаг лучше за Carbon возьмётся.
Ну переписали и переписали, какая разница? В чём новость?
Гугл просто решил повыёбыватся.
В том что сишку выкинули, растишку приняли.
Ну и в том, что гугл считает что раст уже готов для прода.
Пока что только растишку выпнули из лисы.
вы вот с этим (https://www.opennet.me/openforum/vsluhforumID3/131737.html#4) анонимом в показаниях путаетесь.кто-то из вас врунишка. я пока склоняюсь к тому что это ты.
Кусок легаси еще в процессе выкидывания и с ним одни проблемы, все так.
> Прошивка pvmfm (Protected Virtual Machine Firmware) получает управление сразу после запуска виртуальной машиныТьфу, блин, так это псевдопрошивка для виртуалок...
для андроидных виртуалок! То есть какой-то просто совершенно невероятной хрени, непонятно зачем вообще существующей и встречающейся ли в дикой природе в принципе.
Очень даже понятно - чтобы тормозить систему, жрать память и высаживать батарею под предлогом заботы о безопасности. Новые смартфоны сами себя не купят.
Что? Виртуалки на смартфоне?
> Ранее прошивка была написана на языке Си и реализована поверх загрузчика U-Boot, в коде которого ранее находили уязвимостиуязвимости нашли в u-boot а переписали какую-то прошивку, где логика ?
Раст - это не про логику, а про переписывание.
> Раст - это не про логику, а про переписывание.паршивку проще переписать её и переписали. Ищут не там где потеряли а там где фонарь светит - им похоже за переписывание платят а не за результат.
Как теперь закладки добавлять? Не чисто тут все
Сразу в Раст, чего непонятно?
>>В настоящее время возможности Rust по работе с голыми указателями оставляют желать лучшего, но ситуация должна измениться после стабилизации поддержки макросов offset_of, slice_ptr_get и slice_ptr_len.Это пять конечно. Когнитивная нагрузка при лабании на этом недоязыке несравнимо выше чем на Си например. Как следствие - отвратительная архитектура прорамм хотя возможно без выхода за границы массива )))
> Когнитивная нагрузка при лабании на этом недоязыке несравнимо выше чем на Си напримерОбычная отмазка неосиляторов.
Возможно просто когнитивные способности, за годы пограммирования на С, немного уменьшились.
Там думать особо не надо. Ключевых слов мало, по поводу UB можно не париться, все равно все остальные тоже забивают.
Про то что думать не надо это Вы правильно заметили... Это объясняет многое в современном программировании )
Конечно прав.
В соседней теме в libcue "просто" забыли написать для track_set_index проверку 'i >= 0'
И "просто" взяли знаковый integer, вместо беззгнакового.О каких когнитивных способностях сишников можно говорить с такими ошибками?
да. типичный пример
но в каком другом языке каой ошибки нельзя допустить?
В языке в котором нет UB для integer overflow ?
Просто не получим отрицательное значение при переполнении.В раст за пределами unsafe block заявлено что его нет.
А в блоке код должен перечитываться и ревьювиться.
+ будет понятно где смотреть в случае чего.
>не получим отрицательное значение при переполнении.А получим просто неправильное.
Да, будет неправильное значение. И это будет обычный баг, коих море в прогах на любом языке.
Но при этом у тебя не будет "выполнения стороннего кода при обработке специально оформленных cue-файлов".
В 0.01% случаев и то вряд ли. Проще заморочится со статическим анализатором, чем с новым языком.
Ага, в 0.01% случаешь в конфете цианид)) Вряд ли бы ты взял из вазочки хотя бы хоть одну конфетку.
> Ага, в 0.01% случаешь в конфете цианид)) Вряд ли бы ты взял из вазочки хотя бы хоть одну конфетку.Есть варианты. 0.01% цианид.
В другой горке кислота. От которой скочуришься через пять лет.
Что выберешь?
Давай я другой пример приведу, который связан с U-Boot
(и из-за чего собственно прошивку начали переписывать)Вот список уязвимостей из обсуждаемой статьи
https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...посмотрим самые страшные за последние пару лет
CVE-2022-34835 - 9.8 CRITICAL (integer signedness error and resultant stack-based buffer overflow)
CVE-2022-30767 - 9.8 CRITICAL (unbounded memcpy with a failed length check, leading to a buffer overflow)
CVE-2020-8432 - 9.8 CRITICAL (a double free has been found in the cmd/gpt.c do_rename_gpt_parts() function ... allowing an attacker to execute arbitrary code)
CVE-2019-14204 - 9.8 CRITICAL (stack-based buffer overflow)Тебе не кажется, что buffer overflow и double free можно было бы исправить используя другой язык?
И такие уязвимости это "визитная карточка" пары известных языков?
> Тебе не кажется, что buffer overflow и double free можно было бы исправить используя другой язык?жаль что на нем пока ...а, стоп, не на нем. CoC.md написан на ракдауне.
> И такие уязвимости это "визитная карточка" пары известных языков?
На которых и написан U-Boot да и почти все остальное в этом несовершенном мире.
А переписькивать гугловые чудо-разработчики начали почему-то опять не его а какую-то невразумительную прослойку между прокладками. И такие вот переписькивания из пустого в порожнее - действительно визитная карточка одного нескучного язычка.
Вероятно, потому что чтобы написать загрузчик - таки нужно прямое управление памятью. Ужастно небезопастное.
> жаль что на нем пока ...а, стоп, не на нем. CoC.md написан на ракдауне.это ж насколько надо быть упоротым чтоб в комментах под очередной новостью про то что написано писать что ничего нет!?
ты настолько жалок, что на остальные твои выпады даже отписывать не охота. такие же вооброжаемые проблемы из поспаленного сознания.
>> жаль что на нем пока ...а, стоп, не на нем. CoC.md написан на ракдауне.
> это ж насколько надо быть упоротым чтоб в комментах под очередной новостью
> про то что написано писать что ничего нет!?это вот насколько т-пым экспертом опеннета надо быть, чтобы не отличить переписькивание очередной ненужной хтонической хрени (о которой и новость) от самого uboot?
>это вот насколько т-пым экспертом опеннета надо быть, чтобы не отличить переписькивание очередной ненужной хтонической хрени (о которой и новость) от самого uboot?этьо ж надо быть настолько убогим, что отвечать не про то что спрашивали?
>но в каком другом языке каой ошибки нельзя допустить?тут больше о том,что получается если кодить без когнитивной нагрузки.
>Обычная отмазка неосиляторов.Это ты про тех, кто ниасилил отслеживание времени жизни объектов и подсчёт размера массива перед копированием, ввиду чего решили сменить язык ~~и пол~~ на более хипстерский? Ну да, есть такое.
Ты про разрабов ядра и других С либ?
Ну, которые уже 30+ лет не могут научиться проверять размер массива или не делать use after free?
Да с ними большая проблема, тк новому они учиться не хотят, а хотят продолжать портить память.А вот перенести обязанность следить за этим всем на компилятор - это прогресс.
Почти как переход от счетов к калькулятору.
Ибо автоматизация освобождает время программиста для других задач.Хорошо хоть такие люди как Линус это понимают и продвигают Раст в ядро.
Раст продвигает в ядро не Линус, но это так, чтобы ты знал.
Как обычно, искпëрды прочитали один абзац про недостаток и скипнули все остальные сложные слова) Просто чисто байт ламеров))
Читаешь сообщения от разных людей из разных лагерей и тихо охреневаешь.Хотите писать код на С - пишите!
Хотите писать код на Cpp - пишите!
Хотите писать код на Rust - пишите!Каждый язык имеет свои слабые и сильные стороны. Раст не исключение, но пока он позволяет избавиться от одних проблем (многие их знают), его будут использовать. Однозначно он частично вытеснит С, Cpp. А через лет 10 появится очередная замена C, Cpp и уже Rust. И начнется очередное переписывание. Это уже проходили. Примеров полно.
Языки появляются, живут некоторое время и уходят в забвение.
Так фанатикам Rust никто не запрещает писать код на их языке, но они агрессивно продвигают идею что и другие тоже должны писать код только на нем.
> они агрессивно продвигают идею что и другие тоже должны писать код только на немРазве? А мне не нравится, что в ядре которым я пользуюсь и от которого зависит столько всего вокруг (мой телефон, мой роутер, мой сервак и тд) дыры из-за СИшечки и ее пограммеров.
Вам не нравится раст в ядре - форкнул и поддеживай сам! То же касается и остальных продуктов.
Это же опенсорс, тебе никто ничего не должен.В соседней теме ноют про х11, но самому поддерживать это страхокодище как-то очереди нету.
Типичный эгоизм "я хочу все себе, но нахаляву, и не смейте мою халяву уменьшать!"
И кого волнуют твои вымышленные проблемы?>не нравится раст в ядре - форкнул и поддеживай сам!
Опытные СИшные герои-программисты так и делают, они самоотверженно поддерживают свой форк которым ты, неблагодарный, пользуешься. Не нравится - форкай и переписывай на Раст, никто за руки не держит.
Типичный растоман ))
> И кого волнуют твои вымышленные проблемы?Данный сайт пестрит новостями про уязвимости в Си-коде, но типичный си-няк считает, что это чужие проблемы и к тому же вымышленные.
Агрессивно продвигают это как? Приходят к тебе домой и заставляют? И что вообще за претензия такая странная? Хотят и продвигают, тебе то какое дело?
А вот и неправда. Никто никого не заставляет.
Хочешь, пиши на С, только за каждый use-after-free будешь по щам получать. Чтоб не расслаблялся.
так проблема в том что ретрограды
а) не хотят признавать проблемы в языке (ну типа "40 лет ходили за водой на улицу к колонке, ишь чего захотели, водопровод в каждую квартиру"), хотя одни и те же баги делаются и 30 лет назад, и 3 года назадб) не хотят изменять подходы даже для С/С++, каждое предложение "а давайте добавим обязательный стат.анализатор" встречается в штыки
Вот как гуглу приходится решать это для андроида:
"старый код остаётся на C/C++, а борьба с ошибками в нём производится через применение fuzzing-тестирования, статического анализа и применение при разработке техник, подобных задействованию типа MiraclePtr (обвязка над raw-указателями, выполняющая дополнительные проверки обращения к освобождённым областям памяти), системе распределения памяти Scudo (безопасная замена malloc/free) и механизмам выявления ошибок при работе с памятью HWAsan (Hardware-assisted AddressSanitizer), GWP-ASAN и KFENCE."в) не хотят учить что-то новое
Ну тут можно было бы понять, тк это всегда трудно, но огромное ЧСВ и считание себя ылиткой так же являются причиной.г) думаю некоторые боятся остаться без работы (а учиться не хочется), и чем больше они замедлят внедрение - тем больше времени выиграют.
В общем это выглядит как типичные старички, которые ненавидят все новое "не нужон это ваш интарнет!!111" (с)
>Вот как гуглу приходится решать это для андроида:Как же так, гугл наконец-то стал выполнять рекомендации по надежному коду на восхитительной СИшечке!
А еще прикинь это же можно делать и для НОВОГО кода, представляешь? А не дробить кодовую базу на 2, 3, 5, 10 языков!Остальные фантазии комментировать бессмысленно.
> А еще прикинь это же можно делать и для НОВОГО кода, представляешь? А не дробить кодовую базу на 2, 3, 5, 10 языков!И где это для ядра? Для libwebp и прочих либ которые недавно опять жиденько продырявились?
Ты же понимаешь что все выше перечисленное это очень сложно? И дорого?
И это по сути костыли которыми подпирают покосившийся и разваливающийся код.А тут есть язык который решает довольно большую часть проблем с памятью.
Так что логично стараться новое писать на нем, а не обкладываться подпорками.
только гугл говорит, что он их и выполнял и что все эти техники им (почти) совсем не помогают и не помогают не только в андроиде, но и в других сишных/плюсовых проектах. А вот постепенное внедрение раста (в андроиде) кардинально уменьшило кол-во ошибок работы с памятью, а не это вот ваше "Scudo hardened allocator, HWASAN, ..., fuzzing coverage...". (Кстати, в раст-коде, которого там уже 1.5 млн строк, за пару лет не было найдено ни одной ошибки работы с памятью, хотя и не категоричны что не найдут в будущем):"We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabilities found in old code that are included in the above evaluation. These are important tools, and critically important for our C/C++ code. However, these alone do not account for the large shift in vulnerabilities that we’re seeing, and other projects that have deployed these technologies have not seen a major shift in their vulnerability composition. We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor."
https://security.googleblog.com/2022/12/memory-safe-language...
(если ты не просто тролль, который покушать зашел или не ослепленный фанатик, то пройди по ссылке и почитай подробнее, картинки графиков посмотри)
Ну давайте, расскажите мне, что я должен вывалить штуку баксов, чтобы андроид (СПО ахаха) не лагал. Замена процессора в Huawei P60 Pro стоит дороже айфона, а сам он как два. Да идите вы в жо с таким СПО!
Не проца, а материнки, не суть.
Че у тебя там лагает? Четрыхлетний сяоми за 40к летает только в путь.
> языка программирования (C/C++)Не существует такого языка программирования.
Это вот у них безопасный язык, типа того: https://cs.android.com/android/platform/superproject/+/main:...
Так круто же! На 439 строк всего 6 unsafe.
Пять из которых однострочные и один - asm вставка.
Хотели чистую и хорошо читаемую замену C++, а получили второй мудреный С++ с доведенной до абсурда системой макросов и претензией на безопасность.Теперь придется учить два C++...
>TEE, Trusted Execution EnvironmentОсновной мотив переписывания на Rust - невзламываемые никак DRM, тивоизация и анальные зонды. Тюрьма для скота.
То ли дело сишечка: и ты взламываешь, и тебя взламывают! Красота!
> То ли дело сишечка: и ты взламываешь, и тебя взламывают! Красота!Ну правильно, мне нравится, когда я могу делать со своим устройством всё, что захочу. Малварь не существует даже в мире венды, если только не скачивать её по ссылкам из первых страниц выдачи гугла. А о той, что существует во всех этих crates.io, ничто не защитит.
То есть у тебя претензии к крейтам что ли? А то, что у тебя в дистрибутиве есть репозиторий, а в питоне есть pip - это не, это другое?
У меня претензии к npm, слишком часто малварь в популярных пакетах в нём появляется (и этот пакет как правило является зависимостью чего-то, что ты используешь). В pypi и репах такого нет, это чисто тема растовиков/жаваскриптеров.
>> То ли дело сишечка: и ты взламываешь, и тебя взламывают! Красота!
>Ну правильно, мне нравится, когда я могу делать со своим устройством всё, что захочу.Злобный "Хакир": " - Ну правильно, мне нравится, когда я могу делать со ТВОИМ устройством всё, что захочу."
> Малварь не существует даже в мире венды, если
"... отключить устройство от сети, выключить и спрятать в сейф".
> ...если только не скачивать её по ссылкам из первых страниц выдачи гугла.
Смешно. За годы уже было дофигища уязвимостей/эксплойтов для всевозможных полезных и "стандартных" программ/сервисов/ядер, причем не только локальных, но и удаленных.
Не, это так не работает. Линукс не венда, тут не достаточно отправить пакет в закрытый порт, чтобы исполнить код. Значит, он должен как-то попасть к пользователю каким-то образом, а это значить уже желание пользователя его запустить. NetworkManager отчасти это исправлял, исполняя пакет от имени рута, но пользователи NM должны страдать и это было только для пакетов из локалочки. Конечно, есть уязвимости, но это касается только тех, кто держит публичные сервисы. Можно ещё любителям samba посочувствовать.
Доо, ведь до раста тивоизации и ДРМ не существовало. Погоди, так если раст позволяет создать _невзлавымаемый_ ДРМ - так это же офигеть как круто! Никакой ЯП такого не умеет и по твоей же логике надо бежать его учить.
Переписал раз, перепишет и второй.
Мы сидим, а денежки идут...Всё так: цифровизация, ограничения возможностей, большие деньги на счёт.
Нужен тилипон на Фрибэсдэ.