Dit waren de beste +3-reacties van juni

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.

Wat is dit artikel?

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!

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.

Intel 18A-wafer

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

Kind met smartphone

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.103 = 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.

User Reactie
Werelds 'TSMC vraagt 30.000 dollar per 2nm-wafer, 45.000 dollar per 1,6nm-wafer'
jdh009 'TSMC vraagt 30.000 dollar per 2nm-wafer, 45.000 dollar per 1,6nm-wafer'
The Zep Man Pornhub is in Frankruijk niet bruikbaar uit protest tegen leeftijdsverificatie
Mfpower Pornhub is in Frankrijk niet bruikbaar uit protest tegen leeftijdsverificatie
Prince Zonnepanelen leveren vanaf 2027 bijna niets meer op bij Innova Energie
NEK NCTV mag weer internet monitoren door ingang van nieuwe wet
lenwar Zonnepanelen leveren vanaf 2027 bijna niets meer op bij Innova Energie
P_Tingen Amerikaanse belastingdienst maakt aangiftesoftware opensource
SmokingCrop DIGI Belgium moet van rechter stoppen met bovengrondse aanleg van glasvezel
deadinspace Ontwikkelaar forkt Xorg-displayserver naar Xlibre
Enigmus Sony onthult gameplayelementen Death Stranding 2 in nieuwe trailer
jdh009 Sleep A30-oortjes herkennen snurken en passen maskeergeluid direct aan
Odie Bedrijf kondigt Trump-telefoon en mobiel abonnement aan - update
Mirved Nederlands kabinet wil Europese norm voor socialemediagebruik kinderen
Magic Power Steam zet Proton standaard aan op Linux bij games zonder native ondersteuning
kidde Intel gaat tot twintig procent van zijn personeel in chipfabrieken ontslaan
dipje2 Software-update: Darktable 5.2.0
mloman Microsoft wil securityproducten alleen via drivers kerneltoegang geven
TechSupreme Rechter: Broadcom moet VMware voorlopig ondersteunen voor Rijkswaterstaat

Door Tijs Hofmans

Nieuwscoördinator

21-07-2025 • 15:15

73

Lees meer

Darktable 5.2.0
Darktable 5.2.0 Download van 21 juni 2025

Reacties (72)

Sorteer op:

Weergave:

Leuk artikel, het is af en toe pittig schakelen van 'diep' op onderwerp X en dan 'diep' naar onderwerp Y, maar wel erg aantrekkelijk.


Wat ik zoals anderen mis een heldere opknip om die denkstap van context 1 naar context 2 mentaal-visueel te ondersteunen. De kopjes kennen wel een vet optie, maar kleur helpt hierin wellicht meer. Ook de sectie afstand na een ondersteunend plaatje.


Verder wil ik me bij @Electrowolf aansluiten bij een 10-20 woorden samenvatting van een +3 comment in de 'het vermelden waard' eindlijst.

[Reactie gewijzigd door phizzie op 22 juli 2025 10:39]

Een artikel is in mijn ervaring en verwachting op Tweakers iets nieuwswaardigs of een achtergrond stuk.

Dit is een meta achtergrond stuk, waarbij de schrijver geen functie heeft als schrijver maar als redactie. Er zijn namelijk gelieerde bronnen (lezers die deelnemen aan de discussie op Tweakers) die opinie, onderzoeksresultaten of praktijkinzichten delen.

Toch komen reguliere taken van de samensteller van een stuk keurig aan bod: zoeken, selectie, verificatie, moderatie, (wellicht in de toekomst verdere) reflectie.

In deze is precies op de plek waar je de gegevens hebt gevonden (de reacties) als verzamelaar, ook de plek waar de reflectie plaatsvindt. Juist door jouw comment en de mijne. Daarbovenop heeft @TijsZonderH juist gevraagd om terugkoppeling; de reflectie.

Meer Meta of puurder kun je het niet krijgen, Tweakers gerelateerde inhoud voor Tweakers door Tweakers. Je hoeft deze stukken niet te lezen als het type je niet aanstaat.
Omdat er veel gemodereerd wordt op opinie, vind ik dit artikel een dubbel gevoel afgeven. Ik weet daarom niet of ik dit moet toejuichen of juist kritischer moet zijn.

Daarnaast kunnen er ook +2’s en zelfs +1’s zijn die minstens relevant kunnen zijn maar niet zo zijn aangemerkt. Dit versterkt het dubbel gevoel.

Maar ik moet natuurlijk wel waardering afgeven dat jullie het proberen.
Het is naar mijn idee best nuttig om waardevolle informatie die mensen misschien gemist hebben of relevant is voor terugkerende onderwerpen te vermelden zodat het misschien bijdraagt aan het vergroten van het algemene kennisniveau. Zodat misschien niet steeds dezelfde vragen gesteld of beantwoord hoeven worden.

Kritisch kun je natuurlijk altijd in meer of mindere mate zijn. Zo kun je het onderscheid maken tussen feitelijke informatie en een mooi verwoorde mening en voor jezelf bepalen of iets een +1, 2 of 3 waard is. Mensen lezen over het algemeen ook niet alle artikelen of reacties op basis van je interesses en kennisniveau.
Daarnaast kunnen er ook +2’s en zelfs +1’s zijn die minstens relevant kunnen zijn maar niet zo zijn aangemerkt.
Reacties op een artikel van gisteren worden veelal niet eens meer gelezen of gewaardeerd en blijven op nul. En bij de 'controversiële' onderwerpen blijkt iedere keer dat we niet allemaal nuchter en objectief iets van meerdere kanten kunnen bekijken en kan een enkel woord of naam genoeg zijn om vele -1=tjes te scoren.

Over het algemeen is het vermelden van goede, opmerkelijke reacties wel nuttig maar is het op deze manier net zo beperkt en gebrekkig als het systeem zelf.
Dit was ook mijn eerste gevoel bij dit artikel.

Er bestaat een topic op het forum waar al veel gedebatteerd is over de moderatie (en de tekortkomingen ervan): Toename van ongemodereerde posts - Frontpagemoderatie - GoT.

Het punt dat jij aanhaalt, namelijk dat er veel gemodereerd wordt op opinie, is een veelvoorkomend bezwaar in dat topic. Er werden vele suggesties gedaan ter verbetering, maar het is blijkbaar niet echt een prioriteit.

Wetende dat het systeem verschillende gebreken heeft, begrijp ik dan ook niet waarom hierover eigenlijk een artikel wordt geschreven.
maar het is blijkbaar niet echt een prioriteit
Het is geen prioriteit omdat het (goed) aanpakken ervan erg lastig is, Het kan feitelijk alleen door streng te modereren, wat dus tijd en geld kost, maar zal ook problemen opleveren omdat moderatie uit naam van de website zelf altijd zal handelen met bepaalde richtlijnen. Iets dat nu nog beperkt blijft tot 'een vriendelijker Tweakers' (wat al voor interpretatie vatbaar is) zou potentieel uit kunnen groeien tot keiharde censuur op basis van een woordenlijst of specifieke meningen die door 'iemand' als niet acceptabel worden gezien.

De vraag is ook waarom. Meningen zijn er altijd, maar de gevallen waarin en de hoeveelheid waarop die verstorend zouden werken voor waar het moderatiesysteem voor bedoeld is is erg laag. En puur bedrijfsmatig gezien levert het aanpakken van 'meningmodden' niets op. Het genoemde forumtopic ging echter voornamelijk over het gegeven dat veel reacties ongemodereerd blijven, dus buiten het systeem vallen, wat feitelijk afdoet aan de toegevoegde waarde van het systeem.
AuteurTijsZonderH Nieuwscoördinator 21 juli 2025 14:55
Ik ben heel benieuwd naar hoe jullie dit artikel ervaren en wat we de volgende keer eventueel anders zouden kunnen doen. Let me know
edit:
Ik ben aan het kijken naar de wraps, dat zou moeten werken maar het werkt niet en ik snap niet zo goed waarom...

edit 2: weergave met wat css-magic aangepast, zou nu mobiel beter moeten werken.

[Reactie gewijzigd door TijsZonderH op 21 juli 2025 16:12]

