Odpovídáte na názor k článku Devuan 6.0 Excalibur je postavený na Debianu 13 a nepoužívá systemd. Názory mohou přidávat pouze registrovaní uživatelé. Nově přidané názory se na webu objeví až po schválení redakcí.
Já teda nejsem žádný velký systemd nadšenec, ale zrovna ty vyjmenované věci dělá celkem dobře a nejsou to zrovna nové nápady. Task scheduler (ať je to cokoliv) postavený na událostech je super nástroj. Hromada služeb může mít socket activation, takže se spustí až po příchodu packetu na jejich port. Potom služby, které jsou závislé na nějakém disku (třeba síťovém) se nemusejí spouštět, když ten disk není dostupný. (Ano, zrovna tady jsem se systemd zažil srandu, když mount unita nadšeně namountovala disk z pole, který jsem opravdu nechtěl namountovat jako RW, resp v této fázi vůbec.) Logovací démon sice nemusí být nutně součástí init služby, ale stav před tím vypadal tak, že se syslog měnil za rsyslog a rovnou se to posílalo někam do ElasticSearch, aby se to dalo používat. Místo toho stačí zavolat journalctl -f -u nginx -u php-fpm a vidím, jak na to obě služby zareagují a vidím to na dvou řádcích po sobě. A právě na tohle (sledování souvisejících služeb) se vždy používaly externí nástroje.
A jestli tím schedulerem byl myšlen třeba timer, tak to je opět velmi výhodné, protože na rozdíl od cronu, kde se 500 úloh zapnulo ve stejný čas (i když to nebylo nutné), tady stačí dát AccuracySec=1h a systemd to spustí podle aktuální zátěže a situace. Navíc ví, co bude spouštět, takže ví, jestli to vlastně může spustit (jestli to takhle reálně dělá nevím, napadlo mě to až při psaní tohoto textu).
Takže jsem po těch letech se systemd spokojen. Když měli všechno od počátku postavené na cgroups, tak se přímo nabízelo udělat kontejnery a od roku 2016 vlastně nic jiného než nspawn na linuxu nepoužívám. Dneska jdou služby kontejnerizovat do jisté míry i přímo v jejich service konfigu a nastavit omezení paměti, cpu apod. A vzhledem k tomu, že je to vlastně strom všech dalších procesů, tak se to nastavuje mnohem lépe, než dřívější ulimit.
Dále to ve své době mělo konečně rozumné nastavení sítě, kdy v jednom konfigu (resp ve více souborech, ale stále je to ini formát) nastavím bridge, vlan, přejmenuju iface apod. Ve starých network scripts to byl doslova porod a stačilo, aby někdo tam dával postaru iface aliasy a někdo ne a potom nástroje (dodnes velmi oblíbeného) jako ifconfig (nešlo by to konečně definitivně zahodit?) tak jeden admin tam viděl 60 IP adres (ip) a druhý třeba jen "svých" 5. V době, kdy si tam každý balíček může přihodit vlastní network konfig podle toho, jaký typ iface zrovna potřebuje tohle odpadá.
A věci jako NTP a DNS resolver se také přímo nabízejí, protože obé je podmínka nutná, nikoliv postačující pro provoz produkčního serveru. Takže nainstaluju minimal debian, je tam automaticky systemd a automaticky všechno, co kromě mého procesu potřebuju. Takže nemusím nastavovat další služby čistě jen pro základní provoz v roli serveru.
Tedy ne, že by to nešlo jinak, ale serverů, kde chyběl NTP jsem taky viděl hodně. Dneska stačí timedatectl set-ntp true a je to.
A ta modularita tam do jisté míry je. Nevím vlastně proč, ale zrovna debian oddělil nspawn a resolved do vlastních balíčků.