Линукс стал помойкой куда комитят все, от АНБ и Микрософта, до школьника

Если в проект не может коммитить Микрософт/whatever - это уже не свободная разработка, ведь так? Это фундаменталистская секта, о чем в свое время прекрасно сказал Торвальдс. Вы выбирайте, либо «помойка» (хотя с чего бы, все патчи проходят проверку), либо один никому ненужный хакер со своим красивым ядром, которое и забесплатно никому в серьезном деле не вперлось.

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

Для свободы и безопасности необходимы консолидированные усилия сотен квалифицированных профессионалов.

Посмотрю на стрекозу поближе, АНБ в двухтысячных точно советов им не давало!

Шапочку из фольги не забудь.

А раньше как было? Неужели статическое связывание? А чем объясняется такой прогресс?

А у тебя какие бинари? Ынтерпрайз бубунта-сюзя-федорка-... ET_EXEC — статически слинкованы при компиляции! Как и у 99% Ынтерпрайз школоты ЛОРа.

Вот Ъ энтерпрайз компания - Микрософт, ДА ПАЦАНЫ, КРОМЕ ШУТОК, на более 10 тысячах серверов по всему миру держит только Ъ бинари ET_DYN которые способны динамически линковатся при запуску и запускает их на Ъ ядре Linux+PAX которое при запуске бинарей динамически их линкует выбирая рандомно адреса памяти. Ибо Ъ энтерпрайз Микрософт понимает в безопасности чуть больше чем 5-звёздные пользователи ЛОРа. Вот так вот дети, пора бросать сосать мамкину сиську и переходить к борщу...

Для свободы и безопасности необходимы консолидированные усилия сотен квалифицированных профессионалов.

На безопасность в стрекозе внимания не обращали, только сей час, благодаря ПРОСТОТЕ и ПРАВИЛЬНОСТИ выбранных алгоритмов, кажется что ядро получается очень безопасным! Но это редкий случай который требует доказательств.

Если в проект не может коммитить Микрософт/whatever - это уже не свободная разработка, ведь так? Это фундаменталистская секта, о чем в свое время прекрасно сказал Торвальдс. Вы выбирайте, либо «помойка» (хотя с чего бы, все патчи проходят проверку), либо один никому ненужный хакер со своим красивым ядром, которое и забесплатно никому в серьезном деле не вперлось.

Вы заблуждаетесь. Цель не свобода софта, а свобода личности. Вот почему Безопасность софта есть выше чем право АНБ внедрять трояны. И в данном случае для обеспечения информационной свободы личности, свободой АНБ можно пренебречь.

На безопасность в стрекозе внимания не обращали, только сей час, благодаря ПРОСТОТЕ и ПРАВИЛЬНОСТИ выбранных алгоритмов, кажется что ядро получается очень безопасным!

Оно получается безопасным благодаря одной вещи: неуловимый Джо. Потому что в реальном мире никого не интересует простота и правильность, если с ними нельзя достигнуть цели. Как только вещь становится полезной (т.е. входит в мир реальных проблем) она требует постоянной адской работы специалистов. А вот эти все «ну там же гениальный хакер, оно простое и правильное» - это, извини, детский сад и идеализм.

Цель не свобода софта, а свобода личности

Да? А можно цитату из GPL или BSD, где говорится о свободе личности?

Вот почему Безопасность софта есть выше чем право АНБ внедрять трояны

А кто-то с этим спорит?

Ой лол. И после этого эти «эксперты» говорят о пользе ляликса. Польза от него такая же, как и от венды.

Еще один кусок мусора :) Эксперт по детским аргументам.

Ой лол. И после этого эти «эксперты» говорят о пользе ляликса. Польза от него такая же, как и от венды.

«Ой лол» это такой школоло аргумент :)?

Оно получается безопасным благодаря одной вещи: неуловимый Джо. Потому что в реальном мире никого не интересует простота и правильность, если с ними нельзя достигнуть цели. Как только вещь становится полезной (т.е. входит в мир реальных проблем) она требует постоянной адской работы специалистов. А вот эти все «ну там же гениальный хакер, оно простое и правильное» - это, извини, детский сад и идеализм.

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

«Простота и совершенство» - основной девиз Юникс! Простота способствует безопасности.

