Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Методы безопасной работы с памятью позволили существенно снизить число уязвимостей в Android"	+/–
Сообщение от opennews (?), 26-Сен-24, 13:10
Компания Google подвела итоги инициативы по  внедрению в Android методов безопасной разработки (Safe Coding), таких как использование языков программирования, обеспечивающих безопасную работу с памятью, применение статических анализаторов и проектирование API с оглядкой на безопасность. Изменения позволили снизить долю связанных с памятью уязвимостей в Android c 76% в 2019 году до 24% в 2024 году, что значительно ниже среднего показателя по индустрии - 70%... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61933
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от полураспад (?), 26-Сен-24, 13:10
как они в ядре хотят в новом коде гарантировать
Ответить | Правка | Наверх | Cообщить модератору

3. "Методы безопасной работы с памятью позволили существенно сни..."	+10 +/–
Сообщение от Аноним (-), 26-Сен-24, 13:16
> переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительности на 95% Неплохо, весьма неплохо. А что же скажут хейтеры? "QR коды ненужны"? > для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже чем для кода на C++ О, вот как работает парадигма "хорошо делай - хорошо будет". Жаль не сравнили с кодами на СИ, было бы интересно глянуть.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 13:17
	> Жаль не сравнили с кодами на СИ, было бы интересно глянуть. Так это для новых кодов. А гугл на сишке нового практически ничего не пишет. Поэтому и сравнения не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Методы безопасной работы с памятью позволили существенно сни..."	–2 +/–
	Сообщение от Аноним (120), 26-Сен-24, 15:54
	Почти годный вброс, можно было бы поверить, если допустить, что "старый код" никогда не был "новым", что "новый код" появился только в 2024-м, а в 2010...2015... (и ранее) новый код не появлялся, а всё "диды в 70-х написали" и вся статистика по ошибкам, в том числе и в "новом коде" (который сейчас уже старый, но когда-то был новым), канула в черную дыру. Ваапще непонятно тогда, откуда гугл с мелкомягкими взяли число в 70% ошибок с памятью, если в новом коде их почти нет, а в старом всё уже вылизано и переписывать не надо. Заговор какой-то.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Alexander Istcaev (?), 26-Сен-24, 16:47
	Какой не сообразительный человек. Под нлвым кодом гугл подразумевает, как код который нужно написать с нуля, с того момента когда у них была принята эта парадигма
	Ответить | Правка | Наверх | Cообщить модератору

	308. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (120), 28-Сен-24, 19:32
	Какой не сообразительный человек. В 2010...2015... годах (а также и до и после этих годов) у них тоже был код на си/плюсах, написание которого начиналось с нуля и который остался в системах контроля версий. И ошибки, исправляемые в нём, так же остались в истории и статистике. Есть с чем сравнивать кол-во ошибок в старом "новом коде" и новом "новом коде", даже если глупо предположить, что нового "нового кода" на си и плюсах они не пишут.
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Alexander Istcaev (?), 29-Сен-24, 04:41
	Рука лицо. На пальцах. Код написаный на си с нуля, страдает большим количеством ошибок. Которые со временем исправляются. Код написанный с нуля по принятому методу, снижает количество ошибок на начальном этапе. Это уже сравнили и подвели статистику. А почему 2015 или 2010. Может взять 1995 год, тоже наверника статистика есть и сравнить скорость разработки и количество ошибок на си и незнаю, с питоном из 2024го или растом из 2024го, да даже си в 2024м будет выигрывать. Подобные иследования делаются не просто так паралельно.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (8), 26-Сен-24, 13:27
	> позволило добиться повышения его производительности на 95% как всегда избирательное цитирование, художественная резьба по цитатам. Самое главное: > за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции. Язык программирования тут не при чём, тут главное страх: раньше всего боялись, теперь не боятся, эмоциональное поведение.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	12. "Методы безопасной работы с памятью позволили существенно сни..."	+11 +/–
	Сообщение от Анонимусс (-), 26-Сен-24, 13:30
	> Язык программирования тут не при чём Еще как причем. Тот, на котором был написан старый код, не давал достаточных гарантий. Поэтому его необходимо было сендбоксить. А новый дает достаточные гарантии. Поэтому его сендбоксить не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (8), 26-Сен-24, 13:38
	> достаточные гарантии Это объективно измеримое значение или субъективная эмоциональная оценка?
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Анонимусс (-), 26-Сен-24, 14:05
	> Это объективно измеримое значение Разумеется. Напр. считаешь кол-во CVE на 1000 строк кода на дыряшке, плюсах и на расте. Сравниваешь два числа. Выкидываешь дыряшку на мороз сразу, плюсы обмазываешь санитайзерами.
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Методы безопасной работы с памятью позволили существенно сни..."	–2 +/–
	Сообщение от Аноним (222), 27-Сен-24, 00:15
	Так посчитай и сравни, а пока только голословно вбрасываешь. Только того техдира Гугла оставь уж в покое )) Это уже некроданные в 2024.
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Советский инженер (ok), 27-Сен-24, 08:13
	>Так посчитай и сравни, а пока только голословно вбрасываешь. пока голословно вбрасываеш ты. А гугл посчитал и сравнил. так что давай, показуй иную сравнимую кодобазу и опровергай выводы гугла.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Методы безопасной работы с памятью позволили существенно сни..."	+4 +/–
	Сообщение от Аноним (38), 26-Сен-24, 14:01
	Я частично согласен, что language matters, но главный, кто лепит ошибке в коде - это ЧЕЛОВЕК. Если нанимаешь индусов, то они и на пестоне навалят багову кучу. Нельзя быть тупым и одновременно "хорошо кодить за счёт языка"! КВАЛИФИКАЦИЯ должна быть высокой, ПРОГРАММИРОВАНИЕ - ЭТО СЛОЖНО. А каждый индус, продающий свои курсы "С++ за неделю" утверждает обратное - "каждая обезьяна может кодить!". Ну так "код от обезьян" мы и наблюдаем!! Я вот код пишу - у меня КРАЙНЕ редко какие-то ошибки связаны с памятью! (спасибо C# ) Если какой-то клоун с недельными крусами сядет за C#, можешь тушить свет - этот код можно сразу нести на помойку. А sandbox'инг - это вообще за гранью разумного: "вместо квалифицированных специалистов, пишущих правильный код, мы возьмём обезьяну, но завернём её код в песочницу" - гениально!! :))) СМЫСЛ?? Баги так же и останутся (ввиду изначально низкой квалификации разрабов), песочница лишь предотвратит сегфолт.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	207. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Продавец (?), 26-Сен-24, 22:38
	Там вся идея в том что на расте при всём желании якобы не накосячишь с памятью.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Александр (??), 27-Сен-24, 01:30
	Якобы. Да, падать sigsegv'ом не будет. Но утечки памяти, утечку данных, некорректную работу - это никто не отменял.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Проходил мимо (?), 27-Сен-24, 07:54
	На Rust без использования unfase блоков накосячить с памятью? Не будет ли любезен уважаемый Продавец привести пример такого кода?
	Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

	249. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Аноним (8), 27-Сен-24, 09:09
	https://github.com/Speykious/cve-rs > written in 100% safe Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (-), 27-Сен-24, 12:08
	> https://github.com/Speykious/cve-rs >> written in 100% safe Rust. Отличный пример того, что для создания уязвимости на Раст нужно - собрать целый консилиум github.com/Speykious/cve-rs/issues/4 - неделю мучать код - написать свой null_mute используя transmute И только тогда в расте можно получить cve-rs В общем Воины-Супротив-Раста опять обделались
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (8), 27-Сен-24, 12:29
	> И только тогда в расте можно получить cve-rs Был показан пример кода с "#![deny(unsafe_code)]", который портит память. Это "достаточая гарантия"? Если залезть внутрь стандартной библиотеки, там unsafe над unsafe погоняет. Есть независимый аудит стандартной библиотеки, дающий "достаточные гарантии"? Даже банальный двусвязанный список нельзя написать на safe Rust. https://doc.rust-lang.org/1.81.0/src/alloc/collections/linke... И этот язык лезет в системные языки со своими "достаточными гарантиями". > В общем Воины-Супротив-Раста опять обделались Привет Миротворец-Насильно-Насаждающий-Безопасный-Раст, видящий только обделавшихся
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 12:43
	> Был показан пример кода с "#![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 behavior For 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.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (8), 27-Сен-24, 13:06
	> Т.е если не писать специальный код, то да, это "достаточая гарантия". К чему претензия, к "специально"? Обычно код пишут _специально_. Разве что, когда пишут, не приходя в сознание, тогда, да, пишут не _специально_. Но думаю, и в этом случае можно неспециально родить такого трансмутатора. Повторюсь, есть пример safe Rust, который портит память. safe == unsafe. ЧТД. >> Если залезть внутрь стандартной библиотеки, там unsafe над unsafe погоняет. Есть независимый аудит стандартной библиотеки, дающий "достаточные гарантии"? > Не знаю. Можешь привести такой аудит для СИ или С++, я хоть > посмотрю как оно оформляется. Эвангелисты c и с++ не насаждают безопасность, требовать назависимый аудит безопасности - дело добровольное, в отличии от. >> Даже банальный двусвязанный список нельзя написать на safe Rust > А еще на safe Rust нельзя вызывать дыряшечные функции. Одни эмоции! "Объективно" Заметь, я не называл стандартные функции rust "дыряшечными". Это твои слова. Я всего лишь на насаждение безопасности потребовал аудит кода стандартной библиотеки.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 13:23
	> К чему претензия, к "специально"? Да, чел специально написал функцию обфусцирующую segfault и использующую самописный null_mut и специально написанного крейта. > Обычно код пишут _специально_. Да, такой код случайно написать сложно. > Но думаю, и в этом случае можно неспециально родить такого трансмутатора. Не верю (с) Я не видел еще программеров, которые случайно создали крейт, в котором полезли переопределять стд функции и подменять в своем коде. > Повторюсь, есть пример safe Rust, который портит память. safe == unsafe. ЧТД. У человека была цель специально сломать проверку. У него ушла неделя на обсуждения как это можно сделать. Да он добился результата. Надо ли это исправлять? Думаю нет - тут прям иллюстрация "хакер и солонка". Будет ли это исправлено - возможно. >> Не знаю. Можешь привести такой аудит для СИ или С++, я хоть посмотрю как оно оформляется. > Эвангелисты c и с++ не насаждают безопасность, требовать назависимый аудит безопасности  - дело добровольное, в отличии от. Хахаха, т.е аудита нет и не было? Не то что я был сильно удивлен (с) > Я всего лишь на насаждение безопасности потребовал аудит кода стандартной библиотеки. Требуй) Можешь написать фича реквест или создать петиции. Никто безопасность не насаждает - это твои больные фантазии. Гугл никто не заставлял внедрять раст. Они сами так решили.
	Ответить | Правка | Наверх | Cообщить модератору

	276. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Ф1 (?), 27-Сен-24, 16:15
	>Надо ли это исправлять? Думаю нет - Все это основано на очень старом и вроде пока единственном такого рода баге в компиляторе https://github.com/rust-lang/rust/issues/25860 . Исправлять конечно надо, это явный баг компилятора. >тут прям иллюстрация "хакер и солонка". Да случайно его получить очень сложно. >Будет ли это исправлено - возможно. Обещают когда доведут до ума https://rust-lang.github.io/rust-project-goals/2024h2/next-s...
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Методы безопасной работы с памятью позволили существенно сни..."	–2 +/–
	Сообщение от Аноним (14), 26-Сен-24, 13:33
	Не страх, а внутренняя бюрократия. "Правило двух" называется. Просто тупая дискриминация по языковому признаку: https://chromium.googlesource.com/chromium/src/+/master/docs...
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	23. Скрыто модератором	+2 +/–
	Сообщение от Аноним (-), 26-Сен-24, 13:44
	Ух какие страшные слова! Прямо "дискриминация" Ну так сделай НКО "дыряшки тоже важны" и подай на них в суд)) Если в мой цех придет электрик без коврика и с какими то пассатижами обмотанными изолентой и полезет в цеховой распределительный щит, то я его просто выкину нафиг за забор. Потому что для разной работы нужен разный инструмент. Своим небезопасным овном пусть у себя дома в щитке ковыряется.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (49), 26-Сен-24, 14:11
	А в чём проблема этого правила? Вроде звучит как правильная техника безопасности для IT
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	54. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (14), 26-Сен-24, 14:14
	В том, что точно так же как на C++ можно писать безопасный код, на Расте можно писать небезопасный (например используя ключевое слово unsafe, но не только).
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Методы безопасной работы с памятью позволили существенно сни..."	+4 +/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 15:01
	> на C++ можно писать безопасный код Можно, но не пишут. Поэтому считается небезопасным. > на Расте можно писать небезопасный Можно и пишут, но Раст считается безопасным. Заговор?
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (14), 26-Сен-24, 15:17
	> Можно, но не пишут. Пишут, и новость на самом деле о том, что если на C++ использовать правильные методологии разработки, то и количество ошибок связанных с памятью снизится в разы без всякого раста, которого в Хроме и так почти нет (кроме этого бесполезного генератора QR-кодов и ещё пары хеллоуворлдов).
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (-), 26-Сен-24, 15:20
	> Пишут, и новость на самом деле о том, что если на C++  использовать правильные методологии разработки, то и количество ошибок связанных с памятью снизится в разы без всякого раста Это ты так прочитал эту фразу "Раннее выявление узявимостей через использование fuzzing-тестирования и инструментов, подобных AddressSanitizer и MemorySanitizer. Метод лишь устранял симптомы, а не причину болезни, и требовал постоянной работы." ? Даже MiraclePtr не стало решением - смогли отловить половину ошибок, ценой жора памяти и проца у юзера. opennet.ru/opennews/art.shtml?num=60482
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 15:35
	>  если на C++ использовать правильные методологии разработки Если
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	108. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 15:41
	> если на C++ использовать правильные методологии разработки, то и количество ошибок связанных с памятью снизится в разы А почему не используют? Они же тратят кучу денег на исправление и пере-исправление багов. То ли заговор программеров, чтобы получать зарлату, то ли глупость человеческая.
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	127. "Методы безопасной работы с памятью позволили существенно сни..."	+3 +/–
	Сообщение от Аноним (127), 26-Сен-24, 16:06
	> То ли заговор программеров, чтобы получать зарлату, то ли глупость человеческая Да-да. Или массонский заговор, или меркурий не в той фазе. А вот то, что, возможно, сами плюсы не годятся для того, чтобы сразу писать надежный код -- не, это бред какой-то. Ну всего лишь нужно держать в памяти все сроки жизни лябд или помнить, какие объекты можно использовать в разных тредах, а какие нельзя. Или то, что нужно захватить правильный мьютекс, прежде чем модифицировать какое-нибудь значение будет написано в лучшем случае где-нибудь в комментарии в коде. Б - безопасность. Когда проект перерастает хеловорд и над ним работают больше 10 человек и каждый в случайный момент времени эти волшебные мьютексы то убирает, то возвращает, начинаются чудеса.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Rev (ok), 26-Сен-24, 15:52
	> если на C++ использовать правильные методологии разработки Так если компилятор к этому не принуждает, то и не используют. Люди - ленивые жопы.
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	246. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Советский инженер (ok), 27-Сен-24, 08:20
	>если на C++ использовать правильные методологии разработки а еще есть и такие предложения: https://www.opennet.dev/opennews/art.shtml?num=61878
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	309. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (120), 28-Сен-24, 19:47
	> Пишут, и новость на самом деле о том, что если на 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
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	114. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Герострат (?), 26-Сен-24, 15:44
	> Заговор? Нет, обычное стадное поветрие
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	115. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (115), 26-Сен-24, 15:45
	> Заговор? Вот Rust не самообманывается и добавил конструкцию unsafe {}, читая код понятно, где у тебя небезопасно. Осталось добавить конструкцию backdoor {}, чтобы все притензии к языку исключить.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	125. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 16:00
	> Осталось добавить конструкцию backdoor {} Совсем палевно. Unsafe достаточно, для понимающих )
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (115), 26-Сен-24, 16:22
	> Совсем палевно. Unsafe достаточно, для понимающих ) Ну неявный unsafe void main () {unsafe {.....}} куда лучше (то есть Си), зачем продвигать явный unsafe (безопасТный rust) если нужен backdoor? Вероятно, психология фокусника, пока вы следите за руками ...
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (133), 26-Сен-24, 16:24
	> Ну неявный unsafe void main () {unsafe {.....}} куда лучше (то есть  Си), зачем продвигать явный unsafe (безопасТный rust) если нужен backdoor? Вероятно, психология фокусника, пока вы следите за руками ... Так бекдор хорош только пока о нем знаешь только ты. А когда начинается проходной двор и начинают ложки пропадать... И ты задумываешься "а не закрыть ли все нафиг и решать другими методами"?
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (115), 26-Сен-24, 16:56
	> Так бекдор хорош только пока о нем знаешь только ты. Давно уже этими методами никто не пользуется, куда лучше методы PATRIOT Act (backdoor on-demand). А вы не заметили как только "известный фин" получил гражданство "соединенных индейцев", у него отпало желание на все указывать пальцем. Вот придут к нему с этим актом в Портленд, и он как настоящий "патрик", законопослушный, выполнит свой долг. И это не только у "индейцев".
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Perlovka (ok), 26-Сен-24, 18:47
	> для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже чем для кода на C++ При этом количество кода на С++ превышает количество кода на Rust на порядки. Как выдать желаемое за действительное, натягивая лису на глобус.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	292. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 06:31
	Есть такой способ анализа, как сравнение относительных показателей. Он применяется, когда абсолютные показатели несопоставимы. Удельный вес, проценты - это оно. Или в школе уже о таком не учат?
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Методы безопасной работы с памятью позволили существенно сни..."	–2 +/–
	Сообщение от Perlovka (ok), 28-Сен-24, 12:52
	Удельный вес чего? Количество кода на расте по сравнению с количеством кода на C находится на уровне погрешности измерений и стремится к нулю. Поэтому все измерения подобного плана тождественны уровню "одна бабка сказала".
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Ivan_83 (ok), 26-Сен-24, 22:04
	Да, примерно так. Не важно на чём написана генерация QR, это редко используемый функционал который потребляет при работе пренебрежимо мало. Я лично генерацией QR в бразуре ни разу не пользовался и не знал даже что оно там есть.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

