Historia de Unix y Linux: evolución y diferencias

Breve historia de Unix y Linux

La historia de Unix y Linux es una larga disputa sobre quién tiene derecho a poseer el código fuente. Unix comenzó en Bell Labs en 1969. Linux comenzó en Helsinki en 1991 y no comparte nada de aquel código original. Lo que se transmitió entre ambos fue un diseño y un conjunto de interfaces publicadas: archivos, procesos, tuberías (pipes) y un shell que conecta programas pequeños entre sí. Unix se difundió por las universidades en la década de 1970 porque un acuerdo antimonopolio de 1956 prohibía a AT&T (American Telephone and Telegraph) vender software, por lo que Bell Labs licenció el código fuente a bajo costo. Unix terminó en todas partes sin pertenecer a nadie fuera de AT&T, y las disputas legales sobre licencias que siguieron determinaron qué sistema libre de tipo Unix terminó en su rack de servidores.

1969: un PDP-7 de repuesto y las ideas que perduraron

Bell Labs se retiró del proyecto Multics en 1969. Multics (multiplexed information and computing service) era un sistema de tiempo compartido de gran escala desarrollado junto con el MIT y General Electric, y los laboratorios decidieron que era demasiado extenso para finalizarlo. Ken Thompson conservó las ideas que le interesaban y descartó el resto, escribiendo un pequeño sistema de tiempo compartido en un minicomputador PDP-7 desechado. Dennis Ritchie se unió a él. El nombre Unix fue una broma a costa de Multics.

En 1970, el sistema se trasladó a un PDP-11 que los laboratorios compraron para los mecanógrafos del departamento de patentes, ya que era más fácil financiar una herramienta de procesamiento de texto que un sistema operativo. Esa máquina contaba con 24 KB de memoria de núcleo, dividida entre el sistema y los programas de usuario. Este accidente en la financiación es la razón por la cual el primer manual de Unix, fechado en noviembre de 1971, era un conjunto de documentos formateados, y es el motivo por el que todavía escribe man 5 crontab. Los números de sección de aquel manual son los mismos que utiliza el suyo.

Dos cambios hicieron que el diseño fuera permanente. Las tuberías (pipes) llegaron en la Version 3 en 1973, debido a que Doug McIlroy había argumentado durante años que debería ser posible conectar programas extremo a extremo, y Thompson añadió el operador | para que la salida de un programa se convirtiera en la entrada del siguiente. Posteriormente, la Version 4, a finales de 1973, fue reescrita en C. Un sistema operativo escrito en un lenguaje portable puede trasladarse a hardware para el cual no fue diseñado originalmente, razón por la cual Unix sobrevivió a todas las máquinas en las que comenzó.

Por qué se extendió Unix: AT&T no tenía permitido venderlo

Un decreto de consentimiento de 1956 resolvió un caso antimonopolio contra AT&T. AT&T mantuvo su monopolio telefónico y aceptó un límite a cambio: permanecería fuera de negocios distintos a las telecomunicaciones. El software era uno de esos negocios. Por lo tanto, cuando las universidades solicitaron Unix, Bell Labs no pudo venderlo como producto. Licenció el código fuente por una tarifa nominal, sin soporte y sin garantía.

El efecto fue grande y no fue lo que AT&T planeó. La Sixth Edition de Unix, lanzada en 1975, llegó a cientos de departamentos de informática con el código fuente completo. John Lions, de la Universidad de Nueva Gales del Sur, imprimió ese código fuente del kernel con comentarios línea por línea y enseñó a partir de él. Una generación aprendió cómo funciona un sistema operativo leyendo uno real.

Luego, la licencia cambió. La licencia de la Seventh Edition en 1979 prohibió el uso del código fuente en clases, por lo que los comentarios de Lions circularon como fotocopias de fotocopias. Esta es la forma de toda la historia. Unix estaba en todas partes y no era libre al mismo tiempo, por lo que cada mejora que alguien realizaba era una mejora al código propietario de otra persona.

Berkeley: las partes de Unix que realmente escribe

Ken Thompson pasó el año académico de 1975 a 1976 en la Universidad de California, Berkeley, y dejó tras de 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, la Berkeley Software Distribution. Bill Joy escribió gran parte del trabajo inicial: 1BSD en 1978, seguido de 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, razón por la cual la expansión del historial de bash sigue sorprendiendo a quienes escriben un signo de exclamación dentro de comillas dobles cuarenta y tantos años después.

DARPA (la Agencia de Proyectos de Investigación Avanzados de Defensa de EE. UU.) pagó entonces a Berkeley para integrar los nuevos protocolos de internet en Unix. 4.2BSD, lanzado en agosto de 1983, incluía TCP/IP (protocolo de control de transmisión sobre protocolo de internet) y la interfaz de programación de aplicaciones de sockets. Todo servicio de red en su servidor sigue llamando a socket(), bind(), listen() y accept() en ese orden, porque Berkeley eligió esos nombres en 1983.

Un detalle decidió la década siguiente. Una cinta BSD no era un sistema completo. Era un conjunto de adiciones al Unix de AT&T, y se necesitaba una licencia de código fuente válida de AT&T para ejecutarlo legalmente. Berkeley reemplazó las partes de AT&T con su propio código a lo largo de varios años, archivo por archivo. Si ese reemplazo fue realmente completo es la cuestión que más tarde llegó a los tribunales.

1984: la ruptura y las guerras de Unix

El Bell System se disolvió el 1 de enero de 1984 y, con ello, desapareció el decreto de consentimiento que impedía a AT&T participar en el negocio del software. AT&T pudo entonces comercializar Unix como producto, y así lo hizo. Las licencias de código fuente comerciales se encarecieron, por lo que Unix dejó de ser el recurso económico que una universidad entregaba a sus estudiantes.

Los proveedores ya habían creado bifurcaciones (forks). Cada empresa de estaciones de trabajo distribuía su propio Unix para su propio hardware, de modo que, a finales de la década de 1980, un programa escrito para un sistema requería ser portado al siguiente. La industria se dividió en dos bandos estandarizados en 1988: la Open Software Foundation por un lado y Unix International por el otro. Pasaron años distribuyendo sistemas incompatibles mientras discutían sobre cuál era el Unix auténtico.

POSIX (interfaz de sistema operativo portable) surgió de ese caos. El estándar IEEE 1003.1 se publicó en 1988 y definió lo que un sistema tipo Unix debe hacer: las llamadas al sistema, el comportamiento del shell, las utilidades estándar y las interfaces de la biblioteca de C. Esto es más importante de lo que parece, ya que un estándar es una especificación y ninguna licencia lo restringe. Tres años después, un estudiante escribió un kernel basándose en esos documentos.

Minix y el vacío que dejó

Andrew Tanenbaum lanzó Minix en 1987 como el sistema de enseñanza para su libro de texto sobre sistemas operativos. Minix era un sistema pequeño de tipo Unix, el código fuente se incluía con el libro y funcionaba en los PC económicos que los estudiantes realmente poseían. Era legal leerlo en un aula, algo que el Unix de Séptima Edición ya no permitía.

Minix se mantuvo pequeño a propósito, ya que debía ser explicable en un libro, y Tanenbaum rechazó parches que lo habrían convertido en un sistema de producción. La licencia tampoco era libre: comprabas el libro y redistribuir tu Minix modificado no era una decisión que pudieras tomar. Por lo tanto, en 1991, un estudiante podía leer un kernel funcional de tipo 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 de tipo Unix libre. Para 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 el shell en el que su servidor todavía le inicia sesión. El kernel de GNU, Hurd, era la pieza que seguía retrasándose.

La GNU General Public License versión 2 se publicó en junio de 1991. Su regla es breve. Usted puede usar el código y modificarlo, y si distribuye el resultado, debe distribuir el código fuente bajo los mismos términos. Esa regla se convierte en el eje 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 en Helsinki publicó 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 lanzó en septiembre de 1991. No compartía código ni con Unix ni con Minix. Era un kernel nuevo para el 386, desarrollado en una máquina con Minix, escrito siguiendo las interfaces POSIX y combinado con las herramientas GNU que ya existían. Tanenbaum le dijo a Torvalds en enero de 1992 que un kernel monolítico era un diseño obsoleto. Tenía un argumento válido sobre el diseño, pero Torvalds respondía a una pregunta distinta: qué funciona bien en el único ordenador barato que posee un estudiante.

