Релиз systemd 230

Пока ты этого не сделал — я утверждаю, что решение этой задачи на sysvinit будет объёмнее, что подтверждает мои исходные слова.

Да пофиг на объём) Важен функционал и возможность кастомизации. Исходные слова, лол.

rc.cups. Осилишь переписать не теряя функциональности, пусть даже с большим(!) кол-вом кода - дай знать)

# /usr/lib/systemd/system/cups.service
[Unit]
Description=CUPS Printing Service
After=network.target

[Service]
ExecStart=/usr/sbin/cupsd -f
PrivateTmp=true

[Install]
Also=cups.socket cups.path
WantedBy=multi-user.target printer.target

# /usr/lib/systemd/system/cups.socket
[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/var/run/cups/cups.sock

[Install]
WantedBy=sockets.target

# /usr/lib/systemd/system/cups.path
[Unit]
Description=CUPS Printer Service Spool

[Path]
PathExistsGlob=/var/spool/cups/d*

[Install]
WantedBy=multi-user.target

Устроит?

HP-UX, AIX, SINIX, IRIX, UnixWare, OSF1, BSD, Darwin, GNU Hurd, GNU/Linux (не ограниченные редхат блоатварью)?

Не устраивает. Надо бы портировать. Портируешь? В конечном итоге ведь там мало будет написано, по сравнению с «в два раза большей шелл портянкой». Такой плюс, такой плюс.

когда выгодно - входит, когда невыгодно - невходит.

Ложь: udev никогда не входил в PID 1 и вряд ли будет.

perceived bloat can occur from the software servicing a large, diverse marketplace with many differing requirements.

perceived bloat != bloat != bloatware

Вообще-то подтверждает. Стоит внимательно присмотреться к опровержениям, они в твоём духе.

Прекращаем разводить демагогию. Или ты показываешь, что там не так, или ты не прав.

там, где ты переписал rc.cups.

Я не собираюсь искать в Интернете и переписывать скрипт, которого ни разу не видел. Если ты хочешь, чтобы он стал аргументом в споре — приведи релевантные фрагменты.

а на тот кусочек на:

sv check

1. Это не sysvinit.
2. Это решает другую задачу.
3. Куда это вписывать? Полный текст модификации. Без контекста я тоже могу написать что-то вроде

   ! systemctl is-failed A
   case $? in
   ..
   

Важен функционал и возможность кастомизации

Это всё было продемонстрировано. Приведённые мной юниты выполняют поставленную задачу и допускают любую кастомизацию логики.

Да пофиг на объём

В условиях равной функциональности побеждает более лаконичное решение.

Ложь: udev никогда не входил в PID 1 и вряд ли будет.

а где я говорил что входит в PID 1? Не лги от моего лица.

perceived bloat != bloat != bloatware

а глянешь на сустемд - блоатварь блоатварью.

Или ты показываешь, что там не так, или ты не прав.

https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Systemd_components....

и попытки это отмазать :-D

Прекращаем разводить демагогию.

повторяй почаще, демагог.

Я не собираюсь искать в Интернете и переписывать скрипт, которого ни разу не видел. Если ты хочешь, чтобы он стал аргументом в споре — приведи релевантные фрагменты.

То, что ты не собираешься ничё делать - не секрет. Зачем мне напрягаться? cups доступен, скрипт тоже. Осилишь переписать сохранив функционал - твоя правда, я неправ. А до тех пор - звезди не звезди, а сустемд не предоставляет всех плюшек инита + шелл. Что бы ты там не утверждал.

Это не sysvinit.

нерелевантно, шелл везде шелл. на так:

a
case $? in
...

то решает другую задачу.

какую?

Это всё было продемонстрировано.

где

HP-UX, AIX, SINIX, IRIX, UnixWare, OSF1, BSD, Darwin, GNU Hurd, GNU/Linux (не ограниченные редхат блоатварью)?

лгун.

Приведённые мной юниты выполняют поставленную задачу

через жопу

и допускают любую кастомизацию логики.

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

В условиях равной функциональности

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

побеждает более лаконичное решение.

если в твоей логике systemd(bloatware) + shell более лаконично чем sysvinit + shell, то что поделать. я не доктор. разведу тока руками.

Еще говорил что

а где я говорил что входит в PID 1?

Вот здесь:

На протяжении всей подветки мы говорим про init (PID 1). udev в него не входит.

когда выгодно - входит, когда невыгодно - невходит.

а глянешь на сустемд - блоатварь блоатварью.

Повторяю вопросы:

1. Что такое блоатварь?
2. Почему systemd — блоатварь?
3. Почему это плохо?

Жду формальных ответов.

Или ты показываешь, что там не так, или ты не прав.

https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Systemd_components....

и попытки это отмазать :-D

Что «отмазать»? Картинка отражает положение вещей. Автор текста объясняет, почему это положение вещей не есть плохо, в то время как ты утверждаешь, что плохо. Тебе следует либо показать, где автор текста не прав, либо признать, что ты не прав.

Стоит внимательно присмотреться к опровержениям, они в твоём духе.

Прекращаем разводить демагогию.

повторяй почаще, демагог.

«они в твоём духе» — это обвинение в несостоятельности. Неаргументированные обвинения в несостоятельности — это демагогия, практически по определению. Указание на демагогию (отсутствие аргументации) таковой не является.

То, что ты не собираешься ничё делать - не секрет. Зачем мне напрягаться?

wiki:Burden of proof

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

нерелевантно, шелл везде шелл. на так:
a
case $? in
...
стало легче?

Вспоминаем исходную задачу (с твоих слов).

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

Приведённый тобой первый сниппет не подходит, т. к. 1) полагается на дополнительное ПО (команда sv) и 2) полагается на внешние силы, которые запустят его в момент сбоя первого демона.

Приведённый тобой второй сниппет требует пояснений на тему 1) природы команды «a» и 2) того, куда его вписывать.

где HP-UX, AIX, SINIX, IRIX, UnixWare, OSF1, BSD, Darwin, GNU Hurd, GNU/Linux (не ограниченные редхат блоатварью)?

Нигде. В условии задачи ничего про платформы не было.

через жопу

Нет, это твои сниппеты решают задачу через жопу.

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

Что тебе ещё скастомизировать?

я вижу что мои три шелл-строчки против твоих двух файлов

1. Твои три шелл-строчки полагаются на «внешние силы», которые запустят их в момент сбоя первого демона.
2. У меня в решении не два файла, а четыре строчки. Всё остальное — контекст (я показал, куда вписывать).

Вот здесь:

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

Повторяю вопросы:

Релиз systemd 230 (комментарий)

Что «отмазать»?

bloatware. положение вещей.

Тебе следует либо показать, где автор текста не прав,

я тебе показал статью, где автор опровергая что системд не блоатварь - лишь подтверждает это) Что тебе еще от меня надо? станцевать? :D Я тебе даже картинку показал :)

Приведённый тобой первый сниппет не подходит, т. к. 1) полагается на дополнительное ПО (команда sv) и 2) полагается на внешние силы, которые запустят его в момент сбоя первого демона.

то ли дело service файлы. Они у меня случайно из браузера не запустились?

Приведённый тобой второй сниппет требует пояснений на тему 1) природы команды «a» и 2) того, куда его вписывать.

осспади, бред то какой. скачай уже rc.cups и не словоблудь стока :D

Нигде. В условии задачи ничего про платформы не было.

очевидно же, что если одно из решений работает на 2-х с половиной дистрибутивов линукса, а другое на всех юниксах, то системд сосёд.

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

Ололо.

На протяжении всей подветки мы говорим про init (PID 1). udev в него не входит.
когда выгодно - входит, когда невыгодно - невходит.

Вот это была цитата, никакого перевирания. А теперь внимательно смотрим:

мы говорим про init (PID 1). udev в него не входит

когда выгодно - входит

Вот это был «случай так называемого вранья». udev никогда не входит в PID 1.

я тебе показал статью, где автор опровергая что системд не блоатварь - лишь подтверждает это) Что тебе еще от меня надо? станцевать? :D Я тебе даже картинку показал :)

Вот это:

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

то ли дело service файлы. Они у меня случайно из браузера не запустились?

Мы сравнивали sysvinit и systemd, а не какую-то неведомую хрень и systemd.

очевидно же, что если одно из решений работает на 2-х с половиной дистрибутивов линукса, а другое на всех юниксах, то системд сосёд.

Нет, не очевидно, т. к. «все юниксы» никому не нужны.

Вот это был «случай так называемого вранья». udev никогда не входит в PID 1.

сам сказал за меня, сам опроверг.

(== почему это на самом деле плохо)

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

Нет, не очевидно, т. к. «все юниксы» никому не нужны.

Мне нужны Linux/BSD/Darwin. А вы сосите лапу с своим системде)) ненужнисты)

сам сказал за меня, сам опроверг.

У тебя не всё в порядке с головой. Цитировать поддиалог в четвёртый раз считаю излишним.

без всяких ощутимых преимуществ

Преимущества были неоднократно описаны и продемонстрированы. Ты, кстати, так и не показал полное решение на sysvinit/bsd init (да хоть на чём-нибудь, на самом деле) твоей же задачи, которая у меня с использованием systemd заняла 2-4 строки...

Преимущества были неоднократно описаны и продемонстрированы.

Ложь. Хотя, если считать «не нужно» за преимущество, то тебе таки удалось:

