Veinte años de Berkeley Unix: de propiedad de AT&T a libre
redistribución


##UNIX Originarios

Los creadores de Unix Ken Thompson y Dennis Ritchie presentaron el
primer artículo sobre el mismo en el Simposio sobre los Principios de
los Sistemas operativos en la Universidad de Purdue en noviembre de
1973. Un profesor de la Universidad de California en Berkeley - Bob
Fabry - se encontraba presente, e inmediatamente solicitó interesado una
copia del sistema, para poder experimentarla en su Centro de Cómputo
universitario.

Por entonces, en Berkeley contaban con los grandes mainframes de
procesamiento por lotes, por lo que la orden del día era obtener primero
una minicomputadora PDP-11/45 adecuada para funcionar con la entonces
vigente Versión 4 de Unix. Para adquirir esta minicomputadora PDP-11/45
se aunaron presupuestos de los Departamentos de Ciencias de la
Computación de Berkeley, de Matemáticas y el de Estadística. En enero de
1974, los boratorios Bell les remitieron una cinta magnética con la
versión 4 y el estudiante graduado Keith Standiford instaló el Unix en
ella.

Si bien Ken Thompson (antiguo alumno de Purdue) no participó en el
Centro de Cómputo de Berkeley como lo había hecho con la mayoría de los
entornos hasta ese momento, pronto requirieon de su experiencia para
dilucidar ciertos cuelgues en la máquina. Como en Berkeley solo contaban
con un módem de acoplador acústico de 300 baudios sin capacidad de
respuesta automática, Thompson debía llamar al centro de cómputo
Standford y pedía que colocaran el auricular en el módem; esta fue la
forma en la que Thompson pudo depurar de forma remota los volcados de
memoria desde Nueva Jersey.

Muchos de los bloqueos eran provocados por el controlador de disco de
DEC, incapaz de realizar búsquedas simultáneas de manera confiable (al
contrario de lo que afirmaba su documentación). ¡El PDP-11/45 de
Berkeley fue el primer sistema que usó Ken el cual tenía dos discos
acoplados al mismo controlador! Esta depuración remota de Thompson en
persona constituye un primer ejemplo de la cooperación surgida entre
Berkeley y Bell Labs. Fue fundamental la voluntad de los investigadores
de los laboratorios de compartir su trabajo con Berkeley para las
mejoras del software disponible en Berkeley.

Si bien Unix pronto estuvo funcionando de manera confiable, la coalición
de Ciencias de la Computación, Matemáticas y Estadística comenzó a
resquebrajarse: Matemáticas y Estadísticas querían correr el sistema
operativo RSTS de DEC. Tras debatir, acordaron salomónicamente repartir
turnos departamentales: Unix funcionaría durante ocho horas seguidas
luego de las dieciséis horas en los que lo haría RSTS. Para promover la
equidad, los intervalos de tiempo rotaban diariamente. Unix funcionaría
de 8 AM a 4 PM un día, 4 PM hasta la medianoche del día siguiente, y de
la medianoche hasta las 8 AM del tercer día. Resultó revelador que los
estudiantes que tomaban el curso de Sistemas Operativos preferían hacer
sus proyectos en Unix en estos horarios extraños, en lugar de hacerlo en
la máquina de procesamiento por lotes.

El proyecto de base de datos INGRES de los profesores Eugene Wong y
Michael Stonebraker estuvo entre los primeros en pasarse del entorno de
procesamiento por lotes al de tiepo compartido que ofrecía Unix, ya que
ambos se se cansaron por los confinamientos que ya eran evidentes del
viejo método. Rápidamente encontraron intolerable la burocrática escasez
de tiempo de la máquina en el 11/45, por lo que para la primavera de
1974, gestionaron una PDP-11/40 con la Unix 5ta Edición recién salida.

>La base de datos INGRES, cuya primera distribución salió en otoño
>boreal de 1974, constituyó el primer desarrollo departamental
>distribuido (con varios cientos de copias en los siguientes 6 años,
>estableciendo cierta reputación en Berkeley para el desarrollo de
>aplicaciones reales).

Incluso tras volar al INGRES de la PDP-11/45, los demás estudiantes
todavía se veían limitados para programar. Como solución, en junio de
1974 Stonebraker y Fabry se propusieron conseguir dos PDP-11/45 más para
uso exclusivo del Dpto de Ciencias de la Computación. Para cuando
lograron juntar el presupuesto, a principios de 1975 DEC anunció el
lanzamiento de su modelo PDP-11/70, minicomputadora que se prometía muy
superior a la PDP-11/45. Aunando el presupuesto para las dos PDP-11/45
terminaron comprando una PDP-11/70, que arribó en otoño boreal de 1975.
Fue justo el momento en que Ken Thompson decidió tomarse un año sabático
para obrar como profesor invitado en la Universidad de California en
Berkeley, su alma mater. Thompson, junto con Jeff Schriebman y Bob
Kridle, trajeron el último Unix - la Sexta Edición - para el recién
instalado PDP-11/70.

También arribaron dos estudiantes graduados que inicialmente pasaron
totalmente desapercibidos: Bill Joy y Chuck Haley. Ambos se interesaron
de inmediato en el nuevo Unix Sexta Edición, y comenzaron a trabajar en
un entorno de desarrollo de Pascal que el mismo Thompson había
programado para la PDP-11/70. Lo ampliaron y mejoraron hasta el punto de
convertirlo en el lenguaje preferido en el campus por su excelente
esquema de recuperación de errores y rápido tiempo de compilación y
ejecución.

Como Berkeley habían progresivamente comenzado a reemplazar las viejas
terminales teletipo Modelo 33 por novedosas terminales con pantalla de
video Siegler ADM-3, Joy y Haley no tardaron en verse ahogados por las
limitaciones del veterano editor ed (concebido originalmente teniendo en
cuenta a las lentas teleimpresoras electromecánicas). Se pusieron
entonces modificar un editor llamado em obtenido del profesor George
Coulouris del Queen Mary's College de Londres, lo reprogramaron para
operar en monitores de video, logrando un editor de una línea a la vez,
el ex.

A finales del verano boreal de 1976 Thompson partió, y fue entonces que
Joy y Haley comenzaron a interesarse en el kernel de Unix. Bajo la
atenta mirada de Schriebman, lo emparcharon y mejoraron gracias a la
cinta denominada "cincuenta cambios" remitida desde el Bell Labs. Luego
realizaron pequeñas mejoras propias que simplificaban ciertos cuellos de
botella del kernel.

##Primeras Distribuciones

A consecuencia de los comentarios de boca en boca acerca del desempeño
del compilador Pascal, empezaron a aparecer pedidos en el ámbito
universitario de copias de todo el sistema. Para principios de 1977, Joy
integró lo que llamó la "Berkeley Software Distribution", en forma de
ficheros de código fuente compilables, en un carrete de cinta magnética.
Esta primera distribución incluía el IDE de Pascal y - metido en un
oscuro subdirectorio del código fuente del Pascal - se encontraba el
editor ex. Para el año siguiente, Joy - en calidad de secretario de
distribución - había remitido unas treinta copias gratuitas de la cinta
de sistema.

No bien hubo terminales ADM3A (con direccionamiento de cursor), Joy
escribió el editor vi. Esto introdujo a Berkeley en la edición de texto
basada en pantalla. Pronto se vió en un dilema: como los equipos viejos
nunca se reemplazaban al unísono, debió decirdir una etrategia que
consolidara la gestión de distintos modelos de terminales mediante el
uso de un pequeño intérprete que hiciera caso de sus características
técnicas. Este esfuerzo finalmente se convertiría en la aplicación
termcap.

>Termcap permitió finalmente compatibilizar los esfuerzos de Unix
>haciéndolos compatibles con múltiples terminales de video y emuladores
>de terminales no estandarizadas.

##2BSD
Para mediados de 1978, la distribución del software claramente
necesitaba una actualización. La comunidad de usuarios robusteció al
sistema Pascal, haciendo gala de un compilador de dos pasadas capaz de
correr en un viejo PDP-11/34. El resultado de esta actualización fue la
"Segunda distribución de software de Berkeley", nombre abreviado 2BSD,
que incluía al editor vi, pascal, y termcap. Bill Joy preparó una vez
mas la distribución sin ayuda de nadie, haciendo caso de solicitudes
telefónicas de los usuarios del sistema. Durante el año siguiente
despachó casi setenta y cinco cintas. Si bien para 1980 Joy se dedicó a
otros proyectos, lo cierto es que 2BSD continuó expandiéndose.

###2.11BSD
La versión final de esta distribución, la 2.11BSD, constituyó un sistema
operativo completo de 16 bits utilizado en centenares de
minicomputadoras PDP-11, que incluso una década después corría en varios
rincones del globo.

Fue una de las ramas más utilizadas entre esas máquinas y sus clones, ya
que terminó ofreciendo mayores posibilidades que el Unix original para
dicha plataforma.

#VAX Unix

A principios de 1978, el profesor Richard Fateman comenzó a buscar una
máquina con mayor espacio de direccionamiento en donde poder continuar
su labor de desarrollo de Macsyma (originalmente inciada en una PDP-10
de 36 bits). La VAX-11/780 de 32 bits recientemente anuncaida por DEC
cumplía con tales requisitos gracias a su capacidad de virtualización, y
como se encontraba dentro de las posibilidades presupuestarias, elaboró
una propuesta a la National Science Foundation unificando fondos
departamentales para la adquisición de una VAX.

En principio, la VAX corría el sistema operativo DEC VMS que hacía
empleo de la memoria virtual, pero el departamento - acostumbrado a Unix
- quería seguir usándolo. En consecuencia, obtuvieron una copia del Unix
32/V portado a la VAX por parte de John Reiser y Tom London de Bell
Labs.

Si bien 32/V permitía correr la 7ma. Edición de Unix en la VAX, en
realidad no aprovechaba su capacidad de memoria virtual por hardware de
esta minicomputadora; al igual que los portes predecedentes para PDP-11,
se basaba simplemente en el uso de memoria de intercambio en disco. El
grupo Macsyma de Berkeley se vió entonces limitado - pues la falta de
memoria virtual implicaba que el espacio de direccionamiento para
procesos se veía acotado - en la práctica al tamaño de memoria física
instalada en la VAX (inicialmente 1 megabyte).

>El último UNIX lanzado por los Laboratorios Bell fue 32/V; a partir de
>entonces, todos los lanzamientos de Unix de AT&T, inicialmente System
>III y luego System V, fueron administrados por un grupo diferente que
>enfatizó lanzamientos comerciales estables. Con la comercialización de
>Unix, los investigadores de los Laboratorios Bell ya no pudieron actuar
>como cámara de resonancia para la investigación en curso de Unix. En la
>medida que la comunidad de investigación continuó modificando el
>sistema Unix, descubrió que se necesitaba una organización capaz de
>producir publicaciones de investigación. Debido a su participación
>temprana en Unix y su historial de lanzamiento de herramientas basadas
>en Unix, Berkeley rápidamente asumió este papel, antes proporcionado
>por los Laboratorios Bell.

Para solventar este problema, Fateman consultó al profesor Domenico
Ferrari - miembro de la facultad de sistemas de Berkeley - con
intenciones de investigar la posibilidad que su grupo escribiera un
controlador de memoria virtual que funcionase en Unix. Fue Ozalp
Babaoglu - uno de los estudiantes a cargo de Ferrari - quien se abocó a
la tarea de implementar un método de paginación de trabajos en la VAX;
esta labor fue sumamente compleja pues la VAX carecía de bit de
referencia.

Estando Babaoglu próximo a finalizar su prototipo, consultó a Bill Joy
para que le explicase ciertas complejidades internas del kernel Unix.
Intrigado por el enfoque de Babaoglu, Joy se le unió para colaborar en
la integración del código del Unix 32/V, y luego depurarlo.

Lamentablemente sólo disponían en Berkeley de un único VAX (tanto para
programación como para uso). Por ello la comunidad de usuarios debió
bootear el 32/V de producción y en el "Virtual VAX/Unix"
alternativamente, incluso durante las festividades navideñas. El VAX con
frecuencia este último se detenía, seguido varios minutos más tarde por
un aviso de inicio de sesión de 32/V. Recién pudieron subsanar la
mayoría de los errores para enero de 1979, con lo cual el 32/V sin
memoria virtual quedó relegado de la historia.

##3BSD
Joy comprendió que la existencia del VAX de 32 bits de producción en
masa irremediablemente dejaría obsoletas a las PDP-11 de 16 bits, por lo
que comenzó a portar el software 2BSD a las nuevas VAX. Mientras que
Peter Kessler y Marshall McKusick portaban Pascal, Joy se encargó de
portar los editores ex y vi, el intérprete de comandos C Shell y una
miríada de programas pequeños que habían compuesto la distribución 2BSD.
Para fines de 1979, se había completado el portado entero a la VAX. Esta
distribución incluía el empleo de un kernel que habilitaba el uso de
memoria virtual, las utilidades estándar de 32/V y las adiciones de
2BSD. Fue en diciembre de 1979 - al cabo de casi un año de trabajo - que
Joy pudo despachar la primera de casi cien copias.

3BSD, la primera Distribución del UNIX de Berkeley para VAX, pudo correr
ya en los gabinetes celestes de esta importante máquina de 32 bits con
memoria virtual, y con ello asegurar el futuro del sistema operativo en
la máquina más candente del momento.


#Soporte DARPA

Mientras tanto, en las oficinas de los planificadores de la Agencia de
Proyectos de Investigación Avanzada de Defensa (DARPA), se llevaban a
cabo discusiones que tendrían gran influencia en el trabajo en Berkeley.
Uno de los primeros éxitos de DARPA había sido establecer una red de
datos nacional capaz de vincular todos sus principales centros de
investigación: la ARPANET.

Para entonces se estaba haciendo evidente que muchas de las computadoras
en estos centros de cómputo que oficiaban de nodos de la red se
encontraban próximas al final de su vida útil y debía afrontarse su
reemplazo.

Los problemas: el mayor costo de esta empresa estaba dado por el portado
del software de investigación a las nuevas máquinas. Además, muchas de
los centros de cómputo se veían imposibilitada de compartir su software
debido a las incomptaibilidades de hardware y sistemas operativos. La
elección de un único proveedor de hardware resultaba impráctica debido a
los distintos requerimiuentos computacionales de los distintos grupos de
investigación, y la inconveniencia de depender de un único fabricante.

En consecuencia, los planificadores de DARPA decidieron que la mejor
solución sería unificar a nivel de sistemas operativos. Tras mucho
discutir, se escogió a Unix como estándar debido a su comprobada
portabilidad.

En el otoño de 1979, Bob Fabry respondió a este interés de DARPA para
adoptar Unix elaborando una propuesta que sugería que Berkeley
desarrollara "una versión mejorada del 3BSD capaz de ser utilizada para
la comunidad DARPA". Fabry llevó una copia de su propuesta a una reunión
de contratistas de VLSI y procesamiento de imágenes de DARPA, además de
representantes de Bolt, Beranek y Newman (BBN, los desarrolladores de
ARPAnet). Tuvieron cierta reserva sobre si Berkeley podría producir un
sistema de trabajo; sin embargo, el lanzamiento de 3BSD en diciembre de
1979 había disipado la mayoría de las dudas.

Con la creciente reputación otorgada por el lanzamiento de 3BSD para
validar sus afirmaciones, Bob Fabry pudo obtener un contrato de 18 meses
con DARPA a partir de abril de 1980. Este contrato estaba orientado a
"agregar funcionalidades solicitadas por los contratistas de DARPA".
Bajo auspicios de este contrato, Bob Fabry estableció una organización
que fue bautizada como Grupo de Investigación de Sistema de Cómputo, o
"Computer Systems Research Group", CSRG. El enjundio burocrático sirvió
para canalizar amplios fondos de desarrollo.

##4BSD
Joy incorporó el control de trabajo de Jim Kulp y agregó reinicio
automático, un sistema de archivaje de bloques de 1K y soporte para la
última minicomputadora VAX, la VAX-11/750. En octubre de 1980 lanzaron
4BSD, distribución portable pulida que también incluía el compilador
Pascal, el sistema Franz Lisp y un programa de manejo de correo
electrónico mejorado. Durante su vida útil de nueve meses, se remitieron
casi 150 copias. El acuerdo de licencia se hizo institucional en lugar
de por máquina; por tal motivo, se calcula que la distribución se
utilizó en aproximadamente unas 500 máquinas.

##4.1BSD
Con este mayor despliegue y visibilidad del Unix de Berkeley aparecieron
las críticas. David Kashtan del Stanford Research Institute escribió un
ácido artículo comparando VMS y el Unix de Berkeley. En el denostaba lo
que describía como graves desprolijidades y problemas de rendimiento en
el Unix para VAX. Tocado por tamaño desafío fundado, Joy comenzó a
adelgazar el código fuente del kernel, dejando de lado sus planes por
varios meses. En cuestión de semanas, pudo escribir un artículo de
refutación donde demostraba que lo atendido por Kashtan ahora podía
correr tan bien en Unix como en VMS.

Su intención original habría sido llamar a esta versión depurada 5BSD;
sin embargo, AT&T objetó la propuestas aduciendo que los clientes lo
confundirían con su última versión aún no comercializada de Unix, el
System V. Para resolver el intríngulis, Berkeley acordó cambiar el
esquema de nombres para versiones futuras, reteniendo la 4BSD y solo
incrementar luego un decimal de versionado.

Fue así que en lugar de tomar 4BSD y adicionar parches al código fuente
gracias al programa automático de Robert Elz para solventar estas bajo
el nombre de 5BSD, lo lanzó en junio de 1981 con el nombre de 4.1BSD.
Esta versión solventada tuvo una vida útil de dos años, durante lo cual
se distribuyeron alrededor de 400 copias.

##4.2BSD

Con el lanzamiento de 4.1BSD, se aquietaron las aguas sobre el
rendimiento, en gran medida. DARPA estuvo lo suficientemente satisfecha
con los resultados del primer contrato, que extendió el vínculo a través
de un nuevo acuerdo por dos años con Berkeley, que incluía una generosa
financiación, casi cinco veces superior a la original. La mitad de este
dinero se destinaría al Unix y el resto a otras investigaciones del
departamento de Ciencias de la Computación. Este contrato requería que
se hicieran "amplias mejoras al sistema para que la comunidad de
investigación de DARPA pudiera hacer mejor su trabajo". Se establecieron
metas y se dio inicio a labores que definieran las modificaciones que se
deberían hacer al sistema con base en las necesidades de la comunidad
DARPA. En particular, se deseaba incluir: * un sistema de archivos más
veloz que aumentara el desempeño de la tecnología de disco disponible, *
procesos con un espacio de direccionamiento de varios gigabytes, *
comunicación inter-procesos flexibles para investigar el trabajo en
sistemas distribuidos, *soporte de red, de modo que las máquinas que lo
corriese pudiesen participar sin incordios en la ARPAnet.

Duane Adams - gestor de contrato de Berkeley en DARPA - conformó un
grupo conocido como el "Comité Directivo" para guiar el trabajo de
diseño y garantizar el abordaje de las necesidades de la comunidad
investigadora. Este Comité se reunía dos veces al año entre abril de
1981 y junio de 1983. Eran pesos pesados del desarrollo en esa época:

*DARPA: Duane Adams y Bob Baker *Bolt, Beranek and Newman (BBN): Alan
Nemeth y Rob Gurwitz *Laboratorios Bell: Dennis Ritchie *Universidad de
California (Berkeley): Bob Fabry, Bill Joy y Sam Leffler *Instituto de
Tecnología de Massachusetts (MIT): Bert Halstead *Universidad de
Stanford: Keith Lantz *Universidad Carnegie-Mellon: Rick Rashid
*Universidad de California en Los Ángeles: Jerry Popek *Instituto de
Ciencias de la Información: Dan Lynch

>A partir de 1984, estas reuniones del Comité Directivo fueron
>reemplazadas por seminarios ampliados capaces de incluir a muchas más
>personas.

En julio de 1981 el Comité elaboró una Circular de Funcionalidaes
Iniciales, que dio rienda a intensos debates.

>Titulada "Especificación del Sistema 4.2BSD", este documento publicado
>en febrero de 1982 contenía una descripción concisa de las interfaces
>de usuario propuestas para las instalaciones del sistema que se
>implementarían en 4.2BSD.

En verano de 1981, se asumió la implementación del nuevo sistema de
archivos. Durante el verano boreal, Joy se centró en la implementación
de un prototipo de comunicación inter-procesos, y en el otoño boreal de
1981, Sam Leffler se constituyó en el CSRG como integrante a tiempo
completo para asistir a Bill Joy.

En lo que refería a redes, Rob Gurwitz no tardó en realizar una
implementación temprana de los protocolos TCP/IP en Berkeley, la cual
Joy pulió y ajustó. A Joy y Leffler se les hizo evidente por entonces
que el nuevo sistema debería soportar más que solo los protocolos de red
estándar de DARPA. A tal fin rediseñaron la estructura interna de BSD,
refinando interfaces para que se pudieran usar múltiples protocolos de
red simultáneamente.

###4.1a
Conforme esta reestructuración interna estuvo completa y los protocolos
TCP/IP fueron integrados a la implementación prototipo de la Propuesta,
se agregaron varias aplicaciones simples que proporcionaban acceso
inmediato de los usuarios locales a recursos remotos. Estos programas -
rcp, rsh, rlogin y rwho - fueron concebidos como meras herramientas
temporales, con la idea de reemplazarlos eventualmente por programas
mejor escritos (de ahí el uso del prefijo "r", por "investigación").
Este entorno - denominado 4.1a - se distribuyó por primera vez en abril
de 1982 para un uso local; nunca fue la intención darle circulación
amplia, si bien proliferaron copias piratas en la medida que los demás
centros de cómputo se impacientaban aguardando el nebuloso lanzamiento
del futuro 4.2 especificado.

Este sistema 4.1a experimental realmente quedó obsoleto mucho antes de
que se completara. Sin embargo, el feedback recibido resultó valioso
para robustecer al nuevo sistema.


###4.1b
Simultáneamente con el desarrollo de 4.1a, se completó la implementación
del sistema de archivos nuevo y - para junio de 1982 - se incorporó por
completo al kernel 4.1a. El entorno resultante fue denominado 4.1b y
sólo corrió en unas pocas máquinas de desarrollo escogidas en Berkeley.
Joy sintía que - con las modificaciones significativas inminentes a la
Distribución - lo mejor sería incluso evitar un uso local,
particularmente porque se requeriría compaginar ambos sistemas de
archivaje en cada máquina durante el proceso de migración entre 4.1a y
4.1b. Una vez que el sistema de archivos demostró estabilidad, Leffler
le sumó las llamadas al nuevo sistema de archivos. Joy trabajó
entretanto en la revisión de los inter-procesos y las funcionalidades de
red.

Para finales de la primavera boreal de 1982, Joy anunció que se alejaría
de Berkeley para incorporarse a Sun Microsystems. Durante el verano,
dividió su tiempo entre Sun y Berkeley, dedicando la mayor parte de su
tiempo a pulir revisiones de comunicación inter-procesos y reorganizando
el código fuente del kernel de Unix para aislar las dependencias de las
máquinas.

>Con la preanunciada partida de Joy, fue Leffler quien asumió la
>responsabilidad de completar el proyecto BSD.

###4.1c
El lanzamiento para la Comunidad DARPA ya se habían comprometido con
fecha aproximada de primavera de 1983. Dadas las limitaciones de tiempo,
analizaron el trabajo restante por hacer y consideraron nuevas
prioridades. En particular, se despriorizaron las mejoras de memoria
virtual y las partes más sofisticadas del diseño de comunicación
inter-procesos (luego archivadas por completo).

Cumplido el año de la última implementación y ante las crecientes
expectativas de la comunidad Unix, se decidió armar una versión
intermedia que retuviese usuarios hasta dar con el sistema final. Esta -
denominada 4.1c - si se distribuyó a partir de abril de 1983: fue
utilizada mayormente como preparación al portado de la futura 4.2.
Pauline Schwartz fue contratada para hacerse cargo de las tareas de
distribución a partir de la versión 4.1c.

En junio de 1983, Bob Fabry cedió el control administrativo del CSRG a
los profesores Domenico Ferrari y Susan Graham para dar inicio a su año
sabático, libre ya del ritmo frenético impreso a los cuatro años
anteriores. Leffler continuó agregando nuevas funciones de señal,
agregando soporte de red, rehaciendo el sistema de E/S independiente
para simplificar su instalación, integrando las funciones de cuota de
disco de Robert Elz, actualizando toda la documentación y rastreando el
errores de la versión 4.1c.

##4.2BSD
En agosto de 1983, el sistema especificado finalmente fue lanzado como
4.2BSD.

La popularidad de 4.2BSD auspiciado por DARPA resultó impresionante; en
dieciocho meses se habían emitido más de 1.000 licencias de instalación.
Esto significó que 4.2BSD tuvo más instalaciones que de todas las
versiones de Berkeley anteriores combinadas. Resultó notable que la
mayoría de los proveedores comerciales de Unix prefirieron al sistema
4.2BSD en lugar del Unix System V, la apuesta comercial propia de AT&T.
La razón fue que System V carecía de redes y un sistema de archivaje
Berkley Fast. Sin embargo, la versión BSD de Unix solo retuvo su
palmarés dominante durante unos años a mediados de los 80s antes de
volver a sus raíces; conforme se integraron redes y otras mejoras de
4.2BSD a las distintas release de System V, los usuarios volvieron a
gravitar hacia el. Sin embargo, el código desarrollado a posteriori en
BSD continuó incorporándose a la base del UNIX System V.