DragonflyBSD - своих целей достигла:

1. очень проста и эффективна реализация работы на многопроцессорных машинах с полной асинхронностю всего!

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

3. очень простое построение кластера единого системного образа, когда много компов видны для приложения как один с общим количеством ядер и оперативы.

4. код ядра поддерживается настолько простым, чтобы его всегда смог разрабатывать ОДИН человек и ограничен 0,5млн строк. Хоть работает над ним команда с более 200 хакеров.

Смотри в будущие, код ядра Линукса растёт по экспоненте, уже сегодня он не может поддерживаться и развиваться силами только сообщества и требует вложения больших ресурсов корпораций. Скоро он лопнет не достигнув своей цели - перегнать винду по популярности.

Смотри в будущие, код ядра Линукса растёт по экспоненте, уже сегодня он не может поддерживаться и развиваться силами только сообщества и требует вложения больших ресурсов корпораций. Скоро он лопнет не достигнув своей цели - перегнать винду по популярности.

скоро ты, толстенькое зелёненькое школоло, лопнешь, не достигнув своей цели - убедить линуксоидов, что dragonflyBSD никому не нужна из-за злого заговора против этой гениальной ОС, а не потому, что она просто жалкое поделие теоретиков, витающих на радужных облачках в мире единорожиков

Готов отвечать только на технические аргументы.

Да сообщество БСД очень недовольно сообществом стрекозы, такая у них там длинная и сложная история...

Да и Тордвальс и другие разрабы GNU/Linux очень скептически относились и к самой модели LWKT и к общей простоте кода всей ОС в целом, а не отдельной её части (не факт что модель давшая простоту реализаций в одних местах не усложнит реализацию в других).

Но есть судья строгий и безжалостный, который покажет кто вначале принял самые правильные решения и пошёл по правильному пути - ВРЕМЯ.

Готов отвечать только на технические аргументы

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

Но есть судья строгий и безжалостный, который покажет кто вначале принял самые правильные решения и пошёл по правильному пути - ВРЕМЯ

ога, Свидетели Бздуновы всё ждут своё светлое будущее, как совки когда-то коммунизма ждали

вот, дождались, как видно

Ты сюда покудахтать пришёл, болезный?

а что, в тредах про БСД принято кудахтать? Ну ок, буду знать.

Надо подать на БЗДунов в суд за нарушение GPL!1

Этих не засудишь: http://rutracker.org/forum/viewtopic.php?t=4511449

Помогие парню

Вдруг он ЛОРовец?!

да

Именно FreeBSD ближе всего к оригиналу и истории Unix.

Поддерживаю!

И при этом развивалась академически, а не так...как тов. Торвальдс.

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

Понятно. Очередная недо-Reiser4.

Вроде бы хаммер повкуснее будет:

http://manpages.ylsoftware.com/legacy/hammer_5.html

1.После неправильного выключения системы файловая система HAMMER вернётся назад к полностью согласованному состоянию при монтировании файловой системы, обычно менее чем за несколько секунд.
2.Одной из главных задач HAMMER является обеспечение целостности данных, проверки CRC выполняются для всех важных структур и данных. Мгновенные снимки HAMMER позволяют делать проверку целостности данных проще: поля atime и mtime фиксируются в значение ctime для файлов доступных через мгновенный снимок. Поле st_dev основывается на разделяемом uuid PFS, а не на реальном устройстве. Это означает, что архивирование содержимого мгновенного снимка например с помощью tar(1) и перенаправление его через нечто вроде md5(1) даст целостный результат. Целостность также поддерживается на зеркалируемых объектах.

и ограничен 0,5млн строк

по чему 0,5 автор алкаш что ли?

Нет, с авторами всё в порядке, кто-то считает что человек максимум может поддерживать код в 1млн. вот эту цифру решили пополам поделить, ну чтобы с запасом...

Да, есть такое.

Но в DragonflyBSD был выбран свой, принципиально другой путь развития ядер Юникс. Другие БСД, Линукс, ... по этому пути не пошли.

В DragonflyBSD была принципиально изменена сама математическая модель ядра и она оказалась ПРАВИЛЬНОЙ, жаль другие понять пока не смогли.

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

1. Модель ядра DragonflyBSD и самой ОС есть абсолютно правильна для достижения изначально поставленных целей.

