JuergenPB hat geschrieben:Wenn systemd noch nicht alle Dinge ersetzt, die es mal ersetzen soll, kann man natürlich sagen, daß es noch nicht „fertig“ ist. So gesehen, ist auch jedes andere Programm, daß für das nächste Release Neuerungen ankündigt, noch nicht „fertig“.
Nein. Es ist ein massiver umterschied ob irgend was morgen noch naträglich neue Funktionen geschenkt bekommt, oder ob sachen, die heute funktionieren morgen nicht mehr (bzw. anders) funktionieren. Das ist das problem mit Systemd. Das bezieht sich im übrigen nicht nur auf Systemd sondern auch auf die sachen, die es ersetzt. Wenn systemd sagt, ich kann jetzt die crypttab interpretieren und versteht aber viele optionen, die darin vorkommen nicht. Dann ist es nicht fertig. Wenn es das alles kann und in zukunft noch ein paar weitere Optionen verstehen wird sehrwohl.
Deswegen machen vernünftige entwickler das typischerweise nicht so, dass man Programme ersetzt. Man schreibt einfach ein neues, dass besser ist. (Firefox oder chrome ersetzen den Netzcape oder IE ja auch nicht sondern sind halt einfach neuere bessere Programme. Ein bekanntes systemnahes Beispil ist iproute und ifconfig. Es kann mehr als eine Wahrheit geben. Es gibt jetzt iproute, das viele neue Funktionen bietet. Aber ich kann, wenn ich unbedingt will weiter ifconfig nehmen.) Das ersetzen wäre im übrigen IMHO gar nicht nötig gewesen. Mann hätte sogar sysvinit und systemd parallel nutzen können. Systemd stötst systemd-Services an Sysvinit Sysvinit-Services. Das geht sogar ansatzweise (zwar will systemd unbedingt PID 1, aber der eigentliche Teil von Sysvinit sind die rc-Scripte und die kann systemd auch interpretieren. (zumindest im Moment.)) und deswegen beschwert sich auch keine über die init-komponente von systemd. Aber bei vielem anderen Funktioniert das eben nicht. cryptsetup ist da das krasseste Beispiel. Es wäre kein problem gewesen systemd-cryptsetup so zu schreiben, dass es parallel zu cryptsetup laufen könnte. cryptsetup bekommt seine ctypttab und systemd crypttabd und cryptsetup kann devices erstellen, wie es will. Dann könnte jeder der will zur inittabd wechseln, wenn er das für angebracht hällt oder beim alten bleiben. Aber das wollte man nicht so. Man interpretiert die crypttab selbst und das acuhnoch anders. Außerdem kommt man cryptsetup auch noch an anderen Stellen in die quere: Kurz nachdem udev zu systemd gehört stellt es die benötigten Schnittstellen für cryptsetup nicht mehr zur Verfügung. (Stichwort unnötige redundanz.)
Und ich kann das nicht beweisen aber ich denke dass da schon stark Firmenstrategie von RedHat dahintersteht. Man etabliert zuerst systemd und ersetzt nach und nach immer mehr Teile durch systemd. Dadurch wird immer mehr von Systemd abhängig und jedes Teil das abhängig von systemd ist, kann dann auch wider alternativlos durch systemd ersetzt werden, indem man dem orginalen nicht systemd bestandteil die Abhängigkeiten unter den Füßen wegzieht und dann die einzig funktionierende alternative von RadHat. Nach und nach bekommt man so ein RedHat-only system. Mit der Strategie war schon Microsoft und jetzt zum teil auch Apple sehr erfolgreich.
JuergenPB hat geschrieben:Wieviel bleibt übrig, wenn man nur noch die fertige Programme zählt – also jene an denen außer Fehlerbeseitigungen nicht neues mehr geplant ist?
Nach der Definition fällt mir nur Thunderbird und vielleicht dd ein. Aber nach der Oben genannten Trifft das auf sehr viele sachen zu.
Ein beispiel: Hier ist eine
Liste von JVMs. Die werden großteils weiterentwickelt aber eben alle unterstützen (weitestgehend) das, was die erste JVM von 1994 konnte. Und so seht das mit fast allen Basisteilen in debian aus. gzip, tar, bash, cat, cp, ssh, mkfifo, ext, vim, ping, ifconfig ...
Bekamen alle vielleicht hin und wieder mal updates, die sie schneller machten, oder mehr Funktionalität boten. Aber alte funktionen funktionierten immer schön weiterhin.
Selbst bei sachen, wo das nicht so gemacht wird gibt's typischerrweise maximal alle paar Jahre eine major Version, die die alten APIs bricht. In 16 Jahren gab es 5 QT-Versionen. Für GTK in der Gleichen Zeit sogar nur 3. Trotzdem wurde dafür gesorgt, dass ich notfalls 2 verschiedene Versionen nebeneinander installieren kann. Alle 3-5 Jahre meine Zugriffe anpassen ist möglich.
Aber bei systemd haben wir in ca. 4 Jahren deutlich über 100 major versionen. Dh. Ich muss mich mehr als wöchentlich über änderungen in Systemd informieren und meine Software darauf anpassen. Das kann nur systemd selbst. (Das ist auch der Grund, warum Forks nur schwer zu machen sind.)
JuergenPB hat geschrieben:Wenn man einen bestimmten Service von systemd nicht haben will, warum aktiviert man ihn dann? Einen Service zu aktivieren und dann zu sagen: „systemd übernimmt Aufgaben, die es nicht machen soll“, halte ich nicht für besonders klug. In solchen Fällen sitzt der „Fehler“ dann wohl eher vor dem Rechner.
Es wurde entschiden dass sich systemd in jessie nicht mehr (oder nur noch mit extremen einschränkungen) deaktivieren lassen soll. Deswegen haben so viele leute Probleme mit systemd. (Aber kaum jemand mit der Kopete.)
Defakto wird kein systemd in absehbarer Zeit heißen: Kein Debian kein Mint kein Ubuntu kein openSUSE kein Mageia kein Fedora kein CentOS kein Arch kein Gnome kein...
Das ist das Problem. Nich dessen existenz an sich.
Bei habakugs Anleitung ist aber libsystemd0 wahrscheinlich noch installiert.