En febrero de 1992, la versión 0.12 se relicenció bajo la GPL. Desde entonces, Torvalds ha calificado esa decisión como la mejor que tomó. La licencia original de Linux prohibía cualquier intercambio de dinero, lo cual habría bloqueado a los vendedores de CD y a las empresas de soporte que surgieron después. La GPL permitió el comercio a la vez que obligaba a que cada cambio distribuido volviera 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: era un sistema BSD casi completo, al que se le habían retirado los archivos derivados de AT&T. Faltaban seis archivos del kernel. Bill y Lynne Jolitz escribieron los reemplazos y publicaron 386BSD 0.0 en marzo de 1992, y posteriormente 386BSD 0.1 el 14 de julio de 1992. Ya existía un BSD libre, completo y maduro para 386, justo en el momento en que Linux aún era un kernel de aficionados. Berkeley Software Design, Inc. (BSDi) vendió una versión comercial con soporte, BSD/386, y la promocionó 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 poseía Unix, demandó a BSDi en un tribunal federal de Nueva Jersey por secretos comerciales y por la marca registrada Unix. La demanda se modificó más tarde para incluir a los Regents of the University of California. La Universidad presentó una contrademanda en California en 1993, argumentando que AT&T había distribuido código de Berkeley dentro de System V sin el reconocimiento que su propia licencia exigía.

El núcleo legal se desmoronó en 1993. El juez Dickinson Debevoise denegó a USL una medida cautelar, bajo el criterio de que la reclamación de derechos de autor de USL sobre el código antiguo 32V era probablemente inválida, ya que 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 terminar con el conflicto. El caso se resolvió en febrero de 1994. De los aproximadamente 18,000 archivos en la distribución de Berkeley, se eliminaron tres y cerca de setenta recibieron avisos de copyright de USL.

Berkeley publicó 4.4BSD-Lite en junio de 1994 y quedó legalmente limpio. FreeBSD y NetBSD, ambos fundados en 1993 sobre el código disputado de Net/2, tuvieron entonces que reconstruir sus sistemas sobre la nueva base, lo que ocupó la mayor parte del resto de 1994. Linux 1.0 se publicó en marzo de 1994, en medio de esa reconstrucción.

¿Por qué Linux conquistó el mercado de servidores y no BSD?

La demanda judicial es la respuesta popular, y es parte de la explicación. Entre abril de 1992 y febrero de 1994, cualquiera que eligiera un Unix libre para un producto debía sopesar una reclamación legal activa de los abogados de AT&T frente a un kernel de un estudiante finlandés sobre el cual nadie podía demandar. Ese fue el periodo exacto en el que llegó la web y aparecieron las primeras distribuciones de Linux: Slackware en julio de 1993, Debian en agosto de 1993, y luego Red Hat y SUSE.

Otros cuatro factores fueron tan importantes como el caso judicial.

• Hardware. Linux se orientó al PC 386 comercial desde su primera línea de código, y ese es el hardware que se volvió barato. El centro de gravedad de BSD era el VAX y la estación de trabajo, y la adaptación al 386 fue un esfuerzo externo realizado por dos personas.
• La licencia. La GPL exige que una empresa que distribuya un kernel modificado publique sus cambios, por lo que el trabajo de los proveedores regresaba a un único árbol. La licencia BSD permite a una empresa mantener sus cambios en privado, y las empresas efectivamente los mantuvieron así.
• El modelo de desarrollo. Torvalds integraba parches de desconocidos rápidamente y lanzaba versiones constantemente. 386BSD se lanzaba con la lentitud suficiente como para que sus propios usuarios lo bifurcaran dos veces en 1993, en NetBSD y FreeBSD, y de nuevo en OpenBSD en 1995.
• Impulso. Los desarrolladores van a donde ya están los demás desarrolladores, y los controladores se escriben para el sistema que tiene más usuarios.

Seamos honestos sobre la cuestión técnica. BSD en 1994 era el sistema más acabado, con una base coherente, una historia documentada y un código de red que a Linux le llevó años igualar. Nadie eligió Linux en 1994 porque fuera mejor. La gente lo eligió porque estaba disponible, sin trabas legales, funcionaba en el hardware que ya poseían y mejoraba cada semana.

Lo que BSD conservó y dónde se ejecuta ahora

BSD continuó su camino. Lo que perdió fue su posición predominante. La prueba más clara se encuentra en su propia máquina: el proyecto OpenBSD escribió OpenSSH en 1999, y es el servidor SSH en casi todos los sistemas Linux que se distribuyen hoy en día, razón por la cual los hábitos de claves SSH que vale la pena aprender son idénticos en ambas familias.

Netflix sirve vídeo desde dispositivos FreeBSD. Junos, el sistema operativo de los routers Juniper, tiene FreeBSD en su núcleo. El software del sistema de PlayStation desciende de FreeBSD. macOS e iOS de Apple contienen código BSD en el kernel y en todo el espacio de usuario. La licencia permisiva que le costó a BSD el árbol de servidores compartido permitió que el código BSD terminara en una gran cantidad de hardware que nunca lo menciona.

Si usted está eligiendo hoy, la cuestión es práctica más que histórica. Comparar Linux y FreeBSD como servidor se reduce a ZFS, jails, el árbol de ports y cuánto software de terceros asume que Linux está debajo. 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 distinta cuya respuesta depende de su pila de aplicaciones.

El diseño de 1969 que utiliza 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 (pipe). who | wc -l cuenta los usuarios conectados porque la Versión 3 de Unix en 1973 permitió que la salida de un programa se convirtiera en la entrada de otro.
• Las secciones del manual. man 1 ls y man 5 crontab utilizan el esquema de numeración del manual de noviembre de 1971.
• La división del sistema de archivos. /usr existe porque el disco raíz de aquel PDP-11 se llenó en 1971 y los desarrolladores movieron archivos a un segundo paquete de disco. Las distribuciones han revertido esta división: ejecute ls -ld /bin en Ubuntu 24.04 o Debian 13 y obtendrá un enlace simbólico a usr/bin.
• Las llamadas a sockets. Berkeley las escribió para 4.2BSD en 1983, y cada demonio de red las sigue utilizando.
• POSIX. Un script #!/bin/sh escrito bajo este estándar se ejecuta sin cambios en Linux, FreeBSD, macOS y Solaris, porque el estándar es lo que todos ellos implementaron.

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 cual servir. Sobrevivió porque la interfaz fue publicada, debatida, estandarizada y luego reimplementada desde cero por personas a las que nunca se les 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, apuntando a las interfaces POSIX en lugar de a cualquier fuente de AT&T. La herencia de Unix es un diseño y una interfaz publicada: archivos, procesos, tuberías y los nombres de las llamadas al sistema. Las herramientas GNU que rodean al kernel también fueron escritas desde cero, comenzando en 1983. Esa independencia es la razón por la que el litigio de AT&T sobre el código BSD nunca afectó a Linux en absoluto.

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

USL, la subsidiaria de AT&T que poseía Unix, demandó a BSDi en abril de 1992 y más tarde añadió a la University of California como demandada. En 1993, el juez rechazó una medida cautelar, sosteniendo que la reclamación de derechos de autor sobre el código 32V más antiguo era probablemente inválida. Novell compró USL a mediados de 1993 y resolvió el caso en febrero de 1994, eliminando tres archivos de un total de unos 18.000 y añadiendo nuevos avisos de derechos de autor a aproximadamente setenta. No acabó con BSD. Congeló la adopción de BSD durante los dos años en los que el mundo estaba eligiendo un Unix libre.

¿Por qué Linux se impuso en los servidores en lugar de BSD?

La seguridad jurídica fue una razón: durante 1992 y 1993, Linux no tuvo ninguna demanda y BSD sí. Las otras razones fueron el 386 como objetivo desde el primer día, la GPL que obligaba a devolver los cambios de los proveedores a un único árbol, y un proceso de fusión lo suficientemente rápido como para mantener el interés de los colaboradores mientras 386BSD se bifurcaba en tres direcciones. El mérito técnico no fue el factor decisivo, ya que BSD era el sistema más acabado en 1994.

¿Vale la pena ejecutar FreeBSD hoy en día?

Sí, y por razones concretas: ZFS integrado en el sistema base, jails como un modelo de aislamiento maduro, un sistema base desarrollado como una unidad coherente y una documentación que se mantiene precisa. El coste es el trabajo de compatibilidad, ya que la mayoría del software de servidor de terceros, las herramientas de contenedores y el soporte de proveedores asumen Linux. Elija FreeBSD cuando su trabajo de almacenamiento y redes justifique ese coste, en lugar de por lealtad al linaje más antiguo.