Capítulo 8. Forastero

La batalla entre el departamento de informática de la Universidad de
California en Berkeley y AT&T no llegó al sistema judicial hasta 1992,
pero la fricción entre la devoción del departamento por compartir y la
insistencia de la corporación en el control comenzó mucho antes.

Mientras el equipo de BSD luchaba con los abogados, un hombre libre en
Finlandia se propuso escribir su propio sistema operativo sin ningún
impedimento legal o institucional. Al principio dijo que era un proyecto
que probablemente no llegaría a mucho, pero solo unos años después la
gente comenzó a bromear sobre "Total World Domination". Unos años
después de eso, comenzaron a usar la frase en serio.

En abril de 1991, Linus Torvalds tenía un problema. Era un estudiante
universitario relativamente pobre en Finlandia que quería hackear las
entrañas del sistema operativo de una computadora. El sistema de
Microsoft en ese momento eran los más baratos, pero no eran muy
interesantes. El sistema operativo de disco básico (DOS) esencialmente
permite que un programa controle la computadora. Windows 3.1 no era
mucho más que una interfaz gráfica para DOS que presentaba bonitas
imágenes (iconos) para representar los archivos. Torvalds quería
experimentar con un sistema operativo verdadero, y eso significaba UNIX,
o algo parecido a UNIX. Estos sistemas operativos verdaderos hacían
malabares con cientos de programas a la vez y, a menudo, mantenían
contentos a docenas de usuarios. Jugar con DOS era como practicar tiros
de baloncesto por tu cuenta. Jugar con UNIX era como jugar con un equipo
que tenía 5, 10, tal vez hasta 100 personas moviéndose alrededor de la
cancha en patrones complicados y mecánicos.

Pero las máquinas UNIX costaban una fortuna relativa. Los clientes de
alta gama solicitaban dicho el sistema operativo, por lo que, en
general, solo las máquinas de alta gama venían con él. Un estudiante
universitario pobre de Finlandia no tenía dinero para comprar una
estación Sun Sparc de primer nivel. Solo podía permitirse una PC básica,
que venía con el procesador 386. Esta era una PC de primera línea en ese
momento, pero aún no era particularmente emocionante. Algunas empresas
hicieron una versión de UNIX para esta máquina de gama baja, pero
cobraron por ella.

En junio de 1991, poco después de que Torvalds[^3] comenzara su pequeño
proyecto científico, el Grupo de Investigación de Sistemas Informáticos
de Berkeley lanzó lo que pensaban que era su versión completamente libre
de trabas de BSD UNIX conocida como Network Release 2. Surgieron varios
proyectos para portar esto al microprocesador Intel 386, y el proyecto
evolucionó hasta convertirse en las versiones actuales de FreeBSD y
NetBSD. Torvalds ha dicho a menudo que nunca habría iniciado Linux si
hubiera sabido que podía descargar un sistema operativo más completo de
Berkeley.

[3]: Todos en la comunidad, incluidos muchos que no lo conocen, se
refieren a él por su nombre de pila. Las reglas de estilo me impiden
usar eso en algo tan propio como un libro. Pero Torvalds no sabía sobre
BSD en ese momento, y tuvo suerte de que no saberlo. Berkeley pronto se
vio invadida por la demanda con AT&T que afirmaba que la universidad de
alguna manera estaba enviando la propiedad intelectual de AT&T. El
desarrollo del sistema BSD se detuvo bruscamente cuando los
programadores se dieron cuenta de que AT&T podía demandarlos en
cualquier momento si Berkeley era declarado culpable de regalar el
código fuente propiedad de AT&T.

Si no podía permitirse comprar una máquina UNIX, escribiría su propia
versión. Lo haría compatible con POSIX - un estándar para los
diseñadores de UNIX - para que otros pudieran usarlo. Minix es otro
sistema operativo similar a UNIX que un profesor, Andrew Tanenbaum,
escribió para que los estudiantes experimentaran con las entrañas de un
sistema operativo. Torvalds inicialmente consideró usar Minix como
plataforma. Tanenbaum publicaba el código fuente de su proyecto, pero
cobraba por el paquete. Era como un libro de texto para estudiantes de
todo el mundo.

Torvalds consideró el precio de Minix ($150) y pensó que era demasiado.
La Licencia Pública General GNU de Richard Stallman se había arraigado
en el cerebro de Torvalds, y vio las limitaciones de cobrar por el
software. GNU también había producido una amplia variedad de
herramientas y programas de utilidad que podía usar en su máquina. Minix
estaba controlada por Tanenbaum, aunque con mano mucho más relajada que
muchas de las otras compañías en ese momento.

