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