Tweakers Podcast #382 - IKEA-spullen, burgerinitiatieven en custom roms

Deze week praten Wout Funnekotter, Arnoud Wokke, Tijs Hofmans en Yannick Spinner over het EU-burgerinitiatief Stop Killing Games, het publiceren van een gevibecode app in de Play Store, het samenvoegen van Android en ChromeOS, IKEA's overstap op Matter en custom roms.

0:00 Intro
0:19 Opening
1:49 .post
19:32 1,4 miljoen mensen steunen Stop Killing Games
29:20 Je app vibecoden en in de Play Store zetten
45:07 Google voegt Android en ChromeOS samen, waarom?
57:45 IKEA gaat over op Matter en dat doet ertoe
1:02:36 Custom roms, Google en gebruikers: een moeilijke driehoeksverhouding
1:16:17 Sneakpeek

Link:
Tweakers Kwartaalonderzoek

Door Arnoud Wokke

Redacteur Tweakers

17-07-2025 • 06:00

45

Reacties (45)

45
45
21
3
0
23
Wijzig sortering
Dat het Stop Killing Games-initiatief al zoveel handtekeningen heeft verzameld vind ik echt een goede zaak. Een goed geïmplementeerde wet zal volgens mij consumenten wereldwijd kunnen helpen hun games te spelen zo lang als zij dat willen, in plaats van zo lang het opportuun is voor de publisher om het te ondersteunen.

Ik kan me echter (daarom?) totaal niet vinden in de karakterisatie van @WoutF dat het nodig zou zijn om 'een hele tweede multiplayergame' op te moeten tuigen om het mogelijk te maken na het stoppen van de ondersteuning zelf een server te kunnen hosten. Linksom of rechtsom zal er uiteindelijk een server binary gemaakt moeten worden. Tegenwoordig is er waarschijnlijk een diepe integratie met een clouddienst (bijv. AWS) om het 'serverpark' makkelijk te schalen, en je hebt tegenwoordig meestal gewoon matchmaking in plaats van een in-game server browser, maar alles wat je functioneel nodig hebt om een server te draaien wordt gewoon al gemaakt.

Het is wat kort door de bocht, maar als je zo'n server in AWS kunt draaien dan kun je het ook in Docker draaien. Alle redenen die zijn te bedenken waarom dat niet zo is, zijn zuiver "architectonische" overwegingen waar je van tevoren rekening mee kunt houden en waar ik geen redelijk argument zie dat het noodzakelijkerwijs tot bijzonder veel extra werk (en dus kosten) zou moeten leiden.

Het is de publishers er alles aan gelegen om te doen alsof het extreem ingewikkeld en duur gaat zijn om deze wet uit te voeren, alsof het zal leiden tot torenhoge kosten. Immers, als iemand zich nog vermaakt met een game die eerder is gekocht, dan koopt diegene misschien minder snel een nieuwe game. Ik vind het ontzettend jammer dat er al zo wordt voorgesorteerd op deze argumenten. Mijns inziens houden ze nauwelijks steek, en voor zover ze dat doen leiden ze echt in geen enkel redelijk geval tot het ontwikkelen van een hele tweede multiplayer.

edit: per ongeluk 'code' gebruikt in de visuele editor
edit2: tag ging niet helemaal lekker

[Reactie gewijzigd door Patriot op 17 juli 2025 12:35]

Het is wat kort door de bocht, maar als je zo'n server in AWS kunt draaien dan kun je het ook in Docker draaien. Alle redenen die zijn te bedenken waarom dat niet zo is, zijn zuiver "architectonische" overwegingen waar je van tevoren rekening mee kunt houden en waar ik geen redelijk argument zie dat het noodzakelijkerwijs tot bijzonder veel extra werk (en dus kosten) zou moeten leiden.
De gemiddelde devopser zal bij het lezen hiervan vooral pijn in het hart hebben omdat hun hele beroepsgroep wordt platgeslagen ;)

