Что: a04a29f4e16dd3d5aad7c5309e0b10fb7bd5823e
Когда: 2020-05-30 20:25:16+03:00
Темы: systemd
История systemd
https://habr.com/ru/post/503816/
https://suckless.org/sucks/systemd/
https://www.opennet.ru/base/sys/systemd_myth.txt.html
Да уж, systemd как никто разделил людей на два лагеря: любителей этого,
и hater-ов этого.
Я стараюсь называть системы где он используется: systemdOS, ибо если там
что-то (по вопросам администрирования) выполняется не через systemd, то
значит вы что-то делаете неправильно. Десятилетия существования и
разработки рабочего софта выкинуты нафиг и заменяются написанным с нуля:
готовьтесь к тому, что даже DNS, NTP не будут работать запросто (история
это уже показала). Готовьтесь к тому, что поведение всей вашей системы
уже будет совершенно иным (например грохать tmux при вашем logout).
Любой компонент вашей ОС будет заменятся systemd-шным вариантом, уже не
раз доказавшем что он будет более ограниченным и более глюкавым. В
systemd в прошлом году было уже более 1.2M строк кода -- это тянет на не
одну полноценную ОС. 1.2M!!! Ещё с зависимостями, в том числе от Linux.
Если раньше что-то шло не так в процессе запуска, инициализации,
настройки сети, mount-ов и кучу другого, то вы шли и отлаживали,
смотрели что не так. Теперь можно выдохнуть, успокоится и не делать
этого с systemd, ибо это всё равно под сотню бинарников.
А ещё забавный факт про то, что в нём логи в бинарном виде. Тупейший
аргумент за это: для индексирования и поиска по ним. Как бы, а что
мешает индексировать обычные текстовые логи? Вот-вот, ничего, но я уже
сталкивался с тем, что люди банально не могут передать друг другу логи,
ибо читать то их нечем (на целевой системе без systemd). Я не против
индексирования логов -- текстовый формат как-то этому препятствует?
Хочется целостность и аутентичность данных в логе? В чём проблема,
бинарный формат то в этой задаче чем поможет и необходим?
Но многим он понравится. Тем, кто не в состоянии писать скрипты,
понимать как устроена система, самостоятельно решать задачи
администрирования. Вместо тривиальных и простых скриптов (сотни,
максимум тысячи строк кода) полностью рулящих всей системой гибко,
поддерживаемо и понятно, systemd предоставляет кучу "рецептов" в
исходном коде на три порядка большего размера.
На работе безусловно было много холиваров, но, благо они закончились,
так как все сошлись в одном: systemd это штука для desktop-а. Он
актуален и может быть полезен только для desktop-like вещей и desktop
пользователей, которые и не будут знать что такое IP-адрес или точка
монтирования. systemdOS это просто написание Windows/macOS-like системы,
не более. Монолитного, забагованного, ограниченного, невероятно
огромного и громоздкого, не отлаживаемого (ну кроме разработчиков
systemd, которые будут копаться в его C коде) blackbox-а. Ну а так как
компании хотят зарабатывать деньги, то создание аналогичной системы как
Windows/macOS, где пользователь готов терпеть любые баги, глюки,
нарушения приватности (systemd же по умолчанию в Google сливал DNS
запросы), беспомощность и возможность что-либо исправить только через
поддержку сторонних специалистов.
Очень много наездов, кстати, на init-систему запуска, адекватных, если
уж рассматривать systemdOS как систему запуска. Вот только под этой
"init-системой" подразумевают реально какое-то убожество из RedHat
систем, судя по всему, которое мало что умеет делать без сотен строк
shell-кода. В FreeBSD свой rc, удовлетворяющий тьме адекватных
требований и хотелок к системе запуске для сервера. В OpenBSD свой,
только попроще. В NetBSD свой. В Debian точно помню что отличный от
RedHat-овского. Я уверен что и в десятке других дистрибутивов свои
диалекты и версии. Поэтому, как минимум, уже безграмотно объединять
невероятно разные по возможностям системы запуска основанные (даже
неявно) на shell-скриптах. В той же FreeBSD я не помню написал ли хоть
одну строчку реально shell кода (ну чтобы там сохранение PID, lockrun,
if-ы какие-нибудь были) за последние десять лет -- всё делал в
декларативном простом и тупом стиле, ибо возможностей rc FreeBSD за
глаза хватает. При этом я вовсе не ратую и толкаю за использование
shell-скриптов и мол они наше всё. Просто shell вполне себе is good
enough адекватный выбор для задачи инициализации и настройки системы
(возможно кроме сильно других требований для "классических" desktop
систем).
И мне ещё очень нравится пример работы с systemd:
Here is what happens on a stock Arch Linux system, powered by
systemd, when a non-root user tries to restart the system:
$ reboot
Failed to set wall message, ignoring: The name org.freedesktop.PolicyKit1 was not provided by any .service files
Failed to reboot system via logind: The name org.freedesktop.PolicyKit1 was not provided by any .service files
Failed to talk to init daemon.
In contrast, here is the equivalent error message on a system
powered by runit:
$ reboot
init: fatal: unable to create /etc/runit/stopit: access denied
And on the oldest and best, Slackware:
$ reboot
reboot: must be superuser.
Сгенерирован: SGBlog 0.34.0