News Linux-News der Woche: Debian 13 und Mesa 25.2 betreten die Bühne

[garfield121]

AMD hat es vorgemacht, wie es geht. Wobei das auch ein langer und steiniger Weg war, endlose Diskussionen mit Linus, bis der amdgpu endlich in den Kernel übernommen wurde. Proprietäre Bestandteile kann man in spezielle Libs oder Firmware-Dateien auslagern.

 

[Grimba]

seit der Radeon 9600

Also, ich möchte dir ja nicht zu nahe treten, bzw. vermutlich sollte ich dir meine Bewunderung ausdrücken für deine Prinzipientreue, aber zur Zeiten der ATI Radeon 9600 (das war noch ATI und nicht AMD, hatte ein x600, das Nachfolgemodell, das war auch noch ATI) waren sowohl fglrx als auch radeon Treiber, die nicht der Rede Wert waren. Erst die ganz späten fglrx Treiber machten gescheites Spielen von UT2003/4 überhaupt halbwegs möglich, das habe ich damals auch gespielt. Aber da sprechen wir von späten Zeiten der HD5870, die auch noch aus dem Hause ATI kam. Erst danach kam die Übernahme.

Es stimmt, der radeon Treiber war noch immer besser als Nouveau, sogar deutlich. Aber das machte beide trotzdem nicht wirklich brauchbar. Damals waren der proprietäre Nvidia Treiber und Intel das Maß der Dinge in Linux mit Lichtjahren Abstand.

Also irgendwo Hut ab für dein Durchhaltevermögen in der Zeit, aber da dürftest du der einzige gewesen sein, der sich wegen der besseren Linux Unterstützung ATI Karten gekauft hat.

 

[mae]

nVidia ist unter Linux das ungeliebte Kind. Da gehören beiden Seiten mal ordentlich gerüffelt.

Nvidia unterstuetzt freie Software wie Linux nicht (naja, soll sich aendern), AMD und Intel seit langem. Welche Seite ausser Nvidia willst Du dafuer rueffeln und aus welchem Grund?

Xorg lief eine Dekade lang auch kaum besser als WinXP. Das sollte man nicht vergessen.

Was willst Du uns damit sagen? Windows XP lief nicht auf Linux, Xorg schon.

nVidia könnte auch nicht mal so eben einfach FOSS gehen. Wie sollte man dann CUDA "schützen"?

Was hat CUDA mit Grafiktreibern zu tun? Nvidia will einfach keine freien Grafiktreiber herausbringen, weil sie offenbar zu wenig Markt im Linux-Desktop sehen, und weil es genug Leute gibt, die sich mit dem proprietaeren Treiber zufriedengeben und beim naechsten mal wieder zu Nvidia greifen.

Ein bisschen hat das GPGPU-Thema (AI, Supercomputing), wo auch CUDA dazugehoert, schon damit zu tun, zumindest habe ich das so gelesen: Da der Linux-Marktanteil bei den GPGPU-Systemen viel hoeher ist als auf dem Desktop, sah sich Nvidia doch dazu gezwungen, Linux besser zu unterstuetzen, und dazu zaehlt auch das, was jetzt als freier Grafiktreiber laeuft: Ein relativ duennes freies Interface zu einem riesigen proprietaeten Blob, der auf der GPU laeuft; immerhin waere das Problem mit unterschiedlichen CPU-Architekturen damit geloest. Und AMD und m.W. auch Intel haben leider auch proprietaere Blobs.

 

[Fonce]

Mehr noch, bevor AMD den Treiber umgeschrieben hat, zu dem, was man heutzutage unter Windows als Adrenalin kennt, haben auch Linuxer alle zu GeForce gegriffen, sofern sie mehr wollten, als nur im Internet surfen, Musik hören und Office.

Die Windows Treiber von AMD hatten und haben nichts mit dem Open Source Linux Treiber zu tun.
Es sind zwei völlig unabhängig von einander arbeitende Teams.

 

[mae]

Erst die ganz späten fglrx Treiber machten gescheites Spielen von UT2003/4 überhaupt halbwegs möglich, das habe ich damals auch gespielt.

