💾 Archived View for texto-plano.xyz › peron › articulos › unix_berkeley.gmi captured on 2023-11-14 at 08:05:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-03-20)
-=-=-=-=-=-=-
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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á.
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.
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.
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.
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:
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.
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
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
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.
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.
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.