Команда                                                             краткое описание

whoami                              Сообщает имя, с которым вы вошли в систему в    данном сеансе работы

 

w или who                        Сообщает, какие пользователи работают в данный момент в системе

 

pwd                                   Сообщает имя текущего каталога

 

Is -1                                   Выдает список файлов и подкаталогов текущего каталога

 

cd <имя_каталога>         Осуществляет смену текущего каталога

 

ps ax                                  Выдает список выполняющихся процессов

 

Просмотрите описания этих команд с помощью команды man.

Консоль, виртуальные терминалы и оболочка. Итак, вы приобрели первый опыт работы в текстовом, или "консольном", режиме системы Linux. Понятия "терминала" и "консоли", которые встретятся нам еще не раз, требуется, вероятно, дополнительно пояснить.

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

У мейнфреймов имелся особый терминал, который предназначался для системного администратора и назывался консолью. Консоль обычно подсоединялась к компьютеру не по последовательному интерфейсу, а через отдельные разъемы (иногда в качестве устройства вывода в ее состав вместо монитора входило печатающее устройство).

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

Но, кроме консоли, Linux позволяет подключать к компьютеру и удаленные терминалы и, более того, обеспечивает возможность работы с несколькими виртуальными терминалами с одной консоли. Нажмите комбинацию клавиш <Ctrl>+<Alt>+<F2>. вы снова увидите приглашение login:. Однако это не возврат к началу работы с системой — вы просто переключились в другой виртуальный терминал. Здесь вы можете зарегистрироваться под другим именем. Попробуйте войти в систему под именем только что заведенного пользователя. После этого нажмите комбинацию клавиш <Ctrl>+<AltXFl>. Вы вернетесь к первому экрану. По умолчанию Red Hat Linux открывает при запуске 6 параллельных сеансов работы (виртуальных терминалов), и этим иногда очень удобно пользоваться. Для переключения между виртуальными терминалами используются комбинации клавиш <Ctrl>+<Alt>+<Fl>—<Ctrl>+<Alt>+<F6>. (Замечу, что при работе в текстовом режиме тот же результат можно получить, используя комбинации <Alt>+<Fl>—<Alt>+<F6>, однако в графическом режиме без клавиши <Ctii> не обойтись, так что лучше сразу привыкать к комбинациям из 3-х

клавиш). Кстати, если в процессе работы вы забыли, в каком терминале находитесь в данный момент, воспользуйтесь командой tty, которая выводит имя терминала в следующем формате: /dev/tty2.

Сразу же скажем, что, если вы хотите завершить сеанс работы с системой в одном из терминалов, вы можете сделать это нажатием комбинации клавиш <Ctrl>+<D>. Это не приведет ни к остановке работы компьютера, ни к перезагрузке системы. Не забывайте, что Linux — многозадачная и многопользовательская система. Завершение работы одного пользователя не означает, что надо выключать компьютер. Просто завершается сеанс работы одного из пользователей, и система снова выводит в данном терминале приглашение, которое вы уже видели. Можно завершить сеанс работы и введя одну из Команд logout ИЛИ exit.

Зная теперь как открыть и закрыть сеанс работы в системе, выполните приведенные выше рекомендации, т. е. заведите себя как рядового пользователя (без суперпользовательских прав), завершите все сеансы работы, открытые от имени root, и снова войдите в систему под своим новым именем.

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

дит приглашение", это неправильно, поскольку приглашение выводит именно оболочка, жидая ввода пользователем очередной команды. Каждый раз, когда очередной пользователь входит в систему, команда login запускает для него командный процессор — оболочку. Если вы легировались со второго терминала под именем пользователя j im (или под другим выбранным вами именем), то обратите теперь внимание на различие в приглашениях у пользо-

вателей root и j im. У пользователя root приглашение оканчивается символом #, а у всех остальных пользователей — символом $.

Оболочку может запускать не только команда login. Вы можете просто ввести команду bash (именно так называется программа-оболочка в системе Red Hat Linux) и тем самым запустить новый экземпляр оболочки. Выходя из него (по команде exit или по комбинации клавиш <Ctrl>+<D>), вы вернетесь к предыдущему экземпляру оболочки.

