Периодическая таблица дистрибутивов Linux

Оглавление

• 1. Что такое дистрибутив Linux?
• 2. Критерии классификации дистрибутивов
• 3. Признаки несущественные
• 4. Средства управления пакетами ПО
• 5. Сценарии начальной загрузки
• 6. Ориентация дистрибутива на область применения
• 7. Итоговая таблица и заключение

1. Что такое дистрибутив Linux?

Операционная система Linux состоит из многочисленных компонентов, важнейшим из которых является ядро (kernel), сообщество разработчиков которого возглавляет Линус Торвальдс. Но операционная система состоит не только из ядра. Для ее работы необходима еще масса других программных средств: драйверы аппаратных устройств, утилиты управления файловой системой, программы для организации взаимодействия с пользователем и так далее. В отличие от других типов операционных систем (например, Windows, Solaris или HP-UX) отдельные компоненты операционной системы разрабатываются и поддерживаются не какой-то одной фирмой, а независимыми группами разработчиков, которые работают на принципах Open Source и отдают разработанные ими продукты в общественное пользование на условиях Стандартной Общественной Лицензии (General Public License - GPL). Уже к моменту появления ядра Linux значительная часть программных компонент, необходимых для запуска системы, была разработана в рамках проекта GNU, что, собственно, и позволило Торвальдсу в достаточно сжатые сроки создать ОС, которая получила его имя. Можно еще добавить, что кроме операционной системы, для работы пользователя необходимы различные прикладные программы. В случае Linux эти программы в большинстве своем тоже разрабатываются группами энтузиастов "на общественных началах" и распространяются под лицензией GPL.

Поскольку все компоненты Linux-систем распространяются на условиях GPL, может сложиться впечатление, что любой человек может собрать коллекцию свободного ПО и установить Linux на свой компьютер. И какая-то степень правдоподобия в таком утверждении есть. Однако тот, кто задумал осуществить такой проект, должен по крайней мере представлять, какие исполняемые файлы и библиотеки необходимы для того, чтобы успешно запустить систему, а также знать, где должны размещаться системные файлы, как организовать загрузку системы и как правильно ее сконфигурировать. Кроме того, необходимо обеспечить разрешение взаимозависимостей и противоречий между разными пакетами (и версиями пакетов), что является довольно нетривиальной задачей. Самые первые версии Linux, появившиеся в 1991 году, состояли из двух дискет. Первая дискета была загрузочной и содержала ядро, а вторая - корневую файловую систему и основные утилиты, разработанные в рамках проекта GNU. Копии этих дискет можно было загрузить с сервера университета в Хельсинки. Конфигурирование и настройка системы производились вручную и были очень сложными. Поэтому до появления первых дистрибутивов установить Линукс на свой компьютер мог только достаточно подготовленный специалист, можно сказать эксперт в UNIX.

Положение изменилось после появления так называемых дистрибутивов. Дистрибутив Linux отличается от простого набора пакетов программного обеспечения в первую очередь наличием программы инсталляции, которая позволяет рядовому пользователю установить систему на свой компьютер, причем сделать это не привлекая высококвалифицированного эксперта. Если попытаться дать формальное определение дистрибутива, то получится что-то вроде:

Дистрибутив Linux – это набор пакетов программного обеспечения, включающий базовые компоненты операционной систем (в том числе, ядро Linux), некоторую совокупность программных приложений и программу инсталляции, которая позволяет установить на компьютер пользователя операционную систему GNU/Linux и набор прикладных программ, необходимых для конкретного применения системы.

Первые дистрибутивы Linux появились вскоре после того, как Линус Торвальдс выпустил разработанное им ядро Linux под лицензией GPL. Поскольку значительная часть другого необходимого программного обеспечения уже была разработана в рамках проекта GNU, отдельные программисты (и группы программистов) начали разрабатывать как программы инсталляции, так и другие прикладные программы, пользовательский интерфейс, программы управления пакетами и выпускать свои дистрибутивы Linux.

Первый дистрибутив Linux был создан Оуэном Ле Бланк (Owen Le Blanc) в Манчестерском компьютерном центре (Manchester Computing Centre, MCC) в Англии. Первый релиз этого дистрибутива, получившего имя MCC Interim Linux, стал доступен для всех желающих с ftp-сервера Манчестерского университета в феврале 1992 г.

Примерно в то же время сотрудниками университета Техаса был создан дистрибутив TAMU.