5. "Методы безопасной работы с памятью позволили существенно сни..."	+4 +/–
Сообщение от Аноним (-), 26-Сен-24, 13:20
> Уже существующий код со временем становится более проверенным и безопасным, что делает не столь выгодными вложения в проекты по переписыванию существующего кода. А потом вылазит какая то вулна которой уже 15+ лет. Потому что на все простое уже наткнулись и исправили. (ну или можно оправдываться что это просто бекдор)))
Ответить | Правка | Наверх | Cообщить модератору

	16. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 13:36
	Всё упирается в деньги. Если переписывание кода дороже последствий уязвимости – его не будут переписывать. M$ считала, что одна критическая уязвимость обходится компании в $270к. Имеет смысл задуматься о новом коде на безопасном языке.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (22), 26-Сен-24, 13:42
	Постоянно переписывать на новые версии раста это бесплатно?
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 13:56
	> Постоянно переписывать на новые версии раста это бесплатно? А зачем постоянно переписывать? Откуда у тебя такие фантазии? Можно просто фиксируешь Edition и пишешь себе бед не зная. Ты хоть пару строк не нем написал или тебе пацаны во дворе рассказали?
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Методы безопасной работы с памятью позволили существенно сни..."	+3 +/–
	Сообщение от НяшМяш (ok), 26-Сен-24, 14:10
	Я недавно откопал свой первый проект на расте года 2018 ещё с 2015 эдишном. Скомпилировался и запустился растом 1.81 без проблем. Сяшечников с ПТСР надо пожалеть - они проецируют свой страх перед обновлениями версий GCC и LLVM, когда каждый мажорный релиз что-то перестаёт компилироваться.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Методы безопасной работы с памятью позволили существенно сни..."	+7 +/–
	Сообщение от Аноним (22), 26-Сен-24, 14:19
	Только эта фраза Хеллоу Ворлд никому не нужна даже тебе 6 лет была не нужна.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (83), 26-Сен-24, 14:43
	> Я недавно откопал свой первый проект на расте года 2018 ещё с > 2015 эдишном. Скомпилировался и запустился растом 1.81 без проблем. Вы все врети! (с) Тебя купил гугл и ты подтасовываешь результаты! (с) Чел, местные фанатики тебе не поверят, даже если ты бы проект сюда выложил. Они просто не могут представить, что можно делать не через заднее место. > Сяшечников с ПТСР надо пожалеть - они проецируют свой страх перед обновлениями > версий GCC и LLVM, когда каждый мажорный релиз что-то перестаёт компилироваться. И не только мажорным) Помню при переходе ЖЦЦ 4.Х на 4.Y ломались некоторые хаки. А от когда в ядре по умолчанию сделали -Werror то вообще содом и гомора началась. Пару лет назад бугурт был на отлично.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	172. "Методы безопасной работы с памятью позволили существенно сни..."	+3 +/–
	Сообщение от Perlovka (ok), 26-Сен-24, 18:49
	УАЗ "буханку" тоже с 1965 года не модернизируют. Он сразу хорошо получился.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	293. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Прохожий (??), 28-Сен-24, 06:37
	Это не значит, что сразу хорошо получился. Это значит, что не могут. Горбатого только могила исправит, говорят в таком случае
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 15:42
	> Постоянно переписывать на новые версии раста это бесплатно? Нет, конечно. Но, Холмс, зачем это делать?
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	31. "Методы безопасной работы с памятью позволили существенно сни..."	–4 +/–
	Сообщение от Аноним (38), 26-Сен-24, 13:53
	А зачем ПЕРЕписывать? Просто пофиксить баг - не? Не молодёжно? Надо тащить никому ненужный Ржу и всех насильно тыкать носом "у нас безопасная память"?
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	37. "Методы безопасной работы с памятью позволили существенно сни..."	+4 +/–
	Сообщение от Аноним (-), 26-Сен-24, 13:59
	> А зачем ПЕРЕписывать? Просто пофиксить баг - не? Так не получается. Наверное место проклятое (с) Вон у С++ число откатов изменений в результате выявления непредвиденных ошибок в два раза выше. Т.е приходится один и тот же баг исправлять несколько раз. > Не молодёжно? Надо тащить никому ненужный Ржу и всех насильно тыкать носом "у нас безопасная память"? Тебе не нужный, гуглу нужный. Гугл пишет андроид, а ты комменты на форуме. Как ты думаешь на чье мнение можно положить?))
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (38), 26-Сен-24, 14:08
	> Вон у С++ число откатов изменений в результате выявления непредвиденных ошибок в два раза выше. Низкоквалифицированный подаван (типа тебя) тут же делает выводы "с++ плохой". Профи не будет делать поспешные выводы, пока не поймёт, что возможно главная ошибка - в индусах, которые пытаются после недельных курсов С++ писать серьёзный код. Извини, ты облажался. > Тебе не нужный, гуглу нужный. Так почему он свою Ржу ВЕЗДЕ СУЁТ?! Такая агрессивная реклама, ПРОДАВЛИВАНИЕ своего г----ноязыка, будто он реально чего-то стоит! Объяснение только одно - эта гуглопараша никому не нужна, но гуглу (по какой-то причине) очень хочется всех посадить на это ржаподелие. > Гугл пишет андроид, а ты комменты на форуме. И снова ты облажался. Я пишу программы, а гугл - рекламные тексты для Ржы. Ведроид - тот вообще на Жабе писан! > Как ты думаешь на чье мнение можно положить?)) На ТВОЁ, очевидно! Нуб залезает на форум и пытается меня учить, используя даже не свои знания, а просто тыкая пальчиком КАК БЫ в авторитетов! хаха :)))) Ты жалок. Я сам пишу программы стократ лучше гугла. По кр мере не такие позорные, как Ведроид! Так что мне есть кого слушать - себя.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Анонимусс (-), 26-Сен-24, 14:21
	> Я пишу программы, а гугл - рекламные тексты для Ржы. Ты пишешь на опеньке, а гугл пишет хром и андроид для миллилардов девайсов. Но при этом ты считаешь "эта гуглопараша никому не нужна")) Тебе бы к врачу сходить, что ли... На лицо невероятное снижение когнитивных способностей. > Я сам пишу программы стократ лучше гугла. Спасибо, чувак, если бы смех продлевал жизнь, то ты мне ее так нехило продлил)) Ну а весь твой коммент можно подытожить один коротким видосом youtube.com/watch?v=ppVuYhsR8lo
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (83), 26-Сен-24, 14:22
	> Низкоквалифицированный подаван (типа тебя) тут же делает выводы "с++ плохой". Профи не  будет делать поспешные выводы, пока не поймёт, что возможно главная ошибка - в индусах, которые пытаются после недельных курсов С++ писать серьёзный код. Извини, ты облажался. Бла-бла-бла. А по делу будет что-то? Или ты у нас пишешь прямо из офиса гугла, окруженный (но пока не сломленный) танцующими индусами? > Так почему он свою Ржу ВЕЗДЕ СУЁТ?! Такая агрессивная реклама, ПРОДАВЛИВАНИЕ своего г----ноязыка, будто он реально чего-то стоит! Ну у тебя пичот) Откуда столько агрессии? В своем проекте (а андроид это детище гугла) они могут делать все что хотят. Вообще все. Даже удалить репу или переписать на паскаль. И это не их язык, они им просто пользуются. Как и остальные члены rust foundation типа AWS или майкрософта. > Объяснение только одно - эта гуглопараша никому не нужна, но гуглу (по какой-то причине) очень хочется всех посадить на это ржаподелие. Постарайся получше и придумай более правдоподобную теорию заговора. Говорят рептиоиды сейчас в моде. > И снова ты облажался. Я пишу программы, а гугл - рекламные тексты для Ржы. Ведроид - тот вообще на Жабе писан! О, видно кексперта. Надеюсь программы ты пишешь получше. А это что такое lwn.net/Articles/953116/ тоже жаба? > На ТВОЁ, очевидно! Нуб залезает на форум и пытается меня учить, используя даже не свои знания, а просто тыкая пальчиком КАК БЫ в авторитетов! хаха :)))) Ты жалок. Стадию гнева (бомбления) ты уже прошел чуть выше, теперь стадия отрицания? > Я сам пишу программы стократ лучше гугла. > По кр мере не такие позорные, как Ведроид! Так что мне есть кого слушать - себя. Ахахаххаха! Пощади человек-петросян! Ты же наверняка пишешь в опенсорс, может ссылку на репу дашь?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	151. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Анонимище (?), 26-Сен-24, 17:11
	>возможно главная ошибка - в индусах, которые пытаются после недельных курсов С++ писать серьёзный код. А как так получилось, что граждане Индии пишут менее уязвимый код на Rust, чем на C++? Получается Rust можно более качественно освоить после недельных курсов? Если да, то тогда зачем бизнесу использовать C++?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	235. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от СижуПежу (?), 27-Сен-24, 04:09
	Менее уязвимый только В ОДНОМ АСПЕКТЕ - возне с указателями (которую в C# даже не замечают). ВО ВСЁМ ОСТАЛЬНОМ индусокод остаётся таким же _овном.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Анонимище (?), 27-Сен-24, 06:15
	То есть, это уже улучшение. Если они будут писать на C++, то не будет даже этого.
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (120), 28-Сен-24, 20:03
	И этот один аспект убирает сразу 70% всех ошибок. Очевидно, овчинка стоит выделки, если принять в расчет среднюю стоимость исправления одной критической уязвимости, которую привели выше. Особенно учитывая, что наверное 99% критических уязвимостей вызваны именно этими 70% ошибок (работы с памятью).
	Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

	243. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Проходил мимо (?), 27-Сен-24, 08:12
	Rust НЕЛЬЗЯ освоить на недельных курсах. И на месячных толком освоить тоже не получится. Разработка на нем сопряжена с периодическим прилетом нежданчиков, даже после того, как ты на нем что-то пишешь несколько лет (инфа 146%).
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	296. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 07:04
	Смотря какие курсы, и что считать за освоение. Тот же C, C++ по такой логике (прилёт нежданчиков) вообще нельзя освоить, они, нежданчики, и спустя много лет прилетают, после старта разработки. Почему? Потому что в стандарте эти нежданчики записаны. Называются обычно UB.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Анонимусс (-), 26-Сен-24, 14:02
	> Просто пофиксить баг - не? Не. Потому что в соседней функции будет еще один баг. А соседнем модуле, а не, в плюсы же еще не завезли модули, в соседнем файле - еще пару штук. И будешь ты вычищать эти авгиевы конюшни годами. Разрабу наверное это хорошо - часы крутятся, зп мутится. А вот заказчику... ну так себе. > всех насильно тыкать носом О нет! Тебя ЗАСТАВИЛИ читать эту новость!
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	51. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (22), 26-Сен-24, 14:12
	А тебя заставили писать комментарий. Начитался теперь таких новостей и как под гипножабой не можешь остановится защищать раст. Лучше бы код на расте написал что-ли.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 15:05
	> А зачем ПЕРЕписывать? Переписывать не надо. В новости об этом буквально и написано: старый код выгоднее оставлять, новый код выгоднее писать сразу на новом языке.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	150. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (150), 26-Сен-24, 17:11
	Это ты лично просто пофиксишь, когда вернут. Есть "машина", работающая по определенным корпоративным стандартам. Наглядно разницу подходов можно увидеть в фильме 2023 года "Кто убил BlackBerry"
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	239. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Андрей (??), 27-Сен-24, 07:28
	Ну тут нужно посмотреть кто считает, ибо если считал отдел по внедрению раста или менеджеры, нечистые на руку или что более ожидаемо - биржевые спекулянты, то о чём тут говорить - посчитали те, кому выгодно.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	294. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 06:49
	Ага, сплошной мировой заговор против плюсовиков и сишников.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Я (??), 27-Сен-24, 04:20
	если она вылазит раз в 15 лет, то и пускай вылазит.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

6. "Методы безопасной работы с памятью позволили существенно сни..."	+3 +/–
Сообщение от Fjyj (-), 26-Сен-24, 13:26
> Например, 5-летний код в среднем имеет в 3.4 раза меньшую плотность уязвимостей, чем новый код. Но при этом не говорят о серьезности проблемы. Всякий мусор типа "кнопка не того цвета" или даже "приложение крашится" естественно найдут быстро. Например грязная корова Dirty COW (CVE-2016-5195) жила 9 лет. А эпическая Bashdoor была найдена в 2014, а сделана приблизительно в 1992. ИМХО такой подход слегка похож на самообман.
Ответить | Правка | Наверх | Cообщить модератору

	169. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Аноним (169), 26-Сен-24, 18:32
	>> плотность уязвимостей > не говорят о серьезности проблемы "Смотрю в книгу - вижу фигу"? Тебе черным по белому написано, что серьезность проблемы - уровень "уязвимость". Какая  еще "кнопка не того цвета", что ты несешь?
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (-), 26-Сен-24, 19:03
	> "Смотрю в книгу - вижу фигу"? Да, и по тебе это заметно > Тебе черным по белому написано, что серьезность проблемы - уровень "уязвимость". Где? Вот что пишут гугловцы 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. Ничего про "серьзность проблемы" там нет, только про возраст.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (169), 26-Сен-24, 20:58
	>> Тебе черным по белому написано, что серьезность проблемы - уровень "уязвимость". > Где? Пять раз встречающееся слово vulnerability в приведенных тобой цитатах тебе ни о чем не говорит? > Ничего про "серьзность проблемы" там нет Действительно, какие-то там "вульнерабилитис". Наверняка это всякий мусор типа "кнопка не того цвета" или даже "приложение крашится".
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 21:29
	Мда... до тебя все еще не доходит. У cve есть градации. Это может быть CVSS Score или другая категоризация. Напр. local code execution менее опасна чем remote code execution, а DoS обычно менее опасна чем code execution. Так вот, в статистике выше нет информации про опасность cve.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Советский инженер (ok), 27-Сен-24, 08:34
	>У cve есть градации. так и все же, какую градацию cve присваивают когда кнопка не того цвета?
	Ответить | Правка | Наверх | Cообщить модератору

	255. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 12:18
	>>У 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"
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Советский инженер (ok), 27-Сен-24, 14:55
	тут про "tapjacking attack" и про "overlay the toggle button". про очень даже правильный цвет, но другой кнопки. а где про неправильный цвет кнопки?
	Ответить | Правка | Наверх | Cообщить модератору

	273. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 15:06
	> про очень даже правильный цвет, но другой кнопки. > а где про неправильный цвет кнопки? Clickjacking is an attack that occurs when an attacker uses a transparent button. А clear color это уже не цвет?
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Советский инженер (ok), 27-Сен-24, 16:42
	>А clear color это уже не цвет? в случае "Clickjacking" clear color это именно тот цвет кнопки который автор и задумал. тут вулна в том что кнопка вообще есть. так что давай. ищи получше.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 21:32
	И да, "кнопка не того цвета" это конечно смешно. Но пока этот цвет не прозрачный)) Иначе ты получаешь 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
	Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

	215. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Ivan_83 (ok), 26-Сен-24, 23:34
	И никому не мешало, как и куча других ошибок признаных уязвимостями. В реальном мире всё точно так же, и решение для этого простое: страхование рисков.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	297. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 07:08
	>никому не мешало А зачем пофиксили, если никому не мешало? Или под "никому" товарищ майор имеется ввиду?
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (241), 27-Сен-24, 08:10
	Про кнопки не того цвета - это ты правильно подметил. Если "вдруг" красная кнопка запуска МБР станет зеленой, покрасится весь мир. Примитивные представления заурядных кодеров об устройстве мира порой поражают.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
