NT vs POSIX

()

Linux лучше Windows!
- Чем лучше?
- Чем Windows!
Анекдот, однако.

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

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

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

Когда в статье говорится об NT, то имеется ввиду именно NT, а отнюдь не win32 и MFC. NTOS – это одна из первых попыток строить ядро на принципах ООП. В ядре NT была сделана попытка представить все ресурсы, как объекты; в этом была его новизна. Кроме того объектная идеология ядра NT оказалась изолированной от прикладных технологий (COM/DCOM/COM+/.NET).

ОО-подход ядра NT далек от совершенства, и во многом реализован топорно, но при этом ядро не представляется этаким незыблемым монолитом. Скажем, завтра разработчики захотят встроить в ядро NT какую-нибудь новую конечную подсистему, и они легко это сделают. К примеру, разработчики клона NT – ReactOS за 2 недели сделали прослойку поддержки BeOS.

Цель статьи не состоит в сравнении сигнальных концепций NT и Linux (как яркого и быстрорастущего представителя *nix): детальный анализ был бы крайне полезен – многие бы наконец узнали сигналы NT (да Linux), однако сказать о них необходимо. Основная цель статьи – не объяснение механизмов планирования и доказательство почему приоритетное планирование по событиям и таймеру + алгоритм адаптивного планирования лучше, чем круговое планирование по таймеру на фактически ОДНОМ приоритете (планировщик *nix/Linux).

Последняя мысль нуждается в некотором разъяснении. В Linux 100 приоритетов, приоритеты 1-99 – реального времени. Потоки/процессы не реального времени (а их подавляющее большинство) выполняются на единственном приоритете 0, и планируются по принципу круговой диспетчеризации (RoundRobbin – привет из 80-х годов). Для того, чтобы хоть как-нибудь урегулировать выполнение потоков/процессов, в планировщике используется динамический квант процессорного времени, который выделяется каждому потоку в зависимости от его «коэффициента интерактивности» (nice). Чем больше процент использования процессора данным потоком, тем меньше его «коэффициент интерактивности». Коэффициент nice изменяется от -20 до +20.

Потоки реального времени планируются по приоритетной схеме в 2 режимах: FIFO (процессорный квант для данного потока выключен, и он планируется только по событиям), и RR (RoundRobbin, процессорный квант для данного потока разрешен, и он планируется как по событиям, так и по таймеру). Но поскольку практически все работатет вне РВ, то – добро пожаловать в середину 80-х.

Заикающийся Helix в SuSE столь болен в частности именно поэтому. Его и режим РВ не спасает, впрочем какое РВ в SuSE? Совсем недавно конечно появился Suse Linux Enterprise Real-Time, однако гарантированное время реакции в 27 мс – многовато для ОСРВ, особенно учитывая что даже в настольной XP оно порядка 40 мс.

Для сравнения, в NT все потоки планируются по приоритетам, причем разделены на 3 группы:

  • потоки реального времени, приоритеты 16-31.
  • средние динамические приоритеты 4-15.
  • низкие фиксированные приоритеты 0-3.

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

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

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

И не надо тут кивать в сторону различных RT-дистрибутивов, вроде RTLinux или LynxOS (LynxOS-178, LynxSecure), хоть они и позиционируются как ОСРВ, их гарантированное время реакции уступает традиционным лидерам этого сегмента в разы, то есть реализация РВ хоть и возможна, но истоинность этого РВ крайне спорно.

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

Так в NTOS kernel легко можно реализовать POSIX и все разновидности Unix. Более того, NT частично совместим с POSIX, точнее некоторые реализации, основанные на NT совместимы со стандартом POSIX, некоторые нет, как например поддержка Windows 95-98 в ХР.

Под Linux же или *nix невозможно полноценно поддерживать win32, т.к. в них отсутствует механизм APC, широко используемый в win32, т.к. убогая сигнальная концепция *nix несовместима с win32, т.к. асинхронный ввод-вывод в *nix на самом деле фикция. Исходя из сказанного, win32 можно поддерживать, скажем в Linux, только реализовав ядро в ядре, используя Linux, как микроядро. Но и в этом случае APC, сигнальную концепцию NT и асинхронный ввод-вывод полноценно воспроизвести невозможно. К этому следует добавить, что Wine, работая под Linux, никогда не сможет полноценно поддерживать win32.

