Чем однозначно ценна сложившаяся ситуация с Debian, так это тем, что заинтересованным лицам становится видна неприглядная заполитизированность и отсталость альтернативных решений, вся ложь их пропонентов. Например, пеняя systemd его зависимостью от Linux, часто говорили, что SysV как раз переносимый. При этом совершенно забыли спросить тех, кто переносил его, например, на Hurd, так ли оно на самом деле? А надо было бы.

Justus Winter, который как раз и переносил SysV на Debian/Hurd в рамках GSoC 2013, высказался по теме в своем блоге. Он с удивлением заметил, что после нескольких месяцев, которые он на глазах у всего OSS-коммьюнити потратил на частичный перенос SysV на GNU Hurd, люди считают SysV переносимым. Дело в том, что многие современные, т.е. написанные после 1995 года, системные приложения используют Linux-специфичные особенности procfs, от которой, например, отказываются в том же FreeBSD. Для использования SysV в Debian/kFreeBSD и Debian/Hurd были задействованы два сторонних компонента - linprocfs и procfs. Так что технически, все ровно наоборот - в Debian портировали (задействовали сторонние компоненты) ядра FreeBSD и Hurd, чтоб запустить непереносимое ПО. Конечно, уровень доработки, необходимый для запуска systemd, вероятнее всего неподъемный, но технически этот аргумент нужно убирать - SysV и обе альтернативы (systemd и Upstart) непереносимы на устаревшие ядра. Степень переносимости, еще раз заметим, отличается. Интересно, что в процессе обсуждения ситуации с завязкой системных компонентов на procfs наш коллега, инженер Linaro, Koen Kooi, обратил наше внимание, что даже под Linux procfs нестандартизирована толком, чего уж там ожидать особых откровений от BSD-вариантов.

Одной из проблем, с которой столкнулся Justus при портировании SysV на Hurd было отключение. SysV последовательно убивал процессы, чем препятствовал отмонтированию разделов в системе (в systemd эту проблему решают в помощью cgroups, но этот Linux-компонент еще не перенесли на Hurd). Так что можно говорить, что не только SysV не переносим, так он еще и жестко привязан к ядру Linux.

Так уж совпало, что Lennart Poettering как раз поднял тему выключения системы в своей ленте Google+ прокомментировав баг в Upstart, приводящий к повреждению файловой системы при отключении (его пост уже перевели на OpenNET.ru). Прочитайте - возможно, вам больше не будет казаться, что отключение, это такой уж и легкий процесс.

В целом, хотя нам и известно, что в Upstart существует ряд архитектурных неустранимых или очень сложно устранимых проблем, обусловленных в т.ч. и императивным, а не декларативным, как в systemd, подходом к описанию сервисов, которые вылазят в неожиданных местах, теоретически его можно доработать. Но тут есть еще одна проблема. Доработка Upstart приводит к бесплатной работе на Canonical, т.к. проект находится под CLA. С упорством, достойным лучшего применения, Canonical отказывается освободить его из под соглашения. CLA Canonical критикует уже даже сам автор Upstart, не говоря уж о наших коллегах - статья Matthew Garrett, шокирующие признаниях Kay Sievers, мнение Greg Kroah-Hartman и мнение Linus Torvalds. А ведь это серьезно лимитирует количество разработчиков! В поле systemd прекрасное разнотравье из десятков активных участников, представляющих разные компании, а на бетонном плацу Upstart пугающая серая однородность. И это в то время, когда им надо постоянно копипастить, прикручивая изолентой, новые компоненты из systemd.

В тему о новых компонентах из systemd. До нас дошли слухи, что скоро приступят к интеграции Upstart с cgroups, но само собой, заведомо не так, как в systemd, и ряд задач такая интеграция решить так и не сможет. Здесь интересно отметить, что сторонники Upstart критикуют systemd за его-де монструозность, за количество плотно притертых компонентов, а якобы Upstart, это такой standalone init-демон. Вот только теперь ему нужны компоненты из systemd, без которых он не сможет выполнять ряд задач (и дальше таких компонентов будет еще больше), но он все равно якобы "standalone" и юниксвэйный - такова профессиональная честность пропагандистов.

Вернемся к хорошему. GNOME 3.13 планирует перейти на systemd для user sessions, о которых мы уже вам рассказывали. Долго они собирались.

Docker теперь поддерживает socket activation. Интересно, что один из участников команды Docker заартачился, назвав поддержку systemd - vendor-specific фичей. Мы, разумеется, с ним не согласны, но по результатам дискуссии Docker использует библиотеку, разработанную в рамках проекта CoreOS, что конечно лучше.