Quanti di voi erano già operativi nell’anno 2000 o poco prima? In quel periodo scattò la paura del cambio di millennio, ed insieme ad essa il pensiero che il problema Y2K, che venne per l’appunto definito Millennium Bug, mettesse tutto il mondo, informatico e non, al tappeto.
Per i più piccini un veloce riassunto: il Millennium Bug si riferisce alle date memorizzate in campi da sei caratteri anziché otto, per le quali quindi veniva dato per scontato il ventesimo secolo, e che con l’arrivo dell’anno 2000 rischiarono di mandare in confusione i sistemi software che le interpretavano. Pensate ad una persona nata il primo gennaio del 1900 che nel 2000 non si vedeva più riconoscere la pensione nonostante avesse compiuto cent’anni, poiché al sistema risultava ne avesse… Meno di uno!
Ad onor del vero fu più rumore che altro, non successe assolutamente nulla, a parte qualche caso sporadico di voli cancellati, ritardi nei call-center e, forse il più eclatante, il rischio di fermo di un paio di reattori nucleari in Svezia.
Bene, ventiquattro anni dopo c’è un altro problema simile a cui far fronte, ossia il 2038 Bug, o Y2K38 Bug, per gli amici.
Ne sono affetti i sistemi che utilizzano le variabili di tipo time_t, altrimenti detto Unix timestamp, o epoch che rappresenta il numero di secondi passati dal primo gennaio del 1970, idealmente la data del primo rilascio di Unix (da qui uno dei suoi nomi).
Ora, perché il 2038? Perché dopo il 19 gennaio 2038 il tipo in questione comincerà a conteggiare nuovamente da zero, causando potenziali errori nei calcoli del tempo e nei sistemi che dipendono dalla rappresentazione temporale corretta. Come avevamo raccontato a suo tempo, ecco un’immagine reperibile su Wikipedia che illustra in maniera chiarissima il problema:
La soluzione? Usare una variabile a 64 bit anziché a 32, ed è ciò che è stato implementato nel Kernel Linux dal Kernel 5.6, già da diversi anni.
Ma non di solo Kernel vive l’uomo, ed infatti il progetto Debian ha annunciato l’introduzione di time_t a 64 bit a partire dalla prossima unstable, la versione in sviluppo del sistema operativo su cui un abnorme numero di distribuzioni Linux è basato.
L’annuncio è stato dato all’interno nelle Debian micronews e fa riferimento ad un messaggio apparso sulla mailing list del progetto.
Nel progetto Debian l’attività è tracciata in una pagina dedicata dei Debian Release Goals, e viene da sé come la problematica in questione riguardi sostanzialmente tutte le distribuzioni, pertanto sebbene siamo più che nei tempi, prima o dopo annunci simili saranno attesi anche da parte di altri.
Chissà se alle 03:14:07 del 19 Gennaio 2038 qualche orologio, servizio o sistema in un attimo si ritroverà a fare un salto nel tempo, alle 20:45:52 del 13 Dicembre 1901.
In quel caso la soluzione diventerà una ed una soltanto:
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
English (US)