При это для NT создание подсистем и трансляция API – родной мезанизм. NT – это попытка создания базового инструментария, при помощи которого можно строить любую конечную подсистему: win32, posix, os/2 и все, что в голову придет. Причем инструментарий – иерархический. API микроядра предоставляет базовые классы объектов и механизмы, при помощи которых разрабатываются драйверы режима ядра и ближайшее окружение микроядра (в NT в это окружение входят менеджер объектов, менеджер мамяти, система ввода-вывода). Следующий уровень – это API т.н. kernel executive.

Этот API используется в драйверах и защищенных подсистемах. При его помощи создаются конечные подсистемы. На этом уровне создаются классы объектов, наследующие классы объектов микроядра, и новые классы обьектов. Менеджер объектов позволяет управлять объектами kernel executive.

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

Так например одна концепция представления всего и вся в виде файлов – идеологическая ограниченность.

Все *nix построены на концепции «все есть файл», которая сама по себе является ограниченной и не дает ОС развиваться. Сама же концепция файла примитизирована и сведена к единственному его представлению, как «потока данных», или «потока записей фиксированной длины размером 1 байт». И тот же Plan9, который довел концепцию «все есть файл» до предела, именно поэтому обречен.

Другим ограничением *nix и особенно Linux является монолитность ядра. То, что Торвальдс не осилил менеджер памяти независимый от микроядра (в этом не смог превзойти учителя, а потом доказывал и доказывает, что он правее), привело к невозможности добавить драйвер, или системный компонент, без перекомпиляции ядра. То есть наращивание свойств системы путем простого добавления драйверов или компонентов невозможно в принципе.

Поэтому разработчикам в частности приходится каждые 3-4 месяца выпускать новую версию ядра с поддержкой большего количества железа: добавлена поддержка одного, другого, третьего. Поставщики же дистрибутивов вынуждены поставлять ядра скомпилированные с поддержкой максимального количества оборудования, даже если оно и не используется. Зато уж если чего они забыли – то вот пожалуйте в сборочный цех.

При всем при этом ядро постоянно разбухает – количество поддерживаемого оборудования все еще недостаточно.

Одним из самых спорных положений о технической ущербности ядра Linux является объектность, точнее полное отсутствие таковой. Ядро Linux (и вообще *nix) в принципе не может поддерживать объектную идеологию, которая является ключевой для развития интерфейсов нового поколения, и создания единой распределенной операционной среды. Можно возразить, что дескать, можно, используя Linux-ядро, поверх него, как оболочку, создать объектную идеологию. Можно-то конечно можно, но нельзя! Эта оболочка будет существовать вне ядра, и поэтому будет не защищена! Кроме того X-сервер с ООП дружит также плохо, как и ядро Linux.

Вот и получается, что в NT можно найти много более мощных, чем в POSIX, идей и решений.

Помятуя совет: «критикуя – предлагай», переходим плавно ко второй части арлингтонского балета.

Если вы еще не согласились, что Linux – тупиковая ветвь, то перечитайте вышесказанное еще раз, а потом еще, и так до наступления полного просветления. Без этого читать дальше все равно бессмысленно.

Потому, что самое лучшее, что может сделать сообщество FOSS это выкинуть ядро Linux и заняться более полезными вещами. Иначе придет, кто-то, кто вполне возможно не разделяет ценности FOSS и порвет всех и M$ и Red Hat. Linux же будет вынужден ютиться в какой нибудь очень узкой нише.

Что же стоит взять за основу?

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

Есть экзотичный Plan9 и его потомок Inferno. Но по уже указанным причинам первый в принципе ничем не лучше Linux, а второй может использоваться пожалуй только embedded-системах (отсутствие VFS как «класса» знаете ли никому еще на пользу не пошло).

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

Есть еще Minix. Проблемы те же.

