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, вне зависимости от схемы инициализации. То есть основной выигрыш в скорости загрузки обеспечивается вовсе не последней, а исключительно «железом». Что, собственно, было ясно из общих соображений (товарищ майор, поздравляем вас с присвоением очередного звания).