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

 

Вступление

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

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

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

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

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

Некоторое время после этого ничего не происходило.

Саги – не только литературные произведения, но и исторические источники, хотя и весьма своеобразные. И большая часть того, что в них описывается, происходило на самом деле. Так что иногда по косвенным данным (например, по сопоставлению с собственно историческими источниками из сопредельных стран, содержащих датировки в общепринятом для нас ныне формате) удаётся определить абсолютную продолжительность того «некоторого времени», когда не происходило ничего, заслуживающего быть помещённым в контекст сюжета саги. И оказывается, что такие периоды могли длиться годами, а то и десятилетиями. Для авторов и читателей саг они выпадают из течения времени, находятся вне его. А может быть, как предполагал Стеблин-Каменский, в это время для них времени просто не существовало…

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

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

Для чего нужно столь подробное введение? Обосную словами Мэтта Диллона, в прошлом одного из ключевых разработчиков FreeBSD, а ныне создателя её форка – операционной системы DragonFlyBSD:

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

Кроме того, история ОСей мира FOSS просто чрезвычайно увлекательна, а местами и полна драматизма, как хороший приключенческий роман. Надеюсь, на страницах этой книги мне удастся хоть в какой-то мере передать те чувства, которые испытывал сам, когда с нею знакомился.

 

Истоки и составные части

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

Во-первых, это академическая и университетская Computer Science эпохи «больших машин», в частности, работы по искусственному интеллекту.

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

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

В-четвёртых, это Берклиада – история, полная драматизма, в которой, как и в поэме Гомера, впервые переплелись перечисленные выше пряди. Но о ней будет подробно говориться в следующей главе.

В-пятых, это общественные движения – Open Source Software и Free Software. Здесь я немного отступаю от хронологии – второе формально предшествовало первому. До de facto первое явление существует как минимум со времён Ньютона и Лейбница.

В-шестых, это эволюция аппаратных платформ – от первых интерактивных рабочих станций до «народных» x86-совместимых компьютеров.

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

Причём о некоторых истоках и составных частях я умолчал сознательно – например, об эпохе Eniac'а и БЭСМ'ов, ибо нет у меня о них достаточно информации. Надеюсь, что...

... Кто-нибудь услышит, Снимет и напишет, Кто-нибудь помянет...

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

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

 

Computer Science и ARPANET

История академической Computer Science уходит в начало 60-х, время появления первых компьютеров, способных к интерактивной работе. Хотя они далеко ещё не были персоналками – но ведь ранее машины, как помнят читатели «Понедельника», почему-то начинавшегося тогда «в субботу», работали исключительно в режиме пакетных заданий. И влиять на это не могли не только маги вроде Кристобаля Хозевича и Фёдора Симеоновича, но даже всесильные научные администраторы, товарищи Камноедов и Лавр Федотыч.

Место же зарождения этой науки условно определим как крупнейшие американские университеты – Массачусетский Технологический Институт (MIT), Йель, Университет Карнеги-Меллона, Стэнфорд, Калифорнийский университет Беркли. Историческим центром этого движения долгое время была лаборатория искусственного интеллекта MIT (MIT AI – Artificial Intelligence). В недрах MIT AI родился, судя по многим свидетельствам, и термин «хакер» – так называли друг друга те, кто способен был «врубиться» в компьютерные науки. Но эта тема столь жёвана и пережёвана, что на ней мы останавливаться не будем

Работы же по созданию отказоустойчивой правительственной связи США, как нетрудно догадаться, начались по инициативе Министерства обороны этой страны. Ибо имели целью создание надёжной системы передачи информации на случай советского ядерного удара. Финансирование осуществлялась через ARPA – Агентство передовых исследовательских проектов (Advanced Research Projects Agency), которое позднее, без лишнего лицемерия, было переименовано в DARPA, с добавлением слова Defense (в данном контексте – Оборонных проектов). Запомним последнюю аббревиатуру – позднее эта организация сыграет немалую роль в нашей предыстории.

Непосредственная реализация системы связи была возложена на ряд американских университетов – Калифорнийский, Университет штата Юта, Стэнфорд. Потому что, как оказалось, кроме университетских хакеров из сферы Computer Science, разрабатывать и поддерживать её было попросту некому. А эти «ребята, за ту же зарплату», не только выковали электронный щит своей Родины в виде сети ARPANET (по имени организации-кормильца), но, будучи истинными учёными, воспользовались случаем в интересах науки. А именно – наладили бесперебойные каналы обмена информацией между своими Alma mater, создав таким образом сообщество ARPANET – прообраз грядущего Интернет-сообщества.

Первый сеанс связи в рамках проекта ARPANET состоялся 29 октября 1969 года в 21 час по местному времени. И оказался не вполне удачным: удалось передать только три символа, после чего сеть рухнула. Однако уже через два часа работоспособность её была восстановлена (учитесь, нынешние провайдеры!), и передача завершилась успешно. Интересно, что контроль передачи осуществлялся почти тем же методом, который изображён в фильме «Волга-Волга»: не с помощью рупора, конечно (от Лос-Анжелеса до Пало Альто докричаться проблематично), но по телефону.

Сеть ARPANET очень быстро охватила не только университеты, участвовавшие в её разработке, но и многие другие учебно-научные заведения Америки, а потом и сопредельных стран, став таким образом международной коммуникационной магистралью для обмена научной информацией. Правда, скоро её в этой роли сменила сеть Национального научного фонда США (NSF – National Science Foundation), создавшего свою сеть, NSFNet, обеспечивавшую большую пропускную способность. Именно на её базе и был создан современный Интернет.

 

Зарождение UNIX

Зарождение UNIX, как и сообщества Computer Science, также связано с появлением компьютеров, пригодных к использованию в интерактивном режиме, что создало предпосылки к разработке тех самых систем разделения времени, допускающих как бы одновременное исполнение нескольких задач (time sharing), которые пришли на смену машинам, работавшим исключительно в пакетном режиме. Одной из первых таких систем была CTSS (Compatible Time Sharing System).

Без академической составляющей, представленной в данном случае MIT, не обошлось и здесь. В развитие CTSS в 1965 году фирмами AT&T и General Electric вместе с MIT был начат проект по созданию истинно многозадачной и многопользовательской системы, которая получила имя Multics. По замыслу она была столь прогрессивной, что в те времена оказалась нереализуемой, и в 1969 году проект был закрыт, оставив среди его участников тоску по интерактивной работе и идею системы разделения времени, вскоре воплотившуюся в UNIX.

Правда, сама ОС UNIX вышла из корпоративных недр компании AT&T, сотрудниками которой являлись его создатели – бывшие участники проекта Multics. Однако это ни в коей мере не была корпоративная разработка: Кен Томпсон и Деннис Ричи разрабатывали её для собственных потребностей – это был первый в истории IT пример создания «системы для себя». В противоположность, например, системе VAX/VMS от фирмы DEC, которая претендовала на звание «системы для всех».

Правда, понятие «все» в случае c VAX/VMS охватывало весьма узкий круг, даже не столько лиц, сколько организаций. Но остаётся фактом, что система VAX/VMS разрабатывалась не для личного использования. Это наложило отпечаток не только на неё, но и предопределило судьбу её прямого потомка – Windows NT/etc.

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

Впрочем, усилия разработчиков были оценены должным образом, и достаточно быстро: в 1983 году Томпсону и Ричи была присуждена премия Тьюринга – самая престижная награда в информационной сфере. Которую по значимости можно сравнить с премией, учреждённой некогда Альфредом Нобелем «за выдающиеся научные исследования, революционные изобретения или крупный вклад в культуру или развитие общества». Что поделать – Нобель не мог и предполагать, что информационные технологии окажут на развитие общества не меньшее влияние, чем изобретённый им динамит.

А в 1999 году Томпсон и Ричи удостоились одной из высших наград государства, гражданами которого они являются: – Национальной медали в области технологий (National Medal of Technology, ныне – National Medal of Technology and Innovation). Которую им лично вручил человек, прославившийся обсуждением вопроса, является ли оральный секс основанием для обвинения в лжесвидетельстве. Ну и прочими мелочами, типа приказа о бомбардировке Югославии. От чего, впрочем, награда эта не становится менее почётной...

На дальнейшую судьбу UNIX огромное влияние оказали юридические коллизии тогдашнего текущего момента. Незадолго до создания этой системы корпорация AT&T подверглась антимонопольному преследованию, в результате чего претерпела поражение в правах – на деятельность её был наложен ряд ограничений. В частности, она не имела права торговать программными продуктами, в число коих попадала и новорождённая UNIX.

Разумеется, материнская корпорация постаралась пристроить к делу создание своих сотрудников – в частности, UNIX с его инструментарием использовался в AT&T для подготовки технической и патентной документации. Что, кстати, представляет собой типичную пользовательскую задачу. И скажите мне теперь, что UNIX не пригоден для применения конечными пользователями.

Однако, как уже было сказано, в силу юридических ограничений AT&T не могла сделать из UNIX коммерческий продукт. И потому исходники этой системы, начиная с 1974 года, стали распространяться в университетах – в образовательных, как это тогда задумчиво называлось, целях. На условиях по тем временам достаточно либеральных, в том числе, и просто явочным порядком, лично Брайаном – люди с психологией сталинских наркомов, которые могли сказать: «под мою ответственность», встречались не только в Советском Союзе…

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

Однако, во-первых, все эти действия требовали обладания лицензией на исходный код UNIX, которая передавалась AT&T вместе с ней самой и её исходниками, но – за деньги, хотя и не очень большие по масштабам американских организаций середины 70-х годов прошлого века. В личное же пользование лицензии на UNIX тогда ещё не приобретали.

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

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

Выйдя за стены Bell Labs, UNIX зажил самостоятельной жизнью, крепко окопавшись в той же университетско-академической среде Computer Science. Одним из её центров в данном случае оказался Калифорнийский университет Беркли – учреждение, известное всем, интересовавшимся историей как точных наук, так и их влиянием на нашу жизнь.

Получив, благодаря профессору Бобу Фабри (Bob Fabry), в 1974 году ОС UNIX вместе с её исходниками и лицензией на их использование, университет Беркли поддержал и развил традицию «систем для себя», свойственную первозданному UNIX. Но об этом – в следующей главе. А пока – о «железных» предпосылках.

 

«Железные» предпосылки

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

Материалы, касающиеся истории вычислительной техники, принято вести с тех времён, «когда компьютеры были большими». Нашу же историю мы, напротив, начнём с того момента, когда компьютеры начали становиться маленькими, за что и получили имя миникомпьютеров.

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

На одном из таких миникомпьютеров, PDP-7 производства фирмы DEC, и был разработан первозданный UNIX. Который, впрочем, быстро утратил связь с родительской платформой: после того, как основная системы часть была переписана на языке Си (специально созданном для разработки этой ОС), возникли условия для относительно легкого ее портирования на любое «железо». И долгое время миникомпьютеры различных типов (в основном PDP-11 и пришедшие им на смену во второй половине 70-х машины серии VAX), как наиболее демократические платформы того времени, оставались основной средой для разработки и использования UNIX.

Попавший в Беркли UNIX также первоначально был инсталлирован и работал на 16-битных миникомпьютерах PDP-11, и программные наборы 1BSD и 2BSD (собственно системами, как говорилось ранее, их назвать было еще нельзя) разрабатывались на них и для них.

Однако в 1977 году на свет вышли первые миникомпьютеры VAX, уже 32-битные. Разумеется, первозданный UNIX, ставший к тому времени вполне кросс-платформенным, обзавелся для них соответствующей версией, носившей имя UNIX/32V. Однако и берклианская ветвь не осталась в стороне от прогресса: 3BSD – первая целостная система из Беркли уже в 1979 году была портирована на VAX, причём с эффективным использованием всех его аппаратных возможностей, в частности, виртуальной памяти. Именно тогда и сложилась та самая парадоксальная ситуация, о которой я говорил выше: пользователи VAX-машин вынуждены были получать (то есть покупать) лицензию на использование 32V, однако устанавливали и применяли на практике 3BSD, а затем и 4BSD.

Однако миникомпьютеры доживали свой век – на смену им серверы и рабочие станции на фантастически мощных по тем временам RISC-процессорах, объединённые в сети с клиент-серверной архитектурой. Они уже имели вид, подобный обычным персоналкам – с системным блоком, монитором и клавиатурой, а затем и мышью, а рабочие станции к тому же находились в индивидуальном пользовании.

Первые рабочие станции выпустила в 1981 году фирма Apollo. Они были основаны на процессоре Motorola 68000, имели сетевые интерфейсы и объединялись в клиент-серверные сети. Однако операционной системой для них был не UNIX, а собственная разработка – Aegis, позднее переименованная в DOMAIN/OS. Впрочем, ни под тем, ни под другим именем с UNIX она была несовместима, хотя, как говорят, и была с ней сходна внешне, в частности, своим командным интерфейсом.

Машины Apollo, носившие название DN100, были сами по себе дороги, а разработка софта для них, вследствие своеобразия закрытости операционки, обходилась ещё дороже. Что открывало путь к созданию альтернативных решений – более дешёвых и совместимых.

И такое решение появилось мгновенно. В том же 1981 году аспирант Стэнфордского университета Энди Бэчтольшайм (Andy Bechtolsheim), участвуя в работах по созданию сети для своей альма-матер, из отходов производства собрал машину на том же процессоре Motorola 68000. А в 1982 году он вместе Винодом Хосла (Vinod Khosla) основал компанию SUN, что первоначально расшифровывалось как Stanford University Networks, но быстро обрело «солнечную» символику – интересно, не читали ли основатели Луч света в тёмном царстве? Чуть позже третьим к ним присоединился Скотт МакНили (Scott McNealy).

«Трое появились не случайно» – они поставили себе целью создать мощный, но относительно дешёвый компьютер, основанный на стандартных промышленных компонентах. Затея эта удалась – и на протяжении 80-х годов одна за другой выпускаются машины Sun-1, Sun-2, Sun-3, основанные на процессорах Motorola 68XXX.

Стандартизация аппаратной части требовала столь же стандартной операционной системы, каковая могла основываться только на UNIX. И разработкой её занялся Билл Джой, тот самый, который, как мы увидим в главе второй, до того активно участвовал в создании BSD. И нет ничего странного в том, что именно она и была положена в основу новой ОС.

То был отнюдь не единственный пример портирования UNIX на платформу 68XXX. Мало кто ныне помнит, но, например, Apple разрабатывала собственную версию ее, под названием AUX, задолго до MacOS X – чуть не сразу после появления первого Mac’а.

Однако UNIX портировался не только – и не столько – на машины с процессором 68XXX. «Дурной пример» Sun оказался заразительным – и этим путём пошли такие разработчики собственных платформ, как IBM, Hewlett-Packard, DEC. Именно они стали и разработчиками собственных же вариантов UNIX.

 

Компьютеры для народа

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

А поначалу – ничего. Первый широко распространившийся персональный компьютер, собственно IBM PC и развивавший его линию IBM PC/XT, базируясь на внутренне 16-разрядных процессорах Intel 8088 и 8086, работать под исходно 32-битной UNIX не мог, как не способна была на это и персоналка следующего поколения, IBM PC/AT на процессоре Intel 80286.

Только появление в 1985 году первого 32-разрядного процессора от Intel – 80386, дало возможность использовать UNIX на дешевых и общедоступных персоналках. Так что именно здесь пролегала магистральная линия массовой компьютеризации – по всему миру шло триумфальное шествие Советской власти (то есть, пардон, Intel-совместимых PC).

Но под чем же работало все это аппаратное богачество? Да в подавляющем большинстве – под MS DOS, 16-разрядной операционной системой, созданной ещё для первых IBM PC и несущей в себе массу неустранимых ограничений: принципиальную однозадачность, отсутствие многопользовательского доступа, возможность использовать «по прямому назначению» лишь 640 Кбайт оперативной памяти, примитивную организацию файловой системы, не менее примитивные средства работы в текстовом режиме – единственно возможном силами «черного» DOS.

Конечно, предпринимались многочисленные попытки заретушировать «родимые пятна» DOS. Разрабатывались надстройки над ней, способные использовать вес физический объём оперативной памяти и многозадачность, такие, как QuaterDesq и Geoworks. Которые включали также и системы работы в графическом режиме. Некоторые пользовательские DOS-приложения (табличные процессоры Lotus 1-2-3 и QuattroPro, текстовый редактор WordPerfect) обзаводились собственными средствами управления памятью и графическими интерфейсами.

Вся эта многочисленная DOS-косметика была либо неудачной, либо не получила распространения. Конечно, существовала и альтернатива ей – разрабатывавшаяся в IBM операционка OS/2, первая 32-разрядная ОС, специально написанная для PC. Однако и она, не смотря на весьма прогрессивный базис, не приобрела широкой популярности. О причинах этого можно было бы вспоминать долго – не последней оказалось исключительно пофигистское отношение производителя к своему детищу.

Сложилась парадоксальная ситуация: «народная», то есть общедоступная, платформа не имела адекватной «народной» же операционки, способной использовать её возможности. И в следующей главе мы проследим зарождение и развитие первой претендентки на этот титул.

Увы, претензии эти оказались не реализоваными. А «свято место» массовой операционки для настольных персоналок оставалось пусто вплоть до 1995 года – появления Windows 95. Началась эра гегемонии платформы Wintel (то есть машин на Intel-совместимых процессорах под управлением ОС Windows). И гегемония эта практически не поколеблена и по сей день. Не смотря на несколько попыток борьбы с ней в 90-е годы. Не смотря на тщившиеся стать народными Mac'и во всех их проявления. Не смотря на все успехи последних лет в продвижении Linux. Но об этом – позднее.

 

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

 

«Похищение Елены Прекрасной»

В разделе о зарождении UNIX предыдущей главы упоминался профессор Фабри, который принёс свет UNIX’овой мысли в стены Университета Беркли. Где система попала в условия открытого общения специалистов в области Computer Science самого разного ранга, от профессоров до аспирантов – именно такой статус имели во второй половине 70-начале 80-х годов прошлого века Билл Джой (Bill Joy, в последующем, как мы уже видели, один из основателей компании Sun), Маршалл Керк МакКузик (Marshall Kirk McKusick), Озалп Бабаоглу (Özalp Babaoğlu). Их усилиями, вкупе с другими сотрудниками университета, система UNIX медленно, но верно превращалась именно в то, чем она стала ныне. Достаточно сказать, что на счету «ранних берклианцев» разработка системы управления виртуальной памятью, концепции сокетов для взаимодействия между процессами, текстовый редактор vi, ставший в лице своего клона Vim неотъемлемой частью всех UNIX-подобных систем, и командная оболочка C-shell (csh), положившая начало интерактивным методам работы в командной строке.

Нам, избалованным мощными и красивыми текстовыми редакторами для графического режима (или, по вкусу, изощрёнными возможностями нынешнего Vim’а), современными командными оболочками типа bash и zsh, трудно сейчас оценить, какую роль в дальнейшем развитии UNIX-подобных систем сыграли vi и csh, выглядящие сегодня столь невзрачными.

Сотрудники Беркли оказались первыми и в организации распространения результатов своих работ. Этой цели служила Berkely Software Distribution или, сокращённо, BSD – система распространения разработанного в университете софта на магнитных лентах, от которой в конечном итоге происходит всё многообразие форм BSD- и Linux-дистрибуции.

Первые выпуски BSD (1BSD и 2BSD), вышедшие в 1978 году, ещё не представляли собой цельных систем, а содержали лишь набор утилит и приложений собственной разработки. О какой-либо системной целостности можно говорить, начиная с 3BSD (1979 год) – правда, целостность эта в значительной мере была обусловлена включением компонентов собственно UNIX.

Однако именно выпуск 3BSD послужил причиной тому, что команда UNIX-разработчиков Беркли получает в 1980 году грант упоминавшегося в прошлой главе DARPA с целью разработки протокола передачи данных для сети ARPANET, который ныне известен как протокол TCP/IP.

Практически одновременно с получением гранта DARPA Бобом Фабри формируется команда CSRG (Computer System Research Group), которая объединила всех трудящихся университета Беркли (и не только его), связанных с развитием берклианской ветви UNIX. Начиная с октября 1980 года, на протяжении двух с небольшим лет эта группа последовательно выпускает 4BSD, а затем 4.1BSD в нескольких версиях: собственно 4.1BSD – июнь 1981 года, 4.1a, 4.1b и 4.1c (1982—начало 1983 года).

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

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

Такое положение вещей, противоречащее здравому смыслу, не могло продолжаться вечно – и скоро мы узнаем, каким образом оно разрешилось. Но сначала прервём линейность истории, обратившись к вопросу, откуда пошёл свободный софт.

 

Начало свободного софта

Говоря в главе первой об истоках и предпосылках истории FOSS, я упомянул общественные движения Open Source Software и Free Software, однако больше не прибавил о них ни слова. Настало время восполнить это упущение.

Под открытым и свободным программным обеспечением, для которого закрепилась аббревиатура FOSS, понимается два близкородственных, но не вполне идентичных понятия – программное обеспечение с открытыми исходными текстами (Open Source Software) и собственно свободное программное обеспечение (Free Software).

Читатель, знакомый с современным положением дел вокруг так называемого СПО, вправе задать мне вопрос: почему названия из предыдущего абзаца стоят именно в таком порядке? Ведь каждому ребёнку известно, когда Ричард Столлман, известный в миру как RMS, создал Фонд Свободного Программного обеспечения и основал проект GNU, и когда из уст Эрика Рэймонда, не менее известного как ESR, впервые прозвучало словосочетание Open Source Software. Попробуем разобраться.

Движение Open Source организационно оформилось в 1998 году. Однако зародилось оно очень давно – и в тех же академических кругах Computer Science. Собственно, первоначально никакого движения не было – а была лишь обычная, принятая в любой науке, практика свободного обмена результатами своей работы. Благо, ARPANET, а затем и Интернет предоставили к тому практически неограниченные возможности. Да и необходимости в движении не возникало – никакого другого софта, кроме открытого, просто не было в природе.

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

Суть её была очень проста: с исходниками BSD UNIX можно было делать всё, что угодно, кроме как приписывать себе их авторство. Правда, была там и так называемая «оговорка о рекламе» – требование упомянуть регентский совет Университета Беркли в любом производном продукте, но со временем она была изъята.

Поскольку усовершенствования первозданной UNIX, пришедшие из Университета Беркли, были очень существенными, результатом этого было расщепление UNIX на две ветви – проприетарную UNIX от AT&T, за которой со временем закрепилось название System V, и BSD UNIX, распространявшуюся свободно. Впрочем, в силу открытости берклианских разработок, они быстро были инкорпорированы и в System V (начиная с её Realese 4, говорить от первозданном UNIX уже не приходится).

