Текст книги "Вопросы истории: UNIX, Linux, BSD и другие"
Автор книги: Алексей Федорчук
Жанры:
ОС и Сети
,сообщить о нарушении
Текущая страница: 10 (всего у книги 28 страниц)
И такие уроки постаралась извлечь фирма 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 позволяет инсталлятор почти любого современного дистрибутива, то управление логическими томами и по сей день задача не из самых тривиальных.
К тому же мы забыли о файловых системах. А они вносят свою, и немалу, лепту в соотношение «ума, честности и партийности».
