martes, enero 18, 2011

SONY PS3

http://crysol.org/es/node/1448

Interesantísimo artículo publicado en crysol


Si los ingenieros de tu empresa son unos inútiles: contrata buenos abogados
:: historia Mié, 2011-01-12 16:26 — int-0
Hola buenas, hoy voy a hablaros sobre un tema que vengo siguiendo desde hace tiempo relativo a la libertad de los usuarios sobre los cacharros que se compran. Por poner un nombre os hablaré de Sony y de la PS3.

Sony y su PS3
Todos aquellos que tengáis una PS3 (y la uséis) os habréis dado cuenta que se trata de un "cacharro" bastante jugoso y lleno de posibilidades. Cuando salió al mercado Sony estaba dispuesto a que la gente hiciera buen uso de él mediante una increíble "feature" llamada OtherOS. Además de esa "feature" se incluían otras como: compatibilidad con PS1 y compatibilidad con PS2 (primero por HW y posteriormente por SW). Pues bien... de repente en una actualización desaparece la compatibilidad con PS1 y PS2 (de aquellas consolas que lo hacían por SW). Se supone que las actualizaciones deben añadir funcionalidades o corregir errores. Desde luego no creo que emular el hardware de una PS2 sea un error.

La gente inquieta (que forman el 90% de la llamada scene) vivían alegres y felices con el OtherOS ya que permitía usar la consola con los propósitos originales de Sony además de poder hacer lo que tú quisieras con ella sin incurrir en la ilegalidad. No todo era color de rosa: desde OtherOS se vetaba el acceso a un SPU (uno de los procesadores del sistema) y desde luego nada de RSX (el chip gráfico y de sonido denominado "Sintetizador de Realidad"). Con esto se aseguraban que nadie fuera a sacar juegos para el OtherOS que compitiesen con los juegos "habituales" de PS3, es decir, los de empresas licenciadas que habrían pagado una pasta a Sony para que esto fuese así.

Y allí donde alguien pone una barrera alguien desea saltarla.

Apareció un individuo llamado Geohot (conocido por realizar el primer jailbreak de iPhone) que mediente un simple puente en la placa de la consola era capaz de acceder a toda la memoria de la consola, es decir, dentro y fuera del OtherOS. Imaginad que desde la máquina virtual de Java pudiérais acceder a direcciones de memoria del sistema real... Ese avance permitió acceder al RSX y por tanto a una futura implementación de OpenGL dentro del OtherOS que usase el RSX... esto resultó inadmisible para Sony que decidió cortar por lo sano: una actualización del firmware eliminaba la opción OtherOS de la consola. Una opción que aparecía en la misma publicidad de las consolas hasta el momento vendidas. A todas luces esto es ilegal (o al menos según la ley europea) y mucha gente fue la que intentó interponer demandas conjuntas contra Sony. Tal revuelo se formó que Sony decidió hacer frente a las críticas: "que los clientes presenten reclamaciones a los vendedores". Impresionante: evitan a los clientes y "enmarronan" a quien vende su producto...

Con la eliminación del OtherOS llegó la tormenta: demasiada gente muy curiosa ahora no podía usar la PS3 como ellos querían, de hecho como Sony había dicho en un principio que se podía usar. Así la gente comenzó a mirar "dentro" de la (hasta ese momento) "consola más segura del mercado". Y apareció el primer bug: una filtración de un manual de Sony revelaba que la consola, antes de arrancar, podía autenticarse con un dispositivo especial mediante el USB de forma que en el servicio técnico pudieran trabajar con ella, arreglarla, restaurarla, etc. En este proceso de autenticación Sony cometió un error en la reserva de memoria de los descriptores USB. Si el dispositivo que se enchufaba pedía tamaños extravagantes para alojar descriptores de dispositivo, el driver símplemente lo hacía. Mediante un ataque de heap overflow se consiguió inyectar código en la consola antes de que arrancase el GameOS. Las primeras copias de seguridad de juegos podían empezar a usarse después de varios años de vida de la consola. Nunca antes se había tardado tanto en "piratear" una consola, el motivo símplemente era que los "curiosos" podían usar la consola para sus propósitos sin necesidad de "cacharrear" nada.

Aquí el "castigo" de Sony también fue ejemplar: la siguiente actualización de firmware corregía el bug en el driver de USB, además (y de regalo) impedía usar ningún dispositivo USB que no fuera oficial: ni mandos para la consola no oficiales, ni adaptadores de mandos de PS2 a PS3, ni adaptadores de memory card de PS2 a PS3... nada. Si esto no es una acción monopolística, ¿entonces qué es?.

Hasta ahora empezaba el clásico juego de sceners encuentran bugs, empresa publica firmware que corrige bugs. Ya era posible arrancar copias de seguridad pero resultaba un engorro, los juegos nuevos eran más difíciles (o imposibles) de arrancar y era imposible usar la conexión a internet o los servicios del PSN. Pero había un problema: usar GNU/Linux seguía siendo imposible y la alternativa AsbestOS (aplicación casera) resultaba engorrosa de usar. Entonces llegó el 27C3 y su sección Console Hacking 2010 titulada: "Sony PS3: Epic Fail".

Los autores de AsbestOS no estaban dispuestos a renunciar al OtherOS así que se fijaron como objetivo crear el suyo propio. Para ello se pusieron a investigar sobre los últimos bugs de la consola y descubrieron alguno nuevo. En el congreso dieron una animada y divertida charla donde presentaron su trabajo. Fue tal la expectación que resultaba casi imposible conectar a los servidores dedicados del congreso. Al final de la charla revelaron el "Epic Fail" de Sony que explico a continuación:

Imaginemos que disponemos de un sistema de autenticación basado en clave asimétrica. Dentro de la consola, en algún lugar, se encuentra la clave pública. Los programas que se cargan en la consola se cifran mediante una clave privada en las oficinas de Sony. Ambas claves, la privada y la pública, se generaron a partir de una clave maestra. Para mantener la clave maestra a salvo (esta clave se encuentra en las oficinas de Sony bajo máxima seguridad) se generan los pares de claves mediante una función de ofuscación y un número cualquiera. De esta manera, por muchas claves que conozcamos nos será imposible (o computacionalmente imposible) calcular la clave maestra. Y aquí está el problema: los ingenieros de Sony utilizaron SIEMPRE el mismo número aleatorio en lugar de calcular uno cada vez. Si eliminamos la aleatoriedad de la función de ofuscación la convertimos ahora en una constante y por tanto fácilmente computable. Buscando dentro del firmware de la consola las claves públicas podremos recolectar las suficientes como para poder calcular las claves privadas y finalmente la maestra.

Bueno, las consecuencias de esto no se hicieron esperar: se publicó en Google Docs una hoja de cálculo con todas las claves públicas y privadas del sistema, así como la clave maestra. El equipo de AsbestOS sólo se ocupó de la parte necesaria para crear un paquete con firma oficial que permita volver a cargar Linux en la consola (está actualmente en desarrollo) pero abrió la puerta a todos aquellos que deseaban "customizar" el firmware de la consola. Ahora cualquiera podría crear firmwares o paquetes para GameOS con firma oficial. De hecho existen herramientas caseras para hacer esto.

Si os preguntáis qué puede hacer Sony para evitar esto la respuesta es fácil: desde el punto de vista técnico nada, porque si publicasen un firmware con una nueva clave maestra todo el software publicado hasta el momento dejaría de funcionar y si tiene una clave nueva pero se permite la antigua seguiríamos igual. Así que Sony ha decidido ponerse las pilas y ha movido baza: pretende llevar a juicio a todas las personas que han intervenido de alguna forma en el desarrollo de la scene de PS3. La lista de denuncias contra los "hackers" es increíble, incluso acusan de extorsión.

Ahora mi opinión: un error tan grave en el sistema va a intentar ser corregido en los tribunales. Los mismos tribunales que han permitido a Sony eliminar features de su consola. Y es que Sony hace muy buenos productos, pero los gestiona muy mal debido a su grandísimo afán recaudatorio. Intenta exprimir al máximo a todos sus usuarios llegando incluso a emplear técnicas ilegales para ello (¿no recordáis ya el rootkit de Sony Music?). Así que Sony, va siendo hora de que aprendas que la gente compra las cosas para usarlas como más les guste y que a nadie le gusta que le fuercen a nada y menos pagando por ello. La piratería de vuestra consola la creásteis vosotros al piratearnos a nosotros el OtherOS. Pero no aprenderán...

Si os preguntáis qué les va a pasar a los "hackers", bueno, GeoHot no violó ningún término de uso puesto que su aplicación para extraer las claves corría dentro del OtherOS. Por otro lado, Marcan, principal investigador dentro de AsbestOS (grupo Overfl0w) es español y aquí la ley le ampara a él puesto que nunca aceptaron donaciones y su trabajo únicamente sirve para correr Linux dentro de la consola.

Si aún no os habéis aburrido con todo este rollo, aquí van algunos enlaces interesantes:

Charla Console Hacking del Caos Congress 2010: http://events.ccc.de/congress/2010/Fahrplan/events/4087.en.html
Sony toma acciones legales contra sceners: http://www.ps3news.com/PS3-Hacks/sony-takes-legal-action-against-infamou...

Respuesta a Javier Bardem

Hay explicaciones clásicas muy buenas como la de compartir una manzana.

"Si comprato una manzana contigo, como media manzana. Pero si compato una idea contigo, tu y yo tenemos una idea, no dos medias ideas"

Esta respuesta a un comentario tonto de Javier Bardem es otra reflexión muy bien planteada


http://www.meneame.net/c/7526472



Javier Bardem: Dejémonos de estupideces, ¡es robar!
#63 Pongamos el mismo ejemplo.

Javier Bardem quiere «comprar un tomate fresco». Para usar el paralelismo con la industria cultural, Javier debería acudir a una tienda en la que tras pasar por sucesivas manos, el tomate ha incrementado su valor de manera artificial, repercutiendo en el horticultor en menos del 0,1 % de su valor de venta. Son otros, los intermediarios, los que han cobrado más, en muchos casos tan solo por cambiar la pegatina que viene puesta en el tomate. Algo que, por desgracia, no dista mucho de la realidad del mercado de la agricultura --y de la pesca, y de la ganadería...--.

Pero ahora viene la gracia. Javier Bardem no puede compartir ese tomate que acaba de comprar con nadie más, pues de lo contrario la Sociedad General de Agricultores y Especuladores se cabreará con él y lo llamará ladrón: «¡Quien quiera un tomate que se lo compre! ¿Qué es eso de compartir?».

Tampoco puede alterarlo en cualquier forma que no haya sido expresamente autorizada por el horticultor. De hecho, su intención de usarlo para hacer gazpacho se considera un uso no autorizado, y la Sociedad General de Agricultores y Especuladores la condena, llegando a denunciar al comprador si se hace pública la manipulación no autorizada: «El gazpacho, como resultado de la manipulación del tomate entre otros productos, es algo que sólo nosotros, como creadores del tomate original podemos realizar, ya que ese derecho es nuestro. Cualquier manipulación realizada por terceros sin nuestra autorización es una violación de nuestros derechos, y debe ser castigada».

Para colmo, Javier Bardem tampoco puede comerciar con el tomate que acaba de comprar. Si fuera el caso de que tuviera un restaurante donde sirviera ensaladas de tomate --plato que debería contar con la autorización de la Sociedad General de Agricultores y Especuladores--, debería pagar otra vez al horticultor por el lucro cesante que le supone que los clientes de su restaurante vayan a comer un tomate allí, en lugar de comprar otro para ellos. Incluso si el horticultor acuerda no cobrar por este uso, la Sociedad General de Agricultores y Especuladores le cobrará una compensación por tal uso no autorizado.

Por si esto fuera poco, al día siguiente Javier Bardem descubre que tiene que seguir pagando por el tomate que compró ayer, pues los derechos que reconocen el esfuerzo del horticulor estipulan que hay que pagarle por este trabajo hasta más allá de su muerte. Al fin y al cabo él trabajó para producir ese tomate, él plantó la semilla, y día tras día cuidó del crecimiento de la planta, alimentándola cuando lo necesitaba, protegiéndola cuando se debía, hasta el momento de poder recoger su fruto: el tomate. Y ese trabajo debe ser recompensado toda la vida, porque al fin y al cabo, una vez que Javier Bardem ha consumido ese tomate, su organismo se ha beneficiado de él, y ese beneficio para Javier Bardem puede durar años.

Por supuesto este pago Javier Bardem no lo tiene que realizar directamente. No es un impuesto, sino un cobro de derechos, en lo que todo aquello que esté relacionado con el tomate que compró ayer incluirá el pago al horticultor.

De hecho, para proteger el trabajo del horticultor, se ha prohibido que cualquiera pueda producir tomates iguales o razonablemente parecidos a los que compró al horticultor. Por eso no se venden semillas de tomates de ese tipo. Y como aun así es posible que Javier Bardem las obtenga del propio tomate, para reducir el perjuicio ocasionado al horticultor, la Sociedad General de Agricultores y Especuladores ha logrado que se apruebe la inclusión de un canon compensatorio en todos aquellos productos que pudieran facilitar que cualquiera produjera tomates similares a título privado. Este canon se puede encontrar en el abono, el agua, las mangueras, las regaderas, los maceteros, los tiestos, los sistemas de aspersión, las palas, los rastrillos, las carretillas, las azadas y en general cualquier herramienta de agricultura y jardinería, los plásticos y estructuras de posible uso para la construcción de invernaderos, etc.

Por suerte para Javier Barden hay un grupo de personas que consideran que esta situación es un abuso, y han creado sus propias huertas, donde venden los tomates sin todas las restricciones que se han citado, permitiendo su uso y consumo como mejor le parezca al comprador, y destinando prácticamente todo el dinero cobrado al propio horticultor.

Otras personas han creado huertas públicas, donde el cuidado y el mantenimiento de los productos de la huerta es responsabilidad solidaria de todos, y todos pueden disfrutar libremente de los resultados.

En algunos casos las tomateras son el producto de las semillas de los tomates obtenidos a través de la compra a los horticultores tradicionales, y eso ha cabreado a la Sociedad General de Agricultores y Especuladores, porque dicen que eso es piratería, que se están aprovechando del trabajo de sus horticultores, e incluso están en algunos casos obteniendo beneficios por ello.

Así, la Sociedad General de Agricultores Y Especuladores, junto con otros colectivos afectados como Proagripescae, han denunciado en varias ocasiones a los que mantienen dichas huertas. En algunos casos incluso han tratado de crear la idea de que su actividad es más delictiva si cabe porque cobran por otros servicios a quienes acceden a sus huertos a por los productos que allí se disponen gratuitamente.

Por fortuna los jueces, que aun tienen algo de sentido común, siempre han sentenciado a favor de las personas encargadas de las huertas. Esto ha molestado a las sociedades mencionadas, que han movilizado a los horticultores para que protesten y presionen con el objetivo de aprobar una ley que permita cerrar esas huertas sin necesidad de que lo ordene un juez.

¿Qué piensa Javier Bardem de que un colectivo que es parte del conflicto pueda decidir si cierra o no una huerta pública sin requerir la acción de un juez?

lunes, enero 17, 2011

crear herramientas de programación

El balace de las herramientas que me he estado preparando o estudiando
en estas últimas semanas para programar, es buenísimo y creo que con
el tiempo se percibirá aún mejor.


He estado programando al mismo tiempo en c++, python, generando
gramáticas para mis dos lenguajes y defininiendo con los mismos.


Las herramientas están maduras. Aunque el generador de mensajes y el
warper del sistema de comunicaciones no están acabados, todo está lo
suficientemente avanzado como para demostrar que son piezas muy
útiles.

Y eso me lo he demostrado haciendo programas de verdad.


La situación es clara y sencilla, pero hacerlo y conseguir un punto de
maduración de las herramientas adecuado, es duro.

1.- La productividad al escribir código es importante
2.- Es aún más importante el poder mantener y ampliar el código


¿Cómo conseguir estos dos puntos? también es fácil saberlo.


1. Reutilización de código.
2. Hay que separar el qué se quiere hacer del cómo.
3. Sistemas separados en piezas definiendo qué hace cada pieza, su
entrada, su salida y su diagrama de estados.
4. Las piezas se conectan con un middleware.
5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos
(lo que aporta también un paralelismo potencial y por tanto una
escalalibidad enorme).
6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.
7. Tratar de separar lo mínimo la documentación y el código.



Las herramientas y lenguajes de programación no ayudan mucho en ningún punto.


1. Reutilización de código.

Es lo que todos los lenguajes pretenden y dicen conseguir.
Pero sólo se consigue en lenguajes de tipado dinámico.
En los lenguajes de tipado estático, se consigue poco o son técnicas
complejas que no se suelen dominar ni utilizar.
Exceptuando contadísimos casos, tratar de hacer código realmente
reutilizable es muy costoso en rendimiento y complejo de escribir.


2. Hay que separar el qué se quiere hacer del cómo.

Si eres MUY metódico y MUY organizado, puedes intentarlo con los
lenguajes habituales (C++, C, Java, C#, VisualBasic, etc...)
Los lenguajes imperativos se centran en el cómo y el fracaso en la
separación dle qué y el cómo es casi seguro.
Para esto es mucho mejor utilizar lenguajes declarativos.
Si es así, ¿porqué los lenguajes declarativos están infinitamente
menos extendidos?
No es del todo cierto. Entre programadores de categoría, los lenguajes
declarativos son muy utilizados en tareas complejas.
Pero los programadores de bajo nivel, que somos una enorme mayoría
(más de 95%) sólo sabemos trabajar con lenguajes imperativos.



3. Sistemas separados en piezas definiendo qué hace cada pieza, su
entrada, su salida y su diagrama de estados.

Aquí no hay ninguna ayuda.


4. Las piezas se conectan con un middleware.

Hay unos cuantos middlewares, hay que aprender y utilizarlos.
Los lenguajes de propósito general, se pueden conectar a un middleware
o a crear ventanas, o a conectar con una base de datos...
Lo malo es que no son buenos haciendo ninguna de esas cosas



5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos
(lo que aporta también un paralelismo potencial y por tanto una
escalalibidad enorme).

Las hebras y el paralelismo dentro de un proceso son una trampa
mortal. No utilizar salvo situaciones muy específicas y justificadas.
Sólo algunos lenguajes declarativos tienen una buena solución para este punto.
El lenguaje de referencia en este punto es Erlang



6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.

Los lenguajes de propósito general, también son un enemigo de este punto.
Los programadores de bajo nivel, símplemente nos acostumbramos a que
las cosas son así y nos cuesta imaginar que hay otras soluciones
infinitamente mejores.


7. Tratar de separar lo mínimo la documentación y el código.

Si separamos el qué del cómo y tenemos una buena sintáxis (sencilla y
clara), conseguido.
Inconvenientes, la separación en lenguajes imperativos es casi imposible.
La sintáxis clara para un problema específico utilizando un lenguaje
de propósito general... complicado



Lo que he preparado (en un estado muy avanzado y probado con un caso
real no trivial) ayuda muchísimo (si no da una solución decente) en
todos estos puntos.

¿Cómo?

Para empezar con un par de lenguajes específicos del problema a resolver.


Uno es la gestión del estado de la aplicación. BASTA YA DE HACERLO
MANUALMENTE y lo que es peor, improvisar una solución fácil de
escribir pero imposible de leer cada día.

Otro lenguaje para conectar nuestro lenguaje de propósito general, en
este caso C++ con la entrada y salida y por tanto, con el middleware.


En estos lenguajes, sólo se dice el qué y de forma muy concisa. No son
sólo código que se "compilará" para generar un programa, son
documentación.



Estoy contento porque el objetivo era ambicioso y complejo (montar y
probar un sistema así no era nada fácil para mi) pero he pasado el
punto de inflexión crítico.
De haberme quedado un poco más atrás, todo el trabajo podría haber
quedado en un gran esfuerzo pero una idea no utilizable

domingo, enero 16, 2011

Mis 10 comandos más utilizados

ejecutando la siguiente línea en la consola...

history | awk ‘{print $2}’ | sort | uniq -c | sort -rn | head -10

Te sale la lista de comandos que más utilizas


Mi resultado en el SO en el que desarrollo es...

178 ls
176 cd
136 make
59 git
52 rm
35 bg
33 valgrind
25 find
24 ./qpid-config
24 kcachegrind


Nada raro ni especial.


ls ver el contenido de directorios
cd cambiar de directorio
make compilar
git el gestor de versiones que utilizo
rm borrar
bg, mandar a segundo plano
valgrind máquina virtual para verificación de programas y rendimiento
find buscar algo, aunque en realidad lo utilizo combinado con xargs
para ejecutar un comando en varios ficheros
qpid-config, es una herramienta de configuración del middleware con el
que estoy trabajando
kcachgrind una herramienta visual para ver algunos de los brutales
informes generados por valgrind (temas de rendimiento, que empecé a
mirar hacer 3 días)


¿Y a ti que te sale?

miércoles, enero 12, 2011

Herramientas de programación

El balace de las herramientas que me he estado preparando o estudiando
en estas últimas semanas para programar, es buenísimo y creo que con
el tiempo se percibirá aún mejor.


He estado programando al mismo tiempo en c++, python, generando
gramáticas para mis dos lenguajes y defininiendo con los mismos.


Las herramientas están maduras. Aunque el generador de mensajes y el
warper del sistema de comunicaciones no están acabados, todo está lo
suficientemente avanzado como para demostrar que son piezas muy
útiles.

Y eso me lo he demostrado haciendo programas de verdad.


La situación es clara y sencilla, pero hacerlo y conseguir un punto de
maduración de las herramientas adecuado, es duro.

1.- La productividad al escribir código es importante
2.- Es aún más importante el poder mantener y ampliar el código


¿Cómo conseguir estos dos puntos? también es fácil saberlo.


1. Reutilización de código.
2. Hay que separar el qué se quiere hacer del cómo.
3. Sistemas separados en piezas definiendo qué hace cada pieza, su
entrada, su salida y su diagrama de estados.
4. Las piezas se conectan con un middleware.
5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos
(lo que aporta también un paralelismo potencial y por tanto una
escalalibidad enorme).
6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.
7. Tratar de separar lo mínimo la documentación y el código.



Las herramientas y lenguajes de programación no ayudan mucho en ningún punto.


1. Reutilización de código.

Es lo que todos los lenguajes pretenden y dicen conseguir.
Pero sólo se consigue en lenguajes de tipado dinámico.
En los lenguajes de tipado estático, se consigue poco o son técnicas
complejas que no se suelen dominar ni utilizar.
Exceptuando contadísimos casos, tratar de hacer código realmente
reutilizable es muy costoso en rendimiento y complejo de escribir.


2. Hay que separar el qué se quiere hacer del cómo.

Si eres MUY metódico y MUY organizado, puedes intentarlo con los
lenguajes habituales (C++, C, Java, C#, VisualBasic, etc...)
Los lenguajes imperativos se centran en el cómo y el fracaso en la
separación dle qué y el cómo es casi seguro.
Para esto es mucho mejor utilizar lenguajes declarativos.
Si es así, ¿porqué los lenguajes declarativos están infinitamente
menos extendidos?
No es del todo cierto. Entre programadores de categoría, los lenguajes
declarativos son muy utilizados en tareas complejas.
Pero los programadores de bajo nivel, que somos una enorme mayoría
(más de 95%) sólo sabemos trabajar con lenguajes imperativos.



3. Sistemas separados en piezas definiendo qué hace cada pieza, su
entrada, su salida y su diagrama de estados.

Aquí no hay ninguna ayuda.


4. Las piezas se conectan con un middleware.

Hay unos cuantos middlewares, hay que aprender y utilizarlos.
Los lenguajes de propósito general, se pueden conectar a un middleware
o a crear ventanas, o a conectar con una base de datos...
Lo malo es que no son buenos haciendo ninguna de esas cosas



5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos
(lo que aporta también un paralelismo potencial y por tanto una
escalalibidad enorme).

Las hebras y el paralelismo dentro de un proceso son una trampa
mortal. No utilizar salvo situaciones muy específicas y justificadas.
Sólo algunos lenguajes declarativos tienen una buena solución para este punto.
El lenguaje de referencia en este punto es Erlang



6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.

Los lenguajes de propósito general, también son un enemigo de este punto.
Los programadores de bajo nivel, símplemente nos acostumbramos a que
las cosas son así y nos cuesta imaginar que hay otras soluciones
infinitamente mejores.


7. Tratar de separar lo mínimo la documentación y el código.

Si separamos el qué del cómo y tenemos una buena sintáxis (sencilla y
clara), conseguido.
Inconvenientes, la separación en lenguajes imperativos es casi imposible.
La sintáxis clara para un problema específico utilizando un lenguaje
de propósito general... complicado



Lo que he preparado (en un estado muy avanzado y probado con un caso
real no trivial) ayuda muchísimo (si no da una solución decente) en
todos estos puntos.

¿Cómo?

Para empezar con un par de lenguajes específicos del problema a resolver.


Uno es la gestión del estado de la aplicación. BASTA YA DE HACERLO
MANUALMENTE y lo que es peor, improvisar una solución fácil de
escribir pero imposible de leer cada día.

Otro lenguaje para conectar nuestro lenguaje de propósito general, en
este caso C++ con la entrada y salida y por tanto, con el middleware.


En estos lenguajes, sólo se dice el qué y de forma muy concisa. No son
sólo código que se "compilará" para generar un programa, son
documentación.



Estoy contento porque el objetivo era ambicioso y complejo (montar y
probar un sistema así no era nada fácil para mi) pero he pasado el
punto de inflexión crítico.
De haberme quedado un poco más atrás, todo el trabajo podría haber
quedado en un gran esfuerzo pero una idea no utilizable


Además he unido esto a la utilización de un middleware nuevo para mi
(y para todos) llamado qpid y basado en la especificación abierta AMQP.

Y también a la creación de interfaces visuales con Qt, que tampoco tengo
mucha experiencia.