Компания Google перевела браузер Chrome на библиотеку Skrifa, написанную на языке Rust и предоставляющую возможности для обработки шрифтов в формате OpenType. Skrifa реализует подмножество возможностей шрифтового движка FreeType, необходимое для 2D-библиотеки Skia, применяемой в Chrome и Chromium. Для избавления библиотеки Skia от привязки к движку FreeType создан новый шрифтовой бэкенд, основанный на Skrifa...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62922
Скоро они узнают что кроме выхода за границы есть ещё много видов ошибок.
И будут радоваться тому, что не тратят время на высчитывания границ, а сосредоточиться на недопущении этих самых ошибок.
Например логических.
Я вот все читаю про битву Си и Rust.
Складывается впечатление что выход за пределы границ, не проблема языка, а прказатель уровня владения им. Не приведет ли rust к аналогии работы с калькулятором, что некоторые личности настолько активно его начинают использовать что теряют навык счета в уме.
> Складывается впечатление что выход за пределы границ,
> не проблема языка, а прказатель уровня владения им.Если бы так было то профи не допускали бы таких ошибок.
Но практика показыает обратное. Такие ошибки делают и в ядре, и в гугле, и даже диды из 90х делали (привет, xorg!) Сишке уже 40+ лет, а не портить память так и не научились.Возможно дело, что там нужен не уровня владения, а внимание.
Ведь правила очень просты - один раз память выделил, один раз очистил, за границы буфера не выходи. Даже первокурсники это знают.
А вот внимания для такого микроменеджмента на большом проекте уже недостаточно. Просто потому что человек существо крайне ограниченное.> теряют навык счета в уме.
Люди все время заменяли одни, уже ненужные навыки, на другие.
Так что проблема не такая большая
Загружаемые веб-шрифты - дыра в системе, недавние новости это подтвердили.
> Загружаемые веб-шрифты - дыра в системе, недавние новости это подтвердили.Так вот эту дыру и хотят закрыть.
Ну или хотя бы существенно минимизировать поверхность атаки.
Испольованием доп.компилятора? Смешно... От гугл? вовсе печально такое слышать.. очередное разочарование в человечестве.
> Испольованием доп.компилятора? Смешно...Использование недырявого языка.
> От гугл? вовсе печально такое слышать.. очередное разочарование в человечестве.
Тем не менее гугл заинтересован в недырявости своего браузера.
Иначе пользователи будут расстраивать и уйдут. А гугл перестанет получать бабаосики за рекламу и персональные данные. Потому что в хроме гуглу бекдоры не нужны - он и так все сливает кому нужно.
>> Тем не менее гугл заинтересован в недырявости своего браузера.Как жешь они раньше-то жили? И каким, интересно, образом он(браузер) смог набрать такую популярность, конечно дело было в безопастном компиляторе шрифтов, который собрались втыкать.
>>> Тем не менее гугл заинтересован в недырявости своего браузера.
> Как жешь они раньше-то жили?Плохо жили.
opennet.ru/opennews/art.shtml?num=59746
Критическая 0-day уязвимость в Chrome и libwebp, эксплуатируемая через изображения WebPВызвана переполнением буфера в обработчике формата изображений WebP. Уязвимость позволяет выполнить свой код при обработке специально оформленных WebP-изображений. ...
в сети выявлен рабочий эксплоит, который уже применяется злоумышленниками для совершения атак (0-day).> И каким, интересно, образом он(браузер) смог набрать такую популярность, конечно дело было в безопастном компиляторе шрифтов, который собрались втыкать.
Приходилось вкладывать деньги)
А теперь в качестве рекламы можно будет писать "написано с содержанием ЯП одобренным министерством обороны США".
Да, слегка приврали, но зато говорит о надежности!
В то, что пользователи (в более-менее заметном количестве) могли бы расстроиться и уйти из-за того, что браузер перестал нормально всю рекламу резать - я ещё могу представить.
В то, что они могли расстроиться и уйти из-за недырявости - маловероятно. Обычный пользователь вообще не заморачивается таким. Если в другой браузер внедрили какие-то хайповые штуки, а в Chrome нет - вот это более вероятный сценарий перехода :)Есть собственный опыт "с обычными пользователями" (ну, кроме работы эникеем): как-то я обнаружил, что у одной (актуальной на тот момент) модели роутеров обновление прошивки в последний раз выходило 11(!) месяцев назад (две или три версии выпустили сразу после выхода и на этом всё) и в отзывах на известной площадке написал об этом. Меня назвали параноиком, "покрутили у виска" и навтыкали "минусов". Вот это - типикал "обычный пользователь" :)
Чтобы её закрыть всё что надо так это выкинуть такую возможность.
>Если бы так было то профи не допускали бы таких ошибок.Откуда вы знаете какие ошибки делают профессиональные программисты на С? Исходный текст их программ никто не видит, потому что они коммерческие, а чаще всего и программ-то не видят, потому что они программируют встроенные системы.
>Такие ошибки делают и в ядре, и в гугле,
В ядро Linux профессионалы не пишут. Поделки Гугля - это вообще больше из области маркетинга чем из области программирования. Кстати, вы знаете что Гугль - это не компьютерная компания?
>даже диды из 90х делали (привет, xorg!)
Xorg появился в 2006-м, когда уже был расцвет Python, Javascript, PHP.
>ишке уже 40+ лет, а не портить память так и не научились.
Язык не виноват если его пользователь (язык не позволяет назвать их программистами) не знает как правильно программировать на нём.
>Просто потому что человек существо крайне ограниченное.
просто сейчас расцвет капитализма, а при нём качество - не является ценностью. Ценностью является скорость разработки и прибыль.
> Откуда вы знаете какие ошибки делают профессиональные программисты на С? Исходный текст
> их программ никто не видит, потому что они коммерческиеЭ... А Юникс?
Именно ради него СИшка была создана.> Xorg появился в 2006-м, когда уже был расцвет Python, Javascript, PHP.
Ага, прям из воздуха и появился.
ХОрг это форк X11 R7.0
Как думаешь что значат эти циферки? Так что это X11 появился в далеком 1987 году.
А Х1, как можешь догадаться - еще раньше ;)> Язык не виноват если его пользователь (язык не позволяет назвать их программистами) не знает как правильно программировать на нём.
Ага, как оголенные провода торчащие из розетки - тоже не виноваты.
Или станок с открытыми шестернями.
Просто инструмент бывает хороший-качественный, а бывает кривым-косым.> просто сейчас расцвет капитализма, а при нём качество - не является ценностью.
Хахаха, сколько тебе лет, юноша?
Не доводилось ли тебе лицезреть результаты коммунистической промышленности СССР?
А ведь возможно своим появлением ты обязан "качеству" резинового изделия №2.> Ценностью является скорость разработки и прибыль.
Ага.
Альтернатива - долго, овняно и надо в очереди отстоять.
> В ядро Linux профессионалы не пишут.Все так. Профессионалы пишут сугубо в опеннетные комментарии.
>Откуда вы знаете какие ошибки делают профессиональные программисты на С?Компании сами о них докладывают через неделю программу CVE. Заходите на сайт и смотрите и статистику и отдельные случаи.
в гугле не работают "индусы", которые написав три строчки на pip. и nodejs, но при этом знают 33 способа сортировки пузырями, что достаточно для гугла
> Я вот все читаю про битву Си и Rust.Думаю битва еще не особо началась)
> Складывается впечатление что выход за пределы границ, не проблема языка, а прказатель уровня владения им.
О, я люблю слушать сказки и котоламповые истории!
Я надеюсь, что ты расскажешь мне красивую сказку про Настоящих СИшников™, которые таких глупых ошибок не делают.
А вот "Ненастоящие ш̶о̶т̶л̶а̶н̶д̶ц̶ы̶ СИшники" постоянно бокопорят и портят память.А я взамен, приведу пример Теодора "вы не заставите меня выучить раст" Тцо.
Он probably the first Linux Kernel developer in North America, развиватель файловых систем и писатель на СИ десятки лет и в ядро с 91 года, и т.д и т.п.Так вот, процитирую анона из другой темы[1] :
CVE-2022-1184 - ваще шикарная.
А теперь микрофон и все лавры передаются ox55ff с лора
"в 2013 году он закоммитил вот такую портянку github.com/torvalds/linux/commit/dc6982ff4db1f47da73b1967ef5302d6721e5b95Через 9 лет (2022 год) тысячи глаз наконец-то рассмотрели там уязвимость CVE-2022-1184.
Которую смогли исправить только со второй попытки:
первая github.com/torvalds/linux/commit/65f8ea4cd57dbd46ea13b41dc8bac03176b04233
вторая github.com/torvalds/linux/commit/61a1d87a324ad5e3ed27c6699dfc93218fcf3201ext4: check if directory block is within i_size
Бгг. Видимо Теодорчик решил, что в его коде всё within, ведь "индекс проверять надо если программист решил что тут есть шанс того, что он окажется некорректным", а оказалось, что не within. Это какое-то шанс-ориентированное программирование. Сишник к успеху шёл, не получилось, не фартануло.
> Не приведет ли rust к аналогии работы с калькулятором, что некоторые личности настолько активно его начинают использовать что теряют навык счета в уме.
Я не умею настраивать карбюратор, хотя мой отец умеет.
Я не умеею сажать пшеницу и косить траву ручной косой, как мой дед.
Моя дочка не умеет плести лапти как ее бабушка, и не знает что такое "доска для стирки" (и я искренне надеюсь, что у меня получится сделать так, что узнает только по картинками из википедии).
Разве не в этом заключается прогресс?А по поводу счета в уме - у моих соседей ребенок отлично считает в уме сколько тот или иной покемон наносит урона. Просто потому что ему это интересно.
-----------------------------
[1] opennet.ru/openforum/vsluhforumID3/136231.html#130
>А я взамен, приведу пример Теодора "вы не заставите меня выучить раст" Тцо.Зачем ты привел позор растовиков?
Взялись делать систему интеграции в ядро и не смогли сделать автоматические биндинги.
Стали требовать поддерживать биндинги от ВСЕХ разработчиков и получили по рогам. Так как это требование перекладывает их работу на других людей.
Выкинуть, правда, совсем раст не получилось. Но попытка обернулась тем, что Линус подтвердил: пишите не оглядываясь на обертки rust, разок-другой можем задержать интеграцию написанного из-за неготовности rust-оберток, а если будут постоянно опаздывать - дропнем не поддерживаемое.
> и получили по рогам.Получили по рогам как раз сишники.
Мейнтенера DMA натыкали в ссаные тряпки и объяснили что нужно знать свое место и не пытаться контролировать как и кто использует его код.
Снежинка такого не пережила и выпилилась из мейнтейнеров. Плак-плак))Остальным же Торвальдс доходчиво объяснил, что оно или учат раст и принимают участие в обсуждениях, или не учат и закрывают варешку.
Получилось вполне неплохо.А дроп неподдерживаемого кода из-за неготовности или отсутствие мейнтейна - так это и сишку касается. Я конечно подозреваю, что диды-копротивляторы будут стараться максимально подоcpaтьгде только могут, но и это переживем.
Хорошая аналогия кстати, чтобы грамотно в C памятью управлять - это примерно как вы будете 10-значные числа на бумажке перемножать. А в соседний отдел завезли калькуляторы. А вам - пачку рекомендаций, как на бумажке правильно числа записывать, чтоб не ошибиться.
Через 10 лет отдел с калькуляторами деградирует до саморазрушения. А те, что на бумажках - продолжат неспеша выполнять любые задачи.
> Через 10 лет отдел с калькуляторами деградирует до саморазрушения.Смелое предположение, пруфов, я так понимаю, предоставлено не будет?
> А те, что на бумажках - продолжат неспеша выполнять любые задачи.
Лет за 10-20, а там уже и пенсия.
А надо было посчитать за неделю.
Какие тебе пруфы? С какой стати? Сам ищи, пруфы на общеизветные факты...Люди даже в уме числа всегда в истории считали,
до появления калькуляторов...На - можешь начать хоть с этого пруфа: антагоист бывший бухгалтер у Ильфа и Петрова, но понятно он был не единственный такой в мире.
/мимопроходил
> Люди даже в уме числа всегда в истории считали, до появления калькуляторов...Что за бред? Ты про абаки, догарифмические линийки и прочие устройства не слышал?
И они еще говорят о деградации...
Про верёвку с 12-ю узлами, для построения прямого угла, наверняка не слышал. Зато верует, что масоны с рептилоидами заставляют идти в магазин за новым железом.
> Какие тебе пруфы? С какой стати? Сам ищи, пруфы на общеизветные факты...Хм, ты решил использовать гамбит "пруфов нет - кукарекай про ʼобщеизвестные фактыʼ"?
> Люди даже в уме числа всегда в истории считали, до появления калькуляторов...
Свежо предание, но сдается мне что ты брешешь)
Абак появился тысячелетия назад.
Я уже молчу про методики счета на пальцах.
Да-да, ждём примера успешных успехов бухотделов, ручками записывающих результаты абакинга в три книги и апокалиптических картин массового увольнения разучившихся пользователей 1с и экселя в связи с полным развалом доверенного фронта работ...
> Да-да, ждём примера успешных успехов бухотделов, ручками записывающих результаты абакинга
> в три книги и апокалиптических картин массового увольнения разучившихся пользователей
> 1с и экселя в связи с полным развалом доверенного фронта работ...Пример одного ВУЗа: СССР 80е - на каждом курсе на факультете по 3-4 группы по 30 человек, на ВУЗ бухгалтерия 3 сотрудника, без компьютеров, все успевают, без ошибок. Современность - 1-2 группы по 10-20 человек, бухгалтерия 15 сотрудников + кучи компьютеров, серверов, админов - нихрена не успевают, все с ошибками, под бухгалтерией очереди. Постоянные попытки сбросить работу на посторонних - "вы сделайте, посчитайте, заполните, принесите - мы проверим и подпишем".
>> Да-да, ждём примера успешных успехов бухотделов, ручками записывающих результаты абакинга
>> в три книги и апокалиптических картин массового увольнения разучившихся пользователей
>> 1с и экселя в связи с полным развалом доверенного фронта работ...
> Пример одного ВУЗа:Не-не-не, мне не нужен "пример одного вуза" (и сравнение бухучета в СССР с РФ тоже не) - мне нужен пример успешного успеха с заменой 15 человек с коипьютерами на 3х с бумажками.
> Смелое предположение, пруфов, я так понимаю, предоставлено не будет?Возьми свой "калькулятор", посчитай на нем количество значимых научных открытий и изобретений за определенные десятилетия/столетия, проведи корреляцию с количеством и производительностью этих "калькуляторов". Определи тренд. Не плачь.
Не на бумажке, а в уме чтобы, первоначально речь зашла. И люди-счётчики показывают феноминальные результаты. Проверяющие даже не успевают на калькуляторе набрать, а те уже ответ выдвли. И не только перемножать, но корни извлекать.
При подготовке космонавтов подобному обучают. Может, и не с 10-значными числами, конечно.
Вот именно, не 10-значные. Пока все работают строго по утверждённым схемам, входят так где вход и выходят там где выход - всё работает прекрасно. Как только находится один идиот, который влезает в окно - ну вот понадобилось ему для "оптимизации" скопировать куда-то указатель - всё рассыпается как карточный домик. Проблема программистов в том, что в целом они необучаемы. Ну вот невозможно приучить людей хранить данные о кодировке, когда у них есть стандартная библиотека, которая просто копирует строки. И проблема с кодировками "решилась" только когда всех добровольно-принудительно загнали на одну, весёлую и с эмоджи. Так же и тут.
> Ну вот невозможно приучить людей хранить данные о кодировкеИ как все работало? Или не работало. Знаю тех кто и сейчас использует локаль KOI8-R.
Тут говорят, что тотально приведёт. Потому, как скоро кодить будет AI.
да когда ж эта гадина будет наконец-то за меня кодить?!Пока больше похоже что она научится за меня врать почему проект не сделан вовремя. Ну, в принципе, приемлемо...
Rust далеко не единственный язык с безопасной работой с памятью. Можно поглядеть что за ошибки и сколько их в других языках. Ну например есть PHP....
Вы, видать, ничего сложнее функции fib() не писали. У среднего разработчика 10 мегабайт исходного кода в голове не умещаются. Просто поработайте над серьёзным проектом на Сях, а потом на Расте, сразу увидите разницу в скорости разработки и качестве кода. ;)
Средний разработчик в России, усилиями активистов СПО, умещает в голове любое количество кода.Ему достаточно помнить git clone && make install, и полный цикл разработки готов.
АН: Политика ALT состояла все эти годы в том, чтобы построить п͟о͟л͟н͟ы͟й͟ ц͟и͟к͟л͟ р͟а͟з͟р͟а͟б͟о͟т͟к͟и, независимый, а это очень длительный процесс, причем нельзя сказать, что мы с самого начала ставили перед собой такую цель.
>Ему достаточно помнить git clone && make install, и полный цикл разработки готов.Ну ещё свои копюрайты вбить.
А этот позор фамилии уверен, что сборка чужого кода это и есть полный цикл разработки? 😂
Не думаю, что он человек глупый. Подозреваю, дурачит сознательно и достаточно успешно, учитывая количество верующих в профанацию.Интервью известное, кстати. Удивлён, что "Сообщество" такое схавало - в то время понимающих было наверняка побольше. Это я пропустил его, поскольку в то время был в другой ОС.
Alt успешно приплетен. При чем тут Alt, как связан альт с разработкой на Си, откуда информация о том, что умеет средний разработчик в России - осталось загадкой.
Что не ясно в словах "п͟о͟л͟н͟ы͟й͟ ц͟и͟к͟л͟ р͟а͟з͟р͟а͟б͟о͟т͟к͟и, независимый"? Alt ничем подобным не занимается, вопреки заявленной "политике все эти годы".
Нет никакой битвы.
Растоманы пытаются свести все аргументы на безопасно, тогда года С разрабы говорят что у раст нет стабильного API, ABI, да что там... Синтаксис меняют каждый раз когда кто-то один из разрабов проснется в плохом настроение... Ну и культура, большинство сторонников раста это вайберы предыдущего поколения, они полагаются на компиляторы и сторонние пакеты которые тянут из публичной мусора
> некоторые личности настолько активно его начинают использовать что теряют навык счета в умеПочему это вообще является проблемой? Калькулятор всегда под рукой. Тоже самое с картами и навигаторами. Умение использовать компас или астролябию это безусловно круто. Но не для повседневного использования.
> Складывается впечатление что выход за пределы границ, не проблема языка, а прказатель уровня владения им
Для людей совершенно нормально и естественно ошибаться. Одно дело, если ты не используешь калькулятор при подсчёте своих покупок. Другое дело, при подсчёте какой-то сложной штуки вроде авиалайнера. Цена ошибки слишком высока, чтоб полагаться на человеческий фактор.
Я лично очень плохо считаю в уме. Как, я уверен, и подавляющее большинство людей в мире сегодня. И, как подавляющее большинство людей в мире, я не вижу в этом никакой проблемы.Самое забавное, что ты, скорее всего, считаешь не чуть не лучше меня. А может и хуже.
Сравни 1% уязвимостей из-за логических ошибок и 70% из-за кривой работы с памятью. Остальные 29% разные SQL injection, Command Injection, Path Traversal, XSS, Missing Authentication, Type Confusion, которые в данном случае неприменимы или слишком тривиальны для уровня Google.
Сравни денежные потери от выхода за границы буфера в 0 долларов. И потери от логических ошибок в 100 миллиардов долларов.
Откуда цифры?
От кэмэла, вестимо.
> Откуда цифры?Аноним просто ткнул пальчем в небо (или в какую-то другую сущность) и выдал результат.
И да, пруфов не будет, мы анонимы друг друга не обманываем (с).Heartbleed - buffer over-read уязвимость которая повлияла на кучу сайтов. К счастью жила всего 3 года.
Импакт оценили в $500 лямов.
Недавно новости были про перечисление случайным людям около миллиарда, вместо 20 долларов.И говорилось, что такое происходит постоянно. Большие суммы отслеживают и возвращают.
А вот малые.... И это крупнейшие банки США.
Причем тут работа с памятью? Это явно логическая ошибка.
А может и переполнение.
В возрасте 15 лет Билл Гейтс получил от администрации школы, где он учился, задание написать программу для распределения учеников по классам. Гейтс не только выполнил задачу, но и извлёк некоторую выгоду для себя: программа сформировала ему такое расписание, что в его классах было непропорционально большое число интересных девушек.(цитату взял откуда попало, но он сам про это пишет в своей книге)
Так про это и речь, что именно логические ошибки приводят к огромным потерям.И сильно желательно обставить все логические действия так что бы никакой мусор не мешал понимать логику работы.
Цифры он взял из летнего "отказа Windows", когда в драйвере CrowdStrike разыменовывали нулевой указатель. По обыкновению малость приврал.
https://ru.wikipedia.org/wiki/Heartbleed
Ошибке три тысячи миллионов лет, а ты все носишься с ней и пытаешься что-то сам себе доказать?
> Ошибке три тысячи миллионов лет, а ты все носишься с ней и
> пытаешься что-то сам себе доказать?Мне не нужно ничего себе доказывать) Я могу позволить себе использовать те технологии, которые мне нравятся.
Это был контраргумент к тезису, что ошибки доступа к памяти ничего не стоят. Это не первая и не последняя подобная ошибка, но наверное, самая известная.
Выход за границы — это самое тривиальное, что может быть. Раст предотвращает очень многие потенциальные ошибки связанные с доступом к памяти, в весьма неочевидных ситуациях. А ещё, решает проблемы с гонками данных, в многопоточных приложениях, что принципиально улучшает сон и аппетит. У меня складывается впечатление, как будто «адепты старой школы» сами вообще никогда не писали на Си или плюсах реальных проектов.
> У меня складывается впечатление, как будто «адепты старой школы» сами вообще никогда не писали на Си или плюсах реальных проектов.Опеннетные "ярые одепты си" - в основном проекты вида laba1.c, laba2.c ... labaX.c и было это давно. И чем давнее, тем яростнее и беспощаднее "одепт".
Эдакая "любовь на расстоянии", потому что любить сишку именно как ЯП - ну вот абсолютно не за что.Тут как в том анекдоте "Дед, при Сталине жилось лучше? Конечно лучше, внучек! Почему, деда? Потому что при Сталине у меня - стоял!"
> У меня складывается впечатление, как будто «адепты старой школы» сами вообще никогда не писали на Си или плюсах реальных проектов.Ты и правда считаешь что, всё EXE проектов в мире - на Rust/Java/Pyhon/C#/.../BrainFuck ? Что куришь?...
>> У меня складывается впечатление, как будто «адепты старой школы» сами вообще никогда не писали на Си или плюсах реальных проектов.
> Ты и правда считаешь что, всё EXE проектов в мире - на
> Rust/Java/Pyhon/C#/.../BrainFuck ? Что куришь?...Наверное, под EXE, вы имеете ввиду исполняемые файлы. Не понимаю: зачем вы вообще рассуждаете в подобных категориях. Ошибки в библиотеках (вы их , как я могу догадаться, называете ДэЭльЭльками) не менее опасны (я бы сказал, что куда более опасны). Хочу также обратить внимание, что в мире достаточно много различных платформ, и не везде библиотеки и исполняемые файлы называют также как в ОС Виндоуз, которую, как я могу судить, вы имеете удовольствие использовать.
Но если не откланяться от темы дискуссии, Rust конкурирует в основном с Си и «Плюсами». Ввиду своего опыта, я готов сравнивать только C++ и Rust. И несмотря на некоторые слабые стороны в плане обобщённого программирования, писать сложный асинхронный код на Rust гораздо приятнее чем на «плюсах».
В Паскале нет выхода за границы массива. Вообще нет. И всегда так было. Это приводит к аварийному завершению программы. Тем более в Ада.
Как это нет
Вот проверил только что в fpc
> program project1;
> var
> a: array[0..2] of integer;
> i: integer;
> begin
> for i := 0 to 2 do
> a[i] := 1;
> for i := 0 to 5 do
> Write(a[i], ' ');
> end.выдает: 1 1 1 0 4 0
> В Паскале нет выхода за границы массива. Вообще нет. И всегда так
> было. Это приводит к аварийному завершению программы. Тем более в Ада.Наверное в силу каких-то объективных причин, вы упускаете из виду, что проблемы доступа к памяти не ограничеваются лишь выходом за границу массива. К сожалению, всё гораздо сложнее, чем просто не напутать с интеграцией по циклу.
Ещё, вы хотите не просто аварийного завершения, в случае ошибки, но также обнаружить как можно больше проблем на этапе компиляции.
> Скоро они узнают что кроме выхода за границы есть ещё много видов ошибок.Что же не позволяет тебе дочитать новость до конца? Тебе же в дополнение перечислили еще пучок (и заметь, именно они, вместе с выходом за границы, дают львиную часть именно критических ошибок высокой опасности):
"Например, использование Rust, позволило бы избежать ранее выявлявшихся в коде FreeType проблем, связанных с обращением к освобождённым областям памяти, выходом за границу буфера, доступом к массивам без проверки индексов, целочисленными переполнениями, некорректным использованием необнулённых областей памяти и ошибками приведения типов."
Опережая следующую твою сентенцию - и нет, это не полный и исчерпывающий список, от чего еще мог бы защитить раст в отличие от сишки.
Жду возвращения к bitmap-шрифтам
О, наконец-то.
Теперь крикуны "в хроме нет раста" получили неоспоримый пруф))ps жду нытья "на моем rhel6 не хватает пакетов"
ps2 и потока нытья от гентушников "как же это все пересобирать"
Ты рад что всем стало плохо?
> Ты рад что всем стало плохо?Почему всем?
Гентушники и некролюбы - это девиация даже среди линуксойдного меньшинства.
Всем остальным наоброт станет лучше.
>Ты рад что всем стало плохо?
>Почему всем?Потому что в инфраструктуру добавили два вендерлока: сам rust и эта skrifa. С одной стороны какая разница, если хром это один большой вендерлок? С другой не все так просто, сейчас этот движок как раковая опухоль начнет поражать всю экосистему Линукс.
>Всем остальным наоброт станет лучше.
[sarcasm]Ага, лично я просто прыгаю от счастья осознавая это.[/sarcasm]
> экосистему Линукс…которой не существует.
>Потому что в инфраструктуру добавили два вендерлока: сам rust и эта skrifa.Про xorg вы благополучно забыли
Так это же его хлеб. Ему за это платят.
Ну почему сразу всем. Отвыкай говорить за всех. Мне вот стало хорошо. От того, что потенциальных дыреней стало (и станет) меньше.
emerge www-client/google-chrome затащит бинарный пакет.
> emerge www-client/google-chrome затащит бинарный пакет.Перефразирую старый комикс про Неми:
"- А как называется гентушник, который тащит бинарные пакеты?
-- Предатель!"У них же компиляние ради компиляния.
Это не самый странный фетиш, но даже среди линуксоидных меньшинств они довольно маргинальные.
теоретик [рука\лицо]
Ну и как ты скомпилируешь программу без исходного кода? Хромиум в счёт не берём, там синхронизацию отключили
А ты этих "них" видел-то хоть раз, Андерсен ты наш? )
В каждой второй новости на opennet'е, ага.
Если вдруг захотелось собрать систему из исходников, это не значит, что нужно собирать абсолютно всё. Держишь хромы и расты во флатпаке и в ус не дуешь. Ещё и права доступа можно обрезать прямо в кдешном system settings.
Здесь компиляем, здесь не компиляем. Здесь рыбу заворачивали.
> "в хроме нет раста"Так его там реально нет. Есть только бинарники собранные из исходников Rust :-D
Ждём серверов с водяным охлаждением. Можно будет горячую воду в контур отопления дачи пустить, по аналогии с этим https://habr.com/ru/articles/874044/ вместо электрокотла. Сразу два зайца убили: и емержит, и отапливает.
Можно готовить Иишенку, на процессоре.
Safety
Unsafe code is forbidden by a #![forbid(unsafe_code)] attribute in the root of the library.
github.com/googlefonts/fontations/tree/main/skrifa#safetyОго, оказывается на расте можно писать вот воообще без ансейфа.
Правда для этого нужно быть гуглом, а не неосилятором.А вообще тенденция радует.
Дырявую сишку потихоньку заменяют на нормальный язык.
> Дырявую сишку потихоньку заменяют на нормальный язык.Ещё нет, zig будет позже. Когда устанут компилять рустовую разросшуюся кодовую базу.
>> Дырявую сишку потихоньку заменяют на нормальный язык.
> Ещё нет, zig будет позже. Когда устанут компилять рустовую разросшуюся кодовую базу.Это тот самый зиг в котором double-free делается запросто, а списка UB в документации нету?
Даааа, ну может лет через 20, оно дорастет до уровня раста.
> Это тот самый зиг в котором double-free делается запростоТот самый Zig, где ручками управляешь ресурсами.
> Тот самый Zig, где ручками управляешь ресурсами.Он это и сказал.
Хватит вам носится со своим zig-ом, у него до сих пор релизной версии нет. А с учётом того, что ничего прорывного в нём нет, то это вообще какой-то позор. Ладно бы они там афинные/зависимые типы делали или какую-то другую вещ, они скопипастить готовый функционал не могут
> Правда для этого нужно быть гуглом, а не неосилятором.Не нужно быть гуглом для этого. Этот crate-level аттрибут попадается во многих крейтах. Подавляющее большинство растоманов избегает ансейфа даже в тех случаях, когда плюсы его применения могли бы перевесить минусы. А если они и так не используют unsafe, то почему бы не похвастаться этим в src/lib.rs.
на сколько пожирнел?
Ерунда. Эти гуглярщики сделали какуюто там либу. Несложную. А на самом деле чем занимаются? Гребут бабки на рекламе в ютуб. Гребут бабло.
> Ерунда. Эти гуглярщики сделали какуюто там либу.Не какую-то, а которую будут использовать миллиарды юзеров.
> Несложную.
Угу, настолько несложную что бракодеры из FreeType уже которую CVE/RCE допускают.
> Гребут бабки на рекламе в ютуб. Гребут бабло.
Завидно?))
Юзер у этой либы один - сам гугл.
> Эти гуглярщики сделалиты хотел сказать переписали?
Скоро и переписывать не надо будет - GrapRAG (LLM)
https://youtu.be/1VgptLwP588?t=1960 (Mark Russinovich, Microsoft)
Пофайловая конвертация с Python на Rust
да-да, скоро зажравшихся айтишнегов заменит "ИИ"
а я пока побегу накручивать просмотры
А , ещё иногда требуется исправить заголовочные фаилы ты не ослышался: вручную , скоро всё вскроется это проект индустрия 2.0 тут можно стрелять так же и по своим ногам благославляя ложь и мошеннические действия в виде заговоров
Не поможет везде разные флаги , одна программа ждёт -03 другая может вообще какой нибудь -01 третья ждёт добавления пока не известного флага иначе будет в пол тора раза медленее и так далее и только вороватые чужих инвестиции через банки могут быть уверены что они правы
Это разные люди.
> Гребут бабло.Мне кажется это не проблема, а то что они маленьким детям рекламируют какой-нибудь cocos toy или что-то подобное это проблема, а порой чего похуже.
да не ссыте вы все -
glyf, CFF, CFF2, COLRv0, COLRv1, EBDT, CBDT и sbix, вариативные шрифты в форматах glyf, CFF2 и COLRv1, хинтиг шрифтов в форматах glyf, CFF и CFF2.охрененно ж нужное, полезное и востребованное. Каждый же ж день открываешь сайт с цветными (вах!) шрифтами в форматах ХЗЧТОЗАПГРБНЬv1.
(и не режешь их тут же ублоком нахрен)Короче, хрустишки, как всегда, родили ненужное ненужно в виде прослойки к прокладке, но и ее испугались тиражировать на нормальных пользователей - пусть вон эти 3% десктопов попрдлятсо, их никому не жаль.
Зато кто-то отчет об эффективной работе сдал вовремя и получил повышение.
> Короче, хрустишки, как всегда, родили ненужное ненужно в виде прослойки к прокладке,
> но и ее испугались тиражировать на нормальных пользователей - пусть вонОбожаю когда нaxyлю так рвет на части))
А ведь эту либу юзеры получат в ближайшем апдейте.
In Chrome 133 (February 2025) we enabled Fontations for all web fonts usage on Linux, Android and ChromeOS, and for web fonts usage as fallback on Windows and Mac—in cases where the system does not support a font format but Chrome needs to display it.> эти 3% десктопов попрдлятсо, их никому не жаль.
Ты с лисой не путай. Или ты про пингвинусов?
> Зато кто-то отчет об эффективной работе сдал вовремя и получил повышение.
Вполне заслуженное повышение за выкидывание древнего багованного крэпа на дырявом языке.
> and for web fonts usage as fallback on Windows and Mac—in cases where the system does not
> support a font formatспасибо, юзеры чрезвычайно счастливы твоим ПРДЛНГv2 шрифтом, наконец-то!
Но вообще-то они были бы еще больше счастливы, если бы этот дизайнерский выкидыш вообще им не показывался, или заменялся тахомой.Жаль что манифест3 вероятнее всего не даст написать примитивный плагин, делающий именно это. И "цветные шрифты" туда же.
Не беда, еще остались Epiphany, Otter Browser и Ladybird.
Спасибо, поржал. Первые два - просто несамостоятельные шкурки; последний - проект одного ноунэйма, который получил грант на лям: как только деньги закончатся, он перестанет его пилить, или потребует от милого камьюнити ещё деньжат на развлечение.
Ladybird теперь уже не совсем lady, его на Swift переписывают.
Перепишут - переименуют в Ladyboy.
Потому и тормозит этот ваш хром. Для полноты картины нужно написать сервис работы с закладами на джаве, парсинг дома на питончике, а сервис настроек на басике. Да, и еще какой-нить сервис на перлушечке.
> Потому и тормозит этот ваш хром.А оно сейчас тормозит? Но новой либы еще нет у юзеров)))
Вы прям как из того анекдота "Вы только подумайте, что будет, когда мы её включим..."Ну и тормозит по сравнению с чем? С тормозилой? С творением шерстяного? С линксами?
Просто не жалейте хрому оперативы и все будет летать.
Где он тормозит то?
Давно в мировой интернет выходил на нём?
Вот прямо вчера очередной раз сверил часы. Тормозит как не в себя.Да и лучше огненной птицы пока нет.
> Вот прямо вчера очередной раз сверил часы. Тормозит как не в себя.Удивительно. УМВР и ничего не тормозит...
Может ты пытаешься его запустить на каком-то пылесосе?> Да и лучше огненной птицы пока нет.
Ты уже принял их обновленную еулу?))
Огненная птица??? FireBird? Sql-бд?
Перед тем, как стать Firefox браузер успел побыть Phoenix и Firebird
Но я не думаю, что с Mozilla Firebird сейчас можно хоть на какой-то сайт попасть
https://www.firebirdsql.org
> если система не поддерживает формат шрифта, который пытается отобразить браузер...такой шрифт (формат) не должен применяться вообще.
на сайте freetype:The main author of FreeType was David Turner, who created the library in 1996 to render TrueType fonts, including an interpreter for handling TrueType bytecode. It was originally written in the Pascal programming language. In 1997, Robert Wilhelm ported it to C, and Werner Lemberg joined the team. Originally, the C and Pascal versions were developed in parallel, however, development of the Pascal version stopped in 2000.
Core Developers
Alexei Podtelezhnikov (Алексей Подтележников)
Suzuki Toshiya (鈴木俊哉)
Такое ощущение, что Раст тут для отвлечения внимания, погодите.А самого главного не написали. Skrifa позволит Гуглу больше не отслеживать пользователей через свои онлайн шрифты, или наоборот расширит эту возможность и через Skrifa-API будут постоянно дёргаться сервера Гугла?
> постоянно дёргаться сервера Гугла?а чьи еще сервера должно дергать гуглоподелие?
Ой чет у ungoogled chromium, работенки прибавится...
Отличная новость!
Но что еще более отлично - что таких новостей будет все больше и больше :)Количеством горения местных сишников неудовлетворен.
Где возмущение? Где "мы сделаем форк!!!111"?
Они стройными рядами перейдут на firefox...
Oh, shi...!!?
Да куда они там перейдут...
Доля Лисички (к большому сожалению) такая, что её уже в микроскоп рассматривать надо... :(Но и таки вы правы - им ещё и с Linux придётся уходить, так как Линус там тоже это... В отношении Rust тоже не бездействует )))
А потом вдруг вспомнят, что выход за границы можно предотвратить только во время исполнения, а не на этапе компиляции. На этапе компиляции можно понапихать проверок, которые будут отрабатывать во время выполнения, а потом может быть переизобретут "сборку мусора". Но сначала -- распил и откаты.
В раст в худшем случае, если не использовать get и проверки индексов, произойдет паника при выходе за границу, а не выполнение кода как в сишке. Сборка мусора не нужна
> если не использовать get и проверки индексов, произойдет паника при выходе за границуКак она произойдёт, если нет проверки индекса? Магия...
вот так и произойдетfn main() {
let v = vec![0, 1, 3, 4];
println!("{}", v[5]);
}$ ./target/debug/test
thread 'main' panicked at src/main.rs:3:21:
index out of bounds: the len is 4 but the index is 5
Тут уже ассемблер надо смотреть, есть ли там проверка условия выхода за границу
> Тут уже ассемблер надо смотреть, есть ли там проверка условия выхода за
> границутак я про конечного программистов говорю, что не обязательно париться с границами если паника допустима
1984 год, Turbo PascalTurbo Pascal checks if values are within limits. If the value is constant it is immediately checked for lower and upper limit. If it is not constant and range checking is enabled, Turbo Pascal will generate range checking code.
ага, ничто не ново под луной, в раст собрано много хорошего из разных языков
Ужасный, отвратительный был язык! Угнетал свободолюбивых дiдов и мешал стрелять себе в ноги...
И что ты тут понакалякал? v[5] - тут твой безопастный компилятор вставил рантайм проверку. Это умел делать ещё паскаль в прошлом веке.
Так даже в Си можно сделать, когда все известно на этапе компиляции.
> вот так и произойдет
> fn main() {
> let v = vec![0, 1, 3, 4];
> println!("{}", v[5]);
> }
> $ ./target/debug/test
> thread 'main' panicked at src/main.rs:3:21:
> index out of bounds: the len is 4 but the index is
> 5Показательный пример. Теряюсь в догадках, зачем он такой был выбран.
#include <stdio.h>
int main()
{
int v[] = {0, 1, 3, 4};
printf("%i", v[5]);
}<source>:6:18: error: array index 5 is past the end of the array (that has type 'int[4]') [-Werror,-Warray-bounds]
6 | printf("%i", v[5]);
| ^ ~
<source>:5:5: note: array 'v' declared here
5 | int v[] = {0, 1, 3, 4};
| ^
1 error generated.
Compiler returned: 1
заметим что данный код уже эквивалентен вот этому:fn main() {
let v = [0, 1, 3, 4];
println!("{}", v[5]);
}и выдает ошибку компиляции:
error: this operation will panic at runtime
--> src/main.rs:3:20
|
3 | println!("{}", v[5]);
| ^^^^ index out of bounds: the length is 4 but the index is 5
|
= note: `#[deny(unconditional_panic)]` on by default
Так я и заметил начало ветки - "А потом вдруг вспомнят, что выход за границы можно предотвратить только во время исполнения, а не на этапе компиляции."
Ты забыл malloc/free. Тип std::vec::Vec<T> является contiguous growable array. Динамическим массивом.fn main () {
let a = [1, 2, 3, 4];
println!("{}", a[5]);
}error: this operation will panic at runtime
--> src/main.rs:3:20
|
3 | println!("{}", a[5]);
| ^^^^ index out of bounds: the length is 4 but the index is 5
|
= note: `#[deny(unconditional_panic)]` on by default
Я ничего не забыл. Я не реагирую на последнее сообщение ветки, а читаю с корневого сообщения:"А потом вдруг вспомнят, что выход за границы можно предотвратить только во время исполнения, а не на этапе компиляции."
Почему меня и удивило, что спор ушёл не совсем туда.
Удивлю, но программы на Паскале отродясь так работают так что Раст не нужен :)
нет
> А потом вдруг вспомнят, что выход за границы можно предотвратить только во время исполнения, а не на этапе компиляции.Я не думаю, что об этом кто-то забывал. Это же базовые факты которые обсуждаются в базовом IT образовании: проблема останова не позволяет статически доказывать такие факты о коде. Поэтому программисты проверяют эти факты в рантайме. Раст отличается от C в этом только тем, что C'шники часто забывают проверить там, где следовало бы, и выходят за границы массива.
C'шники держат свои "доказательства" того, что где-то выход за границы массива невозможен в голове. Они даже не пытаются выписать эти доказательства на бумажке. Тем более они не сверяют свои доказательства до изменений кода с доказательствами после изменений. Всё это приводит к тому, что становится невозможным не упустить какие-то важные детали и ни разу не забыть про проверку там, где она необходима. Языки же полагающиеся на оптимизатор, чтобы тот выкидывал проверки, полагаются на алгоритмическое выстраивание доказательств ненужности этих проверок. То есть эти доказательства выстраиваются заново каждый раз при каждой компиляции.
Сишочные технологии шагнули куда дальше этой унылой математической черты! Ведь компилятор считает, что все уже доказано и никаких выходов за границы/целочисленных переполнений и т.д. нет и оптимизирует исходя из этого. С - это поистине могучий инструмент для сильных разумом! Жаль, что еще не родился тот сишник, что смог бы с ним совладать. Ну а пока легенда ждет своего героя, можно в комментариях болеть за любимую сишку, самое главное - не пытаться на ней писать.
>Это же базовые факты которые обсуждаются в базовом IT образовании: проблема останова не позволяет статически доказывать такие факты о кодеДля этого нужны статические типы, о которых сишники до сих пор не знают. Про языки типа ATS или Idris вообще не слышали
> Я не думаю, что об этом кто-то забывал. Это же базовые факты
> которые обсуждаются в базовом IT образовании: проблема останова не позволяет статически
> доказывать такие факты о коде.Проблема останова лишь наглядно показывает, что нельзя доказать "все-все-все" (для _всего_ возможного множества программ - но это "все возможное множество" обычно на практике и не интересно).
Выход за границы - в это "недоказуемое" не входит: или у тебя в качестве индекса заранее известный диапазон или же это (условный) внешний "user input", который _нужно_ проверять - тут-то и вылезает наследие старых ЯП с примитивными типами, "срезанием углов" и прочим.
У компилятора в этом случае, зачастую отсутствует необходимая информация ("потерялась" при преобразовании или же изначально не передаваема примитивным типом данных), вместо проверок вся надежна лишь на погроммисткое "мамой клянусь, проверил уже до этого! Правильно!" и "кто ж будет передавать неправильные данные!" или еще что-то (о приколах с UB даже не заикаемся) ...
> У компилятора в этом случае, зачастую отсутствует необходимая информацияУ компилятора есть все исходные тексты под рукой, как у него может отсутствовать информация? Компиляторы компилируют одну функцию за раз, не испольуя доступную им информацию о том, откуда и как эта функция вызывается. Хочешь ответ на вопрос "почему"? Потому что глобальный анализ триггерит проблему останова.
> Выход за границы - в это "недоказуемое" не входит: или у тебя в качестве индекса заранее известный диапазон или же это (условный) внешний "user input"
Или я индексы беру из хешмапа, преобразующего строки в usize? В этом случае надо будет доказать (в общем случае) что c любой строкой, которую я могу использовать для получения индекса, будет ассоциирован валидный индекс. Я подчеркну, что в хешмапе при этом могут хранится пары (String, usize), в которых usize невалидный индекс: до тех пор, пока я их не использую, никаких проблем не возникнет. Ситуацию можно резко упростить, потребовав для всех usize в этой хешмапе, чтобы они были бы валидными индексами, то есть нам нужна возможность объявить новый целочисленный тип, который будет диапазоном из usize, так?
Но этого недостаточно, потому что массив в который я индексирую динамический, и размер его меняется в рантайме. Я получаю новые элементы, закидываю их в массив, после чего беру их индекс и добавляю его в хешмап, чтобы их по имени искать можно было бы. А иногда, когда я вижу что накопилось слишком много лишних и уже ненужных записей, я компактифирую мой Vec, и переписываю индексы элементов в хешпаме. Как компилятор будет доказывать в этой ситуаци, что я делаю всё правильно? Какую именно информацию я мог бы ему предоставить, чтобы ему проще было бы?
>> У компилятора в этом случае, зачастую отсутствует необходимая информация
> У компилятора есть все исходные тексты под рукой, как у него может отсутствовать информация?У компилятора си, плюсов и т.д. (см. предыдущее "наследие старых ЯП с примитивными типами"). Вместо одноразового преобразования "user-input" -> "valid_index" сейчас или по десять лишних проверок -- в каждой функции, работающей с этими данными, которые компилятор оптимизировать может лишь по "косвенным догадкам". Или классическое погроммисткое "мамой клянусь, индекс валидный!" в качестве "доказательства".
> Компиляторы компилируют одну функцию за раз, не испольуя доступную
> им информацию о том, откуда и как эта функция вызывается.Угу, угу. LTO, еще ранее - inlining и прочее (ага, в том же gcc)? Не, не слышали.
> Хочешь ответ на вопрос "почему"? Потому что глобальный анализ триггерит проблему останова.
Потому что гладиолус будет вернее (глобальный анализ НЕ триггерит автомагически проблему останова, она (останова) чисто о глобальном soundness, на который можно и нужно в реальности класть большой и толстый - ну будет у нас из-за "unsound" в анализе дыры для каких-то п̵р̵и̵т̵я̵н̵у̵т̵ы̵х̵ ̵з̵а̵ ̵у̵ш̵и̵ очерь специфичный вещей, ну "и че?". Главное, чтобы на практике сильно не мешали, ну и четко обозначить для конечного пользователя (т.е. программиста) эти дыры).
>> Выход за границы - в это "недоказуемое" не входит: или у тебя в качестве индекса заранее известный диапазон или же это (условный) внешний "user input"
> Как компилятор будет доказывать в этой ситуаци, что я делаю всё
> правильно? Какую именно информацию я мог бы ему предоставить, чтобы ему проще было бы?Чисто теоретически - сделать хэшмап зависимым типом (String, dynamic_usize_from_my_func), аннотировать, что функции компактирования, добавления и прочее - возвращают валидный индекс (т.к. берут "готовый" - что в принципе и должен вывести компилятор) и "старый" хэшмап более не используется после компактирования (время жизни, все дела) ...
Чисто практически - забить (с точки зрения практического компиляторостроителя-ЯП-проектировщика) на такие "пограничные" сценарии. Пусть разработчик именно в _таких_ случаях "мамой клянется" - зато в куче других будет автоматическая валидация, а не как сейчас ...
Тем более, на фоне стоимости hashmap(hash(String))->usize -- не пофиг ли на "лишнюю" проверку размера индекса?
> Угу, угу. LTO, еще ранее - inlining и прочее (ага, в том же gcc)? Не, не слышали.Эти вещи принципиально не меняют расклада. Анализ кода остаётся локальным, просто несколько локаций объединяются в одну, чтобы работать в локациях побольше.
> глобальный анализ НЕ триггерит автомагически проблему останова, она (останова) чисто о глобальном soundness
"Глобальный soundness" -- это лишь одно из утверждений, попытка доказать которое упрётся в проблему останова. На практике подавляющее большинство осмысленных утверждений о коде недоказуемы из-за проблемы останова. Чтобы они не упирались надо писать код специальным образом, но Гёдель сказал, что невозможно написать код таким образом, чтобы доказывались бы все утверждения. Можно выбрать список наиболее интересных утверждений и разработать гайдлайны по написанию кода, по которому эти утверждения можно доказывать. Я не знаю (сомневаюсь), но готов допустить (если ты будешь настаивать), что это возможно для произвольного списка утверждений. Но даже так, утверждения за пределами этого списка опять же будут недоказуемы.
> аннотировать, что функции компактирования, добавления и прочее - возвращают валидный индекс
Я простите не понял, компилятор должен верить этим аннотациям? Или он должен их отдельно доказывать? Но как он их будет доказывать, если индекс, который валиден сейчас, может перестать быть валидным после выполнения следущей инструкции CPU? Размер массива может уменьшаться. Или ещё интереснее, элементы в массиве могут заменяться на другие, и тут будет получаться ситуация a la use-after-free: со строкой ассоциирован индекс на элемент, который уже не существует и заменён на другой элемент.
Я тут, лол, месяц перепиливал кусок lua гумнакода, потому что мне хотелось немного расширить функциональность и отловить мелкие баги, но там было написано так, что я не мог понять этого. Местами это было вида a[b[c][d]][e][f1] = a[b[c][d]][e][f2], но все имена были не однобуквенные а символов по двадцать, типа "осмысленные" и не вКамелКейсе, и не в снейк_кейсе, а простовоттак. На это сверху наложилось то, что я не знаю луа, я не знаю тех API на которые код полагается, при этом на эти API я так и не нашёл внятной документации. Я в результате перепилил код, с третьей попытки нащупав паттерны, которые работают в луа. И вот там я ходил не то что по граблям, по минному полю, из всех этих индексов для индексов, которые в самые неожиданные моменты выполнения кода оказывались невалидными. И после этого, я готов в голос ржать над теми, кто считает что про индексы можно что-то доказать. Если очень правильно писать код, то можно. По-крайней мере если человек возьмётся доказывать, и если этот человек будет небесталанным, то можно написать код так, чтобы он справился. Но если код написан человеком далёким от программирования, то там даже Теренс Тао разведёт руками в бессилии.
> Пусть разработчик именно в _таких_ случаях "мамой клянется" - зато в куче других будет автоматическая валидация, а не как сейчас ...
На "кучу других случаев" есть способы проще. Например итераторы, которые гарантируют, что выхода за границу массива не будет и количество проверок индексов будет минимально необходимым. Современные языки дают способы написать код так, чтобы (лишних*) динамических проверок бы не было, и эти способы работают в большинстве случаев, когда нужна индексация.
*) Совсем без проверок часто не обойтись, скажем: for(i = 0; i < N; i ++) уже содержит одну проверку, которая будет на каждой итерации вычисляться.
> Тем более, на фоне стоимости hashmap(hash(String))->usize -- не пофиг ли на "лишнюю" проверку размера индекса?
Дело не в стоимости выполнения проверки по времени, дело в том, что на вопрос триггернёт ли эта проверка панику или нет у нас нет ответа, и вероятно никогда не будет. Стоимость проверки по времени и так, можно надеятся, будет срезана везде, где это возможно, потому что компилятор инлайнит код индексации в массив, проверка (можно надеятся) оказывается в том же контексте, где и генерация индексов, и вот тут у компилятора есть шансы блеснуть искусственным интеллектом и формально доказать, что проверка всегда даёт позитивный результат, паники не случается, и таким образом проверка бесполезна.
Проблема в том, что компилятор не выкинет ошибку компиляции в том случае, когда он не может доказать что проверка не нужна. Компилятор не будет заставлять программиста писать программу так, чтобы ненужность проверки была бы доказуема статически.
> А потом вдруг вспомнят, что выход за границы можно предотвратить только во время исполнения, а не на этапе компиляции.На этапе компиляции можно на зависимых типах: https://dl.acm.org/doi/pdf/10.1145/277650.277732
>А потом вдруг вспомнят, что выход за границы можно предотвратить только во время исполнения, а не на этапе компиляции.Правильно, раст нужно закапать, так как в нём как и в си/крестах нет зависимых типов
Хорошая ниша для rust. Никакого обрудования. Никаких вариантов компиляции. Строго берем файлы и вытаскиваем их них информацию аккуратно парся.Вот тут да. Многие могут понаделать ошибок с памятью. Вопрос только почему шрифты окажутся подменёнными?
На компьютере пользователя? Так значит систему уже взломали.
На сервере гугла, откуда качаются шрифты. Так значит гугла уже взломали и оттуда что угодно прилететь может.
> Вот тут да. Многие могут понаделать ошибок с памятьюмогли лет 30 назад, когда парсили scanf-ами
> Вопрос только почему шрифты окажутся подменёнными?
потому что каждый второй сайт сейчас грузит свои шрифты, а uBlock Origin, который позволял этот мусор резать, в хроме запретили
Так этот парсер будет работать только с теми шрифтами, которые с гугла качаются. Или я неправильно понял?
не знаю, я новость не читал
> Так этот парсер будет работать только с теми шрифтами, которые с гугла
> качаются. Или я неправильно понял?неправильно. Вон чатгопота тебе уже принесла образец.
@font-face {
font-family: 'MyCustomFont';
src: url('/static/mycustomfont.woff') format('woff');
}шрифт может лежать где угодно
> Вопрос только почему шрифты окажутся подменёнными? ...На компьютере пользователя? ... На сервере гуглана любом сайте интернета. Еще в pdf'ку и тому подобное тебе могут всунуть кастомный шрифт, со своими глифами и всем что там полагается.
> Вопрос только почему шрифты окажутся подменёнными?Ну что тут не понятно то? Заходишь на сайт со специфическим шрифтом где есть cve, все твой компьютер взломан. Впрочем шрифты это не единственная проблема. Если браузер устаревший и cve сработает у злоумышленника, то все компьютер взломан. У меня вот ребенок недавно то ли игру поставил на телефон, то ли картинку какую не такую в интернете посмотрел, на всех домашних устройствах в браузере появилась дополнительная реклама. Нажимаешь кнопку назад на телефоне и все - видишь страницу рекламы.
>частью проекта Oxidize, созданного для перевода утилит и библиотек для работы с текстом и шрифтами с компонентов на языках Python (fonttools, fontmake, nanoemoji) и C++ (HarfBuzz, FreeType) на новые реализации, написанные на Rust.зачемв питонореализации, применяемые, очевидно, только в питоне, руст ?
оно ни безопаснее не будет, ни быстрее - форк кратно дороже
любого питонокода будет.
и даже если там как-то можно что-то сделать ffi'ем, то, все равно, зачем ??
>форк кратно дороже любого питонокода будетВ каком смысле?
>и даже если там как-то можно что-то сделать ffi'ем, то, все равно, зачем ??
Видимо, чтобы ускорить работу программ (библиотек).
>Например, на прошлой неделе во FreeType была выявлена критическая уязвимость,мне интересно, это аффтар новость не читал, или.. или кто ?
не верю, что это разрабы написали.
в FT была ошибка из-за неверного приведения типа. раст умеет от этого спасать ? (при условии, что разрабы просто варнинги выключают)
с типами ржавый очень педантичный, все заставляет явно приводить
> в FT была ошибка из-за неверного приведения типаУгу. А дальше что было? А дальше писали мимо буфера.
"в результате чего может возникнуть целочисленное переполнение и выделение буфера неверного размера. В последующем за пределы данного буфера записывается как минимум 6 знаковых целых чисел с типом "long"."
> раст умеет от этого спасать ?
Разумеется! Это же современный язык со строгой типизацией.
Мутных типов вроде signed short и unsigned long в расте нет, поэтому заменил на аналоги.
Вот код godbolt.org/z/3Tn4KTPc6.
let a: u64 = 10005000;
let mut b: i16 = a;Выдает ошибку
error[E0308]: mismatched types
--> <source>:12:22
|
12 | let mut b: i16 = a;
| --- ^ expected `i16`, found `u64`
| |
| expected due to this
|
help: you can convert a `u64` to an `i16` and panic if the converted value doesn't fit
|
12 | let mut b: i16 = a.try_into().unwrap();
| ++++++++++++++++++++error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0308`
Хотя можно и не паниковать, а взять result и проверить на ошибку.
Т.е. раст не позволяет молча выстрелить себе в ногу.
Накладные расходы на такие извращения в inner/medium inner loop могут быть очень весёлыми.
> Накладные расходы на такие извращения в inner/medium inner loop могут быть очень весёлыми.Где там расходы?
Нужно не экономить битики в цикле с писать сумму в u64 или i64. А u16.into() превращается в нужный u64 вообще одной асм командой (в релизе). Просто от программиста требуется явно указать что он таки хочет ковертнуть типы.Но да, намного веселее получить CVE in the wild и взломы со словами "зато я пару тактов сэкономил!"))
И как, много CVE in the wild лично вас затронули? Ну или хотя бы кого-то из крупняка?
> Накладные расходы на такие извращения в inner/medium inner loop могут быть очень весёлыми.Могут быть, а могут и не быть. У тебя есть профайлер для того, чтобы увидеть разницу, и если накладные расходы кусаются, то сделать как-то иначе. В большинстве же случаев приведения эти накладные расходы невозможно заметить никакими приборами, и жертвовать надёжностью кода во всех этих случаях ради некоторых особых случаев -- это так себе идея.
Хруст и профайлер, вы серьёзно? Они консольные утилиты-то годами переписывают кое-как в версию 0.01 с кучей багов.
Это выявляется на этапе трансляции, но в Си не является ошибкой. Если же требуется проверка именно во время исполнения, то накладные расходы на неё существенно меньше, чем на "выделение буфера [неверного размера]".
> Вот код godbolt.org/z/3Tn4KTPc6.Кек. "try_into().unwrap()"...
Смотри и учить, салага, как делать без проверок и без паник:
let a = 10005000u64;
let b = a as i16;Раст накидает варнингов об этом, но это отличается от C только явностью преобразования типа в коде. При этом варнинги, насколько я помню, будут только из-за того, что компилятор видит, как число не лезущее в i16 преобразуется к i16. Если преобразовываться будет не числовой литерал, а аргумент функции, компилятор промолчит.
> раст не позволяет молча выстрелить себе в ногу.
Странная фраза, напоминающая казнить нельзя помиловать. "молча" у тебя модификатор какого из действий? Действия "позволяет" или действия "выстрелить в ногу"? Если первое, то позволяет молча. Если второе, то да, не позволяет, потому что про "as i16" нельзя сказать, что это "молча".
> Если преобразовываться будет не числовой литерал, а аргумент функции, компилятор промолчит.И нафиг такое счастье? Мне наоборот нужно, чтобы он меня предупредил.
Варнинги в коде признак того, что код начинает попахивать. И их нужно исправлять.> Если второе
Вроде бы очевидно что второе. Тебе что в одном варианте, что в другом нужно явно написать "ДА, я хочу конвертнуть числа".
> Тебе что в одном варианте, что в другом нужно явно написать "ДА, я хочу конвертнуть числа".Но есть разница. Если бы не молчал компилятор, то есть не давал бы способа преобразовать u64 в u16 без обработки случая, когда значение не лезет в u16, или по-крайней мере кидал бы варнинги в тех случаях, что он не может доказать, что значение влезет (вместо того, чтобы кидать варнинги в тех случаях, когда он может доказать, что значение не лезет), то программист был бы вынужден обрабатывать этот случай.
В случае же когда не молчит программист, мы как бы полагаемся на то, что программист, пока писал "as u16", успел подумать о возможных последствиях.
У меня на старте знакомства с rust'ом был интересный опыт борьбы с этими преобразованиями. Я писал что-то там поверх ncurses, и утонул в преобразованиях. Мои собственые структуры данных хранили значения одного размера, ncurses считал, что они другого размера, и у меня чуть ли не в каждой второй строке кода был as. Вставали очень интересные вопросы, какого типа значение должна возвращать моя функция. Про try_from я не знал тогда, и AFAIR я забивал на обработку ошибок преобразования, полагая что их не будет (я думаю вполне обоснованно забивал, но я не помню).
Та фрустрация привела к тому, что я немало думал о таких вещах, всегда обращая внимание на то, как другие делают, и каждый раз сталкиваясь с необходимостью таких преобразований в моём коде, уделял неразумное количество времени на осмысление их. Так вот, я сомневаюсь в том, что "сужающий" as -- это хорошая идея. Правда также я и не уверен в этом: если сужающий as сделать unsafe операцией, чтобы заставить программистов думать, прежде чем сужать без проверки, то есть риски "нормализации девиации": программисты просто привыкнут писать unsafe налево и направо. В целом сложившаяся ситуация для меня выглядит компромиссом, который хоть и качествено лучше чем C-шный подход неявных преобразований, но при этом он далёк от идеала.
>разумеетсяа если скобки почитать ?
компиляторы С тоже об этом пишут. просто ребята с фридесктопа "проверили на ошибку", поотрубав варнинги.
> раст умеет от этого спасать ? (при условии, что разрабы просто варнинги выключают)В расте неверные приведения целых чисел генерируют ошибки, а не варнинги. И ошибки неотключаемы глобально. Можно _локально_ в каждом месте приведения писать as:
let a: u23 = 1234567;
let b: u16 = a as u16; // вот тут явное приведение типа, которое компилятор скушает молчаИ по моему опыту этого достаточно чтобы избегать большинства багов из-за неудачных приведений типов: в коде не остаётся приведений типов, которые ты не заметил. Кроме того, я всегда пытаюсь избавиться от этих as, потому что они легко могут захламлять выражения до нечитаемости. И эти попытки заставляют подумать о том, почему вообще приведения необходимы здесь, какие такие архитектурные свойства программы приводят к этому, и что может пойти не так, почему может пойти не так, и что делать в случае если оно пойдёт не так.
И я бы не полагался на то, что в растокоде не будет возникать проблем с приведениями, но вероятность их существенно сниженна, именно потому, что компилятор тыкает носом в каждое приведение. Это работа замечательного принципа, вокруг которого выстроен раст: чем более гнусную вещь программист хочет совершить, тем больше заморочного кода ему придётся писать. Весь синтаксис выстроен таким образом. И преобразования типов один из примеров: типы лучше не приводить, и поэтому их приведение требует использование as T, а иногда и try_into()?.
>// вот тут явное приведение типа, которое компилятор скушает молчабзв поэтому лучше писать let b = u16::from(a);
the trait `From<u64>` is not implemented for `u16`А вот TryFrom<u64> вполне себе.
Программист должен понимать, что это лучше. Полагаться на то, что он понимает, это примерно как полагаться на то, что программист везде где надо сам, по собственой инициативе, проверит все индексы прежде чем индексировать ими.
вообще, да.
но и варнинги не по приколу существуют.
более того, их описания тоже на что-то обычно наталкивают.
поэтому тут скорее плохой танцор, решивший танцевать с инструментом с таким к.-вом ub.
причем, __явно__ проигнорировавший табличку о последствиях.
> но и варнинги не по приколу существуют.Странно, судя про крупным проектам на них могут забивать годами.
На какой год существования ядра решили -werror включить?
И таки все поломалось. Куча народу жаловалось.Пришлось искать ко(м)промисы и в kernel оно было включено не полностью.
Ну так сишочный консенсус в том, что программист умнее каких-то там тупых компиляторов с варнингами, язык с создания это поощрял. Тем более что варнинг этот мог появиться позавчера, а код написал дед из Беркли в 1983.
Причем у этого деда из Беркли в 1983, возможно код и не вызвал современных предупреждений.Как пример код, который может компилироваться и Qt4 и Qt5,Qt6.
Там поменялось многое, но при желании можно писать один код для 3-х версий библиотек. Вот только он без танцев с бубном он будет вызывать предупреждения из-за несовпадения типов.
> Использование Rust позволило значительно снизить вероятность появления проблем при работе с памятью,Ссылку на измерения в студию или не было.
> По статистике Google и Microsoft около 70% опасных уязвимостей вызваны проблемами при работе с памятью,
Это всё та же статистика десятилетней давности, про которую растоманы нам не устают повторять, или были какие-то фоллоап исследования, подтверждающие числа?
>> Использование Rust позволило значительно снизить вероятность появления проблем при работе с памятью,
> Ссылку на измерения в студию или не было.security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
> Это всё та же статистика десятилетней давности, про которую растоманы нам не устают повторять, или были какие-то фоллоап исследования, подтверждающие числа?
Там был классный followup - отчет о написании 1.5млн строк расто кода в 13 андроиде.
To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
> 1.5млн строк расто кодаесли написать 1.5млн строк на си типа 2+2, в них тоже будет zero memory safety vulnerabilities
Спс за ссылку.Забавно, там есть анти-RiiR утверждение:
> it’s interesting to note that the percent of vulnerabilities caused by memory safety issues seems to correlate rather closely with the development language that’s used for new code. This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components.
Как я понимаю, бессмысленно переписывать старый код на rust'е, потому что там и так уже уязвимостей мало, но вот новый надо писать на rust'е, чтобы не создавать этих уязвимостей.
> Как я понимаю, бессмысленно переписывать старый код на rust'е,
> потому что там и так уже уязвимостей мало, но вот новый надо
> писать на rust'е, чтобы не создавать этих уязвимостей.Да, именно так гугл и делает. И к этому пришли в ядре.
У них есть еще другая статья, где они по своей кодовой базе пытаются рассчитать когда код становится "условно безопасным".
security.googleblog.com/2021/04/rust-in-android-platform.html
Так во после 5 лет получается что большую часть уязвимостей уже исправили.Но RiiR полезен для другого.
С одной стороны нужно на чем-то тренироваться и отрабатывать как навыки сами программистов, так и валидировать сам язык, который продолжает развиваться.
С другой - есть куча "завершенных" софтин, куда добавить как бы уже и нечего. При этом они писались непонятно как, непонятно кем и достаточно дырявы, не смотря на то, что им уже десятки лет - их же не гугл фиксит))
И вот они прекрасный кандидаты на RiiR.
Ну и утверждение гугла валидно только для переписывания за деньги.
Для их старых кодов это экономически не имеет смысла.А вот just for fun можно хоть на брейнфаке писать.
И если есть люди, которые бесплатно переписывают что-то на раст - это наоборот отлично))
Rust предотвращает double-free и use-after-free. Никаких гарантий невыхода за границы буфера он не дает. Покажите где я не прав.
> Покажите где я не прав.Где-то в части про никаких гарантий.
Раст, если при реализации втупую обратиться к индексу за пределами массива, просто паникнёт, не приводя к получению доступа к произвольным данным, выполнениям произвольного кода и прочим UB, за которые так любят сишку 90-летние пердуны.
Но нормальный разработчик будет использовать интерфейсы к массиву, которые будут давать Option или Result, которые обязательно надо обработать... либо использует iter().
> Никаких гарантий невыхода за границы буфера он не дает.
> Покажите где я не прав.Ты не можешь выйти за границы буфера если программа паникует при попытке и аварийно завершается. И то что ты не выйдешь тебе гарантируется))
Отлично! Гугл таки вляпался в раст. Будет весело)))
Настало время изумительных историй.
> Гугл таки вляпался в растЧто значит вляпался?
Он один из создателей RustFoundation и платиновый спонсор. Они платят деньги чтобы раст развивался и становился лучше.Код на расте гугл использует где-то с 2018-19 года (андроид).
Но кто ж из хейтеров об этом знает)))И оно уже давно в проде у миллионов юзеров.
Поэтому весело должно было быть уже лет пять, но что-то мир не рухнул (и андроид тоже).
Похоже, что основная причина создания Rust это работа со шрифтами:
"Использование Rust позволило значительно снизить вероятность появления проблем при работе с памятью, повысить качество кода, снизить затраты времени на исправление проблем с безопасностью и ускорить внесение улучшений в возможности Chrome, связанные со шрифтами."
Причём тут шрифты до Раста?
Сильно печот?
> Причём тут шрифты до Раста?
> Сильно печот?Читай внимательно - не шрифты для раста, а раст для шрифтов.
Ваш оппонент написал "до Раста", а не "для Раста". И кто здесь невнимательно читает?
> Ваш оппонент написал "до Раста", а не "для Раста". И кто здесь
> невнимательно читает?Выражение "не шрифты для раста, а раст для шрифтов" является моим мнением, а не цитатой мнения другого лица.
Моё мнение составлено по результатам ознакомления с публикацией и в комментарии выше я приложил цитату.
В публикации по содержанию текста указано, что с растом решаются определенные проблемы использования шрифтов.
Будьте осторожны в своих рассуждениях, ибо такими рассуждениями можно так же прийти к тому, что так же в основные причины создания Раст, можно включить ядра операционных систем и kernel драйвера)
> Будьте осторожны в своих рассуждениях, ибо такими рассуждениями можно так же прийти
> к тому, что так же в основные причины создания Раст, можно
> включить ядра операционных систем и kernel драйвера)Вообще, под Раст и ядро Линукс уже работает, и даже между мэйнтейнерами ядра Линукс была ссора (скорее всего всё ещё есть, потому что сишники не хотят код на раст и вроде даже не могут с ним работать).
> Использование Rust позволило значительно снизить вероятностьПросьба дать точечную и интервальную оценку указанной вероятности. Хотя полагаю, что подобные исследования вряд ли выполнялись. Автор исследования любит использовать терминологию из области науки, в которой не является специалистом. Все это характеризует обстоятельства вокруг сабжа как не имеющие никакого отношения к программированию.
https://security.googleblog.com/2022/12/memory-safe-language..."As the amount of new memory-unsafe code entering Android has decreased, so too has the number of memory safety vulnerabilities. From 2019 to 2022 it has dropped from 76% down to 35% of Android’s total vulnerabilities. 2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities."
> По статистике Google и Microsoft около 70% опасных уязвимостей вызваны проблемами при работе с памятью, которых можно избежать при использовании языка Rust **без unsafe-блоков**.Ну как бы даже в основной новости написано, что Rust'ом тоже надо уметь пользоваться, чтобы избежать проблем с памятью. Вот внезапность то! И с C / C++ надо уметь пользоваться! И если всё делаете правильно, а не неправильно, то не будет проблем. XD
В общем: как всегда, гаркнуть лозунг гаркнули, а вот в реальности всё будет обстоять совершенно иначе. И Раст ну никак нигде не поможет.
И, о чудо, если на Си программировать сосредоточенно и вдумчиво, а не левой ногой с анимешечкой фоном, то тоже будет всё хорошо! Проблема-то не в языке, а в котелке!)
> а не левой ногой с анимешечкой фоном, то тоже будет всё хорошо!Это что же получается? Все сишники - онимэшниги???
У дидов из FreeType и прочих дыряшечных поделий анимешного фона не видно.
Зато дыреней понаделывали - на сто лет вперед!> Проблема-то не в языке, а в котелке!)
И у всех сишников проблемы с котелком...
Может сишка разрушает мозг? Или на сишке изначально могут писать только отбитые?Но да, убогий недоязык из 70х явно в этом не виноват! Вердикт кексперта с опеннета))
> Это что же получается? Все сишники - онимэшниги???
> И у всех сишников проблемы с котелком...Весь мир сейчас на Си крутится - в каждом утюге, роутере и микроволновке есть прошивка на Си, и ничего - утюги греют, роутеры трафик гоняют, микроволновки еду готовят - всё нормально, никаких проблем с памятью не возникает. Так что сказки про какие-то там "страшные дыры" - это всего лишь плод влажных фантазий воинствующих растовиков)
> Весь мир сейчас на Си крутитсяСлава богу не весь))
Дыряшку вытеснили практически из всех областей применения. Остались только МК, но туда уже давно пришел с++ и совсем немного раст.
Ну и древние жирные проекты, которые так просто не перепишешь ни на какой язык тупо из-за размера. Например ядро линукса. Но как видишь, растовики работают и в этом направлении))Во всех областях этот хлам выкинули на мороз, заменив на с++, java, go, js и так далее.
> в каждом утюге, и микроволновке есть прошивка на Си
Или на асме.
> никаких проблем с памятью не возникает.
Потому что они не подключены в инет.
А роутеры кроме трафикогоняния регулярно становятся сетью ботнетов.> фантазий
Про эти "фантазии" мы регулярно читаем новости тут про очередную CVE.
> вытеснили практически из всех областей примененияНикто ничего не вытеснил, в самых ответственных, высокопроизводительных и нагруженных системах как был Си, так есть, и будет! Непредсказуемый С++ в бортовых системах и микроконтроллерах никому не нужен, и, тем более, на коленке написанный и нестандартизированный раст.
> ядро линукса. Но как видишь, растовики работают и в этом направленииТолько у них не очень получается) В последний раз это закончилось бабской истерикой растовика и последующим самовыпилом его из процесса разработки) Хотя жирный пингвин и говорящая лысина делают своё чёрное дело насильно пропихивая ржавчину в ядро...
> Потому что они не подключены в инет.Про умный дом не слышал?
> читаем новости тут про очередную CVEВ любых программах есть ошибки. Важно не наличие ошибок, а их последствия. Сможешь привести пример хоть одной ошибки на Си за последнее время, которая привела к катастрофическим последствиям?
> в самых ответственных, высокопроизводительных и нагруженных системах как был СиАхаха! В ответственные приложения дыряшку не подпустят на пушечный выстрел.
Максимум misra с, но там такие ограничения (напр. запрет на дин. выделение памяти), что это по факту другой язык с си-подобным синтаксисом.
Практически вся авиация летает на ада, а не сишке.> Только у них не очень получается)
Конечно. Диды копротивляются. Но, как мы видим, их уже ставят на место.
> бабской истерикой
Ты про самовыпил мейнтейнера DMA? Так он вроде сишник был.
> В любых программах есть ошибки. Важно не наличие ошибок, а их последствия.
Именно! И когда переполнение буфера дают удаленный рут - то это очень плохо.
> Сможешь привести пример хоть одной ошибки на Си за последнее время,
> которая привела к катастрофическим последствиям?Напр. CrowdStrike. Отменено 5078 рейсов. Ты осознаешь сколько это денег?))
Отменены большая часть несрочных обращений к врачам в Северной Америке. Плюс урон другому бизнесу. The worldwide financial damage has been estimated to be at least US$10 billion.
Достаточно катастрофические?
А причина - null dereference.
> а не сишкеВсё пишется, смотри рынок соответствующих вакансий.
> ставят на местоО, опять фраза из лексикона тоталитарного раст-сообщества!
> Напр. CrowdStrike"Глобальный сбой в работе Windows" А Си-то тут причём?..
>> ставят на место
> О, опять фраза из лексикона тоталитарного раст-сообщества!Ээээ? Любители СПО уже облизывали "великодушных пожизненных диктаторов" еще в то время, когда создатели раста в школу ходили.
Диктатура это одна из базовых скреп опенсорса.Как минимум на этом сайте любят наяривать на Патрика, Тэо.
Немного меньше на Гвидо с его питоном.
> наяривать на ПатрикаПатрик - диктатор?)) И кому и чего он надиктовал? Тихо-мирно пилит самый спокойный дистр, который не замешан ни в каких скандалах.
>> Напр. CrowdStrike
> "Глобальный сбой в работе Windows" А Си-то тут причём?..PAGE_FAULT_IN_NONPAGED_AREA - разыменовали 0-й указатель.
Другой вопрос, что оно было в 100% случаев, такое не то что должно заворачиваться отделом тестирования, а вообще должно туда не попадать. То есть похоже на сознательную диверсию, а вот цели не ясны.
>То есть похоже на сознательную диверсию, а вот цели не ясны.Если это диверсия, то цели яснее некуда - как можно сильнее нагадить своим пользователям. И, о чудо, у них получилось. 10 млрд. долл. - это много, очень много. Но я думаю, что у вас просто приступ паранойи.
>>То есть похоже на сознательную диверсию, а вот цели не ясны.
> Если это диверсия, то цели яснее некуда - как можно сильнее нагадить
> своим пользователям. И, о чудо, у них получилось. 10 млрд. долл.
> - это много, очень много.Когда сам себе стреляешь в ногу - это не диверсия.
Нагадили они компании Микрософт (в новостях именно их ругали) и её клиентам. Как раз через два дня после закрытия в той отдела разнообразия. ;)
> Но я думаю, что у вас просто приступ паранойи.
Диплом есть, что бы думать на такую тему? И зачем вообще об этом думать, когда можно обсуждать техническую деталь, основываясь на своём опыте создания драйверов?
>> никаких проблем с памятью не возникает.
> Потому что они не подключены в инет.Такого бреда давно не читал
> и ничего - ... роутеры трафик гоняют ... - всё нормально, никаких проблем с памятью не возникает.Кажется ты уронил свой нос 🔴.
Давай просто сделаем поиск по сайту простой фразы "уязвимость маршрутизатор/коммутатор".
И что же мы видим?Уязвимости в сетевых устройствах Juniper и IP-камерах D-Link
"критическая уязвимость (CVE-2024-21591), позволяющая удалённо вызвать переполнение буфера в доступном без прохождения аутентификации обработчике web-интерфейса J-Web и добиться выполнения своего кода с правами root на устройстве."
[1]Уязвимости в беспроводных маршрутизаторах Zyxel, D-Link и Netgear
"В беспроводных маршрутизаторах D-Link серии DSL-3788 выявлена уязвимость (CVE-2024-57440), позволяющая без прохождения аутентификации удалённо выполнить код на устройстве.
Для совершения атаки достаточно отправить на запрос к CGI-скрипту webproc с указанием в поле sessionid слишком большого значения, приводящего к переполнению буфера."
[2]Критические уязвимости в коммутаторах Cisco серии Small Business
"Выявленные уязвимости (CVE-2023-20159, CVE-2023-20160, CVE-2023-20161, CVE-2023-20189) вызваны ошибками при работе с памятью в различных обработчиках, доступных на стадии до прохождения аутентификации. Уязвимости приводят к переполнению буфера при обработке специально оформленных внешних данных."
[3]> Так что сказки про какие-то там "страшные дыры" - это всего лишь плод влажных фантазий воинствующих растовиков)
Какой ужас!
Во-1х, новостник опеннета воинствующий любитель раста и навыдумывал кучу новостей.
Во-2х, оказываются маршрутизаторы очень даже дырявые.
И в-3х, из тебя получился очень унылый 🤡, который умеет только газифицировать лужу без пруфов.[1] opennet.ru/opennews/art.shtml?num=60438
[2] opennet.ru/opennews/art.shtml?num=62677
[3] opennet.ru/opennews/art.shtml?num=59151
> И что же мы видим?И что? Ошибки в программах были, есть и будут. Обнаружили, пофиксили - всего делов! Это даже хорошо, что ошибки находят - как раз благодаря простоте и прозрачноси Си.
Какие-либо серьёзные последствия этих ошибок были?
> И что? Ошибки в программах были, есть и будут."Аварии всегда были, есть и будут. Зачем нужны ремни, подушки, ограниченичения скорости, светофоры, прочее пдд! А так хорошие водители выживыт, плохие нет, а все остальные пострадавшие - это допустимые потери"))
> Это даже хорошо, что ошибки находят - как раз благодаря простоте и прозрачноси Си.
Угу, именно поэтому ошибки живут годами и десятилетиями.
А находят их в основном фаззиногом или генераторами невалидных данных "тупые машины". Потому что мясные мешки неосиливают увидеть все связи и edge кейсы.> Какие-либо серьёзные последствия этих ошибок были?
Конечно была. Миллионы баксов убытков от простоем, взломы, воровство бизнес инфы.
> убогий недоязык из 70хТ.е. ты ездишь на суперсовременных треугольных колёсах, а не на убогих круглых недоколёсах из древности?)
> Т.е. ты ездишь на суперсовременных треугольных колёсах,
> а не на убогих круглых недоколёсах из древности?)Я езжу на современных бескамерных колесах с асимметричным протектором и беспроводным датчиком давления.
А ты все еще ездишь на литых каучуковых?
Или на оббитых металлом деревянных от телеги?
Или на каменных из флинстонов?
> Я езжу на современных бескамерных колесах с асимметричным протектором и беспроводным датчиком давления.Мы искренне рады за вас. Но как это поможет, если авто на скорости 160 км/ч на повороте с дороги вылетит?
Впрочем, приложениям на русте скорость не грозит.
> Мы искренне рады за вас. Но как это поможет, если авто на скорости 160 км/ч на повороте с дороги вылетит?Так они и помогут "не вылететь")
Это как сравнивать нормальные шины и китайский китай.
У каких сцепление будет лучше?
От то-то и оно.> Впрочем, приложениям на русте скорость не грозит.
Какой громкий пук от кексперта! Жаль в лужу.
По скорости раст сравним с дырявыми языками, спасибо проверкам "на этапе компиляции".
Можешь посмотреть тесты, но сомневаюсь что ты будешь это делать.
так он на каменных просто 160км/ч не разгонится, буксовать начнут на месте уже при 20км/ч)))
Будет лупиться каждые 200 метров по стенам, но 20км/ч же не смертельно)))
> Это как сравнивать нормальные шины и китайский китай.Здравствуй, человек из прошлого!
И как вам там, в прошлом тысячелетии?
Нет ничего в изготовлении шин, что было бы невозможно повторить.
Другое дело, что ТЫ не знаешь какая фирма какие шины выпускает - но это твоя проблема, и таких же как ты людей из прошлого тысячелетия.
> Я езжу на современных бескамерных колесах с асимметричным протектором и беспроводным датчиком давления.Ты покупаешь китайские джипы напичканные электроникой, непонятной фирмы.
А кто то покупает классику McLaren.
> убогий недоязык из 70хНу есть такие вещщи как законы гравитации.
Они тоже из 70x .
Не, не. Гравитация существовала и ранее. Но с квантового уровня к ней сегодня конечно же есть вопросы. То есть, существует ли гравитация, когда ты о ней не думаешь? Это как с Линукс, типа.
Хроморасты, раст это конечно хороший язык программирования, он решает большинство проблем современной безопасности. Много ошибок связано с утечками памяти, только я вот не понимаю - чего его так называют то? Бэкдор для специфического американского континента в самом компиляторе/библиотеке/платформе/сервисе каком-нибудь? Может ещё не известная cve в итоге компиляции? Или может смысл в том что компиляция без сети на нем не особо возможна? И на него подсаживают используя как вариант давления отключить? Ну подвох же должен быть какой-то, его бы просто так вот не рекламировали бы. Хотя признаю что язык весьма неплох.
А вы хотите, чтобы хром написал свой формат шрифтов и стал поддерживать только их, и насильно всех пересаживал с формата, который используется везде?)Выбранное решение вполне логично. FreeType не преследует цели, быть безопасной в среде, когда в неё тоннами загружают всякий мусор, и при использовании в ПО которое рендерит шрифты заготовленные его разработчиком ничего плохого не будет, неправильно отрисуется или приложение упадёт, пофиксят и всё. Тогда как в браузере, в условиях когда на вход движку может быть подано что угодно, и вполне себе сломанное и даже специально, хочется быть уверенным, что уязвимостей, которые сложно выявить как можно меньше.
А в связи с раздутостью спецификации тру тайпа протестировать все кейсы возможных уязвимостей почти невозможно.
Вот и написали своё, ориентированное на отсутствие уязвимостей по памяти, при подаче мусорных данных на вход (которого невозможно избежать в условиях браузера)
Минимум в виде 8 гб памяти больше не минимум. Покупаем сразу тридцать два. Для комфортной работы с хромом придётся купить 64 гигабайта.
Мы заметим?