Оценка плюсов и минусов при переходе Debian на systemd или upstart

[Malaheenee]

Под бой курантов на opennet появилась интересная новость:
Два участника Технического комитета 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 имеют явно напряжённый характер.

Срач там в комментах идет нехилый, поэтому давайте не будем его разводить здесь (любые высказывания в этом стиле будут удаляться без права обжалования).

А займемся конструктивным "дележом опытом" по установке и настройке этих двух систем инициализации.

[Yrii]

Честно пишу, что не ставил, пока наблюдаю... пока мне кажется systemd хочет заменить собой "всё", что как бы не unix way...
пользы от upstart в debian уже с этой стороны:

Адаптация Upstart для работы в Debian GNU/kFreeBSD и Debian GNU/Hurd выглядит вполне реальной задачей, что нельзя сказать о systemd.

поболее...

При использовании upstart дистрибутив становится зависим от Canonical, без поддержки которой upstart останется без разработчиков и будет обречён на стагнацию

тут спорно ибо можно форкнуть и поддерживать своими силами (как и весь дистрибутив) ...тем более Canonical, как мне кажется, больше зависит от debian...
вообщем наблюдаем

[vladimir_ar]

Уже с пол-года как перешел на systemd - и переход практически безболезненный, и он достаточно понятен. И для него уже все подготовлено. При попытке просто тупо (как, собственно, пробы и с systemd) в виртуальной машине перейти на upstart - получил полностью неработоспособную незагружающуюся систему. При переходе на systemd - никаких проблем.

[Malaheenee]

vladimir_ar, после беглого гугления выясняется, что ни polkit ни consolekit не нужны для systemd. У Вас они остались?

Хотя Арчвики вещает, что polkit все же нужен.

[Brainey]

Уже не помню, почему, но upstart показался мне глючным ещё в ubuntu 9-х, 10-х версий.

[Malaheenee]

Из новостей в тему - Siduction перешел на systemd. Скачали, потестили на виртуалке с Гномом. Вроде живет и даже памятью не давится.

[vladimir_ar]

что ни polkit ни consolekit не нужны для systemd. У Вас они остались?

Скажем так  - специально не удалял. Если были - то и остались.
Сообщение объединено: 01 января 2014, 20:50:58

aptitude search

vladimir-7@GNU-HOME:~$ aptitude search consolekit
i A consolekit                      - framework for defining and tracking users,
p   consolekit:i386                 - framework for defining and tracking users,
vladimir-7@GNU-HOME:~$ aptitude search polkit
p   gir1.2-polkit-1.0               - GObject introspection data for PolicyKit 
p   gir1.2-polkit-1.0:i386          - GObject introspection data for PolicyKit 
i A libpolkit-agent-1-0             - PolicyKit Authentication Agent API       
p   libpolkit-agent-1-0:i386        - PolicyKit Authentication Agent API       
p   libpolkit-agent-1-dev           - PolicyKit Authentication Agent API - devel
p   libpolkit-agent-1-dev:i386      - PolicyKit Authentication Agent API - devel
i A libpolkit-backend-1-0           - PolicyKit backend API                     
p   libpolkit-backend-1-0:i386      - PolicyKit backend API                     
p   libpolkit-backend-1-dev         - PolicyKit backend API - development files
p   libpolkit-backend-1-dev:i386    - PolicyKit backend API - development files
i A libpolkit-gobject-1-0           - PolicyKit Authorization API               
p   libpolkit-gobject-1-0:i386      - PolicyKit Authorization API               
p   libpolkit-gobject-1-dev         - PolicyKit Authorization API - development
p   libpolkit-gobject-1-dev:i386    - PolicyKit Authorization API - development
c   libpolkit-qt-1-1                - PolicyKit-qt-1 library                   
p   libpolkit-qt-1-1:i386           - PolicyKit-qt-1 library                   
p   libpolkit-qt-1-dev              - PolicyKit-qt-1 development files         
p   libpolkit-qt-1-dev:i386         - PolicyKit-qt-1 development files         
p   lxpolkit                        - LXDE PolicyKit authentication agent       
p   lxpolkit:i386                   - LXDE PolicyKit authentication agent       
p   lxpolkit-dbg                    - LXDE PolicyKit authentication agent (debug
p   lxpolkit-dbg:i386               - LXDE PolicyKit authentication agent (debug
p   polkit-kde-1                    - KDE dialogs for PolicyKit                 
p   polkit-kde-1:i386               - KDE dialogs for PolicyKit           

[свернуть]

[Malaheenee]

vladimir_ar,
[ot]при таком поиске полезно использовать приставку ~i (aptitude search ~ipolkit), тогда он выведет только установленные  .[/ot]

[vladimir_ar]

Malaheenee, можно попробовать удалить на подопытной системе на USB-HDD. Если они не нужны - все будет и так работать.
Сообщение объединено: 02 января 2014, 14:45:41
Malaheenee, если вот так просто в лоб (удалил), то - без сonsolekit не стартуют Х-ы, а без policykit-1 не работает монтирование дисков по запросу (с вводом пароля) в файловом менеджере (nautilus).
Сообщение объединено: 02 января 2014, 14:49:24
Нужно разбираться как задействовать logind из состава systemd
Сообщение объединено: 02 января 2014, 17:29:54
Без consolekit работает.
Только нужно в (в моем случае, использую openbox) ~/.xinitrc удалить ck-launch-session.

[redVi]

мне кажется systemd хочет заменить собой "всё"

Так и есть. Вместо юниксового "разделяй и властвуй" Поттерингоподелка претендует на универсальность и разделения полномочий не признаёт.

[Malaheenee]

Да, вдогонку - в репах экспериментальной ветки появился openrc. Так что выбор для конечного пользователя стал еще шире (ну да, openrc совсем не замена, но тем не менее).
А siduction халтурщики - и sysv оставили и systemd воткнули.

[redVi]

Openrc отличная вещь! Там всё просто и логично. А почему "совсем не замена"?
Я думаю, будущее системы инициализации будет определено тем, что включат мейнтейнеры при новой установке дистрибутива по-умолчанию (или будут предлагать выбор? вряд ли). Большинству пользователей всё равно, что там под капотом, предложенное менять не станут.

[Malaheenee]

redVi, во всяком случаем мы так читали, что openrc не заменяет, а дополняет init.  Идею относительно выбора системы инициализации (СИ) в установщике (как это сделано с ядром) мы уже тут предлагали, осталось самим разработчикам предложить  . Только затык получается в том, что каждый пакет, который имеет стартующие сервисы (типа апача или даже laptop-mode-tools) нужно будет пересобирать для поддержки каждой из систем. В том же lmt вон сейчас и sysv-скрипт и systemd-сервис. А если еще upstart и openrc добавить - мэйнтейнеры точно придушат предложившего идею. Далее встает проблема с пометкой "необходимых-неудаляемых" пакетов. Настолько глубоко рулить конфликтами apt не умеет, тем более если захочется иную СИ воткнуть на работающую систему.
Сообщение объединено: 05 января 2014, 21:12:31
vladimir_ar, а udisks какой установлен? 2-й вроде имеет поддержку systemd.

[redVi]

каждый пакет, который имеет стартующие сервисы нужно будет пересобирать для поддержки каждой из систем

И если мне не изменяет память как раз по этой причине в ArchLinux кроме окоянного (systemd) ничего не поддерживается. Похоже systemd'изация мира linux необратима.
А если выбирать из двух зол, то расклад таков:
1. upstart должным образом неисследованное явление системы инициализации народу, насколько стабилен и хорош неизвестно, но иллюзий насчёт него не питаю.
2. systemd страшен тем, что "много на себя берёт" как уже было заявлено выше. Но по нему по крайней мере есть нормальная документация и даже книжка от Самого Поттеринга.
Что выбрать? Наверное, переезд на FreeBSD 

[vladimir_ar]

vladimir_ar, а udisks какой установлен? 2-й вроде имеет поддержку systemd.

Первый.