ich_iel

was ist dein problem mit systemd?

Es löst das falsche Problem.

Etwas ausführlicher:

Jetzt ist es mit systemd so, dass Services parallel gestartet werden können, weil es sich um Deklarationen (in jeweils eigenen .service files handelt). Bei SysVinit handelt es sich meines wissens nach um bash-skripte, die seriell laufen, und damit um einiges langsamer sind. was sagst du zu diesem einwand?

Zunächst einmal Grundsätzliches: System V ist sh, nicht bash. (Nein, die bash ist keine "bessere sh".) Aber das ist natürlich Erbsenzählerei. Zu dem Einwand sage ich Folgendes:

1. Ja, System V lädt Scripts seriell. Nun wurde systemd aber insbesondere als vorteilhaft für Server bezeichnet. Wie oft startest du deine Server neu, dass das überhaupt ins Gewicht fällt? (Startest du deine Desktops neu oder reicht dir da der Ruhezustand?)
2. systemd macht ja wesentlich mehr als nur Servicestart, sonst wäre es vielleicht eine brauchbare Alternative zu anderen Initsystemen. Leider frisst es sich durch das gesamte System und absorbiert zusehends mehr Dienste. Man kann wohl einen Teil davon immer noch optional laden, aber unter Linux (portabel ist systemd ja zum Glück nicht...) verlassen sich immer mehr Anwendungen darauf, dass das ganze Paket da ist. (Einen Teil dieser Optionen will man nicht haben. Warum muss man hartkodierte Google-IPs nutzen? Warum gibt es keine Option für textbasierte Logdateien, die man einfach greppen könnte?)
3. Je komplexer die Software, desto mehr Sicherheitslücken weist sie auf. Das ist eine allgemeine Beobachtung, die nicht nur für systemd gilt, aber in einem Prozess, der höchste Rechte im System haben muss, will man das am allerwenigsten.
4. Die "Dienste" bei systemd sind INI-Dateien. Damit haben wir in den 90ern unter Windows arbeiten müssen. Spaß hat das nicht gemacht.
5. Alternativen, die weit weniger wuchern, gibt es zuhauf, darunter OpenRC (Gentoo, aber portabel) und runit (Void, aber portabel).