El día de hoy ocurrió el fin de una era para muchos que hicimos pininos en internet a fines de los 90’s y principios del nuevo milenio… Geocities (www.geocities.com) dejó de existir, luego de 15 años de existencia, dejando atrás una historia llena de páginas interesantes o funestas, diseños originales o chocantes.

A quien alguna vez visitó algún sitio de Geocities, seguramente se encontró con esos diseños noventeros. Y a quienes hoy en día visitan los modernos MySapce o Hi5 personalizados con colores que molestan la retina, con fondos que distraen, con estrellitas, corazonsitos, gifs animados y demás, sepan que la idea no es original de esta época (y tampoco de la de Geocities, claro), y que los sitios personales en Geocities se caracterizaban muchas veces por tener esas características también. (Véase por ejemplo, la página del Infierno HTML de Eric Raymond).

Geocities nació en California en 1994, y para 1999 era tan popular que la poderosa de los noventas Yahoo! la adquirió. Yo en lo personal recuerdo que muchas de las búsquedas que he hecho en internet, llegaron a toparse con sitios en Geocities, que hoy ya están perdidos (a menos que el Internet Archive los haya rescatado a tiempo, o claro, que sus dueños los hayan respaldado para darles vida de nuevo en otro nicho en el que, como en sus orígenes, se pueda cultivar la comunidad naciente e inexperta del boom del punto-com

Fue en abril del 2009 que Yahoo! anunció que terminaría con Geocities, que no aceptaría más creaciones de nuevas cuentas y que para el 26 de octubre de ese mismo año, Geocities dejaría de existir…

Y bueno, yo mismo, siendo un post-adolescente veinteañero, en mis años de escuela, inexperto, ignorante y poco experimentado como era, me terminé topando con la idea de tener mi propio sitio en internet, gratis y fácilmente… Así que, como muchos otros, también tuve mi sitio personal en Geocities, el cual como todos ya dejó de existir (bueno, tengo un respaldo, algún día lo pondré en línea para que sirva de memoria histórica nada más .

La siguiente es una imagen de la página principal que, como muchos otros sitios de Geocities, carecen horriblemente de un buen diseño jeje… Por cierto, a la fecha, hasta hace unos minutos, todavía existía mi sitio en Geocities, aunque tenía siglos que no lo actualizaba en nada… Lo último que hice en él fue guardar una foto mía y de mi novia, para tener dicha imagen en línea, así que ahora tendré que buscar otro lugar en línea para lo mismo…

Y así terminó una gran parte de la historia de muchos… ha muerto Geocities, pero larga vida al Internet

Con esta cuarta parte terminamos la traducción de la historia de Unix, del capítulo 2 del libro ‘The Art of Unix Programming’ de Eric S. Raymond. ¡Espero hayan disfrutado leyéndolo tanto como yo haciéndolo!

Historia de Unix (4ta parte)

El movimiento Open-Source (Código Abierto): 1998 y siguientes

Para el momento de la liberación de Mozilla en 1998, la comunidad hacker puede ser analizada mejor vista como una colección algo suelta de facciones o tribus que incluyen al Movimiento del Software Libre de Richard Stallman, la comunidad Linux, la comunidad Perl, la comunidad Apache, la comunidad BSD, los desarrolladores de X, la Internet Engineering Task Force (IETF), y al menos una docena más. Estas facciones se traslapan, y un desarrollador individual bien puede estar afiliado a dos o más.

Una tribu puede estar agrupada alrededor de una base de código particular que mantienen sus miembros, o alrededor de uno o más líderes de influencia carismáticos, o alrededor de un lenguaje o una herramienta de desarrollo, o alrededor de una licencia de software particular, o alrededor de un estándar técnico, o alrededor de una organización vigilante de alguna parte de la infraestructura. El prestigio tiende a correlacionarse con la longevidad y la contribución histórica así como con parámetros más obvios como el estado actual del mercado y la corriente actual de pensamiento; por ello, tal vez la tribu más universalmente respetada es la IETF, que puede reclamar continuidad desde los inicios de la ARPANET en 1969. La comunidad BSD, con tradiciones continuas incluso desde los 70s, tiene un prestigio considerable a pesar de tener muchas menos instalaciones que Linux. El Movimiento del Software Libre de Stallman, con sus orígenes en principios de los 80s, está dentro de las grandes tribus, tanto por su contribución histórica como por ser quien mantiene varias de las herramientas de software en uso constante día con día.

Luego de 1995 Linux adquirió un rol especial tanto por ser la plataforma unificadora para la mayor parte del resto del software de la comunidad, como por ser la marca producida por los hackers más reconocida públicamente. La comunidad Linux mostró una correspondiente tendencia a absorber otras sub-tribus – y, por lo tanto, a captar y absorber las facciones hacker asociadas con los Unixes propietarios. La cultura hacker como un todo comenzó a tener en común una misión: llevar a Linux y al modelo de desarrollo en bazar tan lejos como pudieran ir.

Ya que la cultura hacker posterior a 1980 estaba tan enraizada en Unix, la nueva misión fue implícitamente la misión por lograr el triunfo de la tradición Unix. Muchos de los líderes más respetados de la comunidad hacker también eran ancestros en Unix, que aún portaban las cicatrices de las guerras civiles posteriores a la diversificación en los 80s y resguardándose detrás de Linux como la última, mejor esperanza para conseguir aquellos sueños de rebeldía de los primeros días de Unix.

La liberación de Mozilla ayudó a concentrar más las opiniones. En marzo de 1998 una junta cumbre sin precedentes que convocó a los líderes de influencia de la comunidad, representando a casi todas las mayores tribus, convino en considerar metas y tácticas comunes. La junta adoptó una nueva etiqueta para el método de desarrollo común para todas las facciones: código abierto (open-source).

En tan solo seis meses casi todas las tribus de la comunidad hacker aceptarían “open-source” como su nuevo estandarte. Grupos más viejos como la IETF y los desarrolladores BSD comenzarían a aplicarlo en retrospectiva a lo que habían estado haciendo todo el tiempo. De hecho, para el año 2000 la retórica del código abierto no solamente unificaría la práctica presente de la cultura hacker hacia el futuro, sino que también re-pintaría la visión de su propio pasado.

El efecto galvanizante del anuncio de Netscape, y de la nueva prominencia de Linux, alcanzó más allá de la comunidad Unix y la cultura hacker. Comenzando por 1995, los desarrolladores de varias plataformas que estaban en el camino del monstruo devorador de Microsoft Windows (MacOS; Amiga; OS/2; DOS; CP/M; los Unixes propietarios más débiles; varios sistemas operativos de mainframes, minicomputadoras y microcomputadoras obsoletas) se unieron alrededor del lenguaje Java de Sun Microsystems. Muchos desarrolladores de Windows contrariados se les unieron con la esperanza de mantener al menos cierta independencia nominal de Microsoft. Pero el manejo de Java por parte de Sun fue (como se discute en el Capítulo 14) torpe y alienante en varios niveles. A muchos desarrolladores Java les gustó lo que vieron en el naciente movimiento open-source, y siguieron a Netscape hacia Linux y el código abierto así como anteriormente siguieron a Netscape hacia Java.

Los activistas del open-source dieron la bienvenida a la oleada de inmigrantes provenientes de todas partes. Las antiguas manos de Unix comenzaron a compartir los sueños de los nuevos inmigrantes de no solamente aguantar de manera pasiva al monopolio Microsoft, sino de hecho a quitarle mercados clave. La comunidad open-source como un todo preparó un empuje mayor hacia ser respetada en la corriente principal, y comenzó a aceptar alianzas con corporaciones mayores que cada vez más temían perder el control de sus propios negocios conforme las tácticas cerradas de Microsoft se volvían cada vez más oscuras.

Hubo una excepción: Richard Stallman y el Movimiento del Software Libre. “Open-source” deliberadamente pretendía reemplazar el “software libre” preferido por Stallman con una etiqueta pública que fuera ideológicamente neutral, aceptable tanto para grupos históricamente opuestos como los hackers de BSD como para aquellos que no querían tomar partido en el debate GPL/anti-GPL. Stallman acarició la idea de adoptar el término, y luego lo rechazó con el argumento de que fallaba en representar la posición ética central en su modo de pensar. El Movimiento del Software Libre ha insistido desde entonces en su separación del “open-source”, creando tal vez la fisura política más significativa en la cultura hacker del 2003.

La otra (y más importante) intención detrás de “open-source” fue la de presentar los métodos de la comunidad hacker al resto del mundo (en particular a la corriente de los negocios) en una manera más amigable con el mercado y con menos confrontación. En este papel, afortunadamente, demostró un éxito arrollador – y llevó a que se reviviera el interés en la tradición Unix de donde surgió.

Lecciones de la historia de Unix

El patrón a gran escala en la historia de Unix es este: cuando y donde Unix se ha adherido cercanamente a las prácticas del código abierto, ha prosperado. Intentos de hacerlo propietario han resultado invariablemente en estancamiento y declinación.

En retrospectiva, esto probablemente debió haberse vuelto obvio más pronto que lo que en realidad se hizo. Perdimos diez años luego de 1984 aprendiendo nuestra lección, y probablemente nos hará mucho mal si volvemos a olvidarla.

El ser más listos que cualquiera sobre hechos importantes pero estrechos sobre el diseño del software no previno que fuéramos casi completamente ciegos sobre las consecuencias de las interacciones entre tecnología y economía que pasaban justo frente a nuestros ojos. Incluso los pensadores más perspicaces y previsores en la comunidad Unix estaban cuando mucho medio ciegos. La lección para el futuro es que confiar de más en la tecnología o el modelo de negocio de algún particular sería un error – y el mantener la flexibilidad de adaptación de nuestro software y la tradición de diseño que conlleva es correspondientemente imperativo.

Otra lección es esta: Nunca apostar contra la solución barata. O, de manera similar, la tecnología de hardware de bajas prestaciones y en gran volumen casi siempre termina escalando la curva de potencia y ganando. El economista Clayton Christensen llama a esto una tecnología disruptiva y mostró en The Innovator’s Dilemma [Christensen] cómo sucedió esto con las unidades de disco, las palas de vapor, y las motocicletas. Lo vimos suceder conforme las minicomputadoras desplazaron a los mainframes, las estaciones de trabajo y los servidores reemplazaron a las minis, y las máquinas Intel vistas como materia prima reemplazaron a las estaciones de trabajo y a los servidores. El movimiento open-source está ganando al hacer del software una materia prima. Para prosperar, Unix necesita mantener la destreza al captar la solución barata en lugar de tratar de combatirla.

Finalmente, la comunidad Unix de la vieja escuela falló en sus esfuerzos por ser “profesionales” aceptando toda la maquinaria de manejo en la organización, finanzas y mercadotecnia de las corporaciones convencionales. Debimos ser rescatados de nuestra locura por una alianza rebelde de geeks obsesivos y desadaptados creativos – que procedieron a mostrarnos que el profesionalismo y la dedicación en realidad significaban aquello que estuvimos haciendo antes de sucumbir a las persuasiones mundanas de las “prácticas empresariales sanas”.

Aplicar estas lecciones hacia tecnologías de software aparte de Unix se deja como un ejercicio sencillo al lector.

Referencias bibliográficas de esta sección:
[Christensen] Clayton Christensen. The Innovator’s Dilemma. HarperBusiness. 2000. ISBN 0-066-62069-4.

El libro que introdujo el término “tecnología disruptiva”. Un examen fascinante y lúcido sobre cómo y por qué las compañías de tecnología que hacen todo correctamente quedan deshechas por principantes. Un libro de negocios que las personas técnicas deberían de leer.

–
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: www.torcasajuv.com
“Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos.” (San Agustín) Solamente asegúrate que en realidad sea AMOR…

Parte 3 de la historia de Unix

Historia de Unix (3ra parte)

Orígenes e Historia de los Hackers, 1969 – 1995

La tradición Unix es una cultura implícita que siempre ha llevado consigo más que una simple colección de trucos técnicos. Transmite un conjunto de valores sobre la belleza y el buen diseño; tiene leyendas y héroes folclóricos. Entrelazada con la historia de la tradición Unix se encuentra otra cultura implícita que es más difícil de etiquetar limpiamente. Tiene sus propios valores y leyendas y héroes folclóricos, a veces traslapándose con aquellos de la tradición Unix y a veces derivados de otras fuentes. Ha sido más comúnmente llamada la “cultura hacker”, y desde 1998 ha coincidido en su mayoría con lo que la prensa del comercio computacional llama “movimiento Open-Source” (Código Abierto).

Las relaciones entre la tradición Unix, la cultura hacker, y el movimiento open-source son sutiles y complejas. No quedan simplificadas por el hecho de que las tres culturas implícitas frecuentemente se han referido a los comportamientos de los mismos seres humanos. Pero desde 1990 la historia de Unix es en gran parte la historia de como los hackers de código abierto cambiaron las reglas y arrebataron la iniciativa a los vendedores Unix propietarios de la vieja escuela. Por lo tanto, la otra mitad de la historia detrás del Unix de hoy en día es la historia de los hackers.

Jugando en el recinto universitario: 1961 – 1980

Las raíces de la cultura hacker pueden rastrearse hacia 1961, el año en que MIT recibió su primera minicomputadora PDP-1. La PDP-1 fue una de las primeras computadoras interactivas, y (a diferencia de otras máquinas) en ese entonces suficientemente barata que el tiempo de uso en ella no tenía que ser rígidamente calendarizado. Atrajo la atención de un grupo de estudiantes curiosos del Tech Model Railroad Club (TMRC) que experimentaron con ella en un espíritu de diversión. Hackers: Heroes of the Computer Revolution [Levy] describe divertidamente los primeros días del club. Su más famoso logro fue SPACEWAR, un juego de cohetes espaciales que combaten inspirado por la serie de óperas espaciales Lensman de E. E. “Doc” Smith [18].

Muchos de los experimentadores del TMRC pasaron a convertirse en los miembros centrales del laboratorio de Inteligencia Artificial del MIT, que en los 60s y 70s se convirtió en uno de los centros mundiales de las ciencias de la computación más avanzadas. Tomaron algo del argot y las bromas internas del TMRC, incluyendo una tradición de unas bromas elaboradas (pero inofensivas) llamadas “hacks”. Parece ser que los programadores del laboratorio de IA del MIT fueron los primeros en auto-definirse como “hackers”.

Luego de 1969 el laboratorio de IA del MIT quedó conectado, vía la primera ARPANET, con otros laboratorios líderes en ciencias de la computación en Stanford, Bolt Beranek & Newman, la Universidad Carnegie-Mellon (CMU) entre otros. Investigadores y estudiantes tuvieron la primer probada de la forma en que un acceso rápido en red abolía geografías, a menudo haciendo que fuera más fácil colaborar y formar lazos de amistad con gente a la distancia en la red que con colegas que de otra forma estaban más cercanos pero menos conectados.

Software, ideas, argot, y una buena cantidad de humor fluyó por las ligas de la experimental ARPANET. Algo así como una cultura compartida comenzó a formarse. Una de sus creaciones más tempranas y más duraderas fue el Jargon File (el Archivo de la Jerga), una lista de términos de argot compartido que se originó en Stanford en 1973 y pasó por varias revisiones en MIT luego de 1976. En el camino acumuló argot de CMU, Yale, y otros sitios de la ARPANET.

Técnicamente, la primer cultura hacker estaba mayormente hospedada en minicomputadoras PDP-10. Usaban una variedad de sistemas operativos que hoy ya pasaron a la historia: TOPS-10, TOPS-20, Multics, ITS, SAIL. Programaban en ensamblador y dialectos de Lisp. Los hackers de las PDP-10 se responsabilizaron para mantener la ARPANET misma ya que nadie más quería el trabajo. Posteriormente, se convirtieron en el cuadro fundador de la Internet Engineering Task Force (IETF) y dieron origen a la tradición de estandarizaciones vía los Requests For Comments (RFCs).

Socialmente, eran jóvenes, excepcionalmente brillantes, en su gran mayoría varones, dedicados a programar hasta el punto de la adicción, y tendían a mostrarse fuertemente inconformes – lo que años después sería llamado ‘geeks’. Ellos, también, solían ser hippies greñudos e imitadores de hippies. Ellos, también, tenían la visión de las computadoras como dispositivos constructores de comunidades. Leían a Robert Heinlein y a J.R.R. Tolkien, jugaban en la Sociedad del Anacronismo Creativo, y tendían a tener una debilidad por los juegos de palabras [NT16]. A pesar de sus caprichos (¡o quizás debido a ellos!) muchos de ellos se encontraban dentro de los programadores más brillantes del mundo.

Ellos NO eran programadores Unix. La primer comunidad Unix salió en su mayoría del mismo grupo de geeks en la universidad y los laboratorios del gobierno o de investigación comercial, pero las dos culturas diferían de formas importantes. Una que ya hemos mencionado era la débil capacidad de estar en red del primer Unix. No hubo un acceso efectivo de Unix a la ARPANET hasta después de 1980, y era poco común que cualquiera tuviera puestos sus pies en ambos campos.

El desarrollo colaborativo y el compartir código fuente era una táctica valiosa para los programadores Unix. Para los primeros hackers de la ARPANET, por otro lado, era más que una táctica: era algo más parecido a una religión común, que en parte surgió de la imperativa académica de “publica o muere” y (en sus versiones más extremas) desarrollándose en un idealismo casi chardinista [NT17] sobre comunidades mentales conectadas en red. El más famoso de estos hackers, Richard M. Stallman, se convirtió en el santo asceta de esta religión.

Notas al pie de esta sección:
[18] SPACEWAR no estaba relacionado con el juego Space Travel de Ken Thompson, aparte del hecho de que ambos encontraban referencias con los fans de la ciencia ficción.

Referencias bibliográficas de esta sección:
[Levy] Steven Levy. Hackers: Heroes of the Computer Revolution. Anchor/Doubleday. 1984. ISBN 0-385-19195-2. Disponible en la Red.

Notas de traducción de esta sección:
[NT16] El original en inglés ‘pun’, se traduce como ‘calambur’, que es un juego de palabras que, basándose en la homonimia, en la paronimia o en la polisemia, consiste en modificar el significado de una palabra o frase agrupando de distinta forma sus sílabas. Por ejemplo: ‘plátano es/plata no es’ (http://es.wikipedia.org/wiki/Calambur). Dejé la traducción con un término más genérico, ‘juego de palabras’.

[NT17] Dejo el original en inglés porque, hasta ahora, no he hallado una traducción adecuada para el término original en inglés ‘chardinist’, del que no he encontrado muchas referencias, salvo las que me llevan de nuevo a escritos de Raymond sobre el mismo tema. Algo me hace pensar que es un término relacionado con la ciencia ficción, pero quien sabe…

Fusión con Internet y el Movimiento del Software Libre: 1981 – 1991

Luego de 1983 y el puerto de BSD para TCP/IP, las culturas de Unix y ARPANET comenzaron a fusionarse. Esto resultó ser lo más natural una vez que las ligas de comunicación estuvieron en su lugar, ya que ambas culturas se componían del mismo tipo de personas (de hecho, en pocos pero significativos casos por las mismas personas). Los hackers de ARPANET aprendieron C y comenzaron a usar el argot de tuberías, filtros, y shells; los programadores Unix aprendieron TCP/IP y comenzaron a llamarse “hackers” entre ellos. El proceso de fusión se aceleró luego de la cancelación del Proyecto Júpiter en 1983, que mató el futuro de la PDP-10. Para 1987 ambas culturas se habían mezclado tan bien que la mayoría de los hackers programaban en C y utilizaban de forma casual términos del argot que se remontaban al Tech Model Railroad Club de veinticinco años atrás.

(En 1979 yo era extraño al tener fuertes lazos con las dos culturas Unix y ARPANET. En 1985 eso ya no resultaba extraño. Para el momento en que expandí el antiguo Archivo de la Jerga de ARPANET en el Nuevo Diccionario Hacker [Raymond96], ambas culturas se habían fusionado eficazmente. El Archivo de la Jerga, nacido en ARPANET pero revisado en Usenet, simbolizaba de manera apta la fusión.)

Pero las redes TCP/IP y el argot no fueron las únicas cosas que la cultura hacker posterior a 1980 heredó de sus raíces en ARPANET. También obtuvo a Richard Stallman, y la cruzada moral de Stallman.

Richard M. Stallman (comúnmente conocido por su nombre de usuario, RMS) ya había demostrado a fines de los 70s que él era uno de los más hábiles programadores en vida. Entre sus muchas invenciones estaba el editor Emacs. Para RMS, la cancelación del Proyecto Júpiter en 1983 sólo dio por terminada la desintegración del laboratorio de IA del MIT que había comenzado unos años atrás conforme muchos de sus mejores elementos se fueron a trabajar para compañías de máquinas Lisp en competencia. RMS se sintió expulsado del Edén hacker, y decidió que la culpa era del software propietario.

En 1983 Stallman fundó el proyecto GNU, con el objetivo de escribir un sistema operativo completamente libre. A pesar de que Stallman no era y nunca fue un programador Unix, bajo las condiciones posteriores a 1980 el implementar un sistema operativo estilo Unix era la más obvia estrategia a perseguir. Muchos de los primeros colaboradores de RMS eran hackers de la vieja ARPANET que acababan de llegar a las tierras de Unix, en los que la ética del compartir código fuente era más fuerte que como lo hacía en los de historia más centrada en Unix.

En 1985, RMS publicó el Manifiesto GNU. En él, creó conscientemente una ideología a partir de los valores de los hackers de la ARPANET previos a 1980 – con todo y un nuevo reclamo ético-político, un discurso autónomo y característico, y un plan activista para el cambio. El objetivo de RMS era aunar la difusa comunidad de hackers posteriores a 1980 en una máquina social coherente para lograr un único propósito revolucionario. Su comportamiento y su retórica a medias recordaban los intentos de Karl Marx de movilizar al proletariado industrial contra la alienación de su trabajo.

El manifiesto de RMS inició un debate que aún se mantiene vivo en la cultura hacker de hoy en día. Su programa iba más allá de mantener una base de código fuente, y esencialmente implicaba la abolición de los derechos de propiedad intelectual en el software. Persiguiendo este objetivo, RMS popularizó el término “software libre”, que fue un primer intento de etiquetar al producto de toda la cultura hacker. Escribió la Licencia Pública General (GPL, por sus siglas en inglés), que se convertiría tanto en un punto de reunión como en foco de gran controversia, por razones que examinaremos en el Capítulo 16. Pueden aprender más de la postura de RMS y de la Free Software Foundation en el sitio web de GNU.

El término “software libre” era en parte una descripción y en parte un intento de definir la identidad cultural de los hackers. Desde cierto punto, fue bastante exitoso. Antes de RMS, la gente en la cultura hacker se reconocía a sí misma como compañeros de viaje que usaban el mismo argot, pero nadie se preocupaba por discutir sobre lo que un ‘hacker’ es o debe de ser. Luego de él, la cultura hacker se volvió mucho más consciente de sí misma; las discusiones de valores (muchas veces encuadradas con el lenguaje de RMS, usado incluso por aquellos que se oponían a sus conclusiones) se volvieron un tema normal de debate. El mismo RMS, una figura carismática y polarizadora, se convirtió de tal forma en un héroe cultural que para el año 2000 era difícil distinguirlo de su propia leyenda. Free as in Freedom [Williams] nos da un excelente retrato.

Los argumentos de RMS incluso influenciaron el comportamiento de muchos hackers que se mantenían escépticos a sus teorías. En 1987, convenció a los encargados de mantener Unix BSD de que sería una buena idea limpiarlo de código propietario de AT&T para poder lanzar una versión sin cargos de licencia. Sin embargo, a pesar de sus esfuerzos determinados por más de quince años, la cultura hacker posterior a 1980 nunca se unificó alrededor de su visión ideológica.

Otros hackers iban descubriendo el desarrollo abierto, colaborativo, y sin secretos por razones más pragmáticas y menos ideológicas. Unos edificios más allá de la oficina de Richard Stallman en el noveno piso en MIT, el equipo de desarrollo de X prosperaba a finales de los 80s. Fue fundado por vendedores Unix que habían acordado un empate sobre el control y los derechos de propiedad intelectual del sistema gráfico X, y no encontraron mejor alternativa que dejarlo libre para todos. En 1987-1988 el desarrollo de X prefiguraba las comunidades distribuidas realmente grandes que redefinirían lo más avanzado de Unix cinco años después.

“X fue uno de los primeros proyectos de código abierto a gran escala desarrollado por un equipo dispar de individuos trabajando para diferentes organizaciones diseminadas alrededor del globo. El e-mail permitía que las ideas se movieran rápidamente entre el grupo de manera que los pendientes pudieran resolverse tan rápido como fuera necesario, y cada individuo podía contribuir con la capacidad que más le viniera. Las actualizaciones del software podían distribuirse en cuestión de horas, habilitando a cada sitio para actuar de manera concertada durante el desarrollo. La red cambió la forma en que el software podía desarrollarse.”
— Keith Packard –

Los desarrolladores de X no eran partidarios del plan maestro de GNU, pero no estaban abiertamente opuestos a él tampoco. Antes de 1995 la oposición más seria al plan de GNU venía de los desarrolladores de BSD. La gente de BSD, que recordaban haber estado escribiendo software libremente redistribuible y modificable años antes del manifiesto de RMS, rechazaron el reclamo de GNU de la primacía histórica e ideológica. En específico objetaban la propiedad infecciosa o “viral” de la GPL, manteniendo que la licencia BSD era “más libre” por establecer menos restricciones en la reutilización del código.

No fue de ayuda para RMS que, aunque la Free Software Foundation había producido la mayoría del resto de un completo juego de herramientas de software, no podía entregar la pieza central. Diez años después de la fundación del proyecto GNU, aún no había kernel GNU. Mientras que herramientas individuales como Emacs y GCC demostraron ser tremendamente útiles, GNU sin un kernel ni amenazaba la hegemonía de los Unixes propietarios ni ofrecía un contraataque efectivo contra el creciente problema del monopolio Microsoft.

Luego de 1995 el debate sobre la ideología de RMS tomó un punto de vista algo diferente. La oposición vendría a asociarse de manera cercana tanto con Linus Torvalds como con el autor de este libro.

Referencias bibliográficas de esta sección:
[Raymond96] Eric S. Raymond. The New Hacker’s Dictionary. 3rd Edition. 1996. ISBN 0-262-68092-0. MIT Press. 547pp. Disponible en la Red en la Jargon File Resource Page.

[Williams] Sam Williams. Free as in Freedom. O’Reilly & Associates. 2002. ISBN 0-596-00287-4. Disponible en la Red.

Linux y la Reacción Pragmática: 1991 – 1998

Mientras que el esfuerzo de HURD (el kernel GNU) se atascaba, se abrían nuevas posibilidades. A inicios de los 90s la combinación de PCs baratas y poderosas con acceso a Internet fácil dio un señuelo poderoso para una nueva generación de programadores jóvenes que buscaban retos en donde probar su coraje. El juego de herramientas en el espacio de usuario escritas por la Free Software Foundation sugería una manera que era libre del alto costo de las herramientas de desarrollo de software propietarias. La ideología siguió a la economía en lugar de ir por delante; algunos de los recién llegados se alinearon con la cruzada de RMS y adoptaron la GPL como su estandarte, y otros se identificaron más con la tradición Unix en su totalidad y se unieron al campo anti-GPL, pero muchos desecharon la discusión como una distracción y solamente escribieron código.

Linus Torvalds le dio la vuelta limpiamente a la división GPL/anti-GPL usando el juego de herramientas GNU para rodear el kernel Linux que había inventado y las propiedades infecciosas de la GPL para protegerlo, pero rechazando el programa ideológico que iba con la licencia de RMS. Torvalds afirmó que pensaba que el software libre es mejor en general pero que ocasionalmente utilizaba programas propietarios. Su rechazo a ser un zelote incluso dentro de su misma causa lo hicieron tremendamente atractivo para la mayoría de hackers que habían estado incómodos con la retórica de RMS, pero cuyos argumentos carecían de un punto o de un portavoz convincente para su escepticismo.

El pragmatismo alegre de Torvalds y su estilo adepto pero discreto catalizó una impresionante sucesión de victorias para la cultura hacker en los años 1993-1997, incluyendo no solamente éxitos técnicos sino los comienzos sólidos de una industria de distribución, servicio y soporte alrededor del sistema operativo Linux. Como resultado su prestigio y su influencia se fueron a las nubes. Torvalds se convirtió en un héroe en la época de Internet; para 1995, había logrado en tan solo cuatro años el tipo de eminencia a nivel cultural que a RMS le tomó quince años en ganar – y excedió por mucho el récord de Stallman vendiendo “software libre” al mundo exterior. En contraste con Torvalds, la retórica de RMS comenzaba a parecer tanto estridente como poco exitosa.

Entre 1991 y 1995 Linux pasó de un concepto de pruebas alrededor del kernel prototipo 0.1 a un sistema operativo que podía competir en características y desempeño con los Unixes propietarios, y venció a la mayoría en estadísticas importantes como tiempo en continua ejecución, sin necesidad de reiniciar el sistema. En 1995, Linux halló su “killer app”: Apache, el servidor web de código abierto. Como Linux, Apache demostró ser destacadamente estable y eficiente. Las máquinas Linux ejecutando Apache rápidamente se convirtieron en la plataforma elegida por los ISPs alrededor del mundo; Apache capturó alrededor de 60% de los sitios web [19], prácticamente venciendo a sus dos mayores competidores propietarios.

La única cosa que Torvalds no ofrecía era una nueva ideología – un nuevo razonamiento o mito fundador del hacking, y un discurso positivo para sustituir la hostilidad de RMS a la propiedad intelectual con un programa más atractivo para la gente tanto dentro como fuera de la cultura hacker. Inadvertidamente yo proveí a esta falta en 1997 como resultado del intento por entender el por qué el desarrollo de Linux no se había colapsado en la confusión años antes. Las conclusiones técnicas de mis escritos publicados [Raymond01] serán resumidos en el Capítulo 19. Para este esquema histórico, será suficiente con notar el impacto de la fórmula central del primero de ellos: “Dado un número suficientemente grande de ojos, todos los bugs [NT18] son bajos”.

Esta observación implicaba algo que nadie en la cultura hacker se había atrevido a creer realmente durante el anterior cuarto de siglo: que sus métodos podían confiablemente producir software que no sólo fuera más elegante sino más confiable y mejor que el código de nuestros competidores propietarios. Esta consecuencia, bastante inesperadamente, terminó presentando exactamente el reto directo al discurso del “software libre” que Torvalds mismo no estaba interesado en montar. Para muchos hackers y la mayoría de los no hackers, “Software libre porque funciona mejor” fácilmente venció a “Software libre porque el software debe de ser libre”.

En el escrito, el contaste entre los modelos de desarrollo de ‘catedral’ (centralizado, cerrado, controlado, secretivo) y el de ‘bazar’ (desorganizado, abierto, con revisión por pares intensa) se convirtió en la metáfora central del nuevo pensamiento. En un sentido importante ésto era un mero retorno a las raíces del Unix anterior a la diversificación – es continua con las observaciones en 1991 de McIlroy sobre los efectos positivos de la presión entre colegas en el desarrollo de Unix de principios de los 70s y con las reflexiones en 1979 de Dennis Ritchie sobre comunidad, fertilizada con la tradición académica de la primera ARPANET de la revisión por pares y con su idealismo sobre las comunidades mentales distribuidas en red.

A principios de 1998, el nuevo pensamiento ayudó a motivar a Netscape Communications para liberar el código fuente de su navegador Mozilla. La atención que puso la prensa alrededor de este evento llevó a Linux a Wall Street, ayudó a impulsar el auge de las acciones en tecnología de 1999-2000, y demostró ser un punto crucial tanto para la historia de la cultura hacker como de Unix.

Notas al pie de esta sección:
[19] Diagramas de cómo se reparten los servidores web, actual e históricamente, están disponibles mensualmente en el Netcraft Web Server Survey.

Referencias bibliográficas de esta sección:
[Raymond01] Eric S. Raymond. The Cathedral and the Bazaar. 2nd Edition. 1999. ISBN 0-596-00131-2. O’Reilly & Associates. 240pp

Notas de traducción de esta sección:
[NT18] En el original en inglés, ‘bug‘ se refiere (según el Jargon File) a una propiedad no deseada y no intencional de un programa o pieza de hardware, especialmente una que causa su mal funcionamiento. Dejé el término en inglés por ser común en el uso en español, aunque puede traducirse libremente como ‘error’ o ‘defecto’. Según la leyenda, el origen del término data de cuando la Mark II, computadora sucesora de la Mark I, construida en 1944, sufrió un fallo en un relevador electromagnético. Cuando se investigó ese dispositivo, se encontró una polilla que provocó que el relevador quedara abierto.

–
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: www.torcasajuv.com
“Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos.” (San Agustín) Solamente asegúrate que en realidad sea AMOR…

Continuamos con la historia de Unix, parte 2.
Cabe mencionar que el libro ‘The Art of Unix Programming’ está repleto de citas de varias personas involucradas con Unix y su historia. Eric S. Raymond contactó con estas personas para que le dieran su opinión y revisaran el texto que estaba escribiendo, pero en vez de integrar sus opiniones en el mismo texto, decidió en gran medida dejar las citas textuales de las opiniones de estas personalidades en su libro. De esta manera, TAOUP se convierte también en una especie de testimonio de estas personas involucradas directamente con Unix…

Historia de Unix (2da parte)

Éxodo: 1971 – 1980

El sistema operativo Unix original estaba escrito en lenguaje ensamblador, y las aplicaciones en una mezcla de ensamblador y un lenguaje interpretado llamado B, que tenía la virtud de ser lo suficientemente pequeño para correr en la PDP-7. Pero B no era lo suficientemente poderoso para programación de sistemas, así que Dennis Ritchie le agregó tipos de datos y estructuras. El lenguaje C resultante evolucionó a partir del B a comienzos de 1971; en 1973 Thompson y Ritchie finalmente consiguieron reescribir Unix en su nuevo lenguaje. Esto fue un movimiento muy audaz; en esa época, la programación de sistemas se hacía en ensamblador para así extraer el máximo desempeño del hardware, y el concepto de un sistema operativo portable apenas resultaba difícil de creer [NT7]. En un tiempo tan tardío como 1979, Ritchie aún escribió: “Parece cierto que gran parte del éxito de Unix viene dado por su legibilidad, modificabilidad, y portabilidad de su software, que a su vez viene dada por estar expresado en lenguajes de alto nivel”, a sabiendas de que este era un punto que aún había que remarcar.

[Ken (sentado) y Dennis (de pie) ante una PDP-11 en 1972]

Un artículo en la revista Communications of the ACM [Ritchie-Thompson] le dio a Unix su primer vistazo público. En él, los autores describen el diseño simple sin precedentes de Unix, reportando unas 600 instalaciones del sistema. Todas eran en máquinas consideradas de baja potencia para los estándares de la época, pero (tal como escriben Ritchie y Thompson) “las restricciones han motivado no solamente la economía, sino también cierta elegancia en el diseño”.

Luego del artículo en la CACM, laboratorios de investigación y universidades por todo el mundo clamaban por poder probar Unix. Luego de un decreto de consentimiento en 1958, como resolución de un caso de competencia desleal, a AT&T (la organización padre de los Laboratorios Bell) le quedó prohibido el entrar al negocio de las computadoras. Por lo tanto, Unix no podía ser convertido en un producto; de hecho, bajo los términos del decreto de consentimiento, los Laboratorios Bell estaban obligados a ceder licencia de cualquier tecnología no telefónica que produjeran a quien se los solicitara. Ken Thompson comenzó entonces a responder calladamente a las solicitudes enviando cintas y paquetes de discos – todos, de acuerdo con la leyenda, acompañados con una nota firmada “love, ken” (‘con amor, ken’).

Esto sucedió años antes de las computadoras personales. No solamente el hardware necesario para correr Unix era muy caro como para caber en las posibilidades de cualquiera, sino que nadie imaginaba también que eso cambiaría en el futuro cercano. Así que las máquinas Unix sólo estaban disponibles por la gracia de grandes organizaciones con grandes presupuestos: corporaciones, universidades, agencias gubernamentales. Pero el uso de las minicomputadoras era menos regulado que el de los mainframes, aún más grandes, y el desarrollo de Unix rápidamente tomó un aire de contra-cultura. Era el principio de los 70s; los pioneros de la programación en Unix eran hippies peludos e imitadores de hippies. Se entretenían jugando con un sistema operativo que no solamente les ofrecía retos fascinantes en la punta de lanza de las ciencias de la computación, sino que además derribaba todas las presuposiciones técnicas y las prácticas de negocio que iban con el Gran Cómputo. Tarjetas perforadas, COBOL, suites de negocio, y mainframes por lotes IBM fueron calificados como la vieja escuela; los hackers de Unix se rebelaron en el sentido de que fueron simultáneamente construyendo el futuro y enseñando el dedo medio al sistema.

La emoción de aquellos días fue captada en una cita de Douglas Comer: “Muchas universidades contribuyeron a UNIX. En la universidad de Toronto, el departamento adquirió una impresora/plotter de 200 ppp (puntos por pulgada) y construyó un software que usaba la impresora para simular una fotocomponedora [NT8]. En la Universidad de Yale, los estudiantes y los científicos de la computación modificaron el shell de UNIX. En la Universidad Purdue, el Departamento de Ingeniería Eléctrica logró grandes avances en el desempeño, generando una versión de UNIX que soportaba un gran número de usuarios. En Purdue también se desarrolló una de las primeras redes de computadoras UNIX. En la Universidad de California en Berkeley, los estudiantes desarrollaron un nuevo shell y docenas de nuevas utilidades más pequeñas. Para fines de los 70s, cuando los Laboratorios Bell lanzaron UNIX Version 7, era claro que el sistema resolvía los problemas computacionales de muchos departamentos, y que incorporaba muchas de las ideas que habían surgido en las universidades. El resultado neto final fue un sistema fortalecido. Una ola de ideas comenzaron un nuevo ciclo, fluyendo desde la academia hacia el laboratorio industrial, de regreso a la academia, y finalmente logrando llegar a un creciente número de sitios comerciales”. [Comer]

El primer Unix del que podría decirse que esencialmente puede ser totalmente reconocido por un programador moderno de Unix fue la Version 7 lanzada en 1979 [15]. El primer grupo de usuarios de Unix se formó apenas el año anterior. Para esta época Unix era usado para soporte de operaciones en todos los Laboratorios Bell [Hauben], y se había propagado a universidades tan lejanas como las de Australia, en donde las notas de John Lions en 1976 [Lions] del código fuente de la Version 6 se convirtieron en la primer documentación seria del funcionamiento interno del núcleo (kernel) de Unix. Muchos hackers mayores de Unix aún atesoran una copia.

“El Lions fue una sensación en la publicación samizdat [NT9]. Debido a violaciones en el copyright u otra cosa no podía ser publicado en E.U., así que copias de copias se filtraban por doquier. Yo aún conservo mi copia, que era al menos de 6ta generación. En ese entonces no se podía ser un hacker del kernel sin un Lions.”
— Ken Arnold –

Los inicios de una industria Unix se estaban uniendo también. La primer compañía Unix (la Santa Cruz Operation, SCO) comenzó a funcionar en 1978, y el primer compilador de C comercial (Whitesmiths) fue vendido ese mismo año. Para 1980 una obscura compañía de Seattle también se estaba metiendo al juego en Unix, migrando una versión del Unix de AT&T a microcomputadoras, llamada XENIX. Pero el afecto de Microsoft por Unix como un producto no duraría mucho (aunque Unix seguiría siendo usado para el trabajo de desarrollo interno en la compañía hasta 1990).

Notas al pie de esta sección:
[15] Los manuales de la Version 7 pueden verse en línea en http://plan9.bell-labs.com/7thEdMan/index.html.

Referencias bibliográficas de esta sección:
[Ritchie-Thompson] The Unix Time-Sharing System. Dennis M. Ritchie and Ken Thompson. Disponible en la Red.

[Comer] Unix Review. Douglas Comer. “Pervasive Unix: Cause for Celebration”. October 1985. p.42.

[Hauben] Ronda Hauben. History of UNIX. Disponible en la Red.

[Lions] John Lions. Lions’s Commentary on Unix 6th Edition. 1996. 1-57398-013-7. Peer-To-Peer Communications. Render PostScript de las copias originales del Lions en la Red. Esta URL puede ser inestable.

Notas de traducción de esta sección:
[NT7] La expresión ‘was barely a gleam in anyone\’s eye’, lit. ‘era apenas un brillo en el ojo de cualquiera’, quedó como ‘apenas resultaba difícil de creer’, pues la traducción literal de la frase original en inglés no me sonaba tan adecuada.

[NT8] En el original, ‘phototypesetter’, se refiere a una máquina de fotocomposición tipográfica que utilizaba papel fotográfico para las impresiones de textos. Hoy en día es una técnica obsoleta, por el advenimiento de las computadoras personales y el software de autoedición (http://en.wikipedia.org/wiki/Phototypesetting).

[NT9] de la Wikipedia en español: Samizdat (auto-publicado, en ruso) era una práctica en tiempos de la Unión Soviética destinada a burlar la censura impuesta por los gobiernos de los partidos comunistas en los países del Bloque oriental. Mediante esta práctica, individuos y grupos de personas copiaban y distribuían clandestinamente libros y otros bienes culturales que habían sido proscritos por el gobierno. La idea era hacer unas pocas copias cada vez y que cada persona que tuviese acceso a un medio de copiado hiciera más copias. (http://es.wikipedia.org/wiki/Samizdat) Existe una entrada para ’samizdat’ en el Jargon File (http://www.catb.org/~esr//jargon/html/S/samizdat.html)

TCP/IP y las Guerras Unix: 1980 – 1990

El campus en Berkeley de la Universidad de California surgió desde el principio como el punto académico más importante en el desarrollo de Unix. La investigación en Unix comenzó ahí en 1974, y tuvo un gran ímpetu cuando Ken Thompson impartió clases en la Universidad durante un año sabático de 1975-76. El primer lanzamiento del BSD fue en 1977 por parte de un laboratorio dirigido por un entonces desconocido estudiante graduado llamado Bill Joy. Para 1980 Berkeley era el eje de una sub-red de universidades que contribuían activamente a esa variante de Unix. Las ideas y el código del Unix de Berkeley (incluyendo el editor vi(1)) se retro-alimentaban de Berkeley a los Laboratorios Bell.

Luego, en 1980, la Agencia de Investigación de Proyectos Avanzados de Defensa (Defense Advanced Research Projects Agency, DARPA), necesitaba de un equipo de trabajo para implementar su novel paquete de protocolos TCP/IP en una máquina VAX sobre un sistema Unix. Las PDP-10s que soportaban la ARPANET en esos tiempos se estaban volviendo viejas, y ya se rumoreaba que DEC se vería forzada a cancelar la PDP-10 para soportar la VAX. DARPA consideró contratar a DEC para implementar el TCP/IP, pero rechazó la idea porque les preocupaba que DEC no respondiera positivamente a sus solicitudes de cambio en su sistema operativo propietario VAX/VMS [Libes-Ressler]. En vez de ello, DARPA eligió el Unix de Berkeley como plataforma – explícitamente debido a que el código fuente estaba disponible y sin recargos por licencia [Leonard].

El Grupo de Investigación en Ciencias de la Computación de Berkeley estaba en el lugar y momento adecuados, con las herramientas de desarrollo más potentes; el resultado se convirtió, discutiblemente, en el momento más crucial en la historia de Unix desde su invención.

Hasta que la implementación de TCP/IP fue lanzada con la versión 4.2 de Berkeley en 1983, Unix tenía el soporte para red más débil. Los primeros experimentos con Ethernet fueron insatisfactorios. Una facilidad fea pero útil llamada UUCP (Unix to Unix Copy Program, Programa para Copiar de Unix a Unix) fue desarrollada por los Laboratorios Bell para distribuir software sobre lineas telefónicas convencionales vía módem [16]. UUCP podía enviar correo entre máquinas ampliamente separadas, y (luego de la invención de Usenet en 1981) soportaba Usenet, una facilidad de boletín informativo distribuido que permitió a sus usuarios difundir mensajes de texto a cualquier lugar con líneas telefónicas y sistemas Unix.

Aún así, los pocos usuarios de Unix enterados de los brillos de la ARPANET se sentían atorados en un remanso. Sin FTP, sin telnet, con ejecución remota de procesos muy restringida, y enlaces dolorosamente lentos. Antes de TCP/IP, las culturas de Internet y Unix no se mezclaban. La visión de Dennis Ritchie sobre las computadoras como un medio para “favorecer la comunicación cercana” era sobre comunidades colegiales conglomeradas alrededor de máquinas de tiempo compartido individuales o dentro del mismo centro de cómputo; no se extendía a la “red nacional” distribuida por todo el continente que los usuarios de ARPA comenzaron a formar a mediados de los 70s. Los primeros ARPANETeros, por su parte, consideraban Unix como una cruda improvisación que cojeaba sobre hardware risiblemente débil.

Luego de TCP/IP, todo cambió. Las culturas de ARPANET y Unix comenzaron a mezclarse en sus bordes, y este desenvolvimiento eventualmente salvaría a ambas de su destrucción. Pero antes debían de pagarlo muy caro, como resultado de dos desastres no relacionados: el surgimiento de Microsoft y la orden de venta en AT&T.

En 1981, Microsoft logró su histórico trato con IBM sobre la nueva IBM PC. Bill Gates compró QDOS (Quick and Dirty Operating System), un clon de CP/M cuyo programador Tim Paterson había desechado en seis semanas, a Seattle Computer Products, los patrones de Paterson. Gates, disimulando el trato con IBM a Paterson y SCP, compró los derechos por $50,000 USD. Después convenció a IBM para permitirle a Microsoft comercializar MS-DOS de forma separada al hardware de la PC. Durante la siguiente década, el impulsar código que no había escrito él mismo hizo de Bill Gates un multimillonario, y tácticas de negocio aún más astutas que el trato original le dieron a Microsoft un monopolio cerrado en el área del cómputo de escritorio. XENIX como producto fue rápidamente tomado a menos [NT11], y eventualmente vendido a SCO.

En ese tiempo no era aparente qué tan exitosa (o qué tan destructiva) se iba a convertir Microsoft. Ya que la IBM PC-1 no tenía un hardware capaz de ejecutar Unix, la gente de Unix apenas y se percató de ella (aunque, irónicamente, DOS 2.0 eclipsó a CP/M en gran parte debido a que el co-fundador de Microsoft, Paul Allen, le agregó características Unix como subdirectorios y tuberías). Sucedían entonces cosas que parecían mucho más interesantes – como el lanzamiento en 1982 de Sun Microsystems.

Los fundadores de Sun Microsystems, Bill Joy, Andreas Bechtolsheim y Vinod Khosla, emprendieron juntos para construir la máquina Unix de sus sueños con capacidades de red ya pre-construidas en ella. Combinaron hardware diseñado en Stanford con el Unix desarrollado en Berkeley para producir un éxito demoledor, y así fundaron la industria de las workstations (estaciones de trabajo). En ese entonces, a nadie le importaba mucho el ver como el acceso al código fuente de una rama del árbol familiar de Unix gradualmente disminuía conforme Sun empezaba a comportarse menos como una empresa despreocupada y más como una firma convencional. Berkeley aún distribuía el código fuente de BSD. Oficialmente, las licencias del código fuente del System III costaban $40,000 USD cada una; pero los Laboratorios Bell se hacían los ciegos ante el número de cintas contrabandeadas en circulación, las universidades aún intercambiaban código con los Laboratorios Bell, y parecía que la comercialización de Unix por parte de Sun no era sino la mejor cosa que le podría haber sucedido a Unix hasta entonces.

1982 también fue el año en que el lenguaje C mostró signos de establecerse fuera del mundo Unix como el lenguaje para programación de sistemas. Sólo le tomaría unos cinco años a C para desplazar fuera de uso a los lenguajes ensambladores. Para principios de los años 90s, C y C++ dominarían no solamente la programación de sistemas sino también la de aplicaciones; para fines de los 90s cualquiera otros lenguajes compilados convencionales quedarían efectivamente obsoletos.

Cuando DEC canceló el desarrollo de la máquina sucesora de la PDP-10 (Jupiter) en 1983, las VAXes ejecutando Unix comenzaron a dominar como las máquinas de Internet, un puesto que mantendrían hasta ser desplazadas por las estaciones de trabajo de Sun. Para 1985, cerca del 25% de todas las VAXes ejecutarían Unix a pesar de la dura oposición de DEC. Pero el efecto a largo plazo de la cancelación de la Jupiter fue menos obvio; la muerte de la cultura hacker centrada en la PDP-10 del Laboratorio de Inteligencia Artificial del MIT motivó a un programador llamado Richard Stallman a comenzar a escribir GNU, un clon completamente libre de Unix.

Para 1983 había no menos de seis sistemas operativos estilo Unix para la IBM-PC: uNETix, Venix, Coherent, QNX, Idris y la migración alojada en la tarjeta hija Sritek PC. Aún no se había migrado Unix ni en su versión System V ni en BSD; ambos grupos consideraban al microprocesador 8086 lamentablemente infra-potente y ni siquiera se le acercaban. Ninguno de los sistemas estilo Unix fueron éxitos comerciales significativos, pero sí indicaban una demanda de Unix en hardware barato que los grandes vendedores no estaban abasteciendo. Y ningún individuo podía costearlo por sí mismo tampoco, no con el precio de $40,000 USD en una licencia del código fuente.

Sun ya era un éxito (¡con sus imitadores!) cuando, en 1983, el Departamento de Justicia de los E.U. ganó su segundo caso de competencia desleal contra AT&T y quebró al Sistema Bell. Esto liberó a AT&T del decreto de consentimiento de 1958 por el que se le prohibía convertir a Unix en un producto. Así que AT&T más pronto que tarde corrió a comercializar el Unix System V – un movimiento que por poco mata a Unix.

“Tan cierto. Pero su mercadotecnia promovió internacionalmente a Unix.”
— Ken Thompson –

Muchos de los promotores de Unix pensaron que la venta eran buenas noticias. Pensábamos que en la AT&T de después de la venta, en Sun Microsystems y en los pequeños imitadores de Sun se veía el núcleo de una industria sana de Unix – una que, usando estaciones de trabajo baratas y basadas en el 68000, podría competir y eventualmente romper con el opresivo monopolio que en ese entonces recaía sobre la industria de la computación – el de IBM.

Lo que ninguno de nosotros nos dimos cuenta en ese entonces fue que el hacer de Unix un producto destruiría los intercambios libres de código fuente que habían nutrido tanto al sistema en su vitalidad temprana. Sin conocer otro modelo que el secreto para acumular beneficios del software y ningún otro modelo que el control centralizado para desarrollar un producto comercial, AT&T le pegó duro a la distribución del código fuente. Las cintas promocionales de Unix se volvieron muy poco interesantes a sabiendas de que una demanda legal podía venir con ellas. Las contribuciones de las universidades comenzaron a disminuir.

Para empeorar las cosas, los nuevos grandes jugadores en el mercado Unix comenzaron a cometer grandes errores estratégicos. Uno fue el buscar la delantera a través de la diferenciación de su producto – una táctica que resultó en la divergencia de las interfaces entre los distintos Unixes. Esto echó por la borda la compatibilidad inter-plataformas y fragmentó el mercado de Unix.

El otro, más sutil error, fue comportarse como si las computadoras personales y Microsoft fueran irrelevantes desde la perspectiva de Unix. Sun Microsystems falló en ver que las PCs vistas como materia prima inevitablemente se convertirían en un ataque desde abajo al mercado de sus estaciones de trabajo. AT&T, fijada en sus minicomputadoras y mainframes, intentó varias diferentes estrategias para convertirse en el jugador mayor de las computadoras, y malamente remendó todas ellas. Una docena de pequeñas compañías se alinearon para soportar Unix en las PCs; todas tenían pocos fondos, enfocadas en vender a los desarrolladores e ingenieros, y nunca apuntaron al mercado de oficina y hogar al que Microsoft apuntaba.

De hecho, por años luego de la venta, la comunidad Unix estaba más preocupada aún con la primera fase de las guerras Unix – una disputa interna, la rivalidad entre el Unix System V y el Unix BSD. La disputa tuvo varios niveles, algunos técnicos (sockets vs. streams, tty de BSD vs. termio de System V) y otros culturales. La división estaba de manera general entre los de cabello largo y los de cabello corto; programadores y técnicos solían alinearse con Berkeley y BSD, los más orientados a los negocios con AT&T y System V. Los de cabello largo, repitiendo un esquema de los primeros días de Unix diez años antes, gustaban de verse a sí mismos como rebeldes contra el imperio corporativo; una de las pequeñas compañías publicó un póster que mostraba una nave de combate espacial estilo X-wing con la marca “BSD” huyendo de una gigante “estrella de la muerte” con la forma del logotipo de AT&T en llamas. Así tocábamos la lira mientras Roma ardía.

Pero algo más pasó el año de la venta en AT&T que tendría mayor importancia a largo plazo para Unix. Un programador/lingüista llamado Larry Wall calladamente inventó la utilidad patch(1). El programa patch es una simple herramienta que aplica los archivos de cambios generados por diff(1) sobre un archivo base, lo que significaba que los desarrolladores Unix podían cooperar entre sí pasándose conjuntos de parches – cambios incrementales al código – en vez de archivos de código enteros. Esto fue importante no solamente porque los parches estorban menos que los archivos completos, sino porque los parches seguido se aplican limpiamente, incluso si gran parte del archivo base ha cambiado desde que quien envió el parche hizo su copia del archivo base. Con esta herramienta, distintas corrientes de desarrollo a partir de un código fuente común pueden divergir, ir en paralelo, y reconvergir. El programa patch hacía más que cualquier otra herramienta por sí sola para habilitar el desarrollo colaborativo en Internet – un método que revitalizaría a Unix luego de 1990.

En 1985 Intel lanzó su primer chip 386, capaz de direccionar 6 giga bytes de memoria con un espacio plano de direcciones. El torpe direccionamiento de segmentos del 8086 y del 286 se volvieron inmediatamente obsoletos. Esto eran grandes noticias, porque significaba que por primera vez, un microprocesador en la dominante familia Intel tenía la capacidad de ejecutar Unix sin compromisos dolorosos. El presagio estaba a la vista [NT12] para Sun y los otros fabricantes de estaciones de trabajo. Y ellos no pudieron verlo.

1985 también fue el año en que Richard Stallman publicó el manifiesto GNU [Stallman] y lanzó la Free Software Foundation. Muy poca gente lo tomó a él o a su proyecto GNU seriamente, un punto de vista que resultó estar seriamente equivocado. Sin tener relación alguna ese mismo año, los creadores del sistema X window lanzaron su código fuente sin exigir derechos, restricciones o licenciar el código. Como resultado directo de esta decisión, se convirtió en un área neutral y segura para la colaboración entre los vendedores de Unix, y venció a los competidores de software propietario para convertirse en el motor gráfico de Unix.

Esfuerzos serios de estandarización comenzaron en 1983 tratando de reconciliar las APIs del System V y Berkeley con el estándar /usr/group. Lo siguieron en 1985 los estándares POSIX, un esfuerzo respaldado por la IEEE. Éstos estándares describen la intersección entre las llamadas de BSD y SVR3 (System V Release 3), con el manejo de señales y control de tareas superiores de Berkeley pero el control de terminal de SVR3. Todos los posteriores estándares Unix incorporarían POSIX en su núcleo, y los Unixes posteriores se adherirían a éste de forma muy cercana. La única mayor adición a la API del núcleo de Unix que vendría después serían los sockets de BSD.

En 1986 Larry Wall, el inventor de patch(1), comenzó a trabajar en Perl, que se convertiría en el primero y mayoritariamente usado de los lenguajes de script de código abierto. A principios de 1987 apareció la primera versión del GNU C compiler (GCC, compilador C de GNU) y para finales de ese año el núcleo del conjunto de herramientas GNU estaba quedando en su lugar: editor, compilador, depurador, y otras herramientas básicas de desarrollo. Mientras tanto, el sistema X window comenzaba a utilizarse en estaciones de trabajo relativamente baratas. Juntas, estas herramientas proveerían la armadura de los desarrollos Unix de código abierto de los 90s.

1986 también fue el año en que la tecnología PC quedó libre de las garras de IBM. IBM, tratando aún de preservar la curva del precio vs. potencia entre su línea de productos para favorecer su negocio de mainframes de alto margen, rechazó el 386 para sus computadoras de la nueva línea PS/2 en favor del más débil 286. La serie PS/2, diseñada alrededor de una arquitectura de bus propietaria para cerrarle el paso a los fabricantes de clones, se convirtió en un fracaso colosalmente caro [17]. Compaq, el más agresivo de los fabricantes de clones, aprovechó la movida de IBM sacando al mercado la primera máquina 386. Incluso con una velocidad de reloj de apenas 16 MHz, la 386 hacía una máquina Unix tolerable. Era la primera PC de la que tal cosa podía ser dicha.

Comenzaba a ser posible imaginar que el proyecto GNU de Stallman podría casar con máquinas 386 para producir estaciones de trabajo Unix casi un orden de magnitud más baratas que la que cualquiera estaba ofreciendo. Curiosamente, de hecho nadie parece haber llegado tan lejos en su pensamiento. La mayoría de los programadores Unix, viniendo de los mundos de las minicomputadoras y las estaciones de trabajo, continuaban desdeñando las baratas máquinas 80×86 en favor de los diseños más elegantes basados en el 68000. Y, aunque muchos programadores contribuyeron al proyecto GNU, entre la gente Unix ésto tendía a ser considerado un gesto quijotesco que a duras penas tendría consecuencias prácticas a corto plazo.

La comunidad Unix nunca perdió su línea rebelde. Pero en retrospectiva, estábamos tan ciegos como IBM o AT&T al futuro que nos marcaba el rumbo. Ni siquiera Richard Stallman, que había declarado una cruzada moral contra el software propietario unos años antes, entendió qué tanto el hacer de Unix un producto dañó a la comunidad alrededor del mismo Unix; sus preocupaciones eran con cuestiones más abstractas y de largo plazo. El resto de nosotros nos quedamos esperando que alguna variación inteligente a la fórmula de las corporaciones pudiera resolver los problemas de la fragmentación, la comercialización desalmada, y la deriva estratégica, para redimir la promesa del Unix anterior a la venta. Pero aún habrían de venir tiempos peores.

1988 fue el año en que Ken Olsen (director ejecutivo de DEC) describió en una famosa cita a Unix como “estafa” [NT13]. DEC había estado lanzando su propia variante de Unix en las PDP-11 desde 1982, pero en realidad quería que el negocio se dirigiera hacia su sistema operativo propietario VMS. DEC y la industria de las minicomputadoras estaban en serios problemas, hundidos por las olas de las poderosas máquinas de bajo costo de parte de Sun Microsystems y el resto de los vendedores de estaciones de trabajo. La mayoría de esas estaciones de trabajo ejecutaban Unix.

Pero los propios problemas de la industria Unix estaban creciendo y haciéndose más severos. En 1988 AT&T obtuvo un 20% de Sun Microsystems. Estas dos compañías, líderes en el mercado Unix, estaban comenzando a despertar ante la amenaza puesta por las PCs, IBM y Microsoft, y a darse cuenta que los anteriores cinco años de sangrado les habían dejado poco. La alianza AT&T/Sun y el desarrollo de estándares técnicos alrededor de POSIX curaron eventualmente la brecha entre las líneas del Unix System V y BSD. Pero la segunda fase de las guerras Unix comenzó cuando los vendedores de segundo rango (IBM, DEC, Hewlett-Packard y otros) formaron la Open Software Foundation y se alinearon contra el eje AT&T/Sun (representado por Unix International). Más rounds de Unix contra Unix sobrevinieron.

Mientras tanto, Microsoft hacía millones en los mercados del hogar y los pequeños negocios a los que las facciones en guerra de Unix nunca quisieron dirigirse. El lanzamiento en 1990 de Windows 3.0 – el primer sistema operativo exitoso de Redmond – cimentó el dominio de Microsoft, y creó las condiciones que les permitieron aplanar y monopolizar el mercado de las aplicaciones de escritorio en los 90s.

Los años de 1989 a 1993 fueron los más oscuros en la historia de Unix. Parecía entonces que todos los sueños de la comunidad Unix habían fallado. La guerra fratricida había reducido a la industria del Unix propietario a disputas confusas que nunca llamaban a la determinación o a la capacidad de enfrentar a Microsoft. Los elegantes chips Motorola favorecidos por la mayoría de los programadores Unix habían perdido ante los feos pero baratos procesadores Intel. El proyecto GNU había fallado en producir el núcleo libre de Unix que venía prometiendo desde 1985, y luego de años de excusas, su credibilidad comenzó a disminuir. La tecnología PC implacablemente comenzaba a volverse una industria de corporaciones. Los hackers pioneros de Unix de fines de los 70s llegaban a los 40s y se alentaban. El hardware se volvía más barato, pero Unix aún era muy caro. Tardíamente nos estábamos dando cuenta que el antiguo monopolio de IBM había sucumbido ante un nuevo monopolio de Microsoft, y el software de mala ingeniería de Microsoft estaba alzándose a nuestro alrededor como una ola de aguas residuales.

Notas al pie de esta sección:
[16] UUCP llegó a causar furor [NT10] cuando un módem ‘rápido’ era de 300 baudios.

[17] La PS/2, sin embargo, dejó marca en las PCs posteriores – haciendo del mouse un periférico estándar, razón por la cual el conector del mouse en la parte posterior del chasis de tu computadora se llama “puerto PS/2″.

Referencias bibliográficas de esta sección:
[Libes-Ressler] Don Libes and Sandy Ressler. Life with Unix. 1989. ISBN 0-13-536657-7. Prentice-Hall.

[Leonard] Andrew Leonard. BSD Unix: Power to the People, from the Code. 2000. Disponible en la Red.

[Stallman] Richard M. Stallman. The GNU Manifesto. Disponible en la Red.

Notas de traducción de esta sección:
[NT10] En el original en inglés, ‘hot stuff’ es una expresión para indicar algo que está de moda, está al día y es atractivo, pero en el texto el sentido que interpreto es también de algo considerado lo más avanzado en cierta área. Para traducir la expresión, utilicé una expresión local que me sonó adecuada.

[NT11] En el original en inglés, ‘deep-sixed’ es una expresión para denotar algo que ya no se quiere conservar, que se desecha o desprecia. La expresión en español ‘tomar a menos’ tiene aquí el mismo sentido.

[NT12] ‘The handwriting was on the wall’ es una expresión en inglés tomada del libro bíblico de Daniel, en el que Dios anuncia a los babilonios la próxima caída de su imperio por parte de las fuerzas persas invasoras. Es una expresión que denota un presagio maligno próximo a suceder, y puesto que en español no encontré una expresión literal para el mismo sentido, utilizo la frase ‘presagio a la vista’ en la traducción.

[NT13] ’snake oil’ en el original en inglés es una expresión que hace referencia a un producto que se vende con engaños, siendo en sí mismo un fraude, o que se vende con exagerada mercadotecnia, siendo de calidad poco comprobable o confiable. Originalmente era una medicina china para las articulaciones, pero derivó en el sentido dado aquí. En español no encontré frases equivalentes que den el mismo sentido, así que dejo la traducción de forma genérica con la palabra ‘estafa’.

Nosotros Venceremos: 1991 – 1995

El primer rayo de luz en la oscuridad vino en 1990 con el esfuerzo de William Jolitz de migrar BSD a una 386, publicando en una serie de artículos de revistas en 1991. El puerto 386BSD fue posible gracias a que, en parte influenciado por Stallman, el hacker de Berkeley Keith Bostic comenzó un esfuerzo de limpiar de código propietario de AT&T al código fuente de BSD en 1988. Pero el proyecto 386BSD recibió un golpe severo cuando, cerca de finales de 1991, Jolitz se apartó y destruyó su propio trabajo. Existen explicaciones en conflicto, pero en lo que son comunes dichas explicaciones es en que Jolitz quería que su código fuera liberado como código fuente sin recargos de licencia y se enojó cuando los patrocinadores corporativos del proyecto optaron por un modelo de licenciamiento más propietario.

En agosto de 1991, Linux Torvalds, entonces un desconocido estudiante universitario finalndés, hizo el anuncio del proyecto Linux. Torvalds ha reconocido oficialmente que una de sus principales motivaciones era el alto costo del Unix de Sun en su universidad. También Torvalds ha dicho que si se hubiera enterado de la existencia del esfuerzo en BSD se hubiera unido a él, en lugar de fundar el suyo propio. Pero el 386BSD no fue lanzado sino hasta principios de 1992, unos meses después del primer lanzamiento de Linux.

La importancia de estos dos proyectos se volvió clara solamente en retrospectiva. En su tiempo, atrajeron muy poca atención incluso dentro de la cultura hacker de Internet – y mucho menos en la más amplia comunidad Unix, que aún estaba fijada en máquinas más capaces que las PCs, y tratando de reconciliar las propiedades especiales de Unix con el modelo propietario convencional de un negocio de software.

Pasarían otros dos años y la gran explosión de Internet de 1993-1994 antes de que la verdadera importancia de Linux y las distribuciones de código abierto de BSD se volvieran evidentes para el resto del mundo Unix. Desafortunadamente para los BSDeros, una demanda de AT&T contra BSDI (la pequeña compañía que había respaldado el puerto de Jolitz) consumió mucho de ese tiempo y motivó a muchos desarrolladores clave de Berkeley a pasarse a Linux.

“Se alegó la existencia de copias de código y robo de secretos industriales. El código que en sí cometía la infracción no fue identificado por cerca de dos años. La demanda pudo haber durado mucho más sino fuera por el hecho de que Novell compró USL a AT&T y buscó un acuerdo. Al final, tres archivos fueron eliminados de los 18,000 que conformaban la distribución, y cierta cantidad de pequeños cambios fueron hechos a otros archivos. Además, la Universidad aceptó agregar notas de copyright para USL a cerca de 70 archivos, con la estipulación de que esos archivos continuaran siendo redistribuidos libremente.”
— Marshall Kirk McKusick –

El acuerdo estableció un precedente importante al liberar un Unix completamente operacional del control propietario, pero sus efectos en el propio BSD fueron calamitosos. Las cosas no mejoraron cuando, en 1992-1994, el Grupo de Investigación en Ciencias de la Computación de Berkeley cerró sus puertas; posteriormente, la guerra entre facciones de la comunidad BSD dividió al sistema en tres esfuerzos de desarrollo en competencia. Como resultado, el linaje de BSD se rezagó detrás de Linux en un momento crucial y perdió ante él la posición líder en la comunidad Unix.

Los esfuerzos de desarrollo de Linux y BSD eran nativos a Internet en una forma en que los Unixes anteriores no lo habían sido. Se basaban en el desarrollo distribuido y la herramienta patch(1) de Larry Wall, y reclutaban desarrolladores vía email y a través de grupos de noticias en Usenet. Por lo tanto, tuvieron un impulso tremendo cuando los negocios proveedores de servicio de Internet (ISP, Internet Service Providers) proliferaron en 1993, habilitados por cambios en la tecnología de telecomunicaciones y la privatización de la columna dorsal de Internet, eventos fuera del alcance de esta historia. La demanda por una Internet barata fue creada por algo más: la invención en 1991 de la World Wide Web (WWW, la Red). La Web fue la “killer app” [NT14] de la Internet, la tecnología de interfaz gráfica de usuario que la hizo irresistible para una larga población de usuarios finales no técnicos.

La mercadotecnia en masa de la Internet tanto incrementó la fuente de desarrolladores potenciales como bajó los costos transaccionales del desarrollo distribuido. Los resultados se vieron reflejados en esfuerzos como XFree86, que usó un modelo con Internet al centro para construir una organización de desarrollo más eficaz que el del Consorcio X oficial. El primer XFree86 de 1992 le dio a Linux y los BSDs el motor de interfaz de usuario gráfica que les hacía falta. Durante la siguiente década XFree86 estaría en la delantera del desarrollo en X, y una porción en aumento de la actividad del Consorcio X consistiría en concentrar las innovaciones originadas en la comunidad XFree86 hacia los patrocinadores industriales del Consorcio.

Para fines de 1993, Linux ya tenía capacidades de Internet y X. Todas las herramientas GNU fueron alojadas en él desde el principio, proveyéndolo de herramientas de desarrollo de alta calidad. Además de las herramientas GNU, Linux actuó como un punto de atracción, colectando y concentrando veinte años de software de código abierto que anteriormente había estado disperso en una docena de diferentes plataformas Unix propietarias. Aunque el kernel de Linux aún estaba oficialmente en versión beta (a nivel 0.99), ya era remarcablemente libre de caídas. La amplitud y la calidad del software en las distribuciones Linux era ya la de un sistema operativo listo para el nivel de producción.

Algunos pocos de los de mente más abierta entre los desarrolladores Unix de la vieja escuela comenzaron a percatarse de que el sueño tan largamente esperado de un sistema Unix barato para todo mundo se coló [NT15] enfrente de ellos desde una dirección inesperada. No provino de parte de AT&T o de Sun o de cualquiera de los vendedores tradicionales. Tampoco emergió de un esfuerzo organizado en la universidad. Fue un bricolaje que burbujeó fuera de la Internet a partir de lo que pareciera generación espontánea, apropiándose y recombinando elementos de la tradición Unix en formas sorprendentes.

En otros lados, las maniobras corporativas continuaron. AT&T vendió sus intereses en Sun en 1992; luego vendió sus Unix Systems Laboratories (USL, Laboratorios de Sistemas Unix) a Novell en 1993; Novell pasó la marca registrada Unix al grupo de estándares X/Open en 1994; AT&T y Novell se unieron en la OSF [Open Software Foundation] en 1994, dando fin a las guerras Unix. En 1995 SCO compró UnixWare (y los derechos al código fuente original de Unix) de Novell. En 1996, X/Open y la OSF se fusionaron, creando un gran grupo de estándares Unix.

Pero los vendedores convencionales de Unix y los escombros de sus guerras parecieron cada vez menos y menos relevantes. La acción y la energía de la comunidad Unix estaba cambiando a Linux y BSD y a los desarrolladores de código abierto. Para ese tiempo IBM, Intel y SCO anunciaron el proyecto Monterrey en 1998 – un último intento de obtener una mezcla para Un Gran Sistema a partir de los Unixes propietarios que aún sobrevivían – los desarrolladores y la prensa comercial reaccionaron con diversión, y el proyecto fue abruptamente cancelado en 2001 luego de tres años de ir a ningún lado.

La transición de la industria no puede decirse que se completó hasta el año 2000, cuando SCO vendió UnixWare y el código fuente original de Unix a Caldera – un distribuidor Linux. Pero luego de 1995, la historia de Unix se convirtió en la historia del movimiento del código abierto. Hay aún otro lado de esa historia; para contarlo, necesitaremos regresar a 1961 y a los orígenes de la cultura hacker de Internet.

Notas de traducción de esta sección:
[NT14] El original ‘killer app’ es una expresión del mundo de la informática que en realidad no tiene traducción al español, a pesar de lo que diga la Wikipedia en español. De la misma Wikipedia, una ‘killer app’ es una aplicación determinante, es decir, que su implantación supone la asimilación definitiva por parte de los usuarios. Una aplicación así ejerce una enorme influencia en el desarrollo de posteriores desarrollos informáticos y en la forma en como se ofrece un servicio a partir del momento en que dicha aplicación se populariza. Dejé en el texto la versión en inglés, pues la traducción ‘aplicación asesina’ no me termina de gustar ni convencer en nada. Existe una entrada para ‘killer app’ en el Jargon File (http://www.catb.org/~esr//jargon/html/K/killer-app.html)

[NT15] El original ’snuck’ en realidad no es una palabra del inglés, sino una expresión inventada como si fuera el tiempo pasado de ’sneak’, otra palabra inventada que significa introducirse furtivamente. De ahí que utilicé la expresión ‘colarse’ (utilizado por lo que sé en México, en España, y no se si en otros lugares también) para denotar el mismo significado.

–
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: www.torcasajuv.com
“Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos.” (San Agustín) Solamente asegúrate que en realidad sea AMOR…

Historia de Unix

Linux es, hoy en día, uno de los sistemas operativos para computadoras personales, estaciones de trabajo y otras computadoras, de mayor confiabilidad en el mercado. Puede parecer para muchos, conociendo el origen humilde de este sistema, impresionante como es que a partir de esfuerzos aislados geográficamente de miles de personas en apariencia poco coordinadas, que un sistema así pueda llegar al nivel de calidad que el que Linux y sus aplicaciones tienen hoy en día. Sin embargo, como es común en estas situaciones, es mi opinión que todos somos producto de nuestra historia, y Linux no es la excepción. Tanto la esencia del sistema, basada en el clásico Unix que ha perdurado por décadas, como el método de desarrollo que Linux llevó al éxito son, entre otras cosas, la consecuencia obvia de la historia que llevó a los personajes de la historia de Unix a involucrarse en la historia misma de Linux.

“The Art of UNIX Programming” (TAOUP, ‘El arte de programar en UNIX’) es un libro publicado por Addison y Wesley en el año 2004, escrito por Eric S. Raymond (sitio de internet: http://www.catb.org/esr), un hacker considerado por muchos como el antropólogo e historiador del movimiento hoy conocido como ‘Open Source’. Raymond es autor también de importantísimos ensayos en este aspecto: ‘La Catedral y el Bazar’ (1997), llevó en el año 1998 a la compañía Netscape a liberar el código de su navegador de internet Mozilla (el ancestro del tan de moda hoy en día Firefox), y con ello vino el éxito comercial y financiero que también ha acompañado al ‘código abierto’ y al ’software libre’ tal como los conocemos hoy (véanse los casos de Linux, GNU, Apache, X, Perl, Python, y un largo etcétera.)

Por un lado, la filosofía de programación de Unix, que convoca a métodos sencillos, modulares y reutilizables, entre otras características. Por el otro, la metodología de desarrollo ‘abierta’, o de ‘bazar’, característica de proyectos como la Wikipedia (http://wikipedia.org), en donde la ‘revisión por pares’ se convierte en la esencia del funcionamiento y la calidad de estos proyectos. Y además, la actitud hacker, la de superarse siempre, la de no conformarse con las cosas mal hechas sino mejorarlas, la de, por lo tanto, buscar siempre utilizar y reutilizar sobre plataformas que garanticen esa calidad. Todos estos aspectos, y otros más, se retratan de manera muy concreta en el capítulo 2 del libro TAOUP.

Esta serie de posts son mi traducción personal a este capítulo. Pueden ser vistos en mi blog en Blogger (http://jstitch.blogspot.com/), así como en el de WordPress (http://jstitch.wordpress.com/). Debo mencionar, que el libro ‘The Art of UNIX Programming’ está sujeto a los términos de la licencia Creative Commons Attribution-NoDerivs 1.0 (que puede ser leída en http://creativecommons.org/licenses/by-nd/1.0/legalcode), con la estipulación extra de que el derecho a publicar en papel para fines de lucro, se reserva para Pearson Education, Inc. En pláticas vía email con Mark Taub, encargado de los derechos de traducción de Addison-Wesley, obtuve el derecho para traducir el capítulo 2 del libro TAOUP, y de publicarlo únicamente en las direcciones de internet pertenecientes a mis dos blogs antes citados. Mi intención al traducir y publicar en web la traducción del capítulo 2 de TAOUP es difundir también en el habla hispana parte de la sabiduría contenida en este libro, y qué mejor que el capítulo 2, que habla de la historia y los orígenes de Unix para entender mejor el por qué y el cómo es que se ha llegado hasta donde hoy en día (2008) se ha llegado en Linux, el código abierto, el software libre y demás conceptos relacionados. Por ello, hago aviso de estas estipulaciones de licencia, y no me hago responsable por el uso que se haga de la información de los posts relativos a mi traducción, aunque espero que el propósito inicial de servir como medio de difusión se mantenga siempre puro. Nótese, claro está, que estas advertencias mías no están ni deben interpretarse como que están por encima de lo estipulado en la licencia Creative Commons-NoDerivs 1.0, ni en el derecho de Pearson Education, Inc. a publicarlo en papel para fines de lucro, ni en el permiso que Mark Taub tan amablemente me concedió de publicar por medio electrónico la traducción del capítulo 2 de TAOUP únicamente en mis dos blogs que ya mencioné. Con respecto a las imágenes utilizadas a lo largo de la traducción, fueron sacadas del sitio en línea del libro (http://www.catb.org/esr/writings/taoup/), y los créditos y restricciones de las mismas son idénticos a los del sitio antes mencionado.

Por último, he de decir que, aunque la traducción que propongo pretende ser lo más fiel posible al texto original (véase http://www.catb.org/esr/writings/taoup/translation.html para las notas del autor con respecto a lo que el autor mismo requeriría para una buena traducción), siempre he intentado reflejar en lo que hago el proceso mental que me llevó a ello (podrían preguntar a mis colegas por mi afición para comentar y documentar el código que yo escribo . Es por ello que dentro de la traducción incluyo notas propias, referenciadas dentro del texto principal como pies de sección a través de la marca [NT#], donde ‘#’ es un número consecutivo a partir de 1. Mi intención de estas notas es únicamente reflejar el reto que para mí ha implicado la traducción lo más fiel posible del texto, incluyendo sobre todo el sentido de las frases encontradas en la versión original en inglés, más que la traducción literal del texto, que por demás está decirlo, muchas veces produce traducciones de muy pobre calidad. Esta es mi primer traducción ‘formal’ de un texto, con eso de que se incluye la licencia y todo eso, y por ello la emoción me ganó para incluir dichas notas. Con respecto a las notas a pie de sección, decidí mantener la numeración original del texto, a pesar de que estos posts sólo incluirán el capítulo 2 del libro, por lo que no debe de extrañar que la numeración no comience con ‘1′.

Ahora sí, dicho todo esto, comencemos pues…

Atte.
Javier Novoa Cataño (jstitch)

Capítulo 2. Historia
Un recuento de dos culturas

Tabla de Contenido

Orígenes e Historia de Unix, 1969 – 1995

Génesis: 1969 – 1971
Éxodo: 1971 – 1980
TCP/IP y las Guerras Unix [NT1]: 1980 – 1990
Nosotros Venceremos [NT2]: 1991 – 1995

Orígenes e Historia de los Hackers, 1961 – 1995

Jugando en el recinto universitario [NT3]: 1961 – 1980
Fusión con Internet y el Movimiento del Software Libre: 1981 – 1991
Linux y la Reacción Pragmática: 1991 – 1998

El movimiento Open-Source (Código Abierto): 1998 y siguientes

Lecciones de la historia de Unix

Aquellos que no pueden recordar el pasado están condenados a repetirlo
– Jorge Santayana [NT4] – The Life of Reason (1905)

El pasado informa de la práctica. Unix tiene una larga y colorida historia, mucha de la cual aún está viva como folclore, presuposiciones y (muy seguido) cicatrices de guerra en la memoria colectiva de los programadores Unix. En este capítulo, examinaremos la historia de Unix, desde un punto de vista para explicar el porque, en 2003, la cultura Unix se ve de la forma que es.

Orígenes e Historia de Unix, 1969 – 1995

Un notorio ‘efecto del segundo sistema’ aflige seguido a los sucesores de pequeños prototipos experimentales. La urgencia de incluir todo lo que no se incluyó la primera vez frecuentemente lleva a un diseño gigante y sobre complicado. Menos conocido aún, por lo menos común, es el ‘efecto del tercer sistema’; algunas veces, luego de que el segundo sistema se colapsa por su propio peso, hay posibilidades de regresar a la simplicidad y hacerlo todo bien esta vez.

El Unix original era un tercer sistema. Su abuelo era el pequeño y sencillo Sistema de Tiempo Compartido Compatible (CTSS, Compatible Time-Sharing System), el primer o segundo sistema de tiempo compartido de la historia (dependiendo algunas cuestiones de definición que determinadamente ignoraremos). Su padre fue el proyecto pionero Multics, un intento de crear una ‘utilidad de información’ llena de características que graciosamente soportaría tiempo compartido interactivo de computadoras centrales (mainframes) por parte de grandes comunidades de usuarios. Multics, desafortunadamente, de hecho se colapsó bajo su propio peso. Pero Unix nació de ese colapso.

Génesis: 1969 – 1971

Unix nació en 1969 de la mente de un científico de la computación de los Laboratorios Bell (Bell Labs), Ken Thompson. Thompson fue un investigador en el proyecto Multics, una experiencia que lo desilusionó del primitivo cómputo por lotes que era común prácticamente en todos lados. Pero el concepto de tiempo compartido aún era nuevo a finales de los 60’s; las primeras especulaciones apenas fueron formuladas diez años antes por el científico de la computación John McCarthy (el inventor del lenguaje Lisp), la primer implantación de un sistema así fue hecha en 1962, siete años antes, y los sistemas operativos de tiempo compartido aún eran bestias experimentales y temperamentales.

El hardware de las computadoras era en ese tiempo más primitivo de lo que incluso lo que la gente que lo llegó a ver puede recordar fácilmente. Las máquinas más potentes de la época tenían menos potencia computacional y memoria interna que un típico teléfono móvil celular de hoy en día. [13] Las terminales de vídeo estaban en su infancia y no serían ampliamente implementadas hasta luego de otros seis años. El dispositivo de interacción estándar de los primeros sistemas de tiempo compartido era el teletipo ASR-33 – un dispositivo lento y ruidoso que imprimía solamente letras mayúsculas en grandes rollos de hojas amarillas. El ASR-33 fue el padre natural de la tradición en Unix de los comandos escasos y las respuestas concisas.

Cuando Laboratorios Bell se alejó del consorcio de investigación de Multics, Ken Thompson se quedó con algunas ideas inspiradas en Multics sobre cómo construir un sistema de archivos. Así mismo se quedó sin una máquina en la cual jugar un juego que él había escrito, llamado Space Travel, una simulación de ciencia ficción que involucraba navegar con un cohete a través del sistema solar. Unix comenzó su vida en una minicomputadora PDP-7 limpiada [14], como la mostrada en la figura 2.1, como plataforma para el juego Space Travel y como zona de pruebas para las ideas de Thompson sobre diseño de sistemas operativos.

[Figura 2.1 la PDP-7]

La historia completa del origen se cuenta en [Ritchie79] desde el punto de vista del primer colaborador de Thompson, Dennis Ritchie, el hombre que sería conocido como el co-inventor de Unix y el inventor del lenguaje de programación C. Dennis Ritchie, Doug McIlroy, y unos pocos colegas se habían acostumbrado al cómputo interactivo bajo Multics y no querían perder esa posibilidad. El sistema operativo de Thompson en la PDP-7 les ofrecía una línea de vida [NT5].

Ritchie anota: “Lo que queríamos conservar no era sólo un buen ambiente en el cual programar, sino un sistema alrededor del cual una comunidad se pudiera formar. Sabíamos por experiencia que la esencia del cómputo comunal, tal como lo proveían las máquinas de acceso remoto y tiempo compartido, no estaba solamente en escribir programas en una terminal en vez de una tarjeta perforada, sino en reforzar la comunicación cercana.” El tema de las computadoras vistas no solamente como dispositivos lógicos sino como núcleos de comunidades estaba en el aire; 1969 fue también el año en que ARPANET (el ancestro directo del Internet de hoy en día) fue inventada. El tema de “comunidad” resonaría por la historia de Unix de ahí en adelante.

La implementación de Space Travel por Thompson y Ritchie atrajo atención. Al inicio, el software de la PDP-7 tenía que ser pasado por un compilador cruzado en una mainframe GE. Los programas utilitarios que Thompson y Ritchie escribieron para soportar el desarrollo de juegos en la PDP-7 se convirtió en el núcleo de Unix – aunque el nombre no llegó sino hasta 1970. Originalmente, el nombre se deletreaba “UNICS” (UNiplexed Information and Computing Service, Servicio de Información y Cómputo UNiplexado), que posteriormente Ritchie describió como una “especie de broma truculenta sobre Multics”, que significaba MULTiplexed Information and Computing Service (Servicio de Información y Cómputo MULTiplexado).

Incluso en sus etapas tempranas, el Unix de la PDP-7 tenía una fuerte semejanza a los Unixes de hoy en día, y proveía un ambiente de programación ligeramente más placentero que el que estaba disponible en cualquier otro lado en esos días de mainframes de proceso por lotes alimentadas por tarjetas perforadas. Unix estaba muy cerca de ser el primer sistema bajo el cual un programador podía sentarse directamente en la máquina y hacer programas al aire, explorando posibilidades y probando mientras componía. A lo largo de toda su vida, Unix se ha caracterizado por poseer un patrón que acrecienta las posibilidades atrayendo los esfuerzos de voluntarios hábiles a partir de programadores impacientes con las limitaciones de otros sistemas operativos. Este patrón se estableció temprano, inclusive dentro de los mismos Laboratorios Bell.

La tradición Unix de desarrollo ligero y métodos informales también comenzó desde sus inicios. En donde Multics fue un proyecto largo con miles de páginas con especificaciones técnicas escritas antes que se tuviera el hardware, el primer código de Unix fue inspirado por tres personas e implementado por Ken Thompson en dos días – en una máquina obsoleta que fue diseñada como terminal gráfica para una computadora ‘real’.

El primer trabajo real de Unix, en 1971, fue soportar lo que hoy en día sería llamado procesamiento de palabras para el departamento de patentes de los Laboratorios Bell; la primera aplicación Unix fue el ancestro del formateador de textos nroff(1). Este proyecto permitió la justificación para la compra de una PDP-11, una minicomputadora mucho más capaz. La Administración se mantuvo dichosamente inadvertida del hecho de que el sistema de procesamiento de palabras que Thompson y colegas estaban construyendo estaba incubando un sistema operativo. Los sistemas operativos no estaban en los planes de los Laboratorios Bell – AT&T se unió al consorcio Multics precisamente para evitar desarrollar un sistema operativo por sí mismos. Aún así, el sistema terminado fue un éxito en ascenso. Estableció a Unix como una parte permanente y valorada de la ecología computacional en los Laboratorios Bell, y comenzó otro tema en la historia de Unix – una fuerte asociación con el formateo de documentos, tipografías y herramientas de comunicación. El manual de 1972 presumía de contar con 10 instalaciones.

Posteriormente, Doug McIlroy escribiría sobre este período [McIlroy91]: “La presión de los colegas y un simple orgullo en el trabajo hecho, provocaron que cantidades [NT6] de código fueran reescritas o desechadas conforme emergían ideas mejores o más elementales. La rivalidad profesional y la protección territorial eran prácticamente desconocidas: muchas cosas buenas estaban sucediendo que nadie necesitaba apropiarse las innovaciones”. Pero tendría que ocurrir otro cuarto de siglo para que todas las implicaciones de esta observación llegaran a lugar.

Notas al pie de esta sección:
[13] Ken Thompson me recordó que los teléfonos móviles de hoy en día tienen más RAM que la PDP-7 tenía en RAM y espacio en disco juntos; un disco grande, en esos días, consistía en menos de un mega byte.

[14] Hay una FAQ en la Web sobre las computadoras PDP, que explica el papel, de otra forma extremadamente oscuro, en la historia de la PDP-7.

Referencias bibliográficas de esta sección:
[Ritchie79] Dennis M. Ritchie. The Evolution of the Unix Time-Sharing System. 1979. Disponible en la Red.

[McIlroy91] Proc. Virginia Computer Users Conference. Volume 21. M. D. McIlroy. “Unix on My Mind“. p.1-6.

Notas de traducción de esta sección:
[NT1] Personalmente, el término ‘Unix Wars’ siempre se me ha hecho una referencia a ‘Star Wars’, una famosísima película de ficción en los 70s-80s. Sin embargo, la traducción al español de Star Wars es ‘Guerras de las Galaxias’, lo que no quedaría muy bien traducido como ‘Guerras de Unix’, por lo que me tomé la libertad de quitar la preposición ‘de’ para darle al título un aire más de ficción, al estilo del mismo título ‘Unix Wars’. Una forma tal vez más correcta sería ‘Guerras de los Unixes’, pero al mismo tiempo tal vez esa traducción haría la analogía ‘Star Wars’ – ‘Unix Wars’ más evidente, siendo que esta relación es algo que yo personalmente he pensado, hasta estar seguro de la misma no intentaría establecer el término de manera definitiva.

[NT2] Con base en los comentarios de ESR en http://www.catb.org/esr/writings/taoup/translation.html, el nombre de esta sección quedó haciendo referencia a la rebeldía heroica, ya que ‘Blows against the Empire’, título de un álbum de Paul Kantner, anterior líder de Jefferson Airplane, no tiene (o no encontré una) traducción al español oficial para utilizar. ‘Nosotros Venceremos’, según Google, hace referencia tanto a una canción gospel del Rvdo. Charles Tindley, (‘We shall overcome’), canto de protesta que se convirtió en himno del movimiento de derechos civiles en Estados Unidos. También se encuentran en Google referencias a un canto cristiano que hace referencia al éxito contra el mal, tomado como ‘imperio’ en el sentido que también se puede interpretar en el título en inglés original de esta sección.

[NT3] El original en inglés ‘At Play in the Groves of Academe’ (lit. ‘Jugando en las arboledas de la universidad’), me da la impresión de ser una expresión local, por lo que busqué la forma de adaptarla a una expresión más genérica, pues en español no ubiqué ninguna expresión que pudiera equipararse a la original en inglés.

[NT4] Jorge Agustín Nicolás Ruiz de Santayana y Borrás, nacido en España, es mundialmente conocido como George Santayana.

[NT5] La ‘línea de vida’ (‘lifeline’ en el original), es una cuerda utilizada por los buzos y mineros, entre otros, para guiarse en el camino de regreso de las profundidades en las que se sumergen, a la Teseo en el laberinto del minotauro. No encontré traducción literal para ‘lifeline’, por lo que traduzco libremente aquí.

[NT6] El original en inglés dice ‘gobs’, que yo sustituyo de forma genérica por ‘cantidades’, al no encontrar una traducción más adecuada. Los ‘gobs’ son una forma en que se conoce comúnmente a los restos desechables del carbón en una mina.

–
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: www.torcasajuv.com
“Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos.” (San Agustín) Solamente asegúrate que en realidad sea AMOR…

Como lo comenté en este post, instalé Linux en mi laptop recientemente, pero el problema que me quedó pendiente fue el 3D. Casi inmediatamente, Carlos Rocha contestó en este blog con lo siguiente:

Que tal como estas, solo para comentarte que acabo de instalar el opensuse hoy en el mismo modelo de laptop, yo instale el driver que viene el la pagina de amd, y me funciono y aunque cuando echo a andar el panel de control de ati me dice que no tiene soporte para aceleracion 3d por hardware, le instale el xgl y el compiz y funciono de maravilla, todavia estoy en proceso de instalacion de drivers y afinacion de ciertos detallitos, que espero que queden en el transcurso de la semana…
Los drivers los puedes descargar de la pagina http://ati.amd.com/support/driver.html ,
en el sistema operativo seleccionas linux_64 >> Integrated/Motherboard >> RAdeon Xpress 1250..
este es un archivo .run, lo instalas desde el suse, y ejecutas el comando aticonfig –initial, reinicias y listo..
Espero te haya sido de ayuda.
saludos.

Pues bien, hice esto, desinstalé previamente el controlador fgl que ya tenía antes que nada, y siguiendo las instrucciones de la página Wiki de OpenSuSE para instalar este controlador, conseguí mi 3D!!!! Pueden ver la captura de pantalla en http://invernalia.homelinux.net/~jstitch/jstitch/linux/snapshot1.png.

Muchísimas gracias!

Se me ocurrió que era hora ya de entrarle a la configuración de servidores en Linux. Hasta ahora, sólo había conseguido echar a andar un servidor HTTP en linux, para uso local solamente, de forma que pudiera hacer pruebas en desarrollos web con PHP que a veces hago. Sin embargo, no había conseguido, y no me había interesado, en lograr esto mismo pero hacia el exterior. Puesto que tengo configurada una red local (LAN) en mi casa a través de un router (un 2Wire), utilizando la dirección IP local que el router le asigna a mi máquina, alguna vez ya había podido acceder a los servicios HTTP de mi máquina desde otra máquina en la LAN.

Pero sucedió que en mi trabajo comencé a utilizar un cliente SSH para Windows para acceder a una máquina Unix, y se me ocurrió hacer la prueba en mi casa… me llevé dicho cliente, y desde el Windows de la PC de mi esposa, accedí con éxito a mi máquina! como si estuviera trabajando directamente en ella… todo comenzaba a sonar muy interesante…

Sin embargo, la dirección IP de mi máquina era local, y acceder a ella desde afuera tenía que implicar algo con el router, como efectivamente descubrí: hay que configurar dicho aparato para que las solicitudes externas por medio de su dirección IP se redirijan a una máquina de la LAN en particular (o en otras palabras, asignarle la dirección IP del router a la máquina en cuestión).

En el router 2Wire se consigue en las configuraciones avanzadas del Firewall, en donde se elige el nombre de la máquina a servir como entrada a la LAN. (Si se desea también acceder a las otras máquinas de la red, debe, si no me equivoco, configurarse el etc/hosts de la máquina que quedó como entrada, para redirigir las peticiones correctamente, esto no lo he hecho aún, pero ya lo probaré a su tiempo Cabe hacer notar que en la configuración del router aparece el nombre de la máquina N veces, dependiendo el número de accesos al router que se tengan: conmigo aparece dos veces, una para la conexión alámbrica y la otra para la inalámbrica. Toda esta configuración la di de alta para mi conexión alámbrica únicamente, que para mi es más confiable y rápida que la inalámbrica, con la cual, si estoy trabajando sin cables, no tendré disponible el servidor. A lo mejor es un tabú mío, pero siento que de forma inalámbrica tengo menos seguridad, además de menos velocidad y confiabilidad de mi conexión.

Una vez configurado esto, también en el router hay que establecer el nivel de seguridad que se quiere tener: se puede establecer que ninguna petición externa pase a la máquina seleccionada (lo que no sirve para nada en realidad), o que ciertas aplicaciones entren directamente a la máquina, o que todas las peticiones pasen a ella, ya es cuestión de gustos en aspecto de seguridad. Por otra parte, es muy recomendable a pesar de la opción elegida, configurar el firewall de la máquina que quedó como entrada, para que también filtre ahora sí de manera particular las peticiones de ciertas aplicaciones / puertos abiertos para permitir la entrada desde el exterior.

Obviamente, para que todo funcione, la computadora debe tener levantados ciertos servicios, dependiendo lo que se desee: SSH para sesiones remotas, HTTP para páginas web, FTP para archivos, SMB para compartir archivos como en Windows, etc. De lo contrario, ni de manera local se conseguiría levantar todo esto.

Y así, teniendo el router configurado para asignarle su dirección IP a la máquina elegida, la máquina reiniciada para adquirir la nueva IP, y el firewall configurado también, todo queda listo para tener la computadora abierta al exterior. Lo único que queda es probar
Si se dejó abierto el puerto de HTTP (teniendo también instalado un servidor, como Apache por ejemplo), se puede probar localmente, o mejor, desde una máquina externa en algún otro lugar del mundo (con ayuda de un amigo por ejemplo , para que en un navegador de internet cualquiera teclee http://direccion_ip, lo cual debe llevar a mostrar la página de inicio que tenga configurado el servidor HTTP en la computadora en ese momento. Se pueden hacer otras pruebas, teniendo todo bien configurado, para iniciar sesión en la computadora de manera remota, vía SSH, y muchas otras pruebas más, que en mi caso resultaron satisfactorias y que ahora utilizo para trabajar de manera remota en mi computadora

Otro paso no necesario pero sí muy útil es el DNS de la máquina. Hasta ahora todo quedó configurado con la dirección IP del router, pero ¿qué pasa si el servicio de internet que tengo contratado no me asigna una IP fija, sino dinámica, que se puede reasignar en cualquier momento una vez que se desconecte el router? (por cualquier razón: caídas de voltaje, acciones voluntarias o involuntarias, hasta simplemente mover los cables de corriente a donde está conectado!) Esto provocaría que cada que suceda esta situación, debería tomarse nota de la nueva dirección IP de la máquina, para poder trabajar de forma remota en ella, y no solo eso, si otras personas hacen uso de los recursos de la máquina, habría que notificarles apropiadamente de la nueva dirección IP para que la utilicen.

Esto es engorroso, poco práctico y bueno, en pocas palabras por eso y más desde hace años existe el DNS. Con este servicio, se mapea un nombre común (por ejemplo www.google.com) con una dirección IP dada. Si esta dirección cambia, los servidores DNS se encargan de actualizar esta información, y así los clientes web solo deben consultar estos servicios si acaso se topan con que las cosas ya no funcionan como antes…

Sin embargo, este tipo de servicios tiene un precio, a menos claro que se sepa buscar bien y que se sienta uno satisfecho con lo que los servicios gratuitos pueden proporcionar. Yo en particular, lo hice en dynDns.org, en donde saqué una cuenta gratuita y después di de alta mi servidor, asignando la dirección IP que en ese momento tenía mi máquina con el nombre invernalia.homelinux.net. De esta manera, en vez de aprenderse la dir. IP, basta con teclear estas palabras para lograr el mismo efecto. Al ser un servicio gratuito, tuve que quedarme con el ‘homelinux.net’ (que tampoco se me hizo mala opción), y además dynDns proporciona otros nombres posibles para el dominio. Un servicio pagado a este mismo sitio permitiría elegir el dominio, y registrarlo, pero con esto me basta por ahora

Además, debe hacerse algo respecto al problema mencionado sobre los cambios de direcciones IP. Lo que debe hacerse aquí es tener algún programa que pueda comunicarse con dynDns.org, y que al detectar el cambio de dirección IP registrado respecto al que ahora tenga la máquina, le avise al sitio de la actualización que debe hacerse. Esto lo logré en mi caso utilizando ddclient, un programita que hace precisamente esto cada vez que se arranca la computadora (y existen un montón de estos programas, para diversos sistemas, dynDns.org da una amplia lista).

Por mientras, mi máquina está normalmente dando servicio de lunes a viernes durante las horas del día (en la ciudad de México), que son las horas en que me encuentro ausente de mi casa por mi trabajo, y dejo mi máquina haciendo algo de provecho De noche es menos probable que lo tenga, aunque se da el caso. Y definitivamente en fines de semana es muy poco probable que suceda, primero porque suelo llevarme mi laptop a la Casa de la Juventud, en donde o no me conecto a internet, o si lo hago es solamente para dedicarlo a la labor que hago allá (además de que tendría que configurar mi conexión inalámbrica y el router que tienen allá, y todo un rollo más…) Por otro lado cuando no estoy en la Casa de la Juventud, si estoy utilizando mi máquina, lo suelo hacer en cualquier lugar de mi casa, por lo que uso la conexión inalámbrica, y por lo tanto no da servicio Tal vez, el día que me consiga una computadora de escritorio, deje las cosas conectadas de manera más definitiva…

Apéndice, aplicaciones gráficas y no gráficas vía SSH
Bueno, falta comentar un punto más. Vía SSH puedo iniciar sesión en mi máquina de manera remota, y trabajar en ella como si estuviera frente a la misma. Sin embargo, lo más utilizado normalmente es iniciar sesión en modo texto y hacer uso de los programas en modo texto de Linux. Sin embargo, si se desea, también se pueden correr aplicaciones gráficas, y aquí está el como le hago yo:

Antes que nada, recordar que en Linux las aplicaciones gráficas funcionan vía un protocolo llamado XWindow, o X simplemente. Este protocolo funciona aproximadamente de la siguiente manera: se tiene un servidor X en la máquina que desplegará la aplicacion, y todas las aplicaciones que quieran desplegar gráficos hacen uso de los servicios de este servidor. Ahora bien, el servidor puede estar localmente en la misma máquina que las aplicaciones gráficas, o podría estar de forma remota en una máquina donde quieren ejecutarse las aplicaciones provenientes de otro lugar. Esto es lo que yo hago justamente.

Lo que se necesita es, primero que nada, un servidor X en la máquina que se conectará a mi computadora. Por ahora, puesto que utilizo Windows en mi trabajo (desde donde, secretamente, me conecto a mi compu ), necesito entonces un servidor X para Windows. El que yo utilizo es el de Cygwin (www.cygwin.com, hay que bajarse la utilidad de instalación del Cygwin, instalarlo y elegir entre muchas otras cosas que se deseen, el servidor X11, ya instalado se ejecuta Cygwin, modo texto y de ahí correr los scripts para iniciar el servidor en /usr/X11R6/bin, o directamente modo gráfico con los .bat de ese mismo directorio, no importan las aplicaciones gráficas de Cygwin en este caso, son para usar las cosas de manera local, lo que importa ahorita es el servidor X, que se queda ejecutando en Windows en la barra inferior de aplicaciones en segundo plano).

Una vez con el servidor X, el cliente SSH con el que uno se conecte a la máquina remota (yo utilizo PuTTY, pero podría usarse otro, como el mismo de Cygwin para una conexión entre dos versiones diferentes de Linux, aunque entre comillas una de ellas en fin, este cliente debe configurarse también para que las solicitudes X hechas a la máquina remota sean canalizadas vía SSH, en lugar de quedarse allá en mi computadora. Si no se hace esto, al querer ejecutar una aplicación gráfica, simplemente mi computadora intentará ejecutarla allá, y como estoy en modo texto no me va a dejar hacerlo por ello la canalización hará que la aplicación gráfica envíe las solicitudes a servidor X también vía SSH y acá el servidor X instalado se encargará del resto Así es como ejecuto aplicaciones gráficas sencillas. Si lo que se quiere es tener un entorno de escritorio y toda la cosa, el rollo es más complicado, aún no lo he hecho yo (tanto por falta de tiempo, como por falta de conocimientos, como porque mi conexión a internet desde donde me conecto es lenta, y creo que saturaría la red si mando llamar el KDE vía remota )

Introducción (lo que me llevó a escribir este post)

En febrero pasado adquirí una nueva computadora, debido a que la anterior sufrió un percance, y como no puedo estar sin computadora por mucho tiempo (por mi trabajo, por afición y por la Casa de la Juventud), adquirí algo que me siriviera por un buen rato, me agradara y me permitiera además tener un buen sistema operativo en ella para trabajar.

De entrada, la computadora venía cargada con Windows Vista, que sí es muy bonito para muchos, pero que no deja de tener graves defectos: primero que nada es software no libre, con lo que el precio es altísimo y la calidad malísima, tanto del sistema en sí como de la suite de oficina (Office 2007) y demás software acompañante… Además está lleno de problemas de memoria, es lento en muchas ocasiones, en fin… no es del todo de mi agrado. Fue por eso que, así como con mi computadora anterior, decidí instalarle alguna distribución Linux.

Pero como aún así lo necesito (para la Casa de la Juventud, y también para jugar ) comencé por particionar el disco duro (160Gb), quedándome con 35 para Vista (partición a la que llamé ‘Videogames’ y el resto lo preparé para Linux. Dicho sea de paso, en esos 35Gb le instalé software libre para Windows: aMSN, the Gimp, OpenOffice, etc. y me olvidé de las versiones piratas o legales pero privadas (carísimas o baratas pero en demo o con poco que aportar) de software como Photoshop, Corel, liveMSN, etc.

La partición la hice con el LiveCD para KDE (mi desktop manager favorito) que me bajé del sitio de openSuSE (http://www.opensuse.org/), pues con el particionador de Windows Vista (chafa para no variar) no me dejaba particionarle menos del 50% para ese tonto S.O. (en principio pensaba dejarle unos 45Gb a Windows, pero en vista de la jalada del particionador de este sistema, mejor lo castigue con 10Gb menos Por otro lado dejé una partición de 75 Gb con formato FAT32, para permitirme compartir información entre ambos sistemas, cosa que me resulta útil en gran extremo. De nuevo, hice uso del LiveCD de SuSE, pues el format de Vista no me dejó formatear tanto espacio, mientras que el particionador de SuSE sí.

Así pues, me quedé con aproximadamente 50 Gb reservados para Linux. Mi plan era particionarlo para los distintos directorios del sistema como hice posteriormente… Aunque podía bajarmelo de internet como ya lo he hecho varias veces antes, esta vez decidí en vez de bajarlo de internet, cooperar con la causa y pedí me enviaran a casa el DVD de openSuSE 10.3, pagando a Novell la módica cantidad de $80 USD (que mas gastos de envío, me terminó saliendo en unos $1000 pesos mexicanos ¿caro? ¡para nada! Aunque Windows Vista cueste solo un poco más, en realidad solo incluye el sistema operativo, la suite de oficina más común cuesta una millonada más, ni que decir del obligado antivirus para Windows, y demás software que si se comprara legalmente sería un precio muchísimo muy prohibitivo, mientras tanto esta distribución de Linux, lo mismo que muchas otras, incluye el sistema, suites de oficina (nótese el plural), juegos, software de utilidad variado, software para trabajar en múltiples campos, utilidades de internet que permiten bajar muchísimo más software sin pagar un quinto más (excepto por la electricidad y la conexión a internet claro , y todo por nada de precio, con mucha mayor calidad y la posibilidad de actualizar los programas gratuitamente).

Instalé pues el SuSE en mi máquina y en menos de un día ya lo tenía en el disco, prácticamente todo funcionando. Respecto a las particiones, haciendo un poco de caso del Linux Documentation Project, dejé una partición root (/) con 2Gb, /var con 4Gb, /usr con 15Gb y /home con 25Gb, el resto se lo dejé a la partición swap.

Problemas a los que me enfrenté y el reto de investigar cómo resolverlos

Solamente me atasqué en tres puntos:

• el video,
• la tarjeta de red inalámbrica (wireless) y
• el sonido

Respecto al video, el sistema no me reconoció la tarjeta de video incluida en la lap: una ATI Radeon X1200, y todo se veía a 800×600 pixeles (muy feo para mis gustos actuales), además de no reconocer el 3D que tanto deseaba

Respecto al wireless la tarjeta no era reconocida, y ni utilizando el ndiswrapper pude echarla a andar.

Respecto al sonido, la máquina simplemente no emitía nada de nada.

Así pues, me embarqué en la aventura (satisfactoria, divertida, llena de retos) de buscar vía la conexión alámbrica a internet con la que sí contaba, los medios para resolver estos problemas.

Wireless
Comencé por el wireless. Y como me resultó lógico, comencé a investigar en el sitio de openSuSE. Ahí encontré que efectivamente mi tarjeta wireless (una Realtek 8187B) debía ser instalada por medio de ndiswrapper, pero el driver proporcionado por Realtek no servía en mi caso, así que el consejo de opensuse.org no me sirvió tampoco Busqué en varios foros y la verdad me di por vencido, así que decidí enfocarme en el video y hacer lo del wireless después.

Video
Para el video, de nuevo consultando opensuse.org, comencé por seguir los pasos para instalar tarjetas ATI en SuSE. Con ello ya pude conseguir la detección de mi tarjeta, y un modo de video de al menos 1024×768 Pero resulta que mi tarjeta (Radeon X1200) no está ni siquiera, al menos explícitamente, listada en las tarjetas ATI en el sitio de AMD!!! Por lo tanto, los tips de opensuse.org para conseguir el 3D tampoco funcionaron

Audio
Decidí dejar el 3D para luego, y me fui por el sonido. La tarjeta es una Realtek AC97 (recuerdo que en otra máquina donde instalé Linux, el sonido también era de una Realtek y también me dio mucha lata), y de nuevo los consejos del wiki de openSuSE no me sirvieron de mucho (sin embargo para muchas otras cosas si que ha servido, por ejemplo para la webcam y los controladores propietarios para algunos formatos multimedia que necesitaba El caso es que para no rendirme, me puse a buscar en foros y blogs, ¡y me topé con esto!: http://www.jambitz.com/comunidad/linux/2008/02/22/instalacion-de-ubuntu-710-en-toshiba-a215-sp4057 un post de un usuario de Ubuntu 7.1, con el mismo hardware que yo!!! Y para él ya funcionaba el wireless, el video y el sonido, justamente los mismos problemas que yo tenía!

Wireless!!! (ahora sí, como lo conseguí)
Por ello, dejé el audio a un lado y regresé al wireless. Básicamente lo conseguí de la siguiente forma: el autor de aquel post se topó a su vez con http://www.datanorth.net/~cuervo/rtl8187b/, el post de otra persona que modificó el driver de Realtek (el que no me sirvió en un inicio) para echarlo a andar correctamente (en este caso, hay que bajar la versión modificada por el autor del post, la versión original no me sirvió, y la otra versión modificada por otra persona ni siquiera la probé). Lo que se hace simplemente es bajar la versión modificada, descomprimirla, compilarla como root (con ./makedrv) y listo! Cada vez que se requiera detectar la tarjeta wireless, se ejecuta (como root también) el script ./wlan0up. Se pueden seguir los consejos del README para echarlo a andar automaticamente al encender la computadora, o hacer como yo hice Modifique /etc/rc.d/boot.local y agregué path/a/wlan0up. Además en halt.local agregué path/a/wlan0down, el script que da de baja el driver cada vez que se requiere (en este caso, al apagar la computadora).

Audio
En el mismo post que encontré de jambitz, hallé la solución al audio:Se trata de un package encontrado en un sitio FTP (hasta ahora no se bien a quien pertenece, como para mencionarlo y de esa forma agradecerle :S ) El caso es que en ftp://209.216.61.149/pc/audio/realtek-linux-audiopack-4.07b.tar.bz2 se consigue el código fuente, que se compila y ejecuta con ./install (como root) (para esto, hay que asegurarse de tener instaladas las librerías libc6-dev, libncurses5-dev y gettext o similares, yo utilicé YAST para verificar esto, mientras que el autor del post en jambitz utiliza las utilidades de Ubuntu para lo mismo).

El package ejecuta una aplicación modo texto con Curses, a color y toda la cosa, y esta permite instalar la tarjeta de audio detectada. En mi caso es la ATI Technologies Inc SBX00 Azalia, la cual seleccioné.

Por último, debe modificarse también el archivo /etc/modprobe.d/sound, como root obviamente, y agregar la siguiente linea al mismo:

options snd-hda-intel model=toshiba

y al reiniciar la computadora, el audio queda listo!

Video (revisited y con un continuará…)
Y bueno, hasta aquí, ya había resuelto los problemas más graves, pero aún me quedaba el 3D. Mi problema consiste en que el 3D no es detectado, y SaX2 no me permite entonces configurar nada respecto al 3D. Conforme intenté resolver este problema, como describo más abajo, mi problema terminó con que el 3D era detectado, pero aún así el 3D no funciona, pues provoca que la pantalla se distorsione de un modo que no permite hacer nada
Ni los consejos del post en jambitz, ni los del wiki de opensuse.org, ni nada que leí aquí y allá me estaba sirviendo. Decidí suscribirme a los foros de opensuse que encontré: http://www.suseforums.net/, http://forums.suselinuxsupport.de/ y http://www.forosuse.org/forosuse/ (este último en español Estuve leyendo bastantes entradas en los tres, y varios consejos a otros foreros que probablemente me servirían. Toda la semana llegaba a mi casa para probar mis ideas, pero en vano. Terminé por escribir para pedir ayuda y describir mi problema, el de la distorsión en aplicaciones 3D en el mejor de los casos (o el de que mi máquina se cuelga completamente con ciertos juegos 3D también). La captura de pantalla del problema, ilustrado cuando intento ejecutar fgl_glxgears, la conservo en:
http://invernalia.homelinux.net/~jstitch/jstitch/linux/fgl_glxgears.png (el programa fgl_glxgears es como el glxgears, que debe desplegar unos engranes giratorios en 3D, pero es la versión del controlador de ATI).

Y sucede que, si quito el controlador ATI, no tengo ni tarjeta ni 3D por lo que quedarme con los controladores por default, los libres, no me sirve. Instalar los de ATI para mi tarjeta gráfica (que son propietarios), me deja con este problema. Una vez intenté instalar una versión anterior de los controladores pero me dejó sin video, pero olvidé correr el SaX2 -r para ver si así sí jalaba (es una prueba que tengo pendiente por hacer) y en fin… en cuanto al 3D aún estoy en espera de resolver este problema para poder conseguirlo, y jugar con estos efectos y demás cosas en mi linux CUALQUIER SUGERENCIA AL RESPECTO ES, POR SUPUESTO, BIENVENIDA

Video (revisited2 pero para otra laptop)
Lo que si pude echar a andar fue esta misma versión de openSuSE en otra laptop un año más vieja que la Toshiba, una Dell (no recuerdo el modelo), de mi esposa. Ahí los problemas del wireless y del audio no se presentaron. Mientras tanto en el video sí se detectó la tarjeta NVidia pero no el 3D, pero siguiendo los pasos del wiki de openSuSE todo quedó resuelto, y al menos ella ya puede gozar de esa ventaja (Lo que me lleva a concluir que en cuestión de instalación, las tarjetas NVidia son mucho más fáciles que las ATI lástima que se trate de una laptop en mi caso…)

Apéndice
Esta noche logré instalar el 3D exitosamente, coloco un post nuevo para comentarlo, gracias Carlos Rocha!

Nota: la siguiente crónica es parte mi historia personal, que comencé a escribir teniendo 28 años. La escribo solamente como ejercicio de autoreflexión. Si sirve para otros fines (como ejemplo, para ilustrar algo, para hablar de como crece la vocación de una persona, o como para darme trabajo etc.) no hay ningún problema por mi parte por el uso que se le de, ni siquiera sería necesario para mi el que me den crédito o que me avisen del uso que le den (aunque sería un honor, y un levantamiento de autoestima el saberlo , solamente pido que no se la apropien (por ser mi propia historia), ni que la modifiquen (es mi historia, no la de ustedes), y hacerlo sería de muy mala educación. Eso sí, se aceptan, como en todo, comentarios, correcciones y sugerencias, yo por mi parte me comprometo a sujetarme a la verdad (desde mi subjetiva perspectiva claro, eso no se puede soltar, menos si se trata de una perspectiva personal como es esta), para así corregir esto y atenerlo más a verdades que a suposiciones personales, siempre que no deje de reflejarse lo que yo creí en su momento, comparado con el hecho crudo y real…
—

Sobre como fueron mis primeros (y no tan primeros) contactos con las computadoras

o

Por qué terminé siendo programador

por Javier Novoa Cataño

La primer computadora que conocí en mi vida llegó a mi casa, cuando vivíamos en la ciudad de Monterrey (era importada de EU), y cuando yo era apenas un niño pequeño, a inicios de los 80s. La máquina era una variante de la Commodore 64 adaptada a los ‘gráficos’ en pantalla (un aparato de TV cualquiera): se trataba de una VIC 20 cuyo sistema operativo era programable vía lenguaje BASIC.

Ya a mediados de la década, mi papá nos compró a mi hermano y a mi un par de libros para niños sobre dicho lenguaje, que junto con el manual de la Vic20 se convirtieron en mi primer contacto con los lenguajes de programación de computadoras. A mi hermano, hoy en día arquitecto, no parecieron interesarle mucho dichos libros, pero casualmente a mi me llamó la atención, sobre todo por la posibilidad de teclear unas cuantas cosas para obtener a cambio los sencillos juegos que se proponían en los libros, además de los efectos visuales de la Vic. Sin embargo, como niño, no le presté demasiada atención a un juguete tan complicado, y si el gusto me duraba dos días, ya era mucho.

Posteriormente tuvimos Ataris 2600 y Nintendos, computadoras poco programables desde la perspectiva de un niño como era entonces interesado en jugarlos nada más, por lo que mi siguiente contacto lo tuve estando ya en la escuela, a nivel primaria, en la segunda mitad de la década y principios de los 90s: como la escuela era particular (y para ese entonces soñar con computadoras en las escuelas era casi un imposible muy guajiro) contaban con una salita de cómputo con unas hoy viejas Macintosh ][. Lo primero que recuerdo haber aprendido fue lenguaje Logo, para hacer dibujitos con la famosa tortuguita Pero después cambiaron por enseñar BASIC, y ahí tuve mi segundo contacto con los lenguajes de programación. Claro está. para esa época, no le resultaba nada interesante a un niño aprender ni a dibujar ni a programar en un aparato como esos, así que básicamente lo que más nos interesaba (a mis compañeros y a mi) eran las sesiones en que podíamos entretenernos con los sencillos videojuegos que tenían los maestros. El resto de las sesiones (eran semanales si no mal recuerdo), consistían en aburrida teoría llevada al nivel de niños, junto con práctica en unos cuadernos de ejercicios, junto con un ratito de videojuegos. Lo que sí sucedió a raíz de estas clases fue que, cuando perdía interés en los videojuegos (cosa que no sucedía muy seguido), y cuando mis hermanos me dejaban libre la televisión de mi casa, y no había una buena caricatura que ver claro está, a veces reconectaba la Vic para programar los juegos de aquellos libros que nos regalaron.

Todo esto lo menciono como prehistoria en realidad, jamás me tomé en serio el trabajar con computadoras, ni programarlas, administrarlas o armarlas y desarmarlas. Para mí sólo eran aparatos sofisticados (y caros para la economía de mis papás) con los que, luego de un rato de concentrarse, se podía poner uno a jugar con ellos. El lenguaje que medio aprendí en ese entonces, BASIC, de hecho casi no lo volví a tocar más que en ocasiones muy contadas, sobre todo una vez en que traduje un juego en dicho lenguaje (con QBasic) a C, en mis épocas de estudiante universitario, y en realidad tampoco me ha llamado jamás la atención ninguna de sus ‘variantes’ visuales. Tampoco podría contar el siguiente aparato que programé: un juego de submarino electrónico, en donde programabas las coordenadas de tus barcos, lo mismo que hacía tu oponente, y luego simplemente podías teclear las coordenadas de tu enemigo, y el sistema te decía con luces y sonidos si le habías dado a un barco o al agua. Este juguete fue regalo de unos padrinos que teníamos en común mis hermanos y yo. Ni que decir del primer horno de microondas que tuvimos, o las videocaseteras, televisores, modulares y radios Así pues, mi verdadero primer contacto tuvo lugar unos años más tarde…

Cuando iba ya en secundaria (12 – 15 años, en la primera mitad de los 90s), sucedieron un par de cosas que me impulsaron a decidirme por una vocacion: en primer lugar, la escuela contaba con sala de cómputo (por lo que veo, creo que fui testigo de la primer avanzada de computadoras en escuelas públicas en México…). Así mismo, un tío que en la familia de mi papá siempre se caracterizó por contar con computadora con la que los sobrinos siempre llegábamos a las reuniones familiares a pedirle que nos dejara jugar en ella, él nos regaló una computadora: una Acer con procesador 386SX, a fabulosos 8Mhz y un botón de turbo que le dejaba ir a 16!!! jajaja. Contaba con un disco duro con la grandiosa cantidad de 40Mb de espacio! que con un programa se podían duplicar fácilmente a 80Mb (recuerdo aún cuando oía hablar de discos de más de 100Mb, me parecían una maravilla! jeje). En fin, venía equipada con MS-DOS ver. 3 (o era 4?), y un entonces desconocido Windows 3.1 (así es, soy, como muchos mexicanos y prácticamente terrestres, que en sus inicios con las computadoras tuvieron el contacto con las PCs a través de Microsoft y su afamado Windows). Recuerdo que la suite de oficina era de Lotus, el procesador de palabras un viejo AmiPro, además del clásico MS-Works. Por otro lado, en la escuela, tenían equipos muy similares al de casa, con MS-DOS (pero sin disco duro y sin Windows), con Works vía diskettes (en ese entonces todavía se conocían los de 5 1/4″!!! y comenzaban a ser desplazados por los hoy también casi obsoletos de 3 1/2″…).

En fin, en esa época ya me había olvidado de programar, salvo sesiones aisladas de (otra vez) BASIC (con GwBasic) en la secundaria, y sin embargo gracias a ciertas revistas de computación que mi papá compraba, aprendí y me comencé a foguear en aquello de configurar la PC de mi casa, desde ponerle un color diferente al prompt del MS-DOS, hasta configurar el sistema con los archivos AUTOEXEC.BAT y CONFIG.SYS. Además, la computadora de mi casa (que en algún momento fue sustituida por una 486 que nos regalaron los mismos padrinos del submarino) contaba también con un curioso aparato externo que me permitió abrirme al mundo: un modem!!! De tan solo 56kbps, era suficiente para visitar algunas páginas de la naciente WWW con Windows. Sin embargo, mi primer cuenta de email no la obtuve hasta muchos años después, en mi época universitaria. El internet para mi fue entonces solo para navegar por sitios de Yahoo! y otras pocas cosas que apenas conocía. Sin embargo, el proveedor del servicio de internet (ISP) que nos dio mi tío (una compañía conocida como Spin), nos daba acceso también a un BBS que me resultó particularmente interesante. Ya que entonces no programaba, lo que más hacía, junto con mis hermanos, era jugar (además de las necesarias tareas escolares, impresas con la impresora de matriz de puntos que teníamos ) Y en el BBS de Spin por cierto, encontré algunos juegos extra a los que ya tenía: de carreras, de peleas, etc. Además había un acceso a un MUD para jugar en línea en una especie de juego de rol vía puros comandos y descripciones de texto. En este lugar también conocí NetHack, en su versión PCHack, y gracias al internet, me volví adicto a ese juego de arcaica interfaz de texto pero jugabilidad extrema… Cabe mencionar que al poco tiempo perdimos nuestro acceso a internet, y durante algunos años estuvimos haciendo uso, ilegal, de cuentas Telmex que conseguíamos aquí y allá (si, ya se que estuvo mal, aunque en esos días uno como niño no lo ve así, hoy lo reconozco En fin, otra experiencia más se sumó a mi historia: al poco rato el modem dejó de funcionar por una tormenta eléctrica que cayó en la cercanía (desde entonces aprendí a desconectar mis aparatos cuando no los usaba, y si no contaba con regulador ) Y por ello, mi papá nos compró un nuevo módem, esta vez interno (y luego le siguió otro más, más rápido que el anterior). Y así fue como comencé a foguearme en otra área en la que me se desenvolver: abrir, armar y configurar computadoras. Pues fui yo, de hecho, quien abrió la máquina y le instaló y configuró el nuevo aparato. Entonces recordaba cómo a veces mi tío solía tener su computadora completamente abierta, cuando le hacía reparaciones o que se yo, y de vez en cuando así lo hacía yo también

En fin, que mi único nuevo contacto con la programación lo tuve también gracias a que en realidad nunca fui malo en los estudios, y por un concurso de matemáticas a nivel 2do de secundaria en la escuela, terminé en primer lugar, con lo que me gané una calculadora, de esas Casio programables y que permiten graficar, pero en sus primeras versiones, no como las de hoy en día. Aunque me llamaba la atención la graficación, a lo que creo que le saqué más jugo fue a la programación. Bueno, aprovechando que ando confesando cosas, debo decir que una vez, en Historia (otra de mis materias favoritas, pero en esa época era sólo un adolescente casi niño sin demasiada moral), utilicé mi calculadora para escribir un acordeón de la materia con el que pasé bien ese examen. Jamás lo volví a hacer, pero bueno, así sucedió (como que con estas cosas uno aprende la lección de Spiderman… detrás de un gran poder hay siempre una gran responsabilidad ) En fin, el otro uso, también deshonesto pero no del todo, que le di, fue programar fórmulas de física y matemáticas en la misma. Casi siempre he pensado que eso de memorizar no se me da, como que me da flojera memorizar, y siendo sinceros el sistema educativo en México está hecho para memorizar. A mi lo que me gusta es razonar, deducir, y así entender las cosas y por lo tanto aprenderlas. Si en la escuela me hacían aprender la fórmula del área del círculo (pi * radio * radio), me hubiera gustado aprender ‘por qué’ era así, y no solo aprender la fórmula y ya (eso, gracias a Dios, y a mis maestros, lo aprendí años más tarde, en el bachillerato, la carrera y el posgrado, no sólo sobre el área del círculo, sino también otras fórmulas y procedimientos, desde el algoritmo del mínimo común múltiplo o la fórmula del chicharronero para encontrar las raíces de una ecuación de segundo grado, hasta la ley de Newton, el teorema de Pitágoras generalizado, y otras tantas monerías que nos hacen memorizar, pero no entender, en la escuela). En fin, que para algunos exámenes, más como una vía de estudio que como un medio para hacer trampa, me gustaba programar la calculadora con la fórmula ya bien aprendida, de manera que el programa me pidiera los datos de entrada y me arrojara el resultado como si yo lo hubiera tecleado en el aparato. Puesto que a ese nivel ya nos dejaban utilizar calculadora en los exámenes, me fue fácil hacerlo, y la verdad, no le veía el caso a memorizar la fórmula, y ya desde entonces utilizaba esa vieja tradición de los verdaderos programadores, de ahorrarse trabajo en donde se pueda. Al menos así además de memorizar, me ahorraba la tediosa labor de estar tecleando en la calculadora durante el examen, junto con el tonto riesgo de teclear mal y por una tontería tener un mal acierto en el examen Eso sí, hice mal en pasarle el truco a algunos compañeros, y con el pretexto de ‘maestro, le puedo prestar mi calculadora a fulanito’, ellos simplemente invocaban el programa que previamente les había enseñado a usar, y anotaban sus resultados Lo que tuvo de malo ese hecho fue que, precisamente, ellos no entendían eso de programar el aparato, y sólo buscaban el resultado final (aunque, desde la perspectiva en que hoy me encuentro, puedo decir que ya entonces utilizaba unos cuantos conceptos en los que hoy creo firmemente: el uso libre y compartido de la información (no los aciertos de un examen, claro, sino el hecho de permitirles usar mis programas sin restricción), la importancia de contar con usuarios que prueben tus sistemas y el hecho de que en principio los usuarios generalmente (aunque no siempre) están interesados en los resultados, no en los rollos técnicos que te llevan a conseguirlo). Y antes de terminar, aclaro: cuando en secundaria participé a nivel regional, estatal y federal en los concursos que organizaba la SEP para probar los conocimientos a nivel secundaria, jamás usé esas trampas, trucos, programas y algoritmos, en parte por que sabía que era lo correcto, además porque sería injusto para los otros concursantes que no contarían con ese medio, y también por miedo a que me descubrieran haciendo trampa (lo viera yo o no así), a todo eso también había que sumarle el hecho de que previamente debía conocer qué fórmulas ocupar, pues la memoria de la calculadora era muy poca (sin embargo esta no era la razón más fuerte, me hubiera bastado con capturar las fórmulas más difíciles y ya . Y la calculadora siguió funcionando varios años más, sin embargo aunque seguía usándola de esta forma de vez en cuando, en ocasiones importantes (exámenes finales, trámites de admisión y démás), no la usaba más que como calculadora normal, salvo por las gráficas

Y fue en esos días, cuando todavía se es niño y llegan a preguntarte ‘¿qué vas a estudiar cuando seas grande?’ que les contestaba que quería estudiar lo que fuera, siempre y cuando tuviera que ver con computadoras. Aunque unos años después en realidad no recordé ese hecho, y muchas otras áreas del conocimiento también me llamaron la atención (las matemáticas, la química…) Pero como en ese entonces tenía esa idea, cuando llegó la edad para avanzar al nivel preparatoria, terminé quedando dentro del IPN (mi hermano también, pero desde entonces también el se fue por el dibujo técnico y posteriormente la arquitectura). Yo me fui a Voca 9 (el CECyT Juan de Dios Batiz, homóloga por cierto de la secundaria donde estudié), y tuve todo un primer año para decidirme por una carrera técnica. Aquí, resultaba casi lógico que me hubiera decidido por la carrera de técnico en Programación, soñaba con hacer juegos y demás. Sin embargo, otra área ya me venía llamando la atención desde niño: alguna vez los reyes magos nos regalaron un kit de electrónica muy interesante: podías armar y desarmar fácilmente circuitos sencillos, con los que ibas aprendiendo cómo funcionan los mismos, para que sirven los distintos componentes y bueno, siempre me ha gustado ese juguete (gracias reyes magos! Y si le sumamos mi naciente experiencia abriendo, armando y configurando computadoras, terminé optando por la carrera de técnico en Sistemas Digitales, opción recurrente que me seguiría los pasos años más tarde también. Y la verdad, fue una gran experiencia: aprendí de electrónica y de cómo funcionan las computadoras POR DENTRO, antes de irme a las afueras. Y no solo eso, la currícula de la carrera incluía además dos semestres enteros de programación, así que no me fui con las manos vacías. Y ahí aprendí el lenguaje que se convirtió desde entonces en mi lingua franca, algo así como el español para mí: el lenguaje C. El maestro, casualmente, era compañero de trabajo (en otro trabajo que tenía) del mismo tío nuestro de las computadoras. Y aunque en ese entonces no me volví experto programador, era bueno. Programábamos vía MS-DOS, utilizando el Borland C 4 (sucesor del Turbo C que nunca llegué a utilizar) y ahí si, me comencé a adentrar en el fabuloso mundo de la programación.

Fue por ello precisamente, que al momento de elegir carrera, y escuela para estudiar, terminé optando por ESCOM (la escuela superior de cómputo, del IPN). Pocos compañeros míos eligieron la misma opción, casi todos se fueron a UPIITA, en donde continuabas con la electrónica (y oh sorpresa, la mayoría de ellos, por lo que se, ahora trabajan como programadores el campo laboral es más amplio en esa area que en electrónica aquí en México…) En ese entonces, ESCOM era relativamente una nueva escuela (no tanto como UPIITA, pero solo por unos pocos años), y comencé a estudiar ahí en 1998 (y otra casualidad: la calle sobre la que se encuentra ubicada ESCOM se llama también Juan de Dios Bátiz!). Durante el primer año, de tronco común, aprendí más lenguaje C, desde lo básico otra vez, hasta técnicas de programación más avanzadas, estructuras de datos y otras monerías muy interesantes. Pero al año, tenía que elegir especialidad, y las opciones eran: sistemas (enfocada sobre todo a la programación), y electrónica. Y sí, volví a decidirme por la electrónica, no se porque tengo eso, pero me llama mucho la atención, a pesar de que no me dedico a ella, y casi ni siquiera lo tengo como hobby, ni leo mucho de ella. En fin, resultó después que el programa curricular de electrónica era el más parecido a lo que había en ESCOM antes de que existieran las especialidades, y según muchos maestros, seguía siendo la especialidad más completa. De hecho, seguía habiendo lenguajes de programación, bueno, más C, y después un año de C++, que aunque aprendí bien, no utilicé mucho, aquello de la orientación a objetos aún no me entraba en la cabeza, sino hasta años después.

Y lo que son las cosas, el proyecto terminal que realicé con otros 3 compañeros (en ESCOM, para titularte, debes hacer un proyecto de un año), no tuvo que ver con electrónica, sino con un sistema Eso sí, durante esos 3 años aprendí bastante de electrónica: llegamos a hacer un brazo robot, un elevador a escala, un termómetro digital… y otra de las cosas que desde la vocacional me gustaron: el eslabón perdido entre electrónica y programación, aprendí lenguaje ensamblador para varios microprocesadores y microcontroladores. En total, he programado el Atmel Z80, un par de PICs, el 6502 y otro 65xx que no recuerdo (y del 8080 sólo lo llegué a programar muy poquito vía la utilidad DEBUG del MS-DOS). Me sigue gustando el ensamblador, pero no me dedico mucho a ello, y aunque no me dedicaría para vivir a ello, si le entraría de repente a algún proyecto. De hecho, me bastaría con conocer un juego que descubrí hace menos de un año, Core Wars, en donde cada guerrero es programado en una especie de mini-lenguaje ensamblador llamado Redcode, ya que me pueda dar un tiempo me pondré a ello

En esos años, ya no teníamos la vieja 486, sino una Pentium II que mi mamá compró a través de una tanda que organizó aquel tío también. Digamos que oficialmente pertenecía a mi mamá, en la práctica pertenecía a todos, pero administrativamente era yo quien la configuraba, administraba y mantenía en buen estado Y finalmente, es de las computadoras más lentas que mi papá tiene en su negocio de cibercafé hoy en día.

En fin, mi proyecto terminal, como dije, fue un sistema, de prediagnóstico de anemias, utilizando análisis de imágenes de muestras de sangre. Un compañero y yo nos dedicamos exclusivamente al análisis de las imágenes: separar cada objeto-célula, determinar tamaños, números y formas para dar un prediagnóstico de posibles anemias. El sistema también tiene un módulo de base de datos para almacenar información de historiales médicos (esto lo realizó una de las compañeras), y parte de esa información junto con los resultados del análisis de imágenes es utilizada por una red neuronal (labor de la otra compañera) que aprendiera a determinar también la posible existencia de síntomas de anemia en el paciente. Lo programamos todo para Windows, utilizando el Borland C++ Builder 5, ese que tiene ventanas programadas en Delphi (una especie de sublenguaje de Pascal). Hoy en día no lo programaría así como lo hicimos, para empezar porque no utilizamos el potencial que nos brindaba C++, casi todo fue C y no aprovechamos ni la posibilidad de hacer objetos (salvo las ventanas que C Builder ya crea), ni la API que ya viene con el paquete. Eso sí, nos ganó el derecho no sólo al título de ingenieros en sistemas, sino también a un breve reportaje de televisión

Nótese como, hasta entonces, seguía programando en Windows, como a la fecha lo hago en el campo laboral la verdad más por necesidad que por gusto, y sin embargo, desde que tomaba clases de computación en la secundaria, cuando te enseñan la historia de la computación y esas cosas, te hablan de arcaicos y gigantes sistemas como la ENIAC o la UNIVAC, te mencionan las tarjetas perforadas (que yo jamás he visto una en ‘tiempo real’ ), y por ahí se cuela la información de que existe algo llamado Unix, pero hasta entonces jamás lo había conocido. En ESCOM, durante la materia de programación, una vez tuvimos unas prácticas para programar en Unix, utilizando el editor vi y el compilador cc para generar unos muy sencillos programas, y en la materia de sistemas operativos obviamente se mencionaba, sobre todo para hablar del tema de semáforos y demás cosas que tiene Unix, pero no recuerdo qué pasó con las prácticas, el caso es que no tuve contacto directo con ese sistema. Y otra vez se nos presentó la oportunidad de instalar Linux en la máquina, una versión del Mandrake, sin embargo no nos dio tiempo y para entonces olvidé que existía algo llamado linux, unix y demás. Si además tomo en cuenta lo que se de historia al respecto, Linux comenzó a hacerse un fenómeno comercial en el 98 (año en que yo entré a ESCOM), y para el año en que estaríamos instalándolo en nuestra máquina escolar, sería para el 2001 o 2002, no se si a esa altura, por nuestro nivel de conocimientos sobre todo, ya habríamos podido instalar Linux (tomando en cuenta que a la fecha, me sigue llegando a costar trabajo algunos detalles, aunque hoy en día ya lo veo como un reto y un gusto, pero en ese entonces probablemente me hubiera frustrado de inmediato) (Nótese también cómo sí me gusta la historia! (en este caso de la computación, pero de otros campos también me gusta) espero con eso redimirme de mis trampas de secundaria )

Al terminar la escuela, casi de inmediato conseguí trabajo, programando PDAs. Yo me dedicaba a utilizar el Embedded Visual C++ (aunque en realidad casi todo seguía haciéndose en C) para programar Pocket PCs en Windows CE. Ahí también aprendí en la práctica el SQL para comunicarme con bases de datos, y el Power Builder, un lenguaje para programar ventanas de Sybase, pero así como todos los demás lenguajes de ese tipo, me desagradan muchísimo… De esa época támbién viene mi primer gran éxito profesional y electrónico: con mi sueldo me pude comprar mi primer computadora. Pero puesto que las de marca son caras, y puesto que ya sabía desde antes que las armadas, bien armadas, son buenas, me fui un día al centro de la ciudad de México con mi hermano a comprar el gabinete, fuente de alimentación, tarjeta madre, microprocesador, memoria, disco duro, lector de CDs, bocinas, monitor, teclado y mouse (óptico) con los que armé también mi primer computadora enterita Y dio varios años de buen servicio como a la fecha lo sigue haciendo en el negocio de mi papá a donde fue a parar recientemente.

Podría decirse que gracias al desencanto que mi primer trabajo me provocó, decidí regresar a la escuela dos años después (en la empresa solo estuve año y medio, el medio año restante sobreviví con mis ahorros, casi no la libro, estudiando para el examen de admisión). Así fue como llegué al CIC (Centro de Investigación en Computación) del Poli también. Años antes ya sabía de las maestrías en este lugar, y de hecho barajé la posibilidad de hacer la maestría al terminar la escuela, nada menos que en Sistemas Digitales (más electrónica!), pero conseguí trabajo y lo olvidé, y al final me metí a Ciencias de la Computación…

En el CIC retomé el gusto por las matemáticas, materia en donde conocí a quien sería mi asesor de tesis. También aprendí algunas cosas que en la escuela, al haber tomado electrónica, no aprendí: sobre todo teoría de autómatas y teoría de la computación en general, materia que por cierto, siendo muy matemática, me encantó, a pesar de lo difícil Y también programamos otro PIC en una materia donde volví al ensamblador y donde aprendí de gramáticas, parseadores y analizadores léxicos (otra de las carencias del área de electrónica de ESCOM). También comencé a aprender Java, primero de manera muy amateur, y luego por mi cuenta con más dedicación, pues estaba decidido a realizar mi proyecto de tesis utilizando ese lenguaje. Relacionando las matemáticas, la programación, los autómatas, y los sistemas complejos que ahí conocí (y a los que también les agarré mucho gusto), fue como terminé conociendo los autómatas celulares (ya había oído hablar desde chico del Juego de la Vida, que me parecía interesante, pero no sabía que esos bichos tuvieran más aplicaciones…). Y fue así como, en relación con mi futuro asesor de tesis, me metí al tema de la modelación y simulación de flujo de tráfico vehicular con autómatas celulares. Mi tesis estuvo dedicada a la invetigación de un modelo con autómatas celulares más general que los que ya existían, aplicado en particular a analizar la probabilidad de ocurrencia de accidentes de tráfico. Aún me falta hacerle su página web (el proyecto de ESCOM sí que la tiene: proyecto SIPRA http://members.tripod.com/~sides_escom/), pero ya lo haré cuando tenga tiempo Por cierto, el haber entrado en contacto con Java, y gracias a un interés que despertó en mi poco antes de entrar al CIC, me permitió retomar la orientación a objetos y ahora es uno de mis paradigmas favoritos

Además, aprendí dos actitudes fundamentales: la de investigar y la de tener iniciativa para crear las herramientas cuando se necesitan y no se tienen a la mano… Hoy en día además de ingeniero en sistemas, programador o maestro en ciencias, me autodefino también con intereses en la investigación, área por cierto muy castigada en la economía de mi país, y que la verdad no se lo merece…

Y también en el CIC volví a encontrarme con otra materia que en ESCOM conocí durante un semetre y que me encantó: sistemas operativos. (También tuve una materia de inteligencia artificial que dejó mucho que desear, hoy pienso que me hubiera encantado si me enseñaban LISP, pero aprendimos Prolog (que no es tan malo la verdad), pero a medias (lo cual si es malo), y el área de IA que también siempre me ha llamado la atención, la he dejado postergada desde entonces, ya veremos si otro día con más calma…)

Durante este período, estuve becado por CONACyT, y con mi primer beca me compré mi primera laptop, y que disfruté bastante hasta un desgraciado incidente… (por cierto esa primer beca llegó como 3 meses defasada (esó sí, acumulada), y yo muriendo de hambre porque estuve así con los puros ahorros de mi anterior trabajo! y no lo hubiera logrado si mis padres no me hubieran ayudado en esos precarios tiempos)

Bueno, estaba con los sistemas operativos, y ahí nos enseñaron programación avanzada en nada más y nada menos que UNIX! Y como requisito, había que instalar por lo menos una partición de Linux en una máquina. Así fue como me adentré de lleno en Linux. Unos años antes un primo me había regalado una versión de RedHat que pude instalar en mi casa pero nunca usaba por la dificultad de configurarlo, y luego también obtuve un LiveCD de Mandrake y otro de Ubuntu, pero tampoco les hice caso. Fue hasta que en esta materia tuve que hacerlo que me di cuenta de la maravilla que en realidad es Comencé por instalar Fedora Core 3 en la máquina que tenía en la escuela, y también en mi casa y en mi laptop (que luego subí a Fedora 4). Posteriormente opté por SuSE Linux, en ese entonces 9.1, en mi casa y laptop, pero en la escuela seguí con Fedora 3, y de hecho en esa máquina y con ese sistema operativo realicé todo mi proyecto de tesis: aunque programado en Java que para entonces aún no era GPL, editaba los archivos con kdeveloper, compilaba en kconsole (en lo personal a mi siempre me ha gustado más KDE que GNOME, aunque este último no está nada mal), depuraba también en la consola (siendo novato, no me quedó de otra más que depurar con puras impresiones de líneas que me informaran del estado de mi programa, fue una labor muy difícil, pero al final salió bien , el documento de tesis fue hecho todo en LaTex, con imágenes editadas en The Gimp, y el CD que entregué fue quemado con K3B. En otras palabras, no sólo me adentré en Linux, sino también por consecuencia en el software libre (o de código abierto, para mi la diferencia en cuestión del resultado final es mínima, y las diferencias filosóficas, que si me importan, no las veo tan graves, solo es cuestión de como se miren las cosas, desde puntos de vista diferentes, pero viendo el mismo objeto: el software y cómo se desarrolla). Entré así al mundo del software libre, gracias a las pláticas con un compañero mucho más enterado en el tema, y desde entonces me he vuelto desde un fan, hasta un pequeño aprendiz de hacker , con intenciones también de desarrollar al estilo open source, y por que no? hasta de hacer negocios y vivir de ello! (y aquí abro un importante paréntesis: con hacker me refiero al significado original de la palabra, con orígenes desde la década de los 60’s, hablando de ‘verdaderos programadores’ y nada que ver con crímenes informáticos… más info. en ‘HOWTO become a Hacker’ de Eric Raymond http://catb.org/~esr/faqs/hacker-howto.html, una traducción al español aquí: http://mx.geocities.com/nickidname/principal.html, pero advierto que la traducción no tiene fecha de última modificación y no puedo asegurar que esta traducción esté actualizada respecto a los últimos cambios que se hayan hecho en el original en inglés. También recomiendo el resto de escritos de Eric Raymond (http://catb.org/~esr, sobre todo la serie que se relaciona con ‘La Catedral y el Bazar’) y para contrastar y complementar, también los de Richard Stallman (http://www.gnu.org/, sobre todo el Manifiesto GNU y todo lo relacionado a Software Libre), y el sitio de la Open Source Initiative (http://www.opensource.org/)) (en estos sitios suele haber links a traducciones en español y otros idiomas también)

En principio en mi casa usaban el SuSE 9.1, yo los exhortaba a ello y de hecho les gustaba, pero luego por un problema con el Windows 2000 que tenía instalada la máquina, tuve que reformatear, reinstalar todo, y el Linux también tuvo que ser modificado, pero ya no lo configuré tan bien como antes, no tenía mucho tiempo entonces, y empezó a quedar en el olvido, desafortunadamente. Por fortuna, con mi novia (ahora esposa), si tuve más éxito: le instalé OpenSuSE 10 a su laptop y a la fecha lo tiene instalado y lo usa de vez en cuando. Hoy en día que acabo de instalar OpenSuSE 10.3, estoy por atacar de nuevo para que lo use de manera más definitiva Por cierto, el por qué llegué a OpenSuSE 10.3 tiene que ver con un reciente fracaso mío, del cual aprendí una valiosa lección: adquirí una nueva laptop debido a que la anterior se echó a perder definitivamente. Tenía un problema con el contacto donde se conectaba la corriente eléctrica, y teniendo experiencia con armar y desarmar computadoras de escritorio, se me hizo fácil desarmar esta, soldar bien la patita que tenía el falso, rearmar y volver a encender. No se en sí en donde estuvo el problema, pero me atrevo a decir que no fue en el armado/desarmado de la máquina (aunque al final me sobraron como tres tornillos jajajaja), sino en el soldado que hice, muy sin precauciones, y el caso es que la máquina encendía pero no arrancó de nuevo. Algunos decían que no se veía el video, pero la verdad es que ni eso era, simplemente no arrancaba, no parecía que siquiera entrara a las rutinas de arranque… al menos así me conseguí una nueva máquina, que ya me merecía y necesitaba y aprendí a no meterme con laptops aún y a ser más cuidadoso al soldar circuitos, que no son como los de la escuela : Por otro lado, hoy en día me reinvindico también de cuando adolescente me pirateaba cuentas para acceder a internet, pagando la mía propia, inalámbrica por ser más práctico en una casa tan pequeña donde es mejor tener dos laptops a computadoras de escritorio

Y por otro lado, desde el 2002 tuve mis primeros contactos con el HTML para páginas web. Hoy en día soy el responsable de la página web de un movimiento al que pertenezco (http://www.torcasajuv.com/), pero gracias a un compañero que me brindó mucha ayuda en el período 2004-2005 y a lo que aprendí de aquel amigo con quien hice mi tesis en ESCOM, empecé a tener contacto con un lenguaje de programación más: PHP, que relacionado con MySQL lo he convertido en una potente herramienta para otra área que me interesa: el desarrollo web. Me he metido un poco al ActionScript de Flash, no tanto como me gustaría, pero tampoco tan poco como para no saber, aunque puedo vivir sin ello y también se de javascript.

En fin, terminando el programa curricular de la maestría (que no la tesis, me tardé todavía un año más, en junio pasado apenas presenté mi examen de grado, salí con mención honorífica!), entré a trabajar en un lugar en donde básicamente se dedican a Java, por lo que me he especializado más en ese lenguaje, aunque sinceramente no me llama mucho la atención la certificación, por ahora. Pienso que me interesa más aprender más cosas en vez de enfocarme ahorita en un solo lenguaje. Quisiera certificarme eso sí en administrar sistemas Linux, pero en cuanto a programación me gusta más quedarme abierto a muchas posibilidades. Hoy en día estoy estudiando Python, y me está pareciendo muy interesante. Como práctica, me conseguí el código de Cage (http://www.alcyone.com/pyos/cage/), que modifiqué para agregar la funcionalidad de autómatas de simulación de tráfico (si les interesa les paso mis modificaciones, aún no consigo contactar con el autor para que, si quiere, las suba también).

En conclusión (por fin!!!) estos son los lenguajes de programación con los que me he visto inmiscuido:
-C / C++ (al ‘natural’ y también con las APIs y entorno de Borland C++ Builder y de Embedded Visual C++, también he manejado un poco el STL para C++)
-Java (en aplicaciones de consola como mi tesis, gráficas con Swing muy poquito, y aplicaciones Web, además es el lenguaje con el que he estado trabajando más últimamente)
-PHP, HTML, javascript y actionscript de flash (en estos también me he estado metiendo mucho últimamente)
-BASIC (suficiente, pero no me pidan aprender VB y esas cosas, no me laten…)
-Python (en proceso de aprenderlo)
-LaTex para generar documentos
-Prolog
-Logo (muy poquito y hace centurias…)
-Delphi (muy de refilón, por mi contacto con el Borland C++ Builder)
-SQL para acceder a bases de datos, en Sybase iAnywhere (para PDAs), MySQL y Oracle (junto con los famosos PLs)
-Lenguajes RAD (PowerBuilder de Sybase y Forms de Oracle) (me da pena mencionar estos, pero asi ha sido…)
-Ensamblador del Z80, 6502, 65??, 8080, Redcode (:P) y dos PICs (que no recuerdo sus números, uno en ESCOM y otro en el CIC, pero algo que he aprendido es que en ensamblador, como en otros lenguajes, contar con documentación, y fundamental acceso a internet para investigar, dispara mi potencia de programador a una muy gran escala y no es para mi necesario saber las cosas de memoria, sino saber dónde buscar para aprender y desarrollar…)
-ShellScript de Unix, Batch de MSDOS
-Lenguajes matemáticos: Octave (que usé para mi tesis de maestría) y Matlab (que use a lo largo de la maestría)

Además, en computación he tenido experiencia en las siguientes áreas:
-Programación (ahí está la lista de lenguajes que he tocado al menos una vez en mi vida)
-Desarrollo web
-Administración de sistemas, mejor si son Linux/UNIX (no a nivel profesional, sino en mi casa , pero la verdad me gustaría muchísimo conseguir un trabajo o proyecto que tuviera que ver con este sistema, desde programar en él, hasta incluso administrarlo…) (he instalado exitosamente Fedora Core, RedHat y openSuSE en PCs, y configruado varios servicios locales. Últimamente me he querido meter, además de más configuración, en levantar servicios en red para trabajar remotamente en mi compu estando en otros lados aunque no llevo mucho aún)
-Análisis y diseño de sistemas, utilizando sobre todo UML, pero no necesariamente
-Paradigmas de programación (orientado a objetos y procedural, me interesan los agentes pero nunca me he metido)
-Mantenimiento de computadoras (a nivel hardware y electrónica, circuitos lógicos y demás chucherías)
-Bases de datos (creación, mantenimiento, desarrollo de consultas y procedimientos, y reportes en CrystalReports) (aunque la verdad, ya me estoy cansando de hacer puros sistemas que sólo tienen que ver con consultas a bases de datos, en el clásico esquema de consultas, altas, bajas y actualizaciones sin más nada (y el que tengan procedures y triggers no los hace más interesantes para mi, eh?), pero tambien soy consciente que son lo que más hay hoy en día para desarrollar y mantener…)

En otras áreas que se pueden relacionar con programación o computación en general, he hecho cosas con:
-Autómatas celulares (juego de la vida y modelos de tráfico vehicular sobre todo)
-Análisis y procesamiento de imágenes (desde mi tesis en ESCOM, a un juego de un rompecabezas para MSDOS con intefaz gráfica)
-Sistemas complejos en general
-Matemáticas (series de Fourier, autómatas, máquinas de Turing, etc.)
-Ajedrez (por ahi tengo unas clases que hice como práctica personal en Java (junto con un diseñito en UML) para determinar los posibles movimientos de piezas en un tablero, siguiendo las reglas del juego)

Me llaman también la atención, aunque no me he metido mucho con:
-Inteligencia artificial
-Redes neronales
-Redes de computadoras y protocolos (de esto se un poco más por mis estudios en ESCOM y un interés particular que tengo en ellos) (además, en casa de mis papás y en mi casa soy normalmente yo el que configura las redes, conexiones, ruteadores y demás cosas

Y por último, en general me llaman la atención muchas otras cosas además de las computadoras…
-Leer, sobre todo fantasía y ciencia ficción, pero me gusta desde lo técnico y folosófico de mi área (últimamente más enfocado a Unix y a historia/paradigmas/filosofía del software libre/open source y del movimiento hacker), hasta teología, y también novelas de muchos otros géneros
-La astronomía amateur
-El ajedrez
-Un poco de videojuegos: sobre todo los de estrategia, en tiempo real o por turnos, y los de rol (en particular soy fan de los roguelike)
-El cine (suspenso / terror de preferencia, también ficción y fantasía), la música (rock, metal y trova sobre todo)
-La historia en general (de México, de la humanidad, de ciertas áreas de interés mío, etc.)
-El cristianismo en general y el catolicismo en particular, en cuanto a enseñanzas, historia, teología, pero sobre todo vida y lo que puedo dar de mi para cooperar con ese Gran proyecto… (de paso, las filosofías de otras religiones y modos de pensar también me interesan mucho! al menos para leer y conocer)
-Estar con mi familia, y por supuesto la vida
-(ah si! y la electrónica, siempre ha quedado a un lado, pero siempre ha marcado pasos fundamentales de mi vida profesional

Nota: si toda esta parte final parece un curriculum, la verdad es que no estaría mal si alguien interesado en mis aptitudes y capacidades me contacta para proyectos interesantes (claro está, si luego de tan larga historia, todavía ese alguien aguantó mi egocentrismo para llegar hasta aquí ). No me cierro a posibilidades, pero tomen en cuenta que soy casado, con proyecto de tener familia, y que vivo al norte de la ciudad de México

Y en cuanto a este pequeño registro de mi propia historia, mi plan es irlo haciendo crecer, conforme los eventos relacionados al tema vayan sucediendo y haya tenido tiempo de reflexionar sobre ellos, o conforme me acuerde de más cosas también…

—
jnc
10/marzo/2008

El siguiente relato lo escribí hace unos años, 3 creo, cuando era asiduo participante de El Fenomeno. Sigo inscrito en dicho sitio, pero ya casi no entro… El relato consta de 12 capítulos, que iré colocando poco a poco aquí. ¡Que lo disfruten!

Me voy ahora a mi largo descanso en las estancias intemporales mas allá de los mares y de las montañas de Aman. Pasará mucho tiempo antes de que vuelva a ser visto entre los noldor otra vez; y puede ser que no nos volvamos a encontrar tú y yo de nuevo, en muerte o en vida, pues los destinos de nuestras razas están separados. ¡Adiós!

Capítulo 1. Las estancias
Un dolor inmenso lo abarcó, un dolor que no podía compararse con nada que hubiera sentido antes… y de pronto, todo cesó.
En principio él estaba rodeado de oscuridad, o eso creía, y pasó un largo tiempo, bastante tiempo: ¿días?, ¿semanas? lo que a él le pareció que transcurrió hasta que sus ojos, o lo que el tenía ahora por ojos, se acostumbraron a la oscuridad. Bastante debió de haber sido esta para que la vista de un elfo, que veía más lejos y con más precisión que cualquier otro ser, del pueblo que se había despertado con la luz de las estrellas, tardara tanto en acostumbrarse a ver. O tal vez era que durante todo ese tiempo (lo que a él se le hizo un tiempo muy largo) sus ojos (lo que ahora entendía que serían sus ojos) los había mantenido cerrados (si es que eso es posible para un ser que, luego de morir, abandona el cuerpo y todas sus partes con el: cabello, manos, piernas, torso, ojos y boca también, para ser únicamente alma: el habitante intemporal de la casa temporal).
Conforme pudo ver mejor, observó todo a su alrededor. Se encontraba en un lugar bastante extraño, como nunca había conocido un lugar así. La oscuridad parecía ser el elemento predominante. No una oscuridad vacía, de terror como la que recordaba había caído sobre la hermosa ciudad mientras todos festejaban… detuvo sus pensamientos, no quería recordar eso: aquello había sido sólo el comienzo de La Caída, la caída de su pueblo, su propia caída. Sin embargo, la oscuridad que lo rodeaba ahora parecía conformar los muros del lugar donde estaba, y aún así podía ver; se percataba ahora de alguna luz que debía existir proveniente de algún lugar. La luz no era mucha; aunque no estuvo ahí, su abuelo le había hablado del despertar de su gente, de cómo sus ojos se abrieron con la tenue luz de las estrellas. Ese mismo tipo de luz existía ahora en este lugar, pero sin estrellas.
No tardó en percatarse y saber que el lugar en el que estaba era el único en el que en realidad podía, y debía estar. – Estoy muerto – se dijo. La realidad de estas palabras se le clavaron como una espina, que en principio duele pero después el dolor cede y solo queda la plena realidad. Sin embargo aún sentía otro dolor, proveniente de su vida: no hizo lo que había prometido hacer, había fracasado.
Esta otra realidad lo abarcó tanto que sin darse cuenta empezó a caminar por el lugar. Hacia dónde no lo sabía, no había forma de orientarse en aquel lugar, pero caminó como si supiera qué dirección tomar, pero no sabía hacia dónde ni con qué propósito.
Pasó largo tiempo caminando, aún con la profunda tristeza del recuerdo de su fracaso, hasta que poco a poco sus pensamientos se dirigieron a lo que observaba a su alrededor. Además de oscuridad, podía percibir otras formas en el lugar en el que se encontraba. Recordando su hogar mientras vivía: unas hermosas cuevas y grutas hechas por él mismo y por su pueblo, y por sus amigos que le dieron el nombre que tanto le gustaba: ‘Amo de las cavernas’ quería decir, aunque los de su raza lo traducían mal: ‘el de espíritu justo y leal’ decían… vaya lealtad mostrada al fracasar. Sin embargo en aquella casa, en esas cavernas aún siendo amplias, podía sentirse lo limitado del espacio; ahora que lo recordaba lo sentía como si hubiera sido limitado, porque aquí el espacio se sentía como una larga y gran llanura, aún cuando veía muros de oscuridad rodeando el lugar, aún cuando el espacio parecía…
– ¡Ya no! – sus pensamientos fueron interrumpidos por el grito de alguien, delante de donde estaba y fuera de alguna luz que lo dejara ver. Con cautela se acercó y mientras lo hacía le parecía claro que oía a una persona… no, a dos personas discutiendo. Una gritaba como enfadada, con ira y resentimiento. La otra, aunque hablaba un poco fuerte, lo hacía con un tono que se le antojó era de súplica, o de condescendencia extrema.
– ¡No quiero hablar contigo entiendes!
– Pero… hijo… óyeme… veme… ¿no quieres estar con tu madre?
– Entiende, ¡quiero estar a solas!
– Por… ¿por cuánto tiempo?
– No se, vete… hasta… hasta que pase mucho tiempo.
– ¿No entiendes que tu amargura es en vano? Aún me tienes a mí…
– No tengo nada que valga la pena tener. Ni tú ni mi padre me darán consuelo otra vez. No si no tengo su luz otra vez.
– ¡Otra vez pensando en eso! Acéptalo: las perdiste.
– ¡Vete! ¡Vete lejos de aquí!
– Pero…
Con curiosidad, el elfo se fue acercando para ver de quiénes se trataba que discutían. Tal vez un bueno consejo, o una palabra de consuelo podría ayudar a estos desconocidos personajes a que se reconciliaran. Por lo que escuchó uno era hijo de la otra, y aquel parecía amargado, horriblemente torturado por la pérdida de algo que había apreciado, mucho más que la compañía de su madre por lo que escuchó. Algo en su voz le recordaba a alguien, pero no lograba saber con certeza a qui… – ¡Ahhh – gritó el elfo. Una mano le había tocado el hombro; esta vez la interrupción lo sacó de sus pensamientos con tal violencia que el espanto lo hizo lanzar un grito.
Solo pudo alcanzar a oír a los desconocidos alejarse, mientras el hijo decía:
– Me voy, ahí está otra vez el orgulloso, el que me maldijo a mí y a mi familia. Espiándome seguramente.
El elfo ya no se detuvo a ver por donde se iban o a escuchar qué más se decían. Se volteó y vio ante él a un ser grandioso, imponente. Su rostro mostraba sabiduría, sabiduría que no sólo hablaba de las cosas que son y de cómo es que son. Algo en su mirada decía que el también sabía de cosas que aún no eran, algunas que entendía y algunas que no sabía porque serían, pero sabía que serían. Y sus ojos tenían luz… luz que era desde el principio, y que seguía y seguiría siendo.
– ¡Námo! – exclamó el elfo – Ahora que te veo creo que sé porque caminaba hacia acá, creo que te buscaba.
– Yo también te buscaba, me alegra encontrarte. Ven, debo hablar contigo. Acompáñame a mi casa, al sur de este lugar: las estancias de Mandos, pues es ahí donde te encuentras.
– Lo sabía, o… al menos eso percibía. Vamos pues, no se cuanto tiempo ha pasado pero añoro platicar con alguien. Y que mejor que con el más sabio de los valar.
– ¿El más sabio? Excepto uno, lo sabes.
– Bueno, pero Manwë tiene un lugar especial.
– ¿Y qué dirías de Ulmo? ¿No hay sabiduría en su compasión por ustedes que viven allá en Endor, la Tierra Media? ¿O de Aulë que a ti y tu pueblo les enseño tanto de lo que saben? O…
– Vaya… tu humildad es también de admirar…
Mientras platicaban, Námo (o Mandos como algunos le llaman) y el elfo se dirigieron hacia la casa del vala…

continuará