Quien lo quisiese podía agregar sus propias características a Minix y
algunos lo hicieron. Conseguían una copia del código fuente por $150.
Pero pocos regresaron con sus modificaciones a Minix. Tanenbaum quería
mantenerlo simple y se frustró con la gran cantidad de personas que,
como escribió en ese entonces, "quieren convertir Minix en BSD UNIX".

Así que Torvalds comenzó a escribir su propio sistema operativo diminuto
para este 386. No iba a ser nada especial. No iba a derrocar a AT&T ni a
la floreciente Microsoft. Iba a ser un experimento divertido escribir un
sistema operativo de computadora que fuera todo suyo. Escribió en enero
de 1992: "Muchas cosas deberían haberse hecho de manera más portátil si
hubiera sido un proyecto real. Sin embargo, no estoy poniendo demasiadas
excusas al respecto: fue una decisión de diseño, y en abril pasado
cuando comencé la cosa , realmente no pensé que nadie quisiera usarlo".

Aún así, Torvalds tenía grandes ambiciones. Estaba escribiendo un
juguete, pero quería que tuviera muchas, si no todas, las
características que se encuentran en las versiones de UNIX completas en
el mercado. El 3 de julio, comenzó a preguntarse cómo lograr esto y
colocó una publicación en el grupo de noticias de USENET comp.os.minix,
escribiendo:

Hola netlanders, Debido a un proyecto en el que estoy trabajando (en
minix), estoy interesado en la definición estándar de posix. ¿Podría
alguien indicarme un formato (preferiblemente) legible por máquina de
las últimas reglas posix? Los sitios ftp estarían bien.

La pregunta de Torvalds era bastante simple. Cuando escribió el mensaje
en 1991, UNIX era uno de los principales sistemas operativos del mundo.
El proyecto que comenzó en AT&T y Berkeley se distribuía en computadoras
de IBM, Sun, Apple y la mayoría de los fabricantes de máquinas de mayor
potencia conocidas como estaciones de trabajo. Los bancos y científicos
de Wall Street amaban las máquinas más poderosas y amaban la simplicidad
y la capacidad de hackero de las máquinas UNIX. En un intento por
unificar el mercado, los fabricantes de computadoras crearon una forma
de estandarizar UNIX y la llamaron POSIX. POSIX aseguró que cada máquina
UNIX se comportaría de manera estandarizada.

Torvalds trabajó rápidamente. En septiembre, estaba publicando notas
para el grupo con el asunto "¿Qué es lo que más te gustaría ver en
Minix?" Estaba agregando funciones a su clon y quería realizar una
encuesta sobre dónde debería agregar a continuación.

Torvalds ya tenía buenas noticias para informar. "Actualmente he portado
bash (1.08) y GCC (1.40), y las cosas parecen funcionar. Esto implica
que tendré algo práctico dentro de unos meses", dijo.

A primera vista, estaba haciendo un progreso asombroso. Creó un sistema
de trabajo con un compilador en menos de medio año. Pero también tuvo la
ventaja de tomar prestado del proyecto GNU. El grupo de proyecto GNU de
Stallman ya había escrito un compilador (GCC) y una agradable interfaz
de usuario de texto (bash). Torvalds las tomó y usó porque pudo. Estaba
de pie sobre los hombros de los gigantes que habían venido antes que él.

El núcleo de un sistema operativo a menudo se llama "kernel", que es una
de las palabras extrañas que flotan en el mundo de las computadoras.
Cuando las personas son correctas, notan que Linus Torvalds creó el
kernel de Linux en 1991. La mayoría del otro software, como el
escritorio, las utilidades, los editores, los navegadores web, los
juegos, los compiladores y prácticamente todo lo demás, fue escrito por
otras personas. Si mide esto en espacio de disco, más del 95 por ciento
del código en una distribución promedio se encuentra fuera del kernel.
Si lo mide por la interacción del usuario, la mayoría de las personas
que usan Linux o BSD ni siquiera saben que hay un kernel allí. Los
botones en los que hacen clic, los sitios web que visitan y la impresión
que realizan están controlados por otros programas que hacen el trabajo.

Por supuesto, medir la importancia del núcleo de esta manera es una
estupidez. El núcleo es una especie de combinación de la sala de correo,
la sala de calderas, la cocina y la lavandería de una computadora. Es
responsable de mantener el flujo de datos entre los discos duros, la
memoria, las impresoras, la pantalla de video y cualquier otra parte que
esté conectada a la computadora.

