metaclass | Ненависть к systemd как психическая эпидемия

Ненависть к systemd как психическая эпидемия

Напомните мне или дайте ссылку - я уже спрашивал, чего все на systemd так ополчились?
Выглядит, как средневековая эпидемия одержимости дьяволом, все псят, чего псят - непонятно.
Ну, не считая вот этого: http://metaclass.livejournal.com/889197.html?thread=20959341#t20959341 тут, несмотря на теорию заговора, хоть какое-то обоснование имеется.

Flat | Top-Level Comments Only

А, да, кроме прочего: любой аргумент за systemd как-то оказывается каким-то дегенератством. Впроде аргументов вендофанбоев, который то орали что в винде микрокернел, то -- что там такой появился АД, который одним движэнием на тыщу машын софт устанавливает.

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

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

Вот это кстати там сделано абсолютно логично (хотя и по ебанутому)
man systemd.unit имеет список мест, и порядок чтения.
файлы мержатся при чтении, более позднее значение имеет приоритет.

То есть если тебе в foo.service не нравится _один_ параметр, ты пишешь
cat </etc/systemd/system/foo.service
[Service]
User=super
EOF

И это удобно, когда ты управляешь 100500 боксов каким нибудь шефом или солтом

PS Я при этом не спорю что там много хуиты спорото

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

ЯННП! Какой ещё один параметр? Зачем для его изменения делать cat <...?

Это жеж оверрайд параметров, по моему, достаточно удобная фича.

удобная, подтверждаю

А, я понял. Там большэ с меньшэ перепутано.

Но у нас это делается редактированием /etc/default/$servicename

даа? а как вы поступаете, когда в инитскрипте из дистра тупо не предусмотрена ручка, которую надо подкрутить (i.e. CPUAffinity, ionice, да даже банально переменную окружения в нужное значение выставить)?

Мы либо как-то выкручиваемся, либо правим initscript. Впрочем, при применении верхней головы -- выкручиваемся обычно успешно. А как Вы поступаете, когда ручка не предусмотрена в systemd?

Кстати, переменные окружэния в /etc/default/servicename можно выставить любые, и написать в нём start-stop-daemon () { /sbin/start-stop-daemon --iosched ... "$@" } проблем не составляет.

правим initscript

и молимся, чтобы maintainer пакета не поправил скрипт и не пришлось бы решать конфликты. been there.

А как Вы поступаете, когда ручка не предусмотрена в systemd?

-1) в настоящее время это скорее «если» — ручек, если вы ходили по ссылкам, там более чем дофига, а некоторые далеко не сразу понятно, как реализовывать батниками
0) это какая интересно?
1) пишем скрипт и перекрываем у юнита ExecStart

написать в нём start-stop-daemon () { /sbin/start-stop-daemon --iosched ... "$@" } проблем не составляет

грязный хак. хорошо хоть это только в одном месте можно сделать. если вообще можно: разве /etc/default/servicename есть у всех сервисов?

ну если у мантейнера хватило ума скопипастить из примера -- то оно пытается читать /etc/defaults/$name если он есть

>и молимся, чтобы maintainer пакета не поправил скрипт и не пришлось бы решать конфликты. been there.

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

>ручек, если вы ходили по ссылкам, там более чем дофига,

А у Вас нет ощущения, что "дофига" и "на все случаи жызни" -- это совершэнно ортогональные понятия?

>хорошо хоть это только в одном месте можно
> сделать. если вообще можно: разве
^gt; /etc/default/servicename есть у всех сервисов?

Нет, не у всех. Сейчас посмотрел -- почти у десятка именно сервисов из полутора сотен моей системы -- не используется. У части при этом есть какой-то другой развесистый конфиг, у части -- /lib/lsb/init-functions.

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

я без проблем решаю и гораздо более серьёзные конфликты

нет конфликтов — нет проблем. смекаете?

это гораздо проще, чем решать конфликты в сорцах systemd

расскажите подробнее, как именно вы пришли к необходимости разрешать конфликты в сорцах systemd?

"дофига" и "на все случаи жызни" -- это совершэнно ортогональные понятия

и что, из этого следует, будто systemd ненужен/следует_запретить, потому что его не хватит на все-все-все случаи жизни, так?

У части при этом есть какой-то другой развесистый конфиг, у части -- /lib/lsb/init-functions.

Ага. То есть одни и те же люди ссылками на XKCD предполагают наличие каких-то уже существующих стандартов, а в соседней ветке демонстрируют, что стандартами они де-факто не являются. Выглядит как двоемыслие.

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

мне неоднократно приходилось. мержить инитскрипты, когда можно не мержить — унижение.

(no subject)

tzirechnoy.livejournal.com - 2014-10-09 10:09 (UTC) - Expand

(no subject)

develop7 - 2014-10-09 10:44 (UTC) - Expand

А вот мантейнеры софта ликуют. При приходе systemd во все дистрибутивы им больше не придется писать init скрипты под каждый дистрибутив.

Мэйнтэйнеры апстрима? Так они и так не пишут, чего им радоваться.

А по поводу того, что оно конвергирует -- я тут ужэ ссылку на xkcd постил.

чтоп вам пришлось по работе саппортить 2-3 поколение 3-4 основных дистров.
Потому что стартап, и работозвятель хочет чтобы было вчера.

Да вы смотрю сама доброта ;)

ну одним пакетом, который ставится на все убунты начиная с precise, и дебианы от squeeze до sid я обошелся. (привет разнообразию инитов, ага -- sysvinit+upstart+systemd из коробки)
С центосами уже хуже -- один исходный ==> три бинарных на выходе

Знаю знаю эту фигню. Сам собирал не раз под несколько дистрибутивов.

Мэйнтэйнеры апстрима? Так они и так не пишут, чего им радоваться.

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

Спецыально для нечитателей пощу ещё раз: http://xkcd.com/927/

перечитал — и, как по волшебству, инитскрипты из апстрима заработали во всех дистрах искаропки.
UPD: а нет, показалось

Да видел я это. Смысл в том что сейчас всех основных дистрибоизготовителей склоняют к systemd. И да на данный момент могу сказать что из того что предлагалось для замены sysvinit systemd не самый плохой вариант. Тот же upstart то еще угребище.

Flat | Top-Level Comments Only