Ik vind het een beetje moeilijk lezen. Ik kan slecht benoemen waarom dat zou zijn, maar ik ervaar het als een lap tekst waar ik niet doorheen kom.
Suggestie: Een duidelijkere scheiding tussen onderdelen van deze pagina.
Suggestie: I.p.v. een vloedgolf aan tekst, misschien een "preview" van het comment met een directe link naar de reactie voor als je verder wilt lezen. Dit zou juist weer ruimte kunnen bieden voor wat meer picks. Dus niet 3 hele grote, maar 5 kleintjes (bijv). Gelijk als bonus is t behapbaarder op mobiel.

Ik lees zelf graag de +3 reacties, maar ik lees zo goed als altijd ook de reactie erboven (en het artikel) voor wat meer context, dat heb ik hier minder.
De styling die je gebruikt voor de quote voelt niet als een quote. Ik kan niet benoemen wat het wel is, maar het voelt niet als een quote.
Suggestie: Als het lukt: De styling alsof het een 'echte' reply is, dus incl avatar en +3 score etc.

[Reactie gewijzigd door Martijn.C.V op 21 juli 2025 15:27]

AuteurTijsZonderH Nieuwscoördinator @Martijn.C.V21 juli 2025 16:09
We twijfelden hier intern nog over de vraag of we een deel van de reactie moesten plaatsen en dan een link naar de rest, maar ik vond dat persoonlijk afbreuk doen aan hoe volledig en inhoudelijk een comment kan zijn, en je wil wmb juist dat hele plaatje laten zien. Vandaar dat ik het nu zo integraal heb gedaan.

Misschien is het met de opmaak van nu iets duidelijker?
Duidelijker? Ja. Voldoende? Hm.

Ik zou hier mee kunnen leven hoor, het is een aardige tegemoetkoming van mn suggesties, maar ik geloof dat ik team "preview van reactie" blijf :) Het voordeel van een preview is dat je dus ietsjes meer reacties zou kunnen uitlichten. Ik weet niet of er veel is om uit te kiezen, maar het zou een voordeel kunnen bieden.

Bijv. de eerste reactie in je artikel: Het zegt me weinig zonder context. Als ik wil weten wat er aan de hand is, ga ik sowieso door naar de reactie en lees ik niet dit artikel verder.

[Reactie gewijzigd door Martijn.C.V op 21 juli 2025 16:18]

Het is nog steeds een beste wall of text eerlijk gezegd. Een multi page optie zou hier wel welkom zijn.
Een harmonica, of hoe noemen ze dat? Dat je het begin ziet en hem dan kan uit/in-klappen om verder te lezen. Dan is de structuur direct helder en is alle info er. Bovendien kun je er dan wat meer uitlichten en nog even compact vertellen wat er zo krachtig is aan de comment (al is dat wellicht niet duidelijk).
Ik vraag mij af of het moderatiesysteem wel de juiste vertrekbasis is voor dit soort artikel.

Ik begrijp dat je interessante reacties in de kijker wenst te zetten, maar om nu gewoon te filteren op reacties met een +3 score, dat lijkt mij te gemakkelijk. Je mist een hele hoop reacties die misschien net geen +3-score hebben gehaald, of inhoudelijk interessante maar onpopulaire reacties.
Ik zou het juist per pagina indelen met inhoudsopgave, net zoals bij reviews/roundups.
Wat bij Wikipedia zeer handig is bij dergelijke "walls of text" is om links in beeld zo'n fixed inhoudsopgave te hebben. Zo zie je niet alleen waar je bent, maar kan je ook snel skippen naar andere secties.
Eens, niet een copypaste maar een representatie van de eigenlijke comment zou heel erg tof zijn.

Verder een leuk initiatief om positieve aandacht te geven aan comments waar tijd en moeite in is gestoken.
Bij `Andere reacties` een samenvatting van een zin waar de reactie over gaat. Dan kan ik op basis van inhoud beslissen of ik ´m wil lezen of niet.

Verder mooi artikel (y)
AuteurTijsZonderH Nieuwscoördinator @Electrowolf21 juli 2025 16:11
Dat zou misschien wel een goede zijn ja, ga eens kijken of dat een beetje lukt of niet!
Mag je van mij best AI voor gebruiken ;).
AuteurTijsZonderH Nieuwscoördinator @Electrowolf21 juli 2025 16:16
Ik gebruik wel ChatGPT om tabellen te formatteren, specifiek bij deze artikelen over submits: review: In juni kwam 42 procent van ons nieuws van jullie tips

