Valve plant offiziellen Support für Ubuntu ab 19.10 einzustellen

DrCox1911

Lt. Junior Grade
Registriert
Juni 2018
Beiträge
503
Laut einem Twitter-Post von Pierre-Loup Griffais, Entwickler bei Valve wird Ubuntu ab Version 19.10 nicht mehr offiziell von Steam supported.

Grund dafür ist die kürzlich von Canonical getätigte Aussage, mit Ubuntu 19.10 die 32bit Libs nicht mehr auszuliefern.
Hierbei handelt es sich also nicht um die Bit-Anzahl des Betriebssystems selbst (das schon jetzt nur noch in 64bit ausgeliefert wird), sondern die von den Programmen benötigten Bibliotheken werden nicht mir in 32bit ausgeliefert.

Einige Anwendungen, darunter auch Wine ist sehr stark von den 32bit Libs abhängig, da sehr viel Software und insbesondere Spiele auf die 32bit Bibliotheken setzen.
 
Kann man nur begrüßen, da Ubuntu in vielen Dingen nicht das richtige Linux für das Gamen ist.

Sieht man auch bei YouTube. Da springt einen sofort ein Linux Version ins Auge, die nun mal die meisten benutzen.

Aber ich will keine Werbung machen.
 
Kann mich nicht beschweren bisher, zocke jetzt schon seit 2 Jahren unter Ubuntu (bin nicht auf der LTS-Version).
Muss mir jetzt also eine alternative Distro suchen, wobei bei mir Coding (intellij idea) und Gaming unter einen Hut muss.

Eigentlich würde ich gerne mal Fedora näher anschauen, aber da ist es (nach meiner kurzen Recherche bisher) mühselig, Steam und auch IntelliJ zu installieren. Und meine Lieblings-DE (Budgie) gibt es auch nicht.

Auch Manjaro steht auf meiner Liste mit potentiellen Kandidaten, aber da ich damals schon die zig Probleme von Arch bei meinem Bruder mitbekommen habe, bin ich Arch etwas vorsichtig gegenüber. Hier ist dafür Steam direkt mit an Bord. IntelliJ scheint (?) einfach zu installieren zu sein.

EDIT: Das zurückrudern läuft aber doch wieder darauf raus, dass sie das dann in Snaps mit entsprechenden Libs laufen lassen wollen. Ich bin ehrlich gesagt nicht wirklich ein Fan von den Snaps...
 
DrCox1911 schrieb:
EDIT: Das zurückrudern läuft aber doch wieder darauf raus, dass sie das dann in Snaps mit entsprechenden Libs laufen lassen wollen. Ich bin ehrlich gesagt nicht wirklich ein Fan von den Snaps...
erstmal sollen die notwendigsten 32bit libs so in den repositories bleiben, wie sie es jetzt sind. auf lange sicht wollen sie es mit snap lösen. wobei ich da auch kein fan von bin. andererseits benutze ich auch nicht ubuntu... :)
 
Vllt sollte man erwähnen, dass das von der Einstellung jeglicher Unterstützung für 32-Bit Pakete seitens Ubuntu ab 19.10 einhergeht, die Steam insbesondere für Proton (wine) benötigt.

//oder man liest den ersten Post zu ende. Mein Fail.
 
Systeme auf Arch Basis gibt es genügend. Weiter sollte man "systemd" den Finger zeigen und auf "OpenRC" gehen.

Wem das nichts sagt, einfach mal eine Suchmaschine füttern.
 
Bagbag schrieb:
Welche Probleme? Die lassen sich sicher beheben.
Ist schon eine Weile her, inzwischen benutzt er auch kein Arch mehr. Aber er musste des öfteren ran, da der X gar nicht mehr wollte.

@Y-Chromosome Kenne es ehrlich gesagt so, dass man Fremd-Repos meiden sollte, da kann ja alles mögliche damit eingeschleust werden.
 
OpenMandriva Will den Gleichen Weg gehen.
https://www.pro-linux.de/news/1/27179/openmandriva-unterstützung-für-32-bit-wird-eingeschränkt.html
DrCox1911 schrieb:
dass sie das dann in Snaps mit entsprechenden Libs laufen lassen wollen
Snaps oder Flatpaks laufen abgekabselt vom System für Wine oder Steam völlig ungeeignet.
Ergänzung ()

0x8100 schrieb:
Ultimately though they will be pushing for packages like Wine to make use of Snaps or other containers for running 32-bit software in the future
Absurd, Snap ist ein Container Format und wie bei jeden Container Format kann ein Container nicht auf den Inhalt des anderen Containers zugreifen. Das zu ändern führt das Konzept ad absurdum. Wie wollen sie das Umsetzen. Wine in einem Container laufen lassen in den man dann alle Windows Spiele nachinstallieren kann.
Das wiedersprich komplet dem Konzept. Weil anders rum wird es nicht gehen. Normale Anwendungen haben nur einen eingeschränkten Zugriff auf einen Containerinhalt wenn überhaupt und Umgekehrt ist es das gleiche.

Wer trifft bei Canonical eigentlich die Entscheidungen? Weil viel Ahnung von der Materie scheint derjenige nicht zu haben, das sage ich als normaler Anwender.

Aber gehen wir mal davon aus dass das so geplant ist, dann kann ich jetzt schon erhebliche Performance Probleme vorhersehen.
 
Zuletzt bearbeitet:
Container sind nun nicht dafür bekannt die Performance zu drücken. Du hast da 100% der Host-Performance.

Nachtrag: Mit Ausnahme von Snaps.
 
Zuletzt bearbeitet:
Meine Erfahrung mit Snap sagt mir da was anderes, allein wenn ich vergleiche wie lange ein Programm als Snap installiert zum starten braucht im Vergleich zu dem selben Programm nativ installiert.
 
Zugegeben, ich habe Snaps noch nicht selbst genutzt (jedoch andere Container Technologien, die ebenso wie Snap die Linux Namespaces für die Isolierung nutzen). Google sagt, dass die Snaps lediglich lange zum starten brauchen, weil der Container eben erst erstellt werden muss und Snap da bspw. Fonts generiert. Nach dem Start sollte die Ausführung dann aber mit Host Performance laufen.

Nachtrag: Nach weiterer Recherche scheinen die Snaps auch tatsächlich im Betrieb lahmer zu sein. Das ist jedoch bspw. bei LXC-Containern oder Docker nicht der Fall.
 
  • Gefällt mir
Reaktionen: Linuxfreakgraz
  • Gefällt mir
Reaktionen: Linuxfreakgraz und Y-Chromosome
Zurück
Oben