RPi soffrirà del bug Y2K38?

Solo per curiosità, cosa succederà ai modelli A e B di RPis il 19 gennaio 2038 alle 3:14:07 GMT? Sono interessati dal bug Y2K38 ?

hardware system-clock bugs

— DaGhostman Dimitrov
fonte

Quanti ti aspetti che siano ancora in esecuzione allora?

— Thorbjørn Ravn Andersen,

@ ThorbjørnRavnAndersen a dire il vero credo che l'RPi abbia un grande futuro e ce ne saranno molti ancora in esecuzione (eventualmente modelli C o superiori ma ..)

— DaGhostman Dimitrov

In tal caso, impostare l'orologio e vedere.

— Thorbjørn Ravn Andersen,

Non ho pensato a questo ...: D

— DaGhostman Dimitrov il

Qualunque sia il futuro del PI, è probabile che né esso né nient'altro utilizzeranno ancora un processore a 32 bit tra 25 anni. Come per Wikipedia, i sistemi a 64 bit usano un 64-bit time_t, trasformandolo in un problema Y292G , che né noi né il sole vivremo per vedere.

— riccioli d'oro

Risposte:

Sì.

Ecco l'output di una sessione SSH sul mio Pi che esegue OpenELEC.

Si blocca dopo aver raggiunto Y2K38. Non solo la sessione SSH stessa smette di rispondere, ma anche OpenELEC si blocca.

Mi aspetto (e spero!) Che entro il 2038 sarà stata rilasciata una correzione.

^{Quello, o la tua domanda otterrà molti voti in 24 anni.}

inserisci qui la descrizione dell'immagine

— Quel ragazzo brasiliano
fonte

Sono sorpreso che tu sia riuscito ad aprire una sessione SSH con una macchina con una data così folle. +1 per averlo provato, però.

— einnocent,

@einnocent Perché non dovrei essere in grado? C'è qualche tipo di confronto temporale sulle specifiche di handshaking SSH che lo impedirebbe? Inoltre, ho cambiato il tempo dopo aver stabilito la connessione. Inoltre, l'orologio Pi era già sbagliato (di alcuni mesi, anni, non ricordo): P

— Quel ragazzo brasiliano il

Cambiando il tempo di pre-connessione, capisco che grandi differenze nell'orologio possono causare problemi con alcuni handshake di sicurezza, anche se non conosco SSH in particolare. Con una modifica post-connessione, potrei immaginare che SSH si sia impazzito all'improvviso scoprendo che aveva una connessione aperta per 34 anni. Suppongo che ci sia una piccola (ma diversa da zero) possibilità che SSH abbia semplicemente terminato la connessione in quel momento magico. Ma sono davvero convinto della tua risposta :)

— einnocent il

@einnocent Non mi è venuto in mente che SSH potesse pensare che fosse "aperto per 24 anni" e appendere. Proverò ancora, diciamo, 22 anni. Ma penso che non sia la causa, perché si blocca esattamente al raggiungimento di Y2K38

— Quel ragazzo brasiliano il

In realtà il Raspberry Pi (hardware) andrà bene. Non contiene un RTC, quindi dipenderà dal sistema operativo in uso.

Ma IIRC per tutte le versioni a 32 bit di Linux presenta questo problema. Qualche tempo fa (circa 10 anni) Linus ha affermato di non essere interessato a risolvere questo problema su piattaforme a 32 bit e tutte le piattaforme Linux a 64 bit al momento avevano 64 bit time_t. Da allora, forse, ha cambiato idea. Il miglior link che posso trovare è http://permalink.gmane.org/gmane.linux.kernel/1184914 - che non è lo stesso, ma esprime un intento simile.

Non sarà una cosa particolarmente difficile da cambiare, ma forzerebbe un cambiamento nelle ABI del kernel. Qual è un problema in sé.

Ma RiscOs utilizza un tempo di 40 bit (centisecondi), ma con un'epoca diversa. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - Faccio questo errore nel 2318 - [calc era: 1970 + ((2 ^ 40) / 100) / (60 * 60 * 24 * 365,25)]

Android, ovviamente, usa il kernel Linux. E sono sicuro di aver perso altre opzioni.

— rgammans
fonte

Come è attualmente implementato, il Raspberry Pi subirà il destino del bug elencato, se non vengono apportate modifiche al software.

La maggior parte delle macchine moderne sta passando ai processori a 64 bit, ma non sarei affatto sorpreso di vedere ancora i processori mainstream a 32 bit a quel punto. Esistono soluzioni software che potrebbero e dovranno risolvere il problema.

Mi sembra che la soluzione più probabile sarebbe quella di aggiornare il tempo Epoch per iniziare a qualcosa come il 1 ° gennaio 2000. Anche se questo non ritarderebbe il bug, lo ripristinerebbe sicuramente per il prossimo futuro.

— Jacobm001
fonte