Historia de Unix y Linux: de 1969 hasta hoy

La historia de Unix y Linux, en resumen

La historia de Unix y Linux es una larga disputa sobre quién puede ser propietario del código fuente. Unix comenzó en Bell Labs en 1969. Linux comenzó en Helsinki en 1991 y no comparte código alguno con el código original de Unix. Lo que pasó de uno al otro fue un diseño y un conjunto de interfaces publicadas: archivos, procesos, tuberías y un shell que combina programas pequeños. Unix se extendió por las universidades en la década de 1970 porque un acuerdo antimonopolio de 1956 prohibió a AT&T (American Telephone and Telegraph) vender software, por lo que Bell Labs licenció el código fuente a bajo precio. Unix terminó estando presente en todas partes, aunque fuera propiedad de AT&T y de nadie externo, y las disputas por las licencias que siguieron determinaron qué sistema libre similar a Unix acabaría en el rack de servidores.

1969: un PDP-7 disponible y las ideas que perduraron

Bell Labs abandonó el proyecto Multics en 1969. Multics (multiplexed information and computing service) era un sistema grande de tiempo compartido desarrollado con MIT y General Electric, y los Labs decidieron que era demasiado grande para terminarlo. Ken Thompson conservó las ideas que le parecían útiles y descartó las demás. Escribió un sistema pequeño de tiempo compartido en un minicomputador PDP-7 desechado. Dennis Ritchie se unió a él. El nombre Unix era una broma a costa de Multics.

En 1970, el sistema se trasladó a un PDP-11 que los Labs compraron para los mecanógrafos del departamento de patentes, porque era más fácil financiar una herramienta de procesamiento de texto que un sistema operativo. Esa máquina tenía 24 KB de memoria central, dividida entre el sistema y los programas de usuario. Este accidente de financiación explica por qué el primer manual de Unix, fechado en noviembre de 1971, era un conjunto de documentos formateados, y también por qué todavía escribe man 5 crontab. Los números de sección de aquel manual son los números de sección del suyo.

Dos cambios hicieron permanente el diseño. Las tuberías llegaron en la Version 3, en 1973, porque Doug McIlroy llevaba años defendiendo que los programas debían poder conectarse de principio a fin, y Thompson añadió el operador | para que la salida de un programa se convirtiera en la entrada del siguiente. Después, la Version 4, publicada más tarde en 1973, se reescribió en C. Un sistema operativo escrito en un lenguaje portable puede trasladarse a hardware para el que no fue diseñado. Por eso Unix sobrevivió a todas las máquinas en las que comenzó.

Por qué se difundió Unix: AT&T no podía venderlo

Un decreto de consentimiento de 1956 resolvió un caso antimonopolio contra AT&T. AT&T conservó su monopolio telefónico, pero aceptó una limitación a cambio: debía mantenerse fuera de negocios distintos de las telecomunicaciones. El software era uno de esos negocios. Por eso, cuando las universidades solicitaron Unix, Bell Labs no podía venderlo como producto. Licenció el código fuente por una tarifa nominal, sin soporte ni garantía.

El efecto fue importante y no era lo que AT&T había previsto. Sixth Edition Unix, publicada en 1975, llegó a cientos de departamentos de informática con el código fuente completo. John Lions, de la University of New South Wales, imprimió ese código fuente del kernel con comentarios línea por línea y lo utilizó para enseñar. Una generación aprendió cómo funciona un sistema operativo leyendo uno real.

Después cambió la licencia. La licencia de Seventh Edition de 1979 prohibía usar el código fuente en las clases, por lo que el comentario de Lions circuló como fotocopias de fotocopias. Esta es la estructura de toda la historia. Unix estaba en todas partes y no era libre al mismo tiempo, así que cada mejora que alguien hacía mejoraba el código propietario de otra persona.

Berkeley: las partes de Unix que realmente escribe

Ken Thompson pasó el año académico 1975 a 1976 en la University of California, Berkeley, y dejó atrás un grupo de Unix muy activo. El Computer Systems Research Group (CSRG) de Berkeley distribuía cintas con mejoras locales, y esas cintas se convirtieron en BSD, Berkeley Software Distribution. Bill Joy escribió buena parte del trabajo inicial: 1BSD en 1978 y, después, 2BSD en 1979, que incluía el editor vi y el C shell.

El C shell es el origen de !! y !$. Bash heredó esa sintaxis. Por eso la expansión del historial de bash todavía sorprende a quienes escriben un signo de exclamación entre comillas dobles más de cuarenta años después.

DARPA (la Defense Advanced Research Projects Agency de Estados Unidos) pagó después a Berkeley para incorporar los nuevos protocolos de Internet a Unix. 4.2BSD, publicada en agosto de 1983, incluía TCP/IP (transmission control protocol over internet protocol) y la interfaz de programación de aplicaciones de sockets. Todos los servicios de red de su servidor siguen llamando a socket(), bind(), listen() y accept() en ese orden, porque Berkeley eligió esos nombres en 1983.

Un detalle determinó la década siguiente. Una cinta de BSD no era un sistema completo. Era un conjunto de adiciones al Unix de AT&T, y se necesitaba una licencia válida del código fuente de AT&T para ejecutarlo legalmente. Berkeley sustituyó las partes de AT&T por código propio durante varios años, archivo por archivo. La cuestión de si esa sustitución estaba realmente completa fue la que después llegó a los tribunales.

1984: la ruptura y, después, las guerras de Unix

Bell System se desmanteló el 1 de enero de 1984, y con él desapareció el decreto de consentimiento que había mantenido a AT&T fuera del negocio del software. AT&T ya podía vender Unix como producto, y lo hizo. Las licencias comerciales del código fuente se encarecieron, por lo que Unix dejó de ser el sistema barato que una universidad entregaba a sus estudiantes.

Los fabricantes ya lo habían bifurcado. Cada empresa de estaciones de trabajo distribuía su propio Unix en su propio hardware, así que a finales de la década de 1980 era necesario adaptar a la siguiente plataforma cualquier programa escrito para una de ellas. En 1988, el sector se dividió en dos grupos de estándares: la Open Software Foundation por un lado y Unix International por el otro. Durante años distribuyeron sistemas incompatibles mientras discutían cuál de sus Unix era el auténtico.

POSIX (portable operating system interface) surgió de ese desorden. IEEE 1003.1 se publicó en 1988 y dejó por escrito lo que debía hacer un sistema similar a Unix: las llamadas al sistema, el comportamiento del shell, las utilidades estándar y las interfaces de la biblioteca C. Esto es más importante de lo que parece, porque un estándar es una especificación y ninguna licencia lo cubre. Tres años después, un estudiante escribió un kernel basándose en esos documentos.

Minix y el vacío que dejó

Andrew Tanenbaum publicó Minix en 1987 como sistema didáctico para su libro sobre sistemas operativos. Minix era un sistema pequeño similar a Unix. El código fuente se incluía con el libro y funcionaba en los PC económicos que realmente tenían los estudiantes. Su lectura en un aula era legal, algo que ya no se aplicaba a Seventh Edition Unix.

Minix se mantuvo pequeño de forma deliberada porque debía poder explicarse en un libro. Tanenbaum rechazó parches que lo habrían convertido en un sistema apto para producción. Además, la licencia no era libre: había que comprar el libro y no se podía redistribuir una versión modificada de Minix por decisión propia. Por eso, en 1991, un estudiante podía estudiar un kernel funcional similar a Unix, pero no podía construir nada duradero sobre él.

GNU tenía todo excepto un kernel

Richard Stallman anunció el proyecto GNU en septiembre de 1983, con el objetivo de crear un sistema completo, libre y similar a Unix. En 1991, GNU había producido la mayoría de los componentes que rodean a un kernel: el compilador GCC, la biblioteca GNU C, las utilidades binarias y bash, el shell que Brian Fox escribió en 1989 y en el que el servidor todavía inicia la sesión. El kernel de GNU, Hurd, era el componente que seguía retrasándose.

La versión 2 de la GNU General Public License se publicó en junio de 1991. Su regla es breve. Puede usar el código y modificarlo, pero si distribuye el resultado, debe distribuir el código fuente con las mismas condiciones. Esa regla será el punto de inflexión de esta historia dentro de dos secciones.

Agosto de 1991: la publicación en comp.os.minix

El 25 de agosto de 1991, un estudiante de Helsinki publicó un mensaje en el grupo de Usenet comp.os.minix:

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.

La versión 0.01 se publicó en septiembre de 1991. No compartía código con Unix ni con Minix. Era un kernel nuevo para 386, desarrollado en una máquina con Minix, escrito según las interfaces POSIX y combinado con las herramientas de GNU que ya existían. En enero de 1992, Tanenbaum dijo a Torvalds que un kernel monolítico era un diseño obsoleto. Su argumento sobre el diseño era válido, pero Torvalds respondía a otra pregunta: qué funciona bien en el único ordenador barato que tiene un estudiante.

En febrero de 1992, la versión 0.12 se relicenció bajo la GPL. Desde entonces, Torvalds ha dicho que fue su mejor decisión. La licencia original de Linux prohibía cualquier intercambio de dinero, lo que habría impedido la aparición de los proveedores de CD y las empresas de soporte que llegaron después. La GPL permitía la actividad comercial y, al mismo tiempo, obligaba a incorporar cualquier cambio distribuido al mismo árbol compartido.

La demanda: de abril de 1992 a febrero de 1994

Berkeley publicó Networking Release 2 (Net/2) en junio de 1991: un sistema BSD casi completo, al que se habían retirado los archivos derivados de AT&T. Faltaban seis archivos del kernel. Bill y Lynne Jolitz escribieron sustitutos y publicaron 386BSD 0.0 en marzo de 1992, y después 386BSD 0.1 el 14 de julio de 1992. Ya existía un BSD gratuito, completo y maduro para 386, mientras Linux todavía era un kernel desarrollado como afición. Berkeley Software Design, Inc. (BSDi) vendía una compilación comercial con soporte, BSD/386, y la anunciaba con el número de teléfono 1-800-ITS-UNIX.

En abril de 1992, Unix System Laboratories (USL), la filial de AT&T que entonces era propietaria de Unix, demandó a BSDi ante un tribunal federal de Nueva Jersey por secretos comerciales y por la marca Unix. Posteriormente, la demanda se modificó para incluir a los Regents of the University of California. La Universidad presentó una contrademanda en California en 1993. Alegaba que AT&T había distribuido código de Berkeley dentro de System V sin la atribución que exigía su propia licencia.

El fundamento jurídico se desmoronó en 1993. El juez Dickinson Debevoise rechazó la solicitud de USL de una medida cautelar preliminar. Consideró que la reclamación de copyright de USL sobre el código antiguo de 32V probablemente no era válida, porque AT&T había distribuido ese código durante años sin avisos de copyright. Novell compró USL a AT&T a mediados de 1993, y la dirección de Novell quería poner fin al litigio. El caso se resolvió en febrero de 1994. De los aproximadamente 18,000 archivos de la distribución de Berkeley, se eliminaron tres y a unos setenta se les añadieron avisos de copyright de USL.

Berkeley publicó 4.4BSD-Lite en junio de 1994, y su situación jurídica quedó limpia. FreeBSD y NetBSD, ambos fundados en 1993 sobre el código cuestionado de Net/2, tuvieron que reconstruir sus sistemas sobre la nueva base. Este proceso ocupó la mayor parte del resto de 1994. Linux 1.0 se publicó en marzo de 1994, en plena reconstrucción.

¿Por qué Linux se quedó con los servidores y no BSD?

La demanda es la respuesta más conocida, y forma parte de la respuesta. Entre abril de 1992 y febrero de 1994, cualquiera que eligiera un Unix libre para un producto tenía que sopesar una reclamación activa de los abogados de AT&T frente a un kernel creado por un estudiante finlandés al que nadie podía demandar. Ese fue exactamente el periodo en que llegó la web y aparecieron las primeras distribuciones de Linux: Slackware en julio de 1993, Debian en agosto de 1993 y después Red Hat y SUSE. Red Hat convirtió esa ventaja inicial en el estándar comercial, y la trayectoria de Red Hat Linux a CentOS y después a Rocky y AlmaLinux explica por qué una distribución fundada en 1993 todavía determina qué se ejecuta en muchos servidores empresariales.

Otros cuatro factores fueron tan importantes como el caso judicial.

• Hardware. Linux se orientó al PC 386 convencional desde su primera línea de código, y ese fue el hardware que se abarató. El centro de gravedad de BSD estaba en VAX y las estaciones de trabajo, y el port para 386 fue un esfuerzo externo de dos personas.
• La licencia. La GPL obliga a una empresa que distribuya un kernel modificado a publicar sus cambios, por lo que el trabajo de los proveedores volvía al mismo árbol. La licencia BSD permite que una empresa mantenga sus cambios en privado, y las empresas lo hicieron.
• El modelo de desarrollo. Torvalds integraba rápidamente parches de personas desconocidas y publicaba versiones de forma constante. 386BSD publicaba con la suficiente lentitud como para que sus propios usuarios crearan dos forks en 1993, NetBSD y FreeBSD, y otro en OpenBSD en 1995.
• El impulso acumulado. Los desarrolladores van donde ya están los demás desarrolladores, y los controladores se escriben para el sistema que tiene más usuarios.

Hay que ser precisos con la cuestión técnica. BSD era en 1994 el sistema más acabado, con una base coherente, un historial documentado y código de red al que Linux tardó años en alcanzar. Nadie eligió Linux en 1994 porque fuera mejor. Lo eligieron porque estaba disponible, no tenía restricciones legales, funcionaba en el hardware que ya poseían y mejoraba cada semana.

Qué conservó BSD y dónde se ejecuta ahora

BSD continuó desarrollándose. Lo que perdió fue la posición predeterminada. La evidencia más clara está en su propia máquina: el proyecto OpenBSD creó OpenSSH en 1999, y actualmente es el servidor SSH de casi todos los sistemas Linux distribuidos, por lo que los hábitos de uso de claves SSH que conviene aprender son idénticos en ambas familias.

