( fdavid | 2019. 12. 10., k – 15:55 )

Szerintem a kérdésfelvetés eleve hibás. A systemd távolról sem egy init rendszer, hanem egy operációs rendszer funkciókat (meg mindent is) felvonultató user space réteg. Tekintve, hogy egy mai desktop környezet nagyon sok operációs rendszer (vagy operációs rendszer közeli) funkciót igényel, amit a Linux kernel nem szállít, és így a disztribúciók tele voltak mindenféle megoldásokkal, amik nem nyújtottak a szoftverfejlesztők számára egységes API-t illetve nem voltak egymással jól összehangolva, csak idő kérdése volt, hogy előálljon egy ilyen monolit. Szerintem amióta a mainstream disztribúciók alapértelmezetté tették a systemd-t, már nincs visszaút. Az, hogy a systemd implementációval és a systemd fejlesztők hozzáállásával komoly gondok vannak, arról számos írás született már, pl: https://fromthecodefront.blogspot.com/2017/10/systemd-no.html

Szóval a kérdésfelvetés inkább olyasmi kellene legyen, hogy mi lenne az a UNIX-szerű architekturális megoldás, ami kiváltja a jelenlegi systemd implementációkat, de megoldást nyújt azokra a problémákra, amiket a systemd jól vagy rosszul, de végülis megoldott.

Szóval egy init rendszer nem fogja a systemd-t leváltani, és nem fogja a szerepét betölteni. Egy systemd jellegű megoldásra szükség van, ez egyértelmű abból, hogy a mainstream disztribúciók a sok vita ellenére alapértelmezetté tették. Itt szerintem a legfontosabb kérdés még nem is az, hogy van-e egy jobb, nyitottabb, dokumentáltabb implementáció, hanem hogy a jelenlegi systemd interface-t hogyan lehetne szabványosítani vagy egy annál jobb szabvánnyal helyettesíteni. Akkor már jöhetnek az egymással versengő jobb implementációk.

Ha a Debian erőforrásokat összpontosít a systemd-re az annak csak jót fog tenni. De valójában a kérdés inkább az, hogy hogyan lehetne a systemd fejlesztését abba az irányba terelni, ami kiküszöböli a jelenlegi problémákat.