После года разработки подготовлен (https://www.redox-os.org/news/release-0.5.0/) выпуск операционной системы Redox 0.5 (http://www.redox-os.org), разработанной с использованием языка Rust и концепции микроядра. Наработки проекта распространяются (https://github.com/redox-os/redox) под свободной лицензией MIT. Для тестирования в VirtualBox или QEMU предложены (https://gitlab.redox-os.org/redox-os/redox/-/jobs/10824/arti.../) готовые загрузочные образы.Пользовательское окружение в Redox построено на базе графической оболочки Orbital (https://www.opennet.ru/opennews/art.shtml?num=38934), работающей поверх Wayland. В качестве web-браузера применяется Netsurf (https://www.opennet.ru/opennews/art.shtml?num=41855). Операционная система использует концепцию микроядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами, а вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. Все драйверы выполняются в пространстве пользователя в изолированных sandbox-окружениях. Для совместимости с существующими приложениями предоставляется специальная POSIX-прослойка, позволяющая запускать многие программы без портирования.
Redox развивается в соответствии с философией Unix c заимствованием некоторых идей из SeL4, Minix и Plan 9. В системе применяется принцип "все есть URL". Например, для записи в лог может использоваться URL "log://", для взаимодействия между процессами "bus://", для сетевого взаимодействия "tcp://" и т.п. Модули, которые могут быть реализованы в форме драйверов, расширений ядра и пользовательских приложений, могут регистрировать свои обработчики URL, например, можно написать модуль обращения к портам ввода/вывода и привязать его к URL "port_io://", после чего можно использовать его для доступа к 60 порту через открытие URL "port_io://60".
Проектом также развивается собственный пакетный менеджер (https://github.com/redox-os/pkgutils), набор стандартных утилит (binutils, coreutils, netutils, extrautils), командная оболочка ion (https://github.com/redox-os/ion), vim-подобный текстовый редактор sodium (https://github.com/redox-os/sodium), сетевой стек и файловая система TFS (https://github.com/redox-os/tfs), развиваемая на основе идей ZFS (модульный вариант ZFS на языке Rust). Конфигурация задаётся на языке Toml (https://github.com/toml-lang/toml). Система поддерживает запуск на процессорах с архитектурой x86_64 c VBE-совместимой графической картой (nvidia, intel, amd), AHCI-дисками и сетевыми картами на базе чипов E1000 или RTL8168.
Из новшеств, добавленных в выпуске Redox 0.5, можно отметить:
- Предложена собственная стандартная Си-библиотека Relibc (https://github.com/redox-os/relibc), написанная на языке Rust. Relibc позиционируется как переносимая реализация стандартной библиотеки Си, соответствующая стандарту POSIX и способная работать не только в Redox, но и в дистрибутивах на базе ядра Linux.
Ранее в Redox в качестве стандартной библиотеки применялся форк (https://github.com/redox-os/newlib) библиотеки newlib (https://github.com/redox-os/newlib) от проекта Сygwin, но он не устраивал разработчиков с точки зрения безопасности и кросс-платформенности. На текущей стадии развития Relibc уже намного превосходит newlib по функциональности;- Подготовлены новые загрузчики bootloader-coreboot (https://gitlab.redox-os.org/redox-os/bootloader-coreboot) и bootloader-efi (https://gitlab.redox-os.org/redox-os/bootloader-efi) для coreboot и EFI, на основе которых сформированы загрузочные образы. Написаны библиотеки для работы с EFI на языке Rust и загрузочный код (payload для coreboot) на Rust. Загрузчики могут применяться обособленно от Redox и в других проектах;
- Система обработки событий переработана для предоставления корректной поддержки вызовов select и poll;
- Реализована полноценная поддержка функций отображения в память (mmap);
- Добавлена поддержка Pthreads и предложены дополнительные системные вызовы для обработки сигналов;- Улучшена совместимость с LLVM, что позволило обеспечить сборку rustc и Mesa (c llvmpipe);
- Благодаря переходу на новую системную библиотеку удалось добиться поддержки многих новых приложений (https://static.redox-os.org/pkg/x86_64-unknown-redox/repo.toml). Для установки в Redox подготовлены готовые пакеты с библитеками SDL2, ffmpeg, cairo, gstreamer, pcre, glib, pixman, libiconv, libsodium и gettext, набором компиляторов llvm, реализацией OpenGL/Vulkan Mesa, эмуляторами scummvm, dosbox и mgba, играми eduke32 (Duke Nukem 3D), openttd и FreeDoom. Всего добавлено 62 новых пакета.URL: https://www.redox-os.org/news/release-0.5.0/
Новость: https://www.opennet.ru/opennews/art.shtml?num=50387
> В системе применяется принцип "все есть URL".А там можно как в похапе ровно одной функцией file_exists проверить phar:// на существование и начать его исполнять?
Да глупость какая-то. В винде тоже можно зачем-то написать \\.\COM1, только никому не приходит в голову показывать это в консоли и вондовсэксплорере.
Зачем изолировать драйвера, если Rust безопасный?
Я тоже этого не понимаю до конца. Сам бог, казалось бы, велел вывести монолит на новый уровень, а они вместо этого сообщения между потоками передают. Может они думают не только об ошибках работы с памятью, и не только о тех ошибках, которые можно предотвратить грамотными API, но и об остальных ошибках, на которые никакая креативность не предложит лучшего способа реагировать, кроме panic?
Да, может. В таком случае кажется разумным задокументировать подобные мысли. Однако, в рекомендуемой к прочтению book вместо них лишь общие слова:Microkernels are more secure and less prone to crashes than monolithic kernels. This is due to drivers and other abstraction being less privileged, and thus cannot do damage to the system. Furthermore, microkernels are extremely maintainable, due to their small code size, this can potentially reduce the number of bugs in the kernel.
https://doc.redox-os.org/book/design/kernel/microkernels.htmlС другой стороны:
The basic design of the kernel/user space separation is fairly similar to genuine Unix-like systems, at this point. The idea is roughly the same: you separate kernel and user space, through strict enforcement by the kernel, which manages memory and other critical resources.
However, we have an advantage: enforced memory and type safety. This is Rust's strong side, a large number of "unexpected bugs" (for example, undefined behavior) are eliminated.
https://doc.redox-os.org/book/introduction/why_rust.html
Суть скорее в том что кроме расто драйверов существуют и другие драйвера которые могут быть написаны и на си.Да и не каждому ядру понравится крашится от драйверов мыши (привет из юникса).
А также не каждый драйвер будет работать во благо пользователя теже вирусы например.
А зачем писать драйвера на си, если можно на безопасном Rust?
Затем, что эти драйвера уже написаны, и будут портироваться сюда, потому что врядли кто-то сегодня потянет написание с нуля драйверов, даже для самых популярных устройств
ЛОЛШТО? Драйвер это вообще-то адаптер, преобразующий протокол устройства в протокол (API) ОС. Если это действительно новая ОС со своим протоколом, то и драйверы придётся именно переписывать.
Ну будет у тебя интерфейс драйвера другой. А логику драйвера будешь с нуля реверсить - спеки читать (если они есть вообще)? Тот же видеодрайвер проще взять линуксический и поменять в нём осезависимый код.
>видеодрайвер проще взять линуксический и поменять в нём осезависимый код.
>видеодрайвер
>поменять осезависимый код.Это весь код, что ли?
Ребята совсем не в теме. Вот это и есть уровень типичных растофанов.
> Тот же > видеодрайвер проще взять линуксический
> и поменять в нём осезависимый код.А ещё проще взять готовый виндовый. Тем более, давно есть наглядный пример.
>А ещё проще взять готовый виндовый.Главное синий экран зе забыть портировать.
>>А ещё проще взять готовый виндовый.
> Главное синий экран зе забыть портировать.Всё продумано шеф, возьмём готовый https://docs.microsoft.com/en-us/sysinternals/downloads/blue...
>> и поменять в нём осезависимый код.
>А ещё проще взять готовый виндовый.Чем менять-то, HEX-редактором?
Драйвера менять не надо. Мы же новую ОС пишем. Просто берём ReactOS и переписываем на Rust.
а вы готовы переписать все драйвера на rust ?
Да, готов. Ведь ради этого всё и затевалось. Правда, я бы предпочёл переписать всё на Component Pascal или Sing#, в крайнем случае на ML.
На Electron
Предлагаю предварительно произвести ребрендинг https://ru.wikipedia.org/wiki/%D0%94%D1%... что бы избавиться от негативного заряда.
Без unsafe на нём ничего полезного и быстрого не напишешь, особенно драйвер.
И много кода вы написали на Rust, интересно? Вот мне почему-то кажется, что вы - типичный сипипишник, краем уха слышавший про Rust из диалога коллег по разработке казуальных мобильных игр, и максимум прочитавший несколько глав из растокниги. А то я тут компилятор в своём подвале пишу, а мне и невдомёк, что нужно всё unsafe'ом обмазать, чтобы стало быстрее:
https://gitlab.com/bytefu/rambo~4500 строк кода, на данный момент генерит IR в SSA форме, control flow graph, есть базовые оптимизации - constant folding and propagation, global value numbering, dead code elimination. Прожёвывает примерно 100 000 строк кода в секунду (понятное дело, что это условность). Во всём коде 6 раз встречается unsafe - 3 раза в аллокаторе, считающем потребление памяти (там по API положено unsafe), 2 раза в коде виртуальной машины, которая в данный момент не используется, и последний - вызов isatty() для условной раскраски вывода в терминале. Итого: 2 вызова unsafe для увеличения производительности, оба в данный момент не используются.
не путай причину с следствием.
То есть безопасность Rust обусловлена применением микроядра? Вы же понимаете, если это так, то в прикладном софте говорить о ней не приходится?
>то есть безопасность Rust обусловлена применением микроядра
>Безопасность кирпича обусловлена применением здания.Иди домой ты пьян.
>>то есть безопасность Rust обусловлена применением микроядра
>>Безопасность кирпича обусловлена применением здания.
> Иди домой ты пьян.Переставил причину и следствие по совету эксперта.
И безопасной бритвой можно подавиться.
Ну так не надо их есть
Это по идее просто так не совсем удачно описали принцип работы микроядерной архитектуры. Как бы все изолированно друг от друга в том числе и драйвера.
Когда-нибудь система становится зрелой и получает проприентарные драйвера.Так сто лучще бы их изолировать.
Есть разница между безопасным в смысле stability, и безопасным в смысле security. Rust безопасный в смысле stability... Изоляция нужна для security...
> Есть разница между безопасным в смысле stability, и безопасным в смысле security.
> Rust безопасный в смысле stability... Изоляция нужна для security...А в смысле safety у всего этого как? Шифрование изолированных адресных пространство, как я понял с Ваших слов, Rust реализует прозрачно.
>> Есть разница между безопасным в смысле stability, и безопасным в смысле security.
>> Rust безопасный в смысле stability... Изоляция нужна для security...
> А в смысле safety у всего этого как? Шифрование изолированных адресных пространство,
> как я понял с Ваших слов, Rust реализует прозрачно.Rust - это язык программирования. Он к этой проблеме ортогонален... Это вопрос приложения, а не языка программирования.
> port_ioА почему подчёркивание, а не дефис?
Хотя, в общем-то, почему вообще не port? И так же понятно,что I/O.
>А почему подчёркивание, а не дефис?Какой на ухо дефис? Через минус, что ли? Минут в именах символов используют только дeбилы и создатели CSS, то есть только дeбилы.
"-" — дефис.
"−" — минус.
"—" — тире.
> "-" — дефис.
> "−" — минус.
> "—" — тире.давайте через неразрывный пробел называть тогда уж
Неразрывный пробел это пробел, который не рвётся при переносе строки
> Минус в именах символов используют только дeбилы и создатели CSSКроме языков программирования подчёркивания употребляются реже минусов. CSS вы уже упомянули. В доменных именах подчёркивания просто запрещены. В XML в именах тегов тоже минусы предпочтительнее (не уверен, что подчёркивания разрешены). В unix-утилитах подчёркивание тоже дикость, обычно используются минусы.
Не мешай им бороться с CSS. Они почти победили, а тут ты со своими отсылками к unix-утилитами.
И как с их ссылками работать в скриптах, с помощью wgef и curl? В юниксах концепция "всё файлы" была удобна в скриптах особенно. А в чём смысл "всё ссылки" непонятно, будто просто изврат ради изврата.Файлы-то хоть можно прочитать чем угодно, хоть браузером. А ссылки большинство не поддерживает, а те приложения что поддерживают, то только пару видов всего. Бессмысленная концепция совершенно.
Предлагаю новую концепцию: всё есть systemd-юниты.
SystemDOS
Почему ты считаешь, что URL подразумевает HTTP?
> Почему ты считаешь, что URL подразумевает HTTP?Где ты там увидел подразумевание? В юниксах можно прочитать файл чем угодно, т.к. читать файлы умеют все. Чем прочитать данные по ссылке типа упомянутого в статье log://? Это поддержку каждого протокола надо добавлять во все утилиты, нафиг такое.
Если там так же, как в Plan 9, - ничего не надо.В Plan 9 (откуда они взяли идею) протокол реализуется драйвером, а работаешь ты с таким URL точно так же как с файлом, через стандартные операции ввода-вывода. Точно так же, как в Линуксе сделан procfs.
Какая разница, /var/log/logfile или log://logfile? Принципиально никакой, только драйвер указывается в явном виде.
> Точно так же, как в Линуксе сделан procfs.
> Какая разница, /var/log/logfile или log://logfile? Принципиально никакой, только драйвер указывается в явном виде./proc я могу читать чем угодно, хоть веб-браузером, несмотря на то что он на это не был расчитан. А при попытке открыть log:// я получу ошибку о незнакомом протоколе. Вот и вся разница.
Ты туповат?
Ошибка, непознанный протокол!
Нет, ты напишешь cat log://logfile и получишь желаемое.
> Нет, ты напишешь cat log://logfile и получишь желаемое.Но разработчики ОС не осилят пропатчить абсолютно все приложения так чтобы они поддерживали всевозможные протоколы и схемы ссылок. При том что там кто угодно может выдумывать свои принципиально новые ссылки: "можно написать модуль обращения к портам ввода/вывода и привязать его к URL port_io://"
Тут нет ничего похожего на принцип UNIX. Главная суть принципа "всё есть файл" в том что нет необходимости поддерживать для каждой фигни свой протокол, коих могут плодить 100500, достаточно уметь читать/писать файл: https://i.imgur.com/GLs2RjG.png
>> Нет, ты напишешь cat log://logfile и получишь желаемое.
> Но разработчики ОС не осилят пропатчить абсолютно все приложения так чтобы они
> поддерживали всевозможные протоколы и схемы ссылок.они пропатчили fopen, и теперь он умеет вызывать обработчики всевозможных протоколов и схем ссылок (предположительно)
а кстати чем это отличается от той ситуации которая сейчас в Linux ?любая программа может воспользоваться fuse и посути мы получаем в Linux тот же самый принцип "всё есть URL" что и в Redox.
разница только в способе записи пути.
для Redox это "log://logfile"
а для linux это (например) "/run/user/123456/log/logfile"
(где "/run/user/123456/log" замонтирован через fuse)// P.S.: правда в Linux мы имеем продвинутую систему привелегий, так что любая программа не может замонтировать всё что угодно куда угодно.. интересно, а как это в Redox
При чем тут HTTP?Работать примерно так же, как с файлами. Но есть нюанс.
В юниксовых скриптах "все есть файл" во многом подразумевает "все есть текстовый файл с некоей структурой, которую можно распарсить простейшими утилитами" (не, понятно, что и с бинарными данными работать можно, но это нестандартный сценарий), и надо заранее знать ожидаемый формат ввода и вывода.
С URL это развитие той же идеи со своего рода типизацией: scheme указывает на протокол. Можно все разнообразие свести к некоторому промежуточному универсальному формату и на лету конвертировать одно в другое автоматически. А учитывая, что есть еще и query string, можно варьировать параметрами, специфичными для протокола, безо всяких специальных конструкций.
> При чем тут HTTP?Это у вас надо спросить, я его не упоминал. См. предыдущий коммент
"Все есть файл" не значит "текстовый".В современном unix это значит, можно работать через файловый дескриптор операциями read/write. Но основатели Unix считают, что этого не достаточно.
В ортодоксальном (читай, православном) Plan9 (созданном теми основателями Unix) это означает "ко всему есть доступ через функцию open и путь в файловой системе". В Plan9 и сокеты имеют интерфейс через файлы в файловой системе, и оконная система, и драйверы устройств.
Вот так:cat https://www.opennet.ru/ | iconv -f koi8-r -t utf8 | grep 'align=middle' | sed 's|.*">\(.*\)</a>.*|\1|'
> А ссылки большинство не поддерживает
Я тебе открою секрет: большинство утилит командной строки и имена файлов не поддерживают, они делигируют всю работу с именами файлов ядру.
> Я тебе открою секрет: большинство утилит командной строки и имена файлов не
> поддерживают, они делигируют всю работу с именами файлов ядру.Да, но надо лишь уметь работать с файлами и ты умеешь почти всё. Это главная суть идеи "всё есть файл". А в случае концепции "всё есть ссылка", особенно в их реализации, этого не получится. https://i.imgur.com/GLs2RjG.png
Банально потому что разработчики будут не в состоянии пропатчить всё ПО так чтобы оно поддерживало всевозможные схемы и протоколы URL'ов, тем более там они предлагают любым желающим выдумывать свои какие угодно. Поэтому тут нет ничего якобы "похожего на принцип UNIX, только ссылки вместо файлов". Их концепция не даёт того, что даёт концепция "всё есть файл". Вот я о чём.
Зачем патчить всё ПО? Зачем поддерживать какие бы то ни было схемы и протоколы URL'ов?Приложение поступает с url'ами так же, как с именами файлов, берёт их из командной строки как строку из байт, и засовывает в open(2). Получает взамен файловый дескриптор и работает с ним. Подавляющее большинство утилит из coreutils именно так и делает. Они правда работают на linux'е, а linux'овый open не умеет открывать http, поэтому если ты сделаешь cat https://www.opennet.ru, то ты получишь:
$ cat https://www.opennet.ru
cat: 'https://www.opennet.ru': No such file or directoryЧто произошло? Давай глянем?
$ strace cat https://www.opennet.ru
... бла-бла-бла ...
openat(AT_FDCWD, "https://www.opennet.ru", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "cat: ", 5cat: ) = 5
write(2, "'https://www.opennet.ru'", 24'https://www.opennet.ru') = 24
write(2, ": No such file or directory", 27: No such file or directory) = 27
write(2, "\n", 1
) = 1Видишь вызов openat? Это cat пытался открыть url как файл, запихивая в ядро url. И если бы ядро умело бы обрабатывать схему https://, то это даже могло бы сработать: cat получил бы файловый дескриптор, откуда бы он весело читал бы байтики, и засовывал бы их в stdout, и мы бы увидели содержимое http-странички. То есть, если бы скомпиляли этот cat для redoxos, то он бы там вполне бы мог читать с opennet'а странички, не понимая, что такое https://
> Поэтому тут нет ничего якобы "похожего на принцип UNIX, только ссылки вместо файлов".
Конечно-конечно, как скажешь.
Хм, ну ок, так действительно вполне возможно что это может работать...Кстати, схему file:// стоило бы таким образом и в линуксах сделать, а то из гуишных файловых менеджеров ссылки на файлы почему-то копируются именно как file://..., при копировании в консоль приходится вручную стирать протокол.
>Файлы-то хоть можно прочитать чем угодно, хоть браузером.И редактировать можно с помощью wwwim :)
кастую сравнение redox vs. reactos!
ReactOS: Development began in 1996
Redox: first published on 20 April 2015
redox уже работает
Тоже в VirtualBox или QEMU?
Вообще-то автор его пилил для собственного компуктера, чтобы в нём работать.
Кто объяснит зачем эта ОС?
Просто чтоб ядро не текло? (Раст не умеет текти)
Либо по тому что могут?)Я вот просто сомневаюсь что выйдет ос которая будет работать быстрее.
Тогда практическое применение?
Раст умеет всё.
Доказать всем, что у раста больше. Только, похоже, соревноваться они будут с реактосом.
+1
>Раст не умеет тектиЛюбой полный по Тьюрингу язык программирования может и "текти" и виснуть и глючить. Это прямо следует из его полноты.
В том же Расте: Создаем динамического размера буфер(Vec<i32>) в бесконечном цикле пихаем туда значения. Вуаля, за минуту-другую вся память утекла.
Ты спутал OOM и утечку памяти. Последняя - это когда объект мёртв, до него не достучаться, а память всё равно кушает. В твоём же примере Vec не куда не девается - к нему вполне себе можно обратиться, что ты и делаешь.То что для твоего буфера не хватило памяти - ну сорян, данных много, их где-то надо хранить. Между прочим, Раст это делает намного эффективнее других безопасных языков ибо объекты намного тоньше.
Чем тоньше объекты - тем больше фрагментирована куча
Нет, это ты перепутал частный случай(когда объект мёртв, до него не достучаться, а память всё равно кушает), с общей проблемой. Какая разница, что на объект где-то есть ссылка, если нет кода, который освободит его? Точно также нет разницы, освобождается ли память ручным вызовом free или автоматически сборщиком мусора после удаления последней ссылки на него. Утечки памяти это результат логических ошибок в программе, а не модели управления памятью в языке.
На данный момент "for fun". Как и Linux в начале. Может когда-нибудь применение найдётся. А может и нет.
Микроядро интересне. Может и кольца заюзают наконец (которым сто лет в обед), в отличии от.
Ну а раст - because we can.
>Кто объяснит зачем эта ОС?For fun, для экспериментов, в качестве хобби, для исследований возможностей и лимитов Rust, для исследований микроядерной архитектуры, для статей на OpenNet. Возможно, какие-то ещё интересные применения найдутся со временем.
> Кто объяснит зачем эта ОС?
> Просто чтоб ядро не текло? (Раст не умеет текти)
> Либо по тому что могут?)
> Я вот просто сомневаюсь что выйдет ос которая будет работать быстрее.
> Тогда практическое применение?имхо это шикарный демонстратор языка +(возможно) проверка концепций
если они даже бутлоадер на расте написали и создали свой пакетменеджер вместо использования какого-либо стандартного (например nix) - это явно демонстратор технологий и/или языка
Там в академических кругах кто то взялся пропихивать RUST студентам, ну и видимо они теперь за оценку/зачот будут кодить втуда.Насчёт быстрее - всем пофик, главное чтобы безопасно, а для быстроты нужно покупать железо за 100500 нефти.
По мне - очередное недоразумение от придурков из мозиллы, которое их друзья придурки в академ среде теперь пропихивают. И те и другие показывают друг на друга пальцем и говорят о том что оно всем надо.
Плюс паразитирование на маркетинговых бюджетах всяких контор продающих "безопасность", потому что у них типа всё безопасно.
Вот зачем делать такие рискованные эмоциональные безосновательные заключения?
В Линуксе слишком много дыр!
не в линуксе, а в конкретных приложения и их совместном проживании)) и да ну не верю я в безопасные языки. единственный безопасный - это ассемблер + точное знание архитектуры и оборудования под которую пишется. и да как в древности никаких операционных систем только напрямую запуск на железе. вот тут пожалуй безопасно)) ну если комп вообще не включать пожалуй еще безопаснее))
Отлично! Теперь осталось переписать это всё дело на C.
Лучше на assembler, толку больше.
На ассемблере уже есть. Даже две.
Зачем?
Даже ОС переписали на Rust, а Firefox до этих пор слоупочит...
Mozilla скорее всего перейдёт на движок chromium. Поэтому смысла им никакого нет всё переписывать на rust.
> Mozilla скорее всего перейдёт на движок chromium.Глупый тролинг. На chromium выгодно переходить токо комерческим организациям, так как не нада тратить деньги на програмистов, достаточно 2х дизайнеров.
А Mozilla существует типо как план Б для юзеров веба.
> Глупый тролинг. На chromium выгодно переходить токо комерческим организациям, так как не
> нада тратить деньги на програмистов, достаточно 2х дизайнеров.Вы ошибаетесь. Mozilla Corporation (частная, коммерческая организация) - дочерняя компания Mozilla Foundation, созданная 3 августа 2005 года. Ей были переданы функции по планированию, маркетингу, разработке и распространению Mozilla Firefox. Главной задачей для любой корпорации является получение прибыли. Написание собственного движка - это большой труд и непомерные затраты и издержки. Микрософт это поняли и перешли вместо своего движка в Edge на движок chromium. Поэтому, закономерным итогом всего этого для Mozilla Corporation я вижу переход c собственного движка Gecko на движок Chromium.
Ошибаетесь, Микрососы просто прочитали древнюю мудрость "Не можешь побороть - возглавь" (собственно их Embrace, extend, and extinguish примерно о том же). Во первых они сейчас резко повышают свою совместимость в вэблм, во вторых сокращают атраты, а в третьих начнут ползуче протаскивать нужные им фичи.
Вот возьмем стандарт WebAuthn - с начала 2019-ого Микрософт выключила браузерам прямой доступ к FIDO ключам, теперь только через их проприетарную прослойку Windows Hello, которая навязывает биометрию и TMP модули.
Причем если погуглить, то уже видно, что активно продавливается мысль Webauthn = Windows Hello и никак иначе. Embrace уже навязан, начинаем Extend.С Хромиумом конечно так быстро и просто не выйдет, но веселье еще впереди.
Я могу перечислить тебе ещё десяток уважаемых компаний, которые не стали разрабатывать собственного движка. Но я не понимаю как из этого следует, что мозилле не следует разрабатывать собственный движок.Я могу перечислить десяток уважаемых компаний, которые не разрабатывают windows, значит ли это, что разрабатывать windows невыгодно, и майкрософту следует отказаться от поддержки windows?
Я могу перечислить десяток уважаемых компаний, которые не разрабатывают ракету для вывода на орбиту спутников, значит ли это, что затея Маска провальна?
Если компания хочет власти и влияния - пишет свою ОС, свой сервис карт/картографии, свой язык создает, свой движок браузера.Это больше, чем деньги - это власть. Надо быть большим и зубастым, чтобы диктовать свою волю. МС, судя по всему, уже не такие зубастые.
https://github.com/servo/servo
идея хороша, но зачем оно нужно без софта? Или там можно будет запускать линуховый?
как это без софта, написано же "добавлено 62 новых пакета"
>В качестве web-браузера применяется NetsurfА почему не rast'образный firefox? Что не осилили?
Конечно, они же там зачем-то всё подряд пилят. Не только стандартную библиотеку Си на ржавчине, но и freetype тоже перепиливают с Си на раст. И ничего толком не доделано, что характерно.
Что характерно, это "недоделано" уже запускается и работает. Первый линукс тоже вышел без системдэ и драйверов нвидии.
> Что характерно, это "недоделано" уже запускается и работает. Первый линукс тоже вышел без системдэ и драйверов нвидии.Причем и первый и второй и ... цатый (например: ядро 1.2.13 в третьей слаке) имел еще и меньше строк кода. чем некая "система инициализации" ;)
я помнится обновлял ядрышко 2.4 было около 15 мб, теперь 64819 КБ (4.13.). грубо говоря сильно потолстело.
Не понимаю отрицательных отзывов.
Они сделали еще одну микроядерную ОС. Ну захотели и сделали, молодцы. Судя по всему она уже сейчас может не меньше старых и над расширением совместимости с существующим софтом активно работают.
Написали ее на RUST, ну то же молодцы, с одной стороны течь не будет, с другой возможности RUST показывают. Инструмент вполне соответствует задаче.
Концепция все URL, это прямое расширение концепции все файл и вполне логична. Обращаться к файлам как это принято в Linux это хорошо. Дать возможность по этому же типу делать кучу других стандартных вещей типа логов и т.п. тоже хорошо.
Написание всяких библиотек и загрузчиков с учетом возможности использовать не только с Redox - это вообще какой-то возврат в прошлое, когда люди думали как сделать хорошие универсальные вещи. В отличии от подходов всяких системды.
Чем все недовольны?
Жаль что пока готова только для тестов. Нужно:
1. поддержка железа - возможно прослойка для использования дров линуховых
2. репозитарий с пакетами и пакетов сильно побольше.И после этого можно и нужно будет сравнить производительность этого микроядра с современным линуксом. Понятно что медленнее, вопрос насколько в каких задачах.
Например на этом можно было бы построить безопасный дистр. потери производительности должны быть не больше чем запуск кучи виртуалок. А изначальный подход все есть ссылка должен быть удобен для встраивания проверок доступа между приложениями: кому в какие стороны можно данные передавать, а в какие нет.
> Они сделали еще одну микроядерную ОС.нет
>Написали ее на RUST, ну то же молодцы, с одной стороны течь не будетrust защищает от порчи памяти, но не от ее утечек. Там даже mem::forget сделали безопасной функцией
Вроде ж как главное преимущество отмечается отсутствие сборщика мусора.
Сам я Rust не пробовал. Все думаю посмотреть поглубже.
С порчей памяти понятно.
А можно пример как на нем сделать утечку?
> А можно пример как на нем сделать утечку?fn memleak() {
let leak = Vec::<u64>::with_capacity(1_000_000_000);
std::mem::forget(leak);
}fn main() {
memleak();
println!("Memleak success");
}Это правда не очень хороший пример, потому что Vec::with_capacity берёт неинициализированную память, и из-за этого эффективно отъедает лишь кусок адресного пространства процесса, а не физическую память: ядро не выделяет страницы, пока к ним не было обращения. Но ежели ты туда запишешь что-нибудь, чтобы ядро страницы-таки выделило, то... ты только осторожнее, оно может серьёзно протормозить твою систему.
Можно пойти более сложным путём и создать цикл из Rc<T>, ссылающихся друг на друга.
Всё написанное верно, но при этом все утечки помимо Rc-циклов - явный и осознанный выстрел себе в ногу, который не нужен в 99,999...% кода.
Хм, вчера только прочитал что нельзя в расте получить мутирующую и не мутирующую ссылку на один и тот же объект, таким образом нельзя сделать кольцевые ссылки.Таким образом даже себе в ногу так не выстрелить :-)))
Жаль что не на Golang. Было бы круто.
>Каждый год переписывать всю кодовую базу под новый "модный" язык программированияАлиса в Зазеркалье:
— У нас, когда долго бежишь, непременно попадаешь в другое место.
— Ну, а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же самом месте, а чтобы попасть в другое место, нужно бежать вдвое быстрее.
Всегда поражался, насколько точно эта цитата описывает нашу жизнь
Уже написали, гугли pdf и сорцы на гхабе.
надо sysvinit на rust переписать и вернуть в debian
Зачем иконки такие яблочные? о_О
Интересная концепция про URL в этом их РжавОСе...Но определённо стоит попробовать в действии, заинтриговали.
Хм.mkdir -p http:/yandex.ru
echo TEST > http:/yandex.ru/index.html
cat http://yandex.ru/index.htmlЧто мне я увижу в консоли в этом редоксе?
Ну замени свой http:/yandex.ru на /dev/urandom и попробуй в линуксе. Скорее всего будет то же самое:1. cannot create directory ‘http:/yandex.ru’: Not a directory
2. ничего
3. содержимое http://yandex.ru/index.html
Рад за них. Хочу, чтобы у них получилось. Вот только лицензия... Помню несколько проектов под митовской лицензией, которые развивали, взращивали, а потом приходил хитрожопец и создавал форк с некоторыми улучшениями, но уже платную и всё разваливалось. Последнее что помню - Urho3D и его форк на сишарпе с платными плюшками, который в результате тоже стал открытым, но сообщество развалил и автора оригинала обидел. Все эти пермисивные игры...
А вот интересно отсылает ли эта OS телеметрию своим авторам ? Есть ли в ней "зонды" ?
Когда Golang перепишут на Rust.
Будет наконец-то быстрый и безопасный Golang
Эм Orbital из Redox и другой Orbital это совершенно два разных проекта, просто случайно название совпало и всё.Тот Orbial https://github.com/giucam/orbital, про который вы написали, и правда работает на Wayland, базируется на её эталонной реализации (Weston) и написан на C++.
Но тот Orbital https://github.com/redox-os/orbital, который в Redox, написан на Rust и использует свои Orb** библиотеки, никаких вейлендов. Не имеет ничего общего с тем Orbital кроме названия и что это композитный оконный диспетчерДа, иногда бывают такие случайности
