Компания Google подвела итоги инициативы по внедрению в Android методов безопасной разработки (Safe Coding), таких как использование языков программирования, обеспечивающих безопасную работу с памятью, применение статических анализаторов и проектирование API с оглядкой на безопасность. Изменения позволили снизить долю связанных с памятью уязвимостей в Android c 76% в 2019 году до 24% в 2024 году, что значительно ниже среднего показателя по индустрии - 70%...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61933
как они в ядре хотят в новом коде гарантировать
> переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительности на 95%Неплохо, весьма неплохо.
А что же скажут хейтеры? "QR коды ненужны"?> для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже чем для кода на C++
О, вот как работает парадигма "хорошо делай - хорошо будет".
Жаль не сравнили с кодами на СИ, было бы интересно глянуть.
> Жаль не сравнили с кодами на СИ, было бы интересно глянуть.Так это для новых кодов.
А гугл на сишке нового практически ничего не пишет.
Поэтому и сравнения не будет.
Почти годный вброс, можно было бы поверить, если допустить, что "старый код" никогда не был "новым", что "новый код" появился только в 2024-м, а в 2010...2015... (и ранее) новый код не появлялся, а всё "диды в 70-х написали" и вся статистика по ошибкам, в том числе и в "новом коде" (который сейчас уже старый, но когда-то был новым), канула в черную дыру. Ваапще непонятно тогда, откуда гугл с мелкомягкими взяли число в 70% ошибок с памятью, если в новом коде их почти нет, а в старом всё уже вылизано и переписывать не надо. Заговор какой-то.
Какой не сообразительный человек. Под нлвым кодом гугл подразумевает, как код который нужно написать с нуля, с того момента когда у них была принята эта парадигма
Какой не сообразительный человек. В 2010...2015... годах (а также и до и после этих годов) у них тоже был код на си/плюсах, написание которого начиналось с нуля и который остался в системах контроля версий. И ошибки, исправляемые в нём, так же остались в истории и статистике. Есть с чем сравнивать кол-во ошибок в старом "новом коде" и новом "новом коде", даже если глупо предположить, что нового "нового кода" на си и плюсах они не пишут.
Рука лицо. На пальцах. Код написаный на си с нуля, страдает большим количеством ошибок. Которые со временем исправляются. Код написанный с нуля по принятому методу, снижает количество ошибок на начальном этапе. Это уже сравнили и подвели статистику.А почему 2015 или 2010. Может взять 1995 год, тоже наверника статистика есть и сравнить скорость разработки и количество ошибок на си и незнаю, с питоном из 2024го или растом из 2024го, да даже си в 2024м будет выигрывать. Подобные иследования делаются не просто так паралельно.
> позволило добиться повышения его производительности на 95%как всегда избирательное цитирование, художественная резьба по цитатам.
Самое главное:
> за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции.
Язык программирования тут не при чём, тут главное страх: раньше всего боялись, теперь не боятся, эмоциональное поведение.
> Язык программирования тут не при чёмЕще как причем. Тот, на котором был написан старый код, не давал достаточных гарантий.
Поэтому его необходимо было сендбоксить.
А новый дает достаточные гарантии. Поэтому его сендбоксить не нужно.
> достаточные гарантииЭто объективно измеримое значение или субъективная эмоциональная оценка?
> Это объективно измеримое значениеРазумеется. Напр. считаешь кол-во CVE на 1000 строк кода на дыряшке, плюсах и на расте.
Сравниваешь два числа. Выкидываешь дыряшку на мороз сразу, плюсы обмазываешь санитайзерами.
Так посчитай и сравни, а пока только голословно вбрасываешь.
Только того техдира Гугла оставь уж в покое )) Это уже некроданные в 2024.
>Так посчитай и сравни, а пока только голословно вбрасываешь.пока голословно вбрасываеш ты.
А гугл посчитал и сравнил.
так что давай, показуй иную сравнимую кодобазу и опровергай выводы гугла.
Я частично согласен, что language matters, но главный, кто лепит ошибке в коде - это ЧЕЛОВЕК. Если нанимаешь индусов, то они и на пестоне навалят багову кучу. Нельзя быть тупым и одновременно "хорошо кодить за счёт языка"! КВАЛИФИКАЦИЯ должна быть высокой, ПРОГРАММИРОВАНИЕ - ЭТО СЛОЖНО. А каждый индус, продающий свои курсы "С++ за неделю" утверждает обратное - "каждая обезьяна может кодить!". Ну так "код от обезьян" мы и наблюдаем!!Я вот код пишу - у меня КРАЙНЕ редко какие-то ошибки связаны с памятью! (спасибо C# ) Если какой-то клоун с недельными крусами сядет за C#, можешь тушить свет - этот код можно сразу нести на помойку.
А sandbox'инг - это вообще за гранью разумного: "вместо квалифицированных специалистов, пишущих правильный код, мы возьмём обезьяну, но завернём её код в песочницу" - гениально!! :))) СМЫСЛ?? Баги так же и останутся (ввиду изначально низкой квалификации разрабов), песочница лишь предотвратит сегфолт.
Там вся идея в том что на расте при всём желании якобы не накосячишь с памятью.
Якобы. Да, падать sigsegv'ом не будет. Но утечки памяти, утечку данных, некорректную работу - это никто не отменял.
На Rust без использования unfase блоков накосячить с памятью?
Не будет ли любезен уважаемый Продавец привести пример такого кода?
https://github.com/Speykious/cve-rs> written in 100% safe Rust.
> https://github.com/Speykious/cve-rs
>> written in 100% safe Rust.Отличный пример того, что для создания уязвимости на Раст нужно
- собрать целый консилиум github.com/Speykious/cve-rs/issues/4
- неделю мучать код
- написать свой null_mute используя transmuteИ только тогда в расте можно получить cve-rs
В общем Воины-Супротив-Раста опять обделались
> И только тогда в расте можно получить cve-rsБыл показан пример кода с "#![deny(unsafe_code)]", который портит память.
Это "достаточая гарантия"?
Если залезть внутрь стандартной библиотеки, там unsafe над unsafe погоняет. Есть независимый аудит стандартной библиотеки, дающий "достаточные гарантии"?
Даже банальный двусвязанный список нельзя написать на safe Rust. https://doc.rust-lang.org/1.81.0/src/alloc/collections/linke...
И этот язык лезет в системные языки со своими "достаточными гарантиями".
> В общем Воины-Супротив-Раста опять обделались
Привет Миротворец-Насильно-Насаждающий-Безопасный-Раст, видящий только обделавшихся
> Был показан пример кода с "#![deny(unsafe_code)]", который портит память.Давай посмотрим внимательнее, что там за самописный null_mute:
/// Equivalent to [`std::ptr::null()`], but returns a null reference instead.
pub fn null<'a, T: 'static>() -> &'a T {
crate::transmute(0usize)
}далее оно уходит в велосипедно-обфусцированный transmute, в общем раз "equivalent", то заменяем на оригинал:
+++ b/src/segfault.rs
@@ -7,7 +7,7 @@
///
/// See [`crate::transmute()`]
pub fn segfault() -> ! {
- let null = crate::null_mut::<u8>();
+ let null = std::ptr::null_mut::<u8>();
*null = 42;и вуаля:
cargo build
Compiling cve-rs v0.6.0 (/tmp-build/seg/cve-rs)
error[E0133]: dereference of raw pointer is unsafe and requires unsafe function or block
--> src/segfault.rs:11:2
|
11 | *null = 42;
| ^^^^^^^^^^ dereference of raw pointer
|
= note: raw pointers may be null, dangling or unaligned; they can violate aliasing rules and cause data races: all of these are undefined behaviorFor more information about this error, try `rustc --explain E0133`.
error: could not compile `cve-rs` (lib) due to previous errorТ.е если не писать специальный код, то да, это "достаточая гарантия".
> Если залезть внутрь стандартной библиотеки, там unsafe над unsafe погоняет. Есть независимый аудит стандартной библиотеки, дающий "достаточные гарантии"?
Не знаю. Можешь привести такой аудит для СИ или С++, я хоть посмотрю как оно оформляется.
> Даже банальный двусвязанный список нельзя написать на safe Rust
О, точно. Это полностью блокирует разработку!
А еще на safe Rust нельзя вызывать дыряшечные функции. Какой ужас!> И этот язык лезет в системные языки со своими "достаточными гарантиями".
Да, и че вы сделаете? Поноете на форуме))?
> Привет Миротворец-Насильно-Насаждающий-Безопасный-Раст, видящий только обделавшихся
Насильно-Насаждающий?!
Никакого насилия. Вон гугл сам пришел к выводу что использование раст уменьшает кол-во ошибок.
А вот обделавшихся, к сожалению, вижу постоянно(((
Просто пишешь "уязвимость" в поиске на этом сайте и получаешь целый парад CVE.
> Т.е если не писать специальный код, то да, это "достаточая гарантия".К чему претензия, к "специально"?
Обычно код пишут _специально_.
Разве что, когда пишут, не приходя в сознание, тогда, да, пишут не _специально_. Но думаю, и в этом случае можно неспециально родить такого трансмутатора.Повторюсь, есть пример safe Rust, который портит память. safe == unsafe. ЧТД.
>> Если залезть внутрь стандартной библиотеки, там unsafe над unsafe погоняет. Есть независимый аудит стандартной библиотеки, дающий "достаточные гарантии"?
> Не знаю. Можешь привести такой аудит для СИ или С++, я хоть
> посмотрю как оно оформляется.Эвангелисты c и с++ не насаждают безопасность, требовать назависимый аудит безопасности - дело добровольное, в отличии от.
>> Даже банальный двусвязанный список нельзя написать на safe Rust
> А еще на safe Rust нельзя вызывать дыряшечные функции.Одни эмоции! "Объективно"
Заметь, я не называл стандартные функции rust "дыряшечными". Это твои слова.
Я всего лишь на насаждение безопасности потребовал аудит кода стандартной библиотеки.
> К чему претензия, к "специально"?Да, чел специально написал функцию обфусцирующую segfault и использующую самописный null_mut и специально написанного крейта.
> Обычно код пишут _специально_.
Да, такой код случайно написать сложно.
> Но думаю, и в этом случае можно неспециально родить такого трансмутатора.
Не верю (с)
Я не видел еще программеров, которые случайно создали крейт, в котором полезли переопределять стд функции и подменять в своем коде.> Повторюсь, есть пример safe Rust, который портит память. safe == unsafe. ЧТД.
У человека была цель специально сломать проверку.
У него ушла неделя на обсуждения как это можно сделать.
Да он добился результата.
Надо ли это исправлять? Думаю нет - тут прям иллюстрация "хакер и солонка".
Будет ли это исправлено - возможно.>> Не знаю. Можешь привести такой аудит для СИ или С++, я хоть посмотрю как оно оформляется.
> Эвангелисты c и с++ не насаждают безопасность, требовать назависимый аудит безопасности - дело добровольное, в отличии от.Хахаха, т.е аудита нет и не было? Не то что я был сильно удивлен (с)
> Я всего лишь на насаждение безопасности потребовал аудит кода стандартной библиотеки.
Требуй) Можешь написать фича реквест или создать петиции.
Никто безопасность не насаждает - это твои больные фантазии.
Гугл никто не заставлял внедрять раст. Они сами так решили.
>Надо ли это исправлять? Думаю нет -Все это основано на очень старом и вроде пока единственном такого рода баге в компиляторе https://github.com/rust-lang/rust/issues/25860 .
Исправлять конечно надо, это явный баг компилятора.>тут прям иллюстрация "хакер и солонка".
Да случайно его получить очень сложно.
>Будет ли это исправлено - возможно.
Обещают когда доведут до ума https://rust-lang.github.io/rust-project-goals/2024h2/next-s...
Не страх, а внутренняя бюрократия. "Правило двух" называется. Просто тупая дискриминация по языковому признаку: https://chromium.googlesource.com/chromium/src/+/master/docs...
Ух какие страшные слова!
Прямо "дискриминация"
Ну так сделай НКО "дыряшки тоже важны" и подай на них в суд))Если в мой цех придет электрик без коврика и с какими то пассатижами обмотанными изолентой и полезет в цеховой распределительный щит, то я его просто выкину нафиг за забор.
Потому что для разной работы нужен разный инструмент.
Своим небезопасным овном пусть у себя дома в щитке ковыряется.
А в чём проблема этого правила? Вроде звучит как правильная техника безопасности для IT
В том, что точно так же как на C++ можно писать безопасный код, на Расте можно писать небезопасный (например используя ключевое слово unsafe, но не только).
> на C++ можно писать безопасный кодМожно, но не пишут. Поэтому считается небезопасным.
> на Расте можно писать небезопасный
Можно и пишут, но Раст считается безопасным.
Заговор?
> Можно, но не пишут.Пишут, и новость на самом деле о том, что если на C++ использовать правильные методологии разработки, то и количество ошибок связанных с памятью снизится в разы без всякого раста, которого в Хроме и так почти нет (кроме этого бесполезного генератора QR-кодов и ещё пары хеллоуворлдов).
> Пишут, и новость на самом деле о том, что если на C++ использовать правильные методологии разработки, то и количество ошибок связанных с памятью снизится в разы без всякого растаЭто ты так прочитал эту фразу
"Раннее выявление узявимостей через использование fuzzing-тестирования и инструментов, подобных AddressSanitizer и MemorySanitizer. Метод лишь устранял симптомы, а не причину болезни, и требовал постоянной работы."
?Даже MiraclePtr не стало решением - смогли отловить половину ошибок, ценой жора памяти и проца у юзера.
opennet.ru/opennews/art.shtml?num=60482
> если на C++ использовать правильные методологии разработкиЕсли
> если на C++ использовать правильные методологии разработки, то и количество ошибок связанных с памятью снизится в разыА почему не используют?
Они же тратят кучу денег на исправление и пере-исправление багов.
То ли заговор программеров, чтобы получать зарлату, то ли глупость человеческая.
> То ли заговор программеров, чтобы получать зарлату, то ли глупость человеческаяДа-да. Или массонский заговор, или меркурий не в той фазе.
А вот то, что, возможно, сами плюсы не годятся для того, чтобы сразу писать надежный код -- не, это бред какой-то.
Ну всего лишь нужно держать в памяти все сроки жизни лябд или помнить, какие объекты можно использовать в разных тредах, а какие нельзя. Или то, что нужно захватить правильный мьютекс, прежде чем модифицировать какое-нибудь значение будет написано в лучшем случае где-нибудь в комментарии в коде. Б - безопасность.
Когда проект перерастает хеловорд и над ним работают больше 10 человек и каждый в случайный момент времени эти волшебные мьютексы то убирает, то возвращает, начинаются чудеса.
> если на C++ использовать правильные методологии разработкиТак если компилятор к этому не принуждает, то и не используют. Люди - ленивые жопы.
>если на C++ использовать правильные методологии разработкиа еще есть и такие предложения:
https://www.opennet.dev/opennews/art.shtml?num=61878
> Пишут, и новость на самом деле о том, что если на C++ использовать правильные методологии разработки, то и количество ошибок связанных с памятью снизится в разы без всякого растаГугловцы писАли обратное, что мало помогает. Что они применяют всякие техники и методологии в сишных/плюсовых проектах. И кардинальный сдвиг в уменьшении ошибок по памяти в андроиде связывают не с этими техниками, а с применением ансейф-языков (в нативной системщине - раста). Потому что применяя эти же методологии в других (не андроидовских) сишных/плюсовых проектах они таких же больших сдвигов не увидали:
"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."
Выделю отдельно:
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
> Заговор?Нет, обычное стадное поветрие
> Заговор?Вот Rust не самообманывается и добавил конструкцию unsafe {}, читая код понятно, где у тебя небезопасно. Осталось добавить конструкцию backdoor {}, чтобы все притензии к языку исключить.
> Осталось добавить конструкцию backdoor {}Совсем палевно. Unsafe достаточно, для понимающих )
> Совсем палевно. Unsafe достаточно, для понимающих )Ну неявный unsafe void main () {unsafe {.....}} куда лучше (то есть Си), зачем продвигать явный unsafe (безопасТный rust) если нужен backdoor? Вероятно, психология фокусника, пока вы следите за руками ...
> Ну неявный unsafe void main () {unsafe {.....}} куда лучше (то есть Си), зачем продвигать явный unsafe (безопасТный rust) если нужен backdoor? Вероятно, психология фокусника, пока вы следите за руками ...Так бекдор хорош только пока о нем знаешь только ты.
А когда начинается проходной двор и начинают ложки пропадать...
И ты задумываешься "а не закрыть ли все нафиг и решать другими методами"?
> Так бекдор хорош только пока о нем знаешь только ты.Давно уже этими методами никто не пользуется, куда лучше методы PATRIOT Act (backdoor on-demand). А вы не заметили как только "известный фин" получил гражданство "соединенных индейцев", у него отпало желание на все указывать пальцем. Вот придут к нему с этим актом в Портленд, и он как настоящий "патрик", законопослушный, выполнит свой долг. И это не только у "индейцев".
> для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже чем для кода на C++При этом количество кода на С++ превышает количество кода на Rust на порядки. Как выдать желаемое за действительное, натягивая лису на глобус.
Есть такой способ анализа, как сравнение относительных показателей. Он применяется, когда абсолютные показатели несопоставимы. Удельный вес, проценты - это оно. Или в школе уже о таком не учат?
Удельный вес чего? Количество кода на расте по сравнению с количеством кода на C находится на уровне погрешности измерений и стремится к нулю. Поэтому все измерения подобного плана тождественны уровню "одна бабка сказала".
Да, примерно так.
Не важно на чём написана генерация QR, это редко используемый функционал который потребляет при работе пренебрежимо мало.
Я лично генерацией QR в бразуре ни разу не пользовался и не знал даже что оно там есть.
> Уже существующий код со временем становится более проверенным и безопасным, что делает не столь выгодными вложения в проекты по переписыванию существующего кода.А потом вылазит какая то вулна которой уже 15+ лет.
Потому что на все простое уже наткнулись и исправили.
(ну или можно оправдываться что это просто бекдор)))
Всё упирается в деньги. Если переписывание кода дороже последствий уязвимости – его не будут переписывать.M$ считала, что одна критическая уязвимость обходится компании в $270к. Имеет смысл задуматься о новом коде на безопасном языке.
Постоянно переписывать на новые версии раста это бесплатно?
> Постоянно переписывать на новые версии раста это бесплатно?А зачем постоянно переписывать?
Откуда у тебя такие фантазии?Можно просто фиксируешь Edition и пишешь себе бед не зная.
Ты хоть пару строк не нем написал или тебе пацаны во дворе рассказали?
Я недавно откопал свой первый проект на расте года 2018 ещё с 2015 эдишном. Скомпилировался и запустился растом 1.81 без проблем.Сяшечников с ПТСР надо пожалеть - они проецируют свой страх перед обновлениями версий GCC и LLVM, когда каждый мажорный релиз что-то перестаёт компилироваться.
Только эта фраза Хеллоу Ворлд никому не нужна даже тебе 6 лет была не нужна.
> Я недавно откопал свой первый проект на расте года 2018 ещё с
> 2015 эдишном. Скомпилировался и запустился растом 1.81 без проблем.Вы все врети! (с)
Тебя купил гугл и ты подтасовываешь результаты! (с)Чел, местные фанатики тебе не поверят, даже если ты бы проект сюда выложил.
Они просто не могут представить, что можно делать не через заднее место.> Сяшечников с ПТСР надо пожалеть - они проецируют свой страх перед обновлениями
> версий GCC и LLVM, когда каждый мажорный релиз что-то перестаёт компилироваться.И не только мажорным)
Помню при переходе ЖЦЦ 4.Х на 4.Y ломались некоторые хаки.А от когда в ядре по умолчанию сделали -Werror то вообще содом и гомора началась.
Пару лет назад бугурт был на отлично.
УАЗ "буханку" тоже с 1965 года не модернизируют. Он сразу хорошо получился.
Это не значит, что сразу хорошо получился. Это значит, что не могут. Горбатого только могила исправит, говорят в таком случае
> Постоянно переписывать на новые версии раста это бесплатно?Нет, конечно.
Но, Холмс, зачем это делать?
А зачем ПЕРЕписывать? Просто пофиксить баг - не? Не молодёжно? Надо тащить никому ненужный Ржу и всех насильно тыкать носом "у нас безопасная память"?
> А зачем ПЕРЕписывать? Просто пофиксить баг - не?Так не получается. Наверное место проклятое (с)
Вон у С++ число откатов изменений в результате выявления непредвиденных ошибок в два раза выше.
Т.е приходится один и тот же баг исправлять несколько раз.> Не молодёжно? Надо тащить никому ненужный Ржу и всех насильно тыкать носом "у нас безопасная память"?
Тебе не нужный, гуглу нужный.
Гугл пишет андроид, а ты комменты на форуме.
Как ты думаешь на чье мнение можно положить?))
> Вон у С++ число откатов изменений в результате выявления непредвиденных ошибок в два раза выше.Низкоквалифицированный подаван (типа тебя) тут же делает выводы "с++ плохой". Профи не будет делать поспешные выводы, пока не поймёт, что возможно главная ошибка - в индусах, которые пытаются после недельных курсов С++ писать серьёзный код. Извини, ты облажался.
> Тебе не нужный, гуглу нужный.
Так почему он свою Ржу ВЕЗДЕ СУЁТ?! Такая агрессивная реклама, ПРОДАВЛИВАНИЕ своего г----ноязыка, будто он реально чего-то стоит! Объяснение только одно - эта гуглопараша никому не нужна, но гуглу (по какой-то причине) очень хочется всех посадить на это ржаподелие.
> Гугл пишет андроид, а ты комменты на форуме.
И снова ты облажался. Я пишу программы, а гугл - рекламные тексты для Ржы. Ведроид - тот вообще на Жабе писан!
> Как ты думаешь на чье мнение можно положить?))
На ТВОЁ, очевидно! Нуб залезает на форум и пытается меня учить, используя даже не свои знания, а просто тыкая пальчиком КАК БЫ в авторитетов! хаха :)))) Ты жалок. Я сам пишу программы стократ лучше гугла. По кр мере не такие позорные, как Ведроид! Так что мне есть кого слушать - себя.
> Я пишу программы, а гугл - рекламные тексты для Ржы.Ты пишешь на опеньке, а гугл пишет хром и андроид для миллилардов девайсов.
Но при этом ты считаешь "эта гуглопараша никому не нужна"))
Тебе бы к врачу сходить, что ли... На лицо невероятное снижение когнитивных способностей.> Я сам пишу программы стократ лучше гугла.
Спасибо, чувак, если бы смех продлевал жизнь, то ты мне ее так нехило продлил))
Ну а весь твой коммент можно подытожить один коротким видосом
youtube.com/watch?v=ppVuYhsR8lo
> Низкоквалифицированный подаван (типа тебя) тут же делает выводы "с++ плохой". Профи не будет делать поспешные выводы, пока не поймёт, что возможно главная ошибка - в индусах, которые пытаются после недельных курсов С++ писать серьёзный код. Извини, ты облажался.Бла-бла-бла.
А по делу будет что-то?
Или ты у нас пишешь прямо из офиса гугла, окруженный (но пока не сломленный) танцующими индусами?> Так почему он свою Ржу ВЕЗДЕ СУЁТ?! Такая агрессивная реклама, ПРОДАВЛИВАНИЕ своего г----ноязыка, будто он реально чего-то стоит!
Ну у тебя пичот) Откуда столько агрессии?
В своем проекте (а андроид это детище гугла) они могут делать все что хотят. Вообще все.
Даже удалить репу или переписать на паскаль.
И это не их язык, они им просто пользуются. Как и остальные члены rust foundation типа AWS или майкрософта.> Объяснение только одно - эта гуглопараша никому не нужна, но гуглу (по какой-то причине) очень хочется всех посадить на это ржаподелие.
Постарайся получше и придумай более правдоподобную теорию заговора.
Говорят рептиоиды сейчас в моде.> И снова ты облажался. Я пишу программы, а гугл - рекламные тексты для Ржы. Ведроид - тот вообще на Жабе писан!
О, видно кексперта. Надеюсь программы ты пишешь получше.
А это что такое lwn.net/Articles/953116/ тоже жаба?> На ТВОЁ, очевидно! Нуб залезает на форум и пытается меня учить, используя даже не свои знания, а просто тыкая пальчиком КАК БЫ в авторитетов! хаха :)))) Ты жалок.
Стадию гнева (бомбления) ты уже прошел чуть выше, теперь стадия отрицания?
> Я сам пишу программы стократ лучше гугла.
> По кр мере не такие позорные, как Ведроид! Так что мне есть кого слушать - себя.Ахахаххаха! Пощади человек-петросян!
Ты же наверняка пишешь в опенсорс, может ссылку на репу дашь?
>возможно главная ошибка - в индусах, которые пытаются после недельных курсов С++ писать серьёзный код.А как так получилось, что граждане Индии пишут менее уязвимый код на Rust, чем на C++? Получается Rust можно более качественно освоить после недельных курсов? Если да, то тогда зачем бизнесу использовать C++?
Менее уязвимый только В ОДНОМ АСПЕКТЕ - возне с указателями (которую в C# даже не замечают). ВО ВСЁМ ОСТАЛЬНОМ индусокод остаётся таким же _овном.
То есть, это уже улучшение. Если они будут писать на C++, то не будет даже этого.
И этот один аспект убирает сразу 70% всех ошибок. Очевидно, овчинка стоит выделки, если принять в расчет среднюю стоимость исправления одной критической уязвимости, которую привели выше. Особенно учитывая, что наверное 99% критических уязвимостей вызваны именно этими 70% ошибок (работы с памятью).
Rust НЕЛЬЗЯ освоить на недельных курсах. И на месячных толком освоить тоже не получится. Разработка на нем сопряжена с периодическим прилетом нежданчиков, даже после того, как ты на нем что-то пишешь несколько лет (инфа 146%).
Смотря какие курсы, и что считать за освоение. Тот же C, C++ по такой логике (прилёт нежданчиков) вообще нельзя освоить, они, нежданчики, и спустя много лет прилетают, после старта разработки. Почему? Потому что в стандарте эти нежданчики записаны. Называются обычно UB.
> Просто пофиксить баг - не?Не. Потому что в соседней функции будет еще один баг.
А соседнем модуле, а не, в плюсы же еще не завезли модули, в соседнем файле - еще пару штук.
И будешь ты вычищать эти авгиевы конюшни годами. Разрабу наверное это хорошо - часы крутятся, зп мутится.
А вот заказчику... ну так себе.> всех насильно тыкать носом
О нет! Тебя ЗАСТАВИЛИ читать эту новость!
А тебя заставили писать комментарий. Начитался теперь таких новостей и как под гипножабой не можешь остановится защищать раст. Лучше бы код на расте написал что-ли.
> А зачем ПЕРЕписывать?Переписывать не надо.
В новости об этом буквально и написано: старый код выгоднее оставлять, новый код выгоднее писать сразу на новом языке.
Это ты лично просто пофиксишь, когда вернут. Есть "машина", работающая по определенным корпоративным стандартам. Наглядно разницу подходов можно увидеть в фильме 2023 года "Кто убил BlackBerry"
Ну тут нужно посмотреть кто считает, ибо если считал отдел по внедрению раста или менеджеры, нечистые на руку или что более ожидаемо - биржевые спекулянты, то о чём тут говорить - посчитали те, кому выгодно.
Ага, сплошной мировой заговор против плюсовиков и сишников.
если она вылазит раз в 15 лет, то и пускай вылазит.
> Например, 5-летний код в среднем имеет в 3.4 раза меньшую плотность уязвимостей, чем новый код.Но при этом не говорят о серьезности проблемы.
Всякий мусор типа "кнопка не того цвета" или даже "приложение крашится" естественно найдут быстро.Например грязная корова Dirty COW (CVE-2016-5195) жила 9 лет.
А эпическая Bashdoor была найдена в 2014, а сделана приблизительно в 1992.ИМХО такой подход слегка похож на самообман.
>> плотность уязвимостей
> не говорят о серьезности проблемы"Смотрю в книгу - вижу фигу"?
Тебе черным по белому написано, что серьезность проблемы - уровень "уязвимость". Какая еще "кнопка не того цвета", что ты несешь?
> "Смотрю в книгу - вижу фигу"?Да, и по тебе это заметно
> Тебе черным по белому написано, что серьезность проблемы - уровень "уязвимость".
Где?
Вот что пишут гугловцы
The answer lies in an important observation: vulnerabilities decay exponentially. They have a half-life. The distribution of vulnerability lifetime follows an exponential distribution given an average vulnerability lifetime λ:
security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.htmlИ такое пишут
For example, based on the average vulnerability lifetimes, 5-year-old code has a 3.4x (using lifetimes from the study) to 7.4x (using lifetimes observed in Android and Chromium) lower vulnerability density than new code.Ничего про "серьзность проблемы" там нет, только про возраст.
>> Тебе черным по белому написано, что серьезность проблемы - уровень "уязвимость".
> Где?Пять раз встречающееся слово vulnerability в приведенных тобой цитатах тебе ни о чем не говорит?
> Ничего про "серьзность проблемы" там нет
Действительно, какие-то там "вульнерабилитис". Наверняка это всякий мусор типа "кнопка не того цвета" или даже "приложение крашится".
Мда... до тебя все еще не доходит.
У cve есть градации. Это может быть CVSS Score или другая категоризация.
Напр. local code execution менее опасна чем remote code execution, а DoS обычно менее опасна чем code execution.
Так вот, в статистике выше нет информации про опасность cve.
>У cve есть градации.так и все же, какую градацию cve присваивают когда кнопка не того цвета?
>>У cve есть градации.
> так и все же, какую градацию cve присваивают когда кнопка не того цвета?Например 4.7 MEDIUM
СVE-2022-20214
"In Car Settings app, the toggle button in Modify system settings is vulnerable to tapjacking attack. Attackers can overlay the toggle button to enable apps to modify system settings without user consent"
тут про "tapjacking attack" и про "overlay the toggle button".
про очень даже правильный цвет, но другой кнопки.а где про неправильный цвет кнопки?
> про очень даже правильный цвет, но другой кнопки.
> а где про неправильный цвет кнопки?Clickjacking is an attack that occurs when an attacker uses a transparent button.
А clear color это уже не цвет?
>А clear color это уже не цвет?в случае "Clickjacking" clear color это именно тот цвет кнопки который автор и задумал.
тут вулна в том что кнопка вообще есть.
так что давай. ищи получше.
И да, "кнопка не того цвета" это конечно смешно.
Но пока этот цвет не прозрачный))
Иначе ты получаешь CVE-2022-20214
"In Car Settings app, the toggle button in Modify system settings is vulnerable to tapjacking attack. Attackers can overlay the toggle button to enable apps to modify system settings without user consent"
Base Score: 4.7 MEDIUM
И никому не мешало, как и куча других ошибок признаных уязвимостями.
В реальном мире всё точно так же, и решение для этого простое: страхование рисков.
>никому не мешалоА зачем пофиксили, если никому не мешало? Или под "никому" товарищ майор имеется ввиду?
Про кнопки не того цвета - это ты правильно подметил. Если "вдруг" красная кнопка запуска МБР станет зеленой, покрасится весь мир. Примитивные представления заурядных кодеров об устройстве мира порой поражают.
Убедили, теперь я перехожу на Rust. Этот язык кажется очень перспективным, и я готов изучить его.
Зависит от того чем ты занимаешься.
Если код не сильно требовательный к безопасности (написание игр на С++), то можешь забить, возможно оно того не стоитНу и если у тебя команда будет против - то тебя ждет печальная участь.
Если коду нужна безопасность памяти есть куча языков, питон, джава, джаваскрипт, Хаскель да даже кобол. У раста нет ниши, совсем.
Которые тормознутые как не знаю что.
А если тебе нужно и быстро, и безопасно? Что тогда?
Вот тогда берешь раст.> У раста нет ниши, совсем.
Повторяй это три раза в день перед зеркалом))
Вспоминаешь что не может быть быстро и безопасно. Тут или безопасная двуручная пила или бензопила. Безопасной бензопилы быть не может. Среди бензопил можно конечно взять не пилу дружба, а например Golang как лучшее из того что есть.
Аналогия не аргумент. Rust на этапе компиляции обеспечивает безопасную работу памяти, проверяя код. Asm команды при этом не будут отличаться от аналогичного (но корректного) кода на Си.
Обещает обеспечить путем запрета на мутации. Ты и на Си можешь перестать мутировать только ты ничего не напишешь годного. Ты и в акваланге можешь пробежать марафон 42 километра и не уточнить в случае потопа. Только ты не добежишь.
Утонуть*
> можешь перестать мутироватьНе могу, я уже гидралиск.
> Обещает обеспечить путем запрета на мутацииВо-первых обеспечивает, а во-вторых, запрета на мутации нет.
Ты бы хоть в общих чертах прочитал про раст. Два-три параграфа хватит, чтобы совсем чушь не говорить.> Ты и на Си можешь перестать мутировать только ты ничего не напишешь годного
Си не относится к подобным языкам, такое на нём делать неудобно. А другие языки - вполне себе. Раст, кстати, к ним не относится, он С-подобный.
Мне думается, говоря о запрете на мутации, он с Хаскеллем спутал.И то, это только в "каноничном" функциональном коде в Хаскелле нет мутаций, а если всё же вспомнить про монадки IO и ST, то с мутациями там всё в порядке, не хуже, чем на Сях.
Еще как может быть. Вот seL4 сделали быстрым и гарантировано безопасным, не смотря на то, что на си. Просто зарыли 11 человеколет в формальную верификацию.> Среди бензопил можно конечно взять не пилу дружба, а например Golang как лучшее из того что есть.
Вот как раз раст это и есть лучшее что есть на данный момент.
Почему же никто не использует раст, но все используют Golang?
> Почему же никто не использует растЛол. Прямо в новости написано что гугл использует!
Но в твоем манямирке - "никто не использует раст".> но все используют Golang?
Кто все? Гугл например?))
-"Смотрим в книгу видим фигу"?
Гугель рекомендует. Только все плевать на его рекомендации связанные с rust.
>все плеватьВсем местным неосиляторам и/или хейтерам? Кто бы сомневался.
>>все плевать
> Всем местным неосиляторам и/или хейтерам? Кто бы сомневался.Диды медленно запрягают, да быстро везут. Если заявили в С++ опции безопасной работы с памятью - в течении полугода уже что-то осмысленное выкатят.. А осиляторы rust (Хотя что там осилять, никто из адекватных просто не хочет вникать в неадекватный синтаксис, отсутсвие хоть какой то устоявшейся структуры языка и т.п.), как в сказке о золотой рыбке, после заявления "хочу быть владытчицей морскою" останутся у разбитого корыта, сглатывая концептуальные изменения выкатываемые rust разработчиками, и переписывая куски кода своих старых проектов в новые МОДНЫЕ концепции потому как проектировщики rust так захотели.
> Диды медленно запрягают, да быстро везут. Если заявили в С++ опции безопасной
> работы с памятью - в течении полугода уже что-то осмысленное выкатят..Ты это серьезно?
Диды медленно запрягают, да еще медленнее обсуждают.
Сколько там комитет С++ рожает фичи? Три года минимум надо пообсуждать.
В 26 стандарт оно уже не попало, в 30 сомнительно что попадет.> А осиляторы rust (Хотя что там осилять, никто из адекватных просто не хочет вникать в неадекватный синтаксис, отсутсвие хоть какой то устоявшейся структуры языка и т.п.),
О, начинается нытье про синтакс. Сразу видно что неосилил))
> сглатывая концептуальные изменения выкатываемые rust разработчиками, и переписывая куски кода своих старых проектов в новые МОДНЫЕ концепции потому как проектировщики rust так захотели.
И снова бредовые фантазии от человека, который не знает что такое Edition и как в расте сделана обратная совместимость /_-
> И снова бредовые фантазии от человека, который не знает что такое Edition
> и как в расте сделана обратная совместимость /_-Сглатывайте, сглатывайте малафью вместе с изучением обратной совместимости в одной версии с прямого, а потом с кривого.... Хехехе
Не может быть быстро, безопасно и быстро компилируемо. Компиляция долгая как раз для валидации, а в рантайме и быстро, и безопасно.
Golang везде быстро и безопасно. Да ещё и от гугл.
Не везде. Дискорд, что ли, в своё время отказался от Голанг в пользу Раст, потому что было небыстро.
> Golang везде быстро и безопасно. Да ещё и от гугл.Не спорю, быстро и безопасно, но... Про го, раст, плюсы и гугл, выжимка из выступления Ларса Бергстрома (технический директор Google) о разработке:
"Some additional context on these two specific claims:
Google found that porting Go to Rust "it takes about the same sized team about the same time to build it, so that's no loss of productivity" and "we do see some benefits from it, we see reduced memory usage [...] and we also see a decreased defect rate over time"
On re-writing C++ into Rust: "in every case, we've seen a decrease by more than 2x in the amount of effort required to both build the services written in Rust, as well as maintain and update those services. [...] C++ is very expensive for us to maintain."
"Так что при прочих равных раст имеет преимущество перед го в плане потребления памяти и меньше ошибочек в течение времени жизни проекта.
Ну кстати зиг пытается немного это изменить. Если они слезут с ллвм и научатся быстро патчить инкрементальные правки в бинаре напрямую,то может и раст задумается.
>А если тебе нужно и быстро, и безопасно? Что тогда?В книгах по менеджменту качества пишут, что качество продукции на 80% зависит от личных качеств работников, таких как ответственность, аккуратность, дисциплинированность, и только на 20% зависит от уровня профессиональных знаний работника и инструментов, применяемых ими.
Если вам нужно чтобы сделали быстро и качественно, надо набрать хороших работников.Если у Гугля такие большие проблемы с качеством его продуктов, то это говорит о неправильной кадровой политике Гугля
Поразительно, как из полной чуши ты умудрился сделать правильный вывод! :)))Да, кадровая политика гугли - ДНО. Но качество кода - это В ПЕРВУЮ очередь - квалификация! И только потом - какие-то эфемерные "дисциплины", о которых ты сам понятия не имеешь, но лепишь.
Можно сидеть ОДНОМУ, без каких-либо соц-пересечений и писать нормальный код.
>Можно сидеть ОДНОМУ, без каких-либо соц-пересечений и писать нормальный код.Уровня hello world? Вполне возможно. Но кому такой код нужен?
Всех хороших работников уже разобрали приходится работать с тем что есть.
А других - НАСТОЯЩИХ - сишников у меня для вас нету :).
Не, можно конечно этих на мороз и чатжопэтэ взять - но тут в перспективы раста мне пока больше верится.
> качество продукции на 80% зависит от личных качеств работников, таких как ответственность, аккуратность, дисциплинированность, и только на 20% зависит от уровня профессиональных знаний работникаЛол. Хирурга так себе выбери.
>если у тебя команда будет против - то тебя ждет печальная участьДесять программистов решили написать программу,
Но один из них любил Rust -
И их осталось девять
Один из девяти любил простые кремнивые пистолеты. Однажды ногу прострелил, и их осталось восемь.
Один из восьми запустил AFL и сломал мозги. И их осталось семь
> написание игр на С++Кстати, а покажи тогда чего могут современные ECS на крестах. Есть ли среди них настолько эргономичные и фичастые, как bevy_ecs? Примеры: https://github.com/bevyengine/bevy/tree/main/examples/ecs
Не позорься, готов ты. Прямо как журналисты, которые вечно пишут, что кто-то что-то собирается сделать. Собирается, только никак не соберётся.
100%Опасно то, что гугля создаёт информационный хайп, ЯКОБЫ "все" только и говорят, что о Расте. На деле про ржу только и пишут, что продажные журнашл_иу_шки, да маркетинговый отдел гугли.
Вместо графиков гугля лучше бы показал Хром, переписанный на Расте (ну и соотв. метрики - сколько это стоило по ср. с С++, кто и за сколько будет это Г сопровождать, сколько времени ушло на бизнес-логику, а сколько прыжки вокруг памяти и т.п.).
Надеюсь, у вас крепкие нервы :) Язык хороший и быстрый, но есть нюансы :)
Морально готовьтесь к периодическим "нежданчикам", когда то, что по вашему мнению должно нормально компилироваться, компилироваться не будет и придется вникать и разбираться, почему это происходит и как это обойти.
В Си и Плюсах эти нежданчики сидят прямо в стандарте (UB). Так что такое.
Нежданчик - это когда простые и, вроде как, понятные вещи внезапно демонстрируют совершенно неожиданное поведение, в плюсах такого практически нету. Вот пример последнего нежданчика:fn main()
{
// Рабочий вариант массива строк
let string_array_1: [&str; 3] = ["раз","два","три"];
// Еще один рабочий вариант массива строк
let string_array_2: [String; 3] =
[
"раз".to_string(),
"два".to_string(),
"три".to_string(),
];
// Массив пустых строк - в таком виде тоже работает
let string_array_3: [String; 3] =
[
String::new(),
String::new(),
String::new(),
];
// Массив пустых строк - создается три пустых строки
let string_array_4: [&str; 3] = [""; 3];
// А вот и нежданчик!
let string_array_5: [String; 3] = [String::new(); 3];
/*
for s in &string_array_1
{
println!("'{}'",s);
}
*/
}
> Исправление уязвимостей после их обнаружения.Андроид имеет еще одну особенность - часть систем получат секурити обновления примерно... никогда)))
Поэтому намного лучше вообще не сделать дыру используя Safe Coding подходы.
А не сделать, а потом латать, но не у всех.
Ещё особенность что там почти все джава, а она безопасно работает с памятью.
> В качестве примера приводятся показатели отката изменений - для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже чем для кода на C++.Это просто цирк. Зайдите в репозиторий исходников Хрома и сравните количество кода на C++ и его сложность (количество компонентов, которые взаимодействуют между собой) и на расте. На последнем там только парочка хелооуворлдов: https://github.com/search?q=repo%3Achromium%2Fchro...
Почиканный борров концептуально не даёт написать большой и сложный код. Все что он делает запрещает мутации при наличии любого алиаса на ссылке.
Собаки лают, а боров чекает.
...вместо написания кода.
> Все что он делает запрещает мутации при наличии любого алиаса на ссылке.В многопоточном коде, чтение данных в одном месте и отсутствие лока на запись в другом месте - это 100% проблема, причём плавающая, т.е. будет выявлена "когда-то". Если повезёт - в процессе разработки, не повезёт - "у нас критикал на проде".
У растоманов это будет ошибка компиляции, а кодерам на С/++ - удачи в рантайме!
Нет, это не 100%, такое может вообще никогда не вылезти в какую либо заметную проблему.
Если они пишут и читают из одной области памяти значение размером с регистр - то и лок там особо не нужен в принципе.
И есть конструкции на базе атомиков которые позволяют обходится без локов при одновременном чтении/записи из разных потоков, этому всему уже более 20 лет.В общем ситуации бывают сильно разные, вы похоже больше теоретик-фанатик чем тот кто реально сталкивался с написанием и отладкой многопоточных приложений на С.
> никогда не вылезти в какую либо заметную проблемуТ. е. проблема будет незаметной и её обнаружат только в CVE через 10 лет? Вот это да
> Нет, это не 100%, такое может вообще никогда не вылезти в какую либо заметную проблему.Ну если датарейс не гарантирован, то можно спать спокойно. Авось пронесёт.
data race и UB бояться - тогда вообще за программирование не следует браться.
А лучше, всё же, использовать подходящий язык программирования, чтобы не бояться.
ты не поверишь но в компиляторе есть опция включающая эту проверку в с++...
Я не поверю, точно. Вот допустим код:static char *static_str;
void foo(char* p) {
// как компилятор может здесь проверить, что строки p и static_str не пересекаются?
}Я могу придумать как такое проверить в рантайме -- можно померить длину обеих строк, и потом посмотреть не пересекаются ли диапазоны адресов, но это не то, что можно позволять делать компилятору, потому что для этого компилятор должен предполагать, что оба указателя указывают на null-терминированную строку, что может быть вовсе не моя задумка, так ведь?
Но ты говоришь, что компилятор это может проверить? Расскажи нам, как ему это удаётся. За счёт какой такой магии?
Ну вот поэтому гугля занимается РЕКЛАМОЙ своего недоРжы вместо того, чтобы переписать на нём Хром, к примеру! Или ведроид.
А... при чем тут хромиум? В новости речь про андроид.В андроиде на расте написаны всего лишь блютус стек, биндер и совсем неважная штука keystore2))
И это отдельные проекты, кроме которых есть еще где-то 1.5 ляма строк раст-кода минимум.
Но мне лень искать по их репе.
> А... при чем тут хромиум?действительно, при чем?
> Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust
Привели пример с переписыванием маленького компонента на раст в хромиум.
Ты полез смотреть _весь_ код хромого.Сам натянул сову, сам удивился.
Человек-оркестр.
> Ты полез смотреть _весь_ код хромого.Вот именно, что там кроме этого бесполезного хеллоуворлда на расте ничего толком и нет. Но безопасность при этом повысилась. Потому что новость не про то, как раст всех спас, а про то, что правильные методики программирования на C++ действительно работают. А сову на глобус натягивают фанаты раста.
> Но безопасность при этом повысиласьНет, безопасность не повысилась, она осталась прежней. Повысилась производительность на 95%.
Я понимаю, почему вам так сложно понять раст и его простые концепции. Если даже простую статью, написанную на простом языке, вы не можете усвоить, то куда уж до нового ЯП.
Хотя отсюда можно сделать вывод, что и других языков вы не знаете.Зочем спорите тогда? Спорт?
Как же ты хорошо всё понемаешь: и людей, и в программировании
> Нет, безопасность не повысилась, она осталась прежней
> Для проектов Android и Chromium благодаря внедрению методов безопасной работы с памятью разница составляет 7.4 раза.Докажи, что у тебя больше одного нейрона в голове и ты способен к этому добавить ещё и контекст того поста, который комментируешь, чтобы понять, что в случае с Хромом это не заслуга раста.
> В андроиде на расте написаны всего лишь блютус стек, биндер и совсем неважная штука keystore2))
> всего лишьТого что ты перечислил и так достаточно. Но главное сказать полуправду и даже её умалить и признать ничтожной.
А куда ты дел хотя бы те же DNS-over-HTTP3, Android’s Virtualization framework (AVF)?21% раста (два года назад) в новом коде нативной системщины в андроиде - это будет по-сложнее вашего наколеночного "Операционного Дня Банка" или твоих поделок на 1С или ковыряний в контроллерах.
А другие графики они не хотят показать? Как изменилась стоимость разработки? Сколько теперь нужно разрабов на тот же код. Может хотят показать сколько стоят убытки от сабжевых уязвимостей может быть нуль? Очевидно сабжевое исследование для хомячков у которых нет и не может быть нормального образования.
> Как изменилась стоимость разработкиМожет тебе еще "ключи от квартиры где деньги лежат" ?))
Хотя можешь прикинуть - для раст-кода кол-во регрессий в два раза реже.
Так что кроме разработки нужно учитывать еще и стоимость поддержки.
> Может хотят показать сколько стоят убытки от сабжевых уязвимостей может быть нуль?Не может быть нуль.
Тебе надо взять программеров и они потратят время на исправление, QA чтобы они это все проверили.
Нуль будет только в ситуации "нам пофиг wont fix" и то, какой-то PM или QA должен тикет записать, а потом закрыть.
Опять придуманные цифры. Реальность говорит лишь то что рефакторинг кода на расте невозможен как и большие проекты на нем. Иначе гугл бы не графики выдавал, а просто взял и переписал хром на раст.
> Иначе гугл бы не графики выдавал, а просто взял и переписал хром на растЗолотые слова!
К чему все эти МАРКЕТОИДНЫЕ убеждения для _программистов_?! Они что нас, за тупых считают? Программист верит только цифрам, причём не в графиках от "Леночки-маркетоидши", а в реальных проектах. А растаманы только и умеют, что ls, да dd переписывать! Перделки уровня 3 экранов.
> Реальность говорит лишь то что рефакторинг кода на расте невозможен как и... летательные аппараты тяжелее воздуха
... передача голоса по проводам
... потребность иметь компьютер дома> Иначе гугл бы не графики выдавал, а просто взял и переписал хром на раст.
Может денег жалко.
Если ты не заметил - то в статье про андроид.
И у них могут быть совершенно разные бюджеты.Но в 2023 году
We are pleased to announce that moving forward, the Chromium project is going to support the use of third-party Rust libraries from C++ in Chromium. To do so, we are now actively pursuing adding a production Rust toolchain to our build system.
This will enable us to include Rust code in the Chrome binary within the next year.
security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.htmlРабота ведется. Так что может и перепишут.
В Гугле про все работа ведётся только там проекты закрываются так же просто как и анонсируются.
У тебя (как и у многих молодых людей) слишком оптимистичный взгляд на жизнь.> Chromium project is going to support the use of third-party Rust libraries
Эту новость надо читать БУКВАЛЬНО: "Мы добавим в Хром возможность использовать внешние Ржа-библиотеки". ТОЧКА. Здесь НИЧЕГО не говорится ни о каком "переписывании", ни об интенсивности и широте внедрения этих библиотек, вообще ничего! Поэтому не надо прыгать вперёд кобылы и рисовать радужные облака - это просто "возможность использовать". И не хочешь - не используй! Только и всего.
ВОТ ТАКОЙ строгий, трезвый, инженерный взгляд должен быть у программиста. Это уже не говоря о том, что инженер просто обязан понимать, насколько ущербен Ржа для ИТ.
Ты вообще читал статью или тебя хватает только на газофикацию лужи?
Что тебе не понятно в моей фразе "Работа ведется. Так что может и перепишут."
Ты совсем глупый?Сейчас они используют либы. И юзер получит бинарь хромого вместе с раст кодом.
И чтобы собрать полностью с нуля, раст тоже придется собирать.
This will enable us to include Rust code in the Chrome binary within the next year.Причем не просто так.
Chrome relies heavily on third-party code, and we need to keep up with where that third-party investment is happening. It is critical that we build out support for including Rust into the Chromium project.Так что можешь играться словами, но в Chromium project раст уже есть.
> ВОТ ТАКОЙ строгий, трезвый, инженерный взгляд должен быть у программиста.
Которого я тут не вижу. А вот истерику и капс, вижу.
> Это уже не говоря о том, что инженер просто обязан понимать, насколько ущербен Ржа для ИТ.
Лол, судя по твоим висерам, ты даже на дворника не потянешь.
Аргументов ноль, зато пафосные "обязан понимать")
> инженер просто обязан понимать, насколько ущербен Ржа для ИТ.А можете ли вы развернуть эту мысль? Почему Rust наносит ущерб индустрии IT? Спрашиваю из интереса, цели спорить нет.
> А другие графики они не хотят показать?
> Как изменилась стоимость разработки?Уже показывали. Кратко: быстрее пишут, быстрее погружаются в проект. C++ разработчики также быстро осваивают Раст, в районе двух месяцев. Также C++ разработчики начинают лучше писать на, собственно, С++, после освоения раста. Это кажется очевидным для растомана, но не для стороннего наблюдателя.
> сколько стоят убытки от сабжевых уязвимостей может быть нуль?
Ты участвовал в продуктовой разработке? Хоть в какой-нить, хоть собственный персональный блог, где надо было фиксить что-то и куда-то выкладывать.
Как эти затраты, в принципе, могут быть нулевые? Они огромны.
>разработчики начинают лучше писать на, собственно, С++, после освоения раста.Объяснимо. Это они от страха что их снова заставят писать на Ржавом ))
Здравствуйте, Евгений Ваганович. Как сам, как дети?
>> 95% за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции.Ну если бы они убрали sandbox для C++ было бы быстрее rust, да даже pascal был бы быстрее. Маркетологи
> Ну если бы они убрали sandbox для C++ было бы много новых всеми любимых CVEПофиксил, не благодари.
Тебя CVE в детстве покусали или твои нюдсы украли через дыру?
> Тебя CVE в детстве покусали или твои нюдсы украли через дыру?О, а вот и первые эксгибиционисты подъехали /_-
Ну подумаешь твой комп, телефон или роутер взломают.
Или украдут данные и пароли, или частью ботнета сделают. А может просто rm -rf.
Дело то житейское. Диды терпели и нам завещали.
А может инопланетяне прочитают твой мозг и надо носить шапочку из фольги? Тебе поможет только длительное лечение под присмотром специалистов. Растом тебя уже не вылечить.
> А может инопланетяне прочитают твой мозг и надо носить шапочку из фольги?Ну раз ты веришь в инопланетян и шапочки из фольги, то зачем тебя вообще слушать?
Пруфов от тебя все равно не будет.
А издеваться над убогими.. мне совесть и воспитание не позвоялет.
Диды не терпели. Глобальных сетей тогда не было - терпеть было нечего.
Диды на дискетах сами переносили. Чё-то OneHalf вспомнился. Ностальджи.
Так чево же не убрали? Мозгов не хватило?
Иди, посоветуй им.
Подсказка: там не только для qr-кодов песочницы, там их много.
Давай, ускорь хромого парой патчей, раза в два.
Я сегодня добрый, поэтому потрачу чуток своего времени, чтобы пролить свет реального знания на ваше невежество.
Итак, проект на Rust, по умолчанию, компилируется в режиме --debug, в котором в него включается куча дополнительных проверок. В таком виде код действительно может работать медленнее, чем написанный на Си, Си++ или GoLang. Про Паскаль не знаю - я им не пользовался и тесты не проводил.
Все меняется, когда мы компилируем код в режиме --release. Он становится необычайно быстрым. Настолько, что мне удавалось обойти по производительности оптимизированный на скорость код, написанный на чистом Си (который был примерно на 300% быстрее решения на Си++, основанного на STL и скомпилированного с -O2).
За счёт чего? Только за счёт автоматического __restrict__, или дополнительные гарантии позволяют применять ещё какие-то оптимизации?
>В общем виде Google рекомендует не переписывать старый код, а сосредоточиться на написании нового кодаизвините меня, а кто же тогда финансирует переписывание coreutils, findutils, tls, sudo и т.д., разве не Гугль?
Ты перечислил ГНУ утилиты. Гугл, как и всякий корпораст старается держаться подальше от копилефта.
То-то все они так дружною толпою держаться очень далеко от кернела Linux.
>>рекомендует не переписывать старый кодПравильно, пусть старые бэкдоры продолжают работать так, как работали. Как говорится "работает - не трогай"
Просто появилась ГоПоТа, которая очень хорошо находит утечки памяти и не проверяемые вводные данные. Она очень жестко патчит код if (!writebuf) конструкциями.
Именно, и это главная причина почему не надо переходить на Раст. Через годик все уязвимости запросто найдет ИИ и в нем просто отпадет всякий смысл.
Краткое содержание комментариев вышеВот когда Mozilla будет использовать Rust, тогда и поговорим
Вот когда Dropbox будет использовать Rust, тогда и поговорим
Вот когда Amazon будет использовать Rust, тогда и поговорим
Вот когда Cloudfare будет использовать Rust, тогда и поговорим
Вот когда Google будет использовать Rust, тогда и поговорим
========== вы находитесь здесь ==========
Вот когда я не смогу собрать ядро без RustНу и еще немного бугурта))
В дропбоксе нет раста там только Го. Мозилла должна была переписать движок на раст. Но серво до сих пор не может без зависания корректно отобразить простейшую страницу с формой. В клаудфлере код на сто строк на расте, а рекламы на миллион. В Гугле проекты на уровне генерация qr кода там вообще десять строк. Вся твоя лапша на ушах давно протухла.
Да не мешай ему мечтать, лежа на диване.
Ладно бы он сам хоть что-то коммитил в поделки на расте, но чую что максимум видеоуроки смотрел на ютубчике.
> В дропбоксе нет раста там только Го.Вот как раз в Dropbox переписали лет 8 назад код хранилища с Го на Раст, и оно стало в разы быстрее и перестало зависать на время работы GC.
Ты разве не читал этот блог-пост?
> В дропбоксе нет раста там только Го.Итак в левом углу у нас Всезнающий Аноним, а в правом Дропбокс.
Открываем их бложик dropbox.tech и читаем:
Rewriting the heart of our sync engine
dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync-engine
Какой жестокий удар!Но, аноним не сдается и продолжает гнуть свою линию.
Идем дальше
Why we built a custom Rust library for Capture
dropbox.tech/application/why-we-built-a-custom-rust-library-for-captureКекспертность Всезнающего Анонима на уровне ПТУ животноводства!
Это просто душераздирающее зрелище!
-Ты здесь-
-никогда-
Вот когда Любимая корпорация будет использовать Rust везде
И чтобы Rust смог заменить C++, должен появиться Rust_с_классами.
Довожу до вашего сведения, что в Rust есть структуры и есть возможность привязать к этим структурам методы. И есть возможность регулировать видимость на уровне модуля. И все это из коробки может использовать абстрактные типы.
Т.е., фактически, мы имеем функционал, аналогичный действительно важным возможностям шаблонных классов из Си++.
Этот список с начала уже начал подгнивать. Mozilla выставила команду Раста на улицу, а Серво выпрашивает пожертвования чтобы не помереть окончательно. У остальных по списку тоже нет подвижек, даже Гугл отказался переписывать старый код потому что он (внезапно) и так безопасен.
> Mozilla выставила команду Раста на улицуМозилла поувольняла плюсовиков тоже. Так что это просто показатель подгнивания самой мозиллы.
Тем не менее, код на расте они писать продолжают и использовать: authenticator-rs, neqo, webrtc-sdp, application-services.> даже Гугл отказался переписывать старый код потому что он (внезапно) и так безопасен.
Он был также дыряв как и новый на си. Просто за за годы, ценой тысяч человекочасов, большинство дыр из него вычистили. И повторять такую ошибку они не хотят, поэьтому новый пишется хорошо сразу.
> У остальных по списку тоже нет подвижекОга, знаток ойтишечки. Например, та же клаудфларя уже более года использует Pingor'у, выкинув nginx на свалку и нарадоваться не может. Но Знатокам-наСИльникам с опеннета всё всегда не так или "нинужно" или "они все врут" или "это хелловрот". Ну что такое эти ваши пингора с нгинксом - тьфу и растереть, убогий хелловорд, правда? Ты за один вечер обычно по три таких пишешь на сишечке. И конечно по методикам, а потому без ошибок и безопасно.
>Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительности на 95% за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции.Кто же им доктор! Я не представляю, зачем sandbox-изолировать сериализацию (не путать с десериализацией).
Видимо, даже это не получится написать без опасности выйти за границы или переосвободить память.
Извините, у меня нет нематерных слов, чтобы прокомментировать такое.
Это факт, из за того что последние годы больше внимания уделяют всяким статическим анализаторам я уже и забыл когда в Федоре что то падало. Имена разработчиков ключевых знал, багзиллу и рассылки мониторил. Причём это все на самом деле "тихо и незаметно". Раньше наизусть длиннющие пароли багзиллы вбивал лихо, переживал как там мой багрепорт может что то спрашивают и надо потестировать. Недавно приспичило и всё - бумажка с паролем засалилась упала за стол и не прочитать треть букв кранты аккаунту. И самое главное новый незачем создавать - да оно просто работает . Скучно как то. А что будет когда ядро переведут на микроядерное с этими самыми проверками теоремами или как их там. Realtime в ядре следующем. Будущее светло и прекрасно.
>В общем виде Google рекомендует не переписывать старый код, а сосредоточиться на написании нового кода на языках безопасно работающих с памятью и обеспечении переносимости между новым и старым кодом.
>Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительностиВзаимоисключющие параграфы обнаружены
> Взаимоисключющие параграфы обнаруженыГде?
"В общем виде Google рекомендует не переписывать"
Возможно генератор QR-кодов не попал в эту категорию и его было проще переписать, чем исправить.
>и его было проще переписать, чем исправитьТогда нужно другую формулировку - "не переписывать, а заменять на новый код". Поскольку сейчас это "стой там иди сюда".
Оставлю тут, а то у модера крит. дни.> А если аппа падает с SIGABRT'ом?
> Или удаляет пользовательскую базу?
> Это дело ИБшников или программер просто криворукая камака?Все это может происходить от неопределенного поведения, а что у вас в мат формулах должно происходить при делении на 0, если вы это деление не определили строго? В чем вина программиста, если ваша вычислительная архитектура заведомо не безопасна?
> Мне казалось что деньги можно просить за корректно написанный код. За овнокод
> просить что-то вообще неприлично.просят - попрошайки! А "корректно написанный код" - должен быть подвергнут верификации (валидация), а теперь фокус - чтобы это проделать, необходимо иметь спецификацию (эталон) того кода, который программист "накодит" на том или ином безопасТном ЯП. И как вы, я думаю догадались, верификация так же не в ходит в обязанности программиста, как и вопросы связанные с безопасностью этого кода.
> Все это может происходить от неопределенного поведенияА может и не происходить)
Может пограммист думал во время работы как подкатить к красивой коллеге из отдела маркетинга и забыл прибавить индекс.
Или просто использовал не тот тип, как было например с курлом
- socksreq[len++] = (char) hostname_len; /* one byte address length */
+ socksreq[len++] = (unsigned char) hostname_len; /* one byte length */
https://www.opennet.dev/opennews/art.shtml?num=59909Но ты и дальше можешь пороть чушь.
> как было например с курломНу и у кого он "попросил" за этот кусок кода денег? что захотел то и написал, в чем проблема? У вас что-то пошло не так из-за этого кода? Так это ваша проблема.
> Но ты и дальше можешь пороть чушь.
По вашим просьбам :)
а эта картинка, как раз адресована вам!https://daniel.haxx.se/blog/wp-content/uploads/2024/07/Danie...
Проблема rust не в том, хороший он или плохой, языков много и разных. Проблема в том, что фанаты rust не хотят сами писать на rust, они хотят окружающих заставить на нём писать.
> Проблема rust не в том, хороший он или плохой, языков много и разных.Думаю ты поддельный дед)
> Проблема в том, что фанаты rust не хотят сами писать на rust, они хотят окружающих заставить на нём писать.
Эээ? Вон гугл сам пишет.
Как и в теме про POSIX и декодировщик AV1. Там ребята сами взяли и переписали.
Но аноны все равно не довольны.
>Думаю ты поддельный дед)Не, это только борода у меня приклееная, а свитер с вытянутыми рукавами самый что не на есть настоящий
>Как и в теме про POSIX и декодировщик AV1. Там ребята сами взяли и переписали.
>Но аноны все равно не довольны.Ну что тут скажешь - переписали - молодцы! Не понятно, какую проблему они при этом решили, оставив весь asm, но я как настоящий дид, за кодинг ради кодинга, а там хоть на brainfuck
> Ну что тут скажешь - переписали - молодцы! Не понятно, какую проблему они при этом решили, оставив весь asm,Уменьшили кол-во кода, где может быть баг по памяти, на кол-во строк написанных в safe rust.
Например до АСМа код, читающий юзерский ввод или аргументы из командной строки просто не дойдет, в случае если там будет какая-то чушь.> но я как настоящий дид, за кодинг ради кодинга, а там хоть на brainfuck
О! а это здравый подход, уважаемо.
Но все равно не понятно? почему другие анонимы так горят, от того что гугл в своем проекте какие-то эксперименты проводит ¯\_(ツ)_/¯.
И какой смысл от этого переписывания?? Переписали потенциально безопасные участки кода на rust, оставив потенциально опасные в оригинале?
Красавцы.. Хехехе.. Как звезднополосатые, если им выгодно - называют белое черным и наоборот..
> Переписали потенциально безопасные участки кодаС чего это код на дыряшке стал "потенциально безопасным"?
Может "теоретически небезопасным"? Или "если повезет безопасным"? Или даже "мамкой_клянусь_там_нет_cve безопасным"?Вот они и переписали потенциально дырявый код на безопасный rust. А асм не трогали.
Но все равно буде не хуже чем в оригинале. Потому что оригинал использует тот же асм.
> Как и в теме про POSIX и декодировщик AV1. Там ребята сами взяли и переписали.Ну да, просто взяли и переписали?) Цитаты из той новости:
> не планирует обеспечивать совместимость с утилитами GNU, функциональность которых воспринимается авторами как необоснованно раздутая
> В настоящее время 55 развиваемых проектом утилит соответствуют POSIX и находятся на стадии покрытия тестами, в 22 утилитах обеспечена необходимая функциональность (но пока не реализовано покрытие тестами), 20 находятся на стадии чернового варианта, а работа над 44 утилитами ещё не начата.
> не планирует обеспечивать совместимость с утилитами GNUТо есть не планируют становится полноценной заменой? Ну хоть честно заявили.
> они хотят окружающих заставить на нём писатьНу и всякие "святые диды" в "крестовые походы" не ходили.
Да никто не ходит, все на диване сидят. rust даже близко не подошел и не подойдет чтобы дидов с дивана сорвать... :))
Ну так наверно они бы еще хотели чтобы за это им ещё и платили. Вопрос денег вроде не самый последний и это уже не к обществу которое не хочет на нем писать, а к работодателям, которые н ее хотят дать.
Ну и славно, ждём Safe C++ и не паримся.
Угу. Осталось всего лет 10.
Или пятнадцать. Смотря как быстро комитет будет чесаться.
Но вот как только примут, так ух! нужно будет дождаться поддержки в компиляторах.
А вот тогда и наступит вселенское счастье!
Так уже работа идет во всю, пригласили талантливых ребят.
https://www.opennet.dev/opennews/art.shtml?num=61878
Сроки от этого не станут короче.
>For example, memory safety bugs are effectively prevented by memory-safe languages such as Java, Go, and Rust.Вкратце, чтобы не читать их пдфки.
> Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительности на 95% за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции.Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее всяких растов. Во-вторых, на кой там скорость? Вывод: очередные желтые новости. Переписали бы тогда подсистему изоляции как раз на расте.
> Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее
> всяких растов. Во-вторых, на кой там скорость? Вывод: очередные желтые новости.Это того самого ядра которое дырявое и бедняга Торвальдс ноет что за 33 года даже memory management не осилили?
Из андроида выкинули io_uring как раз про причине "высокой калификации" разработчиков ядра.
opennet.ru/opennews/art.shtml?num=59297> Переписали бы тогда подсистему изоляции как раз на расте.
Может и перепишут. А может нет.
>> Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее
>> всяких растов. Во-вторых, на кой там скорость? Вывод: очередные желтые новости.
> Это того самого ядра которое дырявое и бедняга Торвальдс ноет что за
> 33 года даже memory management не осилили?Ссылки в студию!
> Из андроида выкинули io_uring как раз про причине "высокой калификации" разработчиков ядра.
> opennet.ru/opennews/art.shtml?num=59297Причем тут урина? И почему по ней ты судишь обо всех?
>> Переписали бы тогда подсистему изоляции как раз на расте.
> Может и перепишут. А может нет.Ну вот в том то и дело, что переписывают всякую ерунду. Понятно почему.
> Ссылки в студию!Torvalds mentioned that even though Linux is 33 years old now, "You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management."
zdnet.com/article/linus-torvalds-talks-ai-rust-adoption-and-why-the-linux-kernel-is-the-only-thing-that-matters> Причем тут урина?
Потому что она часть ядра и при этом ее выкинули из андроида.
А о какой компании и каком продукте вообще эта новость?))> И почему по ней ты судишь обо всех?
Потому что остальное принимают такие же, если не те же, люди, что и принимает остальные части ядра.
> Ну вот в том то и дело, что переписывают всякую ерунду.
Так в системе изоляции разве есть проблемы? Может она вообще на java написана, я не проверял.
Но на что бы ты ее не переписал - накладные расходы на сам сендбоксинг останутся.
>> Ссылки в студию!
> Torvalds mentioned that even though Linux is 33 years old now, "You'd
> think that all the basics would have been fixed long ago,
> but they're not. We're still dealing with basic issues such as
> memory management."
> zdnet.com/article/linus-torvalds-talks-ai-rust-adoption-and-why-the-linux-kernel-is-the-only-thing-that-mattersА что это если не желтизна? Что ты умолчал, что это было сказано ответ по поводу помощи AI?
>> Причем тут урина?
> Потому что она часть ядра и при этом ее выкинули из андроида.
> А о какой компании и каком продукте вообще эта новость?))Не надо дурака включать. Обязательно все использовать из ядра? В uring есть проблемы, вот и выкинули. А что на раст не переписали тогда?)
>> И почему по ней ты судишь обо всех?
> Потому что остальное принимают такие же, если не те же, люди, что
> и принимает остальные части ядра.Учасник разработки? В больших проектах обязанности поделены. Далеко не все разрабы ревьювят все.
>> Ну вот в том то и дело, что переписывают всякую ерунду.
> Так в системе изоляции разве есть проблемы? Может она вообще на java
> написана, я не проверял.Ну дак ты проверь.
> Но на что бы ты ее не переписал - накладные расходы на
> сам сендбоксинг останутся.Вот мы возвращаемся с чего начали. Зачем мне в генерации QR кодов какая-то скорость? Надо генерить 1000 QR кодов в секунду?
> А что это если не желтизна? Что ты умолчал, что это было сказано ответ по поводу помощи AI?Что? Где там AI?
Там предыдущий абзац про real-time Linux project.
Ты вообще читать умеешь?
> Обязательно все использовать из ядра? В uring есть
> проблемы, вот и выкинули. А что на раст не переписали тогда?)Почему не переписать? Потому что закостенелые диды всеми силами пытаются не пустить раст в ядро.
> Далеко не все разрабы ревьювят все.
А про всех речь и не шла. Но такие все равно есть.
> Ну дак ты проверь.
Зачем? Еще раз - любой сендбоксинг добавляет накладных расходов.
А код на расте - нет.> Вот мы возвращаемся с чего начали. Зачем мне в генерации QR кодов
> какая-то скорость? Надо генерить 1000 QR кодов в секунду?Действительно! Зачем скорость если можно тормозить и жрать батарейку сендбоксом.
Вопросов больше нет...
>> Обязательно все использовать из ядра? В uring есть
>> проблемы, вот и выкинули. А что на раст не переписали тогда?)
> Почему не переписать? Потому что закостенелые диды всеми силами пытаются не пустить
> раст в ядро.Правильно делают. Можно же патчи наложить свои. Но не делают. Для всех очевидно почему кроме фанатов раста.
>> Ну дак ты проверь.
> Зачем? Еще раз - любой сендбоксинг добавляет накладных расходов.
> А код на расте - нет.он небезопасен, уже выше это обсудили. Раст != изоляции.
>> Вот мы возвращаемся с чего начали. Зачем мне в генерации QR кодов
>> какая-то скорость? Надо генерить 1000 QR кодов в секунду?
> Действительно! Зачем скорость если можно тормозить и жрать батарейку сендбоксом.
> Вопросов больше нет...Замеры есть? Давайте тогда выкинем изоляцию совсем.
> Правильно делают. Можно же патчи наложить свои. Но не делают. Для всех очевидно почему кроме фанатов раста.Ты Торвальдса туда же записываешь или "это другое"
> он небезопасен, уже выше это обсудили. Раст != изоляции.
Изоляция != безопасноть.
Подтверждается кучей багов с выходом из сендбоксинага.
А вот код на расте безопаснее чем код на СИ или плюсах - показано гуглом.
>> Правильно делают. Можно же патчи наложить свои. Но не делают. Для всех очевидно почему кроме фанатов раста.
> Ты Торвальдса туда же записываешь или "это другое"Что ты хочешь с него, он же на зп корпорастов сидит. Крутится как может, вот уже ругаться в рассылках ему запретили. Надо смотреть на тех, кто не сидит и говорит что хочешь.
>> он небезопасен, уже выше это обсудили. Раст != изоляции.
> Изоляция != безопасноть.Facepalm Закачнивай уже сравнивать разные уровни. Не важно на чем написан софт (то, за что топишь ты), его следует запускать в изоляции (то, за что топлю я).
> Подтверждается кучей багов с выходом из сендбоксинага.
Багов, которые обошли сэндбокс, сильно меньше. Доказано гулом (с).
> А вот код на расте безопаснее чем код на СИ или плюсах
> - показано гуглом.Каким местом? Ты не графики смотри рекламные, а открой код проекта и посмотри кол-во кода на С++ там по сравнению с другими.
> Facepalm Закачнивай уже сравнивать разные уровни. Не важно на чем написан софт
> (то, за что топишь ты), его следует запускать в изоляции (то, за что топлю я).А на чем у тебя будет написан софт, эту изоляцию обеспечивающий?
Пока получаем такие великолепные новости:
Уязвимости во FreeBSD, позволяющие повысить свои привилегии или обойти изоляцию гостевой системы
opennet.ru/opennews/art.shtml?num=61838
>> Facepalm Закачнивай уже сравнивать разные уровни. Не важно на чем написан софт
>> (то, за что топишь ты), его следует запускать в изоляции (то, за что топлю я).
> А на чем у тебя будет написан софт, эту изоляцию обеспечивающий?Без разницы. То, на чем проще собрать и сделать бутстрапинг. Я бы хотел видеать на guile scheme :)
> Пока получаем такие великолепные новости:
> Уязвимости во FreeBSD, позволяющие повысить свои привилегии или обойти изоляцию гостевой
> системы
> opennet.ru/opennews/art.shtml?num=61838Опять же если брать в пример гугл, то посмотри сколько они платят за обычную уязвимость в хроме и сколько за обход сэндбокса.
>>> Facepalm Закачнивай уже сравнивать разные уровни. Не важно на чем написан софт
>>> (то, за что топишь ты), его следует запускать в изоляции (то, за что топлю я).
>> А на чем у тебя будет написан софт, эту изоляцию обеспечивающий?Ну и в целом. Софт для изоляции конечный по функционалу. Софт, который запускается - нет. Первую часть проще сделать. Это как (простите) обеспечить безопасность WASM, чем всего кода, который будет там запускаться.
> Без разницы. То, на чем проще собрать и сделать бутстрапинг.Странно что слова "надежность" в твоих требованиях я не увидел.
А хотя... не, не странно.
Вот на чем БСДя написана? Там и бутстрапинг есть и собарать легко.
А толку)?
Может если ее писали бы на АДА, то работало бы оно без таких "особенностей"> Я бы хотел видеать на guile scheme :)
Можешь попробовать написать.
> Опять же если брать в пример гугл, то посмотри сколько они платят
> за обычную уязвимость в хроме и сколько за обход сэндбокса.Естественно за сендбоксинг больше.
Но если он будет не нужен, без потери качества, то можно будет платить меньше.
> Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее всяких растов.Неее, sandbox не для тех случаев. Он не для того, чтобы программерские баги исправлять, а для того чтобы недоверенный код крутить. Насчёт будет ли надёжнее, тут мне сложно сказать. Может если таким костылём использовать, обороняясь от своей неспособности писать надёжный код и исходя из того что злоумышленной активности не будет, будут просто глупости, то может и надёжнее.
>> Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее всяких растов.
> Неее, sandbox не для тех случаев. Он не для того, чтобы программерские
> баги исправлять, а для того чтобы недоверенный код крутить.Если так думать, то все процессы в системе доверенные и можно и без изоляции жить.
> Насчёт будет ли надёжнее, тут мне сложно сказать. Может если таким костылём использовать,
> обороняясь от своей неспособности писать надёжный код и исходя из того
> что злоумышленной активности не будет, будут просто глупости, то может и
> надёжнее.Что такое "надежный код"? Формально верифицированный? Боюсь тебя тогда расстроить, что весь код в твоей системе с большой вероятностю ненадежный. К тому же и формально верифицированном коде есть баги реализации.
> Если так думать, то все процессы в системе доверенные и можно и без изоляции жить.Они доверенные, во всяком случае те, которые ты из репов дистра ставишь, но они бажные, то есть не надёжные.
> Что такое "надежный код"? Формально верифицированный?
У тебя путаница тут просочилась. Надёжный код, это код на который можно положиться. Который выполнит то, что ему следует выполнить, и ничего другого. А формальная верификация один из инструментов достижения надёжности, а вовсе не определение надёжного кода.
> весь код в твоей системе с большой вероятностю ненадежный.
Ты так говоришь, будто возомнил что какое-то великое и неизвестное мне открытие до меня доносишь. Это общее знание, которым владеет любой хомячок.
> К тому же и формально верифицированном коде есть баги реализации.
И ты конечно же можешь накидать примеров таким багам реализации в формально верифицированном коде? Или ты в дополнение к предыдущей путанице заодно путаешь выводы из своих умозрительных рассуждений с фактами? Если так, то ты осторожнее, ты в одном шаге от того, чтобы полагаться на циклические логические цепочки.
>> Если так думать, то все процессы в системе доверенные и можно и без изоляции жить.
> Они доверенные, во всяком случае те, которые ты из репов дистра ставишь,
> но они бажные, то есть не надёжные.'Вообще нет. Нельзя доверять.
>> Что такое "надежный код"? Формально верифицированный?
> У тебя путаница тут просочилась. Надёжный код, это код на который можно
> положиться. Который выполнит то, что ему следует выполнить, и ничего другого.
> А формальная верификация один из инструментов достижения надёжности, а вовсе
> не определение надёжного кода.Ну тогда предложи как проверить надежность, а не абстрактные определения. Или хочешь сказать, что код на расте по умолчанию надежен?) Но вот нет.
>> весь код в твоей системе с большой вероятностю ненадежный.
> Ты так говоришь, будто возомнил что какое-то великое и неизвестное мне открытие
> до меня доносишь. Это общее знание, которым владеет любой хомячок.Видимо ты нет раз пишешь чушь.
>> К тому же и формально верифицированном коде есть баги реализации.
> И ты конечно же можешь накидать примеров таким багам реализации в формально
> верифицированном коде? Или ты в дополнение к предыдущей путанице заодно путаешь
> выводы из своих умозрительных рассуждений с фактами? Если так, то ты
> осторожнее, ты в одном шаге от того, чтобы полагаться на циклические
> логические цепочки.Да легко. Читай любая криптография формально верифицирована, но в реализации есть куча багов.
> Вообще нет. Нельзя доверять.Что ж ты тогда запускаешь его, если нельзя доверять? А?
Хочешь я скажу тебе, почему ты это делаешь? Потому что, во всей этой цепочке поставки программ от непосредственных разработчиков и через мейнтейнеров, довольно сложно проталкивать злоумышленный код. И поэтому ты доверяешь этим программам работать на твоём компе без всяких там сандбоксов. Ты не запускаешь их из-под рута, но от этого тебя останавливают другие опасения, типа чуть не то сделал, и всю систему похоронил, то есть ты от себя защищаешься таким образом. То есть у тебя есть некая модель угроз, и ты оцениваешь с её точки зрения, насколько можно доверять софту.
Но затем, чтобы выглядеть не желтоклювым наивным юнцом, но прожжёным циничным мужем, ты говоришь "вообще нет, нельзя доверять", несмотря на то, что жить согласно этой максиме ты даже не пытался, и когда дело доходит до дела, ведёшь себя как тот самый желтоклювый наивный юнец.
> Ну тогда предложи как проверить надежность, а не абстрактные определения.
Нет 100% способа проверить надёжность. Если вкратце, полнота по Тьюрингу под ногами путается, если более подробно, то тебе сюда: https://pron.github.io/posts/correctness-and-complexity
Иногда, в некоторых случаях проверить можно. И не в смысле потыкать палочкой, "не падает? => надёжно", а в смысле взять и доказать. Иногда можно. Но для этого требуется очень специфически писать код, так чтобы на порядки снизить сложность доказательств. И то, не гарантия, что удастся доказать.
И вот на этом моменте, люди говорят "идеальная надёжность конечно хорошо", но... И начинают выдумывать модели угроз, и проверять надёжность в каком-то ограниченном варианте. Но даже если речь пошла об этом, не получится ставить знак равенства между формальной верификацией и надёжностью.
> Или хочешь сказать, что код на расте по умолчанию надежен?)
Нет, не хочу. Почему вдруг ты подумал, что я хочу такое сказать?
> Читай любая криптография формально верифицирована, но в реализации есть куча багов.
Не канает за пример, у тебя опять путаница из головы полезла. То что алгоритм формально верифицировали, а потом написали наотвали реализацию этого алгоритма пригодную для практики -- это не формальная верификация программы, это формальная верификация алгоритма. Формальная верификация программы -- это формальное доказательство того, что программа соответствует определённым свойствам. Если мы говорим про крипту, то это их какие-то криптографические свойства.
>> Вообще нет. Нельзя доверять.
> Что ж ты тогда запускаешь его, если нельзя доверять? А?Я запускаю в изоляции много софта.
> Хочешь я скажу тебе, почему ты это делаешь? Потому что, во всей
> этой цепочке поставки программ от непосредственных разработчиков и через мейнтейнеров,
> довольно сложно проталкивать злоумышленный код.Ха-ха-ха. Мейнтейнеры тебе код анализируют что-ли? Да большинство бинари просто перекладывают и то хорошо. Как по твоему уязвимости в пакеты попадают, а потом еще и обновления по security каналам этих же пакетов приходят?
>> Ну тогда предложи как проверить надежность, а не абстрактные определения.
> Нет 100% способа проверить надёжность. Если вкратце, полнота по Тьюрингу под ногами
> путается, если более подробно, то тебе сюда: https://pron.github.io/posts/correctness-and-complexityУ тебя путаница в опеределниях. Зачем ты говоришь про надежность, а кидаешь ссылки на корректность? Для тебя это одно и тоже?
>> Читай любая криптография формально верифицирована, но в реализации есть куча багов.
> Не канает за пример, у тебя опять путаница из головы полезла. То
> что алгоритм формально верифицировали, а потом написали наотвали реализацию этого алгоритма
> пригодную для практики -- это не формальная верификация программы, это формальная
> верификация алгоритма.Нормальный это пример. Да даже если делать все как ты говоришь, то баг может быть вообще в используемой библиотеке. А все это к чему приводит? К тому, что нужна изоляция.
> Формальная верификация программы -- это формальное доказательство
> того, что программа соответствует определённым свойствам. Если мы говорим про крипту,
> то это их какие-то криптографические свойства.Ну вот написали реализацию, свойства соблюдены. А cve все равно вылезло.
Нужно более тесное сотрудничество разработчиков архитектуры процессоров, ОС и средств разработки - все это по сути складывается в одну систему.
И ко всему этому обязательно:
>> использование языков программирования, обеспечивающих безопасную работу с памятью, применение статических анализаторов и проектирование API с оглядкой на безопасность.В целом во многих языках есть вполне безопасные подходы.
Ада тоже не идеально, как оказалось. В конечном счёте, корпоративный программист -- это слабое звено. Наиболее безопасным и протестированным является си, теперь ещё спарк добавился. Но писать прикладуху ты ни на том ни на другом не захочешь (и никого не заставишь).
> Наиболее безопасным и протестированным является сиОн же дырявый как сито!
> Ада тоже не идеально, как оказалось
Потому что на ней писать сложнее чем 6ыдлокодить на сишке.
Что тогда, что сейчас нужно хк-хк-и-в-прод.
А на сишке можно научить писать даже обезьяну. Вот такое PHP 90х.Кроме того у Ада были "сложности" с компилятором - нужно было соответствовать требованиям и проходить тесты чтобы называться "компилятор Ада". А для си можно было что угодно назвать "компилятор си"
Весь критический софт ищется на си уже много десятилетий. Проблема не в языке. Ну теперь ещё пишется на ада и транслируется в си. Может быть, дело в том, что писать качественный код скучно и неудобно.
> Весь критический софт ищется на си уже много десятилетий.Хм.. может проблема в том, что чистый СИ плохо подходит для критического софта?
Т.к для реально надежных систем приходится вводить доп. ограничения типа MISRA.
Strictly conformance убивается наличием хотя бы одного UB.
А ты видел программу на СИ без UB))?
Но на безопасность можно и забить, у нас же софт AS IS.> Проблема не в языке.
Неа, как раз именно в языке, раз приходится вводить кучу правил и ограничений, и например запрещать динамические аллокации.
Т.е для серьезных проектов подходить только очень маленькое подмножество языка, да еще и с жесткими ограничениями.Я уже молчу про то, что банальная смена компилятора может поменять работу программы.
> Ну теперь ещё пишется на ада и транслируется в си.
"теперь"? На аде пишут с 80х.
И ее создание это пример как нужно делать ЯП.
Чего только стоит запрет выпускать трансляторы языка, не прошедшие официальную процедуру тестирования на соответствие стандартам (1000+ тестов).> Может быть, дело в том, что писать качественный код скучно и неудобно.
Или дорого. А побыстрячку набацать код просто.
Spark это gcc, так что "теперь" это не "тогда", да и провалы учтены. А что до си, ограничения всё равно необходимы. Это типичные ограничения встраиваемых устройств, ничего сверхъестественного. Т.е. возможность избегать ошибок вполне существует. Или дёшево пиши эффективный код, но ошибки будут.
> Нужно более тесное сотрудничество разработчиков архитектуры процессоров, ОС и средств разработки - все это по
> сути складывается в одну систему.
> И ко всему этому обязательно:
>> использование языков программирования, обеспечивающих безопасную работу с памятью...А, Вы про Apple со свифтом? Вы их маркетолог?
Не вижу графиков сравнения производительности FLOPS/MHz, SpecInt/MHz
А тож понапихают ковно года на растишке, а ты покупай новые грелки воздуха
> переписывание в Chromium кода для генерации QR-кодов на языке Rust
> позволило добиться повышения его производительности на 95% за счёт
> избавления от накладных расходов, вызванный необходимостью применения
> дополнительной sandbox-изоляции.У меня на С и X API, QR код генерился 150 мкс, на ущepбном AMD Geode!!!
Это было лет 10 назад, тогда люди еще не знали что такое QR
>> переписывание в Chromium кода для генерации QR-кодов на языке Rust
>> позволило добиться повышения его производительности на 95% за счёт
>> избавления от накладных расходов, вызванный необходимостью применения
>> дополнительной sandbox-изоляции.
> У меня на С и X API, QR код генерился 150 мкс,
> на ущepбном AMD Geode!!!
> Это было лет 10 назад, тогда люди еще не знали что
> такое QRТакс. Выведите его из зала, он нам всех распугает.
вспомнился видос с жириком, Валера ну че ты ждешь, выведи его вон отсюда, вы посмотрите на его глаза, шизоид :)))
Не знаю, о чем споры. Гугель в итоге рекомендует "языки программирования, обеспечивающие безопасную работу с памятью", а вовсе не только Раст.
Тогда почему не C#??!
Потому что гц
А зачем гуголю рекламировать поделку конкурента.
Я бы на месте гугла подумал не как убедить писать на Rust а почему на нем до сих пор все не пишут, если это так круто. Может синтаксис настолько гавно, что писать на нем можно либо если ты любитель bdsm либо из под палки(рабство оно всегда работает).
Вот вам для примера немного c и c++
char *(*(**foo[][8])())[];
[&, i]{};
[=, *this]{ };
std::cout << var.property << "123\n";
printf("%d %s\n", a, b);
Красота!
Сколько лет комментарии на опеннете читаю, каждый раз недоумеваю: что им не так с синтаксисом раста? Причём, в англоязычной среде таких жалоб вообще не помню. А синтаксис C++ мне всегда казался кошмарным, ещё лет 25 назад, без всяких предвзятостей к нему.Меня в расте только точка-с-запятой как разделитель утверждений бесит, без неё код был бы заметно чище. Но так она и в Си есть.
А не, ещё подбешивает #[xxx(…)] - пальцеломная конструкция. В java/kotkin/scala/python оно сильно удобнее через @xxx(…)
В порядке бренда, а-ля теория заговора.
А если уязвимость целенаправленно внедрить в компилятор. Правда для этого нужно чтобы для языка была всего одна версия компилятора. Получится чудовищное количество уязвимого кода, а если язык ещё и супер безопасный, то уязвимый код ещё и без изоляцией будет запускаться.
> А если уязвимость целенаправленно внедрить в компилятор.Сложно. Придется работать с кучей народу, плюс всякие Ferrocene будут тебе под руку заглядывать.
Проще уже найти либу которая используется везде и внедрить туда какой-то бекдор.
Типа XZ или CUPS.
Причем бекдор может быть какой-то очень простой - ну забыли проверить входные параметры, это же с любым может случиться.> Правда для этого нужно чтобы для языка была всего одна версия компилятора.
Но для раста как минимум 2 бекенда (llvm и cranelift) и есть альтернативные "фронты" - mrustc.
> Получится чудовищное количество уязвимого кода, а если язык ещё и супер безопасный, то уязвимый код ещё и без изоляцией будет запускаться.
Так сейчас и так куча уязвимого кода.
>Правда для этого нужно чтобы для языка была всего одна версия компилятораДавайте посчитаем, насколько велика монокультура на десктопе среднестатистического линуксоида:
- GNU - отсутствует. Существуют, например, дистрибутивы с busybox, хотя эта реализация недотягивает по функционалу.
- Linux - огромна. Есть ещё FreeBSD на основе которых есть несколько десктопных вариантов, но они не настолько доработаны. Остальные системы типа Hurd не пригодны к использованию.
- Systemd - отсутствует. Существют дистрибутивы с другими системами из коробки. Если линуксоид умеет писать хотя-бы скрипты на bash, то он сможет дописать недостающие сервисы
- Xorg - черезвычайно огромна. Замены практически нет. Есть несколько вариантов с Xenocara, но переход даже на неё проблематичен.
- Wayland - отрицательна. Большой зоопарк примерно равных вариаций. Есть заброшенные проекты.
- LLVM - огромная. Если clang может быть и получится заменить на gcc, то llvm ir - нет.
- Chromium - огромная. Некоторые сайты криво написаны и работать в Firefox не будут, некоторые сайты специально препятствуют работе в Firefox и нужно подменять user agent. Если же брать и не chromium и на firefox, то остальные движки сильно отстают
- Python - огромная. Не смотря на то, что python это всего лишь очередной скриптовый язык, удаление с компьютера python зацепит огромное количество других программ.
- Glibc - средняя. Некоторый софт без glibc не соберётся, некоторый будет работать неправильно. Пускай и не глобально, но glibc поставить придётся
- git - черезвычайно огромна. Альтернативы сущетвуют, но вытесняются git-ом. Например, BitBucket отказался от Mercurial в 2020.
Только вот удивительно, вопрос альтернативы git анонимов не волнует. Или возможность, например использовать Freon из Chromium OS.
>Получится чудовищное количество уязвимого кодаКонечно, crates.io - просто свалка кода, доверять которому нельзя, поэтому в будущем эта проблема решится так же, как с Java, то есть фирмы, которые делают деньги на Rust toolchain'е (типа Ferrocene и AdaCore) будут поставлять свои Rust-компиляторы с репозитарием проверенных наиболее часто используемых библиотек.
> Конечно, crates.io - просто свалка кода, доверять которому нельзя,А если я нахожу какую-ту либу на гитхабе?
Ну типа SQLite, FFMPEG или libwebp, как определить это классная либа или просто дырявый выпрограммыш каких-то дилетантов?> поэтому в будущем эта проблема решится так же, как с Java, то есть фирмы, которые делают деньги на Rust toolchain'е (типа Ferrocene и AdaCore) будут поставлять свои Rust-компиляторы с репозитарием проверенных наиболее часто используемых библиотек.
Звучит классно.
Хотя скорее будут смотреть по звездочкам или отзывам коллег)
>как определить это классная либа или просто дырявый выпрограммышесли эта либа есть в репозитарии Debian - значит хорошая.
>Звучит классно
я хотел сказать, что с Java'ой же точно такая же проблема, и она решена. AxiomJDK поставляется с репозитарием проверенных библиотек, если надо какую-то другую библиотеку - делается запрос, её проверяют и добавляют в репозитарий.
>>как определить это классная либа или просто дырявый выпрограммыш
> если эта либа есть в репозитарии Debian - значит хорошая.Хаха, скорее она старая и дырявая.
Например этот забагованый кусок https://packages.debian.org/stable/web/squid"Squid выявлено 55 уязвимостей, 35 из которых пока не исправлены"
opennet.ru/opennews/art.shtml?num=59915
Есть нехилый шанс, что они никогда их не починят "Разработчики Squid были уведомлены о проблемах ещё два с половиной года назад, но так и не завершили работу по их устранению."> AxiomJDK поставляется с репозитарием проверенных библиотек, если надо какую-то другую библиотеку - делается запрос, её проверяют и добавляют в репозитарий.
Интересно, почему с либами на СИ и плюсах такого нету.
То ли они сразу надежные (хехе), то ли просто плевать на качество.
>если эта либа есть в репозитарии Debian - значит хорошая.Дебиан это свалка устаревших версий без поддержки.
https://packages.debian.org/buster/php7.3 7.3.31
https://www.php.net/eol.php 7.3.33
Они молча не осилили поднять на две версии. Сколько вообще таких пакетов в дебиане - открытый вопрос
>В общем виде применение безопасных методов программирования преподносится как наиболее эффективная на сегодняшний день парадигма разработкиБедные Вирт, Хоар, Дейкстра всю жизнь убеждали индустрию в преимуществе надёжных языков и методов программирования, а индустрия над ними только смеялась. И вот только сейчас, после их смерти, индустрия поняла, что, оказывается, надёжное программирование - это выгодно
> Бедные Вирт, Хоар, Дейкстра всю жизнь убеждали индустрию в преимуществе надёжных языков и методов программирования, а индустрия над ними только смеялась.Не правда.
Например АДА создавалась как язык для военки с повышенными требования надежности.
И делали его соответствующе - сначала собирали требования, а уже потом пилили язык.
А когда выпустили, то разрешали впускать компиляторы, только после прохождения тестов (1000+ штук).Но распространение получила СИшка - язык для быстрого бдлокодинга, такой себе ПХП из 70х.
Почему? Потому что на качество было плевать, как и сейчас.> И вот только сейчас, после их смерти, индустрия поняла, что, оказывается, надёжное программирование - это выгодно
Еще нет)
Пока поняли отдельные компании которые теряют деньги и пользователей.
Те, кто привык делать бесплатно, но тяп-ляп, думаю еще долго рассказывать "ну работает же! ну иногда падает и дарит рут.. ну и чё?"
C Адой всё понятно - создавалась по госзаказу для госнужд. С остальным согласен. Си и Unix сделали два программиста just for fun. Linux тоже just for fun. А теперь все мучаются с этими любительскими проектами
>Си и Unix сделали два программиста just for fun. Linux тоже just for fun. А теперь все мучаются с этими любительскими проектамиЧто за бред? Кто мучается? Кто заставляет?
> Вирт, Хоар, Дейкстра... только сейчас, после их смерти...Хоар ещё жив.
> Изменения позволили снизить долю связанных с памятью уязвимостей в Android c 76% в 2019 году до 24% в 2024 году, что значительно ниже среднего показателя по индустрии - 70%.Напомню, в начале 2000ых этот же гугл говорил что java все сделает безопасным. В итоге андройд стал одной из самых дырявых систем. Прямо как сейчас с растом.
> Для проектов Android и Chromium благодаря внедрению методов безопасной работы с памятью разница составляет 7.4 раза.
Сильное утверждение. Проверять я это конечно не буду. Существует 2001 способ как подбить статистику.
> Таким образом, если предотвратить появление ошибок при работе с памятью в новом коде, со временем в старом коде подобные ошибки будут выявляться всё реже и реже.
Логическая ловушка. Событие А не гарантирует Б, а только возможно при многих допущениях.
> Помимо снижения числа уязвимостей использование безопасных методов программирования повышает производительность разработки, позволяет добиться более высокого качества кода и положительно сказывается на производительности.
Производительность против безопасности это классический трейдофф. Либо в гугле научились нарушать законы физики, либо кто-то опять врет.
> Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительности на 95% за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции.
Что говорит только о качестве предыдущей sandbox-изоляции. Опять логическая ловушка. Из А не следует Б.
> В качестве примера приводятся показатели отката изменений - для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже, чем для кода на C++.
Тоже простор для манипуляций. Кода на расте существенно меньше и вероятно он более свежий и применяется в менее важных подсистемах. Можно предположить что случайный код на С++ против случайного кода на расте имеет гораздо меньшее количество откатов чем в 2 раза.
Примерно как в типичном дипломе: Намешаны кони, люди - и раст и методы безопасной работы с памятью и все это вместе смешали, помухлевали статистикой, поподбирали примеры. И вот студент уже гордо заявляет что без раста жить нельзя. В основном по той причине что его руководитель выбрал ему такую тему работы. Через год другой студент получит другую тему и также гордо будет заявлять что раст то не безопасен оказывается, а вот на хрясть2 нужно немедленно перейти, потому что менеджеры в гугле уже получили за него премии...
Как это недавно сказал Торвальдс на выступлении в Австрии: капризные сишники нехотящие переходить на раст напоминают ему холиварящих студентов, как в его молодости.