Обе ветви UNIX, System V и BSD UNIX, сосуществовали мирно, подобно капитализму и социалиализму. Однако лишь до поры, до времени – пока не появилась юридическая возможность коммерческого распространения UNIX, само это слово (в форме UNIX) не стало торговой маркой, соответствие которой должно сертифицироваться, – короче говоря, пока не запахло «баблом».

И вот тут-то формальные правообладатели UNIX вспомнили, что в составе BSD-системы имеется некоторое количество кода, являющегося их «интеллектуальной собственностью», и затеяли судебный процесс против Университета Беркли, о чём речь пойдёт в скором времени.

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

Тем временем Ричард М. Столлман, сотрудник той самой MIT AI, боролся с прикручиванием принтера от HP к своей системе. И боролся безуспешно – поскольку товарищи от Хьюлетта и Паккарда отказались предоставить ему исходники на своё firmware. Что привело Столлмана к убеждению – закрытые исходники суть тормоз прогресса, и все программное обеспечение должно быть открытым и свободным. Начался крестовый поход за освобождение софта.

К середине 80-х годов прошлого тысячелетия RMS создаёт Фонд свободного программного обеспечения (FSF – Free Software Foundation), начинает проект GNU – воспроизведение функциональности UNIX «с чистого листа», но в свободном исполнении, а главное – формулирует принципы Free Software: свобода использования, свобода изучения и модификации, свобода распространения.

Знакомый велосипед, не правда ли? Да, именно на таких условиях распространялись результаты работ сообщества Computer Science (как, впрочем, и любого иного научного сообщества). Новым в принципах RMS, нашедшим своё выражение в разработанной под его руководством (и с участием профессиональных юристов) лицензии GPL (General Public License), было только одно: любая программа, использующая код, защищаемый GPL, должна распространяться на тех же условиях – ныне, присно и во веки веков…

В рамках проекта GNU (что расшифровывается просто – GNU is not UNIX) были разработаны функциональные аналоги всех классических UNIX-утилит и пользовательских приложений, из которых важнейшим (и до сих пор единственным незаменимым) оказался компилятор языка Си (gcc – GNU C Compiler).

Участники проекта GNU, работавшие первоначально на чистом энтузиазме, за считанные годы воссоздали все системное окружение полноценной ОС. За одним единственным исключением – ядра. Но тут уже начинается история из главы четвёртой. А мы продолжим нашу Берклиаду.

 

Возвращение в Беркли

Оно ознаменовалось тем, что в августе 1983 года была выпущена система 4.2BSD – та самая, на разработку которой собственно и был получен грант DARPA. К этому времени Билл Джой, сыгравший большую роль в разработке предыдущих версий, покинул Университет Беркли и стал соучредителем новой компании Sun Microsystems (о чём – в следующей главе). На первые же роли в проекте BSD вышли Майк Карелс (Mike Karels) и Керк МакКузик.

Система 4.2BSD аккумулировала в себе как все ранние достижения берклианской мысли, так и разработки, выполненные уже в рамках CSRG и как бы «порционно» появлявшиеся в последовательности версий 4.1BSD. Из которых главнейшими были протокол TCP/IP и новая файловая система FFS (Fast File System).

О значении TCP/IP много говорить не приходится: если вы читаете эти строки, значит, тем или иным образом имеете доступ в Интернет. Так вот, без TCP/IP ничего этого не было бы: ни Интернета, ни «одноглазникофф ффконтакте», ни самой этой книги.

А чтобы понять значение FFS, достаточно вспомнить что все файловые системы современных UNIX’ов, как свободных, так и проприетарных, берут своё начало именно от неё, если не прямо, то опосредованно, через развитие заложенных в ней принципов.

Так что система 4.2BSD не только предопределила направление развития всех последующих представителей BSD-семейства, но и оказала большое влияние на UNIX «чистой линии». А также – будущей героини нашего повествования, ОС Linux.

Линия BSD рано начала давать боковые отростки. Из них одними из главных, в рамках нашего повествования, стали микроядерные операционки, в первую очередь ядро Mach, разрабатывавшееся в Университете Карнеги-Меллона, а затем – в университете штата Юта. Некогда оно рассматривалось как прообраз операционных систем будущего, однако на практике возлагавшихся на него надежд не оправдала. Сам по себе проект Mach давно прекратил своё развитие, так что главная слава Mach оказалась посмертной. Ибо под его воздействием Энди Танненбаум написал свою игрушечную систему MINIX, которая вдохновила Линуса Торвальдса на написание Linux.

Пора опять возвращаться к магистральной линии развития BSD. Каковая после выхода 4.2BSD, оказавшейся переломной в развитии этой системы, приобрела плавно поступательный характер. Новые релизы появляются относительно редко: выход 4.3BSD датируется июнем 1986 года, а её последовательных инкарнаций – 4.3BSD-Tahoe и 4.3BSD-Reno – июнем 1988 и началом 1990 года соответственно.

Выход следующего релиза, 4.4BSD, который готовился как квинтэссенция всей предшествующей Берклиады, был запланирован на 1993 год. И действительно произошёл почти в установленные сроки. Однако ему суждено было стать и последним в ряду всех систем линии 4.xBSD: потому что в интервале 1990-1993 года случилось несколько событий, которые в своей совокупности изменили весь ход истории свободных операционных систем.

 

Интермедия

Итак, мы остановились на моменте выхода 4.3BSD и двух её последовательных инкарнаций – 4.3BSD-Tahoe и 4.3BSD-Reno. Базовой платформой для всех них был VAX. Однако в 4.3BSD-Tahoe обособлены машинно-зависимые и машинно-независимые части кода, что создавало предпосылки для грядущего портирования на иные архитектуры, планировавшиеся в версии 4.4. А 4.3BSD-Reno и была прототипом этой грядущей ветки, предназначенным для обкатки намечавшихся новшеств.

Параллельно с основными выпусками 4.3BSD было подготовлено ещё два как бы дополнительных – 4.3BSD Net1 (март 1989 года) и 4.3BSD Net2 (июнь 1991 года). Основываясь на 4.3BSD-Tahoe и 4.3BSD-Reno соответственно, они содержали исключительно компоненты, разработанные в Беркли и полностью освобождённые от какого-либо кода первозданного UNIX. И потому могли распространяться свободно как в бинарном виде, так и в виде исходных кодов.

Название выпусков 4.3BSD Net1 и Net2 связано с тем, что они замышлялись как подборки инструментария для работы с сетями – главным образом, по протоколу TCP/IP. Таково было пожелание пользователей, нуждавшихся в этих средствах, но по тем или иным причинам не испытывавших потребности в лицензировании собственно UNIX-кода. Однако, как мы увидим далее, значение этих выпусков скоро переросло поставленные первоначально скромные цели.

И 4.3BSD Net1 стал первой системой из Беркли, которая распространялась под лицензией BSD (ещё в первом её варианте, включавшем «оговорку о рекламе»).

Номинальная цена за ленту 4.3BSD Net1 была установлена в 1000 долларов. Однако, поскольку лицензия это не запрещала, далее копии ленты могли распространяться совершенно свободно, копироваться, устанавливаться на любое количество машин, передаваться и даже выкладываться на анонимные ftp-сервера. Что, разумеется, и происходило – однако, по свидетельству очевидцев этой истории, немало организаций не сочли западло для себя заплатить указанную сумму. Причём не столько ради получения самого кода – его, как уже сказано, можно было получить и бесплатно, сколько для финансовой поддержки проекта.

Подобная практика распространения продолжалась и после выхода 4.3BSD Net2. И опять с тем же результатом – несмотря на возможность откровенной и вполне законной халявы, нашлось немало контор и даже частных лиц, которые выложили 1000 баксов за обладание дистрибутивной лентой. Среди таковых оказался и Грег Лией – в последующем один из ключевых разработчиков FreeBSD.

Факт столь массового спроса на 4.3BSD NetX тем более примечателен, что ни первый, ни второй её выпуск не содержал самодостаточной, загружаемой ОС, а включал только системное обрамление и комплекс утилит, в первую очередь, для работы с TCP/IP. И пользователи, кем бы они ни были, организациями или частными лицами, покупали её на свой страх и риск, так как превращением её в законченную ОС они должны были озаботиться сами.

В ходе подготовки выпусков 4.3BSD Net1 и Net2 обнаружилось, что проприетарного (то есть патентованного) кода первозданного UNIX, права на который к тому времени перешли к USL (UNIX Systems Laboratory – дочерняя компания AT&T, созданная специально для продвижения этой системы) в составе берклианских UNIX’ов осталось не так уж и много. И родилась идея создания полностью открытой, свободно распространяемой операционной системы BSD. Правда, даже в наиболее полном выпуске 4.3BSD Net2 недоставало нескольких ключевых фрагментов, которые превратили бы его в полноценную операционную систему, полностью свободную от наследия UNIX. Их и следовало воспроизвести в первую очередь.

Примерно в это же время прекращается финансирование проекта BSD со стороны DARPA. Есть подозрение, что причиной тому послужил распад мировой системы социализма – всё в жизни имеет свою оборотную сторону, даже крах коммунистической идеологии. И хотя CSRG просуществовала ещё несколько лет (как структурное подразделение, она была расформирована в 1995 году), ряд её сотрудников начал подыскивать себе другие занятия.

В числе их оказались Билл Джолитц (Bill Jolitz) и Линна Джолитц (Lynne Jolitz). Они поставили своей целью, во-первых, воспроизвести недостающие звенья между 4.3BSD Net2 и полноценной ОС, а во-вторых, портировать новообразованную систему на ту самую демократическую платформу того времени – на i386.

Обе задачи были успешно решены в течении полугода после выпуска 4.3BSD Net2. И в результате в январе 1992 года свет увидела работоспособная система под названием 386BSD, первая из всех берклианских систем, полностью свободная от проприетарного кода, и первая же, адаптированная для машин с процессором i386, что и было вынесено в её титулатуру.

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

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

 

FreeBSD: рождённая свободной

И тогда из среды энтузиастов системы выдвинулась группа координаторов «заплаточного» проекта, получившего условное название 386BSD 0.5 или 386BSD Interim. В их числе были Джордан Хаббард (Jordan Hubbard, ныне работающий в фирме Apple директором по технологиям UNIX), Нейт Вильямс (Nate Williams) и Род Граймс (Rod Grimes), оказавшиеся самыми последовательными приверженцами patchlit’ов. Они разработали промежуточный снапшот системы, очищенный от «заплаточных» излишеств.

Однако планы «тройки по борьбе с басмачами» (пардон, заплатками) были нарушены, когда Джолитц окончательно прекратил поддержку своего проекта, не оставив ясных указаний насчёт того, что уже сделано, и что надлежит сделать далее. Но это уже не смогло остановить развитие проекта. А примкнувший к нему Дэвид Гринмен (David Greenman) придумал для него и имя – FreeBSD.

Вахта же Хаббарда выразилась в том, что он наладил контакт с компанией Walnut Creek CDROM, образовавшейся незадолго до этого (в 1991 году) для распространения всякого рода Free- и Shareware (а также и собственно Free Software) на компакт-дисках. Если вспомнить, что до превращения CD-приводов в стандартный атрибут настольных персоналок оставалось ещё несколько лет, можно оценить степень новаторства этой фирмы.

Общепринятым способом распространения сколько-нибудь объёмного программного обеспечения (за исключением коммерческого «коробочного») в те годы были публичные ftp-сервера. Однако доступ к Интернету, по крайней мере, для частных лиц, был тогда ещё большей экзотикой, нежели CD-привод в индивидуальном десктопе. И Хаббард предложил совершенно новую по тем временам идею – распространение дистрибутива операционной системы на компакт-дисках. Это если и не предопределило успех проекта, то немало ему способствовало.

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

FreeBSD 1.0 включала в себя компоненты из BSD4.3 Net 2, 386BSD и её «заплаточного» проекта, а также ряд утилит, разработанных в рамках проекта GNU. Он имела большой успех, который был закреплён и развит выпуском в мае 1994 года версии FreeBSD 1.1.

 

Технологический детектив

Система 386BSD и её наследница FreeBSD были не единственными попытками создания BSD, свободной от проприетарного кода. Еще один вариант был реализован созданной в 1991 году фирмой BSDI (Berkeley Software Design Incorporated) – но уже как коммерческий.

Фирма BSDI занялась разработкой собственной BSD-системы, взяв за основу всё ту же ленту 4.3BSD Net2. Возникшая в результате система получила имя BSD/386 (в дальнейшем она была известна как BSDi и BSD/OS) и стала распространяться в бинарном виде вместе с исходниками по цене 995 долларов под первым вариантом лицензии BSD.

Упоминание Калифорнийского университета и Регентского совета как создателей и владельцев распространяемой системы, присутствовавшее в первом варианте BSD-лицензии, делало фирму как бы сопричастной последнему – тем более, что она была образована бывшими сотрудниками CSRG. Среди них был и Ричард Стивенс (Richard Stevens), главный разработчик BSD/OS, известный также как автор книг по UNIX и протоколу TCP/IP (он скончался в 1999 году в возрасте 48 лет).

Не менее важным, чем причастность BSDI к Калифорнийскому университету, обстоятельством для дальнейших событий оказалось то, что её система позиционировалась, как UNIX, и заказ её можно было осуществить, обратившись по номеру телефона, содержащему слово UNIX. А слово это стало к тому времени торговой маркой, под владением USL, дочерней фирмы AT&T. Которая как раз в это время получила, наконец, право коммерческого использования UNIX. И результаты не замедлили воспоследовать, поскольку, как уже говорилось ранее, в воздухе отчётливо запахло «баблом».

Первые претензии со стороны USL, однако, касались только компании BSDI и затрагивали лишь рекламную сторону дела: использование последней торговой марки UNIX без соответствующего лицензирования и «вводящего в заблуждение» телефонного номера. Обе они были не лишены резона и немедленно удовлетворены: номер был снят, а соответствующие службы компании BSDI переформулировали свои рекламные материалы, популярно объясняя потенциальным покупателям, что BSD/386 является не совсем UNIX’ом.

Однако вслед за этим в USL вспомнили, что в составе BSD-систем имелось некоторое количество кода, являющегося их «интеллектуальной собственностью», и вчинили уже настоящий судебный иск. Сущность его сводилась к тому, что BSDI, кроме проприетарного кода UNIX, распространяет фирменные секреты USL, чем наносит оной непоправимый финансовый урон, и к требованию прекратить продажи BSD/386.

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

Поскольку добиться успешного решения суда в «деле о шести файлах» показалось USL проблематичным, она переформулировала иск, включив в число ответчиков, кроме BSDI, также и Калифорнийский университет, а содержание его распространив на всю BSD-систему в виде 4.3BSD Net2, требуя теперь запрета на распространение и этой последней,

В таких случаях сначала проводится предварительное слушание, определяющее, может ли иск составить предмет рассмотрения в суде, которое и происходит при положительном ответе на этот вопрос.

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

Штат CSRG перешёл от написания кода к написанию нескольких сотен страниц материалов, которые были использованы в юридических сводках.

Наконец, в декабре 1992 года состоялось предварительное слушание, которое проводил судья Федерального суда в Нью-Джерси (штат, в котором располагалась штаб-квартира USL), Диккинсон Р. Девебуа – по причинам, которые станут ясны через несколько строк, имя его должно быть упомянуто в ряду создателей и разработчиков BSD и FreeBSD. Он не принял немедленного решения по иску, а решил подробнее рассмотреть материалы. Это заняло у него шесть недель, по прошествии которых было вынесено решение: большинство обвинений USL отклонялось, за исключением двух пунктов, касавшихся авторских прав и возможности утраты фирменных секретов. И, кроме того, было предложено рассматривать дело в суде штата, а не в федеральном суде.

Это судьбоносное решение было вынесено в пятницу вечером. А уже в понедельник утром Калифорнийский университет вчинил компании USL встречный иск, касавшийся нарушения USL лицензии BSD, под которую подпадал заимствованный ими из BSD-систем код. То есть при распространении UNIX в сопроводительной документации не упоминался Калифорнийский университет как разработчик и собственник заимствованного кода (а бесспорных заимствований из BSD в SVR4 было немало). Вот тут и сыграла свою роль та самая «оговорка о рекламе» в первоначальной версии лицензии BSD, за которую она подвергалась нападкам со стороны пуристов Free Software, начиная с Ричарда Столлмана.

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

Однако скоро накал страстей спал. В 1993 года USL вместе со всеми её торговыми марками и правами, реальными и мнимыми, была куплена у AT&T фирмой Novell. Рэй Нурда (Ray Noorda), бывший тогда её CEO, выразился в том смысле, что предпочитает конкурировать на рынке, а не сквалыжничать в суде. И постарался оказать максимально возможное воздействие на руководство USL, дабы решить вопрос полюбовно.

К слову замечу, что Рэй Нурда, обеспечив славу Novell, как ведущей компании в области сетевых технологий (»ну кто же не помнит старика Нетваря»?), через пару лет покинул её и основал фирму Caldera, на протяжении ряда лет выпускавшую весьма прогрессивный дистрибутив Linux – Caldera OpenLinux. Он отошёл от дел на рубеже тысячелетий и скончался в 2006 году, в возрасте 82 лет. Ему не суждено было увидеть того юридического шоу, которое устроила по поводу собственности на код UNIX SCO – компания, в которую преобразовалась основанная им Caldera. Иска, почти зеркально повторившего дело USL vs Berkeley, но ещё менее обоснованного и завершившегося с существенно более печальными последствиями для истца. Воистину, история мстит забывшим её тем, что имеет обыкновение повторяться.

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

 

Цена свободы

Казалось бы, детективная история разрешилась вполне благополучно, не так ли? Однако на этот счёт существуют неоднозначные мнения. Согласно Керку МакКузику (а он был тогда связан именно с разработкой 4.4BSD в рамках CSRG), воссоединение всех берклианских побегов в лоне едином вызвало лишь кратковременную задержку в их разработке, которая в итоге оказалась

… благом, поскольку она заставила различные группы повторно синхронизировать наработки, сделанные за три года с момента первого выпуска CSRG Networking Release2.

Джордан Хаббард, который тогда занимался разработкой непосредственно FreeBSD, смотрит на ситуацию тех дней не столь оптимистично, полагая, что система 4.4BSD-Lite

… была в прямом смысле light, в частности, потому, что группа CSRG удалила большие куски кода, необходимого для создания реально загружающейся системы (по причине различных лицензионных требований), и фактически, порт 4.4BSD для платформы Intel был очень неполным.

Как можно заключить из слов Хаббарда, в тот момент катастрофа проекта казалась неизбежной – легким движением руки цельная и работоспособная система превратилась в симпатичнейшего уродца. Но, как сказал один из героев Профессора, «приключения никогда не кончаются». И участники проекта FreeBSD приступили

… к сложнейшей задаче буквально пересоздания системы с нуля на основе абсолютно новой и довольно неполной системы 4.4BSD-Lite.

Реинкарнация недостающих фрагментов заняла около года. И в итоге 22 ноября 1994 года было объявлено о выходе первой версии возрождённой FreeBSD – 2.0, которая, несмотря «на множество недотёсаных углов», снискала значительный успех. А главное – к лицензионной её чистоте не смог бы придраться ни один сутяга. Именно она положила начало традиции, не прерывающейся и поныне.

Тем не менее, момент, благоприятный для «народной системы для народной платформы», был упущен: ниша эта оказалась плотно занята, во-первых, главной системой для простого народа в лице Windows 3.1/3.11, а чуть позже и Windows 95. А на роль системы альтернативной, для народа не совсем простого, выдвинулся Linux в лице первых своих дистрибутивов: Slackware, Debian, Red Hat, чуть позже Suse.

Существует мнение, что если бы BSD (еще не разделившаяся на Net- и FreeBSD) не погрязла бы в тяжбе с AT&T и получила бы свободу в конце 80-х – начале 90-х годов, то в разработке Linux не было бы никакой необходимости. Несмотря на свою пылкую любовь к BSD-системам во всех их проявлениях, не могу с этим согласиться: если бы Linux’а не было – его следовало бы изобрести. Потому что без него (и внедрённого Линусом в IT-индустрию метода разработки софта, о котором я говорил ранее) жить было бы скучно…

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

И хотя главная интрига нашего исторического сюжета позади, в будущем FreeBSD будет еще один драматический поворот, о котором мы расскажем в своё время. А сейчас зададимся вопросом – почему же эта ОС не стала системой для пользователя? Ведь, казалось бы, наконец претендент на звание народной ОС для народной платформы определился. Однако эта роль – стать народным десктопных UNIX’ом – выпала на долю системы, которая в это самое время зародилась в других краях и на другой почве. Со временем ответ на этот вопрос придёт. Но прежде мы вернёмся немного назад, к моменту вскоре после расщепления первозданного UNIX'а на ветки System V и BSD.

 

Хотя изложение истории проприетарных UNIX'ов не является предметом данного сочинения, они развивались параллельно с «UNIX'ами» свободными, и обе ветви оказывали друг на друга влияние. Так что время от времени нам придётся обращаться к этой сюжетной линии. Один из таких моментов наступил.

 

Серенада солнечной долины

Вернёмся к тому моменту, когда Билл Джой взялся за разработку ОС для только что появившихся компьютеров Sun. В основу своей системы он положил 4.1BSD, разработчиком которой перед тем являлся. А во главу угла её поставил ориентацию на поддержку компьютерных сетей и интеграцию с ARPANET, а в последующем – и Интернет.

Именно Биллу принадлежит знаменитый лозунг: Сеть – это Компьютер (The Network Is The Computer). Что вполне может быть инвертировано в: Компьютер – это сеть. Правда, выдвинут он был позднее, в середине 90-х годов, уже в эпоху Интернета.

Поддержка сетей в SunOS базировалась на ставших тогда почти стандартными протоколах Ethernet и TCP/IP. Именно из недр Sun вышли понятие виртуальной файловой системы – VFS, реализация сетевой файловой системы – NFS, множество средств удалённого доступа (RPC, Remote Procedure Calls) и так далее.

Далее, в SunOS большое внимание уделялось поддержке масштабируемости систем. Подразумевалось, что одна и та же ОС должна работать как на многопроцессорных серверах, так и на любых подключённых к ним рабочих станциях. С этим тесно связана и поддержка многопроцессорности, столь востребованная в наши дни. Конечно, и масштабируемость, и поддержка многопроцессрности не были уникальными для SunOS – этим же путём шли разработчики всех коммерческих UNIX. Однако Sun здесь была в числе первых – это раз. И во-вторых, именно её разработки оказали наибольшее влияние на развитие поддержки многопроцессорности в FOSS-операционках.

