Глава 2. О Unix'ах, Linux'ах и BSD

Введение в POSIX'ивизм

Глава 2. О Unix'ах, Linux'ах и BSD

Рассказ у нас пойдет в особенности о Linux'ах и BSD. И любознательный читатель, надеюсь, многое узнает об устройстве этих ОС и их использовании. А также поймет, что название первой системы я употребил во множественном числе вполне умышленно - и не только по аналогии с Прологом к известному произведению Профессора...

Введение в POSIX'ивизм

Что такое ОС?

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

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

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

Не менее важно и то, что на основе одного и того же (или сходного) ядра могут быть созданы системы, которые все признают полноценными (и самостоятельными) операционками. Типичный пример - ядро Mach, на коем базируются или базировались и NextOS, и MacOS X, и Darwin, и, до недавнего времени, Hurd, и безвременно оборвавшиеся Xmach и Yamitt. Вряд ли у кого повернется язык отнести все перечисленные имена к одной операционной системе. Особенно показательно сравнение MacOS X и OpenDarwin с их практически идентичным ядром...

Если отвлечься от Linux'а и обратиться к BSD-миру, то в основе ядра и FreeBSD, и NetBSD, и OpenBSD, и коммерческой BSDi лежит одно и то же ядро 4BSD, вернее, его облегченная (от проприетарного кода) версия - 4.4BSD-Lite. И хотя в дальнейшем все они развивались самостоятельно, но их взаимовлияние - факт неоспоримый: многие прогрессивные особенности, реализованные в FreeBSD 5-й ветки, пришли в нее из BSDi, иные же имеют источником проект NetBSD. Однако никому ведь не приходит в голову считать клоны BSD одной операционкой (хотя - в подтверждение высказанного в предыдущем абзаце - с точки зрения пользователя разницы между ними меньше, чем между такими Linux-дистрибутивами, как Mandrake и Slackware).

