Tecnología y desvaríos

Los spammers lo tienen claro

Para el que no lo sepa, Firefox (o Iceweasel) es uno de los navegadores más populares ahora mismo, acercándose, si no me equivoco, al 30% de cuota de mercado aproximadamente, y subiendo imparablemente mes tras mes.

Sin embargo todos los que lo usamos a diario habremos comprobado como según pasa el tiempo le cuesta más «moverse» al escribir una dirección en la barra de direcciones o buscar en el historial. Esto se debe a que todos esos datos los almacena en unas pequeñas bases de datos que con el tiempo acaban fragmentándose.

Para solucionar esos problemas se puede ejecutar un comando que reorganiza esas bases de datos:

echo "vacuum;" | sqlite3 fichero.sqlite

Pero para evitar tener que hacerlo sobre todas las bases de datos de Firefox y, lo mas importante, acordarme de ello, he «cocinado» el script que adjunto, ahora solo se debe copiar a vuestro disco duro y ejecutarlo (o programar su ejecución) de vez en cuando.

Salud (Funciona en Linux y OSX)

¿Un posible logo para una hipotética «eco-debian»?

¿Quien no ha deseado alguna vez guardar la musica que escucha a través de LastFM o Spotify (o cualquier servicio similar)?

Si, se que hoy en día se puede obtener una «copia privada» en un momento pero... ¿y donde quedaría nuestro frikismo?

La cosa es que usando gst-launch se puede re-absorver el sonido que emite la tarjeta de sonido a través de PulseAudio y codificarlo y guardarlo:

$ gst-launch-0.10 pulsesrc device=$(pactl list | grep -A1 '^\*\*\* Source #' | \
  grep '^Name: .*\.monitor$' | cut -d" " -f2 | tail -n1) \
    ! queue ! audio/x-raw-int,rate=44100,channels=2 \
    ! audioconvert ! lame vbr=4 vbr-quality=2 \
    ! filesink location=dump.mp3

Dejo como deberes al lector el análisis del comando ;)

PD. Basado parcialmente en el post recording from PulseAudio de Kees Cook

Lo dicho, que Thunderbird es muy educado.

Parece ser que Google Gears empieza a coger carrerilla (he dejado un enlace para que podáis ver de que va), y esto nos va a traer poco a poco nuevas funcionalidades en las aplicaciones web. Desde soporte offline hasta mayor velocidad gracias al servicio local que provee. Y cada día son mas las aplicaciones web y no solo de Google que dan soporte a Gears.

Esta semana el blog oficial de Gmail publicaba que se iba a añadir soporte en Gmail para Gears, en esta entrada hay una explicación del significado que tiene esto.

La desgracia es que Gears no esta disponible para todas las plataformas y en concreto la mía (Linux x86_64) entra dentro de las que en principio van a tener que esperar para probar Gears. Pero solo en principio, por que gracias a las bondades del software libre he podido modificar lo justo Gears para crear una extensión para Firefox3 en Linux x86_64 y dejarla aquí para quien la necesite ;)

Salud y si alguien necesita las modificaciones que pregunte sin miedo :P (las publicaría ahora pero mañana hay que trabajar :P)

Solo como anotación:

Para generar de una sola pasada el md5 y sha1 de un fichero (útil si el fichero es grande y/o el medio lento) usar el siguiente «one-liner» en bash:

$ function multichecksum () { local F="$1"; (cat "$F" | tee >(md5sum > MD5SUM.txt) | sha1sum > SHA1SUM.txt ) && sed -e "s,-$,$F," -i MD5SUM.txt SHA1SUM.txt; }

Resultado:

$ multichecksum El\ cabo\ del\ miedo.avi  && cat MD5SUM.txt SHA1SUM.txt
92e9ced03921f0e10b17528de9e86f76  El cabo del miedo.avi
5e6beff78b528b2af7ab2ea4907e5cc311275d35  El cabo del miedo.avi

Este es el error que me apareció ayer en Thunderbird.

Y alguien se preguntará «¿Que leches significa eso?», bien, pues no tengo ni la más remota idea, pero por lo que parece es un error procedente del servidor imap de Gmail, un error propio.

No es que Thunderbird se esté convirtiendo en una «aplicación windows», otros clientes como Evolution también muestran el error, sino que, al parecer, Gmail limita la cantidad de datos/correos que se pueden mover al cabo de una hora. Una vez superado este límite aparece este error. Aún así siempre es posible seguir utilizando Gmail a través del interfaz web.

Curioso y desconcertante. Hubiera preferido un «Error indefinido» con opción de «más detalles» a esto.

Como nota.

Para capturar un frame desde un dispositivo de vídeo y guardarlo como jpg:

$ gst-launch-0.10 v4l2src num-buffers=1 ! jpegenc ! filesink location=file.jpg

Y si por lo que sea la cámara esta boca abajo:

$ gst-launch-0.10 v4l2src num-buffers=1 ! videoflip method=1 ! jpegenc ! filesink location=file.jpg

Más info GStreamer y «man gst-inspect-0.10»

A través de www.screenage.de me entero de que en las últimas versiones de ssh incorporan una opción que nos permite ver de forma mas "visual" las claves de los servidores a los que nos conectamos y que de este modo se mas fácil reconocerlas.

Me explico, normalmente cuando nos conectamos a un servidor remoto obtenemos algo así:

user@localhost:~$ ssh user@remote.org
Host key fingerprint is 60:xx:6b:e7:40:xx:d0:c6:ff:fc:xx:eb:42:96:0a:b7
user@remote.org's password: 

user@remote:~$ 

Pues bien, usando la opción VisualHostKey conseguimos esto:

user@localhost:~$ ssh -o VisualHostKey=yes user@remote.org
Host key fingerprint is 60:xx:6b:e7:40:xx:d0:c6:ff:fc:xx:eb:42:96:0a:b7
+--[ RSA 2048]----+
|                 |
|     o           |
|    o + . .      |
|     B . +       |
|  . . * S        |
|.+.. o .         |
|=. .. + .        |
|o E. o +         |
| o+..   .        |
+-----------------+

user@remote.org's password: 

user@remote:~$ _

Como se puede ver en el ejemplo lo que ocurre es que además de mostrarse la huella del servidor en formato hexadecimal, también aparecer una representación gráfica de esta huella. De modo que podemos asociar una "imagen" a un servidor en lugar de un churro de caracteres que seguramente resultará mas sencillo.

De momento yo he activado esta opción por defecto en mi ssh, la dejaremos por una temporada a ver como va ;)

--
Más info y mejor en: http://www.screenage.de/blog/2008/10/15/having-fun-with-openssh-on-ubunt...