> Я начинал привыкать еще с середины 90х. Но идея systemd почему-то отторжения
> не вызвала.

Потому что идея довольно очевидная - и я даже для себя костылил нечто немного похожее для урезания прогам прав, расстановки приоритетов и сборки песочниц сам. Это было криво и вообще - ужасный вел с квадратными колесами. Хорошо что это стандартизировали и можно конфиг прописать вместо дофига деликатного системного кода в привилегированой проге.

Более того - первым на лине это апстарт начал. Но там очень криво с depends'ами, нельзя вписаться before или after кого-то - не меняя _его_ конфиг. А это упс! Это файло ДРУГОГО пакета. И кто его знает что там юзер/адм/пакетник сделают потом с ним.

А вон те с SMF/launchd про юниксвэй тоже не совсем честно мне вещали.

> А слой совместимости с sysv использовал только для одной цели - привычный
> rc.local прикрутил.

Я им всерьез никогда не пользовался почти. А по сервисам распихать логичнее в целом получается. И так статус разных прог очевиднее. Равно как кто тупил и проч. Так я узнал что например в эмбедовке плохо с энтропией, а macchanger - может в блокирующие чтения /dev/random. У эмбедовки и VM старт очень детерминированый.

А чем плоха низкая энтропия... хехехе, я видел, умею это юзать - и поэтому на моих системах этот аспект учитывается. Чтобы там так же нельзя было.

> есть фактически делает всякие там out в порты,специфичные для системной платы,ну
> и в конфигурационные регистры устройств,видимых через шину pci.

Я использую более стандартные интерфейсы управления DVFS и проч. Как-то типа:

for x in /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq; echo 2500000 > $x; done;

...вот так загонит все ядра в максимум 2.5ГГц (в этом случае мой проц почти холодный и не разгоняет вентиль, но все еще довольно производительный).

> фон в колонках. Куда дебианщики собирались вот такое пихать убирая rc.local - я не знаю.

У меня есть несколько сервисов которые "one shot" при старте, или даже "remain after exit" и тогда скажем вон так своп замаунчен, а этак - отмаунчен, и это делается как старт и стоп "сервиса". Сервис, конечно, лишь пинок нескольких команд. Зато можно покомандно настроить критичен ли фэйл команды и в случае чего в логах видно что из того что я считал критичным завалилось.

> В Дебиане особенность systemd вобщем-то одна - при апдейтах могут затираться изменения,
> сделаные в содержимом каталога /usr/lib/systemd

Это нормально. /usr/lib/systemd - "system defaults", /etc - "admin overrides". Так не только в дебиане, это продуманный дизайн системды, для нормального взаимодействия с пакетником.

До этого был жуткий бардак - попробуй угадать перепишут ли мои изменения при обновлении. Как имплементера кастомов меня это волновало: улет моих кастомизаций от апгрейда пакета был бы полным кошмаром, система бы развалилась у юзера. Теперь это документировано, детерменировано, логично - и это специально, с одной стороны дистро может предложить дефолты. С другой админ может их перекрыть. У админа приоритет над системными дефолтами, если есть и то и другое, у админа выше приоритет и часть или все настройик будут из его файла.

А апи вачдога поцтер кажись сделал после очередного Linux Plumbers где какие-то нормальные эмбедеры (pengutronix или free electrons, не помню) донесли типовые проблемы направления - не так уж далекие от серваков на автопилоте в общем то.