Wander schrieb:
Was kritisierst du konkret?
Dass die Entwickler nicht nur ein init-System bauen. Sie haben was schoenes gebaut und jetzt fangen sie an alles drum herum zu ersetzen.
Und wie könnte man es deiner Meinung nach besser machen? Wie schon etliche Male gesagt, systemd ist kein monolithischer Blob sondern besteht aus unzähligen Binaries die alle bestimmte Aufgaben übernehmen und unter einem Namen gepflegt und entwickelt werden.
Wenn man Probleme mit vorhandenen Loesungen hat, forkt man halt, fixt und commitet zurueck. Wenn Systeme (wie z.B. auch x11) broken beyond repair sind, ersetzt man das wofuer sie zustaendig sind. Nicht die halbe Welt drumherum und erst recht nicht mit generischer Ignoranz gegenueber Philosophie.
Genauso könntest du FreeBSD dafür kritisieren eine einzige "Eierlegenden Wollmilchsau" zu sein, weil dieses Betriebssystem (Kernel, Init-System, Userland) unter einem Projekt mit einem Namen entwicklet wird.
Ich hab jahre lang FreeBSD daheim genutzt und ich widerspreche dir dort wehement, weil ausgerechnet die BSDs alles anderes als bloated sind und probieren alles im Kern zu loesen. FreeBSD ohne ports loest eben nur die eine Aufgabe: Ein System bis zum Userland vorbereiten. BSDs versuchen dir nicht vorzuschreiben, wie du services auszufuehren hast.
Geht das bitte etwas konkreter? Was ist an systemd unflexibel? Was meinst du mit der "Dependency-Hoelle" und wieso meinst du, dass der Zustand vor systemd ideal war?
Die Dependency-Hoelle ist genau das, was debian Entwickler schon laenger kritisieren. Wenn dir dein init-System anfaengt vorzuschreiben, wo services UND JETZT AUCH NOCH IHRE KONFIGURATION zu liegen haben, kannst dir ja vorstellen, wieviele Pakete dependency auf systemd haben werden. Willste systemd updaten, darfste deine services gleich mit updaten. Ich soll dann irgendwann z.B. memcached updaten, weil das init-system geaendert wurde? Wenn der service laeuft, interessiert mich das init-system einen feuchten Dreck. Garantieren, dass services laufen geht seit Ewigkeiten mit monit oder services wie supervisord. Jetzt stell dir mal vor, dass ich aufgrund von Geschaeftsprozessen memcached nicht neustarten darf. Safe-upgrades? Joah, aber wieso ueberhaupt den Aufwand machen, wenn am Anfang es schon gar nicht notwendig gewesen waere.
Zum Thema Zustand: sysvinit etc. waren alles andere als ideal. Aber sie waren auch nicht per Definition broken. Irgendwann muss, wie ich eingangs schrieb, auch mal was neues her, aber nicht so.
z.B.: warum war es bisher in Ordnung, dass Logging erst relativ spät im Boot-Prozess verfügbar war? Warum war es bisher in Ordnung, dass Dienste mit herkömmlichen Init-Systemen nicht zuverlässig beendet werden konnten?
Erste Frage: Weil es anders fuer die Masse ueberhaupt nicht noetig war.
Zweite Frage: Das versteh ich ehrlich gesagt nicht so ganz. Ist mir bisher nur bei services untergekommen, die in zu interpretierendem Quelltext vorlagen. Gib mal bitte ein reproduzierbares Beispiel aus debian.
Dein gewuenschtes Beispiel:
Code:
### BEGIN INIT INFO
# Provides: apache2
# Required-Start: $local_fs $remote_fs $network $syslog $named
# Required-Stop: $local_fs $remote_fs $network $syslog $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Interactive: true
# Short-Description: Start/stop apache2 web server
### END INIT INFO
Find ich ziemlich einleuchtend und startet in Abhaengigkeit, was da ist. Klar, ist nicht fuer jeden Fliegenschiss modular, muss aber nicht. Wie schon erwaehnt, monitoring von services ist auch nichts neues, was es vor systemd nicht gab.
Nur damit ich nicht den falschen Eindruck erwecke: Ja, Alternativen entwickeln ist gut, aber man sollte sich auf das Mindeste begrenzen, nicht alles machen, was moeglich ist.
Das ist in meinen Augen halt momentan ein Phaenomen, was die unix-Welt durchzieht. X11 ist broken, Wayland kommt zu recht, Canonical will ihr eigenes Bier mit Mir. Oder check_mk, was momentan in meinen Augen die beste monitoring solution ist, baut jetzt cmdb ein. Wozu? Wieso nicht einfach mal wieder: Ein Tool fuer eine Aufgabe.
