Unix steht an der Schwelle, ein akzeptiertes Betriebssystem für den Masseneinsatz zu werden. Gerade zu diesem Zeitpunkt brennen den Anwendern Probleme zur Integration des Systems in eine bestehende DV-Umwelt oder Fragen zur Entwicklungstendenz auf den Nägeln. Auf der Tagung "Unix transparent II" stellten sich in Inzell Repräsentanten der Unternehmen Hewlett-Packard, HighTec, IBM, PCS. Philips und Siemens (siehe Kasten) dem Auditorium. COMPUTERWOCHE veröffentlicht einige High-Lights dieser Diskussion.
Wie ist derzeit die Marktsituation von Unix, und welche Stückzahlen sind realistisch?
Strack-Zimmermann: Weltweit werden pro Monat etwa 8000 bis 10 000 Unix-Systeme zusätzlich eingesetzt. In Europa kommen monatlich zirka 1500 bis 2000 Unix-Maschinen zu dem installierten Park hinzu. Das sind aber meine persönlichen Schätzungen, da konkrete Zahlen nur schwer zu bekommen sind.
Gulbins: 1983 waren 80 Prozent der Systeme im technisch-wissenschaftlichen Bereich, 1984 dagegen bereits 50 Prozent auf dem kommerziellen Markt eingesetzt (PCS-Verkäufe). Der Markt verschiebt sich zugunsten der kommerziellen Anwender; das scheint auch in USA der Fall zu sein. Zudem haben wir die Feststellung gemacht, daß ein großer Teil der Kunden, bei denen die Forderung bestand, kostengünstig mit einem Mikro einzusteigen, nach kurzer Zeit die Maschinen hochgerüstet haben, zu einer Leistungsklasse, die weit über der Personal-Computer-Klasse liegt, das heißt, eine Maschine, die in der Größenordnung von 30 000 Mark lag, hochgerüstet in die Größenordnung 60 000 Mark.
Hat Unix wirklich die Chance, sich zum Beispiel im Bürobereich langfristig gegen MS-DOS durchzusetzen, das ja zur Zeit eine erheblich größere Verbreitung als Unix hat?
Strack-Zimmermann: Es handelt sich dabei um zwei unterschiedliche Marktsegmente. Die klaren Vorteile von MS-DOS liegen darin, daß es möglich ist, Anwendersoftware in binärer Form dazuzukaufen. Hier gibt es einen Software-Alternativmarkt, der relativ gut läuft. Das ist eigentlich die Stärke von MS-DOS, und ich glaube, das wird auch für einige Zeit so bleiben.
Für die Arbeit unter Unix im Büro-Bereich, zum Beispiel Textverarbeitung, ist eine Winchesterplatte ein Muß. Ohne Platte sind nur wenige Anwendungen möglich oder sinnvoll. Mit einer Winchester-Platte ist der Unterschied zwischen einem Unix- und einem MS-DOS-System verschwindend klein. Unix braucht eine solche Platte von vornherein.
Darüber hinaus gibt es einen Effekt, der überwiegend in kleinen und mittelständischen Betrieben zu beobachten ist: Hier taucht schnell der Wunsch nach einem zweiten Bildschirm auf, und das ist der Moment, in dem MS-DOS einfach ausfällt. Dies wird sich auch nicht stark ändern, wenn MS-DOS 4.0 als Multi-Tasking-Version verfügbar ist.
Es gibt weitere Gesichtspunkte: MS-DOS ist in Assembler programmiert. Die meisten Anwender-Pakete dafür sind sehr maschinennah geschrieben. Es ist ein offenes Geheimnis, daß wir an dem Zeitpunkt des Umbruchs von den 16-Bit-Mikroprozessoren zu den 32-Bit-Mikroprozessoren stehen - ein Generationswechsel findet statt. Das ist für die Kompatibilität von MS-DOS tödlich. Es kann einen ähnlichen Umbruch bedeuten wie damals, als die 8-Bit-Mikroprozessoren am Ende waren - und damit auch das Betriebssystem CP/M-80.
Heintke: Die Anwender unterscheiden sehr stark zwischen Industriestandard-Produkten und sogenannten Hersteller-Propriety-Produkten in Hardware, Betriebssystemen und Software; Die Frage ist also, wie weit Unix in der Lage ist, diese Hersteller-Propriety-Systeme mittelbis langfristig zu ergänzen, zu ersetzen oder die Möglichkeit bieten kann, dorthin zu migrieren.
Kochsmeier: Gerade die IBM unterliegt in diesem Bereich zwangsläufig vielen Spekulationen. Man sollte sich im wesentlichen an unseren Ankündigungen orientieren. Daß wir manchmal System III, Xenix oder im Falle von IX/370 das System V anbieten, liegt daran, daß wir auf externe System- oder Softwarehäuser zugegriffen und von deren Versionen Gebrauch gemacht haben. Man muß auch klar sehen, daß wir bezüglich Unix Anfänger waren. Unser IX/370 läuft als Guest-Operating-System unter VM/SP auf der /370er Architektur, das heißt 4361, 4341 und 3033 bis 3084.
Die Systeme /36 und /38 sind also nicht Unix-fähig?
Kochsmeier: Nein. Es sind mir keine Projekte bekannt.
Strothmann: Mit Unix ist eine völlig neue Situation entstanden. In der Tat sind Hersteller in die Lage geraten, dieses Produkt nicht rechtzeitig oder noch nicht handhaben zu können. Es ist nicht immer böser Wille oder eine heimtückische Absicht, wenn ein Produkt nicht kommt. Gelegentlich ist es auch die Unfähigkeit, ein Produkt umfassend zu unterstützen.
Welche Unterschiede gibt es im wesentlichen zwischen den Unix-Versionen, und wie kompatibel sind diese Versionen untereinander?
Strack-Zimmermann: Es gibt in den Teilen der Schnittstellen Unterschiede, die ein Anwendungsprogrammierer jedoch meidet. Angefangen hat es mit Version 7, dann folgte System III: Hier gab es erstmalig 1-K-Filesystem, darüber Named Types, aber keine Multiple Files mehr. Es folgten 1500 Fehlerbehebungen - Generalbereinigung nennt man das Ganze. Danach kam System V mit einer etwas verbesserten Definition der Sprache "C", Shared Data und Semaphores. In den neuesten Releases von System V kam virtuelle Adressierung hinzu, und es gibt auch Gerüchte bezüglich eines schnelleren File-Systems. Das ist der Bereich, den der Anwender nicht sieht bis auf Shared Data und Semaphores. Und das ist auch der Bereich, den AT&T kurz danach in der "System V Base Definition" wieder zurückgezogen hat, weil es auf den 286-Prozessor nicht implementierbar ist. Auch ein Software-Hersteller muß aufpassen, daß er sich nicht in die Irre führen läßt von demjenigen, der das System erfunden hat.
Schäfer: Mit Unix läuft es etwa so wie mit Fortran: Alle benutzen es und alle haben einen gemeinsamen Kern. Aber es wird immer Zusätze geben, weil man für bestimmte Applikationen Funktionen braucht, die der Standard nicht bereithält. Bei Unix ist es zum Beispiel die Grafik. Es gibt keine Grafikbibliothek, die standardmäßig angeboten wird; es fehlt an Realtime-I/O. Man muß bei solchen Ergänzungen die Herstellerdokumentation daraufhin abprüfen, welche Elemente woher kommen - das ist sehr wichtig.
Wie weit ist eigentlich Microsoft involviert und auch interessiert an den Standardisierungsbestrebungen der "Open Unix Group", denn 70 Prozent der Unix-Installationen sind ja Xenix-Abkömmlinge?
Strack-Zimmermann: Die Funktionen von Xenix, das ja auf Unix System III basiert, wurden von der "Open Unix Group" berücksichtigt und liegen durchaus im definierten Umfang der gemeinsamen Unix-Schnittmenge. Es gibt allerdings einen, vielleicht wesentlichen Unterschied: Die wichtige Lock-Funktion, die Microsoft als erste implementiert hat, ist in der Semantik und in der Syntax anders definiert als bei der User Group und auch bei AT&T. Microsoft ist aber heute nicht mehr so bestimmend auf diesem Sektor, wie es auf Grund der hohen Installationszahlen aussieht. Das sind Installationsstückzahlen, die vor allem auf der Grundlage eines Systems erreicht worden sind. Es ist relativ wenig bekannt, daß Radio Shack ein Xenix-System auf den US-Markt gebracht hat. Es war das erste wirklich kostengünstige Unix-System - und daher der relativ hohe prozentuale Anteil. Darüber hinaus hat auch Altos das Xenix ursprünglich in seiner "Reinkultur" verwendet. Microsoft hat ja klar erklärt, gemeinsam mit AT&T sich dieser System V Base Definition in ihrem nächsten Release Xenix 5.0 anzunähern.
Sehen Sie einen Weg, das Echtzeit-Verhalten von Unix zu verbessern, und wird diese Funktion irgwendwann eimnal standardisiert?
Strothmann: Es gibt Unix-Lookalike-Systeme, die Realzeit-Eigenschaften oder bessere Realzeit-Eigenschaften als das Original-Unix besitzen. Wir haben aber auf Grund unserer Erfahrungen festgestellt, daß es interessanter ist, den umgekehrten Weg zu gehen: In einem Realzeit-Betriebssystem kompatible Unix-Schnittstellen zu schaffen - eine Kompatibilität zwischen den Anwendungen und den Schnittstellen im Unix-Entwicklungssystem. Das hat auch den Vorteil, daß diese Schnittstelle damit definiert ist und sich auch bei Systemerweiterungen nicht mehr ändert. Man hat also ein sehr kleines System, das man System-Call um System-Call erweitert. Es ist eine Symbiose zwischen einem kleinen System, das Realzeit-Eigenschaften als grundlegenden Mechanismus hat, und dem Unix-Entwicklungssystem.
Was verstehen Sie eigentlich in diesem Zusammenhang genau unter Echtzeit-Verarbeitung?
Schäfer: Es gibt eine Reihe von Anforderungen, die ein System erfüllen muß, um den Realzeitanforderungen zu genügen. Dazu gehört, daß Prozesse im Arbeitsspeicher nicht mehr geswapt werden müssen, Prioritäten hochgesetzt, asynchrone Ein-/Ausgabe durchgeführt und Interrupts verarbeitet werden können. Und die Garantie für eine gewisse Reaktionszeit.
Strothmann: Es gibt natürlich andere Wege, die man beschreiten kann, um in vorhandene Systeme, die auf Grund ihrer Hardware-Eigenschaften nicht dazu geeignet sind, trotzdem ein Unix-System zu integrieren, das heißt, die Systeme koexistieren zu lassen. Und was erstaunlich ist, sogar mit ziemlich geringem Aufwand.
Gulbins: Auf einem Rechner, der Echtzeit-Aufgaben durchführt, wird kein Unix eingesetzt, sondern ein System, das in der Lage ist, mit Unix über ein Netz sehr transparent zu kommunizieren. Zum einen kann auf dem Unix-System die Entwicklung sowie die Post- oder Pre-Verarbeitung der Daten durchgeführt werden, zum anderen steht ein eigener dedizierter Rechner zur Verfügung, der nur in der Lage ist, relativ schnell zu reagieren. Das ist sicher auch ein Weg, wie man Unix und Realzeit Verarbeitung koppeln kann.
Heintke: Der Vollständigkeit halber sollte man doch erwähnen, daß die Firma AT&T, die ja aus der Vermittlungstechnik kommt, für diese Echtzeit-Aufgaben einen Unix-Dialekt namens "MERT" eingesetzt hat, der im Prinzip ein Echtzeit-Unix darstellt. Man transferiert also unter Unix entwickelte Software auf die Echtzeit-Umgebung.
Teilnehmer der Podiumsdiskussion auf der Tagung Unix transparent II
* Jürgen Gulbins, PCS, München. Abteilungsleiter und verantwortlich für die Entwicklung von Unix-Systemen.
* Hartmut Heintke, Philips Data Systems, Siegen. Verantwortlich für Software-Qualität und Toolbeschaffung. Er hat in diesem Zusammenhang häufig mit Unix zu tun.
* Harald Kochsmeier, IBM, Böblingen. Zuständig für die Abstimmung der Marktforderungen der internationalen Niederlassungen mit den Entwicklern.
* Helmut Schäfer, Hewlett-Packard, Böblingen. Programm-Manager, Marketing und Kundenunterstützung.
* Hans Strack-Zimmermann, Siemens AG, München. Leiter der Software-Entwicklung von Kleinrechnern schwerpunktmäßig unter Sinix.
* Rolf Strothmann, HighTec EDV-Systeme GmbH, Saarbrücken, Geschäftsführer und Leiter der Entwicklung für Hardware und Software.