Lenguajes de alto nivel para microcontroladores

Últimamente estoy bastante interesado en la búsqueda de algún lenguaje funcional que me pueda servir para programar microcontroladores. En concreto investigo acerca de lenguajes funcionales que se puedan usar para programar las dos familias más populares de microcontroladores: los PIC y los Atmel AVR.

Hay muchas opiniones en internet sobre cuál de las dos familias es mejor que la otra. Después de leer varios post sobre este tema, mi conclusión es que ambas están muy parejas y que la elección tal vez dependa de nuevo de los gustos de cada cual. Aunque si me tuviera que decantar por alguno de los dos yo tiraría por los Atmel quizás porque últimamente son más populares que los PIC (con el apoyo de la comunidad que tiene detrás) y porque tienen algunas versiones que pueden funcionar con 0.7V de alimentación (para poder alimentarlos con una celda solar barata).

Como resultado de mi investigación (no muy fructífera) he encontrado algunos proyectos interesantes. Enumero a continuación no sólo lenguajes funcionales sino toda la variedad de lenguajes de alto nivel que he encontrado para programar microcontroladores (a parte del ensamblador del propio microcontrolador que no lo considero de alto nivel, aunque en él hay que programar las partes que requieren mayor rendimiento):

• OCaPIC (OCaml)
• PicoBIT (Scheme) - PIC
• Forth: (la opción más viable, porque al menos a priori puede caber fácilmente en un micro)
• avrforth 
• amforth (8 a 12 KB de flash, 80 bytes de EEPROM, y 200 bytes de RAM). El amforth es muy prometedor.
• rforth1: Un compilador de Forth para la familia 18Fxxx de microcontroladores PIC. Este mismo autor tiene también un Forth para la familia 16Fxxx de PICs.
• .NET Micro - Aunque no investigado mucho este, parece que es sobre dispositivos más grandes.
• uJ (Java) - PIC
• NanoVM (Java) - Atmel.
• B#: la "huella" en memoria es un poco grande (<24KB de flash y <2KB de RAM). Pero es un lenguaje de programación orientado a objetos específicamente diseñado para MCUs.
• PyMite (Python): Huella de memoria grande (64KB de flash, 4KB de RAM).
• eLua. Para MCUs muy grandes, me da la impresión.
• ¿Alguna opción más? Seguro. Dejádmelo en los comentario y la pongo ;)

En uno de los enlaces que refiero abajo también sugieren programarse un intérprete personalizado de "pcode" que interprete un conjunto de instrucciones que tú definas.

Esto último parece una idea interesante así como también suena bien eso de poder crearse una especificación de máquina virtual que pudiera correr sobre dispositivos como MCUs. Hay algunas ya, pero visto que la JVM de Oracle/Sun son unas 200 microinstrucciones en la capa de VM parece factible poder generar un estándar o conjunto de instrucciones que pudiera servir para dispositivos de recursos más limitados.

¿Existe ya ese estándar? Porque estos dispositivos tienen una serie de características hardware que se podrían abstraer para luego poder programarlos más fácilmente.

Por último, hace poco terminé de leer y entender (que son dos cosas distintas) el paper de investigación que propició la creación del lenguaje Lisp y toda la belle époque de la inteligencia artificial de los años 80 y 90. Se trata de un artículo del gran John McCarthy titulado "Recursive Functions of Symbolic Expressions and Their Computation by Machine" (¡del año 1960! y todavía hoy en día relevante, que se lo apunten algunas mentes pensantes de nuestra época).

A partir de este paper se pueden extraer las operaciones fundamentales que dieron lugar a las primeras implementaciones del lenguaje Lisp. Con este germen tan prometedor: ¿se podría definir una VM basada en estas operaciones sobre MCUs?

En resumen:
Aunque parezca contradictorio, el poder programar un microcontrolador (MCU) con un lenguaje de alto nivel diferente a C (y al ensamblador, que de por sí no se puede calificar de alto nivel) aunque pueda resultar una idea peregrina a mí al menos me resulta altamente interesante. Máxime cuando la tendencia es que haya cada vez más dispositivos "embebidos" / empotrados / móviles como son los que constituyen la "Internet de las cosas" (IoT ó Intenet of Things en inglés).

¿El futuro o el pasado? Dejo al lector elegir.

Enlaces:

• Embedded Systems - Atmel AVR: Un listado de lenguajes de programación para Atmel AVR.
• Alternative languages for embedded programming [Stack Overflow]
• What are the available interactive languages that run in tiny memory? [Stack Overflow]

Reparación de pantallas LCD de cámaras digitales (y Parte 3)

El otro día terminamos de reparar la segunda cámara, marca Pentax. Fue un trabajo en equipo conjuntamente con mi padre. Al final encajaban todas las piezas y sólo nos sobró una chapa que causaba más problemas de los que solucionaba y decidimos no ponerla..

La parte más tricky fue usar partes del marco del antiguo LCD para que al colocarlo con la nueva pantalla encajase en el cuerpo de la cámara. También el hecho de conectar la pantalla mediante el bus y luego dejarla en su sitio no era algo trivial. Había que dejarla muy bien enganchada (mediante el clip del zócalo) y luego darle una serie de vueltas a la pantalla para conseguir que finalmente estuviese alineada. Lo conseguimos fijándonos en la pantalla antigua y haciendo un poco de ingeniería inversa.

No hay fotos en las que quede registro de la gesta. El único efecto colateral fue que la pantalla tiene una parte oscurecida, probablemente causada al hacer presión al intentar que se quedara en su posición mientras cerrábamos la carcasa.

Reparación de pantallas LCD de cámaras digitales (Parte 2)

Me llegó la semana pasada la pantalla LCD de una de las cámaras digitales que estaban en proceso de reparación. En concreto la de la Nikon Coolpix S200. Esta tarde he procedido a la sustitución con éxito de la misma.

En el proceso de montaje, inverso al desmontaje, lo único que me ha costado más es fijar el bus del LCD a la placa mediante el conector. Es muy pequeño y difícil de manipular, pero con un poco de cuidado se puede conectar sin problemas.

Display LCD compatible con la Nikon Coolpix S200

Como vemos en la foto de la pantalla, el extremo marcado con un círculo rojo es el extremo del bus que hay que conectar a la circuitería de la cámara. En la parte de la cámara hay un pequeño zócalo con una pestaña que se abre, de forma que podemos colocar en su posición el extremo del bus antes de volver a cerrarlo (con unas pinzas o un pequeño destornillador). De esta forma la cámara se puede volver a cerrar y todo se queda (idealmente) como estaba, funcionando como si estuviera nueva.

Tengo que señalar sobre la pantalla que te llega desde China el hecho predecible de que no sea de la misma calidad que la original. Hay al menos 2 píxeles incorrectos que sobre cualquier fondo negro destacan en la nueva pantalla. En este tipo de pantallas es normal admitir algún pixel incorrecto, pero yo albergaba la esperanza que mi nueva pantalla fuera perfecta.

Como último paso, para que no nos vuelva a ocurrir, tenemos que comprar un estuche adecuado para trasportarla. Preferiblemente un estuche rígido y que nos frene un poco los golpes que pueda recibir la pantalla.

Me falta por montar la otra pantalla LCD de la Pentax. Pero eso será en otro post ;-)

To be continued...


Enlaces:

• Reparación de pantallas LCD de cámaras digitales (Parte 1)

¿Cuánto dura una batería de 300mAh conectada a un Arduino?

Se me plantea la pregunta de calcular cuánto duraría una batería de 300mAh conectada a un Arduino Nano v3.0.

La capacidad de una batería se mide en mAh. Esta cifra nos da la duración de la batería, mediante la siguiente fórmula:

Capacidad(mAh) = I(mA) x t(h)
t(h) = Capacidad(mAh) / I(mA)

En nuestro caso particularizamos para el dispositivo Arduino Nano. Sabemos que este dispositivo tiene un regulador de tensión cuya corriente máxima es de 500mA:

Capacidad = 300mAh = 300mA x 1h
I = 500 mA => t(h) = 300mAh/500mA = (3/5)h = (3x60)/5 = 36 min

Por completar la explicación, según las especificaciones, podemos alimentar al dispositivo mediante una fuente de tensión no regulada en el rango de 7—12V. En otro de los pines nos deja alimentarlo con una fuente regulada de 5V (por ejemplo esta tensión nos la podría dar una fuente de PC). El microprocesador irá más o menos rápido (varían los MHz) dependiendo de la tensión de alimentación, pero seguirá funcionando. En nuestro caso lo que se propone es conectar una batería de 9V al pin de alimentación no regulada.

Retomando la reflexión sobre la autonomía de la batería hemos visto que si conectamos una batería de 300mAh a un Arduino nos va proporcionar corriente como mínimo 36 minutos. Dependiendo de los componentes que conectemos al Arduino (sobre todo, de los componentes conectados a los puertos, que "chupan" 40mA como máximo cada uno) esta duración es mayor o menor.

Si conectamos otros componentes la corriente que tiene que soltar la fuente aumentaría y la autonomía disminuiría. Hay motores más eficientes y que consumen menos corriente que otros (por ejemplo, los que iban montados en los walkman). Tengo que hacer medidas, pero me da la impresión que un motor con su circuito driver puede llegar a consumir del orden de amperios. Con lo que la autonomía de todo el sistema cae sensiblemente. A parte de los motores, hay otros tipos de sensores que también consumen corriente (sensores de ultrasonidos, micrófonos, cámaras, sensores de temperatura, etc).

Nota 12/1/2012: Leo en algún foro de por ahí que también hay que tener en cuenta otros factores, como son el tipo de batería (Ni-Cd, Li-Ion, etc), las curvas de descarga en voltaje, las veces que se puede cargar y descargar la batería, etc. Es decir, que el tema de las baterías es un asunto peliagudo. También dicen que los mAh son aproximados pero no exactos.

Reparación de pantallas LCD de cámaras digitales (Parte 1)

Maldición, mi cámara no funciona

Una de las causas más comunes de que una cámara digital deje de funcionar es que su pantalla LCD se estropee. Normalmente es debido a un golpe o a alguna experiencia traumática (cambio de temperatura) que sufra durante su vida útil.

En la mayoría de los casos algo así puede acabar con la cámara en la basura ya que si vamos a las tiendas de fotografía los dependientes siempre nos dicen que comprar una pantalla nueva nos va a costar igual que la cámara.

En este post os voy a contar la otra alternativa que con algo de trabajo por nuestra parte podemos adoptar: intentar arreglar la cámara nosotros mismos. Os contaré mi experiencia en dos partes que esperemos que sea exitosa y logre sus objetivos.

Las protagonistas de la gesta

Esta experiencia se inicia hace unos 5 días, cuando leo en una web de descuentos que ofrecen una cámara digital a precio reducido. Se trata de una Agfa, que hace tiempo era más famosa por sus carretes que por otra cosa.

En el fondo de un cajón de mi casa tenía dos cámaras averiadas que por dejadez más que otra cosa no había intentado todavía reparar.

Las cámaras en cuestión son:

• Nikon Coolpix S200
• Pentax Optio S6

De estas dos cámaras la Pentax yo creo que es superior, aunque a la Nikon la tengo cariño porque lleva más tiempo conmigo.

Desmontaje

Armado con mi juego de destornilladores de relojero procedo a desarmar ambas dos cámaras con el pensamiento inicial de comprobar si es viable el cambio de pantalla. Por supuesto las memorias están extraídas y las baterías también, no vaya a ser que de produzca alguna derivación y metamos la pata.

He tenido suerte. Al menos en mis dos modelos es posible el reemplazo, ya que están conectados a la electrónica de la cámara con un bus que no está soldado. La Pentax además tiene conectado otro cable pequeño que sospecho es la alimentación de la pantalla. La Nikon tiene todo en el mismo bus.

Los tornillos hay que guardarlos a buen recaudo. Son minúsculos y si te despistas se te perderán y no volverás a poder cerrar la cámara tan bien como antes. Normalmente están estandarizados y no hay que quedarse con cuál va en dónde. Aunque no es mala idea apuntarlo en algún sitio.

Compra de repuestos

Con los dos únicos datos de las marcas y modelos de las cámaras busco en eBay un posible proveedor de repuestos. Mis búsqueda consiste en las palabras "nikon coolpix s200 lcd display". De forma análoga busco los repuestos de la Pentax.

Veo que un par de vendedores en China me proporcionan recambios. No soy muy optimista de que sean partes originales aunque según ellos sí. Nunca te fíes de un chino cuando te dice que algo es original. Sin embargo creo que pueden servirme para recuperar las cámaras. Además cuesta el repuesto de la Nikon $13.99 sin gastos de envío (unos 10,83€) y el de la Pentax $12.99 más $5 de gastos de envío (en total 13,93€). No se aproxima al precio de las cámaras, que es muy superior.

Con mi cuenta de PayPal (que recomiendan siempre usar cuando compras algo por eBay) realizo las compras. Dicen que tardarán unos 15-20 días (dependiento del proveedor, si lo paran en la aduana, etc) en llegar.

De momento estoy a la espera de que me lleguen los repuestos para seguir. Cuando lo hagan escribiré la "Parte 2" ;-)

To be continued...


Enlaces:

• Reparación de pantallas LCD de cámaras digitales (Parte 2)

Neuromante, de William Gibson

Hace mucho que quería dejar aquí algún comentario sobre esta novela. Desde que la leí la primera vez en cierto sentido es una de mis novelas de referencia. Dicen los estudiosos de estos temas que es una de las primeras novelas del estilo ciberpunk.

De hecho mi primer contacto con ella fue en el tren, de camino a casa después de haber pasado el día en la universidad. Era mi época de estudiante, cuando todavía tenía mucho tiempo para leer (y más ganas de leer que de estudiar). Tampoco me había acomodado tanto como hoy e iba casi todos los días en tren a la universidad. Por aquel entonces, todo hay que decirlo, esta situación tampoco me agradaba mucho.

Había un chico enfrente mío con un ejemplar de la novela, en la edición española de la editorial Minotauro. La portada era curiosa: un dibujo más o menos abstracto que nunca he llegado muy bien a saber qué simboliza. Sobre fondo oscuro se ve una especie de esfera brillante y por detrás unos cilindros también de colores oscuros la rodean. He visto portadas de esta novela mejores, en la que se puede ver a Molly (un personaje de la novela) posando desafiante.

También recuerdo que pocos días después entré en el FNAC de Callao y me la compré. La primera lectura que hice de la novela fue tan rápida como poco fructífera. No me había enterado de nada.

Sólo después de dos o tres lecturas comprendí el sentido de lo que tenía entre manos. Una obra inspiradora, con un lenguaje propio y eléctrico. Yo que siempre estoy pensando en frases que se pueden citar cuando leo algo, esta novela sin duda es un filón. Casi toda se podría citar, frases enteras rellenarían mi pared si tuviera el espacio suficiente.

En cuanto al tema, sin destriparlo mucho, trata sobre un vaquero (hacker) del ciberespacio que ha caído en desgracia y que de buenas a primeras se ve embarcado en una operación que no sabe muy bien en qué acabará. El universo es parecido al de esa película que también nos gusta tanto: Blade Runner.

Así que si te gusta Blade Runner yo creo que puedes darle una oportunidad a Neuromante. Eso sí, la lectura en inglés se hace un poco ardua, tanto por el léxico como por el ritmo propio de la novela.

Reflexiones sobre el tamaño óptimo de los backups incrementales o diferenciales

Definimos el factor:

Factor (F) = (Suma Incrementales o Diferenciales) / Full del ciclo

El factor está acotado de la siguiente manera:

0 ≤ F ≤ (N-1)

Donde N es la duración del ciclo. Por ejemplo si se hacen backups full semanales y cada día un incremental, N=7 porque es por semana. Si se hiciera un backup full mensual y el resto de los días del mes incrementales, N=30.

Valores de F mayores que (N-1) no tienen mucho sentido ya que querría decir que
la los incrementales, de media, pesan más que el full del ciclo.

Ej. 1: full semanal, resto de los días incrementales

         |-- L --|-- M --|-- X --|-- J --|-- V --|-- S --|-- D --|
Semana 1 |       |       |       |       |       |       | FullS |
Semana 2 | Inc1  | Inc2  | Inc3  | Inc4  | Inc5  | Inc6  |       |

=> Factor = (Inc1 + Inc2 + Inc3 + Inc4 + Inc5 + Inc6) / FullS

Ej. 2: full semanal, resto de los días diferenciales

         |-- L --|-- M --|-- X --|-- J --|-- V --|-- S --|-- D --|
Semana 1 |       |       |       |       |       |       | FullS |
Semana 2 | Dif1  | Dif2  | Dif3  | Dif4  | Dif5  | Dif6  |       |

=> Factor = (Dif1 + Dif2 + Dif3 + Dif4 + Dif5 + Dif6) / FullS

Ej. 3: full mensual, resto de los días incrementales

Semana 1 | FullM | Inc1  | Inc2  | Inc3  | Inc4  | Inc5  | Inc6  |
Semana 2 | Inc7  | Inc8  | Inc9  | Inc10 | Inc11 | Inc12 | Inc13 |
Semana 3 | Inc14 | Inc15 | Inc16 | Inc17 | Inc18 | Inc19 | Inc20 |
Semana 4 | Inc21 | Inc22 | Inc23 | Inc24 | Inc25 | Inc26 | Inc27 |
Semana 5 | Inc28 | Inc29 |

