Valve blijft Ubuntu ondersteunen en gaat met meer distro's werken

Valve noemt het zeer waarschijnlijk dat het Ubuntu blijft ondersteunen met Steam, nu Canonical het beëindigen van 32bit-ondersteuning voor Ubuntu 19.10 heeft teruggedraaid. Het gamebedrijf gaat met meer beheerders van distributies samenwerken.

Valve spreekt zijn toewijding uit om Linux te blijven ondersteunen als gamingplatform. Het bedrijf noemt Arch Linux, Manjaro, Pop!_OS, Fedora 'en vele anderen' als Linux-distro's die tegenwoordig een goede game-ervaring bieden. Valve vraagt ontwikkelaars van Linux-distributies die samen willen werken contact op te nemen. Het bedrijf meldt echter niet welke distro's het officieel gaat ondersteunen.

Valve legt in een blog uit waarom 32bit-ondersteuning belangrijk is voor Steam en waarom het vorige week aankondigde Ubuntu vanaf versie 19.10 niet meer te ondersteunen. Dat bericht kwam nadat Canonical bekendmaakte dat vanaf die versie 32bit-ondersteuning gestaakt zou worden. Op die bekendmaking kwam veel kritiek, met name uit de Linux-gemeenschap voor gaming. Daarop besloot Canonical zijn besluit terug te draaien en 32bit toch te blijven ondersteunen.

Niet alleen de Steam-client vereist 32bit-ondersteuning maar ook duizenden games op het platform, beschrijft Valve. Het is wel mogelijk om de Steam-client in een 64bit-omgeving te laten draaien, maar zonder extra compatibiliteitslagen zou een groot deel van het gameaanbod op Steam niet meer beschikbaar zijn voor gebruikers, wat Valve onacceptabel noemt.

Steam op Linux heeft onder andere 32bits glibc, ELF-loader, Mesa en Nvidia-drivers nodig. Valve kijkt al een tijd naar het gebruik van containers om niet meer afhankelijk te zijn van 32bit-componenten, maar een overstap zou niet voor de release van Ubuntu 19.10 te realiseren zijn. Op de lange termijn wil Canonical ook op containers overstappen om 32bit-ondersteuning te blijven bieden.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (66)

Zeker de Valve games draaien als een zonnetje, maar ook games als Battlefield 5 zijn tegenwoordig prima te spelen. Enige wat ik wel ervaar, is dat 'bloom/gloom' effecten op Linux negatief(er) draait dan Windows (eet meer resources). Zonder die setting, draaien de meeste games met een hogere fps dan stock windows.

Maar ... die wine implementatie voor games, vereist 32bit libraries. Dat kan soms een enorme speurtocht zijn welke libs/dependies voor welke game nodig zijn. Je hebt dan een tool als Lutris (tip!) die dat ovor jou regelt. En iedere game in een unieke 'wine bottle' plaatst; zo heeft iedere installatie altijd de juiste en vereiste libs/dependies

[Reactie gewijzigd door himlims_ op 28 juni 2019 10:31]

Zeker de Valve games draaien als een zonnetje, maar ook games als Battlefield 5 zijn tegenwoordig prima te spelen.........
........ ... die wine implementatie voor games, vereist 32bit libraries. Dat kan soms een enorme speurtocht zijn welke libs/dependies voor welke game nodig zijn. Je hebt dan een tool als Lutris (tip!) die dat ovor jou regelt. En iedere game in een unieke 'wine bottle' plaatst; zo heeft iedere installatie altijd de juiste en vereiste libs/dependies

Wat raar dat je daar dus kennelijk een apart tooltje (lutris?) voor nodig hebt, zou het niet beter zijn als valve voor linux een heel eigen variant op steam zou bouwen waarbij valve dus zorgt voor de hele afhandeling van het installeren.

ik zou zover wille gaan dat steam automatisch kijkt of er een linux versie beschikbaar is, en zo nee of er dan een wine-config script aanwezig is om het vervolgens in die wine-bottle te installeren. in die zin kun je dan dus games kopen die gegarandeerd op windows zullen werken, maar mogelijk ook op linux via wine, door een kleine veruiming van het refund beleid naar een uurtje ofzo extra kunnen mensen testen of die wine-setup ook echt werkt, of anders dat ze met de crashlog hun geld kunnen terugvragen.

