Re: Systemd-Zwang in Debian (war: Re: Debian Jessie => Stretch ... Und Tschüss)
Marc Haber - 20.06.17, 11:53:
> On Mon, 19 Jun 2017 08:03:17 +0200, Martin Steigerwald
>
> <martin@lichtvoll.de> wrote:
> >Für mich auf einem ThinkPad T520 ist Linux derzeit
> >zumindest zeitweise instabiler Schrott
>
> Das kann ich nicht bestätigen. Ich arbeite täglich mit einem T520 und
> habe ein zweites als Virtualisierungs-Server nicht ganz ohne Last im
> Testlabor stehen, das tut und ist auch stabil.
Ich teste neuere Kernel als Kernel 4.9. Mit dem läuft das weitgehend, bis auf
das gelegentlichen Hänger beim Tiefschlafen, wahrscheinlich noch beim
Einfrieren der Prozesse, das sollte aber entweder fehlschlagen oder
funktionieren, nicht hängen bleiben, oder beim Freigeben von Speicher. Der
4.10er geht mittlerweile auch. 4.11.3 und 4.12-rc4 war das letzte, was ich
versuchte haben aber das erwähnte Problem. Bei rc´s hab ich da noch ein
gewisses Verständnis, bei .3 hinten dran finde sehe ich das jedoch schon als
Verschlechterung gegenüber meinen früheren Erfahrungen. Und ja, es war hier
wahrscheinlich nicht sonderlich hilfreich, dass ich das nicht dazugeschrieben
habe.
Das Ding ist: Das ist nicht das erste Mal, und oft war es ein Problem mit
Intel DRM. Ein Intel-Entwickler antwortete mir auch mal und das deutete auf
eine gewisse Überforderung hin: Zig verschiedene Hardware-Generationen,
verschiedene Treiber-Versionen, verschiedene Treiber-Optionen… die Test-Matrix
explodiert. Verstehe ich auch alles… nur zusammen mit der Eigenschaft, dass
die Kiste dann einfach hängt, braucht ein sinnvolles Berichten von Fehlern
mehr Zeit, als ich aufzuwenden bereit bin. Grundsätzlich bin ich der Meinung,
dass ein OS nicht einfach hängen bleiben sollte. Niemals. Aber der Neustart-
Mechanismus für die GPU scheint oft genug einfach nicht zu greifen. Die Intel-
Entwickler bauen da gerade wieder dran rum, vielleicht verbessert das was.
Naja, ich verabschiede mich wohl vom Kernel testen, da ich, da mir das
Reporting bei gelegentlichen Hängern zu aufwändig ist, eh nichts Sinnvolles
mehr dazu beitragen kann. Damit testet natürlich wieder einer weniger, aber
sorry, auf diese Kernel oder zumindest Grafiktreiber bleibt hart hängen
Geschichte hab ich einfach keinen Bock mehr. Ein Microkernel hilft da auch
nicht automagisch, das ist mir bewusst, aber zumindest theoretisch ließe sich
da ein hardware-naher Treiber komplett neu durchstarten, wie es Minix 3 wohl
mit Netzwerk-Treibern schon hinbekommt. Aber das führt natürlich hier jetzt
auch zu weit.
> >Mir gefällt das alles auch nicht und ich warte nur darauf, dass irgendwann
> >eine Gegentendenz losgeht. Ich hab selbst bei RedHat einige Bugs
> >eingereicht, die die RedHat-Entwickler trotz Benutzer-Feedbacks, derzeit
> >mit dem Hinweis ignorieren, dass sie nicht von Upstream abweichen wollen.
> >Darunter so lustige Bugs wie, lässt sich /boot nicht einhängen, bootet das
> >System in eine Rettungskonsole, in der dann natürlich auch kein Netzwerk
> >bereit steht. Mehr noch: Wenn ich dann versuche, SSH wie systemctl zu
> >starten, geht Systemd *wieder* in die Rettungskonsole, *wieder* ohne
> >Netzwerk. Bei so einem Verhalten hat einfach *niemand* nachgedacht.
> >Workaround/Lösung: Alles unkritische mit "nofail" markieren.
>
> Dann wird aber auch nicht mehr auf dieses Dateisystem gewartet, was
> ggf dazu führen kann dass Dienste gestartet werden, bevor ein für
> diese Dienste notwendiges Dateisystem eingehängt ist. Dafür gibt es
> Lösungen, die aber allesamt die Semantik der /etc/fstab verändern,
> weil man sich die mount-Units nicht mehr generieren lassen kann. Und
> wieder ein Stück vom klassischen Unix weg.
Das ist so ein bißchen das Ding. Ich bin gar nicht mal pauschal dagegen, an
jahrzehntealten Dingen was zu ändern, allmählich, und so dass nicht alles
gleich kaputt geht, wenn man die Konfiguration nicht sofort ändert. Aber… die
mit der fehlenden Modularität sowohl in Systemd als auch in der Systemd-
Paketierung in Debian bin ich weiterhin nicht einverstanden. Und auch mit dem
Entscheidungsprozess dazu. Ich weiß, Systemd-Upstream-Entwickler haben auch
mit Distros gesprochen und sich auch einige Dinge von Debian abgeschaut für
Konfigurations-Standardisierungs-Vorschläge… aber dann heißt es "Das machen wir
jetzt so, und ihr passt euch entweder an… oder kommt halt nicht in den Genuss
der ganzen anderen Funktionen von Systemd", da es einfach im wesentlichen ein
Ganz-oder-gar nicht ist. Zumindest sobald z.B. GNOME zum Einsatz kommt.
Mir fehlt da der Wettbewerb um die beste Implementation einer Funktionalität.
Den erschwert Systemd durch den "Alles-in-einem-Klumpatsch"-Ansatz.
So wäre auch bei systemd-resolved und der sonstigen Netzwerk-Funktionalität
von Systemd aus meiner Sicht ein Ansatz, das getrennt zu paketieren. Dann
kommt das nicht einfach so als Standard, ohne das ich das merke.
> >So einen Bug, bei dem Debian-Paket-Betreuer nicht von Upstream abweichen
> >wollen, gibt es auch bei Debian. Obwohl es super einfach wäre, das anders
> >zu lösen. So hat systemd-resolved, der standardmäßig jedoch nicht läuft,
> >als Standard-DNS-Server 8.8.8.8 von Google eingetragen. Das Systemd-Paket-
> >Maintainer-Team von Debian ist nicht bereit, den Standard-DNS-Server
> >rauszupatchen
>
> Ja, Information Leak. Dass da das TC nicht draufgehauen hat ist mir
> ein Rätsel.
Ich denke, bislang hat kein DD das TC beauftragt, sich damit zu befassen. Ich
betreue zur Zeit im Wesentlich ein Paket, das mir jemand hochlädt und bin kein
DD. Ich sehe mich also nicht in der Position, das selbst zu tun.
> > Leider sehe ich diese Haltung teilweise auch
> > beim Debian-Systemd-Paketbetreuerteam.
>
> Nein, das kann ich nicht bestätigen. Martin und Michael sind _sehr_
> hilfreich, akzeptieren Bugreports, gehen professionell damit um und
> haben mir schon mehr als einmal konstruktiv geholfen, wie ich mein
> Ziel trotz systemd wieder erreichen kann. Von den beiden habe ich
> dabei mehr gelernt als durch ausgiebige, mehrfache Lektüre der
> dankenswerterweise in großem Umfang vorhandenen Dokumentation.
Hilfreich ist Michael oft. Das sehe ich ja auch hier. Und mit Martin habe ich
bislang kaum Kontakt. Ich sehe auch, dass die beiden ein Spagat zwischen
Upstream und Debian-Anwender hinzubekommen zu versuchen. Bisweilen sah ich
aber auch da die Tendenz "Das macht Systemd so, also muss das richtig sein".
Oder zumindest habe ich die Antwort so gedeutet, die Michael möglicherweise
anders gemeint hat. Ich hab Michael auf der Debconf in Heidelberg gesehen und
da war ich auch positiv überrascht.
Jedoch, sehe ich einfach manchmal einen Rückzug auf eine Denkwelt, die das
Anwender-Bedürfnis, hier z.B. kein Google DNS in der Standard-Konfiguration als
Fallback, mit technischen Argumenten – Google DNS sei zuverlässig, und besser
ein DNS als ein nicht funktionierendes Netzwerk – abtut, die dann einfach
schwerer wiegen sollen, wie die Argumente dagegen. Und dann dreht sich die
Diskussion im Kreise, ohne das da wirklich noch was passiert. Die Art der
Diskussion, die reine Beschränkung auf technische Argumente, wie ich sie im
Systemd-Umfeld so oft gesehen habe, zusammen mit "meine technischen Argumente
sind richtiger als Deine technischen Argumente oder Deine technischen
Argumente sind ja gar keine technischen Argumente" bringt hier aber keine
Lösung. Ich kann eine solche Diskussion ewig weiterführen. Die Bedenken der
Anwender, die den Fehler berichteten oder bestätigten bleiben dennoch
unbeachtet. Das ist ein Teil der sozialen Komponente, die ich meine. Im Fall
der DNS-Geschichte geht es mir und anderen darum, nicht irgendwann als
Fallback so ein Google DNS untergeschoben zu bekommen. Z.B. wenn systemd-
resolved dann doch mal Standard wird… und ein DHCP-Server aus irgendeinem
Grund mal keine DNS-Server-Konfiguration mitliefert.
Okay, ich lasse einfach mal Deine Einschätzung dennoch mal auf mich wirken…
und ja ich sehe auch, dass die Debian-Paketbetreuer da bei weitem nicht so
extrem scheinen, wie ich Upstream wahrgenommen und gedeutet habe.
> >Das ist auch mein hauptsächliches
> >Argument: Aus meiner Sicht ist Systemd hauptsächlich ein
> >zwischenmenschliches Problem. Entwickler, die mit etwas, was ich als pure
> >Arroganz und teilweise auch Selbst-Überheblichkeit bezeichnen würde,
> >Feedback vom Tisch wischen… schaden meines Erachtens der freien
> >Software-Gemeinschaft, die auf ihre Software zurückgreift – und sei es
> >auch nur aufgrund des Drucks, das so viele andere (Distros und
> >Upstream-Projekte) es auch tun. Das war mit Pulseaudio so, das ist mit
> >Systemd so. Und das hat ziemlich direkt auch mit Lennart Poettering zu
> >tun.
>
> Amen.
Na, da sind wir uns dann einig.
Adios,
--
Martin
Reply to: