AMOEBA

De la Universidad Libre de Amsterdam.

Es un sistema distribuido, permite que una coleción de CPU y equipo de E/S se
comporten como una computadora. También proporciona elementos para la
programación en paralelo si se desea.
Amoeba no tiene el concepto de máquina de origen. Cuando un usuario entra
al sistema entra a éste como un todo y no a una máquina específica. El shell
inicial se ejecuta en cierta máquina arbitraria, y los comando en otra máquina
en general no la misma que la del shell. El sistema busca la máquina con la
menor carga para ejecutar el nuevo comando. Amoeba es muy transparente
respecto a la ubicación. Todos los recursos pertenecen al sistema como un
todo y son controlados por él.
No se necesita la memoria compartida, pero si está presente se utiliza para
optimizar la transferencia de mensajes al hacer el copiad de una memoria a
otra, en vez de enviar mensajes a través de la red.
Cuando un usuario escribe un comando, el sistema operativo asigna en forma
dinámica uno o más procesadores para ejecutar ese comando. Al terminar el
comando, se terminan los procesos y los recursos regresan a la pila, en espera
de siguiente comando.
El sistema de archivos de Amoeba consta de tres servidores: el servidor de
archivos para el almacenamiento de éstos, el de directorios para otorgar
nombres y el de réplicas para la réplica de archivos.

Características:
· Kernel pequeño: planificación y paso de mensajes.
· El SO corre como procesos de usuario.
· Servicio de gateway a WAN.
· Gestión del pool mediante un servidor de carga y otro de procesos.

Ventajas:
· Recursos de procesamiento ajustados a las necesidades del usuario.
· Ejecución concurrente.
· Acceso a través de terminales.

Para llevar a cabo la instalación de un sistema Amoeba se requiere de al

menos 5 computadores, los cuales deben contar con un espacio de disco duro
de por lo menos 70 MB, tener como mínimo 16 MB de memoria RAM y poseer
una o más tarjetas de red (por cada máquina).

MACH

Este sistema distribuido se basa en un micronúcleo. Es un proyecto de diseño

de sistemas operativos iniciado en la Universidad Carnegie Mellon en 1985. Se
hizo que Mach fuese compatible con UNIX, esperando poder utilizar el enorme
volumen disponible de software para UNIX. La primera versión apareció en
1986.

Objetivos:
 Proporcionar una base para la construcción de otros sistemas operativos.
 Soporte de un espacio de direcciones ralo y de gran tamaño.
 Permitir el acceso transparente a los recursos de la red.
 Explorar el paralelismo tanto en el sistema como en las aplicaciones.
 Hacer que Mach se pueda transportar a una colección más grande de
máquinas.
La idea es explorar los multiprocesadores y los sistemas distribuidos, a la vez
que se puedan emular los sistemas ya existentes como UNIX, MS-DOS y
Macintosh.
El núcleo de Mach, al igual que otros micronúcleos, proporciona la
administración de procesos, la administración de la memoria, la comunicación y
los servicios de E/S. Los archivos, directorios y demás funciones tradicionales
de sistema operativo se controlan en el espacio del usuario. La idea del núcleo
es proporcionar los mecanismos necesarios para que el sistema funcione, pero
dejando la política a los procesos a nivel de usuario.
Mach se basa en los conceptos de procesos, hilos, puertos y mensajes. Mach
tiene un sistema de memoria virtual muy elaborado con objetivos de memoria
que se pueden asociar o desasociar de los espacios de direcciones,
respaldado por administradores de memoria externos a nivel de usuario. De
esta forma se puede escribir o leer de los archivos en forma directa.

CHORUS

Chorus surgió en el instituto francés de investigación INRIA en 1980 como

proyecto de investigación en sistemas distribuidos. Desde entonces han
aparecido 4 versiones, de la 0 a la 3.
La versión 0 quería modelar aplicaciones distribuidas como colección de
actores, en esencia procesos estructurados, cada uno de los cuales alternaban
entre la realización de una transacción atómica y la ejecución de un paso de
comunicación. La versión 1 se centró en la investigación de multiprocesador.
Fue escrita en Pascal compilado en vez de interpretado y se distribuyó en una
docena de universidades y compañías. La versión 2 fue una reescritura
fundamental en C. Se diseñó de modo que las llamadas al sistema fuesen
compatibles con UNIX en el nivel del código fuente. La versión 3 marcó la
transición de un sistema de investigación a un producto comercial. Se introdujo
la llamada a procedimientos remotos como el modelo de comunicación usual.
Para que sea un producto viable se aumentó la capacidad de emulación de
UNIX, de modo que los programas en UNIX se ejecutaran sin compilarse de
nuevo.

