Компания Google выступила с инициативой по решению проблем в открытом ПО, вызванных небезопасной работой с памятью. По данным Google 70% проблем с безопасностью в Chromium вызваны ошибками при работе с памятью, такими как обращение к буферу после освобождения связанной с ним памяти (use-after-free). Исследование Microsoft также пришло к выводу, что 70% всех уязвимостей, устранённых в изученных обновлениях программ, вызваны небезопасной работой с памятью. Ещё одно исследование показало, что 53 из 95 уязвимостей, выявленных в утилите curl, удалось бы избежать, если бы код был написан на языке, обеспечивающем безопасную работу с памятью...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54615
А давайте перепишем на раст?
И переименуем в rooster farm.
И нажарим окорочков.
И зальём лычи пивом.
И в каждое засунуть ядро НОД32.
А в каждый Нод - по Кейну.
Во имя Кейна!
Кенни умер.
А Фрактаил то был прав!
Что ж он про дотнет то молчал? Майкрософт примерно то же самое и про него рассказывал. Хотя на самом деле их интересовал, конечно, контроль за экосистемой. В хруст файндейшн то они своего директора уже пропихали :)
в раст фандейшн хотя бы нет директора от пейсбука, в отличии от
Я определенно пропустил этот момент. Что мелкософт рассказывал про фроктала?
Гарантию безопасности дает среда исполнения. Компилятор также важен.
# checksec -pl 1
# checksec -d /bin
# checksec -k# paxtest blackhat
Mode: blackhat
Linux fw1 2.6.34-hardened-r6 #1 SMP Mon Oct 4 02:32:46 CEST 2010 x86_64 Intel(R) Xeon(R) CPU E5520 @ 2.27GHz GenuineIntel GNU/LinuxExecutable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable stack (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments : Killed
Anonymous mapping randomisation test : 29 bits (guessed)
Heap randomisation test (ET_EXEC) : 35 bits (guessed)
Heap randomisation test (PIE) : 35 bits (guessed)
Main executable randomisation (ET_EXEC) : 27 bits (guessed)
Main executable randomisation (PIE) : 27 bits (guessed)
Shared library randomisation test : 29 bits (guessed)
Stack randomisation test (SEGMEXEC) : 35 bits (guessed)
Stack randomisation test (PAGEEXEC) : 35 bits (guessed)
Return to function (strcpy) : paxtest: return address contains a NULL byte.
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE) : Vulnerable
> А давайте перепишем на раст?Перепиши, я разрешаю. Можешь даже бесплатно попахать на гугл и майкрософт за идею :)
перепишут на Rust хром хаха мозилла отказалась
В Firefox новые модули на Расте написаны, внезапно, тот же вебрендер
Именно поэтому они так коряво работают.
Коряво это как?
не рендерят как надо
очевидно же
Линуксопроблемы-линуксопроблемушки. 😂 Наверное, снова какие-то дрова отломаны.Под виндой все отлично рендерит.
Только что-то виндовые юзеры послали его в пешее эротическое. Надоело им когда каждые пару версий дополнения слетают или интерфейс перекорежен. И остались они с сколькими там процентами... тремя, чтоли, уже? А скоро и этого не будет.
> Только что-то виндовые юзеры послали егоНу так послали давным давно, когда и Rust-а там и не было.
Да, тормоз без каких-то плюсов мало кому нужен был. Поэтому валили с него быстро.Сейчас уже не стыдно стало Firefox открывать, но вернуть обратно аудиторию не так просто.
Чет уже пять лет как дополнения не слетали. А их у меня около десятка.
Ты сам то пользуешься фоксом, или только языком чешешь?
Давай, расскажи мне как все прекрасно с дополнениями на мобильных устройствах.
А какие дополнения нужны, кроме имеющихся?У хромого и их нет. У ЯБраузера были раньше, да их полностью выпилили даже не знаю когда и зачем.
Ты пишешь какой-то бред. Сколько обновлений, ничего не косо....ло
Баг репорты открыл?
Открыл, посмотрел и закрыл.
> выступила с инициативой по решению проблем в открытом ПОраст решение всех проблем
Crystal и Rust.
> Google занялся продвижением средств безопасной работы с памятью в открытом ПО
> По данным Google 70% проблем с безопасностью в ChromiumЯсно. Расходимся.
Ну так это - директоров в фаундейшн пропихали. И гугл и майкрософт.
В прошлом (или позапрошлом?) году здесь пролетала новость с другими цифрами - 80% и 90%. И были ссылки на соотв. исследования гула и майкрософта.
А киньте ссылочку, пожалуйста, а то что-то трудно найти.
Ох, позор на мою голову, - сам не могу найти... Кучу статей с комментами пролистал. Помнится, что ссылки на гугл и мс были в комментах. У меня чётко отложилось, что по одной статистике было чуть больше 80, а по другой - в районе 90.
Да блин, уже давно все поняли. Не хочешь непрошеных пенетрации -- пиши Rust. Нет, всё ещё открывают Америку...
А не хочешь прошенных пенетрации -- пиши не на Rust
Наоборот же, двойное отрицание равносильно исходному выражению. Растоманы хотят только прошенных пенетраций, непрошенных не хотят, да только ж кто их спрашивать будет? Когда появится используемый хрустософт, будут и их пенетрировать.
Пока глупенькие хейтеры на опеннетике хейтят, крупные корпорации просто берут и используют :)
В прошлый раз они сделали реальностью nodejs и электрон. Мир еше как миниум десятилетие будет после этого будет приходить в себя.
> В прошлый раз они сделали реальностью nodejs и электрон. Мир еше как миниум десятилетие будет после этого будет приходить в себя.Электрон плохой, но UI через веб технологии - это, видимо, будущее. Работать надо в сторону оптимизации рантайма. Есть либа на расте - не помню как называется - которая рендерит UI через встроенный в ОС веб рендерер. На винде mshtml, на маке webkit или как там его, на линуксе не помню. В результате программа не тащит с собой браузер и код рендерера живёт в памяти в единственном экземпляре между приложениями. Хелоу ворд памяти ест очень мало. Вот в каком-то таком направлении оно и будет двигаться.
> В результате программа не тащит с собой браузер и код рендерера живёт в памяти в единственном экземпляре между приложениями.А по факту, каждая программа тащит с собой браузев в виде электрона :)
Не работает это так.
Проще в пакет завернуть электрон, чем следить за работой ПО в зоопарке нативных рендеров. Там ещё свои js интерпретаторы.Уже сейчас на пк обычных пользователей запущено несколько электронов (дискорды, скайпы и прочие). По сути браузеров.
> Уже сейчас на пк обычных пользователей запущено несколько электронов (дискорды, скайпы и прочие). По сути браузеров.Я в курсе. Я писал про то, что есть либа, которая пытается от этого уйти и такой подход лучше электрона. И что оптимизировать будут пытаться именно в эту сторону - такое вот предсказание. Лучше решения я не вижу.
Если вдуматься, то веб-рендеры - это и есть UI toolkit-ы, причём самые продвинутые в мире. Осталось только придумать, как сделать что бы они не жрали по 500мб на один пиксель. :)
https://github.com/tauri-apps/tauri
> https://github.com/tauri-apps/tauri«tiny, blazing fast binaries». изрядно пошутили.
вообще, потуги недоумков с уебом местами даже умиляют. даже жаль их немножечко: они так и не узнают никогда, что такое действительно небольшой и быстрый софт. жалко, но не очень. всё равно стрелять надо, и в голову, а то эти зомби кусаются.
Подожди, а если ты в свой бинарь вкомпилишь Qt или Gtk у тебя правда будет мизерный бинарь?
спасибо. я, было, подумал, что про «недоумков» немного перебрал. но ты пришёл — и сразу меня успокоил.
> Работать надо в сторону оптимизации рантайма.Эх, если бы Вы понимали, что вообще предлагаете... "ну и что, что банкиры жадные -- работать надо над печатанием новых долларов".
> Эх, если бы Вы понимали, что вообще предлагаете... "ну и что, что
> банкиры жадные -- работать надо над печатанием новых долларов".Что бы ответ был конструктивным и следовательно интерсным и обсуждаемым, в нём должны содержаться аргументы, а не просто "вы ничего не понимаете". :)
Согласен, но кроме ровно вот такой зарисовки (да, кривоватой аналогии, но уж какая вышла) -- у меня ничего не получилось сходу.Беда западных экономик -- заигрались в циферки. Беда информационных технологий -- заигрались в слои поверх слоёв. В обоих случаях -- уже десятилетиями в открытой фазе.
Тут бы наоборот -- к человеку думающему думать, как вернуться. А Вы предлагаете всех в макак украинизировать.
Внезапная Украина. :) Я вообще нечего не предлагаю, а предсказываю развитие технологий. Веб-рендер (не конкретный, а как концепция) - это и есть UI toolkit, самый мощный из существующих. За это надо платить памятью. Вот память и будут оптимизировать, а сам подход - html+css и то, что его рендерит скорее всего сохранится. Оно уже кроссплатформенное, оно уже умеет рисовать всё, что нужно - от 2д до 3д. Сам браузер не нужен конечно, а вот движок который рендерит страницы - нужно. И если эти движки уже существуют, зачем их писать заново? UI тулкиты всё равно в конечном счёте к этой функциональности сводятся. Надо только выкинуть оттуда лишнее, что бы например размер бинаря и занимаемой памяти зависел от конфигурации на стадии сборки. Ну или, если оно динамически подгружается, то разбить функциональность веб-рендера на отдельные сошки.Более того, никто же не говорит, что всё это надо обрабатывать строго в рантайме - можно html+css на стадии сборки во что-то более эффективное скомпилировать.
> И если эти движки уже существуют, зачем их писать заново?Например, затем, что помойки на стероидах несут слишком много проблем -- не только ресурсных, а и безопасности.
И даже не писать заново, а "всего лишь" не пихать круглое в квадратное.
> В прошлый раз они сделали реальностью nodejs и электрон.Дотнет еще забыл. Это от майкрософта. Там, кстати, тоже с памятью, типа безопасТно и даже, якобы, не течет. Только что-то в топе выхлопа по програмерским вопросам (вообще не про память) почему-то вылез вой дотнетчиков "как мне дебажить утечки памяти?!" :)
> в топе выхлопа по програмерским вопросамЭто на каком ресурсе?
Просто я .NET-разработчик, не видел такого.
И да, если тебя смущает количество вопросов ПО .NET на Stackoverflow, то мог бы и историю подучить - изначально там только .NET-разрабы и тусовались. Да и написан он на .NET.
Почему сразу хейтеры? Я например вполне lover, могу отыметь во все орифайсы.
Крупные корпорации часто берут что-то, и благополучно потом закапывают, забив на потраченные офиглиарды.
Потому что эксперимент. А вдруг. У гугла таких проектов похороненных - тьма тьмущая.
> У гугла таких проектов похороненных - тьма тьмущая.Да, только туда вписался ещё амазон, майкрософт, китайцы. А главное почему вдруг раст должны забросить непонятно. Это как переживать, что человечество вдруг от электричества откажется, а значит надо готовиться жить в избушке в лесу.
А в vr/ ar кого и сколько вписалось ?И тем не менее, оно все сильнее стопорится, нет уже той радости и инициативности от каждого кому не лень
То что это тебе всё ещё не по карману не означает, что индустрия не развивается. Либо хватит ныть попусту, либо накопи денег и купи себе уже нормальную VR-станцию.
>А главное почему вдруг раст должны забросить непонятнопотому что в реальности это убогий язык, достигающий мнимой безопасности не с помощью каких-то продуманных статических анализов, а тупо ограничивая то что там может написать программист. Причём это ещё и не зеро-кост.
Не, ну почему? Как раз часть они делают именно статическим анализом. И макросы любят, потому что сами по себе они не генерят код.Но увы, ориентация на вебмакак и хайп пополам с ублажением корпов и маркетоидов сильно загадили неплохую изначально идею. Пакетный манагер сразу в яп? С гуглом и мс в совете директоров хруса фаундейшн? Отличная заявка на попадалово. В корпоративное рабство этой сладкой парочки. Офигеть какая эпичная перспектива. Да еще синтаксис постоянно ломали и закорюк понавешали.
> не с помощью каких-то продуманных статических анализов, а тупо ограничивая то что там может написать программист.Весь компилятор - это статический анализатор. А не дать написать то, что приведёт к ошибке - в этом и есть смысл проверки.
> Причём это ещё и не зеро-кост.
Да, компиляция за 0 времени действительно трудно достижима. Если компилятор что-то делает, то это что-то занимает время.
> Причём это ещё и не зеро-кост.Пруфы, пожалуйста, а то сейчас это всего лишь вброс очередного неосилятора.
Rust как раз и отличается (от всех других ЯП с автоматическим управлением памятью) возможностью писать zero-cost абстракции, вопрос лишь в прямых руках пишущего.
> от всех другихвот это и есть максимально возможный уровень рустофанбоев. поэтому их никто серьёзно и не воспринимает.
>> от всех других
> вот это и есть максимально возможный уровень рустофанбоев. поэтому их никто серьёзно и не воспринимает.А вырывание фразы из контекста - это норма среди растохеётеров, да? Был необоснованный вброс без пруфов про конкретный аспект, я уточнил, как обстоит на самом деле. Что не так а том, что я написал? Только давай без вырывания из контекста.
контекст отлично виден прямо выше цитаты. но я понимаю, что для хрустиков его найти — непосильная задача.
> от всех другихИ какой контекст у этот "цитаты"? Нет уж, поясни за базар, обоснуй своё право оскорблять эвфемизмами.
И ты так и не ответил, что было не верно. Лишь вырвал из контекста. Кстати, раз он так виден, то напиши, что в том контексте некорректно.
Опровержение, пожалуйста, а то ты со своим D тут вообще ни разу не написал конструктивного комментария с приведением пруфов, желательно со ссылками. Лишь одно кукарекание "рустофанбои!", "зрустики!", "недоумки!", "дураки!".
Давай либо конструктив, либо хотя бы хватит оскорблять народ направо и налево.
у них куча бабла и человекочасов на всякие развлечения. это не значит что за ними нужно повторять как мартышка. у тебя не те задачи и не те ресурсы.
Переписыванием или написанием программы на расте занимаются разработчики, когда считают это целесообразным. А считают так многие. Альтернатив нету. Когда появятся - могут уйти на другой язык, но в этом суть прогресса - старое выкидывают, берут улучшенное новое.
> занимаются разработчики, когда считают это целесообразнымВ гугле.. конечные разработчики что-то всерьёз решают.. ну-ну :)
А в итоге окажется, что часть разрабов в конторе пока просто нагрузить нечем - вот их на переписывание того что уже работает и отправляют. Гуглу то пофиг - он все равно им зп платит, только иначе платил бы за совсем ничегонеделанье, а так - хоть какая-то работа делается. Крч он ничего не теряет
> Когда появятся - могут уйти на другой язык, но в этом суть прогресса - старое
> выкидывают, берут улучшенное новое.Да вот, блин, ДВС пытаются выкинуть из карет лет уже наверное 150. Можно конечно орать что электромобили новее и лучше, но облом в том что они почти ровесники.
И получается что ни то ни другое никто не выкидывает - а просто полтора века допиливают технологию до кондиции.
Кэп намекает что взять технологию и кучу раз ее улучшить - ведет к лучшему результату чем все сломать, и кучу раз все переписать заново. Но да, это ж не эпично, и вообще, рутинная инженерная и техническая работа. То ли дело с горящими глазами графики (предполагаемых, лол) профитов и улучшений чертить (известно чем) на стенах. Мозилла это и делала 15 лет, а потом уволила всех :)
> взять технологию и кучу раз ее улучшить - ведет к лучшему результату чем все сломать, и кучу раз все переписать заново.То, что можно было улучшить ничего не сломав, давно уже было улучшено - через valgrind, анализаторы кода, fuzz testing и прочее. Потолок возможного достигнут. 50 лет Си - думаю достаточно для заторможенного прогресса.
Если код будет работать медленнее - это правда прогресс?
Смотря что ты получаешь за это замедление. Вон интеловые процессоры какие быстрые, а что в итоге?В каких случаях раст медленнее сей, кстати? При одинаковой корректности программы, конечно.
С чего ты взял что интересы крупных корпораций совпадают с твоими?
Крупные корпорации, не "берут и используют", а проплачивают и ъ проталкивают это г*но, (вернее проталкивают переписывание на это г*но) и при чём делают это подозрительно настойчиво, с примерами статистики хреновости других языков и сетованием на небезопсный язык, хотя статистики безопасности самого раста нету, так как её ещё не с чего собирать (но, тем не менее, раст уже признали безопасным). А как мы все уже знаем - корпораты не будут проплачивать то, что не несёт для них двойных выгод (т.е скрытых и не яаных выгод на ряду с явными и очевидными). Да и заголовок новости манипулятивный: заголовок о "средствах безопасной работы с памятью", а содержание о профинансированной инициативе по созданию альтернатив на расте.
Спрашивается, какого хера вы тогда пропихиваете свои говноязыки в мейнстрим. Пишите браузер на go и dart
Скорпион не может не жалить. Вот и пропихивают.
https://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog
Так это языки для инди-разработки. Фронтендик, бекендик, мобилки. Что-либо серьёзное/фундаментальное писать на них было бы странным.
Нет, т.к. кода под UI в разы больше. Это как банковское ПО - 3 формочки и кода на 10005000 файлов с 100500 тысячами строк.
Та фуксйа которая в да-но-пока-нет'е вот уже 5 лет?
Тут пасутся РустоФобы. или Русто-скептики. Потому и приписали теперь "что при должном использовании". Для русто-скептиков.
Ну таки да. Скептики. Не без оснований скептики, ибо все самое вкусное все равно так или иначе обернуто в unsafe-блоки, делая все их защиты памяти точно такой же фикцией, как и кучку других красивых баззвордов. Хе.Помню раньше был анекдот:
"Сидят ОС и браузеры в кружке, и тут ОС и говорит: "А кто будет жрать больше всего памяти, тому дам по наглой рыжей морде" ".Вот мне просто интересно сейчас: блинк, крупный движок, нарабатывающийся годами. Функций - тьма, методов работы с огромной кучей контента, разметок и бинарных объектов тоже. Много низкоуровневых оптимизаций в адресной арифметике экономящих тысячи тактов, много внутренних оперативных кэшей объектов, позволяющих сэкономить одним метким указателем гигабайты памяти и секунды процессорного времени, вместо долгой и прожорливой прогрузке.
Вопрос простой: во сколько порядков возрастет потреблением его ядром ресурсов (памяти и проца), если их переделать на "безопасном" языке, фактически умножив оптимизации на ноль? Нет, я не говорю про хеллуворлды, графические улучшайзеры утилиты ping и прослойки легких виртуалок. Я говорю про очень сложное ядро браузера, в котором только полноценная ОС еще пока не самозародилась (и в этом я не уверен).
> Ну таки да. Скептики. Не без оснований скептики, ибо все самое вкусное
> все равно так или иначе обернуто в unsafe-блоки, делая все их
> защиты памяти точно такой же фикцией, как и кучку других красивых баззвордов. Хе.
> бернуто в unsafe-блоки, делая все их защиты памяти точно такой же фикцией,Дальше, в принципе, можно не читать. Отличный детектор умников, решивших набросить. И просто "опеннетных Ыкспертов". Хе.
> Много низкоуровневых оптимизаций в адресной арифметике экономящих тысячи
> тактов, много внутренних оперативных кэшей объектов, позволяющих сэкономить одним меткимНу да, для питонистов это все "магия" ... поэтому опять 0 конкретики.
> Вопрос простой: во сколько порядков возрастет потреблением его ядром ресурсов (памяти и проца), если их переделать на "безопасном" языке, фактически умножив оптимизации на
Ответ простой - НЕ переписыайте на питон и НЕ пытайтесь делить всё на две категории: "магическая и божественная сишка/плюсы" и "все остальное - это питон или похожее".
> Нет, я не говорю про хеллуворлды
А можно поподробнее о том, насколько порядков возрасло потребление Лисы после внедрения хелловордлов "Quantum CSS" и "WebRender"?
> Не без оснований скептики...Поверь мне, _без_ оснований. Все твои основания показывают лишь то, что ты не понимаешь подхода C++ и rust от слова вообще. "Меткий указатель", блин. Ты пробовал в проекте размера blink порассуждать о "метком указателе", и проверить не приводит ли его использование в каком-нибудь специальном случае к double-free/use-after-free, к data-race или к нарушению реентерабельности? На проекте размера blink не удастся успешно рассуждать о таких вещах без поддержки со стороны утилит, выполняющих большую часть работы по построению этих рассуждений. И вот тут, внезапно, C++ программисты начинают банить использование raw-указателей в коде, требуя использовать shared_ptr или uniq_ptr, потому что иначе рассуждения этих тулзов не стоят выеденного яйца, а с этим баном тулзы даже не всегда и нужны, потому что часто можно своей головой дотумкать.
Rust лишь делает следующий напрашивающийся шаг, он присобачивает к типу лайфтаймы, доводит до ума move-семантику, чтобы она не выглядела бы костылём, и упрощает задачу контроля за тем, чтобы программисты не использовали бы raw-указатели без нужды.
> Вопрос простой: во сколько порядков возрастет потреблением его ядром ресурсов (памяти и проца), если их переделать на "безопасном" языке, фактически умножив оптимизации на ноль?
Чем больше информации у компилятора о коде, тем лучше он может оптимизировать. C в этом смысле совершенно кошмарный язык, потому что для качественной оптимизации требуется превращать язык в один сплошной UB. И даже несмотря на это, всё равно приходится в рантайме выполнять работу, которую вполне можно сделать в compile-time.
>сплошной UBUB - только в мозгу программиста (в том числе программиста который придумал ЯП).
> C в этом смысле совершенно кошмарный язык, потому что для качественной оптимизации
> требуется превращать язык в один сплошной UB.В стандарте таки есть некоторые дурацкости. Но вот это все же преувеличение. Да и у хипстеров подпертых жирнокорпами лекарства обычно получаются хуже болезни. Завязываться на репо которым M$ и прочие амазоны рулят - UB гораздо более высокого порядка.
> И даже несмотря на это, всё равно приходится в рантайме выполнять работу,
> которую вполне можно сделать в compile-time.А вот это, пардон муа, уже вообще совсем неправда. Если подружиться с оптимизатором и сделать ему удобно, gcc, особенно с LTO - делает удивительно крутой код. Так что даже и на голом ассемблере не факт что так же круто напишешь - он, видите ли, злобно реюзает вон ту константу загруженную в регистры пару кило назад, танцуя от нее везде. Сам на асме трекать usage в таком количестве человек таки задолбается.
И все это как таковое - ортогонально UB и прочему. Да, у раста есть некоторые здравые идеи, но ориентация на полупроприетарный llvm и захват централизованного управления пакетами узкой группой корпов может это быстро и жестко аннулировать. А какие-нибудь политически-корректные трансфемки однажды могут начать резко и больно строить девов, угрожая а то и выкидывая пакеты.
>> И даже несмотря на это, всё равно приходится в рантайме выполнять работу,
>> которую вполне можно сделать в compile-time.
> А вот это, пардон муа, уже вообще совсем неправда. Если подружиться с
> оптимизатором и сделать ему удобно, gcc, особенно с LTO - делает
> удивительно крутой код. Так что даже и на голом ассемблере не
> факт что так же круто напишешь - он, видите ли, злобно
> реюзает вон ту константу загруженную в регистры пару кило назад, танцуя
> от нее везде. Сам на асме трекать usage в таком количестве
> человек таки задолбается.Если ты говоришь, что C оптимизируется круче раста, то сравнивать надо не с человеком на ассемблере, а с rust'ом.
>Поверь мне, _без_ оснований. Все твои основания показывают лишь то, что ты не понимаешь подхода C++ и rust от слова вообще.О, подтянулся видный эксперт. Несколько дней назад ты уже продемонстрировал своё знание плюсов. Подозреваю что и С, и раст ты знаешь примерно так же. Типичный сетевой незнайка, пишущий длинные портянки по предмету которым не владеет. Тебе к сведению, осёл, сейчас идёт работа по внесению в компиляторы С++ -Wlifetime (в CPPX, в зачаточном виде - dangling refs & pointers, уже можно поробовать), который позволит отслеживать проблемные ситуации с памятью. Заметь в компиляторы, т.е без коверкания языка и переписывании предыдущего кода на новые стандарты, как и положено при развитии зрелого языка.
>>Поверь мне, _без_ оснований. Все твои основания показывают лишь то, что ты не понимаешь подхода C++ и rust от слова вообще.
> О, подтянулся видный эксперт. Несколько дней назад ты уже продемонстрировал своё знание
> плюсов.О, подтянулся C++-эксперт все аргументы которого сводятся к ad hominem, причём выстроенным целиком и полностью по методике "диагноз по юзерпику". Если тебе так нравится C++, ты б не позорил его хоть, ассоциируя в глазах читателя себя с ним. Бери пример с фрактала: тот не любит rust, и поэтому ассоциирует себя с растом, а не с тем, что ему нравится.
> Подозреваю что и С, и раст ты знаешь примерно так же.
Охлол. Прям не взгляд, а рентген. Раскусил меня на подлёте. Как тебе это удаётся?
> сейчас идёт работа по внесению в компиляторы С++ -Wlifetime
Да, именно об этом я и говорю: C++ идёт по тому же пути, что и rust. Чтобы понимать это, вовсе не обязательно быть экспертом в C++. Но я заверяю тебя, ему не удастся. Всё что он может -- не идти, а ковылять на костылях, подпирая C'шный синтаксис всё большим количеством этих костылей. У C++ шансов ноль на то, чтобы стать современным языком, потому как он вынужден выдерживать совместимость с уже написанным кодом. А если случится невозможное, и он забьёт на совместимость, то это будет уже не C++, а что-то другое.
не по юзерпику, а конкретно по твоему нику. ты от него достаточно наплясал, чтобы делать выводы. и продолжаешь плясать без устали.
> не по юзерпику, а конкретно по твоему нику. ты от него достаточно
> наплясал, чтобы делать выводы. и продолжаешь плясать без устали.Ещё один взгляд-рентген. Есть какая-то специальная ферма по разведению таких как вы?
а ты — как и любой дурак — уверен, что твоей глупости совсем-совсем не видно? нуок, чо.
> а ты — как и любой дурак — уверен, что твоей глупости
> совсем-совсем не видно?Да, естественно. Но ещё больше я уверен, что твоей глупости не видно. Ты всегда таким умным выглядишь, знающим, понимающим всё на свете. Я даже боюсь с тобой разговаривать.
ты как-нибудь найди того, кто тебе наврал, что ты разговариваешь, и укоризненно посмотри ему в глаза.
> ты как-нибудь найди того, кто тебе наврал, что ты разговариваешь, и укоризненно
> посмотри ему в глаза.Я не разговариваю, я же сказал: я боюсь с тобой разговаривать. Что-то я начал сомневаться в том, что ты всё понимаешь: чёрным по-русски написано, а ты понять не можешь.
да, я и забыл, что намёки чуть тоньше полена до тебя не доходят в принципе.
> да, я и забыл, что намёки чуть тоньше полена до тебя не
> доходят в принципе.Лол. Да. Мне всегда нравится, когда люди из-за несработавшего намёка сваливаются в фоллбек режим, и начинают доносить информацию другим путём, пристёгивая поленья. Выглядит так же идиотски, как попытки объяснить не зашедшую шутку.
спасибо, я и не сомневался, что тебе часто шутки объясняют.
> спасибо, я и не сомневался, что тебе часто шутки объясняют.Тебе тоже спасибо, мне давно никто так упорно не пытался ничего объяснить.
> Не без оснований скептики, ибо все самое вкусное все равно так или иначе обернуто в unsafe-блоки, делая все их защиты памяти точно такой же фикциейНа сколько я понимаю, обычная программа просто завалится, как это сейчас и происходит, а написанная на расте при выполнении unsafe-блока, пытающегося завалить прогу, просто выдаст "ну... эта часть кода упала (функцЭя не работает)", но сама не упадёт, и ты сможешь пользоваться другими, работающими, её функциями. Или нет?
бобёр, выдыхай, лопнешь!
> обернуто в unsafe-блоки, делая все их защиты памяти точно такой же фикциейТо есть Вы даже не разобравшись в конструкции делаете выводы по её названию?
Тут кто-то обвинял всех в ванговании по никнейму. Кто же это был? Ах, да, это же Вы.Двойные стандарты не жмут?
Для конструктивной критики попробуйте хотя бы официальную документацию почитать. А то пока это выглядит, будто Вы школу окончить толком не смогли - Ваши аргументы такие, ничего личного.
> вы все врети, а ещё вы нидаучившейся лицемедр! Я, дочь директора раст файндейшн, поверьте мне, у нас не все так однозначно!Читал. Более того, даже попробовал. Не только хеллуворлд и парс выхлопа сишной утилиты, а вполне активную работу с памятью.
Да, самое вкусное лежит именно в unsafe-области. Оптимизация? Ансейф и возвращение к плюсам. Даже оптимальный по времени и памяти связный список не сделать - нет, сделать можно и без ансейфа, но, мягко говоря, он далеко НЕ ОЧЕ.
Понимаю, что для многих хруст уже стал игоговой как в одноименной секте. Но вопросов в моем первопосте это не отнимает.
> Читал. Более того, даже попробовал. Не только хеллуворлд и парс выхлопа сишной утилиты, а вполне активную работу с памятью.Ссылочку, пожалуйста, на репозиторий, а то я ведь тоже на C++ писал, так там строки через *** работают, темплейты как yourmum и работа с памятью - сплошной бойлерплейт. Это не говоря о базовой работе с вводом/выводом.
> Ссылочку, пожалуйста, на репозиторий, а то я ведь тоже на C++ писал,На какой именно? На домашний локальный гитиа? На локальный инстанс гитлаба на подкроватном сервере? На рабочий, во внутренней сети моей конторы?
На любой, где показано
> возвращение к плюсамМожно даже не свой, раз знакомство не шапочное. А то дерейл, приписываемый тобой растофанам как-то снова тобой же и употребим. Ещё один двойной стандарт, здрасьте.
А то что-то я не могу сопоставить тучу минусов плюсов с 5 (пятью, Карл!) случаями необходимости unsafe, среди которых как рах доступ к небезопасному коду на других языках. То есть на деле есть 4 оправданных случая использования unsafe - они лежат в только системном программировании, чем Rust не ограничивается.
А РастоФаны совсем не пасутся?
if (ptr == nullptr)
return FAIL;ZeroMemory(newmem, sz);
if (i >= sz)
return FAIL;но ради этого, конечно, нужны спецсредства, особенно денежные. *facepalm*
продолжай в том же духе! когда кол-во строк кода перевалит за 100К - приходи снова)
> приходи сноваИ переделай multi-thread и event-driven :)
А в чем, собственно, проблема? У сишников это с лохматых времен было. Собссно interrupts в железе - event driven с незапамятных времен. В posix сделали сигналы, изображающие примерно такую абстракцию. Но хипстеры их в массе своей не осилили.Т.е. примерно полвека спустя до хайпоты и нубов наконец стало доходить что так можно было? Ну вы просто охренеть авангард технической мысли, чуваки :)
> А в чем, собственно, проблема?Всего лишь в том, что в проекте уже около 100kloc ты залюбишься глазами и головой (в стиле, описанным InuYasha) отлаживать где тут кто и что выделил/занулил/освободил и не обгадит-ли это всё внезапно какой-нибудь левый поток. Проекты уровня Chromuim - миллионы строк кода -> нужны автоматические анализаторы кода, т.к. люди не вывозят (даже с "умными-гениальными" указателями С++ и всеми RAII).
Rust предоставляет анализ и попытки недопущения возможностей обгадиться с памятью уже в compile-time с минимально возможными затратами. Возможно не идеальные, но других-то всё равно нет (серьёзных). Следовательно, можно попробовать использовать его. О чём и весь спич гугла.
Честно говоря, я не задолбался. Так же как и не задалбываюсь писать "-тся" и "-ться" как надо. Это просто взято на заметку и уже вошло в привычку. А когда я вижу, например
void ShowReport(char *szData, uint nitems)
{
for (...) printf(szData[i]);
}
то сразу тянутся руки добавить if (szData == nullptre || nItems == 0) return; в начало. Просто в каждой функции обязательно должна быть проверка валидности параметров. Просто представляйте что пишете API для неадекватов. )
> то сразу тянутся руки добавить if (szData == nullptre || nItems == 0) return;Руки-то тянуться хорошо и правильно. Но приходит какой-нибудь олень в соседнем модуле и потоке и естественно косячит с разыменованием указателя (lock забудет\за буфер выйдет\переполнение типа устроит с каким-нибудь левым кастингом\и прочая золотая классика) и хорошая и совершенно правильная проверка в общем-то не спасла, потому что szData[i] - мусор при абсолютно валидных входных данных.
> if (ptr == nullptr)
> return FAIL;
> ZeroMemory(newmem, sz);
> if (i >= sz)
> return FAIL;
> но ради этого, конечно, нужны спецсредства, особенно денежные. *facepalm*Так главный прикол - перевод таких проверок в компайл-тайм.
Компиляторостроение и теория типов не стяли на месте со времен изобретения сишки, так что хотя бы раз в 30 лет вылезайте из криокамеры.
>Так главный прикол - перевод таких проверок в компайл-тайм.может все таки прийти к "нормальной" изоляции памяти?
как в компайл-тайме проверить границы массива, который ты откуда-то считываешь в рантайме? Правильно, никак, и никакой раст тут тебе не поможет.
> как в компайл-тайме проверить границы массива, который ты откуда-то считываешь в рантайме?Зависимые/ограниченные типы, оставляющие _максимум_ 1 проверку при считывании юзверьдат (а не как сейчас принято - от 0 "там все норм" и до "во всех-всех-все 102 (из 103) местах, работающих с этими данными")?
Не, не слышали.
> Правильно, никак,Главное умный и уверенный вид, ога.
> и никакой раст тут тебе не поможет.И мантры не забывать про великую сишку, неосиляторов и хипстеров со смузихлебами! Мантры - анонимное всё!
ну, мантры про хрустик получше, конечно. стильные, модные. это же только хрустик умеет в вывод подтипов и интервальный анализ, а другие компиляторы все такие дураки.
> ну, мантры про хрустик получше, конечно. стильные, модные. это же только хрустикНу, вам с анонимом лучше знать, раз так упорно его пытаетесь приплести везде где можно (ни я, ни ветко-стартер в #13, ни llolik ни разу не упоминали ни "руст", ни "хруст").
> умеет в вывод подтипов и интервальный анализ, а другие компиляторы все такие дураки.
Главное, вовремя свинтить с темы "как в компайл-тайме проверить", при этом скромно проигноровать предыдущее "Компиляторостроение и теория типов не стяли на месте" и опять бодро приплести "хруст" к обсуждению, да?
ты так неумело съезжаешь, что полный зад заноз наберёшь.
https://en.wikipedia.org/wiki/Iterator#Contrasting_with_inde...К слову в расте итераторы волшебны. Ты не можешь "отравить" коллекцию в процессе итерирования, и реализуется это на стадии компиляции.
Признаю что многие базовые алгоритмы без индексирования сделать затруднительно, и тогда лучше всего просто индексировать, пусть это и медленней на несколько тактов. А уже когда придет время оптимизации базового кода, можно и пару unsafe'ов под общим присмотром добавить.
Но чаще всего это уже сделано за вас гораздо лучше в стандартной библиотеке, и например
https://lib.rs/search?q=itertools
https://lib.rs/algorithms
Проблема в том что найти людей способных аккуратно и по спецификации писать код — очень сложно.
Если бы люди могли всё делать аккуратно - самолёты бы никогда не падали, а многочисленные проверки безопасности были бы не нужны. Но если можно пересесть с самолёта начала ХХ века на самолёт ХХI века - о чём тут думать?
Самолеты как правило падают так как их не списывают по неисправностям и старению а латают.И сабж тоже не понятен, а разве это не программер должен делать ? Или им плевать как работает лишь бы работало ?
Опять же - ну упадет что то там в изолированным непривилегированном контейнере и что ? Кибер новый заюзает ...
Боинг 737 MAX готов очень сильно поспорить с этим утверждением.Однако там проблема в том что алгоритм компьютера и пилот не понимают друг друга - пилот начинает бороться с медвежьими услугами компьютера, самолет в результате вытворяет черт знает что, контроль над ситуацией теряется, пилот не может переубедить машину, самолет живет своей жизнью. Конец немного предсказуем. Кстати, при этом вообще не важно на чем оно там унутрях было написано. Чисто логическая ошибка, где-то в основе дизайна алгоритма.
А так Arian 5 брякнулся несмотря на безопасную аду. Более того - она как раз своей безопаТностью настолько мешалась что это как раз и заоверрайдили. Еще скажите что хрустеры так делать не будут.
> а разве это не программер должен делать ?А если отключить все проверки при компиляции и сказать, что это программер должен делать?
Просто ещё несколько удобных проверок на этапе компиляции, исключающих множество неожиданных проблем в последствии.
Если упадёт unsafe, то опять же сразу знаем где проблема. И думаем: либо исправлять (если ещё разрабы остались, которые это поддерживали), либо переписать этот падучий блок уже на Rust'е.
Спецификации пишут люди
Вот если вы айтишники такие всегда из себя умные, почему бы не придумать безопасную память вместо всего этого бардака?
Чо-та не понял, минус - это роспись под собственной глупостью что-ли?
Это умышленно. Идея отдельных стеков для данных и адресов возврата очевидна. Но ради совместимости приходится держать "теневой стек" - копию только для адресов возврата, и всего-лишь сверять с настоящим стеком. Несёт оверхед. Однако уже во всех современных камнях Интела реализована аппаратная поддержка теневого стека.Убивает другое. После x86 было создано море архитектур. Однако все как один повторили ошибки интела. При всей очевидности. Я думаю, что им приказали.
Вряд-ли приказали. Просто очередное проявление интеллекта в худшей форме (не хотел писать слово глупость).
> Идея отдельных стеков для данных и адресов возврата очевидна. [...]
> После x86 было создано море архитектур. Однако все как один
> повторили ошибки интела.Почитайте уже хотя бы http://habr.com/ru/company/embox/blog/447704 про PS, PCS и US в e2k -- да разворачивайтесь с Запада и его "все как один" ошибок.
И да, снова добро пожаловать на опеннет, Вас не хватало. :)
Не факт что в этой костыльной реализации не найдут проблем в будущем.
Впрочем, может и не найдут. Как в Неуловимом Джо...
Уже придумали, годах в 60-х.
https://ru.m.wikipedia.org/wiki/%D0%93%D0...Архитектура была разработана Говардом Эйкеном в конце 1930-х годов
Ну пацаны, ну это все знают, чо уж совсем-то позориться. Как же передовые успехи айти? Вот в чем вопрос.
> Вот если вы айтишникичто ты тут делаешь?
https://en.wikipedia.org/wiki/Transactional_memoryПочему бы и да. Кое-где даже реализованно. В свежих ARM вроде где-то было. В расширениях RISC-V проскакивало. Мб ещё где-то.
>Google занялся...ищи альтернативы, где ещё не занялся.
Уже не знает чем занятся
>How is OpenSSF ensuring inclusive representation of the open source community?Вот оказывается главная цель, а не безопасность.
>>How is OpenSSF ensuring inclusive representation of the open source community?
> Вот оказывается главная цель, а не безопасность.безопасность стульев - тоже безопасность )
А что, "стулья" - из "этих"?
задорно то как получается..
так ненароком ещё и Линуса за-растируют - вот боли то у сичников будет.
Он им факов накидает.
Тебе-то какая разница, активный контрибьютор в ядро с выслугой в овер 9999 лет?
Можно покупать акции производителей памяти...
разве что магниторезистивной.
Кстати как прогресс в этом направлении? Все так же 2K в SOIC8 или есть более другие резултьтаты?
Как минимум FRAM вроде и полмега в таком корпусе бывает. Стоит, правда, как все хорошее, дороже EEPROM в том же корпусе и емкости...
> с безопасностью в ChromiumИ? Ну я думаю что тут не нужно каментов, но я отмечу ненужность каментов тут) И этот тоже ненужный)) Как и 99% прочих. Но уж какие новости - такие и каменты. Вот про Guix написали бы.
> "По данным Google 70% проблем с безопасностью в Chromium вызваны ошибками ..."... программистов Google.
свои-то кадры можно было заинструктировать, дать им инструменты для выявления ошибок и т.п. ?
ну так они же не дураки: они не собираются хром на хрустике переписывать. они хотят этот чемодан без ручки остальным навязать, и впиарить идею «надо всё переписать». кто согласится — мгновенно теряет лет пять и навсегда переходит в догоняющие. это называется «зачистка наиболее глупых конкурентов». (да, гугель тут как рупор, но не гугелем единым)
> они хотят этот чемодан без ручки остальным навязать, и впиарить идею
> «надо всё переписать». кто согласится — мгновенно теряет лет пять
> и навсегда переходит в догоняющиеокей. такая гипотеза как минимум имеет право на существование.
а какие есть аргументы против нее ?
я бы выдвинул такой: гугл уже нехило влошился в раст,
потерять эти инвестиции было бы нехорошо.
ой, когда гугель заботили потеряные инвестиции? у них там кладбище проектов как будто все четыре всадника апокалипсиса проскакали. а потом развернулись и снова проскакали. и ещё раз повторили для верности. а вот превентивно зачистить потенциальных конкурентов — это хороший проект с большим выходом на будущее.количество использующих хрустик — оно самому гугелю как-то до интересного места: за это же лицензионные отчисления не платят.
>свои-то кадры можно было заинструктировать, дать им инструменты для выявления ошибок и т.п. ?к сожалению, у нас нету столь высококвалифицированых икспердов, как анонимы опеннета, потому наши инженеры и допускают ошибки
да там с любыми экспертами большие проблемы. как там стадия — уже захватила мировое господство до трёх раз?
> Отправлено Директор Гугла, 19-Фев-21 11:55слыш, директор - верни мне почтовые ящики на gmail, которые ваш сумасшедший робот определил как якобы "взломанные" в 2010 году.
И мои! Просто потому что "мы не верим вам что вы - это вы, хоть вы и знаете пароль и волшебное слово".
Правильно написали, если на Rust писать без unsafe то сразу этот язык перестанет быть системным - т.е. жрать память, тормоза и т.д.
Зато безопасен, память будет утекать, но виноват в этом будет процессор
> без unsafe то сразу этот язык перестанет быть системным - т.е. жрать память, тормоза и т.д.То есть Вы прочитали одну статейку (кстати, какую?) или комментик и поверили?
Может лучше удосужиться почитать документацию тлт даже пописать код? Zero-allocation abstractions? Не, не слышали.
> Компания Google ... Исследование MicrosoftТак вроде это все их проприетарное ПО. За что СПО-то покритиковали?
> Google 70% проблем с безопасностью в Chromium вызваны
> ошибками при работе с памятьюНаши программисты не способны работать с памятью, поэтому нам нужен язык, который будет их бить по рукам.
Или колоть: Шпага, Рапира :)
Наши программисты - не сверхчеловеки, не делающие ошибок. Существующая инфраструктура предотвращения ошибок по факту неэффективна, поэтому ищем новые методы страховки.Поправил.
Гугл, а давайте вы хром будете переписывать на что хотите, а открытое ПО оставите в покое а?
мы высоко ценим мнение Анонимов Опеннета, потому немедленно прекращаем разработку открытого ПО по Вашему настоянию
Вот так бы и сразу, еще распечатай код хромого, скрути в трубочку и засунь себе в зад.
Как я понял, гугл собрался "сватать" Rust. А мелкомягкие это просекли и тоже собрались. Ну и кто кого обскачет?
> По данным Google 70% проблем с безопасностью в ChromiumНу и зачем нам данные по Chromium, позвольте?
А, ну-ну. Мозиллка уже погулялась по эти граблям, так что до сих пор бюджет штoпает.
я в упор не понимаю что мешает писать всю работу с памятью через std::auto_ptr ну или утащить в с++ реализацию раста для указателей. Иил что мешает гуглу пропихнуть в новый с стандарт безопасную память как отдельный тип. зачем все менять если проблема только с алокацией памяти.
Судя по предложению использования std::auto_ptr, который начали хоронить более 10 лет назад как одну из очень неудачных концепций, создающую большее число новых проблем, чем решающую, вы фундаментально не понимаете проблем, возникающих перед разработчиками. Увы, попробовать вникнуть в них проще, погрузившись самостоятельно в разработку, а я не тот, кто может прояснить данный вопросРазные способы управления памятью имеют разные преимущества и недостатки, нельзя взять и выбрать самый правильный. Пока ещё ни одного правильного не придумали. Так что Гугл не может пропихнуть новый идеальный стандарт, не придуманный ещё никем. Но может экспериментировать с чем-то, что претендует на приближение к этому идеалу — быть может, Rust и докажет, что его модель управления памятью такова, но пока ещё рано и никто об этом не пытается судить (за исключением экспертов_во_всём_вокруг)
И да, насколько мне известно (проверять я, конечно же не буду), в Chromium используется множество способов управления памятью — от сырых указателей до самописного сборщика мусора. Вот более развитые версии auto_ptr где-то по серидине между ними и стоят, они тоже используются. Возможно, определись разработчики с единственным способом управления памятью (и не важно, каким), им бы и стало проще взаимодействовать и вести разработку. Но мы этого точно не знаем
> я в упор не понимаю что мешает писать всю работу с памятью
> через std::auto_ptr ну или утащить в с++ реализацию раста для указателей.http://smallcultfollowing.com/babysteps/blog/2018/04/27/an-a.../ (это с объяснениями к разработке прототипа нового анализатора)
http://smallcultfollowing.com/babysteps/blog/2018/06/15/mir-.../ (это объяснения результата)Причем, эти "страдания" - с "ограничениями" ржавчины, изначально заточенной под эту семантику. А прикрутить такое же к плюсам, не сломав обратную совместимость ... если бы можно было реализовать, то оно наверное уже было бы реализованно.
нужен контроль, либу вы можете не использовать если голова на плечах есть, а если сборщик то он уже будет обязательным ) контроль программ, вот в чем причина )
пишу на D. спокойно использую ручное управление памятью где мне надо. есть у меня мнение, что тебе — как плохому танцору…
не туд отписал походу, не в тему с моим сообщением
Весь этот тред напоминает мне классическую работу на производстве, когда безопасность труда противоречит скорости и эффективности, и рабочий работает безопасно ровно до тех пор, пока на него смотрит безопасник, а дальше всё равно делает по-своему.
Ху из безопасник?
Гугель сам по себе одна большая неустранимая опасность.
:D
ну какже эти ит гиганты хотят нам впихнуть сборщик мусора в каждую программу. контроль всего и вся )
Хмм... То есть гугл предлагает открытое ПО переписать на раст, а свое закрытое оставляет на плюсах?