> Бессмысленно сравнивать "в строках", пока Вы не учли - что эти строки в 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 как бы заливисто смеётся вам в лицо. Давайте, продолжайте обмазываться своими шеллскриптами.