Рассказ у нас пойдет в особенности о Linux'ах и FreeBSD. И любознательный читатель, надеюсь, многое узнает об устройстве этих ОС и их использовании. А также поймет, что название первой системы я употребил во множественном числе вполне умышленно - и не только по аналогии с Прологом к известному произведению Профессора...
Однако, прежде чем переходить к сути дела, хорошо бы ответить на вопрос: а что же такое операционная система? Для чего следует рассмотреть существующие, явно или неявно, мнения на сей предмету.
А распространенных мнений по вопросу, что такое операционная система, - два: минималистское и максималистское. Согласно первому, операционная система - это программа, именуемая ядром ОС. Что применительно, например, к Linux, должно трактоваться так, что под это определение подпадает только разрабатываемое Линусом сотоварищи ядро. А все, что существует в составе любого Linux-дистрибутива помимо, суть системные утилиты и пользовательские приложения, к самой ОС отношения не имеющие.
Понятно, что ядро в очень большой степени определяет своеобразие ОС. Однако если подходить с точки зрения пользователя, само по себе ядро - пресловутая вещь в себе, так как не способно не только функционировать, но даже само себя загрузить. И без соответствующего системного окружения пользователь просто никогда не узнает о его несравненных достоинствах.
Не менее важно и то, что на основе одного и того же (или сходного) ядра могут быть созданы системы, которые все признают полноценными (и самостоятельными) операционками. Типичный пример - ядро mach, на коем базируются или базировались и NextOS, и MacOS X, и Darwin, и Hurd, и перманентно находящиеся в состоянии вялотекущей разработки Xmach и Yamitt (но тем не менее реально существующие - Xmach я однажды даже смог запустить:-)). Вряд ли у кого повернется язык отнести все перечисленные имена к одной операционной системе. Особенно MacOS X и Darwin с их практически идентичным ядром...
Если отвлечься от Linux'а и обратиться к BSD-миру, то в основе ядра и FreeBSD, и NetBSD, и OpenBSD, и коммерческой BSDi лежит одно и то же ядро 4BSD, вернее, его облегченная (от проприетарного кода) версия - 4.4BSD-Lite. И хотя в дальнейшем все они развивались самостоятельно, но их взаимовлияние - факт неоспоримый: многие прогрессивные особенности, реализованные в FreeBSD 5 (в частности, касающиеся многопроцессорности) пришли в нее из BSDi, иные же имеют источником проект NetBSD. Однако никому ведь не приходит в голову считать клоны BSD одной операционкой (хотя - в подтверждение высказанного в предыдущем абзаце - с точки зрения пользователя разницы между ними меньше, чем между такими Linux-дистрибутивами, как Mandrake и Slackware).
Linux, правда, избег этой участи - сепарации по разновидностям ядра. Однако значит ли это, что ядро идентично во всех его дистрибутивах? Отнюдь. Конечно, любой (любой ли?) Linux-дистрибутив теоретически может функционировать на каноническом ядре Линуса (том, что берется с 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 от ее якобы неотъемлемых компонентов (того же IE) предпринимались неоднократно, и попытки успешные.
Если же вернуться к примеру Linux'а, как наиболее показательному (и наиболее обсуждаемому), то суть точки зрения Столлмена и апологетов Debian'а сводится к тому, что именно системное окружение, механизм управления пакетами и прикладные программы, вернее, методика их подбора, тестирования и критерии качества (то есть своего рода инфраструктура) и являют собой собственно операционную систему. А уж поверх какого ядра все это хозяйство функционирует - дело десятое. И иллюстрацией такой точки зрения является сам Debian (то самое обещанное исключение). Если обратиться к разделу портирования на www.debian.org, то там можно обнаружить информацию о портировании ОС (!) GNU Debian не только на ядро Hurd (исторически именно для него программы GNU и предназначались), но и на ядро Net- и FreeBSD.
Однако достаточно минутного размышления, чтобы сообразить: принятие второй точки зрения, в трактовке ли Microsft или в интерпретации RMS и Debian Community, приводит к полному размыванию самого понятия - операционная система. Действительно, с субпозиции MS состав операционной системы определяется исключительно произволом производителя оной. "Ну а вздумается, скажем, ихнему цеху" объявить завтра неотъемлемым компонентом ОС не только IE, но и MS Word с Excell'ем? И получится, что кроме ОС, и программ-то других не бывает...
Ну а продолжая логику RMS: если мы объявили emacs частью операционной системы, то на каком основании должны отказывать в этой чести Vim? И если браузер - неотъемлемый компонент ОС, то какой из них? Любимый RMS'ом lynx, mozilla, galeon или все сразу? И как быть с графическим метаинтерфейсом, представленным оконной системой X, который по определению разрабатывался для работы поверх любых операционок? А ведь другой общепринятой графической системы нет ни в GNU Debian, ни в Linux или FreeBSD (да и вообще в Unix).
В сущности, за кадром высказывания Столлмена стоит утверждение, что в состав ОС входит весь софт, распространяемый по лицензии GPL. Или даже весь софт с лицензиями, не вполне определенно называемыми GPL-compatible (те же Иксы, например, распространяются на условиях собственно лицензии X-консорциума). Но в таком случае понятие операционки из худо-бедно технологического становится сугубо юридическим - ведь технологического способа определить степень "совместимости" лицензий до сих пор не придумано.
Благо, наряду с двумя перечисленными точками зрения существует и третья. Формулировки ее в явном виде мне не встречалось (хотя в неявном, то есть на практике, ее придерживаются разработчики систем BSD-клана). И потому возьму на себя смелость такую формулировку дать: операционная система - это ядро и самодостаточный комплекс средств, необходимых для ее функционирования на благо пользователя. То есть пользователь любой ОС, загрузив оную, должен иметь возможность в первую очередь устанавливать, не обращаясь ни к каким сторонним инструментам, необходимое ему программное обеспечение, запускать его и работать с ним. А теперь попробую дать развернутое обоснование третьей позиции.
То, что любая ОС не способна функционировать без ядра - очевидно. Однако для этого ядро необходимо тем или иным способом загрузить. И потому, говоря языком Столлмена, загрузчик оказывается неотъемлемой частью операционной системы. Конечно, существует достаточное количество мультисистемных загрузчиков. Однако ставить от них в зависимость само существование ОС было бы не правильно - на худой конец, операционка должна иметь штатное средство загрузить саму себя. Другое дело, что средство это не обязано быть уникальным: Linux можно загрузить с помощью Lilo и GRUB (а также без всякого загрузчика вообще), FreeBSD - с помощью собственного loader'а и того же GRUB (да и с помощью Lilo тоже), и так далее.
Вообще говоря, GRUB (см. соответствующие материалы - о GRUB вообще и о загрузке им FreeBSD) тем или иным способом позволяет загрузить практически любую ОС - вплоть до Windows разного рода. И потому имеет все шансы стать надсистемным загрузчиком в мире Open Sources. Что, тем не менее, не мешает развитию ни Lilo, ни FreeBSD Loader'а...
Для функционирования системы недостаточно просто загрузить ядро - необходимо, чтобы оно запустило некий стартовый процесс. В Unix-системах он имеет фиксированное название - init, за запуск которого отвечает одноименный исполняемый файл /sbin/init. Однако в реальной системе под этим именем могут выступать весьма разные программы. И еще - в процессе загрузки следует выполнить некий комплекс мероприятий, определяемый набором сценариев, создающих пользовательское окружение. То есть сочетание инициирующей программы и стартовых скриптов - также необходимые составляющие ОС.
Далее, ядро должно взаимодействовать с файловой системой на каких-либо носителях - иначе откуда будут браться данные для работы системы (да и самому ядру размещаться где-то нужно). А отсюда - третий непременный компонент операционки, включающий средства обращения к физическим носителям, создания на них разделов и файловых систем, их проверки, монтирования и т.д. Если же ядро предусматривает поддержку нескольких файловых систем (как это имеет быть, например, для ядра Linux) в качестве родных (native) - к каждой из них должен прилагаться свой комплекс обслуживающих утилит.
Все перечисленные выше компоненты - ядро, его системное окружение и загрузчик, - необходимы для самообеспечения системы. Но ведь цель ее, в конечном счете, - выполнение пользовательских задач. А потому ОС должна включать - нет, не прикладные программы, это отдельная история, а средства их установки. А в мире Unix-существует один универсальный способ распространения программ - в виде архивов исходников, и единственный столь же универсальный метод их установки - компиляция оных. И тут выявляется абсолютная необходимость, с одной стороны, средств для работы с архивами, с одной стороны, и компилятора со всем сопутствующим инструментарием (линкером, ассемблером и т.д.).
Пакеты распространяются не только в исходных текстах, но и в виде прекомпилированных бинарников разных форматов, из которых наиболее распространены rpm, deb и вариации на тему tgz/tbz2. В одних случаях это - чистые компрессированные архивы (т.н. тарбалл - tarballs), которые могут быть распакованы и установлены стандартным архиватором. В других же - они несут более или менее полную метаинформацию (в частности, описание зависимостей), и для установки их требуются соответствующие программы - менеджеры пакетов. Из них наиболее распространен rpm - Rpm Packages Manager, работающий с пакетами одноименного формата, а наиболее универсален - apt, предназначенный для пакетов deb, но не менее успешно управляющийся и с rpm-пакетами.
И потому существует мнение, что пакетный менеджер - столь же непременная часть ОС, как и архиваторы/компрессоры. Ввиду специфичности как форматов пакетов, так и управляющих ими программ, мне это представляется спорным. Не так давно зародился проект кросс-системного пакетного менеджера. В случае его успеха такая программа будет вполне весомым компонентом любой базовой ОС.
Процесс сборки программ неизбежно влечет потребность в системных библиотеках - библиотеке функций языка Си (главного средства разработки в контексте Unix-систем) и некоторых других (например, свойств терминала). Это - во-первых. Во-вторых же, в процессе сборки программ задействуется некоторое количество утилит для работы с файлами и текстами (find, grep, awk, sed), которые можно было бы отнести к категории пользовательских. Но в этом контексте они оказываются членами необходимого системного окружения - без них сборка и установка программ просто невозможна.
Кроме того, для самодостаточности система должна иметь средства получения программ, а универсальным источником их выступает Интернет. Следовательно, базовый набор сетевого инструментария и средств прочего (например, модемного или ADSL-) доступа, столь же необходимы, как компилятор или системные библиотеки.
Любые действия в любой системе выполняются, прямо или косвенно, путем отдачи соответствующих командных директив. И потому интегрирующей надстройкой над всем описанным богачеством выступает командная оболочка, она же - интерпретатор языка команд, по простому - шелл (shell).
И. наконец, последний необходимый компонент ОС - внутренняя система документации. Таковой испокон веков в Unix выступает система man-страниц (Manual Pages).Не смотря на появление множества других форматов для представления документов, при всей своей архаичности остающаяся простым и универсальным средством оперативного получения информации.
Таковы предельно минималистские требования к комплектации самодостаточной системы. Конечно, в ее базовый набор неплохо включить текстовый редактор для правки конфигурационных файлов, да и еще кое-какие программы. Однако мы говорим именно о незаменимых вещах, а редактор (для указанных целей) вполне подменяется набором текстовых утилит (тех же cat, awk, sed), без которых действительно нельзя обойтись. И потому, вопреки мнению Столлмена, ни редактор, ни браузер не являются неотъемлемыми частями операционки. А вот средства коннекта (например, PPP и/или PPPoE) и ftp-клиент - являются (или вы знаете другой способ подключения к Сети и скачивания из нее программ?).
И что мы получаем, если соберем вместе все перечисленное выше? А получаем мы практически то, что во FreeBSD охватывается понятием Distributions, вернее, той его частью, которая именуется Base и является единственным компонентом, обязательным при минимальной установке. Аналогичный базовый комплекс программ (так и называемый - Base) есть также в NetBSD и OpenBSD. Причем, если ядра в этих системах и различны, то программы системного обрамления - чрезвычайно близки (местами до полной идентичности).
В Linux'е вычленить нечто подобное из какого-либо многодискового дистрибутива Linux'а несколько сложнее. Однако, напротив, можно прикрутить к его ядру некое подобие такой самодостаточной целостности.
Это - некоторый комплекс, который в более или менее неизменном виде входит в любой дистрибутив Linux. По аналогии с BSD-системами, его можно назвать Base Linux. Компоненты этого комплекса а) абсолютно необходимы для загрузки и функционирования системы, б) связаны друг с другом зависимостями, часто перекрестными, и в) являются уникальными именно для Linux'а. Хотя многие программы поименно могут совпадать с классическими Unix-утилитами или своими функциональными аналогами из BSD-систем, но это - именно самостоятельные программы, не заимствованные ни из Unix'ов любого рода, ни из Free- или прочих BSD. А потому сочетание ядра Linux с этим базовым комплексом вполне заслуживает звания операционной системы.
Что же касается многочисленных дистрибутивов Linux, то это, в первую очередь, системы комплектации Base Linux дополнительными (в первую очередь пользовательскими) приложениями.
Среди последних особое положение занимает средство для обеспечения работы в графическом режиме - X Window System, именуемая также оконной системой X или, в народе, просто Иксами. Сугубо кроссплатформенная, изначально не привязанная ни к аппаратной архитектуре, ни к какой-либо ОС, сама по себе она не имеет отношения ни к одному из дистрибутивов Linux, ни к BSD-семейству ОС, ни даже к Unix вообще. Да и стандарты POSIX как-будто бы ничего о ней не говорят - реализации Иксов регламентируются собственными стандартоми, разрабатываемыми специальной организацией - X-консорциумом (X Consorcium, не путать с Консорциумом, известным нам по детективам Данила Корецкого).
Тем не менее, Иксы (в их свободной реализации для Intel-совместимых процессоров - XFree86, разрабатываемой в рамках одноименного проекта и распространяемой под собственной лицензией, стали неотъемлемой частью всех открытых и свободных POSIX-систем - и любого дистрибутива Linux, и всех BSD-клонов (и даже, как говорят, бесплатной версии Sun Solaris для PC-архитектуры - так ли это? кто просветит?).
В недавнее последнее время, после изменения лицензии на XFree86, которое адепты Free Software сочли несовместимым с принципами свободы (я, грешным делом, так и не понял, почему), от него отделился новый, "истинно свободный" проект - Xorg, постепенно включаемый во все большее количество дистрибутивов Linux. Вполне возможно, что именно он заменит XFree86 в качестве стандартного графического метаинтерфейса.
Иксы заняли свое место в мире Open Sources и Free Software по одной очень важной причине - им фактически нет альтернативы в смысле доступа к графическим возможностям PC. И потому они стали почти неотъемлемой частью любой ОС - что Linux, что BSD. Они лежат как бы на грани между базовым комплектом этих систем и их обрамлением, выступая по отношению к приложениям графического режима примерно в том же качества, что и Base - по отношению ко всему остальному. И об этом всегда нужно помнить. Как, впрочем, и о том, что Иксы (в виде ли XFree86, или в реализации Xorg) - это не Linux, не FreeBSD, и не какая-либо другая ОС: это общее достояние всех свободных операционок POSIX-семейства.
Между базовыми комплектами BSD-систем и Linux есть два важных различия, которые мы и рассмотрим последовательно.
Все системы BSD-клана на протяжении длительного времени разрабатывались именно как системные целостности (и, что немаловажно, всегда - сравнительно узкими коллективами разработчиков). Поэтому почти все составляющие их базовых комплектов - это неотъемлемые части этих ОС, созданные специально для них. Хотя есть и исключения, о чем я скажу чуть позже.
С Linux ситуация принципиально иная. Ибо большинство наиболее важных компонентов Base Linux, такие, как компилятор gcc, общесистемная библиотека glibc или командная оболочка bash, были разработаны до Linux'а, независимо от него, и - в рамках проекта GNU. Которому, по выражению Столлмена, не хватало только ядра :-) (смайлик мой - ибо ядро Hurd на момент появления Linux'а работоспособным не являлось; да и ныне, после недавней его гальванизации, вряд ли оно пригодно к практическому применению) для превращения в полноценную, противостоящую Unix, операционку. И потому кажется, что термин GNU/Linux, на котором, применительно к этой ОС настаивает Столлмена и FSF, имеет право на существование.
Однако лично мне он не нравится. Во-первых, он оскорбляет мой литературный вкус - так и предвижу появление дистрибутивов с названиями типа "Гнутикс". Во-вторых, и это важнее, он не вполне правилен по существу. Ведь, если обратиться к истории, можно увидеть, что не проект GNU ухватился за столь недостающее ему ядро. Напротив, это Линус для обеспечения работы своего ядра использовал отдельные компоненты из GNU-арсенала. В полном, к слову сказать, соответствии с духом и буквой GPL и движения FSF.
Так что заслуга построения Linux'а как цельной, самостоятельной и самодостаточной системы принадлежит Линусу. Ну и тому множеству разработчиков, которые приняли в этом участие - никто из них ведь не настаивал на том, чтобы в названии системы фигурировало его имя или название программы, которую он написал.
Кроме того, и это важно, особенностью комплекса Base Linux (и это - второе важное его отличие от Distributions из FreeBSD и Base остальных BSD-систем) является его альтернативность. О возможности выбора загрузчика или инструментария для работы с файловыми системами уже было сказано, про изобилие, скажем, консольных ftp-клиентов - и говорить нечего. Но выбор альтернатив в Linux возможен даже для самых ключевых компонентов базовой системы.
Так, в качестве системы инициации в Linux традиционно используется пакет sysvinit, воспроизводящий стиль загрузки классической Unix System V. Однако его вполне можно заменить (и такое реально проделывалось и проделывается) на пакеты инициации в BSD-стиле (например, simpleinit и его разновидности), сопроводив BSD-подобным набором стартовых сценариев.
Далее, пакет binutils (то есть набор утилит, абсолютно необходимых для сборки программ) даже официально существует в двух вариантах - пакете проекта GNU и близком, но не идентичном аналоге из проекта Kernel.org. Попытки заменить gcc (то есть GNU C Compiler) на другие компиляторы (pgcc, egcc) также
предпринимались (хотя и не очень успешно). А недавние опыты (см. цикл SPEC CPU2000 на ixbt.com показали, что со сборкой многих компонентов Linux справляется коммерческий (но на определенных условиях бесплатный - и потому могущий быть использованным в пакетных дистрибутивах) Си-компилятор от Intel. Причем отнюдь не только на процессорах ее же производства, но и на процессорах AMD, в том числе - AMD64. Даже для glibc можно подобрать замену, пусть менее функциональную, но более компактную (eClibc) - и это на практике делается для дистрибутивов специального назначения, скажем, для встраиваемых устройств.
Что же касается общесистемного интегратора Base Linux - командной оболочки, то в этом качестве вместо традиционного bash вполне можно использовать любой другой шелл из числа совместимых с Bourne Shell (точнее сказать, с эталонным POSIX-shell): от предельно облегченного ash (что часто делается в мини-дистрибутивах) до наиболее функционального представителя семейства - zsh. В частности, у меня в Linux эту роль успешно выполняет именно последний.
Так что альтернативность Base Linux - неотъемлемая черта этой операционной системы. И потому ОС Linux - не только (а может быть, и не столько) ядро и набор базовых программ. Это, на мой взгляд, в первую очередь алгоритм для построения такого набора. Видимо, именно этим он и привлекает определенную категорию пользователей - возможностью соучастия в построении основы основ системы, недостижимую не то что в Windows, но даже в мире 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 предназначены для ознакомительных целей, представляя собой более или менее полное воспроизведение функциональности нормальной Linux-системы. Другие же - монофункциональны, и способны выполнять только какую-либо одну задачу. Примером тому - 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 Standart, который, можно надеяться, со временем снимет эти различия.
Программа установки и средства конфигурирования системы обычно считаются неотъемлемыми атрибутиками самостоятельного дистрибутива. Однако это - скорее
жизненная максима, к которой следует стремиться, нежели реальность. Ряд дистрибутивов, самостоятельность которых сомнению не подвергается (яркий пример - Altlinux), наследуют инсталлятора от своего отдаленного прототипа (в данном случае - Linux Mandrake). А такой безусловно самостоятельный дистрибутив, как Gentoo, программы установки не имеет вообще. Вернее, в качестве инсталлятора в нем выступает командная оболочка bash, а универсальным конфигуратором служит обычный текстовый процессор...
Система инициализации - это наборы стартовых сценариев, определяющих загрузку различных служб при запуске системы. И это - сфера, в которой разработчики дистрибутивов обычно оттягиваются по полной программе. Конечно, все многообразие стартовых наборов сводится к вариациям на две основные темы - мажорную System V и - не то чтобы минорную, но более сдержанную, BSD-тему (о сути обеих разговор пойдет своевременно). Однако: ни в рамках первой, ни в исполнении второй двух одинаковых схем инициации обнаружить, скорее всего, не удастся. И потому систему инициализации можно считать одной из существенных дистрибутив-специфичных особенностей.
Наконец, комплектация пакетами и приложениями. Здесь можно наметить две тенденции: максимально возможный охват всего многообразия свободного софта в рамках отдельного дистрибутива и создание некоего ограниченного, но самодостаточного набора. Первая тенденция наиболее ярко реализована в Debian, Altlinux с его Sysiphus, и в портежах Gentoo. Типичный представитель второго направления - Slackware и его идеологические наследники (типа CRUX и Archlinux).
Однако и в подходе к комплектации можно видеть конвергенцию признаков. С одной стороны, монстроидальные дистрибутивы, как правило. имеют облегченные варианты с более ограниченными наборами программ. С другой - исходно самоограничиващиеся дистрибутивы (а тенденция к самоограничению наиболее отчетливо проявлена в CRUX) обычно пополняются независимыми разработчиками, результаты работы которых доступны, пусть не в составе установочных наборов, но уж в Сети - обязательно.
К чему я все это говорю? Да к тому, что, при всем внешнем различии дистрибутивов Linux (а при беглом сравнении, например, Linux Slackware и Linux Mandrake они кажутся просто разными операционными системами), общего между ними гораздо больше, чем особенного. И потому пользователь с равным успехом может использовать любой дистрибутив - из числа хорошо собранных, разумеется. Перефразируя графа нашего, пахаря: с каждым хорошим дистрибутивом пользователь будет счастлив одинаково, с каждым плохим - несчастлив по своему. Остается только отделить дистрибутивы хорошие от плохих. К счастью, подавляющее большинство известных мне дистрибутивов из числа распространенных (и даже - не очень распространенных) относится к первой категории. На отрицательных примерах я останавливаться не намерен, потому все упомянутые в этой книге дистрибутивы пользователь может числить в хороших (если прямо не оговорено иное).
К тому же обычно нет ни малейших препятствий к пересадке положительных особенностей одного дистрибутива на почву иного. И это проделывается не только сборщиками систем - но и индивидуальными пользователями. В результате любая Linux-система, каково бы ни было ее генетическое происхождение, в процессе эксплуатации все более индивидуализируется, становясь похожей скорее на своего пользователя, чем на своих родителей. "Дети похожи не на своих отцов, а на свое время" - эта арабская поговорка, при всей спорности касаемо человеков, приложима к дистрибутивам Linux (и к прочим свободным POSIX-системам) в полной мере...
Прояснив вопрос с дистрибутивами Linux, обратимся теперь к BSD-системам. Ибо понять их специфику лучше всего в сопоставлении (и противопоставлении) их Linux'у. Как, впрочем, и наоборот - в позапрошлом разделе мы видели, что понимание, что такое Linux, выкристаллизовывается именно в сравнении с BSD.
Для начала назовем наиболее распространенные BSD-системы. Это (хронологически) NetBSD, FreeBSD и OpenBSD (не считая коммерческой BSDi - впрочем, и распространена она мало, по крайней мере, я не слышал о ее пользователях на Руси). Они связаны общностью происхождения - от системы, именовавшейся BSD Unix, а в дальнейшем - X.XBSD, исторически позднейшая версия которой - 4.4BSD. От последней и происходят современные BSD-системы, Net- и FreeBSD - непосредственно, а OpenBSD - как отпочковавшаяся от NetBSD.
Впрочем, история BSD-систем - вопрос отдельный и очень. А в контексте сегодняшнего разговора подчеркну, что Free-, Net- и OpenBSD - это не подвиды одной системы, как дистрибутивы Linux, а именно самостоятельные ОС, каждая со своим ядром и базовым комплектом системных и пользовательских утилит. Хотя, парадоксальным образом, с точки зрения пользователя разницы между ними меньше, чем между Linux Slacware и Linux Mandrake, например.
Итак, первое: если многочисленные дистрибутивы Linux суть вариации на тему одной и той же ОС, то немногочисленные BSD-клоны - самостоятельные, хотя и родственные, операционки. И причина их обособления - ориентация на разные сферы применения.
Так, NetBSD испокон веков развивалась в русле классических традиций Unix (и POSIX) - как максимально независимая от платформы, переносимая система: трудно найти машины такой архитектуры, на которые эта операционка не была бы портирована, от антикварных, названия которых мало кто помнит, до новейших. Как говорят, для переноса NetBSD на машины с процессорами AMD64 потребовались считанные дни.
FreeBSD, напротив, возникла и долгое время развивалась с прицелом на оптимизацию под наиболее демократичную платформу - 32-разрядные Intel-совместимые процессоры. И возможностью работы на наиболее близких к ним, но 64-разрядных процессорах Alhpa. Безвременная кончина последней архитектуры сделала эту линию бесперспективной. Однако 64-разрядные наработки были аккумулированы во FreeBSD 5-й ветки, что способствовало росту ее мультиплатформенности: кроме 64-разрядных процессоров AMD и Intel, она в состоянии работать также на Sun Sparc. Тем не менее, именно ориентация на массовые Intel-совместимые процессоры (сиречь обычные PC'шки) и сделала FreeBSD наиболее распространенным представителем своего клана.
Наконец, конек OpenBSD - это безопасность в самом широком смысле слова. Качество, которое может оказаться востребованным в связи с массовой "интернетизаций" персоналок.
Вторая отличительная черта BSD-систем - монолитность. Если любой дистрибутив Linux являет собой более или менее тесную интеграцию ядра и базовых пакетов разного происхождения, то в каждом BSD-клоне ядро и комплекс средств его обеспечения представляют собой единое и (с некоторыми оговорками, о которых речь пойдет ниже) неделимое целое, не расчленяемое на кванты-пакеты. Базовый комплекс Net- и OpenBSD поставляется в виде единого тарбалла. А во FreeBSD он хотя и разбит на фрагменты по 1,44 Мбайт, но это сделано исключительно из соображений удобства скачивания и записи (наследие тех времен, когда операционную систему еще можно было установить целиком с дискет).
Из этого вытекает третья особенность BSD-систем - их внутренняя безальтернативность. Если в Linux, как уже говорилось, чуть ли не любому компоненту, кроме ядра, можно подобрать функциональный аналог, пользователь BSD привязан к тому комплекту, который идет с его ядром. Характерный пример - FreeBSD. Там переход с одной ветви на более новую (что эквивалентно смене версии ядра в Linux) требует полной пересборки базовой системы (механизм make world).
Монолитность базовой структуры BSD-систем отнюдь не означает, что пользователь должен в принудительном порядке держать на своей машине все ее компоненты, в том числе и заведомо ненужные. Просто для освобождения от балласта тут используются другие механизмы, например, списки исключений при выполнении процедуры make world.
И потому пользователь может индивидуализировать свою систему ничуть не в меньшей степени, чем при последовательной сборке Linux из исходников. В некоторых случаях это приводит к появлению разновидностей BSD-систем, формально напоминающих Linux-дистрибутивы. Известны такие производные FreeBSD, как PicoBSD (система на одной дискете, способная, тем не менее, выполнять функции не только сетевой станции, но даже Dial-Up сервера) или Frenzy - работающая с CD полнофункциональная система, предназначенная для сетевого администрирования.
Тем не менее, BSD-системы избежали сегментации по дистрибутивному принципу. Приведенные примеры, во-первых, крайне немногочисленны, во-вторых, имеют сугубо специальное назначение, в третьих, их развитие все равно остается в рамках генеральной линии FreeBSD.
Тем не менее, клонирование BSD-систем также иногда имеет место, только происходит оно иначе, чем в Linux. Разновидность какой-либо BSD-системы, удалившись от своего предка, превращается в самостоятельную ОС - со своим ядром и базовым комплексом программ. Выше я упоминал о отделении OpenBSD от родительской NetBSD. А уже OpenBSD, в свою очередь, не так давно послужила первоосновой системы ekkoBSD - своего рода аналога user-ориентированных дистрибутивов в Берклианском мире.
В наши дни мы присутствуем при начале расщепления FreeBSD - летом 2003 года от генеральной ее линии ответвилась система DragonFlyBSD. Говорить о ее полной самостоятельности еще рано, но если проект будет иметь успех, количество основных BSD-систем вполне может увеличиться на единицу.
Существует и другой путь размножения BSD-систем: вследствие цельности и сбалансированности базового комплекта их приложений последний подчас используется как инфраструктура, надстраивающая совершенно иные (не связанные генетически с 4.4BSD) ядра. В частности, микроядро Mach, разрабатывавшееся вплоть до второй половины 90-х годов университетами - сначала Карнеги-Меллона, а затем Юта.
Наиболее известный (и единственно работоспособный) пример такой надстройки - MacOS X и ее свободный отпрыск - Darwin. Однако в процессе вялотекущей разработки можно обнаружить еще несколько идеологически близких систем - xMach, похоже, прекративший развитие, и Yammit, на сайте проекта которого иногда фиксируются обновления (см. каталог BSD-ресурсов).
Есть случаи и иного подхода - перенос инфраструктуры Linux на ядро какого-либо BSD-клона. И тут на память приходят амбициозные проекты Debian - Debian GNU/FreeBSD (причем сразу в двух вариантах) и Debian GNU/NetBSD. И, наконец, к этой же категории примыкает попытка переноса системы портежей Gentoo на ядро и системное окружение FreeBSD - взамен ее собственной системы портов (каковая в свое время послужила прототипом портежей).
Однако следует повторить - на взгляд со стороны пользователя сегментация внутри Берклианского мира существенно меньше, чем дивергенция дистрибутивов Linux. Все боковые BSD-ответвления (типа того же ekkoBSD) на сегодняшний день могут рассматриваться как сугубо экспериментальные проекты - думаю, и сами их разработчики не надеются на всеобщее признание и широкое распространение. А упоминаю я об этих проектах по следующим причинам. Во-первых, чтобы показать, что мир BSD не столь однообразен, как это может показаться на первый взгляд. Представление о многообразии его можно получить из взгляда на каталог BSD-ресурсов.
А во-вторых, все эти экспериментальные проекты, вне зависимости от их успешности, отрабатывают какие-либо новые варианты, рациональная составляющая которых будет, несомненно, аккумулирована в операционках основной линии развития.
Вообще, взаимовлияние систем внутри BSD-клана - тоже отличительная его особенность. Удачные решения одной из ОС очень быстро распространяются среди ее сородичей. Пример - система портов FreeBSD, заимствованная в OpenBSD с самого начала, а в дальнейшем (в виде системы pkgsrc) распространившаяся и на NetBSD. С другой стороны, многие отличительные особенности 5-й ветки FreeBSD, напротив, уходят своими корнями в NetBSD (и даже в коммерческую BSDi).
Так что мир BSD-систем в значительной мере сохраняет свое идеологическое единство. Более того, его влияние распространяется и на Linux: выше я неоднократно подчеркивал, что Source Based дистрибутивы Linux в значительной мере основываются на идейном наследии FreeBSD.
Все сказанное в предыдущем разделе не имеет целью доказать преимущества BSD-систем над Linux (впрочем, как и противоположное утверждение): споры такого характера я полагаю беспредметными. Просто я хотел подчеркнуть, что а) Linux'ом мир свободных POSIX-систем не исчерпывается, б) все они находятся в постоянном взаимодействии друг с другом, и в) понимание особенностей BSD-систем может способствовать более глубокому освоению Linux'а, и наоборот. А уж что выбрать для личного употребления - дело целей, задач, обстоятельств, а может быть, даже и вкуса.
Вообще проблема выбора первой системы - широка и многогранна, и потому будет детально рассмотрена позже. Я постараюсь обосновать, почему именно FreeBSD, наряду с парой-тройкой дистрибутивов Linux, из которых оптимальным представляется мне Archlinux, видятся мне самыми благоприятными объектами для изучения POSIX-систем вообще. Но, повторяю, это - не более, чем мое личное мнение. Если после прочтения этих страниц вы сможете сформировать свой собственный взгляд на этот вопрос - одну из целей своего сочинения я буду считать достигнутой.
А в завершение вводной части следует остановиться на вопросе, как же POSIX-системы дошли до жизни такой. Для чего придется погрузиться в глубины истории, подобно тому, как это сделал Гэндальф, расследуя происхождение Кольца Всевластия...