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.
#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.
#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.
#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
#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 https://pandorafms.com/blog/es/perl-2020/
#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.
#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
#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...
#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.
#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.
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.
#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 )
#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
#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
#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
...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?
#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: https://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.
#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.
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
Comentarios
El 38 por fin imbatibles en el escritorio
Si cambian la librería timeval y timespec el codigo dejara de funcionar de manera retroactiva no? Eso es una liada
#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.
#2 Deprecated y alegría
#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.
#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
#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
https://pandorafms.com/blog/es/perl-2020/
#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.
Efecto 2038 en menèame -> ¿Es Linux compatible con Y2K(38)?/c6#c-6
Yo soy más de la opinión de no dejar para mañana lo que puedas hacer pasado mañana.
Que resuelvan ahora un problema del 2000. Mi kubuntu ultima no tiene función de hibernar.
#5 raro, ¿
tienes tanta swap como ram?No he dicho nada, la swap es para suspender , debería funcionar sí o sí
systemctl hibernate quizá
#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
#8 hibernación sólo me funcionó bien en XP. Ni antes ni después me funcionó correctamente ni en windows ni en linux.
#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...
#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.
#8 Es posible que el puerto USB(3) esté despertando al equipo. A mí me costó averiguar por que ni suspendía.
#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.
#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.
#6 No, al contrario. La swap es para hibernar. Para suspender no hace falta.
#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.
https://help.ubuntu.com/community/SwapFaq
PD: yes, tienes razón, mejor no responder a las tantas a los comentarios...
#6 ¿Tu SWAP es menor que la RAM? Por ahí podría venir el problema.
#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 )
#12 Prueba Solus OS Plasma.
#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
#12 Prueba Mageia.
#12 fallos estúpidos? si eso me pasara lanzaría el ordenador por la ventana
#12 prueba Manjaro Linux, basada en Arch
#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
#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
#5 Y estamos en 2020.
...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?
#7 El controlador cutre de la lavadora.
El transbordador espacial usaba procesadores 80286.
#9 Creo que no ha existido versión "resistente a la radiación" y con grado "ultra industrial" del 80286.
https://en.wikipedia.org/wiki/IBM_System/4_Pi
https://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.
#9 Ese sigue sin ser un micro de 32 bits
#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: https://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.
#7 boeing esta planeando empezar a usarlos en 2038
#7 ¿Quien va a estar utilizando procesadores de 32 bits en 2038?
Los linuxeros
#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.
#7 routers, firewalls... En general muchos cacharros de infraestructura de red siguen usando arms/ppc/mips del año de la polca de 32b.
#7 Cualquier sistema empotrado, y además bastante reciente.
Yo no lo voy a ver.
#14 otro que se libra
Espero sacar tiempo para actualizar de aquí al 2038.
en el 2038 todos muertos por coronavirus...
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
#36 boeing seguira usando un 286
Sus 10 usuarios estarán dando saltos de alegría.