Google toont op zijn website de eerste teaser van de aankomende Pixel 10-smartphone. Het toestel ziet er vrijwel exact hetzelfde uit als de Pixel 9. Op 20 augustus houdt Google een presentatie. Dan wordt de smartphonereeks officieel aangekondigd.

Android Authority-journalist Mishaal Rahman schrijft dat Google de teaser in de online webwinkel Google Store toont. Vermoedelijk gaat het om de Amerikaanse versie van de winkel, want vooralsnog is de teaser niet in de Nederlandse versie van het platform te zien.

In de teaser is een grijsblauwe versie van de Pixel 10 te zien. Het toestel heeft hetzelfde ovale camera-eiland als de Pixel 9. Ook de aanknop en volumetoetsen zitten op dezelfde plek. Eerder bleek dat de prijzen van de aankomende Pixel 10-serie ook hetzelfde zijn als die van de equivalente toestellen uit de 9-reeks uit 2024.

In een eerder reclamefilmpje was de Google Pixel 10 ook al te zien. Het ging om hetzelfde model als nu in de teaser te zien is. In dat filmpje is het toestel echter al uit meerdere hoeken te zien.

Microsoft werkt mogelijk aan een eenvoudigere manier om audio in Windows 11 naar twee outputapparaten te sturen. De functie is in een devbuild van Windows 11 gevonden en is vooralsnog niet ingeschakeld. Het is niet duidelijk wanneer Microsoft de optie eventueel uitbrengt.

Volgens Windows-insider PhantomOfEarth is er een nieuwe optie te vinden in het native audiomenu van Windows 11 in een recente ontwikkelaarsversie van het besturingssysteem. Onder Gedeelde Audio kunnen gebruikers naar verluidt een tweede audio-outputapparaat selecteren, als toevoeging aan het standaardapparaat dat al geselecteerd is. Op deze manier kunnen gebruikers met enkele muisklikken bijvoorbeeld naast een koptelefoon een speaker als outputapparaat instellen.

Windows 11 ondersteunt al een dergelijke functie, maar deze is alleen via een relatief ingewikkelde omweg in te schakelen. Daarvoor moeten gebruikers via de Geluidsinstellingen onder 'Meer geluidsinstellingen' handmatig de Stereo Mix-functie in het tabblad Opnemen configureren.

De ceo van Ubisoft, Yves Guillemot, heeft tijdens een vergadering van aandeelhouders gereageerd op de eisen van het Stop Killing Games-initiatief. Volgens hem zijn games eindig maar werkt Ubisoft aan manieren om de 'impact op spelers te minimaliseren'.

Guillemot stelt in een antwoord op een vraag van een aandeelhouder dat individuele games als een service op den duur beëindigd worden: "Niets is voor eeuwig. We doen ons best om ervoor te zorgen dat dit proces voor spelers en kopers goed verloopt, want vanzelfsprekend kan ondersteuning voor alle games niet voor altijd", zo citeert gamejournalist Stephen Totilo.

Wel laat Guillemot weten dat zowel Ubisoft als de game-industrie als geheel werken aan manieren om de impact op spelers van het niet meer ondersteund worden van games zo klein mogelijk te maken. Hij noemt als voorbeeld het offline gaan van The Crew, wat de reden was dat het Stop Killing Games-initiatief werd opgezet. In aanloop naar dat moment zou Ubisoft het vervolg, The Crew 2, voor een euro aan kopers van het origineel hebben aangeboden. Daarnaast benadrukt Guillemot dat gamers van tevoren ingelicht worden over het toekomstige verdwijnen van een spel. Overigens zegt hij niets over het feit dat The Crew 2 en The Crew Motorfest rond diezelfde periode een offlinemodus kregen om kopers tegemoet te komen.

De Ubisoft-ceo neemt een stelling in die overeen lijkt te komen met die van veel andere grote gamebedrijven. Op basis van de aanvankelijke reactie en de uitgebreidere vervolgreactie van de industrie blijkt dat gamemakers vinden dat ondersteuning voor games beëindigd zou moeten kunnen worden, ook als dat ervoor zorgt dat games daardoor helemaal niet meer speelbaar zijn. Vooralsnog lijkt het erop dat de Europese Commissie zich na het waarschijnlijk succesvolle EU-burgerinitiatief over deze kwestie gaat buigen. Het is nog niet duidelijk of daaruit ook een wet volgt en wat die eventuele wet precies inhoudt.

Het Openbaar Ministerie verwacht nog 'weken' uit voorzorg afgesloten te zijn van het internet vanwege beveiligingsproblemen die vorige week werden ontdekt. Het OM gebruikt de software Citrix NetScaler, die een kritieke kwetsbaarheid bevat.

Het Openbaar Ministerie doet nog onderzoek naar de beveiligingskwetsbaarheid, maar zegt dat het implementeren van een oplossing ingewikkeld en tijdrovend is. Volgens het OM wordt 'de komende periode' stapsgewijs bekeken welke systemen weer online kunnen. Momenteel zijn er al enkele zaaksystemen online, waardoor werknemers weer toegang hebben tot dossiers.

Voorlopig kunnen OM-werknemers alleen op kantoorlocaties inloggen, zijn ze niet per e-mail bereikbaar en hebben ze slechts beperkt toegang tot digitale systemen. Ze kunnen bijvoorbeeld geen dossiers bewerken of printen, zegt een woordvoerder tegen de NOS. De overheidsinstantie probeert de impact op onder meer strafzaken en zittingen naar eigen zeggen zo klein mogelijk te houden. Zo helpen rechtbanken en gerechtshoven voorlopig met het printen van de benodigde stukken. Wel is er sinds vrijdag 'incidenteel' een zitting afgelast vanwege de problemen, schrijft de NOS.

Het Openbaar Ministerie ging vrijdagochtend offline, nadat duidelijk werd dat de Citrix NetScaler-software een kritieke kwetsbaarheid bevat. Hiermee konden kwaadwillenden authenticatietokens en inloggegevens in handen krijgen. Volgens het Amerikaanse Cybersecurity & Infrastructure Security Agency wordt het CitrixBleed 2-lek actief misbruikt.

KPN komt met nieuwe roamingbundels voor Thailand, Japan en Indonesië. Daarnaast heeft de provider de hoeveelheid data en prijzen van de bundels voor vijftien andere niet-EU-landen aangepast.

KPN heeft naar eigen zeggen de bundels aangepast voor de populairste vakantiebestemmingen buiten de Europese Unie. Voor drie van deze landen, Thailand, Japan en Indonesië, bood de provider voorheen nog geen eigen databundel aan. Bij de andere landen zijn de bundels vergroot of zijn de prijzen verlaagd.

KPN bood voorheen bijvoorbeeld een roamingbundel van 15GB aan in de VS en Canada voor 35 euro, maar heeft de hoeveelheid data nu voor dezelfde prijs verhoogd naar 20GB. In Marokko was eerst enkel een 3GB-bundel beschikbaar voor 25 euro, maar nu is de prijs verlaagd naar 20 euro en is er een 6GB-bundel bijgekomen voor 30 euro. De bundels zijn na het activeren 31 dagen geldig.

De reacties zijn een van de waardevolste onderdelen van Tweakers. Regelmatig vind je daar interessante, diepgaande extra informatie van experts en gebruikers met praktijkervaring over een onderwerp. In dit artikel zetten we de beste reacties met een +3-moderatie van juni op een rij.

Tweakers maken Tweakers. Dit platform bestaat bij de gratie van gebruikers, die discussiëren op het forum, handelen op V&A en elkaar zelfs tijdens live-evenementen ontmoeten. Maar een van de belangrijkste onderdelen waar tweakers hun waarde toevoegen, zijn de reacties. Die houden ons niet alleen scherp en corrigeren ons op fouten, maar geven ook vaak waardevolle context of extra informatie die anderen meer kan leren. Daarvoor zijn we erg dankbaar. Het gaat bijvoorbeeld om informatie uit de praktijk, die we zelf nooit kunnen weten zonder die praktijkervaring.

De beste reacties worden door andere tweakers met een +3 beoordeeld. De lat om een +3-moderatie op een reactie te krijgen ligt hoog, maar dat levert wel erg mooie resultaten op.

Hoe maak je wafers?

Computerchips maken is, op z'n zachtst gezegd, ingewikkelde materie. Niet gek dus dat twee van de tien +3-reacties onder een artikel over TSMC's waferprijzen staan. Tweaker jdh009 legt in deze reactie uit hoe de prijzen per wafer worden berekend.

Klopt, toen ik het overzicht las vroeg ik me ook het een en ander af, dus zelf het een en ander nagezocht. Wat je volgens mij kunt stellen is dat bij de door Dutchzilla genoemde wafers vrijwel iedere wafer een 300 mm (12 inch) is. De (gelekte) prijzen van TMSC vond ik hier (2004-2022) en hier (2020-2025, met pprijsontwikkeling over tijd) en bedragen (inflatiecorrectie niet toegepast):

• 90nm (2004): $2.000
• 40nm (2008): $2.600
• 28nm (2014): $3.000
• 10nm (2016): $6.000
• 7nm (2018): $10.000
• 5nm (2020): $16.000
• 3nm (2022): $20.000
• 2nm (2025) $25.000

De meerprijs per wafer komt vooral door duurdere materialen (zoals wafers die schoner, vlakker, zuiverder en mechanisch stabieler moeten zijn, en de hogere kosten voor EUV-resist en reticles), extra processtappen (EUV double patterning) en duurdere apparatuur om dit alles te doen (blame ASML). Dat maakt het mogelijk om een aantal algemene regels te stellen over chipdichtheid, kostprijs en opbrengst per wafer. Het waferformaat ligt immers vast, waardoor het aantal chips per wafer vooral wordt bepaald door de chipgrootte, complexiteit, gebruikte node en de yield.

In theorie zou je bij kleinere nodes dus het volgende verwachten:

1. Een kleinere node laat kleinere dies toe en dus méér chips per wafer
2. Bij gelijke chipgrootte neemt de complexiteit toe: meer transistoren per mm²
3. Meer chips per wafer verlaagt de kostprijs per chip, als de yield gelijk blijft
4. Een kleinere node betekent echter ook een duurdere wafer

In de praktijk:

1. Chips worden meestal niet kleiner, omdat ontwerpers de extra transistorruimte gebruiken voor meer functionaliteit (vooral bij high-end SoC’s, GPU’s en CPU’s)
2. De chipgrootte blijft daardoor gelijk of groeit zelfs, waardoor het aantal chips per wafer beperkt blijft
3. Niet elke chip vereist een kleinere die; soms zijn oudere nodes goedkoper en praktischer (zie veel uit de autobranche)
4. Bij nieuwe nodes is de yield in het begin vaak lager door een hogere kans op defccten
5. Daardoor zijn er minder werkende chips per wafer dan je op basis van de node zou verwachten
6. Intussen stijgen de waferkosten, wat de prijs per werkende chip verder opdrijft
7. De yield verbetert vaak na verloop van tijd, zodra bijv. TMSC het productieproces beter onder de knie heeft
8. De transistordichtheid blijft in de praktijk vaak achter bij de theoretische limiet, waardoor de verwachte efficiëntiewinst per mm² niet volledig wordt gehaald (zie tabel hieronder).

En ik zal vast nog wel wat missen. Tijdens het zoeken kwam ik een mooi voorbeeld tegen van de iPhone-SoC. Tabelletje hier: https://tweakers.net/fotoalbum/image/BJsxXjGq7MzWp3C2LYBuFX9L.webp.

Als je de Apple-SoC’s van A10 tot A14 vergelijkt, zie je dat de die size niet geleidelijk afneemt. Van 125 mm² bij de A10 (16nm, 3,3 miljard transistors) daalt het eerst flink tot 83 mm² bij de A12 (7nm, 6,9 miljard transistors), maar stijgt daarna weer naar 98 mm² bij de A13, omdat Apple op dat oppervlak (nog) meer functionaliteit wilde onderbrengen. Bij de A14 (5nm, 11,8 miljard transistors) daalt de die size licht naar 88 mm², maar blijft deze nog steeds groter dan bij de A12.

Een 300 mm-wafer heeft een totaal oppervlak van ongeveer 70.700 mm², maar door de cirkelvorm en de rechthoekige vorm van chips treden er randverliezen op. Het bruikbare oppervlak voor chips ligt daardoor meestal rond de 63.000 tot 65.000 mm². Bij een chipgrootte van circa 100 mm² passen er dus grofweg 630 tot 650 chips op één wafer, mnatuurlijk afhankelijk van de plaatsing en de vorm van het chipontwerp.

Als we dit toepassen op Apple, zien we dat chips in de praktijk niet altijd evenredig krimpen bij een kleinere node. Apple gebruikt de extra transistorcapaciteit zoals de zien is vaak voor meer cores, grotere GPU’s of AI-units, waardoor de die-grootte regelmatig gelijk blijft of zelfs toeneemt, zoals in het voorbeeld van twee alinea's terug. Hierdoor nam het aantal chips per wafer niet sterk toe en daalde het zelfs percentage werkende chips, ondanks theoretisch kleinere die grootte.

Als je daarmee gaat rekenen, kun je voor Apple de volgende theoretisch te verwachten aantallen chips per wafer afleiden. Deze schattingen houden ook rekening met randverliezen, dus met het effectief bruikbare oppervlak van een 300 mm-wafer:

• 28 nm (A7, 102 mm²): +/- 620 chips
• 20 nm (A8, 89 mm²): +/- 715 chips
• 16 nm (A9, 96–104 mm²): +/- 610–660 chips
• 16 nm (A10, 125 mm²): +/- 510 chips
• 10 nm (A11, 89 mm²): +/- 715 chips
• 7 nm (A12, 83,3 mm²): +/- 760 chips
• 7 nm (A13, 98 mm²): +/- 650 chips
• 5 nm (A14, 88 mm²): +/- 720 chips

One of the immediate ramifications of dual sourcing is that the die sizes of the A9s are different. The A9 produced by Samsung on their 14nm FinFET Process is the smaller of the two, at 96mm2. Meanwhile the A9 produced on TSMC’s 16nm FinFET process is 104.5mm2, making it about 9% larger. Though not an immense difference in size (and not that we’d expect otherwise) there are tradeoffs to be had. With all other things held equal, the larger TSMC die would produce fewer complete dies per 300mm wafer, and any given die is more likely to have an imperfection since there are fewer dies for the same number of imperfections.

Bron: https://www.anandtech.com/show/9686/the-apple-iphone-6s-and-iphone-6s-plus-review/3

Waardoor je kunt stellen dat: een groter oppervlak levert minder chips per wafer op en vergroot de kans dat een defect een chip raakt.

Ook de yield daalt over het algemeen bij nieuwe, fijnere nodes, vooral in de beginfase, al is volgens recentere cijfers de yield van TSMC’s 3 nm inmiddels (2025) boven de 90% terwijl het bij Samsung minder goed gaat (maar dit is wel sterk afhankelijk van ontwerp en klant):

Media reports said TSMC has already boosted the yield of its 7nm and 5nm chips to 93.5% and 80%, respectively, in 2019. Now TSMC is making 3nm chips with a yield of 55%, competing against Samsung’s 60-70%.

Samung: According to South Korean media outlet Chosun Biz, even after three years of mass production, its 3nm yields remain at just 50%.

Bron: https://asiatimes.com/2024/02/smic-to-sell-huawei-costly-inefficient-5nm-chips en https://www.trendforce.com/news/2025/05/29/news-samsungs-3nm-yield-reportedly-stuck-at-50-far-behind-tsmcs-90/

Daardoor kunnen er vrij veel chips wel geproduceerd worden, maar uiteindelijk onbruikbaar blijken door defecten, wat resulteert in een lage yield. Soms zijn ze nog deels bruikbaar, als defecte onderdelen uitgeschakeld kunnen worden terwijl de rest van de chip nog functioneert, zodat ze alsnog binnen de specificaties vallen en als een lager model verkocht kunnen worden, wat kosten kan besparen.

Maar dat kun je niet aannemen. Op 2nm zal een verder (qua functionaliteit) identieke chip kleiner zijn dan een chip op een ouder procede en passen er dus meer van die chips op dezelfde wafer.

Dat klopt... theoretisch betekent een kleinere node kleinere transistoren, en dus een kleinere chip bij gelijke functionaliteit. Maar, zoals je hierboven in mijn veel te uitgebreide tekst leest, is niet elke chip gebaat bij een kleinere node. Of dat zinvol is, hangt af van de toepassing, de bijbehorende kosten, de beschikbaarheid van productiecapaciteit en eisen zoals betrouwbaarheid, bestendigheid of lange levertermijnen (vooral in de auto-industrie krijgen oudere nodes vaak de voorkeur, omdat kleinere nodes gevoeliger zijn voor spanningspieken, hitte en straling.)

En zelfs als een chip wel op een kleinere node wordt geproduceerd, betekent dat niet automatisch dat hij ook kleiner wordt, zoals in het voorbeeld van Apple’s SoC’s, waar de diegrootte vaak gelijk bleef of zelfs toenam. Daardoor blijft het aantal (potentiële) chips per wafer in de praktijk meestal vergelijkbaar met eerdere generaties, zolang een kleinere node vooral benut wordt voor extra functionaliteit binnen dezelfde oppervlakte en dat in het eindproduct ook daadwerkelijk een meerwaarde oplevert.

Geen lieve ontwikkelaar

Een beetje drama is de opensourcewereld niet vreemd, maar als je als ontwikkelaar heel radicale ideeën hebt, val je zelfs daar op. Het viel deadinspace dan ook op dat de ontwikkelaar achter een Xorg-fork erg opvallend gedrag vertoonde. Dat wordt mooi uiteengezet in deze reactie:

Oef, ik ben even een beetje verder gaan kijken, maar dit is wel de moeite van het opmerken waard. In de project description van de XLibre fork staat inderdaad:

It's explicitly free of any "DEI" or similar discriminatory policies.

En

Together we'll make X great again!

Maar dat is maar het topje van de ijsberg. Ik vind deze passage bovenaan in de project description misschien wel zorgwekkender voor het project:

That fork was necessary since toxic elements within Xorg projects, moles from BigTech, are boycotting any substantial work on Xorg, in order to destroy the project, to elimitate competition of their own products. Classic "embrace, extend, extinguish" tactics.

"Moles from BigTech" proberen Xorg te vernietigen? Dit klinkt gewoon als een complottheorie.
Hij postte ook dit over corona vaccins op de Linux kernel mailing list (waarop Linus Torvalds hem in typische Linus-stijl vertelt dat hij op moet flikkeren):

And I know *a lot* of people who will never take part in this generic human experiment that basically creates a new humanoid race (people who generate and exhaust the toxic spike proteine, whose gene sequence doesn't look quote natural). I'm one of them, as my whole family.

> So yes, sure, nobody can stop people that think the pandemic is over
> ("we are vaccinated") from meeting in person.

Pandemic ? Did anybody look at the actual scientific data instead of just watching corporate tv ? #faucigate

En het wordt niet beter naarmate ik verder zoek. Hij is een Duitser, en hij lijkt van mening te zijn dat Duitsland in WW1 en WW2 meer slachtoffer was van "de imperialisten" dan iets anders. Selectieve quote:

WW1 was clearly *NOT* started by Germany - the only mistake of the Emperor was officially declaring a war, that was already going undeclared. And WW2 was forced upon Germany, and the allied rejected all the numerous peace offerings from the German side.

Andere juweeltjes in dat bericht zijn dat hij ontevreden is dat de extreem-rechtse AfD met Nazi's vergeleken wordt, en hij wil dat Holocaust-ontkenning legaal is.



Oef. Maar, terug naar XLibre, en het verhaal achter de fork. Hij klaagt dus dat "Redhat employees banned [...] so censored all my work" omdat "My most evil heresies probably were: a) forking Xorg and making *actual progress*".

Hij lijkt inderdaad te hebben bijgedragen aan Xorg; Zo'n 800 commits sinds februari 2024.

800 commits klinkt veel, maar bij het scrollen door die lijst viel me onder andere deze commit op met maar 6 gewijzigde regels:

os: unexport ClientIsLocal()
Not used by any modules, so no need to keep it exported.

Dat is niet heel groot, en lijkt ook niet al te belangrijk. Maar ok, cleanupje, mogelijk prima. Maar hij heeft 24 van dat soort "os: unexport Foo" commits. Zo kom je wel aan 800.

In zijn andere cleanups is het een aantal keer voorgekomen dat hij onbedoeld Xorg stuk maakte voor gebruikers, wat kritiek van andere Xorg ontwikkelaars opleverde. Het lijkt er nu op dat die verstandhouding inmiddels zo slecht is dat hij er uit gegooid is (of boos is opgestapt? Ik kon zo snel geen bewijs vinden dat hij echt geband is).

Het is moeilijk en veel werk om de precieze dynamiek uit te zoeken zonder honderden commits, bugreports en mails te lezen, maar ik vond de discussies in de volgende twee Xorg git issues de sfeer wel een beetje samenvatten.

In 1760: Xorg git broken again (oktober 2024, issue is nog steeds open?):

davidbepo: @metux i appreciate you maintaining and trying to improve Xorg but this is the second time you break it recently, you really should implement more testing...

Jasper St. Pierre: Honestly, I would strongly recommend just not merging anything @metux does from now on. I do not feel that their presence here has been a net positive -- I have seen zero actual bugs solved by any of their code changes. What I have seen is build breakage, ABI breakage, and ecosystem churn from moving code around and deleting code.
Xorg could use some actual maintenance, but that means fixing actual bugs and solving real problems.

In 1797: xrandr doesn't work anymore on xorg-git (februari 2025). Sommige comments zijn gericht aan Enrico Weigelt, sommige comments gaan over hem:

Peter Hutterer: bugs happen, that's normal, but the commit at fault here (c6f1b8a7) did nothing but shuffle code around. No bug fixed, no new feature added, just changing things around. And there are hundreds of other commits like this.

Michel Dänzer: Apologies for being blunt, but I'm afraid it's more like "everyone except you" by now. He's managed to fall out with pretty much every other active project member.
[...]
In general, a very small percentage of Enrico's commits have any user-visible effect. I honestly don't believe they truly benefit Xorg users, certainly not enough to make up for the churn and pain.

Peter Hutterer: I'm not sure why you think trash-talking code that's several decades old is useful. Rules, requirements and tools were different 20 years ago, and even more different 40+ years ago and you're ignoring the various user visible changes that have been fixed over decades. Or, IOW, you're apparently unaware or ignoring that dozens of people have also improved things before you came to your realization that the code is bad.

Some of the code you've been rewriting hasn't changed for decades and requiring others to review, build and test changes just to have e.g. different struct initialization style (like the commit set that triggered this regression) is not worth it. Easy to fix does not imply easy to review and certainly does not imply the result is bug-free.

I burnt myself out trying to review your flood of patches that shuffle things around and eventually gave up. For me this also meant I stopped looking at other MRs because everything else got drowned out.

Daniel Stone: And yet, as @whot says above, your changes are not helping. Changing calls pScreen->DestroyPixmap to dixDestroyPixmap doesn't meaningfully improve the code or make it easier to reason about. Moving byte-swapping of requests and events from one function to another doesn't make the code more robust. Cosmetic changes to the way length fields are written doesn't help with byte vs. word unit confusion, or keep you from writing the wrong amount of data. You're just moving the complexity from point A to point G, not reducing it.
[...]
The immense value X11 has - that it always had and will have for decades to come - is its backwards compatibility, still being able to run 40-year old apps. You correctly called the codebase 'fragile' - you've been finding this out as your changes repeatedly break things. If you're breaking apps, then what exactly is the value in a codebase which is 'cleaner' to your subjective standard but doesn't actually work? If you're trying to get to a multi-threaded xserver, have you read the classic MTX post-mortem where the people who actually did it discussed the problems they faced and why they discontinued it?

Jasper St. Pierre: @metux that you've had to fix this bug twice (!1844 (merged), !1845 (merged)) shows a lack of attention and care. This was a known regression, with clear reproduction steps, and at first glance, it does not look like you tested your PR at all.

De aard van zijn technische bijdragen en de kritiek van langer actieve Xorg developers geven me dan ook weinig hoop.

Alles bij elkaar zie ik twee goede redenen om XLibre niet al te serieus te nemen.

De impact van schermtijd op kinderen

Hoe erg is schermtijd nou eigenlijk écht voor kinderen? Die discussie speelt al jaren, maar Mirved zette eens op een rij wat het wetenschappelijk onderzoek daar eigenlijk over zegt, bij dit artikel over hoe het Nederlandse kabinet Europese normen voor socialemediagebruik bij kinderen wil invoeren.

Wist niet dat Smartphones en Social media in deze vorm al 100 jaar bestond. Wat betreft onderzoek:

Een Canadese en Zuid-Koreaanse studie toonde aan dat zelfs kleine hoeveelheden mobiele schermtijd bij baby's (rond 18–30 mnd) samenhangen met taalachterstanden: elke extra 30 min/dag verhoogt de kans op taalvertraging met ~49 %

https://pmc.ncbi.nlm.nih.gov/articles/PMC8572488/

peuters (3–5 j) die meer dan 1 uur/dag schermtijd hadden, minder witte stof-ontwikkeling hadden in hersengebieden belangrijk voor taal en zelfregulatie.
https://pmc.ncbi.nlm.nih.gov/articles/PMC6830442/

Een studie met 7.097 kinderen in Japan toonde dat 1 tot 4 uur schermtijd op leeftijd 1 gekoppeld was aan significant hogere kans op ontwikkelingsachterstanden (communicatie, fijne motoriek, sociale vaardigheden) op de leeftijd van 2

https://edition.cnn.com/2...risks-wellness/index.html

Britse Canadeze peuters (3–5 j) met meer dan 1 uur/dag schermtijd bleken een 48 % lagere kans te hebben op goede werkgeheugencapaciteit.
https://pubmed.ncbi.nlm.nih.gov/35599677/

Studies tonen aan dat vroege blootstelling aan smartphones en YouTube samenhangt met verhoogde emotionele/gedragsproblemen, door blootstelling aan ongepaste content en algoritmische aanbevelingen
https://bmcpublichealth.b...0.1186/s12889-024-19011-w

Intels massaontslagen

Intels sores houden veel tweakers al lang bezig. Ook de interne strubbelingen rond de massaontslagen van duizenden werknemers zijn interessant, zoals kidde uitlegde bij dit artikel over die massaontslagen.

Dat is niet het hele verhaal:

De chip-foundry van AMD fuseerde met Chartered om GlobalFoundries te vormen, en GlobalFoundries bleek op het laatste moment geen werkend 14nm proces te hebben. AMD was contractueel vastgelegd om bij GlobalFoundries te kopen. TSMC was geen optie; Ryzen 1 was eigenlijk ten dode opgeschreven.

Tegelijk had Samsung het 14nm proces ontworpen voor Exynos smartphone-processors. En wonder boven wonder, kwam iemand van op het lumineuze idee, om Samsungs 14nm smartphone-proces in licentie te geven aan GlobalFoundries.

En ziedaar, het succes van Ryzen: dat zorgde ervoor dat AMD in een keer competitieve server-chips had. En dat zorgde voor de marge-compressie (hard teruglopende winst vanwege verlies van de monopolie-positie) bij Intel.

Vervolgens, Intel 10nm: Het is hetzelfde verhaal over net een beetje teveel hoogmoed van Market Garden / "een bridge too far". Bij Market Garden moesten de geallieerden tegelijk bruggen veroveren in Son en Breughel, Veghel, Nijmegen en Arnhem, en als er 1 zou mislukken, zou het hele project (hogere doel was eerder in Berlijn zijn dan de Sovjets) mislukken. En dat gebeurde helaas.

Natuurlijk werd Montgomery gewaarschuwd dat het plan megalomaan was (onder andere door Sosibowski); en Montgomery zou later aangeven dat alles fout had kunnen gaan; maar het enige probleem was de infrastructuur; er was niet genoeg hulp - en met name door Montgomery zelf niet genoeg tijd (!) gegeven aan het 1e Canadese leger om de Westerschelde (en daarmee diepzeehaven) Antwerpen in te nemen. En daardoor waren de aanvoerlijnen niet goed.

Intel 10nm zat ook zo in elkaar:
-Veghel: Er was een ontwerp waar het hele ontwerp-team aan had gewerkt, genaamd Cannon Lake, dat afhankelijk was van de M1 poly-pitch (kleinste afstand tussen metalen geleidende kanalen van dit proces) van 36nm. Als die afstand groter zou worden, zou Cannon Lake niet meer maakbaar zijn.
-Son en Breughel: Intel zou voortaan Single Dummy gates gebruiken; een beetje het idee van ruimte-besparing van een trein in de 2e klas, vergeleken met de 1e klas . Waarbij je in plaats van twee "prive-armleuningen" per stoel, je de armleuning "deelt' met de buurman, waardoor er eentje weggelaten kan worden.
-Nijmegen: Contact over active gate: De contacten zitten niet meer naast een bepaalde schakeling, maar er boven.
-Arnhem: Vanwege quantum fysica tussen verschillende lagen, kunnen er vroeg of laag electronen gaan "lekken" tussen 2 lagen die moeten isoleren. Als er veel "druk" op de lagen staat (potentiaal-verschil a.k.a. voltage) over langere tijd, kan daardoor de chip gaan falen.
Om dat te voorkomen, ging Intel een nieuw materiaal gebruiken bij de grenslaag: Kobalt.
Bij het maakproces echter, komen er vaak spanningen in het materiaal; net als bij metaal harden. Om dat "ontgedaan" te maken gloei je metaal na; vaak aangeduid als "ontlaten".
Intel echter had geen ervaring met kobalt ontlaten, en de leverancier van de ontlaat-ovens (Applied Materials) had Intel aangegeven, dat volgens de leverancier dus (AMAT), het proces nog niet rijp was voor massa-productie. Dus net als Montgomery had Intel eigenlijk de "infrastructuur" voor het plan niet op orde; en teveel haast gemaakt; en niet naar waarschuwingen geluisterd omdat ze dachten dat ze het beter wisten dan anderen.

Intel echter dacht dat ze beter wisten dan de leverancier hoe ze dat voor elkaar moesten krijgen, en dat mislukte.

Daarom mislukte de brug 'Arnhem', (kobalt), en daarom mislukte het hele project 10nm; en was Cannon Lake dus ook ten dode opgeschreven.

Welnu, het electro-migratie-probleem: Om tegen te gaan dat er voor het einde van de levensduur electronen gaan lekken bij de grenslaag, moet je de "slijtage" op het grensvlak verminderen. Dat kan door te kiezen voor een kortere levensduur, maar voor servers is dat geen optie.
Of je kiest ervoor de "druk" (spanning, voltage dus) te verlagen. Daar koos Intel voor, en de frequentie is een derdemachts-functie van het voltage.

Intel heeft vermoedelijk het voltage met 10% moeten verlagen, dan is de frequentie 1.10³ = 33% lager, en daarom was Cannon lake in plaats van 4gHz op 3gHz gezet.

Waarom hadden TSMC en GloFo geen last van het cobalt-verhaal: Van TSMC weet ik het niet, maar GloFo zat in de common platform alliance met IBM; en die hebben hele goede natuurkundigen. Iemand, mogelijk iemand van IBM; heeft een ander trucje bedacht, ik dacht iets met mechanische spanning op het materiaal zetten, waardoor ze geen last hadden van het levensduur-verkortende electromigratie probleem. En daarom had de concurrentie helemaal geen Kobalt nodig.

Vervolgens mocht AMD na het 14nm proces contractueel weg bij GlobalFoundries, maar ze wilden daar wel klant blijven. Dus had iemand wederom een lumineus idee: Het mixen van GlobalFoundries (I/O die) met TSMC binnen 1 chip. Zo kon een stuk van Ryzen 1 (Samsung proces dus) hergebruikt worden met kleinere dies van TSMC, en daardoor kon AMD sneller vooruit; zonder alles overnieuw te hoeven ontwerpen.

Overigens, double patterning en met name SADP (single aligned double patterning) is juist iets waar Intel extreem goed in is; ze waren er zelfs zo goed in dat ze het twee keer achter elkaar konden doen om tot SAQP (single alligned quadruple patterning) te komen. De Intel baas heeft ooit gezegd dat er echter quintuple of sextuple patterning nodig was; terwijl bijvoorbeeld Samsung gewoon het veel eenvoedigere LELELE deed (litho-etch-lito-etch-lito-etch). Dus eigenlijk totaal verchillende keuzes.

Lichte en donkere foto's

Onze downloadssectie is vooral populair omdat tweakers er zelf hun praktijkervaringen kunnen delen met software. In deze releasenotes over het fotobewerkingsprogramma Darktable zette dipje2 op een rij hoe dat programma werkt met lichte en donkere foto's.

Het hele "scene referred" betekent dat je zo lang mogelijk blijft werken in "ruw licht" als values... Eigenlijk een soort van hdr mode om het simpel uit te leggen, en dan een tone mapping stap op het eind om het in normaal, gamma correct sdr te krijgen.
Daarna kan je ook wel changes maken, maar echte kennis van "hoeveel licht" is dan weg, het is meer "lichter en donkerder", maar niet meer absoluut. Beetje vaag om in een reactie te omschrijven .

Filmic-rgb en sigmoid zijn inderdaad twee manieren om die tone mapping stap te doen. Filmic-rgb is gemaakt door een ontwikkelaar die ondertussen niet meer aan Darktable werkt, maar zijn eigen fork.
Filmic-rgb kan veel leuke dingen, maar is moeilijk te begrijpen soms, en doet dingen die niet altijd gewenst zijn. Sigmoid is _meestal_ simpeler en heeft minder settings / parameters. En daarom makkelijker in het gebruik.

Alle twee werken ze door een soort van curve te maken, een S-curve die voor wat contrast zorgt. Highlights zitten wat meer bij elkaar, shadows zitten wat meer bij elkaar, wat ruimte in het midden voor je mids. Bij filmic-rgb kan je veel parameters aanpassen om die curve te beïnvloeden, en hoe diep gaan de shadows en waar stoppen de highlights (alle twee moet je eerst met exposure het middenpunt instellen). Sigmoid zal altijd alle data gebruiken die er is, en zelf een mooie contrast curve maken. Maar die kan je dus moeilijker tweaken. En aanpassingen moet je dus eigenlijk doen voor sigmoid, vooral met de tone equalizer (waar je bepaalde zaken lichter en donker kan maken). Omdat je bij filmic-rgb het tonemapping process meer kan beinvloeden, merk ik dat het niet altijd nodig is om dingen 'goed' te hebben voor die stap. Dingen zoals shadow-crush regel ik in filmic-rgb, niet in een aparte module bijvoorbeeld.

Ze verschillen ook in wat ze - standaard - doen met de highlights in combinatie met kleur.
Denk aan een mooie knalrode bloem. Geef die meer licht... Meer licht, meer licht... nog meer licht. Wat gebeurt er met het knalrood? Wordt het ooit zo licht dat het puur wit wordt, en je geen rood meer ziet? Of blijft het knalrood? Of er tussen in?
Sigmoid gaat uiteindelijk naar wit toe, en een hoop mensen verwachten dat. Vooral met sunsets en landschappen, en dergelijke. Maar bij portret of human subjects kan het juist gewenst zijn dat je de kleur (beter) blijft zien, en juist niet naar wit gaat.

Ook met kleuren 'out of gamut' zit er verschil. Diezelfde knalrode bloem. Die is veeeeel te rood dan wat er eigenlijk mogelijk is in sRGB plaatjes. Je camera heeft wel de mogelijkheid om de hoeveel rood goed op te vangen, maar als je het uiteindelijk op het web of op de standaard wil weergeven, moet je iets met die TE intense kleur rood. Wil je de details in het rood bewaren? Dan maak je het minder intensief. Je raakt dan saturation kwijt, maar je hebt wel al het kleurverloop. Of clip je het zodat zo veel mogelijk van de saturatie behouden blijft, maar met de kans dat je geen verschil meer ziet in 'hoe rood', alleen maar 'puur rood'.
Hier hebben ze verschillende algoritmes, en hier wordt ook constant aan gesleuteld.

Dat zijn ook problemen in de wereld van Blender of DaVinci Studio trouwens, alleen bestaan er standaarden in de video wereld (ACES?) die blind gebruikt kunnen worden. Niet omdat ze correct zijn, maar omdat iedereen ze gebruikt.
Ze zijn nog aan het experimenteren en worstelen wat je moet doen met dingen 'out of bounds'. Of het nu brightness is of kleurinfo, er zijn vele wegen naar Rome. En geen lijkt geschikt voor alle situaties.

Sigmoid is dus wel de simpelere van de twee en krijgt wat meer liefde en aandacht van de ontwikkelaar(s) die er nog zijn, en is waarschijnlijk gekozen als default omdat het gewoon beter werkt met zero slider tweaken, en minder 'fout' doet. Filmic-rgb heeft meer mogelijkheden en kan een live saver zijn (en snappen wat alles doet, maakt je heel veel beter in Darktable) maar kan soms ook gewoon troep produceren. En als dat de default rendering is, denken veel gebruikers "darktable zuigt".

Andere reacties

In totaal werden er in juni 19 reacties uitgedeeld die uiteindelijk op een +3-moderatie zijn beland. Dat gebeurde zowel onder nieuwsartikelen als onder .geeks, reviews en downloads. Hieronder vind je alle reacties.

Meta lijkt de huidige native WhatsApp-app voor Windows te gaan vervangen door een progressive webapp. Dat blijkt uit de nieuwste bètaversie van de chatdienst.

Versie 2.2569.0.0 van WhatsApp Beta op Windows is niet langer een UWP-app, maar in plaats daarvan een pwa die gebruikmaakt van Microsofts softwareframework WebView2, meldt Windows Latest. Meta heeft de aanpassing niet officieel bekendgemaakt, maar zegt alleen dat 'het uiterlijk en de werking' van WhatsApp Beta is bijgewerkt.

Volgens Windows Latest verbruikt de nieuwe app ongeveer dertig procent meer geheugen dan de UWP-versie. Daarnaast is het uiterlijk van verschillende interface-elementen gewijzigd, zoals de iconen voor bellen en het starten van chats. Ook kan de nieuwe app geen reguliere pop-upmeldingen meer versturen. Aan de andere kant heeft de nieuwe app wel enkele extra functies, die eerder al wel aanwezig waren in de webversie, maar niet in de native desktopapp. Zo biedt de app nu ondersteuning voor Kanalen en zijn er meer functies toegevoegd onder Community's en Status.

Meta bracht de UWP-versie van de Windows-desktopapp in 2022 uit. De versie daarvoor draaide op Electron. Het is niet duidelijk waarom Meta besloten heeft om de UWP-versie van de bèta-app te vervangen door een progressieve webapp. Windows Latest verwacht dat dit het makkelijker voor Meta maakt om de chatdienst te onderhouden, aangezien de nieuwe app gebruikmaakt van dezelfde codebase als de webversie. Of en wanneer deze verandering naar de stabiele app komt, is onbekend.

Lutris voegt ondersteuning voor Steam-gezinnen toe. Met deze functie kunnen gebruikers hun games delen met maximaal vier andere familieleden. Valve maakte de functie op 11 september 2024 officieel beschikbaar op Steam.

Ontwikkelaar rosxz schreef in maart dat hij ondersteuning voor Steam-gezinnen heeft toegevoegd door een speciale Steam-gezinnenbron aan Lutris toe te voegen. Daardoor toont de gamemanager de lijst met spellen die in het Steam-gezin staan onder een speciaal tabblad in het programma. Door in de instellingen de parameter 'STEAM_FAMILY_INCLUDE_OWN' op 'True' te zetten, toont het programma ook de eigen games in dat tabblad.

De pullrequest van rosxz is opgenomen in de main branche van Lutris, maar de functie is nog niet klaar voor de volgende grote release van het programma, versie 0.5.19. Gebruikers kunnen de functie wel al testen met een speciale prerelease van het programma of door de laatste versie van Lutris direct van GitHub te downloaden.

Lutris is een gamemanager voor Linux, waarmee gebruikers hun games vanuit verschillende platformen kunnen beheren. Het programma heeft ondersteuning voor onder meer Steam, de Epic Games Store, GOG, Ubisoft Connect en Amazon Games. Gebruikers kunnen zowel games met native ondersteuning voor Linux als Windows-games met behulp van Proton of Wine eenvoudig installeren.

Nvidia gaat zijn CUDA-softwareplatform integreren in de processorarchitectuur RISC-V. Daardoor kunnen RISC-V-cpu's CUDA-systemen aansturen, net zoals onder andere x86- en Arm-processors momenteel al kunnen.

RISC-V krijgt native CUDA-ondersteuning. Dat heeft Nvidia bekendgemaakt op het evenement RISC-V Summit China. Met deze ondersteuning kunnen cpu's die gebruikmaken van de RISC-V-architectuur dienen als hoofdprocessor in systemen met Nvidia-gpu's, bijvoorbeeld in datacenters. De processor moet dan onder meer de CUDA-drivers aansturen.

RISC-V is een opensource alternatief voor instruction set architectures als x86 en Arm. Daardoor hoeven klanten geen dure licentie af te nemen en zijn ze niet voor de langere termijn afhankelijk van een extern bedrijf. Nvidia gebruikt momenteel al tussen de tien en veertig custom cores voor zijn gpu's die gebaseerd zijn op de RISC-V-architectuur, maakte het bedrijf afgelopen oktober bekend.

De Japanse chipfabrikant Rapidus heeft de eerste prototypewafers geproduceerd op zijn 2nm-procedé. Het bedrijf maakt nog niet bekend wat de yields precies zijn. Rapidus werd eind 2022 opgericht en wil in 2027 beginnen met de massaproductie van 2nm-chips.

Rapidus toonde de voltooide 2nm-testwafer onlangs tijdens een persconferentie. Het bedrijf zegt dat de eerste testchips momenteel worden getest op hun elektrische eigenschappen. Op basis van die resultaten kan Rapidus inschatten wat de yields zijn, oftewel het percentage werkende chips aan het einde van het productieproces. Het bedrijf deelt vooralsnog geen verwachtingen over de yields.

De prototypewafers worden geproduceerd in de IIM-1-fabriek van Rapidus, waarvan de bouw in september 2023 begon op het Japanse eiland Hokkaido. In 2024 werd de cleanroom voltooid en in april begon de pilotproductie in de fabriek. Het bedrijf heeft naar eigen zeggen meer dan 200 chipproductiemachines geïnstalleerd, waaronder euv-machines van ASML.

De fabrikant zegt zich te onderscheiden van andere chipfabrikanten, doordat het zijn volledige productieproces baseert op single-wafer processing. Dat betekent dat iedere wafer die door de fabriek rolt, individueel wordt verwerkt en behandeld. Dat zorgt voor langzamere productietijden en hogere kosten dan batch processing, waarbij meerdere wafers tegelijkertijd worden verwerkt.

Tegelijkertijd zorgt deze aanpak volgens het bedrijf voor meer precisie tijdens het productieproces. Ook moeten verbeteringen aan het procedé sneller gaan, aangezien voor iedere afzonderlijke wafer data wordt verzameld. Die verbeteringen kunnen vervolgens ook voor alle toekomstige wafers worden doorgevoerd. Dat moet ervoor zorgen dat de yields hoger uitvallen en sneller verbeteren.

Rapidus is een van de eerste fabrikanten die volledig overstapt op single-wafer processing voor zijn volledige procedé. Chipfabrikanten gebruiken doorgaans een combinatie van single-wafer en batch processing tijdens de verschillende stappen van hun productieprocessen.

Rapidus werd eind 2022 opgericht door een consortium van Japanse bedrijven en met steun van de Japanse overheid. De chipmaker moet Japan weer op de kaart zetten als fabrikant van geavanceerde chips. Rapidus zou daarmee de vierde geavanceerde foundry worden, naast TSMC, Samsung en Intel.

Het bedrijf heeft een onderzoekssamenwerking met IBM en heeft samen met dat bedrijf zijn eerste 2nm-procedé ontwikkeld. Rapidus heeft daarnaast een overeenkomst met het Belgische imec. De massaproductie op 2nm moet in 2027 beginnen. Begin volgend jaar brengt het bedrijf al een process development kit uit, waarmee klanten chips kunnen ontwerpen voor productie bij Rapidus.

Het Verenigd Koninkrijk wil Apple naar verluidt niet langer verplichten om een achterdeur in iCloud te bouwen. Britse ambtenaren zeggen tegen The Financial Times dat deze eis mogelijk indruist tegen overeenkomsten die het VK met de VS heeft gesloten.

Anonieme hoge functionarissen van de Britse regering zeggen tegen The Financial Times dat het VK 'waarschijnlijk' niet langer een achterdeur in iCloud gaat vereisen. De Britse overheid zou voor de VS een grens overgaan met die eis, omdat 'ze niet willen dat wij aan hun techbedrijven komen'. Volgens de ambtenaren heeft het VK nog niet officieel besloten om de eis van tafel te vegen, maar ze verwachten naar eigen zeggen dat de regering geen andere keus heeft dan om terug te krabbelen.

Begin dit jaar eiste de Britse regering toegang tot versleutelde inhoud van iCloud-gebruikers. De overheid beriep zich op de Investigatory Powers Act uit 2016. Op basis daarvan zou de overheid eisen dat Apple een algemene achterdeur bouwt in iCloud. Laatstgenoemde heeft zich hier niet over uitgesproken; dat is strafbaar volgens deze wet. Wel heeft Apple kort na deze eis de functie Advanced Data Protection, waarmee de cloudopslag wordt versleuteld, uitgeschakeld in het Verenigd Koninkrijk.

De Amerikaanse regering heeft zich al vaker uitgesproken tegen deze Britse eis. Het land stelt dat het VK hiermee het Cloud-verdrag schendt. Dat is een verdrag dat de VS met meerdere landen heeft afgesloten, waarbij Amerikaanse opsporingsdiensten gegevens kunnen opvragen van Amerikaanse burgers als die in andere landen zijn opgeslagen. Dat geldt ook andersom. Amerika vreest echter dat het VK met de achterdeur in iCloud ook toegang kan krijgen tot versleutelde data van Amerikanen.

Microsoft heeft fixes uitgebracht voor twee actief misbruikte kwetsbaarheden in zijn SharePoint Server. Daardoor kunnen kwaadwillenden schadelijke code uitvoeren op fysieke servers bij organisaties.

Microsoft heeft beveiligingsupdates uitgebracht voor de kritieke zerodaykwetsbaarheden CVE-2025-53770 en CVE-2025-53771 in SharePoint Server 2019 en SharePoint Server Subscription Edition. De problemen zijn ook aanwezig bij SharePoint Server 2016, maar Microsoft werkt nog aan een fix voor die versie. Het bedrijf dringt erop aan dat klanten de patches meteen binnenhalen om het beveiligingslek te kunnen dichten.

Door deze kwetsbaarheden kunnen kwaadwillenden op afstand ongeautoriseerde code uitvoeren op SharePoint Servers, waardoor ze het systeem kunnen overnemen. Deze servers staan fysiek bij organisaties en overheden en worden gebruikt voor het delen en beheren van documenten. De cloudservers die voor SharePoint Online in Microsoft 365 worden gebruikt, zijn volgens het bedrijf niet getroffen.

Onder meer het Nederlands Nationaal Cyber Security Centrum zegt dat de kwetsbaarheid actief misbruikt wordt. Het NCSC stelt dat deze kwetsbaarheid niets te maken heeft met het lek in de Citrix NetScaler-software dat onlangs werd ontdekt. Volgens onderzoekers die Bloomberg heeft gesproken, lopen meer dan 10.000 bedrijven met SharePoint Servers risico. De meeste daarvan bevinden zich in de Verenigde Staten, gevolgd door Nederland. Het Nederlandse beveiligingsbedrijf Eye Security zegt dat er vanaf 18 juli tientallen systemen actief zijn aangevallen.

De aankomende iPad Pro met M5-chip krijgt twee camera's aan de voorzijde. Dat schrijft Mark Gurman van persbureau Bloomberg op basis van gesprekken met ingewijden. Het moet daardoor makkelijker worden om de camera te gebruiken in zowel de verticale als horizontale stand.

De M5-versie van de iPad Pro krijgt een selfiecamera aan de lange zijkant en een aan de korte zijkant, claimt Gurman. De Bloomberg-journalist verwacht dat Apple er hiermee voor wil zorgen dat de frontcamera zowel in de horizontale als verticale stand goed bruikbaar is.

Apple heeft de frontcamera bij het iPad Pro-model uit 2024 verplaatst naar de lange bezel, net zoals het bedrijf eerder al deed bij de instap-iPad uit 2022. Dat zorgt er onder meer voor dat gebruikers bij horizontale videogesprekken beter in beeld komen en dat ze hun vingers niet tegen de lens houden als ze Face ID in de horizontale stand willen gebruiken.

Gurman liet eerder dit jaar al weten dat Apple werkt aan een iPad Pro-model met M5-soc. De tablet zou ergens dit jaar moeten verschijnen. Het moet een van de eerste producten worden met Apples nog onaangekondigde chip. Ook de MacBook Pro en Vision Pro-headset krijgen dit jaar naar verluidt een M5-upgrade.

Debian 13 'Trixie', de eerste versie met ondersteuning voor processorarchitectuur RISC-V, komt binnen drie weken uit. De release is op 9 augustus. Dat is ruim twee jaar na de vorige versie van Debian.

Volgende week start de laatste fase voor de uiteindelijke release: de full freeze, zo blijkt uit de aankondiging op de mailinglijst. De release zat er al aan te komen, want een paar weken geleden kwam Release Candidate 2 uit.

Versie 13 voegt, zoals al jaren verwacht, ondersteuning voor 64bit-processors op RISC-V-architectuur toe, zo blijkt uit de releasenotes. Er is ook een lijst van RISC-V-processors te vinden die Debian ondersteunt, zoals de Allwinner D1, maar ook het vervangende moederbord voor de Framework 13 met RISC-V-processor. De vorige stabiele versie van Debian kwam twee jaar geleden uit.

De ceo van DataOps-bedrijf Astronomer, Andy Byron, heeft zijn functie neergelegd. Dat gebeurt enkele dagen nadat hij op camera verscheen bij een Coldplay-concert, waarbij de beelden de indruk wekten dat hij een affaire heeft met een topvrouw van zijn bedrijf.

Het bestuur van Astronomer heeft het ontslag aanvaard, meldt het bedrijf. "Van onze leiders wordt verwacht dat zij de norm stellen op het gebied van gedrag en verantwoording, en onlangs werd niet aan die norm voldaan." Pete DeJoy neemt de taken van Byron waar, terwijl het bedrijf op zoek gaat naar een nieuwe ceo.

Astronomer bestaat sinds 2015 en Byron is twee jaar lang directeur van het bedrijf geweest. Het bedrijf heeft dit jaar nog een investering gehad, waarbij de waarde van het bedrijf 1,3 miljard dollar zou zijn geweest. Video's van Byron en topvrouw Kristin Cabot gingen afgelopen dagen viraal op sociale media, nadat Byron en Cabot, na het wegduiken bij een kiss cam tijdens een concert van Coldplay, de indruk wekten dat zij een buitenechtelijke affaire hebben. Astronomer heeft een dataplatform dat bedrijven helpt bij het bouwen, uitvoeren en beheren van hun data, aangedreven door de opensourcetechnologie Apache Airflow.