17 de noviembre de 2009

Linux no es tierra para FatELF

El tiempo que pasó entre su anuncio y su desaparición fue tan corto que los trolls casi no tuvieron tiempo de pensar argumentos para las discusiones. A pesar de recordar prematuramente al Titanic, FatELF, la idea de juntar los binarios para varias arquitecturas en uno solo, recorrió todos los blogs y sitios de noticias como la pólvora. Pero al final el barco se ha hundido. No diré que me alegro, porque tampoco es de buenos ateos ser puntilloso, pero este hundimiento se veía venir. Y es que francamente este invento tenía, en la práctica, poco de útil.

Hay muchas cosas que Linux puede copiar de Mac OS X u otros sistemas operativos, pero en lo que se refiere a saber convivir con varias arquitecturas, me parece que es más bien al contrario, que es Linux quien puede enseñar un par de cosas. No se suele oir mucho, pero a día de hoy Linux es el SO con más soporte de arquitecturas, por encima de NetBSD. Además, las soporta además desde hace mucho, desde 1995, asi que desde muy pronto se tuvo que lidiar con los problemas que originaban.

Por ejemplo, los sistemas de archivos de algunos SOs están habituados a funcionar en una sola arquitectura, y si mueves el disco de, por ejemplo, un sistema de archivos UFS creado en un SPARC a un x86, no puede leerse, porque la versión para SPARC escribe los datos en formato big-endian y x86 los lee esperando que sean little-endian, es decir, no puede leerlos. En cambio, los sistemas de archivos de Linux estan diseñados para que un disco pueda intercambiarse entre sistemas diferentes sin problemas: El código está adaptado para transformar desde/hacia un tipo de formato a otro en todas las rutas del código que lean o escriban datos al disco, y los datos siempre se escriben en un solo formato (little endian, generalmente).

Cuando se crearon los sistemas de paquetes en Linux, se diseñaron con soporte de varias arquitecturas. Y el principal argumento en contra de FatELF es este: Que el tema de las arquitecturas ya está perfectamente solucionado en Linux desde mucho antes que a Steve Jobs se le ocurriera cambiar PPC por x86. Para Mac OS X los binarios universales les van bien, claro: su modelo para distribuir aplicaciones no es mediante repositorios, y en el switch de arquitectura fue necesario usar aquel truco del viejo Nextstep para facilitar la transición. Pero en Linux la cosa cambia. Los repositorios se ocupan del problema

Aun quedan los programas "de terceros", ¿qué sería de ellos? ¿No les vendría bien FatELF? Pues dudosamente, empezando con que cualquier programador "de terceros" debería, en principio, hacerlo mediante paquetes, que siempre serán varios debido a la fragmentación linuxera. Ignorando ese punto, tendrían que decidir para cuantas arquitecturas van a compilar: x86-32, x86-64, PPC, IA64, SPARC...puede que no sea necesario preocuparse de muchas de esas arquitecturas por su escasa relevancia, claro, pero ahí está el asunto: ¿de cuales te preocupas, y de cuales no? En Apple está todo claro, porque además de software hacen hardware y se sabe a qué hay que atenerse, pero en Linux todo está muy indefinido.

En el caso de que en Linux necesitaramos distribuir algo con soporte de varias arquitecturas en un solo archivo, resultaría mucho más fácil y lógico (y así se lo he indicado al tipo creador de FatElf en un flamewar, sin recibir respuesta) añadir soporte a RPM/DEB para poder crear meta-paquetes que tengan dentro todos los paquetes de las diversas arquitecturas. El instalador (dpkg/rpm) escogería el adecuado para el equipo en el que se instala y voilá, ya tienes distribución multi-arquitectura en un solo archivo...y sin tocar una sola línea de código del kernel, y evitando tener binarios gigantescos en el sistema para una arquitectura que no se utiliza. No es además nada dificil implementarlo: básicamente se trataría -quizás literalmente- de un archivo tar con varios paquetes dentro.

Si nadie lo implementa es por la simple razón de que a nadie le hace falta. FatELF es una idea en infructuosa búsqueda de un problema que resolver.

4 comentarios:

  1. Ciertamente cuando leí sobre el asunto no acabé de verle la gracia. Siendo usuario de Linux desde hace muchos años y de Mac OSX desde que me llegó el primer Mac Pro Xeon que sacaron, una de las ventajas que siempre le he visto al primero es su gestión del espacio en disco. Para algunos un detalle sin importancia pero para mi todo recurso hay que cuidarlo. Me llamó la atención la barbaridad de espacio que consumía OSX y sus aplicaciones. En comparación con Linux era exagerado. Ahora, la nueva versión de OSX 10.6 es "intel only" y su "peso" ha disminuido casi a la mitad.

    ¿Para qué querríamos en linux algo parecido? Si acaso sería para juntar binarios x86 y x86_64, pero ¿acaso el asunto no se soluciona instalando las librerías correspondientes? Al menos así es como, en su momento, solucioné los problemas derivados de la falta de Flash en 64 bits.

    Estoy completamente de acuerdo contigo en que linux tiene esta papeleta solventada de serie. ¿No te da la sensación de que recurrentemente aparecen "soluciones" a la diversidad de linux que dan a entender que existe un problema derivado de la misma?

    ResponderEliminar
  2. Anónimo11:35 a. m.

    Hola. Este comentario no tiene nada que ver con este post. Lee y borra. Es sólo para informarte que el Ultraviolet de SGI vio la luz ayer, por si no lo sabías.

    Te iba a copiar un par de links pero como tienes el copypaste desactivado, pues no lo hago. Pero busca la noticia en theregister.co.uk que es donde mejor está.

    Un saludete.

    (PD: si en el blog tienes publicada alguna información de contacto, palabra que no la he encontrado)

    ResponderEliminar
  3. Anónimo: Gracias por la información, afortunadamente leo The Register y ya leí lo del SGI Ultraviolet, de todos muchas gracias :)

    ResponderEliminar
  4. Anónimo11:20 a. m.

    De nada.

    A ver si te animas a poner una forma de contactar contigo en el blog. A veces he tenido ganas de hacerte llegar información y no me ha sido posible.

    ResponderEliminar