Открытость, свобода и халява

Предметом всего дальнейшего изложения будут почти исключительно операционные системы, их утилиты и приложения, относимые к категориям программ открытых (Open Sources - буквально программы с открытыми исходными текстами) и свободных (Free Software, что в данном контексте имеет значение "свободно распространяемые").

Грани открытости

Во вступлении к этой главе я упомянул о так называемых открытых системах (Open Systems) - понятии, семантически близком к термину Open Sources Software. И тем не менее, понятия эти - разные, и в принципе между собой не связаны. Потому что под открытой системой понимается просто-напросто "система, которая состоит из компонентов, взаимодействующих друг с другом через стандартные интерфейсы" (Жан-Мишель Корну, один из авторов руководства Французской ассоциации пользователей UNIX; цитировано по: С. Д. Кузнецов Операционная система UNIX).

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

Стандартные интерфейсы для открытых систем регламентируются набором соглашений POSIX (Portable Operating System Interface), разрабатываемые двумя организациями - IEEE (Institute of Electrical and Electronics Engineers, Inc.) и Open Group. Соглашения эти, получившие звучный титул стандартов POSIX, опирались в первую очередь на опыт разработки систем Unix. И. следовательно, все Unix-подобные системы, как проприетарные (Solaris, например, или AIX), так и свободные (Linux или FreeBSD) по определению являются POSIX-совместимыми, представляя собой конкретные реализации соответствующих стандартов.

Собственно, термины "Unix-подобная ОС" и "POSIX-совместимая ОС" можно было бы рассматривать в качестве синонимов. И на протяжении всего данного сочинения я так и делаю. Тут, однако, нужно иметь ввиду несколько обстоятельств.

Во-первых, термин "Unix" представляет собой зарегистрированную торговую марку. И продолжающееся по сей день крестоносное сутяжничество SCO против IBM (и попутно - против всего движения Open Sources и Free Software), исход которого остается неясным, в немалой степени будет способствовать его дискредитации.
Имея в своем осадке лишь тот положительный момент, что очередной раз привлекло внимание к понятию Open Systems как системам, следующим открытым (то есть общедоступным) стандартам. Достаточно вспомнить попытку демонстрации "украденного" из Unix кода в Linux-ядре.

Во-вторых же, и главных, понятие POSIX-совместимости, строго говоря, выходит за рамки Unix-подобия, то есть сходства с неким первозданным Unix'ом. В той или иной мере соответствие POSIX-стандартам (хотя и неполное) признается разработчиками ОС QNX, генетически с Unix никак не связанной. Да и Linux представляет собой попытку воспроизведения функциональности Unix с "чистого листа", не только без использования ее кода, но и без доступа к нему. При этом Линус опирался не столько на устройство самой системы Unix, сколько именно на стандарты POSIX. Впрочем, подробнее об этом будет говориться в .

Следует заметить, что и для Windows линии NT/2000/XP декларируется соответствие стандартам POSIX. Однако, как это в обычае у фирмы-разработчика этих продуктов, стандарты эти понимаются тут весьма своеобразно и трактуются весьма расширительно в плане "улучшения". А потому отнесение Windows к POSIX-совместимым системам по меньшей мере спорно.

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

Однако открытость основополагающих стандартов ни в коей мере не подразумевает открытости созданных в соответствие с ними операционных систем. И само по себе соответствие POSIX-стандартам не влечет их свободного (тем более - бесплатного) распространения. Кратко говоря, под Open Systems, в отличие от Open Sources, можно понимать просто системы, основанные на открытых (=общедоступных) стандартах.А уж на каких условиях эти системы распространяются - определяется лицензиями, которые вольно было приписать им разработчиками.

Истоки Free Software

И тут можно сделать интересное наблюдение: большинство т.н. "университетских" лицензий по своей сути тяготеют к формулировкам BSD-стиля. Почему?

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

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

Не случайно первые работы над проектом BSD, полностью вписывающиеся в идеологию Free Software, начались существенно (лет за 10) раньше того, как Столлмен сформулировал свои знаменитые принципы в 1984 году.

Аналогию между научными разработками и Free Software можно углубить. Что является неотъемлемым атрибутом профессионально выполненной научной работы? Тем самым, который безошибочно позволяет отделить всамделишнюю, скажем, геологию или историю от трудов всякого рода атлантологов, уфологов и прочей "фоменковщины"? Атрибутом этим является научный аппарат. То есть для наук экспериментальных - публикация методики измерений, позволяющих независимое воспроизведение результатов; для наук феноменологических, типа той же геологии - описания полевых наблюдений; для истории иже с нею - ссылочного аппарата (дающего читателю теоретическую возможность порыться в первоисточниках).

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

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

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

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

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

Показательно, что все успешные проекты, некогда коммерческие, но подвергшиеся процедуре открытия исходников на определенных, не вполне соответствующих GPL- или BSD-лицензиям, условиях, рано или поздно эволюционировали в сторону полной свободы в понимании Free Software. Здесь достаточно вспомнить StarOffice, Netscape или GRASS. Причем характерно, что на базе одного и того же открытого кода вполне мирно уживаются как полностью свободные программы (OpenOffice.org, Mozilla или многочисленные Gecko-клоны), так и программы, сохранившие свой проприетарный статус (первозданные StarOffice и Netscape). Программы же с открытыми исходниками, не ставшие истинно свободными (например, Solaris или True64 Unix), очень быстро потеряли и свой открытый статус, вернувшись в лоно проприетаризма.

Как же заработать на Open Sources?

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

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

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

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

Реально ли это? Мой личный опыт показывает - более чем. Может ли это выполнить каждый отдельно взятый пользователь (не имеющий, напомню, специального образования и специфических навыков) на отдельно стоящем персональном компьютере? Теоретически - ну конечно же, может.
Для этого только что и нужно, как прочитать несколько толстых книжек по Linux и, особенно, Unix (объемом в какие-нибудь тысячу с небольшим страниц каждая), пару сотенок мануальников и HOW-TO'ев (с побочной пользой - практикой в английском), научиться сочинять простенькие шелл-скрипты и макросы для текстового редактора, ну и освоить еще несколько мелких дел.

Правда, возникает вопрос - а когда этот пользователь будет заниматься своей непосредственной работой? Ну, это - его личное дело ("Меньше спите. Или больше работайте" - как сказал персонаж из "Территории" Олега Куваева). Главная загвоздка тут в другом: в один далеко не прекрасный день такой пользователь с ужасом обнаруживает, что копаться в конфигах или разбираться с опциями компилятора для него стало интереснее, чем переводить контракты, подводить квартальные балансы или даже вычислять P/T-условия выплавления базальтовых магм.

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

И вот тут наступает Час POSIX'ивиста. Именно его может позвать наш бухгалтер/переводчик/геолог для оборудования своего рабочего места. Которое будет включать в себя не просто установку системы, а полный комплекс по ее обработке (рашпилем там, или алмазным надфилем - это уже зависит от задач и субстрата, сиречь исходного дистрибутива). Причем в той степени, какая потребуется, чтобы избавить пользователя от необходимости приобретать хоть какие-то знания о внутреннем устройстве системы.

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


перечисленное выше). Отвечаю: именно в POSIX- системе такое возможно. Потому что обычно индивидуальный пользователь ее - не просто пользователь, но и сам себе админ. То есть он вынужден устанавливать и настраивать систему, устанавливать и обновлять прикладной софт, и так далее.

Здесь же речь идет о создании некоего комплекса, того, что именовалось на заре советской компьютеризации Автоматизированным Рабочим Местом - АРМом бухгалтера, переводчика, геолога. То есть - монофункциональной системы с сознательно урезанными до необходимого уровня возможностями. Пользователь такой системы не должен в сущности даже иметь root-акаунта: все, что от него требуется - это уметь включить питание, элементарным нажатием двух-трех клавиш запустить пару-тройку приложений или утилит с требуемыми опциями (а создание скриптов, обеспечивающих такую возможность - одна из задач нашего POSIX'ивиста) и выйти с сохранением данных и корректным завершением сеанса (например, по нажатию сакраментальной комбинации из трех пальцев, а уж о корректности всего остального должен позаботиться POSIX'ивист).

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

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


Именно по такой схеме начиналась всеобщая PC'фикация всей страны (тогда еще - Советов). То есть: IBM PC/XT с "черным" DOS'ом (необходимости в NC "по делу" - не возникает) и программой бухучета (или там учета кадров), запускаемой batch-файлом, вызываемым нажатием клавиши Any Key:-). Правда, реализация этого, как правило, оставлял желать лучшего, но речь сейчас - об идее. И представьте, как это может быть реализовано на базе современного "железа" - раз, и с полной возможностью лишить пользователя возможности (пардон за тавтологию) совершить потенциально опасное действие в принципе - два.

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

Скорее всего, не очень. Потому что вопрос этот адресован не ко мне. И упирается в повышение материального благосостояния советского (пардон, российского) гражданина - а тут уже Unix way бессилен. Однако...

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

совершенно другие масштабы - это понятно;

совершенно другие объемы кропотливой ручной работы - ведь АРМы для ста банковских операционисток, выполняющих одинаковую работу, будут практически идентичными, и достаточно отрихтовать руками один экземпляр;

совершенно иные условия работы - ведь все эти сто АРМов можно единовременно инсталлировать по локалке;

и, как следствие совершенно иные соотношения трудозатрат/трудоооплат.



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

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

Тем не менее, у него есть свобода выбора другого - заниматься созданием собственного АРМа самому или предоставить это дело тому, кто может это осуществить по уровню знаний и должностной инструкции, то есть тому же нашему POSIX'ивисту. А вот у последнего эта самая свобода выбора сохраняется в полном объеме - и, более того, он имеет не только право, но и реальную возможность ею воспользоваться.

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

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

Кое-что о лицензиях

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

Наиболее известна General Public License (сокращенно GPL) - оставим название без перевода, поскольку смысл английского оригинала интуитивно более понятен, чем любой отечественный эквивалент. Созданная в первоначальном своем варианте Столлменом (при участии профессиональных юристов), она ныне принята для Free Software, разрабатываемого в рамках проекта GNU и при участии FSF. Кроме того, по ее условиям распространяется ядро Linux и множество программ независимых разработчиков.

В двух словах суть GPL повторяет, понятное дело, общие принципы свободы Столлмена, с одним важным дополнением: любое программное обеспечение, разработанное на базе GPL-софта, может распространяться только в сопровождении открытых исходных текстов и под той же лицензией. То есть разработчик, включивший в свое творение хоть строку кода, подпадающего под GPL, не имеет права распространять его под какой-либо другой лицензией. Хотя, повторю еще раз, никаких иных ограничений - ни в плане взимания денег, ни какого-либо иного коммерческого использования, - на него не накладывается. А под сопровождением открытыми исходниками подразумевается их физическая доступность - на твердых ли носителях, на публичных ftp-серверах, и так далее.

Лицензия GPL вызывает наибольшие споры в мире Open Sources - от почитания единственно пригодной для распространения свободного софта до активного неприятия, вплоть до появления термина "вирус GPL". Однако мы в эти споры вдаваться не будем - отметим только, что она являет собой объективную реальность, и что под ней распространяется огромное количество программ - от утилит GNU-проекта до таких крупных продуктов, как ядро Linux, GIMP, GNOME, ГИС GRASS и множество других.
В общем, вероятно, суммарно много большее, чем под всеми прочими свободными лицензиями, вместе взятыми.

Вследствие уже отмеченной аберрации, FSF не просто тесно ассоциируется с самим понятием Free Software, но подчас, осознанно или неосознанно, с ним отождествляется. Однако это не так, и GPL - далеко не единственная лицензия, под которой свободный софт распространяется. Ибо на другом полюсе свободы софта располагается BSD-лицензия, впервые сформулированная в Университете Беркли для распространения системы, именовавшейся в те годы BSD Unix. Ныне под этой лицензией распространяются такие ОС, как Free-, Net- и OpenBSD, все их производные (типа DragonFly), а также изрядное количество программ независимых разработчиков.

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

Чтобы понять, как это выглядит в реальности, рассмотрим наиболее показательный пример. Как известно, MacOS X основана на микроядре Mach (разработанном в Университете Карнеги-Меллона и распространяемом под собственной лицензией BSD-стиля) и системном окружении, заимствованном из FreeBSD, что в совокупности и дает ее ядро Darwin. Поскольку и ядро Mach, и его системное окружение суть свободные программы, то и Darwin имеет тот же статус, распространяясь открыто и свободно (его можно скачать и пользовать из командной строки в свое удовольствие).


Однако графический интерфейс пользователя и прочие прибамбасы, которые собственно и определяют своеобразие MacOS X, являют собой собственные разработки Apple, и об их свободном распространении речи не идет.

Из прочих свободных лицензий известны: лицензия X-консорциума, близкая к ней - Массачуссетского технологического института (MIT) и лицензия, под которой распространяется Mozilla, а также серия "университетских" лицензий. Все они, приближаясь либо к GPL, либо к BSD-стилю, в полной мере отвечают принципам Столлмена. Не случайно самые строгие пуристы от FSF именуют их GPL-совместимыми. Что на практике означает возможность использования софта под этими лицензиями в рамках единых проектов.

Таким образом, многоликость явления Free Software находит отражение в многообразии лицензий, под которыми свободный софт распространяется. Что, однако, не мешает им мирно уживаться друг с другом: так, базовый комплект FreeBSD (т.н. Distributions), подпадающий в основном под BSD-лицензию, включает в себя ряд компонентов проекта GNU, защищаемых лицензией GPL, и называемых Contributions (в их числе такой важный, как компилятор gcc). А базовая система Linux, большая часть которой представлена GPL-программами, включает, например, библиотеку zlib, распространяемую на условиях лицензии BSD-стиля.

Более того, свободные лицензии вполне могут сосуществовать и с коммерческими, ярким примером чему является интегрированная среда KDE. Она основана на библиотеке Qt, которая сама по себе является коммерческой (и стоит, надо заметить, немалых денег). Однако для некоммерческого использования она бесплатна и как бы свободна, распространяясь на условиях близкой к GPL лицензии - QPL. Не возьмусь судить о том, как это реализовано юридически, однако факт остается фактом: на библиотеке Qt разрабатываются и такие проприетарные программы, как браузер Opera (а это, не смотря на бесплатность при некоторых условиях, - все же коммерческий продукт), или Safari - штатный браузер коммерческой MacOS X, так и KDE с ее приложениями, к чистоте и свободе лицензии которой ныне не осталось претензий у самых ярых апологетов FSF.

Вернемся, однако, к свободным лицензиям. Как уже было сказано, все их многообразие укладывается на линию GPL-BSD. Первая однозначно требует,чтобы все программы, включающие в себя свободный код, оставались свободными ныне, и присно, и во веки веков. Вторая же столь же однозначно разрешает закрытое распространение собственных разработок, пусть даже и основанных на свободном коде (хотя, повторяю, легший в основу свободный код таковым все равно остается ad finem seculorum).

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

Кто оплачивает банкет?

Мой снобизм - он как лучик путеводный,

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

Он худой, но гордый, он - художник.

Тимур Шаов

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

Должно, однако, для начала заметить, что родственность Open Sources и фундаментальной науки - не мое изобретение. Блестящее обоснование этого тезиса содержится в статье: Николай Безруков. Разработка программ с открытыми исходниками как особый вид научных исследований. Byte Россия, 2000, #5 (21), с. 64-77. К сожалению, столь древний номер журнала успел, видимо, стать библиографической редкостью, но есть и онлайновая версия.

У читателя большей части популярных публикаций на тему Open Sources вполне может создастся впечатление, что разработка программ этого класса осуществляется на голом энтузиазме, напоминающем ударников-стахановцев и прочих строителей Магнитки. Что, конечно, очень бла-а-родно, но в наш коммерциализованный век вызывает законное недоверие (особенно с учетом аналогии строителей Магнитки и БАМа - забайкальских комсомольцев).

Проблема финансирования Open Sources включает в себя три аспекта:

кто может быть заинтересован (и может ли?) в финансировании разработки Open Sources;

в какой форме заинтересованные стороны могут осуществлять финансирование разработки Open Sources;

каким образом финансирование это может распределяться среди разработчиков.

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

Но сначала зададимся иным вопросом: а нужно ли финансирование разработки программ с открытыми исходниками вообще? Ведь теоретически предполагается, что это - предприятие самоокупаемое, а то и просто прибыльное.
Однако теоретически, как говаривал дед Щукарь, она лошадь, а практически она падает...

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

Прибыльность разработки Open Sources обычно обосновывается туманными фразами о сопровождении и поддержке программных продуктов, распространяемых бесплатно. В смысле - по себестоимости носителей и документации. Когда в отрицание бесплатности открытого софта приводят американские цены на дистрибутивы типа Red Hat или Suse, забывают, что 100- (или даже 200-) долларовые их коробки содержат штук пять-шесть изрядной толщины книжек. А в Америке любая специальная книжка меньше полтинника ихних денег, насколько я знаю, сама по себе не стоит. Если же речь идет о дистрибутивах ценой в несколько тысяч долларов - то тут уже в стоимость включено именно сопровождение продукта в явном виде,

Тем не менее, достоверных известий о фирмах или персонах, обогатившихся за счет массовой техподдержки Open Sources, у меня нет. Что понятно: люди, покупающие дистрибутив Linux (для примера), имеют целью разобраться в системе. И либо этой цели достигают, и тогда в техподдержке не нуждаются. Либо бросают это занятие, и тогда не нуждаются в поддержке тем более. Если же речь идет о корпоративных пользователях - не думаю, что разумный руководитель рискнет перевести весь свой документооборот на Linux или BSD, не имея в штате квалифицированного специалиста по одной из этих систем. Так что мечты о заработке на техподдержке - столь же наивны, как и мечты о самоокупаемости фундаментальной науки, блестяще-утопично сформулированные на заре перестройки Максимом Максимовым в статье "Реанимация" (Знание-сила, 1989, #11).



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

А пока: кто заинтересован в развитии Open Sources и, соответственно, мог бы финансировать его разработку? Кроме его разработчиков и пользователей, разумеется. Но ведь разработчики Open Sources, хотя и заняты своим делом в большой степени из любви к искусству, также хотят есть-пить. А пользователи - они ведь пользуют Open Sources в значительной мере в виду его бесплатности, практической или теоретической. Что удовлетворению означенной потребности разработчиков отнюдь не способствует...

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

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

Молодому человеку, сызмальства привыкшему к Linux (FreeBSD, OpenBSD etc.) и пришедшему на службу со школьной (или университетской) скамьи, работать в Windows - что серпом по... сами знаете чему. Гораздо легче ему будет перейти на Solaris или AIX. А достигнув по службе должного положения, он, безусловно, приложит все усилия к тому, чтобы внедрить POSIX-системы в родном трудовом коллективе - ведь, по тем или иным причинам, далеко не всегда можно обойтись свободными их реализациями.

За иллюстрацией этого достаточно спуститься в не столь уж далекое прошлое - 1995 год. Когда (не заставшим того времени поверить в это трудно - но факт имел место быть) в качестве реальной альтернативы для массовых настольных систем рассматривались OS/2 и Windows 95.


Причем ни у кого не вызывало сомнений технологическое превосходство первой. Но: Windows 95 пришла в дома, а OS/2 - нет (о причинах распространяться здесь неуместно). И через несколько лет на работу вышло поколение, вскормленное и вспоенное в "окнах". Результат не замедлил воспоследовать: кто и когда последний раз видел OS/2 на пользовательском десктопе?

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

Теперь посмотрим, горят ли заинтересованные стороны желанием оказать развитию Open Sources посильную финансовую помощь?

Конечно, странно было бы ожидать от массы Windows-пользователей благотворительных пожертвований в FSF и аналогичные dot-org'и (а для последних это нередко - существенный источник финансирования, примером тому проект OpenBSD). Тем не менее наиболее продвинутая часть их косвенно в финансировании Open Sources участвует. Хотя бы тем, что проявляет интерес к публикациям на эту тему - и бумажным, и сетевым. В результате чего компьютерные издания печатают больше статей соответствующего профиля, регулярно выплачивая авторам гонорары, чем и способствуют материальному благополучию писателей-POSIX'ивистов (навроде вашего покорного слуги:-)).

Теперь о корпорациях - производителях Unix-машин и разработчиках проприетарных версий Unix и софта для них. Об инвестициях IBM в Linux-компании знают, наверное, все. Однако это лишь одна сторона дела. Меньшее внимание привлекает то, что, скажем, изрядное количество разработчиков свободного браузера Mozilla (из некоторых источников явствует, что - большинство) по совместительству являются штатными сотрудниками AOL (хотя скорее - наоборот) и работают над проприетарным (хотя и бесплатным, но не свободным) браузером Netscape.


А команды разработчиков свободного офисного пакета OpenOffice и проприетарного - StarOffice, суть множества пересекающиеся (не знаю уж, насколько точно, но очень значительно). Ну и недавнее приобретение Suse Linux компанией Novell (до некоторого времени правообладателя торговой марки Unix) - также факт показательный.

И, наконец, государство. О прямом госбюджетном финансировании разработки свободного софта в большинстве стран, как будто бы, слышно не очень много. Кроме, разве что, Китая, где курс на внедрение открытого и свободного софта - прямо-таки генеральная линия Партии и Правительства. Проскальзывает информация о господдержке Linux (в сфере наробраза, например) в паре-тройке стран Латинской Америки (Мексика, Бразилия). Ну и есть сведения, что французская компания Mandrakesoft (производитель одноименного дистрибутива Linux) была некогда выведена из затянувшегося кризиса благодаря правительственным ассигнованиям.

Это - с одной стороны, Однако - вспомним, что BSD (предок свободных операционок Free-, Net- и OpenBSD) почти полтора десятка лет разрабатывалась в Университете Беркли. На денежки, между прочим, оборонного ведомства США - то есть прямого госбюджета.

Или - история финского студента Линуса Торвальдса. Который благополучно проучился (а потом и проработал) в университете лет семь, за которые свой Linux и разработал. А ведь высшее образование в Финляндии, насколько мне известно, бесплатное - сиречь финансируемое из госбюджета. Так что можно сказать, что Linux был создан за счет финской казны (и финских же налогоплательщиков; также как FreeBSD - за счет налогоплательщиков американских).

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



Значит ли это, что движение Open Sources имеет достаточную финансовую базу? Отнюдь. Государственные программы имеют обыкновение рано или поздно заканчиваться по самым разным причинам. (Не с падением ли мировой системы социализма связано прекращение финансирования проекта BSD в 1991 году?). Вливания от коммерческих фирм зависят от конъюнктуры рынка. А интерес широких народных масс ко всему, связанному с Linux и Open Sources, в значительной мере лишь дань моде.

Так что какие-либо дополнительные источники финансирования не помешали бы движению Open Sources. Однако уже упоминавшаяся аналогия между ним и фундаментальной наукой наводит меня на мысль: а пойдут ли они ему на пользу? Ибо второй вопрос после получения финансирования - как это финансирование будет распределяться среди собственно разработчиков?

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

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

К слову сказать - модель эта минимум однажды эффективно сработала и в мире открытых исходников. Не напоминает ли вам положение Линуса в компании Transmeta то, в котором оказался Титиан Папскою милостью, или товарищ Курчатов - волею гения всех времен и народов?

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


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

Хотя и для этой модели есть примеры удачного использования в истории движения Free Software - разработка систем линии BSD 4.X в Университете Беркли.

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

История показала, что эта модель, пожалуй, наиболее эффективна. Она прекрасно сработала в случае FreeBSD и Linux Slackware. И тот, и другой проект долгое время развивался при поддержки компании Walnut Creek - известного продавца компакт-дисков (а потом и дистрибутивов). Доход от продажи дистрибутивов (плюс разнообразной атрибутики - маечек, кружечек etc.), насколько мне известно, - один из основных источников финансирования проекта OpenBSD. Ну и для компаний, собирающих дистрибутивы Linux (типа Red Hat и Suse), это - также некоторое подспорье.

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

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

Можно ли заработать на Open Sources?

И здесь мне хотелось бы начать с цитаты из статьи Владимира Попова Размышления на тему Open Sources Way:

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

Возникает вопрос - а приложим ли этот критерий собственно к открытому программному обеспечению? Что особенно актуально в свете все более частых попыток "Заработать на Open Sources". Конечно, само слово "заработать" в этом контексте имеет двойной смысл - но к этому я еще вернусь в конце. А пока все же попробую ответит на свой вопрос. Для чего, несколько забегая вперед, придется обратиться к истории (каковая послужит предметом ).

С чего началась дорога, получившая потом название Unix-way? Как всем известно, началась она с проекта Multics. Что это было такое? Это была совместная разработка Bell Labs, General Electric и Массачуссетского технологического института (MIT). То есть - вполне академический проект. Где работали основоположники Unix? Работали они в той же Bell Labs, хотя и принадлежащей коммерческой компании, но имевшей целью все же научные разработки. А кто сказал, что научная работа не может финансироваться частным капиталом? Только не те, кому посчастливилось получить Нобелевскую премию.

Дальше - больше. Чей вклад в становление Unix в современном его виде был наиболее весом (после его основоположников, конечно же)? Университета Беркли, штат Калифорния. Кем был Ричард Столлмен до того, как он начал свой крестовый поход за освобождение гроба Господня (то есть, пардон, за свободу софта)? Был он, как известно, научным сотрудников в лаборатории искусственного интеллекта в том же MIT. Чем занимался Энди Танненбаум, создатель Minix - системы, вдохновившей Линуса Торвальдса на его бренный труд по написанию терминальной программки? А занимался Энди преподаванием а Амстердамском университете. Да и Minix свой написал он, собственно говоря, для того, чтобы обучать скубентов основам Unix.

Наконец, кем был сам Линус Торвальдс в то время, когда его терминальная программа медленно, но верно превращалась в операционную систему? Был он студентом, а потом научным сотрудником университета в Хельсинки. И число таких примеров можно умножить до бесконечности.

Из всего сказанного можно сделать вывод: создание Unix как открытой (в смысле - соответствующей открытым стандартам) системы и ее производных, представленных открытым и свободным софтом во всех его проявлениях, происходило практически полностью в сугубо академической среде. А если вспомнить о том, что вся софтверная индустрия базируется, в сущности, на математических алгоритмах, развивавшихся в рамках "чистой" математики со времен Евклида и Бируни, становится окончательно ясно: Unix-way и Open Sources есть порождение той области человеческой деятельности, которую именуют "чистой" или фундаментальной наукой. Впрочем, задолго до меня к тому же выводу пришел Николай Безруков в упоминавшейся выше статье.

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

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

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


А уж посредством чего и кого эта оплата осуществляется - вопрос другой.

Мы уже видели, что посредником в оплате научной работы может быть государство в целом или отдельные государственные ведомства. Это могут быть корпорации - ведь компании типа AT&T или IBM суть не что иное, чем социальные объединения, превосходящие по масштабам несредние даже государства. И, наконец, общество (или отдельные, наиболее прогрессивные, его представители) могут выступать финансистами научных работ и непосредственно - в виде пожертвований.

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

Так что зарабатывать на кусок хлеба своей работой на ниве Open Sources вполне можно (правда, боюсь, не в нашей стране). А вот может ли быть открытый софт объектом предпринимательской деятельности? То есть - служить для извлечения прибыли. Здесь однозначный ответ дать трудно.

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


Как тут обстоит дело с прибыльностью?

Очевидно, что норма прибыли при тиражировании свободных программ стремится к нулю. Ведь себестоимость носителей практически нулевая, сами программы - общедоступны, и наварить здесь практически невозможно. Вспомним пример из книги Линуса - когда стоимость завоза воды превышает допустимый пользователями уровень, кто-нибудь обязательно протянет водопровод. Так что единственное, что тут остается - это пытаться компенсировать норму прибыли ее массой. То есть - объемом продаж. А объем этот напрямую связан с количеством пользователей Open Sources. Причем - в первую очередь пользователей-индивидуалов - в силу специфики свободных лицензий компания уже в 100 человек вполне может наладить тиражирование своими силами и в потребных масштабах, - а их за десктопами отнюдь не большинство. Так что и места под солнцем для Linux-предпринимателей оказывается не так много.

И тут тиражирование тесно смыкается с обучением - поскольку существовать без него не может. А под обучением я понимаю не только (и даже не столько) всякого рода сертифицированные курсы, сколько - самую элементарную печатную документацию. Ведь каждому, кто видел в книжном магазине США или Европы научные монографии, становится ясным: цена коробочных дистрибутивов Red Hat или Suse на 90% состоит из стоимости сопутствующей полиграфии. То есть компании-распространители дистрибутивов - это не столько разработчики программного обеспечения, сколько - издатели оного (и сопутствующей продукции). И структура их доходов в этой части оказывается такой же, как у любого книжного издательства.

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



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

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

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

Это я не к тому, что поддержка Linux - дело бесперспективное. Хочу лишь подчеркнуть, что сфера эта столь же ограничена, как и область тиражирования/обучения. А с распространением Linux к тому же будет все менее рентабельной.

Все ли так мрачно в области коммерческого использования Open Sources? Не совсем, потому что есть еще и четвертый способ извлечения прибыли из оного, причем - находящийся на грани с зарабатыванием денег в первом смысле этого слова. Однако о нем я буду говорить в следующем параграфе.

О продолжении банкета

Руины прекративших свое развитие открытых проектов на просторах Интернета служат свидетельством недостаточного финансирования разработки свободного софта.

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

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

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

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

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