=> Factor = (Inc1 + Inc2 + Inc3 + ... + Inc29) / FullM


Tipos de clientes:

Nos encontramos con dos tipos de clientes problemáticos:

• Clientes cuyo F < 0.1: Suma de incrementales o diferenciales es menor que el 10% del tamaño del full.

→ CLIENTES INACTIVOS

• Clientes cuyo F > 0.9: Suma de incrementalos o diferenciales mayor que el 90% del tamaño del full.

→ CLIENTES HIPERACTIVOS

Valor óptimo del factor:

Es difícil dar una cifra óptima ya que la elección de este factor influiría por ejemplo en los tiempos de recuperación, que pueden ser diferentes dependiendo de la política que se quiera seguir en el cliente o de los requerimientos en los tiempos de recuperación.

Además también hay clientes más propensos a tener un F grande. Por ejemplo, cuando son clientes de base de datos es normal generar un volcado diario con los datos. Con lo cual el incremental suele ser grande.

Medidas a adoptar:

Dependiendo del tipo de cliente, ir adoptando las medidas en orden y estudiar cómo evoluciona F a lo largo de las sucesivas semanas.

◊ En los clientes INACTIVOS:

1) Full cada más tiempo

◊ En los clientes HIPERACTIVOS:

1) Estudiar los ficheros que ocupan más tamaño en los incrementales y activar directivas a nivel local en los SaveSets / directorios conflictivos

NOTA: Estas directivas se pueden aplicar a nivel global (se han definido varias políticas en función del sistema operativo) o por el administrador del servidor en cuestión (mediante el fichero .nsr).

1.1) Si son ficheros temporales o prescindibles, excluirlos del backup

• skip : Excluye un directorio o fichero. Espera una máscara. 

1.2) Con los ficheros que no cambian de tamaño a lo largo de la semana, pero sin embargo se van a cinta:

• mtime : Graba sólo un fichero cuando el tiempo de modificación del fichero cambia, es decir, cuando cambia el fichero. A veces te llevas ficheros que sólo se han accedido pero no han cambiado, lo que no es muy adecuado.

2) Si son ficheros de log que no se rotan:

• En Unix se pueden rotar con el logrotate.
• En Windows: habría que buscar una solución similar.

3) Si son volcados a disco (normalmente copias completas de bases de datos):

• Estudiar si es necesario hacer el volcado realmente todos los días y llevárselo al backup o se pueden usar otras técnicas de volcado (por ejemplo, volcados incrementales aunque aumentaría el tiempo de recuperación)
• Si no es posible, documentar en algún sitio que ese cliente tiene los incrementales/diferenciales muy altos y no se puede bajar. Reflejar también el razonamiento.

En la práctica:

• Normalmente (aunque depende de la herramienta de backup que se use) la suma de los incrementales te los hace directamente, mientras que cuando es un cliente con diferenciales (tipo NAS) los tienes que sumar tú (por cada cliente) para calcular el factor (ya que los clasifica como diferencial nivel 1, 2, 3, etc.

• Cuando la estadística es en un período de tiempo largo, se puede hacer la suma en el período de todos los incrementales o diferenciales y luego dividir por la suma de todos los fules en el período. De esta forma sale una muestra mayor y los valores son más significativos.

• Si un cliente tiene varios SaveSets puede que uno de ellos tenga algún problema y los otros estén bien. Realmente cuentan los SaveSets de mayor tamaño dentro de un cliente (los que ocupan GB, es decir en tamaño los del orden de 1E+9). Dado que la política de backup se fija a nivel de cliente, si un SaveSet grande tiene problemas ese cliente tendría que ser entonces candidato para que se le optimice.

• Los diferenciales en realidad son más grandes que los incrementales, ya que se reflejan los cambios desde el último backup full. Para clientes tipo NAS (como por ejemplo EMC Celerra, NetAPP, etc) no conviene tocar mucho la configuración ya que si no se penaliza de cara a los tiempos de recuperación.

¿Puedes romper este código? O como optar a ser espía de UK

eb 04 af c2 bf a3 81 ec   00 01 00 00 31 c9 88 0c
0c fe c1 75 f9 31 c0 ba   ef be ad de 02 04 0c 00
d0 c1 ca 08 8a 1c 0c 8a   3c 04 88 1c 04 88 3c 0c
fe c1 75 e8 e9 5c 00 00   00 89 e3 81 c3 04 00 00
00 5c 58 4d 41 41 41 41   75 43 58 3d 42 42 42 42
75 3b 5a 89 d1 89 e6 89   df 29 cf f3 a4 89 de 89
d1 89 df 29 cf 31 c0 31   db 31 d2 fe c0 02 1c 06
8a 14 06 8a 34 1e 88 34   06 88 14 1e 00 f2 30 f6
8a 1c 16 8a 17 30 da 88   17 47 49 75 de 31 db 89
d8 fe c0 cd 80 90 90 e8   9d ff ff ff 41 41 41 41


Can you crack it? es una forma que se han inventado los británicos de captar a potenciales espías que ayuden en la caza por parte de las fuerzas de la ley de ciber-delincuentes. Si descubres el mensaje en claro asociado al cifrado transcrito arriba, éste te llevará a una página web en la que podrás mandar tu CV y que te "recluten" ;-)

Si ser un especialista en el tema, veo que hay algunos pares hexadecimales que se repiten más que otros (00, 41, 42, 88, 89, 8a, 90, por ejemplo). También creo que se podría asumir que dentro del código descifrado puede haber una URL a la página web donde mandar el CV. Por lo que el patrón http://.../.../ sería uno de los que deberíamos buscar.

Si descubro algo más en los 7 días que quedan para que termine el reto... seguramente les mande mi CV. Aunque va a estar la cosa difícil.

Un gestor de descargas programado en bash

El gestor de descargas favorito de todo sysadmin debería de ser un script programado en bash. Perl también sería otra opción, pero soy menos hábil en ese lenguaje. Lo único que necesita el script son los comandos básicos (echo, awk), uno para comprimir (gzip) y el que vamos a usar para descargar (wget).

El script es el siguiente:

Pastie | Mystic Paste

-----------------[ descarga.sh ]-----------------

#!/bin/bash

WGET_OPTS="-c"

graba_msg_error() {
  ERRORNO=$1
  case $ERRORNO in
    0) MSG_ERR="No problems occurred." ;;
    1) MSG_ERR="Generic error code." ;;
    2) MSG_ERR="Parse error --- for instance, \
when parsing command-line options, the .wgetrc \
or .netrc..." ;;
    3) MSG_ERR="File I/O error." ;;
    4) MSG_ERR="Network failure." ;;
    5) MSG_ERR="SSL verification failure." ;;
    6) MSG_ERR="Username/password authentication \
failure.";;
    7) MSG_ERR="Protocol errors." ;;
    8) MSG_ERR="Server issued an error response." ;;
    *) MSG_ERR="Unknown." ;;
  esac

  echo "(**) RESULTADO DEL COMANDO: $ERRORNO -- \
$MSG_ERR" >>$NOMBRE.log

}

while read LINEA;

do

  NOMBRE=$( echo $LINEA | awk '{print $1}' )
  URL=$( echo $LINEA | awk '{print $2}' )
  echo -n "Descargando $NOMBRE desde $URL..."
  wget $WGET_OPTS -o $NOMBRE.log -O $NOMBRE "$URL"
  N_ERROR=$?
  graba_msg_error $N_ERROR
  gzip -v9 $NOMBRE.log >>$NOMBRE.log 2>&1

  if [ $N_ERROR == "0" ]; then
    echo "OK"
  else
    echo "ERROR!"
    echo "=> N_ERROR = $N_ERROR, ver el log para \
mas informacion."
  fi

done <$1

-----------------[ descarga.sh ]-----------------

El modo de empleo es:

./descarga.sh <fichero_urls.txt>

El parámetro <fichero_urls.txt> es un fichero con líneas, donde en cada línea pones el nombre del fichero y la URL que quieres descargar. Por cada descarga se genera un fichero .log con la salida del comando wget (además de grabarse el fichero de la descarga si esta ha sido correcta). El flag "-c" que se pasa a wget sirve para continuar las descargas que estuvieran a medias. Como característica adicional, se ha programado una función (graba_msg_error) para el control de errores de wget.

WikiRebels

He visto el documental WikiRebels, de la cadena de televisión sueca SVT. Me quedo con estas frases que pronuncian a modo de conclusión:

“ A difference can be made bottom-up. ”

“ Information does not respect borders. ”

“ Democracy without transparency is not democracy. It's an empty word. ”

Enlace al documental

El ideario político de los 'ciberactivistas' Anónimos