> В этом и проблема. Причина нестерпимой ненависти к systemd как раз в том, что его удобно админить.Я бы не назвал это такой уж сильной проблемой.
> Ранее для управления демонами в линукс требовались специфические знания:
> 1. Знать приложение которое ты запускаешь как демон.
> 2. Знать свой инит.
> 3. Уметь писать скрипты на bash.
> 4. Понимать как настроить взаимодействие со всеми остальными скриптами и имеющимися демонами
> с учётом возможных обновлений.
> 5. Специфику дистрибутива.
Это так.
> Systemd предполагает, что п.1 возьмёт на себя апстрим и предоставит интерфейсы для systemd.
Но было бы шикарно что SystemD предоставит интерфейсы сам, а не возложит эти задачи на апстрим.
> Делает п.3 опциональным.
С какой-то стороны это правильно.
> Берёт на себя п.4 и п.5, и, если что-то работает не так как надо, см п.2.
Пункт 5 делает опциональным.
> Унификация оказалась полезна меинтейнерам крупных дистрибутивов и системным администраторам, которые админят самописные корпоративные программы.
И не только.
> Пострадали царь-админы двух скриптов, "Сам Себе Меинтенеры".
И не только.
> ИТ менеджменту выгоднее когда админ написал unit, задокументировал и не парится, а не постоянно поддерживает скрипты корпоративных приложений на каждый чих + обновления.
Да и разумному админу + DIY'щику лучше.
> Выгодно переключить его на другие задачи...
Ему самому выгоднее переключиться на другое занятие по его желанию.
> Но как же? Лучше заниматься беспробудной рутиной и получать за это деньги, быть уникальным специалистом по башеписанию инитскриптов.
Да, гордыня все же держит таких.
> Systemd лишает таких людей работы, заставляет переквалифицироваться.
> Это всё происходит через боль.
А переквалификация это явно лишнее, просто достаточно того что человек умеет man.
> Systemd лучше любого LSB позволяет стандартизировать окружение.
> Представьте себе, что
> 1. Исчезнут каталоги /etc/sysconfig и /etc/default, и systemd начнёт следить за параметрами
> запуска демонов.
`/etc/sysconfig` уже не существует
SystemD осуществляет контроль параметров.
> 2. Выдаст разграничение, чтобы все демоны запускались в контейнерах от лиц своих
> пользователей, причём с явным отделением сетевых демонов от локальных
SystemD разграничивает сервисы, но разделяет окружение, про remote-service забудьте.
> 3. Минимизирует набор демонов запущенных с повышенными привилегиями.
SystemD уже это делает.
> 4. Начнёт контролировать по ACL доступ к демонам и их сокетам, конфигурациям,
> самому себе.
> 5. Обзаведётся шиной данных для обмена информацией с модулями ядра и замкнет
> на себе IPC со своими ACL.
А вот это уже лишнее.
