Devuan: плод нелюбви к systemd

Автор: Евгений Голышев

Статья была опубликована в 237-м выпуске журнала Linux Format. По истечении полугода с момента публикации права на статью переходят ее автору, поэтому материал публикуется в нашем блоге.

Кена Томпсона [Ken Thompson] однажды спросили, что бы он изменил в UNIX, если бы проектировал систему заново, и он ответил: «Я бы написал creat с буквой e» (англ. I’d spell creat with an e). Эта шутка, на мой взгляд, как ничто другое подчеркивает, насколько бережно Unix хранит традиции: за 40 с лишним лет так никто и не добавил букву e к имени системного вызова, хотя количество опечаток, допущенных при написании кода, велико и с каждым днем продолжает расти. В конце концов, кто может осмелиться сказать, что архитектурные решения патриархов Томпсона и Ритчи ошибочны?

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

И однажды в этот мир вторгся человек по имени Леннарт Пёттеринг [Lennart Poettering], со своим видением дистрибутивостроения, которое, по мистическому совпадению, в корне отличалось от того, к которому все успели привыкнуть за пару десятков лет. Всё бы ничего, но Леннарт родился с редкой способностью изменять всё вокруг, поэтому он легко начал воплощать свои задумки, а через крупнейшие дистрибутивы (Debian, Ubuntu, Red Hat Enterprise Linux, SUSE Linux Enterprise и т. д.) они стали добираться до согласных и несогласных с ним пользователей.

Леннарт полон неоднозначных идей того, каким образом дистрибутивы GNU/Linux можно сделать лучше.

Данная статья посвящена Devuan (читается как DevOne). Devuan является производным от Debian GNU/Linux дистрибутивом, основная цель которого заключается в альтернативном развитии Debian, как если бы он никогда не встретился с известным детищем Леннарта под названием systemd. Я написал эту статью главным образом по двум причинам.

Во-первых, Debian-подобные дистрибутивы – моя страсть, а Devuan, один из ярких представителей этого семейства, упоминался на страницах LXF только вскользь, поэтому я чувствую своим долгом исправить это недоразумение.

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

В конце концов, если человек в один прекрасный момент поймет, что ненавидит systemd, то пусть хотя бы будет способен объяснить, почему.

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

  • установке, настройке и администрировании серверов под управлением Devuan;
  • администрировании серверов на базе Linux-подобных операционных систем, использующих systemd (если вы интересуетесь практиче­ской стороной systemd, то рекомендую обратиться к LXF199).

Хочу сразу отметить, что я не являюсь пользователем Devuan, предпочитая ему Debian (рабочая станция) и Ubuntu (ноутбук), и стараюсь занимать нейтральную позицию в спорах, связанных с действиями Леннарта Пёттеринга в общем и с systemd в частности. Но разочаровываться не стоит – я регулярно имею дело с Devuan при решении различных задач, одной из которых является разработка сервиса для кастомизации образов операционных систем для одноплатных компьютеров.

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

В погоне за ускорением загрузки

В конце 2000‐х несколько крупных производителей операционных систем на базе ядра Linux пришли к выводу, что необходимо ускорять время загрузки своих систем. Так как за загрузку операционной системы отвечает система инициализации, стало очевидно, что начинать нужно именно с нее. В течении долгого времени дистрибутивы GNU/Linux использовали для этих целей SysVinit, созданную Микéлем ван Смооренбургом [Miquel van Smoorenburg] и основанную на идеях оригинальной System V init. SysVinit сейчас считается классиче­ской системой инициализации и в данной статье противопоставляется всем другим.

SysVinit представляет собой систему инициализации, основанную на уровнях запуска (runlevel-based). Уровни запуска – это состояния, в которых может находиться система; система переходит из одного состояние в другое. SysVinit выполняет скрипты, ассоциированные с определенным уровнем, когда система входит в (или покидает) этот уровень. К примеру, когда система входит в уровень запуска N, то SysVinit запускает скрипты из /etc/rcN.d, где N — число от 0 до 6. Однако со временем накопилось много потребностей, которые классиче­ская система инициализации не могла удовлетворить в силу своей архитектуры (к примеру, слежение за своими дочерними процессами и их перезапуск в случае необходимости).

Недостатки SysVinit мотивировали компанию Canonical, которая является основным разработчиком Ubuntu, начать работу над альтернативной системой инициализации под названием Upstart, а достоинства launchd из Mac OS X и SMF из Solaris послужили основным источником ценных идей, которые помогли в решении поставленной задачи. Новая система инициализации оказалась эффективнее, чем SysVinit благодаря событийно-ориентированной архитектуре (event-driven architecture). Системные сервисы стало возможным запускать и останавливать на основе событий, а не уровней запуска. Данный подход предполагал генерацию событий при запуске или остановке системных сервисов, что позволило организовать привязку к ним других сервисов.

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

Upstart дебютировала в Ubuntu 6.10 «Edgy Eft» в конце 2006 г., заменив SysVinit (однако окочательно новая система инициализации была интегрирована в дистрибутив только к выходу Ubuntu 9.10 «Karmic Koala»). Затем на Upstart обратили внимание компании Google и Red Hat, интегрировав ее в свои продукты. Так Upstart нашла применение за пределами Ubuntu и начала использоваться в ChromeOS и Red Hat Enterprise Linux 6. На новую систему инициализации даже планировал перейти Debian.

При всех своих достоинствах, Upstart оказалась всего лишь трамплином для другой, более совершенной системы инициализации. Так, в апреле 2010 г. компания Red Hat, при участии разработчиков из Novell, IBM, Intel и Nokia, поставила перед собой цель создать систему инициализации, нацеленную на более интенсивную параллелизацию выполнения сервисов на этапе загрузки. Проект, получивший название systemd, возглавил Леннарт Пёттеринг. И уже в июле того же года была выпущена первая стабильная версия проекта.

На тот момент systemd получала не больше негативной критики, чем любой другой проект, позиционирующий себя как альтернативная система инициализации. Всё шло относительно гладко, несмотря на то что systemd (почти) сразу обратила на себя внимание своим агрессивным подходом к делам, связанным с обратной совместимостью. (К примеру, если Upstart была совместима со скриптами инициализации SysVinit, то новейшая система инициализации не была завязана ни на Bash, ни на любую другую оболочку.) Ситуацию не сильно усугубил и тот факт, что именно Леннарт был тем самым разработчиком звукового сервера PulseAudio, который в начале своего пути не отличался стабильностью работы (в основном из-за аудиодрайверов, а не ошибок в коде PulseAudio).

Проекту серьезно досталось немного позднее, когда в один прекрасный день systemd перестал позиционироваться как альтернативная система инициализации, превратившись в системный менеджер, в котором система инициализации стала всего лишь одним из многочисленных компонентов. О двух таких компонентах — journald и logind — я хочу рассказать прямо сейчас.

logind представляет собой систему управления пользовательскими сеансами. До того, как за решение этой задачи взялись разработчики systemd, дистрибутивы GNU/Linux для этих целей использовали ConsoleKit. В свое время ConsoleKit поставил перед собой амбициозную цель – поддержку более одного независимого рабочего места (multi-seat), что предполагает одновременную работу на одной системе нескольких независимых графических сеансов для различных пользователей. (Функция редкая, но в некоторых случаях очень востребованная.) Тем не менее, архитектура ConsoleKit не способствовала достижению заветной цели и проект оказался в глубокой стагнации. Так, без переизобретения велосипеда непростая задача поддержки более одного независимого рабочего места была решена в рамках компонента logind. Другими словами, лучшей альтернативы в мире Linux еще не видели. Более того, решение оказалось настолько удачным, что Энди Винго (Andy Wingo), один из разработчиков дистрибутива Guix, реализовал возможность обособленного использования logind. Проект получил название elogind (по аналогии с eudev). На elogind даже перешел Devuan, который, напомню, принципиально не использует systemd; но об этом немного позже.

journald представляет собой сервис журналирования событий. Этот компонент, в свою очередь, является отличным примером того, как разработчики systemd не только решили задачу, которая давно не нуждалась в решении, но и решили ее по-своему. Двумя основными отличиями journald от различных реализация syslogd, которые много лет занимались задачами журналирования в Unix, являются использование криптографиче­ских средств для гарантирования неизменности и целостности накопленных логов и хранение этих логов в двоичном виде. Традиционно логи на Unix-серверах хранятся в текстовом виде, поэтому хранение логов в двоичном виде воспринимается как недостаток, который обесценивает любые достоинства journald, даже такие крутые, как гарантию неизменности и целостности логов. Подробнее о journald можно узнать из LXF191/192 и LXF199.

Появление Devuan

В конце 2013-го – начале 2014-го Debian в очередной раз вернулся к актуальной для себя задаче – переходу на более современную систему инициализации. В каче­стве кандидатов рассматривались Upstart и systemd, и по результатам голосования победила последняя. Следом за Debian пошла Ubuntu.

По итогам интеграции systemd в Debian дистрибутив не только перешел на новую систему инициализации, но и оказался сильно завязанным на системном менеджере, который был призван управлять всеми аспектами работы системы. В итоге, systemd был поставлен в один ряд с ядром и стандартной библиотекой языка C, для которых в дистрибутиве не предусмотрены альтернативы. Jessie стал первым выпуском Debian, который не мог функционировать без systemd. Таким образом, группа разработчиков Veteran Unix Admins, которые были не согласны с этой политикой, выпустили в рамках проекта Devuan свободную от systemd версию Jessie. Чтобы этого добиться, разработчикам потребовалось внести изменение в 381 пакет. Так появился первый выпуск Devuan, позволивший пользователям Debian использовать или не использовать systemd в зависимости от их желания.

Второй в истории лидер проекта Debian является пользователем Devaun.

В качестве системы инициализации в Devuan по умолчанию используется SysVinit, которая сейчас более-менее активно развивается. Дело в том, что версия 2.89, выпущенная 28‐го марта 2018-го года, была первой за 8 лет стагнации проекта, но с приходом Джесса Смита [Jesse Smith], который занял пустующее кресло сопровождающего проекта, ситуация резко изменилась.

Различные новостные ресурсы, освещающие достижения открытого и свободного программного обеспечения, позиционируют Devuan как борца за независимость от systemd (отчасти это объясняется тем, что самыми оперативными оказываются информационные источники, пополняемые сообществом, а профессиональные издания, как правило, чуть медленнее реагируют на события и потому постоянно догоняют первых по горячим следам). С одной стороны, это позволило быстро обратить на проект внимание, сделав Devuan звездой мира СПО. С другой стороны, это искажает оригинальные цели проекта – свободе выбора системы инициализации. Сейчас с полной уверенностью можно утверждать, что Devuan добился этой цели: во втором выпуске дистрибутива, известном под кодовым именем ASCII, который вышел 9 июня 2018 г., пользователям помимо SysVinit предлагается OpenRC, которая используется в Alpine Linux и Gentoo.

Заключение

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

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

Имена доверьте авторам

Есть иногда у некоторых проектов такие имена, глядя на которые, не сразу возможно угадать их правильное произношение (под «правильным» я в данном случае подразумеваю принятое в сообществе). Обычно в таких случаях необходимо обратиться к FAQ’у или истории этих проектов. В каче­стве примера на ум приходят web-сервер Lighttpd (читается как lighty) и Nginx (читается как engine-x). (Очень забавно, когда люди с серьезным выражением лица рассказывают о некоем web-сервере под названием Энгинкс.) Но история с именами на этом не заканчивается.

Есть и такие проекты, авторы которых настаивают на строгом написании названий своих детищ. Однако все мы привыкли к тому, что слова, с которых начинаются предложения, пишутся с большой буквы. А еще мы помним, что с заглавной буквы всегда пишутся все имена собственные. Но в школе обычно не учат тому, что всем этим правилам нужно следовать только в том случае, если они не противоречат правилу написания конкретного имени. В каче­стве примеров проектов, с которыми нужно считаться с этой точки зрения, хочу привести ownCloud и, конечно, systemd. Таким образом, в каком бы месте предложения ни стояли эти имена, после какого бы знака препинания не шли – они должны сохранять авторский вариант написания.

В заключение, думаю, что нужно сказать пару слов о том, почему следует писать systemd с маленькой буквы несмотря на то, что это имя собственное. Дело в том, что проект был назван по имени основного исполняемого файла, который запускается первым при загрузке системы, становясь процессом с номером 1 и родителем всех остальных процессов. Традиционно (и тут тоже традиции!) в UNIX и C, родного для этой ОС языка, использовался нижний регистр, поэтому одна из ключевых программ в Linux-подобной операционной системе могла быть названа только systemd, а не Systemd, SystemD или как-то еще.

Leave a Reply

Your email address will not be published. Required fields are marked *