fglrx hatte ich nie, den gab's vermutlich auch anfangs nicht fuer AMD64 (und den proprietaren Nvidia-Treiber wohl auch nicht).
Mit dem freien Treiber lief UT2004, allerdings nicht besonders gut: gelegentliche Grafikfehler waren zu verschmerzen, bei irgendeinem Level waren die Grafikfehler aber so heftig, dass er unspielbar war, und da habe ich dann UT2004 auf dem proprietaeren Spielebetriebssystem weitergespielt. Also soviel Durchhaltevermoegen war da nicht da:-). Andererseits: proprietaeres Spiel auf dem proprietaeren OS, das passt schon. Tux Racer lief jedenfalls problemlos.

Aber da sprechen wir von späten Zeiten der HD5870, die auch noch aus dem Hause ATI kam. Erst danach kam die Übernahme.

Die Uebernahme erfolgte am 25.10.2006, die Radeon 58x0 wurde am 23.9.2009 herausgebracht. Du denkst vielleicht an das Branding: AMD hat die Grafikkarten zuerst weiter unter der Marke ATI verkauft, am 30.8.2010 wurde dann angekuendigt, dass sie die Grafikkarten kuenftig unter der Marke AMD verkaufen wuerden.

 

[Grimba]

Stimmt, das hatte ich vergessen mit dem Weiterführen des Markennamens. Mein Fehler. Beide Treiber gab’s natürlich für AMD64. Ab wann weiß ich nicht mehr genau, glaube aber nicht, dass es da signifikante Verzögerungen gab.

 

[Zyv]

Wer Debian 13 als Desktop installiert, hat die Kontrolle über seine Betriebssystemauswahl verloren.
Debian gehört ohne Desktop auf den Server. Wer einen Desktop will, greift zu Fedora - dafür wurde es entwickelt.

Wer vom 12er upgraden will, findet hier eine Anleitung https://ostechnix.com/upgrade-to-debian-13-trixie-from-debian-12-bookworm/

Defacto der gleiche Vorgang wie von 11 auf 12, sofern man schon 64bit only nutzt.
Je jungfräulicher das Debian ist, desto weniger Probleme sind nach dem Upgrade zu erwarten.
Backup nicht vergessen.

Ergänzung (10. August 2025)

Die Sache bei Ubuntu: Sie freezen irgendeinen alten Stand und gewähren darauf LTS (long term support). Bei Debian ist jede stabile Hauptversion ein "LTS" und die Entwickler arbeiten immer auf dieses Ziel hin. Sprich es gibt kein Debian 13.1 LTS.

würde ich so nicht unterschreiben.
Wenn ich nicht zocken würde, hätte ich sicher nicht Fedora am laufen, sondern safe Debian.
Versteh mich nicht falsch, Fedora ist echt super nice, aber ich hatte tatsächlich auch schon ein Thema mit hard system freezes welche einem Kernel update zuzuschreiben waren. Kein riesen Thema, denn Fedora behält ja immer die letzten beiden Kernels, aber Debian ist daeinfach nochmal eine ganze Nummer zuverlässiger.

Für ein aktuelles Zock-System + daily driver, ist Fedora aber sicher mit das Beste was es in der Linux Welt gibt.

 

[floTTes]

Ja, es kann helfen, auf eine Distribution zu setzen, die Extrawuerste fuer Nvidia braet (Ubuntu vielleicht).

Welche Seite ausser Nvidia willst Du dafuer rueffeln und aus welchem Grund?

Merkst'e selba, ne?

Der Support-Aufwand ist lächerlich gering. Allerdings finden sich kaum Maintainer, denn nVidia ist ja teuflisch evil.

Was willst Du uns damit sagen? Windows XP lief nicht auf Linux, Xorg schon.

WinXP Schrott, Xorg Schrott, Wayland Schrott, Windows 11 Schrott.
Überall gibt's schlechte Software, auch ohne nVidia.

Was hat CUDA mit Grafiktreibern zu tun? Nvidia will einfach keine freien Grafiktreiber herausbringen, weil sie offenbar zu wenig Markt im Linux-Desktop sehen, und weil es genug Leute gibt, die sich mit dem proprietaeren Treiber zufriedengeben und beim naechsten mal wieder zu Nvidia greifen.

CUDA ist das Zugpferd von nVidia. Keine Sau interessiert sich für Gamer - zu Recht. Mit denen kann man nichts mehr verdienen. Gamer sind der "Apfelmus" der Apfelsaftproduktion.
CUDA könnte problemlos auf AMD- oder Intel-Hardware laufen.

Wie solltest du nun also CUDA "schützen" können, wenn der Großteil deines GPU-Codes in Kernel und Mesa stecken? Das wäre quasi ein Freifahrtschein für eine freie CUDA-Alternative. nVidia wird sicher nicht so dumm sein.

FOSS sollte man für Consumer auch nicht überbewerten. Selbst hier in einem IT-Forum haben doch bisher die Wenigsten mal in den Quell-Code von Mesa geschaut.

Es ist Aufgabe der Entwickler "Brücken" zu bauen, nicht Aufgabe der Konsumenten. Diese "Brücken" werden aber nicht nur von nVidia eingerissen. Frag mal Linus.

Allerdings hatte Linus mit nvidia-kernel-dkms-open Recht. Diese Farce kann man sich sparen.

Der Wayland-OpenGL-ES-Mist wurde noch ganz alleine ohne nVidia "designed". Da hat man sich für dein einfachen/kurzen Weg entschieden. Meisterleistung!

 

[Grimba]

Wie solltest du nun also CUDA "schützen" können, wenn der Großteil deines GPU-Codes in Kernel und Mesa stecken?

Ein GPU Treiber in Linux ist derzeit ja grob ein Dreiklang aus Kernelmodul, Userspace Treiber und Firmware. Der Firmwarepart darf auch bei einem ansonsten offenen Treiberstack proprietär sein, und ist es afaik nach wie vor auch bei intel und AMD. Das ist ja das Zugeständnis in Linux an die Hersteller. Ich bin jetzt nicht technisch tief genug drin, um das wirklich bewerten zu können, aber ich denke hier wäre mehr möglich, als Nvidia derzeit nutzt, so dass man ggf. endlich den User Space Treiber öffnen könnte, der ja derzeit das Zünglein an der Waage ist. Im Falle von CUDA könnte man z.B. sowas machen, wie eine Signatur der Firmware seitens Nvidia zu überprüfen, und ohne erfolgreiche Prüfung den Dienst verweigern. Aber das ist jetzt auch nur eine schnelle Idee meinerseits.

 

[Fonce]

FOSS sollte man für Consumer auch nicht überbewerten. Selbst hier in einem IT-Forum haben doch bisher die Wenigsten mal in den Quell-Code von Mesa geschaut.

Es geht weniger darum das hier jemand in den Code gucken kann, sondern darum das die diejenigen darin gucken können und Fehler fixen können die davon Ahnung haben.
Ohne FOSS hätte Linux bei weitem nicht die Hardware Unterstützt und Sachen wie Proton wäre ohne FOSS auch nicht möglich.

 

[metoer]

Wie solltest du nun also CUDA "schützen" können, wenn der Großteil deines GPU-Codes in Kernel und Mesa stecken? Das wäre quasi ein Freifahrtschein für eine freie CUDA-Alternative. nVidia wird sicher nicht so dumm sein.

Bei AMD ist der Grafiktreiber für 3D-Anwendungen und ROCm für Machine-Learning/AI auch getrennt, warum sollte das Nvidia mit CUDA nicht auch können?

Bei AMD ist halt beides open source, Nvidia könnte den CUDA Teil proprietär lassen.

 

[flaphoschi]

"profitieren insbesondere AMD-GPUs von den Neuerungen"

Deswegen werden NV User Linux meiden wie der Teufel das Weihwasser ...

Deswegen meiden Linuxanwender die Hardware von Nvidia. Wie der Teufel das Weihwasser.

Nvidia ist an allem selbst schuld. Nicht nur im PC-Bereich meiden alle Nvidia, die Kenntnis von der Fachlichkeit (Verweigerung von Wayland, quellgeschlossene Treiber über 14 Jahre im Alleingang, jetzt quelloffene Treiber die sie nicht mergen wollen, Fehler mit KMS/Suspend/VT-Switching…) haben.

Die ganze Branche meidet Nvidia (Microsoft, Sony, Valve). Bezeichnend, dass sogar Microsoft einen Bogen um Nvidia macht. Quellgeschlossen, Vendor Lock-in und proprietäre Lösungen. Auf dem Papier passen sie gut zusammen? Aber Microsoft weiß auch, wenn sie selbst in einen Vendor Lock-in geraten (Upsampling, RT und spezielle Cuda) sind sie arm dran. Aus so einem Würgegriff kommt man nicht mehr ohne Hilfe heraus.