het 'feit' dat je 3,4 of 5 verschillende tools nodig hebt maakt het voor veel mensen on-speelbaar.

Zijn twee verschillende zaken:

wine/lutris is een tool die het mogelijk maakt om via wine (vulcan) windows games te draaien

wat valve doet; is native aanbieden (geen tools oid downloaden), maar gewoon een linux binary die gerunt wordt. precies hetzelfde als steam windows.

wil je "alles" spelen (zowel windows als linux) heb je idd meerdere tools nodig

//edit: proton doet geen battlefield 5

[Reactie gewijzigd door himlims_ op 28 juni 2019 20:22]

Valve bied met Proton iets vergelijkbaars dan Lutris, die games draaien ook gewoon onder wine.
Zie o.a. https://www.protondb.com/ en https://github.com/ValveSoftware/Proton .

Valve is bezig om steeds meer Windows-only games beschikbaar te maken via Steam for Linux, met behulp van Proton, een fork van Wine waar ze de settings precies goed hebben gezet per game. Hier kan je zien hoe de voortgang is: https://www.protondb.com/

Eigenlijk zitten niet echt aan de setting per game. Ze willen gewoon zorgen dat alle functionaliteiten dat de games nodig hebben er in zitten. Wine is eigenlijk "gewoon" een herimplementatie van directX.

Moet jij na een update van BF5 veel weer aanpassen of gaat dat redelijk gestroomlijnd? ik speel vornamelijk GW2 en BF5 en als die 2 kunnen draaien is het voor mij een overstap genoeg om daarnaast nog ergens een windows ssdtje te hebben voor het broodnodige.

Beschik zelf over een 1080TI met 8700k dus power is er genoeg.

Als liefhebber ben ik blij om te zien dat Linux steeds meer voeten aan de grond krijgt in de mainstream wereld. Ondersteuning van ontwikkelaars zoals Valve is een belangrijke stap. Mensen zoals ik hebben geen zin om alsnog een dualboot installatie van Windows naast Linux te draaien.

Programma's zoals Photoshop kunnen nog wel in een VM, maar dat gaat met games toch echt een stuk moeilijker.

De ondersteuning van Valve was er al, het is dat canonical de beslissing om geen 32bit ondersteuning heeft teruggedraait kan deze ondersteuning blijven en doorgroeien.

Maar goed hoe lang zal 32 bit nog geïmplementeerd blijven of backwards compatible aanwezig blijven.

Wederom, dat is de verkeerde voorstelling zoals die rond wordt bezuind. Canonical wilde de legacy ondersteuning via snaps en LXD containers gebaseerd op Ubuntu 18.04 laten verlopen. Dat geeft een vast referentiekader en zorgt er voor dat je systeem niet kwetsbaar wordt voor zaken als Spectre and Meltdown waarvoor geen mitigaties zijn in 32bits software. Sowieso is het veel beter om legacy apps via Snaps en containers te laten verlopen omdat die daar speciaal voor ontwikkeld zijn.

Er wordt een soort beeld geschapen dat Canonical plots de stekker uit de gaming en x86-ondersteuning wou trekken en iedereen in de kou liet staan, terwijl de beslissing gebaseerd is op jarenlange discussie in de community. Als je even de commentaren onder de discussie leest begrijp je dat hier weer dezelfde GNU/Gnome trollen achter zitten die Ubuntu vanaf het begin aan het ondermijnen zijn. Ja laat Ubuntu vallen, stap over op Fedora of Majaro. Alsof dat niet een grote dreun zou zijn voor de Linux community. Het is juist dankzij het bestaan van een megapopulaire distro als Ubuntu dat Valve uberhaupt aangedurfd heeft om Linux te omarmen. Anders waren ze er niet eens aan begonnen, omdat Linux land veel te versnipperd is.

Ik vraag me ook af wat de Valve developers bezielde om zo een rigoreuze stap te nemen. Developers bij grote bedrijven willen nog wel eens uit de Gnome community komen en allerlei rare spelletjes te spelen. Zo hebben ze ooit een een hoop heisa gemaakt omdat hun bedrijf "plannen had" die de Gnome naam zou schenden en toen een hoop geld opgehaald in de Linux community voor juridische kosten. Nadat het bedrijf aangaf dat helemaal niet te willen, gaven ze het geld niet terug, want in de kleine lettertjes hadden ze staan dat ze het ook voor andere doeleinden mochten gebruiken, pure misleiding.

