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

 ( trey | 2009. január 1., csütörtök - 21:41 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Na itt meg pont a ti híretekre hivatkoznak:

http://nyelvesz.blog.hu/2009/01/01/zune_1

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

Jóhát, nem tervezték ilyen hosszúéletűre, gondolták a 2006-os Zune-t már úgyse fogja használni senki 2009-ben... :P

Így jár aki nem frissít rendszeresen :-)

--
Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag van.

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

Látod? Ha drágább Zune-t veszel, akkor tudhatod, hogy nem csak a nagyobb kapacitás miatt drágább, hanem a szoftverje is értéknövelt! ;D

még a szökőévet is kezeli?!?!?! hinnye, killer feature! :D

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

Nem a szökőévvel magával, hanem azzal volt baja, hogy szökőév esetén egy évben nem 365, hanem 366 nap van -- legalábbis nekem ez jött le abból, ami történt és ahogy magyarázták.

Vagy azzal, hogy éjfélkor (UTC) volt egy "leap second", vagyis 23:59:59 - 23:59:60 - 00:00:00 volt az idő. Lehet, hogy ez nem tetszett neki.

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

A FAQ-ban határozottan a szökőév utolsó napjának problémás kezeléséről írnak, a szökőmásodpercről nem emlékeznek meg. Azt ilyen eszközök nem nagyon szokták kezelni, főleg azért, mert azt nem lehet előre pontosan számolni, hogy mikor lesz.

így is van.
viszont imvel csak szökőévben van 366 nap, számomra ez ekvivalens azzal, hogy a szökőévvel van baja ;)

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

Ez szépen megmagyarázza. Hát... hm.

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

Igen, csak a 30 gigás az 1. generációs, a többi az ún v2 a wikipedia szerint, tehát nem csak storage capacity-ben térnek el.


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Még szerencse... Viszont akkor is durva, hogy valami nem képes kezelni az év 366. napját...

Az a szornyu, hogy ezzel nincs egyedul, pedig ez utobbi mintha egy picivel komolyabb lenne.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Jó, persze, Mars-szondát is sikerült már elkúrni, mert valamelyik debil nem figyelt az SI-szabványú mértékegységekre.

meg repülőt is, a kétféle gallon miatt...

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

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?

Nem.
Már kezdő programozónak is alap, ha azt mondják, hogy "Írj Naptárprogramot", akkor szökőévet is kezel.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Sok helyen minnel tobb problema van egy termekkel, annal jobban megfizetik/elismerik a programozokat....

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

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

További négy évig megoldás. :)
Az ilyesmiket miért kell újra implementálni?
Nincs egy bevált kód, lib, akármi, amit egyszer megírtak hibamentesre?
Hova lett a programozói lustaság?

a szoftverteszteles, mint olyan, hazankban sem egy annyira bevett gyakorlat. volt olyan munkahelyem ahol egyenesen felhaborodtak mikor mondtam, hogy kene megy egy honap hogy a funkcionalitas/unit testinget megcsinaljuk, merthogy majd ugyis kapnak bugreportot. hat rotfl. :)

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. :)

:)

csak gyakorlat kerdese amugy. :)

A tökéletesség? :D

:)

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.

jó, de azt a marketing osztály találta ki, nem a programozók ;)

Idézet:
"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.

Idézet:
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

de a következő szökőévkor már úgysem fog működni a cucc. meg amúgyis, vegyél inkább újat, az már javított ^^

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

> a listámra került emberkék ugyanannyi pénzért jobb végeredményt készítenek,

MS átlag fizetésért, MS átlag minőségnél jobbat? Természetesen.

jó kis off-by-one bug... ;)

No lám, van is a Mikorszopsznak publikált dátumkezelő eljárása, és jéé, ott tudják kezelni a szökőévet.

Úgy érted nem találtad meg benne a hibát? Akkor te se vagy jobb az MS-nél, látod? ;)

Nem mondod, hogy ez a hibás programkód!?
Nem olvastam végig, de majd most megteszem :-)

omg, mennyi béna ötlet a hozzászólásokban.

uram-atyám

    year = ORIGINYEAR;

    while (days > 365)
    {
        if (IsLeapYear(year))
        {

if (days > 366)

FAIL!

-

-

-