ich nenne zuerst einmal die vorteile aus meiner sicht, anhand eines vergleichs:
man mag ja über JavaScript denken was man mag, aber eine sache haben sie gut hingekriegt, und das ist das modul-system (import bzw. statisches/dynamisches verlinken).
das modulsystem ist so aufgebaut, dass der programmcode beginnt mit
Jedoch hat import den Vorteil, dass es eine “Deklaration” ist, kein “Funktionsaufruf”.
Das heißt, wenn das System startet, analysiert es zuerst alle Importe, und führt diese Parallel aus. Wenn stattdessen funktionsaufrufe genutzt würden, würden diese erst zur Laufzeit starten und seriell ausgeführt werden. Das wäre aber, vor allem bei vielen Abhängigkeiten, deutlich langsamer.
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?
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:
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?)
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?)
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.
Die “Dienste” bei systemd sind INI-Dateien. Damit haben wir in den 90ern unter Windows arbeiten müssen. Spaß hat das nicht gemacht.
Alternativen, die weit weniger wuchern, gibt es zuhauf, darunter OpenRC (Gentoo, aber portabel) und runit (Void, aber portabel).
:D
was ist dein problem mit systemd?
ich nenne zuerst einmal die vorteile aus meiner sicht, anhand eines vergleichs:
man mag ja über JavaScript denken was man mag, aber eine sache haben sie gut hingekriegt, und das ist das modul-system (
importbzw. statisches/dynamisches verlinken).das modulsystem ist so aufgebaut, dass der programmcode beginnt mit
import stuffA from './fileA.js'; import stuffB from './stuffB.js'; console.log("all dependencies loaded...");im gegensatz dazu steht das früher genutzte
require:const stuffA = requre('./fileA.js'); const stuffB = require('./stuffB.js'); console.log("all dependencies loaded...");Jedoch hat
importden Vorteil, dass es eine “Deklaration” ist, kein “Funktionsaufruf”.Das heißt, wenn das System startet, analysiert es zuerst alle Importe, und führt diese Parallel aus. Wenn stattdessen funktionsaufrufe genutzt würden, würden diese erst zur Laufzeit starten und seriell ausgeführt werden. Das wäre aber, vor allem bei vielen Abhängigkeiten, deutlich langsamer.
Jetzt ist es mit
systemdso, 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?Es löst das falsche Problem.
Etwas ausführlicher:
Zunächst einmal Grundsätzliches: System V ist
sh, nichtbash. (Nein, diebashist keine “besseresh”.) Aber das ist natürlich Erbsenzählerei. Zu dem Einwand sage ich Folgendes:systemdaber 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?)systemdmacht 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 istsystemdja 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 einfachgreppen könnte?)systemdgilt, aber in einem Prozess, der höchste Rechte im System haben muss, will man das am allerwenigsten.systemdsind INI-Dateien. Damit haben wir in den 90ern unter Windows arbeiten müssen. Spaß hat das nicht gemacht.