Представлена (http://www.redox-os.org/news/this-week-in-redox-1/) новая операционная система Redox (http://www.redox-os.org), примечательная использованием для разработки языка Rust. Наработки проекта распространяются (https://github.com/redox-os/redox) под свободной лицензией MIT. После сборки систему можно опробовать при помощи VirtualBox или QEMU.
Redox развивается в соответствии с философией Unix и основывается на принципе "все есть URL (https://github.com/redox-os/redox/wiki/URL)". Например, для записи в лог может использоваться URL "log://", для взаимодействия между процессами "bus://", для сетевого взаимодействия "network://" и т.п. Модули, которые могут быть реализованы в форме драйверов, расширений ядра и пользовательских приложений, могут регистрировать свои обработчики URL, например, можно написать модуль обращения к порам ввода/вывода и привязать его к URL "port_io://", после чего можно использовать его для доступа к 60 порту через открытие URL "port_io://60".Операционная система использует концепцию экзоядра (https://ru.wikipedia.org/wiki/%D0%AD%D0%... при котором на уровне ядра обеспечивается только взаимодействия между процессами и управление ресурсами. Вся остальная функциональность вынесена в библиотеки (https://github.com/redox-os/redox/wiki/Standard%20Libra... которые могут использоваться как ядром, таки пользовательскими приложениями. В Redox применён необычный подход к безопасности - все драйверы и программы выполняются только в изолированных sandbox-окружениях, но пользователь при этом имеет наивысшие привилегии в системе.
Несмотря на то, что система находится на начальной стадии развития, она уже снабжен похожим на X11 графическим интерфейсом, VFS, сетевым стеком, загрузчиком файлов в формате ELF и системой виртуальной памяти. ОС снабжена собственным пакетным менеджером оxide (https://github.com/redox-os/oxide) и системой инициализации fired (http://www.redox-os.org/blog/fired-fast-init-system/). В качестве основной файловой системы планируется использовать ZFS, реализация которой в текущем виде пока не доведена до рабочего состояния.
<center><a href="https://raw.githubusercontent.com/redox-os/redox/master/img/... src="https://www.opennet.me/opennews/pics_base/0_1444223985.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Система инициализации fired во многом повторяет типичные init-системы, поддерживает параллельный запуск сервисов и зависит только от ядра (не привязан к libc). Для настройки запуска используются файлы конфигурации на языке Toml (https://github.com/toml-lang/toml) вместо скриптов на shell. Сетевая подсистема предоставляет (https://github.com/redox-os/redox/wiki/Networking) несколько URL для доступа на различных уровнях: "tcp://", "udp://", "ip://", "ethernet://" и "network://". Например, для обращения к 80 порту хоста 10.85.85.1 следует использовать URL "tcp://10.85.85.1/80".
URL: http://www.redox-os.org/news/this-week-in-redox-1/
Новость: http://www.opennet.me/opennews/art.shtml?num=43105
Отлично, раст могет! Смущают только области применения этой ОС
раз всё есть url, значит браузеры планируют поглотить ос. напоминает "стиральную трагедию".
Браузеры уже как несколько лет этим занимаются.
технически почти где угодно, но юрл.... придется многому учиться))) да и прог маловато. но вот в сетевой принтер запихать наверно ничего или другой embeded.
> Смущают только области применения этой ОСjust for fun
https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51.../
> When I first saw rust, I asked, could this be used everywhere? I git pulled the repo and saw that it was using
> libc bindings for system calls! It should be easy enough to get rid of the C bindings altogether, and call the
> OS directly, which would also be written in Rust.Т.е. "увидел раст, решил написать на нем ОСь, вроде получилось".
> Отлично, раст могет!
Жду комментариев типа "это не показатель! Наваять игрушечную ОС можно даже на пистоне!"
После того, как я увидел, что можно заставить PHP работать на Java-машине, меня уже сложно удивить. Вопрос в том, стоит ли создавать средства, не привязанные к реальным задачам.
А в чем сложность php на JVM?
> А в чем сложность php на JVM?Сложности нет. Только разработка требует определённого количества времени, а стоит ли его тратить, если реальных задач, которые требуют данное средство нет?
Я упомянул этот проект, если что: https://github.com/jphp-compiler/jphp
> Только разработка требует определённого количества времени, а стоит ли его тратить, если реальных задач, которые требуют данное средство нет?Вас никто и не заставляет разрабатывать и тратить свое время.
Более того никто и не заставляет вас пользоваться или платить деньги.
> После того, как я увидел, что можно заставить PHP работать на Java-машине,
> меня уже сложно удивить. Вопрос в том, стоит ли создавать средства,
> не привязанные к реальным задачам.Вы сравниваете теплое с мягким.
Раст все таки позиционируется (в том числе и) как "systems programming language". Т.е. попытка написать на нем даже "игрушечную" ОСь позволяет как минимум проверить, так ли это на самом деле – ну и попутно выловить пару тройку граблей и возможно улучшить язык (см. комментарии в треде на реддите, типа
> Any optimization at all can cause memory operations to be reordered in a way that breaks drivers. It is very verbose to fix this ( volatile_load and volatile_store )
> I had to twiddle things very specifically to get my context switching function to work (it needs to push/pop a predictable amount of times)Ну в самом-то деле – не тянуть же сырой язык сразу в продакшен, к "реальным задачам". Но и на одних хелловорлдах далеко не уедешь.
Вот если бы JVM на PHP...
В первую очередь виртуалки — компактная, быстро стартующая система, в которую можно пробросить отдельное железо, работу которого нужно резко оптимизировать, но ради этого не хочется лезть в ядро хоста. Вот давеча новость была - под сетевые карты прикладной софт свои дрова юзал и вообще вводил свой альтернативный сетевой стек. Если под это дело будет хорошая платформа, можем ожидать широкого развития концепции.
Будем посмотреть
На rust операционка, вот это да. Быстрая, как ракета. Интересно, будет ли совместимость с существующим linux софтом?
ничосси. оч забавная тема.
>основывается на принципе "все есть URL"видимо, вдохновлялись Plan9
>>основывается на принципе "все есть URL"
> видимо, вдохновлялись Plan9Сенсация! Учёные обнаружили ОС-ы, где всйио!!!, буквально ФСЁЙО == биты.
почему тогда готовый https://ru.wikipedia.org/wiki/9P не использовать?
Да какая разница, всё одно переписывать на Rust пришлось бы. )
Объясните пожалуйста, чем отличается экзоядро от микроядра?
В экзо ядре всё модули, в микро ядре есть некоторые вещи которые включены в само ядро.
Нет. В микроядре всё, кроме самой основы, реализуется как отдельные процессы, а в экзоядре - как библиотеки.
Спасибо за ответ, есть над чем подумать.
Т.е. ошибкоустойчивости модулей микроядра все равно нет, все выполняется с привилегиями и адресным пространством ядра?
Выдержка из википедии:|Микроядра предоставляют лишь небольшой набор низкоуровневых примитивов/механизмов/компонентов/сервисов/модулей, например:
|* механизм для работы со страницами памяти (см. адресация памяти, виртуальная память) (выделение памяти процессам, обеспечение её изоляции/защиты);
|* механизм для работы с потоками (нитями) процессов (см. планировщик потоков (англ. scheduling)) (выделение процессорного времени потокам процессов);
|* механизм для взаимодействия процессов (англ. inter process communications, IPC) (обход изоляции памяти для организации обмена данными между процессами; реализуется через синхронный обмен сообщениями).А вот пример защищенного микроядра:
https://github.com/seL4/seL4
Не взлетит. Эпоха новых (десктопных) ОС прошла. Всё упирается в драйвера. А они есть в винде (хуже со старыми, зато ассортимент "современного десктопного" поддерживаемого железа побольше) и в линуксе (лучше с поддержкой древного железа).В этом смысле оно не хуже и ни лучше hurd, minix, haiku, syllable и т.п.
Sad, but true :(
> Всё упирается в драйвера.От драйверов как раз сейчас ничего не зависит, всюду виртуализация.
Дваждую. Тут скорее вопрос в том, есть ли реальный профит на фоне Линукса или Виндоуса? Пока, разумеется, нет. Но, возможно, в перспективе есть нечто особо удачное для некоторой схемы использования. Тот же QNX живет и здравствует в разных устройствах. В самолетах имеется Deos, в маршрутизаторах куча специализированных поделок.
Что за Deos?
Я забыл слово десктоп подчеркнуть. В качестве хост-системы сабж не поставишь (драйвера, 3d-ускорялки, звук), а в качестве гест-системы сабж (и ему подобные) годится только на "запустить, потыкать и удалить".
Да что ты так нервничаешь?
Не взлетит так не взлетит.
А драйвера и сфера применения это всё дело времени, если заинтересует разработка.
А то нервничают некоторые будто бы твоё время и деньги на это тратят или заставляют над этим работать.
Я не нервничаю, я вангую.Разработка ради разработки - такого хватает ;)
Вот как разработка тут интересно учитывая направленность Rust.
Мало ли вдруг Rust станет новым C или по крайней мере спровоцирует какое-то изменение в этой сфере.
для микроядерных и экзоядерных ОС новые дрова легче накатывать. они же как внешние сервисы будут работать.
мысль интересная, только почему "tcp://10.85.85.1/80" а не "tcp://10.85.85.1:80" ??? нафига ломать сложившиеся форматы?
Написано же
> Redox развивается в соответствии с философией UnixА какой же это юникс-вей, если все будет просто и интуитивно?
> А какой же это юникс-вей, если все будет просто и интуитивно?Очередной непопавшийвдрузья, так понимаю.
Мишаня, а в чём конкретно мои анонимные братья неправы? Нафига порт слэшем отделять вместо двоеточия?На сегодня 80 и 443 порты в браузере никто не пишет, а после первого слэша уже идёт путь, но никак не порт.
Или это просто опечатался автор статьи?
> Мишаня, а в чём конкретно мои анонимные братья неправы?А тут какой-то персонаж бегает и выкрикивает -- "юниксвэй, юниксвэй", не понимая даже того, что юниксвэй -- это забивать гвозди молотком, а не микроскопом. Речь была именно об этом.
Про схему самому интересно -- с разбегу могу лишь предположить, что по TCP адресации дальше порта нет (хотя... сессии адресовать?), поэтому и решили это подчеркнуть.
> Мишаня, а в чём конкретно мои анонимные братья неправы? Нафига порт слэшем
> отделять вместо двоеточия?
> На сегодня 80 и 443 порты в браузере никто не пишет, а
> после первого слэша уже идёт путь, но никак не порт.
> Или это просто опечатался автор статьи?А причем тут браузер вообще? Тут аналогия с путем к файлу
http://127.0.0.1/80/test.com
если вдруг запилят разбор уровнем выше. И тут твои привычки и то, как там пишут в браузерах, совершенно не к месту.
Если не пишут - зачем тогда и протокол? Если "всё есть файл",то напоминаю, что в никсах НЕТ структур для чтения/записи файлов. Пишутся только блоки байт произвольной длинны, и ни о каких протоколах открытый fh/сокет понятия не имеет.
> Если не пишут - зачем тогда и протокол? Если "всё есть
> файл",то напоминаю, что в никсах НЕТ структур для чтения/записи файлов. Пишутся
> только блоки байт произвольной длинны, и ни о каких протоколах открытый
> fh/сокет понятия не имеет.Да. Это какой-то UnixWay в понимании разработчика форм на JavaScript.
> мысль интересная, только почему "tcp://10.85.85.1/80" а не "tcp://10.85.85.1:80" ???
> нафига ломать сложившиеся форматы?Это более логично, так как порт является спецификой tcp/udp, но в большинстве других протоколов отсутствует. Использование формата с двоеточием было бы сродни буквам дисков в винде вместо единой корневой системы.
указание порта в урле, наподобие "http://mysite.com:8081/", соответствует стандарту.
Так что, "tcp://10.85.85.1/80" - очень даже не логично
Что только не придумают, лишь бы не писать на C.
Чего только не придумают, чтобы не жить в Омске, да?
> Чего только не придумают, чтобы не жить в Омске, да?Сильный аргумент, вряд ли он омским линуксоидам будет по зубам :)
А ты сам на С хоть что нибудь написал кроме хеллолуролд?
Ты правильно понял.
А давайте напишем операционку на perl'е -- всё есть regex. ;-)
Лучше на Java + Groovy для клиентской части :)
> Лучше на Java + Groovy для клиентской части :)Вношу встречное предложение - лисп, и только он. Если не найдутся желающие, то можно попробывать на Алголе забацать, тоже рулез.
> Вношу встречное предложение - лисп, и только он.Поставьте уже Emacs и почитайте про Symbolics, что ли. :)
> Поставьте уже Emacs и почитайте про Symbolics, что ли. :)Emacs поставить! Ну у тебя и шуточки :)
Хм, лисп говоришь сейчас посмотрим... НЕТ ФИГУРНЫХ СКОБОЧЕК??? Фуу это не язык это уг какое то! :D
Clojure бери?
> и основывается на принципе "все есть URL"сделали как в PHP
В PHP эта парадигма привела к серьезнейшим дырам в безопасности.
Как понимаю, ОС написана на расте, значит и может запускать только программы на расте, ведь так? Сложно ли будет добавить поддержку си?
> Как понимаю, ОС написана на расте, значит и может запускать только программы
> на расте, ведь так? Сложно ли будет добавить поддержку си?Сишечка не нужна, Она померла, сразу вслед за паночкой.
> Как понимаю, ОС написана на расте, значит и может запускать только программы
> на расте, ведь так? Сложно ли будет добавить поддержку си?С чего бы такое ограничение?
Какого рода поддержка ожидается для программ на C? JVM? ))
думаю, есть смысл сюа смотреть: http://kgv.github.io/rust_book_ru/src/ffi.html
Низкоуровневые драйвера на Rust? очень смещно!
> Низкоуровневые драйвера на Rust? очень смещно!"Очень смещно" в течение нескольких последних версий падающее при попытке загрузки ядро с ошибкой типа null-pointer dereference в одном из драйверов.
>> Низкоуровневые драйвера на Rust? очень смещно!
> "Очень смещно" в течение нескольких последних версий падающее при попытке загрузки ядро
> с ошибкой типа null-pointer dereference в одном из драйверов.Рантайм с собой тягать на каждый чих?
> В более ранних версиях языка поддерживались легковесные потоки, но потом от них отказались в пользу нативных потоков операционной системы.
Cишечка опять всех обыграла низким уровнем.
Рантайм, можно не таскать.
>> Низкоуровневые драйвера на Rust? очень смещно!
> "Очень смещно" в течение нескольких последних версий падающее при попытке загрузки ядро
> с ошибкой типа null-pointer dereference в одном из драйверов.Это допольнительные расходы ресурсов на проверки null-pointer dereference,
На C борются с nullptr. В Rus буут бороться с обходом проверки nullptr для повышения эффективности.
>>> Низкоуровневые драйвера на Rust? очень смещно!
>> "Очень смещно" в течение нескольких последних версий падающее при попытке загрузки ядро
>> с ошибкой типа null-pointer dereference в одном из драйверов.
> Это допольнительные расходы ресурсов на проверки null-pointer dereference,
> На C борются с nullptr. В Rus буут бороться с обходом проверки
> nullptr для повышения эффективности.Проверка nullptr происходит при компиляции
всех? точно?:)
да
Из man malloc:The malloc() and calloc() functions return a pointer to the allocated memory that is suitably aligned for any kind of variable. On error, these functions return NULL.
Если ты вдруг не в курсе, эти функции вызываются программой во время исполнения, а не компиляции.
Ошибки после вызова этих функций это какой-то уже примитив совсем. Гораздо хуже ситуация когда оказывается что в далеке от этих malloc и calloc в силу логики оказывается разыменование нулевого указателя.
> Представлена новая операционная
> система Redox , примечательная использованием для разработки
> языка Rust.То что в Rust "не позволяет язык" - в С ловится анализаторами и культурой.
Зато абсолютная уверенность молодых фанатов Rust, что язык их спасет от ошибок - приведет к зашкаливанию логических ошибок, пренебрежению архитектурой и породит дурную славу.
>>на языке TomlА чем их [BA][Z]SH не устроил?
Или решили, раз уж делать велосипед, то делать его до конца? :D
Так TOML же простой как палка, парсер на Rust уже есть.
Сам Тим Бернерс-Ли сожалеет о двойном слеше, а тут это оправдывают глупостью "все есть URL"...
Двойной слэш после схемы нужен да-а-алеко не во всех схемах. Но автор, видимо, об этом не знает, и даже url вида mailto:somebody@example.com никогда не видел.
Братцы, а как вам "Фантом", лично мне нравится идея бессмертия. По сути, если запилить ядро имеющее драйверы, или способное подключать их по надобности и загружать виртуальные машины, вот и среда для работы прикладного софта. Главное, загрузить любую платформу с необходимыми ей элементами. Как я понимаю, нет особой разницы, библиотеки это, или модули. В конечном итоге, всё оно будет всего лишь порядком движения электронов в железном организме. Разница в реализациях мне видится с двух позиций. Логичность и удобство для работы с кодом (язык, идеология, мышление), как средство, с одной стороны. И эффективность при оптимизации ресурсов, как цель, с другой стороны. Важен результат выполненной работы, при наименьших затратах на выполнение. Чем прямее дорога, тем быстрее путь, лишь дорогу проложи. И разнообразие проектов можно только приветствовать, если таковое способствует развитию. Например, результат определённых движений в спортзале - умение правильно падать - может очень пригодиться в жизненной ситуации. Но, лучше, если не пригодится, мы ходим не для того, чтобы падать. Вот причина мертворождённости многих проектов. Они не применяются в жизни. Человечество очень лениво. И, рискуя упасть на скользкой дороге, большинство идут не в спортзал, а скорее домой, к своим телевизорам или к компьютерам с Windows. Редко, но есть предпочитающие к "[xx@xxx ~]$" или к "A:\" добавляя команды, делать свой выбор. В конечном итоге, мы все смотрим на квадрат Малевича...
Так вот она какая ЦА Фантом ОС.
http://lurkmore.to/%D0%A0%D1%83%D1&...
"все есть URL"Помнится, в 70-ых одни недалёкие товарищи думали, что "всё есть файл" - даже ЮНИКС написали. Оказалось, далеко не всё есть файл и "трубы" - тоже совсем не универсальный инструмент обработки данных.
Структура URL имеет свою чёткую сетевую ориентированность. На уровне ОС нужна ИЕРАРХИЯ, а не просто "бла-бла://".
> Оказалось, далеко не всё есть файл и "трубы"
> - тоже совсем не универсальный инструмент обработки данных.Ага, когда руки кривые и не лезут в прямую трубу, то виноват конечно же глупый изобретатель этих самых труб, а не индивид, почему-то решивший запихнуть в туда руку ...
> Структура URL имеет свою чёткую сетевую ориентированность. На уровне ОС нужна ИЕРАРХИЯ,
> а не просто "бла-бла://".С:\очередной_не_читатель ?
https://github.com/redox-os/redox/wiki/URL
> this is an extension to the Unix-like file hierarchy to hopefully allow for more obvious abstractions.
> в 70-ых одни недалёкие товарищи думали, что "всё есть файл"В 70-х думали и прикинули что любое взаимодействие можно представить через элементарные операции (open, read, write, close) - это интерфейс взаимодействия. Все эти операции работают очень одинаково - выполняются вышеуказанные операции через дескриптор. Дескриптор отображали на файловой системе чтобы можно читать и писать в него используя стандартный набор unix-утилит (cat, split, ar, ..). Но "нео-программистики"-недоосиляторы того времени (как PHP-шники в наше время) глазами видели везде файлы и из-за этого повилась уверенность в том что все есть файл так, хотя это были лишь дескрипторы.
ЗЫЖ Теперь мы знаем кто вы.
Кстати, это идея. Написать с нуля ОСЬ для серверов с изначальным прицелом на то, что будет запускатьсятолько в виртуальном окружении. Тогда вполне можно выстрелить и обогнать Linux. На 100500 дров и графику не тратить время...
xenс разморозкой
И? Что-то там сплошняком Linux гоняют внутри, а не специализированную ось.
