Plan 9 de Bell Labs

Todos los programas que desean proporcionar servicios como archivos a otros programas utilizan un protocolo unificado llamado 9P. En comparación con otros sistemas, esto reduce la cantidad de interfaces de programación personalizadas . 9P es un protocolo genérico, independiente del medio y orientado a bytes que permite la transmisión de mensajes entre un servidor y un cliente. ^{[ 43 ]} El protocolo se utiliza para referirse a procesos, programas y datos, y comunicarse con ellos, incluyendo tanto la interfaz de usuario como la red. ^{[ 44 ]} Con el lanzamiento de la cuarta edición, se modificó y se renombró como 9P2000. ^{[ 26 ]}

A diferencia de la mayoría de los demás sistemas operativos, Plan 9 no proporciona interfaces de programación de aplicaciones especiales (como sockets Berkeley , recursos X o llamadas al sistema ioctl ) para acceder a los dispositivos. ^{[ 43 ]} En cambio, los controladores de dispositivos de Plan 9 implementan su interfaz de control como un sistema de archivos, de modo que se puede acceder al hardware mediante las operaciones de entrada/salida de archivos habituales (lectura y escritura) . En consecuencia, se puede compartir el dispositivo a través de la red montando el árbol de directorios correspondiente en la máquina de destino. ^{[ 17 ]}

El Plan 9 permite al usuario recopilar los archivos (llamados nombres ) de diferentes árboles de directorios en una única ubicación. El directorio resultante se comporta como la concatenación de los directorios subyacentes (el orden de concatenación se puede controlar); si los directorios constituyentes contienen archivos con el mismo nombre, un listado del directorio resultante ( ls o lc ) simplemente informará nombres duplicados. ^{[ 45 ]} La resolución de un único nombre de ruta se realiza de arriba hacia abajo: si los directorios top y bottom se unen en u con top primero, entonces u/nombre denota top/nombre si existe, bottom/nombre solo si existe y top/nombre no existe , y ningún archivo si ninguno existe. No se realiza una unión recursiva de subdirectorios, por lo que si top/subdir existe, los archivos en bottom/subdir no son accesibles a través de la unión. ^{[ 46 ]}

Se puede crear un directorio de unión utilizando una secuencia de comandos de enlace :

enlazar /arm/bin /bin bind -a /acme/bin/arm /bin bind -b /usr/alice/bin /bin 

En el ejemplo anterior, /arm/bin se monta en /bin , y el contenido de /arm/bin reemplaza el contenido anterior de /bin . El directorio bin de Acme se monta después de /bin , y el directorio bin personal de Alice se monta antes. Cuando se solicita un archivo de /bin , primero se busca en /usr/alice/bin , luego en /arm/bin y finalmente en /acme/bin/arm .

Los espacios de nombres de procesos separados suelen reemplazar la noción de una ruta de búsqueda en el shell. Una variable de entorno de ruta ( $path) todavía existe en el shell rc (el shell utilizado principalmente en Plan 9); sin embargo, la variable de entorno de ruta de rc convencionalmente solo contiene los /bindirectorios .y y se desaconseja modificar la variable, en su lugar, se deben agregar comandos adicionales vinculando varios directorios como un solo /bin. ^{[ 47 ] [ 39 ]} A diferencia de Plan 9, la variable de entorno de ruta de los shells de Unix debe configurarse para incluir los directorios adicionales cuyos archivos ejecutables deben agregarse como comandos.

Además, el núcleo puede mantener tablas de montaje separadas para cada proceso, ^{[ 37 ]} y así proporcionar a cada proceso su propio espacio de nombres del sistema de archivos . Los espacios de nombres de los procesos se pueden construir de forma independiente, y el usuario puede trabajar simultáneamente con programas que tienen espacios de nombres heterogéneos. ^{[ 40 ]} Los espacios de nombres se pueden usar para crear un entorno aislado similar a chroot , pero de una manera más segura. ^{[ 43 ]}

La arquitectura de directorio de unión de Plan 9 inspiró las implementaciones del sistema de archivos de unión de 4.4BSD y Linux , ^{[ 45 ]} aunque los desarrolladores de la función de montaje de unión de BSD consideraron que la fusión no recursiva de directorios en Plan 9 era "demasiado restrictiva para un uso general". ^{[ 46 ]}

Para reducir la complejidad de la gestión de codificaciones de caracteres , Plan 9 utiliza Unicode en todo el sistema. La implementación inicial de Unicode fue ISO/IEC 10646-1:1993 . Ken Thompson inventó UTF-8, que se convirtió en la codificación nativa de Plan 9. Todo el sistema se convirtió a uso general en 1992. ^{[ 49 ]} UTF-8 conserva la compatibilidad con versiones anteriores de cadenas terminadas en nulo tradicionales , lo que permite un procesamiento de información más fiable y el encadenamiento de datos de cadenas multilingües con tuberías Unix entre múltiples procesos. El uso de una única codificación UTF-8 con caracteres para todas las culturas y regiones elimina la necesidad de cambiar entre conjuntos de códigos. ^{[ 50 ]}

Aunque interesantes por sí solos, los conceptos de diseño del Plan 9 estaban pensados ​​para ser más útiles cuando se combinaban. Por ejemplo, para implementar un servidor de traducción de direcciones de red (NAT), se puede crear un directorio de unión, superponiendo el árbol de directorios /net del enrutador con su propio /net . De manera similar, se puede implementar una red privada virtual (VPN) superponiendo en un directorio de unión una jerarquía /net de una puerta de enlace remota , utilizando 9P seguro sobre Internet pública. Un directorio de unión con la jerarquía /net y filtros se puede utilizar para aislar una aplicación no confiable o para implementar un cortafuegos . ^{[ 43 ]} De la misma manera, se puede componer una red de computación distribuida con un directorio de unión de jerarquías /proc de hosts remotos, lo que permite interactuar con ellos como si fueran locales.

Cuando se utilizan conjuntamente, estas características permiten ensamblar un entorno de computación distribuida complejo mediante la reutilización del sistema de nombres jerárquico existente. ^{[ 8 ]}

A diferencia de Unix , Plan 9 fue diseñado teniendo en cuenta los gráficos. ^{[ 44 ]} Después del arranque, una terminal de Plan 9 ejecutará el sistema de ventanas rio , en el que el usuario puede crear nuevas ventanas que muestren rc . ^{[ 52 ]} Los programas gráficos invocados desde este shell lo reemplazan en su ventana.

El fontanero proporciona un mecanismo de comunicación entre procesos que permite la creación de hipervínculos en todo el sistema.

Sam y Acme son los editores de texto de Plan 9. ^{[ 53 ]}

Plan 9 es compatible con los sistemas de archivos Kfs , Paq , Cwfs , FAT y Fossil . Este último fue diseñado en Bell Labs específicamente para Plan 9 y ofrece almacenamiento de instantáneas. Puede utilizarse directamente con un disco duro o con Venti , un sistema de archivos de archivo y almacenamiento permanente de datos.

El paquete de distribución de Plan 9 incluye variantes de compilador y lenguajes de programación especiales, y proporciona un conjunto de bibliotecas adaptadas junto con un sistema de interfaz de usuario de ventanas específico para Plan 9. ^{[ 54 ]} La mayor parte del sistema está escrita en un dialecto de C ( ANSI C con algunas extensiones y otras características omitidas). Los compiladores para este lenguaje se crearon a medida teniendo en cuenta la portabilidad; según su autor, "compilan rápidamente, cargan lentamente y producen código objeto de calidad media". ^{[ 55 ]}

Un lenguaje de programación concurrente llamado Alef estaba disponible en las dos primeras ediciones, pero luego se eliminó por razones de mantenimiento y se reemplazó por una biblioteca de subprocesos para C. ^{[ 56 ] [ 57 ]}

Aunque se suponía que Plan 9 sería un desarrollo posterior de los conceptos de Unix, la compatibilidad con el software Unix preexistente nunca fue el objetivo del proyecto. Muchas utilidades de línea de comandos de Plan 9 comparten los nombres de sus contrapartes de Unix, pero funcionan de manera diferente. ^{[ 48 ]}

Plan 9 puede soportar aplicaciones POSIX y emular la interfaz de sockets de Berkeley a través del Entorno ANSI/POSIX (APE), que implementa una interfaz cercana a ANSI C y POSIX , con algunas extensiones comunes (las interfaces nativas de Plan 9 C no se ajustan a ninguno de los dos estándares). También incluye un intérprete de comandos compatible con POSIX. Los autores de APE afirman haberlo utilizado para portar el Sistema X Window (X11) a Plan 9, aunque no distribuyen X11 "porque soportarlo correctamente es un trabajo demasiado grande". ^{[ 58 ]} Algunos binarios de Linux se pueden usar con la ayuda de una aplicación "linuxemu" (emulador de Linux); sin embargo, todavía está en desarrollo. ^{[ 59 ]} A la inversa, la máquina virtual Vx32 permite que un kernel de Plan 9 ligeramente modificado se ejecute como un proceso de usuario en Linux, soportando programas de Plan 9 sin modificar. ^{[ 60 ]}

En 1991, los diseñadores de Plan 9 compararon su sistema con otros sistemas operativos de principios de los noventa en términos de tamaño, demostrando que el código fuente de una versión mínima ("funcional, aunque no muy útil") era menos de una quinta parte del tamaño de un microkernel Mach sin controladores de dispositivos (5899 o 4622 líneas de código para Plan 9, según la métrica, frente a 25530 líneas). El kernel completo constaba de 18000 líneas de código. ^{[ 39 ]} (Según un recuento de 2006, el kernel tenía entonces unas 150 000 líneas, pero esto se comparó con más de 4,8 millones en Linux . ^{[ 43 ]} ) 

Dentro de la comunidad de investigación de sistemas operativos, así como en el mundo comercial de Unix, se realizaron otros intentos para lograr la computación distribuida y el acceso remoto al sistema de archivos simultáneamente con el esfuerzo de diseño de Plan 9. Estos incluyeron el Sistema de Archivos de Red y la arquitectura vnode asociada desarrollada en Sun Microsystems , y desviaciones más radicales del modelo Unix, como el sistema operativo Sprite de UC Berkeley . El desarrollador de Sprite, Brent Welch, señala que la arquitectura vnode de SunOS es limitada en comparación con las capacidades de Plan 9, ya que no admite el acceso remoto a dispositivos ni la comunicación remota entre procesos de forma limpia, aunque podría haberlo hecho si los sockets de dominio UNIX preexistentes (que "se pueden usar esencialmente para nombrar servidores de nivel de usuario") se hubieran integrado con la arquitectura vnode. ^{[ 41 ]}

Una crítica al diseño de Plan 9, donde "todo es un archivo" y la comunicación mediante mensajes de texto, señaló las limitaciones de este paradigma en comparación con las interfaces tipadas del sistema operativo orientado a objetos de Sun , Spring :

El Plan 9 restringe todo para que parezca un archivo. En la mayoría de los casos, el tipo de interfaz real comprende el protocolo de mensajes que deben escribirse y leerse desde un descriptor de archivo. Esto es difícil de especificar y documentar, y prohíbe cualquier verificación automática de tipos , excepto para errores de archivo en tiempo de ejecución. (...) [Un] nombre de ruta relativo al contexto raíz implícito de un proceso es la única forma de nombrar un servicio. Vincular un nombre a un objeto solo puede hacerse dando un nombre existente para el objeto, en el mismo contexto que el nuevo nombre. Por lo tanto, las referencias de interfaz simplemente no pueden pasarse entre procesos, y mucho menos a través de redes. En cambio, la comunicación tiene que basarse en convenciones, que son propensas a errores y no son escalables.

Una comparación retrospectiva posterior de Plan 9, Sprite y un tercer sistema operativo de investigación distribuida contemporáneo, Amoeba , encontró que

Los entornos que construyen [Amoeba y Sprite] están estrechamente integrados en el sistema operativo, lo que dificulta la comunicación con servicios externos. Estos sistemas sufren las consecuencias de su radical alejamiento del modelo UNIX, lo que también dificulta la portabilidad del software ya existente a la plataforma (...). La falta de desarrolladores, la escasa compatibilidad con hardware y la reducida base de usuarios, incluso en comparación con Plan 9, también han ralentizado significativamente la adopción de estos sistemas (...). En retrospectiva, Plan 9 fue el único sistema operativo distribuido de investigación de aquella época que logró atraer desarrolladores y ser utilizado en proyectos comerciales durante el tiempo suficiente como para garantizar su supervivencia hasta nuestros días.

Plan 9 demostró que un concepto integral de Unix —que cada interfaz del sistema podía representarse como un conjunto de archivos— podía implementarse con éxito en un sistema distribuido moderno. ^{[ 52 ]} Algunas características de Plan 9, como la codificación de caracteres UTF-8 de Unicode, se han implementado en otros sistemas operativos. Los sistemas operativos tipo Unix, como Linux, han implementado 9P2000, el protocolo de Plan 9 para acceder a archivos remotos, y han adoptado características de rfork , el mecanismo de creación de procesos de Plan 9. ^{[ 64 ]} Además, en Plan 9 from User Space , varias de las aplicaciones y herramientas de Plan 9, incluyendo acme y su predecesor sam , se han portado a sistemas Unix y Linux y han alcanzado cierto nivel de popularidad. Varios proyectos buscan reemplazar los programas del sistema operativo GNU que rodean el núcleo de Linux con los programas del sistema operativo Plan 9. ^{[ 65 ] [ 66 ]} El gestor de ventanas 9wm se inspiró en 8½ , el sistema de ventanas anterior de Plan 9; ^{[ 67 ]} wmii también está fuertemente influenciado por Plan 9. ^{[ 63 ]} En la investigación en ciencias de la computación, Plan 9 se ha utilizado como plataforma de computación en malla ^{[ 68 ] [ 62 ]} y como vehículo para la investigación en computación ubicua sin middleware . ^{[ 69 ]} En el comercio, Plan 9 es la base de los sistemas de almacenamiento Coraid . Sin embargo, Plan 9 nunca se ha acercado a Unix en popularidad y ha sido principalmente una herramienta de investigación:

Parece que el Plan 9 fracasó simplemente porque no logró ser una mejora lo suficientemente convincente para Unix como para desbancar a su predecesor. Comparado con el Plan 9, Unix presenta fallos y evidentes deficiencias, pero cumple su función lo suficientemente bien como para mantener su posición. Esto deja una lección para los arquitectos de sistemas ambiciosos: el enemigo más peligroso de una mejor solución es un código base existente que simplemente cumple con lo mínimo.

Otros factores que contribuyeron a la baja adopción del Plan 9 incluyen la falta de respaldo comercial, el bajo número de aplicaciones para usuarios finales y la falta de controladores de dispositivos . ^{[ 52 ] [ 53 ]}

Los defensores y desarrolladores de Plan 9 afirman que los problemas que obstaculizaban su adopción se han resuelto, que se han cumplido sus objetivos originales como sistema distribuido, entorno de desarrollo y plataforma de investigación, y que goza de una popularidad moderada pero creciente. Inferno , gracias a sus capacidades de alojamiento, ha servido como vehículo para llevar las tecnologías de Plan 9 a otros sistemas como parte alojada de redes de computación heterogéneas. ^{[ 70 ] [ 71 ] [ 72 ]}

Varios proyectos trabajan para extender Plan 9, incluyendo 9atom y 9front. Estas bifurcaciones amplían Plan 9 con controladores de hardware y software adicionales , incluyendo una versión mejorada del sistema de correo electrónico Upas , el compilador Go , soporte para el sistema de control de versiones Mercurial (y ahora también una implementación de git), y otros programas. ^{[ 19 ] [ 73 ]} Plan 9 fue portado a la computadora de placa única Raspberry Pi . ^{[ 74 ] [ 75 ]} El proyecto Harvey, descontinuado, intenta reemplazar el compilador C personalizado de Plan 9 con GCC , para aprovechar herramientas de desarrollo modernas como GitHub y Coverity , y acelerar el desarrollo. ^{[ 76 ]}

Desde la versión 1903 de Windows 10 , el Subsistema de Windows para Linux implementa el Protocolo de sistema de archivos Plan 9 como servidor y el sistema operativo Windows anfitrión actúa como cliente. ^{[ 77 ]}