Ибо сколько уже их было микро, нано, экзо...

экзо - это тема, а микроядра отсохнут так и не взлетев.

Всё-то вам, шиндузятники, скриншотики окошечек подавай. Это, блджад, операционная система, а не очередная красивая хипстерская оболочка для жмупинуса.

библиотека Newlib для программ на C (аналог libc);

Скорее для программ на раст. И да, скорее всего не аналог либц, а налог glibc и да - это не аналог а недоделка(хотя она типа ембедед и можно отмазаться, но растОС-то под x86).

Для фом неверующих:

http://pastebin.com/aG4D329R

$ gcc -O2 ../main.c -o glibc
$ gcc -O2 ../main.c -Dnewlib -o newlib
$ time ./glibc 
18263340623574429904

real    0m1.392s
user    0m1.390s
sys     0m0.000s
$ time ./newlib 
18263340623574429904

real    0m6.678s
user    0m6.670s
sys     0m0.000s

И так во всём. А уж с Os как многие любят - оно и до завтра не посчитает.

драйверы работают в пространстве пользователя;

Правда их нет.

доступны распространенные команды UNIX;

Не доступны, а тяп-ляп портированы на раст и то самые простые.

In constrast to Linux, which has a code base with 100% unsafe code, due to the nature of C.

Нет, unsafe там не потому, что си, а потом что надо работать быстро и хорошо.

Rust has enormous advantages, because for operating systems safety matters. A lot, actually.

Ога. Ведь это 100% не пиар-проект, а что-то большее. Верю-верю. А в невероятное кол-во слоганов и мантр в /book - это просто пацан идеей проникся.

Лол. Не нужно же.

Эти ассемблерные вставки вне каталога /arch, ммм!!

Не страшно. Если пойдёт дальше концепта - причешут. :)

Не будет.

будет

http://www.redox-os.org/book/book/design/kernel/disadvantages.html

http://www.redox-os.org/book/book/introduction/will_redox_replace_linux.html

вообще, неплохо было бы увидеть аргументы в пользу того, что тормознутость микроядер - миф

Просадки при переключении контекста на современном железе хоть и не так критичны но их там больше + в микроядре большей проблемой явлеется оверхед на копировании буфферов ввода/вывода.

Вот представим себе чистой воды микроядро - каждый драйвер/модуль это отдельный юзерспейс процесс. И нашему приложению нужно записать блок данных на диск, как это будет происходить:

1 Приложение дергает системный вызов write
2 Ядро находит модуль который обслуживает данный файловый дескриптор (скажем драйвер ext4) и делает memcpy данных в адресное пространство ext4
3 EXT4 подхватывает эти данные находит нужный блок на блочном устройстве и вызывает write для блочного устройства
4 Ядро находит модуль (lvm) и memcpy данные ему
5 lvm подхватывает буффер находит и перенаправляет write нижестоящему устройству
6 Ядро находит модуль (SoftRAID1) и опять memcpy
7 SoftRAID1 подхватывает запрос и формирует два wite для sda и  sdb
8 Ядро находит модуль (SATA) и делает два memcpy в адресное пространство SATA драйвера
9 SATA драйвер формирует in/out запрос и отправляет данные через ядру
10 Ядро пересылает данные на SATA контроллер

Как видно для простой записи на диск у нас потребовалось 10 переключений контекста + 4 memcpy. А теперь представте себе что вызов wite был блокирующий без буферизации в таком случае цепочке придеться раскрутится назад чтобы уведомить процесс о том что операция была успешно завершена (еще +10 переключений контекста).

PS Это конечно реализация «в лоб» и ситуацию можно улутчшить используя шареную память и консолидирую модули (например всю систему дискового (с драйверами FS,Volume Manger, RAID, SATA) IO запихнуть в один процесс) но это уже будет не совсем «идеологически верным» решением для микроядерной архитектуры + там тоже будут свои оверхеды.

После некоторого погружения в их доки (бóльшая часть которых пока в TODO), складывается ощущение, что ребята настроены серьёзно. Хотя и пугают нелогичностью:

«The goals of Redox
We want to be able to use it, without obstructions, as a replacement for Linux on our computers.»

И далее:

«Will Redox replace Linux?
No.»

:) Сшейте мне шаблон обратно!

Вот так вот... пока Ди пытается быть «Лучшим С++», другие взяли и накодеРАСТили 45МБ сорсов. :) Хотя по идее, Ди куда мощнее и хотя бы для аппликух я б выбрал именно Ди.

Что ещё смущает? Когда абстрагируются слишком высоко и слишком абстрактно. «Всё есть URL» через 10 лет будет звучать так же ржачно, как сейчас «всё есть файл». Да ниструя! Мой дисплей не есть файл, хотя ужимки вроде read/write и могут слегка поддержать концепцию. Все устройства требуют свой подход, у них свой API и нет никакого смысла чинить авто через выхлопную трубу, когда можно просто открыть капот.
Redox добьётся определённого успеха (уже в силу того, что ребята понимают насколько Линукс - унылое гогно), но вот базовая концепция... мне она не нравится и кажется очередными костылями в попытке «универсально взглянуть на мир».

гугли QNX

Шревты божественны!

Убил без пистолета! :) На тебе Розенталем по кумполу!

Ни одного сглаженного пикселя. А сглаживание - это либо радуга, либо мыло. Так что божественны...

Месье - кубист и ловит кайф от ступенек?? Ню-ню...

чинить авто через выхлопную трубу

О, вся суть слюникс-вей. Сам придумал?

забавно слышать такой бред от пятизвездочника.

Так тут все пятизвездочные - ламерюги. Не знал? Знай. Тылгунер ещё не самый глупый, просто немножко в маразме.

Прикинь, сколько времени уходит на набивание этих звёзд. И это только ЛОР, а ещё социалочки, бложики. Им скиллы то и некогда качать. Так что многозвездный = социально-активный идиот.

Ребят, для тех, кто переживает за дрова:
Автор(ы?) сам говорит, что «будут поддерживать совместимость с Линупсом ровно до тех пределов, пока это не начинает граничить с корректностью». Системные вызовы (аккуратно отфильтрованы и) перенесены - это и будет базой для дров:
Берём линуксовый драйвер на ламповой Сишечке, конвертим в Раст, чуть приправляем асмом, внедряем в Редокс и вуаля - «драйвер коврика 1.0»!
Дрова уже написаны и даже немножко отлажены :) , это сильно снижает нагрузку по расширению Редокса железом. Так что это уже не «старт с нуля».

Ну и как я говорил, система вполне может взлететь, ведь не зря столько копий сломано на поприще «линукс vs венда» - именно потому, что НИ ОДНА существующая система не годится для «простого обывателя» - слишком много ньюансов и компромиссов, легаси и коммерческой целесообразности.

К слову, сейчас смотрю код Раста - да почти тот же Си, только без маразмов с памятью - сишникам будет оч легко переключиться на новую платформу. Время тухлых Сей и пухлых линупсов прошло, из форточки повеяло переменами! :)

Ты чё не спишь?

А чем плоха шареная память? Чем бы дитя ни тешилось, лишь бы безопасно! Поэтому «передать данные на запись» вовсе не означает memcpy: мы даём другому процессу доступ к той же памяти и так по цепочке, пока не запишется.
Кроме того, при нынешних 4-гигагерцовых кирпичах, можно уже и посмеяться над мифами о контекстах - не так страшны переключения, как бажный, бестолковый софт. Пусть всё будет даже на 10% медленнее, но на 146% надёжнее!

Берём линуксовый драйвер на ламповой Сишечке, конвертим в Раст

Ну-ну, и кто же будет заниматься такой интересной работой?

сейчас смотрю код Раста - да почти тот же Си, только без маразмов с памятью

Сейчас смотрю код Жавы - да почти тот же Си, только без маразмов с памятью.

Надо же, выглядит юзабельно.

но это уже будет не совсем «идеологически верным» решением для микроядерной архитектуры

используя шареную память

что не так с cow-страницами?

as a replacement for Linux on our computers

our

никакого противоречия с

«Will Redox replace Linux?
No.»

тут нет

«Всё есть URL» через 10 лет будет звучать так же ржачно, как сейчас «всё есть файл»

Мой дисплей не есть файл

а что мешает назначить ему url и обращаться по протоколу, соответствующему схеме доступа?

Сейчас смотрю код Жавы - да почти тот же Си, только без маразмов с памятью.

И как часто раму докупаете?

Надо будет поставить кому-нибудь из знакомых для теста на живых людях. Оборзеватель интернетов есть?

а что мешает назначить ему url и обращаться по протоколу

О хоспаде... Дебилов, которым всюду файлы мерещились, сменили идиоты, натягивающие на все свой долбанный rest.

новая UNIX-подобная операционная система

Чота не вижу поводов для гордости. По-моему, это эпичный фейспалм. Кому сегодня может понадобится очередное слюникс-лайк убожество?

systemd уже портирован?

ты или не знаешь что такое rest, или не удосужился узнать, о чем идет речь в треде. anyway, можешь сам захлебнуться в своем словесном поносе, только без моего участия

