Archive for the 'Developing' Category

.X contra XSI, formatos

Posted in 3D-devel on September 16th, 2007

Antes o después te toca subirte las mangas y ponerte todo ciego a mover punticos, aristas y caras; más o menos con toda tu buena intención y un poco de ayuda de Digital Tutors. La idea inicial, modelar algo vagamente orgánico, por ejemplo un insecto común: una libélula. Bien, tomé algunas referencias por la web, fotos y demás y me lancé al tema con mi mejor intención:

Dragonfly XSI basic modelling

Es importante destacar que no soy grafista, ni mucho menos artista 3D. Así que la considero un lograzo, dado el tiempo que puedo dedicarle y lo especializado del asunto. Pero aquí, justo cuando tenía el modelo en ese estado, me dio un jamarazo y me decidí a probar el modelo sobre el visor de DirectX[1] Lo que me obligaba a emplear el exportador por defecto que tiene XSI (v.5.11) para sacar mallas a .X.

Por supuesto la geometría exporta más o menos bien, el problema más evidente viene del mapeado de texturas, cualquier parecido con la intención inicial del creador del modelo es pura coincidencia:

Dragonfly XSI UV texturing

El modelo en XSI (a la derecha) tiene alas de madera y cabeza de leopardo[2] , se ve correctamente en el viewport DX9 construido dentro del propio XSI (situación que me hace creer que la cagué en algún paso intermedio probando el pintado de mip maps del artículo anterior y por eso se despelotaron las UVs)

No soy el único que se ha quejado de este exportador, y parece que la solución habitual pasa por no emplearlo en absoluto: se va a .OBJ y luego hacia .X empleando algún miembro de la familia Deep Exploration. En este mismo instante me estoy planteando otros modos de llevar mis pequeños abortos tridimensionales hacia algún render en tiempo real.

Resulta que Softimage está trabajando muy duro para darnos un empujoncito a los chicos que pretendemos ganarnos la vida con tiempo real tienen dos líneas principales de exportado que me llaman la atención: COLLADA y XNA [3]. La porra del XNA es que supone más madera, un entorno gestionado, un brinco más de lenguaje de programación, otra piedrita al montón de movidas que aprender en el poco, poquísimo tiempo libre del que dispongo últimamente.


1. Que viene de serie con el SDK así que lo tienes fijo.
2. Malditos pinceles por parches: dominan mi mente XD!
3. Y espero por nuestro bien que su exportador de .X en las versiones nuevas, sobre todo en la 6.5 le haga algo de justicia a los modelos :P

MIPMap Mayhem

Posted in 3D-devel on September 9th, 2007

Ya lo dicen muchos: leer es malo porque da ideas. Y las ideas, pues ya se sabe, a veces, nos llevan a follones ^_^. Hace bastantes meses leí un paper,, que describía cómo en muchas ocasiones dejamos pasar buenas oportunidades de afinar nuestro render empleando recursos gratuitos[1] del pipeline. Y ya algo menos crípticamente, describía que se pueden editar los niveles de MIP para mancharlos de colores, parece evidente, pero es más potente y flexible de lo que parece.

El ejemplo del artículo era realmente bueno: supongamos que queremos rendear una chimenea cubierta por una finísima capa de hollín. Cuando la miramos directamente, es decir: perpendicularmente, podemos ver el cemento del que está hecha, quizá ennegrecido, pero vemos claramente el gris. Sin embargo, conforme alejamos la vista y observamos zonas más alejadas del tubo, este es progresivamente más y más negro. En un shader, podríamos emplear el ángulo que forma el punto de vista y la superficie para, empleando por ejemplo una textura degradada de un sólo píxel de ancho, obtener un factor de ennegrecimiento, eso es como mínimo un producto dot más una consulta de textura y probablemente una suma ponderada con respecto al color computado para el material base [2]. Lo que quizá sea demasiado para una maldita chimenea, que en realidad está ahí sólo como decorado, etc. etc.

El articulista proponía un camino lateral para obtener el mismo efecto. ¡Usar la cadena de MIPMap! Es decir: pintar de negro los MIPs más profundos, de modo que el filtrado nos dé ese oscurecimiento, sin necesidad de emplear más ranuras de shader: ¡todo pasa por la textura! Okydoky, echando memoria, recuerdo cómo era todo aquello y me digo: mañana de domingo, … no hay resaca a la vista, c’mon, lets do it!

Empecemos por la chimenea, algo suave y redondeado, … un cilindrito!

Base Textured model

Vale, aprovechando que también estoy intentando pulir un poquito mi XSI, hago yo mismo el modelado[3], el mapeado UV y me monto una textura inicial. Y aquí es donde viene el problema: no tengo photoshop! Y tampoco tengo ganas de machacar ninguna versión, he decidido mantener algo más a ralla el volumen de software de origen oscurete que consumo: el GIMP tendrá que valer.

A esto, hay que añadir otra situación: me es físicamente imposible (por tiempo) aprender en profundidad muchas más cosas ahora, así que debo mantenerme en DirectX. Esto me lleva a usar DDS preferentemente ya que luego podré usar todas las demás herramientas que Hasefrocht incluye en su mastodóntico SDK.

OK, recapitulando: DDS + MIPMap y todo sobre XSI PERO no hay photoshop, esto va a ser divertido[4]!

Lo primero que se necesita es bajar el SDK de Microsoft, eso es más que evidente. Luego hay que hacerse con las tools de texturas de nVidia, que podéis bajar del site de: nVidia Texture tools. Todo es recomendable y el mundo de las texturas es gigantesco, pero lo único necesario es el paquete DDS Utilities. Con todo instalado se tira para alante y:

1. Se crea la textura difusa base y se deja bien guardada.
2. La textura base carece de MIPs así que hay que crearlos, para eso Microsoft nos ofrece una herramientita: Texconv.exe con la que podemos batchear una conversión a DDS más la creación de los MIP chains:

texconv -m 6 -f R8G8B8 -ft DDS tex_cilinder.png

Codigo que genera 6 niveles de MIP en RGB de 24 bits desde tex_cilinder.png.

3. Ok, tenemos los MIPs pero no podemos editarlos, al menos no fácilmente ya que no disponemos de photoshop. Aquí entra la utilidad de nVidia[5], en particular:

detach tex_cilinder separa el DDS inicial en toda la cadena de MIPs, es incómodo, pero vamos, se puede automatizar empleando un .bat, ó si dispones de una consola de verdad en tu sistema, pues miel sobre ojeras.

4. En este punto tenemos un puñao de ficheros que no podemos editar, de nuevo empleando las nVidia DDS tools:

readDXT tex_cilinder_00.dds tras lo cual tendremos TGAs, que sí puede editar GIMP.

Yo hice algo tan tontorrón como esto:

MIPMap modified

Como veis el mip inicial es más o menos plano y luego meto dos cambios muy muy cantosos para poder verlos fácilmente en el render.

5. En este punto hay que hacer el camino inverso TGA –> DDS y luego, recomponer el MIP chain:

texconv -m 1 -f R8G8B8 -ft DDS tex_cilinder_01.tga Notar que se le pide un mipchain de longitud 1

6. y para terminar, recomponer el MIP chain sobre un DDS:

stitch tex_cilinder

Y se termina obteniendo una textura en DDS con los MIP maps modificados. Ya con ese material volví hacia XSI y compuse un árbol de render sobre DX muy sencillo, sin shaders programables y con una simple textura, activé el filtro MIP y listo: como veis, las UVs se fueron de baras directamente, lo que me molestó muchísimo. Además no he encontrado un modo sencillo de crear un render de aspecto plano, es decir, con luz ultra-blanca desde cualquier punto, acabaré componiéndolo en un zeider…

Modified MIPMaps but wrong UV Maps

La coña de esta técnica es que funciona. Es curioso verla en marcha, … llama la atención, impresiona, sobre todo porque el MIP-mapping suele ser un punto del render que solemos ignorar, simplemente está ahí y fuera.

El tortuoso camino de la conversión de texturas

Bien, el numero de pasos que hay que dar para editar un MIP-Chain es ridículo, pero de momento no se me ha ocurrido nada mejor (legalmente), si se me llega a ocurrir algo os lo haré saber, como siempre.


1. Sí, ya sé que lo único gratuito es no ejecutar absolutamente nada.
2. Lo que en sí mismo no significa nada: en una 8800 GTX te-la-suda! ;)
3. Soy 1337, ¡he logrado modelar un cilindro! ¡Chúpate esa Baena!
4. Entre otras cosas porque la versión 5.0.x de XSI se da cada castaña con DirectX de alucinar. Se mete unos crashes por desconectar nodos de texturas que son de terror. Esperemos que la versión 6.5.x arregle y reenfoque todo el asunto.
5. Que viene con dos PDFs de ayuda, así que no incluyo ningún link para documentar.

TDD. O la vagancia ruinosa

Posted in Herramientas on April 21st, 2007

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 ^_^

Libertad móvil

Posted in Developing, Indy Games, Videogames on April 11th, 2007

Antes de nada: ¡hola de nuevo! Ha sido un parón largo y ligeramente dramático. Pero parece ser que vuelvo al tajo bloggero más pronto que tarde.

Llevo unas semanas trabajando en Java. Y en python. Y en PHP. Y levantando egroupware. Es obvio que ha sido una temporada movidita.

Pero me desvío, como siempre, del tema: teléfono móvil y libertad. Cada día los teléfonos son más multitarea: MP3, MP4, juegos, 3D, TV, Bluetooth, WAP, compras a través del teléfono, monedero, MMS, … ¡y también se puede hablar y enviar mensajitos de texto! Parece claro que todo este desarrollo no lo lleva a cabo únicamente el constructor del teléfono (Sony, Nokia, Motorola, …) parte ha de ser trabajo de terceros; desde el operador (Telefónica, Vodafone, Orange,…) hasta compañías mucho más pequeñas que desarrollarán software para modelos específicos ó para entornos operativos específicos.

En este momento cada operador dispone de su propio sistema operativo embebido y embarcado en cada teléfono. Cada modelo de terminal tiene sus propias características, hardware y procesador. Incluso en la misma familia de teléfonos existen diferencias. Esto nos lleva a la siguiente cuestión, ¿es económico/posible publicar software[1] independiente para un teléfono? Ahí el terreno se vuelve muy pantanoso.

En principio muchos de los fabricantes tratan de implementar una versión de la máquina virtual compatible con los estándares de Sun. De esta manera, un desarrollador independiente podría desarrollar soft en Java-móviles y luego publicarlo para descargas, ¿no? Pues sí, estamos de enhorabuena, porque efectivamente se puede desarrollar para teléfonos móviles. Sin embargo, si creíamos que se puede programar sin pasar por el aro, vamos daos.

En mi corta experiencia en móviles, estoy desarrollando un código que necesita tener acceso a Bluetooth y a cámara. El problema viene a la hora de acceder estos dos dispositivos. El modelo de seguridad que propone Sun entiende que es inseguro permitir que una aplicación Java conecte la cámara (o el Bluetooth, o se conecte a la web, o acceda a la agenda, … [2]) A causa de esto el usuario recibe dos inquietantes mensajes:

1. La aplicación no es segura desea instalarla –> esto turba mucho al usuario.
2. (cada vez que se quiere acceder a la cámara) Esta aplicación quiere abrir la cámara ¿qué te parece eso? –> esto incomoda mucho al usuario.

Como mínimo es incómodo para el usuario, ¿si? La única solución es firmar el instalador y eso significa contactar con Verisign o con Twateeeee o con quién tú quieras y pagar [3]. Como bien sabéis, Hasefroch lleva incorporando firmas a sus .exe desde hace algunos años. Así que te pones manos a la obra, primero la documentación, luego la blogosfera, luego la articulo-sfera, luego, … te encomiendas a los ángeles. Pero el teléfono sigue dándote el clásico: firma chunga, ¡pírate! Es descorazonador, es pesado, es frustrante.

Sin embargo continúas bregando y finalmente llegas a firmar un MIDlet válido. Casi parece cosa de magia, estás tocando el cielo con los dedos. Afortunadamente llega Sony-Ericsson para dar por el culo, ¿es que eres tú más listo que Sony que sabe lo que nos conviene?, lo dudo chico! Casi literalmente, thread tras thread de su foro de soporte a desarrolladores, Sony insiste: si quereis certificados válidos tendréis que pagar. ¡¡ WTF !! ¿soy un pequeño desarrollador y tengo que retratarme sólo para programar? ¡¡pero qué cojones!!

Este tipo de políticas me molestan, me ofenden, me hacen enfadar y permanecer fiel a mi viejo (pero minúsculo) teléfono ¿Para qué voy a actualizar mi máquina si no me dejan hacer nada con ella? En este punto no me queda mucho más que decir que ¡viva el IRC! ¡viva Jabber! y vivan las albóndigas de mi abuela! Pero que le den por saco a todo aquel que quiera levantar monopolios (sean portátiles o no)

[1] Entiéndase software como “software serio”, claro
[2] Es decir, las restricciones son, en muchos casos, razonables.
[3] Y a mi no me gusta pagar sólo por desarrollar, puestos a pagar, las ponemos sólo cuando toque.

The rebel filesystem

Posted in Developing, Herramientas on September 12th, 2005

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.

Miembros del equipos incendiarios

Posted in Coordinación on September 10th, 2005

Flame: Un paquete personal, abusivo que se dirige contra el autor de un mensaje de Usenet. Lamentablemente los flames son bastantes comunes y largos. La gente que se dedica a esta “actividad” es conocida como flamer y puede llegar a ser ignorada por toda la comunidad Internet. [Google]

¿Usenet? … náh, los tiempos han cambiado, Internet y sus costumbres toman las calles conforme los geeks van saliendo del armario de sus aficiones y se reunen, tanto en garitos como a través del hilo para comunicarse entre sí, ….

No es que yo sea un provocador ni me guste discutir, ni mucho menos, …. lamentablemente he tenido la desgracia de contemplar 3 tipos de flames:

1. De bar
2. De foro online
3. De lista de correo

Está claro que el tipo [2 y 3] no presentan novedad alguna, siempre surge el típico gilipollas que se hace llamar D.Vader; pero, ¿qué ocurre cuando el flamer se sienta a tu lado en el curro, en clase, … ó es tu hermano? Eso sí es un marronazo. Se supone que somos personas razonables y no nos dejamos llevar por el primer impulso, por Dios, usamos Linux, vestimos camisetas molonas y bebemos Mecca-Cola, ¿qué podría salir mal?

La primera clase tiene unas características únicas, suelen empezar mientras se bebe, generalmente sin medida y son verbales. Una gestión adecuada de estas dos circunstancias permite a los flambeadores excusarse de mil maneras: “no me entendiste bien”, “bebimos demasiado”, “no quería tirarte la cerveza a la cara, se me escapó”. Curiosamente es el único tipo de flame en el que la escalada de injundios puede resolverse en el campo del honor. También son los que pueden cerrarse con un apretón de manos ó una disculpa justo tras haber cometido el error de decir esa frase de más. El peor tipo de flamer de bar es el que se caga en tu madre y acto seguido se disculpa invitándote a un chupito infecto de algo que sabe que no te gusta. Está claro que no puedes majarlo justo después de su invitación, serías un bárbaro.

Son fáciles de encontrar, cualquier visita un viernes tarde al 24h en Zaragoza, acompañado de Púlsar garantiza como mínimo 1 ó 2 por noche.

Respecto al flame online queda muy poco que decir que no haya sido ya objeto de chanza, anécdota e historia. Voy a centrarme en un tipo específico de flame: el flame combinado. Partimos de un grupo de personas que deciden montar una lista de correo para coordinar sus actividades pero que viven en la misma ciudad, de este modo queda constancia documental de sus actos. Y es que somos unos chicos estupendos cuando nos lo proponemos.

Todos los miembros del equipo reciben los mensajes de la lista puntualmente y todos son felices. Hasta que algo ocurre: una discusión mortal. Y entonces a tomar por culo las buenas formas y los emails jocosos con links golfos a la lista. Nos ponemos todos la careta de soy-más-ingenioso-malévolo-y-borde-que-tú y a flambear se ha dicho. ¿Qué nos hace olvidar que los mensajes de texto permanecen en todos y cada uno de los discos de los miembros del equipo?

Me voy a aventurar y diré que este comportamiento está relacionado con el mismo que nos hace adoptar otras identidades en los IRCs: el anonimato. [Falso, como todos sabemos, pero lo importante es la percepción de anonimato no el anonimato como tal] Recibes un mensaje de alguien que conoces porque acabas de tomarte con él unas cañas. Y el email es “demasiado”, ¡clama al cielo! ¿Qué hacer? … lo lógico: abrir el mutt y enviarle el mayor flame que la humanidad haya visto jamás.

Y es que una vez pulsado el botón de enviar poco queda por hacer. Ya está montada. Me sigue fascinando esta actitud porque está claro que se volverá a ver al tipo: cara a cara. Y toda la violencia que la lista de correo evitaba estallará pero bien enveneada y aumentada por cada respuesta cruzada.

Ahora, unos amiguetes de Santiago están precisamente en esa situación. Conociendolos más bien poco me pregunto si esta escalada de provación / insulto se hubiera producido en una reunión en persona o no. Quiero creer que no.

¿Provoca el anonimato la sensación de que nuestros actos serán impunes? ¿Incluso cuando tenemos claro que el estamos lanzándonos pedradas sin vernos las caras pero sabiendo perfectamente quiénes somos?

the petabytes unchained

Posted in Developing, Herramientas on September 7th, 2005

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) …

SAN arquitectura
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.

Comparacion base NAS SAN

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.

Coraid, aspiracion

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:

  • Appliances con Debian, kernel montado manualmente
  • Network block devices/servidores para compartir el disco
  • Network block devices/cliente para aglutinar los puntos de montaje en un sitio coherente.
  • 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.

    Mentes nubladas 1

    Posted in IA on August 26th, 2005

    Volvamos al tema de la inteligencia artificial con un apunte de mi último currele:

    Comienzo a despegar un poquito con Maya y sus manías. En particular llevo unas semanas dándole a AI.Implant , un paquete de inteligencia artificial a modo de plug in.

    Evidentemente hay muchas diferencias entre un plugin y un auténtico stand alone como Massive (quién le echara mano) ó Behavior (que tampoco está mal y nos va a pagar el alquiler durante un par de meses ;) ) Pero se pueden aprovechar las limitaciones propias de un plugin y emplear el contenedor, Maya, como una plataforma de comunicación de componentes. Es decir, en behavior puedes emplear razonamiento por máquinas de estado jerárquicas, lo que es bastante potente, pero, ¿y si quieres emplear control difuso? ¿ó razonamiento dirigido por objetivos? Pues te toca jorobarte y buscarte la vida con algún montaje más o menos ingenioso. Sin embargo a través de Maya debería ser posible comunicar un motor de lógica difusa, FFLL por poner un ejemplo, con Implant, ya que están compartiendo toda la infraestructura Mayesca. Sin embargo, antes de volar, hay que andar.

    Para trabajar con lógica difusa, lo primero que haces es considerar que cualquier aserción no es taxativamente verdadera ó falsa, tiene un grado de verdad, un DOM (degree of membership) de entre [0..1], evidentemente esto se hace con una función que relaciona la(s) entrada(s) x,y,… con una salida DOM, la primera aproximación que he tenido es mediante funciones de respuesta, una idea que saqué del Ai Game programming wisdom (comentado por ahí abajo). Además me lo he progrado sobre el propio motor del Ai.Implant: inconvenientes: ¡todos los del mundo!

  • Los agentes no pueden almacenar de manera nativa las tablas de valores, la única estructura de datos compleja es el vector de 3 posiciones … :-P
  • No hay structs
  • Lenguaje procedural, baja encapsulación
  • Y podríamos seguir hasta el infinito. De todas maneras algo he logrado hacer.
    En este momento trato de integrar FFLL en la propia API del Maya compilándolo como si fuese una DLL. Otro rato más ….

    Nerds best friend in kitchen

    Posted in Herramientas on August 22nd, 2005

    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 …

    Kitchen debuggin tool

    La letra pequeña

    Posted in Bibliotecas, Developing on August 19th, 2005

    Este es uno de esos posts que animarán a los amantes del software libre más ultras. Una de las pegas que se les suele poner a los desarrollos libres es la falta de documentación seria. Pues parece ser que a los desarrolladores privados tampoco les hace gracia tener que escribir 100 páginas de manual, how-to ó lo que sea, …

    Llevo un par de semanas trabajando con un software de inteligencia artificial, out off the box. Concretamente AI Implant . No está mal. Se engancha con Maya ó bien con Max y tiene un funcionamiento limpio, al menos a partir de la versión 2.6 porque las anteriores se daban unas castañas que te giraban los ojos.

    Como todo buen plugin pesado, Implant tiene su propio motor script en las tripas. De este modo BioGraphictech logra vender la misma tecnología para dos programas tan diferentes como Maya y Max. Luego le añade una capa intermedia, más el interfaz de usuario (quién dijo que el multilayered design fuese nuevo?) Cuando despliegas el menú de controles básicos hay un montón de monerías que quieres probar, mallas de navegación, gestión de colisiones, etc.

    Pero claro, como en todo buen software pronto te quedas sólo ante el manual porque quieres hacer eso-que-nadie-pensó-antes. Ok, no hay problema, somos mayores y este es un software propietario, por el amor de Dios he pagado varios miles de dólares por él. Vas directo a la sección de “extender el SDK”, ¿resultado?

    Coming soon …

    ¿Qué? ¿Kouming zun? ¿Qué carajo significa esto? … En este momento me planteo levantar el teléfono y decirle a administración que lenpaguen a BioGraph soon, pero no ahora!

    ¿Será un accidente? Pasemos a la sección del manual que habla de motor propio de script, .. ¿ejemplos de programación en script?

    TO DO

    Ahí sí te crees morir. ¡¡ Pero si vi este mismo comentario en la documentación del Blender!! (notablemente más barato) … ¡ay de mi!

    Pero ya estás muy abajo en la documentación, has superado varios cientos de páginas de documentación automática de esas en las que te cuentan que el método value de un objeto sirve esencialmente para conseguir su valor XD y en ese momento se deslizan los ojos por la típica sección de “errors and workarounds“. Joder pues si hay un error reconocido y está en la documentación digo yo que habrá que solucionarlo, ¿no? Pues nopes, aquí te encuentras con lo que se considera ayuda al cliente, las tablas de trucos sucios que hay que hacerle al soft para que … haga lo que se supone ya hacía sin las ñapas y que es lo que has pagado a tocateja.

    Pero lo realmente triste es cuanto te descubres buscando la sección de, “errors and workarounds” justo después de haber adquirido un software para imprimir las dichosas paginitas y aprendértelas de memoria. Y es que ese parece ser el modo normal y razonable de funcionar con el soft privado.