Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 76 reacties
Submitter: bverstee

Intel heeft de levering van zijn Postville ssd's tijdelijk gestaakt. Winkels zijn gevraagd de ssd's niet te verkopen. De ssd's hebben een bug die ervoor kan zorgen dat alle data corrupt wordt. Een nieuwe firmware-release moet het probleem verhelpen.

Onder andere William George van webwinkel Puget Systems maakt melding van een ernstige bug waarmee Intels X25-M G2 ssd's zouden kampen. Technici van Intel lieten George weten dat de bug opduikt wanneer in het bios van de ssd een wachtwoord wordt uitgeschakeld of veranderd. Het is nog wel mogelijk om zonder gevolgen een wachtwoord op de ssd te zetten, maar zodra dit veranderd of verwijderd wordt, kan alle data op de drive corrupt raken.

Intel heeft besloten de levering van de nieuwe ssd's te staken en ze allemaal van een nieuwe firmware-release te voorzien. De ssd's die al in handen van consumenten zijn, kunnen in principe zonder gevaar voor datacorruptie gebruikt worden, zolang er geen wachtwoord veranderd of uitgeschakeld wordt. Intel zal de firmware-update ook als download beschikbaarstellen. Naar verwachting zal het twee weken duren voordat Intel de levering van de Postville-ssd's weer hervat.

Intel Postville ssd

Moderatie-faq Wijzig weergave

Reacties (76)

Handige bug eigenlijk. Bij normaal gebruik is er dus niets mis, ook als je er een wachtwoord op hebt. Ik weet niet waar het wachtwoord goed voor is, maar als dat ook de schijf beveiligd is het ideaal. Als je je schijf kwijt bent kan iemand het wachtwoord wel wijzigen, maar dan heeft ie niks meer aan de date.

It aint a bug, it's a feature :+
Intel specificeert de X25-M en andere modellen met encryptie, en voor deze encryptie zijn speciale ATA commando's beschikbaar:

(bron: http://www.intel.com/design/flash/nand/mainstream/index.htm)
The Intel X18-M/X25-M SATA SSD supports the Security Mode command set, which consists of:
- SECURITY SET PASSWORD
- SECURITY UNLOCK
- SECURITY ERASE PREPARE
- SECURITY ERASE UNIT
- SECURITY FREEZE LOCK
- SECURITY DISABLE PASSWORD
Vermoedelijk gaat het fout bij 'Security Unlock' en wordt wellicht 'Security Freeze Lock' uitgevoerd ofzo.

Ik denk ook dat dit alleen bij moederborden mogelijk is waarbij je het wachtwoord in de bios kunt instellen; ik ken deze opties in de bios niet.
Een wachtwoord voor het doorstarten van je systeem instellen is iets anders dan encryptie natuurlijk.

Waarschijnlijk zijn er personen die deze ssd's specifiek om de encryptie redenen interessant vinden, misschien wel bedrijven die er veel geld in willen steken.
Daarom is het genoeg reden voor Intel om de verdere uitlevering van de Posville ssd's even in de wacht te zetten.

' Wait Less. Do More' moeten we de komende weken maar even vergeten :)

Lees mee in het Het grote SSD topic ~ Deel 4!
Ik denk niet dat je het wachtwoord kan wijzigen zonder wachtwoord?
Verder gelukkig alleen een firmware probleem.
SSD's hebben ook al een BIOS? LOL.
bijna ieder onderdeel heeft een vorm van "bios'/firmware, zelfs je ramgeheugen en sommige voedingen. ik vraag me af wanneer de eerste overclocktools komen voor SSDs. Verder is dit natuurlijk niet zo schandalig (vind ik). Het is een relatief nieuwe technologie waar iederene met zijn neus bovenop zit en het is een innovatief product. Ik vind het niet zo vreemd dat er wat dingen fout gaan.
Harde schijven ook al hoor ;)
Ik weet niet hoe het precies zit, maar normaal gesproken als je een wachtwoord wil veranderen of verwijderen moet je het wachtwoord dat er op dat moment op staat wel weten. Anders heeft een wachtwoord geen zin: jij hebt iets met een wachtwoord wat ik niet weet, dan verander/verwijder ik hem toch gewoon?

Verder is de bug niet handig, want (als het allemaal goed zit) kun je niet zomaar zonder het wachtwoord te weten deze veranderen/verwijderen, en als je dit doen kun je de data niet meer gebruiken. Zeer onhandig dus.
Wachtwoorden kun je in verreweg de meeste systemen verwijderen door de reset knop / switch / jumper op het moederbord te gebruiken of anders de batterij een tijdje van het moederbord te laten.

De opmerking van GENETX houdt wel degelijk stand: waarom zou iemand een wachtwoord van een SSD regelmatig willen wijzigen? Het lijkt me dat, als je het al gebruikt, je het eenmalig instelt en daarna dat wachtwoord blijft gebruiken.

Als dan iemand jouw systeem steelt en door wil verkopen dan zal hij het wachtwoord willen verwijderen omdat een met wachtwoord beveiligd systeem niet te gebruiken is. Als hij dan het wachtwoord reset is de data corrupt. Hij kan dan het systeem wel gebruiken, maar kan in elk geval niet bij de data. Iets dat bij de meeste bedrijven meer waard is dan het systeem zelf. Helaas is het zo dat er geen garantie op is dat het altijd het geval is, want anders zou je het wel degelijk een feature kunnen noemen.
Dat was vroeger zo, maar tegenwoordig is dat stukken moeilijker geworden.
Probeer het eens zou ik zeggen, bij veel hardware wordt dat wachtwoord namelijk op een apart ic opgeslagen.

Laatst nog een laptop gehad met vergeten bios wachtwoord en toen hielp een bios reset en bios batterij eruit halen en er een hele nacht uit laten ook niets.
Een eeprom vergeet zijn data niet zomaar tegenwoordig.
Of als je geheime informatie erop hebt staan en je wordt gepakt door de overheid/politie/duane/watdanook. Hup, alles weg, laat ze het dan nog maar eens bewijzen :Y)
"One other interesting tidbit is that Intel is not going to be shipping more of these until they have the firmware fix, so there will likely be a shortage of the drives for the next couple weeks (especially depending on how other vendors handle their existing orders). "

Ik zeg nogmaals: prijsverlaging is leuk. Beschikbaar is nog beter...

Destijds had iedereen veel commentaar dat OCZ zijn firmware niet op orde had. Maar nu struikelt de grootste chipfabrikant ter wereld over exact hetzelfde...

Ik zie in elk geval geen reden waarom OCZ nu opeens dramatische prijsverlagingen zou moeten doorvoeren. De concurrentie is immers niet thuis.
Ik zie in elk geval geen reden waarom OCZ nu opeens dramatische prijsverlagingen zou moeten doorvoeren. De concurrentie is immers niet thuis.
SSDs moeten ook nog concurreren met gewone HDs. Het kan best wel eens interessant voor Intels concurrenten zijn om nu d.m.v. prijsverlagingen een groter marktaandeel te pakken.
Concurreert een BMW dan met een Fiat?
Concurreert een BMW dan met een Fiat?
Dus de OCZ is dan een Fiat? Als ik dan toch een auto nodig heb, dan heb ik een auto nodig. Dus een Fiat, want de BMW bestaat alleen op papier

Bovendien is dat een Fiat die een Raptor helemaal wegspeelt. Dus dat is meer een Ferrari - Fiat

[Reactie gewijzigd door ByeSell op 27 juli 2009 17:39]

Beide verkopen auto's dus je zou toch zeggen van wel. Fiat verkoopt goedkopere auto's die voldoen aan de snelheidsregels. BMW moet truucjes gebruiken zoals ik ben stoer, ik verbruik veel maar in vergelijking met..., ik trek 1sec sneller op waardoor je 1sec sneller thuis zou kunnen zijn, ...
Is het wel een bug of is het een ingebakken feature die men nog niet wil gebruiken, of waar men achteraf van besloten heeft het niet als feature te gaan gebruiken maar de code ervoor wel erin heeft laten zitten ?

Lijkt mij namelijk een ideale feature die al die SSD/FLash/USB sticks mogen krijgen. Gestolen en toch proberen ? Data weg en lock dat ding dan gelijk dat het niet meer te gebruken valt, word het voor de diefjes ook weer onaantrekkeleijk :)
Firmware Update Tool laad FreeDos niet eens dus hier werkt het helaas niet.
hmm wel vreemd dit hoor je zou er toch van uitgaan dat alles uitvoerig is getest voordat het de verkoop in gaat.. helaas dat dit moet gebeuren.. was van plan er 1 te halen maar ik wacht nog wel even ;)
je kan nooit ALLES testen in ALLE configuraties.
dat kan mooi wel.. en zou ook moeten gebeuren. Dit soort fouten bewijst maar is dat uitvoerig testen belangrijk is. En alles testen in alle configuraties op een SSD kost dan misschien wel wat tijd. Maar garandeer je wel zekerheid voor de consument.
Ik denk dat Intel wel zijn zaakjes op orde heeft qua testen. Deze bug is zó specifiek en van toepassing op slechts zo'n klein deel van de consumenten (wie hier gebruikt er een BIOS password op zijn HDDs? Hoeveel van jullie veranderen dat password ooit?) dat dit overduidelijk niet op de prio lijst heeft gestaan vóór release. Er is een balans tussen risico, geld en tijd, en érgens houdt het op.

Wil je dat ze ALLES testen in ALLE configuraties voordat ze een product uitgeven, dan hebben we ergens in 2013 een perfecte schijf van 2600 euro. Als ze niets hadden getest hadden we een jaar geleden een onbruikbaar gebugd ding van zes tientjes gehad. Ergens daartussen zit de balans, en zolang ze goede ssupport bieden op het moment dat er iets aan de hand is (zoals ze nu doen) neem ik geen enkel bedrijf iets kwalijk.
Op m'n werklaptop is het verplicht een hdd password te zetten (bedrijfs-policy). Ik heb het idd nog nooit verandert, maar zo raar vind ik de gedachte niet om het af en toe te veranderen.
dat kan mooi wel.. en zou ook moeten gebeuren.
Neen, dat kan niet. Je kan niet testen voor een probleem dat je niet kent. En bovendien is het oneconomisch om extreem lang te testen.

Men heeft het kennelijk getest voor het éénmalig instellen van het paswoord, maar niet meermaals. Goed, dan kan je een test ontwikkelen die daar wel op controleert. Maar wat als er nog een bug in zit die pas voorkomt bij het gebruik van een controller die nog niet eens op de markt is, maar wel zelf perfect correct werkt? Je kan bepaalde scenario's simpelweg niet voorspellen.

Donald Knuth, een beroemde professor computerwetenschappen die veel aan het vakgebied bijgebracht heeft en een uitmuntend programmeur is, looft prijzen uit voor al wie bugs vindt in z'n software. Zelfs jaren na de ontwikkeling en het uitvoerig testen door honderden mensen, vindt men nog steeds (kleine) bugs. Een van zijn beroemde uitspraken is dan ook: "Beware of bugs in the above code; I have only proved it correct, not tried it".

Het is dus duidelijk dat je tot in het oneindige zou moeten testen om echt te garanderen dat iets bugvrij is. Bedrijven zullen dus altijd na een intensieve testperiode beslissen wanneer het risico op significante bugs laag genoeg is om te beginnen met de verkoop. Dat er af en toe toch nog iets foutloopt is onvermijdelijk. Veel software wordt zelfs verkocht met een lijst gekende bugs. Het kost gewoon te veel tijd en geld om die er uit te halen, ten opzichte van hoe ernstig ze eigenlijk zijn.

[Reactie gewijzigd door c0d1f1ed op 27 juli 2009 13:36]

Je kan niet testen voor een probleem dat je niet kent.
dat is onzin want je kunt functionaliteit testen, en als het dan niet werkt conform specificatie heb je een probleem gevonden dat je vooraf niet kende.
Fout. Je gaat ervan uit dat je al specificaties hébt. Dan ben je dus al aan het testen voor een mogelijk probleem dat je anticipeert. De oorzaak van dat probleem is een ander verhaal, maar je test wel actief voor iets dat je reeds kende als mogelijk probleem.

De moeilijkheid van het testen begint dus reeds met het opstellen van de testspecificaties; gebruikscenario's die een specifieke uitkomst dienen te hebben. Het lijkt vanzelfsprekend dat je een paswoord moet kunnen veranderen zonder data te verliezen, maar dat is het niet. Een geautomatiseerde test heeft exacte specificaties nodig en je bent dus enkel en alleen aan het testen of deze voldaan worden. Zo lang niemand op het idee komt om te testen of het veranderen van het paswoord werkt, blijft dat een onbekend idee.

Doodleuk zeggen dat een apparaat correct moet werken, daar heeft een QA team dus niks aan. Dat is geen specificatie. Een specificatie zegt tot in de puntjes wat er moet gebeuren bij bepaalde gebeurtenissen. Zo lang dat dus niet haarfijn op papier staat kan je er niet voor testen en blijft het dus een onbekend probleem.
Onzin, er wordt een functie ontwikkeld die er voor zorgt dat je een wachtwoord op de schijf kunt plaatsen. Deze test je vervolgens, logischerwijs lijkt mij dan dat je test of alles nog functioneert als bedoeld (iedere leek snap zelfs al dat dit nogal kan ingrijpen op de functionaliteit).
Vervolgens wordt er een functie ontwikkeld die er voor zorgt dat je een wachtwoord kunt wijzigen of verwijderen. Deze test je vervolgens zonder te controleren of er uberhaupt nog iets werkt. Dat is meer dan slordig en grenst aan onkunde.
Lezen is een kunst...
"Data *KAN* corrupt raken" , oftewel het wijzigen hoeft niet per definitie te betekenen dat het fout gaat. En dan is dus de vraag "welke condities triggeren deze bug" en dat kan mogelijk veroorzaakt worden door iets wat in unit tests ed niet is voorzien.
Je kunt met testen slechts aantonen dat iets niet werkt, maar je kunt nooit bewijzen dat iets altijd onder alle omstandigheden wel zal werken, simpelweg omdat je niet alle omstandigheden kent of kunt testen (en als dat wel kon, zou het oneindig lang duren).
Dat is natuurlijk makkelijk gezegt....

maar als je iets conform specifikaties maakt wil nog niet zeggen dat het programma ook foutloos werkt. Dit gezien het totaal aantal IT projection in nederland die faalt...

Politie heeft een nieuw systeem... maaaaaaaar we moeten nog even de fouten eruit halen. De belasting diest heeft een nieuw computer systeem.. maaaaaaar we moeten nog wel even de foutjes eruit halen...

Zo gemakkelijk is het niet om goede software te schrijven...

Ries
@HatzaFlatza,

blijbaar heb je geen verstand van software ontwikkeling.

het aantal mogelijk uitkomsten van een programma kan dermate groot zijn dat je hier geen goed test scenario voor kan maken.

Een simple nested if/then statement kan al snel voor 2^x uitkomsten bieden. Een unit test kan wel uitkomst bieden, maar er moet ook een goed balans zijn tussen het aantal unit tests en het aantal functioneel gerschreven code voor commerciele code (van games tot text verwerkers).

Er zijn wel bedrijven die dit process goed onder de knie hebben, maar zelf de software die aan boord van de space shuttle gaat bezit nog programma fouten. En daar toch een flink team op te werken en te testen...

Grt,
Ries
Ik ben een developer. Waarom hoopte je dat ik er geen was?
Ik hoop dat jij geen developer bent..
En jij weet blijkbaar niet waar je het over hebt.

Mission critical code, zo als voor vliegtuigen, militair en olie-raffinaderij/platformen doeleinde kost een factor 10~100x meer dan code voor normaal gebruik.

Dus jij bent berijd om 10~100x meer te betalen voor jouw software ?
Want wat jij wild is code die de zelfde kwaliteit heeft als het besturings systeem van een vliegtuig

Windows heeft ongeveer 2 bugs per 100 regels code, waar van de meeste geen invloed heeft of ondervangen word door fout routines.
Om al die bugs er uit te krijgen heb je veel langere ontwikkelingstijd nodig en dus kosten.

Ik leef wel met die paar bugs als me dat veel geld scheelt.

[Reactie gewijzigd door player-x op 27 juli 2009 14:06]

waarom denk je dat er tegenwoordig alleen maar updates zijn ? als alles goed zou werken zouden er weinig updates moeten uitkomen voor bugfixes..
dat klopt wel maar dit is gewoon het niet afleveren van een degelijk product. Als jij een mobo koopt oid en stel je verandert de bus snelheid dat dan gelijk het hele moederbord niet meer zou werken en blijvend kapot zou zijn.. dan denk je ook dit hadden ze wel moeten testen.. dit is precies het zelfde een wachtwoord change lijkt me nou niet zo'n hele lastige opgaven op te testen ;)

[Reactie gewijzigd door Xenomorphh op 27 juli 2009 12:36]

Dat zou 10/15 jaar terug goed voor hebben kunnen komen.
Dat is gewoon het risico van een nieuw product.
De consument zelf wil het nieuwste van het nieuwste hebben.

Zelfde reden waarom ik heb gewacht met de aanschaf met een nieuwe tv.
iedereen is zo druk ermee bezig, kan je beter wachten op de ontwikkelingen.

En besides, je hoeft er maar een firmware upgrade op te gooie en je hebt er geen last meer van. Dat was vroeger ook wel anders.

Edit:
Het is trouwens ook veel goedkoper om een product uit te brengen en later pas bugfixes uit te brengen, op deze manier ben je de concurrent voor, vergroot je je afzet markt. en stukken goedkoper om naderhand een bugfixje uit te brengen.

Niet dat dat de goeie manier is van markthandel hoor ;)

[Reactie gewijzigd door H0lyGra1l op 27 juli 2009 12:56]

Het is trouwens ook veel goedkoper om een product uit te brengen en later pas bugfixes uit te brengen, op deze manier ben je de concurrent voor, vergroot je je afzet markt. en stukken goedkoper om naderhand een bugfixje uit te brengen.
Dat ligt volledig aan de ernst van de bug. Een ernstige bug kan je reputatie zo veel schade toebrengen, dat je initiële winst die je kreeg omdat je als eerste in de markt stond gelijk verdampt. Dan had je beter beter als 2e in de markt kunnen staan met een beter product.
Ik ben het helemaal eens met Xenomorphh, maar je geeft het zelf aan: mensen willen vooruitgang en dat gaat ten koste van de ontwikkelingsfase van een nieuw product. Zelf ben ik echter van mening dat de consument maar gewoon moet wachten als ik zelf iets op de markt breng, aangezien ik wil dat het in 1x goed is. En niet zoals E.A. games bijvoorbeeld een soort van Betaversie op de markt brengen en vervolgens 10 patches uitbrengen. Microsoft doet dit ook, kijk maar naar Windows XP, Windows Vista, etc. De consument is gewend slechte producten te kopen en daar wordt misbruik van gemaakt door de fabrikanten. En dus ook op hardwaregebied. We zijn allemaal verblind door mooie termen als Megapixels, GHz, gigabytes, terabytes, SSD, enz.
Windows XP RTM was toch helemaal niet buggy?
Windows XP RTM was toch helemaal niet buggy?
Die 3 service packs zijn er niet voor niets geweest ;)

[Reactie gewijzigd door _Thanatos_ op 27 juli 2009 14:28]

Voor SP1 was XP echt te buggy voor woorden. Simpele dingen als de verkenner werkten niet goed en haalden af en toe m'n hele desktop overhoop. Ik ben toen gauw weer terug gegaan naar win2k.
Het feit dat de consument vooruitgang wil mag voor de fabrikant niets af doen aan de degelijkheid van een product.

Dat terzijde is dit mijn inziens echt een major test fout. Je mag verwachten dat in ieder geval alle functionaliteit m.b.t. opslag en datacorruptie worden uitgetest. Alle features en functies die ingrijpen op de storage moeten toch gewoon 100% worden uitgetest (hardware compatibiliteit daargelaten want dit is gewoon een generieke fout).

Als ik de deuren van mijn auto van binnen uit op slot doe en vervolgens weer ontgrendel en m'n auto slaat tijdens het rijden af is dat toch ook belachelijk?
Of de support ontbreekt gewoon....

Ik doe al 4 jaar met mijn iRiver H320 jukebox/mp3 speler. De firmware vervangen door Rockbox die nog steeds (wel erg langzaam) doorontwikkeld wordt en zo kan mijn speler jaren mee en concurreren tegen de iPods e.d.. Hoef je niet te verwachten bij gewone producten die geen fan group hebben waar wat goede gasten tussen zitten. Nee,... dan is het na een paar maanden, tenzij het een goed verkocht product is na een jaar, afgelopen met de doorontwikkeling. Als vista nou gewoon een geperfectioneerde XP zou zijn die nog minder resources gebruikte en beter was, prachtig, maar ja... helaas en zo met veel meer dingen....

[Reactie gewijzigd door Student1563424 op 27 juli 2009 18:37]

Dat kan misschien wel maar kost jaren tijd en vele miljoenen euros, ben jij ook bereid tig jaar te wachten en een veelvoud van de prijs te betalen?
Dit was echter geen nieuw produkt maar een update van het produkt,
men had dus alle tijd om alles te testen en het tijdstip van uitgave te kiezen.

[Reactie gewijzigd door fevenhuis op 27 juli 2009 18:32]

je kan nooit ALLES testen in ALLE configuraties.
dat kan mooi wel..
You must live in a fairy-tale world ;)

Testen is zeer zeker belangrijk, maar het is in de praktijk onmogelijk om alles te coveren: al was het maar dat nieuwe technologieën andere gebruiken mogelijk maken die tijdens het ontwerpen niet te voorzien waren.

