No es la primera vez que publicamos un fragmento de la película Allegro non troppo, de Bruno Bozzetto. Si su interpreatción del vals triste de Sibelius me pareció perfecta para la música, esta versión del Bolero de Ravel me ha sorprendido, porque yo misma me había planteado trabajar en una animación parecida: con peces sucesivamente más grandes devorando a otros más pequeños, pero, en esencia, la música me había sugerido la misma idea. De alguna forma, el Bolero, con su ritmo constante (la percusión no varía en toda la pieza), su tema sensual y tranquilo, su dinámica siempre creciente, nos remite a un fenómeno imparable, maquinal, que se repite una y otra vez en un bucle creciente y se expande conquistando nuevos territorios. Como una infección incontrolada, o como la aparición y proliferación de la vida en la Tierra, que viene a ser algo parecido.

En cualquier caso, la excusa es perfecta para hablar de Maurice Ravel y su archiconocido Bolero. Fue compuesto hacia 1928 a instancias de Ida Rubinstein. Esta  célebre bailarina francesa, pretendía hacerle la competencia a los Ballets Rusos de Diaghilev con su propia compañía. Por ello encargó a Ravel que idease un «ballet con carácter español» que ella misma representaría. Por aquel entonces, Ravel era un compositor muy reconocido, y estaba a punto de emprender su gira por Norteamérica, uno de los puntos cumbre de su carrera, seguido por el estreno del Bolero y su Concierto para piano.

La idea del Bolero, sin embargo, llegó más bien de rebote. En un principio Ravel pensó en trabajar en un arreglo para orquesta de de la Suite Iberia de Albéniz. Sin embargo, en el último momento y con el trabajo ya empezado, se enteró de que los derechos para esa obra habían sido cedidos en exclusiva a Enrique Fernández Arbós, un antiguo discípulo de Albéniz (SGAE, dando por culo desde 1899). Nunca sabremos cómo habría sonado el arreglo de Ravel (una verdadera lástima, ya que, como se demuestra en la pieza de hoy, era un gran orquestador) y Arbós nunca llegó a terminar su trabajo. Sin embargo, y pese a la decepción inicial, Ravel salió adelante con una nueva y atrevida idea, dando lugar a la que hoy es, sin duda, su obra más conocida e interpretada.

El punto de partida era sencillo: Ravel quería componer una pieza a partir de un solo tema musical (0’50”-1’34”) y un contratema no demasiado contrastante (2’30”-3’15”), repetidos incesantemente durante más de 15 minutos y sin la menor variación. Se trataría, por tanto, de una partitura sin evolución ni desarrollo, donde el único elemento estructural, lo único que gradúa la tensión y da una dirección a la música, es su orquestación, siempre creciente. En este sentido, hablamos de una partitura experimental, algo parecido a los Ejercicios de estilo de R. Queneau (siempre lo mismo pero nunca igual). De hecho, el mismo Ravel consideraba su Bolero como un mero ejercicio de orquestación y su éxito llegó a sorprenderle. En cualquier caso, el resultado es una pieza muy original, puede que algo aburrida para algunos (sobre todo para el percusionista), pero ante todo, una música sensual, obsesiva y tremendamente pegadiza, quizás de ahí su gran popularidad.

El propósito principal de la declaración DATA es dar nombres a constantes; en vez de referirse a pi como 3.141592653589793 en todos los lugares que aparezca en el programa, se le puede dar dicho valor a una variable llamada PI con una declaración del tipo DATA, y usar esta variable en lugar del inconvenientemente largo valor de pi. Esto también simplifica el modificar posteriormente el programa, en caso de que el valor de pi cambiase.

(Visto en Cambalache 3,14 y a su vez en Historias Salvajes)

Es tan fácil como hacer una especie de “acuario” de metacrilato del tamaño de la placa base, meter las tripas del PC dentro y llenarlo de aceite mineral. Existe un vídeo del proceso. Importante: sacar los puertos USB fuera.

En resumidas cuentas, la bomba fork no es un agujero en la seguridad de los sistemas operativos porque no produce ningún daño (salvo la molestia), porque lo tiene que ejecutar el propio usuario del sistema (luego es un suicidio en toda regla) y porque es más bien una característica de los lenguajes de programación y el resultado de un programador patoso. Vamos, que es lo mismo que tirar del cable de alimentación queriendo. Aún así, no deja de ser una bonita curiosidad.

Vamos a ver unos ejemplos. Empecemos con Linux. Existe una bomba fork para este sistema que tiene el honor de ser considerada «la bomba más bonita jamás creada», tanto por su simplicidad como por su elegancia. El código es el siguiente:

  ) { : | : & };:

Así de simple. Si introducimos lo anterior en una consola de Linux, probablemente el ordenador quedará inmediatamente colgado. O no. Este código se conoce desde hace bastante tiempo y es posible que en vuestra distribución de Linux ya no funcione porque hayan implementado algún tipo de protección contra usuarios suicidas. Por ejemplo, en mi Fedora 10 no funciona. Si lo analizamos, es lo mismo que escribir lo siguiente:

funcion() {
	funcion | funcion &
};
funcion

Ahora está mucho más claro: definimos una función y luego la llamamos. Dentro de la misma, se llama a sí misma y el resultado se pasa por una tubería a ella misma de nuevo y todo estos se ejecuta en segundo plano (carácter “&”). Es decir, de cada proceso salen dos nuevos, y de cada uno de ellos, otros dos, y así hasta que el sistema operativo lo permita.

Windows también tiene su versión de línea de comandos, y tiene esta pinta:

:s
start %0
%0 | %0
goto s

Hace lo mismo que la anterior. Basta con guardar esto en un fichero de texto y cambiarle la extensión de “.txt” a “.bat”. Tras esto, ejecutar y disfrutar del espectáculo. Guardad todo lo que estéis haciendo primero, que esta sí que funciona, aunque no deja el sistema totalmente colgado, porque llega un momento que los procesos creados empiezan a dar errores de aplicación y la carga del sistema baja, con lo que se puede llegar a hacer algo, pero de todas formas hay que acabar reiniciando.

Y ahora vienen las bombas buenas. Las que dejan al sistema congelado sí o sí, tanto para Linux como para Windows, en lenguaje C. La primera la del pingüino:

#include <unistd.h>

int main(void) {
	while(1)
		fork();
	return 0;
}

Copiad este código en un archivo y guardadlo como “.c”. Tras esto, compiladlo con nuestro querido gcc —sí, de acuerdo, es una mierda, pero es nuestra mierda— y lanzad el binario. It works!

Bien, y como lo prometido es deuda, la versión de Windows (esta es cosecha propia, seguro que las hay mejores):

#include <windows.h>

int main (void) {
	STARTUPINFO si;
	PROCESS_INFORMATION pi;

	ZeroMemory( &si, sizeof(si) );
	si.cb = sizeof(si);
	ZeroMemory( π, sizeof(pi) );

	while(1)
		CreateProcess ("bomba.exe", NULL, NULL, NULL, TRUE, 0, NULL, NULL, &si, π);
	return 0;
}

Aquí el archivo se llama “bomba.cpp” y al compilar queda como “bomba.exe”, por lo que la llamada anterior hace que se inicie a sí mismo. Para los que lo queráis probar, podéis descargar el ejecutable desde aquí.

Como ya hemos comentado, no es algo grave para ningún sistema operativo y un ordenador personal, pero sí que hay que tenerlo en cuenta cuando se trata de servidores. Los administradores deben tener cuidado y configurar adecuadamente los equipos para evitar que usuarios tocahuevos con acceso shell puedan darles un disgusto. Así pues, la solución que pueden aplicar es limitar el número de procesos que puede crear un usuario. Con 20 son más que suficientes. En Linux, mediante el comando ulimit -a podemos ver el número de procesos máximo de nuestro usuario. En mi distribución, el límite está en 1024, algo alto. Esto se puede modificar en el archivo /etc/security/limits.conf.

Para más información y para ver bombas en otros lenguajes de programación, visitad la página de la Wikipedia (primer enlace).

Diagnóstico

¿Doctor, qué le sucede a mi PC? El síntoma más claro de que nuestro disco duro pudiere albergar sectores defectuosos es que todo va bien en apariencia, pero observamos mucha lentitud en determinadas acciones. ¡Ojo! No confundir con la tontería creciente que va acumulando Windows con el paso del tiempo, no… Me refiero a LLLLLLEEEEEEEEEEENNNNTTTIIITTTTTUUUUUUUUUUUUDDDD (el ordenador puede llegar a quedarse parado), y además en puntos concretos: al abrir un archivo, al iniciar el PC, etc.

¿Y si tiene sectores defectuosos, es grave? Depende; para empezar del número de defectos, y, por último, del tipo de estos. Existen dos tipos: sectores mal magnetizados y defectos materiales del disco. Los primeros se pueden arreglar fácilmente con el software adecuado. Los segundos no tienen remedio, pero si no son demasiados podremos seguir utilizando el disco sin problemas tras realizar unos apaños. ¿Por qué se produce esto? Generalmente por tratar el PC con cariño a hostia limpia. Lo malo que tienen los defectos materiales es que, si son muchos, pueden indicar que el deterioro del disco va in crescendo. Por lo tanto, más nos vale comprar otro (y cuidarlo mejor). En cualquier caso, y dejando aparte el disco, lo peor que nos puede pasar es que perdamos algún archivo.

Ya nos hemos mentalizado. ¿Por dónde empezamos?

