>> Бессмысленно сравнивать "в строках", пока Вы не учли - что эти строки в sysvinit
>> 1) на высокоуровневом языке
> Зачем? пример systemd наглядно показывает, что без этого можно обойтись.Да. Наплодив уникального (он только для systemd, в отличие от grep и mount) кода на С. Можно только _верить_, что в этой _новой_ куче С кода, выполняющегося далеко не от простого пользователя, нет пропорционального количества багов. Блажен кто верует.
>> 2) используют кучу общесистемных утилит (сделанных не только для обеспечения загрузки)
> Адовый оверхед.
Зато отлаженный и работающий код. Каждая утилита - делает что-то свое, вместо комбайна, функционал которого непонятно чем ограничен.
>> 3) не учли код самого bloatware (~50k, без учета кучи библиотек), в сравнении с простым sysvinit (~8k _весь_ код, в т.ч. всякие telinit, _без_)
> угу, а 100500 exec()'ов grep/tr — это не bloatware, ага. а boilerplate,
> который даже закэшировать нормально невозможно — это тоже не bloatware.
Что там закешировать нельзя? Десяток бинарников?
>> 4) ExecStartPre/Post + весь с этим связанный код учли?
> На каком основании?
На том, что код шелл-скриптов Вы учли весь. А эти ExecStartPre/Post - будут указывать как раз на куски старых init-файлов, грубо говоря.
>> Взамен получена туча строк на C, причем используемых только в одном месте...
> а) вероятнее всего, не в одном б) машинного кода, вообще-то
а) Невероятно. Иначе - соответствующий код вынесли бы в библиотеки.
b) в первую очередь - это строки C кода. Со всеми прелестями разработки на этом низкоуровневом языке.
>> Без ясного представления автора о том:
>> 1) какие именно проблемы sysvinit новая система будет решать
> г-носкрипты, главным образом
Смотрю в /etc/init.d/* - покажите, пожалуйста, пальцем
"г-носкрипт". Эти скрипты - ровно никуда не денутся. Шаблонная
часть вида case "$1" start) ... stop) - может быть уложена в одну
строчку и без systemd. Рассказать как?
А все остальное - никуда не денется. Любой сложный сервис (апач,
постфикс) - потребует ExecStartPre/Post и Ваших нелюбимых "г-носкриптов" там.
>> 2) что мы ей _будем_ делать
> запускать системные сервисы
Что Вы вкладываете в это понятие? Это пресс-релиз какой-то,
а не техническое задание. Расшифруйте. *Как* запускать?
Что при этом делать, а что - не делать и оставить для других утилит.
>> 3) что мы ей _не будем_ делать
> известные мне сведения о фичах systemd меня устраивают. ничего лишнего вроде как
> не наблюдается.
Зачем Вам понадобился dbus? Как выставление всяческих rlimit-ов,
приоритетов IO-шедулера и проч. относится к старту сервиса? Вот,
появятся у linux новые крутилки ресурсов - Леннарт добавит
параметр в соответствующую секцию? И так - до бесконечности?
Где граница того, что "архитектор" этой приблуды скажет "хватит -
делаем exec shell-скрипта и пусть там админ сам вызывает утилиты
для настройки соответствующих параметров".
>> Реализация у него идет впереди проектирования. С системным ПО это не катит.
> бла-бла-бла
Покажите спецификацию systemd. Как я уже просил, в духе _полного_
списка решаемых задач. А не списка "фич", который выглядит потенциально
неограниченым сверху.
>>> Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет.
>> В чем именно бонус - в экономии на спичках? Сисадмин узнает, что с sshd что-то не так (конфиг кривой, к примеру) - не на этапе загрузки, а когда кто-то залогиниться попытается. Зашибись.
> а) Что-то мешает отладить конфиг обычным порядком и потом переключить в режим
> ondemand?
А что мешает потом его поломать?
> б) Во-вторых, это отличное решение для реализации диагностической
> консоли в каком-нить встраиваемом девайсе.
Это в первую очередь - "отличное решение", чтобы получить проблему не в четко известное время (при старте сервисов), а хрен знает когда.
Поймите, я не просто ругаю. Мне непонятно - абсолютно-ли необходима эта "фича" Вашей "запускалке для сервисов". Может, лучше ее было бы выкинуть - а сервис, который потребует такого счастья запускать через специальную обертку?
>> Отдельный бонус - эта тварь будет пытаться отрестартить сервис при известных условиях.
> Вы тупой или нарочно игнорируете факт, что авторестарт прописывается *явно*? Это вопрос,
> да. Нет, я не уверен.
Из документации systemd.service - не очевидно. Ткните, где четко сказано про такое умолчание.
Буду рад, если ошибся.
>> Берите скрипт ssh init скрипт из Debian и показывайте как переписать его.
> Чьто, внезапно пример с ntp некорректен? А почему?
Вы не поняли? Вот почему: "Error 503 Service Unavailable".
>> За исключением того, что Вы выкинули большую часть функционала init-скрипта апача в том же Debian. Выкинута логика с htcacheclean, выкинута поддержка нескольких экземпляров апача. Такое и с init можно соорудить. Сделать шаблон с именем сервиса, строкой вызова сервиса и стандартным параметром start/stop/restart. В init-скрипте Вы выставите просто все эти переменные и подключите шаблон. Одна строчка.
> одна строка + boilerplate, который повторяется в *каждом* скрипте. Меньше значимого текста
> — меньше ошибок. Всё элементарно.
Вы не поняли. Одной строкой - можно запросто описать один сервис. При желании. Конечно, только достаточно простой. Т.е. вся логика "case $1 start) ... stop) ..." - может быть вынесена в одну строчку.
А вот остальной "boilerplate" - повторяется как раз не в каждом скрипте. И ровно никуда в systemd - не денется - он просто перекочует в ExecStartPre/Post.
>> Просто некоторые люди понимают бессмысленность такой "экономии". Большая часть кода init-скрипта в Debian - обработка опций из /etc/default, разрешение конфликтов конфигурации (админ конфиги не обновил, использует старые параметры в default и т.п.), организация chroot для сервиса и т.п. А вовсе не тупые "case" с вызовами start-stop-daemon.
> Так пусть это делает скрипт на сишечьке, только в 100500 раз быстрее
> и нормально написанный на нормальном ЯП.
Зашибись. Будем плодить ошибки и дырки в работе со строками, только чтобы не использовать высокоуровневые инструменты. Как раз предназначеные для автоматизации системных задач.
Откуда число 100500? "От фонаря" ведь - никаких реальных цифр у Вас нет.
>>> Три? Пять? Во сколько раз это меньше кол-ва сисколлов sh/grep/sed/tr/прочего шлака, сами посчитаете?
>> Без понятия. Десятки. Еще обработка зависимостей, dbus всякие - чего там только нет.
> Это машинный код, понимаете? Неужели вам нужно объяснять, насколько он быстрее?
Объясняйте, конечно. Может появятся таки цифры от Вас - а может кому-то "объяснение" даст повод улыбнуться ;)
>> Во сколько выражается разница в скорости загрузки - на реалистичном случае (LSB-совместимая система загрузки, как в Debian vs systemd тамже) я так и не увидел. Сильно подозреваю, что копейки.
> http://elinux.org/images/b/b3/Elce11_koen.pdf как бы заливисто смеётся вам в лицо. Давайте,
> продолжайте обмазываться своими шеллскриптами.
Что с чем сравнивалось - ежа с ужом? Там до systemd была реализованна полноценная поддержка LSB-совместимых скриптов? Или запуск был последовательным? Такая "прИзентация" - смеется в лицо прежде всего своему автору, фанату "рокзвезд". Да и Вам заодно.
