mono vs micro (kernels)

Мы с вами полностью согласны.

Ждем ваше микроядро

Мда.
Прочитал - "Жмём ваше микроядро".
Надо завязывать с работой.

В чешуе как жар горя
Трицать три богатыря
Ядра - чистый изумруд
Белку вочередь #%$т.

Скоро, видать выйдет micro-alphex =))))))))))))))))

Экзоядра рулят, всё остальное прошлое тысячелетие.

>Экзоядра рулят, всё остальное прошлое тысячелетие.

Это чо?

> / модульность

Linux монолитен, но модулен при этом не менее.

> / стабильность

Если отвалится драйвер ФС, то даже если ядро не упадет в паник, я буду плакать...

> / масштабируемость

Все может быть (tm) Но без работающего примера что-то трудно сказать ;)

> / простота и удобство разработки

Нужен работающий пример, однако.

> минусы его же

> / производительность

Даже если ты сделаешь заказ на весь спам, предлагающий тебе Enlargement чегототам, и отрастишь чтототам рекордной длины, этот минус будет длиннее =)

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

Микроядро не рулед.

>масштабируемость

??? с какого это ???

Микроядра не масштабируются на smp нормально.

>модульность

mono-ядра тоже бывают модульными.

>стабильность

Это 'мнимый' плюс.Если у Вас есть рабочий сервер и в нем отвалится какой-нить _нужный_ драйвер, и микроядро будет работать, то это равносильно kernel panic в monokernel.

>простота и удобство разработки

ну тут на вкус на цвет...

>Linux монолитен, но модулен при этом не менее.

ну не совсем так.

>Все может быть (tm) Но без работающего примера что-то трудно сказать ;)

plan9

>Нужен работающий пример, однако.

plan9

в природе нету ниодного нормально масштабируемого и нормально работающего с кластером монолита.

>Микроядра не масштабируются на smp нормально.

приведи аргументацию ? это еще почему ? все ведь наоборот, на микроядре можно построить проще и удобней необходимый abstraction layer и для smp и для распределения по нодам.

man exokernel

Смешно, пиши еще!

/ модульность - интересно, в чем именно плюс модульного микроядра относительно модульного монолитного. Сказок про обработку отвалившегося драйвера ФС - не надо.

/ стабильность - НИКАКАЯ ТЕХНОЛОГИЯ НЕ ДАЕТ СТАБИЛЬНОСТИ. Стабильность - вопрос реализации и архитектуры "в малом", а не в "большом".

/ масштабируемость - еще одно модное слово

/ простота и удобство разработки - ага, особенно в районе взаимодействия модулей и протоколов. Задача-то проще не стала от того, что ее пошинковали в труху.

Выводо: alphex_kaanoken - маркетойд, который прочитал умные слова. Советую ему пропогандировать Web 2.0 и прочие убогие, но модные понятия.

З.Ы. Нет ни _одной_ работающей микроядерной ОС с более-менее зоопарком железа.

plan9 - это не работающий пример. То есть РАБОТАТЬ на нем нельзя. На нем можно только исследовать некоторые академические вопросы, а РАБОТАТЬ - нет.

/ стабильность - посмотрите на GNU Hurd

/ простота и удобство разработки - ага, посмотрите на GNU Hurd

Рабочий пример...

minix

щас скачаю-поставлю и посмотрим...

/ стабильность - посмотрите на GNU Hurd

/ простота и удобство разработки - ага, посмотрите на GNU Hurd

Рабочий пример...

minix

щас скачаю-поставлю и посмотрим...

Ээээ как пользователь plan9 ... скажу .. чёткой грани между mono и micro в plan9 нет. Есть скорее некая альтернатива - 9P2000 на котором говорят как и драйверы учтройств влинкованные в ядро, так и серверы файловых систем в userspace :) Да ещё, IMHO всё же микроядро не жизнеспособно БЕЗ per-process namespace :)

>Рабочий пример... minix

Не стоит приводить как пример (плохой) попытку посадить одну техгологию на другую ...

>щас скачаю-поставлю и посмотрим...

Во во .. попробуй .. :)

http://plan9.bell-labs.com/wiki/plan9/organizations_using_plan_9_and_inferno/

4.2 то есть.

>приведи аргументацию ?

>необходимый abstraction layer и для smp и для распределения по нодам

возьми например менеджер фс. Чтобы было нормальное масштабирование на 8-way smp необходими запустить 8 * nr_tasks_using_fs тредов. На моно ядре можно добиться того же самого без тредов.

> плюсы микроядер (не все просто самые основные) / модульность

Модульность - это не плюс. Это - ОСОБЕННОСТЬ. У которой есть свои плюсы и свои минусы.

> минусы его же / производительность

> вообщем монолитные ядра прошлый век.

И правда, нах нам производительность?

> Ждем ваше микроядро

Ядро, состоящее из сплошных анекдотов на C - я ХОЧУ это видеть! :)

>/ стабильность - НИКАКАЯ ТЕХНОЛОГИЯ НЕ ДАЕТ СТАБИЛЬНОСТИ. Стабильность - вопрос реализации и архитектуры "в малом", а не в "большом".

Ну, это неправда. Стабильность - это результат архитектуры и в "малом" и в "большом".

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

Небольшой оффтоп:

Кстати, как это может работать для распределенных систем хорошо видно по работе Joe Armstrong-а "Making Reliable Distributed Systems in the Presence of Software Errors (2003)". Ну и вообще по идеологии Erlang/OTP :)

>Сказок про обработку отвалившегося драйвера ФС - не надо.

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

>Стабильность - вопрос реализации и архитектуры "в малом", а не в "большом".

в том то и дело что архитектура монолитов в принципе не способона дать такой скажем коэффициент стабильности как микроядро.

>еще одно модное слово

приведи мне хоть один пример моноядра которое умеет нормально работать на распределенных системах, а то что ес ть то костыли. всякие openmosix что не умеют треды мигрирровать даже не пытайся привести, всякие аки "распределенные фс" тоже не надо, ну не достаточна сама архитектура монолита для этого.

>ага, особенно в районе взаимодействия модулей и протоколов. Задача-то проще не стала от того, что ее пошинковали в труху.

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

>Выводо: alphex_kaanoken - маркетойд, который прочитал умные слова. Советую ему пропогандировать Web 2.0 и прочие убогие, но модные понятия.

Вывод - шаман седьмой флеймер и пустозвон не разбирающийся в сабже, но пользующий свои модераторские права для обсирания других.

я ни разу не маркетолог, а тебе советую учить матчасть.

>З.Ы. Нет ни _одной_ работающей микроядерной ОС с более-менее зоопарком железа.

это прости, но ни разу не аргумент, под виндой железа еще больще поддерживается и что ? она от этого лучше стала сразу ?

>И правда, нах нам производительность?

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

Такое впечатление, что микроядро для некоторых что-то вроде розовой сумки Луис Ветон: и круто и модно.

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

Расскажи, откуда возьмется драйвер ФС, если ФС загнулась? Из кеша драйверов? А если загнулся драйвер кеша драйверов? А что произойдет с запросом, на котором все загнулось?

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

Можно по подробнее о том, как:

1 - хорошо разделить задачу на подзадачи? 2 - С какого перепугу подзадачи станут простыми? 3 - Что такое "грамотно соединить": то есть где про это можно почитать, посмотреть рабочие примеры (НЕ миникс и план), а так же кто определит грамотность?

> это прости, но ни разу не аргумент, под виндой железа еще больще поддерживается и что ? она от этого лучше стала сразу ?

Вообще-то да, стала. Можно так сказать, так как ОС - инструмент для решения задач. Linux тоже стал лучше с 1999 года благодаря поддержке железа: в 1999 у меня была i740 и без бубна работал только VESA режим без аппаратного ускорения и это было очень хреново.

>Расскажи, откуда возьмется драйвер ФС, если ФС загнулась? Из кеша драйверов? А если загнулся драйвер кеша драйверов? А что произойдет с запросом, на котором все загнулось?

шаман сравни все эти если с одним тем что после того как грохнется драйвер фс в монолите ;)

>1 - хорошо разделить задачу на подзадачи? 2 - С какого перепугу подзадачи станут простыми? 3 - Что такое "грамотно соединить": то есть где про это можно почитать, посмотреть рабочие примеры (НЕ миникс и план), а так же кто определит грамотность?

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

>Вообще-то да, стала. Можно так сказать, так как ОС - инструмент для решения задач. Linux тоже стал лучше с 1999 года благодаря поддержке железа: в 1999 у меня была i740 и без бубна работал только VESA режим без аппаратного ускорения и это было очень хреново.

так и сиди себе в досе _работай_ - в чем проблема то? а фитчей необходимых нет - ну извини такая архитектура что поделаешь.

>Такое впечатление, что микроядро для некоторых что-то вроде розовой сумки Луис Ветон: и круто и модно.

тут дело не в том что "круто и модно" а все дело в том что более актуальней и удобней, круто это костыли вечные лепить к монолитам и выдавать их за инновации.

>Расскажи, откуда возьмется драйвер ФС, если ФС загнулась? Из кеша драйверов? А если загнулся драйвер кеша драйверов? А что произойдет с запросом, на котором все загнулось?

Хы. По крайней мере, тут мы имеем выбор. Можем упасть окончательно. Можем выдать ошибку клиенту драйвера ФС и продолжить без этого драйвера. Можем попробовать рестартануть драйвер ФС и выполнить заново запрос. Можем попробовать рестартануть драйвер ФС, но запрос пропустить, выдав ошибку клиенту.

В случае монолита у нас, в общем-то, выбора-то и нет - только первый вариант.

>продолжить без этого драйвера.

Класс! файл-сервер без фс!!

>Можем попробовать рестартануть драйвер ФС и выполнить заново запрос.

с вероятностью 90% он упадет снова.

>но запрос пропустить, выдав ошибку клиенту.

тем самым вызвать memory leak в клиенте(например после запроса close()).

>звизделки и перделки в кде

с этим то в микроядре проблем не будет. Проблемы будут с i/o, причем очень серьезные..

>Класс! файл-сервер без фс!!

Во-первых, файл-серверами все не ограничивается - я приводил пример с контрллером. Во-вторых, для самой системы у нас может использоваться другая ФС, что позволит администратору залогиниться на машину и по горячим следам выяснить суть проблемы. А в третьих, бывают драйвера и для других задач. Например, если отвалится драйвер какого-нибудь тюнера, то можно жить и без него (при этом остальная системы часть гарантированно изолирована от этого драйвера и спокойно продолжает работу).

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

>с вероятностью 90% он упадет снова.

Не уверен, статистику не собирал. Что такое race condition знаете? Как думаете, почему ФС так любят падать именно на больших нагрузках?

>тем самым вызвать memory leak в клиенте(например после запроса close()).

Это уже проблемы клиента. Если ему говорят "возниклапроблемапризаписи", а он при этом течет - это кривой клиент.

Короче, аргументы какие-то смешные. Я не говорю, что такой подход _всегда_ будет работать, так что не надо приводить какие-то конкретные примеры. Я просто рассуждаю на тему того, что этот подход лучше в _целом_ (по одному из параметру).

>Просто потому что они падают так, что валят к черту все ядро.

скорее всего все виснет по железу, и никакое микроядро тут не спасет.

>Что такое race condition знаете? Как думаете, почему ФС так любят падать именно на больших нагрузках?

race - это совсем плохо(надо рвать руки автору драйвера фс), будет еще потеря данных. Опять же если важны данные(а они важны при работе с фс)и драйвер фс в микроядре , падая, накроет фс, тот толку от таково сервака 0.

>Короче, аргументы какие-то смешные.

Хорошо. У нас есть 8xOpteron, 600 процессов(ерундовая загрузка).Подключено 4 фс(/tmp,/,/home,/var) Посчитаем, сколько тредов надо для менеджера фс(пока не учитываем async io): nr_fs_mounted*nr_processes_using_fs, 4*600=2400.Естественно, что они все не будут работать постоянно.Тогда получается 300 процессов на процессор.

...И это только фс, а еще есть сеть , драйвера для hdd,scsi... И теперь представьте, что менеджер фс упал и его надо перезапустить..

В монолите такую масштабируемость можно достичь без этого.

>скорее всего все виснет по железу, и никакое микроядро тут не спасет.

Угу. А винды работают как часы. К тому же падает оно не просто так, а после определенных действий (последние вроде бы уже не падают). С железом проблем не должно быть - это все-таки ноут, и ноут не самый дешевый, а не самосбор.

>race - это совсем плохо(надо рвать руки автору драйвера фс), будет еще потеря данных. Опять же если важны данные(а они важны при работе с фс)и драйвер фс в микроядре , падая, накроет фс, тот толку от таково сервака 0.

o_O. Я почти на 100% уверен, что, скажем, в reiserfs и xfs есть race condition-ы (ну или что-то похожее, потому как встречал отзывы о падениях оных на больших нагрузках). :)

Кстати, я не утверждаю, что предлагаемый механизм будет спасать 100%. Конечно, если драйвер ФС при падении успеет поназаписывать всякой лабуды его рестарт не спасет.

Ну а про перфоманс я ничего и не утверждал :) К тому же, живет же как-то Erlang с сотней тысяч процессов, и ничего. И перезпускается все как надо и когда надо :) Я, конечно, совсем не уверен что опыт Erlang/OTP можно так вот просто перенести на ядра, но что-то общее между подходом OTP и концепцией микроядра точно есть.

>А винды работают как часы

Дык это кривой драйвер вешает железо сначала.

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