The long tomorrow

Esta semana no ha sido la mejor, por así decirlo, ni en mi curro (a pesar de avances importantes en recortar los consumos de memoria, tanto globalmente como dinámicamente) ni en desarrollos en casa. Sin embargo una nueva utilidad ha aparecido en mi radar: la extensión Subversion para el visual studio: ankhsvn. La estoy probando un poco y ha funcionado bien. No creo que llegue al nivelazo de la integración con sourcesafe, pero para entornos híbridos o con sistemas basados en unix puede ser útil.

Un pequeño resumen de la semana incluye:

1. Hemos probado el modo multiplayer de Guitar Hero 2 y terminar convencido de que no está mal, aunque el diseño de niveles no está pensado para jugar dos personas.

2. Mi DS ha vuelto a la vida y he probado el Metroid Fusion. Me ha llamado mucho la atención, junto al Castlevania: harmony of dissonance. Si alguno dispone de una DS ó una GBA hará bien en conseguir las dos joyas y jugarlas a fondo.

3. Como técnico de fin de semana sigo poco a poco volviendo a C++ y, para continuar con mi batalla por los formatos, he empezado a trabajar en la carga de ficheros .X manualmente. Las funciones de ayuda incluidas con las DX-utils facilitan mucho la vida a la hora de cargar mallas y “cosas normales”, pero qué pasa si por ejemplo quieres cargar una ruta, un mogollón de vectores, o cualquier otro elemento que no sea necesariamente rendeable: pues que tienes una situación en ciernes XD

He incorporado a la barra lateral, en la sección DirectX algunos enlaces a toymaker que he encontrado muy útiles para empezar a entender qué leches estaba haciendo cuando cargaba un fichero .X
También me ha resultado muy útil el foro de gamedev.

Algunas cosas a tener en cuenta son:
1. Es necesario precargar los templates sobre la estructura básica del fichero.
2. Al ser un desarrollo clásico de Microsoft, no todos los recursos son fáciles de alcanzar ni mucho menos,

#include "rmxftmpl.h" // Incorpora los templates precompilados
#include "rmxfguid.h" // Constantes de identificación de frame


El código de trabajo con ficheros de tipo X sera necesariamente muy recursivo y empezará con algo como:

LPD3DXFILE p_file = NULL;
D3DXFileCreate(&p_file);
p_file->RegisterTemplates(
D3DRM_XTEMPLATES,
D3DRM_XTEMPLATE_BYTES);
LPD3DXFILEENUMOBJECT p_xFileObject = NULL;
p_file->CreateEnumObject(
"Media\\file.x",
D3DXF_FILELOAD_FROMFILE,
&p_xFileObject);

Cualquier búsqueda en gamedev con alguna de las funciones que aparecen en los snippets anteriores os llevarán directos a ayudas y consultas completas.

De vuelta al trabajo de fin de semana: sigo a castañas con problemas de formatos y conversiones entre ellos. Pero esta vez he decidido lurkear entre los foros de XNA sobre MOD y he llegado a algunas desoladoras aunque esperables conclusiones:

El soporte que da Softimage a través de MOD y XSI a DirectX es poco menos que un chiste[1]. Como ya venía diciendo en posts anteriores la exportación geométrica funciona bien, y la salida de coordenadas UV es directamente de chiste. No quiero ni imaginarme lo que ha de ser tratar de sacar animaciones del paquete. Dejaremos las animaciones para más adelante (que será otra odisea criminal)

Sin embargo, sí hay una solución y como siempre, desde el lado más gamberro del 3D: ¡blender! Blender dispone de un exportador out-of-the-box que funciona correctamente al generar .X

Efectivamente el procedimiento incluye pasar por .OBJ para llegar hasta el objetivo, quedando algo así:

1. Se genera todo el contenido sobre XSI + GIMP + nVidia texture tools + …
2. Se exporta a .obj
3. Se abre el .obj con Blender
4. Se exporta a .X

Este procedimiento es algo rústico, ya lo sé. Pero abre la puerta a generar contenido para .X sin necesidad de machacar ninguna versión de MAX; MOD es gratuíto y Blender es libre, y, si realmente te apetece se puede obtener todo el material desde Blender sin necesidad de pasar por la herramientita de XSI, lo que posiblemente sea la mejor opción al estar MOD severamente modificado y resulta en el ahorro de un cambio de formato con todas las pegas que esto tiene.

–
1. No he probado la versión 6.5 pero que no me vengan con hostias: las limitaciones al exportado eran severísimas: un sólo canal de textura por punto (clúster, para ser exactos), que luego había que escalar en las 2 coordenadas por -1.

Los programadores de C++ del mundo tienen (tenemos) mucho que aprender de Java. A pesar de ser un lenguaje comparativamente joven, su masiva aceptación y su implantación en decenas (sino todas) las grandes compañías de desarrollo software del mundo han producido un buen cuerpo teórico y de herramientas.

De entre ellas hay una especialmente interesante JUnit. Es un framework de desarrollo orientado al test. Funciona muy bien y se integra sin problemas en Eclipse, NetBeans y con Ant. Sé que algunos de vosotros estaréis pensando que se me ha ido la cabeza: que ant es un remedo de make y el TDD lleva siendo una característica nativa de python desde la versión 0.0 alpha. Bien, no lo niego. Simplemente a veces cuesta darse cuenta y entrar en la dinámica.

Incluso hay una versión razonablemente limpia para Java para móviles j2meUnit. Evidentemente no funciona igual de limpiamente que la versión completa para Java. Tampoco es una JVM tan potente qué carajo.

Lo que sí me resultó curioso fue que hablando con un compañero del curro y contándole toda la instalación me soltó el clásico: no tengo tiempo de mirar esa chorrada. Qué interesante. He oído eso mismo un puñao de veces y no hay ocasión en la que esa chorrada, no termine convertida en una tecnología dominante:

Para qué estudiar Java, es un lenguaje interpretado, … qué lento!

¿Qué es eso de Python? … báh, otra chorrada de esas GNU que te gustan a tí …

etc.

Un amiguete llamaba a esto las “ultimas y gloriosas frases”. Hay algo de verdad en que nunca se tiene tiempo para nada. Lo curioso es que muchas veces, esta inversión de algo de esfuerzo te vuelve en una productividad multiplicada ^_^

Sigo con el montaje del RAID5 + 1 para el Labsys en Santiago de Compostela.

Estos días no ha habido entradas porque, sinceramente, esperaba poder hacer uno de esos post de gran relumbrón en los que se cuenta lo listo que se es y lo grande que se tiene.

Bien, al grano. Después de pelearme un rato con el paquete nbd-client y nbd-server comprobé que lo único que faltaba en la inicialización era crear los dispositivos nbd en el sistema cliente. Son dispositivos de bloque con mayor 43. Así que ya sabéis, un pequeño mknode y queda el asunto arreglado.

El uso de nbd-client es trivial después, pero por si acaso, siempre que falle, conviene empezar comprobando:

0. Iptables configuradas en modo NO draconiano, no olvidemos que esto es un servicio de red, señores.
1. Que el servido está en activo (no es coña, puede pasar)
2. Que la conexión se ha levantado correctamente (netstat -tp | grep nbd)
3. Que el fichero de dispositivo bloque 43:x está correctamente creado.

Respecto de la seguridad de conexión en el servicio, existe un fichero asociado a nbd-server que identifica los clientes permitidos, no lo empleo porque soy un macarra pero en principio creo recordar que sigue el nombrado clásico, acabado en .allow ó algo por el estilo.

Bien una vez tienes todos los detalles estos resueltos es posible y fácil hacer algo así como un:

nbd-client host puerto dispositivo
cfdisk dispositivo — en este momento no estoy del todo seguro de que sea necesario, hazlo que no molesta mucho.
mkfs -foo -bar -temp dispositivo
mount dispositivo

Y tendrás un disco duro añadido al sistema. Bien, esta es la primera etapa del viaje.

RAID

