El año pasado, por estas fechas, escribí “ El metaverso necesita un sistema operativo ”, una inmersión profunda en por qué era necesaria la idea de nuevas bases de software para manejar un cambio en la forma en que interactuamos a través de la computación espacial. Se exploraron conceptos nuevos y antiguos, pero en última instancia la conclusión fue que hacia donde nos dirigimos en muchos aspectos requiere un replanteamiento del diseño del sistema operativo desde cero.
Simplemente no podemos avanzar donde el pensamiento todavía está estancado en el diseño del núcleo y la arquitectura del sistema operativo de mediados de los años 1980 y 1990. Ahora, con el auge de la IA y los grandes modelos de lenguaje, la soberanía de los datos y el control del usuario, la identidad y los viejos argumentos de ' propietario versus código abierto ', surge nuevamente la cuestión de la necesidad de repensar el sistema operativo de ayer para el mañana.
Advertencias bastante amplias: lo que sigue es puramente conceptual y se basa en investigaciones documentales en campos en los que no soy un experto, pero con una creencia fundamental (sea correcta o incorrecta) de que las cosas deben cambiar. Me atengo deliberadamente a los principios básicos de descentralización, código abierto y modularidad. Intentaré evitar por completo las preguntas sobre las nuevas arquitecturas de CPU y silicio necesarias para aprovechar realmente los cambios porque, seamos realistas, estamos atrapados en el mismo pensamiento debido al diseño del sistema operativo. Es un problema doble.
La industria espacial, a pesar de toda su innovación en la última década gracias a SpaceX, todavía se basa en principios de software operativo que se remontan a la década de 1960 y esto no es una base para construir el futuro de la exploración espacial (“The [Starlink] constellation tiene más de 30.000 nodos Linux (y más de 6.000 microcontroladores) en el espacio en este momento”, dijo Matt Monson en un AMA de Reddit en 2020. Es una gran cantidad de código ubicado en una arquitectura fragmentada concebida originalmente en los años 90.
El panorama de los sistemas operativos, particularmente dentro del sector espacial, se caracteriza por un mosaico de sistemas propietarios y de código abierto, cada uno con su propio conjunto de interfaces y protocolos. Esta falta de estandarización ha generado ineficiencias, mayores costos y complejidades en el diseño de la misión . Algo nuevo abordaría directamente estos desafíos al proporcionar una plataforma cohesiva que garantice la compatibilidad y comunicaciones fluidas entre diversos componentes de hardware y software a través de un enfoque único: una combinación de arquitecturas descentralizadas y RTOS.
Para los no iniciados, Plan 9 de Bell Labs es un sistema operativo distribuido que se originó en el Computing Science Research Center (CSRC) de Bell Labs a mediados de la década de 1980 y se basó en conceptos UNIX desarrollados allí por primera vez a finales de la década de 1960. Desde 2000, Plan 9 es gratuito y de código abierto. El lanzamiento oficial final fue a principios de 2015. Plan 9 reemplazó a Unix como la plataforma principal de Bell Labs para la investigación de sistemas operativos. Exploró varios cambios en el modelo Unix original que facilitan el uso y la programación del sistema, especialmente en entornos distribuidos multiusuario.
¿Por qué preocuparse por esto? ¿Por qué molestarse con esto? Bueno, porque los conceptos detrás del Plan 9 (y hasta cierto punto, GridOS también mencionado en el artículo original de Metaverse OS ) señalan el camino hacia un cambio radical en cómo realmente debemos pensar sobre el diseño del sistema operativo y la arquitectura del kernel, especialmente en el industria espacial.
Descentralizado y modular : algo nuevo debe diseñarse para ser descentralizado, lo que significa que puede operar a través de una red distribuida, reduciendo los puntos únicos de falla y potencialmente mejorando la resiliencia y la tolerancia a fallas, lo cual es crítico para las operaciones espaciales.
Personalización : gracias a una arquitectura de microkernel modular, debería permitir una mayor flexibilidad. Se pueden agregar o quitar módulos según sea necesario para diferentes aplicaciones o misiones, lo que lo hace altamente adaptable a diversos requisitos.
Capacidades en tiempo real : la integración de capacidades de procesamiento en tiempo real, cruciales para aplicaciones urgentes, como las que se encuentran en la exploración espacial y las operaciones satelitales, aborda algunas de las preocupaciones inmediatas sobre la descentralización y la comunicación de nodos.
Impulsado por la comunidad y de código abierto : debe construirse sobre un modelo de código abierto, fomentando las contribuciones de la comunidad y haciendo que el código fuente esté disponible para su revisión, lo que puede fomentar la innovación y la confianza.
Compatibilidad y transición : debe diseñarse teniendo en cuenta la compatibilidad, de modo que admita plataformas de hardware existentes y pueda ejecutar aplicaciones heredadas dentro de módulos seguros, facilitando la transición desde los sistemas operativos tradicionales.
Lo que Windows es como plataforma de sistema operativo de propósito general y productividad la convertiría en una plataforma de software operativo altamente adaptada para el futuro de la humanidad en el espacio como su opuesto.
Integración de datos mejorada : una naturaleza modular permite la integración perfecta de varios sensores y fuentes de datos. Esta capacidad es crucial para SDA, donde los datos de radar, telescopios, satélites y otros sensores deben sintetizarse para proporcionar una imagen completa del entorno espacial.
Procesamiento y análisis de datos mejorados : el aspecto descentralizado de un nuevo sistema operativo puede facilitar el procesamiento de datos distribuidos, reduciendo el tiempo que lleva analizar grandes cantidades de datos en el dominio espacial. Un procesamiento de datos más rápido conduce a respuestas más oportunas a amenazas como desechos espaciales, maniobras adversas o fenómenos naturales.
Resiliencia y redundancia : para las operaciones militares, la resiliencia es fundamental, por lo que una estructura descentralizada puede ofrecer una mayor resiliencia contra ataques cibernéticos y fallas del sistema. Si un nodo falla, otros pueden tomar el control, asegurando operaciones SDA continuas.
Interoperabilidad : como las operaciones militares a menudo implican coaliciones, un sistema operativo descentralizado puede proporcionar protocolos e interfaces de comunicación estandarizados, lo que permite la interoperabilidad entre sistemas de diferentes países y servicios, lo cual es esencial para los esfuerzos conjuntos de SDA.
Adaptabilidad y escalabilidad : el diseño modular de un sistema operativo descentralizado permite una rápida adaptación a nuevos sensores, tecnologías o requisitos de misión. A medida que el dominio espacial evoluciona, también se pueden incorporar nuevos módulos para abordar las necesidades emergentes de SDA sin necesidad de revisar todo el sistema.
Seguridad : con una nueva arquitectura del núcleo, los protocolos de seguridad se pueden integrar estrechamente en cada módulo, proporcionando medidas de seguridad sólidas que son vitales para las operaciones militares. La naturaleza descentralizada también significa que es menos probable que un ataque a un módulo comprometa todo el sistema.
Eficiencia de costos : la estandarización en un sistema operativo modular puede generar ahorros de costos al reducir la necesidad de desarrollo de software personalizado para cada nueva iniciativa SDA. Esta eficiencia económica puede liberar recursos para otras necesidades críticas de defensa.
Ahora, analicemos el futuro de los sistemas operativos como Windows y Linux en un mundo de inteligencia artificial. ¿No son redundantes los sistemas operativos monolíticos donde podemos usar IA para crear aplicaciones, navegar por la web, responder preguntas complejas, realizar investigaciones y hacer compras con agentes automatizados a nuestra entera disposición?
Yo diría que sí. El enfoque en este momento es simplemente integrar los LLM y la IA en varias partes del sistema operativo o plataformas de productividad en lugar de diseñar la IA desde cero para que sea integral . Diferencia sutil.
Integración profunda versus complementos superficiales: los sistemas operativos actuales podrían integrar la IA como una capa adicional, mejorando ciertas funcionalidades. Sin embargo, es posible que este enfoque no aproveche todo el potencial de la IA. Un rediseño desde el nivel del kernel podría integrar la IA más profundamente en las funciones centrales del sistema operativo, lo que conduciría a un enfoque más integral.
Gestión y programación de recursos : los sistemas operativos tradicionales no están diseñados principalmente para las complejidades de las cargas de trabajo de IA. Rediseñar el kernel podría permitir una gestión más eficiente de los recursos (como CPU, GPU y memoria) para los procesos de IA, optimizando el rendimiento y el consumo de energía.
Seguridad y privacidad: la IA introduce nuevos desafíos de seguridad y privacidad. Un kernel rediseñado teniendo en cuenta la IA podría incorporar protocolos de seguridad más avanzados para afrontar estos desafíos, especialmente en el procesamiento de grandes volúmenes de datos confidenciales.
Procesamiento en tiempo real y computación perimetral : las aplicaciones de inteligencia artificial, en particular aquellas que involucran aprendizaje automático y procesamiento de datos en tiempo real, pueden beneficiarse del procesamiento de baja latencia y alta velocidad. Un rediseño a nivel de kernel podría optimizar estos procesos, especialmente para escenarios de computación de borde.
Operación autónoma y autorreparación : un kernel impulsado por IA podría permitir que el sistema operativo realice tareas de optimización y autorreparación autónomas, prediciendo y previniendo fallas del sistema y optimizando el rendimiento sin intervención humana.
Aceleración de hardware : las aplicaciones modernas de IA a menudo dependen de hardware especializado como GPU y TPU. Un kernel diseñado teniendo esto en mente podría proporcionar un mejor soporte y optimización para dicho hardware, mejorando el rendimiento de las aplicaciones de IA. Muy parecido a lo que Graphcore se propuso hacer con su IPU, pero no cumplió con el ajuste del mercado de productos y los altos requisitos de inversión de capital para continuar.
Compatibilidad con versiones anteriores y transición : un desafío importante al rediseñar el kernel para IA es mantener la compatibilidad con las aplicaciones y sistemas existentes. Esta transición requeriría una planificación cuidadosa y una implementación gradual.
Si adoptamos un enfoque revolucionario para el diseño de sistemas operativos, combinando la arquitectura de IA primero, la integración de IA a nivel de kernel y la descentralización como principios básicos, una nueva arquitectura de kernel y sistema operativo diferiría significativamente de los sistemas tradicionales como Windows y Linux. Por supuesto, ese cambio también requeriría superar importantes obstáculos en el camino en términos de desarrollo, adopción y compatibilidad con la tecnología y la infraestructura existentes. No es poca cosa, pero si abordas esto desde el ángulo de que construir un sistema operativo como este era una estrategia del Océano Azul, entonces ser paciente y nutrirlo durante un par de décadas es un juego y un premio más importante al que aspirar.
Un ejemplo perfecto de esto fue cuando Nintendo lanzó la Wii.
Estos son marcos conceptuales e ideas que he estado dando vueltas y Dios sabe si se mantendrán, pero si hay alguien por ahí asintiendo violentamente con la cabeza, ya sea un ingeniero de software o un inversor, derribe mi puerta y hablemos porque Tengo el deseo de hacer esto realidad.