Bericht Linux-Gaming: Mit welcher Distribution laufen Windows-Games am besten?

Und Nvidia ist ein Punkt, an den ich in dem Moment definitiv nicht gedacht habe, obwohl mir diese Problematik sehr bewusst ist.
 
Die meisten Leuten hier im Forum werden das Debakel rund um Crowdstrike im Juli mitbekommen haben. Eine der Auswirkungen davon ist, dass Microsoft gewisse Dinge unter der Haube ändern möchte um ähnliche Ausfälle in Zukunft zu vermeiden. Unter anderem steht der Versuch im Raum, Sicherheitssoftware aus dem Kernel-Space zu "verdrängen".

Ich hätte das nicht weiter beachtet wenn ein Artikel auf Notebookcheck mich nicht auf einen interessanten Aspekt hingewiesen hätte:

According to the blog post, Microsoft and many of its security partners and vendors discussed several aspects of the future of security in Windows, but moving security features out of the kernel has some interesting implications for the future of gaming on Linux. Removing kernel-level security software would mean that anti-cheat software would all have to be implemented with user access, making it much less intrusive and far easier to emulate with translation layers, like WINE or Valve's Proton.

Das .. wäre tatsächlich ein gigantischer Schritt nach vorne für Gaming unter Linux.
 
  • Gefällt mir
Reaktionen: Poulton, Deinorius, Yar und 2 andere
Ich würde da keine vorschnellen Schlüsse ziehen. Das liest sich im ersten Moment zwar alles sehr gut, aber ich bleibe da skeptisch, bis ich es selber sehe. Es KANN sein, dass das auch das Ende für Kernel-Level Anti-Cheat ist und den Spielen damit Tür und Tor für Linux geöffnet wird, es KANN aber auch sein, dass die Publisher stattdessen auch Mechaniken implementieren werden, die das OS Environment prüfen und dann den Start verweigern, wenn die Prüfung eine Linux-Umgebung ergibt. Zutrauen würde ich es ihnen, genauso wie ich Microsoft zutrauen würde, dass sie den AC-Anbietern und Spiele-Publishern entsprechend "entgegenkommen".
 
Zuletzt bearbeitet:
Auch wenn du mit dem möglicherweise fragwürdigen Verhalten von Publishern leider richtig liegst, so wären das Maßnahmen die vergleichsweise leicht zu umgehen wären. Rechtliche Fragen jetzt mal aussen vor gelassen. Ich glaube, egal wie man es dreht und wendet ist es ein Schritt in eine richtige Richtung. Wie groß der Schritt dann tatsächlich ist wird sich erst zukünftig weisen.
 
Welchen Vorteil bietet es denn den Publishern, Windows only mit ihrem AntiCheat Programm zu fahren?
Die meisten AntiCheat Programme bieten doch aktuell auch die Möglichkeit Linux freizugeben.
Das es nachher bei den Spielen nicht passiert, ist ja eine Einstellungsgeschichte des Studios/Publishers.

Letztlich kann doch der Publisher froh sein, wenn die Kundengruppe um den kleinen Kreis der Linux Nutzer auch wächst.
Der einzige Nachteil, der damit verbunden wäre, wäre ein zusätzlicher Support Aufwand für Linux, nur dem kann man ja entgegenwirken, in dem man ganz klar kommuniziert, keinen Support für Linux zu bieten und auf die Systemanforderungen mit Windows zu verweisen.
Man lege halt Linux keine Steine in den Weg, will aber den Weg aufgrund von erhöhten Personalaufwand und Kosten nicht mit gehen.
 
SavageSkull schrieb:
Welchen Vorteil bietet es denn den Publishern, Windows only mit ihrem AntiCheat Programm zu fahren?
Weniger Wartungsaufwand, weniger Supportaufwand, geringeres Risiko für Missbrauch. Für eine Personengruppe, die ca. 5% der Spielerschaft ausmacht, würde ich das auch nicht machen und die Verantwortung übernehmen. Die Publisher sind Wirtschaftsunternehmen und agieren entsprechend.

Bitte nicht falsch verstehen: ich nutze kein Windows, sondern Linux auf meinen Rechnern (Server, Gamingkiste, "Konsole", ...). Ich persönlich würde ebenfalls davon profitieren - hmm - oder auch nicht. Wenn ich mir die Spiele anschaue, die ich nicht wegen dem Anti-Cheat-Programm spielen kann, dann kann ich sehr gute darauf verzichten ;)
 
Hier noch mal als Empfehlung, invasive clientseitige Anti-Cheats nicht zu supporten oder tolerieren. Auch wenn es im ersten Moment cool klingt, wenn ein Anti-Cheat auch unter Linux lauffähig ist. Yay, mehr Kompatibilität, mehr Popularität, und so. Ja. Aber die (nicht direkt sichtbaren) Kosten dafür sind hoch.

Das Ziel von so einem clientseitigen AntiCheat ist am Ende immer, dem Spiele-Prozess bzw. dessen "Kumpel", dem Anti-Cheat-Prozess, die Herrschaft über euren PC zu geben, damit die Anticheatkomponente maximale Rechte hat, eventuelle Cheat-Prozesse im Hintergrund zu erkennen. Dieses ganze Prinzip läuft sämtlichen Sicherheitsprinzipien komplett entgegen. Jeder nicht vertrauenswürdige Prozess auf eurem System (darunter zählt auch: jedes Spiel) sollte mit so geringen Rechten wie nur möglich laufen auf eurem System. Ich persönlich lasse Spiele nur in einer Sandbox laaufen und dazu werden auch noch viele der Verbindungen, die ein Spiel herstellen will nach irgendwo, geblockt. Noch dazu setze ich keine Spiele mit invasiven Anticheatkomponenten ein (wenn ein Spiel eine haben sollte, und bei mir mit den minimalen Rechten laufen würde, dann wäre es OK/tolerierbar. Wenn nicht, dann ignoriere ich dieses Spiel).
Noch dazu sind diese ganzen Anticheatkomponenten immer shady Software, so wie Spiele es oft auch selbst sind. Nichts davon ist auf "hohe Sicherheit" ausgelegt. Bei Spielen muss man ja heutzutage schon froh sein, wenn sie überhaupt Day 1 lauffähig sind ohne erst mal ein paar 50GB-Patches. Anti-Cheat-Hersteller werden sich auch nicht groß drum kümmern, ob deren Sachen sicher sind. Ich meine, es gab schon mehrere Fälle von Malware, die NUR deshalb funktionieren konnte, WEIL Anticheatkomponenten am Laufen waren im Hintergrund. Heißt, mit solchen Prozessen am Laufen seid ihr unsicherer unterwegs als ohne. Das betrifft insbesondere Windows-User.
Vielleicht ist es noch tolerierbar wenn ihr eine reine Gaming-Maschine habt auf der ihr literally nichts anderes macht außer gaming-bezogene Dinge, dann vielleicht. Aber das ist typischerweise ja nicht der Fall bei PC-Gamern. Die haben oft einen PC für alles. Und dann ist sowas im Hintergrund immer aktiv.

Noch dazu gebt ihr Microsoft und solchen Spieleherstellern quasi Munition in die Hand, euch wahllos auszusperren. Von Dingen die ihr rechtmäßig gekauft habt. Die eine Zeit lang noch liefen unter Linux und dann plötzlich nicht mehr. Das schadet auch dem Linux Gaming langfristig. Wenn solche Spiele populär sind, ist eine größere Abhängigkeit von diesen Tools und von einem physikalisch installierten Windows da, und das ist nicht gesund.

Es sind immer noch Spiele. Ihr solltet eure IT-Sicherheit nicht so leichtfertig aufgeben. Kein Spiel ist es wert, sein System zu trojanisieren, und dann auch noch nach ausgegebenem Geld mit dem Prinzip Hoffnung darauf zu hoffen, dass es noch so lange lauffähig ist, wie ihr das Spiel noch vorhabt zu spielen. Das funktioniert so auf lange Sicht nicht. Ihr werdet garantiert irgendwann ausgesperrt werden obwohl ihr keine Cheater seid. Und das zeigt dann auch, dass das ganze System der clientseitigen invasiven Anticheats wegen false positives und false negatives nicht funktioniert. Es wird auch trotzdem immer Cheater geben, da es immer Wege geben wird, clientseitig laufende Software auszutricksen. Cheaterkennung muss serverseitig laufen und darf clientseitig nur so weit gehen, wie es IT-sicherheitstechnisch noch OK ist.

Am besten gar keine solchen Spiele spielen. Egal ob sie (noch) unter Linux laufen oder nicht. Nicht supporten. Es gibt auch viele tolle Spiele ohne solche invasiven Komponenten.
 
  • Gefällt mir
Reaktionen: Yar, ropf, ma77es und eine weitere Person
Ergänzend zu meinem Beitrag #848 möchte ich ganz gerne mal noch eine Story mit euch teilen, wie ich es geschafft habe, dass nach ziemlich genau 30 Tagen - also Anfang Oktober - meine EndeavourOS-Installation kaputt ging. Witzigerweise nicht durch ein System-Update oder kaputte Abhängigkeiten, sondern durch meine eigene Dummheit. 😅

Ursprünglich hatte ich Timeshift für die Btrfs-Snapshots installiert. Da mir Timeshift aber zu spartanisch war und ich damit nicht wirklich warm wurde und das refind-btrfs-Skript für den mittlerweile installierten Bootmanager rEFInd nicht so recht funktionieren wollte und ich las, dass refind-btrfs mit Snapper besser funktionieren soll, löschte ich erst alle mit Timeshift erstellten Snapshots und deinstallierte dann Timeshift mit pacman. (Das Skript refind-btrfs schaut im Grunde nach, welche Snapshots neu erstellt oder gar gelöscht wurden, kopiert die Snapshots dann nach /root/.refind-btrfs/ oder löscht diese und fügt oder löscht dann in der refind.conf bzw. einer eigenen, untergeordneten Config Boot-Stanza-Einträge mit der Kernel-Option rw hinzu, um die Snapshots auch in rEFInd zur Boot-Auswahl zu haben. Quasi das gleiche, was grub-btrfs für Grub2 macht.)

Dann sah ich, dass unter /run/ noch ein Ordner vorhanden war, der mit timeshift beschriftet war und ich etwas verwirrt war, dass der Ordner noch vorhanden ist, obwohl Timeshift nicht mehr auf dem System ist. Da ich verwundert war und vermutete, dass Timeshift nicht hinter sich aufräumt, wechselte ich in Dolphin auf die Admin-Ebene und löschte besagten Ordner mit root-Rechten (dass Timeshift zur Laufzeit dieses die Snapshots unter /run/timeshift/ einbindet und / nicht auf / zeigt, sondern auf /run/timeshift/xxxxx/backup/ und dort die Btrfs-Subvolumes sowie den Ordner timeshift-btrfs mit den Snapshots darin auflistet, habe ich zu dem Zeitpunkt irgendwie ausgeblendet). Warum ich das vermutet hatte? Keine Ahnung, scheint noch eine Windows-Krankheit zu sein, denn dort räumen schlecht entwickelte Programme bei der Deinstallation auch nicht hinter sich auf und lassen Datei- und Ordner-Leichen zurück, teilweise auch Einträge in der Registry.

Quasi direkt nachdem der Ordner gelöscht wurde, verschwanden die Symbole der angehefteten Programme in der Kontrollleiste, alle Programme im Anwendungsstarter waren weg und die KDE-Oberfläche reagierte kurz danach auch gar nicht mehr. Da hab ich dann realisiert, dass was nicht stimmt und ich wahrscheinlich Bockmist gebaut habe. 😅
Ein Reboot des Systems blieb erfolglos, da sich rEFInd und Grub2 beim Boot beschwerten, dass das Kernel-Image vmlinuz-linux nicht gefunden wurde.

