Нейтральный пофигист сколоняется к ненависти

А у тебя децентрализация. И кто прав? :)

Хорошо работает в режиме белого и пушистого, но очень неудобно в штатном режиме.

Поясни. Не понял эту фразу.

Вот есть у меня демон. Точнее нет. Ты же не хочешь демонов. Есть обычная программа, которую надо демонизировать. Ок, демонизируй. Как? Ну, почитай доку на один из 100500 «погонщиков демонов» который используется на этой конкретной системе. А на другой системе ты пойдёшь читать другую доку для другого «супервизора». Админский рай прямо-таки.
В то время как с точки зрения программиста задача решается одинаково и тривиально.
Зачем ты такой злой? Зачем ты создаёшь проблемы на ровном месте?
Ты не понял сарказма? Объясню — именно мой программистский подход без супервизора обеспечивает единообразие, твой же супервизорный вариант обеспечит лишь хаос.
Компренде?:)

Ок, демонизируй. Как? Ну, почитай доку на один из 100500 «погонщиков демонов» который используется на этой конкретной системе.

Не проблема, т.к. везде в скором времени будет стоять systemd. ☺

Классное единообразие. Одна программа демонизируется при указании -d, другая — наоборот, не демонизируется при указании -n, твоя вон вообще неправильно демонизируется...

Супервизоров всегда меньше, чем демонов. В идеале вообще один.

Ну а в крайнем случае — /bin/sh -c "/path/to/daemon &".

В крайнем случае есть screen, который любят использовать писатели скриптов для sysvinit.

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

screen? для демонизации? шта? я пропустил очередное королевское извращение?

Там даже на Си 20 строк кода.

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

И, раз intelfx рассуждает, что:

И, кстати, одни только signal-ы в x86 займут байт 100

то он тоже против того, чтобы запускаемые из под systemd процессы обрабатывали сигналы? Там, в мире systemd, какая-то другая идеология, сигналы не нужны и чем-то заменены ?

то она не должна обрабатывать сигналы?

В моём конкретном частном случае — да.

то он тоже против того, чтобы запускаемые из под systemd процессы обрабатывали сигналы?

Вовсе нет. Он лишь уточнил мной от фонаря названное число в 50 байт.

sysvinit (который, спешу заметить, занимает больше места и имеет больший футпринт, чем systemd — если считать суммарно с bash'ем и coreutils).

ну вот и системД есть... и как, удалось выкинуть из системы bash и coreutils? :) если нет, то какой это аргумент?

Из начальной загрузки — да, удалось. Ну, если нигде нет легаси-юнитов, вызывающих скрипты. В любом случае, сильно уменьшилось количество их использований (каждый субшелл, каждый вызов — это время, и даже если на твоём x86 оно исчисляется микросекундами, то где-нибудь на 500-мегагерцевом ARM'е — вполне себе миллисекундами).

А где-то, в каком-нибудь embedded'е, и вовсе удастся их выкинуть из системы.

Так что аргумент.

ага, а во всех _остальных_ системах добавился системД. на фоне оставшихся и шела и кореутил :)

ну пилил бы себе поттеринг свой системД для эмбендет и виртуалок... зачем его пихать туда где он не решает _ничего_ (кроме разрушения совместимости с ранее написанным софтом).

ресурсы у сообщества не безграничны и потраченное на соответствии пульсу, а теперь еще и этому велосипеду вовсе не способствуют развитию.

ресурсы у сообщества не безграничны и потраченное на соответствии пульсу, а теперь еще и этому велосипеду вовсе не способствуют развитию.

http://facepalm.ncrmnt.org

твой слив засчитан, «специалист» по очередному «ненужно» :)

Нет, поскольку я отвечал на неаргументированное субъективное мнение, а о вкусах, как известно, не спорят.

Ладно, если ты хочешь разбора, то вот он:

добавился системД. на фоне оставшихся и шела и кореутил

Контрпример: лично у меня в загрузке системы шелл не участвует вплоть до запуска дисплейного менеджера, где подгружается Xsession.

зачем его пихать туда где он не решает _ничего_

4.2, контрпример: kwin_wayland будет завязан на logind

