News Ubuntu: Zukunft als Spiele-Distribution in Frage gestellt

[Photon]

Manjaro taucht in der Steam Hardware&Software Survey direkt hinter Ubuntu und noch vor Mint auf, wenn Ubuntu nicht infrage kommt, wäre also Manjaro eine mögliche Alternative. Interessanterweise wird dort Steam sogar vorinstalliert ausgeliefert, afaik eher ungewohnt für eine Linuxdistro.

 

[silentdragon95]

Mal so zum Thema "niemand braucht 32-Bittige Software" - Windows führt für x86 und x64 Software ja getrennte Ordner. Ich vergleich das mal kurz bei mir.

x64: 64 Unterordner
x86: 71 Unterordner

Na hoppla! Nein, natürlich überrascht mich das nicht im geringsten. Etwa die Hälfte der Windows-Software, die ich installiere, ist noch 32-Bit - und Spiele sind hier noch gar nicht eingeschlossen, denn darum kümmern sich ja Steam & Co. Ich denke mal, das dürfte bei den meisten nicht anders aussehen.

 

[new Account()]

Mal so zum Thema "niemand braucht 32-Bittige Software" - Windows führt für x86 und x64 Software ja getrennte Ordner. Ich vergleich das mal kurz bei mir.

x64: 64 Unterordner
x86: 71 Unterordner

Windows != Linux! Der Witz unter Linux sind ja gerade so viele Open Source Programme. Da ist es mir egal, die gibts für die Distribution dann halt in 64 bit kompiliert. Das Problem 32/64 bit ist viel geringer unter Linux als unter Windows. Da sind schnell mal alle Programme für 64 bit verfügbar. Windows hat da gar keine andere Wahl als 32 bit als Subsystem mitzuführen.

 

[Rubyurek]

Kommt darauf an, was du zockst und welche Windowsprogramme du verwendest. Einiges läßt sich virtualisieren.

https://www.golem.de/news/steam-pla...llo-linux-ein-gamer-zieht-um-1906-141920.html

Naja ich zb zocke: wow,ff14, r6 siege,teso, steam spiele.
Nutze Programme wie: Adobe Photoshop, premiere pro

 

[PS828]

Uff, Linux. Also ich freue mich erstmal dass da ordentlich Bewegung drin ist und es scheint grade für den versierten Nutzer kein Problem zu sein für sich das passende Paket zu finden. Ich habe kaum Erfahrungen mit Linux bisher machen können aus Zeitmangel, aber habe Ambitionen nach meinem umstieg im nächsten Jahr auf TR Gen 3 Linux mal auszuprobieren, weil wohl bestimmte Programme die mit vielen Kernen klar kommen dort besser liefen als auf Windows (zumindest gen 2). Allerdings habe ich da keine so richtige Ahnung was ich brauch, da Linux für mich wie ein riesiger flickenteppich wirkt wo zwar alles funktioniert aber eben hier und da und mit dem und das

Sehr verwirrend, könnt ihr mir da ne seite oderso emfehlen die einen da bisschen einführt in die Thematik? Würde mich freuen mir eine zweite Plattform neben Windows für entsprechende Anwendungen aufbauen zu können.

 

[Decorus]

Windows != Linux!

Diese triviale Erkenntnis bringt leider vor dem Hintergrund nicht funktionierender aber benötigter Software nichts.

Der Witz unter Linux sind ja gerade so viele Open Source Programme. Da ist es mir egal, die gibts für die Distribution dann halt in 64 bit kompiliert.

So einfach ist das nicht....
64bit PCSX2 kompilieren? Das ist Open Source.... total easy?
Nope Recompiler sind sehr architekturspezifisch, dazu muss ja dann auch die kompatibilität mit 2.000 Programmen erhalten werden, dann muss das Plugin Framework samt der Plugins umgestellt werden.
Da kannst du nicht mal eben den Compiler anwerfen und ein paar Korrekturen vornehmen.

Dazu Treiber, die nur in 32bit vorliegen (Brother).
Plugins für diverse Sound und Grafikprogramme.

Dennoch: sollte das so sein, dass Steam und WINE mit ~200 statt 6000 Paketen 32bittig auskommt, dann kann man das ja noch mitführen, nur würden dann auch Spiele weiterhin funktionieren mit denen oder eben nur Steam und WINE?

Spiele bei Steam dürfen nur die Steamruntime + ihre selbst mitgelieferten libraries benutzen.
Ausnahme ist natürlich der tiefe Systemkram wie glibc/stdc++/Grafikstack, weil das zu unendlich Konflikten mit den unterschiedlichen Distributionen führen würde. Deswegen sind es für Steam auch weniger Pakete als bei Wine.

Genau das ist der Punkt. Valve hat ja die Ressourcen, um den Client/Proton auf 64 bit umzustellen, das würde ja Abhilfe schaffen. Damit hätte man Libraries gespart und die Spiele müssen genauso wie Windows Spiele unter WINE eben nicht angepasst werden.

Steamclient auf 64bit bringt dir nichts, wenn die Spiele 32bit sind.
Die brauchen ja dann immer noch den 32bit Stack ausserhalb der Runtime, glibc/Mesa, etc.

Proton/Wine auf 64bit gibt es bereits, aber 32bit Windowssoftware wird auf 32bit Linuxbefehle übersetzt.
Das auch auf 64bit zu heben würde immense Probleme verursachen. Dazu wird die Kompatibilität verringert, neue Bugs geschaffen und die Performance signifikant verringert.
Wine muss das gerade für das neue MacOS machen und hat schon massiven Performanceverlust sowie den Verlust von Kompatibilität angekündigt.


Um nicht nur zu kritisieren, sondern auch mal meine Sicht dieser Situation darzulegen:
Ubuntus Supportende für die x86-32 Hardware ist verständlich.
Das wird mit stark schwindender Nutzerbasis zu den Nischendistris oder Debian wandern (müssen).

Hiermit auch den Support für 32bit Software einzustellen, (für die eine 64bit Variante existiert!) ist auch verständlich.

Gleich den Support für alle 32bit libs rauszuwerfen, obwohl man selber Blocker identifiziert hat und es sich dabei um nur 2-3% des Gesamtrepos handelt, war eine völlige Fehleinschätzung.
Vor allem, da bei den libs, die Steam und Wine benutzen nicht mal das "keine User und damit keine Bugreports mehr -> Bitrot" Argument zieht.
Und vor allem, weil man 90 Tage vorher diese Entscheidung verkündet und keine Lösung hat, sondern "schon eine finden wird"(TM).

Das war alles so unnötig.....

 

[Schmarall]

Die Redaktion dankt ComputerBase-Leser „Schmarall“ für den Hinweis zu dieser Meldung!

Und ich danke für die Erwähnung Freut mich, dass ihr das Thema aufgegriffen habt. So macht das ganze Spaß und geht Hand in Hand zwischen Leser und Redaktion

 

[Blutschlumpf]

Klar, jetzt werden die ganzen Entwickler hingehen und ihre Spiele von 1995 auf 64 bit portieren weil die 3 Ubuntu-User, die das spielen in 4 Jahren keine Updates für 32 bit bekommen.
Wer sicher sein will, dass er Spiel xy in 5/10/15 Jahren noch spielen kann, der sollte sich heute ne Kiste mit Windows7 32 bit und ggf. noch XP aufsetzen und für alle wichtigen Spiele No-CD-Patches oder sonstige cracks besorgen.
Ich erinnere nur mal dran, dass der Steam-Browser schon WindowsXP nicht mehr nimmt.
Alles was nicht offline lauffähig ist, muss im Grunde als verloren betrachtet werden.

 

[RedDeathKill]

Mal so zum Thema "niemand braucht 32-Bittige Software" - Windows führt für x86 und x64 Software ja getrennte Ordner. Ich vergleich das mal kurz bei mir.

x64: 64 Unterordner
x86: 71 Unterordner

Das hat nicht so viel Aussagekraft, man müsste noch genauer nachforschen. Einige Programme (Google Chrome) oder Spiele (ESO) legen grundsätzlich ihre Daten unter x86 ab, obwohl es 64 bit Programme sind.

 

[Tom_111]

Ich wollte von Debian-Stable auf Ubuntu wechseln, weil das weniger Fummelei erfordert. Aber jetzt gehe ich dann lieber auf Debian-Testing.

 

[Decorus]

Update von Valve zu der Situation:
https://steamcommunity.com/app/221410/discussions/0/1640915206447625383/
Ubuntu wird nach der Verlängerung weiterhin Unterstützt, nachdem sowohl Valve und die Community klargemacht haben, dass 3-4 Monate zu wenig Zeit sind, für eine Lösung die Steam und nicht-Steam Spiele unterstützt.

 

[DeusoftheWired]

Naja ich zb zocke: wow,ff14, r6 siege,teso, steam spiele.
Nutze Programme wie: Adobe Photoshop, premiere pro

WoW ist da recht unproblematisch. R6S läuft wegen fehlendem Battleeye nicht auf Linux, das wird sich in Zukunft aber ändern. FF14 läuft mittel bis gut.

PS ist das alte Thema mit GIMP.
Zu Premiere gab es letztes Jahr eine Abstimmung zur Portierung auf Linux. Alternativen sind Openshot, Kdenlive, Avidemux, je nachdem, was du mit Premiere machst. Professionell noch Blender.

Update von Valve zu der Situation:
https://steamcommunity.com/app/221410/discussions/0/1640915206447625383/

Das dürfte die Redaktion interessieren und ein Update des Artikels wert sein. Paging Dr. @AbstaubBaer !

 

[SOWJETBÄR]

Diese triviale Erkenntnis bringt leider vor dem Hintergrund nicht funktionierender aber benötigter Software nichts....

Wie ich vorher rezitiert wurde damit sieht man schon, dass das einiges bringt. Da wird zu einfach Windows und Linux in einen Topf geworfen, wo aber die Bedingungen gerade da nicht so zutreffen. Auf Linux gibt es nun mal viel weniger Software die nur in 32 bit vorliegt.

...So einfach ist das nicht....
64bit PCSX2 kompilieren? Das ist Open Source.... total easy?
Nope Recompiler ...

Recompilieren wie in binär32->binär64? Nope, wenn schon Open Source meinte ich schon auch aus dem Source mit bspw. gcc64 statt 32bit. Und ja, wenn bspw. PCSX2 weiter entwickelt wird, warum dann nicht die nötige Anpassungen auf neue Systeme vornehmen? Weil das Aufwand ist?
Da komm ich aber zum Punkt von vorher: wo außer Spielen brauch ich denn das tatsächlich? Da sind wir grade bei PCSX2 (einem Emulator) dabei, dass eine andere Hardware emuliert werden soll für ein anderes Ziel. Was würde dagegen sprechen auf 64bit umzustellen. Dass es verschwindet würde ich nicht hoffen und auch das 32 bit irgendwann immer schlechter unterstützt wird, davon würde ich auch ausgehen.

...Dazu Treiber, die nur in 32bit vorliegen (Brother)....

Ist aber auch nicht sehr realitätsnah, alte Geräte mit alter Peripherie auf ein brandneues Ubuntu umzustellen. Siehe auch die vielen Maschinen in der Industrie, die steinalte Systeme verwenden (zugegeben meist Windows) weil die Hardware nicht auf neueren Systemen funktioniert. Das Problem hab ich aber in Linux genauso, egal wie "bittig". Einige Hardware wird eventuell nur unter bestimmten Kernelversionen unterstützt, weil eben der Treiber mit anderen Kerneln nicht kompatibel ist. Da gilt aber genauso, Ubuntu wird zurecht nicht mit 20 Kerneln ausgeliefert.

...Das auch auf 64bit zu heben würde immense Probleme verursachen. Dazu wird die Kompatibilität verringert, neue Bugs geschaffen und die Performance signifikant verringert.
Wine muss das gerade für das neue MacOS machen und hat schon massiven Performanceverlust sowie den Verlust von Kompatibilität angekündigt....

Ist klar unschön der Performanceverlust, wie stark ist der denn? Bei alten Programmen würde das aber zumindest die CPU schaffen, nehme ich an. Und alte Software sollte ja auch eher die Ausnahme sein allem Aufschrei zum Trotz.

Ich hör da halt was alles nicht gehen soll und die Beispiele sind dann PCSX2 (Treiber lass ich mal raus, da gibts wie erwähnt auch so Probleme genug). Der Punkt ist ja gerade, dass doch kaum einer unter Linux alte Software verwenden wird. Die beliebten Programme werden wenn sie einschlafen geforkt und weiter unterstützt. Und dann wird natürlich aktualisiert (bspw. auch Qt/GTK gewechselt bei den GUIs), wo die neue Version lauft. Da muss man dann auch sagen, dass Ubuntu für die Zielgruppe auch gar nicht gedacht ist, die unbedingt eine exotische Software laufen lassen möchten. Da gehts nun mal einzig um Spiele und da kann man eben viel über Steam/Wine/Proton die libs hochheben um gerade alte Spiele, wenn auch mit Leistungsverlust aber bei neuerer Hardware immer noch spielbar, weiter zu unterstützen.

...Um nicht nur zu kritisieren, sondern auch mal meine Sicht dieser Situation darzulegen:...

Will auch nicht kritisieren, da wird halt zu sehr wieder rum gemeckert. Man könnte ja durchaus so ~100-200 Pakete weiter anbieten, wenn das schon reicht (sofern keine Fehler in neueren Versionen auftreten, braucht man da ja nicht mal was ändern). Langfristig wird da aber wohl kein Weg dran vorbei führen, dass auch die Projekte, die noch entwickelt werden und auch verwendet, wechseln müssen.

Gerade Ubuntu (ist Zulu für "ich verkaufe deine Daten") kann bei vielen Alleingängen kritisiert werden. In dem Fall aber seh ich grad das 90 Tage vorher einfach vor Tatsachen stellen nicht. Laut den News soll 20.04LTS die letzte Version mit 32bit libs sein (in fast einem Jahr kommt das erst raus!!!) und eben LTS sprich bis grob 2025 32 bit unter Ubuntu ermöglichen. Wenn man also 6 Jahre vorher ankündigt, stellt endlich um, ist das definitiv nicht kurz. Da ist insbesondere mal Steam gefragt, die ja bei der Epic vs. Steam Diskussion so gute Linux Unterstützung haben sollen, eine Kompatibilitätsschicht auch dafür zu entwickeln.

Und um auch meine Sicht noch genauer zu umreissen:
Ja ich bin für Kompatibilität, auch bei den Schnittstellen: Klinke im Smartphone und USB-A am Gerät. Bin aber auch sehr für neue Technik zu begeistern und USB-C ist echt eine super Vereinheitlichung zu A/B,2/3,micro/mini+Kombis. Das heißt aber nicht, dass Laptops kein USB-A mehr haben sollen, wenn keine Maus, Tastatur, fast kein USB-Stick, beliebige Peripherie... NEU USB-C hat, geschweige denn Hardware die man schon gekauft hat und noch gerne ein paar Jahre nutzen will. Langfristig sollte aber schon Hardware mit USB-C kommen. Und bei 32/64 bit ist genau das eben schon soweit. Da ist 64 bit seit ~2010 schon recht verbreitet gewesen bei neueren Computern, dann wäre in der Windows/Linux Welt Ubuntu einer der ersten, die nach 15 Jahren damit brechen, andere werden ohnehin noch einige Jahre mehr bieten. Das ist ein Zeitraum, wo man schon sowas machen dürfte meiner Meinung nach. Man darf ja nicht vergessen, dass auch die 8/16 bit Programme auf heutigen OS nicht laufen, auch wenn der PC sehr wohl noch im real mode hochfährt.

 

[BrollyLSSJ]

Also ich wäre auch dafür, dass VALVe auf Fedora wechselt. Gefällt mir am besten. Ich wollte neulichs mal Manjaro probieren, aber die haben ja, wie auch arch, seit einigen Monaten (gut 2 Jahre) keine reine 32 Bit Version mehr. Dann habe ich mir gedacht, guck mal nach Antergos, weil das näher an arch ist als Manjaro, aber das ist ja inzwischen auch eingestellt. Ich traue mir halt noch nicht zu ein reines Arch selber aufzusetzen. Bei Fedora mag ich auch, dass das Upgrade bisher immer problemlos lief (ich fing mit 18 an und habe immer wieder auf die neueste Version das upgrade durchlaufen und nie Probleme gehabt, während dies bei debian und ubuntu immer im Kernal Panic und andere Scherze endete). Debian basiert kann mir daher gestohlen bleiben. Also VALVe, bitte auch offiziell Fedora und arch / Manjaro supporten.

 

[Serana]

@SOWJETBÄR
Die Frage die Canonical beantworten muß ist ganz einfach: Wollen sie das Ubuntu eine Distribution ist die uneingeschränkt auch für Steam/Proton und Wine tauglich ist oder wollen sie das nicht. Daraus ergibt sich ob auch weiterhin (und zwar langfristig) die für diesen Anwendungszweck wichtigen 32 Bit Bibliotheken angeboten werden oder eben nicht.

Leben kann ich persönlich, schon weil ich Ubuntu oder seine Derivate gar nicht einsetze, mit beidem. Nur eine klare Entscheidung wäre halt nett damit man einfach weiß, ob man Ubuntu für den Einsatzzweck Linux-Spielerechner uneingeschränkt empfehlen kann oder ob da andere Distributionen eben besser geeignet sind.

Wenn es nur um Anwendungen geht die nativ für Linux entwickelt wurden dürfte eine ausschließlich auf 64 Bit fokussierte Distribution natürlich in den meisten Fällen vollkommen ausreichend sein. Aber darum geht es bei der Diskussion gar nicht. Es geht darum welchen Weg Ubuntu in Zukunft einschlagen will.

 

[n30cr0n]

Wenn er Manjaro seit Jahren auf der Arbeit nutzt bedeutet dies wohl, dass das Betriebssystem stabil genug für den Produktiveinsatz ist. Dies ist nicht unbedingt eine Selbstverständlichkeit und für mich eine interessante Information, wenngleich das nicht für jeden Leser gelten muss

Waere es, wenn irgendetwas zum Anwendungsszenario mit eingeworfen wuerde. So ist es nicht einmal eine Information, sondern gerademal ein nutzloses Datum.
Haengt er den ganzen Tag nur in einem Linux Terminal? Macht er Bildbearbeitung? Musik? Ist er Journalist und schreibt Texte? Braucht er es nur fuer Emails und Termine, weil er in einer Fuehrungsposition ist?
So ist der Beitrag nicht zu gebrauchen, und sieht fuer mich daher sehr nach "schaut her, ich benutze Linux" also wie Erschleichen von Aufmerksamkeit aus.
Wenn ich jetzt sage, ich benutze Windows privat und im Job, weil Manjaro dafuer nicht geeignet ist, bringt es genau so wenig etwas ohne Benennung der Einschraenkungen, Probleme bzw. meiner Anwendungsszenarien ...

 

[Decorus]

Auf Linux gibt es nun mal viel weniger Software die nur in 32 bit vorliegt.

Das bringt dir aber nichts wenn du auf bestimmte Windowssoftware angewiesen bist. Stichwort Firmwareupdater. Und die sind gerne auch mal 32bit Programme. Und das wiederum bedeutet, du brauchst 32bit Wine.

Recompilieren wie in binär32->binär64? Nope, wenn schon Open Source meinte ich schon auch aus dem Source mit bspw. gcc64 statt 32bit.

Der Recompiler im Emulator natürlich. Irgendwie muss der Emotion Engine Code ja auf x86 laufen. Und ja der ist Open Source, aber er ist eben auch sehr Architekturspezifisch, schon alleine aus Performancegründen.

Und ja, wenn bspw. PCSX2 weiter entwickelt wird, warum dann nicht die nötige Anpassungen auf neue Systeme vornehmen? Weil das Aufwand ist?

Die Arbeiten an einem Port zu 64bit begannen 2006..........
Wenn du glaubst dass das so einfach ist, kannst du dir den Code ja gerne im github anschauen und mithelfen.

Da komm ich aber zum Punkt von vorher: wo außer Spielen brauch ich denn das tatsächlich? Da sind wir grade bei PCSX2 (einem Emulator) dabei, dass eine andere Hardware emuliert werden soll für ein anderes Ziel. Was würde dagegen sprechen auf 64bit umzustellen. Dass es verschwindet würde ich nicht hoffen und auch das 32 bit irgendwann immer schlechter unterstützt wird, davon würde ich auch ausgehen.

Nur weil dein Usecase diese Sachen nicht einschliesst, gilt das nicht für alle Anderen.

Ist aber auch nicht sehr realitätsnah, alte Geräte mit alter Peripherie auf ein brandneues Ubuntu umzustellen.

Alle Brother Treiber für Drucker sind in 32bit. Auch die von den Allerneuesten.

Ist klar unschön der Performanceverlust, wie stark ist der denn? Bei alten Programmen würde das aber zumindest die CPU schaffen, nehme ich an. Und alte Software sollte ja auch eher die Ausnahme sein allem Aufschrei zum Trotz.

Wir werden es bald sehen, aber wenn ich mir anderes JIT recompiling ansehe dann können wir mindestens von halbierter Performance ausgehen. Dazu kommt dann noch der Verlust an Kompatibilität.

Ich hör da halt was alles nicht gehen soll und die Beispiele sind dann PCSX2 (Treiber lass ich mal raus, da gibts wie erwähnt auch so Probleme genug).

Also wenn du Treiber, Spiele und alte Software unter Linux ausklammerst, ja dann ist klar, dass du da kein Problem siehst.
Andere denken sich da dann: Wozu hab ich ein OS wenn eh nur noch das Allerneueste läuft?

Will auch nicht kritisieren, da wird halt zu sehr wieder rum gemeckert. Man könnte ja durchaus so ~100-200 Pakete weiter anbieten, wenn das schon reicht (sofern keine Fehler in neueren Versionen auftreten, braucht man da ja nicht mal was ändern). Langfristig wird da aber wohl kein Weg dran vorbei führen, dass auch die Projekte, die noch entwickelt werden und auch verwendet, wechseln müssen.

Die müssen nicht notwendigerweise wechseln. Solange User es benutzen und es genug Feedback gibt, kann das überleben. Ist ja nicht so als müsstest du da ne riesen Toolchain aufbauen dafür.

Gerade Ubuntu (ist Zulu für "ich verkaufe deine Daten") kann bei vielen Alleingängen kritisiert werden. In dem Fall aber seh ich grad das 90 Tage vorher einfach vor Tatsachen stellen nicht. Laut den News soll 20.04LTS die letzte Version mit 32bit libs sein (in fast einem Jahr kommt das erst raus!!!) und eben LTS sprich bis grob 2025 32 bit unter Ubuntu ermöglichen.

Das ist nach dem Zurückrudern.
Bisher war es so, dass 19.10 schon keine nativen 32bit libs mehr haben sollte und jeder der 19.04 hat (weil er neuere Treiber/Software braucht) gekniffen gewesen wäre, wei sein einziger Upgradepfad ihm die 32bit libs unter dem Hintern wegzieht, und ja das sind 3-4 Monate Vorwarnzeit und das ist - sorry - inakzeptabel.

Man darf ja nicht vergessen, dass auch die 8/16 bit Programme auf heutigen OS nicht laufen, auch wenn der PC sehr wohl noch im real mode hochfährt.

Wie gesagt, der Linuxkernel hat immer noch 16bit Kompatibilität für Wine, deswegen läuft auch 16bit Software noch unter Wine.

 

[SOWJETBÄR]

Recompiler im Emulator

Jetzt weiß ich was gemeint ist

Die müssen nicht notwendigerweise wechseln. Solange User es benutzen und es genug Feedback gibt, kann das überleben. Ist ja nicht so als müsstest du da ne riesen Toolchain aufbauen dafür.

Im Bezug auf ein paar nötige Pakete (die ominösen ~200 von über 6000) sind wir ja einer Meinung.

...Wenn du glaubst dass das so einfach ist,...
...Also wenn du Treiber, Spiele und alte Software unter Linux ausklammerst...

Hab ich nie gesagt. Besonders:

Nur weil dein Usecase diese Sachen nicht einschliesst, gilt das nicht für alle Anderen.

Bitte das vollkommen unnötige Totschlagargument "Tellerrand" weglassen, es gibt IMMER den einen Spezialisten der irgendwas macht (oder auch "Ausnahme bestätigt die Regel"). Stattdessen dann bitte auch ein Beispiel bringen. Ich klammere EXPLIZIT NICHT Software, sprich Programme, aus. Ich hab erwähnt, dass die unter Linux in kompatibler (ja auch 64bit) Version vorliegen oder eben wenn eingeschlafen, geforkt und wieder aktualisiert werden. Auch alte Software kriegt eine neue Version. Und wenn denn nicht, dann bitte ein Beispiel nennen! Das klingt ja mit dem überspitzten "OS nur mit neuester Software" so als würden ohne die 32bit libs auf einmal nur die aktuellsten Versionen aller Programme laufen. Das ist ja nicht mal annähernd der Fall. Bitte dennoch Windowsprogramme ausklammern, siehe weiter unten.

Treiber hab ich auch nicht ausgeklammert, gerne auch hier nochmal: Treiber sind grade unter Linux nicht problemlos so weiter verwendbar, egal ob ich den schon in 64 bit vorliegen habe. Da Treiber gerne mal für eine Kernelversion geschrieben sind und (immerhin von Firmen) proprietär sind, kann ein Treiber schon mal auf einem neuen Kernel nicht mehr funktionieren. In dem sehr wahrscheinlichen Fall, dass aber für einen neueren Kernel kein Treiber mehr kommt, sitz ich dann fest.
Und auch da, definitiv akzeptier ich

Alle Brother Treiber für Drucker sind in 32bit.

wusste ich schlicht nicht, dass es sowas gibt bei AKTUELLEN Treibern. Da stellt sich aber schon die Frage, ist das tatsächlich ein guter Grund weiter 32 bit bis in alle Ewigkeit zu unterstützen? Auch hier, damit ganz klar ist was ich mein, nicht morgen abstellen aber zumindest sagen in ~2-3 Jahren ist Schluss?

Noch kurz zu "mein Usecase", Ubuntu ist EIN Usecase. Da können nicht alle zufrieden gestellt werden mit der Distribution, das muss klar sein - nur weil das für einen Anwender was ist gilt das nicht für alle Anderen. Da gehts auch nicht darum alles in alle Ewigkeit zu unterstützen und mir gings auch vorher nicht darum. Wie ich schon schrieb, alte Hardware in der Industrie: das is keine Zielgruppe für Ubuntu. Auch wenn das nicht mein/dein Usecase ist, gibt es ihn. Dennoch kann halt Ubuntu darauf keine Rücksicht nehmen, weil ein kleines OS ohne einfach bedienbare UI mit Standardprogrammen wie für so Industriemaschinen ideal dem Einsteiger der Ubuntu-Zielgruppe nicht passt.

Das bringt dir aber nichts wenn du auf bestimmte Windowssoftware angewiesen bist. Stichwort Firmwareupdater. Und die sind gerne auch mal 32bit Programme. Und das wiederum bedeutet, du brauchst 32bit Wine.
...
Wie gesagt, der Linuxkernel hat immer noch 16bit Kompatibilität für Wine, deswegen läuft auch 16bit Software noch unter Wine.

Das ist natürlich was anderes als native Linuxprogramme, analog zu Windows muss da das System friss oder stirb arbeiten. Guter Punkt ist aber die 16bit Kompatibilität, die funktioniert (man staune!) auf WINE 32 bit! Was spricht nun also dagegen auch hier (nun halt 16 und 32 bit) auf WINE mit 64 bit laufen zu lassen. Ich greif extra dein Beispiel auf, das ich ja den Usecase nicht falsch von meiner Sicht aus annehme: Firmwareupdater werden (das trau ich mich sogar für alle Update zu sagen ich böser Verallgemeiner) auch mit halber, viertel, Zehtnel Geschwindigkeit noch laufen auf halbwegs aktuellem System sogar ohne merkbarem Zeitunterschied (halt mit mehr CPU-Last). Auch ohne das zu sehr auf meinen Anwendungsfall zu biegen sollte klar sein, dass immer weniger Leute immer weniger alte Programme ausführen mit der Zeit, womit der Overhead auch mehr in den Hintergrund rückt und der Vorteil einiges an Paketen zu sparen überwiegt.
Wichtig hier: auch wenn das nicht mein Usecase ist, seh ich den sehr wohl und hab auch eine Alternative als Vorschlag. Ob ich nun nur des Vorschlags wegen WINE an einem Wochenende ganz allein umschreiben muss damit ich das schreiben darf überlass ich dir.

Das ist nach dem Zurückrudern.

Da hätten wir uns auch viel hin und her jetzt ersparen können. Das ist natürlich was anderes, ob ich vor vollendete Tatsachen gestellt werde oder noch Zeit habe um umzustellen. Die News hatte halt schon von Anfang das Zurückrudern drin und da kann man schon durchaus eine sehr faire Lösung attestieren.

 

[burglar225]

Im Bezug auf ein paar nötige Pakete (die ominösen ~200 von über 6000) sind wir ja einer Meinung.

Ich finde den Schluss, den ihr daraus gezogen habt etwas seltsam: Wegen 200 Paketen wird ein Aufstand veranstaltet etwas altes am Leben zu halten (sinngemäß, ihr versteht, was ich meine).
Ich bezweifle sehr stark, dass Wine und Steam die einzigen sind, die 32bit-Bibliotheken verwenden. Die anderen sind wahrscheinlich einfach nicht groß genug, um gehört zu werden.
Canonical sollte doch eigentlich ausreichend Telemetriedaten haben, um zu wissen, welche Pakete wie oft verwendet werden. Warum dann nicht einfach die deprecaten, die gar nicht mehr verwendet werden?
Ich würde daher vermuten, dass alle der 6000 Pakete noch in Verwendung sind.
Im Endeffekt will ich sagen, dass es hier nicht nur um Wine um Steam geht, sondern auch um einen ganzen Haufen andere Programme, wenngleich es deutlich weniger sind, wie unter Windows, wo 32bit noch fest dazugehört.

 

[Serana]

Canonical sollte doch eigentlich ausreichend Telemetriedaten haben, um zu wissen, welche Pakete wie oft verwendet werden.

Ich weiß ja nicht wie das ganze bei Canonical gehandhabt wird, aber zumindest bei Debian ist es so, daß die Abfrage (popularity-contest) welche Pakete genutzt werden über einen Opt In-Mechanismus läuft. D.h., daß der Installer bei der Installation nachfragt ob er das einrichten darf. Sollte das bei Canonical über eine automatisch eingerichtete Telemetrie ungefragt auf jedem Ubuntu-System laufen (was ich nicht hoffe) wäre das ein starkes Argument gegen Ubuntu.

Vielleicht kann dazu mal jemand was sagen der tatsächlich Ubuntu nutzt.