Steam auf Ubuntu vorerst gerettet, Valve aber dennoch "nicht glücklich"

Am vergangenen Wochenende gab es für eine ganze Reihe von Steam-Nutzern einen einigermaßen großen Schock. Denn nach einer An­kün­di­gung von Ubuntu-Anbieter Canonical zum Support von 32-Bit-Bib­lio­the­ken teilte Valve mit, dass ... mehr... Steam, Linux, Videospiele Bildquelle: Valve Steam, Linux, Videospiele Steam, Linux, Videospiele Valve

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
na geht doch
 
Spiele sind Kunst und auch erhaltenswert deswegen frage ich mich warum die Linux community dieses ausradieren will.
 
@Menschenhasser: Ich hoffe, du trollst nur. Die Linux-Community radiert keine Spiele aus, sie entwickelt ihr System weiter und die herrenlosen alten Videospieltitel, bei denen sich keiner mehr kümmert (und keiner mehr freiwillig kümmern kann, weil sie proprietär sind), halten nicht Schritt.

Sie brauchen eben langfristig eine Sandbox in welcher der Fortschritt eingefroren wird, um weiter ausgeführt werden zu können. Dafür gibt es schon verschiedene Ansätze.
 
@dpazra: Es ist doch egal wie alt die Spiele sind. Das ist für mich einfach eine ausrottung von Kunst und diesen Vorwurf gebe ich an die Linux Community weiter weil die nichts daran ändern.
 
@Menschenhasser: Die freie Softwarecommunity tut definitiv mehr als jede andere Gruppe zur Erhaltung alter Computerspiele. Allein durch RetroArch bleiben locker 50 Plattformen für Spiele zugänglich, die man längst nirgendwo mehr kaufen kann, und entwickelt immer noch neue Features für die Nutzung solcher Titel (z.B. OCR). Und auch Win32-Spiele gehen hier nicht verloren, wie du leicht herausfinden könntest, wenn du dieses Thema aktiv verfolgen könntest.
 
@dpazra: Und ist das so schwierig das System so weiterzuentwickeln, dass man dadrauf auch ältere Software laufen lassen kann, wenn man das muss oder möchte? Auf Windows 10 kann ich die meisten halbwegs vernünftig für Windows 95 programierten Anwendungen ausführen, es scheint also nicht gerade unmöglich zu sein über 25 Jahre das System zumindest grundsätzlich kompatibel zu halten.
 
@Link: Auf aktuellen GNU/Linux-Distributionen läuft nach wie vor extrem alte Software, z.B. GNU bc (Rechenprogramm) von 1991 und sicher noch viel ältere Software, die Sache ist eben, dass wir in der GNU/Linux Welt von freier Software sprechen und es kein Problem ist sie neuzubauen und neu gegen die Bibliotheken zu linken wenn sich das Binärinterface ändert.

Ob die Abwärtskompatibilität von Windows 10 so gut ist, wäre noch zu diskutieren. Ansonsten denke ich nicht, dass es der richtige Ansatz ist, die Systembibliotheken mit einem endlosen Versionsbacklog aufzublähen, das ist nämlich auch alles Angriffsfläche. Der bessere Ansatz besteht imho in Sandboxen mit dauerhaft kompatiblen Interfaces, in denen Legacy-Software ausgeführt werden kann. Das ist auch der Ansatz, der derzeit in der GNU/Linux-Welt für Software verfolgt wird, die nicht den Ansprüchen an Pflege und Aktualität genügen, die an die übliche Software aus dem Paketmanager gestellt werden.
 
@Menschenhasser: Da verwechselt jemand die Linux-Community mit Canonical (Ubuntu)!
 
Valve nennt bereits als bessere alternative Linux Distributionen für Spiele und Spieler Manjaro Linux und Pop!_OS. Beide Linux Systeme werden weiterhin 32-Bit-Bibliotheken pflegen und sind bereits in den vergangenen Monaten immer wieder anstelle von Ubuntu für Spiele von Valve empfohlen worden, weil diese wenig Konfigurationsaufwand beim Einrichten für dieses Einsatzgebiet erfordern. Für Spieler bleibt Linux ungeachtet des Canonical-Durcheinander somit eine mittlerweile gangbare Wahl.

