A través del monitor

¡Sí! He usado toda esta tarde la beta 4 del mencionado, no porque me diera curiosidad, sino porque su actual versión estable (2.0.0.12) me tiene harta: reducir el consumo de memoria implica una navegación más que deficiente, a menos, imagino, que tenga el tiempo suficiente para jugar con about:config hasta lograr cierto equilibrio. Y no lo tengo. Ni ganas.

Y eso que no voy a hablar de las nuevas características (que por lo demás ya han sido más que revisadas en todo blog de corte geek que hay). ¡Firefox 3 final ya!

Debería ser una opción opcional. Es molesto esperar a que aparezca el enlace para descargar un archivo adjunto porque el antivirus trata de protegerme de un sistema operativo que no uso.

$ su
# aptitude install googleearth-package
# make-googleearth-package
# dpkg -i googleearth_4.1.7076.4458+0.2.0-1_i386.deb

Ahora me toca averiguar por qué al ocultar la barra lateral anda funciona tan lento.

Una de las ventajas de usar aptitude en lugar de apt para administrar paquetes, es que trata de mejor forma las dependencias, ya que no sólo instala paquetes necesarios, además elimina los que ya no lo son, permitiendo así mantener limpio el sistema sin complicaciones. Sin embargo, y de manera paradójica, por defecto está configurado para instalar paquetes recomendados. Por ejemplo, al querer instalar Gwenview con dicha opción activada se obtiene:

# aptitude install gwenview
Reading package lists… Done
Building dependency tree
Reading state information… Done
Reading extended state information
Initializing package states… Done
Reading task descriptions… Done
Building tag database… Done
The following NEW packages will be automatically installed:
cdparanoia cdrdao dcraw dvd+rw-tools exiv2 genisoimage imagemagick k3b
kaddressbook kdepim-kio-plugins kipi-plugins kmail kooka libao2
libbluetooth2 libcdio6 libdvdread3 libexiv2-0 libflac++6 libgnokii3
libgpgme11 libieee1284-3 libiso9660-4 libk3b3 libkcal2b libkdepim1a
libkexif1 libkipi0 libkleopatra1 libkmime2 libkpimidentities1 libkscan1
libksieve0 libktnef1 libmagick++9c2a libmimelib1c2a libpth20 libsane
libvcdinfo0 ocrad sane-utils vcdimager wodim

Mientras que al desactivarla:

# aptitude install gwenview
Reading package lists… Done
Building dependency tree
Reading state information… Done
Reading extended state information
Initializing package states… Done
Reading task descriptions… Done
Building tag database… Done
The following NEW packages will be automatically installed:
libexiv2-0 libkipi0

Los paquetes recomendados no son necesarios, pero podrían mejorar el desempeño del que intentamos instalar, ya que de alguna manera se relacionan con este. Personalmente, no me gusta que aptitude instale paquetes que podría, quizás, a lo mejor, tal vez, llegar a utilizar, por lo que desactivé la opción. Para ello:

$ su
# aptitude

Y en la GUI que aparecerá vamos a Options, Dependency handling y desmarcamos Install Recommended packages automatically.

Hago eco de la útil herramienta explicada por Mark para mantener el sistema limpio de locale inecesarios.

Un locale es un conjunto de reglas culturales que definen el país, idioma, caracteres y otras preferencias de la interfaz del usuario. En Linux las interfaces de todas las aplicaciones dependen de que locale estén instaladas en el sistema.

Al parecer, algunas aplicaciones instalan sus propios locale aunque no los vayamos a utilizar, ocupando espacio en el disco duro. localepurge es un paquete para Debian y distribuciones basadas en ella que permite mantener sólo los locale necesarios.

Inmediatamente después de instalarlo aparece una pantalla en el terminal (yo utilicé aptitude, imagino que las herramientas gráficas también la ejecutan) donde se deben seleccionar los idiomas que utilizaremos. En mi caso fueron:

