edición general
159 meneos
1105 clics

Linux 5.6 ya ha solucionado el problema del efecto 2038 para los 32 bits

Uno de los últimos commit del Kernel Linux incluye un parche desarrollado por Arnd Bergmann para solucionar este problema de manera definitiva. A grandes rasgos, el parche opta por eliminar las librerías time_t/timeval/timespec no utilizadas y recomendar a los desarrolladores compilar una nueva librería time_t preparada para registrar fechas más allá del 19 de enero del 2038.

| etiquetas: linux 5.6 , efecto 2038 , 32 bits
72 87 3 K 291 tecnología
48 comentarios
72 87 3 K 291 tecnología
Comentarios destacados:      
  1. ur_quan_master #1 ur_quan_master
    El 38 por fin imbatibles en el escritorio :foreveralone:
    5 K 49
  2. #2 EuropeoDespierto
    Si cambian la librería timeval y timespec el codigo dejara de funcionar de manera retroactiva no? Eso es una liada
    0 K 7
  3. zoezoe #3 zoezoe
    Efecto 2038 en menèame -> www.meneame.net/c/1318299 :troll:
    0 K 13
  4. elchacas #4 elchacas
    Yo soy más de la opinión de no dejar para mañana lo que puedas hacer pasado mañana.
    4 K 34
  5. Cidwel #5 Cidwel
    Que resuelvan ahora un problema del 2000. Mi kubuntu ultima no tiene función de hibernar.
    2 K 37
  6. elchacas #6 elchacas *
    #5 raro, ¿tienes tanta swap como ram?

    No he dicho nada, la swap es para suspender :-S , debería funcionar sí o sí

    systemctl hibernate quizá
    1 K 7
  7. Fingolfin #7 Fingolfin
    ...para procesadores de 32 bits, porque para los de 64 ya está preparado desde hace unas versiones. ¿Quien va a estar utilizando procesadores de 32 bits en 2038?
    1 K 17
  8. Cidwel #8 Cidwel
    #6 no, hay mucha gente quejándose de esto por los internet. Viene con hibernar desactivado. En mi caso ese comando que tu pones no hace nada mas que apagar la pantalla y volverla a mostrar al cabo de unos segundos.

    Estas cosas no pasaban cuando usaba ubuntu hace 10 años
    2 K 42
  10. Aokromes #10 Aokromes *
    #7 boeing esta planeando empezar a usarlos en 2038 :troll:
    1 K 14
  11. comadrejo #11 comadrejo *
    #9 Creo que no ha existido versión "resistente a la radiación" y con grado "ultra industrial" del 80286.

    en.wikipedia.org/wiki/IBM_System/4_Pi
    history.nasa.gov/computers/Ch4-3.html

    Si algún 80286 ha salido al espacio, creo que como mucho puede haber sido en un portátil y no sería en ningún sistema vital para la misión.
    0 K 7
  12. casius_clavius #12 casius_clavius
    #5 Llevo con Kubuntu un montón de años y la verdad, va casi todo muy bien, pero estoy hasta las narices de fallos estúpidos (algunos de los últimos años, y que además se repiten: deja de funcionar el DNS, la interfaz de red de desconecta constantemente, el teclado deja de funcionar de repente, Discovery se vuelve imbécil y no encuentra más actualizaciones nunca más, etc )
    0 K 17
  13. #13 --625430--
    #12 Prueba Solus OS Plasma.
    1 K 26
  15. Cidwel #15 Cidwel *
    #12 ayer instalé fedora kde. Si vuelvo a ver puta mierda glitchosa le follarán a linux para siempre. De momento me llevo la grata sorpresa de que el hibernar funciona

    Esto con la ubuntu de zapatero no pasaba
    1 K 28
  16. Jesulisto #16 Jesulisto
    #14 otro que se libra :-(
    1 K 9
  17. #17 --165145--
    Espero sacar tiempo para actualizar de aquí al 2038.
    0 K 17
  18. angelitoMagno #18 angelitoMagno
    #7 ¿Quien va a estar utilizando procesadores de 32 bits en 2038?
    Los linuxeros :troll:
    5 K 38
  19. pedrobz #19 pedrobz
    #9 Ese sigue sin ser un micro de 32 bits :troll:
    0 K 11
  20. #20 --375108--
    #5 estas cosas nunca han funcionado bien, pero ni en linux ni en Windows. Es lo que pasa cuando hay un estandar que todo el mundo se pasa por el forro de los cojones
    0 K 9
  21. insulabarataria #21 insulabarataria
    #8 hibernación sólo me funcionó bien en XP. Ni antes ni después me funcionó correctamente ni en windows ni en linux.
    0 K 7
  22. Black_Diamond #22 Black_Diamond
    #7 pues mira, ahora mismo hay mucha gente ejecutando simuladores de NES y spectrum para juegos, 35 años después de haberse diseñado. Aquellos ordenadores no tenían reloj, pero los pc modernos sí. Esto quiere decir que los pc modernos podrán ser emulados y tener la fecha del momento. Sin el parche no podrán ser emulados.
    0 K 10
  23. #23 rafael90 *
    #21 A mí me funciona perfectamente. Lo probé en sobremesas con XP y W10 sin problemas, donde sí lo usé un montón fue en mis portátiles con Windows 7, 8 y 10 (normal, ya vienen configurados para hibernar cuando la batería baja a niveles críticos). Nunca me han dado ningún problema.

    Donde sí he tenido problemas es con Linux, las veces que lo he probado. Por lo que tengo entendido, el problema es que los fabricantes no siguen los estandares de gestion de energía, lo cual da problemas en linux...
    0 K 11
  24. #24 portulo
    en el 2038 todos muertos por coronavirus...
    0 K 6
  25. anv #25 anv
    #6 No, al contrario. La swap es para hibernar. Para suspender no hace falta.
    2 K 28
  26. anv #26 anv
    #12 Prueba Mageia.
    1 K 26
  27. insulabarataria #27 insulabarataria
    #23 a mi una de las versiones de Ubuntu también me funcionó, pero ya te digo que fue por la época del XP-W7. Luego dejó de funcionar.
    0 K 7
  28. #28 --619432--
    #12 fallos estúpidos? si eso me pasara lanzaría el ordenador por la ventana
    1 K 25
  29. elchacas #29 elchacas *
    #25

    Hibernation (suspend-to-disk) The hibernation feature (suspend-to-disk) writes out the contents of RAM to the swap partition before turning off the machine. Therefore, your swap partition should be at least as big as your RAM size. Although the latest versions of Ubuntu don't support hibernation OOTB you may configure your system to allow Hibernation. In both alternatives (PM-UTILS or SYSTEMD) you may use a partition or a file.

    help.ubuntu.com/community/SwapFaq

    PD: yes, tienes razón, mejor no responder a las tantas a los comentarios...
    2 K 25
  30. SemosOsos #30 SemosOsos
    #7 routers, firewalls... En general muchos cacharros de infraestructura de red siguen usando arms/ppc/mips del año de la polca de 32b.
    4 K 27
  31. #31 --272073--
    #8 Es posible que el puerto USB(3) esté despertando al equipo. A mí me costó averiguar por que ni suspendía.
    1 K 15
  32. blid #32 blid
    #5 Y estamos en 2020.
    1 K 19
  33. #33 pcmaster
    #2 Pueden incorporar además de la librería antigua la nueva, y los programadores tienen 18 años para cambiar los programas. Cuando ya no se use la antigua, se elimina.
    1 K 15
  34. #34 fran89
    #12 prueba Manjaro Linux, basada en Arch
    2 K 26
  35. #35 Sr.Aracnido
    #8 #31 ¿Y cómo hacer para que no interfiera? Yo tengo el mismo problema con KDE neón...no hay huevos a suspender el sistema y termino apagando, lo cual es un coñazo.
    0 K 10
  36. #36 juanlinux
    y quien empleará un sitema de 32 bit en el año 2038? yo llevo en linux empleando sistemas de 64 bits desde el año 2004-2005, esta noticia debería ser irrelevante
    0 K 6
  37. #37 juanlinux
    #12 pues en Opensuse estas cosas ami no me han pasado desde el año de la polca, llevo empleándolo desde que salió la primera versión la 10.0 y antes suse y todo correcto
    1 K 26
  39. Gonzo345 #39 Gonzo345
    #2 Deprecated y alegría
    0 K 6
  40. #40 --8899--
    #2 Si lo entendí bien, si recompilas, no. Lo que han hecho es que en la libc, time_t es ahora de 64 bits, y las llamadas time y gettimeofday piden la versión de 64 bits, con lo que si, simplemente, recompilas, el problema del 2038 desaparece. Pero los binarios viejos de 32 bits que no han sido recompilados llaman a la versión vieja, que devuelve un valor de 32 bits, con lo que el cambio no les afecta.
    0 K 11
  41. #41 --8899--
    #9 Te di positivo por lo de la lavadora, pero el transbordador espacial nunca llevó 286, sino el AP-101, un derivado para aviónica del IBM 360: en.wikipedia.org/wiki/IBM_System/4_Pi

    A lo mejor te liaste con el 386, que se usaba en el glass cockpit que se instaló a finales de los 90 en los transbordadores.
    0 K 11
  42. Aokromes #42 Aokromes
    #36 boeing seguira usando un 286 :troll:
    0 K 7
  43. #43 --272073--
    #35 A mi me ocurre fuera de KDE. Pues sería cuestión de ver qué es lo que puede despertar al equipo con:
    cat /proc/acpi/wakeup | grep enable

    Y ver con lpsci qué es cada cosa. Obviamente no desactivar PBTN o similares puesto que dormiría para siempre.
    Y para USBs sería algo así:
    echo ECH1 > /proc/acpi/wakeup
    echo EHC2 > /proc/acpi/wakeup
    Para el 3.0
    echo XHC > /proc/acpi/wakeup

    Los cambios no son permanentes por lo que es conveniente crear un script que arranque en cada inicio.
    1 K 21
  44. garnok #44 garnok
    #2 el problema de que algún software no se actualice en 18 años creo que tendrá mucho menos que ver con el error del año 2038 a que ese software no se actualiza desde hace 18 años
    0 K 7
  45. javierchiclana #45 javierchiclana
    #6 ¿Tu SWAP es menor que la RAM? Por ahí podría venir el problema.
    0 K 15
  46. #46 --606024--
    #2 Diría que no porque si cambias el tipo de la variable (como por ejemplo de un int32_t a un int64_t) lo lógico es usar las funciones que usan esas variables también, por lo tanto al usarlo todo el conjunto no debería de haber fallos. El código antiguo que use esas variables y funciones debería de seguir funcionando correctamente tras recompilarse.
    0 K 6
  47. #47 --606024--
    #7 Cualquier sistema empotrado, y además bastante reciente.
    0 K 6
  48. Aokromes #48 Aokromes
    #44 bueno, recientemente ha habido el "efecto 2020" en muchos sitios que para "arreglar" el efecto 2000 se les ocurrio simplemente añadir 20 años mas con la esperanza de que en 20 años no se usarian mas xD
    pandorafms.com/blog/es/perl-2020/
    0 K 7
comentarios cerrados

menéame