Eli
254meneos

¿Es Linux compatible con Y2K(38)?

De acuerdo a www.y2k38.info, todos los sitemas Unix/Linux 32bit, en sus actuales estados, llegarán a su fín el 19 de Enero de 2038 (Y2K38). Esto es debído al hecho de que los sistemas *nix llevan un registro del tiempo en un entero de 4 bytes que corresponde al número de segundos después del 1 de Enero de 1970. El máximo valor de un entero de 4 bytes es 2,146,483,547 el cual es equivalente al 19 de Enero de 2038.

 47 comentarios en: tecnología, software libre karma: 868
etiquetas: linux, unix, y2k(38)
votos negativos: 12  usuarios: 178  anónimos: 76  
  1. #1   Como que en el 2038 vamos a estar usando todavía sistemas 32-bit :roll:
    votos: 22, karma: 177
    por Kartoffel el 30-12-2007 19:06
  2. #2   Tu no #1. Pero la cantidad de cacharros que hay por ahi (switches, routers, televisiones, marcos digitales, reproductores de divx, neveras, etc. etc) con un Linux embedded...

    "El máximo valor de un entero de 4 bytes es 2,146,483,547"

    El valor máximo de un entero CON SIGNO de 32 bits es 2,147,483,647. (2^31 - 1)
    votos: 20, karma: 179
    por JackDaniels el 30-12-2007 19:10
  3. #3   #1 eso se decía en los años 60, y mira :-p

    De todas maneras no me acabo de creer lo que dice la web: o estoy muy equivocado, o las distros actuales almacenan la fecha en 64 bits desde hace bastantes años.

    Los problemas se darán con máquinas antiguas o con chips empotrados (a los que es muy difícil actualizar el firmware).
    votos: 14, karma: 149
    por DZPM el 30-12-2007 19:11
  4. #4   #2 esos aparatos YA están programados para durar 2 o 3 años, no me jodas xD
    votos: 32, karma: 300
    por jotape el 30-12-2007 19:16
  5. #5   #3 cualquier programa corriente y moliente utiliza el tipo de datos "time_t", que en un sistema de 32 bits acaba siendo un int.

    Peor aún, muchos programas no utilizan el time_t para almacenar la fecha y lo hacen con int directamente.
    votos: 7, karma: 81
    por JackDaniels el 30-12-2007 19:16
  6. #6   Algo más sobre el asunto en español... es.wikipedia.org/wiki/Problema_del_año_2038

    #5 ahora en serio, si de aquí al 2038 no hemos pasado a 64 bits tenemos un problema como civilización xD
    votos: 23, karma: 241
    por jotape el 30-12-2007 19:21
  7. #7   #6 ¿quedan solo 30 años eh? xD

    Tambien hay que migrar a IPv6, a HDTV... no se yo si dará tiempo a tanto cambio.
    votos: 18, karma: 175
    por JackDaniels el 30-12-2007 19:24
  8. #8   También está el problema del año 2070... en.wikipedia.org/wiki/Year_2070_problem
    Pero para esa fecha, no creo que esté yo por aquí :-P
    votos: 6, karma: 68
    por lurker el 30-12-2007 19:25
  9. #9   #7 Al HDTV le queda bastante tiempo... con que pasemos a TDT me sentiré satisfecho. Y luego veremos que pasa con el ancho de banda del espectro radioeléctrico como para ver si se podrá pasar a HDTV.
    votos: 1, karma: 18
    por lurker el 30-12-2007 19:27
  10. #10   Yo utilizo un sistema de 64 bits hoy, a mi me la suda...si quereis probar el efecto, poned la fecha momentaneamente a 31 de diciembre de 2037 a las 11:59. Aquí no he tenido ningún problema, excepto tener que hacer login de nuevo para entrar en meneame, y una expiración de certificado en firefox.

    De todas maneras hay que destacar que este no es un problema de Linux, sino del hardware. Los procesadores de 32 bits no pueden incrementar de forma atómica un número mayor de 32 bits, todo lo que se haga para solucionar este problema por software será una chapuza.
    votos: 6, karma: 75
    por diegocg el 30-12-2007 19:38
  11. #11   Otro fake como el YK2000? venga ya.
    votos: 12, karma: -27
    por birdy el 30-12-2007 19:42
  12. #12   #10 en realidad pasaría algo más tarde, las 3:14:07 serán el último segundo computable con 32 bits ;-)
    votos: 2, karma: 37
    por jotape el 30-12-2007 19:42
  13. #13   Siento amargaros la fiesta, pero es antigua y triplicada:

    meneame.net/story/19-enero-2038-03-14-07-fin-mundo-otra-vez
    meneame.net/story/el-efecto-2038
    meneame.net/story/19-01-2007-31-anos-efecto-2038
    votos: 39, karma: 317
    por perl el 30-12-2007 19:42
  14. #14   #13 Ditto...
    votos: 4, karma: 44
    por lurker el 30-12-2007 19:43
  15. #15   #13 Aguafiestas :D
    votos: 7, karma: 86
    por Taikochu el 30-12-2007 19:44
  16. #16   no es por ser alarmista pero como fabriquen los t-800 usando ubuntu ya sabemos lo que va a pasar
    votos: 9, karma: 36
    por omefilo el 30-12-2007 19:45
  17. #17   pero no me pongais negativos, que es una broma. Jo! ahora sufro. Como llame a mi primo Chuck os vais a enterar
    votos: 6, karma: -27
    por omefilo el 30-12-2007 20:43
  18. #18   ¿2038?
    Bueno, me preocuparé en 2018... si para entonces todavía no hemos vuelto a la edad de piedra después de que se acabe el petróleo.
    votos: 4, karma: 53
    por JarFil el 30-12-2007 20:50
  19. #19   Yo creo que de aquí a 30 años vista, algún parche sacarán, ¿no? :D
    votos: 0, karma: 9
    por dale el 31-12-2007 00:27
  20. #20   #19 De aquí a 30 años Vista... será un gigantesco parche... :-D
    votos: 6, karma: 40
    por Zakatua el 31-12-2007 00:55
  21. #21   #10,#12 gogo #0 la fecha no es el 1 de enero, es el 19 de enero...
    votos: 0, karma: 7
    por zitro el 31-12-2007 01:37
  22. #22   #20 ¿Vista? na, para entonces ya habrá salido Tacto... no será tan bonito, pero mucho más políticamente correcto, y sólo con el doble de bugs.
    votos: 3, karma: 12
    por JarFil el 31-12-2007 01:39
  23. #23   No hará falta 64 bits para entoces: con quitarle el signo a ese entero de 32 bits ya tenemos el doble de tiempo, hasta 2106.

    ¡¡Rápido, tenemos que quitarle el signo a un int en todos los sitemas antes de que pasen 30 años!!
    votos: 1, karma: 13
    por DiThi el 31-12-2007 01:42
  24. #24   El problema del efecto 2038 es muy conocido , sino preguntarle a John Titor : es.wikipedia.org/wiki/John_Titor
    votos: 3, karma: 25
    por JuanCa el 31-12-2007 01:54
  25. #25   » ver comentario
    por --2479-- el 31-12-2007 01:57
  26. #26   » ver comentario
    por --16689-- el 31-12-2007 02:03
  27. #27   Que ganas de armagedones, cataclismos y ecatombes que tenemos.
    Esto es un síndrome holliwodiense, sin duda.
    Sería irónico que después de tanto lío los únicos ordenadores que sobreviviesen fuesen los basados en windows, o incluso en Atari, spectrums y de más.

    Ya hemos tenido la dosis catastrofista del día en Meneame. Cual será la siguiente? Petroleo? Meteorito? Clima? Enfermedades? Acebes presidente? Se aceptan apuestas

    (todas las opciones me dan repelús por igual)
    votos: 4, karma: -20
    por Jumbo2 el 31-12-2007 02:26
  28. #28   Si mi padre, al mes de usar Windows Vista me dijo que le migrara a Ubuntu, ... en el 2038 no vamos a estar rulando con 64 ? ...
    votos: 1, karma: 2
    por Jata el 31-12-2007 02:44
  29. #29   #26 Mientras restes al numero mayor el numero menor, no hay ningún problema incluso aunque no tenga signo. Es más, cuando restas a un numero menor otro mayor, el resultado lo puedes tomar como con signo y seguirás teniendo un resultado válido. El problema vendría cuando restas 2 fechas separadas más de 68 años entre sí (y además restes a la fecha menor la mayor). Pero para entoces seguro que el software está preparado para ello, simplemente con comparar cuál es más reciente es suficiente. Todo esto suponiendo que el anticuado procesador de 32 bits se pasa el carry por el forro.
    votos: 1, karma: 12
    por DiThi el 31-12-2007 03:40
  30. #30   Me hace gracia que escriban Y2K38 (5 caracteres) frente a 2038 (sólo 4) :D
    votos: 36, karma: 270
    por khyros el 31-12-2007 03:57
  31. #31   #30 Non comment. Lo único relevante y decente en to la noticia. Un aplauso.
    votos: 3, karma: 30
    por ioroku el 31-12-2007 05:12
  32. #32   conocia pero no habia notado el detalle de q muchas cosas no estan corriendo con chips de 64bits. Interesante igualmente ver si dentro de 30 años AUN tenemos chiches a 32bits...

    PD: me pregunto q pasara con las hojas viejas de excel en ese entonces?
    votos: 0, karma: 7
    por Pajblito el 31-12-2007 06:04
  33. #33   #9 (...) HDTV le queda bastante tiempo... con que pasemos a TDT(...)

    Creo que tienes un pequeño lío con esto del cambio a digital... pero bueno tampoco tengo ganas de aclarate nada ahora. Lee si te interesa el asunto. Me voy a dormir que ya es hora y creo que con los comentarios que llevo habré recaudado suficientes negativos para donarlos esta navidad.
    votos: 1, karma: -5
    por psk el 31-12-2007 07:20
  34. #34   si se solucionó el y2k en windows, como no se va a solucionar una similaritud en una comunidad de gente que mejora, investiga y corrige.
    votos: 0, karma: 6
    por MArkFIA el 31-12-2007 08:55
  35. #35   » ver comentario
    por --4114-- el 31-12-2007 10:15
  36. #36   #34 Aquí hablamos de un tema de hardware y el y2k era puro software (1999 > 19100 <> 2000). Se basta por que como dice #2 el máximo valor en UNIXTIME es la fecha del fenomeno Y2K(38)... no se si me explico.
    votos: 0, karma: 16
    por Adrian el 31-12-2007 10:53
  37. #37   » ver comentario
    por --4114-- el 31-12-2007 11:04
  38. #38   Hombre yo creo que los SO de 64 bits para entonces ya estarán a la orden del dia, creo yo.
    votos: 0, karma: 5
    por giropau el 31-12-2007 11:44
  39. #39   #30 Realmente no es Y2K38 en lugar de 2038. Más bien es Y2K38 en lugar de "Year 2038", y si me apuras, "Year 2038 effect" xD
    votos: 2, karma: 30
    por Nildur el 31-12-2007 11:58
  40. #40   4 bytes=32 bits
    2^32=4294967296

    Es 4.294.967.296 y no es 2.146.483.547 como pone en la noticia.

    4294967296 segundos = 71582788,2666 minutos = 1193046,47111 horas = 49710,269629629 dias = 136,1925195 años

    1970+136 = 2106

    Según mis cálculos fallaría en 2016 y no 2038. O en algo me equivoco o hay algún dato mal en la noticia.
    votos: 2, karma: -15
    por tragaldabas el 31-12-2007 12:46
  41. #41   » ver comentario
    por --4114-- el 31-12-2007 13:01
  42. #42   #40 mírate #2 ...
    votos: 0, karma: 8
    por Lobo_Manolo el 31-12-2007 13:04
  43. #43   #40 ya lo ha comentado alguno en el hilo.

    El tipo de datos time_t que es el que está en "crisis". Este tipo de datos es un typedef de otro tipo de datos entero, esto depende de la biblioteca que se use puede ser uno u otro, con signo y sin signo. Y además el tipo de datos puede tener un tamaño diferente e incluso alineación de bits distinto según la arquitectura.

    En C se puede llegar a tener bastante control sobre estas cosas, alienaciones de bits, tamaños de tipos de datos, etc...

    El caso es que la peor de las combinaciones sería una definición de time_t como int con signo representado por 4 bytes. Como cometas 4 bytes son 32 bits, pero en el caso de que sea un tipo de datos con signo (no unsigned int) el bit más significativo se emplea para almacenar el signo, de este modo los mayores valores de números en valor absoluto realmente estarían representando cantidades enteras negativas.
    votos: 0, karma: 6
    por glurmo el 31-12-2007 13:14
  44. #44   Perdonad, no me había dado cuenta de lo del signo. De todas formas veo un poco absurdo utilizar un entero con signo para almacenar valores que siempre serán positivos, o también se podía haber empezado a contar el primer segundo desde el valor negativo mas bajo posible, incrementando hasta cero y continuando posteriormente con los valores positivos. Esto daría el doble menos uno de valores. O simplemente utilizar solo enteros y empezar desde el 0 hacia delante, que también daría el doble menos uno de valores posibles.
    votos: 0, karma: 6
    por tragaldabas el 31-12-2007 15:33
  45. #45   bueno, por lo menos tienen hasta ese año para enmendar el error, no a toda prisa como con el 2000
    votos: 0, karma: 5
    por Chet el 31-12-2007 15:53
  46. #46   » ver comentario
    por --42764-- el 31-12-2007 16:06
  47. #47   » ver comentario
    por --28547-- el 31-12-2007 18:03
comentarios cerrados

menéame