El fracaso del PARC ¿Realmente Apple robó el fuego sagrado (las GUIs) a Xerox?

Lo que sigue son unas notas de lectura o una reseña parcial del libro "Dealers of Lightning. Xerox PARC and the Dawn of the Computer Age" de Michael A. Hiltzik, publicado hace ya casi 25 años. No se trata de una novedad editorial, pero casi un cuarto de siglo después de su publicación sigue siendo una fuente imprescindible para entender las razones detrás de la larga lista de innovaciones que en los años '70 surgieron del PARC.

Sigue una lista demasiado suscinta: la impresora laser, ethernet como tecnolgía de redes locales, la primera computadora personal (PC), programación orientada a objetos, interfaces gráficas de usuario (GUIs), aplicaciones WYSIWYG ("Lo que ves es lo que obtenés"), tecnología VLSI en integración de semiconductores, y muchas otras.
También suele señalarse no sin una gran dosis de patetismo el modo en que Xerox habría fracasado en lograr transformar la innovación que surgía a borbotones del PARC en productos comerciales. La lectura del libro de Hiltzik sirve para echar luz sobre esos hechos o algunos mitos, como aquella "verdad revelada" que todos conocemos, según la cual, en una visita Steve Jobs habría tomados por asalto al PARC y le habría robado algunas de sus creaciones, que tiempo después serían la esencia de la Apple MacIntosh, el segundo gran hit de Apple. Hiltzik ayuda a echar luz sobre aquel mito.

El Xerox PARC (siglas de "Centro de Investigaciones de Palo Alto"), fue producto de la visión de Charles Peter McCoulough, CEO de Xerox entre 1968 y 1982), en cuya mentalidad el Centro de Investigaciones debía convertirse en algo parecido a los Bell Labs de AT&T. El lugar del emplazamiento del PARC fue opuesto: se ubicó en California, cercano a la Universidad de Stanford, mientras que los Bell Labs estaban en la costa Este de los Estados Unidos.
La historia del PARC que el libro de Hiltzik presenta está construida mayoritariamente a partir de testimonios de primera mano de los principales investigadores del PARC, y el libro tiene como enorme mérito el de un relato que pareciera contarse a si mismo, casi de manera cinematográfica.
El libro de Hiltzik cubre la historia del PARC a través de sus años dorados, desde su establecimiento hasta comienzos de los años ´80 con la serie de conflictos que derivaron con el alejamiento de Robert Taylor, director entonces del "Computer Science Lab". Cabe recordar que Bob Taylor es el mismo que años antes había dirigido el IPTO de ARPA y bajo su tutela se puso en marcha la red ARPANet.
La visión de McCoulough en la primera década del PARC se materializaría en el propósito de crear una oficina del futuro, en la que el papel y las copias (el principal negocio de Xerox) tuvieran un papel secundario y las computadoras interconectadas en red permitirían procesar archivos, enviar emails, imprimir documentos en calidad tipográfica, etc. Las máquinas de escribir, los memos, el telex todas esas herramientas de la oficina de los '70 podrían quedar en el pasado. Incluso el PARC abrió la puerta a la posibilidad de tele-trabajar, ya que alguno de sus colaboradores trabajaron remotamente durante algún tiempo.
En el curso de una década el PARC había producido MAXC, una minicomputadora que era un clon de la PDP-10 de DEC, la cual fue la base para el desarrollo posterior en el Centro, luego la computadora que podría considerarse la primera PC, la Xerox Alto (1973), que fue la primera en incluir una interfaz gráfica de usuario, mouse, aplicaciones WYSIWYG como editores de texto, display de bitmap (con capacidades gráficas). Todo aquello era absolutamente nuevo. La computadora no llegó directamente al mercado pero se construyeron unas 2000 unidades, muchas de las cuales servían para el trabajo diario y como ambiente de desarrollo en el PARC. Además cientos de esas máquinas funcionaban en red, gracias al desarrollo y el despliegue de Ethernet en el Centro, que interconectó todas sus computadoras, se crearon servidores de archivos e impresión. Xerox presentó la patente de Ethernet en 1975 y destaca sus inventores: Robert M. Metcalfe, David R. Boggs, Charles P. Thacker y Butler W. Lampson.
El libro de Hiltzik narra de forma sumamente interesante cómo el PARC construyó el futuro, es decir muchas de las tecnologías que hoy son para nosotros cotidianas y damos totalmente por sentadas. La metáfora de nuestro ambiente de trabajo como un escritorio virtual surgió en el PARC.
La impresaora Laser fue tal vez el producto del PARC que Xerox mejor haya conseguido comercializar. Salió al mercado en 1977.
Ethernet llegó hasta nuestros días, gracias a que Xerox hizo un acuerdo con Intel y DEC para liberarla como un estándar abierto.


"Los grandes artistas roban"

El libro de Hiltzik también ayuda a poner en perspectiva un mito firmemente establecido en el folclore de la historia de la computadora. Según el mito Steve Jobs habría robado los secretos más preciados del PARC y Apple los habría utilizado con mucho éxito.
En parte el mito fue estableciéndose por testimonios de los propios protagonistas de Apple y sus estrategias de marketing, fueran estas manifiestas o no tanto. El propio Jobs, para referir aquellas visitas al PARC en 1979 lo hacía con una frase atribuida a Pablo Picasso ("Los buenos artistas copian, los grandes artistas roban"). De hecho el título del episodio de la serie "El Triunfo de los nerds", en donde aparece el testimonio de Jobs llevó por título la frase de Picasso.
Sin embargo, como el propio Hiltzik describe el robo no fue tal. Aquello fue producto de un acuerdo. En 1979, antes de la IPO (oferta inicial pública de acciones de Apple), Xerox compró como parte de una pre-venta unas 100.000 acciones de Apple, a un precio de 10 dólares por acción. De haberlas mantenido hasta la actualidad el valor ascendería a un par de billones de dolares.
Como parte del acuerdo Xerox accedió a hacer algunas demos para el personal técnico de Apple, incluido Jobs.
Para esas dos demos de 1979 los ingenieros de Apple estaban muy bien preparados, ya conocían de antemano qué se estaba cocinando en el PARC, porque leían los papers científicos de los investigadores del PARC o también tenían amigos o conocidos trabajando en el PARC. Asimismo el ambiente "académico" tendía a crear un entorno tendiente a presentar los avances y resultados de la investigación. Los técnicos de Apple fueron preparados para hacer las preguntas que debían hacer, porque eso era lo que precisaban para el diseño de la nueva Apple Lisa, la primera en presentar una interfaz gráfica de usuario.
Por supuesto, dentro del PARC hubo quienes se opusieron a que el Centro expusiera abiertamente sus productos a una audiencia altamente capacitada como eran los ingenieros de Apple, una de ellas fue Adele Goldberg. Sin embargo, los directivos de Xerox insistieron que como parte del acuerdo la demo debía hacerse. Xerox pensaba en que Apple podría ser la empresa que produjera y comercializara algunos de sus productos, cosa que finalmente no ocurrió.
Algunos historiadores suelen ser categóricos con Xerox en el sentido no haber podido aprovechar la oficina del futuro y la fábrica de innovación que tenía ¿Cuáles son algunas de las causas de no haber podido llevar los productos del PARC al mercado?
Para Hiltzik (luego también para Jobs), el principal problema venía dado por la cultura corporativa de Xerox. En los años '70, prácticamente todo la fuerza de ventas de Xerox estaba enfocada en vender un único tipo de producto: fotocopiadoras. De hecho, el modelo de leasing de las máquinas y pago por consumo o impresiones tendía a crear la ilusión de que Xerox no vendía máquinas, simplemente producía ganancias.
Esa cultura, largamente establecida entraba en choque con la suerte de "destrucción creativa" que habría sido necesaria para poder llevar la "oficina del futuro" al mercado. Es raro que compañías que llegan a una posición dominante y funcionan como monopolio de hecho, como la Xerox de los '70, puedan reconvertirse por completo, como por ejemplo para entrar en el mercado de las computadoras.
Estos choques culturales eran patentes entre los científicos del PARC y su visión de la alta gerencia de la compañía, a quienes solían referirse como "Toner heads" ("Cabezas de toner"), por el hecho de estar "moldeados" por la cultura de la fotocopia.
El propio Steve Jobs señalaba algo parecido en la entrevista de la PBS de mediados de los '90. Según él, en compañías que son monopolios de hecho, la gente de ventas y marketing termina tomando las decisiones de negocio. De alguna forma, el Jobs que estaba exiliado en Next, estaba refiriéndose a lo que había pasado en Apple bajo la dirección de John Sculley. Como resultado de eso, la alta dirección deja a parte a los diseñadores de productos y la compañía pierde de vista el esfuerzo que requiere hacer buenos productos. "La gente de ventas no tienen ni idea de la artesanía y el esfuerzo que supone convertir una buena idea en los mejores productos" (Entrevista a Jobs). Para compañías monopólicas el ritmo de la innovación es una lenta cadencia y en general son innovaciones de marketing, por ejemplo que Pepsi Co. presente una botella de un nuevo tamaño.
En aquella entrevista, el propio Jobs pone en perspectiva lo que para él habría sido el "fracaso" de Xerox: "Xerox podría haber sido la IBM de los años '90, podría haber sido la Microsoft de los '90".


Una conclusión, otros factores externos

No se trata de minimizar los problemas al interior de Xerox que limitaron el aprovechamiento de la "oficina del futuro". El choque de culturas impidió la "destrucción creativa" requerida para que Xerox pudiera adaptarse a sus nuevos horizontes.
Pero también hay otros hechos que permiten explicar algunas razones de aquel "fracaso". Por un lado, los investigadores del PARC estaban acostumbrados a construir, trabajar y desarrollar en un hardware que era el "estado de arte" de su época. Tal vez por ello, muchos de ellos experimentaban cierto desprecio por el incipiente mercado de pequeñas computadoras de 8 bits, que había surgido a la luz del Homebrew Computing Club y que luego se consolidaron en computadoras como las de Apple, Commodore, Radio Shack, Sinclair y Accorn en el Reino Unido. Precisamente de ese ambiente provenía Apple, la Apple II fue un producto directo de la revolución de los 8 bits y la electrónica "económica".
En 1981 coinciden también un par de cosas. Xerox lanza al mercado su Star 8010, el producto que era resultado de casi 10 años de desarrollo del Alto y que incluía un escritorio gráfico, mouse, apps gráficas, networking, etc. Su precio fue aproximadamente 16.000 dolares de 1981.
Ese mismo año se produce el otro hecho que lo cambiaría todo y que tomaría a la industria como un huracán: IBM presentó su IBM 5150, es decir la primera PC. Su precio básico era algo menor a los 2000 dolares de la época.
Como he sugerido en otro lugar, los modelos básicos de la primera PC tenían bastante similitudes con las pequeñas máquinas de 8 bits que ya habían inundado el mercado norteamericano y del Reino Unido a comienzos de los '80.
Definitivamente las computadoras económicas de 8 bits, fueron abriendo el camino, educando a los consumidores, para que finalmente la "oficina del futuro" fuera una realidad.
Xerox no fue la única en fracasar frente torbellino de la PC de IBM. Apple también lo hizo con Lisa, que salió a la venta en 1983 a un precio cercano a los 10.000 dolares.
¿Podría haber aprendido Apple de los problemas del Xerox Star? Como sea, Apple tendría que esperar al MacIntosh para tener su siguiente hit. Pero para lograrlo, tuvo que preparar a los consumidores a base de publicidad y marketing preciso, como el comercial de Ridley Scott en el Super Bowl, para que la oficina del futuro ya fuera pareciéndose a un logro del presente.
Entre éxitos y fracasos, el caso del PARC y de Lisa ilustra bien una conocida frase atribuida a Winston Churchill: "El éxito no es definitivo, el fracaso no es fatal: lo que importa es el coraje para continuar."

Matías Gutierrez Reto Continuar »

"Christmas Time's A-Comin'": los Bell Labs de AT&T también fueron un fábrica de hits

A lo largo de todo el siglo XX los Bell Labs inventaron el futuro. Láser, transistores, UNIX, AWK, teoría de la Información... La lista es larga como también lo es la cantidad y diversidad de los premios que sus científicos obtuvieron. Contando solo los Nobel, suman una decena, algunos de ellos obtenidos en este siglo. Pero esta historia es sobre otros de los hits de los Bell Labs: "Christmas Time's A-Comin'".

Recuerdo un artículo del semiólogo y filósofo Eliseo Verón en el diario Perfil, hace ya más de una década. En una digresión (o algo así) Verón se preguntaba por lo extraña que resulta la aliteración de la 'a' en el título "The Times They Are A-Changin'" de Bob Dylan. La huella, tal vez, está soplando en el viento y hay que rastrearla en esta canción navideña de Tex Logan, ingeniero y matemático de los Bell Labs.


Si a alguien lo bautizan Benjamin Franklin posiblemente esté predestinado a no perder el tiempo. Quizá ese fue el caso de Benjamin Franklin Logan Jr., nacido en Coahoma, un pueblo de menos de un millar de habitantes al Oeste de Texas. No había la menor impostura cuando Ben usaba un sombrero "10 galones", el de los cowboys, aún cuando ya se hubiera establecido en la Costa Este de los Estados Unidos.
Ben Logan Jr. obtuvo su título de grado en Ingeniería Eléctrica por el Texas Tech, luego continuó sus estudios en el MIT, donde obtuvo su título de Master in Science (Ingeniería eléctrica). Para 1956 se mudó a Nueva Jersey para sumarse a los Bell Labs y continuar sus estudios de doctorado en la Universidad de Columbia.
De jóven, cuando aún vivía en Texas una vez le envió una carta a Bill Monroe, uno de los padres fundadores del Bluegrass preguntándole quién era el "fiddler" (intérprete de violín) en los discos de 78 que escuchaba. La carta nunca tuvo respuesta, y los discos en ese tiempo no incluían los detalles de los músicos de la sesión de grabación.
La entrada de Wikipedia, de donde provienen algunos de esos datos biográficos define a Logan antetodo como "fiddler". Término de difícil traducción que designaría al intérprete popular de violín y no un "violinista". "Fiddle" refiere de forma informal al violín, pero también a una forma de interpretarlo, en especial en la tradición de música norteamericana de raíces irlandesas y escocesa, como el bluegrass pero también algunas otras de tradiciones algo diferentes como el cajún y zydeco o las jug bands de los años '20 y '30.
El padre de Logan, originario de Alabama, también había sido fiddler, de él Tex aprendió su arte.
Los verdaderos científicos saben discernir con claridad los límites de las analogías. En una entrevista a la PBS de Nueva Jersey Logan respondió "A menudo se dice que las matemáticas y la música se parecen. No la música que yo hago". Ser fiddler no es ser violinista, aunque a veces la velocidad de la digitación de vértigo. En otro lugar contó que en cierto momento de su juventud intentó estudiar violín, se dió cuenta que eso no era "fiddling", no como su padre tocaba el violín.
Ya en sus tiempos de estudiante en el MIT Tex Logan comenzó a salir a la ruta y ganar una suma nada despreciable de dinero como fiddler. Hasta retirarse de los Bell Labs en 1993, en días hábiles podrían llamarlo "Dr. Logan" o simplemente Ben para los amigos. Por las noches y en el camino, Ben era "Tex" Logan.
Está claro que a él no le gustaba mucho comparar el campo de la música con la ciencia. Con todo, sus logros científicos fueron comparables a su labor como interprete y compositor. En los Bell Labs trabajó en la teoría de señales. En 1962 junto a John Kelly presentaron un método de cancelación de eco, desde luego aplicable a las comunicaciones telefónicas de larga distancia, denominado "Adaptative Echo Canceller".
En la década de los '70 Logan trabajó junto Larry Shepp desarrollaron un método matemático para la clarificación de imágenes denominado desde entonces el "espectro Shepp-Logan", el paper de 1974 llevó por título "The Fourier Reconstruction of the Head". El método contribuyó al desarrollo de estudios de química y astronomía como también tuvo aplicaciones claves en el campo del diagnóstico médico por imágenes (en especial la tomografías).
En los Bell Labs Logan trabajó junto al físico alemán Manfred Schroeder, cuyas ideas acerca la "codificacación perceptual" llevaron al desarrollo de los métodos de compresión del sonido digital, por ejemplo el mp3.
Probablemente el mayor hit de Tex Logan en el campo de la música fue Christmas Time's A-Comin', una aparente simple colección de bucólicos motivos navideños de alguien que vuelve a su hogar en el campo para Navidad. Simplicidad, pero qué es si no una canción navideña.
. Su virtuosismo como fiddler lo llevó a tocar junto a su admirado Bill Monroe, Jerry Garcia, incluso grabar con los Bee Gees en el tema "Give Your Best" del album Odessa de 1969, donde el fiddle de Tex Logan destaca.
El eco de sus hits nunca fue cancelado. Christmas Time's A-Comin' fue grabada por una lista larga de artistas, como Johnny Cash, Emmylou Harris, Jerry Garcia y otros tantos. Aquí la versión de Jerry Garcia .
Diamond Joe, otra creación de Tex Logan fue grabada por Garcia y Dylan (este la grabó para la banda de sonido del filme "Masked and Anonymous" de 2003. No hay que confundirla con la canción homónima que Dylan incluyó en el album de 1992 Good as I've Been to You, que se remonta a la versión de Cisco Houston en primer término y Ramblin' Jack Elliot.
Diamond Joe debió llegarle a Logan a través de su padre u otros miembros de su familia, posiblemente de Alabama. La grabación de campo realizada por Alan Lomax en la granja de trabajo Parchman, la penitenciaría del estado de Mississippi en 1937 en la que Charlie Butler canta a capella unos versos que coinciden con la versión de Logan: "Diamond Joe, come and get me...". La versión de los Georgia Crackers definitivamente se acerca a la de Logan.
"Fiddling" no es exactamente lo mismo que tocar el violín, porque como dijo una vez un cantaor "El flamenco (o cualquier música folclórica) se canta con faltas de ortografía". De forma análoga siempre en el campo de la canción popular la tradición se expone y oculta alternativamente, expone sus conexiones con un pasado más o menos lejano. Su tradición se construye en el mismo acto de su interpretación.
Lo que este puñado de canciones también demuestran es que en tiempos de segregación racial, la música de los estados del sur de los EEUU mostraba cómo la tradición afro-americana cruzaba caminos con el Blue Grass.

A mi amigo Juan Millones, que en algún lugar debe seguir tocando Blues.

Matías Gutierrez Reto

Continuar »

Los 40 años de "Juegos de Guerra": la película que nos hizo soñar con la computadora

Este mes de junio de 2023 se cumplieron 40 años del estreno de la película "WarGames" o "Juegos de Guerra", como se la conoció en países de habla hispana. La película capturó con acierto los momentos en que la computadora se estaba volviendo "personal" y nos sumergió en un largo sueño digital: querer tipear en un teclado de una computadora, entender de qué se trataba todo aquello. Cuarenta años después sigue siendo un filme de culto, que vale la pena volver a ver. Algunos temas de la película tienen hoy un valor muy actual, como la Inteligencia Artificial.
Alguien alguna vez escribió que salir del cine (dejar el recinto de la sala para salir a la calle) guarda alguna similitud con el despertar de un sueño: el cuerpo, que por un cierto tiempo se ha sometido a un estado submotricidad, se pone lentamente en movimiento. En el paso del sueño a la vigilia intentamos a veces perdurar el sueño si aquel fue placentero, de la misma forma que para nosotros "reproducimos" internamente algo de las imágenes que por cierto tiempo se han desarrollado frente a nuestra vista cuando dejamos el cine.
En 1983 yo tenía nueve años, estaba en cuarto grado de la escuela primaria. Tan solo un año antes había sido la trágica experiencia colectiva de la guerra de Malvinas. En Buenos Aires "Juegos de guerra" se estrenó a principios del mes de julio de 1983.
Mi padre me llevó a ver la película a un cine del Centro un domingo de aquel invierno, pudo haber sido el cine Metro de la avenida Cerrito. Liberados ya de la tensión del relato en virtud del final catártico, cuando a la tardecita dejamos la sala ya era noche cerrada. El "sueño" del relato cinematográfico terminaba, volvíamos a la vigilia de la vida cotidiana, sin embargo la película consiguió construir en muchos de nosotros, apenas niños por entonces, el deseo desesperado de poner nuestras manos en una computadora real. Por largos años, echamos mano a todo aquello que pudiera seguir alimentando ese sueño: libros, revistas, etc.
Cinematográficamente hablando 1983 fue un año fecundo: se estrenaron, entre otras, "El regreso del Jedi", "007: Octopussy" y "Rambo". Todas ellas siguen siendo buenos clásicos, cuarenta años después. Pero "WarGames" creo que consiguió algo más: años después se convirtió en una película de culto porque condensó emotivamente de una forma muy poderosa el momento en que la computadora estaba volviéndose "personal". Tarde o temprano, el sueño de tener una computadora (poco importaba cuál) en nuestros cuartos podría hacerse realidad. Si eso estaba ocurriendo en los países centrales, tenía finalmente que ocurrir en los nuestros también.
De un primer vistazo "Juegos de guerra", pareciera tener todos los elementos necesarios para llegar a una audiencia de adolescentes, es sin dudas una "película para adolescentes", sin embargo terminó trasponiendo las fronteras demográficas de ese público acotado. Se transformó en un filme de culto. Algunas de las técnicas usadas en la película como el war dialing terminaron inspirando las técnicas de ciber seguridad, cracking y hacking "etico" que se desarrollaron posteriormente.
En la pantalla chica de la tele (solo había cuatro canales) y uno que desde la ciudad de Buenos Aires se veía siempre con algo de "lluvia" y "fantasmas" (literalmente) porque era de la ciudad de La Plata. El año siguiente, 1984, se realizó en los Estados Unidos una serie llamada "Whiz Kids", la que la televisión local emitió en su totalidad (solo duró una temporada), y que en castellano se llamó "La pandilla de la computadora". La serie fue una derivación ex profeso de "Juegos de Guerra", en la que la computadora, los modems y el acceso a sistemas remotos ocupaban un lugar central en esa ficción televisiva.
Las revistas que de a poco llegaban desde los Estados Unidos, como Byte o Rainbow que se exhibían en los kioscos "grandes" de la ciudad y las que pronto empezaron a aparecer en español, como Programación Popular o K64, que vieron la luz en el año 1984, nos hicieron perdurar el sueño de teclear sobre las teclas de una computadora real.


Esa máquina: IMSAI 8080

La computadora de David Lightman, el personaje principal de "WarGames" que protagonizó Mathew Broderick era una IMSAI 8080, contaba con una doble unidad de discos floppy, una terminal, el modem se acoplaba físicamente a un teléfono de "Ma Bell" por medio de un acoplador acústico. Para el año 1983 la computadora era algo obsoleta: se había dejado de producir en 1978.
Para 1983 la PC de IBM estaba comenzando a abrirse paso (terminaría de hacerlo por completo cuando proliferaron los clones). La computadora personal por excelencia en 1983 era la Apple II, una creación de Steve Wozniak y el producto primogénito con el que Apple levantó vuelo.
La IMSAI podía parecer algo vetusta para 1983, pero resultaba icónica. Su panel central de "blinkenlights" (en el argot hacker, "lucecitas titilantes") le daba un indudable aire "hacker", en el antiguo sentido del término. La IMSAI fue uno de los primeros clones de la historia: el fabricante (IMS Associates Inc) "clonó" la computadora de su principal competidor, la Altair 8800, que fabricó desde mediados de los '70 la firma MITS de Nuevo México. En un principio esa compañía vendió la computadora como un kit, que los usuarios debían ensamblar. Para proveer al incipiente mercado de hobistas con un lenguaje de programación interpretado y de alto nivel, los jóvenes Paul Allen y Bill Gates consiguieron escribir un intérprete basic que pudiera correr en los escasos 4K de ram de la Altair. Así fundaron, en Albuquerque, Nuevo México, cerca de la fábrica de Altair la firma Micro-Soft. Con el tiempo el guión intermedio desaparecería y la empresa se establecería definitivamente en Redmond, en los suburbios de la ciudad de Seattle.
Altair o IMSAI, ambas máquinas buscaban satisfacer el incipiente mercado de hobistas que estaban buscando hacer realidad el sueño de la computadora personal, una máquina que cualquiera de nosotros pudiera tener en su casa. Porque hasta entonces, la computadora era un bien escaso y solo accesible para universidades, grandes empresas o ciertas organizaciones estatales en los países centrales.
A principios de los años '70, en Menlo Park, en el llamado Silicon Valley se estableció el Homebrew Computer Club, allí confluyeron la mayoría de los pioneros de la llamada "micro-computadoras": Steve Wozniak, Steve Jobs, Lee Felsenstein, Thomas Fischer, Nancy Freitas (ambos empleados y luego dueños de IMS Associates/IMSAI), entre otros. Firmas como Apple, IMSAI, Cromenco entre otras derivaron de las reuniones de esa comunidad DIY ("hágalo usted mismo").

La arquitectura de la Altair 8800 (que al igual que la máquina de David en el filme estaba equipada con un procesador Intel 8080), se basó en el bus S-100. Ese mismo bus fue un estándar de facto en aquella primera generación de computadoras personales: la Altair y la IMSAI, pero también la Apple II. Esa arquitectura abierta hizo de aquellas computadoras un hardware abierto para el que otras empresas pudieron desarrollar placas de expansión y periféricos. Al igual que la Apple II la IMSAI resultaba altamente "customizable" y el usuario entusiasta (hacker) tenía al alcance de sus manos la potencialidad de expandir su hardware.
La IMSAI 8080 fue de las primeras máquinas en utilizar el sistema operativo CP/M, escrito por David Kildall, que luego sería la inspiración para el conocido DOS.
La IMSAI de David (Mathew Broderick) era una computadora para entusiastas, "entendidos" o hackers. No era como la Apple II, un dispositivo listo para que el usuario conectase y encendiese tan fácilmente como un electrodoméstico más. Su display de "Blinlenlights" resultaba además visualmente atractivo. Al igual que el display de la computadora del NORAD/DoD, denominada en la ficción como WOPR (War Operation Plan Response), y que se pronunciaba igual que la hamburguesa de Burger King.
A partir del hardware del cuarto de David, de los motivos visuales que se le aparecen al espectador en pantalla: ese "setup" de IMSAI, terminal, floppy, etc se puede decir que el personaje de Broderick es una representación fílmica de una generación de hackers que siguió a los pioneros de los microprocesares de 8 bits, del Homebrew Computer Club. Con ese personaje nos podíamos identificar plenamente, él era uno de los primeros usuarios de esas primeras computadoras "personales". Uno de nosotros, o aquello a lo que aspiraríamos a ser.


David Lightman

En WarGames no hay mención explícita del término "hackers". Si bien se puede inferir en base al hardware que David, el personaje encarnado por Mathew Broderick, tenía conocimientos bastante avanzados, y una red de amigos "hackers", a quienes consulta sobre backdoors y recopila datos que le servirán para la principal técnica que utiliza para introducirse en sistemas remotos, la denominada "ingeniería social". Para conseguir la contraseña del usuario del profesor Falken David realiza una cuidadosa investigación en base a datos públicos sobre la vida del profesor.
Pero otro de los rasgos de la personalidad de David es el hecho de ser un gamer. Lo vemos jugando al Galaga en un arcade antes de entrar a clase. Su motivación principal para hacer el "war dialing", es decir, la búsqueda ya sea por fuerza bruta o guida, realizando llamadas hasta que un modem responda. Esa técnica debía estar acompañada por el tono de 2600 Hz que descubrieron los phreaks (hackers de la red telefónica estadounidense). Aquel descubrimiento les permitió hacer llamadas de larga distancia a un costo cero.
La principal motivación de David, para nada contradictoria con su "estilo" hacker, es el gaming. Por la vía del escaneo de los teléfonos de una localidad ("war dialing") David busca conectarse a la computadora (nótese que aún no se las denominaba "servidores") de una compañía de video juegos, que se preparaba para lanzar un nuevo título al mercado. Él tenía que jugar a ese juego.
Una de las características del modo de hacer "hacker" es que la frontera existente entre el trabajo y el juego se desdibuja, porque el hacker está haciendo algo que encuentra inherentemente divertido y desafiante.

Los primeros ecos

El programa televisivo "The Computer Chronicles" (en lo sucesivo, TCC) se emitió desde 1983 hasta 2002 por la cadena televisiva pública estadounidense, PBS. El programa semanal tuvo como presentadores y columnistas a profesionales destacados del Silicon Valley. La emisión del 26 de marzo de 1984, poco más de medio año después del estreno de la película y solo dos meses después de que comenzara la primera temporada del programa, tuvo como tema central "Computer Security" ("la seguridad de las computadoras"). Para quien vea retrospectivamente el programa, resultará evidente que el traje y la corbata eran por lejos la vestimenta obligada en aquel tiempo. Sin embargo, el argot de ciberseguridad ya estaba allí, con muchos de los términos que aún siguen usándose en la actualidad.

De esta forma comenzaba la emisión de TCC del 26 de marzo de 1984:

"En nuestro programa de hoy estaremos conversando acerca de los problemas de la seguridad de computadoras. Imagino que a esta altura la mayoría debe haber oído acerca de la película 'Juegos de Guerra' y los diferentes tipos de problemas de seguridad que presenta la historia del film, pero tipicamente los problemas de seguridad de computadoras no suelen implicar cosas tan espectaculares como una guerra nuclear sino cosas mucho más mundanas, como el robo de dinero o información".

WarGames y la técnica de war dialing que David utiliza en la ficción aparecen como ejemplo de cómo podrían operar los crackers del mundo real. En aquella emisión de TCC no se hablaba acerca de redes, sino que el objetivo de los intrusos o delincuentes era la "computadora", que todavía no se había convertido en "servidor" o "clientes".
La visión técnica o hacker de WarGames no hizo foco en los riesgos y temores globales acerca de un conflicto nuclear sino en las técnicas de descubrimiento de objetivos y acceso no autorizado a sistemas remotos. Los presentadores se referían a "hackers" como personas que intentaban romper las credenciales de sistemas de tiempo compartido para conectarse a ellos.
La comunidad técnica veía WarGames como una forma de explorar accesos genuinos y de otro tipo a un recurso que si bien comenzaba a convertirse en un bien accesible, continuaba siendo un recurso escaso: la computadora. Esta visión de la película tal vez descuidó dos de los otros temas que la película trataba: los videojuegos y la inteligencia artificial. Aunque pueda resultar extraño, la IA era un tema de moda en 1984, quizá tanto como lo es hoy, cuarenta años después. De hecho la emisión siguiente del programa TCC estuvo dedicada a la inteligencia artificial, y tuvo entrevistados como John McCarthy, pionero de la IA, creador del lenguaje de programación LISP y profesor en Stanford.
Las críticas de cine generales, las que se publicaron en los diarios y a los que hoy podemos acceder gracias al archivo de la web, no hicieron el mismo foco en el tema del acceso (autorizado o no) a sistemas de tiempo compartido remotos, por el contrario se enfocaron en el papel de la inteligencia artificial en la historia que la película cuenta y el peligro de un conflicto nuclear, que sin duda movilizaba una dosis importante de preocupación en la audiencia de 1983.
Por ejemplo la crítica que Rita Kempley escribió para The Washington Post ubicó a WOPR en la misma serie que HAL, la computadora mentalmente "enferma" de 2001 Odisea en el Espacio y su secuela 2010:

"WOPR se ve como un horno homicida con ojos digitales, hijo antropomórfico de HAL, cuyo creador le enseñó no solo a jugar duro, pero también le enseñó a aprender de sus errores.

La crítica de Kempley concluía de manera favorable:

"WarGames presenta sutilmente una protesta, a favor de la gente, anti-nuclear y anti-máquina que entretiene. No vende ni la histeria de Jane Fonda en El sindrome de China ni la desesperanza de Dr. Strangelove. Es un llamamiento por la paz que resulta bueno hasta el último byte".

Por su parte, el crítico Roger Ebert, en su reseña del Chicago Sun-Times en 1983:

"Tarde o temprano una de estas máquinas inteligentes nos va a hacer volar de la superfície de nuestro planeta. Ese es el mensaje de WarGames, un escalofriante e inteligente thriller, que es una de las mejores películas de este año".

La crítica habló, de manera contemporánea al estreno de la película de los peligros de la IA, y de cómo el film podía ser visto como un alegato para la paz.
La teoría de los juegos (incluyendo al subconjunto juegos de video) y su relación con la Inteligencia Artificial es uno de los temas centrales de la película. La pregunta que deja planteada la historia es ¿Pueden las máquinas tomar decisiones tan trascendentales para el destino de la humanidad como lanzar una ojiva nuclear? El relato debate ese asunto, con personajes como el general Beringer, un militar de vieja escuela, campechano y de pocas pulgas, que desconfía abiertamente de las ventajas de la IA y sus antagonistas, como el Dr. McKittrick, jefe e impulsor del proyecto WOPR.
De manera parecida a HAL en la ficción de Arthur C. Clarke y Stanley Kubrick, WOPR también termina sufriendo algún problema de "psíquico". Pero otro aspecto interesante de la película viene dado por cierta ambigüedad: como espectadores no podemos saber si WOPR confunde la realidad, es decir descree de las señales que provienen de sus sensores externos (sentidos) para dejarse llevar por el mecanismo interno de su algoritmo ¿Confunde WOPR el juego con la realidad? ¿Alucina? (un concepto que hoy es actual en relación a la IA, pero en sentido más laxo). O por el contrario WOPR sabe que está jugando una simulación y son los personajes los que creen asistir a una escalada peligrosamente real. No podemos asegurar si WOPR habría llegado a accionar el misíl que la película nos muestra, aunque tememos que sí lo habría hecho y que la simulación no era tan solo eso, un juego en modo dry-run. Esta ambigüedad se cierra hacia el fin del film, para liberarnos de la tensión a la que el relato nos tuvo sometidos durante largo rato.

Los efectos

Hemos revisado algunos efectos de la película, en las críticas de cine y en un programa especializado de 1984, The Computer Chronicles.
El hecho de que rápidamente la película apareciera en emisiones o medios especializados es una muestra de cómo iría convirtiéndose en una referencia o en una "peli de culto" para la comunidad técnica. Los hackers no veían ninguna poesía anti-máquina en la película, por el contrario podían considerar todo eso como la exageración que hace de toda historia atractiva. Lo que más importaba para ellos eran las capacidades de acceso e intercambio (autorizado o no), es decir toda la potencialidad de la computadora, el objeto de deseo.
Otra muestra de la fuerza con que la película dejó su impronta en la imaginación y los productos de las comunidades científicas y técnicas en los años '80 y posiblemente en lo sucesivo la encontré recientemente cuando analicé el sistema operativo 4.2BSD de 1983. Esa versión de la distribución Unix desarrollada en la Universidad de California en Berkeley (De allí sus siglas> Berkeley Software Distribution) fue liberada en agosto de 1983, unos pocos meses después del estreno de la película. Como particularidad, esa versión de BSD fue la primera en incluir la pila de protocolos TCP/IP. La agencia DARPA (dependiente del Departamento de Defensa de los Estados Unidos) había elegido a BSD como el UNIX en el que se implementaría oficialmente el nuevo protocolo TCP/IP. Aquel año, 1983 DARPA estableció que ocurriría la transición de los antiguos protocolos de ARPANET (NCP y BBN 1822) a TCP/IP. Internet como la conoceríamos estaba tomando forma.
En otro lugar he analizado algunas de las particularidades históricas de 4.2BSD, el resultado de esa experiencia puede verse en este video: "El primer TCP/IP productivo corriendo en 4.2 BSD y funcionando, 40 años después". La experiencia fue realizada a partir de cintas originales que se preservaron con 4.2BSD.
En lo que respecta a 4.2BSD y WarGames, lo interesante es que el equipo de científicos que trabajó en la creación de la distribución incluyó algunas referencias a la película. El "Mensaje del día" (MOTD) que se mostraba a cada usuario luego de que hubieran ingresado exitosamente sus credenciales era "¿Querés jugar a un juego?". El mismo que recibió David en la ficción, luego de que consiguiera acceder a WOPR.
Otro hecho también resulta sumamente interesante. El archivo de usuarios /etc/passwd contiene los nombre de varias celebridades de la historia de Unix, por ejemplo Dennis Ritchie, Kirk McKusick, Bill Joy, Eric Alman, entre otros.

Pero hay un usuario más en la lista, llamado "falcon", fonéticamente muy similar a "falken" (el científico de la ficción). Su contraseña además es la misma que en la película, es decir uno puede "loguearse" en 4.2BSD usando las mismas credenciales que David dedujo en la ficción aplicando hoy las técnicas que denominamos como "ingeniería social".
"Juegos de Guerra" dejó una huella profunda no solo en la imaginación hacker (lo que sería difícil de demostrar) sino también en sus sistemas operativos. A partir de aquellos años BSD se convertiría en el UNIX "hacker" por antonomasia, hasta la llegada de Linux/GNU a principios de los años '90.

Cierre: "la única forma de ganar es no jugar"

En 4.2BSD (agosto de 1983) un usuario cualquiera podía identificarse con las credenciales del Profesor Falken e inmediatamente después aparecía en la consola la pregunta "¿Querés jugar a un juego?", si su respuesta era afirmativa seguía el mensaje: "Curioso, la única forma de ganar es no jugar". Aquella frase extraída de la película, parece referir a la situación conocida como "Zugzwang" en ajedrez.
En los años '80 ya se pensaba que la Inteligencia Artificial había llegado a un estadio de su desarrollo que podría ser explotada comercialmente. En aquel tiempo se denominaba a algunas de esas aplicaciones como "sistemas expertos". Pero aún no podía interactuar con alguna aplicación de IA utilizando el lenguaje natural. No había capacidad de cómputo aún para semejante cosa.
Hoy las aplicaciones de IA generativa, basadas en grandes modelos de lenguaje (chatGPT es la cara más visible) están en el centro de la escena. Curiosamente, hemos llegado al punto en que voces destacadas están advirtiendo sobre algunos peligros de la IA, con una situación similar al "Zugzwang". Para ellos sería necesario parar la pelota: no jugar por un tiempo como una forma de salir indemnes colectivamente ¿Será porque acaso se habría ido demasiado lejos?
De momento, pareciera que estamos lejos de HAL o de WOPR, pero siempre es difícil hacer predicciones, en especial hablando del futuro.

Matías Gutierrez Reto (retux), junio 2023

Referencias:
The Computer Chronicles "Computer Security", marzo 1984.
Roger Ebert: Wargames Review (1983)
Rita Kempley: "WarGames: Tense and Suspenful".
How the ARPANET protocols worked
Si te interesa la historia de la tecnología, quizá te interese "Piensa Abierto: Una historia del software de código abierto y libre.

"WarGames" o "Juegos de Guerra" es copyright de MGM/UA, dirigida por John Badham con guión de Lawrence Lasker y Walter F. Parkes, estrenada en junio de 1983

Continuar »

Optimizando el kernel de Linux para el escritorio (desktop) con xanmod

En ocasiones customizar y compilar el kernel de Linux/GNU puede ser una tarea que lleve mucho tiempo, no siempre invertir ese tiempo se justifica.

Eso se aplica si el hardware de tu PC es actual o si no querés sumergirte un poco en cómo el sistema funciona "bajo el capot".

Para quienes deseen exprimir su hardware al máximo y optimizar el comportamiento del sistema operativo para ciertos usos, por ejemplo optimizarlo para funcionar con aplicaciones "de escritorio" este post puede resultarles útil.

Hoy en día compilar el kernel del Linux es mucho más fácil de lo que acostumbraba ser. Xanmod o Liquorix ofrecen una serie de parches y optimizaciones que se aplican por sobre el kernel "vainilla" de Linux y que procuran optimizar el kernel para diferentes casos de uso.

Respecto de utilizar un kernel "de stock" provisto por nuestra distribución favorita, compilar el kernel nosotros mismos es una tarea que requiere invertir de cierto tiempo. Requiere al menos familiarizarse con el hardware en donde vamos a ejecutar ese kernel. Mi modesto consejo es configurá tu kernel si:

• Estás buscando optimizarlo para ciertos casos de uso.
• Si tu hardware es raro y requiere soporte que no estuviera ya presente en el kernel de tu distribución.
• Si por ejemplo un sistema embebido tiene relativamente pocos recursos y hay que reducir la "pisada" del sistema.

En mi caso más o menos recientemente solo necesité compilar el kernel cuando utilizo hardware antiguo. Por ejemplo si quisiéramos utilizar una unidad floppy o una interfaz ide un kernel estándar actual nos va a dejar a pie. Tengo una máquina que ya tiene cerca de doce años, es una pequeña netbook de las que el Gobierno de la Ciudad entregó a los alumnos de las escuelas primarias. Ya mis hijos no la utilizaban, porque quedó bastante rezagada para correr soft actual.

A mí me gusta por su diseño y su robustez. Puedo usarla a la intemperie, en cualquier clima. Y con Linux tiene una vida algo extendida, de otro modo ya habría ido a parar al callejón del olvido. Si bien el teclado no es cómodo, usé esa máquina para transcribir mi libro ("Piensa Abierto") de mis cuadernos manuscritos a archivos markdown, que fueron la base para su composición tipográfica. Demás está decir que navegar la web no es una experiencia llevadera en esa máquina, pero para escribir con visual studio o codear algunos script o aplicación simple resulta utilizable. Por eso me propuse hace unos días tratar de optimizarle algunos pocos ciclos de cpu a ver si podía reducir la latencia de ciertas aplicaciones. Pese a tener solo 1GB de ram, utilizo allí debian con enlightenment como gestor de escritorio, lo que hace al desktop elegante y liviano. El principal cuello de botella de la máquina es sin dudas su CPU, un antiguo Atom de Intel.

Xanmod y la optimización del kernel

Xanmod es una distribución de software, en este caso una distribución del kernel Linux que incluye varios parches y mejoras, algunas de las cuales no se incluyen en el kernel estándar. En general el fuerte de Linux/GNU desde su edad temprana ha sido correr en el servidor. Es por ello que con cierto grado de solución de compromiso, el kernel suele incluir una configuración que resulte estable para el servidor, pero no necesariamente está optimizada del todo para software de escritorio. Entre otros usos xanmod procura facilitar esos ajustes y "tweaks" para que uno pueda optimizar el kernel para el escritorio. Otra distribución alternativa es Liquorix . Estas distribuciones suelen incluir binarios ya compilados del kernel, empaquetados en paquetes .deb, por ejemplo utilizables en Debian o Ubuntu. Además existen paquetes para Arch, Fedora, etc. Un problema es que ya es raro que se incluyan binarios 32bits en estos builds, y el Atom de mi vieja netbook no es 64 bits. Compilar el kernel tenía entonces algo más de sentido. Además podría incluir algunos ajustes más para reducir la latencia, en particular me interesaba ajustar la "preferencia" del kernel (en inglés "preemption" para intentar reducir en algo la latencia del escritorio). Además podría seleccionar schedulers alternativos para controlar la Entrada/Salida de disco (este fierro viejo tiene hdd).

Compilando el kernel (usando el código fuente de xanmod) a la manera de Debian

Para comenzar, obviamente se requiere descargar el código fuente del kernel, en la distribución provista por xanmod. Como he descripto en una entrada en este blog hace ya varios años atrás voy a compilar el kernel a la Debian, eso quiere decir que los artefactos que resulten del build serán un puñado de archivos .deb (el kernel en sí, sus headers y al librería de C). De esa forma uno puede distribuir esa versión de su kernel "custom" de forma fácil. La manera en como se compila a la Debian ha cambiado hace un tiempo y hoy es incluso más fácil. Manos a la obra. Por supuesto no iba a compilar mi kernel en la vieja netbook, porque allí demoraría días, o quizá semanas. De forma que es mejor utilizar el hardware más potente que tengamos a mano. En mi caso, la PC de mi escritorio tiene un procesador AMD de 64 bits, de modo que es necesario hacer un cross-compiling para que los binarios resultantes sean de 32 bits. Pero eso no es más que pasarle un parámetro al compilador.
Si uno quiere empezar a jugar con la configuración y no invertir horas de prueba y error, lo más seguro es partir de una configuración conocida. En el directorio /boot tenemos la configuración del kernel que estamos utilizando y podemos partir de esa configuración para empezar a hacerle algunos cambios.

1) Instalar dependencias, si es la primera vez que vamos a compilar el kernel necesitaremos las herramientas de desarrollo:

$ sudop apt-get install build-essential bison flex

2) Para partir de una configuración "conocida", desde dentro del directorio de las fuentes de xanmod:

$ make localmodconfig

Con esto lo que haremos es crear el archivo de configuración del kernel (.config) a partir de la configuración del kernel actual y de los módulos que éste contiene.

3) Luego, copiar el directorio de xanmod a la máquina (más potente quizá) que utilizaremos para la compilación.

4) En este punto, previo a la compilación es cuando -si queremos- podemos hacer algunos ajustes. A mí me interesaba, como comenté antes, cambiar la preferencia del scheduler del kernel:

$ make menuconfig

Ese comando abrirá una interfaz ncurses para navegar las diferentes secciones de la configuración del kernel.

En la sección "Preemption Model", selecciné "Preemptible Kernel (Low-Latency Desktop)". Una nota sobre esto ¿De qué se trata el model de preferencia? Dicho en pocas palabras, define el modo en que el kernel elige entre las diferentes procesos o tareas que deben correrse en un sistema operativo multi-tasking (como todos los actuales). El modo seleccionado procura que las aplicaciones de escritorio puedan correr sin muchos contratiempos, aún cuando el sistema esté bajo una carga pesada, como suele ser el caso de mi netbook. Por otro lado quería experimentar también con el scheduler de Entrada/Salida, por ello agregué algunos schedulers que no suelen ser tan estándar:

