News Linux-News der Woche: Erste RDNA-4-Benchmarks unter Linux

Wenn PPAs so Probleme machen, was habe ich für Alternative unter Linux Mint? Ich brauche den neusten Treiber für Split Fraktion. Aber der PPA 570 zeigt mir nichtmal das Steam Overlay an.
 
Caramon2 schrieb:
Wieso? Für Windows lädt man die Treiber doch auch am besten beim Hersteller.

PPAs sind ziemlich fragwürdig, da einem dort alles untergeschoben werden kann! - Anders als beim AUR kann man nicht mal kontrollieren, was wirklich installiert wird und woher die Sachen kommen.

Im entsprechenden Ubuntuusers-Wiki wird gleich dreimal davor gewarnt:
https://wiki.ubuntuusers.de/Paketquellen_freischalten/PPA/

Wer hirnlos PPAs hinzufügt, spielt quasi russisches Roulette.

Was man unter Windows macht, macht man unter Windows. Unter Linux läuft der Hase anders. wenn man mit Windows-Lösungsansätzen an Linux-Probleme rangeht, geht das selten gut.

PPAs sind erst mal nur eine Erweiterung der Paketquellen. Dabei muss man natürlich dem PPA-Maintainer vertrauen. Das muss man immer, wenn man sich Software herunterlädt. Vor allem unter Windows, wenn man sich sog. Schlangenöl-Tools von irgendwelchen shady Websites installiert.

wenn du schon den Vergleich mit dem AUR rausholst. Kleiner Reminder:
Vertrauen muss man — ACHTUNG — auch wenn man sich Zeugs aus dem AUR installiert. Das AUR ist ein User-Repository. Dort kann jeder Hans und Frans jeden erdenklichen Dreck hochladen. Eine Qualitätsprüfung findet nicht statt. Software aus dem AUR kann oft fehlerhaft sein und die Systemstabilität gefährden. Schlimmstenfalls kann das AUR auch Malware enthalten. Letzteres ist auch schon vorgekommen. PPAs machen normalerweise keine Probleme. wenn du Mint benutzt, benutzt du ohnehin ein PPA. Die Mint-Paketquellen sind nämlich auch nichts anderes.
 
  • Gefällt mir
Reaktionen: Nine-tailed Fox
Nine-tailed Fox schrieb:
Ja, das stimmt. Deshalb nutze ich den Treiber der mit der Distro kommt. Wenn dann auch veraltet/langsamer.
Ein richtiger Linuxprofi oder Programmierer kann das aber vermutlich besser abschaetzen und individell nutzen.
Mit der Argumentation würdest Du für mich Linux auf dem Desktop in das uninteressanteste Stück Softwaremüll verwandeln, welches es gibt und mich eher motivieren, mit so komischen Experimenten wie Tiny 11 mein Glück zu versuchen.

Klar muss man dem Maintainer eines PPAs Vertrauen entgegen schenken, das muss man aber auch mit jedem anderen Stück Software.

Bevor ich dem durchschnittlichen Anwender sage, jetzt setzt Du Dich nochmal auf die Schulbank und liest Dir erstmal alle Kapitel der Anleitung durch, damit hinterher Dein openSUSE Tumbleweed (welches immerhin rollt) oder Dein Arch läuft (welches auch rollt und immerhin kein Barebones-Bausatz aller LFS ist), sage ich doch, bleib bei Deinen Leisten und sichere Windows so für Dich ab, dass Du auch mit Zusatz-Software Ruhe vor Microsofts Schwachsinn hast.

Der Pluspunkt von Mint ist nun mal auch die einfache Installation von speziell GeForce-Treibern über die grafische Oberfläche, genau so etwas will ich fernab von Linux doch für den PC generell haben.

Wenn so etwas problematisch ist... ja dann bleibt entweder gar nichts an Soft- und Hardware ändern, womit man auch gleich zum Mac oder zur Konsole greifen kann.

Fürs Protokoll, ich verwende Linux seit Dezember 2004 auch neben Windows, aber solche Probleme, wie sie die Installation von Grafiktreibern verursachen kann, sind in meinen Augen universell überall gegeben und damit muss man im Zweifel rechnen.
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Nine-tailed Fox
Nine-tailed Fox schrieb:
Windows hat immer den gleichen Kernel. Der Linux Kernel kann je nach Distribution oder user anders sein, was dann zu Problemen bei Installation & Nutzung fuehren kann.
Der Treiber muss natürlich den Kernel kennen, damit er das passende Kernel-Modul generieren und einpflegen kann.

Gleich gilt z. B. auch für Virtualbox: Wenn die bei einer neuen Version schreiben, es unterstützt jetzt auch den Kernel 6.13, ist damit nicht gemeint, dass der in der VM laufen kann (da ist das vollkommen egal, da der emulierte Standard-PC sowieso von jeden geläufigen Kernel unterstützt wird), sondern der Kernel des Host-Systems: Wird der nicht unterstützt, kann vBox nicht das Kernel-Modul generieren und funktioniert nicht.

Nine-tailed Fox schrieb:
Ja, das stimmt. Deshalb nutze ich den Treiber der mit der Distro kommt. Wenn dann auch veraltet/langsamer.
Und da finde ich eben bei LMDE toll, dass man einfach mit dem genannten apt-Befehl alle installierten Pakete in einen Rutsch auf die Backport-Versionen umstellen kann und so von allen die jeweiligs aktuellsten vorhandenen Versionen bekommt - und behält, da die automatisch weiter als Backports aktualisiert werden: Offizielle Pakete von Debian!

Manche Leute warnen zwar, dass die weniger gut getestet sind, aber das ist DEBIAN! - Wenn die "weniger" testen, ist das vermutlich immer noch mehr, als andere Distributionen überhaupt testen…

Nine-tailed Fox schrieb:
Ein richtiger Linuxprofi oder Programmierer kann das aber vermutlich besser abschaetzen und individell nutzen.
Ich sehe mich als versierter Laie: Ich weiß genug, um erahnen zu können wie ungeheuer viel ich noch nicht weiß. ;)

Kontrapaganda schrieb:
Was man unter Windows macht, macht man unter Windows. Unter Linux läuft der Hase anders. wenn man mit Windows-Lösungsansätzen an Linux-Probleme rangeht, geht das selten gut.
In die Falle bin ich damals auch getappt: Zuerst wollte ich mir LinuxMint 17.1 auch so einrichten, wie ich es mir für Windows mit der Zeit erarbeitet habe und es sich bewährt hat, aber Linux hat mir das schnell "abgewöhnt". :) - Zu meinem Vorteil: Dadurch, dass ich mich auf die Vorgaben eingelassen und für mich übernommen habe, hatte ich sogar rel. schnell viel mehr Ordnung in meinen Daten und konmte gut ¼ ausmisten: Unnötiger Kram, der sich mit der Zeit angesammelt hat.

Das ändert aber nichts daran, dass der Hersteller am besten wissen sollte, wie seine Hardware funktioniert, so dass dessen Treiber sicherlich nicht die schlechteste Wahl ist, solange die betreffende Linux-Distribution nicht immer mehr ihr eigenes "Süppchen" kocht und sich nicht mehr an die Standards hält.

Kontrapaganda schrieb:
PPAs sind erst mal nur eine Erweiterung der Paketquellen. Dabei muss man natürlich dem PPA-Maintainer vertrauen. Das muss man immer, wenn man sich Software herunterlädt. Vor allem unter Windows, wenn man sich sog. Schlangenöl-Tools von irgendwelchen shady Websites installiert.
Das meinte ich mit hirnlose. ;)

Kontrapaganda schrieb:
wenn du schon den Vergleich mit dem AUR rausholst. Kleiner Reminder:
Vertrauen muss man — ACHTUNG — auch wenn man sich Zeugs aus dem AUR installiert. Das AUR ist ein User-Repository.Dort kann jeder Hans und Frans jeden erdenklichen Dreck hochladen. Eine Qualitätsprüfung findet nicht statt. Software aus dem AUR kann oft fehlerhaft sein und die Systemstabilität gefährden. Schlimmstenfalls kann das AUR auch Malware enthalten.
Genau das ist der Unterschied: Aus dem AUR bekommt man keine Software!

Aus dem AUR bekommen man nur eine Art Skript (mache vergleichen es mit Kochrezepte), nach dem der AUR-Helper sich alles benötigte zusammensuchen und lokal das zu installierende Paket erstellt.

Ich nutze "trizen" und das zeigt dieses Skript als ersten an. Es gibt sogar die Option es zu bearbeiten und man muss es erst bestätigen, bevor es abgearbeitet wird. - Das habe ich aber deaktiviert, damit schon mal die Sachen geladen und das Paket erstellt wird, während ich das Skript kontrolliere: Ohne mein Root-Passwort wird sowieso nichts installiert.

Die Kontrolle ist rel. einfach: Rel. weit oben gibt es "sources" (also von wo was geladen werden soll) und die kontrolliere ich auf Plausibilität: Jedes Mal!

Natürlich wenn ich was neues installiere, aber auch wenn etwas aktualisiert wird: Auch wenn es noch nie Probleme gab und die Kommentare und Bewertungen (beides kontrolliere ich, wenn ich etwas neues installieren will) alle gut sind, könnte der Ersteller ja z. B. gehackt worden sein: Shit happens.

Wobei die Quellen beliebig sein können: Für Opera wird das .deb direkt von Opera geladen und in ein pacman-Paket konvertieren, bei den Opera-ffmpeg-Codecs wird das gleiche mit dem entsprechenden Snap-Paket von afair Suse gemacht und für 7zip-full wird sogar der offizielle Quellcode geladen und lokal kompiliert (dauert auf meinem 4 GHz AMD FX-8350 ca. 3 Min.! Für ein so kleines Programm!).

Mehr beziehe ich nicht aus dem AUR.

Kontrapaganda schrieb:
PPAs machen normalerweise keine Probleme.
Genau das ist ja die Gefahr: Weil "nie" etwas passiert, wird man unvorsichtig.

Vor allem kontrolliert man das PPA vielleicht bevor man es integriert, aber dann kommen schön bequem die Updates zusammen mit denen aus den offiziellen Paketquellen und keiner denkt mehr daran, dass die PPAs permanent ein gewisses Gefahrenpotential haben.
 
Zuletzt bearbeitet: (Tippfehler)
  • Gefällt mir
Reaktionen: Tanzmusikus
@Randnotiz Ja, da stimmt ich dir schon zu. Ich wollte damit nicht sagen das man Maintainern nicht vertrauen kann, sondern vertrauen muss. Was mir persoenlich eher schwer faellt. Also generell.

Linux ist fuer mich vor allem der Wunsch nach Community. Und die Freiheit mein Betriebssystem nach meinen Wuenschen zu aendern. Fuer das ich nicht fuer jede Hardware nen Lizienzschluessel kaufen muss. Gerade wenn ich mir aus alten Teilen ein System baue, weiss ich das zu schaetzen. Auch die gigantische Auswahl an verschiedenen Distributionen ist fuer mich ein Plus fuer Linux.

Fuers Protokoll, ich empfehle nicht ausschliesslich Linux, sondern auch Windows wenn es fuer den jeweiligen User/usecase besser scheint. Aber ich selbst mag halt Linux.
Ergänzung ()

Caramon2 schrieb:
Offizielle Pakete von Debian!
Da du es gearde ansprichst. Wie ist es denn bei contrib und non-free?
Da weiss ich nicht ist das jetzt offiziell oder nicht. Werd da aus dem wiki nicht schlau.
 
Zuletzt bearbeitet von einem Moderator: (Ergaenzung & Korrektur)
  • Gefällt mir
Reaktionen: Randnotiz
Nine-tailed Fox schrieb:
Da du es gearde ansprichst. Wie ist es denn bei contrib und non-free?
Da weiss ich nicht ist das jetzt offiziell oder nicht. Werd da aus dem wiki nicht schlau.
Das sind originale Paketquellen von Debian.

Da ich das mangels bisherigen Interesse aber nicht genauer spezifizieren kann, habe die KI von Opera gefragt:


Ja, contrib und non-free sind offizielle Paketquellen von Debian, aber sie enthalten Software, die nicht vollständig den Debian Free Software Guidelines (DFSG) entspricht. Hier ist eine kurze Übersicht:
  1. main: Enthält nur freie Software, die den DFSG entspricht.
  2.  contrib: Beinhaltet Pakete, die zwar selbst frei sind, aber von nicht-freier Software abhängen.
  3. non-free: Enthält Pakete, die nicht den DFSG entsprechen, also proprietäre Software.


Scheint plausibel.
 
  • Gefällt mir
Reaktionen: Nine-tailed Fox und Tanzmusikus
@Caramon2
Danke das du dir die Mühe gemacht hast die KI zu fragen.
Ich hatte mich mit meiner Frage eigentlich auf deine Aussage offizielle Pakete, nicht offizielle Paketquellen bezogen.
 
Zuletzt bearbeitet von einem Moderator: (Korrektur)
Caramon2 schrieb:
  1. main: Enthält nur freie Software, die den DFSG entspricht.
  2.  contrib: Beinhaltet Pakete, die zwar selbst frei sind, aber von nicht-freier Software abhängen.
  3. non-free: Enthält Pakete, die nicht den DFSG entsprechen, also proprietäre Software.
Bis heute übrigens ersichtlicher als das, wie Canonical die Quellen benannt hat.
 
  • Gefällt mir
Reaktionen: Nine-tailed Fox
Kleinere Downloads sind echt ne Super Sache, an die ich noch garnicht gedacht hab, dass Entwickler so ne Option bringen könnten. Könnte man imho auch außerhalb des Steamdecks machen.
 
Da sind sie wieder.. die Linux News 🙂
 
  • Gefällt mir
Reaktionen: Kaito Kariheddo
  • Gefällt mir
Reaktionen: Nine-tailed Fox
Kaito Kariheddo schrieb:
Ich glaub von Nvidia gibts nur 570 für Linux, während Windows bei 572 ist.
Nicht glauben sondern wissen: https://www.nvidia.com/de-de/drivers/ ;)

Stimmt aber:

Windows: https://www.nvidia.com/de-de/drivers/details/242141/

Linux: https://www.nvidia.com/de-de/drivers/details/241089/

Btw:

Total krank, dass der Windows-Treiber inzwischen schon fast 1 GiB groß ist!

Aber auch der Linux-Treiber ist mit 376 MiB fast dreimal größer, als der gesamte Linux-Kernel, der u. a. alle unterstützen Treiber beinhaltet, inkl. "amdgpu": https://archlinux.org/packages/core/x86_64/linux/

Wie viel Müll packen die da rein?
 
Zuletzt bearbeitet: (hatte "fast" (1 GiB) vergessen)
  • Gefällt mir
Reaktionen: Tanzmusikus
Caramon2 schrieb:
Total krank, dass der Windows-Treiber inzwischen schon 1 GiB groß ist!
Dass das Treiberpacket für Windows so groß ist, liegt an dessen Inhalt. Das ist nämlich nicht nur der reine Grafikkarten-Treiber, sondern u.A. auch das Nvidia Control Panel, PhysX-Treiber, HDMI-Audiotreiber und die neue Nvidia App (vorher Geforce Experience. Gerade Letzeres haut bei der Größe ordentlich rein. Man lädt immer das Alles runter, auch wenn man am Ende lediglich eine "Driver Only" Installation macht.

Caramon2 schrieb:
Aber auch der Linux-Treiber ist mit 376 MiB fast dreimal größer, als der gesamte Linux-Kernel, der u. a. alle unterstützen Treiber beinhaltet, inkl. "amdgpu": https://archlinux.org/packages/core/x86_64/linux/
Nein, ist er nicht. Der reine Kerneltreiber ist unter Linux (zumindest bei Arch Linux) nur ~7 MB groß.
Bash:
[mibbio@haupt-pc ~]$ pacman -Si nvidia-open
Repositorium             : extra
Name                     : nvidia-open
Version                  : 570.124.04-3
Beschreibung             : NVIDIA open kernel modules
Architektur              : x86_64
URL                      : https://github.com/NVIDIA/open-gpu-kernel-modules
Lizenzen                 : MIT AND GPL-2.0-only
Gruppen                  : Nichts
Stellt bereit            : NVIDIA-MODULE
Hängt ab von             : linux  nvidia-utils=570.124.04  libglvnd
Optionale Abhängigkeiten : Nichts
In Konflikt mit          : nvidia
Ersetzt                  : Nichts
Größe des Downloads      : 7,09 MiB
Installationsgröße       : 7,12 MiB
Packer                   : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Erstellt am              : Fr 07 Mär 2025 21:44:43 CET
Verifiziert durch        : SHA-256-Summe  Signatur

In der Regel will man halt auch noch die Treiber für Vulkan, OpenGL und NVENC von Nvidia, welche bei Arch Linux in einem separaten Paket (nvidia-utils) stecken. Das ist dann tatsächlich recht groß mit ~270 MB Downloadgröße und ~790 MB Installationsgröße. Andere Distribution bündeln ggf. Alles in einem Paket, wodurch der Treiber dort dann entsprechend groß ist.
Bash:
[mibbio@haupt-pc ~]$ pacman -Si nvidia-utils
Repositorium             : extra
Name                     : nvidia-utils
Version                  : 570.124.04-1
Beschreibung             : NVIDIA drivers utilities
Architektur              : x86_64
URL                      : http://www.nvidia.com/
Lizenzen                 : custom
Gruppen                  : Nichts
Stellt bereit            : vulkan-driver  opengl-driver  nvidia-libgl
Hängt ab von             : libglvnd  egl-wayland  egl-gbm  egl-x11
Optionale Abhängigkeiten : nvidia-settings: configuration tool
                           xorg-server: Xorg support
                           xorg-server-devel: nvidia-xconfig
                           opencl-nvidia: OpenCL support
In Konflikt mit          : nvidia-libgl
Ersetzt                  : nvidia-libgl
Größe des Downloads      : 268,93 MiB
Installationsgröße       : 789,03 MiB
Packer                   : Peter Jung <ptr1337@archlinux.org>
Erstellt am              : Do 27 Feb 2025 18:14:43 CET
Verifiziert durch        : SHA-256-Summe  Signatur
 
  • Gefällt mir
Reaktionen: Caramon2
Caramon2 schrieb:
Ich nehme das mal als Aufhänger, um noch mal was zu der nvidia-Treiber-Sache zu sagen.
Mein Gefühl ist, da ist gerade viel Bewegung in der Thematik. Jahrelang hatte man ja nur den rein proprietären Treiber und dann noch nouveau, der zumindest grundlegende Funktionen abdeckte.

Dann kam nVidia auf die Idee zu sagen: Wir machen den Treiber Open-Source. Und da kann man natürlich sagen "Naja. Ganz nett. Aber so wirklich schick ist das alles ja noch nicht". Aber im Zuge dessen wurde auch eine Menge Doku veröffentlicht.
Und das alles hat, so mein Eindruck, auch wieder etwas mehr Schwung in die Open-Source-Treiber-Entwicklung gebracht.

So gibts mit NOVA einen ist Rust neu entwickelten Treiber (im Wesentlichen aus der Redhat Ecke). Der ist jetzt noch nicht so weit, ein Drop-in-Replacement für den Originaltreiber zu sein, aber es scheint sich was zu tun und möglicherweise haben wir schon in absehbarer Zeit für nvidia-Graphics die gleiche Situation die wir jetzt ja schon mit AMD-Graphics unter Linux haben. Das es halt schon ziemlich gut out-of-box funktioniert. Und zwar nicht auf Nouveau-Niveau (sorry für das Wortspiel :) ), wo denn schnell die Limits erreicht sind, sondern eher so: "Die meisten Sachen funktionieren völlig zufriedenstellend und nur wenn ich mehr Spezialdinge brauche, muss es dann tatsächlich von der Treiber von www.nivida.com/drivers sein".

Oder wie würdet ihr das sehen?
 
Nine-tailed Fox schrieb:
Da du es gearde ansprichst. Wie ist es denn bei contrib und non-free?
Da weiss ich nicht ist das jetzt offiziell oder nicht. Werd da aus dem wiki nicht schlau.
main, contrib, non-free und non-free-firmware sind alles offizielle von Debian herausgegebene Pakete, die den üblichen Debian Releaseprozess durchlaufen und sich hauptsächlich in der Lizenz unterscheiden.
Offizielle Beschreibung (ohne KI): https://www.debian.org/doc/debian-policy/ch-archive#archive-areas

Es gibt darüber hinaus noch ein paar "logische" Unterschiede wie Pakete supported werden, da das Security Team z.B. kaum Möglichkeiten hat, Patches in non-free Pakete zurückzuportieren.
Und auch der Extended Support (>= 5 Jahre) wird aufgrund des Aufwands meist auf main Pakete beschränkt.
 
  • Gefällt mir
Reaktionen: Tanzmusikus, Nine-tailed Fox und Caramon2
Caramon2 schrieb:
Wie viel Müll packen die da rein?
Alleine die Beschreibungen der Register, welche automatisiert aus den VHDL-Quellen der Chips erzeugt werden, braucht schon einiges an Platz:
Code:
~/Downloads/linux-6.14-rc6$ du -hs drivers/gpu/drm/amd/include/asic_reg
446M	drivers/gpu/drm/amd/include/asic_reg
~/Downloads/linux-6.14-rc6$ find drivers/gpu/drm/amd/include/asic_reg -type f -\! -name '*.h'
~/Downloads/linux-6.14-rc6$ find drivers/gpu/drm/amd/include/asic_reg -type f -name '*.h' | xargs wc -l | grep total
  4583107 total
~/Downloads/linux-6.14-rc6$
Das ist eben komplexe HW.
Ergänzung ()

andy_m4 schrieb:
Oder wie würdet ihr das sehen?
Welcher andere Hersteller von GPUs pisst sich wg. open source mittlerweile immer noch so wie NV ein?
 
  • Gefällt mir
Reaktionen: Caramon2
  • Gefällt mir
Reaktionen: Tanzmusikus
foofoobar schrieb:
Welcher andere Hersteller von GPUs pisst sich wg. open source mittlerweile immer noch so wie NV ein?
Eventuell Mediatek? Die sind zwar nicht direkt selber ein GPU.-Hersteller, sondern verwenden in ihren Mobile-SoCs die von Arm entwickelte "Mali" GPUs, aber sie rücken ihre Treiber dafür in der Regel nur an die Gerätehersteller raus. Das macht es oft schwierig, Custom-ROMs für Smartphone mit Mediatek-SoC anzubieten.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
dev/random schrieb:
main, contrib, non-free und non-free-firmware sind alles offizielle von Debian herausgegebene Pakete, die den üblichen Debian Releaseprozess durchlaufen und sich hauptsächlich in der Lizenz unterscheiden.
Offizielle Beschreibung (ohne KI): https://www.debian.org/doc/debian-policy/ch-archive#archive-areas
Danke fuer's Erklaeren. Ich versteh das so, dass die Pakete von Debian aus dem nicht freien sourcecode gebaut und dann offiziell veroeffentlicht werden. Wenn ich das richtig verstehe?
 
So ungefähr, die Regeln für contrib und non-free unterscheiden sich aber noch.

Pakete in contrib enthalten nur freie Software (also open source mit DFSG-kompatibler Lizenz), benötigen aber entweder nicht-freie Software zum erstellen (z.B. einen proprietären Compiler) oder bei der Ausführung. Ein Beispiel ist das ttf-mscorefonts-installer Paket, das die Microsoft Core Fonts installiert. Der Installer selber ist freie Software, lädt und installiert bei der Ausfûhrung aber Schriftarten deren Lizenz nicht DFSG-kompatibel ist.

In non-free ist dann auch nicht-freie Software in den Paketen enthalten, wie z. B. der nvidia-driver.

Aber alle diese Pakete erfüllen die Debian Policy und haben einen Debian Maintainer, der die Pakete baut und veröffentlicht und auch bug reports entgegen nimmt.
Edit: Links mit Maintainer Infos ergänzt.
 
  • Gefällt mir
Reaktionen: Nine-tailed Fox
Zurück
Oben