Il 03:14:08 Greenwich Mean Time (GMT, aka Coordinated Universal Time) 19 gennaio 2038 (che è un martedì), il mondo finisce. Beh, non nel senso biblico del Libro dell’Apocalisse. Ma, quello che accadrà è che il valore del tempo nei sistemi operativi basati su Unix a 32 bit, come Linux e le vecchie versioni di macOS, finisce i numeri e inizia a contare il tempo con numeri negativi. Questo non va bene. Possiamo aspettarci che i computer a 32-bit che eseguono questi sistemi operativi abbiano delle crisi. Fortunatamente, gli sviluppatori di Linux avevano già una correzione pronta a partire.
Il problema inizia con il modo in cui Unix racconta il tempo. Unix, e le sue relazioni — Linux, macOS, e altri sistemi operativi compatibili con POSIX — datano l’inizio del tempo dall’Epoca: 00:00:00 GMT del 1 gennaio 1970. La famiglia Unix misura il tempo in base al numero di secondi dall’Epoca.
Fin qui tutto bene. Ma, poiché Unix e famiglia hanno iniziato come sistemi operativi a 32 bit, il valore del tempo è mantenuto come un singolo numero intero firmato a 32 bit. Sono un sacco di secondi, ma proprio come il bug Y2K del secolo scorso, non è abbastanza.
Gli sviluppatori Linux hanno visto questo arrivare per decenni. Così, lo sviluppatore del kernel Linux Arnd Bergmann e altri hanno lavorato a una riparazione. Queste correzioni sono ora nel prossimo kernel Linux 5.6. Bergmann ha spiegato: “Linux-5.6, o il mio backport delle patch alla 5.4, dovrebbe essere la prima release che può servire come base per un sistema a 32 bit progettato per funzionare oltre l’anno 2038.”
Ci sono alcuni avvertimenti:
- Tutto lo spazio utente deve essere compilato con un time_t a 64 bit, che sarà supportato nei prossimi musl-1.2 e glibc-2.32, insieme agli header del kernel installati da Linux-5.6 o superiore.
- Le applicazioni che usano direttamente le interfacce delle chiamate di sistema devono essere portate ad usare le syscalls time64 aggiunte in Linux-5.1 al posto delle chiamate di sistema esistenti.
- Le applicazioni che usano una copia privata dei file header uapi del kernel o il loro contenuto potrebbero aver bisogno di aggiornare alla versione di Linux-5.6.
- Alcune interfacce rimanenti non possono essere modificate per passare un time_t a 64 bit in modo compatibile, quindi devono essere configurate per usare tempi CLOCK_MONOTONIC.
- Tutti i problemi Epoch presenti sulle macchine a 64 bit si applicano anche alle macchine a 32 bit. In particolare questo colpisce i file system con timestamp su disco che usano secondi firmati a 32 bit: ext4 con inode piccoli in stile ext3, ext2, xfs (che sarà corretto presto) e ufs.
In breve, c’è un sacco di lavoro di pulizia da fare anche dopo che il problema principale è stato risolto.
MacOS si sta allontanando dal software a 32 bit da oltre un decennio. Ma, tt è stato solo nel tardo 2019 rilascio di macOS Catalina, che Apple ha dato 32-bit apps l’avvio.
Ora, vi starete chiedendo – dal momento che stiamo tutti eseguendo computer a 64 bit in questi giorni – perché questo è anche un problema. Beh, è così. In primo luogo, molti sistemi embedded e dispositivi Internet of Things (IoT) stanno ancora eseguendo sistemi operativi a 32 bit. Infatti, entro il 2038, ci saranno probabilmente ancora nuovi dispositivi a 32-bit in arrivo sul mercato.
Sappiamo anche, grazie al bug Y2K che spunterà di nuovo nel 2020, che i sistemi che si potrebbe supporre saranno gettati nelle discariche tra 18 anni saranno ancora vivi e vegeti — e si comporteranno male quando arriverà l’Epoca.
Ma guardate in questo modo: Dopo aver sistemato questo, non dovremo preoccuparci che Linux a 64 bit finisca i secondi fino alle 15:30:08 GMT di domenica 4 dicembre, 29.227.702.659. Personalmente, non ho intenzione di preoccuparmi di questo.
Storie correlate:
- Il bug Y2K è tornato, causando di nuovo mal di testa per gli sviluppatori
- Il governo della Corea del Sud esplora il passaggio da Windows a Linux desktop
- Nasty Linux, macOS sudo bug trovato e risolto
