Fuchsia: Vom Kernel bis zur Oberfläche – Googles neues Betriebssystem teilt sich in mehrere Layer

Veröffentlicht am von Jens
fuchsia 

Googles neues Betriebssystem Fuchsia lässt weiter auf sich warten, macht aber dennoch immer wieder durch kleinere Entwicklungsschritte von sich Reden. Das Herzstück des gesamten Projekts ist der Zircon-Kernel, der sich in der Layer-Architektur auf unterster Ebene befindet und noch sehr lange Bestand haben könnte. Aber die Layer-Architektur kennt natürlich noch weitere Ebenen, die wir uns heute einmal genauer ansehen wollen.


Obwohl Google nicht offiziell über Fuchsia spricht, haben viele Nutzer größere Hoffnungen und auch Interesse am neuen Betriebssystem. Auch Beobachter geben Fuchsia recht gute Chancen darauf, bei zukünftigen Betriebssystemen eine Rolle zu spielen und vielleicht sogar die Dominanz von Android fortzuführen. Dafür spricht, dass Google seit längerer Zeit mit Hochdruck an dem Projekt arbeitet und vergleichbare Projekte außerhalb der Hersteller-Ökosysteme derzeit nicht bekannt sind.

fuchsia logo

Das gesamte Fuchsia-Betriebssystem ist modular aufgebaut und soll den relativ einfachen Austausch einzelner Komponenten oder Ebenen ermöglichen bzw. es den Entwicklern vereinfachen, einzelne Teile der Architektur sehr leicht zu aktualisieren. Das hat viele Vorteile und soll unter anderem das in Android sehr mühsam eingeführte Konstrukt von Hause aus mitbringen und den universellen Einsatz von Fuchsia auf allen denkbaren Plattformen und Geräten ermöglichen.

Diese Modularität findet sowohl an der Oberfläche statt und erstreckt sich bis in jede kleinste dynamisch generierte Anwendung, reicht aber auch bis tief in den Kern des Betriebssystems. Zircon ist die unterste Ebene und hat das Potenzial, den heute in sehr vielen Betriebssystemen verwendeten Linux-Kernel zu ersetzen. Auch Android und Chrome OS setzen in tiefster Ebene auf den Linux-Unterbau, womit es auch für Googles Entwickler ein Novum ist.

Mehr Informationen zum Kernel findet ihr in diesem Artikel. Tatsächlich könnte diese schon bald nicht nur bei Fuchsia, sondern auch in anderen Betriebssystemen zum Einsatz kommen. Sogar Huawei hat Interesse daran gezeigt und bis jetzt kann nicht ausgeschlossen werden, dass Harmony OS und Fuchsia die gleichen Wurzeln haben.



fuchsia architektur

Oben seht ihr die einzelnen Layer von Fuchsia, die von unten nach oben gestapelt die Hierarchie vom Kernel bis zur Verbindung mit der Oberfläche zeigen. Alle Layer haben jeweils eigene Codenamen, die bereits seit langer Zeit Bestand haben und wohl auch in einer möglichen finalen Version nicht geändert werden. Als Endnutzer kommt man mit diesen aber sowieso niemals in Berührung, deswegen müssen sie nicht unbedingt auswendig gelernt werden 😉

Zircon
Zircon ist ein völlig neuer Kernel, der von Google von Grund auf neu entwickelt wurde und somit erstmals die alten Zöpfe zu Linux abschneidet. Der Kernel übernimmt die Kommunikation der Software mit der Hardware und steht somit auf der untersten Ebene. In frühen Versionen wurde Zircon auch als „Magenta“ bezeichnet. Zircon selbst hat mit dem reinen Fuchsia nicht viel zu tun und könnte auch für viele weitere Google-Betriebssysteme (vor allem bei Internet of Things-Geräten) zum Einsatz kommen.

Garnet
Garnet ist der unterste Layer des Fuchsia-Betriebssystems und übernimmt viele Basic-Aufgaben. Garnet verwaltet die Hardware-Treiber, regelt die gesamte Kommunikation, hält die zur Verfügung stehenden Anwendungen im Speicher bereit und ähnliche Dinge. Das Update-System Amber ist ein Teil von Garnet und läuft auf dieser Ebene. Hier findet also die gesamte Verwaltung und damit sehr wahrscheinlich auch die Kommunikation mit den Google-Servern zum App-Streaming und dem ständigen Datenaustausch statt.

Peridot
Peridot befindet sich schon auf der ersten App-Ebene. Hier werden die modularen Anwendungen verwaltet und nach den Bedürfnissen des Nutzers zusammengestellt. Die Synchronisierung der vom Nutzer verwendeten Anwendungen und Daten über Ledger findet auf dieser Ebene statt und auch die Assistant-Schnittstelle Kronk & Bucky ist hier zu Hause. Die Peridot-Ebene sorgt also dafür, dass der Nutzer auf allen Geräten stets die Inhalte vorfindet, die auch auf anderen Plattformen zu finden waren. Damit ist es der erste Layer, der von anderen Unternehmen für eigene Zwecke ausgetauscht werden könnte.

Topaz
Topaz ist die Schnittstelle mit dem Endnutzer und übernimmt die Darstellung der gesamten Oberfläche. Die Benutzeroberflächen Capybara (Desktop) oder Armadillo (Mobil) werden in dieser Ebene dargestellt und die Oberflächen der Anwendungen entsprechend angepasst. Beide wurden zwar mittlerweile zurückgezogen, aber auch zukünftige Oberflächen klinken sich an dieser Stelle ein. Auch Googles Geheimwaffe Flutter kommt erst auf dieser Ebene zum Einsatz, sodass auch „alte“ Apps aus den anderen Betriebssystemen ausgeführt und wie gewohnt genutzt werden können. Topaz dürfte dann wohl der Teil sein, der von den Herstellern am umfangreichsten angepasst oder ausgetauscht wird (so wie heute etwa die Android-Launcher).



Diese Architektur ist auch auf der Fuchsia Entwickler-Webseite zu finden und ein wichtiger Grundstein für den radikalen neuen Ansatz des Betriebssystems – und das wird auch dringend benötigt. Alle aktuellen Betriebssysteme wurden stets nur für eine Plattform entwickelt und tun sich ungemein schwer damit, auf einer anderen Fuß zu fassen. Das gilt für Windows genauso wie für Android oder auch die Apple-Betriebssysteme. Doch die digitale Welt ist in den letzten Jahren immer flexibler geworden.

Es braucht nun ein Betriebssystem, das für alle Arten von Geräten geeignet ist, vom kleinen Wearable über ein Embedded System bis hin zu Systemen mit üppiger Hardware. Weil das eigentlich nicht möglich ist, setzt Google auf die Modularität und fügt einfach nur die benötigten Bausteine zusammen, die für den jeweiligen Einsatz benötigt werden. Aus diesem Grund ist auch der Zircon-Kernel so bedeutend und vielleicht der Grundstein für viele neue Plattformen.

Nicht umsonst haben auch die großen Hersteller von smarten Geräten wie Samsung oder Huawei eigene Lösungen im Gepäck, die aber wohl nicht ganz so flexibel sind und auf eine offene Plattform setzen, so wie es Fuchsia tun könnte. Der Markt ist potenziell riesengroß und könnte den der Smartphones und Desktops noch weit in den Schatten stellen – denn gerade in puncto Smart Home oder Wearables werden immer mehr Geräte ein sehr einfaches und schlankes Betriebssystem benötigen.

Siehe auch
» Harmony OS: Huaweis neues Betriebssystem kann Android ersetzen & Googles Fuchsia zuvorkommen

» Squoosh: Kostenlose Google-App verkleinert und verändert Fotos blitzschnell und Offline im Browser


Teile diesen Artikel:

Facebook twitter Pocket Pocket

comment 1 Kommentare zum Thema "Fuchsia: Vom Kernel bis zur Oberfläche – Googles neues Betriebssystem teilt sich in mehrere Layer"

  • Für mich sieht, dass so aus als wolle Google mit der Modularität vor allem politische Probleme lösen und ich weiß nicht, ob das so eine gute Idee ist.
    Die hohe Modularität sorgt ja dafür, dass man im Gegensatz zum Linux-Kernel wesentlich mehr Schnittstellen hat für, die man Stabilität sicherstellen muss.
    Es besteht also die Gefahr, dass die Hardwaretreiber in Garnet nach dem Release nicht mehr weiterentwickelt werden.
    Wenn Google also nicht in Zukunft ältere Geräte von Zircon-Updates ausschließen möchte, dürfen die die API zu Garnet nicht verändern, was sich als schwierig erweisen könnte. Tuen sie es doch, haben sie das gleiche Problem wie unter Android.
    Das Problem mit dem Linux-Kernel bestand ja eher darin, dass sich die Androidentwickler geweigert haben ihre Patches in den Kernel einzupflegen sondern die lieber extern entwickeln und sich so über die Jahre immer weiter vom Upstreamkernel entfernt haben. Schlimmer noch die Gerätehersteller, die sich gleich ganz geweigert haben ihre Treiber open source zur Verfügung zu stellen. Stattdessen haben die sich eine Kernelversion herausgepickt und nur für diese entwickelt. Weil der Linuxkernel nun mal monolithisch ist, gibt es einfach keine stabile API für Treiber und diese sind ohne Anpassung meist nur für sehr wenige Versionen nutzbar.
    Klingt für mich also eher so als wolle Google mit dem modularen Ansatz dem eigenen Unvermögen und dem seiner Partner, mit dem Rest der Kernel-Community zusammenzuarbeiten, begegnen.

Kommentare sind geschlossen.