Жирок то потек.

и в чем я мог бы выиграть, избавившись от него?

На лор будешь фигню постить, но ты и так постишь фигню.

Каждый день на форуме кто-нибудь да отпустит язвительный комментарий в сторону systemd (особенно в свете новостей про Debian и Devuan). Почитать ЛОР, там без него было намного лучше, но зачем то же его написали и продвинули.

Лор-овцы ненавидят всё. И System_D, и SysV init, и тебя.

И System_D

Толсто.

Ты перестанешь быть илитой типа спуфинга.

Если не админ, скорее всего разницы не заметишь. Глюкодром раннего systemd пофиксили. Можно пользоваться. Не увидишь ни плюсов, ни минусов.

Очевидно же. После изменения юнита сначала надо делать daemon-reload, чтоб перечитать конфиги. Потом restart. Потом еще и status, т.к restart не сообщит если юнит фэйлит.

Во время разработки раз 20 такое напишешь и пальцы устанут

Чем для меня может быть плох systemd?
не админа

Вместо чтения выхлопа о какой-либо ошибке после запуска демона сразу из консоли будешь сношаться с унылым journalctl.

я тоже не понял как узнать удачно ли запустился запущенный вручную сервис без дополнительных с моей стороны действий: вдруг он сдох при попытке запуска и ничего не сказал об этом

makoven,

Потом restart. Потом еще и status, т.к restart не сообщит если юнит фэйлит.

Вот-вот. Удобно же

Можете для продвинутого пользователя GNU/Linux на десктопе (не админа) объяснить, чем для меня лично плох systemd и в чем я мог бы выиграть, избавившись от него?

Ничем, ничего[/thread]

Инициализация системы - тонкое место, где всё должно быть прозрачно для пользователя. Иначе, бинарная помойка аки венда. Это раз. Во-вторых, нарушает изначальную концепцию Unix, где одна утилита на одну задачу. Ну про бинарные логи, хттп сервер и генератор qr-кода в (!) системе инициализации я вообще молчу.

Абзац подкрался незаметно

Кроме того, политика внедрения systemd мешает развитию его альтернатив, что ослабляет конкуренцию и ведёт к застою. Без всяких lighttpd, cherokee и thttpd мы бы до сих пор сидели на Apache без надежды на nginx.

не админ

Ну и не парься. Какая разница рядовому пользователю, что там под капотом? Ну, научишься писать ini-подобные юниты, если захочется чего-то нестандартного, а не научишься — стащишь из рача.

Потом еще и status, т.к restart не сообщит если юнит фэйлит.

Справедливости ради, пишите с поддержкой SD_NOTIFY и в юните TYpe=notify. Тогда ваш сервис при старте сообщит systemd, что он READY, и всё будет хорошо.

Ничем

Можете для продвинутого пользователя GNU/Linux на десктопе (не админа) объяснить, чем для меня лично плох systemd и в чем я мог бы выиграть, избавившись от него?

Абстракцией меньше

Меня все устраивает, но может я чего-то не понимаю?

Сиди дальше работай

Если оно загружается нормально, ни разу не падало, не ломало систему при обновлении, не требовало включить с десяток опций в ядре и не выжирало раму - то только тем что является потенциальной точкой отказа.

Чем для меня может быть плох systemd?

От него может брат умереть.

чем для меня лично плох systemd

Раньше было глюкодромище с гонками при загрузке и зависанием намертво. Сейчас вроде бы всё починили, но желания с ним работать нет. Ни одной проблемы для десктопа systemd не решил, а только всё вернул как было.

чем я мог бы выиграть, избавившись от него

То, что в твоей системе не будут чинить то, что не сломано.

Тебя intelfx в свой расстрельный список внесет.

Чем для меня может быть плох systemd?

Немного лучше веществ

Можете для продвинутого пользователя GNU/Linux на десктопе (не админа) объяснить, чем для меня лично плох systemd

Как раз для админа плох, а для тебя хорош (до первого большого бага а-ля svchost). Однако, я считаю, что число серверных инсталяций линукса заметно больше десктопных, отсюда основная проблема с systemd.

запуска демона сразу из консоли будешь сношаться

он же пользователь, он не умеет читать (и не должен). только котиков кликает.

Как раз для админа плох

Что? systemd на порядки упрощает администрирование, снимая головную боль почти полностью.

Сколько серверов или какие проблемы были решены? Лично у меня сложилось другое мнение.

снимая головную боль почти полностью.

Таки да, практика показывает что заложенные Лёней-быдлокодером противопехотные мины в этом глюкалове снимают лёгкую головную боль почти полностью.

Лично видел неадекватное поведение на ноуте на 8-м дебиане, уже не вспомню. Решилось заменой на sysvinit. С точки зрения админства - [сарказм]табы для /etc/init.d/<service> reload|restart значительно сложнее чем systemctl reload| restart <service>[/сарказм] и при этом ты должен точно знать имя сервиса, или иди и смотри список всех юнитов другой командой. Очень удобно во время отладки, или когда у тебя сервер уходит в даунтайм, и тебе нужно его как можно быстрее поднять.

Еще видел нюансы, когда юнит стартует раньше времени, но это на сложных серверных сетапах.

Жечь напалмом systemd.

История с Devuan показательна тем, что(как и предсказывали) уже сейчас без systemd много чего не работает.

Много чем. На деле сам решай, чем именно. Чтобы понять, почитай новости про эпичные баги systemd.

Эта история показательна тем, что к systemd стараются привязать всё искусственно и кровавую монополию устроить.

