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

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

Сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	115. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
	Сообщение от Аноним (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ообщить модератору

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

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

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

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

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

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

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

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

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

	46. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
	Сообщение от Аноним (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ообщить модератору

	39. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Анонимусс (-), 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ообщить модератору

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

	169. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (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ообщить модератору

	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ообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	44. "Методы безопасной работы с памятью позволили существенно сни..."	+1 +/–
	Сообщение от Аноним (-), 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ообщить модератору

	35. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (35), 26-Сен-24, 13:57
	> А другие графики они не хотят показать? Там очевидно же, заменяешь четырёх сениур c++ маэстро, которые друг другу яйца по очереди простреливают на одного java/kotlin разработчика > Как изменилась стоимость разработки? Очевидно, стоимость сократилась > Сколько теперь нужно разрабов на тот же код. Очевидно же, один rust разработчик заменяет 3-4 дырявых сениур c++ маэстро
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

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

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

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

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

30. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
Сообщение от Перепишу (?), 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ообщить модератору

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

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

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

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

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

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

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

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

	224. "Методы безопасной работы с памятью позволили существенно сни..."	+/–
	Сообщение от Аноним (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.ru/opennews/art.shtml?num=61878
	Ответить | Правка | Наверх | Cообщить модератору

162. "Методы безопасной работы с памятью позволили существенно сни..."	–1 +/–
Сообщение от Аноним (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. "Методы безопасной работы с памятью позволили существенно сни..."	+2 +/–
Сообщение от Вы забыли заполнить поле 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. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 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ообщить модератору

	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ообщить модератору

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

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

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

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

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

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

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

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