Опубликовано Автор: alv

Слово о дистрибутивах

Автор: Алексей Федорчук
14 марта 2006 г

В статье о Base Linux мы сформулировали это понятие, определили его состав, а заодно и выяснили, что этот стройный системный комплекс разрабатывается множеством независимых разработчиков в рамках столь же самостоятельных проектов. Возникает очередной вопрос — а кто же берет на себя труд собрать этот комплекс воедино, нарастив его заодно разнообразными опциональными (то есть выходящими за пределы базовой функциональности) приложениями, включая оконную систему X, оконными менеджерами для нее, интегрированными десктопами, офисными пакетами, браузерами, коммуникационными программами и прочими столь необходимыми широким народным массам вещами?

Что такое дистрибутив

Имя этим героям IT-фронта — майнтайнеры дистрибутивов…

Что такое майнтайнер — ответить нетрудно: это тот, кто взваливает на себя вышеозначенную непосильную ношу. В физическом воплощении это могут быть

  • разномашстабные фирмы — наиболее популярные дистрибутивы, Red Hat и Suse, собираются силами сотрудников одноименной компании и корпорации Novell, соответственно;
  • крупные общественные объединения — ярким примером чему служит уже более чем десятилетнее развитие дистрибутива Debian;
  • отдельные разработчики, формирующие вокруг себя нечто вроде индивидуально-частного предприятия — тут мы вспоминаем Патрика Фолькердинга, на котором вот уже чертову дюжину лет держится дистрибутив Slackware;
  • такие же разработчики-индивидуалы, обрастающие со временем неким сообществом — наиболее показательным примером тут будет Дэниел Роббинс с его дистрибутивом Gentoo;
  • наконец, просто индивидуальные пользователи, решившие собрать индивидуальный же дистрибутив «для себя, любимого» — однако чаша формирования вокруг своего произведения более или менее обширного сообщества не минет и их, свидетельством чему — судьба CRUX Пера Лидена и Archlinux Джадда Винета.

Я привожу лишь примеры, наиболее известные миру или хорошо знакомые мне — на самом деле вариантов образования майнтайнерским команд намного больше, вплоть до прямого Госзаказа — каковым выступит разрабатываемый в Китае дистрибутив Red Flag. Или, скажем, деятельность dot-com предпринимателя и космического туриста Марка Шаттлворта, вдохновляющего и финансирующего команду разработчиков дистрибутива Ubuntu.

Одним словом, майнтайнер дистрибутива Linux — не профессия, а образ жизни. И редкий пользователь этой системы не мечтает на некотором этапе своего развития собрать дистрибутив собственный. А некоторые даже и воплощают свою мечту в жизнь. В результате число дистрибутивов растет из дня в день: только на сайте Distrowatch, самом полном ресурсе по учёту и контролю Linux-дистрибуции, их зарегистрировано почти полтысячи (но даже туда попадают не все дистрибутивы).

Остаётся определить только, что же это такое — дистрибутив Linux?

Для начала — о самом термине дистрибутив (Distributions). Как-то на одном из форумов возник вопрос об адекватном русском его эквиваленте. И, после обсуждения и обмена мнениями, участники постановили, что таковым будет слово дистрибутив. Почему? Да потому, что английское Distributions приобретает весьма разный смысл в зависимости от контекста. Для доказательство чего достаточно сравнить три словосочетания: Windows Distributions, FreeBSD Distributions, Linux Distributions.

Действительно, какие ассоциации вызывает у нас словосочетание дистрибутив Windows? Перед глазами сам собой возникает образ CD-бокса с голограммой, подтверждающей подлинность, приобретаемый за 100 примерно американских рублей в респектабельном компьютерном салоне. Или, чаще, его «базарная» копия, купленная за 100 рублей уже пост-советских, подчас более или менее точно воспроизводящая и внешний вид оригинала.

В то же время FreeBSD Distributions — понятие не материальное, а скорее идейное. Оно включает в себя ядро и комплекс самодостаточных средств для его функционирования и использования. То есть собственно и является операционной системой FreeBSD.

И, наконец, слова дистрибутив Linux (в обиходе — distro, а дальнейшем речь пойдет именно о нем) рождают в уме самые различные образы. Здесь будут и красивые коробки с книжками документации толщиной в десятки сантиметров, и аскетические CD-боксики с тонкой брошюркой, и сотни мегабайт качаемых из Сети ISO’шников, записываемых на болванки в домашних условиях, и даже наборчики из двух дискет — все это дистрибутивы Linux. Главное же в том, что вслед за словами дистрибутив Linux практически неизбежно следует имя собственное — Red Hat или Debian, Slackware или Gentoo, — имя им легион.

Подобно человеческому имени, имя дистрибутива — неотрывный его атрибут. Однако каких-либо правил имяобразования для дистрибутивов Linux не сложилось. Обычно они образуются из некоего символического названия и слова-эпонима ОС (например, Red Hat Linux), которое в обиходе часто опускается. Нередко символическое имя представляет собой более или менее осмысленную аббревиатуру. Так именная часть ASPLinux первоначально расшифровывалась как Application Service Provider. Многие майнтайнеры считают своим долгом подчеркнуть роль проекта GNU в формировании софта для своих дистрибутивов. В результате возникают названия вроде Debian GNU/Linux, или SourceMage GNU/Linux. В ходу также аббревиатуры от полного именования дистрибутивов, например, SLES — Suse Linux Enterprise Server.

Важно также, что номер версии дистрибутива никак не коррелирует с таковым ядра Linux. И, в общем случае, не коррелирует ни с чем вообще, вовсе не обязательно начинаясь с какой-то маленькой цифры. Так, первая по времени версия ASPLinux несла на борту номер 7.1, соответствующий версии материнского Red Hat (говорят, была еще и версия 7.0, но ее на Руси никто не видел). Возможны провалы в нумерации версий: Slackware версии 3.5 волшебным образом преобразовалась версию 7.0 (видимо, чтобы не отстать от соплеменного Red Hat). А некоторые майнтайнеры вообще именуют версии по году и сезону выхода, — примером тому старая практика Altlinux и современная — Gentoo и Mandriva. Последняя система, на мой взгляд, наиболее осмысленна и информативна для ориентации во времени выхода версий.

Так чем же завлекательно-таинственный Sorcerer отличается от фундаментального Archlinux’а, неопределенная аббревиатура ASP — от вполне прозрачной LFS, крестоносный CRUX — от легкомысленного Rubyx’а?

Комплекс Base Linux, обеспечивая исходную функциональность системы, далеко не способен удовлетворить запросы большинства пользователей. И потому нуждается в наращивании самыми разнообразными программами — от оконной системы X, менеджеров окон, интегрированных десктопов, до редакторов, браузеров, серверных и офисных приложений, и так далее. Которые, в свою очередь, связаны зависимостями с самыми разнообразными библиотеками и иными разделяемыми компонентами. Разрешение таких зависимостей — задача нетривиальная, и требует определенной системы. И тут мы приходим к определению дистрибутива Linux. Каковое я сформулировал бы так:

Дистрибутив Linux — это система комплектации ядра ОС и комплекса его окружения утилитами и прикладными программами.

Система комплектации (коль скоро речь идет именно о системной целостности) должна включать в себя все аспекты таковой — получение, установку, обновление и удаление программ, контроль их зависимостей и средства для разрешения оных, а также средства учета установленных компонентов. И вот тут мы приходим к первому из главных критериев классификации дистрибутивов.

Критерии классификации

Как известно, по сей день человечество придумало лишь два способа управления программным обеспечением — сборку их непосредственно из пакетов исходных текстов (авторских пакетов) и установку из прекомпилированных бинарных пакетов (дистрибутивных пакетов). В соответствие с чем мы и разделяем изобилие дистрибутивов Linux на два больших класса.

Первый класс — дистрибутивы пакетные: все их компоненты, от ядра и базовых утилит, и до самого распоследнего пользовательского приложения, устанавливаются из заранее собранных (прекомпилированных, бинарных) пакетов. Соответственно и распространяются эти дистрибутивы в виде набора прекомпилированных пакетов. А неотъемлемым компонентом такого дистрибутива будет система пакетного менеджмента.

За вторым классом закрепилось название Source Based дистрибутивов. На мой взгляд — не самое удачное, и по двум причинам. Во-первых, пакетные дистрибутивы в конечном счете, также собираются из исходников (потому что больше их просто не из чего собирать). А главное — дистрибутивы эти не просто собираются посредством компилятора и сопутствующих утилит, а собираются по вполне определенным правилам, обеспечивающим регистрацию установленных компонентов и разрешение их взаимных зависимостей. Набор таких правил испокон века носит имя системы портов, пришедшее из мира BSD. И потому второй класс правильнее было бы величать дистрибутивами портируемыми: какая-либо из портообразных систем оказывается столь же непременной их составляющей, как система управления бинарными пакета — для пакетных дистрибутивов.