Netflix sirve vídeo desde dispositivos FreeBSD. Junos, el sistema operativo de los routers Juniper, utiliza FreeBSD internamente. El software del sistema de PlayStation desciende de FreeBSD. macOS e iOS de Apple incluyen código BSD en el kernel y en todo el userland. La licencia permisiva que hizo que BSD perdiera el árbol de servidores compartido introdujo código BSD en gran cantidad de hardware que nunca lo menciona.

Si va a elegir ahora, la cuestión es práctica, no histórica. Comparar Linux y FreeBSD como servidor se reduce a ZFS, jails, el árbol de ports y cuánto software de terceros da por supuesto que se ejecuta sobre Linux. FreeBSD 15 como servidor es un sistema actual y mantenido, no una pieza de museo. Y Linux frente a Windows Server es una cuestión independiente cuya respuesta depende de su pila de aplicaciones.

El diseño de 1969 que todavía usa hoy en un VPS

Cada uno de estos elementos es más antiguo que la mayoría de las personas que los utilizan.

• La tubería. who | wc -l cuenta los usuarios conectados porque Version 3 Unix permitía, en 1973, que la salida de un programa se convirtiera en la entrada de otro.
• Las secciones del manual. man 1 ls y man 5 crontab usan el esquema de numeración del manual de noviembre de 1971.
• La separación del sistema de archivos. /usr existe porque el disco raíz de aquel PDP-11 se llenó en 1971 y los desarrolladores trasladaron los archivos al segundo paquete de discos. Desde entonces, las distribuciones han deshecho la separación: ejecute ls -ld /bin en Ubuntu 24.04 o Debian 13 y obtendrá un enlace simbólico a usr/bin.
• Las llamadas de socket. Berkeley las escribió para 4.2BSD en 1983 y todos los daemons de red siguen usándolas.
• POSIX. Un script #!/bin/sh escrito conforme al estándar se ejecuta sin cambios en Linux, FreeBSD, macOS y Solaris porque el estándar es lo que todos ellos implementaron.

Una herencia no sobrevivió al cambio: la secuencia de arranque basada en scripts de shell que Linux heredó de System V ha desaparecido de casi todas las distribuciones, y el argumento que la sustituyó por systemd es el conflicto más reciente sobre cómo debe ser un sistema tipo Unix.

Cuando alquila un servidor privado virtual e inicia sesión, está escribiendo en una interfaz diseñada para una máquina con 24 KB de memoria y un departamento de patentes al que atender. Sobrevivió porque la interfaz se publicó, se debatió, se estandarizó y después fue implementada desde cero por personas a las que nunca se permitió ver el código original.

FAQ

¿Contiene Linux código original de Unix?

No. Linus Torvalds escribió el kernel desde cero a partir de 1991 y se orientó a las interfaces POSIX, no a ningún código fuente de AT&T. La herencia de Unix está en el diseño y en una interfaz publicada: archivos, procesos, tuberías y nombres de llamadas al sistema. Las herramientas GNU que rodean al kernel también se escribieron desde cero a partir de 1983. Esa independencia explica por qué el litigio de AT&T sobre el código de BSD nunca afectó a Linux.

¿Cuándo fue la demanda de AT&T contra BSD y acabó con BSD?

USL, la filial de AT&T propietaria de Unix, demandó a BSDi en abril de 1992 y posteriormente añadió a la University of California como parte demandada. En 1993, el juez rechazó una medida cautelar al considerar que probablemente no era válida la reclamación de copyright sobre el código antiguo de 32V. Novell compró USL a mediados de 1993 y resolvió el caso en febrero de 1994: se eliminaron tres archivos de unos 18,000 y se añadieron nuevos avisos de copyright a aproximadamente setenta. BSD no desapareció. Su adopción se frenó durante los dos años en los que el mundo estaba eligiendo un Unix libre.

¿Por qué Linux sustituyó a BSD en los servidores?

La seguridad jurídica fue una de las razones: durante 1992 y 1993, Linux no tenía ninguna demanda y BSD sí. Las otras fueron el 386 como plataforma objetivo desde el primer día, la GPL, que incorporaba los cambios de los proveedores al mismo árbol, y un proceso de integración suficientemente rápido para mantener el interés de los colaboradores mientras 386BSD se dividía en tres ramas. El mérito técnico no fue el factor decisivo, porque BSD era el sistema más completo en 1994.

¿Sigue mereciendo la pena usar FreeBSD?

Sí, por razones concretas: ZFS integrado en el sistema base, jails como modelo de aislamiento maduro, un sistema base desarrollado como una unidad coherente y documentación que se mantiene actualizada. El coste es el trabajo de compatibilidad, porque la mayoría del software de servidor de terceros, las herramientas de contenedores y el soporte de los proveedores presuponen Linux. Elija FreeBSD cuando sus capacidades de almacenamiento y red justifiquen ese coste, no por lealtad a la antigua línea de desarrollo.