Arch Linux

Warum wollte niemand Upstart und OpenRC?

Ovion

Einen guten Abend,
eine Frage, die mir gerade gekommen ist:

Es überschlagen sich alle, wieviel besser systemd im Vergleich zu SysVinit ist (ok, 'n bisschen übertrieben, aber ihr wisst, was gemeint ist 😉), innerhalb ~ eines Jahres hat systemd SysVinit in Fedora/RHEL, SuSE, Arch und wonochnichtalles ersetzt, so schnell wie das gegangen ist, könnte man meinen, dass SysVinit ja echt mies gewesen sein muss.

Aber es gab doch bereits vorher neue Initsysteme, allen voran Gentoos OpenRC und Canonicals Upstart. Nachdem systemd jetzt so schnell adaptiert wurde, SysVinit also offenbar nicht vermisst wird (und systemd sicher auch aus den Fehlern beider gelernt hat), warum hat niemand vor systemd-Entwicklungsbeginn SysVinit durch OpenRC oder Upstart zu ersetzen versucht?

Bei Upstart könnte ich mir vorstellen, dass es vielleicht Canonicals altbekannte Ader ist, die externe Entwickler vergrault, liege ich damit richtig? Außerdem trifft das so ja afaik nicht auf Gentoos OpenRC zu.

Was reizte an systemd, was an OpenRC und Upstart nicht reizte? Dass systemd besser als beide ist, kann es ja nicht sein, weil ich mich ja auf die Zeit beziehe, bevor jemand dessen Existenz erdacht hat. Oder hat systemd schlicht das richtige Timing erwischt? Falls ja, inwiefern?

Creshal

Upstart… Canonical, 'nuff said.

OpenRC: Für Nicht-Server-Distributionen war sysvinit gut genug, da hatte OpenRC keine echten Vorteile. Serverseitig scheint es weder Debian gefallen zu haben (die Sysvinit bis zum Erbrechen patchen, mit geringem Erfolg), noch RedHat.

Und Redhat hatte einfach die Ressourcen, systemd in zwei Jahren bis zur "Marktreife" (i.e., stabil genug für den Servereinsatz) zu prügeln, während OpenRCs Entwicklung wohl eher dahinkriecht.

Ovion

Ok, da lag ich bei Upstart ja gar nicht so schlecht mit meinem Tipp.^^

Was hat OpenRC denn speziell für Server in petto, was man auf dem Desktop nicht braucht? (Hab so gar keine Ahnung von OpenRC, außer, dass es Daemonabhängigkeitsauflösung kann.)

Creshal

Ressourcenlimits (cgroups etc.), besseres Debugging, der ganze Schmarrn, der zwar nützlich ist, aber nicht *so* nützlich, dass Desktop-Distributionen sofort wechseln würden.

Auf Servern war sysvinit hingegen schon lange eine Krücke, da bestand echter Bedarf. Da war OpenRC aber anscheinend nicht gut genug für…

Dirk

Ovion schriebWas reizte an systemd, was an OpenRC und Upstart nicht reizte? Dass systemd besser als beide ist, kann es ja nicht sein, […]

Doch, genau das ist es. So ’ne richtig objektive Gegenüberstellung habe ich zwar nicht gefunden, weil jeder Bäcker seine Brötchen für die besten hält (und seitens Gentoo im Bezug auf systemd in deren WIki sogar dreist gelogen wird, um systemd schlechter dastehen zu lassen), aber soweit ich das sehe haben wir folgendes:

SysVinit: Altbewährt, aber einfach nicht mehr zeitgemäß
Upstart: Ubuntu-Spezifisch und nur auf dem Papier offen
OpenRC: SysVinit mit Gentoo-spezifischen Erweiterungen
systemd: Moderne, distributionsunabhängige Neuentwicklung

Lycanthropist

Dirk schrieb(und seitens Gentoo im Bezug auf systemd in deren WIki sogar dreist gelogen wird, um systemd schlechter dastehen zu lassen)

Intressant. Wo z.B.?

Dirk

Lycanthropist schrieb
Dirk schrieb(und seitens Gentoo im Bezug auf systemd in deren WIki sogar dreist gelogen wird, um systemd schlechter dastehen zu lassen)
Intressant. Wo z.B.?

Hard-to-debug monolitic startup in undocumented C
[no] separation of code and configuration
[no] easily extensible startup scripts
[no] verbose debug mode

Das Känguru

Dirk schrieb[…]
Hard-to-debug monolitic startup in undocumented C
[no] separation of code and configuration
[no] easily extensible startup scripts
[no] verbose debug mode

Hossa! Das ist arg dreist. Wenigstens die letzten beiden Punkte sind nicht der Fall. Ich schreib mir gerne mal einen eigenen Service und das geht mir leicht von der Hand. Bei sysv war das duetlich komplizierter.

Dirk

Na ja, und die ersten beiden stimmen meinem Verständnis nach auch nicht (der erste definitiv nicht, wenn ich mir den Quellcode angucke, der ausreichend dokumentiert zu sein scheint).

Das Känguru

Ich nutze Englisch nur als zweite Sprache, vielleicht ist meine Übersetzung von in undocumented C auch falsch und es bedeutet das die genutzte C-Version undokumentiert ist. ^^

Creshal

Ich traue Lennart ja viele Verbrechen zu, aber das wäre selbst für ihn sportlich. 😃

iconfly

Wobei am letzten Punkt was dran ist. journalctl gibt mir in wenigen Fällen nur das passende aus. Oft sehe ich nur error code's. Aber was genau nicht geht, erfahre ich kaum. Das muss man dann selber raus finden.
Ein Beispiel war, das bei mir Virtualbox und nvidia Module nicht geladen werden konnten, was jedoch nicht mit journalctl herauszufinden war 🙁 .

Smon

Willst du für jedes Modul, dass nicht geladen wird, einen Log-Eintrag?

Edit: Wie wäre es bei Modulen eigentlich mit dmesg?

Dirk

iconfly schriebWobei am letzten Punkt was dran ist.

Selbst, wenn man sich alle Punkte so drehen kann, das sie „irgendwie ja doch zustimmen“, der Punkt, dass Code und Konfiguration nicht getrennt werden würden, ist schlicht falsch – Code und Konfiguration wurden bei SysVinit nicht getrennt, ja, aber systemd hat eine vorbildliche Trennung, sogar so sehr, dass man nicht mal Code in den Konfigurationsdateien HABEN kann!

Ovion

Dirk schrieb
Ovion schriebWas reizte an systemd, was an OpenRC und Upstart nicht reizte? Dass systemd besser als beide ist, kann es ja nicht sein, […]
Doch, genau das ist es.

Das habe ich auch nie abstritten, es war aber für den Kontext meiner Frage irrelevant aus Gründen, die bei dir im […] stecken geblieben sind. 😉

iconfly

Dirk schrieb
iconfly schriebWobei am letzten Punkt was dran ist.
Selbst, wenn man sich alle Punkte so drehen kann, das sie „irgendwie ja doch zustimmen“, der Punkt, dass Code und Konfiguration nicht getrennt werden würden, ist schlicht falsch – Code und Konfiguration wurden bei SysVinit nicht getrennt, ja, aber systemd hat eine vorbildliche Trennung, sogar so sehr, dass man nicht mal Code in den Konfigurationsdateien HABEN kann!

Habe ich auch nie bestritten.

Smon schrieb Willst du für jedes Modul, dass nicht geladen wird, einen Log-Eintrag?
Edit: Wie wäre es bei Modulen eigentlich mit dmesg?

Wenn ein Service nicht startet, will ich schon den genauen Grund und nicht ewig die dmesg durchforsten.
Aber trotzdem Danke für den Tipp, werde ich nächstes mal machen.

Datenschutz
Impressum