Vuonna 2000 Y2K-virhe tuli ja meni ilman suuria ongelmia. Huolimatta ennusteista laajamittaisesta epäonnistumisesta kriisi vältettiin sekä pitkän aikavälin että viime hetken suunnittelulla ja toimenpiteillä, eikä yksikään kriittinen järjestelmä kaatunut. Sittemmin ne harvat käyttöjärjestelmät ja sovellukset, joihin vika vaikutti, on useimmissa tapauksissa päivitetty, korvattu tai poistettu käytöstä.
Jos käytät Unix- tai Linux-pohjaista järjestelmää, sinun on huolehdittava vielä yhdestä päivämäärään liittyvästä viasta – vuonna 2038.
Kaikki 32-bittiset Unix/Linux-pohjaiset järjestelmät tallentavat järjestelmän kellonajan sisäisesti sekuntien lukumääränä epookista eli 1. tammikuuta 1970 kello 00:00:00 lähtien. Tämä sisäinen tietotyyppi, time_t, on useimmissa tapauksissa 32-bittinen (4 tavua) merkillinen kokonaisluku. Jos kyseinen järjestelmä noudattaa POSIX-standardia (kuten useimmat Unix- ja Linux-järjestelmät noudattavat), viimeisin aika ja päivämäärä, joka voidaan esittää sekuntia aikakauden alkamisajankohdasta lähtien 32-bittisenä merkityn kokonaislukuna, on 3:14:07 UTC tiistaina 19. tammikuuta 2038.
Tämän kellonajan ja päivämäärän jälkeen järjestelmän sisäinen järjestelmän kellonajan esitystapa saavuttaa arvon 2147483647, joka on korkein 32-bittisenä merkityn kokonaislukuna tallennettavissa oleva luku. Sekunti tämän jälkeen se kiertyy negatiiviseen lukuun -2147483648. Nykyiset sovellukset tulkitsevat tämän negatiivisen luvun joko vanhemmaksi vuodeksi (1901) tai jäädyttävät järjestelmäkellon aikaan 03:14:07 19.1.2038. Tämä aiheuttaa mahdollisesti sovellusten ja käyttöjärjestelmien epäonnistumisen, koska niitä ei ole suunniteltu toimimaan roikkuvan tai vuoden 1901 näyttävän järjestelmäkellon kanssa.
Ei ole olemassa käyttökelpoisia korjauksia (jotka eivät rikkoisi olemassa olevia sovelluksia) 32-bittisiä prosessoreita käyttäville järjestelmille tai käyttöjärjestelmille ja sovelluksille, joita käytetään 32-bittisessä tilassa 64-bittisillä prosessoreilla. Monet nykyiset Unix/Linux-käyttöjärjestelmät toimivat jo 64-bittisessä tilassa (vastaavalla ”pitkällä” time_t:llä, kun ne toimivat 64-bittisellä prosessorilla; useimmissa tapauksissa tämä ratkaisee ongelman.
Käyttöjärjestelmät, jotka tukevat pitkää 64-bittistä time_t:tä, eivät todennäköisesti kärsi vuoden 2038 bugista järjestelmän sisäisen kellon osalta. Sovellukset, jotka käyttävät 32-bittistä time_t:tä, voivat kuitenkin silti epäonnistua, vaikka sovellusta pyörittävä järjestelmä tukisi täyttä 64-bittistä toimintaa.
Tässä on lyhyt katsaus Unix 2038 -tuen nykytilaan valtavirran Unix/Linux-julkaisuissa:
- Solaris 7:ssä tai uudemmissa 64-bittisissä UltraSPARC- ja SPARC64-prosessoreissa sekä Solaris 10:ssä x86-64-alustoilla on 64-bittinen time_t.
- AIX:n versiossa 4.3.3 64-bittisillä PowerPC- ja Power-prosessoreilla on 64-bittinen time_t.
- IA64- tai x86-64-prosessoreilla 64-bittisessä tilassa toimivassa Linux-ytimessä on 64-bittinen time_t.
- Mac OS X:n versiossa 10.4 ja uudemmissa on 32-bittinen ydin, mutta sovellukset voivat käyttää 64-bittistä time_t:tä ajettaessa PowerPC G5- tai x86-64-suorittimilla.
- FreeBSD:ssä 6.0 ja uudemmissa on 64-bittinen time_t ajettaessa 64-bittisellä alustalla.
- OpenBSD 4.1 ja uudemmat tukevat 64-bittistä time_t:tä.
- NetBSD:ssä ei vielä ole 64-bittistä time_t:tä, mutta ongelmaa pyritään korjaamaan tulevaa julkaisua varten.
Ei hätää, vaikka nykyinen käyttöjärjestelmäsi ei olisikaan vielä Unix 2038 turvallinen! Ihmiset ovat olleet tietoisia ongelmasta jo monta vuotta, ja he työskentelevät aktiivisesti ratkaisujen parissa. Useimmissa tapauksissa ongelma ratkeaa siten, että käyttöjärjestelmä ja sovellukset toimivat lopulta täysin 64-bittisessä tilassa.
Odotan, että kaikki tärkeimmät työpöytäkäyttöjärjestelmät ovat täysin 64-bittisiä seuraavien 5-10 vuoden aikana. Lisäksi ”trickle down” -vaikutus auttaa korvaamaan nykyiset järjestelmät 64-bittisillä kokoonpanoilla siellä, missä se on sovellettavissa ja kustannustehokasta.
AUTORISTA: Bill Bradford on SunHELPin luoja ja ylläpitäjä, ja hän asuu Houstonissa, Texasissa vaimonsa Amyn kanssa.