| Участник проекта Debian Майкл Штапельберг (Michael Stapelberg) ответил на критику systemd, высказанную другими разработчиками в рамках проведённого в конце мая опроса. В своём блоге Майкл попытался опровергнуть аргументы, традиционно выдвигаемые против systemd.
 systemd имеет много зависимостей.
 Для опровержения этого аргумента был приведён отдельный документ,
 включающий в себя список зависимостей пакета systemd и его исполняемого
 файла. В частности в нём видно, что большинство библиотек уже есть в 
среднестатистической системе и потребуется очень мало дополнительных 
библиотек. Также он приводит список возможных проблем с зависимостями:
  1. Циклические зависимости.
Майкл упоминает о том, что systemed зависит от DBus, тогда как тот 
сам должен быть загружен системой инициализации, что потенциально может 
быть источником проблем. Однако systemd не зависит от dbus-daemon, а использует интегрированную минимальную реализацию.
 2. Усложнение кода.
Здесь автор приводит ссылку на фрагмент кода systemd с целью показать его читаемость и простоту.
 3. Зависимость от большого количества библиотек. 
Автор утверждает, что большинство библиотек уже активно используются 
такими программами, как DBus, Udev, SELinux, libcap, pcre и т.п., 
поэтому установка пакета приведёт к установке лишь небольшого числа этих
 библиотек на обычной системе (всего около 10 пакетов).
 4. systemd использует больше памяти, чем sysvinit. 
В качестве опровержения этого утверждения, разработчик пишет, что 
большинство библиотек уже загружено в память и systemd в худшем случае 
загрузит около 500 кБ дополнительных библиотек, что является небольшой 
ценой за предоставленные возможности и актуально разве что в нише 
встраиваемых систем, где systemd всё равно не слишком необходим 
(примечание переводчика).
 systemd перегружен функциональностью и является bloatware. 
 Майкл отсылает критиков к статье на Wikipedia
 с определением bloatware как программы, замедляющейся и разрастающейся 
от релиза к релизу. В качестве контраргумента он утверждает, что systemd
 работает быстрее, чем sysvinit и занимает памяти всего на 1 мБ больше, а
 также на то, что функциональность systemd разбита по небольшим 
отдельным бинарным файлам.
 systemd делает слишком много вещей.
 Автор согласен с этим утверждением, однако предлагает 
воспринимать его как положительную черту - это открывает множество 
дополнительных способов использования, а также использование на широком 
спектре устройств. Кроме того упоминается, что не обязательно 
использовать все возможности systemd, которые разбиты по разным файлам и
 иногда даже разным пакетам.
 systemd слишком усложнён.
 Здесь Майкл предлагает сравнить монолитное ядро Linux с systemd и
 микроядро Minix с sysvinit, а также упоминает, что не унифицированные и
 дублирующие друг друга скрипты на Shell порой более сложны и медленны, а
 также вызывают больше проблем, чем обычный код на языке C.
 Вывод.
Из написанного выше, автор делает вывод - критики systemd во 
многом правы, но иногда следует посмотреть на вещи с положительной 
стороны и увидеть, что systemd просто старается сконцентрировать в одном
 месте усложнённость множества различных init-скриптов, оставив 
сложности внутри себя, а простой, но в то же время гибкий интерфейс - 
снаружи. В итоге, упрощается работа мэйнтейнеров пакетов по написанию 
сервисных файлов (аналог скриптов инициализации) и предоставляются 
целостные и надёжные средства для управления сервисами. Systemd заметно 
отличается от sysvinit, а альтернативные подходы первое время часто 
кажутся усложнёнными. То, что systemd потребляет больше ресурсов, чем 
sysvinit, компенсируется задействованием данных ресурсов для учёта 
большей информации о сервисах, а более детализированный контроль 
состояния позволяет администратору более глубоко контролировать работу 
служб. 
 |