> Берёшь эту вероятность P. Прикидываешь, как часто у тебя перезагружаются демоны. Если
> за некий промежуток времени у тебя перезагружается N демонов, то вероятность
> того, что дрянь случится: 1-(1-P)^N Неверно. Кто сказал, что речь идёт исключительно о демонах? Напоминаю, что я утверждал:
> Такое только на вашем локалхосте нормально. В дистрибутивных скриптах инициализации за это бьют ногами, ибо nginx мог уже упасть, а этот PID - быть занят другим процессом.
Этим процессом может быть что угодно, например процесс вкладки Chromium на чьём-нибудь десктопе. Поэтому в дистрибутивных скриптах такая хрень как убивание процесса по PID-файлу безо всякой проверки не приветствуется, мягко говоря, - думаете, в Debian просто так start-stop-daemon используют?
Как видите, *прямого* отношения к оценке риска приведённая вами изначально вероятность P не имеет, как я и утверждал:
> процессов ощутимо больше одного, поэтому эта вероятность не имеет прямого отношения к оценке риска.
Более того, данная оценка всё равно исходит из излишне упрощённой модели, ибо не учитывает, например, меру множества свободных идентификаторов процессов (а именно из этого множества, включающего искомый PID, и будет получен идентификатор новым процессом).
>> Нет, дело как раз в ответственности: не конечные пользователи принимали решение о
>> переходе на systemd по умолчанию, а разработчики дистрибутива, поэтому любовь или
>> нелюбовь бизнес-пользователей к systemd, равно как и их желание перенести ответственность,
>> не имеют никакого значения.
> Какие ещё "бизнес-пользователи"? Где ты про пользователей хоть что-то нашёл?
Я вёл речь о Debian (на багтрекер которого я и давал ссылку, замечу). Однако перечитав ещё раз исходное сообщение, признаю, что я недостаточно ясно дал это понять.
Так что имелось в виду, что в Debian решение о переходе именно на systemd принималось уж явно не бизнесом, который в контексте Debian является лишь пользователем, а не субъектом, принимающим решения.
> Каждая опция/параметр в юните systemd -- это заплатка на вполне определённые случаи.
> В одном только systemd.service(5) перечислены штук тридцать. Ещё штук сто в
> systemd.exec(5). И это ещё древняя версия.
Т.е. ExecStart - это "заплатка" на тот граничный случай в системе инициализации, если нам нужно будет что-нибудь запустить? Смешно, да. :)
> Эко ты словом "пользователь" стал жонглировать. Я уже не понимаю, кого ты
> этим словом называешь. В моём мире пользователь не должен лезть в
> run-скрпты или юниты.
А в моём мире есть разработчики ПО и пользователи ПО (т.е. это понятие вообще не включает в себя уровень доступа). Видимо, да, терминология у нас с вами не совпадает из-за явно выраженной профессиональной деформации. :)
>> Прежде всего systemd (равно как и upstart, launchd, smf и другие) -
>> это качественный переход в системе инициализации, сравнимый с переходом от использования
>> ./configure && make && make install к менеджерам пакетов
> Ну сравнил слона с мухой. Без пакетника жить тяжело.
Думаю, есть люди, которые с вами не согласились бы. Но они заняты компиляцией, им некогда.
> Без systemd -- запросто.
Без менеджера пакетов - запросто. Жили же как-то до его появления, и несколько поколений UNIX-джедаев с презрением смотрят на эти ваши менеджеры пакетов.
> Неспроста. Альма-матер одной половины комитета -- RedHat, а второй -- Canonical.
https://lwn.net/Articles/585219/
>[оверквотинг удален]
> - попробую ввести собеседника в заблуждение
> - обязательно где-нибудь усомнюсь в квалификации собеседника
> - сделаю неуместное сравнение
> - попробую вбросить про выборы 2014го
> Знаешь, беседа в таком ключе мне нафиг не нужна. Я уже растоптал
> достаточное количество твоих единомышленников с подобной аргументацией, мне это уже скучно.
> Так что дальше -- ты идёшь в пень, куда тебя уже послали
> все остальные твои оппоненты. Последнее слово, конечно же, за тобой. Можешь
> пораспинаться, что мол все мы хейтеры такие, не дождёшься от нас
> аргументации без переходов на личности. :)
Да-да. Если громко хлопнуть дверью, может, кто-нибудь поверит, что ты не сбежал. :)
