LINUX.ORG.RU
ФорумTalks

Google будет донатить на переписывание критически важных проектов на Rust

 , , ,


0

3

Анонс можно найти тут: https://security.googleblog.com/2021/02/mitigating-memory-safety-issues-in-open.html.

Основная причина — некорректное управление памятью. Значит ли это, что сишных дыреней станет меньше, или отточенные годами проекты превратятся в хеллоуворды на невзлетевшем языке? Интересно будет посмотреть.

Ответ на: комментарий от rbbtnspc

Сам с этим говном столкнулся. Даже раст скачал, но он не смог. Установил старую версию модуля. Прям безопасность во все поля.

xaizek ★★★★★
()
Ответ на: комментарий от deep-purple

чтобы не получилась в итоге деградация

Как насчет того, чтобы наоборот, в итоге отбросить лишний мусор?

Manhunt ★★★★★
()
Ответ на: комментарий от deep-purple

А можно пару историй успеха где реально перенесли все что было в том же виде и без кастрации? Причем жду не сколько про растишку, а вообще.

Первое что в голову приходит это docopt. Изначально вроде на питоне было написано, а перенесли на кучу языков. Мелочь конечно, но все же.

dvetutnev
()
Последнее исправление: dvetutnev (всего исправлений: 1)
Ответ на: комментарий от deep-purple

Но результат в фаерфоксе впечатляет. Ест ЦПУ и памяти намного меньше хрома, разработан с нуля меньшей по размеру командой.

Shadow ★★★★★
()
Ответ на: комментарий от Aswed

Тут эта, меня уже в Москве работать на расте зовут.

q0tw4 ★★★★
()
Ответ на: комментарий от Aswed

Очевидно, по ссылке речь об уязвимостях, связанных с некоректной работой с памятью.

andalevor ★★
()
Ответ на: комментарий от Manhunt

Почему мусор не был отброшен ещё в старой реализации?

deep-purple ★★★★★
()
Ответ на: комментарий от Harald

M$ уже сделал арктическое хранилище. Можно туда ещё сишников забэкапить, чтобы было кому поддерживать код после разморозки.

andalevor ★★
()
Ответ на: комментарий от Harald

Все так на утечках сконцентрировались, хотя Раст от них не защищает. Речь то про уязвимости из-за некорректной работы с памятью.

andalevor ★★
()
Ответ на: комментарий от andalevor

Я ни с чем не выступал, а просто высказал своё мнение основанное на своём опыте, вот и все. Я лично часто вижу говнокод куда опаснее чем утечки памяти, во вполне себе прикладных языках в которых проблемы памяти вроде как решены.

DawnCaster ★★
()
Последнее исправление: DawnCaster (всего исправлений: 1)
Ответ на: комментарий от andalevor

А при чём тут стартовый пост, если я вообще-то вел беседу с другим лоровцем. Мусье не умеет в контекст ? Объясните уж тогда мне глупому, о каком именно моём заявлении идёт речь, я их вообще много делаю.

И да, безопасное управление памятью в расте оно в том числе и про утечки памяти, это чуть-ли не главное что всегда всех разработчиков под раст волнует.

DawnCaster ★★
()
Последнее исправление: DawnCaster (всего исправлений: 2)
Ответ на: комментарий от rbbtnspc

Ну, в таком случае, раст ещё большее ненужно чем я думал.

DawnCaster ★★
()

А кто-нибудь вообще может припомнить, чтобы кампания по переписыванию на какие-то языки была успешной?

На мой взгляд успешным может быть только когда авторы конкретного проекта увидели что-то конкретно лучшее для себя, чтобы переписать. Не абстрактное «потому что лучше», а по пунктам чем лучше для конкретного проекта. Лучше, в том числе и в смысле оправданности потери времени и ресурсов на переписывание, которые можно было бы потратить на развитие без переписывания.

А так я уже видел подобные кампании, результат которых был сомнительным. Например, в 90-х кое-где ринулись переписывать матпрограммы на Fotrtan-е на Turbo pascal и Delphi. Сейчас на это только хмыкнуть можно. Переписывали также на Си и даже на Visual Basic (и такое видел).

В общем, спустя 20+ лет можно уверенно сказать, что кое-как оправдалось только переписывание на Си, да и то с оговорками. К примеру, у крупнейшей библиотеки численных расчетов NAG ее реализация на Fortran до сих пор как бы эталонная, в отличие от Си-версии. По большому счету, больше всего выиграли те, кто продолжали развивать научно-расчетную часть, а не увлекались более правильными языками.

praseodim ★★★★★
()
Ответ на: комментарий от Manhunt

Более половины реальных уязвимостей в ПО

А ты просто не путай уязвимости и ошибки. Тогда число проблем из-за утечек резко сокращается, раз так в 50

SR_team ★★★★★
()
Ответ на: комментарий от DawnCaster

А при чём тут стартовый пост

При том, что он как бы задаёт тему для обсуждения. Хотите обсудить утечки – создайте другую тему. Если же вы не разделяете уязвимости и утечки, то не вводите тех, кто будет всё это читать в заблуждение. Это не одно и тоже.

И да, безопасное управление памятью в расте оно в том числе и про утечки памяти

И нет, но выше уже дали ссылку.

andalevor ★★
()
Ответ на: комментарий от SR_team

Более половины реальных уязвимостей в ПО

А ты просто не путай уязвимости и ошибки. Тогда число проблем из-за утечек резко сокращается, раз так в 50

И какой ты хочешь сделать из этого вывод?

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Что основная проблема это логические ошибки, а уязвимости как правило в местах чтения/записи пакетов/файлов, и в расте там скорее всего будет такой же unsafe

SR_team ★★★★★
()
Ответ на: комментарий от Manhunt

Бензопилами продолжают резаться... Запретить бензопилы! :)

slackwarrior ★★★★★
()
Ответ на: комментарий от DarkEld3r

Ох, как гугл зачищает. Radim Řehůřek там запросил обещанную поддержку 11.12.2020. Ни одного ответа. Потом 18.02.2021 рассказал об этом на популярном публичном форуме, неподконтрольном гуглу. Тогда началось какое-то движение, которое вот так неожиданно закончилось. Цензурой.

gag ★★★★★
()
Ответ на: комментарий от praseodim

По большому счету, больше всего выиграли те, кто продолжали развивать научно-расчетную часть, а не увлекались более правильными языками.

Ну правильно, языками увлекаются компьютерные саентисты и кодеры-полиглоты, которым больше нечего предъявить кроме знания языков. А так на деле нужны очень очень веские причины, чтобы что-то большое и важное переписывать. Даже если там кобол какой. Потому что это неблагодарный и непродуктивный труд который хуже лени.

bread
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.