>>> Не понимаю аргумента с худшими проблемами.
>> Да сколько угодно.  Меньшая прозрачность системы, сложность отладки и т.п.
> Прозрачность init-скриптов в дистрибутивах вызывает у меня сомнения. Особенно, если учесть
> что я не гуру вообще, и в sh в частности.

А у меня - нет.  Как и для любого администратора - POSIX-shell это часть базовых знаний.  Дело прежде всего даже не в стандартных утилитах, а в нормальном скриптовом языке, логика которого прозрачна и понятна.

> Ключик запуска я конечно поменять смогу, но дебри юнитов или init-скриптов

Вам, как пользователю - нужно просто открыть баг в дистрибутиве, и не лезть куда не след.  Что с sysvinit, что systemd.

>> Главное, забыть что существуют разные способы IPC...
> Главное не забыть, что мы говорим о сервисе и его клиентах. Между
> сервисом и клиентом трудно представить более подходящий тип IPC, чем сокет.

"Трудно, но можно."

> Остальные IPC, такие как shared memory и семафоры(есть еще что-то в
> linux, что я забыл?)

Забыли, конечно.  atd вон - никаких сокетов не создает, а поди кому-то потребуется.  Точно также, как и cron (а, возможно, мы захотим @reboot пускать под самый конец загрузки?).

> Да, к сожалению не все сервисы можно стартануть независимо. Однако то, что
> в конфигурации запуска некоторых сервисов зависимости можно не указывать - положительный
> фактор, который уменьшает сложность поддержки системы в целом.

Или отрицательный - который увеличивает ее неоднородность и уменьшает прозрачность администрирования.

> К тому же есть возможность собрать dbus довольно
> аскетичным способом, который сведет возможность появления дырки в безопасности по вине
> dbus к минимуму.

Если возможность только "есть" - видимо, ей не пользуются.  Или как?  Почему вы столь уверены, что что-то работает, если этим практически не пользуются?  А в числе пользователей - разработчики да толпа мартышек (99% пользователей десктопа)...

>>> Причем тут роль, которую выполняет компьютер? не знаю, чем может
>>> помешать d-bus, даже на сервере.
>> Бесполезностью.  Лишними проблемами с безопасностью.
> Если на сервере стоит systemd, то dbus не бесполезен. Насчет безопасности выше.

На счет "полезности" - еще выше.  Мы уже прошлись по всяким on-demand запускам сервисов и т.п. х-не.  Выяснили, что подобная блажь на сервере *не нужна*.

> Нет, не всё. Во первых, вы сами привели примеры тех демонов, для
> которых on-demand активация довольно странное решение

А для каких - не странная.  Что есть на сервере: apache, sshd, postfix, nginx, sendmail, etc.  Честно говоря, аргументы выше работают для всего, что мне приходит в голову добавить в этот список.

Может вы перестанете говорить загадками - и укажете такие, для которых "не странно"?

> , и, во вторых, есть проверка
> конфигов. В третьих, если вы админите удалённый сервер, то вы _должны_
> проверять конфиги

И во-вторых, и в-третьих - не работает, т.к. человеческий фактор.

> И systemd тут ни при чём, sysvinit никак вас
> не спасёт. И в случае с sysvinit, и с systemd после
> перезагрузки с неверным конфигом вы получаете нерабочий сервис.

Спасет.  См. ниже.

> Отличие только в
> том, что с systemd(или (x)inetd кстати) вы узнаете об этом при
> первой попытке использования.

А в случае sysvinit - *сразу после плановой перезагрузки*.  Т.е. в четко известное "время и место".  Есть разница?

>>> не принуждает использовать on-demand и dbus, просто такая возможность есть.
>> Эта возможность откручивается полностью?  Т.е. весь код для поддержки этого брахла?
> systemd - это в первую очередь система инициализации, в основе которой лежит
> активация как принцип, неважно принудительная, on-demand, socket-based, mount-based
> и т.д. И вы спрашиваете можно ли отключить то, ради чего
> все городилось и лежит в основе systemd.

Вот такой вот "принцип" и "плагины".  И вы еще удивляетесь, что люди не в восторге от "архитектуры" systemd?

>>>> Это вам автор пообещал.  А мы скажем мягше - пытается не ломать.   Не всегда получается...
>>> Ну дык, работа над ошибками, как и ошибки, будут всегда..
>> Ну вот когда *таких* ошибок не будет вовсе - можно подумать и о включении в дистрибутивы.
> Пока не будет пользователей - не будет ошибок. Release often, release early?

Это не про софт для задач такого уровня.  Поспешишь - людей насмешишь.

>>>> Ну-ну.  Багтрекеры дистрибутивов посмотрите...
>>> не ковырялся.
>> Вот-вот...
> По логике тут должна быть ссылка. Жду.

см., к примеру, http://bugs.debian.org/  Пакет найдете самостоятельно?

> Тогда будьте добры, в доказательство своих слов, приведите пример, когда цикл(да и
> вообще скрипт со сложной логикой) при старте сервиса необходим.

$ grep 'for .*in' /etc/init.d/*|wc -l
94

Можно еще посчитать while до кучи.  Вполне прилично, короче.

> К тому же, вам никто не мешает сделать unit
> для своего сложного скрипта и в нем стоять хоть на ушах.

Вот-вот - ну и зачем нам, в таком разе systemd, ежели всякие сложности на каждом шагу заставляют "стоять на ушах".  Да, всякие Exec* остались не от хорошей жизни.  Реальность не желает стоять во фрунт...

>>> Я думаю сложность преувеличена. Типичный юнит для systemd это несколько строк говорящего
>>> самого за себя текста.
>> Ну-ну.  Вам то же задание, что и прочим "фанатам".  Есть init-скрипт апача в Debian.  Перепишите все для systemd с сохранением совместимости - время пошло.
> Давайте обойдёмся без ярлыков. Я не являюсь фанатом, я лишь пытаюсь понять
> причины ненависти к systemd.

Я не испытываю "ненависти".  Для меня - это просто плохое, негодное ПО.  Почему - пытаюсь вам объяснить.

> А домашние задания оставьте при себе.

Т.е. собственную точку зрения доказать на примере - не можете?

>>> А там, где нужна сложная логика -
>>> без манов не обойтись в любом случае, как в случае с
>>> systemd, так и в случае с sysvinit.
>> Так вот - не нужна.  Любой профпригодный администратор знает shell, да и о стандартных системных утилитах вкурсе.
> Видимо, профпригодные администраторы всосали manы по шеллу и стандартным утилитам с молоком матери?

На этапе обучения.  Но командная оболочка и системные утилиты - имеют куда больший спектр применений, чем инициализация.  Вот почему замена этому обучению на "другое" (а почитай-ка маны systemd) - не катит, ваша ирония неуместна.

>> [...] а будут - юниты для systemd.  "Простота" написания оных - мифическая, как вам указали.
> Ничего вы мне не указали. Только общие фразы.

Где юнит для апача, как вас выше просили?  Пупок развязался написать?  То-то.

> К тому же особого бардака в init-скриптах вроде нет, просто у каждого дистрибутива они
> отличаются координально, что вносит некий диссонанс.

Этот "диссонанс" правильно называется - бардак.

> Если вам будет легче - используйте telinit. Он работает. Просто есть еще
> вариант использования, под который я не могу придумать use-case, но это
> не значит, что его не существует.

Если вы даже "не можете придумать" - откуда взялся квантор сущестования?  Выглядит уже нагло, извините...

> "Primarily it has two intended use cases: to allow the user to
> temporarily enter a specific state such as "Emergency Shell", terminating current
> services, and provide an easy way to return to the state
> before, pulling up all services again that got temporarily pulled down."

Ага.  А в sysvinit для этого достаточно сказать telinit.  А все почему?  Потому что кто-то запускает "on-demand", без жестко прописанных зависимостей и т.п. всякую *****, а потом геройски решает проблемы, которых можно было бы не иметь вовсе...

>> Получается излишняя сложность, нет?  Если есть и плагины, и возможность запуска сценариев - может что-то лишнее?
> Думаю, не весь функционал systemd можно или целесообразно реализовать в рамках сценариев.

Ну может и ну его, к бесу, этот "функционал", не?  Собственно, такое отношение к "функционалу" и пугает в первую очередь.  Как клептоман - тащим первую понравившуюся идею, разберемся потом...