I 2000 kom og gik Y2K-fejlen uden mange problemer. Trods forudsigelser om omfattende fejl blev krisen afværget ved både langsigtet og sidste øjebliks planlægning og indgriben, og ingen kritiske systemer brød sammen. I årene derefter er de få operativsystemer og applikationer, der blev berørt, i de fleste tilfælde blevet opgraderet, udskiftet eller pensioneret.
Hvis du bruger et Unix- eller Linux-baseret system, er der endnu en datarelateret fejl, du skal bekymre dig om – i år 2038.
Alle 32-bit Unix/Linux-baserede systemer gemmer systemurets tid internt som antallet af sekunder siden epoke, eller 00:00:00:00 den 1. januar 1970. Denne interne datatype, time_t, er i de fleste tilfælde et 32-bit (4-byte) signeret heltal. Hvis det pågældende system følger POSIX-standarden (som de fleste Unix- og Linux-systemer gør), er det seneste tidspunkt og den seneste dato, der kan repræsenteres som sekunder siden epoken i dette 32-bit signerede hele tal, 3:14:07 UTC tirsdag den 19. januar 2038.
Efter dette tidspunkt og denne dato vil den interne repræsentation af systemtiden nå 2147483647, det højeste tal, der kan lagres i et 32-bit signeret heltal. Et sekund efter dette vil den nå op på et negativt tal, -214748363648. De nuværende programmer vil enten fortolke dette negative tal som et ældre årstal (1901) eller fastfryse systemuret på 03:14:07 den 19/1/2038. Dette vil muligvis få programmer og operativsystemer til at fejle, da de ikke er designet til at fungere med et hængende systemur eller et systemur, der viser årstallet 1901.
Der findes ingen brugbare løsninger (som ikke ødelægger eksisterende programmer) for systemer med 32-bit processorer eller operativsystemer og programmer, der kører i 32-bit tilstand på 64-bit processorer. Mange nuværende Unix/Linux-operativsystemer kører allerede i 64-bit-tilstand (med en tilsvarende “lang” time_t, når de kører på en 64-bit-processor; i de fleste tilfælde løser dette problemet.
Operativsystemer, der understøtter en lang 64-bit time_t, er højst sandsynligt ikke berørt af fejlen Year 2038 med hensyn til det interne systemur. Programmer, der bruger en 32-bit time_t, kan dog stadig fejle, selv om det system, der kører programmet, understøtter fuld 64-bit drift.
Her er en hurtig oversigt over den aktuelle status for Unix 2038-understøttelse i de almindelige Unix/Linux-udgivelser:
- Solaris 7 eller højere på 64-bit UltraSPARC- og SPARC64-processorer samt Solaris 10 på x86-64-platforme har en 64-bit time_t.
- AIX version 4.3.3 på 64-bit PowerPC- og Power-processorer har en 64-bit time_t.
- Linux-kernen, der kører i 64-bit-tilstand på IA64- eller x86-64-processorer, har en 64-bit time_t.
- Mac OS X version 10.4 og nyere har en 32-bit kerne, men programmer kan bruge en 64-bit time_t, når de kører på PowerPC G5 eller x86-64 CPU’er.
- FreeBSD 6.0 og nyere har en 64-bit time_t, når de kører på en 64-bit platform.
- OpenBSD 4.1 og nyere understøtter en 64-bit time_t.
- NetBSD har endnu ikke en 64-bit time_t, men der arbejdes på at løse problemet til en kommende udgave.
Selv om dit nuværende styresystem endnu ikke er Unix 2038-sikkert, skal du ikke være bekymret! Folk har været opmærksomme på problemet i mange år nu, og der arbejdes aktivt på løsninger. I de fleste tilfælde vil problemet blive løst ved at få styresystemet og programmerne til sidst til at køre i fuld 64-bit-tilstand.
Jeg forventer, at alle større desktop-styresystemer vil være fuldt ud 64-bit inden for de næste fem til ti år. Desuden vil en “trickle down”-effekt bidrage til at erstatte nuværende systemer med 64-bit konfigurationer, hvor det er muligt og omkostningseffektivt.
Om forfatteren: Bill Bradford er skaberen og vedligeholderen af SunHELP og bor i Houston, Texas, sammen med sin kone Amy.