очевидно же, что если одно из решений работает на 2-х с половиной дистрибутивов линукса, а другое на всех юниксах, то системд сосёд.

Нет, не очевидно, т. к. «все юниксы» никому не нужны.

всё с тобой ясно. Война это мир. Ограничения это преимущество. Скриптование в декларативном ini это благо. Чем хуже тем лучше.

Портируешь?

В этом нет необходимости: если там появится systemd, то приведенные cups.{service,socket,path} можно будет использовать без изменений. В GNU/Linux это уже произошло.

Раньше:
1) Кастомная конфига для алсы / пульсаудио, что бы разделить звук.
2) Редактирование удава, что бы разделить юсб-порты.
3) Редактирование конфиг иксов, что бы разделить устройства ввода/вывода.
4) Автоматизация всей этой чушни так, что бы оно не слетало при каждом чихе.
5) Переписать конфигу дисплейного менеджера.

Сейчас:
1) С помощью loginctl раскидать устройства.
2) Изменить одну строчку в lightdm.conf (что-то вроде multiseat=true, точно сейчас не помню)

А вообще забавно, доказывая что сустемд настраивается лучше чем sysvinit + shell ты приводишь shell

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

Так вот, init + shell настраивается лучше systemd. И даже больше, init + shell настраивается лучше чем systemd + shell.

Но явно хуже, чем init + ассемблер. Стопудов! )
Настраивается - это когда тебе не нужно использовать язык программирования. Когда программируешь - это уже «дорабатывается напильником».

всё с тобой ясно. Война это мир.

А разве это было не видно раньше? Что у человека каша в голове:

NIH-синдром у демонописателя плохо
NIH-синдром у разработчиков systemd это хорошо.

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

Настраивается - это когда тебе не нужно использовать язык программирования. Когда программируешь - это уже «дорабатывается напильником».

и где эта тонкая грань, к примеру если у тебя .emacs конфиг какой-нибудь?

Портируешь?

В этом нет необходимости: если там появится systemd, то приведенные cups.{service,socket,path} можно будет использовать без изменений.

rc скрипты можно использовать без изменений под всевозможные ОС уже сейчас. И так - много-много лет. Но вы подождите, да. Все равно ведь пока:

а) 2.5 дистрибутива - это всё что для счастья нужно

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

в) смесь скриптования и описания в ini-конфигах - нормальная практика реализации «частных случаев»

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

чушня - это сохранённые конфиги, как понимаю. Почему оно слетало при каждом чихе?

Настраивается - это когда тебе не нужно использовать язык программирования.

так именно что хрен там, что системд настраивается) Напишите Лёньчику, чтоб запилил case-exec.

А разве это было не видно раньше? [skip] Тут не нужно дискутировать на технические темы, а врачей звать для коррекции психики.

общение происходит с форумом посредством этого) если сразу звать санитаров, то на форуме не будут представлены разные мнения насчёт системд, поттеринга, сиверса, и всей этой редхат-3.14z-добра-тии. У читателя может возникнуть ощущение, что в восторженных слюнях сектантов есть рациональное зерно, и шелл - это действительно что-то ужасное. Конфиги - зло. Переносимость - не нужна. А вендорлок, bloatware, отсутствие ясного видения конечной цели продукта, ломание поведения без предложения чего-то ценного взамен - это благо.

Ты, кстати, так и не привёл корректного ответа на свою же задачу.

Продолжать спор ad nauseam считаю бессмысленным: всё, что нужно, было названо, несостоятельность заявлений об «ограничениях» была продемонстрирована. Имеющий глаза да увидит.

Ты, кстати, так и не привёл корректного ответа на свою же задачу.

два (разных, лол) примера привёл, тебе всё не то.

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

фразой «не нужны»?)

Имеющий глаза да увидит.

ахаха, ну ты наглый, жесть)

rc скрипты можно использовать без изменений под всевозможные ОС уже сейчас. И так - много-много лет.

И на здоровье, пользуйтесь. Если у вас есть эти ОС, конечно. Кстати, я тут попытался нагуглить rc.cups, нашел http://englanders.us/~jason/howtos.php?howto=cups, а там

# If you have both init scripts, leave the init.d one, remove the other test -e /etc/rc.d/rc.cups && test -e /etc/rc.d/init.d/cups && rm -f /etc/rc.d/rc.cups

И так — много-много лет.

И так — много-много лет.

естественно, в слаквари pam отсутствует много-много лет.

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

Centos6:
S10network
S25netfs
S55sshd

В netfs есть волшебный код
fsck -A -T -M -a -t opts
if [ «$rc» -gt 1 ]; then
echo $«*** An error occurred during the file system check.»
echo $«*** Dropping you to a shell; the system will reboot»
echo $«*** when you leave the shell.»

