> она впала в ступор (то есть это либо аппаратный сбой, либо
> сбой на драйверов). Причем тут пользовательские процессы?Наверное, при том что более высокоуровневая логика поведения железки - формируется этими процесами. И если девайс перестанет выполнять свои задачи и потребует к себе внимания человека, это опаньки. Даже если ядро и живое, радости то с этого?
> кодовая база Xorg станет сложнее (поддержка вачдог от systemd + свой вачдог).
А вот это уже не факт. Можно скажем заявить что вот такие апи - минмальная планка. И далее вы эти апи или вывешиваете, или как-то очень отдельно дергаетесь по этому поводу. Ну а что, с DRM/KMS как-то так и сделали. Хорошо получилось, имхо. Вон уже бояздэшники запиливают себе, впопыхах передирая древние версии кода из линя. А если так совсем не делать - были бы ща CP/M и MULTICS.
> Есть второй вариант - каждая система инициализации пилит свой вачдог. Для Xorg
> приходится писать поддержу n-ого колличества вачдогов.
На практике обычно никто или не пилит совсем, или юзает нечто запиленное до них. Скриптокидозники предпочитают первый вариант. Я - второй. Ну а вы уже показали ваш джамшут-процесс-менеджмент с while true. Который положит систему если это будет не "transient", а "permanent" сбой. Постоянными рестартами сервиса. Круто будет, когда на вход по ssh и остановку грабледрома придется убить полчаса, потому что система озадачена "важным" занятием - рестартом сервиса по кольцу, прямым курсом, с максимальной скоростью. И вот таких нюансов - есть. В апстарте и системд это сделали нормально. С учетом. В отличие от вашего велосипеда из водопроводных труб.
> умеющий использовать особенности различных систем инициализации (с возможностью их
> отключения на стадии компиляции).
Для начала я не уверен что именно иксам как процессу надо вачдог. Ну и с практической точки зрения - вот вы побежите в вашей программе запиливать поддержку Menuet OS? Переписав все на асме, потому что у них так принято. Ну и остальные - так же. Поэтому на практике фичу или совсем дропнут, рассказав что "не очень то и хотелось", как местные скриптокидозники, лечащие что в сферическом вакууме единороги должны cpaть радугой а багов быть вообще не должно. Или возьмут готовую реализацию. А варить вел из водопроводных труб в гараже будут только наиболее ушлые. Я считаю что хорошо когда админ умеет программить... при условии что это не перетекает в идиoтский и контрпродуктивный формат и баранью упертость "а я привык вот так".
> Возможно, но нужно это далеко не всегда.
Зато плохо, когда это нужно а этого нет. Самому писать логику супервизора процессов мне как-то не улыбается.
> Мне лично проще отладить скрипт 15-20 строк,
А мне вот совсем не проще, когда такой шитец не стартует "почему-то". А во всех логах - просто ноль. Системд в этом плане втыкает с отрывом. Он и код возврата запишет, и вывод программы покажет. И даже в /dev/kmsg залоггит, если например ничего другого не доступно в энной ситуации. А из скрипта в kmsg самому логгить - грабледром, скажу я вам. А если например ФС readonly, а экрана принципиально нет - куда еще логгить? Системд почему-то нормально к таким подаркам судьбы относится. Это страновато для шапки, особенно после сказок хейтеров, но все-таки.
> может сработать не совсем так как я предполагаю
Не знаю, на мое нескромное мнение системд сделан довольно логично и ведет себя чаще всего именно так как я ожидаю. И это обычно видится мне логичным и понятным поведением. И уж куда конструктивнее чем местные визги про "нужно не везде", "можно обойтись" и "в ваших программах не должно быть багов!!!111".
> (или что поведение по-умолчанию будет изменено при апдейте).
Если уж на то пошло, при апгрейде пакета стартовый скрипт тоже может быть переписан пакетным менеджером во многих дистрах. Это отдельное поле для грабель. В апстарте с этим вышел небольшой факапчик, кстати. Потому как указать порядок старта своего сервиса без трогания job-файла чужого сервиса - опа. А тот файл фиг бы его знает как обрабатывает пакетный менеджер при апгрейде, возможны варинаты. А вот Поттеринг о таких вещах подумал, у него вписаться "before" или "after" можно и без колупания чужого unit'а. Сугубо своим новым файлом.
> Еще нет, но с каждой версией это все больше похоже на слова
> Столмана - "у нас, в проекте GNU, было все, кроме ядра".
Ну так как-то так оно и было. И хорошо что Линусу не пришлось самому кодить весь юзермод. Это надолго бы заклинило разработку линуха. По этой же причине я не буду сам кодить эрзац-супервизор процессов при наличии готового...
> называться системным менеджером.
Как сказать? Я вот не очень хочу объяснять дубоватому монтажнику как настроить сеть. Особенно в его винде. Поэтому dhcp тоже может пригодиться. А если он не требуется - ну не знаю, у меня network-manager на десктопе живет и сетевые фичи системды ему не мешают. Потому что отключены.
> подходит, так как предполагает управление стандартными блоками системы, а не их
> замещением и интеграцией в себя.
А никаких стандартных блоков не образовалось. У каждого дистра были малосовместимые наборы инит-скриптов и костыли и подпорки по месту.
> А еще в emacs есть текстовый редактор ;)
А в системд есть система инициализации :).
> Куда же без них.
Ну вон мсдос обходился и без них. Сама по себе логика сисколов сводится к запрос-ответ, треды не есть нечто абсолютно необходимое в этой парадигме. То что так будет сильно сложнее разрабатывать систему и работать куда паршивее - другой вопрос :)
> Поддержка монтирования сетевых ФС должна быть на уровне ядра.
А она у кого-то что-то занимала, что должна? Линух работает на куче железяк где сети вообще нет.
> Не знал. Ссылка есть?
Да была парочка экспонатов работающих в ядре. В майнлайне их разумеется нет.
> Без средств отладки не обойтись.
Только (вашими же словами вам) они нужны не всем. Применим вашу же противосистемдшную логику? Обойдтесь без дебагера. Сами накрайняк допишете. А сильно вам хочется все бросить и пойти писать дебагер и профайлер, вместо того чтобы дебажить и профаилить? :).
> Проблемы дистра, можно выбрать более подходящий дистрибутив (или вариант ядра в нем)
> либо собрать самому.
Ну так системд тоже можно собрать самому и неслабо обрубить. Особо утонченные ценители его даже в openwrt втрамбовать ухитрились, на гитхабе такой эксперимент болтается :)
> Ну видео драйвера тоже работают с железом,
Мне вообще нравится как сейчас сделано. Как бы и не совсем mandatory, но как бы если графика есть - настойчиво рекомендуют DRM/KMS использовать, кроме исключительных случаев.
> да и консоль 80x25 меня лично мало радует.
На моем мониторе 80х25 вообще выглядит отвратительно. Мой монитор - массив 2560х1400 пикселей. Кто не готов с этим столкнуться - деинсталл.
> Притормаживает, но не всегда это критично, постоянно использую - хорошее решение для
> многих проблем.
А я этим решением почти не пользуюсь. ФС у меня ядерные. Как насчет применения вашей же логики? :)
> 1. невозможность использовать отдельные компоненты в других системах инициализации
С другой стороны, разные системы инициализации и дистры не заморачивались какой либо совместимостью. Стандарных кубиков не сложилось. Каждый пхал по месту местечковый glue code. Ну вот поттеринг и сбразнул дустом это безобразие. Не скажу что мне их жалко.
С другой стороны, в системд работают другие логгеры. Или даже их отсутствие. И sysv скрипты. Которые к тому же рулятся systemctl (приветы апстарту:P).
> 2. невозможно использовать в минималистичных (без демонов, d-bus, udev) системах.
Это имхо актуально разве что для совсем мелочи, типа openwrt. А так нынче даже у модуля с половинку кредитной карты размером ресурсов хватит на два десятка udev'ов и системд.
> можно было и обойтись.
Ну вот без ядерных тредов можно обойтись. И без fuse.
> с sysfs.
А sysfs, на минуточку, тоже опциональный компонент в ядре. И его можно оборвать. У ядра линя на самом деле много чего обрубается :). Как впрочем и у системд...
> Не соглашусь - если бы его разбить на отдельные проекты, то их
> наработки проще бы было внедрять (при необходимости) в другие системы инициализации.
Не уверен что это кому-то так уж надо. Было бы надо - имхо отфоркались бы и показали как это делать. А так - большинство компонентов системды таки опциональные. И если хочется, их можно оторвать. На свой зад. Ну так и sysfs в ядре тоже очень на свой зад будет обрывать. И уж тем паче procfs (да, его тоже можно, если СИЛЬНО захотеть).
> решения не должны страдать из-за внедрения новых. Сейчас, например, внедряют nftables,
> но iptables продолжает полноценно работать.
Ну так sysv скрипты - работают на системах с systemd, если это надо. И даже удобнее рулятся - все через systemctl. Никто в здравом уме не вынесет это сразу и резко. Будет постепенный phase out.
