Леннарт Поттеринг (Lennart Poettering) опубликовал объёмную статью, в которой попытался опровергнуть 30 типичных мифов, связанных с системным менеджером systemd.

1. Миф: systemd является монолитом.
   - Леннарт считает что это неправда, поскольку при полной сборке всех компонентов systemd создаётся 69 различных исполняемых файлов, каждый из которых отвечает за решение своей задачи. При этом большая часть данных исполняемых файлов может использоваться обособленно, без привязки к systemd. Целью разбиения функциональности на отдельные исполняемые файлы произведено, например, для решения таких задач, как более полное разделение привилегий (каждый процесс снабжается привилегиями только для выполнения узких задач) и обеспечение параллельного выполнения операций в процессе загрузки.
2. Миф: главной целью systemd является скорость.
   - По мнению Леннарта, высокая скорость systemd - это всего лишь побочный результат правильного дизайна и архитектуры проекта. Разработчики специально не занимались выжиманием всей возможной производительности из кода. Более того в некоторых ситуациях разработчики предпочитают более читаемый код, чем немного более быстрый и запутанный.
3. Миф: скорость загрузки, предоставляемая systemd, не востребована на серверах.
   - Леннарт отмечает что многие системные администраторы напротив желают минимизации простоев (downtime) при выполнении обслуживания серверов. Кроме того, скорость старта востребована в облачных системах и на виртуальных машинах. Также критична скорость восстановления после сбоя систем высокой доступности.
4. Миф: systemd не совместим с shell-скриптами.
   - На самом деле он совместим, просто сами разработчики systemd не пользуются shell-скриптами в процессе загрузки, чтобы не терять преимущества systemd. Тем не менее, systemd позволяет запускать скрипты, написанные на любых языках программирования, как сервисы systemd.
5. Миф: освоить systemd сложно.
   - По мнению Леннарта это не так, поскольку это унифицированная платформа, язык файлов конфигурации прост и предоставляется типовой набор утилит. Тем не менее, Леннарт согласен с тем, что некоторое обучение работе с systemd все-таки требуется.
6. Миф: Systemd не модульный.
   - Это не так: в сборочном скрипте configure есть ряд ключей, позволяющих указать какие именно части systemd требуется собрать. Таким образом выбор предоставляемых возможностей осуществляется на этапе сборки.
7. Миф: Systemd появился как результат синдрома NIH (Not Invented Here, создание собственного решения вместо использования уже существующих аналогов).
   - Изначально у разработчиков была идея использовать проект Upstart от фирмы Canonical, однако постепенно разработчики пришли к выводу, что у него есть ряд значительных недостатков в базовых основах дизайна, которые достаточно проблематично исправить. Наиболее крупным просчетом по мнению Леннарта является то, что upstart сам по себе не заботится о зависимостях сервисов и переносит заботу об этом аспекте на плечи администраторов и разработчиков.
8. Миф: systemd - проект FreeDesktop.org.
   - FreeDesktop.org используется в основном как инфраструктура хостинга.
9. Миф: systemd далёк от философии UNIX.
   - В systemd используется множество концепций UNIX, напрмер, идея "всё есть файл" реализована в доступе ко всем сервисам systemd осуществляется через файловую систему cgroupfs. Встроенная поддержка подключения нескольких рабочих мест к одному компьютеру выражается в поддержке multi-seat и возможности автоматической настройки подключаемого оборудования. Основу systemd составляет набор связанных через стандартные интерфейсы утилит, каждая из которых решает свою задачу.
10. Миф: Systemd сложно устроен.
    - Леннарт частично согласен с этим тезисом, однако отмечает, что это связано с тем что современные компьютеры стали сложными. Тем не менее, Леннарт считает, что systemd проще и содержит меньше избыточности и зависимостей, чем эквивалентные по возможностям решения.
11. Миф: Systemd чрезмерно тяжелый и перегруженный.
    - Systemd вероятно является как раз обратным примером. Он модульный, предоставляет много функциональности, а требуемые зависимости включают в себя лишь Glibc, libcap и DBus.
12. Миф: Systemd создан только для Linux и не может использоваться в BSD-системах.
    - По мнению Леннарта, основной причиной данной ситуации является то, что разработчики систем на основе BSD не заинтересованы в данной системе инициализации, так как исторически ядра BSD-систем развивались одновременно с пользовательским окружением вокруг них и данные системы имеют собственные системы инициализации, жестко привязанные к особенностям каждому BSD-проекту.
13. Миф: Systemd не сможет использоваться по умолчанию в Debian, так как он поддерживает только ядро Linux.
    - Леннерт отмечает, что работа по одновременному сопровождению unit-файлов systemd и классических init файлов является номинальной и незначительной по объему на фоне столь масштабной работы как внедрение в систему поддержки ядер, отличных от Linux.
14. Миф: Systemd можно портировать для других ядер, если мэйнтейнеры этих ядре этого пожелают.
    - Systemd слишком завязан на возможности и интерфейсы, доступные только в ядре Linux. В некоторых ядрах имеются аналоги подобных интерфейсов, некоторые возможности можно отключить, но все необходимые функции вряд-ли удастся обеспечить в ядрах, отличных от Linux. Среди активно используемых в Systemd возможностей: cgroups, fanotify, umount2(), /proc/self/mountinfo, /dev/swaps, udev, netlink, /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces, prctl(), ioctl, системный вызов mount(), selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input и т.п.
15. Миф: Systemd не является переносимым (Not Portable) без каких либо на то причин.
    - Это не так! Systemd просто использует специфичную для Linux функциональность чтобы реализовывать все что хотели сделать разработчики. У Linux столько возможностей, что остальные unix/posix системы попросту не предоставляют каких либо аналогов для многих из них, в то время как разработчики systemd желают дать в руки пользователей данные возможности.
16. Миф: Systemd использует конфигурационные файлы в бинарном формате.
    - В Systemd используются только простые и легко редактируемые вручную текстовые файлы конфигурации. Никакого XML и тем более бинарных форматов.
17. Миф: Systemd содержим избыточную функциональность.
    - Systemd изначально не ограничивался только системой инициализации и развивается как набор кирпичиков для построения ОС. Какие именно из возможности использовать решает пользователь, большая часть функций отключается на этапе сборки или в процессе работы.
18. Миф: Systemd заставляет кого-то что-то делать.
    - Программы - не мафия. Они не могут никого заставить что-либо делать против их воли. В Free Software каждый добровольно делает то, что считает нужным.
19. Миф: Systemd не позволяет использовать Syslog.
    - Это не так. Хотя у systemd есть свой метод ведения журналов, разработчики предприняли усилия чтобы сохранить полную совместимость с более традиционным syslog.
20. Миф: Systemd ни с чем не совместим.
    - Разработчики Systemd делают всё вохможное чтобы обеспечить наилучшую возможную совместимость с sysvinit. Большинство init-скриптов могут быть использованы с Systemd без необходимости внесения в них изменений. Имеющиеся несовместимости хорошо документированы.
21. Миф: К Systemd невозможно обращаться из скриптов из-за использования D-Bus.
    - Systemd предоставляет обширный набор утилит (systemctl, loginctl, timedatectl, hostnamectl, localectl) со всевозможными опциями, являющимися аналогами вызовов D-Bus, которые можно запускать из скриптов для автоматизации выполнения различных задач. Кроме того, нет никаких проблем с обращению к D-Bus из скриптов при помощи таких утилит как dbus-send и gdbus.
22. Миф: Systemd вынуждает использовать дополнительные конфигурационные утилиты вместо непосредственной правки файлов конфигурации.
    - Это не так. Конфигурационные утилиты предоставляют только дополнительную функциональность, такую как автодополнение имён директив конфигурации, но никто не заставляет обязательно их использовать. Пользователь может реализовать все действия через прямую правку файлов конфигурции с последующим ручным перезапуском связанных с ними процессов.
23. Миф: Systemd нестабилен и изобилует ошибками.
    - Этот тезис не подтверждается багтрекером системы Fedora.
24. Миф: Systemd трудно отлаживать.
    - В Systemd предусмотрен специальный отладочный интерфейс с поддержкой интерактивной отладки, отслеживания состояния, отключения компонентов при загрузке.
25. Миф: В Systemd изменения вносятся ради изменений.
    - Это не так, каждое вносимое в Systemd имеет техническое обоснование и разработчики по возможности стараются донести до общественности причины тех или иных изменений в wiki, блогах, документации и других источниках. Нарушающие совместимость изменения вносятся только в крайних случаях и явно документируются.
26. Миф: Systemd является проектом только компании Red Hat, которая использует трудоустроенных разработчиков для распространения своего мировоззрения.
    - Это не так, из 16 ведущих разработчиков Systemd только 6 работает в Red Hat, а остальные представляют такие проекты и компании как ArchLinux, Debian, Intel, Canonical, Mandriva, Pantheon.
27. Миф: Systemd не позволяет отделить /usr от корневой директории.
    - С самого начала systemd поддерживает опцию сборки "--with-rootprefix=", которая позволяет выделить необходимые для начальной стадии загрузки компоненты и установить их в корень или любою другую директорию. Хоть разработчики systemd и не считают загрузку без /usr хорошей идее, такая возможность поддерживается из коробки.
28. Миф: Systemd не позволяет заменять свои компоненты.
    - Это не так, большая часть возможностей Systemd может быть отключена и заменена на альтернативные реализации.
29. Миф: Использование D-Bus вместо сокетов делает Systemd непрозрачным.
    - D-Bus использует сокеты в качестве транспорта, но при этом предоставляет стандартизованный механизм сериализации сообщений, отправляемых через сокеты. Так как методы сериализации хорошо документированы и имеются штатные утилиты трассировки, то использование D-Bus наоборот делает систему более прозрачной, что нельзя сказать о многих Unix-демонах, которые использовали собственные протоколы для обмена данными.