L'orologio Linux non funzionerà il 19 gennaio 2038 3:14:08?

23

Sono un po 'preoccupato per questo. Si chiama "problema dell'anno 2038". Il kernel di Linux o Ubuntu è pronto per gestire le date successive, a partire dal 12.04?

time

— ThePiercingPrince
fonte

8

Hai provato a impostare l'orologio su qualcosa come 19 gennaio 2038 3:14:07 e aspettare un secondo?

— gertvdijk,

2

Supponiamo che questo problema esista e non sia stato ancora risolto. 12.04 non sarà supportato per sempre, quindi tu e tutte le altre persone sarete su una distribuzione aggiornata fino a quando ciò non accadrà, poiché ci sono molti anni tra. L'aggiornamento è facile. Uno di questi aggiornamenti conterrà sicuramente una correzione. Quindi non c'è motivo di preoccuparsi, ma questa è davvero una domanda interessante.

— verpfeilt,

3

Il bug era già stato corretto.

— ThePiercingPrince

L'orologio di sistema non funzionerà (comunque non su un kernel abbastanza recente); alcune strutture di dati (e i programmi che la utilizzano) potrebbero presentare comportamenti anomali. A mio avviso, questo sarà un problema con i dispositivi integrati: è molto meno probabile che eseguano il codice corrente.

— Piskvor,

1

@hmayag: non stavo pensando "tostapane", più come "controller semaforo". Quelle cose sono un po 'più robuste dell'elettronica di consumo e potrebbero facilmente superare quella durata (con sostituzioni di parti , ma forse senza aggiornamenti) - IIRC, ci sono stati alcuni problemi con l'elettronica degli anni '80 subito dopo Y2K.

— Piskvor,

13

No, non fallirà. Nel peggiore dei casi, dal punto di vista di un programmatore funzionerà come previsto: verrà reimpostato ad oggi 1901-12-13 20:45:52:

inserisci qui la descrizione dell'immagine

Questo nel caso in cui non aggiornerai le tue attuali distribuzioni fino a quando ciò non accadrà. "L' aggiornamento è facile. Uno di questi aggiornamenti conterrà sicuramente una soluzione ", come ha affermato Chocobai .

Ricordo che era lo stesso problema / domanda con le macchine a 16 bit prima del 2000 e alla fine non c'erano problemi.

Una soluzione da Wikipedia:

La maggior parte dei sistemi operativi progettati per essere eseguiti su hardware a 64 bit utilizzano già time_tnumeri interi a 64 bit con segno. L'uso di un valore a 64 bit con segno introduce una nuova data avvolgente che è oltre venti volte maggiore dell'età stimata dell'universo: circa 292 miliardi di anni da oggi, alle 15:30:08 di domenica 4 dicembre 292.277.026.596. La capacità di effettuare calcoli in date è limitata dal fatto chetm_yearutilizza un valore int a 32 bit con segno a partire da 1900 per l'anno. Ciò limita l'anno a un massimo di 2.147.485.547 (2.147.483.647 + 1900). Sebbene ciò risolva il problema dell'esecuzione dei programmi, non risolve il problema della memorizzazione dei valori di data all'interno di file di dati binari, molti dei quali utilizzano formati di archiviazione rigidi. Inoltre, non risolve il problema per i programmi a 32 bit in esecuzione con livelli di compatibilità e potrebbe non risolvere il problema per i programmi che archiviano erroneamente i valori temporali in variabili di tipo diverso da time_t.

Uso Ubuntu 13.04 a 64 bit e, per curiosità, ho cambiato manualmente l'ora in 2038-01-19 03:13:00. Dopo 03:14:08 non era successo nulla:

Data e ora prima del 2038-01-19 03:14:08 Data e ora dopo il 2038-01-19 03:14:08

Quindi non c'è nulla di cui preoccuparsi per questo problema.

Di più:

— Radu Rădeanu
fonte

9

Se si ripristina, non riesce perché per "errore" intendo "non funziona o non funziona correttamente".

— ThePiercingPrince

1

@LinuxDistance Questo accade dal tuo punto di vista. Ma dal punto di vista di un programmatore funzionerà come previsto: verrà ripristinato . Era lo stesso con la fine del calendario Maya: il mondo non ha fallito per questo.

