Еще раз про любовь, или что же такое дистрибутивы Linux

Автор: Алексей Федорчук
Февраль 2005 г.

Статья отправлена на свалку истории, как морально устаревшая. Более актуальным является этот материал.

На сочинение этой заметки меня побудила недавняя статья Виктора Костромина Периодическая таблица дистрибутивов Linux”, в которой была сделана попытка разработать классификацию дистрибутивов Linux. Или, скорее, обсудить принципы подхода к такой классификации.

Содержание

• Преамбула
• Пара слов о Base Linux
• О дистрибутивах
• О пакетах и пакетных дистрибутивах
• Порты и портируемые дистрибутивы
• О предназначении
• Подведение итогов

Преамбула

Вообще говоря, попытки классификации дистрибутивов Linux предпринимались неоднократно — наверное, с того момента, как впервые оформились три первых генеральных линии их развития. Однако времена меняются, и дистрибутивы меняются вместе с ними. И та самая, первая, классификация их на линии Slackware, Red Hat, Debian давно уже не отвечает реалиям текущего момента. Применительно в которому Виктор и написал свою статью. Сама по себе ее форма служит предлогом к обсуждению.

Однако сначала — несколько вводных замечаний. Первое касается самого термина дистрибутив (Distributions). Как-то на на одном из форумов возник вопрос об адекватном русском его эквиваленте. И, после обсуждения и обмена мнениями выяснилось, что таковым будет слово дистрибутив:-). Почему? Да потому, что английское 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 неоднократно рассматривалось ранее — последнее по времени изложение этой концепции можно найти здесь. Должен, однако, заметить, что ныне мои представления на сей предмет несколько изменились. И ныне в этот комплекс я включил бы следующие компоненты:

1. ядро Linux (ну еще бы);
2. средства его загрузки (собственно загрузчик и сценарии инициализации) и обеспечения функциональности (то есть утилиты, реализующие поддерживаемые ядром функции — работу с устройствами, файловыми системами, сетевыми протоколами; согласитесь, мало радости пользователю от поддержки ядром некоей файловой системы, если он не располагает инструментами для работы с ней);
3. минимальный набор системных и пользовательских утилит (преимущественно, но не обязательно происходящих из недр проекта GNU) и интегрирующую их командную оболочку;
4. средства обеспечения работы утилит и приложений — общесистемные библиотеки.

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

А вот перечисленные компоненты можно обнаружить в любом дистрибутиве 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, представляющие собой (как и пакеты большинства дистрибутивов этой группы) «чистые» тарбаллы, являют пример эффективного контроля зависимостей за счет внешних баз данных — базы пакетного репозитория (на установочном диске и на сервере проекта) и базы пакетов, установленных на локальной машине. Гибкость такого «внешнего» метода пакетного менеджмента определяется тем, что пользователь может легко создать собственный пакетный репозиторий в базой данных, в которой описаны только нужные ему зависимости.

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

Я столь подробно остановился на системах пакетного менеджмента потому, что полагаю их основополагающим критерием классификации дистрибутивов 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

Примечание: в таблице перечислены только те дистрибутивы, которые мне довелось устанавливать и видеть в работающем состоянии.

Можно ли дать более дробную классификацию дистрибутивов? Как было показано выше, в принципе можно. Например, по типам пакетов — для первого класса, по соотношению портируемых и прекомпилированных компонентов — во втором. Нужно ли? Мне кажется, нет. Потому что выделенные четыре перекрывающиеся группы дают вполне достаточное (для пользователя) представление о потребительских, так сказать, качествах их представителей. А потом — в конечном счете все дистрибутивы мы поделим всего на две группы — те, которые нам нравятся, и те, что мы не любим. Причем каждый сделает это по-своему…