> Во первых сложно провести четкую грань.Согласен.
> Ну вот смотри, если системный вачдог
> дергается системдой а тот в свою очередь является софтварным вачдогом для
> важных процессов, получается расшаривание вачдога на всю толпу. При том -
> логично устроенное и как-то так
> это и должно быть сделано.
Я далек от подобных задач и мне не понятно - для чего вообще нужно расшаривать вачдога, ведь задача вачдога - перезапустить систему, если она впала в ступор (то есть это либо аппаратный сбой, либо сбой на драйверов). Причем тут пользовательские процессы?
> сделано. Ну да, мой сервис будет требовать системд. Но там один
> фиг туева хуча linux-специфичных вызовов, характерных для новых ядер, а работает
> оно в готовой железке, где никакой генты не будет даже в
> проекте - так что никто ничего с этого не теряет :)
В вашей ситуации - да, никто ничего с этого не теряет. Но допустим, разработчики Xorg решили использовать вачдог от systemd. Соответственно без systemd Xorg работать не будет. Получится, что для работы с другими init системами, в Xorg все равно придется добавить свой вачдог - кодовая база Xorg станет сложнее (поддержка вачдог от systemd + свой вачдог).
Есть второй вариант - каждая система инициализации пилит свой вачдог. Для Xorg приходится писать поддержу n-ого колличества вачдогов.
Правильный вариант (ИМХО): вачдог, не зависящий от конкретной системы инициализации, но умеющий использовать особенности различных систем инициализации (с возможностью их отключения на стадии компиляции).
>[оверквотинг удален]
>> то, что уже было написано, отлажено и работало без него.
> Не вижу где была написана логика вачдогования. Не вижу обработки ошибок и
> логинга статусов в горьбатом скриптошите. Не вижу нормального управления процессами, типа
> выставления шедулеров, приоритетов, урезания прав и прочая. А еще оно может
> логгить... ну допустим в kmsg. Удобно, если ничего кроме него вообще
> нет. Это можно было сделать на соплях и скотче, но т.к.
> из скрипта сискол в лоб дернуть не того - получался страх
> и ужас. В kmsg тоже запись из скриптов работает криво. А
> вот системд можно попросить дернуть нужные сисколы парой директив конфига. Это
> удобно.
Возможно, но нужно это далеко не всегда. Мне лично проще отладить скрипт 15-20 строк, чем изучать поведение каждой опции и боятся что оно может сработать не совсем так как я предполагаю (или что поведение по-умолчанию будет изменено при апдейте).
>> Если бы systemd позиционировал себя как отдельная ОС (типа как android), то
>> критики было бы на порядок меньше.
> Он не ОС.
Еще нет, но с каждой версией это все больше похоже на слова Столмана - "у нас, в проекте GNU, было все, кроме ядра".
> Он - системный менеджер. Берет на себя типовую системную
> рутину.
consoled? dhcp-server? ИМХО он уже давно перешагнул грань того, что могло бы называться системным менеджером. Да и само название "системный менеджер" мало ему подходит, так как предполагает управление стандартными блоками системы, а не их замещением и интеграцией в себя.
> В том числе - старт процессов. А также их вачдогование,
> трекинг зависимостей, рестарты, расстановку приоритетов и прочая. И это таки удобно,
> хоть вы тут полопайтесь все.
А еще в emacs есть текстовый редактор ;)
> Оно включает в себя довольно много чего...
> 1) Оно нынче может запускать ядерные треды.
Куда же без них.
> 2) Есть всякие там nfs
Поддержка монтирования сетевых ФС должна быть на уровне ядра. Тем более, что сервера для них не входят в ядро.
> и даже httpd в ядре.
Не знал. Ссылка есть?
> 3) Куча всяких весьма опциональных вещей типа профилирования и отладки. Хомяк может
> и без perf обойтись. И Kdb ему ни к чему. А
> вот разработчикам - удобно.
Без средств отладки не обойтись.
> 4) В дефолтной сборке дистра over 9000 алгоритмов сжатия, шифрования и чексумм.
> Совсем не факт что лично тебе они нужны все.
Проблемы дистра, можно выбрать более подходящий дистрибутив (или вариант ядра в нем) либо собрать самому.
> 5) Там есть например вывод графики на экран. Опциональный и по сильно
> некоторым случаям. Но все-таки.
Ну видео драйвера тоже работают с железом, да и консоль 80x25 меня лично мало радует.
> 6) Всякая хрень типа FUSE и прочих "драйверов символьных устройств в userspace".
> Так что те кто бредил по микроядрам - давно могут писать
> половину дров в режиме пользователя, если им это так уж сильно
> надо.
Притормаживает, но не всегда это критично, постоянно использую - хорошее решение для многих проблем.
> Половину ессно можно обрубить, если сильно хочется. Ну так и в системд
> много что обрубается, если что.
Обрубить то можно. Тут претензии другие:
1. невозможность использовать отдельные компоненты в других системах инициализации
2. невозможно использовать в минималистичных (без демонов, d-bus, udev) системах.
>> Излишней завязки user space за какие-то сложные подсистемы ядра тоже не наблюдается.
> #define "излишней завязки"?
Требования user space софта каких-то дополнительных опций (подсистем) в ядре, без которых можно было и обойтись.
В ядре таких примеров не знаю, а ближайший аналог - в mesa была жесткая завязка за libudev для определения pci id адаптера. К чести разработчиков mesa нужно отметить, что пробыла она там не долго - было добавлено более простое решение - получение необходимой информации напрямую с sysfs.
> А это у них довольно красиво получилось. Но для системды такое оверкилл.
> Это для совсем больших проектов надо. Системд не настолько монстр чтобы
> его ТАК пилить на части.
Не соглашусь - если бы его разбить на отдельные проекты, то их наработки проще бы было внедрять (при необходимости) в другие системы инициализации.
>> позволяет искать и внедрять новые конкурирующие решения, не ломая при этом старых.
> Тем не менее, иногда вытряхивают и старый мусор. Ну вон поддержку i386,
> например.
Естественно устаревший и не используемый код нужно чистить. Но пока не отлажены новые решения и пока они не докажут свое неоспоримое превосходство, старые решения не должны страдать из-за внедрения новых. Сейчас, например, внедряют nftables, но iptables продолжает полноценно работать.
