Spätestens seit sich die Open Software Foundation (OSF) dazu entschlossen hat, ihre Unix-Derivate OSF/1 und demnächst auch OSF/2 auf der Basis der sogenannten Mach-Technologie zu errichten, ist das Betriebssystem in aller Munde. Markus Kolland* geht auf die Architekturen der Versionen 2.5 und 3.0 ein, beschreibt den Unterschied zu herkömmlichen Unix-Systemen und erläutert die Marktchancen des Betriebssystems.

Die Architektur von Informationssystemen war in den letzten Jahren starken Veränderungen unterworfen. Einerseits wurden Hardwarebausteine entwickelt, die auf kleinstem Raum eine immer mächtigere Funktionalität integrieren. Dies ermöglichte eine wesentliche Steigerung der Leistungsfähigkeit heutiger Rechner und die Entwicklung neuer Hardware-Architekturen (zum Beispiel Multiprozessoren). Zum anderen lösen verteilte Systeme aus Rechnern mit unterschiedlichen Eigenschaften die zentrale Großrechenanlage in immer mehr Bereichen ab.

Neue Technologien für bestehende Betriebssysteme

Diese Entwicklungen spiegeln sich auch in der Evolution des Unix-Betriebssystems wider. In den letzten Jahren integrierten Entwickler in bestehende Unix-Kerne zusätzliche Funktionalität, um den veränderten Anforderungen an ein Betriebssystem - wie zum Beispiel die Unterstützung von Verteilung oder auch Echtzeitfähigkeit - zu entsprechen.

Die nächste Stufe wird nun mit der Entwicklung von Betriebssystemen beschritten, welche die oben beschriebenen Rechnerarchitekturen direkt durch neue Mechanismen unterstützen und so die für unterschiedliche Aufgabenfelder geforderte Funktionalität integriert anbieten. Zur Sicherung getätigter Investitionen ist dabei Kompatibilität zu Unix gefordert.

Das Betriebssystem Mach stellt den derzeit wohl populärsten relevanten Vertreter dieser Klasse neuer Betriebssysteme dar. Daher ist die Frage zu klären, ob Mach wirklich das Unix-Konzept der Zukunft ist, als das es einige sehen. Bei der Entwicklung von Mach geht es nicht um die Einführung eines Betriebssystems mit neuen Schnittstellen oder Werkzeugen etc., sondern vielmehr um eine neue Technologie für existierende Betriebssysteme, insbesondere für Systeme aus der Unix-Welt.

Kompatibilität zu existierenden Standards ist also das oberste Entwicklungsziel. Soll die Bedeutung des Mach-Ansatzes geklärt werden, so muß klar sein, welche Funktionalität in Zukunft von Betriebssystemen gefordert wird, wo diesbezüglich die Schwächen heutiger Systeme liegen und in welcher Form Mach die gestellten Anforderungen erfüllt.

Anforderungen an Betriebssysteme unterscheiden sich je nach Sichtweise. Endbenutzer sind vor allem an hoher Leistungsfähigkeit und Skalierbarkeit für zukünftige Aufgaben interessiert. Aus Gründen der Wirtschaftlichkeit spielen aber auch Aspekte der Datensicherheit und der Zuverlässigkeit zunehmend eine große Rolle, zumal Informationssystemen in den Unternehmen immer häufiger entscheidende Bedeutung für den organisatorischen und technischen Ablauf zukommt.

Drei Strömungen bei den Entwicklungstrends

Für Softwarehäuser, die bestehende Anwendungen auf ein Betriebssystem portieren oder neue Applikationen entwickeln, sind vor allem Standardschnittstellen wichtig. Diese erleichtern die Entwicklungsarbeit und machen Softwareprodukte einem erweiterten Anwenderkreis zugänglich. Doch auch die Innovationskraft eines Betriebssystems ist für Softwarehersteller interessant, da Entwicklungen für Betriebssysteme mit kurzem Lebenszyklus kaum kommerzielle Erfolge versprechen.

Aus Herstellersicht ist dagegen die effiziente Ausnutzung unterschiedlicher Hardware-Architekturen von zentraler Bedeutung: Kann das jeweilige System an die technologischen Innovationen auf der Hardwareseite angepaßt werden? Auch die Portierbarkeit eines Betriebssystems spielt eine wesentliche Rolle, denn bei der Einführung neuer Hardware entstehen hier hohe Kosten. Ein letztes wichtiges Argument für den Hersteller ist der Aspekt

der Integration. Neue Systeme müssen mit den existierenden Produkten in ein Gesamtsystem eingefügt werden können, das die einzelnen Betriebssysteme unterstützen.

Bei den Entwicklungstrends der letzten Jahre auf dem Betriebssystem-Sektor lassen sich drei wesentliche Strömungen identifizieren. Zum einen werden existierende Allzweck-Betriebssysteme um zusätzliche Schichten erweitert, ein Trend der vor allem im Bereich der verteilten Informationsverarbeitung festzustellen ist. Beispiele für derartige Schichten sind die im Rahmen von Esprit (European Strategic Program for Research in Information Technology) entwickelten verteilten Systemplattformen Comandos und ISA, die wie das NCS von Apollo jeweils auf Unix-Systeme aufsetzen und zusätzliche Verteilungs- und Netzwerkfunktionen zur Verfügung stellen.

Ein anderer Ansatz verfolgt die Integration spezifischer Funktionalität in bestehende Betriebssystem-Kerne. Typische Beispiele für diese Vorgehensweise sind die Echtzeiterweiterungen des Unix-Kerns, zum Beispiel Sorix, oder die Ergänzungen für verteilte Dateisysteme etwa Sun NFS. Die dritte Kategorie, zu der auch das Mach-System in der Version 3 zählt geht von einer kleinen gemeinsamen Basisfunktionalität - dem sogenannten Mikrokern - aus und leitet daraus spezialisierte, das heißt auf bestimmte Einsatzgebiete zugeschnittene, Betriebssysteme ab. Hierzu zählt die Familie der Tron-Systeme und die auf Basis des Mach-Mikrokerns implementierten Betriebssystem-Schnittstellen.

Mach wird seit 1985 an der Carnegie Mellon Universität im amerikanischen Pittsburgh entwickelt. Entsprechende Konzepte wurden unter anderen Bezeichnungen bereits in Vorläuferprojekten realisiert. Bei Mach kamen schließlich wesentliche Gesichtspunkte der Unix-Kompatibilität und der minimalen Betriebssystem-Kernbasis hinzu. So wurden zuerst wesentliche Mechanismen aus Bereichen wie der Speicherverwaltung oder der Kommunikation in einen bestehenden BSD-4.2-Kern integriert, wobei jedoch die Binärkompatibilität zu diesem Unix-System erhalten blieb.

Daraus entstand die seit 1989 verfügbare Mach-Version 2.5, die heute unter anderem Basis des OSF/1-Betriebssystems von der Open Software Foundation ist. Die Umsetzung der Mikrokern-Architektur und die Integration zusätzlicher Mechanismen erfolgt seit 1989 im Rahmen der Mach-Version 3.0, die seit kurzem in einem ersten Release auf dem Markt ist.

Was sind nun die wesentlichen Designmerkmale des Mach-Systems? Wodurch hebt sich das Betriebssystem von herkömmlichen Unix-Systemen ab? Ein wesentliches Entwicklungsziel war die effiziente Unterstützung verschiedenster Hardware-Architekturen, Uni- und Multiprozessoren sowie vernetzter Systeme. Vor allem die Möglichkeit, verschiedene Multiprozessor-Architekturen - zum Beispiel eng gekoppelt mit gemeinsamem Speicher oder eng gekoppelt mit nicht direkt addressierbarem Speicher - in einer gemeinsamen virtuellen Speicherverwaltung zu unterstützen, ist ein wesentliches Mach-Merkmal.

Das System läßt aber auch allgemeine Hardwareheterogenität bezüglich Befehlssatz, Datenrepräsentation und Netzarchitektur zu. Mach folgt einem Bausteinansatz. Ein minimaler sicherer Kern stellt die für die meisten Anwendungsfelder benötigte Grundfunktionalität zur Verfügung (Kommunikation, Speicherverwaltung). Höhere Betriebssystem-Dienste setzen darauf auf und stellen - unter Umständen binärkompatibel - diverse Betriebssystem-Schnittstellen zur Verfügung.

Binärkompatibel zu Unix BSD 4.2

Mach und die entsprechenden Dienste sind objektorientiert aufgebaut. Dies erleichtert die Wiederverwendbarkeit sowie Erweiterbarkeit und erlaubt eine flexible Konstruktion des Systems. Ein wesentlicher Aspekt bei der Entwicklung von Mach ist die Integration von Mechanismen, um Anforderungen spezifischer Anwendungsfelder effizient zu unterstützen. So lassen sich sichere, verteilte oder parallele Systeme implementieren.

Wie bereits erwähnt, ist Kompatibilität zu vorhandenen Betriebssystemen oberstes Ziel. Mach bietet Binärkompatibilität zu Unix BSD 4.2 und enthält Konzepte zum Aufsetzen beliebiger Betriebssystem-Schnittstellen (binärkompatibel).

Bei der Entwicklung der Mach-Version 2.5 sollte ein bestehender BSD-4.2-Kern hinsichtlich oben genannter Designmerkmale modifiziert werden. So implementieren die Entwickler eine vollkommen neue virtuelle Speicherverwaltung, welche insbesondere den unterschiedlichen Speicherarchitekturen bei Multiprozessoren Rechnung trägt. Auch die Aktivitätsverwaltung wurde zugunsten einer effizienten Multiprozessor-Unterstützung modifiziert.

Hinzu kamen auch effiziente und für den Einsatz in LANs geeignete Kommunikationsmechanismen. So erfolgt die Kommunikation in Mach über sogenannte Ports, die eine vollkommen transparente Adressierung, unabhängig von Art und Lage der Partner, erlauben. Die restliche Funktionalität - zum Beispiel das Filesystem - wurde vom BSD-Kern übernommen.

Die Mach-3.0-Architektur basiert auf dem Mikrokern. Darunter ist ein minimaler Betriebssystem-Kern zu verstehen, der nur grundlegende, für alle Anwendungsgebiete eines Systems interessante Funktionalitäten anbietet. Dazu gehört hier die bereits in der Version 2.5 implementierte, ortstransparente und effiziente Kommunikation über Ports. Auch die Aufspaltung des Prozeßkonzeptes in Tasks, die Ausführungsumgebung eines Prozesses (Speicherbereiche, offene Dateien etc.), und die Threads, die Aktivitätsträger (Register, Stack etc.), ist ein wesentliches Konzept des Mikrokerns.

Mach-Mikrokern bietet "Transparent libraries"

Damit kann die Umschaltung zwischen Aktivitäten auf Multiprozessoren effizient implementiert werden. Die virtuelle Speicherverwaltung, ebenfalls Bestandteil eines Mikrokerns, berücksichtigt im Fall von Mach insbesondere heterogene Speicherarchitekturen von eng gekoppelten Multiprozessoren. Außerdem ist die Integration von Sicherheits- und Verteilungsmechanismen (Authentifizierung, Remote Procedure Call) typisch für Mikrokerne und auch Mach bietet hier direkte Unterstützung.

Version 3.0 setzt dabei auf den heterogenen Hardwareplattformen der einzelnen Knoten im System auf. Es stellt den aufsetzenden Subsystemen (Betriebssystemen) Grundfunktionen zur Verfügung. Diese Funktionalität kann entweder direkt von Anwendungen genutzt werden, oder sie ist Basis für die Implementierung von Betriebssystem-Servern, von Subsystemen also, die aufsetzenden Applikationen existierende Betriebssystem-Schnittstellen (binär-) kompatibel anbieten.

Den Applikationen bleibt die Implementierung der Schnittstelle, zum Beispiel Unix verborgen. Der Mach-Mikrokern bietet hierfür besondere Unterstützung an, nämlich "Transparent libraries". Mit ihrer Hilfe ist es relativ einfach möglich, beliebige Betriebssystem-Schnittstellen auf den Mikrokern aufzusetzen. Dies führte zu einer ganzen Reihe von Betriebssystem-Server-Entwicklungen im Mach-Umfeld. Derzeit werden Server für Unix V.4, Unix BSD 4.3, OSF/1, OSF/2 und Secure implementiert.

Vor einer strukturellen Bewertung muß zuerst die Frage geklärt werden, welche Betriebssystem-Funktionalität verschiedene Anwendungsfelder in den nächsten Jahren fordern. Erst auf dieser Basis lassen sich konkrete Systeme evaluieren und zwar, indem untersucht wird, in welcher Form die geforderte Funktionalität angeboten wird. Diese Evaluierung und ein Vergleich mit herkömmlichen Unix-Systemen tragen einen wesentlichen Teil zur Klärung der Frage nach dem Unix-Konzept der Zukunft bei.

Künftige Betriebssysteme unterstützen Verteilung

Wie sehen nun die Anforderungen an zukünftige Betriebssysteme aus? Ein wesentlicher Aspekt ist die effiziente Unterstützung von Verteilung. Hierzu zählt eine ganze Reihe von Mechanismen, die vom betreffenden System direkt angeboten werden sollten. Transparenz ist in verteilten Umgebungen eine unabdingbare Forderung, sei es, daß die Kommunikation unabhängig vom Ort der Kommunikationspartners ist, daß Komponenten unbeeinflußt vom Fehlverhalten anderer Komponenten bleiben, oder daß die Replikation von Komponenten verborgen bleibt. Alle diese Aspekte werden von heutigen Unix-Systemen nur ungenügend unterstützt.

Auch die Heterogenität der Umgebung spielt hier eine Rolle. Verteilte Systeme bestehen in der Regel aus Hardwarekomponenten unterschiedlicher Hersteller. Ein Betriebssystem sollte auf all diesen Komponenten effizient ablauffähig sein, vor allem der Portierungsaufwand auf eine Zielhardware muß begrenzt bleiben. Unix bietet hier bereits sehr gute Ansätze (Herstellerunabhängigkeit). Neben der Verteilung ist der Gesichtspunkt der Kompatibilität für zukünftige Entwicklungen von ausschlaggebender Bedeutung.

Wichtig sind X/Open und Posix-Standards

Um die in Software getätigten Investitionen beim Anwender zu sichern, haben langfristig nur Systeme eine Chance am Markt, die kompatibel zu existierenden Standards sind. Hier ist vor allem Dingen Kompatibilität zu Unix (X/Open, Posix) gefragt. Wie bereits oben erwähnt, geht die Entwicklung von besonders leistungsfähiger Hardware immer mehr in Richtung Multiprozessor-Architekturen. Um auf der Anwenderseite deren Leistungsvorteile möglichst vollständig nutzen zu können, müssen Betriebssysteme in ihrem Aufbau und ihren Mechanismen derartige Architekturen effizient unterstützen.

Unix hat hier schwerwiegende Nachteile, da zum Beispiel aufgrund der langen Prozeßwechsel-Zeiten eine große Anzahl an Prozessoren nicht gewinnbringend ausgenutzt werden kann. Für Entwicklungen auf Basis eines gegebenen Systems ist die Verfügbarkeit von Werkzeugen für Software-Entwicklung, Systemverwaltung etc. Voraussetzung. Hier haben eingeführte Systeme natürlich Vorteile gegenüber Forschungssystemen wie Mach.

Gerade am Beispiel von Unix oder MS-DOS, in deren Umfeld dem Anwender eine Unmenge von Werkzeugen und Applikationen zur Verfügung steht, läßt sich die Wichtigkeit dieses Gesichtspunktes ablesen.

Zusätzlich gibt es noch eine Reihe von Anforderungen spezieller Anwendungsgebiete, welche in zunehmendem Maße von Allzweck-Betriebssystemen gefordert werden. Dazu gehören Sicherheitsmechanismen (Verschlüsselung, Authentifizierung) und die Unterstützung von Echtzeitanwendungen (Prioritäten, Aktivitätsverwaltung und Scheduling).

Gerade in diesen Punkten haben heutige Allzweck-Betriebssysteme enorme Mängel, die sich zum Teil nur unter sehr großem Aufwand beheben lassen (Implementierung von Echtzeit-Unix).

Am Beispiel der Aspekte Heterogenität, Unix-Kompatibilität und Verfügbarkeit von Softwarewerkzeugen soll Mach einer derartigen strukturellen Bewertung unterzogen werden, wobei der Verfasser keinen Anspruch auf Vollständigkeit erhebt.

Unterstützt Mach die Heterogenität? Wie oben bereits ausgeführt, besteht der Mach-Kern nur aus einer minimalen Basis von Grunddiensten. Höhere Dienste stehen als Server zur Verfügung, die auf den Kern aufsetzen. Somit sind die meisten Teile des Betriebssystems bereits vollkommen Hardware-unabhängig. Im Kern selbst findet eine strikte Trennung zwischen Hardware-abhängigen und -unabhängigen Teilen statt. Diese beiden Eigenschaften erleichtern wesentlich die Portierung auf diverse Hardwareplattformen.

Der Mach-Kernel bietet Betriebssystem-lnterfarces

Doch nicht nur Heterogenität auf der Hardwareseite findet in der Architektur von Mach seinen Niederschlag. Die Kommunikation zwischen Knoten in einem LAN wird im Kern auf der Basis unterschiedlicher Protokolle unterstützt (TCP/IP, UDP, VMTP), und die objektorientierte Strukturierung der Mach-Dienste nach dem Client-Server-Prinzip trägt dazu bei, die Heterogenität einzelner Komponenten zu verbergen.

Auf den Mach-Kern lassen sich diverse Betriebssystem-Schnittstellen (binär-) kompatibel aufsetzen. Dies erlaubt Heterogenität seitens der in einem verteilten System vorhandenen Betriebssysteme. Daß sich diese Konzepte auch in der Praxis bewähren, zeigt die große Menge von Mach-2.5-Portierungen auf diverse Hardware-Architekturen (IBM /370, Motorola, National, Sparc, Mips, Intel) sowie auf Zielsysteme (DEC/VAX, Sun3/4, IBM RT, Sequent Balance, Encore Multimax, Next etc.). Da Mach 3.0 in seinen grundlegenden Konzepten auf der Version 2.5 aufbaut und zudem den Vorteil der Mikrokern-Architektur bietet, ist eine ähnlich leichte Portierbarkeit zu erwarten.

Auf das Konzept der sogenannten "Transparent libraries", mit dem in Mach 3.0 beliebige Betriebssystem-Schnitt stellen binärkompatibel auf den Mach-Kern aufgesetzt werden können, wurde bereits hingewiesen. Auf diese Weise läßt sich Unix-Kompatibilität sicherstellen.

Ruft eine Unix-Anwendung (Binärsode) einen Unix-Systemdienst auf, so erkennt der Mach-Mikrokern an der Nummer des erzeugten Software-Interrupts, daß es sich um den Aufruf eines aufgesetzten Subsystems handelt und verzweigt an die entsprechende Stelle in der "Transparent library". Diese ist für jede angebotene Betriebssystem-Schnittstelle spezifisch und leitet den Aufruf entweder an einen als Server implementierten Dienst (Filesystem-Aufrufe, Unix-Prozeßverwaltung etc.) weiter oder benutzt einen Mechanismus des Mach-Kerns (Kommunikation etc.).

