"Y2K9" bug döntötte halomra a 30GB-os Microsoft Zune lejátszókat

Microsoft, Windows

A 2006-ban gyártott 30GB-os Microsoft Zune lejátszók tulajdonosai aggodalommal figyelték tegnap, ahogy készülékeik sorra működésképtelen állapotba kerülnek. Az online fórumokon futótűzként terjedt a hír és csakhamar már beceneve is volt a problémának: y2k9. Ünnepek ide vagy oda, a probléma híre Redmond-ba is eljutott, hiszen a Zune Product Team csapat részéről Matt Akers tájékoztatta a kétségbeesett ügyfeleket arról, hogy mi okozta a problémát.

A termékért felelős csapat vezetője elmondta, hogy tegnap kora reggel értesültek először arról, hogy a 2006-os 30GB-os Zune modelleket széleskörűen érintő probléma bukkant fel. A technikai csapat azonnal rászívódott a problémára és azonosította a hibát: a készülék belső órájának driverében olyan bug van, amely érinti a szökőévek kezelését. A hivatalos tájékoztatás szerint a problémának automatikusan meg kell szűnnie, ahogy elérkezik 2009. január 1. Ha a csapat várakozásai helyesek, akkor az érintett készülékek belső órájának GMT idő szerint ma délben automatikusan alaphelyzetbe kellett állnia. A készülékek tulajdonosainak hagyniuk kell a készülékeiket teljesen lemerülni, majd miután azok feltöltődtek, be kell azokat kapcsolni.

Muszáj idézni a hivatalos FAQ-ból:

"Q: Frissíteni fogjátok a firmware-t a következő szökőév eljövetele előtt (2012)?
Igen."

A Zune csapat elnézést kért a kellemetlenségért. Részletek a hivatalos állásfoglalásban és FAQ-ban itt.

( zeller | 2009. 01. 01., cs – 21:49 )

Már sokan mondták, hogy egy Microsoft termék képzelhető el amivel nincs szívás, de az meg egy porszívó... A világon iszonytatóan sok olyan gadget van, ami belső órával, szökőévekkel, vagy akár a szökőmásodpercekkel is meg tud birkózni... De a Zune, na az nem ilyen, az belerohad... LOL...

A Windows 95 mennyi uptime után rosálta össze magát? Ez akkor is randa nagy lámaság, hiszen a nagyobb kapacitású eszközökben meg nincs gond -- azt gondolná az 1szerű kocka, hogy szoftverice azonos, csak nagyobb tárkapacitással bír, aztán lóalkatrészt, olyan komponensekben is eltérnek, amiknek semmi köze a kapacitáshoz...

meg Huygens szondát, mret nem figyeltek a Doppler-eltolódásra.
Meg asszem még valami marsszonda-pályát elszámoltak, és ami elvileg keringett volna csak a bolygó körül, majdnem becsapódott. viszont a keringő egységeket nem csírátlanítják, ezért lett is belőle gebasz:)

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( nucc | 2009. 01. 01., cs – 23:40 )

Azert nem irigylem a fejlesztoket. Bar, ha megirtak volna jol, akkor vidaman unnepelhettek volna. De ezek azok a hibak, amiket ritkan tesztelnek a tesztelok.

Csak úgy elképzeltem, hogy egy ilyen vacakrol tolom a zenet a szilveszteri bulin, es ejfelkor szevasz. Mehet mindenki haza. Vagy elokerul egy iPod, hogy errol probald haver, ez menni fog :P

Az a fejlesztő, aki megír egy ilyen kódot, simán tarkónlőheti magát. Abszolút kezdő programozást tanulóknak szokott lenni alapfeladat, hogy írj egy naptárprogramot, ami kezeli a szökőéveket. Még jó hogy a hónapok hosszát nem drótozták be fix 30-ra, pedig az innen már csak egy nagyon kicsi lépés.
A másik oldalról viszont felmerül bennem, hogy milyen minőségbiztosítási rendszerük lehet? Nem tűnt fel senkinek, hogy az év kb 4 évente lehet 366 napos is?

( PDA_FAN | 2009. 01. 02., p – 00:41 )

Azért mókás, hogy van itt a fiókomban olyan palmtop, ami egy évtizeddel ezelőtt már röhögve kezelt a naptárával szökőéveket és 2000 utáni dátumokat, de a mikroszoftnál még ilyet biztosan nem láttak...

( bolond | 2009. 01. 02., p – 11:19 )

A hozzászólásokból látszik, mennyi hibátlan ember van itt. Ez csodálatos! :) Rajta vagytok a listámon, és ha majd szoftvert szeretnék fejlesztetni, megkereslek titeket. Köszönöm! :) Jaj, már alig várom, hogy teljesen hibamentes szoftvert írjatok nekem! Olyan izgatott vagyok! Ki is megyek az udvarra, hogy alábbhagyjon a láz. :P

:)

A szoftvert nem megírni kell hibamentesre (pontosabban minimális hibával terheltre), hanem tervezni, méghozzá úgy, hogy a tervezésnek része a tesztelés tervezése is -- egy óra/naptár kód esetén természetesen a szökőnapok, a szökőmásodpercek helyes kezelése (bár ez csak akkor releváns, ha külső forrásból kaphat időszinkront, ha szabadonfutó számlálót/órát használ, akkor a szökőmásodperc okozta pontatlanság az óraáramkör hibájával összemérhető). Az év 366. napjának kezelése meg... Lehet, hogy valahol konstansként be lett hegesztve, hogy for DayOfYear=1 to 365 -- mást nem nagyon lehet elképzelni -- ez durván tervezési hiba számomra.

Bolond, azért ne kezdj itt mártírkodni! Egy ilyen naptárkezelési hiba annyira szánalmas, mintha mondjuk az autóból kifelejtenék az olajtöltő nyílást. Mész vele egy darabig, aztán mikor olajat kell cserélni, keresed, hogy hol lehet utántölteni. A gyártó meg sajnálkozik, hogy jaj, hát ők nem gondolták, hogy olajat akar a tulaj cserélni :-)

A hasonlat persze sántít, mert ha kiderül, hogy egy autónak konstrukciós hibája van, akkor visszahívják az egész szériát, és sűrű bocsánatkérések közepette kijavítják. Ajándék bonbon az ülésen, karácsonykor üdvözlőlap a szervizvezetőtől.

De ha egy Microsoft gyártmányú bárminek hibája van, akkor szívjon vele a felhasználó, olvasgassa a manualt, ott majd leírják neki, hogyan gyógyítsa meg a gyártó által elcseszett szoftvert.

Ráadásul el kell fogadnod a licenszszerződést, hogy a szoftver nem a tiéd, azt te csak használhatod. De ha hibás a szoftver, akkor mégis neked kell pöcsölnöd a javítással, és nem viheted vissza, és nem tolhatod a CD-t az eladó arcába.

Szinkronizálni, ha befagyott, már nem lehet -- le kell teljesen meríteni, várni egy napot, hogy a belső óra 2008.12.31-ről 2009.01.01.-re váltson, majd feltölteni a készüléket... Ez nem megoldás, ez egy baromira ronda workaround. Normális esetben az adott kód minőségéért felelős emberkének fel kellene állnia a székéből, bárhol is ül most, és elhúznia a péróba. Nem, nem a kódernek, bár ő sem érdemli meg, hogy megsimogassák érte a buksiját...

Hasonlóval én is találkoztam régebben, de csak mostanában kezdek rákattanni a func tesztekre. Nagyon hasznos dolog, általában töredéke annyi idő alatt _garantáltan_ hibamentes a cucc, mintha végigkattintgatnám az egészet. Csak sokszor a töredéke annyi idő is több, mint 0, így marad az általad említett mentalitás :(

Egyáltalán nem szánalmas.

Én csak arról beszéltem, hogy nekem majd jobban meg fogja érni anyagilag, hogy a listámra került emberkék ugyanannyi pénzért jobb végeredményt készítenek, mint az átlag tenné. Vagy megtörténhet, hogy ők is hibáznak? Áhh, dobom is ki a listám.

Szerintem a legtöbb hardveren futó :) szoftverben vannak hibák (figyelmetlenségből adódó hibák is). Ellenben itt sokan azt az érzetet keltik, hogy ők jól csinálnák. Végül is nincs ezzel semmi gond, szép dolog az önbizalom. Polesz aláírása illik ide: "Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag van." Kívánom mindenkinek, hogy hibátlan kódot adjon ki a kezei közül! :)

Semmit sem kell. De mindent lehet. :)