И наконец, SunOS изначально была тесно интегрирована со средствами поддержки графического интерфейса пользователя. Причём – средствами собственной разработки. Первым из них была SunView (Sun Visual Integrated Environment for Workstations, изначально SunTools) – оконная система, возникшая едва ли не одновременно с самой ОС в первой половине 80-х годов. От всех последующих оконных систем, ориентированных на UNIX, она отличалась тем, что большая её часть поддерживалась ядром. Кроме того, она включала в себя набор стандартных пользовательских приложений, таких, как текстовый редактор, почтовый клиент, инструменты для настройки. И, наконец, она являлась частью стандартной поставки операционной системы. По-видимому, именно в SunOS впервые была реализована интеграция операционной системы, графического интерфейса и пользовательских приложений, получившая дальнейшее развитие не только в мире UNIX.

На смену ей в середине 80-х годов пришла NeWS (Network extensible Window System) – более сложная система, основанная на PostScript. Однако получить широкого распространения она не успела.

Наконец, в конце 80-х годов для SunOS была разработана оконная среда OpenWindows. Сначала она поставлялась как отдельное дополнение, а потом была включена в состав операционной системы.

На протяжении 80-х – начала 90-х годов были выпущены версии SunOS с 1-й по 4-ю, работавшие на машинах Sun-1, Sun-2, Sun-3. Однако в конце 80-х годов начинается смена аппаратной платформы: процессоры Motorola 68XXX в серверах и рабочих станциях заменяются на»камни» собственной разработки и производства, RISC-процессоры SPARC. Для которых разрабатывается и новая операционная система, названная Solaris 2. В отличие от предшественницы, она основывалась не на BSD-линии, а на «классической» System V (SVR4). Параллельно происходит отказ от графических средств собственной разработки, сменяясь ставшими стандартными для UNIX мира оконной системой X и рабочей средой CDE.

Некоторое время обе архитектуры со своими операционками сосуществовали, причём SunOS научилась поддерживать Sparc'и. Последний её релиз (SunOS 4.1.4) вышел в ноябре 1994 года. Тем не менее, название SunOS по сей день сохраняется за ядром OS Solaris (и OpenSolaris).

Однако тут мы уже чрезмерно углубились в 90-е годы. А ведь SunOS была не единственным представителем проприетарных UNIX'ов. О которых пойдёт речь в следующей главе.

 

В оковах проприетаризма

Из предыдущих страниц могло создастся впечатление, что всё развитие UNIX вращалось вокруг университета Беркли и компании Sun. Разумеется, это не так. Просто там проходила генеральная линия развития тех систем, которые позднее составят мир FOSS. Основные же события, связанные с развитием проприетарных ветвей UNIX, происходили в более иных местах.

Я не буду говорить о них подробно – во-первых, потому, что они лежат за гранью нашей главной темы. А во-вторых, просто плохо знаю их историю – надеюсь, она найдёт своих летописцев. Тем не менее, несколько слов о проприетарных 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, берклианскую реализацию механизма виртуальной памяти, и многое другое.

В частности, легший в последствии в основу стандарта POSIX шелл Корна, несмотря на совместимость с первозданным шеллом (Bourne Shell), заимствовал из C-Shell такие особенности, как управление заданиями, историю команд, поддержку псевдонимов и т.д. (впрочем, развитие шеллов – совершенно отдельная история, о которой мы поговорим, когда придёт время – и не в этой рубрике).

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

UNIX от AT&T, был лицензирован многими компаниями – производителями оборудования, оценившими, вслед за Sun, портируемость этой ОС: IBM, Hewlett-Packard, DEC, SGI и еще несколько забытых. Базируясь на SVR3, а позднее – на SVR4, они адаптировали систему под собственные архитектуры, создав такие варианты UNIX, как AIX от IBM, HP-UX, Digital UNIX (позднее Tru64), IRIX, соответственно. Все это были коммерческие операционки, однако, будучи жестко привязанными к аппаратуре фирм-производителей, в свободной продаже (подобно нынешним Windows) они не присутствовали.

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

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

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

В результате ни одной из этих разработок не досталось народной любви – вследствие высокой стоимости и малого количества приложений, а для XENIX еще и урезанной функциональности. Хотя SCO UNIX получила довольно широкое распространение в банковской сфере. В частности, её потомки трудятся в Сбербанке России чуть ли не по сей день.

Каждая из перечисленных (и забытых) мною компаний создавала сугубо свой UNIX, не совместимый с другими. В итоге, кроме двух базовых системы – System V и BSD, расцвело не менее дюжины вариантов, в той или иной мере различающихся между собой. Мною были упомянуты далеко не все из них, а лишь те, которые уцелели и поныне. Или – те, о которых мне довелось в свое время хоть что-то прочитать. На самом деле UNIX-клонов в те времена было гораздо больше.

Так что можно было констатировать, что в конце 70-х и в 80-х годах прошлого века UNIX развивался в соответствие со знаменитым лозунгом Великого кормчего китайского народа – «Пусть расцветают все цветы!» И, по заветам Председателя Мао, назрела настоятельная необходимость в упорядочивании стилей работы. Но об этом мы поговорим в следующем разделе, посвящённом битве за стандарты.

 

Битва за стандарты

Как следует из предшествующего изложения, со временем различия между клонами UNIX становились все более значительными. Во-первых, в основе существовавших её вариантов лежали разные базовые системы – SVR3, SVR4, 4BSD.

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

Это ставило под угрозу один из краеугольных камней 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, разработанный международной организацией под названием IEEE (Institute of Electrical and Electronics Engineers, Inc.). То есть было принято, что любая операционная система, претендующая на звание UNIX (или UNIX-совместимой), должна соответствовать соглашениям, описанным в основополагающих документах стандарта. Как мы увидим со временем, именно этими документами воспользовался Линус Торвальдс при создании Linux.

Крёстным отцом термина POSIX стал Ричард Столлман. Произносится это слово как позикс – это специально подчеркивалось во Введении в POSIX.1:

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

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

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

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

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

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

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

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

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

 

Пока, как было сказано в предыдущих главах, в Беркли и его окрестностях поневоле занимались юридическим крючкотворством,а в мире проприетарных UNIX'ов пытались выполнить заветы Великого Мао по упорядочиванию стилей, на другом конце света, в Финляндии, некий студент по имени Линус Торвальдс размышлял, что же ему делать с только что приобретённым IBM PC/386. И, как ни странно, результаты его размышлений оказали не меньшее влияние на нашу историю, нежели многолетний труд исследователей, финансируемых правительством мировой державы, и инженеров на окладе крупнейших компьютерных фирм.

Впрочем, редкий линуксописатель не описывал рождественскую сказку о том, как бедный студент копил деньги на 32-битный компьютер, а потом сочинял программу терминального доступа к удалённой университетской машине, которая затем превратилась в полноценную ОС. Известна она и в версии от создателя этой ОС – самого Линуса Торвальдса. Так что пересказывать её в очередной раз я не буду. А попробую, в меру своего понимания, выявить предпосылки появления Linux. Правда, и к вопросу о бедном студенте мне придётся ещё вернуться.

 

Предпосылка первая, «железная»

О первопричине появления Linux я уже говорил – она «железная», и вызвана триумфальным шествием Советской власти (то есть, пардон, Intel-совместимых PC). И главную роль здесь сыграло появление в 1985 году первого 32-разрядного процессора от Intel – 80386. Что дало возможность использовать UNIX на дешёвых и общедоступных персоналках. А начавшееся вслед за тем производство процессоров Intel 80486 вплотную приблизило по производительности эти самые «писюки» к рабочим станциям на RISC-процессорах.

Надо сказать, что параллельно с платформой на процессорах Intel и их клонах, таких, как AMD, Cyrix, UMC, существовали и другие варианты персоналок, на иной аппаратной базе – процессоре Motorola 680x0. Ими были Macintosh и Amiga, с их System # и AmigaOS, соответственно. И обе эти платформы были не прочь претендовать на высокое звание «народного» компьютера. Особенно первая – в силу ряда причин, как технических, так и маркетинговых, у неё, казалось, были на то все основания.

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

Не в последнюю роль в расползании по нишам и Mac'а, и Amiga сыграла цена конечных решений. Что плавно подвело нас ко второй предпосылке.

 

Предпосылка вторая, «денежная»

Как это ни печально признать русским интеллигентам, но второй (по счёту, но не по значению) предпосылкой для возникновения Linux'а была цена. Потому что как раз в начале 90-х годов машины с 32-битными процессорами от Intel (а затем от AMD и Cyrix) стали доступны народу.

Причины этого явления уходят ещё в 80-е годы. Когда IBM выпустила свой первый PC, ещё 16-битный, руководство фирмы не относилось к этой затее совсем серьёзно, и не рассчитывало «нарубить капусты» на этом рынке. В результате все спецификации архитектуры были открыты, и не имелось ни технических, ни юридических препятствий к клонированию этих машин.

Чем немедленно воспользовались многие производители, сначала американские, а затем европейские и восточноазиатские. И очень скоро количество клонов (так называемых IBM-совместимых машин) превысило число оригинальных IBM PC-XT и PC-AT. А потом была выпущена ( в 1986 году) и первая машина на 32-битном процессоре от Intel (80386). И выпустила её вовсе не IBM, а фирма Compaq – она получила имя Compaq DeskPro 386.

Тут в IBM спохватились, что рынок, созданный их стараниями, от них уходит – и разработали новую архитектуру, также на процессоре x86, но с закрытыми спецификациями, исключающими клонирование – PS/2. Однако было поздно: рынок был заполнен стандартными PC. К рубежу 80-х и 90-х годов их не производил только ленивый – начиная от компьютерных гигантов типа Hewlett-Packard и заканчивая дядюшкой Мяо с Малой Арнаутской улицы острова Тайваня. К которому вскоре присоединился его родич – дядюшка Ляо с её продолжения на континентальном Китае. И с тех пор эти два дядюшки (особенно второй) обеспечивают мир большей частью комплектующих для компьютеров и даже готовыми системами – под какими бы торговыми марками последние не продавались.

Результатом был лавинообразный обвал цен. Первый IBM PC-XT стоил более трёх тысяч долларов, а для полноценной работы требовал ещё и доукомплектования на треть этой суммы. Ко второй половине 80-х годов относятся слова Линуса Торвальдса:

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

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

 

Предпосылка третья: «студенческая операционка»

В числе тех, кому такие машины были действительно нужны, и кто мог, тем или иным путём, ими обзавестись, оказались и студенты, обучавшиеся по специальностям, связанным с Computer Science. Но вот с операционной системой для 32-битных компьютеров у студентов оказалось хуже: FreeBSD ещё не начала своё свободное плавание, а коммерческие UNIX'ы стоили несколько дороже, чем необходимое для их работы «железо». Да и не густо было с ними: на архитектуре i386 были способны работать только SCO UNIX и Xenix – кастрированный UNIX от Microsoft.

И тут в канву нашего сюжета вписывается «игрушечная» ОС MINIX. Она была явлена миру в январе 1987 года Эндрю Таненбаумом (Andrew Stuart Tanenbaum), профессором Университета Врийе, Амстердам, Нидерланды. Где преподавал он ни что иное, как Computer Science, хотя и был по специальности физиком.

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

Так вот, Таненбаум вёл в именованном университете курс UNIX, к которому написал собственный учебник – Operating Systems: Design and Implementation. Но изучать UNIX без системы – все равно, что обучаться музыке без инструмента. А с инструментом-то как раз и была напряжёнка. И ему не осталось ничего другого, как такой инструмент изготовить. Им-то и стала ОС MINIX (в дальнейшем получившая имя MINIX 1), вышедшая в свет в 1987 году.

Это была маленькая и компактная операционка, работавшая на машинах с архитектурой i386. Доступность MINIX усугублялась ещё и тем, что ее можно было скомпилировать даже в 16-битном варианте, и в этом качестве она становилась пригодной к использованию не только на PC-AT (80286), но даже, как говорят, на XT’шках, то есть на машинах с процессором 8086/8088.

Распространялась она исключительно как сопроводительный материал к упомянутому выше учебнику. Весь комплект, по свидетельству Линуса Торвальдса, стоил 169 долларов при заказе по почте. Что на самом деле не так дорого: в те годы на Западе, только-только переставшем загнивать, ни одно специализированное книжное издание не стоило дешевле 100 баксов. Так что фактически основная, если не вся, затратная часть для пользователя приходилась на книжку, да и дискеты были не так дешёвы. Сама же ОС как таковая могла рассматриваться в качестве бесплатного приложения к книге и носителям. И, во всяком случае, это было несоизмеримо дешевле тех тысяч долларов, в которые обходилась лицензия на любой из существовавших тогда проприетарных UNIX’ов. Требовавших, к тому же, сущей безделицы в виде соответствующей рабочей станции в несколько десятков тысяч.

Разумеется, ОС MINIX распространялась в сопровождении исходных текстов, предназначенных для изучения и потрошения. Необходимость в котором возникла очень скоро.

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

Однако сама по себе MINIX по прежнему распространялась исключительно в первозданном виде – как чисто учебная система, и лишь в сопровождении книги (или, напротив, сопровождая книгу). То есть, будучи открытой, она не была свободной. Ибо права на MINIX принадлежали издательству Prentice-Hall, выпустившему учебник Таненбаума. В сущности, правовой статус MINIX был точно таким же, как и обычной книги. Что, однако не мешало тому, что на протяжении десяти, а то и более, лет по ней учились поколения студентов как до Торвальдса, так и после него.

Надо заметить, что Таненбаума нельзя рассматривать только как предтечу Линуса, а его систему – как трамплин для его разработки. Кроме упомянутой выше Operating Systems: Design and Implementation (в переводе: Операционные системы: разработка и реализация), его перу принадлежат:

   • Computer Networks (Компьютерные сети);

   • Modern Operating Systems (Современные операционные системы);

   • Structured Computer Organization (Архитектура компьютера);

   • Distributed Systems: Principles and Paradigms (Распределённые системы. Принципы и парадигмы).

Все они по праву относятся к классике жанра IT-литературы, выдержали по несколько изданий (Computer Networks и Structured Computer Organization – аж по пять), и переведены на многие языки. В том числе и на русском языке они изданы издательством «Питер» в серии «Классика Computer Science».

Труды Эндрью Таненбаума не ограничиваются ОС MINIX и перечисленными выше книгами. Тут уместно вспомнить проекты Amoeba – разработанную «с нуля» открытую микроядерную распределённую операционную систему, и Globe – распределённую объектную систему, предназначенную для поддержки миллиардов пользователей «в мировом масштабе».

главной разработке Таненбаума, MINIX, судьба также уготовила вторую жизнь. Долгое время она продолжала эволюционное развитие в качестве учебной системы – были выпущены версии MINIX 1.5 (1992 год) и MINIX 2 (1997 год), представлявшие собой «песочницы» для начинающих юниксоидов. Однако кардинал лелеял коварные замыслы: превратить MINIX в полноценную операционную систему, реализующие его представления о том, какой должна быть современная ОС. А заодно – сделать ее свободной в полном понимании этого слова: ведь «несвобода» предыдущих версий объяснялась не жадностью профессора, а спецификой издания и распространения.

Результатом явился анонс новой операционки, MINIX 3, который состоялся 24 октября 2005 года. И о которой я расскажу подробнее в главе восьмой.

 

Герой выходит на сцену

Итак, толчком для написания Линусом собственного ядра послужила MINIX – «студенческая» операционка Энди Танненбаума, с помощью патчей приспособленная для выполнения практической работы.

Однако сам Линус не занимался «доведением MINIX до ума». Не использовал он также и код какой-либо из реализаций UNIX или BSD. Он воссоздал функциональность ядра UNIX с нуля – руководствуясь описаниями системных вызовов, данными в соответствующем стандарте POSIX. И потому Linux не является ни клоном System V, ни клоном BSD – хотя в ней и использована схема инициализации в стиле первой, да и идейное влияние второй, безусловно, имело место быть. Как было сказано в предыдущей главе, Линус Торвальдс, создавая свою ОС по мотивам MINIX, опирался почти исключительно на стандарты POSIX.

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

Лично Линусу принадлежит честь разработки ядра Linux и файловой системы ext (то есть Extended – расширение для файловой системы Minix). В качестве среды для работы он выбрал bash – командную оболочку, разрабатываемую в рамках проекта GNU. Для сборки своего кода был использован компилятор gcc (GNU C Compiler), а главной общесистемной библиотекой функций языка Си выступала GNU-реализация ее, glibc. Все прочее системное окружение ядра – комплекс пакетов, который можно назвать Base Linux – также в основном происходит из проекта GNU. Да и при выборе политики распространения Линус в конце концов остановился на лицензии GPL – детище Ричарда Столлмана и его Фонда свободного программного обеспечения (FSF).

На основании сказанного выше часто полагают, что ОС Linux должна на самом деле именоваться GNU/Linux. Правильно ли это?

По моему скромному мнению, нет. Конечно, роль программного обеспечения, разработанного в рамках проекта GNU, для развития Linux как пользовательской платформы переоценить трудно. Однако не проект GNU ухватился за столь недостающее ему ядро. Напротив, это Линус для обеспечения работы своего ядра использовал отдельные компоненты из GNU-арсенала. В полном, к слову сказать, соответствии с духом и буквой GPL и движения FSF. Впрочем, те, кто считает нужным подчеркнуть роль компонентов GNU в составе Linux, вполне могут это делать – и делают.

Добавлю ещё, что неотъемлемой чертой Base Linux является альтернативность его комплектации. И потому ОС Linux – не только (а может быть, и не столько) ядро и набор базовых программ, но в первую очередь алгоритм для построения такого набора. И создание такого алгоритма – второе, после написания кода ядра, великое достижение Линуса.

Наконец, Линус оказался создателем уникального метода разработки масштабных проектов Open Source, того самого, который Эрик Реймонд позднее назовёт методом большого базара. Впрочем, справедливости ради следует отметить, что в данном случае и он изобрёл велосипед – аналогичный способ привлечения дармовой рабочей силы использовал Том Сойер в своих «Приключениях». Однако, если инструментами Тома были сердцевина от яблока и крыса с привязанной к хвосту верёвкой, чтобы удобнее размахивать ей над головой, то орудием Линуса оказался Интернет.

Рождение Linux дало толчок к окончательному оформлению движения Open Source, несколько обособившемуся от сообщества Free Software – хотя и по сей день это существенно пересекающиеся множества. Но, если апологеты FSF, во главе с Ричардом Столлманом, декларируют, что всё программное обеспечение должно быть свободным, исходя из моральных и идеологических соображений, то для сторонников Open Source характерен более прагматический подход. Их принцип – открытое программное обеспечение следует использовать не потому, что оно открытое, свободное или бесплатное. А потому, что оно просто лучше проприетарного. В том числе – и в следствие публичной экспертизы, реализуемой именно благодаря внедрённому Линусом методу Тома Сойера.

 

NetBSD и OpenBSD: первый форк в благородном семействе

Уделив на предыдущих страницах столько внимания FreeBSD, я невольно оставил в тени её родную сестру – NetBSD. А между тем она была первой в ряду свободных ОС BSD-клана.

Кроме того, существует мнение, не лишённое оснований, что именно NetBSD воплощает в себе дух первозданного UNIX par exellence. По крайней мере, это верно в отношении максимально полной независимости от аппаратной части: в отличие от FreeBSD, первоначально ориентированной только на «демократическую» платформу i386, NetBSD исходно разрабатывалась как кросплатформенная: с первого для своего существования она поддерживала рабочие станции HP 9000 и Sun, компьютеры Amiga и Macintosh, полузабытые машины PC532 (на процессорах серии NS32000), а также, конечно, обычные персоналки с i386 и выше.

Наконец, история NetBSD также не лишена драматизма. И если драматизм в развитии FreeBSD носил, как мы видели, детективно-юридический характер, то здесь можно говорить скорее о драме идей, завершившейся... скоро мы увидим, чем она завершилась.

Ранее, в главе второй, я уже упоминал, что будущая NetBSD отделилась от проекта 386BSD в начале 1993 года, в тот момент, когда он оказался заброшенным своим создателем, Биллом Джолитцем, а «заплаточная группа» – будущие разработчики FreeBSD, ещё не развернули свою деятельность.

Ядро новой группы составили Крис Деметрио (Chris Demetriou), Тео де Раадт (Theo de Raadt), Адам Гласс (Adam Glass) и Чарльз Ханнам (Charles Hannum). Разрабатываемая ими система получила имя NetBSD, предложенное Тео – как раз в это время Интернет начал широко распространяться в узких пока кругах, особо приближённых к разработке.

Первым релизом новой системы считается версия 0.8, вышедшая в апреле 1993 года. Однако истинную мультиплатформенность она обрела в версии 1.0 – правда, та последовала не очень скоро, осенью 1994 года.

А вскоре, в декабре того же года, внутри группы перворазработчиков разгорелся конфликт: Тео разошёлся во мнениях относительно дальнейшего развития системы с остальными членами группы. И дело закончилось тем, что весной 1995 года ему был закрыт доступ к дереву исходных текстов NetBSD.

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

Во главу угла новой системы были положены два аспекта: свобода от любых компонентов, могущих ограничить её распространение, и безопасность. Последняя неразрывно была связана с криптографией. И, дабы избавиться от оков, налагаемых законами США на распространение «сильных» криптографических технологий, Тео покидает Калифорнию и перебирается в Канаду, куда некогда эмигрировала из ЮАР его семья, дабы откосить сыновей от службы в армии антинародного режима апартеида. Там, в почти родном городе Калгари, университет которого Тео закончил до работы над NetBSD, и обосновывается штаб-квартира нового проекта.

В результате, после нескольких внутренних тестировочных версий, в октябре 1996 года, рождается новая ОС – выходит первый официальный релиз OpenBSD 2.0. С тех пор полугодовой релиз-цикл выдерживается неукоснительно – очередные версии появляются каждую весну и осень.

Однако завершим историю NetBSD. В последующие годы она была портирована на всё «железо», которое может запускаться, и немножко – на то, которое запускаться не способно. Чтобы убедиться в этом, достаточно посмотреть «лист совместимости» на сайте проекта – в них обнаружатся и VAX, и Sun Sparc, и RISC-системы от Hewlett-Packadr, и DEC Alpha, и PowerPC, и Amiga, вкупе с мало кому ведомыми Acorn, Atari, Sharp, и так далее, и так далее, и так далее… Список столь обширен, что PC-платформа как-то просто теряется в середине его.

В качестве системы пакетного менеджмента в NetBSD в 1997 году была принята pkgsrc, разработанная по образу и подобию портов FreeBSD, но почти сразу также приобретшая кросс-платформенный характер. Кроме родной ОС, она официально поддерживается для многих UNIX-подобных операционок: Solaris, Linux, Darwin (Mac OS X), FreeBSD, OpenBSD, IRIX, AIX, DragonFlyBSD, HP-UX, QNX. Правда, это не значит, что в них она широко используется: во всех этих ОС есть собственные развитые средства управления пакетами. В частности, в OpenBSD, ответвившейся до возникновения pkgsrc, была просто заимствована система портов из FreeBSD. Относительно Linux мне известно несколько попыток прикрутить pkgsrc к Slackware. Лишь в DragonFlyBSD pkgsrc долгое время была принята в качестве штатной, но об этом мы поговорим в следующей главе. А в этой – вернёмся к FreeBSD и очередному перелому в её истории.

 

