Компания Google объявила о включении языка программирования Rust в число языков, допустимых для разработки платформы Android. Компилятор языка Rust был включён в дерево исходных текстов Android ещё в 2019 году, но поддержка данного языка оставалась экспериментальной. Одними из первых компонентов на Rust, которые планируется поставлять в Android, являются новые реализации механизма межпроцессного взаимодействия Binder и Bluetooth-стека...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54918
надо было на rust переписать, вот тогда дела в гору пойдут
Если при этом ещё 100500 раз повторить слово "безопасность", то код в unsafe станет самым безопасным в мире, а растаманы перестанут путать > и <=.
Если ты не понимаешь для чего unsafe, то мне даже страшно представить, что за гавнокод ты пишешь на Си.
triggered
Никакой код он и не пишет, он только комменты строчит
так нонче за комменты лучче платят. И в трудовую пишут приятное название должности.
...коммиТы, состоящие из одних только коммеНТов
> Если ты не понимаешь для чего unsafe, то мне даже страшно представить,
> что за гавнокод ты пишешь на Си.А на хрусте получается гомнокод (можно подумать, дешевые хипстеры могут что-то лучше) - только еще с более поганым синтаксисом и периодом полураспада полгода - "скачайте новый хруст, без этого не соберется". А, фичи a, b, c и d уже давно deprecated.
А знаете что? Мне проше valgrind и asan прогнать чем трахаться с этой полунедотипасовместимостью. А андроид один черт давно превратился в квазипроприетарное адово месиво, которое простому смертному отребилдить вообще не светит. Для его ребилда надо скачать половину интернета, а с переходом на гуглобилдсистему это вообще рокетсайнс, потому что этим никто кроме гугла не пользуется. В общем, проект сделал все от него зависящее чтобы его вообше никто кроме гугла руками не трогал. Хруст неплохо вписывается в ту парадигму - теперь для сборки ведроида надо будет качать еще больше барахла и тех кто сможет и захочет этим заниматься будет еще меньше. Так можно стать почти-проприетарой с сорцом. Глядишь, постепенно сорц можно станет и не выкладывать, лицензия позволяет, а билдить это все-равно мало кто может.
полностью поддерживаю, в c++ нету никаких unsafe - и нет проблем с небезопасным кодом
Осилиль наконец умные указатели.
А когда Python добавят, чтобы можно было без всяких Pydroid?
Когда он перестанет нетормозить :)
Вот кстати, мне из свидетелей раста никто так и не может сказать, в чем отличие умных указателей от растовского контроля за памятью. Вот чет не верится, что никто из них не заглядывал ни в буст, ни в раст.
Алсо, тот, кто реализовал хеши в расте, в детстве лопатой мало били?
Чем отличается время выполнения от времени компиляции?
Лучший комментарий.
Господа эксперты, кто нибудь объяснит что с этим языком не так?
Нормально с ним все. Просто на волне хайпа огребает)) Олды негодуют. Смузихлебов не любят)
Смузихлебов не любят за то, что когда 2 ляма строк уже написано и отлажено на 17, они начинают гнобить всех, за то, что уже выкатили 21, и никто кроме них не мейнстрим. На пинок от банков, бирж и военных они боятся нарваться, поэтому терроризируют остальных.
Поделитесь мудростью, кто такие смузихлебы в вашем понимании то?)
> Поделитесь мудростью, кто такие смузихлебы в вашем понимании то?)Те кто чинят то что не сломано, решает проблемы которых нет, а из улучшений предлагают "зато на %s". А, и главное - доказывают с пеной у рта что их выс@ры чем-то лучше.
С практической точки зрения улучшение, правда, в периоде полураспада и жоре ресурсов. Еще бывает в телеметрии и нежелательной функциональности и прочиx strings attached.
Как говорится, больше всего шума создает тот, кто меньше всего заслуживает внимания.
> что с этим языком не так?сложно сказать, что с ним так.
Тик-так...
1) У него отвратный синтаксис, что для 2021 года мягко говоря диагноз
2) Его ну очень активно рекламируют как серебрянную пулю от всего, забывая сказать что он решает довольно небольшой спектр проблем и в довольно узких случаях и конечно не упоминаются решения в других экосистемах, во многих из которых эти проблемы давно решены. В итоге получается реклама доместоса "мы победили проблемы С++99 встроив в язык обвязку которая давно была и в старом С++, а в новом не нужна вовсе". И уж тем более никто не упоминает о его производительности, которая ощутимо хуже того же С++ не говоря о С.
3) Это ЕЩЕ один язык пытающийся создать себе имя на фатальном недостатке. "Строим новое, ломаем старое" и "на улучшении старого не сделаешь себе имени" - вот девиз современных разработчиков языков-экосистем. Это явно не тот язык который объединит "низкоуровневых" разработчиков. Делая выбор в пользу раста мы раскалываем сообщество еще больше. Больше барьеров, меньше кооперации, больше языкоспецифичных и инфраструктурных проблем на пустом месте.
4) Локомотив этого движения АВС, гугль, мелкософт, мозилла - одни из самых подлых, лживых и недостойных компаний в айти индустрии, которые готовы на все ради денег, каждый из них неплохо отработал стратегию EEE, они утопят целую экосистему языка не моргнув глазом, если это сулит им барыши. Мозилла уже так и поступила. И конечно они будут влиять на направление разработки в своем русле.
> У него отвратный синтаксис, что для 2021 года мягко говоря диагнозВ чём отвратность синтаксиса? Тут многие это повторяют, но примеров не приводят.
> Его ну очень активно рекламируют
его пиарят такие анонимы как вы, рассказывая насколько сильно он ненужен.
Давно не работал с С/С++ но вот читая эти кавычки новые обозначения, не понимаю что и как.#[derive(Debug)]
struct Person<'a> {
name: &'a str,
age: u8
}fn main() {
let name = "Peter";
let age = 27;
let peter = Person { name, age };// Pretty print
println!("{:#?}", peter);
}Вот не понятно что за структура, она как-то от типа а зависит, или это конструктор такой или что это вообще
Что за ' тоже не понятно. Накрутили над с++ каких-то функций и сказали что переменная не удаляется со стекла при выходе, а можно ее передать на следующий уровень. Все это конечно хорошо, но почему бы не упростить все это в написании. Вот хороший пример go, все просто и понятно в синтаксисе, а если разобраться то и вообще все понятно если не мудрить с написанием. Для явы сделали более простые реализации как скала и Котлин. Все наоборот упрощают все, а не усложняют. Хотя может мне стоит разобраться в раст и станет все понятно.
go это даже не с++, это фактически надстройка над Си. Наследование через interface {} и switch .type это еще тот изврат.
> Вот не понятно что за структура, она как-то от типа а зависит,
> или это конструктор такой или что это вообщеэто не типы - это обозначения времени жизни ссылок. Да, это довольно сложная штука, но, увы, без неё и раста бы не было.
> Для явы сделали более простые реализации как скала и Котлин.
там есть сборщик мусора, тут его нет
'a - это лайфтайм параметр для ссылки. Нужен для того чтобы компилятор мог определить что твоя переменная name живет столько же сколько живет переменная peter в которой ты на неё ссылаешься через &str.
let name = "Peter";
let peter = Person { name, age };
Т.к. в твоем коде строка берется по ссылке а не копируется в структуру, то строка должна быть валидной на момент создания Person, именно поэтому нужен 'a - он проверяет что твоя строка жива и её можно использовать в структуре по ссылке.Твой код можно переписать двумя способами чтобы скрыть лайфтайм параметр в объявлении структуры.
1. Тут будет malloc на этапе создания строки.
#[derive(Debug)]
struct Person {
name: String,
age: u8,
}fn main() {
let name = String::from("Peter"); //malloc "Peter"
let age = 27;
let peter = Person { name, age };// Pretty print
println!("{:#?}", peter);
}2. Тут будет глобальная строка которая хранится в бинарнике и никаких выделений памяти. &'static это тоже лайфтайм параметр который указывает что переменная, которую мы взяли по ссылке, валидна на всем этапе выполнения программы.
#[derive(Debug)]
struct Person {
name: &'static str,
age: u8,
}fn main() {
let name = "Peter"; // Валидно на всем этапе выполнения программы.
let age = 27;
let peter = Person { name, age };// Pretty print
println!("{:#?}", peter);
}
Там нет никакой магии. Все довольно просто если разобраться для чего нужно.
можно забить и за место ссылки String положить )Я кстати, такой прикол заметил, что в расте если не хочешь париться с временами жизни ссылок - можно тупо всё копировать.
Да, это будет работать в N раз медленнее. Но если так делать - то можно писать очень даже просто, и на первое время "сойдёт"
именно так все и будут писать. хайпо-компашка из самых лживых корпораций окончательно распиарит этот недоязычёк среди вайтишников и все кто ноет, что сейчас программы медленные пишут-с, скоро вы лицезреете действительно большое переписывание. готовьте свои компутеры к эпохе раста, запасайтесь железом - оно вам понадобится. хе-хе-хе
Не все такие гении как вы, маэстро
Обновления раста ломают всё, к чему он прикоснулся, совместимость с предыдущими версиями тоже, не веришь - читай гиткомменты, разрабы очень четко поясняют белому мужскому трудовому классу, что сегодня курс другой, и если ты не с нами, то ты за столмана.
В продакшене после такого вещают манагеров, если они не успевают скрыться.
Не спец по Rust, но читал, что с версии 1.0 там всё довольно стабильно.
брехня
> В чём отвратность синтаксиса?1) Многабукав. Примеры были оптом в соседних коментах. Но растаманы предпочли не заметить или сказали что так и задумано.
2) Что еще хуже, распределение закорюк - идиотское! Выучить полторы закорюки, для повышения эффективности кодинга - ну, ок! Но в расте это через @нус. Ну то-есть let mut blah-doh as something else - им нормально, типа. Хоть это и частая декларация вроде бы. Нет, написать := если хотелось присвоение от остального отделить не судьба, паскаль не крут. Надо сразу из гребаного васика let обезьянить, чтоб сосем дно. Сишник жмет 1 кнопку. Паскалист две. Растаман рубится с прогером на васике, три. Этим обезьяны с смузи от человека и отличаются.
3) Свежую порцию закорюк подвозят в каждой второй версии. Ессно полунедонесовместимо. Так что еще даже первой версии стандарта нет, но есть куча несовместимых синтаксисов. Период полураспада кода, соответственно, как у питона какого.
4) И кстати делать rustup и что там еще чуть не пайпом в шелл с ремотного сайта - господам безопасТникам почему-то безопасТно. В свете чего их и счатают клоунами от безопасности.> Тут многие это повторяют, но примеров не приводят.
В соседних новостях их было более чем. Но растовики бубнят что гамнистый код так и задумано.
>> Его ну очень активно рекламируют
> его пиарят такие анонимы как вы, рассказывая насколько сильно он ненужен.Они лишь стебутся над навязчивой рекламой в стиле "комет и микробов убивает - если @#$нуть посильнее".
> Надо сразу из гребаного васика let обезьянить, чтоб сосем дно.
> Сишник жмет 1 кнопку. Паскалист две. Растаман рубится с прогером на
> васике, три. Этим обезьяны с смузи от человека и отличаются.
> из гребаного васика let обезьянить
>> The languages Scheme, ML, and more recently Haskell have inherited let expressions from LCFОчередная наглядная демонстрация глубины "познаний" попеннетных "анти-хрустовиков" в целом и местного Ыксперта-по-всему-294 в частности.
> Очередная наглядная демонстрация глубины "познаний" попеннетных "анти-хрустовиков"
> в целом и местного Ыксперта-по-всему-294 в частности.Слишком сложно.
Там классический "впоппеннетный теоретег" (с) (ну или 1Сник), см.
>> Нет, написать := если хотелось присвоение от остального отделить
>> ... Сишник жмет 1 кнопку. Паскалист две. РастаманТ.е. мистер Эксперт даже не в курсе, сколько кнопок жать нужно (и чем вообще принципиально неудобен := в US/DE/ES/GB раскладках при десятипальцевой печати, хотя это конечно спорный вопрос).
Ожидать от такого знания, в чем заключается принципиальное отличие let-паттернов из семейства ML-языков от паскалево-сишных "присвоений" несколько ... наивно.
> Ожидать от такого знания, в чем заключается принципиальное отличие let-паттернов из семейства
> ML-языков от паскалево-сишных "присвоений" несколько ... наивно.Расскажите подробнее? А то у меня в голове усвоилось только как пользоваться, а тут видимо какая-то теория хитрая
> Расскажите подробнее? А то у меня в голове усвоилось только как пользоваться,
> а тут видимо какая-то теория хитраяhttps://users.rust-lang.org/t/why-shadowing-is-implicit/2667
В принципе, там народ неплохо "накидал" (в смысле идей и паттернов использования, а не на вентилятор).
Тем более, "=" в фунциональщине именно знак равенства между левой и правой частью, т.е. "умеет" в деструктуризацию видаlet c = Foo::Qux(100);
...
if let Foo::Qux(value) = c {
println!("c is {}", value);
}
Сишно-паскальное присвоение тут "рядом не стояло".Ну или что-то типа
https://reasonml.github.io/docs/en/let-binding
---
Binding ShadowingBindings can be shadowed to give the appearance of updating them. This is a common pattern that should be used when it seems like a variable needs to be updated.
let x = 10;
let x = x + 10;
let x = x + 3;
/* x is 23 */
> 3) Свежую порцию закорюк подвозят в каждой второй версии. Ессно полунедонесовместимо. Так что еще даже первой версии стандарта нет, но есть куча несовместимых синтаксисов.Отличный индикатор. Позволяет влет опознать очереднгого Заслуженного Ыксперда Попеннета Ж)
> Многабукав растаманы обезьяны с смузи🤦 Почему модераторы не удаляют такие сообщения?
В целом согласен, но вот с> Локомотив этого движения АВС, гугль, мелкософт, мозилла - одни из самых подлых, лживых и недостойных компаний в айти индустрии, которые готовы на все ради денег, каждый из них неплохо отработал стратегию EEE, они утопят целую экосистему языка не моргнув глазом, если это сулит им барыши. Мозилла уже так и поступила. И конечно они будут влиять на направление разработки в своем русле.
не могу. Ты знаешь какие-то другие компании? Сравни их, например, с Газпромом, Мейл.ру, Яндекс, Касперски и далее по списку и начинаешь понимать, что на их фоне - они белые и пушистые. Я плохо себе представляю CEO Мозиллы, обращающегося к условному "навальному" - "Слышь, ты, тьфу на тебя!".
Хотя тебя скоро избавят от всех этих "самых подлых, лживых и недостойных компаний". Будет сплошной РуТуб и Мейл.ру и ты обретешь, наконец-то, счастье в своей жизни лол
> Это явно не тот язык который объединит "низкоуровневых" разработчиков. Делая выбор в пользу раста мы раскалываем сообщество еще большеСтарые "низкоуровневые" разработчики на Си слишком часто дискредитируют это сообщество дорогими и очень болезненными ошибками. Зачем объединяться вокруг абсолютно небезопасного Си, если и старые разработчики, и вновь приходящие, несмотря на кучу инструментария выявления уязвимостей, постоянно совершают одни и те же ошибки? Только потому что ты выучил и накопил опыт по Си и не хочешь переучиваться?
> и старые разработчики, и вновь приходящие, несмотря на кучу инструментария выявления уязвимостей, постоянно совершают одни и те же ошибкии тут такая добрая конторка "гуглозонт инк." выпускает милейший язычёк хруст и люди такие рррррраз - и кардинально все изменились и стали без ошибок писать и в жизни вообще с тех пор никто ни одной ошибки не совершил... и какать стали розовыми поняшами
> Старые "низкоуровневые" разработчики на Си слишком часто дискредитируют это сообщество
> дорогими и очень болезненными ошибками. Зачем объединяться вокруг абсолютно небезопасного
> Си, если и старые разработчики, и вновь приходящие, несмотря на кучу
> инструментария выявления уязвимостей, постоянно совершают одни и те же ошибки? Только
> потому что ты выучил и накопил опыт по Си и не хочешь переучиваться?Потому что это в целом более приятное, децентрализованное и независимое сообщество, не подмятое полутора мегакорпами с мегазондами под каблук, например. А его представители - и менно про, а не смузихлебы. И если кто утверждает что смузижоры не будут делать дорогих и болезненных ошибок, это возможно только в случае если они вообще не будут писать код которым кем-то пользуется. А так то самая дорогая ошибка в истории человечества вообще на "безопасной" аде была влеплена.
Синтаксис не отвратитетельный, отвратны 3 вещи:1. отсутствие автоделегирования
2. пакетный менеджер и подходы к пакетированию
3. отсутствие целостности самого языка - куча новых фич, которые потом оказываются не нужны, ибо можно понапридумывать ещё кучу новых фич. Старые ненужные фичи продолжат гнить и мне о них почему-то придётся помнить. Имейте яйца ломать совместимость в каждой новой версии уже и создавать не лоскутное одеяло, а целостный язык с минимумом примитивов, необходимых для комфортной разработки.
> 3. отсутствие целостности самого языка - куча новых фич,каких фич? пример можно? там после стабилизации future/async/await вроде ничего не менялось
> каких фич? пример можно?В новостях об очередной версии возьмите. Что, уже целые полтора месяца ничего не менялось? :)
>> каких фич? пример можно?
> В новостях об очередной версии возьмите. Что, уже целые полтора месяца ничего
> не менялось? :)я читаю все новости, как правило, там переводят какие-то методы в "стабильное" апи и добавляют больше константных дженериков.
Язык принципиально не меняется, вы примеров не приводите
Ну то-есть try_new по вашему вовсе даже не костыль? И что там насчет обратной совместимости подобных изменений?
> И уж тем более никто не упоминает о его производительности, которая ощутимо хуже того же С++ не говоря о С.Это ложь. (без сарказма/иронии)
Наверное, если там есть моззила и другие гиганты,то все возможные недостатки и достатки они уже обсудили.
Смысла писать, то, что все писали до тебя нет, прошло 5 лет с первой мной увиденной новости, а то, что тут пишут не меняется.
В общем, узбогойся, не нравится не юзай, перестань тратить время впустую. Лучше погладь кота, отдохни, выпей чаю, насладись жизнью, а не вот это всё.
Компания Google намерена инвестировать в ремонт дороги Шенчжень-Москва. Это обусловлено желанием компании увеличить безопасность и стабильность платформы Андроид. Напомним что недавно было принято решение переписать код Андроида на языке Rust. Но Google на этом не остановилась, и уже подписала контракт на освящение 1Миллона телефонов в храмах московского патриархата. Несмотря на утверждение специалиста по массовым освещениям девайсов что надобно переписать трижды, в компании поселилось противоречие между свидетелями раста и христа.
Неужели местные аноны пользуются андроидом и смартафоном? А как же вечные песни на опеннете про гуглозонды и постоянную слежку? А ведро, это вам даже не хром!
Высверленные камеры, отпаяные гсм модули, кастомные прошивки жеж
> Высверленные камерыможно же изолентой заклеить
ТруЪ-псих так не поступит.
сода+люминий+локтайт в юзб порт
> Высверленные камеры, отпаяные гсм модулиКак ты отпаяешь сотовый модем в квалкоме каком? Кристалл лазером ему покоцаешь? :)
Ну и если оно хотелось, первое что стоит сделать это выбросить андроид нафиг. Ну вот нет под него нормального софта, и операционка под стать. Все пердит-свистит-рыгает и ворует данные оптом. Если кому хотелось не этого - maemo leste есть. Блин, он даже без systemd, если кому это важно :D
И опять гулаг не слушает икспертов с опеннета...
Не слушает.
Контроль за корректностью работы с памятью процессов необходимо организовывать с помощью ядра OS и процессора.
Компилятор важен но гарантии безопасности от компилятора ты не получишь, а от ядра OS и процессора получишь гарантии безопасности.
> необходимо организовывать с помощью ядра OS и процессораВот только не существует таких ОС, которые брали бы менеджмент памяти полностью на себя, а если вдруг и есть, то на ОС общего назначения они скорее всего не потянут. Никто не запрещает сейчас взять условный Си, вызвать *alloc на рандомный размер памяти, и разместить там то, что хочется, а если *alloc каким-то образом запретить, то поднимется вой, даже тут, в стиле "олололо опять смузихлебы лезут память не умеют рулить вон из профессии"
ОС общего назначения корректно работающая с памятью: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../Linux + PAX = https://grsecurity.net/featureset/memory_corruption
BSD + PAX = NetBSD
PAX: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...
- changing the executable status of memory pages that were not originally created as executable,
- making read-only executable pages writable again,
- creating executable pages from anonymous memory,
- making read-only-after-relocations (RELRO) data pages writable again.
> ОС общего назначения корректно работающая с памятью: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../На оригинальном сервере папку Linux удалили - http://ftp.linux.kiev.ua/
Нет, она не работает с памятью корректно. Всё что она делает -- предотвращает дыры вида "исполнение произвольного кода". Она не предотвращает дыры вида "исполнение не-произвольного кода", она не предотвращает дыры вида "выйдем за границы буфера и перезапишем пару указателей на стеке, чтобы заставить программу поверить, что мы доверенный клиент, которому полагаются повышенные привилегии".
Там есть патчи реализующие pax_mprotect (выход за границы буфера, если есть попытка записи в RO область памяти должен детектится) и проги собраны с опциями ssp (защита стека канарейками, переполнение на стеке должно детектится). Патчи безопасности от grsecurity+PAX + UA попытка реализации POSIX тех годов + патчи gcc, glibc и binutils.При загрузке есть выбор уровня безопасности:
Софтмоде - только логируем
Стандарт - логируем и блокируем
Усиленный - логируем, блокируем + мандатный контроль доступа.Крайняя версия за август 2008 (на сайт не залили)
> Там есть патчи реализующие pax_mprotect (выход за границы буфера, если есть попытка
> записи в RO область памяти должен детектится)С точностью до размера страницы. Какой у тебя там размер страницы памяти? 4Kb?
Если переполнение на стеке, то отловит по любому, канарейку переполнение буфера задавит и ядро убьет процесс.
Давайте не только критику, а и предложения по усилению защиты. ;)
> Если переполнение на стеке, то отловит по любому, канарейку переполнение буфера задавит и ядро убьет процесс.Канарейка спасает от переполнения стека, то есть от ситуации, когда на стеке слишком много выделяется. Но оно не спасает от переполнения буфера на стеке и вредоносной перезаписи переменных лежащих на стеке и не имеющих отношения к буферу.
> Давайте не только критику, а и предложения по усилению защиты. ;)
Заставить программу следить за размером кусков памяти. До тех пор, пока программа нескомпрометирована, у неё есть теоретическая возможность отслеживать все выходы за границы буферов с точностью до каждого байта. Практически с этим могут быть проблемы, поскольку программа может содержать баги. Вот надо нацеливаться именно на эти баги, и снижать их число, которое вполне возможно снизить на порядок, как минимум.
А если рандомизация кучи включена:
CONFIG_COMPAT_BRK is not setecho 2 > /proc/sys/kernel/randomize_va_space
> Заставить программу следить за размером кусков памяти
Это очень дорого!!! Оно реализуется только в критических приложениях для защиты секретных ключей: openssh, gnupg, ...
Как вы относитесь к общему контролю со стороны ядра ОС о недопустимости вмешательства одних процессов в память других процессов, например YAMA в Linux:
echo 3 > /proc/sys/kernel/yama
Гляньте в Documentation/Security/Yama.txt они утверждают что ptrace закрыт даже для разных процессов одного пользователя это лучше чем:
CONFIG_GRKERNSEC_PROC_USER=y
CONFIG_GRKERNSEC_PROC_ADD=yГляньте в https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...
> она не предотвращает дыры вида "выйдем за границы буфераPAX_NOEXEC должен блокировать исполнение кода даже при перезаписи если область помечена NX: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...
>> она не предотвращает дыры вида "выйдем за границы буфера
> PAX_NOEXEC должен блокировать исполнение кода даже при перезаписи если область помечена
> NX: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...PAX_NOEXEC не запрещает выполнять код из страниц, которые помечены как исполняемые. А там знаешь как много всякого интересного? Там, например, нечаянно может оказаться интерпретатор python'а, а тот, сволочь такая, будет исполнять код из страниц не помеченных как исполняемые. Правда python'овый код, но какая собственно атакующему разница?
> интерпретатор python'а, а тот, сволочь такая, будет исполнять код из страниц не помеченных как исполняемые.Если python запущен другим пользователем, то использовать его исполняемые области памяти не удастся. DAC в DYSTRYK распространяется на странице памяти в оперативе и разделяет пямять одного пользователя от другого.
Сегодня YAMA это запрещает даже если python запущен тем же пользователем.
>> интерпретатор python'а, а тот, сволочь такая, будет исполнять код из страниц не помеченных как исполняемые.
> Если python запущен другим пользователем,python может быть подгружен как библиотека. Если не python, то lua. Если не lua, то eBPF, wasm, guile, js, или что-нибудь ещё с тьюринг-полнотой. А если нет ничего с тьюринг-полнотой, то... не надо недооценивать тьюринг-неполноту, она на самом деле тоже много чего может. Она в некотором смысле даже хуже: от тьюринг-полноты ты хоть знаешь чего ожидать можно, а вот что сможет выжать разум злоумышленника, который полгода размышляет над тем, что можно выжать из данной тьюринг-неполноты, ты никогда не угадаешь.
> python, то lua. Если не lua, то eBPF, wasm, guile, jsМеня пару лет назад, наверно через guile, ломанули и подобавляли гадости в исходники моих прог, прям русским языком матюки написали... ;)
Теперь интерпретатор или не ставлю или режу DAC:
groupadd guile
usermod -a -G guile vasya
chown root:guile /usr/bin/guile
chmod o-rx /usr/bin/guileИ не ставлю лишних интерпретатора, компиляторов и прочих сборочных инструментов.
В идеале пользователь запускает только бинари и не имеет доступа даже к /bin/sh
> А если нет ничего с тьюринг-полнотой, то... не надо недооценивать тьюринг-неполноту, она на самом деле тоже много чего может.
Как ее запустить? Допусти защита от ROP в DYSTRYK тоже есть: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...
CONFIG_PAX_RAP=y
Строгого контроля за границами буфера как в KASAN и KFence https://www.opennet.dev/opennews/art.shtml?num=54671 конечно нет. Дистр собран gcc-3 с патчами pie и ssp это середина нулевых.По странично или посегментно отлов переполнений буфера есть.
> не предотвращает дыры вида "исполнение не-произвольного кода"Атак ввиде "code reuse attacks" тогда не было, они дорогие. Защиты от ROP в тех версиях нет, защита от ROP относительно недавно появилась.
>> не предотвращает дыры вида "исполнение не-произвольного кода"
> Атак ввиде "code reuse attacks" тогда не было, они дорогие. Защиты от
> ROP в тех версиях нет, защита от ROP относительно недавно появилась.Если ты подменишь строку "*" на строку "/*", перед тем как эта строка будет передана в rm, то результатом будет удаление всех файлов. Если ты позволяешь внешнему агенту бесконтрольно писать в память процесса, то дальше тебе следует исходить из предположения, что он может сделать всё что угодно. Просто на всякий случай стоит предполагать это, потому что ты не сможешь доказать, что он чего-то сделать не может.
> Если ты подменишь строку "*" на строку "/*", перед тем как эта строка будет передана в rm, то результатом будет удаление всех файлов./ система там защищена от удаления rm -rf /.
> Если ты позволяешь внешнему агенту бесконтрольно писать в память процесса, то дальше тебе следует исходить из предположения, что он может сделать всё что угодно. Просто на всякий случай стоит предполагать это, потому что ты не сможешь доказать, что он чего-то сделать не может.
Защита процессов некая там есть. Можно портить процессы только своего пользователя, процессы в памяти других пользователей защищены от записи и чтения их неиспортишь. Защита процесов не такая сильная как сегодня в YAMA, но она проста и эфективна.
В дополнение рандомизация адресного пространства ASLR сильно затрудняет поиск в памяти нужного места для записи. Необходимо брутыосить и в логах это будет видно, можно и пользователя прибить за плохое поведение с памятью.
>> Если ты подменишь строку "*" на строку "/*", перед тем как эта строка будет передана в rm, то результатом будет удаление всех файлов.
> / система там защищена от удаления rm -rf /.Да, отличная заплатка. Продолжай накладывать заплатку поверх заплатки, я верю в тебя, когда-нибудь все эти заплаток закроют все дыры.
>> Если ты позволяешь внешнему агенту бесконтрольно писать в память процесса, то дальше тебе следует исходить из предположения, что он может сделать всё что угодно. Просто на всякий случай стоит предполагать это, потому что ты не сможешь доказать, что он чего-то сделать не может.
> Защита процессов некая там есть. Можно портить процессы только своего пользователя, процессы
> в памяти других пользователей защищены от записи и чтения их неиспортишь.
> Защита процесов не такая сильная как сегодня в YAMA, но она
> проста и эфективна.А так ли обязательно портить процессы других пользователей? Если ты можешь испортить один процесс, то ты можешь испортить все процессы им порождаемые. Переменные окружения позволяют прокинуть в них произвольные данные, а LD_PRELOAD подгрузить произвольный код. В секцию, которая EXEC. И делать всё, что угодно. Если же ты полагаешь, что защита процессов проста и эффективна, то зачем ты вообще паришься защитой памяти?
> В дополнение рандомизация адресного пространства ASLR сильно затрудняет поиск в памяти
> нужного места для записи. Необходимо брутыосить и в логах это будет
> видно, можно и пользователя прибить за плохое поведение с памятью.Да. Продолжай накладывать одну заплатку поверх другой. Я верю, что со временем это приведёт к системе, которую невозможно эксплуатировать. Есть некоторые сомнения -- не упадёт ли система раньше под весом заплаток, но я думаю что нет, она выдержит.
> Продолжай накладывать заплатку поверх заплаткиНикто бездумно заплатки на дыры не накладывал. Или поведение ядра приводилось в соответствии стандарту POSIX или уязвимости групировались в классы и разрабатывалась одна техника защиты от целого класа уязвимостей.
> Переменные окружения позволяют прокинуть в них произвольные данные,
Это да. В идеале шелы можно закрыть и исключить возможность изменения переменных окружения.
> а LD_PRELOAD подгрузить произвольный код. В секцию, которая EXEC
1. Как идея со сборкой всех бинарей статически, например как в AlpinaLinux? Есть минус в рандомизация, бинари с разделяемыми библиотеками лучше рандомизируются в памяти.
2. RO / или Integrity не дадут подгрузить лишнего.
> Если же ты полагаешь, что защита процессов проста и эффективна, то зачем ты вообще паришься защитой памяти?
Защита должна быть и бинарей в файловой системе и процессов в памяти! Не говорю, что все просто обсуждаю с вами варианты, критику ценю.
> Да. Продолжай накладывать одну заплатку поверх другой.
Бездомных заплаток не накладывал, все усиления безопасности в DYSTRYK хорошо систематизированы и структурированы.
>> Продолжай накладывать заплатку поверх заплатки
> Никто бездумно заплатки на дыры не накладывал. Или поведение ядра приводилось в
> соответствии стандарту POSIX или уязвимости групировались в классы и разрабатывалась одна
> техника защиты от целого класа уязвимостей.Это теория. А на практике, техники защиты, которые не закрывают класс уязвимости, лишь в каких-то случаях осложняют эксплуатацию таких уязвимостей, они не устраняют причину -- баги остаются, просто класс опасности бага снижается, вместо произвольного выполнения кода, мы получаем DoS. Это попытка снять симптомы болезни, не трогая причину этой болезни. И это срабатывает не всегда, потому что это заплатка, форма которой не совсем совпадает с формой класса уязвимости.
Я верю, что существует единственный перспективный способ бороться с багами, и этот способ -- интеллект. Интеллект позволяет не бороться с нежелательными следствиями багов, а воздействовать на причину, устраняя баги. Да, надо признаться, пока не придумали как писать программы без багов. Но ситуация меняется. Она десятилетиями меняется в сторону создания инструментов, которые позволяют писать с меньшим количеством багов.
То есть, ведь программист, когда пишет программу, именно что выстраивает доказательство того, что программа будет работать. Но он делает это неформально и постоянно срезает углы, и из-за этого его доказательства часто ошибочны. Это не значит, что нельзя доказать -- ты можешь докопаться к любому программисту насчёт его программы, и задать вопрос "почему тут нет проверки индекса на выход за границы" и получить ответ вида "тут индекс не может выходить за границы, потому что..." и дальше следует доказательство того, что он не выходит за границы. Такое доказательство не приводит к повышению требований к железу в рантайме. Это целиком статическая вещь. При этом, если программист не может доказать, что индекс не выходит за границы и не ставит проверку, то он не скорость программы повышает, а говнокодит, привлекая баги.
Ты не слышал про wuffs[1]? Язык, который видя a[i], пытается доказать, что i не выйдет за границы массива, и если ему это не удаётся, выкидывает ошибку компиляции. Мне очень понравилась идея. То есть ты пишешь a[i], и если компилятор не смог доказать, то надо добавить if(i < 0 || i > a.len()) { return Error } перед индексацией, после этого компилятор сможет доказать. Это, кстати, в некотором смысле подход противоположный rust'у: в расте стандартная библиотека принудительно втыкает проверки, и если компилятор потом может доказать, что они не нужны, он их удаляет. Не может, не удаляет. wuffs даёт больше контроля программисту, при этом заставляя его доказывать, что проверка не нужна, если тот хочет от неё избавиться.
На самом деле, мне всё это не совсем понятно: все программисты, которых я знаю, одержимы идеей автоматизации. Но почему-то когда речь заходит об автоматизации доказательств тех или иных свойств кода, они начинают мычать что-то невразумительное, и скатываться на всякие благоглупости, типа "реальность -- не математика, про реальную программу хрен что докажешь" и тп. Но ведь, если хрен что докажешь, то это эквивалентно поднятию белого флага и сдаче всех позиций в пользу багов. Это про программу на C хрен что докажешь, потому что C не позволяет статически энфорсить свойства программы. Поэтому они предпочитают полагаться на динамические защиты от симптомов
[1] https://github.com/google/wuffs
1. Вы делаете туже ошибку, что создатели Rust. Гарантии безопасности может дать только ядро OS и процессор. При этом компилятор очень важен для обеспечения безопасности. Но компилятор не есть ключ к гарантиям безопасности.2. Вы недоконца поняли проактивную защиту, она не только заменяет дыру на DoS. Да прога упадет, но В ЛОГАХ останется подробная запись о причинах и месте падения. Логи с падением шлем разрабам и они фиксят дыру. Баги при внедрении проактивной защиты не остаются, они все быстро находятся и исправляются.
3. GCC очень сложный, он старается защитить компилируемые проги, в некоторых местах, защищает от переполнения буфера: -D_FORTIFY_SOURCE=2. Целесообразно внедрить -D_FORTIFY_SOURCE=3.
-fPIC преобразовывает код в позиционно независимый, а -fPIE собирает позиционно независимый бинарь, который в ASLR ядре OS, грузится по разным адресам в памяти и значительно усложняет атаки. Делает их обнаруживаемыми, с записями в логах.
Техника SSP вставляет "канарейки" сигнализирует о переполнении стека.4. Если интересует компилятор проверяющий индексы можно посмотреть Fortran, Pascal. Для С-ишных прог попробуйте собрать GCC с: --param ssp-buffer-size=1 -fstack-protector-all переполнения индексов в масивах должны отлавливатся, проверьте и отпишите.
> 1. Вы делаете туже ошибку, что создатели Rust. Гарантии безопасности может дать
> только ядро OS и процессор. При этом компилятор очень важен для
> обеспечения безопасности. Но компилятор не есть ключ к гарантиям безопасности.Нет, я не делаю ошибок. Это ты мыслишь админскими категориями, а не программерскими.
> 2. Вы недоконца поняли проактивную защиту, она не только заменяет дыру на
> DoS.Это если эта проактивная защита сработает. Более того, где сработает проактивная защита? Там где ты совершил ошибку в коде? хехе, нет. Она сработает там, где код разадресовывает dangling pointer, а не там, где ты создал этот dangling pointer. У тебя в логах есть бектрейс? Или даже у тебя есть core dump? Успехов теперь угадать, каким образом этот dangling pointer был создан. Тот стековый фрейм, на котором он был создан, был удалён со стека, может быть за трое суток до того, как этот dangling pointer был разадресован. Более того, может быть ещё более мозговыносящая ситуация: dangling pointer был создан, потом двое суток он не использовался, и поэтому не создавал проблем, потом он начал использоваться, но волею случая он указывал в место, где был выделен какой-то другой объект, и таким образом все эти твои проактивные защиты не видели в этих разадресациях ничего плохого, они считали, что всё ок: указатель ведь в выделенную память указывает? Если тебе повезло, то указатель использовался только для чтения из памяти. А потом этот объект был удалён, и следующее использование dangling pointer'а привело к панике и core dump'у. Если тебе не повезло, то ситуация может быть ещё более мозговыносящей: твоя программа делала что-то типа dangling_pointer->id = 234897, это поле id попадало на поле ptr какой-то структуры, и ты по факту создавал _новый_ dangling_pointer, и в core dump твоя программа упала тогда, когда тот ptr разадресовывался.
А вот теперь, попробуй найти ошибку, которая привела ко всему этому. Я где-то как-то читал о замечательном баге, который выскакивал в программе совершенно непредсказуемо _годами_. Были десятки багрепортов о нём, но найти его никто не мог. И все твои проактивные защиты были бесполезны против него. Если тебе приходилось когда-нибудь пару дней отлаживать C'шную программу, выискивая то место, где ты забыл обнулить указатель, или может быть ты забыл не обнулить его, а индекс неверно высчитал? Или может там переполнение целого где-то случилось? Или, блин, ты не к тому типу привёл void*? Или может ты наступил на грабли UB, и поэтому проверка на NULL как бы и есть в сорце, но её как бы и нет в машинном коде? Если тебе приходилось ковыряться пару суток вокруг такой хрени, то как ты вообще можешь верить в проактивные защиты? А если не приходилось, то это говорит лишь о том, что ты никогда не писал на C, и тогда непонятно, что позволяет тебе верить в действенность защит со стороны ядра или, если уж на то пошло, в ненужность rust'а.
Все твои рантайм защиты со стороны ядра нацелены лишь на то, чтобы сделать _эксплуатацию_ таких вещей сложнее. При этом они не дают гарантий, эти защиты недоказуемы. Они усложняют атаки, очевидно, но не делают их невозможными. Поскольку они усложняют, может быть и имеет смысл их использовать, пока они не приводят к существенным пенальти в сторону производительности. Но если ты хочешь делать атаки невозможными, тебе надо сделать невозможными вот те сценарии, которые я описал выше.
> 4. Если интересует компилятор проверяющий индексы можно посмотреть Fortran, Pascal.
Да мне похрен на индексы, ты понимаешь это? Проверка индекса на выход за границы -- это лишь малая часть, того что даёт rust, и реализована она в библиотечном коде с опорой на другие возможности языка, которые позволяют реализовать такое в библиотеке, оформив это няшным и удобным для использования API. То есть, ты вот явно непонимаешь о чём речь, я поясню на примере. Допустим мне вдруг стало неинтересно, что массив паникует, когда я выхожу за границы его. Допустим я решил, что я знаю как обрабатывать в рантайме такую ошибку. Ты понимаешь, что я могу взять и изменить slice таким образом, чтобы index возвращал бы Result? Да, потом мне придётся писать
"arr[i]?" вместо "arr[i]", хм... но и чё? Ну-ка расскажи мне, как я могу паскаль научить не падать с рантайм-ошибкой при выходе за границы массива?Я тебе очень рекомендую не рассуждать о расте на основании маркетинговых материалов, а взять и попробовать. Просто заценить как это круто, когда все сообщения об ошибках, как compile-time, так и runtime указывают тебе в то место, где ты совершил ошибку, а не в рандомное место соседнего процесса^W^W... ок, в соседний процесс оно не указывает никогда, но ты понял суть, да?
> Это ты мыслишь админскими категориями, а не программерскими.Точка зрения зависит от точки сидения.
> Это если эта проактивная защита сработает.
Когда-то тестировал все эксплоиты на все CVE. Проактивная защита срабатывала всегда и во всех случаях где она была. Показатель 100%.
> А если не приходилось, то это говорит лишь о том, что ты никогда не писал на C, и тогда непонятно, что позволяет тебе верить в действенность защит со стороны ядра или, если уж на то пошло, в ненужность rust'а.
Крайнюю прошу на C написал лет 20 назад. С большим удивлением потом узнал что ее использовали более 5 лет. Да, я не сишник и грубо говоря не программист, если не считать 10 строк на баше.
Меня учили использовать для масивов for и проблем с индексами не было. Учили строго, жестко. Программировать не учили грубо говоря, учили матмоделированию и алгоритмам.
Информативность логов зависят от опций сборки!!! Безопасность тоже. ;)
> Я тебе очень рекомендую не рассуждать о расте на основании маркетинговых материалов, а взять и попробовать.
У меня, извиняюсь, органическое отвращение к языкам go, rust. Firefox на расте сложно написать так чтобы не выделялась память в режиме WX? А что сказать о сборки проекта на go: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-p2p/go-ip... 1380 пакетов в зависимостях! Без PGP подписей.
А что это, чтобы собрать раст надо компилятор раст. Они даже не задумываются пока о бутстрапе, чистом компиляторе. Кто его знает сколько дряни корпорация в этот rust уже засунули и бутстрапе пока нет и не планируют.
Мне, админу C-шные проги лучше.
> Меня учили использовать для масивов for и проблем с индексами не было.
> Учили строго, жестко. Программировать не учили грубо говоря, учили матмоделированию и
> алгоритмам.Да. Поэтому в статистику ты не веришь? Она слишком fuzzy на твой вкус, да? Статистика говорит, что проблемы с индексами возникают везде, где они есть. Но личный анекдотичный опыт важнее статистики?
>> Я тебе очень рекомендую не рассуждать о расте на основании маркетинговых материалов, а взять и попробовать.
> У меня, извиняюсь, органическое отвращение к языкам go, rust.Пфеу. С этого надо было начинать. "Органическое отвращение", ха! Ты ключевым образом не специалист в области программирования и никогда им не будешь. Инструмент выбирается исходя из требований задачи, а не исходя из личного эмоционального отношения. Пока ты к рациональным аргументам не начнёшь относиться серьёзнее, чем к эмоциональным, ты никогда не станешь специалистом.
> Они даже не задумываются пока о бутстрапе, чистом компиляторе.
Вот сейчас ты языком мелешь, демонстрируя что ты абсолютно, совершенно не в курсе. Бутстрап возможен, но слишком сложен. Но при этом вовсю идёт развитие gccrs и mrust. И на фоне этого ты говоришь "не задумываются".
Давай может, говоря что-то, мы будем всё же оперировать фактами, а не эмоциями? Ну, чтоб хотя бы на первый взгляд со стороны выглядело, будто-то бы мы квалифицированные специалисты, ведущие умные беседы, которые отличают выдумку от реальности, которые думают в терминах "создать продукт", а не в терминах "вот меня в школе препод учил использовать for", а?
Если ты о языке знаешь по маркетинговым материалам, что позволяет тебе думать, что ты знаешь сильные и слабые стороны языка? Если "органическое отвращение" мешает тебе ознакомится с языком чуть ближе? Так сложно одолевать эмоции? Попробуй тогда освоить haskell и ocaml, после этого знакомство с растом займёт всего каких-нибудь две недели, которые потребуются для того, чтобы понять требования борроу-чекера. Или haskell с ocaml'ом тоже вызывают "органическое отвращение"?
> Статистика говорит, что проблемы с индексами возникают везде, где они есть.Статистика лжет.
for заметно сокращает проблемы с индексами. А ошибки бывают у всех, недавно вносил изменения в прогу и взял уже используемый индекс... при тестировании баг нашол и исправил.
> Инструмент выбирается исходя из требований задачи, а не исходя из личного эмоционального отношения.
Как админ, сборщик пакетов, пользователь - утверждаю что раст с го это ад и Израиль! В моих системах их нет. Не попадают раст и го в мой шаблон безопасности...
Дам ссылку на одну статейку, сразу скажу что со многими тезисами автора я категорически не согласен и считаю ошибочными, но автор улавливает некие угрозы го и раст програм: https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag.../
Стоимость использования инструмента тоже важна. С-шные проги будут раз в 10 дороже чем на python, это если зарплаты одинаковы.
> при этом вовсю идёт развитие gccrs
Столмана вернем и он это безобразие исправит;) Если gccrs будет собираться дырявой сишечькой то вопрос бутстрапа будет решен. Главное чтобы этот gccrs потом смог собрать оригинальный rust.
> mrust
https://docs.rs/mrust/0.0.1/mrust/ это? Консервативен не смотрел.
> Если ты о языке знаешь по маркетинговым материалам, что позволяет тебе думать, что ты знаешь сильные и слабые стороны языка?
Точка зрения на язык программирования зависит от точки сидения!
Я не программист!!! Смотрю на раст и го как админ, сборщик пакетов и пользователь. Это точка зрения под другим углом не с нутри, а снаружи..
Firefox написанный на rust некорректно работает с памятью. Этот факт и прочие обусловливает мое отношение к "корректно работаещему" с памятью расту.
> Статистика лжет.Ну я о том же.
> Как админ, сборщик пакетов, пользователь - утверждаю что раст с го это ад и Израиль!
Очень важно мнение админа, сборщика пакетов и пользователя. Ведь именно эти группы людей выбирают инструмент для разработки.
> Стоимость использования инструмента тоже важна.
Да, это один из критериев, который надо учитываеть при выборе инструмента. Кстати, если использовать экономические инструменты (вполне применимые), то всё сведётся к стоимости.
> https://docs.rs/mrust/0.0.1/mrust/ это? Консервативен не смотрел.
Нет, вот это: https://github.com/thepowersgang/mrustc
> Firefox написанный на rust некорректно работает с памятью.
Где ты нашёл Firefox написанный на раст? Поделись ссылкой, я бы поставил немедленно. Пока мне доступен лишь ff, в котором и 10% раста нет. И про который, скажем, можно почитать такое: https://hacks.mozilla.org/2021/04/eliminating-data-races-in-.../
> Очень важно мнение ... сборщика пакетов ... Ведь именно эти группы людей выбирают инструмент для разработки.Нет. Инструмент выбирает программист.
А если инструмент и программа сборщика пакетов не понравятся, то админ и пользователь этой программой пользоваться не будут.
> https://github.com/thepowersgang/mrustc
Очень нужная для раста вещь.
> всё сведётся к стоимости
И как стоимость разработки на раст в сравнении с питоном.
Не все сведется к стоимости. Есть вещи которые надо иметь бинарнике и за них заплотят, кто понимает.
>> Очень важно мнение ... сборщика пакетов ... Ведь именно эти группы людей выбирают инструмент для разработки.
> Нет. Инструмент выбирает программист.
> А если инструмент и программа сборщика пакетов не понравятся, то админ и
> пользователь этой программой пользоваться не будут.Успехов им писать замену. Я только "за": чем больше программистов, тем лучше.
>> https://github.com/thepowersgang/mrustc
> Очень нужная для раста вещь.Возможно.
>> всё сведётся к стоимости
> И как стоимость разработки на раст в сравнении с питоном.Дороже, естественно. А почему ты спрашиваешь?
> Не все сведется к стоимости. Есть вещи которые надо иметь бинарнике и
> за них заплотят, кто понимает.Читай глазами, плз, и не выдирай фразы из контекста. Там написано: "если использовать экономические инструменты (вполне применимые), то всё сведётся к стоимости". Это конструкция если-то, A=>B. Отрицая B, и игнорируя при этом A ты выставляешь себя идиотом, кто учебник по матлогике не открывал ни разу в жизни. Там ведь эти вопросы разбираются в первой главе про натуральный вывод, или как там она называется? Хмм... за двадцать лет я забыл уже. Но в англоязычной литературе это называется propositional calculus.
> Язык, который видя a[i], пытается доказать, что i не выйдет за границы массива, и если ему это не удаётся, выкидывает ошибку компиляции. Мне очень понравилась идея.Вы уловили ценную идею. Лет 10 назад в некоторых дистрибутивах GNU/Linux еще поддерживались флаги GCC:
-Wformat -Wformat-security -Werror=format-security
сегодня люди закончились и сборку с этими флагами дистры уже не тянут...
> Это про программу на C хрен что докажешь, потому что C не позволяет статически энфорсить свойства программы.Не знаю какой у вас дистрибутив GNU/*, BSD* в Gentoo есть такая фича как "проверка качества", устанавливается переменными:
QA_STRICT_* = "set"
FEATURES="... stricter ..."
Все доказательства для разработчиков находятся в файлах:
grep -l 'QA' /var/log/portage/elog/*
> и разместить там то, что хочетсяДепартамент обороны США категорически запрещает с 1983 года:
2.1.3.1.1: «The TCB shall maintain a domain for its own execution protects it from external interference or tampering (e.g., by modification of its code or data strucutres).»
По этому делаю:
echo "appraise func=BPRM_CHECK mask=MAY_EXEC
appraise func=MMAP_CHECK mask=MAY_EXEC" > /sys/kernel/security/ima/policy
SecurityIs the FreeBSD team interested in using safer languages like Rust to improve security? Baldwin did not see this as the primary route to more memory safety. "One of the things I work on is a project at Cambridge called CHERI (Capability Hardware Enhanced RISC Instructions) that allow us to push special memory safety into the processor itself, so that you're able to have a much safer version of C itself.
"And that will compose well with languages like Rust. It means we can take the safeness of the language and enforce it further down the stack than we currently can. So my personal bias is I think CHERI is going to be a better solution. FreeBSD is largely written in C and we were able to run the whole base system on CHERI. So we have all of that C code running as a safer C. I think that's the more likely future way to get memory-safe systems."
https://www.theregister.com/2021/03/10/the_state_of_freebsd/
Конечно, если Вы застряли в 60-х, то это заявление - истина, потому, что идея из той эпохи, тогда верили, что программы в 90-х будут летать, интерпретируя лисп или бейсик на интеллектуальных процессорах, обеспечивая тотальный контроль за качеством кода, да, из тех фантазий возник intel432 на аде, да и алгольные суперкомпьютеры... но прошло время, идиоты ушли, пришли другие, банкротства заблуждений никого не учит...
А проблема в другом, проблема си - сам си, он родом из конца 60-х, начала 70-х, он не про программирование, он про 16-и битные контролеры, вся "программа" которого не может "не влезть" в ограниченные рамки (большего все равно никто не даст), и поэтому дискет вполне хватало, и выразительности языка, тем более для программ на 1-2 страницы распечатки. Не нужен был для перфолент "надежный" язык программирования, нужен был язык описания автоматов, тем более в эпоху засилья фортран-программистов и паскаль-апологетов...
Войну с ассемблером си выиграл.., за счет некорректных трюков с освобождением памяти, последствия которых и разгребает раст, а суть проблемы не в памяти, а образовании "программеров" и профов, которые генерят си-фантазии с запахом вишни. Дело в том, что (и в 60-х!) могли писать корректные программы, даже на ассемблерах, только... таких людей - единицы, большинство программистов даже не способно освоит программирование... и раст решает проблему отсеивания последних экземпляров, вызывая у них культурный диссонанс и ненависть к языку, а не к своей необразованности.Человеку с "такими" взглядами на раст (на язык дающий только инструментарий, а не решение), в профессии делать нечего, он не способен сделать процессор, потому, что это единая система: язык и исполнитель.
А си OS - обречены, тем более такие древние, но если он считает, что можно и дальше откапывать труп Multics... пусть экспериментирует, VM - тоже из той эпохи! и... си - "быстрый" язык для создания супер-медленных систем jit- интерпретирующий java и js в изолированных VM... эпоха победившего разума!Прекратите тянуть труп из 60-х, tcc генерирует отвратительный код - это тот уровень который может дать си( это предел языка ), а gcc - берет код от "си-программера" и делает из него "вменяемый" по быстродействию, да и только если не брать во внимание код freebsd и более древний, он непредсказуемо крешится после применения оптимизаций -о3... и от черихлеба это никак не зависит, трюки были созданы, когда си-компилятор был туп, и все, что от последнего требовалось - не лезть со своими оптимизациями, просто все во фре - прогнило, и код и идеологи.
> дальше откапывать труп MulticsНедавно опять смотрел, ту часть Multics которая касается безопасности. Да это 1960-тые годы. Да прошло уже ~60 лет. И она полностью актуально до каждой буквы и запятой сегодня. 2+2=4 так было есть и будет.
> tcc генерирует отвратительный код
Он нужен только как промежуточный компилятор в процессе бутстрапа.
> раст решает проблему отсеивания последних экземпляров, вызывая у них культурный диссонанс и ненависть к языку, а не к своей необразованности.
Язык должен быть простой, синтаксис удобочитаемый и легко понимаемый. Иначе будут большые сложности аудита и поддержки кода.
А "програмистов" можно отсеивать на тестовой программе уровня олимпиады. Зачем язык портить?
https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag.../Rust имеет проблемы с дроблением, а вот статистическую сборку бинаря в плане безопасности я одобряю. ;) C проги для безопасности также надо линковать статически.
> Rust имеет проблемы с дроблением, а вот статистическую сборку бинаря в плане
> безопасности я одобряю. ;)Ты блэкхэт чтоли?! Так то да, удобно - у лоха непатченая либа или что там, а он об этом даже не узнает, как он ее трекать то будет статически влинкованую? Пакетный менеджер и прочие глупости либу не видят же. И ее заапдейченость на совести хрен знает кого, от проги зависит. И безопасТность скатится до уровня виндов, где цать лет не обновляемые проги с известными эксплойтами.
Нет я вайтхед :)А ты расист? Черных не любишь?
Гента выловит завасимости и при статической линковке.
equery d имя_пакета
И по /var/db/pkg/*/*/NEEDED* можно грепнуть.
А проблемы недопакетных менеджеров меня не колышут.
> Контроль за корректностью работы с памятью процессов необходимо организовывать с помощью ядра OS и процессора.Дело уже идёт к выпуску.
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
Ох, уж эти маркенеджеры! Правильный график - это развернуть на 180 градусов и назвать анализ "качество кода падает с каждым годом". Нет, ребята, раст вас не спасёт.
Но свой профит они с этого имеют:
понижаем порог входа(js, rust),
на рынке до фига говнокодеров,
средняя зарплата по рынку падает,
"сеньор" стоит дешевле.Качество не главное)
Порог входа в раст выше, чем в плюсы. На плюсах любая макака с порога может начать говнокодить, с утечками, уб и гонками, зато всё скомпилируется. А вот порог, где хороший код отличается от плохого, на расте
а. и правда чуть пониже за счёт дружелюбного конпелятора
б. самое главное - его лучше видно. Искать уб и гонки в коде растовика нужно только в unsafe блоках, которых может вовсе не быть. А код плюсиста - весь unsafe, или ты веришь ему на слово (у него же борода), или просишь ещё 3х плюсистов поискать ошибки в коде (если он без бороды).(а утечку в расте нужно ещё постараться создать, это примерно как вирус под линух)
А чего там стараться? `Box::leak` и погнал )
Потом спрашиваешь:
- А зачем ты тут `leak` вызываешь?
- А я в лайфтаймы не смог, решил `'static` сделать ))))
Линтер перед мерджом в помощь - просто запретите мерджить такое.С плюсами придется просто запретить мерджить.
> Линтер перед мерджом в помощь - просто запретите мерджить такое.И увольте всех вебмакак. Наняв профи втрое дороже. Ага, размечтался. Хруст корпам нужен для того чтобы безмозглых макак можно было на галеру к веслу приковать, подешевле. Если это не получится, его зак@пают по бырому. Мозилла в общем то уже.
> Понижаем порог входа
> RustВообще мимо, порог входа там вполне себе здоровый. Rust не упрощает разработку, он лишь не дает случайно отстрелить ногу.
И компилятор зверь, расслабиться не даст.
А если пытаться с ним бороться и затыкать ошибки (вместо того чтобы продумать нормально, где владения где заимствования и как обработать Result), то на программу будет больно смотреть и захочется переписать это по-нормальномуА вот Golang уже больше подходит под ваш комментарий)
> он лишь не дает случайно отстрелить ногу.Именно поэтому там наколенный пакетный менеджер не проверяющий что качает и rustup и какие там еще пайпы в шелл с ремотного сайта.
> А если пытаться с ним бороться и затыкать ошибки (вместо того чтобы
...написать везде unsafe :). Обкатаная технология, еще адовиками в ариане 5 проверена.
> продумать нормально, где владения где заимствования и как обработать Result), то
> на программу будет больно смотреть и захочется переписать это по-нормальномуНу так может компилеры надо делать не через @нус, чтобы с ними бороться не надо было и все было просто, консистентно и логично? И это походу не про хруст.
> Ох, уж эти маркенеджеры! Правильный график - это развернуть на 180 градусов и назвать анализ "качество кода падает с каждым годом".Если бы у них в графике получился бы не пуассон, то это было бы _очень_ странно.
Ну что сказать это было ждидаемо.
Да и как могла твквя радужная (гоп)компания как Гогольмоголь
пройти мимо такого прекрастного сообщества любителей коричнегого как раст.
Теперь они наконец то смогут вместе одной компанией участвовать в парадах.
А синтаксис хруста все равно блевотен!)))
Не то что в прекрасном С++, да?)
да
да
да
Простите, а при чём тут С++?
А с еще ржавчину сранивать то?
С си-с-классами.
в расте нету классов
Да. Но нечайно плюсанул, не обольщайся
Выйди и зайди нормально, как настоящий аноним. И поставь минус.
>Не то что в прекрасном С++, да?)Синтаксис С++, конечно, не идеал. Но, по сравнению с Rust, он человеческий.
Дык котлин же есть, он интереснее по всем параметрам
Системное программирование на котле? Да вы батенька ебобо.
Для системного программирования есть С.
... из-за возможностей которого в совокупности со способностями разработчиков на нем (многие десятилетия нескончаемых однотипных ошибок) и привели к созданию в том числе и раста. В топку бы Си выкинуть, но на нем (исторически сложилось) мириады тонн нужного софта написано. Твой Си для Андроида с трудом вписывается в то гугловское "правило двух". Но настоящим крутым разработчикам, таким как ты, это не нужно, оно для слабаков. Тебе же привели статистику по ошибкам памяти в Андроиде, но таким как ты "хоть ссы в глаза - всё божья роса".
Как напишешь аналог андроида на расте - поговорим. Вы вон редокс еще дописать не успели, а он уже утек... Где безопасноть то?
Утечка памяти не является ошибкой памяти. Memory leaks are memory safe. Учите матчасть )
> Утечка памяти не является ошибкой памяти.Наверное она является фичой памяти :)
СПИРВА ДОБИЙСЯ!11
Да-да, мы услышали, а теперь кидай свой профиль гитхаба и покажи, какой ты батя.
Я системный администратор. Какой тебе нужен профиль на гитхабе?
Просто заявления, - что вот супер-пупер технология(rust), а все остальное нужно выкинуть на помойку(C, C++), и при этом в качестве аргументов только слюни и брызги фанатов - вызывают недоумение.Появилась новая технология(язык в данном случае) - отлично. Но прежде чем совать его везде, неплохо бы показать чем он и продукт, созданный с его применением лучше. Вон люди в теме пишут, что rust решает уже решенные проблемы, и при этом софт, написанный на нем работает медленнее. Ну а в системном программировании будет полно unsafe - и код на rust по безопасности будет мало чем отличаться от того же С. Ну и зачем он нужен тогда?
И да, на С я немного писал, на С++ тоже(правда исключительно как на С с классами). Только было это лет 15-20 назад. Сейчас больше мелочевка на python/bash для автоматизации. И не вижу проблем при работе с этими языками, если голова на месте. Вот сейчас снова возникла необходимость в небольшой програмке(dns proxy с специфичным поведением). Скорее всего возьму для этого С.
> Я системный администратор. Какой тебе нужен профиль на гитхабе?А, ну понятно. Черный пояс по болтанию языком.
Ты не нас переубеждай, ты вон иди разрабов андроида убеждай. Они-то решение уже приняли (изучив все за и против), но твоего "авторитетного" мнения уже не знают.
>>Ты не нас переубеждай, ты вон иди разрабов андроида убеждай.Я тут никого не убеждаю. Исключительно ИМХО. Это фанбои раста(вы, кстати, из них?) на каждом углу орут, что все остальное не нужно. Вот эти крики и достали.
>>А, ну понятно. Черный пояс по болтанию языком.
Можно узнать вашу область деятельности? И вы уверены,что моя работа - "болтать языком"? За слова свои, конечно, готовы ответить?
> Это фанбои раста(вы, кстати, из них?) на каждом углу орут, что все остальное не нужно.Чей-то орущими я тут замеча только вбросчиков и "антирастовиков" различной степени упор^W фанатичности.
>> Вон люди в теме пишут, что rust решает уже решенные проблемы, и при этом софт, написанный на нем работает медленнее. Ну а в системном программировании будет полно unsafe - и код на rust по безопасности будет мало чем отличаться от того же С. Ну и зачем он нужен тогда?
> За слова свои, конечно, готовы ответить?Балаболка опеннетная, обыкновенная, двойностандартная.
>> Балаболка опеннетная, обыкновенная, двойностандартная.Где вы двойные стандарты увидели?
>>>> Вон люди в теме пишут, что rust решает уже решенные проблемы, и при этом софт, написанный на нем работает медленнее. Ну а в системном программировании будет полно unsafe - и код на rust по безопасности будет мало чем отличаться от того же С. Ну и зачем он нужен тогда?
Я думал, сейчас аргументировано приведут опровержение, но, как понимаю, его не будет?
Ну и кто тут "балаболка"?
В реале я бы еще и за балоболку спросил, но... В общем, не о чем с вами более дискутировать.
>> то rust решает уже решенные проблемы, и при этом софт, написанный на нем работает медленнее. Ну а в системном программировании будет полно unsafe - и код на rust по безопасности будет мало чем отличаться от того же С
> Где вы двойные стандарты увидели?Требовать от других готовности "ответить за слова", при этом повторяя за Ыкспердами опеннета обычный оепенетный бред. Пруфы где?
>> Вон люди в теме пишут, что rust решает уже решенные проблемы, и при этом софт, написанный на нем работает медленнее. Ну а в системном программировании будет полно unsafe - и код на rust по безопасности будет мало чем отличаться от того же С. Ну и зачем он нужен тогда?
> Я думал, сейчас аргументировано приведут опровержение, но, как понимаю, его не будет?Видишь ли, "знаток" ты наш ненаглядный, бремя доказательства лежит на утверждающем. Т.е на тебе. Чайник Рассела и все дела.
Но так и быть:
> Here are the abilities Unsafe Rust has in addition to Safe Rust:
> * Dereference raw pointers
> * Implement unsafe traits
> * Call unsafe functions
> * Mutate statics (including external ones)
> * Access fields of unionsвсе.
Такое вот "будет мало отличаться", ога.
О "решает уже решенные проблемы" и "при этом софт, написанный на нем работает медленнее" я не говорю - пруфов этих "вумностей" ведь не будет?
И кто ты после этого?> Ну и кто тут "балаболка"?
> В реале я бы еще и за балоболку спросил,Но остался бы ею, совершенно независимо от результата "спроса".
> но... В общем, не о чем с вами более дискутировать.
Дискутировать с оскорбившейся балаболкой действительно не о чем.
Ты все перепутал. Люди нормально писали себе программы и никаких проблем небыло и тут вдруг появился раст с абстракными, но очень дырявыми програмиздами и понеслось обосцывание глаз.
А график (в статье) Гугл специально сфабриковал, но анонима с опеннета так просто не проведёшь - сразу раскусил что проблемы-то не было.P.S. Кто-нибудь в курсе, почему антирастеры ведут себя так же, как сторонники плоской земли, "американцы не были на Луне", "Билл чипирует вакциной 5G" и прочие фрики?
Вы 2 плюса забыли.
А Kotlin Native как же?
Анон выше про ебобо в точку попал.
Кто-то даже не знает что такое Котлин, а уже ноет. Системного там ни шыша не будет на хрусте
> Системного там ни шыша не будет на хрустеАга, на строчках статьи про новую подсистему межпроцессного взаимодействия и блютуз-стек ты наверное чихнул, отвлекся и пропустил их? Это ведь конечно не системщина, а так, рядом с Tux racer'ом валяется/запускается.
С каких пор> подсистему межпроцессного взаимодействия и блютуз-стек
это системное программирование ?
Сразу видно настоящего иксперта опеннета. Жаль, конечно, что гугл к вам на консультации не ходит.
межпроцессовый xml , тебя видать роняли в дентсве с размаху
Раз:> System software is software designed to provide a platform for other software.
Два:
> Application software (app for short) is computing software designed to carry out a specific task other than one relating to the operation of the computer itself, typically to be used by end-users.
Теперь ты можешь разобраться, что такое прикладное программирование и что такое системное, а также узнаешь, что xml к различию этих двух видов программирования совершенно ортогонален. И не стоит проецировать травматичный опыт собственного детства на всех окружающих.
Есть в принципе и Scala Native и C# и F# давным давно. Даже есть ОС написанная на C#. Но есть "но"...
Great news!
Да, наконеч закопают андроид и придут нормальные системы на нормальных языках. Rust к ним не относится.
пришел почитать экспертов с opennet по этому поводу
Fracta1L пока молчит 😑
У него раст упал.
>Fracta1L пока молчитФрактал полсе этой новости - в дугу :)
по этому не доступен :)
На облечивании
А зачем мне тут что-то говорить)))
А что ему говорить - "специалистов с опеннета" уели разработчики андроида (на минуточку, самой популярной мобильной ОС). Да еще и с обоснованием и графиком.
Сейчас начнётся ©®™
А Столман пользуется мобилой? Ведь ОпСоС может отслеживать перемещение анона.
Конец ведру
- Мозила начала использовать раст
- Доля FF упала до 1%
- Мозила выгнала растаманов.
...
- Гугл начал использовать раст...
- Мозила выгнала растаманов.А до этого растаманы выгнали Грейдона Хоара.
> - Мозила выгнала растаманов.
> А до этого растаманы выгнали Грейдона Хоара.Это да, если бы не они ... А так, Митчель очень внимательно прислушалась к негодующим сотрудникам из Mozilla Research и со слезами на глазах ...
Часовню кстати, тоже они развалилил. Инфа 146%!
И Храм на Храмовой горе тоже их рук дело.
- Мозилла начала обезъяннить хромогугель, развивая "сервисы", выкидывая XUL и кладя на разработку браузерного движка
- Анонимы на опеннете начали хаять раст
- Доля FF упала до 1%
- Мозила выгнала команду реагирования на угрозы, часть комманды по безопасности, всех сотрудников Mozilla Developer Network и растаманов из Mozilla Research, оставив только скруглителей углов и менеджеров
- Доля FF почему-то не выросла
...
- Гугл начал использовать раст...
- Анонимы, хающие раст на опеннете, подорвались от такой наглости
Дрожь от близких подрывов, громкий залп пуканов
Дружный вопль "Вы все врети! Аноним к атаке хруста готов!"Это опеннет, детка!
О-о-о-у-у-о-о-о, это опеннет!
Сарказм как у Виллема родившегося 1982 году.
Да уж, ты и белое назовешь черным.
Мозилла уже давно на дне, задолго до раста и выбираться не собираются, но вид деятельности разводят. Раст как раз и был одной из таких деятельностей-ширм. Было бы странно если бы ширму выкинули, а толстый живот остался.Раст и в фурифоксе на протяжении 12+ лет не смог составить ощутимой доли в коде, если хром (заметь, не абстрактный гугл) начнет его использовать, понадобится еще лет 30, чтобы кто-то это заметил.
> Да уж, ты и белое назовешь черным....
> Раст и в фурифоксе на протяжении 12+ лет не смог составить ощутимой доли в коде,Очередное Очень Ценное Мнение. Пишите исчо!
> Конец ведруПоддерживаю. Но новоть этим и хороша.
> Конец ведруЭто Расту конец.
Раст выбросили в помойное ведро. Вынесут раст в помойном ведре на помойку, потом ведерко ополоснут, чтобы растом не воняло и Го в него выкинут...
Корпорация все что им не нужно в Linux выбрасывают.
Одни уже пытались использовать хрустик. 2021 год, на растишке довольно небольшая часть кода, разработчики предпочитают не связываться с фурифоксом в том числе из-за нелюбимого раста, да и сам раст выкинут на мороз, подбирать его видимо будут гугл и мелкософт, у обоих есть "типа безопасные альтернативы" джава, c#, go, все три внедрялись (особенно джава) под предлогом безопасности и скорости. Ни того ни другого не получилось, не получится и с растом, потому что он далеко не серебряная пуля, а решает либо очень узкий класс проблем, либо то что давно решено, даже в современном c++ (при лучшей производительности)
Вот истину глаголишь. Или существишь.
Хоть один все по полочка разложил.
> Хоть один все по полочка разложил.Сам себя (для надежности раза два) не похвалишь, никто не похвалит?
Выкинут на мороз? Про Rust Foundation ты видимо не слышал?
а решает либо очень узкий класс проблем, либо то что давно решено, даже в современном c++ (при лучшей производительности)Как с помощью с++ можно решить проблему, если проблема - с++ ?
А на джаву и дотнет не надо гнать, хорошие языки, безопасные. Последние версии дотнета еще и почти радикально решили проблему NullReferenceException
Ну всё! И сюда добрался...
Так ржавчина она так и распространяется. Поражает как раковые клетки разрушая всё на своём пути. RIP Android. Как и любой проект где появляется раст.Да и сообщество у них само по себе такое. Гнилое. Они друг друга сожрут. Как та история с челом который какой-то сайт на расте написал. Так его свои же загнобили.
Прикольно. У растоманов такая короткая память. Они буквально на следующий день забывают как сами облажались.Указываешь на исторический факт. Когда растоманы друг друга жрали и чмырили потому что у них там идиология разошлась в каком-то проекте. Так они своего - же зачмырили, и не важно что чел проект на их хвалёном расте написал. Даже за своих порадоваться не могут.
Но потом сразу приходят модераторы и начинают прятать такие соощения. Как это так. Указали на гнильё любимой ржавчины. Да не приятно правду слушать.
Посмотришь так на другие сообщества. Люди друг другу проблемы помогают решать. Советы дают. А эти только хейтят другия языки, слепо восхваляют свой раст и чмырят друг друга.
Интересно через сколько опять модератор скроет правду которая ему глаза режет
А почему для обеспечения безопасности кода на Rust в Android не применяется sandbox-изоляция ?
А потому что у Rust и так "Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами и учёт времени жизни объектов (области видимости), а также через оценку корректности доступа к памяти во время выполнения кода".
И вся эта красивая сказка рушится на unsafe. Как недавно падал FF из-за кривого раст-кода.
От кривого кода уже изобрели обзор кода (code review) и автотесты.
Если ты в своем проекте делаешь code review, на ревьювера ставишь не идиота, то тогда зачем rust?
Code review нужен не для того, чтобы можно было продолжать писать на говне.
Чтобы ревьюер просматривал не тысячу строчек, а внимательно изучил unsafe-блок на десять и прилегающее к нему.
Зачем тогда нужен этот ваш сРАСТ?
> От кривого кода уже изобрели обзор кода (code review) и автотесты.Все мы знаем как проходит код-ревью
> Все мы знаем как проходит код-ревьюНе все, и не мы. В разных компаниях/проектах по-разному.
В том падении заменив растовый panic на плюсовый std::exception разве что-то бы поменялось?
Да, аноним перестал бы бугуртить.
Лол, зачем тогда нужен раст если нормальные язык делают всё то же самое и даже лучше.
> проверку ссылок, отслеживание владения объектами и учёт времени жизни объектов (области видимости),С разможрозкой. Это уже давным давно есть в С++. И куда лучше.
Но куда тебе умные книжки читать.
Кому в 2021 нужен С++
К сожалению ничего лучше пока не изобрели.
D же :)
Си?
>> проверку ссылок, отслеживание владения объектами и учёт времени жизни объектов (области видимости),
> С разможрозкой. Это уже давным давно есть в С++. И куда лучше.Очередной бугурнящий Эксперд Опеннета?
Пример можно с отслеживанием владения объектов на плюсах и учетом времени жизни?
> во время компиляции через проверку ссылок, отслеживание владения объектами и учёт времени жизни объектовОн точно проходит весь граф зависимостей?
Все состояния этого графа точно достижимы?
Это точно не займет больше времени жизни вселенной?
Там сделано поумнее, не так тупо. Почитайте про Rust в интернете, есть масса описаний.
Это список того, что ржавый не гарантирует. jmp бомбы они даже не собираются обходить, и если с++ в этом случае выстрелит в колено сразу, то раст забьет, и это никак не обойти, потому что фича.
Представьте себе Rc<T>(счётчик ссылок) как телевизор в гостиной. Когда один человек входит, чтобы смотреть телевизор, он включает его. Другие могут войти в комнату и посмотреть телевизор. Когда последний человек покидает комнату, он выключает телевизор, потому что он больше не используется. Если кто-то выключит телевизор во время его просмотра другими, то оставшиеся телезрители устроят шум!Не надо никакой граф обходить.
поздравляю - у вас граф.
Refcount увы тоже либо не обеспечивает освобождение памяти либо требует анализа графа ссылок. И доступен на с/с++
Памяти не хватит.
Ну включен. Даже Go гугловцы не реализовали. Ни чо чем новость. Все равно надо будет ежемесячно обновлять систему патчами безопасности.
То систему обновлять. Теперь тебе придётся ещё и раст обновлять. Но на это у тебя не хватит памяти.Да ни у кого не хватит. С такими то утечками. И определятелями доступной памяти.
Да просто Ржавой идет без библиотеки как Си библиотека системная. Эти сумасшедшие разрабы хотят Ржавого в ядро пихнуть. Если glibc весит мегабайты, musl намного легче, то тянуть rust-std весом в 117 мегабайт (больше ядра в 100+ раз) это как-то странно.
> Если glibc весит мегабайты, musl
> намного легче, то тянуть rust-std весом в 117 мегабайт (больше ядра
> в 100+ раз) это как-то странно.Я смотрю, у местных "консерваторов" совсем уж фантазия разыгралась:
$ du -Ah usr/lib/x86_64-linux-gnu/libstd-6bf3f16f340782ca.so
4,5M usr/lib/x86_64-linux-gnu/libstd-6bf3f16f340782ca.so
Ога, ошибочка вышла. Ржавой весит 485 мегабайт в войде. Одна библиотека не ставится отдельно.
> Ога, ошибочка вышла. Ржавой весит 485 мегабайт в войде. Одна библиотека не ставится отдельно."Наши руки кривоваты - в этом хрусты виноваты!"
Ага прямые руки это палки. Если мозги корявые, то такое понятие как "прямые руки" относятся к прямым мозгам. Руки чтоб ты знал имеют утолщения, расширения, пальцы и т.д и т.п. Но ты можешь поискать прямой нерв или там вену хотя бы.
> Ага прямые руки это палки. Если мозги корявые, то такое понятие как "прямые руки" относятся к прямым мозгам.---
Фразеологизм
фразеологическая единица, идиома, устойчивое сочетание слов, которое характеризуется постоянным лексическим составом, грамматическим строением и известным носителям данного языка значением (в большинстве случаев – переносно-образным), не выводимым из значения составляющих Ф. компонентов. Это значение воспроизводится в речи в соответствии с исторически сложившимися нормами употребления.
---
(с) Большая советская энциклопедия
http://www.google.com/search?q="кривые%20руки"
В общем, незачетная попытка спрыга с темы.>> ошибочка вышла. Ржавой весит 485 мегабайт в войде. Одна библиотека не ставится отдельно.
> Руки чтоб ты знал имеют утолщения, расширения, пальцы и т.д и т.п.А еще могут расти из жопы - но виноваты, конечно, другие.
Я в курсе, что какие-нибудь азиаты могут узаконить ошибки. Но фактическое положение дел и желание перевести все на жопы или невменяемые фразы про какие-то хрусты виноватые в кривых руках - это неадекватное поведение. Вас надо в поликлинику сдать для опытов.
>> тянуть rust-std весом в 117 мегабайт
>> Ржавой весит 485 мегабайт в войде. Одна библиотека не ставится отдельно.
> Я в курсе, что какие-нибудь азиаты могут узаконить ошибки. Но фактическое положение дел и желание перевести все на жопы или невменяемые фразы про какие-то хрусты виноватые в кривых руках - это неадекватное поведение.Фактическое положение дел:
$ du -Ah usr/lib/x86_64-linux-gnu/libstd-6bf3f16f340782ca.so
4,5M usr/lib/x86_64-linux-gnu/libstd-6bf3f16f340782ca.so
А твои претензии - претензии обыкновенного опеннетного ламерья, неотличающего реальные зависимости от кривой разбивки софта на пакеты.> Вас надо в поликлинику сдать для опытов.
Опеннетное ламерье опять с умным видом пишет очередную *рень :)
«The voluntary consent of the human subject is absolutely essential.» (Nuremberg Code)
«Никто не может быть без добровольного согласия подвергнут медицинским, научным или иным опытам» (Часть 2 статьи 21 Конституции РФ)
Распакованный 600 весит
Ну 485 мегабайт это версия с системной библиотекой musl. Так то glibc делает более жирные файлы. Потому в итоге может быть и 600 мегабайт.
>так как по статистике большинство ошибок всплывает в новом или недавно изменённом коде. В частности, около 50% выявляемых ошибок работы с памятью в Android выявляются в коде, написанном менее года назад.последствия внедрения diversity?
Bug Lives Matter
> около 50% выявляемых ошибок работы с памятью в Android выявляются в коде, написанном менее года назадОтлично наговнокодили индусы! Андройдом-12 пользоваться будет невозможно.
Большие корпорации очень ценят свое время. Если они используют Rust, то от Rust-a есть польза(может быть очень большая).
ХааааааааааааааааааааааааааИменно поэтому rust в больших не будет. Потому что ценят время. Разработка аналогичного кода на rust занимает куда больше времени чем на C/C++ а его сопровождение учитывая постоянные изменения в языке превратиться в ад.
Ок, умник, а Amazon насколько большая компания?
Или Dropbox?
Или Cloudflare?Или не считается?
Ты ещё мозилу вспомни.
У дропбокса нет кода на Раст в проде у них только Го.
У них как минимум часть клиента (которая отвечает за синхронизацию) и самые низкоуровневые части бекенда на расте.
Это из разряда «большие компании не могут ошибаться» ?)Только вот.. у того же гугла куча фактически выброшенных пректов( с открытыми исходниками и практически отсутствующей поддержкой )
В любом случае, добавление раста ещё больше усложнит сборку и структуру зависимостей.
Хотя, даже забавно - у гугла и го и дарт имеются, но в проект тащат что-то другое.. ещё и постоянно меняющееся
Я отвечал на "Именно поэтому rust в больших не будет.", т.к. на практике уже давно есть и в критичных частях.
C++ не меняется, что ли?
И по поводу времени разработки. Вон, количество строк в два раза меньше стало в движке после переписывания с C++ на Rust.
> C++ не меняется, что ли?Код 20 летней давности современный компилятор плюсов спокойно переварит, чего не скажешь про раст.
> Код 20 летней давности современный компилятор плюсов спокойно переварит, чего не скажешь про раст.Ну да, ведь кода 20 летней давности на расте нет ...
Откуда такая статистика? Выглядит как глупость из воздуха.
Разработка включает в себя отладку ;)
Какие постоянные изменения? Что ты несешь? Путаешь stable с nightly небось. С версии 1.0 он обратно совместим.
Не хочу тебя расстраивать но (в том числе большие) корпорации совершенно не ценят ни своего (руководителей) времени, ни своих сотрудников. Ценят только деньги и для некоторых менеджеров внедрение раст как серебрянной пули означает укрепление позиций для себя (плевать сколько уйдет времени разработчиков и опсов) и непризрачные премии.
Пилить заранее убыточный проект? Раз плюнуть, закроем, не впервой (С) ГуглКто ценят свое время так это некоторые стартапы - там время действительно ценный ресурс от которого зависит дальнейшее существовании компании.
А если подумать, то станет ясно, что время - деньги. Но это если подумать.
Нет, время помноженное на ценность сотрудников - деньги. А спешка пока конкуренты не написали аналог уже бесполезна, в мире уже нет уникального ПО, выбор делается исключительно благодаря успехам маркетинга.
Смартафоны — это инструменты Большого Брата. Это мечта Сталина. Не дожил. Жаль.
Забавно, но ты подтвердил тот же самый тезис, о котором говорил я. Время - деньги. А уж на что его умножать - дело каждого конкретного случая.
Хах, теперь надо будет кроме конкретной версии ndk тащить еще и кокретную версию хруста.Интересно, как менеджерам удалось протащить это решение мимо разработчиков?
> Интересно, как менеджерам удалось протащить это решение мимо разработчиков?А кому хочется оказаться на месте Столлмана. Его ведь не столько ради ухода травят, сколько в назидание непослушным.
Почему мимо-то? Сами разработчики наверняка и инициировали
Вот то, что морозится версия - это хреново, конечно. Но типа штабильность.
Какой бред. Давайте ещё допускать ТОЛЬКО нетрадициалов. Это куда безопаснее.
>Давайте ещё допускать ТОЛЬКО нетрадициалов.Перебьёшся - дома сиди.
При чём здесь память/владение вообще?Растом может называться только конкретный компилятор, выпущенный конкретной организацией, вокруг которого построена подконтрольная этой организации инфраструктура. Комплекс сделан с заложенной by design возможностью инжекции кода потребителям этой инфраструктуры. А через них и конечным потребителям. Память, безопасное владение, понимашь ли... Дым над водой, маскировочная завеса.
Память и владение оказывают влияние на время разработки и последующего сопровождения. Вроде, простая мысль.
А вот причём здесь инжекция кода, остаётся только догадываться. Кто мешает тому же Гуглу делать что угодно с их ОС?
> Память и владение оказывают влияние на время разработки и последующего сопровождения. Вроде, простая мысль.Конечно оказывают. Причём в основном через понижение квалификации разработчиков, и, как следствие, деградация уровня архитектурных решений (код там глубоко вторичен). Зато для бизнеса выгодно --- зарплата ниже, заменяемость выше.
> Кто мешает тому же Гуглу делать что угодно с их ОС?
Эту операционку собирает кто угодно. А на отгруженных устройствах она практически не меняется никогда.
А вот cargo, это уже готовая инфраструктура доставки/влияния. Сравните с соответствующей экосистемой вокруг npm/node.js и сопутствующими еле заметными "скандальчиками". Заметьте, что проблемы, которые привели к "скандальчикам", неустранимы принципиально --- они неотемлемая часть этих технологий.
> Причём в основном через понижение квалификации разработчиков, и, как следствие, деградация уровня архитектурных решений (код там глубоко вторичен). Зато для бизнеса выгодно --- зарплата ниже, заменяемость выше.ИМХО, квалификация разработчиков здесь вообще ни при чём. На критические задачи никто не будет брать низкоквалифицированных разработчиков, следовательно, зарплата таких спецов как была высокой, так ею и останется. А для всякого г-нокода и индусов хватает, нет смысла платить десятки тыщ за какой-нибудь Hello World. Это во-первых. Бизнесу же выгодно, чтобы задача делалась не только качественно, но и быстро. Если язык А предоставляет преимущества по этому параметру по сравнению с языком Б, то почему бы и не одобрить для разработки язык А?
> Эту операционку собирает кто угодно. А на отгруженных устройствах она практически не меняется никогда.
Собирает, кто угодно. Но кто делает исходный код? Тоже кто угодно? Я вот сильно сомневаюсь.
А в cargo никто не заставляет тащить всякую фигню. Или заставляет?
До сих пор не понимаю что мешает писать на плюсах используя std::shared_ptr для всей памяти.
> что мешает писать на плюсах используя std::shared_ptrЕсли напишешь std::shared_ptr, то...
- у тебя не будет 10 директоров, 5 из которых от корпораций добра;
- ты потратишь слишком мало времени на разработку, а это несолидно;
- простой код слишком понятен другим;
- в твоём коде недостаточно "!!!";
- std не скачивается из файлопомойки, что делает невозможным инжекцию;
- твоя программа будет работать.
>> что мешает писать на плюсах используя std::shared_ptr
> Если напишешь std::shared_ptr, то...
> - Онанимные Экспертусы опеннета скромно умолчат о рантайм счетчике ссылок
> взамен написав кучу бредаОх уж эти скромные Экспертусы опеннета.
Тебя же не удивляет, что растаманы в рантайме ручками проверяют, не вышел ли индекс за массив? При этом умудряются перепутать операторы сравнения и уронить прогу :)
Рустики это же вчерашние джаскриптизеры.
В расте на каждый чих по функции и типов там точно больше float32
Ну да, в хрусте их нету же, завс лично спускается очищать память.
> Ну да, в хрусте их нету же, завс лично спускается очищать память.Сразу виден Настоящий Опеннетный Экспертус.
Т.е ты утверждаешь что памятью рулит именно волшебство, а не gc ? Рак оно уже научилось лечить ?
> Т.е ты утверждаешь что памятью рулит именно волшебство, а не gc ?
> Рак оно уже научилось лечить ?
> ты утверждаешь ... а не gcТебе еще не надоело балаболить?
Все очень просто, друг. Как хлебушек.На С/С++ писать надо уметь. Подними не такую уж давнюю новость про С-contest. Ну...да. Наши растоумейки и там отметились громким "НИИИНУЖНА!!", похлопали крылышками и улетели хвалить друг-друга и требовать пруфы и пруфы на пруфы с любого, кто хоть как-то внятно критикует язык. Но дело не в этом.
Кодер на С, настоящий кодер на С - стоит денег. Больших денег. Даже на уровне джуна он знает о внутренностях машины больше, чем крутейший, не-на-каждой-хромой-козе сеньор-джсник. Это БигБизу крайне невыгодно и сейчас они стараются избавится от Сшников. Доходит до абсурда, когда выгодгнее платить прямому мошеннику-манагеру, чем реализовать обещания из буклетика.
Кодер на С++ - также стоит хороших денег. Индустрия уже научена опытом, когда на место плюсовиков сажают индусских макак и получают...хм, получают вообщем. И большой техдолг в этой ситуации едва ли не самая предпочтительная ситуация - даже гугл на хоникомбе-тройке с этим обжегся. Да, и плюс плюсовики (каламбур, лул) не страдают от излишней скромности, оценивая себя адекватно. А высокое IQ - не позволяет рассказать им красивую сказочку про *спасение мира от угнетения серобуромалинового меньшинства*. Это бигБизу тоже невыгодно - иметь работника, который не боится за своё место, не стыдится своего труда и может самостоятельно вырасти в конкурента, которого только громкими процессами и задушишь, но победя будет пиррова для имиджа.
А теперь посмотри, какой порог вхождения у раста, у жс, у го...порог минимален. Т.е. можно посадить желторотого студента на ставку менеджера макдака, требуя с него две продуктивности нормальных программистов, забивая на скорость и на сам код. Быстрее, больше, дешевле. Кто раньше вывел сервис - тот и победил. Кто красивее нарисовал инфографику - тот победил. Пользователи уже не клиенты, пользователи уже капитал. А студентик из технического спеца, кем были сишник или плюсовик, превращается в обычный офисный планктон. Которого и заменить легко таким же, и сказочку красивую, о повесточке, рассказать (про то, как бедные негрята недоедают...поэтому даешь пятилетку за год!) можно, и он ей поверит.
Писать можно. Отличная абстракция, эти умные указатели. Только дело уже не в языке, а в том, кто пишет. У раста нет никаких ломающих преимуществ перед плюсами, кроме компилятора (который писать должны сишники, иначе...) и низкого порога входа. Зато столько фанатиков...
> какой порог вхождения у раста... можно посадить желторотого студента на ставку менеджера макдака... забивая на скорость и на сам кодНеудивительно, что у ресдоха траблы на реальном железе и течёт память, FF падает, а эти желторотые маккаки не знают, чем отличается меньше от больше. Посмотрите на пыхпых - самые низкооплачиваемые позиции.
Что вы все заладили "FF падает", где вы это взяли? Куда падает, зачем падает? Использую FF уже который год, ни разу ещё не упала. Процитирую классика - ЧЯДНТ?
> ЧЯДНТ?пишешь тут непотребные сообщения.
Низкий порог входа у JavaScript? У Rust?Ты совсем ебобо? C++ проще Rust, и проще JavaScript. Говорю как C++ программист, бывший.
Сложность C++ в его тотальной говнятине, ужасном дизайне и тотальном уродстве и непродуманности и сплошном undefined behaviour. Хуже только Bash.
Для C++ программиста достаточно знать C++. Для JavaScript - гораздо больше. Это CSS, HTML, Web API, WebGPU, WebGL / 3D графика / Canvas API, SVG, Responsive Design, WASM и ещё кучу всего.
А ещё нужна математика, не очень сложная. Но поболее того что знает большинство C++ программистов.
О, да! Эти всем известные JS-математики!
Да, без знаний линейной алгебры —
снежынки на экране вообще двигаться не будут.Один я здесь средь вас весь в белом, стою кросивый.
По поводу сложности C++ согласен.А вот то, что программисту на C++ надо знать только язык - это очевидная глупость. В современном мире только на знании языка далеко не уедешь. Надо ещё владеть какой-нибудь инфраструктурой средой. А часто и не одной.
> Для C++ программиста достаточно знать C++. Для JavaScript - гораздо больше. Это CSS, HTML, Web API, WebGPU, WebGL / 3D графика / Canvas API, SVG, Responsive Design, WASM и ещё кучу всего.Зачем сравнивать язык и апи?
Любой язык программирования - это инструмент, и ничего больше. Любым языком, следовательно, надо уметь пользоваться. И, при желании, можно накосячить на любом языке. Читал историю, как программист на F# за полгода в одно лицо переписал кривое ПО на C++ на крупной бирже, которое писалось годами коллективом в два десятка человек.Кодер - это самый дешёвый тип труда, вообще-то. Хоть на C, хоть на чем ещё.
И что с того, что кодер на C знает лучше внутренности машины? А кодер на каком-нибудь Scala лучше знает банковские бизнес-процессы. И получать может куда больше кодера на C, по крайней мере в банке крупном.
Кстати, о зарплатах. Программист на C++ - это далеко не самая высокооплачиваемая должность, если говорить о средних мировых зарплатах. Ты бы хоть исследование вначале какое провел, прежде чем глупости ляпать.
Я вот прогаю на асме, UB для меня уже проявляется на OOO микроархитектуры, это не исключая того, что гонки есть и будут, даже на серилизации RR, даже на конвейере.>И что с того, что кодер на C знает лучше внутренности машины?
А то, что скорость настолько важна в банках, бизнесах, биржах, что остается ее выжимать только на уровне машины. На С и C++ это сделать НАМНОГО проще, не говоря о том, что это можно сделать физически. И если на перепроводку оптоволокна и маршрутизации за 10 лет NY биржа за микросекунды втаскивает 30% бюджета, то за драгоценные наносекунды инвалидации строки в кеше убить готова, потому что это недополученная прибыль.
> Я вот прогаю на асме, UB для меня уже проявляется на OOO микроархитектуры, это не исключая того, что гонки есть и будут, даже на серилизации RR, даже на конвейере.В наши дни прогать на АСМе можно или по причине сильной необходимости - какое-нить очень слабое железо или очень жёсткие требования к производительности фрагмента кода. Или по причине упоротости. Потому что современный компилятор в общем случае даст фору любому программисту по части оптимизации сложного кода. Я уж молчу про время разработки.
Если же говорить про веб-приложения, к примеру, то там от АСМа толка, как от козла молока. Потому что основные потери в производительности не за счёт железа, а за счёт всяких сетевых задержек, потерь сетевых пакетов и тому подобных вещей. АСМ в этом случае не даст практически ничего, а вот время на разработку увеличится на порядки (в десятки, сотни раз).> А то, что скорость настолько важна в банках, бизнесах, биржах, что остается ее выжимать только на уровне машины. На С и C++ это сделать НАМНОГО проще, не говоря о том, что это можно сделать физически.
Ерунда, по поводу намного проще. Потому что C++ очень непростой язык и нюансов там овердофига. Ещё раз напомню, один человек за полгода для крупной биржи на F# оптимизировал софт, написанный двумя десятками человек на C++ в течение нескольких лет.
На всякий случай сообщу, что правильно подобранное железо неплохо масштабируется. Поэтому зачастую гораздо дешевле купить более мощное железо, чем платить программисту за оптимизации, которые могут длиться не один год и стоить не один десяток тысяч долларов.
"на F# за полгода в одно лицо" - вот оно, современное лицо г***внокодеров! :) Не находишь здесь ключевой проблемы?
НАПИСАТЬ код - вообще не проблема, а кто его потом будет сопровождать?! Опять то самое "одно лицо", которое его и сможет понять? (если за полгода не забудет)
F# - вообще не то, на чём надо писать долгоживущие проекты. Просто представить как концепт - да, но сопровождать это functional-ушлёпище - лучше сразу закопайте!
Софт писался для КРУПНОЙ, ОЧЕНЬ КРУПНОЙ биржи. Поэтому ни о каком г-нокодерстве речь не идёт от слова совсем. Ключевая же проблема здесь в том, что предыдущее поколение программистов на C++ не справилось с задачей. А этот человек справился, потому что, во-первых, он человек очень высокой квалификации, а во-вторых - выбрал более подходящий инструмент для решения задачи.> F# - вообще не то, на чём надо писать долгоживущие проекты. Просто представить как концепт - да, но сопровождать это functional-ушлёпище - лучше сразу закопайте!
Хозяева биржи, насколько мне известно, остались довольны результатом работы - время реакции ПО сократилось в несколько раз. Поэтому ты им можешь рассказать о своих теоретических выкладках, как они лоханулись. Мне - не надо.
> А теперь посмотри, какой порог вхождения у раста, у жс, у го...порог минимален.Вы ужд определитесь: А то там вон выше по комментам твои "коллеги по разуму" (все сплошь суперпрофи в С и С++) писали, что синтаксис раста не осилили. Больно уж сложно для них оказалось. А тут такой ты раз и говоришь, что у раста низкий порог вхождения.
Хто-та врот.
Потому что "shared_ptr везде" медленнее, чем сборка мусора. Тебе придётся отказаться от выделений на стеке, выделять всё в куче, и при каждом копировании указателя разадресовывать его, чтобы изменить значение ref_count. В конкурентном окружении, тебе этот ref_count придётся ещё атомарно менять, а не абы как. Сборка мусора будет быстрее, истинно тебе говорю.
> Тебе придётся отказаться от выделений на стеке, выделять всё в куче, и при каждом копировании указателя разадресовывать его, чтобы изменить значение ref_count.
> Сборка мусора будет быстрее, истинно тебе говорю.Ну хз, я пока программизмом позанимаюсь. Мусор подождет.
Потому что в Расте безопасность - далеко не главная фишка. Я воспринимаю её скорее как просто бонус. Весомый, но бонус.
А вот от нормальной асинхронности, (де)сериализации структур без костылей, карго, трейтов и прочего я балдею после плюсов, которые (даже самые современные) похожи на привет из 90-ых (без обид, сам c++ dev).
Теперь андроид будет падать из-за нехватки утёкшей памяти :)
Пора переходить на Фуксию.
В Фуксии тоже пишут на Раст.
Это неважно, главное, чтобы бачок со смузи не потик.
Новые модули будут писаться на Расте, а не С, так что не утечет :)
растаманы как там хеловорд безпасненька принтится?
Да ладно вам, злопыхатели, зато теперь раст точно не устонет.
о, да... в руках гугла рипнулась не одна сотня проектов.
они это и не скрывают, там в совете одни пи.
Всё проржавело! Ужосы. Но я буду до последнего беречь мои сверкающие сишки!
Просто понимаеш, это единственная возможность нанять белых американцов, пусть и нетрадиционных, вот да.«Job Security through Code Obscurity» ©
Кругом одни брахманы...
Пiчальна, чо.
> Rust даёт возможность добиться производительности близкой к языкам C и С++Поправка: неотличимой от Си и местами быстрее, чем C++.
Да ладно! раст! быстрее даже! ассемблера! И значительно! опережает команды процессора!
Только не смейтесь - компыль раста искривляет само пространство и время и выдает код, который написан раньше, чем придуман, а инструкции выполняются быстрее, чем они загрузятся по шине в проц! Это не шутка! 640 гигабайт оперативы хватит всем! А еще раст лечит язву, простатит, геморрой, геморрой у язвы, вредный характер мамы язвы, открывает третий глаз, растопыривает чакры, выпрямляет прану, побеждает рептилоидов, изгоняет крыс, мышей, лягушек, блох, клопов и вшей!
Вот теперь реально захотелось его попробовать..
Чтобы избавиться от простуд раз и навсегда достаточно каждый вечер писать следующую программу на расте...
- Мой гитхаб увеличивается на 5 сантиметров в день, если каждый день писать этот КОД на расте...
- Вот на чем кодил Ленин! Шок!
- Торвальдс раскрыл тайну новых обвязок для написания драйверов...
- Раскачал бицуху компилируя этот растовый код...
- Секретные фото Линуса Торвальдса, кодящего на расте, смотреть здесь >>
- Нацисты проиграли только потому, что Сталин коммитил в карго. Шок
вы принятыС увожением Яндекс Дзен
> Да ладно! раст! быстрее даже! ассемблера! И значительно! опережает команды процессора!Если бы ты хоть немного знал об оптимизации, то перестал бы ёрничать. В некоторых сложных случаях оптимизирующий компилятор хоть с C, хоть с Rust, может быть быстрее ассемблера.
Что то не может быть быстрее ассемблера, так как всегда можно взять код компилятора и выдать за ассемблер. А если компилятор увидел не все возможности для оптимизации, то можно сделать код производительнее. Так, что код генерируемый компилятором всегда равен или хуже ассемблера. Но в мире где код меняется по 100 раз на дню, лучший код не нужен.
Прохожий здесь по большому счёту прав. Убогие человечишки проигрывают современным оптимизирующим компиляторам в решении задачи оптимизации. Учесть happens-before (возможность паралелизации выполнения инструкций), оптимальность загрузки конвейра при наличии ограничений, учёт спекулятивного выполнения --- ну не может человечишко это в башке удерживать.Ассемблер остаётся там, где об оптимизации и скорости вообще речи нет --- "нам бы PLL вот здесь включить".
Да ладно! Почему тогда, например, ржавый av1 кодек на 2/3 на асме и только на треть на ржавчине?
Дак что мешает при использовании ассемблера написать код с учетом всех фич проца?
Мозгов не хватит. :) Это как "зачем так долго проводить суды, когда и так весь закон записан в книгах?". Записан - да, попробуй вспомни и примени!
И потом, современные CPU уже достаточно быстрые, чтобы не корячиться с АСМом. АСМ можно применить где-то на совсем низком уровне - в небольших функциях, где ты понимаешь все потенциальные бенефиты CPU и можешь руками сделать 3-страничный код. Математические библиотеки - самое оно!
> В некоторых сложных случаях оптимизирующий компилятор хоть с C, хоть с Rust, может быть быстрее ассемблера.Не совсем. Компиляторы ограничены в том, что они могут сделать, человек не имеет этих ограничений. Вплоть до того, что если поиск самого быстрого машинного кода, решающего данную задачу, окажется слишком сложным для ущербных человеческих мозгов, человек может создать специализированную программу, которая будет заниматься таким поиском. И с этой точки зрения, человек в любой конкретной ситуации может получить результат, как минимум, не хуже компилятора.
Люди предпочитают компиляторы, потому что писать код, дооптимизированный до уровня примеров программ в кнутовском TAOCP, очень долго. И время доведения кода до такого уровня оптимизированности растёт нелинейно с ростом размера программы. Написать в таком стиле electron людям не удалось бы, даже если бы они взяли все человекочасы всех живших или живущих людей, которые те потратили на чтобы то ни было, и все эти человекочасы вбухали бы в разработку максимально эффективного электрона. Всё равно их не хватило бы.
Если ты откроешь Брукса и почитаешь его "Мифический человекомесяц", ты увидишь пример тому, как программисты IBM когда-то впоролись в эту проблему, в процессе написания OS/360. Очень жёппно. Чтобы не впарываться так, программисты начинают упрощать себе жизнь, вводя всякие ABI, например. Но ведь как только ты выбрал какую-то конвенцию вызова, так сразу ты отказал себе в возможности микрооптимизировать код, подбирая конвенцию вызова, на основании того, как функция работает с аргументами, и того как эта функция чаще всего вызывается. Или не отказал, но усложнил -- легко потом забыть провести такую микрооптимизацию. А потом ты изменишь программу, и микрооптимизацию придётся проводить снова, меняя конвенцию вызова той или иной функции раз в месяц. Или ещё пример: современные API предполагают, что функция имеет ровно одну точку входа, что она блин _функция_. Но зачем? Можно же делать несколько точек входа. Или, допустим, разделение чисел на знаковые и беззнаковые -- процессору пофигу, какие там числа, какие операции будешь использовать, так он с ними и будет работать. Но людям было удобно, они создали абстракцию, которая потенциально может сделать код медленнее. Дейкстра пришёл и зачмырил goto, но goto позволяет создавать более быстрые программы, чем все эти ваши for/while/if. Отказ от goto сделал программы проще для человека, но ограничил их в возможности писать быстрые программы.
Всё это пытаются нивелировать оптимизирующими компиляторами, и в целом небезуспешно. То есть компилятор вполне может создать функцию с несколькими точками входа, если он достаточно прошарен в теме, хотя ты и не можешь сказать ему сделать именно это. В результате, как правило, довольно сложно написать код, который будет быстрее того, что сгенерировано компилятором. Но не факт, что невозможно. Я бы даже исходил из обратного постулата: любой компилятор можно обогнать.
По-хорошему, есть выбор: писать говнокод, который невозможно ни читать, ни, тем более, мейнтейнить, либо писать хорошо и красиво, но полагаться в оптимизациях на компилятор. Но тут мы подходим к тонкой грани между теоретической возможностью написать быстрее компилятора, практической возможностью, и к cost-benefit анализу. А это слишком сложная тема для уровня опеннета, в ней ты сольёшь без шансов, потому что, когда опеннетовец будет говорить о возможности, он будет говорить о теоретической возможности, а когда он будет говорить о невозможности, он будет говорить о практической невозможности, переключаясь с одного определения на другое так, как ему будет удобно для выстраивания его софизмов. И поделать с этим ты ничего не сможешь. Так что мой тебе совет: даже и не пытайся.
Прекрасный комментарий, браво
Вообще-то нет. Автор спорит сам с собою в разных абзацах. Под конец переходит на личности, пытаясь указать оппоненту на его место. Это всё признаки очень плохого комментария.
Оу, я не заметил сразу твоего этого коммента, но это же _шедевр_!!!> спорит сам с собою
> переходит на личности, пытаясь указать оппоненту на его место
Где уж мне за тобой угнаться в "шедевральности" логических размышлений.
> Где уж мне за тобой угнаться в "шедевральности" логических размышлений.Ой, ну давай только вот без этой лишней скромности. Тебе реально удалось встроить очень шизофреничный образ. Мне понравилось.
> Не совсем. Компиляторы ограничены в том, что они могут сделать, человек не имеет этих ограничений.Смотря какой человек и смотря за какой промежуток времени.
> человек может создать специализированную программу, которая будет заниматься таким поиском
Ты только что изобрёл велосипед. Пардон, оптимизирующий компилятор. ;)
> в ней ты сольёшь без шансов
Думаю, что ты уже слился в ней. Просто пока не осознал этого. Попробую объяснить.
> Так что мой тебе совет: даже и не пытайся.
Я всё-таки попытаюсь. Ты ведь такой же опеннетовец, как и я, да?
Буду исходить вот из чего. Люди, довольно умные люди, надо заметить, и не один человек, а большая группа людей, выбрали путь оптимизирующего компилятора практически во всех сферах, кроме относительно небольшого числа пока ещё не освоенных ниш (или эти ниши нет нужды осваивать в виду их узкости). И такой выбор они сделали не потому, что ненавидели язык А, отдавая предпочтение языку Б, а потому что это более эффективный путь развития индустрии. Эффективность в данном случае выражается в деньгах.
Как я понял, что выбран именно такой путь? Очень просто. Достаточно взглянуть на популярность тех или иных языков программирования - это всё практика, никакая не теория.> По-хорошему, есть выбор: писать говнокод, который невозможно ни читать, ни, тем более, мейнтейнить, либо писать хорошо и красиво, но полагаться в оптимизациях на компилятор.
По-хорошему такого выбора в подавляющем большинстве случаев нет, если всё-таки мыслить рационально. Там, где есть оптимизирующий компилятор, пользуются им. Это дешевле, чем писать хрен пойми что, хрен пойми сколько времени, которое будет работать только на вот этом железе.
> А это слишком сложная тема для уровня опеннета
Ничего сложно, на самом деле нет. Человечество экспериментальным путём уже сделало свой выбор.
>> А это слишком сложная тема для уровня опеннета
> Ничего сложно, на самом деле нетУуу, я смотрю для тебя это тоже слишком сложная мысль. Слишком много за раз?
Я же по-русски написал. Ничего сложного в этой теме нет. Надо по-английски продублировать?
> Я же по-русски написал. Ничего сложного в этой теме нет. Надо по-английски
> продублировать?Что ты хочешь продублировать? Ещё раз уподобиться заурядному опеннетовцу, показав как ты не можешь отличать "практическую возможность" от "теоретической возможности"? Ну продублируй, я посмотрю.
А ведь создатели языка намекнули конкретно в названии. Но не все понимают ;)
=)Да. Второй Great Oxidation Event происходит прямо сейчас, но люди не верят своим глазам. Кстати, на русский язык этот ивент переводят гораздо более триггерящим "кислородная катастрофа". Обидно, что это ещё на один ассоциативный шаг дальше от ржавчины.
> создатели языка намекнули конкретно в названии ...Чтобы понять "тонкий" намёк создателей языка (Fe)2(O)3, надо дополнительно "осилить" промышленную химию и, в частности, антикоррозионную защиту силовых конструкций.
Преподавание последнего, похоже, уже исключено: продлевает срок службы, повышает надёжность.
Ибо, если ржавчина уже образовалась - остановить процесс коррозии очень трудно и крайне редко удается. Коррозию можно эффективно только предупреждать, заранее защищая металл.
Коррозию следует предупреждать, заранее защищая металл от ржавчины.
> заранее защищая металл от ржавчины.Вот-вот, надо защищать мир от раста. А знаешь, чем? Сиплюсплюсом! Лучшая антикоррозийная защита!
Анон! А у тебя свободный телефон?!
Эхх... А могли бы Аду использовать...
У Ады фатальный недостаток: "сделано не ими".
Наконец-то это дырявое ведро потихоньку начнёт превращаться в нормальную операционную систему. Такими темпами лет через пять им можно даже пользоваться, а может, даже раньше. Ну серьёзно, это не операционка, а какой-то тяжёлый и тормозной гипервизор, в котором каждая приложение - отдельная оерационка.
> тяжёлый и тормозной гипервизор, в котором каждая приложение - отдельная оерационка.А всё именно так и останется. Ты вообще понял хоть, про что новость?!
Опять 25 :(В очередной раз : Почему С++ считается не безопасным а Rust безопасным.
И там есть unsafe и там и там его можно использовать или нет.
С++ные безопасные обертки не являются частью языка, а лишь дополнительный набор библиотек, поэтому они проигрывают в производительности нативным растовским оберткам.
смачная у тебя трава... Безопасность С++ - в менежмент-типах, и это нативная фича, по другому и быть не может. Ничего нового растаманы не придумали, а всего лишь взяли подмножество фич С++.
А можно подробнее? Про какие библиотеки речь?
Он хочет сказать, что шаблоны и менежмент-типы реализованы какими-то сторонними библиотеками :) И выполняются в рантайме...
> Почему...Потому что надо посмотреть на компиляторы... ЧТО пропихивает раст, а что при этом отвалится. Какая лицензия у раста-компилятора. КТО может его изменять. И т.д., и т.п. Помните историю с системдой? "Мне только хвостик погреть...".
Потому что unsafe-операции в Rust четко отделены в специальные блоки. Сразу видно, куда нужно обратить внимание на ревью и тестировании.
И даже unsafe не отключает все проверки
Вот у луддитов подгорает...
Моно не нуно?
Радует развитие Раста.
После C/C++ словно лучик света.
Потихоньку перехожу на Раст (с преимущественно C++) и другим советую :)
Ну если ты не осилил c/c++ то на расте так ничего и не напишешь.А вот когда освоил c/c++ то после этого раст уже не нужен и выглядит убого, скудно и недоразвито.
Ты сколько времени кодил на Расте?
О C вообще не говорю, он минимальный, а C++ после Раста похож на старую клячу.
Раст выглядит лучше, продуманнее, современнее и перспективнее.
Читал статью от хорошего успешного программиста, который программировал на С++ много лет (около двух десятков). Так вот он написал, что очень и очень устал от C++. Виной тому и новые стандарты, которые надо каким-то образом сочетать с унаследованным кодом, и неоднозначность поведения разных компиляторов, которое, если пытаешься писать кросс-платформенные приложения, надо постоянно держать в уме. И даже отсутствие полной поддержки стандартов (где-то сайт встречался о том, какие компиляторы поддерживают какие стандарты C++ и в каком объёме). История заканчивается тем, что программист в итоге перешёл на Хаскель, и теперь не нарадуется его однозначности и чистоте.
Тоже читал эту статью, полностью согласен с каждым словом.
как это сочетается с растом, который только под арм и х86 фактически? Все прибито гвоздями, одна реализация.
Речь была не про Rust, а про C++. Я отвечал на пост, который выше, если до сих пор непонятно.
Я одного не понял, с какого перепоя РУСТ вдруг стал синонимом безопасности?!! То, что в Русте вокруг памяти наворотили костылей и заставляют на них танцевать (серьёзно мешая нормальной разработке), ещё не означает, что Руст внезапно стал полезен!Мне Руст напоминает вождение авто с мануалкой. Только помимо самого гемороя с переключением, есть разные ручки для "повышения" и "понижения" скорости и ты их выкручиваешь и вкручиваешь нужную.
ОНО МНЕ НАДО??Руст (будь он нормальным языком) ДАВНО бы занял свою нишу! Нет необходимости толкать в задницу язык, если он и так "решил бы все проблемы с памятью". Но никто это г****но не использует! Отдельные извращенцы лишь подчёркивают исключительность таких случаев.
> ДАВНО бы занял свою нишуПервый стабильный релиз Rust был в 2015. Приведите хоть один пример _современного, не говномантного_ языка, которому 6 лет и который ДАВНО занял свою нишу?
> стабильный релиз Rust был в 2015Разработка началась в 2006.
https://en.wikipedia.org/wiki/Rust_(programming_language)
...project begun in 2006...
У раста нет ниши, это не нишевый язык - в отличие от всех остальных мейнстримовых языков он - универсальный. Хочешь - пиши под микроконтроллеры, хочешь - под браузеры, хочешь - бекенд, игры, мобилки и тд.
Ну давай покажи примеры из каждой группы, чтобы полностью на ржавчине были.
Зачем полностью-то?
В типичном бэке большинству системные языки нужны для узкого горлышка, не более
Как у Дискорда, к примеруНа Расте большинство пишет новые модули, а не переписывает весь старый код, который вполне мог быть написан до релиза Раста 1.0
Для узкого горлышка есть с/c++
И получим падения и уязвимости на чистом месте
Раст не медленнее
> Ну давай покажи примеры из каждой группы, чтобы полностью на ржавчине были.https://docs.rust-embedded.org/book/intro/index.html
https://rustwasm.github.io/docs/book/
https://github.com/mrDIMAS/StationIapetus
https://actix.rs/ (+ куча других либов типа diesel и тд)
https://mozilla.github.io/firefox-browser-architecture/exper...
https://mozilla.github.io/firefox-browser-architecture/exper...
в мозиле переписали на раст менее 10% кода, при этом FF стал больше тормозить и жрать памяти...
Тормозить как раз перестал, почти догнал хром, а памяти да больше кушает.
Ну а теперь реальные мейнстримовые проекты.
> Ну давай покажи примеры из каждой группы, чтобы полностью на ржавчине были.А, причём это ещё не всё. На нём ещё и под GPU пишут.
Примеры реальных (а не петроджектов) в студию.
На такие сообщения только один вопрос: сколько месяцев (хотя бы) опыт программирования на Расте?
И желательно сфера применения
r.i.p. Android
???
По пути мозилы пошли.
Близкой - понятие растяжимое, такое же растяжимое, как у современных толерастов понятие о нравственности.
А чё не так с нравстенностью ? Паранжу носишь ?
rip android
как rust по скорости в сравнении с C и golang? киньте плиз сравнений.
знаю C,C++,golang стоит учить rust? для чего лучше подходит он?
> стоит учить rust? для чего лучше подходит он?Для понтов. Для всего остального есть С/С++/bash.
Раст для удобства
Ценишь комфорт, кадет?
Шашечки не нужны - нам ехать надо.
Ну так с Растом дальше можно уехать, а без него вначале заехать в UB, а потом крешнуться :)В Расте тоже бывают внезапные выходы из программы. Но разница в том, что это обычно легальная паника с точным описанием проблемы.
Сколько на моей практике было непонятных вылетов в C++ - боюсь даже вспоминать. Самый сок - когда в дебаг всё отлично, а в релизе падает :)
Именно крешей в Расте я ловил по двум причинам: плохой ffi с C (моя вина) и неправильное использование format! (тоже моя в общем-то).Так что да, хочется именно ехать, а не в столбы врезаться.
> Сколько на моей практике было непонятных вылетов в C++ - боюсь даже вспоминатьub санитайзеры пробовали?
> Именно крешей в Расте я ловил по двум причинам: плохой ffi с C (моя вина) и неправильное использование format! (тоже моя в общем-то)
То есть кривое использование с++ - это не твоя вина?
Видимо, речь шла о том, что в C++ проще отстрелить себе ногу, чем на Rust.
Подходит для того чтобы писать вэб кэш. Допустим тебе нужен кэш на пару гигабайт но быстрее редиса и если ты его напишешь на го то он будет лагать из за сборки мусора каждые 2 минуты. На расте не будет лагать.
Раст подходит для маленьких утилит и маленьких веб сервисов наподобие кэша т.е. для того же что и С++. Как язык для микроконтроллеров вроде не очень и Zig в этом плане получше.
По поводу производительности https://www.techempower.com/benchmarks/ Это бенчмарки разных языков и фреймворков в рамках работы с сетью и БД.
По поводу бенча уточнение:
Дрогон там http 1 (что примитивнее), поэтому быстрее actix, у которого честное http 2
Голанг он обгоняет, ибо без сборки мусора. С Си сравнивать странно, потому что Си намного примитивнее (не равно хуже).
Учить стоит, язык крут своей железной дисциплиной, в нем не вылетит неожиданно exception про который ты забыл. Любая возможная ошибка должна быть обработана. Все пути программы должны быть определены явно (для частых случаев есть сахар, но он тоже вполне явный).Ну и безопасность с памятью как небольшой бонус :)
Естественно с такими требованиями писать программы сложнее, потому что не получится просто отмахнуться от возможных ошибок в будущем. Самый простой способ забить на ошибку требует явно вызвать метод .unwrap(), который при ошибке просто крашит поток, но эти unwrap()-ы по коду видно невооруженным глазом.
И вот как раз за счёт того, что обработка ошибок обязательна, а возможные ошибки видны в сигнатуре функции, программу на Rust проще написать надёжной.
Можно писать вместо unwrap просто ? и обрабатывать один раз ошибку из всей функции
Получаем нормальную проверку без дурных экспшенов и забиваний на абстрактное светлое будущее
Не, unwrap лучше. С unwrap ты получаешь бектрейс, когда что-то пошло не так, и этот бектрейс явно указывает на место, где что-то пошло не так, даже думать не надо, просто берёшь и исправляешь. А ?, во-первых, требует чего-нибудь в стиле AnyHow, чтобы все ошибки автоматом прокидывались бы, и, во-вторых, ты в конечном итоге получаешь бектрейс от того места, где тебе было не лень ошибку обработать, и откуда здесь взялась ошибка ты потом можешь гадать очень долго.В целом, мой опыт подсказывает, что unwrap (или ещё лучше except) самый офигенный способ. А ? и всё остальное, это тогда когда ты уже в целом логику программы выверял до уровня, когда можно рассуждать о логике обработки ошибок, вот тогда можно unwrap'ы заменять на ? или map_err(...)?
https://www.youtube.com/watch?v=E9-scyUdmeI
Почитайте также комментарии к ролику.
речь про этот комментарий?> Антон сильно уже сделал акцент на том что С++ имеет такое же количество UB как и Rust, но как видим как минимум на 3 UB в Rust меньше ...
Ну это не сильно все меняет.
https://habr.com/ru/post/492410/
Лучше бы на Java написали!
у явы фатальный недостаток: сделана не гуглом.
решение на перспективу, конечно
А с какой версии Android он будет поддерживаться официально интересно.
а кто мне объяснит почему не использовать rust для разработки android вместо kotlin, необходимость компилировать приложения в байт-код отпадёт, мы сделаем ненужным art, система станет немного легче (почти также как ios)