У истоков новой системы

У истоков новой системы

Итак, где-то в середине июня 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?). Однако в виде, пригодном для установки простыми смертными, она не существовала.

Так продолжалось до мая 2004 года, когда один за другим начали появляться iso-образы CD бета-версий DragonFly. Они не имели ещё инсталлятора: следовало, руководствуясь документацией (вполне, впрочем, ясной, хоть и англоязычной), вручную разметить диск, создать файловые системы, перенести на них с дистрибутивного CD необходимые каталоги и произвести ещё кое-какие манипуляции (типа создания файлов устройств и настройки стартовых сервисов). Задача была не то чтобы сверхъестественно сложной – но и не вполне тривиальной.

А затем… Затем, в июне 2004 гjlf, появился пре-релиз DragonFly, точнее, DragonFlyBSD 1.0RC1. От своих бета-предшественников он отличался тем, что уже имел инсталлятор – BSD Installer, разработанный в рамках самостоятельного проекта как универсальный установщик для любых BSD-систем. И впервые опробованный именно на DragonFly.

Надо заметить, что уже в те далекие времена (в масштабах истории DragonFly) установка этой ОС проходила без малейших осложнений (в том числе и на «железо», на которое FreeBSD устанавливалась с трудом). Однако к использованию система была пригодной лишь условно. Ибо, кроме базиса (соответствующего FreeBSD Distributions), не содержала почти ничего – ни Иксов, ни прекомпилированных пакетов (за исключением нескольких консольных утилит типа cvsup и cdrtools), ни собственной системы пакетного менеджмента.

Нужно сказать, что пре-релизная стадия для DragonFly оказалась очень короткой: уже в 11 июля 2004 года было объявлено о выходе релиза – DragonFlyBSD 1.0-RELEASE. Правда, и он просуществовал недолго: как это нередко бывает, в него вкралось несколько мелких, но весьма неприятных ошибок, которые были выявлены мгновенно и столь же быстро исправлены в корректирующем релизе 1.0A.

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

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

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

Первоначально предполагалось, оба варианта – не более, чем временные паллиативы, и в рамках проекта DragonFly будет разработана собственная пакетирования – насколько можно судить по отрывочным указаниям того времени, похожая на систему PBI, реализованную позднее в PC-BSD. Однако затем эта идея была оставлена, и до недавнего времени pkgsrc была единственной системой управления пакетами.

Такова была ранняя, короткая, но насыщенная событиями история операционной системы DragonFlyBSD на момент годовщины её первого релиза. В последующие годы в ней появилось немало новшеств, как косметических (например, настоящая графическая консоль – аналог режима frame buffer в Linux), так и весьма кардинальных. Среди последних необходимо отметить:

   • собственную реализацию виртуальной файловой системы, обеспечивающей доступ к практически всем файловым системам UNIX-подобных ОС

   • оригинальную файловую систему Hammer – точнее, интегрированная система размещения данных, по своим принципам сходная с возникший чуть раньше ZFS и несколько более «юной» btrfs.

Статическое создание файлов устройств сменилось динамической файловой системой устройств devfs. Со временем DragonFly была портирована на архитектуру x86_64. И, наконец, для управления пакетами она снова вернулась к собственной модификации портов FreeBSD – системе dports. А сразу же по появлении системы пакетного менеджмента pkg-ng внедрила её у себя – чуть ли не раньше, чем возник первый официальный репозиторий для родительской операционки (то есть всё той же FreeBSD).

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