Programmed shutdown: pequeño script para apagar la máquina

Programmed shutdown: step 1

Paso 1: ¿cuánto tiempo?

Después de buscar (no, mucho, eso si) por y no encontrar algo que se adaptase a mis mínimas necesidades, me he hecho un pequeño de apagado de la máquina para mi maravilloso PC en el salón (que no de salón) equipado con un GNU/ (en concreto una Debian, pero el es multiversal dentro del mundo y quizá , depende de si el software está en otras plataformas o no).

Programmed shutdown: step 2

Paso 2: tú tranqui, que ya te aviso yo...

La idea es poder pedirle a la máquina que se apague dentro de equis minutos, con posilibidad de cancelarlo y cierto feedback visual de cuánto tiempo te queda. Posibles usos son por ejemplo imitar la función de algunas televisiones, o, cuando te vas de vacaciones y tienes algunas descargas tirando, o algún programa de TV que quieres que se grabe, pedirle que se apague en unos días para no consumir energía tontamente.

El sólo requiere que esté instalado Zenity. El código fuente del mismo lo podéis ver a continuación:

#!/bin/
# Ask for time in minutes to  and ater that  the computer
# needs - 
# Diego Toharia - deigote@deigote.com

# Messages
TITLE="Apagar el ordenador"
MINUTES_QUESTION="¿Dentro de cuántos minutos?"
WAIT_PRE="Esperando"
WAIT_POST="minutos"

minutes=` --entry --title "$TITLE" --text "$MINUTES_QUESTION" 2>&1` || exit
seconds=`expr $minutes "*" 60`

if [ $seconds != "" ] ; then
	for i in `seq 1 $seconds` ; do
		percentage=`expr $i "*" 100`
		percentage=`expr $percentage "/" $seconds`
		echo $percentage
		 1
	done |  --title="$TITLE" --text="$WAIT_PRE $minutes $WAIT_POST" --progress --auto-close --auto-kill
	
fi

También quiero pensar que, si alguna vez cambio algo, podréis encontrar una versión actualizada en el enlace Programmed shutdown script pero no garantizo que cumpla mis propósitos .

Programmed shutdown: laucher

Programmed : laucher

Para invocarlo, basta guardarlo en un directorio que esté en el path (yo suelo usar para estos scripts $HOME/bin) y darle permisos de ejecución. Recordar que debéis tener permisos para ejecutar el mandato poweoff. En mi caso, tengo en la barra inferior un lanzador precedido del mandato gksudo, de tal manera que el se lanza con los permisos necesarios, pidiéndome la contraseña en caso necesario.

Randall Munroe, you are not alone

I’m an idiot too (de un modo mucho menos pero, al menos para Rubén y para mi, igual de gracioso a la par que triste):

I'm also an idiot - Yo también soy un idiota

I'm also an - Yo también soy un idiota

En fin…

Dos mejoras que echo en falta en Google Reader

Desde hace algunas versiones Reader incorpora la posibilidad de compartir elementos con tus amigos de añadiendo una nota o comentario. Sin embargo, al menos en mi caso y el de la gente con la que suelo compartir noticias, dichos comentarios son muchas veces una contestación a otro comentario. Por lo tanto, sería de gran ayuda que al compartir un elemento con un comentario de otra persona, dicho elemento mantuviese el comentario anterior, además del tuyo (y así sucesivamente, claro).

De esta manería, se mantendría el contexto y el resto de amigos que lean tu elemento compartido podrían entender tu comentario. En los casos en que el nuevo lector y la persona a cuyo comentario contestabas fueran amigos entre si, el nuevo lector ya habría visto el comentario anterior en otro elemento compartido, y la ganancia sería fundamentalmente de recordarle el contexto sobre el que va tu comentario. En el caso en que no fueran amigos entre si, la ganancia es aun mayor, puesto que con el funcionamiento actual, el nuevo lector es incapaz de entender el comentario.

Un posible Google Reader con comentarios

