Intel haalt verbod op benchmarks uit voorwaarden Linux-microcode

Intel heeft de voorwaarden van de Linux-microcode voor cpu's aangepast. De nieuwe versie bevat niet langer een verbod op benchmarks en prestatievergelijkingen. Intel heeft geen verklaring gegeven waarom dat verbod erin stond.

Intel-topman Imad Sousou zegt in een tweet dat Intel de voorwaarden van de Linux-microcode versimpeld heeft om verspreiding ervan eenvoudiger te maken. De nieuwe voorwaarden zijn veel korter dan de versie die Intel eerder opstelde, en het verbod op het maken van benchmarks en prestatievergelijkingen is in zijn geheel verdwenen. Intel rept verder niet over die passage, maar zegt 'als actief lid van de opensourcecommunity open te staan voor alle feedback'.

Op het moment van schrijven staan de oude voorwaarden, met verbod op benchmarks en prestatievergelijkingen, nog in het installatiebestand van de Linux-microcode. Intel moet dat bestand vermoedelijk nog bijwerken.

Eerder deze week ontstond er ophef over de voorwaarden, toen opensourcepionier Bruce Perens opmerkte dat Intel een passage had opgenomen met een verbod op benchmarks. De microcode bevat patches tegen kwetsbaarheden zoals Spectre en L1TF en kan de prestaties van processors negatief beïnvloeden. Terwijl de voorwaarden actief waren heeft Intel overigens wel zelf benchmarks getoond en ook andere partijen, zoals Phoronix en Red Hat, hebben dat gedaan.

Er was niet alleen kritiek op de passage over benchmarks; het Debian-team weigerde de microcode te gebruiken in zijn Linux-distributie vanwege de aanwezigheid van de licentie, omdat die passages zou bevatten die de verspreiding ervan bemoeilijkten. De nieuwe, versimpelde voorwaarden zouden dat probleem ook weg moeten nemen.

Reacties (66)

[beany]

Of ze zijn geschrokken van de ophef, of het hoger management is het simpelweg niet eens met de interne juristen die de bewuste passage had toegevoegd.

Ik snap ook niet waarom iemand deze passage had toegevoegd. Je kon er op wachten dat dit een 'dingetje' ging worden. Je loopt er meer imagoschade mee op dan wanneer er daadwerkelijk benchmarks worden gepubliceerd waaruit blijkt dat de microcode de snelheid negatief beïnvloedt.

[Neko Koneko]

Ik denk dat het de ophef is geweest die ze heeft doen terug krabbelen, maar het was ook gewoon een domme regel. Als je probeert om mensen de mond te snoeren zullen ze alleen maar harder schreeuwen als ze de kans krijgen, en gezien de EULA niet rechtsgeldig is in een groot deel van de wereld zullen die benchmarks toch wel komen, desnoods online gezet vanuit Rusland of een ander land waar die EULA niets voorsteld. Alleen nu met gratis extra aandacht en veel meer mensen gaan nu nieuwschierig zijn naar die benchmarks dan voordat ze deze domme regel in de EULA hadden opgenomen

[.oisyn]

en gezien de EULA niet rechtsgeldig is in een groot deel van de wereld

Kun je dat toelichten? Ik zie niet in hoe het in Europa bijvoorbeeld niet rechtsgeldig is.

[Jerie]

Het gaat in tegen het GPL. Je mag niet verdere restricties leggen bovenop het GPL. Dat is ook waar de zaak van Bradley Spengler vs Bruce Perens over gaat.

[GeniusDex]

Intel verspreid hun microcode niet onder de GPL, en ik neem hierbij aan dat er ook geen GPL-software inzit waardoor Intel hiertoe verplicht zou zijn. Ze staan gewoon vrij om hun eigen licentie te kiezen. Het is dus niet relevant dat het ingaat tegen de GPL.

[RoadRunner84]

Intel is ook niet verplicht, maar je zou kunnen stellen dat de GPL verbied om Linux op deze platformen uit te rollen.

[dmantione]

Er staat wel een uitzondering in de GPL wat betreft systeembibliotheken. Een GPL-applicatie onder Windows die van systeem-DLL gebruikt maakt is in strijd met deze hoofdregel, maar de uitzondering maakt het toch mogelijk. Je zou kunnen stellen dat microcode ook onder deze uitzondering kan vallen.

[MSalters]

Ik denk dat je echt niet begrijpt hoe de GPL werkt. Of Open Source software licenties in het algemeen. Als auteur ben je zlef niet gebonden aan de regels van de GPL. Je kunt bovendien ook software uitbrengen onder "GPL behalve X,Y,Z". Linux maakt bijvoorbeeld expliciet duidelijk dat Linux applicaties niet automatisch GPL zijn.

[dtech]

Dat intel een GPL-incompatibele licentie op de microcode plaatst is juist het probleem voor de Linux distributies, daardoor kunnen zij de beveiligings-update niet op de standaard manier naar gebruikers verspreiden.

[GeniusDex]

Dat is een enigszins ongenuanceerde manier om het probleem te benoemen. Sowieso mag elke Linux-distro zelf kiezen hoe ze updates verspreiden, en is er geen overkoepelende reden waarom verspreiding verhinderd wordt met de licentie van Intel.

Specifiek voor Debian was de oude licentie wel een probleem, en ik denk dat je daar op doelt. Debian hanteert hun eigen set aan richtlijnen om te bepalen wat zij 'vrije software' noemen. Alleen software met een licentie die hieraan voldoet nemen zij op in hun standaard repository. De GPL is een van de licenties die hieraan voldoet, maar er zijn er meer, zoals de BSD- en Apache-licenties. De licentie waaronder Intel deze update in eerste instantie verspreidde voldeed niet aan deze richtlijn, en daarom kon Debian de update volgens hun eigen regels niet zomaar verspreiden.

Van andere distributies dan Debian weet ik niet in zoveel detail hoe ze omgaan met licenties van software die ze verspreiden.

[dmantione]

De koppeling met GPL snijdt inderdaad geen hout. Wel is het zo dat Linuxdistributies eisen hebben aan licenties die de software die zij meeleveren mag hebben. Verenigbaarheid met de GPL is voor sommige soorten software zeker een criterium. Als je als Intel microcode uitbrengt met een licentie die in strijd is met de eisen die distributies stellen, dan is het nettoresultaat dat het gros van de Linuxgebruikers niet zullen gebruiken en bereik je dus je doel als fabrikant niet.

[Jerie]

My bad ik haal er twee door elkaar. Wat ik schreef was van toepassing op de zaak tussen Spengler en Perens.

Wat hier het geval was, was dat Debian het niet toevoegde omdat het in gaat tegen DFSG. Hoe het bij andere distributies zit weet ik niet.

Zie ook deze ludieke reactie 'Dear Ad Networks'.

[Guru Evi]

Een deel van de Intel microcode (management engine) is ook op MINIX gebaseerd

[GeniusDex]

Ik heb het even opgezocht en MINIX hanteert een BSD-achtige licentie. Het is dan dus gewoon toegestaan om bij verdere verspreiding strictere voorwaarden te stellen.

[Wootles]

Dat een eula per definitie niet rechtsgeldig is lijkt een beetje voorbarig, maar het is een feit dat de rechtsgeldigheid op z’n minst flink betwist kan worden.

Als ik mijn bron juist interpreteer is de eula (in ieder geval in Nederland) sowieso niet geldig wanneer deze pas getoond wordt na aankoop van het product. De consument kan dan immers niet meer beslissen om niet akkoord te gaan zonder het product te moeten retourneren.

Daarnaast is een eula ondergeschikt aan de bestaande wet- en regelgeving. Dus je kan nooit akkoord gaan met minder rechten dan dat je dat je als consument als heb gekregen van de overheid. Met dat laatste zou het verbod op benchmarken uit het bovenstaande nieuwsbericht waarschijnlijk flink wringen.

Bron: https://www.security.nl/p...orwaarden+rechtsgeldig%3F

[Neko Koneko]

Dat een EULA ondergeschikt is aan bestaande wet- en regelgeving is eigenlijk wat ik bedoelde, maar daarnaast zullen er genoeg landen zijn waar een EULA van een Amerikaans bedrijf gewoon letterlijk nietszeggend is, dus je zou je benchmarks gewoon vanuit die landen kunnen uitvoeren/publiceren en dan heeft Intel gewoon pech. Daarnaast kan een dergelijke clausule in de EULA ook aangevochten worden, ik kan me goed voorstellen dat hij in de VS bijvoorbeeld in strijd kan zijn met het recht op de vrijheid van meningsuiting (dat argument wordt daar al voor veel dommere dingen succesvol gebruikt).

[dmantione]

Hij is ondergeschikt aan wet- en regelgeving, maar ook aan andere contracten. De koop van een product is ook een contract en de EULA kan (vaak) gezien worden als algemene voorwaarden bij een koopcontract. Je komt dan op de juridische materie rond kernbedingen: Wat in algemene voorwaarden staat is te allen tijde ondergeschikt aan kernbedingen in een contract. Zeker als de koopovereenkomst geen melding maakt van algemene voorwaarden/EULA (eerder regel dan uitzondering), dan ziet het er vaak slecht uit voor wat in de EULA staat. Maar ook al maakt de koopovereenkomst er wel melding van: Als in de EULA bijvoorbeeld staat dat de software gelicenseerd is en niet verkocht, dan is dat toch echt pure onzin: Een koopovereenkomst betekent per definitie dat iets van eigenaar wissel. Je bent dus eigenaar van het exemplaar van het produkt dat je gekocht hebt en verkrijgt daar mee alle rechten die met eigendom gepaard gaan.

[.oisyn]

Maar bij linuxdistributies gaat het doorgaans nou juist niet over aankopen . Een EULA bij vrij downloadbare software voor download óf voor installatie is gewoon prima volgens Nederlandse maatstaven (en ik gok in de rest van Europa). Dit uiteraard even los van de specifieke punten die in de EULA staan.

[MSalters]

De koop van een product is ook een contract en de EULA kan (vaak) gezien worden als algemene voorwaarden bij een koopcontract. ...Zeker als de koopovereenkomst geen melding maakt van algemene voorwaarden/EULA, dan ziet het er vaak slecht uit voor wat in de EULA staat.

Understatement, dat. Algemene Voorwaarden moeten vooraf gemeld worden. Niet gemeld, niet geldig.

[.oisyn]

Als ik mijn bron juist interpreteer is de eula (in ieder geval in Nederland) sowieso niet geldig wanneer deze pas getoond wordt na aankoop van het product.

Echter koop je de meeste van deze OS'en niet, die zijn gewoon vrij downloadbaar. Je punt gaat dus niet op (en dat is iets waar ik al aan had gedacht voor ik mijn reactie typte )

[Anoniem: 420148]

Een EULA met een verbod om een product te testen en je bevindingen te publiceren? Succes met de rechter vinden die dat rechtsgeldig verklaard.

[.oisyn]

Ik vroeg dus om een toelichting. Gewoon stellen dat het zo is is geen toelichting. Maar bedankt voor je poging to bijdrage.

[MSalters]

Succes met de rechter vinden die (zo'n EULA) rechtsgeldig verklaard.

Dat heeft vooral te maken met het feit dat rechters dat niet doen. He is simpelweg hun baan niet, en nee, er is ook niemand anders die dat wél doet.

Fundamenteel is de aanname dat een gesloten contract rechtsgeldig is. Er zijn omstandigheden waarin de houdbaarheid van het contract in het geding is, maar zelfs dan nog zie ik geen scenario waarin één van de contractanten ooit een rechter zou verzoeken om het rechtsgeldig te verklaren. De correcte weg is dat je eist dat de tegenpartij het contract nakomt, en zoniet, dan sleep je'm voor de rechter om hem aan het contract te houden. Als eiser moet je dan het meeste bewijzen, maar a priori niet dat het contract rechtsgeldig is.

[dmantione]

Een EULA is op zichzelf niet illegaal, maar kan in strijd zijn met andere rechten, relevant zijn hier consumentenrechten. Je hebt een processor gekocht en daarmee recht op de geadverteerde eigenschappen. Als er een defect in die processor zit, heb je recht op reparatie. Het is niet redelijk dat je allerlei beperkingen moet accepteren om die reparatie te krijgen.

Veel EULA's falen niet omdat een EULA op zichzelf een onredelijke overeenkomst is, maar omdat er vaak dingen in staan die in strijd zijn met andere rechten of de EULA dingen probeert af te dwingen die niet met een éénzijdig vodje papier afdwingbaar zijn.

[jqv]

1 heel makkelijk voorbeeld:
In veel staten in de VS mag je met een wapen over straat lopen. Dit is wettelijk bepaald. Dat mag in ons land niet.

Dus als je een EULA maakt op basis van de amerikaanse wetgeving, dan zullen er regels zijn in ons land/europa die anders zijn. Dat kan ervoor zorgen dat een deel of de hele EULA ongeldig is in ons land.

[.oisyn]

Ik heb het niet over willekeurige EULA's, ik heb het over deze specifieke EULA van intel.

[coen254]

Ik denk dat er meer gedoeld word op testen in een niet westers land (of doen alsof je daar test) en de resultaten verder gewoon verspreiden. Geen reden dat dat verspreiden niet zou mogen, lijkt me.

[Durandal]

Kun je dat toelichten? Ik zie niet in hoe het in Europa bijvoorbeeld niet rechtsgeldig is.

Heb je die EULA in mogen zien en aantoonbaar geaccepteerd voordat je de processor kocht?
Zo nee, dan ben je er niet aan gebonden en heb je gewoon een ding gekocht dat nu je eigendom is en mag je er alles mee doen.

[memphis]

Ik denk dat juridisch het niet eens te houden is. Mensen willen kunnen vergelijken en dat is een consumentenrecht lijkt mij.

[Jerie]

Als je probeert om mensen de mond te snoeren zullen ze alleen maar harder schreeuwen [...]

AKA het Streisand effect

[...] als ze de kans krijgen [...][/quote]

Streisand in dit geval niet eens gebruikt door Phoronix en Red Hat.

[Cerberus_tm]

Inderdaad, ja. Hoe hadden ze ooit kunnen denken dat dit een succes zou worden? Ik ben al een hele tijd aan het twijfelen tussen Intel en AMD voor mijn volgende computer. En ik neig hierdoor nu toch meer naar de R5 2600 dan naar de i5 8400. Ik vraag me alleen af wat voor moederbord, geheugen en ventilator je nodig hebt om de 2600 een klein beetje te kunnen overklokken. En of dat in een micro-ATX-behuizing gaat lukken. Dan betaal je in totaal wat extra (maar hoeveel?) en kun je eventueel ooit nog overklokken.

[doeternietoe]

... en gezien de EULA niet rechtsgeldig is in een groot deel van de wereld zullen die benchmarks toch wel komen ...

Cruciale vraag (naar Nederlands recht tenminste) lijkt me wie op welk moment met deze EULA geconfronteerd wordt. Zijn dat de makers van Linux distro's of eindgebruikers? Ik kan me namelijk niet herinneren dat ik als eindgebruiker ooit bij een (kernel)update akkoord moest gaan met een EULA voor intel microcode... Ook niet bij de installatie van een nieuw systeem trouwens.

Als het de distro-makers zijn (daar lijkt het imo op) maakt dat het verbod gelijk volstrekt onhoudbaar. Hoe moet een distro-maker voorkomen dat eindgebruikers verschillende versies gaan benchmarken?

Als het de eindgebruikers zijn en deze gaan niet expliciet akkoord, heeft het in veel landen geen rechtskracht.

Linksom of rechtsom waarschijnlijk dus niet te handhaven.

[MSalters]

Het antwoord op je eerste vraag is waarschijnlijk een varrassing voor je: beiden.

Distributeurs hoeven niet af te dwingen dat eindgebruikes zich aan de EULA houden, maar ze moeten wel toelaten dat Intel het doet. Zoiets kan via een kettingbeding.

[doeternietoe]

Kettingbeding is de naam van een constructie voor registergoederen (zie ook 6:252 BW). Ik snap wat je bedoelt: een distro-maker gaat er mee akkoord dat hij op zijn beurt de eindgebruikers akkoord zal laten gaan met de voorwaarde dat er geen benchmarks gedraaid zullen worden. Dat zou ik dan eerder kwalificeren als een derdenbeding, maar dat terzijde...

Anyways, hier is de betreffende overeenkomst:
https://paste.ubuntu.com/p/z2F3Cj6R8Q/

En dit is de gewraakte passage:

Unless expressly permitted under the Agreement, You will not, and will not allow any third party to [...] (v) publish or provide any Software benchmark or comparison test results.

"will not allow" zou je ook kunnen lezen als "technisch onmogelijk maken". Hoe dan ook, kan ik me niet herinneren dat ik in > 10 jaar Linux gebruik ooit akkoord ben gegaan met een specifieke intel EULA voor microcode...

[Reactie gewijzigd door doeternietoe op 26 juli 2024 10:32]

[MSalters]

Ik geef direct toe dat ze voor registergoederen gangbaarder zijn, maar het kettingbeding is niet daartoe beperkt. Wat BW6 Art 252 regelt is de inschrijving van een kettingbeding in het kadaster; voor niet-registergoederen en andere overeenkomsten (zoals deze EULA) bestaat de inschrijfplicht dus niet.

[nelizmastr]

Of ze zijn geschrokken van de ophef, of het hoger management is het simpelweg niet eens met de interne juristen die de bewuste passage had toegevoegd.

Die passage was toch al niet juridisch houdbaar, dus het bestaan ervan is inderdaad meer imagoschade dan wat anders.

[jpsch]

Of dit idee kwam van het hogere management af en niemand durfde dat tegen te spreken.

[totaalgeenhard]

Managers/juristen wonen op een andere eiland dan techneuten.

[Borromini]

Of ze zijn geschrokken van de ophef, of het hoger management is het simpelweg niet eens met de interne juristen die de bewuste passage had toegevoegd.

Dat soort dingen wordt heus niet toegevoegd zonder akkoord van hogerop.

[ajolla]

Proefballonnetje. Afgekeken van Monsanto. Die hadden acceptatie van dat soort voorwaarden ook aan de verkoop van genetische gemanipuleerde gewassen en zaden verbonden.
Seralini was dus eigenlijk 'illegaal' bezig.

[Fermion]

Heel goed, al was het wel een hele domme zet.

[sugarcube]

Tot nu toe altijd tevreden geweest van de intels (met name i3 / i5) vooral performance/power voor in de laptop.
Volgende laptop wordt waarschijnlijk een Ryzen, hoewel ik (nog) niet kan inschatten hoe vergelijkbaar deze zijn.

Intel zal zich weinig aantrekken van mij, maar amazon, google etc... zullen ook richting amd gaan kijken, en dat zal wel meer impact hebben. (En ja AMD heeft vergelijkbare problemen maar lijkt er iets profesioneler mee om te gaan).

Misschien moet ik ook maar eens navragen bij aws wanneer ze een feature gaan aanbieden zodat ik voor onze servers een instance met specifieke (AMD) cpu kan kiezen...

[Belgar]

Afgezien dat de voorwaarde juridisch moeilijk houdbaar is, denk ik ook niet dat Intel hier veel vrijheid heeft.

Linux is het platform waar de microcode updates MOETEN kunnen plaatsvinden, omdat het overgrote deel van de systemen die echt direct risico lopen door alle speculatie problemen op Linux draaien.

[The Zep Man]

Linux is het platform waar de microcode updates MOETEN kunnen plaatsvinden, omdat het overgrote deel van de systemen die echt direct risico lopen door alle speculatie problemen op Linux draaien.

De microcode updates konden onder Intel's (belachelijke) voorwaarden ook plaatsvinden. Je mocht alleen met die updates geen benchmarkresultaten van de betreffende systemen publiceren.

Wat Linux tricky maakt voor Intel is dat het makkelijk is om specifieke situaties te testen. Onder Linux kan je enkel de microcode update zo in- en uitschakelen. Het enige dat nodig is voor de wissel tussen geen en wel microcode (en andersom) is een reboot. De rest van het systeem blijft hetzelfde.

Bij Windows zit de microcode update in een sliert aan maandelijkse Microsoft updates verwerkt, en is het lastiger om een 'pure' benchmark uit te voeren zonder en met nieuwe microcode. Verschillen kunnen ook toegewezen worden aan andere updates.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 10:32]

[Bezulba]

Aanname: die voorwaarde zat in de testversie die nog lang niet optimaal werkte waardoor benchmarks een vertekend beeld gaven en iemand zat niet op te letten en vergat het eruit te halen bij officiële release.

[TWyk]

Ook zullen ze misschien bezorgd geweest zijn dat er door een performance verschil in gepatchte en ongepachte CPU's mensen zouden stoppen met het patchen van hun CPU's. Dan zouden de lekken bovendien langer in het nieuws kunnen blijven.

[leuk_he]

Er zijn omstandigheden te bedenken dat je niet hoeft te patchen. Bv een dedicated backend database server.

[borft]

tot een userlevel bug in je db software zorgt voor escallatie naar admin rechten. Het ka nwel een bacend server zijn, maar potentieel heeft elk proces toegang tot het volledige geheugen. Als je backend server niet aan een netwerk hangt hebt je natuurlijk gelijk.

[The Zep Man]

tot een userlevel bug in je db software zorgt voor escallatie naar admin rechten.

*tapt voorhoofd* Je hoeft geen rekening te houden met user level kwetsbaarheden die kunnen escaleren naar admin niveau als je alles laat draaien op admin niveau.

Situatie die je vaak genoeg tegenkomt.

[Neko Koneko]

Aanname: die voorwaarde zat in de testversie die nog lang niet optimaal werkte waardoor benchmarks een vertekend beeld gaven en iemand zat niet op te letten en vergat het eruit te halen bij officiële release.

Dan hadden ze dat als zodoende in een disclaimer moeten toevoegen, dat was veel netter geweest (en had waarschijnlijk ook op meer begrip vanuit de community kunnen rekenen).

[jpsch]

Het was te proberen.

[84hannes]

Dat dacht ik eerst ook: kans dat het niemand opvalt en ze er mee weg komen, en anders draaien ze het terug. Maar wat als het niemand was opgevallen, en bijvoorbeeld Tweakers, of zoals gebeurd is, Red Hat de benchmarkresultaten publiceert? Dan kunnen ze een rechtszaak beginnen, en wellicht zelfs winnen, maar dat zou ze pas echt imagoschade hebben opgeleverd: Intel wil niet dat de prestaties van hun processors gemeten worden. Kort door de bocht. Meer reden om naar de concurrentie over te stappen heb je toch niet nodig?

[Borromini]

Dat dacht ik eerst ook: kans dat het niemand opvalt en ze er mee weg komen, en anders draaien ze het terug. Maar wat als het niemand was opgevallen, en bijvoorbeeld Tweakers, of zoals gebeurd is, Red Hat de benchmarkresultaten publiceert? Dan kunnen ze een rechtszaak beginnen, en wellicht zelfs winnen, maar dat zou ze pas echt imagoschade hebben opgeleverd: Intel wil niet dat de prestaties van hun processors gemeten worden.

Weinig kans dat zoiets stand houdt in de rechtbank, net zoals die EULA's warmee je je ziel verkoopt

[qbig1970]

en zelfs die EULA's houden niet stand: Ná het openen van pakket of Ná downloaden van programma of Ná het installeren van programma met zoiets komen.... gaat niet op in NL.
Dat moet altijd(!) vooraf!
Op sommige artikelen staat het in Heul Heul Heul kleine letterjes, dat bij het openen van artikel, gebruiker akkoord gaat met de voorwaarden. (welke voorwaarden, die lees je pas aan het eind)

[jimshatt]

Volgens mij was het probleem van Debian dat in de voorwaarden staat dat deze gelezen en geaccepteerd moeten worden door de gebruiker. Dat maakt automatische installatie ervan lastig. Aan de andere kant zijn voorwaarden die niet van tevoren ter hand gesteld zijn in Nederland in ieder geval niet rechtsgeldig. Dan kun je restricties opleggen wat je wilt, maar als het niet gelezen en geaccepteerd is maakt het geen zak uit.

Je kunt dit oplossen door een downloader als package te hebben die je de voorwaarden toont, de binary downloadt en installeert. Misschien dat er native (dwz apt of dpackage) ook mogelijkheden zijn om een EULA te tonen (binnen dpackage-reconfigure oid).

De package bevind zich al in het non-free gedeelte van Debian, dus dat het geen GPL is maakt niet uit.

[mutley69]

Intel mag weghalen uit die voorwaarden wat ze willen - dit ga ik niet snel vergeten!

[MainframeX]

Die benchmarks hadden we anders ook wel anoniem geplaatst. Wel leuk dat die paarse broeken dachten dat we er wat van zouden aantrekken.

Sukkels.

[Mikoda]

En weer heeft een Amerikaans bedrijf geprobeerd de consument te naaien. Zoals Jpsch al aangaf ze proberen het gewoon en als er teveel gereclameerd word trekken ze het maar in. Kijk ons toch aardig zijn voor de consument.

[Olaf van der Spek]

Zoals Jpsch al aangaf ze proberen het gewoon en als er teveel gereclameerd word trekken ze het maar in.

Het zijn net politici..

[Neko Koneko]

Dit soort zaken zijn ook een van de redenen dat ik, waar mogelijk, graag voor de underdog ga. AMD doet dit soort dingen gewoon niet (ik snap dat dit vooral zal zijn omdat ze niet de positie hebben waar ze ermee weg kunnen komen, en dat ze waarschijnlijk net zo erg zouden zijn als ze in de positie van Intel zaten, maar goed, daar zitten ze niet).

Daarnaast moeten we voorkomen dat dit soort bedrijven die al meerdere malen hun ware aard hebben laten zien ooit een absolute monopolie positie krijgen.

[watercoolertje]

Gezien het natuurlijk om voor/na benchmarks gaat, heeft de onderlinge strijd tussen 2 merken er niks mee van doen. De strijd is tussen dezelfde CPU met andere microcode...

Daarnaast wat Countess zegt, AMD is juist weer terug van weggeweest

[Reactie gewijzigd door watercoolertje op 26 juli 2024 10:32]

[The Zep Man]

Gezien het natuurlijk om voor/na benchmarks gaat, heeft de onderlinge strijd tussen 2 merken er niks mee van doen.

"Microcode update maakt Intel CPU een stuk trager. Prijs/kwaliteitsverhouding is nog schever geworden! Vergelijkbare AMD CPU is nu (nog) beter."

Het is gewoon PR management vanuit Intel. Dit was een proefballonnetje. Werkte niet. Geeft niets, want er is niets verloren. Het is niet alsof Intel noemenswaardige verkopen verliest door de (tijdelijke) microcode voorwaarden.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 10:32]

[Countess]

Jij hebt de 32 core threadripper gemist?

Nee, Hij wint niet elke benchmark, maar jouw bewering dat AMD niet mee doet in de benchmarks is gewoon dikke onzin.

Servers, desktop, hpc, amd doet overal mee in de top.

[Reactie gewijzigd door Countess op 26 juli 2024 10:32]