Multics
De Wikipedia, la enciclopedia libre
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.
Tabla de contenidos |
[editar] Descripción
Los planes iniciales y el desarrollo de Multics comenzó en 1964. Originalmente era un proyecto coperativo liderado por Fernando Corbató del MIT, con General Electric y los laboratorios Bell. Los laboratorios Bell abandonaron en 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 contro de acceso sobre cada fichero 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.
[editar] Ideas nuevas
Multics fue un de los primeros sistemas operativos que implementó un único nivel de almacenamiento para el acceso a los datos, desechando la clara distinción entre los ficheros (llamados segmentos en Multics) y los procesos en memoria. La memoria de un proceso consistía solamente en segmentos que estaban mapeados 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 POSIX, era como si cada fichero fuese mmap()eado; sin embargo, en Multics no existía el concepto de memoria de proceso, separado del de la memoria utilizada para mantener mapeados sobre los ficheros, 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 kernel, etc.
(Una desventaja práctica, dadas las particularidades de la arquitectura hardware de las máquinas en las que se ejecutaba, y no del concepto básico, era que el tamaño de los segementos 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 ficheros mayores que esto, llamados ficheros multisegmento. En los días anteriores a las bases de datos grandes, y los posteriores gráficos bitmaps inmensos, no era frecuente encontrarse con esta limitación.)
Esto nos conduce a la segunda gran idea de Multics, enlace dinámico, mediante el que 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, 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 (informática) (en otro proceso) un proceso de usuario simplemente realiza una llamanda 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.
Debe notarse que 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 on-line 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. (De hecho, 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 los tests 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 Multics 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écnias 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 ficheros jerárquico, los nombres de los ficheros casi podían tener una longitud y sintaxis arbitraria; dado un fichero 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 ahora estándar concepto 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 escritos en un lenguaje de alto nivel; se utilizó PL/I, aunque el sistema Burroughs B5000, que utilizaba ALGOL precedió a Multics.
[editar] Historia del proyecto
Multics se desarrolló inicialmente para el mainframe GE-645, un sistema de 36 bits; después fue soportado por la serie de máquinas Honeywell 6180.
Los laboratorios Bell dejaron el proyecto en 1969; algunas de las personas que habían trabajado en su desarrollo se dedicaron a crear el sistema Unix. Aunque de un modo superficial, UNIX muestra la influencia de Multics en muchas áreas, incluido el nombre de los comandos. 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") 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.
Honeywell compró la división de computación de General Electric, lanzó una mejor base hardware, y continuó el desarrollo del sistema hasta 1985. Se realizaron unas 80 instalaciones por valor de varios millones de dólares, en universidades, industria, y administración. 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, los usuarios migraron a otros sistemas (incluyendo sistemas Unix).
La última máquina Multics fue apagada el 31 de Octubre de 2000, en el Ministerio de Defensa de Canadá.
[editar] Mirando hacia atrás
Es más que sorprendente descubrir que el kernel de este poderoso mainframe multiprocesador computing utility, tan criticado en sus días por ser demasiado grande y complejo, ocupaba 135 KBytes de código. El primer GE-645 del MIT tuvo 512K palabras de memoria (2 [MByte]s), de manera que el kernel 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 unos 1500 módulos de código fuente. Cada uno con una longitud media de unas 200 líneas de código fuente, y compilaban para producir aproximadamente 4,5 MBytes de código de procedimientos, que aunque hoy parezca pequeño era muy grande para los standards 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.
[editar] Véase también
- Fernando J. Corbató, líder del proyecto mientras el MIT estuvo involucrado
- Jerome H. Saltzer
- Jack B. Dennis
- Peter J. Denning
- Robert M. Graham
- Victor A. Vyssotsky
[editar] Más lecturas
La siguiente literatura contiene un gran número de papes 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.
- F. J. Corbató, V. A. Vyssotsky, Introduction and Overview of the Multics System (AFIPS 1965) is a good introduction to the system..
- F. J. Corbató, C. T. Clingen, J. H. Saltzer, Multics -- The First Seven Years (AFIPS, 1972) is an excellent review, after a considerable period of use and improvement.
[editar] Detalles técnicos
- Jerome H. Saltzer, Introduction to Multics (MIT Project MAC, 1974) una extensa introducción al sistema, dirigida hacia usuarios del sistema.
- Elliott I. Organick, The Multics System: An Examination of Its Structure (MIT Press, 1972) el proceso estándar del sistema, si bien documenta una de las primeras versiones, incluyendo algunas que nunca vieron la luz.
- V. A. Vyssotsky, F. J. Corbató, R. M. Graham, Structure of the Multics Supervisor (AFIPS 1965) describe la estructura interna básica del kernel de Multics.
- Jerome H. Saltzer, Traffic Control in a Multiplexed Computer System (MIT Project MAC, June 1966) es la descripción original de intercambio de pilas en el kernel (switching kernel stacks); este trabajo se ha convertido en un artículo clásico en computación.
- R. C. Daley, P. G. Neumann, A General Purpose File System for Secondary Storage (AFIPS, 1965) describe es sistema de archivos, incluyendo el control de acceso y mecanismos de respaldo.
- A. Bensoussan, C. T. Clingen, R. C. Daley, The Multics Virtual Memory: Concepts and Design, (ACM SOSP, 1969) describe el sistema de memoria de Multics de forma bastante detallada.
- Paul Green, Multics Virtual Memory - Tutorial and Reflections revisión profunda del sistema de almacenamiento de Multics.
- Roger R. Schell, Dynamic Reconfiguration in a Modular Computer System (MIT Project MAC, 1971) describe el mecanismo de reconfiguración.
[editar] Seguridad
- Paul A. Karger, Roger R. Schell, Multics Security Evaluation: Vulnerability Analysis (Air Force Electronic Systems Division, 1974) describes the classic attacks on Multics security by a "tiger team".
- Jerome H. Saltzer, Michael D. Schroeder, The Protection of Information in Computer Systems (Proceedings of the IEEE, September 1975) describes the fundamentals behind the first round of security upgrades; another classic paper.
- M. D. Schroeder, D. D. Clark, J. H. Saltzer, D. H. Wells. Final Report of the Multics Kernel Design Project (MIT LCS, 1978) describes the security upgrades added to produce an even more improved version.
- Paul A. Karger, Roger R. Schell, Thirty Years Later: Lessons from the Multics Security Evaluation (IBM, 2002) is an interesting retrospective which compares actual deployed security in today's hostile environment with what was demonstrated to be possible decades ago. It concludes that Multics offered considerably stronger security than most systems commercially available in 2002.
[editar] Enlaces externos
- http://www.multicians.org/ is a great site with a lot of material
- Multics papers online
- Myths discusses numerous myths about Multics in some detail, including the myths that it failed, that it was big and slow, and numerous other canards, as well as a few understandable misapprehensions
- Multics security
- Multics repository
- Multics repository at Stratus Computer
- Multics at Universitaet Mainz
