martes, 20 de octubre de 2009

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?

viernes, 11 de septiembre de 2009

Volviendo al hogar

Gracias a iarenaza, que confió en mí y en su propio buen criterio, ya estoy de vuelta en el lugar en que todo empezó, el sitio en que empecé a «bloguear» (yo prefiero decir «escribir») mis historias informáticas: la casa de la rubia.

Libertonia es, quizá, la mejor página sobre informática de España: los artículos no pasan a portada hasta que han sido revisados por los usuarios, y si las cosas son como eran, eso no ocurre si son tendenciosos, están mal escritos o cualquier otro defecto similar.

Realmente pensé que Libertonia estaba muerta, pero parece que no: no está muerta, simplemente yace eternamente.

martes, 1 de septiembre de 2009

RESHAPE es ineficiente

Fortran es un lenguaje pensado para escribir en el ordenador fórmulas matemáticas, o más en general, cálculos científicos. Y es muy bueno trabajando con matrices multidimensionales: se puede escribir


real(4) :: a(64,64,64)
real(4) :: b(10,10,10)

[...]

b=a(1:10,1:10,1:10)


y así, sin necesidad de bucles, copiamos un trozo de una matriz en la otra. O también podemos, para rellenar de datos una matriz:


real(4) :: a(1:64,1:64,1:64)
integer :: i,j,k

a=RESHAPE( (/ ( (/ ( (/ ( REAL((i-1+(64/2))/64)+1.0 ,k=1,64) /) ,j=1,64) /) ,i=1,64) /) , (/64,64,64/) )


para rellenar un cubo de datos de 64*64*64 con los valores 1 y 2. Esto es lo mismo que


real(4) :: a(1:64,1:64,1:64)
integer :: i,j,k

do k=1,64
do j=1,64
do i=1,64
a(i,j,k)=REAL((i-1+(64/2))/64)+1.0
end do
end do
end do


aunque la filosofía no es la misma. En el primer caso, creamos una ristra de 64*64*64 valores que después adaptamos a un cubo de lado 64. En el segundo caso calculamos los valores uno por uno y los vamos colocando en sus lugares de memoria. El segundo código parece más ineficiente, y puede que el compilador no lo sepa optimizar bien... pero el primero es el realmente ineficiente: compilarlo puede tardar muchísimo más, incluso hacerse eterno con valores mayores, mientras que el segundo se compila en un instante y se ejecuta en poco tiempo.

Recordemos, pues, que salvo en determinadas ocasiones, explícito es mejor que implícito, por mucho que les duela a los fortranistas de toda la vida.

lunes, 17 de agosto de 2009

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

lunes, 27 de julio de 2009

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

miércoles, 27 de mayo de 2009

Soporte 3D para una tarjeta nVidia

Comentaba ayer mis aventuras con Google Earth, cuyo resultado fue necesitar la aceleración 3D de mi tarjeta gráfica, una nVidia Quadro NVS 110M.

Desde que reinstalé la máquina, hace poco, con Lenny, había estado trabajando con el controlador libre nv, que fue automáticamente puesto en su sitio por la autoconfiguración de Xorg. Y la verdad, sin problemas.

Ahora bien, poner a funcionar la aceleración 3D tampoco ha sido demasiado complicado. En primer lugar, tuve que compilar el módulo del núcleo, cosa que module-assistant hizo por mí:

m-a a-i nvidia
En segundo lugar, añadir una línea a mi fichero /etc/X11/xorg.conf: cambiar
Section "Device"
Identifier "Configured Video Device"
EndSection
por
Section "Device"
Identifier "Configured Video Device"
Driver "nvidia"
EndSection
Y en tercer lugar, simplemente reiniciar la máquina. Nada del otro mundo, ¿verdad?

Lo que sí he notado es que, aparte de que la aceleración 3D ahora funciona, ha cambiado el tamaño de mis fuentes en la pantalla, con lo que, aparte de que he tenido que reordenar todos los iconos del escritorio, algunas aplicaciones que dependen del tamaño de la fuente dan mínimos problemas. Por ejemplo, gnumeric, que establece el alto de las líneas en función de la fuente.

Pero bueno, detalles menores que, en realidad, no molestan.