Živě T-10: nafouknutá bublina Y2K

Je zajimavé kolik najivků se tadz sešlo. Problem Y2K byl a byla to realna hrozba. Velke podniky maji tak komplikovane systemy, kdy kazdou cast resil nekdo jiny a ten to jeste po nekom prevzal, ze opravdu nikdo nemohl tusit co se vyvrbi. Ac je to neuveritelne, tak my jsme mely ve firme problem Y2010 , stacilo aby programator pocital jen s posledni cislici v roku a uz nefungovala vyroba. Proste pred temi 8 lety se reklo ze vyrobek pojede 4 roky a naraz se vyrabi doted. Takovych chybek je vsude mozne hromada

Po bitve je kazdy general. Vim prinejmensim o jedne korporaci kde by se problem byval projevil. At uz kvuli BIOSu v te dobe pouzivanych stanic nebo treba formatu data v DB. V te dobe jedna z nejvetsich spedicnich firem by tedy mela dost problemy, pokud by se tahle "bublina" neresila vcas.

http://odhal-ji.wz.cz/index.php...

Problém Y2K nebyl je ve změně letopočtu na nový rok, ale i v tom, že byl přestupný a některý software jej chybně určil jako nepřestupný.

Ano, i takové nesmysly se vyskytly. Drtivá většina problémů ale byla tím, že se letopočet zcela běžně uváděl dvouciferně. A protože 00 < 99, bylo mnoho programů v háji.

Traduje se, že to bylo hlavně snahou o šetření drahou pamětí. Bylo to ale i snahou o šetření sloupci na rychlotiskárnách. Jenže se to tak vžilo, že najednou spousta programů netušila, že 00 je 2000 a ne 1900. A v databázích to bylo taky běžné, takže se honem upravovaly a s nimi samozřejmě i obslužné programy... byla toho spousta.

Pozor, kdo používáte Spamassassin, je tam pravidlo, které dává 3.19 bodu mailům s rokem 2010 a vyšším!

FH_DATE_PAST_20XX

Pamatuje na "Vizi strašlivou o roku 2000"?

tady je :http://fudge.logix.cz/art/ukazid.xp/377...

Dobrou zábavu

No, tak pro běžného uživatele Windows se u Y2K o velký problém nejednalo. Pro velké firmy se ale naopak o velký problém jednalo, protože nejznámější podnikový systém, tedy SAP, právě tímto problémem trpěl. Takže všichni, co měli SAP, byli donuceni k upgrade, což nebylo málo práce ani málo peněz. A SAP samozřejmě nebyl jediný takový software.

Přiznejte se, komu, kdo má linux (já osobně mám Ubuntu 9.10) jde nastavit datum třeba v roce 2040... Zrovna mně to nejde (buď problem Y2K38, a nebo ubunťáci ví, že tahle verze se v té době už stejně používat nebude :D).

Hey, what's going on here? Who's the monkey?

V pohode se mi povedlo nastavit datum 3210 system potom normalne bezel, az na problem ze to neustal BIOS a prestal fungovat USB radic na desce...

Mimochodem, jak o tomto tématu informovalo Živě??

Nemyslím ten předhozený článek z půlky ledna 2k ale zajímaly by mně vaše články z doby kdy hysterie pomalu gradovala. Tedy z podzimu 99 . Jestli jste taky náhodou nepatřili k těm co prorokovali konec světa v 00:00:01 1.1.2000

Kdysi jsem dělal program který při startu PC opravoval špatné datum,po roce 2000 totiž většina levnějších desek po restartu nechápala a resetovala datum na 1981 (rok 1900 BIOS neznal),všechno zůstalo správně,jen se vám datum po resetu PC vždy překlopil na rok 1981.Když počítač běžel,tak překlopení data na rok 2000 nebyl problém,ale po restartu BIOS opět nepochopil číslo 2000 a nastavil výchozí hodnotu.Řešil jsem to programem ve kterém se prostě jednou za rok musel ručně přehodit rok,aby při startu systému nastavil správný (kdo to neudělal,tomu to pořád nastavovalo 2000).Zajímavé ovšem bylo,že tenhle problém měli jen desky s BIOSy American Megatrends a potom desky s BIOSy Award pro procesory Cyrix,stará 80386SX s BIOSem Phoenix neměla sebemenší problém

