Valve stopt met Ubuntu-ondersteuning Steam

Valve heeft te kennen gegeven dat het gaat stoppen met het ondersteunen van Ubuntu op zijn Steam-dienst. Dat heeft er mee te maken dat Ubuntu niet langer 32bit-software gaat ondersteunen op 64bit-systemen.

Pierre-Loup Griffais, een ontwikkelaar die bij Valve in dienst is, geeft in een bericht op Twitter aan dat Ubuntu vanaf versie 19.10 niet meer wordt ondersteund. In plaats daarvan gaat Valve zich richten op Steam-ondersteuning voor een andere Linux-distributie, maar het is op dit moment nog niet bekend welke dat gaat zijn.

Dat Steam niet langer wordt ondersteund op Ubuntu heeft ermee te maken dat de makers van laatstgenoemde ervoor hebben gekozen om 32bit-ondersteuning te laten vallen. Dat maakten zij vorige week bekend, waarbij werd aangegeven dat met Valve naar een oplossing zou worden gezocht om Steam te laten functioneren in de toekomst. Dat lijkt dus niets te hebben uitgehaald.

Voorlopig zal Steam waarschijnlijk blijven werken op versies van Ubuntu met een versienummer lager dan 19.10. Het is echter mogelijk dat door het gebrek aan ondersteuning, in de toekomst nieuwere versies van Steam niet langer zullen werken met Ubuntu.

Reacties (152)

Ik volg ook al een paar dagen deze ontwikkelingen, er is veel ophef over in de Linux community en er wordt Ubuntu verweten dat ze als mainstream distro het gebruikers nu te moeilijk gaan maken omdat dit wine ontzettend schaad. Opvallend was wel dat in die discussies werdt genoemd dat steam er via hun steam runtime makkelijk omheen kan maar dat juist platformen als GOG de klos zijn.

Persoonlijk vind ik het wel een goed idee om de 32-bit repo's te verkleinen, als je geen 32-bit OS meer uitbrengt heeft een massale repo met alle 32-bit packages geen nut meer. Maar waar ze de mist in gaan is door ook de cruciale packages niet meer aan te bieden welke sommige software zoals wine, games en steam nodig hebben.

Ik zie de meest gekke oplossingen voorbij komen als steam in een flatpak draaien, LXC containers en VM's. Dat kun je de simpele gebruiker gewoon niet gaan aandoen en het is dus ook logisch dat valve zegt het niet officieel te willen ondersteunen. Maar ik verwacht wel dat ze hier op terug komen gezien de devs inmiddels hebben gemerkt dat dit gevolgen heeft die ze niet hadden voorzien. Op het behouden van de packages na heeft ook iemand anders een goed idee geoppert, een aanpassing van deze essentiele packages zodat deze niet enkel de 64-bit library maar ook de 32-bit library installeren zonder echte multi-arch support. Op die manier blijven de applicaties gewoon werkend. Al vind ik persoonlijk dat ze beter een minimale repo overeind kunnen houden voor de essentiele 32-bit packages met als voorwaarde dat je moet kunnen aantonen waarom de 64-bit variant niet voldoet voor iets wordt opgenomen.

Hier kun je de discussies volgen : https://discourse.ubuntu....h-eoan-ubuntu-19-10/11263
https://discourse.ubuntu....bit-only-eoan-19-10/11353
https://www.winehq.org/pi...vel/2019-June/147869.html
https://www.phoronix.com/...u-19-10-setup#post1107921
https://www.phoronix.com/...2-bit-support#post1107597

Update: Steam blijft wel werken binnen de flatpak die reeds bestaat, meerdere gebruikers hebben dit getest op een systeem zonder 32-bit binaries. Dus mocht je toch Steam willen gebruiken op Ubuntu 19.10 (Als dit niet wordt opgelost) of een ander 64-bit only distro kun je het beste de flatpak gebruiken.

Update 2: Ubuntu heeft aangegeven dat de 32-bit libs beschikbaar blijven in 19.10 maar niet langer worden onderhouden. Hoe zij dit implementeren is onduidelijk maar het kan zijn dat de 32-bit stack van 18.04 wordt gebruikt onder de motorkap.

[Reactie gewijzigd door henk717 op 24 juni 2019 01:32]

Flatpak is eigenlijk bedacht als oplossing om dit ook in de lange termijn op te lossen. Het maakt het mogelijk om apps uit te brengen die geschreven zijn naar een speciale set runtimes en libraries, welke naast elkaar kunnen bestaan. Op deze manier kun zou je prima een 20 jaar oude 32bit applicatie kunnen draaien naast jouw state-of-the-art VLC of Steam. Er zitten nog andere voordelen in Flatpak (atomic, sandboxed) maar puur voor Valve's probleem is dit een goede oplossing.

Het is ook wel een kip-ei verhaal. Als Ubuntu 32bit blijft ondersteunen gaat niemand gebruik maken van de packaging methoden die er zijn voor legacy software, met als gevolg dat Ubuntu patches moet blijven uitbrengen voor libs die al 10 jaar deprecated zijn. Mogelijk dat Flatpak dus de oplossing is voor dit probleem, niet direct nu maar zeker over tien jaar, wanneer 32bit onderteuning echt wel eens dood mag.

Heb de afgelopen dagen de Flatpak versie van Steam getest en in het eerste opzicht werkt alles gewoon: Counter Strike GO, Doom 2016, DOTA.

Wat ik wel even wil benadrukken voor de vluchtige lezer, Valve twijfelt niet aan hun Linux strategie. Ze nemen op dit moment alleen maar extra mensen aan om hun Linux ondersteuning uit te breiden en ze hebben alleen aangegeven dat ze deze versie van Linux niet meer willen steunen. Wie Linux draait heeft immers iets te kiezen: Als je huidige distributeur er een potje van maakt kun je naar de concurrentie gaan.

[Reactie gewijzigd door Eonfge op 23 juni 2019 12:38]

Deze vat ik niet zo heel goed: "Het is ook wel een kip-ei verhaal. Als Ubuntu 32bit blijft ondersteunen gaat niemand gebruik maken van de packaging methoden die er zijn voor legacy software, met als gevolg dat Ubuntu patches moet blijven uitbrengen voor libs die al 10 jaar deprecated zijn."

Volgens mij stelt @henk717 juist dat er een minimale set aan libraries 32bits ondersteuning moeten behouden. Dat zou ook de meest voordehandliggende strategie zijn. glibc, gcc en een aantal essentiele (welke dat ook mogen zijn op Ubuntu) en je bent er eigenlijk al; dan kan je allerhande 32bits applicaties die enkel in binary beschikbaar gesteld zijn, nog steeds draaien.

Een OS is er voor de applicaties en gebruikers; niet andersom. Dat lijkt Canonical soms te vergeten. Juist een applicatie als wine, maar ook Steam zorgen ervoor dat mensen voor een Linux kunnen kiezen, omdat hun oude software nog "gewoon" blijft werken (grotendeels) Zeker omdat wine inmiddels een betere compabiliteit met oudere windows APIs heeft, is dit een heel sterke reden dat mensen minder afhankelijk worden van een OS leverancier (Microsoft)

Let wel: keuzestress is misschien lastig; maar de keuze hebben is een groot goed; daardoor kan een leverancier toch geen al te gekke dingen doen, omdat dat een groot deel van hun klanten zal kosten.

Volgens mij stelt @henk717 juist dat er een minimale set aan libraries 32bits ondersteuning moeten behouden. Dat zou ook de meest voordehandliggende strategie zijn. glibc, gcc en een aantal essentiele (welke dat ook mogen zijn op Ubuntu) en je bent er eigenlijk al

Daar heb je dus meteen het probleem te pakken. glibc is onderdeel van het OS, in tegenstelling tot Windows. Dat wil zeggen dat nieuwe OS features een update vereisen van glibc. En aangezien 32 bits programma's een 32 bits glibc nodig hebben, moet het OS dus ook die 32 bits ondersteuning leveren - precies wat Ubuntu wil vermijden.

Allemaal aparte containers of flatpaks, elk met hun eigen 32 bits glibc werkt op zich wel. Maar dan heb je dus een fikse overhead aan duplicate files. Bovendien heb je dan ook een heleboel kopiëen van elk security issue in glibc.

Ter vergelijking: Windows heeft Side-by-Side installation (SxS), waardoor je geen onnodige kopieën hebt van zulke libraries.

Daar heb je een punt; wat ik bedoelde: glibc is ook simpelweg in zowel 32 als 64 bits te bouwen; omdat dit onderdeel is van het OS zou je hopen dat canonical dit zou doen (maar het kan ook door de community) naast de 64bits geleverd door het OS. Maar gezien dit dus erg beperkt is qua onderhoud, zou je hopen dat Canonical dit onderdeel nog wel er naast wil en kan doen.

Zonder glibc heb je inderdaad niets.

Allemaal flatpacks of lxc containers... dan nog zit je met het issue dat er nog een 32bits OS aan ten grondslag ligt (of in elk geval een OS dat 32bits ondersteunt); Maak het jezelf dan makkelijk, en stap daar dan maar op over; de overhead is enorm.

Wat ik wel even wil benadrukken voor de vluchtige lezer, Valve twijfelt niet aan hun Linux strategie. Ze nemen op dit moment alleen maar extra mensen aan om hun Linux ondersteuning uit te breiden en ze hebben alleen aangegeven dat ze deze versie van Linux niet meer willen steunen. Wie Linux draait heeft immers iets te kiezen: Als je huidige distributeur er een potje van maakt kun je naar de concurrentie gaan.

Is dat echt zo? Immers als je er niet aan twijfelt kan je toch ook wel een 64-bit versie maken? Ik kan niet zomaar harde statistieken vinden, maar Ubuntu is waarschijnlijk als gewoon Windows vervanger (eg, geen Raspberries meegerekend, of computers die alleen er staan om mee te kloten) met marge de populairste optie. Het Linux marktaandeel is voor desktop gebruik al klein, en nu hebben ze dat in één keer gehalveerd.

Het probleem van Steam is dat ze ook bakken 32bit games in hun repo hebben. Die weken dan niet meer out of the box. Voor 32bit support voor Wine bijvoorbeeld heb je ook 32bit libs en dergelijke nodig. Het is dus een bijzondere keuze van Ubuntu als je kijkt naar 32bit close source spullen.

Hmm, beetje vaag verhaal van mij, maar je snapt hopelijk wat ik bedoel (ben nog niet helemaal wakker).

Welke games zijn dat dan 32 bit only?
Ik kan geen lijstje vinden hiervan.

meer dan de helft, alles uit het Win7 en daarvoor tijdperk.

veel, heel veel.

[Reactie gewijzigd door redniels op 24 juni 2019 08:10]

Juist het tegenovergestelde. Ze gaan juist te snel door de oude libs ineens niet meer te ondersteunen waardoor ineens hele hordes apps en games mogelijk niet meer werken. Had Microsoft vroeger die stappen ook maar durven nemen dan hadden we al 10 jaar eerder 64 bits os-en en apps gehad.

Is dat zo? Of blijven mensen en bedrijven dan juist met oude software draaien? Denk aan al die berichten dat bedrijven nog Windows XP draaien nadat officiële ondersteuning al gestopt was.

Ik bedoelde juist als Ubuntu 32-bit blijft ondersteunen dat Linux maar in het verleden gaat blijven hangen. Uiteindelijk is het aan distros en zelf bouwers om straks alleen nog 64-bit te ondersteunen, dan zal de kernel support uiteindelijk ook een keer ophouden. Kan Linus een keer blij zijn dat de kernel size verkleind is.

Wie Linux draait heeft immers iets te kiezen: Als je huidige distributeur er een potje van maakt kun je naar de concurrentie gaan.

Jij brengt het als iets positiefs, maar dit is precies een reden dat ik en vele anderen Linux juist niet gebruiken. De andere reden is dat mijn tools er niet op werken (Altium, CATIA, etc).

Ik wil niet hoeven kiezen en ik wil niet nadenken over welke variant vandaag het beste is. En morgen opnieuw nadenken over welke variant morgen het beste is voor mij.

Nu hadden we eindelijk een hele populaire distro die je "veilig kon kiezen", krijg je dit weer. Dus ik kan snappen dat de Linux community redelijk pissig is.

[Reactie gewijzigd door GeoBeo op 23 juni 2019 13:31]

Keuze op OS niveau is inderdaad niet het zelfde als keuze op applicatie niveau. Als jij afhankelijk bent van producten die zichzelf koppelen aan één (toe-) leverancier zoals Autodesk, Microsoft, en dergelijke, dan heb je inderdaad weinig keuze vrijheid. Soms heb je niets te kiezen en moet je gewoon slikken. Het beste wat je dan kunt doen is goed documenteren wat alle (verborgen) kosten zijn, zodat je bij de volgende inkoopronde een beter alternatief kunt voorstellen.

Bij mijn werk moedig ik een pluriform landschap aan, en de helft van de ontwikkelaars zit ondertussen op een variant van Linux, maar Windows wordt ook gewoon gebruikt. Dit zal de economische onafhankelijkheid van ons bedrijf zeker ten goede komen, want geen handelsoorlog die ons het gras voor de voeten weg maait.

En inderdaad, keuzestress is een ding... Het alternatief is echter gevaarlijker. Wat krijg je als jou leveranciers geen concurrentie hebben? In het beste geval niets, maar ga er maar vanuit dat je vroeg of laat erbij wordt genaaid. Dit heb ik zakelijk al meerdere malen mogen meemaken bij werkgevers, en privé waak ik er net zo goed voor.

Mocht je zakelijk de keuze willen maken, kies dan Red Hat Enterprise Linux of de gratis versie CentOS. Beide groot in de zakelijker wereld en super stabiel en conservatief. Wil je wat meer een moderner, betrouwbare en zakelijke desktop, kijk dan naar Fedora.

En inderdaad, keuzestress is een ding... Het alternatief is echter gevaarlijker. Wat krijg je als jou leveranciers geen concurrentie hebben? In het beste geval niets, maar ga er maar vanuit dat je vroeg of laat erbij wordt genaaid. Dit heb ik zakelijk al meerdere malen mogen meemaken bij werkgevers, en privé waak ik er net zo goed voor.

Nu word ik natuurlijk nieuwsgierig Kun je wat voorbeelden noemen?

Whahaah, dit is geen anoniem account dus je zult het hier mee moeten doen

Ik kan wel man en paard noemen hoor. Zowel Microsoft als Oracle hebben als business model om de licentievoorwaarden zo onoverzichtelijk te maken dat gebruikers ofwel te dure licenties kopen, ofwel bij een audit de sjaak zijn (en liefst allebei).

Zie bijvoorbeeld https://www.forbes.com/si...d-tactics-the-2018-model/ voor een aardig inzicht in Oracle. Met MS SQL heb ik ook zulke dingen zien gebeuren trouwens.

En inderdaad, keuzestress is een ding... Het alternatief is echter gevaarlijker. Wat krijg je als jou leveranciers geen concurrentie hebben? In het beste geval niets, maar ga er maar vanuit dat je vroeg of laat erbij wordt genaaid. Dit heb ik zakelijk al meerdere malen mogen meemaken bij werkgevers, en privé waak ik er net zo goed voor.
Indien je niets krijgt van je leveranciers zijn het dan wel een leveranciers?

“Ik en vele anderen”
Met drogredenen wordt je pleidooi niet sterker

“Ik en vele anderen”
Met drogredenen wordt je pleidooi niet sterker

Insgelijks.

CATIA bestaat voor Linux (volgens de site) maar Altium niet. In ieder geval heb je minder keus - maar ga er niet van uit 'dat het er toch niet zal zijn voor Linux'. Juist bedrijven met een geschiedenis in de workstations (weet je nog, dat Unix-systemen veel krachtiger waren dan PC's) kunnen of hebben dit.

Nadenken over welke variant het beste is hoef je niet morgen meteen alweer te doen. Dat is hooguit 1 x in de 3 of 4 jaar. En ik zie het probleem niet. Er bestaan ook vele verschillende automerken. Ik heb nog nooit iemand daarover horen klagen.

Slechte vergelijking. Er bestaan alleen "Microsoft Windows" achtige automerken: je koopt een auto en kunt er helemaal niets aan modificeren. Met modernere auto's kun je er zelfs niet meer aan sleutelen (er is geen "right to repair"). Alles aan een auto is closed source.

Auto's zijn bovendien zwaar gereguleerd door de overheid en OS'en zo goed als niet. ivm me veiligheid.

Als er nou auto's bestonden, waaraan je onbeperkt modificaties mocht aanbrengen en waar je zelf zonder enig probleem aan mocht sleutelen met gratis beschikbare "maintenance manuals", ontwikkeld door een community waarvan alle ontwerpen volledig open source waren.

Zelfs DAN had ik de vergelijking nog steeds niet begrepen: waar is de vergelijking met incompatibel apps, (niet bestaande) drivers voor Linux, Steam die op de eene opensource OS variant wel support heeft en op een andere niet en ga zo maar verder?

Ik zie de vergelijking niet...

Of je wel of niet kan sleutelen aan een auto doet er heel niet toe. Het gaat om het keuze aspect . Je maakt het veel te ingewikkeld. Dat een auto niet het zelfde is als een OS snap ik ook nog wel.

[Reactie gewijzigd door Nickname55 op 24 juni 2019 19:50]

Of je wel of niet kan sleutelen aan een auto doet er heel niet toe. Het gaat om het keuze aspect . Je maakt het veel te ingewikkeld. Dat een auto niet het zelfde is als een OS snap ik ook nog wel.

Zelfs dan. Simpel:

In elk merk/type auto kun je direct rijden.

Niet elke linux distro is direct bruikbaar. Het ligt aan: of er wel drivers zijn beschikbaar zijn voor de distro die je draait, of de software die je wilt draaien wel of niet ondersteund wordt voor die distro, of de nodige libs en dependencies aanwezig zijn in de distro, of de software die je wilt gebruiken draait op Linux, 32/64 bit wel niet beide ondersteund ellende, enz.

[Reactie gewijzigd door GeoBeo op 24 juni 2019 20:19]

Het gaat om de keuze. Wat kan je dr mee en wat wil je. Op basis daarvan kies je voor een bepaald merk en type auto. Als je 6 kinderen hebt, dan kies je een andere auto dan als je in je uppie bent. Als je met de caravan naar Zwitserland wilt, dan vallen er ook een heleboel auto's af. Als je 200 wilt rijden op de Duitse snelweg, dan kies je ook iets wat daarvoor geschikt is. Ik heb nog nooit iemand horen zeuren dat het toch allemaal zo moeilijk is dat er zoveel verschillende auto's zijn.

Met een besturingssysteem maak je ook een keuze afhankelijk van wat je er mee wilt. En ik zie niet in waarom het een probleem zou zijn dat er veel verschillende linux distro's zijn.

[Reactie gewijzigd door Nickname55 op 28 juni 2019 09:43]

Ik wil toch even vermelden dat er geen enkel of amper een softwarepakket is in de repositories dat zal stoppen met werken door de beslissing van Canonical.

Valve "eist" van de distributies dat ze een stack onderhouden die maakt dat software die nooit bedoeld was voor het platform misschien kan werken. En Valve ziet vervolgens de centen als gebruikers het platform gebruiken.

Ze hebben SteamOS geprobeerd: dat was verre van overtuigend. Ze weten dus best dat een distributie maken veel werk kost, en dat legacy code qua kosten-baten moeilijk ligt. Denk daarbij ook eens aan Spectre en Meltdown, wie weet wat er qua lijken nog uit de kast valt. Als Ubuntu LTS de 32 bits libs bevat, zitten ze er voor 10 jaar aan vast. Ok dan is de point release het moment om dit te doen. Zo onredelijk vind ik dat niet. Qua communicatie vind ik het allemaal nogal ongelukkig, dat lijkt een terugkerend fenomeen bij Canonical.

Die Linux strategie zit wat mij betreft dus grondig fout. Ok, er is proton en vulkan, maar dat is slechts een klein deeltje van het geheel. Investeren in een sluitend pakket lijkt me echt geen luxe, die opties zijn er vandaag gewoon.

Dat is de kern van de zaak: Technisch kan Valve waarschijnlijk wel de benodigde bibliotheken zelf installeren. Als Ubuntu het evenwel enkel belangrijk vindt dat software in de repo's functioneert, dan is de kans dat Valve zich in de toekomst in nog meer bochten moet wringen. Spellen zijn een softwaresoort die nagenoeg altijd in binary-vorm komen en zelden langdurig geactualiseerd worden. Een distributie die niet bereid is om dat te ondersteunen is simpelweg geen goede distributie voor amusement. Voor Valve is er dan ook geen reden om Ubuntu nog langer als voorkeursdistributie voor Steam te behandelen.

Er zijn toch genoeg manieren vandaag om dit technisch netjes voor mekaar te krijgen zonder jezelf in bochten te wringen. Of een FTE sponsoren bijvoorbeeld.

Het gaat erom dat als iets éénrichtingsverkeer is, je niet de goede partner hebt. FTE's sponsoren doet Valve genoeg, maar als die FTE het werk moet doen met een weinig meewerkende rest van de gemeenschap (binnen Linux niet vreemd), schiet het niet op. Je wilt een partner die het belang ziet, en dan kun je overwegen een handje te helpen.

100% oneens, maar dat mag hé. Daarvan ga ik je niet kunnen overtuigen.

Ik heb al 10 jaar geen 32-bit besturingssysteem gebruikt en wat mij betreft mag de ondersteuning nu echt wel gestaakt worden. Het kost veel tijd zonder noemenswaardig voordeel. Valve kan nu de ondersteuning voor de benodigde libraries het best zelf voor zijn rekening nemen of een soort samenwerkingsverband creëren om gezamenlijk deze libraries te onderhouden. Of Canonical gewoon betalen om deze ondersteuning alsnog beschikbaar te houden.

Je kan nog zo geïnteresseerd zijn en enthousiast worden van een OS, maar dat OS is er uiteindelijk om de software te gebruiken die jij nodig hebt of graag wilt gebruiken. Als het OS dat niet doet of niet meer wilt doen, zal je, je heil elders moeten zoeken.
Dat Steam zou moeten betalen voor de support is mijns inziens toch wel echt de omgekeerde wereld. Het gaat namelijk niet alleen om de Steam applicatie, maar ook om de games zelf.
Verder vraag ik me af of jij in je 64bits OS echt helemaal geen 32 bits applicaties gebruikt.

Ik gebruik inderdaad geen 32-bit applicaties, omdat ik de behoefte daaraan helemaal niet heb. Alle programma's die ik gebruik, zijn native 64-bit, op x86, ARM en POWER. Spellen op Steam speel ik helemaal niet, hoewel ik vandaag een account heb aangemaakt om het eens uit te proberen. Maar ik ben niet bereid ervoor te betalen, zolang niet alles native 64-bit is.

De vraag is waarom er op x86 een uitzondering moet worden gemaakt, terwijl ze dat op alle andere architecturen helemaal niet hoeven te doen en dus ook niet doen. Valve zou kunnen doen wat elk weldenkend bedrijf in de 21ste eeuw doet en alles als 64-bit kunnen uitbrengen.

er staan nou eenmaal een lading games op steam die 32-bit libraries nodig hebben. zelfs als steam hun eigen app volledig voor 64-bit zou bouwen kun je niet verwachten dat alle gamedevs jaren-oude games ook naar 64-bit gaan brengen. valve is alleen een distributeur dus die kan dat niet zelfs al zouden ze het willen.

Als de flatpak "gewoon werkt", en Steam niet twijfelt aan het cateren aan Linux gebruikers, en flatpak is hier speciaal voor gemaakt (Flatpak: The days of chasing multiple Linux distributions are over. Standalone apps for Linux are here!), wat is dan het probleem waardoor Valve met dit nieuwsbericht komt?

Is het maken van de pak erg lastig? Is de performance subpar? Of roept Valve dit uit irritatie terwijl het effectief niet zo'n probleem hoeft te zijn?

Ik gebruik al meer dan een jaar de Flatpak versie van Steam, ook op Ubuntu of Debian. Ik vind het net handig dat je geen schrik moet hebben dat een upgrade van je systeem ineens niet meer wil werken met Steam. Vroeger heb ik wel eens meegemaakt dat je OpenSSL of wat dan ook update, en plots werkte de helft van Steam niet meer. Met Flatpak ben ik zoiets nog nooit tegen gekomen.

Flatpak is inderdaad de oplossing, precies gemaakt voor dit soort dingen. Super simpel om te installeren en sandboxed.

Maar 15 GB runtimes hier voor 10 GB applicaties. Ik heb die piste intussen weer verlaten.

Welke distro is dat? Op Fedora is Steam ~60MB. Heb ook Skype en Riot installed. Samen met de bundled dependencies kom ik op ~1.5GB.

Wanneer je alle gedeelde dependencies optelt van RPM/DEB files is het alsnog met een Flatpak meer, maar niet dramatisch veel. Het voordeel met Flatpaks is dat software developers voor alle distro's software kunnen releasen. Dat is die paar honderd meer MB's op je disk wel waard, vind ik. Plus de extra security die het biedt. Ook niet verkeerd, aangezien Skype en Steam closed source zijn, dat mag best in een sandbox.

Vorige reactie niet doorgekomen zo blijkt.
Standaard Ubuntu LTS 18.04.

Je cijfers zullen ongeveer kloppen. Ik had 3x Gnome, 2x KDE, 2x Freedesktop, enkele malen Nvidia, en dan nog wat themes. Bijna een stack per app, dat is de kern van het probleem denk ik.

Let wel: ik zie er absoluut toekomst in, maar niet op deze manier.

Een nadeel is wel dat Ubuntu standaard geen flatpak ondersteund, dit moet je los installeren. Wellicht zou een Snap versie het voor de end-user makkelijker maken als ook deze om kan gaan met 32-bit OpenGL binnen een package.

Een Flatpak bundelt al zijn run time dependencies. Canoncial heeft inderdaad zijn eigen Snap. Maar sinds Ubuntu als default nu weer GNOME gebruikt kunnen ze net zo goed ook overstappen op Flatpak. We moeten niet weer verschillende installatie formats hebben waardoor er een split is van opties.

Ja en Ubuntu heeft er tegenwoordig ook een handje van om de idiootste dingen in snaps te stoppen.

Snaps/flatpaks hebben voordelen in sommige situaties. Dingen als de 'luie developer' (zelfde als waar Electron op teert), maar ook het voorkomen van versieconflicten van speciale extra-oude of juist nieuwe libraries die sommige apps nodig hebben. Speciale architecturen.

Maar het verbruikt enorm veel extra geheugen en diskruimte door al die kopieen van al die libraries die elke app apart meelevert, en ook werkt het optimaliseren van shared memory hier niet meer door alle verschillende versies die tegelijk in gebruik zijn. En een vulnerability in iets als OpenSSL is ook niet meer zo 1-2-3 gepatcht omdat je niet alleen de lib op je systeem moet updaten maar ook elke snap maintainer dit moet doen

Dus, ik zou zeggen: Gebruik deze techniek voor de apps waar het echt nodig is. Maar Ubuntu is als een dolle hond bezig om alles op hun heilige snap techniek over te zetten, zelfs commandline tooltjes van een paar kb en die ook vaak de default maken in hun store.

En laten we eerlijk zijn: De 'library hell' van Ubuntu bestond helemaal niet. Er was helemaal geen probleem, dit was iets uit de vroege jaren '00 maar dit is allang door de uitstekende pakketbeheer programma's opgelost.

Dit moet inderdaad niet voor alles gebruikt worden, slechts voor de apps waar het handig is (licentie-wise of in het geval van Steam). Maar volgens mij valt dat wel mee met vulnerabilities. Flatpaks bundelen dan wel al hun dependencies, maar dat zijn dan nog wel gezamenlijke Flatpak dependencies. OpenSSL en zo zitten volgens mij allemaal in de FreeDesktop base. Die moeten dan nog wel goed bijgehouden worden, maar het is niet zo (volgens mij) dat iedereen maar wat gaat doen. Het kan wel natuurlijk, maar als iedereen FreeDesktop compatible builds maakt, dan zit het wel goed.

[Reactie gewijzigd door UPPERKEES op 23 juni 2019 18:30]

De "dolle hond" mentaliteit heeft mij heel lang geleden al doen beslissen om Ubuntu niet meer te gebruiken. Ubuntu kan zo ineens het roer omgooien. Tevens maken ze zo nu en dan vreemde beslissingen.

Unity was zoiets maar ook mir. Als ze al die developer tijd nou eens in een bestaand project hadden gestoken (Gnome, Wayland) was iedereen daar veel beter uitgekomen.

Er is vanuit beveiligingsonderzoekers aardig kritiek op flatpack om de simpele reden dat het een beetje op .exe bestanden kunnen gaan lijken.

Betreft 32bit. Debian heeft losse bestanden . Heb jij een programma dan is de arch: arm, MIPS, 32 bit, of 64 bit. Dit kan Ubuntu ook gewoon doen (doen ze nu waarschijnlijk al)
Is wel tekenend dat de 1 van de meest commerciële distros dit gebeurt. Anderen hadden eerst een stemming binnen hun gemeenschap gehouden denk ik.

Wat is er inherent mis met .exe bestanden?

het komt niet uit een appstore dus iedereen kan ze zomaar aanbieden, ook mensen met minder goede bedoelingen. De controle is een beetje weg.

Als ik zo lees wat flatpack doet lijkt het meer op een appv package dan een executable. Bij appv kun je al de dependencies meeleveren in 1 package en heb je geen last van versies.
Vanuit beveiliging is het echter zo dat je ze wel moet bijhouden. Als een dependency een update krijgt zal je eigenlijk je hele package ook moeten updaten, ookal draait het in een sandbox.

Ik volg ook al een paar dagen deze ontwikkelingen, er is veel ophef over in de Linux community en er wordt Ubuntu verweten dat ze als mainstream distro het gebruikers nu te moeilijk gaan maken omdat dit wine ontzettend schaad.

Ik snap niet helemaal het probleem, vanuit Ubuntu's perspectief.

Arch Linux draait ook al een tijd enkel op 64 bit systemen. Wel is er een aparte officiële repository met 32 bit gecompileerde packages specifiek voor zaken zoals Steam, Wine, etc. Daarmee is het nog steeds mogelijk om deze software onder Arch Linux te gebruiken.

Kan Ubuntu niet zoiets als dat implementeren? Volgens mij is dat echt nodig om bepaalde (gesloten) software onder Linux te kunnen gebruiken. Als Ubuntu gebruiksvriendelijk wilt blijven, dan denk ik dat dit echt nodig.

[Reactie gewijzigd door The Zep Man op 23 juni 2019 13:17]

Natuurlijk kan dat op papier. Ubuntu heeft 7 lagen van software in hun beheerde repositories. Ze zouden prima alle 32bit libs naar 'backports' kunnen verplaatsen en dan valt het in de categorie niet-ondersteunde componenten. De facto haalt dat natuurlijk niets uit, want iedereen zet dan gewoon het vinkje aan, wat betekend dat Ubuntu dan nog steeds klachten krijgt als het niet werkt.

Er is ook al over gesproken om deze libs op te nemen in een community beheerde repo of in de repo van bijvoorbeeld het Wine project, maar niemand is hier happig op omdat dit wel heel beveiligings- en stabiliteitsgevoelig is.

Voor mensen die een alternatief willen:
Manjaro heeft Steam voorgeïnstalleerd! (als je niet weet welke versie je wilt, kies de XFCE - die is het vlotst)

Ik heb Manjaro op een cheapo laptop met een Atom Z-8350 (niet echt snel dus), maar het loopt wel (relatief) vlot op zulke slappe hardware!

Waarschijnlijk zal een tiling window manager iets vlotter zijn, maar dan is steam niet automatisch geïnstalleerd, volgens mij. Maar Steam is alsnog binnen 2 minuten geïnstalleerd. Er gaat niets boven i3-gaps, voor mij, maar het is niet bepaald inuïtief.

Als software developer snap ik niet echt niet waarom valve niet gewoon een 64bit versie van steam compiled. Zou het misschien iets met DRM zijn dat gemaakt is exclusief voor 32 bit systemen?

Proton heeft deels 32-bit libs nodig, en de games hebben 32-bit libs nodig.
Steam zou hier wel omheen kunnen werken via hun runtimes maar missen dan mogelijk nog steeds 32-bit driver ondersteuning voor OpenGL games die 32-bit zijn. Dit zijn namelijk packages die steam moet installeren als deze de eerste keer start en die zullen hierna niet langer beschikbaar zijn.

Als software developer zou je juist moeten snappen dat veel games 32-bits zijn en dat grote aantallen van de library van mensen plotseling niet meer gaat werken als ze 32-bits zouden laten vallen.

Ah ik had niet door dat het ging om alle games en libraries, dacht dat het probleem puur bij de steam client lag. Je kan dan hopelijk nog wel alle 64 bits games opstarten op Ubuntu. Ook al wordt de client niet officieel ondersteund.

Nee, ook Steam is een 32-bit applicatie, dus zelfs 64-bit only games zullen niet opstarten.

Dat was ook ooit het geval met o.a. de C64, maar daar klaagt ook niemand meer over. Dus tijd dat 32-bit eenzelfde afscheid krijgt; net als voor bijv. de C64 komen er heus wel goede emulatoren.

Je hebt het wel even over een totaal andere gebruikersgroep en realiteit tussen 32 bit gebruikers en C64 gebruikers.

Ik durf ook wel te stellen dat, ten tijde van de opheffing, er een heel stuk minder mensen C64 spellen speelde dan dat er nu mensen zijn die 32bit spellen spelen. En die groep C64 gebruikers zijn ook niet echt te vergelijken met huidige gebruikers. (Alhoewel we het natuurlijk wel over Linux gebruikers hebben hier).

En die emulators zullen er vast wel komen idd, alleen heeft Valve dus blijkbaar geen zin om dat te gaan doen.

Wat ik mij vooral afvraag in deze disccussie, wat is nu de reden om te stoppen met deze ondersteuning? Kost dit nog heel veel moeite om te blijven ondersteunen ofzo?

Ik zei ook "o.a.". Je kunt vast zelf ook nog wel een platform bedenken

Maar inderdaad gaat het hier alleen om Ubuntu-gebruikers, dus zelfs als we alleen focussen op C64 dan is het wel degelijk vergelijkbaar.

Ok... maar de opvolger van de C64 was backwards compatible....

Op dit moment is het installeren van een set bibliotheken (ze hoeven alleen maar op de harde schijf te staan) gewoon een stukken eenvoudiger optie dan een 32-bits besturingssysteem virtueel te gaan draaien.

Op het moment dat processoren 32-bit dumpen, of de Linuxkernel 32-bit dumpt, dan komt emulatie wellicht in beeld.

Dus tijd dat 32-bit eenzelfde afscheid krijgt; net als voor bijv. de C64 komen er heus wel goede emulatoren.

Er is niks om te emuleren, de hardware ondersteund 32-bit (x86) instructies en de 32-bit games kunnen ook gewoon overweg met moderne hardware. Een "emulator" bouwen zou in dit geval hetzelfde zijn als 32-bit packages shippen.

Je argument zou veel logischer zijn als we massaal aan het overstappen zijn naar ARM64 voor onze desktop PCs, maar dat is nog niet het geval.

Die vergelijking gaat nergens over natuurlijk. Ja het zijn beide een personal/home computer, maar daar houden alle vergelijkingen wel op. Het is compleet verschillende hardware van verschillende fabrikanten. Dat is hetzelfde als verwachten dat Sony's playstation 5 backwards compatible zou moeten worden met Microsoft's Xbox lijn, of met de consoles van Nintendo.

Tuurlijk, was commodore gewoon doorgegaan met die lijn van apparatuur dan hadden we vast nog een tijd compatibiliteit gehad. Een concurrerende fabrikant met een andere architectuur is echter dominerend geworden, en die cross compatibility is er nooit geweest.

Kan zijn dat een hoop dependancies geen 64bit support hebben. je kunt trouwens niet zo maar iets naar 64bit compileren zonder alle code goed na te lopen en zeker te zijn dat alles correcte size is.

Ubuntu is gebaseerd op Debian, en die ondersteunt wel 32-bit (vanaf de Pentium Pro/2).
Dus zomaar 32/64-bit compilen is voor Ubuntu niet zo'n big deal, ze kunnen meestal gewoon het Debian pakket gebruiken.
Sowieso doen ze dat al grotendeels, het is zeldzaam dat ze "core" code aanpassen, hooguit wat cosmetische dingen of een patch hier en daar voor extra features.
Evengoed is het wel een flinke extra last om dat daadwerkelijk echt volledig te supporten, dus als te weinig users dat nodig hebben, is het begrijpelijk dat ze dat willen beeindigen.
Maar tussen volledige 32-bit support (met aparte kernel, installer/livedvd, volwaardige repo met alle pakketten), en helemaal niks, zouden ze nog een minimale selectie 32-bit libs kunnen aanbieden.
Dan zijn ze iig af van de last om uucpsend, zmf2epub, en al die andere obscure tools die vrijwel niemand gebruikt te hoeven supporten.

T gaat hier over wine en games die 32bit zijn.

Wel grappig om te lezen dat mensen oplossingen aandragen om Steam alsnog werkend te krijgen op Ubuntu, maar dat het te moeilijk zou zijn voor de doorsnee gebruiker. Newsflash: De doorsnee gebruiker van Steam zit op Windows, niet op Ubuntu.

Dat klopt. En voordat je überhaupt kan game moet je eerst videokaart drivers installeren en dat kan een gemiddelde gebruiker al helemaal niet op Linux.

Of je moet steamos gebruiken, dan gaat het wel vanzelf volgens mij.

Uw reactie geeft mij het idee dat u nog nooit Linux heeft gebruikt of de laatste keer dat u het wel heeft gebruikt is 10 jaar geleden.

Als je een Intel of AMD GPU hebt hoef je geen drivers te installeren. Basic display drivers zitten in de Linux kernel en drivers voor OpenGL, Vulkan etc.. zitten in MESA dat wordt meegeleverd in vrijwel elke 'beginners' distro.

Als je een Nvidia GPU hebt hoef je voor distros zoals Pop!_OS en de toekomstige Ubuntu 19.10 niks te doen behalve toestemming te geven voor het installeren van niet-vrije software, de drivers worden mee geleverd. Op Ubuntu 19.04 en eerder hoef je alleen maar een vinkje te zetten in het doosje waarnaast staat "Installeer niet-vrije software." tijdens de installatie en dan vervolgens kan je meet een aantal klikjes de driver installeren via het "Drivers en software" programma. Dit systeem is stukken makkelijker te gebruiken dan Windows naar mijn mening waarbij je de software online moet downloaden en daarna door een Wizard heen moet.

[Reactie gewijzigd door Omega op 23 juni 2019 15:52]

Dit systeem is stukken makkelijker te gebruiken dan Windows naar mijn mening waarbij je de software online moet downloaden en daarna door een Wizard heen moet.

Windows doet het ondertussen automatisch als je zelf geen drivers installeert.

Windows haalt inderdaad meeste drivers en driver updates zelf op via Windows Update. Maar regelmatig zie ik Windows daarmee fouten maken of ernstig verouderde drivers installeren. In sommige gevallen zoals bij een defecte secondary GPU in een laptop wil je misschien wel geen driver installeren of je wil misschien een nieuwere driver installeren dan Windows Update levert, maar voordat je de kans krijgt automatische driver installatie uit te zetten heeft Windows de drivers gedownload en geïnstalleerd wat ernstig hinderend kan zijn.

Een mooi idee op papier, maar het werkt gewoon niet omdat drivers niet up-to-date worden gehouden door veel fabrikanten, niet in Windows update zitten en omdat het op je word geforceerd.

Wat is er mis met nouveau?

Afschuwelijke prestaties, niet compatibele met alle Nvidia GPUs. Voornamelijk met laptop GPUs is Nouveau een ramp (Niet dat het heel veel beter is dan de proprietary drivers die kunnen ook dramatisch zijn in laptops).

Nouveau is goed genoeg om een beeld op het scherm te krijgen zodat je de proprietary Nvidia drivers kan installeren.

Als je FOSS minded bent denk ik niet dat je een Nvidia GPU zal kopen als je grafische rekenkracht nodig hebt, dan zou je wel voor een Intel of AMD gaan.

Maar ja als je iets hebt zoals een GT 1030 dan zou je die prima op Nouveau kunnen draaien.

En met die instelling zal linux altijd een buitenbeentje blijven.
En is dat ook de reden dat het na 20 jaar nog steeds geen volwaardig alternatief is. Behalve voor een selecte groep gebruikers die voor lief neemt dat ze een hoop of helemaal niet of met beperkingen/trager/minder makkelijk kan doen.

Het is gewoon dom om 32 bit te laten vallen niets meer niets minder en zal dan ook voor een groot deel die het wel gebruikt het einde van ubuntu zijn.
Hun loss voor de gebruiker zijn er toch wel betere oplossingen.

[Reactie gewijzigd door computerjunky op 23 juni 2019 13:16]

Of is het dom van Steam om op 32 bit te blijven zitten? Iemand moet eens de eerste zijn die een stap neemt. Misschien juist wel een mooi moment voor Epic om in te stappen in Linux/Unix? Je hoeft je niet door 1 bedrijf maar alles altijd laten op te leggen.

Linux is trouwens al lang geen buitenbeentje meer in de commerciële markt, verre van dat. In de consumentenmarkt ligt dat natuurlijk wel anders, maar het is niet dat linux geen bestaansrecht heeft omdat je er geen games op kan spelen.

[Reactie gewijzigd door Fraaank op 23 juni 2019 13:29]

Er is helemaal niks doms aan. Voor compatibiliteit mogen ze van mij gewoon op 32bit blijven. Het probleem is dat een zeer groot aantal van de games op Steam 32bit zijn en die niet meer zullen werken tenzij Valve daar omheen weet te komen en hun eigen 32bit libraries in Steam inbegrijpt.

Op MacOS krijg ik van het besturingssysteem continue meldingen dat Steam niet 64 bit is. Voor zo groot bedrijf snap ik echt niet dat ze inmiddels geen 64 bit versie hebben. Tevens vindt ik de interface echt snel en lomp aan voelen.

Ik denk omdat meer dan 70% van de steam applicaties een 32-bit applicatie is.
Ergens vind ik het een goede zet dat Valve ervoor heeft gekozen dat de ondersteuning van hun bibliotheek belangrijk is in het mee nemen van zo'n besluit.

Ik vind het laten vallen van 32-bit ook een zeer grote stap, het was beter geweest als ze slechts de support hadden laten vallen, maar het het verder nog wel zouden ondersteunen (bijvoorbeeld door wine standaard te gaan combineren met hun platform)

Maakt voor de cliënt toch niet uit of een spel 32 of 64 is, in dit geval voor de Steam app?

Als je steam client wel 64 bit is, maar een groot deel van je games dat niet zijn, kan dat wat lastig uit te leggen zijn aan je gebruikers. Dan is kiezen voor een linux distributie die wel 32 bit wil ondersteunen een best logische keuze.

Als je Steam opnieuw van de website downloadt, dan is het volledig 64-bits. Er zit blijkbaar een component in dat niet bijgewerkt wordt door de automatische updates.

Dat de interface lomp aanvoelt heeft niks met 32 of 64bit te maken. Steam is gewoon een beetje ouderwets met hun interface, het is natuurlijk ook gewoon webpaginas in een wrapper. Ze gaan binnenkort echter wel met een volledige overhaul komen, hopelijk maakt dat alles wat sneller.

Die waarschuwingen krijg je omdat vanaf Catalina (deze herfst) 32-bit op Mac ook niet meer gesupport wordt. Die popups zitten er al in vanaf High Sierra, de vorige versie, dus 2 jaar lang zijn deze getoond voor het echt uitgeschakeld wordt.

Dus Valve zal wel moeten...

[Reactie gewijzigd door GekkePrutser op 23 juni 2019 15:49]

Of niet. Linux en Max zijn qua gaming nog altijd maar een heel klein deel van de markt. En Microsoft kan het zich niet veroorloven 32-bit te droppen, mede vanwege dat overwicht op de gaming-markt.

Steam doet al jaren zo goed als niks aan ontwikkeling. Die app is nog steeds gebouwd voor een 800x600 scherm lijkt het. Ze verdienen genoeg zonder te investeren aan ontwikkeling aan dat platform.

Vulkan, Proton... ze doen een reuzeberg werk op de achtergrond. De Steam-applicatie werkt prima, die aanpassen aan de laatste modetrend valt in het niet bij het belang om de afhankelijkheid van Microsoft te verminderen.

Het probleem zit hem er niet in Steam zelf. Dat is vrij snel op te lossen maar een grote library aan games die nog 32bit zijn.

En dan vooral bij de oudere games waarvan de developer inmiddels al jaren ter ziele is gegaan of is opgenomen door een grote publisher, noem voor het gemak EA. Ik denk dat het voor Ubuntu handiger is om gedeeltelijk 32 bit nog te behouden, gezien een hoop mensen deze distro gebruiken, al dan niet in combinatie met Steam . . .

"En dan vooral bij de oudere games waarvan de developer inmiddels al jaren ter ziele is gegaan of is opgenomen door een grote publisher"

Dat is inderdaad een groot probleem. Daarom ook dat je op elk OS out-of-the-box C64-spellen kunt spelen, want o wee als ze die backwards compatibility ook al zouden schrappen... Oh wacht, die is allang geschrapt omdat men niet in het verleden wil blijven hangen, dus is het tijd dat 32-bit ook volgt. Net als voor bijv. de C64 komen er heus wel goede emulatoren.

Toen Nintendo de SNES introduceerde vond niemand het raar dat deze geen NES-spellen ondersteunde. Maar moet je nu eens kijken als Microsoft een nieuwe XBox uitbrengt die geen oude spellen ondersteund... tijden zijn veranderd.

Tijden zijn helemaal niet veranderd of in ieder geval was backwards compatibility al een lange tijd de gang van zaken. Toen Nintendo de Wii uitbracht werden Gamecube spellen nog gewoon ondersteund, omdat de hardware het nog steeds ondersteunde. Zelfde geldt voor de Playstation 2 die nog Playstation 1 spellen ondersteunde. En vergeet de Gameboy niet waarbij backwards compatibility praktisch 20 jaar nooit is verbroken.

Pas wanneer het hele architectuur veranderd laat je backwards compatibility vallen. Dit was het geval bij de overstap van de Playstation 3 naar de Playstation 4.

[Reactie gewijzigd door Armada651 op 23 juni 2019 14:15]

Goede analyse, maar weinig relevant voor de eindgebruiker. Hoeveel % van de XBox-gebruikers denk jij dat weet welke processorarchitectuur hun console gebruikt?

Pas wanneer het hele architectuur veranderd laat je backwards compatibility vallen. Dit was het geval bij de overstap van de Playstation 3 naar de Playstation 4.

De PlayStation 3 had een revolutionaire nieuwe processor, de Cell Broadband Engine, die zijn gelijke nog moet vinden. Toch hadden de eerste PlayStation 3’s daarnáást ook de PlayStation 2 e-motion chip aan boord om backwards compatibel te kunnen zijn. Geen: ‘sorry beste klanten, andere architectuur enzo’. Slecht voorbeeld misschien, volgens mij zijn er altijd issues geweest met PlayStation 2 spellen op de PlayStation 3, maar het geeft wel aan dat Sony het toen belangrijk vond (en de PS3 zo schreeuwend duur was dat zo’n oude chip de prijs nauwelijks verhoogde).

[Reactie gewijzigd door 84hannes op 23 juni 2019 18:37]

Goede analyse, maar weinig relevant voor de eindgebruiker.

Ik bekeek het meer vanuit het oogpunt van een developer, niet het oogpunt van een eindgebruiker.

Toch hadden de eerste PlayStation 3’s daarnáást ook de PlayStation 2 e-motion chip aan boord om backwards compatibel te kunnen zijn.

Extra hardware toevoegen voor backwards compatibility is minder ongebruikelijk dan je zou verwachten, de Gameboy Advance had naast een ARM processor ook een Z80 processor voor oude Gameboy games.

[Reactie gewijzigd door Armada651 op 23 juni 2019 18:55]

De Sega Megadrive is ook een leuke: Die had een Z80-processor aan boord die door 16-bit spellen gebruikt werd voor het geluid. Er was een volledig passieve converter voor te krijgen waarmee je cartridges voor de 8-bit Sega Master System kon inprikken. In dat geval werd de 68000-processor uitgeschakeld en was de Z80 volledig de baas.

Extra hardware toevoegen voor backwards compatibility is minder ongebruikelijk dan je zou verwachten, de Gameboy Advance had naast een ARM processor ook een Z80 processor voor oude Gameboy games.

Dat van de GameBoy wist ik niet, en @dmantione laat ook een leuk feitje zien. Het onderstreept precies wat ik bedoel (maar blijkbaar niet duidelijk overbracht): backwards compatibile zijn is een keuze gericht op de markt (de eindgebruiker), niet een keus gebaseerd op de hardware (developer).

Fair point, het is inderdaad belangrijk voor de eindgebruiker. Maar als de hardware het ondersteunt is er altijd backwards compatibility geleverd omdat developers weten dat je een hele goede reden moet hebben om dat niet te doen.

Nog een leuk feitje over de Gameboy Advance: er zit een fysieke knop in de cartridge slot die bepaalt of de Z80 processor wordt gebruikt. Advance cartridges hebben een inkeping aan de onderkant waardoor die knop niet ingedrukt wordt.

[Reactie gewijzigd door Armada651 op 24 juni 2019 11:02]

Maar als de hardware het ondersteunt is er altijd backwards compatibility geleverd

Met het risico dat we ons verliezen in de details (en wat is er leuker dan dat?):
De Wii ondersteunde GameCube spellen, de Wii U ondersteunde Wii spellen, maar niet GameCume spellen. Ergens is dus bewust een ondersteuning laten vallen.
De Wii is feitelijk een GameCube met andere randapparatuur: een grotere CD-speler, wifi en andere controllers. Daarom heeft de Wii een aansluiting voor GameCube controllers: er is extra hardware toegevoegd om GameCube spellen te kunnen spelen (al kon dit volgens mij ook met een nieuwe controller)! Bij de Wii U is deze extra hardware weggelaten, maar omdat Wii spellen speelbaar zijn zou GameCube support (al dan niet met een nieuwere controller) waarschijnlijk relatief eenvoudig zijn geweest. Nintendo heeft er in mijn ogen expliciet voor gekozen N-1-compabiliteit te leveren. Opnieuw: marketingkeuze, geen ontwikkelkeuze.

Nog een leuk feitje over de Gameboy Advance

Die is wel leuk ja.

EU PS3's hebben nooit de Emotion Engine ingebouwd gehad. Alleen de RSX GPU, wat ook (groten)deels de mindere comptabiliteit verklaart van sommige PS2 spellen op de PS3.

PS3 ondersteunde ook nog steeds de PS1, en de eerste ook nog PS2.

Het verschil is hier wel dat de hardware nog prima 32-bit ondersteund, maar geen enkele hardware ondersteuning heeft voor C64. Het zou nogal onlogisch zijn om iets te gaan emuleren wat de hardware nog prima ondersteund.

Een betere vergelijking zou DOS games zijn: een 64-bit (x86-64) processor ondersteund nog steeds 16-bit instructies, echter gebruiken we daar nu DOSBOX voor om het te emuleren. Maar ook dat is niet echt een goede vergelijking, omdat de meeste 16-bit applicaties een hele andere modus van de CPU verwachten (real mode) die niet ondersteund wordt in combinatie met 64-bit ondersteuning.

Mijn mening is dat backwards compatibiliteit enorm belangrijk is voor een OS en dat is iets dat Microsoft al lang heeft begrepen. De enige goede reden om backwards compatibiliteit te laten vallen is wanneer het niet meer mogelijk is op moderne hardware.

De Linux kernel community begrijpt dit wel ("we do not break userspace"), echter lijkt er nog geen gebruikersvriendelijke distributie te zijn die dat even belangrijk vindt. Dit is een van de voornaamste redenen dat ik nog steeds Windows gebruik.

[Reactie gewijzigd door Armada651 op 23 juni 2019 13:53]

Moderne processoren ondersteunen nog steeds 16-bit software, doch alleen als het besturingssysteem 32-bit is. Zodra de 64-bit mode van de processor geactiveerd wordt, is het niet langer mogelijk 16-bit segmenten te alloceren of de vm86-mode te gebruiken. De enige uitweg is virtualisatie: Via de virtualisatieopties in de processoren zou je alsnog 16-bit software kunnen draaien.

Software zoals Dosemu werd dan ook waardeloos in het 64-bit tijdperk. Je zou kunnen herschrijven door van virtualisatie i.p.v. vm86 gebruik te maken. Dat is echter een keus die de softwareontwikkelaars niet genomen hebben: Het emuleren van de gehele hardware door middel van Dosbox presteert inmiddels prima voor oude software en Dosbox heeft het voordeel dat het ook de oude hardware zoals Soundblasters emuleert.

Op windows 64 bit werken 16 bits toepassingen niet meer. Op linux 64 bit met wine wel. Vm86 wordt dan niet meer ondersteund, maar 16 bit protected mode toepassingen wel, en laat nou Windows vanaf versie 3.0 nou in de protected mode draaien.

Daarom ook dat je op elk OS out-of-the-box C64-spellen kunt spelen, want o wee als ze die backwards compatibility ook al zouden schrappen..

Compleet andere architectuur, niet te vergelijken... en de opvolger van de C64, de 128 was wel degelijk backwards compatible.

Dit verklaart ook waarom dit probleem redelijk uniek is voor games. Die worden uitgebracht en na een half jaar niet meer onderhouden. Het grootste deel van alle desktop software wordt constant door ontwikkeld en geüpdatet.

Dat is mijn ogen nog altijd geen heel goed argument. Ik snap dat er heel wat games geen 64-bit support hebben maar dit zou toch perfect in de UI opgevangen kunnen worden met een 'niet compatibel voor uw systeem'-label? Zo kan je nog altijd games spelen die wel ondersteund worden in plaats van wel... gewoon geen.

Een 32-bit omgeving, middels conversie of als een heel virtueel systeem bovenop een 64-bit systeem draaien is volgens mij niet zo'n groot probleem. Ik denk zelfs dat daar wel voordelen uit te halen zijn ten opzichte van een native 32-bit OS, zoals meer cores en RAM. Je kan parallel aan je game-proces optimalisaties doen zonder bijkomende CPU impact.

Ik denk dat het probleem wel bij Steam ligt. Ze kunnen de eindcontrole over de fysieke graphics-hardware niet loslaten, want dan redt iedereen zich ook wel zonder Steam. Directe communicatie tussen (OSS) programmatuur van derden en die hardware gaat nooit gebeuren.
Stel je voor dat alle oude 32-bit games ineens vlekkeloos werken op een volledig open Linux systeem met een driver die zich automatisch als dependency installeert...

Nou ben ik benieuwd of Ubuntu dit als een "oh shit... Dat was niet de bedoeling"-moment gaat ervaren en wellicht toch nog de ondersteuning voor 32-bits gaat verzorgen, of dat ze al hadden voorzien dat Steam zou vertrekken.

64-bits CPU's bestaan al heel erg lang. Prima dat de ondersteuning daarvan richting vuilnisbak gaat. Ik kan het mij niet voorstellen dat er nog veel mensen zijn die een computer gebruiken met 32-bits CPU. Dan heb je het over desktops van 20 jaar oud.

Snap ik, maar het valt natuurlijk niet te verkopen dat een ander besturingssysteem op dezelfde hardware het wel gewoon kan draaien aan de eindgebruiker die software wil draaien met enkel 32-bits ondersteuning.

Ik zou er zelf niet heel veel last van hebben, ik game eigenlijk nooit. (Pas op, patience en mijnenveger wil ik nog wel eens doen.) Maar de softwareondersteuning voor games op Linux ligt al lager. Nu doet Ubuntu er nog een schepje bovenop.

Er zijn wel heel wat spelklassiekers van 20 jaar oud waar mensen nog geen afscheid van willen nemen... het is niet minder dan waardevol cultuurerfgoed. Veel energie die Valve spendeert, bijvoorbeeld met Proton, is juist gericht op compatibiliteit bieden met dit erfgoed. Als een distributie daar het belang niet van in wil zien, dan vind ik het prima dat die distributie richting de vuilnisbak gaat...

64-bits CPU's bestaan al heel erg lang. Prima dat de ondersteuning daarvan richting vuilnisbak gaat.

Wellicht, maar het gaat hier niet om de ondersteuning van 32-bits hardware, maar om de 32-bits software die ook niet meer ondersteunt wordt door Ubuntu.

En zo blijft gamen nog steeds een Windows dingetje.

Kan Valve niet gewoon een 64bit versie van steam uitbrengen?

Dat kunnen ze wel, maar hebben ze waarschijnlijk om compatibiliteitsredenen tot nu toe niet gedaan. Van mij mag alles voortaan voor AMD64 en ARM64 uitkomen en de 32-bit spellen via virtualisatie en emulatie. Ik houd bij het aanschaffen van hardware echt geen rekening met antieke software, hoe leuk deze oude spellen ook mogen zijn.

Meestal speel ik toch eerder games voor consoles op emulatoren en die werken op bijna ieder soort hardware. Eigenlijk is het al gek om 32-bit te blijven onderhouden voor een compatibiliteitslaag voor een ander besturingssysteem om closed source spellen te spelen. Laat Valve dan zelf maar met een containeroplossing komen, wellicht met ondersteuning voor emulatie op niet-x86 architecturen.

Van mij mag alles voortaan voor AMD64 en ARM64 uitkomen en de 32-bit spellen via virtualisatie en emulatie.

Probleem daarbij is dat de laatste generatie spellen die uitsluitend in 32bit is uitgekomen ook van moderne hardware nog aardig wat kan eisen. The Witcher 2 of vergelijkbare spellen uit die periode via een extra emulatie laag draaien word nog een uitdaging.

Op dat gebied is het jammer dat het bij games zolang heeft geduurd voordat men met standaard met een 64bit versie kwam; als dit meteen was gebeurd waren de problemen een stuk kleiner

Dat kan, maar dan zullen veel oudere games niet werken. En Proton/WINE zal dan ook niet (volledig) functioneel zijn. Daarnaast zullen niet officieel op Linux ondersteunde clients zoals Battlenet, Uplay en Origin ook niet meer draaien.

Stopt Ubuntu dan helemaal met 32-bit en dus ook geen libs meer, of hoe moet ik het zien?
Bij Arch Linux worden deze libs nog gewoon aangeboden in de multilib repo, ondanks dus dat ondersteuning is gestopt.

Dat zou best vaag zijn, want ook de officiële Steam cliënt heeft dit nog steeds nodig, al zou een fatsoenlijke moderne rewrite beter zijn.

Verder zijn er genoeg andere oplossingen beschikbaar en kan ik de keuze van Ubuntu opzicht ook wel begrijpen, zij moeten die pakketten tevens onderhouden en blijven hosten. Waarom niet gewoon een ppa, flatpak of andere oplossing gebruiken voor mensen die het perse willen hebben?

Ik heb een tijdje gestoeid met Windows-software/games op Linux en het bleek dat veel geporte software uiteindelijk toch eigen libs nodig hadden (dus ook een DLL-hell gingen vormen op mijn systeem maar dat terzijde). Giet het dus in een andere vorm, kap met die onnodige 32-bit Steam cliënt en globale x32-libs die toch niet compatibel zijn met elkaar.

[Reactie gewijzigd door HollowGamer op 23 juni 2019 12:47]

Wat Ubuntu wil doen is simpelweg niet langer 32-bit varianten van de software in hun repositories compileren. Libc6 is een uitzondering - in de amd64-repositories zit het pakket libc6-i386.

Dit betekent dus dat het nog steeds mogelijk is om 32-bit software te draaien, maar dat je voor je eigen dependencies zult moeten zorgen. Dat kan dus bestaan uit ze zelf compileren en meeleveren met je programma, statisch linken, uitvoeren in snap of flatpak, ...

(Het is overigens, na het aanpassen van kernelinstellingen, zelfs nog mogelijk om 16-bits software te draaien. Zo heb ik in het verleden bijvoorbeeld allerlei software uit het Windows 2/3-tijdperk gedraaid op een 64-bits Ubuntu, gewoon om te kijken of het kon.)

Maar wat is dan valve zn probleem? ja ze zullen de 32-bit ook moeten gaan leveren maar wat is het probleem daarin? ik snap te weinig hiervan om echt zinnige opmerkingen te maken dus daarom vraag ik het maar even.

Spellen zijn geen software waar sprake is van langdurige ondersteuning: Ze worden door de auteur geschreven en na enige tijd zijn ze verweesd, er komen geen updates meer. Voor spellen is het dan ook van belang dat het besturingssysteem oude software blijft ondersteunen. Een besturingssysteem dat hierin verzaakt, is geen goed besturingssysteem voor spellen.

Dat is het probleem dat Valve hiermee heeft. Dat ze in nu nog zelf kunnen oplossen met hun Steam Runtime is niet voldoende, ze eisen toewijding van de Linuxdistributie aan deze problematiek.

Waarschijnlijk omdat ze dan alle libraries waar een 32-bit spel tegenaan linkt moeten meeleveren. Al is er een handjevol libraries waarmee je de meeste spellen al hebt.

Valve heeft het probleem wel een beetje zelf veroorzaakt door niet van de gamemakers te eisen dat ze 64-bit ondersteunden. In 2013 (toen Linuxondersteuning werd toegevoegd) was 32-bit allang op zijn retour. Sowieso krijg ik een beetje het idee dat ze aan 32-bit en X vasthouden.

Ik vind dat een reus zoals Valve wat meer moeite zou mogen doen om hun volledige stack te onderhouden. Het is wel makkelijk om te eisen dat iemand anders gratis die verouderde stack voor je blijft ondersteunen, terwijl ze geen eurocent inkomsten zien.

Ik denk dat Canonical de beslissing zal aanpassen, maar Valve vind ik in deze echt zielig.

Ze zouden het onderhoud kunnen sponsoren via enkele FTE of een alternatief pakket samenstellen. Zelfs als dit niet zou voldoen aan de gangbare formaten zou men een deal kunnen voorstellen waar Canonical het in de installatie opneemt.

Nee, liever hun gebruikers een migratiepad opsturen en hopen dat ze ooit een alternatief hebben dat de volumes van Ubuntu haalt.

Het probleem is dat er duizenden spellen op steam zijn die alleen maar op 32 bit draaien.

Is het niet zo dat je 32bit applicaties op 64bit besturingsystemen kan draaien?

Mijn 64bit windows draait ook 32bit steam..

Niet native. Om 32 bits programma's te draaien op een 64 bits OS heb je een emulator nodig. Die zit dus ook in windows gewoon vanaf het begin al ingebakken en tot nu toe ook bij Ubuntu.
Precies die support wordt er nu dus uit gesloopt. Daar gaat het hele artikel over.

Aaah nu zie ik het ja. Ik dacht eigelijk dat ze alleen de 32bit installer (net zoals we die kenden bij Windows) zouden laten verdwijnen. Maar het gaat dus om de emulatie van 32 op 64bit...

Tja dat veranderd mijn mening wel.. Shame on you ubuntu!

Lees mijn post. Valve kan met hun miljoenen net zo goed een FTE bij Canonical sponsoren en zeggen "wij krijgen de lusten, we zullen een deel van de lasten betalen".