Un posible Reader con comentarios

Otra ganancia de este sistema es que muchas veces veríamos quien es el compartidor original, lo que quizá nos haría añadir sus elementos compartidos como un (o, para los más desinhibidos, añadirle directamente como amigo en el Talk).

El único posible problema que le veo es el de privacidad, en el caso de que no quieras que nadie más vea tu comentario excepto tus amigos, pero creo que sería fácilmente solucionable con una opción del estilo Compartir con mis amigos y Compartir con todo el mundo, que quedase asociada a cada comentario o similar.

La otra mejora que se me ocurre también tiene relación con los elementos compartidos. Muchas veces, cuando veo un elemento especialmente interesante o gracioso que me llega a través de un al que mis amigos también están suscritos, lo comparto a pesar de que sé casi seguro que todos los destinatarios ya lo habrán visto en sus propios feeds. Supongo que este comportamiento es normal, y en mi caso lo hago inconscientemente a modo de “premio” al autor del contenido que comparto. Sin embargo, es un premio que no sirve de nada, ya que no llega más allá de mi círculo de amigos del Talk.

Estaría muy bien que hubiese una nueva sección del estilo Más compartidos, con algunos filtros básicos (sólo amigos, por regiones, etcétera), que ayudasen al usuario a encontrar lo que más ha gustado entre todos los usuarios del servicios.

Estas dos mejoras acercarían ligeramente Reader a ofrecer un servicio tipo o pero más básico (adicionalmente a los servicios que ya ofrece), pero obviando el paso intermedio de lo leo en el y me voy al servicio a mandarlo, escribir una descripción, etcétera , y evitando el karmawhorismo, dos de las razones que me han alejado de estos servicios[*].

En conclusión, Reader me parece muy interesante, lo seguiré atentamente.

[*]Eso no ha sido una crítica a //ponga_aquí_su_clon. Símplemente, este esquema que yo he descrito se adapta mejor al uso que yo hago de la red, como seguramente se adaptará peor al uso que le dan otros.

Refréscame esa caché

Wordpress, el CMS que uso para gestionar mi , dispone de varios plugins para acelerar su carga mediante cachés, algo muy necesario en general, y más si, como yo, eres usuario de un servicio de hosting barato.

En mi caso, el de caché que estoy usando es WPSuperCache, que guarda una copia estática de cada página generada por , y la sirve directamente en próximas peticiones, siempre y cuando el usuario no esté registrado. Esto evita todas las peticiones contra la base de datos por parte de . Además, opcionalmente, el permite guardar las páginas estáticas con una estructura de directorios equivalente a la que las representa, y proporciona reescrituras de URL para llegar a dichas páginas directamente, evitando toda intervención por parte de (y evitando, por lo tanto, la ejecución de código PHP en el servidor). Finalmente, además, te da la opción de guardar los archivos comprimidos con GZip. Todas estas opciones aceleran notablemente la carga de la página, puesto que el único trabajo que debe realizarse es el del : encontrar la página y servirla.

WPSuperCache, como la mayoría de plugins de caché, cuenta con un borrado automático de la caché cada cierto tiempo. Cada vez que se ejecuta esta tarea, las siguientes peticiones (si las hay) a las distintas páginas del harán que se regenere la caché automáticamente.

Sin embargo, cuando tienes pocas visitas, no es buena idea hacer que la caché sea regenerada por los . En ese caso, el mío, es probable que un lector obtenga una página no cacheada en vez de una que sí lo está. Una posiblidad es aumentar en gran medida el intervalo de borrado de la caché, pero en general es preferible tener una caché actualizada. La otra posiblidad es, además de borrar la caché, regenerarla automáticamente, de tal manera que todos los del se beneficien de la caché del mismo.

En mi caso, he escrito un que visita todos los enlaces de una página web basándose en el sitemap de la misma, siempre que este cumpla el protocolo descrito por Sitemaps.org. El código es el siguiente:

#!/bin/
# Visit all the links provided by a  file.
# Diego Toharia - http://.deigote.com

# Verify parameter
if [[ $# -ne 1 ]] ; then
    echo "Error: first parameter ( ) missing"
    echo "Usage: `basename $0` "
    exit 1
fi

=$1
links=`wget -q -O - http://.deigote.com/.xml |  '{ print $1 }' | grep "^http" |  'BEGIN { FS=">" } { print $2 }' |  'BEGIN { FS="<" } { print $1 }'`

for i in $links ; do
	echo "Visiting " $i
	wget -q -O - $i > /dev/null
done

Seguro que hay formas más elegantes de hacerlo, pero es tan potente que es difícil resistirse a usarlo. Lo he llamado visit_site_by_sitemap, original que es uno.

Una vez tenemos el , lo más fácil es programar una tarea del cron que cada cierto tiempo (preferiblemente, en franjas horarias con el menor tráfico posible) borre la caché y ejecute el pasándole como parámetro la del . Por cierto que, en mi caso, el lo genera el Google Sitemap Generator. El mandato para la regla en mi caso sería algo como:

cd path/al//wp-content ; find  -type f -name '*.' -exec rm {} \; -o -name '*.gz' -exec rm {} \; ; ~/bin/visit_site_by_sitemap http://.deigote.com/.xml

La idea es borrar todos los ficheros y gz generados por la caché y regenerar la misma visitando todos los enlaces proporcionados por el del .

Podemos hacer un par de pruebas que, sin ser demasiado científicas, nos dan una idea del beneficio que obtenemos. La primera sería ejecutar en local el dos veces, previo borrado de la caché. La primera visitaría todos los enlaces sin disponer de caché, mientras que la segunda lo haría usando la caché.

$ cd path/al//wp-content
$ find  -type f -name '*.' -exec rm {} \; -o -name '*.gz' -exec rm {} \;
$ time ~/bin/visit_site_by_sitemap http://.deigote.com/.xml
Visiting  http://.deigote.com/
...
real    4m12.102s
$ time ~/bin/visit_site_by_sitemap http://.deigote.com/.xml
Visiting  http://.deigote.com/
...
real	0m7.759s

Podemos ver que los resultados son espectaculares. De 4 minutos hemos pasado a 7 segundos. Sin embargo, estamos probando el caso óptimo, en el que la latencia es mínima y la velocidad de conexión con el es máxima, lo que hacen que la capacidad de proceso sea el único parámetro que influye en los resultados.

Si ejecutamos esta misma prueba en una máquina externa y situada en España, la misma desde la que estoy escribiendo, obtenemos unos resultados bien distintos: casi trece minutos (12m45) frente a casi 9 (8m44s).

Sin embargo, esto es culpa de la lamentable latencia y velocidad de conexión que tiene en España, ya que ejecutando la prueba en una máquina situada en USA (y de otro servicio de hosting distinto), se obtienen 3 minutos (3m02s) frente a 22 segundos, resultados más parecidos a la ejecución en local. Tendré que pensar seriamente en cambiar de hosting.

La otra prueba que se puede hacer es algo más realista: medir el tiempo de descarga de una única página, que es lo que hace un usuario cualquiera (no creo que tenga ningún lector tan fan como para visitarse todas las entradas del una detrás de otra). En mi caso, he usado un navegador Firefox con la caché deshabilitada y con la extensión Firebug instalada, usando la pestaña Red de dicha extensión para medir el tiempo de carga del de la página de inicio. He realizado varias pruebas con la caché vacía y con la caché llena y he obtenido de media unos 2.5 segundos frente a medio segundo respectivamente, lo cual no está mal. Sin embargo, el resto de elementos de la página (malditos emoticonos) ralentiza la carga total de la misma en gran medida, aunque eso es otra historia.

Gracias a Álvaro por su inestimable ayuda a la hora de lanzar el juego de pruebasen un servidor externo a españa.