• en
• en_GB.ISO-8859-15
• en_GB.UTF-8
• es
• es_CL
• es_CL.UTF-8

Dónde los esenciales son en y es ya que contienen la información general respecto al idioma. Mark me explicó que conservar el inglés se debe a que hay aplicaciones que no han sido traducidas al español, no sé si es necesario, pero frente a la duda… Elegí inglés británico de caprichosa.

Lista la instalación lo ejecutamos con permisos de administrador: sudo localepurge, y en pocos segundos entregará los resultados. En mi caso:

localepurge: Disk space freed in /usr/share/locale: 32784K
localepurge: Disk space freed in /usr/share/man: 2268K
Total disk space freed by localepurge: 35052K

Y desde ahora, cada vez que se instala una aplicación mediante apt-get localepurge se ejecutará automáticamente. Yo instalé KOffice con aptitude y no sucedió, aunque no sé si se debe a que aptitude y localepurge no son compatibles o a que no había locale que eliminar.

Como si saltarnos un paso al realizar búsquedas fuera poco, ahora podemos saltarnos dos. La extensión ConQuery para Mozilla Firefox permite realizarlas sin necesidad de recurrir al teclado. Basta con seleccionar lo que queremos buscar y escoger el motor adecuado desde el menú contextual que aparece al hacer clic con el botón derecho del mouse; o desde el menú contextual propio de la extensión que puede aparecer al mantener presionado durante algunos segundos configurables el bóton central (a.k.a. la ruedita), o mediante la combinación Bloq Mayús / Ctrl+botón derecho del mouse.

Las letras de canciones fueron hasta hace un tiempo el tipo de búsqueda que de forma más recurrente hacía. Entonces tenía que utilizar el buscador de turno y, una vez encontrada, copiarla al disco duro debido al abrumador exceso de publicidad. En otras ocasiones me frustraba debido a lo rebuscado de la canción y la consecuente carencia de resultados, pero con el paso del tiempo el escenario a mejorado: existe la posibilidad de colaborar con servicios como Lyrc (sobre el cual ya escribí) o lyricsfly.com (también), que por el momento se niega a incluir publicidad. Sin embargo, la moderación de envíos y correcciones, además de la pésima organización de ambos, que termina con letras duplicadas y mal catalogadas, me hicieron buscar alternativas.

Una de las que conozco es Lyriki (buen nombre), un wiki creado con MediaWiki, el CMS de la Wikimedia Fundation, que permite bastante flexibilidad al momento de colaborar, ya sea agregando, editando u organizando el directorio. Pero mi favorita, y con la que me quedo, es LyrikWiki, de la cual me enteré vía Menéame. Aprovecha mejor las características de MediaWiki, las URLs son más intuitivas y cuenta con plugins para Firefox y amaroK entre otros.

En la última entrada me referí a myComments, un muy útil plugin para Wordpress, Textpattern y Blogger (por el momento) que genera un canal RSS de nuestros comentarios y las respuestas que reciben. Bien, a través de Quemar las Naves me enteré de la existencia de coComment, un servicio web con la misma función que se vale de otro método: en lugar de que el autor de cada blog instale el plugin para el CMS que utiliza, son los propios visitantes quienes envían el ping al servidor mediante un bookmarklet que se agrega al navegador utilizado, siendo el hacer clic en él el paso posterior a dejar un comentario.

En una primera instancia parece que solventa la falencia de myComments: la necesidad de que los bloggers instalemos el plugin, sin embargo, como blogum explica en los comentarios de la nota en ñblog, coComment tampoco es compatible con todos los CMS que hay. Cierto es que está en beta (motivo por el cual el registro requiere de una invitación solicitable en esta página), pero veo más difícil su extensión en el tiempo de lo que es para myComments gracias a la apertura de su API. Por otro lado parece ser que el seguimiento de las respuestas a nuestros comentarios es más complicada dado que sólo lista aquellas dejadas por usuarios registrados en coComment. Todo lo anterior más la obligación de hacer clic en el bookmarklet luego de comentar lo hacen a la larga más engorroso que myComments, al menos por el momento. Es evidente que prefiero el plugin de Diego.