Есть любительские ОСи. Как, например, Syllable, OBOS или SkyOS. Про них ничего к сожалению сказать не могу.

Остается еще ReactOS.

Итого в сухом остатке имеем два «джастфофан» направления – любительские ОСи и клон всеми любимого поделия от M$. Любопытно найдется ли спонсор, который вложит в развитие кого-нибудь из них эдак миллиардик-другой как IBM в Linux?

P.S. Свои мнения о статье вы можете присылать на troninster@gmail.com

Комментарии:

xxx 2006-11-06 16:49:30 (#)

LOL

Hmm 2006-11-08 15:14:03 (#)

Да, давненько такой бредятины не читал. Повеселил автор, повеселил...
Кто там из великих сказал, что идеальная конструкция, эта на та, в которую уже нечего добавить, а та, из которой уже нечего убрать. Это к вопросу API glibc.
А теперь посмотрим на API win, win32, win32s, winNT, win2000, winXP. В смысле на совместимость этих API. Как говориться, нет слов. Это не учитывая "косяки" в этих API. А также легкость и "прозрачность" этих API. Даже такую действительно бездарную библиотеку как MFC использовали только и только по одной причине - не
связываться с API OLE2/ActiveX.
Об ООП Windows. Когда автор отключит графическую подсистему, которая для сервера уж никак не нужна, попробую ему поверить. А еще отключить сервис SNMP для
домохозяечного варианта и посмотреть КАК работает родимая Windows. И с чего это автор вдруг решил, что попытка представления всех ресурсов как обьекты в Windows, это новизна? Это преднамеренная ложь или еще один анекдот на тему о том, что Бил Гейтс изобрел интернет? А что тогда делать с концепцией добавления/удаления/замены ядерных модулей "на лету", которая впервые была прекрасно реализована в Linux, а в Windows появилась в более-менее полноценном варианте только в XP? Да и еще была представлена как инновация. А почему драйвер, скажем, какого-нибудь принтера, может напрочь убить хваленую систему? Но вот драйвер CUPS в Linux ни при каких обстоятельствах этого сделать не в состоянии.
Не знаю, как там с "убогостью" планирования процессов/потоков в Linux, но, только все познается в сравнении. Вот к примеру, в XP, при просмотре фильма с HD, вставьте CD-диск в устройство, и посмотрите, что произойдет с вашим плейером, да и со всеми активными приложениями. Это можно назвать одним словом - ступор. В
Linux же для меня нормальная ситуация; одновременно компилировать серьезную по размеру программу, смотреть фильм, а по ходу дела еще и нарезать dvd-болванку. И
это на одном из самых медленных дистров, на SuSE. Версия 10.0 x86. В которой у меня Helix почему то не заикается. Может у автора проблемы с утройством /dev/hands? Не знаю. По крайней мере, никто на запрещает использовать ALSA, GStreamer итд. Вообщем то, что больше всего подходит конкретному конечному пользователю.
Опять же, из статьи совершенно не понятно, почему сигнальная концепция Linux "убогая". Если уж говорить о сигналах, то как раз в Windows сигналы кастрированы
до безобразия. Для этого просто достаточно почитать MSDN и заодно man-ы.
Далее. Все или почти все основные поставщики железа выпускают драйверы и для Linux. А некоторые только для Linux. И ядро каждые три месяца в основном патчится.
А что, например, протокол SCTP в Windows уже реализован или нет? Или дыры во втором сервис-паке уже убрали? Вспомним еще полнейшее фиаско Windows64. Это когда
произодители железа просто проигнорировали эту систему. А для Linux x64 вот они, эти драйверы, пожалуйста.
Совершенно непонятно, во-первых, почему автор считает, что обьектная идеология является ключевой в развитии интерфейсов нового поколения и, во-вторых, почему поверх Linux нельзя создать как оболочку обьектную технологию. А в третьих, почему эту оболочку надо защищать. Автора можно простить, ну думает человек, что вопросы решаются только вождением мышки по экрану. Только вот шаг влево или шаг вправо и... надо лезть ручками в реестр, ту еще супер-пупер обьектную технологию. Хотелось бы спросить еще, такие оболочки над системой как Qt/KDE/GNOME, это какие технологии,
обьектные или нет? И почему их надо защищать? Может это систему надо защищать от всяких там оболочек, чтобы они эту систему ненароком не убили. В Linux это не проблема, потому как Qt/KDE/GNOME, это действительно оболочки, и к самой системе отношения никакого не имеют. А как дела обстоят в Windows уважаемый? В 2000-ой лично у меня, например, периодически появлялся "синий экран смерти" при обращении к инвалидному хэндлу меню.
Ну и совсем бездоказательно утверждение автора, что концепция "все есть файл" является ограниченной и не даст ОС развиваться. До FUSE Венде, как до неба раком.
И если вы еще не согласились, что Windows - тупиковая ветвь, то перечитайте вышесказанное еще раз, а потом еще, и так до наступления полного просветления

Svolotch 2006-11-08 19:29:52 (#)

бггг.... статью не читал, но аффтара осуждаю... :)))
каменты порадовали....
уважаемый Hmm, прочитал ваш пост 18 раз, а просветление все еще не наступает, что я неправильно делаю?

Hmm 2006-11-09 12:58:08 (#)

Svolotch
Это не мое предложение, а автора. Только вместо Линукс само вставилось слово Виндовз. :)

Svolotch 2006-11-10 16:29:56 (#)

ну дык я ж автора не читал... ;-)

troninster 2006-11-11 00:44:12 (#)

Сначала я вообще не хотел спорить с коментами. Согласитесь спорить с человеком который читает невнимательно - проблематично. Ведь в самом начале статьи сказано, что сравнивается только ядро NT (причем больше как концепт, нежели как конкретная реализация) и POSIX (точнее Linux и тоже как концепт).

Так ведь нет начинают втирать, что и MFC тут убога по сравнению с glibc и API не совместимы и дыры.
Вот ей богу, разве про то, что они хороши или плохи, хоть слово было сказано?
Единственный вопрос который прямо затрагивает ядро - это поддержка графики в нем. Решение безусловно крайне неоднозначное. Пусть это будет на совести M$ я не брался быть их адвокатом. Я лишь сравниваю архитектуры.

А теперь по пунктам:
>И с чего это автор вдруг решил, что попытка представления всех ресурсов как обьекты в Windows

Поправка не Windows, а ядра NT в userspace объектность как таковая не представлена и пользы никакой от ней нет.
Для справки: NTOS впервые была создана в 1989 году, какой Linux тогда был не подскажите?

>Опять же, из статьи совершенно не понятно, почему >сигнальная концепция Linux "убогая"

Это все-таки не было целью статьи.
А вот почему почему - ответов много.

Уже одной реализации таймеров в *nix/linux достаточно, чтобы говорить об убогости.

В *nix/linux возможен один синхронный таймер на поток. В NT возможности более гибкие: любой поток может либо пользоваться функцией Sleep(), либо, при необходимости, создать неограниченное количество таймерных объектов, и синхронизироваться с любым из них при помощи функции
WaitFor...Object().

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

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

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

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

физически можно, об этом так и сказано, читайте внимательнее.

>А в третьих, почему эту оболочку надо защищать
:)
по вашему защита, права доступа и привилегии - это глупость получается?
Вообще защищать нужно не оболочку отдельно, а систему целиком, но коль скоро система получается гетерогенной (ядро само по себе), а объектная оболочка само по себе.
Как админить такой хозяйство совершенно не понятно. Это ад получится почище сегодняшнего в виндовсах различных (там-то объектность внутри, а поверх непонятно что).

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

>Ну и совсем бездоказательно утверждение автора, что >концепция "все есть файл" является ограниченной и не >даст ОС развиваться. До FUSE Венде, как до неба раком.

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

