Figuraciones

Nada más fácil: se crea una cuenta en Flickr o Twitpic y enviando un mensaje de correo con foto anexa, se publica directamente en estos y quién sabe cuántos más servicios.

Pero, ¿qué pasa si quieres tener todas tus fotos en tu propio servidor y para ello utilizas la versión 1 de Gallery y sigues apegado a ese programa? Ahí la cosa se complica porque no hay -todavía- ninguna manera de publicar una foto mediante un mensaje de correo. Lo que sí hay es un script de Perl llamado galleryadd.pl que permite publicar una foto desde el disco local de la máquina a tu galería fotográfica.

Después de mucha vuelta, llegas a la conclusión de que lo que necesitas es un script que al recibir el mensaje con la foto, la guarde en el disco y le diga a galleryadd.pl que la coloque en su album.

En primer lugar parece lógico configurar galleryadd.pl para que publique en un album predeterminado con un usuario predeterminado y hacer un script de una línea (llamémoslo fotoAGaleria que simplifica el envío de las opciones, la contraseña es fija y el album es fijo. El pie de foto será el 'asunto' del mensaje de correo ("$2", muy importantes las comillas).

#!/bin/sh
/ruta/al/script/galleryadd.pl -p XXX -a NOMBREDEALBUM  -C "$2" $1

A continuación lo más sencillo resulta ser utilizar los filtros de kmail de la forma siguiente. Entre las opciones de filtrado está la de 'ejecutar orden'; con esa opción el primer adjunto (la imagen) se guarda en el disco así: cat %1 > fototemporal.jpg

Inmediatamente después (otra opción 'ejecutar orden' del filtrado) se ordena la publicación invocando el script realizado anteriormente:
/ruta/al/script/fotoAGaleria /ruta/a/fototemporal.jpg %{Subject} ; allí se puede ver que el primer argumento es el archivo con la foto y el segundo, el asunto (subject) que servirá como pie de foto.

En mi caso creé una cuenta de correo sólo para esto y cada vez que reciba una foto será publicada automáticamente. KMail revisará periódicamente la cuenta y borrará el mensaje después de publicar la fotografía... nada más fácil.

Actualización: Con adición del módulo Mailhandler a Drupal, y un poquito de configuración, el envío se puede hacer a los dos lugares; a las galerías gráficas y como post de Drupal...

Ahora que he hecho el proceso completo al menos una vez, creo estar en condiciones de echar el cuento de cómo producir un audiolibro en GNU/Debian(testing)/Linux. Se supone que disponemos de un libro -o cualquier otro texto- en formato PDF, al final se obtiene un cierto número de archivos mp3 u ogg que pueden escucharse en la computadora o en un tocador portátil de esos formatos.

Los programas requeridos -aparte de las herramientas normales del terminal- son: festival (incluye text2wave y voz en español), pdftotext o ps2text, y lame para producir MP3.

Primero, hay que convertir el archivo PDF a texto y el problema puede estar en la codificación del texto. En esta máquina la codificación predeterminada es iso-8859-1 o Latin1. También puede pasar que la conversión no se pueda realizar porque el conversor no "conoce" la codificación. En ese caso, hay que agregar la línea textEncoding Latin1 en el archivo de configuración de xpdf, en debian está en: /etc/xpdf/xpdfrc. Así que hay dos opciones:

• pdftotext -enc Latin1 archivo.PDF
• pstotext -output archivo.txt archivo.pdf

Después de probar ambas, me quedo con la última. ps2text hace un mejor trabajo de conversión del texto a Latin1 (de hecho es lo que hace de forma predeterminada), elimina caracteres ocultos y deja el texto más limpio (por ejemplo, convierte los guiones largos en ---). Este proceso tarda unos pocos segundos.

Pero el conversor de texto a voz comete actualmente algunos errores intolerables, como no entender los signos ¿ (pronuncia "equis" y deletrea la palabra que sigue). Así que hay que pulir el texto, esto es, corregir la ortografía (los acentos y demás detalles son importantes para la pronuciación correcta) y eliminar los caracteres no pronunciables o que causan esos errores en el robot-lector, en el caso que nos ocupa ¿ ¡ - y similares. Para ello se puede hacer un pequeño libreto (script) con sed, como líneas como esta: sed -i -e 's/¿/ /g' archivo.txt. Una vez pulido el texto, ya se puede enviar al lector, pero el resultado sería un solo archivo excesivamente largo si se trata de un libro (unas 300 páginas pueden llevar a 200 megabytes de archivo de sonido y eso en un formato comprimido). Así que es preferible 'picar' o dividir el texto original en trozos para que sea más sencillo detener al lector y llegar a un punto dado.

Para dividir el archivo ya corregido en pedazos de (por ejemplo) 300 líneas: split -l 300 -d archivo.txt prefijo. El 'prefijo' es el nombre que tendrán los archivos divididos seguidos de un número secuencial, por lo tanto esa orden crea una serie de archivos con nombre prefijo01, prefijo02, etc. Si text2wave se confunde con los nombres de los archivos, se les puede agregar la extensión .txt de forma automática así: rename 's/$/\.txt/' prefijo*

Hasta aquí, no se ha producido ningún sonido, aparte del típico repiqueteo del teclado. Ahora hay que ordenarle a text2wave que vaya leyendo cada uno de los archivos text2wave prefijo04.txt -o archivodesonido04.wav. Pero, puede pasar -así fue en este caso- que el lector predeterminado no sea el que queremos. Para hacer que la voz elegida por text2wave para leer sea la que realmente se desea hay que modificar -o crear, si no existe- un archivo llamado .festivalrc y colocar esta línea: (set! voice_default 'voice_el_diphone): la voz "el_diphone" que corresponde a un lector español será la que haga el trabajo; de otro modo muy bien puede suceder que el lector sea un gringo y la lectura será consecuentemente errada.

Además, es preferible hacer de una vez la conversión a un formato portátil, sea MP3 u Ogg, de una de estas formas:

• text2wave prefijo01.txt | lame - prefijo01.mp3
• text2wave prefijo01.txt | oggenc - -o prefijo01.ogg

Ya que pueden resultar muchos archivos (entre 10 y 100, dependiendo de la longitud que hayamos decidido poner como norma) es mejor hacer un libreto o script, algo como:


cuenta=1
for i in `ls prefijo*`
do
text2wave $i | lame - prefijo${cuenta}.mp3
cuenta=`expr $cuenta + 1`
done


Lo que queda es esperar un rato; según mi cuenta, aproximadamente una décima parte del tiempo de lectura real. Es decir, si la lectura del libro completo dura unas 30 horas, el proceso de conversión de texto a voz tardará unas tres; de hecho algo menos, dependerá de la velocidad de la máquina y demás detalles.

De las cosas menos aprovechadas en el ámbito de las tecnologías actuales (no "nuevas") la que más resalta es la del sonido. La situación se puede comparar con la radio: muchas emisoras, cero producción. Tantas y tantas horas de emisión radial y prácticamente ningún aprendizaje útil. 50 % musiquita, 50 % o más de propaganda (y no hay que olvidar que el porcentaje de musiquita también es propaganda). Alguna noticia. Más nada. Por otro lado, es casi increíble la facilidad que tiene un oyente para atender a lo que escucha y a otra cosa que puede estar haciendo simultáneamente. De allí lo de la gran oportunidad desaprovechada.

Quienes padecemos sin remedio la "autopista" regional del centro nos vemos obligados a soportar cualquier cantidad de musiquita y propagandas; la única excepción consiste en una emisora 'vial informativa' que da información sobre lo que es evidente: hay cola aquí, habrá allá, los peajes están congestionados, no hay vías alternas, etcétera. Sin embargo, hay ocasiones en que un dato de esta emisora permite evitar algo de la inevitable cola que más tarde o más lejos encontrarás.

Es en ese contexto que los tocadores de formatos comprimidos de audio (típicamente MP3) vienen a cumplir una función que podríamos llamar educativa. Es algo que también se puede hacer con lectores de CD, pero es más práctico con estos "bichitos".

He escuchado algunas conferencias e incluso algún libro grabado por lectores humanos, y por supuesto es mucho más grato que escuchar propagandas estridentes. Pero con ocasión de la búsqueda de algún libro para entretener esas horas perdidas me encontré con algo que no por conocido deja de sorprender. Conseguí un libro completo leído mediante una voz autómata que me ha impresionado por su claridad. El libro es 'La revelación de los templarios' y no merece mayor atención; sin embargo, la lectura de esta robot, porque es una voz femenina, impacta porque lee mejor que mucha gente que uno conoce. Los errores que comete se deben a algún acento mal colocado o a la presencia en el texto de nombres extranjeros (como los autores del libro) que pronuncia tal como se leen en la grafía española. El único otro inconveniente es la velocidad, que aunque correcta para la lectura, se hace pesada al rato debido a la constancia implacable de la lectora.

Viendo la cantidad de libros en formato electrónico que tengo en cola para leer 'algún dia' es evidente que si logro convertirlos en audio digital los podré escuchar con más probabilidad que leerlos en la pantalla del computador. Recordé que dispongo de un programa lector de este tipo denominado festival. Tras una pequeña búsqueda veo que el escritorio que utilizo (KDE) tiene una interfaz gráfica que facilita su uso. Lo que faltaría es recoger el sonido de la lectura en un archivo, cosa que hace con facilidad Audacity, tras lo cual se puede comprimir el resultado en formato MP3 o Vorbis. Lo demás sería automatizar el proceso para convertir todos esos libros en audio. Entre otras ventajas está la de no requerir personal, comprometido por horas para leer con tono uniforme textos que posiblemente no le interesan.

La versión de 'festival' de que dispongo tiene una sola voz en español, masculina y castiza. Se equivoca bastante con los guiones y otros signos atravesados en el texto, pero en general es entendible y esos detalles se pueden corregir si uno es el que está produciendo el material. Supongo que para convencer a los más escépticos debo aportar una prueba, y aquí está (4,5 minutos, mp3, 777 KB).

Estuve retrasando un buen tiempo el asunto de crear los respaldos de toda la información (bases de datos, documentos y por supuesto ¡el blog!) porque requería hacer un estudio en profundidad de cómo conectarme a otra máquina sin que solicitase contraseña, para poder programar un respaldo madrugador y sin intervención humana. Eso iba a ser aproximadamente nunca, si no fuese porque conseguí un sitio donde explican brevemente cómo hacerlo.

Con fines "filantrópicos" (más bien mnemotécnicos), relataré aún más brevemente el asunto y en cristiano, por si puede servirle a alguien.

Lo primero es que en ambas máquinas, la que origina la conexión (digamos UNO) y la que la recibe (digamos DOS) deben disponer de una instalación funcional de SSH (Secure SHell, en debian se trata de OpenSSH). El usuario que origina la conexión debe tener un directorio .ssh, al igual que el usuario de destino. A continuación, los tres pasos para que se dé la conexión sin explicitar contraseña:

1. En la máquina UNO, se genera un par de claves, en el directorio .ssh con esta orden: ssh-keygen -t dsa -f id_dsa -P ''; esto genera dos archivos id_dsa y id_dsa.pub que corresponden a cada clave.
2. Se copia la clave pública en la máquina DOS, en el directorio .ssh del usuario destino: scp id_dsa.pub usuariodestino@maquinaDOS:.ssh/
3. En la máquina DOS se agrega la clave pública recién copiada a la lista de claves autorizadas: cat id_dsa.pub >> authorized_keys2

El paso siguiente es probar que funciona. Para realizar un respaldo automático se debe tener en primer lugar un libreto (script) con la o las órdenes correspondientes, incluyendo los nombres de la máquina y el usuario de destino. Algo como esto: rsync -avzt /home/usuario1 usuario2@maquinaDOS:/respaldos/. Una vez guardado y hecho ejecutable, es sólo cuestión de añadir una línea en el archivo de p.e. /etc/cron.d/tareasdiarias, que debe lucir algo así: 10 4 * * * usuario1 /usr/local/bin/respaldoEnMaquinaDOS para que ejecute el libreto todos los días a las cuatro y 10 a.m.

Aunque creo que hay más de 2000 sitios donde se aclara este asunto, no sé por qué parece que nunca queda claro. He estado convirtiendo una máquina Pentium II con Debian-Woody (núcleo o kernel 2.2) para servir como enrutador y cortafuegos entre una red interna de otras 15 máquinas similares e Internet. El problema es que el núcleo 2.2 no incorporaba los módulos necesarios para hacer la función NAT (network address translation). Así que en lugar de recompilar el núcleo, lo que hice fue actualizar toda la instalación a Debian-Sarge con núcleo 2.6, que ya viene con todo lo necesario.

Parecería que no hay problema, pero resulta que al actualizar el sistema las dos tarjetas de red desaparecieron... Resultó que el controlador de esas tarjetas no venía incorporado en el nuevo núcleo (con el núcleo 2.2, las tarjetas funcionaban perfectamente). Así que fue necesario buscar el modelo de las tarjetas con lspci e incorporar su controlador mediante modconf. Una vez hecho esto, todo funcionó normalmente. La red interna utiliza esta máquina como puerta de enlace para la navegación por Internet. La configuración de las dos tarjetas se hace en el archivo /etc/network/interfaces que se puede ver acá.

# /etc/network/interfaces -- configuration file

# La segunda tarjeta de red
auto eth1
iface eth1 inet static
address 192.168.1.111
netmask 255.255.255.0


En este caso, la primera tarjeta se conecta con un servidor DHCP, y la segunda tiene un número fijo. Todo lo que hay que hacer es incluir la configuración de la segunda tarjeta en el archivo mencionado y configurar el resto de las máquinas para que utilicen a ésta (número fijo: 192.168.1.111) como su puerta de enlace a la infoesfera.