Группа разработчиков из Китая развивает ядро Asterinas, написанное на языке Rust и предназначенное для использования в операционных системах общего назначения. Для упрощения интеграции с уже разработанными системными компонентами ядро предоставляет ABI (Application Binary Interface), совместимый с ядром Linux и способный использоваться вместо него. Код проекта распространяется под лицензией MPL (Mozilla Public License)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62061
Ada spark обеспечила бы не только безопасную работу памяти, но и верификацию кода. Не осилили.
Список по каким критериям раст лучше ады.1. Безопасность памяти: Rust использует систему владения, которая предотвращает множество ошибок, связанных с памятью, таких как утечки и гонки данных, без необходимости в сборщиках мусора. Ada/Spark также предлагает безопасность, но Rust реализует эти концепции более гибко и выразительно.
2. Современный синтаксис: Rust имеет более современный и удобочитаемый синтаксис, что облегчает его освоение для новых разработчиков. Это может способствовать более быстрому написанию кода и его обслуживанию в долгосрочной перспективе.
3. Экосистема и сообщество: Rust обладает активным сообществом и богатой экосистемой библиотек (крэтов), что позволяет разработчикам эффективно решать разнообразные задачи. Ada/Spark имеет более ограниченное количество доступных библиотек.
4. Кроссплатформенность: Rust разработан с учетом кроссплатформенной совместимости и отлично работает на различных операционных системах. Это делает его удобным для разработки приложений, которые должны функционировать на разных платформах.
5. Асинхронное программирование: Rust предлагает мощные инструменты для асинхронного программирования, что делает его подходящим для написания высокопроизводительных сетевых приложений. Ada/Spark также поддерживает параллелизм, но Rust имеет более развитые возможности в этой области.
Я тоже могу скопипастить ответ нейронки, как это сделал ты:1. Безопасность и надежность: Ada и Spark предлагают более строгую статическую проверку типов и формальные методы верификации, что делает их более подходящими для разработки критически важных систем, где безопасность и надежность являются ключевыми требованиями.
2. Встроенная поддержка параллелизма и многозадачности: Ada изначально разрабатывалась с учетом параллельных вычислений и многозадачности, что упрощает разработку многопоточных приложений.
3. Зрелость и промышленное применение: Ada и Spark имеют долгую историю использования в промышленности, особенно в аэрокосмической и оборонной отраслях, где они зарекомендовали себя как надежные и проверенные языки.
4. Поддержка реального времени: Ada и Spark предлагают встроенную поддержку реального времени, что делает их более подходящими для разработки систем, где важна предсказуемость и детерминированность.
5. Строгая типизация и модульность: Ada и Spark имеют более строгую типизацию и модульную структуру, что может упростить разработку и поддержку крупных проектов.
6. Формальная верификация: Spark предлагает мощные инструменты для формальной верификации кода, что позволяет доказывать свойства программ и обеспечивать их соответствие спецификациям.
> 1. Безопасность памяти: Rust использует систему владения, которая предотвращает множество ошибок, связанных с памятью, таких как утечки и гонки данных, без необходимости в сборщиках мусора. Ada/Spark также предлагает безопасность, но Rust реализует эти концепции более гибко и выразительно.Это заслуга С++ного LLVM-бекенда, которым этот "выразительный" брейнфак собирается.
> 2. Современный синтаксис: Rust имеет более современный и удобочитаемый синтаксис, что облегчает его освоение для новых разработчиков. Это может способствовать более быстрому написанию кода и его обслуживанию в долгосрочной перспективе.
Это реально смешно.
> 3. Экосистема и сообщество: Rust обладает активным сообществом и богатой экосистемой библиотек (крэтов), что позволяет разработчикам эффективно решать разнообразные задачи. Ada/Spark имеет более ограниченное количество доступных библиотек.
Активно сообщество, к-е так ничего до сих пор не родило, только рассуждают и всячески о себе заявляют.
> 4. Кроссплатформенность: Rust разработан с учетом кроссплатформенной совместимости и отлично работает на различных операционных системах. Это делает его удобным для разработки приложений, которые должны функционировать на разных платформах.
Это заслуга С++ного LLVM-бекенда, которым этот "выразительный" брейнфак собирается.
> 5. Асинхронное программирование: Rust предлагает мощные инструменты для асинхронного программирования, что делает его подходящим для написания высокопроизводительных сетевых приложений. Ada/Spark также поддерживает параллелизм, но Rust имеет более развитые возможности в этой области.
Это заслуга С++ного LLVM-бекенда, которым этот "выразительный" брейнфак собирается.
Поговорил с ботом - день прошел не зря.
>Неудобно? Значит, пора учиться, а не сваливать на инструменты.Вот на Brainfuck неудобно писать. Ну чтож, значит, пора научиться, а не сваливать на инструмент.
>>Неудобно? Значит, пора учиться, а не сваливать на инструменты.
> Вот на Brainfuck неудобно писать. Ну чтож, значит, пора научиться, а не
> сваливать на инструмент.Что теряешься, Анон? Спроси у бота чем брейнфак лучше вон тех - и тоже запость сюда список преимуществ :)
1. А вот и нет! Rust — это не просто оболочка вокруг LLVM. Его концепции и философия разрабатывались независимо от C++.
2. Не переоценивай роль LLVM! Это лишь инструмент. Сам язык задания и его безопасность — это заслуга разработчиков Rust.
3. В чем проблема? Если LLVM помогает, то это только плюс! Какой язык не использует мощные инструменты для оптимизации?
4. Выразительность языка — это его сила, а не слабость. Проблема, если не понимаешь, как это работает.
5. Неудобно? Значит, пора учиться, а не сваливать на инструменты. Rust даёт больше возможностей, чем ты думаешь.
>Rust имеет более современный и удобочитаемый синтаксис, что облегчает его освоение для новых разработчиковПо этому пункту Линус Торвальдс с вами не согласился.
Так это по сравнению с адой, а не си. Посмотри синтаксис ады там адок. Особенно для питониста.
Аду Торвальдс пока что даже и не рассматривал. А вот некоторое время существования Rust в ядре уже дало ему повод сделать некоторые выводы.
"Пока что"... Оптимист! Я не имел счастья разрабатывать на Аде, но, посмотрев примеры, предполагаю, что добровольно на таком никто не возьмётся программировать. Для армии, может, и подойдёт.А вот Rust люди любят, в него влюбляются: https://habr.com/ru/companies/macloud/articles/557792
дочитал до "Для начала загрузим rustup..." и команды для его запуска
вы на улице тоже всё в рот тащите неглядя?
Судя по всему только любят, а не пишут
Торвальдс-то как раз не против Rust в ядре.
Он моргнул дважды! (С)
Стало быть он давал интервью с элктрошокером в @ - Сатья большой перестраховщик! и знает толк(С):)
Скорее, после зачисления платежа ;)
1. Формальная верификация: СПАРК разработан с учетом требований формальной верификации. Она позволяет разработчикам доказывать отсутствие определенных классов ошибок (таких как исключения во время выполнения, гонки данных и переполнения буфера) с помощью формальных методов. Это может привести к повышению надежности критически важных систем, например, используемых в аэрокосмической промышленности и медицине.
2. Безопасность и надежность: СПАРК обеспечивает строгую типизацию и предоставляет функции, которые помогают предотвратить распространенные ошибки программирования. Его дизайн поощряет написание безопасного кода, что может иметь решающее значение в системах с высокой степенью надежности. Хотя Rust также делает упор на безопасность, возможности формальной верификации СПАРК обеспечивают дополнительный уровень гарантии.
3. Детерминированное поведение: Дизайн СПАРК способствует детерминированному поведению, что очень важно для приложений реального времени и приложений, критичных к безопасности. Возможности языка помогают обеспечить предсказуемость поведения программы, что может быть сложнее гарантировать в Rust из-за его модели параллелизма.
4. Отсутствие исключений во время выполнения: СПАРК разработан для устранения исключений во время выполнения, которые могут быть источником непредсказуемости в системах. Это особенно важно для критически важных приложений, где неожиданное поведение может иметь серьезные последствия.
5. Программирование на основе контрактов: СПАРК поддерживает программирование на основе контрактов, позволяя разработчикам указывать предварительные и последующие условия, а также инварианты. Это может повысить надежность и удобство сопровождения кода, поскольку позволяет определить предполагаемое поведение функций.6. Устаревшие и специфичные для конкретного домена приложения: СПАРК имеет долгую историю применения в таких областях, как аэрокосмическая, оборонная и автомобильная промышленность, где часто требуются формальные методы. Для проектов в этих областях СПАРК может быть более подходящим из-за его устоявшегося использования и наличия инструментов для формальной верификации.
7. Инструментарий для верификации: СПАРК поставляется со специализированными инструментами для формальной верификации, такими как набор инструментов SPARK Pro, который может анализировать код на предмет корректности. Хотя в Rust есть инструменты для статического анализа и тестирования, возможности формальной верификации в SPARK более развиты.
Иными словами, раст совершенно неконкурентоспособен и ему нечего предложить, кроме базвордов, таких как "современный" синтаксис, "сильное" сообщество и "отличная" поддержка параллельного программирования.
1. Ой, формальная что? Это звучит как что-то из научного фильма! Но, наверное, если это помогает не ошибаться, то круто!2. Безопасность — это важно, особенно когда речь идет о жизни и смерти! Но я не знаю, что такое строгая типизация, звучит сложно!
3. Детерминированное поведение? Это как когда ты всегда знаешь, что будет на ужин? Звучит удобно!
4. Убрать исключения? О, боже, это как убрать слезы из комедии! Значит, все будет предсказуемо?
5. Программирование на основе контрактов? Это как когда ты на кухне записываешь, что готовишь по рецепту! Умно, наверное!
6. Устаревшие вещи — это как старая сумка из гардероба! Но если она работает в аэрокосмосе, значит, она, наверное, супер надёжная!
7. Инструменты для верификации? Как отвертка для программистов! Если они помогают проверять, то здорово!
В целом, звучит, как будто Раст просто не дотягивает до сложности всего этого!
1. А можно понятным техническим языком, что такое выразительно? А то, лично для меня, макросы masm выразительны, практически впрямую транслируются в диалекты русского языка.
2. Синтаксис стоит далеко не на первом месте при долгосрочном обслуживании, раньше стоит понимание прикладной задачи и архитектура решения, я могу на Бейсике сварганить такую хрень, что черт ногу сломит, могу на Perl написать прозрачный и понятный код, есть код на асме он в продакшене
4. Сообщество штука динамичная сегодня оно активное, завтра пассивное, возвращаемся к долгосрочной перспективе.
5. Ada тоже кросплатформенное решение. Более того, сама по себе кросплатформенность мало о чем говорит, зависит от того, насколько полно решение работает на разных платформах.
6. Давайте вернемся к технике, мощные инструменты, развитые возможности это не технические параметры, а скорее продажная шелуха, вы на примерах свою мысль продемонстрировать можете?
> 4. Кроссплатформенность:Вот тут поподробнее, пожалуйста! Как мне собрать компилятор раста для архитектуры, для которой мозилла не выложила уже готовый бинарник?
Мозилла уже миллион лет не имеет отношения к расту.
> Мозилла уже миллион лет не имеет отношения к расту.Ну не завезли еще в отдаленные вербовочные пункты "Военства Супротив Раста" современные методички ...
Но ответа не последовало.
> Но ответа не последовало.О Великий Воен, судя по постановке вопроса - ответ вам все равно никуда не уперся (потому что из вопроса неясно, подразумевалась ли кросскомпиляция или добавление нового "таргета" или вообще, полноценное портирование компилятора - только вот при втором еще и стд. либу желательно портировать). Ну и да, есть такая штука, как доки - их даже не растовцы придумали:
https://rustc-dev-guide.rust-lang.org/building/how-to-build-...
Это ChatGPT нагенерил? Особеноно про "Rust предлагает мощные инструменты для асинхронного программирования" смешно.
Естественно. Собственно, если асинхронные генераторы нормальные когда-нибудь завезут, язык станет вполне юзабельным. Но, что-то у меня сомнения уже, что это когда-то случится. А без этого язык жуткое легаси, на котором писать прикладной код невозможно.
1. Оценочное суждение. Что такое "более гибко" и "выразительно"? Это можно как-то численно оценить?
2. С каких пор закорючки и другие символы более удобочитаемые? Только потому, что Си эту практику ввёл?
3. Есть сравнение в цифрах?
4. На сколько знаю, Ada есть под GCC и LLVM.
5. Что понимается под "развитыми возможностями"?
> Ada spark обеспечила бы не только безопасную работу памяти, но и верификацию
> кода. Не осилили.Ну дык - так и быть, разрешаю вместо очередных комментов на опеннете "как надо было правильно!" показать личным примером (или спонсировать-организовать единомышленников) все преимущества Ада ...
Или очередной опеннетный "не тактик, а стратег!"?
Пожалуйста:
https://ironclad.nongnu.org/Ironclad is a formally verified, hard real-time capable kernel for general-purpose and embedded uses, written in SPARK and Ada. It is comprised of 100% free software, free in the sense that it respects the user’s freedom.
Some of the supported features are:
A familiar POSIX-compatible interface.
True simultaneous preemptive multitasking.
Advanced cryptography and a security-centered architecture.
Mandatory Access Control (MAC).
Highly configurable, hard real-time scheduling.
Support for several architectures and boards.
только Haskell/Agda
галюцинации чатжопаты в топку
У меня к расту только один вопрос: что мешало сделать C-подобный синтаксис? Зачем постоянно пытаются изобретать кривые велосипеды для годных технологий?
Так-же и с GoLang, очень хорошая технология, но жуткий синтаксис с неисправимыми болячками.
Ваш вопрос о синтаксисе Rust вполне оправдан. Разработчики стремились создать язык, который бы сочетал безопасность и функциональность, внося новшества. Синтаксис Rust может показаться сложным из-за его особенностей управления памятью и параллелизма, но эти меры направлены на избегание распространённых ошибок, делающих код более надежным.
Хорошая попытка, ИИ. К счастью, это все еще очень заметно даже невооруженным глазом.
Что тебе заметно? Тут половина комментов ИИ ты только один вычислил. Короткие комменты вычислить практически невозможном.
ИИ вычислить проще простого: формальная грамотность + абсолютная бессмысленность.
ИИ не существует.
Зомбированный евангилист с промытыми мозгами чем не ИИ ?))
В сообществе Раст-евангелистов все настолько плохо, что даже пришлось привлечь GPT.
Задуматся что с синтаксисом C++ что не ладно корона не позволяет?
У Rust C-подобный синтаксис во всех местах, где только возможно.
Ну, разве что, основанный на блоках кода, оформляемых скобочками {...}
>Ну, разве что, основанный на блоках кода, оформляемых скобочками {...}Ну вот, вы уже и торгуетесь. Глядишь, прочитаете книжку "Idiomatic Rust".
С Растом да, но что с Golang-то не так? У Го как раз-таки хороший и удобный Си-подобный синтаксис. Не даром Кен Томпсон был в команде разработки
golang это вендорлок, нет смысла тратить время на его обсуждение
Какой вендорлок? Го - свободное ПО, крупных реализаций компилятора даже две, есть от GCC. Репозитория пакетов типа cargo нет. Где лок-то?
Ты бы почаще в методичку эксперта заглядывал, чтобы такие вопрос не задавать.1) Го для глупых программистов 2) его сделал гугл чтобы экономить на них 3) поэтому на го программируют те кто не умеет программировать 4) это выгодно гуглу 5) поэтому го поддерживается гуглом 6) поэтому го зависит от гугла 7) Гугл это M$ №2
Мне пофиг что там выгодно Гуглу, если оно даёт выгоду и мне. Язык рабочий, дела делаются, программы пишутся. А не только сказки про безопасную память сказываются, как у некоторых
> есть от GCCЧто даже в пробе его используете? Нет? А толку тогда говорить об этом.
Дарю=====
Copyright (c) 2009 The Go Authors. All rights reserved.Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of Google Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Разве речь шла про лицензию? Нет.
В таком формате все вендер-лоск. Где-то компания "вендер-лоск", где-то человек или группа.>> Разве речь шла про лицензию? Нет.
Пятками назад? ну-ну
> В таком формате все вендер-лоскТак и где Лок? Редистрибьютить можно, форкать можно. Да все почти можно, что может понадобиться, это ж BSD license
И где тут вендор-лок? Как раз тут текст одной из самых свободных лицензий - 3 clause BSD
> golang это вендорлок, нет смысла тратить время на его обсуждениеУдивительно ... но они нас боятся :)
Никому не говори - GCC работают на Go и оно в принципе уже работает. Скоро включат в коллкшен.
Не бойтесь, мы вас по доброму от-иго-гошим, даже нежно! ;-D
> С Растом да, но что с Golang-то не так? У Го как раз-таки хороший и удобный Си-подобный синтаксис. Не даром Кен Томпсон был в команде разработкиЭтот тот язык, где неиспользуемая переменная приводит к ошибке компиляции? Или где форматирование не по гайдам тоже?
Насчет переменной - да, именно так. И что в этом плохого? Странная предъява. Если вдруг нужно реально не использовать какую-то переменную, явно присваиваете в _. Если нужно импортировать пакет без побочных эффектов, аналогично, import _ "package"Насчет форматирования - это не актуально, потому что форматирование автоматически делается по стандарту утилитой или твоей IDEшкой. Впрочем, я прогал и без IDE, и ошибок за форматирование никаких никогда не было, это не Питон всё-таки
> Насчет переменной - да, именно так. И что в этом плохого? Странная
> предъява. Если вдруг нужно реально не использовать какую-то переменную, явно присваиваете
> в _. Если нужно импортировать пакет без побочных эффектов, аналогично, import
> _ "package"При отладке временные неиспользуемые переменные - это ок. В нормальных языках это warning.
> Насчет форматирования - это не актуально, потому что форматирование автоматически делается
> по стандарту утилитой или твоей IDEшкой. Впрочем, я прогал и без
> IDE, и ошибок за форматирование никаких никогда не было,Автоматическое форматирование не отменяет факта, что я могу писать как хочу. clang-format тоже может код отформатировать, но до этого его можно написать и скомпилить в любом стиле.
> это не
> Питон всё-такиОткрывающую скобку нельзя разместить на след. строке из-за особенностей парсера
> For instance, the opening brace of a function cannot appear on a line by itself.
> При отладке временные неиспользуемые переменные - это ок. В нормальных языках это warning.Ну опять же, добавите _ = если так уж надо, ничего страшного. Обычно всё равно советуют компилировать, что ворнинг = ошибки
> Автоматическое форматирование не отменяет факта, что я могу писать как хочу.
И вот зачем вам эта свобода "писать как хочу"? Чтобы что? Вам задачу решать или писать как хочется? Не знаю, вот на мой взгляд эти все решения в Go - пример максимального прагматизма. Язык сосредоточен на том, чтобы решать задачи и не было ничего лишнего. Ни дум о форматировании, ни висящих ненужных переменных
>> При отладке временные неиспользуемые переменные - это ок. В нормальных языках это warning.
> Ну опять же, добавите _ = если так уж надо, ничего страшного.
> Обычно всё равно советуют компилировать, что ворнинг = ошибкиГде советуют? У нормальных языков есть разные режимы сборки. В прод — да, в дев — не обязательно.
>> Автоматическое форматирование не отменяет факта, что я могу писать как хочу.
> И вот зачем вам эта свобода "писать как хочу"? Чтобы что? Вам
> задачу решать или писать как хочется? Не знаю, вот на мой
> взгляд эти все решения в Go - пример максимального прагматизмаКак раз таки максимальные ограничения — это не про свободу разработки. Но как метод борьбы с дешевыми Кодманками работает.
> Как раз таки максимальные ограничения — это не про свободу разработки.Ну вот о чем и речь, нужна не свобода разработки, нужно выполнение задач. И в этом ключе я считаю правильной философию, что инструмент должен иметь ровно те возможности, которые нужны и ни фичей больше. Это как принцип, что не нужно сидеть под админом
>> Как раз таки максимальные ограничения — это не про свободу разработки.
> Ну вот о чем и речь, нужна не свобода разработки, нужно выполнение
> задач. И в этом ключе я считаю правильной философию, что инструмент
> должен иметь ровно те возможности, которые нужны и ни фичей больше.Смотря для кого. Для конторы, чтобы индусы писали код и шаг влево и вправо растрел, ок получилось.
> Это как принцип, что не нужно сидеть под админом
Принцип админа "больше возможностей, требуют большей ответственности". Тут же возможностей просто не дают. Потому что опять таки зачем индусам давать админа.
> Ну опять же, добавите _ = если так уж надо, ничего страшногоВот есть у меня файл на 500 строк, где-то внизу вызов импортированной функции, я его закомментировал , потому что он временно не нужен, идёт процесс разработки и я не намерен фиксировать такой код. И тут он мне говорит, а вот фиг тебе, неиспользуемый импорт. И вот я как примат с пальмы должен скакать по коду и приводить его в конечный вид, но это НЕ конечный вид!
В ту же копилку можно скинуть требование писать комментарий к каждой публичной сущности, из-за чего во многих проектах совершенно прекрасные комментарии в духе
// это мост
Мост
Комментарии к каждой публичной сущности писать необязательно, уж во всяком случае ошибок компиляции от этого нет. Насчет импортов - ну у меня ИДЕ сама приводит, лишние импорты убивает, но в целом ну да - надо закомментировать или _ поставить. Кто-то может спорить, что получилось топорно, но в целом язык годный, мои задачи решает, и здравый смысл в этих решениях я вижу и принимаю
Я вдогонку еще вот что скажу. Я на Go профессионально пишу 3 года уже - вы не за те вещи его ругаете. То, за что вы его ругаете - за это я бы похвалил как раз. А вот действительно слабые моменты вы упускаете из виду
> Я вдогонку еще вот что скажу. Я на Go профессионально пишу 3
> года уже - вы не за те вещи его ругаете. То,
> за что вы его ругаете - за это я бы похвалил
> как раз. А вот действительно слабые моменты вы упускаете из видуПро отсутсвие нормальной системы типов, дурацкую обработку ошибок, паузы в гц?
С типами да, они слабоваты. Обработка ошибок - скорее да, хотя исключения мне не очень нравятся. Обработка ошибок болит вот еще в дополнение с отсуствием поддержки кортежей как типов. Насчет пауз в ГЦ не скажу, а вот тупняки в C-Go интеропе имеются
Как только вы начинаете использовать препоцессор - начинается лютый оверинжиниринг.
Тут дело не в синтаксисе, а привычке с ним работать. Если работаешь с С-подобными языками, то работа с Go или Rust может казаться отвратной из-за непривычных конструкций. (Пы.Сы: Rust на самом деле довольно сильно похож по синтаксису к C/C++)
>У меня к расту только один вопрос: что мешало сделать C-подобный синтаксис?Странная претензия. Rust входит в число языков программирования с Си-подобным синтаксисом.
А если конкретнее? Например, могу пояснить, почему был выбран синтаксис функции с ключевым словом 'fn', а не такой, как в Си.
> Например, могу пояснить, почему был выбран синтаксис функции с ключевым словом 'fn', а не такой, как в Си.А почему, действительно?
>А почему, действительно?Однозначность. Представим себе, что надо нагрепать в C++-проекте все функции...
Функций?
Указателей на функции?
Функторов?
Лямбд?
>>А почему, действительно?
> Однозначность. Представим себе, что надо нагрепать в C++-проекте все функции...А. Да... Еще методы и указатели на методы?
Что грепать собрался?
> позволяет писать классный код!Толпа требует прувов!
Вы сиподобный синтаксис видели?
char *(*(**foo[][8])())[];
[=, *this]{ };
[&, i]{};
A b(c);
A b(c d);
у Go - тяжкое наследие языка Limbo, который использовался в plan9 ОС. (со-)Автор всех этих вещей - Роб Пайк.
Рассказы про "жуткий синтаксис" этих языков сразу указывают, что человек малость не в теме :D1. Синтаксис Rust очень близок по стилю к синтаксису Си++. В нем единственно реально неудачная вещь - это задание времени жизни (к счастью, это в реальном коде требуется делать достаточно редко).
2. Синтаксис GoLang очень простой и понятный, единственная реальная претензия - требование писать открывающую фигурную скобку на той же строке, где находится if, for, название структуры/функции и т.п.
Опять нытьё про синтаксис. Ничего нового.
> с неисправимыми болячками.Вы занаете самый главный принцип в ветеринарии?
.
.
.
Лекарство не должно стоить больше чем новый пациент :)
> намерен уже в этом году добиться уровня, пригодного для широкого использования в виртуальных машинах с архитектурой x86-64Ага. Значит как и все проекты на rust, пока не доделан.
> Начиная со следующего года основное внимание планируют переключить на реализацию поддержки оборудования и других архитектур CPU
А вот это зря. Значит и не доделают.
Вот запуск в одной архитектуре с одним набором оборудования (в данном случае виртуальных машин) - задача которая rust'у по плечу.
Как только от неё отойдут - утонут в лавине кода.
>> намерен уже в этом году добиться уровня, пригодного для широкого использования в виртуальных машинах с архитектурой x86-64
> Ага. Значит как и все проекты на rust, пока не доделан.Если в проект не вносят изменения, то этот некрокод уже никому не нужен)
Ну и обобщение "как и все проекты на rust" классическая манипуляция.> А вот это зря. Значит и не доделают.
Миллиард китайцев и не доделают?
> Вот запуск в одной архитектуре с одним набором оборудования (в данном случае виртуальных машин) - задача которая rust'у по плечу.
> Как только от неё отойдут - утонут в лавине кода.Гугл как-то не утонул, и амазон тоже.
Хотя может китайцам достаточно одной архитектуры лонгсунги)
> Если в проект не вносят изменения, то этот некрокод уже никому не нужен)Тут речь о другом. Он еще не работает на виртуалке. Только собираются дожелать.
> Ну и обобщение "как и все проекты на rust" классическая манипуляция.
Это деформация из-за новостей опен-нет про очередных переписчиков которые или собираются достигнуть паритета или даже не собираются заявляя об избыточности функциональности оригинала.
Все вопросы к тем кто эти новости писал.
> Миллиард китайцев и не доделают?
У них сейчас новая игрушка от Ху... кхм Хуавея.
> Гугл как-то не утонул, и амазон тоже.
Они доделали? Или все еще делают?
> Хотя может китайцам достаточно одной архитектуры лонгсунги)
Судя по новости, кто то идеально выбрал нишу для rust: работа в виртуалке прокладкой.
Но пришел менеджер и все испортил.
> Это деформация из-за новостей опен-нет про очередных переписчиков которые или собираются
> достигнуть паритета или даже не собираются заявляя об избыточности функциональности оригинала.Ну, пожелаем им успеха.
У каждого свое хобби.>> Гугл как-то не утонул, и амазон тоже.
> Они доделали? Или все еще делают?Они сделали достаточно, чтобы код отправился к пользователям.
И работал у миллионах юзеров андроида.
У клоудфари тоже работает.Ты лучше ответь, ядро линукс оно уже доделано или еще нет)?
> Они сделали достаточно, чтобы код отправился к пользователям.И дал он преимущества этим пользователям?
Или пока бонусы получает только менеджмент, который может гнуть пальцы ни в чем не разбираясь, но сильно надувая щеки.
> Ты лучше ответь, ядро линукс оно уже доделано или еще нет)?
Сравнил полностью написанное ядро с кусочками переписанного.
Слабая попытка.
> И дал он преимущества этим пользователям?Да. Меньше ошибок и уязвимостей, меньше шансов что товй телефон ломанут прислав специально оформленную картинку или видео.
Следовательно пользователям лучше.Вот можешь почитать security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
А вот относительно старая статья про 13 дроид security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
С хорошим показателем
"To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code."> Сравнил полностью написанное ядро с кусочками переписанного.
Так "полностью написанное" или нет?
А когда версия 1.0 вышла, уже было "полностью" или еще кучу версий просто от нечего делать дописали?> Слабая попытка.
Ты вертишься как уж на сковородке, а смотреть приятно)
И это я молчу про регулярные дыры с повышением привилегий или запуском левого кода.
> С хорошим показателемАга. Значит менеджеры щеки надувают.
И дальше:
> А когда версия 1.0 вышла, уже было "полностью" или еще кучу версий просто от нечего делать дописали?
А затем:
> Ты вертишься как уж на сковородке, а смотреть приятно)
Явно видно, что осознаешь свое положение.
Сравнивать полностью функциональное ядро и кусочки кода. А затем сводить тему на версию 1.0.Красавец.
Так доделал google, или нет?
> Ага. Значит менеджеры щеки надувают.Т.е для тебя отсутсвите багов это "менеджеры щеки надувают"?
Твоя логика поражает воображение.
А CVEшки менеджеры находят или может они их пишут?> Явно видно, что осознаешь свое положение.
> Сравнивать полностью функциональное ядро и кусочки кода. А затем сводить тему на версию 1.0.Раз у тебя проблемы с пониманием спрошу еще раз, постараюсь максимально прямо:
ядро версии 6.11 это "функциональное ядро" и в него не придется дописывать код или нет ?> Красавец.
Конечно.
> Так доделал google, или нет?
Полностью? Нет.
Но стало ли лучше для юзеров? Да.
Так же как и ядро. Или любая другая программа.Но твой глупейший вброс "Значит как и все проекты на rust, пока не доделан" с обобщением, так и остался вбросом.
Старайся лучше.
Я спрашивал что получили пользователи. Меньше написанного кода - меньше багов.
И толстые щеки у менеджера.> в него не придется дописывать код или нет ?
Придется или нет - не важно. Важно полнота. Да оно полностью завершенное - рабочее.
Кусочки кода по определению не могут быть полностью завершенными.> Полностью? Нет.
> Но стало ли лучше для юзеров? Да.Это было в отчетах менеджеров которые своими таблицами оправдывали свое решение перед начальством и акционерами?
> Я спрашивал что получили пользователи. Меньше написанного кода - меньше багов.Тогда ты наверное советуешь пользователям какой-то FreeDOS?
Типа чем меньше кода, тем меньше багов.
У тебя просто генитальная логика.> И толстые щеки у менеджера.
Возможно.
Тебя менеджер чем-то обидел? Ну там мамку твою из семьи увел или на ногу наступил и не извинился?
Откуда столько желчи?> Придется или нет - не важно. Важно полнота. Да оно полностью завершенное - рабочее.
Ядро в котором есть такое "позволяющая локальному пользователю выполнить код на уровне ядра и поднять свои привилегии в системе" (opennet.ru/opennews/art.shtml?num=60860)
или эпичные "уязвимости, которые позволяют удалённо без прохождения аутентификации добиться выполнения своего кода с правами ядра" (opennet.ru/opennews/art.shtml?num=60668)это еще "рабочее" или уже ближе к "кусок овнокода"?
> Это было в отчетах менеджеров которые своими таблицами оправдывали свое решение перед начальством и акционерами?
Не знаю. Это у тебя нездоровый интерес к менеджерам.
То что там решают акционеры меня мало волнует.
А меня интересует, чтобы код был не такой дырявый как был раньше.
> Тогда ты наверное советуешь пользователям какой-то FreeDOS?За мыслью уследить не смог. Прости. Я не телепат.
> Откуда столько желчи?
Причем тут желчь? Я вижу реальность. В которой менеджеры заинтересованны в построении карьеры, в срубании бабла по-быстрому или в потоплении конкурентов. Практически никогда решения менеджеров крупных корпораций не основаны на пользе проекту.
> это еще "рабочее" или уже ближе к "кусок овнокода"?
Вот совершенно левая попытка подменить понятия. Код работает. Свою функцию выполняет. Уязвимости и ошибки никак не влияют на его завршенность.
> Не знаю. Это у тебя нездоровый интерес к менеджерам.
А какой интерес здоровый? Вообще не замечать? Или делать вид что не замечаешь?
> То что там решают акционеры меня мало волнует.
> А меня интересует, чтобы код был не такой дырявый как был раньше.Религиозные фанатики только об этом и говорят. О приходе миссии.
Одна проблема, увидеть его негде. Просто нет мест в которые бы он пришел. Только везде хотя бы на пол шишечки запихнуть его пытаются.
> За мыслью уследить не смог. Прости.Не страшно. Я вижу что ты стараешься как можешь.
Ты написал "Меньше написанного кода - меньше багов."
Следует ли из этого, что "программы где меньше всего кода - лучше"? Или нет?> Причем тут желчь? Я вижу реальность. В которой менеджеры заинтересованны в построении карьеры, в срубании бабла по-быстрому или в потоплении конкурентов.
Хм.. а что плохого в потоплении конкурентов? Это вполне человеческое действо?
Я вот не вижу примеров "срубании бабла по-быстрому", те менеджеры с которыми мне довелось работать имели стаж в проекте от 8 до почти двух десятков лет.
И они реально волновались за свое детище, при этом не стеснялись просить совета у программеров.
Возможно тебе просто не повезло.> Практически никогда решения менеджеров крупных корпораций не основаны на пользе проекту.
Если это было бы правдой, то крупные корпорации уже разорились.
Но этого не произошло.> Вот совершенно левая попытка подменить понятия. Код работает. Свою функцию выполняет. Уязвимости и ошибки никак не влияют на его завршенность.
Ненене, это ты не подменяй понятия.
Если код должен обеспечивать изоляцию, то любая дырень это не называется "Свою функцию выполняет". Так же как и denial of service.
Ты же не скажешь, что дверь с замком выполняет свою функцию, если по ней можно 3 раза постучать и она откроется)?> А какой интерес здоровый? Вообще не замечать? Или делать вид что не замечаешь?
Не приплетать их без повода.
Ты ж думаешь, что менеджер прокрадывается в офис ночью и овнокодит?> Религиозные фанатики только об этом и говорят. О приходе миссии.
А еще у них кругом теории заговоров, везде поддельные графики и в общем все куплены)
> Одна проблема, увидеть его негде. Просто нет мест в которые бы он пришел. Только везде хотя бы на пол шишечки запихнуть его пытаются.
Открываешь репу андроида и смотришь глазками.
Или репу Pingora или Hickory.
Niri, COSMIC - это все новые проекты, которые кстати уже работают.
> Следует ли из этого, что "программы где меньше всего кода - лучше"? Или нет?Опять подмена понятий. Имеют преимущество, очевидно, же. Меньше кода - легче поддерживать и понимать написанное. Но естественно не всегда.
> Хм.. а что плохого в потоплении конкурентов? Это вполне человеческое действо?
Вместе с проектом своей же компании или вообще своего же отдела?
Конкуренция между менеджерами естественно. И она есть везде и всегда.
Наверх, обычно, пролезают наиболее наглые и безпринцыпные.> Если это было бы правдой, то крупные корпорации уже разорились.
Но этого не произошло.
Для этого ввели систему патентов. Это система бонусов фаворитам королей переделанная в систему бонусов крупному капиталу. В этой системы могут выжить только корпорации. Но они не эффективны. Чего только стоят попытки корпораций создать свои мессенджеры. В итоге покупают чужие наработки.
> Ты же не скажешь, что дверь с замком выполняет свою функцию, если по ней можно 3 раза постучать и она откроется)?
А если подойдут с болгаркой и она откроется? А если с дрелью пару дырок сделают?
Это чистой воды подмена понятий. Ядро работает. Крутится на почти всех серверах и устройствах. Значит функцию свою выполняет.
> Ты ж думаешь, что менеджер прокрадывается в офис ночью и овнокодит?
Отшутиться не получится. Менеджер не разбираясь, но слыша звон, принимает решение об использовании rust. Перед начальством отчитывается о внедрении и собирается получить повышение. Если ничего не внедрять то конкуренты сожрут.
Такова система корпораций.> А еще у них кругом теории заговоров, везде поддельные графики и в общем все куплены)
То есть. Когда у тебя один источник информации, заинтересованный в том, что информация была соответствующая ты веришь этому источнику? Ну... теперь я понял с кем говорю.
> Открываешь репу андроида и смотришь глазками.
То есть у них получилось полностью перейти на rust?
> Или репу Pingora
Что это? Где работает?
> или Hickory.
Что это? Где работает?
> Niri, COSMIC - это все новые проекты, которые кстати уже работают.
А! Новые проекты... А работают то где? Реальное применение хотя бы в значимой доле по сравнению с конкурентами?
Нет?
>> то было в отчетах менеджеров которые своими таблицами оправдывали свое решение перед начальством и акционерами?
> Не знаю. Это у тебя нездоровый интерес к менеджерам.
> То что там решают акционеры меня мало волнует.
> А меня интересует, чтобы код был не такой дырявый как был раньше.И да. Какая разница кого что волнует. Главное достоверность источника информации.
> Но твой глупейший вброс "Значит как и все проекты на rust, пока не доделан" с обобщением, так и остался вбросом.Меньше несите в новости хело ворды. Тогда и не будет таких Фраз. А пока, что ни новость про rust, то недоделка.
В Андроиде есть код на Го?
> Миллиард китайцев и не доделают?Ну ты чё как маленький? Расту в китае ловит нечего, там главный пахан - Си 8-)
> Ага. Значит как и все проекты на rust, пока не доделан.Но CoC.md-то уже есть! Что еще надо для освоения средствов?!
> Вот запуск в одной архитектуре с одним набором оборудования (в данном случае виртуальных машин)
> - задача которая rust'у по плечу.но ресдох...
А в целом новость надо читать (как обычно с новостями про хруст): команда китайских разработчиков с именами из квадратиков собралась начать переписывать линукс на хрусте и уже родила нечто, что канпелируется, но не работает даже на виртуалочке.
Планов у них громадье, дарагие инвесторы, несите денег мешками и побольше мешки выбирайте!
OfftopНейросети убили интернет. Что не топик, то нейроблудство.
То что половина комментов в соцсетях и каналах от таких ботов, это полбеды.
Проблема, что они дальше будут на этом Г. обучаться на следующих итерациях.
Они убили не только профессию рерайтера и копирайтера, но и оставили многих художников и дизайнеров (ремесленников среднего достатка) без работы, а так же подогнали тексты начитываемые блогерами в ютубе под одну кальку, где прям сразу с первых строк понимаешь, что автор даже поленился переписать это всё с нейросетевого на человеческий язык. И да, каждая итерация обучения будет основываться на предыдущем сгенерированном.
они хотябы своё пилят и никому не мешают.
ну и пусть тогда пилят, может что нормальное получится(а нет так нет, нежалко)
Диды поддерживают!
Вот пишут же сами, а не других заставляют.
Удачи ребятам. Клёво будет, если у них получится. А не получится - тоже не плохо - опыта набирутся.
В любом случае продвинут к ответу вопрос - а можно-ли на rust чёнить сложное написать.
Это хорошая новость. Теперь все любители внедриться в ядро могут туда сваливать
>Теперь все любители внедриться в ядро могут туда сваливатьКупи себе свое ядро и там командуй.
А в Linux будут командовать уважаемые платиновые спонсоры.
А вы себе, так понимаю, купили Астра Линукс? Нет, не лицензию на использование, а в собственность? ;)
> А вы себе, так понимаю, купили Астра Линукс? Нет, не лицензию на
> использование, а в собственность? ;)нет, не купил. у меня столько денег нет.
С другой стороны, я им и не говорю что включать в дистриьбутив,а что нет.
Делайте ваши ставки на то, что из этого получится что-то жизнеспособное. Текущий коэффициент 1:2000
Если сабж встроят хотя бы в систему управления кофеваркой это уже будет для него победа.
Новый тип китайского "микроядра": "микроядро" внутри монолитного ядра.
У них микроархитектура в одном адресном пространстве. Защита сервисов и ядра от ненадежного кода возлагается на проверки RUST. В общем, правильно. Ядро Linux тоже предпочитает работать в одном адресном пространстве. Да и подпроцессы имеет. Однако отсутствует явное деление на основу и сервисы и обмен между ними сообщениями. Новая архитектура предполагает, что и пользовательские программы, написанные на Rust, можно будет запускать в том же адресном пространстве: real time user spacePS: genode OS вполне себе здравствует, имеет кучу разных совместимых микроядер. Но до запуска ядра и сервисов в одном адресном пространсте пока не дошло.
> Новая архитектура предполагает, что и пользовательские программы, написанные на Rust, можно будет запускать в том же адресном пространстве: real time user spaceЭ... А если кому-то вздумается сделать свою модификацию rust?
Что бы спойкойно по памяти полазить.
Чего-то непонятно.
> ABI (Application Binary Interface), совместимый с ядром Linux и способный использоваться вместо негоВ линуксе abi постоянно ломается. При этом хак на хаке едет и хаком погоняет.
Т.е. они хотят сделать ядро, такое же, но другое, потому что в первом есть фатальный недостаток. Даже два.
И постоянно это ядро переписывать, потому abi постоянно изменяется.
Отличная инициатива.
Речь идёт о UABI -- ABI используемое программами режима пользователя, а не внутреннее ABI компонентов и модулей ядра. UABI в Линуксе стабильное.
Страшно представить сколько времени такое ядро компилироваться будет.
Нет доверяю Я китайским погромистам (C)
На интуитивном уровне при поиске пакетов избегаю те, где автор(ы) с квадратными именами. Заметил, что он бросают многие репы с багами, тикетами, недоделками - просто бросили и все, как умерли.
А есть еще всякие jin tan'ы - такие еше и уязвимостей напихают
Китайское поделие не всегда, но имеет шанс взлететь, если начальство бьет палками по пяткам.Если это проект "китайских товарищей на доверии", то 100% - забросят.
Шанс что подхватят корпы есть, потому и пиарят. Благо сейчас деглобализация, и прочей.
Короче: пиво, фисташки, чипсики и наблюдаем за попыткой товарищей продаться.
Проблема что как только начальство меняется - палки начинают бить других китайцев и старый проект летит в помойку, потому что никто не помнит этих квадратиков. Кто вон еще помнит - tengine ? А как дысал, как дысал...> Шанс что подхватят корпы есть, потому и пиарят. Благо сейчас деглобализация, и прочей.
нету шанса. Есть шанс что глупые китайские спекулянты деньгами дадут немножко прямщас. Через неделю забудут.
Т.е. нонеймам из квадратиков оно поможет купить плошку риса и смазку для кошкожены, один раз. А нам с тобой толку вообще ровно ноль.
Это не интуитивный уровень, а расистский. Надо отучаться.
Китайцы почти в каждой репе на гитхабе есть. Просто не всегда создатели репы.
И китайскому майору.
А чем это лучше Maestro? Там на начало 2024 года вроде как была реализована поддержка 115 syscalls
Китайцы? Эти смогут.
> Компоненты ядра в Asterinas размещаются в общем адресном пространстве, а безопасность достигается на уровне логического разделения безопасного кода и кода в котором не исключено возникновение проблем с безопасностью.Т.е. если взять обычное ядро Linux, и пометить функции, в которых 100% всё безопасно, то получится то самое логическое разделения безопасного кода.. И ядро сразу станет безопаснее без какой-либо правки кода!
> пометить функции, в которых 100% всё безопасноМетить может только руст, ой, то есть gptchat, ой, ИИ в смысле машина.
Человеку нельзя.
Well yes, but actually no.
Странная у вас справедливость и что же они возьмут и спишут микро ядро того chromium os 77 , а это магические цифры фактически числа бога семь дней. Не нарушает ли это закон бога что грозит последствиями
Если это будет иметь stable API/ABI, то оно имеет шанс заменить Линукс.Zircon не взлетел, Google не дал, может, это взлетит.
Ага, а кто модули ядра для железок им писать будет? Скорее всего, будут лепить внутрядерную прослойку с ABI/API Линукса для использования модулей оного. Ну и приводить в соотвествии там это с каждым мажорным релизом ядра Linux.
А-а, они будут делать совместимость только с ядрами LTS. Так и сам Линукс с LTS неплохо живёт. Вобщем, по затратности человеко-часов ничем не лучше оригинала.
> Ага, а кто модули ядра для железок им писать будет? Скорее всего,
> будут лепить внутрядерную прослойку с ABI/API Линукса для использования модулей оного.
> Ну и приводить в соотвествии там это с каждым мажорным релизом
> ядра Linux.
> А-а, они будут делать совместимость только с ядрами LTS. Так и сам
> Линукс с LTS неплохо живёт. Вобщем, по затратности человеко-часов ничем не
> лучше оригинала.Они с ума сойдут повторять изменения API ядра. Это титаническая неблагодарная работа.
Скорее, будет так: изначально чисто enterprise с поддержкой стандартов (EFI, ACPI, TIMERS, AHCI, NVME, USB 2/3), и популярных сетевых карт.
Потом, если взлетит, ведоры подсуетятся или кто-то портирует драйвера из ОС с более permissive license, i.e. FreeBSD).
// b.
А когда это в линуксе отменили стейбл апи? С этого момента поподробнее.
В ядре есть два API: internal and userspace (aka Linux syscalls).Первое - 100% unstable, Google: Stable API nonsense.
Второе - 100% stable.Все это гуглится за 3 минуты. Почему анонимы задают тупые вопросы - я не знаю.
В Windows internal API стальной стабильно для минимум одной версии ОС, по факту часто гораздо больше.
Некоторые драйверы для win 8 работают в win 10. Win 11 не проверял.
"широкое использование на виртуальных машинах" - это как? Если есть совместимость с линуксом, то в чем проблема запускать на любых машинах?
Может драйверов нет а совместимость бинарная с бинарниками...
дизайн выглядит намного жизнеспособнее redox
Есть ядро написанное на Ada.
Какое?
https://ironclad.nongnu.org/
вот это реально круто. судя по новостям в rss, проект живет.
спасибо за ссылку.
Четыре релиза за прошлый год, ни одного за текущий.Уже не очень живёт
если Вы из тех, кто жизнь измеряет по принципу "сколько раз за годик бафнули версию", то.. идите дальше под новости про systemd !
Зы. причина бугурта в том, что эти <слов цензурных нет> убрали возможность определения работы tomoyo через Condition из за того, что "проект не развивается".
при том, *****, что неапстримовые версии живут активной жизнью, а апстримовая уже 10 дет бьется головой об lsm, безуспешно пытаясь патчи в него протолкнуть для полноценной функциональности путеоснованных MACов.
спрашивается, **** они тебе там, *******, сделают, если, *****, линус рога выставил? ядро **** форкнут?
и это лично поцтеринг сделал.
до стх пор бомбит. вот по такой логике и действуюет "новая волна программистов", как я вижу
а тут все еще проще: некоторые вещи дольше и сложнее реализуются, чем другие.
и в случае с ядрами, это очень ярко выражено. если пройдете по ссылке, то увидите, что у них уже там целый дистрибутив с гуем, исправно функционирующий. но работающий только в qemu.
если превзайдете добрую часть опеннета, пройдя по 2й ссылке на гитхаб, то увидите, что последний коммит в src 2 месяца назад был.
и судя по файлам, что-то мне подсказывает, что активно момент а запуском на чем-то, кроме виртуалок, решается.
Пишут, что Gloire должна нормально работать на любой машине x86, будь то UEFI или BIOS.
SELinux продвигают, поэтому убрали. А жаль.
Кто вкурсе. Что такое SPARK: фреймворк на Ada, расширение Ada?
это язык-надстройка.
Если посмотреть их сайт. То еще не написанное.0.5.0 2023-Oct-31 Not stable
И почти год нет релизов.
Значит и не будет написано.
Попутного им ветра. Пусть расцветают сто цветов, победит сильнейший и всё такое. И, вдогонку, большая просьба — пускай заодно заберут с собой тех сидоров, которые сейчас пихают Rust в ядро.
> Попутного им ветра. Пусть расцветают сто цветов, победит сильнейший и всё такое.О, здравая мысль.
Именно поэтому у линукс столько ДЕ.> И, вдогонку, большая просьба — пускай заодно заберут с собой тех сидоров, которые сейчас пихают Rust в ядро.
А это просто эпичная тупость.
Пока престарелые 321ы ставят палки в колеса новому языку.
Это понятно, так можно делать CVEшки и испралять их. А если раст в ядро попадет, то всю эту шоблу отправят на пенсию.Но это не страшно, диды не вечны, может Тцо скоро помрет или в деменцию впадет.
> Но это не страшно, диды не вечны, может Тцо скоро помрет или в деменцию впадет.ППЦ... __единственная__ надежда ржавчикофф :-)
Вас вон тупица линус в ядро пустил (пусть и не по своей воле) - и что?
А сбежали, типо у нас - лапки :)
Rust в ядро попал, если вы не заметили. Никто на пенсию не ушёл, ядро активно разрабатывается. Сбежал, правда, только один растоман.
> Rust в ядро попал, если вы не заметили.Не заметил? Да такого горения оп на форуме невозможно было не заметить
> Никто на пенсию не ушёл,
К сожалении никто не ушел, как бракоделили, так и продолжают.
> ядро активно разрабатывается.
И Торвальдс просто так рассказывает, что медленно внедряется тк старики копротивляются.
> Сбежал, правда, только один растоман
Конечно сбежал. Там же типичная дидовщина))
Зачем ему работать с дидами, которые сразу говорят "новое учить не буду"?
Так что раст в ядре есть, а разработчиков не будет.Запасаемся попкорном и ждем магического пенделя от спонсоров ядра.
Это Линуса что ли? А то ведь это он пушит, если ты не знал)
В этом барахле прекрасно все, особенно такоеdocker run -it --privileged --network=host --device=/dev/kvm -v $(pwd)/asterinas:/root/asterinas asterinas/asterinas:0.9.3
Многое говорит о вас растишках. Мало того что нет нормального гайда сборки ядра, так еще и контейнеры что уже плохой тон. Мало того тут и привелегии вам подавай, и сетку хоста, и железки вам прокить, и рута дай, и хрен пойми откуда контейнер и с какими вирусяками.
Просто праздник хреновой сборки, и все это просто для сборки кода карл.
Шёл 2024 год, а мыши всё продолжали переписывать операционную ситему из 60-х годов прошлого столетия.
Во-первых, из 1990-х.
Во-вторых, так принципиально других-то и нет.
Здрасьте вам - нет?! Полно. Просто ни одна _настолько_ не взлетела, это да :)
А что вы считаете _принципиально_ другим: FreeBSD, OpenBSD? :) И родом они тоже из 1990-х. Да даже Хайка, в ней тоже - всё есть файл.
GNU/Linux - это клон того самого древнейшего UNIX из конца 60-х годов. Туда же относятся все *BSD и прочие Unix-like системы.
Как нету ?? MacOS ! Мэйнфреймы !!
>Мэйнфреймы !!Таr они же родом из 1960-х?... или даже 1950-х. Тож получается, что они дренее того самого UNIX из конца 60-х годов.
Макось — тот же старинный юникс поверх микроядра плюс красивый закрытый гуи.
> Шёл 2024 год, а мыши всё продолжали переписывать операционную ситему из 60-х
> годов прошлого столетия.Господа с plan9 пытались что-то такое изобразить. Оказалось что Неуловимый Джо и правда никому не интеересен чтобы еще за ним бегать.
Kerla-2: иногда они возвращаются.
>>> Ядро разбито на две части, написанные на Rust: OS Framework и OS Services. В OS Services запрещено применение unsafe-блоков, а все низкоуровневые операции, требующие выполнения кода в блоках unsafe, вынесены в OS Framework и доступны только через высокоуровневый API. Все системные вызовы, файловые системы и драйверы реализуются на уровне OS Services и не могут включать unsafe-блоки.Ничего что OS Services будет вызывать OS Framework который вызывает unsafe код? И в этом все растоящеры. Как будто на других ЯП нельзя вынести 'unsafe' код в отдельную библиотеку и работать через нее. Они реально считают это каким-то своим личным достижением. Вот только как было обращение с unsafe коду в проекте оно так и осталось.
в других ЯПах либо все потенциально небезопасно, либо ничего, а небезопасным кодом рулит супервизор в той или иной форме.
>только как было обращение с unsafe коду в проекте оно так и осталось...но не осталось шанса допустить нелогические ошибки на стороны вызывающего.
сделайте так же в С?
буквально вчера полдня код дебажила, пытаясь понять, почему strtok_r остаток контента зануляет.
а оказалось, что это компилятор порядок исполнения перетусовал.
в русте такого нет.
Пример кода и какая версия компилятора, интересно стало. Хочу повторить, то что вы на 100% утверждаете.
> широкого использования в виртуальных машинах с архитектурой x86-64Реактос приветы передавал, у них там уже 20-й год побед идет. Или какой там.
Как бы, since 1998.