Andreas Hermann schrieb am Wed, 6 Jul 2022 16:45:17 +0200:
> Während Arch und die Ableger für meinen Geschmack etwas zu schnell
> sind, Updates in den Upstream zu schicken, war Debian für meinen
> Geschmack um einiges zu langsam. Da hinkten einige Pakete mal ein Jahr
> und mehr hinter den Releases der Entwickler zurück. Das ist mir mit
> einigen Programmen etwas übel aufgestoßen - u.a. mit Ardour, wenn ich
> mich recht erinnere. Da gab es innerhab von einem Jahr etliche
> Verbesserungen, aber bei Debian waren die halt noch nicht "stabil".
Es hängt m.E. eben auch davon ab, was man mit seinem Linux primär machen
will.
Für meinen Produktiv-Einsatz hat eben die Laufstabilität und
Funktionskompatibilität aller zusammen wirkenden Programme höchste
Priorität und die neueste Programm-Version ist mir im Einzelfall i.d.R.
nicht so wichtig.
Da muss man z.B. schnell und dringend eine wichtige E-Mail raushauen und
just in diesem Moment stellt man fest, dass das letzte Rolling-Release-
Update bestimmte Programm-Funktionalitäten geändert hat und z.B.
deshalb eigene Skripte oder andere Dienst-Programme im Zusammenwirken
mit dem E-Mail Programm nicht mehr funktionieren. Oh - das nervt,
ausgerechnet in einem solchen Moment jetzt auf Fehlersuche gehen zu
müssen :-)
> Per se ist das nichts schlimmes und ich bin durchaus auch für
> konservatives Aktualisieren. Das war mir dann aber wieder etwas zu
> konservativ. :-)
Was hältst Du vom Debian-Testing? Ok - ist kein Rolling-Release!
Ich glaub nach ca. 2 Wochen im Sid gehen die Neuerungen ins Testing.
Läuft nach meiner Erfahrung i.d.R. ebenfalls mit vergleichbaren allseits
bekannten "Rolling-Release-Nebenwirkungen" erstaunlich stabil und dann
aber mit aktuellster Software.
Ein aktuelles praktisches Beispiel:
Gestern zum Beispiel kam das von mir sehnsüchtig erwartete zweite
Micro-Code-Update in Debian-11-Bullseye-Stable an:
Als dieses Bullseye im Sommer des vergangenen Jahres stable wurde,
lief komischer Weise nur bei einem von dreien meiner mit Debian
bestückten Rechner, Debian leider nicht mehr rund. Es hat relativ
lange gedauert, bis ich herausgefunden hatte, dass die Systemabstürze an
Kompatibilitätsproblemen des neuen Kernels mit der von Intel zur
Verfügung gestellten Mirco-Code-Software eben dieses speziellen
Prozessor-Typs zu tun hatte. Also habe ich kurzfristig das
Micro-Code-Modul des Kernels auf diesem Rechner deaktiviert und ich
konnte auch mit dem dritten Rechner wieder störungsfrei weiter
arbeiten. Nach dem das erste Micro-Code-Update unter Bullseye-Stable
aufgespielt war, habe ich das Mirco-Code-Modul wieder aktiviert und
konnte sehen, dass ich ins Schwarze getroffen hatte, denn es lief
alles, auch jetzt mit dem notwendigen Prozessor-Schutz wieder wie es
sollte.
Und jetzt das Interessante:
In einem bei mir parallel laufenden Debian-12-Bookworm-Testing konnte
ich sehen, dass etwa seit Mai diesen Jahres ein neues zweites
Mico-Code-Paket getestet wurde. Ah ha, interessant dachte ich bei mir,
mal sehen, wann das denn in Stable zur Verfügung gestellt wird.
Unerwartet und sehr vereinzelt kam es dann aber in den Folgemonaten hin
und wieder zu den überwunden geglaubten Systemabstürzen meines Stable.
Verdammt noch mal, warum dauert das so lange mit der Freigabe des
Micro-Code-Updates? Ziemlich sauer habe ich also wieder das
Kernel-Modul deaktiviert. Dann durfte ich in der Zwischenzeit noch ein
oder zwei Kernel-Updates bewundern und siehe da, gestern Nachmittag kam
endlich das zweite Micro-Code-Update in der selben Version, wie es
bereits seit Mai im Testing getestet wird. Gestern habe ich also das
Micro-Code-Modul wieder aktiviert und heute scheint alles wieder rund
zu laufen.
Ja, man sieht auch hier: Bei Linux gibt es letztlich keine Garantie
dafür das immer alles rund läuft, weder bei einem Stable-, Testing-
oder Rolling-Release-System.
Trotzdem muss ich sagen, dass mich das schon sehr beeindruckt, was die
Debian-Jungs da leisten. Die Erfahrungen aus dem Testing-Zweig
stabilisieren das Stable, nicht nur beim Release-Wechsel, sondern auch
im fortlaufenden Betrieb, und umgekehrt; die Erfahrungen aus Stable
machen andererseits auch Testing wieder stabiler.
> Ich muss auch gestehen, dass ich mit dem Debian Package-Manager nie so
> richtig warm geworden bin. Da gefiel mir das System von FreeBSD sogar
> besser - aber das ist nur eine persönliche Präferenz.
Ja, da gebe ich dir recht. Den Pacman wünsche ich mir auch für Debian.
Allein, wie schön sich da die unterschiedlichen Pakete in allen
Hierarchie-Ebenen mit allen Abhängigkeiten in allen Verzweigungen
darstellen lassen, ist schon klasse :-)
Ja, aber das hat auch historische Gründe. Debian hat wohl als erste
Linux-Distribution, ein Paketierungssystem für vorkompilierte Pakete
entwickelt. Jetzt sind da leider noch immer "ein paar Inkonsequenzen"
drin. Arch-Linux ist jünger und hatte es deshalb leichter, konnte bei
seiner Neu-Entwicklung des Pacman auf etwas Vorhandenes zurückgreifen
und von Anfang an "die Weichen richtig stellen".
Um die obere Hierarchie-Abhängigkeits-Ebene ausfindig zu machen
behilft man sich in Debian halt mit 'rdepends'. Insgesamt ist Debian mit
der ständigen Weiterentwicklung von 'apt' aber auf einem guten Weg, der
mir sehr gefällt und das Paketierungssystem arbeitet nach meiner
Erfahrung bei Aktualisierungen, Installationen und Deinstallationen im
alltäglichen Einsatz äußerst zuverlässig.
--
Gruß Peter