Y2K: el bug del 2000 no fue una farsa, y todavía quedan piedras en el camino

En algún momento de la primera mitad de 1998 uno de mis colaboradores me pidió una reunión a solas. Cuando estuvimos en la oficina, puso sobre la mesa una carpeta y dijo:

–Mirá esto.

Me puse a leerlo. Antes de terminar el primer párrafo tenía todas las alarmas mentales encendidas. El informe era inverosímil, pero posible. Incluso probable. Cuando terminé de captar toda la idea, antes todavía de leer toda la documentación, solté:

–Si esto es cierto y no lo publico, me quedo sin trabajo. Y si lo publico y no es cierto, también.

Estaba exagerando un poco, pero había algo de cierto en mi evaluación. Porque no tenía modo de comprobar si ese informe, que hablaba de lo que luego se conoció comoBug del 2000 o Y2K (por Year 2000), era cierto o no. La carpeta podía ser muy creíble y provenía de una organización muy seria. Pero para ponerlo en tinta sobre papel no me alcanzaba.

Entonces se me ocurrió una idea. Fuimos a mi escritorio y la llamé a Silvina Seiguer, que hoy hace la comunicación de McDonald’s y por entonces estaba en IBM. Le pedí ver el código fuente de los programas que podían fallar cuando se agotara el último segundo del 31 de diciembre de 1999 y pasáramos al año 2000. Casi seguramente fue la solicitud más extravagante que recibió en su carrera, pero nos conocíamos bien y de inmediato se puso a buscar el modo de que pudiera ver ese código fuente.

De 99 a 0 en un segundo

Todo lo anterior, supongo, requiere una explicación. El Y2K era un problema (y uno serio, como se verá enseguida) porque compañías de toda clase, la banca, organismos estatales, hospitales y empresas de servicios públicos, entre otros, usaban programas que habían sido escritos en una época en la que el costo de la memoria y del almacenamiento era astronómico. Así que había que ahorrar bits a toda costa. Una de las técnicas que se empleó fue la de representar el año con solo dos dígitos. Después de todo, nadie esperaba que esas aplicaciones duraran tanto tiempo.

Pero, contra todo pronóstico, llegaron a finales del siglo XX, y cuando 1999 se convirtiera en 2000, para miles de funciones y rutinas el cambio sería de 99 a 00. Así, por ejemplo, un banco podría entender que sus cuentas llevaban 99 años sin usarse, y el software las cerraría. Parecía demasiado malo y a la vez demasiado banal para ser cierto.

Pero la razón por la que el asunto me resultó verosímil es que vi nacer estas tecnologías, y a una edad temprana, por lo que ciertas ideas se fijaron de manera indeleble. Sabía de primera mano que el código debía ser conciso y que al principio todo costaba fortunas y era pesado. No tenía nada que ver con el concepto de computación que tenemos hoy, móvil, de bolsillo, con miles de millones de bytes de espacio de memoria y billones de bytes de almacenamiento. Las comunicaciones se medían en unos pocos cientos de bits por segundo (o menos), no en decenas de millones. El Y2K podía ser un cuento, pero tenía sentido. Algo me decía que tenía sentido. Esa corazonada no alcanzaba para imprimirlo en la tapa del diario. Pero ahí estaba, punzante. Lo único que quería en ese momento era verle la cara. Que es donde entra la trillada y mal comprendida frase "código fuente".

Vos hablás raro

El código fuente o código a secas (no códigos, en plural, como suele leerse) es el texto que escribe una persona en un lenguaje de alto nivel para desarrollar programas, software. ¿Sigue sonando como que estoy insolado, no? Por supuesto. Pero es más simple de lo que parece (si evitamos los detalles más finos).

Un programa de computadora (o smartphone, aspiradora inteligente, smartTV, etcétera) le dice al equipo que haga algo. Por ejemplo, que funcione como este procesador de texto que estoy usando ahora. A la vez estoy corriendo otro programa, para navegar la web (Firefox). Y otro para oír música (Spotify). Las instrucciones para que una computadora (etcétera) haga algo las ejecutará un microprocesador o cerebro electrónico (en ocasiones, más de uno). Fantástico, redondito, pero hay un problema.

Los cerebros electrónicos no entienden los lenguajes humanos. El único lenguaje que entienden es el de los unos y los ceros. O sea que para escribir un programa sencillo podría ser necesario componer 10.000 líneas de código escribiendo solamente (insisto, solamente) unos y ceros, y usando instrucciones las microinstrucciones correspondientes a ese cerebro electrónico. Imposible. Una pesadilla.

Pero esa pesadilla es lo que el cerebro electrónico puede ejecutar; ese lenguaje se conoce como "instrucciones de lenguaje de máquina".

Muy bien. De un lado tenemos una persona que quiere crear un programa. Pero no habla lenguaje de máquina. Del otro, un cerebro electrónico que no entiende ningún idioma humano. Necesitan un intérprete, para ponerlo en términos bien simples.

¿Cómo funciona? El programador escribe el software en un lenguaje que usa palabras y estructuras sintácticas fáciles de comprender para la mente humana. A tales lenguajes se los conoce como de alto nivel (C, Java, JavaScript, Python, y sigue la lista). Ese texto compuesto de líneas de código en un lenguaje de alto nivel se conoce como "código fuente". Todavía no sirve para ejecutarlo en una máquina. Primero hay que traducirlo (sin entrar en detalles, esto se llama "compilar") a las instrucciones del lenguaje de máquina. Algunas veces (es el caso de JavaScript) la compilación es en tiempo real. Otras, antes de la ejecución del programa. En cualquier caso, si de verdad querés saber qué hace un software tenés que mirar su código fuente. Por eso el software libre o de código fuente abierto es clave en el mundo hoy.

Es decir, si el Y2K era real, el código de las algunas funciones que involucraran fechas contemplaría solo dos dígitos para el año, y tomarían una decisión más o menos seria sobre esa base. Esa base estaba a menos de dos años de convertirse en falsa. Al pasar de 1999 a 2000 la máquina podría suponer, por ejemplo, que había vuelto a 1900. Así que cuando Seiguer me avisó que tenía la demostración lista, caminé hasta el edificio de IBM, subí a no sé qué piso y me senté con un programador.

Ahí estaba el Y2K, claro y distinto. Revisamos varias funciones de un programa bancario. En todos los casos, el software iba a tomar medidas disparatadas cuando se hicieran las cero del 1° de enero de 2000.

Pero lo arreglaron

OK, había chequeado el dato, agradecí (de nuevo) el haber aprendido programación, y en agosto LA NACION publicó la primera nota sobre el Bug del 2000. Luego siguieron muchas otras. Era como una sombra que me perseguía, porque a medida que se acercaba la hora señalada, tenía que volver sobre el tema una y otra vez. Además, empezó el delirio, como casi siempre que se combinan hechos catastróficos, fines de siglo y artilugios esotéricos, como lo eran las computadoras en esa época. Recuerdo, por ejemplo, el libro en el que un pícaro daba instrucciones para protegerse de lo que, anticipaba, sería la expiración de la civilización tal como la conocíamos. Se sumaron sectas varias. Y muchos oportunistas que no podían ni siquiera deletrear la palabra Cobol. Algo semejante pasa hoy con los que hablan de algorritmos.

Con el tiempo, y esto es de lo más injusto, todo el asunto quedó como una gran farsa fabricada por las corporaciones, los medios y otros eternos sospechosos. El argumento (y esto, les digo la verdad, me supera) fue que "al final no pasó nada". O sea que si hacés los deberes, anticipás un problema potencialmente desastroso a tiempo e invertís unos 300.000 millones de dólares para evitarlo, entonces el problema no existió. Genial.

Como han pasado veinte años desde que el mundo debería haberse acabado (y no pasó casi nada), Steven Bellovin, profesor de ciencias de la computación de la Universidad de Columbia, escribió estos días sus experiencias con el Y2K. Lo cito: "Realmente fue un problema potencialmente serio, pero el desastre fue evitado gracias a un montón de trabajo por parte de programadores que nunca fueron reconocidos". Entrevisté a Bellovin hace unos seis años, en ocasión de un error llamado Heartbleed, y el hombre es una autoridad en materia de seguridad informática.

Lo interesante de su artículo es que, con un poco más de tiempo, advierte sobre otra falla, para la que faltan todavía 18 años, pero que ya podría empezar a causar problemas. Está en inglés, pero es muy interesante, tanto como el hilo en Twitter que publicó John Feminella, de ThoughtWorks.

En pocas palabras, el nuevo cuco se llama Y2038, por lo que faltan 18 años (un poco menos, como se verá) para que explote. Lo que ocurre es que todos los sistemas basados en Unix (típicamente, Linux y MacOS) usan un sistema para almacenar el tiempo que cuenta la cantidad de segundos que pasaron desde las cero del 1° de enero de 1970 (un instante conocido como La Época). El problema es que en los sistemas de 32 bits, eso representa un rango que termina el 19 de enero de 2038 a las doce y cuarto (con 8 segundos) de la noche (hora Argentina).

Es poco probable que para entonces sigamos usando sistemas de 32 bits, pero, más allá de que lo mismo se pensó del Y2K, los problemas ya se están presentando ahora, especialmente, sostiene Bellovin, en las Mac.

Conforme a los criterios de

Conocé más