News Proton 10 Release Candidate: Mehr Spiele mit weniger Fehlern unter Linux spielbar

gamecard schrieb:
@Kuristina

-Unabhängigkeit von der Distribution
-Bessere Sicherheit durch Sandboxing
-Keine Abhängigkeitskonflikte
-Einfache Deinstallation und Installation

Das wegen flatpak und vor allem funktioniert unabhängig von der Distribution ...

Und in Paketmanager hat nicht alles.
Sandboxing ist weitestgehend nicht wirklich aktiv. Hat trotzdem oftmals Access zu dem kompletten Homefolder access, wenn es nicht dementsprechend angepasst wird

-Keine Abhängigkeitskonflikte

Sollte eigentlich nicht passieren bei den meistein Distributionen, solange diese richtig gepackaged werden und keine Third Party repos genutzt werden

Flatpak ist für einige wenige Pakete wirklich gut, z.B das offizelel obs-studio Paket von Flatpak da dies die meisten Features enthält. Viele Distributionen packagen dies nicht wegen dem Chromium Framework.
Das NVIDIA / Mesa Driver management ist bei Flatpak auch ein Horror, welches seit Jahren nicht gelöst wird, e.g man könnte den nativen Treiber vom System nutzen und zu Flatpak exposen, aber naja.

Ebenfalls hat man auch echt wenig Power, ob die Pakete die neusten Libaries bringen oder nicht. Dies ist beim dynamischen Linking nie der Fall und dadurch werden Security fixes wesentlich schneller ausgerollt.
 
  • Gefällt mir
Reaktionen: ILoveShooter132, Deinorius und Kaito Kariheddo
Cl4whammer! schrieb:
Seit wann richtet sich etwas nach denen? Der Zug ist
ich kenne einige Leute, die eigene Serverinfrastruktur betreiben...
 
sedot schrieb:
Witcher 3 GOTY war aufwändiger weil GOG, kein Grund für Drama für mich.
Andere mögen jetzt unter anderen Umständen andere Erfahrungen sammeln, klar.
GoG Spiele sind mit Heroic Launcher und UMU inzwischen sehr pflegeleicht.
 
  • Gefällt mir
Reaktionen: xXDariusXx und sedot
flaphoschi schrieb:
Schön das Valve sich anstrengt. Aber jetzt sollten zunehmend die Ressourcen in die Förderung qualitativ hochwertiger nativer Ports fließen.

Gibt extra die Linux Runtime für Entwickler die etwas Hilfe benötigen:
https://github.com/ValveSoftware/steam-runtime

Wird längst Zeit bei den Steam Awards native Spiele (Indie und AAA) zu krönen.


Das Preisgekrönte Unrailed ist auch nativ und läuft hervorragend. Schön, wenn gezeigt wird, dass das doch an den Entwicklern selbst liegt ;)

Counter-Strike, Xonotic, Unreal Tournament, Unity und Konsorten. Alles nativ. Wichtig sind kompetente Linuxentwickler!
Wenn ein langjährige Windowsentwickler einen Port macht, merkt man das leider auch. Die kennen auch ihre Kniffe (C++ Reddistribuatable…), aber machen mangels Erfahrung andere Fehler.
Die Idee für Awards von Linux native Spiele finde ich nett, das ist ein guter Einfall und Valve sitzt hier am Hebel dies auch umsetzen zu können.

Dennoch hat, wie andere meine ich in ähnlicher Form geschrieben haben, Proton bzw. der verstärkte Support von Valve in Sachen Linux Gaming die Mühe für native Linux Spiele zunächst nach hinten verschoben (nicht torpediert). Ich bin nun 2 Jahre auf Linux und diesbzgl. habe ich die Erfahrung gemacht oder besser gesagt vernommen, dass native Linux Spiele abhängig von der Distro und den mitgelieferten Systembibliotheken besser oder schlechter laufen können. Ich denke, das ist auch das oder eines der Probleme.

Und dieses Problem geht ja Valve mit dem Container System und dem Linux Runtime in Steam auch an. Problem (in meinen Augen) ist aber, dass es zu nah an Valve bzw. Steam hängt. Gut, dank UMU ist es mittlerweile von Steam abgekoppelt, aber viele kennen UMU nicht und es noch relativ jung. Ich denke, es wäre gut wenn mehr Einheitlichkeit herrschen würde. Eine Basis, auf der native Spiele Fuß fassen können und die in den verschiedenen Distros (transparent und über eine Übersicht leicht einsehbar), zumindest wenn die Köpfe dahinter Wert auf gaming legen, vorhanden ist und/oder via package manager nachinstalliert werden kann bzw. automatisch installiert wird, wenn nicht bereits vorhanden, sobald gespielt werden möchte und ein Spiel diese Basis als Voraussetzung mit sich bringt. Oder um es in anderen Worten zu sagen:

Die Linux Welt benötigt ein gaming-runtime-environment, auf das sich im großen Stil verständigt wird, von mir aus durch ein Gremium überwacht und vorangetrieben. Es ist schön, dass Valve, natürlich auch aufgrund Eigeninteresse, das selber vorantreibt, aber die Linux Welt sollte und darf sich nicht nur auf Valve in der Hinsicht verlassen. Valve hat den ersten Pfeiler errichtet, nun macht daraus ein solides Fundament (mit Valve von mir aus als Teil des angesprochenen Gremiums).
 
  • Gefällt mir
Reaktionen: flaphoschi
Mimir schrieb:
Das soll ein Problem "höherer Größenordnung" als bei Windows sein?
Mimir schrieb:
Die Probleme sind um viele Größenordnungen gravierender (in Bezug auf Gaming)
Dass man bei einem Spiel auf "Proton experimentell" stellen muß?
Ernsthaft?
Proton Experimentell ist die vorab Version, ähnlich eine Beta, der kommenden Version.
Das ist ziemlich genau, wie wenn man bei so einem Titel, unter Windows vielleicht einen Beta/hotfix Grafikkartentreiber installieren muß, weil der bisherige WQHL Treiber noch keine Fixes für das Spiel drin hat.
Wartet man einen Monat, ist der Fix aus experimentell in der aktuellen Proton Version von Haus aus drin.
Sprich die notwendigen Fixes für das Spiel sind bereits verfügbar (an Tag 1) sind nur noch nicht in der finalen Proton Version drin, weswegen die Bewertung mit grün/Daumen hoch auch richtig sind.
Beim nächsten Proton Update, sind diese Fixes dann auch integriert und es läuft auch ohne, dass man den einen Klick für Proton experimentell machen muß.
Da hast du unter Windows aber bedeutend mehr Aufwand, wenn der Treiber für so einen Indi Titel noch nicht gefixed ist. Und die Situation hatten wir schon mehrmals in der letzten Zeit, wenn ein Titel rauskommt, der vielleicht kein AAA Budget und Werbung hatte, dass AMD/Nvidia noch keine Optimierungen im Treiber vorgenommen haben und es deswegen nur fehlerhaft lief.

Manche Nutzer, stellen auch ein, das pauschal Proton Experimentell genutzt werden soll. Im Gegensatz zu Windows, bei dem nur ein Treiber gleichzeitig aktiv ist, kann ich unter Linux jedem Spiel sagen, dass es bitte diese Proton Version nutzen soll.

Grundsätzlich darf man das aber auch gerne mal ansprechen, dass die Spielehersteller viel zu oft rumpfuschen und nachher unter Windows der Treiber, oder unter Linux Wine/Proton, deren Fehler ausbaden müssen.
 
  • Gefällt mir
Reaktionen: xXDariusXx, ILoveShooter132, Hyourinmaru und eine weitere Person
Mimir schrieb:
Dort werden trotz gravierender Mängel Spiele mit der höchsten Platinum Auszeichnung versehen „spiel läuft PERFEKT ohne jegliche änderungen“, obwohl selbst dort die Kommentare voll mit gravierenden Problemen sind oder eben zumindest modifikationen notwendig sind, was beides eben nicht der Auszeichnung entspricht.
So ist das halt mit Community-Projekten. Wenn man den Usern die Bewertung überlässt, braucht man eine kritische Masse, damit das eine relevante Aussage ergibt. Die einzige Alternative, die in dieser Hinsicht existiert, ist Valves Steam Deck Bewertungsystem und das hat eigene Probleme, ist jedoch nicht auf Linux an sich gerichtet.

Mimir schrieb:
Hier ist es defintiv gerechtfertigt, dieses Spiel als GOLD zu klassifizieren. Da wäre es gut zu wissen, ab welcher Verhältnismäßigkeit etwas als GOLD oder PLATINUM gelistet wird. Aber auch hier, wenn die User nicht richtig einordnen können, müssen die Betreiber eine Anpassung vornehmen, damit die Vorgehensweise eindeutiger wird.
Das Umstellen der Proton-Version im Steam Client betrachte ich jedoch nicht als Tinkering! Wenn das schon als problematisch angesehen wird, wie ist das dann erst unter Windows? Oder glaubst du, darunter haben einige Leute absolut keine Probleme? Linux-Kritiker tun manchmal so, als ob Windows unproblematisch wäre.
Aber GOLD ist immer noch sehr gut, was die Spielbarkeit betrifft. Zumindest in diesem Spiel sind die meisten zufrieden und das einzige Linux-relevante Problem scheint Audio zu sein und das hat nicht jeden betroffen. Andere Probleme (wie die Einstellungen) sind welche des Spieles. Nach deinem ersten Kommentar habe ich weitaus schlimmeres erwartet.

Btw. wie schafft man es Arch mit dem Kernel 6.2.6 zu betreiben? :lol: Und Linux Mint mit 5.15 ist auch recht konservativ.

Rondrer schrieb:
Dank Wine 10 laufen die Games jetzt nativ in Wayland und man ist nicht mehr auf die xwayland Kompatilitätslayer angewiesen.
Jo, der Treiber ist in Wine 10 standardmäßig an und sollte es auch in Proton sein. Benchmarks zwischen xwayland und wayland wären recht interessant, ob sich da Unterschiede auftun.
Aber der Steam Client bleibt weiterhin 32-bit und X11, unter wayland sollte es ja noch immer problematisch sein?
 
Deinorius schrieb:
Linux-Kritiker tun manchmal so, als ob Windows unproblematisch wäre.

Ist es auch weitestgehend.

Das gravierendste Problem, das ich in den letzten 10 Jahren hatte, war jüngst mit den Nvidia Treibern.
Dort kam es zu Systemabstürzen, wenn man DLSS4 Frame Generation in Kombination mit Vsync und mehr als 120 Hz nutzen wollte.

Für mich ein recht ärgerliches Problem, aber trotzdem sehr spezifisch. Auf DLSS3 Frame Generation zurück zu gehen (also einfach den Override in der Nvidia App nicht nutzen), oder auf 120 Hz zu stellen oder Vsync zu deaktivieren und stattdessen ein FPS limit zu setzen um im VRR bereich zu bleiben, löste das Problem bereits. Mittlerweile ist es auch vollständig gefixed.

Es gibt zwar weiterhin große Probleme mit RTX5000, aber weder das noch das gerade beschriebene Problem hat irgendwas mit Windows zu tun.

Ich kann mich nicht erinnern, dass es sonst irgendwelche Probleme gab. Ich kaufe recht viele Spiele übers Jahr. Meistens an die 10 Triple-A Spiele. Meist zum Release und die einzigen Probleme die ich sonst in den letzten 10 Jahren erlebt habe beziehen sich auf Bugs in den Spielen selbst. Also Bugs in bezug auf Spielmechanik oder mal ein Darstellungsfehler. Das wird aber ganz normal über die Spielepatches behoben.


Ich will nicht sagen, dass Windows fehlerfrei ist. Meine güte, das ist es ganz bestimmt nicht, weit davon entfernt. Ich will sogar glauben, dass Linux Systeme meist sauberer laufen. Aber wir reden hier von grundsätzlicher Kompatibilität von Spielen. Also so dinge wie Soundaussetzer, Crashes, fehlende Texturen.

Das sind teils grundlegende Probleme die weder den Grafiktreiber noch den Spieleentwickler betreffen.
Das kann meist nur über Proton gefixed werden und bei Windows kenne ich sowas nunmal nicht.
Und sowas ist dann eben ein völlig anderes Kaliber an Problemen oder auch potenziellen Problemen mit denen man sich unter Proton herumschlagen muss.

Auf dieser Ebene gibt es bei Windows einfach keinerlei Probleme. Aber die gibt es grundsätzlich bei allen Systemen nicht, oder zumindest so gut wie gar nicht, solange Software für das System entwickelt und getestet wird, auf dem sie laufen soll. Das liegt in der Natur der Sache.

Und deswegen wundert es mich auch nicht, dass wahrscheinlich 8/10 Problemen mit einem Spiel auf einen Übersetzungslayer wie Proton zurückzuführen sind und die restlichen 2/10 auf das Spiel selbst oder den Grafiktreiber. Auch glaube ich, dass es extrem selten vor kommt, dass Probleme in Spielen auftreten, die von Windows selbst verursacht werden, auf einem Linux System mit Proton aber nicht auftreten Aber gerade das scheint ja wohl das Hauptargument zu sein, wenn man von "Windows Problemen" spricht?
Ich wüsste aber zu gerne, welche das sein sollen. Zumindest in Bezug auf die Kompatibilität mit Spielen würde mir da kein Beispiel einfallen.
 
  • Gefällt mir
Reaktionen: daivdon
schM0ggi schrieb:
Die Idee für Awards von Linux native Spiele finde ich nett, das ist ein guter Einfall und Valve sitzt hier am Hebel dies auch umsetzen zu können.

Dennoch hat, wie andere meine ich in ähnlicher Form geschrieben haben, Proton bzw. der verstärkte Support von Valve in Sachen Linux Gaming die Mühe für native Linux Spiele zunächst nach hinten verschoben (nicht torpediert). Ich bin nun 2 Jahre auf Linux und diesbzgl. habe ich die Erfahrung gemacht oder besser gesagt vernommen, dass native Linux Spiele abhängig von der Distro und den mitgelieferten Systembibliotheken besser oder schlechter laufen können. Ich denke, das ist auch das oder eines der Probleme.

Und dieses Problem geht ja Valve mit dem Container System und dem Linux Runtime in Steam auch an. Problem (in meinen Augen) ist aber, dass es zu nah an Valve bzw. Steam hängt. Gut, dank UMU ist es mittlerweile von Steam abgekoppelt, aber viele kennen UMU nicht und es noch relativ jung. Ich denke, es wäre gut wenn mehr Einheitlichkeit herrschen würde. Eine Basis, auf der native Spiele Fuß fassen können und die in den verschiedenen Distros (transparent und über eine Übersicht leicht einsehbar), zumindest wenn die Köpfe dahinter Wert auf gaming legen, vorhanden ist und/oder via package manager nachinstalliert werden kann bzw. automatisch installiert wird, wenn nicht bereits vorhanden, sobald gespielt werden möchte und ein Spiel diese Basis als Voraussetzung mit sich bringt. Oder um es in anderen Worten zu sagen:

Die Linux Welt benötigt ein gaming-runtime-environment, auf das sich im großen Stil verständigt wird, von mir aus durch ein Gremium überwacht und vorangetrieben. Es ist schön, dass Valve, natürlich auch aufgrund Eigeninteresse, das selber vorantreibt, aber die Linux Welt sollte und darf sich nicht nur auf Valve in der Hinsicht verlassen. Valve hat den ersten Pfeiler errichtet, nun macht daraus ein solides Fundament (mit Valve von mir aus als Teil des angesprochenen Gremiums).
Ich muss erstmal schauen was UMU ist.

Für eine einheitliche Umgebung bei quellgeschlossenen Spielen - die bringen leider Ihre eigenen Probleme die man bei IOQuake3, OpenRA oder Xonotic gar nicht kennt - ist Flatpak eigentlich ideal.

Nur wenn man in Flatpak keine Bezahlfunktion einbaut, kann halt auch niemand etwas anbieten (ausser Valve eben Steam).
Ergänzung ()

Mimir schrieb:
Ist es auch weitestgehend.

Oh je. Dann frag mal die Entwickler. Und warum es so viele Bugfixes braucht.

Trick 1: Wir packen schön alle alten Bibliotheken die wir haben zum Spiel. Ist egal ob die Fehler haben. Es sind die Fehler die wir kennen…

Wer die meisten C++ Redistributables findet gewinnt?

Da gibt es genau eine unter Linux ;)
Ansonsten wird dieser Trick von Closed-Source Entwicklern auf jeder Plattform angewendet. Die Kunst ist zu wissen, auf welche Bibliotheken und Dienste man sich wie weit verlassen kann.

Mimir schrieb:
Das gravierendste Problem, das ich in den letzten 10 Jahren hatte, war jüngst mit den Nvidia Treibern.
Dort kam es zu Systemabstürzen, wenn man DLSS4 Frame Generation in Kombination mit Vsync und mehr als 120 Hz nutzen wollte.

Es gibt einen Grund warum immer von Nvidia abgeraten wird.

Mimir schrieb:
Für mich ein recht ärgerliches Problem, aber trotzdem sehr spezifisch. Auf DLSS3 Frame Generation zurück zu gehen (also einfach den Override in der Nvidia App nicht nutzen), oder auf 120 Hz zu stellen oder Vsync zu deaktivieren und stattdessen ein FPS limit zu setzen um im VRR bereich zu bleiben, löste das Problem bereits. Mittlerweile ist es auch vollständig gefixed.

Zugegeben. Das klingt genau nach den Windows-Speziallocken.

Seit zwanzig Jahren das gleiche Muster bei Windowsanwendern:

Also wenn Linux x macht, dann komme ich.
Linux macht x. Gewaltige Kraftanstrengung, weil es generell für alle funktionieren soll.

Anwender so:
Ich aber jetzt y und y will auch auch. Außerdem FDR5 und NSYNC4.

Mich interessiert nur eines, läuft es stabil und flüssig. Wenn man dagegen den i Punkt in der Suppe sucht, trägt man nicht zur Lösung bei. Sinnvoll ist es, direkt beim Hersteller zu kommunizieren was man möchte und dann erstmal die Kaufentscheidung davon Abhängig zu machen.

FreeSync hat länger gebraucht - auch weil sich AMD etwas ungeschickt angestellt hat. Läuft aber nun seit Jahren und…eigentlich ist es mir dann doch nicht so wichtig gewesen.


Eingebrannt hat sich bei mir die Person, die wegen einer Nvidia-3D-Shutterbrille nicht wechseln konnte. Also. Weil die Person das so wollte.


PS: Und um Himmels Willen! Kauft nie Nvidia. Keine Firma hat so viel Leute angepisst wie die Bude. Neuester Streich “quelloffen ja, aber wir werden nichts in Linux und Mesa mergen!!!”. Und das alles wegen 20% in einem Pressebenchmark. AMD oder Intel rein - Ruhe. Weiss ich wenigstens, dass nicht nach einem VT-Switch die Texturen weg sind…fünf Jahre lang. Nvidia weiß das seit 2016 und statt das Problem zu beheben, erfinden sie eine OpenGL-Extension dafür.
https://www.phoronix.com/news/NVIDIA-Ubuntu-2025-SnR

Da erkennt man den Monopolist. Erklärt einen Fehler zum Feature. Definiert sich eine Extension dafür und sagt “Ist normal”.
https://registry.khronos.org/OpenGL/extensions/NV/NV_robustness_video_memory_purge.txt


This extension will have a limited lifespan, as planned architectural
evolutions in the NVIDIA Linux driver stack will allow
video memory to be persistent. Any driver that exposes this
extension is a driver that considers video memory to be
volatile. Once the driver stack has been improved, the extension
will no longer be exposed.

Das war 2016.

Ich habe so einen Verdacht. Die Nvidiatreiber sind nirgends “besser” als die vom Intel oder AMD. Die Spieleentwickler sind gezwungen, dass auf Nvidia alles auszubessern.

PS: Nvidia ist für mich inzwischen ein Triggerwort geworden. Diese “wir mergen nichts in Linux und Mesa” Nummer war nur der letzte Tropfen. Übergelaufen ist das Fass bei mir schon 2010 ;)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: gongoscho, ILoveShooter132 und Deinorius
Oh je, also muss ich mich bei Linux auch noch bei der Wahl meiner Hardware einschränken oder neu kaufen. Nichtmal der Markführer in Sachen GPUs funktioniert damit gut. Das ist ja dann ne Vollkatastrophe.

Linux funktioniert viel fehlerfreier als Windows, aber Proton und die Treiber sind Dauerbaustelle, aber das kommt nur vom Mindest der User, die sich nicht weit genug einschränken wollen. Okay.


Sorry, wenn ich das so polemisch formuliere, aber das macht es wirklich nicht besser für den interessierten Kunden...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: daivdon
Mimir schrieb:
Und deswegen wundert es mich auch nicht, dass wahrscheinlich 8/10 Problemen mit einem Spiel auf einen Übersetzungslayer wie Proton zurückzuführen sind und die restlichen 2/10 auf das Spiel selbst oder den Grafiktreiber.
Völliger Bullshit auf der Basis von Selbst ausgedachten Zahlen.

Proton als Übersetzungslayer funktioniert ziemlich ausgereift und auf einem soliden Standard. Neue Features wie Upscaling kommen verspätet, liegt in der Natur der Sache. Wenn aber der Übersetzungslayer versagt, dann ist das kein Fehler in Proton, sondern liegt an "kreativen" Wegen, wie die Entwickler Hardware-API- oder Systemcalls in ihre Software reingestümpert haben (oder neue geniale Lösungen gefunden haben, je nachdem).
Das muss dann reingepatcht werden.
 
  • Gefällt mir
Reaktionen: ILoveShooter132, Deinorius und Gohma
Mimir schrieb:
Nichtmal der Markführer in Sachen GPUs funktioniert damit gut.
Was aber weniger ein Problem von Linux selber ist, sondern weil Nvidia Nvidia-Dinge tut. Und darin sind sie sehr gut.
Die Community hat ja damals schon gezeigt, dass sie irgendwo den Willen hat, Nvidia-GPUs lauffähig zu machen, woraus dann der Nouveau-Treiber resultierte. Da Nvidia aber dokumentationsgeizig ist und Techniken oftmals Closed Source sind, musste die Community halt das nehmen, was sie bekam und was für die Arbeit zur Verfügung stand. Daraus resultierte ein eher ungenügender Treiber, den man eigentlich nicht benutzen möchte, außer man hat eine sehr alte Nvidia-Karte, wodurch man halt in den sauren Apfel beißen und doch den propritären Treiber nehmen musste, der bei weitem besser funktioniert als Nouveau. Wenn ich das so noch richtig im Kopf habe.

Diese Firma interessiert sich für Linux uns Consumer soviel wie ich für Raketenwissenschaften und der "freie" Treiber, den nvidia nun entwickelt ist meiner Meinung nach, nicht die Ressourcen wert, die dafür aufgewendet werden. Die können sie auch in anderen Abteilungen wie DLSS oder so. wieder einsetzen.
Zusätzlich zu der Sache mit Mesa- und dem Kernel-Merge, packt diese Firma Teile des Treibers einfach in die Closed Source Firmware*, damit man dann am Ende wieder behaupten kann, der Treiber sei Open Source.
Der Grund, dass Nvidia überhaupt mit der Entwicklung seines "Open Source"-Treibers begonnen hat, liegt sicher nicht daran, dass sie die Consumer lieben oder Lederjacke plötzlich eine 180° Wende gemacht hat.

*Sicher, AMD wird das vermutlich auch gemacht haben, aber mit Sicherheit nicht in einem solchen Umfang und Umgang, wie es Nvidia tut.
 
  • Gefällt mir
Reaktionen: ILoveShooter132
Tevur schrieb:
Völliger Bullshit auf der Basis von Selbst ausgedachten Zahlen.

Proton als Übersetzungslayer funktioniert ziemlich ausgereift und auf einem soliden Standard. Neue Features wie Upscaling kommen verspätet, liegt in der Natur der Sache. Wenn aber der Übersetzungslayer versagt, dann ist das kein Fehler in Proton, sondern liegt an "kreativen" Wegen, wie die Entwickler Hardware-API- oder Systemcalls in ihre Software reingestümpert haben (oder neue geniale Lösungen gefunden haben, je nachdem).
Das muss dann reingepatcht werden.

Also liegt es in der Natur der Sache, dass Linux und Proton niemals in Sachen Kompatibilität mit Windows gleichziehen kann, solange man Windows Anwendungen laufen lässt.

Also bestätigt das genau das was ich bisher immer kritisiert habe. Solange keine nativen Ports kommen, wird das Niveau niemals vergleichbar sein können.
 