Deze bevinding is ook een van de belangrijkste redenen waarom veel zaken in software (firmware is immers software) worden afgehandeld en niet in hardware: software kan je nadien nog updaten terwijl je dat niet (of heel beperkt) kan met hardware.
Datacorruptie door het aanpassen van het wachtwoord. Blijkbaar is er wel getest of het wachtwoord aanpassen werkt, maar niet of de data dan nog leesbaar is.
Na het aanpassen van het wachtwoord is je data corrupt -> formatteren, nieuwe data erop, probleem "opgelost". Het produkt is dus niet blijvend beschadigd, je bent alleen je data kwijt die je sowieso hoort te backuppen.

Ik ben blij dat Intel dit serieus oppakt en winkels adviseert om de voorraad niet te verkopen maar te wachten op een firmware upgrade. Als je ziet hoe Seagate de 7200.11-affaire aangepakt heeft is dit gewoon een stukje goede PR voor Intel. Zelfs nadat Seagate de firmware gefixt had werden er nog gewoon SD15 schijven verkocht, en kreeg je van de RMA zelfs nog schijven met die firmware terug. Dat eerste kan je niet voorkomen, maar dat laatste is gewoon enorm triest.
Dan *kan* dit probleem optreden. Blijkbaar is het dus een kwestie van een specifieke configuratie waarbijn dit fout gaat. Dat is nou juist wat je dus niet kan testen.
Heb je al ooit eens van een product gehoord waar geen fout in zit. Daar waar software in zit is het gemaakt door mensen en dus zitten er fouten in.
Ook hardware is door mensen ontworpen en bevat dus vaak fouten. ;) Soms is het zelfs de taak van de softwaremensen om die fouten op te vangen. Ik denk hierbij bijvoorbeeld aan de R600 chip (Radeon HD 2900). De resolve-hardware voor multisampling bevatte zodanig veel fouten dat ze het nooit op tijd af kregen, en men besloot om via de drivers deze functionaliteit met behulp van shaders te doen. Met als gevolg natuurlijk dat het geheel niet optimaal presteerde.

Ik wil maar zeggen, het is niet altijd de fout van de software-ontwikkelaars. O-)
Maar je kan wel ALLE bedoelde mogelijkheden op EEN pc testen. Dan hadden ze deze bug al gevonden.
Achteraf klinkt het altijd eenvoudig. Maar als ik je vertel dat ze gegarandeerd nog een bug zullen vinden (die al dan niet ernstig genoeg is om te patchen), weet jij dan al op voorhand waar te zoeken?

Natuurlijk niet. Het zoeken naar bugs is dan ook het zoeken naar iets onbekends. Ze hebben wellicht héél veel energie gestoken in het opsporen van problemen rond de betrouwbaarheid en prestaties gedurende alledaags gebruik. Slechts een beperkte hoeveelheid tijd is voorhanden voor het testen van speciale BIOS-functies. Waarschijnlijk is het toch nog serieus getest geweest, maar dat ene ding net wat minder. En dat valt gewoon niet te anticiperen.
En dat valt gewoon niet te anticiperen.
Dit valt dus wel te anticiperen, het is geen ad-random issue die enkel in configuratie x onder omstandigheid y tijdens actie z voorkomt. Het is gewoon een blunder..Natuurlijk bevat software fouten die vervelend of onhandig kunnen zijn, dat het echter de basis van het product namelijk storage omzeep helpt hoort gewoon niet.
Dit valt dus wel te anticiperen.
Nogmaals, achteraf is het altijd eenvoudig.

Je vergeet dat er ook een serieuze tijdsdruk is, en je bent dus verplicht om keuzes te maken wat je uitvoerig gaat testen, en waar je sneller van uit zal moeten gaan dat het corect werkt. Stel dat je team twee weken krijgt om de release candidate van de firmware te testen. Dan spendeer je wellicht negen dagen aan echt cruciale zaken, zoals betrouwbaar lezen, schrijven, herschrijven, verplaatsen, wissen, etc. en dat alles met hoge prestaties. Er blijft dus een dagje over om de minder gebruikte BIOS-functies te testen. Uiteraard ben je niet de eerste die ze ooit uitgeprobeert heeft, maar misschien zijn er nog een paar dingen veranderd in de dagen voor het een release candidate werd. De kans is klein dat er een nieuwe bug in geslopen is, maar als er een inzit is de kans dus reëel dat je het in dat dagje niet vindt. Als je enkel eenmalig het instellen van het paswoord test, of tweemaal maar erna een format doet, heb je het dus niet opgemerkt.

Theorie en praktijk ligt hier dus een eindje uiteen. Hindsight geeft je misschien het idee dat het eenvoudig te voorkomen was, maar als je zelf voor de taak stond had je het hoogstwaarschijnlijk ook niet gevonden.

Dus nee, het valt echt niet te anticiperen. Stel dat iemand er toch aan gedacht had om het opnieuw instellen van het paswoord te testen, dan was er een even grote kans dat elders nog een andere bug zat. In Donald Knuth's software zijn járen later nog bugs gevonden, ondanks zowat de meest gerenommeerde programmeur te zijn.

[Reactie gewijzigd door c0d1f1ed op 27 juli 2009 19:42]

Het is dus wel een at-random issue, dat in een bepaalde configuratie voorkomt als je een bepaalde actie uitvoert. Niet iets dat iedere keer voorkomt als je een bepaalde functie gebruikt.
Een ingenieur met weinig praktijkervaring, who would have figured. Als je software maakt, dan zijn alle geïmplementeerde functies het minimum dat je test. Ik weet goed genoeg dat je onvoorziene bugs niet makkelijk kan vinden en ze meestal pas in het wild opduiken, dit is er dus niet zo een. Het is zelfs niet onder speciale omstandigheden. Je wijzigt wachtwoord en data is weg. 100% te voorkomen, dus iemand mag hier een zware les leren.
Inderdaad.

Zelfs een Pentium 3 1.13GHz kan je niet in alle configuraties testen. :+
Ik vind dit geen goed voorbeeld: misschien kan deze cpu niet veel aan, maar je hoeft niet "alle" configuraties te testen. Je hoeft alleen alle configuraties te testen waarvan jij zegt dat het werkt. Als er bijvoorbeeld staat 'compatible with Windows Vista, hoor je (en zou je eigenlijk ook moeten) testen of het echt met Vista werkt, of het dan werkt met MS DOS boeit dan niet.
Maar wat betekent "compatible met Vista"? Vast iets meer dan dat je Vista succesvol kunt booten met deze processor. En dan, definieer "succesvol", etcetera.

Testen (en het specificeren ervan) is enorm veel werk. Als je een product op de markt wil hebben voordat het achterhaald is, zul je keuzes moeten maken wat je wel en niet gaat testen, want een 100% dekkende test is alleen in theorie mogelijk.
Ik heb onlangs een bug gevonden in de trackpad driver van Apple voor Vista. Deze herstelt de MMX registers niet, waardoor midden in een applicatie plots de registers van waarde kunnen veranderen.

Doorgaans is dit niet kritiek, omdat MMX gebruikt wordt voor het afspelen van multimedia, en een kleine 'glitch' bij muziek of video niet opvalt. Maar bij mijn applicatie werden er geheugenadressen berekend in de MMX registers en dat zorgde dus wél voor een crash.

Mijn punt is dat als je bepaalt dat het "compatibel moet zijn met Vista", dit zéér ruim en weinig specifiek is. Apple noch Microsoft heeft ooit bovenstaande bug verwacht, omdat men er logischerwijze op vertrouwde dat het correct werkte wanneer al hún software correct werkt.

Een volledige dekking geven om te testen op elk mogelijk probleem is dus in de praktijk simpelweg onmogelijk.
Ik ben het niet eens met je conclusie.

De noodzaak om MMX registers veilig te stellen is door Microsoft voldoende onderkend. Jouw applicatie heeft geen probleem als andere applicaties de MMX registers legen. Registers inclusief MMX worden bij elke taskswitch veilig gesteld.

Voor drivers gelden andere regels. Die zijn zelf verantwoordelijk, en niet zo gek: drivers kunnen alles verkloten, inclusief memory. Er is weinig reden voor Microsoft om speciale bescherming voor MMX registers in te bouwen. En Apple had moeten weten dat drivers geen applicaties moeten tackelen.

Ook het "MMX is niet belangrijk" verhaal gaat niet op. Een "division by zero" is geen glitch meer.
Waar zeg ik dat MMX niet belangrijk zou zijn? Het is zeker een zware bug, ondanks dat maar weinigen er ooit last van zullen hebben.

Mijn enige punt is dat simpelweg zeggen dat iets correct moet werken, nog heel ver weg staat van te beschikken over een sluitende specificatie en bijhorende tests. Dat is gewoon praktisch onhaalbaar. En ja, achteraf klinkt het heel logisch dat zoiets als het herstellen van MMX registers moet getest worden, maar zo lang je niet op problemen stuit is het niet vanzelfsprekend om te realizeren dat hier een probleem rond kan ontstaan en dat het getest dient te worden.

Ik denk hierbij bijvoorbeeld ook aan Microsofts WHQL test voor grafische drivers. Het duurt dágen om die allemaal te draaien, en nog zijn artifacts in games schering en inslag. Ondanks de miljoenen tests is de specificatie simpelweg niet compleet sluitend. Het zijn zeer complexe systemen waarbij het aantal mogelijke interacties onmeetbaar groot is en dus kan men enkel zo goed mogelijk pogen om met een beperkt aantal tests zo veel mogelijk scenario's te testen.
Hij doelt er niet op dat deze SSD met deze processor getest zou moeten worden, maar hij doelt op het debacle dat Intel had toen ze deze processor terug moesten roepen omdat Tom's Hardware problemen had ontdekt: http://www.tomshardware.c...ms-pentium-iii-1,235.html en http://windowsitpro.com/a...s-pentium-iii-113ghz.html

[Reactie gewijzigd door Pooh op 27 juli 2009 12:40]

Tuurlijk wel, kost alleen veel geld en tijd.
Hoewel zo'n bug natuurlijk niks met andere hardware te maken heeft maar goed.
Je hoeft niet te wachten, want in principe zou je vanaf nu (cq 2 weken) alleen goede kunnen kopen, en anders flash je hem zelf toch gewoon :)
Wees gerust, een bedrijf wil echt geen terugroepactie moeten organiseren. Dat kost zeer veel geld en bovendien schaadt het hun reputatie.

Maar je kan nu eenmaal niet blijven testen op elk mogelijk scenario. En je kan niet testen op een probleem dat je niet kent. Het lijkt dat dit specifieke probleem zeer eenvoudig te testen was, maar da's enkel 'hindsight'. Als jij een week had om de drive te testen, had je het hoogstwaarschijnlijk ook niet gevonden.
Dat is al de zoveelste keer dat er met een nieuw product iets mis blijkt te zijn.

Ik begrijp dat elektronische apparaten ingewikkelde dingen zijn, waar ook veel software / firmware in zit en dat er altijd een foutje in kan zitten, maar het gebeurt vrij regelmatig dat er een "domme" fout in een nieuw product blijkt te zitten (en natuurlijk niet alleen bij Intel, maar bij verschillende fabrikanten). Slecht voor de consument en slecht voor de reputatie van de fabrikant.

Het is blijkbaar toch beter om met nieuwe producten een tijdje te wachten, in plaats van ze direkt te kopen op het moment dat ze uitkomen.
Deze producten zijn duidelijk voor 'early-adopters', mensen die heel bewust zijn van mogelijke problemen.

Anderzijds bepaalt deze tijd wie de grote spelers worden in de SSD markt voor de komende twintig jaar of zo, dus ze deinzen er niet voor terug om wat risico's te nemen. De winnaars zijn uiteindelijk zij die snel nieuwe producten op de markt brengen, die goed presteren en relatief goedkoop zijn. Een bug in een weinig gebruikte feature is dan ook niet zo kritiek als de ervaring tijdens alledaags gebruik...

Het duurt nog wel even voor SSD's echt mainstream zijn, maar wees gerust dat tegen dan de kaarten wel gedeeld zijn en dat ze zich zo geen foutjes meer veroorloven. Wil je echter vandaag al het nieuwste van het nieuwste, dan moet je je er bewust van zijn dat het nog wat kinderziekten kan hebben. Al bij al vindt ik dit echter een zeer miniem probleem, en Intel reageert er heel snel op.
wanneer in het bios van de ssd een wachtwoord wordt uitgeschakeld of veranderd.
Hoe doe je dat?
Zoals bij RAID kaarten? FXX toest indrukken tijden boot proces?
Tsja, heel jammer natuurlijk, dat er een bug in zit, maar het is een goede zaak dat Intel zo snel ingrijpt en de verkoop voorlopig stopt zet. Dat vind ik alleen maar prijzenswaardig. Zeker als je je het fiasco met de firmware van de Seagate schijven van een paar maanden geleden nog herinnerd: Eerst ontkennen ze dat er een probleem is, dan een update vrijgeven die totaal averechts werkt en de boel nog verergerd en dan uiteindelijk, na een dikke week of zo, kun je dan de juiste fw downloaden, tenminste, als de server niet plat ligt na een stormloop.

Nee, wat mij betreft heeft Intel het goed aangepakt. Uiteindelijk kun je gewoon niet alles testen van te voren....en als dan blijkt dat er iets niet goed werkt en je reageert dan zo snel en adequaat: dan blijven je klanten heus wel bij je!

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True