¿RPi sufrirá el error Y2K38?

Solo por curiosidad, ¿qué pasará con los modelos RPis A y B el 19 de enero de 2038 en 3:14:07 GMT? ¿Están afectados por el error Y2K38 ?

hardware system-clock bugs DaGhostman Dimitrov
fuente

¿Cuántos esperas que sigan funcionando entonces?

Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen, para ser honesto, creo que el RPi tiene un gran futuro y habrá muchos de ellos aún en ejecución (eventualmente modelos C o superiores, pero ...)

DaGhostman Dimitrov

En ese caso, ajuste el reloj y vea.

Thorbjørn Ravn Andersen

No he pensado en eso ..: D

DaGhostman Dimitrov

Cualquiera que sea el futuro del pi, es probable que ni él ni ninguna otra cosa sigan usando un procesador de 32 bits en 25 años. Según wikipedia, los sistemas de 64 bits usan uno de 64 bits time_t, convirtiéndolo en el problema Y292G , que ni nosotros ni el sol viviremos para ver.

Ricitos de oro

Respuestas:

Si.

Aquí está el resultado de una sesión SSH para mi Pi que ejecuta OpenELEC.

Se cuelga después de llegar a Y2K38. No solo la sesión SSH misma deja de responder, sino que OpenELEC también se congela.

Espero (¡y espero!) Que para 2038 se haya lanzado una solución.

^{Eso, o su pregunta recibirá muchos votos positivos en 24 años.}

ingrese la descripción de la imagen aquí

Ese chico brasileño
fuente

Me sorprende que hayas podido abrir una sesión SSH con una máquina con una fecha tan descabellada. +1 por probarlo realmente.

inocente

@einnocent ¿Por qué no podría? ¿Hay algún tipo de comparación de tiempo en las especificaciones de apretón de manos SSH que lo impida? Además, he cambiado la hora después de que se estableció la conexión. Además, el reloj Pi ya estaba mal de todos modos (por unos meses, años, no recuerdo): P

Ese tipo brasileño

Cambiando la pre-conexión de tiempo, entiendo que las grandes diferencias en los tiempos de reloj pueden causar problemas con algunos apretones de manos de seguridad, aunque no sé sobre SSH en particular. Con un cambio posterior a la conexión, me imaginaba que SSH se volvía loco al descubrir que tenía una conexión abierta durante 34 años. Supongo que hay una pequeña (pero no nula) posibilidad de que SSH simplemente termine la conexión en ese momento mágico. Pero realmente estoy convencido con tu respuesta :)

inocente

@einnocent No se me ocurrió que SSH podría pensar que estaba "abierto durante 24 años" y colgar. Lo intentaré nuevamente con, digamos, 22 años. Pero creo que no es la causa, porque se cuelga exactamente al llegar a Y2K38

ese chico brasileño el

En realidad, el Raspberry Pi (hardware) estará bien. No contiene un RTC, por lo que dependerá del sistema operativo que utilice.

Pero IIRC todas las versiones de 32 bits de Linux tienen este problema. Hace algún tiempo (10 años más o menos), Linus dijo que no estaba interesado en arreglar esto en plataformas de 32 bits y todas las plataformas Linux de 64 bits en ese momento tenían 64 bits de time_t. Puede que haya cambiado de opinión desde entonces, por supuesto. El mejor enlace a esto que puedo encontrar es http://permalink.gmane.org/gmane.linux.kernel/1184914 , que no es lo mismo, pero expresa una intención similar.

No será algo particularmente difícil de cambiar, pero forzaría un cambio en las ABI del núcleo. Lo cual es un problema en sí mismo.

Pero, RiscOs usa un tiempo de 40 bits (centisegundo), pero con una Época diferente. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - Hago ese fallo en algún momento en 2318 - [calc fue: 1970 + ((2 ^ 40) / 100) / (60 * 60 * 24 * 365.25)]

Android, por supuesto, usa el kernel de Linux. Y estoy seguro de que me he perdido otras opciones.

rgammans
fuente

Como se implementa actualmente, la Raspberry Pi sufrirá el destino del error enumerado, si no se realizan cambios en el software.

La mayoría de las máquinas modernas están dando el salto a los procesadores de 64 bits, pero no me sorprendería en absoluto ver todavía procesadores incorporados de 32 bits en ese momento. Hay soluciones de software que podrían y tendrán que resolver el problema.

Me parece que la solución más probable sería actualizar Epoch time para comenzar en algo así como el 1 de enero de 2000. Si bien esto no retrasaría el error, sin duda lo restablecería en el futuro previsible.

Jacobm001
fuente