Revod hat geschrieben: 19.08.2019 09:41:56
Und seid neuesten sehe es die Leute von Knoppix auch so
Klaus war schon immer ein Gegner von Systemd. Das ist nichts neues.
Das Grundproblem an SystemD ist folgendes:
Systemd will wohl das die Programme selber etwas dynamischer sind.
lassen mich immer zuerst vermuten, dass es lediglich der Unit-Programmierer nicht hinkriegt
Yes, it is written systemd, not system D or System D, or even SystemD.
In Wahrheit ist das mit den Parallelstarts unter systemd also ein Paradigmenwechsel, den sich meiner Meinung einige weigern zu aktzeptieren oder sich anzupassen. Das ist m.M.n. keine gute Basis für eine Diskussion.
Die Indeologie hinter systemd ist: Ein Mensch will Entscheiden wie alle anderen Programme zu funktionieren haben. Und das ist das was knallt.
Gerade der letzte Fall ist exemplarisch: Es gibt da massenhaft Programmierer die schreiben seit Jahrzehnten gut funktionierende Programme. Und gut funktionierend heißt, die funktionieren unter *BSD, Diversen Linux-Distributionen (Und zwar mit klassischem SysV, paralleles LSB-SystV, Upstart, OpenRC und mit minimalem Aufwand meist auch unter Windows. Denn überall gilt: Der Entwickler kümmert sich darum dass sein dienst in linearer Reihenfolge starten kann und das init-System parallelisiert dann von sich aus ohne Anpassungen im Programm.
Und dann kommt Herr Pöttering und schreibt SystemD und das Zeug funktioniert halt nicht mehr.
Und zwar damit:
es ein paar zehntel Sekunden Startzeit kostet.
Denn alle modernen SystemVs starten mittlerweile schneller als Systemd.
Plötzlich habe ich als Programmierer nicht ein bisschen sondern gerade im Netzwerk- und Gerätemanagementbereich den Zigfachen Aufwand. Und Herr Pöttering meint, dass das ja ein Problem der Entwickler sei die sich nicht an das neue Paradigma anpassen können.
Selbst von sich selbst will er sich nichts sagen lassen: Pöttering weigert sich konsequent nach dem Prinzip was interessiert mich mein Geschwätz von gestern seit der Entwicklung von Systemd stabile APIs raus zu geben – schränkt ihn in seinem Fortschritt ein. Wenn er mal wieder was anders machen will will er das ungehindert machen können. Das ist mittlerweile über 200 mal passiert. Und 1500-Deamon Entwickler sollen hinterher her springen und gefälligst ihre Programme anpassen.
Anders herum Sieht das btw. ganz anders aus: Pöttering pushed die ganze Zeit neue Änderungen in den Linux-Kernel und ersetzt dauernd Softwarekomponenten die ihm nicht passen. So gesehen bei udev, dbus, OpenNTP oder eben beim nicht Support von Hurd.
Prominentestes Beispiel sind Usernamen, die mit Nummern beginnen. Seit Jahrzehnten Teil vom PAM-System und in vielen Institutionen etablierte Praxis. Systemd kann damit nicht umgehen. – Kein Problem von systemd. Da soll man gefälligst restriktiver mit den Usernamen umgehen.
Anderere Linux-Betriebssysteme im suspend hat Systemd halt ab Version 215 einfach mal geschrottet. Aber natürlich kein Problem von systemd: Man hat ja ein Flag eingeführt, dass die gefälligst setzen sollen, dann werden sie auch nicht geschrottet.
Es steht hier ein Mensch im Raum der allen erklärt was sie anders zu machen haben und das auch noch alle zwei Wochen anders. Selbst sagen lassen kann der sich aber gar nichts.
Besonders schön ist die Schreibweise. Auf der einen Seite nutzt man selbst die Aussprache von System D, beruft sich auf die englische Rechtschreibung, die Systemd fordern würde, erklärt dann aber, dass systemd die einzig legitime Schreibweise ist.... Denn was ist schon die englische Grammatik gegen das Wort von den systemd-Entwicklern.
Kein Wunder, dass da keine konstruktive Diskussion bei rüber kommt.
Das ist absehbar dass das schief läuft, weil da einige keinen Bock haben. Und irgend wann fragt man sich halt ist es einfacher 1500 Programme anzupassen oder ein mal Systemd zu ersetzen. Und du siehst im Netzwerkbereich, dass das vollständig passiert ist. Ist halt um Größenordnungen einfacher einen neuen init-deamon zu schreiben als die Netzwerkprogramme auf alle Eigenheiten von Systemd anzupassen. Gerade die Leute, die hinter dnsmasq stehen haben zum großen Teil an einem init-System mitgearbeitet womit ihr dnsmasq problemlos läuft. Genau so wie Systemd seinen eigenen dhcp mitbringt. (Der btw. so buggy ist, dass keine mir bekannte Distro den einsetzt.)
Es ist also offensichtlich das das Problem nicht alleine bei dnsmasq oder Systemd liegt. Die einigen sich einfach nicht.
Man kann dieses Thema nicht wie von Meillo gewünscht diskutieren:
Ich finde, man merkt deutlich, dass noch nicht die Zeit gekommen ist, um nuechtern, sachlich, neutral und wissenschaftlich dieses Thema neu zu bewerten. So werde ich wohl noch ein paar Jahre darauf warten muessen.
Es geht darum, ob jeder seinen Dienst nach eigenem Gusto schreiben kann, solange man sich an an großen Tischen ausgehandelte Standards (wie POSIX oder LSB) hält oder ob einer nach eigenem Gusto alle paar Wochen neu bestimmt wie alles zu funktionieren hat.
Am Ende halte ich es für absehbar, dass Letzteres sich deutlich schneller entwickeln wird und einfacher zu verstehen sein wird, während ersteres deutlich stabiler läuft und deutlich mehr Spezialfeatures für Spezialanwendungen hervorbringen wird. Und genau das sehen wir IMHO auch.
Was man will ist dann eine Abwägungssache. Und genau deshalb halte ich es btw. so problematisch, dass jetzt defakto alle Distros systemd (Auch Debian läuft ja nicht mehr wirklich ohne) machen. Ich hätte gerne die Wahl. Deswegen halte ich die Entscheidung von Debian, den Support von nicht-Systemd-Systemen defakto zu droppen falsch.
Edit: Einiges detaillierter dargestellt.