Lo primero que hace falta es un kernel que soporte RAID, esto es fácil ahora que el kernel compila casi solito. Después necesitas instalar este kernel en la máquina que vaya ha hacer de concentrador principal.

La idea es instalar el servicio nbd-client únicamente en una máquina y mapear todas las unidades que planees emplear como parte del RAID. Luego se crea el RAID. A partir de este punto empieza el pantano. Los howtos que se encuentran en internet están en su mayoría enfocados al uso de las raidtools y no del mdadm, herramienta más reciente y que unifica la capacidad del raidtools en un único ejecutable.

Notar que a partir de aquí empieza el terreno pantanoso: en mi opinión para hablar con cierto criterio de esto hay que ser un experto en sistemas de almacenamiento y temas de arquitectura de buses. Pero en fin ahí voy a la piscina.

1. Lo primero que se hace es crear el RAID, se ejecuta un mdadm –create, se elige el nivel de RAID que se está buscando (0,1,5,linear,…) y quedan preparados los dispositivos. Bien en este punto un experto diría que hay que ajustar los tamaños de “chunk” del RAID para afinar el rendimiento, que depende del número y tamaño del fichero medio que vayamos a emplear en el mismo.

2. A partir de aquí lo lógico es hacer algunas pruebas de desmontado y ajustar el fichero de configuración de mdadm (/etc/mdadm/xxx.yyy) Si tienes dudas acerca de cómo está montado el raid prueba a hacerle un cfdisk al dispositivo RAID, poco ortodoxo pero funciona.

En este punto llega el dolor: una vez tienes el RAID montado, dispones de un dispositivo de bloques, generalmente un /dev/md0 ó algo por el estilo. Para usarlo hay que crear un sistema de ficheros sobre él. El propio gestor de RAID se debe encargar de la gestión de los chunks, replicación coherencias, etc. En general dependiendo de cuándo se escribió el howto se encuentra ext2 / ext3 / reiser. Siempre creado a lo macho mkfs.ext3 /dev/md0.

Pues bien, si has llegado hasta aquí, ejecutas el mkfs y te funciona, quiero saber cómo lo has montado porque en mi caso, comienza la ejecución del creador de sistemas de ficheros y se cuelga tras una intensa actividad de red. Supongo que la palabra colgarse sonará a rookie, pero no: ni top ni ssh ni nada, sospecho que el sistema de ficheros se queda más frito que un churro. Y a partir de aquí todo es bruma y duda:

1. ¿La relación nbd + RAID es excesiva con volúmenes de 100GB?
2. ¿Es un problema únicamente del módulo de RAID?
3. ¿Funcionará empleando una capa intermedia de LVM ó sólo complica las cosas?

Os iré contando conforme vaya sabiendo. Ánimo que este negocio puede ser a veces muy muy frustrante.

Seguimos con el problema de los discos distribuídos en red: se busca crear un “disco virtual” único sobre unos appliances usados para renderizar mágenes. Sé que la idea no suena bien y mezcla máquinas de producción con máquinas de servicio; pero es lo que hay. Cuando no hay ni un leuro a la vista se aprende a ser pragmático y asumir unos riesgos completamente suicidas.

Comencé echándole un ojo a las soluciones que se habían propuesto para almacenamientos y redes de almacenamiento de tipo SAN, vayan aquí unos links: Redes de almacenamiento explicadas. Si te lees el artículo, completamente recomendable, llegarás a la conclusión siguiente:

SAN = SUN = $SUN = (SCSI + fiber + multiproccesor) …

A partir de ahí me desinflé un poco y me tiré de cabeza a google, seguimos con NAS (Network attached storage)

Donde ya aparecen algunos conceptos familiares algo menos $únnico$, NFS, IP, CIFS, palabritas muy queridas por todos nosotros. Quedaba claro que existía una solución software para resolver el problema pero Wikipedia no afinaba más la búsqueda. De vuelta a Google.

La tercera búsqueda en Google me lleva a una página tope de divertida, un “Alien vs. Predator” del almacenamiento: . Hay que
joderse, podría haber empezado por ahí y me habría ahorrado un buen rato de búsqueda.