Оболочка bash является не только командным процессором, но и мощным языком программирования. В ней имеется целый ряд встроенных (внутренних) команд и операторов, а, кроме того, в качестве команды может использоваться любая программа, хранящаяся в виде файла на диске. Список встроенных команд можно получить по команде help. Попробуйте! Детальную информацию по конкретной встроенной команде выдает та же команда help с указанием в качестве параметра имени встроенной команды, например: help cd.

Поскольку оболочка играет очень важную роль в Linux, ей будет посвящена отдельная глава этой книги. Впрочем, аналогичный материал вы найдете в любой книге по UNIX. Стоит только отметить, что для UNIX-подобных систем разработано несколько альтернативных bash оболочек. Их можно использовать и в Linux, но по умолчанию запускается именно bash.

Рассмотрим теперь еще одну команду, которую вам необходимо знать, поскольку все же компьютер у вас персональный (неважно, дома ли он стоит, или на работе). А это значит, что вы и есть суперпользователь данного компьютера. Но, как уже было сказано выше, входить в систему под именем суперпользователя не рекомендуется, поскольку любое неосторожное действие суперпользователя может привести к нежелательным последствиям. Входя под именем простого пользователя, вы, по крайней мере, не можете по неосторожности удалить или испортить системные файлы. В то же время, имеется ряд действий (например, монтирование файловых систем), выполнить которые может только суперпользователь. Не перезагружать же каждый раз компьютер! Именно в таких ситуациях выручает команда su. Достаточно ввести команду su и текущая оболочка (так и хочется сказать "система") запустит для вас новый экземпляр оболочки, в который вы попадете уже с правами пользователя root. Естественно, что для этого вам придется (в ответ на соответствующий запрос) ввести пароль этого пользователя. Закончив выполнять администраторские действия, выйдите из оболочки, и вы снова станете непривилегированным пользователем с отведенными ему полномочиями.

Если вы вошли в систему под именем root, то вы можете аналогичным образом запустить новый экземпляр оболочки от имени любого пользователя, пароль которого вы знаете. Но для этого надо указать имя этого пользователя в командной строке, например:

 

[user]$ su jim

 

Когда мы вводим su без указания имени, по умолчанию подставляется имя суперпользователя root.

Но в ОС Linux есть еще одна возможность временно переключаться в бюджет пользователя root для выполнения административных функций. Вспомните, что Linux — это многопользовательская система, в ней одновременно могут работать несколько пользователей. Поэтому в первом виртуальном терминале можно войти под именем root, а в любом другом терминале — под именем простого пользователя. Основную работу вы можете выполнять как простой пользователь, а когда потребуется выполнить административные функции, вы "зовете системного администратора". Для этого достаточно нажать <Ctrl>+<Alt>+<Fl> — и системный администратор уже тут. По завершении операции, которую может выполнить только суперпользователь, вы немедленно должны вернуться в бюджет простого пользователя. В таком случае вы не рискуете нарушить что-либо в системе, пока еще не набрались необходимого опыта.

 

Т е м а 4.6 Дистрибутивы Linux

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

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

В последнее время дистрибутивы разрослись до сотен мегабайт, и скачивать их из Internet становится дороже, чем просто приобрести на CD-ROM. В сущности, дистрибутивы на CD-ROM бывают двух видов - часть ftp-архива какого-нибудь сервера или специально подготовленный дистрибутив, покупая который вы заодно получаете техническую поддержку.

Список FTP-сайтов, содержащих дистрибутивы Linux приведены в таблице 1.

 

Таблица 1. FTP-сайты, содержащие дистрибутивы Linux Имя IP-адрес   tsx-11.mit.edu 18.172.1.2 /pub/Linux sunsite.unc.edu 152.2.22.81 /pub/Linux ftp.funet.fi 128.214.248.6 /pub/Linux net.tamu.edu 128.194.177.1 /pub/Linux ftp.mcc.ac.uk 130.88.203.12 /pub/Linux src.doc.ic.ac.uk 146.169.2.1 /packages/Linux fgb1.fgb.mw.tu-muenchen.de 129.187.200.1 /pub/Linux ftp.informatik.tu-muenchen.de 131.159.0.110 /pub/comp/os/Linux ftp.dfv.rwth-aachen.de 137.226.4.111 /pub/Linux ftp.informatik.rwth-aachen.de 137.226.225.3 /pub/Linux

 

На данный момент существует несколько десятков специально созданных дистрибутивов Linux, в том числе и специальные русифицированные версии. Рассмотрим несколько самых популярных вариантов пакетов Linux.

