Citat:
Ursprungligen postat av
BeneathTheSurface
Det går ju alltid skylla på någon annan, när man inte har ett fungerande system, liksom varför designar man ens en instruktion som inte ger förväntat resultat? De hade lätt kunnat designa så instruktionen aldrig returnerade innan den var färdig, det här är bara en idiotursäkt.
Hmm, alltså en helt normal nybakad programmerare kommer att konsultera manualen för en bra slumpgenerator. Okej han hittar RDSEED, och kör med den.
Men denna nya programmerare har knappast tiden eller engagemanget för att avgöra om denna RDSEED har de avsedda egenskaperna. Det kan krävas flera timmars testning innan hann kommer på att RDSEED ibland lämnar ifrån sig nollor när den inte ska det.
Den normale programmeraren anser att det är experternas områden att hålla på med sådant.
Han själv får ju inte timpenning för att köra testningen.
Missen finns i själva verket i en av de första utgåvorna i manualtexten. Där författaren nämner ( i förbifarten ) att CF flaggan ( Carry Flag ) ska och måste ovillkorligt kollas att den är satt på ett, 1. CF ställs tillbaka till 0 när ett slumptal har hämtats och lästs in. Står den kvar på 0, så säger definitionen den att antingen fås det gamla värdet tillbaks en gång till, eller det blir noll istället som slumpvärde.
Den vanligen programmeraren fattar alltså inte denna kryptiska inledningstext om CF, att den är
synnerligen viktig.
Metoden med CF flaggan, eller liknande flaggor finns också hos en den data-kontrollerkort, tex sådana som är kopplade till fysiska mätinstrument och liknande. Tänk dig ett ljudkort.
Då kan CF flaggan stå på ett, 1 och det betyder att det finns en ny sträng bitar av en ljudstream att hämta i bufferten. Skulle CF stå på noll så får du vänta tills det finns något nytt läsbart i bufferten.
Nu brukar man inte hålla på med sådant finlir utan man använder streamoperatorna ändå bara rakt av.
Via tex errno så kan man ta reda om det fanns tex en buffer overflow eller liknande.
Errno är en global variabel som brukar finnas i de flesta system.
Men kan inte se att varken exemplet med AMDs microcode patchning eller denna RDSEEDs missade manualtext har kunnat gjort svår skada i verkligheten.
En del slumptalsgeneratorer filtrerar ju gärna bort siffrorna 0 och tex även 0xFFFF FFFF som ogiltiga outouts.
Det finns alltså inga kända exempel på hackare som har dragit nytta av dessa buggar.
AMD är urstarka på CPU och GPU - fronten numera och de nya EPYC-serierna av server-/workstation-rprocessorer är avsedda att konkurrera ut gamla Intel Xeon i rackservrar.
Intel och AMD tillhör två helt olika generationer av CPU-tillverkare. I Intels barndom på 1980-talet gick teknikerna omkring med en räknestickan i skjortfickan.
Medans AMD kunde börja direkt med moderna hjälpmedel. AMD har visst bara 31 000 anställda.
Ändå producerar AMD många riktigt kreativa lösningar. Och snart kommer det förhoppningsvis en 32-kärnig Ryzen med rätt hyggligt pris istället för de med Threadripper priserna.
Medans Intel har över 200 000 anställda, kanske till och med 300 000 om man tar med alla underliggande utvecklingsbolag. Och deras nya teknikgrenar och startups inom koncernen.
Intel har en ohotad ställning som NR 1 alla kategorier. Just på grund av sin mycket stora produktportfölj.
Både Intel och AMD har genomgått den snabba utvecklingen inom teknikområdet som även de japanska, taiwanesiska, thailändska och sydkoreanska företagen har genomgått.
Säkert så finns det ändå de avskydda Anti Thrust-lagarna i USA kvar som en hämsko som ska förhindra amerikanska företag att bli alltför marknadsdominerande.
Dessa lagar sitter säkert i bakhuvudet på alla dessa CEOs i dessa företag.
Faktiskt så säljer Intel fortfarande äldre modeller av nya Xeon server CPUs i stora volymer.
Serverteknikerna byter ju dessa, i med mera RAM, snabba SSDs och servern kan stå och tugga en 5-7 år till ungefär. En ringa kostnad för en uppgradering.
.
Intel kommer att fortfarande dominera datorvärlden för lång tid framöver.
Företaget med flest programmerare och anställda är väl Amazon har jag för mig ?
Över miljonen programmerare.
Intressant dock i samma artikel om att VMs har i vissa lösningar inte tillgång till några äkta entropienheter, i och med att de inte har någon direktaccess till hårdvaran. Det blir en inbyggd svaghet som en testare inte kan se heller, om hen inte är riktigt observant och klurig.
Att man har vid vissa tillfällen kunnat se att ens VMs omsorgsfulla kryptering inte blir så omsorgsfullt utförd.
Tex en applikation byggd för rätt många år sedan fick samma serie av slumptal om den startades inne i en VM, just pga brist på äkta entropi. Eller det var samma entropi-värde hela tiden, typ...
Ingen anledning att vara upprörd - Beträffande kritiken mot AMD och INtel, tänk om vi bara haft ryska eller kinesiska CPUs hur hade det sett ut då ?
Jo hälften av utvecklingspengarna skulle försvinna varje år i kommuunisternas och oligarkernas djupa bottenlösa fickor.
Jag frågade tex en bekant som är datorhandlarei grannstaden här men bara säljer proffsmodeller om hur många returer hanhaft på hårdvarorna. Noll procent på drygt två år.
Det måste man väl ändå ge ett gott betyg till dagens hårdvara ???
Nu är det uteslutande DELL och HP som han säljer i och för sig.
