Memorias de un hacker retirado

Recuerdo mis primeros intentos por desentrañar los misterios de los computadores y la programación, en el lejano 1982. Mi primer compañero fue mi viejo y querido VIC20.

Obviamente, yo era de la hermandad de los fanáticos de Commodore. Y hasta el día de hoy, todavía mantengo largas discusiones con viejos camaradas, sobre cuáles eran los líderes de los primeros microcomputadores para el hogar.

Nunca llegaremos a una conclusión definitiva.

Commodore, Sinclair o Atari, todos con su legión de apasionados defensores y furibundos detractores, plenos de argumentos teñidos por la pasión.

N. del A.: Parece que desde los orígenes del mundo digital, el fundamentalismo forma parte de nuestra cultura.

Mi VIC20 tenía la fabulosa cantidad de 4.096 bytes de RAM (4 Kilobytes ... término que las nuevas generaciones no conocen).

En ese VIC20 aprendí los primeros vericuetos de la programación en BASIC y nació mi amor por transformar una abstracción en código fuente. A través de la animación de sprites, extensiones a la ROM y programación de rutinas de aceleración gráfica, conocí la simpleza y potencia de la fuerza bruta del lenguaje de máquina, la sutileza en el uso de un JMP condicional y la precisión necesaria para hacer un shift de bits en un registro.

Pero mi vida cambió radicalmente, cuando mis padres me pudieron comprar un Commodore 64.

Un nuevo y fabuloso equipo, que seguía conectando en largas veladas nocturnas al TV "en colores" del living de mi casa.

Siempre hemos escuchado que mirar TV excesivamente cerca, hace pésimo para la vista. Claramente, las largas jornadas de 6 o más horas, a una distancia de 35 o 40 centímetros de la pantalla del televisor, programando a punta de peek y poke, son un importante antecedente para mi temprana miopía.

A pesar de tener buses de 8 bits, el C=64 direccionaba hasta 64 Kb. La ROM/BIOS ocupaba sólo 8 Kb., por lo cual el C=64 me ofrecía ahora la fabulosa cantidad de 56 Kb de RAM, disponibles totalmente para mí.

Y permitía hacer maravillas, como ejecutar ese maravilloso juego llamado Ghosts & Goblins.



Así continué aprendiendo y experimentando, hasta que el año '86 tuve mi primer PC en casa.

Un "monstruo" con un procesador 8088 con 768 Kb de RAM (768 = 640 + 128, los geeks entienden por qué :-) y la increíble cantidad de 30 Mb en disco duro.

Cada vez que partía, ese computador con sus vibraciones y crujidos me recordaba el motor de un viejo refrigerador.

También en esa época, alrededor del '86, tuve la oportunidad de poseer un modem de 1.200 bps., aún cuando ciertamente no tenía muchos "nodos remotos" con los cuales aplicar mis nuevas "capacidades telemáticas".

Mi principal actividad remota era conectar mi ruidoso computador, a unos pocos BBS chilenos, participando de las primeras comunidades digitales locales. Incluso en algún momento, recuerdo haber levantado un servidor Wildcat, pero las continuas llamadas telefónicas recibidas en mitad de la noche, hicieron que mis padres rápidamente prohibieran el nuevo hobby.

Eran los tiempos donde debíamos aprender obligadamente las diferencias entre E-7-1 o N-8-1 para una emulación de terminal, y nos sabíamos de memoria los comandos y argumentos Hayes para configurar un módem (recordar un ATDTX3S0=0 me sirvió muchísimo hace unos días ...:-).

Esto de la paridad par o impar era particularmente importante, cuando nos conectábamos a la U para emular un IBM 3270 (que obviamente era MUY distinto de una emulación VT100, para conectarse a una VAX o un equipo Unix). Y aprendíamos con dificultad la diferencia entre la codificación EBCDIC y ASCII.

Ahí, en esos primeros tiempos, aprendí la importancia de la interoperabilidad, más allá de la teoría.

Eran buenos tiempos, donde nos rebuscábamos la mejor forma para poder acceder a ese gran banco de software llamado SIMTEL, ya fuera por una BBS potente o a través de una conexión a BITNET.

Más de alguien aprendió (después de quebrarse la cabeza) que XModem era un protocolo engañoso (porque modificaba los archivos recibidos), alabamos la flexibilidad de YModem y la capacidad de restauración de ZModem. Estos protocolos no sólo los usamos, sino que también los programamos y modificamos, adaptando el modelo de administración de ventanas y puntos de restore para diversos proyectos locales.

Y definitivamente nos graduamos de magos, cuando logramos completar una sesión de transferencia multiplataforma mediante Kermit.

En esos tiempos, lograr transferir un archivo de 150 Kb. era más preciado que un diamante. Y durante los 30 minutos o más que duraba una simple transferencia (en esos tiempos sí que había latencia), rezábamos para que no se cayera la sesión.

La experiencia de esos años austeros, en los cuales debíamos aprovechar al máximo cada bit disponible, me ha servido mucho y en diversos contextos.

Recuerdo un complejo proyecto a principios de los '90, en el cual todos esos conocimientos de hacker, los incluimos en un sistema distribuido de alta disponibilidad, que combinaba computadores clientes con 1 Mb de RAM, procesos residentes con corrutinas bajo DOS e interfaces usuario en Clipper orientado al objeto, una arquitectura fault tolerant sobre 3 nodos servidores VAX/VMS espejados en tiempo real, dispersos geográficamente y conectados sobre redes X.25, con anchos de banda de 64 Kbps. En ese sistema, diseñamos y programamos desde el más mínimo bit hasta los procesos de sincronización en tiempo real. Eran buenos tiempos.

Cuando estuve a cargo de Cybermarket en 1997 y montamos el primer mall virtual en Chile, en una operación de Comercio Electrónico pero "de verdad" (ofrecíamos un mix de 44.000 productos en 4 rubros, incluyendo lechugas, martillos, azúcar, destornilladores y crema facial), definimos algunos criterios de uso de recursos, tiempos de respuesta y usabilidad, que como responsable tecnológico consideré en ese tiempo como "intransables", con el pesar del equipo de implementación.

Cybermarket debía cargar las páginas en los browser de los clientes, en un máximo de 7 segundos, considerando transferencias con un ancho de banda de 14.4 kbps. y sin exigir capacidades de procesamiento de Javascript en el lado cliente. Y por cierto, con esas estrictas definiciones, problemas de interoperabilidad no teníamos.

Fue difícil lograr cumplir con esas duras condiciones. Pero hace más de 12 años, implementamos un sistema de e-commerce con algunos servicios que incluso hoy podrían aparecer como avanzados, porque nos preocupábamos más de la funcionalidad y usabilidad, que de los "bells & whistles" de las interfaces.

Probablemente, si no hubiera aprendido en mis primeros tiempos en un entorno de "carencia digital", habría sido más derrochador durante mi carrera profesional.

Pero en los momentos difíciles no transé y resistí la tentación de la abundancia. Y fue bueno no transar, motivo por el cual varios de esos proyectos fueron exitosos y tuvieron una larga vigencia.

En estos nuevos tiempos de "abundancia", ser un "avaro digital" sigue siendo una buena actitud.

Me sorprende ver cómo algunos nuevos arquitectos y diseñadores, consideran que el "ancho de banda" es cuasi ilimitado, el almacenamiento infinito, la disponibilidad continua, el hardware infalible. Y formados en la "abundancia", diseñan servicios, modelos, negocios, considerando un pool ilimitado de recursos.

Hoy declaro formalmente que soy un "hacker retirado", que se dedica a tomar litros de café conversando sobre el diseño de modelos de negocios y de servicios, y que lo más complejo que programo, son las reglas de distribución de mis correos electrónicos.

Pero a la luz de la experiencia, mi única y principal recomendación a los nuevos programadores (teniendo sólo algunos de ellos los antecedentes suficientes para ser llamados "arquitectos"), es que sean siempre .. unos "avaros digitales". :-)

Stay Tuned!

Fuentes de las imágenes: Wikipedia