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

Почему у "сообщества" так "подгорает" от systemd? Откуда эта ненависть и "бугурт"? В чем его объективные недостатки?
  • Вопрос задан
  • 2056 просмотров
Решения вопроса 2
@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%.
Ответ написан
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 на ней сделать не в состоянии...
Ответ написан
Ваш ответ на вопрос

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

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