Перед вами очередное «сравнение мужей», которое, как и все сочинения данного жанра, преследует в основном гуманитарные цели – этнографические или, если угодно, этологические. Однако, прежде чем добраться до гуманитарной составляющей, придётся пройти сквозь некоторые технические детали устройства объектов сравнения. А в качестве таковых выбраны 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.