[opensuse-es] Es que los 64 bits tienen más bugs que los 32?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
I have found that if any part of a table in an MS Word document falls outside the page margins OOo 3.1 will not display that table. OOo 3.0.1 does not have this problem, also I had a friend with Windows try OOo 3.1.0 Windows version and there is no problem.
It seems to be 64-bit-specific bug. I see it only on x86_64. I see it also with the Sun 64-bit build. I filed a bug report but have not any response. https://bugzilla.novell.com/show_bug.cgi?id=512245 Florian is quite busy. I have just assigned it to another developer that should have more time to look at it... ¿Como es posible que el simple hecho de compilar una aplicación para una u otra arquitectura produzca bugs como esos? Con tan sólo cambiar el target? O hay más que se me escapa, imagino. Pero si esto ocurre habitualmente, tiemblo de pensar que nos vayamos todos a los 64 bits... - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpHOCMACgkQtTMYHG2NR9XfBgCfTMnZdZLJMr5bfGzP+iIWzH2q HRkAn1a6PdpHvlYBieC9XUajKqSxvXzZ =PWUS -----END PGP SIGNATURE-----
2009/6/28, Carlos E. R.:
Una curiosidad, ya que decíais hace dias de que la versión de 32 bits de suse linux desaparecería. En http://lists.opensuse.org/opensuse/2009-06/msg00996.html hablan de un bug del OOo 3.1.0 por el cual si un documento tiene tablas que se salen fuera del margen de página, no las muestra; la versión anterior sí las mostraba. Y dice " Petr Mladek" que es un bug específico de la versión de 64 bits:
Cada plataforma tiene sus bugs... ¿o acaso el OOo para 32 bits no tiene ningún problema? >:-)
I have found that if any part of a table in an MS Word document falls outside the page margins OOo 3.1 will not display that table. OOo 3.0.1 does not have this problem, also I had a friend with Windows try OOo 3.1.0 Windows version and there is no problem.
It seems to be 64-bit-specific bug. I see it only on x86_64. I see it also with the Sun 64-bit build.
I filed a bug report but have not any response. https://bugzilla.novell.com/show_bug.cgi?id=512245
Florian is quite busy. I have just assigned it to another developer that should have more time to look at it...
¿Como es posible que el simple hecho de compilar una aplicación para una u otra arquitectura produzca bugs como esos? Con tan sólo cambiar el target? O hay más que se me escapa, imagino.
No sería nada muy grave porque parece que ya lo han resuelto (upstream): WW8: table imported with wrong position on ubuntu linux http://www.openoffice.org/issues/show_bug.cgi?id=101451
Pero si esto ocurre habitualmente, tiemblo de pensar que nos vayamos todos a los 64 bits...
Bueno... un bug es un bug. Lo cual significa que "alguien" ha hecho algo mal (dale caña al programador no a la plataforma) :-P Además, también hay errores que sólo afectan a la plataforma de 32 bits...espera, te pongo un ejemplico para que ejecutes en tu plataforma de 32 bits: *** date -d 2040-12-5 *** Y ahora prueba en una de 64 bits... ¿funciona, verdad? Hum... sí. Pues para esto no han sacado parche aún >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 28 de junio de 2009 06:47, Camaleón
2009/6/28, Carlos E. R.:
Una curiosidad, ya que decíais hace dias de que la versión de 32 bits de suse linux desaparecería. En http://lists.opensuse.org/opensuse/2009-06/msg00996.html hablan de un bug del OOo 3.1.0 por el cual si un documento tiene tablas que se salen fuera del margen de página, no las muestra; la versión anterior sí las mostraba. Y dice " Petr Mladek" que es un bug específico de la versión de 64 bits:
WW8: table imported with wrong position on ubuntu linux http://www.openoffice.org/issues/show_bug.cgi?id=101451
Pero si esto ocurre habitualmente, tiemblo de pensar que nos vayamos todos a los 64 bits...
Bueno... un bug es un bug. Lo cual significa que "alguien" ha hecho algo mal (dale caña al programador no a la plataforma) :-P
Además, también hay errores que sólo afectan a la plataforma de 32 bits...espera, te pongo un ejemplico para que ejecutes en tu plataforma de 32 bits:
*** date -d 2040-12-5 ***
Y ahora prueba en una de 64 bits... ¿funciona, verdad? Hum... sí.
Pero ese bug es en ubuntu.... El tema 32 versus 64 bits, es largo. Cuando se trata de potencia de procesamiento, con registros de mas de 32 bits, no se discute la superioridad de los 64 bits. Pero para una pc de escritorio, los 64 bits son mas problematicos, y como dije en el hilo anterior, en el caso de los servidores web, no hay aumento de rendimiento de 32 a 64 bits, y lo unico que aumenta, es el uso de memoria, ya que require mas del doble, como dije y puse los links en el hilo anterior que se trato el tema. http://www.linuxforums.org/forum/linux-tutorials-howtos-reference-material/6... Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-06-28 a las 10:28 -0300, Juan Erbes escribió:
El 28 de junio de 2009 06:47, Camaleón escribió:
Además, también hay errores que sólo afectan a la plataforma de 32 bits...espera, te pongo un ejemplico para que ejecutes en tu plataforma de 32 bits:
*** date -d 2040-12-5 ***
Y ahora prueba en una de 64 bits... ¿funciona, verdad? Hum... sí.
Pero ese bug es en ubuntu....
¿Un bug de Ubuntu? :-? No entiendo. A mi me falla en suse.
El tema 32 versus 64 bits, es largo. Cuando se trata de potencia de procesamiento, con registros de mas de 32 bits, no se discute la superioridad de los 64 bits. Pero para una pc de escritorio, los 64 bits son mas problematicos, y como dije en el hilo anterior, en el caso de los servidores web, no hay aumento de rendimiento de 32 a 64 bits, y lo unico que aumenta, es el uso de memoria, ya que require mas del doble, como dije y puse los links en el hilo anterior que se trato el tema.
http://www.linuxforums.org/forum/linux-tutorials-howtos-reference-material/6...
El problema, Juan, es que son los desarrolladores del kernel los que están debatiendo "unificar" ambas plataformas: Linux: Unified x86 Architecture http://kerneltrap.org/node/13984 Recomiendo leer el mensaje de Thomas Gleixner donde explica muy bien la idea. Independientemente de lo que nosotros queramos es algo que están planendo hacer (no sé si al final llegarían a alguna conclusión), por eso es mejor ir preparándose para lo que viene... Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 28 de junio de 2009 10:54, Camaleón
El 2009-06-28 a las 10:28 -0300, Juan Erbes escribió:
El 28 de junio de 2009 06:47, Camaleón escribió:
Además, también hay errores que sólo afectan a la plataforma de 32 bits...espera, te pongo un ejemplico para que ejecutes en tu plataforma de 32 bits:
*** date -d 2040-12-5 ***
Y ahora prueba en una de 64 bits... ¿funciona, verdad? Hum... sí.
Pero ese bug es en ubuntu....
¿Un bug de Ubuntu? :-? No entiendo.
A mi me falla en suse.
El tema 32 versus 64 bits, es largo. Cuando se trata de potencia de procesamiento, con registros de mas de 32 bits, no se discute la superioridad de los 64 bits. Pero para una pc de escritorio, los 64 bits son mas problematicos, y como dije en el hilo anterior, en el caso de los servidores web, no hay aumento de rendimiento de 32 a 64 bits, y lo unico que aumenta, es el uso de memoria, ya que require mas del doble, como dije y puse los links en el hilo anterior que se trato el tema.
http://www.linuxforums.org/forum/linux-tutorials-howtos-reference-material/6...
El problema, Juan, es que son los desarrolladores del kernel los que están debatiendo "unificar" ambas plataformas:
Linux: Unified x86 Architecture http://kerneltrap.org/node/13984
Recomiendo leer el mensaje de Thomas Gleixner donde explica muy bien la idea.
Independientemente de lo que nosotros queramos es algo que están planendo hacer (no sé si al final llegarían a alguna conclusión), por eso es mejor ir preparándose para lo que viene...
Ok, pero, así como se unificó el kernel smp con el no-smp, no es nada extraño unificar el kernel de 32 y 64 bits, de acuerdo con el set de instrucciones X86-64 desarrollado por AMD, que permite ejecutar codigo de 32 o 64 bits, pero manteniendo la compatibilidad hacia atras con micros anteriores, lo cual no implica que solamente se pueda ejecutar codigo de 64 bits, ya que el kernel se adapta al codigo de las aplicaciones de 32 o 64 bts. El link que pusiste, habla de unificar, y no de que solamente ejecute codigo de 64 bits: Linux: Unified x86 Architecture Thomas Gleixner described an effort to create a unified x86 architecture tree, "the core idea behind our project is simple to describe: we introduce a new arch/x86/ and include/asm-x86/ file hierarchy that includes all the existing 32-bit and 64-bit x86 code and allows the building of either a 32-bit (i386) kernel or a 64-bit (x86_64) kernel." Andi Kleen expressed some concern, "I think it's a bad idea because it means we can never get rid of any old junk. IMNSHO arch/x86_64 is significantly cleaner and simpler in many ways than arch/i386 and I would like to preserve that. Also in general arch/x86_64 is much easier to hack than arch/i386 because it's easier to regression test and in general has to care about much less junk. And I don't know of any way to ever fix that for i386 besides splitting the old stuff off completely." Additional concerns about legacy issues were countered by Linus Torvalds, "there really isn't that much legacy crud. There are things like random quirks, but every time I hear the (theoretical) argument about how much time and effort we save by having it duplicated somewhere else, I think about all the time we definitely waste by fixing the same bug twice (and worry about the cases where we don't)." Among the justifications for a unified architecture, Thomas noted: "We believe that the whole x86 CPU family is very much related and should be supported in a single architecture tree. All 64-bit CPUs implement the ability to execute pure 32-bit kernels, and will probably do so for the next couple of decades. So it's not like it will ever be possible to get rid of our legacies: for example even the latest 64-bit CPUs implement the legacy 'A20 line' feature that was already a weird outdated hack in the days of 16-bit x8086 CPUs." Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-06-28 a las 22:51 -0300, Juan Erbes escribió:
El problema, Juan, es que son los desarrolladores del kernel los que están debatiendo "unificar" ambas plataformas:
Linux: Unified x86 Architecture http://kerneltrap.org/node/13984
Recomiendo leer el mensaje de Thomas Gleixner donde explica muy bien la idea.
Independientemente de lo que nosotros queramos es algo que están planendo hacer (no sé si al final llegarían a alguna conclusión), por eso es mejor ir preparándose para lo que viene...
Ok, pero, así como se unificó el kernel smp con el no-smp, no es nada extraño unificar el kernel de 32 y 64 bits, de acuerdo con el set de instrucciones X86-64 desarrollado por AMD, que permite ejecutar codigo de 32 o 64 bits, pero manteniendo la compatibilidad hacia atras con micros anteriores, lo cual no implica que solamente se pueda ejecutar codigo de 64 bits, ya que el kernel se adapta al codigo de las aplicaciones de 32 o 64 bts.
El link que pusiste, habla de unificar, y no de que solamente ejecute codigo de 64 bits:
Linux: Unified x86 Architecture Thomas Gleixner described an effort to create a unified x86 architecture tree, "the core idea behind our project is simple to describe: we introduce a new arch/x86/ and include/asm-x86/ file hierarchy that includes all the existing 32-bit and 64-bit x86 code and allows the building of either a 32-bit (i386) kernel or a 64-bit (x86_64) kernel." Andi Kleen expressed some concern, "I think it's a bad idea because it means we can never get rid of any old junk. IMNSHO arch/x86_64 is significantly cleaner and simpler in many ways than arch/i386 and I would like to preserve that. Also in general arch/x86_64 is much easier to hack than arch/i386 because it's easier to regression test and in general has to care about much less junk. And I don't know of any way to ever fix that for i386 besides splitting the old stuff off completely." Additional concerns about legacy issues were countered by Linus Torvalds, "there really isn't that much legacy crud. There are things like random quirks, but every time I hear the (theoretical) argument about how much time and effort we save by having it duplicated somewhere else, I think about all the time we definitely waste by fixing the same bug twice (and worry about the cases where we don't)." Among the justifications for a unified architecture, Thomas noted:
"We believe that the whole x86 CPU family is very much related and should be supported in a single architecture tree. All 64-bit CPUs implement the ability to execute pure 32-bit kernels, and will probably do so for the next couple of decades. So it's not like it will ever be possible to get rid of our legacies: for example even the latest 64-bit CPUs implement the legacy 'A20 line' feature that was already a weird outdated hack in the days of 16-bit x8086 CPUs."
Hombre, claro... ¿cómo se van a cargar de un plumazo una plataforma tan extendida? :-) Además, hay micros que son de 32 bits (el mismo pentium 4 por ejemplo, o incluso algunos modelos de Atom, que tampoco admite las extensiones de 64). No hombre, si la idea que tienen es buena, sobre todo para los programadores. Supongo que un entorno unificado sería más sencillo de gestionar (a la hora de aplicar parches o funcionalidades, se ahorran hacerlo dos veces por separado, por ejemplo). Los 32 bits irán cayendo en desuso, los fabricantes se centrarán en hardware puro de 64 bits pero para que eso llegue creo que aún le queda algún tiempito :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (3)
-
Camaleón -
Carlos E. R. -
Juan Erbes