FreeBSD: десятилетие спокойствия

Мы оборвали историю FreeBSD 22-го ноября 1994 года – дне, когда было объявлено о выходе FreeBSD версии 2.0, после чего оценили, во что же этой ОС обошлась её свобода. На нынешней же странице посмотрим, как события развивались дальше.

Начиная с выхода первой «настоящей» версии FreeBSD (то есть 2.0), сложилась модель разработки этой операционной системы, реализуемая и по сей день. Впрочем, она была в значительной мере унаследована от стиля работы CSRG и свойственна всем системам берклианской линии.

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

Все участники разработки FreeBSD объединяются в три кольца. Первое, как бы внешнее, кольцо включает в себя многочисленных добровольцев со всего мира, работающих над отдельными компонентами системы – начиная от ядра и до сопровождения портов, а также занимающихся составлением и переводом документации. Разработчики (как, впрочем, и всё остальное прогрессивное человечество) имеют свободный доступ к дереву исходных текстов системы, но вносить в него изменения непосредственно не могут: свои наработки они должны передавать «по команде» для утверждения.

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

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

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

А пока вернёмся немного назад, к началу истории собственно FreeBSD, и посмотрим, что же послужило причиной её почти мгновенной популярности.

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

Более того, под влиянием sysinstall возникла не только программа установки практически одновозрастной Slackware – влияние её сказывалось ещё и в начале нынешнего тысячелетия, непосредственно – в инсталляторах таких дистрибутивов, как CRUX и Archlinux, косвенно – в установочной программе Zenwalk’а. Что же до сквозных графических конфигураторов, то первого из них, Drackconf из Mandrake, Linux’у пришлось ждать около пяти лет (первые варианты YAST, упомянутого на странице про Suse, функционировали в текстовом режиме).

Ничуть не менее важной составляющей FreeBSD была система портов и пакетов. Ибо это была первая в истории FOSS цельная система сборки и установки программ с автоматическим разрешением их зависимостей. Вспомним, что одновозрастная Slackware таковых не имела вообще (и, штатно, не имеет и по сей день), а rpm и dpkg на большее, чем сообщение о нарушении зависимостей, способны не были. Как, впрочем, не способны и по сей день – до появления изощрённых механизмов apt и его последователей было ещё очень и очень далеко.

Таким образом, основные особенности, определившие потенциал FreeBSD, в том числе, и как пользовательской платформы, были заложены уже в её первой «настоящей» версии. Почему же она не реализовалась в этом качестве, уступив пальму первенства Linux’у? Тайна сия велика есть, хотя некоторые предположения на этот счёт сделать можно.

Вспомним, кем были первые пользователи первых FOSS-систем. Это были, с одной стороны, разработчики их же самих, с другой – сетевые администраторы и Интернет-провайдеры. А для первых более свободная и динамичная модель разработки Linux’а, видимо, казалась более привлекательной, нежели более иерархическая и «камерная» модель FreeBSD. С другой стороны, обеспечиваемые последней стабильность и предсказуемость оказались более востребованными именно администраторами, для которых надёжность была важнее фронтирности.

А потом уже работал просто стереотип мышления: за FreeBSD закрепилась репутация серверной платформы, тогда как от Linux’а ждали «поворота лицом к конечному пользователю». И, надо сказать, стереотип этот работает и по сей день.

Однако я опять отклонился от генеральной линии. Успех первой версии FreeBSD был закреплён выходом версии следующей, получившей номер 2.05 и ликвидировавшей те самые «недотёсанные углы», о которых упоминал Хаббард.

Дальше время опять замедляет свой ход. Впереди были долгие годы плавной эволюции. Примерно два-три раза в год выпускается новая версия системы (2.1.x, затем – 2.2.x), она обрастает приложениями и утилитами (значительная часть которых происходит из проекта GNU и Фонда свободного программного обеспечения), совершенствуется ядро, улучшается (как это ни странно для, казалось бы, чисто американской по происхождению системы) интернациональная поддержка.

В ноябре 1996 г. происходит событие, определившее структуру развития FreeBSD на долгие годы (с некоторыми оговорками – до сего дня): ветка 2.x.x была выведена из активной разработки, получив имя STABLE. Отныне, вплоть до последнего релиза (2.2.8 в ноябре 1998 года), в ней лишь исправляются ошибки и вносятся мелкие безопасные изменения. А все долговременные и принципиально новые разработки концентрируются в версии 3.0-CURRENT. Каковая претворяется в STABLE в октябре 1998 г.

Начиная с ветки 3 (версия 3.4, судя по архивам), начинаются первые попытки портирования FreeBSD на архитектуры, отличные от i386. Первым претендентом на портирование стали машины с процессорами DEC Alpha, доживавшие тогда свои последние дни. Тем не менее, поддержка этой платформы осуществлялась долгое время, пока не была прекращена с выходом 7-й ветки.

С этого времени и вплоть до ответвления единовременно развивается две ветки FreeBSD – STABLE, предназначенная для широкого применения, и CURRENT, ориентированная главным образом на разработчиков и энтузиастов. Так, в январе 1999 г. обособляется ветка 4.0-CURRENT, обретшая статус стабильной в марте 2000 г.

Ветке 4.X суждено было стать самой «долгоиграющей» во всём дереве развития FreeBSD. Правда, на протяжении только 2000 года вышло ещё три её релиза – 4.1, 4.1.1 и 4.2, выступавшие в роли своего рода обкаточных для всех новшеств этой ветки. Которая в дальнейшем стабилизировалась, и последующие её версии, вплоть до последней, 4.11, вышедшей в январе 2005 года, содержали в основном исправления и косметические изменения. И кстати, версия 4.11 поддерживалась более двух лет после её выхода, а практически, насколько я знаю, используется чуть ли не по сей день.

 

FreeBSD: переломный год

Однако закулисно на протяжении трех лет шла незаметная, но большая работа по коренному изменению FreeBSD, завершившаяся появлением в январе 2003 года первой версии новой, 5-й ветки. В нарушение описанной выше закономерности, она очень долго (вплоть до версии 5.3), не получала статуса STABLE, а позиционировалась как «ново-технологический релиз». В сущности, стабильной она так и не стала, выступая скорее как прототип грядущей ветки 6.

Тем не менее, выход в свет 5-й ветки FreeBSD был, пожалуй, самым революционным событием со времен ее появления как самостоятельной операционной системы. Почему год её выхода я и назвал годом переломным – конечно, не столь драматичного, как события 1991-1993 годов, но тоже сопровождавшегося не только приобретениями, но и потерями.

Именно в 5-й ветке FreeBSD, начиная с самой первой пред-релизной версии, предназначенной для разработчиков (июнь 2002 года), был заложен тот потенциал, который обусловил её применимость в качестве современной настольной операционки для конечного пользователя. Это и последовательно модульный подход, позволяющий обходиться без пересборки ядра для поддержки важных для пользователя особенностей, и файловая система устройств, облегчающая работу с устройствами «горячего подключения» (такими, как USB-накопители, сканеры, цифровые камеры), и эффективная работа с ATA RAID (а в дальнейшем и с винчестерами Serial ATA), и многое другое.

В 5-й ветке был продолжен и курс на кросс-платформенность: с первого же релиза (5.0) в ней появляется поддержка AMD64, Sparc64 и IA64 (Merced, он же Itanium), несколько позднее, в версии 5.5 (май 2006 года) – PowerPC, то есть практически всех 64-битных платформ. Если вспомнить, что объект первого портирования FreeBSD, процессор Alpha, также был 64-битным, то это можно рассматривать как подготовку к эпохе 64-разрядных вычислений. Иначе довольно трудно было бы объяснить усилия, затрачиваемые на поддержку архитектур или мёртвых, как Alpha, или отмирающих, как PowerPC (обратим внимание, что выход порта для него произошёл через год после перехода Apple на «камни» от Intel), или, наконец, поставляемых обычно с собственными операционными системами, как Sparc64 и Itanium, и вряд ли предоставляющих широкое поле для инсталляций FreeBSD.

Шестая ветка FreeBSD, появившаяся в ноябре 2005 года, не была столь богата инновациями, а скорее являла собой логическое продолжение тенденций, заложенных в ветке 5.X. Хотя многие из её новых особенностей оказались очень важны для конечного пользователя. Среди них – поддержка высоких разрешений в так называемой графической консоли, обратно портированная из DragonFlyBSD (о которой речь пойдет в следующей главе), возможность работы с популярными файловыми системами Linux – ReiserFS и XFS (правда, в режиме «только для чтения»). Наконец, версии 6-й ветки демонстрировали значительное повышение быстродействия, особенно – операций с файлами. До этого за новшества, привнесённые в 5-ю ветку, приходилось расплачиваться снижением скорости работы по сравнению с веткой 4-й, в ряде случаев – весьма существенным.

Интересно, что FreeBSD 6-й ветки в варианте для архитектуры AMD64 демонстрировала некоторый прирост быстродействия относительно своей 32-битной сестры – не очень значительный, но всё-таки видимый невооружённым тестами взглядом. В отличие от Linux, дистрибутивы которого в своих тогдашних 64-битных инкарнациях были как минимум не быстрей 32-битных, а то и медленней на некоторых операциях, в первую очередь файловых. Вполне возможно, что в этом и сказалась «тренировка» на неактуальных, казалось бы, чисто 64-битных платформах...

Тем не менее, и 6-я ветка не производила впечатления долгожителя, хотя последняя её версия (6.4, появившаяся в ноябре 2008 года) пользовалась статусом промышленного, хотя и «староватого» (legacy) релиза, и поддержка её осуществлялась довольно долго.

Новым рубежом в развитии FreeBSD стала ветка 7 (февраль 2008 года), в которой, начиная с первых пре-релизных версий (с осени 2007 года), поддерживается файловая система ZFS – одно из самых перспективных явлений в этой сфере, разработанное фирмой Sun для своей операционки Solaris в 2004 году. И хотя поддержка ZFS во FreeBSD долгое время имела статус экспериментальной, и эта файловая система не рекомендовалась к промышленному применению, было ясно, что её стабилизация в рамках этой ОС – не более, чем вопрос времени.

И это время наступило: в середине сентября 2009 года, в канун выхода релиза 8-й версии, Павел Давидек (Pawel Dawidek) объявил о готовности ZFS во FreeBSD к промышленной эксплуатации. Однако до повсеместного её внедрения было ещё далеко: ZFS не поддерживалась на стадии установки программой sysinstall – и соответственно, на ней нельзя было расположить корень файловой иерархии. Фактически о её окончательном утверждении во FreeBSD можно говорить, начиная с 10-й ветки – финальный её релиз вышел за несколько дней до окончания редактирования этой книги.

 

Оглядываясь вокруг

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

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

Далее, существовало (и частично существует по сей день) несколько проектов создания LiveCD на основе FreeBSD – в основном специализированных сборок для системных администраторов. Они отражали всё ту же общую тенденцию – доминирование в развитии FreeBSD серверного направления. Хотя и здесь она была теснима мало-помалу, с одной стороны, соплеменным Linux'ом, с другой – классово чуждым Windows, но сохраняла твёрдые позиции.

А вот о настольных применениях этого сказать нельзя. Если Linux понемногу пробивал дорогу на пользовательские десктопы, то FreeBSD, похоже, к этому и не стремилась – по крайней мере, до недавнего времени. Статистика заходов на сайты, тематически связанные с UNIX и Open Sources, показывает, что доля FreeBSD среди клиентских машин ничтожно мала.

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

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

Проект PC-BSD не остался одиноким на ниве пользовательских десктопов, производных от FreeBSD: считанные месяцы спустя (лето 2005 г.) аналогичный по сути, но несколько иначе реализованный проект был объявлен под именем DesktopBSD.

Следует подчеркнуть, что ни PC-BSD, ни DesktopBSD не являлись отдельными дистрибутивами в том понимании, в каком этот термин применяется к вариациям на тему Linux'а. И тем более это – не самостоятельные системы, поскольку и та, и другая после установки превращаются в самую обычную (и полноценную) FreeBSD. Точнее, это – именно дистрибутивы в буквальном смысле слова, то есть способы распространения операционной системы FreeBSD, адаптированные для конечного «десктопного» пользователя.

главное, чем и PC-BSD, и DesktopBSD отличались от своей материнской системы – это их программами инсталляции. Если для FreeBSD в этом качестве на протяжении многих лет применялась текстовая (псевдографическая) программа sysinstall, то в основу установщиков ее «юзерофильных» разновидностей лег BSD Installer.

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

Существовала также попытка Эндрю Тернера (Andrew Turner) прикрутить (в рамках программы Google's Summer of Code 2005) BSD Installer и к собственно FreeBSD – взамен sysinstall. Впрочем, развития она не получила – последнюю версия сборки FreeBSD с этим инсталлятором датируеся маем 2006 года.

Наконец, в рамках все той же программы Google's Summer of Code (теперь уже – 2007) Иваном Ворасом (Ivan Voras) была предпринята еще одна попытка одеть инсталлятор FreeBSD во фрак – посредством программы finstall. В отличие от всех предыдущих вариантов, она основывалась не на движке BSD Installer, а на собственном back-end'е, и имела построенный на библиотеке Gtk front-end, запускавшийся с LiveCD из среды XFce. Сама же устанавливаемая им система была самой обычной FreeBSD текущей (current) версии для архитектуры i386. Правда, проект этот был быстро и полностью заброшен.

Интересные побеги на дереве FreeBSD – гибридные системы FreeBSD/Linux, то есть попытки использования её ядра в обрамлении иной инфраструктуры, заимствованной из различных дистрибутивов Linux. Таких проектов некогда было два: Debian GNU/FreeBSD и Gentoo/FreeBSD.

Проект Debian GNU/FreeBSD первоначально существовал в двух вариантах: libc5-based Debian GNU/FreeBSD и gnu-libc-based Debian GNU/FreeBSD. Оба они использовали ядро FreeBSD и пользовательское окружение проекта Debian, в частности, его репозитории и систему управления пакетами по механизму apt.

Первый проект, как нетрудно догадаться, в качестве главной системной библиотеки для портируемых приложений использовал BSD Libc – родную для всехBSD-систем. Пользовательское окружение (так называемый userland) в нём тоже было унаследовано от FreeBSD. Последнее обновление проекта датировалось апрелем 2002 года, после чего он прекратил своё развитие, и притом навсегда – в том числе и потому, что физически погиб его сервер. Хотя из всех «гибридов» он выглядел наиболее логичным, представляя собой, в сущности, FreeBSD Distributions, в котором место традиционных портов заняла инфраструктура apt. Эта модель, как будет показано в главе девятой, была успешно реализована в системах Nexenta и Dyson.

Второй же из упомянутых проектов, известный под названием Debian GNU/kFreeBSD, участь сия миновала – более того, он нынче имеет статус официально поддерживаемого в памках мегапроекта Debian. В отличие от предыдущего, здесь в качестве основы для пользовательских приложений выступает стандартная для Linux библиотека glibc (GNU C library), а большая часть родного юзерланда заменена GNU-аналогами: буква k в имени системы, видимо, призвана подчеркнуть, что от FreeBSD в ней было взято только ядро. Хотя с портированием инфраструктуры Debian существовали (да и существуют) проблемы, сама система, по утверждению её разработчиков, являлась вполне работоспособной. Впрочем, на меня она произвела впечатление химерической смеси бульдога с носорогом...

Проект портирования на ядро FreeBSD инфраструктуры Gentoo примечателен тем, что сам по себе дистрибутив Gentoo Linux был создан под сильным влиянием FreeBSD: в частности, портежи Gentoo представляли собой первоначально адаптацию портов FreeBSD к ядру и окружению Linux'а. И первая попытка обратного портирования системы портежей на FreeBSD была предпринята Грантом Гудьером (Grant Goodyear) через год после обретения Gentoo стабильного статуса, в сентябре 2003 года.

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

Тем не менее, FreeBSD легла в основу и совершенно самостоятельной операционной системы, корни которой уходят в тот самый год переломный 2003 год.

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

 

Предварительный итог...

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

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

Первый вывод – технологического плана. Хотя FreeBSD по анкетным, так сказать, данным и моложе Linux'а, за спиной у нее – долгая история совместного с UNIX развития. То есть она – система с прошлым. Что имеет и свои минусы, и свои плюсы. Не могу отказать себе в удовольствии процитировать Мэтта Диллона (Matthew Dillon):

Хотя некоторые считают BSD «старой» операционной системой, те из нас, кто работает над ней, видят ее скорее системой со «зрелым» кодом. Лев Кертман

Итак, первый вывод из истории FreeBSD – что это система сложившаяся, устоявшаяся, где-то даже консервативная. Но при этом – постоянно развивающаяся и совершенствующаяся.

Кроме того, FreeBSD (и ее предтечи) возникла и развивалась в университетской среде, не просто высококлассными программистами, но людьми с неслабой теоретической подготовкой. Следствием чего явилась исходная продуманность ее архитектуры. И опять помяну Диллона:

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

И это – второй вывод из рассмотренной истории, который также можно отнести к технологии.

Третий же вывод, также следующий из академического происхождения FreeBSD, носит, условно говоря, гносеологический характер. Ученые (по крайней мере, те, кто заслуживает неругательного значения этого слова) – люди, основным стимулом деятельности которых является удовлетворение собственного любопытства. И FreeBSD, как творение академических исследователей, – это система, идеально для такого удовлетворения подходящая. Как сама по себе, так и как инструмент исследования в иных научных областях, в том числе – и далеких от Computer Science...

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

 

FreeBSD на Руси

Осталось сказать несколько слов об истории FreeBSD (и её предшественниц) на Руси. Несколько слов – не потому что история эта коротка. Отнюдь – существуют косвенные данные, что первые BSD-системы появились ещё в Советском Союзе, и еще до официального выхода самой FreeBSD. Достоверных сведений о тех временах далеких, теперь почти былинных, очень немного. Однако то, что примерно к 1995-1996 году сервера большинства крупных Интернет-провайдеров России работали под управлением этой операционной системы, можно считать более-менее установленным. Тогда же, вероятно, появились и первые зеркала проекта. Да и дистрибутивы FreeBSD на дисках в исполнении Walnut Creek стали доступны, по крайней мере, в Москве, также не позднее 1998-1997 года.

Характерно, что один из самых старых и по сей день самых обширных сайтов по UNIX-тематике – Opennet.ru, и BSD-минипортал его – один из самых полных источников информации по рассматриваемой тематике.

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

Правда, о настольном использовании FreeBSD в те годы никто и не помышлял. Не была она избалованна и вниманием прессы. Хотя первые публикации о BSD-системах в компьютерных журналах не намного отстали во времени от статей про Linux – вспоминаем статью Вадима Колонцова «ОС BSD жила, живет и будет жить» (Открытые системы, №3, 1997). Однако долгое время они выглядели редкой вкрапленностью даже на фоне не частых тогда материалов о Linux. Хотя были среди этих вкраплений и очень яркие сочинения. Например, статья того же Вадима Колонцова под характерным заглавием – «Я живу во FreeBSD». Сайт, на котором она была размещена, давно прекратил своё существование, однако при желании можно обнаружить её в переразмещенном виде.

Ряд статей о BSD-системах вообще и FreeBSD, в частности, появлялся в короткий период существования UNIX-раздела в журнале Byte/Russia (1999-2000 годы); к сожалению, ни одна из них ныне в Сети недоступна...

Переломным с точки зрения популяризации FreeBSD в широких массах стал 2002 год. Во-первых, тогда был начат (и к настоящему времени практически завершен) проект тотального перевода официальной документации по этой ОС, размещавшийся первоначально на freebsd.org.ua, а ныне доступный на главном сайте проекта.

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

И, наконец, в-третьих, в конце 2002 – начале 2003 года подряд вышли первые русскоязычные книжки по FreeBSD, две переводные (очень похожие, так как принадлежат перу одних и тех же авторов – Майкла Эбена и Брайана Таймэна) и одна отечественная (вашего покорного слуги). На протяжении 2003-2004 годов к ним прибавилось еще несколько изданий – Родерика Смита, Майкла Лукаса, а затем, в 2006 году, фундаментальная книга Керка МакКузика и Джорджа Невилл-Нила «FreeBSD: архитектура и реализация».

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

Росло тем временем и количество русскоязычных Интернет-ресурсов, посвященных BSD-системам вообще и FreeBSD, в частности. Конечно, их число не поражает воображение, как количество Linux-сайтов. Однако к упомянутым ранее ресурсам присоединился специализированный bsdportal.ru.

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

 

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

Об одной из них, системе, возникшей на наших глазах, на наших же глазах угасшей, но возродившейся вновь, хотя и под другим именем, я и хочу рассказать в этой статье. А в конце её попробую в очередной раз извлечь уроки из истории – тем более, что тема эта будет продолжена в ближайших главах. Итак, наша сегодняшняя героиня – AtheOS, позднее известная как Syllable.

 

Пролог

История горячего финского парня Линуса Торвальдса, в одиночку из ничего сочинившего операционную систему, знают все, интересовавшиеся историей ОСестроения. А вот история норвежского парня Курта Скавена (Kurt Skauen, за точность транскрибции не ручаюсь) широкой известности не получила даже в узких кругах. Хотя Курт занимался своей разработкой ещё более в одиночку и ещё менее из ничего. Возможно, потому, что он парень ещё более горячий, вследствие чего его деятельность не имела таких последствий.

Однако начнём по порядку. Все системы, описанные ранее в этом цикле, так или иначе, генетически или парагенетически, связаны с первозданным UNIX'ом.

Так, все BSD-клоны, в сущности, ни что иное, как UNIX, очищенный от проприетарного UNIX-кода. MINIX, о которой упоминалось ранее и к которой мы вернёмся в ближайшее время, представляла собой модельную (или «игрушечную» систему UNIX). Linux же исторически – попытка воспроизведения функциональности UNIX-систем, вообще не используя код UNIX, а опираясь только на стандарты. И даже Hurd, в котором декларируется отход от принципов UNIX-архаики, подчинен единой идее: сделать все, как в UNIX, но иначе. То есть в полном соответствие с известным рекурсивным высказыванием Ричарда Столлмана: GNU – GNU is Not UNIX. Правда, к счастью, всё, что до сих пор сделано в рамках проекта GNU, от этого меньшим UNIX'ом не стало. По крайней мере, пока.

Возникает вопрос – все ли в мире свободных ОС прямо и непосредственно происходит от UNIX? Как выясняется, не всё. И примером этому – некая свободная альтернативная операционная система, названная создателем AtheOS. Об этимологии её имени могу только гадать – но у меня оно ассоциируется и со славным городом Афинами, и с Афиной Палладой. Дальнейшую ассоциативную цепочку читатель легко построит сам.

 

Чем была AtheOS

Создателем AtheOS от начала и до конца всей истории выступал один-единственный человек – ранее упомянутый Курт Скавен. Согласно его декларации, AtheOS – своего рода tabula rasa (цитирую – «new clean desktop OS»), разработанная с нуля. То есть – не потомок UNIX, в отличие от BSD, и не реинкарнация ее, подобно Linux. И даже POSIX-совместимость Курт не возводил в абсолют, хотя и более-менее его стандартам следовал. В этом отношении напрашивается аналогия AtheOS с QNX, отнюдь не UNIX'ом, но местами сходной с ним операционкой. История которой, кстати, тоже весьма интересна, но мной не рассматривается по причине недостаточного знакомства.

Разработка AtheOS была начата Куртом во второй половине 90-х годов. Однако о своём создании он заявил миру весной 2000 года,разместив в открытом доступе её исходники под лицензией GPL (тогда ещё только за номером 2). А в начале 2001 (то есть уже однозначно в XXI веке) года под AtheOS был портирован Apache и сайт проекта http://www.atheos.cx/ заработал под управлением её же самой. И работал ещё несколько лет после прекращения разработки, без всякого участия автора. Так что всю короткую, но яркую историю AtheOS можно целиком считать принадлежащей к третьему тысячелетию.

AtheOS функционировала на любых Intel-совместимых процессорах, причем с очень эффективной поддержкой мультипроцессорных архитектур. Система написана почти целиком на Си – ассемблерная часть ядра составляет чуть больше 20 Кбайт. И потому теоретически она повязана с Intel-архитектурой не больше, чем любая иная POSIX-совместимая система.

Одна из отличительных особенностей AtheOS – поддержка в ядре графического интерфейса пользователя, основанного на архитектуре клиент-сервер, но отличного, тем не менее, от оконной системы X, привычной всем пользователям UNIX. Вместе с тем поддерживается и стандартный интерфейс командной строки в лице типичных UNIX’овых Shell’ов (штатно – bash, но и zsh был на эту ОС портирован). Ну и вообще декларируется поддержка, хотя и не полная, всяческих стандартов (типа POSIX).

 

Как она получалась...

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

   • образы двух загрузочных дискет;

   • образ дискеты с данными, под коими имеется ввиду базовый набор компонентов;

   • обственно систему в виде единого тарбалла объемом около 20 Мбайт;

   • небольшую, но вполне внятную документацию, посвященную описанию инсталляции системы и параметров загрузки ядра.

Кроме этого, на сайте (в отдельном каталоге) имелся набор дополнительных пакетов (также в виде tgz-архивов), несколько ограниченный, но оригинальный по подбору: средства разработки (gcc, automake и подобные), web-сервер Apache, редактор emacs, основные UNIX-утилиты типа grep, gawk и т.д., включая даже Midnight Commander.

 

Как устанавливалась...

Для установки системы требовался винчестер со свободным разделом или не размеченным пространством, какой-либо носитель с файловой системой FAT (раздел диска или, например, Zip) и три трёхдюймовые дискеты. На FAT-носитель помещался базовый файл, на дискеты, посредством rawrite (в DOS/Windows) или dd (в UNIX/Linux), – образы загрузочных дискет и дискеты с данными.

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

Все последующее было не просто, а очень просто. Для начала в bash запускалась программа DiskManager и на пустом пространстве целевого диска выделялся раздел под родную файловую систему afs (AtheOS File System. Разумеется, если не жалко, можно было уничтожить какой-либо из разделов существующих.

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

После этого на разделе или диске создавалась (командой format) файловая система afs и две точки монтирования – для FAT-устройства с базовым файлом и для afs-раздела для системы собственно. Установка же последней осуществлялась банальной распаковкой (командой tar с соответствующими опциями) базового тарбалл.

 

И как работала

Теперь оставалось только обеспечить загрузку новообретённой системы. Загрузчиком её являлся самый обычный GRUB. И потому посредством стандартного текстового редактора (в качестве коего выступал jed – к счастью или несчастью, но никакого vi не было и в помине) правился его конфигурационный файл.

Затем система перезагружалась (обязательно с помощью комбинации из трех пальцев, но никак не Reset’ом) с первой дискеты и при появлении меню GRUB’а переводилась в режим его редактирования. Тут следовало указать новый корневой раздел, после чего сделанные изменения изменения записать в MBR. После этого, вынув дискету, можно было загрузить AtheOS уже нормальным образом. При этом система практически мгновенно переходила в графический режим, и после авторизации перед глазами возникал рабочий стол с пузырчатыми обоями, в углу которого сиротливо ютились пиктограммы для запуска программ: файлового менеджера, браузера, терминала, утилиты настройки (Prefs) и пары-тройки системных мониторов.

Штатный набор приложений выглядел бедновато, но мог быть расширен за счёт дополнительных пакетов, правда, тоже не очень многочисленных. Это выполнялось в два приема: сначала пакет распаковывался из архива, а потом регистрировался в базе данных специальной утилитой. В отличие от всех тогдашних UNIX-подобных систем, дополнительные пакеты устанавливаются каждый в свой подкаталог каталога /usr, а не раскидывал свои файлы по древу многочисленных bin’ов, lib’ов и прочих man’ов. Не будем обсуждать, хорошо это или плохо – но ныне такой подход практикуется в PC-BSD и некоторых дистрибутивах Linux.

Что еще остается добавить? Утилита конфигурирования Prefs позволяла настроить разрешение экрана и глубину цвета, выбрать экранные шрифты (в качестве системных используются шрифты True Type) и раскладку клавиатуры – они представлены для большинства европейских языков, хотя русского среди них не было, как и кириллических экранных шрифтов, хотя русская locale имелась.

Не знаю, удалось ли мне в своём рассказе передать то чувство лёгкости, быстроты, компактности, аккуратности интерфейса, простоты установки и использования, которое испытывал при общении с AtheOS действующий пользователь Linux или BSD. Но она вызывала именно такие эмоции. Конечно, на тот момент времени её нельзя было рассматривать как полноценную универсальную ОС для практической деятельности. Хотя уже тогда резонные люди утверждали, что применяться как платформа для разработки она могла. А её потенциал как системы для настольного использования просмтаривался достаточно явно.

Что же касается утверждения автора об отсутствии связи AtheOS с UNIX – можно констатировать: он постарался, чтобы его систему нельзя было бы спутать с Linux или FreeBSD. Однако несомненно, что идеологически он следовал именно пути UNIX, а не, скажем, традициям DOS или Windows. Хотя в те годы AtheOS часто сравнивали с AmigaOS или BeOS.

Увы, потенциал AtheOS так и не был реализован. Разработки Курта прекратились в начале 2002 года, последнее обновление сайта датировалось осенью 2003-го. Хотя, повторяю, сайт был доступен ещё долгое время, пока на нём не появилось сообщение об окончании срока регистрации домена. Ныне сайт символически восстановлен в качестве своего рода мемориала по тому же адресу – правда, дальше первой страницы пройти по нему нельзя.

О причинах прекращения разработки в Сети ходили противоречивые слухи. В частности, писали о том, что Курт увлёкся любительским пилотированием и потерял интерес к AtheOS. А поскольку в ходе активной его разработки он, в отличие от Линуса, не особенно привлекал к нему посторонних разработчиков, проект оказался «бесхозным», и Афина Паллада не пришла ему на помощь.

Так что столь интересный и потенциально многообещающий проект можно было бы считать мертвым. Однако чувство печали – ведь с уходом чего-то хорошего становится как-то грустно – заставляло меня время от времени наведываться на сайт проекта в надежде увидеть там какие-то подвижки. Пока вдруг по наитию не набрал слово «AtheOS» в поисковой строке Google.

 

Эпилог

И тут в очередной раз обнаружилось, что приключения никогда не кончаются, по крайней мере – в мире Open Source (надеюсь, вы не забыли, что AtheOS распространялась по лицензии GPL?). Так вот, угасание проекта вызвало, видимо обиду не только у меня: на одном только SourceForge я обнаружил тогда пять разработок, выводящих свою генеалогию из системы Курта.

Правда, по настоящему действующей была только одна, носившая имя Syllable. Но зато это было настоящее развитие, продолжающееся и поныне, хотя далеко не теми темпами, как при Курте. Так что хочется верить – история AtheOS еще не окончена.

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

Конечно, и это второй урок нашей истории – до определённого предела. После которого требуется привлечение соратников и единомышленников. Курту Скавену это не удалось – или это не входило в его планы. Но если проект интересен не только его автору, соратники и единомышленники появляются сами, даже если автор потерял всякий интерес к своему созданию. И это – третий урок, который мы в очередной раз извлекаем из истории Open Source.

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

Героинями следующих двух статей цикла также будут ОС третьего тысячелетия – DragonFlyBSD и MINIX3. Хотя первая из них рассматривается обычно как форк FreeBSD, а вторая – как развитие той самой «игрушечной» MINIX, которая вдохновила Линуса Торвальдса на создание своей терминальной программы, обе они нынче являют собой вполне самостоятельные системы. И история их в этом качестве целиком принадлежит уже нашему времени. А судьба их оказалась более счастливой, нежели у героини сегодняшнего рассказа.

 

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

Как догадались многие читатели, речь пойдёт о DragonFlyBSD, ответвлении FreeBSD, для которой отсчёт времени пошёл в июне 2003, и я за которой я следил с самого начала. И которую начал использовать с того момента, как она к тому стала пригодна.

 

«Железная» ретроспектива

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

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

Конечно, время от времени производители продолжали бодро рапортовать об очередном повышении тактовых частот процессоров, увеличении их кэша до совершенно невообразимых, некогда вполне достаточных для основной памяти, объемов, включении дополнительных наборов инструкций под замысловатыми названиями, встраивании в чипсеты поддержки всего, чего можно, и даже того, чего, как недавно казалось, нельзя – например, 3D-графики. Однако накал страстей вокруг всего этого был не тот, что в во второй половине 90-х. А отчёты о тестировании процессоров и материнских плат стали напоминать просмотр фотофиниша на стометровке.

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

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

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

Вторая, столь же революционная, новинка – 64-разрядные вычисления. Вспомним терью статью цикла: каким прорывом в светлое будущее были 32-битные процессоры для PC, те самые первые «трешки», которые сделали возможным портирование на эту архитектуру UNIX и, в конечном счёте, появление Linux. Повторилась ли история на новом витке диалектической спирали?

Увы, отрицательный ответ был получен практически мгновенно. Потому что в те далекие уже годы аппаратура PC едва поспевала за софтом – 32-битные ОС разменивали уже второй десяток лет своего существования, и приложений, использующих 32 разряда на полную катушку, было вдоволь. В описываемый же момент их в пользовательском сегменте просто не было по одной простой причине – не востребованности. К слову сказать, почти нет их и по сей день. Ибо единственная ниша пользовательских приложений, где 64 бита хоть как-то задействованы – параноидальная криптография.

Так что усилия «камнестроителей» пропадали бы втуне. Если бы ещё не одно новшество, о котором я сознательно не упоминал ранее – Hyper Threading, то есть виртуальная мультипроцессорность. Каковая в некоторых (правда, весьма редких) задачах давала вполне даже реальный прирост производительности. Правда, он мало значил для пользователей, работающих преимущественно интерактивно. Но весьма способствовал производительности труда применителей – тех, кто, в силу врожденной лености отдавал предпочтение всякого рода скриптам, пакетным заданиям и прочим средствам автоматизации.

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

Разговоры о двухпроцессорных пользовательских десктопах возникали неоднократно. Кое-кому из читателей памятно, как дешевенькие Celeron’ы первого разлива можно было вставлять в относительно не очень дорогие двухпроцессорные материнские платы, получая таким образом нечто вроде «народного суперкомпьютера».

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

Сами по себе процессоры Power4 (как и пришедшие им на смену Power5) ориентировались на индустриальный сектор. Однако на базе их были созданы процессоры G5 – сердце тогдашних Mac’ов, имевших, в том числе, и двухъядерный вариант.

Правда, пользователям PC’шек (а мы говорим в основном о них) от этого было бы ни холодно, ни жарко. Однако здесь «камнестроители» не заставили себя ждать: и AMD, и Intel очень быстро анонсировали, а затем и воплотили в реальность, свои двухъядерные решения, стоимость которых вполне вписывалась в рамки «суперкомпьютера для народа». По крайней мере, в лице лучших его представителей.

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

 

Софтверная перспектива

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

Во-вторых, неизбежны были потери быстродействия за счет «накладных расходов» – согласования операций, выполняемых на разных процессорах.

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

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

Решение проблем многозадачности на «железном» уровне было задачей производителей аппаратуры. А вот минимизация же «накладных расходов» и распараллеливание задач относились уже к сфере разработчиков софта, в первую очередь – системного. Хотя в последнем случае роль создателей программ прикладных ничуть не меньше. Ну а эффективное использование достижений тех и других – это уже вахта пользователей.

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

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

Так что вырисовывалась заманчивая картина – все это изобилие параллельно работающих задач выполнять действительно параллельно, раскидав по разным процессорам. Дело оставалось за малым – воплотить её в кодах.

Изначально создатели UNIX (и ранних его клонов) ни о какой многопроцессорности не помышляли. И один из краеугольных камней его идеологии – концепция монолитных процессов, выполняемых на одном процессоре квазипараллельно, за счет квантования времени, – казалось бы, препятствует реализации распараллеливания задач по разным «камням».

Тем не менее, когда многопроцессорные серверы и рабочие станции стали реальностью в индустриальном секторе, в дополнение концепции процесса была создана и концепция т.н. нитей, или потоков (threads). Это – части процесса, выполняемые параллельно и почти независимо друг от друга (в том числе и на отдельных процессорах), разделяющие, тем не менее, ресурсы составленного из них процесса. То есть собственного контекста, в том числе и отдельного пространства памяти, они не имеют, почему носят ещё и имя легковесных процессов (light weight process) – обычные UNIX-процессы в этом случае можно называть «тяжелыми».

Само по себе понятие нитей возникло задолго до UNIX – чуть ли не со времен Очакова и ламповой электроники. И уже тогда были выявлены существенные недостатки этой концепции. Однако за истекшие годы ничего лучшего для поддержки мультипроцессорности придумано не было.

Как уже говорилось, проблема мультипроцессорности встала в первую очередь в индустриальном секторе. Где по ряду причин (в том числе и исторических) традиционно преобладали проприетарные представители UNIX-семейства. И разработчики последних доблестно эту проблему разрешили. Можно спорить, где она была решена лучше, где – не так хорошо, однако общепризнанно: масштабируемость многие годы был главной отличительной чертой (и главным козырем) и AIX от IBM, и Solaris от Sun, и прочих их братьев-конкурентов.

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

Движение свободных операционок в корпоративный сектор, в первую очередь в качестве серверов разного рода, поставило перед ними задачи многопроцессорной поддержки и масштабируемости. И задачи эти постепенно решались: в том или ином виде многопроцессорные конфигурации давно поддерживаются ядром Linux и FreeBSD, затем такая поддержка появилась в NetBSD и OpenBSD. Тем не менее, ни одна из этих ОС не дотягивала ещё до масштабируемости проприетарных UNIX’ов.

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

Из микроядерных решений наибольшее признание получило ядро March, разработанное в Университете Карнеги-Меллона, а затем развивавшееся в Университете Юты. Оно легло в основу ряда проектов разработки свободных ОС – самым известным из них долгое время был Hurd, разработка которого затем была переведена на другое микроядро – L4. Что, однако, не приблизило проект к состоянию, пригодному для применения. Однако существовали и другие попытки создания свободных микроядерных ОС – проекты xMach и Yamit. И оба они своё развитие прекратили.

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

Как ни странно, удачные реализации микроядерной архитектуры имели место быть в проприетарном секторе: на ранних версиях Mach основывалась знаменитая система NEXTStep, видевшаяся лет 15 назад платформой фантастического будущего. А предпоследняя, 3-я, версия Mach легла, вместе с системными службами FreeBSD, в фундамент современной MacOS X.

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

 

У истоков новой системы

Итак, где-то в середине июня 2003 г. Мэтт Диллон (Matt Dillon), вместе с группой товарищей сообщил о начале работы над новой ОС BSD-семейства – DragonFlyBSD. Возник сайт проекта – http://www.dragonflybsd.org и репозиторий её исходников, cозданный 16 июня 2003 года – этот день можно считать именинами системы. Репозиторий этот основывался на кодовой базе FreeBSD 4-й ветки, имевшей статус стабильной (хотя в то время уже вовсю развивалась ветка 5-я, вбирающая в себя все инновации BSD-мира).

Новая система получила и собственный тотем – стрекозу, что должно символизировать легкость и быстроту её. Кстати, разработчики не гнушаются и сокращенных названий своей системы – DragonFly и даже DFBSD, к которым, вслед за ними, время от времени, будем прибегать и мы.

Может возникнуть (и многократно возникает) вопрос: для чего нужна ещё одна BSD-система? Разве не вдоволь насмотрелись мы на изобилие Linux-дистрибутивов, чтобы и BSD-системам желать той же участи?

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

А в оригинальности DragonFlyBSD отказать невозможно. Ибо, при практически полном внешнем сходстве с прототипом (FreeBSD 4.X), «внутре» у нее всё было другое: управление памятью и процессами, представление о драйверах устройств и виртуальной файловой системе, вплоть до нового типа файлов – вариантных символических ссылок (varsims).

В основу DragonFly была положена модель легковесных нитей ядра (LWKT – Light Weight Kernel Threads), что само по себе и не ново. Новым стал механизм планирования нитей – вместо единого планировщика (sheduler) их было введено несколько, по числу процессоров. Нити привязаны к своим процессорам изначально, однако допускается передача выполнения нити с одного процессора на другой при некоторых особых условиях. Данные отдельных нитей могут быть кэшированы независимо для каждого процессора.

Подобно системам с микроядерной архитектурой, в DragonFly максимум функций ядра вынесен из его пространства памяти в пользовательское пространство (userland). В первую голову это относится к драйверам устройств – таким образом достигается рост как производительности, так и надежности системы, резко уменьшая вероятность её «падения» под воздействием неправильно работающего драйвера.

Это повлекло за собой отказ от традиционного для UNIX механизма системных вызовов (каковой лишь эмулируется в целях совместимости). Его место занял механизм сообщений (messages) и их очередей, т.н. портов (ports), подобный применяющемуся в микроядре March, упоминавшемся выше.

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

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

Далее, важно, что если матушка DragonFly, FreeBSD, изначально предназначенная только для архитектуры i386, все более эволюционировала в сторону кроссплатформенности (в 5-й ветке к поддержке древней Alpha был добавлен Sparc, а затем и PowerPC), то наша «стрекоза» возвращается на исходные рубежи. И единственной поддерживаемой архитектурой в ней является Intel-совместимая – на тот момент только 32-битная (64-разрядный вариант долго находился в состоянии разработки).

Такое ограничение в плане поддерживаемого «железа» может показаться отступлением от истинного UNIX Way. Однако на момент выхода DFBSD сбылось мрачное пророчество, высказанное почти двадцать лет назад в одном компьютерном журнале:

Через десять лет все платформы, кроме IBM PC, уйдут в небытие

И все остальные архитектуры в качестве настольных платформ полностью утратили актуальность. Разработчики DragonFly считались с этой реальностью: в их тогдашних планах переноса на другие архитектуры не было (нет его и сейчас). Что компенсировалось возможностью оптимизации под платформу, единственно значимую практически. Это дало свои плоды – по визуальному быстродействию в настольных условиях DragonFly со дня своего зарождения существенно опережала FreeBSD как 5-й, так и 4-й ветки.

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

Всё сказанное выше было технологическим обоснованием для того, чтобы отнестись к DragonFly не просто как к ещё одному BSD-клону. Но это подкреплялось и субъективным фактором – личностью организатора проекта.

К моменту начала работы над DragonFly Мэтт Диллон был широко известен (в узких кругах) благодаря трем разработкам: Си-компилятору для платформы Amiga (именно из этой ОС пришла в DragonFly идея «ядерного прелинкинга»), утилите dcron и, главное, системе управления виртуальной памятью во FreeBSD. Не то чтобы он был единственным автором последней, однако вклад его в эту тему был одним из определяющих современный облик FreeBSD, Да и к аналогичной подсистеме ядра Linux он приложил руку.

Что немаловажно, в специальной статье (присутствующей в официальной документации FreeBSD) Мэтт сумел описать архитектуру виртуальной памяти языком, понятным для широких масс трудящихся. Очень рекомендую к прочтению – во введении к ней высказано немало интересных мыслей общего характера. Тем более, что она доступна и в русском переводе. А пока позволю себе вторично процитировать её фрагмент:

Самой большой ошибкой, которую может допустить программист, является игнорирование истории.

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

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

Так продолжалось до мая 2004 года, когда один за другим начали появляться iso-образы CD бета-версий DragonFly. Они не имели ещё инсталлятора: следовало, руководствуясь документацией (вполне, впрочем, ясной, хоть и англоязычной), вручную разметить диск, создать файловые системы, перенести на них с дистрибутивного CD необходимые каталоги и произвести ещё кое-какие манипуляции (типа создания файлов устройств и настройки стартовых сервисов). Задача была не то чтобы сверхъестественно сложной – но и не вполне тривиальной.

А затем… Затем, в июне 2004 гjlf, появился пре-релиз DragonFly, точнее, DragonFlyBSD 1.0RC1. От своих бета-предшественников он отличался тем, что уже имел инсталлятор – BSD Installer, разработанный в рамках самостоятельного проекта как универсальный установщик для любых BSD-систем. И впервые опробованный именно на DragonFly.

Надо заметить, что уже в те далекие времена (в масштабах истории DragonFly) установка этой ОС проходила без малейших осложнений (в том числе и на «железо», на которое FreeBSD устанавливалась с трудом). Однако к использованию система была пригодной лишь условно. Ибо, кроме базиса (соответствующего FreeBSD Distributions), не содержала почти ничего – ни Иксов, ни прекомпилированных пакетов (за исключением нескольких консольных утилит типа cvsup и cdrtools), ни собственной системы пакетного менеджмента.

Нужно сказать, что пре-релизная стадия для DragonFly оказалась очень короткой: уже в 11 июля 2004 года было объявлено о выходе релиза – DragonFlyBSD 1.0-RELEASE. Правда, и он просуществовал недолго: как это нередко бывает, в него вкралось несколько мелких, но весьма неприятных ошибок, которые были выявлены мгновенно и столь же быстро исправлены в корректирующем релизе 1.0A.

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

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

Двигалось дело и с портированием сторонних приложений. Первоначально оно осуществлялось с помощью адаптированной системы портов FreeBSD. Однако позднее разработчики пошли другим путем: прикрутили в DragonFly pkgsrc – кроссплатформенную портообразную систему, заимствованную из проекта NetBSD. И таким образом в распоряжении пользователя новой ОС сразу оказалось все изобилие открытого и бесплатного софта, портированного на эту платформу – а надо отметить, что на NetBSD он портирован в очень значительной своей части.

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

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

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

   • оригинальную файловую систему Hammer – точнее, интегрированная система размещения данных, по своим принципам сходная с возникший чуть раньше ZFS и несколько более «юной» btrfs.

Статическое создание файлов устройств сменилось динамической файловой системой устройств devfs. Со временем DragonFly была портирована на архитектуру x86_64. И, наконец, для управления пакетами она снова вернулась к собственной модификации портов FreeBSD – системе dports. А сразу же по появлении системы пакетного менеджмента pkg-ng внедрила её у себя – чуть ли не раньше, чем возник первый официальный репозиторий для родительской операционки (то есть всё той же FreeBSD).

Однако предпосылки всего этого были заложены в первый год существования системы. Ныне её история не окончена – но выходит за рамки рассматриваемого периода.

 

Вступление

Кто же из линуксоидов не знает старика MINIX'а? Эта миниатюрная учебно-показательная UNIX-подобная ОС была создана четверть века назад профессором Эндрю Таненбаумом. Предназначалась она для вразумления студентов и приобщения их к идеалам UNIX на самой демократической платформе всех времён и народов – на IBM PC-совместимых компьютерах. Она уже фигурировала в нашей истории – в разделе о зарождении Linux. Ибо именно MINIX вразумил Линуса Торвальдса настолько, что он занялся сочинением своей терминальной программы, которой суждено было превратиться в Linux.

В том же разделе была описана и история ОС MINIX, сначала 1, а потом и 2, которую можно рассматривать как предысторию героини сегодняшнего рассказа. И которая завершилась анонсом MINIX 3, состоявшимся 24 октября 2005 года. Насколько повторяясь, подчеркну: это была не просто следующий релиз прежних MINIX'ов, а совершенно новая операционная система, и цифра «3» здесь – не номер версии, а часть её имени собственного. Таненбаум неоднократно подчеркивал, что сходство ее с предшественниками – лишь в первом компоненте названия, а различие между MINIX 1/2 и MINIX 3 не меньше, чем между Windows 3.1 и Windows XP.

Отныне MINIX 3 более не рассматривалась как учебно-показательная разработка, а позиционировалась как всамделишняя операционная система общего назначения, предназначенная, в перспективе, для широкого класса устройств, в том числе и встраиваемых. Это символизировалось и сменой правового статуса системы: отныне она распространялась под лицензией BSD.

Официальный сайт проекта – .minix3.org. Интересно, что буквально через несколько месяцев после анонса MINIX 3, 1 февраля 2006 года, Романом Игнатовым был создан русскоязычный ресурс по этой системе – minix3.ru, который успешно развивается и по сей день.

Отличие новой системы заключалось ещё и в модели разработки. MINIX 1 и MINIX 2 были фактически личными творениями Эндрю Таненбаума, а все дополнения к ней, вроде ставшего знаменитым патча Брюса Эванса (именно с его дополнением использовал MINIX Линус Торвальдс для работы над своей будущей операционкой), носили, в силу условий распространения, сугубо неофициальный характер.

К разработке же MINIX 3 Таненбаум с самого начала привлёк широкий круг участников – от своего соавтора по второму изданию учебника Альберта Вудхалла до студентов, аспирантов и сотрудников Университета Врийе, а также волонтёров. Состав участников проекта, по понятным причинам, был весьма текучим, и перечислить их всех поимённо не представляется возможным. Однако нельзя не отметить среди них наших соотечественников – упомянутого выше Романа Игнатова и Евгения Иванова.

 

О микроядрах

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

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

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

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

С другой стороны, в понятие аппаратной части включаются и внешние, по отношению к системе процессор/память, устройства, от видеокарт и жестких дисков до принтеров, сканеров, сетевых адаптеров и многого, многого другого.

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

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

В результате ядра стали катастрофически увеличиваться в размерах. Что влекло за собой а) непроизводительные расходы ресурсов, в первую очередь памяти, и б) рост числа ошибок, обусловленный огромными объемами «ядрёного» кода, недоступного восприятию человека.

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

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

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

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

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

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

Из свободных микроядерных реализаций наибольшую известность приобрело микроядро Mach, разрабатывавшееся вплоть до второй половины 90-х годов университетами – сначала Карнеги-Меллона, а затем штата Юта. Различные его версии в разное время составляли основу законченных систем, как свободных – BSD Mach (она же xMach) или Yamitt, так и проприетарных – NeXT и продолжившей её дело MacOS X. Все они имели в своем составе микроядро Mach, поверх которого запускалась драйверно-сервисная часть от ядра BSD, собранная в виде отдельного модуля.

Впрочем, из всех перечисленных систем только BSD Mach можно назвать по настоящему микроядерной, так как у него BSD-окружение ядра функционировало в пользовательском пространстве. И у NeXT, и у MacOS X BSD-окружение запускалось в том же пространстве ядра, так что микроядерными их можно назвать только по имени. А Yamitt в том виде, в каком я её наблюдал, просто не запускалась вообще.

Наконец, как мы видели, начиная с 1987 года и по настоящее время существует MINIX 1/2, основанная на собственной реализации микроядра. Каковую, в рамках очерченных для ннеё задач, можно считать удачной. А вот будет ли сопутствовать удача её потомку – микроядру нашей героини, MINIX 3, рассудит история.

 

Собственно о MINIX 3

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

Отличие первое – микроядро MINIX 3 самое микроядреное микроядро в мире. Из него вычищено все, кроме перечисленных ранее компонентов, таких, как обработчик прерываний, средства запуска и останова процессов, планировщик задач, механизм межпроцессного взаимодействия; правда, почему-то в ядро включён и один из сервисов – сервис часов. В результате все это хозяйство укладывается менее чем в 4000 строк кода – и только оно исполняется в пространстве ядра.

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

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

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

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

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

Однако имеет ли скорость загрузки системы к быстродействию ее при реальной работе? Отнюдь. Достаточно вспомнить, что MS DOS 3.3 на IBM PC/XT грузилась быстрее, чем любой Linux на любом супер-мега-Ivy Bridge. Перефразируя слова Сергея Образцова, измерение скорости загрузки ОС, строго говоря, даже к скорости загрузки ОС никакого отношения не имеет. Потому как зависит скорость загрузки в первую очередь от количества подгружаемых модулей и стартовых сервисов. Так что измерение её на самом деле меряет радиус кривизны рук пользователя, меру его лени или, напротив, количество свободного времени, которое он способен выделить на доведение системы до ума. А в последнее время, с распространением SSD-накопителей, скорость загрузки ОС вообще измеряет толщину кошелька пользователя или степень его жадности.

Не лучше и с тестами на реальных приложениях под разными ОС. Например, со столь любимым сравнением скорости обработки запросов web-сервером под Linux и FreeBSD, на основании чего делается вывод о превосходстве одной операционки над другой. Кстати, и не помню даже, кого над кем, да это и не важно. Потому что сразу же возникает закономерный вопрос: а что меряется в этом случае? Сравнительное быстродействие ОС? Или все-таки качество реализации конкретной версии Apache или, например, MySQL под ту и другую систему?

В общем, отдав в свое (не такое уж давнее) время дань увлечению всякого рода тестированием (это занятие было бы точнее классифицировать как пузометрию или … ну, то, что в этнографической литературе называют «сравнением мужей», подробно описанному в книжке: Мир FOSS. Заметки гуманитария), я пришел к стойкому убеждению, что в большинстве случаев это либо измерение аршином с точностью до ангстрема, либо, по изящному выражению Таненбаума, сравнение яблок с апельсинами.

И тем не менее, методика тестирования, предложенная командой Таненбаума, производит впечатление. Во-первых, она (команда) поставила себе целью оценить влияние на быстродействие системы одного-единственного фактора: выноса драйверов за пределы ядра и перемещения их в пользовательское пространство. И потому тестирование быстродействия MINIX 3 проводилось… на MINIX 2. Каким образом? Очень просто: в качестве сравнительных объектов использовались каноническая MINIX 2, с одной стороны, и она же, пересобранная с удалением из ядра драйверов устройств и еще некоторыми модификациями, что фактически превратило её в MINIX 3.

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

Результаты оказались парадоксальными. Разумеется, квази-Minix 3 проиграла MINIX 2 по всем статьям. Но давайте посмотрим, где и насколько.

По чисто «ядерным» тестам вроде исполнения системных вызовов отставание первой составило 12%, по тестам на файловых операциях и запросах к базам данных – 8-9%, по тестам на реальных приложениях – 6%. Последнее на современных машинах практически равнозначно отсутствию визуальной разницы вообще.

 

Чего нет у рыб?

Результаты тестов, о которых я только что говорил, были опубликованы в работе  «A Lightweight Method for Building Reliable Operating Systems Despite Unreliable Device Drivers» ещё в январе 2006 года. Они показали, что катастрофического провала производительности при переходе к «чистому» микроядру не наблюдается. И, следовательно, идея, положенная в основу архитектуры MINIX 3:

   • имеет право на существование, и

   • заслуживает дальнейшего развития.

Так что дело оставалось за малым: воплотить идею во что-то, реально работающее. А до этого на момент публикации результатов тестов, MINIX 3 было также далеко, как омарам – нетрадиционным способом пробраться до города Пекина.

Обычно, когда описывают особенности некоей системы, разговор начинается с того, что в ней есть. Я же нарушу традицию, и расскажу о том, чего с MINIX 3 не было. И даже не в момент её анонса, а более чем год спустя, на рубеже 2006-2007 годов, когда мне довелось познакомиться с ней воочию – в актуальной на тот момент версии 3.1.2.

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

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

С MINIX 3 – случай аналогичный. Монокль к установочному ее диску не прилагается, и полное собрание сочинений Шпильгагена на нем не присутствует (да и вряд ли вообще существует в оцифрованном виде). Однако, как и с рыбами, список отсутствующих в MINIX 3 функций моноклем и Шпильгагеном далеко не исчерпывается.

Итак, в MINIX 3 отсутствовали:

   • поддержка огромного количества современного оборудования – от шины USB до интерфейса SATA, а видеоподсистема обеспечивала работу только в VESA-режиме;

   • возможность динамической линковки приложений с функциями системных библиотек;

   • поддержка каких-либо файловых систем, кроме своей собственной – даже доступ к ISO 9660 осуществлялся через устройство, которое у людей располагается обычно чуть ниже спины;

   • поддержка виртуальной памяти.

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

И они стояли её доблестно: постепенно в MINIX 3 появилась поддержка виртуальной и разделяемой памяти, иных файловых систем, вплоть до подсистемы FUSE с экспериментальной поддержкой NTFS. Обрастала она и драйверами устройств, расширялся круг портированных приложений, в том числе за счёт задействования системы pkgsrc – той же самой, что была принята на вооружение в DragonFlyBSD.

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

И ныне, пожалуй, в MINIX 3 не найти разве что, действительно, монокля и полного собрания сочинений Шпильгагена – большинство остальных атрибутов полноценной операционки в ней имеется. Что внушает оптимизм относительно его дальнейшего развития.

 

Заключение

Вот о будущем всех трёх родившихся на наших глазах операционных систем я и хотел бы сказать несколько слов под занавес. С одной стороны, и DragonFlyBSD, и MINIX 3 развиваются – может быть, не такими темпами, как хотелось бы их поклонникам, но поступательно и необратимо. Правда, о Syllable этого не скажешь – её жизнь протекает ни шатко, ни валко. Но относительный успех хотя бы двух систем из трёх, на фоне бурного развития Linux»а, показателен. Это при том, что разработчики Free- и других BSD тоже не сидят сложа руки.

С другой стороны, Год Великого перелома, о котором речь пойдёт в одной из следующих статей цикла, смешал карты: сначала интенсивная десктопизация Linux, а затем внедрение её инкарнации – Android»а , казалось бы, не оставил для всех других операционных систем места под солнцем.

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

 

Как бы ни хотелось апологетам абстрактной свободы вообще и свободы софта откреститься от внешнего мира, с его презренными проприетарными разработками, результаты их деятельности сосуществовали с последними в едином пространстве. И сосуществование между этими общественно-технологическими системами было если и не всегда мирым, то обычно взаимонаправленным. И, подобно тому как Linux проникал в enterprise-среду, проприетарные UNIX'ы предпринимали попытки внедриться на пользовательские десктопы. Зачем и почему? Не трудно ответить.

 

Зачем нужен десктопный UNIX

На протяжении многих лет изо всех закоулков FOSS-мира слышались радостные вопли о UNIX'е с человеческим лицом. А с распространением Linux'а они стали перемежаться стонами о неготовности его к десктопу.

Зачем надо готовить Linux к десктопу? Исторический опыт, в том числе и отражённый в этой книжке, однозначно свидетельствует, что система, пришедшая в дома на пользовательские десктопы, неизбежно рано или поздно окажется в промышленном секторе.

Это хорошо иллюстрируется случаем с Windows: её 95-я инкарнация, появившись на пользовательских десктопах сначала как платформа для запуска игрушек, быстро проникла на десктопы и офисных работников. А с выходом сестры во интерфейсе – Windows NT 4.0 – оказалась и достаточно массовой средой для серверов рабочих станций. И с тех пор только укрепляла свои позиции по всем фронтам.

Напротив, enterprise-систему, на пользовательские десктопы не попавшую, столь же неизбежно ждёт увядание и в её основной, промышленной, нише. Забегая вперёд, скажу, что такова была судьба проприетарных UNIX'ов, таких как Tru64, HP-UX, Sun Solaris и ряд ныне забытых: иные мертвы, остальные существуют по инерции, на старых корпоративных контактах. И одна из причин том – недостаточное внимание десктопному сектору.

Как показывает история, системам, не преуспевшим на десктопах, мало чего светит и на противоположном полюсе пользовательского пространства – на всякого рода гаджетах. И тут достаточно вспомнить блистательный взлёт PalmOS и Symbian, не имевших никаких десктопных традиций – и их медленное, но неуклонное отступление под натиском Windows Mobile/CE, перешедшее затем в паническое бегство.

В меньшем масштабе история повторилось и при появлении нетбуков: модели с предустановленным Linux'ом быстро исчезли из прайс-листов. И не вследствие козней «Империи зла», а из-за отсутствия спроса. Отдельные же сохранившиеся реликты – не более чем платформы для установки пиратской Windows.

Подозреваю, что в ближайшее время следует ожидать и ещё одного витка истории. С появлением Windows 8, в том числе и в мобильной модификации, сдадут свои позиции гаджеты на Android'е, казалось бы, властвующем здесь безраздельно. Ибо длинные руки Microsoft'а дотянулись до святая святых без-win'ного мира: до ARM-процессоров. И тут магия имени сработает в очередной раз: потребители гаджетной продукции, снова предпочтут устройства с системой, хотя бы именем похожей на ту, что стоит на их настольных персоналках. А поскольку Android за всё время своего доминирования на гаджетах так и не порадовал, в отличие от былых PalmOS и Symbian, своими технологическими достоинствами, к ним присоединятся и многие из тех, кого действительно можно назвать пользователями.

Я далёк от мысли считать себя самым умным. И уверен, что сказанное выше задолго до меня понимали серьёзные дяди из фирм, разрабатывающих проприетарные UNIX'ы. Почему время от времени можно было наблюдать попытки экспансии последних на рабочие столы применителей, о чём нынче не очень любят говорить вслух – или просто напрочь забыли.

 

Блеск и нищета персональных Workstation'ов

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

С одной стороны, в те времена былинные под UNIX развивалось некоторое количество обычных пользовательских приложений. Лучший текстовый процессор всех времен и народов – WordPerfect, замечательная электронная таблица Wings, в которой было реализовано большинство достижений, позднее приписанных Excel'у, Frameworks – единственная настольная издательская система, пригодная для вёрстки очень больших и очень сложно структурированных документов, – все они имели и версии под большинство проприетарных UNIX-систем. А уж что касается специализированных приложений, типа ГИС или имидж-процессоров, то они и разрабатывались под UNIX, а лишь затем портировались на Windows NT или получали аналогов под свободные UNIX-подобные системы.

С другой же стороны, в это время начала стираться грань между рабочими станциями и персональными компьютерами. С древних времён существует мнение, что рабочая станция – это что-то могучее и серьёзное, а персональный компьютер – слабое и легкомысленное. На рубеже 80-х и 90-х годов прошлого века оно имело некоторые основания: в рабочих станциях мощные высокоскоростные (в плане мегагерц) процессоры с RISC-архитектурой – в персональных компьютерах CISC-процессоры с тактовой частотой, дай бог переваливающей за 10 МГц. В «работягах» – мегабайты памяти, в «персоналках» – роковые 640 КБ, в лучшем случае до мегабайта, из которого треть невозможно использовать без дополнительных ухищрений. «Работяги» комплектуются мощными видеосистемами и крупноформатными мониторами высокого разрешения – в «персоналках» гнездятся CGA/EGA-адаптеры, к которым подсоединены соответствующие мониторы о четырнадцати дюймах. В рабочих станциях...

Да, собственно, на этом сравнение можно заканчивать: сказанного, казалось бы, достаточно, чтобы возмести между «работягами» и «персоналками» Железную Стену, разделяющую Мир Гуманного Воображения и Мир Страха перед будущим, как писали некогда классики. Не зря же приобщившиеся рабочих станций ласково называли персональные компьютеры «писюками» (причём вне зависимости от того, шла ли речь о собственно «плебейских» IBM PC или претендующих на аристократичность Macintosh’ах). Однако возгордились они рано, потому что ситуация менялась прямо на глазах.

Уже появление первых процессоров Intel 80486 с их внутренними RISC-инструкциями ознаменовало начало «стирания грани» между «персоналками» и «работягами» в номинальной вычислительной мощности, а Pentium и Pentium II процесс усугубили. И к рубежу тысячелетий можно было говорить о полном «замазывании пропасти», как бы ни пытался этому воспрепятствовать профессор Выбегалло. А поскольку в это же время происходило стремительное вымирание почти всех аппаратных платформ некогда легендарных рабочих станций, то ныне рабочая станция – это обычно, за исключением отдельных реликтов, тот же компьютер на базе архитектуры x86, что и «персоналка», и различия их – в сфере применения, определяющей детали конфигурации.

На моей памяти в 90-х годах прошлого века было три попытки проникновения рабочих станций на пользовательские десктопы. Первым на этом поле решил сыграть Hewlett-Packard со своей RISC-платформой HP-PA (Precission Architecture) и UNIX-операционкой HP-UX. Где-то в 1993-1994 годах появились сообщения о создании пользовательского варианта таких машин, в несколько урезанной (с точки зрения памяти и дискового пространства) комплектации, но зато по вполне «пользовательской» цене, сопоставимой со стоимостью тогдашних PC-брендов типа IBM или Compaq. В начале 1995 года машины эти демонстрировались на первой отечественной выставке UNIXExpo – и, должен заметить, впечатление производили изрядное, особенно в отношении 3D flying'а («облёта» виртуального трёхмерного ландшафта) и воспроизведения видео в реальном времени – на PC и то, и другое были ещё практически недоступно. Однако дальнейшего развития это начинание не получило, о причинах чего скажу чуть позже.

Вторым вступила в игру компания DEC с компьютерами на базе процессоров Alpha – первыми в те времена с точки зрения номинального быстродействия и к тому же первыми 64-разрядными. Эти машины были способны работать под управлением нескольких ОС – собственных VAX/VMS и DEC UNIX (Tru64 UNIX), а также Windows NT; существовал тогда уже и порт Linux под процессоры Alpha (кстати, вообще первый порт этой ОС на платформу, отличную от i386).

Компания DEC пошла другим путем, нежели Hewlett-Packard: она предоставила возможность сторонним производителям собирать машины на базе своих процессоров и материнских плат, прочие же компоненты Alpha-компьютеров к тому времени (на дворе был 1997 год) уже использовались стандартные, те же самые, что и для PC. Я знал две или три фирмы в Москве, собиравшие на заказ такие машины, также по цене, не превосходящей высококлассные персоналки. А комплектовались они, по желанию заказчика, любой из поддерживаемых ОС – правда, за отдельную мзду. Но не возбранялось приобретать их без ОС вообще, и устанавливать на них Linux своими силами.

В третьем раунде борьбы за пользовательские десктопы (гонг прозвучал в самом конце 90-тых) выступила компания Sun. Она также обратилась к услугам сторонних партнёров, в числе которых были и крупные российские компьютерные фирмы (например, R-Style). Они продавали самые обычные компьютеры Sparc, комплектовавшиеся из экономии стандартной для PC видеосистемой (а не собственным видеоадаптером 3D Creator, который, будучи и сам не дешевым, требовал дорогущего фирменного монитора) и IDE-дисками. В качестве предустановленной ОС на них имел место быть, разумеется, Solaris.

Все три проекта потерпели фиаско. Причин к тому было несколько:

   • и дороговизна стульев (пардон, UNIX-десктопов) для трудящихся всех стран, привыкших уже к дешёвому и относительно качественному самосбору, утратив привычку «меряться брендами»;

   • и неудачность комплектации: так, HP-PA в «пользовательском» исполнении скорее напоминал сетевую рабочую станцию, мало пригодную к автономному существованию; сфера же применения «самосборных» Sparc вообще оказывалась неясной – для пользовательских десктопов они были дороговаты, до серверов не дотягивали из-за дисковой подсистемы, а как серьезные графические станции не проходили из-за слабой видеосистемы;

   • и постепенное прекращение развития большинства пользовательских приложений для проприетарных UNIX;

   • и, наконец, просто утвердившаяся среди конечных пользователей привычка к Windows всякого рода.

Собственно, единственным из трех перечисленных проектов, имевшим шансы на успех, был вариант Alpha. Этому способствовала

   • и политика, ориентированная на «конструктора-самоделкина» (вплоть до сборщика-индивидуала – такая возможность в Москве тоже имелась);

   • и самая демократичная из всех трёх рассмотренных вариантов цена: когда в конце 1997 года я всерьёз размышлял о покупке такой машины «навалом», то высчитал, что она, при прочих равных, обошлась бы на 500 баксов дороже, чем самосборный компьютер на Pentium-II;

   • и, наконец, наличие порта самой демократичной ОС – Linux – именно её устанавливали на «самосборные альфы» все известные мне их обладатели.

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

 

Sun Solaris: глотки свободы

И такие уроки постаралась извлечь фирма Sun. К рубежу тысячелетий она осознала, что попытка «десктопизации» UNIX на собственной аппаратной платформе обречена на провал. Каковы бы ни были достоинства последней (в данном случае – платформы Sparc), не будучи массовой, по соотношению цена/производительность она и близко не сможет конкурировать в «настольном» сегменте с машинами на архитектуре x86. Что, собственно, и показала история с «народными» Sparc'ами: даже в таком обстуганном с разных сторон виде они оказывались через чур дорогими для среднего десктопа и недостаточно мощными – для десктопа класса high end.

И тогда, подозреваю, что в головах Sun'овских «кардиналов» зародились те же коварные замыслы, что несколько раньше взлелеял Билл Гейтс, а несколько позже воспроизвёл Марк Шаттлворт. И которые с успехом раскусил... нет, не Шарль де Баас де Кастельморо, известный нам под ником д'Артаньян. А всего лишь – (не очень) скромный автор этих строк.

Замыслы были просты: если не получается продвинуть в массы ОС с собственной платформой (а без продвижения в массы говорить о массовости и, следовательно, перспективе удешевления последней смешно), то почему бы не продвинуть туда же ОС на платформе массовой? В расчёте на то, что массы, привыкнув к новой ОСи на «своей» платформе, по мере своего информационного и финансового роста ринутся скупать то «железо», для которой эта ОС была создана.

Здесь можно воспользоваться поэтическим обобщением Алисы Деевой (см. сборник её Стихов и прозы в Библиотеке Блогосайта):

Чтоб тайны приподнять завесу Скажу: хотя все бабы стервы, Но путь к постели поэтессы Лежит через её шедевры.

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

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

Правда, и тут поначалу Solaris'у на десктопах ничего не светило. Один вид её листа совместимости с оборудованием вызывал скупую мужскую слезу даже у применителя Linux'а, не избалованного тогда поддержкой аппаратуры. В частности, все видеокарты, которые поддерживались использовавшимся в те годы в Solaris коммерческим X-сервером, уже являли собой музейные экспонаты. Да и последний не отличался дружелюбием к пользователю, особенно не нативному носителю английского.

Так что большой популярности Solaris для x86 не снискал даже в условно-бесплатном варианте. Тем более, что фирма Sun, как истинный хозяин своего слова, то давала его в отношении бесплатности Solaris, то забирала его обратно. Пока, наконец, не было принято кардинальное решение: открыть исходники всего, чего можно открыть без патентных осложнений со сторонними производителями. Что и было сделано в июне 2005 года.

Для открытых исходников Solaris была изобретена собственная лицензия, именуемая CDDL (Common Development and Distribution License). Она основана на известной MPL (Mozilla Public License) и, подобно последней, признаётся FSF в качестве свободной. Однако ряд особенностей делает её несовместимой с GPL – то есть невозможным использование в одном проекте кода под обеими лицензиями. Тут есть немало крючкотворских заморочек, вникать в которые – выше разумения обычного человека. Однако остаётся фактов – эта лицензия породила ряд коллизий, одна из наиболее показательных будет рассмотрена в следующей главе.

Однако просто открытием исходников Sun не ограничилась. Следуя примеру некоторых коммерческих дистрибутивов Linux (о чём пойдёт речь во второй части нашей книги), она расщепила свою ОС на две ветви – проприетарную, собственно Solaris, и свободную – OpenSolaris. И тут надо подчеркнуть, что в основной своей части первая была столь же открыта, как и вторая. И она также могла использоваться бесплатно. Отличие же заключалось в том, что собственно Solaris включала в себя некоторый дополнительный проприетарный (и закрытый) софт. Кроме того, «законный» покупатель ОС Solaris получал техническую поддержку от Sun Microsystems, которой скачиватель бесплатного варианта был, разумеется, лишён.

С тех пор ситуация изменилась. И после ответвления свободного потомка от проприетарного Solaris в этом потомке использовались те же самые Xorg, интегрированная среда GNOME, Openoffice.org и другие приложения, что и в любом дистрибутиве Linux или BSD-системе. Это давало надежду на возможность использования OpenSolaris в мирных целях. Насколько они оправдались — мы увидим в одном из следующих разделов этой главы. А пока обратимся к тому, чем завершилась история собственно OpenSolaris.

 

Мир без Солнца, или бессмертна ли мафия?

Смутные слухи о том, что фирма Sun решила продаться общественным работникам, циркулировали в Сети задолго до того, как этот факт свершился. Причём в качестве ответственного работника называли разные компании. Когда же оказалось, что в этой роли выступила Oracle, возникли опасения за судьбу свободных проектов, находившихся на Sun'итарном иждивении. А в их числе были Openoffice.org, MySQL, VitrualBox, ряд средств разработки, не говоря уже о собственной ОС – OpenSolaris, которая нас сейчас собственно и интересует. Не загнутся ли они под чутким руководством Ларри Эллисона? – думалось в народе.

Впрочем, оснований волноваться за большинство из них не было ни малейших. Так, MySQL вполне могла выступить «легковеным» дополнением к собственно СУБД Oracle. OpenOffice.org не могли бросить, как единственный «полноценный» офисный пакет из числа свободных, ввиду его явной востребованности конечным пользователем. VirtualBox и Sun Studio etc. представляли интерес для множества разработчиков, и потому их тоже легко не прикрыть.

В первую очередь опасения касались OpenSolaris, ибо возникал резонный вопрос, касающийся её проприетарного собрата, то есть собственно Solaris: а нужна ли будет Oracle ещё одна ОС,в добавление к собственному клону RHEL? И если нет – то необходимости в тестовой площадке для неё (а именно в этом качестве OpenSolaris и выступала в свои самые «солнечные» дни) не будет тем более. Сама же она, за время своего «свободного плавания» не достигла ни полностью законченного состояния, ни критической массы пользователей и разработчиков – той, что сделало бы её способной это плавание продолжать.

Ныне мы знаем, что опасения эти были не беспочвенны. Судьба всех курировавшихся Sun свободных проектов оказалась различной, но в общем и целом не трагичной, и в том или ином качестве они продолжают свое развитие. Все, кроме OpenSolaris: этот проект можно считать полностью свёрнутым: 14 августа 2010 года Oracle официально объявила о прекращении её разработки как свободной системы. Отныне она стала доступной только в бинарном виде и на условиях Oracle Technology Network Developer License, то есть только для разработки и тестирования программ под неё же саму.

Этим новый владелец OpenSolaris подписал ей смертный приговор: если она и была чем интересна потенциальным пользователям – то своими инновациями. А превратившись в Solaris... не для бедных даже, а для нищебродов, питающихся объедками с барского стола, она стала не интересной никому. Как, подозреваю, вскоре станет не интересен и «большой» Solaris – срок его жизни отмерен временем контрактов на техподдержку крупных заказчиков.

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

 

Дети Солнца

Как было сказано в одном из предшествующих разделов, после открытия исходников SunOS и большей части ей сопуствующего обрамления, от генеральной линии партии Solaris, по образу и подобию Red Hat с его Fedora, и SUSE с её openSUSE, ответвился комсомольский побег — OpenSolaris. Который, согласно известной песенке, призван был с молодым задором пробивать дорогу для почёта старикам. Впрочем, фрайер этот танцевал под музыку не долго – до продажи его «партийного куратора» фирме Oracle.

Однако открытие исходников SunOS и её обрамления спровоцировало также и несанкционированную старшими партийными товарищами активность в виде клонов. Причём первый из них, ShilliX, был представлен Георгом Шиллингом (известным разработкой утилиты cdrecord) буквально через несколько дней после данного события. Вслед за чем появились такие клоны (или дистрибутивы?) OpenSolaris, как BeleniX, Nexenta и MilaX.

Затем последовало приобретение Sun'а фирмой Oracle и закрытие разработки OpenSolaris -- ей на смену пришёл бесплатный, но не открытый Solaris «для нищебродов». Что вызвало появление свободного форка – illumos, продолжавшего развития SunOS, и разрабатываемого на его основе дистрибутива OpenIndiana, явившейся преемницей OpenSolaris.

Это была, так сказать, генеральная линия комсомола, не примирившегося с засильем партийных геронтократов из официального Solaris'а и классово чуждых буржуинов Oracle. Однако наряду с ней образовался и левый уклон.

Выше я упоминал клоны (или дистрибутивы?) OpenSolaris. Из них SchilliX как-то развивается и по сей день -- но это система, ни в коем случае не предназначенная для конечного пользователя (честно говоря, я так и не понял, для кого она предназначена, кроме её собственного разработчика). Прочие же системы не пережили продажи Sun'а и фактического сворачивания головного проекта, OpenSolaris. Но если BeleniX и MilaX тихо канули в Лету, то Nexenta породила сразу две линии систем.

Первой была Nexenta сама по себе -- своеобразная надстройка инфраструктуры Debian над SunOS и её userland'ом. Однако и она как самостоятельный продукт прекратила своё развитие довольно быстро. Ныне это своего рода основа для NexentaStor -- специализированной коммерческой системы для хранилищ данных, использующей преимущества ZFS. А вот вторая линия её развития имела неожиданное продолжение -- в виде ориентированной на десктопы системы StormOS, которая своей быстротой и компактностью вызывала ассоциации с теми дистрибутивами Linux'а, которые я некогда назвал системами быстрого развёртывания.

Система StormOS меня некогда очень заинтересовала, однако век ей был отпущен недолгий: уже через год на её официальном сайте сообщения о дальнейшем развитии стали носить очень уклончивый характер. И я почти забыл о ней -- мало ли в бозе усопших дистрибутивов UNIX-подобных систем мне довелось видеть на своём веку. Но однажды, зайдя на полумёртвый сайт проекта StormOS, я неожиданно обнаружил на нём следы очередного всхода – DysonOS, возникший в сентябре 2012 года.

По агентурным данным, разработчиком Dyson является наш соотечественник, Игорь Пашев. И она представляет собой продукт дальнейшей интеграции Solaris и Linux в его Debian-ипостаси. Если в Nexenta и StormOS (как и в современной OpenIndiana) Debian'овские механизмы накладываются на ядро и userland от Solaris'а, то в Dyson последний планомерно замещается своими GNU-аналогами. В настоящее время от исходной системы, кроме ядра и специфичных служб обеспечения (SMF, DTrace, ZFS) сохраняется также собственная LibC, которую автор в ближайшее время планирует заменить на glibc.

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

 

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

 

Вводные слова

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

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

Вне зависимости от того, реализуется ли размещение данных путем отдельных инструментов или интегрированных систем, оно должно обеспечивать выполнение ряда требований. Которые были сформулированы ещё в старом советском анекдоте. Как известно еще с те, атеистических, времен, Господь Бог, создавая человека, хотел сделать его умным, честным и партийным. Но оказалось, что даже он, при всём своём всемогуществе, не смог ему дать больше двух качеств вместе.

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

 

Дисковая разметка

Говорят, что во времена далекие, теперь почти былинные, файловых систем не было: информация на носители записывалась побитно, без всякой организации в именованные её наборы. Впрочем, такой способ записи данных применялся и много позднее – например, при резервном копировании на стриммерные ленты. Можно обходиться без файловых систем и при записи на стандартные блочные устройства – винчестеры, SSD, компакт-диски. Однако в большинстве случаев данные на носителях блочного типа организуются в виде файлов, а файлы объединяются в файловые системы – плоские, как в древнем DOS’е, древовидные, как во всех UNIX-подобных операционках, или, так сказать, «многодревные», как в Windows. Каковые могут быть созданы непосредственно на носителе как raw-устройстве, но обычно накладываются на дисковые разделы.

До недавнего времени в Linux’е применялась разметка в MS-DOS-стиле, предполагающая возможность разбиения диска на четыре раздела, называемых первичными [primary partitions]; один из них может быть определён как расширенный раздел [extended partition], внутри которого по «матрёшечному» принципу можно создать логические разделы, максимальным числом до 63.

Разметка в MS-DOS-стиле преобладает в дистрибутивах Linux’а и по сей день. Однако всё большее распространение получает разметка в GPT-стиле. Среди её преимуществ – возможность создания на диске до 128 абсолютно равноправных (то есть не разделяющихся на физические и логические) разделов. А в случае использования винчестеров «продвинутого» формата [Advanced Format] и SSD, размер блоков которых равен 4 КБ, она обеспечивает оптимальное выравнивание границ разделов.

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

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

 

Массивы и логические тома

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

Для решения задачи объединения физических носителей в единое логическое устройство и «размазывания» по ним файловых систем традиционно используется два основных способа: RAID (Redundant Array of Independent Disks – избыточный массив независимых дисков) и LVM (Logical Volume Manager – менеджер логических томов).

RAID’ы существуют трёх видов – аппаратные, квази-аппаратные (так называемые Fake RAID) и чисто программные (Soft RAID). Первые дороги и на десктопах почти не встречаются; работа вторых под Linux’ом часто проблематична, так что речь пойдёт в основном о третьих. Впрочем, с точки зрения логики это роли почти не играет.

Логически в любом из RAID’ов несколько дисков (а в Soft RAID – и дисковых разделов) могут просто слиться воедино (Linear RAID), при записи на них может осуществляться расщепление данных [stripping], что приводит к ускорению дисковых операций (RAID Level 0); на объединенных разделах можно создать различные формы избыточности, обеспечивающей восстановление данных при отказах дисков. Из таких избыточных массивов чаще всего используется полное дублирование (RAID Level 1, он же mirror) или избыточность за счет контрольной суммы (RAID Level 5). Наконец, возможно и совмещение стриппинга с дублированием.

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

Этим целям служит технология LVM, объединяющая физические носители в группы логических томов, разделяемых на собственно логические тома, которые, в свою очередь, разбиваются на экстенты – объединения физических блоков дисковых устройств. Логические тома предстают перед операционной системой как обычные разделы, каждый из которых может нести свою файловую систему. При этом технология LVM даёт возможность при необходимости перераспределять физическое пространство носителей между ними посредством добавления или отнятия экстентов на лету, не только без переразметки дисков, но и без перезапуска системы.

Технология LVM может обеспечить, как и RAID Level 0, стриппинг данных между физическими томами с целью повышения быстродействия файловых операций. А в сочетании с Soft RAID позволяет и создавать массивы с полной (зеркалирование) или частичной (за счёт контрольных сумм) избыточностью, повышающей надёжность. Таким образом, LVM выполняет оба поставленных условия: слияние дискового пространства, в том числе и вновь подключаемых накопителей, и возможность его перераспределения между существующими файловыми системами, да ещё и с бонусом в качестве повышения быстродействия. Комбинация же LVM и Soft RAID позволяет и повысить надёжность. Казалось бы, чего ещё не хватает для счастья?

Чтобы ответить на этот вопрос, следует вспомнить тезис Господа Бога об уме, честности и партийности. То есть в нашем случае – о быстроте, надежности и простоте использования. В соответствие с чем видим:

   • либо быстрое и простое решение на основе RAID Level 0, не блещущее надёжностью;

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

   • либо, наконец, относительно надёжное и потенциально быстрое решение при использовании технологии LVM – однако о простоте здесь можно забыть сразу: если установить LVM позволяет инсталлятор почти любого современного дистрибутива, то управление логическими томами и по сей день задача не из самых тривиальных.

К тому же мы забыли о файловых системах. А они вносят свою, и немалу, лепту в соотношение «ума, честности и партийности».

 

Файловые системы

Изначальная файловая система Unix носила имя s5fs (то есть файловая система System V). По свидетельству современников, была она отменно медленной, да еще и не допускала имен файлов из более чем 14 символов. А поскольку в те времена в Университете Беркли также разрабатывалась версия Unix (именовавшаяся BSD Unix – предтеча всех современных BSD-систем), то берклианцы решили поправить дело. И создали в 1983 году файловую систему, названную FFS (Fast File System, где первое слово символизировало ее быстроту сравнительно с s5fs).

Поскольку FFS, как и прочие разработки берклианцев, была свободной, создатели проприетарных Unix'ов не погнушались включить поддержку FFS в очередную версию канонической System V. А уже от нее и произошло, прямо или косвенно, большинство современных файловых систем UNIX, как проприетарных, так и свободных. Хотя для нашего повествования имеет значение только UFS из FreeBSD.

Вообще говоря, UFS расшифровывается просто как файловая система Unix (Unix File System). И под этим именем известны и файловые системы других ОС этого семейства, отнюдь не идентичные UFS из FreeBSD (например, файловая система SunOS и Solaris). Так что некоторая неопределенность терминологии имеет место быть.

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

Другим новшеством UFS, появившемся несколько позже, стал парадоксальный механизм Soft Updates, приводящий к росту одновременно и надёжности, и быстродействию файловой системы. Он, с одной стороны, выполнял контроль за последовательностью зависимых обновлений (тем самым способствуя целостности состояния файловой системы и, следовательно, её надёжности). С другой же стороны, при включенииSoft Updates происходила группировка нескольких обновлений в единую атомарную операцию синхронного обращения к диску. Что и вызывало рост быстродействия файловых операций.

И действительно, по производительности UFS+Soft Updates была вполне сопоставима с файловой системой Linux'а – ext2, хотя последняя по умолчанию работала в асинхронном режиме, а UFS – в частично синхронном (с немедленной записью метаданных и отложенной – блоков данных). А в отношении надёжности они были просто не сопоставимы: в те далёкие годы, да ещё и не иобильные с точки зрения бесперебойников, полный развал ext2 при «мёртвом» зависании или сбое питания был делом достаточно обычным, тогда как с UFS у меня такого не случалось ни разу.

В 5-й ветке FreeBSD на смену UFS пришла её усовершенствованная, 64-битная, модификация. Которая привнесла немало удобств (в частности, выполнение операции fsck в фоновом режиме на смонтированных файловых системах), однако ценой этого было быстродействие – точнее, его потеря. Не случайно именно тогда от FreeBSD отпочковалась DragonFly с её файловой системой Hammer, правда, находящейся тогда только в голове создателя, Мэтта Диллона.

В Linux'е же поначалу использовалась файловая система MINIX, созданная Эндрю Таненбаумом для своей одноимённой ОС на базе классической s5fs, без всякого влияния берклианских наработок. Она имела массу ограничений, в частности, на максимальный размер в 64 МБ (вследствие своей 16-битности), на длину имени файла (14 символов). Что и послужило причиной для её усовершенствования, выполненных Линусом Торвальдосм одновременной с работой над ядром. Что в итоге вылилось в файловую систему extfs (Extended File System), уже 32-битную, с обычными для этого класса поддержкой разделов до 2 ГБ и длины имён файлов до 256 символов. Хотя MINIX долгое время использовался в Linux'е для его загрузочных дискет, а поддерживается ядром чуть ли не по сей день.

Однако и на extfs творческая мысль разработчиков не остановилась. Для ликвидации некоторых присущих ей ограничений, например, в атрибутах файлов, в 1993 году Реми Кард (Remi Card) разработал улучшенную её модификацию, названную ext2. Именно она стала на долгие годы стандартной для ОС Linux. И используется по сей день, оставаясь эталоном быстродействия.

Думаю, каждого, кто начинал знакомство с Linux’ом во времена безраздельного господства файловой системы FAT в DOS/Windows, ext2fs поражала скоростью выполнения всех файловых операций. Что было обусловлено эффективностью их кэширования и полностью асинхронным режимом работы. За что, как уже только что было сказано, приходилось платить надёжностью – сбой системы по любой причине влёк за собой тяжкие последствия, вплоть до полного разрушения файловой структуры. Но и даже когда до полной катастрофы дело не доходило, отказы (например, по питанию) вызывали за собой долгую и нудную процедуру проверки целостности файловой системы.

