Ubuntu blijft 32bit toch ondersteunen

Canonical komt terug op de beslissing om te stoppen met ondersteuning voor 32bit-applicaties. Het bedrijf heeft na veel kritiek besloten een 'geselecteerd aantal' 32bit-packages voor Ubuntu te blijven ondersteunen.

De koerswijziging is het gevolg van 'de grote hoeveelheid feedback' van onder andere gamers, Ubuntu Studio, en de WINE-community, meldt Canonical.: "We veranderen van plan en bouwen een geselecteerd aantal 32bit i386-packages voor Ubuntu 19.10 en 20.04 LTS."

De ondersteuning zal echter niet de volledige 32bit-softwarebibliotheek betreffen. Voor het selecteren van de packages schakelt het bedrijf de community in. In samenwerking met communityleden wil Canonical zelf bepalen welke 32bit-packages nodig zijn voor softwareondersteuning. Daarbij blijft de mogelijkheid om packages op een later moment toe te voegen open staan.

Vorige week maakte Canonical bekend de 32bit-ondersteuning vanaf Ubuntu 19.10 te willen staken. Het zou de ontwikkelaars te veel tijd kosten dat in stand te houden, en slechts een klein aantal gebruikers zou ermee worden bediend. De stap leverde veel kritiek op van met name gamers, omdat er nog heel veel 32bit-games voor Linux op Steam staan. Valve besloot daarop Ubuntu 19.10 en latere versies niet meer te ondersteunen.

Canonical zegt verrast te zijn over de felheid van de discussie over het einde van 32bit-ondersteuning. Die voert het bedrijf naar eigen zeggen al sinds 2014. Het bedrijf dacht hier juist consensus voor Ubuntu 20.04 LTS over te hebben bereikt na een uitgebreide thread over het onderwerp met betrekking tot 18.04 LTS. De organisatie blijft er ook bij dat de meeste 32bit x86-packages nauwelijks gebruikt worden. Bij de uiteindelijke end-of-lifeprocedure wil Canonical containers gebruiken om het draaien van oude applicaties mogelijk te blijven maken.

Reacties (104)

[ShadowLord]

"Het bedrijf dacht hier juist consensus voor Ubuntu 20.04 LTS over te hebben bereikt na een uitgebreide thread over het onderwerp met betrekking tot 18.04 LTS."

Als je die thread leest (uit mei 2018) zie je dat daar al mensen waarschuwen voor het droppen van i386 packages voor compatibility (met o.a. Steam). Ook komt naar voren dat er wat onduidelijkheid is waar de thread over gaat: alleen i386 installaties droppen of alle i386 packages.

Dus dat Canonical uit die thread haalt '"We kunnen i386 compleet droppen" dan hebben ze (het begin) niet goed gelezen. De consensus in mei is vooral dat de i386 Ubuntu images en installers weg kunnen, maar niet de individuele packages. Ook wordt er voorgesteld om i386 packages standaard met SSE2 aan te gaan compilen want x86_64 processors ondersteunen dat standaard.

[MeMoRy]

Bedankt voor de samenvatting. Bespaard leeswerk.
Wat je volgens mij vaak ziet is dat beleidmakers communitydiscussies vaak selectief interpreteren. Zo halen ze precies eruit wat ze willen horen. (En voor je het weet, zit je met z'n allen in een open-office te werken )

[Elefant]

Canonical wilde 32bit ondersteuning niet droppen maar bevriezen op 18.04 omdat het voor legacy applicaties is die ook al lang uitontwikkeld zijn. Verdere ontwikkeling zou eerder de compatibiliteit in gevaar brengen. Zie Ubuntu Developer Talks Down Impact Of 32-Bit Changes For Ubuntu 19.10

Er is dan ook niets wezenlijks veranderd alleen dat ze nadrukkelijk bevestigen dat ze het zullen includen. Maar ze gaan het echt niet ondersteunen in de zin van verder ontwikkelen.

Er zitten mensen in de Linux gemeenschap die al jaren alles wat Ubuntu communiceert opzettelijk verkeerd negatief uitleggen en onmiddelijk schandaal beginnen te schreeuwen. En die krijgen dan steun van een domme meute die ze napraat zonder zich te verdiepen. Als je dat wil begrijpen moet je in de geloofssecte van Richard Stallman verdiepen. Want daarin zitten de volksmenners die de zaak lopen opstoken. Zelf laat Stallman zich graag sponsoren door bedrijven als Google die absoluut niet willen dat er een echte open source tegenkracht ontstaat. Het stinkt als een beerput. Zie mijn eerdere posts hier en hier.

Dit zal weer voorgesteld worden als een overwinning op evil Canonical. Ik vind Mark Shuttleworth echt een held dat hij er nog steeds niet de bijl er bij neergooit, na alle stront die hij over zich heen gestort heeft gekregen. Dat doet hij om al die Linux (Debian) developers hun baan te laten houden. Zelf is hij er honderden miljoenen bij ingeschoten. Waar vind je zulke mensen nog? Met een lantaarntje moet je ze zoeken.

[Reactie gewijzigd door Elefant op 22 juli 2024 20:01]

[Maarten21]

Hoe groot is de groep gamers op Ubuntu eigenlijk? Ik dacht (misschien onterecht) dat alle pc gamers op Windows zaten.

[Omega]

Er is een redelijk grote community van mensen die gamen op Linux. Hier is een link naar de Linux User Group op Steam, een van de grotere Linux groepen op Steam;
https://steamcommunity.com/groups/steamlug

Meeste games worden tegenwoordig naar Linux geport waardoor Linux een prima gaming platform is geworden. De Windows games die niet worden geport die draait men via WINE/Proton.

Meeste van deze mensen die draaien Linux om ideologische redenen of omdat ze gewoon klaar zijn met Windows.

Als jij kijkt naar de Steam Survey zie je dat Linux gebruikers 0.84% van de gebruikers op Steam zijn.
https://store.steampowere...e-Survey-Welcome-to-Steam
Deze survey is op vrijwillige basis en word aangeboden aan willekeurige gebruikers. Dus dit exacte percentage met een beetje zout nemen, ook al is het redelijk stabiel van maand tot maand. Steam heeft 90 miljoen maandelijks actieve gebruikers, wat betekend dat er ongeveer 750.000 Linux gebruikers op Steam zitten als we er vanuit gaan dat de survey een beetje klopt.

[Reactie gewijzigd door Omega op 22 juli 2024 20:01]

[Bamsebjorn]

Ik weet niet hoe betrouwbaar de cijfers zijn; gezien de ideologie van Linux kan je ervan uit gaan dat veel Linux gebruikers de survey stelsmatig weigeren waardoor het percentage Linux gebruikers lager uit zal vallen.

Edit: Oké, bedankt voor de correctie.
Ik gebruik Fedora, btw...

[Reactie gewijzigd door Bamsebjorn op 22 juli 2024 20:01]

[Omega]

De meer extreme ideologisch gemotiveerde Linux gebruikers zullen Steam niet installeren, het is een proprietary programma.

Zoals Bamsebjorn zegt, Linux gebruikers zullen juist sneller de survey draaien. Memes zoals "I use Arch btw" bestaan niet zonder reden

Ik ben zelf actief in verschillende Linux community's en de mensen daar zijn allemaal in overeenstemming dat je de survey moet doen als je die krijgt om het Linux marketshare percentage omhoog te krijgen.

_{Edit: allemaal vreemde typefoutjes}

[Reactie gewijzigd door Omega op 22 juli 2024 20:01]

[Anoniem: 420148]

De meer extreme ideologisch gemotiveerde Linux gebruiken zullen Steam niet installeren, het is een proprietary programma.

Die zullen dan ook niet gamen, om dezelfde redenen :-)