Also EndeavourOS-Livesystem vom Stick gebootet, die lokale endeavouros-Partition meiner SATA-SSD in den Verzeichnisbaum eingehängt und mir den Schaden angesehen, den ich angerichtet hatte: Ich hatte durch meine Aktion das komplette @-Subvolume gelöscht. Zwar war die komplette Ordnerstruktur inklusive allen Unterordnern und Verzweigungen in / noch vorhanden, allerdings fehlten in jedem Ordner die Dateien, die sich dort eigentlich befinden sollten, bspw. war /dev/ noch vorhanden sowie alle Unterordner darin, aber alle Gerätedateien waren futsch. Das @home-Subvolume blieb zum Glück unangetastet und alle Daten waren dort noch vorhanden, sodass ich meine Lutris-Library, Downloads, alle Config-Daten und selbst erstellten Shell-Skripte noch wegkopieren und EndeavourOS dann neu installieren konnte. Meine Steam-Library hatte ich zwar auch wegkopiert, mir fiel aber erst danach auf, dass da etliche GBs fehlen, da Steam auf der neuen Installation zwar die Spiele-Ordner erkannt hat, aber im Prinzip alle Daten neu heruntergeladen hat. Dann hatte ich auch gesehen, dass der steamapps-Ordner weit weniger groß war, als er es gerade aktuell tut.

Jetzt läuft das System wieder seit dem 01.10. stabil, voll eingerichtet und auch mit Snapper und dem Btrfs-Assistant als GUI komme ich deutlich besser zurecht und das refind-btrfs-Skript funktioniert nun ebenfalls. Timeshift hat die Angewohnheit, unter /run/timeshift/ einen Ordner mit einer random Zahl zu erzeugen, in dem sich dann in einem weiteren Unterordner backup die Snapshots verbergen, der zum einen immer nur dann da ist, wenn Timeshift gerade ausgeführt wird und zum anderen sich der Name des Ordners, also diese Zahl, jedesmal aufs neue ändert, wenn Timeshift gestartet wird. Wenn Timeshift nicht läuft, ist /run/timeshift/ einfach leer. Dementsprechend musste ich die refind-btrfs.conf anpassen und den Pfad plump auf /run/timeshift/ festlegen und die Suchtiefe entsprechend erhöhen, damit die Snapshots überhaupt gefunden wurden. Denn mit einem festen, absoluten Pfad kann man bei einem Ordner, dessen Name sich jedesmal ändert, einfach nicht arbeiten.
Snapper hingegen legt einfach unter / den Ordner .snapshots an und listet darin die Snapshots einfach mit einem jeweiligen Ordner mit einer Zahl entsprechend ihrer Erstellungs-Reihenfolge, was viel einfacher und angenehmer mit zu arbeiten ist als mit Timeshift.
Ob ich das System zwischen der Deinstallation von Timeshift und dem Löschen von /run/timeshift/ einfach mal hätte rebooten sollen oder ob das dann trotzdem so passiert wäre, kann ich nicht mehr sagen.
 
Zuletzt bearbeitet:
Solche Erfahrungsberichte sind Gold wert. Danke dafür.

Ist diese btrfs GUI buttermanager?
 
  • Gefällt mir
Reaktionen: Hyourinmaru
Nope, die GUI heißt btrfs-assistant. Wird glaube ich gerne in Verbindung mit Snapper verwendet, laut Gitlab Page ist das Installieren von Snapper aber nur optional. In meinem Fall verwende ich es mit Snapper. Ich häng mal n paar Screenshots an.

1728687372038.png
1728687426438.png
1728687460500.png
1728687486811.png


Gitlab Projekt: https://gitlab.com/btrfs-assistant/btrfs-assistant
AUR Package: https://aur.archlinux.org/packages/btrfs-assistant
 
Hallo zusammen,

wollte mir jetzt mal Linux als Betriebssystem genauer anschauen und habe es mal Testweise installiert.

Leider habe ich mit Bildfehlern zu kämpfen.
Beim bewegen der Desktopfenster strahlen rote vertikale Linien von der Oberseite des Fensters bis zum Ende des Monitor weg.

Umso heller der Inhalt des Fenster, desto schlimmer ist die Ausprägung.

Kennst jemand diesen Fehler?

Der Fehler tritt bei verschiedenen Distribution auf, habe mehrere getestet.
Nobara 40 mit Kde
Nobara 40 mit Gnome
CachyOs

Habe in meinem Rechner einen Ryzen 5700
Und eine Rtx 3070
 

Anhänge

  • 20241015_160234.jpg
    20241015_160234.jpg
    1,4 MB · Aufrufe: 58
Hallo & willkommen im CB-Forum!! 🙂

Liegt wahrscheinlich am nVidia-Treiber.
Bitte mal einen älteren Treiber testen.

Ist eventuell der HDR-Modus im Monitor aktiviert?
Dann testweise deaktivieren.
 
  • Gefällt mir
Reaktionen: frazzlerunning
Interessantes Video mit paar Erklärungen.

 
Mein "Distrohopping" habe ich am Wochenende offiziell für beendet erklärt - naja, wenigstens bis zum Weihnachtsurlaub, da fange ich immer wieder an zu basteln :D

In den letzten Monaten habe ich viele Distributionen auf unterschiedlichen Rechnern getestet und fand es sehr spannend, wie unterschiedlich die Ditros waren. Getestet habe ich (mindestens ein paar Wochen auf einem Rechner - keine VM): OpenSuse Tumbleweed, OpenSuse Leap, EndeavoursOS, Garuda, Chachy OS, Debian und Nobara).

Auf meinem Hauptrechner läuft seit Samstag wieder EndeavourOS, da es recht nah an Arch ist und mir viele Freiheiten gibt. Die Installation und Konfiguration war definitiv aufwändiger als z.B. bei Garuda, aber die individuelle Einrichtung hat mir Spaß gemacht und so konnte ich mir mein persönliches System zusammenbasteln. Für fortgeschrittene Anfänger ein super OS.

Meine "Konsole" (alter PC, der am Fernseher hängt) läuft weiterhin auf CachyOS. Ein wirklich tolle Distro und hat den (nahezu perfekten) Sweetspot zwischen "ist nichts vorhanden" (Arch) und "ziemlich überladen" (Garuda).

Mein Server läuft weiterhin auf OpenSuse Leap - und das bleibt auch so. Wird ja nicht zu zocken benutzt :)
 
  • Gefällt mir
Reaktionen: Tanzmusikus, Deinorius, Hyourinmaru und 2 andere
Mich hat auch mal der Spieltrieb gepackt, mein MSI NB (mit RTX) + Pop!_OS + Steam und zum testen Sniper Elite 5, das läuft genauso flüssig und gut wie mit Windows. Nur der Start ist ab und zu etwas wackelig, braucht manchmal 2 Anläufe.
 
frazzlerunning schrieb:
@Leranis Tipp für den Weihnachtsurlaub: bazzite
Läuft super auf meinem frame.work 16
Für die "Konsole", also den Gamingrechner, der am PC hängt, sicher eine nahezu perfekte Lösung, aber für ein Notebook?

Ich nutze bazzite sehr gern auf dem Steam Deck und kann mir jedoch nicht vorstellen, das auf meinen Notebooks und PCs zu installieren.
 
Bazzite hat ja für das Deck oder andere Handhelds bzw. für Konsolenverhalten den Steam Gaming Mode aktiv. Den hab ich für den Laptop nicht mitinstalliert, damit verhält sich Bazzite eher wie ein 'gewöhnliches' Linux, aber mit den Vorteilen die Bazzite eben so unter der Haube hat: atomic updates, scheduler Optimierungen, fsync Kernel...

Und:
1729505589651.png
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Deinorius

Ähnliche Themen

Zurück
Oben