Un software que se repara a si mismo

#1   people.csail.mit.edu/rinard/techreport/MIT-CSAIL-TR-950.pdf

#2   Me ha recordado a "El hacker y las hormigas Versión 2.0"

#3   Es realmente increíble lo que puede hacer ClearView. Software que controla a otros software para que no falle. Parece sacado de una película de ciencia ficción.

De momento, no le veo mucha utilidad para poner a ClearView en producción. Intuyo que consume muchos recursos del sistema, ya que debe analizar los resultados que ejecuta y compararlos con otras ejecuciones para detectar si hay algo extraño. Otro problema que veo es que el sistema puede detectar un error y parchearlo haciendo el sistema más resistente a ataques; pero si el error no es producido por un ataque sino por un mal diseño, podemos obtener una respuesta erronea. Por ejemplo, tienes un sistema que hace varias operaciones, por un mal diseño, divides por cero. Esto genera una excepción y termina la ejecución del programa. Se parchea el error saltándote la división por cero y se sigue con el resto de las operaciones. no se ha solucionado la raíz del problema y el resultado obtenido es un resultado erroneo.

#4   Esto ya si que me deja sin trabajo definitivamente

#5   El día que un virus se repare a si mismo nos vamos a joder pero bien. Bueno, qué cojones, a los admins de sistemas nos viene al pelo.

#6   imageeknation.blogspot.com/2009/03/inteligencia-artificial.html

#10   Mientras no lo llame Skynet...

#11   #6

#12   #7, #10 trabajo presentado este mes durante el ACM Symposium on Operating Systems Principles, en Big Sky, Montana

#13   Me recuerda al comic "Ronin".

#14   ¿Y de los bugs del ClearView este quien se encarga? Por que lo mismo el tio se empeña en que todos los demas programas tienen un error y se los carga a todos. ¿Hay que poner un Clearview para vigilar los bugs del ClearView?

#15   Y qué hará cuando se diagnostique lupus?

#16   “crear un programa inmortal e invulnerable.”

¿Que podría salir mal? ^_^

#17   Aceite de serpiente aplicado a la informática.

Un programa funciona correctamente cuando responde a su especificación formal.

Teniendo en cuenta que la mayoría de los programas no se especifican formalmente, bien por imposibilidad (enorme complejidad) bien porque no merece la pena invertir el esfuerzo, no hay forma de saber si un programa funciona como debe o no. Por tanto no tienes forma de saber si debes arreglar algo o no.

En cómo arreglarlo ya ni entro, porque si difícil es lo primero lo segundo es ciencia ficción.

#18   muy bien por el avance tecnologico, tenia que inventar un chip, para los politicos cuando quieran hacer un fraude un chispazo de 20.000 amperios

#19   #3 De momento, no le veo mucha utilidad para poner a ClearView en producción.
Hombre, se supone que cuando has puesto un programa en producción es porque ya no tiene errores... ¿lo pilláis, lo pilláis?

#20   #7 la ostia, había entrado para poner tu comentario palabra por palabra...

#21   ¡La máquina de Touring que hace prácticas! Uno de mis sueños húmedos cuando era estudiante...

#22   Deberemos buscar un elegido para conbatir al agente Smith.

#23   ARQ: Tu vida es la suma del remanente de una ecuación desequilibrada inherente a la programación de matrix. Eres la eventualidad de una anomalía, que a pesar de mis más sinceros esfuerzos me ha sido imposible eliminar, de lo que de otra manera sería una armonía... de precisión matemática. Aunque sigue siendo una carga asiduamente evitada, no es inesperada ni está más allá de ser controlada. Lo cual te trajo inexorablemente... aquí.

#24   ¿Esto significa que los videojuegos se vana quitar los cracks solitos?

Dejando chorradas a parte, no esta mal, aunque no se yo si me gustaria que se dedique a parchearme cosas porque si... Peferiria que simplemente guarde un checksum del binario (supongo que hara algo por el estilo) y si ve que tiene un comportamiento extraño lo compruebe y me diga si se ha modificado... Bueno y si busca el error no estaria mal, pero no que lo parchee por su cuenta pudiendo hacer cosas que no interesan al usuario.

#25   El software creado por el ser humano, ergo la máquina, y salvo error técnico de la propia máquina hará lo que el ser humano especificó/tecleó/definió, luego si el ser humano quería hacer un programa de sumas pero al teclearlo hizo uno de restas, ya puedo hacer maravillas el programa que restará todo lo que quiera y como en esta ciencia (sí, informática) hacer un documento previo es pérdida de tiempo, este programa, salvo que además de analizar el código analice la especificación (oh wait, que no se hace en el 90%) de lo que debería hacer el código, no servirá para nada. Y si es capaz de analizar la especificación, entonces que no arregle nada si no que programe desde 0 esa especificación, y entonces se cargue al ser humano porque ya no servirá de nada... bueno sí, ese ser humano es el que decide que programa necesita o quiere hacer.

#26   #25 ¿has leido el articulo? no pretenden arreglar bugs de los programas, lo que buscan es defender el programa ante ataques externos que lo hagan funcionar de forma diferente a como lo hacia antes...

La idea es bien sencilla (la practica ya no...) el programa se dedica a monitorizar el comportamiento del resto de programas y si en algun momento uno de ellos se comporta de forma extraña investiga el por que de este comportamiento y si puede lo soluciona.

Algunos parece ser que habeis entendido que el programa se dedica a arreglar los bugs cometidos por los desarrolladores... para eso va a ser que seguiremos necesitando el debugger y paciencia.

#28   #7 Tomara conciencia de si mismo el 21 de diciembre de el 2012.

#29   #23 Citando el artículo, no se ve mucha diferencia con el arquitecto de matrix:

"ClearView detecta la anomalía e identifica las reglas que han sido violadas. Después crea una serie de parches potenciales diseñados para obligar al software a seguir las reglas que han sido violadas. (Los parches se aplican directamente a la binaria, pasando por encima del código fuente.) ClearView analiza estas posibilidades para decidir cuáles son las que tienen más probabilidades de funcionar, después instala las mejores candidatas y pone a prueba su efectividad. Si se violan más reglas, o si un parche hace que el sistema se cuelgue, ClearView lo rechaza y prueba con otro distinto."

Tienes mi positivo

#30   ha este paso nos dejan sin curro a los programadores

#31   #9 Reglas de la robótica:

1. Un robot no debe dañar a un ser humano o, por su inacción, dejar que un ser humano sufra daño.
2. Un robot debe obedecer las órdenes que le son dadas por un ser humano, excepto si estas órdenes entran en conflicto con la Primera Ley.
3. Un robot debe proteger su propia existencia, hasta donde esta protección no entre en conflicto con la Primera o la Segunda Ley.

es.wikipedia.org/wiki/Tres_leyes_de_la_rob%C3%B3tica

Esto no es robótica, es ingeniería de software

#32   Eso ya existe. Se llama Ubuntu.
Se repara a si mismo vía APT.
Todavía necesita utilizar a esclavos humanos, pero está trabajando en aniquilar ese problema.

#33   #9 Y sinó que se lo digan a Rajoy con el "señor" Costa

#34   #30 no te preocupes aqui estamos por las meteduras de pata que pueda hacer este sistema, que por bueno que sea seguro que tiene fallos (made by Humans).

#35   #31 Isaac? Eres tú?
Por favor, dime que tu muerte fué un bulo

#36   Matrix esta cerca

#37   #17: Se me ocurre, a bote pronto, usar lo siguiente que sé que se hace (porque he trabajado en un proyecto que lo hace): generación dinámica de invariantes.

Cuando un programa está ejecutándose mucho tiempo, otro programa puede obtener el estado de ciertas variables y registros en algunos puntos de la ejecución (principio y final de función, fácilmente identificables por las instrucciones call o ret, por ejemplo). Cuando tienes una cantidad considerable de datos de esos puntos, un motor de inferencia puede generar invariantes para esos puntos (verbigracia, Daikon).

Suponiendo que durante un periodo prolongado de uso todo será como se espera que sea, tendrás una ristra de invariantes asociados a puntos del programa. A partir de ahí, es sencillo ver cuando algo se ha salido de madre: en el momento que el estado de salida o entrada no respeta las pre/postcondiciones inferidas, algo ha salido mal.

Partiendo de esos invariantes observados, y de los datos que ha provocado el fallo, supongo que será capaz de encontrar el punto donde algo "se ha roto", y aplicar un parche genérico (comprobación de la longitud de un buffer, p.ej)

#38   #35 Tendría su gracia que Isaac citara sus leyes... en la Wikipedia.

PD: Aunque bueno, bien pensando es lo más parecido a la labor de los enciclopedistas por el momento así que por qué no.

#39   Esto es lo de siempre... ¿y quien vigila a la policía?

#40   Los virus ya hacen algo parecido. Por mucho que intentes desinfestar el ordenata, al final acabas formateando, es como si supieran las acciones que vas ha hacer, y actuen en consecuencia.

#41   #38 Ahhhh!!! Siempre es un placer encontrarse con un ciudadano de Términus

#43   skynet, anyone?