We hebben een GPT gemaakt die automatisch de opmaak doet met linkjes naar de user en linkjes naar de website, dus hoef ik alleen maar de spreadsheet te uploaden die BI aanlevert :)
Mooi!

Bedoelde voor al voor het genereren van een zin die de +3 reactie samen vat.
Qua opmaak zou ik die dan onder of boven de link naar de reactie plaatsen. De links zijn nu namelijk al best wel lang, dus een zin er bij maakt denk ik niet zo veel uit qua vormgeving?
Mooi om deze reacties op een rij te zien!

Tip: In het artikel zijn enkele van de +3 reacties gekozen. Het is me niet duidelijk op basis waarvan de selectie heeft plaatsgevonden. Zou goed zijn om uit te leggen in het artikel.

Tip 2: Je zou zelfs kunnen denken aan een poll om de top x meest gewaardeerde reacties van de maand te bepalen.
AuteurTijsZonderH Nieuwscoördinator @MallePietje21 juli 2025 16:56
Tip: In het artikel zijn enkele van de +3 reacties gekozen. Het is me niet duidelijk op basis waarvan de selectie heeft plaatsgevonden. Zou goed zijn om uit te leggen in het artikel.
Beetje willekeur, en omdat ze het meest uitgebreid zijn van alle +3's. Dus inderdaad wat arbitrair, maar 19 reacties op één pagina was ook niet te doen.

Wat een poll betreft, ik weet niet of dat hier heel veel toevoegt, wat zou de meerwaarde volgens jou zijn?
[...]

Wat een poll betreft, ik weet niet of dat hier heel veel toevoegt, wat zou de meerwaarde volgens jou zijn?
Ik denk getriggerd door de opmerking "Tweakers maken Tweakers". Zou het proces om dit artikel te maken wel complexer maken. De selectie is dan wel simpel uitlegbaar. 😉

Het was trouwens niet mijn bedoeling te suggereren alle +3 reacties integraal in het artikel op te nemen. 🙂 Ik dacht alleen: misschien heb je gekeken naar de reacties met de meeste +3 moderaties, of met de hoogste gemiddelde moderatie of zo. Dat had wel leuk geweest om te benoemen.
Heel leuk! Ik vind de reacties altijd erg waardevol en leuk om te lezen. Maar… op mijn iPhone is dit niet leesbaar :( . De reacties breken niet af in de breedte. Dus ik ben de hele tijd van links naar rechts aan het scrollen. Zou mooi zijn als dat opgelost kan worden!
AuteurTijsZonderH Nieuwscoördinator @LoeiOrdinair21 juli 2025 15:35
Ik ben ernaar aan het kijken!
edit:
Beetje creatief ge-css't met behulp van @DaFeliX, juist nu iets beter leesbaar te zijn!

[Reactie gewijzigd door TijsZonderH op 21 juli 2025 16:09]

Hier een 15 Plus, in landscape past het wel :-)
Formatteer de reacties in het artikel als daadwerkelijke +3 reacties. Dat zou de leesbaarheid ten goede komen denk ik.
AuteurTijsZonderH Nieuwscoördinator @3raser21 juli 2025 16:02
Daar heb ik niet de tools voor ben ik bang, of je moet screenshots gaan plaatsen maar dat is ook niet echt ideaal.
Screenshots is niet handig nee. Dat komt de leesbaarheid zeker niet ten goede. Vooral niet op mobiele devices.
Superleuk, ik had ze allemaal gemist. Echter, het zijn wel erg kleine lettertjes in de grijze blokken. En door de forse lengte van een aantal uitgelichte posts is het hele artikel heel veel langer dan gebruikelijk.

Mijn suggesties: maak het multi-pagina met per pagina een iets langere inleiding over het originele artikel (zodat ik kan scannen of het onderwerp me gaat interesseren) en vraag de tweakers misschien of ze nog een toevoeging hebben op dit latere moment.
AuteurTijsZonderH Nieuwscoördinator @Bundin21 juli 2025 16:20
Mijn suggesties: maak het multi-pagina
De standaardweergave voor achtergrondartikelen is tegenwoordig de singlepage, dus dat zet denk ik weinig zoden aan de dijk voor het gros van de users.
Het zou denk ik al aardig helpen als de multiknop óók bovenaan staat, zodat je niet helemaal naar onderaan het artikel maar bovenaan de comments moet scrollen om naar multi te kunnen switchen. Ik kan me voorstellen dat mensen die niet heel enthousiast zijn voor het onderwerp een lang artikel verlaten nu er geen multiknop meer is.

Overigens zie ik (in Safari op hotspotsnelheid) de multiknop 5 seconden linksbovenaan het artikel verschijnen (articlemeta-div) onder de titel (samen met 3 van de 4 socials-deelknopjes) tot het laden en renderen van de pagina compleet is, dan wordt het verborgen (de titel klapt namelijk uit en duwt het authorblock-div van rechtsboven naar de plek van de multiknop). Als die knop niet wegteleporteert, dan valt het denk ik best te doen.

Je kunt bij Tweakers' breedste layout de knop/de articlemeta-div nog wel zien ontdek ik net, maar bij alle kleinere layouts verschijnt het on load en verdwijnt het binnen enkele tellen. Valt goed te zien, misschien met een tragere verbinding: review: Meer laptop voor je geld dan ooit - Vier budgetmodellen tot 550 euro

[Reactie gewijzigd door Blizz op 22 juli 2025 00:54]

Hoe ik dit ervaar? Voor een stuk is het lezen wat ik al eens gelezen heb :+

Maar ook, het feit dat de formattering van de tekst veranderd ten opzicht van hoe we hem in de reacties zien,
zeker wat betreft quotes,
maakt dat de reacties die jullie posten weer net dat beetje moeilijker te lezen zijn.

En zeker niet als spelbreker bedoelt, maar is het niet een beetje laat om deze oplijsting over vorige maand zo laat in de huidige maand te plaatsen?

Sowieso lijkt het mij een format waarbij het zoeken zal zijn naar de juiste manier om het weer te geven.
AuteurTijsZonderH Nieuwscoördinator @Blokker_199921 juli 2025 18:56
Hardcore tweakers als jij zijn denk ik ook niet meteen de doelgroep van het artikel, het is meer bedoeld voor wie minder actief is en misschien reacties mist.

En dit is een eerste test, als dit bevalt (en dat lijkt wel zo), dan vraag ik deze data op bij de andere maandelijkse datasets die ik begin van iedere maand krijg, zoals het aantal submits. Dan kunnen we hier begin van iedere maand voortaan iets van brouwen :)
Ik weet dat het onderwerp de +3 comments zijn; maar om het beter te plaatsen lijkt het me wel leuke info om wat inzicht te krijgen in de hoeveelheid aan comments er zijn en inzicht in de verdeling en frequentie in de scores.
We zijn hier allen tenslotte tweakers en apprecieren dus cijfers.

Denk aan:
# comments (gemiddeld aantal comments per artikel)
Hoeveel daarvan waren:
  • weggehaald door jullie
  • -1
  • 0
  • +1
  • +2
  • +3
Het verbaasde me oprecht dat een +3 zo uitzonderlijk was.


edit: zorg dat de weergegeven +3 comments inklapbaar zijn (en standaard ingeklapt zijn). Dit bevorderd de leesbaarheid enorm.

[Reactie gewijzigd door Prince op 21 juli 2025 15:31]

Top idee om waardevolle comments en community uit te lichten. 🙂 +1
Leuk concept, uitvoering wordt vast beter. Inderdaad de wraps zijn beetje knudde, iig op mobiel, scheelt dat je hebt gelinkt naar de comments, dat ik ze daar alsnog kan lezen.


Ben benieuwd of je op termijn wellicht ook weer zoiets als beste reviews van de maand, reviews met de meest views, reviews met de meeste interactie in een maand etc krijgt. Zoiets lijkt mij, als vaste reviewer op Tweakers, dan wel weer een leuke.
Iets met marge / padding en max-width of zo, maar de reacties gebruiken niet de hele breedte , en dat maakt het onprettig lezen. Daarmee lijken de al erg grote reacties nog langer.


Kunnen die mensen niet wat meer to the point schrijven of zo...

.... Hey, ik sta er in 😁.
Mooi initiatief @TijsZonderH.

Puntje van aandacht: leesbaarheid, dit is knap moeilijk te lezen. Het voelt als Windows Notepad zonder word-wrap!

Nu maar hopen dat deze tegel geen +3 voor volgende maand wordt 🤪.
AuteurTijsZonderH Nieuwscoördinator @flipjevandejam21 juli 2025 16:57
Dit is inmiddels dus opgelost maar fijn dat je het verder waardeert!
Alleen op mobiel is het leesvenster juist weer heel snel. Althans bij mij (Firefox Android).

Verder erg leuk initiatief! Zeker mee door blijven gaan.
Ik lees liever echt nieuws. Heb hier helemaal niks mee. Prima dat anderen het leuk vinden en waarderen.

Wellicht dat met een filter optie artikelen als dit weg gefilterd kunnen worden voor wie dat wil? Bijv. net als de X-aantal artikelen zijn ingestuurd door de community, voor mij vallen die in dezelfde categorie.
AuteurTijsZonderH Nieuwscoördinator @Leaplasher21 juli 2025 16:58
Dat filter is doorgaans 'als je niet klikt, lees je ze ook niet' ;)
Dat ben ik niet met je eens.

In de PW kun je ook filteren op zaken die je wel/niet wil zien in je overzicht. Dan zie is je overzicht van wat je wel wil zien, helder en niet verstoort met allerlei zaken die er niet toe doen.

Wel MSI, geen Asus, etc.
Hoewel ik zelf dit soort artikelen wel waardeer, begrijp ik de wens van @Leaplasher wel om het te kunnen wegfilteren als je er echt niet in geïnteresseerd bent. Een makkelijke manier zou denk ik zijn om dit in het vervolg als .Plan te posten, daar is immers wel een dergelijk filter voor via https://tweakers.net/nieuws/zoeken/

Verder ben ik het met de anderen eens dat dat artikel wel makkelijker te lezen zou zijn als de gekopieerde +3 reacties er op de een of andere manier meer als zodanig (in een groen kader of zo) uit zouden zien.
Het zou ook leuk zijn om dit uit te ontwikkelen in een soort "community highlights" pagina, eentje die de top comments van de dag/week/maand (rolling window) toont.
AuteurTijsZonderH Nieuwscoördinator @YopY21 juli 2025 16:19
Ja in een perfecte wereld... Punt is dat dat heel veel ontwikkeltijd kost. Dit niet, dit wordt nu een invuloefening die ik maandelijks relatief snel in elkaar kan zetten.
Mooi artikel, complimenten. Toch mooi om te zien dat er best wat +3 reacties zijn.
AuteurTijsZonderH Nieuwscoördinator @Meg21 juli 2025 17:00
Fijn om te zien dat je het waardeert :) Ik weet niet of het er veel of weinig zijn, zeker als je het gaat vergelijken met 'vroeger' (whatever that means), maar het waren er iig genoeg dat we problemen kregen met selectiekeuzes en opmaak dus dat zal een goed teken zijn!
Leuk idee, maar de context van de reactie ontbreekt wel een beetje. Het zijn nu vooral hele lappen tekst zonder goed te weten waar er op gereageerd wordt. Ja je kunt weer doorklikken naar het originele artikel en die eerst lezen, maar dat doet dit bericht dan weer wat tekort.
AuteurTijsZonderH Nieuwscoördinator @dutchgio21 juli 2025 17:13
Heb je een idee hoe dat opgelost kan worden?
Fijn dat op deze manier berichten (en de tweakers erachter) in het zonnetje gezet worden. Zo laat je merken dat echte inzet loont!
Nou ja, loont met internetpuntjes. Waar je niet zo veel aan hebt. Waar je die verdieping gratuit beschikbaar stelt aan een commerciële partij. Voor die puntjes niet toch? Ik zou zeggen voor de interactie met andere gebruikers.
Ik was aan het denken: wat maakt een reactie goed. De +3 comments lijken langere reacties met een duidelijke aanvulling. Heb niet alle gelinkte reacties bekeken maar misschien is dit dus (onbewust) de verwachting om een hoge waardering te krijgen. Een beknopte reactie die iets aanvult is dan maximaal +2 bijvoorbeeld.

Op dit item kan niet meer gereageerd worden.