[T-men]

Dat werkt ook andersom: veel Linux gebruikers zijn trots op hun systeem en willen dat ook graag laten zien in de cijfers. Meer (zichtbare) gebruikers = ook meer ondersteuning.

[RefriedNoodle]

Zou juist eerder verwachten dat Steam-gebruikers onder Linux juist wel de survey invullen, om te zorgen dat hun platform (wat toch in de minderheid is) hoger te krijgen?

[Wouterie]

Ik gebruik alle beschikbare platforms maar toch het meest Windows. Dat haal je niet uit zo'n survey.

[JeroenED]

Meeste van deze mensen die draaien Linux om ideologische redenen of omdat ze gewoon klaar zijn met Windows.

Geld niet voor mij, ben begonnen met linux omdat bij een errste ervaring bleek dat verschillende apps beter (als in sneller en in minder extra zever) ondertussen draai ik deze programma's niet meer, maar zijn er weliswaar andere redenen om bij linux te blijven. Een daarvan is het gebruiksgemak met ppa's en m'n backupscripts en andere scripts die ik sowieso op linux moet draaien wegens geschreven in bash (wat ook al niet meer van tel is met wsl)

[Terr-E]

Zie bijvoorbeeld [1]

Nu is deze survey niet 100% sluitend (slechts een klein deel van de gebruikers per maand wordt geloot om de survey in te vullen, en daarbij is er ook nog een groep die de Windows versie van Steam in Wine of Virtualbox o.i.d. gebruikt op Linux) maar het geeft een aardig idee.
Laten we gul zijn en zeggen dat 1% van de Steam gebruikers op Linux zit en Ubuntu (en afgeleiden) daarvan het grootste aandeel is. Volgens [2] en [3] zijn er zo'n 90M unieke Steam gebruikers, met tot wel 19M tegelijk ingelogd. Dat zouden bijna een miljoen Linux gebruikers zijn.

[1] https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam?platform=combined
[2] https://store.steampowered.com/stats/
[3] https://www.pcgamer.com/steam-now-has-90-million-monthly-users/

[Blokker_1999]

Het gaat natuurlijk niet alleen om gamers. Er is enorm veel oude software die niet in 64bit vorm bestaat. En door zelfs geen minimale basis te voorzien op 32bit sluit je die allemaal uit.

[Anoniem: 1322]

Dit is het correcte antwoord. Er wordt natuurlijk veel meer software gedraaid op een computer dan alleen maar games. Als Microsoft morgen alle 32bit software zou blokkeren valt er ook genoeg om... 16bit was al een drama voor sommige organisaties..

[Kees]

Het 'probleem' is dat vrijwel alle linux gamers Steam en wine gebruiken. En die hadden grote problemen met het uitzetten van de 32bits libs, zo zeer zelfs dat ze de ondersteuning voor ubuntu zouden stoppen als dit plan doorging. DSat was niet iets waar ze bij Ubuntu echt rekening mee hadden gehouden.

Aangezien linux vrij veel smaken kent, is het eenvoudig om gewoon over te stappen zonder grote problemen naar een andere distro. Vrijwel alles werkt dan zoals je het kent, inclusief Steam en Wine support. Dat zou Ubuntu best veel gebruikers kosten.

[procyon]

Iets wegnemen dat er voorheen al wel was zorgt altijd voor weerstand.
Was trouwens verbaast over het feit dat het kennelijk gamen (Steam) nog op 32 Bit draait? Is dat in windows ook het geval?

[Wormaap]

Steam heeft een gigantische back-catalog van oude(re) games die op 32bit draaien.

[Mathi159]

Ik zie alleen niet helemaal waarom de launcher dan ook 32bit moet zijn?

