Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
BerichtLinux Jahresrückblick 2025: Der Pinguin ist auf dem Weg zum echten Gamer
Secure boot hilft gegen 2 sachen:
1. das die jemand mit physischen zugriff auf das system, die schlaphöte am flughafen, ein einbrecher oder deine putz kraft ein rootkit ins system einpflanzen
2. das ein virus welches das system bereizs übernommen hat sich mit einem rootkit noch tiefer ins system eingräbt so das du nach einem reboot es gar nciht mehr so einfach finden kannst.
Genen eine initialie infektion hilft Secure boot ausschlieslich nur in Szenarien in denen jemand dein PC physisch in seine Finger bekommt.
Und ich Dussel bin all die Jahre davon ausgegangen, dass --- wenn einer vor dem Rechner sitzt, der alles damit tun kann.
Wie zB ins Bios gehen und Secure boot ausschalten... ... und noch viel mehr. Also entweder ist Secure boot ein physischer Wächter der hinter dem Rechner sitzt, oder das alles bringt nix dann.
Bei einem Rootkit kanns helfen, aber sonst... fragwürdig für Privatanwender. Bei Unternehmen hats ja noch eine weitere Begründung, wie mir geflüstert wurde.
In Unternehmensumgebungen bietet Secure Boot eine zusätzliche Sicherheitsebene, die hilft, die Einhaltung von Sicherheitsstandards zu gewährleisten und das Risiko von Cyberangriffen zu reduzieren.
Weil ich kein gemeinnütziger Supportdienstleister bin.
Und ich denke es wäre unpassend in den faden dort zu schreiben schick mir 250€ und das Programm und ich untersuche das.
Na dann nimmt mal Wine/Proton raus und kein Hahn kräht mehr nach Linux. Nativ sieht es nämlich ziemlich Trübe aus und Wine/Proton haben Großen Anteil daran das Entwickler nichts für Linux machen.
Ganz ehrlich, mir ist das wumpe. Ich nehm's, wie's kommt und was besser funktioniert. Die Linux-Community und entsprechende Publisher haben Wine/Proton angenommen und dementsprechend verwende ich auch das. Wine/Proton und die anderen Projekte sind der Grund dafür, dass ich Linux auf meinem Gaming-PC mittlerweile den Vorzug gebe und Windows auf der zweiten SSD vor sich hinschimmelt, da es nur noch für HSR und Valorant und für etwas Magix Vegas verwendet wird.
Würde es Wine/Proton, GE-Proton, DXVK, VKD3D, Vulkan, Radv und die Fortschritte in diesen Projekten nicht geben, wäre ich wahrscheinlich weiterhin komplett auf Windows unterwegs und müsste Microsofts rote Pille schlucken.
Gäbe es diese Projekte nicht die sich die Arbeit teilen würden Software Entwickler noch weniger für Linux entwickeln, weil es noch weniger Nutzer von Linux gäbe und damit weniger Notwendigkeit besteht.
Die Performance für viele Anwendungen ist so nah an dem was Windows liefern würde , hier und da sogar besser, warum also darauf rumhacken dass es eine Übersetzungsschicht gibt?
Unterschiede schrumpfen mit jeder neuen Version. Ein großer Teil kann in den Gerätetreibern vorangetrieben werden und das passiert auch für das so verdammte NVIDIA.
Ich glaub das Argument ist sehr sehr schwach über die Zeit.
Ich mag da ja auch Falsch liegen, aber ließt sich halt nach nicht richtig unterstützter Hardware von A-Z und eben in der Hauptsache liegt es daran, die die Hersteller die du nutzt keinen oder zu schlechten Linux support bieten
Punkt 1 reines Treiberproblem
Punkt 2 Hört sich nach Nvidia Treiberkarfuffle an (ist besonders gerne mit gerade nicht der neuesten Generation Nvidia Karten)
Punkt 3 vermutlich auch auslösend durch ein Nvidia Treibermodul Problem.
Wenn man den Umstieg wirklich will hilft beim Hardware kauf selbst schon unter Windows auf Kompatibilität zu schauen.
Ich auch hier, mit KDE, Manjaro by the way
Man muss ja nem Meme treu bleiben.
Ichhabe nen Tiling Plugin aktiv, da konnte ich auf die schnelle nicht das Fenster verschieben über das andere, aber die Option und wie erreicht ist demonstriert :-) :
Edit@Grimba hier nochmal, hatte da irgendwie verpasst, das es um Spiele geht und da gebe ich dir recht unter KDE :-) da bleibt das Spielefenste im Vordergrund. Du hast im Grunde 2 Varianten um das zu umgehen. das Steam Overlay, wobei der Browser darin ein bissl eingeschränkt ist oder auch das Spiel im Fenstermodus natürlich, ggf. mit gamescope erzwungen.)
Anhang anzeigen 1692940
Und natürlich ist auch der Option ein Shortcut zuweißbar in den Systemeinstellungen, wenn man denn möchte.
Hm, sehe ich nicht so, wenn ich mir die Kerntakte mit scxtop anschaue, da ist immer wieder ein ganzer haufen der Kerne auf 0mhz
Und das der 3d cache nicht funktionieren soll halte ich für ein Gerücht, hast du da irgendwo Fakten dazu? Kein geschwurbel, Fakten bitte.
(Ein effekt könnte ich mir vorstellen, das wenn unter Linux ein code kompakter geschrieben ist und sowieso in den üblichen cache passt, hast du durch einen 3d cache an der Stelle keinen geschwindigkeitsvorteil natürlich. Also du musst zu beginn erstmal auch code haben, der einen Vorteil von dem Cache bekommen kann. Factorio dürfte da wohl berühmt sein, ich meine das ging steil mit x3d, solange es in den cache passt.
x3d ist keine mach alles cshneller magie, es ist ein riesen blob an cache.. mehr erstmal technisch nicht.
Wieviele wohl zur Playstation wechseln, wenn GTA VI erscheint?
(dein Text minimal angepasst zur besseren Lesbarkeit)
Wooting vollkompatibel und irre was die machbar machen.
Ich benutze auch sleep, welche Software ist das denn?
Nicht, das das nur wieder der nächste Nvidia Bug ist.
Cool, muss ich gleich mal testen :-) könnte aber auch Distro spezifisch sein, eben was die alles OOTB mitkompilieren.
Edit:
ist bei Manjaro wohl noch nicht angekommen, abe wie du schon schreibst hab ich mal -vo drm mit dran getestet und da Spielts im Terminal direkt ab :-) (das an sich geht ja schon länger)
Ja ich kriege wwniger FPS bei einem Game.unter Linux und die CPU ist dabei zu 28% ausgelastet und bei 77Grad, das gleiche Game mit den gleichen Einstellungen unter Windows läuft nicht nur besser, di3 Auslastung beträgt nur 19% und die CPU Temp 68 Grad, das sagt schon viel aus. Abhilfe schafft nur ein ganz exotischer Kernel, welcher die Last bei 3d-Vcache CPUs besser managed, da die meistens Distros aber fast immer einen Standard oder Gerenic-Kernel verwenden, ist dies in meinem Fall mit dieser CPU nicht optimal. Aber es ist ja von AMD ein neuer CPU Planer für den Ryzen 9 9950x3d unterwegs, mal schauen ob sich die lage dann bessert
Ergänzung ()
HiveTyrant schrieb:
Meiner Meinung nach gibt es hier und da noch ein paar Probleme.
Ich spiele auch mit dem Gedanken, habe auf meinem Notebook jetzt Bazzite installiert (Gaming, aber auf ein Fedora aufgesetzt, nicht ein komplett auf Gaming ausgelegtes Linux).
Von Haus aus fehlt z.B. Samba, was etwas nervig ist, da viele Drucker heutzutage über Netzwerk angesprochen werden können, aber auf Linux keine Treiber haben.
Den Scanner in meinem Drucker muss ich auch noch zum laufen bringen.
Mein NAS konnte ich auch erst einbinden, als ich SMB nachinstalliert hatte.
Scanner und eventuell noch einmal schauen, ob die Webcam (normalerweise physisch verdeckt) funktioniert. Die meisten meiner Spiele sollten nominell funktionieren, ein einfaches CAD sowie Office Paket läuft auch.
Warum Bazzite und nicht einfach SteamOS? Bazzite bietet alle Integrationen und ist nicht nur auf Steam eingeschossen. Wenn ich ein Spiel AUSSERHALB von Steam kaufe, hat das normalerweise einen Grund - nämlich, das ich auch wenn Steam mal wieder überlastet und am verrecken ist, noch irgendetwas habe.
Dazu auch noch Waydroid on Top. Sprich, ich will eben nicht 'Füg es als Nicht-Steam Spiel in Steam hinzu, weil Proton und so'.
Alles in allem muss die Hardware-Unterstützung noch besser werden.
Bei mir läuft der Drucker sowie Samba ohne Murks auf Linux.....HP und Brother haben sogar offizielle Linux Treiber und mein Synology NAS Samba wird auch vollumfänglich out of the Box unterstützt
Eins, bei mehr nicht? Das riecht vielmehr nach einem Bug als nach einem X3D Problem. Deine Infos sind noch etwas dürftig. Und das ist noch zurückhaltend ausgedrückt.
Übrigends ich mit meinem X3D habe eigentlich immer die beten Ergebnisse mit dem ganz normalen Standard Linux Kernel, Linux Mainline, bzw eben dem 0815 der Distro ausgelieferten.
Edit:
Hab übrigends genau den Selben (9950 X3D)
Das ist aber in Linux Debatten wie diesen gerne so, man hat ein Problem was einem Linux vermiest , gibt aber nicht genug Details an um das Problem entweder direkt lösen zu können oder wenigstens analysieren zu können damit ein ordentlicher Bugreport an der Richtigen Stelle für eine Lösung in Zukunft sorgen kann.
Das macht mich kirre. Genau wie die Fälle wo man den Verdacht hat dass die Person irgendwo vor 10 Jahren mal was ausprobiert hat was inzwischen ganz anders sein kann.
Eins, bei mehr nicht? Das riecht vielmehr nach einem Bug als nach einem X3D Problem. Deine Infos sind noch etwas dürftig. Und das ist noch zurückhaltend ausgedrückt.
Übrigends ich mit meinem X3D habe eigentlich immer die beten Ergebnisse mit dem ganz normalen Standard Linux Kernel, Linux Mainline, bzw eben dem 0815 der Distro ausgelieferten.
Edit:
Hab übrigends genau den Selben (9950 X3D)
Gut möglich dass dieses Game es nicht korrekt managed , konnte bisher nicht alle Games testen, mag sein dass der Nvidia Treiber noch dieses Problem verstärkt nur nicht nur die CPU, aber was ich bemerkt habe, wenn ich einen Kernel mit BMQ nehme, läuft es genau so gut wie in Windows und deutlich flüssiger und kühler. Die Temperaturen sind dann auch in Ordnung. Da es mein Lieblingsgame zur Zeit ist, bleibt mir nichts anderes übrig als auf Arch Distros zu zocken oder auf Windows...
Ach ich dachte du hast die Radeon benutzt... steht ja in deiner Signatur. Dir ist aber bekannt, das der Nvidia Treiber bekannt ist unter Linux auch mal locker einfach 30% weniger fps als unter Windows zu machen? Je nach SPiel/Api bla bla...
Das passiert wohl leider. Zumindest in den Fällen, über die ich in den letzten 15 Jahren gestolpert bin, waren es am Ende entweder Projekte, die nicht versucht haben aktuell zu bleiben. Also über Jahre hinweg als "deprecated" markierte APIs verwendet haben. Oder welche, die wiederum andere, nicht mehr gepflegte Libs verwendet haben und sei es nur weil da eine tolle Funktion etwas Arbeit abgenommen hat.
Am Ende sollte man als Maintainer zumindest versuchen mit dem Kernel / libc oder den gewählten Frameworks / Bibliotheken Schritt zu halten und die eigenen Abhängigkeiten auf das technisch notwendige zu beschränken. Und da bin ich voll bei dir, das ist für Windows deutlich einfacher zu machen - auch aus Entwicklersicht, weil man bei Windows eine recht stabile "Kern-API" bzw. SDKs zur Verfügung hat. Hier hilft der Wildwuchs bei Linux genau gar nicht :-/.
Nicht mit der Pro Lizenz.
Für Windows muss ich aber nach einer Neuinstallation gut 15min investieren bis es so läuft und ausschlaut wie es muss. Teilweise schwere Eingriffe nötig. Bei Linux ist es eig. Je etwas Optik und 2-3 kleine Settings.
Das lustige ist nur, das Microsoft selbst ein Windows 11 ohne alles anbietet aber nur für Firmen und besondere Lizenz.
Praktisch komplett nackt
Wie sicher ist man denn auf diesen Arch basierten Distros vor Fehlern in der Qualitätssicherung?
Wird da ausgiebig geprüft bevor man ne neue Version veröffentlicht eines Pakets oder fällt man da öfter auf die Nase?
Arch Linux und darauf basierende Distros haben neben den Main-Repos (core, extra und multilib) auch noch Testing-Repos für diese drei, die aber per Default nicht aktiviert sind. Bei Arch Linux landen also neue Paketversionen auch erstmal im Testing, bevor diese dann an die Main-Repos weitergereicht werden. Neue Kernel-Releases, insbes. neue Major-Releases vom Kernel, bleiben auch schonmal zwei bis vier Wochen im Testing, bis diese dann ins core-Repo wandern.
Wie ausgiebig da jedoch geprüft wird, kann ich nicht sagen; ich kann dir nur mal auflisten, dass ich auf meinem EndeavourOS, das ich seit September 2024 einsetze, seitdem fünfmal Probleme bei Updates hatte:
November 2024 stand ein neues Update für Pacman selber bereit, es konnte sich aber nicht updaten, weil ich noch Pamac (grafische Anwendungsverwaltung, die man von Manjaro kennt) installiert hatte. Es gab da eine Abhängigkeitsverletzung, weil libpamac (Pamac Library) libalpm braucht und dieses Teil von Pacman ist. Nach der Deinstallation von Pamac lief das Update von Pacman sauber durch. Danach konnte ich Pamac dann wieder installieren. Vor kurzem trat dieser Fehler ein zweites Mal auf, Lösung mit dem selben Vorgehen.
Juni 2025 wurde das linux-firmware-Paket aufgesplittet in mehrere einzelne Pakete für die Firmwares von AMD, nVidia, Intel, Mediatek und weitere, die allerdings von linux-firmware abhängen, also mitinstalliert/geupdatet werden, wenn linux-firmware geupdatet wird. Grund war wohl, dass die nVidia-Firmware immer größer wurde und man den Split deswegen vollzogen hat. Das Update bzw. die Installation von linux-firmware-nvidia lief auf Fehler, da das Paket Verzeichnisse anlegen wollte, die aber schon existiert hatten. Die Fehlermeldung von Pacman enthielt auch direkt die Bezeichnung der problematischen Verzeichnisse. Die Lösung war das manuelle Löschen dieser Verzeichnisse, dann lief das Update auch sauber durch (ich hatte linux-firmware nicht komplett deinstalliert, wie es im Arch Linux-Blog beschrieben ist). Mittlerweile lasse ich das nVidia-Firmware-Paket immer löschen, da ich keine nVidia-GPU habe.
Ebenfalls Juni 2025 gab es Probleme mit einer neuen Version von linux-firmware-amdgpu, die nach einem Reboot in Verbindung mit RDNA 4-GPUs nur noch Blackscreens hevorbrachte. Bei mir wurde im grafischen Modus der Login-Manager SDDM schon nicht mehr angezeigt und im Terminalmodus wurden lediglich die Kernel- und systemd-Meldungen beim Boot angezeigt und dann war Sense, da der Login-Prompt nicht angezeigt wurde. Die Lösung bei mir war, mittels BtrFS Snapper Snapshot einen früheren Zustand des Systems (vor dem Update) zu laden, diesen Zustand als Hauptumgebung zu setzen, dann erneut das Update anzustoßen und direkt nach Fertigstellung dann das Downgrade auf die vorherige Version von linux-firmware-amdgpu zu machen. Der anschließende Reboot ging dann ohne Probleme. Der Fehler wurde aber schnell mit einem neuen Update gefixed, ich glaube, nach zwei oder drei Tagen war der Bugfix draußen.
November 2025 hat die Kernel-Version 6.17.8 gebracht und mir in den Kernel-Meldungen beim Booten die Meldung "RDSEED32 is broken" oder so ähnlich beschehrt. Liegt wohl daran, dass bei meinem Ryzen 7 9800X3D die Zufallszahlen über den Zufallsgenerator via RDSEED32 nicht so ganz zufällig sind, wie sie es eigentlich sein sollten, weswegen das entsprechende CPU-Bit mit der neuen Kernel-Version offenbar deaktiviert wurde. RDSEED64 ist davon nicht betroffen. Jedenfalls führte das Kernel-Update bei mir aber vermehrt zu Kernel Panics, die ich bis zu diesem Zeitpunkt nicht mit irgendwas in Verbindung bringen konnte, wobei die Laufzeit auch sehr unterschiedlich war, wann der Panic überhaupt aufgetreten ist. Den beschriebenen Grund weshalb das so ist, hatte ich bei der Recherche dann auf Reddit gefunden. Ich hatte dann den Kernel zurück auf 6.17.7 gerollt, womit die Kernel Panics (und die Kernel-Meldung mit RDSEED32) dann wieder weg waren. Ich hatte mit dem weiteren Update dann gewartet bis Kernel 6.18.1 draußen war, damit ich neben den anderen Paketen auch gleich auf den 6.18er wechseln konnte. Der AMD-CPU-Mikrocode wurde auch geupdatet, ob es aber jetzt am 6.18er Kernel oder am neuen Mikrocode lag, was das behoben hat, weiß ich nicht; jedenfalls treten seit diesem Update auch weiterhin keine Kernel Panics mehr auf. Ein UEFI-Update mit entsprechend neuer AGESA-Version hatte bisher nicht gemacht.
[EDIT] Auf meiner alten Intel-Mühle mit einer Radeon RX 580 hat MangoHud irgendwann die Texturen in sämtlichen Spielen, die Vulkan verwenden, kaputtgemacht. Wenn ich MangoHud nicht verwende, dann sind die Texturen völlig in Ordnung. Woran das konkret liegt, konnte ich bis heute nicht herausfinden. Auf meinem neuen AMD-System mit einer Radeon RX 9070 XT tritt dieser Fehler nicht auf.[/EDIT]
Das sind die bisher einzigen Probleme, die ich direkt mit dem Updaten von Paketen auf EOS/Arch Linux hatte. Im Rest der Zeit lief alles glatt. Meine Erfahrung mit EOS bzw. Arch Linux ist insgesamt, dass es trotz dieser fünf Probleme bisher sehr stabil läuft.
Bei anderen Arch-based Distros wie Manjaro, das Pakete ja gerne noch länger im Testing belässt oder CachyOS, das ja auch eigene Repos hat und in dessen Repos wesentlich mehr Pakete enthalten sind als im EndeavourOS-eigenen Repo, kann ich nicht sagen, wie das bei denen ist.
Bei anderen Arch-based Distros wie Manjaro, das Pakete ja gerne noch länger im Testing belässt oder CachyOS, das ja auch eigene Repos hat und in dessen Repos wesentlich mehr Pakete enthalten sind als im EndeavourOS-eigenen Repo, kann ich nicht sagen, wie das bei denen ist.
Im Gegensatz zu Manjaro ist CachyOS (genauso wie EndeavourOS) einfach Arch mit ein paar extra Repositories, aus denen sie ihren eigenen Kram beziehen. Zusätzlich werden bei CachyOS in eigenen Repositories viele Arch Pakete als Rebuild mit höhereren x86_64 Architekturen vorgehalten, welche aber zu Arch kompatibel/konsistent bleiben müssen. Dementsprechend unterscheidet sich die Testing-Zeit zu Arch nicht wirklich. Für die eigenen Repos sind sie halt dann selbst verantwortlich, da Schritt zu halten. weil Arch wartet ja nicht auf sie, entsprechend eng ist das Testing Fenster auch hier.
Manjaro hingegen liefert ALLE Pakete selbst. Grob waren das, als ich zuletzt geguckt habe, so 2 Wochen Unterschied zu Arch selbst mit wenigen Ausnahmen, wie z.B. Browsern. Das ermöglicht ihnen natürlich vollumfängliche Hoheit über die gesamte Distribution, aber gibt ihnen natürlich auch volle Verantwortung darüber. Technisch gesehen ist das dann eigentlich nicht mehr Arch, sondern eher grob ähnlich wie bei Ubuntu und Debian von der Verwandtschaft her (Release Zyklen hier außer acht gelassen). Aber im Prinzip heißt dass dann auch zumindest potenziell mehr Zeit für Testing. Ob das wirklich was ausmacht ist umstritten, wie immer.
Heutzutage hat doch jedes Smartphone ein high res display, dazu mindestens 8gb manche sogar 16gb ram und die cpu und gpu haben auch schon genug power. Das läuft auf Android und basiert ja auf Linux.
Na und? Es geht hier ausschliesslich um 0815 User die Ihr System Plig and Play mässig benutzen wollen und nicht noch Terminalkommandos zu erlernen. Alle anderen Technikaffinen haben damit keon Problem. Auch Leute die nur eine GUI benutzen wollen, qas zu 1000% legitim und okay ist. Schlimmer finde ich die Personen welche das mot dem GUI und Klickibunti immer wieder so herablassend suggestieren müssen, das zeugt einfach von einem schlechten Charakter und sehr schlechter Erziehung. Eigentlich haben oder hätten genau solche Leute in so einer Community gar nichts verloren.
Ich sehe es nicht so trennscharf.
Es gibt unter Windows die Powershell dir so mächtig ist das Firmen sie abdrehen um es Malware schwerer zu machen.
Unter Linux benutze ich sie nur um schneller Software aus verschiedenen Quellen auf einmal zu aktualisieren weil mir die grafische Oberfläche nicht gefällt. Auch gerne mal um Fehler direkt zu sehen live anstatt hinterher Protokolldateien suchen zu müssen.
Wirklich brauchen tu ich sie aber bisher nicht.
Ich sehe nur einen Fall, ist aber auch eher exotisch, wo mir eine mächtigere GUI noch fehlt: TortoiseGIT im Windows Explorer hat kein Gegenstück unter Linux.
Die Integration im KDE Dateimanager Dolphin ist viel schwächer und erkennt grade nak dass es ein Git Verzeichnis ist. Keine Änderungshistorie, keine Verwaltung, nada.
