Zum neuen Kernel 4.10:

[rockyracoon]

@niemand:

Jo, dann warte mal, bis dein Testing knallt.

Nö - - wenn ich bis zum Stretch/Freeze kein Knallen (?) erlebt habe, dann ist so ein Knallen (?) beim Stretch/Stable erst recht nicht zu erwarten.

Debian betreibt imho eine sehr verantwortliche Systempflage. Versauen kann sich das System eigentlich nur der unsachgemäß frickelnde Benutzer. Deshalb verzichte ich auch auf das Verwenden von Backports oder gar Fremdquellen.

[ViNic]

Da überschätzt Du meine Kenntnisse.

Das schöne an Kenntnissen ist ja, die kann man ausbauen
Kernel kompilieren ist gar nicht schwer

[rockyracoon]

Debian betreibt imho eine sehr verantwortliche Systempflage. Versauen kann sich das System eigentlich nur der unsachgemäß frickelnde Benutzer. Deshalb verzichte ich auch auf das Verwenden von Backports oder gar Fremdquellen...

... und das Kompilieren von Kerneln*. Warum auch eigentlich?

* https://debian-handbook.info/browse/de- ... ation.html

[Milbret]

@rockyracoon
Dann mach es dir in der Debian Stube mit Stretch schon mal gemühtlich.
Da Stretch schon im Freeze ist, werden keine großen Katastrophen mehr auflaufen.
Hier und da noch ein paar grobe Schnitzer, aber nichts was dein System total zersägen dürfte.
In einigen Monaten, mein Schätztermin liegt so Ende April, dürfte Stretch dann auch raus kommen.
Da die Bugs in den letzten 2-3 Wochen schon kräftig gefallen sind, dürfte es also nicht mehr lange dauern.
Aber wie immer heißt es eben, I's done when it's done.

Nachtrag:
Du solltest aber anfang dich mit er Shell und Shellskripten vertraut zu machen.
Ist anfangs wahrscheinlich etwas schwierig, macht den Alttag aber ungemein einfach.
Ich komme immer mal wieder in Situationen in dem ich mir einem kleinen Skript einige Probleme schneller lösen kann als über die grafische Oberfläche.

Ist auch aktuell bei mir unter Windows 10 mit Powershell genauso.
Damit konnte ich einige Aufgaben wie Backups und auch Cleanups automatisieren.
Eine grafische Lösung in der Form gibt es dafür bei Windows nicht bzw. nicht so wie ich es möchte

Martin

[rockyracoon]

@Milbret:

Du solltest aber anfangen dich mit der Shell und Shellskripten vertraut zu machen.

Mach` ich doch, hab` ich doch - zumindest was einfache Shell-Kommandos betrifft. Meinen Brother Drucker/Scanner habe ich natürlich über Konsole installiert. Ohne "force"-Befehle wäre da nichts gegangen. Auch den "rule"-Befehl durfte ich nicht vergessen, damit Xsane den Scanner erkennt. Auf der Webside von Brother gab es dazu eine klare Anleitung. Und wenn dann Drucker und Scanner einwandfrei laufen, ist das ein feines kleines Erfolgserlebnis, welches meine durch und durch analogen Endomorphine (umgangssprachlich "Glückshormone") aktiviert. Eigene Skripte für Geistreicheres haben aber noch etwas Zeit...

Dann mach es dir in der Debian Stube mit Stretch schon mal gemühtlich.

YEP! Auf Stretch/Stable freue ich mich, weil ich kein Tüftler und Immerwiederneuesausprobierenwoller bin, sondern Anwender, welcher seine Programme (vor Allem Rawtherapee und Gimp für digitale Photographie) immer besser einsetzen und beherrschen will.

Ist auch aktuell bei mir unter Windows 10 mit Powershell genauso.

Am besten wäre dann "purge windows"...

[scientific]

@Colttt:

.. hast du denn so einen?

Nein. Aber wie geschrieben, soll die Wlan-Funktion optimiert sein.

Und wo ist dann der Vorteil ggü. dem 4.9er?

Im 4.10er sollte ein Patch sein, der auf meinem Rechner eine zusätzliche 3-Sekunden Verzögerung beim Booten abstellt, beim EC bei ACPI...

Hab den Kernel mit dem Patch manuell mal selber gebaut. Aber momentan scheint der noch ein wenig instabil zu sein. Mir friert gelegentlich mein X vollkommen ein. Manchmal nach Suspend, manchmal einfach so, wenn ich in Gnome ein Programm starten möchte.
Und Wenn ich den Rechner zuklappt, geht der Rechner zwar in den Suspend-Mode (wie auch im Log zu sehen ist), beim Wiederaufklappen aber bootet der Rechner neu.

Da scheint noch einiges an Schleifarbeiten bei 4.10 notwendig.

lg scientific

[scientific]

@niemand:

Jo, dann warte mal, bis dein Testing knallt.

Nö - - wenn ich bis zum Stretch/Freeze kein Knallen (?) erlebt habe, dann ist so ein Knallen (?) beim Stretch/Stable erst recht nicht zu erwarten.

Debian betreibt imho eine sehr verantwortliche Systempflage. Versauen kann sich das System eigentlich nur der unsachgemäß frickelnde Benutzer. Deshalb verzichte ich auch auf das Verwenden von Backports oder gar Fremdquellen.

Backports sind doch gar keine Fremdquelle mehr...

Und mit Backports hab ich mir das System auch noch nie versaut. Mit dem früheren debian-multimedia heute deb-multimedia (wenn ich das richtig im Kopf habe), hab ich mir schon ein paar Mal vlc und anderes zerschossen... Daher aktiviere ich das auch ausschließlich für die libdvdcss, installiere das und deaktivere diese Quelle gleich wieder.

Das mit den Fremdquellen und dem Systemversauen klingt sehr nach ehemaligem Ubuntu-User oder jemand, der sich viel auf Ubuntu-Seiten herumtreibt... Zugegeben, die verschiedenen Wikis bei Ubuntu geben oft in der Tat mehr her, als die wesentlich spärlicheren Debian-Wikis - die noch dazu oft stark veraltet sind... Aber wenn ich sehe, wofür in Ubuntu überall ein PPA eingebunden werden muss, was ich bei Debian aus dem Standardrepo bekomme, frag ich mich, wozu so viele überhaupt Ubuntu verwenden...

lg scientific

[Revod]

...Debian betreibt imho eine sehr verantwortliche Systempflage. Versauen kann sich das System eigentlich nur der unsachgemäß frickelnde Benutzer. ...

... bei stable ok ... ist noch nicht Ostern, jedoch bei Testing können Ostereiern vor Ostern eintreffen und wenn Du sie dann bemerkt hast reden wir nochmal darüber.

[BenutzerGa4gooPh]

... bei stable ok ... ist noch nicht Ostern, jedoch bei Testing können Ostereiern vor Ostern eintreffen und wenn Du sie dann bemerkt hast reden wir nochmal darüber.

Ich hatte es schon geahnt: Debian Testing ist das Analogon zu Windows10 Insider Builds. Duck und wech.
http://winfuture.de/news,96037.html

[rockyracoon]

@Revod:

bei stable ok ... ist noch nicht Ostern, jedoch bei Testing können Ostereiern vor Ostern eintreffen

In drei Tagen ist das Freeze von Debian/Testing.
"Ostereier", "Knaller" oder Ähnliches waren vorher nicht da und werden jetzt erst recht nicht zu erwarten sein, sondern befinden sich imho in der Phantasie der "Warner".

[KBDCALLS]

@niemand:

Jo, dann warte mal, bis dein Testing knallt.

Nö - - wenn ich bis zum Stretch/Freeze kein Knallen (?) erlebt habe, dann ist so ein Knallen (?) beim Stretch/Stable erst recht nicht zu erwarten.

Debian betreibt imho eine sehr verantwortliche Systempflage. Versauen kann sich das System eigentlich nur der unsachgemäß frickelnde Benutzer. Deshalb verzichte ich auch auf das Verwenden von Backports oder gar Fremdquellen.

Backports ist eigentlich relativ unkritisch. Den das sind ja Debianentwickeler. Bei Paketen aus fremden Quellen sollte man besser die Finger lassen . Denn da kriegt man manchmal das gruseln.

[breakthewall]

Kompiliere doch den Kernel selbst und musst nicht extra auf testing gehen.

Mein Distributor liefert standardmäßig Kernel-4.4 aus und aus Spaß habe ich einen 4.9-Kernel compiliert und es ist jetzt mein Default.

Und dir ist auch bewusst, inwieweit sich der Debian-Kernel vom Mainline-Kernel unterscheidet? Klar kann man immer kompilieren, nur bei Letzterem hat man keinen freien und sauberen Kernel mehr. Der Debian-Kernel dagegen, enthält nur noch freie Bestandteile, und nichts mehr was weder Source-Code mitbringt noch gegen die Debian eigenen Richtlinien verstößt. Daher hoffe ich für dich, sofern das für dich Relevanz hat, dass den Kernel mit einer entsprechenden Konfiguration kompiliert hast.

[guennid]

Ich benutze seit über 10 Jahren nahezu ausschließlich selbstkompilierte Kerne von kernel.org

[Revod]

@ rockyracoon

Ja richtige " Knaller " meinte ich auch nicht. Mit " Ostereiern " war eher schwerwiegendere Funktion Fehler. Habe Testing ja... ca. über 2 Jahren und ging auch lange Zeit sehr gut mit den Update ( Auch mit meine eigene Bedienung Konfiguration und der eine oder andere fremde Software und echt jetzt, unbedeutende gepingte Tools, wie das LXPanel, weil die höhere Version buggy ist ).

Auch welches Desktop man benutzt spielt eine Rolle, da gab es in letzter Zeit einige User mit " Magenbeschwerden " mit Testing.

Hatte die Idee Testing wie eine " Rolling Release " Distri zu behandeln, weil ich nicht immer das grosse " Update Risiko " mitmachen wollte ( Auch schon erlebt, nach drei misserfolgte voll Update und Back zurück spulen war eine neue Installation nötig, was ich nicht wieder riskieren will. Auch ein Grund warum ich vor 10 Jahren die " WSUS " velassen hatte ).

Nun ja, dieser " Rolling Release Testing Test " hat am Ende nicht geklappt. Seid 6 Monate keine gültige Sitzung mehr, Mate-Tools vom Mate-Control-Center starten unter lxde-gtk2 nicht mehr, keinen Shutdown / Neustart aus dem Benutzer mehr möglich.

Konnte vor ca. 3 Monate alle diese Fehler beheben, doch nach dem 3. Update waren die gleichen Fehler wieder da, da kommt man sich wie Sisyphos vor wozu ich echt keine Lust darauf habe und erst Recht keine Zeit. Mit Systemd kann ich Debian auf meinen ca. 12 jähriges Fuji echt nicht gebrauchen, nur noch schwarzes Monitor, egal mit ob mit nouveau oder non-free und keine Tastatur Befehl Funktionen mehr möglich usw. Nun ruht es seid drei Monate unberührt vor sich hin und fahre vorerst " nur " mit meiner ersten Distri, PCLinuxOS 32 bit, die die 32 bit seid 6 Monate auch eingestellt wurde ( Dafür kommt eine neue 32 bit aus PCLinuxOS, " Uplos " entwickelt von PCLinuxOS User / Entwickler was in kürze ganz fertig sein wird, fehlt nur noch die Lizenz Entscheid ).

