ich denke die ganz Diskussion um für und wieder von SystemD ist müssig. Ein Großteil der Linux Distributionen setzt es schon heute ein, weil man dort die Vorteile erkannt hat und über die Nachteile (die gibt es, keine Frage) hinwegsieht - die Vorteile überwiegen für die Entscheider. Da etwa auch Debian auf SystemD wechselt sind das also nicht nur kommerzielle Hintergründe die da zum tragen kommen!
In dem verlinkten CRE spricht Poettering u.a. über die längst überfällige Standardisierung die man mit POSIX einfach nicht weit genug tragen konnte. Das sind so Banale Dinge, wie das man sich nicht mal darauf einigen konnte, in welcher Datei der Hostname gespeichert wird. Da gibt es /etc/hostname (Debian), /etc/HOSTNAME (Suse), /etc/sysconfig/hostname (Red Hat) und sicher noch einige mehr. Keiner kann hier behaupten, dass es etwa bei diesem Beispiel um technische belange geht. Da wird einfach an dem festgehalten, was seit Jahrzehnten schon so ist.
Als Softwareentwickler, würde ich auch nur noch auf die SystemD APIs setzen, weil ich mich eben darauf verlassen kann, dass es auf jedem System so ist und ich eben nicht viele Unterscheidungen einbauen muss. Da braucht sich niemand wundern, dass SystemD vor allem bei Entwicklern auf so großen Zuspruch führt. Solche Abstraktionen sollten eben möglichst an einer Stelle gemacht werden und nicht von jedem Programm selbst. Das gilt übrigens auch für diverse Init-Skripte. Die meisten Programme müssen einfach nur, ggf. mit ein paar Optionen, gestartet werden. Irgendwer muss sich die Prozess ID merken und am Ende eben jene Beenden - im Idealfall mit allen Child Prozessen. Warum man dafür jedes mal ein ganzes Skript braucht, wenn die Angabe des Programms mit Optionen ausreichen würde, ist mir einfach schleierhaft. Für die vielleicht 5% aller Software für die das nicht ausreicht, kann man ja gerne Skripte schreiben, aber doch nicht für alles. Ich denke hier im Forum können alle mit Shell Skripten arbeiten und selbst welche erstellen. Das können viele, vor allem Neulinge aber nicht und warum sollte man für diese die Lernschwelle höher legen als nötig?
Letztlich ist es aber so, dass SystemD gesetzt ist. Klar wird es immer Distributionen ohne geben, aber die werden eben vieles Patchen müssen oder Shims implementieren. Wenn das unter BSD nicht geht, etwa weil Kernelfeatures nicht da sind, wird die schon jemand schreiben. Ob man cgroups haben will - da kenne ich mich nicht aus. Aber einen Mechanismus, mit dem ich alle Prozesse erkennen kann, die direkt oder indirekt von einem anderen gestartet wurden, der ist doch sinnvoll (sagen wir einfach mit einem "Tag"). SystemD nutzt cgroups um eben genau das zu erkennen, damit ein Dienst eben sauber mit allen Childs zu beenden.
SystemD selbst hat übrigens nur zwei Abhänigkeiten: einmal das Journald, das aber die Logs nachdem es sie verarbeitet hat auch an einen Syslog Dienst weitergeben kann, der dann Textfiles speichert. Als zweites dann DBus das wenn es nach Poettering geht in den Kernel wandern soll. Weil das alle modernen OS so machen, behaupte ich mal, dass IPC im Kernel durchaus Sinnvoll ist. Alle anderen SystemD Komponenten sind optional, abstrahieren aber auch hier vieles und werden daher gerne genutzt.
Inwiefern das nun die Freiheit von irgendwem einschränkt die Software seiner Wahl zu nutzen kann ich nicht nachvollziehen. Erstmal ändern sich nur die Init-Skripten die durch Unit-Dateien ersetzt werden. Ich denke aber dass gerade wer im IT-Umfeld tätig ist, in dem sich quasi täglich alles ändert, sollte so flexibel sein sollte damit umzugehen. Wenn ich für komplexe Angelegenheiten weiterhin Skripte brauche, lasse ich die einfach von SystemD starten. Wenn ich einen anderen NTP-Daemon starten möchte, kann ich auch das tun. Nur darf ich mich nicht wundern, wenn irgendwelche Software dann nicht rund läuft weil der andere Daemon kein - sagen wir - DBus spricht. Aber das ist doch jetzt auch schon so: ersetze ich ein Stück Software, durch welche die nicht default ist, kracht es eben irgendwo.
Kurzum: ich sehe das wie
@-Nuke-
Edit: ich kann den CRE nur empfehlen. Da wird so einiges an Entscheidungen mit Hintergründen gefüttert. Ob die immer sinnvoll sind, darüber kann man sicherlich streiten. Es ist aber nicht so, dass aus Prinzip alles anders gemacht wird....