>> Естественно у systemd есть свои сильные стороны в определенных ситуациях.
> Я бы сказал что у него одна сильная фича: избавляет от туевой
> хучи дурного велосипедизма. И показывает что администрирование системы вовсе не обязано
> быть синонимом понятий "геморрой" и "много долботни на ровном месте".Это если systemd умеет делать то, что нужно. А вот внедрить в него то, чего он не умеет, будет на порядок сложнее, чем в простую инит систему.
Пример того как у меня работает сеть на ноуте я приводил ранее:
https://www.opennet.ru/openforum/vsluhforumID3/100356.html#434
Не уверен, что это легко получится реализовать через systemd и не получить различных косяков в совершенно неожиданных местах.
> А то что оно вот такое - на половину вообще не системд
> претензии. Кто виноват что из скриптов не катит делать сисколы, а
> 20 напрочь разных утилит, писаных разными людьми в разное время -
> неудобно админить? Там и в апях то разнобой знатный, так что
> соваться прописывать какие-нибудь ограничения вызовов через seccomp без системд рискнет
> не каждый первый. А когда это директива в конфигах - почему
> бы и нет?
Никто не говорит, что до systemd все было идеально. Но systemd пытается спрятать проблемы, а не решить их.
> Ну то-есть вы же понимаете что я не могу
> убить на кодинг запускалки столько же времени сколько на кодинг сервисов,
> ради которых все затевается, правда?
Все же вы существенно преувеличиваете. В большинстве случаев достаточно одной-двух строк.
> Поэтому на практике все придет к
> халтуре, джамшутингу и бустанию всех мыслимых фич, в ущерб всему. Большинство
> инит скриптов это отлично иллюстрируют.
Фактически systemd просто спрятал то, что было в скриптах.
> Без systemd по моему опыту большинство виденых линуксных систем как-то так по
> жизни вообще кладет на всякое там обслуживание вачдога. И при зависоне
> - требует живого юзверга, жмущего резет или передергивающего питальник. А когда
> этого юзера нет... эм... получается не комильфо.
ИМХО вачдог не понацея, а крайнее средство. Если произошло зависание, то нужно искать и устранять причину, а не тупо перезагружать. Для некоторых ситуаций, когда лучше глючная, но хоть как-то работающая система, это может сработать. Например самолетах, системах жизнеобеспечения или как подстраховка для всякой автоматики.
Но для ПК смысла мало - ядро например по-умолчанию даже в ребут само не уходит при kernel panic. С сервисами/драйверами еще менее однозначно - зависла видеокарта наглухо, по идее нужен ребут. Но если на фоне рендеринг 20 часов шел? Или основная задача этой машины - сервер и видеокартой там пользуются раз в неделю. ИМХО правильно все делают - вачдог по-умолчанию не нужен, а кому он реально нужен - разберется и настроит.
> Ну вон в openwrt
> например, обслуга вачдога, конечно, есть. Но если встанет колом какой-то важный
> для работы железки сервис - традиционно будут опаньки. И все эти
> runit, monit и прочая прекрасно. Только слегка не то. Скажем, сервис
> может и не быть сетевым в плане доступности портов на listen.
Если железо нормальное, то вероятность такого расклада (зависание сервиса без segfault) очень мала.
Если железо с глюками - его менять нужно, а не ждать когда оно полностью встанет. Особенно забавно, когда люди говорят: винт глючит, что делать? Отвечаю: срочный бэкап всего нужного на новый винт. Через пару дней: винт глючить перестал, новый покупать пока не буду. Через неделю - винт полностью обрубился, бэкапов нет ...
> И вообще, довольно так себе критерий живости программы. Ну вот скажем
> поливалка цветов, щелкающая релюхами по таймеру. Тот кто щелкает релюхой -
> не обязан быть сетевым сервисом. И даже если оно управляется через
> веб, это совсем не значит что я хочу иметь дело с
> сетью в именно той проге, которая релюхой клац-клац. А вот
> если прога повиснет - клац-клац релюхой сорвется. FAIL.
А если реле залипнет ? ;) Тут однозначно управление реле (а лучше симистором/мосфитом) на МК, а все не критичное на ПК/RBPi/etc. И программу можно сделать bug free практически сразу и вачдог на случай аппаратного зависания есть.
> Ну да. Я видел пару уродцев, типа пальмоси, где все пытались совать
> в БД, чтоли. Ну их таких! При работе с такой системой
> возникает ощущение что мне оторвали руки и ноги, поэтому печатать на
> клавиатуре теперь можно исключительно носом. Результативность взаимодействия с системой
> - на таком уровне. ФС как таковая и есть БД. Только
> простая и низковровневая, так что покрывает все мыслимые юзкейсы а не
> пытается с пеной у рта доказать что "да и фиг с
> ним, с открытием аттача из почты другой программой".
У меня подобное ощущение и результативность от некоторых "облачных" технологий возникает.
