27 августа 2004

Эта статья была написана почти 10 лет назад – во времена, когда казалось, что Linux и FreeBSD могут выступать на десктопном поле в одной категории. Дальнейшее развитие этой темы мы увидим в статье следующей.

Вступление post factum

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

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

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

Пара отмазок

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

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

Субъективное введение

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

В периоды, когда на моей машине живет одна FreeBSD, рабочее время мое распределяется примерно так: 90% – практическая работа (абсолютно не важно, какой характер она носит в данный момент), и 10% – более или менее нездоровые эксперименты над системой. Стоит же угнездиться в уголке винчестера какому-никакому Linux'у – и временная доля экспериментов сразу подскакивает до 50%. А в периоды, когда я занимался сборкой Linux'а с нуля, экспериментальный режим фактически становился перманентным.

И я задал себе вопрос – почему? И – для себя же – ответил: FreeBSD – цельная и стройная система, в которой, после комплекса начальных настроек не возникает желания ни прибавить чего, ни убавить. Не случайно же движение from Scratch, время от времени охватывающее широкие слои Linux-пользователей, в мире FreeBSD фактически не получило развития: известное сочинение Йенса Швайкхардта «FreeBSD from Scratch» – это скорее описание автоматизированной альтернативы sysinstall, нежели ручного построения собственной системы с нуля.

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

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

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

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

Бытует мнение, что Linux поддерживает более широкий спектр оборудования, нежели FreeBSD. Действительно, для последней мы не найдем, скажем, принтерных драйверов от производителя, полноценная поддержка современных видеокарт реализована только в том случае, если они – от NVIDIA (да и то, по отзывам, существенно худшая, нежели для Linux'а). Вероятно, возникнет в этой ОС напряженка и с т.н. win-модемами. Это – с одной стороны.

А с другой: всем счастливым обладателям контроллеров ATA RAID и Serial ATA в Linux до недавнего времени приходилось прибегать ко всякого рода ухищрениям. К тому же – не всегда удачным, особенно если присобаченные к таким контроллерам диски предполагалось использовать в качестве загрузочных устройств. Собственно, ситуацию можно считать нормализовавшейся только в последних ядрах ветки 2.6.X...

Во FreeBSD же 5-й ветки более или менее параллельно, на каком контроллере IDE-семейства сидит жесткий диск: благодаря CAM (Common Access Method) как-то работать с ним можно будет в любом случае, а если он еще и корректно опознан – то не будет препятствий и для загрузки с него. Да и в 4-й ветке – я ни разу не сталкивался с проблемами для «одновозрастных» контроллеров ATA RAID.

Другой пример – звуковые карты. Все те из них, что основаны на более-менее распространенных чипах, работали во FreeBSD без малейшего напряжения (рук или мысли). То же можно сказать и о «чипсетном» звуке. В Linux'е же аналогичные устройства часто требовали не вполне тривиальных манипуляций с ALSA-драйверами, благо ныне они встроены в ядро. Однако даже и в последнем случае без кое-каких настроечных действий не обойтись. Но это уже – предмет второй попытки объективизма.

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

Настройка

Устоявшее (и тщательно культивируемое) мнение, будто бы FreeBSD сложнее в установке и настройке, нежели Linux, я не могу объяснить ничем иным, как ходячим недоразумением. Потому что ничего общего с действительностью (в которой, как известно, все не так, как на самом деле) оно не имеет.

Начнем с установки. Инсталляция FreeBSD штатными средствами (с помощью утилиты sysinstall выполняется за полчаса, не требует непременного доступа к Сети (хотя таковой лишним не будет) и дает в итоге полностью работоспособную систему с кириллической консолью, функционирующим dial-up (или, по ситуации, включением в локалку), запускаемыми Иксами и необходимым для начала практической деятельности минимумом пакетов (из прекомпилированных бинарников). Все настройки – и общесистемные, и для прикладных пакетов, – разумны (пусть и не идеальны с точки зрения конкретного юзера).

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

Большинство известных мне инсталляторов из разных дистрибутивов Linux отличаются от Free'шного sysinstall в две противоположные стороны:

   • есть установщики более простые – хотя, ИМХО, это та самая простота, которая хуже... ну сами знаете чего;

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

Наравне с Free'шным sysinstall я поставил бы (из всех мне известных) только установщик из Archlinux. Написанный, как свидетельствует его разработчик, под влиянием первого, он обеспечивает почти такое сочетание простоты и гибкости.

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

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

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

Конечно, в user-ориентированных дистрибутивах Linux отечественного происхождения пользователь получает стопроцентно русифицированную консоль «из коробки». Однако – выполненную в соответствии с представлениями разработчиков. Каковые отнюдь не обязаны совпадать с представлениями (и, главное, потребностями) данного конкретного пользователя. И уж в этом случае на коррекцию ему придется затратить существенно больше сил, нежели при русификации с нуля какого-либо дистрибутива из числа Source Based. В подтверждение чему – вспомним многочисленные статьи, посвященные откату в Red Hat (и Fedore'ном Core) с «прогрессивной» кодировки UTF на KOI8, пусть «бомжовскую», но вполне устраивающую многих и многих...

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

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

Не случайна тенденция многих современных дистрибутивов Linux – использовать BSD-стиль загрузки, примерами чему, кроме классической Slackware, и CRUX, и Gentoo. А в Archlinux понятие runlevels вообще утрачивает значение – хотя соответствующие слова в файле /etc/inittab найти можно, на практике уровни выполнения при старте системы никак не играют. А вот попыток внедрить в BSD-системы «прогрессивный» стиль System V что-то не наблюдается – не считать же таковым группировку скриптов различных служб в едином подкаталоге в /etc во FreeBSD 5-й ветки.

Что же до русификации Иксов – X, как известно, он и в Африке X. И действия по вписыванию путей к файлам с кириллическими шрифтами, коррекция клавиатурной раскладки и установка переключателя с латиницы на кириллицу окажутся неизбежными, поверх какой операционки Иксы бы ни стояли.

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

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

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

Однако перекомпиляцией ядра дело не ограничивается. Нужно еще поставить соответствующий ALSA-инструментарий (да еще, как правило, средства совместимости ее со старой звуковой системой OSS), активизировать соответствующего демона и с помощью не вполне очевидных средств обеспечить его «самовосстановление». И после всего этого опять столкнуться с неожиданностями. Например, с нежеланием мирного сосуществования ALSA и arts (звуковой системы KDE). Конечно, мне могут возразить, что это – проблемы KDE, однако во FreeBSD их не возникает вовсе.

Кстати, о доустановке инструментария (и прочих программ – для этого ведь необходима

Система управления пакетами

Здесь до недавнего времени первенство безусловно принадлежало FreeBSD: система портов ее обеспечивала несравненное сочетание простоты и гибкости, всегда оставляя возможность выбора – собирать ли пакеты из исходников, или устанавливать их из бинарников. Не возбраняя и комбинацию этих методов. Из всего Linux'ового богачества по этой части с портами мог сравниться только Debian'овский apt, ассимилированный в недрах многих rpm-based дистрибутивов. Однако, хотя apt и предполагает возможность сборки собственных пакетов, основным методом при нем является использование прекомпилированных бинарников, собранных в соответствие с представлениями майнтайнера о зависимостях оных.

Ныне положение изменилось – и в Source Based дистрибутивах Linux широко используются портообразные системы, развившиеся под сильным влиянием своего FreeBSD-прототипа: портежи Gentoo, Sorcery из Sorcerer'а, порты CRUX, Archlinux Building System из одноименного дистрибутива. Они подчас превосходят своего прародителя по универсальности, гибкости, глобализации настроке или прозрачности устройства, использования и модернизации. К тому же за десятилетие своего развития порты FreeBSD стали весьма громоздким и труднообозримым сооружением, поддержание которого в актуальном состоянии представляет собой отдельную задачу. Далеко не всегда решаемую с помощью дополнительных средств типа portupgrade (которая сама по себе является уже частью не базовой системы, но системы портов).

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

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

Что меня всегда удивляло в портах FreeBSD – ситуация со сборкой моего любимого редактора joe. Каковой в качестве зависимости непременно требовал GNU make версии 3.80, хотя собственный make входит в состав FreeBSD Distributions – и собрать с его посредством joe руками – не составляет никаких проблем.

А вообще «чистота» установки пакета очень зависит от конкретной реализации порта. Давеча вот обнаружил я где-то в новостях сообщение о новом оконном менеджере под названием edo – небольшом, как говорилось, компактном и быстром. Обнаружился он и в портах FreeBSD, откуда я решил его собрать. В итоге этот маленький:-) WM потянул за собой (как зависимость зависимости) не что иное, как MySQL...

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

Каждый, кому доводилось собирать Linux from Scratch, знает, что некоторые версии пакетов Base Linux имеют обыкновение собираться только с определенными (отнюдь не обязательно – самыми свежими) версиями таких утилит, как autoconf и automake, категорически отказываясь делать это с другими их версиями (пусть даже более свежими и прогрессивными).

Разработчики Source Based дистрибутивов Linux подчас обходят эту сложность тем, что принудительно вносят в список зависимостей таких «склизких» пакетов autoconf и automake «прошлогоднего» розлива – при том, что сам по себе базовый комплект включает уже текущие на данный момент их версии. В результате чего, например, в Gentoo при выполнении бутстраппинга или emerge system можно с удивлением наблюдать, как система лезет в Интернет за бородатым, как Карл Маркс, autoconf – хотя свежая его версия только что была развернута из тарбалла stage1. А если вспомнить, что многие полагают, будто по настоящему стабильное ядро Linux может быть собрано только с gcc версии 2.9.X, результатом чего оказывается присутствие в системе двух компиляторов, – о какой «чистоте» сборки можно еще говорить?

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

   • FreeBSD, вопреки устоявшемуся мнению, существенно проще в настройке и локальном администрировании – даже без учета того факта, что она одна, а Linux'ов – много;

   • напротив, система портов FreeBSD в настоящее время (в отличие от недавнего прошлого), не имеет значимых преимуществ перед аналогичными инструментами из Source Based дистрибутивов Linux.

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

Пользовательские качества

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

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

Ибо такой пользователь большую часть времени проводит в Иксах, и ему абсолютно без разницы, поверх какой операционки эти самые Иксы крутятся. Ему только кажется, что он работает в Linux или FreeBSD (NetBSD, OpenBSD – рискну расширить я этот список). На самом же деле работает он в KDE (Gnome, XFce, WindowMaker – нужное дописать). И если бы ему не пришлось предварительно устанавливать и настраивать свою операционку, он имел бы шанс никогда не узнать, в какой именно из POSIX-совместимых систем он работает: перед ним будут одни и те же интерфейсные элементы, одни и те же средства настройки, одни и те же приложения.

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

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

Пользователь Linux для начала вынужден разбираться с тем, какой из двух пакетов управления консолью – kbd или console-tools – применяется в его дистрибутиве. Конечно, ныне они практически идентичны по своим возможностям, но каждый имеет свой набор команд с несколько различающимся синтаксисом. А кое-какие настройки (например, цвета текста и фона) требуют от него использования команд, не входящих ни в один из пакетов. А кое-что (например, те же цвета бордюров) все равно останутся для него недоступными.

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

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

Так что же – в консольном режиме первенство остается за FreeBSD. По моему мнению – безусловно. Но – только если речь идет именно о чисто текстовой консоли. Если же обратить свой взгляд на т.н. графическую консоль (реализуемую посредством Frame Buffer) – все видится несколько иначе.

Начать с того, что графическая консоль FreeBSD (т.н. Raster Mode) ограничена одним-единственным разрешением – 800x600 (тут речь идет именно о настоящем пиксельном разрешении, а не плотности символов). Да и то – на некоторых чипах этот режим не работает вообще, на других же – имеет вид вполне скверный. Собственно, нормального результата в Raster Mode мне не удавалось добиться ни на одной из имевшихся в моем распоряжении видеокарт.

В Linux же графическая консоль просто радует взгляд. Даже при поддержке Frame Buffer для абстрактных VESA-совместимых карт на всегда ней можно варьировать разрешения от 640x480 до 1280x1024, с изменением глубины цвета в стандартном диапазоне. Что обеспечивает не только комфортный просмотр изображений, но и весьма приличное (на мой взгляд – более чем приличное) воспроизведение видео. Для карт же, имеющих хорошо реализованные собственные драйвера в ядре Linux (Matrox, ATI, чипсетное видео от Intel) – к этому добавляется возможность установки нестандартных разрешений экрана.

Конечно, никто не использует консоль для работы с изображениями, и очень немногие – для просмотра видео. Почему же я придаю графической консоли такое значение? Да потому, что незаметно, на тоненьких пока ножках, но наступает эра жидкокристаллических дисплеев, знаменующая собой смерть чисто текстового режима (но не консольного режима как такового). Почему – легко поймут те, кто видел стандартный текстовый режим 80x25 символов на 18-дюймовом LCD-мониторе с физическим разрешением матрицы 1280x1024. А как это смотрелось бы на экране с соотношением сторон 16:9 – я боюсь себе даже представить...

Наконец, остается еще один вопрос, важный для пользователя -

О производительности

Представление о большем быстродействии FreeBSD по сравнению с Linux'ом – столь же традиционно, как и мнение о большей сложности ее настройки. Однако так ли все однозначно?

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

Во-вторых, даже если считать скорость загрузки одним из критериев быстродействия, – превосходство перед Linux'ом обнаруживает только FreeBSD 4-й ветки. Пятая ветка грузится ровно столько же, сколько и любой дистрибутив Linux, задействующий файловую систему устройств devfs. Конечно, в благородном Linux-семействе можно подобрать таких представителей, которые грузятся еще дольше – но это очень дружественные к юзеру системы, отягощенные... нет, не вином и едой, но изобилием стартовых сервисов (в частности, автоопределителем оборудования kudzu).

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

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

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

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

В Linux принята другая модель работы с ATA-дисками: разные типы контроллеров имеют (или не имеют) собственную поддержку в ядре. Что исключает использование явно не поддерживаемых устройств, зато для поддерживаемых, судя по всему, обеспечивает большее быстродействие. Файловые же системы (а Linux поддерживает в качестве нативных несколько их разновидностей) по умолчанию все (кроме, возможно, JFS) используются в полностью асинхронном режиме (async mode), когда и данные, и метаданные кэшируются в оперативной памяти.

В результате сочетания указанных факторов файловые операции осуществляются в Linux существенно быстрее, нежели во FreeBSD. Собственно, я всегда это подозревал, но только серия измерений показало, насколько отставание FreeBSD 5-й ветки в этом плане существенно – положение не спасает даже механизм SoftUpdates, призванный повысить и надежность, и производительность манипуляций над файлами. К слову сказать – во FreeBSD 4-й ветки такого отставания ранее не наблюдалось, что косвенно подтверждает негативное влияние работы с дисковой подсистемой (усугубляющее деградацию именно синхронных операций) – в ней модель CAM не используется (по крайней мере, не использовалась, когда я ею пользовался). А вот в Linux с его исключительно асинхронным использованием файловых систем, по моим наблюдениям, зависимости скорости работы с файлами от производительности дискового железа почти нет.

Второе из обещанных исключений относится к операциям своппинга. Каковые в Linux и FreeBSD выполняются существенно по разному. Для установления чего достаточно посмотреть на вывод команды top в той и другой ОС при среднепользовательской нагрузке. В Linux можно видеть, что при достаточном количестве оперативной памяти процент использования swap-пространства стремится к нулю. Например, на моем ноутбуке с Linux (512 Мбайт памяти) в момент сочинения этих строк, при загруженном KDE, html-редакторе Quanta, konsole, двух экземплярах konqueror и работающем mplayer (воспроизводство mpeg и RealAudio), swap не задействован вообще. На десктопе же с FreeBSD (1 Гбайт памяти) при той же нагрузке задействованная область подкачки меньше 10% почти не опускается.

Это связано с тем, что Linux прибегает к своппингу только при переполнении оперативной памяти, во FreeBSD же на диск в любом случае (даже при избытке RAM) выгружаются страницы памяти, к которым не было обращений в течении некоего промежутка времени. В сущности, оперативная память в этой ОС выступает в качестве своего рода кэша для области подкачки (точнее, для виртуальной памяти вообще). Что эффективно при ограниченном ее объеме и было оправдано в стародавние времена, когда процессоры были медленными, а памяти – мало. Ныне же такая модель использования своппинга в некоторых ситуациях приводит к замедлению работы. Пример – в KDE с большим количеством рабочих столов и периодическим переключением между ними, где такое замедление видно невооруженным глазом.

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

Подведем итоги

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

Чем подкупает FreeBSD – так это а) простотой установки, б) логичностью настройки и в) легкостью администрирования в локальном масштабе. Однако те же особенности (по крайней мере, большая их часть) характерны ныне и для лучших (по моему мнению) современных представителей Linux-семейства (CRUX и Archlinux, в какой-то степени – Gentoo). Хотя ожидать от них внутренней стройности и целостности FreeBSD, по понятным причинам, в ближайшее время не приходится.

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

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

Демон с пингвином – братья навек!