En muchos aspectos, un núcleo bien escrito es como un buen hotel. Los
huéspedes se registran, se les asigna una habitación y luego pueden
pedir lo que necesiten al servicio de habitaciones y al personal de
conserjería perfectamente engrasado. ¿Este nuevo trabajo requerirá 10
megabytes adicionales de espacio en disco? No hay problema señor. En
seguida, señor. Estaremos listos con eso. Idealmente, el software ni
siquiera sabrá que otro software se está ejecutando en una habitación
separada. Si ese otro programa es una herramienta de reproducción de MP3
de rock-and-roll ruidoso, el otro software no se dará cuenta cuando
falla y quema su propia habitación. El hotel simplemente navega,
ocupándose de los negocios.

Para 1991, Torvalds tenía una breve lista de características que quería
agregar al kernel. Internet era todavía una red pequeña que unía
universidades y algunos laboratorios avanzados, por lo que la creación
de redes era una preocupación menor. Solo apuntaba al 386, por lo que
podía confiar en algunas de las características especiales que no
estaban disponibles en otros chips. Las tarjetas de hardware de gráficos
de gama alta seguían siendo bastante caras, por lo que se concentró en
una interfaz de solo texto. Más tarde arreglaría todos estos problemas
con la ayuda de la gente en la lista de correo del kernel de Linux, pero
por ahora podía evitarlos.

Aún así, hackear un kernel significa anticipar lo que otros
programadores podrían hacer para arruinar las cosas. Nunca sabes si
alguien intentará hacerse con los 128 megabytes de RAM disponibles. No
sabes si alguien va a conectar una vieja y extraña impresora de rueda de
margaritas e intentar meterle un archivo PostScript por la garganta. No
sabes si alguien va a crear un bucle sin fin que va a escribir números
aleatorios en toda la memoria. Los programadores estúpidos y los
usuarios tontos hacen estas cosas todos los días, y tienes que estar
preparado para ello. El núcleo del sistema operativo tiene que mantener
las cosas fluyendo sin problemas entre todas las diferentes partes del
sistema. Si uno sale mal debido a un poco de código descuidado, el
kernel necesita cortarlo como una extremidad que se está gangrenando. Si
un trabajo comienza a calentarse, el núcleo debe tratar de darle todos
los recursos que pueda para que el usuario esté contento. El hacker del
kernel necesita mantener todas estas cosas en orden.

Crear un sistema operativo como este no es tarea fácil. Muchos de los
sistemas comerciales fallan con frecuencia sin motivo perceptible, y la
mayoría del público simplemente lo acepta.[^4] Muchas personas de alguna
manera asumen que debe ser su culpa que el programa falle. En realidad,
probablemente sea del kernel. O más precisamente, es culpa del diseñador
del kernel por no anticipar lo que podría salir mal.

[4]: Microsoft ahora reconoce la existencia de un error en las decenas
de millones de copias de Windows 95 y Windows 98 que hará que su
computadora 'deje de responder (se cuelgue)', ya sabe, lo que llama
fallar, después de exactamente 49 días, 17 horas, 2 minutos y 47,296
segundos de funcionamiento continuo. .. . ¿Por qué 49,7? ¿días? Porque
las computadoras no cuentan los días. Están contando los milisegundos.
Un contador comienza cuando se inicia Windows; cuando llega a 232
milisegundos, que resultan ser 49,7 días, bueno, ese es el número más
grande que puede manejar este contador. Y en lugar de dar la vuelta con
gracia y comenzar de nuevo desde cero, logra detener todo el sistema
operativo". --James Gleick en el New York Times.

A mediados de la década de 1970, las empresas y los informáticos ya
estaban experimentando con muchos diferentes formas de crear sistemas
operativos viables. Si bien las computadoras de la época no eran muy
poderosas según los estándares modernos, los programadores crearon
sistemas operativos que permitían que decenas, si no cientos de
personas, usaran una máquina simultáneamente. El sistema operativo
mantendría las diferentes tareas ordenadas y ordenadas. asegúrese de que
ningún usuario pueda interferir con otro.

A medida que las personas diseñaban más y más sistemas operativos,
rápidamente se dieron cuenta de que había una pregunta difícil: ¿qué tan
grande debería ser? Algunas personas argumentaron que el sistema
operativo debería ser lo más grande posible y estar completo con todas
las funciones que alguien podría querer usar. Otros respondieron con
diseños simplificados que venían con un pequeño núcleo del sistema
operativo rodeado de miles de pequeños programas que hacían lo mismo.

