Автор: Алексей Федорчук
Сочинялось на протяжении 2004-2005 годов и в разных вариантах размещалось на нескольких сайтах. Ибо не каждый день на наших глазах возникает (и, главное, активно развивается, а не забрасывается по прошествии недолгого времени) новая операционная система.
…Много воды утекло,
и всех, кто мог чего-то помнить,
давным-давно замочили.
Гоблин, Братва и кольцо
Кто не догадался — речь идет о DragonFlyBSD, ответвлении FreeBSD, проект которой стартовал в июле 2003 г. А поскольку я следил за ним фактически с самого начала, то и решил сочинить эту заметку исторического плана. Пока еще чего-то помню (и пока меня не замочили:-)).
Содержание
Хардверная ретроспектива
Несколько лет назад я писал, что мы живем в интересное время: впервые с момента появления персональных компьютеров, софтверная индустрия не смогла выполнить свое сакральное предназначение — вытрясать пользовательские кошельки на перманентный апгрейд своих машин, что обеспечивало бы финансовые источники для дальнейшего развития аппаратных средств. И ныне мы видим плоды этого: развитие главного компьютерного «железа» — процессоров и чипсетов, то есть того, что определяет лицо платформы, — фактически прекратилось.
Конечно, время от времени производители бодро рапортуют об очередном повышении тактовой частоты «камней», увеличении кэша level n до совершенно невообразимых, некогда вполне достаточных для основной памяти, объемов, а то и добавлении очередного level’а, дополнительных наборов инструкций под замысловатыми названиями, встраивания в чипсеты поддержки всего, чего можно (и даже того, чего, как недавно казалось — нельзя, например, полноценной 3D-графики). Однако накал страстей вокруг всего этого давно уже не тот, несколько напоминая бег стометровки — мало кого (кроме фанатов этого вида спорта) волнует, какую десятую секунды отыграл один суперспринтер у другого.
А главное, что, подобно рекордам в стометровке, достижения «камнестроителей» все меньше волнуют широкие пользовательские массы. Ведь от медведя не убежит и олимпийский чемпион, а успеть за пивом в магазин перед его закрытием способен любой мало-мальски тренированный человек. Так и с компьютерами: настолько-пользовательские задачи в большинстве случаев решаются средствами любого подручного «железа», купленного за пределами лавки древностей. А «тяжелые» задачи как требовали часов (а то и суток) пахоты персоналок, так и требуют (и потому решаются разумными людьми обычно не на PC’шках).
Фактически за последние годы производители предложили нам два архитектурных решения, претендующих на революционность. Первым (по времени) была архитектура Pentium 4. Не будем распространяться здесь о ее достоинствах или недостатках как таковой. Для нас сейчас важно только то, что она обеспечила возможность роста тактовой частоты процессоров, поражающего воображение (пользователя, тянущегося к бумажнику). И к тому же казавшейся безграничной…
Правда, на счет безграничности жизнь довольно скоро внесла свои коррективы. И разговоры о том, что эта технология позволит играючи достичь тактовой частоты в 10 гигагерц, как-то стихли сами собой — нынче даже о четырех гигагерцах почему-то не любят говорить вслух.
Впрочем, по сему поводу можно сказать словами поэта:
Минутной печали не стоит, друзья, предаваться
Ведь быстрым машинам нет смысла у нас появляться
Ибо в кои веки чисто случайно оказалось, что гигагерцев, в отличие пряников, как раз и хватило на всех (кроме тех, которым, как уже говорилось, их не будет хватать всегда). И разница между 2-х и 4-гигагерцной машиной в быстродействии была бы, думаю, меньше, чем между P-133 и P-166…
Вторая, казалось бы, революционная, новинка — 64-разрядные вычисления. Вспомним, каким прорывом в светлое будущее были 32-битные процессоры для PC, те самые первые «трешки», которые сделали возможным портирование на эту архитектуру Unix и его порождений — свободных POSIX-совместимых операционок. Повторится ли история ныне?
Ответ можно дать уже сейчас — и ответ, увы, отрицательный. Потому что в те далекие уже годы аппаратура PC едва поспевала за софтом — 32-битные ОС разменивали уже второй десяток лет своего существования, и приложений, использующих 32 разряда на полную катушку, было уже вдоволь. Нынче же… Да вы и сами знаете, как нынче обстоит дело с переходом на 64 бита «внутре» ОС, а уж когда дело дойдет до пользовательских программ — и пророк Заратуштра предсказать не возьмется.
Потому что на самом деле 64-разрядность в пользовательском сегменте не востребована. Ведь что она дает по большому счету? Увеличение объема максимально адресуемой памяти? Да, прекрасно, но есть ли у пользователя 64 Гбайт ОЗУ и терабайты дискового пространства? И главное, нужны ли они ему в принципе? И понадобятся ли в обозримом будущем. Так что единственная ниша пользовательских приложений, где 64 бита хоть как-то заиграют — параноидальная криптография. Конечно, в свете недавних событий нас попробуют убедить, что без последней в современном мире террора и анти-террора не выжить каждой домохозяйке, однако и здравый смысл пока еще не совсем отменили…
Так что усилия «камнестроителей» пропали бы втуне. Если бы еще не одно новшество, о котором я сознательно не упоминал ранее — Hyper Threading, то есть виртуальная мультипроцессорность. Каковая в некоторых (правда, весьма редких) задачах давала вполне даже реальный прирост производительности. Опять же, мало значащий для пользователей самой распространенной операционки, работающих преимущественно интерактивно. Но могущий способствовать производительности труда брата-POSIX’ивиста. Вследствие врожденной лености отдающего предпочтение всякого рода скриптам, пакетным заданиям и прочим средствам автоматизации.
Однако Hyper Threading — не более, чем суррогат истинной мультипроцессорности. Своего рода мультипроцессорность для бедных, но гордых. Да еще и вызывающая некоторые сомнения с точки зрения банальной безопасности. И потому, сказавши А, производитель процессоров неизбежно должны открыть рот для произнесения Б. То есть переходить к собственно двухпроцессорным конфигурациям в пользовательском сегменте.
Разговоры о двухпроцессорных пользовательских десктопах на нашем веку возникают не впервые. Помните, как дешевенькие Celeron’ы первого призыва можно было вставлять в относительно не очень дорогие двухпроцессорные «мамы»? Получая таким образом нечто вроде «народного суперкомпьютера» А еще масла в это пламя подлили Opteron’ы, также в начальном своем уровне вполне доступные для широких масс — по крайней мере, для узкого круга лучших их представителей.
Правда, первая линия «народной мультипроцессорности» была очень быстро пресечена производителем. А во втором случае дешевизна базовой платформы с лихвой компенсировалась дороговизной требуемой для нее регистровой памяти. Да и в любом случае цена двухпроцессорного решения будет более чем вдвое выше однопроцессорного — лишний сокет тоже денег стоит:-).
Однако идея мультипроцессорности для народа продолжает витать в воздухе — никаким иным способом создать впечатление прогресса уже не удается. И первый шаг в этом направлении сделала, насколько мне известно, IBM со своими Power4 — вероятно, абсолютными рекордсменами по «чистому» (=тестовому) быстродействию. В том числе и благодаря тому, что имели варианты с двумя и более процессорными ядрами в едином корпусе.
Сами по себе Power4 (как и пришедшие им на смену Power5) ориентировались на индустриальный сектор. Однако на базе их были созданы процессоры G5 — сердце современных Mac’ов, имеющие, в том числе, и двухъядерный вариант. У которого есть все шансы со временем широко распространиться по столам пользователей платформы от Apple.
Правда, пользователям PC’шек от этого было бы ни холодно, ни жарко. Однако и их «камнестроители» не заставили себя ждать: и AMD, и Intel уже анонсировали свои двухъядерные решения. А имеющиеся данные о строимости и тех, и других вполне вписываются в рамки «суперкомпьютера для народа» (хотя и не для всякого его представителя).
Так что вполне возможно, что уже при следующем апгрейде перед нами встанет выбор — приобретение машины с традиционным одноядерным процессором или, за чуть большое, но сопоставимые деньги — машины с процессором двухъядерным. Готовы ли мы к этому? То есть — способны ли получить от последней хоть какой-то выигрыш в производительности, компенсирующий затраты?
Софтверная перспектива
Исходя из самых общих соображений очевидно, что ожидать двукратного увеличения быстродействия от самого факта удвоения числа процессоров (вне зависимости, каждый ли в своем сокете, или «два в одном стакане») не приходится. Во-первых, на «железном» уровне два и более процессоров будут совместно использовать какие-то общие ресурсы компьютера — память, кэши, шины (в зависимости от конкретной аппаратной реализации).
Во-вторых, неизбежны потери быстродействия за счет «накладных расходов» — синхронизации и согласования операций, выполняемых на разных процессорах.
В-третьих, системные и прикладные задачи, выполняемые на многопроцессорной машине, должны допускать их распараллеливание, иначе любое увеличение количества «числодробителей» доставит мало радости пользователю.
И, наконец, в-четвертых, эффективность многопроцессорных конфигураций в значительной мере определяется стилем выполнения пользовательских задач. Очевидно, что преимущественно интерактивные методы работы от удвоения «камней» выиграют весьма мало — в любом случае тут узким местом окажется пресловутый человеческий фактор.
Решение проблем многозадачности на «железном» уровне — это задача производителей аппаратуры, и влиять на нее мы не в силах (а можем только учитывать). Минимизация же «накладных расходов» и распараллеливание задач — это сугубо вахта разработчиков софта, в первую очередь — системного (хотя в последнем случае ее разделяют и создатели программ прикладных). Ну а эффективное использование достижений тех и других — это уже сфера деятельности нас, пользователей.
И нужно сказать, что пользователи Unix-подобных (или, точнее, POSIX-совместимых) операционок, в силу самой специфики их работы и укоренившихся привычек, подготовлены к многозадачности лучше других. И способны получить от нее больший выигрыш, даже без кардинального update собственной личности.
Действительно, что происходит на типичной пользовательской Unix-машине — в очередной раз оговорюсь, что речь я веду только о пользовательских десктопах и, где-то, о рабочих станциях (ведь плоха та персоналка, которая не мечтает стать workstation, разница между ними ныне в основном количественная)? На ней постоянно что-то компилируется, архивируется/разархивируется, кодируется/декодируется, бэкапится, — и все параллельно, и, в большей или меньшей степени, без интерактивного участия пользователя. Озаботившегося, разумеется, заблаговременно, скриптами для запуска своих задач, выводом полученных данных в логи и прочие файлы, и так далее — за интерактивным режимом остается только просмотр результатов. И, конечно же, их осмысление:-).
Так что вырисовывается заманчивая картина — все это изобилие параллельно работающих задач выполняется действительно параллельно, будучи раскиданным по разным процессорам. Дело остается за малым — реализовать ее в кодах.
Изначально создатели Unix (и ранних его клонов) ни о какой многопроцессорности не помышляли. И один из краеугольных камней его идеологии — концепция монолитных процессов, выполняемых на одном процессоре квазипараллельно, за счет квантования времени, — казалось бы, препятствует реализации распараллеливания задач по разным «камням».
Тем не менее, когда многопроцессорные серверы и рабочие станции стали реальностью в индустриальном секторе, в дополнение концепции процесса была создана и концепция т.н. нитей, или потоков (threads — тот же общегерманский корень, что и в названии литературного жанра — Пряди об исландцах). Это — части процесса, выполняемые параллельно и почти независимо друг от друга (в том числе и на отдельных процессорах), разделяющие, тем не менее, ресурсы составленного из них процесса. То есть собственного контекста, в том числе и отдельного пространства памяти, они не имеют, почему носят еще и имя легковесных процессов (light weight process) — обычные Unix-процессы в этом случае можно называть «тяжелыми».
В разных системах концепция нитей была реализована по разному. Выделяют нити ядра, прикладные нити и промежуточные между ними варианты — прикладные нити, поддерживаемые нитями ядра, с деталями можно ознакомиться в монументальной книге Юреша Вахалии: Unix изнутри. СПб: Питер, 2003). Для нас сейчас важно, что концепция нитей создала предпосылки для реализации мультипроцессорных архитектур в Unix.
Нужно заметить, что само по себе понятие нитей возникло задолго до Unix — чуть ли не со времен Очакова и ламповой электроники. И уже тогда были выявлены существенные недостатки этой концепции (см. руководство С.Д.Кузнецова по операционной системе Unix). Однако — увы — за истекшие годы ничего лучшего для поддержки мультипроцессорности придумано не было.
Как уже говорилось (и это очевидно из общих соображений), проблема мультипроцессорности встала в первую очередь в индустриальном секторе. Где по ряду причин (в том числе и исторических) традиционно преобладали проприетарные представители Unix-семейства. И разработчики последних доблестно эту проблему разрешили. Можно спорить, где она была решена лучше, где — не так хорошо, однако общепризнанно: масштабируемость — главная отличительная черта (и главный козырь) и AIX от IBM, и Solaris от Sun, и прочих их братьев-конкурентов.
Свободные POSIX-совместимые ОС, в отличие от проприетарных, разрабатывались преимущественно или в университетско-академической среде, или просто энтузиастами-любителями, как правило, на подручном оборудовании. Среди которого многопроцессорные суперкомпьютеры встречались не так уж и часто (солнце народной мультипроцессорности еще не показало из-за горизонта своих первых лучей). И потому долгое время поддержка многопроцессорности была слабой стороной и Linux, и BSD-систем (по крайней мере, для платформы Intel и совместимых).
Движение свободных операционок в корпоративный сектор, в первую очередь в качестве серверов разного рода, поставило перед ними задачи многопроцессорной поддержки и масштабируемости. И задачи эти постепенно решались: в том или ином виде многопроцессорные конфигурации давно поддерживаются ядром Linux и FreeBSD, недавно такая поддержка появилась в NetBSD и OpenBSD (для платформы i386, в иных архитектурах она имелась, вроде бы, и раньше). Тем не менее, согласно всем встречавшимся мне мнениям, ни одна из этих ОС не дотягивает еще до масштабируемости проприетарных Unix’ов.
Время от времени на форумах возникают споры, где лучше реализована многозадачность — в Linux или во FreeBSD. В обсуждение чего мы вдаваться не будем — уже сам по себе факт периодичности возникновения таких споров свидетельствует, что и там, и там многопроцессорность реализована не идеальным образом. Что косвенно подтверждается недавним тестированием всех свободных операционок (интересно, что участвовавшая в нем Solaris для Intel-архитектуры отнюдь не показала затмевающих результатов — видимо, сведения о ее замечательной масштабируемости относятся исключительно к родной аппаратной платформе).
Правда, в мире свободного софта испокон веков развивалось другое течение, косвенно связанное с многопроцессорностью — так называемые микроядерные ОС. Идея их — в том, чтобы максимально возможную часть обязанностей ядра (взаимодействие с устройствами, файловыми системами и т.д.) вынести в пользовательское пространство памяти, оставив за ядром только коммуникационные функции. Что, теоретически рассуждая, должно было бы обеспечить упрощение устройства операционки, легкость ее портирования на новые архитектуры (в том числе и многопроцессорные), а также возможности масштабирования.
Из микроядерных операционок наибольшее признание получило ядро March, разработанное в Университете Карнеги-Меллона, а затем разрабатывавшееся в Университете Юты (нужно сказать, что на обоих сайтах давно не видно признаков активности).
Ядро March легло в основу ряда проектов разработки свободных ОС — наиболее известен из них Hurd — долгострой проекта GNU, разработка которого недавно переведена на другое микроядро — L4. Однако были другие попытки создания свободных микроядерных ОС — мне известны проекты xMach (правда, сайт его не откликается уже больше года) и Yamit (совсем недавно и его постигла та же участь).
Можно видеть, что судьба свободных микроядерных проектов была по преимуществу печальной. Что, помимо их невостребованности, объясняется еще и технологическими причинами: судя по всему, разработчики не смогли обеспечить приемлемую производительность своих систем: ведь упрощение устройства ядра влечет за собой усложнение межпроцессных коммуникаций.
Как ни странно, удачные реализации микроядерной архитектуры имели место быть в проприетарном секторе: на ранних версиях Mach основывалась знаменитая система NEXTStep, видевшаяся лет 15 назад платформой фантастического будущего. А предпоследняя, 3-я, версия Mach 3 легла, вместе с системными службами FreeBSD, в фундамент современной MacOS X. От которой вторично отпочковался уже собственно свободный проект — Darwin (или, точнее, Gnu Darwin.
Таков был исторический фон, на котором развернулись описанные далее события.
Хроника текущих событий
Итак, где-то в середине июня 2003 г. Мэтт Диллон (Matt Dillon), известный, вместе с группой товарищей объявил о начале работы над новой ОС BSD-семейства — DragonFlyBSD. Возник сайт проекта — http://www.dragonflybsd.org и репозиторий ее исходников, cозданный 16 июня 2003 г. — этот день можно считать именинами системы, на кодовой базе FreeBSD 4-й ветки, имевшей статус стабильной (хотя в то время уже вовсю развивалась ветка 5-я, вбирающая в себя все инновации BSD-мира).
Новая система получила и собственный тотем — стрекозу, что должно символизировать легкость и быстроту ее. Однако заглавная буква F в названии ОС (как подчеркивает Мэтт Диллон, вопреки правилам английской орфографии) говорит, что и ассоциация с мощью дракона и его мудростью также не возбраняется. И кстати, разработчики не гнушаются сокращенных названий своей системы — DragonFly и даже DFBSD; вслед за ними будем и мы время от времени прибегать к ним.
Может возникнуть (и многократно возникает) вопрос: для чего нужна еще одна BSD-система? Разве не вдоволь насмотрелись мы на изобилие Linux-дистрибутивов, чтобы и FreeBSD желать той же участи?
Вопрос этот, конечно, носит сугубо риторический характер. Ведь если новые операционки создаются — значит, это кому-то нужно. И каждая такая система (если она, конечно, действительно нова и оригинальна) привносит в наш мир что-то свое, увеличивая, тем самым, сложность его и разнообразие.
Маленькое отступление: бытует мнение, что если бы 4.4BSD (еще не разделившаяся на Net- и FreeBSD) не погрязла бы в тяжбе с AT&T, и получила бы свободу в конце 80-х — начале 90-х годов, то в разработке Linux не было бы никакой необходимости. Не смотря на свою пылкую любовь к BSD-системам во всех их проявлениях, не могу с этим согласиться: если бы Linux’а не было — его следовало бы изобрести. Потому что без него (и внедренного Линусом в IT-индустрию метода разработки софта, известного под названием метода Тома Сойера) жить было бы скучно…
А в оригинальности DragonFlyBSD отказать невозможно. Ибо, при практически полном внешнем сходстве с прототипом (FreeBSD 4.X), «внутре» у нее все другое: управление памятью и процессами, представление о драйверах устройств и виртуальной файловой системе, вплоть до нового типа файлов — вариантных символических ссылок (varsims).
Впрочем, на теоретической стороне вопроса я останавливаться не буду. Со всеми инновациями DragonFly можно ознакомиться на сайте проекта и в документации к нему2. Вкратце остановлюсь только на наиболее важных моментах.
В основу DragonFly положена модель легковесных нитей ядра (LWKT — Light Weight Kernel Threads), что само по себе и не ново. Новым стал механизм планирования нитей — вместо единого планировщика (sheduler) их было введено несколько, по числу процессоров. Нити привязаны к своим процессорам изначально, однако допускается передача выполнения нити с одного процессора на другой при некоторых особых условиях. Данные отдельных нитей могут быть кэшированы независимо для каждого процессора.
Подобно системам с микроядерной архитектурой, в DragonFly максимум функций ядра вынесен из его пространства памяти в пользовательское пространство (userland). В первую голову это относится к драйверам устройств — таким образом достигается как рост производительности, так и надежность системы в целом, ибо вероятность «падения» системы от воздействия неправильно работающего драйвера стремится к нулю.
Это повлекло за собой отказ от традиционного для Unix механизма системных вызовов (каковой лишь эмулируется в целях совместимости). Его место занял механизм сообщений (messages) и их очередей, т.н. портов (ports), подобный применяющемуся в микроядре March, упоминавшемся выше.
При этом DragonFly не является микроядерной ОС — базовые функции, такие, как поддержка устройства, несущего корневую файловую систему, как и ее самой, все равно возлагаются на ядро (и размещаются в его пространстве памяти). Однако почти все прочее может быть безболезненно собрано в качестве модулей юзерланда.
Таким образом, можно видеть, что основные инновации DragonFly ориентированы на работу в многопроцессорных системах. А вопрос о том, есть ли что делать простому пользователю на многопроцессорном, с позволения сказать, компьютере, мы рассмотрели уже в ходе обзора хардверной ретроспективы.
Далее, важно, что если матушка DragonFly, FreeBSD, изначально предназначенная только для архитектуры i386, все более эволюционирует в сторону кроссплатформенности (в 5-й ветке к поддержке древней Alpha добавился Sparc, а в current-ветке неофициально поддерживается и PowerPC), то наша «стрекоза» возвращается на исходные рубежи. И единственной поддерживаемой архитектурой в ней является Intel-совместимая. Правда, в разработке находится поддержка ее 64-битного расширения от AMD — того самого, которое, похоже, принял на вооружение и Intel (имеется ввиду поддержка собственно 64-битного режима — в режиме 32-разрядном DragonFly прекрасно работает на Opteron и Athlon64 уже сейчас.
Такое ограничение в плане поддерживаемого «железа» может показаться отступлением от истинного Unix Way. Однако… Много лет назад в одном толстом компьютерном ежемесячнике (PC Magazine/RE) была опубликована статья (автора, к сожалению, не помню, а журнал давно потерян) с жутковато-апокалиптическим названием: Через десять лет все платформы, кроме IBM PC, уйдут в небытие. Во времена, когда вполне справно, кроме Mac и PC, на столах пользователей трудились и Amiga, и Next, когда начинались, пусть робкие, но попытки выхода на десктопы HP-PA и Alpha, это казалось невероятным.
Однако пророчество исполнилось — причем опережающими темпами. И хотя усилия, скажем разработчиков NetBSD вдохнуть вторую жизнь во все древние архитектуры вызывают уважение (хотя и напоминают несколько пассы некроманта), принудительная сила реальности такова: на ближайшие годы i386 (плюс AMD64 в разных ипостасях) останется практически единственной настольной платформой. И разработчики DragonFly с этой реальностью считаются (хотя, вероятно, и вынужденно — вследствие малолюдности команды): в их планах переноса на другие архитектуры не найти (правда, теоретически возможность этого и не отрицается). Что компенсируется возможностью оптимизации под платформу, единственно значимую практически. И замечу: такая оптимизация дает свои плоды: по визуальному быстродействию в настольных условиях DragonFly существенно опережает FreeBSD как 5-й, так и даже 4-й ветки.
Наконец, в DragonFly на уровне ядра поддерживается механизм, напоминающий prelinking (предварительное связывание с разделяемыми библиотеками) — насколько мне известно, особенность почти уникальная. И обещающая значительный прирост скорости загрузки (а возможно, и быстроты исполнения) сложных программ, линкуемых со множеством библиотек. Во всяком случае, пример Linux’а, где prelinking уже довольно давно реализован как пользовательский процесс, дает все основания для оптимизма.
Это все технологические обоснования для того, чтобы отнестись к DragonFly не просто как к еще одному BSD-клону. Но есть ведь и субъективный фактор. И это — личность организатора проекта.
К моменту начала работы над DragonFly Мэтт Диллон был широко известен (в узких кругах) благодаря трем разработкам: Си-компилятору для платформы Amiga (именно из этой ОС пришла в DragonFly идея «ядерного прелинкинга»), утилите dcron и, главное, системе управления виртуальной памятью во FreeBSD. Не то чтобы он был единственным автором последней, однако вклад его в эту тему был одним из определяющих современный облик FreeBSD, Да и к аналогичной подсистеме ядра Linux он приложил руку.
Что немаловажно, в специальной статье (присутствующей в официальной документации FreeBSD) Мэтт сумел описать архитектуру виртуальной памяти языком, понятным для широких масс трудящихся. Очень рекомендую к прочтению — во введении к ней высказано немало интересных мыслей общего характера. Тем более, что русский перевод ее доступен, например, здесь.
Так вот, позволю себе процитировать фрагмент из означенного мемуара:
Самой большой ошибкой, которую может допустить программист, является игнорирование истории, и это именно та ошибка, которую сделали многие другие современные операционные системы… Я плохо переношу тех, кого не учит история.
Эта фраза (значение которой не ограничивается программированием) вселяет надежду, что в DragonFly ошибки прошлого будут учтены. И первое же знакомство с этой системой эту надежду подтверждает.
Однако вернемся к истории DragonFly. Некоторое время проект развивался как бы закулисно. Конечно, все желающие ознакомиться с прототипом системы могли свободно получить ее исходники с сайта проекта через CVS и развлекаться с ними в свое удовольствие (нужно ли говорить, что DragonFly распространялась и распространяется на условиях лицензии BSD?). Однако в виде, пригодном для установки простыми смертными, она не существовала. По крайней мере, не распространялась.
Как вдруг, начиная с мая 2004 г., один за другим начинают появляться iso-образы компактов различных бета-версий DragonFly. Они не имели еще инсталлятора: следовало, руководствуясь документацией (вполне, впрочем, ясной, хоть и англоязычной), вручную разметить диск, создать файловые системы, перенести на них с дистрибутивного CD необходимые каталоги и произвести еще кое-какие манипуляции (типа создания файлов устройств и настройки стартовых сервисов). Задача была не то чтобы сверхъестественно сложной — но и не вполне тривиальной.
А затем… Затем, в июне 2004 г., появился пре-релиз DragonFly, точнее, DragonFlyBSD 1.0RC1. От своих бета-предшественников он отличался тем, что уже имел инсталлятор — BSD Installer, разработанный в рамках самостоятельного проекта как универсальный установщик для любых BSD-систем. Но впервые, насколько я знаю, опробованный именно на DragonFly.
Отличительная особенность BSD Installer в том, что теоретически к нему могут подключаться фронт-энды, созданные на базе самых разных библиотек. В дистрибутиве DragonFly был использован текстовый (псевдографический) фронт-энд на основе библиотеки ncurces. Однако, например, PC-BSD (клон FreeBSD, ориентированный на десктопное применение — см. сайт проекта) снабжена тем же инсталлятором с Qt’шной «мордой»…
Надо заметить, что уже в те далекие времена (в масштабах истории DragonFly) установка этой ОС проходила без малейших осложнений (в том числе и на «железо», на которое FreeBSD устанавливалась с трудом). Однако к использованию система была пригодной с трудом. Ибо, кроме базиса (соответствующего FreeBSD Distributions), не содержала почти ничего — ни Иксов, ни прекомпилированных пакетов (за исключением нескольких консольных утилит типа cvsup и cdrtools), ни собственной системы пакетного менеджмента (хотя в будущем таковая была обещана).
Нужно сказать, что пре-релизная стадия для DragonFly оказалась очень короткой: уже в начале июля 2004 года (11-го, если не ошибаюсь, числа), практически в годовщину проекта, было объявлено о выходе релиза — DragonFlyBSD 1.0-RELEASE. Правда, и он просуществовал недолго: как это нередко бывает, в него вкралось несколько мелких, но весьма неприятных ошибок. Хотя выявлены они были мгновенно и столь же быстро исправлены в баго-фиксном релизе 1.0A. Каковой и по сей день доступен на официальном сайте проекта, долгое время являясь официальной (точнее, супер-официальной) версией системы.
Начиная с этого момента, DragonFly можно было считать более-менее пригодной к использованию. Сам по себе дистрибутив по прежнему не включал ни пакетов, выходящих за рамки базовой системы, ни системы портов. Однако с самого момента его выхода прекомпилированные пакеты для DragonFly можно было найти сразу на двух сайтах — LiveBSD и GoBSD. Причем если на первом имелся лишь самый минимум-миниморум дополнительных приложений, то второй содержал практически все (за небольшими исключениями), что имелось в коллекции портов FreeBSD (с системой портов коей DragonFly сохраняет, при некоторых оговорках, совместимость и по сей день).
Однако жизнь не стояла на месте, и дальнейшая работа над системой не прекращалась: с интервалом в 3-5 дней на ftp-сервере проекта и его зеркалах появляются текущие снапшоты — как в виде дерева исходников в CVS-репозитории, доступном через cvsup (который, напомню, имеется в составе базовой системы), так и в виде iso-образов дистрибутивных CD. Образы cнапшотов выходят в свет в двух вариантах: собранные компилятором gcc версии 2.95 и 3.4.X. Первые позиционируются как рабочие, вторые — как преимущественно экспериментальные. Что, впрочем, не мешает и им функционировать вполне справно
Вообще говоря, модель разработки DragonFly отличалась от таковой FreeBSD своей линейностью: она не разветвлялась тогда на стабильную и разрабатываемую ветки (по крайней мере, пока). Просто некоторые из промежуточных снапшотов имели в имени своем пометку stable.
Надо заметить, что команда разработчиков DragonFly невелика: на соответствующей странице сайта перечислено, кроме Мэтта, 21 имя. Но эффективность их работы не может не вызвать восхищения.
Параллельно разработке самой DragonFly развивался упомянутый выше сайт GoBSD, созданный специально для дистрибуции новой системы. Распространявшийся на нем вариант DragonFly основыван был на одном из промежуточных стабильных снапшотов, но несколько отличался от оригинала по комплектации.
Двигалось дело и с портированием сторонних приложений. Во-первых, как я уже сказал, в DragonFly по сию пору не возбраняется использование системы портов матушки FreeBSD. Правда, ввиду того, что это все же разные ОС с разными ядрами, не все порты родительской коллекции под DragonFly собираются успешно. Однако для коррекции этого выступает подсистема dfports — в нее включены «неудачные», с точки зрения DragonFly, порты. И такой метод работает. Доказательством тому длинный список бинарников на GoBSD и сервере Fortunaty.net: и те, и другие собраны именно через обычные порты FreeBSD с учетом изменений dfports.
Позднее на GoBSD пошли другим путем: прикрутили в DragonFly pkgsrc — кроссплатформенную портообразную систему, заимствованную из проекта NetBSD. И таким образом в распоряжении пользователя новой ОС сразу оказалось все изобилие открытого и бесплатного софта, портированного на эту платформу — а надо отметить, что на NetBSD он портирован если не весь, то Bouno Parte. Именно наличием тарбалла древа pkgsrc, адаптированного для DragonFly, и отличается в первую очередь диск, распространяемый с GoBSD, от снапшотов проекта и его зеркал.
Однако оба варианта — не более, чем временные паллиативы. Потому что в рамках проекта DragonFly разрабатывается и собственная система управления пакетами, появление которой ожидается во второй официальной версии.
Впрочем, информации о дате выхода второй версии пока не имеется. Последнее знаковое событие в мире DrafonFly — выход ее версии 1.2, случившийся апреля 2005 года. Он примерно совпал с изменением схемы разработки ОС: отныне она имеет стабильную (четные номера во второй позиции и разрабатываемую ветки (с нечетной номерацией).
Такова на сегодняшний день короткая, но насыщенная история операционной системы DragonFlyBSD. Надеюсь, она не окончена, и будет дописываться по мере развертывания событий.
Последняя стабильная версия на сегодня — 2.0.1 — вышла в сентябре 2008 года, нестабильная — 2.1.1.