Inferno - das "hotter than hell" OS

Inferno – das “hotter than hell” OS
                                                   Bernd R. Fix 

Wenn man ein neues Betriebssystem entwickelt, dann braucht es nicht nur neue
Konzepte, sondern auch viele neue Namen: Für das OS selbst, für Protokolle,
Utilities und vieles andere mehr. Wenn der Architekt des neuen Systems dann
auch noch Dantes “Göttliche Kommödie” liest und als Inspiration wirken lässt,
dann kommen dabei auch schon mal ungewöhnlichere Namen heraus – wie eben
“Inferno”.
Das zeigt uns aber schon mal, das der Architekt eher Nerd als Marketing
Manager war:          der Name ist    werbe-technisch –   gelinde    ausgedrückt –
problematisch. “Das kann doch gar nicht funktionieren” sagt sich der Anwender
und denkt “Nomen est Omen”. Aber Nerds ist Dante eben wichtiger als Dollar.
Apropos Dante: Noch einen kleinen Merkspruch bevor es losgeht...

Um den Zugang zu Inferno zu finden, gehen wir mal in der Zeit zurück – sehr
weit zurück: Am Anfang war alles Eins...

Doch dann entdeckten die Menschen die Null, bauten einen Computer und
brauchten ein Betriebssystem.

Das war die Zeit, in der UNIX geboren wurde, sich über die Rechnerwelt
ausbreitete und viele Nachkommen hervorbrachte.

Schauen wir uns den Stammbaum von UNIX einmal in vereinfachter Form an:
Das ursprüngliche UNIX, in den Bell Laboratories von AT&T ab etwa 1968
entwickelt, war seiner Zeit weit voraus: Nicht nur weil es funktionierte (was man
von vielen anderen Betriebssystem der damaligen Zeit nicht unbedingt
behaupten konnte), sondern auch weil es völlig neue Konzepte wie z.B.
hierarchische Filesysteme einführte, für den Multi-User-Einsatz geeignet war und
selbst auf leistungsschwacher Hardware (das hiess damals so etwas wie PDP-7)
laufen konnte.

Inferno – das “hotter than hell” OS                                             Seite 1/8

Der letzte Punkt war schon dadurch bedingt, dass man den Entwickler-Nerds
keine bessere Hardware überlassen wollte und man das Projekt überhaupt nicht
so ganz ernst nahm. So wundert es nicht, dass dieses erste Ur-UNIX kein
kommerzielles Produkt war. Der Begriff “OpenSource” war damals noch nicht
erfunden und es gab auch nicht so viele Leute, die eine PDP-7 im Keller hatten –
aber im “Forscher-”Kreisen (sprich: Universitäten) wurde UNIX durchaus
wahrgenommen und quell-offen verteilt.

So wundert es nicht, dass die erste “Abspaltung” vom Ur-UNIX an der Universität
Berkeley passierte, wo das heute noch aktive BSD entstand. Da insgesamt die
Zahl der UNIX-Installationen aber stetig stieg, weckte das auch das kommerzielle
Interesse, unter anderem natürlich bei AT&T, die UNIX ja sozusagen erfunden
hatten. Mit “UNIX System III” steigt AT&T in den kommerziellen UNIX-Markt ein.

Die zweite Generation besteht nur aus UNIX-Varianten, die heute praktisch nicht
mehr relevant oder tatsächlich schon ausgestorben sind.

Erst die dritte Generation hat wieder lebende Mitglieder.

Wer Linux vermisst: Linux basiert auf keiner Quellcode-Linie und gehört deshalb
wie andere Kandidaten (Minix) nicht in diesen Stammbaum. Linux ist vielleicht
am ehesten so etwas wie eine “Cleanroom”-Implementation von UNIX SysV.

Spätestens mit dem Aufkommen der ersten kommerziellen UNIX-Varianten (die
natürlich Closed-Source waren) bestand die Notwendigkeit, UNIX so etwas wie
einer Standardisierung zu unterwerfen, damit die verschiedenen Entwicklungen
nicht zu sehr auseinander laufen und Software (auf Quellcode-Ebene) portabel
bleibt. Es gründete sich POSIX, ein Konsortium von Firmen, die UNIX vertrieben.

Damit war aber auch das “Grundkonzept” von UNIX festgeschrieben – jedes OS,
das nur einige Konzepte von UNIX übernahm, aber grundlegende Sachen
grundlegend anders machte, war – wie zum Beispiel DOS oder Windows -
dadurch per Definition auch kein UNIX mehr.

Inferno – das “hotter than hell” OS                                       Seite 2/8

Dieser UNIX-Stammbaum umspannt 40 Jahre, so dass die Frage: “Ist dies
Innovation? Oder nur eine langsame Evolution?” durchaus berechtigt ist. Meine
ernüchternde Antwort darauf ist: “Ja, es ist leider nur eine Evolution.” Und im
technischen Bereich bedeutet das auf lange Zeit                 das Todesurteil:    Die
technologische Entwicklung schreitet heute so schnell voran, dass ein System,
dass sich nur evolutionär entwickelt, auf Dauer nicht überleben wird.
Aber keine Panik: Wenn für UNIX alles gut läuft, dann gibt es noch ein paar UNIX-
Systeme, die den Epoch Time Overflow im Jahr 2038 live erleben...

Wenn es also einen Fluch der UNIX-Gene gibt, was ist dann diese UNIX-Gen, das
andere Betriebssysteme nicht haben?
[...]
Es ist das Konzept, Ressourcen (vor allem interne und externe Hardware-
Komponenten) wie Dateien im Filesystem zu behandeln; die Steuerung von
Ressourcen geschieht dabei jedoch durch einen getrennten Mechanismus (ioctl).

Als Beispiel für eine solche Ressource wollen wir uns mal die serielle Schnittstelle
ansehen (in Linux als /dev/ttyS0 definiert). Dafür gibt es einen Kernel-Treiber,
der mit der entsprechenden Hardware interagiert.
Wollen wir jetzt Zeichen über die serielle Schnittstelle empfangen oder senden,
können      wir    ganz      normale   Dateioperationen   (Lesen/Schreiben)   auf   der
entsprechenden Ressourcen-Datei ausführen – das vereinfacht die Anwendungs-
Entwicklung natürlich ungemein, da man sich mit den Internas der Ressource
nicht auseinandersetzen muss.
Um aber die Schnittstelle zu steuern – also zum Beispiel um die Baudrate
einzustellen oder festzulegen, wie Paritätsbits zu handhaben sind – müssen wir
ioctl-Aufrufe auf der Serial-Schnittstelle verwenden.

Dieses Grundkonzept wurde mit dem Ur-UNIX Anfang der 70'er Jahre eingeführt,
hier sehen wir die beiden “Erfinder” bei der Arbeit (Ken Thompson stehend,
Dennis Ritchie am Terminal). Kennt noch jemand den Rechner im Hintergrund?
[...]

Inferno – das “hotter than hell” OS                                            Seite 3/8

Jetzt mal ehrlich: sehen die beiden Burschen so aus, als hätten sie nach UNIX
genug von Betriebssystemen und danach nur noch Buchhaltungssoftware pro-
grammiert? Wohl kaum...

Aber UNIX grundlegend weiter zu entwickeln, war nach POSIX auch nicht möglich
– das wäre dann kein UNIX mehr gewesen. Aber Thompson und Ritchie
erkannten, das UNIX noch kein konsequent zuende gedachtes System war und so
etwas ist für Nerds eine schlimme Beleidigung. Also arbeiteten sie daran, die
Unvollkommenheit von UNIX zu überwinden: Alles, aber auch wirklich alles, ist
ein File – auch die Steuerung von Ressourcen. Und so entstand Plan9...

“Plan 9 From Outer Space” - der unbestritten schlechteste SciFi-Film aller Zeiten
stand hier Pate für den Namen des Betriebssystems. Wer den Film nicht kennt,
hier ein Trailer:

Ausser dem Namen haben Plan9 und der Film wenig gemeinsam, im Gegenteil:
Der Film hat gezeigt, dass man alles falsch machen kann und trotzdem berühmt
wird, während Plan 9 alles richtig macht und trotzdem relativ unbekannt bleibt.

Machen wir uns mit einigen Beispielen zuerst einmal klar, was “alles ist ein File”
in Plan9 bedeutet: [Beispiele]

Natürlich gehen die neuen Konzepte von Plan 9 über die “alles ist ein
File”-Strategie hinaus, deshalb wollen wir uns diesen neuen Konzepten näher
zuwenden:

Zuerst einmal ersetzt Plan 9 das Root Filesystem, das jedes UNIX zum
Hochfahren benötigt durch einen sogenannten Namespace:

Ein Namespace ist eine hierarchische Struktur von Namen. Files (Blätter des
Baumes) und Pfade (Directory-Abfolge) werden dabei in üblicher Schreibweise
dargestellt. Die logische Sicht auf einen Namespace ist praktisch identisch mit
der logischen Sicht auf ein Filesystem.

Inferno – das “hotter than hell” OS                                        Seite 4/8

Aus physikalischer Sicht gibt es aber einen wesentlichen Unterschied: Der
Namespace ist virtuell (in-memory) und nicht mehr an eine Hardware (Festplatte
o.ä.) gebunden. Das hat enorme Konsequenzen: Im Gegensatz zum Root
Filesystem, das ein Singleton ist und für alle Prozesse in UNIX global sichtbar ist,
gibt es in Plan 9 beliebig viele Namespaces: genau einen für jeden Thread, wobei
ein Thread (i.d.R.) den Namespace seines Erzeugers als Kopie erbt.

Das bedeutet, das “mount” keine privilegierte Operation mehr ist, das sie ja nur
den individuelle Namespace manipuliert. Allerdings mountet der Befehl auch
nicht mehr eine Hardware-Ressource, sondern einen “Server” - mehr dazu
nachher. Mit “bind” können (gemountete) Pfade im Namespace übereinander
gelegt werden, um eine einheitliche Namespace-Struktur zu erhalten (ähnlich
UnionFS in Linux). Das Ganze ist aus Sicherheits-Sicht natürlich eine super Sache
– jeder Prozess und Anwender bekommt einen Namespace zugeteilt, in dem nur
das enthalten ist, was der Prozess/User sehen darf. Für gemeinsam benutzte
Namespaces gibt es weiterhin Permissions, Gruppen und Owner.

Der “Kern” von Plan 9 ist das Protokoll, mit dem Namespaces (lokal und entfernt)
manipuliert werden können; das Protokoll wird oft als “Styx” oder “9P”
bezeichnet. Das Protokoll werden wir uns gleich anschliessend genauer ansehen.

Der Kernel ist grob gesehen nur so etwas wie ein lokaler Styx-Handler, der die
lokalen Namespaces verwaltet (und ggf. exportiert). Alle Bibliotheksfunktionen in
Plan 9 übersetzen den jeweiligen Request in Styx-Messages, die vom Kernel
abgearbeitet werden.

Daraus resultiert ein kleiner, leicht protierbarer Kernel, der nur etwa 10% des
Syscall-Umfangs eines Linux-Kernels hat und zudem auch noch immanente
Sicherheit bietet.

Grundlage des Ganzen ist wie gesagt das Namespace-Protokoll “Styx” bzw. “9P”:
Es ist ein NFS für Namespaces, aber sehr viel einfacher und vor allem mit mehr

Inferno – das “hotter than hell” OS                                         Seite 5/8

Sicherheits-Funktionen:
    ●   Server und Client müssen sich mit Zertifikaten authentifizieren.
    ●   Die Datenübertragung erfolgt verschlüsselt und integritätsgesichert.
    ●   Es hat nur ~30 Befehle, die wie erwähnt so etwas wie das Kernel-API sind

Mit diesem Protokoll sind jetzt nicht nur die lokalen Ressourcen ein File, sondern
auch die Ressourcen anderer Computer in einem 9P-Netzwerk. Gemeinhin nennt
man so etwas dann ein Netzwerk-Betriebssystem.

Vorhin haben wir gesehen, dass Plan 9 das Root Filesystem durch Namespaces
ersetzt. Natürlich gibt es auch weiterhin Filesysteme für permanente Files auf
Festplatte o.ä., aber diese sind eben kein “Root FS” mehr und werden vom
Kernel-Mount-Device per Styx bearbeitet. Und auch das neue Filesystem von Plan
9 ist sehr innovativ:

Das Filesystem heisst Fossil und ist ein sogenanntes Snapshot-Filesystem. Das
OS erzeugt periodisch (z.B. täglich) einen Snapshot des aktiven Filesystems. Der
Anwender kann die Snapshots mounten und so einfach auf ältere Versionen von
Dateien zugreifen. So ist es in Plan 9 sehr einfach, z.B. alte Versionen von
Programmen auszuführen.

Um Snapshots zu archivieren gibt es in Plan9 den Venti-Server, der auch mit
überraschenden Konzepten aufwartet. Dateien werden blockweise archiviert,
wobei ein Block zwischen 512 Bytes und 56kB gross ist; grössere Dateien werden
in mehrere Blöcke aufgeteilt. Die Ablage-Addresse eines Blockes im Repository
wird jetzt über den Hashwert der Blockdaten berechnet, d.h. gleicher Inhalt =
gleicher Hashwert = gleiche Repository-Addresse. Damit werden automatisch
gleiche Dateien im Archiv nur einmal gespeichert und können nie mit anderen
Daten überschrieben werden, denn andere Daten = anderer Hashwert = andere
Ablage-Addresse. So etwas nennt man dann revisions-sichere Archivierung.

Wer sich jetzt an die Centera von EMC erinnert fühlt, hat Recht: Das ist das
gleiche Prinzip – und wer von wem abgekupfert hat, kann sich jeder selbst

Inferno – das “hotter than hell” OS                                        Seite 6/8

ausrechnen. In Plan9 jedenfalls ist das Open-Source und umsonst dabei, eine
Centera ist deutlich teurer ;-)

Plan9 spielt seinen Vorteil des Netzwerk-Betriebssystem natürlich erst in
(grossen) Netzwerken aus, in denen viele Computer ihren Dienst tun. Eine
“typische” Plan9-Installation besteht also aus einem schnellen Backbone-Netz,
an dem die Rechenknechte hängen. Ein Gateway schafft den Übergang in ein
LAN, an dem die Terminals hängen (diskless). Auch der Übergang ins Internet
passiert im Gateway und erlaubt auch die Nutzung von entfernten Terminals.

Aber natürlich kann man auch Stand-alone Plan9-Installationen haben (Xen sei
Dank!) und neben anderen Betriebssystemen nutzen. Oder es im heimischen
Umfeld benutzen, wie folgendes Beispiel zeigen soll:

Wir haben einen Computer mit Internetanbindung (rechts) und ein kleines Gerät,
dass nur eine Infrarot-Schnittstelle besitzt (links). Wenn wir jetzt mit dem kleinen
Gerät ins Internet wollen, gibt es ein Problem: das Gerät besitzt keinen IP-Stack,
wohl aber die grosse Maschine. Mit zwei Befehlen können wir den IP-Stack über
die Infrarot-Verbindung in das kleine Gerät importieren. Danach sind wir “drin im
Internet” und können es nutzen.

Zum Abschluss des Themas “Plan9” noch eine kurze Liste mit wenig bekannten
Fakten zum Betriebssystem: Plan9 ist der Erfinder des UTF-8-Zeichensatzes und
das erste OS, dass UTF-8 auch konsequent nutzt. Da es ein so schönes und
schlankes Netzwerk-Betriebssystem ist, wundert es auch nicht, das Rechner-
Cluster und Supercomputer gerne darauf zurückgreifen.

War das jetzt schon das Ende? Sind die Architekten von UNIX und Plan9 danach
in Rente gegangen. Weit gefehlt – denn man kann Gutes immer noch besser
machen. Wenn schon Ressourcen geteilt werden, warum dann nicht auch
Programme in dieses Konzept einbinden?

Inferno – das “hotter than hell” OS                                         Seite 7/8

So passierte der nächste Schritt und Inferno wurde aus der Taufe gehoben.
Komisch, die Namen der Architekten kennen wir schon vor irgendwo her...

Inferno übernimmt alle Basiskonzepte von Plan9 – alles, was ich vorher über
Plan9 gesagt habe, gilt auch bei Inferno. Der Unterschied liegt in der
Applikationsentwicklung: Während Plan9 mit einem C-Compiler aufwartet und
damit     wie     unter     UNIX      programmiert   wird,   besitzt   Inferno   eine     neue
Programmiersprache namens Limbo. Diese ist nicht ganz objekt-orientiert
(Module), hat aber interessante Konstrukte (Channels wie in Occam) für
netzwerk-taugliche (verteilte) Applikationen und die VM ist direkt in den Kernel
integriert. Alle Utilities wie shell, window manager und development tools sind in
Limbo programmiert. Vereinfacht lässt sich sagen: Inferno ist Plan9 mit einer
Kernel VM.

Als Inferno entwickelt wurde, haben die Architekten kurzzeitig überlegt, Java als
Programmiersprache zu nehmen. Leider war damals Java noch sehr jung (pre-
1.0) und entsprach auch nicht genau den Vorstellungen – das Channel Paradigma
fehlte zum Beispiel. Irgendwo ist das schade, weil Inferno heute sicher bekannter
wäre, wo es doch so viele Java-Programmierer gibt. Aber auf der anderen Seite
auch nicht, denn die neuen Konzepte möchte man auch nicht missen.

Inferno – das “hotter than hell” OS                                                     Seite 8/8