А давайте всё-таки начнём поцтеросрачик?
Я понимаю, конечно, что непятница, но надо завершать начатое.

Я горячий финский парень пользуюсь systemd почти с того самого момента, как она была включёна в состав Debian Unstable. К тому моменту говны уже вовсю бурлили, и мне стало любопытно, каким же должен быть софт, взорвавший столько пуканов. Выбрав свободный вечер, я решительно крутанул барабан и спустил курок снёс systemv-init и установил systemd и systemd-sysv. И что же?

К моему великому разочарованию, система просто перезапустилась и продолжила работу. Только “/proc/1/comm” говорил мне “systemd” вместо “init”.

Потом я практически забыл про systemd на несколько месяцев и вспомнил только тогда, когда взбесившийся DVD-привод начал подмораживать примерно каждый четвёртый запуск. Как ни странно, мне удалось разобраться в системе отладки скриптов, а systemd-bootchart помогла мне косвенно вычислить виновника траблов.

Надо сказать, что от самого systemd проблем я так и не увидел.

Тогда я решил, что если с самим systemd всё OK, то не иначе как пуканы взрывает сам Поттеринг. Но и тут облом: вежливый, интеллигентный паренёк в очочках одной рукой с переменным успехом отмахивается от троллей, другой − участвует в документировании и продвижении systemd, и скилл техписательства у него вкачан явно лучше, нежели троллфидинга троллфайтинга.

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

Ну что, начнём?

1. Не UNIX-way. Это идеологический, а не технический аргумент. Отклоняется.


2. Бинарные логи. Тут есть и минусы, касающиеся форензик-использования. Но есть и плюсы: логи компактны и позволяют упростить и стандартизовать парсинг. Так что это не однозначный минус. Вывод же загрузочной информации в консоль никто не отменял, равно как и dmesg.


3. Зачем придумывать новую систему инициализации, когда есть проверенная временем system V init? Работает − не лезь! Ну, сказать про систем-пять «работает» можно лишь с большой натяжкой. Во-первых, чтобы запустить сервис, вам требуется написать программу на языке bash. Нет, я не ненавижу bash, я подучил его не в последнюю очередь благодаря необходимости писать инит-скрипты и не раз использовал его для всякой малой автоматизации. Но согласитесь, что танцы с bash несколько отвлекают нас от основной задачи − запустить этого долбаного демона! Во-вторых, скрипты будут различны для каждого дистрибутива, что не прибавляет уверенности в будущем. Про невозможность конкурентной загрузки я уже молчу: можно и зайца научить зажигать спички, и многопоточный сервер на bash написать, но это уже будет за гранью разумного. В общем, system V init давно уже пора было на пенсию, и systemd, upstart, openrc и прочие появились не из-за NIH-синдрома, а из сугубой необходимости.


4. Зачем навязывать systemd, если есть другие замечательные системы инициализации, например, upstart (openrc, launchd, smf, bolgen-init и т. д.)? Если кто-то приставлял мейнтейнерам разных дистрибутивов пистолет к виску и приказывал дропнуть проддержку всех 100500 замечательных систем инициализации ради systemd, то пусть этим вопросом занимается полиция. Я в этом не компетентен и меня это не интересует. Правда, последнее время мне кажется, что никакого пистолета у виска и не было: systemd победил по принципу “Survival of the fittest”. Но это опять же не технический вопрос.


5. Куда пропали мои .core? Это поведение systemd можно настроить так, что всё вернётся на свои места. В общем случае, централизованное управление дампами памяти имеет свои профиты в смысле безопасности.

NB! Пост может обновляться/редактироваться.