¿Fallará el reloj de Linux el 19 de enero de 2038 3:14:08?
23
Estoy un poco preocupado por esto. Se llama el "problema del año 2038". ¿El kernel de Linux o Ubuntu está listo para manejar fechas posteriores a esta fecha, a partir de 12.04?
¿Has intentado ajustar tu reloj a algo así como el 19 de enero de 2038 3:14:07 y esperar un segundo?
gertvdijk
2
Supongamos que este problema existe y aún no se ha solucionado. 12.04 no será compatible para siempre, por lo que usted y todas las demás personas estarán en una distribución actualizada hasta que esto suceda, ya que hay muchos años entre ellos. La actualización es fácil. Una de estas actualizaciones seguramente contendrá una solución. Por lo tanto, no hay razón para preocuparse, pero esta es una pregunta interesante.
verpfeilt
3
El error ya estaba solucionado.
ThePiercingPrince
El reloj del sistema no lo hará (no en un núcleo razonablemente reciente de todos modos); Algunas estructuras de datos (y los programas que lo utilizan) pueden presentar un comportamiento anómalo. En mi opinión, esto será un problema con los dispositivos integrados: es mucho menos probable que ejecuten el código actual.
Piskvor
1
@hmayag: No estaba pensando en "tostadora", más bien como "controlador de semáforo". Esas cosas son un poco más resistentes que la electrónica de grado de consumo, y podrían exceder fácilmente esa vida útil (con reemplazos de piezas , pero posiblemente sin actualizaciones): IIRC, hubo algunos problemas con la electrónica de 1980 justo después de Y2K.
Piskvor
Respuestas:
13
No, no fallará. En el peor de los casos, desde el punto de vista de un programador, funcionará como se esperaba: se restablecerá hasta la fecha 1901-12-13 20:45:52:
Esto en caso de que no actualice sus distribuciones actuales hasta que esto suceda. " Actualizar es fácil. Una de estas actualizaciones seguramente contendrá una solución ", como dijo Chocobai .
Recuerdo que era el mismo problema / pregunta con las máquinas de 16 bits antes del 2000 y al final no hubo ningún problema.
Una solución de Wikipedia:
La mayoría de los sistemas operativos diseñados para ejecutarse en hardware de 64 bits ya usan time_tenteros de 64 bits con signo . El uso de un valor firmado de 64 bits introduce una nueva fecha de ajuste que es más de veinte veces mayor que la edad estimada del universo: aproximadamente 292 mil millones de años a partir de ahora, a las 15:30:08 del domingo 4 de diciembre de 292,277,026,596. La capacidad de realizar cálculos en fechas está limitada por el hecho de quetm_yearutiliza un valor int de 32 bits con signo a partir de 1900 para el año. Esto limita el año a un máximo de 2,147,485,547 (2,147,483,647 + 1900). Si bien esto resuelve el problema para ejecutar programas, no resuelve el problema de almacenar valores de fecha en archivos de datos binarios, muchos de los cuales emplean formatos de almacenamiento rígidos. Tampoco resuelve el problema para programas de 32 bits que se ejecutan bajo capas de compatibilidad y puede que no resuelva el problema para programas que almacenan incorrectamente valores de tiempo en variables de tipos distintos time_t.
Uso Ubuntu 13.04 en 64 bits y, por curiosidad, cambié manualmente la hora a 2038-01-19 03:13:00. Después de las 03:14:08 no había pasado nada:
Por lo tanto, no hay nada de qué preocuparse por este problema.
Si se restablece, falla porque por "falla" me refiero a "no funciona o funciona incorrectamente".
ThePiercingPrince
1
@LinuxDistance Esto sucede desde su punto de vista. Pero desde el punto de vista de un programador funcionará como se esperaba: se reiniciará . Fue lo mismo con el final del calendario maya: el mundo no falló debido a esto.
Radu Rădeanu
10
¿Estoy en desacuerdo? desde el punto de vista de un programador, se supone que un reloj no se reinicia, por lo que fallará
Nanne
3
Esta discusión en los comentarios no tiene sentido. La pregunta es "¿Está el kernel de Linux o Ubuntu listo para manejar las fechas después de esto?". Bueno, no es capaz de manejar tales fechas, por lo que falla en el contexto de esta pregunta.
gertvdijk
2
@gertvdijk "¿Está el kernel de Linux " actual / actual "o Ubuntu listo para manejar las fechas después de esto?"
Radu Rădeanu
7
Puede verificar si el tiempo de su computadora se bloqueará utilizando el siguiente script de Perl:
#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
print ctime($clock);
}
Si su computadora estará bien, obtendrá esto:
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
Si su computadora es como la mía, se ajustará así:
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
También podría hacer esto:
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
Creo que estás probando Perl aquí y no el sistema operativo real en el núcleo. ¿O eres tú, con el uso de ctime?
gertvdijk
@gertvdijk Bueno, da la primera salida en computadoras parcheadas, y mi computadora portátil Ubuntu da la segunda, mientras que la tercera es de mi servidor Debian. En realidad no escribí el código, está en todo Internet en la misma forma exacta.
SkylarMT
2
confirmado. Si tiene una máquina de 64 bits, entonces estará bien. Además ... ¿quién de nosotros tendrá máquinas de solo 32 bits que aún funcionen en el año 2038?
jrg
1
Busqué esto para ilustrar el problema de 2038 a un compañero de trabajo, y 2 años después de hacer el comentario anterior, tengo muy pocas dudas de que en 2038 tendremos máquinas de 32 bits que fallarán. Ah, optimismo juvenil.
jrg
@ James, tal vez algunos sin darse cuenta. Probablemente habrá Linux embebido de 32 bits en dispositivos IoT alrededor de ese momento, sin parchear. ¿Fin del mundo? No. ¿Algún problema en algunos lugares? Seguro.
Prof. Falken apoya a Monica el
3
Escribí y publiqué un breve artículo sobre esto en 1996. Esto incluyó un breve programa en C para demostrarlo. También recibí correos electrónicos con David Mills sobre problemas similares con NTP, el Protocolo de tiempo de red. En mi computadora portátil Ubuntu 14.04 de 64 bits, el código perl no exhibía la limitación, por lo que las bibliotecas subyacentes de 64 bits deben haberse modificado.
Sin embargo, ejecutar mi código de prueba de hace mucho tiempo muestra el tiempo de vuelta a la época de UNIX. Entonces, no todo está bien con el código de 32 bits del pasado.
Mi artículo de 1996, ¡ El tiempo de UNIX se acabará en 2038! ha estado en mi sitio web desde alrededor del año 2000. Una variante de este titulada "Tiempo UNIX" se publicó en 1998 en "Las mejores prácticas del año 2000 para la informática del milenio Y2K" ISBN 0136465064.
Linux de 64 bits está listo, al menos si está hablando de las interfaces principales del sistema operativo (las aplicaciones individuales, por supuesto, todavía pueden arruinarlo). time_t se define tradicionalmente como un alias para "long" y "long" en linux de 64 bits que es de 64 bits.
La situación para Linux de 32 bits (y la capa de compatibilidad para binarios de 32 bits en Linux de 64 bits) es mucho menos optimista. Está roto y arreglarlo sin romper todos los archivos binarios existentes no es una tarea fácil. Una gran cantidad de API usa time_t y, en muchos casos, está incrustado como parte de las estructuras de datos, por lo que no solo las API deben duplicarse, sino que también las estructuras de datos con las que trabajan.
Incluso si hay algún nivel de compatibilidad con versiones anteriores, será necesario reconstruir todos los binarios que deseen obtener la hora correcta para utilizar las nuevas interfaces de tiempo de 64 bits.
Respuestas:
No, no fallará. En el peor de los casos, desde el punto de vista de un programador, funcionará como se esperaba: se restablecerá hasta la fecha 1901-12-13 20:45:52:
Esto en caso de que no actualice sus distribuciones actuales hasta que esto suceda. " Actualizar es fácil. Una de estas actualizaciones seguramente contendrá una solución ", como dijo Chocobai .
Recuerdo que era el mismo problema / pregunta con las máquinas de 16 bits antes del 2000 y al final no hubo ningún problema.
Una solución de Wikipedia:
Uso Ubuntu 13.04 en 64 bits y, por curiosidad, cambié manualmente la hora a 2038-01-19 03:13:00. Después de las 03:14:08 no había pasado nada:
Por lo tanto, no hay nada de qué preocuparse por este problema.
Más sobre:
fuente
Puede verificar si el tiempo de su computadora se bloqueará utilizando el siguiente script de Perl:
Si su computadora estará bien, obtendrá esto:
Si su computadora es como la mía, se ajustará así:
También podría hacer esto:
fuente
ctime?Escribí y publiqué un breve artículo sobre esto en 1996. Esto incluyó un breve programa en C para demostrarlo. También recibí correos electrónicos con David Mills sobre problemas similares con NTP, el Protocolo de tiempo de red. En mi computadora portátil Ubuntu 14.04 de 64 bits, el código perl no exhibía la limitación, por lo que las bibliotecas subyacentes de 64 bits deben haberse modificado.
Sin embargo, ejecutar mi código de prueba de hace mucho tiempo muestra el tiempo de vuelta a la época de UNIX. Entonces, no todo está bien con el código de 32 bits del pasado.
Mi artículo de 1996, ¡ El tiempo de UNIX se acabará en 2038! ha estado en mi sitio web desde alrededor del año 2000. Una variante de este titulada "Tiempo UNIX" se publicó en 1998 en "Las mejores prácticas del año 2000 para la informática del milenio Y2K" ISBN 0136465064.
fuente
Linux de 64 bits está listo, al menos si está hablando de las interfaces principales del sistema operativo (las aplicaciones individuales, por supuesto, todavía pueden arruinarlo). time_t se define tradicionalmente como un alias para "long" y "long" en linux de 64 bits que es de 64 bits.
La situación para Linux de 32 bits (y la capa de compatibilidad para binarios de 32 bits en Linux de 64 bits) es mucho menos optimista. Está roto y arreglarlo sin romper todos los archivos binarios existentes no es una tarea fácil. Una gran cantidad de API usa time_t y, en muchos casos, está incrustado como parte de las estructuras de datos, por lo que no solo las API deben duplicarse, sino que también las estructuras de datos con las que trabajan.
Incluso si hay algún nivel de compatibilidad con versiones anteriores, será necesario reconstruir todos los binarios que deseen obtener la hora correcta para utilizar las nuevas interfaces de tiempo de 64 bits.
Se ha realizado algún trabajo (ver, por ejemplo, https://lwn.net/Articles/643234/ y http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ) pero cometemos todavía están muy lejos de una solución completa. No está claro si alguna vez habrá distribuciones de 32 bits de uso general que sean seguras para Y2K38.
fuente