Еще недавно из-за корявого Alt Linux пришлось ехать в другой конец города. Сеть поднимается но что-то там с mdadm ему не нравится и он останавливается не дойдя до sshd.
Линукс такой линупс.

в слаквари pam отсутствует много-много лет.

Рекомендация удалять rc.cups вызвана отсутствием в слакве pam?

я подумал что установка rc.cups в init.d директорию происходит при перекомпиляции по дефолту.

Вполне возможно ошибаюсь. Если знаешь к чему он так написал - скажи.

и где эта тонкая грань, к примеру если у тебя .emacs конфиг какой-нибудь?

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

чушня - это сохранённые конфиги, как понимаю. Почему оно слетало при каждом чихе?

Честно - на убунте 1204 не осилил свою лень толком разобраться. То был домашний комп, потому особо с ним не боролся.

так именно что хрен там, что системд настраивается) Напишите Лёньчику, чтоб запилил case-exec.

И какая система инициализации без баш-скриптов поддерживает case-exec?

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

1) Так это удобство как раз - расширяемая функциональность, а не ограниченый набор свойств, о которых успел додуматься разработчик. К примеру, нужно сбросить опции в конфиге и тьюринг-полным языком можно просто пройтись map или циклом по списку параметров. То есть в случае возникновения нештатной ситуации/запроса вы можете решить проблему с наименьшими усилиями, а не ждать, когда Поттеринг проснется и добавит новую опцию ResetAll=YES, закоммитит в код, мейнтенеры добавят к себе и потом обновление прилетит в дистрибутивы.

2) Ну и с точки зрения существования систем: рано или поздно энтропия приведёт к расширению списка опций и их значений. Энтропия же в изолированной системе нарастает см Термодинамику. Зачем ждать этого если можно сразу создавать не-изолированную систему базирующуюся на программируемых конфигах.

3) Да и судя по ini-конфигам, упоминаниям autoexec.bat мы имеем дело с главной бедой для Linux. Любители ini-файлов, подумайте на досуге зачем Microsoft PowerShell добавила в свою ОС. Может осенит наконец.

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

Переводя на русский язык - «sysvinit = ну не шмогли мы написать нормальный инит, мейнтернеры, дописывайте сами»

Ну и с точки зрения существования систем: рано или поздно энтропия приведёт к расширению списка опций и их значений. Энтропия же в изолированной системе нарастает см Термодинамику. Зачем ждать этого если можно сразу создавать не-изолированную систему базирующуюся на программируемых конфигах.

Иначе говоря, все тлен, один фиг все развалится, давай все делать на синей изоленте!

Да и судя по ini-конфигам, упоминаниям autoexec.bat мы имеем дело с главной бедой для Linux. Любители ini-файлов, подумайте на досуге зачем Microsoft PowerShell добавила в свою ОС. Может осенит наконец.

Кстати, характерно, что оно не связанно с инициализацией системы а используется именно как инструмент для быстрых, *временных* решений.

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

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

В моей практике был такой сюрприз. Запрятано было среди скриптов инициализации весьма далеко.

Цельные конструкции все-же предсказуемей и их проще контролировать. Проще провести аудит.

А я на Фанте сейчас сижу с OpenRC. Иногда накатываю сабж, убеждаюсь, что все плохо и сношу его обратно.

И в чём ты убедился в последний раз?

В том, что документация systemd лжет.

Например, юнит, помещенный в /etc/systemd/system не стартует, хотя должен.

Подробнее?

Установлена утилита cpupower. Соответственно нужно, чтобы при старте машины выставлялась политика СЩТЫУКМФЕШМУ и максимально домустимая частота 2700 MHz. Пишется юнит следующего содержания:

 
[Unit]
Description=Cpupower daemon
[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set --governor conservative --max 2700MHz
[Install]
WantedBy=multi-user.target

Далее делается systemctl enable cpupower.service, systemctl start cpupower.service. Все хорошо. Перезагружаем машину и видим, что cpupower.service не стартовал, приходится опять запускать его вручную.

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

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

Извини, родной, но это - не проблемы дистра. Это - проблемы самого systemd, ибо OpenRC со стартом демона прекрасно справляется.

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

Фамильярность оставь при себе. И нет, это именно проблемы твоей конфигурации, потому как в эталонном дистрибутиве (арче) всё работает из коробки.

в эталонном дистрибутиве (арче)

С каких пор Arch стал эталонным дистрибутивом? Для кого?

Для всех, кто дружит с логикой. В арче не патчат софт (помимо grave-багов).

Для арчешколоты и прочих задротов.

В арче не патчат софт

Зря, между прочим.

В контексте этого разговора «эталонный дистрибутив» — это такой, по которому можно оценивать поведение и работоспособность немодифицированного апстрима. Очень простое и объективное определение. Попробуй назвать хотя бы одну причину, по которой арч таковым не является.