živě: nafouklý nadpisy článků

spíš než nafouklá bublina to byl nafouklý problém. dobře si pamatuju, jak se zkoušelo co udělá nový rok a některý programy měly opravdu problém rozdejchat že je rok 2000. problém byl, akorát novináři kolem nesmyslně šíleli, což je logický, čím víc drama, tím víc čtěnářů, tím lepší výplata. takže nafoukli problém a na to se přiživilo pár rádoby konzultantů. kdyby nedělali novináři takový humbuk, nebyl byl zájem firem pak o tyhle konzultanty. svět IT dobře věděl co ho čeká a řešil by problém i bez varování novinářů apod.

Bublinou bolo to, že sa Y2K problém podarilo vsugerovať aj vlastníkom PC, prípadne tým prevádzkovateľom systémov, ktorým by prípadný chybný dátum nerobil problém. Určite existovali aj rôzne dôležité systémy, ktorým by chybný dátum problémy narobil, ale ak sa zamyslíme, je ich menšina.

U PC to jednoducho popísal vtedajší Chip: "Nastavte si čas na pár minút pred polnocou 31.12.1999 a sledujete, čo sa stane. Ak sa dátum zmení na správny, ste v pohode. Ak sa dátum zmení na nesprávny, ale dá sa prestaviť a po reštarte ostane správny, tiež ste v pohode... Za svoje databázy si zodpovedáte sám."

Verím, že 90% PC problém nemalo, a u časti tých, čo ich mali, to aj tak nejako nevadilo. Ale ľudia namiesto takéhoto pokusu vyhadzovali peniaze za rôzne "špeciálne softvéry".

Podobne neverím, že by napr. riadenie svetiel na križovatke nejako zásadne záviselo od letopočtu a neverím, že nebolo možné to nejako neškodne vyskúšať.

>Verím, že 90% PC problém nemalo

co to je proboha za nesmysl? vis co by bylo kdyby 10% pocitacu melo problem? treba kazdy desaty pocitac ridici krizovatku.

A proč by jako měl být počítač řídící křižovatku nějak závislý na tom, jaký je datum? To si jako představuješ, že ten počítač si najednou řekne, sakra, blbý datum, hodim tam zelenou ze všech stran? Asi máš dost malé povědomí o fungování podobných systémů....

asi tak,

tých 90% som myslel na obyčajné stolné PC, u ktorých to spôsobilo nanajvýš určité problémy pri prenose súborov, čo väčšinou tí ľudia, ktorých sa to týkalo, aj tak nerobili. U niektorých systémov problém vzniknúť mohol, ale tam za to zodpovedal ich správca. Ten musel vedieť, či tam je niečo, čo životne závisí na dátume. Ale to neriešili tie všeobecné softvéry a certifikáty.

Ze neco neznate neznamena, ze to neexistuje

Treba semafory v Praze (nektere) jsou rizeny pocitacem, ktery urcuje mmj. rezim denni/nocni a to i podle kalendare (vikendy/svatky). Neni to tak davno co se z nejakeho duvodu nepodarilo prehodit denni/nocni rezim a kolony byly i bez prispeni nehod az k Pruhonicim...

Tolik k "hloupym" semaforum.

řízení světel? Jedině, kdyby brali např podle dne v týdnu, jak budou přeblikávat (v neděli lidi jedou jinam, než v pondělí), ale katastrofa by to asi nebyla. Ale slyšel jsem o případu, kdy systém odvelel k vyhození náklad celé námořní lodi, protože si myslel, že zboží je 100 let prošlé Splatnosti faktur, ověření věku (vlastně i spočítání věku z rodného čísla je podobný problém)

Nebyla to bublina, a venkoncem většina servisních balíčků byla zdarma.

Ostatně, jak správně konstatuje článek, pokud měl podnik moderný zabezpečený IS (ať už bankovní či energetický), tak dostal od výrobce informaci "náš produkt je Y2K" compliant, a už se tím nemusel víc zabývat.

To že halt spousta systémů zabezpečené nebyly,a je smutný fakt. Možná ne pevné disky, ale už biosy, OS

,většina programů v tehdy tak populární Foxpro...

Autor má možná pravdu že se to dost medializovalo, a spoustě jiných chyb se takové slávy nedostalo.

Asi podobnou medializací prochází nedávný kiks TipSportu - jejich web umožnil vložit sázkařům nepovolenou (z hlediska pravidel) variantu sázky. Vyhranou sumu cirka půl miliardy pochopitelně TipSport vyplatit nehodlá, a odvolává se jak na vyhlášená pravidla, tak i na chybu v softwaru.

>A co nás čeká v budoucnu? Už se můžeme těšit na fenomén Y2K38, který nastane 19. ledna roku 2038. Stávající

>systémy (které tou dobou budou už v muzeu) případně i některé velmi staré stroje vybavené elektronickým >datem, tak za 28 let možná ukážou špatně datum

ten problem sa tyka len 32 bitovych systemov. t.j systemov, kde je splnena jedna z moznosti

a) 32 bit CPU

b) 32 bit OS na 64 bit CPU

c) 32 bit. aplikacny program na 64 bit OS na 64 bit CPU

co samazrejme uz davno nebude problemom, uz ani dnes to nie je problem, tam, kde ma admin rozum...

http://www.phoronix.com/scan.php...

jediny problem vidim v hrackych PC a nejakych ekonomickych systemoch

alebo nejake riadaice systemy pre armadne stroje, satelity, rakety ... od Octagonu

http://www.octagonsystems.com/products/products.aspx...

ako najcastejsie kupovana 2050 s AMD(nexGen) nx5x86 CPU

http://www.octagonsystems.com/products/2050.aspx...

alebo druha najcastejsia maticna doska Octagon 6020

http://www.octagonsystems.com/products/6020.aspx...

Lenze tie systemy maju aj tak problem s casovacim chipom AMD 3113, ktory sa prevail aj v roku 2002 a to aj po oprave z roku 1998, ked Tomahawky trafili riaditelstvo intelu v Bagdade

http://www.theregister.co.uk/1998/12/18/amd_powered_mi... ...

taky chybny chip na maticnej doske (motherboard) moze sposobit, cokolvek, vid ovplyvnopvanie roadenej strely semaformi, aj ked je zdroj bulvarny...

But the INQUIRER reckons that Cruise Tomahawk missiles are not all they're cracked up to be. They sometimes go a bit awry and we were told by an AMD employee just around the time of Gulf War I there's a reason for that.

It's because the AMD 3113 timer chip in the guidance system of the Cruise missiles has a bug, sorry defect, which sometimes causes the Tomahawks to turn right at the traffic lights or whatever instead of left.

http://www.forum.hr/showthread.php...

s AMD 80386

Výskumník a vyučujúci predmetu Unix/Linux... na 101. najlepšej univerzite v oblasti informatika na svete shanghairanking.com/SubjectCS2012.html , . ACM Professional member #5480576

...nebo kde jakákoliv aplikace ukládá interně datum do 32-bitového datového typu, bez ohledu na architekturu na které aplikace běží. Nebo starší databázové stroje, které používají 32-bitový formát data. Těch možných problémů je opět dlouhá řada.

Buď do roku 2038 ty aplikace kompletně přepíšeme, nebo se bude problém opakovat. Protože bankovní systémy nejsou váš domácí počítač, lze předpokládat, že minimálně některé programy napsané před rokem 2000 tam najdete ještě v roce 2038.

Zrovna dnes, když jsem vstával jsem si na to vzpomněl. Taky si vzpomínám, že jsem si na sklonku roku koupil Computer (tehdy to byl můj první koupený časopis o PC) a v něm bylo jako příloha CD, jak přežít Y2K. Takže jste se na tom také přiživili ;) (ale nechci vám křivdit, možná to byl váš konkurent pro začátečníky Počítač pro každého).

Nicméně měl jsem doma v té době jakousi 486 a ta to přečkala bez jakékoliv újmy, stejně jako moje 286... No přiznám se jako desetiletý kluk mě zajímali úplně jiné věci než jakýsi konec světa kvůli PC.... :))

Co si pamatuju, tak s OS problém nebyl, ale ne každý BIOS takové datum unesl. Doma mi to tehdy zvládly všechny počítače až na jednu 80MHz 486DX2, která po restartu měla datum vždycky blbě. Pomohla disketa s nějakým programem, který se hodil do autoexecu/configu, a bylo po problémech. Na tom počítači se kdysi dělalo účetnictví, tak mi ten program ušetřil nějakou práci navíc s výměnou HW. Věřim, že to pomohlo více lidem.

Mám tu dokonce ještě modré CD Y2K pack od Microsoftu. Když už nic jiného, tak to byla aspoň dobrá cesta, jak lidem nahrát poslední opravy do jejich Windows, Office a pár dalších produktů, což neni nikdy k zahození.

OS to dával (Windows, nevím jak DOS), ale problémy byly často přímo v programech, jak ony samy pracovaly s datem.

Samozřejmě, že novináři a ostatní laici (v čele s vševědem Václavem Klausem) si myslí, že Y2K byla bublina. Desetitisíce systémáků a statisíce programátorů po celém světě dva roky makaly na tom, aby to tak dopadlo. Já byl jeden za nich a vím, kolik aplikací a systémů se u nás ve firmě muselo opravit, aby od 1.1.2000 dávaly správné výstupy. A přesto nám tři chyby utekly a honily se ještě v lednu a únoru. Když na vašich počítačích závisejí peníze zákazníků...

No já nevím, ale osobně jsem také celkem přesvědčený, že to, že se "nic" nestalo (nepamatujete už na ty stojící vlaky, vyhozené náklady s "proslými" konzervami atd.?) bylo právě díky tomu, že se to aktivně řešilo? Vezměte si, že hodně PC opravdu problém s datumem mělo a lidi to řešili, teď po bitvě to je lehké zpochybnit, ale nechci vidět ty zoufalé pohledy lidí na účetnictví a rok 1900... ještě nedávno jsem narazil na webovou stránku s datem 19009 nebo tak nějak

Takže sorry, možná byly ty vize přehnané, aby se na tom vydělalo co nejvíc, ale lidi aspoň věděli o možném problému a řešili ho.

"se "nic" nestalo bylo právě díky tomu, že se to aktivně řešilo" .. jistě, to je důvod. Když člověk na silnici věnuje pozornost řízení a nehavaruje, tak jen blázen z toho může udělat závěr, že protože nehavaroval, tak dávat pozor vlastně ani nemusel. To postrádá elementární logiku.

Y2K problém nenastal právě proto, že se mu pozornost věnovala.

Now slightly more awesome!

Jenže Tvoje logika je zvrácená úplně stejně. Když budu chodit v helmě, aby mi na hlavu nespadl meteorit a on nespadne, tak budeš tvrdit, že kdybych helmu neměl, tak mi na hlavu spadne? Zaměňuješ příčinu a následek.

Kdyby se Y2K problém neřešil, dopadlo by to úplně stejně. O pár databází a systémů víc by začalo hlásit nesmyslný datum, během jednoho dne by se to opravilo a nic by se nestalo.

Jak jsem psal níže, zkus se zeptat bank, pojišťoven, velkých korporací, burz, kde běží software navržený 30-40 roků dozadu... Tam bylo potřeba programovat a kdyby se to nedělalo, bude velký problém. To jsou fakta, která člověk co se věnuje jen novinařině a zná jen "domácí" aplikace typu Word nevidí.

Příspěvek byl 1× upraven, naposled 31. 12. 2009 13:08

Now slightly more awesome!

jestli myslíte, že v bankovním systému se taková chyba opraví během jednoho dne, jste naivní. Vím, kolik práce dalo v nebakovním systému změnit slovenské koruny na eura, trvalo to asi rok. Taková změna se musí testovat, musí se zohlednit, kde všude se s tím datem pracuje a jak, musí se zajistit nejen ukládání a načítání, ale i prezentace, operace s datem, projít celý kód, jestli někde nejsou kolize atd...

BTW kdyby zxrovna systém vaší banky hlásil nesmyslný datu, že máte spoustu plateb po splatnosti a zažádal o exekuci, asi byste to na tak lehkou váhu nebral, co?

No vidíte, takže mi chcete říci, že v takto důležitých systémech hledají programátoři chyby chvíli před tím, než nastanou? Pochybuji, že se kontrolou možných kombinací dat a přestupných dní zabývali až těsně před 1999-2000.

Neřeknu u běžných programů, přetažených z dosu a podobně starých věcí, ale u kritických a obrovských systémů, kde jde především o čísla a přesná data, je to vysoce nepravděpodobné, to dřív uvěřím, že to programují studenti středních škol v odpoledním vyučování.

It's All Part of the Plan...

Kdybyste ty "kritické a obrovské" systémy znal, tak byste věděl, že spousta z nich je desítky let stará. V řadě případů k nim nejsou zdrojáky, a jejich autor je neznámý, v důchodu či mrtvý. A například data ukládaná programy v psanými v COBOLu nemají ani popsaná pole, bez zdrojáku programu je to jen binární změť. Zapomeňte na dnešní komfortní databáze, kde i bez aplikace vidíte tabulky, sloupce a hodnoty v nich. A teď si představte, že máte podobný pravěký program. Jak ukládá datum v databázi? Bude správně fungovat po 1.1.2000? Jaké ztráty firmě přinese, když ten program nebude fungovat? Když u vás doma zítra nepůjde počítač, je to trochu jiné, než třeba v datovém centru ČNB :)

Podle vás a autora článku se na to měli všichni vykašlat? Jak by se vám líbilo, kdyby od 1.1.2000 nebylo možné třeba vybírat z bankomatů, autorizovat platební karty, nebo vstupovat do budov opatřených čipovým autorizačním systémem?

Ano, ano! Máte naprostou pravu, pracoval jsem jako IT specialista ve vývoji elektronického bankovnictví jedné z největších českých bank... A přesně tak to bylo!

Nikdo nevěděl jak nic pracuje, když jsme chtěli dělat nějaký software, aby měl nové funkce a potřeboval komunikovat s ČNB, tak jsme se museli stát rytíři Jedi a pomosí Síly naprogramovat správné funkce, protože autor původních systémů ČNB byl už dávno mrtvý a nikdo nevěděl jak to funguje

A když nastala nějaká chyba, tak jsme měli v budově synagogu, mešitu a křesťanskou kapli a modlili jsme se každý ke svým bohům, aby chybu odstranili - protože logicky z tak prastarého systému, který nikdo nevěděl jak funguje odstranit prostě nešla DDD

A máte naprostou pravdu, kdyby neexistovalo tolik firem na Y2K, tak nejen že by bankomat vůbec nefungoval při pokusu o výběr 1.1.2000, ale ještě by Vás na místě rozřezal laserovým parskem jak v Resident Evilu a k tomu by na celou Vaši rodinu poslal z budoucnosti Terminátora T-800 DDD

Tak a teď víte celou pravdu, kterou jsme my, bankovní IT specialisti, tajili před světem!!

Spousta firem po celém světě problém Y2K vůbec neřešila a výsledek dopadl tak jak dopadl. Naopak se vyskytl i případ u nejmenovaného účetnictví, které i přes placený update "Y2K" obsahoval chybu data v některých dokladech při přechodu z února na březen. Jak je napsáno v článku, chyby v programech jsou stále a ty s datem rovněž. Ve staré době to byla nutná optimalizace z nedostatku paměti, v roce 2000 už to byla jen a jen chyba případných programátorů aplikací.

It's All Part of the Plan...

no ale to přece nejsme v rozporu, ne? Evidentně ta chyba existovala, lidi na ni byli upozorněni, a protože věděli o problému, mohl se řešit. Jak to dopadlo v konkrétních případech, že často to bylo zbytečné, spousta firem na tom vydělala na hranici podvodu, to jsou už jiné věci. Ale problém roku 2000 existoval, sám jsem viděl nejeden počítač, který to nerozdýchal už na úrovni BIOSu (a tehdy hodně programů typu účetnictví bralo datum právě z BIOSu), takže se to řešit muselo.

Myslíte v "malém rozsahu". Nejedná se o aplikace pro domácnost, zkuste se zeptat bank, pojišťoven, velkých korporací, burz, kde běží software navržený 30-40 roků dozadu... Tam bylo potřeba programovat a kdyby se to nedělalo, bude velký problém.

Now slightly more awesome!

Pamatuju si, že naše staré PC nebylo schopno v BIOSu rok 2000 překlopit, tak jsme tehdy do toho koupili nějakou speciální přídavnou kartu, která to nějak opravovala... Stála tehdy asi 800 korun, nikdy jsem nepochopil, co přesně dělá... Ale W3.11 s ní byly spokojené a datum nezlobil Možná to někde ještě doma budu mít i s krabicí

Zdravím. Na toto "hardwarové" řešení jsem jednou narazil. Docela rád bych ho měl ve svém muzeu. Kdybyste to doma našel, byl byste to ochoten věnovat, nebo prodat do dobrých rukou sběrateli?

To by mě moc zajímalo o co šlo, zní to nepříliš věrohodně

Tedy jsem byl součástí projektu řešícího Y2K, takže to znám. BIOS ukládá rok ve formátu BCD, nejvyšší hodnota je 99. Při přechodu z roku 1999 na 2000 se může stát, že hodnota zůstane na 99, případně se přetočí na 100 místo 00, což vede k přepsání jiného byte v CMOS paměti BIOSu.

Těch možných problémů bylo samozřejmě víc. Například prostředí dBase IV a FoxPro intepretovaly krátké datum 1.1.00 jako 1.1.1900. Když se vám tohle stalo, těžko šlo počítat mzdy za leden 2000 :). Také větší množství sestav vypisovalo data stylem 1.1.19100, některé digitální měřáky spotřeby energií nedaly přechod...

Popsané věci nepatří mezi vysoce kritické, ale přesto bylo třeba je opravit. Faktura s datem 1.1.19100 je totiž neplatná, kalkulace mezd může selhat, spotřebu energie nebude jak vyúčtovat atd. Navíc tu byl potenciál pro větší problémy. Například přetečení jednoho bitu v paměti výtahu může znamenat jeho odstavení (nejde o výtah u vás v paneláku, ale o složitější výtahy ve výškových budovách, které znají datum). A když vám uvíznou v jeden okamžik lidé ve VŠECH výtazích daného typu v jednom časovém pásmu, tak to není moc velká sranda. Podobně nefunkční klimatizace nebo nefunkční kartový systém řízení vstupu do budovy může u mrakodrapu nadělat velké vrásky.

Tak jestli jsi dělal nějaké "projekty", tak jsi byl pěkný zloděj!! Protože je úplně jedno jaký BIOS udržuje datum - může klidně udržovat datum 10.15.1521 a není problém, aby to systém interpretoval jako 02.01.2009. Na BIOSu je důležité jen to, aby dokázal udržovat plynoucí jakýkoli čas - klidně i rok 5238.

Microsoft a další výrobci OS tehdy dokonce udělal "záplaty" na Y2K, takže systém i pokud by dostal z BIOSU datum chybně, tak ho interpretoval správně a správně ho i předával všem aplikacím v něm spuštěným...

Jinak účetnictví a mzdy s datem 1.1.19100 nejsou vůbec žádný problém - pokud už je účetní software tak prasácky napsaný, stačí do programu udělat drobný patch a případné již hotové výstupy nechat projet opravou typu "1.1.1900; 1.1.19100 = 1.1.2000" a je "po problému" DD

Demagogie s výtahy atd. je KRAVOVINA JAKO HROM!!!! Proboha jaký výtah funguje na základě data? Pokud systém výtahu vůbec datum zná, tak ho zná jenom jeden sybsystém, který může klidně vypadnout celý, ale výtah svoji činnost nepřeruší, zrovna tak přístupové karty atd. - nanejvýš by do updatu systému byly v LOGu výtahu nebo přístupu kartou chybně zobrazená data. A důsledek? Byl by asi tak "závažný" jako jestli máš stránku textu zarovnanou pouze doleva nebo pěkně úhledně "do bloku" DD

--

Kvůli změně DPH z 19% na 20% taky nevybouchne Temelín a nezaseknou se všechny výtahy, protože jejich systém musí nově zpracovávat servisní zásah s jiným DPH a kdyby to starý systém neměl nastavené, tak by jim to spolu nesedělo DDDDD )

Y2K je problematika pro dementy vycucaná z prstu

Nezpochybňuju že k drobným problémům mohlo dojít (zejména na systémech, kde se až příliš šetřilo pamětí).

Nicméně moje reakce byla na ono hardwarové zařízení pro PC... to jako že by se pridala karta, nastavená na IRQ 8?? imho to jsou jen teoretické dohady.

Programy pro otestování kompatibility s "Y2K" nebylo nic jiného než nějaký program, co přehodil čas na 31.12.1999 23:59 a pak se počkalo (+ hodně grafické omáčky kolem, poučení atd., aby uživatel měl pocit, že se něco "důležitého" děje). Kupodivu počítač nevybuchl

V té době jedno z CD časopisu comuter, bylo tématicky zaměřeno na Y2K problém :)

Tohle ale dokaze otestovat jenom BIOS, vesi okolo vlastnich aplikaci, databazi, mailserveru apod. si musis otestovat sam...

Kdysi na pocitaci RPP-16 byly v systemovem timestampu na rok vyhrazeny 4 bity a pripocitaval se k tomu offset 1972. A predstavte si, ze jeste v roce 1988 jich behalo asi 10 kousku, kde stalo za to vrtat v systemu, aby to slapalo dal!

2012 to jistí. Více neřešte, je to plýtvání penězi

Možná by bylo dobré se zaměřit na Mainframy.

Problém byl jinde než u osobních počítačů.

Priznam se ze moc nechapu proc by zrovna pro mainframy mel byt problem zpracovat cislo 946684800 (1.1.2000 v unixtime).

Cele Y2K byla fakt jen nafoukla bublina.

Problemy mohly nastat tak maximalne v pripade hodne starych databazi kde se pro usporu mista zapisoval cas pouze poslednim dvoucislim (a i tak jich mela nemale mnozstvi bitovy priznak stoleti) a podobne.

Asi tak Y2K byl fake jak svina... pro unix like systemy to nebylo nic vyznamneho, pro widle v podstate take ne (i kdyz nwm jak starsi verze, prece jen M$ jsou prasata stoleti)

a tusi nekdo nejakou app ktere rok 2000 vadil ????

Proto říkám, že problém byl hlavně u programů na mainframech, které používaly zkrácený formát data.

Programy na mainframy pochazí klidně i ze šedesátých let.

Oháníte se zde unixem a windowsem. Ale jsou i jiné systémy jako třeba z/OS.

