PandaBuilder: así se compila masivamente Ubuntu para ARM

Uno de los últimos esfuerzos de Canonical está orientado a lograr que Ubuntu sea totalmente compatible con la plataforma ARM, y para ello hay un equipo al frente del cual está David Mandalla, que se está encargando de trasladar todos los paquetes de Ubuntu a esta plataforma a partir del código fuente.

El problema, claro está, es que compilar más de 20.000 paquetes no es moco de pavo: eso requeriría un tiempo notable en una máquina convencional, así que Mandalla ha tenido una genial idea: crear una máquina de compilación masiva para la plataforma ARM.

Se trata de PandaBuilder, un servidor 4U con nada menos que 20 “PandaBoards” controladas por otra placa maestra que es la que distribuye las tareas de compilación en este maquinón. Para que os hagáis una idea, estos son los componentes del servidor:

21 PandaBoards, cada una con un precio de 174 dólares y con los siguientes componentes
- Un procesador OMAP4430
- 1 GB de memoria DDR2
- Ranura SD/MMC
- Conector HDMI 1.3
- Conectividad 802.11 b/g/n, Bluetooth 2.1, Ethernet 10/100
- 2 puertos USB 2.0
20 discos duros SATAII USB de 300 GB
1 fuente de 200A, 5V
1 fuente de 100A, 12V
24 controladoras serie montadas en los PCBs en matrices de 8
21 jacks Ethernet

Podéis seguir la evolución de este proyecto en el blog de su responsable, que desde luego ha tenido una idea genial para acortar tiempos de forma crítica. Ahora solo hay que esperar a ver los resultados.

ARM Canonical compilación Intel Ubuntu

m4rk1
Anda, pero si ha descubierto el clustering. Enhorabuena.
julio
mmm.. y la compilación cruzada? yo no me canso de compilar para arm7 usando gcc…
No he leído el articulo, pero me imagino que el uso de la máquina será principalmente el testeo de los paquetes, que no de compilación, ya que para compilar, creo que irá todo mas rápido en las maquinas que tengan para ello.
Y aun así para testear, se podría usar qemu, aunque tal vez no fuese lo ideal, xd
- julio
  vale… veo que la compilación cruzada lleva bastante mas tiempo. Me retracto en este caso.
  Pero la máquina se usa para compilar y testear el paquete
  - gsar
    No estoy muy seguro de cuanto rendimiento se pierde en la compilación cruzada, pero si ya tienes un cluster de máquinas potentes (para las otras ramas), no le veo demasiado sentido al invento.
    En realidad, me resulta extraño que otras distros como Debian (que tiene un repositorio de choporrocientos paquetes), tengan soporte para ARM hace eones, y a ninguno se le ocurriera montar algo similar….
    Me parece curioso, pero no lo termino de ver como algo productivo (De todos modos, me encantan los proyectos de mooding y caharreo en gral, así que se agradece la entrada).
Annubis
Picajoso, sin ánimo de ofender, pero creo que deberías documentarte un poco antes de escribir ciertos artículos.
El problema, claro está, es que compilar más de 20.000 paquetes no es moco de pavo:
Créeme que lo más fácil de todo el proceso es construir los paquetes.
eso requeriría un tiempo notable en una máquina convencional,
Los paquetes para las distros nunca se compilan en “una máquina convencional”. Se usan “granjas de compilación” o (término que sí os sonará) “Build Systems”. En éstas máquinas, no es que sean “maquinones”, es que son clusters de varios “maquinones”
así que Mandalla ha tenido una genial idea: crear una máquina de compilación masiva para la plataforma ARM.
Pues a mí me parece un atraso en lugar de un avance. Me explico: cada vez que se importe un nuevo paquete en Ubuntu, deberá pasar por el build system “normal” (el que construye los paquetes para 32 y 64 bits, que son las arquitecturas que actualmente maneja dicha distribución) y luego pasarlo por el PandaBuilder éste. Es decir, doble trabajo.
- hsierra
  Pues a mí me parece un atraso en lugar de un avance. Me explico: cada vez que se importe un nuevo paquete en Ubuntu, deberá pasar por el build system “normal” (el que construye los paquetes para 32 y 64 bits, que son las arquitecturas que actualmente maneja dicha distribución) y luego pasarlo por el PandaBuilder éste. Es decir, doble trabajo.
  ¿En pocas palabras dices que esto obliga a compilar primero para las arquitecturas x86y x64, para luego con esos paquetes compilar los paquetes para ARM?
  Te recuerdo que la compilación de los paquetes se hace a partir de los archivos fuente, por lo que una cosa no depende de la otra, y por otro lado, el tener que compilar los paquetes para cada arquitectura bajo la cual se pretende funcionen los programas, es inevitable.
  - Annubis
    ¿En pocas palabras dices que esto obliga a compilar primero para las arquitecturas x86y x64, para luego con esos paquetes compilar los paquetes para ARM?
    Estoy diciendo que cada vez que se añada un nuevo paquete (el cual contiene un programa), tendrá que construirse para x86 y x86_64 en la máquina que tendrán a tal efecto y después, con los ficheros fuente (no con el paquete ya creado), compilar para ARM en el PandaBuilder éste.
    Te recuerdo que la compilación de los paquetes se hace a partir de los archivos fuente, por lo que una cosa no depende de la otra, y por otro lado, el tener que compilar los paquetes para cada arquitectura bajo la cual se pretende funcionen los programas, es inevitable.
    Ya, ya lo se. No estoy diciendo lo contrario. Por eso digo que me parece un paso atrás tener que compilar todo desde 2 máquinas distintas (una para x86 y x86_64 y otra para ARM), cuando desde una misma máquina se podría hacer todo.
    - hsierra
      Pues ahora si esta más claro. Sin embargo me parece que usar los mismos equipos para compilar paquetes para distintas arquitecturas, si obligaría a hacerlo en la forma que describes, dado que, obviamente el compilador es incapaz de compilar simultáneamente para ambas arquitecturas.
      Por otro lado, tener equipos dedicados a compilar para cada arquitectura, si permite realizar la tarea de forma simultanea y proporciona independencia a ambos proyectos, porque nadie tiene que esperar a que el otro termine para trabajar.
      En todo caso, me parece que el punto a destacar del PandaBuilder no es si representa realmente un avance o no, sino el que con unos cuantos cientos de dolares han logrado armar un equipo para realizar el trabajo.
      - Annubis
        Sin embargo me parece que usar los mismos equipos para compilar paquetes para distintas arquitecturas, si obligaría a hacerlo en la forma que describes, dado que, obviamente el compilador es incapaz de compilar simultáneamente para ambas arquitecturas.
        http://en.wikipedia.org/wiki/Cross_compiler
      - hsierra
        Ok. Sabias algo que no sabia yo.
Carlos
Warning! off topic!
http://www.phoronix.com/scan.php?page=article&item=phoronix_dirndl_final&num=1
El muchacho sigue dando pistas…
Espero que no termine siendo un Epic Fail…
- Pavloco
  Ya vieron GPL!!! Eso me da gusto, tambien espero y no sea una broma de mal gusto.
  Deberían de darle mas seguimiento a la noticia. Solo es una recomendación.
Azur
JA se haorro el trabajo aunque aun asi es muy jodido y ninguno de ustedes supongo como mierda se hara eso asi que de carajo se quejan eh!?
Predatux
También podrían crear un proyecto de computación distribuida, al que la gente pudiese unirse usando software como BOINC. Me parece una fantástica idea y forma de ayudar de la comunidad.
yonose
En mi opinión este tipo de clusteing es algo dispendioso, entiendo claramente la razón y el enfoque de no tener que usar un cross-compiler para hacer la tarea para determinado nicho (perdon por ser tan vago, pero en la noticia tampoco hay mucho información), sin embargo esta reinvención de la rueda, aunque creativa e interesante, no es que sea muy útil.
No tengo buen hardware aquí, pero si tuviera grandes recursos con seguridad lo haría desde una granja de servidores o por cualquier método de grid computing, al estilo de BOINC, con el cross-compiler de la arquitectura diseñada… es más, y qué tal si necesito adaptar un sistema empotrado con ubuntu, o angstrom, o antroid o debian, para otras arquitecturas de ARM?? por ejemplo, ARM7TDMI o ARMV5tl o ARMV4t , qué tal si yo no quiero quedarme sólo con Cortex sera seria M o serie A?? Entonces, si no me equivoco, es necesario utilizar un cross-compiler con los procesadores ARM y de paso acomodar los “targets” para diversas arquitecturas y si no están los blancos para las demás arquitecturas de ARM, portarlos, lo cual no creo que sea mucho trabajo para un desarrollador experimentado, pero igual…
No me malentiendan, el proyecto es muy interesante, sino que francamente no le veo proyecciones a nivel industrial todavía!
saludos.

PandaBuilder: así se compila masivamente Ubuntu para ARM

Lo último

Suscríbete gratis a MuyLinux

Gracias, recibirás un correo para confirmar tu suscripción.