Pero con todo, tiene su ventaja: usando Javascript permite mostrar en cualquier web una lista de los comentarios que vamos dejando desparramados por la red, un nuevo bloque informativo que estará a la derecha (hasta que cambie el diseño) de A través del monitor caundo regrese a Santiago.

Acabo de toparme, vía Menéame, con uno de los plugins para WordPress más útiles que puede haber: myComments. Su función es enviar una copia de los comentarios que se dejan en el blog a un servidor que se encarga de generar un archivo RSS 2.0 para cada usuario, de forma que podemos seguir las respuestas a los comentarios que dejamos en cuanto blog pulula por la red mediante el agregador de canales que utilicemos (Feedness en mi caso). La identificación de los comentarios se basa en la dirección de correo electrónico que damos al momento de comentar, igual que los gravatars.

Como myComments está disponible sólo para WordPress el archivo RSS 2.0 se genera con los comentarios dejados en blogs creador con dicho CMS y que tengan el plugin instalado, pero se espera en un futuro poder disponer de versiones para otros gestores de contenido, como el popular Movable Type. En A través del monitor ya está instalado, así que sólo les falta generar sus archivo RSS 2.0, y esperar a que todos los autores de blogs creados con WordPress instalen el plugin.

Gracias a Diego por su creación.

Desde que Ricardo Galli anunció su existencia, Menéame se ha ganado un lugar entre aquellas herramientas web que me son imprescindibles, al punto de que he pensado en cancelar mi suscripción a viarios blogs populares. Después de todo, si la información es relevante, alguien la habrá de menear.

Sobre el facilitar dicha tarea, proporcionando el enlace correspondiente directamente en cada blog, trata esta entrada. De esta forma nos ahorramos el paso de visitar Menéame para enviar noticias.

HTML puro.

La forma más fácil es mediante un enlace a la dirección http://meneame.net/submit.php?url=http://url-de-la-entrada. Si fuésemos a menear esta misma entrada, quedaría http://meneame.net/submit.php?url=http://atravesdelmonitor.lamatriz.org/meneame. Ahora, la idea es que el enlace aparezca de forma automática en cada entrada. Para ello hay que utilizar el código correspondiente que usa cada CMS para imprimir la URL de cada entrada.

En el caso de Blogger, por ejemplo, el código utilizado es <$BlogItemPermalinkURL$>, por lo que el código a insertar en cualquier parte entre las etiquetas <Blogger> y </Blogger> sería: <a href="http://meneame.net/submit.php?url=<$BlogItemPermalinkURL$>">Meneame</a>. Obviando el hecho de que el texto entre <a> y </a> puede variar.

Javascript.

Ricardo informó hace un tiempo de la existencia de un script en dicho lenguaje que basta enlazar en la página individual de cada entrada. Para ello hay que agregar la siguiente línea de código: <script type="text/javascript" src="http://meneame.net/api/check_url.js.php"></script>.

La ventaja que ofrece por sobre el método anterior es que si el apunte aún no es enviado a Menéame invita a hacerlo; en caso contrario invita a votar, mostrando más información a través del atributo title del enlace.

En caso de que el agente de usuario no soporte Javascript, o el propio usuario lo haya desactivado, se pueden mezclar ambos métodos de la siguiente manera (utilizando nuevamente a Blogger como ejemplo):

<script type="text/javascript" src="http://meneame.net/api/check_url.js.php"></script>
<noscript><a href=”http://meneame.net/submit.php?url=<$BlogItemPermalinkURL$>”>Menéame</a></noscript>

Plugin para WordPress.

Finalmente, Manuel Almeida programó Menéame Plugin. Está en beta y es el método que estoy utilizando. La ventaja que ofrece es que permite incluir el enlace en la página principal del blog, permitiendo así enviar las noticias directamente, sin tener que visitar la página individual de cada entrada.