NLTSS

El Sistema de Tiempo Compartido de Red Livermore ( NLTSS , también conocido a veces como Nuevo Sistema de Tiempo Compartido de Livermore e internamente como LINOS , el Sistema Operativo de Red Interactiva LINCS ) es un sistema operativo que se desarrolló activamente en el Laboratorio Lawrence Livermore (LLL) (ahora Laboratorio Nacional Lawrence Livermore , LLNL) desde 1979 hasta aproximadamente 1988, aunque continuó ejecutando aplicaciones de producción y recibiendo soporte e incluso, en algunos casos, se extendió hasta 1995. Un sistema operativo anterior, el Sistema de Tiempo Compartido de Livermore, se había desarrollado más de una década antes en LLL.

Inicialmente, NLTSS funcionaba en un ordenador CDC 7600 , pero desde aproximadamente 1984 hasta 1995 solo se utilizó para producción en ordenadores Cray , incluidos los modelos Cray-1 , Cray X-MP y Cray Y-MP .

El sistema operativo NLTSS era inusual en muchos aspectos y único en algunos.

La mayor parte de la programación de NLTSS se realizó en una extensión de Pascal desarrollada en el Laboratorio Nacional de Los Alamos, conocida como "Model". Model extendió Pascal para incluir un mecanismo de tipo de datos abstracto (objeto) y algunas otras características.

NLTSS arrastraba problemas de compatibilidad heredados. NLTSS surgió tras el desarrollo e implementación del Livermore Time Sharing System (LTSS) en el Livermore Computer Center del LLNL (aproximadamente entre 1968 y 1988). El desarrollo de NLTSS comenzó casi al mismo tiempo que LTSS se portaba al Cray-1 para convertirse en el Cray Time Sharing System . Para mantener la compatibilidad con las numerosas aplicaciones científicas del LLNL, NLTSS se vio obligado a emular las llamadas al sistema del sistema operativo LTSS anterior. Esta emulación se implementó mediante una biblioteca de compatibilidad denominada "baselib". Por ejemplo, si bien la estructura de directorios y, por lo tanto, la estructura de procesos de NLTSS era naturalmente un grafo dirigido (las capacidades de los procesos podían almacenarse en directorios, al igual que las capacidades de los archivos o los directorios), la biblioteca baselib emulaba una estructura de procesos lineal simple (controlador-controlado) (ni siquiera una estructura de árbol como en Unix ) para mantener la compatibilidad con el LTSS anterior. Dado que los usuarios científicos nunca accedieron a los servicios de NLTSS fuera de la biblioteca baselib, NLTSS terminó pareciéndose casi exactamente a LTSS para sus usuarios. La mayoría de los usuarios desconocían sus capacidades, no se daban cuenta de que podían acceder a recursos a través de la red y, en general, no sabían que NLTSS ofrecía servicios más allá de los de LTSS. NLTSS sí admitía el procesamiento simétrico multiprocesador de memoria compartida , un desarrollo paralelo a uno similar en el sistema de tiempo compartido de Cray .

Incluso el nombre NLTSS era, en cierto modo, un legado. El nombre "New Livermore Time Sharing System" se consideró inicialmente un nombre provisional para usar durante el desarrollo. Una vez que el sistema comenzó a ejecutar algunas aplicaciones en modo de sistema dual (una especie de máquina virtual que compartía controladores con LTSS), los desarrolladores eligieron un nombre más permanente: LIncs Network Operating System (LINOS). Desafortunadamente, la dirección de LLNL decidió que el nombre no se podía cambiar en ese momento (aparentemente porque el término anterior se había utilizado en las solicitudes de presupuesto), por lo que el nombre provisional de desarrollo NLTSS se mantuvo con el sistema durante toda su vida útil.

Paralelamente a NLTSS, se desarrolló un sistema de almacenamiento masivo que utilizaba los protocolos LINCS (los mismos protocolos de archivos y directorios que NLTSS). Este sistema/software se comercializó posteriormente como Unitree. Unitree fue generalmente reemplazado por el Sistema de Almacenamiento de Alto Rendimiento (HPSS), que podría considerarse, en cierto modo, un legado de LINCS y NLTSS. Por ejemplo, LINCS y NLTSS introdujeron una forma de transferencia de terceros (para copiar archivos en NLTSS, un proceso podía enviar dos solicitudes a los servidores de archivos, una de lectura y otra de escritura, e indicarles que transfirieran los datos entre sí), que se mantuvo, con algunas modificaciones, en Unitree y HPSS.

El principal inconveniente de NLTSS durante su vida útil fue su rendimiento. El problema de rendimiento que más afectó a los usuarios fue la latencia de acceso a archivos . Si bien esto generalmente no representaba un problema significativo para la entrada/salida (E/S) de disco, los sistemas en los que se ejecutaba NLTSS también admitían una cantidad considerable de discos de estado sólido de muy baja latencia con tiempos de acceso inferiores a 10 microsegundos. Las latencias iniciales para las operaciones de archivos en NLTSS eran comparables a la latencia de acceso a discos de estado sólido y significativamente superiores a la latencia de LTSS para dicho acceso. Para mejorar la latencia de acceso a archivos en NLTSS, la implementación se modificó sustancialmente para ubicar los procesos más sensibles a la latencia (en particular, el servidor de archivos) en el núcleo. Este esfuerzo no fue tan significativo como podría parecer a primera vista, ya que todos los servidores NLTSS funcionaban con un modelo de multihilo . En realidad, este cambio consistió en trasladar los hilos responsables de los servicios del servidor de archivos de un proceso de servidor de archivos independiente al proceso del núcleo. La comunicación con los usuarios se mantuvo sin cambios (aún mediante tablas de búfer, tokens LINCS, etc.), pero las operaciones de archivos evitaron algunos cambios de contexto significativos que fueron la causa principal de las mayores latencias en comparación con el antiguo LTSS y el sistema de tiempo compartido Cray de la competencia . Este cambio mejoró significativamente (aproximadamente tres veces) la latencia de las operaciones de E/S de archivos, pero también significó que el servidor de archivos se convirtiera en una parte confiable del núcleo (por implementación, no por diseño).

Un segundo problema de implementación con NLTSS se relacionaba con la seguridad/integridad de su capacidad como implementación de datos. Esta implementación utilizaba un modelo de capacidad de contraseña (por ejemplo, véase Control por Contraseña). ^{[ 2 ]} Con este modelo, cualquier persona o proceso que pudiera acceder al espacio de memoria de un proceso tendría autoridad para acceder a la capacidad representada por los datos encontrados en esa memoria. Algunos arquitectos de sistemas (por ejemplo, Andrew S. Tanenbaum , el arquitecto del sistema operativo distribuido Amoeba ) han sugerido que esta propiedad del acceso a la memoria, que implica acceso a capacidades, no es un problema inherente. En el entorno de NLTSS, a veces ocurría que las personas tomaban volcados de memoria de programas para que otros los analizaran. Debido a esto y otras preocupaciones, dichas capacidades de contraseña se consideraron una vulnerabilidad en NLTSS. Se diseñó un mecanismo para protegerse contra esta vulnerabilidad, el Control por Cifrado de Clave Pública ^{[ 3 ]} . Este mecanismo no se implementó en producción en NLTSS debido a su importante costo de rendimiento y porque los usuarios no eran conscientes de la vulnerabilidad de las capacidades de contraseña. Los avances modernos en criptografía harían práctica dicha protección para las capacidades, especialmente para las capacidades de Internet/Web (por ejemplo, véanse las URL ^{[ 4 ]} o WideWORD). ^{[ 5 ]}

Un problema de diseño de NLTSS que no se consideró hasta años después de su retirada de producción fue su arquitectura de red abierta. En NLTSS, los procesos se consideraban procesadores virtuales en una red sin cortafuegos ni otras restricciones. Cualquier proceso podía comunicarse libremente con cualquier otro. Esto significaba que no era posible aplicar restricciones, ni siquiera en el sentido de limitar la comunicación directa, por ejemplo, en comparación con limitar canales encubiertos como el ataque de "wall banging". Para corregir este problema, NLTSS tendría que requerir capacidades que permitieran la comunicación. El trabajo de desarrollo posterior en NLTSS, como los "números de flujo", se acercaba a dicha funcionalidad, pero cuando el desarrollo activo cesó en 1988, la comunicación en NLTSS seguía sin estar restringida.

• Sistema de tiempo compartido de Livermore

• JE Donnelley, Componentes de un sistema operativo de red , Cuarta Conferencia sobre Redes Locales, Minneapolis, 1979. También en Computer Networks 3 (1979) 389–399.
• JE Donnelley, Managing Domains in a Network Operating System , Actas de la Conferencia sobre Redes Locales y Sistemas de Oficina Distribuidos, Londres, mayo de 1981, págs.  345–361.
• ST Brugger, M. Gandhi y G. Streletz, Sistema de tiempo compartido de la red Livermore (NLTSS) , 2001

• Computación basada en capacidades en LLNL. Un análisis de la historia del uso de capacidades en la computación en LLNL, incluyendo una breve mención del sistema RATS y cómo su desarrollo condujo a NLTSS.
• Historias del desarrollo de la computación científica a gran escala en el Laboratorio Nacional Lawrence Livermore.
• Las Crónicas de NLTSS: Dibujos animados del desarrollo de NLTSS y LINCS.