Generell ist bei einer Gamer Linux Distribution wichtig, dass ein aktueller Kernel mitgeliefert wird, man einfachen Zugang zu neuen Userspace-Grafiktreibern (Mesa), unfreien Treibern hat und man sich einfach mit den Werkzeugen und Pfaden für die Systemkonfiguration zurechtfindet.
Das ist z.B. etwas, was Ubuntu nach unnötig kompliziert macht, indem Standardmethoden des Systemmanagements abgewandelt werden (Systemd kompatibel mit dem Uraltstandard SysVInit, dpkg-reconfigure XXX anstatt ändern der entprechenden Dateien in etc, ...
Das ist bei Manjaro wesentlich einfacher für Gamer geregelt.

https://manjaro.org/

Mit Pop! OS habe ich mich bisher noch nicht auseinander gesetzt, werde es aber auch mal testen:
https://system76.com/pop
 
@ContractSlayer: Pop!_OS verwende ich seit einiger Zeit auf meinem Laptop und finde es recht angenehm zu bedienen :) Für Leute die ansonsten Windows nutzen auf jeden Fall eine interessante Alternative.
 
Das ist definitiv nicht das Ende dieser Geschichte, weil hier ein viel grundlegenderes Problem drin steckt. Die Art und Weise, wie eine übliche GNU/Linux-Distribution wie Ubuntu funktioniert ist fundamental inkompatibel mit der Funktionsweise von Steam. Für dieses Problem gibt es einen sinnvollen Lösungsansatz, aber dazu am Ende mehr.

GNU/Linux ist im Prinzip eine Menge von verschiedenen freien Softwareprojekten, die jeweils verschiedene Entwickler haben können. Wenn eine Gruppe von Entwicklern diese ganze verschiedene Software kompiliert, verpackt, zusammenstellt, mit Konfigurationsdateien versieht, dann entsteht daraus eine konkrete GNU/Linux-Distribution wie Ubuntu.
Die Ubuntu-Macher gucken, wenn sie eine Version einer Bibliothek A zu einem Paket verpacken, dass es erst in die Distribution kommt, wenn alle Programme B, C und D mit der neuen Version kompatibel ist und wenn die ursprünglichen Entwickler von Programm C schlafen, dann patchen die Ubuntu-Macher das Programm C vielleicht selber und geben es als neues Paket an die Ubuntu-Nutzer weiter. Wenn Programm D eine Sicherheitslücke hat und der Entwickler von Programm D nicht schnell genug patcht, dann patcht es vielleicht das Ubuntu-Sicherheitsteam und bringt ein Paketupgrade für dieses Programm.
Jedes Paket hat stets einen Maintainer, der es neu bauen kann, wenn das nötig wird.

Da alles freie Software ist, funktioniert dieses System. Die Ubuntu-Macher können sich natürlich koordinieren, so dass sie alles Software so bauen, dass sie nicht mehr von 32-Bit-Paketen abhängig ist (idealerweise muss man dafür nur mit anderen Parametern neu kompilieren, in der Praxis können manuelle Anpassungen dort nötig sein, wo 32-Bit-spezifischer Code verwendet wurde). Jedes

Steam ist das komplette Gegenteil. Eine Sammlung weitgehend proprietärer Software, die weitgehend keine Updates mehr kriegt (welcher Nicht-E-Sport-Titel kriegt nach 5 Jahren noch Updates?). Wenn ein Spiel wegen einer neuen Bibliotheksversion nicht mehr funktioniert, wer baut es neu? Entweder der ursprüngliche Entwickler oder niemand, weil niemand den Quellcode hat. Wäre Steam eine GNU/Linux-Distribution, würden diese ganzen Titel, die mit 64 Bit Bibliotheken nicht funktionieren neu gebaut werden oder wegen Herrenlosigkeit (niemand kümmert sich mehr um Updates) aus dem System fliegen.

Ubuntu (und die GNU/Linux-Welt insgesamt) wird sich weiterentwickeln und immer wieder mit der Abwärtskompatibilität brechen, so dass es immer wieder Probleme mit alten Titeln geben wird. Die Lösung ist eine definierte Laufzeitumgebung mit der die Spiele in einer Sandbox mit ihren veralteten, unsicheren Bibliotheken laufen könne, soetwas wie Flatpack oder Snappy. Das ist nicht nur die Lösung für Spiele, sondern allgemein für proprietäre Software unter GNU/Linux, die den Distro-Maintainern keine Möglichkeit lässt, ein Problem zu lösen, dass mit den Upgrades anderer Pakete entsteht und deren Entwickler nicht imstande oder nicht willens sind, sich ausreichend um ihre Software zu kümmern um mit einer veränderlichen Systemumgebung schritt zu halten.
 
@dpazra: Deine Betrachtung ist richtig, es bleibt aber dabei, dass Ubuntu hier ein Betriebssystem ist und ein Betriebssystem kann man durchaus danach bewerten, wie gut es Software ausführen kann. Nicht mal bei quelloffener Software hat man die Entschuldigung, das 32-Bit-System rauszuwerfen, immerhin hat nicht jeder Nutzer Bock oder das technische Vermögen, Zeug neu zu kompilieren. Die offiziellen Paketquellen sind keine sinnvolle Lösung da Software dort entweder hoffnungslos veraltet oder schlichtweg mal nicht da ist (habe beides erlebt und als professioneller Softwareentwickler war Kompilieren unter Linux eine Herausforderung mangels irgendeiner Dokumentation außer "Du weißt schon, was zu tun ist"). Für Software ohne Quellen ist die Diskussion komplett hinüber. Das Statement bleibt aber, wenn Ubuntu den Anspruch erhebt, ein Betriebssystem zu sein und nicht nur eine Sammlung an kompiliertem quelloffenen Code, gibt es Ansprüche zu erfüllen. Einer von denen ist Kompatibilität. Wenn es wenigstens Sicherheitsgründe gäbe, eine API (oder ABI, im Linuxumfeld muss man oft explizit "ABI" sagen) abzuändern oder abzuschaffen, ok. Moralisch vertretbar. Aber mehr oder minder aus Spaß an der Freude den Nutzern einen Stock in die Speichen zu werfen ist nicht lustig.

Was du hier als Lösung beschreibst, ist arg windowsartig: Jeder bringt sein Zeug selber mit. Mit dem Ergebnis, dass man als tüchtiger Spieler irgendwann 20 Kopien derselben Bibliothek hat. Dabei hätte Linux das Potenzial, BESSER zu sein, als Windows. Erstens müsste man dazu die Binärkompatibilität aufbohren. Es gibt keinen vernünftigen Grund, warum Version N+1 einer Bibliothek kein drop-in-Ersatz für Version N sein kann. Man muss Rückwärtskompatibilität nicht brechen, jedenfalls nicht so dauernd, wie es das gesamte Linuxumfeld als Tugend betrachtet. Dann würde jedes Spiel ganz simpel eine Reihe an Abhängigkeiten auflisten, die über die Linux-Desktop-Kern-ABI hinausgehen und der Paketmanager kümmert sich um den Rest (wie es Steam aktuell zu gewissen Teilen unter Windows macht). Neben der besagten Binärkompatibilität wäre auch die Aktualität ein Thema. Gerade Ubuntus Quellen sind lächerlich veraltet, ein Spiel erst ein halbes bis ganzes Jahr nach Erscheinen zu spielen, weil es eine Version einer Bib nutzt, die es noch nicht in den Paketquellen gibt, macht keinen Spaß.

Nur noch das 32-Bit-Subsystem zu der besagten Desktop-Kern-ABI dazupacken, das ganze ordentlich dokumentieren mit einem "Wenn du dich dran hältst, wird dein Programm auch noch 10 Kernel-/Distributionsreleases später ohne Anpassungen laufen"-Disclaimer und viola, Problem gelöst.
 
@Kirill: Ok, da sind ja jetzt ein paar Themen aufgekommen.

1. Offizielle Paketquellen sind keine sinnvolle Lösung da Software dort entweder hoffnungslose veraltet oder schlichtweg mal nicht da ist.

Das stimmt nur bedingt. Die Software in z.B. Ubuntu, Debian und RHEL/CentOS sowieso ist immer veraltet. Das liegt daran, dass das Point Release Distributionen sind. Das ist das Modell für "Ich setze meinen Server auf und drücke 1, 5, 7, 10 oder 13 Jahre lang auf "Update" ohne, dass irgendetwas die Rückwärtskompatibilität bricht oder ich irgendetwas wegen einer neuen Softwareversion anpassen muss, aber mit allen Sicherheitsupdates und kompatiblen Bugfixes. Genau deshalb können Entwickler proprietärer Software aber auch ein Paket z.B. für Ubuntu 18.04 packen und das funktioniert in 2 Jahren (wahrscheinlich) immer noch.

Würde ich für den Desktop so nicht haben wollen, da will ich neue Software sofort, deshalb nutze ich Arch, aber es gibt auch noch Manjaro, Tumbleweed, etc.

Genauso ist es mit den Paketen. Die weiter oben genannten Distros haben das Modell, dass man etwas aus den Paketen installiert und das ist dann von den Distromachern so abgeseegnet, es funktioniert, es ist mit allen anderen Paketen kompatibel etc. Wenn die Distro den eigenen Anwendungszweck nicht so gut abdeckt, gibt es noch Zusatzrepos für einzelne wichtige Pakete, Backports, oder eben (was ich als Desktopuser sinnvoller finde) Distros wie Arch mit vielen Userpaketen. Und dann gibt es noch Flatpak/Snappy/Docker, etc. wenn man Software nicht in Paketen findet und nicht selber bauen will.

2. API/ABI
Ja, in der freien Softwarewelt ist API natürlich meistens gut genug, weil es in der Regel kein Problem für den Maintainer ist, ein Paket bei reinen ABI-Veränderungen neu zu bauen.

3. Abwärtskompatibilität
Abwärtskompatibilität zu brechen ist an sich keine Tugend, aber es ist eine Tugend, Fehler zu korrigieren und manche Fehler liegen im Design eines Interfaces. Dann wird das schlechte Interface Deprecated und irgendwann entfernt. Wenn man das nicht macht, dann wird es weiter genutzt werden, weil irgendjemand googlet, wie man ein Problem löst und auf alte Code Samples stößt. Und es ist auch nicht gut, eine Bibliothek immer weiter aufzublähen und alles drinzulassen. Irgendwann ist der Entwickler weg, der den alten Code versteht und in all dem alten Code, den keiner mehr ließt, schlummern auch immer Sicherheitslücken, die irgendwann zutage kommen.
Nein, die Bibliotheken die mein nginx-Server oder mein OpenSSH Dienst benutzt, sollen bitte möglichst übersichtlich für ihre Entwickler bleiben, da hätte ich ungern 15 Jahre Backlog an Sicherheitslücken in weitgehend ungenutzten Codekomponenten, die irgendwann entdeckt werden.

Deshalb sage ich, es soll 2 Klassen von Software im Userland geben: Die Distribution an sich mit immer gut gepflegter, freier Software, gebaut von den Machern meiner Distro mit tagesaktuellen Sicherheitsupdates, nicht zurückgehalten durch Abwärtskompatiblität und immer als ganzes geupdatet. Da erwarte ich eine deutlich bessere Adminexperience als unter Windows.
Und der zweite Punkt ist eine dauerstabile, distributionsunabhängige Laufzeitumgebung a'la Flatpak oder Snappy für Software, die von woanders kommt, die nur in einer Sandbox ausgeführt wird und die für immer von Legacy-Code abhängig sein kann. Denn davon reden wir bei Spielen. Eine Plattform für Computerspiele zu bieten, bedeutet dass auch in 10 Jahren noch jemand versehentlich den Deus-Ex-Soundtrack auf YouTube anklickt und dann eine DirectX-7-Anwendung auf seinem System von 2029 installieren möchte. Dass soll er gerne machen können, aber der ganze unschöne Kladderadatsch der dafür im Hintergrund nötig sein wird, soll bitte vom Rest des Systems abgetrennt laufen und den zu managen, soll nicht die Aufgabe des gleichen Menschen sein, der dafür sorgt, dass keine Malware ausgführt wird, wenn ich eine böswillig manipulierte Videodatei anklicke.
 
@dpazra: 1. Es wäre technisch und logistisch möglich, Software in Paketquellen aktuell zu halten. Scheiße, sogar MS schafft es in seinem Store, eine aktuelle Fassung der Arduino-IDE anzubieten und die Linuxwelt hat Jahrzehnte mehr Erfahrung (und tendenziell den besseren technischen Unterbau) in Sachen Softwareverteilung. Wenn ich allerdings ohnehin selbst runterladen (und je nachdem, wie viel Pech ich habe, selber kompilieren) darf, kann man die Paktetquellen auch lassen und Linux fällt auf den Stand von Windows, wenn nicht schlechter, wo aktuell Valve das von mir in 4. beschriebene System nachrüstet, weil MS selber in Sachen zentraler Softwareverwaltung Jahrzehnte hinterherhinkt.
2. Schön für den Maintainer. Wenn ich aber selber gebaut habe, weil die Paketverwaltung veraltet ist (s.o.) oder wenn es keine Quellen gibt, fällt das Konzept in sich zusammen. Zumal eine stabile ABI kein Ding der Unmöglichkeit ist sondern ein Ding des Willens. Zugegeben, ich habe auch schonmal, meinen Abnehmern zuliebe, sagen wir weniger ästhetischen Code gebaut, als mir lieber gewesen wäre, mit einer ordentlichen Codestrukturierung schafft man aber Wartbarkeit (das einzig wahre Schönheitskriterium für Code) und eine nach außen hin stabile ABI. Man muss es nur wollen. Abgesehen davon schafft eine instabile ABI in der Praxis Sicherheitslücken. Beispiel aus der Uni: Die Laborrechner laufen mit Linux (wegen mir weil es objektiv besser ist, im wesentlichen aber weil es kostenlos ist) und wie es im Labor schon mal passiert, läuft darauf LabView und der NI-Treiber für die Messhardware. Mangels stabiler ABI läuft darauf aber ein uralt-Kernel, damit der Treiber glücklich ist. inklusive uralt-Sicherheitslücken. Das Modell von Linux funktioniert in der Theorie (wo es hingehört) und stockt in der Praxis unangenehm.
3. S.o. Abwärtskompatibilität ist eine Sache von wollen. Bibliothek aufblähen? Lager halt die ganze neue Funktionalität in eine neue Bibliothek aus. Oder baue die ganze Bib um, während du altes Verhalten auf der neuen Implementierung emulierst. Alte Entwickler weg? Erstens, Dokumentation. Löst die meisten Probleme. Zweitens, übersichtlicher Code. Mit diesen beiden Methoden kann ein jeder neuer Entwickler sich einarbeiten und Sicherheitslücken schließen. Das wiederum hängt vom Willen ab und nicht von grundsätzlicher Machbarkeit.
4. Wenn man die Verwaltung von Laufzeitumgebungen im Systemkern hat, hat es gewisse Vorteile. Gerade das uralte DX7-Spiel ist da ein tolles Beispiel. Wenn das Spiel sein DX7 (bzw. eine beliebige Bib von 2009) mitbringt, kannst du dir Sicherheitslücken absolut sicher sein. Wenn das Spiel allerdings im Manifest "Ich brauch Bib XAC" hat, kann das System sich darum kümmern, dass Bib XAX auch runtergeladen wird und zwar in einer aktuellen Version mit sämtlichen (bekannten) Lücken geschlossen. Setzt natürlich voraus dass der Entwickler in seiner unendlichen Weisheit (lies: Ignoranz) die Bib während der Zeit nicht inkompatibel verbockt hat, mehr dazu s.o.
 
@Kirill: Zu 1. Ich war anscheinend oben zu unklar: Ja, man kann die Software aktuell halten. Wird auch gemacht, die Distribution heißt ArchLinux (oder Manjaro, etc.). Ubuntu ist ein anderes Produkt. Ubuntu ist eine Point Release Distribution. Wenn du immer aktuelle Pakete haben möchtest, ist Ubuntu das falsche Produkt für dich. Ubuntu ist das Produkt für denjenigen, der jeden Tag "Update" drücken will um sein System sicher und möglichst fehlerarm zu halten, aber immer die gleichen Software-Major-versionen behalten will.

Es gibt natürlich Ausnahmen, man kann selektiv Backports oder andere Repositories benutzen, um einzelne Pakete unter Ubuntu aktueller zu halten, aber wenn man von allem die neuste Version haben will, ist Ubuntu das falsche Produkt. Ubuntu ist das richtige Produkt für jemanden, der nach einem Paketupdate keine neue Oberfläche in Office haben will, weil LibreOffice plötzlich von Version 3 auf 4 geupdatet wurde oder keine neue Oberfläche in GNOME sehen möchte, weil Gnome plötzlich von Gnome 3 auf 4 geupdatet wurde. Wer das will, braucht Arch oder Manjaro oder so.

2. Ja, ABI-Änderungen sind ein Problem, wenn die Paketverwaltung nicht gut läuft oder man ein Produkt einsetzt, das für die eigenen Bedürfnisse nicht das richtige ist (siehe Punkt 1).

3. Ja, mit genug Resorcen, kann man ewige Rückwärtskompatibilität mit optimaler Wartbarkeit vereinbaren, mit genug Resourcen kann man auch fehlerfreie Software schreiben (ist ein reines Wahrscheinlichkeitskalkül, wieviele Audits hintereinander ein Bug übersehen werden kann). Fakt ist, Resourcen sind endlich und offenkundig ist man bei den meisten Free Softwareprojekten der Meinung, dass Resourcen effizienter eingesetzt werden, wenn man die Komplexität gering hält, indem altes auchmal rausfliegt oder ersetzt wird und auf ABI-Kompatibilität weniger Rücksicht genommen wird. Das kann ich nachvollziehen, wie weiter oben erläutert, bedient GNU/Linux in erster Linie eine Zielgruppe, die auf freie Software setzt und für diese Zielgruppe ist ABI-Kompatibilität nachrangig.

Im Übrigen heißt ABI- (manchmal auch API-)Rückwärtskompatibilität oft genug auch "Bug-Kompatibilität" die Dokumentation und das Protokoll sagen das eine (logische), die Software tut in bestimmten Ausnahmefällen aber das andere (ich glaube die Samba-Leute kennen sich damit aus, unter Linux gibt es auch eine lange Liste von Hardware-Quirks). Manche Nutzer der Schnittstelle erkennen die Bugs und stellen sich darauf ein (hängen von ihnen ab), andere benutzen die Schnittstelle, wie sie beabsichtigt war (und haben deshalb schlummernde Bugs im Verhalten ihrer Software obwohl ihr eigener code korrekt ist). Schon alleine deshalb gibt es keine ewige ABI-Stabilität, manchmal muss etwas kaputt gehen, damit etwas anderes heile wird.

4. Ja, siehe 3. Software ist ein Stack, wenn man das korrigiert, was in der Mitte mal kaputt war, funktioniert das eine richtig was darüber liegt und beim anderen greifen die Krücken ins leere, ich denke wirlich nicht, dass es möglich ist, DX7-DLLs zu bauen, die alle alten Fehler beheben, ohne dass dabei alte Spiele kaputt gehen, die darauf basieren, es sei denn da steht am Ende drin "if caller == quake || caller = unreal1) broken_behavior1(); else broken_behavior2();... Wer soll das freiwillig programmieren und dauerhaft warten und wer soll wen mit welcher Profitaussicht dafür bezahlen? Und diese Komplexität will ich nicht in meinen Systembibliotheken haben, das kann schön abgetrennt in der Sandbox laufen, dann sind mir auch die Sicherheitslücken egal.
 
Was ist bittesehr eine "Auswahl"? Ich hätte einen ganz einfachen Lösungsvorschlag. Den GESAMTEN Satz an Bibliotheken, die zur userspace-ABI gehören, in 32 Bit behalten. Wenn jemand eine Extrawurst brauchen, soll er es selbst mitliefern.
 
Linux spielt für die Spielekultur eher eine geringe bis gar keine Rolle.
Nur Valve hat einiges aus ihrem Hardware Portfolio leider darauf gesetzt.
 
@Postman1970: Der Gegenstand der News sind ja Bemühungen das zu ändern. Diese Bemühungen laufen seit einigen Monaten auf Hochtouren: https://www.protondb.com/explore?page=0&sort=playerCount
 
Das ist ja alles eher für Casual User bzw als "Verkaufsargument" für Steam interessant. "unterstützt" heißt ja nur, das es von Valve/steam quasi empfohlen wird.

Bei mir läuft Steam (Steam Play /windows api usw) zb problemlos unter Slackware, auch mit relativ aktueller Nvidia Grafik (gtx 1080).

Interessant ist übrigens, das von meinen >120 Spielen schon 75 Linux native unterstützen.

Ohne sytemd, ohne Abhängigkeitcheck usw (gibt es bei slackware nicht).
Wichtig ist halt, das die Distro multilib unterstützt, und da hat Ubuntu/canonical halt verkackt mit ihrer Entscheidung.

Valve wird irgend eine User-friendly distro mit guter Wartung/Verbreitung aussuchen, diese als "unterstützt" labeln und gut ist. Dann wird die Sache auch auf allen anderen Distros laufen, solange die multilib unterstützen.
Kommentar abgeben Netiquette beachten!
Einloggen

Jetzt als Amazon Blitzangebot

Ab 15:35 Uhr Yamay Fitness Armband mit Blutdruckmessung,Smartwatch Fitness Tracker mit Pulsmesser Wasserdicht IP68 Fitness Uhr Blutdruck Messgeräte Pulsuhr Schrittzähler Uhr für Damen Herren Anruf SMS SNS BeachtenYamay Fitness Armband mit Blutdruckmessung,Smartwatch Fitness Tracker mit Pulsmesser Wasserdicht IP68 Fitness Uhr Blutdruck Messgeräte Pulsuhr Schrittzähler Uhr für Damen Herren Anruf SMS SNS Beachten
Original Amazon-Preis
34,99
Im Preisvergleich ab
34,99
Blitzangebot-Preis
27,83
Ersparnis zu Amazon 20% oder 7,16
Im WinFuture Preisvergleich