Zoek bijvoorbeeld eens naar het verschil tussen Docker en een orchestrator. De kans dat het met 1 commando of executable draait is tegenwoordig redelijk laag.
De gemiddelde devopser zal bij het lezen hiervan vooral pijn in het hart hebben omdat hun hele beroepsgroep wordt platgeslagen
Daarom zei ik al, dit is kort door de bocht. Ik heb het zelf overleefd, mijn mede devops gaan het ook overleven.
Zoek bijvoorbeeld eens naar het verschil tussen Docker en een orchestrator. De kans dat het met 1 commando of executable draait is tegenwoordig redelijk laag.
Ik kan hier inhoudelijk niet op ingaan, daarvoor hebben we beiden teveel complexiteit platgeslagen, maar ik denk dat ik wel kan bespeuren dat er een tweetal (mijns inzien onjuiste) aannames aan ten grondslag ligt:

Ten eerste dat de uiteindelijke oplossing moet betekenen dat iemand de gehele infrastructuur achter een bepaalde game over moet nemen. Zoals ik eerder ook al heb aangegeven zijn er zaken die onderdeel uitmaken van die infrastructuur die niet vereist zijn om de kern van de game in leven te houden. Ik zou het zelf nog iets scherper willen maken, en zeggen dat het grootste deel van de complexiteit alleen maar inherent is aan de verwachte schaalbaarheid van het gehele systeem en niets te maken heeft met het fundamentele onderdeel dat één instantie van de game beheerst.

Ten tweede is dit initiatief niet retroactief ingestoken. Het is niet zo dat de hele infrastructuur van een bestaande game waarbij geen rekening is gehouden met deze eis om zaken achteraf los beschikbaar te maken. Het gaat om nieuwe games waar er bij het ontwerp al rekening mee gehouden kan worden.

Het gaat dus om een subset van de infrastructuur, en het gaat om dat deel van de infrastructuur wat het minst spannend is (dat zeg ik als devops, maar niet als gamedev). En dan los van dat alles geldt ook gewoon dat 'als het niet perfect is dan is het enige alternatief niks doen' eigenlijk een valse dichotomie is.
Het gaat dus om een subset van de infrastructuur, en het gaat om dat deel van de infrastructuur wat het minst spannend is (dat zeg ik als devops, maar niet als gamedev). En dan los van dat alles geldt ook gewoon dat 'als het niet perfect is dan is het enige alternatief niks doen' eigenlijk een valse dichotomie is.
Ik denk niet dat "gamedev" en (technisch) "perfect" in dezelfde zin passen ;)
Daarom zeg ik ook dat het niet perfect hoeft ;) Nou ja, onder andere daarom :+
Het is zeker een goeie zaak dat de petitie zo vaak getekend is, alleen is het doel behaald en nu aan de EU om er wat mee te doen, zetten die het niet door zijn we terug bij af.
Veel mensen lijken ook te denken dat dit allemaal moet voor de huidige games, maar dit zal natuurlijk alleen gaan gelden voor games met een release vanaf een bepaald moment na de wet. En als jij vanaf dag -1 weet dat je server infrastructuur zo opgebouwd moet zijn dat het na de dood moet kunnen werken, dan kan ik me inderdaad niet voorstellen dat het ZO veel extra gaat kosten...
Voor de mensen die het leuk vinden om de statistieken van LineageOS in te zien: Bron

TL;DR: (De nummers zijn actieve installs)
4.237.331 wereldwijd
Grootste land: Brazilie met 2.036.293
Nederland heeft: 7220
Luistert lekker weg!

Ik ben het niet eens met de mening van Wout over SKG. Ik denk dat hij zich meer moet verdiepen in de materie alvorens die claims te maken. Always online games kunnen bv de server software delen, zodat de servers redraaid kunnen worden door spelers. Als devs dat weten vanaf dag 1, is het bijna geen extra werk.

[Reactie gewijzigd door Dekar op 17 juli 2025 09:37]

Always online games kunnen bv de server software delen, zodat de servers redraaid kunnen worden door spelers.
Het is tegenwoordig helaas niet meer een .exe die je ergens dropt en draait (uitzonderingen daargelaten). Veel online games hebben een relatief ingewikkelde back-end, verspreid over meerdere cloud diensten. Dus ja, het initiatief is lovenswaardig en ik steun het van harte maar ik denk dat je hier wat kort door de bocht gaat door te stellen dat het delen van de "server software" (wat is dat dan eigenlijk) gedraaid kunnen worden door spelers. O+

[Reactie gewijzigd door Muncher op 17 juli 2025 09:30]

Dat klopt. Maar de games zijn ook ontwikkeld zonder enige vorm van behoud in het achterhoofd. Als een dev team vanaf dag 1 rekening moet houden met een end-of-life plan kan dat makkelijk. Alle clouddiensten die niet nodig zijn, zoals matchmaking, anti-cheat, support, voice chat. Ik ken game devs persoonlijk en die zeggen unaniem dat het geen probleem is om dat te regelen.

Je kan zelfs kunnen beargumenteren dat een offline versie met bots ook 'reasonable playable' is. Dan heb je helemaal geen server nodig.

En het is gewoon wettelijk verplicht, mits je een game als een product beschouwd. En als je bv in een winkel een disk koopt, dan is dat ook zo. En over Steam of digital copies is die wetgeving ook helemaal niet duidelijk. Meestal zal een rechter dan de kant kiezen van de meest benadeelde partij van het contract, en dat is wederom de consument.
Je kunt je afvragen hoeveel van die diensten echt noodzakelijk zijn om de kernervaring van de (multiplayer-)game te ondersteunen. Een deel zal verantwoordelijk zijn voor bijvoorbeeld matchmaking en analytics, en ik vraag me af in hoeverre dat op de eerste plaats noodzakelijk is om de game te kunnen spelen en ten tweede in hoeverre het dan noodzakelijk is om een game precies op die manier te ontwikkelen dat de game volledig onspeelbaar is als dit niet beschikbaar is.

Het is niet zo dat je niet een enigszins gedegradeerde speelervaring zou kunnen hebben. Ik kan me bijvoorbeeld voorstellen dat je geen server directory hebt. Er zal immers vanuit de publisher geen server draaien waar servers zich kunnen aanmelden dat ze beschikbaar zijn. Om vergelijkbare redenen is matchmaking niet mogelijk.

Als je kijkt naar initiatieven om oude games heden ten dage speelbaar te houden en zelfs te verbeteren, dan zijn er legio voorbeelden die vele malen vernuftiger en ingewikkelder dan deze ooit door de oorspronkelijke ontwikkelaars zijn gemaakt. Dat zeg ik niet om de ontwikkelaars te kakken te zetten, maar om aan te tonen dat we als gemeenschap (in brede zin) in staat zijn om dit soort dingen te draaien, ondersteunen en waar nodig zelfs verder te ontwikkelen.
Je hebt helemaal gelijk. Mijn enige punt was dat er soms wel heel makkelijk word geroepen "GEEF ALLES VRIJ EN WE DRAAIEN HET ZELF" terwijl het in de praktijk echt wel iets lastiger is. Maar inderdaad, een gedegradeerde speelervaring is nog altijd beter dan helemaal geen speelervaring!
Dat is natuurlijk ook wel deels een ontwerpkeuze. Een essentieel deel van de ontwikkelaar om zelf servers te hosten, is natuurlijk 'ook' DRM en veiligheid. (al dan niet in die volgorde.) Een spelontwikkelaar kan prima het spel zo maken, dat je via de officiële servers matchmaking/leaderboard/blablablabla van hen hebt, en via 'alternatieve servers', dat die zaken dan via die servers lopen. (of desnoods minder functionaliteit hebben.) Dus dat je bijvoorbeeld een leaderboard hebt op server XYZ. (ik noem maar wat.) Zo zouden zelfs bedrijven/universiteiten/enz. (waar wenselijk) interne leaderboards en zo kunnen maken. Want laten we eerlijk zijn. Of de game-client nou de data van server 1, of server 2 ontvangt, maakt niet uit.

Dan zetten ze gewoon een grote disclaimer dat bij die 'alternatieve servers', dat zij geen verantwoordelijkheid (kunnen) nemen voor fairplay en het gedrag van andere spelers, enzovoorts.

Daarnaast heb je ook nog spellen met een 'single-player' component, en dan is het extra zuur, als je dat ook niet meer kan spelen als de ontwikkelaar de stekker er uit heeft getrokken.

Als de grotere spelontwikkelaars dit zouden faciliteren, heb je zelfs kans dat er dan bedrijven/organisaties komen die dit actief als dienst gaan aanbieden (externe servers). Dus dat je met een groep vrienden verschillende games kunt spelen bij zo'n dienst, en dan dat je dan cross-game leaderboards krijgt of zo.
Je bent eigenlijk de normale gang van zaken in de hele gamewereld van vroeger aan het omschrijven. Het nadeel voor de publisher is dat je dan vaak minder in de hand hebt. Het is bijvoorbeeld lastig om een systeem van skins en andere microtransacties te ondersteunen, omdat het vaak heel makkelijk is om zulke zaken te unlocken zonder te betalen.

Dat gezegd hebbende, dat kan eigenlijk geen factor zijn nadat de ondersteuning van de game stopt want dan kun je noodzakelijkerwijs óók geen microtransacties meer verkopen.
Precies dat. Het is een bewuste keuze om geen externe servers te ondersteunen. Niet ten faveure van de klant, maar voor henzelf. En dat is jammer.
Dat gezegd hebbende, dat kan eigenlijk geen factor zijn nadat de ondersteuning van de game stopt want dan kun je noodzakelijkerwijs óók geen microtransacties meer verkopen.
Het enige is dan, dat ze een grote laatste patch moeten uitbrengen, of ineens serversoftware gaan uitbrengen (dan wel API's publiceren), en dat kost dan geld voor een spel dat ze eigenlijk willen uitfaseren. Hierin zie je dus, dat het spel is ontworpen om het verdienmodel heen, en niet andersom.
Het enige is dan, dat ze een grote laatste patch moeten uitbrengen, of ineens serversoftware gaan uitbrengen (dan wel API's publiceren), en dat kost dan geld voor een spel dat ze eigenlijk willen uitfaseren. Hierin zie je dus, dat het spel is ontworpen om het verdienmodel heen, en niet andersom.
Het uitbrengen van de serversoftware (in ieder geval na de 'zonsondergang' van het product) was juist de uitgangspositie.
En daar heb je dan mogelijk helemaal niets aan voor bestaande diensten. Als die software specifiek is ontworpen om onder bepaalde omstandigheden bij een obscure cloudprovider te draaien, is dat weinig zinvol. Dan moeten ze echt een stuk software gaan uitbrengen (en onderhouden), om het te kunnen faciliteren, of ze moeten een generiek iets gebouwd hebben, dat onder een standaard Linux/Windows/UNIX-platform draait. (en daarnaast ook nog die laatste patch maken om een target-server aan te wijzen).

Maar het zou wel iets voor nieuwe games kunnen zijn. Dan kunnen ze daar bij het ontwerp rekening mee houden.
Leuk voorbeeld hiervoor is BattleField 2.

Deze wordt al lang niet meer ondersteund, maar je kan gewoon online vanuit het spel met elkaar spelen en er is een los 'server' programma waar iedereen mee kan verbinden. Dus na al die jaren kunnen we nog steeds spelen.
Een goed punt van Yannick dat je 10x over een tekst heen kunt lezen en die 'joekel' van een spelfout gewoon niet ziet.
Het gekke wat ik daarbij heb is dat ik die spelfout vaak wél zie, maar precies ná (!) de het verzenden van mijn reaktie, of mijn app. (Ik heb dus bij vrijwel al mij reakties een notificatie staan dat ik achteraf weer wat ge'edit heb.)
Ik snap alleen niet hoe dat kan ? Waarom zie ik dat niet al vantevoren ?

[Reactie gewijzigd door T-men op 17 juli 2025 09:46]

Zo heb ik op mijn scriptie een spelfout gemaakt die ik over het hoofd zag. Na inlegeren wees een maat van mij er op dat er in mijn koptekst notabene een spelfout zat. Dit staat op (bijna) ELKE PAGINA! Gelukkig een technishe studie dus nooit iets van gehoord.
Vandaar dat ik ook zo blij ben met de 'recall' optie in gmail, waarbij je het verzenden ongedaan kan maken.
Uiteraard weet ik dat dit gewoon een timertje op de achtergrond is, maar ik druk best vaak op 'Ongedaan maken'. Toch gek inderdaad dat je pas de fout ziet op het moment van versturen
[Reactie gewijzigd door T-men op 17 juli 2025 09:46] :henk

Dat komt vaker voor, ik heb er ook last van. Dat komt omdat je 2 fases hebt in het typen van een bericht:

- tijdens het typen ben je bezig om wat je wilt zeggen in tekst om te zetten, maar je primaire taak is letters intypen en zinnen neerzetten. In deze f4se cntroleer je ng niet 3cht of de grummatica klopt, je kijkt vooral of de hele zin omgezet is in tekst.

Zeker als je geen multitasker bent, zal je focus voornamelijk op slechts één aspect van het typen van tekst liggen, waarbij op dat moment foutloos typen (nog) niet het belangrijkste is.

- Zodra je op verzenden klikt, verschuift je aandacht naar wat je aan het versturen bent, mogelijk schiet je dan net als ik dan naar een meer analytische modus waar je kritischer bent op de grammatica, mede gevoed door de gedachte dat wat je verstuurt nu niet meer gecorrigeerd kan worden.

Om dit te veranderen moet je je cognitief gedrag aanpassen, wat niet veel meer betekent dat je gewoon moet aanleren een extra controle in te voeren voordat je op de verzendknop drukt.
Na de opmerking over logaritmen, algoritmen (5m35s), dacht ik... Alles heeft een ritme!

Frizzle Sizzle - Songfestival 1986
Jaa, ik ook! Ik had verwacht dan @ArnoudWokke die wel in zou koppe

Maar helaas... :+
Auteurarnoudwokke Redacteur Tweakers @P_Tingen17 juli 2025 11:58
Hahaha, mijn hoofd dacht dat ook, maar ik dacht vlak daarna: maar deze opmerking gaan héél weinig mensen snappen, en toen slikte ik hem in hahaha
De vorm die het meest in de buurt komt van een Squircle is een Superellips. Verschil is dat de Superellips meestal ongelijke zijdes heeft en een Squircle gelijke zijdes. Dus elke Squircle is een Superellips maar niet elke Superellips is een Squircle 😉
Deze discussie draaft natuurlijk al snel door, omdat het zo triviaal is, maar volgens mij is de eigenschap van de 'squircle' niet zozeer dat het een op zichzelf staande vorm is, maar dat het gaat om een cirkel die 'geprojecteerd' wordt op een vierkant (hetzij met afgeronde hoeken).

Het is natuurlijk ook gewoon een taalkundig 'grapje', geen definitie van een geometrische vorm.
Oef, het is even geleden, maar ik heb in m'n hoofd zitten dat superellipsen veel meer soorten vormen kunnen hebben dat iets dat op een 'squircle' lijkt. Een superelips is toch gebaseerd op een bepaalde puntenverzameling?

(( één van de dingen van wiskunde waar je na je academische carrière, de rest van je leven niks mee doet :D. ))
edit:
Dit dus :) De Lamécurve

[Reactie gewijzigd door lenwar op 17 juli 2025 11:47]

Ha custom rom gebruiker hier ;) inderdaad uit privacy overwegingen.
Heb ik mn bedenkingen bij custom roms, omdat deze toch schikbarend vaak door mensen die ... een te grote ego voor hun doen en dan interesssante ideeen hebben over wat de community hun moet teruggeven.

Niet dat ik niet een chinaphone met custom rom heb hoor, ik heb niet het geld voor een goede nieuwe phone :+
Het is de /e/os rom wat een redelijk gezonde club lijkt.
37:19 Mooie uitleg van @WoutF over hoe je AI kunt aansturen om op een gestructureerde manier je software te laten maken.

Het woord PRD was nieuw voor me:
Wikipedia: Product requirements document

Het ontwikkelproces hoe het beschreven wordt lijkt voor mij sterk op een soort Price2 documenten opstellen en daarna het werk volledig uit laten voeren conform planning.

Het mooi is ten opzicht van "gewone projecten" dat de doorlooptijd veel korter is. Dus dat de kans dat de context / omgeving verandert tijdens de implementatie is daardoor vele malen kleiner.
Bij versie nummers wordt vaak de Semantic Versioning methodiek toegepast.
Given a version number MAJOR.MINOR.PATCH, increment the:
  1. MAJOR version when you make incompatible API changes
  2. MINOR version when you add functionality in a backward compatible manner
  3. PATCH version when you make backward compatible bug fixes
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
In de praktijk zien we dit steeds minder vaak. In ieder geval bij de grotere softwareprojecten. Daar zien we juist vaker dat ze de versienummers (de majeurs) laten oplopen vanuit (ogenschijnlijk) sprints. Zie de versies van bijvoorbeeld browsers en zo. Of op basis van een datum. (zie Home Assistant en zo.)

Ik vind het overigens persoonlijk een hele prettige manier, als software-ontwikkelaar het wel toepassen. Dan weet je als gebruiker/afnemer van de dienst/software beter waar je aan toe bent. (vooral professioneel is dit erg praktisch.)
rens-br Forum Admin IN & Moderator Mobile 17 juli 2025 10:48
Custom ROM's interessant onderwerp om weer een keer op te rakelen. Ik was zelf een Custom ROM gebruiker van ongeveer het eerste uur.

Ik heb een Samsung Galaxy S Plus gehad met een ROM, zodat ik weer updates kreeg, uiteraard ook een HTC HD2 gehad, met daarop Android, wat opzich prima werkte.
Daarna een OnePlus One gekocht, default geleverd met CyanogenOS erop, nadat de support vanuit OnePlus was gedropt heb ik daarop CyanogenMod gedraait, wat later LineageOS werd.

Toen de OPO voort echt wat te traag werd ben ik overgestapt naar een Pocophone F1, een toestel wat wel 14 dagen zijn originele ROM heeft gedraaid(tijd dat het koste om de bootloader te unlocken), waarna ik ben overgestapt op LOS. Ook dat werkte eigenlijk erg goed, maar het nadeel van zo'n ROM blijft toch wel dat ik regelmatig opnieuw moest installeren als het flashen weer eens fout gegaan was. Voordeel was dat het toestel nog steeds ondersteund wordt en ik recentelijk Android 15 heb geïnstalleerd en dat gezien de leeftijd eigenlijk nog erg goed draait.

Mijn main device is de Nothing Phone (1), ook die heb ik meteen uit de doos de bootloader unlocked, echter het toestel nooit geroot en aangezien allerlei zaken niet zo goed werken met een unlocked bootloader heb ik deze na een half jaar ook weer dichgezet. Inmiddels heb ik dat toestel ruim drie jaar en draai dan ook al drie jaar op de stock versie. Nothing OS werkt ook gewoon goed, stabiel en is lekker clean. Het toestel krijgt nu nog ongeveer één jaar updates, wellicht dat ik daarna toch overstap op LineageOS, of ik doe nog een tijdje 'updateloos'.

Custom ROM's draaien is tegenwoordig gewoon wat minder nodig. Software is lekker stabiel, alle features zitten er gewoon standaard in, rooten is eigenlijk niet echt meer nodig voor het unlocken van extra mogelijkheden. Updates krijgt je tegenwoordig voor 4 tot 7 jaar. Kortom het werkt 'gewoon'.

[Reactie gewijzigd door rens-br op 17 juli 2025 10:50]

Iedereen hier in huis (vrouw, 2 kinderen en ikzelf) heeft een telefoon die geen updates meer krijgt van de fabrikant, maar die met LineageOS erop toch alles doet wat moet. Mijn telefoon van 5 jaar oud doet gewoon nog wat ik wil dat ie doet, ik mis niets.
rens-br Forum Admin IN & Moderator Mobile @Cafe Del Mar17 juli 2025 11:21
Ik had met een unlocked bootloader paar jaar geleden in ieder geval problemen met Google Pay op mijn Nothing Phone (1). Op mijn Pocophone had ik dit probleem niet, want die heeft geen NFC.
Hier vergelijkbaar, maar dan met Tablets. Heb er twee: Samsung Tab S 7 en Xiaomi Pad 6. Beide prima tablets maar geen OS upgrades terwijl ze voor tablets nog prima te gebruiken zijn. Misschien zijn OS upgrades minder relevant, maar voor die Xiaomi vindt het wel fijn om van MUI af te zijn :).


Om te kunnen reageren moet je ingelogd zijn