Пожалуй, самым популярным дистрибутивом на данный момент является небезызвестный RedHat. В него входят как программы необходимые для сервера под управлением Linux, так и для домашнего использования. RedHat 6.0 поставляется с двумя графическими средами - GNOME и KDE. Данный пакет рекомендуется и специалистам в области UNIX, и новичкам.

Русифицированным вариантом RedHat является дистрибутив Black Cat. Он создается участниками Донбасской группы пользователей Linux, которые не только локализуют дистрибутив RedHat, но и пишут множество специальных патчей, которые входят позже (после выхода очередной версии Black Cat) в реализацию RedHat. Разработчики ставят своей целью объединение в данном дистрибутиве как программ для администрирования сетей Intranet/Internet, так и для создания мощной мультимедийной рабочей системы. Особенное внимание уделяется применению русского и украинского языка Linux. Дистрибутивы RedHat и Black Cat считаются наилучшим выбором как для профессионалов, так и для новичков, поэтому именно их можно порекомендовать для установки.

К числу русифицированных вариантов RedHat можно отнести дистрибутивы Русский Linux "Красная Шапочка", "Открытое Ядро" и KSI Linux.

Еще одним дистрибутивом, основанным на RedHat, является Mandrake Linux компании Mandrakesoft и его русская версия Mandrake Linux Russian Edition, подготовленная фирмой IPLabs. Цель создания данного дистрибутива - сделать доступной Linux для новичков и непрофессионалов, что достигается простотой его установки и настройки.

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

Одним из первых и самых простых на данный момент дистрибутивов Linux является Slackware Linux. Несмотря на некоторые сложности с настройками, этот дистрибутив лучше всего подходит для того, чтобы разобраться с внутренним строением Linux.

Рабочий стол под управлением GNOME и диспетчера окон Enlightenment.

 

SuSe Linux является одним из самых популярных дистрибутивов Linux в Европе. Он разрабатывался в Германии, поэтому его родной язык - немецкий. Но были сделаны переводы и на другие языки, в том числе и на русский (компанией IPLabs). Фирма SuSe специализируется на разработке X-серверов для графической системы Linux XFree386, поэтому в данном дистрибутиве новые драйвера для видеокарт появляются раньше, чем в других. Помимо этого в дистрибутив входит несколько диспетчеров окон и KDE. SuSe Linux подходит как новичкам, так и профессионалам, однако основной упор делается на профессионалов - программистов и администраторов.

Более подробную и полную информацию об имеющихся дистрибутивах можно найти на сервере www.step.kosnet.ru. Сайты фирм и магазинов, в которых можно приобрести дистрибутивы Linux, приведены в таблице 2.

 

http://posix.ru/distro/whatis_distro/

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

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

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

А вот перечисленные компоненты можно обнаружить в любом дистрибутиве Linux, однако состав их может различаться. Конечно, ядро Linux будет безальтернативно присутствовать всегда - иначе это был бы не Linux, а другая операционная система. Да и утилиты поддержки будут одни и те же - очевидно, что для обеспечения работы с файловой системой Ext2fs (для примера) потребуется соответствующий пакет (e2fsprogs). Однако дальше возможны варианты: конечно, на практике во всех дистрибутивах Linux в качестве общесистемной командной оболочки используется bash, а в роли общесистемной библиотеки выступает glibc. Однако теоретически никто не мешает заменить первую любым POSIX-совместимым шеллом, а вторую - каким-либо аналогом, и реально такие случаи известны. Например, в Linux для встроенных систем в качестве главной Си-библиотеки выступает uClibc, bash в небольших дистрибутивах подменяется ash'ем, и так далее. В принципе, при статической линковке, можно обойтись и без общесистемной библиотеки вообще, хотя на практике такое встречается крайне редко, и только в узкоспециализированных системах.

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

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

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

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

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

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

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

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

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

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

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

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

Надо добавить, что в некоторых дистрибутивах в понятие метапакет вкладывается и иной смысл. Так, в Debian этот термин фигурирует при описании назисимостей пакетов от неких программ общего назначения, например, систем доставки почты (MTA). Каковая и выступит в этом случае в качестве метапакета mail-transport-agent, вне зависимости от того, какой именно пакет реально используется в этом качестве. Впрочем, это детали, в данном контексте несущественные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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