Algo huele a podrido en OpenSuSE 10

Una de las cosas que más ocupado me ha tenido estas últimas semanas es un ordenador que se quedaba bloqueado porque sí.

Se trata de una máquina TYAN (un Transport VX50), que venía del distribuidor (una pequeña empresa local, que lo montó en instaló el S. O.) con una placa base TYAN (la Thunder n4250QE (S4985-E)) para cuatro procesadores AMD Quad Core de 64 bits, y una placa de expansión de la placa base también TYAN (la M4985), para montar un total de 8 procesadores de núcleo cuádruple y 128GiB de memoria. Ah, y 8TB de disco.

¿A que mola? El caso es que la máquina, que venía del distribuidor con OpenSuSE 10 (la 11 no había salido aún), se quedaba bloqueada. Como suena. Simplemente estaba trabajando y de repente dejaba de responder. Todo. Ni contestaba al PING ni se veía nada en la pantalla. Y los leds del teclado, parpadeando.

Pensamos que era cosa de la temperatura, así que subimos la velocidad de los ventiladores en la BIOS. Se siguió cayendo.

Pensamos que era cosa del ECC, así que lo desactivamos en la BIOS. No estamos seguros, quizá se caía menos, pero se siguió cayendo.

Pensamos que era cosa de la memoria, así que le corrimos un memtest durante un fin de semana. Con 128GiB pues solamente le dió una vuelta a la memoria, pero estaba limpia. Otras pruebas en la que obligamos a la máquina a swapear de mala manera con cargas del orden de 400 no hicieron caerse la máquina.

Finalmente hemos pensado que fuera cosa del entorno gráfico. A fin de cuentas, ¿quién sabe? ¿Y qué falta hace un entorno gráfico en una máquina de cálculo científico? Hemos desactivado el entorno gráfico pasando el nivel de ejecución del 5 al 3. Y la máquina lleva dos días calculando sin parar.

¿Habremos acertado ya?

Lo peor es que si fuera eso, algo en OpenSuSE 10 (en su entorno gráfico, en particular) no está nada bien. Y de ser así, mi candidato a culpable es earlyxdm.

Pongamos un SAI al mundo

Un ordenador.

Una subida de tensión.

¿Qué tenemos? Ordenador frito.

Y sabiendo el estado de la red eléctrica nacional, y más en estas fechas en que todo el mundo enciende el aire acondicionado, debería ser obligatorio que el dinero que salga de mis impuestos esté protegido, ¿no?

Me refiero a que debería ser obligatorio que los ordenadores de las instituciones públicas tuvieran SAIs (o mejor SS.A.I.) para evitar las pérdidas causadas por picos o apagones.

Pero bueno, el caso es que he conseguido 10 SSAI para proteger algunos de los ordenadores de quien ahora mismo hace como que paga mis facturas: el Departamento de Astronomía y Astrofísica de la Universidad de Valencia. Deberían haber sido prácticamente el doble, pero todavía hay gente que considera que el material de trabajo de <<su>> puesto de trabajo es suyo. Y se equivocan, pero yo no puedo obligarlos a hacer las cosas bien. Algunos me han dicho, incluso: <<¿SAI? Ni tengo ni quiero.>> Debería ser delito de malversación de caudales públicos.

Eso sí, cuando venga otro apagón generalizado, a mí que no vengan a quejárseme.

Bueno, a lo que íbamos. Ya he instalado el primero de esos SSAI. Un ordenador que antes estaba desprotegido, ahora está protegido.

El programa de elección para efectuar el apagado del ordenador ha sido Network UPS Tools (NUT), en su versión 2.2

El SAI elegido es un APC Back-UPS CS 500. No proporciona mucha autonomía a un ordenador grande con su pantalla, pero la idea no es proporcionar autonomía, sino evitar un casque por un mal apagado, de los que ya hemos tenido por aquí.

Me hubiera gustado elegir otra marca de SSAI. Las APC tienen buenas y malas costumbres. Entre las buenas, que son fiables como rocas y que tienen asegurado el suministro de baterías de recambio. Entre las malas, que no colaboran con los programadores de programas libres y tratan de obligarte a utilizar su pesado y patético programa PowerChute.

Gracias a $DEITY los SSAI de la serie CS se pueden enchufar por el puerto USB y responden aceptablemente al controlador usbhid-ups de NUT.

Así, tras bajar NUT y realizar los típicos ./configure, make y make install (lamentablemente el ordenador a proteger dispone de una distribución que no tiene paquetes para NUT), obtuve un precioso y funcional sistema. Luego fue cosa de tocar un poco los ficheros de configuración.

Como nota, el SAI informa de batería en estado crítico cuando se encuentra al 10% de su capacidad, lo que no da tiempo al ordenador para apagarse correctamente. Por ello, he tenido que utilizar la última pieza del conjunto, upssched, diseñada específicamente para apagar el sistema antes de que se alcance la condición de batería en estado crítico.

Algunas verdades

Una imagen...

Diseños de teclado

A consecuencia de una pregunta de un compañero, he pasado hoy buena parte de la tarde mirando documentación (ciertamente escasa) sobre el sistema XKB. Se trata de la capa que transforma las pulsaciones de teclas en símbolos que entienden las aplicaciones. Además, he mirado no solamente la propia documentación (sobre todo la muy completa de Ivan U. Pascal y la muy comprensible de Doug Palmer) sino los propios ficheros de definiciones y reglas de XKB. Allí me he dado cuenta de que existe un modelo de teclado llamado «latitude», equivalente en casi todos los aspectos al «pc105» que se supone que debería usar, solo que tiene correctamente asignadas las teclas 174, 176 y 160, es decir, <I2E>, <I30> e <I20> a las «pseudoteclas» XF86AudioLowerVolume, XF86AudioRaiseVolume y XF86AudioMute.
Así, sólo con haber cambiado el modelo de mi teclado en /etc/X11/xorg.conf de

Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "es"
EndSection

a

Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "latitude"
        Option          "XkbLayout"     "es"
EndSection

he conseguido que funcionen las teclas para subir o bajar el volumen.

Blog de Toscalix en castellano

Bueno, hace mucho que no escribo en la desbitácora, al contrario que en la bitácora. Pero no ha sido por falta de trabajo, sino al contrario.

Pero en fin, al grano. He inaugurado la sección de Enlaces (quizá) interesantes (al fondo a la derecha, como el servicio) con la bitácora de un amigo y ex-jefe, Agustín Benito.

Él no es desarrollador, al contrario de lo que podría parecer ya que enlazo su bitácora en castellano (tiene otra en inglés) desde aquí. Es una cosa rara. Yo lo llamaría un intermediador. Busca gente que necesite programas libres, y tiene contacto con gente que hace o gestiona programas libres. Y gana dinero en el proceso. Bien es verdad que no demasiado: en ese plan tuvo una empresa en la que yo trabajaba. Éramos solamente nosotros dos, y la relación tenía una parte de jefe-empleado, obviamente, y otra parte de comercial-técnico. Yo a veces decía que él trabajaba para mí, como comercial de mis soluciones técnicas, y además me pagaba.

Finalmente yo me vine a la Universidad de Valencia a mantener sistemas y acabar de una vez mi doctorado, y él, dado que no se puede mantener una empresa técnica sin un técnico, cerró. Por el camino hicimos varias cosas interesantes, y a veces uno debe pararse y mirar atrás.

En colaboración con otras miniempresas como Neuroomante de Pedro Gracia (Lasarux) desarrollamos una solución de aula LTSP con UML para docencia informática que era un primor. O las soluciones de firma de discos duros que están en esta misma desbitácora. Pero no siempre había clientes, y había que comer todos los meses (él vivía de ello, y yo trabajaba a media jornada), y también nos tocó «pringar» con cuestiones de mantenimiento de sistemas Windows, casi siempre piratas, subcontratados para empresas de nuestro mismo estilo pero un poco más grandes, o instalar cableado.

En esa época aprendí mucho, no sólo como técnico (lo que debo agradecer sobre todo a Lasarux, Kuko y la gente más antigua de Fotón, ustedes saben quienes son, chicos, gracias por todo), sino sobre cómo llevar (y cómo no llevar) una empresa o un proyecto basados en programas libres. Toscalix, a su vez, creo que aprendió de mí algo de filosofía libre (no demasiado, porque interferiría en su trabajo, que es ganar dinero con ello), algo de sistemas, y sobre todo de cómo trabajar con programas libres y montar redes. O al menos eso quiero creer.

Bueno, la etapa ha acabado. Ahora yo, con todo lo que aprendí con él, mantengo ordenadores de cálculo científico en Valencia, y él, con todo lo que aprendió conmigo, trabaja en un proyecto de migración a programas libres en una comarca de Málaga. Y seguimos pensando diferente, y seguimos siendo amigos.

Como nos enseña la mecánica cuántica, quizá nuestros caminos (profesionales) nunca se vuelvan a cruzar, pero habernos cruzado ha alterado nuestras historias para siempre.

Gráficos en TeX

Últimamente he tenido que escribir un trabajo académico. Lo he hecho en TeX porque me maravilla la capacidad tipográfica que tiene y la calidad del resultado final.

La mayor parte de los usuarios de TeX, en realidad, son usuarios de LaTeX. Si TeX hace el trabajo del cajista, LaTeX hace el del tipógrafo-compositor. En mi caso particular, prefiero utilizar TeX en vez de LaTeX (me gustan las cosas a bajo nivel).

Claro que TeX no está directamente preparado para soportar gráficos. Knuth, previendo la diversidad de dispositivos de salida y de tipos de gráficos, tan sólo diseñó la orden \special como una manera genérica de enviar datos a dispositivos de salida. LaTeX quedó mejor en ese sentido.

Fianlmente, la almendra del asunto es que los que usamos TeX, a pelo, también queremos poner gráficos en nuestros trabajos. Y no queremos lidiar con los \special. Esta semana he descubierto que la solución la aporta graphics-pln, gracias al cual podemos utilizar en TeX comandos de LaTeX como \includegraphics o \rotatebox.

La instalación de graphics-pln no merece siquiera tal nombre. Basta con descargar el fichero graphics.zip y descomprimirlo en el directorio de trabajo del documento. A partir de ahí, ya se pueden usar directamente las órdenes gráficas habituales.

En otra entrega hablaré de modos más generales de instalación.

Instrucciones de procesador (I)

Uno de mis eternos proyectos, que retomo una y otra vez y que nunca termino, es diseñar y programar el emulador de un microprocesador.

El núcleo del proyecto de programación es el lector de instrucciones, y eso nos lleva a que una pieza fundamental del diseño es el juego de instrucciones.

Una de las operaciones fundamentales de un procesador es, evidentemente, leer un valor de la memoria y depositarlo en un registro o viceversa, escribir en la memoria un valor presente en un registro.

El diseño de procesador que he elegido implica que estas dos fundamentales operaciones se realicen únicamente desde el registro que he denominado A.

A estas operaciones les he asignado los mnemónicos LEE y SCR y los códigos binarios 0xc0 y 0xc1. Ambas operaciones necesitan como argumento una dirección de memoria.

Asumiendo que el procesador emulado es una estructura de datos que almacenamos en procesador, que la memoria es una matriz que almacenamos en memoria, y que el puntero de instrucción es el registro CI del procesador, el código de emulación para estas instrucciones lo he programado como sigue:

switch(memoria[chip->CI])
{
 case 0xc0 /* Instrucción LEE */
  chip->A=memoria[memoria[chip->CI+1]];
  break;
 case 0xc1 /* Instrucción SCR*/
  memoria[memoria[chip->CI+1]]=chip->A;
  break;
 /* Aquí el código para otras instrucciones */
}

Con este código, una instrucción de dos bytes como 0xc0 0x12 se desensambla como LEE 0x12, es decir, "coge el contenido de la posición de memoria 0x12 y cópialo en el registro A".

Continuaré más adelante...