Getting freedesktop notifications from Telegram CLI

NOTE: In the comments section, AleixDev proposes a simpler solution, calling an external process. Take a look at it if you don’t want to build cdbus and l2dbus by yourself.

Lately, Telegram is gaining a lot of traction as an alternative to WhatsApp. From my point of view, that’s quite cool for a variety of reasons, specially for features like secret chats, but also due to the (reasonably) open nature of its protocol.

This openness will surely lead to a widespread adoption of the protocol, specially on Free Software IM clients (something that WhatsApp has stupidly rejected from its very beginnings, which is something that, IMHO, will hurt their business in the long term), making it available on multiple devices and Operating Systems, effectively ending vendor dictated restrictions and the pain of being forced to use a mobile touchscreen even when you’re in front of a computer with a full size physical keyboard.

In my particular case, until the protocol is implemented in Kopete (I’d like to do this work myself, but I don’t the time right now), I’m using the CLI client created by Vitaly Valtman. Using a command line program for messaging may look awkward to some people, but I’m quite comfortable with it. The only thing I was missing is being notified when a message arrives, so I’ve decided to do something about this.

It was clear to me that the better approach would be to create a DBUS connection for sending a notification through it, something that both KDE and GNOME desktops would know how to interpret and show. My initial intention was to modify the source code to implement this function, but since tg-cli supports Lua, a language I’ve head a lot about but I’ve never actually used, I’ve decided to give it a try, which also saves me from patching the source code.

Installing Telegram CLI with notifications

  1. Clone and build CDBUS:
  2. Clone and build L2DBUS:
  3. Clone and build Telegram CLI:
  4. Clone:
  5. (Optional) Grab a cool icon (you can download the official app logo from its repo), place it somewhere, and update the “icon_file” variable in notify.lua to point to it (use full path, not relative).
  6. Run Telegram CLI with notify.lua: ./telegram -s notify.lua

Have fun!

Aumentando la duración de la batería en GNU/Linux con PowerTOP

En los últimos años, gracias a las nuevas generaciones de procesadores optimizados para portátiles y a la proliferación de discos de estado sólido, hemos visto cómo aparecían ultrabooks cuya autonomía supera con holgura las 5 horas. Por otra parte, a mayor duración de la batería, mayor impacto en la misma tiene la configuración y el comportamiento del software.

Por fortuna, en GNU/Linux disponemos de PowerTOP, una herramienta desarrollada por ingenieros de Intel, que nos ofrece información detallada sobre la distribución del consumo energético, y una serie de recomendaciones para reducirlo.

Usando PowerTOP: ¿Qué procesos despiertan la CPU?

Desde hace varios años, los procesadores x86 ofrecen al sistema operativo la posibilidad de minimizar el consumo energético reduciendo la frecuencia del reloj (Dynamic frequency scaling), o incluso apagándolos parcialmente (saltando entre C-States). Lógicamente, el S.O. sólo puede hacer uso de estas funcionalidades cuando no hay ningún proceso reclamando ser planificado.


En esta línea, la primera pantalla de PowerTOP nos muestra información sobre los eventos que “despiertan” la CPU y el origen de los mismos. Conviene que revisemos la parte alta de dicha lista, en busca de algún proceso que no debiera estar allí. Puede sonar extraño, pero dependiendo del escritorio y la distribución que estemos empleando, nos podemos encontrar con un gestor de ventanas que no para de lanzar eventos, o con alguna aplicación de sincronización en la nube que está “demasiado activa”.

Usando PowerTOP: Opciones recomendadas

Una funcionalidad especialmente útil de PowerTOP, es la que nos muestra una lista de configuraciones recomendadas para el S.O. que no tenemos activas, y nos indica el comando que debemos ejecutar para reestablecerlas.


Es posible activar dichas opciones pulsando enter sobre ellas, pero dicha configuración no es permanente, y ser perderá tras un reinicio. Una forma sencilla de extraer los comandos para cargarlos en el rc.local (o el equivalente que use nuestra distro), sería algo así:

slp@linux-18od:/tmp> # Generamos un informe en CSV con PowerTOP
slp@linux-18od:/tmp> sudo powertop --csv
Cargado 260 medidas previas
RAPL device for cpu 0
RAPL device for cpu 0
RAPL device for cpu 0
Preparing to take measurements
Taking 1 measurement(s) for a duration of 20 second(s) each.
PowerTOP outputing using base filename powertop.csv
slp@linux-18od:/tmp> # Editamos el fichero powertop.csv, y eliminamos todo menos en la sección "Software Settings in need of Tuning"
slp@linux-18od:/tmp> vi powertop.csv
slp@linux-18od:/tmp> # Preparamos un pequeño script para extraer la parte que nos interesa:
slp@linux-18od:/tmp> cat > << EOF
import re

file = open("powertop.csv", "r")
lines = file.readlines()
for l in lines:
    m = re.match(".*?;(.*)", l)
    if m:
slp@linux-18od:/tmp> # Y hacemos uso de él
slp@linux-18od:/tmp> python > commands
slp@linux-18od:/tmp> # Finalmente, revisamos el fichero y hacemos copypaste a nuestro rc.local
slp@linux-18od:/tmp> vi commands

Tras reiniciar, al volver a la misma pantalla de PowerTOP, deberíamos ver cómo todas las configuraciones parecen como ya establecidas:


Running RISCOS on QEMU

UPDATE (17/09/14): Some time after writing this, I’ve replaced the QEMU repository referenced here with a clean one without the changes needed for running RISCOS. I’ve just created another repository with the proper sources:

Some time ago, while trying to get NetBSD to run on Efika MX Smartbook (I should write about that), I’ve decided that I would never do any serious OS development on a platform without a JTAG interface, or a working emulator. Being able to stop the execution at will, for looking at the CPU registers, or examining an arbitrary memory location, will save you a lot of hours otherwise invested in a painful trial and error cycle.

For this reason, when I’ve decided to try and do some hacking on RISCOS (and I’m not going to lie, I was attracted by their bounty program), the first option I’ve considered was trying to get it to work under QEMU. This serves a double purpose: establishing a comfortable development environment, and getting myself to know RISCOS internals and its build process.

Nowadays, in addition to other platforms, RISCOS is able to run on BeagleBoard (OMAP3) and Raspberry Pi (BCM2835). I have access to a real RPi, so being able to emulate this platform would allow me to do most part of the coding under QEMU, and then verify the results with a physical device.

The bad news is that QEMU, as is, doesn’t emulate the BCM2835 SoC. True, some people are running Raspberry Pi GNU/Linux distributions under QEMU, but this is being done with a trick, replacing the original kernel with one compiled for VersatilePB SoC, which is fully emulated under QEMU. As the userland doesn’t care much about the SoC (it just needs a platform compatible with its ABI, which it’s mostly the case, unless you’re applying some NEON/VFP3 optimizations), this approach works reasonably well. But, for this strategy to work for RISCOS, I would need to do a new port to the VersatilePB platform, and that’s a project far beyond the size of what I initially considered.

Luckily, I’ve came across the amazing work being done by Gregory Estrade to add real BCM2835 emulation on QEMU. Older versions of RISCOS did run on qemu-rpi, but recent ones refused to boot. With a bit of hacking here and there, I’ve managed to get it to boot to the Desktop, but I still needed a working pointer.

As with the real RPi, the emulated one should be able to provide an USB mouse, but with pre-EHCI interfaces, data polling for USB pointer interfaces its just too expensive, and it showed an erratic behavior. I can’t say this came to me as a surprise, as I still remember the days when the first USB mouse got introduced to x86 desktops, and how it jumped around the screen when the CPU was slightly loaded.

Thinking about this problem, I’ve remembered that QEMU also features USB Tablet emulation. A tablet always provides absolute positions for the pointer, which makes it more precise, even when working with a lower interrupt rate. After applying an ugly and crude (but working!) hack to make QEMU provide resolution adjusted values that RISCOS could properly interpret as pointer positions, I’ve finally got a working RISCOS Desktop:


Running it yourself

To be able to run RISCOS on QEMU, follow this steps:

  1. Checkout my fork of qemu-rpi, switch to the rpi branch, and build it (you’ll only need the arm-softmmu target).
  2. Grab a RISCOS for Raspberry Pi SD Card image from here:
  3. Get my patched ROM: riscos.rom. Alternatively, if you have access to a RISCOS machine and the DDE, you can download this patch and build it yourself.
  4. Uncompress both files.
  5. Launch QEMU with something like this:
    qemu-system-arm -kernel riscos.rom -initrd riscos.rom -cpu arm1176 -M raspi -sd riscos-2013-07-10-RC11.img -d guest_errors -serial stdio -device usb-kbd -device usb-tablet -usb

Stuff to be done

  • Support for USB storages. This needs some fixes on the QEMU BCM2835 USB stack.
  • Network support. This needs some of the fixes mentioned above, and extending RISCOS support for USB CDC network devices.
  • Fix some graphic glitches.

Table: Libre Mobile OS Alternatives to Android.

Project Core Graphical Backend User Interface Applications Framework Main License Requires Proprietary Components Flagship Device
FirefoxOS Android/b2g GAIA Firefox HTML5+JS MPL Yes Geeksphone Keon/Peak
Ubuntu Touch Android/Ubuntu Mir Unity 8 Qt 5 (C++/QML) GPL Yes Nexus 4
Maemo Debian/Maemo X11 Hildon C+GTK ? Yes Nokia N900
MeeGo Maemo/Moblin X11 ? Qt 4.7 (C++/QML) GPL/LGPL Yes Nokia N9/950
Nemo Mer (MeeGo evolution) Wayland Lipstick Qt 5 (C++/QML) GPL/LGPL Yes Nokia N9/950
Plasma Active Mer (MeeGo evolution) Wayland Plasma Qt 5 (C++/QML) GPL/LGPL Yes ?

Desarrollando un videojuego sencillo (Parte II – Bucle principal y mapa del nivel)

Pequeño cambio de planes

Aunque en la primera parte había comentado que iba a usar Python+PyGame para escribir el prototipo, he cambiado de idea y voy a emplear HTML5 con JavaScript. Hay varias razones que me han animado a llevar a cabo este cambio:

  • Aparte de, no he trabajado mucho con JavaScript, y me apetece reforzar mi experiencia con este lenguaje.
  • JavaScript es también un lenguaje de alto nivel y, aunque no me entusiasma depender del navegador, debo reconocer los ciclos de coding<->debugging<->coding son bastante ágiles.
  • Me permite publicar los ejemplos funcionando en este mismo Blog.
  • Facilita la integración de funciones “sociales” que tan de moda están hoy en día, y con las que puede ser interesante experimentar más adelante.

El bucle principal

Habitualmente, el corazón del código de un videojuego está compuesto por un bucle principal que, al menos conceptualmente, suele ser similar a éste:

  1. Procesar los eventos de entrada.
  2. Actualizar la representación lógica del mundo.
  3. Pintar el mundo en la pantalla (representación visual del mundo).