Игорь Вагулин 2006-11-12 13:20:41 (#)

>Последняя мысль нуждается в некотором разъяснении. В Linux >100 приоритетов, приоритеты 1-99 – реального времени. >Потоки/процессы не реального времени (а их подавляющее >большинство) выполняются на единственном приоритете 0,

Вы либо плохо осведомлены либо лукавите. Приоритетов в Linux 140. 0-99 как вы и сказали RT 100-140 это пользовательские приоритеты.

>Другим ограничением *nix и особенно Linux является >монолитность ядра.

То что конкретно вы думаете что это недостаток ещё ничего не доказывает. Вы хоть аргументы какие-нибудь приведите.

>Поэтому разработчикам в частности приходится каждые 3-4 >месяца выпускать новую версию ядра с поддержкой большего >количества железа
/usr/src/linux/Documentation/stable_api_nonsense.txt - здесь написано почему нет стабильного апи для драйверов полагаю нет смысла повторять.

Напоследок хотелось бы задать вопрос. Почему когда я в виндовс компилирую программу(причем этой таске дан низкий приоритет) я не могу нормально писать письма в отлуке периодически всё подвисает ?

troninster 2006-11-12 23:50:21 (#)

>Вы либо плохо осведомлены либо лукавите. Приоритетов в Linux 140. 0-99 как вы и сказали RT 100-140 это пользовательские приоритеты.

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

>То что конкретно вы думаете что это недостаток ещё ничего не доказывает. Вы хоть аргументы какие-нибудь приведите.

Так думаю не только я. Существенная часть системных разработчиков полагает, что ярхитектура монолитного ядра уже давно морально устарела.
Почитайте дискусси Торвальдса и Таненбаума по поводу микроядерности.
Что касаемо преимуществ, то, например, одно из преимуществ ОС, основанной на микроядре - возможность ее гибкой конфигурации: от минимальной бездисковой embedded, загружаемой с ПЗУ, до мощной
полнофункциональной ОС.

>Почему когда я в виндовс компилирую программу(причем этой таске дан низкий приоритет) я не могу нормально писать письма в отлуке периодически всё подвисает ?

:)
Тут траблы разные могут быть: от кривизны рук (как пользователя и админа, так и разработчиков винды), до дефицита помяти.
Вы не забывайте, что в 2000-й видне и особенно XP для совместимости с бездарной веткой Windows 3.11 -95-98-2-ME ядро NT серьезно переработано по сравнению с ранними версиями (обычно говорят, что оно было просто изуродовано :). Поэтому грабли в коде вполне вероятны. Причина слива производительности может быть и в этом.

Игорь Вагулин 2006-11-13 01:24:32 (#)

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

Чего-то я не понимаю, мы сейчас про о(1) шедулер я полагаю? На каждый процессор по RunQueue в ней 2 массива тасков Active и Expire в них односвязные списки тасков. По списку на приоритет всего 140 списков. после завершения юзер таски к ней применяеться эстиматор который меняет её приоритет в зависимости от поведения. Ваше утверждение что все юзер таски имеют одинаковый приоритет неверно.

>Что касаемо преимуществ, то, например, одно из преимуществ ОС, основанной на микроядре - возможность ее гибкой конфигурации: от минимальной бездисковой embedded, загружаемой с ПЗУ, до мощной

ifdef, endif и вперёд с монолитным ядром :)

>NT серьезно переработано по сравнению с ранними версиями (обычно говорят, что оно было просто изуродовано :).

Что бы не служило причиной но после Линуха работать за Виндой крайне неприятно. Проект над которым я работаю на Линуксе собираеться быстрее на 60 процентов. Не это ли говорит о бездарной реализации основных подсистем ядра.

Игорь Вагулин 2006-11-13 01:43:47 (#)

>асинхронный ввод-вывод в *nix на самом деле фикция.
Ссылка на библиотеку асинхронного воода-вывода.
http://www.kernel.org/pub/linux/kernel/people/andrea/libaio/
Какие здесь проблемы ?

geek 2006-11-13 13:21:09 (#)

>Тупиковость концепцим "все есть файл" это скорее личное мнение. Если вы считаете, что это передовая технология, вам карты в руки.

нет, надо на каждый чих писать свой API как в виндовсе.

Evgeniy 2006-11-13 13:38:06 (#)

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

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

Как вы думаете распространяются закрытые драйверы для Linux? Вместе с собранным ядром?

man modprobe

robot12 2006-11-13 13:58:00 (#)

>Есть экзотичный Plan9 и его потомок Inferno. Но по уже указанным причинам первый в принципе ничем не лучше Linux, а второй может использоваться пожалуй только embedded-системах (отсутствие VFS как «класса» знаете ли никому еще на пользу не пошло).

Аффтор ... Вы хоть про Styx (9p2000) что нить знаете ? И про концепцию "всё есть файл" ??? Может Вам, уважаемый, всё таки почитать документацию ?

anonymous 2006-11-15 00:44:52 (#)

Проблема в том, что разработкой NT занимались фанатики, а не прагматики. Во-первых, автор плохо знаком с Unix-системами, если имеет неосторожность утверждать, что Unix присуща концепция "всё есть файл". В Unix related литературе ясно сказано, что с точки зренеия пользователя, в операционной системе Unix существуют два типа объектов: файлы и процессы. Это азбука. Во-вторых, мнимая гибкость NT, о которой пишет автор, не более чем фикция. Архитектура Unix куда более модульна, нежели архитектура NT. Основная концепция гомоморфности системы как раз и не позволяет обеспечить должный уровень масштабируемости и гибкости при условии ошибок на стадии проектирования. На заре становления ООП разработчики NT увлеклись романом и незаметили как балка затрещала ней :) API ядра проектировалось исходя из некоторых реалий, которые в последствии изменились. Теперь можно брать цветные фломастеры и рыдая рисовать древовидную структуру NT. Автор так увлеченно пишет о том, как космические корабли могут бороздить просторы Большого театра и о высоком уровне flexebility ядра, способного поддерживать хоть OS/2, хоть POSIX. На деле же, NT не может поддерживать даже Win API из-за неминуемых конфликтов. ООП понятие довольно таки сферо-вакуумное, что бы на него полагаться полностью. Серебряных пуль не бывает. В Unix, архитекрура ядра (да и остальной системы) выглядит как конструктор. Модули могут быть динамически загруженны в ядро и удалены в процессе работы системы и заменены другими в плоть до применения kexec. Всё, что можно вынести из ядра в user space, туда и вынесено, что там происходит уже другой вопрос. ООП типы и объекты Qt, X11, DE, beryl, API для распределенных вычислительных сред и тому подобные вещи просто добавляются рядом или используются как звено в цепи и обеспечивают разумную гибкость и ту самую мифическую модульность, которой якобы наделена NT. Просто Unix архитектуру не из пальца высосали, а разработали методом проб и ошибок, в отличии от NT, над которой трудились с целью разработать конечный продукт и заморозить систему на как можно более долгий срок. Что бы не вышло как с DOS\Win9x. А потом начинать всё сначала. С этой точки зрения ядро NT держит марку.

Hmm 2006-11-15 17:15:49 (#)

По автору, масштабируемость, наверное, тоже признак технической отсталости, негибкости и убогости ядра. Только вот в Топ500 суперкомпьютеров мира Windows почему то не замечена вообще. А Linux 75%:
http://top500.org/stats

Микроядерный порт Linux:
http://l4linux.org/

RaSla 2006-11-17 14:24:26 (#)

Хватит спорить!

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

2 All:
Лично мне ПОФИГ на какой системе выполнять свою работу и получать удовольствие! Лишь бы это отнимало меньше времени и было УДОБНО!!!
(на данный момент:
работать удобнее однозначно в Линухе,
а отдыхать немного чаще в Винде)

Сидеть в Никсах, только потому что это Никсы - неоправданный ФАНАТИЗМ.
Любить Винду, только потому что "хотели сделать как лучше" - неоправданный ОПТИМИЗМ.

Мне нужно прямо сейчас, прямо здесь и прям для меня!
В этом плане, мне сейчас больше нравится Линукс.

П.С.: ОЧЕНЬ большое Спасибо всем!!!
Было приятно посмотреть на всё это с разных сторон :)
Но флэйм хорош в меру!
Новый комментарий



© 2006-2016 Вадим Калинников aka MooSE

Выход прост - куплю планшет.