Не знаю. Но прелесть в том, что это можно сделать независимо от авторов проекта. Если нужно, вы берёте, например, libpng, дописываете спецификации какого-нибудь Farma-C, и проверяете. И для этого не нужно ограничивать выразительность исходного языка.
OSи пишут на разных языках: Lisp, Java, Haskell, Forth, ML и даже JavaScript. Написать небольшую OS для конкретной железяки - не такой уж и амбициозный проект. У меня второкурсники микроядра с вытесняющей многозадачностью писали за месяц. Человечество уже давно знает, как это делается. В этом плане Rust ничего принципиально нового не предлагает...
Ну, разве только то, что не получится привычные структуры данных использовать для всяких очередей таймеров или планировщиков пакетов. В этом есть некое интеллектуальное приключение. Но что-то я сомневаюсь, что оно упрощает написание OS, а не усложняет. В той же Redox довольно печально с этим дела обстоят: вместо кучи таймеров активное ожидание с переключением контекстов, очередями событий служат deque и т.д. Не самые эффективные решения, мягко говоря, особенно для систем реального времени.
Это хуже, потому что там бывают весьма серьёзные протечки: из стека в static, например. В Си вы знаете, что так может быть, и следите за этим, структурируете программу соответствующим образом. В Rust вы верите, что так не бывает, и не следите, а потом долго удивляетесь, что вам сносит стек. При этом, опасное поведение может быть запрятано в библиотеке.
Rust даёт обещания, которые не выполняет, и полагаться на него нельзя. Всё равно, приходится прогонять всё через valgrind какой-нибудь. Так зачем тогда Rust?
Система типов в Rust - unsound, и допускает ошибки, а сам проверяльщик с багами. Поэтому эти проверки 100% гарантий не дают.
Про библиотеку не понятно. Мы же говорим о программировании в Linux, так ведь? В ядре есть библиотека примитивов. Она тоже протестирована, гораздо лучше, кстати, чем Rust, и тоже даёт гарантии.
Си лучше тем, что он не даёт ложных обещаний корректности программисту, и программист думает, когда пишет код, отлаживает и тестирует экзотические и паталогические поведения.
В Rust программист борется с системой типов, обычно, полагаясь на неё. Н,о на самом деле, гарантий никаких нет. Вы загрузили два драйвера в ядро, что будет гарантировать, что они не используют одну и ту же очередь, без Sync? Как компилятор это проверит? Кроме того, при тестировании нельзя создать паталогические сценарии, потому что система типов и структуру тестов ограничивает - снова нужен unsafe или ffi (unsafe в тестах, Карл!)
Что делать с обработчиками прерываний? И т.д. и т.п. Вопросов много, а ответ один: unsafe. Ну и зачем такое счастье?
Вот, например, понятно, зачем вкорячивать Lua в ядро NetBSD: дополнительная гибкость и скорость разработки. Зачем вкорячивать Rust в Linux - я не понимаю. Это только повысит трудоёмкость разработки, но ничего не даст взамен (везде будет unsafe из-за специфики ядер операционных систем).
В ядре операционки. На уровне приложений вам эффективное изменение размера вектора обеспечивает виртуальная память - remap всякий. В ядре такой роскоши нет, а необходимость поддерживать fifo порядки есть. На самом деле, нужны более сложные структуры данных с переменным количеством элементов. Но если в Rust даже простая очередь - это небольшой unsafe адок, то что говорить о более сложных конструкциях?
В статье примеры проблем перечислены. Большинство искусственные, конечно. Но когда это останавливало разработчиков новых прекрасных языков программирования? За Linux вот только страшновато. Обычно софт на Rust выходит корявым логикой своей работы, потому что Rust уж слишком ограничивает выразительные возможности.
Ну, почему? У IBM есть транзисторы с вертикальным затвором, а Intel предлагает силовую и сигнальную разводку сделать по разные стороны слоя с транзисторами. Это ещё несколько десятков процентов добавит к производительности при заданном TDP. Потом, наверное, часть сигнальной разводки будут заменять на оптическую.
Можете объяснить, почему это решение ошибочно? Вроде как, поведенческая психология нам подсказывает, что в среднем люди при непосредственном общении лучше решают задачи. Исключения есть, конечно. Но строить компанию на исключительных сотрудниках - рискованная стратегия.
DALL-E (первая) генерирует полную муть. Я раз 100 пытался получить приемлемого качества картинку по самым разным запросам - так ничего и не вышло. Всегда получалась просто каша из пикселей. Со второй версией не работал.
Вы придумываете лишние коннотации моим утверждениям. Я имел в виду только то, что уровень агрессии внешней политики не коррелирует отрицательно с уровнем экономического развития. А о том, что мирных государств не существует, ещё со времён Сунь-Цзы известно.
Про P.S. То есть, когда активны РФ конфискуются (самолёты, валютные резервы, яхты олигархов, даже тех, кто публично кричал, что Путин - зло, грузовые судна и т.д.) - это норм, а когда активы Siemens - это ай-я-яй? Почему двойные стандарты? Почему Вы не возмущаетесь действиями Лондона в отношении, например, Петра Авена?
А зачем производит всё? То, что можем производить, нужно производить самим - это полезно вообще для повышения качества человеческого капитала. То, что не можем, но должны для экономической безопасности страны, нужно учиться производить. Остальное - как получится. Турбины мы можем сами производить.
Ну, и, как бы, агрессивная внешняя политика США и ЕС, вроде как, не мешает им развиваться. Сколько себя помню, они всегда несли свет демократии туда, куда их не просили, средствами гуманитарных бомбардировок.
Тут дело не в войнах и угрозах ядерным оружием, а в том является ли валюта страны инвестиционной, в стоимости кредита, в возможности эмиссии, в объёмах рынков сбыта, в уровне образования и прочих экономических факторах.
В статье и о том ещё, что Siemens обязалась локализовать производство, но не сделала это. И почему Вы уверены, что вместо дешёвых и хороших будут плохие и дорогие? У нас в стране есть несколько заводов, производящих газовые турбины, в том числе и на экспорт. Турбины Siemens просто большей мощности. Не факт, что наши производители не смогут такие изготовить, если будет спрос.
Про "хапнула советских технологий" ссылки найти не удалось (да и пишут ли о таком?). Могу пересказать то, что мне рассказывал дядя, работавший на заводе слесарем-инструментальщиком. Они занимались холодной штамповкой деталей из алюминия, и получилась у них это особенно хорошо (не помню, что именно хорошо, а сейчас уже не спросить :( что-то связанное со скоростью производства). После развала СССР к ним высадился десант инженеров из Siemens, которые изучили пресс, опросили технологов и инструментальщиков, скопировали чертежи, а через некоторое время вывезли и некоторые детали пресса, после чего цех закрылся.
Не думаю, что такая история была исключительной для одного провинциального завода.
Не знаю. Но прелесть в том, что это можно сделать независимо от авторов проекта. Если нужно, вы берёте, например, libpng, дописываете спецификации какого-нибудь Farma-C, и проверяете. И для этого не нужно ограничивать выразительность исходного языка.
Да ладно? Проекты на Си обмазывают тестами, фаззерами, разнообразными статическими анализаторами весьма обильно. Инструментов для этого предостаточно.
А где можно посмотреть доказательство корректности битонной сортировки, например?
OSи пишут на разных языках: Lisp, Java, Haskell, Forth, ML и даже JavaScript. Написать небольшую OS для конкретной железяки - не такой уж и амбициозный проект. У меня второкурсники микроядра с вытесняющей многозадачностью писали за месяц. Человечество уже давно знает, как это делается. В этом плане Rust ничего принципиально нового не предлагает...
Ну, разве только то, что не получится привычные структуры данных использовать для всяких очередей таймеров или планировщиков пакетов. В этом есть некое интеллектуальное приключение. Но что-то я сомневаюсь, что оно упрощает написание OS, а не усложняет. В той же Redox довольно печально с этим дела обстоят: вместо кучи таймеров активное ожидание с переключением контекстов, очередями событий служат deque и т.д. Не самые эффективные решения, мягко говоря, особенно для систем реального времени.
Только сортировать она сможет лишь списки, и лишь одним медленным способом.
Это хуже, потому что там бывают весьма серьёзные протечки: из стека в static, например. В Си вы знаете, что так может быть, и следите за этим, структурируете программу соответствующим образом. В Rust вы верите, что так не бывает, и не следите, а потом долго удивляетесь, что вам сносит стек. При этом, опасное поведение может быть запрятано в библиотеке.
Rust даёт обещания, которые не выполняет, и полагаться на него нельзя. Всё равно, приходится прогонять всё через valgrind какой-нибудь. Так зачем тогда Rust?
Система типов в Rust - unsound, и допускает ошибки, а сам проверяльщик с багами. Поэтому эти проверки 100% гарантий не дают.
Про библиотеку не понятно. Мы же говорим о программировании в Linux, так ведь? В ядре есть библиотека примитивов. Она тоже протестирована, гораздо лучше, кстати, чем Rust, и тоже даёт гарантии.
Си лучше тем, что он не даёт ложных обещаний корректности программисту, и программист думает, когда пишет код, отлаживает и тестирует экзотические и паталогические поведения.
В Rust программист борется с системой типов, обычно, полагаясь на неё. Н,о на самом деле, гарантий никаких нет. Вы загрузили два драйвера в ядро, что будет гарантировать, что они не используют одну и ту же очередь, без Sync? Как компилятор это проверит? Кроме того, при тестировании нельзя создать паталогические сценарии, потому что система типов и структуру тестов ограничивает - снова нужен unsafe или ffi (unsafe в тестах, Карл!)
Что делать с обработчиками прерываний? И т.д. и т.п. Вопросов много, а ответ один: unsafe. Ну и зачем такое счастье?
Вот, например, понятно, зачем вкорячивать Lua в ядро NetBSD: дополнительная гибкость и скорость разработки. Зачем вкорячивать Rust в Linux - я не понимаю. Это только повысит трудоёмкость разработки, но ничего не даст взамен (везде будет unsafe из-за специфики ядер операционных систем).
И чем это лучше реализации на Си? Unsafe-код есть, ручное управление памятью есть, потокобезопасности нет. ??♂️
В ядре операционки. На уровне приложений вам эффективное изменение размера вектора обеспечивает виртуальная память - remap всякий. В ядре такой роскоши нет, а необходимость поддерживать fifo порядки есть. На самом деле, нужны более сложные структуры данных с переменным количеством элементов. Но если в Rust даже простая очередь - это небольшой unsafe адок, то что говорить о более сложных конструкциях?
Мой любимый пример - реализация двусвязного списка на Rust. Даже на Haskell это проще сделать.
В статье примеры проблем перечислены. Большинство искусственные, конечно. Но когда это останавливало разработчиков новых прекрасных языков программирования? За Linux вот только страшновато. Обычно софт на Rust выходит корявым логикой своей работы, потому что Rust уж слишком ограничивает выразительные возможности.
Так это поэтому для Rust нет нормальных мануалов по структурам данных? Потому что они все требуют unsafe?
Ну, почему? У IBM есть транзисторы с вертикальным затвором, а Intel предлагает силовую и сигнальную разводку сделать по разные стороны слоя с транзисторами. Это ещё несколько десятков процентов добавит к производительности при заданном TDP. Потом, наверное, часть сигнальной разводки будут заменять на оптическую.
Лечение нынче дорогое. Как раз, понадобятся
Можете объяснить, почему это решение ошибочно? Вроде как, поведенческая психология нам подсказывает, что в среднем люди при непосредственном общении лучше решают задачи. Исключения есть, конечно. Но строить компанию на исключительных сотрудниках - рискованная стратегия.
В предыдущей статье по первой ссылке: на двух ионах, как у четырёх кубитов.
DALL-E (первая) генерирует полную муть. Я раз 100 пытался получить приемлемого качества картинку по самым разным запросам - так ничего и не вышло. Всегда получалась просто каша из пикселей. Со второй версией не работал.
Вы придумываете лишние коннотации моим утверждениям. Я имел в виду только то, что уровень агрессии внешней политики не коррелирует отрицательно с уровнем экономического развития. А о том, что мирных государств не существует, ещё со времён Сунь-Цзы известно.
Про P.S. То есть, когда активны РФ конфискуются (самолёты, валютные резервы, яхты олигархов, даже тех, кто публично кричал, что Путин - зло, грузовые судна и т.д.) - это норм, а когда активы Siemens - это ай-я-яй? Почему двойные стандарты? Почему Вы не возмущаетесь действиями Лондона в отношении, например, Петра Авена?
А зачем производит всё? То, что можем производить, нужно производить самим - это полезно вообще для повышения качества человеческого капитала. То, что не можем, но должны для экономической безопасности страны, нужно учиться производить. Остальное - как получится. Турбины мы можем сами производить.
Ну, и, как бы, агрессивная внешняя политика США и ЕС, вроде как, не мешает им развиваться. Сколько себя помню, они всегда несли свет демократии туда, куда их не просили, средствами гуманитарных бомбардировок.
Тут дело не в войнах и угрозах ядерным оружием, а в том является ли валюта страны инвестиционной, в стоимости кредита, в возможности эмиссии, в объёмах рынков сбыта, в уровне образования и прочих экономических факторах.
В статье и о том ещё, что Siemens обязалась локализовать производство, но не сделала это. И почему Вы уверены, что вместо дешёвых и хороших будут плохие и дорогие? У нас в стране есть несколько заводов, производящих газовые турбины, в том числе и на экспорт. Турбины Siemens просто большей мощности. Не факт, что наши производители не смогут такие изготовить, если будет спрос.
Про "хапнула советских технологий" ссылки найти не удалось (да и пишут ли о таком?). Могу пересказать то, что мне рассказывал дядя, работавший на заводе слесарем-инструментальщиком. Они занимались холодной штамповкой деталей из алюминия, и получилась у них это особенно хорошо (не помню, что именно хорошо, а сейчас уже не спросить :( что-то связанное со скоростью производства). После развала СССР к ним высадился десант инженеров из Siemens, которые изучили пресс, опросили технологов и инструментальщиков, скопировали чертежи, а через некоторое время вывезли и некоторые детали пресса, после чего цех закрылся.
Не думаю, что такая история была исключительной для одного провинциального завода.