La Odisea de una aplicación comercial hecha en Ogre y CEGUI

Últimamente he estado concentrado en una tarea que considero extenuante, por la falta de información, y por la abundancia de respuestas que no aportan nada al caso. El dilema en cuestión es la distribución de binarios en Linux de una aplicación privativa, concretamente un juego hecho en OGRE y CEGUI. Y la verdad es que la odisea es larga. Así que he decidido comparar todas las opciones, sus pros y sus contras.

OGRE

Opciones

Las opciones que he valorado para comparar son:

  • Paquetería nativa DEB, RPM y TAR.XZ
  • Distribuir un TAR.GZ binario
  • Estatificar (palabro inventado) el binario
  • Paquetería multi-distro, Autopackage, Listaller

Paquetería nativa DEB, RPM y TAR.XZ

Esta opción, es a priori la más conveniente. El usuario dispondrá de un bonito paquete nativo (que se podrá actualizar) y se le gestionarán las dependencias, por ello ahorrará espacio en disco. Además tendrá una integración real con el sistema, lo podrá desinstalar desde donde acostumbra a desinstalar y el juego le aparecerá en los menús. Sin embargo los problemas salen enseguida, por una parte tienes que centrarte en ofrecer varios sistemas de distribución. Por otra parte, los paquetes nativos suelen no llevarse muy bien con otros paquetes de otras arquitecturas, ya que en algunos casos se nos pedirá instalar prácticamente el sistema de 32 bits encima del de 64, cuando realmente no es necesario. Además el tema de las dependencias es un arma de doble filo, pues en el caso de OGRE y CEGUI, o no hay, o están desfasadas. Así pues nuestro paquete puede quedarse inservible pronto. Y una peculiaridad de OGRE, resulta que tenemos que definir en plugins.cfg la localización de los plugins que usemos (normalmente con definir el de OpenGL ya sirve), pero la localización de esos plugins puede estar dispersa entre sistemas y arquitecturas. Con lo que deberíamos modificar el fichero plugins.cfg en cada sistema y arquitectura.

Distribuir un TAR.GZ binario

Visto lo anterior, parece ser más cómodo distribuir un TAR.GZ binario. Muchas aplicaciones como Oracle Java o Mozilla Firefox son distribuidas desde el sitio oficial usando este sistema. Sin embargo, y aunque pueda parecer una buena idea, tiene algún que otro inconveniente. En primer lugar debemos intentar usar librerías estáticas. Si las librerías que usamos tienen esa opción, correcto. Puede que esas librerías dependan en otras que no puedan ser estáticas, y aunque lo fueran, añadirían más carga al ejecutable y complejidad en la compilación. Si dependemos de librerías compartidas las podemos poner en una carpeta que tengamos dentro del TAR.GZ y usar RPATH con $ORIGIN o LD\_LIBRARY\_PATH. El caso es que hay ciertas herramientas que nos pueden servir para ello. Por ejemplo cpld nos puede servir para copiar todas las dependencias. El problema es que el proceso no puede ser automatizado completamente ya que el script no puede diferenciar una dependencia base de Linux de una que realmente debamos distribuir. Así que despúes de usar la herramienta nos tocará volver a revisar los ficheros que ha copiado ya que habrá copiado libc, libm, libpthread, libX11 y otras que posiblemente no necesitemos. Pero si no las copiamos podríamos tener problemas en sistemas de 64 bits. Una solución efectiva consiste en hacer un pequeño script que cargue las librerías según el sistema en el que estemos, habiendo usado el script en un sistema de 32 bits y en otro de 64 bits. Esto puede parecer razonable, pero tanto OGRE como CEGUI usan una arquitectura basada en plugins. Estos plugins no pueden ser analizados por ninguna herramienta y deberemos saber manualmente que plugins tendremos que pasar a  el comprimido. Por supuesto debemos separar las dos arquitecturas. En OGRE es fácil pasar los plugins ya que por defecto se usa el fichero plugins.cfg para leer los plugins, pero CEGUI no tiene esa característica (o yo no la he encontrado). Sin embargo es una alternativa muy sólida.

Estatificar

Una opción que encontré mientras buscaba una solución se puede llamarla como estatificar. Es un método poco común que coge las dependencias compartidas y las empaqueta en un único binario. No se debe confundir con compilación estática ya que estatificar requiere un binario ya compilado con dependencias. Únicamente hay dos aplicaciones que hacen esta función, y las dos son del mismo creador, aunque difieren en el funcionamiento de base. Por un lado Statifier, open source y gratuita, trabaja a un modo más rudimentario; por otro lado, Magic Ermine, trabaja con un sistema más perfeccionado, es de pago pero tiene una demo gratuita para probar. Los resultados no eran muy buenos, Statifier modificó el binario de manera que ya no arrancaba, por otro lado Magic Ermine funcionaba correctamente, pero el plugin de OpenGL de OGRE usa libGL.so, y como es cargada dinámicamente, Magic Ermine no sabe que tenía que empaquetarla y como consecuencia falla con un bonito error.

Paquetería multidistro

Autopackage, Listaller, 0install, … Prometen mucho pero no funcionan bien. Autopackage ha sido descontinuado en favor de Listaller, Listaller se tiene que integrar con AppStream y PackageKit, pero esos mismos componentes no están finalizados, Listaller falla más que una escopeta de feria en la práctica y la documentación es pésima. Realmente espero que mejoren ya que prometen mucho, pero no se cuando será realmente usable. 0install trabaja de otra manera y al menos en mi caso, fallaba y no podía siquiera empaquetar una simple aplicación. Esta opción quizá en otro momento, pero ahora no.

Conclusión

Hemos visto 4 opciones. Dos de ellas no funcionaban bien en la práctica (estatificar y la paquetería multidistro), las otras dos eran tediosas, pero si se estudia al detalle puede funcionar bien. Así pues podemos elegir entre la paquetería nativa y el TAR.GZ binario con scripts de dependencias. Así pues cada cuál elija la que más le guste.

loading...

GAJSE, una carta de presentación

Si me seguís en Google+ sabreis que hace poco he anunciado públicamente la existencia de GAJSE. Hoy os voy a hablar un poco más sobre GAJSE y todo lo relacionado. En primer lugar comentar la idea, GAJSE nace con el objetivo de cubrir el nicho de las aventuras gráficas en 3D en el navegador. Busqué y no encontré nada parecido, solamente había motores 2D para el navegador. Así pues, y después de jugar a Grim Fandango, el proyecto comenzó. He estado aprendiendo node y npm por el camino, de modo que todavía GAJSE no es un proyecto 100% node, pero espero que lo sea rápidamente. En GAJSE he buscado facilidad a la vez que flexibilidad. De momento GAJSE no hace mucho por sí solo, pero espero que eso mejore. Todo puesto en su lugar para que en un determinado momento se puedan generar los juegos desde un editor gráfico sin tocar una pizca de código. Más adelante les enseñaré como usar GAJSE de forma productiva pero espero que esto sirva de carta de presentación a GAJSE aquí, en mi blog.

Mis predicciones para el futuro (en lenguajes de programación) I

Recientemente he estado probando nuevos lenguajes de programación, he investigado un poco en su historia y he pensado en hacer unas predicciones para el futuro de los lenguajes más populares.

Python
Python va a subir su popularidad con a corto plazo debido a su implantación en la educación. Si se consigue la transición a Python 3 que la gente lleva esperando tanto tiempo podría estabilizarse pero si no tendríamos en el problema de compatiblidad con grandes aplicaciones en Python 2. Quizá interese a largo plazo un nuevo JIT, de manera que este aumente su velocidad. Por estos motivos y teniendo en cuenta su sintaxis no de C creo que a largo plazo podría bajar considerablemente su popularidad.

Perl
Sencillamente cada vez va a bajar más. Es un lenguaje que para la mayoría resulta demasiado complejo teniendo otras alternativas para el scripting como Python, Bash o Node. Perl se seguirá usando en las tareas de compilación debido a la gran dependencia de las autotools pero no creo que evolucione mucho más de lo que es. Habrá que ver como reacciona la gente con Perl 6. Mencionar también que los sitios usando CGI van poco a poco a ir desapareciendo. De hecho el módulo de CGI está desrecomendado dentro de Perl 5.22 .

Node y JavaScript
Le veo un gran futuro a esta plataforma, al igual que a las bases de datos al estilo de MongoDB y al gran gestor de paquetes NPM. Su rapidez y el concepto de asíncrono van a ser sus grandes bazas. Me parece que va a ser un gran contrincante en el mundo web y también para el scripting, pudiendo sustituir eventualmente a Python y Perl en esas tareas. En el lado del cliente su uso es obligatorio pero va a crecer mucho con las tecnologías HTML5.

PHP
Se estabilizará bastante. Dentro de lo que cabe, es rápido para la poca memoria que gasta en comparación con otros lenguajes (Python, Java,…). Se va a seguir usando bastante sobre todo debido al gran público que conoce PHP. Además muchas empresas seguirán usando PHP antes que arriesgar con otros lenguajes más novedosos.

Java
Perderá adeptos. El modelo actual de Java es a mi parecer demasiado estricto y complejo y además cuenta con limitaciones de soporte en escritorio y perdida de velocidad en la web. Opino que si bien Java es de los lenguajes más populares, va a perder comunidad, que se va a desplazar a otros lenguajes más cómodos. Pero será muy gradual debido a la misma razón que PHP, muchas empresas seguirán usando Java un tiempo

Ruby
Ruby va a ser más importante sobre todo en scripting local, y quizá algo menos en web. La razón es que Ruby no aporta atractivas ventajas para las empresas al cambiar de PHP o Java a Ruby. Por eso creo que va a crecer más en scripting local, aunque posiblemente las startups usen Ruby para sus proyectos.

C y C++
Grandes proyectos seguirán usando C y C++ y muy dificilmente cambien. Los nuevos proyectos quizá se sientan menos atraídos por C++ teniendo Rust y Go, pero aguantará mucho.

C#
Crecerá. En cuanto la plataforma .NET se abra más a diferentes sistemas, el crecimiento será exponencial. Y ese es el rumbo que se está tomando con iniciativas como Xamarin o ASP.NET vNext, que han comunicado que será open-source y funcionará sobre Mono en Mac OS X y Linux.

Rust
Creo que este lenguaje va a dar mucho que hablar, no hoy, pero sí en un futuro a medio plazo. Rust aporta ventajas al venerado C++ y conserva su velocidad. Creo que Rust va a ocupar un lugar en los videojuegos, creo que en algún tiempo veremos algún Triple A hecho en Rust como lenguaje principal.

Seguiré con mis predicciones en otro post

La Semana en Adrianistán (IV)

Con un día de retraso llega una nueva entrada de La Semana en Adrianistán. Empecemos:

  • GAJSE ha añadido soporte para eventos cuando el usuario choque con un objeto.
  • DivCity ha mejorado en lo relativo al display de las Cells e incluye un nuevo concepto para modificar las Cells, las Tools.
  • DivPacker, un nuevo proyecto, que espero que sea simple y divertido
  • Tengo nueva página oficial. Mi nueva página pasa a estar disponible en http://adrianarroyocalle.github.io Basada en una temática de una ciudad, es muy colorida.