>>для обучения есть смысл
> Я не говорю, что ты совсем не прав. Уверен, что ты прав, если стоит задача обучить админа общего юникс-назначения, который шмог бы при необходимости и в BSD, и в Linux (хрен бы с ним с этими играми в рекурсивные "не-юниксы") и неважно, в какой именно дистрибутив. Но учитывая, что Linux пошёл особым путём и то, что systemd, чтобы там ни говорили диссиденты, таки де-факто(!) промышленный стандарт - если стоит задача приготовить годного Linux-админа (и не только админа), то как раз с systemd ему начинать и имеет смысл, дабы научился эффективно смотреть на систему именно через этот инструмент. Ему с ним жить.

Это факт, что если человеку по работе нужно админить systemd, желателен опыт использования systemd. Однако, я вижу эти знания абсолютно бесполезными без понимания того, как оно на самом деле должно работать, а не, выражусь корректно, довольно спорное видение поттеринга.

На сервере мне важнее прозрачность процесса загрузки и тривиальность нахождения/устранения проблем, а не скорость загрузки. А супервизор/вотчдог для продакшен-сервисов можно (и нужно) запускать сбоку от init/rc-скриптов.

> таки де-факто(!) промышленный стандарт

Мой опыт не подтверждает это утверждение. Да, systemd приехал во многие места вместе с обновлением дистрибутивов, но используется исключительно для загрузки ОС, бизнес-логика запускается сторонними средствами. Сталкивался с использующими самописное решение и с runit.
Чтобы продакшен-сервисы запускали что systemd, что sysvinit, что bsdшным rc.d я не видел. Ну, если речь не о горе-хостинге или каком-то незначительном количестве серверов - тогда пофигу, можно хоть руками в tmux'е всё запускать)) С таким, кстати, тоже сталкивался)).

> если стоит задача приготовить годного Linux-админа (и не только админа), то как раз с systemd ему начинать и имеет смысл, дабы научился эффективно смотреть на систему именно через этот инструмент

А я вот за кругозор. И общую теорию. Человек, умеющий в unix сумеет и в systemd, обратное не обязательно так - высокий уровень абстракции.
Чтобы понимать плюсы и минусы инструмента надо знать, что и как делают другие. Иначе получится как у моего оппонента, который уже во втором треде хвалится своим неумением завершить процесс в контейнере без systemd. Не надо так.
Смотреть на всё через один инструмент - ограничивать самому себе пространство возможных решений.

> Ему с ним жить.

Как по мне, пока рано это утверждать. Может быть и так. А может быть, как это модно в линуксе, опять всё решат переписать.
Я за специалистов, которые могут решить проблему, а не которые знают тот или иной инструмент.

>>Комм?
> Сокр. от "комментарий".

Тупанул, да.