Nel 2000, il bug Y2K arrivò e passò senza molti problemi. Nonostante le previsioni di un fallimento diffuso, la crisi è stata evitata grazie alla pianificazione e all’intervento sia a lungo termine che all’ultimo minuto, e nessun sistema critico è fallito. Negli anni successivi, quei pochi sistemi operativi e applicazioni che sono stati colpiti sono stati nella maggior parte dei casi aggiornati, sostituiti o ritirati.
Se usate un sistema basato su Unix o Linux, c’è un altro bug legato alla data di cui dovrete preoccuparvi — nell’anno 2038.
Tutti i sistemi a 32 bit basati su Unix/Linux memorizzano internamente il tempo dell’orologio di sistema come il numero di secondi dall’Epoca, o 00:00:00 del 1 gennaio 1970. Questo tipo di dati interni, time_t, è nella maggior parte dei casi un intero firmato a 32 bit (4 byte). Se il sistema in questione segue lo standard POSIX (come la maggior parte dei sistemi Unix e Linux), l’ultima ora e data che può essere rappresentata come seconds-since-the-Epoch in quel 32-bit signed integer è 3:14:07 UTC di martedì 19 gennaio 2038.
Dopo questa ora e data, la rappresentazione interna del tempo del sistema raggiungerà 2147483647, il numero più alto memorizzabile in un 32-bit signed integer. Un secondo dopo, si avvolgerà su un numero negativo, -2147483648. Le applicazioni attuali interpreteranno questo numero negativo come un anno più vecchio (1901) o congeleranno l’orologio di sistema alle 03:14:07 del 19/01/2038. Questo potrebbe causare il fallimento di applicazioni e sistemi operativi, poiché non sono progettati per lavorare con un orologio di sistema bloccato o uno che mostra l’anno come 1901.
Non ci sono soluzioni praticabili (che non rompano le applicazioni esistenti) per sistemi che usano processori a 32 bit, o sistemi operativi e applicazioni che funzionano in modalità 32 bit su processori a 64 bit. Molti degli attuali sistemi operativi Unix/Linux funzionano già in modalità a 64 bit (con un corrispondente time_t “lungo” quando su un processore a 64 bit; nella maggior parte dei casi questo risolve il problema.
I sistemi operativi che supportano un time_t lungo a 64 bit molto probabilmente non sono affetti dal bug dell’anno 2038 in termini di orologio di sistema interno. Tuttavia, le applicazioni che utilizzano un time_t a 32-bit possono ancora fallire, anche se il sistema che esegue l’applicazione supporta il funzionamento a 64-bit completo.
Ecco una rapida panoramica dello stato attuale del supporto Unix 2038 nelle versioni principali di Unix/Linux:
- Solaris 7 o superiore su processori UltraSPARC e SPARC64 a 64 bit, così come Solaris 10 su piattaforme x86-64, ha un time_t a 64-bit.
- AIX versione 4.3.3 su processori PowerPC e Power a 64 bit ha un time_t a 64 bit.
- Il kernel Linux che gira in modalità 64 bit su processori IA64 o x86-64 ha un time_t a 64 bit.
- Mac OS X versione 10.4 e successive ha un kernel a 32 bit, ma le applicazioni possono usare un time_t a 64 bit quando funzionano su CPU PowerPC G5 o x86-64.
- FreeBSD 6.0 e successive ha un time_t a 64 bit quando funziona su una piattaforma a 64 bit.
- OpenBSD 4.1 e successive supportano un time_t a 64 bit.
- NetBSD non ha ancora un time_t a 64 bit, ma sono in corso sforzi per risolvere il problema per una prossima release.
Anche se il vostro attuale sistema operativo non è ancora Unix 2038 sicuro, non preoccupatevi! Le persone sono consapevoli del problema da molti anni ormai, e stanno lavorando attivamente alle soluzioni. Nella maggior parte dei casi, il problema sarà risolto facendo in modo che il sistema operativo e le applicazioni alla fine girino in modalità completamente a 64 bit.
Mi aspetto che tutti i principali sistemi operativi desktop siano completamente a 64 bit nei prossimi cinque o dieci anni. Inoltre, un effetto trickle down aiuterà a sostituire i sistemi attuali con configurazioni a 64-bit dove è applicabile e conveniente.
CHI SIAMO: Bill Bradford è il creatore e manutentore di SunHELP e vive a Houston, Texas, con sua moglie Amy.