Nvidia hat sich überhaupt mal ein bisschen bewegt, weil einige Rechenzentren wissen, dass KI-Beschleuniger ein Fass ohne Boden sind, wenn sie auf proprietäre Treiber angewiesen sind. Aber was nützt einem das, wenn der Quellcode vom Hersteller bewusst nicht in Linux und Mesa gemerged wird. Also Gefrickel, wieder warten bis das mit Upstream funktioniert oder ewig bei alten Systemen bleiben.


AMD: Verlässlich.
Nvidia: Beim synthetische Benchmark zum Release 20% schneller.

Da ist die Entscheidung klar. Immer AMD. Deren Trackrecord sagt seit 15 Jahren “wir unterstützen Linux voll und ganz”.

 

[1776]

Wer vom 12er upgraden will, findet hier eine Anleitung https://ostechnix.com/upgrade-to-debian-13-trixie-from-debian-12-bookworm/

Tbh finde ich die Anleitung ziemlich gemeingefaehrlich.

apt purge '~o'​

apt purge '~c'​

Gleich als eines der ersten Kommandos, noch vor dem ziehen der Backups von z.b. /etc?

Generell wuerde er bei mir 811 Pakete entfernen ...
Das hier duerfte mir ziemlich sicher das System zerschiessen. Weil ohne die Firmware wuerde das amdgpu modul erstmal das System freezen beim hochfahren. Und wer weiss ob die Netzwerkkarte/Wifi Karte ohne die Firmwares ueberhaupt noch funktionieren?

# apt list '~o'|egrep 'microcode|firmware'​

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.​

amd64-microcode/now 3.20220411.1 amd64 [installed,local]​

firmware-amd-graphics/now 20221109-4 all [installed,local]​

firmware-linux-nonfree/now 20221109-4 all [installed,local]​

firmware-misc-nonfree/now 20221109-4 all [installed,local]​

firmware-realtek/now 20221109-4 all [installed,local]​

intel-microcode/now 3.20221108.1 amd64 [installed,local]​

​

Ich ziehe mein Debian seit 6 jedesmal ohne diese beiden Befehle hoch. Niemals ein Problem gewesen.
Also wuerde ich doppelt und dreimal ueberlegen, bevor man solche Pakete einfach entfernt. Ohne sich ueber jedes Einzelne Gedanken zu machen.

 

[mae]

Der Support-Aufwand ist lächerlich gering. Allerdings finden sich kaum Maintainer, denn nVidia ist ja teuflisch evil.

Warum findest Du Dich nicht dafuer, wenn das tatsaechlich so wenig Support-Aufwand ist, wie Du behauptest?

WinXP Schrott, Xorg Schrott, Wayland Schrott, Windows 11 Schrott.

Kann mich nicht beschweren, bei Windows 11 allerdings mangels Erfahrung.

Wie solltest du nun also CUDA "schützen" können, wenn der Großteil deines GPU-Codes in Kernel und Mesa stecken? Das wäre quasi ein Freifahrtschein für eine freie CUDA-Alternative. nVidia wird sicher nicht so dumm sein.

Die freie CUDA-Alternative gibt's ja schon. Was sie nicht wollen, ist CUDA-Support fuer AMD und Intel. Mit GPU-Code im Kernel oder in Mesa hat CUDA aber ueberhaupt nichts zu tun. CUDA ist ja zum Grossteil im User-Space, und da gibt's ueberhaupt keine Einschraenkungen fuer proprietaeren Code.

FOSS sollte man für Consumer auch nicht überbewerten. Selbst hier in einem IT-Forum haben doch bisher die Wenigsten mal in den Quell-Code von Mesa geschaut.

Ich habe auch nicht in den Quellcode des freien Radeon-Treibers geschaut, war diesbezueglich also ein reiner "Consumer". Trotzdem lief der auf dem iBook, und der proprietaere Nvidia-Treiber lief auf dem PowerBook nicht. Die Vorteile freier Software enden nicht damit, dass ich persoenlich mir den Code anschaue.

Es ist Aufgabe der Entwickler "Brücken" zu bauen

Sagt wer? Wenn niemand die Entwickler dafuer bezahlt, Extrawuerste fuer Nvidia zu braten, dann ist es auch nicht ihre Aufgabe, sondern bestenfalls ihr Hobby.

 

[Grimba]

Bezeichnend, dass sogar Microsoft einen Bogen um Nvidia macht.

Dein Ernst? Microsoft investiert viele Milliarden in den Ausbau von AI (alleine in Deutschland 3,3 Millarden), insbesondere Rechenzentren. Und womit werden die wohl bestückt, wenn nicht mit GPUs vom AI Platzhirsch schlechthin: Nvidia?! Auch die Azure ND GB200V6 Cloud läuft mit GB200 NVL72 GPUs. Weitere Ausbau von Blackwell Hardware in der Azure Cloud geplant. Das ist weniger Bogen machen, mehr umarmen. Worauf läuft wohl Copilot und ChatGPT?

 

[S_aus_B]

Für die ganzen 32bitter, es gibt noch Antix und einige andere Distros für eure Oldies.

Ich bin gespannt, was antix zukünftig macht.

 

[Grimba]

Deren Trackrecord sagt seit 15 Jahren “wir unterstützen Linux voll und ganz”.

Oh weia.... Vor 15 Jahren, also 2010, war die Unterstützung von ATI/AMD GPUs in Linux nicht gerade das Gelbe vom Ei. Amdgpu, der Treiber den heute alle so lieben, erschien erst 2015, angekündigt und mit ihm die neue offene Strategie von AMD wurde er 2014, und selbst ab da brauchte es noch Jahre, bis er in dem Zustand war, mit dem Nvidia Treiber gleichzuziehen bzw. in dem er heute ist. Vor 2015 von "voll und ganzer" Unterstützung zu sprechen, ist freundlich ausgedrückt mehr als gewagt um nicht zu sagen Kokolores. Selbst Valves erste Steam Machines setzten auf Nvidia (2014), da damals kein Weg an deren Performance für SteamOS vorbeiführte. Den Herstellern stand es damals aber schon frei zu wählen, entsprechend fiel die Wahl aus.

Vielleicht schnallst du mal deine rote AMD Kappe nicht ganz so eng am Kopf fest. Ich verstehe ja, dass man AMD heute sympathischer findet. Aber für solche Aussagen soviele einfach nachzuprüfende entgegenlautende Tatsachen einfach zu ignorieren, nützt deiner Argumentation kein bisschen. Es sollte doch gerade heutzutage jedem noch so eingefleischten AMD Fanboy maximal leicht fallen, AMDs Vorzüge in den Vordergrund zu stellen, ohne dabei Mist zu erzählen. Es geht quasi nicht einfacher als derzeit. Da sind solche Kapriolen doch einfach unnötig.

 

[BxBender]

25.2 flutscht gut, bei Callisto Protocoll habe ich ein paar FPS im Bench mehr, allerdings ist Windows gerade an den brenzligen Stellen doch ordentlich schneller, trotz neuer AMD Karte

 

[BrollyLSSJ]

Vielen Dank für die News. Proxmox 9 soll ja schon auf debian 13 aufbauen. Die Migration von 8 auf 9 soll aber durchaus Probleme verursacht haben, zumindest laut diverse Kommentare auf reddit.

 

[Maex84]

Ich bin sowohl von Nvidia, als auch von AMD kein Fan. Meine Sympathien gehen leicht Richtung AMD, da es der Underdog im GPU-Markt ist und Konkurrenz für Nvidia zwingend erforderlich ist.

Gleichzeitig bin ich sehr sicher, dass Nvidia in den nächsten Monaten massiv zu AMD in Linux Gaming aufholen wird. Ein Nvidia-Entwickler hat ja letzte Woche bestätigt, dass ihnen die schlechtere Leistung unter Linux bewusst ist und das sie bereits daran arbeiten.

Was ich bei AMD nicht verstehe ist, dass sie FSR 4 nicht stärker pushen. Es ist ein Witz, dass Tools wie Optiscaler schneller eine gute Upscaling-Lösung bieten als AMD selbst. Dagegen erweitert Nvidia stetig und kurzfristig seinen Katalog mit DLSS 4-Titeln. Wie gesagt, ich mag Nvidia nicht. Jedoch supporten sie ihre Produkte besser als AMD. Vielleicht sollte AMD die gleiche Strategie wie ihre CPU-Sparte fahren. Dort war der Support vorbildlich und hat dafür gesorgt, dass innerhalb weniger Jahre ein Monopol gebrochen wurde.