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.
In dit artikel laten we zien wat de beste reacties op Tweakers waren in de afgelopen periode. Zo willen we andere gebruikers in aanraking brengen met reacties die ze misschien hebben gemist. We willen maandelijks een uitdraai maken van alle +3-reacties. We beginnen nu met de reacties uit juni. We zijn benieuwd wat je van dit artikel vindt. Laat dat weten in de comments − al zullen die niet snel een +3 krijgen!
−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):
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:
In de praktijk:
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:
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.
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%.
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.
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:
It's explicitly free of any "DEI" or similar discriminatory policies.
Together we'll make X great again!
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.
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
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.
os: unexport ClientIsLocal()Not used by any modules, so no need to keep it exported.
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.
davidbepo:Jasper St. Pierre: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.
Peter Hutterer:Michel Dänzer:Peter Hutterer:Daniel Stone:Jasper St. Pierre:De impact van schermtijd op kinderenHoe 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 2https://edition.cnn.com/2...risks-wellness/index.htmlBritse 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 aanbevelingenhttps://bmcpublichealth.b...0.1186/s12889-024-19011-w
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.
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.
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.
Source: Tweakers.net