systemd и почему его не любят

В данной статье я попытаюсь комплексно проанализировать причины неприязни к systemd, что заставляет людей от него отказываться и есть ли для этого какие то веские основания.

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

Глава 1. Рождение

1) Ситуация с системами инициализации до появления systemd

Когда-то давно, а точнее в 1979 году, в UNIX 7 был введен init. init выполнял /etc/rc и создавал процессы инициализации терминала и входа для юзера. Спустя время init обрастал новыми функциями (например, монтирование файловых систем, автоматическая очистка /tmp и многое другое). Прогресс не стоял на месте, и к середине 80-х init начал устаревать. Одним из его недостатков была "прямолинейность" и невозможность, к примеру, перезагрузить один из демонов.

Ситуация изменилась с выходом UNIX System V, которая предложила SysVinit, внёсшую понятие уровня выполнения, позволяющее управлять группами демонов одновременно.

Linux перенял SysVinit у UNIX System V, и большинство дистрибутивов использовали его как основной в течение следующих 20 лет.

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

2) Появление и первое внедрение systemd

30 марта 2010 года Леннарт Пёттеринг и Кай Зиверс из корпорации Red Hat представили миру новую подсистему инициализации и управления службами - systemd. Сам продукт был опубликован под лицензией GNU LGPL (Lesser General Public License) версии 2.1.

Огромным плюсом systemd, по сравнению с SysVinit, было распараллеливание запуска служб при старте системы, что значительным образом ускоряло загрузку операционной системы. Также было введено понятие - "модуль", как основная единица для управления СИ. Каждый модуль отвечал за отдельную службу, точку монтирования, файл подкачки и так далее.

Также systemd позволял контролировать состояние службы, ввёл cgroups для отслеживания системных процессов и многие революционные, на 2010 год, моменты.

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

Первый дистрибутив, начавший использование systemd, - Fedora. Уже в июле 2010 года его взяли за основу в Fedora Rawhide. Проблемы были, и их было довольно много. Некоторые разработчики были обеспокоены обратной совместимостью с некоторыми программными компонентами. Однако боевой характер Пёттеринга убедил команду Fedora выпустить Fedora 14 с systemd.

Глава 2. Тотальный захват

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

Так, в августе 2012 года один из известнейших дистрибутивов Linux, Arch Linux, перешёл на systemd, тем самым дав зелёный свет другим разработчикам. В период с сентября 2012 большая часть дистрибутивов отказалась от SysV.

Ближе к концу 2013 года оставались 2 последних, самых распространённых дистрибутива в то же время - Debian и его дериватив Ubuntu. Важно отметить, что в период с октября 2013 по февраль 2014 года были попытки, можно сказать, насильного внедрения systemd в Debian. Огромный пласт разработчиков, работающих, зачастую, в коммерческих корпорациях, таких как Red Hat, Microsoft, Google, очень активно выступали за внедрение нового системного компонента. Забавный факт, что в будущем практически те же люди проголосуют за отстранение Ричарда Столлмана с поста в совете FSF (Фонда свободного программного обеспечения).

В итоге, один из важнейших дистрибутивов, 11 февраля 2014 года, официально принял systemd как основную систему инициализации. Следующий релиз Debian вышел уже с systemd в качестве менеджера системы, и вслед за ним также поступила Ubuntu.

На начало 2024 года самыми популярными дистрибутивами с systemd являются:

1. Arch Linux
2. Fedora
3. Debian
4. openSUSE
5. Ubuntu

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

Глава 3. Причины неприязни

1) Недоверие продукту Red Hat

Red Hat, пожалуй, компания, которая внесла самый большой вклад в развитие Linux. Они занимаются как поддержкой существующего софта, так и разработкой нового, например: PipeWire, Wayland (благодаря команде GNOME, многие участники которой работают в Red Hat).

Однако, по мнению некоторых фанатиков, это не причина для уважения. Есть факт, что корпорация Red Hat является одним из главных подрядчиков АНБ (Агентство национальной безопасности США) и часто берёт у них заказы на выполнение. Например, продажи лицензий на RHEL, разработка определенного вида софта и так далее. Это может создать впечатление, что Red Hat - компания, полностью подвластная правительству Соединённых Штатов. По интернету гуляет мнение, что systemd был разработан в качестве бэкдора для Linux систем, чтобы следить за каждым пользователем свободного ПО. Эти опасения особенно подогрели опубликованные Эдвардом Сноуденом данные о тотальной слежке за гражданами практически любой страны мира. К сожалению, полностью отрицать такой расклад событий нельзя. Но меня всё же смущает то, что systemd имеет полную открытую лицензию, что позволяет провести полный анализ системы инициализации вручную. Такие ужасные подозрения ни разу не подтвердились, конечно же, но можем ли мы вообще кому-то доверять?

2) Раздутость кодовой базы и общая неповоротливость

systemd очень часто критикуют за раздутость кодовой базы. Некоторые даже называют её "специально раздутой". В ней содержится более 2 миллионов строк кода, что увеличивает вероятность ошибок. Проведение аудита безопасности и выявление ошибок становится довольно трудоемким процессом. Например, OpenRC имеет значительно более компактный размер (около 500 тысяч строк кода), что упрощает процедуру аудита.

Также systemd очень раздут функциональностью. Он управляет журналированием, монтированием, отслеживанием и многими другими вещами, которые система инициализации обычно не должна осуществлять самостоятельно. Его превратили в огромный комбайн, который контролирует множество аспектов системы. Это может быть удобно для кого-то, но для меня система инициализации должна в первую очередь инициализировать userspace, после чего может оставаться в стороне. Но это всего лишь мои размышления.

3) Скорость запуска

Это аргумент, который часто упоминают особенно при работе на старых машинах. systemd действительно не самый быстрый, но и OpenRC не сильно опережает его. Поскольку systemd содержит в себе множество компонентов, их запуск требует определенного времени. В сравнении с другими, он действительно один из самых медленных.

По результатам моих тестов, список скорости примерно такой:

1. s6 и dinit
2. runit и OpenRC
3. systemd
4. SysVinit

Я проводил сравнения на Artix и Arch Linux, соответственно. На моей машине разница не так заметна, но на слабых системах лучше выбрать что-то более легковесное.

4) "Бородатый скрипты" или нежелание сис.админов что то менять

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

5) Слишком высокие полномочия и дыры в безопасности

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

В течение жизненного срока systemd было обнаружено колоссальное количество ошибок. Только на официальном гитхабе закрыто около 9 тысяч ошибок, и ещё 2 тысячи остаются открытыми.

Главный разработчик systemd, Ленарт Пёттеринг, очень чувствительно реагирует на замечания, и случались обвинения пользователей в "неблагодарности" со стороны Пёттеринга. Многие ошибки остаются незакрытыми очень долгое время, что вызывает недоумение у сообщества.

6) Отступление от UNIX-way

Как писал выше - systemd очень раздули. Это полностью противоречит эфимерной философии UNIX - "Делай одну вещь и делай её хорошо". Очень много фанатов, так называемого UNIX-wa'я, твердят про эту эту проблему. Команда suckless (разработчики такие) вообще предложила свой sinit, который по их мнению полностью соответствует философии UNIX. Ни в каком дистрибутиве не представлен, но если интересно, то можете поизучать и поставить в условный Артикс.

Глава 4. Альтернативы

1) Какие бывают системы инициализации?

На первый взгляд альтернатив systemd нет, но это далеко не так. Самыми простыми, по моему мнению, являются OpenRC или dinit. Последний по синтаксису очень схож с systemd (вместо systemctl - dinitctl). Если хотите что-то более уникальное, то можно попробовать s6 или runit. SysVinit неплохо представлен в Devuan и MX Linux, потому там его можно заценить на полную, так скажем.

2) В каких дистрибутивах пробовать другие системы инициализации?

Есть наверное 4 мастодонта в мире non-systemd:

1. Gentoo и gentoo-based (OpenRC)
2. Devuan (SysVinit, runit, OpenRC)
3. Artix (dinit, OpenRC, runit, s6)
4. Void (runit)

Эти дистрибутивы предоставляют самый приятный опыт работы без systemd. Можно, конечно, попробовать Slackware или Crux, но там опыт будет явно посложнее чем в Devuan.

3) Стоит оно того?

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

Если у вас есть что то дополнить, то прошу писать в комментарии. Так мы сможем создать полную картину. Спасибо за прочтение!