> Да, но:
> 1. systemd тоже разбирает конфиги.
> 2. в 90% случаев вся интерпретация в шеле сводится к запуску конкретного
> бинарника systemd не надо интерпретировать команды. Соответственно, ему не надо в голове иметь интерпретатор / виртуальную машину. Формат unit-файла чётко специфицирован. В нём могут встречаться только определённые ключевые слова и только в определённом месте. В результате есть возможность при старте системы прочитать все значения параметров, сохранить их в структуру, и больше не заниматься парсингом и т.п.
>> systemd выигрывает за счёт двух вещей:
>> 1) Отсутствие или сведённое к миниумму количество shell-скриптов (всё в unit-файлах в
>> виде параметров, а не в виде результатов работы внешних команд)
> Но по факту он должен производить те же манипуляции, что и shell
> команды. В теории он может иметь выигрыш за счет меньшего количества
> процессов, но у него есть и собственные накладные расходы в виде
> cgroups/dbus и Поттеринг знает еще чего.
systemd не нужно, например, по десять раз инициализировать разделяемые библиотеки, что происходит при запуске шелла. Напшите ldd /bin/ваш-любимый-шелл. Сколько разделяемых библиотек могут захотеть проинициализироваться при старте процесса?
>> 2) Параллельность
> У меня это решается так:
> nice -n 19 /etc/init.d/background &
Это выглядит более похоже на костыль, чем на решение. Как вы определяете зависимости между сервисами? Как избегаете race condition'ов? На глаз? В случае с systemd можно прописать зависимости декларативно.
У systemd есть ещё плюс -- активация сервиса через сокет (socket based activation). Например, вы можете настроить систему так, чтобы sshd не запускался до первого соединения (нечто похожее на inetd).
