> Многое из того, что systemd поставляет из коробки -- на самом
> деле вполне себе реализуется на скриптах, Ну, реализуй хотя-бы lockdown сервиса на этом, с запретами сисколов и изоляцией в свое окружение. У системды коронный номер - то что он УЖЕ в памяти, УЖЕ привилегированный, УЖЕ все либы - в RAM. Поэтому может скомпоновать arena'у процессу и когда все готово вызвать желаемое.
А когда мы пытаемся собрать себе ограниченное/изолированное окружение скриптом - это задник. Надо полсистемы внутрь совать чтобы бинари и либы были доступны, иначе обломается на середине.
> и в целом предлагают большую свободу действий администратору системы,
В случае с системдой можно при желании и скрипт вызвать. А так эта свобода потом, видите ли, брякается на бошку в виде гамнокода который хрен декодируешь без поллитры. А делать это таки придется, потому что у разных дистров все это видите ли разное было.
> более удобный дебаг скриптов и т.д.
Это, наверное, шутка. Типичная ситуация с sysvinit: сервис не стартанул, диагностики везде по нулям. Но вы можете накодить себе удобный дебаг и логгинг. Правда, целью было вообще-то нестартовку сервиса затраблшутить, а ценность результата кодинга дебаглогинга нулевая. Вы, конечно, потом узнаете где какой-нибудь -EPERM или что там еще был. Но с системдой это случится раз в 20 быстрее, он видите ли журналит самые очевидные обломы, да и выхлоп софта.
> Проблема скриптов заключается в том, что они не унифицированы между дистрибутивами, что
> собственно является закономерным следствием sysvinit:
А также игнорирует современные проблемы и пожелания, типа повышенной изоляции сервисов и проч.
> В теории мы можем получить всё, что предоставляет systemd, и при помощи скриптов.
А на практике это такой головняк что этим никто никогда не занимался.
> Но systemd уже есть, и потому скрипты никто допиливать не будет.
Десятки раз делать 1 и ту же работу может и задолбать.
> заниматься даже разраюботчики.
Или совершенно сторонние лица, до кучи комитнувшие юнит системды. А что, 10 строчек накидать может казуальный пользователь сервиса. Багов особенно налепить там негде. И это более-менее одинаково между дистрами, и сервис таки подымает.
> теперь мы можем делегировать задачу запуска сервиса непосредственно разработчику, и тем
> самым разгрузить мейнтейнеров дистрибутивов.
А разработчики зачастую это делегируют на вообще внешних юзерей, в отличие от sysv им бывает не обломно юнит системды накидать.
> Встроенным супервизором systemd отвечает нуждам старого энтерпрайза
А также новой (да и старой) эмбедовки с линухом, например.
> свои системы супервизоры. Хотя бы тот же djb daemontools.
...от которых вышеупомянутым толку ноль целых, фиг десятых? Сервис бывает не только сетевым.
> в целом плевать, что часть лога может потеряться.
Она и в обычном текстовике может потеряться. Курить позиксную семантику файловых систем до посинения. С пониманием того как там вообще и что с журналингом, так, по жизни.
И да, далеко не любой прогер эксперт в этом вопросе хотя-бы уровня поттера - в этом случае масштабы разрушений фееричные. Половина лога может только в буфере в RAM оказаться и при факапе просто испарится.
> А серьёзный энтерпрайз использует более высокоуровневые решения для журналирования,
Так там для них и сделан и редирект, и настройки чего-куда.
> ибо никому нафиг не сдались. Но зато systemd прекрасно справляется со
> своей основной задачей -- поднимает docker и kubelet. =)
Да он и без них так то может половину этого обтяпать, особенно systemd-nspawn. Так что это больше вкусовщина и удобства..
> с 2014го года я -- главный критик systemd на opennet.
Ну а что, так рвал глотки за свою точку зрения ... для того чтобы на нее забить? :)