Para este proyecto, voy a partir del código de del proyecto mortar-game-stub de Mozilla, que nos proporciona un canvas de HTML5 y el esqueleto de la aplicación JavaScript. La función principal se encuentra en el fichero www/js/app.js, donde podemos encontrar además una implementación básica del mencionado bucle (he añadido más comentarios para explicar su funcionamiento):

    // Bucle principal
    function main() {
        // Si nuestra pestaña en el navegador no es visible,
        // omitimos las actualizaciones.
        if(!running) {

        // Tomamos la referencia del tiempo transcurrido desde
        // la última iteración.
        var now =;
        var dt = (now - then) / 1000.0;

        // Procesamos los eventos y actualizamos el mundo.

        // Representamos el mundo en el canvas de HTML5.

        // Actualizamos la marca de tiempo.
        then = now;

        // Solicitamos al navegador que nos vuelva a llamar
        // cuando considere oportuno.


Pintando el mapa del nivel

Ahora que ya está localizado el bucle principal, hay que empezar a darle forma al juego. A la hora de  diseñar los componentes, se debe tener en cuenta que se tiene que trabajar tanto en su representación visual (cómo se va a ver el componente en la pantalla) como en su representación lógica (las estructuras de datos que permiten definir y manipular el componente en el código).

Voy a empezar por implementar el mapa del nivel, es decir, el mundo por el que se va a mover el personaje del jugador en cada pantalla del juego. Utilizando el Donkey Kong original como inspiración, quiero preparar algo sencillo, con plataformas a varias alturas y escaleras conectándolas. Mirando en el spritesheet del Platformer Art Deluxe, veo cuatro tiles que me pueden venir bien para empezar:













El primero representa la parte central de la plataforma, mientras que el segundo y el tercero se corresponden a los bordes derecho e izquierdo, respectivamente. El cuatro tile será la pieza base para construir las escaleras que conectan las plataformas.

Para poder hacer cambios de forma rápida, voy a hacer que cada nivel se represente en una rejilla de 15×12 celdas, y a definir el contenido de las mismas con números enteros. Como cada tile tiene un tamaño de 70×70 píxeles, la aplicación tendrá un resolución de 1050×840 (más adelante ya la ajustaremos convenientemente).

Dicha rejilla se puede implementar con un doble array (me niego a utilizar la traducción “arreglo”). Un nivel definido de esta forma, quedaría así:

var map = [

En este caso, los “0” representan espacios vacíos, los “1” se corresponden con el tile del bloque central, el “2” con el derecho y el “3” con el izquierdo.

Como se puede observar, este mapa no tiene representada ninguna escalera. La razón es que la parte superior de la escalera debe superponerse al bloque de la plataforma, lo que obligaría a incrementar el número de dígitos empleados para representar las combinaciones posibles. De momento, y con el objetivo de simplificar, he creado un mapa independiente para las escaleras:

var map_ladders = [

Si se mezclara este último mapa con el anterior, se vería que, efectivamente, las escaleras actúan como conectores entre las plataformas, y que la parte superior de las primeras se superpone con el bloque conectado. De todas formas, no hace falta imaginarlo, ya que va a ser posible verlo en cuanto se implemente el pintado del mapa en el canvas.

Como se ha visto en el código del bucle principal, éste llama a una función render que es la encargada de representar el mundo sobre el canvas. Ahora mismo, dicha función tan sólo rellena todo el espacio de color negro, y pinta un cuadrado verde para el jugador.

Voy a eliminar el contenido de la función para que pinte el mapa, pero antes necesito cargar las imágenes para tenerlas disponibles para su uso. Esta tarea se puede realizar añadiendo al principio de la función principal un fragmento de código como éste (he copiado previamente las imágenes que voy a emplear al directorio www/img):

    var imgGrassMid = new Image();
    imgGrassMid.src = 'img/grassMid.png';
    var imgGrassRight = new Image();
    imgGrassRight.src = 'img/grassRight.png';
    var imgGrassLeft = new Image();
    imgGrassLeft.src = 'img/grassLeft.png';
    var imgLadderMid = new Image();
    imgLadderMid.src = 'img/ladder_mid.png';

    var ASSETS = new Array();

El array ASSETS, con ese push vacío al principio, me proporciona una forma sencilla (aunque algo sucia) de posicionar los recursos gráficos en el mismo orden que estoy usando para representarlos en el mapa.

Ahora que los tengo cargados, ya puedo pintarlos en el canvas:

    function render() {
        // Pintamos todo el canvas de azul claro
        ctx.fillStyle = 'lightblue';
        ctx.fillRect(0, 0, canvas.width, canvas.height);
        // Recorremos la rejilla pintando los tiles representados
        // en la misma.
        for (var y=0; y < 12; y++) {
            for (var x=0; x < 15; x++) {
                var imgNum = map[y][x];
                if (imgNum != 0) {
                    ctx.drawImage(ASSETS[imgNum], x * BLKSIZE, y * BLKSIZE);
                var ladderNum = map_ladders[y][x];
                if (ladderNum != 0) {
                    ctx.drawImage(ASSETS[4], x * BLKSIZE, y * BLKSIZE);

Con esto, ya está implementada la representación lógica y visual del mapa, y el primer nivel del juego queda representado en el navegador:


Por supuesto, esta implementación de la función render es muy ineficiente, ya que se está pintando toda la pantalla indistintamente de lo que cambie. Una de las tareas que será necesario hacer en el futuro, será detectar qué partes de la rejilla han cambiado, y hacer que se pinten sólo estas últimas.

En la siguiente parte, añadiré el personaje del jugador y una lógica sencilla de movimiento, para que el juego empiece a ser algo interactivo.

Desarrollando un videojuego sencillo (Parte I – Introducción)

Durante mi carrera profesional, he tenido la fortuna de ir probando varias de las distintas vertientes que tiene el campo de las TI. Empecé como técnico de hardware, de ahí pasé a administrador de sistemas y, finalmente, llevo casi cuatro años desarrollando software, con la suerte de haber podido trabajar en proyectos de diversa naturaleza. Durante todo este tiempo, además, he ido complementando mi formación con proyectos personales, especialmente en el área de los Sistemas Operativos. Pero, a pesar de ello, sigo teniendo una espinita clavada: desarrollar un videojuego desde cero. Así pues, he decidido ponerme manos a la obra y, de paso, contar mi experiencia en este blog.

Read More

Democracia representativa dinámica: una idea en bruto

Se suele decir que la democracia (haciendo alusión a la democracia representativa) es el menos malo de los sistemas políticos que ha puesto a prueba la humanidad. La situación actual ha evidenciado que lo de “menos malo”, ha pasado de ser un apelativo cariñoso, a un inmerecido piropo. El desgaste de este sistema es cada día más evidente. Y la reciente demostración que ha llevado a cabo el PP de que es posible ganar unas elecciones diciendo “blanco”, para luego gobernar haciendo “negro”, es un achaque más de esta moribunda democracia.

Read More

Checking the health of your SSD from GNU/Linux

As you already know, SSDs degrade over time, as its memory cells support a limited amount of writes (a sacrifice that many people, including myself, find worthy in exchange to get rid of those slow and noisy mechanical disks).

This morning, while talking to a colleague, an interesting question was raised: how do we know when our SSD is near to day of its defunction?

Expensive, enterprise-grade SSD cards, like the ones from TMS, come with monitoring tools and a nice entry in “/proc” that can be easily checked by a script. But I had no idea if there’s some similar for consumer SSDs.

Turned out it was quite easy. Most models provide health info via the S.M.A.R.T. feature, so you can obtain it with smartctl (on Fedora, this utility came into the package smartmontools:

[slopez@slp-work ~]$ sudo smartctl -a /dev/sda
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
9 Power_On_Hours 0x0032 099 099 --- Old_age Always - 23
12 Power_Cycle_Count 0x0032 099 099 --- Old_age Always - 34
177 Wear_Leveling_Count 0x0013 099 099 --- Pre-fail Always - 1
178 Used_Rsvd_Blk_Cnt_Chip 0x0013 077 077 --- Pre-fail Always - 458
190 Airflow_Temperature_Cel 0x0022 067 051 --- Old_age Always - 33
235 Unknown_Attribute 0x0012 099 099 --- Old_age Always - 10

The most relevant attribute while checking the health of our SSD, is Wear Leveling Count (more info on Wear_leveling on Wikipedia). But don’t get fooled by its name, it’s not really a count, but an indicator of how healthy are the cells in your disk, where 100 is the best, and 0 the worst.

When this value falls below 20, you should start considering backing up your data and buying a new disk.

Java, Google y Oracle, un triángulo amoroso conflictivo

Piense por un momento en el número de aplicaciones Java que emplea usted con frecuencia. Ahora, repita el ejercicio con un usuario doméstico convencional. Lo más habitual será que responda “una” o “ninguna” en ambos contextos. Y es que, en la práctica, la presencia de aplicaciones Java en PCs de escritorio se limita en gran medida a un puñado de applets empleados en ciertos sitios web para superar algunas de las tradicionales limitaciones que imponían los lenguajes ejecutados en el navegador. Pero, a medida que estas limitaciones se reducen, lo hace también el ya de por sí estrecho marco funcional de dichos applets.

En el frente de los servicios web, la cosa no pinta mucho mejor para Java. La nueva generación de servidores de aplicaciones incumplieron la promesa de ponerse a dieta, y siguen siendo monstruos pesados, complejos y poco eficientes. Los frameworks más populares, sufren de los mismos síntomas. En conjunto, esto ha provocado que la mayor parte de empresas jóvenes del sector de las TI hayan evitado el uso de estas tecnologías (aunque no de la JVM, que gracias a lenguajes como ScalaGroovyClojurejRuby, parece estar viviendo una segunda juventud), al menos en el corazón de su negocio.

Y no es que no sea posible escribir aplicaciones eficientes en Java. OpenDJ es, probablemente, el servidor LDAP más rápido del planeta. A su vez, la evolución de los garbage collectors concurrentes, ha puesto fin (si el programador toma las precauciones apropiadas) a la temida recolección “stop-the-world”, lo que posibilita el uso de la JVM en entornos donde es crítico que los servicios resuelvan las peticiones en un tiempo limitado. El problema es, en mi opinión, el abandono total de cualquier visión pragmática en pos de la aplicación estricta, y casi enfermiza, de formalismos y patrones. Lo cual se traduce en que las tareas más sencillas se hayan convertido en el recorrido reiterativo de stack traces kilométricas.

Por fortuna para Java (y por desgracia para muchos programadores), le queda un reducto donde parece estar a salvo del embite del resto de lenguajes: el entorno financiero. Gracias al empuje que, en su momento, le dieron Sun, IBM y Oracle, este lenguaje se ha convertido (aunque algunos rechacen reconocerlo por las connotaciones negativas que conlleva) en el nuevo COBOL. Y no es de extrañar, ya que son precisamente estas empresas las más proclives a sacrificar rendimiento y flexibilidad, a cambio de la promesa de un entorno estable y predecible (que Java y sus frameworks sean realmente capaces de sostener esta promesa es un asunto bastante discutible, pero ese es otro tema).

Y entonces, llegó Android

Las circunstancias expuestas arriba hacen que, a pesar de ser un lenguaje que suele estar presente en los entorno académicos, Java perdiera el sex appeal entre los nuevos programadores. Pero entonces llegó Android, para el cual Google decidió que se usaría Java con una implementación de la API y la JVM desarrolladas por ellos mismos. Y con Android, la fiebre de las aplicaciones móviles se extendió a un nuevo terreno,siendo Java el vehículo preferente para recorrerlo. Y así, este lenguaje que parecía languidecer por momentos, obtuvo el balón de oxígeno que tanto necesitaba.

Pero a pesar del tremendo favor que Google le estaba haciendo a Oracle al empujar a las nuevas generaciones de ingenieros para que mantuvieran el interés por Java, los chicos de Larry Ellison decidieron denunciar al rey de los buscadores por el uso“inapropiado” de “su” lenguaje. Obviamente, la intención del gigante rojo no era otra que monetizar la inversión que hizo en Sun, y que parecía no encontrar forma de rentabilizar. Y como innovar no parece ser lo suyo, decidió probar por la vía legal. Que los abogados son más baratos que los buenos ingenieros. O por lo menos, visten mejor.

El caso es que así fue, y no puedo decir que me sorprenda. Oracle a los mandos de un negocio distinto de el de las bases de datos, es como un elefante en la cabina de un Boeing 747. Ni siquiera él mismo sabe qué hace allí, y lo más probable es que termine estrellándolo.

El paro y la reforma laboral, análisis de un ciudadano

Renuncia de responsabilidad

En primer lugar, quiero dejar claro que no soy un experto en economía. Simplemente soy un ciudadano más con cierta curiosidad, que lleva varios días recabando información sobre este tema. Mi intención con esta entrada es consolidar mi opinión, hacerla pública y aprender, si alguien tiene a bien corregirme (os invito a todos los que tengáis algo que aportar a dejar vuestros comentarios).

La evolución de la tasa de desempleo en España

Como muchos habréis visto en repetidas ocasiones, circulan por Internet y otros medios de comunicación un sinfín de gráficas que afirman representar la tasa de desempleo en España. Lamentablemente, muchas de ellas tienen un carácter claramente tendencioso, con la intención de culpar a unos y vanagloriar a otros.

En este artículo, voy a emplear la siguiente gráfica (extraída de este blog: en la que las proporciones son lineales y se remonta hasta 1976:

En ella podemos apreciar la siguiente evolución:

  • La gráfica comienza en un ciclo ascendente causado por la Crisis del Petróleo de 1973 y el complejo clima político de los últimos días del régimen de Franco y el proceso de transición. [1]
  • En 1985, tres años tras la entrada por primera vez del PSOE en el gobierno, se detiene la destrucción de empleo e incluso se reduce la tasa de paro hasta situarse ligeramente por encima del 15% entre 1989 y 1990.
  • Entre 1991 y 1992 se produce un ligero incremento del paro, hasta 1993 en que la crisis mundial de principios de los 90 irrumpe con fuerza en España. En este punto comienza un ciclo de destrucción de empleo que duraría hasta mediados de 1994, cuando el paro alcanzó el 24.1% [2].
  • A finales de 1994 comienza un nuevo ciclo de creación de empleo. Dicho ciclo comienza con el PSOE de Felipe González todavía en el poder (aunque algunos atribuyen erróneamente el mérito a su sucesor) y mantiene un ritmo de creación de empleo constante en los primeros años del gobierno de Jose María Aznar (PP), a excepción un ligero estancamiento en 1999.
  • Posteriormente, a finales de 2000 y principios de 2001, en la segunda legislatura del gobierno del PP, la creación de empleo se estanca alrededor del 10% y el paro sufre un ligero repunte. Esta circunstancia puede estar ligada a la conocida como “Crisis de las Puntocom”, aunque no he encontrado datos objetivos que avalen esta afirmación.
  • Entre 2004 y 2008, con el PSOE de José Luis Rodríguez Zapatero en el poder, la tasa de desempleo se mantiene razonablemente estable (el descenso que se aprecia en la gráfica está ligado a un cambio en el sistema de valoración de la E.P.A.)a pesar de la inyección de población activa que supuso la legación masiva de inmigrantes en situación irregular.
  • En 2008 estalla la crisis de la burbuja inmobiliaria y comienza un ciclo agudo de destrucción de empleo que lo dispara hasta la tasa actual del 20%.

Ideas que se pueden extraer del análisis de la gráfica

El primer hecho que me llama poderosamente la atención, es la tremenda inestabilidad del mercado laboral español, capaz tanto de destruir como de crear empleo en plazos extremadamente cortos. Esto es especialmente significativo cuando se compara con el grado de fluctuación de la tasa de desempleo con la otros países de Europa. En los últimos 10 años, la variación (valor en el punto máximo menos valor en el punto mínimo) en España ha sido de 11.8 puntos, mientras que en Portugal [3], Italia [4] y Francia [5] ha sido de 3.5, 2.4 y 2 puntos respectivamente.

Adicionalmente, la gráfica evidencia un claro efecto rebote entre el ciclo de creación de empleo que comenzó en 1994 y el actual de destrucción, poniendo de manifiesto que las estrategias de crecimiento promulgadas por el gobierno de Felipe González primero, y el de José María Aznar después, aunque fueron capaces de generar empleo rápido, crearon puestos de trabajo de mala calidad y en sectores poco competitivos.

Según la FEDEA (Fundación de Estudios de Economía Aplicada) [6] la inestabilidad de este modelo de crecimiento envenenado se nutre fundamentalmente de la dualidad del mercado laboral, repartido entre contratos temporales altamente precarios y contratos indefinidos ligeramente sobreprotegidos. Asimismo, también señala la falta de flexibilidad del sistema de negociación colectiva.

La reforma laboral del Partido Popular

Hace escasos días, el Partido Popular, esta vez con Mariano Rajoy al frente, promulgó una reforma laboral destinada a atajar la destrucción de empleo. Lamentablemente,dicha reforma no sólo no elimina el problema de la temporalidad, sino que lo empeora introduciendo un contrato de formación hasta los 30 años de edad y un contrato indefinido con periodo de prueba de un año (comportándose como un contrato temporal, a efectos prácticos).

Asimismo, a la hora de incrementar la flexibilidad del mercado laboral, en lugar de buscar un equilibrio de fuerzas razonable entre trabajadores y empresarios, otorga de golpe a estos últimos la potestad de variar las condiciones laborales de forma prácticamente unilateral.

Por otra parte, a pesar de que todos los implicados coinciden en señalar al empleo de baja calidad como la causa fundamental de la inestabilidad del modelo español, el plan del PP no contempla un incremento sustancial de las inversiones en I+D+i, ni una mejora efectiva del sistema educativo que incremente la cualificación de los trabajadores. Tampoco contiene ninguna iniciativa pública para el fortalecimiento del tejido industrial de carácter nacional.

A título personal, hay dos cosas que me llaman poderosamente la atención al respecto:

  • Que esta reforma, en su conjunto, esté claramente inspirada en reformas similares ejecutadas en otros países europeos, a pesar de que los datos señalan que el caso de España es único en la UE, y debería tratarse de forma particular.
  • El hecho de que el PP evite resolver el problema de la temporalidad y la calidad del empleo, a pesar de haber sido ambos reiteradamente señalados como principales causantes de la inestabilidad del marcado laboral. Esto me hace sospechar que su intención real no es otra que intentar reproducir el ciclo de crecimiento rápido que tuvo lugar entre 1994 y 2001, aún siendo sabedores de las consecuencias que esta estrategia ha tenido (y está teniendo). Espero equivocarme, pero todo apunta a que quieren volver a construir un gigante con pues de barro, con la esperanza de que se desplome cuando esté otro al mando.