В октябре 1992 появился разработанный Питером Мак-Дональдом (Peter McDonald) дистрибутив Softlanding Linux System (SLS), который был первым дистрибутивом, включающим в себя такие элементы, как X Window System и поддержка TCP/IP.

Ни один из этих дистрибутивов не имел хорошей поддержки. В конце 1992 года Патрик Фолькердинк (Patrick Volkerding) выпустил дистрибутив, в значительной части основанный на SLS, который он назвал "Slackware" и который является старейшим дистрибутивом из тех, которые до сих пор активно развиваются.

На основе дистрибутива Slackware германской фирмой S.U.S.E (акроним от немецкого "Software- und System Entwicklung), основанной в 1992 году как консультативная группа по ОС UNIX, был создан дистрибутив SuSE Linux, версия 1.0 которого вышла в 1994 году. Позже SuSE интегрировал дистрибутив Jurix Флориана Ла Роше (Florian La Roche).

Еще один проект по разработке дистрибутива, Debian, был начат Яном Мёрдоком (Ian Murdock) 16 августа 1993 года как альтернатива коммерческим дистрибутивам Linux. Ян хотел создать систему, распространяемую абсолютно свободно и открыто, в духе Linux и GNU. Позже разработка Debian была профинансирована проектом GNU: Free Software Foundation, который выделил деньги на один год, с ноября 1994 по ноябрь 1995, что позволило Я.Мердоку в течение этого периода уделять проекту Debian все свое время.

Дистрибутив Red Hat, который включал в себя некоторые аспекты дистрибутива Bogus (например, механизм пакетов), был основан в 1993 году. На основе Red Hat было создано множество других дистрибутивов, в том числе многие коммерческие дистрибутивы, например, Caldera, Mandrake и TurboLinux.

С тех пор число дистрибутивов постоянно растет, возможно, в силу той относительной легкости, с которой дистрибутив может быть создан из отдельных пакетов, поставляемых независимыми разработчиками. По состоянию на 14 января 2005 года сайт DistroWatch.com (на котором ведется учет разных дистрибутивов) насчитывал 373 дистрибутива. Поддержка некоторых из них уже прекращена, но все же еще более 300 разработок были “живы”. Только за 2004 год появилось более сотни новых дистрибутивов. И это еще не конец, потому что чуть ли не ежедневно появляются новые и новые дистрибутивы!

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

2. Критерии классификации дистрибутивов

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

Поскольку число дистрибутивов Линукс очень велико, ознакомиться на практике с каждым дистрибутивом, чтобы сделать обоснованный выбор, уже не представляется возможным. Следовательно, актуальной становится проблема какой-то классификации дистрибутивов, выделения существенных характеристик, которые могут служить критериями выбора дистрибутива. Достаточно много материалов, дающих хотя бы частичный ответ на поставленные вопросы, можно найти на уже упоминавшемся сайте DistroWatch.com ([1]). Эти материалы и легли в основу настоящей статьи, в которой будет предпринята попытка классификации дистрибутивов Линукс по нескольким критериям.

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

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

• требования к аппаратному обеспечению (некоторые дистрибутивы ориентированы (оптимизированы) на компьютеры класса Pentium, другие устанавливаются и на 486-е; SUSE LiveCD 9.2, например, не запускается на компьютере у которого объем ОЗУ меньше 256 МБайт),

• используемая графическая оболочка (например, KDE, GNOME или XFce),
• наличие средств локализации, обеспечивающих поддержку необходимых вам языков (например, в некоторых LiveCD дистрибутивах не предусмотрена поддержка русского языка, так что русскоязычным пользователям придется приложить дополнительные усилия для русификации системы),

• носитель, с которого может запускаться система (например, одна или несколько дискет, CD, только установка на жесткий диск),

• организация процедуры начальной загрузки системы (BSD или System V),

• используемая система управления пакетами (например, dpkg в Debian, RPM в Fedora Core),

• структура каталогов файловой системы (см. [5,6]),
• родословная или история проихождения дистрибутива ( Новые дистрибутивы создаются, в основном, не на пустом месте, а на основе одного из уже существующих дистрибутивов.)

• состав базового устанавливаемого ПО (см. [7]),

• доступность дополнительных пакетов,

• наличие и состав коммерческих программ, включенных в дистрибутив,

• процедура определения аппаратуры,

• предоставляемые инструменты управления системой,

• и так далее ...

Давайте попытаемся выделить из этого списка те признаки, которые могут служить основой для какой-то классификации дистрибутивов. Начнем с того, что отбросим некоторые критерии, не имеющие практического значения.

3. Признаки несущественные

Некоторые из перечисленных признаков можно исключить без долгих обоснований. Например, доступность дополнительных пакетов практически одинакова для всех дистрибутивов, поскольку любую программу можно скомпилировать из исходных кодов или же создать пакет в специфичном для данного дистрибутива формате. Точно по тем же основаниям можно исключить признак наличия в составе дистрибутива коммерческого ПО, так как никто не может запретить вам купить такое ПО и добавить его в свою систему. Средства локализации включаются сейчас во все дистрибутивы без исключения, разве что не всегда дистрибутив содержит нужные шрифты. Этот признак становится еще более несущественным в связи с наметившимся переходом на Unicode. Еще несколько признаков давайте рассмотрим чуть подробнее.

Структура файловой системы

А.Федорчук в статьях [5,6] предлагал использовать в качестве одного из критериев классификации дистрибутивов структуру каталогов файловой системы. Вероятно, это отличие было существенно в то время, когда была написана статья [5]. В последнее же время набирет ход процесс разработки стандартов для Линукс. В рамках организации Linux Standard Base, ставящей своей целью наладить взаимодействие между разными дистрибутивами и разработать общие стандарты на те или иные компоненты системы (а точнее, даже чуть раньше возникновения этой организации), был разработан стандарт на структуру каталогов файловой системы (Filesystem Hierarchy Standard - FHS). Следование требованиям стандарта существенно упрощает жизнь создателям программных приложений, потому что обеспечивает нахождение необходимых для приложения компонент программного обеспечения (в частности, библиотек) в известных и строго определенных местах. Поэтому структура каталогов приняла примерно одинаковый вид во всех основных дистрибутивах. Дистрибутив SuSE, например, когда-то упрекали за неполное соответствие стандарту FHS, но в версии 9.2 он уже полностью соответствует версии 2.3 этого стандарта. Даже если фактическая структура каталогов отличается от стандартной, добиться соответствия можно путем использования символических ссылок. Так что выделить по признаку различия структуры файловой системы какие-то четко очерченные группы дистрибутивов не представляется возможным.

Используемая графическая оболочка

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

Родословная дистрибутива

Большая часть современных дистрибутивов ведет свою родословную либо от Red Hat, либо от Debian. Но происхождение дистрибутива, то есть выяснение того, от какого из ранее существовавших дистрибутивов он отпочковался, представляет, на мой взгляд, чисто исторический интерес. Любой новый дистибутив со временем отдаляется от своего прародителя и может мигрировать как в сторону другого дистрибутива, так и стать основателем какой-то совершенно новой ветви в "дистрибутивостроении". Такие дистрибутивы, например, как Mandrake, Conectiva или PLD, произошли, как известно, от Red Hat, но сейчас уже представляют собой вполне самостоятельные разработки. Более того, существуют уже другие дистрибутивы, являющиеся производными от названных. Так что, хотя происхождение и может в какой-то степени характеризовать дистрибутив для опытных пользователей, все же служить критерием классификации оно не может. Если вас интересует какие дистрибутивы от каких произошли, то на DistroWatch имеется страничка, на которой эти данные приведены.

Процедура определения аппаратуры

Судя по отзывам в разных источниках, средства определения аппаратного обеспечения компьютера в разных дистрибутивах различаются довольно существенно. Широко известно, что дистрибутив Knoppix отличается в этом смысле в лучшую сторону. Однако, я полагаю, что преимущество это временное. В силу открытости всего программного обеспечения Линукс достижения и наработки одного из разработчиков быстро становятся достоянием всех, а поэтому идеи, найденные Клаусом Кноппером, вскорости будут реализованы и в других дистрибутивах. Именно этот свободный обмен идеями и позволяет быстро развиваться свободному софту вообще.

Состав базового устанавливаемого ПО

Инструменты управления системой

Носитель, с которого запускается система

Среди тех сотен дистрибутивов, которые существуют в настоящее время, имеются как дистрибутивы, устанавливающиеся на жесткий диск и запускающиеся с него, так и дистрибутивы, которые не требуют установки на жесткий диск. В качестве носителя системы может выступать CD-ROM, USB pendrive, дискета или несколько дискет и даже виртуальный диск, созданный в оперативной памяти компьютера. Однако классифицировать дистрибутивы по этому признаку вряд ли целесообразно. В конце концов, мы пытаемся построить классификацию для того, чтобы облегчить выбор дистрибутива для того или иного применения. И не важно, откуда мы систему запустим, важно то, какую задачу система будет выполнять. Ведь ни один дистрибутив не создается с целью просто запустить систему. Даже дистрибутивы на дискетах создаются для запуска системы в качестве маршрутизатора, файервола, для использования компьютера, на котором такая система, в качестве удаленного терминала или станции для выхода в Интернет.

Требования к аппаратуре

Что касается требований к аппаратному обеспечению компьютера, на котором будет запускаться система, то этот признак, на мой взгляд, сливается с признаком назначения дистрибутива. Просто среди сфер применения дистрибутива нужно завести отдельную категорию - дистрибутивы для "слабых" компьютеров. В эту категорию частично войдут и те дистрибутивы, которые запускаются с дискет, если у них нет другого предназначения.

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

4. Средства управления пакетами ПО

Как было сказано в приведенном выше определении, дистрибутивы состоят из отдельных пакетов, каждый из которых содержит какое-то приложение, утилиту или сервис. Отдельный пакет может содержать, например, веб-браузер, библиотеку для работы с графическими файлами в формате PNG, набор шрифтов и так далее.

Программное обеспечение, содержащееся в пакете, поставляется в одном из двух основных видов:

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

Существуют также пакеты, которые можно при желании отнести как к первому, так и ко второму виду. Это пакеты, которые содержат скрипты и конфигурационные файлы, страницы руководств в формате man/info, информацию о копирайтах и другую документацию. С одной стороны, они представляют собой такие же "исходные тексты", с другой - устанавливаются в систему без всякой дополнительной обработки, как и исполняемые файлы. Но этот тип пакетов играет вспомогательную роль и для нас какого-либо интереса не представляет. А вот количество и состав пакетов первых двух типов играет в классификации дистрибутивов самую существенную роль.

Вспомним, во-первых, что все программное обеспечение в Linux является открытым, то есть поставляется вместе с исходными кодами. И поэтому для каждого бинарного пакета на дистрибутивных дисках найдется соответствующий ему пакет с исходными кодами. А вот обратное утверждение уже не имеет места, так как существуют дистрибутивы, в которых число бинарных пакетов сильно ограничено. Это так называемые "Source-based" дистрибутивы, то есть дистрибутивы, основанные на исходных кодах. Их создатели предполагают, что пользователь такого дистрибутива может самостоятельно скомпилировать и установить в систему любое нужное ему приложение. Но ведь для того, чтобы запустить процесс компиляции, система в какой-то минимальной конфигурации уже должна работать. Должны быть установлены загрузчик, ядро, архиваторы tar и gzip (чтобы развернуть пакет с исходниками), компилятор со всем сопутствующим инструментарием (линкером, ассемблером и т.д.), библиотеки функций языка Си, утилиты для работы с файлами и текстами (find, grep, awk, sed), без которых сборка и установка программ просто невозможна. Эта проблема решается двумя способами: либо компиляция проходит на какой-то другой системе, либо необходимый минимум прекомпилированных пакетов устанавливается из дистрибутива, а остальные компилируются уже в полученной таким образом среде. Самый яркий пример реализации подхода, основанного на компиляции всей системы из исходных кодов - проект Linux From Scratch, который не является дистрибутивом в прямом смысле этого слова, а представляет собой набор инструкций по созданию системы из набора пакетов с исходными кодами (см. [10]).

Что же касается пакетов с прекомпилированным программным обеспечением, то для установки как в поцессе инсталляции, так и в уже установленой системе требуются специальные средства управления пакетами. Дело в том, что установка программного обеспечения из пакетов обычно связана с разрешением так называемых "зависимостей". Например, пакет, содержащий компилятор GNU C (gcc) "зависит" от пакета binutils, который включает в себя компоновщик и транслятор. Если пользователь попытается установить gcc без предварительной установки binutils, процесс установки пакета с GCC скорее всего завершится сообщением об ошибке. Поэтому в состав пакета обычно включается не только бинарный код исполняемой программы, но еще и некая служебная или мета-информация: название программы, данные о разработчике, информация о других пакетах, которые необходимы для того, чтобы данное ПО корректно работало (чаще всего это необходимые данному приложению библиотеки), контрольные суммы, информация о том, как правильно сконфигурировать пакет, и как его корректно удалить, если необходимость в его использовании отпала.

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

Система управления пакетами - это набор инструментов, предназначенных для автоматизации процессов установки, обновления, конфигурирования и удаления пакетов программного обеспечения определенного формата.

Наиболее известными (или распространенными) системами управления пакетами являются:

• RPM/YUM — менеджер пакетов Red Hat. Сейчас аббревиатура RPM расшифровывается обычно рекурсивно (RPM = RPM Package Manager), но первоначально ее расшифровывали как менеджер пакетов Red Hat (Red Hat Package Manager), поскольку разработана она была для дистрибутива Red Hat. В настоящее время она используется и во многих других дистрибутивах.
• dpkg/APT — система управления пакетами *.deb дистрибутива Debian, тоже портированная в настоящее время в другие дистрибутивы. Пакеты .deb представляют собой просто два tar-архива, сжатых с помощью gzip: в одном архиве содержится управляющая информация, в другом - данные. Стандартным средством управления такими пакетами является консольная программа dpkg, дополненная оболочкой APT (Advanced Packaging Tool).
• tgz или tar.gz — стандартный набор из двух программ tar + gzip, иногда дополненный некоторыми дополнительными управляющими файлами. Используется в дистрибутиве Slackware и некоторых других, не обеспечивает разрешения зависимостей. От Source-based дистрибутивов эта система отличается тем, что внутри tar.gz-архивов находятся заранее скомпилированные программы.
• система портежей дистрибутива Gentoo, которая представляет собой набор файлов ebuild, содержащих информацию о том, как получить (из любых доуступных источников - сети, локального диска и т.д.), скомпилировать и установить пакет в системе Gentoo, используя консольную команду emerge. Обычно пакет ПО в этом случае содержит исходные коды программ, и приложение компилируется прямо в процессе инсталляции, за счет чего оптимизируется для конкретной машины. Хотя этим способом могут устанавливаться и заранее откомпилированные программы, но такой вариант используется только в исключительных случаях, например, при инсталляции системы на очень медленные машины.
• YaST - утилита, разработанная Novell и используемая в дистрибутиве SuSE.

Компиляцию пакетов из исходных кодов тоже можно рассматривать как один из вариантов системы управления пакетами. От перечисленных выше систем он отличается только тем, что пакеты ПО в source-based дистрибутивах почти не содержат в своем составе заранее скомпилированных программ (кроме тех, которые абсолютно необходимы, типа ядра и компилятора), так что единственный способ установки нового пакета заключается в непосредственой компиляции его из исходных кодов.

Наиболее распространенным средством управления пакетами программного обеспечения остается программа RPM. Правда, она обладает тем недостатком, что задача разрешения зависимостей ложится в основном на плечи пользователя. Программа RPM только сообщает, что таких-то пакетов в системе не достает, а их поиск и установку пользователь должен выполнить самостоятельно. Поэтому многие основанные на RPM дистрибутивы сейчас используют также заимствованный из Debian инструмент APT, который появляется иногда и под другими именами. Дебиановский DEB и TGZ из Slackware (и его производные) тоже распространены достаточно широко. Кроме названных были изобретены еще несколько средств управления пакетами. Примерами могут служить SLP из дистрибутива Stampede, который имеет несколько интересных особенностей, и система управления пакетами дистрибутива JBLinux.

Таблица 1, заимствованная с сайта DistroWatch.com, показывает распространенность различных систем управления пакетами. Имейте в виду, что в отличие от аналогичной таблицы на DistroWatch, я не ставил задачу перечислить в правом столбце таблицы все дистрибутивы, использующие тот или иной способ управления пакетами, а привел только по несколько примеров.

Таблица 1.

Нужно сказать, что провести четкую границу между разными системами управления пакетами иногда довольно затруднительно. Кроме того, существует программа Alien, которая позволяет конвертировать пакеты одной системы в пакеты другой. Если вы хотите использовать пакет из дистрибутива, отличного от установленного на вашем компьютере, вы можете воспользоваться этой программой для конвертации этого пакета в формат, используемый вашей системой, после чего сможете его установить.

5. Сценарии начальной загрузки

Для начала давайте вспомним, что существует два разных стиля начальной загрузки операционной системы типа UNIX, происхождение которых уходит корями в историю развития UNIX-систем: так называемый стиль BSD (используемый также в таких системах как FreeBSD, NetBSD и OpenBSD), и стиль System V (или стиль ATT). Различие между ними проявляется в организации и размещении стартовых сценариев (скриптов), обеспечивающих управление процессами загрузки системы. В классических BSD-системах эти файлы хранятся в каталоге /etc и их имена начинаются с префикса "rc". В системах семейства System V файлы сценариев располагаются в каталоге /etc/init.d, а ссылки на них созданы в каталогах /etc/rc0.d, /etc/rc1.d и т.д. Второй вариант организации является более четким и позволяет аккуратнее выполнять останов системы. Если вы хотите подробнее узнать о различиях в двух названных стилях загрузки, прочитайте главу 2 книги [6].

Большая часть дистрибутивов Linux использует стиль System V. К этому классу относятся Debian, все клоны Red Hat, включая Mandrake и российские дистрибутивы ASPlinux и ALT Linux. В стиле BSD организована загрузка в дистрибутиве Slackware и его производных. Однако тот или иной стиль сценариев начальной загрузки выдерживается не очень четко. К примеру, структура каталогов, в которых хранятся инициализационные скрипты, в основных дистрибутивах существенно различается:

Листинг 1.

/etc/init.d/-----символьная ссылка на /etc/rc.d/init.d/
/etc/rc.d/------скрипты rc, rc.sysinit и rc.local
         |
         /init.d/-----множество файлов-скриптов
         /rc0.d/-----символьные ссылки @K*.* и @S*.*
         /rc1.d/-----символьные ссылки @K*.* и @S*.*
         ...........
         /rc6.d/-----символьные ссылки @K*.* и @S*.*
         /rcS.d/-----символьные ссылки @K*.* и @S*.*

/etc/init.d/-----скрипты rc, rcS, reboot и множество других,
/etc/rc0.d/-----символьные ссылки @K*.* и @S*.*
    /rc1.d/-----символьные ссылки @K*.* и @S*.*
     ...........
    /rc6.d/-----символьные ссылки @K*.* и @S*.*
    /rcS.d/-----символьные ссылки @K*.* и @S*.*

/etc/rc.d/--скрипты rc.0, rc.4, rc.6, rc.K, rc.M, rc.S, rc.local, 
	rc.syslog, rc.nfsd, rc.sysvinit, rc.netdevice, rc.keymap 
	и другие скрипты, имена которых имеют вид rc.*.

/etc/init.d/--скрипты с самыми разными именами.

/etc/rc.d/------символьная ссылка на /etc/init.d/
/etc/init.d/----множество файлов с разными именами, в частности boot.*
           /boot.d/----символьные ссылки @K*.* и @S*.* 
           /rc0.d/-----символьные ссылки @K*.* и @S*.*
           /rc1.d/-----символьные ссылки @K*.* и @S*.*
           ...........
           /rc6.d/-----символьные ссылки @K*.* и @S*.*
           /rcS.d/-----символьные ссылки @K*.* и @S*.*

Как видите, даже в Red Hat и Debian, которые следуют стилю System V, структура каталогов несколько отличается. А SuSE, хотя и происходит от Slackware, движется в сторону стиля System V, по крайней мере в организации структуры каталогов. А вот Red Hat, наоборот, завел скрипт rc.local, напоминающий одноименный сценарий во FreeBSD. В процессе загрузки он выполняется последним. Правда, в последних версиях Red Hat и Fedora Core этот скрипт "пустой", то есть практически не используется. И авторы книги [6] не советуют добавлять в него собственные команды, рекомендуя лучше воспользоваться средствами System V.

Но структура каталогов и названия инициализационных скриптов, может быть, и не самое главное. Как известно, в процессе начальной загрузки системы вначале загружается ядро, которое запускает процесс init, всегда имеющий идентификатор 0. Процесс init выполняет инструкции, заданные в файле /etc/inittab. В листинге 2 приведены выдержки из файла /etc/inittab для нескольких дистрибутивов. Приводится не полный текст файла /etc/inittab, а только по 4 группы самых важных строк, определяющих процесс загрузки. Во всех дистрибутивах кроме приведенных инструкций определяются еще действия по комбинации клавиш <Ctrl>+<Alt>+<Del> и выполняется запуск виртуальных терминалов (только в Fedora Core и SuSE для этого вызываются процессы mingetty, в Gentoo и Slackware - agetty, в Knoppix - /bin/bash -login).

Листинг 2.

id:3:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

x:5:respawn:/etc/X11/prefdm -nodaemon

id:5:initdefault:

# Boot-time system configuration/initialization script.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:respawn:/bin/bash -login >/dev/tty1 2>&1 </dev/tty1

l0:0:wait:/etc/init.d/knoppix-halt
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/knoppix-reboot

# Run X Window session from CDROM in runlevel 5
w5:5:wait:/bin/sleep 2
x5:5:wait:/etc/init.d/xsession start

id:3:initdefault:

# System initialization (runs when system boots).
si:S:sysinit:/etc/rc.d/rc.S

su:1S:wait:/etc/rc.d/rc.K
rc:2345:wait:/etc/rc.d/rc.M
l0:0:wait:/etc/rc.d/rc.0
l6:6:wait:/etc/rc.d/rc.6

# Runlevel 4 used to be for an X window only system
x1:4:wait:/etc/rc.d/rc.4

id:3:initdefault:

# System initialization (runs when system boots).
si:S:sysinit:/sbin/rc boot

~~:S:wait:/sbin/sulogin
l0:0:wait:/sbin/rc shutdown 
l1:1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot
z6:6:respawn:/sbin/sulogin

# Used by /etc/init.d/xdm to control DM startup.
x:a:once:/etc/X11/startDM.sh

# The default runlevel is defined here
id:5:initdefault:

# First script to be executed, if not booting in emergency (-b) mode
si::bootwait:/etc/init.d/boot

# /etc/init.d/rc takes care of runlevel handling
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
#l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

# what to do in single-user mode
ls:S:wait:/etc/init.d/rc S
~~:S:respawn:/sbin/sulogin

Как видите, во всех случаях порядок действий примерно одинаков:

• Вначале задается уровень выполнения (runlevel).
• Затем выполняются действия начальной инициализации системы, не зависящие от заданного уровня. В разных дистрибутивах для этого вызываются разные скрипты:
  • в Fedora Core - /etc/rc.d/rc.sysinit
  • в Knoppix - /etc/init.d/rcS
  • в Slackware - /etc/rc.d/rc.S (то есть скрипт перехода в Single User mode):
  • в Gentoo - /sbin/rc boot
  • в SuSe - /etc/init.d/boot
• Затем выполняется скрипт перехода на заданный уровень выполнения. При этом, если в Fedora Core и Gentoo для каждого уровня выполнения задана своя строка, то в Slackware для уровней со 2-го по 5-ый выполняются одни и те же действия.
• Наконец, во всех дистрибутивах, кроме SuSE, отдельная строка задает процедуры запуска графической оболочки.

При использовании стиля System V используется один и тот же скрипт перехода на заданный уровень, а то, что он делает, определяется содержимым каталога /etc/rc.d/rcN.d. Этот каталог содержит перечень ссылок на скрипты запуска тех системных сервисов, которые должны работать на уровне N. Сами скрипты размещаются в каталоге /etc/init.d или /etc/rc.d/init.d.

В отличие от стиля System V в BSD-стиле каждому уровню загрузки соответствует свой сценарий. И сначала всегда происходит переход на уровень S (однопользовательский), а затем уже переход на заданный уровень. Стиль BSD в наиболее чистом виде (из рассматриваемых примеров) представлен в дистрибутиве Slackware.

Поскольку стиль System V взят за основу при создании стандарта LSB (Linux Standart Base), дистрибутивы, ранее использовавшие стиль BSD, в последнее время заботятся о совместимости с System V. Slackware обеспечивает такую совместимость начиная с версии 7.0. Достигается это путем использования сценария rc.sysinit, который производит поиск всех сценариев стиля System V в каталоге /etc/rc.d и выполнит их, если уровень загрузки соответствующий. Это полезно, если вы пользуетесь коммерческим программным обеспечением, которое ориентируется на стиль System V. В то же время, вы можете пользоваться и BSD сценариями.

Ориентация дистрибутива на область применения

Таблица 2.

Замечу, что на сайте Linux Weekly News приведена гораздо более полная таблица, классифицирующая дистрибутивы по их назначению (см. [3]).

7. Итоговая таблица и заключение

Подытоживая вышеизложенное, можно констатировать, что существует три существенных критерия классификации дистрибутивов Linux: