История изменений

Но посмотрите на OpenRC, чем не решение? Я уже давно пользуюсь гентой, но т.к. это десктоп, инит-скриптов своих писать не приходилось, и вот в связи с этой истерией о systemd глянул в её скрипты, это ж просто праздник! Вопрос, чего такого решает systemd, чего нельзя без него, до сих пор для меня открыт.

И они вынуждены использовать start-stop-daemon для запуска демонов и ненадёжные PID-файлы для остановки. В отличие от этого, systemd автоматически запихивает каждый демон (со всеми его потомками) в отдельную группу cgroups. Для надёжной остановки демона нужно всего лишь прибить все процессы из группы. В случае PID-файлов во-первых, нет возможности установить, действительный ли он, или демон уже давно упал, а под этим номером работает другой процесс; а во-вторых, PID-файл хранит номер одного процесса — как надёжно убивать его потомков, остаётся неясно.

Это одна из проблем, которую решает systemd. Но не стоит забывать, что systemd не только управляет демонами. Он также предоставляет удобное API для управления локалью, раскладками клавиатуры, шрифтами в консоли, временем, хостнеймом и многими другими вещами. Это повышает интеграцию DE с системой. Например, прямо из гнома можно установить в настройках времени галочку для синхронизации с NTP, гном через D-Bus сообщит новую настройку systemd-timedated, а последний включит или выключит time-sync.target, в котором выполняется ntpd. Если бы такого не было, мейнтейнерам каждого дистрибутива пришлось бы патчить гном, чтобы он вызывал дистрибутивоспецифичные методы для включения и отключения ntpd.

Кстати, относительно недавно в портедже появилась программа, предназначенная для работы под OpenRC, предоставляющая интерфейсы systemd на D-Bus для вышеперечисленного. Если бы не systemd, вряд ли кому-нибудь пришла в голову идея написать такую прослойку для унификации дистрибутивозависимых вещей.

Но посмотрите на OpenRC, чем не решение? Я уже давно пользуюсь гентой, но т.к. это десктоп, инит-скриптов своих писать не приходилось, и вот в связи с этой истерией о systemd глянул в её скрипты, это ж просто праздник! Вопрос, чего такого решает systemd, чего нельзя без него, до сих пор для меня открыт.

И они вынуждены использовать start-stop-daemon для запуска демонов и ненадёжные PID-файлы для остановки. В отличие от этого, systemd автоматически запихивает каждый демон (со всеми его потомками) в отдельную группу cgroups. Для надёжной остановки демона нужно всего лишь прибить все процессы из группы. В случае PID-файлов во-первых, нет возможности установить, действительный ли он, или демон уже давно упал, а под этим номером работает другой процесс; а во-вторых, PID-файл хранит номер одного процесса — как надёжно убивать его потомков, остаётся неясно.

Это одна из проблем, которую решает systemd. Но не стоит забывать, что systemd не только управляет демонами. Он также предоставляет удобное API для управления локалью, раскладками клавиатуры, шрифтами в консоли, временем, хостнеймом и многими другими вещами. Это повышает интеграцию DE с системой. Например, прямо из гнома можно установить в настройках времени галочку для синхронизации с NTP, гном через D-Bus сообщит новую настройку systemd-timedated, а последний включит или выключит time-sync.target, в котором выполняется ntpd. Если бы такого не было, мейнтейнерам каждого дистрибутива пришлось бы патчить гном, чтобы он вызывал дистрибутивоспецифичные методы для включения и отключения ntpd.