Для решения проблемы надёжности файловой системы (они, хотя и в различной степени, касались всех UNIX'ов) предлагались различные механизмы – Soft Updates, о котором только что говорилось, был одним из них. Однако магистральная линия развития файловых систем пошла по пути так называемого журналирования. Суть его в том, что сведения о файловых операциях записываются в специальный файл журнала до того, как эти операции будут фактически выполнены. Это дает возможность после любого сбоя «откатить» файловую систему до последнего непротиворечивого состояния. Оборотной стороной чего, как обычно, яв.ляется снижение быстродействия – различное для отдельных файловых систем и видов файловых операций.

Эпонимом журналируемых файловых систем стала JFS, разработанная IBM для собственных RISC-станций и своего же варианта UNIX — AIX (1990-й год). Затем, в варианте JFS2, она была портирована сначала на серверную версию OS/2 (конец 90-х годов), бившуюся тогда в последней стадии агонии, а вслед за тем — и на Linux, разумеется. Где она и прижилась под именем просто JFS. И стала, кажется, первой «чужой, но породнившейся» файловой системой, поддержка которой была официально включена в каноническую версию ядра — точной даты не помню, но где-то аккурат рядом с рубежом тысячелетий.

Однако широкого признания Linux-реализация JFS не снискала – ни тогда, ни в последствии. В частности, и вследствие исключительной медлительности – в этом отношении она могла поспорить только с UFS2 из FreeBSD. Причина заключалась в том, что в Linux-версии разработчики отказались от собственного кеширования файловых операций (наличествовавшего в реализациях JFS для AIX и OS/2), положившись на то, что эта функция будет выполняться ядром.

Следующей журналируемой файловой системой в Linux стала ReiserFS, разрабатывавшаяся специально для этой ОС Хансом Рейзером (Hans Reiser) и сотрудниками его фирмы Namesys, начиная с конца 90-х годов. Официальную поддержку в каноническом ядре она обрела с выходом его версии 2.4.

Коньком ReiserFS (кроме собственно журналирования) была работа с очень большими массивами очень маленьких файлов – то есть файлами меньше логического блока файловой системы (обычно в диапазоне от 512 байт до 4 Кбайт). А таких в любой UNIX-системе действительно несчётное множество. Типичный пример – дерево портов FreeBSD или портежей Gentoo.

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

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

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

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

Во-вторых, говоря о возможности восстановления данных из блоков, утративших привязку к своим inodes, я не случайно употребил определение «теоретическая». Потому что на практике это занятие чрезвычайно трудоемкое, не дающее гарантированного результата. Каждый, кому приходилось этим заниматься, согласится, что предаться ему можно только от полной безысходности. И это относится ко всем файловым системам Linux. Так что этим аспектом при выборе файловой системы можно пренебречь.

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

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

Главная же проблема ReiserFS была в другом – в совместимости. Сначала она «из коробки» поддерживалась очень малым количеством дистрибутивов, и совсем не поддерживалась никакими другими ОС, даже соплеменными BSD. Только в DragonFly довольно быстро реализовали модуль её поддержки в режиме «только для чтения» – но отношение этой операционки к другим файловым системам всегда было особым.

Проблема с совместимостью для ReiserFS возникла и в последние годы. Если раньше она «ещё не поддерживалась» многими дистрибутивами, то теперь один за зругим дистрибутивы её «уже не поддерживают». Видимо, скоро она исчезнет и из ядра Linux'а.

Чтобы более не возвращаться к этому вопросу, замечу, что на протяжении ряда лет Ханс Рейзер и фирма Namesis разрабатывали файловую систему Reiser4. Это не была очередная версия ReiserFS (развитие той остановилось на версии 3.6.X), а существенно новая разработка, в детали которой вдаваться сейчас не буду: до полной пригодности к практическому применению она доведена не была, и теперь уже, наверное, никогда не будет. О некоторых причинах можно догадаться, прочитав соответствующий раздел в книге Мир FOSS. Заметки гуманитария, имеющей место быть в Библиотеке Блогосайта.

Зато идеалом с точки зрения совместимости оказалась ext3fs – журналируемая модификация классической ext2: представленная на рубеже тысячелетий Стивеном Твиди (Stephen Tweedie), она, однако, получила поддержку в ядре Linux'а не сразу, а даже позже, чем ReiserFS. Однако после этого была включена практически во все дистрибутивы и, следовательно, могла быть прочитана почти на любой Linux-машине. Более того, она осталась полностью совместимой с ext2 по формату. То есть прародительница превращалась в ext3 лёгким движением руки – точнее, добавлением к ней журнала с помощью утилиты tune2fs не только без остановки машины, но даже без отмонтирования целевого носителя. Не менее проста была и обратная процедура – ext3 можно было просто перемонтировать без журналирования, и тогда она становилась самой обычной ext2. Утилиты для работы файловой системой (создания, проверки и так далее) для ext2 и ext3 также были одними и теми же.

В ext3 (и это была её особенность) предусматривалось три режима работы:

   1. журналирование с обратной записью (writeback), когда в файл журнала записываются только изменения метаданных файлов;

   2. последовательное, или обычное (ordered), задействуемое по умолчанию – также с журналированием только метаданных, но с группировкой связанных с ними данных в единую транзакцию;

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

Теоретически считается, что от первого режима к третьему возрастает надёжность файловой системы, но уменьшается быстродействие. В отношении быстродействия – вопрос спорный: Дениэл Роббинс (Daniel Robbins) приводи случаи, когда режим полного журналирования оказывался быстрее не только последовательного, но даже журналирования с обратной записью. По моим наблюдения, показатели быстродействия ext3 были вообще невоспроизводимы и от режима журналирования не зависели вовсе. И в любом случае уступали интегральной скорости работы в ReiserFS (не говоря уже о ext2), будучи сопоставимыми с UFS (не UFS2!) при включении Soft Updates.

Отступление для тех, кто не знает: Дениэл Роббинс был не только создателем дистрибутива Gentoo, но и автором большого количества технических статей, публиковавшихся на сайте IBM для разработчиков свободного софта. Среди этих статей (кстати, обладающих незаурядными литературными достоинствами) было Руководство по продвинутым файловым системам, известное в русском переводе Владимира Холманова. А размещались эти переводы первоначально на сайте линуксоидов города Ярославля, созданном в незапамятные времена Александром Благиным и существующем, как ни странно, до сих пор.

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

Спорить на счёт устойчивости ext3 не буду. Но моё личное мнение по этому вопросу таково: устойчивость файловой системы вообще зависит от личного везения применителя. Особенно если речь идёт о сравнении ext3 и ReiserFS: жалоб на развал при аварийном завершении работы по поводу первой я слышал не меньше, чем относительно второй.

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

Тем не менее, как я уже сказал, репутация часто оказывается самым весомым фактором – и на протяжении долгого времени ext3 предлагалась по умолчанию инсталляторами большинства дистрибутивов.

Ныне, однако, ext3 почти вышла из употребления. Если ext2 всё ещё нередко применяется в ряде специальных случаев (например, для носителей небольшого объёма или там, где журналирование в принципе не имеет смысла), то в амплуа файловой системы общего назначения нынче выступает ext4. Она была разработана Эндрю Мортоном (Andrew Morton) в качестве экспериментальной в 2006 году, и в 2008 принята в ядро Linux'а как стабильная. С тех пор она развивается и поддерживается командой разработчиков, из которых наиболее известен Теодор Цо (Theodore Ts'o).

Подобно ext3, ext4 представляет собой дальнейшее развитие линии ext2, но уже без сохранения совместимости на уровне формата и инструментария. В ext4 предусматривается те же три режима журналирования, что и в ext3, с теми же названиями и особенностями. Однако в ней добавлен и четвёртый – режим работы без журнала вообще. Считается, что в этом режиме она наконец смогла отобрать у ext2 лавры рекордсмена по интегральному быстродействию.

Однако я забежал вперёд – ext4 не стала ещё достоянием истории и, похоже, не собирается это делать в обозримом будущем. Потому что следующей журналируемой системой по очередности появления в Linux'е стала XFS. Хотя создана она была много раньше – в 1994 году, усилиями фирмы Silicon Graphics, для её собственного варианта UNIX'а – IRIX. И была одной из первых 64-разрядных файловых систем.

К весне 2001 года относится открытие исходников XFS под лицензией GPL и разработка Linux-реализации. Долгое время её поддержка ядром этой ОС обеспечивалась только сторонними патчами – официально она была включена в ядро только в 2004 году. Да и после этого какой-то период по умолчанию поддерживалась не всеми дистрибутивами.

Но постепенно XFS утвердилась в Linux'е в качестве стандартной, чему способствовали её особенности, хорошо вписавшиеся в изменившиеся реалии окружающего мира. Если ReiserFS лучше всего показывала себя в обращении с маленькими файлами, то «коронкой» XFS была работа с очень большими файлами на очень больших файловых системах. Что и не удивительно, если вспомнить о её происхождении: фирма Silicon Graphics (ныне SGI) издревле была ориентирована на профессиональные средства в области графики и мультимедии, данные которых требовали большого объёма дисковой памяти и организации её в виде больших файлов. К середине нулевых годов это оказалось востребованным и в Linux'е.

Однако это было не единственной причиной распространения XFS: она (с некоторыми оговорками, о которых я скажу чуть позже) отличалась также впечатляющей производительностью и высокой надёжностью. Причём в полном блеске показывала своё быстродействие на многодисковых устройствах (multiple devices), то есть на аппаратных и программных RAID'ах, которые тоже получили широкое распространение в это время.

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

Затем это безобразие пытались побороть, включив в XFS по умолчанию опцию write barriers, от сей напасти избавляющую. Что, однако, привело к падению быстродействия на некоторых операциях. В частности, удаление большого количества маленьких файлов (а в работе с маленькими файлами XFS не блистала и без этой опции) стало происходить просто удручающе медленно.

При этом проблема потери данных при сбоях до конца решена не была, хотя и не стояла так остро. Однако, с учётом и старых вопспоминаний, отношение к XFS местами было настороженным. Хотя эта система уже давно предлагается по умолчанию в инсталляторах некоторых дистрибутивов, причём отнюдь не самых «мультимедийных» или «промышленных», таких как Zenwalk или Salix.

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

Отступление. Интересно, что это перекликается с позицией Google. Как-то в сеть просочилась информация, что на серверах этой компании используется исключительно ext4 – и в режиме без журналирования (without journal). Как я недавно говорил, теоретически это должно обеспечивать максимальную производительность. Что же до неизбежного в таком случае риска нарушения целостности файловой системы при сбоях – в Google предпочитают бороться с этим путём обеспечения качественного электропитания. Впрочем, надо заметить, что своё решение Google как панацею от всех бед отнюдь не пропагандируют. Видимо, опять таки помня, что водка, легко доступная министру, не всегда по карману не только бичу, но даже простому инженеру.

Изменение отношения к XFS совпали с изменением модели её развития. Фирма-создатель, ныне носящая имя SGI, постепенно отстранялась от дальнейшей её разработки – в последние годы она осуществлялась в основном силами программистов, по совместительству являющихся сотрудниками Red Hat. В конце концов SGI отказалась от поддержки XFS вообще, и ныне эта файловая система продвигается Red Hat'ом. В частности, она будет файловой системой по умолчанию в RHEL 7.

Рассказ о традиционных файловых системах уместно закончить упоминанием файловой системы Tux3. Это экспериментальная файловая система, развиваемая Дениэлем Филиппсом (Daniel Phillips) на протяжении уже пятнадцати лет, но так никогда и не анонсировавшаяся в качестве окончательного релиза. Отличительной её особенностью является версионная модель. То есть каждый файл в ней существует в виде нескольких разновременных вариантов, что в случае сбоев выполнять откат до последнего работоспособного.

Впрочем, когда мы эту файловую систему увидим – не ясно. Её разработчик лет пять назад в одном интервью высказался по сему поводу очень оптимистично: это случится раньше, нежели портирование на Linux файловой системы Hammer из DragonFly (о ней будет сказано позднее). Учитывая, что с тех пор никто вроде бы и не начинал работы по продвижению Hammer'а в Linux – времени у Дениэла ещё вдоволь.

Резюмирую затянувшийся базар о файловых системах. Можно видеть, что с точки зрения простоты использования ни в одну из файловых систем Linux’а бросить камень рука не подымется: создание и монтирование их никаких трудностей не сулит. Так что требование «партийности» для них выполняется, пожалуй, при любых соотношениях «ума» и «честности». Но эта ситуация сохраняется, пока мы не начинаем комбинировать «ум, честность и партийность» файловых систем с аналогичными качествами систем управления RAID’ами или с LVM. В частности, вследствие многоуровневости всех этих решений. И очевидно, что удлинение «цепочки» уровней в любом случае приводит к снижению надежности: чем больше в ней звеньев, тем вероятней отказ всей цепи.

И тут-то и возникает вопрос: а нельзя ли уменьшить количество уровней, сделать систему более «плоской»? Попыткой ответа на этот вопрос и стали интеригрированные системы размещения данных.

 

Из истории систем размещения

Не в интересах правды, а истины ради нужно заметить, что комплексные системы размещения данных – отнюдь не порождение мира FOSS, их корни лежат в недрах проприетаризма. И первой из них была, видимо, файловая система Veritas (или VxFS), разработанная фирмой Veritas Software и представленная миру в 1991 году. Она же претендует на звание первой в истории мироздания журналируемой файловой системы. Хотя, как говорилось в предыдущем разделе мне известно, JFS – эпоним всех журналируемых ФС – в своей реализации для AIX появилась в 1990 году, так что вопрос приоритета в отношении журналирования остаётся не вполне ясным.

VxFS является основной файловой системой в HP UX, работает также во всех ныне живущих проприетарных UNIX’ах и теоретически может применяться и в Linux’е. Однако о практических примерах такого применения, по крайней мере в не очень промышленной обстановке, я не слышал: VxFS является системой проприетарной и весьма дорогой.

VxFS тесно интегрирована с менеджером логических томов – VxVM. Благодаря чему в ней возможно изменение (в любую сторону) размера файловой системы «на лету», включение различных режимов использования томов – стриппинг данных, их зеркалирование, а также комбинации того и другого, создание избыточных массивов по типу RAID Level 5, изменение внутренней организации данных без остановки работы. Всё это позволяет VxFS (в сочетании с VxVM) претендовать на звание комплексной системы размещения данных.

Впрочем, не меньше к тому оснований было и у AdvFS – файловой системы, разработанной к 1993 году фирмой DEC для своего проприетарного варианта UNIX, именовавшегося сначала OSF/1, затем Digital UNIX, и завершившего свою жизнь под именем Tru64 UNIX. Судьба её была печальной. Снискав заслуженное признание на своей родной платформе DEC Alpha под управлением указанной ОС, она после покупки DEC фирмой Compaq оказалась в загоне. А после того, как Compaq, в свою очередь, был поглощён фирмой Hewlett Packard, использовавшей для своего UNIX’а на платформах HP PA и Itanium только что упомянутую VxFS, AdvFS оказалась совсем не при делах.

В результате HP сделала щедрый дар сообществу свободного софта вообще и Linux-сообществу в особенности: в середине 2008 года исходники файловой системы AdvFS были открыты под лицензией GPv2 – ради максимальной совместимости с ядром Linux. С предложением использовать их в этой ОС если не в качестве системной целостности, то как богатую технологическую базу. Правда, оговорка, что сама HP не заинтересована в дальнейшем развитии AdvFS, заставляла опять вспомнить народную присказку: «Возьми, боже, что мне не гоже».

Да и предложение несколько запоздало: как мы скоро увидим, к тому времени интенсивно развивались и ZFS, и Hammer, и btrfs.

Однако, помимо исходников, HP предоставила также доступ ко всей документации – благодаря чему об AdvFS при желании можно узнать больше, чем о любой другой проприетарной файловой системе для UNIX-подобных операционок. Это избавляет меня от необходимости описания её особенностей. Замечу только, что среди них мы увидим все черты развитой комплексной системы размещения данных. Те самые, которые мы наблюдаем при рассмотреннии устройства, например, ZFS. К обзору истории которой и пора перейти.

 

Начало истории ZFS

Разработчики ZFS поставили себе честолюбивую цель: создать систему хранения данных, которая отвечала бы всем трем критериям сформулированного ранее идеала. Разработка её проводилась в компании Sun Microsystems, командой под руководством Джеффа Бонвика (Jeff Bonwick) и Мэттью Аренса (Matthew Ahrens). Первоначально название ZFS рассматривалось как аббревиатура от Zettabyte File System, но быстро стало просто условным именованием. Его можно интерпретировать как последнюю точку в развитии файловых систем вообще. И в последующем мы увидим: это недалеко от истины.

Результаты работы над ZFS были представлены миру в августе 2004 года. А в 2006 году она была включена в штатный состав OS Solaris 10 (релиз 6/06). То есть, подобно своим предшественницам, она также была проприетарным продуктом. И пользователям свободных UNIX-подобных систем поначалу от ее существования было ни холодно, ни жарко. Однако период камерного существования ZFS продолжался недолго – уже в ноябре 2005 года, то есть до включения в Solaris, ее поддержка была интегрирована в открытый её вариант, OpenSolaris. Ибо она основывалась на том же ядре SunOS 5, что и коммерческий прототип.

Исходники ZFS распространяются, как и собственно OpenSolaris, под лицензией CDDL (Common Development and Distribution License). Эта лицензия, базирующаяся на Mozilla Public License (MPL), не влияет на общую лицензию проекта, в состав который включены CDDL-компоненты. И потому оказывается совместимой с большинством свободных лицензий. За исключением... какой? Правильно, GPL во всех её проявлениях.

Разумеется, ZFS была задействована в клонах openSolaris, таких, как BeleniX, SchilliX и, в первую голову, в Nexenta OS. Правда, последняя развивалась в направлении коммерческой системы хранения данных, а о числе пользователей остальных можно было только гадать.

Некоторое время ZFS была доступна пользователям Macintosh’а – в Mac OS X Leopard от осени 2007 года. Правда, ходившие перед её выходом слухи, что она будет там файловой системой по умолчанию, оказались несколько преувеличенными: поддержка ZFS оказалась опциональной и лишь в режиме «только для чтения». А в последующих версиях ОСей семейства кошачьих вообще исчезла и, видимо, уже не возродится.

Так что для широких народных масс ZFS по прежнему оставалась недоступной. Пока... пока ее не портировали под FreeBSD в 2007 году, и официально не включили её поддержку в 7-ю версию этой ОС, вышедшую в начале 2008 года. В чём, как и в дальнейшем её развитии, основная заслуга принадлежит Павлу-Якубу Давидеку (Pawel Jakub Dawidek) и Ивану Ворасу (Ivan Voras). Правда, до недавнего времени ZFS нельзя было задействовать при установке FreeBSD средствами её штатного инсталлятора и конфигуратора sysinstall. Однако это без труда можно было осуществить в дальнейшем руками. В том числе и разместить на ZFS корень файловой иерархии. А с выходом FreeBSD версии 10.0 она стала доступна применителям этой ОС, что называется, «из коробки».

С самого начала поддержки ZFS во FreeBSD появилась и возможность задействовать её, что называется, «искаропки», в десктоп-ориентированном клоне последней – PC-BSD. А с переходом FreeBSD, начиная с версии 9.0, на новую программу установки – BSDInstall, эта функция распространилась и на материнскую систему.

Успех ZFS во FreeBSD, где она стала если не главной файловой системой, то добилась равноправия с UFS2, послужил примером для других BSD-систем. Так, ныне ZFS поддерживается в NetBSD – эта работа была начата Оливером Голдом [Oliver Gould] летом 2007 года в рамках акции Google Summer of Code. А в 2009 году Адам Хамсик [Adam Hamsik] интегрировал её код в ядро NetBSD. Правда, насколько я понимаю, использование ZFS в этой операционке рекомендуется только в экспериментальных целях.

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

Таким образом, пользователям большинства BSD-систем ZFS или уже доступна как нативная, или может стать доступной в ближайшее время.

 

Из истории юриспруденции

А что же Linux, спросите вы меня? Как обстоит дело с поддержкой ZFS в самой массовой из свободных UNIX-подобных операционных систем нашего времени? А вот с Linux’ом все оказывается гораздо сложнее. Ибо не зря поминали мы выше лицензию CDDL. Которая сама по себе очень даже свободная, и не накладывает почти никаких ограничений на распространение защищаемых ею программ.

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

А вот с лицензией GPL обеих актуальных версий (v2 и v3) CDDL входит в диалектическое противоречие. Ибо любые продукты, производные от программ под GPL, вне зависимости от формы распространения, должны сопровождаться исходными текстами. Что делает юридически невозможным включение кода поддержки ZFS непосредственно в ядро Linux, распространяемое, как известно, на условиях GPLv2.

Кроме того, невозможность включения в ядро Linux кода поддержки ZFS объясняется тем, что GPL требует распространения всех основанных на ней продуктов под GPL же, тогда как CDDL – сохранения её для «своих» компонентов.

Правда, часть кода ZFS была открыта под GPL с тем, чтобы соответствующий патч можно было включить в загрузчик Grub. Это обеспечило возможность загрузки Open Solaris непосредственно с ZFS-раздела. Однако оказалось недостаточным для полноценной реализации этой системы, которую можно было бы распространять под данной лицензией.

Впрочем, не будучи юристом, ломать голову над лицензионными вопросами не буду, и моим читателям не советую, ибо понять это всё равно невозможно. А достаточно лишь запомнить, что всеми резонными и юридически подкованными людьми признано, что поддержки ZFS в ядре Linux быть не может.

Таким образом, сложилась абсурдная, с точки зрения здравого смысла, ситуация: два программных продукта под свободными лицензиями (обсуждать вопрос, какая из них «свободней другой», мы сейчас не будем), созданные друг для друга, как Huggies и... э-ээ... место пониже спины (дальнейшие события показали, что технических сложностей при портировании ZFS на Linux практически нет), невозможно было использовать в составе одного проекта. По крайней мере, для законопослушных граждан, чтущих... нет, не уголовный кодекс, а принципы свободного программного обеспечения.

И, разумеется, здравомыслящие люди попытались эту ситуацию разрешить. И первая такая попытка была предпринята ещё в 2006 году в рамках Google Summer of Code. Основывалась она на поддержке ZFS через FUSE (Filesystem in Userspace). Поскольку модуль FUSE работает как пользовательское приложение, необходимости во включение кода ZFS в ядро Linux нет, что снимает все юридические вопросы. Однако встают вопросы другие – производительности и устойчивости.

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

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

 

ZFS on Linux: технология против крючкотворства

И тем не менее, решение этой проблемы нашлось – и решение столь же изящное, сколь и очевидное. Его предложил весной 2010 года Брайан Белендорф (Brian Behlendorf), некогда один из основных разработчиков web-сервера Apache. Он создал модуль поддержки ZFS, который собирается и может распространяться отдельно от ядра, сохраняя прародительскую лицензию CDDL. А поскольку последняя, как уже говорилось, является лицензией «пофайловой», этим самым обходится антагонистическое противоречие – запрет на распространение продуктов, в которых смешан код, лицензируемый под CDDL и GPL.

На базе разработки Брайана возникло сразу два проекта. Первый осуществлялся индийской компанией KQ Infotech, которой уже в сентябре 2010 года удалось выпустить работоспособный, пригодный для тестирования патч Linux-ядра с реализацией файловой системы ZFS. А в январе следующего, 2011, года появилась финальная его версия, доступная тогда в исходниках и в виде двоичных пакетов для Fedora 14, RHEL6, Ubuntu 10.04 и 10.10.

Однако весной того же года KQ Infotech была куплена фирмой STEC, занимающейся производством SSD-накопителей, каковых, впрочем, в наших палестинах никто не видел. И работы по дальнейшему развитию нативной поддержки ZFS были свёрнуты. Хотя исходники модуля и сопутствующих компонентов до сих пор доступны, последнее их обновление происходило около назад. А информации о дальнейшей судьбе проекта с тех пор не появлялось.

Однако сам Брайн продолжал свою работу – вместе с сотрудниками Ливерморской национальной лаборатории, каковая, будучи в подчинении Министерства энергетики США, занимается не только вопросами ядерного оружия (эвфемизмы вроде Минсредмаша в ходу не только в бывшем Советском Союзе), но и разработкой суперкомьютеров. В результате скоро возник проект ZFS on Linux, в рамках которого модуль поддержки ZFS и сопутствующие утилиты поддержки, портированные из Solaris – так называемый SPL (Solaris Porting Layer), были доведены до ума, и к началу 2011 года стали пригодны для использования в экспериментальном режиме. А к настоящему времени, несмотря на формальное сохранение статуса release candidatе, порт ZFS on Linux можно считать готовым к практическому применению.

Правда, майнтайнеры основных дистрибутивов не торопились включать поддержку ZFS в свои системы даже в качестве дополнительных неофициальных пакетов. Подозреваю, что не столько из косности и лени, сколько из-за очередной сложности: видимо, по всё тем же лицензионным ограничениям модули zfs и spl приходится привязывать к фиксированной версии (и даже конкретной сборке) ядра Linux. Что, при регулярных, даже корректирующих, обновлениях последнего требует и их пересборки.

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

Достаточно подробно включение ZFS описано в Gentoo Wiki. А майнтайнеры её клона, дистрибутива Sabayon, прославившиеся своей склонностью к экспериментам, включили поддержку ZFS почти «искаропки»: соответствующие модули подгружаются при старте с LiveDVD и могут быть опробованы в «живом» режиме. Хотя штатного способа установки системы на ZFS в инсталляторе этого дистрибутива, всё из-за тех же юридических заковык, и не предусмотрено. Но нет и причин, препятствующих любому благородному дону установить этот дистрибутив на ZFS в любом виде, хоть и корня файловой иерархии. Если ему этого хочется, конечно.