GoRaXaN dice:

Por lo que he leido en su web, no es mas que coger los binarios especificos de cada arquitectura y juntarlos en un fichero que lleva en la cabecera información acerca de qué arquitecturas estan incluidas en ese fichero.

Por lo que a nivel del programador el ahorro en el codigo es nulo (ya que tiene que seguir programando para cada arquitectura) y a nivel de usuario se ahorra tener que elegir el paquete correspondiente a su arquitectura (a costa de, segun dicen en su propia web, muchas veces multiplicar el tamaño del fichero original tantas veces como arquitecturas se añadan, por lo que tardamos bastante mas en descargarlo).

La idea no es mala pero no lo veo demasiado útil, además, los gestores de paquetes ya nos eligen los paquetes específicos de nuestra arquitectura y rara vez nos descargamos algo que no sea mediante el gestor.

itomailg dice:

Todo ayuda, pero como dice GoRaXaN, no le veo demasiada utilidad, sobre todo para los programadores.

Lo interesante seria poder hacer una libreria de 64, que funcionase ella por su cuenta en un sistema a 32(con sus limitaciones). No se programas, por lo que a lo mejor es una tonteria

David Saltares dice:

Todo lo que sea multiplataforma es bueno porque facilita las cosas y beneficia mucho a los usuarios que pueden acceder a un catálogo más variado de software.

¡Saludos!

Kadai dice:

Lo de los binarios universales ya lo habia escuchado o.O (es más hasta con instaladores universales, que te instalaban paquetes sin necesidad del deb o de un rpm… muy al estilo de como instalas programas es Windows)

Ahora, la idea es buena… y de hecho algo así medio ocurre con Songbird o Firefox… que ya vienen pre-compilados o algo así tengo entendido… en sí, traen su propio ejecutable que ya solo tu corres.

Ahora, la idea de tener un compromido que tenga cada binario en cada plataforma que exista, es un arma de doble filo.

En mi caso, yo propondria un formato universal usando a medias la idea de los pre-compilados… claro, con diferencias rotundas… mmm… me imagino algo como…

Digamos que dejamos que el programador siga programando y compilando en su arquitectura favorita, pero que en vez de usar un compilador regular, use un compilador especial para portabilidad.

Ese compilador, despues de convertir en binario el archivo, separa (por medio de una base de datos) cada instrucción que es especifica de una arquitectura y deja lo demás marcado como universal. Digamos que usamos como una especie de metadatos en un puzzle para resolver el problema más tarde.

Ya luego, en la computadora del usuario, cuando este intente ejecutar el binario, lo primero que hara el sistema, es verificar si es un binario universal. Si lo es, buscara un archivo oculto que le diga si ha sido compilado ya… si no esta, llama entonces a un modulo y le manda al binario para traducción (Si no es de la arquitectura propia)

Entonces, el modulo toma al binario, y si es de la misma arquitectura local, solo lo ensambla… de no ser así, busca todas las instrucciones marcadas con el metadata y las traduce a la arquitectura local (via una base de datos universal, incluso aqui, podria incluirse en el archivo esas piesas del codigo fuente para hacerlo más fácil) para luego ensamblar de nuevo el archivo con las intrucciones traducidas, pero como un archivo oculto que será llamado la proxima vez que el usuario intente ejecutar el binario universal.

XDDD

Ahora, quien sabe si todo eso sea remotamente posible =9… pero seria mi acercamiento a la solución.

Picholeiro dice:

Me parece una buena idea ya que no da problems en un paquete especifico para cada arquitetura que sino un usuario normal puede descargar sim ploblemas el archivo, lo malo es que es doble trabajo para desarrolldores pero si hubiera librerias conjuntas , tambien es un buen ahrro

Kadai dice:

@anonimo2

Que mal entonces que no se pueda con los otros (assembler) como dices… sin embargo, estoy seguro que de una manera u otra algo ha de ser posible hacer ^^

Es solo buscarle maneras diferentes de hacer las mismas cosas… ya en algun momento algo ocurrira que permita que eso pase y que las barreras fisicas se pasen.

Nitsuga dice:

@juancarlospaco: No tienen por qué ir más lento, cuanto mucho perderas algunos milisegundos, y 4 o 5 ciclos de CPU (eso es muy poco, tu CPU de doble núcleo hace hace mas de 5.200.000.000 ciclos por segundo) mientras se detecta que tipo de universal es y dónde está los datos para la arquitectura deseada

edgar dice:

Pues a mi me parece perfecto pues acabaria con la barrera de los programas echos para arquitecturas y sistemas de 64 bits, la cual hoy aun sigue un poquito rezagada.

Desearia mas informacion sobre todo esto, buena la info, gracias muylinux

anonimo dice:

Yo más que un binario multiarquitectura lo que desearía serían binarios estáticos(como el de opera), que los instalas y no te pide ninguna dependencia, y aunque serán más pesados en tamaño, el usuario seguro que lo agradece.
Además eso te da la posibilidad de instalar la versión del paquete que te de la gana, en la distro que te de la gana(ya sea estable o no).
¿Nadie ha echado en falta versiones nuevas de ciertos paquetes en distros estables? Y por un par de paquetes no vas a actualizar a una inestable.

Rayniery dice:

Yo estoy de acuerdo con anónimo y MagoBlanco, lo que hace falta en GNU/Linux son instaladores estándares que funcionen en cualquier distro y que estén enlazados estáticamente, así se podría instalar cualquier versión de un programa en cualquier distro sin problemas. Por ejemplo, para yo instalar amarok 1.4 en Mandriva 2009.1 fue un tremendo problema porque el gestor de paquetes lo reconoce como un programa obsoleto y he tenido que dejar de actualiar la distro para no tener problemas.

Anónimo dice:

Yo creo que lo del binario universal está muy interesante en cierto sentido. Es parecido a un programa en Java, pero habiéndolo desarrollado para distintas arquitecturas. La ventaja de un único ejecutable no es útil para un sistema de repositorios o para programas que sueles descargarte a veces. Es útil para empresas de videojuegos (por ejemplo) que tras una instalación, tienen un ejecutable que se encarga de todo para que un usuario sin conocimientos pueda usarlo inmediatamente. Es útil también para llevar en un pendrive tu firefox y ejecutarlo en “cualquier” PC como si fuese una aplicación java, manteniendo tus perfiles, marcadores, etc.

Sobre la velocidad, no sé cómo lo habrán diseñado, pero lo más lógico parece ser un lanzador del resto de los binarios. Ese lanzador determina la plataforma y luego lanza el binario correspondiente. Estos binarios, por lo que dice la noticia, parecen estar encapsulados en el lanzador, aunque bien podrían estar en una subcarpeta bin. De ser un mero lanzador universal, sólo tardaría un poco más (casi inapreciable) en el lanzamiento de la aplicación. Una vez lanzada, sería igual de rápida.

@anonimo:
Lo del binario estático va contra la filosofía de GNU/Linux. Todas las dependencias nos ahorran mucho espacio. Ahora que tenemos discos duros enormes, eso se puede notar poco, pero las dependencias las gestionan aplicaciones de forma automática. No tenemos que pelearnos con ellas, así no le veo mucha utilidad salvo para pequeñas aplicaciones puntuales de “usar y tirar” en las que al venir fuera de los repositorios, un único uso no merece la búsqueda de dependencias a mano.

anonimo2 dice:

@Anonimo eso depende del codigo, a veces para acelerar C algunos desarrolladores (incluido) bajamos a Assembler y hay si dicho programa estara lock in en una arquitectura, pero a veces esto n oes necesario.

Estoy deacuerdo con lo que dices, lo unico que casi estoy 100% seguro de que el binario estatico n ova en contra de la filosofia e GNU y/o Linux sino en contra de las de UNIX.