Pero no todo es tan sencillo: aparece aquí otro contendiente “AoE”
, ¡esto era de lo más prometedor!

Ya que las máquinas de las que disponía admitían SATA. Y, … todo marchaba bien … pero, súbitamente: Artículo Coraid

La clave de este artículo está en la palabra Coraid que, como habrás adivinado, sagaz lector, es el cerebro detrás del appliance que cubre el artículo de Linux Journal. Le doy algunas vueltas más pero no he encontrado modo humano de emular AoE mediante software y cada día que pasa más convencido estoy de que era una soberana chorrada.

Así que me decido a volver al segundo candidato: NAS. Buscando buscando averiguo
(vía Slashdot) que existe un servicio nbd (network block device) capaz de compartir un dispositivo de bloques sobre TCP y hacerlo ver como local a una máquina tercera (en el clásico ejemplo de cliente / servidor).

Como si hubiese visto la luz me tiro a por nbd como un kafre: y he aquí lo que encuentro: resumen RAID , ¡joder pero si hay un mogollón de recursos!

Mientras llego a esta conclusión estoy montando un Debian en uno de los appliances destino, compruebo, aterrado, que el hardware entre las máquinas difiere levemente, el mapeo de las unidades SATA, por poner un ejemplo, no está coincide en las IDES, las tarjetas gráficas son distintas, el kernel base que
reconoce los dispositivos es el 2.4, … esas cositas. Pero tampoco pasa nada, te armas de paciencia bajas la 2.6.13 y a compilar, … curiosamente la compilación es limpia y fácil.

Una vez tengo un kernel nuevo (y esto empieza a parecer una receta de cocina) le echo un ojete al sistema de paquetería de Debian (stable/Sarge) y los ojitos se me ponen de colores cuando veo que nbd y nbd-server están como paquetes deb, todo bonitos, todo chequeados, ¡aúpa Debian! que viva la madre que los parió!
Los instalo sin pensarlo mucho, ahora creo que eso ha sido un error ya que se me han acumulado demasiados servicios en la instalación base.

Hago una pequeña consulta a Warp networks http://www.warp.es/ porque tengo la memoria hecha un queso y no me acordaba del nombre de la herramienta de sysadmin por excelencia (sí, más allá de quota y rm -Rf /home/encefalopower), partimage. Que sirve, como todos recordaréis, para clonear particiones. Me bajo las dos distribuciones la binaria estática y las fuentes.

Hagamos un pequeño recuento hasta el momento:

Y me faltaba una cosa: … el RAID! de vuelta a wikipedia para tener una visión histórica de lo que estaba haciendo: este artículo sí es muy interesante. Le doy un par de vueltas y tras echar mano del howto me doy cuenta de que estaría de cojones tener un LVM que agrupase todo el RAID junto y lo hiciese más sencillo.

Este esquema te lleva a tener una GIGA-LAN sobre la que vas a montar un montón de máquinas haciendo una especie de NAS. Agrupas estos dispositivos en un tercer equipo donde montas los nbd’s y les creas un RAID, sobre el RAID un LVM y cuando lo tienes todo ya montado publicas este LVM como particiones por red,
específicamente en CIFS / Samba / NFS (esto depende de lo exigente que sea tu público) En mi caso tendrá que ser un diskote compatible con Windozes así que no me quedan más pelotas.

Me falta por contaros: creación (rápida y fácil) de un arranque por USB más todo el proceso de cloneado más el montaje del RAID, dadme algo de tiempo.

Resulta fascinante cómo funciona la mente femenina cuando se deja que administre un piso / hogar / casa / madriguera juanker ó como se le quiera llamar. Mientras mantienes una sesuda conversación acerca de campos discretos de potencial, empleando absolutamente toda la capacidad mental de la que dispones, ella para un momento y suelta algo como … hay que limpiar esos hornillos, … para continuar el tema exáctamente en el punto en que lo dejó.

Ahora bien, no nos llevemos a engaño, se va a ir al curro y te vas a quedar frente a los hornillos. Está claro que uno de esos comentarios no se hace a la ligera y si se quiere que la vida en pareja funcione bien (que nadie interprete esta frase de ninguna manera ) hay que plantearse ciertos sacrificios: enfrentarse a unos hornillos rebeldes es uno de ellos. aparentemente no están muy sucios. Luego cometes el error de tocarlos con las manos desnudas y se comprueba, inmediatamente, que sí lo estaban.

No me alargaré mucho más porque este post (de la sección de herramientas) está dedicado a uno de los productos más perfectos de la moderna guerra química: el KH-7, desengrasante eficaz, fiel compañero contra el detrito, camarada valiente y tenaz, poco amigo de melindres, dudas ó recelos, siempre fiero, arrojado y, por encima de todo, ¡letal para la roña de los hornillos!

Valga este comentario como sentido homenaje …

Durante estos dos años he conocido bastantes profesionales del gremio de la informática, hoy he echado un instante la vista atrás y me apetece comentar algunas conclusiones divertidas. Como en cualquier tema, la generalización me llevaría a ser injusto e impreciso; afortunadamente este blog no pretende evitar ninguna de ambas cosas. Así que adelante con el asunto:

Comencemos por el sector funcionarial del gremio de informáticos en sistemas: tienen un buen montón de usuarios (otros funcionarios en su mayor parte) y disponen de un fabuloso escudo burocrático para mantenerse inactivos. Resulta fascinante cómo el sistema (como el de la Universidad de Zaragoza) es totalmente ineficiente e inútil cuando las peticiones las hace un estudiante; y lo bien que funcionan las peticiones puerta a puerta de los secretarios de los centros.
Todos recordamos la guerra que se mantuvo para instalar vim en Merlin, hazaña incontestable, gesta épica de la administración. Ó cuando el blaster, o el sasser, arrasó la red gracias a la ausencia de directivas de seguridad y cortafuegos estables y mantenidos.

Durante aquellas maravillosas semanas tuve la oportunidad de escuchar de todo, la conclusión general era que se necesitaba contratar más gente para que se hiciese cargo del servicio de mantenimiento de seguridad de red. Se referían evidentemente a que hiciesen otros el trabajo. Seguro que Koke nos podría contar qué habría pasado en su empresa en una situación similar .

Es evidente que la administración pública, institutos de investigación, becas, etc. todo el tema se gestiona de un modo bastante parecido, es decir: malo. En la privada existe una peligrosa tendencia a echar a la gente de mantenimento cuando el sistema va demasiado bien. Recuerdo haber oído hablar a un tipo diciendo que saboteaba intencionalmente el servicio de email de los cargos intermedios para mantenerse en el puesto de trabajo. Buen truco. Lo echaron cuando externalizaron el servicio.

No quiero extenderme ahora -. aunque podría hacerlo .- porque hay una conclusión sencilla: salvo que seas funcionario, no dejes de estudiar jamás.

De modo imperdonable había abandonado mi portátil a su suerte durante los últimos meses. He de admitir, avergonzado, que lo empleaba únicamente para leer algún documento. Pero hace unos días recordé que había salido una versión nueva de Debian, … y me tentó.
Volver a ver las pantallas de texto plano, navegadas por ncurses, la barra de resalte controlada por los cursores, grub, exim, less, vim, esos viejos conocidos que han vuelto. La instalación fue como la seda, ninguna pregunta cósmica ni duda existencial, los repositorios funcionaron de maravilla, los debs bajaron como un manso río.
Ver esa pantalla imposible de la carga del XServer, y el gdm, frío y eficaz, tan Unix.
Como el viajero que vuelve a su ciudad y se sorprende al ver que aún siendo la misma, ha cambiado. Nuevas caras, algunos conocidos algo más maduros, viejos compañeros que han sido abandonados en la orfandad de paquetes …
Podría seguir así toda la mañana, Debian no te deja tirado.

Escribo esta entrada desde el portátil, han vuelto las peleas con las fuentes del núcleo, los módulos de memoria y los mensajes de email a la cuenta redireccionada del root. ¿Quién podría decir que se podía echar esto de menos?