Сообщение от Walker (??), 26-Сен-24, 13:27
Убедили, теперь я перехожу на Rust. Этот язык кажется очень перспективным, и я готов изучить его.
Ответить | Правка | Наверх | Cообщить модератору

	11. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Fjyj (-), 26-Сен-24, 13:30
	Зависит от того чем ты занимаешься. Если код не сильно требовательный к безопасности (написание игр на С++), то можешь забить, возможно оно того не стоит Ну и если у тебя команда будет против - то тебя ждет печальная участь.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Методы безопасной работы с памятью позволили существенно сни..."	–5 +/–
	Сообщение от Аноним (22), 26-Сен-24, 13:47
	Если коду нужна безопасность памяти есть куча языков, питон, джава, джаваскрипт, Хаскель да даже кобол. У раста нет ниши, совсем.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Анонимусс (-), 26-Сен-24, 13:59
	Которые тормознутые как не знаю что. А если тебе нужно и быстро, и безопасно? Что тогда? Вот тогда берешь раст. > У раста нет ниши, совсем. Повторяй это три раза в день перед зеркалом))
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (22), 26-Сен-24, 14:07
	Вспоминаешь что не может быть быстро и безопасно. Тут или безопасная двуручная пила или бензопила. Безопасной бензопилы быть не может. Среди бензопил можно конечно взять не пилу дружба, а например Golang как лучшее из того что есть.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (47), 26-Сен-24, 14:10
	Аналогия не аргумент. Rust на этапе компиляции обеспечивает безопасную работу памяти, проверяя код. Asm команды при этом не будут отличаться от аналогичного (но корректного) кода на Си.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (22), 26-Сен-24, 14:16
	Обещает обеспечить путем запрета на мутации. Ты и на Си можешь перестать мутировать только ты ничего не напишешь годного. Ты и в акваланге можешь пробежать марафон 42 километра и не уточнить в случае потопа. Только ты не добежишь.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (22), 26-Сен-24, 14:23
	Утонуть*
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (47), 26-Сен-24, 14:44
	> можешь перестать мутировать Не могу, я уже гидралиск.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	92. "Методы безопасной работы с памятью позволили существенно сни..."	+3 +/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 15:10
	> Обещает обеспечить путем запрета на мутации Во-первых обеспечивает, а во-вторых, запрета на мутации нет. Ты бы хоть в общих чертах прочитал про раст. Два-три параграфа хватит, чтобы совсем чушь не говорить. > Ты и на Си можешь перестать мутировать только ты ничего не напишешь годного Си не относится к подобным языкам, такое на нём делать неудобно. А другие языки - вполне себе. Раст, кстати, к ним не относится, он С-подобный.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	196. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Nuke (?), 26-Сен-24, 20:56
	Мне думается, говоря о запрете на мутации, он с Хаскеллем спутал. И то, это только в "каноничном" функциональном коде в Хаскелле нет мутаций, а если всё же вспомнить про монадки IO и ST, то с мутациями там всё в порядке, не хуже, чем на Сях.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Анонимусс (-), 26-Сен-24, 14:14
	Еще как может быть. Вот seL4 сделали быстрым и гарантировано безопасным, не смотря на то, что на си. Просто зарыли 11 человеколет в формальную верификацию. > Среди бензопил можно конечно взять не пилу дружба, а например Golang как лучшее из того что есть.   Вот как раз раст это и есть лучшее что есть на данный момент.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	60. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (22), 26-Сен-24, 14:17
	Почему же никто не использует раст, но все используют Golang?
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Анонимусс (-), 26-Сен-24, 15:12
	> Почему же никто не использует раст Лол. Прямо в новости написано что гугл использует! Но в твоем манямирке - "никто не использует раст". > но все используют Golang? Кто все? Гугл например?))
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от bOOster (ok), 26-Сен-24, 19:06
	-"Смотрим в книгу видим фигу"? Гугель рекомендует. Только все плевать на его рекомендации связанные с rust.
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Прохожий (??), 28-Сен-24, 07:00
	>все плевать Всем местным неосиляторам и/или хейтерам? Кто бы сомневался.
	Ответить | Правка | Наверх | Cообщить модератору

	318. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от bOOster (ok), 29-Сен-24, 08:30
	>>все плевать > Всем местным неосиляторам и/или хейтерам? Кто бы сомневался. Диды медленно запрягают, да быстро везут. Если заявили в С++ опции безопасной работы с памятью - в течении полугода уже что-то осмысленное выкатят.. А осиляторы rust (Хотя что там осилять, никто из адекватных просто не хочет вникать в неадекватный синтаксис, отсутсвие хоть какой то устоявшейся структуры языка и т.п.), как в сказке о золотой рыбке, после заявления "хочу быть владытчицей морскою" останутся у разбитого корыта, сглатывая концептуальные изменения выкатываемые rust разработчиками, и переписывая куски кода своих старых проектов в новые МОДНЫЕ концепции потому как проектировщики rust так захотели.
	Ответить | Правка | Наверх | Cообщить модератору

	319. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (-), 29-Сен-24, 09:41
	> Диды медленно запрягают, да быстро везут. Если заявили в С++ опции безопасной > работы с памятью - в течении полугода уже что-то осмысленное выкатят.. Ты это серьезно? Диды медленно запрягают, да еще медленнее обсуждают. Сколько там комитет С++ рожает фичи? Три года минимум надо пообсуждать. В 26 стандарт оно уже не попало, в 30 сомнительно что попадет. > А осиляторы rust (Хотя что там осилять, никто из адекватных просто не хочет вникать в неадекватный синтаксис, отсутсвие хоть какой то устоявшейся структуры языка и т.п.), О, начинается нытье про синтакс. Сразу видно что неосилил)) > сглатывая концептуальные изменения выкатываемые rust разработчиками, и переписывая куски кода своих старых проектов в новые МОДНЫЕ концепции потому как проектировщики rust так захотели. И снова бредовые фантазии от человека, который не знает что такое Edition и как в расте сделана обратная совместимость /_-
	Ответить | Правка | Наверх | Cообщить модератору

	323. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от bOOster (ok), 29-Сен-24, 13:41
	> И снова бредовые фантазии от человека, который не знает что такое Edition > и как в расте сделана обратная совместимость /_- Сглатывайте, сглатывайте малафью вместе с изучением обратной совместимости в одной версии с прямого, а потом с кривого.... Хехехе
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от НяшМяш (ok), 26-Сен-24, 14:15
	Не может быть быстро, безопасно и быстро компилируемо. Компиляция долгая как раз для валидации, а в рантайме и быстро, и безопасно.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	73. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (22), 26-Сен-24, 14:28
	Golang везде быстро и безопасно. Да ещё и от гугл.
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 07:10
	Не везде. Дискорд, что ли, в своё время отказался от Голанг в пользу Раст, потому что было небыстро.
	Ответить | Правка | Наверх | Cообщить модератору

	312. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (120), 28-Сен-24, 20:22
	> 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." " Так что при прочих равных раст имеет преимущество перед го в плане потребления памяти и меньше ошибочек в течение времени жизни проекта.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	201. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Василий Пупов (?), 26-Сен-24, 21:58
	Ну кстати зиг пытается немного это изменить. Если они слезут с ллвм и научатся быстро патчить инкрементальные правки в бинаре напрямую,то может и раст задумается.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	53. "Методы безопасной работы с памятью позволили существенно сни..."	+3 +/–
	Сообщение от Аноним (53), 26-Сен-24, 14:13
	>А если тебе нужно и быстро, и безопасно? Что тогда? В книгах по менеджменту качества пишут, что качество продукции на 80% зависит от личных качеств работников, таких как ответственность, аккуратность, дисциплинированность, и только на 20% зависит от уровня профессиональных знаний работника и инструментов, применяемых ими. Если вам нужно чтобы сделали быстро и качественно, надо набрать хороших работников. Если у Гугля такие большие проблемы с качеством его продуктов, то это говорит о неправильной кадровой политике Гугля
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	69. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (38), 26-Сен-24, 14:24
	Поразительно, как из полной чуши ты умудрился сделать правильный вывод! :))) Да, кадровая политика гугли - ДНО. Но качество кода - это В ПЕРВУЮ очередь - квалификация! И только потом - какие-то эфемерные "дисциплины", о которых ты сам понятия не имеешь, но лепишь. Можно сидеть ОДНОМУ, без каких-либо соц-пересечений и писать нормальный код.
	Ответить | Правка | Наверх | Cообщить модератору

	299. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 07:15
	>Можно сидеть ОДНОМУ, без каких-либо соц-пересечений и писать нормальный код. Уровня hello world? Вполне возможно. Но кому такой код нужен?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (22), 26-Сен-24, 14:25
	Всех хороших работников уже разобрали приходится работать с тем что есть.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	71. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от User (??), 26-Сен-24, 14:25
	А других - НАСТОЯЩИХ - сишников у меня для вас нету :). Не, можно конечно этих на мороз и чатжопэтэ взять - но тут в перспективы раста мне пока больше верится.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	170. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (169), 26-Сен-24, 18:37
	> качество продукции на 80% зависит от личных качеств работников, таких как ответственность, аккуратность, дисциплинированность, и только на 20% зависит от уровня профессиональных знаний работника Лол. Хирурга так себе выбери.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	34. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (53), 26-Сен-24, 13:57
	>если у тебя команда будет против - то тебя ждет печальная участь Десять программистов решили написать программу, Но один из них любил Rust - И их осталось девять
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	52. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (47), 26-Сен-24, 14:13
	Один из девяти любил простые кремнивые пистолеты. Однажды ногу прострелил, и их осталось восемь.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Хру (?), 27-Сен-24, 14:18
	Один из восьми запустил AFL и сломал мозги. И их осталось семь
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от laindono (ok), 26-Сен-24, 18:20
	> написание игр на С++ Кстати, а покажи тогда чего могут современные ECS на крестах. Есть ли среди них настолько эргономичные и фичастые, как bevy_ecs? Примеры: https://github.com/bevyengine/bevy/tree/main/examples/ecs
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	61. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (61), 26-Сен-24, 14:18
	Не позорься, готов ты. Прямо как журналисты, которые вечно пишут, что кто-то что-то собирается сделать. Собирается, только никак не соберётся.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	72. "Методы безопасной работы с памятью позволили существенно сни..."	+3 +/–
	Сообщение от Аноним (38), 26-Сен-24, 14:27
	100% Опасно то, что гугля создаёт информационный хайп, ЯКОБЫ "все" только и говорят, что о Расте. На деле про ржу только и пишут, что продажные журнашл_иу_шки, да маркетинговый отдел гугли. Вместо графиков гугля лучше бы показал Хром, переписанный на Расте (ну и соотв. метрики - сколько это стоило по ср. с С++, кто и за сколько будет это Г сопровождать, сколько времени ушло на бизнес-логику, а сколько прыжки вокруг памяти и т.п.).
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Проходил мимо (?), 27-Сен-24, 08:20
	Надеюсь, у вас крепкие нервы :) Язык хороший и быстрый, но есть нюансы :) Морально готовьтесь к периодическим "нежданчикам", когда то, что по вашему мнению должно нормально компилироваться, компилироваться не будет и придется вникать и разбираться, почему это происходит и как это обойти.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	300. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 07:56
	В Си и Плюсах эти нежданчики сидят прямо в стандарте (UB). Так что такое.
	Ответить | Правка | Наверх | Cообщить модератору

	331. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Проходил мимо (?), 30-Сен-24, 08:40
	Нежданчик - это когда простые и, вроде как, понятные вещи внезапно демонстрируют совершенно неожиданное поведение, в плюсах такого практически нету. Вот пример последнего нежданчика: 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);     }     */ }
	Ответить | Правка | Наверх | Cообщить модератору