И ладно бы, что второй путь противоречит всей идеологии Unix (тому, что называют Unix Way). Но ведь порочность его доказана практикой - всей историей проприетарного софта. Производители которого неизбежно вынуждены расширять, с позволения сказать, функциональность своих продуктов. Ведь как иначе убедить в необходимости покупки Office 2003 пользователя (которому зачастую вдоль хватило бы возможностей Lexicon'а), как не открывающимся перед ним сказочным богатством функций? За которые приходится расплачиваться гигагерцами и гигабайтами железа, монстроидальностью интерфейса и в конечном счете снижением общей производительности работы...

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

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

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

Постановка вопроса

Понятия программ открытых (Open Sources) и свободных программ (Free Software) близки как по букве, так и по духу, но не идентичны, ибо сосуществуют как бы в разных, хотя и пересекающихся, плоскостях. Кроме того, и то, и другое явление тесно соприкасается с понятием открытых систем (Open Systems).

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

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

Сразу оговорюсь, что все, описанное далее в этом разделе, основано на документах движений Open Sources и Free Software Foundation (далее FSF), а также публичных высказываниях их лидеров. Однако я излагаю свое понимание предмета, которое отнюдь не обязано совпадать ни с одним из первоисточников. Каковые, не будучи марксизмом, являются не догмой - руководством, и не столько к действию, сколько к размышлению.

Степени свободы

Начнем с понятия Open Sources Software, как наиболее, с моей точки зрения, общего. Это в первую очередь термин чисто технический, и применяется к программам, чьи исходные тексты принципиально общедоступны без дизассемблирования и прочих "хакерских" приемов. Подчеркну - принципиально, ибо форма доступа к исходникам может быть самой разной: платной или бесплатной, безусловной или с соблюдением определенных условий (например, дальнейшего нераспространения или некоммерческого использования). Смысл же общедоступности - в том, что любой человек, придя с улицы и, возможно, выполнив указанные условия (заплатив деньги, или согласившись с ограничениями на распространение), получает исходные тексты данной программы.

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

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

Таким образом, понятием Open Sources определяется первая степень свободы - свободы изучения исходников. Рискуя повториться, подчеркну: отрытые исходники сами по себе не подразумевают ни свободы распространения, ни бесплатности оного. Хотя с первой связаны почти неразрывно. Свидетельством тому судьба всех проектов, исходники которых открывались: либо они становились истинно свободными, либо - закрывались обратно.

Вторая степень свободы определяется понятием свободного софта - Free Software, что не следует путать ни с Freeware, ни с Free Software Foundation, о котором я скажу попозже. Это понятие - более узкое, нежели Open Sources Software, и охватывает аспекты использования и распространения программ. Оно базируется на знаменитых принципах свободного софта, сформулированных Ричардом Столлменом (Richard M. Stollman, известный в миру как RMS), основоположником движения за свободный софт вообще и FSF (Free Software Foundation - организация движения за открытые исходники) в частности: свободе использования, свободе изучения и модификации, свободе распространения.

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


ящик стола, прибить на стенку или использовать в качестве подставки под пивную кружку.

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

Наконец, свобода распространения относится уже не к правам на экземпляр программы, а к условиям ее тиражирования. То есть пользователь имеет право копировать программу Free Software и распространять ее любым угодным ему способом: раздавать в переходе метро, или продавать, причем - за любые деньги, в которые он оценит свои усилия по тиражированию, амортизацию своего оборудования и прочие накладные расходы. Разумеется, в рамках действующего по сему поводу законодательства данной страны - но к программному обеспечению, как таковому, это отношения уже не имеет.

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

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



А где же здесь бесплатность (в смысле халявы), резонно спросите вы меня? А нигде, столь же резонно отвечу я вам. Потому что ни понятие Open Sources, ни понятие Free Software к понятию халявы никакого отношения не имеют. Каким бы способом вы ни приобретали свободную программу, вам придется заплатить: за трафик при получении по Сети, за носитель, его оформление и доставку при покупке на CD, за полиграфию упаковки и печатной документации при покупке коробочной версии, и так далее. Включая оплату накладных расходов распространителя (вплоть до, возможно, даже его затрат на рекламу). Короче говоря, за все то же, за что вы платите при покупке бутылки пива или автомобиля.

Другое дело, что при покупке Free Software вы платите только за это - и ни копейкой больше. Ни о какой оплате мифической интеллектуальной собственности речи быть не может. Даже в том случае, если распространитель продает собственный (или собственноручно доработанный) продукт.

И потому часто встречающееся сравнение типа: "копия Windows стоит (всего) 100 баксов, а дистрибутив Linux можно найти и за (ажно) 5 тысяч оных" - мягко говоря, некорректно. Потому что при покупке Windows иже с ним, даже на CD из коробки, вы приобретаете не товар, а право на его использование, ограниченное теми условиями, какие заблагорассудится поставить разработчику. Конечно, ваше право - принять их или не принять (т.н. договор присоединения). Но во втором случае право на использование вами теряется.

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



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

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

Еще одно отступление: по моим наблюдениям, статус Freeware в большинстве случаев - сугубо временный, чем-то эти программы сродни товарам, приобретенным на рекламных распродажах и тому подобных акциях. Очень мало разработчиков принципиально декларируют Freeware-статус своих произведений. Это и есть случай врожденного альтруизма; на память приходит, пожалуй, только Пауль Лютус со своей замечательной Arachnophilia. В большинстве случаев Freeware-проект либо превращается в коммерческий, либо, если коммерческий успех не светит, тихо и незаметно умирает.

Вернемся, однако, к явлению Free Software.


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

Далее, принципы Ричарда Столлмена - отнюдь не обязательны. Никто под дулом автомата не заставляет автора программы раскрывать свои исходники. Как не возбраняется и изменение статуса распространения программы - свободный Open Sources волею разработчика (и это - следствие того же авторского права) может превратиться во вполне закрытый продукт (с ограничениями, накладываемыми свободными лицензиями, о чем - в следующем разделе).

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

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

И это - свобода в понимании Free Software Foundation и проекта GNU (GNU is not Unix - проект воспроизведения функциональности этой ОС с "чистого листа"), каковые опять же являются детищами Ричарда. Вследствие понятной аберрации Free Software часто рассматривается как эквивалент Free Software Foundation. Однако это - не так.


Потому что в понимание Free Software par exсellence (то есть по FSF) к сформулированным выше принципам добавляется еще один: все свободные программы, а также все программы, хоть в какой-то степени основанные на свободном софте, должны оставаться свободными ныне, и присно, и во веки веков. Аминь...

Конечно, сам Столлмен сотоварищи в качестве Free Software рассматривает именно свободный софт в понимании FSF - все прочее, по его мнению, принадлежит миру Open Sources. Однако это - тот самый результат расширенной трактовки собственных принципов: если придерживаться буквы последних, то становится ясным, что подавляющее большинство программ из разряда Open Sources столь же свободны, как и разработки под эгидой FSF. Однако к этому вопросу мы еще вернемся.

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

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

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

Благо, наряду с двумя перечисленными точками зрения существует и третья. Формулировки ее в явном виде мне не встречалось (хотя в виде неявном, то есть на практике, ее придерживаются разработчики систем 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.

Что такое ОС?

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

А распространенных мнений по вопросу, что такое операционная система, - два: минималистское и максималистское. Согласно первому, операционная система - это программа, именуемая ядром ОС. Что применительно, например, к 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-совместимыми. Но в таком случае понятие операционки из худо-бедно технологического становится сугубо юридическим - ведь технологического способа определить степень "совместимости" лицензий до сих пор не придумано.

О Unix'ах, Linux'ах и BSD

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

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

Bell-прелюдия

Совсем-совсем недавно, лет пять назад (а конкретно - 1 января 2000 г.) все прогрессивное человечество широко отметило (в узком кругу) тридцатилетний юбилей первозданного Unix'а. Разумеется, это не значит, что операционная система Unix (а некогда это действительно была конкретная операционная система) волшебным образом возникла в этот день, как Афина Паллада из головы Зевса. Создание ОС - процесс, несколько длящийся во времени, и потому паспортную дату рождения ее установить затруднительно. Просто системные часы всех Unix-машин во всем мире отсчитывают свое время (в секундах) с той самой знаменательной даты, с нуля часов ее. И это - одно из многочисленных соглашений, о которых пойдет речь в этой заметке (и которые имеют непосредственное отношение к нашему сюжету).

Вообще говоря, о первой пятилетке истории Unix (1969-1974 гг.) написано немало, поэтому ограничусь основными фактами. Началось все с того, что Bell Labs (в то время подразделение корпорации AT&T) совместно с General Electric и Массачуссетским технологическим институтом разрабатывала очень прогрессивную по тем временам ОС под названием Multics, многопользовательскую и многозадачную, как легко догадаться из названия. Причем - безуспешно, на причинах чего здесь останавливаться не будем. Однако разработка эта имела некое побочное следствие: один из участников проекта, Кен Томпсон, написал под нее игру Space Travel.

В 1969 г. проект Multics был закрыт, и играть Кену стало не на чем и не под чем. Благо, в закромах Bell Labs обнаружилась завалящая машина PDP-7, которая и была окучена под игровые цели. Правда, игра Кена под родной ее операционкой не работала, так что заодно пришлось написать для нее и ОС. Созданная на базе Multics, она получила название Unics - ибо, в отличие от прототипа, пользователь у нее первоначально был один (позднее к Кену в этом качестве присоединился Денис Ритчи, в честь чего и название трансформировалось в Unix).

На дальнейшую судьбу Unix огромное влияние оказали юридические коллизии текущего момента.
Еще до создания этой системы корпорация AT&T подверглась антимонопольному преследованию (подобно Microsoft ныне), в результате чего претерпела поражение в правах - на деятельность ее был наложен ряд ограничений. В частности, она не имела права торговать программными продуктами, в число коих попадала и новорожденная Unix. Так что последняя на протяжении первых 5 лет своего существования вела исключительно внутриутробное существование в лоне породившей ее компании.

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

Все нововведения в первозданном Unix находили отражение в его титулатуре. Сначала они знаменовались сменой версий - было их чуть ли не 10. Затем количество перешло в качество, и версии стали системами - System III, скажем, потом System V, которой, кстати, суждено было стать последней. Дальнейшие модификации в ее недрах получали имена реализаций - System V Release 3, System V Release 4. Последняя также оказалась знаковой - она (под идеограммой SVR4) легла в основу большинства современных коммерческих Unix. Впрочем, я существенно забежал вперед.

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


А вот продавать- то Unix как раз было нельзя. Однако - не пропадать же добру, созданному как бы и самопроизвольно, но - на проприетарном оборудовании. И компания AT&T, юридический владелец Unix, начиная с 1974 г., стала передавать исходные ее тексты в университеты (преимущественно Америки, но также и некоторых других стран) и прочие учреждения - "в образовательных целях", как обычно говорится в источниках.

Это не было свободным распространением в том смысле, который потом вложили в это понятие апологеты движения Open Sources, начиная с Ричарда Столлмена и кончая героями Free Software Foundations. Правда, Unix (вернее, в то время - не более, чем ее прототип) передавалась целиком в исходных текстах с правом их изучения, модификации, доработки и прочего потрошения. Однако для производства таких действий требовалось обладание лицензией на исходный код Unix. Лицензия же могла быть предоставлена владельцем (то есть AT&T) вместе с самой системой, но - уже за деньги (хотя, как пишут, и символические).

Главное же отличие от принципов Open Sources заключалось в том, что условия этой самой лицензии не допускали дальнейшего свободного распространения ни системы целиком, ни каких-либо ее компонентов, содержащих исходный код Unix. "Что, собственно, и создало сюжет". Вернее, интригу всего дальнейшего, почти детективного, сюжета...

Однако до юридических коллизий было еще далеко. А пока университеты с радостью приобщались к новой операционной системе, в которой были реализованы все передовые идеи того времени. И к тому же в принципе способной функционировать практически на всем спектре тогдашнего оборудования. Напомню, что речь идет о середине 70-х годов прошлого века - Стив Джобс еще не помышлял о продаже калькулятора и использовал родительский гараж по прямому назначению, а Билл Гейтс не освободил еще мир от засилья CP/M.

Берклиада Unix-кода

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

В Беркли, в условиях открытого общения профессиональных специалистов в области зарождавшихся Computer Sciences, система Unix медленно, но верно превращалась именно в то, чем она стала ныне. И в значительной мере - именно усилиями трудящихся из университета, объединенных в Computer System Research Group (CSRG), финансировавшуюся в сугубо мирных целях, как не трудно догадаться, Министерством обороны США.

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

Следующим принципиальным вкладом Беркли была реализация файловой системы. Поскольку именно это весьма важно для нас, простых пользователей персоналок, остановлюсь на этом вопросе подробнее.

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

Я уже говорил, что основные характеристики файловой системы были сформированы уже в первозданном Unix. Эта файловая система (получившая впоследствии название s5fs, то есть файловой системы System V) базировалась на трех китах - понятиях суперблока, таблицы так называемых inodes, и области блоков данных.

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

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

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

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

Второе - s5fs была образована некими квантами информации - логическими блоками, имевшими размер от 512 (размер физического дискового блока) до 2048 байт. Очевидно, что увеличение размера блока вело к повышению быстродействия дисковых операций. Однако не менее ясно, что при этом дисковое пространство расходовалось неэффективно: ведь любой файл, сколь мал бы он ни был (а в Unix количество очень маленьких файлов весьма велико), занимал логический блок целиком.

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



Это - что касается физики хранения данных. Логически же файловая система Unix изначально приобрела древовидную (или иерархическую) структуру, основанную на разделении каталогов и всех прочих файлов. Каталоги образовывали как бы скелет файловой иерархии и содержали только идентификаторы файлов и их имена - это и были те самые ссылки, о которых говорилось чуть выше. Причем, вследствие изначально принятого формата каталога, длина имени файла (как это ни покажется парадоксальным пользователям нынешних Linux или BSD, привыкшим к файлам с именами длины немерянной) ограничивалась 14 символами. Ведь каталог - это, в сущности, база данных для идентификаторов файлов и их имен, состоящая, как и любая БД, из записей и полей. Так вот, каждая каталожная запись в s5fs имела фиксированную длину в 16 байт, из которых два первых отводились под идентификатор, так что на имя этих байт оставалось только 14.

Разработки Университета Беркли сняли многие ограничения как физики, так и логики s5fs. Во-первых, единое пространство файловой системы было разделено на части, именовавшиеся группами цилиндров, каждая из которых имела копию суперблока, самостоятельную таблицу inodes и область данных. Это давало большой прирост в быстродействии файловых операций за счет минимизации перемещения дисковых головок. Плюс к тому дублирование критически важной части файловой системы - суперблока - весьма способствовало надежности.

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

Все это привело к потере совместимости новой файловой системы с файловой системой изначального Unix.


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

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

Новая файловая система получила имя FFS - Fast File System, что подчеркивало ее быстродействие относительно исходной s5fs. Я столь подробно остановился на ее отличиях от прототипа по двум причинам. Во-первых, из-за важности их для пользователей. И во-вторых - потому что реализованные в FFS принципы разделения файловой системы и фрагментации ее блоков были ассимилированы во всех последующих файловых системах, применяемых ныне в любых разновидностях Unix. К этим принципам восходят и группы блоков в файловой системе Linux (ext2fs), и экстенты (extents) JFS и, особенно, allocations group в XFS, выступающие здесь уже как почти самостоятельные файловые субсистемы.

И все потому, что Университет Беркли, представляя собой обычное научное сообщество, отнюдь не делал секрета из своих разработок. Распространяя их на условиях, общепринятых в академических кругах всех времен и народов.


То есть все эти результаты публиковались в простых научных журналах и были доступны для воспроизведения любым желающим (и, что немаловажно, можущим). Позднее такие условия распространения софта, с одной стороны, легли в основу лицензии BSD. А с другой, Ричард Столлмен, в юности не чуждый академической науке, опираясь на них, изобрел очень похожий велосипед, и назвал его GPL (General Public License).

Распространялась и сама берклианская разновидность Unix как программный продукт. Группа CSRG, начиная с 1976 г., внедряла в народе свои достижения - на магнитных лентах, под названием Berkely Software Distribution, что, с указанием номера версии, и дало в дальнейшем имя системе. Это было первичное понимание аббревиатуры BSD, которое не следует путать с возникшим позднее BSDi - Berkely Software Development, Inc (или Berkeley Software Design, Inc, мне попадались обе расшифровки этой аббревиатуры), фирмой, выпускающей коммерческий клон BSD-систем, называемый, строго говоря, BSD/386 (хотя в обиходе за этой системой закрепилось то же имя - BSDi).

Первоначально (под именем 2BSD и по цене 50 американских рублей) распространялся только пакет собственно берклианских наработок, включающий, в частности, командную облочку C-Shell и культовый редактор юниксоидов vi. Однако, начиная с 3BSD, берклианские ленты включали уже и модернизированную Unix-систему. Особенно обильные побеги дала ее 4-я ветка - 4.0BSD, 4.1BSD с несколькими подвариантами, 4.2BSD, 4.3BSD и, под занавес истории, 4.4BSD.

Наиболее существенным этапом был выпуск в 1982 г. системы 4.2BSD: именно в ней была реализована файловая система FFS, да и большинство прочих специфических особенностей BSD-систем. Не случайно тип раздела FreeBSD (и DragonFlyBSD) по сию пору идентифицируется как раздел 4.2BSD, а до недавнего времени этот же идентификатор имели и разделы Net- и OpenBSD. С этого момента стало реальностью сосуществование двух самостоятельных линий развития Unix - System III/V и BSD Unix.

А системе 4.4BSD, была предначертана особая судьба, о чем я расскажу несколько позднее.

Вопросы истории POSIX'ивизма

На протяжении предшествующих разделов то и дело упоминались названия различных операционных систем - Linux, Free- и прочие BSD, а также некоторые другие. А внимательный читатель компьютерной прессы время от времени (правда, последнее время - все реже) встречается, с одной стороны, со звучными заграничными именами типа Solaris или UnixWare, с другой же - с неудобопонятными аббревиатурами вроде AIX или HP-UX. Все вышепоименованные ОС имеют ряд общих черт, позволяющих объединить их в единое семейство. Имена ему суть многи - величают эти системы и Unix'ами, и юниксоидами, и Unix-подобными ОС. Хотя наиболее строгий титул им всем будет - POSIX-совместимые операционные системы. Откуда же они взялись? Об этом и пойдет нынче разговор.

Пусть расцветают все цветы

Конечно, система Unix развивалась не только в Беркли. Во-первых, не забрасывала свое детище сама AT&T во всех ее проявлениях. Правда, разработка системы плавно перемещалась от Bell Labs к иным подразделениям, типа группы поддержки Unix и т.д., однако в мои цели не входит описание истории этой корпорации, и потому названия их я опускаю.

Тем не менее, из недр AT&T (в обощенном понимании этого термина) последовательно выходят System III, System V, System V Release 2 (SVR2) и, наконец, System V Release 3 (SVR3); этой системе, разработанной в 1987 г., суждено было стать последним представителем чистой линии первозданного Unix. Ибо уже System V Release 4 (SVR4), появившаяся в 1989 г., включила в себя множество новшеств из разработки 4BSD - интеграцию с TCP/IP, поддержку FFS, берклианскую реализацию механизма виртуальной памяти, и многое другое. В частности, легший в последствии в основу стандарта шелл Корна, несмотря на совместимость с первозданным шеллом (Bourne Shell), заимствовал из C-Shell такие особенности, как управление заданиями, историю команд, поддержку псевдонимов и т.д. (впрочем, развитие шеллов - отдельная история, к которой я еще вернусь в ).

Благо, как уже было сказано, берклианские разработки распространялись в соответствие с принципами открытой науки - то есть практически свободно. И если AT&T не всегда заимствовала их на уровне реализаций (то есть непосредственно кода), то идейное их влияние на первозданный Unix было несомненным.

Во-вторых, портируемость Unix оценили производители специфического оборудования - имена им были IBM, Sun, Hewlett-Packard, DEC и еще несколько забытых. Базируясь на SVR3, BSD, позднее - на SVR4, они адаптировали систему под собственные архитектуры, создав такие варианты, как AIX, SunOS, HP-UX, Digital Unix, соответственно. Все это были коммерческие или, как нынче модно говорить, проприетарные, операционки, однако, будучи жестко привязанными к аппаратуре фирм-производителей, в свободной продаже (подобно нынешним Windows) они не присутствовали.

В третьих, чисто софтверные фирмы подняли мутный вал уже чисто коммерческих Unix'ов. Это были, в частности, Interactive Systems и Santa Cruz Operations (косвенный предок скандально прославившейся ныне SCO). Не имея собственных аппаратных платформ, они адаптировали Unix под платформы общераспространенные, коими были в то время сначала PDP, а затем и IBM PC. Кажется, именно SCO Unix стала первой представительницей семейства Unix, портированной на машины с процессором Intel (конкретно - на i386).

Как ни странно, в числе первых на этом поприще отметилась и Самая Великая Софтверная фирма всех времен и народов. Ею была создана система XENIX для тех же i386-х машин. По словам видевших ее, это было нечто вроде однопользовательской реализации Unix - как всегда, Microsoft и тут, подобно товарищу Ленину, пошла своим путем...

Наконец, Беркли был не единственным университетом, приобщившимся к миру Unix. Разработки в этом направлении велись в нескольких академических учреждениях США, а также иных стран (например, Франции и Австралии). Однако наибольшую известность стяжала деятельность Университета Карнеги-Меллона, результатом которой явилась микроядерная Unix-совместимая система Mach. Которая одно время виделась операционной системой будущего - на ней базировались и Digital Unix, и знаменитый NextStep, всерьез поговаривали о использовании ее в разработке OS/2. А Ричард Столлмен положил ядро Mach в основу своего перманентного долгостроя - GNU/Hurd.

Однако главная слава Mach оказалась посмертной. Ибо, во-первых, под ее воздействием Энди Танненбаум написал свою игрушечную систему MINIX, которая вдохновила Линуса Торвальдса на написание Linux. А во-вторых, микроядро Mach нынче составляет сердце MacOS X. Но в рамках описываемых событий это - опять же дела грядущего.

А пока можно было констатировать, что в конце 70-х и в 80-х годах прошлого века Unix развивался в соответствие со знаменитым лозунгом Великого кормчего китайского народа - "Пусть расцветают все цветы!" В итоге, кроме двух, существенно различных, базовых системы - System V и BSD, расцвело не менее дюжины вариантов, в той или иной мере различающихся между собой.Мною были упомянуты далеко не все из них, а лишь те, которые уцелели и поныне. Или - те, о которых мне довелось в свое время хоть что-то прочитать. На самом деле Unix-клонов в те времена было гораздо больше.

Свободная берклиада: продолжение истории

Не стояло на месте и развитие BSD-систем. Мы расстались с ними в исторический момент - на рубеже 80-90-х годов. До этого BSD Unix (а система эта носила тогда это имя) развивалась более-менее во взаимодействии с прочими ветвями этой системы, давая время от времени боковые побеги, в том числе и коммерческие, такие, как SunOS, например, или A/UX (уже встарь были попытки приобщения Macintosh'а к миру Unix, вылившиеся ныне в MacOS X).

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

Именно созданием общедоступной Unix-системы, причем - на общедоступной же платформе, сиречь Intel x86 (ведь эпоха персоналок уже началась), озаботились Вильям и Линна Джолитц. Базируясь на одном из побегов ветви 3BSD - BSD Net/2, они дописали недостающие компоненты и создали 386BSD - первую BSD-систему, претендовавшую на звание открытой в собственном смысле слова. И еще это был первый берклианский побег, портированный на PC (IBM-совместимые компьютеры,как их тогда еще задумчиво называли).

Система эта не была еще вполне готовой к употреблению. Однако она активно исправлялась и улучшалась весьма широким кругом разработчиков, благодаря чему возник институт patchkit'а - корректирующего набора, позволяющего превратить 386BSD в работоспособную операционку.

Однако поддержание такого комплекта заплат оказалось задачей хлопотной и не очень благодарной. Вероятно, именно по этому основоположник 386BSD, Билл Джолитц, к началу 1993 г. "находился в состоянии полного пренебрежения к ней" (здесь и далее - свидетельствует очевидец и активный участник событий, Джордан Хаббард, о чем можно прочитать и по-русски).

Тем не менее, история не закончилась. В том же 1993 г. три последних координатора "Заплаточного проекта" - упомянутый выше Джордан Хаббард, Нейт Вильямс и Род Граймс, - решили "привести промежуточный снапшот 386BSD в порядок, исправив множество проблем, которые механизм patchkit не мог решить". Это предполагалось сделать "путем предоставления промежуточных 'очистных' снапшотов". Однако планы тройки по борьбе с заплатами "были невежливо оборваны, когда Билл (Джолитц - А.Ф.) внезапно решил забрать его (вероятно, свои - А.Ф.) санкции у проекта без любых ясных комментариев, что должно быть сделано вместо этого."

Однако и это не очень повредило делу. К проекту присоединились Джулиан Элишер и Дэвид Гринмен. Именно последнему принадлежит заслуга изобретения имени нового проекта - FreeBSD и приобретения на него права собственности.

Вахта же Хаббарда выразилась в том, что он "связался с Walnut Creek CDROM с мыслью о путях последующего улучшения каналов распространения FreeBSD для множества невезучих без доступа к Internet. Walnut Creek CDROM не только поддержал идею распространения FreeBSD на CD, но также пошел далеко вперед и предоставил проекту компьютер для работы и быстрый доступ к Internet. Без почти беспрецедентной веры Walnut Creek CDROM, в то время полностью неизвестный проект (видимо в проект FreeBSD - А.Ф.), вряд ли FreeBSD зашел далеко и так быстро, как сегодня."

В декабре 1993 г. совместные усилия проекта FreeBSD и Walnut Creek обрели зримое воплощение в виде FreeBSD 1.0, распространявшейся как с ftp-серверов (вспомним - тогда это был почти единственный способ получения софта, за исключением коммерческого "коробочного"), так и на CD.

Ветка FreeBSD 1.x базировалась все на той же Net/2, что и произведение Джолитца, из которого она включила многочисленные дополнения. Кроме того, существенным компонентом ее стали утилиты и приложения проекта GNU. Все это были открытые и свободные разработки. Однако исходная лента Net/2 изначально содержала некоторое количество проприетарного Unix-кода.


И это были именно критически важные фрагменты, превращавшие Берклианские разработки в цельную работоспособную систему.

На основе 4BSD в это же время развивалось еще два проекта BSD/OS и NetBSD. Первый имел коммерческий статус и ныне воплотился в 386BSD - Unix-подобную систему, распространяемую за деньги, но с исходными текстами (хотя последние - за отдельную мзду).

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

Тут-то господа правообладатели, чуя наживу, и напомнили разработчикам из Беркли о своих правах. А права на исходный код Unix и торговую марку, нареченную этим именем, приобрела у AT&T фирма Novell. В тот момент одержимая, подобно сиятельному Камильбеку из "Повести о Ходже Насреддине", хватательным рвением.

Начался "вяло-текущий судебный процесс о легальности версии Net/2 из Беркли". В результате юридического сутяжничества из системы, лежащей в основе FreeBSD и NetBSD, были изъяты все следы частнособственнического кода - а, повторяю, речь шла именно о критически важных фрагментах. Гильотинированная версия получила имя 4.4BSD-Lite, и всем претендентам на BSD-наследие было рекомендовано в добровольно-принудительном порядке перейти на ее использование.

Катастрофа свободных BSD-систем казалась неизбежной. Но - "приключения никогда не кончаются". И потому снова слово Джордану:

"Тогда FreeBSD приступил к сложной задаче - буквально полному изобретению себя из абсолютно новой и довольно неполной системы 4.4BSD-Lite. "Lite" был в прямом смысле light потому, что из него удалили большие куски кода, необходимого для создания реально загружающейся системы... и фактически порт 4.4BSD для платформы Intel был очень неполным".



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

Аналогичным путем, и примерно в то же время, были решены лицензионные проблемы и разработчиками NetBSD. Однако ни та, ни другая системы уже не были лидерами в мире свободных Unix-клонов: на этом месте прочно утвердился Linux.

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

Однако вернемся к нашей берклиаде. Некоторое время оба свободных BSD-клона развивались параллельно - каждый в своем направлении. NetBSD портировалась на всё новые (точнее, в основном все старые) платформы, тогда как разработчики FreeBSD все более эффективно использовали возможности самой распространенной из них. Однако в 1996 г. произошло первое ветвление в BSD-мире: от NetBSD отделился самостоятельный проект, OpenBSD, в которой мультиплатформенность надстроена ориентацией на максимальную безопасность.

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

Однако главное ветвление FreeBSD случилось прямо на наших глазах. В середине июня 2003 г. Мэтт Диллон (Matt Dillon), известный, объявил о начале работы над новой ОС BSD-семейства - DragonFlyBSD, отколовшейся от FreeBSD 4-й ветки.И по промествии года вышел и первый релиз новой системы. Впрочем, это - отдельная, и частично уже описанная история.

Упорядочивание стилей работы

Постепенно различия между клонами становились все более значительными. Во-первых, в основе существовавших вариантов Unix лежали разные базовые системы - SVR3, SVR4, 4BSD. Во-вторых, каждый разработчик считал своим долгом либо адаптировать систему под возможности собственной аппаратной платформы, либо просто внести те или иные усовершенствования. А поскольку практически все существовавшие системы были не только проприетарными, но и закрытыми, усовершенствования эти слабо согласовывались между собой. И, в любом случае, реализовывались различным образом.

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

Тем не менее, процесс упорядочивания пошел. Первый шаг в этом направлении резонно было бы сделать основоположнику Unix. И AT&T создала документ, описывающий спецификации, которым должна соответствовать система, претендующая на звание Unix - SVID (System V Interface Definition, то есть определение интерфейса System V). И даже разработала программу, которая проверяла претендента на соответствие этим спецификациям - System V Verification Suite.

Нетрудно было предположить, что в этих спецификациях нашли отражение только те особенности BSD, которые были инкорпорированы в каноническую System V. А ведь BSD была столь же полноводным источником, из которого черпали все производители Unix. Их такое положение дел не очень устроило. И потому было создано несколько организаций, разрабатывающих свои версии стандартов для операционных систем, расширенные по сравнению со SVID. Наибольшее признание из таких разработок заслужил стандарт POSIX (Portable Operation System Interface based on uniX).

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

Стандарты POSIX существуют в виде серии регулярно обновляемых документов (общим числом под два десятка), в которых описываются спецификации отдельных компонентов систем. Из них наибольший интерес для нас представляет документ IEEE Std 1003.1, в последней редакции которого (от 2004 г. - 2004 Edition) были объединены ранее отдельные стандарты. В современном своем виде он включает четыре "тома":

Base Definitions volume (XBD) - определение терминов, концепций и интерфейсов, общих для всех томов данного стандарта;

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

Shell and Utilities volume (XCU) - определение стандартных интерфейсов командного интерпретатора (т.н. POSIX-shell), а также базовой функциональности Unix-утилит;

Rationale (Informative) volume (XRAT) - дополнительная, в том числе историческая, информация о стандарте.

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


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

Я понятно выразился в предыдущем абзаце? Если не очень, попробую пояснить на паре конкретных примеров. Так, в стандарте POSIX предусмотрена команда split, предназначенная для разделения текстового файла на отдельные фрагменты - по размеру (в байтах, килобайтах или мегабайтах) или числу строк. Что достигается указанием соответствующих опций, также описанных в стандарте (-b и -l, соответственно). И именно это команда split обязана делать в любой системе, претендующей на звание POSIX-совместимой.

И, скажем, реализация команды split в Linux (вернее, в пакете coreutils проекта GNU - одном из компонентов Base Linux) выполняет свои обязанности буквально. А вот та же команда в BSD-реализации делает все то же, но имеет еще и дополнительную возможность - разбиение текста на фрагменты по шаблонам (например, заголовкам вида Глава или Часть). Для чего в ней введена опция -p (или --pattern), выходящая за рамки стандарта.

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

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

Именно на стандарты POSIX в первую очередь и опирался Линус Торвальдс, создавая свою ОС по мотивам MINIX. Однако это уже следующая история.

Увертюра Линуса

Как было сказано ранее, Unix в разных его проявлениях получил широкое распространение в университетах всего мира. Более того, он стал основой базового академического образования в области Computer Sciences (и не только - Unix'у кое-где учат и студентов-геологов). И потому возникла необходимость в соответствующих учебных пособиях, каковые и появились во множестве.

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

Это противоречие разрешил Энди Танненбаум, профессор Амстердамского университета, написав "пионерский" вариант Unix - ОС Minix, предназначенную исключительно для образовательных целей. И распространял ее в виде набора дискет вместе со своим учебником по теории операционных систем.

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

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

Именно таким образом поступил в 1990 г. некий студент университета Хельсинки - Линус Торвальдс, - когда ему захотелось поизучать внутреннее устройство процессора своей новой машины (i386) и одновременно приобщиться к Unix, которую он изучал в своем ВУЗе: купил книгу Танненбаума вместе с Minix, скачал и установил соответствующие патчи.

Далее ему потребовался терминальный доступ к университетской машине, чтобы выходить в Сеть, не выходя из дома (как я его понимаю...). В Minix штатно подходящей программы не обнаружилось, и Линусу пришлось сочинить ее. Однако под управлением ядра Minix она работала плохо - так что волей-неволей потребовалось новое ядро. Его нужно было куда-то размещать - так родилась новая файловая система, ext (то есть Extended - расширение для файловой системы Minix). Для запуска терминальной программы не худо было иметь какую-то среду - для этой цели Линус портировал на свое ядро командную оболочку bash, разработанную в недрах проекта GNU. Ну и все это хозяйство требовалось чем-то собирать - не перезагружаться же обратно в Minix каждый раз, как потребуется внести коррективы в исходники. Так что к bash пришлось присоединить еще и единственный свободный из наличных компиляторов Си - GNU C Compiler (известный как gcc). А итогом всего этого явилось объявление в августе 1991 г. о создании новой операционной системы. Видите, как все просто?

Новая ОС получила название Linux - в определенной степени случайно: так именовался домашний каталог Линуса на том ftp-сервере, на котором она впервые была выложена для свободного доступа. Сначала - под лицензией, сочиненной Торвальдсом собственноручно. Однако вскоре, не собираясь особо заморачиваться юридическим крючкотворством, с одной стороны, но желая оградить свое творение от враждебных посягательств - с другой, он изменил лицензию на GPL, под которой распространялись такие важные ее компоненты, как bash и gcc.

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

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


В результате Linux не является чистым клоном Unix: ее можно считать первой настоящей POSIX-системой в полном смысле этого слова. А черты ее сходства с какими-либо вариантами System V или BSD обусловлены только тем, насколько полно все они воплощают соответствующие стандарты.

Во-вторых, Linux создавался на машине с процессором i386 для архитектуры Intel и первоначально - только для нее. Более того, Линус вообще сомневался, что его система когда-либо сможет быть портирована на любую иную аппаратную платформу. И потому соответствие стандартам в данном случае преследовало целью не переносимость Linux самого по себе, а в первую очередь возможность компиляции в этой ОС всего ранее созданного программного ассортимента для Unix и POSIX-совместимых систем вообще.

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

В третьих... а в третьих тесно связано со вторым: Линус оказался создателем уникального метода разработки масштабных проектов Open Sources, того самого, который Эрик Раймонд позднее назовет методом большого базара. Впрочем, справедливости ради следует отметить, что и в данном случае изобретался велосипед - аналогичный способ привлечения дармовой рабочей силы использовал Том Сойер в своих "Приключениях".

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

Линус же обеспечил своему проекту, помимо практического бессмертия, еще и непрерывность развития.


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

В результате деятельности аморфного, неорганизованного, "базарного" коллектива разработчиков, не имеющих первоначально никаких источников финансирования, ядро Linux очень быстро обросло такими функциями, как поддержка сетей, протокола TCP/IP, оконной системы X, на нее были портированы все аналоги классических Unix-утилит и приложений, созданные как в рамках проекта GNU, так и независимыми разработчиками. А затем настал черед и чисто пользовательских приложений, в том числе офисных, графических и мультимедийных. Следствием чего было привлечение не только новых разработчиков, но и конечных пользователей.

И ныне число пользователей Linux много превосходит таковое всех прочих POSIX-совместимых систем, вместе взятых. Причем если среди последних представлены почти исключительно разработчики программного обеспечения и администраторы компьютерных систем разного ранга, то Linux все больше проникает на десктопы тех юзеров, которых принято называть конечными - то есть профессионально не связанных с IT-индустрией.

Почему Linux не Windows

Мысль изреченная банальна,

Но, однако ж, эта мысль важна

Изрекаю: пить шмурдяк, дружище, аморально,

Пиво пить почетно, старина.

Тимур Шаов

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

Linux - это не Windows

Возможно, мое утверждение покажется вам столь же банальным, как заявление Тимура о вреде употребления неправильной водовки. Однако оно столь же верно, как и его максима. И если, по совету Ходжи Насреддина, вы будете думать над ним неотступно, то проникнетесь его величием и блеском. Итак, изрекаю:

Linux - это не Windows, а Windows - не Linux. И те приемы, что хорошо (эффективно) показывают себя в Windows, отнюдь не обязаны быть столь же действенными в системе POSIX-совместимой. Как, впрочем, и наоборот.

Приведу простой пример. Первейший инструмент Windows-пользователя (для простоты, вслед за Владимиром Игнатовым, будем величать его "подоконником") - это программа, которую в этой ОС (точнее, русскоязычной ее ипостаси) называют текстовым процессором. На самом деле текстовый процессор в общепринятом понимании этого слова - нечто совсем другое, поэтому впредь программы этого класса будут именоваться визуальными процессорами - принцип WYSIWYG представляет собой их главную отличительную черту, - или word-процессорами. Так вот, практически первое, что чуть ли не инстинктивно делает в Linux мигрант-подоконник - это тянется к знакомому пистолету. То есть пытается отыскать среди изобилия Open Sources что-то, хотя бы отдаленно напоминающее ему Word (WordPerfect, WordPro, Lexicon - ненужное в скобках зачеркнуть).

И, к чести Open Sources сообщества, нужно заметить, что нынче его усилия увенчаются успехом. Хотя еще пару-тройку лет назад наш экс-подоконник не получил бы ничего, кроме верблюдообразных софтин (у верблюда спросили: "Почему у тебя шея кривая?" - "А что у меня прямое?" - резонно ответил тот). Способных только на то, чтобы привить стойкое отвращение (к офисным пакетам или к POSIX-системам - это уже другой вопрос).

А сейчас он имеет в своих руках тройку программ, вполне знакомых видом и почти таких же нравом, что и привычный ему Word, с функциональностью от идентичной до несколько ослабленной, но в большинстве случаев - более чем достаточной: OpenWriter из комплекта OpenOffice.org, KWrite из аналогичного KDE-набора, и AbiWord из эвентуального пока офиса для среды GNOME (хотя сам по себе AbiWord - сугубо кросс-платформенное приложение).

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

И так далее. При желании он отыщет и графическую среду, внешне сходную с Windows (а при минимальных настройках - просто неотличимую), и Explorer-подобный файловый менеджер, и браузер a la Internet Explorer, и почтового клиента в диапазоне возможностей от Outlock Express до (почти) The Bat, и так далее - вплоть до медиа-плееров всякого рода и вида. Те, кто не верит - обратитесь к таблице соответствия программ Windows->Linux (строго говоря, Windows->POSIX).

Хорошо это или плохо для начинающего Linux-пользователя? Конечно, хорошо, - скажете вы, и я не смогу с вами спорить, памятуя свои первые шаги в Linux, посвященные лихорадочным попыткам применить в мирных целях тогдашние StarOffice или Applixware. Ведь нынче начинающий пользователь Linux может скрасить свой горький эмигрантский хлеб сладостью знакомых сред и классово близких приложений. Чем он, скорее всего, и воспользуется по полной программе.

Однако скоро у нашего экс-подоконника зародится мысль: а не напоролся ли он на то, за что боролся? И какой смысл был ему менять уютное и привычное место на подоконнике на такое же, только видом сбоку? Ибо OpenOffice покажется ему неповоротливым и тормозным, KOffice - падучим и слабо совместимым, GNOME Office - просто недо-офисом, и так далее. Где же обещанная ему при переходе мощь Unix на персональном компьютере? - задаст он резонный вопрос.

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


И тогда у него остается два выхода: или бежать обратно, на обжитый подоконник, как муж возвращается к нелюбимой, но хозяйственной жене от страстной, но безалаберной любовницы. Или все же, если очень нужно, очень хочется, или просто гордость не позволяет возвращаться битым - стиснуть зубы и начинать работать в bash и vim, искать файлы find'ом и тексты - grep'ом, а главное - читать man'ы, info'ы, doc'и и прочие how-to'и.

Так не лучше было бы для нашего подоконника, если бы кто-нибудь сразу объяснил ему: нет ничего более нелепого, чем ставить Linux ради того только, чтобы сочинять служебные записки в OpenWrite, финансовые отчеты - в OpenCalc. Или, паче того, ради профессиональной обработки изображений в Gimp - на то есть более подходящие инструменты (и, добавлю, более подходящие операционки и аппаратные платформы). Что сила POSIX-систем для пользователя (о разработчиках или сисадминах тут речи не идет) - в изощренных средствах создания и обработки текстов, а также в мощнейших коммуникационных возможностях. А не это ли, как я уже отмечал в преамбуле, требуется большинству пользователей от компьютера "по делу", а не ради развлечения?

Прошу понять меня правильно: я не призываю отказываться от OpenOffice.org сотоварищи. Более того, я всецело "за" - эти средства помогут, помимо относительно безболезненного вхождения в новый дивный POSIX-мир, не чувствовать себя чужими на празднике жизни окрестных "подоконников" с их doc-файлами. Я лишь прошу вас помнить о том самом внешне скромном Unix-инструментарии, оттачивавшемся веками (в масштабах времени компьютерной эпохи) - и именно для работы с текстами и коммуникаций.

Помнится, на заре своего приобщения к Linux первое, что я делал после установки системы - были инсталляция StarOffice и прикручивание к нему русских буковок (тогда это не всегда выглядело столь тривиально, как сейчас). А нынче? Нынче я месяцами не вспоминаю об OpenOffice.org или любом ином офисном пакете - пока не придет doc-файл, который нужно не просто прочесть, но и поправить с сохранением форматирования.



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

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

Почему компьютер - не видак

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

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

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

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

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

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

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

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

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

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



Вернемся, однако, к рецептам и принципам. Пока пользователь видеотехники остается чистым потребителем, он вполне может обходиться минимумом рецептов. Однако первые же попытки креативного характера приводят к резкому возрастанию потребности в HOW TO: куда встать, под каким углом держать, откуда направить свет, и так далее. И здесь перед ним два пути: экстенсивный или интенсивный. Первый - копить все те же практические рецепты, наработанные эмпирически. Однако скоро а) их становится очень много и б) все рецепты по определению охватывают только стандартные ситуации, ничего нетленно-непреходящего с их помощью не создашь. И приходится нашему пользователю волей-неволей обращаться к истокам - то есть базовым принципам. Бия себя по голове за то, что в школе не читал внимательно "Физику" Перышкина...

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

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

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



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

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

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

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



Но упростить производственную-то функцию компьютера - все равно не удастся ( работать вообще довольно трудно, как говорил, если не ошибаюсь, Антон Палыч Чехов). И потому лозунги типа "С выходом Windows 3.0 (3.1, 95, 98, ME, XP etc.), обращаться с компьютером наконец-то (выделение мое - А.Ф.) стало также просто, как с бытовой техникой", которые я лично слышу уже более 10 лет, - лукавы, как минимум, вдвойне. Во-первых, это самая обычная подмена понятий - если под обращением понимать не только развлекательную сторону, но и производственную (см. вышеуказанный тезис А.П. - создавать видеофильмы никогда не будет также просто, как их просматривать). А во-вторых, сама регулярность появления таких лозунгов (я не случайно выделил слова наконец-то) вызывает подозрения, что и с развлекательной строной компьютеров все еще сохраняется некоторая напряженка. В частности, за что я не люблю Windows, - за то, что она, обещая избавление от всех и всяческих проблем хотя бы в потребительском аспекте, своих обещаний не выполняет.

Рецепты против принципов

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

Подобно нашему видеолюбителю, профессиональный текстовик, пересев с пишущей машинки (или с письменного стола со стопой бумаги и паркеровской авторучкой) за компьютер, быстро узнает множество простых рецептов, как то: нажав клавишу Insert, он может забить неправильно введенный текст (как забивочные листки на машинке, только проще), клавишами Delete или Backspace можно уничтожить лишнюю букву (в отличие от замазки, без следов), и так далее.

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

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

К слову сказать, современные ворд-процессоры WYSIWYG-типа пользователя к такой структуризации отнюдь не стимулируют. За ненужностью народу, вероятно. В одной книжке про Word мне как-то встретилась фраза, что стилевая разметка - это штука очень сложная, которая по силам только высоким профессионалам. Простым людям, видимо, проще вручную придавать заголовку каждой главы кегль и начертание (и при этом помнить, какое оформление было придано Главе 1, какое - Главе 2, и так далее).

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

Возьмем простую задачу - создание единого документа из нескольких существующих, причем - включенных в определенной последовательности. Мне этот пример кажется очень показательной, и я не устаю его повторять. Можно: открыть документ 1, перейти в его конец, щелкая мышью по контекстному меню (или даже воспользовавшись существующим рецептом - макрокомандами с привязанными к ним горячими клавишами), вставить туда документ 2, и так далее. Быстрее, конечно, чем подклеивать бумажные листы силикатным клеем, но все ли это, что может компьютер?

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

$ cat file1 file2 file3 > file-all

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



Задача обратная - поделить наш правильно (!) структурированный документ на отдельные части в соответствие с его внутренней структурой (например, разбить книгу на главы, как это обычно требуется для представления в издательство). Для автоматизации процесса нам достаточно знать о другом относительно общем понятии - регулярных выражений, причем лишь в той его части, которая описывается термином шаблон (pattern). И задача сводится к тому, чтобы отыскать в нашем файле строки, начинающиеся последовательностью символов Глава и каждую последовательность символов в промежутке записать (то есть вывести) в самостоятельный файл. Что можно сделать многими способами, но один из них - штатен и элементарен, это команда split (в BSD) или csplit (в Linux).

Последний пример показывает, что, хотя понимание принципов и не избавляет уж совсем от обращения к рецептам, но зато позволяет вычислить последние при их незнании. Дело в том, что в BSD команда split универсальна, и служит для разделения файла по любому параметру - размеру, номеру строки или шаблону. Одноименная же команда в Linux выполняет только первые две функции, опции -p (--pattern) в ней не предусмотрено. Что поначалу может расстроить. Однако если понимать, что в принципе разделение файлов по шаблону почти ничем не отличается от такового по номеру линии или размеру (и то, и другое суть действия, основанные на анализе последовательности символов), остается только изыскать соответствующий рецепт. Что можно сделать просто в лоб - поискать слово split в каталоге с man-страницами командой grep (строго говоря, не слово, а последовательность символов, и командой zgrep, так как страницы эти обычно в gzip-сжатом виде). Чем и обнаруживается man-страница с описанием команды csplit, прочитать которую - уже вопрос элементарной грамотности.

Следующий пример соотношения рецептов и принципов касается установки пакетов. Пользователь любого прекомпилированного дистрибутива быстро усваивает простые рецепты управления оными. Таким рецептом в rpm-based дистрибутивах Linux является команда вида



$ rpm -ihv package_name.rpm

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

Но особенно явно превосходство принципов над рецептами выступает при конфигурировании всего и вся - от общесистемных опций до шрифта меню конкретного приложения. Рецептурный подход - использование специализированных средств настройки, оформленных в виде самостоятельных утилит или встроенных в прикладные программы. Самостоятельные утилиты такие многочисленны и разнообразны, не зря же Владимир Попов как-то заметил, что число утилит конфигурирования давно превзошло количество конфигурируемых параметров. Интерфейс у них разный в разных дистрибутивах, да к тому же еще и может меняться от версии к версии. Так что доскональное знание какого-либо DrakX из Mandrake ничем не поможет при работе с sysinstall из FreeBSD, и наоборот.

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

Что касается объектов конфигурирования, то есть соответствующих файлов, и субъектов оного - параметров настройки, - то они определяются стандартными утилитами работы с текстами, например, командой find - для поиска файлов по маске, и командой grep - для изыскания в них подходящих по смыслу фрагментов. Ну и, разумеется, осмысленного анализа результатов того и другого...



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

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

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

И опять к слову: понятие атрибутов принадлежности и доступа, одно из краеугольных в Unix-системах, существует и в тех Windows, которые можно назвать всамделишними (то есть NT/2000/XP, даже в ME вроде бы есть зачатки - семейный доступ в систему и прочее). Да вот только пользователи их об этом часто не подозревают.


Не потому, что чайники, а потому, что их от этого знания тщательно оберегают.

В результате к нештатным ситуациям (например, потере пароля - кто от этого застрахован, все мы люди, все мы человеки) пользователи Windows оказываются просто морально не готовы: нужно дергаться, звать админа, даже (страшно подумать) лезть в книги (не для того ли мы отказывались от man- и info-страниц?) для поиска рецептов, соответствующих ситуации.

А в Unix (вернее, Linux/*BSD, за прочие не скажу по незнанию) - все просто, если помнить о файле (файлах) паролей, однопользовательском режиме (или возможности загрузки с внешнего носителя) и о том, что дисковые устройства нужно монтировать (насколько я знаю, в NT сотоварищи диски тоже как бы монтируются, только "дружелюбно" и "прозрачно" для пользователя; в итоге ему остается только удивляться сообщениям об ошибках, выдаваемых при неправильном извлечении USB-драйва).

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

В я вскользь упоминал, что FreeBSD видится мне более подходящей системой для приобщения к POSIX'ивизму, нежели какой-либо из user-ориентированных дистрибутивов Linux. И теперь я могу высказать первый к тому резон: отличие этой ОС от Windows с первых же шагов проступает столь явственно, что не рождает даже мысли об использовании "подоконных" приемов работы.

Конечно, такие Source Based дистрибутивы Linux, как Gentoo, уже на стадии установки оставляющие пользователя наедине с командной строкой и текстовым редактором, еще более гармонируют с методом "большого болота". Однако для совсем уж неподготовленного юзера болото может оказаться чересчур уж глубоким.



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

Тем не менее, основной десктопной платформой среди открытых ОС выступает Linux. И среди Linux'ов также можно подобрать подходящие (можно сказать, модельные) объекты для постижения истин POSIX-мира. Многие поколения пользователей входили в этот мир через Linux Slackware. Однако в настоящей книге в качестве таких модельных систем выбраны два близкородственных дистрибутива - Archlinux и CRUX.

Может возникнуть вопрос - почему я остановился на относительно мало распространенных представителях этого семейства?

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

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

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

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

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

Как научиться плавать: установка системы

...А был он в плаванье сущий король.

Это ложь, что он плавал саженками -

У него был поставленный кроль.

Аркадий Аршинов

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

Обеспечение работы в графическом режиме

Изложение своих POSIX-максим я начал с того, что Linux - это не Windows. Тем не менее, придать ему "подоконный" образ можно - для этого нужно только обеспечить возможность работы в графическом режиме. Этой цели служит так называемая оконная система X (X Window System), которую мы по ряду причин в дальнейшем будем называть просто Иксами.

Не премину в очередной раз подчеркнуть, что сами по себе Иксы ни к Linux'у, ни к BSD никакого отношения не имеют. Так как создавались изначально для работы поверх почти любой операционной системы (не обязательно Unix-подобной), в принципе способной работать с графикой. В частности, одна из двух свободных реализаций Иксов - XFree86 или Xorg, общепринятых в Linux - это точно те же системы, работающие над Free-, Net- и OpenBSD, OS/2 и даже, страшно сказать, поверх Windows. Однако других полноценных, и при этом свободных, графических систем в открытых Unix'ах нет, и потому XFree86 или, в последнее время чаще, Xorg всегда стандартно включаются в любой дистрибутив Linux (за исключением узкоспециализированных) и в любую BSD-систему.

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

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

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

Здесь замечу только, что при таком подходе к русификации иногда оказывается, что в текстовом и графическом режиме национальные раскладки, да и клавиша-переключатель, окажутся несколько разными. Впрочем, как мы со временем увидим, лечится это достаточно легко.

С любыми современными мышами - ничуть не сложнее. Если она была не совсем точно определена на автомате - обычно достаточно скорректировать это выбором из предлагаемого списка (например, Microsoft Intellimouse, Genius NetScroll и т.д.). Иногда, правда, требуется отдельно указать протокол и интерфейс нашего "грызуна". И здесь достаточно помнить, что все современные мыши работают по протоколу Microsoft Intellimouse или просто Microsoft (в зависимости от того, есть у мыши колесико или нет); исключением, говорят, являются некоторые Geius'овские модели - но и для них можно подобрать подходящий. А интерфейс - это порт, куда мышь втыкается, и ныне их осталось два - PS/2, постепенно отмирающий, и USB.

С устройством вывода - то есть сочетанием видеокарты и монитора, - несколько сложнее. Для видеокарты необходимо знать производителя чипа (графического процессора), благо их нынче - раз (Nvidia), два (ATI), три (чипсетное видео от Intel) и обчелся (Matrox'ом), иногда - модель поточнее, а также объем видеопамяти. Точная же настройка монитора (включая оптимальные частотные характеристики) невозможна без документации: необходимы знания допустимых диапазонов строчной и кадровой развертки.


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

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

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

Обеспечение загрузки

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

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

И потому в Linux принято два системных загрузчика - традиционный Lilo и GRUB, имеющий шансы стать стандартным в мире Open Sources вообще. Оба они - не просто системные, а мультисистемные, то есть позволяют загружать не только Linux, но и многие другие операционки, от Windows до любой BSD. Какой из этих загрузчиков используется по умолчанию в данном дистрибутиве - дело личных пристрастий его разработчика.

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

Любой из загрузчиков может быть установлен двумя различными способами - в загрузочный сектор диска или в соответствующий же сектор Linux-раздела (корневого или, если таковой создавался - boot-раздела). Первый способ обязателен, если GRUB или Lilo будут основными системными (или мультисистемными) загрузчиками - что очевидно, ведь тогда другого загрузчика у нас нет. Если же на машине есть уже некий подходящий загрузчик (а Linux в состоянии грузить и NTloader, или как он там нынче называется, и известный Partition Magic, и Acronis OS Selector, и BSD Loader - штатный загрузчик операционок одноименного семейства), то его можно сохранить, а собственно Linux'овый загрузчик записать в boot-сектор раздела.

Впрочем, на тему сосуществования и совместной загрузки Linux и Windows я распространятся не буду, так как уже подзабыл, как это делается. Да и написано на сей счет немало. А мы двинемся дальше.

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

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

Особенности установки BSD-систем

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

В принципе установка какой-либо BSD-системы включает почти те же этапы: 1) обеспечение ее загрузки со сменного носителя и запуска программы-инсталлятора, 2) подготовка диска, совмещенная здесь с установкой загрузчика, 3) собственно установка. Настройка работы в графическом режиме в NetBSD, OpenBSD и DragonFlyBSD не предусмотрена, а во FreeBSD - носит опциональный характер (и из последних ее версий исключена - хотя, возможно, и не навечно). Однако каждый из этапов имеет некоторую специфику.

Ближе всех к Linux'овым user-ориентированным - инсталлятор FreeBSD, запускаемый при старте машины с установочного диска. Он последовательно предлагает пользователю разбить диск на разделы, определить точки монтирования файловых систем, записать собственный начальный загрузчик (впрочем, не запрещается и использование GRUB или Lilo - особенно при совместном использовании с другими ОС), выбрать компоненты базовой системы и, при необходимости, дополнительные (не входящие в собственно FreeBSD Distributions) пакеты, произвести сетевые и прочие настройки (включая базовую русификацию). При желании можно сконфигурировать также XFree86 - для этой цели служат тут штатные конфигураторы последней.

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

Установочные программы Net- и OpenBSD имеют более аскетический вид. Начать с того, что OpenBSD не имеет штатного инсталляционного CD (распространяемые через онлайновые магазины диски не являются официальными, а изготовлены энтузиастами-пользователями). а установочный диск NetBSD для архитектуры i386 лишь недавно (с версии 1.6.1) стал, наконец, загрузочным. В принципе в обеих этих ОС чуть ли не в качестве основного метода установки принимается а) загрузка с дискеты и б) последующая инсталляция по Сети (по ftp- или http-протоколу, с локального сервера и т.д.).

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

Установка DragonFlyBSD, подробно рассмотренная в отдельном цикле, имеет лишь одну особенность - базовая система не распаковывается из архива (архивов), а переносится непосредственно с дистрибутивного CD специальной командой cpdup (что, впрочем, маскируется инсталляционной программой - BSD Installer).

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

Подготовка диска

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

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

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

Вообще говоря, для первой установки я рекомендовал бы именно чистый диск - пусть и не первый (Linux в силах грузиться как с Master'а, так и со Slave на любой IDE-линии).

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

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

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

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


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

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

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

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

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



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

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

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

И последнее. Возможно, установщик будет настойчиво рекомендовать небольшой раздел для использования в качестве загрузочного. Если так - по возможности, соглашайтесь, не пожалеете. И размер его определите в 30-50 Мбайт (хотя, например, Fedora откажется устанавливаться, если этот раздел будет меньше 70 Мбайт).

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


Linux в качестве родных (native) поддерживает множество типов файловых систем - классическую Ext2fs и ее усовершенствованную разновидность - Ext3fs, ReiserFS, XFS, JFS. И все они могут быть предложены инсталлятором на выбор. Так что вопрос этот - весьма сложен, но поначалу, до формирования устойчивых личных предпочтений в этой области, можно согласиться с тем, что предлагается по умолчанию. С монтированием же - очевидно, что корневой раздел должен быть смонтирован в точку корня (/), раздел для данных - в точку /home, загрузочный - в точку /boot. А раздел подкачки в монтировании не нуждается...

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

Подготовка к заплыву

Банальность этого утверждения осложняется одним моментом. Прежде чем начать работать в Linux или BSD, любую из этих систем необходимо установить. Поскольку спасение утопающих - дело рук самих утопающих, то устанавливать ее придется, скорее всего, тому самому пользователю, в планы которого и входит обучение Unix'у. А вот тут - увы - оказывается, что сама по себе установка этой системы предполагает некоторые навыки обращения с ней: все та же уловка 22, о которой уже говорилось ранее.

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

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

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

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

Так что выбор в качестве первой пробы пера какого-либо user-ориентированного дистрибутива вполне оправдан. Однако понимание сути действий установщика любой дружественной системы от этого не становится менее важным. Тем более, что все они, в сущности, делают одно и то же.

Что именно? А давайте подумаем, что нужно сделать, чтобы установить ОС.

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

Далее, кроме установочного носителя (в его качестве ныне обычно выступает CD ROM), неплохо иметь накопитель, на который новая ОС будет устанавливаться. Таковым в большинстве случаев является жесткий диск (он же винчестер или, в народе, просто винт). Причем этот накопитель нужно подготовить неким определенным образом, доступным для понимания устанавливаемой системой. То есть, в терминах DOS/Windows, разметить (или разбить на разделы) и отформатировать.

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


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

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

Хотя нет, есть еще и пятый шаг - это настройка графического режима работы. Сама по себе она ни к Linux'у, ни к любой BSD никакого отношения не имеет, однако выступает непременным атрибутом установщика любого дистрибутива, претендующего на роль user-ориентированного.

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

Проблема выбора

В рамках второй истины остается рассмотреть последний вопрос - о выборе водоема для обучения плаванию. Один из наиболее распространенных вопросов на форумах: какой дистрибутив Linux выбрать? Или - более редкая его вариация: что выбрать, Linux или Free- (Open-, Net-) BSD?

В ответ на такой вопрос пользователь может получить кучу вполне конкретных советов, типа: Gentoo - потому что это круто, или Red Hat - потому что это рулез, или FreeBSD - forever (список можно расширять неограниченно). И среди них наверняка будет один совет - универсальный: использовать ту систему, которая стоит у ближайшего Unix-гуру.

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

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

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

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

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

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

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

Тем не менее, принудительная сила реальности такова, что большинству людей, вне зависимости от их природной склонности к дедукции или индукции, приходится заниматься освоением новой ОС в ходе ее практического использования и параллельно с ним.


То есть сразу по установке системы ему нужно иметь некий минимум функций, настроек, приложений.

Именно на такую категорию пользователей рассчитаны такие пакетные user-ориентированные дистрибутивы, как Red Hat, Mandrake, их более или менее отдаленные клоны (Altlinux, ASPLinux). Каковые, казалось бы, и будут оптимальным выбором для большинства начинающих пользователей, не правда ли?

Однако все не так просто. Потому что в расплату за простоту установки и быстроту "вхождения в тему" пользователь получает по умолчанию некую Windows-подобную систему, перегруженную программами, ему, возможно, не нужными (а главное - программами, назначение которых он рискует не узнать никогда). Систему, модификация которой отнюдь не прозрачна. По крайней мере, для начинающего - вопреки существующему мнению, вносить изменения в конфигурацию user-ориентированного дистрибутива гораздо сложнее, чем заниматься настройкой с нуля дистрибутива Source Based. Тем, кто не верит, предлагаю посмотреть конфигурационные файлы Suse (если вы - пользователь Red Hat) или Mandrake (если вы - пользователь Suse). И, при указанных условиях, попытаться внести в них осмысленные изменения.

С другой стороны, чисто "исходнячные" дистрибутивы для начинающего пользователя также, скорее всего, не приемлемы. И дело даже не в том, что уже установка таких систем требует определенных знаний: знания - дело наживное, для их приобретения достаточно умения читать. А документированы Source Based дистрибутивы обычно очень хорошо - лучше, чем многие пакетные дистрибутивы (кто не верит - опять же, сходите на Gentoo.org - http://www.gentoo.org/doc/en/index.xml, есть там немало и русскоязычных материалов). Нет, причина - в том, что любой Source Based дистрибутив требует кропотливой настройки до запуска первого практически нужного приложения (собственно, в этом и есть их цимес). А мы уже выяснили, что свежеустановленную ОС обычно приходится начинать использовать для всамделишней работы сразу.

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


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

Конечно, для установки FreeBSD пользователю необходимо несколько больше предварительных знаний, чем для установки user-ориентированного пакетного дистрибутива Linux. Однако за источником таких знаний далеко ходить не нужно - проект FreeBSD прекрасно документирован, и большая часть его материалов доступна ныне и на русском языке. А серия руководств, как переводных (например, Иллюстрированное руководство по установке FreeBSD, не говоря уже о Handbook), так и исходно русскоязычных (например - FreeBSD: быстрое развертывание) делает инсталляцию ее ничуть не сложнее, чем развертывание Mandrake или Red Hat.

Теперь посмотрим, каковы возможности выбора для пользователя, предпочитающего более или менее глубоко изучить POSIX-систему, прежде чем применить ее на практике. И здесь, казалось бы, лучший выбор - это именно Source Based дистрибутивы Linux? Не буду с этим спорить: установка и индивидуальная настройка, например, Gentoo способна дать в этом плане очень много. Однако...

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

И тут мы опять вспоминаем о BSD.


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

Какую из BSD-систем выбрать как объект углубленного изучения? Теоретически рассуждая, чуть ли не любую. Хотя следует учитывать, что OpenBSD и NetBSD относительно слабо освещены в русскоязычных источниках, имеют проблемы с русификацией. А главное - их достоинства (защищенность и кросс-платформенность) для индивидуального пользователя несущественны. Так что на выбор остаются - FreeBSD или DragonFlyBSD. Мой личный выбор - в пользу последней, но это сугубо дело вкуса...

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

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


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

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

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

Установка

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

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

Это не значит. что пакеты - маленькие, размер их может быть самым разным. Как и состав - есть пакеты, включающие фактически одну-единственную монофункциональную программу, есть пакеты, образованные набором программ определенной направленности. А есть - и такие, которые сами по себе являются самостоятельной системой. Примером чему - оконная система X (X Windows System) или, в просторечии, Иксы.

В состав дистрибутива пакеты могут быть включены в трех формах формах:

в виде т.н. исходных текстов (sources - "исходников"), которые перед установкой и использованием подлежат определенным действиям - трансформации в исполняемый код (процесс этот называется сборкой);

в виде набора правил для получения (из Сети) и сборки готовых к использованию пакетов из исходников - так называемых портов, хотя в Linux такие наборы правил имеют собственные названия в каждом дистрибутиве; при этом сами исходники в состав дистрибутива входить не обязаны;

в виде заранее собранных, т.н. бинарных (или прекомпилированных) пакетов, которые необходимо только развернуть из архивов и поместить куда нужно.

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

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

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

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

Кроме того, проблема выбора осложняется еще явлением, известным под названием "зависимости пакетов". На практике это выглядит так, что выбор пакета A автоматически влечет за собой также установку пакетов B и C - количество зависимостей для каждого пакета может быть разным.

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

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


Что, однако, не значит, будто эта дополнительная функциональность покажется полезной именно вам...

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

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

Если же пользователь решается на попакетный выбор - проблема зависимостей встает перед ним в полный рост. Однако и тут его не бросят наедине с длиннющим списком. В подавляющем большинстве пакетных дистрибутивов существует та или иная система контроля зависимостей, которая не позволит установить компонент A без компонента B, если между ними существует "жесткая" зависимость. В своей заботе о пользователе они идут еще дальше, распространяя ту же систему контроля и на зависимости "мягкие". Впрочем, большинство пакетных дистрибутивов не позволяют различать "жесткие" и "мягкие" зависимости: какие из них прописаны в данном пакете его сборщиком (майнтайнером), те и будут установлены, вне зависимости от вашего желания. Однако на эту тему мы еще подробно поговорим, когда дело дойдет до принципов и систем пакетного менеджмента.

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

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

Загрузка и запуск

Загрузка Linux для установки этой системы осуществляется с CD - времена загрузочных дискет, надеюсь, остались в далеком прошлом (ныне дискеты могут понадобиться только в особых случаях), а времена DVD-дисков - пока еще в светлом будущем, более или менее отдаленном (хотя некоторые дистрибутивы и предлагаются на этих носителях). То есть первый (а иногда - и не только первый) диск любого дистрибутивного набора - загрузочный, и для старта достаточно вставить его в соответствующий привод, перезагрузить машину (тремя пальцами или одним - по ситуации), в ходе перезагрузки выставить в BIOS Setup соответствующую опцию - загрузка с CD, - и ждать завершения процесса (что может занять не одну минуту).

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

То есть: любую свободную ОС POSIX-семейства в той или иной комплектации можно (по определению - см. ) скачать по ftp- или http-протоколу (в виде iso-образа) с сайта/сервера разработчика или какого-либо иного (из более иных заслуживает быть отмеченным LinuxISO). И это - вполне приемлемый путь, если вы а) сидите на "толстом" канале и б) не платите за него из толщины собственного кошелька (или толщИны эти эквивалентны). Что, в условиях постсоветской действительности, бывает на так и часто...

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

изобилие дистрибутивов Linux во все расширяющемся ассортименте;

практически любую из существующих BSD-систем;

литературу по тематике Unix, Open Sources (ну и по общекомпьютерной тоже);

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

"А чего не хватит в доме - сколько хочешь, в гастрономе": и если позарез нужный вам дистрибутив не обнаруживается в закромах Линукс Центра, . После чего отнюдь не исключено, что он там скоро появится.

Однако предположим, что проблема получения дистрибутива была решена - и решена успешно.

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

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

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

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


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

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

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

Еще бывают проблемы с USB-мышами и, особенно, клавиатурами - не все разработчики дистрибутивов усвоили, что PS/пополамные грызуны (не говоря уже о COM'портовских) и их тети Клавы скоро разделят участь динозавров. Однако и эти проблемы отходят в прошлое. Правда, если они все же возникнут (как во многих версиях FreeBSD - с USB-клавиатурами), решить их можно только временной (на период установки и начальной конфигурации) заменой соответствующего дивайса его престарелым аналогом.

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



Не могу не воспользоваться случаем и не молвить пару слов во славу FreeBSD - в 5-й ее ветке проблем с контроллерами ATA RAID почти не бывает. А вот NetBSD, напротив, до недавнего времени знать о них не знала и не желала (насколько мне известно, начиная с версии 2.0 это, наконец, изжито). OpenBSD тут занимает промежуточное положение - диски на контроллерах ATA RAID она обычно распознает, но работать с ними может только как со стандартными IDE-винчестерами.

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

Во-вторых, внимательно ознакомиться с комплектацией дистрибутива. Многие из них (и здесь доброго слова заслуживает Slackware) оснащаются не одним ядром, а несколькими - в том числе и для поддержки всякого экзотического оборудования. Причем - с тщательно прокомментированными конфигурационными файлами, легко позволяющими понять, какое ядро для какого "железа" предназначено. Правда, не факт, что такие дополнительные ядра могут стартовать непосредственно с CD - тут-то и придется повозиться с загрузочными дискетами. Благо, процедура их создания под DOS/Windows описана в большем числе документов, чем возникает случаев необходимости обращения к ним.

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

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


Так что главное - установиться, а там видно будет, как сказал бы гражданин император Наполеоне Буонопарте.

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

Если с базовыми компонентами машины все в порядке - происходит запуск собственно инсталлятора. Однако перед этим во многих дистрибутивах выполняется (уже не ядром, а отдельной программой - в Linux ею обычно является kudzu) диагностика оборудования, не критичного для установки, но весьма важного для пользователя: звуковой и сетевой карт, принтера, модема, сменных накопителей, и т.д. И если оно будет опознано правильно - есть шанс получить их поддержку сразу по завершении установки, без дополнительных телодвижений.

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

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

Единственная тонкость касается как раз языка. В одних системах (примером - ASPLinux) язык установки (предположим, русский) никак не связан с базовой русификацией системы (последняя настраивается потом и отдельно). В других же, напротив, избежать последующей ручной русификации можно, только выбрав русский язык как используемый при установке (Mandrake, Altlinux). При этом подчас (помянем добрым ласковым русским словом некоторые версии Red Hat и Fedore'но Core) доходит до смешного: выбор русского языка при установке в некоторых ситуациях делает затруднительным ввод латиницы (и, как станет ясным из , вход в систему) сразу после перезагрузки. Так что - читайте документацию, ибо даже и user-ориентированная система может здорово спрашивать...

---

---