Linux, правда, избег этой участи - сепарации по разновидностям ядра. Однако значит ли это, что ядро идентично во всех его дистрибутивах? Отнюдь. Конечно, любой (любой ли?) Linux-дистрибутив теоретически может функционировать на каноническом ядре Линуса (том, что берется с http://www.kernel.org). Однако практически все крупные разработчики дистрибутивов патчат свои умолчальные ядра почем зря собственными разработками. Или включают в них достижения независимых патчестроителей, о количестве которых можно получить представление, просмотрев на том же www.kernel.org каталог people. Однако на этом основании никто (за одним исключением, о котором я скажу ниже) не утверждает, что, скажем, Red Hat и Gentoo - разные операционные системы.

Максималистская точка зрения на трактовку понятия "операционная система" последовательно проводится Microsoft с ее Windows любого рода. Согласно ей, ОС - это не только ядро, но и все его системное окружение, и графический интерфейс, и даже программы, которые испокон веков относились к категории пользовательских приложений - браузеры, например. Вспомним не столь уж давнюю тяжбу по поводу того, является ли Internet Explorer неотъемлемой частью MS Windows, которая так и не получила однозначного разрешения. А согласно сегодняшней политике MS, версий IE как отдельного приложения вообще более не будет - все его новые реализации жестко привязываются к грядущим реализациям самой Windows. В том числе - к механизмам безопасности, по всей видимости, встраиваемым в ядро (а где им еще быть?). То есть неявным образом утверждается, что ядро ОС и ее приложения - столь же едины, как народ и партия при советской власти...

Парадоксально, но такая же позиция поддерживается с крайнего фланга противоположной линии фронта - со стороны Ричарда Столлмена и его соратников по проектам GNU и Debian (ныне представленном в виде Debian GNU/Linux, но имеющего весьма экспансионистские планы). Если обратиться к интервью со Столлменом, взятым Максимом Отставновым специально для тематического выпуска "Домашнего компьютера" (#12 за 2002 год), то там можно в явном виде встретить утверждения о том, что текстовый редактор emacs - часть операционной системы, и графический интерфейс (сиречь, в данном случае, оконная система X - X Window System) - часть операционной системы, и (sic!) браузер - тоже часть операционной системы. Прямо по Биллу Гейтсу...

Некоторый резон во второй точке зрения имеется. Что особенно ясно видно на примере той же (вернее, любой) Windows. Во-первых, с теоретических позиций: вычленить из этих операционок их ядро - задача нетривиальная (а в будущих версиях, похоже, и невозможная). А практически - что останется от Windows 95/98/ME (о линии NT/2000/XP ничего не скажу), если такое удастся? Не голый ли получится DOS? Хотя нужно заметить, что попытки освобождения ОС Windows от ее якобы неотъемлемых компонентов (того же Internet Explorer) предпринимались неоднократно, и попытки успешные.

Если же вернуться к примеру Linux'а, как наиболее показательному (и наиболее обсуждаемому), то суть точки зрения Столлмена и апологетов Debian'а сводится к тому, что именно системное окружение, механизм управления пакетами и прикладные программы, вернее, методика их подбора, тестирования и критерии качества (то есть своего рода инфраструктура) и являют собой собственно операционную систему. А уж поверх какого ядра все это хозяйство функционирует - дело десятое. И иллюстрацией такой точки зрения является сам Debian (то самое обещанное исключение). Если обратиться к разделу портирования на http://www.debian.org, то там можно обнаружить информацию о портировании ОС (!) GNU Debian не только на ядро Hurd (исторически именно для него программы GNU и предназначались), но и на ядра Net- и FreeBSD.

Однако достаточно минутного размышления, чтобы сообразить: принятие второй точки зрения, в трактовке ли Microsft, или в интерпретации Столлмена и Debian Community, приводит к полному размыванию самого понятия - операционная система. Действительно, с субпозиции MS состав операционной системы определяется исключительно произволом производителя оной. "Ну а вздумается, скажем, ихнему цеху" объявить завтра неотъемлемым компонентом ОС не только Internet Explorer, но и MS Word с Excell'ем? И получится, что кроме ОС, и программ-то других не бывает...

Ну а продолжая логику Столлмена: если мы объявили emacs частью операционной системы, то на каком основании должны отказывать в этой чести vim? И если браузер - неотъемлемый компонент ОС, то который из них? Любимый Ричардом lynx, mozilla, galeon или все сразу? И как быть с графическим метаинтерфейсом, представленным оконной системой X, который по определению разрабатывался для работы поверх любых операционок? А ведь другой общепринятой графической системы нет ни в GNU Debian, ни в Linux или FreeBSD (да и вообще в POSIX-системах).

В сущности, за кадром высказывания Столлмена стоит утверждение, что в состав ОС GNU входит весь софт, распространяемый по лицензии GPL. Или даже весь софт с лицензиями, не вполне определенно называемыми GPL-совместимыми. Но в таком случае понятие операционки из худо-бедно технологического становится сугубо юридическим - ведь технологического способа определить степень "совместимости" лицензий до сих пор не придумано.

Что необходимо для ОС?

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

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

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

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

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

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

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

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

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

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

Некогда (вплоть до далекой ныне середины 90-х) микроядра виделись часто как база операционных систем будущего. Однако практические их реализации в большинстве случаев возлагаемых надежд не оправдали: их потенциальные достоинства (например, слабая зависимость от аппаратных платформ) с лихвой перекрывалась недостатками (сложностью взаимодействия компонентов и, как следствием, низким быстродействием). И ныне микроядерная архитектура реализована в узкоспециализированной ОС QNX и в нишевой MacOS X. Однако в последнее время многие идеи, исходящие из проекта Mach, были реализованы в ядре DragonFlyBSD - ответвлении FreeBSD, ориентированном на работу в многопроцессорных системах. Хотя в собственном смысле слова к микроядерным ее отнести нельзя.

Очевидно, что для работы ядро необходимо тем или иным способом загрузить. Что, как будет показано со временем, оно в принципе способно проделать собственными силами - то есть загрузчик не оказывается неотъемлемой частью операционной системы. Однако для функционирования системы недостаточно просто загрузить ядро - необходимо, чтобы оно запустило некий стартовый процесс. В Unix-системах он имеет фиксированное название - init, за запуск которого отвечает одноименный исполняемый файл /sbin/init. Однако в реальных системах под этим именем могут выступать весьма разные программы. И еще - в процессе загрузки следует выполнить некий комплекс мероприятий, определяемый набором сценариев, создающих пользовательское окружение. То есть сочетание инициирующей программы и стартовых скриптов - второй из необходимых составляющих ОС.

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

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

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

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

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

Таковы предельно минималистские требования к комплектации самодостаточной операционной системы. Именно реализация перечисленных семи компонентов обычно уникальна для каждой ОС и определяет ее своеобразие с точки зрения пользователя. Однако практически их оказывается недостаточно: для полнофункциональной необходимо еще два дополнительных компонента.

Первый - средства наращивания системы дополнительными программами, то есть комплекса инструментов, объединяемых понятием пакетного менеджмента: установки, отслеживания и удовлетворения зависимостей, удаления. Эти действия могут выполняться вручную - посредством простой сборки программ из исходных текстов. И это - универсальный метод, применимый в любой Unix-подобной системе. В этом случае достаточно наличия компилятора для языка Си/Си++ и сопутствующего инструментария (линкера, ассемблера, средств ведения проекта). В свободных POSIX-системах такой инструментарий практически безальтернативен, включая пакеты gcc (компилятор) и binutils с сопутствующими утилитами типа make, automake, autoconfig. Каковые и могут быть включены в операционную систему в качестве восьмого, но уже необязательного, компонента.

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

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

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

И последний из дополнительных (но опять-таки практически необходимых) компинентов ОС - средства для обеспечения работы в графическом режиме. Сам по себе Unix и все его потомки и производные таковых внутри себя не имели и не имеют. Эта функция возлагается на кросс-платформенную систему - X Window System, именуемую также оконной системой X или, в народе, просто Иксами. Изначально не привязанная ни к аппаратной архитектуре, ни к какой-либо ОС, сама по себе она не имеет отношения ни к одному из дистрибутивов Linux, ни к BSD-семейству ОС, ни даже к Unix вообще. Да и стандарты POSIX как-будто бы ничего о ней не говорят - реализации Иксов регламентируются собственными стандартоми, разрабатываемыми специальной организацией - X-консорциумом (X Consorcium).

Тем не менее, Иксы в одной из их свободных реализаций для Intel-совместимых процессоров - XFree86, разрабатываемой в рамках одноименного проекта, или Xorg (составная часть проекта http://freedesktop.org), оказываются непременной частью всех открытых и свободных POSIX-систем - и любого дистрибутива Linux, и всех BSD-клонов.

Иксы заняли свое место в мире Open Sources и Free Software по одной очень важной причине - им фактически нет альтернативы в смысле доступа к графическим возможностям PC. И потому они оказываются практически неотъемлемой частью любой ОС POSIX-семейства - что Linux, что BSD. Они лежат как бы на грани между базовым комплектом этих систем и их обрамлением, выступая по отношению к приложениям графического режима примерно в том же качества, что и базовые компоненты операционки - по отношению к утилитам и приложениям режима текстового. И об этом всегда нужно помнить. Как, впрочем, и о том, что Иксы (в виде ли XFree86, или в реализации Xorg) - это не Linux, не FreeBSD, и не какая-либо другая ОС: это общее достояние всех свободных операционок POSIX-семейства.

И что мы получаем, если соберем вместе все перечисленное выше? А получаем мы практически то, что во FreeBSD охватывается понятием Distributions, вернее, той его частью, которая именуется Base и является единственным компонентом, обязательным при минимальной установке. Аналогичный базовый комплекс программ (так и называемый - Base) есть также в NetBSD и OpenBSD. Причем, если ядра в этих системах и различны, то программы системного обрамления - чрезвычайно близки (местами до полной идентичности).

В Linux'е вычленить нечто подобное из какого-либо многодискового дистрибутива Linux'а несколько сложнее. Однако, напротив, можно прикрутить к его ядру некое подобие такой самодостаточной целостности. По аналогии с BSD ее можно назвать Base Linux. Представление о его составе можно получить, ознакомившись с LFS Book Герарда Бикманса - проектом, посвященным сборке собственной Linux-системы "с нуля".

Подведем итог столь длительных рассуждений. В состав любой POSIX-совместимой системы входит базовый набор из семи обязательных компонентов:

ядро ОС;
средства инициализации системы;
системные утилиты, обеспечивающие исполнение ядром его функций;
средства "боевого обеспечения" - минимальный набор пользовательских утилит;
средства "тылового обеспечения" - системные библиотеки;
командная оболочка;
система документации.

Они дополняются двумя как бы опциональными (на практически столь же обязательными компонентами): той или иной системой управления пакетами и системой поддержки работы в графическом режиме. Весь этот комплекс вполне резонно было бы назвать Base POSIX.

Кое-что о GNU, или не GNU ли Linux?

Между базовыми комплектами BSD-систем и Linux есть два важных различия, которые мы и рассмотрим последовательно.

Все системы BSD-клана на протяжении длительного времени разрабатывались именно как системные целостности (и, что немаловажно, всегда - сравнительно узкими коллективами разработчиков). Поэтому почти все составляющие их базовых комплектов - это неотъемлемые части этих ОС, созданные специально для них. Хотя есть и исключения, о чем я скажу чуть позже.

С Linux ситуация принципиально иная. Ибо большинство наиболее важных компонентов Base Linux, такие, как компилятор gcc, общесистемная библиотека glibc или командная оболочка bash, были разработаны до Linux'а, независимо от него, и - в рамках проекта GNU. Которому, по выражению Столлмена, не хватало только ядра для превращения в полноценную, противостоящую Unix, операционку. И потому кажется, что термин GNU/Linux, на котором, применительно к этой ОС, настаивает Столлмена и FSF, имеет право на существование.

Однако лично мне он не нравится. Во-первых, он оскорбляет мой литературный вкус - так и предвижу появление дистрибутивов с названиями типа "Гнутикс". Во-вторых, и это важнее, он не вполне правилен по существу. Ведь, если обратиться к истории (а в следующей главе мы это сделаем), можно увидеть, что не проект GNU ухватился за столь недостающее ему ядро. Напротив, это Линус для обеспечения работы своего ядра использовал отдельные компоненты из GNU-арсенала. В полном, к слову сказать, соответствии с духом и буквой GPL и движения FSF.

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

Кроме того, особенностью комплекса Base Linux (и это - второе важное его отличие от Distributions из FreeBSD и Base остальных BSD-систем) является его альтернативность. Причем даже для самых ключевых компонентов базовой системы - командной оболочки, главной системной библиотеки, средств работы с файловыми системами.

Так что альтернативность Base Linux - неотъемлемая черта этой операционной системы. И потому ОС Linux - не только (а может быть, и не столько) ядро и набор базовых программ. Это, на мой взгляд, в первую очередь алгоритм для построения такого набора. Видимо, именно этим он и привлекает определенную категорию пользователей - возможностью соучастия в построении основы основ системы, недостижимую не то что в Windows, но даже в мире BSD с его камерным стилем разработки. Не зря дедушка русского линуксописания, Владимир Водолазкий, отметил в свое время, что быть просто пользователем Linux- скучно. И действительно, рано или поздно любой линуксоид становится творцом - по крайней мере, в масштабах своей локальной машины. Правда, скорее всего, чаша сия не минует и пользователя BSD-системы...

Немного о дистрибутивах Linux

Термин "дистрибутив Linux" постоянно фигурировал ранее и столь же регулярно будет появляться и впредь, так что следует уделить некоторое внимание тому, что же он означает.

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

В обиходе за такими адаптированными комплексами закрепился термин Distro, сопровождаемый, как правило, именем собственным вместе с родовым именем ОС. Примерами являются: Red Hat Linux, Slackware Linux, и так далее. Некоторые разработчики считают нужным в имени дистрибутива подчеркнуть GNU'тое происхождение большей части входящих в них программ. Отсюда появляются названия - Debian GNU/Linux и подобные. А бывают и дистрибутивы (например, CRUX), в названии которых слово Linux вообще отсутствует - и это не значит, что они отвергают свою родовую принадлежность, просто разработчикам так показалось красивей.

Адаптация Base Linux под конкретные задачи осуществляется в двух направлениях. Основным является наращивание функциональности. Разработчики дистрибутивов дополняют базовый комплекс дополнительными программными средствами, предназначенными, например, для работы в графическом режиме вообще (оконная система X), программами, обеспечивающими графический пользовательский интерфейс (оконные менеджеры и интегрированные рабочие среды), инструментарием для работы с графическими и мультимедийными данными, пакетами для офисных работ, и так далее. В результате образуется более или менее канонический набор программ, в прекомпилированном виде занимающий ныне обычно 3-5 дисков. Дистрибутивы такого типа и объема можно назвать полнофункциональными, или универсальными.

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

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

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

Можно представить себе и еще одну разновидность специализированных дистрибутивов - пока эвентуальную, но с которой, как мне кажется связано будущее десктопного применения Linux (и, возможно, BSD-систем) в сколько-нибудь широких масштабах - если таковое когда-либо наступит. Это - те самые АРМы (автоматизированные рабочие места) специалистов в областях, далеких от информационных технологий - от банковских операционистов до офисных делопроизводителей, - о которых шла речь в предыдущей главе. То есть - монофункциональные системы, собранные и настроенные для выполнения одной задачи, но уже не административной (как многочисленные мини-дистрибутивы) или ознакомительной (как большинство LiveCD), но - производственной. Ныне таковых практически не существует. Но упомянутый выше MoviX может рассматриваться как прототип таких АРМов - ибо является ни чем иным, как "рабочим местом" потребителя мультимедийной продукции.

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

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

Поскольку систем управления бинарными пакетами существует не так уж много, по тому же критерию можно провести и более дробную классификацию пакетных дистрибутивов. Здесь обособляется многочисленное семейство дистрибутивов, базируемых на rpm (Red Hat Packages Manager), семейство deb-дистрибутивов (прародителем которых был дистрибутив Debian) и разнообразные дистрибутивы с управлением пакетов в стиле Slackware. Что же касается систем Source Based, то почти каждая из них обладает уникальной системой пакетного менеджмента, в основе которой лежит идея портов FreeBSD (почему их можно назвать также дистрибутивами портируемыми).

Впрочем, взаимовлияние и проникновение идей в мире Open Sources таково, что удачные находки в области пакетного менеджмента распространяются по нему со скоростью лесного пожара. Так, пакетный менеджер apt, родившийся в недрах Debian, был очень быстро адаптирован для использования с пакетами rpm-формата и внедрен во многих клонах Red Hat, порты FreeBSD легли в основу всех систем автоматизации сборки пакетов из исходных текстов, и так далее.

Грань между пакетными дистрибутивами и "исходняками" также не является непреодолимой. Такие дистрибутивы, как CRUX и Archlinux, распространяясь в прекомпилированном виде, имеют развитые системы портов. Gentoo - наиболее популярный представитель "исходнячного" класса, - имеет и прекомпилированный вариант распространения. Ну и системы пакетирования типа apt также могут служить и для установки программ непосредственно из исходников.

Иерархия файлов и каталогов - то, что часто называют файловой системой в логическом смысле этого слова, - долгое время была весьма специфичной для дистрибутивов Linux. По крайней мере, представители основных генетических линий их (такие, как клоны Red Hat или Debian) отличались между собой, на горе как разработчиков, так и пользователей, достаточно отчетливо. Однако ныне активно развивается проект Filesystem Hierarchy Standard, который, можно надеяться, со временем нивелирует эти различия - по крайней мере, для главных общесистемных каталогов.

Программа установки и средства конфигурирования системы обычно считаются неотъемлемыми атрибутами самостоятельного дистрибутива. Однако это - скорее теоретическая максима, к которой следует стремиться, нежели жизненная реальность. Ряд дистрибутивов, самостоятельность которых сомнению не подвергается (яркий пример - Altlinux), наследуют инсталляторы от своего отдаленного прототипа (в данном случае - Linux Mandrake). А такой безусловно самостоятельный дистрибутив, как Gentoo, программы установки не имеет вообще. Вернее, в качестве инсталлятора в нем выступает командная оболочка bash, а универсальным конфигуратором служит обычный текстовый редактор...

Система инициализации - это наборы стартовых сценариев, определяющих загрузку различных служб при запуске системы. И это - сфера, в которой разработчики дистрибутивов обычно оттягиваются по полной программе. Конечно, все многообразие стартовых наборов сводится к вариациям на две основные темы - мажорную System V и - не то чтобы минорную, но более сдержанную, BSD-тему (о сути обеих разговор пойдет в главе 13 и следующей за ней интермедии). Однако: ни в рамках первой, ни в исполнении второй двух одинаковых схем инициации обнаружить, скорее всего, не удастся. И потому систему инициализации можно считать одной из существенных дистрибутив-специфичных особенностей.

Наконец, комплектация пакетами и приложениями. Здесь можно наметить две тенденции: максимально возможный охват всего многообразия свободного софта в рамках отдельного дистрибутива и создание некоего ограниченного, но самодостаточного набора. Первая тенденция наиболее ярко реализована в Debian, Altlinux с его Sysiphus, и в портежах Gentoo. Типичный представитель второго направления - Slackware и его идеологические наследники (типа CRUX и Archlinux).

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

К чему я все это говорю? Да к тому, что, при всем внешнем различии дистрибутивов Linux (а при беглом сравнении, например, Linux Slackware и Linux Mandrake они кажутся просто разными операционными системами), общего между ними гораздо больше, чем особенного. И потому пользователь с равным успехом может использовать любой дистрибутив - из числа хорошо собранных, разумеется. Перефразируя графа нашего, пахаря: с каждым хорошим дистрибутивом пользователь будет счастлив одинаково, с каждым плохим - несчастлив по своему. Остается только отделить зерна от плевел - дистрибутивы хорошие от дистрибутивов плохих. К счастью, подавляющее большинство известных мне дистрибутивов из числа распространенных (и даже - не очень распространенных) относится к первой категории. На отрицательных примерах я останавливаться не намерен, потому все упомянутые в этой книге дистрибутивы пользователь может числить в хороших (если прямо не оговорено иное - но обвинениями в адрес дистрибутивов я отягощать свою совесть не намерен - о дистрибутивах aut bene, aut nihil, как сказали бы древнеримские греки).

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

А вообще свои последние представления о классификации дистрибутивов я описал в специальной статье. К коей и отсылаю заинтересованных читателей.

О BSD сотоварищи

Прояснив вопрос с дистрибутивами Linux, обратимся теперь к BSD-системам. Ибо понять их специфику лучше всего в сопоставлении с Linux'ом и противопоставлении ему. Как, впрочем, и наоборот - в предыдущих разделах мы видели, что понимание того, что такое Linux, выкристаллизовывается именно в сравнении с BSD-системами.

Для начала назовем наиболее распространенные BSD-системы. Это (хронологически) NetBSD, FreeBSD и OpenBSD (не считая коммерческой BSDi - впрочем, и распространена она мало, по крайней мере, я не слышал о ее пользователях на Руси). Они связаны общностью происхождения - от системы, именовавшейся BSD Unix, а в дальнейшем - X.XBSD, исторически позднейшая версия которой - 4.4BSD. От последней и происходят современные BSD-системы, Net- и FreeBSD - непосредственно, а OpenBSD - как отпочковавшаяся от NetBSD. А недавно BSD-семейство пополнилось еще одним полноправным членом - системой DragonFlyBSD, заслуживающей специального разговора.

Впрочем, и история BSD-систем - вопрос отдельный и очень интересный - мы к нему еще вернемся в следующей главе. А в контексте сегодняшнего разговора подчеркну, что Free-, Net- и OpenBSD, не говоря уже о DragonFly, - это не подвиды одной системы, как дистрибутивы Linux, а именно самостоятельные ОС, каждая со своим ядром и базовым комплектом системных и пользовательских утилит. Хотя, парадоксальным образом, с точки зрения пользователя - я не боюсь повториться в очередной раз, - разницы между ними меньше, чем между Linux Slackware и Linux Mandrake, например.

Итак, первое: если бесчисленные дистрибутивы Linux суть вариации на тему одной и той же ОС, то редкие BSD-клоны - самостоятельные, хотя и родственные, операционки. И причина их обособления - ориентация на разные сферы применения.

Так, NetBSD испокон веков развивалась в русле классических традиций Unix (и POSIX) - как максимально независимая от платформы, переносимая система: трудно найти машины такой архитектуры, на которые эта операционка не была бы портирована, от антикварных, названия которых мало кто помнит, до новейших. Как говорят, для переноса NetBSD на машины с процессорами AMD64 потребовались считанные дни.

FreeBSD, напротив, возникла и долгое время развивалась с прицелом на оптимизацию под наиболее демократичную платформу - 32-разрядные Intel-совместимые процессоры. И возможностью работы на наиболее близких к ним, но 64-разрядных процессорах Alpha. Безвременная кончина последней архитектуры сделала эту линию бесперспективной. Однако 64-разрядные наработки были аккумулированы во FreeBSD 5-й ветки, что способствовало росту ее мультиплатформенности: кроме 64-разрядных процессоров AMD и Intel, она в состоянии работать также на Sun Sparc. Тем не менее, именно ориентация на массовые Intel-совместимые процессоры (сиречь обычные PC'шки) и сделала FreeBSD наиболее распространенным представителем своего клана.

Конек OpenBSD - это безопасность в самом широком смысле слова. Качество, которое может оказаться востребованным в связи с массовой "интернетизаций" персоналок.

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

Вторая отличительная черта BSD-систем - монолитность. Если любой дистрибутив Linux являет собой более или менее тесную интеграцию ядра и базовых пакетов разного происхождения, то в каждом BSD-клоне ядро и комплекс средств его обеспечения представляют собой единое и (с некоторыми оговорками, о которых речь пойдет ниже) неделимое целое, не расчленяемое на кванты-пакеты. Базовый комплекс Net- и OpenBSD поставляется в виде единого тарбалла. А во FreeBSD он хотя и разбит на фрагменты по 1,44 Мбайт, но это сделано исключительно из соображений удобства скачивания и записи (наследие тех времен, когда операционную систему еще можно было установить целиком с дискет). DragonFly же вообще переносится в процессе инсталляции в том же виде, в каком эта система присутствует на установочном CD.

Из этого вытекает третья особенность BSD-систем - их внутренняя безальтернативность. Если в Linux, как уже говорилось, чуть ли не любому компоненту, кроме ядра, можно подобрать функциональный аналог, пользователь BSD привязан к тому комплекту, который идет с ядром его системы. Характерный пример - FreeBSD. Там переход с одной ветви на другу, более новую (что эквивалентно смене версии ядра в Linux) требует полной пересборки базовой системы (механизм make world).

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

И потому пользователь может индивидуализировать свою систему ничуть не в меньшей степени, чем при последовательной сборке Linux из исходников. В некоторых случаях это приводит к появлению разновидностей BSD-систем, формально напоминающих Linux-дистрибутивы. Известны такие производные FreeBSD, как PicoBSD (система на одной дискете, способная, тем не менее, выполнять функции не только сетевой станции, но даже Dial-Up сервера), Frenzy - работающая с CD полнофункциональная система, предназначенная для сетевого администрирования, или FreeSBIE - столь же полнофункциональный LiveCD, призванный продемонстрировать достоинства BSD-систем как пользовательских десктопов..

Тем не менее, BSD-системы избежали сегментации по дистрибутивному принципу. Приведенные примеры, во-первых, крайне немногочисленны, во-вторых, имеют сугубо специальное назначение, в третьих, их развитие все равно остается в рамках генеральной линии FreeBSD: и PicoBSD, и Frenzy, и FreeSBIE с точки зрения внутреннего устройства представляют собой самую обычную FreeBSD.

Тем не менее, клонирование BSD-систем также иногда имеет место, только происходит оно иначе, чем в Linux. Разновидность какой-либо BSD-системы, удалившись от своего предка, превращается в самостоятельную ОС - со своим ядром и базовым комплексом программ. Выше я упоминал о отделении OpenBSD от родительской NetBSD. А в наши дни мы присутствуем при начале расщепления FreeBSD - летом 2003 года от генеральной ее линии ответвилась система DragonFlyBSD, внешне почти неотличимая, но совершенно иная с точки зрения внутренней архитектуры.

Существует и другой путь размножения BSD-систем: вследствие цельности и сбалансированности базового комплекта их приложений последний подчас используется как инфраструктура, надстраивающая совершенно иные (не связанные генетически с 4.4BSD) ядра. В частности, микроядро Mach, разрабатывавшееся вплоть до второй половины 90-х годов университетами - сначала Карнеги-Меллона, а затем штата Юта.

Наиболее известный (и единственно работоспособный) пример такой надстройки - MacOS X и ее свободный отпрыск - OpenDarwin. Однако в процессе вялотекущей разработки можно обнаружить еще несколько идеологически близких систем - xMach, похоже, прекративший развитие, и Yammit, недавно разделивший его участь.

Есть случаи и иного подхода - перенос инфраструктуры Linux на ядро какого-либо BSD-клона. И тут на память приходят амбициозные проекты Debian - Debian GNU/FreeBSD (причем сразу в двух вариантах) и Debian GNU/NetBSD. И, наконец, к этой же категории примыкает попытка переноса системы портежей Gentoo на ядро и системное окружение FreeBSD - взамен ее собственной системы портов (каковая в свое время послужила прототипом портежей).

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

Вообще, взаимовлияние систем внутри BSD-клана - тоже отличительная его особенность. Удачные решения одной из ОС очень быстро распространяются среди ее сородичей. Пример - система портов FreeBSD, заимствованная в OpenBSD с самого начала, а в дальнейшем (в виде системы pkgsrc) распространившаяся и на NetBSD. С другой стороны, многие отличительные особенности 5-й ветки FreeBSD, напротив, уходят своими корнями в NetBSD (и даже в коммерческую BSDi). Есть и примеры внедрения во FreeBSD новшеств из ее отпрыска - DragonFly.

Так что мир BSD-систем в значительной мере сохраняет свое идеологическое единство. Более того, его влияние распространяется и на Linux: выше я неоднократно подчеркивал, что Source Based дистрибутивы Linux в значительной мере основываются на идейном наследии FreeBSD.

Все сказанное выше не имеет целью доказать преимущества BSD-систем над Linux (впрочем, как и противоположное утверждение): споры такого характера я полагаю беспредметными. Просто я хотел подчеркнуть, что а) Linux'ом мир свободных POSIX-систем не исчерпывается, б) все они находятся в постоянном взаимодействии друг с другом, и в) понимание особенностей BSD-систем может способствовать более глубокому освоению Linux'а, и наоборот. А уж что выбрать для личного употребления - дело целей, задач, обстоятельств, вкуса, а может быть, даже и случая.

Вообще проблема выбора первой системы - широка и многогранна, и потому будет детально рассмотрена в главе 5-й. В ней я постараюсь обосновать, почему именно FreeBSD, наряду с парой-тройкой дистрибутивов Linux, из которых оптимальным представляется мне Archlinux, видятся мне самыми благоприятными объектами для изучения POSIX-систем вообще. Но, повторяю, это - не более, чем мое личное мнение. Если после прочтения этих страниц вы сможете сформировать свой собственный взгляд на вопрос выбора системы и (или) дистрибутива - одну из целей своего сочинения я буду считать достигнутой.

Следует уделить внимание вопросу, как же POSIX-системы дошли до жизни такой. Для чего придется погрузиться в глубины истории, подобно тому, как это сделал Гэндальф, расследуя происхождение Кольца Всевластия...

Назад Содержание Вперед