Libertonia || Comments || Una opinión sobre el G5


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Una opinión sobre el G5 | 44 comentarios (42 temáticos, 2 editoriales, 0 ocultos)

Debian en Sparc (4.50 / 2) (#25)
por jorginius ("jorginius" en Google Mail) a las Wed Jul 9th, 2003 at 03:44:42 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

A petición de Ridiculum, que no hace más que darme la vara con que tengo que decir algo respecto a Debian y Sparc, escribo este tostón de demasiadas líneas. Por si no no tenéis moral para seguir leyendo, os lo resumo: en Sparc Debian no funciona ni por asomo igual de bien que en x86 (o eso espero, por el bien de los usuarios de Debian en x86 :-)).

tengo instalado woody en i386 y Sparc y funciona igual, o casi, en ambas arquitecturas.

No conozco Debian en x86, pero si me aseguras que funciona igual (o casi) que en Sparc, compadezco a la gente que tiene que sufrirla.

Es bastante frustrante que paquetes de la versión estable (Woody), descargados de los repositorios oficiales, sencillamente no funcionen. Den fallos de segmento nada más al iniciar o errores de "Bus Error" en puntos "aleatorios" (un clásico del código C++ compilado con el gcc-2.95 o 3.0 que se distribuye con Woody bajo Sparcv7 o v8), fallos que pueden ser evitados a veces escogiendo otras opciones de compilación distintas de las que usa Debian por defecto.

Sobre las opciones de compilación: prácticamente toda la distribución (el userland de v9 y todo para v8 y anteriores) se compila para Sparcv7. Para ponernos en situación, Sparcv7 es una arquitectura sobre la que el propio Solaris (versión 8 y posteriores) no corre y no se ha usado para nada salvo para algún sistema embarcable en los últimos 20 años. La "vieja" SS5 de presi ya es una v8.

Lo peor es que la especificación del micro Sparcv7 no incluye fpu ni operaciones "avanzadas" sobre enteros (tan avanzadas como la multiplicación o la división), así que el compilador emite código para emular éstas y las operaciones con reales por software. Huelga mencionar el lamentable desempeño de, por ejemplo, OpenSSL causado por esas opciones de compilación.

En la época de Potato, uno de los responsables de la rama de Debian Sparc mantenía versiones de los paquetes "críticos" compilados para v9 (UltraSparc). Sin embargo, al no ser capaz el sistema de paquetería de Debian de manejar mismas versiones de los mismos paquetes, para la misma arquitectura pero compilados de forma distinta, aquello era un pequeño infierno de mantener y en Woody se ha abandonado esa forma "dual" de distribuir los paquetes. En teoría, la última distribución de Debian que iba a ser compilada para v7 sería Woody, en la práctica seguimos en las mismas con Sid.

Tampoco da una buena impresión que el soporte de Sparcaudio haya sido retirado del kernel de Debian por alguna razón que se me escapa (porque funcionar, en nuestras Sparcs funciona), o que el que se hayan olvidado de incluir en las isos oficiales de Woody un kernel 2.4 de 64 bits para la instalación, cuando la opción en el SILO sí aparece (estás obligado a arrancar con el de rescate o tirar del 2.2 alternativo) o cosas tan tontas como que el mapa del teclado de las X por defecto no tenga en cuenta la tecla Meta.

Honestamente, la mayoría de las pegas, salvo algunos scripts de postinstalación de paquetes mal escritos, algunos paquetes mal separados o compilados con opciones sin mucha cabeza (si incluyes el cliente de ssh instala además el servidor, cyrus-imapd no está compilado con soporte para cyrus-sasl, etc. Para más señas, consultad el Diario de Ridiculum) se reducen a problemas del compilador que se incluye con Debian, que es bastante buggy compilando para 32 bits en Sparc y esta totalmente roto si hablamos de generar código de 64 bits. De hecho se incluye una versión antediluviana del egcs para compilar exclusivamente los kernel de 64 bits y que falla casi sistemáticamente en todo lo demás.

En general da la impresión en Sparc de que la gente de Debian verifica que compila y empaquetan el software, sin ni siquiera mirar en un poco de detalle si funciona o no. Puedo entender que eso lo hagan en una versión de desarrollo, esperando que la gente notifique los bugs... Pero que lo hagan en la "estable" me parece una tomadura de pelo. Si no tienen medios para verificar que todo lo que distribuyen funciona, que no lo distribuyan o que lo etiqueten como "no testeado". Mi tiempo es limitado y no quiero perderlo intentando inútilmente hacer funcionar algo que está "roto de fábrica", aún cuando lo llamen "estable".

Respecto al kernel, nosotros tenemos en las SS5, en las Classic y en las Ultra el mismo 2.4.20, aparte de OpenBSD y NetBSD. Creo recordar que tuvimos problemas con el 2.4.18, ya que hubo alguna SS5 a la que le instalamos un 2.2 con los parches para ext3. Pero desde que salio el 2.4.20 ni una pega.

Hemos compilado el kernel para las máquinas de 32 bits un par de veces en las Ultra con el gcc-3.2, usando el entorno sparc32, con éxito irregular. Dependiendo de la fase de la luna, unas veces el kernel funciona y otras no: ahora solemos compilar siempre en las SS5 (total, siempre tenemos alguna ociosa por ahí) con el 2.95 y sin novedad hasta ahora, ni en las Classic ni en las SS5.

[ Padre ]

Others have rated this comment as follows:

Envite	4
advocatux	5

Una opinión sobre el G5 | 44 comentarios (42 temáticos, 2 editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda