jueves, mayo 30, 2013

Notas sobre la Xbox One y la Playstation 4

Estos últimos dos meses he seguido con bastante interés las presentaciones de la siguiente generación de consolas de Sony y Microsoft, la PlayStation 4 y la Xbox One. Hay varios puntos que han captado mi interés:

  • Ambas están diseñadas para ser el centro de entretenimiento en los salones de las casas. Los negocios no son ya sólo los juegos, sino todo tipo de contenido multimedia que pueda llegar a los televisores a través de las mismas. Un filón que tanto Sony como Microsoft quieren explotar al máximo.Esto implica sistemas diseñados para trabajar permanentemente conectados a Internet, no sólo para bajar el contenido sino para tener un control mucho más estricto sobre lo que se ve, se hace o se juega.
  • En la parte más técnica ambas giran entorno a un SoC de AMD - un chip que integra los núcleos de proceso, el hardware gráfico, los controladores de memoria y los diversos interfaces dentro de la misma oblea de silicio. Ambas consolas usan una APU de AMD cuya microarquitectura se llama Jaguar, de la cual se puede encontrar un buen análisis en este artículo AMD’s Jaguar Architecture. Ambas llevan unidades de blue ray, 8 Gb de RAM - eso sí, con mucho más ancho de banda la GDDR5 que monta la PS4 frente a la XBox One - , 8 cores cada una, Wifi, discos duros y puertos USB
  • A día de hoy es probable que las consolas no se compren por su potencia de proceso bruta sino por las franquicias de juegos que tenga. En eso, parece ser que Microsoft intenta ponerse al día, al menos en la presentación de la Xbox , se hablaba que iba a tener 15 franquicias en exclusiva. Cada vez más cualquiera de estos juegos necesita equipos de desarrollo y presupuestos más cercanos a una superproducción de cine de Hollywood.
  • Enlazando con lo anterior, estoy bastante interesado en el desarrollo independiente de juegos, indie en el argot. Parece ser que Sony tiene claro que quiere atraer a los desarrolladores independientes a su plataforma, y cuanto más haya dotándola de contenido mejor. En el caso de las Xbox One no está tan claro que el soporte sea tan sencillo, al menos por ahora. Veremos que ocurre cuando las plataformas estén en la calle. Tampoco me extrañaría que llegado el momento, intentasen ambos fabricantes imitar los modelos de tienda de aplicaciones de Apple o Google. No olvidemos que estos dos fabricantes se están comiendo el mercado de juegos móviles en detrimento de plataformas como la Nitendo DS o la PlayStation Vita.
  • Una cosa que me preocupa bastante es las posibles implicaciones que tiene la obligatoriedad del sensor Kinect en la Xbox One, unido a la necesidad que la consola esté conectada a Internet, para chequear información, por el momento desconocida. No olvidemos que este sensor es una cámara, y que por el diseño de la consola esta siempre está activa, aunque en diversos estados de consumo de energía. Esto ha levantado algunas suspicacias respecto a la privacidad y posibles usos del sensor. Por ejemplo, Microsoft tiene una patente de uso del Kinect para contar las personas que están enfrente del mismo.

Pocas más noticias tendremos hasta el próximo E3 2013. Personalmente espero más información sobre el desarrollo indie de juegos, las características técnicas de las consolas y cual será el uso permitido de los juegos en las mismas. Hay bastante preocupación de que tanto Sony como Microsoft intenten acabar con los mercados de segunda mano para obligar a que todo el mundo pase por caja, algo que el modelo de tienda de aplicaciones de Google y Apple parece que están logrando.


Technorati Tags: ,

domingo, mayo 26, 2013

Airport Express, utilidad de configuración versión 5.6 y MacOS X Lion

Tengo un viejo punto de acceso de Apple, un Airport Express, de primera generación, que soporta redes wifi con los estándares b o g. El programa que por defecto viene incluido en MacOS X Lion, no soporta este tipo de estaciones base, es necesario bajarse e instalar la Airport Utility 5.6 para Lion. Todo parece sencillo, pero en realidad no lo es, el instalador que suministra Apple falla.

