Cada vez que un ataque informático es publicado, que algún sistema en nuestra oficina actúa de forma extraña o que una actualización llega a nuestros teléfonos escuchamos el término “bug”: el atacante pudo tomar control del sistema gracias a un bug en una aplicación utilizada en la compañía; el bug que hacía que nuestra computadora nos mostrara una pantalla azul; o esas fotos filtradas que fueron resultado de un bug que permitía un ataque de fuerza bruta… pero ¿qué es un bug? Vamos a comenzar con un ejemplo, uno de estos “bugs” que existió en el mundo de Exchange Server (el servidor de correo electrónico de Microsoft) hace varios años, y que era más o menos así:

Un empleado de alguna compañía planeaba tomar unas vacaciones, y responsablemente definía en su sistema Outlook una respuesta automática para avisar a cualquier persona que le enviara un correo que él, o ella, no estaría en la oficina, algo así como:

“¡Hola! Gracias por tu correo, estoy de vacaciones de tal fecha a tal fecha, sin acceso a correo electrónico, teléfono de oficina, celular, fax, IM, SMS o ninguna otra manifestación del campo electromagnético, cualquier cosa por favor molesten a mi jefe o a mi asistente, sus datos son: emaildeljefe@ejemplo.com, etc.,”, el empleado dejaba esto programado, se iba de viaje, pero un momento antes de subirse al avión se conectaba a Internet por última vez para enviar un correo importante al Dr. Jack Shephard, un contacto suyo de otra empresa. El correo salía de su dirección y llegaba al buzón del Dr. Shephard, que en ese momento tampoco estaba disponible ¿dónde estaría? Pero que también había dejado programado Outlook para enviar una notificación de ausencia automática. El servidor del Dr. recibía este email y lo contestaba explicando que el Dr. estaba fuera de la oficina sin acceso a email y etc., el destinatario original recibía este correo automatizado del Dr., y lo contestaba con su mensaje automático, el servidor del Dr. recibía este segundo mensaje y lo volvía a contestar, -hola, gracias por tu correo, estoy de vacaciones…

Y el primer servidor contestaba: – hola, gracias por tu correo, estoy de vacaciones…

Y el segundo: – hola, gracias por tu correo, estoy de vacaciones…

Y el primero – hola, gracias por tu correo estoy de vacaciones…

y seguían así hasta que uno de los dos moría, es decir, se quedaba sin espacio de almacenamiento o reventaba su base de datos y toda la empresa se quedaba sin correo. Y el tipo de sistemas, que probablemente ese domingo en la noche estaba en su casa viendo “Lost” tenía que ir a la oficina y pasar las siguientes 36 horas rehaciendo volúmenes y rescatando “inboxes”

Se escucha divertido, sucedió, y definitivamente es una historia un poco embarazosa para Microsoft, no es el tema de este blog y no hay empresa “libre de pecado”, pero ¿existe alguna manera de crear un mundo “bug-free”?

Un bug yo lo entiendo como una interacción no anticipada entre las líneas de código de un programa con otras líneas de código en él mismo o en otra aplicación. Esta interacción puede tener consecuencias inocuas, como por ejemplo que el mouse no responda por unos segundos cuando abrimos determinadas aplicaciones en determinada secuencia, o devastadoras, como http://heartbleed.com/ que potencialmente le quita lo confidencial a todo lo confidencial en Internet.

Creo que con esta definición podemos contestar la pregunta: ¿podremos tener acceso algún día a software sin “bugs”? Sí, lo único que necesitaremos será una simulación de todas y cada una de las líneas de código interactuando de todas las maneras posibles con todas y cada una de las combinaciones de las otras líneas hasta lograr una especie de “determinismo binario”, o lo que es lo mismo, adivinar el futuro ¿es esto posible? Matemáticamente la respuesta es sí: lo único que necesitamos es una computadora con capacidad de procesamiento y de almacenamiento infinitos. Jeje.

En el mundo real las leyes de la termodinámica y la entropía en los sistemas nos cierran esta puerta definitivamente (temas relacionados: problemas de Hilbert, teorema de Shannon), así que la informática está condenada a un sistema evolutivo, no a uno determinista, y los errores van a ser siempre parte del avance de la tecnología en general y de extinción de algunas empresas en particular. Tony Hoare dijo: “hay dos maneras de diseñar software. Una es hacerlo tan simple que obviamente no haya errores. La otra es hacerlo tan complicado que no haya errores obvios”. La magnitud de la tarea y los miles de millones de líneas de código aún por escribir son parte de nuestra historia futura como especie, hay algunos movimientos interesantes como seL4, un sistema operativo cuyo Kernel ha comprobado matemáticamente estar libre de “bugs” pero claro, ningún equipo falla si no lo sacas de la caja, también hay tendencias en programación altamente preocupantes, como las utilizadas en casas de bolsa, lo cual me lleva a la segunda pregunta ¿está en peligro la humanidad de que un bug comience una guerra nuclear o destruya la economía? Sobre la guerra nuclear no tengo ni idea, espero que no, de la economía me encontré el otro día el siguiente artículo de Donald MacKenzie:

http://www.lrb.co.uk/v36/n17/donald-mackenzie/be-grateful-for-drizzle
La historia larga, corta, llega el tipo de comunicaciones en una de estas empresas de “stock-market” y le informa al VP correspondiente que la conexión con la sucursal de Londres ya está lista y que a partir de ese momento todos los cambios de un mercado se reflejarán de manera inmediata en el otro, y el VP le dice:

— Define inmediato

— Bueno, a la velocidad de la luz, la velocidad máxima en el universo. Si alguna acción o bono cambia de precio en NJ, ese cambio se transmitirá a la velocidad de la luz a Londres –uno se puede imaginar al tipo esperando su palmadita en la cabeza

— ¿Y cómo lo lograron?

— Unimos con fibra óptica las dos sucursales, fue un trabajo enorme, tuvimos que aislar la fibra con materiales que todavía no existían, cruzar los abismos más profundos del planeta y luchar con tiburones (todo esto es real)

— Ok, entonces cuando dices velocidad de la luz te refieres a la velocidad de la luz en un cristal, no en el vacío

— Correcto, 2/3 partes de la velocidad de la luz en el vacío, 125,000 millas o 5 vueltas a la tierra por segundo

— Pues no nos sirve, tiren esa fibra a la basura y conéctense por antenas, esto es una empresa seria.

Y efectivamente, a elegir geodesias y poner antenas, ya que la velocidad es crítica al grado de que incluso la longitud del cable que te conecta al router principal desde tu data center debe de ser igual al de todas las empresas que rentan espacio en el mismo. Para los desarrolladores que trabajan en este entorno las reglas cambian: utilizando la elegante técnica del “bit fucking” que ellos definen como: “no toques el Kernel, no toques la memoria, no invoques subrutinas” crean algoritmos en los circuitos integrados de estas máquinas que permiten un procesamiento suficientemente veloz como para sacar ventaja a la velocidad de la luz en el vacío vs. fibra óptica… ok… muy interesante, ¿Qué significa? Significa que esta evolución hacia la velocidad, este “bit fucking”, ha eliminado cualquier función adicional en el código, incluidos los mecanismos de detección de errores.

Vale, esto suena como un Meh! pero… un pequeño bug en estos sistemas, digamos alguien que confunda en el código el signo + por el signo –, que esté en producción unos segundos puede hacer perder millones al bróker, en 50 segundos más hacer quebrar al banco y en varios minutos colapsar la economía mundial, así que la siguiente vez que alguien confunda el 5 con la S podría ser el fin del mundo. Y eso es Mr. Bug.

Mi consejo a los programadores: coman frutas y verduras

Jorge A. Pinedo
Octubre, 2014