[Blorgg]

Ik zie alleen niet helemaal waarom de launcher dan ook 32bit moet zijn?

Los van dat 32-bit ondersteuning ooit eens op gaat houden. Wat zijn volgens jou de technische redenen om de Steam client 64-bit te maken? Dus niet de games, alleen Steam.

En als de Steam client dan 64-bit is. Wat doen we dan met de duizenden games die 32-bit zijn en blijven?

Valve levert zelf de benodigde 32-bit packages mee voor de Steam client. Ofwel, de Steam client werkt op een 64-bit OS zoals Canonical dat voor ogen had. Wat Steam op Linux onlangs een enorme sprong heeft doen maken is Valve's Proton waarmee het gros van de Windows games zonder gedoe onder Linux te spelen zijn. Gewoon vanuit je Steam client onder Linux een Windows game installeren en spelen. Echt super fijn. Maar daarvoor heb je dus wel Proton en Wine nodig. En daarvoor heb je nu nog 32-bit packages nodig.

[psychicist]

Linux distributies zitten anders in elkaar dan bijvoorbeeld Windows of Solaris, waarbij nog wel veel software als 32-bit wordt aangeleverd. Normaal gesproken zijn op een 64-bit distributie ook echt alle pakketten 64-bit met de mogelijkheid om 32-bit pakketten te installeren. Dus het zou op den duur wel te verwachten zijn dat de Steam client ook als 64-bit aangeleverd wordt met 32-bit compatibility libraries voor de oudere spellen.

Wat ik met deze aankondiging wel eens zou willen zien, is een betere ondersteuning om software voor een andere architectuur zonder al teveel prestatieverlies te kunnen draaien via QEMU user emulation. Dan zou Steam ook bijvoorbeeld ook op je Raspberry Pi of je Talos II workstation kunnen draaien.

Jaren geleden was er Transitive om op 50% van de prestaties binaries op een ander besturingssysteem op een andere architectuur (bijvoorbeeld Solaris/SPARC of HP-UX/PA-RISC op Linux/x86) te kunnen draaien en dat zou voor mij voldoende zijn. Rosetta van Apple was daar ook op gebaseerd voor de overgang van PowerPC naar Intel. Ik weet niet wat er met dat product is gebeurd, sinds IBM het bedrijf heeft overgenomen.

[Zer0]

Dus het zou op den duur wel te verwachten zijn dat de Steam client ook als 64-bit aangeleverd wordt met 32-bit compatibility libraries voor de oudere spellen.

Nee, want Steam is geen OS, slechts een launcher.

[Qalo]

Nee, want Steam is geen OS, slechts een launcher.

Je mag je opmerking ombuigen naar: Steam is in principe een launcher, maar bestaat ook als aparte OS. Zie hier, gebaseerd op Debian.

[Reactie gewijzigd door Qalo op 22 juli 2024 20:01]

[Zer0]

Dat is SteamOS, en iets anders dan Steam...

[Qalo]

Het is iets anders, maar ook Steam.

[scholtnp]

Transitive zegt me niks. Bedoel je dit misschien?
https://nl.wikipedia.org/wiki/Transmeta

[psychicist]

Transmeta waar Dave Ditzel CEO was en Linus Torvalds indertijd nog gewerkt heeft, ken ik inderdaad. Dave Ditzel heeft nu een nieuw bedrijf, dat Esperanto Technologies heet. Hij doet het zo'n 20 jaar later dus opnieuw.

Maar wat ik eigenlijk bedoelde, is dit product https://en.wikipedia.org/wiki/QuickTransit van Transitive Corporation, dat later door IBM werd overgenomen.

[Reactie gewijzigd door psychicist op 22 juli 2024 20:01]

[dmantione]

Los van dat 32-bit ondersteuning ooit eens op gaat houden.

Ik denk niet dat je zo moet denken: Het 32-bit tijdperk heeft 3 decennia geduurde, er is zoveel software in dat tijdperk geschreven dat het bijzonder lang gaat duren voordat niemand meer software uit dat tijdperk wil draaien. Wellicht dat op een bepaald moment naar virtualisatie of emulatie overgestapt kan worden, maar de wens om oude software te draaien op nieuwe computers zal blijven bestaan.

[Laurens-R]

Er zitten best wat onderdelen in Steam die direct interfacen met de game zelf. Denk aan interactie met achievements, DRM, Proton support etc. Dat soort dingen vereisen gewoon dat er in een aantal gevallen 32 bit libraries en client aanwezig moeten zijn indien de game zelf ook 32 bit is.

[Reactie gewijzigd door Laurens-R op 22 juli 2024 20:01]

[.oisyn]

Dat is niet echt een antwoord op de vraag - voor 64 bits geldt het natuurlijk precies hetzelfde. En als 32 bits niet meer ondersteund wordt, is de 32 bits interface natuurlijk ook niet meer nodig. Móet de launcher 32 bits zijn? Nee. Schieten we er iets mee op door de launcher 64 bits te maken? Een klein beetje, maar heel veel games gaan sowieso niet meer werken als de support voor 32 bits vervalt, dus je kunt je afvragen wat de moeite dan nog is.

[johnbetonschaar]

Ik zie alleen niet helemaal waarom de launcher dan ook 32bit moet zijn?

Omdat de launcher nogal useless is als je een significant deel van de spellen niet kunt opstarten (met name de proton games, welke in het overgrote deel 32-bit executables zijn)? Ik denk niet dat Valve moeilijk doet over het recompilen van hun eigen code naar 64 bit, maar geen zin heeft om een platform te ondersteunen waar driekwart van de games niet op werken.

[Reactie gewijzigd door johnbetonschaar op 22 juli 2024 20:01]