Sind noch 2 bis 5 weitere " Kleinigkeiten " doch die obigen " Ostereiern Erlebnisse " waren / sind ziemlich die fettesten. Nun heisst es für mich abwarten und Tee trinken, bezüglich Debian 32 bit, weiss noch nicht ob ich auf Old-Stable-Jessie zurück gehe und dabei auf " ewig " darauf bleibe, oder mit einer neue Installation auf Testing weiter mache. Unter Jessie, damals Testing hat ausser auf meinen erwähnten Fuji alles funktioniert bei allen anderen Rechner, auch mit meinen " extra Spezial Konfigurationen und ca. 5 Fremde Software und gepingtes LXPanel " . Also wie Du nun liest meine Ostereier in Stretch, resp. Testing kommen gerne immer wieder Mal...

[ViNic]

Und dir ist auch bewusst, inwieweit sich der Debian-Kernel vom Mainline-Kernel unterscheidet? Klar kann man immer kompilieren, nur bei Letzterem hat man keinen freien und sauberen Kernel mehr.

Man kann auch die Debian-konfiguration wählen und somit erhält man einen Debian-kompatiblen Kernel.

Der Debian-Kernel dagegen, enthält nur noch freie Bestandteile, und nichts mehr was weder Source-Code mitbringt noch gegen die Debian eigenen Richtlinien verstößt.

In der Regel "besudelt" man es im nach hinein ohnehin mit modulen aus non-free, wenn man seine Hardware vollständig nutzen will.

Daher hoffe ich für dich, sofern das für dich Relevanz hat, dass den Kernel mit einer entsprechenden Konfiguration kompiliert hast.

Ich nutze kein Debian, folglich habe ich keine Probleme damit

Edit: Was ich noch ergänzen wollte. Kernel kompilieren bringt mMn. den Vorteil, das man sich gewissen Unabhängigkeiten schafft gegen über dem Distributor. Was passiert wenn man aus den Backports oder anderweitigen Quellen, den gewünschten Kernel und Funktionalität nicht bekommt. Was ist wenn die gewünschte Firmware zwar existiert, aber es noch nicht in den Linux-Sources selbst ist und man selbst Hand anlegen muss? Es kann Sinn machen, sich mit solchen Sachen zu beschäftigen.

[rockyracoon]

@Revod:

...Auch mit meine eigene Bedienung Konfiguration (?) und der eine oder andere fremde Software...

Da hast Du Dir vermutlich Deine eigenen "Ostereier" gelegt und solltest nicht Debian ohne Selbstfrickelei für entstehende Probleme verantwortlich machen. Geschweige denn vorsichtige Leute wie mich unnötig und auch vergeblich verunsichern wollen.

Und abgesehen von dem Kauderwelsch in dem Du schreibst, spricht der Rest Deines Posts von verquerem Denken, bei dem mich gar nichts mehr wundert.

@ViNic:

Was ich noch ergänzen wollte. Kernel kompilieren bringt mMn. den Vorteil, das man sich gewissen Unabhängigkeiten schafft gegen über dem Distributor. Was passiert wenn man aus den Backports oder anderweitigen Quellen, den gewünschten Kernel und Funktionalität nicht bekommt.

Ich habe nie eine Funktionalität vermisst. Im Gegenteil, bei Debian habe ich viele wertvolle Anwendungen gefunden. Daher brauche ich keine "Unabhängigkeit" vom Distributor.
Ich teile vielmehr den Post von breakthewall, der vor einem - zudem unnötigen - Kernel-Gefrickel (sprich "Kompilation" - https://debian-handbook.info/browse/de- ... ation.html ), warnt. Es sei denn, man will experimentieren.

[Revod]

Du hättest " Richter " werden sollen, oder doch nicht wegen der viel zu rasche Beurteilung ( Beurteilungen lese ich es nicht nur, nun Richtung meiner Person ).

Zwei reale Beispiele, soeben mein Testing fertig geupdatet ( nach 3 Monate knapp 900 Pakete, in mehrere Etappen und einen Neustart 2 Std Zeit gebraucht ) und immerhin zwei Bugs weg. LXDE meldet nun nach dem einloggen " Keine gültige Sitzung " nicht mehr.

Das System kann nun aus dem Anmeldemanager auch neu gestartet und runter gefahren werden, will heissen die damaligen Befehle, die ich mir damals per Scripte ( Tastenbefehle ohne Rückfrage im lxde, eben lxde hat keine Tools wie Mate, KDE usw. ) eingerichtet hatte nicht mehr gültig sind ( wird ein Klacks sein die Befehle neu zu editieren ). Vor drei Monate wollte das System nicht mehr runter fahren, auch nicht aus dem Anmeldemanager.

Aus Mate nur die [deb]mate-system-tools[/deb] installiert. Wie Du siehst da ist nix im Stretch davon aufgelistet. Allerdings und eigenartigerweise in mein Synaptic noch nicht unter " veraltet " angezeigt. Ich vermute schwer, dass Mate aus Stretch von Grund auf neu rekompiliert werden muss. In Meine sources.list habe ich allerdings " testing " eingetragen.

Habe heute nix neues konfiguriert, oder meine Konfigurationen neu angepasst und trotzdem die obigen zwei Bug weg und wenn Du nun noch " mate-system-tools " nicht im Stretch gelistet berücksichtigst, will heissen dass noch ein paar Dingens in Arg sind im Stretch.

Ach ja, am " init 3 " habe ich auch nichts " rum geschraubt " und trotzdem, es wird nicht geladen, von init 3 bis init 6 nicht.

Alles andere funktioniert nun wieder, ausser die " root pexec " Befehle zum starten eines Tools mit root Berechtigungen, Synaptic, gParted .... Jedoch mit " gksu " , oder aus der Konsole " su und Passwort und synaptic Eingabe und Enter " starten diese Anwendungen, auch " Gufw Firewall Einstellung tool "

Für mich heisst das, dass das ganze pexec Zeug im Stretch noch nicht richtig angepasst wurde, und auch an diese Pexec Scripte habe ich nix rum gefrickelt). Einige user mit Testing mussten die starter.desktop Dateien neu editieren, von " Exec=synaptic-pexec " auf " gksu synaptic " und gut ist. Bin also nicht der einzige mit gleichen und ähnliche Bugs so um nur wegen eigene Konfigurationen anzudeuten. Das sind keine System eigene Konfigurationen, sondern lediglich die lxde Bedienung etwas " komfortabler " damit bereichert, das ist alles.

[simpel]

@rockyraccon

Du kannst sicher sein, manch eine/r frickelt so lange am System rum, bis irgendwas nicht mehr funktioniert, damit er/sie wieder was zu frickeln hat.
Allerdings handelt es sich dann idealerweise um ein Testsystem, welches auf einem separaten Rechner oder einer separaten Platte installiert ist.
Vielleicht hast du irgendwann die Möglichkeit dir ein solches Testsystem einzurichten. Du wirst feststellen, die Lernkurve steigt sehr schnell. Und es vermittelt ein gutes Gefühl, sein System selbst zu administrieren - so gesehen meint frickeln ungefähr das Gleiche

[Revod]

... jepp und ist die richtige Vorgehensweise, auf separate HD, oder Rechner. Anderweitig kann man bei stable bleiben, sich einen Desktop wie XFCE, oder Gnome3, oder Mate, oder und KDE installieren, die ihre eigene " komfortable " Tools von Haus aus mit bringen und doch bloss nix verändern aus Angst Gründe was Kaputt zu machen, sondern nur nutzen so wie es daher kommt.

Dann würde mir die Funktion " Supertaste+1 = Laufwerk Schublade öffnen und alt+1 = Laufwerk Schublade schliessen, oder Supertaste+X = runter fahren ohne Rückfrage usw. " und gelernt hätte ich auch nix, stimmt.

Das alles und die " mate-system-tools " haben alles unter Jessie-Testing bis hin zum Stretch vor 6 Monate funktioniert, die Rede ist über eine langfristige Zeit von gut 3 bis 4 Jahre, also nicht nur für ein paar Minuten / Tage. Will heissen, dass meine extra Konfigurationen über Bedienung im LXDE Desktop nicht soooo verkehrt, oder gar falsch sind, auch weil ich die genau gleichen Konfigurationen in PCLinuxOS seid über 6 Jahren eingerichtet habe und niemals das System in keiner, minimalster weise beeinträchtigten.

@ rockyraccon

- Und ja, mein Kauderwelsch... das Land Deutschland ist nicht die Welt ( Auch " Amis " nicht, die meinen alle müssen ihre Sprache können, wenn sie in einen fremdes Land reisen ), es gibt auch noch andere Nationen.

- Schuld an Debian Distri, oder Linux habe ich niemals gegeben und nochmals, seid über ca. 7 Jahren nutze ich ausschliesslich Linux ( vor 10 Jahren damit angefangen, Vista sei Dank, doch war 3 Jahre lang zu faul wegen xy.doc um ins odf Format zu portieren und daher nutzte noch mein w2k-pro SP4 nur deswegen ).

- Wie Du nun aus meiner, obige Erklärung vielleicht ( ... na ja, wegen meinen Kauderwelsch ) erkennen kannst, es sind keine eigene selbst gelegte Ostereiern.

- Vergessen zu sagen, empfehle Dir weniger zu beurteilen, dafür sachlicher und mehr argumentieren zu versuchen.

[Dogge]

Zwei reale Beispiele, soeben mein Testing fertig geupdatet ( nach 3 Monate knapp 900 Pakete, in mehrere Etappen und einen Neustart 2 Std Zeit gebraucht ) ...

Bei einem rolling release (ja, gleich kommt ein Rabulist und erzählt mir warum Testing kein echtes RR ist ) sollte man regelmäßig updates durchführen. 3 Monate sind schon eine sehr lange Zeit, da hat sich viel geändert, wie du ja an den 900 Paketen siehst. Ich mache bei Testing tägliche Updates und bin nach 3 Wochen Urlaub schon erschlagen wie viel da heruntergeladen werden muss.
Bei einem RR kann es bei langer Zeit zwichen den Updates passieren, dass bei manchen Paketen Versionen übersprungen werden weil in der Zeit schon 2 oder 3 Updates für das Paket kamen und dabei kann es halt mal knallen. Bei täglichen Updates hab ich mit Testing keine negativen Erfahrungen gemacht.

2007/2008 hatte ich mal Arch, dann hatte ich zu Hause mal für 6 Monate kein Internet. Nach dem Update habe ich ein paar Tage versucht das zu reparieren und irgendwann entnervt Arch den Rücken zugewandt.

[rockyracoon]

@Dogge:

Bei täglichen Updates hab ich mit Testing keine negativen Erfahrungen gemacht.

So ging es mir auch. Trotzdem freue ich mich darauf, mit Stretch/Stable etwas kontinuierlicher und upgradeärmer zu fahren.

Zum anderen verquasten Posts gilt ab jetzt für mich: "Dont Feed The Troll..."

[Revod]

@ Dogge

.... 900 Pakete .... jo eben von " jessie-stable später auf stretch-stable " voll zu upgraden sind es vermutlich weitaus mehr... Daher meinen " sinnlichen Testing-RR Testversuch " und eben, es ging über 3 - 4 Jahre immer sehr gut...

