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

+1. Только добавлю, что человек явно слаб в техническом плане.


Работает нормально на всех x86-совместимых системах. И на Pentium 2 (заявлено, что и на 386/486 — но ни у кого такого железа нет), и на i5. 


Можно пример того, как тупят? Задержка на IPC составляет порядка 500 нс (в MINIX 3), а это ерунда в сравнении со временем выполнения большинства операций ввода-вывода. Для микроядер считается, что потеря производительности составляет 5-10%. На современных машинах куча ядер, 3 GHz, дешёвая оперативная память.
Кроме того, написание и отладка серверов/драйверов для микроядра мало чем отличается от написания обычных пользовательских программ: используешь нужный API, дебажишь обычные user-space процессы. Это значительно улучшает читабельность и качество кода. Сравните реализацию любой ФС под MINIX и под Linux/FreeBSD.

Добавлено через 1 минуту и 22 секунды

GrayCardinal, я не понимаю, как можно сравнивать ОС, глядя на софт, который под них портирован? Речь о том, что под капотом.

powerfox,

>Работает нормально на всех x86-совместимых системах. И на Pentium 2 (заявлено, что и на 386/486 — но ни у кого такого железа нет), и на i5.

Я утрировал, если это вдруг было непонятно. А x86 она и на втором пне, и на корке и5 x86. И речь шла не столько о поддерживаемых архитектурах (я хз, насколько это чудо техники легко портировать на amd64 или arm), сколько о поддерживаемой переферии (видеокарты, сетевухи, вайфаи и т.д.).

>Можно пример того, как тупят?

Примеров у меня нет. Насколько я знаю, основной косяк в том, что модуль микрояда выполняет все задачи в очереди, многопроцессность в монолитных ядрах позволяет нескольким процессам "одновременно" получать доступ к чему-нибудь, за что в микроядре отвечал бы соответствующий модуль. Емнип, Торвальдс то ли в джаст фо фане, то ли в своем сраче с Таненбаумом приводил пример с ФС: в микроядре задачи на чтение/запись выстраиваются в очередь, в результате чего последние в очереди курят, пока полностью выполнятся заявки предыдущих. Потому, с другой стороны, и реализация в монолите сложнее.

>Для микроядер считается, что потеря производительности составляет 5-10%

Всего-то? Жалкие десять процентов! А я бы нашел им применение!

>На современных машинах куча ядер, 3 GHz

На мультисовременных это может и так, а у просто современных это нифига не так. К тому же тенденция по набору гигагерц приостановилась.

Производительность всё равно растёт. И никто никогда не разрабатывает серьёзное ПО для того, что есть. Пишут для того, что будет. Что сингулярити, что миникс ориентированы на будущее.


Процессы тоже составляют «очередь», только никто для них не использует FIFO/LIFO — и всё почти нормально (хотя голодание всё равно возникает).


Этот вопрос никак не связан с плюсами/минусами идеи микроядра. MINIX 3 является исследовательской платформой, на примере которой собираются продемонстрировать реализацию отказоустойчивости. Если начнут использовать в production, то будет поддерживаться и переферия.


У меня запущены браузер, konsole, vim, mplayer, ktorrent, kopete. Раньше я работал на Celeron 1.6M и не испытывал дискомфорта, сейчас у меня i5-660 (купил только из-за наличия виртуализации, для работы использовал VMWare) — как думаешь, какая разница в производительности? 10% точно не жалко.

С другой стороны, я не помню, чтобы линукс помирал, а если и помрёт, то мне не критично. Но есть системы, где это критично.

Добавлено через 10 минут и 54 секунды

Немного не так. В монолитном ядре процесс А выполняет системный вызов, который обрабатывается ФС. Мы переходим в режим ядра, где выполняется этот вызов. В это время нас никто не может прервать, по сути, мы монополизируем ФС. Когда мы выходим из режима ядра, диспетчер может запустить процесс B.
В микроядре системный вызов процесса А преобразуется в сообщение, которое будет обработано, когда управление перейдёт процессу ФС (за это время может придти запрос от B). Если процесс ФС не успеет за отведённое ему время обработать запрос, то произойдёт переключение, например, на C. "С" тоже может захотеть поработать с ФС. При этом во встроенных системах может оказаться так, что запрос от С нужно обработать в первую очередь, микроядро позволяет прервать обработку запроса от А и обработать С, а уже потом снова вернуться к А. В монолитном, на сколько я знаю, это невозможно. У всего есть свои плюсы и минусы.
Замечу, что разница c монолитным обычно равна лишь цене переключений пользователь-ядро (при «умном» планировнии процессов).

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

ты про preemption или о чем? есть она в линухе.

действительно открытый вопрос - насколько хорошо работает микроядро с множеством вычислительных единиц (см. "ядер"), и множеством устройств ввода/вывода, т.е. в условиях параллелизьма.
думаю, что усложнение схем связи между элементами системы как раз проявляется в таких условиях, и является тем, кто отвечает за эти потери в 5-10%. хотя я не совсем знаю о чем я говорю , надо код читать, а нет на это сейчас желания.

5-10 на одноядерных/однопроцессорных системах.


Таненбаум на FOSDEM 2010 обозначил это как одно из направлений исследований.


Если честно, не знал. В «Understanding the linux kernel» было написано, что ядро является nonpreemptive, не думал, что изменили.

какого издания ?

Добавлено через 2 минуты и 23 секунды

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

Так шедулер, в принципе, здесь не при чём. 

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

кто же отвечает за эти аспекты ОС как не шедулер ?

За эти — шедулер. А вот за преемтиновсть — не он. Поскольку ядро не является процессом, шедулер ничего о нём не знает. Обработчик прерывания может снова включить прерывания, а может и не включать. Он выставляет флаг, что мы находимся в режиме ядра, что влияет на сохранение контекста.

  
Блин!
Класс!!!
Всё интересно, с примерами, аргументированно!!!
Нравится мне задавать вопрос и затем следить за тем, что потом с обсуждением происходит.
  

дополню

в x86/entry_64.S есть функция common_interrupt, которая вызывается из idt-обработчика прерывания, т. е. для _любого_ прерывания
преемптивность (вытеснение процесса, работающего в режиме ядра) определяется действиями, выполняемыми после вызова do_IRQ в ее контексте, т. е. тут

retint_kernel в зависимости от CONFIG_PREEMPT определена или тут, или тут
т. е. преемптивность в принципе возможна только при установленном CONFIG_PREEMPT, а он прямо _не связан_ с шедулером
шедулер определяет когда процесс должен быть вытеснен, а само вытеснение возможно, когда процесс к этому готов, а это не регулируется шедулером

что то я проржавел. почему-то думалось, что именно шедулер это делает.

MAKCim, 
powerfox, 

ok врубиссимо! надо перечитать часть одной книжины, и немного поковырять ведро.
а то совсем уже расслабился.