Покажи лучше пример взаимодействия с дисплеем на быдло-урлах, икпсерд по рест.

Покажи лучше пример взаимодействия с дисплеем на быдло-урлах, икпсерд по рест.

А что там показывать, от клиента к серверу:

PUT /window/<id>/data?x=100&y=100&width=200&height=50
<RGBA binary data>

От сервера к клиенту:

PUT /mouse/pos
{ x: 50, y: 50 }

Только ес-но это нахрен не нужно.

anonymous

двух дебилов, уверенных что url бывает только в rest, быть не может

двух дебилов, уверенных что url бывает только в rest, быть не может

Пример был для анонимуса, который не понимал как это сделать через REST (впрочем и не только). А твоя неадекватная реакция говорит о тебе самом.

твой пример - офтоп в энной итерации, и тоже про rest зачем-то

анонимус все прекрасно понимает, просто строит дурочку. а если и правда не понимает - тут уже никакие примеры не помогут, тем более примеры, поддакивающие его непониманию

QNX

За пределами гипервизоров и всякого там эмбидеда оно толком не взлетело.

Как и linux за пределами всяких серверов. У всех своя ниша.

вообще, неплохо было бы увидеть аргументы в пользу того, что тормознутость микроядер - миф

вот высплюсь и если будет настроение, то поспорю на эту тему. Хотя...

Главное в системах на микроядре не то, где работают драйвера - в отдельных адресных пространствах или в адресном пространстве самого микроядра (по вашему - kernel space и user space), а то, как реализовано взаимодействие процессов/нитей. Всё вкусное именно в реализации этого взаимодействия.

От неё за километр несёт фрибиздёй.

Почему Minix 3, Genode OS и Haiku не могли взлететь? Особенно последние две могут похвастаться даже поддержкой Gallium 3D и Qt 5 например, просто это показательно.

Haiku технологически 95-я винда. На словах там ООП, а на деле даже прав доступа к файлам нет.

Genode OS — конструктор, не система общего назначения.

В Minix 3 до недавнего времени даже динамического связывания не было.

Всё это мертворождённое.

Только http://www.helenos.org/ имеет небольшие шансы взлететь. Лет через 10 будет видно. Остальное умерло сразу при родах.

А тупить не будет из-за переключений контекста? Эх вот бы кто написал маленькую ОС полностью живущую в привилегированном режиме с минимумом защиты от себя, чтоб реалтайм был шустрый. На концерты в виде синтезатора самое оно.

https://en.wikipedia.org/wiki/Single_address_space_operating_system

Это мода нынче такая: писать слюникс-лайк оси на всём, что по рукой? Тогда с нетерпением жду ось на Befunge или на Malbolge.

Но проще будет пееписать...

Но это реально миф, основанный на микроядрах 1 поколения (привет любителям H.U.R.D. и Mach!) с появлением ядер типа L4 проблема тормозов в IPC была решена.

К слову, сейчас смотрю код Раста - да почти тот же Си, только без маразмов с памятью - сишникам будет оч легко переключиться на новую платформу. Время тухлых Сей и пухлых линупсов прошло, из форточки повеяло переменами! :)

Нет, это С++, только хуже, и вообще, толсто.

Берём линуксовый драйвер на ламповой Сишечке, конвертим в Раст, чуть приправляем асмом, внедряем в Редокс и вуаля - «драйвер коврика 1.0»!
Дрова уже написаны и даже немножко отлажены :)

А ничего, что линукс - монолитное ядро?

Не взлетит.

Микроядерная архитектура. Значит имеет смысл только как концепт.

ну я и говорю, можно страницы шарить. кажется, это оптимальный по скорости вариант.

проблема будет в интеграции энтого дела с libc, построенной на буферах, которые вряд ли в разных процессах окажутся выровненными по одному смещению в пределах страницы. хотя я так понял, авторы не боятся при необходимости переделывать концепции, и это немного обнадеживает. но про posix тогда речи вообще идти не будет: read должен будет возвращать свой буфер, а не писать в пользовательский.

так или иначе, по сравнению с монолитным ядром замедление IPC на блокировках IO должно быть порядка двух раз, потому что эти блокировки придется реализовывать обращениями к планировщику.

хотя это тоже можно сделать тупо записью в шареную память.. может и правда все не так мрачно. в теории вообще получается, что микроядро будет быстрее, но с трудом верится

То то в линюк системные вызовы добавляют, что бы при отсылке файлов на один системный вызов меньше слать. А уж у драйверов...

А тупить не будет из-за переключений контекста?

будет

Не будет.

Значит с безопасностью беда будет.