[procyon]

Aah natuurlijk.. check

[sspiff]

Steam zelf is 32-bit op Windows, alsook veel games. Sommige games zijn vandaag de dag wel al 64-bit, maar lang niet allemaal.

[Marctraider]

En steam is geen dependency van games maar merely een (onnodige) launcher.

Dat dat nog 32-bit gecompileerd is is mij een raadsel.

[MicGlou]

Steam is in zoverre een dependency van games dat het de licenties oftewel het eigendom van de games beheerd... daarnaast heb je dan nog zaken zoals achievements enzovoort.

[Horatius]

Wat ik in de vorige post las over steam en Linux support komt het omdat steam meerdere stukken gebruikt die nog 32bit zijn en grote delen van proton nog 32 bit nodig hebben.

[dmantione]

Steam bestaat uit 32-bit en 64-bit componenten, dat moet wel, omdat er spellen van beide typen zijn. De applicatie zelf is inderdaad 32-bit. De reden was 32-bit systemen te kunnen ondersteunen. Die ondersteuning is inmiddels stopgezet; op termijn zal daardoor de Steam-applicatie wel een keer 64-bit worden, maar daar is geen dringende noodzaak voor.

[Amanoo]

Sommige games zijn gewoon 64-bit. Maar heel veel games niet. Vaak zijn dat wat oudere games (soms slechts enkele jaren ouder). Ook veel Windows games zijn 32 bit, en draaien dus in een 32 bit WINE omgeving. Dan wil je dus wel die libraries hebben.

Steam zelf is ook 32 bit meen ik. Dat zouden ze gewoon 64 bit moeten compileren. Desalniettemin zijn er genoeg games die 32 bit zijn, en geen 64 bit versie zullen krijgen.

[Reactie gewijzigd door Amanoo op 22 juli 2024 20:01]

[dantalion]

Ik zie veel mensen verbaasd zijn over dat steam een 32bits applicatie is maar als je er even over nadenkt is het vrij logisch.

Veel oude games zijn nog 32bit denk aan oude age of empires spellen als voorbeeld nu zou een 64bit launcher en een 32bit spel op zichzelf niet zo een probleem zijn. Steam bied echter veel integraties aan zoals de in game overlay en achievements maar ook trading cards en zelfs multiplayer en save game synchronisatie.

Dit soort features vereisen al snel integratie met een spel en de libraries / dll's die daarvoor geladen moeten worden zullen toch echt voor dezelfde hoeveelheid bits gecompileerd moeten zijn als de game zelf.

Hierom is het niet meer dan logisch dat Steam zelf een 32bits applicatie is want een besturingssysteem kan je zo maken dat die zowel 32 als 64bits applicaties kan draaien maar een 32bits applicatie kan niet met 64bits libraries overweg.

[2green]

Canonical gaf in een officiële statement aan dat ze vooraf zelfs overleg met Valve hadden gehad over het laten vallen van 32bits support. Blijkbaar heeft Valve hierin ook een bal laten vallen.
Bron

Aangezien Valve zeker niet al hun eindgebruikers(gamers) en leveranciers (ontwikkelaars) willen vragen om een ander Linux-OS te installeren en gebruiken, zullen ze binnenkort wel aankondigen dat Ubuntu ondersteund blijf en tevens het geadviseerde ontwikkelplatform blijft voor ontwikkelaars.

Heb nog niet zo lang geleden met wat game developers op steam gekletst over Linux optimalisaties, maar je schrikt er echt van hoe weinig game developers een OS kunnen installeren of tenminste dat ooit hebben getracht. Ze waren echt verschrikkelijk bang dat er iets mis zou gaan en dan hebben we het over AA studio's (als dat een term is, geen AAA maar wel forse budgetten)

[Reactie gewijzigd door 2green op 22 juli 2024 20:01]

[Wouterie]

Tja, je weet natuurlijk nooit wat er nou daadwerkelijk besproken is. We hebben zo vaak de discussie met leveranciers over wat wel en niet afgesproken is onder welke voorwaarden. Daarom hamer ik er altijd op om alle afspraken meteen vast te leggen. Scheelt weer dat ik veel minder bij zulke overleggen word uitgenodigd!

Valve heeft uiteraard aangegeven welk belang ze hebben bij de 32bits ondersteuning, maar blijkbaar is er toch ergens ruis op de lijn ontstaan en vond Valve het nodig om er met gestrekt been in te gaan. Ik vind het allemaal wel lollig overigens.

[2green]

Same, zorg ook altijd voor gedeelde notulen en bijvoorkeur duidelijke actiepunten.

Maar ze zouden dit niet naar buiten brengen als het niet besproken is. Het is wel ongelooflijk bizar dat als iemand begint over libraries verwijderen, alle 32bits maar liefst dat ze bij valve niet eraan denken om vervolg vragen te stellen.

Ubuntu is trouwens niet alleen een ondersteund platform voor games, maar ook het geadviseerde OS om op te ontwikkelen.

En veel ontwikkelaars weten tegenwoordig niet veel meer dan hoe ze een game development kit kunnen installeren, zijn vaak niet eens in staat om windows of Ubuntu te installeren. Je schrikt er van als je sommige spreekt. Vooral op steam. Dus Valve is denk ik heeeeeeel blij dat ze niet van os hoeven te wisselen.

[2green]

Je gestrekte been opmerking bleef hangen... Denk dat je een punt hebt dat valve het blijkbaar nodig vond.

Goede kans dat dit hele gebeuren niet alleen gaat om support vanuit Valve en zelfs niet eens het onderhoud ervan. Ik vermoed dat ze willen forceren dat er een oplossing komt om 32-bits code paden te isoleren van het systeem, groot deel van die libraries zijn tenslotte niet gepatched voor de bekende en onbekende security issues. Waarmee valve toekomstig support en ontwikkelaars kan behouden.