Objetivos de Chorus:
 Emulación de UNIX de alto rendimiento.
 Uso de sistemas distribuidos.
 Aplicaciones de tiempo real.
 Integración de la programación orientada a objetos en Chorus.

Está estructurado en capas. En la parte inferior está el micronúcleo que

proporciona la mínima administración de los nombres, procesos, hilos, memoria
y comunicación. Se tiene acceso a estos servicios mediante llamadas al
micronúcleo.
Los procesos de las capas superiores proporcionan el resto del sistema
operativo.
Por arriba de micronúcleo pero operando también en el modo núcleo están los
procesos del núcelo.
Estos se cargan y eliminan de manera dinámica durante la ejecución del
sistema y proporcionan una forma de extender la funcionalidad del micronúcleo
sin que aumente de manera permanente su tamaño y complejidad.
El micronúcleo y los subsistemas proporcionan juntos tres construcciones
adicionales: las posibilidades, los identificadores de protección y los
segmentos. Los primeros dos se utilizan para nombrar y proteger los recursos
del subsistema. La tercera es la base para la asignación de memoria, tanto
dentro de un proceso en ejecución como en el disco.

DCE

DCE significa ambiente de administración distribuido, este ambiente se

construye sobre los sistemas operativos existentes.
El ambiente ofrecido por DCE consta de un número grande de herramientas y
servicios, más de una infraestructura para que éstos operen. Las herramientas
y servicios han sido elegidos de modo que funcionen juntos de manera
integrada y faciliten el desarrollo de aplicaciones distribuidas. Por ejemplo, DCE
proporciona un mecanismo para sincronizar los relojes de máquinas diferentes
y obtener el concepto global de tiempo.
DCE se ejecuta en muchos tipos distintos de computadoras, sistemas
operativos y redes. De esta forma los desarrolladores de aplicaciones producen
con facilidad software portable en varias plataformas.
El modelo de programación subyacente en todo DCE es el modelo
cliente/servidor. Los procesos usuario actúan como clientes para tener acceso
a los servicios remotos proporcionados por los procesos servidor. DCE soporta
dos facilidades que se utilizan intensamente, tanto dentro del propio
DCE como en los programas usuario: hilos y RPC. Los hilos permiten la
existencia de varios flujos de control dentro de un proceso. RPC es el
mecanismo básico de comunicación dentro de DCE.
Permite que un proceso cliente llame a un procedimiento en una máquina
remota.
DCE soporta cuatro servicios principales a los que tienen acceso los clientes:
los servicios de tiempo, directorios, seguridad y archivos. El servicio de
directorios guarda los nombres y posiciones de todos tipos de recursos y
permite que los clientes los busquen. El servicio de seguridad permite que los
clientes y servidores se autentiquen entre si y realicen una RPC autentificada.
El sistema de archivos proporciona un espacio de nombres para todos los
archivos del sistema.

INFERNO

Es un sistema operativo compacto diseñado para la construcción de sistemas

distribuidos y en red en una amplia variedad de dispositivos y plataformas. Con
muchas características avanzadas y únicas.

Portabilidad entre plataformas

Inferno puede funcionar como una aplicación de usuario en la parte superior
de un sistema operativo existente o como un sistema autónomo de
funcionamiento. La mayoría de los sistemas operativos y arquitecturas de
procesadores son compatibles:
Los sistemas operativos Arquitecturas soportadas
host  Intel x86 (386 y más)
 Windows NT/2000/XP  Intel XScale
 Irix  IBM PowerPC
 Linux  StrongARM ARM (ARM y del
 MacOS X pulgar)
 FreeBSD  Sun SPARC
 Solaris
 Plan 9
Inferno también funciona como un plug-in en Internet Explorer versión 4 o
superior. Cada sistema Inferno presenta un ambiente idéntico al de las
aplicaciones, independientemente del sistema operativo subyacente de acogida
o la arquitectura, lo que permite al programador trabajar con un ambiente
verdaderamente homogénea a través de múltiples plataformas diferentes.
Aplicaciones portátiles
Inferno aplicaciones están escritas en el limbo, un moderno, seguro,
concurrente lenguaje de programación modular similar a la sintaxis de C. Es
más poderoso que el C, pero mucho más fácil de entender y de depuración de
C + + o Java. Es fácil de expresar la concurrencia en el mundo físico
directamente en la sintaxis de Limbo. Cualquier aplicación Inferno se ejecutará
de forma idéntica en todas las plataformas Inferno.
Portable Código
Limbo código se compila en código independiente de la arquitectura para el
Dis Virtual Machine, con una representación compacta. Dis se puede
interpretar directamente (ahorro de espacio), o recopilada sobre la marcha para
un procesador determinado objetivo (ahorro de tiempo). La elección se puede
hacer en tiempo de ejecución, por módulo. La arquitectura de Dis fue
cuidadosamente diseñado para que el código de generación en volar directo.
Sus instrucciones son fáciles de implementar.
Transparente de Recursos
Seguridad
Inferno ofrece soporte completo para autenticación, conexiones cifradas
mediante un certificado basado en esquema de identificación de usuario y una
variedad de algoritmos que incluyen:
• IDEA, DES de 56 bits, 40, 128 y 256 bits RC4 algoritmos de cifrado
• MD4, MD5 y SHA algoritmos hash seguro
Una solución completa
Inferno es no sólo un sistema operativo, también es un entorno completo de
desarrollo, proporcionando todas las herramientas necesarias para crear,
probar y depurar las aplicaciones que se ejecutan dentro de él.
• Acme IDE: incluye editor, shell, herramientas avanzadas de
coincidencia de patrones y más
• Rápida compilador: con la sintaxis completa y comprobación de tipos en
tiempo de compilación
• Gráfica del depurador: con traza completa de las discusiones que se
ejecuta actualmente
• Potente Shell: con sofisticadas capacidades de scripting
• UNIX como comandos: en particular, se unen, grep, gzip, montaje, ps,
alquitrán, yacc ...
Se ejecuta en dispositivos con tan sólo 1 MB de RAM.

PLAN 9

Plan 9 es un avanzado multi-usuario de código abierto del sistema operativo

diseñado con funciones de red en mente. Se ejecuta en múltiples plataformas
de hardware y es muy adecuado para la construcción de grandes sistemas
distribuidos.
Un típico Plan 9 de instalación estaría integrada por uno o más servidores de
archivos, algunos servidores de la CPU y un gran número de terminales
(estaciones de trabajo del usuario).
Plan 9 es adecuado para grupos de investigación de pequeñas a grandes
organizaciones. La sobrecarga del sistema de gestión bajo la hace
especialmente adecuada para aplicaciones de clase y la enseñanza.

Está diseñado en torno al principio básico de que todos los recursos aparecen
como archivos en un sistema jerárquico de archivos (espacio de nombres) que
es único para cada proceso. Estos recursos se accede a través de un nivel de
protocolo de red llamado 9P que oculta la ubicación exacta de los servicios por
parte del usuario. Todos los servidores de prestar sus servicios como una
jerarquía de exportación de archivos.
Características:
• El sistema de archivo de volcado de todos los días hace una
"instantánea" de la FILESTORE disposición de los usuarios
• juego de caracteres Unicode de apoyo en todo el sistema
• Avanzadas instalaciones del núcleo de sincronización para el
procesamiento paralelo
• ANSI / entorno POSIX emulador (APE)
• Fontanería, de manera idioma impulsada por las aplicaciones se
comuniquen
• Acme - un editor, depósito y sistema de ventanas para los
programadores
• Sam - un editor de pantalla con estructural expresiones regulares
• Apoyo a MIME mensajes de correo e IMAP4
• Seguridad - no hay super-usuario o de la raíz, y las contraseñas no se
envían a través de la red
• Venti - almacenamiento de archivos
• Fósiles - jerárquica del sistema de archivos integrado en la parte
superior de Venti, con instantáneas automáticas y archivos

TAOS

Taos es un S.O basado en Kernels. Que introducen técnicas novedosas como

la compilación en demanda para tolerar sistemas heterogéneos. Taos introdujo
una innovación en la construcción de S.O. paralelo consistente en el uso de
una máquina abstracta de muy bajo nivel de tal modo que los binarios del
sistema se compilaban en demanda durante el proceso de carga desde disco.
Consiguientemente, Taos es capaz de operar en sistemas heterogéneos sin
incurrir en la ineficiencia que el uso de una máquina abstracta conlleva--como
ocurre en el caso de Java.

Taos combina el enlazado de código con la traducción a nativo en demanda de

tal modo que todo el sistema está compuesto por una serie de nodos (la
abstracción básica en Taos) que básicamente son paquetes de datos de
tamaño variable susceptibles de enlazarse entre si. Estos nodos se compilan
en demanda al procesador nativo que se utilice (el código fuente en sistemas
Taos se compila para un procesador virtual).