Dit is ook weer zo een vreemde hetze. De bedoeling is steeds Canonical op zoveel mogelijk kosten te zetten en een negatief imago te geven zodat developers van hen afkeren. Daar zitten Stallman met zijn club achter die feitelijk Google lopen helpen, en Gnome developers die weer in dienst zijn van Red Hat, die in Ubuntu een grote concurrent ziet. Niet alleen willen ze Ubuntu klein houden op de markt, maar ook zorgen dat zo weinig mogelijk developers met Ubuntu werken.

Mensen lopen nu te juichen maar feitelijk blijven we nu zitten op een inferieure, onveilige oplossing. Met Snap of LXD containers kan je legacy software prima laten draaien zonder performance hit en veel veiliger en het fijne is nu juist dat altijd blijft draaien zonder problemen die kernel en driver updates steeds weer kunnen veroorzaken. Het is win-win. De gebruiker weet dat legacy software altijd en veilig blijft draaien omdat de omgeving (kernel+drivers) niet veranderd, en de maintainer hoeft niet steeds problemen op te lossen die Kernel en Driver updates met zich meebrengen.

Nu krijgen we een tussenoplossing waarbij Canonical de update kosten probeert te minimaliseren door beperkt x86 ondersteuning te bieden en de user nog steeds met een onveilig systeem zit dat kwetsbaar is voor Spectre and Meltdown.

De FSF/GNU/GNOME/REDHAT trollen hebben weer een overwinning behaald!
Mensen trap er toch niet in. Dit is geen overwining voor Linux. Zo blijft het juist achter. Deze verkeerde manier van legacy ondersteuning is een verspilling van mankracht die veel beter gebruikt kan worden voor nieuwe ontwikkeling. Google en Red Hat zijn er effectief in geslaagd om de Open Source developers niet voor de Open Source gemeenschap maar de corporaties te laten werken.

En daarmee hebben ze ook voorkomen dat er succesvolle populaire gedistribueerde open source alternatieven zijn gekomen en dat Open Source een serieus alternatief voor de smartphone heeft kunnen ontwikkelen. Open Source dat nota bene in het leven kwam om de afhankelijkheid van gecentraliseerde systemen te voorkomen (Hippy bevrijding), is zo tot het fundament gemaakt van gecentraliseerde systemen.

Linux is slaaf gemaakt van corporaties die gebruik maken van gratis developers, IP-vrije software, en open standaarden die bij hun agenda voor globalisering passen. Waarom is Canonical zo gevaarlijk voor ze? Omdat Canonical gedreven wordt door altruisme van zijn oprichter die er een groot deel van zijn vermogen in gestopt heeft (Inmiddels honderden miljoenen). Omdat alle verliezen uit zijn zak moeten worden betaald proberen ze Canonical verliesgevend te houden om hem tot overgave te dwingen. Elke poging om kosten te besparen wordt door hen gedwarsboomd. Dit gaat al jaren zo. Zie mijn vorige posts over dit onderwerp.

[Reactie gewijzigd door Elefant op 28 juni 2019 18:59]

Gelukkig zijn er mensen die beter weten. Fedora heb ik niet meer gebruikt sinds de dagen van Fedora Core 1, toen ze het voor elkaar kregen beta software populair te maken. Daarna heb ik een aantal jaar Slackware gebruikt, totdat Ubuntu/Kubuntu goed genoeg bleek en ik daarop overgestapt ben. Nu gebruik ik het nog steeds en installeer ik het voor vrienden en familie, omdat het gewoon werkt.

Iedereen zit bij Google en IBM/Red Hat, omdat daar het geld zit. En dat zijn ook mensen zoals Dave Patterson, die naast zijn werk in Berkeley altijd consulting heeft gedaan bij de grote bedrijven zoals Sun Microsystems en nu dus Google.

Maar wat Ubuntu voor de Linux desktop voor elkaar heeft gekregen, lukte de andere distributies niet. En het bedrijf is zowaar winstgevend tegenwoordig en dat moeten we koesteren. En de tussenoplossing boeit me niet zoveel. Het is bij mij eenrichtingsverkeer richting ARM, RISC-V en POWER. En daar zullen ze niet snel een oplossing voor hebben.

Ik deel je mening dat er de op allerlei niveaus de agenda's van Linux-bedrijven doorgedrukt worden. Maar om nou alles 100% af te geven op Canonical is te kort door de bocht.

Dan vind ik de groep van GNOME/systemd/PulseAudio/avahi/CoreOS (waarvan de hoofdontwikkelaars op de loonlijst van RedHat staan) 'enger' dan Canonical.

Bij Ubuntu weet je dat je Canonical's alternatieve oplossingen, zoals snap ipv flatpak, Mir ipv WayLand, Unity ipv GNOME gebruikt en dan afhankelijk bent van de agenda van Canonical.

Bij GNOME, systemd, PulseAudio, avahi e.d. is dat veel minder transparant. Je "denkt" dat je een software pakket gebruikt dat door onafhankelijke ontwikkelaars wordt onderhouden, maar dat is allesbehalve zo.

Lees nog een keer. je zegt precies hetzelfde als ik

Dat wist ik, ik had het beter kunnen formuleren:

Het blijven ondersteunen door ontwikkelaars als Valve is belangrijk voor Linux als platform. Zeker als het wil doorgroeien naar de mainstream markt.

[Reactie gewijzigd door jrswgtr op 28 juni 2019 10:33]

Ik zie niet in waarom 32-bit helemaal zal gaan verdwijnen. Je zal distro's hebben die een volledige 32-bit
Linux zolang het kan zullen blijven ondersteunen. Je zal wel zien dat 32-bit ondersteuning op 64-bit systemen een afgeslankte vorm gaan krijgen, zoals de hier voorgestelde containers om veel gebruikte programma's als Steam te kunnen blijven draaien.

Voor photoshop is ook een erg goed alternatief beschikbaar op linux (GIMP) maar in een vm werken zorgt natuurlijk wel voor een performance impact. En voor video editing is er (naar mijn weten) niet echt een goed alternatief voor Linux en is alle performance impact erg belangrijk helaas, net als games.

Davinci resolve voor video op Linux (+ Windows en MacOS)

Mijn ervaring is dat dit inderdaad verreweg de beste video editor is onder linux

Ik ben bekend met GIMP, maar loop toch altijd tegen compatibiliteitsproblemen aan met PSD bestanden. Dingen zien er anders uit en werken met webfonts van bijv. Adobe gaat ook niet lekker. Dus zolang de ontwerpers waarvan ik bestanden aangeleverd krijg in Photoshop werken en Adobe Linux niet ondersteunt blijf ik toch bij mijn VM.

[Reactie gewijzigd door jrswgtr op 28 juni 2019 10:45]

Misschien gebruik ik GIMP fout, maar al jaren vind ik het een van de meest frustrerende stukken software om ook maar /iets/ in te doen.

Ik kan er inmiddels wel mee overweg. Maar ik doe ook niet veel beeldbewerking meer. Vroeger wel gedaan en alles geleerd in Photoshop. En de overstap is erg lastig. Imho is de interface van Photoshop veel logischer.

Voor mij is Gimp voor kleine dingen prima. Maar als ik een keer wat meer moet doen gebruik ik toch een verouderde versie van Photoshop onder Wine.

Toen ik het nog voor werk gebruikte ging ik toch maar voor Apple/Adobe (met tegenzin)

Ik vind dat best wel meevallen hoor. Ik gebruik het al jaren (naast Inkscape). Er zijn inderdaad zeker verbeterpunten te vinden maar het is stabiele software waar je veel mee kunt bereiken. Met Photoshop heb ik nooit gewerkt.

Heel herkenbaar, vreselijk programma.

Overigens kan je Photoshop prima draaien met wine staging. Je moet wel even de DXVK dlls naast de EXE zetten. Zelf run ik het ook met Ubuntu. De performance is ook erg goed, en ik heb zelden een crash. Het enige wat soms moeilijk doet is het Creative Cloud activation gebeuren, maar daar is op meerdere manieren om heen te werken. Mocht je het willen proberen en je komt er niet uit, stuur maar een berichtje.

[Reactie gewijzigd door Natrox op 28 juni 2019 10:52]

voor video bewerking kan ik kdenlive aanbevelen

Ik moet binnenkort ook wat simpele videotjes in elkaar knippen en plakken (paar videootjes, muziekje eronder, klaar). Ik heb vooral iets nodig met een simpele leercurve. Zou je dan eerder kdenlive of openshot aanraden?

[Reactie gewijzigd door kramer65 op 28 juni 2019 11:12]

openshot is wat makkelijker. Als je wat ervaring hebt met gimp/photoshop - layers begrijpt - kan je daar met een uurtje simpele dingen mee maken.

kdenlive is wat uitgebreider en had ik zelf een middag tijd voor nodig en moest ik de documentatie lezen om basis handelingen te begrijpen

openshot is denk wat makkelijker zoals @tratz al zecht, maar vind de export kwaliteit minder dan die van kdenlive

Gebruiken die niet allemaal FFmpeg? Je zou die met parameters kunnen finetunen.

als ik het goed heb wel ja

ik ben met verschillende testen bezig maar je ziet alsnog een aardig verschil met de export en daarna de upload naar youtube (zie hier)

[Reactie gewijzigd door rohimma op 28 juni 2019 15:23]

Thanks, ik ga er eens naar kijken Ben altijd op zoek naar beter dan adobe

GIMP is nou niet echt een fatsoenlijk alternatief te noemen, ik zou dan nog eerder Krita aanraden, dat is qua user interface in ieder geval een beetje vergelijkbaar.

Dualboot is hier ook geen optie meer, mijn desktop draait gewoon een aantal VM's welke 24/7 content serven en crypto munten staken. Ik zit sinds een aantal jaar op windows, virtualbox werkt perfect.

Sinds VT-D is dat toch een beetje een non-issue geworden? Je kunt Windows vanaf linux draaien met hardware matige passthrough voor de videokaart. Omgekeerd gaat ook, vanuit Windows linux draaien. Sterker nog, Windows 10 krijgt een volledige linux kernel: https://www.theverge.com/...s-10-linux-kernel-feature

Ik vind Photoshop alles behalve prettig werken. Waar ik met Windows een 2019 ervaring heb voelt het met Linux alsof ik 15 jaar terug in de tijd ga.

In vm lukt gaming ook vlot hoor. Je werkt dan best met een pass-through gpu setup. In de toekomst zal virgl zo ver staan dat gamen in een vm standaard gewoon vlot draait

Ik vraag me af: Stelt Valve nu wel als eis dat nieuwe games iig 64-bit support hebben? Of zitten we over 20 jaar nog met hetzelfde issue omdat er nog steeds nieuwe 32-bit spellen komen? Ik begrijp prima dat met het huidige aanbod het een probleem is, maar ik zou ook verwachten dat je dan iig probeert in de toekomst het probleem te verminderen.

De vraag is ook of je in de komende 20 jaar volledig van 32 bit af wilt komen. Wat men nog weleens wilt vergeten is dat er een enorme culturele kaalslag gaat ontstaan. Ik denk dan bijvoorbeeld even aan de enorme lijst met games (ja, ook dat valt onder cultureel erfgoed, zelfs als zien we dat nu nog niet zo) die in 32 bit geschreven zijn. Ik merk nu al dat oudere Windows spellen vaak nog 16 bit installers gebruiken, die dus al niet meer werken op je 64 bits OS. Laat staan als je straks alle 32 bits spellen niet meer beschikbaar hebt, lijkt me behoorlijk zonde, dat is een stuk historie wat dan simpelweg verloren gaat. Laat die 32 bit laag voorlopig nog maar even intact..

In de Windows cultuur, waarin het gebruikelijk is binaries te verspreiden, lijkt me dat 32 bit nog lang zal blijven bestaan. (Gaan we nog last krijgen van het jaar 2038 probleem?)

In de Open Source wereld wordt de code opnieuw door de compiler getrokken, en daarom is het op Linux makkelijker 32 bit support te droppen, zonder dingen te slopen, zolang je maar open source software gebruikt.

Games komen vaak uit een cultuur waarin het gebruikelijk is binaries te verspreiden, en als het een tijdje oud is, dan is er een final build en daar moet je het mee doen. En dan zit je vast aan hoe het ooit gebouwd is, en als dat 32 bit is, moet je dat blijven supporten.

Ergens wel grappig, een 64 bit Windows kan geen 16 bit Windows toepassingen meer draaien, maar onder een 64 bit Linux met Wine draaien 16 bit Windows toepassingen prima. En daarmee ondersteund Linux dus meer als Windows, zolang niemand het idee krijgt dat eruit te slopen.

x86-i568 is nu niet het meest moeilijke om te emuleren dat kan tegenwordig al op een beetje ARM core, de vraag is dus eigenlijk wel terrecht, hoe lang zitten we nog met deze legacy meuk opgescheept voordat men eindelijk met een architectuur komt die breekt met het verleden zodat we op veel vlakken enorm kunnen optimaliseren.

laat men dat beetje legacy dan maar emuleren, ik wed dat als je nieuwe arch naar alle maatstaven van nu wordt geoptimaliseerd dat het prima mogelijk moet zijn om voor die laatste dingetjes een emulator te bouwen.

Het compileren van de bibliotheken voor i686 is gewoon de meest eenvoudige methode om compatbiliteit te realiseren. Emulatie klinkt leuk, maar dat betekent dat je de volledige hardware moet gaan emuleren van een PC van destijds, want bijvoorbeeld een oude Mesa-bibliotheek snappen geen moderne hardware.

Door 32-bit mee te leveren kun je oude spellen voorzien van geactualiseerde hardware-interfaces, je kunt nog veiligheidslekken dichten en optimalisaties uitvoeren; dat is allemaal weg als je een oud besturingssysteem in steen beitelt en op geëmuleerde hardware gaat draaien.

Het argument met legacy-meuk opgescheept te zitten is wat mij betreft zwak: Je bent niet verplicht het te installeren. Ik heb even geteld, van de OpenSusE-distributie die ik gebruik is net iets minder dan 10% van de paketten een 32bit-pakken. Die 10% levert je zo'n beetje 100% compatibiliteit op 32-bit Linux. Is 10% minder pakketjes, die mensen niet eens verplicht hoeven te installeren, het nu echt waard om vele decennia aan software definitief koud te maken?

Het was sowieso al een idee van me om te kijken hoe het met QEMU user emulatie zou draaien op ARM. Waarschijnlijk kan dit veel efficiënter gedaan worden dan nu het geval is en dat zou ik graag met wat QEMU ontwikkelaars willen bespreken

Zo heb ik enkele bugs met de emulatie voor POWER gemeld, omdat ik graag mijn kennis van de architectuur wil vergroten, maar op het moment nog niet echte hardware wil aanschaffen. In ieder geval werkt Firefox nu wel in QEMU, terwijl dat bij de vorige release nog niet het geval was.

Maar juist exact om de reden die je beschrijft zou het goed zijn als valve nu 64 bit verplicht voor nieuwe spellen. Zodat als je over tien jaar dit toch gaat doen, je niet die kaalslag hebt.

Zo lang Windows nog gewoon native 32-bits code blijft ondersteunen, en er nog heeel veel 32-bits libraries in omloop zijn waar nooit iemand een 64-bits versie van geschreven heeft (want duur en niet nodig, en kost meer ruimte ook etc) verwacht ik dat we een volledige overstap naar 64-bit wel kunnen vergeten de aankomende 10 jaar.
Het OS mag dan volledig 64-bits zijn, en misschien een aantal programmas, maar bijvoorbeeld je CPU kan nog prima native 32-bit instructies afhandelen (in tegenstelling tot 16-bit, dat met veel moeite gesupport is maar niet in combinatie met 64-bit).

Volledig 64 bit werken is lastig, en destijds heeft Intel een dappere poging gewaagd met haar Itanics, maar omdat dan alles (en dan bedoel ik ook echt ALLES!) opnieuw gecompileerd moest worden werd dat hem niet. Zeker niet bij software waarvan de maker nu een ander verdienmodel heeft, of gewoon niet meer bestaat.

Laten we wel wezen: zolang Windows 32 bit ondersteuning heeft is dit een non-discussie.

En laten we wel wezen: Als over 10 jaar Windows 32-bit ondersteuning dropt, dan krijgen we een gezeik dat dat niet kan omdat op Steam nog vele jaren nieuwe 32-bit applicaties zijn toegevoegd.

Ik vraag me ook af of Valve stopt met ondersteuning voor macOS. Deze stopt in een aankomende release ook met 32-bit support.

Dat hebben ze niet aangegeven. Ook hebben ze de macOS-client recent een 64-bit update gegeven (je moet het programma dan wel opnieuw downloaden). De macOS markt is in potentie een stuk groter dan de Ubuntu-Linux markt (al heeft Apple de afgelopen jaren geen gamer-vriendelijk beleid gevoerd). Wel is het zo dat > 75% van de AAA-titels op de Mac niet meer speelbaar zal zijn met de Catalina-update.

Mooi te zien dat ze meer distributies ondersteunen.
Helemaal mooi te zien dat ze verschillende distributies met verschillende package formaten ondersteunen. Dat lees ik er in ieder geval uit dat ze ubuntu (met debian package management) en fedora (met red-hat package management) ondersteunen. Dat bied voordeel in de breedte: De hiervan afgeleide distributies kunnen/zullen in de toekomst ook gebruikt (en ondersteund?) kunnen worden.

Nu nog ondersteuning voor gentoo en andere source-gebaseerde distributies. Dan kunnen echt lean and mean installaties gemaakt worden.

Toevoeging: Overigens wel appart dat games nog op 32 bits draaien. De game-consoles zijn al jaren de consumenten systemen die de grootste woord-breedte bieden. De meeste spellen van tegenwoordig hebben juist veel woordbreedte nodig. Of wordt de 32 bits omgeving gebruikt voor de oudere spellen (ook uit de 8-bit en 16-bit tijd)?

[Reactie gewijzigd door beerse op 28 juni 2019 11:53]

Hele stukken library zijn 32-bits, want ergens in de afgelopen 15 jaar geschreven, en lekker compatible gehouden met Windows-XP. Dat de hoofdcode in 64-bits is, en hele stukken grafische grappen ook (want meer dan 4 GB geheugen nodig) is niet heel relevant, je moet nog steeds 32 bit kunnen draaien. Security libraries zijn een goeie, je hebt zelden de nieuwste nodig, zo lang er updates voor de oude versies zijn.

In spelcomputers was er enige tijd een rage wie de meeste bits had. Dat ging echter niet om de adresruimte, maar om de breedste SIMD. Volgens die definitie is een PC 512-bit (AVX512) en omdat AVX512 ook in 32-bit software te gebruiken is zou 32-bit software dat aan kunnen wenden.

De PC een 512-bit platform noemen lijkt me evenwel weinig met de realiteit te maken hebben, net zoals de bits-claims van die spelcomputers zeer aanvechtbaar waren.

Deze 32-/64-bit-transitie gaat over de grootte van de adresruimte. Een Nintendo64 had een 32-bit adresruimte.

De adresruimte? Die is toch maar 48 bit op x86-64?

De adres ruimte is iets anders dan de woord-breedte. De ene is voor het geheugen adres, de ander is voor de waarde die daar staat. Die waardes kunnen gegevens of instructies zijn (of natuurlijk andere adressen)

In de CPU heb je diverse registers voor het adres, de instructie en de gegevens. De adres registers bepalen de adres-ruimte, de data en instructie registers bepalen de woord breedte. Toegegeven, zelfs bij een oudje als de Z80 kunnen registers worden gekoppeld tot een grotere woord-breedte. Zelf heb ik altijd begrepen dat de 'woordbreedte' van een cpu wordt bepaald door de gegevens maat die het snelste door de cpu wordt verwerkt. De gekoppelde registers van de Z80 worden in de cpu bij verwerking in 2 slagen verwerkt wat het niet sneller maakt.

Dat bedoel ik maar net, wat bedoelen we precies met xx bit? Adresruimte, woordbreedte, instructielengte?

En al zijn de adresregisters van de x86-64 architectuur 64 bit, als alleen de 48 least significant bits bekeken worden, is de adresruimte 48 bits. (Worden deze op 0 geforceerd of hebben we staks weer "gate A20"-achtige taferelen?)

Dit feit lijkt mijn vraag ook te beantwoorden, dat het de woordbreedte betreft als we het over een aantal bit van een cpu (-architectuur) hebben.

Met woord breedte van xx bit bedoelen we de data breedte.
De anderen zijn de instructie lengte en de address breedte.
Een 8 bits cpu als de Z80 heeft 16 bits adressen (8 bits = 256 adressen, 16 bits = 64 K adressen.)
Een 8- bit cpu kan wel 16 bits instructies hebben maar dat zijn dan vaak speciale gevallen.

Het is inderdaad de breedte van de architectuur. Dat waar de cpu het snelst mee overweg kan. Het optellen van 2 integers gaat in 1 slag. Bij de Z80 is dat 8 bit, het optellen met de 16-bit registers gaat daar in 2 slagen (2 cpu cycles)

Ik kan me eerlijk gezegd niet voorstellen dat er geen oplossing gaat komen waar zowel Steam als Ubuntu tevreden mee zijn. Die twee zijn zo groot en belangrijk voor elkaar dat ik niet geloof dat ze elkaar in de steek laten. Er zijn al verschillende oplossingen aangedragen, en een deel daarvan kan in principe ook door gebruikers zelf worden gedaan. Als er geen mooie officieel ondersteunde oplossing komt dan komt er wel een lelijke onofficiële oplossing zodat mensen kunnen blijven gamen.
Publicitair gezien is het misschien een beetje jammer dat dit zo via de media gaat omdat het de indruk geeft omdat gamen jarenlang een moeilijke reputatie had, maar van de andere kant ben ik blij dat we niet opeens met een vervelende verassing worden geconfronteerd.

/

[Reactie gewijzigd door thisischrys op 28 juni 2019 15:16]

Goed dit te horen. Ik werk al jaren op Linux en het is mooi om te zien dat het wel steeds meer geaccepteerd wordt als alternatief. Steeds meer programma's draaien (met dank aan oa Electron) op de Linux desktop (alhoewel er veel mensen bitchen op Electron brengt het wel programma's naar Linux die er anders niet waren geweest).

Verder krijg je ook steeds meer hardware vendors die Laptops met Linux preinstalled verkopen. Mijn laatste twee laptops heb ik met Linux preinstalled gekocht, en mijn derde (een Dell XPS13) is nu onderweg. Naast het feit dat ik mijn geld niet richting Microsoft wil sturen, vind ik het ook belangrijk dat je hiermee support van de hardware vendors afdwingt. Dell zorgt er nu iig voor dat Linux goed draait op hun laptops. En met mijn centjes motiveer ik ze daar nog wat meer toe. Bovendien zien bedrijven nu ook dat mensen geen Linux willen "omdat het gratis is", maar omdat het gewoon beter is, en ze er dus ook best geld aan uit willen geven.

Gaming is een volgende grote stap voor de Linux desktop. Het zorgt ervoor dat er steeds minder redenen zijn om Windows te "moeten" hebben. De laatste stap zal denk ik Adobe Photoshop/Premiere en dingen als MS office worden. Alhoewel ik gezien het verleden nog enige reservaties heb richting MS wat betreft hun voornemens, vind ik dat ze wel goed bezig zijn. Met Crossover Office is het natuurlijk al mogelijk, maar wellicht zal "MS Office for Linux" op een mooi moment dan tóch het levenslicht zien.

De toekomst ziet er goed uit!

[Reactie gewijzigd door kramer65 op 28 juni 2019 11:24]

Veel mensen gebruiken office 365 via de browser, dus opzich is dat al een vooruitgang, voor de mensen die perse office willen gebruiken.

Steam kwam al standaard met Manjaro mee en werkte uitstekend. In tegenstelling tot Ubuntu zit je met Manjaro wel op modernere kernels en drivers, dus de compatibility en support voor nieuwe features en hardware was veel beter geregeld.

Ze kunnen niet met een generieke oplossing komen, maar gaan well al die distributies actief ondersteunen?

Weinig geloofwaardig hoor.

Valve heeft Canonical de arm omgewrongen zodat ze goed geld kunnen blijven verdienen zonder de support op zich te nemen. Dat blijft mijn conclusie. En we juichen het nog toe ook.

Je kan moeilijk een distro forceren om de requirements van je software te blijfen ondersteunen.
Het is makkelijker testing te doen op distro's die wel gewoon die requirements hebben dan proberen een distro te ondersteunen die niet wil meewerken.

Wat is Manjaro toch een top os ik start het tegenwoordig meer op dan Windows 10.