2. Кажись под ядро DragonflyBSD надо много переписывать прикладного софта и это тяжело. А иначе теряется смысл в параллельной асинхронной работе ПО..

3. DragonflyBSD имеет полный эмулятор посикс который разрешает полностью компилить любые проги БСД или Линукс и запускать их.

4. Если прога написана под DragonflyBSD то она реально рвёт в производительности на многопроцессорных задачах все ОС!

5. Если прога работает через эмулятор то по сравнению с Линукс прирост не большой и только до ~32-64 ядер при большем количестве ядер эмулятор проигрывает Линуксу.

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

в Btrfs всё то же самое, только оно ещё и работает худо-бедно, лол

Я говорил здесь только о технических вещах

если ты считаешь свой туманный трёп техническими вещами, то ты блондинка с ГСМ

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

Говорил о технических вещах

где? покажи

Со стрекозой знаком на растоянии, много сказать не могу. Но 2 вещи, которые мне хочется видеть в моей ОС хочу донести:

1 Вышла DragonFly BSD 3.8 (комментарий)

2 Вышла DragonFly BSD 3.8 (комментарий)

По поводу 1 - мне не понятно почему её игнорируют все Ынтерпрайз дистры.

По поводу 2 - в Линуксе и других БСД нам сего уже не видать, слишком испорченное ядро.

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

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

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

На ведать с тобой им не по пути.

А я вот хочу спросить - про какую такую математическую(!) модель ты говоришь?

Модели параллельных вычислений мне известны, а вот что такое матмодель ядра интересно...

В основном я имел ввиду LWKT

Также можно глянуть DragonFly's Major Features List

Более подробно могу добавить что мат модельядра там действительно принципиально другая и кажись POSIX API не даёт, оно делается дополнительным эмулятором.

Главным камнем преткновения между Cтрекозой и другими Юникс стал именно алгоритм работы в многопроцессорной системе ибо от него сильно зависят:

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

* асинхронность

* параллелизм - у стрекозы он свой (Ъ асинхронный, без блокировок) и с параллельными методами программирования в Линукс мало общего. В этом основной минус и сложность, надо переписать прикладное ПО для параллельной асинхронной работы.

* простота реализации кластера единого системного образа.

* простота и производительность виртуализации

* общая простота ядра и минимализм кода.

параллелизм - у стрекозы он свой (Ъ асинхронный, без блокировок) и с параллельными методами программирования в Линукс мало общего. В этом основной минус и сложность, надо переписать прикладное ПО для параллельной асинхронной работы.

Чото бред. С каких пор LWKT распространяется на прикладное ПО? Если не распространяется - зачем это ПО переписывать?

Они там всё сильно изменили. Я плохо в стрекозе ориентируюсь, могу ошибаться, но кажись POSIX там таки через эмулятор ;)

И прикладное ПО для найтивной работы в стрекозе, параллельной и асинхронной, таки надо переписывать! Может здесь чё есть: http://www.dragonflybsd.org/docs/developer/c_development_under_dragonfly_bsd/

Поэтому они медленно и пишут: почтовик, сервер времени..

кажись POSIX там таки через эмулятор ;)

Нерелевантно.

Может здесь чё есть: http://www.dragonflybsd.org/docs/developer/c_development_under_dragonfly_bsd/

Там нет ровно ничего.

блинамать!

А про матмодель где?! Где матмодель ты узрел в posix api и какую?

lwkt мало чем отличается от соляркиных lwp

Шедулер там оригинальный, да. Ещё допилят мультимастер в хамер2.

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

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

lwkt мало чем отличается от соляркиных lwp

LWKT отличается от всех приличных реализаций нитей %)

А про матмодель где?

Light Weight Kernel Threads (LWKT)

Гуглю СТРОГОЕ описание мат модели Стрекозы но найти не могу.

Вот для обывателей:

http://citkit.ru/articles/68/

http://itc.ua/articles/dragonflybsd_-_strekoza_s_rozhkami_17811/

Где матмодель ты узрел в posix api и какую?

API это отдельная тема, надо глянуть посикс там найтивный или они сломали всё и посикс эмулируется.

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

http://www.dragonflybsd.org/docs/developer/Locking_and_Synchronization/

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

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

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

Может эти ссылки помогут больше:

https://ru.wikipedia.org/wiki/DragonFly_BSD

http://leaf.dragonflybsd.org/~justin/devcentral/article.html

Таки разница с Юникс очень большая, сломали всё, и в целях совместимости все системные вызовы эмулируются.

Кто знает ссылку на строгое описание мат модели ядра, по которому разрабы Стрекозу пишут, дайте пожалуйста ссылку!

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

гибридное ядро это слегка переделанное монолитное ядро, вот в чем небольшая трабла под номером 2. Или я ошибаюсь ?

Да, знаю знакомого которому эта ОС понравилась больше чем линукс, только прочитав про ее особенности.
Ставил ее еще когда не было dports, а было pkgsrc, вывод один, это переделанная слегка FreeBSD внешним видом и полностью внутри. Даже конфиги одни и теже были для подключения драйверов.

Поясни плиз чем, ну и +/- если не трудно :)

Удачи в гуглении 😁

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

Я не разраб этой ОС и даже не пользователь.. Хотя чё-то и знаю.

гибридное ядро это слегка переделанное монолитное ядро, вот в чем небольшая трабла под номером 2. Или я ошибаюсь ?

Мы о чьём ядре говорим о Стрекозе? Тогда там изменений много.

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

Да это полностью переделана внутри FreeBSD, а на внешние «обои» они времени не тратят.

Поясни плиз чем, ну и +/- если не трудно :)

Удачи в гуглении 😁

Это старое описание модели 10 летней давности, на сегодня изменений много, но анонимусу сойдёт:

" В основе DragonFly лежит модель легковесных нитей (threads) ядра (LWKT, Light Weight Kernel Threading). Для каждого процесса в системе имеется ассоциированная с ним нить, а большинство процессов ядра - это фактически всего лишь чистые нити. Например, демон pageout (вытеснения страницы из ОЗУ) - это чистая нить без контекста процесса.

У модели LWKT имеется ряд ключевых особенностей, независимых от архитектуры. Эти особенности были разработаны для устранения или сокращения конкуренции между процессорами.

1. Для каждого процессора в системе имеется свой собственный, автономный LWKT-планировщик (sheduler). Нити умышленно привязываются к своим процессорам и могут быть перемещены на другой процессор только при наступлении некоторых особых условий. Любая операция планирования LWKT на конкретном процессоре может выполняться только непосредственно на этом процессоре. Это значит, что LWKT-планировщик может производить планирование и переключение нитей без каких бы то ни было блокировок. Никаких блокировок на уровне многопроцессорной системы, ничего, кроме простого критического участка.

2. Нить никогда не будет вытеснена на другой процессор, пока она выполняется в ядре, и нить никогда не будет перемещаться между процессорами, когда она блокирована. Планировщик пользовательского уровня может переместить нить, выполняющуюся пользовательском режиме. Нить никогда не будет переключена через вытеснение непрерываемой нитью. Если прерываемая нить вытесняет текущую нить, то в момент, когда прерываемая нить завершает свое выполнение или блокируется, вытесненная нить возобновляет выполнение независимо от своего состояния с точки зрения планировщика. Например, нить может быть вытеснена после вызова lwkt_deschedule_self(), но это произойдет раньше, чем она реально отключится. И это правильно, потому что управление будет возращено ей непосредственно после того, как прерываемая нить поток завершит свое выполнение или блокируется.

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

4. Процессор, который пытается планировать нить, принадлежащую другому процессору, для выполнения операции будет посылать целевому процессору сообщения основанные на IPI. Эти сообщения асинхронны по умолчанию, и хотя IPI могут обладать некой латентностью, они не обязательно растрачивают вхолостую циклы по этой причине. Нити могут заблокировать подобные операции путем входа в критический участок, что фактически и делает LWKT-планировщик. Вход в критический участок и выход из него считаются экономными операциями и не требуют ни блокировки, ни выполнения команд блокирования шины.

5. Подсистема сообщений IPI работает со взаимными блокировками FIFO, путем прокручивания и обработки очереди входящих сообщений в ожидании разгрузки очереди исходящих сообщений. В этих условиях подсистема сообщений IPI специально не переключает нити, что позволяет программе воспринимать ее как неблокирующий API, хотя может происходить прокручивание.