— Radu Rădeanu,

10

Non sono d'accordo? dal punto di vista di un programmatore un orologio non dovrebbe reset, in modo che sarà fallire

— Nanne

3

Questa discussione nei commenti è inutile imo. La domanda è "Il kernel Linux o Ubuntu è pronto a gestire le date successive?". Bene, non è in grado di gestire tali date, quindi fallisce nel contesto di questa domanda.

— gertvdijk,

2

@gertvdijk "Il kernel Linux " attuale / attuale "o Ubuntu è pronto a gestire le date successive?"

— Radu Rădeanu,

7

Puoi verificare se l'ora del tuo computer si bloccherà usando il seguente script Perl:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

Se il tuo computer andrà bene, otterrai questo:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Se il tuo computer è come il mio, si avvolgerà così:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Potrebbe anche fare questo:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

— SkylarMT
fonte

Penso che tu stia testando Perl qui e non il vero sistema operativo nel core. O lo sei, con l'uso di ctime?

— gertvdijk,

@gertvdijk Bene, dà il primo output su computer con patch, e il mio laptop Ubuntu dà il secondo, mentre il terzo proviene dal mio server Debian. In realtà non ho scritto il codice, è tutto su Internet nella stessa forma esatta.

— SkylarMT,

2

confermato. se hai una macchina a 64 bit, allora andrà bene. Inoltre ... chi di noi avrà ancora macchine a 32 bit ancora in funzione nell'anno 2038?

— jrg

1

Ho cercato questo per illustrare il problema del 2038 a un collega e 2 anni dopo aver fatto il commento sopra, ho pochi dubbi sul fatto che nel 2038 avremo macchine a 32 bit che falliranno. Ah, ottimismo giovanile.

— jrg

@James, forse un po 'inconsapevolmente. All'epoca probabilmente ci saranno Linux a 32 bit incorporati nei dispositivi IoT, senza patch. Fine del mondo? No. Qualche problema in alcuni posti? Decisamente.

— prof. Falken sostiene Monica il

3

Ho scritto e pubblicato un breve articolo su questo nel 1996. Questo includeva un breve programma C per dimostrarlo. Ho anche ricevuto e-mail con David Mills su problemi simili con NTP, il Network Time Protocol. Sul mio laptop Ubuntu 14.04 a 64 bit il codice perl non presentava la limitazione, quindi le librerie a 64 bit sottostanti devono essere state modificate.

Tuttavia, l'esecuzione del mio codice di test di lunga data mostra che il tempo ritorna all'epoca UNIX. Quindi non tutto va bene con il codice a 32 bit del passato.

Il mio articolo del 1996, The UNIX time scadrà nel 2038! è sul mio sito web da circa 2000. Una variante di questo "UNIX Time" è stata pubblicata nel 1998 in "Anno 2000 Best Practices for Y2K Millennium Computing" ISBN 0136465064.

— oldunixguy
fonte

2

Linux a 64 bit è pronto, almeno se stai parlando delle interfacce del sistema operativo principale (le singole applicazioni possono ovviamente rovinarlo ancora). time_t è tradizionalmente definito come un alias per "long" e "long" su Linux a 64 bit è 64-bit.

La situazione per Linux a 32 bit (e il livello di compatibilità per i binari a 32 bit su Linux a 64 bit) è molto meno roseo. È rotto e ripararlo senza rompere tutti i file binari esistenti non è un compito facile. Un sacco di API usa time_t e in molti casi è incorporato come parte delle strutture di dati, quindi non solo le API devono essere duplicate, ma anche le strutture di dati con cui lavorano.

Anche se esiste un certo livello di compatibilità con le versioni precedenti, tutti i binari che desiderano ottenere l'ora corretta dovranno essere ricostruiti per utilizzare le nuove interfacce temporali a 64 bit.

C'è stato un po 'di lavoro svolto (vedi ad esempio https://lwn.net/Articles/643234/ e http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ) ma abbiamo già accettato sono ancora lontani da una soluzione completa. Non è chiaro se ci saranno mai distribuzioni a 32 bit di uso generale che sono sicure per Y2K38.

— Peter Green
fonte