Posts Tagged 'GNU/Linux'

Lecciones aprendidas: migrando mi servidor de GNU/Linux

La entrada esta aqui:

http://jstitch.blogspot.com/2010/01/lecciones-aprendidas-migrando-mi.html

saludos!

Richard Stallman en México, ESIME Culhuacan

Richard Stallman en MexicoEl día de hoy asistí a la conferencia que dio Richard Stallman en el plantel Culhuacán de la ESIME del IPN.

La conferencia empezó a la 1 de la tarde, bueno un poquito pasado de la 1, y por dos horas pasamos un rato bastante ameno mientras RMS nos platicaba la historia de como llegó a fundar el movimiento del Software Libre, el proyecto GNU y a lo que actualmente se dedica, que es a promover dicha forma de ver el desarrollo, uso y distribución del software. Además disfrutamos de sus gags, y del momento final en el que (paganamente, he de decir) se invistió de san iGNUtius de la iglesia de emacs, para bendecir las computadoras de aquellos que usaran software libre.

Claro, RMS no es el fundador del software libre como tal, software libre se ha venido haciendo y usando desde los albores de la computación, antes de que nacieran las hoy infames gigantes empresas de software (como Microsoft, Apple, Oracle y un largo etcétera desde finales de los 70’s). Desde los 50’s la llamada cultura hacker hacía y compartía software ayudándose unos a otros mientras aprendían y hacían nacer lo que hoy son los sistemas informáticos más estables y difundidos del mundo (el internet, UNIX, los variados campos de las ciencias de la computación…)

Sin entrar en más detalles históricos (que pueden leerse en cualquier lugar de internet, desde la wikipedia hasta el sitio oficial del proyecto GNU, o de la Free Software Foundation), de lo que sí hablaré es un poco de su filosofía.

Desde su perspectiva, el software es una obra intelectual que, como toda obra intelectual, debería poder ser compartida con quien tú quisieras, con el propósito de ayudarlo. Por ello, es incorrecto, no-ético, inmoral, que el software esté hecho de tal forma que evite por medios legales (licencias de software que así lo indiquen) o ilegales (con código escondido que provoque también esto indirectamente) se comparta, y eso es un mal a la sociedad. Si alguien te pide un disco de, digamos Windows para poder usarlo, según la licencia de Windows, es ilegal que lo compartas. Así que te quedan dos opciones: o compartes tu disco y por lo tanto rompes la ley (lo cual es malo) o respetas la ley y no ayudas a tu amigo (lo cual es malo). Bueno, pues tal vez el menor de los males sería que compartieras el disco, a pesar de romper la ley. Pero aún así, es un mal. Lo ideal, sería poder compartir, y que eso no implicara ningún mal, menor o mayor.
San iGNUtius de la iglesia de emacs

Bueno, a partir de esto es que surge la idea del software libre: software hecho, y sobre todo con medidas legales y técnicas, para poder ser compartido. Para RMS, hay 4 libertades fundamentales que debe tener un software para poder ser considerado libre:

1. La libertad de ejecutar el programa, para cualquier propósito (libertad 0).
2. La libertad de estudiar cómo trabaja el programa, y cambiarlo para que haga lo que quieras (libertad 1). El acceso al código fuente es una condición necesaria para ello.
3. La libertad de redistribuir copias para que puedas ayudar al prójimo (libertad 2).
4. La libertad de mejorar el programa y publicar tus mejoras, y versiones modificadas en general, para que se beneficie toda la comunidad (libertad 3). El acceso al código fuente es una condición necesaria.

Y con ello, su proyecto GNU, de crear un sistema operativo completamente libre, y todo el software creado con este propósito, está hecho y licenciado para poder respetar estas cuatro libertades.

Regresando un poco a la historia, sucedió que luego de casi 10 años trabajando (el proyecto fue fundado en 1983), el equipo de la Free Software Foundation no conseguía terminar la pieza clave de todo sistema operativo: el kernel. Y así fue como en 1992, Linus Torvalds, un estudiante de Finlandia, hizo su propio kernel, le agregó el software de GNU, terminó licenciando su kernel bajo la GPL (la Licencia Pública General del proyecto GNU que establece las directivas para respetar las 4 libertades del software libre), y por fin la comunidad hacker, y después el mundo, pudo contar por primera vez con un sistema operativo completo y libre.

Richard Stallman en Mexico
Por discusiones posteriores, en las que influyó el hecho de que Linus no se iba por el lado ‘extremo’ de defender las libertades (lo mismo que muchos otros hackers, la mayoría, todo hay que decirlo), el movimiento del software libre se escindió, quedando como hoy en día, dividido en dos: por un lado los que aún se mantenían con la FSF, que denominan al movimiento ‘Software Libre’, y cuya bandera está en la defensa de las libertades, y por otro lado los que se mantenían con la mayoría de los hackers (subdividido en diversos ‘clanes’ de acuerdo a algún lenguaje de programación o licencia de software u otro parámetro), que denominan al movimiento ‘Open Source’, y cuya bandera está en la defensa de la calidad técnica y demás cualidades (que sin duda tiene el software con estas características), según ellos sin dejar a un lado las libertades, pero sí dejándolas a un lado del discurso, de forma que hoy en día las empresas, la bolsa de Nueva York y la prensa, toman por el movimiento auténtico al del open source, dejando a la FSF en una minoría un tanto escandalosa. Y es por esta razón que Richard Stallman insiste en que el sistema operativo debe de llamarse GNU / Linux (es decir, GNU con kernel Linux), y no Linux a secas, pues este sólo es el kernel, pieza fundamental sí, pero no la única, y así como existe kernel Linux, podrían haber muchos otros kernels, como el eterno e inacabado HURD de GNU.

Controversial de por sí, si algo hay que reconocerle a Richard Stallman, es el mantenerse fiel a sus ideales siempre. Sin duda, aquello que dicen los hackers de ‘calla y enséñanos el código’ habla del afán y el amor que tienen por su arte, pero yo creo que si alguien encuentra algo por lo que hay que dar la vida, entonces hay que darlo siempre. Y creo yo, Richard Stallman lo tiene en la defensa de las libertades del software, libertades que, en última instancia, repercuten no solamente en los programadores, sino también y sobre todo en los usuarios (recordando las 4 libertades, las libertades 2 y 4 pueden ser aprovechadas solamente por aquellos que sean programadores, pero las libertades 1 y 3 están hechas para cualquiera).

Yo acostumbro abstraerme de la discusión, no porque no sepa que hay diferencia. De hecho, admiro mucho a hackers que se encuentran en ambos lados del movimiento. Eric Raymond es uno de ellos, y es uno de los más duros críticos de Stallman. Mi pretexto es que, como en inglés gran parte de la discusión salió de la ambigüedad de la palabra ‘free’ (que puede significar libre o gratuito), en español no existe tal, pues libre es libre y ya, gratis es otra cosa. Por eso me zafo cómodamente de la discusión… aunque no se, tal vez no debería… tal vez cuando tenga más dinero para obtener la membresía, me haga miembro de la FSF 🙂

Como sea, en momentos así, es cuando me atrevo a decir, al estilo de la Revolución Francesa, ‘Vive la liberté!’

Richard Stallman en Mexico

Por cierto, nótese el orgullo que siente el autor de este blog al ver a tan gran personalidad con el escudo de mi institución al fondo XD

Y por último, unos videos…



Historia de Unix (parte 4)

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: http://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 (parte 3)

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: http://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 (parte 2)

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.

kd14
[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 (parte 1)

Historia de Unix

normal_linux_unix1

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 (https://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.

pdp73
[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

3d en OpenSuse 10.3, Linux en mi laptop Toshiba Satellite A215

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!

snapshot1.png