Oude 32-bits games zijn een grote reden voor gamers om bij valve te blijven, als linux deze libraries isoleert in een container dan kunnen ze deze klanten behouden.

Tevens verwacht ik dat Valve ook uit wil komen met een Linux based game-stream service, zoals Google Stadia.
- eigen controller = gereed
- Linux OS (SteamOS) = gereed
- binnenshuis streamen naar diverse apparaten = gereed
- buitenshuis streamen = gereed
- Streamen vanaf Valve server = onderweg?

[RoestVrijStaal]

Nou weet ik ook niet met wie je gekletst hebt, maar tegenwoordig is het programmeergedeelte van games door diverse frameworks en game engines aardig geabstraheerd, waardoor veel technische kennis niet nodig is. Tenzij je veel wil optimaliseren.

Tegenwoordig wil het gamersoog ook wat. En iets beleven. Games zijn geen bedrijfssoftware. Je game kan zò goed programeer-technisch in elkaar steken. Als de graphics, audio, gameplay en setting ruk zijn, gaat niemand het spel spelen, laat staan kopen. Daarmee gezegd is het technische gedeelte van game dev maar een fractie van wat de game tot een (financieel) succes kan maken.

Daarnaast: van een slager verwacht je ook niet dat hij brood verkoopt.

[mjz2cool]

Dat soort dingen vereisen geen integratie, savegames synchroniseren is gewoon het uploaden van lokale savefiles, multiplayer wordt door de game geregeld, en de rest werkt allemaal via api's, en die kunnen prima platform onafhankelijk zijn.

Het klopt dat een 32bit applicatie niet met 64bit libraries overweg kan, maar andersom kan ook niet, een 64bit executable kan alleen 64bit libraries gebruiken.
Ze zouden prima Steam kunnen compileren in 64bit, en dan zullen 32bit games nog steeds prima kunnen werken.

64bit heeft voor Steam geen zin, want dan kun je ook 32bit games niet meer op een 32bit pc spelen, en in het geval van Ubuntu zou Steam dan wel werken, maar de 32bit games nog steeds niet. Ze zouden het wel kunnen doen, want ik denk niet dat er nog veel gamers zijn met een 32bit os, maar omdat 64bit voor Steam zelf niet zoveel toevoegt gaan ze daar ook niet zoveel moeite in stoppen. En zoals je al zegt, een 32bit applicatie kan ook in een 64bit os draaien (zolang dat os 32bit libraries bevat).

[.oisyn]

Dat soort dingen vereisen geen integratie, savegames synchroniseren is gewoon het uploaden van lokale savefiles, multiplayer wordt door de game geregeld, en de rest werkt allemaal via api's, en die kunnen prima platform onafhankelijk zijn.

De game communiceert niet direct met de Steam servers, dat gaat via de client (of via een lokale service waar de client ook mee verbonden is). Hoe weet de game anders welke gebruiker jij bent? Dat weet ie omdat jij bent ingelogd via de client. Als game link je gewoon met door Steam meegeleverde libraries die die communicatie verzorgen. Dat heet gewoon integratie.

[Reactie gewijzigd door .oisyn op 22 juli 2024 20:01]

[.oisyn]

Steam bied echter veel integraties aan zoals de in game overlay en achievements maar ook trading cards en zelfs multiplayer en save game synchronisatie.

Die integratie biedt Steam toch ook voor 64-bit games? Volgens diezelfde logica zou de client dan toch gewoon ook 64-bits moeten zjin? Oftewel, die redenatie houdt geen stand

Voor 32-bits games zijn er 32-bits libs nodig, en vice versa voor 64-bits games. Wat de architectuur van de client dan zelf verder is boeit niet zoveel, er zal hoe dan ook een translatieslag gemaakt moeten worden voor games van de andere architectuur. Dus je kunt net zo goed een 64-bits client uitbrengen die met 32-bits games interfacet, zoals de 32-bits client nu ook met de 64-bits games interfacet.

[Reactie gewijzigd door .oisyn op 22 juli 2024 20:01]

[Qlusivenl]

Betekend dat ook dat Valve de ondersteuning behoudt?

[Soldaatje]

Dat was op basis van een twitter bericht van een van de ontwikkelaars, een officieel standpunt vanuit Valve is er nog niet geweest.

[freekvandeven]

Ik neem aan van wel anders zou canonical echt niet 32 bit weer ondersteunen.

[2green]

Valve wil echt niet alle hun eindgebruikers en minstens zo belangrijk ontwikkelaars vragen om van ubuntu over te stappen op een andere os. Dat kost klanten en game leveranciers.

Die blijven nu zeker weten op Ubuntu zoals waarschijnlijk al het plan was voorafgaand aan dat twitter bericht.

[JapyDooge]

Goh wat een verrassing.
De vraag is of ze Valve nog wel terug krijgen als 'fan', die relatie is nu wel even troebel lijkt mij.

En zo niet, waar gaat Valve dan wel voor.
Pop!_OS lijkt interessant, maar is ook in handen van een relatief kleine commerciële partij (System76).
Manjaro lijkt een voor de hand liggende keuze, maar is toch wel even een stukje minder volwassen voor de gemiddelde eindgebruiker.

[sspiff]

Pop!_OS is bovendien gebaseerd op Ubuntu, dus zou door hetzelfde probleem zorgen.

[JapyDooge]

Ja in dat specifieke geval heeft System76 al aangegeven dat zij 32-bits binaries blijven bijleveren. De vraag is natuurlijk hoelang ze dat volhouden, want dat is wel even wat werk.

[Reactie gewijzigd door JapyDooge op 22 juli 2024 20:01]

[2green]

system76 is een kleintje op dit gebied, die gaan op zijn best de 32-bits binaries erin gooien, maar halen de veiligheidslekken en bugs er niet uit. Volgens mij zijn veel van de grote security issues niet eens volledig verholpen in 32-bit code paden. Dat weet valve ook wel.

Daarnaast heeft valve vast geen zin om al hun eindgebruikers(gamers) en leveranciers (ontwikkelaars) te vragen om van OS te wisselen. Beide partijen kunnen vaak niet eens een OS installeren, je schrikt echt van de kennis dat game developers hebben tegenwoordig.

[dmantione]

Debian doet het leeuwedeel van het werk. Die ondersteunen een hele batterij aan architecturen, waaronder veel 32-bits. Dat maakt dat et voor een kleine partij als system76 goed te doen is om 32-bit weer aan te zetten.

[2green]

Het onderhouden van 32-bits libraries wordt juist voornamelijk NIET door debian gedaan.

Die architecturen ondersteunen ze voornamelijk door de daarvoor beschikbaar gestelde code te integreren *kuch* ker *kuch* nel.

[dmantione]

Definieer onderhouden... uiteindelijk moet de ontwikkelaar van de software voor zijn eigen software zorgen. Maar het zorgen dat het pakket netjes gebouwd kan worden voor i386 wordt door Debian gedaan en Ubuntu en system76 kunnen daarvan gebruik maken.

[2green]

Hoe definieer jij onderhouden dan?

En hoe doet Debian op basis van die definitie het leeuwendeel van het werk?

[dmantione]

Wat doet een distributeur precies? In basis is dat het beheren van de metadata die nodig is om een pakket te bouwen. Wat Debian doet is die metadata schrijven en controleren of een pakket op alle architecturen bouwt. Daarnaast gaan veel distributeurs verder en Debian behoort daartoe: Als er in een pakket beveiligingsproblemen ontdekt worden, dan zorgt Debian dat die bug in alle ondersteunde Debian-versies gefixt wordt: De patch wordt gebackport. Debian schrijft in de regel niet de securitypatch, maar zorgt er wel voor dat die netjes in oudere versies geïntegreerd wordt.

Debian porteert geen code, dat doet de programmeur. Uit eigen ervaring kan ik je vertellen dat als je software hebt in Debian, dat de Debian-maintainer je af en toe vraagt eens naar een Debian-bugreport te kijken. Dat kan zo maar een bug zijn dat jouw programma niet op een broodrooster met exotische processor werkt. Je kunt daarmee als programmeur omgaan hoe je wilt, je kunt ervoor kiezen om te zeggen "zoek het maar uit", maar heel vaak is een kleinigheidje nodig om de betreffende gebruiker te helpen en los je het op.

Dit is de reden waarom Debian op zoveel verschillende architecturen kan draaien, zonder dat Debian reusachtige legers mankracht beschikbaar heeft om alles te testen.

Je kunt er vanuit gaan dat i386 ordes meer gebruikt wordt dan exotische broodroosters en dat bugreports de programmeurs gewoon bereiken. Omdat je als programmeur i386 op je eigen PC kunt testen is het ondersteunen van i386 stukken eenvoudiger dan een exotisch broodrooster, de problemen zijn gewoon ordes kleiner.

Een van Debian afgeleide distributie kan gewoon het werk dat al verricht wordt aanwenden: De packages kunnen gewoon vanuit de metadata gebouwd worden voor i386, de mechanismen waardoor bugs opgemerkt en gefixt worden zijn in functie. Veel problemen zijn daardoor niet te verwachten. Mocht een specifiek pakket problemen geven, dan kun je grotendeels reactie handelen: Komt er een bugreport, zet die door naar achteren (Debian of de softwareontwikkelaars), komt er geen oplossing dan kun je dat specifieke pakket niet langer op i386 bouwen.

[2green]

Jij beschrijft in vrij algemene termen nu het onderhouden van een distro, dat is niet hetzelfde als het onderhouden van de libraries.

Nergens uit dit hele verhaal blijkt hoe het leeuwendeel van het werk bij debian zit qua library onderhoud.

Ben zelf trouwens een ex kernel developer, maintainer van diverse stacks en drivers en heb redelijk wat bugreports in debian op mijn naam. Ik ken daarmee de ins en outs van debian niet, maar heb zoveel contact gehad met ze dat ik voldoende weet om ze te stellen dat ze geen libraries onderhouden en vaak zelfs niet eens een kwaliteit controle (vaak door gebrekkige library code trouwens, niet te wijten aan debian).

[2green]

Naar definities vragen belooft meestal niet veel goed... hopelijk blijft dit gesprek constructief.

Simpel gezegd is onderhouden het updaten van de code aan de voortschrijdende inzichten, dat doen de debian ontwikkelaars niet, zij draaien met name builds van code dat andere mensen updaten. Hooguit doen ze ze (upstream) patches voor compatibiliteit.

Maar het punt is, dat debian deze code dus niet vrij maakt van fouten, veiligheidslekken, etc. Daarvoor hebben ze noch de kennis en de mankracht.

Daarnaast is veel 32-bits code helemaal niet vrij gemaakt van de grote issues die in het nieuws zijn geweest, laatst staan de kleinere issues en de issues die niemand ziet omdat er niet op getest wordt. Allemaal bekende discussies in de Linux Kernel list en vergelijkbare discussies onder debian en ubuntu trouwens. 32-bits code paden zijn zo lek als een mandje. Zou het niet eens in een lxc container vertrouwen.

[psychicist]

Om nog maar niet te spreken over het niet meer kunnen compileren van bepaalde software, omdat het teveel geheugen vereist of niet meer nieuwe functionaliteit heeft verkregen.

Ik heb eerder dit jaar OpenBSD op mijn Powermac G4 gezet, omdat dat een van de weinige besturingssystemen is die nog 32-bit processoren ondersteunt.

Ik had vooral problemen met het compileren van zaken zoals MariaDB, Rust en Firefox en heb het toen maar opgegeven. Deze machine lijkt een paar weken geleden de geest te hebben gegeven. Of misschien is de voeding stuk en zal ik die moeten vervangen.

[dmantione]

Ik heb eerder dit jaar OpenBSD op mijn Powermac G4 gezet, omdat dat een van de weinige besturingssystemen is die nog 32-bit processoren ondersteunt.

Ik had vooral problemen met het compileren van zaken zoals MariaDB, Rust en Firefox en heb het toen maar opgegeven. Deze machine lijkt een paar weken geleden de geest te hebben gegeven. Of misschien is de voeding stuk en zal ik die moeten vervangen.

Dat is natuurlijk een hele andere situatie: Moderne software is steeds meer bedoeld om op 64-bit systemen te draaien en het zal steeds lastiger worden die software op 32-bit processoren te draaien. Waar het hier om gaat is het omgekeerde: Een 64-bit distributie die in staat is om 32-bit software te draaien. Wat je daarvoor nodig hebt, is vooral een set bibliotheken en die kun je zo voor i386 compileren. Elke serieuze distributie die afgestapt is van het ondersteunen van 32-bit processoren heeft dat inmiddels en Ubuntu volgt nu.

[psychicist]

Natuurlijk is dat een andere situatie, maar zelfs op mijn Powermac G5 met 64-bit besturingssysteem (Debian, Adélie, Gentoo, FreeBSD) is het vrij lastig geworden om sommige software als 32-bit te compileren. Natuurlijk helpt het niet dat IBM na zoveel jaren heeft besloten om big-endian te deprecaten en little-endian als de nieuwe standaard aan te nemen voor Linux. AIX is nog steeds big-endian en zal dat blijven, totdat het een keer uitgefaseerd wordt.

Gelukkig zijn de dependencies in het geval van wine niet zo groot en ingewikkeld te compileren, maar ik heb wel te doen met degenen die grotere en ingewikkeldere dependencies nodig hebben zoals bijvoorbeeld LLVM.

[2green]

Daar kijk ik eerlijk gezegd van op, wist niet dat compileren ook al (nieuwe) problemen gaf.

[sspiff]

Inderdaad, nu lukt dat allemaal makkelijk te compileren, maar veel van die pakketten zullen wellicht niet meer zo veel getest worden op 32-bit eens Ubuntu er mee stopt. Het lijkt me sterk dat system76 voldoende geld en mensen heeft om al die pakketten te (helpen) ondersteunen.

[latka]

Als ze het eenvoudig willen houden: gewoon Debian (de basis van Ubuntu). Pop!_OS is ook een Debian derivaat (via Ubuntu) blijkbaar. Er zijn eigenlijk maar een paar 'echte' distributies. De rest is vaak makeup op een bestaande distributie en een serie andere defaults.

[Roel911]

Er zijn eigenlijk maar een paar 'echte' distributies. De rest is vaak makeup op een bestaande distributie en een serie andere defaults.

Meteen opgezocht. De oudste distrubuties zijn: Debian, Slackware (gebaseerd op SLS, maar wordt niet meer voortgezet), Red Hat en een aantal distributies die niet meer voortgezet worden. Bron: https://upload.wikimedia....Distribution_Timeline.svg.

Pop OS bestaat sinds 2017, Manjaro (in een reactie van iemand anders genoemd) sinds 2011.

[N8w8]

Vergeet Suse niet, een aparte "familietak" die ook al erg oud is, en nog steeds springlevend.
Zelf weinig ervaring mee, maar ze waren (ooit?) redelijk groot in corporate en KDE desktops.

Founded in 1992, it was the first company to market Linux for the enterprise.