:)

Nem, hanem a szoftverfejlesztés folyamatának, a szükséges és elégséges feltételeknek az ismerete. Egyébként meg nem lesz olcsóbb, ha a listádról választva íratsz meg valamit, ugyanis tuti, hogy a tervezési- és implementálási fázis is több erőforrást fog elvinni (tesztelés megtervezése, code review elvégeztetése), illetve lesz még egy nem is pici tétel, ami a szoftver tesztelésére fordított időt és erőforrást fogja fedezni.

Könyörgöm, egy akkora cég, mint a Microsoft, nem engedhetne meg figyelmetlenségből adódóan olyan hibát, mint hogy négyévente szökőév van! Ez nagyon primitív hiba!

Egy könyvelő bt-nek Clipperben programozó maszeknál elhiszem, hogy becsúszik egy gikszer, hiszen egymaga van mindenre: tervez, programoz, tesztel. De egy olyan cégnél, ahol sokezer ember dolgozik, nincs senki, aki kiszúrná, hogy rossz a dátumkezelés???

Pláne azok után, hogy a Zune-t úgy dobták a piacra, hogy az majd pár év alatt jól lenyomja az iPod-ot.

Szánalmas.

"Könyörgöm, egy akkora cég, mint a Microsoft, nem engedhetne meg figyelmetlenségből adódóan olyan hibát, mint hogy négyévente szökőév van! Ez nagyon primitív hiba!

Orvosi műtéteknél általában több ember van jelen – akik ráadásul nagyon koncentrálnak a feladatukra –, mégis előfordul, hogy a páciensben hagynak ezt-azt, vagy nem azt vágják, amit kéne. Sem a Microsoft, sem senki más nem bújhat ki a világ szabályai alól. Ennyi. Még egy-, a közössége által tisztelt és szeretett pap/sámán/vallási vezető is elkövet hibákat, vagy olyasmiket, amiket nem szándékozott megtenni, mégis megtette. Szerintem egy olyan pap/sámán/vallási vezető, akit a közössége tisztel és szeret, mindenképpen megbecsülésre méltó. Ebből következik, hogy ha egy ilyen ember hibázik, akkor hibázni nem lehet akkora nagy szörnyűség, mint ahogy itt megpróbáljátok beállítani.

Szánalmas.

Nem az.

:)

> hibázni nem lehet akkora nagy szörnyűség, mint ahogy itt megpróbáljátok beállítani.

Ez valóban nem szörnyűség, hanem tipikus [majd valaki megírja hogy mi, nekem nem sikerült jó elnevezést találnom]. Megspórolnak X fejlesztési időt, ami miatt Y(>>X) felhasználói idő pazarolódik el.

Meg ugye azt is tudjuk, hogy amit a fejlesztés időszakában egységnyi költséggel ki lehetne javítani, az a teszteléskor 10, a gyártáskor 100, és amikor már kint van a felhasználóknál, akkor 1000 egységnyi költséggel javítható.
Vagy ismét egységnyi költséggel kiteszem a cég honlapjára, hogy "négyévente egyszer belefér, hogy kikapcsolod". :))

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

Hát azért egy szoftverfejlesztést orvosi műtéthez hasonlítani nem valami épkézláb dolog. A fejlesztés szerves része a tesztelés, amit ez esetben nyilván nem vettek komolyan. Egy műtétnél nem nagyon van lehetőség a végeredményt tesztelni.

Abban igazad van, hogy bárki hibázhat, csakhogy ezreket etet a M$ azért, hogy teszteljék. Ők vajon mit csináltak?

Épkézláb?! És mi van az olajtöltő nyílással? :P

Az nyilván egy hülye, aki lemegy a boltba kenyérért és ezért-azért, de főleg kenyérért, aztán vesz ezt-azt, de kenyeret nem, mert elfelejtette. Vagy azért hülye, mert nem vett kenyeret, vagy azért, mert elfelejtett kenyeret venni.

Mit csináltak volna?! Ettek! :D

:)

egy olyan pap/sámán/vallási vezető, akit a közössége tisztel és szeret, mindenképpen megbecsülésre méltó.

igen, de a közössége a Microsoftot tiszteli és szereti? Most ne a nagyvállalati megrendelőkre gondoljunk, hanem a Zune célközönségére;)

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd