Etiquetas

jueves, 26 de diciembre de 2013

Cross-compile para Raspberry Pi con scratchbox2 - Un borrador

En realidad, estas notas son apenas un borrador.
Llevo un tiempo haciendo cross-compile del kernel linux para raspberry pero siempre compilar algún programa en C++ propio me había resultado muy complicado.
Hoy decidí probar con scratchbox2 y este es el borrador del "work-in-progress". La verdad parece muy util y directo que otro acercamiento.

Como dije, esto es un borrador, no un tutorial. Por eso si alguien encuentra errores, o conoce scratchbox más en profundidad cualquier aporte será bienvenido. Es un borrador, porque además fui haciéndolo en días sucesivos, por lo tanto podría haber algun/os error/es.

Decidí utilizar los paquetes más estándares posibles, disponibles en los repositorios de Debian Wheezy.
El sistema "host" es un i386, mientras que el "target", lógicamente será un armv6, el tipo de arquitectura de CPU de la Raspberry Pi.
Por lo que leí, resumido brevemente, la gran ventaja de scratchbox es que es una jaula fakeroot en la que se instalará un fs root de raspbian y allí podremos ir instalando las dependencias (librerías) que el soft que vayamos a compilar requiera. Scratchbox y qemu serán los encargados de mantener la magia, es decir, compilar para la arquitectura "target" e inclusive ejecutar código compilado para arm en la CPU "host". Con algunos ejemplos creo que se puede ver mejor:

1) Instalación de los paquetes necesarios:

# aptitude install scratchbox2 fakeroot realpath qemu-user

2) Instalación del toolchain

El "toolchain" para compilación cruzada podría compilarse, pero lo más directo es usar las rpi-tools, disponibles en este repositorio git.

$ mkdir -p $HOME/raspi_build/rpitools/ && cd $HOME/raspi_build/rpitools/
$ git clone https://github.com/raspberrypi/tools.git --depth 0

Tomemos nota del directorio donde lo instalamos y a seguir

3) Extracción del rootfs de raspbian

Para crear el ambiente que scratchbox precisará para su magia, vamos a copiar de una imagen de raspbian el sistema de archivos raíz (rootfs), que normalmente está en la segunda partición de la imagen de la SD:

Para esto usé una imagen más o menos actual de raspbian: 2013-07-26-wheezy-raspbian.img


$ mkdir -p $HOME/sb2_lab/mnt
$ cd $HOME/sb2_lab
$ mkdir raspbian-rootfs
Crear el dir de trabajo donde se prefiera, claro y copiar allí la img de raspbian.

$ cd $HOME/sb2_lab
$ /sbin/fdisk -lu 2013-07-26-wheezy-raspbian.img

Disco 2013-07-26-wheezy-raspbian.img: 1939 MB, 1939865600 bytes
255 heads, 63 sectors/track, 235 cylinders, 3788800 sectores en total
Units = sectores of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificador del disco: 0x00047c7a

Disposit. Inicio Comienzo Fin Bloques Id Sistema
2013-07-26-wheezy-raspbian.img1 8192 122879 57344 c W95 FAT32 (LBA)
2013-07-26-wheezy-raspbian.img2 122880 3788799 1832960 83 Linux
Veamos, que la partición tipo linux comienza en el sector 122880, y cada sector tiene 512 bytes. Con eso vamos a montar el loop device para copiar los archivos.
Hagamos el cálculo:
$ echo "512 * 122880" | bc
62914560


Para montar el loop device, tenemos que hacerlo como root y le pasamos el offset que calculamos:

# mount -o ro,loop,offset=62914560 -t auto 2013-07-26-wheezy-raspbian.img mnt/

A copiar:

$ cd $HOME/sb2_lab/
$ rsync -avz mnt/ raspbian-rootfs

Ahora en el subdir ./raspbian-rootfs tendremos el rootfs de raspbian

$ ls raspbian-rootfs/
bin boot dev etc home lib lost+found media mnt opt proc root run sbin selinux srv sys tmp usr var


4) Iniciar el ambiente de scratchbox

Ingresamos al directorio donde copiamos el rootfs de raspbian, de otra manera sb2 no podrá iniciar bien el toolchain.
Vamos iniciar el ambiente para Scratchbox2, pasandole la ubicación de gcc en la versión del toolchain para Cross-Compile que habíamos bajado:

$ cd $HOME/sb2_lab/raspbian-rootfs
$ sb2-init raspberrypi_wheezy
/home/matias/raspi_build/rpitools/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc

Al final del proceso aparecerá:

"sb2-init completed successfully, have fun!"

Si no aparece, a desconfiar de algo y revisar.
Con eso ya tenemos el ambiente listo. Ahora, a probarlo.

5) Compilando algo para probar

Creemos el siguiente código, solo para probar. Puede ser en el directorio de trabajo o en cualquier otro:

/* Archivo: teste.c - Solo para probar sb2 */
#include <stdio.h>
int main(){
printf("Hello, #RasPi\n");
return 0;
}

Lo llamé teste.c, vamos a compilarlo dejando que scratchbox haga su magia:

$ sb2 gcc -o teste teste.c

Ahora veamos la info sobre el binario que creó:

$ file teste
teste: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x2c11b259c80ffd4ceccb9a2a0622fb12571858f7, not stripped

$ readelf -a teste | grep -i "cpu\|mach"
Machine: ARM
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_CPU_unaligned_access: v6

Como se ve, la arquitectura de destino fue, en efecto, arm v6.
Ahora, con la ayuda de qemu scratchbox permite hasta ejecutar el binario arm en el sistema "host" (i386):

$ sb2 ./teste
Hello, #RasPi

6) Probar compilar algo del mundo "real"

Por ahora, todo muy lindo. Pero el código de ejemplo es tan básico que precisa de librarías estándares y mínimas.
Probé lo siguiente, que me estaba dando mucho laburo compilar sin usar scratchbox.
El código siguiente es muy simple, es parte de unas clases que usé y modifiqué un poquito para controlar los leds de "status" de una raspberry. Los leds indican si el sistema completó el boot y monitorea el estadod e ethernet. Es algo bastante útil si se usa una RasPi sin monitor, para tener una idea de su estado si necesidad de ping, conectar por ssh, etc.

$ git clone https://github.com/retux/raspileds_status --depth 0
Cloning into 'raspileds_status'...
remote: Counting objects: 56, done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 56 (delta 11), reused 50 (delta 5)
Unpacking objects: 100% (56/56), done.

Originariamente, había compilado estos binarios directo en la raspi. Porque la verdad el tiempo de compilación es mínimo. Ahora compilarlo con ScratchBox fue muy sencillo:


$ cd raspileds_status
$ sb2 make clean
rm -f *.o
$ sb2 make
g++ -Wall -c -o GPIOClass.o GPIOClass.cpp
g++ -Wall -c -o netifledwatch.o netifledwatch.cpp
g++ -Wall -o netifledwatch GPIOClass.o netifledwatch.o
g++ -Wall -c -o gpiopinctrl.o gpiopinctrl.cpp
g++ -Wall -o gpiopinctrl GPIOClass.o gpiopinctrl.o
g++ -Wall -c -o gpioctrl.o gpioctrl.cpp
g++ -Wall -o gpioctrl GPIOClass.o gpioctrl.o

Veamos alguno de los binarios para confirmar:
$ file netifledwatch
netifledwatch: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xd7cb48d849ae94101dbd00c1ad28f67f0f56048b, not stripped

Como se ve, la magia de ScratchBox hizo posible que ni siquiera fuera necesario modificar el Makefile.

¿Qué sigue?

Queda por ver cómo se puede usar las maravillas de apt-get en el ambiente scratchbox, por ejemplo, para instalar dependencias necesarias para compilar soft más complejo. No lo probé aún, pero tiene que poder hacerse.

Agregado 27/12/2013:

Con la imagen de raspbian reciente que estoy usando para el ambiente chroot de scratchbox, es necesario comentar la línea del archivo ld.so.preload, porque de lo contrario algo de la emulación con qemu se rompía y no permitía por ejemplo ejecutar un apt-get update dentro del ambiente chroot.

$ cat raspbian-rootfs/etc/ld.so.preload
#/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so

Después de eso, se puede ejecutar apt-get update e instalar paquetes en el ambiente, sin problemas:

$ sb2 -eR apt-get update
Get:1 http://mirrordirector.raspbian.org wheezy Release.gpg [490 B]
Get:2 http://mirrordirector.raspbian.org wheezy Release [14.4 kB]
Get:3 http://raspberrypi.collabora.com wheezy Release.gpg [836 B]
Get:4 http://archive.raspberrypi.org wheezy Release.gpg [490 B]
...

$ sb2 -eR apt-get install vim
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libgpm2 vim-runtime
...

¿Lindo, no es cierto? De esta forma podrían instalarse con apt-get las libs y dependencias para compilar el soft X e intentar el cross-compile con Scratchbox.

Agregado 30/12/2013:

Correr apt-get y todas sus maravillosas luces y botoncitos dentro del ambiente chroot de scratchbox2, por eso siguen una líneas con el procedimiento usado:

Primero entramos en la emulación de Scratchbox con el siguiente comando:
$ sb2 -eR
[SB2 emulate raspberrypi_wheezy] root@debian-test-kput raspbian-rootfs #

Vemos que estamos en el ambiente chroot, lo que nos informa el prompt.

Segundo, instalamos las claves públicas de los repositorios:

[SB2 emulate raspberrypi_wheezy] root@debian-test-kput raspbian-rootfs # wget http://archive.raspbian.org/raspbian.public.key -O - | apt-key add -
--2013-12-30 15:28:47-- http://archive.raspbian.org/raspbian.public.key
Resolviendo archive.raspbian.org (archive.raspbian.org)... 5.153.225.206, 2001:41c9:1:3ce::10
Conectando con archive.raspbian.org (archive.raspbian.org)[5.153.225.206]:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 1776 (1,7K) [application/octet-stream]
Grabando a: “STDOUT”

100%[======================================================================================>] 1.776
--.-K/s en 0s

2013-12-30 15:28:47 (13,0 MB/s) - escritos a stdout [1776/1776]
OK

[SB2 emulate raspberrypi_wheezy] root@debian-test-kput raspbian-rootfs # wget http://archive.raspberrypi.org/debian/raspberrypi.gpg.key -O - | apt-key add -

2013-12-30 15:52:34 (12,2 MB/s) - escritos a stdout [1719/1719]

OK

[SB2 emulate raspberrypi_wheezy] root@debian-test-kput raspbian-rootfs # wget http://raspberrypi.collabora.com/collabora-raspbian.gpg -O - | apt-key add -
--2013-12-30 16:01:35-- http://raspberrypi.collabora.com/collabora-raspbian.gpg
Resolviendo raspberrypi.collabora.com (raspberrypi.collabora.com)... 93.93.128.223
Conectando con raspberrypi.collabora.com (raspberrypi.collabora.com)[93.93.128.223]:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 3145 (3,1K) [text/plain]
Grabando a: “STDOUT”

100%[======================================================================================>] 3.145 --.-K/s en 0s

2013-12-30 16:01:35 (22,6 MB/s) - escritos a stdout [3145/3145]

OK


Conclusión provisional

Con apt-get completo corriendo, pudiendo instalar dependencias para aquello que vayamos a compilar scratchbox2 es una belleza.
Inclusive, hace hasta innecesario y menos eficaz tener necesidad de emular un raspbian (o cualquier otra distro) en un x86, porque basta hacer:

$ sb2 -eR

Y ya estamos en el ambiente chroot, desde donde podremos ejecutar los binarios compilados para arm, cuyas instrucciones serán reinterpretadas y traducidas por qemu.
Continuar »

viernes, 20 de diciembre de 2013

Correr Raspian en una máquina virtual (qemu) y redimensionar su Sistema de Archivos (FS)

Si bien, la Raspberry Pi es de las cosas más transportables en este mundo, a veces nos la olvidamos. Contra ese olvido y otras aplicaciones puede servir correr Raspbian u otra distribución para arm1176 desde qemu.
A mí me resulta útil para probar algunas cosas sin tener que andar reescribiendo repetidamente en una SD, o para compilar algún programa que vaya a correr en la Raspberry desde un i386.
También esto puede servir para ajustar y customizar una imagen del S.O a nuestro gusto, darle el tamaño adecuado y después transferirla a memorias SDs.
Siguen algunos tips al respecto.

Como muchos sabrán QEMU es el acrónimo de "Quick Emulator", es un hypervisor que realiza emulación de hardware. Sirve para "traducir" binarios compilados de una arquitectura para correrlos en otra arquitectura de CPU o bien para correr una máquina virtual completa. Para esto último es que lo usaremos, para que nuestra VM sea una Raspberry corriendo en i386 o derivados.
Sin más introducciones, manos a la obra.
Las instrucciones para usar qemu con la variante arm de las Raspberry Pi puede encontrarse aquí:

http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/ En español y resumiendo el procedimiento puede resumirse de la siguiente forma:

1) Preparar el ambiente

Crear el directorio de trabajo.
Descargar el kernel "custom" para funcionar con qemu-arm:

wget http://xecdesign.com/downloads/linux-qemu/kernel-qemu

2) Bajar la imagen de Raspbian que vamos a usar como base

La imagen puede ser Raspbian o cualquier otra distro para RasPi. En el caso de Raspbian se puede descargar desde http://www.raspberrypi.org/downloads

Descompactar la imagen, de modo que quede, por ejemplo: 2013-09-25-wheezy-raspbian.img


3) Si no tenemos qemu instalado, instalarlo

En mi caso en el sistema "host" es un i386 con Debian, para instalar el paquete de qemu:
# aptitude install qemu-system

4) Ver que tengamos todo lo necesario

Primero verificamos que la versión de qemu fue compilada con soporte para arm1176

$ qemu-system-arm -cpu ?
Available CPUs:
arm1026
arm1136
arm1136-r2
arm1176
arm11mpcore
arm926
arm946
cortex-a15
cortex-a8
cortex-a9
cortex-m3
pxa250
pxa255
pxa260
pxa261
pxa262
pxa270
pxa270-a0
pxa270-a1
pxa270-b0
pxa270-b1
pxa270-c0
pxa270-c5
sa1100
sa1110
ti925t
any

En negrita puede verse que el paquete por defecto para Debian soporta arm1176, la arquitectura de la CPU de la Raspberry.
Si tenemos la imagen del S.O (Raspbian o el que fuere) y el kernel (archivo kernel-qemu), tenemos todo listo.


Como dice el tuturial citado, basta correr la siguiente línea en el directorio de trabajo para bootear el Raspbian:

$ qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2012-12-16-wheezy-raspbian.img
Véase: -m 256 indica cuántos Megabytes de la memoria de la máquina host (i386) le asignaremos a la MV Guest ("RasPi", digamos). Yo llegué a probar hasta con um mínimo de 64Mb (sin correr X) y todo fue bien.

PERO: en versiones más recientes de la imagen de raspbian (ejemplo, la que usé para este tutorial que es la 2013-09-25-wheezy-raspbian.zip) es necesario agregar el siguiente paso extra:

En el dir de trabajo creamos un sub-dir para punto de montaje de la imagen:
$ mkdir mnt
$ /sbin/fdisk -lu 2013-09-25-wheezy-raspbian.img
GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.


Disk /mnt/backup/RaspberryPi/qemu-vms/raspbian/2013-09-25-wheezy-raspbian.img: 2 GB, 2961100800 bytes
255 heads, 63 sectors/track, 360 cylinders, total 5783400 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/mnt/backup/RaspberryPi/qemu-vms/raspbian/2013-09-25-wheezy-raspbian.img1 8192 122879 64228 c FAT32 LBA
Warning: Partition 1 does not end on cylinder boundary.
/mnt/backup/RaspberryPi/qemu-vms/raspbian/2013-09-25-wheezy-raspbian.img2 122880 5785599 2835472 83 Linux
Warning: Partition 2 does not end on cylinder boundary.

El dato que nos interesa es el bloque de inicio de la segunda partición, que es donde está el sistema. Como el tamaño de los bloques es 512 bytes deberemos pasarle el offset a losetup haciendo el cálculo 122880 * 512:

# losetup -f --show -o `echo "122880 * 512" | bc` 2013-09-25-wheezy-raspbian.img
/dev/loop0
# mount /dev/loop0 mnt
# ls mnt
bin boot dev etc home lib lost+found media mnt opt proc root run sbin selinux srv sys tmp usr var

Primero, creamos el loop device, y después lo montamos en el dir mnt.

# vim mnt/etc/ld.so.preload

En ese archivo es necesario comentar la única línea que lo compone:

#/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so

# umount mnt
# losetup -d /dev/loop0

Esto último es importante, porque de lo contrario el raspbian en la MV no iniciará.

Fuente: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=37386&p=311360#p311360

Redimensionando la imagen, para que la SD "virtual" sea más grande

Así como establecía el tuto http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/ ya podremos correr Raspbian virtualizado. El problema es que resta redimensionar la imagen de la SD, la cual viene reducida a 1.8Gb aproximadamente. Si no la redimensionamos el sistema no nos servirá de mucho, ya que le queda muy poco espacio disponible en el File System para, por ejemplo, instalar soft nuevo.
Dicho esto, vamos a "hacer" una SD "virtual" más grande, digamos de unos 4Gb:

1) Crear uma img "contenedora"

$ dd if=/dev/zero of=4gbraspi.img bs=1M count=4000
4000+0 registros leídos
4000+0 registros escritos
4194304000 bytes (4,2 GB) copiados, 59,7716 s, 70,2 MB/s

Como siempre digo, mucho cuidado con dd. Especialmente cuando estamos obligados a correrlo como root. Por eso, es bueno tener una máquina de "laboratorio" para hacer estas cosas que no sea una máquina "de trabajo". Por eso, el resto lo hacés a tu propia cuenta y riesgo. En este texto el caracter '$' indica que el comando puede ejecutarse como usuario plano y '#' indica que debe ejecutarse como root (con muuucho cuidado).
/dev/zero es un archivo especial del sistema, que cuando se lo lee siempre devuelve el caracter \0 (NULL).

2) Copiar la imagen original a la nuestra

2.1) Preparamos los loop devices:

Vamos a utilizar las "loop device" tools que son las encargadas de la enorme magia de permitirnos leer la imagen del FS como si fueran nodos de dispositivos. En la práctica eso se entiende mejor:

# losetup -f --show 4gbraspi.img
/dev/loop0
# losetup -f --show 2013-09-25-wheezy-raspbian.img
/dev/loop1

Véase que en /dev/loop tenemos nuestra imagen SD "nueva" y en /dev/loop1 tenemos la imagen de raspbian original.

2.2) Copiamos los datos a nuestra "nueva" imagen OJO, es como root

# dd if=/dev/loop1 of=/dev/loop0
5785600+0 registros leídos
5785600+0 registros escritos
2962227200 bytes (3,0 GB) copiados, 227,464 s, 13,0 MB/s

2.3) Podemos "desmontar" la imagen original, que ya no usaremos:

# losetup -d /dev/loop1

Llegado a este punto podríamos bootear con qemu nuestra imagen, pero no tendrá nada nuevo, porque el espacio restante estará repleto de bytes NULL. Entonces vamos a redimensionar la partición ext4 de la imagen raspbian y su File System para que ocupen todo el espacio restante.

3) A redimensionar

3.1) Veamos el tamaño total de la imagen (SD "virtual"):

# fdisk -l /dev/loop0
GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.


Disk /dev/loop0: 4 GB, 4186667520 bytes
255 heads, 63 sectors/track, 509 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/loop0p1 1 8 64228 c FAT32 LBA
Warning: Partition 1 does not end on cylinder boundary.
/dev/loop0p2 8 361 2835472 83 Linux
Warning: Partition 2 does not end on cylinder boundary.

Vamos a agrandar la partición de Linux (tipo ext4) a todo el tamaño de la imagen, para eso usamos la herramienta parted:

# parted /dev/loop0
GNU Parted 2.3
Using /dev/loop0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: (file)
Disk /dev/loop0: 4194MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 4194kB 62,9MB 58,7MB primary fat16 lba
2 62,9MB 2962MB 2899MB primary ext4

(parted) rm 2
(parted) mkpart primary 62.9 4194
(parted) print
Model: (file)
Disk /dev/loop0: 4194MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 4194kB 62,9MB 58,7MB primary fat16 lba
2 62,9MB 4194MB 4131MB primary ext4
(parted) quit
En negrita se indican los comandos en la consola de parted. Primero borramos la partición 2 (que originariamente iba hasta los 2962 MB) y luego la redefinimos com mkpart, iniciándose en los 62,9 MB y hasta los 4194, que es el tamaño total del dispositivo, como lo indicaba parted también.
Con esto la partición ya está redimensionada. Solo queda redimensionar el File System, para que la ocupe por completo.


4) Redimensionar el File System ext4

Debemos buscar el punto de inicio de la partición ext4 para pasárselo al offset de losetup
# fdisk -lu /dev/loop0
GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.


Disk /dev/loop0: 4 GB, 4186667520 bytes
255 heads, 63 sectors/track, 509 cylinders, total 8177085 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/loop0p1 8192 122879 64228 c FAT32 LBA
Warning: Partition 1 does not end on cylinder boundary.
/dev/loop0p2 122880 8191999 4032315 83 Linux
Warning: Partition 2 does not end on cylinder boundary.

El número que nos importa es 122880, que es el sector donde comienza la segunda partición.
Lo multiplicamos por el tamaño de cada sector:

# echo '122880 * 512' | bc
62914560

62914560 es el offset que tenemos que pasarle a losetup:

# losetup -f --show -o 62914560 4gbraspi.img
/dev/loop1

Corremos un fsck para verificar la integridad del FS:

# e2fsck -f /dev/loop1
e2fsck 1.42.5 (29-Jul-2012)
Paso 1: Verificando nodos-i, bloques y tamaños
Paso 2: Verificando la estructura de directorios
Paso 3: Revisando la conectividad de directorios
Paso 4: Revisando las cuentas de referencia
Paso 5: Revisando el resumen de información de grupos
/dev/loop1: 72857/177056 files (0.1% non-contiguous), 427737/707840 blocks

Y, finalmente redimensionamos el F.S:

# resize2fs /dev/loop1
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/loop1 to 1008640 (4k) blocks.
The filesystem on /dev/loop1 is now 1008640 blocks long.

Desmontamos los loops devices:

# losetup -d /dev/loop1
# losetup -d /dev/loop0

Y podemos probar nuestra "nueva" imagen:

$ qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 4gbraspi.img

Una vez iniciada nuestra VM podremos ver que nuestra "SD" virtual ahora tiene el tamaño que definimos (en este ejemplo 4Gb aprox., pero eso va a gusto de cada cual, claro)

~$ df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 3.8G 1.7G 2.0G 47% /
/dev/root 3.8G 1.7G 2.0G 47% /
devtmpfs 62M 0 62M 0% /dev
tmpfs 13M 184K 13M 2% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 25M 0 25M 0% /run/shm

Si bien en este tuto usamos raspbian, el procedimiento debiera ser muy pero muy similar si se usa otra distro para Raspberry Pi.
Continuar »

viernes, 6 de diciembre de 2013

Optimizando recursos migrando a ngetty como terminales virtuales ttys

Linux es heredero de Unix, el sistema operativo creado por Dennis Ritchie y Ken Thompson en los Bell Labs de AT&T a fines de los años '60. Por eso, algunas "cosas" que Linux aún corre, vienen de larga data, son producto del desarrollo colectivo de muchas muchas personas. Getty es uno de esos procesos, que se encargan de las llamadas tty o terminales virtuales. En este post sigue un procedimiento para ahorrar significativamente memoria RAM migrando de getty a ngetty.


Getty es el proceso encargado de la gestión de las terminales virtuales (tty). Como Unix, getty tiene una historia larga: su nombre proviene de "Get Teletype", porque antiguamente las consolas que se conectaban eran teletipos. La tarea de getty es detectar una conexión y proceder al login.
En los Linux actuales las terminales virtuales se acceden con ctrl+alt+Fn donde Fn es una tecla de función F1-F6 en la configuración canónica.
El proceso getty es iniciado por init, y por lo tanto configurado en /etc/inittab.
En sistemas con mucha memoria RAM, es prácticamente despreciable el uso getty hace de recursos. Pero puede darse el casos que Linux tuviera que correr como un sistema "embebido" o que el hardware que vayamos usar no tenga GB de memoria sino algunos MBs. Un ejemplo también podría ser la Raspberry Pi. Entonces ahorrar algo de consumo de RAM podría ayudar.
Veamos el consumo inicial de memoria de los procesos gettys corriendo:


En los campos VSZ (Virtual Size) y RSS (Resident Set Size) nos podemos hacer una idea de la memoria que están usando las gettys tradicionales. Sin entrar en los detalles acá de VSZ y RSS más info se puede encontrar aquí
http://www.linuxquestions.org/questions/linux-hardware-18/why-is-vsz-more-than-rss-in-ps-aux-even-if-i%27m-not-using-any-swap-663109/

ngetty entra en juego

ngetty a diferencia de getty no inicia N procesos dependiendo de cuántas terminales virtuales estemos usando. ngetty es un demonio único, y su uso de recursos es a demanda. Según indica su autor, Nikola Vladov, "ngetty es un demonio que inicia sesiones de login en consolas de terminales virtuales bajo demanda. Es un buen reemplazo de todos aquellos procesos gettys iniciados por init que, la mayor parte del tiempo, sólo toman memoria. ngetty, cuando se compila usando dietlibc el binario ngetty solo tiene 2k y usa mucha menos memoria que getty".
Esas y otras informaciones sobre ngetty se pueden encontrar en el site oficial del proyecto: http://riemann.fmi.uni-sofia.bg/ngetty/

En Debian, para instalar ngetty es tan simple como:

aptitude install ngetty

Antes de reemplazar definitivamente ngetty se puede hacer una prueba para verificar el comportamiento, como se indica en el site de ngetty. Para eso editar /etc/inittab y agregar la si:

1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
# 4:2345:respawn:/sbin/mingetty tty4
# 5:2345:respawn:/sbin/mingetty tty5
# 6:2345:respawn:/sbin/mingetty tty6
# Run ngetty in standard run-levels

#Config de ngetty en ttys 4,5 y 6
ng:2345:respawn:/sbin/ngetty 4 5 6
Aquí se han comentado las getty originales de las tty 4, 5 y 6. Es decir las que se acceden con ctrl+alt+F4, F5 o F6.

con init q podemos hacer que el sistema haga un reload de inittab, pero si se quiere para más seguridad se puede dar un reboot o pasar a modo single-user y luego a un runlevel multiusuario.

init q

Entonces si con ctrl+alt+F4, F5 o F6 podemos acceder bien y loguearnos en esas terminales virtuales, entonces podemos pasar a deshabilitar definitivamente getty:

# 1:2345:respawn:/sbin/mingetty tty1
# 2:2345:respawn:/sbin/mingetty tty2
# 3:2345:respawn:/sbin/mingetty tty3
# 4:2345:respawn:/sbin/mingetty tty4
# 5:2345:respawn:/sbin/mingetty tty5
# 6:2345:respawn:/sbin/mingetty tty6

# Run ngetty in standard run-levels
ng:2345:respawn:/sbin/ngetty 1 2 3 4 5 6

Aquí ngetty se iniciará en los runlevels estándares 2, 3, 4 y 5 y habilitará ttys (o consolas virtuales) de 1 a 6 (ctrl+alt+F1 hasta F6).

Comparemos ahora el consumo de memoria:


Comparemos los valores de VSZ y RSS y veremos que los valores de ngetty son notablemente menores a las que acumulan todos los procesos getty canónicos.
En sistemas muy antiguos, o en hard donde Linux tenga que consumir menos recursos ngetty puede hacer alguna diferencia.

En la Raspberry Pi

En la RasPi, aunque mucho de nosotros no usemos las consolas virtuales, ngetty es una forma de reducir el uso de ram, sin deshabilitar el acceso a las ttys por completo.

# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
#1:2345:respawn:/sbin/getty --noclear 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

ng:123:respawn:/sbin/ngetty 1 2 3 4 5 6

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

# Example how to put a getty on a modem line.
#
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3


#Spawn a getty on Raspberry Pi serial line
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Nótese la línea final, en la que dejé un proceso para getty, ya que esa es la consola serial que la RasPi tiene disponible a través del puerto serie ttyAMA0, ubicado en el GPIO (no son niveles RS-232, así que cuidado. Hace falta hardware para adaptar los niveles). Si la quisiéramos deshabilitar se puede comentar, claro.
Continuar »

jueves, 19 de septiembre de 2013

Reducir ciclos de escritura en almacenamiento flash/USB

Complemento aquí algunas configuraciones que pueden ayudar a alargar la vida útil de medios de almacenamiento como las tarjetas SD o los USB stick cuando los usamos como soporte del sistema de archivos, por ejemplo en la Raspberry Pi.


En otro lugar ( http://www.equiscentrico.com.ar/2013/09/raspberry-pi-crear-initramfs-para-usar.html ) he detallado el procedimiento que seguí para usar UUID desde el inicio del bootstraping, para lo cual fue necesario recompilar el kernel de raspbian y crear una imagen initrd para que todo funcionara junto.

Aquí voy a agregar unos tips simples para reducir un poco la "pisada" del sistema sobre el sistema de archivos principal, tratando de prolongar la vida útil de medios como las tarjetas SD o los USB stick, que de por sí tienen un ciclo de vida mucho más reducido que otros medios de almacenamiento.

Por defecto el sistema de archivos que usa Raspbian para la partición raíz es ext4 (con journalling).
/etc/fstab tiene por defecto una configuración muy importante:

/dev/mmcblk0p2 / ext4 defaults,noatime 0 1

La opción de montaje "noatime" es vital en la Raspberry porque por defecto Linux utilizaría la opción "atime", que escribe timestamps en el disco cada vez que lee algo. Esa opción no plantea problemas para un disco duro, pero sería fatal para una tarjeta SD.

Bien, además de eso podría reducirse un poco más la pisada sobre el sistema de archivos de raspberry:

Yo pensaba utilizar ext2 para el sistema de archivos raíz, porque aquella versión no usaba journalling. Pero esa feature también puede deshabilitarse en un sistema de archivos tipo ext4. Para eso, tenemos que montar el sistema de archivos en otra máquina

# dumpe2fs /dev/sdf1 | grep -i journ
dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Journal inode: 8
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal length: 32768
Journal sequence: 0x000001c1
Journal start: 0

Entonces, deshabilitamos journalling

# tune2fs -O ^has_journal /dev/sdf1
tune2fs 1.42.5 (29-Jul-2012)

Y ahora se ve que no tenemos journalling habilitado:

# dumpe2fs /dev/sdf1 | grep -i features
dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem features: ext_attr resize_inode dir_index filetype extent
flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Por si acaso chequeamos la integridad del F.S:

# e2fsck /dev/sdf1
e2fsck 1.42.5 (29-Jul-2012)
rootfs: clean, 73586/262144 files, 443671/1048576 blocks

Ahora arrancamos la RasPi y podemos verificar que el journalling del F.S no
esté habilitado entre las features.


Logs en RAM:

Esta opción es muy simple pero puede contribuir a reducir la pisada.

Podemos agregar en /etc/fstab las siguientes dos entradas:

# FSs en RAM
none /var/log tmpfs size=1M,noatime 0 0
# Si quisieramos tambien /var/run
none /var/run tmpfs size=1M,noatime 0 0

De esa forma los f.s /var/log y /var/run que son los que tienen mayores actualizaciones, se guardarán en RAM con un límite de 1Mb cada uno.

Los logs serán volátiles por lo cual si la RasPi presentara algun problema y precisaramos guardar logs persistentemente tendríamos que comentar la entrada para /var/log.

Más info sobre tmpfs en *nix: http://en.wikipedia.org/wiki/Tmpfs

Continuar »

lunes, 9 de septiembre de 2013

Raspberry Pi crear initramfs para usar UUID u otras features

Estas líneas surgieron a propósito de una incomodidad: no poder usar UUID para identificar la partición del sistema de archivos raíz en mi Raspberry Pi. Eso me llevó a la sospecha de que para hacerlo funcionar sería necesario crear un sistema inicial de archivos en RAM, más conocido como initramfs. Siguen aquí los pasos para crear esa configuración, que fueron mucho más sencillo de lo que yo esperaba.


Estas notas son un borrador ya que resta probar que la configuración sea estable, pero por el momento viene funcionando sin problemas.
Aclaración: si vas a hacer esto, está claro que es por tu cuenta y riesgo. Para hacerlo, es mejor contar con una SD de pruebas, hacer backup y todo lo que consideres apropiado para la integridad de tus datos.



Estas pruebas me llevaron a reforzar más aún un argumento que se está convirtiendo en mi credo: "La pequeña Raspberry Pi se apoya en los hombros de un gigante", ese gigante es Linux, pero también Debian porque en el caso de Raspbian la Raspberry Pi es heredera de las dos décadas de trabajo de la comunidad mundial de Debian. Lo digo, porque para que crear un initramfs sea una tarea simple es porque se pudieron usar las herramientas initramfs-tools de Debian, encargadas de la magia de la trastienda de la creación del initramfs. Sin Linux la Raspberry Pi sería un pedacito de fierro del tamaño de una tarjeta de crédito, y poco más.

Incomodidad inicial

Para experimentar y entender cómo funcionaba el proceso de boot de la Raspberry Pi decidí crear una tarjeta SD (de 512 Mb que me facilitara mi amigo @DiegoRAM). Esa tarjeta SD sólo contiene la partición /boot, que guarda el firmware Raspberry Pi y el kernel Linux. Por cómo es la arquitectura de la Raspberry Pi, hay que recordar que es obligatoria usar una tarjeta SD, con sistema de archivos tipo VFAT.
La partición raíz la instalé en un USB stick de 8Gb ¿El motivo? Sólo experimentar, per-jodere o "Just for fun". Para ciertas configuraciones, en las que se requiera uso intensivo de escritura en el siste de archivos, ej un servidor web que usara un base de datos en la misma Raspberry Pi resultaría conveniente "aislar" las particiones de datos (la raíz y quizá otros F.S como /var) fuera de la tarjeta SD de inicio.
Queda claro entonces que para estas pruebas usé un usb stick (8Gb) pero podría haberse usado un disco duro, por ejemplo.

Cómo crear los sistemas de archivos y copiar los archivos no lo detallo aquí, para no extenderme demasiado. Es simplemente usar herramientas *nix estándar como fdisk, mkfs... rsync. En resumen, tenemos dos particiones creadas, la /boot en la SD 512 Mb y la raíz (/) en el USB stick, ambas con los archivos estándares contenidos en la iso de Raspbian.

La configuración por defecto de los archivos que componen el firmware RasPi y el kernel trae un arhivo llamado cmdline.txt que es el encargado de pasarle los parámetros al kernel, en momento de boot:

pi@raspberrypi ~ $ cat /boot/cmdline.txt.ori
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

boot= le indica al kernel dónde debe buscar el File System raíz (/). Por defecto, en la imagen de Raspbian ese F.S está en la segunda partición de la SD, como en este caso ésta no existe le indicamos que la busque en la partición del USB stick:

pi@raspberrypi ~ $ cat /boot/cmdline.txt.ori
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline rootwait

También debe alterarse el /etc/fstab:

proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
#/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
#/dev/sda1 / ext4 defaults,noatime 0 1
UUID=fa5e974b-7360-45c3-9f35-67a090f34bdd / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, so no using swapon|off from here on, use dphys-swapfile swap[on|off] for that

Como se ve, el montaje de la partición raíz original ( /dev/mmcblk0p2 ) está comentado y reemplazado por el FS contenido en el usb stick.


Mientras hacía esto percibí que muchas personas que utilizan un sistema de archivos externos en la Raspberry Pi en realidad utilizan la partición raíz /dev/mmcblk0p2 (en cmdline.txt) y luego montan el FS raíz en un segundo paso en /etc/fstab. Esto no tiene nada de malo, sólo que agrega un paso extra al proceso de boot. En caso de que el FS root en la SD fallara la RasPi no iniciaría.

Hasta este punto todo funcionaba bien la RasPi booteaba sin problemas, todo funcionaba como de costumbre.
Bien, he aquí cómo se originó el problema. No habría mucho problema siempre y cuando en cmdline.txt pasaramos al kernel el parámetro root=/dev/sda1 o cómo el kernel se dignase de identificar nuestro usb stick. Quien lleve un tiempo usando linux, discos scsi, s-ata o pendrives conocerá, algun problema puede ocurrir: el nombre del dispositivo puede cambiar. Ejemplo si alguna vez booteáramos la RasPi con otro pendrive conectado nada asegurará que nuestro usb stick (o hd) siga llamándose /dev/sda1.
Por eso yo quería usar UUID Universal Unique Identifier (véase http://en.wikipedia.org/wiki/Uuid ). Ese es el modo en que el kernel, en cualquier arquitectura puede identificar un dispositivo de forma más confiable.

Los UUID se pueden ver con blkid:

pi@raspberrypi ~ $ blkid
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="7709-6D92" TYPE="vfat"
/dev/sda1: LABEL="rootfs" UUID="fa5e974b-7360-45c3-9f35-67a090f34bdd" TYPE="ext4"

Aquí vemos que mi FS en el usb stick tiene la UUID=fa5e...blah...blah.

La solución debía ser simple, tan simple como agregar la UUID en el cmdline.txt, inclusive así se menciona en ciertos posts:

cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=UUID=fa5e974b-7360-45c3-9f35-67a090f34bdd rootfstype=ext4 elevator=deadline rootwait rootdelay=5

Pero... Así la cosa no funcionaba. El bootloader (configurable a través de cmdline.txt) le pasa el parámetro al kernel, pero este no puede identificar la partición por su UUID. Una vez que el kernel se cargaba, no hay problema en /etc/fstab ese problema no existe.
Luego de investigar un poco llegué a la conclusión que el bootloader no podía pasar así por así la UUID al kernel. Hacía falta un FS de inicio en RAM, más conocido como initramfs o initrd según su variante.
Para llegar a esta conclusión este thread fue fundamental http://forum.stmlabs.com/showthread.php?tid=9966.


Mundo PC / Mundo RasPi


La mayoría de las distribuciones actuales de Linux/GNU utilizan entre las diferentes etapas del proceso de inicio o boot un sistema de archivos en memoria RAM, cuyo objeto es cargar módulos del kernel indispensables para poder continuar con el proceso. De esa forma, la "pisada" del kernel en memoria se reduce porque sólo se van cargando los módulos bajo demanda.
Por defecto, el firmware Raspberry Pi no utiliza un initramfs. Para usar UUID había que crearlo.

Como el kernel stock (por lo menos el de raspbian) no trae por defecto el soporte para initramfs había que compilarlo:

UPDATE 10/10/2013: Hicimos un pedido a los mantenedores del firmware y el kernel Raspberry Pi https://github.com/raspberrypi/linux/issues/392 y muy amablemente y en poquísimos días nos agregaron el feature en el stock kernel de testing. Eso simplifica mucho este proceso porque no se requiere ya recompilar el kernel y además, con sucesivos rpi-updates no vamos a perder el soporte para initrd.
Para bajar el stock kernel de pruebas (3.10.15+) al momento de escribir estas líneas:

# export BRANCH="next" && rpi-update

Luego de clonar el git de desarrollo debe instalarnos el kernel de la rama "next" (testing) con el soporte para initrd, que luego del reboot se puede verificar con:

$ zcat /proc/config.gz | grep -i initr
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""

El que opte por usar este kernel stock, puede seguir con los pasos descritos en "Creación del initramfs"

Claro, el que por algún motivo lo desee puede seguir construyendo su kernel "custom", con los pasos descriptos abajo.

1) Compilar

En elinux.org, el site con la mejor documentación sobre Rasberry Pi se describe el paso-a-paso para compilar un kernel, inclusive haciendo cross-compilling: http://elinux.org/RPi_Kernel_Compilation
Siguiendo el paso-a-paso del roadmap de la doc que traduzco abajo, compilar en un Debian 386 fue mucho más sencillo de lo que esperaba:


1) Obtener el código fuente del kernel más reciente, con las características del Raspberry Pi (https://github.com/raspberrypi/linux) en este caso bajé el tarball: $wget https://github.com/raspberrypi/linux/archive/rpi-3.6.y.tar.gz
2) Establecer la variable del entorno KERNEL_SRC que apunte al lugar del código fuente: ( e.g. export KERNEL_SRC=/home/me/linux/ )
3) Obtener el compilador para ARM variante raspberrypi (git clone https://github.com/raspberrypi/tools)
4) Establecer variable de entorno CCPREFIX para apuntar a la localización del las herramientas de compilación ( e.g. export CCPREFIX=/home/me/tools/arm-bcm2708/arm-bcm2708-linux-gnueabi/bin/arm-bcm2708-linux-gnueabi- )
5) Desde el directorio donde se ubica el kernel, limpiar con "make mrproper"
6) Copiar la config default de un raspbian, copiando el archivo /proc/config.gz desde un Raspbian corriendo (porque el fs /proc corre en memoria).
7) En el directorio del fuente del kernel zcat config.gz > .config. Y correr "ARCH=arm CROSS_COMPILE=${CCPREFIX} make oldconfig"
8) Modificar la configuración del kernel ya sea alterando .config file o usando "ARCH=arm CROSS_COMPILE=${CCPREFIX} make menuconfig". Deberemos buscar la opción para habilitar initramfs, bajo la sección "General Setup" como se puede ver en la imagen.

9) Construir el nuevo kernel usando "ARCH=arm CROSS_COMPILE=${CCPREFIX} make" (ir por una cervecita)
10) Establecer variable de entorno MODULES_TEMP para apuntar a la localización del fuente ( e.g. export MODULES_TEMP=/home/me/modules/ )
11) Aislar los módulos del nuevo kernel usando "ARCH=arm CROSS_COMPILE=${CCPREFIX} INSTALL_MOD_PATH=${MODULES_TEMP} make modules_install"
12) Desde la ubicación de las herramientas de compilación en el directorio mkimage correr: "./imagetool-uncompressed.py ${KERNEL_SRC}/arch/arm/boot/zImage"
13) Mover el kernel resultante como kernel.img al directorio /boot/ de la raspberry Pi, previamente habiendo guardado una copia del original (mv /boot/kernel.img /boot/kernel.img.stock)
14) Empaquetar los módulos en un archivo (ej. tar) para que queden en el top-level de la jerarquía, con la estructura como sigue:
./firmware
./firmware/brcm
./firmware/edgeport
./firmware/emi26
...
./modules
./modules/3.6.11+
./modules/3.6.11+/kernel
./modules/3.6.11+/kernel/lib
./modules/3.6.11+/kernel/fs
...
15) Mover el archivo con los módulos al directorio raiz de la raspberry Pi y extraerlos, de modo que se sobre-escriban en /lib/firmware y /lib/modules. Previamente hacer backup de esos directorios.
16) Esto no fue necesario porque ya tenía el firmware en /boot (git://github.com/raspberrypi/firmware.git)

17) Transferir el contenido del directorio firmware/hardfp/opt al directorio /opt de Raspberry pi.
18) Reboot de la Raspberry Pi


Creación del initramfs


Ahora se debe crear el initramfs, que gracias a las herramientas provistas por Rasp(DE)bian resulta muy sencillo.

Si no está instalado en la Raspberry vamos a precisar el paquete initramfs-tools:

# aptitude install initramfs-tools

Habiendo booteado con el kernel "custom", verificamos el soporte para initramfs:

root@raspberrypi:~# uname -r
3.6.11


root@raspberrypi:~# zcat /proc/config.gz | grep -i initr
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
Nos muestra que este kernel fue compilado con el parámetro de soporte para initrd.

Entonces, a crear la el FS:

# update-initramfs -c -k `uname -r` -v

Aquí el único cuidado es ingresar la versión del kernel "destino" del fs init. Si ya booteamos con el kernel que vamos usar podemos usar uname -r, si no más vale ingresar la versión del kernel a mano.

Eso creará el archivo /boot/initrd.img-3.6.11

El contenido del F.S de inicio se puede ver fácilmente con:

root@raspberrypi:~# lsinitramfs /boot/initrd.img-3.6.11 | less


Ahora debe alterarse el archivo config.txt del firmware Raspberry Pi para usar initramfs, agregamos esta línea:

# Test de initramfs, generado con initramfs-tools de DEBIAN
initramfs initrd.img-3.6.11 followkernel


A pesar de que hay cierta controversia en este punto, si al parámetro initramfs debe pasarsele una direccion
de memoria donde cargar el f.s, la opción followkernel funcionó. Aclaro, usando la versión más reciente del
firmware.


Ahora boot usando UUID (que no funcionaba sin el initrd):

pi@raspberrypi ~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1
root=UUID=fa5e974b-7360-45c3-9f35-67a090f34bdd rootfstype=ext4 elevator=deadline rootwait rootdelay=5

Podemos verificar que haya arrancado:

pi@raspberrypi ~ $ dmesg | grep -i uuid
[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416
bcm2708.boardrev=0xd bcm2708.serial=0xe90f78bb smsc95xx.macaddr=B8:27:EB:0F:78:BB
sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1
root=UUID=fa5e974b-7360-45c3-9f35-67a090f34bdd rootfstype=ext4 elevator=deadline rootwait rootdelay=5


Hacerlo requiere un cierto conocimiento y tener un background con Linux, los scripts de Debian initramfs-tools hicieron la cosas mucho más sencilla de lo que habría sido crear un initrd de la nada.

Algo que habrá que tener en cuenta, a partir de este momento habrá que tener cuidado con rpi-update, porque seguro va a sobreecribir el kernel, y los archivos de config.












Continuar »

miércoles, 21 de agosto de 2013

Montar partición contenida en imagen

Las particiones contenidas en una imagen pueden extraerse con la herramienta dd, pero es más eficaz montarlas con la opción loop y offset de mount. Esto puede servir para ver o "trabajar" a partir de las imágenes de Raspbian u otras distros para Raspberry Pi.



En este ejemplo trabajamos con la imagen 2013-07-26-wheezy-raspbian.img, de raspbian.

$ /sbin/fdisk -ul 2013-07-26-wheezy-raspbian.img
GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.


Disk /mnt/backup/RaspberryPi/raspbian_img/2013-07-26-wheezy-raspbian.img: 1 GB, 1932940800 bytes
255 heads, 63 sectors/track, 235 cylinders, total 3775275 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/mnt/backup/RaspberryPi/raspbian_img/2013-07-26-wheezy-raspbian.img1 8192 122879 64228
c FAT32 LBA
Warning: Partition 1 does not end on cylinder boundary.
/mnt/backup/RaspberryPi/raspbian_img/2013-07-26-wheezy-raspbian.img2 122880 3788799 1831410
83 Linux
Warning: Partition 2 does not end on cylinder boundary.

Las opciones a fdisk: -u indica que use como unidad bloques y -l lista.

Lo que nos interesa son los sectores de inicio ("Start"), para pasarselos a mount con el parámetro offset. Vemos que el sector de inicio de la particion de boot (FAT32) es 8192. Ese número lo multiplicamos por 512 (el tamaño de cada bloque). Nos da: 4194304.

Entonces, como root montamos la particion:

Creamos los puntos de montaje:
mkdir boot raiz

Y montamos la partición de boot de raspbian, que contiene todo el firmware y la imagen del kernel:

# mount -o ro,loop,offset=4194304 -t auto 2013-07-26-wheezy-raspbian.img boot

# ls boot/
bootcode.bin cmdline.txt config.txt fixup_cd.dat fixup.dat fixup_x.dat issue.txt kernel_emergency.img
kernel.img start_cd.elf start.elf start_x.elf

Ahora la raiz de Raspbian:

# mount -o ro,loop,offset=62914560 -t auto 2013-07-26-wheezy-raspbian.img raiz/

Véase que offset=62914560 viene de multiplicar el sector de inicio de la partición 122880 * 512.

# ls raiz/
bin boot dev etc home lib lost+found media mnt opt proc root run sbin selinux srv sys tmp
usr var

Veamos los tamaños de las particiones:

# df -h boot/
S.ficheros Tamaño Usados Disp Uso% Montado en
/dev/loop0 56M 19M 38M 33% /mnt/backup/RaspberryPi/raspbian_img/bootcode

La de boot tiene 56M aprox. Y la raiz: 1,8G:

# df -h raiz
S.ficheros Tamaño Usados Disp Uso% Montado en
/dev/loop1 1,8G 1,4G 266M 85% /mnt/backup/RaspberryPi/raspbian_img/raiz

Continuar »

lunes, 12 de agosto de 2013

40 años de video juegos en el centro de Buenos Aires

El museo de la informática ICATEC, que desde hace pocos meses abrió su sede propia -antes realizaba muestras itinerantes- presenta al público durante el mes de agosto la muestra "Play The Game" un recorrido por las distintas generaciones de consolas de videojuegos y computadoras. La propuesta incluye la posibilidad de poder jugar con juegos corriendo sobre el hardware original, como la famosa Nintendo NES, que a fines de los '80 popularizó el Mario Bros.



Sobre la muestra conversamos en la columna de Tecnología en "Dinero por nada", programa de Radio América AM 1190 Khz, que dirigen Horacio Riggi y Julieta Camandone.

La cita es en Tucumá 810, Capital Federal. Horario de apertura al público:

Jueves y Viernes de 15 a 20 horas
Sábados de 14 a 19 horas
Bono contribución: $ 10

Site: http://www.museodeinformatica.org.ar/ Continuar »

domingo, 11 de agosto de 2013

Play the game: 40 años de video juegos

Play the game, es el nombre que la gente de ICATEC, la Fundación Museo de Informática, Computadoras y Accesorios Tecnológicos dio a la muestra que está abierta al público durante todo el mes de agosto.
Allí podrán verse y jugar con una pléyade de consolas organizadas en cuatro generaciones.

Pese a mis años, no había conocido la legendaria Nintendo NES original más que en fotos y por los emuladores para PC. En cambio conocí uno de sus clones más o menos "piratas", el Family Game, que hace poco cumplió 30 años. Por estos pagos, el family fue popular de veras allá por comienzos de los años '90.

Hoy, los niños pudieron jugar con muchas de las consolas que se exponen en el museo de la informática ICATEC. Curiosamente, les llamó la atención el bucólico pong que se veía en una tele blanco y negro. Para niños chicos, eso debe ser algo así como un fósil, pero aún en movimiento. Posiblemente sea también una muestra del poder de la abstracción, es decir, que quizá jugar un rato con "algo" (dos rectángulos y un cuadradito) que poco tienen de analógico con un tenis quizá tenga algo de diversión aún. Aunque sea por un rato.

O al menos, para generaciones acostumbradas al hiper-realismo de la representación de los videojuegos actuales eso debe ser sin dudas sumergirse en un pasado arcaico y abstracto.


La muestra

La muestra está organizada en cuatro generaciones de consolas. La primera, en la lejana década del '70 tenía como exponentes a consolas como la Atari Pong, como se la puede ver en la imagen de abajo

Además la muestra cuenta con muchas otras Atari, de fines de los '70
como la mítica y exitosísima 2600. De la que recuerdo que un amigo de primaria tenía una y nos pasabamos alternando fútbol y consola.
Digresión: Atari tenía un CEO ultravisionario e inteligentísimo, Nolan Bushnel que a fines de los años '70 acogió -y toleró- al jóven Steve Jobs.
Entre los fichines, el salón del museo tiene al mítico Tetris.
No faltan las computadoras "hogareñas" de los '80, que se usaban casi exclusivamente como consolas, como las Commodore 64 y 128, o las MSX.
Entre las perlas, hay muchas. Pero me sorprendió la historia de la última consola de Atari: la Jaguar, que abrió el camino a las de la siguiente generación como la Playstation de Sony. La Jaguar de Atari fue lanzada en 1993 y tenía un hardware descomunal:
Sus competidores Sega y Nintendo venían ganandole a Atari más y más cuota de mercado. Con la Jaguar Atari intentó acortar la brecha. Jaguar funcionaba a 64 bits, cuando sus competidoras seguían con 16 bits. En realidad conseguían los 64 bits usando 5 procesadores de 32 bits contenidos en dos chips que funcionando en paralelo y un coprocesador Motorola 68000, una GPU a 26,591Mhz funcionando a 26,591 MIPS, un bus de datos de 64 bits y una memoria DRAM de 2MB.

Esas y otras sorpresas quizá le depare al visitante la muestra "Play the Game". Vale la pena visitarla. La cita es durante todo el mes de agosto, en Tucumán 810, en el centro porteño. Está abierto los jueves y viernes de 15 a 20 hs y los sábados de 14 a 19 hs.

Cabe destacar que el museo es iniciativa de entusiastas y expertos en preservar el parque informático del país para futuras generaciones. Se mantienen con el aporte de empresas y las donaciones de particulares. El bono contribución es de $10.


Continuar »

sábado, 10 de agosto de 2013

Gabinete para Raspberry Pi

A estas alturas la Raspberry Pi no necesita mayores presentaciones, porque se ha vuelto bastante popular.
Para aquellos que no la conozcan aún, la Raspberry Pi es una SBC (Single Board Computer) del tamaño de una tarjeta de crédito aproximadamente. Fue lanzada en Gran Bretaña a principios de 2012. Si bien su hardware está quedando un poquito antiguo (viene con una CPU ARM11, de la arquitectura ARMv6) lo más revolucionario es su precio: 35 dólares estadounidenses.
Aquí muestro un gabinete estándar que fue adaptado para alojar la Raspberry Pi en su interior junto con un hub usb, periférico indispensable.

Por su precio y tamaño tiende a pensarse que la Raspberry Pi es la mejor opción para sistemas embebidos o un appliance que tienden a correr un número limitado de aplicaciones. No tengo nada contra eso, pero no hay que olvidar que la Raspberry Pi es una computadora de uso general, y por lo tanto sus usos pueden ser sumamente variables, pero en todos los casos aprovechando las capacidades que ofrece GNU/Linux: ser un sistema multiusuario, multitarea y, hasta donde sé, multiproceso (con algunas limitaciones) Véase: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2&t=5326
Creo, sinceramente, que una vez que uno definió las "aplicaciones" o si hará de su RasPi un appliance o una compu de uso general, uno tiene que encontrar el gabinete que mejor se adapte a la función (ahora que lo escribo esto parece super Bauhaus loco).

La idea inicial de este proyecto fue: intentar hacer un gabinete más o menos del tamaño de un thinclient, que en su interior tuviera la Raspberry Pi, con su tarjeta SD algo más protegida que en los gabinetes estándar y un hub USB. Éste último es el periférico indispensable, porque no hay que perder de vista que la corriente máxima que puede ofrecer cada puerto USB es de 500 mA (digamos algo menos), y mucho más que esa corriente no puede circular por el circuito de protección de la RasPi. El síntoma más evidente de problemas de alimentación o una fuente insuficiente suele ser cuelgues inesperados de la RasPi. Otro punto al que hay que prestarle atención es que algunos cables USB suelen ser muy malos, porque sus conductores son extremadamente delgados, lo que produce que a mayor consumo mayor sea la caída de tensión en el cable. Después de todo todo conductor se comporta como una resistencia que responde a las leyes del viejo Ohm.
El único requisito que me impuse al comenzar es que no modificaría en nada la placa original de la RasPi. Si quisiera cambirla de gabinete sólo la tendría que desatornillar y a otra cosa. Como contrapartida, esa decisión implica ocupar más espacio en el interior del gabinete.

Mi proyecto original era usar un gabinete de aluminio, pero para esta primera RasPi opté por uno plástico. La verdad es que es muy sencillo trabajar. El gabinete lo compré en http://www.gabiart.com.ar.

La verdad que diseño de la RasPi complica bastante hacer algunos moddings, ponerla en gabinetes que no sean los estándares. La razón principal: que tiene conectores de I/O en tres de sus caras, y en la restante el zócalo de la tarjeta SD. Como el objetivo era no desoldar nada de la placa, lo que hice fue hacer "extensiones" para cada uno de los conectores, a excepción del hdmi, el cual se accede directamente.
Esta foto muestra ya el trabajo en el frente y tapa posterior casi terminado. Atrás a la izquierda el jack para la entrada de +5v que alimenta la RasPi como el Hub. En el centro de la parte posterior, la abertura para el plug hdmi y a la derecha el jack RJ-45 para la ethernet. En esa imagen aún no había agregado los orificios para los jack de audio y RCA de video compuesto.
Todos los agujeros fueron hechos solamente con un par de mechas y limas para darles la forma adecuada.

Lo que sí modifiqué un poquito fue el hub USB. Utilicé uno chinísimo (con DOC: Denominación de Origen Controlada) si se me permite la humorada. En él, desoldé los jacks USB. Los nuevos jacks del frente los soldé en una plaqueta universal y le hice extensiones con cable plano, que van hasta la plaquita del USB.
Otro de los USB va en la parte de atrás, como se ve en la imagen.

Sobre la base del gabinete pegué los separadores plásticos (con la Gotita, trademark by PoxyPol) donde se atornilla la placa de la RasPi.

En esta segunda imagen se pueden ver más de los componentes, ya montados. La RasPi, el hub chinísimo, con sus extensiones. En la de abajo, ya con todo conectado y funcionando.
La forma de alimentar la RasPi merece un comentario breve. Por qué sus diseñadores le habrán puesto un jack micro-usb cuando la mayoría de las SBC viene con un jack de dos conductores? Yo creo que para que forzando a los usuarios a usar un cargador de celular se evitara aplicar una tensión incorrecta. Supongo.
Pero lo cierto es que por el micro-USB no creo que pueda circular demasiada corriente (la RasPi modelo B requiere a la fuente unos 700mA). Por eso, encontrar un conector micro-usb para conectarle fue la parte más dificil del proyecto, porque no son muy populares. Queda por averiguar si es que la placa se puede alimentar por algún PIN del GPIO, ya que eso ayudaría.




Aquí se ve el aspecto exterior, al frente y posterior.

Work in progress

Así es como está el estado actual de este proyecto, que me dió algo más de diversión los fines de semana. Quedan cosas por hacer, como intentar darle algún acabado que le otorgue algo de eye-candiness. Eso no es sencillo, pero ya se verá.
Un tema que me preocupaba un poco era la temperatura del SoC de la RasPi, la pastilla que contiene la CPU y la GPU. La estoy usando sin overclocking, y sin disipadores. De momento todo va bien. Pero tiendo a pensar que si se quiere hacer overclocking u overvolting habrá que buscar alguna solución térmica, como abertura para que el aire circule o los indeseables ventiladores.


Continuar »

domingo, 7 de julio de 2013

Douglas Engelbart, creador del mouse nos dejó

Esta semana el Dr. Douglas Engelbart falleció a los 88 años, de una insuficiencia renal.
Entre otros muchos logros, el científico creó el mouse y vislumbro con absoluta clarividencia lo que habría de ser el futuro de la computación personal para los siguiente '60 años.
Con la llegada de dispositivos táctiles acaso el mouse y el escritorio convencional parecieran tener los día contados. Pero siempre está por verse si es que un dispositivo simple y eficaz puede encontrar un sucesor que lo supere en practicidad de uso.
Sobre ese y algunos otros temas conversamos en la columna de tecnología del programa "Dinero por nada", por Radio América AM 1190 Khz, los sábados a las 16 hs.



En 1968 el Dr. Engelbart hizo una presentación que quedaría en la historia, además del mouse y de una incipiente Interfaz Gráfica de Usuario (o GUI) la presentación contó con una videoconferencia. En inglés, se la puede ver en https://www.youtube.com/watch?v=yJDv-zdhzMY

Continuar »

miércoles, 19 de junio de 2013

Google pone a prueba su proyecto Loon en Nueva Zelanda

Loon: en inglés, alocado (¿recuerdan los clásicos de la animación Looney tunes?). Los globos siempre han tenido un lugar importante en la imaginación y en la vida de niños y hombres, desde Julio Verne hasta Jorge Newbery.
Google dió ese nombre, jugando con la palabra baloon ("globo") al proyecto con el cual pretende ofrecer internet a bajísimo costo para llegar a parte de los 2/3 de la población mundial que todavía no tiene conexión a la red.
Sobre ese tema conversamos este domingo en la columna de Tecnología en "Dinero por nada", que va los domingos a las 16 hs por Radio América, AM 1190 khz.




Puede parecer alocado. Pero el proyecto requiere del conocimiento y la experimentación no sólo de ingenieros sino de físicos, meteorólogos y científicos de diversas especialidades. Requiere, como todo gran proyecto por más alocado que sea del trabajo en equipo.
Actualmente, el aspecto físico de la red que conocemos como Internet lo constituye un entramado submarino de fibras ópticas que conectan los distintos países y continentes entre sí.
En el tramo de acceso final, entre los PSI ("Proveedores de Servicio de Internet, en inglés ISP), se utilizan diversos medios físicos o inalámbricos de conexión. Puede ser fibra óptica, cobre en el caso del "cablemodem" o el ADSL o también las redes por ondas de radio tipo 3G o similar, que en su mayoría explotan las compañías de servicios de telefonía móvil.
Según Google en muchas partes del mundo esos servicios aún no tienen la universalidad que debieran tener. Recordemos que el negocio de Google es que el número de usuarios de internet crezca, porque así crece su potencial audiencia publicitaria.
Según estimaciones del gigante de la publicidad on-line, dos terceras partes de la población mundial no cuenta con acceso a internet.
La imagen que acompaña estas líneas pertenece a Google e ilustra el principio básico de funcionamiento del proyecto Loon. Se trata de poner en la estratósfera, a unos 20 Km de altura globos que transporten equipos de radiofrecuencia para ofrecer acceso a internet por vía inalámbrica. Los globos no estarían estáticos, sino que aprovecharían los vientos que circulan en la estratófera para cubrir vastas áreas del planeta. El principio es que con un grupo de globos podría cubrirse una vasta área ubicada en las márgenes de cierta latitud. Ese esquema debería repetirse para otras latitudes.
Este mes de junio en la provincia de Canterbury, Nueva Zelanda se está realizando una prueba piloto.

Más información oficial de Google en español y videos sobre el proyecto Loon pueden verse en: http://www.google.com/intl/es-419/loon/
Esta prueba piloto puede seguirse a través de la red social Google+ https://plus.google.com/+ProjectLoon/posts

Continuar »

lunes, 17 de junio de 2013

La actualidad de un juguete con mucha historia: el Meccano

En la columna de tecnología del programa "Dinero por nada", que se emite por Radio América los domingos a las 16 hs, el domingo 9 de junio hablamos sobre la actualidad de un juego con mucha historia y que es mucho más que un juguete: el Meccano y sus parientes. El audio se encuentra disponible en el enlace de abajo.




Continuar »

lunes, 3 de junio de 2013

La Estación Espacial Internacional migra sus notebooks a Debian

Debian al infinito, y más allá. Las agencias espaciales que gestionan la Estación Espacial Internacional decidieron iniciar la migración de las docenas de laptops que se usan en la estación para que usen Debian, una de los sabores (distribuciones) del sistema operativo de colaborativo y de Código Abierto, Linux/GNU.

Google retira de su tienda Google Play aplicaciones de pago de origen argentino. Esta medida genera preocupación por parte de los desarrolladores argentinos, que de momento, no podrán obtener beneficios económicos que generaban las ventas de sus productos en la tienda en línea de Google.

Escuchar el audio de la emisión del 02 de junio de 2013 de la columna Tecnología en el programa "Dinero por nada", que dirigen Horacio Riggi y Julieta Camandone por Radio América AM 1190 KHz, domingos de 16 a 17 hs.





Una medida de Google que está preocupando a los desarrolladores de aplicaciones para Android del país es la decisión por parte de Google de retirar todas las aplicaciones de pago de origen argentino. Según informó el site especializado celularis.com, los desarrolladores argentinos dados de alta en Google Play recibieron un correo electrónico con el anuncio y deberán dar de baja sus aplicaciones de pago antes de fines de junio. Podrán continuar ofreciendo, sin embargo, sus aplicaciones de forma gratuita.


Fuentes:

http://www.celularis.com/google/pagos-de-google-play-en-argentina/


http://training.linuxfoundation.org/why-our-linux-training/training-reviews/linux-foundation-training-prepares-the-international-space-station-for-linux-migration


Continuar »

domingo, 26 de mayo de 2013

Abre sus puertas el Museo de la Informática

El próximo 7 de junio abrirá sus puertas al público el Museo de la Informatica, el primero en su género en el país. Luego de funcionar algún tiempo sin sede propia, ahora el Museo cuenta con un espacio destinado a exhibir su colección. El museo cuenta con un acervo importantísimo de equipos históricos, de las décadas del '70, '80 y '90.

Escuchar el audio de la emisión del 26 de mayo de 2013 de la columna Tecnología en el programa "Dinero por nada".




Desde el próximo 7 de junio, todos los viernes por la tarde el Museo de la Informática abrirá sus puertas al público. Su sede está ubicada en la calle Tucumán 810, Planta Baja.

La Fundación Museo ICATEC (Museo de Informática, Computadoras y Accesorios TECnológicos), iniciada por sus fundadores Alicia Murchio y Carlos Chiodini tiene un foco en preservar el patrimonio tecnológico con una finalidad pedagógica para las nuevas generaciones. Según señala su sitio web (www.museodeinformatica.org.ar):

“Conservar, preservar y exponer el patrimonio informático de nuestro país para conocimiento de futuras generaciones y resguardar la memoria de los pioneros que tuvieron una participación activa en los procesos más importantes de la historia de la computación en la Argentina.
Integrar a varias generaciones a través de un interés común, como es la tecnología, posibilita un mejor diálogo y mayor participación, solidaridad e inclusión en la sociedad”.


Un viaje retro

Personalmente, tengo una enorme expectativa de conocer el museo para poder ver equipos con los que soñaba cuando tenía poco más de diez años. Eran tiempos en los que cada computadora tenía un diseño y una arquitectura que alas diferenciaba de las competidoras. El mercado estaba altamente fragmentado, había distintas CPUs mutuamente incompatibles y un lenguaje de dudosareputación (BASIC) dominaba el panorama. Tiempo después tuvimos que "desaprender" BASIC para entender mejor que aquel lenguaje podía conducir a malas prácticas a la hora de programar.
Mi primera computadora, una Radio Shack Coco II me regaló años de felicidad. Aún cuando grabara mis programas en cintas de cassette, porque nunca llegué a tener una unidad de Floppy. Años después descubrí que aquella joya de 8bits podía correr una versión de Unix multitarea y multiusuario, como me hubiera gustado verlo.

Otras, que veíamos en las fotos de revistas norteamericanas y que eran inalcanzables por su precio y acceso desde la Argentina de los años '80 como la Apple II había sido diseñada por Steve Wozniack. Sabíamos que en los Estados Unidos existía un Valle del Silicio y ese era un lugar mítico, construido por las crónicas de las revistas, por ejemplo la K-64.
Otros modelos de lo que se llamaba "Home Computers" eran las TI-99 de Texas Instruments o la Timex Sinclair, del Z-80 en adelante. De esos equipos se construyeron clónicos a lo largo de todo el mundo. Todos ellos forman parte del acervo del Museo y muchos de ellos fueron la puerta de entrada para entusiastas, aficionados y profesionales de la informática.
También hay lugar para equipos más sofisticados y que hicieron historia, como la IBM 5150, la primera "IBM PC", lanzada al mercado en agosto de 1981.
Creo que a partir de los años '90 sólo el desarrollo de sistemas abiertos como GNU/Linux o los BSDs fueron los que hicieron que otra vez le pusieramos diversión a nuestras computadoras. En eso creo que el eslógan del site Distrowatch da totalmente en el clavo ("Put fun into computing: use Linux, BSD..."). Los años que siguieron a las home computer, mientras las PCs usaban el MS-DOS eran tristes :)


Habían otras cosas en los años '80 haciendo memoria. Un programa semanal llamado "El Club de la Computadora" que iba los domingos a la tarde por canal 2 de La Plata y lo dirigía Johnny Allon. Sí señores, leyeron bien. Un pionero.
También una serie de ficción que consumíamos con avidez: "Whiz-kids" su título original pero que en la Argentina se conoción como "La Pandilla de la Computadora", pasen y vean la presentación:


Continuar »

domingo, 28 de abril de 2013

Rock & FOSS - Cómo los "Deadheads" compartían música y crearon Comunidad en los años '60

El 26 de abril se conmemoró el Día Internacional de la Propiedad Intelectual, conmemoración promovida por la OMPI, Organización Mundial de la Propiedad Intectual. Según dicha organización, dependiente de Naciones Unidas, los sistemas de patentes y copyright garantizan la innovación. Otros analistas sostienen, en cambio que tienden a "criminalizar" los hábitos que internet viabilizó.
Pero hay un caso ya de casi 50 años de edad que puede enseñarnos cómo los músicos permitieron que sus creaciones fueran libremente copiadas y compartidas siempre y cuando sus fanáticos no lucraran con ello. Y además lograron hacer buenos negocios. Es la historia de Greatful Dead y de la contracultura de San Francisco, que previeron las licencias Creative Commons o la GPL.





Creo que uno no debería temer equivocarse al afirmar (al menos así lo creo) que una de las mayores influencias sociales en el surgimiento del software libre (o de código abierto) -FOSS- proviene de la contracultura de los años '60, del "flower power" y la vida comunitaria que el hippismo ensayó por entonces.
Indudablemente varios elementos de lo que fue aquel movimiento marcaron a fuego al código abierto. De hecho, muchos de los primeros hacker, de los '60 y los '70 eran fervientes creyentes de lo "alternativo" y lo "contracultural".
Posiblemente el área de San Francisco en California, no haya sido solamente terreno fértil solo para la música y el movimiento hippie. Lo fue también, sin duda, para la tecnología informática.
Un punto en el que se entrecruzan el Rock y el FOSS es Greatful Dead, el grupo emblemático liderado por Jerry García que se formó en Palo Alto.
Fueron músicos Creative Commons "avant la lettre" ¿Por qué? Sencillo, ellos permitían a sus fans -autodenominados "deadheads"- grabar sus conciertos, en aquella época en cintas, y distribuirlas libremente.
Inclusive, los Greatfull Dead ofrecían conexiones directas a la consola de sonido, con lo cual muchas de las grabaciones de sus shows fueron obtenidas con buena calidad de audio.
Greatful Dead no tuvo demasiados temas en los top 40. Pero el secreto de su éxito no estaba en maximizar las ventas de discos. Por el contrario, su truco era crear una comunidad de seguidores, que se reconocieran a sí mismos como grupo, fueron los deadheads.
Además de sus discos, que se comercializaban por el circuito comercial tradicional los Dead ofrecían memorabilia, merchandising, objetos de arte, remeras. Sin haber llegado demasiado alto en los chart llegaron a facturar 50 millones de dólares al año. Y crearon una banda emblemática, tocaron con Dylan, volaron alto.
Musicalmente, otro de sus secretos fue llevar la zapada -jam- al extremo de que cada interpretación en vivo siempre fuera diferente.
Los deadheads no eran sólo consumidores eran parte activa del movimiento que la banda generaba.
No es casual que John Perry Barlow, fundador de la Electronic Frontier Foundation haya sido letrista de The Greatful Dead.

Continuar »