HaikuOS

С каких это пор однопользовательская BeeOS/Haiku стали unix-like?

1. есть гнутый софт: основной компилятор — g++, python, bash и т.п. Собирается Qt, gtk 1 cобирался когда-то, gtk2/3 пилить надо (там не сложно, но нет рук/времени)

2. с точки зрения процессов, драйверов (модулей ядра), структуры ядра: это unix, только нитей много, и ими более активно пользуются. Родной API ядра на С++, драйвера на С++, GUI. Дефолтное GUI приложение многопоточное, как минимум две нитки: team (аналог процесса) состоит из нескольких нитей, GUI (AppServer) многопоточно их отрабатывает. В ядре есть аналоги FUSE, загружаемые модули ядра и т.п. Ядро — на основе микроядра NewOS, но больше всё-таки напоминает гибрид (из-за BSD подсистемы).

3. С точки зрения программирования, напоминает какую-то BSD. GUI программирование проще — на родном Be API, многопоточное из коробки. libc свой (libroot.so). pthreads портированный есть, но нативный АПИ не хуже.

Полный перевод тут http://habrahabr.ru/post/143176/

Виндовс тоже posix умеет (по крайней мере раньше там эта подсистема была).

ну да, ну да. Во-первых, SUA выпилили в восьмёрочке. Во-вторых, Interix вполне себе BSD, с костыльным старым gcc и башем, ничем не лучше какой-нибудь другой BSD.

«повсеместная многопоточность» aka 'pervasive multithreading'

The Haiku kernel allows each thread to run on its own core or processor—even threads within the same application.

Где это не так?

Haiku simplifies the process of writing multithreaded code by hiding most of the thread interaction so that the developer doesn’t need to worry about it.

Это достоинство ОС или библиотеки Qt?

Instead of directly accessing that data, Threads A and B each pass a message, which is placed in a central message queue and dealt with in a specified order. Without that mechanism, the two threads would attempt to access Thread C simultaneously, creating a deadlock, in which they both just wait endlessly

Как будто дидлок нельзя устроить на очередях сообщений.. Интересно о какой очереди «central message queue» речь - это что-то типа IPC, требующее переключение контекста или что-то вне кернела?

Ну вот там выше кто-то рвался поставить эту систему в виртуалке. Давайте спросим у него - ЗАЧЕМ? Ну в самом деле зачем ему гонять это уёбище в виртуалке?

ну мне например интересно повозиться с портированием. Вот есть линукс с линуксизмами, есть БСД, а есть нормальный мобильный, переносимый «из коробки» софт, который достаточно только перекомпилировать. Есть некоторые костыли в реализации той же хайки, например, загрузчик ELF далеко не ld.so, да и БСД подсистема далеко не полная.

Так это ведь хорошо! Если некий софт будет даже на этом огрызке собираться без проблем, значит:

а) подсистема огрызка достаточно полная, для практического применения. Вот например, в AROS когда портировали gcc, bash и прочее (до того gcc был только кросскомпилятором) много косяков в POSIXанутасти вычистили.

б) некий софт легко собирается везде, а значит — он труЪ.

А вообще Линукс пингвинеет, кабанеет, поттерингует и движется куда-то не туда. Поэтому простые, но функциональные «огрызки» вроде Хайки или Genode — это наш запасной аэродром. Ну и микроведро поковырять интересно, да.

Где это не так?

не требуя при этом кодирования вручную. Ядро автоматически распределяет приложения по разным ниткам, нитки - по процессорным ядрам. В самом приложении ничего для этого делать не надо.

Это достоинство ОС или библиотеки Qt?

Я вообще тут не говорю про Qt, кроме того, что оно было довольно легко портировано на native Be API.

Это достоинство ОС, то есть самого native Be API, реализованного органично уже начиная с ядра.

Интересно о какой очереди «central message queue» речь - это что-то типа IPC, требующее переключение контекста или что-то вне кернела?

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

Скорее всего, это BMessage http://www.haiku-os.org/legacy-docs/bebook/BMessage.html http://www.haiku-os.org/legacy-docs/bebook/TheApplicationKit_Messaging.html

А вообще что вы привязались с этой многопользовательностью. Ну есть вот здесь https://github.com/haiku/haiku/blob/master/src/system/kernel/team.cpp какие-то real_uid/real_gid/effective_uid/effective_gid ..., другое дело что в зачаточном состоянии и не используется в остальных подсистемах.

А в ведре вон есть KMessage https://github.com/haiku/haiku/tree/master/src/system/kernel/messaging

