Lanzi: Da hab ich einen eisenharten Vorteil - für mich war das 2010 alles totales Neuland, ich musste nicht umlernen, da war nichts, was ich wusste
Und auch hier noch mal ganz zart der Hinweis: systemd ist ein Satz von schicken kleinen Dämonen, die sauber einzeln zu bedienen sind. Und jetzt kann man drüber streiten, ob man die in einem Quelltextrepo pflegt oder das splittet oder wie auch immer. Die gemeinsame Verwaltung und auch die gemeinsame Auslieferung find ich so verkehrt nicht, eventuell könnte man das ein wenig mehr aufsplitten - macht aber eigentlch™ auch keinen Sinn.
Und manchmal muss man dann auch Entscheidungen treffen - auch als User: Will ich das überhaupt? Und je nach dem, wie ich das beantworte, muss die nächste Frage lauten (ja): in welchem Maß will ich das (nein) was habe ich an Alternativen, schränkt das eventuell Funktionalitäten der Software ein, die ich nutzen will.
Netzwerk ist nen schönes Beispiel: Wie verwalte ich denn das jetzt? ifupdown oder systemd-networkd? oder besser gleich connman? wenn nicht connman, aber ifupdown - will ich den Networkmanager oder reicht mir ceni oder schreib ich die Konfiguration einfach mal aus der freien Hand, weil sich eh nichts ändert - oder will ich dhcp nutzen - wenn ja, in welchem Umfang?
Eigentlich ist das recht langweilig - entscheide ich mich für ifupdown, dann würde ich wahrscheinlich ceni zum konfigurieren nehmen - und wenn ich das auf einem Laptop machen, dann eben halt auch den wpa-kram über ceni erledigen. Ich bevorzuge auf dem Lappi einfach connman/cmst, eingeschworene Gnome/KDE-Fans werden eventuell ifupdown/network-manager nehmen - oder auf dem Lappi auch wicd - und das muss jeder selbst für sich entscheiden, wir können allenfalls auch eine Entscheidung treffen, was wir in die Flavors einbauen. Aber vom Prinzip und in der Praxis funktionieren alle Varianten gleich gut (mehr oder weniger), es kommt halt auch darauf an, was der Upstream dessen, was man gedenkt, einzusetzen aus welchen Gründen auch immer bevorzugt.
So viele Dinge ausserhalb vom Netzwerk sind auch nicht zu beachten - ok ntp vs system-timedated, rsyslog oder journald - wobei ein rsyslog über journald auch richtig fein sein soll, da man den frühen boot mitprotokollieren kann. und ob nun mysql oder irgendein serverdienst durch ein servicefile oder initscript gestartet wird, ist eigentlich auch schnuppe - wenn es denn ordentlich startet.
Verschlüsselung is doof, war es aber schon mit upstart - da kommt dann je nach Umfang plymouth zum Tragen. Hier haben initsysteme, die einfach nur serialisieren, einfach die Nase vorn: allet läuft nacheinander und wenn dat Ding ein Passwort zum entschlüsseln haben will, dann wartet dat Ding
. und beim der nächsten Anforderung wieder - und wieder, so notwendig. Hier brauchts bei den moderneren Systemen wie upstart und systemd halt plymouth - das übernimmt dann diese serialisierung, die beim Vorgänger naturgegeben war.
Der Rest ist eigentlich auch recht langweilig - bestimmte Umgebungen verlangen einfach bestimmte Schnittstellen und die müssen zur Verfügung gestellt werden. Und wenn eine bestimmte schnittstelle nur durch systemd zur Verfügung gestellt wird, ist man, solange diese Schnittstelle nicht durch was anderes zur Verfügung gestellt wird, ziemlich in den Arsch gekniffen. Hier kommen dann solche Konstrukte wie der systemd-shim zum Einsatz, bei dem systemd nicht als PID 1 läuft, sondern nur noch die Schnittstellen zur Verfügung stellt. Bis jetzt ist das nur in Gnome so - und bei wenigen anderen Programmen wie sddm und connman - aber die muss man ja nicht nutzen, wenn man nicht will.
