> Это вероятность того, что некий демон займёт вполне определённый один PID.Верно. Но процессов ощутимо больше одного, поэтому эта вероятность не имеет прямого отношения к оценке риска. Для более правильной оценки риска нужна вероятность того, что под заданным PID окажется произвольный процесс (конечно, последствия некорректного завершения у разных процессов разные, поэтому в расчёте нужно использовать весовые коэффициенты, но можно исходить из того, что ненужных процессов в правильно настроенной системе нет).
> Так ведь в том и суть. Бизнес рассматривает systemd как отличный инструмент
> по простой причине: ему плевать на свободу и гибкость, а что
> ему действительно нужно, так это делегирование ответственности. Эти самые граничные случаи
> -- это то, что корпорации очень не любят. Как правило в
> продакшене им уделяется мало внимания, потому что "надо срочно пилить новые
> фичи, чтобы превзойти конкурентов".
> Так что ещё раз: дело не в ответственности. Дело в её делигировании
> на сторону. Кажется, это называется стрелочничество.
Нет, дело как раз в ответственности: не конечные пользователи принимали решение о переходе на systemd по умолчанию, а разработчики дистрибутива, поэтому любовь или нелюбовь бизнес-пользователей к systemd, равно как и их желание перенести ответственность, не имеют никакого значения.
Разработчики Debian несут ответственность за корректную работу, поэтому выбор более надёжного в этом плане инструмента - это как раз следствие наличия ответственности, а не желания избавиться от неё.
> Systemd же предлагает бизнесу простое решение: он
> имеет несколько сотен "заплаток", прикрывающих ряд наиболее распространённых ошибок.
> В цитируемом Вами сообщении он рассказывает безусловно правильные вещи, вот только не
> упускайте важную деталь: этими "заплаточками" от systemd надо ещё уметь воспользоваться.
> Для этого надо как минимум знать, какие граничные случаи бывают, и
> для прикрытия каких именно случаев какая "заплатка" нужна.
Какие ещё "несколько сотен заплаток"? Вы systemd, похоже, только издалека видели. Такие граничные случаи, как описал Расс, считаются стандартными для системы инициализации, и потому решаются в нём по умолчанию, не требуя для этого какой-то специальной конфигурации от пользователя.
> Расс Олбери -- очень хороший специалист, и много говорит по делу. Я
> хочу обратить Ваше внимание, что даже он признаёт (и заявлял, мягко
> говоря, неоднократно), что юниты systemd -- это потеря гибкости в угоду
> упрощению покрытия типовых сценариев запуска.
Прежде всего systemd (равно как и upstart, launchd, smf и другие) - это качественный переход в системе инициализации, сравнимый с переходом от использования ./configure && make && make install к менеджерам пакетов: систематизация подхода. Смотрите сами: объединение процессов (hint: файлов) в одну логическую единицу: сервис (hint: пакет), выражение связей между логическими единицами в виде зависимостей между сервисами (hint: пакетами), централизованное управление сервисами (hint: пакетами) через единый интерфейс: системный менеджер (hint: менеджер пакетов) - ничего не напоминает? Да, менеджер пакетов менее гибок, чем ./configure && make && make install, но и значительно удобнее в использовании и легче в поддержке - то же самое и с systemd (или upstart, launchd, ...) в сравнении с sysvinit.
Замечу, что ни в одном из голосований насчёт системы инициализации по умолчанию sysvinit не поднимался выше последнего места, а выбор и вся дискуссия шли между systemd и upstart. Это всё же неспроста.