Al igual que lo sucedido tras el lanzamiento de 4.1BSD, las críticas al
4.2 no tardaron en llegar: la mayoría de ellas se referían a la lentitud
del sistema. El problema - como era de esperar - tenía sus raíces en el
ajuste final de las nuevas funciones, y a los nuevos usos del kernel
generalista. El primer año se dedicó nuevamente a estos menesteres.

Tras dos años de trabajo de ajuste y refinado del código de red, se
anunció en la Conferencia Usenix de junio de 1985 el lanzamiento del
4.3BSD, más tarde para ese verano. Sin embargo, estos planes se vieron
frustrados por la gente de BBN: criticaron a 4.2BSD en virtud que no
haber sido actualizado con la versión final de su código de red, y que
en lugar de ello lo habían hecho implementando el triste prototipo
inicial emparchado de muchos años atrás. Estas consideraciones de BBN
llegaron a DARPA - pues la política decía que Berkeley debía crear la
interfaz mientras que BBN debía realizar el protocolo - por lo que
Berkeley debía reemplazar el código TCP/IP de 4.3BSD con la
implementación de BBN.

Mike Karels recibió el código fuente BBN e hizo una evaluación de la
programación efectuada desde la creación del prototipo de Berkeley. En
su opinión lo mejor sería incorporar las buenas ideas del código BBN al
viejo código de Berkeley, pero de ninguna manera reemplazarlo, en vista
de las pruebas y mejoras generalizadas a la versión 4.2BSD. Como
compromiso, ofreció a incluir ambas implementaciones cuando saliese la
distribución 4.3BSD y permitir que fuesen sus quienes decidieran cuál
integrar en su kernel. En DARPA estudiaron la propuesta, pero
consideraron que ofrecer dos ramas de código generaría problemas
innecesarios de interoperabilidad, dictaminando que solo debería
incluirse una única implementación. Comisionaron a Mike Muuse del
Laboratorio de Investigación de Balística - a quien tanto Berkeley como
BBN consideraban un tercero independiente - para decidir cual utilizar.
Tras un mes de pruebas, llegó el informe de que el código de Berkeley
era mas eficiente pero que el código BBN resistía mejor la congestión.
La evaluación de desempate tuvo como resultado que el código de Berkeley
pudo correr todas las pruebas sin problemas, mientras que el código de
BBN provocaba kernel panics bajo ciertas condiciones de estrés. Ante
estas condiciones, el veredicto final de DARPA fue mantener el código de
red de Berkeley para su versión 4.3BSD.

##4.3BSD
En junio de 1986 finalmente se publicó el sistema 4.3BSD pulido. Como
era de esperarse, atemperó muchas de las quejas sobre el rendimiento (al
igual que la versión 4.1BSD había disipado las dudas de 4BSD). Si bien
la mayoría de los proveedores habían iniciado su regreso a System V,
gran parte de 4.3BSD se trasladó a tal sistema también, particularmente
al subsistema de redes.

##2.11BSD
En octubre de 1986, Keith Bostic se unió al CSRG. Una condición de su
empleo era que se le permitiera terminar un proyecto en el que se había
desempeñado en su trabajo anterior: portar 4.3BSD a las veteranas
PDP-11. Si bien se consideraba imposible que el sistema compilara de 250
Kbytes en la VAX a los 64 KB de espacio de direccionamiento de 64 Kbytes
de las PDP-11, el portado resultó exitoso (haciendo uso del intrincado
conjunto de superposiciones y estados de procesador auxiliares
disponibles en dicha arquitectura). Como consecuencia de este logro fue
el lanzamiento de 2.11BSD, realizado por Casey Leedom y Bostic,
utilizado por largo tiempos hasta la discontinuación de los últimos
PDP-11 de producción en 1998.

###4.3BSD-Tahoe
En el interín se iba haciendo cada vez más evidente que la arquitectura
VAX estaba llegando al final de su vida útil, por lo que sería hora de
considerar otras arquitecturas para poder correr BSD.

Computer Consoles, Incorporated creó una nueva arquitectura prometedora
de su época, a la que denominó Power 6/32. Desafortunadamente, esta
murió cuando la empresa decidió cambiar su dirección estratégica. Sin
embargo, proporcionaron al CSRG varias máquinas, lo que les permitió
terminar fácilmente tal propuesta. En consecuencia de esta labor, Bill
Joy había dividido el núcleo BSD en código dependientes de máquina y
código independientes de máquina. El resultado de este trabajo de
organización del código vio la luz como 4.3BSD-Tahoe en junio de 1988.

>El nombre Tahoe proviene del nombre de desarrollo utilizado por
>Computer Consoles, Incorporated, para la máquina que finalmente
>lanzaron con el nombre de Power 6/32. Si bien la vida útil del soporte
>de la máquina Power 6/32 fue breve, el trabajo realizado para dividir
>el kernel en partes independientes y dependientes de la máquina
>demostró ser extremadamente valioso, ya que el BSD terminó siendo mucho
>más simple de transferirse a muchas otras arquitecturas futuras.

##Rumor de Guerra (UNIX)
Hasta el lanzamiento de 4.3BSD-Tahoe, todos los destinatarios de BSD
debían adquirir primero una licencia de código fuente del viejo UNIX
32/V de AT&T, raíz del árbol de desarrollo. Eso se debía a que Berkeley
nunca publicó los BSD en un formato solo binario, sino que las
distribuciones de cinta magnética contenían el código fuente completo
para la compilación de cada parte del sistema.

>La historia del sistema Unix y del sistema BSD en particular ha
>demostrado la valía de poner a disposición de los usuarios el código
>fuente. En lugar de usar el sistema de forma pasiva, estos trabajaban
>activamente para corregir errores, mejorar el rendimiento y la
>funcionalidad, e incluso agregar funciones completamente nuevas.

