>> она впала в ступор (то есть это либо аппаратный сбой, либо
>> сбой на драйверов). Причем тут пользовательские процессы?
> Наверное, при том что более высокоуровневая логика поведения железки - формируется этими
> процесами. И если девайс перестанет выполнять свои задачи и потребует к
> себе внимания человека, это опаньки. Даже если ядро и живое, радости
> то с этого?Перезапуск одного повисшего процесса не должен происходить перезапуском всей системы притом через ресет,
>> умеющий использовать особенности различных систем инициализации (с возможностью их
>> отключения на стадии компиляции).
> Ну и с практической точки зрения - вот вы побежите в
> вашей программе запиливать поддержку Menuet OS?
Я сам - нет, мне это не нужно. Но если кто пришлет нормальный патч и поддержка будет опцией - почему нет?
> Переписав все на асме, потому
> что у них так принято. Ну и остальные - так же.
Зачем? Это Поттеринг любит все заново написать.
>> Возможно, но нужно это далеко не всегда.
> Зато плохо, когда это нужно а этого нет. Самому писать логику супервизора
> процессов мне как-то не улыбается.
Речь не о том, что бы писать все самому. А о том что бы иметь много простых решений для каждой задачи. И использовать их по необходимости (типа unix way). А не одно навороченное переусложненное.
>> Мне лично проще отладить скрипт 15-20 строк,
> А мне вот совсем не проще, когда такой шитец не стартует "почему-то".
> А во всех логах - просто ноль. Системд в этом плане
> втыкает с отрывом. Он и код возврата запишет, и вывод программы
> покажет.
А sms он пришлет? А пришлет только после третьей неудачно попытки рестарта?
> И даже в /dev/kmsg залоггит, если например ничего другого не
> доступно в энной ситуации. А из скрипта в kmsg самому логгить
> - грабледром, скажу я вам. А если например ФС readonly, а
> экрана принципиально нет - куда еще логгить?
tmpfs/devtmpfs - я так на андройде делаю для раннего дебага.
> А никаких стандартных блоков не образовалось. У каждого дистра были малосовместимые наборы
> инит-скриптов и костыли и подпорки по месту.
В моем понимании стандартные блоки это драйвера/ФС/сервисы. А инит система - связующее звено для этих блоков.
>> Поддержка монтирования сетевых ФС должна быть на уровне ядра.
> А она у кого-то что-то занимала, что должна? Линух работает на куче
> железяк где сети вообще нет.
И? Ненужно - не используй. А с systemd такое не пройдет: не нужен d-bus/udev все равно используй.
>> Притормаживает, но не всегда это критично, постоянно использую - хорошее решение для
>> многих проблем.
> А я этим решением почти не пользуюсь. ФС у меня ядерные. Как
> насчет применения вашей же логики? :)
О какой логике речь? Если решение удачное для определенных задач, то почему нет? Вот если бы fuse была обязательным элементом системы. Xorg ее требовал или init система и требование это было слабо обоснованно - то да, я бы возмущался, даже не смотря на то, что я ее (fuse) использую для других (реально обоснованных) ситуаций.
>> 1. невозможность использовать отдельные компоненты в других системах инициализации
> С другой стороны, разные системы инициализации и дистры не заморачивались какой либо
> совместимостью. Стандарных кубиков не сложилось. Каждый пхал по месту местечковый glue
> code. Ну вот поттеринг и сбразнул дустом это безобразие. Не скажу
> что мне их жалко.
Ну да, следующий шаг Поттеринга - DE/WM, напишет свой, единственно правильный, а все остальные предаст анафеме, а то нет единообразия на десктопе. При это приложения написанные для его DE будут требовать systemd/PA/его DE.
> С другой стороны, в системд работают другие логгеры.
Но не наоборот. Вам не кажется это несколько настораживающим?
>> 2. невозможно использовать в минималистичных (без демонов, d-bus, udev) системах.
> Это имхо актуально разве что для совсем мелочи, типа openwrt. А так
> нынче даже у модуля с половинку кредитной карты размером ресурсов хватит
> на два десятка udev'ов и системд.
А зачем из держать если в них нет реальной необходимости? Можно и винду в виртуалке постоянно держать - ресурсов ПК хватит, но зачем если ты ей не пользуешься?
>> можно было и обойтись.
> Ну вот без ядерных тредов можно обойтись. И без fuse.
Без udev/d-bus система работает бысрее и не теряет функциональность - старый ноут (7-8) лет за 9 секунд грузится и жрет около 20mb. Лучше память под кэш отдать, чем под тупо болтающиеся демоны.
>> Не соглашусь - если бы его разбить на отдельные проекты, то их
>> наработки проще бы было внедрять (при необходимости) в другие системы инициализации.
> Не уверен что это кому-то так уж надо. Было бы надо -
> имхо отфоркались бы и показали как это делать.
Уже что-то было про logind или что там гном тянет.
> А так -
> большинство компонентов системды таки опциональные. И если хочется, их можно оторвать.
То, что их можно отключить != что их можно запустить отдельно без systemd.
