Алексей Федорчук - Священные войны мира FOSS

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

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

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

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

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

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

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

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

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

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

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

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

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

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