@kozue, Suse en RH hebben idd RPM gemeen, maar dat is alleen het (Linux Standard Base) pakket distributie format. Het OS wordt vooral bepaald door wat er in de pakketten zit en hoe ze die ontwikkelen, en daar zit niet zoveel gemeenschappelijks in (behalve uiteraard al die upstream code die alle distro's delen).
En ja eea was in t verre verleden wel afgeleid van andere distro's, maar dat is niet vergelijkbaar met bijv Ubuntu/Mint/Redhat, die voor elke release de nieuwste Debian/Ubuntu/Fedora kopieren en afwerken.

[Reactie gewijzigd door N8w8 op 22 juli 2024 20:01]

[kozue]

Volgens z'n grafiekje is Suse een Slackware afgeleide en dus geen aparte familie. En ook niet een die veel als basis voor andere distro's gebruikt is. Dacht zelf altijd dat Suse een Red Hat afgeleide was. Ze hadden ook allebei rpm als pakketbeheer en vielen daarmee al snel in de Red Hat hoek.

[dmantione]

SuSE is inderdaad oorspronkelijk van Slackware afgesplitst, maar ik zou het sinds ze overgestapt zijn op RPM (vroeg in de ontstaansgeschiedenis) geen Slackware-afgeleide meer noemen, dat suggereert dat er nog overeenkomsten zijn en die zijn er gewoon niet. Er zijn goede argumenten om het een onafhankelijke famillie te noemen, je zou het ook in de famillie van RPM-distributies kunnen plaatsen.

[bigbadbull]

suse is als ik mijn iet vergis nog de default voor SAP on linux, dus daar heb je wel een ferme corporate user base inderdaad.

[Miasma]

Misschien een optie voor hen om te zeggen dat ze ontwikkeling en onderhoud ervan staken over een jaar of 5. Dan hebben de community en de developers lang genoeg tijd om zich hierop voor te bereiden. Microsoft geeft ook altijd extreem lang van tevoren aan wanneer ze ondersteuning voor bepaald OS staken.

[r0n625]

Dat doen ze dus ook, want versie 18.04 wordt de eerste jaren nog ondersteund.

[Cyphax]

Het gaat niet zozeer om een OS in dit geval, maar ondersteuning voor een architectuur. De dag dat Microsoft aankondigt 32bit ondersteuning te staken wordt een leuke.
Zelfs als Valve z'n client volledig 64bit maakt, dan moet er nog een oplossing komen voor alle 32bit software die er is; dit is een stuk backwards compatibility die je bijna niet kan laten vallen. Alle ontwikkelaars van games zouden dan retroactief 64bit versies moeten maken. Dat levert hen echter niets op.
Zelfs als alle nieuwe titels nu 64bit zouden worden (wat me een goed idee lijkt in eerste instantie), dan zit je nog met je bestaande library.

[Zeror]

De community, waar je het tenslotte voor doet, heeft hun wens uitgesproken. Goed dat Canonical hier naar luistert.

[computerjunky]

Niet dat ze een keuze hebben.
Het is of ondersteuning voor 32 bit of je os is per direct obsoleet en mensen stappen over op 1 van de honderd andere builds.
Het is dom en zegt veel over hun inzicht dat ze hebben overwogen de support te stoppen.
Met een beetje inzicht in je product en de software die er op draait hadden ze dit nooit overwogen.

Maar dat zie je bij veel bedrijven ze hebben een visie en daar moet je het mee doen en wat de consument je weet wel degene die je bestaansrecht geeft ervan vind is vaak niet relevant.
Nou heb je bij linux zal alternatieven en zijn ze allemaal eenzelfde compromis. Microsoft heeft het geluk dat er geen concurrentie is en die hebben honderden miljoenen mensen gewoon de vinger gegeven met hun tablet UI op de pc en niemand die er wat aan kan doen.

[Chinco]

Of uit hun telemetry blijkt iets anders dan de community zegt. Sluit ik zeker niet uit.

Toch is het een goede ontwikkeling dat ze terugkeren op hun schreden. Ik had al een afname van hun marktaandeel voorspeld. Ik hoop voor ze dat ze op tijd zijn. Vertrouwen komt ook hier te voet en gaat te paard.

[_Thanatos_]

Niet dat ze een keuze hebben.
Het is of ondersteuning voor 32 bit of je os is per direct obsoleet en mensen stappen over op 1 van de honderd andere builds.

Waarom zou dat een probleem voor ze zijn? Ubuntu is gratis. Dan zal het ze toch jeuken of je Ubuntu of Fedora gebruikt?

[computerjunky]

Uiteindelijk zijn ze een bedrijf en die willen toch echt geld verdienen.
En als niemand je product gebruikt word dat heel heel erg lastig.

[_Thanatos_]

Nou volgens mij verdienen ze geen cent meer als ik zometeen Ubuntu download en installeer.

[Omega]

Ik heb geen vertrouwen in Canonical meer. Het is duidelijk dat hun prioriteiten liggen in de server en cloud markt waar meer geld in te verdienen valt. Ze hebben grote hoeveelheiden mensen ontslagen die aan de desktop editie van Ubuntu werkten een aantal jaar geleden toen ze van Unity over gingen op GNOME. Ze willen ook continue tegen de stroom in, ze willen een eigen display server (Mir) om te concurreren met Wayland een eigen initsystem (Upstart) om te concurreren met Systemd. Al deze experimenten/projecten zijn gefaald en canceled. Wat een verspillen van manuren.

Ze zijn ook enorm disconnected van de community zoals de keuze van het laten vallen van 32bit libs aantoont.

[Blokker_1999]

Canonical heeft nog geen dag winst gemaakt. Dat er dus af en toe geherstructureerd wordt om minder verlies te maken en daarbij meer focus te leggen op die delen die inkomsten genereren mag dan ook niet verbazen.

Upstart was trouwens een alternatief voor het verouderde sys-V-init en nadat systemD vele van de verbeteringen van upstart ook bleek te bevatten zijn ze daar ook op overgestapt. MIR was imho wel een grote fout, maar vooral door de manier dat ze met de communicatie rondom dat project zijn omgesprongen.

en als je nooit nieuwe dingen probeerd dan blijft iedereen hangen in het verleden.

[2green]

Ze hadden afgelopen jaar 110 miljoen dollar winst.

https://www.zdnet.com/article/inside-ubuntus-financials/

[Reactie gewijzigd door 2green op 22 juli 2024 20:01]

[Tiimmeh]

Mooi nieuws! Betekent dit ook daadwerkelijk dat Valve ook zijn keus hierover ongedaan maakt? Lees alleen dat dit een reden was om de keus terug te draaien.

[2green]

Ubuntu is niet alleen een ondersteund platform voor games, maar ook het geadviseerde OS om op te ontwikkelen.

En veel ontwikkelaars weten tegenwoordig niet veel meer dan hoe ze een game development kit kunnen installeren en gebruiken, zijn vaak niet eens in staat om windows of Ubuntu te installeren. Je schrikt er van als je sommige spreekt. Vooral op steam. Dus Valve is denk ik heeeeeeel blij dat ze niet van os hoeven te wisselen.

Officieel nog niets bekend, maar hierover twijfel ik niet. Valve gaat echt niet aan zowel gamers en ontwikkelaars vragen om over te stappen.

[Reactie gewijzigd door 2green op 22 juli 2024 20:01]