Практически единственным чисто «исходнячным» дистрибутивом можно считать LFS Герарда Бикманса и варианты его многочисленных последователей — BLFS (Beyond Linux From Scratch — расширенный LFS для конечного пользователя), HLFS (Hardened Linux From Scratch — LFS повышенной секретности), CLFS (Cross Linux From Scratch — кросс-платформенный LFS). Однако характерно, что их пользователи, те, что не сделали сборку системы «с нуля» целью своей жизни, а используют их для практической работы, рано или поздно приходят к автоматизации процесса сборки посредством всякого рода самосочиненных скриптов, (субпроект ALFS — Automated Linux From Scratch, то есть автоматизированный LFS), получая в итоге очередные разновидности дистрибутивов портируемых. Именно таково происхождение RockLinux Клиффорда Вольфа — первого (1998 год) в истории дистрибутива, который можно было бы отнести к категории Source Based, возникшего до проекта LFS (и до появления самого термина, кстати говоря).

В отличие от пакетных дистрибутивов, дистрибутивы портируемые распространяются обычно в виде некоего базового прекомпилированного комплекта, более или менее соответствующего по составу выделенному выше Base Linux — с той лишь разницей, что тут компилятор и утилиты для сборки оказываются уже непременной его составляющей. Плюс — собственно система правил для получения и сборки всех остальных необходимых приложений. Причем правила эти распространяются и на компоненты базового комплекта — средства пересборки его (bootstrapping) практически обязательны для любого портируемого дистрибутива. Впрочем, некоторые из портируемых дистрибутивов (Archlinux — типичным тому примером) распространяются преимущественно в прекомпилированном виде, почему это понятие не тождественно понятию дистрибутива Source Based (собственно, последние можно рассматривать как подмножество портируемых дистрибутивов).

Четкую грань между пакетными и портируемыми дистрибутивами провести нелегко. С одной стороны, развитые системы пакетного менеджмента подразумевает возможность построения пакета непосредственно из исходников. Правда, обычно эта возможность не является «сквозной» (то есть распространяемой на систему в целом). Но Debian и его производные (включая Ubuntu и Kubuntu) включают средства тотального пересбора системы.

С другой стороны, как уже было сказано, ряд портируемых дистрибутивов (CRUX, например, или Archlinux) распространяется преимущественно в прекомпилированном виде, а система портирования выступает в качестве опции. С третьей же — системы пакетного менеджмента являются столь же неотъемлемой часть портируемых дистрибутивов, как и дистрибутивов пакетных. Другое дело, что, как правило, они оказываются вторичными по отношению к системе портирования и производными от нее. То есть разделить портируемые и пакетные дистрибутивы можно по субтрактивному принципу: первые имеют и систему портов, и систему пакетного менеджмента, тогда как вторые — только последнюю — но, опять-таки, в дистрибутивах семейства Debian последняя вполне в состоянии выполнить роль системы портов.

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

В пакетных дистрибутивах под пакетом понимается набор исполняемых бинарных файлов и необходимых им компонентов (дистрибутивный пакет). Разумеется, основой для его сборки служит тот же авторский пакет исходников, однако корреляция между ними отнюдь не однозначная. Обычной практикой пакетных дистростроителей является дробление авторского пакета на серию пакетов дистрибутивных, каждый из которых может быть установлен независимо от других. Обычно такое дробление проделывается со сложными пакетными пакетными комплексами, вроде вычленения отдельных монофункциональных пакетов из состава Иксов или из больших авторских пакетов KDE.

Таким путём достигается большая компактность инсталлированной системы: пользователь пакетного дистрибутива может выбрать для установки только те компоненты авторского пакета, которые необходимы лично ему (например, дистрибутивный пакет kget из всего авторского пакета kdenetworks), тогда как в портируемом дистрибутиве в большинстве случаев приходится устанавливать авторский пакет целиком.

Впрочем, возможна и обратная процедура — группировка нескольких авторских пакетов в единый дистрибутивный метапакет или метапорт, что призвано избавить пользователя от лишних размышлений. Так, выбрав для установки метапакет (или, как это называется в Debian и его клонах, виртуальный пакет) kde, пользователь автоматически получит в свое распоряжение все нужные ему компоненты этой графической среды. Впрочем, в сочетании с кучей вещей, заведомо ненужных — в примере с KDE ими наверняка окажется все изобилие поддерживаемых ею локалей, включая весьма экзотические (например, зулусскую или маорийскую).

О пакетах и пакетных дистрибутивах

Возможна ли более дробная классификация дистрибутивов каждого класса? Возможна, причем по независимым критериям. Так, для пакетных дистрибутивов напрашивается разделение по формату пакетов. Которые можно разделить на две группы — те, что содержат внутри себя мета-информацию (в частности, информацию о зависимостях пакетов), и пакеты, таковой лишённые.

Начнем со второй группы, как более простой. Это самые обычные тарбаллы, то есть компрессированные tar-архивы типа *tar.gz/*tar.bz2 (часто фигурирующие в форме tgz и tbz). Важно, что сами по себе tgz и tbz — это форматы вовсе не пакета, а именно архива (то есть определяются используемой утилитой компрессии — gzip или bzip2, соответственно).

А важно это потому, что те же самые tgz/tbz архивы могут прекрасно содержать в себе и мета-информацию, автоматически попадая тем самым в первую группу. Примеры из Linux-мира мне на ум не приходят, однако packages FreeBSD, в которых, при формальной принадлежности к обычным тарбаллам, содержится исчерпывающая информация о зависимостях, показывают, что ничего невероятного в этом нет.

Однако типичными представителями первой группы являются широко распространенные форматы пакетов rpm (Rpm Packages Manager, характерный для одноименного дистрибутива и его многочисленных потомков) и deb (свойственный дистрибутиву Debian и его клонам). И тот, и другой также представляют собой компрессированные архивы, которые, помимо набора собственно бинарных файлов с указанием путей их размещения в целевой файловой системе, содержат данные о зависимостях, хотя и представленные в разной форме. Впрочем, детали описания мета-информации в аспекте классификации дистрибутивов не важны.

Отсутствие в составе пакета информации о его зависимостях отнюдь не препятствует контролю над ними: он может осуществляться за счёт внешних баз данных репозиториев пакетов и локальных баз данных пакетов установленных. А функции удовлетворения зависимостей в этом случае целиком ложатся на программы, осуществляющие пакетный менеджмент. И надо отметить, что управление «чистыми» тарбаллами подчас оказывается более гибким, чем пакетами с информацией об их зависимостях.

Программы пакетного менеджмента — ещё один из критериев классификации. Правда, собственно средства установки пакетов жёстко привязаны к их формату — для установки rpm-пакетов служит одноимённая утилита (rpm), пакеты deb устанавливаются посредством утилиты dpkg, для пакетных тарбаллов предусмотрены собственные средства, в зависимости от их формата (и обычно — дистрибутив-специфичные, не смотря на похожие, и даже подчас одинаковые, имена, типа pkg_add). Конечно, существуют средства взаимной трансформации пакетов разных форматов (типа rpm2cpio, rpm2tgz или почти универсальной утилиты alien), однако возможности их применения ограничены — очевидно, что из rpm-пакета (и тем более «чистого» тарбалла) получить полноценный deb-пакет невозможно.

Однако существуют еще и средства пакетного мета-менеджмента, если так можно выразиться (собственно, только они-то и заслуживают названия систем управления пакетами). Наиболее известное и распространённое из них — apt (Advanced Packaging Tools). Появившийся сначала в Debian’е и рассчитанный, соответственно, на deb-пакеты, он очень быстро стал универсальным кросс-пакетным механизмом установки, удаления и обновления программ, успешно работая с пакетами rpm (дистрибутивы Connectiva, Altlinux), тарбаллами Slackaware (механизм slapt-get). И в принципе не видно препятствий к прикручиванию его к тарбаллам любого формата — от «чистых» до сколь угодно насыщенных метаинформацией.

Под явным влиянием apt возникли и иные системы пакетного менеджмента — yum, urpmi и так далее. Однако они ориентированы только на rpm-пакеты (вероятно, их можно использовать и для иных форматов, но кому это нужно при наличии apt?) и потому не получили столь широкого распространения, оставаясь принадлежностью «родительских» дистрибутивов и более-менее точных их клонов. Так, yum, насколько мне известно, используется только в Red Hat/Fedora и ASPlinux, urpmi — достояние Mandrake, и судьба его после образования Mandriva (потомка кросс-кузенного брака с Connectiva, впервые прикрутившей apt к rpm-пакетам) не ясна.

Так что если классификация пакетных дистрибутивов по формату пакетов — условно говоря, на rpm-based, deb-based и tarball-based, — имеет некоторый резон, то разделение их по средствам управления оными все больше утрачивает смысл.

Порты и портируемые дистрибутивы

Обратимся теперь к дистрибутивам портируемым. Их также можно разделить на две группы — дистрибутивы, распространяемые преимущественно в виде исходников (то есть собственно Source Based) и дистрибутивы, распространяемые главным образом в прекомпилированной форме.

Самым известным и распространенным представителем первой группы является Gentoo, меньшей популярностью пользуются Sorcerer и его потомки — SourceMage и Lunar. Все они образованы из базового тарбалла (или набора взаимоисключающих тарбаллов, рассчитанных на разные условия установки, как Gentoo) и системы получения, компиляции, установки, учета и контроля зависимостей сторонних (то есть выходящих за пределы Base Linux) пакетов. Не смотря на их принципиальное сходство (обусловленное наследованием идейных традиций портов FreeBSD), двух одинаковых среди них мы не обнаружим — система portage из Gentoo отличается от «заклинаний» (sorcery) из Sorcerer как реализацией, так и приемами использования.

Преимущественно «исходнячное» распространение Source Based дистрибутивов не исключает их пакетирования (так, Gentoo распространяется и в прекомпилированном варианте). Соответственно, имеют они и средства управления пакетами — однако те не образуют самостоятельной целостности, а являются составной частью системы портов.

Представителями прекомпилированных дистрибутивов, обладающими системой портов, являются CRUX и Archlinux. В отличие от предыдущей группы, в них портообразные системы (ports и ABS, соответственно) мирно сосуществуют с самостоятельными (и весьма развитыми) средствами пакетного менеджмента: так, pacman из Archlinux, если еще и не достиг мощи Debian’овского apt’а, то стремительно движется в этом направлении. Тем не менее, сами пакеты, распространяемые в составе дистрибутива, генерируются за счет портообразной системы, которая позволяет также легко выполнить и пересборку базовой системы в соответствии с запросами пользователя.

К слову говоря, пакеты Archlinux, представляющие собой (как и пакеты большинства дистрибутивов этой группы) «чистые» тарбаллы, являют пример эффективного контроля зависимостей за счет внешних баз данных — базы пакетного репозитория (на установочном диске и на сервере проекта) и базы пакетов, установленных на локальной машине. Гибкость такого «внешнего» метода пакетного менеджмента определяется тем, что пользователь может легко создать собственный пакетный репозиторий в базой данных, в которой описаны только нужные ему зависимости.

О предназначении

Я столь подробно остановился на системах пакетного менеджмента потому, что полагаю их основополагающим критерием классификации дистрибутивов Linux, вытекающим из самой их природы. Однако и остальные критерии классификации игнорировать не след. И одним из таких критериев традиционно выступает назначение дистрибутива. В этом аспекте обычно выделяется три их группы — дистрибутивы серверные, десктопные и системы специального (подчас узкоспециализированного) назначения. Давайте посмотрим, насколько это обоснованно.

Для начала отметаем различие между серверными и десктопными системами. Действительно, Mandrake Linux, со дня своего возникновения позиционируемый как типичный user-ориентированный дистрибутив, даже в своей установочной программе имеет опцию — установки в качестве сервера. С другой стороны, серверные редакции Red Hat или Suse ничем (технологически) не отличаются от своих младших десктопных родственников, и вполне могут быть использованы в качестве последних. Правда, никто, скорее всего, делать этого не будет — при изобилии существенно более дешевых альтернатив, однако это уже относится к сфере ценовой политики…

Конечно, существуют и чисто серверные разновидности дистрибутивов, просто не содержащие в комплекте поставки никаких пользовательских приложений, вплоть до отсутствия оконной системы X. В качестве характерного примера тут можно упомянуть Altlinux Castle. Однако такие системы правильнее было бы отнести к разряду узкоспециализированных.

Так что мы опять-таки приходим к бинарной классификации — на дистрибутивы общего назначения (или универсальные) и назначения специального, не так ли? Не совсем. Потому что специализированные системы, как правило, самостоятельного значения не имеют. Создаваясь на базе систем универсальных — за счет сознательного урезания их функций. А универсальность дистрибутива именно в том и состоит, что из него можно выкроить и сетевой роутер, и ftp- или http-сервер, и даже игровую станцию (вспомним game-CD проекта Gentoo) или некий аналог бытового телевизора (MoviX).

С другой стороны, разделение на универсальные и специализированные дистрибутивы на практике имеет некоторое значение. В первую очередь — из-за расплодившихся в последнее время LiveCD — Linux-систем, способных не только запуститься, но и функционировать с компакт-диска, без установки на винчестер. Правда, большинство из них — производные «нормальных» дистрибутивов: из того же Gentoo их можно печь, как блины. А самостоятельные разработки — типа Knoppix’а — играют сугубо демонстративную роль. Если же они используются как рабочие, то превращаются в самый обычный Debian (применительно к примеру Knoppix’а).

Тем не менее, разделить дистрибутивы по назначению можно, но иначе, а именно: на дистрибутивы «для себя» и дистрибутивы «для всех» — эта альтернатива красной нитью проходит через всю историю Unix и Linux. Первая группа представляют собой скорее конструкторские наборы для построения индивидуальной системы, отличаясь более-менее простыми инсталляторами и слабо развитыми средствами конфигурирования (с выраженной тенденцией к ручным настройкам). Самый характерный пример этой группы — Gentoo, вообще не имеющий ни инсталлятора, ни конфигуратора (точнее, в нем в этом качестве выступают командная оболочка и текстовый редактор).

Дистрибутивы «для всех» — это системы, работающие «из коробки», такие, как Red Hat, Suse, Mandrake. Они отличаются красивыми графическими инсталляторами и средствами сквозного конфигурирования, делающими установку и настройку легкой и простой. Оборотная сторона чего — недостаточная гибкость того и другого, а также сложность глубокой индивидуализации системы: очевидно, что представления об идеале у всех разные, и попытка создать идеал «для всех» приводит к тому, что он не достигается ни для кого…

Очевидно, что к категории дистрибутивов «для себя» относятся все системы портируемого класса, тогда как среди пакетных дистрибутивов преобладают системы «для всех». Однако в последнем случае исключений не намного меньше, чем правил. Так, типично пакетный дистрибутив Slackware, безусловно, нужно отнести к системам «для себя». А Debian, в зависимости от стратегии инсталляции, может быть превращен в систему и той, и другой категории.

Говоря о дистрибутивах «для себя», я отнюдь не подразумеваю их малой распространенности: так, Gentoo за последние годы прочно обосновался среди лидеров по популярности (а ранее, испокон веков, в этом качестве стабильно пребывала Slackware). И не отрицаю, опять же, что система «для всех» может быть также весьма индивидуализирована — просто внутреннее устройство Red Hat или Mandrake пользователя к тому отнюдь не подталкивает. А, скажем, YAST из Suse до недавнего времени так просто препятствовал «ручному» вмешательству в настройки (видимо, полагая это разновидностью рукоблудия. С другой стороны, готовые решения на базе портируемых дистрибутивов часто приближаются по своим качествам к системам «для всех» — и тут можно вспомнить CRUX Evolution, пользовательский вариант комплектации изначального CRUX.

В общем, грань между дистрибутивами «для всех» и «для себя» достаточно условна: как первые, за редчайшими исключениями, создавались в том числе и «для себя» (иначе не удалось бы убедить других использовать то, чем не пользуешься сам), так и вторые, как правило, собирались в расчете на то, что они потребуются еще кому-нибудь. Впрочем, к этому вопросу мы еще вернемся в заключительном разделе.

Есть и другой критерий аналогичного разделения — на дистрибутивы, дружественные к пользователю, и дистрибутивы, дружественные, по выражению Клиффорда Вольфа (создателя Rocklinux — одного из первых Source Based дистрибутивов), к администратору. Причем последнее отнюдь не предполагает серверной ориентации дистрибутива: ведь на десктопе каждый пользователь сам себе администратор. И, позаботившись о своем удобстве в первом качестве, не лишним было бы вспомнить и о собственных же интересах — во втором.

И тут встает вопрос о предмете общесистемного конфигурирования, что в значительной своей части сводится к стилям стартовых сценариев. Конечно, разделение дистрибутивов по этому признаку на две группы (стиль System V и BSD-подобный стиль) — объективная реальность, весьма важная для пользователя в ипостаси администратора (и, тем более, для собственно администратора). И тут можно наблюдать интересную закономерность: практически все дистрибутивы «для всех» придерживаются схемы инициализации в стиле System V, тогда как среди дистрибутивов «для себя» доминируют вариации на тему BSD-подобного стиля. Наводит на размышления, не так ли?

О распространении

Можно разделить дистрибутивы и по условиям распространения: на свободные и коммерческие. Где лежит грань между ними — проще пояснить на примере. Так, типичным примером свободных дистрибутивов можно считать Debian. Это не значит, что его нельзя продавать. Вполне даже можно скачать полный набор из почти полутора десятков образов CD, растиражировать их, вложить в красивую коробку и, сопроводив печатной документацией, продавать за деньги. А если еще обеспечить сопровождение и поддержку — то даже за деньги большие. Однако, поскольку поступить так имеет право каждый, на изначальной свободе дистрибутива это никак не скажется.

А можно — взяв за основу то же Debian, дополнить его проприетарными компонентами (купив соответствующие лицензии у их разработчиков), продавать полученный комплект. И это будет уже дистрибутив коммерческий.

Правда, часто грань между коммерческими и свободными дистрибутивами оказывается трудноуловимой, примером чему служат сопряженные пары Red Hat/Fedora и Suse/OpenSuse, которые представляют собой, в сущности, одни и те же системы, разница между которыми сводится к наличию или отсутствию проприетарных компонентов и технической поддержки. Хотя не совсем, второй пример показывает еще один тип соотношений: OpenSuse выступает по отношению к Suse в качестве своего рода «фронтира», на котором обкатываются инновации, прежде чем быть включенными в коммерческий вариант. Так что если Fedora можно трактовать как «Red Hat для бедных», то OpenSuse — это скорее «Suse для смелых».

Вопросы генетики дистрибутивов

Широкой популярностью пользуется классификация дистрибутивов по генетическим, если так можно выразиться, линиям. Таковых в первом приближении выделяется три: клоны Slackware, Debian и Red Hat, происходящие от одноименных патриархов дистростроения. В значительной мере она совпадает с приведенной выше классификацией по формату пакетов — tarball-, deb- и rpm-based, однако, как показывает неоднократно приводимый пример Suse, отнюдь ей не идентична.

Направленность развития основных генетических линий весьма различна. Клоны Slackware традиционно развиваются в двух направлениях. С одной стороны, на ее базе создаются специализированные монофункциональные системы. С другой — немалое число энтузиастов занимается совершенствованием исходного дистрибутива путем прикручивания к нему развитых систем управления пакетами — от традиционно вездесущего механизма apt до новомодного pacman (заимствованного из Archlinux), портов FreeBSD и даже такой экзотики, как pkgsrc, привнесенного из NetBSD.

История и направленность клонирования Debian подробно рассмотрена в специальной статье. Здесь отмечу лишь, что семейство это отличается наибольшей степенью совместимости — вплоть до того, что большинство Debian-клонов могут безболезненно комбинировать пакетные репозитории друг друга и материнской системы.

Наибольшее разнообразие царит в линии Red Hat. Самые популярные его производные, как прямые, например, Mandrake, так и «внучатые» — примером потомок последнего Altlinux, очень быстро утрачивали сходство и с первопредком, и с непосредственным родителем. Даже те из его дериватов, которые первоначально возникали как точные клоны исходного дистрибутива с некоторыми дополнительными возможностями — именно так позиционировался ASPLinux, — постепенно приобретали своеобразие. И, не смотря на то, что линия Red Hat использует наиболее распространенный формат пакетов, о совместимости бинарников между ее представителями в общем случае говорить не приходится.

Интересно рассмотреть количественные соотношения между тремя выделенными линиями Linux-дистрибуции. Бытует устойчивое представление о том, что наиболее клонируемым из «патриархов» является Red Hat. Что, однако, не выдерживает элементарной проверки цифрами. В таблице 1 собраны сведения о количестве производных трех ветеранов дистростроения (Slackware, Debian, Red Hat) — как ныне здравствующих, так и в Бозе почивших.

Дистрибутив Slackware Debian Red Hat Fedora Mandrake Suse RPM-Based
Активные 38 122 21 52 15 4 92
Всего 46 152 42 72 17 6 137
%% активности 82 80 50 72 88 67 67

Примечание: таблица составлена по данным Disctrowatch.

Так вот, из приведенных цифр, как дважды два, следует, что Red Hat, даже с учетом не только прямых (Fedora), но и косвенных (Mandriva), а также очень условных (Suse, происходя от Slackware, заимствовала лишь формат пакетов) потомков, породил далеко не рекордное число клонов. Зато доля умерших проектов среди них составляет чуть не половину.

Существенно более продуктивным с точки зрения клонирования оказывается Slackware — причем и процент «живых» проектов среди ее потомков существенно выше. Это и не удивительно — будучи по сути своей конструктором, эта система просто провоцирует пользователя на создание собственного дистрибутива, особенно специального назначения. Остается только удивляться, сколько таких дистрибутивов «для себя» оказалось нужным еще кому-то, помимо своих создателей, и продолжает развиваться.

Тем не менее, место лидера среди клонопородителей, как количественно, так и качественно (по числу «живых» проектов), безусловно, принадлежит Debian: число его активно развивающихся производных практически равно сумме ныне здравствующих потомков Slackware и rpm-based дистрибутивов, вместе взятых.

Вообще, генетика дистрибутивов Linux весьма запутана и неоднозначна, и потому генетический подход не в состоянии охватить всего их многообразия. Изрядное число весьма известных дистрибутивов невозможно вывести от какого-либо первопредка. Типичным примером тут выступает Gentoo. Будучи идейным наследником умершего проекта Stampade, концепцию своей системы управления пакетами он заимствовал у портов FreeBSD. В дистрибутивах CRUX и Archlinux тесно сплелись традиции Slackware (хотя ни тот, ни другой назвать его клонами нельзя ни в коем случае), BSD-систем вообще и портов FreeBSD в частности. А система управления бинарными пакетами Archlinux (pacman) возникла и развивается под явным воздействием Debian’овского apt.

Несколько слов в заключение

Итак, дистрибутивы Linux можно разделить по трем независимым критериям на три пары частично перекрывающихся по составу групп. С одной стороны, по способу комплектации обособляются дистрибутивы пакетные и портируемые, с другой, по назначению — дистрибутивы «для всех» и «для себя», с третьей же (ведь эта медаль имеет три стороны, не так ли?) — свободные и коммерческие.

Конечно, классификацию дистрибутивов можно углубить: в частности, пакетные дистрибутивы разделить по формату пакетов, портируемые — по соотношению прекомпилированных и портируемых пакетов, и так далее. Однако мы этим заниматься не будем. А вместо этого зададимся философским вопросом: а за каким зеленым нужно все это изобилие дистрибутивов? И не лучше ли было бы сосредоточить усилия разработчиков на двух-трех наиболее перспективных системах?

Отвечая на второй вопрос, скажу: с точки зрения чисто практической — да, вероятно, лучше. И попытки «концентрации усилий» предпринимались — достаточно вспомнить United Linux, объединение Suse, Mandrake, Caldera Linux и Connectiva, четырех крупнейших, за исключением Red Hat, майнтайнеров. Попытка эта претерпела полную фетяску — и не только из-за неприсоединения Red Hat и сутяжничества Caldera (преобразовавшейся в SCO). Как не увенчались пока успехом и попытки стандартизирующих организаций — разработчиков LSB (Linux Standard Base) и FHS (Filesystem Hierarchy Standard), — ввести «единомыслие на Руси» (пардон, среди майнтайнеров дистрибутивов).

И прична тому очень проста: каждый имеет свои представления о том, что перспективно и бесперспективно, хорошо и плохо. И Linux-дистростроение — эта одна из тех немногих областей человеческой деятельности, где индивидуум имеет реальную возможность реализовать свои представления на практике — не только без вреда для окружающих, но подчас и с пользой для общества. Linux не был бы Linux’ом, если бы не предоставлял бы пользователю множество альтенатив на выбор — ибо, как я пытался показать в статье о Base Linux, альтернативен по своей сути. Перед теми же, кто нуждается в единообразии и унификации (а есть сферы деятельности, где без них не обойтись) — перед ними расстилается упорядоченный мир BSD-систем…

Ну а на первый вопрос легко ответить словами Антуана де Сент-Экзюпери: если дистрибутивы создаются, значит, это кому-то надо. Хотя бы одному человеку — его создателю. А поскольку, как сказал мой друг Володя Родионов, совсем уж уникальных людей очень мало, то есть шанс, что любой дистрибутив найдет своих пользователей. Яркими чему примерами являются RockLinux Клиффорда Вольфа и CRUX Пера Лидена: будучи классическими системами «для себя», созданными исключительно в соответствие с собственными представлениями о дистростроении, они достаточно быстро стали центрами кристаллизации собственных Community.

Конечно, время от времени создаются дистрибутивы, которые не нужны никому — и в первую очередь своим создателям (такой пример из недавнего прошлого мы знаем, не так ли?). Однако это — редчайшие исключения из общего правила, и, думается, они обречены на скорое забвение.

И вообще, точки над i в судьбе дистрибутивов расставит история: системы, сохраняющие интерес для пользователей и разработчиков, развивались, развиваются и будут развиваться — возможно, под другим именем и другими майнтайнерами. Или заложенные в них идеи будут реализованы в рамках более иных дистрибутивов. Если же интерес утрачен полностью — они тихо и незаметно канут в Лету. Так пожелаем же всем начинающим майнтайнерам, чтобы чаша сия их миновала…