Заключение post factum

В результате развернувшегося обсуждения должен признать: заметка получилась у меня если и без гнева, но не совсем без пристрастия – ну люблю я FreeBSD, что поделать? Хотя и против Linux'а ничего не имею и даже им пользуюсь.

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

Относительно поддержки видеокарт – также согласен, упущение. Потому что в игры не играю и фирменные драйверы никогда не ставлю – для 2D достаточно штатной Иксовой поддержки. Да и про Linux Compatible во FreeBSD – каюсь, просто забыл.

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

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

А вообще, конечно, сравнение Linux с FreeBSD можно резюмировать очень тривиальным образом: лучше та система, которую лучше знаешь.

4 декабря 2008 г

Давным-давно написал я статью «Linux или FreeBSD? Без гнева и пристрастия». Много воды с тех пор утекло, немало сменилось ядер Linux'а и веток FreeBSD, менялись файловые системы, менялось «железо», мир десктопов заполнился 64-битными и многоядерными машинами. И настало время вернуться к этому вопросу на новом витке развития ОСестроения и аппаратных средств.

Вступление

Благо, для возвращения к вопросу подвернулся и повод: статья morbo «Сравнение FreeBSD и Linux (Debian)», сопровождавшаяся обсуждением как непосредственно в блоге, так и на форуме POSIX.ru. Впрочем, всё это послужило только катализатором для кристаллизации давно созревавшего замысла.

Конечно, сравнительные достоинства различных Unix-подобных систем, в том числе и Linux vs FreeBSD, обсуждались бессчётное количество раз — на уровне идеологическом и технологическом, эмоционально или с попытками бесстрастия. И ныне затрагивать эту тему на полном серьёзе невозможно. Так что и всё сказанное ниже чересчур уж серьёзно воспринимать не надо. Но и не след забывать, что в каждой шутке есть лишь её доля. Не понимающим этого — просьба воздержаться от дальнейшего чтения во избежание отрицательных эмоций.

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

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

   • пользовательский сегмент — под ним мы будем понимать не столько пользователей домашних медиа-центров, сколько людей, занятых решением своих производственных задач на одной отдельно взятой машине;

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

   • сегмент встраиваемых устройств — очертить его словами довольно трудно, но смысл, думаю, интуитивно понятен.

Разумеется, у каждого есть свои предпочтения, что из перечисленного считать мухами, что — котлетами, а что — гарниром. Это, во-первых. Во-вторых, и это — следствие первого, непреодолимой границы между выделенными сегментами нет: как было резонно отмечено в обсуждении на POSIX.ru, одно и то же устройство может выступать в любой из указанных ролей. А в-третьих, напротив, граница между мухами, котлетами и гарниром с течением времени становится всё более резкой. Что хорошо видно на примере эволюции мультимедии разного рода. Играя роль котлеты для их разработчиков, они, по мере превращения в привычный гарнир для своих пользователей, всё больше оказываются в амплуа мух для тех чудаков, кто по прежнему использует компьютер традиционным способом, то есть для работы.

Нечто аналогичное на наших глазах происходит со встраиваемыми устройствами, что демонстрирует в своём «Железном марше» Сергей Голубев. Типичный пример — сетевые накопители. Оснащенные винчестерами, подчас объединёнными в RAID-массивы, такого объема, которому ещё недавно позавидовал бы data-центр средней руки, они нынче, казалось бы, прочно переместились в пользовательский сегмент. Однако не будем спешить: уверен, что очень скоро эти агрегаты будут продаваться с «предустановленными» видео- и аудиозаписями, коллекциями изображений и подборками материалов «только для взрослых». После чего прочно окучат сектор бытовых устройств.

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

Теперь про области сравнения. Традиционно Linux и FreeBSD сравниваются с точки зрения:

   • поддержки аппаратных платформ;

   • поддержки дополнительного оборудования внутри одной архитектуры;

   • поддержки хранилищ данных, таких, как логические тома и файловые системы;

   • внутреннего устройства системы и средств поддержки её целостности;

   • средств управления дополнительным программным обеспечением;

   • наконец, производительности.

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

Поддержка аппаратных платформ

Итак, поддержка аппаратных платформ. Да, Linux поддерживает их существенно больше, нежели FreeBSD (хотя до уровня Net- и даже OpenBSD существенно не дотягивает).

Актуально ли это для сферы десктопного применения? Увы, отнюдь нет. На протяжении многих лет я не устаю вспоминать статью в журнале PC Mafazine, опубликованную лет пятнадцать назад под названием (по памяти) «Через 10 лет все платформы, кроме IBM PC, уйдут в небытие».

Ныне в пользовательском сегменте это можно считать свершившимся фактом: единственной настольной платформой сейчас является x86_64 (она же AMD64), чистый i386 скоро можно будет найти только у старьёвщиков и торговцев антиквариатом. Платформа PowerPC прекратила своё существование с переходом Macintosh'ей на Intel. Платформа Cell в универсально-настольной своей ипостаси, не смотря на возлагавшиеся на неё надежды, похоже, умерла ещё на стадии зачатия. О доле Sparc'ов, Alpha. Power и прочих Itanium'ов в настольных системах можно не говорить, верно?

Так что возникает вопрос: зачем нужна многоплатформенность на столе? Для поддержки старого железа? Старые Alpha или Sparc благополучно доживают свой век со своими родными старыми же операционками. Конечно, в истории известны случаи гальванизации старых Sun'овских станций путём установки Linux'а, вместо морально самортизированной предустановленной версии Solaris — пример такой процедуры описан в известной книге Владимира Водолазкого. Но проводился его эксперимент в уж больно специфической обстановке первой половины 90-х годов. А чем только не занимались в то время пролетарии умственного труда, вроде нас с вами...

Так может быть, версии Linux или FreeBSD для указанных выше аппаратных платформ могут рассматриваться как альтернатива родным ОС? С трудом верится, что те, кто затратил изрядные, даже по ненашим масштабам, деньги на приобретение соответствующих комплексов, будут сносить предустановленные, оплаченные, тщательно заточенные под «родное железо» системы, да ещё подчас со столь же предустановленными и оплаченными, специализированными приложениями, ради сомнительного удовольствия устанавливать на них свободную ОС и столь же свободные (но далеко не всегда столь же функциональные) приложения?

На моей памяти был случай... не скажу массового, но по крайней мере организованного применения Linux'а на платформе, отличной от i386 – на DEC'овских Alpha. Но об этом рассказ пойдёт в книжке Мир FOSS. Вопросы истории (готовится к размещению).

Итак, поддержка многочисленных платформ в настольном сегменте похвальна с точки зрения общих соображений, но не особенно востребована на практике. Более того, самое смешное, что она ударными темпами теряет актуальность и в сегменте серверном — с тех самых пор, как появились дешёвые многопроцессорные системы на Opteron'ах. Да, амортизация серверов происходит медленно, и дорогие сервера на не-Intel'овских платформах будут крутиться ещё очень долго. Однако, по аналогии с рабочими станциями, трудно представить себе, что в процессе промышленной эксплуатации их родные операционки будут заменяться на что бы то ни было свободное.

Вообще-то говоря, я могу понять мотивы портирования Linux на архитектуры, отличные от x86. Главный из них, как мне кажется, — просто наличие соответствующей техники у разработчиков и спортивный азарт при адаптации любимой ОС для прикручивания к оной. Опять-таки, мотив веский с точки зрения just for fun, но вряд ли способствующий «концентрации сил и средств на решающем направлении».

Сложнее понять растущую тягу к многоплатформенности среди разработчиков FreeBSD — системы, изначально ориентированной на самую демократичную платформу всех времён и народов. Единственное объяснение, которое я вижу — это отработка поддержки 64-битных архитектур вообще: обратим внимание, что таковыми были все поддерживаемые FreeBSD не-Intel'овские платформы, причём поддержка эта появилась ещё до широкого распространения x86_64.

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

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

Более того, перебрав 64-битные варианты нескольких дистрибутивов Linux, я обнаружил падение производительности в задачах, связанных с интенсивными дисковыми и файловыми операциями, что, в принципе, и следовало бы ожидать. Так что единственное, что реально даёт пользователю Linux'а поддержка 64-битной архитектуры — это возможность использования памяти более трёх с копейками гигабайт, если таковая имеется в наличии.

Впрочем, того же результата можно добиться и косметическими мерами — пересборкой ядра с поддержкой PAE. При этом сама по себе система остаётся не только полнофункциональной, но и 32-битной, то есть на ней можно использовать, например, фирменные драйвера для видеокарт от Nvidia или ATI/AMD, 64-битные версии которых или отстают во времени, или просто отсутствуют как класс.

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

Однако это более чем с лихвой окупается тем, что собственно 64-битный вариант FreeBSD функционирует более чем исправно, и на машинах с соответствующими процессорами (то есть AMD64, Intel Core 2 и более высокими) прирост производительности можно заметить даже при обычной работе, а не только на тестах. Замедление же файловых операций, вероятно, имеющее место при работе с файловой системой UFS2 (которая и сама по себе достаточно задумчива) компенсируется тем, что именно на мощных 64-битных машинах с большим количеством реальной и полностью адресуемой памяти во всём блеске начинает играть ZFS, родной поддержки которой в Linux'е в ближайшее время не предвидится.

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

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

Поддержка дополнительного оборудования

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

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

Для начала следует заметить, что сами по себе ОС Linux и FreeBSD поддерживают все карты, соответствующие стандарту VESA, то есть практически все, существующие ныне в природе. Причём собственными силами делают это как в текстовом режиме, так и графическом консольном, именуемом режимом frame buffer в Linux или pixel mode во FreeBSD.

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

Так что, когда речь заходит о поддержке видеосистемы, явным или не явным образом подразумевается её поддержка в оконной системе X (или, в просторечии, в Иксах). И тут надо сказать, что Иксы, практически единственной современной реализацией которых является Xorg, абсолютно одни и те же и в Linux'е, и во FreeBSD, и во всех прочих свободных Unix-подобных системах, вплоть до Solaris'а. И собственными, то есть свободными, видеодрайверами Иксов все существующие видеокарты, точнее, чипы, на которых они основаны (а их и осталось-то практически всего три ряда — от Intel, Nvidia и ATI/AMD) поддерживаются абсолютно одинаково. То есть — хорошо в отношении 2D графики и никак — в отношении графики трёхмерной.

Так что относительно различий в поддержке видеокарт в Linux'е и FreeBSD можно говорить только применительно к 3D-функциям, обеспечиваемым фирменными драйверами, и только для видеокарт от Nvidia и ATI/AMD. И тут — да, Linux обходит FreeBSD на несколько корпусов: под него существуют драйвера от обеих фирм в 32-битных вариантах, а от Nvidia — также и в 64-битном. Тогда как для FreeBSD имеются только 32-битные фирменные «дрова» Nvidia, да и то, по отзывам, качество их реализации оставляет желать лучшего.

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

Поддержка звуковых карт, как сама по себе, так и механизм её реализации во FreeBSD, давно уже стала притчей во языцех. Только давайте посмотрим, а есть ли предмет разговора? Ведь фактически весь ныне существующий их ассортимент сводится к паре-тройке встроенных аудиокодеков типа AC'97 и одной-двум текущим «крутым» моделям от Creative. Относительно вторых ничего сказать не могу, ибо со времен SB AWE128 не испытывал в них ни малейшей потребности. А вот со встроенными кодеками во FreeBSD всё обстоит более чем нормально. Причём ещё с тех времён, когда их настройка в Linux'е представляла собой не вполне тривиальную задачу, во FreeBSD она обеспечивалась одной-тремя строками в конфиге ядра или загрузчика.

Предвижу возражение, что в Linux'е с тех пор звуковая система развилась до невозможных пределов, а во Free всё осталось по прежнему. Да, но так ли уж это плохо? Ведь всем известно, что если солнце всходит на востоке, заходит на западе и так — каждый день, может быть, лучше ничего не менять в этом процессе?

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

Поддержка хранилищ данных

А вот поддержка средств хранения данных — вопрос для пользователя очень важный, если, конечно, его личные данные не сводятся к набору порнухи, скачанной из Интернета. И тут, казалось бы, мы видим явное лидерство Linux'а, ядро которого поддерживает массу файловых систем как нативных (а в ближайшее время число таковых обещает чуть не удвоиться), обеспечивает эффективные средства работы с программными RAID'ами и логическими томами (LVM). Чем до недавнего времени FreeBSD могла противопоставить только архаичную, не смотря на все усовершенствования, файловую систему UFS и несколько способов организации программных RAID-массивов, причём без возможности задействовать их простыми средствами.

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

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

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

Отступление: не могу не констатировать с удовольствием, что ныне с поддержкой ZFS в Linux с технической точки зрения всё нормально (проект ZFS on Linux). Не смотря на препоны и рогатки, чинимые статусом – по прежнему далёким от официального.

И вообще, специфика разработки Linux'а в отношении файловых систем выливается в то, что энтузиасты, желающие (и могущие) этим заниматься, с большим удовольствием создают собственные велосипеды, типа BTRFS или TuxFS, нежели доводят до ума велосипеды существующие, чему примером служит печальная судьба AdvFS. Само по себе это не хорошо и не плохо — это медицинский факт. Однако именно в области файловых систем он играет роль не самую положительную...

Внутреннее устройство системы и обеспечение её целостности

Это, пожалуй, самое кардинальное различие между Linux'ом и FreeBSD. Linux — это конкреция, более или менее произвольно (по произволу майнтайнеров дистрибутивов) разрастающаяся вокруг центра кристаллизации, то есть ядра системы за счет агломерата внешних утилит и приложений, без которых она не то что использоваться, но даже и загрузиться простым способом не может. FreeBSD — монолитный кристалл, теоретически самостоятельный и самодостаточный.

Конечно, и то, и другое — в идеале. На практике и в любом дистрибутиве Linux можно выделить базовый комплекс, состоящий из примерно одного набора системных и пользовательских утилит, необходимых для старта системы и её минимальной функциональности. А FreeBSD Distributions, напротив, включает в базовый набор, с одной стороны, компоненты, вовсе не являющиеся жизненно необходимыми (типичный и наиболее часто поминаемый пример — sendmail). С другой стороны, base FreeBSD нельзя считать и полностью самодостаточным — трудно представить себе её, например, без Perl'а...

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

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

Средства пакетного менеджмента

Это — вопрос в большей степени религиозный, нежели технологический. Пользователи FreeBSD гордятся (и вполне заслуженно) системой ports&packages, обеспечивающей, с одной стороны, быстроту установки приложений из бинарных пакетов, с другой — гибкость сборки их из портов.

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

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

Приведу простой пример из собственной недавней практики. В ходе обсуждения данной темы на POSIX.ru неожиданно был затронут вопрос о формате rpm и его истории, позднее выделенный в отдельное производство. С rpm based системами я не имел дела много лет, и потому решил во FreeBSD поставить rpm из порта — дабы хотя бы почитать, что о нём говорит тётя Маня.

Сказано — сделано: перехожу в каталог /usr/ports/archivers/rpm4/ и, не мудрствуя лукаво, набираю

# make install clean

после чего продолжаю заниматься своими делами. Через некоторое время решил поглядеть, что там у меня делается с установкой — и с удивлением обнаружил, что она всё ещё продолжается: скачиваются и собираются в качестве зависимостей TeX, Qt и ещё что-то...

Разумеется, такую ситуацию можно было бы предотвратить внимательным изучением Make-файла или списка зависимостей, например, на Freshports. Сказанным же хочу только подчеркнуть, что системы портов, как и пакетный менеджмент в стиле apt, сами по себе гарантии от неё не дают, наиболее эффективно работая в том случае, когда пользователь знает, что делает. А вот отсутствие в Slackware развитых средств управления пакетами просто заставляет относиться к их установке вдумчиво.

О сравнении производительности

Это ещё более сакральный вопрос. И ответить на него можно только в том случае, если ясно определиться, производительность чего именно сравнивается. В двух словах же я сказал бы так: на современных машинах, выполняющих набор обычных пользовательских приложений в окружении распространённых ныне графических сред, разница в производительности между Linux'ом и FreeBSD не фиксируется. Точка. Исключение — массовые файловые операции. Если до недавнего времени FreeBSD, за счёт особенностей работы с PATA-контроллерами и задумчивости своей файловой системы, однозначно (и местами весьма значительно) проигрывала Linux'у, то ныне распространение SATA-винтов выровняло ситуацию, а портирование ZFS сместило чашу весов в её пользу.

Разумеется, только на мощных машинах. Как-то, эксперимента ради, я поставил FreeBSD с ZFS на ноутбук с Sempron'ом (одним из первых), медленным, даже по ноутбучным меркам, винчестером и 512 Мбайт памяти. Зрелище было душераздирающее. Так что, пожалуй, для реанимации относительно старого «железа» лучше подойдёт какой-либо из «легких» дистрибутивов Linux. Хотя для «железа суперстарого», в силу особенностей обращения с памятью, FreeBSD опять окажется предпочтительной — правда, также в одной из старых своих ипостасей, например, 4-й ветки.

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

