Názor k článku
Utilita run0 je bezpečnější náhradou za sudo založenou na systemd od Filip Jirsák - Netuším, o jakých pravidlech a jejich podpisu je...

Netuším, o jakých pravidlech a jejich podpisu je řeč. Já jsem nikde nepodepisoval, že se má Apache odforkovat z dosahu SysVinitu ani že má mít vlastní utilitu na správu procesů. To prostě vyplynulo z toho, že SysVinit neposkytoval služby, které potřeboval Apache a jeho správci.

Tím jsem chtěl říct, že pokud někdo používá systemd restart proto, že mu dochází zdroje, tak se má postarat o ty zdroje.
Ale ony mu nemusí docházet systematicky. Může se stát, že se jedna aplikace zblázní a vyžere všechnu dostupnou paměť nebo zaplní disk. Nemělo by se to stát, ale je lepší počítat s tím, že se něco takového stát může. Stejně jako by se nemělo stát, že vypadne napájení – přesto dáváme do datových center UPS a agregáty, protože je lepší počítat s tím, že se něco takového může stát.

Pořád je to o tom, zda se snažíme postavit systém, který nemůže selhat (a nakonec stejně selže), nebo jestli stavíme systém, u kterého se se selháním komponent počítá a systém se z toho umí zotavit, pokud možno automaticky.

Chtěl opravdu někdo správce procesů?
Ano, chtěl. Kdyby to nikdo nechtěl, nejsou ve všech distribucích pomocí shell skriptů nad SysVinitem dobastlení správci procesů. Přičemž to „dobastlení“ nemyslí nijak zle vůči autorům – v době, kdy to vznikalo, to jinak nešlo.

Který se ale současně brání tomu to spojit třeba s monitoringem toho, co ten proces má dělat.
Jak se tomu brání? systemd je správce procesů, není jeho starostí řešit, zda ten proces dělá, co má. To je starost jiných nástrojů, monitoringu – a ty mají možnost, když zjistí, že je s procesem něco špatně, chtít nějakou akci po správci procesů –třeba ukončení procesu nebo jeho restart.

Takže jsme se ve výsledku jen zbavili dvojitého forku, který někdy někomu možná z nějakých neznámých důvodů vadil.
Ten důvod není neznámý a řešili to snad všichni správci procesů, kteří přišli po SysVinitu. Základní věc, co musí správce procesů vědět, je zda jím spravovaný proces běží nebo neběží. K čemuž je potřeba, aby ten proces byl potomkem správce procesů. Zapsat PID procesu do nějakého souboru a občas otestovat, zda proces s takovým PID pořád máme v systému, a doufat, že je to pořád ten samý proces a ne nějaký jiný, který náhodou dostal stejné číslo, fakt není systémové řešení.

Hezky si upravuješ realitu.
Neupravuju. Stavěla se datacentra s třemi nezávislými přívody elektřiny a internetové konektivity, uvnitř minimálně dva nezávislé napájecí okruhy, to samé v serveru, značkový server se záručním listem podepsaným samotným ředitelem HP, na serveru certifikovaný aplikační server… Všechno navržené pro provoz 24×7 se spoustou devítek, protože spolehlivost celého řešení znamenala ty devítky mezi sebou pronásobit.

A pak přišel Google, který řekl, že kašle na superdrahé servery, protože spolehlivějšího výsledku dosáhne, když místo jednoho drahého serveru pořídí deset levných počítačů a bude počítat s tím, že mu každý týden jeden lehne. Tak nebude řešit nějakou záruční opravu, ale prostě tam dá jiný levný počítač.

appka se napsala nudně dle 50 let starých standardů a ono by to bohatě stačilo
Akorát že by ta appka taky stála podle 50 let starých cen. Jinými slovy – nikdo by ji nezaplatil. To se řeší možná u řízení vlaku nebo letadla, nebo ještě o několik úrovní dál u řízení jaderné elektrárny. Chtěl jsem napsat ještě u vesmírných raket, ale tam už Musk také ukázal, že se to nevyplatí.

Chápu, že je to paradoxní, že vývoj neznamená vždy to, že by něco nového bylo kvalitativně lepší. Často to znamená, že je to kvalitativně jen 90 % předchozího, ale za 10 % ceny. Takže to najednou má daleko víc možností užití a odvede to daleko větší službu.