Bolas enfriadoras

Hace un tiempo comenté que, para evitar el recalentamiento de mi portátil, lo levanto sobre trabas de la ropa.

Cuando eso no basta, por ejemplo, porque fuerzo al ordenador a trabajar al 100% durante horas, lo que hago es ponerle debajo de la entrada del ventilador unas bolas enfriadoras. Las mismas bolas plásticas rellenas de gel que se guardan en el congelador y que uso para enfriar los refrescos.

Harto de correo basura que pasa el filtro

Pues eso, que me he hartado de ver que hay mensajes de correo basura que pasan el filtro de mi spamassasin. El problema no es el programa, que funciona muy bien, sino que hay mensajes que son emitidos correctamente, con reverse-DNS y todo eso, pero que sin embargo tienen un contenido que es pura carne en lata, o eso que los Monty Python dieron en llamar SPAM.

Pues nada, ni corto ni perezoso, y como ya me he hartado (y me fío del discriminado bayesiano del spamassasin) me he ido al /etc/spamassassin/local.cf y he añadido estas líneas al final:

score BAYES_80 4.0
score BAYES_95 4.5
score BAYES_99 5.0

Hala. Como mi umbral está en 5, arreglado.

No perder datos ni tiempo

En el mundo empresarial los datos son dinero, y el tiempo también. Un estudio de arquitectura, por ejemplo, que pierda sus datos (planos, informes, fotografías, etc.) irá a la ruina o, como mínimo, pasará un muy mal trago. Así que hay que asegurarse de que los datos no se pierden, para lo que tenemos soluciones como RAID 1 para los fallos de los discos.

Pero los fallos de los discos no son la única causa de que se pierdan datos. De hecho, ni siquiera son la principal. Un error del usuario al borrar un fichero, o un fallo del programa, o cualquier otra causa que vaya al sistema RAID y corrompa el sistema de ficheros puede suponer un desastre casi tan grave, y mucho más probable. Así que hay que asegurarse de que los datos están en más de un sitio a la vez. RAID 1 solamente nos permite seguir trabajando si un disco se estropea mientras llega su recambio. Para las copias de seguridad, tenemos el maravilloso rsync y su intefaz dirvish.

Y como comentaba arriba, no se puede tampoco perder tiempo, así que los datos no solamente deben estar a salvo en la copia de seguridad, sino que en caso de que falle la máquina deben poder ser utilizados inmediatamente mientras el servidor de ficheros es reparado, con lo que las copias de seguridad deben realizarse en un disco externo que pueda enchufarse, provisionalmente, a otra máquina.

Este es el sistema que he montado para una empresa semejante a la que ponía de ejemplo: Un servidor dedicado, con dos discos duros iguales (pero de distintos lotes, para evitar que puedan tener los mismos microdefectos de fabricación que puedan causar su mortalidad infantil o senil a la vez) en RAID 1, salvo el sector de arranque y la partición /boot, que son idénticos en ambos. La zona RAID particionada a su vez mediante LVM, con una parte para el sistema y otra separada para los datos de los usuarios, que se sirven mediante SAMBA. Y finalmente, un disco duro externo, identificado mediante su número de serie, con formato FAT, donde se realizan las copias de seguridad mediante dirvish, que es montada justo antes de copiar y desmontada justo al terminar.

Este disco externo pueden los usuarios desenchufarlo en cualquier momento (aunque les recomiendo que no lo hagan a las horas de las copias ;) ) para disponer de las copias de seguridad en otra máquina, aunque debido a su formato se pierda una de las mejores características de dirvish, los enlaces duros entre copias de distintas fechas, y haya (además) habido que desactivar las opciones de copia de permisos y propietarios.

Así, sea cual sea el incidente (salvo un desastre mayor de la máquina, como un incendio), los usuarios podrán acceder a sus datos de trabajo.

Para alguien que levanta España, no los vamos a dejar sin trabajar, ¿no?

StarCraft en Linux

Acabo de volver a jugar a StarCraft, ese maravilloso juego de Blizzard ambientado en el espacio. Y por supuesto, lo he hecho en Linux, aunque se trata de un juego que tengo para otro sistema operativo. Y ello gracias a una capa de emulación del API llamada Wine.

El objetivo de Wine es precisamente que los programas creados para Windows puedan ser ejecutados en Linux. Para ello, pone una capa entre el programa y el sistema de tal manera que las peticiones a Windows del programa son capturadas por Wine, que las transforma en peticiones a Linux.

Volver a tener a los Zerg bajo mis órdenes ha sido una maravillosa experiencia. Ya no se hacen juegos como los de antes, con buena jugabilidad y un guión serio.

La pena es que Wine no destaca precisamente por su manejo del sonido. Tiene la mala costumbre de requerir acceso exclusivo al sistema de sonido, ya sea OSS o ALSA. Y eso en KDE es una mala idea: o juegas sin sonido, lo que no es agradable, o no tienes sonido en el sistema. Yo, la verdad, si me pongo a jugar, quiero el sonido. Así que uso el siguiente truco:

~/.wine/dosdevices/c:/Archivos de programa/Starcraft$ artsdsp sh wine StarCraft.exe

Copiar propiedades en Subversion

Un pequeño truco que utilizo para asignar a un fichero versionado con Subversion una propiedad tal y como la tengo en otro fichero. Normalmente la utilizo para la propiedad svn:keywords que suele tener el mismo valor en todos los ficheros de cada uno de mis proyectos.

svn propset svn:keywords "`svn propget svn:keywords ficheroviejo.c`" ficheronuevo.c

Google Earth en Debian

La verdad, esperaba encontrarme el Google Earth empaquetadito y todo, es que Debian me tiene malacostumbrado, la verdad, pero bueno, tenemos un precioso paquete llamado googleearth-package que lo que hace es bajarse el instalador oficial de Google y crear un paquete a partir de él, muy al estilo Debian.

Y la verdad, googleearth-package se instaló sin problemas y make-googleearth-package hizo su trabajo: él solito se bajó el instalador, lo descomprimió, compiló y empaquetó, y me dejó un bonito paquete. O casi.

El casi viene por un par de detalles. El primero es que la versión de googleearth-package de Debian 5.0 (llamada Lenny) no está pensada para la versión actual (en mi caso, la 5.0.11733.9347) del instalador de Google Earth, así que no bastó con decir make-googleearth-package sino que en su lugar tuve que decir make-googleearth-package --force. El segundo es que make-googleearth-package no funciona bien en un directorio que tenga el bit SGID activado, y el directorio donde lo intenté las primeras veces (un subdirectorio de /usr/src) lo tiene.

Y así, prácticamente en dos patadas, tuve mi Google Earth funcionando. Eso sí, funcionando a pedales: no tenía aceleración 3D en el ordenador. Pero eso es otra historia, y deberá ser contada en otra ocasión (Ende).

Un pequeño truco

A veces hay que trabajar en línea de comandos (o mejor, línea de órdenes) con nombres de ficheros con espacios. Y es un problema pasarlos por las tuberías (pipes), porque estas interpretan los espacios como separación entre argumentos.

Pongamos un ejemplo: hoy enchufé mi disco externo a un ordenador Windows y se me llenó de ficheros llamados Thumbs.db. Es un problema borrarlos uno a uno, así que lo más cómodo es usar find de una manera como ésta:

find . -name Thumbs.db | xargs rm -rf

Pero no funciona. Un fichero que se llame mountpoint/Mi Carpeta/Thumbs.db será entendido por xargs como dos ficheros distintos, mountpoint/Mi y Carpeta/Thumbs.db, que por supuesto no existen.

La solución es tan sencilla como:

find . -name Thumbs.db | sed '{s/ /\\ /g}'| xargs rm -rf

utilizando sed para escapar los espacios. Ojo, que no funcionará sin las comillas sencillas para escapar las barras invertidas.

Trabas

Uno de los culpables del calentamiento global es, sin duda, el cada vez más elevado consumo de energía por parte de los ordenadores. Y no solo por el CO₂ que se emite al generar esa energía, sino por el propio calor que los procesadores desprenden. Basta con entrar a una sala de servidores decentemente refrigerada y acercarse a los armarios de cálculo para comprobarlo.

Pero no solo de servidores vive el hombre, ni solo a ellos les afecta el calor. De hecho, a los ordenadores portátiles les afecta más. Es bastante común poner un portátil sobre una mesa (con lo cual sus patitas lo separan de ésta ligeramente). Y también ponérselo sobre las piernas en el sofá, delante de la tele, y cosas parecidas. Pero el detalle importante de estas actitudes es que los portátiles se refrigeran por debajo, y si bloqueamos esa entrada de aire, o es insuficiente, el portátil se recalentará.

Incluso un portátil colocado sobre una mesa, levantado por sus propias patas de goma, se recalienta si está trabajando en serio. Claro que mucha gente no lo nota porque sus portátiles no hacen cálculo numérico, solamente escribir cartas y leer correos, pero... ¿de verdad quieres ver tu portátil trabajando con el estrangulador al 12%? O peor, ¿quemado?

Si, como yo, pones tu portátil realmente a prueba, no necesitas comprar esos elevadores USB con ventilador tan monos que hay en muchos sitios a la venta... sobre todo porque aparte de costar dinero, el ventilador USB consume más aún la batería del portátil (o eleva la factura de la luz). No. Basta con cuatro trabas de la ropa.