SPRITE

Sistema operativo distribuido con un núcleo monolítico desarrollado por la

University of California, Berkeley, más concretamente por el grupo de
investigación de John Ousterhout.
Este sistema operativo tiene la apariencia para los programadores de un
sistema único, ya que la distribución se produce dentro del propio núcleo y de
este modo, Sprite nos da la impresión de estar trabajando sobre un típico
sistema UNIX.

SPRING

Este sistema introduce nuevas técnicas basadas en el modelo de Orientación a

Objetos (OO) de tal modo que los servicios del SO están compuestos por un
conjunto de objetos que cooperan para implementarlos y es factible modificar
los mecanismos empleados en la interacción entre dichos objetos.
Anteriormente, Choices ya empleó la OO como base para alcanzar un SO
flexible y reconfigurable.
Spring introduce innovaciones como el modelo de subcontrato que permiten
adaptar en cierta medida la intercomunicación entre los distintos objetos que
constituyen el sistema. El modelo de subcontrato consiste en delegar la
invocación de métodos remotos a un objeto que implementa el “subcontrato''
que tiene el cliente con el servidor. Modificando éste se puede alterar la
interconexión entre el cliente y el servidor.
En cuanto a los servicios suministrados por el sistema, Spring incorpora
Shuttles, Threads, Espacios de Direcciones y Doors como abstracciones
fundamentales del sistema, imponiéndose abstracciones pesadas a las
aplicaciones.
El sistema de memoria virtual de Spring, que implementa los espacios de
direcciones, ejecuta “fuera'' del kernel. No obstante, ejecuta con todos los
privilegios del núcleo y además impone su abstracción de Espacio de
Direcciones a las aplicaciones. A efectos de adaptabilidad en el sistema, la
gestión de memoria puede considerarse dentro del núcleo salvo por la
existencia de paginadores externos como ocurría en Mach.
El sistema de gestión de procesos, que emplea Shuttles, oculta éstos a las
aplicaciones. Éstas perciben Threads como abstracción básica, y estos threads
están multiplexados por el núcleo sobre los shuttles existentes. No es preciso
decir pues que tampoco es posible reemplazar o adaptar el comportamiento y/o
la implementación de estas abstracciones en Spring.
El mecanismo básico de IPC en Spring (las doors) es una adaptación del
modelo de gates de MULTICS. Un Shuttle puede emplear una door para
efectuar una transferencia protegida de control cambiando (posiblemente) su
domino de protección. Esta abstracción está contenida en el núcleo, y se
emplean descriptores para exportarla a las aplicaciones. La implicación obvia
es que el núcleo debe intervenir en todos aquellos casos en que una aplicación
obtiene (o pierde) derecho a invocar una door. Como consecuencia, la
implementación de la transferencia de datos entre un cliente y un servidor está
predeterminada en gran medida por el núcleo (dado que éste debe intervenir y
cuidar las transferencias que involucran transferencias de derechos de
invocación de doors. La ventaja de emplear descriptores y hacer que la
transferencia de éstos la realice el núcleo es que resulta muy simple emplear
mecanismos de cuenta de referencias para liberar recursos que ya no se
utilizan.

Solaris MC

Solaris MC es una extensión del núcleo de Solaris para operar en cluster. Éste
sistema incorpora ideas procedentes de Spring, aunque mantiene la estructura
de núcleo monolítico no adaptable que presenta UNIX.
Solaris MC se construye como conjunto de extensiones al Solaris bajo UNIX y
proporciona el mismo ABI/API que Solaris, ejecutando aplicaciones sin
modificar. Los componentes de Solaris MC se ponen en ejecución en C++ a
través de un sistema orientado a objetos de OCRcBcA-compliant con todos los
nuevos servicios definidos por el lenguaje IDL. de tal modo que los servicios del
SO están compuestos por un conjunto de objetos que cooperan para
implementarlos y es factible modificar los mecanismos empleados en la
interacción entre dichos objetos.
El sistema de memoria virtual implementa los espacios de direcciones, ejecuta
``fuera'' del kernel. No obstante, ejecuta con todos los privilegios del núcleo y
además impone su abstracción de Espacio de Direcciones a las aplicaciones. A
efectos de adaptabilidad en el sistema, la gestión de memoria puede
considerarse dentro del núcleo salvo por la existencia de paginadores externos
como ocurría en Mach.
En pocas palabras, Solaris MC es un sistema distribuido que no puede
considerarse como un sistema adaptable en realidad, aunque sea elegante y
extremadamente flexible.