> Бессмысленно сравнивать "в строках", пока Вы не учли - что эти строки в sysvinit
> 1) на высокоуровневом языке

Зачем? пример systemd наглядно показывает, что без этого можно обойтись.

> 2) используют кучу общесистемных утилит (сделанных не только для обеспечения загрузки)

Адовый оверхед.

> 3) не учли код самого bloatware (~50k, без учета кучи библиотек), в сравнении с простым sysvinit (~8k _весь_ код, в т.ч. всякие telinit, _без_)

угу, а 100500 exec()'ов grep/tr — это не bloatware, ага. а boilerplate, который даже закэшировать нормально невозможно — это тоже не bloatware.

> 4) ExecStartPre/Post + весь с этим связанный код учли?

На каком основании?

> Взамен получена туча строк на C, причем используемых только в одном месте...

а) вероятнее всего, не в одном б) машинного кода, вообще-то

> Без ясного представления автора о том:
> 1)  какие именно проблемы sysvinit новая система будет решать

г-носкрипты, главным образом

> 2) что мы ей _будем_ делать

запускать системные сервисы

> 3) что мы ей _не будем_ делать

известные мне сведения о фичах systemd меня устраивают. ничего лишнего вроде как не наблюдается.

> Реализация у него идет впереди проектирования.  С системным ПО это не катит.

бла-бла-бла

> Итог: bloatware будет расти, тащить с собой все новые либы с багами, помимо собственных.  Будет Вам в init и splash, и крон...

С чего бы? plymouth уже есть сервисом. Крон в ините не нужен, хватит сервиса.

> И в конце-концов какой-нибудь полноценный скриптовый язык, вместо расширяющегося до бесконечности декларативного INI-говна.

Всё лучше, чем шеллскрипты + grep/tr/прочийшлак. Я молчу насколько это маловероятно.

>> Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет.
> В чем именно бонус - в экономии на спичках?  Сисадмин узнает, что с sshd что-то не так (конфиг кривой, к примеру) - не на этапе загрузки, а когда кто-то залогиниться попытается.  Зашибись.

а) Что-то мешает отладить конфиг обычным порядком и потом переключить в режим ondemand?
б) во-первых, это может быть произвольный демон. Вроде mongodb или redis, которыми я практически не пользуюсь. Во-вторых, это отличное решение для реализации диагностической консоли в каком-нить встраиваемом девайсе.

> Отдельный бонус - эта тварь будет пытаться отрестартить сервис при известных условиях.

Вы тупой или нарочно игнорируете факт, что авторестарт прописывается *явно*? Это вопрос, да. Нет, я не уверен.

>  И это надо будет _отключать_, чтобы не мешать работе нормального мониторинга.

Отключать не надо. *Можно* *включать*. Разберитесь уже там в предмете обсуждения или прекращайте спекулировать, не?

>> "И 6 (шесть) аналогичного конфига systemd — http://en.gentoo-wiki.com/wiki/Systemd#ntpd"
> "Error 503 Service Unavailable".  Ну, см. на ответ на Ваше первое замечание про "строки".

ну сокет-то слушает, не? значит работает. остальное — в конфиги опача.

> Берите скрипт ssh init скрипт из Debian и показывайте как переписать его.

Чьто, внезапно пример с ntp некорректен? А почему?

>> Вот примерно так — http://www.linux.uz/forum/index.php?topic=2703.0#msg34308
>> 14 (четырнадцать) строк против 282 у меня в системе. Где-то 20кратная разница.
> За исключением того, что Вы выкинули большую часть функционала init-скрипта апача в том же Debian.  Выкинута логика с htcacheclean, выкинута поддержка нескольких  экземпляров апача.  Такое и с init можно соорудить.  Сделать  шаблон с именем сервиса, строкой вызова сервиса и стандартным параметром start/stop/restart.  В init-скрипте Вы выставите просто все эти переменные и подключите шаблон.  Одна строчка.

одна строка + boilerplate, который повторяется в *каждом* скрипте. Меньше значимого текста — меньше ошибок. Всё элементарно.

> Просто некоторые люди понимают бессмысленность такой "экономии".  Большая часть кода init-скрипта в Debian - обработка опций из /etc/default, разрешение конфликтов конфигурации (админ конфиги не обновил, использует старые параметры в default и т.п.), организация chroot для сервиса и т.п.  А вовсе не тупые "case" с вызовами start-stop-daemon.

Так пусть это делает скрипт на сишечьке, только в 100500 раз быстрее и нормально написанный на нормальном ЯП.

>> Три? Пять? Во сколько раз это меньше кол-ва сисколлов sh/grep/sed/tr/прочего шлака, сами посчитаете?
> Без понятия.  Десятки.  Еще обработка зависимостей, dbus всякие - чего там только нет.

Это машинный код, понимаете? Неужели вам нужно объяснять, насколько он быстрее?

> Во сколько выражается разница в скорости загрузки - на реалистичном случае (LSB-совместимая система загрузки, как в Debian vs systemd тамже) я так и не увидел.  Сильно подозреваю, что копейки.

http://elinux.org/images/b/b3/Elce11_koen.pdf как бы заливисто смеётся вам в лицо. Давайте, продолжайте обмазываться своими шеллскриптами.