Hasta cierto punto, el debate es más sobre la semántica que sobre la
realidad. Un usuario quiere que la computadora pueda enumerar los
diferentes archivos almacenados en un directorio. No importa si la
pregunta la responde un gran sistema operativo que maneja todo o un
pequeño sistema operativo que usa un programa para encontrar la
respuesta. El trabajo aún debe hacerse, y muchas de las instrucciones
son las mismas. Es solo una cuestión de si las instrucciones están
etiquetadas como "sistema operativo" o como un programa auxiliar.

Pero el debate es también sobre el diseño. A los programadores, maestros
y la compañía Lego les encanta creer que cualquier problema se puede
resolver dividiéndolo en partes pequeñas que se pueden ensamblar para
crear el todo. Todo programador quiere convertir el diseño de un sistema
operativo en miles de pequeños problemas que se pueden resolver
individualmente. Este sueño suele durar hasta que alguien comienza a
ensamblar las piezas y descubre que no funcionan juntas tan
perfectamente como deberían.

Cuando Torvalds comenzó a crear el núcleo de Linux, decidió que iba a
crear una versión más grande e integrada a la que llamó "núcleo
monolítico". Este fue un movimiento algo audaz porque la comunidad
académica estaba fascinada con lo que llamaron "microkernels". La
diferencia es en parte semántica y en parte real, pero se puede resumir
por analogía con las empresas. Algunas empresas tratan de construir
grandes, integrar sin problemas los pasos de producción. Otros tratan de
crear operaciones más pequeñas que subcontratan gran parte del trabajo
de producción a otras empresas. Uno es grande, monolítico y lo abarca
todo, mientras que el otro es más pequeño, fragmentado y heterogéneo. No
es raro encontrar dos empresas en la misma industria que toman
diferentes enfoques y piensan que están haciendo lo correcto.

El diseño de un sistema operativo a menudo se reduce a la misma
decisión. ¿Queremos construir un núcleo monolítico que haga todos los
malabares internamente, o queremos un modelo más pequeño y fragmentado
que debería ser más flexible siempre que las partes interactúen
correctamente?

Con el tiempo, el mundo de los sistemas operativos comenzó a referirse a
este núcleo como el kernel del sistema operativo. Las personas que
querían crear grandes sistemas operativos con muchas funciones
escribieron núcleos monolíticos. Sus enemigos ideológicos que querían
dividir el sistema operativo en cientos de pequeños programas que se
ejecutan en un núcleo pequeño escribieron micronúcleos. Algunas de las
personas más extremas etiquetaron su trabajo como nanokernel porque
pensaron que hacía incluso menos y, por lo tanto, era incluso más puro
que esos microkernels obesos.

La palabra "núcleo" es un poco confusa para la mayoría de las personas
porque a menudo la usan para referirse a un fragmento de un objeto o una
pequeña fracción. Un argumento extremo puede tener una pizca de verdad.
Una película de desastres siempre da a los personajes y al público un
núcleo de esperanza al que aferrarse.

Los matemáticos usan la palabra de manera un poco diferente y enfatizan
la capacidad de la palabra para permitir que una pequeña parte defina un
concepto más grande. Técnicamente, el núcleo de una función f es el
conjunto de valores, x[1], x[2],. .. x[n] tal que f(x[i])=1, o
cualquiera que sea el elemento de identidad. La acción del kernel de una
función hace un buen trabajo al definir cómo se comporta la función con
todos los demás elementos. Los algebristas estudian el núcleo de una
función porque revela el comportamiento general.[^5]

[5]: El núcleo de f(x)=x[2] es (-1, 1) e ilustra cómo la función tiene
dos ramas. Los diseñadores del sistema operativo usan la palabra de la
misma manera. Si definen el kernel correctamente, seguirá el
comportamiento del resto del sistema operativo. La pequeña parte del
código define el comportamiento de toda la computadora. Si el kernel
hace una cosa bien, toda la computadora lo hará bien. Si hace una cosa
mal, entonces todo sufrirá.