9. "Методы безопасной работы с памятью позволили существенно сни..."	+6 +/–
Сообщение от Анонимусс (-), 26-Сен-24, 13:28
> Исправление уязвимостей после их обнаружения. Андроид имеет еще одну особенность - часть систем получат секурити обновления примерно... никогда))) Поэтому намного лучше вообще не сделать дыру используя Safe Coding подходы. А не сделать, а потом латать, но не у всех.
Ответить | Правка | Наверх | Cообщить модератору

	17. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Аноним (22), 26-Сен-24, 13:37
	Ещё особенность что там почти все джава, а она безопасно работает с памятью.
	Ответить | Правка | Наверх | Cообщить модератору

10. "Методы безопасной работы с памятью позволили существенно сни..."	+4 +/–
Сообщение от Аноним (14), 26-Сен-24, 13:28
> В качестве примера приводятся показатели отката изменений - для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже чем для кода на C++. Это просто цирк. Зайдите в репозиторий исходников Хрома и сравните количество кода на C++ и его сложность (количество компонентов, которые взаимодействуют между собой) и на расте. На последнем там только парочка хелооуворлдов: https://github.com/search?q=repo%3Achromium%2Fchro...
Ответить | Правка | Наверх | Cообщить модератору

	15. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (22), 26-Сен-24, 13:36
	Почиканный борров концептуально не даёт написать большой и сложный код. Все что он делает запрещает мутации при наличии любого алиаса на ссылке.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Методы безопасной работы с памятью позволили существенно сни..."	+5 +/–
	Сообщение от Аноним (130), 26-Сен-24, 16:14
	Собаки лают, а боров чекает.
	Ответить | Правка | Наверх | Cообщить модератору

	228. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (222), 27-Сен-24, 00:42
	...вместо написания кода.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Методы безопасной работы с памятью позволили существенно сни..."	+3 +/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 16:25
	> Все что он делает запрещает мутации при наличии любого алиаса на ссылке. В многопоточном коде, чтение данных в одном месте и отсутствие лока на запись в другом месте - это 100% проблема, причём плавающая, т.е. будет выявлена "когда-то". Если повезёт - в процессе разработки, не повезёт - "у нас критикал на проде". У растоманов это будет ошибка компиляции, а кодерам на С/++ - удачи в рантайме!
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	216. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Ivan_83 (ok), 26-Сен-24, 23:40
	Нет, это не 100%, такое может вообще никогда не вылезти в какую либо заметную проблему. Если они пишут и читают из одной области памяти значение размером с регистр - то и лок там особо не нужен в принципе. И есть конструкции на базе атомиков которые позволяют обходится без локов при одновременном чтении/записи из разных потоков, этому всему уже более 20 лет. В общем ситуации бывают сильно разные, вы похоже больше теоретик-фанатик чем тот кто реально сталкивался с написанием и отладкой многопоточных приложений на С.
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (242), 27-Сен-24, 08:11
	> никогда не вылезти в какую либо заметную проблему Т. е. проблема будет незаметной и её обнаружат только в CVE через 10 лет? Вот это да
	Ответить | Правка | Наверх | Cообщить модератору

	285. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 21:25
	> Нет, это не 100%, такое может вообще никогда не вылезти в какую либо заметную проблему. Ну если датарейс не гарантирован, то можно спать спокойно. Авось пронесёт.
	Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

	306. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (306), 28-Сен-24, 14:35
	data race и UB бояться - тогда вообще за программирование не следует браться.
	Ответить | Правка | Наверх | Cообщить модератору

	322. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 29-Сен-24, 13:08
	А лучше, всё же, использовать подходящий язык программирования, чтобы не бояться.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (252), 27-Сен-24, 11:55
	ты не поверишь но в компиляторе есть опция включающая эту проверку в с++...
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	286. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 21:28
	Я не поверю, точно. Вот допустим код: static char *static_str; void foo(char* p) {     // как компилятор может здесь проверить, что строки p и static_str не пересекаются? } Я могу придумать как такое проверить в рантайме -- можно померить длину обеих строк, и потом посмотреть не пересекаются ли диапазоны адресов, но это не то, что можно позволять делать компилятору, потому что для этого компилятор должен предполагать, что оба указателя указывают на null-терминированную строку, что может быть вовсе не моя задумка, так ведь? Но ты говоришь, что компилятор это может проверить? Расскажи нам, как ему это удаётся. За счёт какой такой магии?
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (38), 26-Сен-24, 13:50
	Ну вот поэтому гугля занимается РЕКЛАМОЙ своего недоРжы вместо того, чтобы переписать на нём Хром, к примеру! Или ведроид.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	32. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Анонимусс (-), 26-Сен-24, 13:56
	А... при чем тут хромиум? В новости речь про андроид. В андроиде на расте написаны всего лишь блютус стек, биндер и совсем неважная штука keystore2)) И это отдельные проекты, кроме которых есть еще где-то 1.5 ляма строк раст-кода минимум. Но мне лень искать по их репе.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	45. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (14), 26-Сен-24, 14:07
	> А... при чем тут хромиум? действительно, при чем? > Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 15:17
	Привели пример с переписыванием маленького компонента на раст в хромиум. Ты полез смотреть _весь_ код хромого. Сам натянул сову, сам удивился. Человек-оркестр.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Аноним (14), 26-Сен-24, 15:23
	> Ты полез смотреть _весь_ код хромого. Вот именно, что там кроме этого бесполезного хеллоуворлда на расте ничего толком и нет. Но безопасность при этом повысилась. Потому что новость не про то, как раст всех спас, а про то, что правильные методики программирования на C++ действительно работают. А сову на глобус натягивают фанаты раста.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Методы безопасной работы с памятью позволили существенно сни..."	–4 +/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 15:41
	> Но безопасность при этом повысилась Нет, безопасность не повысилась, она осталась прежней. Повысилась производительность на 95%. Я понимаю, почему вам так сложно понять раст и его простые концепции. Если даже простую статью, написанную на простом языке, вы не можете усвоить, то куда уж до нового ЯП. Хотя отсюда можно сделать вывод, что и других языков вы не знаете. Зочем спорите тогда? Спорт?
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Продавец (?), 26-Сен-24, 22:42
	Как же ты хорошо всё понемаешь: и людей, и в программировании
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (14), 27-Сен-24, 00:04
	> Нет, безопасность не повысилась, она осталась прежней > Для проектов Android и Chromium благодаря внедрению методов безопасной работы с памятью разница составляет 7.4 раза. Докажи, что у тебя больше одного нейрона в голове и ты способен к этому добавить ещё и контекст того поста, который комментируешь, чтобы понять, что в случае с Хромом это не заслуга раста.
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	313. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (120), 28-Сен-24, 20:36
	> В андроиде на расте написаны всего лишь блютус стек, биндер и совсем неважная штука keystore2)) > всего лишь Того что ты перечислил и так достаточно. Но главное сказать полуправду и даже её умалить и признать ничтожной. А куда ты дел хотя бы те же DNS-over-HTTP3, Android’s Virtualization framework (AVF)? 21% раста (два года назад) в новом коде нативной системщины в андроиде - это будет по-сложнее вашего наколеночного "Операционного Дня Банка" или твоих поделок на 1С или ковыряний в контроллерах.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