Mimir schrieb:
Oh je, also muss ich mich bei Linux auch noch bei der Wahl meiner Hardware einschränken oder neu kaufen. Nichtmal der Markführer in Sachen GPUs funktioniert damit gut. Das ist ja dann ne Vollkatastrophe.

Linux funktioniert viel fehlerfreier als Windows, aber Proton und die Treiber sind Dauerbaustelle, aber das kommt nur vom Mindest der User, die sich nicht weit genug einschränken wollen. Okay.
Wo ist den Proton eine Dauerbaustelle? Es ist schon richtig das an Proton immer gearbeitet wird so wie es nun mal auch auf Windows mit den Grafikkartentreibern der Fall ist.

Dir ist hoffentlich klar das für die Grafikkartentreiber auf Linux einzig und alleine die HERSTELLER verantwortlich sind und nicht Linux als Betriebssystem oder? (vor allem wenn wir hier von Nvidia reden)
 
flaphoschi schrieb:
Wobei ich die Rolle von BSD nicht verschweigen möchte. Es wird weiterhin eingesetzt.
Das einzige BSD, welches noch im halbwegs nennenswerten Umfang eingesetzt wird ist FreeBSD. Und selbst das leidet darunter, das bestimmte Dinge (noch) nicht gehen, wie "Docker" oder GPU-computing.

Linux zieht sehr viel Aufmerksamkeit aufsich und da kommt die Betriebssystem-Diversität so ziemlich unter die Räder.
 
Mimir schrieb:
Also liegt es in der Natur der Sache
Genau.
Aber deswegen ist "kritisieren" doch absurd. Du hast den Sachverhalt doch ziemlich richtig dargestellt.
Das ist wie zu kritisieren, dass Wasser nass macht, statt zu krtisieren, dass die Jacke Wasser durchlässt.
 
Mimir schrieb:
Sorry, wenn ich das so polemisch formuliere, aber das macht es wirklich nicht besser für den interessierten Kunden...
Kunden, welcher Kunde?
Linux ist kostenlos. Und genau das, ist das Problem.
Ihr meint immer alle Ansprüche stellen zu dürfen an etwas, das man euch schenkt.

Bleibt Windows Kunden und gut.
Da könnt ihr euch dann auch beschweren, wenn mal etwas nicht funktioniert.
 
  • Gefällt mir
Reaktionen: xXDariusXx, douggy, Mittelspecht und 8 andere
Mimir schrieb:
ProtonDB verbildlicht diese Mentalität vortrefflich.
Dort werden trotz gravierender Mängel Spiele mit der höchsten Platinum Auszeichnung versehen „spiel läuft PERFEKT ohne jegliche änderungen“, obwohl selbst dort die Kommentare voll mit gravierenden Problemen sind oder eben zumindest modifikationen notwendig sind, was beides eben nicht der Auszeichnung entspricht.
Etwas passiert oder etwas passiert häufig? Wenn man auf sicher gehen will gibts doch in Steam dieses "offiziell unterstützt Steamdeck" oder wie das heißt...

Das vereinzelt solche Systeme auch mal schlecht funzen weil jemand Mist baut ist doch normal... die Frage ist immer in der Häufigkeit.
 
flaphoschi schrieb:
Drei Viertel ;) Denn Windows war von vornherein nichtfür Server so geeignet wie Unix, war also auch nicht das OS, das es zu verdrängen galt. Die Unternehmen kannten es von der Desktopdominanz her und das war auch eigentlich der einzige Fuß, mit dem MS in diesem Markt Anteile gewonnen hatte. Und bei den ersten großen Schritten von Linux (NASA, SUpercomputer) war Windows noch gar nicht dabei und danach sowieso nicht wirklich.
Mimir schrieb:
will ich nicht einsteigen,
Ich würde an deiner Stelle diese Community (oder zumindest die sich als ihre Vertreter verhalten) nicht soo ernstnehmen und erst recht nicht deren Meinung als Maßstab, ob du "einsteigst" oder nicht.
Das interessiert eh "keinen" in der Echo-Chamber, wo alles tipi-topi funktioniert.
Probier einfach mal auf einer externen Platte (bzw SSD) ab und an den Stand der Dinge aus, also jetzt zB., und sobald du siehst dass bei dir alles gut läuft, dann über einen Wechsel nachdenken. Und wenn nicht, einfach nicht weiter drüber nachdenken. Ein funktionierendes OS hast du ja noch.
Ontopic:
Im Gegensatz zu der Befürchtung, dass nicht alles mit Valve verbunden sein soll, was diese Spiele-Entwicklung angeht, würde ich mich schon darüber freuen, wenn sie auch außerhalb Proton mitmischen würden.
Und wenn AMD es in ein paar Jahren auch CUDA u. Konsorten wenigstens in der Breite Paroli bieten kann, dann..dann bricht wirklich das JAHR DES LINUX an :P
Aktuell schaut es bei den Spielen eher nicht danach aus für mich, bei anderem Kram vermutlich auch nicht.
Mal schauen ob Pop wenigstens solider läuft mittlerweile.
 
Mimir schrieb:
Also liegt es in der Natur der Sache, dass Linux und Proton niemals in Sachen Kompatibilität mit Windows gleichziehen kann, solange man Windows Anwendungen laufen lässt.

Eigentlich ist es doch genau umgekehrt, oder nicht :confused_alt: Proton steigert die Kompatibilität ja über Windows 10/11 hinaus, das ist doch gerade der Witz daran. Windows-Anwendungen sind immer von einer entsprechenden Windows-Version abhängig, genau die stellt Proton/WINE ja nach (Was Windows ja mit Kompatibilitätsmodi auch versucht).
 
  • Gefällt mir
Reaktionen: ILoveShooter132
Mimir schrieb:
Ist es auch weitestgehend.
Hier könnten wir uns jetzt streiten, wie das definiert gehört. Ab wie vielen Problemen zählt ein Betriebssystem als nicht ausreichend funktionierend?
Ich kann mir Linux so zerschießen wie es unter Windows auch möglich ist. Damals 2018 hat mir der Radeon Treiber unter Windows das gesamte System zerschossen, auf irgendeine Art und Weise geht das in Linux auch. Und dann ist da noch die tickende Zeitbombe "Windows Update".
Ja, Windows funktioniert weitestgehend ... wie auch Linux. 🤷‍♂️

Mimir schrieb:
Ich kann mich nicht erinnern, dass es sonst irgendwelche Probleme gab.
Anekdotische Evidenz. Radeon Treiber sind schlimmer als Nvidia Treiber, nein, umgekehrt! Oder doch doppelt umgekehrt?
Ich sage es hier direkt anekdotisch: "Mein" Arch Linux (btw.) ist das stabilste OS, das ich jemals hatte. :smokin:

Mimir schrieb:
Aber wir reden hier von grundsätzlicher Kompatibilität von Spielen. Also so dinge wie Soundaussetzer, Crashes, fehlende Texturen.
Also Probleme, welche auch unter Windows vorkommen können und ich bin mir sicher, auch von Soundaussetzern unter Windows gelesen zu haben. Dein Gegenargument wäre, dass das kein Problem direkt mit Windows ist.
Aber es ist ein Problem direkt mit Windows. Diese Bugs kommen direkt von Spielen und Anwendungen, oder auch durch Fehler im OS bzw. in der Kommunikation mittels APIs usw. Du hast es selber formuliert: Was interessiert es den User, wo der Fehler herkommt? Der Fehler ist da.

Mimir schrieb:
die Treiber sind Dauerbaustelle
Also wie auch Treiber unter Windows.
Und Windows selber, genau wie auch der Linux Kernel.
Und dann auch die Anwendungen ...

Jede verdammte Software ist eine Dauerbaustelle!

Eigentlich würde ich Software, die eine Dauerbaustelle ist, als hochwertiger betrachten, weil dann wenigstens an dieser gearbeitet wird. Bugs und security leaks kommen immer vor, immer, also ist es besser, diese zu korrigieren.
Ich wünschte, Spiele wären auch Dauerbaustelle, denn es gibt einige (zu viele ...) Vertreter, welche selbst Jahre, auch über 10 Jahre nach Release, Bugfixes bräuchten. Schen warats.
 
  • Gefällt mir
Reaktionen: ILoveShooter132 und netzgestaltung
Zurück
Oben