На сочинение этой заметки меня
побудила недавняя статья Виктора Костромина “
Периодическая таблица дистрибутивов
Linux”, в которой была
сделана попытка разработать классификацию дистрибутивов Linux.
Или, скорее, обсудить принципы подхода к такой
классификации.
Содержание
Преамбула
Вообще говоря, попытки
классификации дистрибутивов Linux предпринимались неоднократно
- наверное, с того момента, как впервые оформились три первых
генеральных линии их развития. Однако времена меняются, и
дистрибутивы меняются вместе с ними. И та самая, первая,
классификация их на линии Slackware, Red Hat, Debian давно уже
не отвечает реалиям текущего момента. Применительно в которому
Виктор и написал свою статью. Сама по себе ее форма служит
предлогом к обсуждению, тяга к коему лишь частично была
реализована на Linuxforum`е. И потому ниже находит свое
естественное продолжение.
Однако сначала - несколько
вводных замечаний. Первое касается самого термина
дистрибутив
(Distributions). Как-то на том же Linuxforum`е возник вопрос об адекватном русском его
эквиваленте. И, после обсуждения и обмена мнениями выяснилось,
что таковым будет слово дистрибутив:-). Почему? Да потому, что английское
Distributions приобретает весьма разный смысл (как в
оригинале, так и в переводе) в зависимости от контекста. Для
доказательство чего достаточно сравнить три словосочетания:
Windows Distrinutions, FreeBSD Distributions, Linux
Distributions.
Действительно, какие ассоциации
вызывает у нас словосочетание дистрибутив Windows? Перед глазами сам собой возникает образ
CD-бокса с голограммой, подтверждающей подлинность,
приобретаемый за 100 примерно американских рублей в
респектабельном компьютерном салоне. Или, чаще, его купленная
за 100 рублей уже пост-советских "базарная" копия, подчас
более или менее точно воспроизводящая и внешний вид
оригинала.
В то же время FreeBSD Distributions - понятие не материальное, а скорее
идейное. Оно включает в себя ядро и комплекс самодостаточных
средств для его функционирования и использования. То есть
собственно и является операционной системой
FreeBSD.
И, наконец, слова
дистрибутив
Linux (а дальнейшем речь
пойдет именно о нем) рождают в уме самые различные образы.
Здесь будут и красивые коробки с книжками документации
толщиной в десятки сантиметров, и аскетические CD-боксики с
тонкой брошюркой, и сотни мегабайт качаемых из Сети
ISO`шников, и даже наборчики из двух дискет - все это
дистрибутивы Linux. Главное же в том, что вслед за словами
дистрибутив
Linux практически
неизбежно следует имя собственное - Red Hat или Debian,
Slackware или Gentoo, - имя им легион. Так чем же
завлекательно-таинственный Sorcerer отличается от
фундаментального Arch`а, неопределенная аббревиатура ASP - от
вполне прозрачной LFS, крестоносный CRUX - от легкомысленного
Rubyx`а?
Пара слов о Base
Linux
Чтобы ответить на этот вопрос,
нужно для начала определиться с тем, что же такое все-таки
дистрибутив Linux (или, как говорят в народе, Linux-дистро)?
Что для начала требует определения для самого понятия Linux.
Попробуем ответить на поставленные вопросы последовательно -
начиная с самого общего.
Широко распространенное мнение о
том, что Linux - это не более чем ядро операционной системы,
видится мне несколько ограниченным. Ибо само ядро - вещь в
себе, и не пригодно не только к использованию, но даже не
способно загрузить само себя. И потому, с точки зрения любого
пользователя этой операционки (а таковыми являются все, кто ее
использует: от конечного пользователя до собственно
разработчика ядра), она представляет собой некий минимально
самодостаточный комплекс утилит и приложений, обеспечивающих
функционирование и использование ядра ОС, который можно
назвать Base Linux.
Понятие Base Linux неоднократно
рассматривалось ранее - последнее по времени изложение этой
концепции можно найти здесь. Должен, однако, заметить, что ныне мои
представления на сей предмет несколько изменились - не без
влияния статьи Тихона Тарнавского. И ныне в этот комплекс я включил бы
следующие компоненты:
-
ядро
Linux (ну еще бы:-));
-
средства его загрузки (собственно
загрузчик и сценарии инициализации) и обеспечения
функциональности (то есть утилиты, реализующие
поддерживаемые ядром функции - работу с устройствами,
файловыми системами, сетевыми протоколами; согласитесь, мало
радости пользователю от поддержки ядром некоей файловой
системы, если он не располагает инструментами для работы с
ней);
-
минимальный набор системных и
пользовательских утилит (преимущественно, но не обязательно
происходящих из недр проекта GNU) и интегрирующую их
командную оболочку;
-
средства обеспечения работы
утилит и приложений - общесистемные библиотеки.
Сравнение этого списка с
ранее приведенным показывает, что из него исключены
компилятор и прочие средства разработки (точнее в данном
контексте - средства сборки) программ, именно на это меня
подвигла упомянутая выше статья Тихона. Почему - ответить не
сложно: некоторые дистрибутивы, как будет показано ниже, в
принципе способны обходиться без таковых.
А вот перечисленные компоненты
можно обнаружить в любом дистрибутиве Linux, однако состав их
может различаться. Конечно, ядро Linux будет безальтернативно
присутствовать всегда - иначе это был бы не Linux, а другая
операционная система. Да и утилиты поддержки будут одни и те
же - очевидно, что для обеспечения работы с файловой системой
Ext2fs (для примера) потребуется соответствующий пакет
(e2fsprogs). Однако дальше возможны варианты: конечно, на
практике во всех дистрибутивах Linux в качестве общесистемной
командной оболочки используется bash, а в роли общесистемной библиотеки
выступает glibc. Однако теоретически никто не мешает
заменить первую любым POSIX-совместимым шеллом, а вторую -
каким-либо аналогом, и реально такие случаи известны.
Например, в Linux для встроенных систем в качестве главной
Си-библиотеки выступает eClibc, bash в небольших дистрибутивах подменяется
ash`ем, и так далее. В принципе, при
статической линковке, можно обойтись и без общесистемной
библиотеки вообще, хотя на практике такое встречается крайне
редко, и только в узкоспециализированных
системах.
О дистрибутивах
Base Linux, обеспечивая исходную
функциональность системы, далеко не способен удовлетворить
запросы большинства пользователей. И потому нуждается в
наращивании самыми разнообразными программами - от оконной
системы X и менеджеров окон до редакторов, браузеров,
серверных и офисных приложений, и так далее. Которые, в свою
очередь, связаны зависимостями с самыми разнообразными
библиотеками и иными разделяемыми компонентами. Разрешение
таких зависимостей - задача нетривиальная, и требует
определенной системы. И тут, наконец, мы приходим к
определению дистрибутива Linux. Каковое я сформулировал бы
так:
Дистрибутив Linux - это
система комплектации ядра ОС и комплекса его окружения
утилитами и приложениями.
Система комплектации (коль скоро
речь идет именно о системной целостности) должна включать в
себя все аспекты таковой - получение, установку, обновление и
даже удаление программ, контроль их зависимостей и средства
для разрешения оных, а также средства учета установленных
компонентов. И вот тут мы приходим к первому из главных
критериев классификации дистрибутивов.
Как известно, по сей день
человечество придумало лишь два способа управления программным
обеспечением - сборку их непосредственно из исходных текстов и
установку из прекомпилированных бинарных пакетов. В
соответствие с чем мы и разделяем изобилие дистрибутивов Linux
на два больших класса.
Первый класс - дистрибутивы
пакетные: все их компоненты, от ядра и базовых утилит и до
самого распоследнего пользовательского приложения,
устанавливаются из заранее собранных (прекомпилированных
бинарных) пакетов. Соответственно и распространяются они в
виде прекомпилированных пакетов. А неотъемлемым компонентом
такого дистрибутива будет система пакетного
менеджмента.
За вторым классом закрепилось
название Source Based дистрибутивов. На мой взгляд - не самое
удачное, и по двум причинам. Во-первых, пакетные дистрибутивы
в конечном счете также собираются из исходников (потому что
больше их просто не из чего собирать:-). А главное -
дистрибутивы эти не просто собираются посредством трех
сакральных слов (./configure, make, make install), а собираются по вполне определенным
правилам, обеспечивающим регистрацию установленных компонентов
и удовлетворение их взаимных зависимостей. Набор таких правил
испокон века носит имя системы портов, пришедшее из мира BSD.
И потому второй класс правильнее было бы величать
дистрибутивами портируемыми: какая-либо из портообразных
систем оказывается столь же непременной их составляющей, как
система пакетного менеджмента - для пакетных
дистрибутивов.
В отличие от пакетных
дистрибутивов, дистрибутивы портируемые распространяются
обычно в виде некоего базового прекомпилированного комплекта,
более или менее соответствующего по составу выделенному выше
Base Linux - с той лишь разницей, что тут компилятор и утилиты
для сборки оказываются уже непременной его составляющей. Плюс
- собственно система правил для получения и сборки всех
остальных необходимых приложений. Причем правила эти
распространяются и на компоненты базового комплекта - средства
пересборки его (bootstrapping) практически обязательны для
любого портируемого дистрибутива. Впрочем, некоторые из
портируемых дистрибутивов распространяются преимущественно в
прекомпилированном виде, почему это понятие не тождественно
понятию дистрибутива Source Based (собственно, последние можно
рассматривать как подмножество портируемых
дистрибутивов).
Четкую грань между пакетными и
портируемыми дистрибутивами провести нелегко. С одной стороны,
развитые системы пакетного менеджмента подразумевает
возможность построения пакета непосредственно из исходников,
хотя обычно эта возможность не является "сквозной" (то есть
распространяемой на систему в целом). С другой стороны, ряд
портируемых дистрибутивов распространяется преимущественно в
прекомпилированном виде, а система портирования выступает в
качестве опции. С третьей же - системы пакетного менеджмента
являются столь же неотъемлемой часть портируемых
дистрибутивов, как и дистрибутивов пакетных. Другое дело, что,
как правило, они оказываются вторичными (и производными) от
системы портирования. То есть разделить портируемые и пакетные
дистрибутивы можно по субтрактивному принципу: первые имеют и
систему портов, и систему пакетного менеджмента, тогда как
вторые - только последнюю.
О пакетах и пакетных
дистрибутивах
Возможна ли более дробная
классификация дистрибутивов каждого класса? Возможна, причем
по независимым критериям. Так, для пакетных дистрибутивов
напрашивается разделение по формату пакетов. Которые можно
разделить на две группы - те, что содержат внутри себя
мета-информацию (в частности, информацию о зависимостях
пакетов), и таковой лишенные.
К первой группе относятся широко
распространенные форматы пакетов rpm (Red Hat Packages Manager, характерный для
одноименного дистрибутива и его многочисленных потомков) и
deb
(свойственный дистрибутиву Debian и
на нем основанным). И тот, и другой, помимо собственно архива
бинарных файлов и путей к ним, содержат данные о зависимостях,
хотя и представленные в разной форме (впрочем, детали описания
мета-информации в аспекте классификации не важны).
Пакеты без метаданных - это
обычные тарбаллы, то есть компрессированные tar-архивы типа
*tar.gz/*tar.bz2 (часто фигурирующие в форме tgz и
tbz). Важно, что сами по себе
tgz и tbz - это форматы вовсе не пакета, а именно
архива (то есть определяются используемой утилитой компрессии
- gzip
или bzip2, соответственно). А важно это потому, что
те же самые tgz/tbz архивы могут прекрасно содержать в себе и
мета-информацию, оказываясь более сходными с пакетами
rpm
или deb (и ниже мы столкнемся с примерами этого).
Примеры из Linux-мира мне на ум не приходят, однако
packages
FreeBSD показывают, что ничего
невероятного в этом нет.
Еще более существенно то, что
отсутствие в составе пакета информации о его зависимостях
отнюдь не препятствует контролю над ними: он может
осуществляться за счет внешних баз данных репозиториев пакетов
и локальных баз данных пакетов установленных. А функции
удовлетворения зависимостей в этом случае целиком ложатся на
программы, осуществляющие пакетный менеджмент. И надо
отметить, что управление "чистыми" тарбаллами подчас
оказывается более гибким, чем пакетами с информацией об их
зависимостях.
Программы пакетного менеджмента -
еще один из критериев классификации. Правда, собственно
средства установки пакетов жестко привязаны к их формату - для
установки rpm-пакетов служит одноименная утилита
(rpm), пакеты deb устанавливаются посредством утилиты
dbpkg, для пакетных тарбаллов предусмотрены
собственные средства, в зависимости от их формата (и обычно -
дистрибутив-специфичные, не смотря на похожие, и даже подчас
одинаковые, имена). Конечно, существуют средства взаимной
трансформации пакетов разных форматов (типа rpm2cpio, rpm2tgz
или почти универсальной утилиты alien), однако возможности их
применения ограничены - очевидно, что из rpm-пакета (и тем
более "чистого" тарбалла) получить полноценный
deb-пакет невозможно.
Однако существуют еще и средства
пакетного мета-менеджмента, если так можно выразиться
(собственно, только они-то и заслуживают названия систем
управления пакетами). Наиболее известное и распространенное из
них - apt. Появившийся сначала в Debian`е и
рассчитанный, соответственно, на deb-пакеты, он очень быстро стал
универсальным кросс-пакетным механизмом установки, удаления и
обновления программ, успешно работая с пакетами
rpm
(дистрибутивы Connectiva, Altlinux),
тарбаллами Slackaware (механизм slapt-get). И в принципе не видно препятствий к
прикручиванию его к тарбаллам любого формата - от "чистых" до
сколь угодно насыщенных метаинформацией.
Под явным влиянием
apt возникли и иные системы пакетного
менеджмента - yum, urpmi и так далее. Однако они ориентированы
только на rpm-пакеты (вероятно, их можно использовать и для
иных форматов, но кому это нужно при наличии apt?) и потому не
получили столь широкого распространения, оставаясь
принадлежностью "родительских" дистрибутивов и более-менее
точных их клонов (yum, насколько мне известно, используется
только в Red Hat/Fedora и ASPlinux).
Порты и портируемые
дистрибутивы
Обратимся теперь к дистрибутивам
портируемым. Их также можно разделить на две группы -
дистрибутивы, распространяемые преимущественно в виде
исходников (то есть собственно 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 можно прочитать здесь).
К слову говоря, пакеты Archlinux,
представляющие собой (как и пакеты большинства дистрибутивов
этой группы) "чистые" тарбаллы, являют пример эффективного
контроля зависимостей за счет внешних баз данных - базы
пакетного репозитория (на установочном диске и на сервере
проекта) и базы пакетов, установленных на локальной машине.
Гибкость такого "внешнего" метода пакетного менеджмента
определяется тем, что пользователь может легко создать
собственный пакетный репозиторий в базой данных, в которой
описаны только нужные ему зависимости.
О предназначении
Я столь подробно остановился на
системах пакетного менеджмента потому, что полагаю их
основополагающим критерием классификации дистрибутивов Linux,
вытекающим из самой их природы. Однако и остальные критерии
классификации игнорировать не след. И одним из таких критериев
традиционно выступает назначение дистрибутива. В этом аспекте
обычно выделяется три их группы - дистрибутивы серверные,
десктопные и системы специального (подчас
узкоспециализированного) назначения. Давайте посмотрим,
насколько это обоснованно.
Для начала отметаем различие
между серверными и десктопными системами. Действительно,
Mandrake Linux, со дня своего возникновения позиционируемый
как типичный user-ориентированный дистрибутив, даже в своей
установочной программе имеет опцию - установки в качестве
сервера. С другой стороны, серверные редакции Red Hat или Suse
ничем (технологически) не отличаются от своих младших
десктопных родственников, и вполне могут быть использованы в
качестве последних. Правда, никто, скорее всего, делать этого
не будет - при изобилии существенно более дешевых альтернатив,
однако это уже относится к сфере ценовой
политики...
Конечно, существуют и чисто
серверные разновидности дистрибутивов, просто не содержащие в
комплекте поставки никаких пользовательских приложений, вплоть
до отсутствия оконной системы X. В качестве характерного
примера тут можно упомянуть Altlinux Castle. Однако такие
системы правильнее было бы отнести к разряду
узкоспециализированных.
Так что мы опять-таки приходим к
бинарной классификации - на дистрибутивы общего назначения
(или универсальные) и назначения специального, не так ли? Не
совсем. Потому что специализированные системы, как правило,
самостоятельного значения не имеют. Создаваясь на базе систем
универсальных - за счет сознательного урезания их функций. А
универсальность дистрибутива именно в том и состоит, что из
него можно выкроить и сетевой роутер, и ftp- или http-сервер,
и даже игровую станцию (вспомним game-CD проекта Gentoo) или
некий аналог бытового телевизора (MoviX).
С другой стороны, разделение на
универсальные и специализированные дистрибутивы на практике
имеет некоторое значение. В первую очередь - из-за
расплодившихся в последнее время LiveCD - Linux-систем,
способных не только запуститься, но и функционировать с
компакт-диска, без установки на винчестер. Правда, большинство
из них - производные "нормальных" дистрибутивов: из того же
Gentoo их можно печь, как блины. А самостоятельные разработки
- типа Knoppix`а - играют сугубо демонстративную роль. Если же
они используются как рабочие, то превращаются в самый обычный
Debian (применительно к примеру Knoppix`а).
Тем не менее, разделить
дистрибутивы по назначению можно иначе, именно: дистрибутивы
"для себя" и дистрибутивы "для всех". Первый представляют
собой скорее конструкторские наборы для построения
индивидуальной системы, отличаясь более-менее простыми
инсталляторами слабо развитыми средствами конфигурирования (с
выраженной тенденцией к ручным настройкам). Самый характерный
пример этой группы - Gentoo, вообще не имеющий ни
инсталлятора, ни конфигуратора (точнее, в нем в этом качестве
выступают командная оболочка и текстовый редактор).
Дистрибутивы "для всех" - это
системы, работающие "из коробки", такие, как Red Hat, Suse,
Mandrake. Отличаются красивыми графическими инсталляторами и
средствами сквозного конфигурирования, делающими установку и
настройку легкой и простой. Оборотная сторона чего -
недостаточная гибкость того и другого, а также сложность
глубокой индивидуализации системы: очевидно, что представления
об идеале у всех разные, и попытка создать идеал для всех
приводит к тому, что он не достигается ни для
кого...
Очевидно, что к категории
дистрибутивов "для себя" относятся все системы портируемого
класса, тогда как среди пакетных дистрибутивов преобладают
системы "для всех". Однако в последнем случае исключений не
намного меньше, чем правил. Так, типично пакетный дистрибутив
Slackware, безусловно, нужно отнести к системам "для себя". А
Debian, в зависимости от стратегии инсталляции, может быть
превращен в систему и той, и другой категории.
Говоря о дистрибутивах "для
себя", я отнюдь не подразумеваю их малой распространенности:
так Gentoo за последние годы прочно обосновался среди лидеров
по популярности (а ранее в этом качестве стабильно пребывала
Slackware). И не отрицаю, опять же, что система "для всех"
может быть также весьма индивидуализирована - просто
устройство Red Hat или Mandrake пользователя к тому отнюдь не
подталкивает. А, скажем, Yast из Suse так просто препятствует
"ручному" вмешательству в настройки (видимо, полагая это
разновидностью рукоблудия:-)). С другой стороны, готовые
решения на базе портируемых дистрибутивов часто приближаются
по своим качествам к системам "для всех" - и тут можно
вспомнить CRUX Evolution.
Есть и другой критерий
аналогичного разделения - на дистрибутивы, дружественные к
пользователю, и дистрибутивы, дружественные, по выражению
Клиффорда Вольфа (создателя Rocklinux - одного из первых
Source Based дистрибутивов), к администратору. Причем
последнее отнюдь не предполагает серверной ориентации
дистрибутива: ведь на десктопе каждый пользователь сам себе
root. И, позаботившись о своем удобстве в первом качестве, не
лишним было бы вспомнить и о собственных же интересах - во
втором.
И тут встает вопрос о предмете
общесистемного конфигурирования, что в значительной своей
части сводится к (почти по товарищу Мао) стилям стартовых
сценариев. Конечно, разделение дистрибутивов по этому признаку
на две группы (стиль System V и BSD-подобный стиль) -
объективная реальность, весьма важная для пользователя в
ипостаси администратора (и, тем более, для собственно
администратора). И тут можно наблюдать интересную
закономерность: практически все дистрибутивы "для всех"
придерживаются схемы инициализации в стиле System V, тогда как
среди дистрибутивов "для себя" доминируют вариации на тему
BSD-подобного стиля. Наводит на размышления, не так
ли?
Подведение итогов
Итак, дистрибутивы Linux можно
разделить по двум независимым критериям на две пары частично
перекрывающихся по составу групп. С одной стороны, по способу
комплектации обособляются дистрибутивы пакетные и портируемые,
с другой, по назначению - дистрибутивы "для всех" и "для
себя". Что можно выразить в табличной форме примерно таким
образом (таблица).
Способ
комплектации |
|
Пакетные
дистрибутивы |
Портируемые
дистрибутивы |
Назначение |
"Для всех" |
Red Hat/Fedora, Suse,
Mandrake, Altlinux, ASPlinux, отчасти
Debian |
CRUX
Evolution |
|
"Для себя" |
Slackware, отчасти
Debian |
Rocklinux, Gentoo, CRUX,
Archlinux, Sorcerer, SourceMage,
Lunar |
Примечание: в таблице
перечислены только те дистрибутивы, которые мне довелось
устанавливать и видеть в работающем состоянии.
Можно ли дать более дробную
классификацию дистрибутивов? Как было показано выше, в
принципе можно. Например, по типам пакетов - для первого
класса, по соотношению портируемых и прекомпилированных
компонентов - во втором. Нужно ли? Мне кажется, нет. Потому
что выделенные четыре перекрывающиеся группы дают вполне
достаточное (для пользователя) представление о
потребительских, так сказать, качествах их представителей. А
потом - в конечном счете все дистрибутивы мы поделим всего на
две группы - те, которые нам нравятся, и те, что мы не любим.
Причем каждый сделает это по-своему...