13. "Методы безопасной работы с памятью позволили существенно сни..."	+3 +/–
Сообщение от Аноним (22), 26-Сен-24, 13:31
А другие графики они не хотят показать? Как изменилась стоимость разработки? Сколько теперь нужно разрабов на тот же код. Может хотят показать сколько стоят убытки от сабжевых уязвимостей может быть нуль? Очевидно сабжевое исследование для хомячков у которых нет и не может быть нормального образования.
Ответить | Правка | Наверх | Cообщить модератору

	20. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 13:38
	> Как изменилась стоимость разработки Может тебе еще "ключи от квартиры где деньги лежат" ?)) Хотя можешь прикинуть - для раст-кода кол-во регрессий в два раза реже. Так что кроме разработки нужно учитывать еще и стоимость поддержки. > Может хотят показать сколько стоят убытки от сабжевых уязвимостей может быть нуль? Не может быть нуль. Тебе надо взять программеров и они потратят время на исправление, QA чтобы они это все проверили. Нуль будет только в ситуации "нам пофиг wont fix" и то, какой-то PM или QA должен тикет записать, а потом закрыть.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (22), 26-Сен-24, 13:45
	Опять придуманные цифры. Реальность говорит лишь то что рефакторинг кода на расте невозможен как и большие проекты на нем. Иначе гугл бы не графики выдавал, а просто взял и переписал хром на раст.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Методы безопасной работы с памятью позволили существенно сни..."	–2 +/–
	Сообщение от Аноним (38), 26-Сен-24, 13:49
	> Иначе гугл бы не графики выдавал, а просто взял и переписал хром на раст Золотые слова! К чему все эти МАРКЕТОИДНЫЕ убеждения для _программистов_?! Они что нас, за тупых считают? Программист верит только цифрам, причём не в графиках от "Леночки-маркетоидши", а в реальных проектах. А растаманы только и умеют, что ls, да dd переписывать! Перделки уровня 3 экранов.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 14:07
	> Реальность говорит лишь то что рефакторинг кода на расте невозможен как и ... летательные аппараты тяжелее воздуха ... передача голоса по проводам ... потребность иметь компьютер дома > Иначе гугл бы не графики выдавал, а просто взял и переписал хром на раст. Может денег жалко. Если ты не заметил - то в статье про андроид. И у них могут быть совершенно разные бюджеты. Но в 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 Работа ведется. Так что может и перепишут.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	76. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (22), 26-Сен-24, 14:34
	В Гугле про все работа ведётся только там проекты закрываются так же просто как и анонсируются.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (38), 26-Сен-24, 14:39
	У тебя (как и у многих молодых людей) слишком оптимистичный взгляд на жизнь. > Chromium project is going to support the use of third-party Rust libraries Эту новость надо читать БУКВАЛЬНО: "Мы добавим в Хром возможность использовать внешние Ржа-библиотеки". ТОЧКА. Здесь НИЧЕГО не говорится ни о каком "переписывании", ни об интенсивности и широте внедрения этих библиотек, вообще ничего! Поэтому не надо прыгать вперёд кобылы и рисовать радужные облака - это просто "возможность использовать". И не хочешь - не используй! Только и всего. ВОТ ТАКОЙ строгий, трезвый, инженерный взгляд должен быть у программиста. Это уже не говоря о том, что инженер просто обязан понимать, насколько ущербен Ржа для ИТ.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	87. Скрыто модератором	+/–
	Сообщение от Аноним (-), 26-Сен-24, 15:01
	Ты вообще читал статью или тебя хватает только на газофикацию лужи? Что тебе не понятно в моей фразе "Работа ведется. Так что может и перепишут." Ты совсем глупый? Сейчас они используют либы. И юзер получит бинарь хромого вместе с раст кодом. И чтобы собрать полностью с нуля, раст тоже придется собирать. 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 раст уже есть. > ВОТ ТАКОЙ строгий, трезвый, инженерный взгляд должен быть у программиста. Которого я тут не вижу. А вот истерику и капс, вижу. > Это уже не говоря о том, что инженер просто обязан понимать, насколько ущербен Ржа для ИТ. Лол, судя по твоим висерам, ты даже на дворника не потянешь. Аргументов ноль, зато пафосные "обязан понимать")
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от ZXCVBN (?), 29-Сен-24, 14:10
	> инженер просто обязан понимать, насколько ущербен Ржа для ИТ. А можете ли вы развернуть эту мысль? Почему Rust наносит ущерб индустрии IT? Спрашиваю из интереса, цели спорить нет.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	101. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 15:25
	> А другие графики они не хотят показать? > Как изменилась стоимость разработки? Уже показывали. Кратко: быстрее пишут, быстрее погружаются в проект. C++ разработчики также быстро осваивают Раст, в районе двух месяцев. Также C++ разработчики начинают лучше писать на, собственно, С++, после освоения раста. Это кажется очевидным для растомана, но не для стороннего наблюдателя. > сколько стоят убытки от сабжевых уязвимостей может быть нуль? Ты участвовал в продуктовой разработке? Хоть в какой-нить, хоть собственный персональный блог, где надо было фиксить что-то и куда-то выкладывать. Как эти затраты, в принципе, могут быть нулевые? Они огромны.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	229. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (222), 27-Сен-24, 00:46
	>разработчики начинают лучше писать на, собственно, С++, после освоения раста. Объяснимо. Это они от страха что их снова заставят писать на Ржавом ))
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 08:11
	Здравствуйте, Евгений Ваганович. Как сам, как дети?
	Ответить | Правка | Наверх | Cообщить модератору

30. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
Сообщение от Перепишу (?), 26-Сен-24, 13:52
>> 95% за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции. Ну если бы они убрали sandbox для C++ было бы быстрее rust, да даже pascal был бы быстрее. Маркетологи
Ответить | Правка | Наверх | Cообщить модератору

	59. "Методы безопасной работы с памятью позволили существенно сни..."	+4 +/–
	Сообщение от НяшМяш (ok), 26-Сен-24, 14:17
	> Ну если бы они убрали sandbox для C++ было бы много новых всеми любимых CVE Пофиксил, не благодари.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (22), 26-Сен-24, 14:40
	Тебя CVE в детстве покусали или твои нюдсы украли через дыру?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Аноним (83), 26-Сен-24, 14:47
	> Тебя CVE в детстве покусали или твои нюдсы украли через дыру? О, а вот и первые эксгибиционисты подъехали /_- Ну подумаешь твой комп, телефон или роутер взломают. Или украдут данные и пароли, или частью ботнета сделают. А может просто rm -rf. Дело то житейское. Диды терпели и нам завещали.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (22), 26-Сен-24, 15:08
	А может инопланетяне прочитают твой мозг и надо носить шапочку из фольги? Тебе поможет только длительное лечение под присмотром специалистов. Растом тебя уже не вылечить.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (-), 26-Сен-24, 15:11
	> А может инопланетяне прочитают твой мозг и надо носить шапочку из фольги? Ну раз ты веришь в инопланетян и шапочки из фольги, то зачем тебя вообще слушать? Пруфов от тебя все равно не будет. А издеваться над убогими.. мне совесть и воспитание не позвоялет.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (164), 26-Сен-24, 17:49
	Диды не терпели. Глобальных сетей тогда не было - терпеть было нечего.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	314. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (120), 28-Сен-24, 20:40
	Диды на дискетах сами переносили. Чё-то OneHalf вспомнился. Ностальджи.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 15:27
	Так чево же не убрали? Мозгов не хватило? Иди, посоветуй им. Подсказка: там не только для qr-кодов песочницы, там их много. Давай, ускорь хромого парой патчей, раза в два.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	248. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Проходил мимо (?), 27-Сен-24, 09:00
	Я сегодня добрый, поэтому потрачу чуток своего времени, чтобы пролить свет реального знания на ваше невежество. Итак, проект на Rust, по умолчанию, компилируется в режиме --debug, в котором в него включается куча дополнительных проверок. В таком виде код действительно может работать медленнее, чем написанный на Си, Си++ или GoLang. Про Паскаль не знаю - я им не пользовался и тесты не проводил. Все меняется, когда мы компилируем код в режиме --release. Он становится необычайно быстрым. Настолько, что мне удавалось обойти по производительности оптимизированный на скорость код, написанный на чистом Си (который был примерно на 300% быстрее решения на Си++, основанного на STL и скомпилированного с -O2).
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	332. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Anonim (??), 01-Окт-24, 13:54
	За счёт чего? Только за счёт автоматического __restrict__, или дополнительные гарантии позволяют применять ещё какие-то оптимизации?
	Ответить | Правка | Наверх | Cообщить модератору

40. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
Сообщение от Аноним (53), 26-Сен-24, 14:03
>В общем виде Google рекомендует не переписывать старый код, а сосредоточиться на написании нового кода извините меня, а кто же тогда финансирует переписывание coreutils, findutils, tls, sudo и т.д., разве не Гугль?
Ответить | Правка | Наверх | Cообщить модератору

	175. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 19:00
	Ты перечислил ГНУ утилиты. Гугл, как и всякий корпораст старается держаться подальше от копилефта.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (164), 26-Сен-24, 19:18
	То-то все они так дружною толпою держаться очень далеко от кернела Linux.
	Ответить | Правка | Наверх | Cообщить модератору

63. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
Сообщение от ИмяХ (ok), 26-Сен-24, 14:20
>>рекомендует не переписывать старый код Правильно, пусть старые бэкдоры продолжают работать так, как работали. Как говорится "работает - не трогай"
Ответить | Правка | Наверх | Cообщить модератору

68. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
Сообщение от commiethebeastie (ok), 26-Сен-24, 14:24
Просто появилась ГоПоТа, которая очень хорошо находит утечки памяти и не проверяемые вводные данные. Она очень жестко патчит код if (!writebuf) конструкциями.
Ответить | Правка | Наверх | Cообщить модератору

	230. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (222), 27-Сен-24, 00:51
	Именно, и это главная причина почему не надо переходить на Раст. Через годик все уязвимости запросто найдет ИИ и в нем просто отпадет всякий смысл.
	Ответить | Правка | Наверх | Cообщить модератору

89. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
Сообщение от Аноним (-), 26-Сен-24, 15:04
Краткое содержание комментариев выше Вот когда Mozilla будет использовать Rust, тогда и поговорим Вот когда Dropbox будет использовать Rust, тогда и поговорим Вот когда Amazon будет использовать Rust, тогда и поговорим Вот когда Cloudfare будет использовать Rust, тогда и поговорим Вот когда Google будет использовать Rust, тогда и поговорим ========== вы находитесь здесь ========== Вот когда я не смогу собрать ядро без Rust Ну и еще немного бугурта))
Ответить | Правка | Наверх | Cообщить модератору

	95. Скрыто модератором	+8 +/–
	Сообщение от Аноним (22), 26-Сен-24, 15:13
	В дропбоксе нет раста там только Го. Мозилла должна была переписать движок на раст. Но серво до сих пор не может без зависания корректно отобразить простейшую страницу с формой. В клаудфлере код на сто строк на расте, а рекламы на миллион. В Гугле проекты на уровне генерация qr кода там вообще десять строк. Вся твоя лапша на ушах давно протухла.
	Ответить | Правка | Наверх | Cообщить модератору

	102. Скрыто модератором	+3 +/–
	Сообщение от Денис Попов (?), 26-Сен-24, 15:26
	Да не мешай ему мечтать, лежа на диване. Ладно бы он сам хоть что-то коммитил в поделки на расте, но чую что максимум видеоуроки смотрел на ютубчике.
	Ответить | Правка | Наверх | Cообщить модератору

	124. Скрыто модератором	+2 +/–
	Сообщение от Rev (ok), 26-Сен-24, 15:59
	> В дропбоксе нет раста там только Го. Вот как раз в Dropbox переписали лет 8 назад код хранилища с Го на Раст, и оно стало в разы быстрее и перестало зависать на время работы GC. Ты разве не читал этот блог-пост?
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	147. Скрыто модератором	+2 +/–
	Сообщение от Аноним (-), 26-Сен-24, 17:05
	> В дропбоксе нет раста там только Го. Итак в левом углу у нас Всезнающий Аноним, а в правом Дропбокс. Открываем их бложик 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 Кекспертность Всезнающего Анонима на уровне ПТУ животноводства! Это просто душераздирающее зрелище!
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	122. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от КО (?), 26-Сен-24, 15:55
	-Ты здесь- -никогда- Вот когда Любимая корпорация будет использовать Rust везде
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	163. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (164), 26-Сен-24, 17:45
	И чтобы Rust смог заменить C++, должен появиться Rust_с_классами.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Методы безопасной работы с памятью позволили существенно сни..."	–2 +/–
	Сообщение от Проходил мимо (?), 27-Сен-24, 09:13
	Довожу до вашего сведения, что в Rust есть структуры и есть возможность привязать к этим структурам методы. И есть возможность регулировать видимость на уровне модуля. И все это из коробки может использовать абстрактные типы. Т.е., фактически, мы имеем функционал, аналогичный действительно важным возможностям шаблонных классов из Си++.
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (222), 27-Сен-24, 00:57
	Этот список с начала уже начал подгнивать. Mozilla выставила команду Раста на улицу, а Серво выпрашивает пожертвования чтобы не помереть окончательно. У остальных по списку тоже нет подвижек, даже Гугл отказался переписывать старый код потому что он (внезапно) и так безопасен.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	263. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (263), 27-Сен-24, 13:20
	> Mozilla выставила команду Раста на улицу Мозилла поувольняла плюсовиков тоже. Так что это просто показатель подгнивания самой мозиллы. Тем не менее, код на расте они писать продолжают и использовать: authenticator-rs, neqo, webrtc-sdp, application-services. > даже Гугл отказался переписывать старый код потому что он (внезапно) и так безопасен. Он был также дыряв как и новый на си. Просто за за годы, ценой тысяч человекочасов, большинство дыр из него вычистили. И повторять такую ошибку они не хотят, поэьтому новый пишется хорошо сразу.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (120), 28-Сен-24, 22:47
	> У остальных по списку тоже нет подвижек Ога, знаток ойтишечки. Например, та же клаудфларя уже более года использует Pingor'у, выкинув nginx на свалку и нарадоваться не может. Но Знатокам-наСИльникам с опеннета всё всегда не так или "нинужно" или "они все врут" или "это хелловрот". Ну что такое эти ваши пингора с нгинксом - тьфу и растереть, убогий хелловорд, правда? Ты за один вечер обычно по три таких пишешь на сишечке. И конечно по методикам, а потому без ошибок и безопасно.
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

123. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от Аноним (123), 26-Сен-24, 15:59
>Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительности на 95% за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции. Кто же им доктор! Я не представляю, зачем sandbox-изолировать сериализацию (не путать с десериализацией).
Ответить | Правка | Наверх | Cообщить модератору

	138. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 26-Сен-24, 16:33
	Видимо, даже это не получится написать без опасности выйти за границы или переосвободить память.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (180), 26-Сен-24, 19:15
	Извините, у меня нет нематерных слов, чтобы прокомментировать такое.
	Ответить | Правка | Наверх | Cообщить модератору

136. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
Сообщение от anonymous (??), 26-Сен-24, 16:32
Это факт, из за того что последние годы больше внимания уделяют всяким статическим анализаторам я уже и забыл когда в Федоре что то падало. Имена разработчиков ключевых знал, багзиллу и рассылки мониторил. Причём это все на самом деле "тихо и незаметно". Раньше наизусть длиннющие пароли багзиллы вбивал лихо, переживал как там мой багрепорт может что то спрашивают и надо потестировать. Недавно приспичило и всё - бумажка с паролем засалилась упала за стол и не прочитать треть букв кранты аккаунту. И самое главное новый незачем создавать - да оно просто работает . Скучно как то. А что будет когда ядро переведут на микроядерное с этими самыми проверками теоремами или как их там. Realtime в ядре следующем. Будущее светло и прекрасно.
Ответить | Правка | Наверх | Cообщить модератору

144. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
Сообщение от Аноним (144), 26-Сен-24, 16:52
>В общем виде Google рекомендует не переписывать старый код, а сосредоточиться на написании нового кода на языках безопасно работающих с памятью и обеспечении переносимости между новым и старым кодом. >Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительности Взаимоисключющие параграфы обнаружены
Ответить | Правка | Наверх | Cообщить модератору

	148. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 17:08
	> Взаимоисключющие параграфы обнаружены Где? "В общем виде Google рекомендует не переписывать" Возможно генератор QR-кодов не попал в эту категорию и его было проще переписать, чем исправить.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (211), 26-Сен-24, 23:08
	>и его было проще переписать, чем исправить Тогда нужно другую формулировку - "не переписывать, а заменять на новый код". Поскольку сейчас это "стой там иди сюда".
	Ответить | Правка | Наверх | Cообщить модератору

152. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от Аноним (115), 26-Сен-24, 17:13
Оставлю тут, а то у модера крит. дни. > А если аппа падает с SIGABRT'ом? > Или удаляет пользовательскую базу? > Это дело ИБшников или программер просто криворукая камака? Все это может происходить от неопределенного поведения, а что у вас в мат формулах должно происходить при делении на 0, если вы это деление не определили строго? В чем вина программиста, если ваша вычислительная архитектура заведомо не безопасна? > Мне казалось что деньги можно просить за корректно написанный код. За овнокод > просить что-то вообще неприлично. просят - попрошайки! А "корректно написанный код" - должен быть подвергнут верификации (валидация), а теперь фокус - чтобы это проделать, необходимо иметь спецификацию (эталон) того кода, который программист "накодит" на том или ином безопасТном ЯП. И как вы, я думаю догадались, верификация так же не в ходит в обязанности программиста, как и вопросы связанные с безопасностью этого кода.
Ответить | Правка | Наверх | Cообщить модератору

	155. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Анонимусс (-), 26-Сен-24, 17:23
	> Все это может происходить от неопределенного поведения А может и не происходить) Может пограммист думал во время работы как подкатить к красивой коллеге из отдела маркетинга и забыл прибавить индекс. Или просто использовал не тот тип, как было например с курлом - 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 Но ты и дальше можешь пороть чушь.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (115), 26-Сен-24, 17:31
	> как было например с курлом Ну и у кого он "попросил" за этот кусок кода денег? что захотел то и написал, в чем проблема? У вас что-то пошло не так из-за этого кода? Так это ваша проблема. > Но ты и дальше можешь пороть чушь. По вашим просьбам :)
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (115), 26-Сен-24, 18:01
	а эта картинка, как раз адресована вам! https://daniel.haxx.se/blog/wp-content/uploads/2024/07/Danie...
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

154. "Методы безопасной работы с памятью позволили существенно сни..."	+4 +/–
Сообщение от Диды (?), 26-Сен-24, 17:20
Проблема rust не в том, хороший он или плохой, языков много и разных. Проблема в том, что фанаты rust не хотят сами писать на rust, они хотят окружающих заставить на нём писать.
Ответить | Правка | Наверх | Cообщить модератору

	156. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (-), 26-Сен-24, 17:25
	> Проблема rust не в том, хороший он или плохой, языков много и разных. Думаю ты поддельный дед) > Проблема в том, что фанаты rust не хотят сами писать на rust, они хотят окружающих заставить на нём писать. Эээ? Вон гугл сам пишет. Как и в теме про  POSIX и декодировщик AV1. Там ребята сами взяли и переписали. Но аноны все равно не довольны.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Диды (?), 26-Сен-24, 17:43
	>Думаю ты поддельный дед) Не, это только борода у меня приклееная, а свитер с вытянутыми рукавами самый что не на есть настоящий >Как и в теме про  POSIX и декодировщик AV1. Там ребята сами взяли и переписали. >Но аноны все равно не довольны. Ну что тут скажешь - переписали - молодцы! Не понятно, какую проблему они при этом решили, оставив весь asm, но я как настоящий дид, за кодинг ради кодинга, а там хоть на brainfuck
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (-), 26-Сен-24, 17:50
	> Ну что тут скажешь - переписали - молодцы! Не понятно, какую проблему они при этом решили, оставив весь asm, Уменьшили кол-во кода, где может быть баг по памяти, на кол-во строк написанных в safe rust. Например до АСМа код, читающий юзерский ввод или аргументы из командной строки просто не дойдет, в случае если там будет какая-то чушь. > но я как настоящий дид, за кодинг ради кодинга, а там хоть на brainfuck О! а это здравый подход, уважаемо. Но все равно не понятно? почему другие анонимы так горят, от того что гугл в своем проекте какие-то эксперименты проводит ¯\_(ツ)_/¯.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от bOOster (ok), 26-Сен-24, 19:10
	И какой смысл от этого переписывания?? Переписали потенциально безопасные участки кода на rust, оставив потенциально опасные в оригинале? Красавцы.. Хехехе.. Как звезднополосатые, если им выгодно - называют белое черным и наоборот..
	Ответить | Правка | Наверх | Cообщить модератору

	200. Скрыто модератором	+/–
	Сообщение от Аноним (-), 26-Сен-24, 21:44
	> Переписали потенциально безопасные участки кода С чего это код на дыряшке стал "потенциально безопасным"? Может "теоретически небезопасным"? Или "если повезет безопасным"? Или даже "мамкой_клянусь_там_нет_cve безопасным"? Вот они и переписали потенциально дырявый код на безопасный rust. А асм не трогали. Но все равно буде не хуже чем в оригинале. Потому что оригинал использует тот же асм.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Сен-24, 19:23
	> Как и в теме про  POSIX и декодировщик AV1. Там ребята сами взяли и переписали. Ну да, просто взяли и переписали?) Цитаты из той новости: > не планирует обеспечивать совместимость с утилитами GNU, функциональность которых воспринимается авторами как необоснованно раздутая > В настоящее время 55 развиваемых проектом утилит соответствуют POSIX и находятся на стадии покрытия тестами, в 22 утилитах обеспечена необходимая функциональность (но пока не реализовано покрытие тестами), 20 находятся на стадии чернового варианта, а работа над 44 утилитами ещё не начата.
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	224. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (222), 27-Сен-24, 00:25
	> не планирует обеспечивать совместимость с утилитами GNU То есть не планируют становится полноценной заменой? Ну хоть честно заявили.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (115), 26-Сен-24, 17:25
	> они хотят окружающих заставить на нём писать Ну и всякие "святые диды" в "крестовые походы" не ходили.
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	179. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от bOOster (ok), 26-Сен-24, 19:12
	Да никто не ходит, все на диване сидят. rust даже близко не подошел и не подойдет чтобы дидов с дивана сорвать...  :))
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (186), 26-Сен-24, 19:36
	Ну так наверно они бы еще хотели чтобы за это им ещё и платили. Вопрос денег вроде не самый последний и это уже не к обществу которое не хочет на нем писать, а к работодателям, которые н ее хотят дать.
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

160. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
Сообщение от Аноним (164), 26-Сен-24, 17:41
Ну и славно, ждём Safe C++ и не паримся.
Ответить | Правка | Наверх | Cообщить модератору

	214. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 23:22
	Угу. Осталось всего лет 10. Или пятнадцать. Смотря как быстро комитет будет чесаться. Но вот как только примут, так ух! нужно будет дождаться поддержки в компиляторах. А вот тогда и наступит вселенское счастье!
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (222), 27-Сен-24, 00:26
	Так уже работа идет во всю, пригласили талантливых ребят. https://www.opennet.dev/opennews/art.shtml?num=61878
	Ответить | Правка | Наверх | Cообщить модератору

	302. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 08:29
	Сроки от этого не станут короче.
	Ответить | Правка | Наверх | Cообщить модератору

162. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от Аноним (162), 26-Сен-24, 17:44
>For example, memory safety bugs are effectively prevented by memory-safe languages such as Java, Go, and Rust. Вкратце, чтобы не читать их пдфки.
Ответить | Правка | Наверх | Cообщить модератору

183. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 26-Сен-24, 19:27
> Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительности на 95% за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции. Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее всяких растов. Во-вторых, на кой там скорость? Вывод: очередные желтые новости. Переписали бы тогда подсистему изоляции как раз на расте.
Ответить | Правка | Наверх | Cообщить модератору

	187. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 19:37
	> Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее > всяких растов. Во-вторых, на кой там скорость? Вывод: очередные желтые новости. Это того самого ядра которое дырявое и бедняга Торвальдс ноет что за 33 года даже memory management не осилили? Из андроида выкинули io_uring как раз про причине "высокой калификации" разработчиков ядра. opennet.ru/opennews/art.shtml?num=59297 > Переписали бы тогда подсистему изоляции как раз на расте. Может и перепишут. А может нет.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Сен-24, 22:34
	>> Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее >> всяких растов. Во-вторых, на кой там скорость? Вывод: очередные желтые новости. > Это того самого ядра которое дырявое и бедняга Торвальдс ноет что за > 33 года даже memory management не осилили? Ссылки в студию! > Из андроида выкинули io_uring как раз про причине "высокой калификации" разработчиков ядра. > opennet.ru/opennews/art.shtml?num=59297 Причем тут урина? И почему по ней ты судишь обо всех? >> Переписали бы тогда подсистему изоляции как раз на расте. > Может и перепишут. А может нет. Ну вот в том то и дело, что переписывают всякую ерунду. Понятно почему.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 23:21
	> Ссылки в студию! 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 написана, я не проверял. Но на что бы ты ее не переписал - накладные расходы на сам сендбоксинг останутся.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Сен-24, 23:40
	>> Ссылки в студию! > 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 кодов в секунду?
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 23:50
	> А что это если не желтизна? Что ты умолчал, что это было сказано ответ по поводу помощи AI? Что? Где там AI? Там предыдущий абзац про real-time Linux project. Ты вообще читать умеешь?
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (258), 27-Сен-24, 12:35
	> Обязательно все использовать из ядра? В uring есть > проблемы, вот и выкинули. А что на раст не переписали тогда?) Почему не переписать? Потому что закостенелые диды всеми силами пытаются не пустить раст в ядро. > Далеко не все разрабы ревьювят все. А про всех речь и не шла. Но такие все равно есть. > Ну дак ты проверь. Зачем? Еще раз - любой сендбоксинг добавляет накладных расходов. А код на расте - нет. > Вот мы возвращаемся с чего начали. Зачем мне в генерации QR кодов > какая-то скорость? Надо генерить 1000 QR кодов в секунду? Действительно! Зачем скорость если можно тормозить и жрать батарейку сендбоксом. Вопросов больше нет...
	Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

	265. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 27-Сен-24, 14:06
	>> Обязательно все использовать из ядра? В uring есть >> проблемы, вот и выкинули. А что на раст не переписали тогда?) > Почему не переписать? Потому что закостенелые диды всеми силами пытаются не пустить > раст в ядро. Правильно делают. Можно же патчи наложить свои. Но не делают. Для всех очевидно почему кроме фанатов раста. >> Ну дак ты проверь. > Зачем? Еще раз - любой сендбоксинг добавляет накладных расходов. > А код на расте - нет. он небезопасен, уже выше это обсудили. Раст != изоляции. >> Вот мы возвращаемся с чего начали. Зачем мне в генерации QR кодов >> какая-то скорость? Надо генерить 1000 QR кодов в секунду? > Действительно! Зачем скорость если можно тормозить и жрать батарейку сендбоксом. > Вопросов больше нет... Замеры есть? Давайте тогда выкинем изоляцию совсем.
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 14:24
	> Правильно делают. Можно же патчи наложить свои. Но не делают. Для всех очевидно почему кроме фанатов раста. Ты Торвальдса туда же записываешь или "это другое" > он небезопасен, уже выше это обсудили. Раст != изоляции. Изоляция != безопасноть. Подтверждается кучей багов с выходом из сендбоксинага. А вот код на расте безопаснее чем код на СИ или плюсах - показано гуглом.
	Ответить | Правка | Наверх | Cообщить модератору

	274. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 27-Сен-24, 15:55
	>> Правильно делают. Можно же патчи наложить свои. Но не делают. Для всех очевидно почему кроме фанатов раста. > Ты Торвальдса туда же записываешь или "это другое" Что ты хочешь с него, он же на зп корпорастов сидит. Крутится как может, вот уже ругаться в рассылках ему запретили. Надо смотреть на тех, кто не сидит и говорит что хочешь. >> он небезопасен, уже выше это обсудили. Раст != изоляции. > Изоляция != безопасноть. Facepalm Закачнивай уже сравнивать разные уровни. Не важно на чем написан софт (то, за что топишь ты), его следует запускать в изоляции (то, за что топлю я). > Подтверждается кучей багов с выходом из сендбоксинага. Багов, которые обошли сэндбокс, сильно меньше. Доказано гулом (с). > А вот код на расте безопаснее чем код на СИ или плюсах > - показано гуглом. Каким местом? Ты не графики смотри рекламные, а открой код проекта и посмотри кол-во кода на С++ там по сравнению с другими.
	Ответить | Правка | Наверх | Cообщить модератору

	275. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 16:07
	> Facepalm Закачнивай уже сравнивать разные уровни. Не важно на чем написан софт > (то, за что топишь ты), его следует запускать в изоляции (то, за что топлю я). А на чем у тебя будет написан софт, эту изоляцию обеспечивающий? Пока получаем такие великолепные новости: Уязвимости во FreeBSD, позволяющие повысить свои привилегии или обойти изоляцию гостевой системы opennet.ru/opennews/art.shtml?num=61838
	Ответить | Правка | Наверх | Cообщить модератору

	277. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 27-Сен-24, 16:29
	>> Facepalm Закачнивай уже сравнивать разные уровни. Не важно на чем написан софт >> (то, за что топишь ты), его следует запускать в изоляции (то, за что топлю я). > А на чем у тебя будет написан софт, эту изоляцию обеспечивающий? Без разницы. То, на чем проще собрать и сделать бутстрапинг. Я бы хотел видеать на guile scheme :) > Пока получаем такие великолепные новости: > Уязвимости во FreeBSD, позволяющие повысить свои привилегии или обойти изоляцию гостевой > системы > opennet.ru/opennews/art.shtml?num=61838 Опять же если брать в пример гугл, то посмотри сколько они платят за обычную уязвимость в хроме и сколько за обход сэндбокса.
	Ответить | Правка | Наверх | Cообщить модератору

	278. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 27-Сен-24, 16:31
	>>> Facepalm Закачнивай уже сравнивать разные уровни. Не важно на чем написан софт >>> (то, за что топишь ты), его следует запускать в изоляции (то, за что топлю я). >> А на чем у тебя будет написан софт, эту изоляцию обеспечивающий? Ну и в целом. Софт для изоляции конечный по функционалу. Софт, который запускается - нет. Первую часть проще сделать. Это как (простите) обеспечить безопасность WASM, чем всего кода, который будет там запускаться.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 17:04
	> Без разницы. То, на чем проще собрать и сделать бутстрапинг. Странно что слова "надежность" в твоих требованиях я не увидел. А хотя... не, не странно. Вот на чем БСДя написана? Там и бутстрапинг есть и собарать легко. А толку)? Может если ее писали бы на АДА, то работало бы оно без таких "особенностей" > Я бы хотел видеать на guile scheme :) Можешь попробовать написать. > Опять же если брать в пример гугл, то посмотри сколько они платят > за обычную уязвимость в хроме и сколько за обход сэндбокса. Естественно за сендбоксинг больше. Но если он будет не нужен, без потери качества, то можно будет платить меньше.
	Ответить | Правка | К родителю #277 | Наверх | Cообщить модератору

	195. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 26-Сен-24, 20:52
	> Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее всяких растов. Неее, sandbox не для тех случаев. Он не для того, чтобы программерские баги исправлять, а для того чтобы недоверенный код крутить. Насчёт будет ли надёжнее, тут мне сложно сказать. Может если таким костылём использовать, обороняясь от своей неспособности писать надёжный код и исходя из того что злоумышленной активности не будет, будут просто глупости, то может и надёжнее.
	Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

	204. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Сен-24, 22:32
	>> Как бы sandbox изоляция делается на уровне ядра, а это 100% безопаснее всяких растов. > Неее, sandbox не для тех случаев. Он не для того, чтобы программерские > баги исправлять, а для того чтобы недоверенный код крутить. Если так думать, то все процессы в системе доверенные и можно и без изоляции жить. > Насчёт будет ли надёжнее, тут мне сложно сказать. Может если таким костылём использовать, > обороняясь от своей неспособности писать надёжный код и исходя из того > что злоумышленной активности не будет, будут просто глупости, то может и > надёжнее. Что такое "надежный код"? Формально верифицированный? Боюсь тебя тогда расстроить, что весь код в твоей системе с большой вероятностю ненадежный. К тому же и формально верифицированном коде есть баги реализации.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 00:06
	> Если так думать, то все процессы в системе доверенные и можно и без изоляции жить. Они доверенные, во всяком случае те, которые ты из репов дистра ставишь, но они бажные, то есть не надёжные. > Что такое "надежный код"? Формально верифицированный? У тебя путаница тут просочилась. Надёжный код, это код на который можно положиться. Который выполнит то, что ему следует выполнить, и ничего другого. А формальная верификация один из  инструментов достижения надёжности, а вовсе не определение надёжного кода. > весь код в твоей системе с большой вероятностю ненадежный. Ты так говоришь, будто возомнил что какое-то великое и неизвестное мне открытие до меня доносишь. Это общее знание, которым владеет любой хомячок. > К тому же и формально верифицированном коде есть баги реализации. И ты конечно же можешь накидать примеров таким багам реализации в формально верифицированном коде? Или ты в дополнение к предыдущей путанице заодно путаешь выводы из своих умозрительных рассуждений с фактами? Если так, то ты осторожнее, ты в одном шаге от того, чтобы полагаться на циклические логические цепочки.
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 27-Сен-24, 03:10
	>> Если так думать, то все процессы в системе доверенные и можно и без изоляции жить. > Они доверенные, во всяком случае те, которые ты из репов дистра ставишь, > но они бажные, то есть не надёжные.' Вообще нет. Нельзя доверять. >> Что такое "надежный код"? Формально верифицированный? > У тебя путаница тут просочилась. Надёжный код, это код на который можно > положиться. Который выполнит то, что ему следует выполнить, и ничего другого. > А формальная верификация один из  инструментов достижения надёжности, а вовсе > не определение надёжного кода. Ну тогда предложи как проверить надежность, а не абстрактные определения. Или хочешь сказать, что код на расте по умолчанию надежен?) Но вот нет. >> весь код в твоей системе с большой вероятностю ненадежный. > Ты так говоришь, будто возомнил что какое-то великое и неизвестное мне открытие > до меня доносишь. Это общее знание, которым владеет любой хомячок. Видимо ты нет раз пишешь чушь. >> К тому же и формально верифицированном коде есть баги реализации. > И ты конечно же можешь накидать примеров таким багам реализации в формально > верифицированном коде? Или ты в дополнение к предыдущей путанице заодно путаешь > выводы из своих умозрительных рассуждений с фактами? Если так, то ты > осторожнее, ты в одном шаге от того, чтобы полагаться на циклические > логические цепочки. Да легко. Читай любая криптография формально верифицирована, но в реализации есть куча багов.
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 21:13
	> Вообще нет. Нельзя доверять. Что ж ты тогда запускаешь его, если нельзя доверять? А? Хочешь я скажу тебе, почему ты это делаешь? Потому что, во всей этой цепочке поставки программ от непосредственных разработчиков и через мейнтейнеров, довольно сложно проталкивать злоумышленный код. И поэтому ты доверяешь этим программам работать на твоём компе без всяких там сандбоксов. Ты не запускаешь их из-под рута, но от этого тебя останавливают другие опасения, типа чуть не то сделал, и всю систему похоронил, то есть ты от себя защищаешься таким образом. То есть у тебя есть некая модель угроз, и ты оцениваешь с её точки зрения, насколько можно доверять софту. Но затем, чтобы выглядеть не желтоклювым наивным юнцом, но прожжёным циничным мужем, ты говоришь "вообще нет, нельзя доверять", несмотря на то, что жить согласно этой максиме ты даже не пытался, и когда дело доходит до дела, ведёшь себя как тот самый желтоклювый наивный юнец. > Ну тогда предложи как проверить надежность, а не абстрактные определения. Нет 100% способа проверить надёжность. Если вкратце, полнота по Тьюрингу под ногами путается, если более подробно, то тебе сюда: https://pron.github.io/posts/correctness-and-complexity Иногда, в некоторых случаях проверить можно. И не в смысле потыкать палочкой, "не падает? => надёжно", а в смысле взять и доказать. Иногда можно. Но для этого требуется очень специфически писать код, так чтобы на порядки снизить сложность доказательств. И то, не гарантия, что удастся доказать. И вот на этом моменте, люди говорят "идеальная надёжность конечно хорошо", но... И начинают выдумывать модели угроз, и проверять надёжность в каком-то ограниченном варианте. Но даже если речь пошла об этом, не получится ставить знак равенства между формальной верификацией и надёжностью. > Или хочешь сказать, что код на расте по умолчанию надежен?) Нет, не хочу. Почему вдруг ты подумал, что я хочу такое сказать? > Читай любая криптография формально верифицирована, но в реализации есть куча багов. Не канает за пример, у тебя опять путаница из головы полезла. То что алгоритм формально верифицировали, а потом написали наотвали реализацию этого алгоритма пригодную для практики -- это не формальная верификация программы, это формальная верификация алгоритма. Формальная верификация программы -- это формальное доказательство того, что программа соответствует определённым свойствам. Если мы говорим про крипту, то это их какие-то криптографические свойства.
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 30-Сен-24, 01:00
	>> Вообще нет. Нельзя доверять. > Что ж ты тогда запускаешь его, если нельзя доверять? А? Я запускаю в изоляции много софта.
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 30-Сен-24, 01:00
	> Хочешь я скажу тебе, почему ты это делаешь? Потому что, во всей > этой цепочке поставки программ от непосредственных разработчиков и через мейнтейнеров, > довольно сложно проталкивать злоумышленный код. Ха-ха-ха. Мейнтейнеры тебе код анализируют что-ли? Да большинство бинари просто перекладывают и то хорошо. Как по твоему уязвимости в пакеты попадают, а потом еще и обновления по security каналам этих же пакетов приходят?
	Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

	329. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 30-Сен-24, 01:02
	>> Ну тогда предложи как проверить надежность, а не абстрактные определения. > Нет 100% способа проверить надёжность. Если вкратце, полнота по Тьюрингу под ногами > путается, если более подробно, то тебе сюда: https://pron.github.io/posts/correctness-and-complexity У тебя путаница в опеределниях. Зачем ты говоришь про надежность, а кидаешь ссылки на корректность? Для тебя это одно и тоже?
	Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

	330. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 30-Сен-24, 01:09
	>> Читай любая криптография формально верифицирована, но в реализации есть куча багов. > Не канает за пример, у тебя опять путаница из головы полезла. То > что алгоритм формально верифицировали, а потом написали наотвали реализацию этого алгоритма > пригодную для практики -- это не формальная верификация программы, это формальная > верификация алгоритма. Нормальный это пример. Да даже если делать все как ты говоришь, то баг может быть вообще в используемой библиотеке. А все это к чему приводит? К тому, что нужна изоляция.   > Формальная верификация программы -- это формальное доказательство > того, что программа соответствует определённым свойствам. Если мы говорим про крипту, > то это их какие-то криптографические свойства. Ну вот написали реализацию, свойства соблюдены. А cve все равно вылезло.
	Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

184. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от А769ноним (?), 26-Сен-24, 19:32
Нужно более тесное сотрудничество разработчиков архитектуры процессоров, ОС и средств разработки - все это по сути складывается в одну систему. И ко всему этому обязательно: >>  использование языков программирования, обеспечивающих безопасную работу с памятью, применение статических анализаторов и проектирование API с оглядкой на безопасность. В целом во многих языках есть вполне безопасные подходы.
Ответить | Правка | Наверх | Cообщить модератору

	189. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (189), 26-Сен-24, 19:46
	Ада тоже не идеально, как оказалось. В конечном счёте, корпоративный программист -- это слабое звено. Наиболее безопасным и протестированным является си, теперь ещё спарк добавился. Но писать прикладуху ты ни на том ни на другом не захочешь (и никого не заставишь).
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 12:14
	> Наиболее безопасным и протестированным является си Он же дырявый как сито! > Ада тоже не идеально, как оказалось Потому что на ней писать сложнее чем 6ыдлокодить на сишке. Что тогда, что сейчас нужно хк-хк-и-в-прод. А на сишке можно научить писать даже обезьяну. Вот такое PHP 90х. Кроме того у Ада были "сложности" с компилятором - нужно было соответствовать требованиям и проходить тесты чтобы называться "компилятор Ада". А для си можно было что угодно назвать "компилятор си"
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (189), 27-Сен-24, 12:55
	Весь критический софт ищется на си уже много десятилетий. Проблема не в языке. Ну теперь ещё пишется на ада и транслируется в си. Может быть, дело в том, что писать качественный код скучно и неудобно.
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 13:14
	> Весь критический софт ищется на си уже много десятилетий. Хм.. может проблема в том, что чистый СИ плохо подходит для критического софта? Т.к для реально надежных систем приходится вводить доп. ограничения типа MISRA. Strictly conformance убивается наличием хотя бы одного UB. А ты видел программу на СИ без UB))? Но на безопасность можно и забить, у нас же софт AS IS. > Проблема не в языке. Неа, как раз именно в языке, раз приходится вводить кучу правил и ограничений, и например запрещать динамические аллокации. Т.е для серьезных проектов подходить только очень маленькое подмножество языка, да еще и с жесткими ограничениями. Я уже молчу про то, что банальная смена компилятора может поменять работу программы. > Ну теперь ещё пишется на ада и транслируется в си. "теперь"? На аде пишут с 80х. И ее создание это пример как нужно делать ЯП. Чего только стоит запрет выпускать трансляторы языка, не прошедшие официальную процедуру тестирования на соответствие стандартам (1000+ тестов). > Может быть, дело в том, что писать качественный код скучно и неудобно. Или дорого. А побыстрячку набацать код просто.
	Ответить | Правка | Наверх | Cообщить модератору

	271. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (189), 27-Сен-24, 14:47
	Spark это gcc, так что "теперь" это не "тогда", да и провалы учтены. А что до си, ограничения всё равно необходимы. Это типичные ограничения встраиваемых устройств, ничего сверхъестественного. Т.е. возможность избегать ошибок вполне существует. Или дёшево пиши эффективный код, но ошибки будут.
	Ответить | Правка | Наверх | Cообщить модератору

	316. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (120), 28-Сен-24, 23:00
	> Нужно более тесное сотрудничество разработчиков архитектуры процессоров, ОС и средств разработки - все это по > сути складывается в одну систему. > И ко всему этому обязательно: >>  использование языков программирования, обеспечивающих безопасную работу с памятью... А, Вы про Apple со свифтом? Вы их маркетолог?
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

190. Скрыто модератором	+/–
Сообщение от pavlinux (ok), 26-Сен-24, 19:49
Не вижу графиков сравнения производительности  FLOPS/MHz, SpecInt/MHz А тож понапихают ковно года на растишке, а ты покупай новые грелки воздуха
Ответить | Правка | Наверх | Cообщить модератору

191. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от pavlinux (ok), 26-Сен-24, 19:58
>  переписывание в Chromium кода для генерации QR-кодов на языке Rust > позволило добиться повышения его производительности на 95% за счёт > избавления от накладных расходов, вызванный необходимостью применения > дополнительной sandbox-изоляции. У меня на С и X API, QR код генерился 150 мкс, на ущepбном AMD Geode!!! Это было лет 10 назад,  тогда люди еще не знали что такое QR
Ответить | Правка | Наверх | Cообщить модератору

	206. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Сен-24, 22:36
	>>  переписывание в Chromium кода для генерации QR-кодов на языке Rust >> позволило добиться повышения его производительности на 95% за счёт >> избавления от накладных расходов, вызванный необходимостью применения >> дополнительной sandbox-изоляции. > У меня на С и X API, QR код генерился 150 мкс, > на ущepбном AMD Geode!!! > Это было лет 10 назад,  тогда люди еще не знали что > такое QR Такс. Выведите его из зала, он нам всех распугает.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (115), 26-Сен-24, 23:52
	вспомнился видос с жириком, Валера ну че ты ждешь, выведи его вон отсюда, вы посмотрите на его глаза, шизоид :)))
	Ответить | Правка | Наверх | Cообщить модератору

227. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от Аноним (222), 27-Сен-24, 00:39
Не знаю, о чем споры. Гугель в итоге рекомендует "языки программирования, обеспечивающие безопасную работу с памятью", а вовсе не только Раст.
Ответить | Правка | Наверх | Cообщить модератору

	237. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от СижуПежу (?), 27-Сен-24, 05:46
	Тогда почему не C#??!
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Василий Пупов (?), 27-Сен-24, 10:52
	Потому что гц
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (268), 27-Сен-24, 14:20
	А зачем гуголю рекламировать поделку конкурента.
	Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

257. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
Сообщение от Аноним (257), 27-Сен-24, 12:33
Я бы на месте гугла подумал не как убедить писать на Rust а почему на нем до сих пор все не пишут, если это так круто. Может синтаксис настолько гавно, что писать на нем можно либо если ты любитель bdsm либо из под палки(рабство оно всегда работает).
Ответить | Правка | Наверх | Cообщить модератору

	283. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (211), 27-Сен-24, 21:11
	Вот вам для примера немного c и c++ char *(*(**foo[][8])())[]; [&, i]{}; [=, *this]{ }; std::cout << var.property << "123\n"; printf("%d %s\n", a, b);
	Ответить | Правка | Наверх | Cообщить модератору

	288. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (288), 27-Сен-24, 21:59
	Красота!
	Ответить | Правка | Наверх | Cообщить модератору

	333. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (333), 03-Окт-24, 12:38
	Сколько лет комментарии на опеннете читаю, каждый раз недоумеваю: что им не так с синтаксисом раста? Причём, в англоязычной среде таких жалоб вообще не помню. А синтаксис C++ мне всегда казался кошмарным, ещё лет 25 назад, без всяких предвзятостей к нему. Меня в расте только точка-с-запятой как разделитель утверждений бесит, без неё код был бы заметно чище. Но так она и в Си есть.
	Ответить | Правка | К родителю #283 | Наверх | Cообщить модератору

	334. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (333), 03-Окт-24, 12:42
	А не, ещё подбешивает #[xxx(…)] - пальцеломная конструкция. В java/kotkin/scala/python оно сильно удобнее через @xxx(…)
	Ответить | Правка | Наверх | Cообщить модератору

267. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от anonimus (?), 27-Сен-24, 14:19
В порядке бренда, а-ля теория заговора. А если уязвимость целенаправленно внедрить в компилятор. Правда для этого нужно чтобы для языка была всего одна версия компилятора. Получится чудовищное количество уязвимого кода, а если язык ещё и супер безопасный, то уязвимый код ещё и без изоляцией будет запускаться.
Ответить | Правка | Наверх | Cообщить модератору

	270. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 14:30
	> А если уязвимость целенаправленно внедрить в компилятор. Сложно. Придется работать с кучей народу, плюс всякие Ferrocene будут тебе под руку заглядывать. Проще уже найти либу которая используется везде и внедрить туда какой-то бекдор. Типа XZ или CUPS. Причем бекдор может быть какой-то очень простой - ну забыли проверить входные параметры, это же с любым может случиться. > Правда для этого нужно чтобы для языка была всего одна версия компилятора. Но для раста как минимум 2 бекенда (llvm и cranelift) и есть альтернативные "фронты" -  mrustc. > Получится чудовищное количество уязвимого кода, а если язык ещё и супер безопасный, то уязвимый код ещё и без изоляцией будет запускаться. Так сейчас и так куча уязвимого кода.
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (211), 27-Сен-24, 21:08
	>Правда для этого нужно чтобы для языка была всего одна версия компилятора Давайте посчитаем, насколько велика монокультура на десктопе среднестатистического линуксоида: - 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.
	Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

	287. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (288), 27-Сен-24, 21:57
	>Получится чудовищное количество уязвимого кода Конечно, crates.io - просто свалка кода, доверять которому нельзя, поэтому в будущем эта проблема решится так же, как с Java, то есть фирмы, которые делают деньги на Rust toolchain'е (типа Ferrocene и AdaCore) будут поставлять свои Rust-компиляторы с репозитарием проверенных наиболее часто используемых библиотек.
	Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

	290. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 23:17
	> Конечно, crates.io - просто свалка кода, доверять которому нельзя, А если я нахожу какую-ту либу на гитхабе? Ну типа SQLite, FFMPEG или libwebp, как определить это классная либа или просто дырявый выпрограммыш каких-то дилетантов? > поэтому в будущем эта проблема решится так же, как с Java, то есть фирмы, которые делают деньги на Rust toolchain'е (типа Ferrocene и AdaCore) будут поставлять свои Rust-компиляторы с репозитарием проверенных наиболее часто используемых библиотек. Звучит классно. Хотя скорее будут смотреть по звездочкам или отзывам коллег)
	Ответить | Правка | Наверх | Cообщить модератору

	305. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (306), 28-Сен-24, 13:59
	>как определить это классная либа или просто дырявый выпрограммыш если эта либа есть в репозитарии Debian - значит хорошая. >Звучит классно я хотел сказать, что с Java'ой же точно такая же проблема, и она решена. AxiomJDK поставляется с репозитарием проверенных библиотек, если надо какую-то другую библиотеку - делается запрос, её проверяют и добавляют в репозитарий.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 28-Сен-24, 15:14
	>>как определить это классная либа или просто дырявый выпрограммыш > если эта либа есть в репозитарии Debian - значит хорошая. Хаха, скорее она старая и дырявая. Например этот забагованый кусок https://packages.debian.org/stable/web/squid "Squid выявлено 55 уязвимостей, 35 из которых пока не исправлены" opennet.ru/opennews/art.shtml?num=59915 Есть нехилый шанс, что они никогда их не починят "Разработчики Squid были уведомлены о проблемах ещё два с половиной года назад, но так и не завершили работу по их устранению." > AxiomJDK поставляется с репозитарием проверенных библиотек, если надо какую-то другую библиотеку - делается запрос, её проверяют и добавляют в репозитарий. Интересно, почему с либами на СИ и плюсах такого нету. То ли они сразу надежные (хехе), то ли просто плевать на качество.
	Ответить | Правка | Наверх | Cообщить модератору

	310. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (211), 28-Сен-24, 19:55
	>если эта либа есть в репозитарии Debian - значит хорошая. Дебиан это свалка устаревших версий без поддержки. https://packages.debian.org/buster/php7.3 7.3.31 https://www.php.net/eol.php 7.3.33 Они молча не осилили поднять на две версии. Сколько вообще таких пакетов в дебиане - открытый вопрос
	Ответить | Правка | К родителю #305 | Наверх | Cообщить модератору

281. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от Аноним (281), 27-Сен-24, 20:50
>В общем виде применение безопасных методов программирования преподносится как наиболее эффективная на сегодняшний день парадигма разработки Бедные Вирт, Хоар, Дейкстра всю жизнь убеждали индустрию в преимуществе надёжных языков и методов программирования, а индустрия над ними только смеялась. И вот только сейчас, после их смерти, индустрия поняла, что, оказывается, надёжное программирование - это выгодно
Ответить | Правка | Наверх | Cообщить модератору

	289. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (-), 27-Сен-24, 23:13
	> Бедные Вирт, Хоар, Дейкстра всю жизнь убеждали индустрию в преимуществе надёжных языков и методов программирования, а индустрия над ними только смеялась. Не правда. Например АДА создавалась как язык для военки с повышенными требования надежности. И делали его соответствующе - сначала собирали требования, а уже потом пилили язык. А когда выпустили, то разрешали впускать компиляторы, только после прохождения тестов (1000+ штук). Но распространение получила СИшка - язык для быстрого бдлокодинга, такой себе ПХП из 70х. Почему? Потому что на качество было плевать, как и сейчас. > И вот только сейчас, после их смерти, индустрия поняла, что, оказывается, надёжное программирование - это выгодно Еще нет) Пока поняли отдельные компании которые теряют деньги и пользователей. Те, кто привык делать бесплатно, но тяп-ляп, думаю еще долго рассказывать "ну работает же! ну иногда падает и дарит рут.. ну и чё?"
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (306), 28-Сен-24, 13:50
	C Адой всё понятно - создавалась по госзаказу для госнужд. С остальным согласен. Си и Unix сделали два программиста just for fun. Linux тоже just for fun. А теперь все мучаются с этими любительскими проектами
	Ответить | Правка | Наверх | Cообщить модератору

	320. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Диды (?), 29-Сен-24, 09:47
	>Си и Unix сделали два программиста just for fun. Linux тоже just for fun. А теперь все мучаются с этими любительскими проектами Что за бред? Кто мучается? Кто заставляет?
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от ZXCVBN (?), 29-Сен-24, 13:46
	> Вирт, Хоар, Дейкстра... только сейчас, после их смерти... Хоар ещё жив.
	Ответить | Правка | К родителю #281 | Наверх | Cообщить модератору

326. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
Сообщение от keydon (ok), 30-Сен-24, 00:33
> Изменения позволили снизить долю связанных с памятью уязвимостей в Android c 76% в 2019 году до 24% в 2024 году, что значительно ниже среднего показателя по индустрии - 70%. Напомню, в начале 2000ых этот же гугл говорил что java все сделает безопасным. В итоге андройд стал одной из самых дырявых систем. Прямо как сейчас с растом. > Для проектов Android и Chromium благодаря внедрению методов безопасной работы с памятью разница составляет 7.4 раза. Сильное утверждение. Проверять я это конечно не буду. Существует 2001 способ как подбить статистику. > Таким образом, если предотвратить появление ошибок при работе с памятью в новом коде, со временем в старом коде подобные ошибки будут выявляться всё реже и реже. Логическая ловушка. Событие А не гарантирует Б, а только возможно при многих допущениях. > Помимо снижения числа уязвимостей использование безопасных методов программирования повышает производительность разработки, позволяет добиться более высокого качества кода и положительно сказывается на производительности. Производительность против безопасности это классический трейдофф. Либо в гугле научились нарушать законы физики, либо кто-то опять врет. > Например, переписывание в Chromium кода для генерации QR-кодов на языке Rust позволило добиться повышения его производительности на 95% за счёт избавления от накладных расходов, вызванный необходимостью применения дополнительной sandbox-изоляции. Что говорит только о качестве предыдущей sandbox-изоляции. Опять логическая ловушка. Из А не следует Б. > В качестве примера приводятся показатели отката изменений - для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже, чем для кода на C++. Тоже простор для манипуляций. Кода на расте существенно меньше и вероятно он более свежий и применяется в менее важных подсистемах. Можно предположить что случайный код на С++ против случайного кода на расте имеет гораздо меньшее количество откатов чем в 2 раза. Примерно как в типичном дипломе: Намешаны кони, люди - и раст и методы безопасной работы с памятью и все это вместе смешали, помухлевали статистикой, поподбирали примеры. И вот студент уже гордо заявляет что без раста жить нельзя. В основном по той причине что его руководитель выбрал ему такую тему работы. Через год другой студент получит другую тему и также гордо будет заявлять что раст то не безопасен оказывается, а вот на хрясть2 нужно немедленно перейти, потому что менеджеры в гугле уже получили за него премии...
Ответить | Правка | Наверх | Cообщить модератору

335. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от Аноним (333), 03-Окт-24, 15:52
Как это недавно сказал Торвальдс на выступлении в Австрии: капризные сишники нехотящие переходить на раст напоминают ему холиварящих студентов, как в его молодости.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема