> Да. Наплодив уникального (он только для systemd, в отличие от grep и mount) кода на С. Можно только _верить_, что в этой _новой_ куче С кода, выполняющегося далеко не от простого пользователя, нет пропорционального количества багов. Блажен кто верует.Ох мать. Теперь мы с багами боремся.
А апелляция к вере вообще абсурдна. Предпочитаю оперировать фактами. Извините. Вот факты — https://bugs.freedesktop.org/buglist.cgi?product=systemd&com...---
И да, как по-вашему, что быстрее и проще — preg_match() или grep? /usr/bin/mount или mount()?
>>> 2) используют кучу общесистемных утилит (сделанных не только для обеспечения загрузки)
>> Адовый оверхед.
> Зато отлаженный и работающий код. Каждая утилита - делает что-то свое, вместо комбайна, функционал которого непонятно чем ограничен.
А systemd запускает сервисы согласно их описанию в конфигах. Всё. чем не «что-то своё»?
>>> 3) не учли код самого bloatware (~50k, без учета кучи библиотек), в сравнении с простым sysvinit (~8k _весь_ код, в т.ч. всякие telinit, _без_)
>> угу, а 100500 exec()'ов grep/tr — это не bloatware, ага. а boilerplate, который даже закэшировать нормально невозможно — это тоже не bloatware.
> Что там закешировать нельзя? Десяток бинарников?
байткод повторяющихся кусков, из которых оные г-носкрипты состоят чуть менее, чем полностью.
>>> 4) ExecStartPre/Post + весь с этим связанный код учли?
>> На каком основании?
> На том, что код шелл-скриптов Вы учли весь. А эти ExecStartPre/Post - будут указывать как раз на куски старых init-файлов, грубо говоря.
Ну не обязательно же. Зачем всю дорогу передёргивать? systemd в этих местах делает самый обычный exec(). что в нём — забота maintainerа.
>>> Взамен получена туча строк на C, причем используемых только в одном месте...
>> а) вероятнее всего, не в одном б) машинного кода, вообще-то
> а) Невероятно. Иначе - соответствующий код вынесли бы в библиотеки.
Исходники доступны, доказывайте.
> b) в первую очередь - это строки C кода. Со всеми прелестями разработки на этом низкоуровневом языке.
это C-то низкоуровневый? Это вы ещё на асме и машкодах не писали.
>>> Без ясного представления автора о том:
>>> 1) какие именно проблемы sysvinit новая система будет решать
>> г-носкрипты, главным образом
> Смотрю в /etc/init.d/* - покажите, пожалуйста, пальцем "г-носкрипт". Эти скрипты - ровно никуда не денутся. Шаблонная часть вида case "$1" start) ... stop) - может быть уложена в одну строчку и без systemd. Рассказать как?
start-stop-daemon?
> А все остальное - никуда не денется. Любой сложный сервис (апач, постфикс) - потребует ExecStartPre/Post и Ваших нелюбимых "г-носкриптов" там.
которые внезапно запросто можно реализовать в виде маленьких элегантных бинарников. ну или г-носкриптов — на любителя.
>>> 2) что мы ей _будем_ делать
>> запускать системные сервисы
> Что Вы вкладываете в это понятие? Это пресс-релиз какой-то, а не техническое задание. Расшифруйте. *Как* запускать? Что при этом делать, а что - не делать и оставить для других утилит.
То есть на sysvinit ТЗ не нужно, а на systemd — обязательно, так?
>>> 3) что мы ей _не будем_ делать
>> известные мне сведения о фичах systemd меня устраивают. ничего лишнего вроде как не наблюдается.
> Зачем Вам понадобился dbus?
Зачем и всем — слать типизированные сообщения кому попало, не заморачиваясь необходимостью проверять, запущен ли этот самый кто попало. Нет, сигналы для этого непригодны.
> Как выставление всяческих rlimit-ов, приоритетов IO-шедулера и проч. относится к старту сервиса? Вот, появятся у linux новые крутилки ресурсов - Леннарт добавит параметр в соответствующую секцию? И так - до бесконечности?
То есть как в initскрипте прописать ionice — так нормально и правильно, а как systemd сказать, чтобы выставил нужный приоритет — так ненужно и нерелевантно. Двоемыслие во все поля, да.
Ну и да, добавлять — не убирать. BC не ломает.
> Где граница того, что "архитектор" этой приблуды скажет "хватит - делаем exec shell-скрипта и пусть там админ сам вызывает утилиты для настройки соответствующих параметров".
Это можно делать уже сейчас — sh -c в любом из Exec*'ов. А Леннарту (я убеждён) вообще пофиг, как это используется.
>>> Реализация у него идет впереди проектирования. С системным ПО это не катит.
>> бла-бла-бла
> Покажите спецификацию systemd. Как я уже просил, в духе _полного_ списка решаемых задач. А не списка "фич", который выглядит потенциально неограниченым сверху.
Беглый гуглёж не нашёл спеки на sysvinit. Двойные стандарты во все поля.
>>>> Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет.
>>> В чем именно бонус - в экономии на спичках? Сисадмин узнает, что с sshd что-то не так (конфиг кривой, к примеру) - не на этапе загрузки, а когда кто-то залогиниться попытается. Зашибись.
>> а) Что-то мешает отладить конфиг обычным порядком и потом переключить в режим ondemand?
> А что мешает потом его поломать?
Напомните-ка, зачем-зачем нужно ломать то, что работает?
>> б) Во-вторых, это отличное решение для реализации диагностической консоли в каком-нить встраиваемом девайсе.
> Это в первую очередь - "отличное решение", чтобы получить проблему не в четко известное время (при старте сервисов), а хрен знает когда.
Тестируется на раз. Поэтому мимо.
> Поймите, я не просто ругаю. Мне непонятно - абсолютно-ли необходима эта "фича" Вашей "запускалке для сервисов". Может, лучше ее было бы выкинуть - а сервис, который потребует такого счастья запускать через специальную обертку?
Эта фича — просто приятный бонус. Не более.
>>> Отдельный бонус - эта тварь будет пытаться отрестартить сервис при известных условиях.
>> Вы тупой или нарочно игнорируете факт, что авторестарт прописывается *явно*? Это вопрос, да. Нет, я не уверен.
> Из документации systemd.service - не очевидно. Ткните, где четко сказано про такое умолчание. Буду рад, если ошибся.
Элементарно — http://cgit.freedesktop.org/systemd/tree/man/systemd.service... Нашлось за 5 минут.
>>> Берите скрипт ssh init скрипт из Debian и показывайте как переписать его.
>> Чьто, внезапно пример с ntp некорректен? А почему?
> Вы не поняли? Вот почему: "Error 503 Service Unavailable".
error 503? у ntpd? Брысь обратно в свою параллельную вселенную.
>>> За исключением того, что Вы выкинули большую часть функционала init-скрипта апача в том же Debian. Выкинута логика с htcacheclean, выкинута поддержка нескольких экземпляров апача. Такое и с init можно соорудить. Сделать шаблон с именем сервиса, строкой вызова сервиса и стандартным параметром start/stop/restart. В init-скрипте Вы выставите просто все эти переменные и подключите шаблон. Одна строчка.
>> одна строка + boilerplate, который повторяется в *каждом* скрипте. Меньше значимого текста — меньше ошибок. Всё элементарно.
> Вы не поняли. Одной строкой - можно запросто описать один сервис. При желании. Конечно, только достаточно простой. Т.е. вся логика "case $1 start) ... stop) ..." - может быть вынесена в одну строчку.
Но не выносится. Чуть менее, чем везде — https://gist.github.com/6af2f58c87cd97e1ec08
> А вот остальной "boilerplate" - повторяется как раз не в каждом скрипте. И ровно никуда в systemd - не денется - он просто перекочует в ExecStartPre/Post.
Это решать maintainerу, systemd тут ничего не навязывает. Хотя я бы предпочёл маленькие бинарнички.
>>> Просто некоторые люди понимают бессмысленность такой "экономии". Большая часть кода init-скрипта в Debian - обработка опций из /etc/default, разрешение конфликтов конфигурации (админ конфиги не обновил, использует старые параметры в default и т.п.), организация chroot для сервиса и т.п. А вовсе не тупые "case" с вызовами start-stop-daemon.
>> Так пусть это делает скрипт на сишечьке, только в 100500 раз быстрее и нормально написанный на нормальном ЯП.
> Зашибись. Будем плодить ошибки и дырки в работе со строками, только чтобы не использовать высокоуровневые инструменты. Как раз предназначеные для автоматизации системных задач.
Can't into getopt и stdlib?
> Откуда число 100500? "От фонаря" ведь - никаких реальных цифр у Вас нет.
Предположение, да. Бенчить лень.
>>>> Три? Пять? Во сколько раз это меньше кол-ва сисколлов sh/grep/sed/tr/прочего шлака, сами посчитаете?
>>> Без понятия. Десятки. Еще обработка зависимостей, dbus всякие - чего там только нет.
>> Это машинный код, понимаете? Неужели вам нужно объяснять, насколько он быстрее?
> Объясняйте, конечно. Может появятся таки цифры от Вас - а может кому-то "объяснение" даст повод улыбнуться ;)
Да вы и сами добудете эти цифры. Года через три.
>>> Во сколько выражается разница в скорости загрузки - на реалистичном случае (LSB-совместимая система загрузки, как в Debian vs systemd тамже) я так и не увидел. Сильно подозреваю, что копейки.
>> http://elinux.org/images/b/b3/Elce11_koen.pdf как бы заливисто смеётся вам в лицо. Давайте, продолжайте обмазываться своими шеллскриптами.
> Что с чем сравнивалось - ежа с ужом? Там до systemd была реализованна полноценная поддержка LSB-совместимых скриптов? Или запуск был последовательным? Такая "прИзентация" - смеется в лицо прежде всего своему автору, фанату "рокзвезд". Да и Вам заодно.
Теперь вы показываете, как userspace грузится за аналогичное время, но на sysvinit. Вот тогда мы и похохочем.
