LinuxDoc.RuДва участника Технического комитета Debian, которому делегировано принятие решения по выбору системы инициализации для будущего выпуска, представили отчёты с анализом целесообразности выбора systemd или upstart. Ян Джексон (Ian Jackson), автор dpkg, в прошлом работавший в компании Canonical, выступил в пользу перехода на upstart. Расс Олбери (Russ Allbery), отвечающий за сопровождение ряда подсистем Debian, попытался доказать необходимость перехода на systemd.
Доводы в пользу upstart:
Upstart более прост для портирования на системы, отличные от Linux, в то время как systemd очень жестко завязан на возможностях ядра Linux. Адаптация Upstart для работы в Debian GNU/kFreeBSD и Debian GNU/Hurd выглядит вполне реальной задачей, что нельзя сказать о systemd;
Upstart более привычен для разработчиков Debian, многие из которых по совместительству участвуют в разработке Ubuntu. Два члена Технического комитета Debian (Steve Langasek и Colin Watson) входят в состав группы разработчиков Upstart.
Upstart проще и легковеснее systemd, как следствие, меньше кода - меньше ошибок;
Upstart лучше подходит для интеграции c кодом системных демонов. Политика systemd сводится к тому, что авторы демонов должны подстраиваться под upstream (для замены компонента systemd следует предоставить аналог, совместимый на уровне внешнего интерфейса), вместо того чтобы upstream предоставлял комфортные средства для разработчиков демонов.
Upstart проще в плане поддержания и сопровождения пакетов;
Сообщество разработчиков Upstart более открыто для совместной работы. В случае systemd придётся принимать методы systemd как должное и следовать им, например, поддерживать отдельный раздел "/usr" или использовать только абсолютные пути для запуска.
Недостатки Upstart относятся к категории поправимых проблем;
В текущем состоянии Upstart уже полностью готов для использования в Debian 8.0 (Jessie);
В Upstart более привычная модель определения конфигурации сервисов, в отличие от systemd, где настройки в /etc перекрывают базовые параметры настройки юнитов, определённые в иерархии /lib.
Использование Upstart позволит поддержать здоровый дух конкуренции, который будет способствовать развитию различных подходов и будет держать разработчиков в тонусе.
Systemd слишком монолитен и не предоставляет возможность выбора, поставляя изначально заданный набор базовых сервисов (например, замену cron, syslog, inetd), в то время как Upstart больше соответствует позиционированию системы инициализации как связующей прослойки между различными программными проектами.
Upstart больше проверен временем, в то время как systemd развивается слишком динамично без уделения должного внимания обратной совместимости и не исключая подключения новых зависимостей.
Доводы в пользу systemd:
Systemd опережает Upstart по возможностям и продуманности архитектуры. Без существенной переработки архитектуры Upstart не сможет догнать systemd по функциональности (например, перевёрнутая модель запуска зависимостей (вместо запуска всех требуемых зависимостей при старте заданного сервиса, запуск службы в Upstart осуществляется при поступлении события о готовности к работе зависимостей); использование ptrace мешает применению upstart-работ для таких демонов, как avahi, apache и postfix; возможность активации службы только по факту обращения к сокету, но не по косвенным признакам, таким как зависимость от активации другого сокета; отсутствие надёжного отслеживания состояний выполняемых процессов).
Systemd содержит относительно самодостаточный набор компонентов, что позволяет сосредоточить внимание на устранении проблем, а не доработке конфигурации с Upstart до возможностей, уже присутствующих в Systemd. Например, в Upstart отсутствуют: поддержка детального статуса и ведения лога работы демонов, множественная активация через сокеты, активация через сокеты для IPv6 и UDP, гибкие средства ограничения ресурсов.
Использование systemd позволит сблизить между собой и унифицировать средства управления различными дистрибутивами. На systemd уже перешли Fedora, openSUSE, Sabayon, Mandriva, Arch Linux, кроме того systemd будет применён в будущих выпусках RHEL и SUSE Linux.
У systemd более активное, крупное и разноплановое сообщество разработчиков, в которое входят инженеры компаний SUSE и Red Hat. При использовании upstart дистрибутив становится зависим от Canonical, без поддержки которой upstart останется без разработчиков и будет обречён на стагнацию (невозможно предугадать останется Ubuntu на upstart или нет). Для участия в разработке upstart требуется подписание соглашения о передаче имущественных прав компании Canonical.
Компания Red Hat не без повода решилась на замену upstart на systemd. Существует опасение, что перейдя на upstart проект Debian через 2-3 года вынужден будет мигрировать на systemd.
Для реализации некоторых возможностей загрузки в Upstart требуется использовать фрагменты shell-скриптов, что делает процесс инициализации менее надёжным и более трудоёмким для отладки.
Поддержка systemd реализована в GNOME и KDE, которые все более активно используют возможности systemd (например, средства для управления пользовательскими сеансами и запуска каждого приложения в отдельном cgroup). GNOME продолжает позиционироваться в качестве основного окружения Debian, но отношения между проектами Ubuntu/Upstart и GNOME имеют явно напряжённый характер.
Доводы в пользу upstart:
Upstart более прост для портирования на системы, отличные от Linux, в то время как systemd очень жестко завязан на возможностях ядра Linux. Адаптация Upstart для работы в Debian GNU/kFreeBSD и Debian GNU/Hurd выглядит вполне реальной задачей, что нельзя сказать о systemd;
Upstart более привычен для разработчиков Debian, многие из которых по совместительству участвуют в разработке Ubuntu. Два члена Технического комитета Debian (Steve Langasek и Colin Watson) входят в состав группы разработчиков Upstart.
Upstart проще и легковеснее systemd, как следствие, меньше кода - меньше ошибок;
Upstart лучше подходит для интеграции c кодом системных демонов. Политика systemd сводится к тому, что авторы демонов должны подстраиваться под upstream (для замены компонента systemd следует предоставить аналог, совместимый на уровне внешнего интерфейса), вместо того чтобы upstream предоставлял комфортные средства для разработчиков демонов.
Upstart проще в плане поддержания и сопровождения пакетов;
Сообщество разработчиков Upstart более открыто для совместной работы. В случае systemd придётся принимать методы systemd как должное и следовать им, например, поддерживать отдельный раздел "/usr" или использовать только абсолютные пути для запуска.
Недостатки Upstart относятся к категории поправимых проблем;
В текущем состоянии Upstart уже полностью готов для использования в Debian 8.0 (Jessie);
В Upstart более привычная модель определения конфигурации сервисов, в отличие от systemd, где настройки в /etc перекрывают базовые параметры настройки юнитов, определённые в иерархии /lib.
Использование Upstart позволит поддержать здоровый дух конкуренции, который будет способствовать развитию различных подходов и будет держать разработчиков в тонусе.
Systemd слишком монолитен и не предоставляет возможность выбора, поставляя изначально заданный набор базовых сервисов (например, замену cron, syslog, inetd), в то время как Upstart больше соответствует позиционированию системы инициализации как связующей прослойки между различными программными проектами.
Upstart больше проверен временем, в то время как systemd развивается слишком динамично без уделения должного внимания обратной совместимости и не исключая подключения новых зависимостей.
Доводы в пользу systemd:
Systemd опережает Upstart по возможностям и продуманности архитектуры. Без существенной переработки архитектуры Upstart не сможет догнать systemd по функциональности (например, перевёрнутая модель запуска зависимостей (вместо запуска всех требуемых зависимостей при старте заданного сервиса, запуск службы в Upstart осуществляется при поступлении события о готовности к работе зависимостей); использование ptrace мешает применению upstart-работ для таких демонов, как avahi, apache и postfix; возможность активации службы только по факту обращения к сокету, но не по косвенным признакам, таким как зависимость от активации другого сокета; отсутствие надёжного отслеживания состояний выполняемых процессов).
Systemd содержит относительно самодостаточный набор компонентов, что позволяет сосредоточить внимание на устранении проблем, а не доработке конфигурации с Upstart до возможностей, уже присутствующих в Systemd. Например, в Upstart отсутствуют: поддержка детального статуса и ведения лога работы демонов, множественная активация через сокеты, активация через сокеты для IPv6 и UDP, гибкие средства ограничения ресурсов.
Использование systemd позволит сблизить между собой и унифицировать средства управления различными дистрибутивами. На systemd уже перешли Fedora, openSUSE, Sabayon, Mandriva, Arch Linux, кроме того systemd будет применён в будущих выпусках RHEL и SUSE Linux.
У systemd более активное, крупное и разноплановое сообщество разработчиков, в которое входят инженеры компаний SUSE и Red Hat. При использовании upstart дистрибутив становится зависим от Canonical, без поддержки которой upstart останется без разработчиков и будет обречён на стагнацию (невозможно предугадать останется Ubuntu на upstart или нет). Для участия в разработке upstart требуется подписание соглашения о передаче имущественных прав компании Canonical.
Компания Red Hat не без повода решилась на замену upstart на systemd. Существует опасение, что перейдя на upstart проект Debian через 2-3 года вынужден будет мигрировать на systemd.
Для реализации некоторых возможностей загрузки в Upstart требуется использовать фрагменты shell-скриптов, что делает процесс инициализации менее надёжным и более трудоёмким для отладки.
Поддержка systemd реализована в GNOME и KDE, которые все более активно используют возможности systemd (например, средства для управления пользовательскими сеансами и запуска каждого приложения в отдельном cgroup). GNOME продолжает позиционироваться в качестве основного окружения Debian, но отношения между проектами Ubuntu/Upstart и GNOME имеют явно напряжённый характер.
