¿Crees que los SO gestionados son una buena idea? [cerrado]

Los sistemas operativos administrados como Microsoft Singularity y JNode son un concepto bastante interesante. Esencialmente, el sistema operativo se inicia con código escrito en un lenguaje de bajo nivel (C / C ++ / Assembly), que esencialmente implementa una máquina virtual. El resto del sistema operativo (y todas las aplicaciones de usuario) se ejecutan en la máquina virtual. Hay algunas cosas geniales sobre esto. Por ejemplo, de repente haces obsoletos los punteros arbitrarios. Y si está bien escrito, se deshace de una tonelada de legado crud que los sistemas operativos más modernos tienen actualmente.

Sin embargo, como desventaja, está mucho más alejado del hardware y, como desarrollador, pierde la capacidad de descender a un nivel inferior de abstracción y ensuciarse las manos.

Cual es tu opinión sobre esto?

Creo que este es otro caso donde "depende".

Si está escribiendo aplicaciones como navegadores web, procesadores de texto, etc., donde el rendimiento a la velocidad del rayo no es necesariamente un problema, entonces este enfoque tiene sus ventajas. Al utilizar este enfoque, puede ofrecer a sus clientes una experiencia más segura y controlada. No solo está limitando el daño que puede causar el malware, sino que también se está ejecutando en un entorno más consistente.

Es como la diferencia entre los juegos de consola y los juegos de PC. Los primeros saben exactamente con qué hardware necesitan trabajar, por lo que pueden hacer uso de ese conocimiento, mientras que los segundos deben ser capaces de hacer frente a una variedad más amplia de tarjetas gráficas, tarjetas de sonido, velocidades de disco duro, etc.

Sin embargo, habrá aplicaciones (como juegos) que requieren un acceso de bajo nivel y que aún deberán ejecutarse "de forma nativa".

Al igual que los idiomas administrados, deberá utilizar la herramienta adecuada para el trabajo.

En general, creo que son una buena idea, pero dado que no hay muchos de ellos cerca o cerca de estar completamente horneados, es muy difícil saber cómo se comportarían en el mundo real. Desearía que MS hubiera actualizado el proyecto Singularity para que pudiéramos ver a dónde iba, pero supongo que parte de esto se está trabajando en alguna versión de Windows

Creo que los beneficios de un sistema operativo totalmente administrado son enormes y que realmente podría ser el futuro, pero requerirá muchos años.

Un buen sistema operativo administrado le proporcionará todo el punto de entrada administrado que necesita para hacer todo lo que necesite de bajo nivel, independientemente de cómo se gestione: capturar interrupciones y realizar E / S con dispositivos. C # también permite código inseguro (que trata con punteros) pero solo se permitirá en los "controladores de dispositivo" (que será solo otro tipo de proceso aislado de software).

Los beneficios en seguridad, uniformidad, portabilidad y especialmente confiabilidad ciertamente excederán cualquier inconveniente de rendimiento. Entonces, un sistema completamente administrado es sorprendentemente rápido, ya que ya no es necesario hacer un cambio de contexto.

Los sistemas operativos administrados probablemente son de alguna manera como microkernels: sacrifica el rendimiento en nombre de la seguridad.

Podría haber problemas similares, ya que requiere dividir el código en 2 partes:

• Kernel de bajo nivel escrito en C / ensamblador
• Kernel de alto nivel escrito en lenguaje administrado

Dependiendo del costo de ingresar / salir de forma segura del lenguaje HL, puede imponer problemas similares a los microkernels, posiblemente un poco más rápido (dejar HL es más rápido que el cambio de contexto completo, pero IIRC, por ejemplo, JNI es bastante costoso).

La aplicación de usuario probablemente también necesitaría contextos separados, ya que muchas aplicaciones están escritas en otras plataformas (por ejemplo, C, Java o .Net). En los mismos casos, las aplicaciones pueden estar vinculadas a la CPU (compiladores, convertidores de música, etc.) e incluso necesitan una optimización del ensamblador para funcionar con suficiente velocidad. Además, la protección MMU implementada en el lenguaje HL probablemente no será tan rápida como la del hardware, incluso si se ajusta mucho más.

Además, el lenguaje HL no es competente en las operaciones de bajo nivel. Si bien el software generalmente está diseñado con "buenas" prácticas de codificación, los controladores no son necesarios. No creo que protejan contra al menos algunos errores, ya que los núcleos a veces requieren memoria de gestión manual.

Finalmente, no creo que dicho sistema operativo requiera una máquina virtual completa. Dado que el sistema operativo no se puede construir con los principales lenguajes HL de compilación una vez que se ejecutan en todas partes (incluso con GC & co.) Sería un mejor candidato.

Por ejemplo, de repente haces obsoletos los punteros arbitrarios.

El sistema operativo es inherentemente de bajo nivel. Usted pasa al hardware no solo 'puntero arbitrario' sino probablemente una dirección física en lugar de una virtual. Algunos DMA pueden manejar solo los primeros 16MiB de memoria. Si bien dicho sistema operativo puede simplificar mucho, no eliminará las direcciones.

Y si está bien escrito, se deshace de una tonelada de legado que actualmente tienen la mayoría de los sistemas operativos modernos.

1. Hay mucho hardware heredado. Mucho más que en software. Primero comienza en modo real, luego habilita la puerta A20 (no preguntar) salta al modo protegido y luego al modo largo.
2. La compatibilidad API / ABI es buena. Digamos que han escrito ese sistema operativo, ¿qué ejecutarías en él? Firefox - no (C y C ++ usando WinAPI). Java, probablemente necesitaba ser portado o tenía algunos problemas menores a través de ikvm, a menos que utilizara JNI. Supongo que MSSQL (y con seguridad Oracle, MySQL, Postgresql ...) no está escrito en lenguaje administrado, por lo que no sería apto para el servidor.
3. Incluso la compatibilidad de errores es "buena". AFAIK MS pasa mucho tiempo simplemente probando y verificando si algún software no está utilizando API de manera inteligente (lectura incorrecta). Al igual que el problema de usar el puntero freecuando Windows realmente comenzó a liberar memoria.

Supongo que ganará popularidad al mismo tiempo que los microkernels.

Personalmente, creo que la idea de un sistema operativo administrado es un poco como el comunismo: bueno en teoría, pero poco práctico de implementar.

El problema es que simplemente no veo ninguna forma de activar el sistema operativo administrado sin reescribir completamente el sistema operativo desde cero (y espero que alguien pueda demostrar que estoy equivocado en esta parte). Además, ¿cómo hace que décadas de código no administrado encajen en un SO administrado?

Los núcleos de los sistemas operativos más populares están probados en batalla y han madurado en el transcurso de un par de décadas. No los reescribes simplemente por capricho. Sin mencionar que la historia está llena de ejemplos de diseños de procesadores y arquitecturas de kernel que eran indudablemente mejores pero que nunca pudieron convencer a nadie de que valía la pena el costo de cambiarlos.

Por último, ¿cómo va a vender una empresa como Microsoft o Apple un sistema operativo administrado a los clientes? ¿Al usuario promedio de la computadora le importará si su sistema operativo es administrado o no?

Lo mencionado anteriormente, espero estar equivocado y que los sistemas operativos administrados sean una realidad. Pero soy escéptico. Si alguna vez lo vemos, probablemente no será por otra década o dos.

El código administrado es solo una extrapolación de lo que la protección de memoria virtual le compra hoy, es decir, la capacidad de la computadora para negar el acceso a los recursos.

IBM ya hace esto en sus sistemas mainframe (simplemente lo llaman de otra manera), por lo que, en mi opinión, es solo cuestión de tiempo antes de que esto suceda en los sistemas disponibles para el público en general.

¿Le importaría si una computadora portátil Google (que ejecuta Chrome y básicamente nada más) se ejecuta en código administrado o no?

Sin embargo, como desventaja, está mucho más alejado del hardware y, como desarrollador, pierde la capacidad de descender a un nivel inferior de abstracción y ensuciarse las manos.

Esto no es realmente cierto. En JNode, por ejemplo, hay una Unsafeclase (y otras) que le permiten acceder a ubicaciones de memoria, etc. También hay algunas clases / métodos "mágicos" que el compilador JIT traduce en instrucciones privilegiadas. El acceso a estas clases / métodos está (o estará) restringido por el administrador de seguridad, el compilador JIT, etc. Pero si está escribiendo código que se ejecuta a nivel del sistema operativo, estas facilidades están disponibles para usted.

La advertencia es (por supuesto) que el uso incorrecto de Unsafey las clases relacionadas pueden provocar fallas en el sistema operativo de inmediato, o en el futuro.

Dudo de su utilidad para las computadoras de escritorio. Pero el tiempo puede probar que estoy equivocado en este punto.

Pero un potencial interesante para mí es como sistema operativo de servidor, más específicamente como sistema operativo invitado en un entorno virtualizado. Nunca me sentó bien instalar una instalación completa del servidor de Windows en un entorno de servidor virtual, sabiendo cuántos servicios innecesarios ejecuta, incluida la GUI completa.

Ahora, instalar algo como Singularity en un servidor virtual para alojar aplicaciones ASP.NET, tiene más sentido. Suponiendo que puedan mantenerlo como un sistema operativo liviano.