Multics

Multics (Multiplexed Information and Computing Service) fue uno de los primeros sistemas operativos de tiempo compartido y tuvo una gran influencia en el desarrollo de los posteriores sistemas operativos.

Los planes iniciales y el desarrollo de Multics comenzaron en 1964. Originalmente, era un proyecto cooperativo liderado por el científico estadounidense Fernando J. Corbató del MIT, con la participación de la corporación General Electric y los laboratorios Bell. Los laboratorios Bell abandonaron el proyecto en el año 1969, y en 1970 el negocio de computación de General Electric, incluyendo Multics, fue adquirido por Honeywell.

Multics fue concebido como un producto comercial por General Electric, y alcanzó este logro para Honeywell, pero no tuvo un gran éxito. Sin embargo, tuvo un gran impacto en el campo de la computación gracias a sus muchas ideas nuevas y valiosas. Aunque en su época recibió muchas críticas [1], la historia ha demostrado que eran infundadas.

Un gran número de características intentaban proporcionar alta disponibilidad, de manera que el servicio de computación igualase a los servicios de telefonía y a la red eléctrica. Para alcanzar este logro, se utilizó una estructura modular tanto en el software como en el hardware, y el sistema podía crecer simplemente añadiendo más recursos - poder de computación, memoria principal, almacenamiento de disco, etc. Listas de control de acceso sobre cada archivo proporcionaban un método flexible para compartir información, además de la privacidad requerida. Contenía diferentes mecanismos estándar para permitir a los ingenieros analizar el rendimiento del sistema, además de varios mecanismos para la optimización del rendimiento.

Multics fue uno de los primeros sistemas operativos en el cual fue implementado un único nivel de almacenamiento para el acceso a los datos, desechando la clara distinción entre los archivos (llamados segmentos en Multics) y los procesos en memoria.

Hasta entonces, la memoria de un proceso consistía solamente en segmentos que estaban asignados en su espacio de direcciones; para leer o escribir en ellos, el proceso simplemente utilizaba instrucciones normales de la CPU, y el sistema operativo tenía cuidado de asegurarse que todas las modificaciones fueran guardadas en disco.

En la terminología del estándar POSIX, era como si cada archivo fuese asignado; sin embargo, en Multics no existía el concepto de memoria de proceso, separado del de la memoria utilizada para mantener mapeados sobre los archivos, como hace Unix. Toda la memoria del sistema formaba parte de algún segmento, que aparecía en el sistema de archivos; incluida la memoria temporal del proceso, la pila del núcleo, etc. Esta era una desventaja práctica, dadas las particularidades de la arquitectura del hardware de las máquinas en las que se ejecutaba, y no del concepto básico, era que el tamaño de los segmentos estaba limitado a 256K palabras de 36 bits, aproximadamente igual a 1MB actual, y por lo tanto se debía utilizar código extra para trabajar con archivos mayores que esto, llamados archivos multisegmento. En los días anteriores a las bases de datos grandes, y los posteriores gráficos de mapas de bits de gran tamaño, no era frecuente encontrarse con esta limitación.

Otro aporte de Multics, fue el concepto de enlace dinámico, mediante el cual un proceso en ejecución puede solicitar que otros segmentos se añadan a su espacio de direcciones. Estos segmentos pueden incluir código que puede ser ejecutado. Con esta característica disponible, las aplicaciones automáticamente utilizaban la última versión de cualquier rutina externa que llamaban, estas rutinas estaban en otros segmentos, que se enlazaban dinámicamente sólo cuando un proceso intentaba ejecutarlas. Como diferentes procesos, pertenecientes a diferentes usuarios, podían utilizar diferentes reglas de búsqueda, diferentes usuarios podían automáticamente acabar utilizando diferentes versiones de las rutinas externas.

Igualmente importante, con la configuración adecuada de las características de seguridad de Multics, fue que el código en el otro segmento podía ganar acceso a las estructuras de datos mantenidas en un proceso diferente.

De este modo, para interactuar con una aplicación ejecutándose en parte como un demonio (en otro proceso) un proceso de usuario simplemente realiza una llamada normal a un procedimiento, hacia un segmento de código con el que se enlazó dinámicamente (un segmento de código que implementa alguna operación asociada con este demonio). El código en este segmento puede entonces modificar los datos mantenidos y utilizados por el demonio. Cuando la acción necesaria para comenzar la solicitud se completa, una simple instrucción de retorno del proceso retorna el control del proceso de usuario al código del usuario.

Estas dos ideas, se utilizan todavía en la mayoría de los sistemas operativos, independientemente del rápido y enorme avance realizado en el campo de la computación desde la década de 1960.

Multics también soportaba una reconfiguración en línea muy agresiva; las CPUs, los bancos de memoria, unidades de disco, etc. podían ser añadidas y quitadas mientras el sistema continuaba funcionando; entrando en servicio, o eliminándose cuando fuera necesario. Era una práctica común en el sistema del MIT, donde se realizó la mayoría de los desarrollos de software iniciales, dividir el sistema; que era un sistema multiprocesador; en dos sistemas separados, al eliminiar suficiente componentes para formar un segundo sistema, dejando el resto todavía ejecutando la los usuarios que tenían una sesión abierta. Las comprobaciones sobre el software desarrollado podían realizarse en la segunda máquina; cuando las pruebas concluían, los componentes del segundo sistema se añadían de nuevo en el sistema principal, sin tener que apagarlo en ningún momento. Como se soportaban varias CPUs, fue uno de los primeros sistemas multiprocesador.

Multics también fue notable por su innovador énfasis en su diseño para obtener seguridad informática, y fue posiblemente el primer sistema operativo diseñado como un sistema seguro desde su inicio. Independientemente de esto, las primeras versiones de Multics se mostraron vulnerables, no una vez, sino de forma repetida.

Esto condujo a más trabajo para mejorar la seguridad que trazó las técnicas de seguridad modernas, e hizo los sistemas mucho más seguros; al adoptarse el hardware de segunda generación, con soporte hardware para los anillos de seguridad (un refinamiento multinivel del concepto de modo maestro), las intrusiones se convirtieron en algo muy extraño.

Además de haber sido el primer sistema operativo que proporcionó un sistema de archivos jerárquico, los nombres de los archivos casi podían tener una longitud y sintaxis arbitraria; dado un archivo o directorio este podía tener varios nombres (típicamente uno largo y otro corto); también se soportaban enlaces simbólicos entre directorios.

Fue el primero en utilizar el concepto, hoy convertido en característica estándar, de tener una pila por proceso en el núcleo, con una pila separada para cada anillo de seguridad. También fue uno de los primeros sistemas escritos en un lenguaje de alto nivel denominado PL/1, aunque el sistema Burroughs B5000, que utilizaba ALGOL precedió a Multics.

Multics se desarrolló inicialmente para el computador central de General Electric GE-645, un sistema de 36 bits; después fue soportado por la serie de máquinas Honeywell 6180.

El personal de los Laboratorios Bell abandonó el proyecto en 1969. Algunas de las personas que habían trabajado en su desarrollo se dedicaron a crear el sistema operativo UNIX. Aunque de un modo superficial, UNIX muestra la influencia de Multics en muchas áreas, incluido el nombre de los comandos. Sin embargo, la filosofía de diseño fue muy diferente, centrándose en mantener el sistema tan pequeño y simple como fuese posible, y de este modo corrigiendo lo que se veía como una deficiencia de Multics. El nombre "Unix" (originalmente "Unics", por "UNIplexed information and Computing Service" en vez de "MULTIplexed Computer and Information Service") es un hack de "Multics". Se rumorea que la U de UNIX significia "Uniplexado" en oposición al concepto "Multiplexado" de Multics, resaltando la intención de los diseñadores de rechazar la complejidad de Multics en favor de una aproximación práctica más directa.

La empresa estadounidense Honeywell compró la división de computación de General Electric, lanzó una mejor base de hardware, y continuó el desarrollo del sistema hasta 1985. Se realizaron unas 80 instalaciones por valor de varios millones de dólares, en universidades, industrias, y administraciones. El sistema universitario de Francia contó con varias instalaciones en los inicios de la década de 1980. Después Honeywell dejó de soportar Multics, y entonces los usuarios migraron a otros sistemas, incluyendo otras distribuciones de UNIX. La última máquina en usar Multics fue apagada el 31 de octubre de 2000, en el Ministerio de Defensa de Canadá.

En la actualidad, el código fuente de Multics ha sido liberado por el MIT y se puede descargar desde su página.^[1]​

Es más que sorprendente descubrir que el núcleo de este sistema operativo para computadoras centrales multiprocesador, que fue criticada en sus días iniciales por su tamaño y complejidad, ocupaba 135 kB de código. El primer GE-645 del MIT tuvo 512K palabras de memoria (2 MB), de manera que el núcleo sólo utilizaba una pequeña porción de la memoria principal de Multics.

Medido de otra forma, el sistema completo, incluyendo no sólo el sistema operativo, sino también el complejo compilador de PL/I, los comandos de usuario, y las bibliotecas de subrutinas, contenía aproximadamente 1500 módulos de código fuente con una longitud media, cada uno, de unas 200 líneas de código fuente, y se compilaban para producir aproximadamente 4,5 MB de código de procedimientos, que aunque hoy parezca pequeño, era muy grande para los estándares de la época.

Los compiladores de Multics generalmente optimizaban la densidad de código antes que la velocidad de ejecución, por ejemplo se utilizaban pequeñas subrutinas llamadas operadores para secuencias de código frecuentes, realizar comparaciones directas con el tamaño de los objetos de código en los sistemas más modernos no tiene sentido. La alta densidad de código era una buena opción de optimización para un sistema multiusuario con una memoria principal cara, como Multics.

La siguiente literatura contiene un gran número de documentos sobre Multics y varios componentes del mismo. Una lista bastante completa es accesible a través de here. Los más importantes y/o informativos son listados debajo.