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.