Mir macht, ehrlich gesagt, systemd nichts aus, WENN(!) ich mich damit nicht beschäftigen muss. Das bedeutet für mich, dass systemd für reine Desktop-Rechner "ok" wäre, weil ich da den Standard-Matsch, den die Distro anbietet einfach übernehme. Das passt sogar zu Debian, weil das Linux genauso verwirrt ist, dass ich das meistens nicht wage, es tiefergehend zu konfigurieren.
ABER(!), ich habe ein Desktop-System, das ein Server ist und ich MUSS(!) mich mit Sachen herumschlagen, die bis zum Bootvorgang reichen und allgemein das System beeinflussen. Ich brauche Admin-Tools, die ich mag, die eigenständig sind und immer dann laufen, wenn der betreffende Teil des Systems funktionstüchtig ist. Ich verstehe dann besser was läuft und was nicht. Ich hatte noch nicht alle fatalen Probleme der Welt mit FreeBSD (natürlich!), aber die meisten Probleme sind immer akut schmerzhaft und müssen gelöst werden, ohne das man nervös wird.
init ist klein und hat seine dedizierte Aufgabe, die Wahrscheinlichkeit ist klein, dass es ein Problem hat, sodass ich daran irgendetwas drehen muss. systemd ist ein Ungetüm, es ist für alles zuständig. Ich muss mich damit beschäftigen, ich kann nicht wie bei rc.d einmal drumherum skripten, weil es, anstatt anständiger Turing-vollständiger Sprache, Beschreibungen in Textdateien verwendet. Hat systemd an einer Stelle irgendwo ein Problem, wirkt sich das global aus und jetzt sieht es so aus, als ob das System nicht anständig bootet (anständig = sodass man den Fehler einfach beheben kann), wenn ein Teil von systemd ausfällt.
Zweitens... ich brauche Logs. Viele davon. Ich lese sie nicht oft, aber WENN ich sie brauche, dann werden sie LEBENSWICHTIG. Sie sollen einfach zugreifbar sein und mir ist egal, ob sie konsistent sind, oder nicht (wen interessiert das, wenn eine Zeile mittendrin aufhört?). Es ist VERDAMMTNOCHMAL ein Log! Ein Log hat keinen Anspruch auf Konsistenz... es soll das MAXIMALE bieten was der Admin gebauchen kann und wenn ein Dienst noch einen letzten Hilfeschrei reinsetzt, der mittendrin aufhört, ist das besser als transaktionale Logs zu haben, die dann "repariert werden"... und Information vernichten. Ich brauche Logs auch, wenn wenig Tools zur Verfügung stehen und sie sollen textbasiert sein, sonst werde ich wahnsinnig damit.
systemd führt zudem falsche, von mir nicht erwünschte Prinzipien ein. "rootfs ist nicht genug" (das schmerzt sehr!). Es ist natürlich rund um die Uhr "Daemonen neu zu starten"... ihr habt wahrscheinlich noch nie den Printer-Dienst mitten im Auftrag abstürzen sehen (startet er dann neu und ich mach Pause und es nicht weiß habe ich tausende mit Müll bedruckte Blätter, wegen "Retries"). Ich finde das einfach hirnrissig, was manche Leute sich hier denken. Ein Dienst soll abstürzen und das System soll mir sagen, dass er nicht mehr läuft und Logs sollen mir Infos bieten, wo das eigentliche Problem ist. Einfache kette, die jeder Admin versteht!
Ich habe regelrechte Angst Linux überhaupt anzuschauen, weil jede Distro den systemd-Käse am Laufen hat. Naja gut, dann kann ich mir Linux erstmal für lange Zeit sparen, bis die Leute all die Schmerzen bekommen haben, um systemd sinnvoll zu gestalten. Das wird voraussichtlich etwas dauern. Aber ich verfolge stets passiv mit, wie verloren viele Leute sind, auch die die von systemd "überzeugt" sind.
Ich habe auch übrigens keinen Bock auf Glaubenskrieg (siehe "überzeugt"). Ich betrachte gerne die Essenz aus der Sache und gucke, ob ich mehr Probleme habe als zuvor. Hier habe ich die. Ich hatte die schon, wenn ich Linux als Server einsetze, weil sie alles so unkomfortabel dort machen (Gentoo ist eine angenehme Ausnahme, übrigens, aber Anwendungen ans Laufen zu kriegen ist dort zeitweise ein Krampf!). Ich bin froh, dass ich zur rechten Zeit auf FreeBSD als Hauptsystem gekommen bin und betrachte mir den Unsinn der da mit systemd passiert aus sicherer Distanz an. Manchmal lache ich darüber und bin dann froh, dass ich mich damit nicht beschäftigen muss (viele Leute in sozialen Medien schreiben darüber, stellt Euch vor wir würden dauernd schreiben wie toll/schlecht init oder rcng ist... das machen wir nicht, weil das einfach LÄUFT!).