Muchos usuarios de computadoras a menudo notan este efecto sin darse
cuenta de por qué existen operaciones donde una compañía controla todo.
La mayoría de las computadoras Macintosh, por ejemplo, pueden ser lentas
a veces porque el sistema operativo no hace un buen trabajo al hacer
malabarismos con la carga de trabajo entre los procesos. El núcleo del
sistema operativo no se ha revisado por completo desde los primeros días
en que las máquinas ejecutaban un programa a la vez. Esta lentitud
persistirá un poco más hasta que Macintosh lance una nueva versión
conocida como MacOS X. Esta se basará en el kernel de Mach, una versión
desarrollada en la Universidad Carnegie-Mellon y lanzada como software
de código abierto. Steve Jobs lo adoptó cuando se fue a NeXT, una
empresa que finalmente se volvió a incorporar a Apple. Este kernel hace
un trabajo mucho mejor al hacer malabarismos con diferentes tareas
porque utiliza la multitarea preventiva en lugar de la multitarea
cooperativa. La versión original de MacOS permitía que cada programa
decidiera cuándo y si iba a ceder el control de la computadora para
permitir que se ejecutaran otros programas. Esta versión de malabarismo
de bajo costo se denominó multitarea cooperativa, pero fracasa cuando
algún programa en el hotel no coopera. La mayoría de los desarrolladores
de software obedecien las reglas, pero aun así se cometen errores. Los
malos programas bloquearían la máquina. La multitarea preventiva le
quita este poder a los programas individuales. Cambia el control de un
programa a otro sin pedir permiso. Un programa obeso no puede ralentizar
toda la máquina. Cuando el nuevo kernel de MacOS X comience a ofrecer
multitarea preventiva, los usuarios deberían notar un comportamiento
menos lento y un rendimiento más consistente.

Torvalds se sumergió y creó un núcleo monolítico. Esto facilitó la
modificación de todas las extrañas interacciones entre los programas.
Claro, un microkernel construido alrededor de una arquitectura limpia de
paso de mensajes era una forma elegante de construir las entrañas de un
sistema operativo, pero tenía sus problemas. No había manera fácil de
tratar con excepciones especiales.

Digamos que desea que un servidor web se ejecute muy rápidamente en su
máquina. Eso significa que debe tratar los mensajes que ingresan a la
computadora desde Internet con una velocidad excepcional. Debe enviarlos
con el equivalente de entrega especial o FedEx. Debe crear una excepción
especial para ellos. Agregar estas excepciones a un microkernel limpio
comienza a hacer que se vea mal. El diseño comienza a volverse
desordenado y menos elegante. Después de agregar algunas excepciones
especiales, el microkernel puede comenzar a confundirse.

El kernel monolítico de Torvalds no tenía la elegancia o la simplicidad
de un sistema operativo microkernel como Minix o Mach, pero era más
fácil de piratear. Los nuevos ajustes para acelerar ciertas funciones
fueron relativamente fáciles de agregar. No hubo necesidad de idear una
arquitectura completamente nueva para el sistema de paso de mensajes. La
desventaja era que las entrañas podían volverse notablemente bizantinas,
como la burocracia de una gran empresa.

En el pasado, esta complejidad perjudicó el éxito de los sistemas
operativos propietarios. La complejidad producía errores porque nadie
podía entenderla. El sistema de Torvalds, sin embargo, viene con todo el
código fuente, lo que facilita mucho a los programadores de aplicaciones
descubrir qué está causando fallas. Para llevar un poco más lejos la
metáfora de la burocracia corporativa, el código fuente actuó como la
secretaria omnisciente que es capaz de explicarle todo a un ejecutivo
estresado. Este conocimiento perfecto redujo el costo de la complejidad.

Para principios de 1992, Linux ya no era un pasatiempo de medio tiempo
para los estudiantes finlandeses. Varios programadores influyentes se
interesaron en el código. Era gratuito y relativamente utilizable.
Corría gran parte del código GNU, y eso lo convirtió en una forma
ordenada y económica de experimentar con algunas herramientas
excelentes. Más y más personas descargaron el sistema y una fracción
significativa comenzó a informar errores y sugerencias a Torvalds. Esto
lo realimentó, y el proyecto creció como una bola de nieve.


8.1 Un pasatiempo engendra un proyecto

A primera vista, la decisión de Torvalds de crear un sistema operativo
no resulta extraordinaria. Millones de estudiantes en edad universitaria
suelen decidir que pueden hacer cualquier cosa si se esfuerzan un poco
más. Departamentos universitarios de teatro, periódicos y revistas de
humor comenzaron con este impulso, y la noción no se limita a los
estudiantes universitarios. En su tiempo libre, millones de adultos
dirigen equipos de Pequeñas Ligas, construyen maquetas de ferrocarriles,
presionan al gobierno local para que cree parques y asumen miles de
proyectos grandes y pequeños.

Cada gran idea tiene un líder que puede producir un sistema para
sostenerla. Todos los lotes de los pueblos pequeños tenían niños jugando
béisbol, pero algunos muchachos organizaron un programa de ligas menores
que estandarizó las reglas y la competencia. Cada pueblo pequeño contaba
con gente haciendo campaña por los parques, pero un pequeño grupo creó
el Sierra Club, que lucha por los parques en todo el mundo.

Este talento para organizar el trabajo de los demás es un bien escaso, y
Torvalds tenía una habilidad especial para ello. Tuvo la amabilidad de
compartir su sistema con el mundo y nunca se enseñoreó de nadie. Sus
mensajes estaban llenos de bromas y humor autocrítico, la mayoría de los
cuales estaban cuidadosamente marcados con caritas sonrientes (:-)) para
asegurarse de que el mensaje fuese claro. Si escribía algo peleagudo, se
disculparía por ser un "*impulsivo*". Siempre fue amable al dar crédito
a otros y recalcó que gran parte de Linux era solo un clon de UNIX. Todo
esto lo hizo fácil de leer y, por lo tanto, influyente.

Sin embargo, su mayor truco fue su decisión de evitar el manto del
poder. Escribió en 1992: "Aquí está mi posición sobre 'mantener el
control', en 2 palabras (¿tres?): No lo haré. El único control que
efectivamente he mantenido en Linux es que lo conozco mejor que nadie".

Señaló que su control era solo una ilusión causada por el hecho de que
hizo un buen trabajo manteniendo el sistema. "He puesto mis cambios a
disposición en sitios ftp, etc. Esos se han convertido efectivamente en
lanzamientos oficiales, y por algún tiempo no espero que esto cambie: no
porque sienta que tengo algún derecho moral, sino porque no he oído
demasiadas quejas".

A medida que agregaba nuevas funciones a su sistema operativo, con
frecuencia publicaba nuevas copias. Internet hizo que esto fuera fácil
de hacer. Simplemente subiría una nueva versión en un servidor y
publicaría un aviso para que todos lo leyeran: vengan a descargar la
última versión.

Dejó en claro que la gente podía votar para destituirlo en cualquier
momento. "Si la gente siente que hago un mal trabajo, pueden hacerlo
ellos mismos". Podrían simplemente tomar todo su código de Linux y
comenzar su propia versión utilizando el trabajo de Torvalds como base.

Cualquiera podría romper con el proyecto de Torvalds porque Torvalds
decidió enviar el código fuente a su proyecto bajo la Licencia Pública
General GNU de Richard Stallman, o GPL. Al principio, lo emitió con una
licencia más restrictiva que prohibía cualquier uso "comercial", pero
finalmente pasó a la licencia GNU. Esta fue una decisión crucial porque
cimentó una promesa con cualquiera que pasara unos minutos jugando con
su sistema operativo de juguete para el 386. Establecía que todo el
código fuente que escribiera Torvalds o cualquier otra persona sería de
libre acceso y compartido con todos. Esta decisión fue un arma de doble
filo para la comunidad. Todo el mundo podía tomar el software gratis,
pero si comenzaban a circular algún software nuevo creado con el código,
tendrían que donar sus cambios al proyecto. Era como papel matamoscas.
Todos quienes comenzaron a trabajar con el proyecto se encariñaron con
él. No podían huir a su propio rincón. Algunos programadores bromean
diciendo que esta licencia de papel matamoscas es como el sexo. Si
comete un error al conectarse con un proyecto protegido por GPL, lo paga
para siempre. Si alguna vez comercia una versión del proyecto, debe
incluir todo el código fuente. Se puede distribuir libremente para
siempre.

Mientras que algunas personas se quejan de la naturaleza pegajosa de la
GPL, muchos la ven como una virtud. Les gusta el código fuente de
Torvalds, y les gusta el hecho de que la GPL los convirtiera en socios
de pleno derecho en el proyecto. Cualquiera podía donar su tiempo y
estar seguro de que no iba a desaparecer. El código fuente se convirtió
en un cuerpo de trabajo mantenido en confianza común para todos. Nadie
podía acordonarlo, cercarlo o tomar el control.

Con el tiempo, el proyecto científico favorito de Torvalds y su afición
al hacking crecieron a medida que más personas se interesaban en jugar
con las entrañas de las máquinas. El precio era justo y la curiosidad
ociosa podía ser poderosa. Algunos se preguntaban qué podía hacer un
tipo en Finlandia con una máquina 386. Otros se preguntaban si realmente
era tan funcional como las grandes máquinas de las empresas comerciales.
Otros se preguntaron si era lo suficientemente potente como para
resolver algunos problemas en el laboratorio. Otros solo querían jugar.
Todas estas personas lo intentaron, y algunas incluso comenzaron a
contribuir al proyecto.

