> 1) Тем что компактнее в раз так эн.

Либо экран Вам поболее, либо память получше. Склероз в таком юном возрасте...

> Типовой юнит влезает на экран.

Естественно слезает, ведь он запускает BASH портянку. Если нужно что-то сложнее, то 30+ строчек кода в юните обычное дело, но куда нам до лаконичности запуска хеловорлдов

> 2) Все параметры на виду - а не на третьей, блин, странице,
> вперемешку с кодом.

Ну зачем мне видеть параметры, если их смысл придумывали шизики, которые даже в документации стыдятся написать подробно обо всех подводных камнях?

> 3) И кстати код вперемешку с конфигурацией, имхо, совсем не круто.

Имхо, Вам бы поучиться, чтобы понять, когда код, когда конфиг, а когда логика декларируется. Если сравнивать, что половина логики задаётся декларативно в unit-е, половина в скрипте запуска и это повсеместно, то, как по мне, лучше всё-таки всё в одном файле, чем в 3х?

> 4) Параметры более-менее унифицированы и описаны в мане. В отличие от.

Только написанное в мане подходит для самых простых случаев, шаг в сторону -- неопределённое поведение в лучшем случае. В худшем - отваливается другая часть системы инициализации. Про параметры окружения я вообще молчу.

> 5) Системд это привилегированый агент, который может сам отвесить все сисколы в
> нужном порядке собирая арену будущего процесса, до того как отдать ему
> управление.

Может, если хорошо попросишь у кого нужно. В почтовой рассылке.

> 6) Вызов интерпретера на каждый пшик не то чтобы быстро и эффективно.

Вы приведите оценку насколько, а потом говорите. И да, воз го***, который тащит и запускает SystemD, видимо, не влияют на скорость.

> 7) Системд более-менее может в нормальный логгинг, в отличие от. Так что
> если нечто померло чаще всего есть хоть что-то полезное в логах.

О боже, что за школота!

> Например, скриптота при сборке контейнера налетает на тот факт что большая часть
> системы в энный момент уже недоступна. А зачем HTTP серверу вызывать
> bash или вон тот интерпретер? Это не требуется для его нормальной
> работы, вызов оного - сигнал "сервер взломан". Давайте вот блин еще
> упростим взломщикам развитие атаки. И диагностики что сломалось нихрена, но вы
> дескать можете сами накодить это.

Волков бояться, в лес не ходить. Вы, наверное, часто запускаете контейнеры на 100ТБ по несколько ТБ ОЗУ в прод? Тогда из-за чего переживаете про взлом? Не понимаете векторы атак, потому что взяты готовые контейнеры из помоек? Ну в этом случае -- могила исправит.

> Не, не так. В 95% случаев скрипты как раз нафиг не -
> и только вот когда реально надо можно вызвать шелл интерпретер с
> скриптом. Т.к. это чуть менее удобно а вон то делается и
> средствами системды.

Фантазии...

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

Так вся эта простыня была только из-за ИДЕИ декларативного программирования системы инициализации? Если да, то я тоже такого хочу, но убожество, которым является SystemD -- это явно не тот случай.

Ну а если Вы действительно уверены в том, что SystemD панацея, пожалуйста, напишите два юнита:

1. U1 работает и поддерживает сервис для U2
2. Запуск U1 вещь затратная и его запуск занимает существенное время
3. U2 не может работать без U1
4. После запуска U2 должен с использованием U1 отрапортовать об успешном запуске.

Я бы назвал эту ситуацию как 2 сильно связанных сервиса.

Напишите Unit-ы которые обеспечат работоспособность связки в рабочих условиях (когда работа U1 может случайным образом стать невозможной).