Linux: Еще раз про любовь, или что же такое дистрибутивы Linux.
Автор: Алексей Федорчук, февраль 2005 г.
На сочинение этой заметки меня побудила недавняя статья Виктора Костромина “Периодическая таблица дистрибутивов 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
Примечание: в таблице перечислены только те дистрибутивы, которые мне довелось устанавливать и видеть в работающем состоянии.
Можно ли дать более дробную классификацию дистрибутивов? Как было показано выше, в принципе можно. Например, по типам пакетов - для первого класса, по соотношению портируемых и прекомпилированных компонентов - во втором. Нужно ли? Мне кажется, нет. Потому что выделенные четыре перекрывающиеся группы дают вполне достаточное (для пользователя) представление о потребительских, так сказать, качествах их представителей. А потом - в конечном счете все дистрибутивы мы поделим всего на две группы - те, которые нам нравятся, и те, что мы не любим. Причем каждый сделает это по-своему...