Antes que nada, recomiendo bajar un LiveCD que os puede sacar de más de un apuro y más de dos, y que contiene la mayoría de las herramientas que os voy a recomendar. Se trata del Hiren’s BootCD.

Lo primero que hay que hacer cuando Windows empieza a tambalearse es ejecutar el CHKDSK (el que por allí por Windows 98 se llamaba SCANDISK). En mi caso, había un problema: Windows no llegaba a iniciarse, y sin Smint no hay beso. Esto significaba que los sectores defectuosos se encontraban al principio del disco: mal rollo… Así que nada, metemos el LiveCD, arrancamos, y ejecutamos una herramienta llamada NTFS Dos Pro, que lo primero que hace es ejecutar CHKDSK. En este punto ya confirmé que había sectores defectuosos, pero como la herramienta en cuestión es estúpida, no hace nada con ellos.

Una vez confirmado el diagnóstico, lo primero es utilizar la excelente herramienta llamada HDD Regenerator (en el mismo CD mientras no diga lo contrario). Es un programa bastante lento, todo hay que decirlo, pero con la peculiaridad de que repara los sectores defectuosos debidos a errores magnéticos sin pérdida de datos. Si hace bien su trabajo, solucionado. Como mucho, tendréis que volver a copiar los archivos del sistema de Windows si no carga porque estaban dañados, y el PC como nuevo.

Los sectores están materialmente dañados

Todavía no está todo perdido (ni lo estará). El programa Seagate Seatools Graphical es capaz de encontrar los sectores defectuosos y marcarlos, haciendo una lista con ellos. Así, el sistema operativo los ignora, y es como si no existieran, como si tuviéramos un disco duro un pelín más pequeño. Vale, perfecto. Tras esto, como en el apartado anterior, el disco como nuevo.

Son demasiados sectores y la cosa va a más

El disco duro está en las últimas. Pobrecillo. Habrá que copiar todo a un disco nuevo y corregir allí los errores. Tenéis diversas herramientas en el CD que seguro funcionarán muy bien (como Norton Ghost, Acronis True Image, etc.), sin embargo, al ser un sistema de ficheros NTFS, acudí a una herramienta específica: ntfsclone. Os recomiendo para ello el SystemRescueCd, un LiveCD de Linux que contiene todas las herramientas más importantes de Linux para la recuperación de nuestro sistema.

Conectamos el disco duro nuevo vacío (como esclavo, por USB, o como queráis), iniciamos y ejecutamos lo siguiente:

ntfsclone --rescue /dev/hda1 --overwrite /dev/hdd1
dd if=/dev/hda of=/dev/hdd bs=446 count=1

La primera sentencia clona la partición NTFS dañada (hda1) al nuevo disco (hdd) ignorando los errores de lectura debido a los sectores dañados. La segunda, copia el MBR, para que podamos arrancar desde el nuevo disco. Ahora no recuerdo si es necesario poner el flag de boot en la partición del nuevo disco, pero eso es fácil con cualquier editor de particiones (recomiendo Gparted, del LiveCD de Linux).

¿Ya está?

No. Ahora viene lo bueno: tenemos un disco sin daños, pero con supuestos sectores dañados marcados gracias al punto 3. Hemos clonado el disco, para lo bueno y para lo malo. Si queremos redimensionar la partición, por ejemplo, no nos dejará debido a esto. ¡Pero sabemos que no están realmente dañados! ¿Cómo los desmarcamos? Esto no es tan fácil. Al parecer Windows Vista trae un CHKDSK con una opción /b que vuelve a repasar los sectores marcados para ver si realmente están dañados, pero, obviamente, no merece la pena instalar ESO… La solución la encontré en el LiveCD de Linux que os acabo de recomendar (por esta razón recomiendo ese y no otro), pues es de los pocos que he visto con el programa que necesitamos: ntfstruncate.

Primero ejecutamos lo siguiente (sustituimos <partition> por nuestra partición):

ntfsinfo -i 8 <partition>

Esto nos da una información de salida. De ella, bajo el título “Dumping attribute $DATA (0×80)”, tenemos que buscar el apartado que dice “Allocated size” y copiar el valor que aparece a la derecha. Ahora:

ntfstruncate <partition> 8 0x80 '$Bad' 0
ntfstruncate <partition> 8 0x80 '$Bad' <ntfs_size>

Donde <ntfs_size> es el número que hemos copiado antes. Ya está. De esta manera, hemos eliminado la lista de sectores defectuosos que habíamos mencionado más arriba. Sólo queda ejecutar el CHKDSK de Windows para que arregle algún índice y como nuevo.

(John von Neumann, matemático húngaro-estadounidense, 1949)

(Vista en una viñeta de Mauro Entrialgo, humorista gráfico que publica en Público, y recogida por El Perro Mistetas)

(Vía: haha.nu)

(Vía: caduca HOY)