Движение свободных операционок в корпоративный сектор, в первую очередь в качестве серверов разного рода, поставило перед ними задачи многопроцессорной поддержки и масштабируемости. И задачи эти постепенно решались: в том или ином виде многопроцессорные конфигурации давно поддерживаются ядром Linux и FreeBSD, затем такая поддержка появилась в NetBSD и OpenBSD. Тем не менее, ни одна из этих ОС не дотягивала ещё до масштабируемости проприетарных UNIX’ов.
Правда, в мире свободного софта испокон веков развивалось другое течение, косвенно связанное с многопроцессорностью – так называемые микроядерные ОС. Идея их – в том, чтобы максимально возможную часть обязанностей ядра (взаимодействие с устройствами, файловыми системами и т.д.) вынести в пользовательское пространство памяти, оставив за ядром только коммуникационные функции. Теоретически рассуждая, это должно было бы обеспечить упрощение устройства системы, легкость её портирования на новые архитектуры (в том числе и многопроцессорные), а также возможности масштабирования.
Из микроядерных решений наибольшее признание получило ядро March, разработанное в Университете Карнеги-Меллона, а затем развивавшееся в Университете Юты. Оно легло в основу ряда проектов разработки свободных ОС – самым известным из них долгое время был Hurd, разработка которого затем была переведена на другое микроядро – L4. Что, однако, не приблизило проект к состоянию, пригодному для применения. Однако существовали и другие попытки создания свободных микроядерных ОС – проекты xMach и Yamit. И оба они своё развитие прекратили.
Таким образом, можно констатировать, что судьба свободных микроядерных проектов была (и остаётся) печальной. Что, помимо их невостребованности, объясняется ещё и технологическими причинами: судя по всему, разработчики не смогли обеспечить приемлемую производительность своих систем: ведь упрощение устройства ядра влечёт за собой усложнение межпроцессных коммуникаций.
Как ни странно, удачные реализации микроядерной архитектуры имели место быть в проприетарном секторе: на ранних версиях Mach основывалась знаменитая система NEXTStep, видевшаяся лет 15 назад платформой фантастического будущего. А предпоследняя, 3-я, версия Mach легла, вместе с системными службами FreeBSD, в фундамент современной MacOS X.
Таков был исторический фон, на котором развернулись описанные далее события.
Итак, где-то в середине июня 2003 г. Мэтт Диллон (Matt Dillon), вместе с группой товарищей сообщил о начале работы над новой ОС BSD-семейства – DragonFlyBSD. Возник сайт проекта – http://www.dragonflybsd.org и репозиторий её исходников, cозданный 16 июня 2003 года – этот день можно считать именинами системы. Репозиторий этот основывался на кодовой базе FreeBSD 4-й ветки, имевшей статус стабильной (хотя в то время уже вовсю развивалась ветка 5-я, вбирающая в себя все инновации BSD-мира).
Новая система получила и собственный тотем – стрекозу, что должно символизировать легкость и быстроту её. Кстати, разработчики не гнушаются и сокращенных названий своей системы – DragonFly и даже DFBSD, к которым, вслед за ними, время от времени, будем прибегать и мы.
Может возникнуть (и многократно возникает) вопрос: для чего нужна ещё одна BSD-система? Разве не вдоволь насмотрелись мы на изобилие Linux-дистрибутивов, чтобы и BSD-системам желать той же участи?
Вопрос этот, конечно, носит сугубо риторический характер. Ведь если новые операционные системы создаются – значит, это кому-то нужно. И каждая такая система (если она, конечно, действительно нова и оригинальна) привносит в наш мир что-то свое, увеличивая, тем самым, сложность его и разнообразие.
А в оригинальности DragonFlyBSD отказать невозможно. Ибо, при практически полном внешнем сходстве с прототипом (FreeBSD 4.X), «внутре» у нее всё было другое: управление памятью и процессами, представление о драйверах устройств и виртуальной файловой системе, вплоть до нового типа файлов – вариантных символических ссылок (varsims).
В основу DragonFly была положена модель легковесных нитей ядра (LWKT – Light Weight Kernel Threads), что само по себе и не ново. Новым стал механизм планирования нитей – вместо единого планировщика (sheduler) их было введено несколько, по числу процессоров. Нити привязаны к своим процессорам изначально, однако допускается передача выполнения нити с одного процессора на другой при некоторых особых условиях. Данные отдельных нитей могут быть кэшированы независимо для каждого процессора.
Подобно системам с микроядерной архитектурой, в DragonFly максимум функций ядра вынесен из его пространства памяти в пользовательское пространство (userland). В первую голову это относится к драйверам устройств – таким образом достигается рост как производительности, так и надежности системы, резко уменьшая вероятность её «падения» под воздействием неправильно работающего драйвера.
Это повлекло за собой отказ от традиционного для UNIX механизма системных вызовов (каковой лишь эмулируется в целях совместимости). Его место занял механизм сообщений (messages) и их очередей, т.н. портов (ports), подобный применяющемуся в микроядре March, упоминавшемся выше.
При этом DragonFly не является микроядерной ОС – базовые функции по прежнему возлагаются на ядро (и размещаются в его пространстве памяти). Однако почти всё прочее может быть безболезненно собрано в качестве модулей юзерланда.
Таким образом, можно видеть, что основные инновации DragonFly ориентированы на работу в многопроцессорных системах. А вопрос о том, есть ли что делать простому пользователю на многопроцессорном, с позволения сказать, компьютере, мы рассмотрели уже в ходе обзора хардверной ретроспективы.
Далее, важно, что если матушка DragonFly, FreeBSD, изначально предназначенная только для архитектуры i386, все более эволюционировала в сторону кроссплатформенности (в 5-й ветке к поддержке древней Alpha был добавлен Sparc, а затем и PowerPC), то наша «стрекоза» возвращается на исходные рубежи. И единственной поддерживаемой архитектурой в ней является Intel-совместимая – на тот момент только 32-битная (64-разрядный вариант долго находился в состоянии разработки).
Такое ограничение в плане поддерживаемого «железа» может показаться отступлением от истинного UNIX Way. Однако на момент выхода DFBSD сбылось мрачное пророчество, высказанное почти двадцать лет назад в одном компьютерном журнале:
Через десять лет все платформы, кроме IBM PC, уйдут в небытие
И все остальные архитектуры в качестве настольных платформ полностью утратили актуальность. Разработчики DragonFly считались с этой реальностью: в их тогдашних планах переноса на другие архитектуры не было (нет его и сейчас). Что компенсировалось возможностью оптимизации под платформу, единственно значимую практически. Это дало свои плоды – по визуальному быстродействию в настольных условиях DragonFly со дня своего зарождения существенно опережала FreeBSD как 5-й, так и 4-й ветки.
Наконец, в DragonFly на уровне ядра поддерживался механизм, напоминающий prelinking (предварительное связывание с разделяемыми библиотеками) – насколько мне известно, особенность почти уникальная. И обещавшая значительный прирост скорости загрузки (а возможно, и быстроты исполнения) сложных программ, связываемых со множеством библиотек.
Всё сказанное выше было технологическим обоснованием для того, чтобы отнестись к DragonFly не просто как к ещё одному BSD-клону. Но это подкреплялось и субъективным фактором – личностью организатора проекта.
К моменту начала работы над DragonFly Мэтт Диллон был широко известен (в узких кругах) благодаря трем разработкам: Си-компилятору для платформы Amiga (именно из этой ОС пришла в DragonFly идея «ядерного прелинкинга»), утилите dcron и, главное, системе управления виртуальной памятью во FreeBSD. Не то чтобы он был единственным автором последней, однако вклад его в эту тему был одним из определяющих современный облик FreeBSD, Да и к аналогичной подсистеме ядра Linux он приложил руку.
Что немаловажно, в специальной статье (присутствующей в официальной документации FreeBSD) Мэтт сумел описать архитектуру виртуальной памяти языком, понятным для широких масс трудящихся. Очень рекомендую к прочтению – во введении к ней высказано немало интересных мыслей общего характера. Тем более, что она доступна и в русском переводе. А пока позволю себе вторично процитировать её фрагмент:
Самой большой ошибкой, которую может допустить программист, является игнорирование истории.
И дальнейшая история показала, что в DragonFly ошибки истории прошедшей были учтены.
Некоторое время проект развивался как бы закулисно. Конечно, все желающие ознакомиться с прототипом системы могли свободно получить её исходники с сайта проекта через CVS и развлекаться с ними в свое удовольствие (нужно ли говорить, что DragonFly распространялась и распространяется на условиях лицензии BSD?). Однако в виде, пригодном для установки простыми смертными, она не существовала.
