El trabajo de Aitor Menta (I)

Tras un par de posts que deben haber dejado bien claro qué opina Aitor de la política, viene a ser la hora de revelar más datos personales acerca de este extraordinario personaje. Hoy les he venido a contar de qué trabaja Aitor. Porque Aitor trabaja y es mileurista, como toca a los universitarios de su generación. Por suerte, sólo trabaja cuatro horas al día. Bueno, por suerte no, porque se lo merece.

Aitor es informático, como toca a los universitarios de su generación. Aitor decidió ser informático en pleno auge de las dotcom. E inició la carrera en pleno estallido de las dotcom. Son cosas que pasan. Nos decían antes de entrar que nos harían ofertas de trabajo en tercero, en cuarto, pero que debíamos renunciar a ganar mucho dinero si queríamos obtener el título.

Pues ya ves.

Aitor es un informático que no sabe lo que es pehachepe, ni ayax ni puntonet. No tiene ni zorra de flash, java ni nada de eso. No sabe qué es debian. Y no es extraño. La mayor parte de estudiantes de informática no ven eso en sus carreras. Se estudia teoría de colas, conjuntos, gramáticas, estadística, clasificadores, arquitecturas y protocolos. Ningún estudiante de informática sabe arreglar ni formatear un ordenador, al menos no gracias a la carrera. Entre los estudiantes circula el lema: "Soy informático y NO voy a arreglar tu ordenador". Lo más probable es que no sepan cómo.

Así que Aitor no hace páginas web, ni instala linuxes ni arregla ordenadores, tareas todas ellas que creemos típicas de un informático. Su trabajo es mucho, MUCHO más guay que todo eso junto: Aitor jode ordenadores. Los pringaos arreglan ordendores. Sólo los espíritus libres los joden y les pagan por ello.

¿Qué se debe hacer para fastidiar un ordenador?. Bueno, primero, Aitor no trabaja con ordenadores al uso. Trabaja con SOCs, que viene a ser como tener un pequeño procesador con unos cuantos componentes, interficies de comunicación y memorias. Molan más porque puedes toquitearlo todo. Puestos a liarnos a martillazos, ni siquiera es necesario quitarle la carcasa.

He aquí una imagen para que se hagan ustedes a la idea.



Pero no es cuestión de liarse a martillazos, no. No por nada, sino porque el tipo de fallos que esto comporta no suele ser reproducible ni estudiable, aunque seguro que también hay gente que se dedica a golpear cosas hasta que se rompen. No es el caso, por desgracia. La idea es analizar los fallos que pueden producirse en un aparato de este tipo (hasta las tostadoras tendrán cosas similares dentro) y ver de qué manera podemos garantizar cierto funcionamiento en caso de fallo.

Y de eso va la cosa: de sistemas tolerantes a fallos. ¿Y qué es un fallo?. Pues venga, un poco de terminología.

Un fallo es lo que todos tenemos en mente: algo que no va bien. Un fallo en informática puede ser un bit que no es el que debería, un nivel de tensión que no es el adecuado, una división por cero. Podemos clasificar los fallos de un montón de maneras distintas: accidentales o intencionados, maliciosos o no. Temporales o permanentes, internos o externos... Los fallos pueden estar dormidos (como un error en una posición de memoria que no se usa) o activos.

Un error es la manifestación del fallo. Continuamente se producen fallos en nuestro sistema. Muchas veces estos son tratados antes de que se conviertan en errores. Otros ni siquiera son percibidos por éste. Llamamos a un error latente cuando no ha sido detectado. Lo llamamos detectado cuando... bueno, vale. Cuando un error afecta al comportamiento del sistema y al usuario del mismo lo llamamos avería. Una avería viene a ser una exclamación del tipo "esto no furula".

Averías también hay de muchas clases. Puede ser de valor, cuando obtenemos un resultado que no toca. O puede ser de tiempo, cuando obtenemos un resultado cuando no toca. En sistemas de tiempo real, por ejemplo, tan importante es lo uno como lo otro. Podemos tener una avería coherente (en esos casos es fácil imaginar qué ha ido mal). O podemos tener una avería bizantina. En las averías bizantinas a veces la cosas van bien y a veces no. Quizá una parte del sistema piense que funciona correctamente y la otra lo contrario. Las averías bizantinas son la mejor manera de volverse loco en poco tiempo.

Podemos tener averías benignas o desastrosas. Un informático te lo explicará así: en las benignas, las consecuencias que se producen son de un orden de magnitud igual al beneficio obtenido por el servicio entregado en ausencia de averías. ¿Guay, eh?. Podemos imaginar, en contraposición qué es una avería desastrosa. Las averías desastrosas entrañan muerte y destrucción en los peores casos.

Definimos criticidad de un sistema como la mayor gravedad de sus posibles modos de avería. Debemos intentar que los sistemas más críticos tengan modos seguros de a avería. Hay sistemas críticos que simplemente parándose lo consiguen. Hay otros, como aviones, que es mejor que no lo hagan si no desean planear sin control durante lo que le queda de viaje.

Y aquí viene lo que buscamos: se dice que un sistema es tolerante a fallos cuando es capaz de continuar su trabajo aunque se manifiesten errores permanentes, transitorios o intermitentes. Un sistema tiene un comportamiento seguro, si una vez que se produce una avería, y además no se puede continuar con el correcto funcionamiento, el sistema se detiene en un estado conocido que no causa ningún tipo de riesgo.

¿Cómo consiguen hacer estas cosas maravillosas los informáticos?. Pues de muchas y sofisticadísimas maneras. A veces poniendo a funcionar varios componentes que hacen lo mismo. Por ejemplo. A eso le llamamos redundancia de componentes. Si nos queremos dar el pegote podemos hablar de redundancia intrínseca, si no hemos hecho nada para conseguirla o redundancia extrínseca, si ha sido intencionada para tolerar fallos.

[A estas alturas ya debe haber quedado claro que informática no es una carrera difícil, pero hacemos como que sí hablando raro].

¿Y de qué manera se puede uno dedicar a fastidiar ordenadores, que era lo que quería contar?. Pues como esta entrada ya queda muy larga, le pondré una I al título y ya continuaré más adelante.

Hasta la vista.

La imagen corresponde a una placa de evaluación de Keil.