кроме разрушения совместимости с ранее написанным софтом

Пруф, пожалуйста.

ресурсы у сообщества не безграничны и потраченное на соответствии пульсу, а теперь еще и этому велосипеду вовсе не способствуют развитию.

Эта фраза как минимум грамматически некорректна настолько, что её трудно понять. А как максимум — опять же, упоминается взятый с потолка и ничем не подтверждённый факт «затраты ресурсов» на какое-то «соответствие».

ты строишь из себя важного толстого троля, а суетишься как сопливый трольчишка :)

Контрпример: лично у меня в загрузке системы шелл не участвует вплоть до запуска дисплейного менеджера, где подгружается Xsession.

самому не смешно? 1) у меня в ноуте загрузка происходит _раз_в_месяц_ 2) поскольку система при этом лежит на ssd это занимает менее 20 секунд без всякого системД

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

Пруф, пожалуйста.

данный тред :) только не надо заводить национальные песни «о овце с одним черным боком самоубившейся упавшим с воздушного шара кондиционером»?

Что касается ресурсов сообщества: потраченное на адаптацию к пульсе и системД время разработчиков я считаю потраченным зря, поскольку _никакой_ новой функциональности это не принесло.

ты строишь из себя важного толстого троля, а суетишься как сопливый трольчишка :)

Что, последний аргумент в дискуссии? =)

у меня

Отучаемся говорить за всех.

данный тред :)

Данный тред — свидетельство того, что человек поленился прочесть ман (дважды — при написании демонизации и при написании юнита). Решение его проблемы составляет три строки.

_никакой_ новой функциональности это не принесло

Опять же, отучаемся говорить за всех.

да ты таки «позорно слил», хотя тебе давался шанс потрепыхаться.

иди потренируйся ещё в других тредах «про Кумира» :)

О, спасибо, мой господин, что дали мне шанс!

Нет. Слил ты. Субъективное предпочтение не является аргументом в дискуссии. Dixi; я больше не буду отвечать тебе в рамках этого треда.

нет, это я тебе отвечать не буду ТМ :)

Эй, ну это же ведь совсем другое дело!

intelfx, psv1967:
-- Ты дурак!
-- Нет, ты дурак!
-- А ты жирный!
-- А ты картавишь!
-- Ы-ы-ы-ы...
-- А-а-а-а...

Не знаю кто там из вас «слился», но со стороны вы оба выглядите глупо.

не мешай! :)

везде в скором времени будет стоять systemd

Висеть. А потом улетать в /dev/null с пожеланиями всего хорошего поттеру

Че т категорически не согласен, но мое мнение маленькое :)

Во-первых, процедура демонизации является абсолютно стандартной функцией и легко гуглится. Во-вторых, можно (в строках кода) ограничиться вызовом не-POSIX функцией daemon(), про которую велосипедопейсатели обычно, почему то, забывают.

В-третьих, ИМХО, если программа - демон, она *должна* предоставлять возможность демонизации без привлечения новых сущностей. Будешь ты этим пользоваться, или нет - дело десятое. Например (только за себя), тот же dhcpcd зачастую проще стартануть так, чем вырисовывать в консоли systemctl start dhcpcd. Твой пример с 'sh -c «smth &»' также едва ли является более аккуратным.

В-четвертых, на арче мир клином не сошелся. Всегда нужно стараться думать о совместимости с устаревшим ПО (в рамках разумного, конечно).

функцией daemon(), про которую велосипедопейсатели обычно, почему то, забывают.

Итить-колотить! Спасибо, мужик. Прикольно, а я и не знал о её существовании.

Вполне возможно, что ты прав. Там тоже было исключительно моё мнение, основанное на субъективном же чувстве прекрасного...

Ну и про обратную совместимость — иногда всё же нужно её ломать. А олдстейбл пусть использует версии программ, актуальные на момент заморозки.

Кстати, darkarcanis@mail.ru, который один из арчовских TU, — это ты?

Да

Потому что переменная PWD создаётся шеллом и отражает текущую рабочую директорию. Её установка ни на что не влияет.

вот оно как оказывается. Спс.