Компания Vivo, занимающая около 10% мирового рынка смартфонов (5 место среди производителей смартфонов), представила первый официальный открытый релиз ядра операционной системы BlueOS (Blue River OS). Операционная система BlueOS развивается с 2018 года и уже используется в умных часах серии Vivo Watch. Vivo также работает над применением BlueOS в умных очках, роботах, умных терминалах и потребительских AI-устройствах. Код ядра написан на языке Rust и открыт под лицензией Apache 2.0. На Rust также написаны системные фреймворки BlueOS...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63649
> комбинация из применения умных указателей во время выполнения и проверок на этапе компиляцииЧто из этого не умеет делать с++?
Проверки на этапе компиляции.
Используйте Gentoo Linux с правильными опциями сборки: https://airbus-seclab.github.io/c-compiler-security/gcc_comp...Ржавчина не нужна!
Гентушник как всегда не разобрался в вопросе и вместо ответа по существу решил в который раз попиарить свое болото
Вопрос веры. Зрителям нравится deus ex machina.
Вопрос формальных тестов: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309
Гентушник ткнул носом в доступные флаги по безопасности, для C, C++.Ткну носом ещё в доки по сборке: https://wiki.gentoo.org/wiki/Project:Hardened
Другим дистрибутивам ничего не мешает вместо внедрения вредносной ржавчине использовать флаги безопасности при сборке C, C++ программ.
Для тех кто не разобрался в безопасности вообще повторяю сотый раз: "Одним компилятором безопасности не достичь!!!"
Система должна давать гарантии безопасности при исполнении программы и это достигается аж пятерью критически важными компонентами, а не одним только компилятором:
1. Архітектура и инструкциии процесора для работы с памятью.
2. Ядром операционной системы которое следит за режимами выделения памяти для программ и самого ядра.
3. Компилятором.
4. Линковщиком.
5. Общесистемной библиотекой.
Только кому сдался Gentoo и где доказательства эффектовности?Одним компилятором можно убрать ошибки с памятью, в чем и причина внедрения Rust.
Один компилятор не может дать гарантии безопасности во время исполнения!А CPU + Ядро OS + компилятор с линковщиком + системная библиотека - могут дать гарантии безопасности при работе с памятью: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309
Да, в C, C++ гарантии безопасной работы с памятью есть за счёт стабильности работы программы. Но они таки есть! При переполнении буфера или прочих попытках эксплуатации уязвимостей, если они существуют, ядро OS может:
1. Записать факт эксплуатации дыры в лог, для ее исправления.
2. Записать факт эксплуатации дыры в лог, для ее исправления. И убить процесс.
3. Записать факт эксплуатации дыры в лог, для ее исправления. И убить все процессы пользователя с запретом создания новых (запрет логина).
4. Записать факт эксплуатации дыры в лог, для ее исправления. И вызвать панику ядра с выключением компьютера, для предотвращения чистки логов.
>> Да, в C, C++ гарантии безопасной работы с памятью есть за счёт стабильности работы программыТы смешал теплое и мягкое, программа может работать с памятью не безопасно, но стабильно в обычной ситуации. Но возникни некий пограничный worst case... И даже в этом случает программа может работать стабильно, но к её памяти может получить доступ кто-то ещё…
>> Да, в C, C++ гарантии безопасной работы с памятью есть за счёт стабильности работы программы
> Ты смешал теплое и мягкое, программа может работать с памятью не безопасно, но стабильно в обычной ситуации. Но возникни некий пограничный worst case... И даже в этом случает программа может работать стабильно, но к её памяти может получить доступ кто-то ещё…Ещё 101 раз для тех у кого все давно проржавело.
1. Может ядро OS работать в специальном softmode режиме, при котором факт эксплуатации дыр в памяти логируется, но сами программы не убиваются, что даёт стабильность в ущерб безопасности. Или для конкретной программы могут быть включены флаги файловой системы снимающие защиту памяти при ее исполнении. Это частные случаи которые могут быть предусмотрены ядром OS.
2. В безопасном режиме ядро OS не допускает небезопасной работы с памятью или несанкционированный доступ к памяти процесса. При любой небезопасной работой с памятью процесс будет убит ядром OS. Здесь гарантии безопасности достигаются за счёт нестабильной работы программы.
3. При правильной организации работы с памятью никаких третьих, пограничных вариантов не существует. Процес некорректно работающий с памятью гарантировано будет убит ядром OS!
Критерии корректной работы с памятью в C, C++, для гарантии безопасности: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#312
Да, за счёт компилятора ADA, для подмножества языка ADA - SPARK есть возможность провести математическую верификацию кода на этапе компиляции и одновременно дать гарантии безопасности и стабильности при исполнении программы. Но это не C, не C++ и даже не rust, а SPARK!
С чего ты вообще решил, что понимаешь, как работает компьютер и ОС?
Моё понимание правильной работы компьютера и ядра OS подтверждается не использованием: JIT, BPF, systemd, polkit, wayland, rust, ... и прочей неправильной фигни.
> Моё понимание правильной работы компьютера и ядра OS подтверждается не использованием:
> JIT, BPF, systemd, polkit, wayland, rust, ... и прочей неправильной фигни.Т.е. пещерный человек понимал как работают компьютеры. Ибо все то он точно так же не использовал.
У него тогда не было выбора.Понимание доказывается правильностью выбора.
> Ещё 101 раз для тех у кого все давно проржавело.
> Это частные случаи которые могут быть предусмотрены ядром OS.Где это посмотреть в проде, на массмаркет девайсах?
Или пофиг, пусть их ломают?> При любой небезопасной работой с памятью процесс будет убит ядром OS. Здесь гарантии безопасности достигаются за счёт нестабильной работы программы.
С учетом предыдущего пункта, а можно мне не "два стула", а один нормлаьный без пик и буёв?
> 3. При правильной организации работы с памятью никаких третьих, пограничных вариантов не существует. Процес некорректно работающий с памятью гарантировано будет убит ядром OS!
Повторю пункт 1. А где это можно скачать, в руках покрутить?
> Критерии корректной работы с памятью в C, C++, для гарантии безопасности:
> https://www.opennet.dev/openforum/vsluhforumID3/129886.html#312
> Но это не C, не C++ и даже не rust, а SPARK!Это та самая АДА-Спарк, которая joins the Rust foundation и стала silver member?
adacore .com/press/adacore-joins-rust-foundation-as-silver-member
blog.adacore .com/adacore-joins-the-rust-foundation
Возможно они о чем-то догадываются))
> пофиг, пусть их ломают?
> А где это можно скачать, в руках покрутить?Если честно, то дело печально......
Пару лет назад кто то похерил ftp.kiev.ua и следовательно его mirror на Яндексе. Почему Яндекс похерил миррор ftp.kiev.ua загадка. На нем лежали мои LiveCD/DVD в которых правильная защищенная работа с памятью была реализована.
Последние 10 лет я не встречал публичных GNU/Linux дистров с правильно защищённой памятью. Последним сдался Hardened Gentoo. Но это не значит, что сегодня невозможно собрать защищённую систему самому.
Ко мне в 2008 году в России подошёл "товмайор" и долго убедительно попросил прекратить разработку и распространение защищённых LiveDVD с GNU/Linux...
Тем нимение в организациях защищённую систему устанавливал аж до 2014 года. На своем рабочем месте и домашнем использую...
Здесь вопрос есть о правильной сборке GNU/Linux. Потенциально GNU/Linux может потянуть уровень B3 по оранжевой книге 1983г. Реально дистрибутивы GNU/Linux не тянут и C1 по оранжевой книге 1983г., ибо W^X не соблюдается.
Сегодня советую акцент делать на автоматизированные тесты дистрибутивов при выборе: https://www.linux.org.ru/forum/security/17104486?cid=17717042
Если вам говорят, что paxtest и lynis для тестирования дистрибутивов GNU/Linux не подходят это ЛОЖЬ! У меня GNU/Linux и paxtest с lynis 100% проходят. lynis тестировал стандартными тестами.
> Ко мне в 2008 году в России подошёл "товмайор" и долго убедительно попросил прекратить разработку и распространение защищённых LiveDVD с GNU/Linux...Охохо, "у нас есть такие приборы, что мы вам о них не расскажем..."
Ваше предложение?Все показано:
Результат: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309
Тесты: https://www.linux.org.ru/forum/security/17104486?cid=17717042 просто выбирайте не энтерпрайз дистры, а те что лучше проходят тесты.Законом запрещена разработка и распространение в РФ: https://www.linux.org.ru/forum/security/15283293?cid=15285785
Для себя использовать уже созданное в РФ можно.
Вижу два варианта:
1. Офшор вне юрисдикции стран запрещающих разработку и распространение безопасного ПО.
2. Частный случай это только внедрение внутри организации без разработки и распространения.
> на массмаркет девайсахСписок теоретически поддерживаемых ядром Linux с настройками безопасности процессоров (постранична защита памяти):
* Alpha > Alpha-4 - эталон
* AMD > AMD64 (Athlon 64, Opteron) - эталон
* ARM > ARMv8-A - ??? тесты
* ARM > ARMv8.2 - ??? тесты
* IBM > PowerPC G - будет притормаживать
* IBM > z/Architecture-12 - ??? тесты
* Intel > Itanium (Merced) - ??? тесты
* Intel > Pentium 4 последних версий с инструкцией PAE (Prescott с PAE) - первые версии получались бажные, но в x86_64 уже эталон.
* PA-RISC > PA-RISC-2.0 - эталон
* SPARC > SPARC-8 - эталонЯдра OS в той или иной степени поддерживающие защиту памяти.
> Androi-2.3 - дырява
> FreeBSD-5.3 - дырява
> Linux-2.6.8 - дырява, Fedora, Ubuntu, openSUSE могут не включать защиту вообще, чтобы поддерживать загрузку на всех процессорах. Почему их инсталлер на этапе установки не определяет наличие необходимых инструкций процессора загадка...Linux + PAX (Linux + GrSecurity) (AMD64) = максимум защиты! Эталонная реализация!!!
> macOS-10.5 = ??? надо тесты
> NetBSD-2.0 (alpha, amd64, hppa, i386 (with PAE), powerpc (ibm4xx), sh5, sparc (sun4m, sun4d), sparc64) = максимум защиты! Эталонные реализации!!!
> OpenBSD-3.3 (Alpha, AMD64, HPPA, SPARC) - дырява
> Solaris-2.6 (SPARC) = ??? надо тесты
> Windows XP Service Pack 2; Windows Server 2003 - украденная в Linux + PAX, да ещё и дырявая.
> Да, в C, C++ гарантии безопасной работы с памятью есть за счёт стабильности работы программы.
> При переполнении буфера или прочих попытках эксплуатации уязвимостейПоёт про гарантии безопасности в C и C++ и тут же рассказывает о переполнении буфера. 🤦
Да, сишна дыра, пока ее не исправить никуда не девается. Гарантии безопасности в c, C++ даются не в отсутствии дыр, хоть и этого можно на этапе компиляции сегодня избежать, а в невозможности их эксплуатации при ИСПОЛНЕНИИ программы!Наличие дыры в C, C++ с переполнением буфера в принципе допускается. Гарантии безопасности даются на невозможность эксплуатации такой дыры при работе программы! При попытке эксплуатации программа будет убита ядром OS. В C, C++ гаранти безопасности идут в ущерб стабильной работы.
Надеюсь, вы понимаете разницу между "наличием переполнения буфера и невозможности эксплуатации программы с ним" и отсутствием переполнения буфера?
Программа может быть дырявой и иметь возможность переполнения буфера.Ядро OS не датст проэксплуатировать дыру с переполнением буфера при работе программы убив процесс.
Дырявая программа может нормально работать годами, но если найдут эту дыру и напишут экспорт, то при попытки эксплуатации этой дыры ядро убьет процесс и запишет попытку в лог. По лоту можно увидеть дыру в коде, проскочить, обновить и работать дальше.
Вместо переписывания всего на очередной модный язык люди решили, что лучше использовать правильные процессоры и ядра OS дающие контроль использования памяти при выполнении процесса сразу для ВСЕХ программ, на всех языках и баз уменьшения производительности.
> Ядро OS не датст проэксплуатировать дыру с переполнением буфера при работе программы убив процесс.Вашу программу с дефектным буфером (который может переполняться) нельзя будет эксплуатировать, потому что ОС её прибьёт. Какой смысл в такой программе, которую нельзя эксплуатировать? Программы пишутся для того, чтобы их ОС прибивали, или они, всё-таки, должны выполнять какую-то полезную работу?
> Дырявая программа может нормально работать годами
Может работать, а может и не работать. Как тот кот Шрёдингера.
> Вместо переписывания всего на очередной модный язык люди решили
Всё переписывать никто не будет. И нет, люди решили, что кое-что переписать всё-таки следует. И переписали уже. Гугл, Майкрософт, Клаудфлэр, Дропбокс, Дискорд, Амазон и прочие фирмы-лидеры на рынке разработки ПО.
> и баз уменьшения производительности.
Но с существенным сокращением стабильности эксплуатации ПО. Прекрасное решение (нет).
> Вашу программу с дефектным буфером (который может переполняться) нельзя будет эксплуатировать, потому что ОС её прибьёт.а Вашу, судя по, например, https://doc.rust-lang.org/std/vec/struct.Vec.html#indexing, прибьёт рантайм Rust-а, вызвав панику...
В частности так происходит на таком простом примере из документации:
;-----------------------------------------X8
let v = vec![0, 2, 4, 6];
println!("{}", v[6]); // it will panic!
;-----------------------------------------X8по крайней мере в https://play.rust-lang.org/?version=stable&mode=debug&editio...
В итоге что у Анонима задача аварийно завершилась, что у Вас.
> В итоге что у Анонима задача аварийно завершилась, что у Вас.Только в расте будет лог в какой строке произошла ошибка.
А у анонима что будет? Что в такой адрес памяти попытались что-то записать?
Удачного дебага)))
>> В итоге что у Анонима задача аварийно завершилась, что у Вас.
> Только в расте будет лог в какой строке произошла ошибка.Реверсеры одобряют полный слив кишок всякой проприетари дебагсимволами наружу :)
А так то - прикольно конечно знать в какой строке ядро ОС в панику ушло, но...
> А у анонима что будет? Что в такой адрес памяти попытались что-то записать?
> Удачного дебага)))Про addr2line этому анону кажется никто не рассказал... :)
Здесь речь идёт о теоретических принципах работы защиты, а не о практических нюансах.На практике, в злачные места, ставят медовые ловушки, которые собраны специально со всей отладочной информацией. Эксплоиты не прод долбят, а медовые ловушки, с которых снимаются логи, фиксятся дыры. А прод только обновляет фиксы дыр. Все у С, С++ в работе с проактивной защитой отлажено многими десятилетиями.
ЗЫ: мордеры важный пост в этой ветке удалили...
И зачем вы перепрыгнули с разговора о "переполнении буфера" на "выход за пределы диапазона массива"?
> И зачем вы перепрыгнули с разговора о "переполнении буфера" на "выход за
> пределы диапазона массива"?А чем они, в данном контексте, принципиально отличаются?
Используйте. Много успешных проектов уже сделали самостоятельно уровня мобильной OS?
Доо, мобильная ОС которая работает на одном единственном микроконтроллере и в QEMU. Класека ржавых ОС.
>Ржавчина не нужна!Компания Vivo, занимающая около 10% мирового рынка смартфонов (5 место среди производителей смартфонов) встала смирно и взяла под козырек перед мнением иксперда опеннета.
Компания Vivo, занимающая около 10% мирового рынка смартфонов, внезапно обнаружила, что выбор раста для ядра был глупостью и поддержка стала слишком дорогой.Ввиду чего и открыла код чтобы получить бесплатных разработчиков.
>околоhttps://habrastorage.org/r/w1560/getpro/habr/upload_files/43...
> Компания Vivo, занимающая около 10% мирового рынка смартфонов
> 5 место среди производителей смартфонов) встала смирно и взяла под козырек
> перед мнением иксперда опеннета.Что характерно - вон то лишь какая-то шляпа для ненужночасов, а смартфоны - на линухкернеле, как я понимаю.
Проверки на этапе компиляции невозможны в принципе пока для каждой ссылки в аргументах и возвращаемых значениях, а также каждого типа, содержащего ссылки, не будет обязательным указание лайфтайма. Есть зачаточная реализация этого в виде lifetimebound, но она именно что зачаточная, и нестандартная (хотя обложиться нестандартным говном чтобы просто работать это именно то чего C++ достоин), и до внедрения её в любом виде хотя бы в фундаментальных библиотеках типа openssl пройдёт ещё лет 20.
>Используйте Gentoo LinuxВ часах! Не, ну, а почему бы и нет?
> В часах! Не, ну, а почему бы и нет?Вообще, часы с андроидом уже бывают. Т.е. линух на часах забутявить реально вполне. Но если ты сможешь закомпилять на часах генту - ты однозначно сделаешь день в топе айтишных новостей.
Что именно ты не смог прочитать в документации по ключам си-компилятора в разделе проверки во время компиляции?
С++ тоже можно проверить на этапе конь-пиляции.
> Проверки на этапе компиляции.В настоящий момент (до принятия С++26) в C++ это можно сделать плагином для компилятора: https://github.com/rsashka/memsafe
> В настоящий момент (до принятия С++26) в C++ это можно сделать плагином
> для компилятора: https://github.com/rsashka/memsafe"Просто обмажтесь плагинчиками от васянов и будет вам щастя"
Ты это же не серьезно советуешь?
Это proof of concept реализации всех разрекламированных возможностей Rust на С++.Ведь ты не серьезна советуешь переписать тонны существующего кода на новом модном языке?
> Ведь ты не серьезна советуешь переписать тонны существующего кода на новом модном языке?Но ты же серьезно предлагаешь покрыть ручками весь старый код аттрибутами и всяким memsafe :Shared<>, которые необходимы для работы этого плагина. Или ты думал, что он сам автоматом магию делает?
> Это proof of concept реализации всех разрекламированных возможностей Rust на С++.Вот именно что proof of concept, да еще и гвоздями к Шлангу прибитый. Вот когда такое в C++ из коробки появятся, тогда и можно будет говорить.
Это заговор. Чтобы сбить темпы развития СПО время от времени пропагандируют что-то переписать. Так было с python2-3 переписывание не добавили безопасности и пару лет времени отобрало.Теперь предлагают переписать с C на rust под предлогом безопасности.
Как закончат переписывать с C на rust, скажут что теперь надо все на SPARK переписать...
> Это заговор. Чтобы сбить темпы развития СПО время от времени пропагандируют что-то переписать.А у СПО есть какие-то темпы развития?
Шевеление есть только там где есть корпы, которые вкладывают ресурсы.> Так было с python2-3 переписывание не добавили безопасности и пару лет времени отобрало.
А кто говорил про безопасность?
Питон 2 просто не соответствовал современным реалиям.
Отсутствие нормального Unicode, проблемы с целочисленным делением, просто архитектурные недостатки.> Теперь предлагают переписать с C на rust под предлогом безопасности.
Но дырявость СИ это печальный факт.
Тот кто отказывается от безопасности в угоду скорости, не получит ни первого, ни второго, а будет разгребать CVE/RCE> Как закончат переписывать с C на rust, скажут что теперь надо все на SPARK переписать...
И это нормально.
Это эволюция: в машинах сначала были только ремни, потом добавили подушки, потом АБС, программируемые зоны деформации и так далее.
Неправильная постановка вопроса. Нужно: Что из этого не умеют делать разрабы на С++?
Вопрос риторический, ответ очевиден:Выдерживать сроки разработки при должном качестве конечного продукта такого уровня на C++ сложнее, чем на Rust
Для бизнес-сегмента это критично. Для любительских проектов - хоть до конца жизни вымучивай, никто слова не скажет против. Можно ли ручной пилой перепилить 400-летний дуб? Можно. Но проще и быстрее это сделать бензопилой. Хотя кто-то скажет что распил будет не таким аккуратным.
> Неправильная постановка вопроса. Нужно: Что из этого не умеют делать разрабы на
> С++?
> Вопрос риторический, ответ очевиден:
> Выдерживать сроки разработки при должном качестве конечного продукта такого уровня на C++
> сложнее, чем на Rust
> Для бизнес-сегмента это критично. Для любительских проектов - хоть до конца жизни
> вымучивай, никто слова не скажет против. Можно ли ручной пилой перепилить
> 400-летний дуб? Можно. Но проще и быстрее это сделать бензопилой.
> Хотя кто-то скажет что распил будет не таким аккуратным.Для бизнес сегмента Rust тоже нафиг никому не нужен. Была Java и много где до сих пор используется. Винда сидит на C шарп в целом норм. Замену JAVA - GoLang много интереснее по причине схожего синтаксиса и более низких уровнях вхождения в язык.
А раст не нужен особо никому кроме кучки оголтелых..
> Замену JAVA - GoLangЭт в какой вселенной голанг является заменой жавы? Замена жавы это Котлин, ну или хотя бы Шарп, на худой конец. Голанг это замена всяким там микросервисам на жс и байтолюбствам на сишке в некритичных к производительности местах
Это странно, но почему-то на го очень часто переходят с явы.
>Для бизнес сегмента Rust тоже нафиг никому не нужен.Зависит от того, что понимается под бизнес сегментом. Да? А то ведь вот эта Vivo - тоже бизнес сегмент.
> Для бизнес сегмента Rust тоже нафиг никому не нужен.Гугл с его андроидом это бизнес или нет?
Клоудфларя? letencript?А вольво которые добавляют хруст в свои машины? Вроде серьезный бизнес)
> А вольво которые добавляют хруст в свои машины?Это как покрасить коленвал в розовую полосочку.
>Хотя кто-то скажет что распил будет не таким аккуратным.Так может сказать только тот, кто ни разу в своей жизни не работал ручным инструментом. Аккуратнее и ровнее распила чем от применения электроинструмента(бензо в том числе) ты не получишь.
> Для любительских проектов - хоть до конца жизни вымучивай, никто слова не скажет против.Пример ffmpeg и libav !!!
Где важна оптимизация на максимальное быстродействие с использованием SIMD инструкций процессора время написания правильного кода на C в пять раз больше чем кривого. И ВСЕ кричат давай дырявый код на C, но чтобы видео кодек был готов за год, а не через пять лет.
История ffmpeg и libav доказательство выше сказанного.
заставлять разработчиков этим пользоваться..
"Поверх ядра реализована стандартаная библиотека Си, поддерживающая программные интерфейсы..." - т.е. оглядка на обеспечение безопасности здесь заканчивается и вся Растовость тает. Поймите правильно, без сарказма.
Rust при компиляции полагается на Сишную библиотеку.
Как бы это не звучало, без неё Rust можно будет скомпилировать только с без самой стандартной библиотеки Rust'а.
> Rust при компиляции полагается на Сишную библиотеку.Это в std режиме, то есть при компиляции в таргет с операционной системой. Если пишешь ось, то ты сам по себе и реализуешь все абстракции самостоятельно в каком виде нравится - хоть в виде внешней сишной либы, хоть на расте, хоть в асм секциях на расте.
> хоть в асм секциях на расте.небезопасно же!
> Rust при компиляции полагается на Сишную библиотекукто б сомневался, без си ни шагу.
> "Поверх ядра реализована стандартаная библиотека Си, поддерживающая программные интерфейсы..." - т.е. оглядка на обеспечение безопасности здесь заканчивается и вся Растовость таетВо-первых, заканчивается она только там, где начинается сишный код. Причем твой собственный сишный код, потому что начинка этой библиотеки С написана на Расте.
Во-вторых, саму эту библиотеку С использовать никто не заставляет.
Непотнятно, где ты тут увидел таяние.
Чел, там больше 50% растокода на ансейфах, о чем вообще разговор?
> Чел, там больше 50% растокода на ансейфах, о чем вообще разговор?Во-первых, откуда цифра в 50%? Во-вторых, unsafe Rust это все равно намного безопаснее Си. Самые главные фичи Раста, включая borrow checker, активны и в unsafe. Единственное исключение - это сырые указатели, ради которых собственно этот режим и существует. Все остальное - это по сути тот же Раст.
Чел, 100% сишного кода это ансейф x)
> Чел, 100% сишного кода это ансейф x)Бедные воины против Раста не замечают, что своими аргументами поносят именно Сишку. 😂
"Какой толк от вашей бочки Раста, если ложечка Сишечки ломает всю вашу безопасность! Ахаха, выкусите, растоманы!"
Сишку тебе хотя бы valgrind поправит, да и генерируемый двоичный код достаточно читаемый и предсказуемый. Лучше с плюсами сравнивать, там тоже чёрте что, и никак не разберёшься, что и куда утекает.
> Сишку тебе хотя бы valgrind поправитВ Дебиане уже поправили один раз, спасибо, но больше не надо.
Никто не заставляет, но остальные будут её использовать. И в итоге твой аргумент про безопасность рушится на ходу.
> И в итоге твой аргумент про безопасность рушится на ходу.М... т.е. если мы повесили знак 90, а кто-то решил давануть 150, то это "аргумент про безопасность рушится на ходу"?))
Если кто-то продолжает пользоваться дырявыми языками, то это их проблема. И с ними уже начали бороться.
> остальные будут её использовать. И в итоге твой аргумент про безопасность рушится на ходу.В итоге безопасность будет рушится только в твоем сишочном коде, а не в самой ОС, которая на Расте. Вы правда не догоняете разницы?
а коды что - изолированы друг от друга и никакими параметрами не обмениваются? Косяк в расте может привнести ошибку в си коде.
> а коды что - изолированы друг от друга и никакими параметрами не обмениваются?Да, изолированы, прикинь? И да, общаются только через вызовы функций и их параметры.
Это, по-твоему, как-то противоречит изначальному утверждению, что небезопасная работа с памятью будет именно во внешнем сишном коде, а не в самом растовом сабже?
> Косяк в расте может привнести ошибку в си коде.
А твои коллеги по войне против Раста намекают на обратное: что якобы если во *внешнем* сишном коде дырени, то нет смысла писать *внутренний* код ОС на Расте.
Вы уже пределитесь-то, против чего воюеете, а то ваши аргументы похожи на какой-то сумбурный бред.
Ну и главное: какой еще косяк в Расте ты имеешь в виду и какое он имеет отношение к теме о безопасной работе с памятью?
А люди пользуются программами, а не ОС.
Так что удачи в святой безопасности ржавчины.
ну хоть кто-то сделал на расте что-то полезноеслава б-гу
Болгеос для часов?! Было время, когда часы работали по 8 лет без замены батарейки.
> Было время, когда часы работали по 8 лет без замены батарейки.Такие часы и сейчас есть. Но ничего, кроме собственно часов, будильника и секундомера/таймера в них нет.
Сабж для других "часов", которые не ради просмотра времени покупают.
В моих ышшо барометр, альтиметр, шагомер, термометр и скедулер, который это все может сливать в телефон по бт. Батарейка за 3+ года так и не менялась. Так что мимо
а и компас забыл, тоже есть
> а и компас забыл, тоже естьглубинометр. глубинометра не хватает.
> глубинометр. глубинометра не хватает.Водонепроницаемость у часов пропадет сильно раньше, чем батарейка разрядится.
Эпплочасами не ту глубину, что с водой, меряют.
BT и три года… верим, верим
> BT и три года… верим, веримА я вот верю, потому что на практике этими всем уберметрами эти персонажи пользуются ровно один раз в жизни - после покупки. 😂
> это все может сливать в телефон по бтЕсли это делается в ручном режиме раз в год - то вполне может быть.
Лучше бы тело написало бы конкретную модель, чтобы мы все оценили.
А с подзарядкой от солнышка считается?У меня функциональность ограничена. Но синхронизация времени с телефоном по бт работает. Ну и часовые пояса периодически выставлять приходиться (стрелки туда сюда крутить).
Аккумулятор через 15-лет сдох, хотя гарантия на 3 года.
После замены снова все работает.
> Такие часы и сейчас есть. Но ничего, кроме собственно часов, будильника и секундомера/таймера в них нет.а надо?
> а надо?А как же! Читать текст СМСки на экране 3.5 см, например.
Иногда хватает пары строк, чтобы понять что это очередная реклама. После этого sms удаляется одним движением на тех же часах.
А мне не надо лезть в карман за телефоном.Плюс еще куча возможностей (которые нужны мне): управление плеером, нотификации о звонках в silent режиме телефона.
У меня когда-то был телефон с дисплеем вот примерно 3,5 см, и с него прекрасно читались смски. Только разрешение было 128×128, а не как сейчас на часах.
Было время, телефоны по две недели работали.
Правда, телефонией их функции и ограничивались.
> Правда, телефонией их функции и ограничивались.Да ладно. Там была еще адресная книга. И... и змейка!
А еще им можно было колоть орехи или отбиваться от гопарей.
>> Правда, телефонией их функции и ограничивались.
> Да ладно. Там была еще адресная книга. И... и змейка!
> А еще им можно было колоть орехи или отбиваться от гопарей.студентка принесла в ремонт древнюю нокию чуть ли не 3310.
приемщик: девушка, уже выбросили бы эту рухлядь и купили что-то новое?
студентка: вы что!!?? у него 16 режимов виброзвонка!шутки шутки но даже уже как бы микрософтовская нокия 520, купленная как подхват, когда быв супруга мобилку протеряла, успела быть перееханной автобусом но доси работает (мобилку переехало не жену к сожал^W^Wя)
>не жену к сожал^W^WяРазводись. Пусть жена найдет себе адекватного мужа.
Так он же написал "быв супруга". Развёлся уже.
> Болгеос для часов?! Было время, когда часы работали по 8 лет без
> замены батарейки.э э никто твои касио 91 например из твоих мертвых холодных пальцев не вырывает
они говоряти доси производятся
Красота. Хорошая новость.
> В минимальной конфигурации ядро требует для своей работы всего 13 КБ оперативной памятиА сколько на диске занимает?
Гигабайт
подсказка: оно на раст
СКОЛЬКО!?
Оно в наручных часах работает, чувак. Не терабайты, точно.
А я хочу в настенных!
Кто вам мешает прибить наручные часы на стену?
>> В минимальной конфигурации ядро требует для своей работы всего 13 КБ оперативной памяти
> А сколько на диске занимает?Вычеркните уже "У Раста жирные бинари! Хелловрот весит 10мегов!" из вашей методички, а то слишком уж уныло.
Нормально.https://blueos.cloud/docs/stable/integrations/hardware/requi...
>ядро требует для своей работы всего 13 КБ оперативной памяти.рынок каждый год настаивает чтобы мы обновляли смартфоны,
кого эти ребята хотят обмануть
Да никого, они потом жвм поверх накрутят и понеслась.
Там небось, микроядро, которое предоставляет предельный минимум, вот оно и жрёт 13кб. А сервисы, реализующие всё остальное, решили не считать.
> 13 КБ оперативной памяти.
> рынок каждый год настаивает чтобы мы обновляли смартфоны,Но если запустить браузер.
виндакапец уже настал. линухкапец на подходе...
>Компания VivoПрощупывают что-то через суббренд.
Если кто не знал, то:
BBK → Oppo и Vivo.
Oppo → realme и OnePlus.
Vivo → iQOO
>p.s.:
>https://www.opennet.dev/opennews/art.shtml?num=58613О боже мой! Да что они себе позволяют!
Пользуйтесь айфонами и пикселями, там точно ваши данные в полной безопасности!
Конечно всякое бывает, но добровольно отдаться КПК нет никакого желания.
Эдвард Сноуден рассказал про https://ru.wikipedia.org/wiki/PRISM_(программа_разведки), к сожалению про программы слежки других стран мне не известно, хотя наверняка они есть.
Он то явно не принципиальный чел: https://www.kommersant.ru/doc/5581983
А я вот думаю что было бы круто иметь серверную, десктопную, смартфонную операционную систему с одним ядром, потребляющим немногим больше 13 КБ ОЗУ.
> Пользуйтесь айфонами и пикселями, там точно ваши данные в полной безопасности!Ну так гугл с дядей Сэмом где-то там и сливать данные тов. майору не будет.
А китайчина это сделает с удовольствием.Нужно же думать не только о том, что сольют данные или нет, а кому они достанутся.
>Ну так гугл с дядей Сэмом где-то там и сливать данные тов. майору не будет.Это они тебе сами лично сказали? Что их остановит? Все правительства сотрудничают между собою в плане слежки и выявления неугодных, хватит этих розовых очков.
> Это они тебе сами лично сказали?Слава богу нет :)
> Что их остановит?
Нежелание сотрудничать с реальным врагом?
> Все правительства сотрудничают между собою в плане слежки и выявления неугодных,
> хватит этих розовых очков.Если бы это было так, то меня бы уже посадили. Но как видишь я пишу тут комменты.
Все зависит от того что ты сделал. США вот вообще не уперлось передавать данные что такой-то такой-то в 2019 году в фейсбучке запости карикатуру на солнцеликого. А еще писал инструкции по настройке сами знаете чего из трех букв. А еще шутил над обезъяной и верунами. Ух сколько всего плохого сделал)))
Неуловимый Джо?
Есть такое слово Интерпол.
Интерпол донес в российскую полицию на 14-летнего подростка из-за компьютерной игры.
https://lenta.ru/news/2025/07/13/interpol-dones-v-rossiyskuy.../
Много тебе есть чего скрывать от товарища Майора? Есть подозрения, что ты даже своей/своему (подставь что сам хочешь) не очень интересен, не то что бы товарищу Майору🤹🤡🎉
За написание майора с большой буквы доплачивают, или это от незнания правил русского языка?
Это от очень большого уважения.
> О боже мой! Да что они себе позволяют!
> Пользуйтесь айфонами и пикселями, там точно ваши данные в полной безопасности!Настолько в безопасности - что без одобрения эппл вообще девайсом пользоваться невозможно. Концентрационный лагерь - это весьма специфичная форма безопасности. Даже гламурный и с улыбчивыми надзирателями.
Надо посчитать сколько там у них unsafe. ЕВПОЧЯ.
Да без разницы! Факт тот, что танцевать на льду при помощи костылей с коньками никто не будет (я про раст программирование :) ). Язык выбран крайне неудачно и всё, что они получили - ещё один "местечковый проект". Ну это как написать мобильную ОСь на Smalltalk - тоже лучший из ООП языков, причём ещё и выигрывающий по концепциям, но... извини - никому не нужный.
Так я о том же, только тоньше.
>никто не будетСтатистика говорит об обратном - популярность, количество вакансий и проектов растут как на дрожжах. inb4 - "корпорасты насильно зостовляють"
>Язык выбран крайне неудачноИнтересно, по каким критериям оценивал? Видимо, по критерию "очень не люблю, поэтому плохой".
Трепло!(С) :)__18__ место на TIOBE. Между Scratch и Assembly language... К успеху шли :)
PS: И даже не думай мне тут петь что TIOBE - это не показатель, пока ваша ржавка там росла вы тут первые на неё ссылались. Вот и жрите чего там нынче! -5 позиций, кромешный успех. Просто народ начал догадываться ;)
> __18__ место на TIOBE.Мда... вот от тебя ссылку на TIOBE не ожидал...
Ничего что в нем Visual Basic обгоняет Kotlin?
> я про раст программирование :)Хорошо что пояснил, до этого было очевидно, что ты по сишку.
> местечковый проект
В эмбеде Раст себя отлично чувствует. Там настолько все устали от сишки, что готовы были туда, прости Господи, даже питон запихнуть, лишь бы уровень пердолинга уменьшить и качество увеличить.
Я смотрю, некоторые пугаются самого слова unsafe, как будто там обязательно какой-нибудь бэкдор ☺. Не забывайте напоминать себе, что каждая строка C++ является unsafe.
ну и кому верить, тебе или рекламе раста? не смеши
> ну и кому верить, тебе или рекламе раста?Можешь любому, ибо оба топят за Раст. Или ты этого не понял в порыве праведного гнева? 😂
Так авторы C++ и не утверждают что он безопасный, в отличии от раст-неучей.
Ещё скажите, они (авторы C++) гордятся этим 🤦♂️Ой, постойте, совсем не гордятся. А даже начали смотреть в сторону Rust, что бы у него позаимстовать, чтобы сделать свой монструозный язык (C++) хоть как-то соответствующим современным требованиям к ПО.
> Так авторы C++ и не утверждают что он безопасный, в отличии от раст-неучей.И именно поэтому они сейчас пытаются лепить Safe C++ )))?
Заимствуют туда подходы из раста.Правда это раскололо комитет на 2 противоборствующие группы и устроило бугурт среди поклонников разных подходов.
> Правда это раскололо комитет на 2 противоборствующие группы и устроило бугурт среди поклонников разных подходов.Представляешь два разных подхода. И в обоих направлениях можно получить свои плюсы и минусы. А rust просто лепят как получится.
Ибо rust, по своей сути, пилотный проект.
> Представляешь два разных подхода. И в обоих направлениях можно получить свои плюсы и минусы.Шутка про два стула уже актуальна?
Насколько я видел, то от технических аргументов уже ушли, и в ход пошли оскорбления, политические лозунги и прочий крап.> А rust просто лепят как получится.
Возможно.
Но пока получается.> Ибо rust, по своей сути, пилотный проект.
Хороший пилотный проект, в андроиде уже работает, у кучи фирм типа клоуфлар, мелкомягких и тд - тоже.
Даже на пол шишечки зашел, так сказать пенетрировался, в ядро линукс.
> Хороший пилотный проект, в андроиде уже работает, у кучи фирм типа клоуфлар, мелкомягких и тд - тоже.
> Даже на пол шишечки зашел, так сказать пенетрировался, в ядро линукс.С тем, что он хороший как пилотный проект - согласен.
Нужен следующий этап - осмысление получившегося и проектирование правильного.
> Нужен следующий этап - осмысление получившегося и проектирование правильного.Чтобы потом опять переписать))?
Я думаю, что просто какой-то rust 2028 стабилизируют и внесут ломающие изменния.
Добавят чего не доставало, может что-то дропнут.
Не является. Потенциальные проблемы могут быть только у при операции разрешения указателя (в реальный адрес памяти). Всё остальные операции безопасны как тот же rust.
И то, на C++ хватает абстракций, чтобы прямая работа с памятью была необязательна. Т.е. программы вполне себе могут быть безопасны целиком и полностью (точно так же как и на rust).
> Потенциальные проблемы могут быть только у при операции разрешения указателя (в реальный адрес памяти). Всё остальные операции безопасны как тот же rust.Очередной эксперт, в глаза не видевший C++, воюет против Раста.
Вот тебе банальный пример на подумать:
std::vector<int> v{1, 2};
auto& i = v[0];
v.push_back(3);Или:
int a = 1;
int& i = std::max(a, 10);А теперь ответь, эксперт, чему в обоих примерах равен i? Там же все безопасно, прямо как в Расте, не правда ли?
Во втором примере Вы const забыли:q.cpp:10:20: error: binding reference of type ‘int&’ to ‘const int’ discards qualifiers
int& j = std::max(a, 10);
В обоих примерах использованы ссылки (семантика указателей в другом синтаксисе). Именно про это и было написано выше.Хотите чтобы безопасно - обращайтесь к элементам коллекции всегда по индексу. И -D_GLIBCXX_ASSERTIONS включить не забудьте. Да, станет тормознее - всё как в rust.
Присваивать результат функции в ссылку (или возвращать ссылку на локальную переменную) - детские грабли. Компилятор C++ такого не запретит (и этим он прекрасен), но это надо знать.
> В обоих примерах использованы ссылки (семантика указателей в другом синтаксисе). Именно про это и было написано выше.Выше написано "в C++ хватает абстракций, чтобы прямая работа с памятью была необязательна". И в обоих примерах нет прямой работы с памятью.
> Присваивать результат функции в ссылку (или возвращать ссылку на локальную переменную) - детские грабли
Но ведь методы vector и функции типа max возвращают именно ссылки/итераторы. Предлагаешь всегда копировать? Ты там вроде что-то о скорости Раста заикался?
> Компилятор C++ такого не запретит (и этим он прекрасен), но это надо знать.
Старое доброе "чтобы не было багов, не делайте багов". Всего-то делов 😂.
> ...ошибками при работе с памятью, которые по статистике Google и Microsoft составляют 70% от всех уязвимостей в операционных системахнапомню: в ВАШИХ операц.системах! Написанных ВАШИМИ индусами и прочими "специально отобранными HRами" фуфелами.
Я вот пишу на C# - да, довольно далеко от C++, но... кто мешает в том же С++ юзать "умные указатели"?? Факт тот, что "проблемы с памятью" больше проблема низкоквалифицированных, ДЕШЁВЫХ кадров, а не языка. Писали же как-то в 2000-ых большие системы! И ничё, без всяких Растов вылизывали код и работало со 100% гарантией. Эмбед - тот вообще на Си - тоже устройства работают ГОДАМИ БЕЗ СБОЕВ. Так что лажа с памятью - извини, макросоfак, твоя личная халтура.
Теперь тоже самое, но про Ассемблер (вместо С) и С (вместо Rust).
Пожалуйста:Си - сильно __облегчил__ жизнь системных программистов у которых до него были только ассемблеры...
Раст ... ну ... мнэ...
Есть ровно один доделанный проект на руст, остальное - "начали переписывать, вот C0c уже готов"(С)нах-пох
Начнем с того, что ASM вы не сможете читать в реальном времени и понимать всю структуру кода и данных. Нужно много комментариев.
В Си это из коробки.
И да, полностью согласен, что очень часто люди имеющие очень большой "опыт" не понимают базовых вещей, потому что... Ну так получилось.
А использование Rust-а или языков с автоматическим управлением памяти этому способствует.
Что тут можно сказать: пишите больше на Rust-е, чтобы нормальные программисты без работы не остались!
> Что тут можно сказать: пишите больше на Rust-е, чтобы нормальные программисты без
> работы не остались!Это те нормальные, которые CVEшки по памяти уже десятки лет плодят?
Тут уже приводили пример Теодора Тцо, который типа супер СИшник, писака в ядро с 91 года и тд.
При этом делает типичные ошибки с переполнениями буфера.
>> люди имеющие очень большой "опыт" не понимают базовых вещей, потому что...Что по твоему являются "базовыми вещами?" Многие ассемблерщики тоже не понимают, как нолики-единички кодируются в плавающих затворах транзисторов.
>>> люди имеющие очень большой "опыт" не понимают базовых вещей, потому что...
> Что по твоему являются "базовыми вещами?" Многие ассемблерщики тоже не понимают, как
> нолики-единички кодируются в плавающих затворах транзисторов.Прошу прощения, да, я сам это понимаю не по проф. необходимости, а потому что так сложилось...
Я имею в виду, управления памятью процесса, цикл жизни объекта, передача объекта по ссылке и т.п. вызывает удивление, когда человек с 2 годами опыта просто не понимает, что тут есть определённые правила. Про выход за границы вообще молчу.
> Что тут можно сказать: пишите больше на Rust-е, чтобы нормальные программисты без работы не остались!Ох, как я люблю эту элитарность!
У нормальных программистов язык – это инструмент, а не святая корова, которой они поклоняются.
Неспособность использовать разные языки – отличительная черта непрофессионала. Тебе не стоит этим гордиться.
> У нормальных программистов язык – это инструмент, а не святая корова, которой они поклоняются.И они с ними не носятся как писаной торбой, везде неся "благую весть", как отъявленные евангелисты.
Я 20 лет пишу на голых указателях и у меня не было проблем. Просто я знаю что пишу, зачем пишу и как пишу. Боятся указателей только недалекие любители ООП.
> Я 20 лет пишу на голых указателях и у меня не было
> проблем. Просто я знаю что пишу, зачем пишу и как пишу.
> Боятся указателей только недалекие любители ООП.писать на голых указателях щекотно и неприлично
слышал про тесты, статические анализаторы и анализаторы памяти?
> слышал про тесты, статические анализаторы и анализаторы памяти?Ага. Только они или мало помогают или ими приходится обмазываться как лечебной грязью. И тоже не всегда помогает)
Вот opennet.ru/opennews/art.shtml?num=58622
Уязвимости в OpenSSL/LibreSSL: чтение вне буфера, use-after-free, double free, разыменование NULL. Целый набор типичных уязвимостей дыpяшки.И это при том что у них там и санитайзеры, и фаззинг, и тесты.
Можно даже посмотреть github.com/openssl/openssl/actions/runs/4124496105Т.е в крипто либе куча дыреней, причем типичных по памяти.
От которой зависит упрут ли твои денюжки, своруют ли код или личные фото с компа, или даже познакомит ли тебя тов.Майор со своей любимой бутылочкой шампанского.
> Только они или мало помогают или ими приходится обмазываться как лечебной грязьюА вот ровно тоже самое, но встроенное в компилер рузда - увеличивает пенис на пару дюймов(С)
> Уязвимости в OpenSSL/LibreSSL
Уязвимостей в RustSSL - нет... Потому что RustSSL - нет. Всё логично - самый безопасТный ёзыг :)
> Уязвимостей в RustSSL - нет... Потому что RustSSL - нет.Есть Rustls вообще-то.
Ты методичку когда в последний раз обновлял? С таким наплевательским подходом Раст не победить.
Где используется? :) Ну понятно ... (С)Где используется OpenSSL "написанный дидами на дыряшке" и который нетакусики _несколько_ раз тужились заменить - я не расскажу, у меня столько свободного времени нету :)
Оф коз. Наши гении местные даже Coverity купили за стоимость маленькой деревни с крепостными... Всё более, чем ок было.
> слышал про тесты, статические анализаторы и анализаторы памяти?Эти все инструменты уровня "может баг поймает, может не поймает". Когда отсутствие багов гарантируется статически на базе системы типов, то оно гарантируется, то есть формально математически доказывается.
Единственный косяк в этом, не все баги удаётся помножить на ноль системой типов. Процентов 90, наверное, а дальше неустранимая проблема останова.
> Я 20 лет пишу на голых указателях и у меня не было проблем. Просто я знаю что пишу, зачем пишу и как пишуВ одно лицо писать свои хэлоуворлды вы можете хоть на Brainfuck. Серьезно.
С вероятностью 80% твоё сообщение пришло через мой хэллоу ворлд, смешной.
> С вероятностью 80% твоё сообщение пришло через мой хэллоу ворлд, смешной.Я тебе конечно верю,
Разве могут быть сомненья,
Ведь не может Аноним,
В интернете назвездеть!Пруфы просить не буду, так такие как ты просто сливаются в закат)
Вмести с си идёт комплектом проблемы с памятью.
С комплектом проблем с памятью идет прокладка между стулом и монитором
> С комплектом проблем с памятью идет прокладка между стулом и мониторомУгу, Вася сам виноват что его на шкив без кожуха намотало.
Нужно просто быть внимательным, а кожухи вообще не нужны.
Я не понял :(
На всякий случай загрузил твой пост в AI а оно ... мне проно-фильм сгенерило ...;-D :-))))))
Так что ж ты тогда не работаешь на M$/Google/Apple, а строчишь комменты на опеннете? Отправь своё резюме в M$, напишешь такой 12 мастдай, что все ахнут)))))
Не ахнут. Не напишет, даже если захочет.Капиталу не нужны конкуренты, капиталу нужна дешёвая раб. сила, не слушком вумная, чтобы вопросами не задавались. А компенсировать их косяки будет вера в Святой Безопасный Язык, который заранее знает, что всё будет хорошо.
> Капиталу не нужны конкуренты, капиталу нужна дешёвая раб. сила, не слушком вумная, чтобы вопросами не задавалисьВот потому удел нашего умного непризнанного гения (как он сам и признался) - писать свои хэллоуворлды в одно лицо. Да и то - чисто в перерывах от каторжной физической работы, ибо кушать-то ему хочется. 😭
> Капиталу не нужны конкурентыКакие конкуренты? Что вы несёте? У одного человека есть возможность составить реальную конкуренцию вот этим всем перечисленным конторам?
> но... кто мешает в том же С++ юзать "умные указатели"?Никто.
Просто их ценность слегка преувеличена.
Гугуль их даже улучшил и сделал MiraclePtr.
Нежидано, но Чуда не произошло))"Предоставило защиту от 57% уязвимостей класса use-after-free" - у вас будет дырявая память 50-на-50.
"Потребление памяти основным процессом браузера при применении MiraclePtr увеличивается на 5.5-8% ... Среднее повышение потребления для всех процессов оценивается в 1-3%"
А еще оно будет тормозить и жрать память.opennet.ru/opennews/art.shtml?num=60482
> Просто их ценность слегка преувеличена.Не совсем так.
С умными указателями не проходят все те варианты использования, которые есть с простыми. Поэтому писать с ними большие проекты можно (неудобно, так как часть шаблонов проектирования отпадает, но можно), а вот переписывать совсем тяжко. Так как обычно как раз эти варианты использования простых указателей используются и в хвост и в гриву.
>>кто мешает в том же С++ юзать "умные указатели"?Стремление к компактности кода и лучшей читаемости. Для обычных указателей достаточно заюзать один символ * или &, а умные указатели выглядят как нагромождение всяких std::unique_ptr и иже с ними, что мешает воспринимать код и увеличивает количество ошибок.
> . Писали же как-то в 2000-ых большие системы!А потом эти "большие системы" подключили зачем-то к Интернет ... из последнего - Аэрофлот
> Факт тот, что "проблемы с памятью" больше проблема низкоквалифицированных, ДЕШЁВЫХ кадров, а не языка.Не поделитесь информацией, сколько вы зарабатываете в год? Подозреваю, что ваш труд будет гораздо дешевле специалистов из Google и Microsoft, которые проходят многочасовое собеседование прежде, чем попасть в подразделения системного программирования.
> Писали же как-то в 2000-ых большие системы! И ничё, без всяких Растов вылизывали код и работало со 100% гарантией.
Писать-то, писали. Но до сих пор CVE вылавливают вот с тех дремучих времён. При всём желании ЭТО назвать 100%-й гарантией можно только в очень сильном похмельном угаре.
> Эмбед - тот вообще на Си - тоже устройства работают ГОДАМИ БЕЗ СБОЕВ.
Ох уж эти "эксперты" Опеннетные. На, любуйся.
1. Радиотерапевтический аппарат Therac-25 (1980-е)
Проблема: Гонки потоков (race conditions) в коде на C привели к передозировке радиации.
Последствия: Несколько пациентов получили серьёзные травмы или погибли.
Причина: Плохая синхронизация между аппаратными и программными компонентами.2. Непреднамеренное ускорение у Toyota (2000-е)
Проблема: Ошибки во встроенном ПО блока управления дросселем (ECU).
Последствия: ДТП, жертвы, масштабный отзыв автомобилей.
Причина: Переполнение стека, ошибки рекурсии, недостаточный контроль таймеров в коде на C.3. Уязвимость Heartbleed в OpenSSL (2014)
Проблема: Выход за пределы буфера из-за отсутствия проверки границ.
Последствия: Массовые утечки данных, включая устройства с встроенным OpenSSL.
Причина: Банальное упущение в широко используемой C-библиотеке.4. Контроллер батареи Samsung Galaxy Note 7 (2016)
Проблема: Ошибки в управлении температурой аккумулятора.
Последствия: Самовозгорание и взрывы устройств, глобальный отзыв.
Причина: Ненадёжная логика управления терморегуляцией в прошивке на C.5. Система управления батареями Boeing 787
Проблема: ПО не распознавало перегрев аккумуляторов.
Последствия: Временный запрет на полёты, расследование FAA.
Причина: Недостаточные алгоритмы обнаружения неисправностей в C-коде.> Так что лажа с памятью - извини, макросоfак, твоя личная халтура.
Как бы ни был мастер, рано или поздно, он таки шваркнет себя обычным молотком по пальцам. А с автоматическим забивателем гвоздей это, СЮРПРИЗ, невозможно.
>А с автоматическим забивателем гвоздей это, СЮРПРИЗ, невозможно.Вы явно никогда не ставили на ладонь пневмо- или электро-степлер
> 2. Непреднамеренное ускорение у Toyota (2000-е)
> Проблема: Ошибки во встроенном ПО блока управления дросселем (ECU).
> Последствия: ДТП, жертвы, масштабный отзыв автомобилей.
> Причина: Переполнение стека, ошибки рекурсии, недостаточный контроль таймеров в коде на C.ЧСХ, Rust без MMU (в микроконтроллерах нет MMU)...
1) Никак не спасет неудачника системного программирования от переполнения стека при какой там рекурсии.
2) И от перезаписи того что было за стеком - в такой конфигурации - тоже.
3) Об этом честно написано в описалове хруста и ресурсов эмбедеров - но кто ж это еще и читает?
4) В свете этого - я пешочком постою ездить на фирмваре ECU с хрустом, там програмер мог бaклaнить на раз уповая что его спасут компилер и рантайм. А они внезапно - не волшебники. И не могут предотвратить переполнение стека в системе без MMU.
Отличная новость. Пойдет в массы - найдут толпу других ошибок и уязвимостей, кроме как работы с памятью. Да еще и unsafe в продуктиве подсыпет радостей, и все вернется на круги своя С и С++
Это поделие на бумаге выглядит красиво, эксплуатация покажет другое. "Вот те крест на все пузо" :)
С и С++ - это подходит только для hello world, ну там сортировка массивов и т.п. лёгенькие алгоритмы! Для надёжных ОС только РАСТ!
и что ты тут делаешь используя ОС,о ужос, нарисанную на C?
> Пойдет в массыДа ладно тебе! Это же не первая оЗЪ на ржавом. Какие "массы", какое "пойдёт" ... ты через месяц и не вспомнишь :)
Гугл УЖЕ переписал часть Андроида на Rust. Клаудфлэр переписала свой прокси-сервер, которым четверть пользователей Инета пользуется. Дропбокс свой софт. Дискорд - свой.
Везде эксплуатация показывает, что всё работает прекрасно, а продуктивность программистов выросла.Давай, малюй дальше своё пузо крестами. Забавно ведь смотреть, как беспомощный воин супротив Раста над своим телом измывается в порыве бессильной злобы и отчаяния.
Раст вошел в рыночек ОС, и теперь сишка будет вытеснена! Лет через 30 - так точно!
Что-то мне это напоминает... не с теми же лозунгами Линукс "побеждал" Венду на десктопах? :))Раст - пропихиваемый(!!!) гуглом язык, который никому в пень не упёрся. Просто вчитайся - ПРОПИХИВАЕМЫЙ! Т.е. люди НЕ ХОТЯТ его юзать, но им всё равно c_p_y_т в уши "а вот раст, а вот ошибки с памятью, кøкøкø....". Надоело. Хуже кАзино и центра английского! :)) Эта п@раша не взлетит. Она УЖЕ не взлетела - просто болтается где-то в пыли, её волокут, отряхивают, трясут для имитации жизни, но она всё равно дохлая лошадь. Просто поверь челу с 35 годами в ИТ.
Сишка - точно язычок прошлого. С этим глу по спорить вообще.
Современный рабочий язык, а не такой который каждую неделю несовместимо меняется.
> Современный рабочий язык, а не такой который каждую неделю несовместимо меняется.Настолько современный и рабочий, что его выкинули из GCC и дальше пишут на плюсах.
На сишке сейчас пишуть только унылое легаси и особенные проекты с особенными диктаторами (вроде аймфиниша)
> дальше пишут на плюсахи на питоне
> особенные проекты с особенными диктаторами (вроде аймфиниша)Который первый же пытается от сишки сбежать на раст в своём особенном проекте, да кандалы мешают.
Охохо. Да ты смешон. Реальность, меж тем, такова, что по соотношению простота/возможности/производительность конкурентов у Си нет, считай. Поэтому все разговоры бесполезны.
> Охохо. Да ты смешон.А аргументы будут?
> Реальность, меж тем, такова, что
СИшку таки выкинули из кодов комилятора GCC - теперь весь новый код пишется на плюсах)
> по соотношению простота/возможности/производительность конкурентов у Си нет, считай.
Ты про соотношение "куча подводных камней/ отсутствие возможностей / производительность на уровне С++" ?
> Поэтому все разговоры бесполезны.
Конечно. Разговоры с фанатиками устаревших ЯП бесполезны.
Си уже морально устраивает по тихоньку. Тоже самое говорили про иксы, в итоге иксы все дропнули.
Так и ты морально устарел, тебя тоже скоро дропнут.
Никто иксы не дропнул (см. пост про Ardour), а Си ещё и тебя переживёт!
> Как и GTK2, библиотека YTK поддерживает только работу с использованием протокола X11 и требует использования XWayland для работы в окружениях на основе протокола Wayland.Вот так он и будет работать, через прослойку совместимости (пока прослойка работать будет). Такое диды будут до талого ваять.
> Никто иксы не дропнул (см. пост про Ardour), а Си ещё и тебя переживёт!Отличный у вас манямирок))
Иксы уже дропают все адекватные дистры. Но слаководу этого не понять...Ardour, кстати, перешел на свой форк GTK2 как раз из-за того что дистры начали массово выкидывать ее из пакетов. И с иксами будет тоже самое - вначале будет работать через xwayalnd, потом будет работать все хуже и хуже, а потом "поддержка двух бекендов отнимает слишком много сил" и выкинут даже xwayalnd.
... а потом "вот вам дефолт бравсер в дефолт гноме"
"А остальное отнимает слишком много сил" и выкинутПоправил не благодари!
Устали бедняжки запятые в C0C.md переставлять.Впрочем никому уже давно не интересно что там у линукса на десктопе, _увы_! :(
> Впрочем никому уже давно не интересно что там у линукса на десктопе, _увы_! :(Чего?
Диды старались выдумывали, а ты так про их труды)У нас было 1 ядро, 75 вариантов его сборки, 5 вариантов init'ов, полсолонки файловых систем и гора утилит, шелл команд и всего такого, всех цветов, а ещё gtk, qt, ящик нескучных обоев, половинка UXа и две дюжины васяновистрибутивов.. Не то чтобы это всё было нужно чтобы сделать десктопную систему, но раз начал заниматься велосимедостоением, то иди в своём увлечении до конца. Единственное, что меня беспокоило — это баш. В мире нет никого более беспомощного, безответственного и безнравственного, чем человек пишущий баш портянки. И я знал, что довольно скоро мы в это окунёмся.
Да шелл как шелл, уж точно не самый плохой.
Просто надо знать когда остановится :) и взять уже ЯП.
> Что-то мне это напоминает... не с теми же лозунгами Линукс "побеждал" Венду
> на десктопах? :))
> Раст - пропихиваемый(!!!) гуглом язык, который никому в пень не упёрся. Просто
> вчитайся - ПРОПИХИВАЕМЫЙ! Т.е. люди НЕ ХОТЯТ его юзать, но им
> всё равно c_p_y_т в уши "а вот раст, а вот ошибки
> с памятью, кøкøкø....". Надоело. Хуже кАзино и центра английского! :))
> Эта п@раша не взлетит. Она УЖЕ не взлетела - просто болтается
> где-то в пыли, её волокут, отряхивают, трясут для имитации жизни, но
> она всё равно дохлая лошадь. Просто поверь челу с 35 годами
> в ИТ.Хуже только реклама Гнусмаса ВЕЗДЕ..
Это напоминает как Java и JavaScript в свое время вытеснили С и С++ из Энтерпрайза и веба. Олды помнят сколько каках было в чатиках вымучено на обоснования что "не взлетит"
Помню-помню, как писали серверные скрипнули на сих для веб-страничек. А потом... упс! И ты в шелл под рутом на сервер попал! Эх! Золотые времена для мамкиных хакеров!
> Это напоминает как Java и JavaScript в свое время вытеснили С и
> С++ из Энтерпрайза и веба. Олды помнят сколько каках было в
> чатиках вымучено на обоснования что "не взлетит"Че за бред? Никогда ни С ни С++ в серьезном Ынтерпрайзе не были, если касаться фронтофиса. А JavaScript вообще значительно позже Java и Appletов появился.
>Че за бред? Никогда ни С ни С++ в серьезном Ынтерпрайзе не были, если касаться фронтофиса.Что такое фронтоофис в данном контексте? Может быть фронтэнд? Мне кажется ты путаешься в терминологии, что ставит под сомнение твою анонимную экспертность?
А на чем писали, на TurboPascal?
Писали на Перле, VBScript, JScript/JavaScript (первое — под IIS, второе — под Netscape Server), PHP3, Ruby
Ого, как у онанима горит. Значит раст всё делает верно.
Когда Раст ничего не делает он поступает верно.
> сишка будет вытеснена! Лет через 30 - так точно!Ну и НЕ растом - точно! :)
>> сишка будет вытеснена! Лет через 30 - так точно!
> Ну и НЕ растом - точно! :)Да никто не будет на расте даже хеллоуворды писать!
Да никто не будет на расте делать серьезные проекты!
Да никогда ваш раст в ядро даже не будут добавлять!
<<<- вы находитесь здесь
Да никогда СИшка не будет вытеснена растомИ другие пророчества местных кекспертов))
Я всегда просто ору - НЕ пишите апликухи на Си! Он для систем-* дроча!
И __хрен__ его оттуда хоть какой Ёзыг вытеснит! Делаю ставки!(С)С растом - всё сложнее. Людям он не зашёл, а AI сдаётся мне сразу будет в кодах (ну ... или на Си :) ) генерить...
> Я всегда просто ору - НЕ пишите апликухи на Си!Так они и не пишут.
Ты же свой коммент выcepаешь в теме про то что кто-то не пишет на дырявой сишке)
Ты это осознаешь?> Он для систем-* дроча!
Заметно.
> И __хрен__ его оттуда хоть какой Ёзыг вытеснит! Делаю ставки!(С)
Лол, как тебя только из цирка отпустили.
В новосте про последнее ведро упомянаются и дрова на хрусте, и впихивание в ядро (не смотря на нытье дидов), а ты тут ставки хочешь ставить.
Дыряшку из эмбедовки уже плюсы вытеснили, а ты про системное пограммирование все вещаешь)> С растом - всё сложнее. Людям он не зашёл,
Ага, то-то на гитхабах на нем ломанулись писать.
И это не считая корпов с кнутами и пряниками.> а AI сдаётся мне сразу будет в кодах (ну ... или на Си :) ) генерить...
Обучать AI чтобы на СИшке писать на чем будете?
На овнокоде от дырявых?
Ну... удачки)
Поделка уровня Tizen, которую даже из часов уже выкинули.
С тазиком с самого начала было просто: либо они разрабатывают тазик, либо им позволяют выпускать ведро.
А почему не ресдох? Она - всё?
Да они уже переписывают недописанное. Растовики что с них ещё взять.
просто переписывают на раст
.. с раста?!?!Это надо обмозговать ... это-ж какие перспективы открываются?! 8-)
тут главное, что на раст и сам факт переписывания, а остальное не имеет значенияхотя обычно для переписывания берут только рабочий готовый софт, с этим на расте могут возникнуть проблемы
Redox - домашний проект. Proof of concept, если тебе знаком такой термин (хотя я сильно сомневаюсь в этом).
> Redox - домашний проект. Proof of concept, если тебе знаком такой термин
> (хотя я сильно сомневаюсь в этом).Redox - микроядро.
Прям как Hurd (Minix/Phantom ̷A̷OS).
Но всем нерастоманам понятно, что Hurd - ЭТОДРУГОЕПОНИМАТЬНАДО!™
Hmm. We’re having trouble finding that site.We can’t connect to the server at blueos.vivo.com.
If you entered the right address, you can:
Try again later
Check your network connection
Check that Firefox has permission to access the web (you might be connected but behind a firewall)Ну и на фиг. Насколько криво DNS настроен, что у меня не резолвится.
DNSSEC и DoT отключать ради китайщины не буду.
> Ну и на фиг. Насколько криво DNS настроен, что у меня не резолвится.У меня все открывает. Что через слово_на_три_буквы, что без.
Скорее всего это не у них криво DNS настроен, а у тебя руки из **пы.Да и зачем их сайт, если есть гитхаб?
Всё работает, похоже что-то ты там с настройками перемудрил...
Очень интересно. Надо попробовать на Raspberry Pi Pico2.
очередная фуксия?
сайт прикольно сделан с автопереводом, но когда показывают картинку с архитектурой на китайском, то сразу как-то опять пахнет галимым недоделом. ибо никто не мешал перевести и разместить картинки.
13 RAM, ARM, RISC-V, POSIX, Rust.
Да это офигенное ядро!
Я фигею с этого ядра!
>В минимальной конфигурации ядро требует для своей работы всего 13 КБ оперативной памяти.Да так если подумать, под этот ваш Андроид не нужен в принципе.
>Код ядра написан на языке Rust и открыт под лицензией Apache 2.0.Восторженные восторги продолжу и выбором замечательной лицензии, а не этой вашей GPL.
Почему бот-обормот скрывает любые комментарии на тему сравнения лицензий? По мнению бота есть только одна правильная лицензия?
Ядро которое ничего не умеет вот уж действительно ядро!
Всё правильно делают. Как K&R завещали, только на другом языке.
Старые сишники дупеют с этой прикормки
>Предоставляется собственная файловая системаУ нас что и так файловых систем в зоопарке мало (и при этом ни одной нормальной нет)? Теперь для этого говна реализации писать и отлаживать придётся, а файловые системы - это rocket science.
Ну, если представить, что сабж захватит приличную часть рынка, а причин почему бы ему это не сделать, то можно и новую файловую систему выучить.
Но зачем? Взяли бы готовую - продукт куда привлекательнее был бы. Да и готовую, наверное, бу улучшил, переписав на Rust.
Какой готовый? Андроид разве только.
ext4 отличная fs.
Но на богомерзкой Си-шке. Для ржавчикоф - харам! :)
Этим только fat16 светит.
В тексте новости забыли важную деталь упомянуть: компания КИТАЙСКАЯ. Что сразу означает, что тем, у кого действуют партийные комитеты, по-умолчанию не то что доверия нет, а есть сразу активное недоверие.
Тогда используйте отечественное.
Присоединяйтесь, друзья, к разработке Hurd.На amd64 он теперь работает, для драйверов реализовали netbsd rump kernel, теперь всё _сильно_ лучше с драйверами. Иксы запускаются.
Если портировать L4Linux на Hurd, можно будет вообще, небось, и все драйвера, кроме nvidia легко запустить.
Новость напиши, что HURD теперь x64 архитектуру поддерживает.
Осталось прикрутить GNOME и будет не хуже этого вашего линукса.
У ReacOS тоже выходят ежедневные x64 сборки, но они почему-то не пишут новости об этом.
GNOME не прикрутить будет к HURD, в GNOME объявили ещё более усиленное прибивание его к systemd.
Hurd даже не имеет группы в Телеграме, чтобы заходить, вопросы задавать.
потому что hurd создавали не в рф, а телегой больше нигде не пользуются
Овердохрена им где пользуются, РФ не на первом месте даже.
вообще нигде. хорошая попытка, ботинок, но нет
Аргументация как всегда, на вашем уровне.
извини, это другое, стрелочка не поворачивается, не всё так однозначно
Открою секрет, из IRC айтишники перешли в ТГ часты, у многих дистрибутивов, FreeBSD, даже illumos есть англоязычные чаты в ТГ. Вообще много у чего на тему ИТ есть англоязычные чаты в ТГ. У Hurd нет ни ТГ чата, ничего, потому что он мёртв.
Не забываем, что HURD - это FSF. Они не станут использовать проприетарную Телегу. Скорее, какой-нибудь чат в GNUnet или XMPP.
> Открою секрет, из IRC айтишники перешли в ТГ часты,Это не айтишники, а так, массовочка пытающаяся под них косить.
Можешь новость про поддержку rump написать? Да и вообще краткий обзор текущего состояния Hurd
> Ядро BlueOS (Blue River Kernel) оптимизировано для минимального потребления ресурсовБезобразие какое, несовременно же.
Заглянул в доки Rust - ассемблерные вставки должны быть завёрнуты в unsafe.
> ассемблерные вставки должны быть завёрнуты в unsafeЭто больше для напоминания, что надо быть аккуратным. UB ассемблерной вставкой не получить.
> При этом ядро поддерживает современные процессорные
> архитектуры - ARM32, ARM64, RISCV32 and RISCV64О нет! А как же они обошлись поддержки дремучего хлама, некросистем и прочей маргинальщины!?
Где поддержка m68k?! Где SPARC? Где PPC?
НЕУЖЕЛИ это все не нужно??
> НЕУЖЕЛИ это все не нужно??Судя по всему x86 тоже туда записали :). В принципе все так, но... :)
Смех смехом, а для сабжа можно попробовать pentium4 запилить ;)
В теории, если из Андроид повыкидывать коммерческие внедрения и бэкдоры компаний для слежки и прочего, то тоже можно будет масштабировать от мала до велика
> В теории, если из Андроид повыкидыватьА на практике выкидывальщики могут только трепаться языком и дальше этого дело не продвинется.
> и бэкдоры компаний
Сколько лет прошу показать бекдор в AOSP - никто не хочет.
Но все верят, что он там есть.
AOSP это та сборка, которая должна быть по умолчанию на продаваемых устройства. Сколько лет прошу показать, где их массово покупают - никто не хочет.
Google.com/pixel не благодари. Лучшие телефоны на Андроиде. Всё остальное — буквально всё — хлам разной степени мерзости.
Сектанты пикселя хуже сектантов айфона.
И да, пиксель теперь немножко не AOSP.
> открыт под лицензией Apache 2.0. На Rust также написаны системные фреймворки BlueOS.Поработать на китайцев бесплатно - а они потом сорец закроют, сказав что лицензия позволяет? Во отличное предложение :D
А че так можно было?
> Поработать на китайцев бесплатно - а они потом сорец закроют, сказав что
> лицензия позволяет? Во отличное предложение :DИ отправят узгоглазого ниндзю чтобы удалить код с твоего компа?
Все эти куракеки "вот-вот и код закроют" разбиваются о 2 факта:
- у тебя останется весь код, в который ты вкладыался
- в мире существуют десятки проектов с миллионами пользователей, который никто не закрывает. Например AOSP и хромиум.
> - у тебя останется весь код, в который ты вкладыалсяИ нулевая пользовательская база. Что в большинстве случаев ставит крест на любые потуги.
> - в мире существуют десятки проектов с миллионами пользователей, который никто не закрывает. Например AOSP и хромиум.
А есть те которые закрыли.
Если риск закрытия не критичен - нормально. Если критичен - стоит сто раз подумать.
> И нулевая пользовательская база. Что в большинстве случаев ставит крест на любые потуги.В смысле нулевая?
Это уже какие-то придумки.> А есть те которые закрыли.
А есть сотни GPL проектов авторы которых на них забили.
Дальше что?> Если риск закрытия не критичен - нормально. Если критичен - стоит сто раз подумать.
А как определяется критичность?
Автор может свой код закрыть независимо от лицензии.
Он может найти нормальную работу, жениться или помереть, как сделал создатель ВИМ-бибикалки.Все равно у вас останется самый свежий код на момент события.
Пока что всё с точностью до наоборот, это китайские товарищи поработали и дали всем, в том числе тебе ядро, которые ты можешь взять и закрыть, вот но дух свободы.
я учусь расту потихоньку, пишу шаред библиотеку спокойно. Недавно обновил компилятор раста и он теперь функцию extern "C" инструкцию no_mangle требует обернуть в unsafe. Чёт мотивации не прибавляется продолжать.
> я учусь расту потихоньку, пишу шаред библиотеку спокойно. Недавно обновил компилятор раста и он теперь функцию extern "C" инструкцию no_mangle требует обернуть в unsafe.Ты про это rust-lang.github.io/rfcs/3325-unsafe-attributes.html ?
Ну там написано по какой причине принято такое решение.> Чёт мотивации не прибавляется продолжать.
Хм.. не продолжай.
Вот серьезно. Тебя же никто не заставляет.
Я это читал. Если ты плохо понял переведу: unsafe декларация перед no_mangle добавлена исключительно с целью чтобы программист расписался что понимает что означает эта инструкция и к каким проблемам оно может привести. В коде компиляции ничего не меняется абсолютно. Просто блок тем, кто не расписался в знании. Это полный аналог журнала ознакомления по Технике безопасности, который нужно подписывать перед допуском на опасные работы, вахтерство в чистом виде
а это идея, можно на любом языке оборачивать куски кода в unsafe и говорить "бачили очі, що купували"
у меня лучше идея. нужно чтобы компилятор при обнаружении потенциально опасной инструкции выдавал вопрос о том, чем опасна данная инструкция с 4 вариантами ответа. Только при выборе правильно ответа компиляция будет продолжена.
> Я это читал. Если ты плохо понял переведуЯ тоже это читал. И понял хорошо.
> добавлена исключительно с целью чтобы программист расписался что понимает что означает эта инструкция и к каким проблемам оно может привести.
И это отлично!
Потому что людям свойственно ошибаться.> Это полный аналог журнала ознакомления по Технике безопасности, который
> нужно подписывать перед допуском на опасные работы, вахтерство в чистом видеЕсли для тебя журнал это вахтерство, то лучше вообще не программировать)
А то еще заставят проходить ревью pull-request'ов, так снежинка расстроится, что ей не доверяют и расплачется.
> Это полный аналог журнала ознакомления по Технике безопасности, который нужно подписывать перед допуском на опасные работы, вахтерство в чистом видеЯ не знаком, с журналом ознакомления по Технике безопасности, но то что делает раст здесь -- это естественное следствие его общей стратегии: чем больше граблей разложено на каком-то пути, тем сложнее синтаксисы придётся использовать, чтобы по этому пути идти. Самый простой пример -- это Index.
В C++, чтобы индексировать массив с проверкой на выход за границы, надо использовать не operator[], а какую-то функцию. Поскольку [] использовать проще, программисты используют [], несмотря на то, что в подавляющем большинстве ситуаций проверка индекса не помешает, и если она будет применяться в этом подавляющем большинстве ситуаций, то багов в программе станет резко меньше. Чтобы таких ситуаций не возникало, в расте Index (он же operator[]) выполняет проверку, а вот если тебе надо без проверки, то придётся использовать метод get_unchecked заворачивая его вызов в unsafe. Результат? get_unchecked используется только тогда, когда очень-очень-очень надо. Когда просто очень-очень надо, люди предпочитают забить и продолжить использовать [].
В описываемой же тобою ситуации, не надо использовать #[no_mangle] если тебе не надо "очень-очень-очень". И unsafe добавляет тебе дополнительный заборчик, чтобы тебе через него каждый раз перепрыгивать надо было бы.
Это стратегия языка, против неё возникать бессмысленно. Если тебя она не устраивает, попробуй zig вместо rust'а.
>Если тебя она не устраивает, попробуй zig вместо rust'а.А нормальные, проверенные временем языки не пробовали использовать? Обязательно надо что-то нишевое и никому не нужное использовать, чтобы быть нетакусиками?
Нормальных, проверенных временем я не видел. Но просто проверенные временем я пробовал использовать 20+ лет. Они разочаровывают, и сколько их не используй, никак не отделаться от желания поискать что-нибудь получше.
Пиши на Лиспе. Лисп никогда не разочарует. Особенно если этот Лисп Clojure.
Вот честно, не стоит, потрать жизнь на что-то лучше.
Например, в выискивании очередной CVE. Да? Это ж, поди, любимое занятие программистов на довольно распространённом языке программирования. И тогда можно будет сказать, что жизнь удалась.
Если на языке ничего не написано, то и проблем там нет, да?
Да там и на написаном регулярные сегфолты, гы.
В ваших фантазиях, разве что.
Слона-то я и не заметил, да? Гугл, Майкрософт, Дропбокс, Дискорд, Клаудфлэр, Вольво - их софт, который используется, наверное, половиной жителей Земли - это "ничего"?
Они все используют баш!
Короче, сначала купите эти часы, а потом уже концпелируйте на них хоть геньту, хоть хурд без соли.
это даже не ос.
это прошивка для микроконтроллера с минимальным функционалом. надо очень постараться чтоб там хоть что-то сломать.
Почему-то KasperskyOS написан на C++, а не на Rust'е
> KasperskyOSчто это
KasperskyOS
KasperskyOS — проприетарная частично POSIX-совместимая микроядерная операционная система. Она предназначена для разработки ИТ-продуктов для отраслей с повышенными требованиями к кибербезопасности, надежности и предсказуемости работы.Цель KasperskyOS — обеспечить защиту ИТ-систем от вредоносного кода и эксплуатации уязвимостей, а также снизить риски, связанные с ошибками в коде, случайными или намеренными повреждающими действиями.
Разработку KasperskyOS ведёт «Лаборатория Касперского». Операционная система не является модификацией какой-либо из существующих ОС; в её основе — микроядро собственной разработки, написанное с нуля, без использования сторонних библиотек и кода.
> Она предназначена для разработки ИТ-продуктов для отраслей с повышенными требованиями к кибербезопасности, надежности и предсказуемости работы.Если это всё правда, тогда почему в Аэрофлот до сих пор используют Windows XP?
KasperskyOS хоть кто-то видел вообще хоть где-то?
Такую же статью на вики можно и про BolgenOS состряпать
>Она предназначена для разработки ИТ-продуктов для отраслей с повышенными требованиями к кибербезопасности, надежности и предсказуемости работы.Ну и как с историями успеха по внедрению?
Просьба обратить внимание на процессор - core2duo
https://ru.wikipedia.org/wiki/KasperskyOS#/media/%D0�...
лучше б спеки с протоколами своих часов открыли
> код ядра BlueOSТолько ядро? А дрова?
