Текст книги "Вопросы истории: UNIX, Linux, BSD и другие"
Автор книги: Алексей Федорчук
Жанры:
ОС и Сети
,сообщить о нарушении
Текущая страница: 12 (всего у книги 28 страниц)
Не в интересах правды, а истины ради нужно заметить, что комплексные системы размещения данных – отнюдь не порождение мира 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 в любом виде, хоть и корня файловой иерархии. Если ему этого хочется, конечно.
Часть II. История дистрибутивов
Глава одинадцатая. Начало дистрибуции
Прошлую статью я завершил на обсуждении вопроса, что же такое придумал Линус, и не GNU ли его Linux. В религиозные вопросы по сему поводу вдаваться не будем. А лучше посмотрим, что же именно Линус придумал (не считая метода разработки, который придумал Том Сойер).
Был ли дистрибутивом первозданный Linux?Общеизвестно, что Линус придумал ядро операционной системы имени... нет, не и минеральных источников, а имени себя. И это правда, чистая правда – но не вся правда. Потому что Линус придумал ещё и файловую систему ext (расширение файловой системы MINIX, которая позднее воплотилась в ext2). Кроме того, им или с его подачи был разработан набор низкоуровневых утилит для работы с ядром, его модулями, файловой системой ext – он получил имя linux-utils. Наконец, в рамках реанимированного Линусом метода Тома Сойера Вернер Альмесбергер разработал загрузчик ядра Linux – Lilo (LInux LOader), который затем, до появления GRUB'а, успешно выступал в качестве мультисистемного.
Именно этот комплекс, (почти) способный к самостоятельному существованию, и можно назвать операционной системой Linux в самом узком смысле слова. Однако он существовал не в безвоздушном пространстве. Ибо, с одной стороны, требовал средств управления – им, в силу некоторых причин, стала командная оболочка bash. А с другой – его требовалось чем-то собирать, и в этом качестве выступил компилятор gcc вместе с набором сопутствующих ему инструментов (binutils, make и так далее). И то, и другое было разработано в рамках проекта GNU – что и служит по сей день основанием для именования нашей ОС как GNU/Linux.
Подобно первозданному UNIX’у, Linux изначально являлся типичной «системой для себя». Более того, исходно единственным его назначением была разработка самого же себя – никаких других целей Линус перед собой поначалу не ставил. Да и первые пользователи Linux’а устанавливали (точнее, собирали) систему для того, чтобы её изучать и, по возможности, совершенствовать. Так что ни в каких дополнительных компонентах, кроме ядра, утилит обрамления и инструментария для их сборки, необходимости не возникало.
Установка Linux в те «времена старинные, теперь почти былинные» была задачей не вполне тривиальной даже для опытного компьютерщика (а иные его и не пользовали). И в формирующемся тогда же Linux-сообществе возникла идея облегчить им эту процедуру. В результате чего родилось понятие дистрибутив Linux. Это – система комплектации ядра ОС и его обрамления дополнительными программами и способ её распространения. Она предполагает наличие программы-установщика и средств управления пакетами, то есть теми самыми дополнительными программами.
И уже через несколько месяцев после обнародования Линусом исходников первой (0.01) версии своего ядра, в начале 1992 года, появляются первые наборы программ, которые можно считать прототипами позднейших дистрибутивов Linux – MCC Interim Linux и TAMU. Они представляли собой комплекты разработчика, включающие в прекомпилированном виде ядро, командную оболочку, компилятор со средствами сборки, а также основные пользовательские утилиты, что позволяло развернуть работоспособную систему на «чистой» машине, не несущей никакой иной ОС.
Начало началВ итоге в октябре 1992 года на свет появляется комплект, который можно назвать первым в истории настоящим дистрибутивом Linux. Он носил имя SLS (Softlanding Linux System) и был разработан Питером Мак-Дональдом. Помимо ядра Linux и утилит обрамления, дистрибутив SLS включал в себя оконную систему X и средства работы с сетью, то есть был уже вполне пригоден для конечного пользователя. Правда, не следует забывать, что конечными пользователями Linux в те годы были исключительно его же разработчики.
Дистрибутив SLS просуществовал недолго – последняя его версия вышла в 1994 году. Однако он лёг в основу целой линии дистроения, протянувшейся в наши дни яркой нитью, и потому о нём стоит сказать подробней.
Дистрибутив SLS распространялся преимущественно на трехдюймовых дискетах, в количестве 20-30 штук. Образы дистрибутивных дискет можно было получить по Сети (у нас – практически только по служебным каналам), а также заказать на CD (хотя CD-приводы в то время на пользовательских машинах были не меньшей экзотикой, чем Интернет на дому).
Одной из знаковых особенностей SLS была схема инициализации в BSD-стиле – хотя в дальнейшем в большинстве дистрибутивов майнстрима возобладал стиль System V, которую Линус заимствовал из первозданного UNIX'а.
Формат бинарных пакетов в SLS был предельно прост – tar-архив, компрессированный с помощью Gzip или compress, возможно – с постинсталляционным сценарием. Для установки и удаления пакетов использовалась утилита sysinstall – предтеча всех последующих систем пакетного менеджмента. Которая не только разворачивала архив и инкорпорировала его компоненты в файловую систему, но и фиксировала его в специальной базе данных – на предмет последующего удаления, если таковое потребуется. Хотя о контроле зависимостей тогда речи ещё и не возникало.
Прекращение разработки SLS связывается с его переходом на формат бинарных файлов ELF вместо общепринятого тогда в Linux и вообще в UNIX формата a.out. Хотя ELF был более «прогрессивен», нежели a.out, тогда это оказалось шагом преждевременным. Но, возможно, дело было просто в потере интереса разработчика к своему произведению – ситуация, с которой мы ещё не раз столкнёмся при знакомстве с историей Open Source.
О SLS ныне мало кто помнит, однако роль его в дальнейшем дистроении трудно переоценить: именно он лёг в основу старейшего дистрибутива из числа доживших до наших дней – Slackware.