Ano, ale asi jen velmi maly. Hlavicka souboru dbf udajne obsahovala datum s rokem ulozenym do jednoho byte. A dBase3+ pak chybne hlasila datum. Ale za prve to asi nikomu nevadilo, za druhe jen malokdo v roce 2000 asi jeste pouzival neco takhle zastaraleho.

Stejne tak pouze z doslechu znam zarizeni s HW problemem y2k - razitko s datem, kde se dalo natocit vsechno, krome prvniho dvojcisli roku. Udajne bylo na Libereckem magistrate pouzivano temer cely leden roku 2000

Proc myslite, ze to nebylo nic vyznamneho pro unix-like systemy? Unixy to nakonec nepostihlo diky pouziti y2k patchu, to ale ani zdaleka neznamena, ze zadny problem neexistoval...

Jediny y2k patch o kterem vim, byl "projistotni" v Linuxu. Resil prenastaveni RTC na PC v pripade ze by onen RTC chybu obsahoval. Vzhledem k tomu, ze RTC je pouzit pouze pri bootu a navic je zvykem pred vypnutim/rebootem ulozit stav systemovych hodin do hardwarovych (cimz by se prepsal chybne vygenerovany cas v RTC tim spravnym), tak to bylo fakt jen pro jistotu.

Navic systemy kde na case fakt zalezi maji obvykle ponekud presnejsi zdroj hodin nez je RTC.

Pro system jinak bylo uplne jedno jestli slo o 1. ledna roku 2000 nebo 46. zelence roku ovocneho netopyra.

Pokud vite o nejakem konkretnim patchi, resici Y2K chybu v OS (pravdepodobne i s upresnenim o ktery unix ci unix-like system jde), sem s nim. Bez vysmechu, bez urazky (jeden nemuze vedet vsechno).

Pokud si vzpominam spravne, tak vubec nejvic y2k patchu bylo pro SunOS 4.1.x: do jadra novy ovladac TOD a mam pocit ze i neceho v tcp/ip stacku, potom cron a at, suni sendmail a meli jsem problemy i se systemovym ucetnictvim. Taky se musela patchovat libc (a to i u Solarisu 2.x jestli se nepletu). No a pak samozrejme takove ty drobnosti jako nove date, passwd, touch atd.

Patch byly protreba i pro AT

for(rok = 70; rok rok; rok++) {

unix_time += sekund za rok;

if (LEAPYEAR(rok))

unix_time += sekund za den;

}

a pak se jeste dopocetly mesice, dny atd.

1.1.2000 byl ale TOD.rok nula, co to znamena pro takovyhle algoritmus je celkem jasne...

Samozrejme, tohle je jen naprosto trivialni priklad, ale musim rict, ze nekdy kolem toho roku 97 sme z toho vseho meli docela strach

Aha, Solaris (SunOS).

OK, Muzu se 100% jistotou prohlasit, ze Solaris 2.6 (SunOS 5.6) prezil beze ztraty kyticky rok 2000 aniz by byl jakkoliv patchovan nejakymi patchi ohledne Y2K (nejake patche teda ma, ale bez nich neslo nainstalovat HP OpenView - ani jeden se ale netyka Y2K).

Starsi neznam.

BTW. odkdy 'touch' a 'passwd' potrebuje prevod casu? Ty prevod do "cloveciho formatu" vubec nepotrebuji.

Jo a 'date' tam mam z roku 97, zda se nepatchovany, a nevypada ze by jej rok 2000 (ani prestupny den) nejak trapil. Ale priznavam ze si nepamatuju jestli jsem si nahodou pro sichr nevypomohl s NTP.

Apropo hodne "testeru" tohle vubec neresili.

Jasne, nas s Y2K honili taky. Ale celkove vzato si porad myslim ze to proste byla zbytecne moc nafoukla bublina. U nas byl napriklad zbytecne testovany desitky stroju, kterych se jakakoliv prace s casem ani nijak netykala (podle toho vypadaly i jejich casy - nektere mely dokonce rok 2000 uz za sebou .