Кстати, вот ещё фича BeOS/Haiku, родом из Amiga/AREXX , достаточно уникальная: скриптование GUI приложений, прозрачным способом.

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

В BeAPI она «из коробки», таким образом, любое GUI приложение по умолчанию становится скриптуемым унифицированным, одинаковым способом:

http://www.birdhouse.org/beos/byte/08-scripting/

Аналогично тому, как в Amiga/AREX реализованы порты приложения.

PS. Да, я знаю что в Qt есть нечто подобное (например, средства для автоматизации GUI тестирования работают через рефлексию QObject, а питоньи средства автоматизации тестирования этим нагло пользуются). Вопрос только в «высокоуровневости» такого API скриптования, в идеале — нечто вроде Automator.

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

Это как? Вот есть у тебя хелловорлд, скажем длинный. Как ядро будет автоматически распределять его по разным ниткам?

нитки - по процессорным ядрам. В самом приложении ничего для этого делать не надо.

А где это не так?

Я вообще тут не говорю про Qt
то достоинство ОС, то есть самого native Be API, реализованного органично уже начиная с ядра.

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

это что-то в ядре, не требующее полноценного контекста (процессов или teams), а на простых нитках

Что мешает в других системах наряду с другими средствами синхронизации использовать очереди сообщений в юзерспейсе, реализаций которых только ленивый ещё не написал? Так ли упрощается написание программы со всеми этими циклами выборки сообщений в каждом потоке?

Сабж можно запилить, скажем, в качестве управляющей системы?

управляющей чем?

На что вообще гайка годится, кроме десктопа?

ну, например её встраивали в диджейскую штуковину: http://www.tunetrackersystems.com/ttbasic.html http://www.informationweek.com/byte/documents/s=617/byt20010521s0001/

А вообще что вы привязались с этой многопользовательностью. Ну есть вот здесь https://github.com/haiku/haiku/blob/master/src/system/kernel/team.cpp какие-то real_uid/real_gid/effective_uid/effective_gid ..., другое дело что в зачаточном состоянии и не используется в остальных подсистемах.

Ну, например, есть мнение, что система может стать менее отзывчивой при реализации проверки прав доступа процессами к ресурсам.

А управление приоритетами процессов там тоже в зачаточном состоянии?

А управление приоритетами процессов там тоже в зачаточном состоянии?

ну насколько я понимаю, в NewOS и в Haiku нет процессов в классическом понимании. Есть нитки, они объединяются в команды (teams), группа команд это примерный аналог процесса. Планировщик планирует на уровне команд и отдельных ниток. У ниток есть приоритет, у команд соответственно тоже.

GUI представлен AppServer-ом, который реализован несколькими нитками, при порождении «процесса» ядро создаёт «команду» из нескольких ниток. Как бы не каждое отдельное окно представлено своей отдельной ниткой на стороне «процесса» и на стороне AppServer-а.

niceness в bash есть и как-то работает : http://cgit.haiku-os.org/haiku/plain/src/bin/coreutils/src/nice.c

А управление приоритетами процессов там тоже в зачаточном состоянии?

ну насколько я понимаю, в NewOS и в Haiku нет процессов в классическом понимании. Есть нитки, они объединяются в команды (teams), группа команд это примерный аналог процесса. Планировщик планирует на уровне команд и отдельных ниток. У ниток есть приоритет, у команд соответственно тоже.

GUI представлен AppServer-ом, который реализован несколькими нитками, при порождении «процесса» ядро создаёт «команду» из нескольких ниток. Как бы не каждое отдельное окно представлено своей отдельной ниткой на стороне «процесса» и на стороне AppServer-а.

niceness в bash есть и как-то работает : http://cgit.haiku-os.org/haiku/plain/src/bin/coreutils/src/nice.c

не требуя при этом кодирования вручную. Ядро автоматически распределяет приложения по разным ниткам, нитки - по процессорным ядрам. В самом приложении ничего для этого делать не надо.

Ещё раз - где это не так?

я так понимаю, планировщик в хайке это доработанный из NewOS

Про планировщик, подробнее http://otoko.narod.ru/files/haiku/haiku_scheduler_part1.html http://otoko.narod.ru/files/haiku/haiku_scheduler_part2.html

Ну то есть, я не знаю, грубо говоря, сколько ниток ядро породит при запуске «процесса»-команды : простого GUI хелловорда. Будет ли AppServer реализован одним процессом-командой, или несколькими, раскидан по несколькими cores. Будет ли это одна нитка на хелловорд или несколько на окно, на процесс, на AppServer.

Поинт в том, что и не должен знать это, как и то, как именно они будут планироваться планировщиком. И вместо юзерлевел «зелёных ниток» в библиотеке (поинт в том, что) можно положиться на ядерные нитки, которые ядро может сделать оптимальнее, не требуя переделок юзерлендского кода значительным образом.

Вот что «ядро может само сделать оптимальнее» — это тезис и поинт NewOS, и затем Haiku.

Насколько я всё это понимаю.

В пределе, мы можем всю обработку BMessage-ей раскидать по отдельным «зелёным ниткам». Один обработчик - одна нитка.

А поскольку ядро/AppKit/прочие_Kit общаются между собой через KMessage/BMessage, получаем «всеобъемлюющую» многопоточность «на халяву».

Если конечно, в этой очереди не возникнет какой-то Giant lock. Да если и возникнет в одной, что мешает сделать пул из нескольких таких очередей, раскиданных по отдельным ниткам.

Ну, например, есть мнение, что система может стать менее отзывчивой при реализации проверки прав доступа процессами к ресурсам.

Соответственно, ресурсы типа процессов/ниток или других ресурсов процесса/нитки/сообщения/... становятся более «мелкозернистыми» (fine grained), улучшается параллелизьм в целом и контроль в целом становится принципиально возможен на уровне этих мелких зёрнышек, если ядро допускает более мелкие абстракции, чем процессы. (это тезис).

Что мешает в других системах наряду с другими средствами синхронизации использовать очереди сообщений в юзерспейсе, реализаций которых только ленивый ещё не написал? Так ли упрощается написание программы со всеми этими циклами выборки сообщений в каждом потоке?

Вообще да, было бы интересно:

1. Допортировать Google Go на Haiku.

2. Сделать обвязку goroutines -> BMessages (ну какие-то Broutines :-)

3. Переписать AppServer на эти Broutines

4. Сравнить реализации userland goroutines vs. stock Haiku многопоточность vs. эти 'Broutines'

В идеале тогда нативные программы под эти Broutines под Go сильно бы упростились. Делаешь какое-то boo вместо go, и процедура-обработчик сообщения уходит в отдельную нитку.

И сравнить, чья реализация лучше, системная, на уровне рантайма Go, на уровне чего-то более мелкозернистого.

Понятно. Интересно.

А ты думал! Это я ещё закусывал!!!

Соответственно, ресурсы типа процессов/ниток или других ресурсов процесса/нитки/сообщения/... становятся более «мелкозернистыми» (fine grained), улучшается параллелизьм в целом и контроль в целом становится принципиально возможен на уровне этих мелких зёрнышек, если ядро допускает более мелкие абстракции, чем процессы. (это тезис).

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

ну насколько я понимаю, в NewOS и в Haiku нет процессов в классическом понимании.

Но тогда получается, что процессы сидят в одном адресном пространстве и по ошибке (я даже о злом умысле не говорю) могут гадить друг другу в память!?

Поинт в том, что и не должен знать это, как и то, как именно они будут планироваться планировщиком. И вместо юзерлевел «зелёных ниток» в библиотеке (поинт в том, что) можно положиться на ядерные нитки, которые ядро может сделать оптимальнее, не требуя переделок юзерлендского кода значительным образом.

Вот что «ядро может само сделать оптимальнее» — это тезис и поинт NewOS, и затем Haiku.

Я не понимаю. Мне кажется что всё это вместе не может работать без проблем...

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

Рассмотрим классический дидлок, который происходит при «встречной» блокировке ресурсов. Пример с потолка - кто-то переводит деньги со счёта А на счёт Б. Одновременно владелец счёта Б также переводит деньги со счёта Б на счёт А.

При отсутствии других транзакций, поток, обслуживающий владельца счёта А получил бы сумму его счёта, уменьшил бы её на размер переводимой суммы, потом бы получил сумму счёта Б и увеличил её на соответствующую сумму. И потом бы сохранил все изменения (коммит в БД или запись файла - не принципиально, главное чтобы баланс не изменился). В случае со встречной же транзакцией всё резко меняется - нельзя допустить чтобы другой процесс переписал счёт А между тем моментом, когда сумма была извлечена и моментом, когда транзакция по переводу бабла со счёта А на счёт Б завершена - какие-то деньги потеряются. При одновременном исполнении двух встречных транзакций получается конфликт двух потоков: первый заблокировал счёт А чтобы снять денег и перевести их на счёт Б, но не может этого сделать потому, что счёт Б заблокирован вторым потоком, который снял денег со счёта Б и пытается перевести их на счёт А, который в свою очередь уже заблокирован первым потоком.

Это классический дидлок, как он решается на уровне ОС? Да никак! ОС понятия не имеет о логике приложения, а схемы дидлоков встречаются куда как более сложные. Так что ядро не может ничего «сделать оптимальнее». И это глобальное queue нифига не решает такие проблемы.

Более того, там, где может транзакция и проскочила бы, может вмешаться этот шедулер и переупорядочить вызовы так, что дидлок возникнет там, где его вообще не ждали - ведь нормально процессы синхронизируются между собой, а тут такой механизм не предусмотрен: «шлите письма в queue».

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

Инфа тут https://www.haiku-os.org/documents/dev/understanding_the_design_and_requireme...

Haiku упрощает процесс написания многопоточного кода путём сокрытия большей части взаимодействия между потоками, так что разработчикам не нужно думать об этом. Во многом это возможно благодаря обширному использованию механизма сообщений. Скажем, Поток А и Поток Б в одном приложении оба хотят получить кусок данных от Потока В. Вместо того, чтобы прямо обратиться к этим данным, Потоки А и Б посылают по сообщению, которые помещаются в центральную очередь сообщений и обрабатываются в определённом порядке. Без этого механизма два потока попытались бы доступиться к Потоку В одновременно и зашли бы в тупик (deadlock), в результате чего они ждали бы друг друга вечно. В Haiku сообщения могут быть посланы как внутри приложения, так и другим приложениям. Таким образом, механизм сообщений Haiku берёт на себя всю сложность управления потоками, освобождая от этого разработчика.

Об авторе. Райн Ливенгуд (Ryan Leavengood) — компьютерный консультант в Boynton Beach, Fla., занимающаяся разработкой сайтов на Ruby on Rails. Впервые он был вовлечен в проект с открытым кодом для разработки Haiku в 2003 году,

Уймись уже, ты просто не понимаешь какую хрень ты несёшь.

Увеличится количество переключений контекста -

он легковесный, это не проблема

у нити же например своя локальная память д/быть,

ну и что? контекст нити полюбому меньше контекста процесса. Вот в L4 микроядре с Map/Grant/Revoke вообще не надо на эту тему голову морочить — можно определить несколько диспетчеров памяти, для разных ситуаций. В NewOS map/grant/revoke/экзоядер нет, но подход применить то можно.

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

нет, есть. Полноценная виртуальная память, разделяемые библиотеки (см. поддержку динамического линкера в haiku_loader — своя реализация загрузчика ELFов). Управление памятью там с зональным аллокатором, как в исходниках Dooma — чем-то похоже.

Собсно тот же BMessage — это разделяемая память (если передавать не копии, а ссылки по чему-то типа map/grant/revoke). А ещё это метаобъектный протокол к системному API такой.

будут постоянно сбрасываться кеши процессора,

без анализа производительности VM тут разговор беспредметен. Происходит ли такое вообще в реальном сценарии использования, или это перестраховка.

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

да ладно. Композитор, индексирование в BFS, копирование, и т.п.

А под специальные задачи есть специальные процессоры.

ну в BeBox тоже были специальные процессоры: два CPU, два DSP. И ими унифицированно управляли.

Но тогда получается, что процессы сидят в одном адресном пространстве и по ошибке (я даже о злом умысле не говорю) могут гадить друг другу в память!?

нет, не могут. Не сидят они в одном адресном пространстве, есть виртуальная память (на уровне «команд», на уровне ниток — нет). Просто объединяются они более легковесным способом.

ОС понятия не имеет о логике приложения, а схемы дидлоков встречаются куда как более сложные

но ОС имеет понятие о логике своего АПИ, и это АПИ может поспособствовать чтобы на уровне системы дедлоков процессов системы не было (на уровне приложений — пускай, ССЗБ)

Так что ядро не может ничего «сделать оптимальнее».

ядро может предложить лучшую дефолтную схему, в которой каждое ССЗБ приложение может при усилии напортачить. Поинт в том, что надо делать усилие.

И это глобальное queue нифига не решает такие проблемы

не, оно решает другие проблемы.

Более того, там, где может транзакция и проскочила бы, может вмешаться этот шедулер и переупорядочить вызовы так, что дидлок возникнет там, где его вообще не ждали - ведь нормально процессы синхронизируются между собой, а тут такой механизм не предусмотрен: «шлите письма в queue».

ну в критике NewOS шедулера так пишут, что если один «процесс» сильно реалтаймовый, и редко отдаёт остальным, то потенциально может возникнуть starvation. ХЗ, насколько оно справедливо для Хайки.

Можно посмотреть на проблемы той же BFS. Журналируемая с расш. атрибутами, индексацией по атрибутам, поиском — отдельным процессом. По любому получается, нужна какая-то транзакционность, вопрос насколько крупными кусками она должна быть.

ведь нормально процессы синхронизируются между собой, а тут такой механизм не предусмотрен: «шлите письма в queue».

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

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

поинт в том, что как это реализовано — дело десятое. Можно будет эту реализацию и переделать. С анализом производительности типичных сценариев, и т.п. По типу того, как в L4 сделан пейджер : пользовательские реализации подкачки страниц и виртуальной памяти, для разных процессов могут быть разные, потенциально если сделать как JIT-профилировщик, система сама может догадаться заменить стратегию на другую стратегию и другую реализацию .

Ну тут в Хайке какой-то системный монитор транзакций/шина сообщений/объектный брокер появится. На разных кусках — свои разные реализации, но в рамках общей идеологии.

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

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

Здесь в качестве такой метамодели выступает системное АПИ. (тезис).

то есть обработка BMessage-ей шедулируется по разным транзакциям/ по разным очередям/по разным ниткам и по разным процессам-командам, по разным cores.

Каким-то унифицированным единым системным способом.

UP

Не смог установить, вроде как у меня жёсткий диск на ноуте не видит.

Какая ревизия и образ? Жесткий диск sata - в bios какой режим выставлен? Какова стрктура разделов на жестком диске? Бутманагер использовали? С лайвсиди HaikuOS этот комп загружался? и тд ..

Что то на десятой странице анонимусы стали более осведомленные о beos/haiku. Такое ощущение что beos позвал себе подмогу :)
А теперь о серьезном:

Ядро — на основе микроядра NewOS

fix

Ядро — на основе ядра микро ос NewOS

Я лично общался с разработчиком NewOS и он утверждает что это ядро модульное т.е. как в линуксе. К тому же написано не на С++ а на С. Но добавил что сейчас ядро гайки это уже что то совершенно другое имеющее только примитивное сходство с NewOS.

Кстати, сама NewOS загнулась?

UP

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

Она и не оживала. Это было прикрытие для того чтобы где-то выложить то что удалось вынести из беос в день его закрытия. Сам автор забросил его поддержку еще в 2005 году.

Есть мнение..

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

Модульное ядро — современная, усовершенствованная модификация архитектуры монолитных ядер операционных систем компьютеров. В отличие от «классических» монолитных ядер, считающихся ныне устаревшими, модульные ядра, как правило, не требуют полной перекомпиляции ядра при изменении состава аппаратного обеспечения компьютера. Вместо этого модульные ядра предоставляют тот или иной механизм подгрузки модулей ядра, поддерживающих то или иное аппаратное обеспечение (например, драйверов). При этом подгрузка модулей может быть как динамической (выполняемой «на лету», без перезагрузки ОС, в работающей системе), так и статической (выполняемой при перезагрузке ОС после переконфигурирования системы на загрузку тех или иных модулей). Все модули ядра работают в адресном пространстве ядра и могут пользоваться всеми функциями, предоставляемыми ядром. Поэтому модульные ядра продолжают оставаться монолитными. Модульность ядра осуществляется на уровне бинарного образа, а не на архитектурном уровне ядра, так как динамически подгружаемые модули загружаются в адресное пространство ядра и в дальнейшем работают как интегральная часть ядра. Модульные монолитные ядра не следует путать с архитектурным уровнем модульности, присущим микроядрам и гибридным ядрам.

Haiku воплощает в себе основные идеи BeOS. Это модульная система, архитектурно решённая как гибридное ядро: микроядерная архитектура, способная динамически подгружать необходимые модули.

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

Пусть приходят когда напишут нормальный браузер

Arora и прочие qt+webkit работают.

и производители драйверов напишут нормальные драйвера

Критерий нормальности? Даже под Linux только и слышно маты в сторону кривых блобов (хотя и под винду тоже :3 )

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

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

По твоему опеределению и Линукс мертв, ведь ни нормальных драйверов, ни браузеров в нем нет.

ТС зачем ты пишешь под анонимом? Ахаха, прекрати.

Могли бы Linux наконец допилить.

Не царское это дело, в мейнстриме копаться.

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