Апрель, 2012

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

Вступление

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

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

Завязкой сюжета послужила информация об отчёте Linux Foundation, посвящённая вопросу вклада в ядро Linux, сделанному различными фирмами, организациями и лицами в 2011 году. На русском языке она прозвучала, например, на OpenNet'е. Одновременно её интерпретацию озвучил Пётр Леменков в заметке «Кто разрабатывал ядро Linux в 2011 году?»

Пересказывать содержание отчёта и тем более его возможных (и/или сделанных) интерпретаций не буду. Чисто фактографически же это выглядит так: наибольший вклад в разработку ядра Linux (далее – LK), если не считать собирательного образа в лице Большого Бухарца Сообщества, внесли сотрудники Red Hat (которые по совместительству являются и основными разработчиками дистрибутива Fedora). Это – по количеству внесённых (и принятых) патчей. По числу же патчеодобрятелей Red Hat оставил позади даже всё сообщество, вместе взятое.

Отдельной строкой был отмечен вклад компании Microsoft, занявшей 17-е место по числу патчей. Правда, все они касаются только поддержки Linux как гостевой ОС в их собственной системе виртуализации Hyper-V. Да и объём кода невелик. Однако он разбивается на много патчей, что позволило компании войти в двадцатку сильнейших.

В сети же по следам этого отчёта «отдельно, с большим наслажденьем» комментировался вклад фирмы Canonical в развитие LK. Точнее, видимая незначительность этого вклада: в отличие от Microsoft, Canonical по числу не сподобилась причислению к «великолепной двадцатке». Дело дошло до обвинений в том, что в Ubuntu вообще не сочиняют код, а только передвигают кнопки справа налево и перекрашивают обои. Впрочем, такие мелкие «дружеские» подначки в адрес Ubuntu и Canonical последнее время стали любимым развлечением пользователей некоторых более иных дистрибутивов.

Разумеется, «ответ Чемберлену» ждать себя не замедлил. Марк Шаттлворт выступил с объяснениями, почему основанная им компания не участвует в разработке ядра. И ответ его можно свести к двум «апрельским» тезисам:

   1. для Canonical приоритетным является развитие Ubuntu как цельной системы, направленной на благо пользователя, кем бы он ни был (домохозяйкой или админом огромной сети);

   2. развитием LK и без неё занимается много сильных компаний и команд, так что Canonical вмешивается в это дело лишь постольку, поскольку оно требуется для развития собственного бузинеса.

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

Важно заметить, что все эти обсуждения протекают на фоне других разговоров, касающихся новшеств, продвигаемых в дистрибутиве Fedora, что косвенно затрагивает также и Red Hat (то есть RHEL). И если острота дискуссий по поводу GNOME 3 или pulseaudio отошла в прошлое, то страсти вокруг systemd прямо так и кипят. Усугубляясь смежными темами, как то: слиянием проектов systend и udev, введением новой системы записи log'ов или предложением переноса в сферу компетенции systemd части функций интегрированных сред (KDE, GNOME, XFce).

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

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

Ретроспектива

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

Как известно, дистрибутив Red Hat не был первым дистрибутивом Linux. А одноимённая компания не была первой на поприще бизнеса FOSS related – похоже, что здесь первенство за S.u.S.E., двадцатилетие развития которой мы скоро будем праздновать. Не исключено, что были и другие фирмы, пытавшиеся заработать на распространении и поддержке дистрибутивов Linux и свободного софта вообще – но до наших дней они не дожили, и память о них затёрлась.

Но фирма Red Hat безусловно была

   • первой FOSS-компанией на Американском континенте (повторяю, за исключением вымерших гипотетических участников), и

   • первой успешной компанией, подвизавшейся на ниве свободного софта.

И, к слову сказать, пока она оказывается и последней: ни одной компании, основывающей свой бизнес на распространении и поддержке свободного софтае повторить успех Red Hat до сих пор не удалось. Даже упомянутой выше S.u.S.E., имевшей, казалось бы, фору почти в два года.

Почему? Рискну предположить, что одной из причин было как раз американское происхождение компании. И, как следствие, потенциальная возможность выхода на существенно более широкий рыночный простор, чем могла открыть перед S.u.S.E. Германия или даже вся Европа.

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

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

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

Первенство Red Hat не поколебало ни возникновение столь же корпоративного Caldera Linux, ни создание первого «юзерофильного» дистрибутива – Mandrake (и продолжателей тенденции – StormLinux и Corel Linux), ни поднявшаяся в начале нулевых годов волна интереса к дистрибутивам Source Based (Rock Linux, Gentoo, первоначально CRUX и Archlinux), ни появившиеся тогда же системы быстрого равёртывания, ориентированные, как и Mandriva, на конечного пользователя (Vector Linux, Mepis). S.u.S.E., она же SUSE и Suse, уверенно удерживала второе место в тройке корпоративных участников, но с очень большим отрывом.

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

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

В Red Hat же десктопное направление было выделено в отдельное производство – в развиваемый сообществом, при поддержке фирмы, дистрибутив Fedora. Каковой первоначально рассматривался в основном как испытательный стенд для апробации всяких новшеств, которые потом включались (или не включались) в коммерческую линию дистрибутивов RHEL.

Это с одной стороны. С другой же, Fedora выступала в роли Red Hat для бедных – пользователей-индивидуалов, не желающих оплачивать техническую поддержку RHEL или в ней не нуждающихся. Но желающих, тем не менее, приобщиться к величию «редхатианской мысли».

С ролью RHEL'овского полигона Fedora справлялась вполне успешно – и неудивительно, ведь многие её основные разработчики по совместительству были и сотрудниками Red Hat. И они имели здесь возможность порезвиться, не будучи скованными узами «партийной дисциплины». Именно отсюда и берёт начало традиция, развивающаяся по сей день: изрядная часть новшеств в LK берёт своё начало из проекта Fedora. На втором же месте неизменно держится Suse, принявшая, после попадания в объятия Novell, ту же модель разработки – расщепление на коммерческую ветку SLE и свободную openSUSE.

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

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

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

   • сотрудники Red Hat и Novell развивают свои коммерческие продукты, а в свободное от этого время экспериментируют в своих песочницах, при участии сложившихся вокруг них сообществ волонтёров;

   • пользователи Slackware продолжают изучать материальную часть, в силу этого время от времени поставляя кадры пользователей существующих дистрибутивов, а то и разработчиков новых (таких, как Zenwalk);

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

   • Mandriva балансирует между банкротством и получением немыслимых правительственных контрактов (или всё-таки субсидий?);

   • пользователи Gentoo, набравшись опыта, задумываются, а куда бы им переползти, но пока стойко продолжают перекомпилировать систему по будням, отдыхая по праздникам;

   • разнообразные нишевые дистрибутивы и дистрибутивы второго эшелона... да кто же уследит, что происходит в их мирках; разве что некоторым, как Archlinux, удаётся попасть в запас эшелона первого.

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

Появление второго протагониста

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

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

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

Кстати, впервые выражение «Linux с человеческим лицом» я услышал (точнее, прочитал) применительно к Corel Linux, типичному представителю юзерофильных дистрибутивов первой волны. И, столь же кстати, бывшего в этой волне первым «барашком» – если оставить за чертой Mandrake, который был всё-таки дистрибутивом всамделишним, и под именем Mandriva остаётся им до сих пор. Так вот, Corel Linux, возникнув в недрах одноимённой фирмы (да-да, той самой, которая Corel Draw – она тоже оскоромилась на ниве Linux'а, но это совсем другая история) в 1999 году и удостоенный кучи хвалебных отзывов в околокомпьютерных СМИ, в том числе того самого, про лицо (что невольно вызывало вопрос: если это его лицо, то какова же его, да простят меня читающие это дамы, жопа)...

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

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

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

И в первой версии (04.10) так оно и было. Что опять-таки не способствовало оптимистической оценке Ubuntu. Так что я выкинул его из головы.

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

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

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

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

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

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

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

Не менее, чем количество, показателен состав пользователей Ubuntu в сравнении с более иными дистрибутивами. Для начала, в многочисленных опросах о первом дистрибутиве Linux на протяжении первой половины нулевых годов неизменно, и с большим отрывом, одерживала победу Mandrake, она же в замужестве Mandriva. Но те же опросы о текущем дистрибутиве показывали, что после успешного старта с Mandriva изрядное число пользователей перетекало на другие системы.

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

В то же время немало оказалось и действующих пользователей Ubuntu, для которых этот дистрибутив был не первым, и не вторым, тех, кто прошли и ручную настройку Slackware, и тотальную компиляцию Gentoo, и роман «Ядро и мир» от FreeBSD, а возможно, и сборку LFS. И чьё сердце успокоилось в казённом доме тихой и уютной Ubuntu.

В своё время Марк в интервью журналу Linuxformant (тогда ещё английской версии), сказал о двух категориях потенциальных пользователей Ubuntu. Первая:

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

И вторая категория, в которую

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

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

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

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

Буквально за пару лет Марку Шаттлворту, фирме Canonical, примкнувшим к ним независимым разработчикам и, не в последнюю очередь, активным пользователям – создателям сайтов и авторам блогов убунтийской тематики, удалось превратить, казалось бы, рядовую «человеко-мордастую» поделку в самый популярный и распространённый дистрибутив планеты.

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

Последствия

Предыдущую заметку я закончил на том, что Ubuntu понадобилось всего года два для того, чтобы добиться если не доминирования среди Linux-десктопов, то явного преобладания. То есть той популярности среди узкого круга широких народных масс, к которой на протяжении полутора десятков лет стремились и Red Hat в свою ещё и десктопную пору, и Debian во время своих самых широких имперских притязаний, и Mandrake с Mandriva при всей своей перманентной юзерофильности.

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

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

Напомню, что первоначально в качестве объектов бесплатной рассылки выступали собственно Ubuntu и её «образовательный» вариант – Eduduntu, обе – с GNOME в качестве рабочего окружения. Kubuntu с KDE включилась в этот процесс существенно позднее, и участвовала в нём не очень долго.

В сочетании с шоковым действием, оказанным на старых KDE'шников первыми версиями 4-й ветки этой среды, это привело к тому, что GNOME по популярности с ней почти сравнялся.

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

А вот второе следствие было более общим: лавинообразный рост источников информации о Linux'е. Ибо к середине нулевых годов писательский пыл линуксоидов первого призыва подыссяк. И причины того понятны. Ибо проблемы, которые волновали поколения пользователей, начинавших свой путь в Linux ещё в прошлом тысячелетии, и бывшие поводом для сочинения всякого рода FAQ'ов, How-to'ёв, Tips'ов и Hint'ов, ушли в прошлое.

К моменту массового распротсранения Ubuntu ни в одном из «больших» дистрибутивов уже почти не требовалось ни ручной правки Иксовых конфигов, ни построения программых RAID'ов и систем LVM «с нуля», ни прикручивания файловых систем, отличных от умолчальной ext2, ни, в наших условиях, кириллизации. Все эти вопросы решались «искаропки», требуя в худшем случае небольшой косметической доводки. И в результате из прежних линуксописателей на вахте остались только те, для кого, как для автора этих строк, это занятие стало чем-то вроде профессии.

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

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

– Вот вы тут сидите и не знаете, а пиписька-то х...м называется!

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

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

Ещё одно частное, но очень важное для конечного пользователя следствие распространения Ubuntu – появление в Иксах качественных шрифтов. Точнее, не столько даже самих шрифтов, сколько механизмов их экранного воспроизведения. Если раньше

   • для практической работы широко применялись пиксельные шрифты,

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

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

то в Ubuntu качественный рендеринг шрифтов обеспечивался из всё той же тумбочки коробки.

И ещё очень важный момент: Ubuntu, развивая традиции систем быстрого развёртывания, начинавшейся со сгинувшего StormLinux и продолженная в таких дистрибутивах, как Vector Linux, MEPIS, Zenwalk, довела до логического завершения безальтернативную «установку в пять кликов», милую сердцу начинающего пользователя. И в то же время сохранила идущую от Debian'а альтернативную текстовую инсталляцию, допускающую широкое ручное вмешательство со стороны пользователя, знающего, что он делает.

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

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

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

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

Ещё немного ретроспективы

Итак, прошлая заметка заканчивалась тем, что Ubuntu явочным порядком (и самим фактом своего существования) изменяла мир Linux'а: если раньше пользователь в основном приспосабливался к этому миру, то ныне мир стал приспосабливаться к нему. А что поделывали в это время Fedora и стоящий за ней Red Hat?

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

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

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

Так продолжалось до того момента, пока в Ubuntu не замахнулись на святое – на серверы. Не то чтобы Ubuntu Server вдруг в одночасье стал прямым конкурентом для серверов на RHEL. Более того, отношение к Ubuntu в амплуа сервера было ещё более скептическим, чем поначалу – к Ubuntu в роли пользовательского десктопа. По крайней мере, на Linux-ресурсах было хорошим тоном иронизировать по этому поводу. Кстати сказать, это положение не изменилось и по сей день.

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

Всё началось с того, что была выкована супер-мега-ОСь выпущена Windows 95. К которой, как и к Ubuntu, поначалу никто не относился серьёзно: она воспринималась как платформа для запуска игрушек. Даже для всамделишней офисной работы резонные люди консервативного склада отдавали предпочтение старой, не очень доброй, но досконально известной Windows 3.1/WfW 3.11. Прогрессисты же склонялись к OS/2 3 Warp, затем 4 Merlin. Что же до серверов на Windows 95 – такое могло привидеться в кошмарном сне с большого перепоя.

Нет, у Microsoft была в загашнике и самая настоящая ОСь – Windows NT, от которой по прямой линии происходят все варианты всех современных Windows. Но как серверная платформа и даже платформа для рабочих станций она и близко не могла конкурировать не только с UNIX-машинами – в те времена ещё и несоизмеримыми по мощности с любыми компьютерами на x86, но даже с рассчитанной на последние OS/2. А на десктопах применение NT тормозилось интерфейсом, унаследованным от Windows 3.1, который в считанные месяцы после выхода 95-ой стал казаться старомодным.

Однако именно тогда, на исходе 1995 года, в одной из колонок Георгия Кузнецова (в то время – главного редактора «Компьютерры») проскользнула пророческая фраза (воспроизвожу по памяти):

Пользователи притащат Windows 95 на службу, и нам, профессионалам, придётся с ней разбираться).

Так оно и случилось, хотя и не сразу. Но постепенно Windows 95 утвердилась на рабочих местах различных контор. Я хорошо помню, как у нас на службе она постепенно вытесняла не только старушку три-первую, но и недавно установленного «Кривого Мерлина».

А затем... затем Microsoft в очередной раз всех напарила, выпустив Windows NT 4 с интерфейсом в стиле modern, то есть a la Windows 95. И именно с неё началось распространение NT-серверов и рабочих станций.

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

Потому что веб-мастер может управлять своим сайтом с помощью привычного интерфейса.

Судя по тому, что означенная услуга пользовалась спросом, аргумент действовал.

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

Видимо, вспомнили эту историю и в Red Hat – ведь Ubuntu тоже начала свой путь с оккупации пользовательских десктопов. В том числе десктопов школьников и студентов. А поскольку, как я уже говорил, пользователи Ubuntu, в отличие от Mandriva, уже показали завидное постоянство своих привязанностей, резонно было ожидать, что со временем эти самые школьники и студенты принесут её и на рабочие места. Так что пора было принимать меры по десктопизации если не RHEL, то Fedora. Какие? Скоро увидим.

Федорины меры

Я пропустил момент, когда начали приниматся меры по десктопизации Fedora. Да, скорее всего, его и уловить было невозможно, поскольку поначалу проводились они за кулисами. Так что остаётся только попытаться реконструировать события.

Рискну предположить, что за этими самыми кулисами процесс пошёл примерно во время выхода 7-го релиза в мае 2007 года, когда Fedora утратила Core'мычное дополнение к своему имени. Поскольку частица Core некоторым образом ассоциируется с ядром (или, скорее, сердцевиной), она символизировала тот факт, что разработчики дистрибутива заняты серьёзными делами, типа усовершенствования ядра и системных сервисов, а не мелкими поделками из разряда десктопных приблуд.

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

Как бы то ни было, когда я плотно засел на Fedora, а было это летом 2009 года, вскоре после выхода релиза 11, десктопизация этого дистрибутива шла полным ходом. И мне выпала возможность наблюдать её на протяжении четырёх релиз-циклов – вплоть до 14-го релиза включительно. Почему не далее? Этот вопрос имеет прямое отношение к теме настоящих заметок, и со временем я вернусь к нему.

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

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

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

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

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

Впрочем, в отношении последнего пункта очень велика была роль проекта Russian Fedora, возникшего осенью 2008 года, и с тех пор выпускавшего собственные сборки дистрибутива (RFRemix) одновременно с выходом оригинального релиза. Именно в нём и были реализованы впервые столь важные для пользователя мелочи. К коим следует добавить и сборку библиотек шрифтовой поддержки с опциями интерпретации байткодов (что по истечении срока действия соответствующего патента попало и в оригинальную Fedora) и субпиксельного рендеринга.

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

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

В общем, пресловутая «готовность к десктопу», о которой последнее время говорят не меньше, чем о «человеческом лице» Linux'а – в недалёком прошлом, возрастала и в оригинальной Fedora, и, особенно, в RFRemix от версии к версии. И достигла своего апогея в релизе 14 (ноябрь 2010 года).

Предшествующие версии RFRemix (по крайней мере с 11 по 13, которые я, что называется, «щупал рукаами»), можно было рекомендовать начинающим пользователям – но с рядом оговорок. Впрочем, число их от релиза к релизу всё сокращалось. И 14-й релиз я взял на себя смелость рекомендовать уже безусловно и всем пользователям, вне зависимости от задач и начальной подготовки. В общем, как сказал мой коллега Сергей Голубев в одном из своих обзоров:

... еще один Linux пошел в народные массы.

Увы, сказал он это задним числом – потому что с выходом 15-го релиза, имевшим место быть в марте 2011, выяснилось, что предпосылки к обретению статуса образцового дистрибутива оказались похеренными.

Как это случилось – будет рассказано в следующей заметке. А на вопрос почему? я постараюсь дать предположительный ответ несколько позже.

Fedora 15: переломный релиз

Так что же трагического для десктопных пользователей случилось с выходом 15-го релиза Fedora? Такого, что дало основание сказать Сергею Голубеву (в упомянутом ранее обзоре), что

... все рухнуло в одночасье.

Давайте посмотрим, попытавшись заодно оценить меру «рушения».

Собственно, тревожные симптомы можно было уловить ещё до выхода релиза – по сообщениям в новостях, а затем и по тестовым версиям.

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

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

А вот вторая ласточка была куды жирней, и для десктопного пользователя тянула уже на приличную курицу. Это было внедрение в качестве рабочей среды по умолчанию пресловутого (или знаменитого) GNOME 3 с его GNOMEShell'ом. О его весьма спорных достоинствах и бесспорных недостатках уже написано без счёта постов на форумах и в блогах. Немало говорено и о том, как превратить его в почти нормальный GNOME 2 – кажется, 90% всех форумных постов, так или иначе касавшихся Fedora 15 и GNOME 3, были посвящены этому вопросу.

Так что просто «кратко резюмирую вчерашний уж базар», не вдаваясь, повторяю, в материи, столь любимые некогда Великим Советским Поэтом:

GNOME 3 – откровенно нишевое решение, ориентированное на устройства, управляемые пальцами и яйцами стилами. Которое столь же откровенно (и весьма агрессивно) продвигается как решение универсально-десктопное.

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

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

Во-первых, со стороны лиц, связанных с проектом Fedora и Russian Fedora. Ну им как бы по долгу службы положено, это я понимаю. Хотя от главного сборщика RFRemix, Аркадия Шейна aka Tigro, дифирамбов в адрес «третьегнома» я тоже не слышал.

Ну а во-вторых, радетелями за GNOME 3 в основном выступают пользователи, для которых Linux-машина является не рабочим инструментом, а объектом развлекательного плана. Это типа такое этнографическое наблюдение.

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

– Мама, я не люблю дедушку... – Не нравится – не ещь!

А конкретней – это предложения:

   • оставаться на GNOME 2;

   • использовать GNOME 3 в режиме «второгномоподобия»;

   • применять более иные рабочие среды.

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

Но на самом деле всё оказывается не так просто. «Второгном» с выходом «третьегнома» можно смело зачислять в разряд того, что в биологии называют «живыми окаменелостями», вроде рыбы латимерии. Конечно, сам по себе он будет каким-то образом поддерживаться – хотя бы потому, что корпоративные клиенты Red Hat будут использовать его ещё многие годы. Будут существовать и форки – но опыт Trinity уже показал, что этот путь большого энтузиазма в массах не вызывает. Что же до режима «второгномподобия» – то его откровенная ущербность, вроде бы, сомнений ни у кого не вызвала.

А вот с более иными рабочими средами интересней. Казалось, бы – да, не тюрьма народов, «средь мира дольного для сердца вольного» есть и KDE, и XFce, и LXDE. Но это очередной случай того, что в реальности тоже не совсем так, как на самом деле. GNOME 2 в исполнении Fedora был привлекателен для начинающих пользователей и терпим для старых его нелюбителей (типа автора этих строк) своей доведённостью и интегрированностью с системными службами этого дистрибутива. А вот последнего заведомо и близко не лежало у LXDE, с этим были заметные напряги у XFce... ну разве что KDE более или менее, судя по отзывам, в этом отношении допилили.

И в итоге получается, что у Fedora, начиная с 15-го релиза, из колоды, на глазах весьма значительной категории пользователей, выпал весьма сильный козырь. А туз в прикупе, то есть GNOME 3, при ближайшем рассмотрении оказался даже не третьей дамой, а четвёртым валетом, играющим только при единственном раскладе у вистующих.

Что же, дядя Лёша, спросите вы меня, ты что, дяденек из Red Hat'а совсем уж за лохов держишь, которые ферзя от туза не отличают? Отнюдь – отвечу я вам. Дяди эти фишку просекают чётко, и мы скоро в этом убедимся. Но сначала нам надо рассмотреть ещё одно агрессивно продвигаемое новшество Fedora – не менее пресловутую, чем «третьегном»: systemd и связанные с ней материи.

Предстрастие к systemd

«Гномомстрасти», описанные в прошлой заметке, в основном уже отгорели. Хотя и поныне чуть ли не каждую неделю на Distrowatch'е можно видеть дистрибутивы (как правило, клоны Debian'а или Ubuntu) с GNOME 2 или вариациями на его темы в качестве десктопа по умолчанию. А вот страсти по очередной новинке, впервые увидевшей свет в составе Fedora, systemd, только разгораются. И причину их опять надо поискать в истории.

Как известно, исторически сложилось так, что Linux ассимилировал систему инциализации в стиле SysV, с главным процессом init и уровнями запуска (Runlevel) – наборами сценариев на разные случаи жизни. Замечу тут в скобках, что BSD-подобный стиль инициализации некоторых дистрибутивов Linux (Slackware, Gentoo, Arch, CRUX) – своего рода эвфемизм: от присутствия главного сценария инциализации и его конфига уровни запуска в них (свойственные Linux и отсутствующие в BSD-системах) никуда не исчезают.

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

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

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

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

Коллеги, мы же профессионалы. Давайте просто расстегнём штаны и померяем.

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

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

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

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

Сужу по своему опыту. Через мои руки прошло два SSD Corsair с интерфейсами SATA II и SATA III, и выполненный в виде платы PCI-E OCZ Revo Drive. Все дистрибутивы, которые у меня были в то же время (Fedora, PCLinuxOS, openSUSE) грузились с любого из них примерно за 20 секунд – из них всё мало-мальски уловимое время уходило на поиск DNS-сервера и синхронизацию по NTP, а собственно процесс инициализации, вне зависимости от схемы её (классический init, upstart или systemd, о которых скоро зайдёт речь) занимал какие-то мгновения.

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

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

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

Не случайно, когда несколько лет назад проблема ускорения загрузки вдруг стала актуальной (или показалось, что стала таковой), практически одновременно было разработано несколько «параллельных» альтернатив классическому init'у: runit, daemontools, initng. Была даже попытка портировать на Linux систему инициализации MacOS X – launchd. Правда, некоторую известность из них приобрёл, пожалуй, только initng. Однако и он, насколько я знаю, не прижился даже в родном дистрибутиве – в Gentoo.

Не смотря на различие в деталях, все эти системы инициализации сохраняли init'оподобие, то есть объединяли в себе традиционные shell-скрипты и простые текстовые конфиги, от которых они получали свои параметры. И если в скрипты лазать ручонками шаловливыми, без чёткого понимания смысла своих действий, весьма не рекомендовалось, то поменять значение-другое параметра в конфигах было вполне по силам почти любому функционально грамотному пользователю.

Примерно в том же ключе init'оподобия была оформлена и система upstart. Она разрабатывалась в рамках проекта Ubuntu на достаточно ранних стадиях его жизни (upstart 0.1.0 – сентябрь 2006 года). И сначала за пределами родного дистрибутива не использовалась. Однако весной 2008 года система upstart, как прогрессивная, была включена... куда? Разумеется, в самый фронтирный дистрибутив своего времени, в Fedora 9-го релиза.

Казалось бы, поддержка со стороны двух самых «крутых» носителей прогресса в Linux-мире предвещает триумфальное по нему шествие советской власти этой системе. Но:

И, как мы скоро увидим, человек такой нашёлся.

Страсти по systemd

Итак, фронтирнейший дистрибутив Fedora включает в себя вполне такую фронтирную систему инициализации upstart, что вроде бы обрекает последнюю на светлое будущее во всех дистрибутивах. И действительно, в виде опции она появляется в тестовой ветке консервативнейшего Debian'а, поговаривают о включении её в openSUSE (и вроде бы она промелькнула в какой-то из тестовых версий 10-го релиза).

Но что это за фронтирный дистрибутив, который довольствуется новшествами, написанными в дистрибутиве ином? Непорядок, который срочно должен быть исправлен. И весной 2010 года Леннарт Поттеринг, сотрудник Red Hat, ранее прославленный созданием аудиосервера PulseAudio, выступает с новой прогрессивной инициативой – системой инициализации по имени systemd.

Сначала она имеет статус прототипа, к лету того же года обретает права 1-го релиза, а уже весной 2011 года оказывается в составе Fedora 15 – одновременно с GNOME 3, о котором говорилось ранее.

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

И второе – большинство сервисов штатно запускается не shell-скриптами, а скомпилированными Си-программами. Хотя пока, в целях совместимости, не возбраняется и запуск сценариев, в том числе и самописных.

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

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

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

Я не поленился, и провёл эксперимент. Благо, дистрибутив openSUSE, вслед за Fedora внедривший новую прогрессивную инициализацию, сохранил (в релизе 12.1 и в тестируемой версии будущего релиза 12.2) возможность лёгкого, безболезненного и обратимого отката с умолчального Systemd на SysVinit. Так вот, на ноутбуке с медленным HDD (5400 об./мин.) скорость загрузки при возврате sysvinit не только не увеличилась, но даже уменьшилась на 9 (девять!) секунд (46 против 55 секунд, соответственно). Иными словами, systemd проиграл старику-традиционалисту вчистую (подробнее об этом – в следующем «сравнении мужей»).

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

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

А вот как раз с этим-то и может возникнуть напряжонка. Конечно, пока ещё при инциализации в стиле systemd использование стартовых сценариев допускается. Но надолго ли хватит такого либерализма? В одном из своих сетевых заявлений Поттеринг обещал подготовить полностью shell-loss систему – и, возможно, уже выполнил это обещание.

У сторонников systemd есть два, как им представляется, неубиенных аргумента в её защиту (кроме, разумеется, утверждения, что это система новая и потому уже хорошая по определению):

   1. докажи мне, что systemd плох (более мягкий вариант – покажи, в чём именно он плох);

   2. сначала изучи systemd как следует, а потом говори о его недостатках.

Первый аргумент демонстрирует некоторую напряжёнку с логикой у его авторов. Не могу отказать себе в удовольствии процитировать высказывание Goodvin'а в одном из обсуждений на Юниксфоруме:

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

И далее вполне к месту упоминается знаменитый чайник Рассела.

В данном случае бременем доказательства сторонники systemd себя не отягощают – более того, на все возражения типа того, что никакого профита пользователю он не даёт, следует повторение того же тезиса: докажи, что это плохо.

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

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

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

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

Некогда я затратил немало времени на ковыряние с файловой системой устройств в Linux (devfs) и HAL'ом в нём же. Последний, кстати, даже прикручивал, и вполне успешно, к FreeBSD. О потраченном времени не жалею – но возникает вопрос: и где теперь эти devfs и HAL? Брошены и погребены в одной могиле. И рядом с ней, возможно, заготовлено место и для upstart.

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

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

– Опять ничего не получилось!

весьма характерен для многих проектов Open Source, особенно связанных с Linux'ом: не доведя до ума имеющегося, всё бросать и создавать новый клон, форк, подсистему etc. Мир BSD этим грешит меньше: в частности, devfs, выскобленная и выглаженная, безотказно служит во FreeBSD по сей день.

Правда, в нынешней ситуации надежд, что для systemd пора столбить участок по соседству с HAL'ом и devfs, весьма мало: уж очень тяжёлая артиллерия пущена в ход для его поддержки, да и фланговое прикрытие имеет место быть. Но об этом мы поговорим на следующей странице.

Послестрастие к systemd

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

Собственно, начало этого процесса мы уже наблюдаем. Так, с systemd оказывается связанным journald – демон ведения системных журналов, продвигаемый как замена традиционному syslog... кем бы вы думали? Леннартом Поттерингом и Кеем Сиверсом, одним из основных разработчиков подсистемы udev – скоро мы и до неё доберёмся. Однако связь между ними – не только в именах разработчиков: поскольку journald представляет собой один из стартовых сервисов, он неизбежно должен укладываться в общую канву системы инициализации.

Впрочем, системный журнал – не та штука, которая больше всего интересует конечного пользователя (в отличие от системного администратора). Но дальше – больше: вслед за этим упомянутый только что Кей Сиверс объявляет о слиянии подсистемы udev и systemd в единую кодовую базу. А вот это для пользователя уже важнее: ведь udev отвечает и за настройку Иксов, и за монтирование сменных носителей, и вообще за работу всех устройств. То есть выполняет все функции именованных в прошлой заметке покойников – devfs и HAL.

Правда, в заявлении Кея специально подчёркивается, что udev может использоваться и помимо systemd, и вообще

совместимость udev из состава systemd с другими системами инициализации будет сохранена на протяжении длительного времени.

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

Таким образом, длинные руки systemd протянулись уже и в сторону Xorg, очень сильно зависящего от подсистемы udev. Но это ещё не всё: буквально через считанные дни после заявления Сиверса Auke Kok (транскрибировать не берусь), один из разработчиков системы Tizen (ОС для смартфонов и прочих гаджетов, базирующаяся на Linux) и Lunar Linux (одного из Source Based дистрибутивов второй волны), выступил совсем уж с неожиданным «рабочим почином».

Суть его «встречного плана» – в переносе функциональности, обеспечиваемой ныне дисплейными менеджерами (такими, как KDM и GDM), системами запуска рабочих сред и управления сеансами, из состава этих сред (то есть из KDE, GNOME, Xfce, LXDE)... куда? Правильно, разумеется, в systemd.

Правда, о реакции разработчиков соответствующих десктопов на столь смелую инициативу до сих пор ничего неизвестно. Можно только гадать, в каком восторге от такой перспективы пребывают ныне разработчики KDE, XFce и особенно LXDE.

А вот реакция разработчиков GNOME вполне предсказуема: они сделают так, как будет приказано. Собственно, уже сейчас, по выходе версии 3.2, systemd включён в число его зависимостей. Что, как на шести пиках в преферансе, фактически обязывает майнтайнеров всех дистрибутивов, использующих «третьегном» в своих сборках, обеспечивать поддержку новой системы инициализации, хотя бы опционально.

Впрочем, и без этого systemd расползается по дистрибутивам, по крайней мере, наиболее известным и распространённым. В openSUSE он был внедрён в релизе 12.1 в качестве системы инициализации по умолчанию (хотя, как я уже говорил, возможность «отката» на SysVinit здесь пока сохраняется).

Mandriva перешла на systemd, начиная с прошлогоднего релиза (2011). Разрабатываемый независимым сообществом форк её, Mageia, будет иметь это удовольствие во 2-й своей версии, выход которой должен случиться в ближайший месяц-два.

Чисто «сообщнические» дистрибутивы – Debian, Gentoo, Archlinux, верные своему принципу не забыть никого и ничего – уже опционально включили systemd в свои тестовые ветки.

Очевидно, что инспирировавший всё это Red Hat сменит классово чуждый upstart на родной systemd, как только волонтёры из Fedora вытящат из огня все каштаны отловят основную массу багов. И за ним, естественно, потянутся его клоны в скобках сателлиты, такие, как Scientific Linux и CentOS.

Фактически из популярных дистрибутивов совсем вне сферы systemd'изации пока остаются:

   • Slackware, традиционно отстранённая от всяких «политических разборок»,

   • PCLinuxOS, отличающийся здоровым консерватизмом,

   • серия user-friendly дистрибутивов, типа Vector Linux и MEPIS, которые погоды не делают.

И, разумеется Ubuntu со всеми своими вариантами и клонами. Но тут я уже перехожу к выводам и прогнозам, о которых – позднее.

Отборочные соображения

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

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

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

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

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

Однако тихо и незаметно Ubuntu расширяет сферу своей деятельности в двух противоположных от десктопа направлениях. Первое – это серверные решения, реализуемые в виде периодически выходящих «долгоиграющих» (LTS) версий. Здесь конкурировать с Red Hat она в настоящее время не может и близко – но намерения обозначены. А учитывая базу десктопных пользователей (своего рода подразделения запаса), претворение этих намерений в действительность – вопрос техники и времени. Кроме того, кое-где они даже начали претворяться – но об этом чуть позже.

Второе же направление – прямо противоположное: разного рода гаджеты. И если в серверной сфере Ubuntu тащилась в хвосте не только за Red Hat и SUSE, но даже за прародительским Debian'ом, то здесь она оказалась в числе передовиков производства.

Это выразилось, во-первых, в виде сборок для нетбуков (NBR – NetBook Remix) – а ведь нетбуки, по крайней мере по первоначальной задумке, были куда ближе к гаджетам, нежели к персоналкам. Сам по NBR не получил распространения среди производителей нетбуков и не снискал (вполне заслуженно) популярности среди пользователей. Да и сами нетбуки быстро эволюционировали в сторону «недобуков для бедных», и эта ниша оказалось закрытой.

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

А во-вторых (и это тесно связано с «во-первых»), именно Ubuntu одной из первых всерьёз занялась адаптацией самой себя для альтернативных процессоров – ARM'ов всякого рода. Причём как организованно, так и частным порядком. Первое направление представлено официальными образами для ARM-архитектуры в основной ветке дистрибутива, причём как в десктопном, так и (sic!) серверном вариантах.

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

Разумеется, в Red Hat и на вершинной части его айсберга, представленной Fedora, сложа руки не сидели. В заметке про Федорины меры я уже говорил об интенсивной и весьма успешной десктопизации этого дистрибутива – до поры, до времени.

Оболочка GNOME Shell вышла практически одновременно с Unity – и, как и последняя, пыталась перенести «гаджетную парадигму» на рабочий стол. Правда, сама по себе «гаджетная» система на базе Fedora до сих пор в проекте – в грядущем релизе 18, но можно быть уверенным – за ней дело не заржавеет.

Выходим в полуфинал

И тем не менее, Red Hat (говорим Red Hat – подразумеваем и Fedora) впервые за всю историю существования дистрибутивов Linux оказался не в роли законодателя мод, в выступил в амплуа второго любовника. На десктопном поприще Fedora, по степени «юзерофильности» едва сравнявшись с Ubuntu в своей 14-й ветке, оказалась отброшенной назад с переходом на GNOME 3.

Нет, Unity из одновозрастной Ubuntu была ничуть не лучше GNOME Shell'а (хотя и не хуже, потому что, ИМХО, хуже некуда). Но, имея чуть более длинную предысторию, обладала хоть каким-то средствами настройки. Тогда как GNOME 3 сразу приходилось твикать сторонними твикерами – такого позорища, кажется, не было даже в KDE 4.0.

Но самое главное не в этом. А в том, что Unity вызвала меньшее отторжение среди пользователей Ubuntu, нежели GNOME Shell – среди пользователей Fedora. И причина очевидна: за счёт интенсивной популяризации среди убунтийцев процент совсем начинающих пользователей, которые, кроме Unity, ничего больше толком увидеть не успели, был неизмеримо выше, чем среди пользователей Fedora.

Впрочем, и Unity, и GNOME Shell вызвали, во-первых, возрождение популярности KDE – тем более, что эта среда к тому времени по своей стабильности, функциональности и конфигурабельности стала вполне похожей на настоящую (то есть на KDE 3.5.X). А во-вторых, спровоцировали всплеск интереса к XFce и LXDE.

И здесь опять Ubuntu оказалась более «продвинутой». Её варианты Kubuntu, Xubuntu, а затем и Lubuntu давно развивались как тесно интегрированные с «генеральной линией партии», но самостоятельные проекты. И хотя Джонатан Риддел, главный майнтайнер Kubuntu, недавно был снят Canonical'ом с довольствия, на проекте это как будто не сказалось. Во всяком случае, до сих пор отсутствие дотаций от фирмы-матери не мешало успешно развиваться ни Xubuntu, ни Lubuntu.

В Fedora же XFce и LXDE ютились на задворках великой империи GNOME: официальные сборки дистрибутива с этими средами впервые появляются в тестовой версии 17-го релиза, до этого они имели место быть только в RFRemix. То есть бедные американцы, не владеющие русским языком, были ранее вынуждены устанавливать соответствующие метапакеты с DVD или по сети.

Интеграция XFce и особенно LXDE с общедистрибутивными системными службами оставляла желать лучшего. Про улёт кириллических раскладок я уже упоминал – он касался только ретроградствующих обскурантов вроде меня, которые упорно не желают менять устаревший вариант раскладки typewriter на прогрессивный winkeys. Но постоянно возникали проблемы с автомонтированием сменных носителей и вообще с выполнением операций, требующих ввода рутового пароля.

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

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

Кстати, тут можно фиксировать отставание Fedore, а, следовательно, по завершении периода релаксации, и Red Hat, в коронной для последнего области – серверной: среди убутианских ARM-сборок есть и предназначенные для серверов на этом процессоре. А ныне, в связи с борьбой за энергосбережение, они приобретают актуальность.

Ну а о том, что Ubuntu вырвалась вперёд на таком новомодном направлении, как «облачные вычисления», не говорил ещё разве что совсем ленивый. И не говорите мне, что could computing – это нечто... эээ... не очень определённое, я это и сам знаю. Однако он предназначен для корпоратива и ынтырпрайза, а там, где начинается корпоративный охмурёж – мсье Здравый Смысл может спокойно покурить в тенёчке. И кому это не знать, как ветерану Linux-корпоративного движения.

Империя наносит удар

Я могу представить себе чувство обиды, испытываемое ветераном движения в данной ситуации. Ведь на протяжении 20 лет Red Hat сначала самолично, к лице одноимённого дистрибутива, а затем под псевдонимом Fedora был основным источником инноваций в мире Linux'а. Или, по крайней мере, очень многими воспринимался в этом качестве.

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

Разумеется, реально в серверной сфере Rad Hat'у ничего не угрожает: легион его корпоративных клиентов не будет менять коней не то что на переправе – а просто в дороге. Так что рискну предположить, что в большей мере чувство обиды возникало от того, что скорохват-Ubuntu стал в массовом сознании близнецом-братом Linux'а:

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

Однако, если Столлман пошёл по пути борьбы терминологической – за словосочетание GNU/Linux, и фонетической – за акцентирование первого слова, то Red Hat принял кардинальное решение: отрешиться от старого мира путём отряхивания всего праха мира прежнего – от парадигмы пользовательского интерфейса до системы инициализации, призванной в недалёком грядущем пропитать все прочие подсистемы не только Linux'а, но и некогда кросс-платформенных решений – Иксов и графических сред.

В одной из предыдущих заметок я говорил о своём нежелании знакомиться с systemd. А ещё ранее, и неоднократно (уже не упомню, когда и где) – о нежелании тратить силы на освоение GNOME 3. Мотивируя это тем, что это мне не нужно.

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

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

Кто не с нами – тот против нас!

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

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

Ну а уж что до мелких подъ...ок (да простят меня читающие это дамы, но никакое иное слово здесь не подходит по смыслу) касаемо перекрашивания обоев или перетаскивания кнопок управления окном справа налево – то это просто смешно. Особенно на фоне таких шоу, как демократический выбор имени следующего релиза дистрибутива. Не говоря уж о том, что стратегия «перекрашивания обоев и перетаскивания кнопок» (употребляю это очень фигурально) за несколько лет дала Ubuntu больше пользователей, чем Red Hat'у – самые передовые патчи ядра за двадцать лет.

Короче говоря, мы видим нынче не какую-то техническую дискуссию, а очередной акт вековой драмы, имя которой – Борьба Бабла и Зла. Другое дело, что от исхода этой борьбы зависит направление технического развития систем, которые до сих пор назывались Свободными. И потому пользователей их, вне зависимости от ОСеисповедания и дистрибутиво-ориентации, не может не интересовать ответ на вопрос: чьё же Бабло в борьбе обретёт право стоять во главе борьбы со Вселенским Злом.

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

В преддверии финала

Не исключено, что мы являемся сейчас свидетелями одного из судьбоносных моментов в истории и FOSS, и UNIX-подобных операционных систем, сравнимых по значимости с такими явлениями, как отщепление Берклианской ветки от древа первозданного UNIX'а и возникновения Linux.

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

Вариант первый – осуществление программы-максимум разработчиков systemd: во-первых, её внедрение, по крайней мере, в дистрибутивах «первой десятки», во-вторых, инфильтрация её, при участии udev, практически во все подсистемы Linux, надстраивающих его Иксов и интегрированных сред. Это, подобно зубцу Логовенко из известного произведения классиков, делит мир Linux на две части: майнстримную и маргинальную.

Представители первой группы находятся, как кажется на первый взгляд, в режиме наибольшего благоприятствования. Для них пишутся новые, systemd-ориентированные патчи к ядру, для них, с оглядкой на всё на тот же systemd, развивается Xorg и интегрированные десктопы. Да и приложения со временем начинают писать не под абстрактный UNIX, абстрактные Иксы, Qt и Gtk, и даже не под их адаптации для Linux как таковой: их пишут под Linux, повязанный подсистемами systemd и её метастазами.

Оборотная сторона медали – все представители первой группы со временем превращаются в сателлитов Red Hat. И будут либо подхватывать объедки с барского стола, подобно нынешним CentOS и Scientific Linux, либо расширят «песочницу» Red Hat, ныне представленную одной Fedora, до масштабов изрядной части Linux-сообщества.

Маргинальная группа влачит жалкое существование, которое ей и предрекают Поттеринг и Лангхофф. Они вынуждены довольствоваться старыми версиями ядра, замороженными субсистемами типа udev, застывшими в своём развитии Xorg, рабочими средами и их существующими приложениями, а также обходиться без приложений, которые будут написаны в будущем. И представителям второй группы останется только или тихо помереть, или продастся общественным работникам упасть таки в объятия systemd'щиков.

Поскольку systemd и udev – подсистемы сугубо Linux'овые, в положении маргиналов автоматически оказываются все операционки BSD-семейства. Что ставит окончательный крест на их развитии как десктопных систем. Возможно, об этом не так уж и пожалеют – доля BSD на десктопах нынче исчезающе мала. Но это ставит под сомнение продолжение их развития вообще – ведь все обновления вообще будут сочиняться уже с учётом специфики связки Linux и systemd/udev.

Вспоминается в этой связи высказывание Тео де Раадта в момент распада Иксов на XFree86 и Xorg – о несовместимости новой лицензии первой с идеалами свободы и открытости. Интересно, а как бы ему понравился Xorg, несовместимый с его собственной операционкой? Или абстрактные идеалы для него важнее собственного детища?

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

Очередное этнографическое подтверждение того, что отмирание десктопного Linux'а предвижу не только я – в оттоке от Linux'а юниксоидов старого закала. Правда, не на Windows, а на Macintosh, но зато оттоке массовом – насколько можно говорить о массе применительно к этой немногочисленной группе.

Вероятен ли такой поворот сюжета? Вполне. Во-первых, за ним стоит крупнейшая Linux-компания мира. И, как мы видели ранее, единственная по настоящему успешная, не так давно отпраздновавшая десятый миллиард своего дохода.

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

И, пожалуй, нигде более, чем в крупных Linux-проектах (а все крупные FOSS-проекты последних двух десятилетий в существенной мере завязаны именно на Linux) не проявляется две черты, сформировавшиеся ещё в период, когда их разработка осуществлялась в рамках Just for Fun:

   1. синдром чукчи-хирурга, о котором я уже говорил, и

   2. стремление к созданию собственного велосипеда.

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

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

Разумеется, за исключением энтузиастов штатных, типа Поттеринга, – они-то всё знают, всё понимают, и даже не считают нужным своё понимание скрывать. Прикрывая его фиговыми листочками разговоров о свободе выбора. Ибо для них период Just for Fun в далёком прошлом – они участвуют в бизнес-играх.

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

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

А будет ли финал?

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

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

Правда, в истории мира FOSS я затрудняюсь вспомнить такие случаи: обычно новое принималось «на ура», а потом долго и мучительно доводилось до функционала старого. Чему типичным примером – KDE 4, но его судьба будет предметом специального сравнения мужей.

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

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

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

А в-третьих и главных – мы забыли про второго нашего протагониста, Ubuntu. Ведь со всеобщей systemd'изацией она окажется среди маргиналов – и более того, в первых их рядах. А это уже совсем другой коленкор.

Во-первых, в десктопной сфере Ubuntu, вместе с сателлитами типа Kubuntu сотоварищи, по числу пользователей наверняка превосходит все прочие дистрибутивы Linux, вместе взятые, а с учётом клонов, вроде Mint'а, перевес будет ещё большим.

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

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

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

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

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

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

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

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

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

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

Леннарт Поттеринг об upstart и systemd

Апрель 25, 2012, оригинал 24.04.2012

От переводчика: это запись из блога Леннарта Поттеринга (названия в оригинале нет), с которой я внимательно ознакомился по наводке Vascom'а. Ну и заодно решил её перевести и сопроводить комментарием (см. следующую заметку). Курсивом в скобках – мои вставки, сделанные исключительно ради гладкости русского текста.

Многие люди просят меня в нескольких словах прокомментировать решение Canonical не включать systemd (в состав своей системы). В нескольких словах и скажу:

Я слышал очень много закулисных разговоров о контроле. Они (Canonical) контролируют Upstart (и как майнтайнеры, и как обладатели авторских прав), и полагают, что не контролируют systemd. Однако свободное программное обеспечение никогда не было (полностью) подконтрольным (кому бы то ни было), и, когда вам что-то не нравится – у вас есть возможность создать собственный форк. [Кроме того, во время Git легко поддерживать и собственный набор патчей]. Пример таких компаний, как Sun (которая боялась отказаться от контроля над Java), стремление к контролю вызывает грусть, и никогда не идёт на пользу (любому) проекту.

Я думаю, что такое решение не подходит для экосистемы Linux. Ubuntu стала островом, который становится все более и более отдаляется от всех прочих больших коммерческих дистрибутивов Linux. Поскольку они не приняли systemd, они будут продолжать развивать и поддерживать направления, официально заброшенные разработчиками и майнтайнерами (например, ConsoleKit, независимый udev). Они погрязли в полуустаревшем стеке, который уже не будет развиваться. Конечно, Canonical может сделать инвестиции в большие работы по его развитию для своей платформы, но это, несомненно, станет первым опытом для них, и я серьезно сомневаюсь, что у них достаточно знающих инженеров для этого. Canonical почти ничего не внесла в проектирование Linux, так же как они держатся подальше от (разработки) ядра. Теперь перед ними открывается две возможности: а) остаться навсегда с наполовину устаревшей кучей, или б) много работать, чтобы развивать свой стек исключительно своими силами, чтобы оставаться конкурентоспособными с нами.

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

Всё это выражает мнение Марка, что cloud и focus (его любимые модные словечки) полностью сделают Upstart частью программного обеспечения будущего...

Это печальный день для экосистемы Linux. Но нам это облегчает жизнь, поскольку мы можем отказаться от любых действий по «облегчению», и сохранить свое место в открытом мире с systemd.

Комментарий к заметке Леннарта Поттеринга об upstrat и systemd

Апрель 25, 2012

С предыдущим текстом я ознакомился по ссылке, присланной в личном сообщении Vascom'ом, за что ему весьма признателен – сам бы я до блога Поттеринга не добрался. По прочтении я решил разместить здесь её перевод, сделанный в меру моих скромных сил и возможностей в этой области. А поскольку заметка хорошо укладывается в сюжет очередного Сравнения мужей ( Ubuntu vs Fedora ), то заодно и сопроводил её комментариями.

Для начала надо сказать, что Vascom прислал мне эту ссылку по недоразумению (что не уменьшает меры моей ему благодарности). Вероятно, полагая, что я являюсь приверженцем upstart'а и ненавистником systemd. Должен откреститься от такой трактовки моей позиции: обе системы инициализации мне, как простому советскому юзеру, глубоко до лампочки. И обе, с точки зрения того же пользователя, я полагаю лишними в равной степени – по причинам, изложенным в одном из частей сравнения (Ubuntu vs Fedora).

Однако, тем не менее, разница между ними есть. Точнее, разница в политике их продвижения. Upstart никогда особо не навязывался разработчиками Ubuntu окружающему миру – они полагали его своим личным делом. И то, что он был инкорпорирован, например, в Fedora – проявление доброй воли её разработчиков и их тяги к прогрессу. Кроме того, по большому счёту Upstart не так уж сильно отличается от канонического SysVinit – что, возможно, большой минус с точки зрения гипермодернистов, но не меньший плюс для простых пользователей.

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

Умиляют крокодиловы слёзы Леннарта над грядущей горькой судьбой Ubuntu, которая останется как изолированный остров в дивном новом мире со своим полуустаревшим стеком (мне очень хотелось перевести его stack как кучу... ну вы сами понимаете, чего, но я удержался). Однако, учитывая, что «настольных» пользователей Ubuntu, даже без учёта прямых клонов, типа Mint'а, наверное, больше, чем пользователей всех остальных дистрибутивов, вместе взятых, вопрос о том, что тут остров, а что – матёрая земля, становится не вполне однозначным. Как и вопрос о том, кто из антагонистов стремится к всеобщему (учёту и) контролю.

Да, в корпоративном секторе расклад другой, и в ближайшее время он не изменится. Однако примеры того, как системы с пользовательских десктопов инфильтровались в «корпоратив», мы видели в статье Ubuntu vs Fedora. А вот обратных, пожалуй, и не припомнить. По крайней мере, их не явили нам ни OS/2 встарь, ни OpenSolaris – в недалёком прошлом. И ни один коммерческий UNIX – тоже. А ведь в середине 90-х такие попытки предпринимались со стороны и HP UX, и True64 UNIX, и той же Solaris (правда, вкупе с их же аппаратными платформами, что, в немалой степени, было причиной претерпения ими фетяски).

Что же до стиля Поттеринга... Да, он неслабый пропагандист и агитатор. Прекрасно владеющий любимым приёмом всех гипермодернистов и революционеров – наклеиванием ярлыков на оппонента, типа:

А уж дальше пусть оппонент, подобно пану Гималайскому, сам отыскивает справочку, что он не верблюд.

О пузометрии

Ноябрь 19, 2012

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

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

Так что для начала пара цитат из постов serzh-z'а. Первая из них:

15 лет назад речь не шла о 2-х (двух) секундах, с момента передачи управления ядру и отображения менеджера GUI

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

Однако  serzh-z с этим не согласен:

Системе инициализации на bash и с initrd – 2 секунды не светят.

В ответ на что я предположил, что при отключении сети на моей системе получится нечто подобное – с давних пор изрядное время при загрузке у меня уходит на поиск DHCP сервера и синхронизацию времени с сервером NTP.

Я, конечно, ничего не понимаю в  и прочих systemd'овых штуковинах. Но привык доверять своим глазам и своему секундомеру. Да и измерить время загрузки  своей машины вполне в состоянии, руки пока не отваливаются. Тем более, что применяемая мной openSUSE (пока) даёт возможность прямого сравнения времени загрузки при использовании той или иной схемы инциализации.

Ранее я уже проводил такого рода измерения. И не откажу в удовольствии процитировать себя любимого:

измерения скорости загрузки с секундомером вообще показали интересную картину: при использовании systemd  openSUSE грузилась 55 секунд (это почти втрое дольше, чем Fedora 14 ещё без оного). А вот если переключиться на SysVinit — то время загрузки…падает до 46 секунд.

Предвижу возражение: те измерения проводились на ноутбуке с его медленным и отсталым традиционным винчестером. Да и systemd тогда, в феврале месяце текущего года, была ещё не той системы. А вот  на мощной системе с современным SSD накопителем современная же systemd покажет себя во всей красе.

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

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

   • при systemd – 10 секунд;

   • при SysV... 10 секунд.

Отключаю все сетевые службы и повторяю процедуру. Получаю:

   • при systemd – 10 секунд;

   • при SysV... 8 секунд.

Признаю, загнул в азарте, и при SysV двух секунд на загрузку действительно не светит. Но ведь их не засветило и при использовании systemd. Более того, если при SysV отключение «лишних» служб ведёт к сокращению времени загрузки (пусть и на жалкие 2 секунды), то sysyemd на это просто не реагирует.

Но это ещё не всё. После авторизации у меня грузится KDE с кучей постоянно применяемых мной приложений, в том числе FireFox и Rekonq, в каждом из которых открыто по несколько сайтов. Так вот, после загрузки с помощью SysV сайты эти всегда действительно открыты в соответствующих вкладках. При systemd же вместо этого я вижу сообщение об ошибке и предложение восстановить сеанс в обоих браузерах.

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

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

Правда, убедить в чём-то приверженцев этого менеджера инициализации ничуть не легче, чем читателя Шекспира – в том, что Ричард Третий...

А вот причины этого явления заслуживают отдельного этнографического исследования.

О пузометрии: спустя почти полгода

Апрель 29, 2013

Когда речь заходит о systemd, сторонники этого менеджера инициализации говорят о массе его преимуществ по сравнению и с древним sysvinit, и с upstart, разработанным для Ubuntu.

Многие из этих преимуществ выглядят субъективными. Например, логичность внутреннего устройства системы: логика, как известно, бывает разная, как минимум, аристотелева, неаристотелева и женская. Другие, скажем, контроль над выполнением фоновых процессов, обычно не могут быть оценены конечным пользователем (да и не очень его волнуют). Третьи же, такие, как управление службами, в systemd если и имеют преимущества по сравнению с аналогами из sysvinit и upstart, то только в «многобуквии» (см., например, ) и более ином синтаксисе. В чём следует видеть неустанную заботу о пользователе, дабы он не разучился читать (новую документацию) и писать (точнее, набирать на клавиатуре).

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

   1. момент этот несущественный (нормальная UNIX-машина загружается много если раз в сутки), и

   2. не имеет никакого отношения к скорости выполнения реальных задач.

Тем не менее, сторонники systemd постоянно козыряют этим преимуществом. Провоцируя своих оппонентов на очередные фаллометрические тесты.

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

По установке Ubuntu появилось желание продолжить фаллометрические состязания – уже в сравнении systemd с upstart, в качестве одного из преимуществ которой также декларируется несравненная скорость загрузки. С этой целью были использованы два идентичных накопителя SSD SanDisk Extreme 120 GB. На первом была установлена openSUSE 12.3 с systemd (в этой версии возможность простого переключения на sysvinit ликвидирована), на втором – Ubuntu 13.04 с upstart. В обоих случаях использовалась файловая система ext4. Никаких оптимизаций загрузки ни в той, ни в другой системах не проводилось – загружались службы, предусмотренные при первичной инсталляции.

Усреднённые результаты по десяти замерам времени от нажатия Enter в меню GRUB до приглашения к авторизации (в KDM и LightDM для openSUSE и Ubuntu, соответственно) для каждой из систем следующие:

   • openSUSE с systemd – 7 секунд;

   • Ubuntu с upstart – 8 секунд.

В процентном отношении выигрыш systemd по отноешнию к upstart cсоставляет внушительные 14%. Однако не будем забывать, во-первых, о том, что в абсолютных цифрах речь идёт об 1 (одной!) секунде. Во-вторых, процедура POST на моей машине занимает 18 секунд, на фоне которых та самая секунда выигрыша просто теряется.

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

То есть скорость загрузки системы при использовании systemd – кажущаяся: приглашение к авторизации появлятся до старта всех используемых служб, подобно тому, как это делается в Windows. Казалось бы, ничего страшного? Однако на практике это выливается в ряд мелких, но очень раздражающих неудобств: необходимости повторной загрузки документов, открытых с внешнего винчестера в текстовом редакторе, ручном восставновлении torrent-сессии, обновлении страниц в браузере, а иногда и его перезапуске. Вероятно, systemd как-то можно настроить, чтобы избежать такого безобразия, но upstart ни в какой настройке не нуждается (как, к слову сказать, и sysvinit). Да и абсолютное время загрузки при этом, видимо, будет иным...

Любопытства ради я померял и время загрузки Xubuntu, которая установлена у меня на традиционном винчестере (Seagate Barracuda, 500 ГБ, 7200 об./мин.). Оно составило 11 секунд, то есть примерно в полтора раза больше, чем старт системы с SSD, вне зависимости от схемы инициализации. То есть основной выигрыш в скорости загрузки обеспечивается вовсе не последней, а исключительно «железом». Что, собственно, было ясно из общих соображений (товарищ майор, поздравляем вас с присвоением очередного звания).

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

Отбор участников

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

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

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

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

   • за каждым из этих дистрибутивов стоит тыловое прикрытие (или даже «крыша») в виде коммерческой фирмы.

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

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

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

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

Критерии сравнения

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

   • программа установки;

   • состав репозиториев и их структура;

   • поддержка различных рабочих сред;

   • политика обновления дистрибутива и/или его частей;

   • средства управления пакетами и репозиториями;

   • штатные средства настройки.

Конечно, при этом местами мы вступаем в пограничную область сравнения дистрибутивов и используемых в них рабочий сред. Ибо один и тот же дистрибутив со средой KDE будет похож на любой другой KDE-ориентированный дистрибутив, нежели на самого себя с GNOME или Xfce. Однако это – тоже показательный момент при сравнении. Потому что все три участника нашего соревнования, с одной стороны, имеют свою коронку в виде рабочей среды, поддерживаемой «по первому разряду»: GNOME 3 для Fedora, KDE для openSUSE, Unity для Ubuntu. А с другой стороны, все «коронные» десктопы любого из них поддерживаются остальными участниками или непосредственно, или силами окружающего сообщества. Исключение тут, понятное дело, Unity – но и как мы увидим в конце концов, весьма показательно.

Объяснения и отмазки

Данное Сравнение основано на практическом применении всех его объектов на протяжении ряда лет, хотя местами и с перерывами: Ubuntu – начиная с 05.10 Breezy Badger‭, Fedora – c лета 2009 года и 11-го релиза, openSUSE – с февраля 2012 года и версии 12.1.

Все описываемые особенности дистрибутивов были актуализированы по текущим их версиям: (в порядке выхода «в свет») Ubuntu 13.10 Saucy Salamander (вместе с представителями её семейства того же поколения, стабильный релиз от 17.10.2013), openSUSE 13.1 (стабильный релиз от 19.11.2013), Fedora вместе с RFRemix 20-го релиза).

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

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

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

Широко распространено мнение, что одни дистрибутивы более стабильны, нежели другие. Правда, в качестве как «одних», так и «других» называются те же самые имена, и выяснение этого вопроса часто переходит в виртуальные побоища. Я этот вопрос обсуждать отказываюсь категорически. Во-первых, единицы количественного измерения пресловутой «стабильности» никто ещё не придумал. Во-вторых, за исключением некоторых дистрибутивов, криво собранных на коленке, все современные Linux'ы из числа распространённых – и в первую очередь объекты нашего сравнения – субъективно стабильны, и стабильны одинаково. Конечно, в каждом из них время от времени бывают неудачные версии – но огрехи их достаточно быстро исправляются в рабочем порядке.

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

Сказано же всё это к тому, что любые претензии типа «дистр А падает», «дистр Б глючит», «дистр В тормозит», а «дистр Г летает», отметаются с негодованием. Как, разумеется, и глубокие теоретические обобщения, что «Fedora/openSUSE/Ubuntu отстой, а Ubuntu/Fedora/openSUSE рулезз». С этим, пожалуйста, к врачу-ЛОРингологу...

Ну а мы тем временем приступим к сравнению по намеченным критериям и в указанном порядке.

Реверансы и референсы

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

   • Ирине Киттелль, известной в сети как Алиса Деева – она вдохновляла меня на труды сочинительские;

   • Владимиру Попову, Владимиру Родионову и Сергею Голубеву – немало затронутых здесь вопросов мы обсуждали в реале и виртуале;

   • моим товарищам по форуму POSIX.ru, Юниксфоруму и Джуйке – поимённое их перечисление исчерпало бы мою дисковую квоту.

Искренняя благодарность – участникам проекта Russian Fedora, русскоязычной секции openSUSE Forums и создателям ресурсов по Ubuntu, имя которым – легион. И, разумеется, разработчикам соответствующих дистрибутивов.

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

Вступление

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

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

Исходя из сказанного, попробуем сравнить инсталляторы наших участников. Но сначала – несколько слов о типах инсталляторов. Традиционно установка системы осуществлялась путём выбора некоторых предопределённых наборов пакетов, с опциональной их коррекцией – добавлением нужных компонентов и удалением ненужных. Издревле также это дополнялось режимом чистого попакетного выбора. Но в любом случае пользователь имел некоторую альтернативу для индивидуализации системы. Именно так первоначально обстояло дело в Red Hat и SUSE – предшественниках современной Fedora и openSUSE, соответственно.

Однако на рубеже тысячелетий возникли первые Системы Быстрого Развёртывания. Они основывались на переносе содержимого установочного носителя (как правило, LiveCD) на носитель целевой «один в один». После чего применитель сразу получал в своё распоряжение систему с набором приложений, необходимых для начала практической работы. Выбор рабочей среды и приложений или не предполагался вообще, или осуществлялся до установки – путём подбора соответствующего варианта «живого» образа. Системы Быстрого развёртывания активно развивались в начале нулевых годов – и апофигеем этого развития стала Ubuntu.

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

А вот дистрибутивы с попакетным выбором эволюционировали (не без влияния Ubuntu, к слову сказать) в противоположном направлении – большинство из них обзавелись наборами LiveCD, с которых выполнялось быстрое безальтернативное развёртывание системы. Так что в Fedora и openSUSE оба способа можно рассматривать как равноправные. Но о генетическом происхождении инсталляторов нужно помнить при их сравнении.

Ubuntu

Ubuntu, как только что было сказано, изначально ориентировалась на быстрое развёртывание до более или менее работоспособного состояния. Она не была первой СБР в истории, но среди первых оказалась самой удачной и успешной. Хотя нынче уже не выглядит столь уникальной, как ещё несколько лет назад.

Будучи исходно клоном текстового Debian Installer'а, установочная программа Ubuntu быстро обзавелась графическим интерфейсом с пресловутой «установкой в пять кликов» с так называемых desktop-образов, представляющих собой LiveDVD. При которой, тем не менее, оставалось достаточно возможностей для ручного вмешательства на самых ответственных стадиях – дисковой разметки и создания файловых систем. Правда, в графическом режиме возможна только разметка диска в стиле MSDOS, однако прибегнуть к более иному стилю (читай – GPT) можно при так называемой установке альтернативной (см. ниже).

Выбор доступных файловых систем богат, включая все нативные для Linux (ext2/3/4, XFS, JFS, btrfs, до недавнего времени и ReiserFS) и всякие прочие, вроде FAT'ов и NTFS. Размещать файловые системы можно не только на разделах, но и на мультидисковых устройствах (softRAID и LVM). Правда, опций монтирования их можно задать не много, но все наиболее важные имеются, нет только специфичных для SSD.

Установка пакетов в графическом режиме безальтернативна, и определяется их набором на desktop-носителе: ни прибавить к нему, ни убавить на стадии инсталляции нельзя. Однако индивидуальный выбор пакетов возможен в режиме эксперта при поминавшейся выше альтернативной установке в текстовом режиме, которая сохранилась, во-первых, для дистрибутива Xubuntu, во-вторых – при сетевой инсталляции с MinimalCD.

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

Но есть и другой способ установки индивидуализированного набора пакетов – выполнение из Live-режима процедуры debootstrap, при которой устанавливается так называемая core system, которую в дальнейшем можно нарастить с помощью apt-get. Тот же результат достигается при альтернативной установке выбором режима Command Line Only.

openSUSE

В openSUSE за инсталляцию отвечает соответствующий модуль системы её глобального конфигурирования YaST. Предусмотрено два варианта установки:

   1. с DVD или NET-диска – по своим возможностям они идентичны, различаясь только источником для получения пакетов;

   2. с LiveCD, точнее уже практически всегда LiveDVD – их штатно два, с KDE и GNOME в качестве десктопа.

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

Правда, в наиболее ответственной части установки – разметке диска и создания файловых систем, – возможности инсталлятора, запущенного с LiveCD и же с DVD/CD, в этом отношении одинаковы и богаты до чрезвычайности. В обоих случаях целевой носитель может быть размечен в любом из существующих стилей – практическое значение, как уже говорилось имеют MSDOS и GPT. Созданные разделы могут как непосредственно нести на себе файловые системы, так и объединяться в мультидисковые устройства – softRAID и LVM.

Из файловых систем, правда, поддерживаются не все нативные – нет JFS (не очень-то, впрочем, и хотелось), а в релизе 13.1 пропала ещё и ReiserFS. Что в какой-то мере компенсируется не просто поддержкой btrfs, а возможностью манипуляции её субтомами: как известно, btrfs – это ведь не просто ещё одна файловая система, а нечто с претензией на систему управления размещением данных вообще, подобно ZFS. Ещё одна особенность инсталлятора openSUSE – возможность монтирования файловой системы tmpfs в произвольные точки, разумеется, те, для которых это осмысленно. И, наконец, для всех создаваемых в ходе инсталляции файловых систем можно указать любые из возможных опций монтирования, в том числе и специфичные для SSD-накопителей.

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

С точки зрения выбора пакетов между режимами установки DVD/NET-диска и с LiveCD, казалось бы, существует очевидная разница. В первом случае можно выбрать один из предопределённых наборов – с рабочей средой KDE или GNOME, во-первых, с чистыми Иксами или «голой» консолью, во-вторых. А на следующем этапе обратиться к индивидуальному выбору пакетов для добавления нужных компонентов и удаления излишних, разумеется, с автоматическим разрешением зависимостей.

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

В Live-режиме openSUSE есть и ещё одна возможность индивидуализации системы на стадии её установки. Она похожа на механизм debootstrap в Ubuntu и основывается на понятии шаблонов (patterns), о которых подробнее будет сказано в разделе о пакетном менеджменте. Суть её в монтировании в Live-среду того раздела целевого носителя, который будет в дальнейшем корнем инсталлированной системы, установке на него минимального набора пакетов – так называемого шаблона base (и, возможно, также шаблона enhanced_base), выполнения операции смены корня командой chroot и доустановке всех необходимых компонентов с помощью пакетного менеджера zypper уже в индивидуальном порядке.

Fedora

Установка Fedora осуществляется, как и в случае с openSUSE, либо со специальных установочных носителей (DVD или netinst), либо с одного из LiveDVD, различающихся используемыми рабочими средами. Как и в openSUSE, инсталляционная программа одна и та же для всех типов носителей. И различия в ходе её работы те же самые: с DVD/netinst можно установить как предопределённые наборы пакетов, так и заниматься их индивидуальным выбором – правда, только в отношении пополнения исходного набора (например, рабочий стол GNOME или KDE), корректировать его нельзя.

При инсталляции с LiveCD создаётся точная копия «живой» системы. В отличие от openSUSE, корректировать систему в Live-режиме с сохранением результатов после установки нельзя. Нет и простого механизма установки минимальной системы, подобного debootstrap в Ubuntu или шаблону base в openSUSE. По крайней мере, на поверхности он не валяется, хотя теоретически представить себе такую минимальную установку можно.

Отступление. Некогда в Red Hat применялся текстовый инсталлятор, считавшийся образцом дружелюбия к пользователю. На рубеже тысячелетий его сменил графический установщик Anaconda, верой и правдой прослуживший более десяти лет и заимствованный в ряде других дистрибутивов . Однако к началу второго десятилетия нынешнего века он стал казаться архаичным на фоне Ubuntu и недостаточно функциональным по сравнению с YaST'ом из openSUSE.  Поэтому, начиная с релиза 17, начались попытки его модернизации. Первые из них нельзя признать удачными. Но, как показывает бета-версия, к 20-му релизу (о котором здесь и идёт речь) «болезни роста» остались позади.

Особо надо сказать о разметке диска. В современном инсталляторе она упрощена до предела и сводится к

   • выбору целевого носителя – если таковым выступает чистый диск, на нём будет автоматически создана разметка в стиле MSDOS; от принятой в прошлых версиях GPT-разметки нынче отказались;

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

   • выбору так называемого типа устройства, каковых предусмотрено три – LVM (выбор по умолчанию), btrfs (выбор экспериментатора) и обычный раздел (выбор обычного применителя).

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

Итоги

Подведём итог сравнения инсталляционных программ. Ещё несколько лет назад установщик Ubuntu в своей desktop-ипостаси казался непревзойдённым по простоте, а его alternate-вариант, особенно в режиме эксперта, делил пальму первенства с Debian Installer по части функционального богатства, первую очередь в отношении возможности ручного вмешательства в процесс. Ныне ситуация изменилась.

Нет, графический инсталлятор Ubuntu хуже не стал. Но нынешний установщик Fedora по простоте существенно обогнал его, хотя и несколько уступил в функционале в отношении разметки диска. А вот инсталляционный модуль YaST'а из openSUSE, будучи в варианте DVD/NET не существенно сложнее Ubuntu'вского desktop, далеко превосходит его богатством возможностей. Более того, большинство этих возможностей (кроме выбора пакетов, конечно) доступны при установке в Live-режиме, которая уж точно ничуть не сложнее, чем desktop-инсталляция Ubuntu. Казалось бы, сохранение в последней реликтового текстового установщика могло бы уравнять шансы. Но нет: по функционалу alternate всё равно не дотягивал до YaST'а даже в свои лучшие годы, а нынче он к тому же и деградировал – индивидуальный выбор пакетов в нём стал почти невозможным. Конечно, в этом вина «поломанной» aptitude, но применителю от этого легче не становится.

Иными словами, в координатах простота/функциональность на противоположных полюсах можно поместить современный инсталлятор Fedora (наиболее простой и самый бедный) и модуль YaST'а из openSUSE (относительно сложный – но исключительно в том случае, если есть необходимость использовать его бесподобный функционал на всё катушку). Графический же установщик Ubuntu займёт близэкваториальную зону между ними.

В заключение раздела ещё раз подчеркну следующие моменты.

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

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

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

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

Вступление

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

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

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

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

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

Fedora

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

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

На некоторых зеркалах репозиториев Fedora (например, зеркале Yandex'а) репозитории os и rpmfusion можно видеть в едином дереве каталогов. Но это сделано исключительно для удобства нас с вами – то есть граждан одной из (многочисленных) стран, законы которых не признают ограничений свободы распространения программ по патентному, например, признаку. Официально же RPM Fusion – отдельный проект, и разработчики Fedora делают вид, что его репозиторий не имеет к ним ни малейшего отношения.

Кстати, на зеркале Yandex'а можно увидеть и ещё один репозиторий, имеющий к официальному os ещё меньше отношения, чем rpmfusion – russianfedora. Как нетрудно догадаться, он ведётся нашими соотечественниками и включает в себя в основном пакеты, учитывающие российскую специфику. К нему я ещё вернусь перед подведении итогов.

openSUSE

Репозитории openSUSE также разделяются на основную, официально поддерживаемую майнтайнерами, ветвь (distribution) и ветвь, развиваемую сообществом (repositories). Однако устройство их существенно отлично от аналогов для дистрибутива Fedora. Так, в состав официоза входят не только полностью свободные пакеты, но и некоторые пакеты ограниченного распространения. Правда, здесь эти части без всяких ссылок на свободу и несвободу, называются проще: oss (то есть OpenSuSe, что подчёркивает её неотчуждаемую принадлежность дистрибутиву) и non-oss (очевидно, что это пакеты, без которых дистрибутив может и перебиться).

А вот единого репозитория пакетов от сообщества, подобного rpmfusion в Fedora, в openSUSE нет и в помине. Вместо неё в ветви repositories есть множество отдельных тематических репозиториев, содержащих не только пакеты, дополняющие официоз (и даже не столько их), но в первую очередь сборки более свежих, относительно текущего релиза, крупных компонентов, таких, как ядро, Иксы, KDE, GNOME, а также шрифты и всё, что к ним относится. Эта часть ветви совершенно официально называется полуофициозом (Semi official repositories). Хотя структурно она никак не отделена от репозиториев для дополнительных пакетов, в том числе специализированных, которые тоже имеются в изобилии.

Тем не менее, большая часть дополнительных пакетов сконцентрирована в «домашних» репозиториях (repositories/home:/name). Это своего рода домашние каталоги пользователей – независимых разработчиков отдельных пакетов и их групп.

И тематические, и «домашние» репозитории охватываются понятием репозиториев OBS (Open Build Service). Как явствует из названия, это система сборки пакетов (причём не только для openSUSE, но и для некоторых более иных дистрибутивов), присоединиться к которой может любой «прохожий с улицы». Не вдаваясь в детали (описание которых потребовало бы половины нынешней книги), суть её в следующем: каждый желающий принять участи в развитии пакетной базы openSUSE регистрируется вв системе, получает там учётную запись и домашний каталог, как на локальной машине (например, у автора этих строк – repositories/home:/alv_fedorchuk/) и может резвиться там со сборкой нужных и интересных для него пакетов в полное своё удовольствие. Для чего ему, кроме домашнего каталога, представляется полный сборочный инструментарий (компилятор, необходимые библиотеки и утилиты), запускающийся удалённо в виртуальной машине на сервере OBS.

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

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

Ubuntu

Наиболее широки рамки официоза в репозитории Ubuntu. Для начала в его составе можно выделить официоз первого сорта и, так сказать, второго, то есть поддерживаемые непосредственно фирмой Cannonical и неким сообществом. Это группы main и universe, соответственно: обе включают исключительно свободные программы. Первая дополняется группой restricted, вторая – группой multiverse: и в той, и в другой собраны программы с различными ограничениями. А различия между ними те же: первая официально поддерживается Canonical'ом, вторая... ну как бы не совсем официально.

Здесь очень важно подчеркнуть, что в Ubuntu все четыре группы главного репозитория с точки зрения применителя практически равноправны и могут быть задействованы при инсталляции – для этого достаточно отметить соответствующие опции для установки пакетов из restricted, universe и multiverse.

Однако этим специфика Ubuntu не исчерпывается: кроме основного репозитория, для неё существуют ещё и так называемые репозитории PPA (Personal Package Archive) и инструмент для работы с ними – Launchpad. Это нечто вроде аналогов OBS и её тематических и «домашних» репозиториев. То есть наоборот – приоритет здесь за Canonical (создание Launchpad – 2004 год, OBS, первоначально именовавшаяся OpenSUSE Build Service – 2006 год). Поддерживаются PPA-репозитории, как явствует из названия, сторонними разработчиками, то есть уже сообществом в полном смысле слова.

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

Отступление о стабильности

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

В кругах форумных активистов бытует мнение, что таких «кривых» пакетов больше всего в PPA-репозиториях Ubuntu, хотя многие готовы отдать пальму первенства в этом отношении OBS-пакетам openSUSE или пакетам из rpmfusion Fedora. Правда, в каждом случае уровень доказательности сводится к «у меня не встал» или «а у меня работает».

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

Хотя я готов согласиться с тем, что вероятность нарваться на «кривой» пакет из PPA-репозитория несколько выше, чем из OBS, и ощутимо выше, чем из rpmfusion. Но объяснение этому очень простое: в PPA пакетов немного больше, чем в OBS, и существенно больше, чем в rpmfusion.

Заключение о структуре

Как можно видеть из приведённого описания, главное различие в структуре репозиториев сравниваемых дистрибутивов – в границах их официально поддерживаемой части: наиболее широки они у Ubuntu, наиболее узки – у Fedora, openSUSE же занимает промежуточное положение, хотя и более близкое к последней. С точки зрения их применителей это обуславливает различие в доступе к пакетам, лежащим за пределами круга базовых.

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

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

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

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

Чисто теоретически самой логичной представляется структура репозиториев Fedora – за счёт чёткого отделения официоза от сообщака и агнцев свободы от козлищ проприетаризма. В Ubuntu обе границы проведены вполне волюнтаристически – и потому не всегда понятно, в какой из четырёх групп её главного репозитория следует искать нужный пакет, и не лежит ли он вообще в PPA-сообщаке. В openSUSE собственно официозная часть выделена очень чётко – однако за её пределами попадаешь в сложное переплетение полуофициоза, сообщака и экстернала. Хотя, раз в нём разобравшись, дальше в этих материях ориентируешься легко и непринуждённо. Впрочем, всё сказанное по поводу лёгкости и сложности – не более чем моё очень субъективное мнение.

Наполнение

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

Хотя на самом деле и эта проблема во многом надумана. Если мы обратимся к официозу всех трёх сравниваемых дистрибутивов, то увидим практически полную их идентичность. Что и неудивительно – ведь входящие в них пакеты должны обеспечивать функционирование среднестатистической Linux-системы, Иксов, поддерживаемых рабочих сред и основных приложений. То есть компонентов, которые одни и те же во всём мире FOSS – что в Африке, что в Европе, что в Америке. Оговорок тут две: первая связана с более широким понимание официоза в Ubuntu, о чём уже была речь, вторая – с поддерживаемыми рабочими средами, про что будет сказано в следующем разделе.

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

С другой стороны, экосистема, сложившаяся вокруг Ubuntu, обеспечивает, во-первых, охват наиболее широкого круга дополнительных пакетов, во-вторых, самое активное его расширение. Так что распространённое мнение, что в PPA, как в Греции, всё есть, имеет под собой все основания. Как и то, что в наши дни большинство новых программ и их свежих версий появляется именно в сборках для Ubuntu. Более того, её Launcher может использоваться как своего рода путеводитель по новым пользовательским программам и их свежим версиям.

Ну а openSUSE в этом отношении занимает промежуточное положение. Хотя инфрастуруктура OBS позволила бы ей наступать на пятки лидеру. Однако её потенциал до сих пор не реализован в полной мере (но это уже проблема гуманитарная).

Завершу раздел о репозиториях небольшим патриотическим рассуждением. Если о богатстве или бедности абстрактных репозиториев можно спорить до посинения, то в отношении первенства во всём, что касается обеспечения работы в условиях нашего Отечества, торг неуместен: оно принадлежит репозиторию russianfedora (среди объектов настоящего сравнения, разумеется). И дело даже не в том, что он даёт возможность устанавливать мультимедийные кодеки или использовать патентованные методы рендеринга шрифтов «из коробки», хотя и это немаловажно. Главное, в рамках проекта Russian Fedora все баги, ущемляющие национальную гордость великороссов, выявляются мгновенно – и столь же мгновенно ликвидируются.

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

Итог

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

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

А вот место второе я отдал бы openSUSE: официоз её, как и у победителя, в более дробной структуре не нуждается (если считать пару дюжин пакетов из non-oss просто довеском). А ветвь repositories, хотя и имеет запутанную структуру, но – имеет; и при желании в её логике на так сложно разобраться.

Ubuntu оказывается на последнем месте заслуженно: во-первых, за волюнтаризм, проявленный при разделении базовых пакетов, во-вторых – за полное отсутствие структуры репозиториев PPA, в которых без поллитры Launcher'а не разобраться.

С точки зрения доступности репозиториев картина прямо противоположная: первое место присуждается Ubuntu за возможность доступа к дополнительным пакетам при инсталляции системы. На втором месте – openSUSE, в которой при установке определённым образом дополнительные репозитории прикрутить можно. На третьем месте, по понятным причинам, Fedora (тот самый случай, когда принципы вступают в противоречие с практикой).

Впрочем, с учётом запасного игрока из клубной команды – репозитория russianfedora, картина опять повернётся другим боком, и Fedora вполне может потягаться с Ubuntu за первую ступеньку пьедестала почёта. А поскольку мы живём в этой стране, единственное основание его не учитывать – низкопоклонство перед Западом и укоренившееся недоверие ко всему отечественному. Так что при таком раскладе openSUSE остаются глубоко... на третьей ступени.

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

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

Первое, что видит применитель после установки дистрибутива и первого запуска системы – это рабочая среда (или, по простому, десктоп). Та самая, которую он выбрал при инсталляции или ещё раньше, скачивая Live-носитель для оной. Да и в дальнейшем он будет работать не столько в Linux'е или каком-либо его дистрибутиве, а в KDE, GNOME, Unity и так далее. И потому очень важный критерий нашего сравнения – поддержка десктопов.

Вступление

Сравнение поддержки десктопов в дистрибутивах вообще сводится к ответу на два вопроса: какие рабочие среды они поддерживают – во-первых, и как именно они это делают – во-вторых.

Применительно к героям нашего сравнения на первый вопрос двумя словами ответить очень легко: в том или ином виде и Ubuntu, и openSUSE, и Fedora поддерживают все существующие в природе свободные рабочие среды. В репозиториях каждого, официозных или сообщнических, мы найдём и ветеранов-мастодонтов (не только по возрасту, но и мощи) KDE и GNOME, и их лёгкого ровесника Xfce, ныне животом не менее плечистого, и молодого (возможно, навсегда) LXDE, и совсем уж зелёную поросль Mate с Cinnamon'ом.

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

Открою страшную тайну: каждый из участников нашего сравнения поддерживает не только интегрированные рабочие среды, но и практически все хоть как-то развиваемые менеджеры окон. В официальных или дополнительных их репозиториях можно увидеть и IceWM (устанавливается в openSUSE по умолчанию при выборе конфигурации с минимальными Иксами), и Enlightenment (используется в одном из клонов Ubuntu – Bodhi Linux, устанавливается опционально в инсталляторе Fedora), и представителей семейства *box'ов, и обретшего не так давно вторую жизнь WindowMaker, и многие, многие другие. Но их я в настоящем сравнении рассматривать не буду.

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

openSUSE

Проще всего ответить на второй вопрос относительно openSUSE: в этом дистрибутиве совсем официально поддерживаются только KDE и GNOME. Под совсем официальной поддержкой я подразумеваю наличие соответствующих Live-носителей, во-первых, и возможность выбора одного из этих десктопов на первой ступени установки с DVD/NET-носителя – во вторых.

Однако в официозе openSUSE присутствуют также и такие рабочие среды, как Xfce и LXDE. И они доступны для выбора на первой ступени установки с DVD/NET-носителя. Более того, с недавних пор среди официальных Live-носителей openSUSE появился образ под названием Rescue – ни что иное, как «живой» диск со средой Xfce. Правда, по умолчанию он не предназначен для установки системы, но путём несложных манипуляций сделать это можно.

А вот таких относительно новых десктопов, как Razor-Qt, Mate и Cinnamon, мы в официозе openSUSE не найдём. Однако и они доступны для установки – достаточно обратиться к тематическим или домашним репозиториям OBS.

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

А вот Xfce поддерживается... не то что плохо, а просто недостаточно. Что и не удивительно: по агентурным данным, поддержкой этой среды в openSUSE занимается всего один человек.

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

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

Fedora

В Fedora до недавнего времени дело обстояло ещё проще: в ней официально поддерживались только GNOME и KDE, отчасти Xfce. Причём Fedora была ещё более GNOME-ориентированной, нежели openSUSE – ориентированной на KDE: остальные десктопы поддерживались или похуже (KDE), или кое-как (Xfce). Ныне, однако, ситуация выравнялась: в официальном репозитории дистрибутива представлены все ныне развиваемые десктопы. А среди официальных Live-носителей имеются сборки с GNOME, KDE, Xfce, Mate. Есть они и в RFRemix. В сборках коего, кстати, при установке с DVD/NET-носителей имеется возможность выбора GNOME и KDE в минимальной комплектации.

Что же до качества поддержки – есть основание предполагать, что для GNOME оно осталось неизменно превосходным (с оговоркой на счёт предмета поддержки), для KDE – по слухам, достигло того же уровня, что и для «головного» десктопа. С Xfce всё по прежнему – это похоже на побочный продукт жизнедеятельности проекта. Относительно состояния дел с LXDE, Mate ничего сказать не могу. А вот что касается Cinnamon'а, то поддержкой это можно назвать чисто условно: не смотря на официальный статус, система с этим десктопом в русскоязычном окружении (и, подозреваю, в других не англоязычных) к использованию не приспособлена (надеюсь, что временно – пока до него не дотянутся длинные руки участников Russian Fedora).

Ubuntu

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

Однако Ubuntu – это не только одноимённый дистрибутив, но и целое их семейство, построенное на одной базе (то есть общих репозиториях main и restricted), но с различными компонентами из universe и multiverse, в первую очередь как раз с разными десктопами. И среди «законных» его отпрысков – Kubuntu, Xubuntu, Lubuntu и Ubuntu GNOME с рабочими средами KDE, Xfce, LXDE и GNOME 3, соответственно. И поскольку эти дистрибутивы развиваются сообществами любителей и энтузиастов перечисленных десктопов, каждый из них поддерживается «с искусством и любовью» – по крайней мере, про первые два могу утверждать на основе собственного опыта.

На этом список официально признанных десктопов заканчивается. Однако с течением времени вокруг Ubuntu образовалось изрядное количество «бастардов», самый известный из которых носит имя Mint. Он основан на тех же пакетах из базовых репозиториев родительской системы, надстраиваемых собственными сборками рабочих сред и их приложений. И исконными его десктопами являются Mate и Cinnamon. К поддержке которых слова Эрика Реймонда про искусство и любовь применимы не меньше – опять же про Cinnamon подтверждаю собственными впечатлениями.

К слову, заодно в Mint поддерживаются собственные сборки с KDE и Xfce. А его сборки Mate и Cinnamon'а можно безболезненно перетащить в Ubuntu – и это сделано посредством соответствующих PPA-репозиториев.

Итоги

Подведём итог. Для Fedora и openSUSE характерна блестящая поддержка «титульного» десктопа и произвольная, часто по остаточному принципу, всех остальных. Что я ни в коем случае не отнёс бы к недостаткам: лучше один хорошо заточенный десктоп, чем много недоделанных. Что мы, собственно, и видим в коммерческих линиях RHEL и SLE.

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

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

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

Релиз-циклы

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

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

Релиз-цикл всех трёх наших героев колеблется вокруг 6 месяцев. Для Ubuntu он выдерживается очень строго: новая версия выходит дважды в год, в октябре и апреле. Единственная в истории этого дистрибутива задержка была связана с разработкой первого «долгоиграющего» релиза 6.06 LTS dapper и составила почти два месяца.

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

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

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

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

В «межрелизье»

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

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

В «межрелизье». Fedora

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

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

В «межрелизье». Ubuntu

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

Далее, при необходимости каких-либо важных компонентов системы можно обратиться и к PPA-репозиториям. Например, существует специальный репозиторий с пакетами ядра Linux версий, более старших, чем входят в текущий релиз дистрибутива. А если как следует покопаться в Launchpad'е, то можно найти свежие версии и различных десктопов (например, KDE, более позднюю, чем в текущей Kubuntu), и офисных пакетов (как LibreOffice, так и Apache OpenOffice), и многое другое. Правда, стабильность таких сборок не всегда гарантирована – но это касается любых дополнительных репозиториев всех без исключения дистрибутивов.

В «межрелизье». openSUSE

Однако больше всего возможностей для маневра в деле обновления системы – у применителей openSUSE. Во-первых и во-вторых, как и остальных, в их распоряжении стабильный релиз с его косметическими апдейтами и чисто тестовый Factory – репозиторий релиза разрабатываемого, со всеми «джигитскими» особенностями аналогов. В-третьих, имеется репозиторий Tumbleweed, регулярно обновляемый по модели rolling release и содержащий сборки всех пакетов дистрибутива в версиях, актуальных на данный момент времени. В отличие от Factory, он предназначен не только для опробования, но и для практической работы, и потому проходит тестирование именно как системная целостность. Хотя, конечно, по части стабильности может уступать текущему релизу.

В-четвёртых и, на мой взгляд главных, пора вспомнить о полуофициальных репозиториях. Как уже говорилось, в них содержатся сборки последних версий ключевых компонентов системы – ядра, KDE, GNOME и некоторых других. В отличие от Tumbleweed, их можно подключать независимо друг от друга, используя, таким образом, модель частичного роллинга только для тех пакетов, которые наиболее важны для данного применителя. Причём частичный роллинг может быть не перманентным, а задействованным на период активного развития интересующих подсистем. Например, во время кардинального совершенствования KDE, продолжавшегося с версии 4.6.X по 4.9.X, я подключал соответствующий полуофициальный репозиторий. А когда мне было интересно отслеживать изменения поддержки в ядре файловых систем (btrfs, f2fs), я задействовал репозиторий Kernel.

Наконец, в-пятых, самые свежие версии некоторых компонентов подчас можно отыскать в «домашней» части репозиториев OBS, подобно тому, как применители Ubuntu обращаются к PPA. Правда, в openSUSE, из-за наличия других моделей обновления, этот способ требует аккуратности: пакеты из home-репозиториев собираются под конкретные стабильные релизы, а также обычно под Tumbleweed и Factory. А вот с полуофициальными репозиториями они могут быть не согласованы по версиям.

Итог

Сказанного, думаю, достаточно, чтобы читатель составил себе представление о сравнительных возможностях обновления в Fedora, Ubuntu, openSUSE. А также – кому из них присудить переходящее красное знамя: ведь как раз на это я толсто намекал, отдавая предпочтение устройству репозиториев openSUSE. Именно их структуре этот дистрибутив обязан своей гибкой и контролируемой моделью частичного роллинга.

Таким образом, за безупречное следование политической линии обновлений, определяемых применителем, дистрибутив openSUSE награждается золотой медалью. А вот серебро и бронзу поделим поровну: Ubuntu за то, что допускает произвольное обновление из PPA-репозиториев, Fedora – за то, что не даёт возможности поломать систему, обновляя её в «межрелизье».

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

Вступление

Инструменты для работы с пакетами можно разделить на четыре группы:

   • установщики пакетов;

   • менеджеры пакетов;

   • их графические фронт-энды;

   • центры приложений.

С первой группой всё ясно – это низкоуровневые утилиты для работы с единичными пакетами, каковыми в нашем случае выступают самые обычные rpm для Fedora и openSUSE, и dpkg для Ubuntu. Сравнивать тут особенно нечего, по своим функциям они практически идентичны. Да и непосредственно применяются нынче редко – все обыденные манипуляции с пакетами обычно проще выполнять посредством менеджеров пакетов и их графических оболочек, которые и будут основным объектом дальнейшего сравнения.

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

Менеджеры пакетов

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

Среди участников нашего сравнения в роли «главменеджера» выступают:

   • в Ubuntu – комплекс утилит apt;

   • в Fedora – утилита yum;

   • в openSUSE – утилита zypper.

Список этот составлен в порядке «старшинства»: apt – древнейший из пакетных менеджеров вообще (начало разработки – 1998 год), yum создавался на несколько лет позже, в 2001-2002 годах, а zypper появляется в составе openSUSE в 2008 году. И это следует учитывать при сравнении функционала наших героев: более поздние пакетные менеджеры разрабатывались с учётом опыта предшественников.

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

Управление репозиториями включает в себя:

   • получение списка включённых репозиториев,

   • получение информации о репозитории,

   • подключение нового репозитория и отключение ненужного,

   • обновление локального кэша пакетов после изменения репозиториев.

И вот тут мы сталкиваемся с первым различием в функционале объектов сравнения: если yum и zypper прекрасно справляются с первыми двумя задачами, то в apt таких возможностей не предусмотрено. Подключение и отключение репозиториев – штатные функции и yum, и zypper (последний умеет также их переименовывать и модифицировать), тогда как в Ubuntu для этого требуется специальная утилита add-apt-repository (которая, кстати, появилась совсем недавно). Обновление локального кэша и в yum'е, и в zypper'е выполняется при каждом запуске (хотя это при необходимости можно отключить), apt-get же требует специальной субкоманды.

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

Начать с того, что для поиска и получения информации, с одной стороны, и непосредственно для действий с пакетами в Ubuntu требуется две отдельные команды – apt-cache и apt-get, соответственно, тогда как в Fedora и openSUSE достаточно одной, титульной. Далее, apt-cache search не способен отличать установленные и неустановленные пакеты, что по силам yum'у. А zypper, кроме того, имеет собственный фильтр, делающий ненужным обращение к команде grep для отделения «зёрен от плевел». Вообще по богатству извлекаемой информации zypper в ряду нашего сравнения – вне конкуренции.

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

Различно также обращение сравниваемых утилит с метапакетами – наиболее специфичным (и гибким) тут опять же выглядит zypper. Если метапакеты в Ubuntu и Fedora (задачи и группы, соответственно) представляют собой жёсткие списки пакетов, то шаблоны в openSUSE включают в себя обязательные, альтернативные и опциональные компоненты, определённые майнтайнерами. Но даже они могут быть скорректированы пользователем при установке. Все три типа метапакетов ныне могут быть принудительно «разубожены» – то есть после установки из них можно изъять, при соблюдении некоторых условий, ненужные компоненты. Делается это различным образом: «лобовым» удалением пакета в Fedora, изменением его статуса в Ubuntu, удалением включающего шаблона в openSUSE.

И, наконец, действия над системой в целом – это её обновление и очистка от «мусора». Тут глубоких различий между возможностями утилит из сравниваемых дистрибутивов я не вижу. Разве что опять-таки при использовании apt-get требуется отдельной командой предварительно обновить кэш, а yum и zypper сделают это автоматически. А так – все три системы предлагают два вида обновления: просто обновление установленных пакетов до последних доступных в репозитории версий и апгрейд дистрибутива, позволяющий смену его релиза. Правда, yum предлагает ещё несколько разновидностей обновлений системы, но каково их практическое значение, мне осталось не ясным.

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

Синтаксически наименее прозрачным и логичным мне представляются утилиты apt – хотя бы потому, что на каждый чих их требуется две (это не считая дополнительных команд типа add-apt-repository – да, Беня знает за автодополнение, но всё же...). Да и субкоманды к каждой длинноваты и не всегда смысл их очевиден. В этом отношении yum, ограничивающийся одноимённой командой, кажется гораздо более простым и лаконичным. Однако ряд функций его реализован за счёт внешних плагинов, которые не всегда устанавливаются по умолчанию, и с которыми тоже надо разбираться. А вот zypper с его логичным синтаксисом, допускающим использование сокращений в субкомандах, выглядит абсолютным чемпионом.

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

Графические фронт-энды

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

В случае объектов нашего сравнения «морды» до недавнего времени были таков:

   • в Ubuntu и всех Gtk-сородичах – Synaptic, и Muon, его функциональный аналог в Kubuntu;

   • в Fedora – gnome-packagekit для одноимённого десктопа GNOME и apper для среды KDE;

   • в openSUSE – модули универсальной системы YaST для управления пакетами и репозиториями.

И Synaptic, и Muon – графические надстройки над утилитами apt-get и apt-cache, добросовестно воспроизводящие их функционал в наглядном и интуитивно понятном виде. Более особо сказать о них нечего – но ведь и честного исполнения своего долга достаточно.

Ситуация с Fedora изменилась буквально пока верстался номер. В её 20-м релизе из набора gnome-packagekit исчез интегратор – gpk-application: ныне исполнение его супружеских обязанностей возложено на GNOME Software – но это представитель следующего класса программ.

А пока пару слов об уходящем gpk-application – не исключено, что он ещё появится.

Утилиты gnome-packagekit и apper – высокоуровневые надстройки над системой PackageKit. Последняя задумывалась как самое кросс-форматное, кросс-дистрибутивное и вообще самое-самое кросс-платформенное средство пакетного менеджмента – своего рода метапакетный менеджер. «Снизу» к ней теоретически можно подключить чуть не любые пакетные менеджеры – apt, zypper и, разумеется, yum. «Сверху» же PackageKit надстраивается консольной утилитой pkcon и уже именованными графическими «мордами».

Утилита pkcon подходит только на роль yum'а для нищих (духом), предлагая некоторое упрощение использования за счёт существенного ограничения функционала, по сравнению со своим бэк-эндом. И, видимо, поэтому ею никто не пользуется: для знающих yum она слишком убога, для ниасиливших интерфейс командной строки – излишне сложна.

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

Полноты картины для надо заметить, что в Fedora есть ещё одна графическая программа того же назначения – Yum Extender. Как явствует из названия, это «морда» к консольному yum'у – непосредственно, без прослойки PackageKit. По своим возможностям он примерно эквивалентен Synaptic'у, но по умолчанию не используется в основных базовых десктопах: мне он попался только при установке Fedora с Cinnamon'ом в качестве рабочей среды.

И, наконец, YaST из openSUSE. Это – универсальная система конфигурирования всего и вся, о которой будет подробно говориться в следующем разделе. Сейчас же нас интересуют только два её модуля – управления пакетами и репозиториями. Это опять-таки не более чем «морды» к zypper'у – но «морды», полностью задействующие возможности своего бэк-энда. А поскольку на прошлой странице последний был увенчан чемпионскими лаврами в своей весовой категории, то в категории графических фронт-эндов этот титул по праву принадлежит YaST'у.

Центры приложений

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

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

На самом деле эту чуждую нам магию мы немедленно разоблачим. Ибо Центр приложений – ни что иное, как надстройка над комплектом утилит apt. И поиск осуществляется в его базе данных, то есть в подключённых репозиториях и источниках коммерческих программ – партнёров Canonical. То есть для поиска в PPA-репозиториях, что наиболее актуально для применителя, Центр приложений оказывается бесполезным. Эту функцию выполняет отдельное web-приложение – Launcher.

Центр приложений работает во всех дистрибутивах семейства Ubuntu, кроме Kubuntu: там имеется его аналог – Muon Discover. Нечто подобное, под названием Менеджер программ, существует и в Mint'е. Наконец, в сообществе разрабатываются несколько усовершенствованные производные Центра – например, App Grid.

Однако нашей целью является сравнение не убунтоидов, а трёх главных героев. Как с программами этого типа обстоит дело в них?

Если говорить о Fedora – то ответ до недавнего времени был прост: никак. Правда в GNOME версии 3.10, которая входит в состав 20-го релиза, был обещан некий GNOME Software –но в бета-версии его не было. Появился неожиданно в релизе. Что о неё сказать? Центр как центр, сделан по образу и подобию Центра приложений Ubuntu.  Не лучше и не хуже. За одним исключением. В Ubuntu после введения соответствующей приблуды Synaptic в системе сохранили – хотя и не по умолчанию. В Fedora же gpk-application подвергли обрезанию под корень.Слова доброго он, конечно, не стоил – но всё же жить с одним центром приложений – это тоже не правильно.

Кстати говоря, в openSUSE 13.1 сборка с GNOME (версии 3.10, однако) ни малейшего софтверного центра не содержит.

Но зато в openSUSE есть механизм, реализующий те же функции, что и Центр приложений (и даже лучше). Это так называемый 1 Click Install. Он не представляет собой отдельного приложения на локальной машине, но работает через любой браузер. И делает это так.

Если зайти на вот страницу (доступ к ней – также через Get it главной страницы сайта проекта) и ввести в строке имя пакета (или его часть – поиск инкрементный), то выведется весь список подходящих пакетов для всех поддерживаемых версий дистрибутива, вне зависимости от того, находятся ли они в подключённом или незадействованном репозитории. После чего достаточно выбрать нужную версию и архитектуру, щёлкнуть на ссылке, которая так и называется 1 Click Install – и начнётся процедура установки пакета. Для чего, если пакет находится в неподключённом репозитории, запускается сначала модуль управления репозиториями YaST, а затем и его модуль управления пакетами. То есть в первооснове всего механизма оказывается всё тот же zypper.

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

Итог

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

Столь же бесспорно второе место Ubuntu. Конечно, её apt несколько менее строен, чем yum, но вполне самодостаточен. А его фронт-энд, Synaptic, как бы ни обзывали его архаичным, всяко лучше PackageKit'овских «морд». И, конечно, Центр приложений ничуть не вредит: не смотря на «попсовость», он позволяет быстро поставить какую-нибудь софтину «на поглядеть». И столь же быстро её ликвидировать, если не глянулась. Так что в общем зачёте для Fedora не осталось другого места, кроме третьего. В том числе и за пудрение мозгов с GNOME Software.