7 consejos para mejorar tu privacidad en Android

Mucho se ha hablado de los peligros que conlleva la información que divulgamos en las redes sociales, existiendo incluso campañas de sensibilización al respecto. En cambio, es bastante menos conocido que, de forma silenciosa e inconsciente, vas dejando un rastro de las acciones que realizas con tu móvil, que algunas empresas recopilan y emplean para diversos propósitos.

En este guía te voy a dar algunos consejos sobre cómo reducir tu huella digital y limitar la cantidad de información que pueden recopilar sobre ti.

Read More

7 consejos para mejorar tu privacidad en Android

Mucho se ha hablado de los peligros que conlleva la información que divulgamos en las redes sociales, existiendo incluso campañas de sensibilización al respecto. En cambio, es bastante menos conocido que, de forma silenciosa e inconsciente, vas dejando un rastro de las acciones que realizas con tu móvil, que algunas empresas recopilan y emplean para diversos propósitos.

En este guía te voy a dar algunos consejos sobre cómo reducir tu huella digital y limitar la cantidad de información que pueden recopilar sobre ti.

Read More

Running Alan Cox’s Fuzix OS on a Z80 emulator

This past Halloween, Alan Cox announced Fuzix OS, a project for building a UNIX-like operating system for 8 bit computers, based on UZI sources. This OS targets a number of physical machines, both old and homebrew computers, and some emulators too.

The easiest and more approachable way for trying Fuzix OS is running it on cpmsim, which comes bundled inside the Z80pack package. If want to give it a try the easy way, just continue reading.

Read More

My answers to Interstellar questions

As he already did in movies like Inception or Memento, Christopher Nolan has introduced some big open questions in his latest movie, Interstellar, leaving to the spectator the task of filling the blanks with his own interpretation.

I’ve decided to give it a shot, writing here my answers to such questions. As it’s obvious, from this point, there will be HUGE spoilers, so stop reading if you haven’t watched the movie yet (and go to your nearest theater right now! ;-).
Read More

Porting socz80 (a retro microcomputer) to DE0-nano

UPDATE: Mikolas has added support for the DE2-70 board. Check his repo here: https://github.com/mikolas/socz80-de0_nano

Due to my intrinsic, chronic curiosity, for a long time I wanted to get a in touch with FPGA and related technologies (Verilog, VHDL, etc…), and experience the feeling of total control, having both hardware and software subdued to my control (well, not so much, due to the mysterious and semi-secret process of synthetization and fitting done by the tools involved in the process, but you get the idea).

So finally, some months ago, I bought a DE0-nano. This is a small but nicely built device, easily programmable with an integrated USB Blaster, and with a relatively low price (~70 €), which makes it perfect for learning and practicing a little.


After a few project of blinking LEDs and playing with clocks and PLLs, I’ve decided to take a step further and seek for a challenge. Then I came across the socz80 project, an amazingly cool project for building a Z80 compatible computer in FPGA-synthetizable VHDL. The code was targeted for the Papilo Pro board, which is a Xilinx based device (the FPGA world is divided between two major makers, Xilinx and Altera), so I decided to give a try and port it to the DE0-nano.

After a few hours dealing with timing problems, I managed to get it running. This is how I’ve done it.

Read More

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: https://github.com/xs-embedded-llc/cdbus
  2. Clone and build L2DBUS: https://github.com/xs-embedded-llc/l2dbus
  3. Clone and build Telegram CLI: https://github.com/vysheng/tg
  4. Clone: https://github.com/slp/tg-notify
  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 > pmtun.py << EOF
import re

file = open("powertop.csv", "r")
lines = file.readlines()
for l in lines:
    m = re.match(".*?;(.*)", l)
    if m:
        print m.group(1).replace("\"","").replace(";","")
slp@linux-18od:/tmp> # Y hacemos uso de él
slp@linux-18od:/tmp> python pmtun.py > 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: https://github.com/slp/qemu-riscos.

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: http://www.raspberrypi.org/downloads
  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 anotame.es, 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 = Date.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.