Me interesó el scheduler BFQ. En este caso agregué el scheduler como módulo, de modo que si no lo quiero utilizar luego no ocupe más memoria en la imagen del kernel.

5) Finalmente (en una máquina más o menos "potente") hacer el build:

$ make ARCH=i386 -j 8 deb-pkg LOCALVERSION=-retux

Aquí con ARCH= indicamos la arquitectura target, que es i386 ya que se trata de un procesdor Atom de Intel. Con -j N podemos asignar un cierto número de núcleos de CPU disponibles para paralelizar la compilación.

6) Instalar en la máquina de destino, que usará este kernel instalar los .deb.

$ sudo dpkg -i *.deb

7) En la configuración del kernel, en los parámetros que grub le pasa en tiempo de boot, se puede seleccionar el scheduler BFQ y deshabilitar watchdog (que en una máquina de escritorio o laptop no es indispensable):

elevator=bfq nowatchdog

Con justicia, ustedes me preguntarán ¿Y los resultados? ¿Vale la pena el esfuerzo? Algunos mejoras en la netbook, en lo que hace a la latencia fueron perceptibles. No es el día y la noche, solo con esto no vamos a hacer de una pc de 13 o 14 años, pero en algo podemos extenderle la vida. Además puede ser el comienzo de otras experimentaciones para el que le interese.
Existe una analogía entre algo del "hacking" con la práctica de los radioficionados. Entre estos existe una práctica denominada transmisión QRP, que consiste en transmitir con la menor potencia en antena. De esa forma, lo que se procura es optimizar el rendimiento (de la línea de transmisión, de la antena, etc) para obtener el mejor resultado posible. De esa forma, un comunicado QRP tiene otra satisfacción diferente a la de poner 100W en antena.
Espacio para mejoras, siempre suele haber, por pequeño que este sea. Si puedo hacer algunos benchmarks prometo publicarlos próximamente.

Continuar »