Special Steam unter Linux: Mehr Leistung durch Proton-Startoptionen

Ich habe das Gefühl, dass du den Open Source Prozess und Proton an sich nicht so ganz verstehst. Proton ist keine "Weiterentwicklung" von Wine. Proton ist eine Sammlung von verschiedenen (open source) Tools mit ein paar extra Anpassungen von Valve oben drauf - das inkludiert Wine, aber auch Translation Layers wie vkd3d, dxvk und media en/decoder (ffmpeg, gstreamer) und VR runtimes und...
Der Vorteil von Proton ist dass all diese Teile vorkonfiguriert, spezifisch auf Spielkompatibilität geliefert werden (während zB Wine mehr allgemein "Windows Software" anvisiert). Proton an sich ist nichts "besonderes" oder "neues" und man kann mehr oder weniger dieselben Ergebnisse erhalten indem man ausschließlich die upstream Projekte verwendet (mit dem kleinen Sternchen von den paar noch nicht upstream Änderungen von Valve - aber Valve hat bisher einen guten track record diese Änderungen relativ bald in upstream zu bringen sofern sie anwendbar sind).

Die Existenz von Proton stoppt die Weiterentwicklung von den upstream Projekten nicht - Wine bekommt weiterhin Updates (mit vielen Änderungen von Valve, ja, aber bei weitem nicht nur von Valve). Worauf sich die Aussage beruht, dass Wine sich "quasi nicht mehr eigenständig entwickelt" verstehe ich ehrlich gesagt nicht.
Im Gegenteil, Wine ist ein so integraler Bestandteil von Proton dass sich die Versionsnummer (Proton 9, 10, 11, ...) direkt auf die unterliegende Wine Version bezieht. Wenn Valve Proton 11 veröffentlicht ist das nicht "der nächste Schritt mit dem Valve Wine zurücklässt" sondern im Gegenteil, Valve updated auf die neue Wine 11 Version (die bereits seit 9. Januar raus ist). Sogesehen hinkt Proton hinter Wine her, nicht umgekehrt.

Und im selben Zug kann Valve nicht einfach "Proton an SteamOS binden". Proton ist eine Ansammlung an verschiedenen Open Source Tools und ist selbst ebenso Open Source. Selbst wenn wir davon ausgehen dass Valve ab morgen Proton auf einmal hinter verschlossenen Türen weiterentwickelt (was die Lizenzen der upstream Projekte sowieso nicht erlauben) dann ist alles was sie bisher gemacht haben weiterhin offen. Valve kann niemals das was sie bisher veröffentlicht haben wieder zurücknehmen! Valve kann ebenso niemals unterbinden dass ich die öffentlich zugänglichen Dateien auf einer anderen Distribution als SteamOS runterlade und verwende. Und selbst wenn Valve irgendeinen magischen Code "der macht dass Proton nur auf SteamOS funktioniert" in Proton hinzufügt (was potentiell auch gegen die Lizenzbedingungen verstoßen könnte, aber ich bin kein Anwalt also wer weiß) kann Valve nicht unterbinden dass ich (oder, wahrscheinlicher, Distro Maintainer) diesen Code wieder entfernen. Und selbst wenn Valve magisch aus dem ganzen Internet und von jedem Computer weltweit jegliche Version von Proton löschen würden dann sind die allermeisten Änderungen und Verbesserungen der letzten Jahre nicht exklusiv in Proton, sondern größtenteils bereits im upstream wie zB Wine, dxvk, usw.

Klar, es ist immer besser wenn mehr Firmen kollaborieren weil es schon möglich ist, dass eine (oder wenige) Firmen alleine zu stark die Richtung eines Projektes angeben können in eine die ihnen hilft, aber eben nicht unbedingt der Allgemeinheit. Aber Wine hat mMn eine gesunde Bandbreite and Entwicklern auch abseits von Valve und... selbst du scheinst ja Proton als Technologie zu mögen, nur eben nicht dass es von Valve ist. Entsprechend scheint ja das Ziel (zumindest in technischer Sicht) mit "unserem" (= Spiele gut spielen zu können) zu überschneiden.

Das ist doch das schöne an Open Source - ich muss die Leute/Firmen/... die kollaborieren nicht mögen, aber ich kann daran glauben dass sie in ihrem eigenen Interesse arbeiten: "Wir verwenden Tool XY das open source ist und wollen dass es für unser Profitgeschäft besser ist. Der einfachste Weg dafür ist diese Verbesserungen zu machen und sie dem upstream zu geben weil wir sie dann nicht mal mehr Instandhalten müssen". Open Source ist die Verkörperung von Interessen aneinander ausrichten. Wir wollen bessere Software für die Allgemeinheit und die Firma will bessere Software um mehr Geld zu machen. Beide dieser Ziele werden mit derselben Aktion erreicht: Open Source Kollaboration. Ich mag Microsoft, Google, Meta, Bytedance, ... auch absolut nicht, freue mich aber wenn sie Verbesserungen in den Linux Kernel, ffmpeg, ... beitragen. Weil ich eben auch davon profitiere und selbst wenn sie eines Tages aufhören das zu tun, können sie ihre bisherigen Verbesserungen nicht mehr zurück nehmen.

Sorry für diesen super langen Text, aber ich hoffe es war doch verständlich und lesbar.
So gut, ich hab gerade den Thread gelesen und hab mir vorgenommen dem Cleriker zu erklären, dass Open Source anders funktioniert als er denkt und jetzt hast du mir die Arbeit vorweggenommen :D

Nur eine kleine Ergänzung (du hattest es schon erwähnt): JA, es ist nicht auszuschliessen, dass Valve seine Einstellung ändert. JA es ist denkbar, dass sie in Zukunft ihr eigenen Süppchen kochen wollen - so etwas ist in der Open Source Geschichte ja schon oft geschehen. Dann gibt es einen "Fork" der Projekte, d.h. Proton würde sich komplett von der Wine-Entwicklung abspalten (aber wie schon mehrfach erwähnt, erst ab diesem Zeitpunkt - alles davor bleibt auch bei Wine!)

Aber momentan sehe ich es so:

a) Valve hat so viel Know-How und Code in Wine upgestreamed - warum sollten sie es plötzlich anders handhaben? Wenn man bestehende Errungenschaften nutzen möchte ohne etwas beizutragen, dann forked man eigentlich sofort. Man sieht es ja an anderen Projekten (Looking at you, Android, looking at you, PS5) in denen Open Source ohne bzw. mit kaum Gegenleistung genommen und geschlossen wurde.

b) Auch wenn Valve nichts mehr zu Wine upstreamen würde, die initiale HIlfe war immens. Ich dene Wine könnte es nun auch ohne Valve stemmen

Ah und was mir spontan nicht klar ist (nicht recherchiert): Valve könnte einen etwaigen Fork ja gar nich closed-source machen, oder? (Kommt auf das Lizenzmodell an...)
 
Ah und was mir spontan nicht klar ist (nicht recherchiert): Valve könnte einen etwaigen Fork ja gar nich closed-source machen, oder? (Kommt auf das Lizenzmodell an...)

Ich könnte mir vorstellen dass vielleicht die Wrapper/Launcher scripts closed werden könnten (also zB das haupt Python script), aber selbst da bin ich mir nicht sicher. Ob Forks von den einzelnen Projekten closed sein können kommt auf die jeweilige Lizenz an, aber zumindest Wine hat soweit ich weiß GPLv2+ und mit der dürfen Derivate nicht closed source werden. Den Spaß kann man sich natürlich mit den ganzen anderen Projekten auch machen und Lizenzen schauen, aber ich nehme an die meisten werden copyleft Lizenzen sein bei denen das ähnlich aussehen wird.
 
So gut, ich hab gerade den Thread gelesen und hab mir vorgenommen dem Cleriker zu erklären, dass Open Source anders funktioniert als er denkt
Eben nicht. Ich hab doch ganz klar geschrieben, dass meine Befürchtung darauf basiert, dass es im fall der Fälle eben nicht jemand selbst in die Hand nimmt und ein eigenes proton-äquivalent zusammenstellt.

Wine entwickelt sich weiter, aber nicht so wie früher. Wine läuft hinterher. Wir reden ja nicht über die Funktionalität von Wine als solchem, da tut sich schon noch einiges, sondern meine Anfrage hier fing an mit der Spieletauglichkeit. Wine ist bei vkd3d auf version 1.19, während proton bereits bei 2.14.1 spielt, richtig?
Es wird gesagt, proton bezieht sich und seine Versionsnummer immer auf den letzten stabilen Stand von Wine, aber die eigenen Anpassungen machen eben sehr viel aus.
Nimm mal "nur" wine zum spielen und stell im Spiel rt an oder aus. Dann landest du, abhängig vom Spiel, ganz schnell auf dem Desktop, während es mit proton weiterläuft.

Du schreibst das so locker weg. Dann tu mir doch als Wine-Nutzer den Gefallen und schreib mir gerade mal die Proton-Verbesserungen in die letzte Wine-version und schick mir das heute Nachmittag. Ich teste dann wie es läuft und schildere es hier.
Geht nicht so einfach? Wozu? Genau das habe ich beschrieben. dass ich eben diese Reaktion befürchte.

Linux nutze ich seit knapp 20 Jahren und die Spielefähigkeit hat sich in den ersten 15 Jahren kaum bewegt. Erst zuletzt und dank Valve tat sich da wirklich immens etwas.

Was denkst speziell du, wie Valve sich das Geld wiederholen zu gedenkt? Die 3% Spieler unter Linux? Davon waren 2% bereits unter Windows vertreten. Das bringt ihnen nicht mehr ein. Das ist aber ein gewinnorientiertes Unternehmen, also muss jede Ausgabe gedeckt werden. Anders gehts nicht.
 
Du schreibst das so locker weg. Dann tu mir doch als Wine-Nutzer den Gefallen und schreib mir gerade mal die Proton-Verbesserungen in die letzte Wine-version und schick mir das heute Nachmittag. Ich teste dann wie es läuft und schildere es hier.
Geht nicht so einfach? Wozu? Genau das habe ich beschrieben. dass ich eben diese Reaktion befürchte.
Zwischen "das wird keiner machen" und "ein beliebiger Nutzer aus einem Forum wird das an einem halben Tag machen" gibt es schon noch ein bisschen Spielraum...
Was denkst speziell du, wie Valve sich das Geld wiederholen zu gedenkt? Die 3% Spieler unter Linux? Davon waren 2% bereits unter Windows vertreten. Das bringt ihnen nicht mehr ein. Das ist aber ein gewinnorientiertes Unternehmen, also muss jede Ausgabe gedeckt werden. Anders gehts nicht.
Ich glaube das mit der Deckung von Ausgaben ist bei Valve kein Problem und da die nicht an der Börse sind und dementsprechend keine Leute im Nacken haben, die eine kurzfristige Gewinnmaximierung erzwingen, können sie halt langfristige Entscheidungen treffen. Newell ist halt schon länger skeptisch gegenüber Microsoft und die Abhängigkeit von Microsoft, bzw. wiederum deren Aktionären ist eine der größten Gefahren für das Geschäftsmodell von Steam.

Außerdem wäre eine Plattform wie das Steam Deck ohne Linux spätestens zu dem Zeitpunkt kaum möglich gewesen und ich würde mal behaupten, dass die daran schon auch ein bisschen was verdient haben. Das gleiche wird vermutlich für das Frame in der angekündigten Form gelten.
 
Eben nicht. Ich hab doch ganz klar geschrieben, dass meine Befürchtung darauf basiert, dass es im fall der Fälle eben nicht jemand selbst in die Hand nimmt und ein eigenes proton-äquivalent zusammenstellt.

Wine entwickelt sich weiter, aber nicht so wie früher. Wine läuft hinterher. Wir reden ja nicht über die Funktionalität von Wine als solchem, da tut sich schon noch einiges, sondern meine Anfrage hier fing an mit der Spieletauglichkeit. Wine ist bei vkd3d auf version 1.19, während proton bereits bei 2.14.1 spielt, richtig?
Es wird gesagt, proton bezieht sich und seine Versionsnummer immer auf den letzten stabilen Stand von Wine, aber die eigenen Anpassungen machen eben sehr viel aus.
Nimm mal "nur" wine zum spielen und stell im Spiel rt an oder aus. Dann landest du, abhängig vom Spiel, ganz schnell auf dem Desktop, während es mit proton weiterläuft.

Du schreibst das so locker weg. Dann tu mir doch als Wine-Nutzer den Gefallen und schreib mir gerade mal die Proton-Verbesserungen in die letzte Wine-version und schick mir das heute Nachmittag. Ich teste dann wie es läuft und schildere es hier.
Geht nicht so einfach? Wozu? Genau das habe ich beschrieben. dass ich eben diese Reaktion befürchte.

Linux nutze ich seit knapp 20 Jahren und die Spielefähigkeit hat sich in den ersten 15 Jahren kaum bewegt. Erst zuletzt und dank Valve tat sich da wirklich immens etwas.

Was denkst speziell du, wie Valve sich das Geld wiederholen zu gedenkt? Die 3% Spieler unter Linux? Davon waren 2% bereits unter Windows vertreten. Das bringt ihnen nicht mehr ein. Das ist aber ein gewinnorientiertes Unternehmen, also muss jede Ausgabe gedeckt werden. Anders gehts nicht.
Also ich habe natürlich keinen Einblick in die Kosten, aber ich denke es gibt mindestens zwei Argumente warum das Valve macht:

- Risikomanagement: Sie machen es um Microsoft nicht ausgeliefert zu sein (ja ich weiss, wie können sie Nutzer nicht einfach auf Linux umstellen. Aber man braucht Alternativen um sich nicht komplett abhängig zu machen)
- Finanzierung: Jedes Valve Gerät ohne Windows spart eine Windows Lizenz. Natürlich weiss ich nicht, wie viel das ausmacht und ob es die Proton/SteamOS Entwicklungskosten komplett gegenrechnet. Aber könnte langfristig schon Sinn machen
 
Man darf ja auch nicht vergessen, dass sich Windows immer mehr zum Cloud-OS entwickelt.
Ganz anders als valves steam, dass deine Spielstände und Fortschritte nur auf deinem System hinterlegt und nicht standardmäßig in der cloud...
Außerdem wäre Microsoft nicht der erste OS-Anbieter, der auf die Idee kommt, bei Drittanbietern die Hand aufzuhalten.
Ganz anders als valves steam, die nicht 30% für gar nichts von den Entwicklern erpressen, oder mir vorschreiben mit welcher Version eines Spiels ich glücklich zu sein habe...
 
War das mit dem Vorschreiben jemals ein Problem? Cloud-Sync kannst bei Bedarf deaktivieren. Und, hey, man kann ja bei Ubi oder Epic oder bei MS Vertreiben lassen. Niemand zwingt zu Steam. Wahlfreiheit und so sind gegeben.

Aber was hat das alles mal wieder mit den Startoptionen für Proton zu tun? :ka:
 
Dies kann man in den Einstellungen vollständig Deaktivieren in Steam, seit langem bekannt.
Hab ich etwas gegenteiliges geschrieben?
Du hast doch meine Wortwahl sogar noch fett geschrieben.
Valve (über die diakut wir) hält es aber standardmäßig als aktiv für richtig.
Aber was hat das alles mal wieder mit den Startoptionen für Proton zu tun? :ka:
Das weiß ich auch nicht. Empy kam mit cloud Diensten und Windows um die Ecke. Ich hab nur darauf reagiert um nicht unhöflich zu sein.
 
Das weiß ich auch nicht. Empy kam mit cloud Diensten und Windows um die Ecke. Ich hab nur darauf reagiert um nicht unhöflich zu sein.
Ja, als Grund dafür, warum Valve an einer Alternative für Windows festhalten wollen könnte. Weil du irgendwie die ganze Zeit einen Grund dafür suchst, warum Valve Proton und den allgemeinen Linux-Support bestimmt bald einstampfen wird.
 
Ich traue valve bedeutend weniger als Microsoft und denen traue ich schon nicht weit. Deshalb interessiert mich, wie gut es ohne valve geht. Auf windows ist es nicht tragisch, darauf zu verzichten. Valve ist der Grund warum wir heute DRM haben und es überhaupt zu sowas wie kernelaccess Lösungen kommen konnte und ich fände es sehr schade wenn Linux auch dahin gebracht wird.
Das ist auch mein Eindruck, aber wie es eben so mit Eindrücken ist, sind die subjektiv und mich würde eine neutrale Bewertung interessieren.

Mit wine habe ich schon viel Erfahrung gesammelt über die Jahre. Angefangen mit dem gothic 3 Release damals 2006.


Irgendwie erinnert sich mein früheres, hochseefahrendes „Piratenhirn“ deutlich anders an die 90er und frühen 2000er: DRM war lange vor 2004 und dem Launch von Steam in Verbindung mit Half-Life 2 schon ziemlich verbreitet. (Seit meinem 10. Geburtstag im September ’92 auf dem PC unterwegs – zufällig im selben Monat wie die Erstausgabe der PC Games.)
Wenn man es historisch sauber trennt, muss man zwischen dem Begriff „DRM“ und der Praxis unterscheiden, Nutzungsrechte technisch durchzusetzen. Der Begriff selbst kommt erst Ende der 90er/Anfang der 2000er auf und wird vor allem durch die Musikindustrie geprägt, etwa rund um SDMI und später Plattformen wie Apples iTunes Store mit „FairPlay“. Dort wird „DRM“ überhaupt erst breit verwendet. Die Praxis ist älter. In Spielen sprach man in den 90ern noch von Kopierschutz, funktional ist das aber bereits DRM: SafeDisc (ab 1998) und SecuROM (Ende der 90er) setzen genau das um – Zugriff nur unter bestimmten Bedingungen. Anfang der 2000er kommen dann mit Systemen wie SecuROM Online Activation bereits serverbasierte Aktivierungen dazu, also genau das Prinzip, das später oft Steam zugeschrieben wird.
Valve ist also weder beim Begriff noch bei der Praxis der Ursprung. Steam bündelt und vereinheitlicht das nur in einer Plattform. Wenn man, aber deinen Einwand weiterdenkt, geht es vermutlich weniger um „wo kommt DRM her?“, sondern wohl eher darum, ob genau diese Bündelung durch Bequemlichkeit wieder akzeptabel wird? Und da wäre meine eigentliche Frage: Geht es dir darum, dass sich so etwas unter Linux wiederholt? Und wenn ja, was genau bereitet dir daran Sorgen – gerade wenn man sich anschaut, unter welchen Lizenzmodellen Proton selbst steht (GNU LGPL v2.1 oder später, 3-Klausel-BSD, zlib-Lizenz)?
 
Ein Spiel welches ich damals gekauft habe und SecuROM nutze, kann ich heute einlegen, installieren, die standalone patches drüber bügeln, ggf.. exe manipulieren und spielen.

Jetzt geh aber mal ins Netz, lösche dein steam Konto, dann setz deinen Rechner neu auf und installiere Spiel X mit Patchversion Y.

Geht's, oder geht's nicht?
Das hat steam eingeführt. Das Nutzungsrecht hattest du selbst bei SecuROM, nur musstest du nachweisen auch den datenträger zu haben.
 
Ein Spiel welches ich damals gekauft habe und SecuROM nutze, kann ich heute einlegen, installieren, die standalone patches drüber bügeln, ggf.. exe manipulieren und spielen.

Jetzt geh aber mal ins Netz, lösche dein steam Konto, dann setz deinen Rechner neu auf und installiere Spiel X mit Patchversion Y.

Geht's, oder geht's nicht?
Das hat steam eingeführt. Das Nutzungsrecht hattest du selbst bei SecuROM, nur musstest du nachweisen auch den datenträger zu haben.
Ich verstehe deinen Punkt mit Datenträger + Patch und der damit verbundenen Unabhängigkeit. Aber ganz so romantisch war das in der Praxis auch nicht. Optische Medien sind kein besonders langlebiges oder zuverlässiges Archivmedium – Stichwort Disc-Rot, alternde Kunststoffe, zerkratzte Datenträger. Dass eine Sammlung nach 20 Jahren noch vollständig und problemlos funktioniert, ist eher Glück als Regel. Ich persönlich bin ehrlich gesagt froh, dass ich mir das nicht mehr ins Regal stellen muss – wenn ich (bei den heutigen Preisen für Wohnraum) Platz investiere, dann lieber in etwas, wo sich Haptik auch wirklich lohnt. Sprich: Bücher, gerne auch Schallplatten (samt ihrer großen Cover-Booklets), aber bitte keine DVD-Hüllen. Wenn schon ein physisches Medium, dann muss es sich auch lohnen, physisch zu sein. Software auf Disc ist primär Transportmedium, nicht Erlebnisobjekt.
Bücher und Platten sind für meinen Geschmack hingegen haptisches Erlebnis + Objekt.

Klar, theoretisch gehört dir mit Datenträger die Software unmittelbarer. Praktisch war das aber oft mit viel Reibung verbunden: unterschiedliche Kopierschutzsysteme, Patches zusammensuchen, Versionen, die ohne bestimmte Updates gar nicht stabil liefen. Heute hast du dafür eine stärkere Bindung an Accounts, aber eben auch deutlich mehr Komfort – zentrale Bibliothek, einfache Updates, kein Medienwechsel, kein physischer Platzbedarf. Dazu kommen Dinge wie Sales oder Keys, die den Zugang zusätzlich erleichtern. Für mich ist das weniger ein klarer Verlust als eine Verschiebung: weniger klassische technische Kontrolle, dafür deutlich weniger Friktion im Alltag.

Und was die Sorge angeht „was ist, wenn der Dienst irgendwann weg ist?“: Die kann man haben, aber sie wirkt auf mich oft etwas prepper-mäßig überzogen. Wenn eine Plattform wie Steam nach Jahrzehnten und all den Investitionen tatsächlich komplett verschwinden würde, hätten wir vermutlich ganz andere Probleme als unsere Spielebibliothek.
Und ganz ehrlich: Meine ISO-Sammlung liegt natürlich trotzdem auf dem NAS im Keller.
 
Zuletzt bearbeitet:
Ein Spiel welches ich damals gekauft habe und SecuROM nutze, kann ich heute einlegen, installieren, die standalone patches drüber bügeln, ggf.. exe manipulieren und spielen.

Jetzt geh aber mal ins Netz, lösche dein steam Konto, dann setz deinen Rechner neu auf und installiere Spiel X mit Patchversion Y.
Solang du vor dem löschen des Kontos die Dateien irgendwo hin weg kopiert hast wäre das Vorgehen identisch zur alten CD.
Dateien rüber kopieren, DRM freie Exe besorgen und los geht's.
 
Das Nutzungsrecht hängt aber am launcher. Kein Konto mehr, keine Nutzung erlaubt. Genau das ist bei den alten CDs anders. Du hast sie, also darfst du sie zum laufen bringen.
 
Zurück