Malgré le fait qu'il y ait peu de nouvelles sur Fuchsia OS, le projet continue de se développer et est très actif. Preuve - Un message des développeurs sur leurs plans pour implémenter un mécanisme pour exécuter des programmes non modifiés qui sont construits pour Linux.
Ce mécanisme est basé sur une "couche" spéciale, appelée starnix. C'est elle qui assure la compatibilité avec l'ABI Linux.
Les interfaces système du noyau Linux sont implémentées dans un gestionnaire qui s'exécute en tant que processus pour le système d'exploitation Fuchsia. Le processus fonctionne dans l'espace utilisateur, traduisant les requêtes des programmes Linux en appels aux sous-systèmes OS correspondants. Au cours du développement de ce projet, de nombreux sous-systèmes devront être modifiés afin que toutes les interfaces système nécessaires soient disponibles pour les utilisateurs.
L'architecture de la «couche», selon les développeurs, ressemble fortement à un sous-système similaire pour Windows, qui est appelé sous-système Windows pour Linux. Il est également utilisé pour traduire les appels système Linux en appels système Windows.
Le code intercalaire sera écrit en Rust afin d'atténuer les problèmes de vulnérabilité. Les développeurs estiment que ce langage de programmation contribuera à minimiser le risque de vulnérabilités qui pourraient être exploitées pour élever les privilèges d'un processus Linux au processus starnix lui-même. Pour cela, les mécanismes de protection standard Fuchsia seront également utilisés.
Exemple: lors de l'accès au système de fichiers, à la pile réseau ou au sous-système graphique, starnix traduira les requêtes, convertissant l'ABI Linux en ABI du système Fuchsia. Ceci, à son tour, permettra les mêmes restrictions que celles utilisées pour les processus normaux dans Fuchsia. Les mécanismes d'autorisation standard de Linux seront également utilisés.
Il est à noter que les développeurs d'OS ont développé la possibilité d'exécuter des applications Linux sous Fuchsia plus tôt. Mais ils ont utilisé une implémentation similaire à celle utilisée dans Chrome OS. En général, vous pouvez les comprendre, car Fuchsia est une sorte de pet-project de Google. Auparavant, pour la compatibilité avec Linux, il était proposé d'utiliser la bibliothèque Machina, qui exécute le logiciel Linux dans une machine virtuelle spéciale, qui est formée à l'aide d'un hyperviseur basé sur le noyau Zircon et les spécifications VirtIO.
Pour autant que vous puissiez le dire, la virtualisation sera utilisée en parallèle dans Fuchsia, car il n'est pas si facile d'implémenter l'interface système Linux. Très probablement, la virtualisation sera utilisée en conjonction avec la «couche». Dans ce cas, le noyau Linux fonctionnera dans une machine virtuelle séparée, ce qui n'est pas mauvais, mais nécessite des ressources. C'est en raison de l'intensité des ressources que l'équipe Microsoft qui a travaillé sur le sous-système Windows pour Linux a abandonné le traducteur et a utilisé le noyau Linux natif dans WSL 2.
Au fait, les développeurs de Fuchsia ne mangent pas leur pain pour rien - le système d'exploitation fournit déjà le niveau de compatibilité POSIX Lite, qui fonctionne en plus de l'ABI du système Fuchsia. Tout cela vous permet d'exécuter un certain nombre de programmes Linux, mais vous devez recompiler les applications ou même modifier le code source. L'un des problèmes avec POSIX Lite est l'implémentation incomplète de toutes les fonctionnalités POSIX.
Le principal problème ici est le manque de support pour les appels à changer l'état global des processus, y compris kill. En conséquence, en cas de divergence avec les concepts de sécurité en Fuchsia, il est interdit de changer l'état global. Cependant, l'utilisation de la version allégée de POSIX est payante lors du portage d'applications open source. Certes, il y a un problème avec les programmes en cours d'exécution qui n'ont pas accès au code.
Quant à Fuchsia, c'est un système d'exploitation universel: où exactement il sera utilisé est encore inconnu. Cependant, il est compatible avec presque tous les types d'appareils, y compris les stations de travail, les smartphones, les appareils IoT et l'électronique grand public. Le développement est réalisé en tenant compte de l'expérience de création d'une plate-forme Android et des lacunes dans le domaine de la mise à l'échelle et de la sécurité.
La base du nouveau système d'exploitation est le micro-noyau Zircon, qui, à son tour, est basé sur les développements du projet LK.
Le projet est relativement actif depuis plusieurs années, avec des suggestions publiées sur le réseau selon lesquelles Google le développe comme une alternative à Android. Pendant tout ce temps, le système d'exploitation a continué d'évoluer. Par exemple, en 2017, il a été signalé que le système d'exploitation avait reçu une nouvelle interface utilisateur, des capacités de ligne de commande et plusieurs autres fonctionnalités. En 2018, Google a publié une nouvelle version de son OS, qui pourrait déjà être testée.
Fuchsia a sa propre interface graphique qui est écrite en Dart en utilisant le framework Flutter.
De plus, le projet développe:
- cadre pour la construction d'interfaces utilisateur Peridot;
- Gestionnaire de packages Fargo;
- bibliothèque standard libc;
- système de rendu Escher;
- Pilote Vulkan Magma;
- Gestionnaire composite scénique;
- systèmes de fichiers MinFS, MemFS, ThinFS (FAT en langage Go) et Blobfs
- Gestionnaire de partition FVM.
Pour le développement d'applications, la prise en charge de C / C ++, Dart est fournie, Rust est également autorisé dans les composants système, Go est autorisé dans la pile réseau et Python est utilisé dans le système d'assemblage du langage.
Le gestionnaire système est utilisé pour le chargement, qui fonctionne avec appmgr pour créer l'environnement logiciel initial. Sysmgr et basemgr sont utilisés pour former respectivement l'environnement de démarrage et l'environnement utilisateur.
Pour protéger le système, un "sandbox" est utilisé, qui ne donne pas aux nouveaux processus l'accès aux objets du noyau, de plus, aucune mémoire n'est allouée pour eux et aucun code n'est exécuté. L'accès aux ressources est géré par un système d'espace de noms qui définit les autorisations disponibles. Le bac à sable utilise un cadre qui permet la création de composants spécialisés qui peuvent interagir avec d'autres composants via IPC.
