A pesar de que hay pocas novedades sobre Fuchsia OS, el proyecto sigue desarrollándose y es muy activo. Prueba: un mensaje de los desarrolladores sobre sus planes para implementar un mecanismo para ejecutar programas no modificados que se crean para Linux.
Este mecanismo se basa en una "capa" especial, que se llama starnix. Es ella quien proporciona compatibilidad con la ABI de Linux.
Las interfaces del sistema del kernel de Linux se implementan en un controlador que se ejecuta como un proceso para el sistema operativo Fuchsia. El proceso funciona en el espacio del usuario, traduciendo las solicitudes de los programas de Linux en llamadas a los subsistemas de SO correspondientes. Durante el desarrollo de este proyecto, muchos subsistemas deberán ser modificados para que todas las interfaces necesarias del sistema estén disponibles para los usuarios.
La arquitectura de la "capa", según los desarrolladores, se parece mucho a un subsistema similar para Windows, que se llama Subsistema de Windows para Linux. También se utiliza para traducir llamadas al sistema de Linux a llamadas al sistema de Windows.
El código de la capa intermedia se escribirá en Rust para mitigar los problemas de vulnerabilidad. Los desarrolladores creen que este lenguaje de programación ayudará a minimizar el riesgo de vulnerabilidades que pueden explotarse para elevar los privilegios de un proceso de Linux al propio proceso de Starnix. Para ello también se utilizarán los mecanismos de protección estándar Fuchsia.
Ejemplo: al acceder al sistema de archivos, la pila de red o el subsistema de gráficos, starnix traducirá las solicitudes, convirtiendo la ABI de Linux en la ABI del Sistema Fuchsia. Esto, a su vez, permitirá las mismas restricciones que se utilizan para los procesos normales en Fuchsia. También se utilizarán los mecanismos de autorización estándar de Linux.
Vale la pena señalar que los desarrolladores del sistema operativo han desarrollado la capacidad de ejecutar aplicaciones Linux en Fuchsia anteriormente. Pero usaron una implementación similar a la que se usa en Chrome OS. En general, puedes entenderlos, porque Fuchsia es una especie de proyecto favorito de Google. Anteriormente, por compatibilidad con Linux, se propuso utilizar la biblioteca Machina, que ejecuta el software de Linux en una máquina virtual especial, que se forma mediante un hipervisor basado en el kernel de Zircon y las especificaciones VirtIO.
Por lo que puede decir, la virtualización se utilizará en paralelo en Fuchsia, ya que no es tan fácil implementar la interfaz del sistema Linux. Lo más probable es que la virtualización se utilice junto con la "capa". En este caso, el kernel de Linux se ejecutará en una máquina virtual separada, lo cual no está mal, pero requiere recursos. Debido a la intensidad de los recursos, el equipo de Microsoft que trabajó en el Subsistema de Windows para Linux descartó el traductor y usó el kernel nativo de Linux en WSL 2.
Por cierto, los desarrolladores de Fuchsia no se comen el pan por nada: el sistema operativo ya proporciona el nivel de compatibilidad POSIX Lite, que funciona además del ABI del sistema Fuchsia. Todo esto le permite ejecutar varios programas Linux, pero necesita recompilar las aplicaciones o incluso modificar el código fuente. Uno de los problemas de POSIX Lite es la implementación incompleta de todas las funciones de POSIX.
El principal problema aquí es la falta de soporte para las llamadas para cambiar el estado global de los procesos, incluida la eliminación. En consecuencia, si hay una discrepancia con los conceptos de seguridad en Fuchsia, se prohíbe cambiar el estado global. Sin embargo, usar la versión lite de POSIX vale la pena cuando se transfieren aplicaciones de código abierto. Es cierto que existe un problema con la ejecución de programas que no tienen acceso al código.
En cuanto a Fuchsia, es un sistema operativo universal: aún se desconoce dónde se usará exactamente. Sin embargo, es compatible con casi cualquier tipo de dispositivo, incluidas estaciones de trabajo, teléfonos inteligentes, dispositivos IoT y productos electrónicos de consumo. El desarrollo se lleva a cabo teniendo en cuenta la experiencia de crear una plataforma Android y las deficiencias en el campo del escalado y la seguridad.
La base del nuevo sistema operativo es el microkernel Zircon, que, a su vez, se basa en los desarrollos del proyecto LK.
El proyecto ha estado relativamente activo durante varios años, con sugerencias publicadas en la red de que Google lo está desarrollando como alternativa a Android. Durante todo este tiempo, el sistema operativo siguió evolucionando. Por ejemplo, en 2017, se informó que el sistema operativo recibió una nueva interfaz de usuario, capacidades de línea de comandos y varias funciones más. En 2018, Google lanzó una nueva versión de su sistema operativo, que ya podría probarse.
Fuchsia tiene su propia GUI que está escrita en Dart usando el marco de flutter.
Además, el proyecto desarrolla:
- marco para la construcción de interfaces de usuario Peridot;
- Administrador de paquetes de Fargo;
- libc biblioteca estándar;
- sistema de renderizado Escher;
- El conductor de Vulkan Magma;
- Gestor compuesto escénico;
- sistemas de archivos MinFS, MemFS, ThinFS (FAT en lenguaje Go) y Blobfs
- Administrador de particiones FVM.
Para el desarrollo de aplicaciones, se proporciona soporte para C / C ++, se proporciona Dart, Rust también está permitido en los componentes del sistema, Go está permitido en la pila de red y Python se usa en el sistema de ensamblaje del lenguaje.
El administrador del sistema se utiliza para la carga, que trabaja con appmgr para crear el entorno de software inicial. Sysmgr y basemgr se utilizan para formar el entorno de arranque y el entorno de usuario, respectivamente.
Para proteger el sistema se utiliza un "sandbox", que no da acceso a los nuevos procesos a los objetos del kernel, además, no se les asigna memoria ni se ejecuta ningún código. El acceso a los recursos se gestiona mediante un sistema de espacio de nombres que define los permisos disponibles. El sandbox utiliza un marco que permite la creación de componentes especializados que pueden interactuar con otros componentes a través de IPC.