###Networking Release 1
A mediados de 1988 AT&T decidió elevar el costo de las licencias para
modificación del código fuente, barajando la friolera de 50.000 dólares.
Como el costo de licencias de código fuente de origen de AT&T lo hacía
prohibitivo, esperaban mudar el modelo a la distribución de copias
licenciadas de binarios precompilados. bajo este razonamiento económico,
se dificultarían las compilaciones a quienes querían un sistema
independiente con facilidades de red TCP/IP. Al recibir los primeros
rumores en este sentido, la comunidad de usuarios no tardó en solicitar
que Berkeley desglosara el código de red y las utilidades desarrolladas,
y las proporcionara bajo términos de licenciamiento que no requiriesen
de una licencia de código fuente por parte de AT&T. Esto se debía a que
el código fuente de red TCP/IP - desarrollado bajo auspicios de DARPA -
claramente no existía en la versión Unix 32/V (siendo que lo habían
desarrollado en su totalidad en Berkeley y sus colaboradores bajo atenta
mirada del Comité). Este código fuente que compendiaba aplicaciones de
red originales de BSD y las utilidades de soporte fueron - efectivamente
- lanzados en junio de 1989 bajo la designación de parche Networking
Release 1, el primer código fuente de libre distribución de Berkeley.

Los términos de la licencia del Network Release 1 resultaban liberales:
a cambio de 1.000 dólares, el licenciatario podría publicar el código
modificado o sin modificar, tanto en formato fuente o binario, sin
requerir abonar regalías ni denunciarlo a Berkeley. Los únicos
requisitos eran conservar intactos los avisos de derechos de autor
contenidos en el archivo fuente, y que los productos que incorporarsen
el código fuente de Berkeley y sus colaboradores lo indicaran de forma
explícita en su documentación. A pesar del costo de licencia, de la
copia y del envío físico de la cinta, lo cierto es se permitía a
cualquiera obtener una copia gratuita de alguien que ya la hubiese
abonado. En la práctica, varios centros de cómputo grande dejaron
disponible de hecho copias accesibles a través de FTP anónimo, poco
tiempo después de producido su lanzamiento.

El CSRG de hecho se alegró ante este fácil acceso, ya que varios
centenares de organizaciones realmente honraron abonar el costo de
licencia de modificación para sus copias, lo que facilitó el
financiamiento de mayores desarrollos.

###4.3BSD-Reno

Mientras tanto, el desarrollo continuó en el sistema base. El sistema de
memoria virtual cuya interfaz había sido descripta en el white paper de
4.2BSD finalmente se hizo realidad. En lugar de diseñar un nuevo sistema
de memoria virtual, se hizo caso a alternativas existentes (recayendo la
primera elección en el sistema de memoria virtual del SunOS de Sun
Microsystem, aunque esto no dio frutos). Se optó por una segunda opción:
incorporar el sistema de memoria virtual del sistema operativo MACH
escrito en la Universidad Carnegie-Mellon. Mike Hibler de la Universidad
de Utah fusionó esta tecnología central de MACH junto a la interfaz
descrita en la Especificación de 4.2BSD (que también era la interfaz
utilizada por SunOS).

La otra adición importante al sistema en ese momento fue una versión
compatible con Sun del Network Filesystem (NFS). De esta manera y una
vez más, se pudo evitar escribir el código NFS real y - en rigor - se
sustanció una implementación realizada por Rick Macklem en la
Universidad de Geulph en Canadá.

###4.3BSD-Reno
Si bien aún no contaban con elementos para finalizar la versión 4.4BSD,
el CSRG decidió auspiciar un lanzamiento provisional que sirviera para
recabar experiencias. Esta versión provisional con licencia se denominó
4.3BSD-Reno y tuvo lugar a principios de 1990. La gran ciudad de juego
en Nevada como un recordatorio oblicuo para sus destinatarios de que
ejecutar la versión provisional era un poco arriesgado.

###Network Release 2
Redes, Versión 2

Durante una de las reuniones grupales semanales en el CSRG, Keith Bostic
sacó a relucir el tema de la popularidad del las redes de libre acceso,
y consultó al grupo sobre la posibilidad de hacer un lanzamiento
ampliado que incluyera el código BSD para tal cometido. Le señalaron el
inconveniente que liberar partes grandes de un sistema sin garantizarlo
constituía una tarea enorme y de largo aliento, pero acordaron que si él
podía resolver cómo lidiar con la reimplementación abierta de los
cientos de utilidades y la enorme biblioteca de C, entonces podrían
abordar hacerlo con el kernel. Sentían sin embargo que la propuesta no
llegaría a nada.

Sin inmutarse, Bostic se convirtió en pionero en práctica de realizar un
esfuerzo de desarrollo de masas basado en la red. Solicitó a los
programadores reescribir las utilidades Unix desde cero, basándose
únicamente en sus descripciones publicadas. Su única compensación sería
que su nombre figurara entre los contribuyentes de Berkeley junto al
nombre de la empresa de servicios públicos que reescribieron. Estas
recontribuciones comenzaron lentamente e inicialmente en su mayoría
fueron para los servicios públicos triviales. Sin embargo, en la medida
que crecía la lista de servicios públicos terminados, Bostic continuó
utilizando eventos públicos como Usenix para solicitar contribuciones, y
con ello la tasa de contribuciones siguió creciendo. Pronto se superaron
las cien utilidades, y luego de 18 se habían reescrito casi todas las
utilidades y bibliotecas importantes.

No quedó mas remedio - entonces - que pasar a la revisión del Kernel.
Karels, Bostic y McKusick pasaron los meses siguientes revisando archivo
por archivo toda la distribución, quitando código fuente original de la
versión 32/V. Luego de eta labor a conciencia, sólo restaron seis
ficheros del kernel contaminados, que no podían reescribirse
trivialmente. Si bien consideraron reescribir dichos ficheros para
formar un sistema completo, terminaron lanzando solo lo que tenían. Para
ello solicitaron permiso a los directivos de la Universidad. Tras
debatir internamente y verificar el método para determinar el código
propietario, se les dio el visto bueno para hacer el lanzamiento.

##Network Release 2
La idea inicial era concebir un nombre completamente nuevo para nuestro
segundo lanzamiento de libre distribución. Sin embargo, arribaron a la
conclusión que escribir y aprobar una licencia completamente nueva por
los abogados de la Universidad constituiría una innecesaria pérdida de
tiempo y recursos. Decidieron llamar a la nueva versión Networking
Release 2 ya que sólo utilizarían una revisión del acuerdo de licencia
de Networking Release 1 ya aprobado. Esta segunda versión muy ampliada y
libremente distribuible comenzó a enviarse en junio de 1991. Los
términos y costos de redistribución eran los mismos de la primera
Network Release. De forma similar, varios cientos de personas y
organizaciones pagaron la tarifa de $1,000 para obtener la distribución
de Berkeley.

##386/BSD y NetBSD
Cerrar la brecha entre la distribución Networking Release 2 y un sistema
en pleno funcionamiento no requirió. En menos de seis meses posteriores
al lanzamiento, Bill Jolitz reescribió reemplazos para los seis archivos
faltantes. Rápidamente lanzó un sistema completamente compilado y de
arrancable en la arquitectura de PC basada en 386, al que llamó 386/BSD.
La distribución de 386/BSD de Jolitz se realizó casi en su totalidad
desde la red. Simplemente lo subió a un FTP anónimo y dejó que
cualquiera que la quisiera la descargara gratuitamente. En cuestión de
semanas tenía un gran número de seguidores.

Desafortunadamente, las demandas de mantener un trabajo de tiempo
completo implicaron que Jolitz no pudiese dedicar el tiempo necesario
para mantenerse al día con la avalancha de correcciones de errores y
mejoras entrantes que requería el 386/BSD para PC. Fue entonces quye - a
los pocos meses del lanzamiento de 386/BSD - un grupo de ávidos usuarios
de 386/BSD formó el grupo NetBSD para unir colectivamente sus recursos
para ayudar a mantener y luego mejorar el sistema. Sus lanzamientos se
conocieron como la distribución NetBSD. El grupo NetBSD eligió enfatizar
el soporte de tantas arquitecturas como fuese posible, y continuar el
desarrollo del estilo de investigación realizado por el CSRG. Hasta
1998, la distribución de NetBSD se hacía únicamente a través de la Red;
no existían otros medios de distribución disponibles.

El grupo continúa apuntando principalmente a los usuarios técnicos más
exigentes. Puede encontrar más información sobre el proyecto NetBSD en:
=> http://www.netbsd.org. Proyecto NetBSD

##FreeBSD
El grupo FreeBSD se formó unos meses después que el grupo NetBSD con un
estatuto que indicaba admitir solo la arquitectura de PC, persiguiendo a
un grupo de usuarios más grande y técnicamente menos avanzado, en la
misma verba que lo había hecho GNU con kernel Linux.

Programaron elaborados scripts de instalación y comenzaron a enviar su
sistema en un disco de CD-ROM de bajo costo. La combinación de facilidad
de instalación y fuerte promoción en red y eerias comerciales
importantes como Comdex condujo a una curva de crecimiento veloz.
Ciertamente, FreeBSD cuenta con la mayor base instalada de todos los
sistemas derivados de la Network Release 2.

FreeBSD también aprovechó el engorde de GNU con Linux al agregar un
confiable modo de emulación de Linux, que permite correr los binarios de
Linux en la plataforma FreeBSD. Esta función permite a los usuarios de
FreeBSD utilizar el conjunto cada vez mayor de aplicaciones disponibles
para Linux, a la vez que retienen la solidez, confiabilidad y el
rendimiento del sistema FreeBSD. El grupo abrió el FreeBSD Mall, que
reúne a muchas partes de la comunidad de FreeBSD, incluidos servicios de
consultoría, productos derivados, libros y un boletín informativo.
=>http://www.freebsdmall.com FreeBSD Mall

##OpenBSD
A mediados de la década de 1990, OpenBSD se separó del grupo NetBSD. Su
enfoque técnico estaba dirigido a mejorar la seguridad del sistema. Su
enfoque de marketing era hacer que el sistema fuera más fácil de usar y
estuviese más al alcande de todos. Por lo tanto, comenzaron a producir y
vender CD-ROM con muchas de las ideas de fácil instalación de la
distribución FreeBSD.

Se puede encontrar más información sobre el proyecto OpenBSD en
=>http://www.openbsd.org Proyecto OpenBSD

#La Demanda

Además de los grupos organizados para redistribuir libremente los
sistemas creados en torno a la cinta Networking Release 2, se formó una
empresa, Berkeley Software Design, Incorporated (BSDI), para desarrollar
y distribuir una versión comercial del código. (Se puede encontrar más
información sobre BSDI en => http://www.bsdi.com Berkeley Software
Design, Incorporated (BSDI).

Al igual que los otros grupos, comenzaron agregando los seis archivos
faltantes que Bill Jolitz había escrito para su versión 386/BSD. BSDI
comenzó a vender su sistema, incluidos tanto el código fuente como los
binarios, en enero de 1992 por $995. Comenzaron publicando anuncios
promocionando su descuento del 99% sobre el precio cobrado por el código
fuente de System V más los sistemas binarios. A los lectores interesados
se les dijo que llamaran al 1-800-ITS-Unix.

Poco después de que BSDI comenzara su campaña de ventas, recibieron una
carta de Unix System Laboratories (USL) - subsidiaria de propiedad
mayoritaria de AT&T escindida para desarrollar y vender Unix. La misiva
exigía que dejaran de promocionar su producto como Unix y, en
particular, que desistieran de usar el engañoso número telefónico. Si
bien dieron de baja la línea, y cambiaron los anuncios explicando que el
producto "no era Unix", la USL seguía descontenta y presentó una demanda
para impedir que BSDI vendiera su producto. La demanda alegaba que el
producto BSDI contenía un código USL patentado y secretos comerciales.
USL buscó obtener una orden judicial que detuviese las ventas de BSDI
hasta que se resolviera la demanda, alegando que sufrirían daños
irreparables por la pérdida de sus secretos comerciales si continuaban
las distribuciones de BSDI.

En la audiencia preliminar para la orden judicial, BSDI sostuvo que
simplemente estaban utilizando código fuente distribuido gratuitamente
por la Universidad de California junto a seis ficheros adicionales.
Estaban dispuestos a discutir el contenido de cualquiera de los seis
archivos agregados, pero no creían que se los debería responsabilizar
por la distribución de los archivos por parte de la Universidad de
California. El juez estuvo de acuerdo con el argumento de BSDI y dijo a
USL que tendrían que reafirmar su queja basándose únicamente en los seis
archivos o la desestimaría. Reconociendo que tendrían dificultades para
presentar un caso solo con los seis archivos, USL decidió entonces
presentar la demanda contra BSDI y la Universidad de California. Como
antes, USL inició una demanda de caución sobre la publicación de
Networking Release 2 de la Universidad y sobre los productos BSDI.

Con la inminente audiencia judicial a solo unas pocas semanas, el
litigio escaló. Todos los miembros del CSRG fueron citados al igual que
casi todos los empleados de BSDI. Escritos, contra-escritos y
contra-contra-escritos volaban entre los abogados de cada bando. Keith
Bostic y McKusick personalmente debieron redactar varios cientos de
páginas de material que terminaron en varios informes.

En diciembre de 1992, Dickinson R. Debevoise, juez de distrito de Nueva
Jerseyoyó los los argumentos a favor de la medida cautelar. Aunque los
jueces suelen fallar inmediatamente sobre las solicitudes de medidas
cautelares, decidió tomarlo en consideración. Un viernes, unas seis
semanas después, emitió un dictamen de cuarenta páginas en el que denegó
la medida cautelar y desestimó todas las demandas menos dos. Estas dos
quejas restantes se redujcían a derechos de autor recientes y la
posibilidad de pérdida de secretos comerciales. También sugirió que el
asunto debía presentarse en una audiencia estatal antes de que el
sistema judicial federal se abocara.

La Universidad de California captó la indirecta y acudió a la corte
estatal de California el lunes siguiente por la mañana con una
contrademanda contra la USL. Al presentarla primero en California, la
Universidad había establecido precedente para cualquier otro recurso
estatal. La ley estadounidense requiere que todas las presentaciones
estatales se realicen en un solo estado para evitar que un litigante con
mucho dinero desangre a un oponente presentando cincuenta casos en su
contra en cada estado de la Unión. Como resultado, si USL deseaba
emprender acción contra la Universidad en los tribunales estatales, se
vería obligada a hacerlo en California en lugar de en su estado nativo,
Nueva Jersey.

La demanda de la Universidad afirmaba que USL no había cumplido con su
obligación de otorgar el debido crédito a la Universidad por el uso del
código fuente BSD en Unix System V según exigía la licencia que habían
firmado con la Universidad. Si se determinaba válido el reclamo, la
Universidad solicitaría que USL fuese obligada a reimprimir toda su
documentación con el debido crédito agregado, notificar a todos sus
licenciatarios sobre su supervisión y publicar anuncios de página
completa en publicaciones importantes como The Wall Street Journal y la
revista Fortune notificando al mundo empresarial de su descuido
involuntario.

Poco después de la presentación ante el tribunal estatal, Novell compró
USL a AT&T. El CEO de Novell, Ray Noorda, declaró públicamente que
preferiría competir en el mercado que en los tribunales. Para el verano
de 1993, iniciaron conversaciones para llegar a un acuerdo.
Desafortunadamente, las dos partes se habían atrincherado tanto que las
conversaciones avanzaron lentamente. Con más insistencia de Ray Noorda
por parte de USL, se limaron muchas asperezas y finalmente se llegó a un
acuerdo en enero de 1994. Eliminaron tres ficheros de los 18.000 que
componían Networking Release 2, y efectuaron una cantidad de cambios
menores a otros ficheros. Además, la Universidad acordó agregar las
notas de derechos de autor de USL a unos 70 ficheros, si bien los mismos
continuaron redistribuyéndose libremente.

#4.4BSD

El lanzamiento recientemente bendecido se llamó 4.4BSD-Lite y se lanzó
en junio de 1994 bajo términos idénticos a los utilizados para los
lanzamientos de Networking. Específicamente, los términos permiten la
redistribución gratuita en forma binaria y fuente sujeta únicamente a la
restricción de que los derechos de autor de la Universidad permanezcan
intactos y que la Universidad reciba crédito cuando otros usen el
código. Simultáneamente, el sistema completo se lanzó como
4.4BSD-Encumbered, que todavía requería que los destinatarios tuvieran
una licencia de modificación de código fuente de parte de USL.

El acuerdo de la demanda también estipuló que USL no demandaría a
ninguna organización que utilizara 4.4BSD-Lite como base de desarrollo.
Por entonces, todos los grupos de BSD que se encotraban desarrollando
distribuciones - BSDI, NetBSD y FreeBSD - se vieron obligados a
recomenzar su base de código con las fuentes 4.4BSD-L, a las que
aplicaron luego sus propias mejoras y desarrollos. Si bien esta
reintegración provocó un retraso a corto plazo para el lanzamiento de
todos estos derivados de BSD, resultó en una bendición encubierta ya que
obligó a todos los grupos divergentes a resincronizarse con los tres
años de desarrollo que se habían producido en el CSRG desde el
lanzamiento del Networking Release 2.

###4.4BSD-Lite, Versión 2

El dinero recibido de las versiones 4.4BSD-Encumbered y 4.4BSD-Lite se
utilizó para financiar un esfuerzo a tiempo parcial para integrar
correcciones de errores y mejoras. Estos cambios continuaron durante dos
años hasta que la tasa de informes de errores y mejoras de funciones se
redujo prácticamente a cero. El conjunto final de cambios se conoció
como 4.4BSD-Lite, Versión 2 en junio de 1995. La mayoría de estos
cambios desembocarían en los otros sistemas también.

Tras el lanzamiento de 4.4BSD-Lite Release 2, el CSRG se disolvió.
Después de casi veinte años de pilotar el barco de BSD en las
tormentosas aguas, era hora de dejar que otros con ideas frescas y un
entusiasmo sin límites se hicieran cargo del timón.

Si bien puede parecer mejor tener una sola autoridad centralizada que
supervise el desarrollo del sistema, la idea de tener varios grupos con
diferentes estatutos asegura probar muchos enfoques diferentes. Debido a
que el sistema se publica en forma de código fuente, otros grupos pueden
recoger fácilmente las mejores ideas. Si un grupo se vuelve
particularmente efectivo, eventualmente puede convertirse en el sistema
dominante.

Hoy en día, el movimiento del software de código libre está ganando cada
vez más atención y respeto. Aunque el sistema GNU con Linux es quizás el
más conocido, alrededor de la mitad de las utilidades que se empaquetan
con ellos provienen de la distribución BSD. Las distribuciones de Linux
también dependen en gran medida del compilador, los depuradores y otras
herramientas de desarrollo escritas por la Free Software Foundation. En
conjunto, el CSRG, la Free Software Foundation y los desarrolladores del
kernel de Linux han creado la plataforma desde la cual se lanzó el
movimiento del software de código fuente libre.

Es cada día más cercano el día en que el uso de código libre se
convierta en la forma preferida de desarrollar y comprar software para
usuarios y empresas de todo el mundo.