и в чем я мог бы выиграть, избавившись от него?

В функциональности, удобстве и скорости. Только не выиграть, а проиграть.

Во время разработки раз 20 такое напишешь и пальцы устанут

man bash

Сколько серверов

4, АПВС? И рабочие станции разве админить не нужно?

какие проблемы были решены?

С логами работать намного проще и удобнее, networkd очень удобен на воркстейшенах и в контейнерах, сами контейнеры удобно организованы и очень быстро стартуют, простые написание, сопровождение и развёртывание юнитов для самописных демонов, остановка и запуск юнитов затрагивает все их зависимости, таргеты позволяют удобно и гибко управлять группами связанных юнитов и т.д., сходу могу всё не вспомнить, я уже 6 лет с ним активно работаю, все юзкейсы в один абзац вряд ли поместятся. Ну и главное — нет груды кривых баш-портянок. Например, демоны нормально рестартятся.

systemd всем хорош

+1, дополнение реализованное через огромную портянку bach complitions вообще не радует.

4, АПВС?

4 сервера??? это даже как-то ни о чем. давай просто не физические считать, а сразу виртуальные. АПВС? это новый молодежный жаргон или внутреннее сокращение?

С логами работать намного проще и удобнее

Вот как раз это одно из самых слабых мест. Допустим, одно из твоих приложений очень интенсивно какает в лог. Не спрашивай меня почему. Девелоперы отлаживают на живую или еще что. Пару гигов в сутки. Хранить их долго нет смысла. Почитал - удалил. Как ты можешь очистить лог для отдельного приложения в твоем случае?

networkd очень удобен на воркстейшенах

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

и в контейнерах, сами контейнеры удобно организованы и очень быстро стартуют

они и так быстро стартуют, разве нет? почему это стало работать лучше?

простые написание, сопровождение и развёртывание юнитов для самописных

демонов

да, юниты создавались в расчете на это, но много ли ты юнитов пишешь сам? а самое главное отлаживать их стало сложнее. как уже писали на этом форуме, systemd может что-то не запустить и промолчать.

гибко управлять группами связанных юнитов

можно пример? на сервере без разницы, запустишь ты сначала tomcat, а потом апач или наоборот.

сходу могу всё не вспомнить, я уже 6 лет с ним активно работаю

в этих случаях помогает рабочий журнал;)

Например, демоны нормально рестартятся.

я по ссылке не ходил, но они и так нормально рестартятся супервизором. более того, супервизор под это заточен и больше умеет вокруг этого танцевать, плюшки печет и кофе варит.

Ну и главное — нет груды кривых баш-портянок.

они не стандартизированы, но от этого не становятся кривыми. весь линукс, можно сказать, такой. зато их очень легко отлаживать, ведь это просто скрипты. ты даже чтобы отладить systemd должен сначала запустить, а потом обратиться к journalctl.

Меня все устраивает, но может я чего-то не понимаю?

Ага, не понимаешь. Ты должен орать, что системд говно, бросаться на стены и демонстративно закатывать глаза от одного только этого слова. И пох, что все работает. Ну да ты и сам все знаешь, звезду-то вон отъел себе как-никак.

С логами работать намного проще и удобнее

допустим, у тебя есть сбойные диски с крешнутой ОС, журнал systemd не целостный. ты хочешь достать оттуда логи системы с последними сообщениями от mdadm, допустим. как быстро определить, какой именно лог относится к системным messages и позволит ли journalctl его читать, если он побит?

Я как-то видел сбой, потому что система не могла прочекать xfs раздел (и загрузиться вроде тоже не могла). Была логическая ошибка внутри кода systemd (внутри был просто exec утилиты для проверки). Если бы это был «кривой скрипт», мы бы просто что-то там поправили и пошли дальше, а тут никак.

Во время разработки раз 20 такое напишешь и пальцы устанут

man bash

каждый раз альясы писать будешь? а если серверов много? так тебе тогда надо их всюду скопировать. мало ли что где сломается. сам себе проблем придумал, короче.

АПВОВНВ?

И пох, что все работает.

Типа раньше не все работало.

противопехотные мины... снимают лёгкую головную боль

а так же взрывают пуканы хейтеров, вызывая у них сильнейшую попаболь

не удержался

Держи методички за обе стороны:

https://wiki.debian.org/Debate/initsystem/sysvinit

https://wiki.debian.org/Debate/initsystem/systemd

О!

Оконный сервер в системе - тонкое место, где всё должно быть прозрачно для пользователя. Иначе, бинарная помойка аки венда. Это раз. Во-вторых, нарушает изначальную концепцию Unix, где одна утилита на одну задачу. Ну про сервер печати, бинарные трансляторы (COFF, A.OUT, ELF), четыре хреново работающих подсистемы ввода (базовый протокол X11, Xinput 1.0, Xinput 2.0, Xinput 2.2) и дохлый и никому ненужный тулкит (Xaw via X Toolkit Intrinsics) в (!) оконном сервере я вообще молчу.

По мнению Поцеринга от shell-скриптов надо избавляться. Так что bash тут ни-ни.

То бишь, никакие проблемы не решены, а просто кучка неосиляторов отказалась осваивать готовые средства для решения тех проблем, и кинулась жрать systemd. Я уверен, что ты не знаешь, какие средства для решения этих задач задолго до systemd существовали и продолжают существовать сейчас. Единственная причина использования systemd - это хайп.

Отсыпь.

По мнению Поцеринга от shell-скриптов надо избавляться

толсто