Der Anwendung bleibt dieser Ablauf verborgen, sie sieht lediglich die angeforderte Unix-Funktionalität. Daß dieses Schema mit Einbußen bei der Performance verbunden ist, liegt auf der Hand, doch bei Applikationen, bei denen Sourcekompatibilität allein nicht ausreicht, nimmt man derartige Nachteile in Kauf.

Unabhängig vom Aufwand für die Kompatibilität von Betriebssystem-Implementierungen auf Mach 3.0 ist auch die Performance von Mach 2.5 als modifizierter BSD-4.2-Kern im Vergleich zu herkömmlichen Unix-Systemen interessant. Diese Gegenüberstellung gibt Hinweise auf die grundsätzliche Eignung der neu entwickelten Konzepte und ihrer Implementierung in der Praxis. Beim Vergleich von Mach 2.5 und SCO Unix auf 386er PCs zeigt sich vor allem im Bereich Speicherverwaltung und Kommunikation eine Verbesserung, obwohl in dieser Rechnerumgebung viele der Mach-Neuerungen (zum Beispiel Multiprozessor Unterstützung) nicht zum Tragen kommen.

SW-Entwicklungs-Tools sind schon verfügbar

Für den Mach-Mikrokern ist - zumindest in einigen Bereichen - durch die Minimierung der Nachrichten- und Prozeßwechsel, durch eine neue Technik der Speicherverwaltung und durch eine allgemeine Steigerung der Code-Effizienz mit weiteren Performance-Gewinnen zu rechnen.

Kommen wir zu den Software Entwicklungswerkzeugen im Umfeld von Mach, die in jüngster Zeit erfolgreich realisiert wurden. Dazu gehören "MIG" zum Entwurf verteilter Applikationen, "Isis" zum Entwurf fehlertoleranter Anwendungen "Camelot" für verteilte Transaktionen, "C-Threads" für den Entwurf paralleler Applikationen und "Machobjects" für die objektorientierte Software-Entwicklung. Außerdem steht in Mach das für Wide Area Networks (WAN) geeignete verteilte Filesystem "AFS" zur Verfügung.

Mach 2.5 ist die Basis des ersten Betriebssystems der Open Software Foundation, von OSF/1. In diesem Rahmen stehen zusätzliche Werkzeuge zur Verfügung. OSF/1 bietet neben den gewöhnlichen Unix-Entwicklungs-Tools die Kommandos von IBMs AIX, Kommunikation über Streams, Unterstützung des Transport Interfaces (XTI) von X/Open und ein Sicherheitssystem.

Neben dieser strukturellen Evaluierung, die mehr technische und architektonische Aspekte berücksichtigt, ist für die Zukunft eines Betriebssystems natürlich auch entscheidend, wo die Konkurrenten am Markt stehen. Für die Beantwortung der Frage "Mach - Das Unix-Konzept der Zukunft?" bedeutet dies, daß die Konkurrenten am Unix-Markt unter die Lupe genommen werden müssen. Technologisch ist im Unix-Bereich derzeit das von Unix International unterstützte System V.4 State of the Art. Hier handelt es sich um einen gewöhnlichen System-V-Kern, der hinsichtlich Code-Effizienz restrukturiert wurde und wesentliche funktionale Erweiterungen (Verteilung, Echtzeitunterstützung) enthält.

Im großen und ganzen entspricht dieser Ansatz der bei Mach 2.5 verfolgten Strategie, einen vorhandenen Unix-Kern funktional zu erweitern und durch effizientere Mechanismen zu verbessern, wobei die Gesamtarchitektur jedoch beibehalten wird. Trotzdem hat Mach 2.5 Vorteile bei der Kommunikation und der Multiprozessor Unterstützung.

Mach 3.0 stellt einen wesentlich weitergehenden Ansatz für die Architektur zukünftiger Betriebssysteme dar. Unix V.4 hat aufgrund der Unterstützung von Unix International derzeit eine sehr starke Position am Markt, viele namhafte Hersteller verwenden das System als Basis ihrer Unix-Linien. Das europäische Gegenstück zu Mach ist das von Chorus Systems entwickelte Betriebssystem Chorus.

Mach unterstützt Realtime-Anwendungen

Designprinzipien und Architektur sind vergleichbar mit Mach, auch hier wird Kompatibilität zu Unix System V geboten. Die Möglichkeit, Echtzeitanwendungen zu unterstützen, ist ein wesentlicher Pluspunkt gegenüber Mach. Chorus ist im Gegensatz zu Mach ein kommerziell erhältliches Produkt mit Pflege und Support. Es wird derzeit hauptsächlich im Rahmen von Esprit-Projekten, bei der Telekommunikation sowie der europäischen Raumfahrt evaluiert oder bereits im Vorfeld eingesetzt. Unisys bringt demnächst eine Unix-Workstation auf Chorus-Basis auf den Markt.

Soll Mach im kommerziellen Umfeld zum Einsatz kommen, so ist klar zwischen den Versionen 2.5 und 3.0 zu unterscheiden. Während 3.0 noch in der Entwicklungsphase ist und sich erst allmählich zu einem kommerziell einsetzbaren Produkt entwickelt, ist Version 2.5 bereits in kommerziellen Systemen zu finden. Bis Mitte 1990 war Mach 2.5 eine rein universitäre Entwicklung der Carnegie Mellon Universität. Es wurde lediglich in Steven Jobs Next-Rechnern eingesetzt.

Bis 1990 wurden etwa 8000 Mach Systeme installiert, wobei der Großteil im universitären Bereich zu finden ist und nur etwa ein Viertel auf Hersteller und Behörden entfällt. Seit 1990 engagiert sich die OSF in der Mach-Entwicklung und verwendet die Version 2.5 als Basis ihres Betriebssystems OSF/1. Grund hierfür war vor allem die führende technologische Position von Mach 2.5 im Bereich offener Unix-Systeme.

Seit kurzem evaluiert die OSF die Mach-3.0-Mikrokerntechnologie gemeinsam mit anderen Systemen. In diesem Rahmen finden Implementierungen von Unix-Servern im oben erläuterten Sinn statt. Die Arbeiten bilden die Basis für die zukünftigen Betriebssystem-Entwicklungen der OSF. Auch soll es in Zukunft ein echtzeitfähiges Mach geben, womit ein wesentlicher Kritikpunkt ausgeräumt wäre.

Mach-Entwicklungen sind noch rein universitär

Betrachtet man die Anforderungen an zukünftige Betriebssysteme, so läßt sich abschließend feststellen, daß Mach hier wesentliche Aspekte wie Verteilung, Multiprozessor-Fähigkeit oder Unix-Kompatibilität unterstützt. Insbesondere die Mikrokern-Architektur der Version 3.0 stellt einen wesentlichen Schritt in Richtung zukünftiger Betriebssystem-Architekturen dar. Dies allein genügt jedoch nicht, um existierende Unix-Technologien abzulösen, weil die Mach-Entwicklungen rein universitär sind, also nicht den Charakter kommerzieller Produkte haben.

Das Engagement der OSF stellt den Schlüssel für die Akzeptanz von Mach dar, da es so zum kommerziell verfügbaren System wird. Insbesondere die Technologieauswahl für OSF/2 und eine damit verbundene weitere Verbreitung der Mikrokernarchitektur wird für die zukünftige Position von Mach ausschlaggebend sein. Zusammenfassend gilt also: Technisch erfüllt Mach sicherlich die Anforderungen an das Unix-Konzept der Zukunft, der tatsächliche Erfolg jedoch hängt von einigen Randbedingungen ab, die aus heutiger Sicht nur schwer zu beurteilen sind. +