Какие существуют объективные недостатки у systemd?

Почему у "сообщества" так "подгорает" от systemd? Откуда эта ненависть и "бугурт"? В чем его объективные недостатки?
  • Вопрос задан
  • 1810 просмотров
Решения вопроса 3
@pcdesign
Обычно systemd-хейтеры находятся в возрасте 14-18 лет и настоящих Unix™ в глаза не видели.
1. systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
2. systemd — прямой аналог launchd и smf которые как раз в сертифицированных Unix™ живут.

А все эти визги про «не юниксвейно» раздаются от тех, кто только с мамкиных компов на лоре читал, что так надо попискивать.

Цитата взята отсюда:
https://habr.com/ru/company/southbridge/blog/31570...

Я согласен с автором на 100%.
Ответ написан
@Sha644
Много текста
technical

systemd appropriates the cgroup tree and takes control of it and completely messes with any other user of the cgroup tree and really wants them all to go through systemd, systemd was wirtten basically on the assumption that nothing but systemd would be using cgroups and they even tried to lobby to make cgroups a private prioperty of systemd in the kernel but that went no-where.

systemd's usage of cgroups for process tracking is a fundamentally broken concept, cgroups were never meant for this and it's a good way to fuck resource usage up

systemd has a hard dependency on glibc for really no good reason

systemd relies on DBus for IPC, as the name 'Desktop bus' implies DBus was never written with this in mind and it shows. DBus was written to facilitate IPC within a single desktop session, not as a transport during early boot. This is why systemd wanted to push kdbus heavily beause kdbus solved some of the problems inherent to DBus being used as IPC during early boot.

systemd's security and general code quality practices are less than stellar, a lot of security bugs pop up in systemd due to its insistence of putting quite a bit of code in pid1 and quickly adding new features and quickly changing things.

political

systemd creates dependencies and is a dependency of things for political reasons in order to encourage people to pick these things. This is not conjecture, Lennart has admitted multiple times that he creates dependencies to 'gently push' everyone to the same configuration

systemd is monolithic for its own sake. It's basically product tying to encourage people to pick an all-or-none deal to again gently push towards this consistency

personal

Lennart Poettering, the face of systemd and its lead dev is the biggest primadonna FOSS has ever known who continues to shift blame and demand that entire world adapt to his designs.
(с)/u/jij_je_walkman_terug
Ответ написан
kotomyava
@kotomyava
Системный администратор
По моим наблюдениям, в большинстве случаев, бугурт не от конкретных недостатков systemd, а от необходимости изучить что-то новое, и от его быстрого внедрения во все основные дистрибутивы.

Sha644 Привёл недостатки, и отчасти, они мешают, особенно то, что касается cgroups. Но на практике, это всё мало мешает тем, кто эксплуатирует дистрибутивы, больше тем, кто их поддерживает, а это был именно их выбор, в конце концов.
А многое и вовсе за уши притянуто: Например, от glibc всё равно зависят все широко используемые дистрибутивы, кроме какого-нибудь alpine, который весьма специфичен и где не нужен systemd вовсе, и.т.п.

Systemd, в целом, более сложная система, и многофункциональная, но он сложна внутри, а не в эксплуатации, и ведёт себя довольно неплохо.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
@metajiji
Интересно наблюдать как прямо сейчас Хейтеры в яндекс-кликхаус делают велосипед на init+sed, чтобы симулировать 1 строчку Restart:)
Только вдумайтесь в происходящее. Запустил сервис, в кроне добавилась задача, если сервис упал - запусти. Если сервис остановили скриптом, крон таска убирается. Слов нет, только эмоции. А вы про какие-то glibc беспокоитесь, там у них пакет в зависимостях не тянет за собой which, а в скриптах использует ы? Знакомо ага? Да молитесь на systemd, наконец навели порядок в этом безобразии всяких upstart, SysV, udev и кучи другого добра! А ещё кто не знал, но полюбас прогревал себе пукан, когда в fstab прописана фигня или недоступный nfs, сервер вообще не включается! И нужно душевно так провести время, хорошо, если есть ipmi, то вопрос 5 минут, а если нет? Так вот к чему я, есть .mount юниты это же каеф + зависимость кинул, чтобы сервис без шары не взлетал и падал вслед за шарой. Сервер запустится, шара нет, сервис тоже не поднимется, а зайти по ssh можно и главное починить легко и оперативно. И это только малая часть боли которую systemd реально прямо сейчас решает без плясок и крови из глаз.
Ответ написан
@MechanID
Админ хостинг провайдера
На самом деле sytemd был шагом вперед и избавил от зоопарка каких угодно скриптов в /etc/init.d/ но:
1 все помнят как насаждался и как "хорошо" работает pulseaudio
2 внезапная имплементация systemd принесла множество неразберихи и связанных проблем.
Маинтейнеры пакетов досихпор иногда не справляются с задачей написать правильно unit file который приезжает на продакшен сервера и вызывает неудобства (особенно такие параметры как ProtectSystem=full) но тут конечно дело в мейтейнерах пакетов а не в systemd
По сравнению с старой системой инит скриптов недостатков нет.
Ответ написан
@marsdenden
Жалею, что не разобравшись, поставил в продакшн сервер с systemd. За три месяца огреб столько проблем, сколько их не было за три года на sysVinit. Да и для десктопа преимущества сомнительные. Особенно, когда начинает сыпаться корневая ФС, а он fschk на ней сделать не в состоянии...
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы