Systemd-Zwang in Debian (war: Re: Debian Jessie => Stretch ... Und Tschüss)
lindermann - 19.06.17, 06:23:
> Wow. Eine dependency-hell jagt die nächste. Ich habe noch *nie* in
> meinen Jahren, seit ich mit Debian (etch glaube ich) angefangen habe, so
> einen Mist beim Versionssprung erlebt – pardon!
>
> Mit stretch scheint es unmöglich geworden zu sein, ein anderes init zu
> betreiben außer systemd. dpkg rennt in einen Fehler nach dem nächsten
> und alle haben entweder mit systemd oder udev zu tun.
>
> Ich glaub langsam, das war's für mich mit Debian. Eine Distro, die mir
> ein init-System aufzwingt, ist nicht meine Distro. – Ernst gemeinter
> Dank dennoch an die allermeisten Debian-Entwickler für ihre tolle Arbeit.
Ich kann Deine Bedenken nachvollziehen. Mir gefällt das auch nicht wirklich,
ich gehe da aber derzeit noch den Weg des geringsten Widerstand. Da ich aber
auch mit dem Linux Kernel zunehmend Schwierigkeiten habe, zuletzt, weil die
Intel-Entwickler den Intel-Grafiktreiber für Sandybridge immer wieder kaputt
hauen und auch Tiefschlaf manchmal hängst und mit 4.11/4.12 sogar Standby
kaputt ist, möchte ich am liebsten auf ein anderes freies Betriebssystem
umsteigen. Der Linux-Kram scheint mir immer komplexer, unüberschaubarer und
fehleranfälliger zu werden – Plasma Desktop eine erfreuliche Ausnahme, da
dessen Entwickler modularisieren, vereinfachen und auch mal was rauswerfen,
derzeit. Kein Wunder bei der Entwicklungsgeschwindigkeit. Da wohl nur wenige
Intel-Entwickler, wenn überhaupt einer, noch mit Sandybridge arbeitet, testet
das auch kein Entwickler. Und die automatisierten Tests triggern solche Fehler
nicht. Fehlerberichte für "Ich bleibe manchmal einfach *ohne* weiteres
Feedback hängen" sind aufwendig. Ein Git Bisect für einen solchen Fehler für
mich indiskutabel. Für mich auf einem ThinkPad T520 ist Linux derzeit
zumindest zeitweise instabiler Schrott – das klingt krass, ist aber für mich
so. Redox OS läuft zwar auf einem ThinkPad T420, ist aber denke ich noch nicht
weit genug für den Praxis einsatz. Und Hurd hat auch zuviele Einschränkungen.
Aber ich denke, es braucht da mal sinnvolle Alternativen. Vielleicht FreeBSD.
Dann wäre Devuan Ascii vielleicht was für Dich. Oder, falls Du lieber eine
stabile Version möchtest Devuan Jessie. Ich habe beides bislang nicht
probiert, denke aber seit langem drüber nach. Zumindest in Devuan Jessie
(gleicher Stand wie Jessie) ist libsystemd0 aber soweit ich nicht mitbekommen
hab, noch mit drinnen.
Es kommt aber wohl auch darauf an, was für einen Desktop zu verwendet. GNOME
ohne Systemd geht nur mit heftigem Patchen. Mit Plasma sollte das *eigentlich*
noch einfacher gehen. So wie es aussieht schon:
Unstable von vor ein paar Tagen:
merkaba:~#100> apt purge systemd
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr
benötigt:
bluedevil bridge-utils colord-data ebtables gvfs-libs hplip-data iputils-
arping libcolorhug2 libfakekey0 libfprint0 libgdata-common libgdata22
libgee-0.8-2
libgoa-1.0-0b libgusb2 libk3b6-extracodecs libkf5purpose-bin libkf5purpose5
libndp0 liboauth0 libopenconnect5 libsane-hpaio libtaskmanager6 libteamdctl0
libudisks2-0
libvirt-clients python-pexpect-doc python3-notify2 python3-pexpect python3-
ptyprocess python3-renderpm python3-reportlab python3-reportlab-accel
qml-module-org-kde-bluezqt qml-module-org-kde-purpose qml-module-org-kde-
solid software-properties-common software-properties-kde
Verwenden Sie »apt autoremove«, um sie zu entfernen.
The following additional packages will be installed:
consolekit libck-connector0 libnm0 libpam-ck-connector plasma-desktop-data
sysvinit-core
Vorgeschlagene Pakete:
bootlogd
Empfohlene Pakete:
plasma-workspace
Die folgenden Pakete werden ENTFERNT:
colord* dbus-user-session* fprintd* gvfs* gvfs-backends* gvfs-daemons*
hplip* hplip-gui* iio-sensor-proxy* k3b* k3b-i18n* kde-config-systemd* kde-
full*
kde-plasma-desktop* kde-standard* kdeconnect* kinfocenter* libnss-
mymachines* libpam-systemd* libvirt-daemon-system* lxqt* lxqt-policykit*
network-manager*
network-manager-openvpn* network-manager-vpnc* packagekit* packagekit-tools*
plasma-desktop* plasma-discover* plasma-mediacenter* plasma-nm* plasma-
widgets-addons*
plasma-workspace* plasma-workspace-wayland* policykit-1* polkit-kde-agent-1*
printer-driver-postscript-hp* sddm-theme-breeze* systemd* systemd-container*
systemd-sysv*
systemd-ui* udisks2*
Die folgenden NEUEN Pakete werden installiert:
consolekit libck-connector0 libpam-ck-connector sysvinit-core
Die folgenden Pakete werden aktualisiert (Upgrade):
libnm0 plasma-desktop-data
2 aktualisiert, 4 neu installiert, 43 zu entfernen und 170 nicht aktualisiert.
Es müssen noch 391 kB von 6.196 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 122 MB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n]
Dann allerdings ohne Network Manager. Und udisks2 fällt auch raus, also nix
mehr mit in den Desktop integrierten Mounten von USB-Sticks – was bitte schön
zum Geier hat das Mounten von Datenträgern mit Systemd zu tun? Und einen
anderen Display Manager bräuchte ich dann auch.
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. Wieder mehr Komplexität. Sinnvoller wäre
da aus meiner Sicht gewesen, eine Möglichkeit zu bieten, Dateisysteme als zum
Booten notwendig zu markieren.
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, daher habe ich dieses hier konfiguriert:
merkaba:~> cat /etc/systemd/resolved.conf.d/no-fallback.conf
[Resolve]
FallbackDNS=
Das dann offenbar aktualisierungsfest ist. Denn auch, wenn systemd-resolved
standardmäßig nicht läuft, kann es sein, dass die Paketverwalter das in
Zukunft ändern. Ich denke auch, dass systemd-resolved in die resolv.conf
schaut, aber ich möchte nicht, dass bei einem DHCP-Server, der keine
Nameserver liefert (Fehlkonfiguration), oder bei anderen unvorgesehenen Fehlern
der Google-Nameserver zum Einsatz kommt und ich nicht mal merke, dass es mit
der Konfiguration ein Problem gibt.
Aber immerhin: Die Systemd-Geschichte hat zum Debian Fork Devuan geführt und
die dortigen Entwickler haben Devuan Jessie tatsächlich mittlerweile als
stabile Version freigegeben. Devuan Ascii ist noch in Entwicklung, laut
Berichten auf der dng-Mailingliste jedoch durchaus verwendbar. Das wird dann
auch ein Nachteil sein. Devuan wird Debian hinterherhängen. Wie lange es
dauert, bis Ascii rauskommt und ob es dann exakt auf dem Stand von Stretch
sein wird, weiß ich nicht.
Ich hab weiterhin sehr gemischte Gefühle in Bezug auf Systemd. Einige
Funktionen sind echt super, aber ich bin weiterhin der Ansicht, das wäre auch
modular möglich gewesen. Wie Upstream Bugreports und kritisches Feedback
handhabt, finde ich indiskutabel. Leider sehe ich diese Haltung teilweise auch
beim Debian-Systemd-Paketbetreuerteam. 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.
Ciao,
--
Martin
Reply to: