Inferno das hotter than hell OS

Transkript

1 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

2 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 I I 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

3 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

4 Jetzt mal ehrlich: sehen die beiden Burschen so aus, als hätten sie nach UNIX genug von Betriebssystemen und danach nur noch Buchhaltungssoftware programmiert? 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

5 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

6 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

7 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

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