El núcleo floreciente de Torvalds encajaba muy bien con las herramientas
que creó el proyecto GNU. Todo el trabajo de Stallman y sus discípulos
podía trasladarse fácilmente para trabajar con el núcleo del sistema
operativo que Torvalds ahora llamaba Linux. Este es el poder del código
fuente de libre distribución. Cualquiera puede hacer una conexión, y
alguien invariablemente lo hacía. Pronto, gran parte del código GNU
comenzó a ejecutarse en Linux. Estas herramientas facilitaron la
creación de más programas nuevos y la bola de nieve comenzó a rodar.

Muchas personas sienten que el verdadero acto de genialidad de Linus
Torvalds fue idear un sistema flexible y receptivo para permitir que su
sistema operativo de juguete creciera y cambiara. Lanzó nuevas versiones
a menudo y animó a todos a probarlas con él. En el pasado, muchos
desarrolladores de código abierto que utilizaban la GPL de GNU solo
habían lanzado nuevas versiones en los principales hitos del desarrollo,
actuando un poco como los desarrolladores comerciales. Tras de lanzar la
versión 1.0, se refugiaban en sus sótanos hasta que agregaban
suficientes funciones nuevas para justificar la versión 2.0.

Torvalds evitaba este perfeccionismo y compartía actualizaciones con
frecuencia. Si solucionaba un error el lunes, lanzaría una nueva versión
esa tarde. No era extraño tener dos o tres nuevas versiones publicadas
en Internet cada semana. Esto supuso un poco más de trabajo para
Torvalds, pero también facilitaba la participación de otros. Podían ver
lo que estaba haciendo y hacer sus propias sugerencias.

Esta libertad también atrajo a otros al partido. Sabían que Linux
siempre sería suyo también. Podían escribir funciones interesantes y
conectarlas al kernel de Linux sin preocuparse de que Torvalds les
arrancara la alfombra. La GPL es un contrato que dura mucho a futuro. Es
una promesa de unión.

El kernel de Linux también tuvo éxito pues fue escrito desde cero para
la plataforma de PC. Cuando los hackers de Berkeley UNIX estaban
transfiriendo BSD a la plataforma de PC, no pudieron hacer que encajara
perfectamente. Estaban tomando una pieza de software diseñada para
computadoras más antiguas como la VAX, y recortando esquinas y
reescribiendo secciones hasta que se ejecutó en la PC.

Alan Cox me señaló: "Las primeras cosas de BSD fueron hechas por gente
de UNIX para gente de UNIX. Necesitabas una calculadora y familiaridad
con BSD UNIX en máquinas grandes (o mucha lectura) para instalarlo.
Tampoco podías compartir un disco entre DOS/Windows y 386BSD o las
primeras ramificaciones de este.

"Hoy en día, FreeBSD entiende las particiones de DOS y puede compartir
un disco, pero en ese momento daba miedo instalar BSD", continuó.

El BSD también daba por sentado ciertas piezas de hardware. Las primeras
versiones de BSD requerían un 387, un coprocesador numérico que
aceleraría la ejecución de números de coma flotante. Cox recuerda que el
precio (alrededor de 100 dólares) era demasiado alto para su
presupuesto. En ese momento, el mundo del software libre era una
organización muy magra.

El sistema operativo de Torvalds llenó un agujero crucial en el mundo
del software libre e hizo posible que alguien pudiera ejecutar una
computadora sin pagarle a nadie por una licencia. Richard Stallman había
soñado con este día y a Torvalds se le ocurrió la última pieza
importante del rompecabezas.


8.2 Un tipo diferente de prueba

Durante los primeros meses del trabajo de Torvalds, el grupo BSD estaba
atrapado en un pantano legal. Mientras el equipo de BSD estaba
involucrado en conversaciones de acuerdos secretos y declaraciones
secretas, Linus Torvalds se encontraba escribiendo felizmente código y
compartiéndolo con el mundo en la red. Su vida no era todo color de
rosa, pero todos sus problemas estaban abiertos. El profesor Andy
Tanenbaum - un científico informático bastante respetado y famoso -
sostuvo un largo debate con Torvalds sobre la estructura de Linux.
Estudió a Linux y afirmó que Linux habría sacado dos F en su clase
debido a su diseño. Esto condujo a una gran guerra de llamaradas que fue
tan desagradable como la pelea entre Berkeley y la USL de AT&T. De
hecho, para el observador promedio fue aún más desagradable. Torvalds
devolvió fuego a Tanenbaum con palabras fuertes como "fiasco", "daño
cerebral" y "apestar". Descartó las malas notas al señalar que
supuestamente Albert Einstein obtuvo malas notas en matemáticas y
física. Los abogados de alto precio que trabajaban para AT&T y Berkeley
probablemente usaron palabras muy caras y educadas para tratar de
ocultar los cuchillos que intentaban clavarse mutuamente en la espalda.
Torvalds y Tanenbaum se arrancaban virtualmente los ojos como un
festival de graznidos en el programa de Jerry Springer.

Pero la guerra de llamaradas de Torvalds con Tanenbaum ocurrió
abiertamente en un grupo de noticias de Internet. Otras personas podrían
leerlo, pensar en él, agregar sus comentarios e incluso tomar partido.
Fue un debate muy abierto que descubrió muchas fallas en las versiones
originales de Linux y Minix de Tanenbaum. Obligaron a Torvalds a pensar
profundamente sobre lo que quería hacer con Linux y considerar sus
fallas. Tuvo que escuchar los argumentos de un crítico y varios de sus
compañeros en la red y luego presentar contraargumentos sobre por qué su
kernel de Linux no apesta demasiado.

Esta lucha abierta tuvo un efecto muy diferente al que se desarrollaba
en el sistema legal. Los desarrolladores y los hackers de UNIX evitaron
las diversas versiones gratuitas de BSD debido a la nube legal. Si un
juez decidiera que AT&T y USL tenían razón, todos habrían tenido que
abandonar su trabajo en la plataforma. Si bien el CSRG trabajó duro para
liberarse, los jueces no siempre toman las decisiones que queremos.

La pelea entre Torvalds y Tanenbaum, no obstante, atrajo a la gente al
proyecto. Otros programadores como David Miller, Ted T'so y Peter da
Silva intervinieron con sus opiniones. En ese momento, solo eran
espectadores interesados. Con el tiempo, se convirtieron en parte del
grupo de expertos de Linux. Pronto contribuyeron con el código fuente
que se ejecutaba en Linux. La emoción de la discusión los obligó a mirar
el sistema operativo de juguete de Torvalds y tratar de decidir si su
defensa tenía algún sentido. Hoy, David Miller es uno de los mayores
contribuyentes al kernel de Linux. Muchos de los debatientes originales
se convirtieron en importantes contribuyentes a los cimientos de Linux.

Esta pelea atrajo a la gente y los mantuvo involucrados. Mostró que
Torvalds se tomaba en serio el proyecto y estaba dispuesto a pensar en
sus limitaciones. Más importante aún, expuso estas limitaciones e
inspiró a otras personas en la red a dar un paso adelante y tratar de
solucionarlas. Todos podían leer los argumentos y participar. Incluso
hoy, es posible desenterrar los archivos de esta batalla y leer con
detalles insoportables lo que la gente estaba pensando y haciendo. La
pelea AT&T/USL-versus-Berkeley aún está sellada.

Hasta el día de hoy, todos los devotos de los diversos BSD rechinan los
dientes cuando oyen hablar de Linux. Piensan que FreeBSD, NetBSD y
OpenBSD son mejores y tienen buenas razones para sostener tal credo.
Saben que fueron los primeros en salir con un sistema completo en
funcionamiento. Pero Linux está en la portada de las revistas. Todos los
grandes técnicamente sucios ahora están comenzando a usar "Linux" como
sinónimo de software libre. Si AT&T nunca demandara, los equipos de BSD
serían los que cosecharían la gloria. Serían a ellos a quienes recurría
Microsoft cuando necesitaba un competidor plausible. Serían más famosos.

Pero eso es llorar sobre la leche derramada. El CSRG de Berkeley vivió
una vida de relativo lujo en su mundo enriquecido con grandes donaciones
corporativas y gubernamentales. Tomaron el efectivo, y era solo cuestión
de tiempo antes de que alguien los reclamara. Sí, al final ganaron, pero
llegó demasiado tarde. Torvalds ya estaba fuera de la puerta y atraía a
más discípulos.

McKusick dice: "Si trazas la base de instalación de Linux y BSD en los
últimos cinco años, verás que ambos están en crecimiento exponencial.
Pero BSD está atrasado entre dieciocho y veinte meses. Ese es el tiempo
que tomó entre Net La versión 2 y el 4.4BSD-Lite libre de cargas. Ese es
el tiempo que tardó el sistema judicial en hacer su trabajo".