Look and Feel

Wieder einmal trafen sich die SCO-Jünger im sonnigen Kalifornien, um über die Zukunft von SCO Unix zu sprechen. Bill Gates hätte seine Freude gehabt.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 9 Min.
Von
  • Jürgen Fey
Inhaltsverzeichnis

Die vor zwei Jahren sich abzeichnende Strategie der Einbindung der Windows-Clients in das SCO-Serverumfeld und die damit zementierte Aufgabe des Desktopbereiches für Unix, führte man in diesem Jahr fort. So kann man jetzt auf die Mainwin XDE-Entwicklungsumgebung von Mainsoft aufbauen, die einige Windows-APIs (darunter die MFC) unter SCO Unix zur Verfügung stellt. Wintif 95 erlaubt in Kombination mit einem X-Server ein Windows-95-Look-and-Feel für Unix-Applikationen, und das Arcserve-Backupsystem von Cheyenne arbeitet jetzt auch unter SCO Unix. Mit dem Telekommunikationsmarkt und Chorus/Fusion for SCO peilt man einen wachstumsorientierten Bereich an, der nach einem skalierbaren Standardbetriebssystem mit Echtzeiteigenschaften schreit. Ziel der Kalifornier ist es, das eigene Betriebssystem sowohl in die Vermittlungsknoten der Telefongesellschaften als auch in die kommerziellen Telefonanlagen zu verpflanzen. Gelingt dies, so könnten in den nächsten Jahren mehrere hunderttausend SCO-Lizenzen zusätzlich einen Abnehmer finden. Chorus/Fusion, bereits seit 1994 verfügbar, verbindet den bekannten Chorus-Mikrokernel mit der darüber plazierten System- und Entwicklungsumgebung des nicht mehr aktuellen SCO ODT 3.0. Der Entwickler von Telekom-Applikationen kann auf die Echtzeiteigenschaften des Kernels, die Echtzeitservices nach Posix 1003.1b/1c sowie IPC und TCP/IP (allerdings ohne NFS) zurückgreifen. Durch die Binärkompatibilität zum SCO System 3.0 laufen entsprechende Applikationen auch auf diesem Kernel ab.

Die zum SCO-Forum angekündigte Release 2 von Chorus/Fusion ist allerdings nur ein Zwischenschritt, da sich zu dem Chorus-Mikrokernel Anfang 1997 endlich der SCO OpenServer 5 gesellt. Dann soll es auch möglich sein, bestehende 'Legacy'-Applikationen zusammen mit neu geschriebenen Echtzeit- und typischen Unix-Applikationen etwa auf einem Telefonswitch ablaufen zu lassen. Das neue System (Projektname 'Voyager') erlaubt den Restart des Kernels sowie der einzelnen Applikationen im Betrieb, ist dank der Kernel-to-Kernel-IPC-Calls beliebig skalierbar (Multiprozessing) und unterstützt die Posix-APIs 1003.1b/1c und 4b. Voyager ergänzt die für die erste Jahreshälfte des Jahres 1996 zu erwartende nächste Version des Openserver (Projekt Comet), die einen P6-Compiler, den Support von User-Threads, bis zu 4 GByte Hauptspeicher oder bootfähige Mirror-Devices einschließt und Unix95-konform sein soll.

Die zweite Jahreshälfte von 1997 dürfte mit dem Olympus-Projekt dann endgültig den Einzug eines Intel-Unix in die Ruhmeshallen der High-End-Server bringen, denn dann steht der Support einer P6-typischen Serverumgebung (P6-Cluster, 64-Bit-Dateisystem, dynamisches Resizing der Dateisysteme, Distributed Lock Manager, Dateisystem- und Daten-Journaling, Kerberos V, C2, C2+, B1, B1+, Firewall) bevor. Die vielleicht irgendwann einmal auch in der Praxis spürbaren Vorteile des Plug and Play finden dann ebenfalls auch in der Unix-Welt ein Zuhause. Die Einbettung in Windows-Umgebungen möchte man durch kompatible EMail-Clients, DHCP oder eine Entwicklungsumgebung für OLE2, ODBC, MFC und Win32 schmackhaft machen; ein entsprechendes System könnte eine ernste Konkurrenz für Windows NT darstellen. Der eigenen Scriptsprache Visual TCL, die schrittweise als Standardplattform für alle administrativen Systemkommandos genutzt und zudem als Cross-Platform-Tool auch für andere Unix-Systeme etabliert werden soll, stehen Visual Basic-Erweiterungen bevor. Bereits Anfang 1996 möchte man mit dem Openserver5-Zusatzprodukt 'Cowell' direkt eine Alternative zu Windows NT als Serverplattform anbieten. Cowell bietet, auf den Openserver 5 aufgesetzt, typische Features eines NT-Servers wie Datei- und Druckservices, Domain-Kontrolle, Trusted Relationships, Enhanced Security und unterstützt direkt Windows-95-, WFW- und Windows 3.11-Clients.

Die Administration soll mittels des Cheyenne-Backup-Systemes, eines Netzwerkmanagementpaketes sowie verschiedener Diagnosetools erleichtert werden. Im Laufe des Jahres ist dann noch mit dem Support von WINS, DHCP und IPX/NetBIOS zu rechnen. Zudem läßt sich dann das System auch mittels eines Windows-Clients steuern. Den Funktionsumfang ergänzt ein Internet-Paket bestehend aus einem httpd-Server, Datenmanagementtools, Sicherheitsmechanismen wie Firewall, Secure Telnet und -Login, der verbesserte Modem-Support mit PPP sowie ein WWW-Toolpaket.

Für die bisherigen Geschäftsaktivitäten sind jetzt drei Bereiche innerhalb von SCO verantwortlich. Die Tatsache, daß man mit dem Openserver 5 und Chorus/Fusion derzeit zwei getrennte Betriebssysteme betreuen muß, ist für den SCO-Chefentwickler und -Mitgründer Doug Michels nur eine Frage der Zeit: 'Natürlich ist es erstrebenswert, von einem einzigen Source-Baum auszugehen, aber manchmal muß man auch einen Umweg machen, um auf spezifische Kundenwünsche schneller einzugehen.' Einige der auf den Telekommunikationsmarkt zugeschnittenen Chorus/Fusion-Features wie die Echtzeitverarbeitung und die Möglichkeit zum Clustering könnten demnach auch in einer zukünftigen Openserver-Plattform auftauchen. Zukünftige Systeme sollten auf jeden Fall wahlweise Mikrokernel-fähig sein. SCO baut auch darauf, daß die mit dem Chrorus/Fusion gemachten Erfahrungen für den Bereich der Telefonie (etwa Voicemail-Server) beinahe unverändert auch für einen künftigen Multimedia-Server von Belang sind. Noch immer will man von der System V Release 4 nichts wissen, hat man doch viele der SVR4-Annehmlichkeiten schrittweise in das eigene System integriert. Für Doug Michels stehen die derzeit noch fehlenden Kernel-Threads mit an oberster Stelle, doch orientiert sich SCO an dieser Stelle eher am Ansatz der Lightweight-Threads im Gegensatz zu den oft kritisierten Heavyweight-Threads von SVR4.

Bei Neuentwicklungen könne man nicht mehr wie bisher auf die 'Magie der Architektur offener Systeme' zurückgreifen. Während bislang ein Anruf beim allwissenden X/Open-Konsortium ausreichte, um die Spezifikation aller in Zukunft wichtigen Entwicklungen zu bekommen und dementsprechend die Inhouse-Arbeit auszurichten, sei diese Quelle jetzt nicht mehr so relevant. Microsoft dominiert den Desktop, während die offenen Systeme den Servermarkt beherrschen. Die Frage, die sich nach Michels jetzt stellt, ist die, wie die beiden Welten besser zu integrieren sind. Michels: 'An dieser Stelle können wir nicht mehr auf das träge X/Open-Konsortium warten, das zudem die Windows-Welt vernachlässigt und keinen Einfluß auf Spezifikation etwa wie das MAPI hat'. Der von X/Open entwickelte 'Common Desktop Environment'-Standard (CDE) sei ein Beispiel für einen Standard im Bereich offener Systeme, der in der Praxis keinen Sinn mache. Prinzipiell orientiere sich SCO ungezwungen an den bestehenden Schnittstellen: 'Unser Ansatz ist nicht, etwas Neues zu erfinden, wenn schon etwas Vergleichbares existiert. Es gibt schon genug APIs.' Eine Wunscharchitektur würde nach Michels auf der Client-Seite die Windows-APIs unterstützen und diese mit dem Unix-Server integrieren. Hierzu gehöre auch die Fähigkeit, daß Clients und Server über das IPX-Protokoll miteinander reden können. Damit könnte man auch einer größeren Menge firmeninterner PCs den Zugang zum Internet ermöglichen, ohne daß hierzu auf jedem PC erst TCP/IP installiert und eine IP-Adresse vergeben werden müßte. Die Übernahme der Windows-APIs könnte bis hin zu einem auf dem Openserver ablaufenden Exchange-Server gehen.

Die hohen Erwartungen konnten dieAuftritte der Net-Insider John Perry Barlow und des Physikers/Buchautors Clifford Stoll erfüllen. Stoll empfahl eine gewisse Zurückhaltung vor den Versprechungen der neuen Technologien: 'Viele Leute laufen immer hinter der High-Tech-Lösung her und sehen nicht, daß die einfachen Lösungen oft vollkommen ausreichen. Wenn das Internet, wenn IRC wirklich so toll ist, warum kommen dann noch immer alle Leute zu Veranstaltungen wie dieser? Computer sind gut, aber was mir auf den Nerv geht, ist dieser unsägliche Kult um den Computer, dieses Ideal, daß man online sein oder eine EMail-Adresse haben muß, um in Echtzeit den Fortschritt mitverfolgen zu können. Es gibt mir einfach zu denken, daß so viele Leute wirklich Herausragendes schaffen, ohne jemals an einem Computer zu sitzen. Warum ist das Virtuelle wichtiger als das Reale?' Auch John Perry Barlow kann (gerade als Rancher) dem 'Meatspace' noch immer mehr als dem Cyberspace abgewinnen, doch sieht er keinen Grund, sich exklusiv für eine der beiden Welten entscheiden zu müssen. Er brachte es auf den Punkt:'Ich bin gerne mit meinem Körper in Pinedale, Wyoming und lasse meine Gedanken zugleich im Internet umherschwirren. Ich möchte gar nicht mehr ausschließlich im Meatspace leben.' Interessanterweise stellte Barlow fest, daß er oft mit seinem Geist an seiner zentralen EMail-Lokation 'barlow@eff.org' weilt, während sein Körper in der Welt umherreist, da nur so der direkte Kontakt mit anderen Menschen möglich sei. Dieses Ideal sei aber nicht für jedermann gültig: 'Es gibt in der Welt viele Nobodies, die bei der direkten Face-to-Face-Kommunikation schlecht abschneiden und gerade für die ist die computerbasierende Interaktion die einzige Möglichkeit, aus ihrer Isolation herauszukommen.' (fm) (fm)