В дополнение к этим ключевым особенностям, модель LWKT позволяет производить вытеснение по FAST-прерываниям И вытеснение по нитиевым прерываниям. FAST- прерывания могут вытеснять текущую нить, когда она не находится в критическом участке. Нитиевые прерывания также могут вытеснять текущий поток. Система LWKT будет переключаться в режим нитиевых прерываний, а потом - обратно в исходное состояние, когда нитиевое прерывание блокируется либо завершает работу. Действие функций IPI очень похоже на действие FAST-прерываний. В DragonFly это в полной мере используется в SYSTIMERS API для распределения прерываний hardclock() и statclock() между всеми процессорами. Подсистема IPI для работы с сообщениями

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

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

Подсистема IPI интенсивно используется не менее чем в шести основных подсистем LWKT, включая внутрипроцессорное планирование нитей и подсистемы обмена сообщениями. Поскольку система IPI является прирожденной для DragonFly, в ней не требуется и не используется механизм Big Giant Lock (как во FreeBSD). Поэтому все функции, основанные на IPI, должны быть МР-безопасными (и они таковыми являются). Основанная на IPI подсистема синхронизации процессоров

В модели LWKT используется обощенный, машиннонезависимый API синхронизации процессоров. Этот API может использоваться для перевода целевых процессоров в известное состояние, пока ведется работа с чувствительной структурой данных. Этот интерфейс, прежде всего, применяется при обновлении таблиц страниц устройства управления памятью (MMU). Например, небезопасно проверять и очищать бит модификации в элементе таблицы страниц, а потом удалять этот элемент, даже сохранив соответствующую блокировку. Это потому, что пользовательский процесс, выполняющийся на другом процессоре, может обращаться к этой таблице и изменять ее, из-за чего возникнет соревнование между образом буфера быстрого преобразования адреса (TLB) на целевом процессоре и вашими попытками очистить элемент таблицы страниц. Правильное решение состоит в том, чтобы сначала перевести в известное состояние все процессоры, которые могут произвести выталкивание из TLB в элемент таблицы страниц (т.е. все процессоры в маске pm_active pmap'а), провести модификацию, после чего освободить процессоры с запросом на объявление недействительными их TLB.

API, реализованное в DragonFly, свободно от взаимных блокировок. Действия по синхронизации нескольких процессоров могут выполняться параллельно, и это распространяется на все нити, которые обрабатывают событие ссинхронизации, на время этой обработки. Даже при наличии этой гибкости, поскольку интерфейс синхронизации процессоров работает в контролируемой среде, функции обратного вызова (callback) работают подобно функциям используемым в подсистеме сообщений IPI. Сериализующие маркеры

Сериализующий маркер (serializing token) может удерживаться одновременно несколькими нитями. Для нити, удерживающей сериализующий маркер, гарантируется, что одновременно с ней не будет выполняться ни одна нить с тем же маркером.

Нить может удерживать любое число сериализующих маркеров.

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

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

Сериализующие маркеры может также использоваться для защиты нитей от вытеснения прерываниями, стремящимися получить тот же маркер. Этот эффект несколько отличается от механизма Big Giant Lock (также известной под названием МР-блокировки), который не обеспечивает блокировку для защиты от вытеснения прерываниями на том же самом процессоре. Важно заметить, что атомарность маркера сохраняется в условиях вытеснения, даже если вытеснение предполагает временное переключение на другую нить. Для того, чтобы сохранить атомарность маркера, нет необходимости входить на уровень spl() либо в критический участок.

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

зачем вся эта вода здесь? продемонстрируй реальные результаты, как всё это рвёт в клочки по производительности и отзывчивости обычное ядро Linux, а?

я нашёл бенчмарки сам

сабж версии 3.2.1 сливает убунте 12.10

практически вровень с Scientific Linux 6.2

сабж версии 3.4.1 - то вровень, то жёсткий слив

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

ещё тесты версии 3.4 - сабж где-то в районе днища, в лучшем случае - середнячок

В 3.8 в производительности гайки подкрутили.. И тестовый софт не под LWKT писался, а стандартный посикс - работает в эмуляторе.

Главное простота кода, почти микроядро и простота реализации SMP, SSI, виртуализации.