Etwas polemischer Titel, ich weiß, aber trifft den Kern: Die Unzufriedenheit über systemd, *kit und Konsorten wächst definitiv.
Ich halte systemd zwar für einen Fortschritt gegenüber sysvinit, was das Initsystem angeht, gleichzeitig macht systemd aber meiner Meinung mit seinen zehn anderen Komponenten jeweils mindestens einen Schritt zurück. Consolekit ist eine Pest, PolKit genauso nett gemeint wie schlecht umgesetzt, PackageKit eine Totgeburt, PulseAudio und Avahi haben sich nur durch Sicherheitslücken und Bugs bekannt gemacht. Udev und DBus sind prinzipiell nette Ideen, aber intransparente Mistdinger und im Fall von Udev auch extrem lästig zu konfigurieren (dank subtiler Änderungen in der Konfigurationssyntax und mangelhafter Doku).
Was dagegen tun?
ConsoleKit
Ich weiß immer noch nicht, wofür das Ding jemals gut war. Berechtigungen in /dev setzen und alle Accounts in die passenden Gruppen eintragen hat für mich immer gereicht. Da müsste höchstens mal jemand hingehen, den zugehörigen Wiki-Artikel polieren und prominent genug verlinken.
PackageKit
Hat bei Arch glücklicherweise nie Verbreitung gefunden und kann in Frieden ruhen. Umsteiger können sich am
Rosetta-Stein orientieren.
PolKit
Wäre meiner Meinung prinzipiell eine gute Idee, wenn es intelligentere Defaultwerte hätte und einfacher zu konfigurieren wäre. Für den durchschnittlichen Ein-Benutzer-Rechner (bzw. komplett administrierter Rechner), die den Großteil der Arch-User abdecken, würde auch sudo reichen, wenn Desktopumgebungen nicht mehr und mehr PolKit verpflichtend voraussetzen würden. Derzeit bleiben damit nur zwei Alternativen: Irgendwie hinfrickeln und damit leben, oder auf Desktopumgebungen verzichten. Beides ist keine wirkliche Lösung.
Theoretisch müsste man das PolKit-Interface nachprogrammieren und an ein sauberes, unixoideres Backend binden (Gruppen/sudo/…). Wäre nur extrem viel Aufwand. 😐
PulseAudio
Hat für netzwerktransparentes Audio eine Daseinsberechtigung, ich wüsste sonst nichts, wo es wirklich zwingend ist. Lautstärkeregler für einzelne Applikationen habe ich zumindest nie vermisst, und Mixing bieten sowohl ALSA als auch OSS (bei dem man den deutschen Wiki-Artikel überarbeiten oder kübeln müsste, im jetzigen Zustand ist er nur abschreckend).
Avahi
Hat den Mist irgendjemand mal gebraucht? Irgendjemand? 🙂 Am liebsten würd ich das Ding gegen ein leeres Stub-Paket ersetzen.
DBus
Wohl das "erfolgreichste" FDO-Projekt. Ich habe ein halbes Dutzend DBus-Anwendungen geschrieben, ohne den blassesten Schimmer zu haben, wie das Ding funktioniert oder wie ich es debuggen könnte. Durch die Verbreitung ist es unmöglich, das Ding loszuwerden; durch die Komplexität ist es kaum durch etwas anderes zu ersetzen. Wird uns wohl länger erhalten bleiben.
udev
Müsste, nachdem es mit systemd gemergt wurde, prinzipiell auch ersetzt werden. Wie viel ist davon überhaupt nötig? Ich muss ehrlich sagen, dass ich keine Ahnung habe, was das Ding alles genau macht (wie üblich bei FDO). Die Symlinks für Blockgeräte etc. sind auf jeden Fall ein sehr hilfreiches Feature, auf das ich nicht verzichten wollen würde. Wie sonst könnte man die Funktionalität erreichen, wenn man rein hypothetisch auf udev verzichten will?
systemd
Auf Grund des Funktionsumfangs aufgesplittet (danke, Lennart…):
logind
Da das eine Mischung aus ConsoleKit und acpid ist, kann es durch/genauso wie selbige ersetzt werden.
localed
Glorifiziertes DBus-Interface für locale.conf und so nötig wie ein Montag-Morgen-Meeting.
timedated
DBus-Interface für Zeiteinstellungen. (open)ntpd + Initsystem.
hostnamed
Initsystem.
journald
syslog-ng, rsyslog, ...
Socket-Aktivierung
xinetd
"Socket"-Aktivierung für Blockgeräte (x-systemd.automount)
Soweit ich weiß ist das eines der wenigen wirklich
neuen Features von systemd. Und ein recht praktisches, das ist der einzige Mount-Daemon, mit dem ich es geschafft habe, sshfs-Laufwerke automatisch mounten zu können. Gibt es da etwas vergleichbares?
Systemd-Readahead
Richtiges Readahead.
Initsystem
sysvinit ist ganz nett, hat aber auch einige Nachteile – manuelle Konfiguration von LVM/RAID, und der serialisierte Start von Daemons (die alle von Hand in der richtigen Reihenfolge aufgelistet werden müssen – meh). Archs Hintergrundstart ist nicht wirklich vergleichbar mit systemds abhängigkeitsbasiertem Boot, und Debians "dependency-based boot" ist so unglaublich schlecht implementiert, dass es
langsamer ist als Archs serialisierter Boot (ohne Hintergrundstarts).
Mir am liebsten wäre ein Initsystem, das systemds Konfigurationsdateien für Daemons verwendet; Initscripts verleiten Maintainer meiner (Sysadmin-)Erfahrung nach einfach zu sehr dazu, sch***e zu bauen und Programmlogik in distributionsspezifische Initscripte auszulagern. Angesichts dessen, dass sich nicht einmal Maintainer für sysvinit finden lassen, wohl leider illusorisch. Was wäre nötig, um zumindest sysvinit am Leben zu erhalten?