Lo primero que hay que ver en caso de error de instalación son los registros que el sistema deja en el fichero /var/log/install.log. Puede verse ejecutando la aplicación Terminal.app, yendo al directorio y usando cualquiera de las utilidades de la línea de comandos como puede ser more, o bien usar la aplicación Consola que está en dentro de la carpeta utilidades de la carpeta aplicaciones. En cualquiera de los dos casos es necesario un usuario con privilegios de administración del sistema para poder ver dicho fichero. En el mismo podía encontrar cada vez que intenta la instalación las siguientes líneas de registro:

May 24 00:20:08 swordcoast installd[62762]: ./preinstall: nothing found to unload
May 24 00:20:09: --- last message repeated 1 time ---
May 24 00:20:09 swordcoast _securityagent[62791]:Error stopAPD.sh: 256

Vaya, todo parecía indicar que había un error en uno de los scripts, stopAPD.sh que venían con la instalación del paquete.Lo primero que tenía que hacer era extraer los ficheros del paquete y ver el contenido del script para intentar averiguar la causa del fallo. Con la ayuda de la utilidad pkgutil se extraen los contenidos del fichero pkg de instalación a un directorio que nos interese. Una vez realizada la operación, localizar el script stopAPD.sh

pkgutil --expand /Volumes/AirPortUtility/AirPortUtility56.pkg  ~/tmp/airport
cd ~/tmp/airport/AirPortUtility56Lion.pkg/Scripts/preinstall_actions
Dentro de dicho directorio está el script que causa los problemas: Intenta parar a través de launchd el servicio que se especifica en el fichero com.apple.AirPortBaseStationAgent.plist, el cual no existe en mi máquina. La solución para que funcione la instalación es crear uno correcto - porque posteriormente el sistema lo reescribirá - , y para ello, dentro del directorio /System/Library/LaunchAgents/ cree un fichero llamado com.apple.AirPortBaseStationAgent.plist, simplemente copiando el contenido del fichero org.openbsd.ssh-agent.plist que se encuentra en dicho directorio. Lancé la instalación y finalizó sin problemas.


Technorati Tags: ,

lunes, mayo 13, 2013

vim:Usar el resaltado de sintaxis para generar código HTML

Hoy en día, casi cualquier editor tiene soporte para el coloreado de sintaxis en función del tipo de fichero que se esté editando.En vim es muy fácil de activar con la orden :syn on en modo comando. Ahora, no todos son capaces de coger dicho texto editado y exportarlo como fichero HTML para que pueda usarse en una página web. Aunque hay herramientas como GNU Source-highlight o algunas web como Online syntax highlighting que realizan esta labor, el script 2html.vim de vim, consigue resultados muy buenos usando los esquemas de color del editor. Si estamos editando un fichero, se puede crear un fichero HTML completo a partir del mismo ejecutando la siguiente orden en modo comando:

:runtime! syntax/2html.vim

La orden anterior dividirá la ventana que se está editando en dos, y en la nueva ventana insertará el código HTML correspondiente al contenido de la ventana desde la cual se ejecutó. En la siguiente captura de pantalla puede verse el resultado de ejecutar dicho script cuando se está editando un pequeño programa en C:


Resultado de ejecutar 2html.vim

La salida de esta orden es una página HTML completa.A partir de aquí, se puede coger las partes que interesen para insertarlas en el código HTML que se esté editando. Las propiedades del texto se controlan a través del uso de CSS, se pudiéndose modificar de acuerdo a nuestros intereses.

Por ejemplo, los listados de esta entrada del blog están hechos usando este script, insertando el código CSS está insertado en la plantilla del blog


Technorati Tags:

sábado, mayo 11, 2013

Como algunas administraciones públicas facilitan la labor empresarial

Hace unos días me pasaron un enlace al siguiente vídeo.

Por desgracia lo único que demuestra es que ciertas administraciones públicas pasan más tiempo creando burocracias y leyes para justificar su existencia que estando al servicio de los ciudadanos. Luego no debemos extrañarnos de los casos de sobornos y tráfico de influencias a la hora de buscar la documentación y abrir obtener los permisos necesarios para abrir cualquier actividad por inocua que ésta sea.

No he podido dejar de pensar en la ironía que supone los machacones mensajes de todos los políticos durante esta crisis a la hora de hablar de emprendedores y de la creación de empresas que a su vez, permita crear puestos de trabajo para bajar la vergonzante tasa de paro de este país: Si los primeros que ponen todas las trabas son los mismos que se les llena la boca con la palabra emprendedor.


Technorati Tags: ,

martes, mayo 07, 2013

Autotools, tutorial de uso (II): Un ejemplo sencillo

En esta segunda entrada sobre las autotools voy a describir un sencillo ejemplo que compila un programa en C. El código fuente del mismo se puede bajar del git autotools-tutorial. En el directorio tut1 se encuentran las plantillas Makefile.am y configure.ac, un subdirectorio m4 con un fichero de macros ,acexample.m4 - vacío de momento - , el código fuente que se va a compilar, tut1.c y por último un shell script que va a ejecutar los diferentes herramientas de las autotools para generar los ficheros intermedios.

Cuando las distintas herramientas procesan las plantillas, se va sustituyendo aquellas construcciones que reconoce copiando a los ficheros de salida el resto de la entrada. El resultado de procesar el fichero configure.ac, será un fichero configure, que no es más que un shell script, con lo cual se podrá incluir código Bourne Shell1 que las diferentes herramientas copiaran sin tocar - o haciendo las sustituciones correspondientes - , mientras que la plantilla Makefile.am se puede incluir código de Makefile que será copiado sin modificar a la salida.

A continuación se describe un pequeño ejemplo de las plantillas para generar el script configure y a partir de la ejecución del mismo se generan los Makefile, que permitirá compilar un programa simple:

configure.ac

 1 dnl Esto es un comentario
 2 dnl Esta macro fuerza a una versión mínima de autoconf
 3 AC_PREREQ([2.59])
 4 AC_INIT([tut1],[1.0],[cterron@users.sourceforge.net],[tut1.tar.gz],
 5         [https://sourceforge.net/p/autotutorial/])
 6 dnl Necesitamos el compilador de C
 7 AC_CONFIG_HEADERS([config.h])
 8 AC_PROG_CC
 9 dnl Init automake 
10 AM_INIT_AUTOMAKE
11 dnl Debe de ir al final de la plantilla. Genera el fichero config.status
12 AC_CONFIG_FILES([Makefile])
13 AC_OUTPUT

El fichero configure.ac es procesado por varias utilidades - autoconf, autoheader y automake -. Es procesado por el macroprocesador m4. En este pequeño ejemplo se pueden ver algunas de las características de este lenguaje de macros:

  • En primer lugar tenemos la macro dnl. Esto lo que hace es descartar toda la entrada del fichero hasta el fin de línea, lo cual es útil para poner comentarios. También nos puede server el símbolo #.
  • AC_PREREQ es una macro es opcional, pero nos sirve para indicar cual es la versión mínima de autoconf que se va a usar. En este caso se necesita como mínimo la versión 2.59. Aquí se puede ver una característica del lenguaje m4, que es el paso de parámetros: Estos tienen que ir encerrados entre corchetes, [2.59]
  • AC_INIT es la macro que se encarga de emitir el código en el configure que se encargará de realizar la inicialización del script. Tiene dos parámetros obligatorios, que son el nombre del paquete y la versión (tut1 y 1.0 en el ejemplo). Los otros tres parámetros son opcionales. Esta macro debe de estar presente en el fichero antes de cualquier macro que genere una salida. La definición de esta macro generará una serie de variables que se podrán usar en el fichero configure, así como unas macros de preprocesador, que también podremos usar.
  • AC_CONFIG_HEADERS Esta macro va a generar un fichero de definiciones en C, cuyo nombre final se pasa como parámetro, en este caso config.h. Pero para generar dicho fichero, por defecto el script configure que se generará espera encontrar un fichero config.h.in que se genera a partir del procesamiento de este fichero por autoheader..
  • AM_INIT_AUTOMAKE Esta macro es la encargada de inicializar todo el conjunto de código necesario para poder procesar los ficheros Makefile.in y generar los Makefiles. Puede llevar una lista de parámetros opciones que se utiliza para procesar cada fichero Makefile.am.
  • AC_CONFIG_FILES Esta macro especifica que ficheros de salida debe de crear el automake. En este ejemplo sólo queremos crear el fichero Makefile en el directorio actual.
  • AC_OUTPUT Procesa la lista de ficheros que se especifica. En este caso, puesto que los Makefile se están especificando con la macro AC_CONFIG_FILES no es necesario poner parámetros. Si se le da una lista de parámetros, son nombres de fichero separados por espacios, lo que hará el sistema es procesar el nombre junto al sufijo .in cuando se ejecute. Por ejemplo AC_OUTPUT([start.py]), hará que cuando se ejecute el configure el sistema busque start.py.in y lo procese de manera adecuada. Puede llevar dos parámetros opcionales que indican comandos antes y después de ejecutar la salida del fichero.

Makefile.am

1 bin_PROGRAMS= tut1
2 tut1_SOURCES = tut1.c

El formato que sigue la plantilla de Makefile.am es muy similar: Siempre un nombre y un sufijo separado por un subrayado. Así:

  • En primer lugar está bin_PROGRAMS que es una lista separada por espacios de los programas que se van a compilar y que se instalarán cuando tras compilar se ejecute la orden make install. La instalación por defecto será en $prefix/bin, lo que en la terminología de GNU se llama bindir2
  • La segunda línea nos define cuales son los ficheros fuentes necesarias para compilar el binario tut1, en este caso sólo tenemos tut1.c

Generación de los scripts

Aunque el script autogen.sh que hay en el directorio de ejemplo hace todos los pasos, a continuación se detallan para que se puedan ver cuales son pasos:

1 aclocal -I m4
2 rm -rf autom4te.cache/
3 autoheader
4 automake --foreign
5 autoconf

En primer lugar se genera el fichero aclocal.m4 ejecuanto aclocal, en el mismo directorio donde está el resto de ficheros de plantilla. Se va a usar las macros que estén en el directorio m4, cosa que pasamos como parámetro con la opción -I. Decir que, aunque no estaba en el dibujo que se publicó en la entrada anterior, al ejecutar aclocal se incluirá diversas definiciones de macros en el fichero aclocal.m4, entre otras, aquellas que definen las macros que usará automake

La segunda orden borra un directorio caché que crea las diversas ejecuciones de las autotools para ir más rápido en la ejecución

autoheader va a recorrer el fichero configure.ac, para encontrar la primera llamada a la macro AC_CONFIG_HEADERS de donde tomará el nombre del fichero de salida que va a generar, añadiéndole el sufijo .in. Así si dicha macro tiene como parámetro el nombre config.h, generará un fichero llamado config.h.in donde estará las posibles definiciones que se hayan hecho en el configure.ac.

automake va a generar los ficheros Makefile.in a partir de los Makefile.am que se tengan en los directorios. Generará las reglas por defecto, definirá variables, definirá todos los objetivos estándar de construcción (install, install-exec,clean, ....). Algunas definiciones que serán procesadas cuando se ejecute el configure quedará entre símbolos @, para ser procesado posteriormente por configure. El parámetro --foreign le indica al automake que es un proyecto que no sigue con los estándares GNU a la hora de tener ciertos ficheros de documentación. Un trozo de un fichero Makefile.in generado a partir del Makefile.am puede verse a continuación.

....
 15 @SET_MAKE@
 16 
 17 VPATH = @srcdir@
 18 pkgdatadir = $(datadir)/@PACKAGE@
 19 pkglibdir = $(libdir)/@PACKAGE@
 20 pkgincludedir = $(includedir)/@PACKAGE@
....

Pueden verse variables que definirá el proceso (por ejemplo $(libdir)) o zonas de texto cuyo valor será sustituido cuando se ejecute el configure y procese este fichero (por ejemplo @SET_MAKE@ o @PACKAGE)

Por último, autoconf procesará el fichero configure.ac para generar el fichero configure. Una vez generado lo podemos ejecutar con ./configure, y podremos ver como se procesa los ficheros, y se generan los ficheros Makefile.

Documentación

Notas

  1. Curiosamente, hay que usar construcciones lo más compatibles posible, porque no todos los Bourne Shell se comportan igual.
  2. Estoy adelantando información, ya que el configure define una serie de variables - a fin de cuenta es un shell script - que se pueden usar a lo largo de todo nuestro sistema para especificar directorios u otros valores de configuración.

Technorati Tags: ,