Hatte ich ja auch gemacht ( alle 3 bis 4 Tage geht's auch, sehr selten über ca. 80 Pakete ). Doch nach dem ich die Bugs vor 3 Monate gefixt hatte und nach dem zweites Update alle meine Fixes nichts mehr nutzten stellte ich es zurück wie es vor dem Fix war und trotzdem blieben die Bugs erhalten. Und ich vermute auch schwer, meinen ca. 13 Jahres altes AMD Athlon HW Chipsätze werden nicht mehr richtig unterstützt. Deswegen dachte ich in einen Post von mir an Wheezy zurück zu gehen.

Ich vermute auch schwer richtung Systemd, weil immer nach einen udev und Systemd Update die Probleme erschienen sind, bei allen anderen Pakete und Kernel nicht nicht. Genau so war es mit zweiten Systemd Update in Jessie damals, auf meinen FujiTsu Amilo Notebook, schwarzes Monitor und keine Maus, oder Tastatur Funktion mehr vorhanden.

Und als drittes, ich weiss auch nicht wie gut der Code von Systembibliotheken für 32 bit Systeme noch ist. Ob man sich vlt. mehr mühe für 64 bit gibt und unbewusst das 32 bit eher mehr nachlässiger behandelt sein könnte, weisst ja warum.

Kann mich nur wiederholen, ein anderer User hat, oder hatte mit Mate auch seine grosse Probleme, bei einige anderen funktionierte das pexec nicht mehr auch so wie bei mir.

Meinen Jessie ( Testing von damals ) Buck-UP habe ich. Nun eröffnen 2 neue Möglichkeiten, das Buck-Up zurück zu spielen und alles updaten und gucken, oder Stretch neu installierien und von Grund auf wieder neu beginnen und gucken....

... der Rest ist klar ( RR ) ...

[Dogge]

@ Dogge

.... 900 Pakete .... jo eben von " jessie-stable später auf stretch-stable " voll zu upgraden sind es vermutlich weitaus mehr... Daher meinen " sinnlichen Testing-RR Testversuch " und eben, es ging über 3 - 4 Jahre immer sehr gut...

Ich nutze auf meinem Hauptrechner seit 2010 Debian Testing (zuerst als LMDE, nachdem ich feststellte, dass ich außer dem Design alles deinstalliert hatte was aus den Mint-Repos kam hab ich dann irgendwann Anfang 2011 auf Debian Testing umgestellt) und habe auch mal Arch genutzt. Dass man regelmäßig updaten sollte, damit immer alle Änderungen gemacht und nicht beim "Sprung" über 2-3 Versionen verloren gehen ist meine persönliche Erfahrung. YMV.

Ein Vergleich vom Upgrade eines Debian Releases zum nächsten mit einem Testing-Upgrade nach mehrmonatiger Pause zu vergleichen macht meiner Meinung nach keinen Sinn, da das Update von Stable zu Stable gründlich getestet wird, das Testing-Upgrade vom Stand Zeitpunkt x und Update-Pause bis x+n Monate hat halt niemand getestet. Die Entwickler die Testing oder Unstable benutzen werden wohl immer auf dem aktuellsten Stand arbeiten, da sie ihre Pakete ja im Zusammenspiel mit dem state-of-the-art Debian testen wollen.

[simpel]

... ich vermute auch schwer, meinen ca. 13 Jahres altes AMD Athlon HW Chipsätze werden nicht mehr richtig unterstützt.

Dass ist durchaus möglich - neue Kernel enthalten neue Treiber, Treiber für veraltete Hardware fliegen irgendwann raus.

Für so alte Hardware verwende ich den 2.6er Kernel. Keine Ahnung, ob es den für Debian überhaupt noch gibt? CentOS6 wäre da meine erste Wahl (Support noch bis 2020, meine ich gelesen zu haben)

[Tintom]

... ich vermute auch schwer, meinen ca. 13 Jahres altes AMD Athlon HW Chipsätze werden nicht mehr richtig unterstützt.

Dass ist durchaus möglich - neue Kernel enthalten neue Treiber, Treiber für veraltete Hardware fliegen irgendwann raus.

13 Jahre sind für Hardware aus Sicht des Kernels noch jungfräulich
Zum Vergleich: Der SCSI-Controller meines ersten Rechners (Baujahr 1994) wird upstream immer noch gepflegt. Deine Probleme müssen eine andere Ursache haben