Blick nach vorn

Ausblick auf die nähere Linux-Zukunft

Trends & News | Trend

Längst bestimmt nicht mehr der Kernel allein über die Linux-Zukunft. Die weltweit verstreute Entwicklergemeinde werkelt an neuen Bedienoberflächen, 3D-Grafikschnittstellen und diversen Anwendungsprogrammen.

Aufmacher

Es ist klar, wohin die Reise geht: Linux soll bedienerfreundlicher werden, ein reichhaltiges Applikationssortiment bieten und trotzdem für den Einsatz in speziellen Gebieten gewappnet sein, etwa als Betriebssystem für Embedded Controller. Da all das nicht eine zentral gesteuerte Gruppe mit klar gesetztem Ziel verfolgt, ist es schwer, die wesentlichen Strömungen zu erfassen. Das Folgende stellt deshalb eine subjektive - will sagen: willkürliche - Auswahl dar.

Unabhängig davon, ob die Entwickler das tatsächlich bezwecken, gilt Linux derzeit als die Konkurrenz zu Windows - dem Betriebssystem des übermächtigen Software-Konzerns Microsoft. In vielen Punkten muss es sich an seinem Komfort und seinen Features messen lassen. Viele der aktuellen Entwicklungen scheinen genau darauf ausgerichtet: die den Kinderschuhen entwachsenden [#kasten2 3D-Schnittstellen], Bedienoberflächen wie das [#kasten1 K-Desktop-Environment 2] und natürlich der 2.4er-Kernel, um den es sich im Folgenden dreht.

Im kommenden 2.4er-Kernel finden sich reichlich Hinweise darauf, dass Linux nicht gegenüber Windows zurückstehen soll: Unterstützung für das Advanced Control und Powermanagement Interface (ACPI), den Universal Serial Bus (USB) und ISA-Plug&Play reifen in den für Entwickler vorbehaltenen Versionen (2.3.x) heran. Damit stürzen sich die Kernel-Entwickler auf Standards, die von Branchengrößen wie Intel und Microsoft etabliert worden sind und auf die Linux-Anwender nicht verzichten mögen.

Am weitesten fortgeschritten von all diesen Standards zeigt sich die USB-Unterstützung in den Vorversionen des 2.4er-Kernels. Wir haben uns diese an Hand der Kernel-Version 2.3.31 angesehen: Sie deckt die gebräuchlichen USB-Adapter ab. Derzeit sind vor allem zwei registerkompatible USB-Bausteine anzutreffen, der in Intel- und VIA-Chipsätze integrierte UHCI- oder der von Compaq, OPTI und Apple eingesetzte OHCI-Baustein. Der Kernel enthält Module für beide Adapter und liefert die gemeinsamen Funktionen in einem speziellen USB-Modul (usbcore).

Treiber für Drucker, Kameras, Wechselplattenlaufwerke, Modems und natürlich USB-Mäuse, -Tastaturen und -Hubs bringt der Kernel mit. Während Tastatur und Maus auf Anhieb funktionieren, bereiteten uns sowohl die Kamera als auch die Wechselplatte Probleme. Zum Kernel gehört lediglich ein Treiber für Kameras mit CPiA-Chip. Dieser Chip ist vor allem in Kameras der vorletzten Generation anzutreffen, die längst durch inkompatible Nachfolger abgelöst worden sind.

Da auch in der Redaktion partout keine Kamera mit diesem Chip aufzutreiben war, wichen wir auf Treiber aus, die ein niederländischer Programmierer speziell für die derzeit im Handel erhältliche Philips USB-Kamera (PCVC680) anbietet. Da der Autor nur über eine Vertraulichkeitsvereinbarung mit Philips an die nötigen Daten herankam, gibt er derzeit nur fertige Module [1], aber keine Quelltexte heraus. Um sein Modul einsetzen zu können, sind zudem einige Patches am Kernel notwendig.

Derzeit konkurrieren zwei Standards zum Schreiben von USB-Treibern unter Linux: Die ursprünglich vorgesehene Schnittstelle, mit der die aktuellen Entwicklerkernel daherkommen, und ein Modell, das den USB-Request-Blöcken (URBs) von Windows nachempfunden ist. Der Treiber für die Philips-Kamera benutzt URBs, deshalb ist der Patch notwendig. Man kann wahlweise die URB-Patches für den 2.3.31-Kernel verwenden, die der Autor mit seinem Treiber bereitstellt, oder einen alternativen USB-Stack für Linux mit URBs nutzen, der aus München kommt [2].

Die Kamera funktioniert nach unserer Erfahrungen mit beiden USB-Stacks. Ein USB-Zip-Drive hingegen funktionierte weder mit dem Original-Stack des 2.3.31-Kernels noch mit den URB-Patches, noch mit dem alternativen Stack. Die USB-Stacks erkannten das Laufwerk zwar; auch ließ sich die nötige SCSI-Emulationsschicht laden (ein spezielles Modul), aber spätestens nach einigen Zugriffen auf das Zip-Laufwerk war Schluss.

Wer mit USB und Linux experimentieren will (was auch mit 2.2er-Kernel möglich ist [3]), sollte auf jeden Fall SMP-Support beim Kompilieren der Kernel abschalten (2.3.31 aktiviert ihn standardmäßig). Ansonsten erlebt man mehr böse Überraschungen als nötig. Die im Web bereitstehenden Seiten zu USB und das How-to sind eine große Hilfe und beinhalten auch Hinweise, wie eine USB-Maus unter X in Betrieb zu nehmen ist [4, 5].

Gegenüber dem reichhaltigen Support für USB sieht es mit ISA-Plug&Play und ACPI eher dürftig aus: Die Plug&Play-Infrastruktur im Kernel ist zwar da, aber sie wird noch nicht ausgeschöpft. Beim Booten erkennt der Kernel ISA-Plug&Play-Karten. Über das /proc-Dateisystem stehen Funktionen bereit, um die Konfigurationsoptionen der Karten auszulesen und sie zu konfigurieren. Aber bisher macht kein Treiber davon Gebrauch. Der 2.4er-Kernel bleibt damit etwa auf dem Stand seines Vorgängers, wenn man das isapnp-Paket einsetzt.

Ähnlich bei ACPI: Dahinter steckt nicht nur eine renovierte Schnittstelle für das Powermanagement (als APM-Ersatz), sondern auch ein weit reichendes Ressourcen-Management. Der 2.4er-Kernel wird es wohl nicht berücksichtigen, denn es mangelt noch an der dahinter liegenden Infrastruktur [6, 7]. Zu solchen Eigenmächtigkeiten wie etwa Windows 2000, das auf einem ACPI-System die wohl zugeordneten PCI-Ressourcen (etwa IRQs) vollständig durcheinander wirft, neigt Linux - glücklicherweise - (noch) nicht.

Erfreulicherweise kommen trotz Integration solcher Neuerungen weder die Detailpflege noch die Fehlerbereinigung zu kurz. Schließlich bestand das Ziel der Kernel-Entwickler nicht darin, möglichst viele neue Features einzubauen, sondern die Entwicklung zu konsolidieren. Mit dem 2.4er-Kernel fallen so einige ärgerliche Einschränkungen im Cache-Management und die Obergrenze für die Anzahl der Prozesse beziehungsweise Threads, die beim 2.2er-Kernel noch bei Kompilation festzulegen ist.

Neu sind sogenannte Raw-Devices. Ihrer können sich Anwendungen bedienen, die auf absolute Datensicherheit versessen sind: Schreibvorgänge auf ein solches Gerät führt Linux unmittelbar aus, ohne die Daten durch den Cache zu schicken. Unter anderem benutzen Datenbanken solche Geräte, um ein eigenes Cache-Management etablieren zu können. Wie viele andere auch betrifft diese Ergänzung allerdings eher den Einsatz in Unternehmen.

Wer Linux auf einem Notebook benutzt, dürfte sich freuen, dass im 2.4er-Kernel PCMCIA-Unterstützung gleich eingebaut ist; bisher musste man sich diese separat besorgen. Um den zusätzlich erforderlichen Card-Manager muss man sich trotzdem kümmern. Er sorgt dafür, dass beim Ein- und Ausstecken von PCMCIA-Karten die richtigen Module geladen werden. Probleme, die sich im Zusammenspiel von PCMCIA und APM ergeben, etwa dass ein Neuladen der PCMCIA-Module nach einem Suspend nötig ist, bestanden mit 2.3.31 weiterhin.

Weitere Neuerungen bringt 2.4 im Netzwerkbereich: Erneut wurde der in den Kernel integrierte Firewall-Code umgebaut. Statt der mit dem 2.2er-Kernel eingeführten Steuerungsprogramme für IP-Chains stehen Programme für das neue Konzept (‘Netfilter’ genannt) zur Verfügung [8]. Optimierungen am Socket-System sorgen dafür, dass auf eine Netzverbindung lauernde Prozesse gezielter vom System geweckt werden, etwa ein Web-Server, der auf Zugriffe von außen wartet.

Wer zwischen OS/2 und Linux wechselt, dürfte sich darüber freuen, dass 2.4 nicht nur lesende, sondern jetzt auch offiziell schreibende Zugriffe auf HPFS-Partitionen vorsieht. Wer das für NTFS haben will, muss riskieren, dass ihm die als ‘experimental’ ausgewiesenen Schreibzugriffe Datensalat anrichten. Von einem ‘Journaling Filesystem’, das im Fall eines unerwarteten Systemausfalls in Windeseile die Daten in konsistenten Zustand bringt, ist leider noch nichts zu sehen.

Für viele Neuerungen steht noch einiges an Arbeit bevor: So gibt es für den Einsatz von USB-Geräten unter Linux noch keine Mittel, um etwa beim nachträglichen Einstecken von Geräten die richtigen Module zu laden und sie beim Abziehen auch wieder zu entladen. Lediglich Vorschläge dafür, wie eine solche Infrastruktur aussehen könnte, gibt es bis-her. Ähnliches gilt auch für ACPI. Um Firewire respektive IEEE1394 macht der neue Linux-Kernel sogar noch einen Bogen [9].

Linux ist, wenn es trotzdem funktioniert: Von eventuellen Problemen beim Umgang mit den derzeitigen Entwickler-Kerneln sollte man keineswegs auf den endgültigen 2.4 schließen. Zwar zeigen sich beim Umgang mit den Neuerungen noch diverse Schwächen, aber bisher hat die Linux-Etwicklergemeinde es verstanden, stets reife Kernel für den produktiven Einsatz herauszubringen. Dass sie dabei mitunter den Ankündigungen hinterherhinkt (ursprünglich sollte 2.4 mal zu Weihnachten kommen), nimmt niemand übel. (ps)

[1] Modul für Philips USB-Kameras und Patches für URB

[2] Alternativer USB-Stack für Linux mit URB

[3] USB für 2.2

[4] Linux USB-Seiten mit Hinweisen auf USB für 2.2

[5] Linux-USB-How-to

[6] ACPI-Spezifikation

[7] ACPI-Projekt für Linux

[8] Firewall in 2.4

[9] Linux und IEE1394

[#anfang Seitenanfang]


Das K Desktop Environment (KDE) hat sich als Standardoberfläche für Linux etabliert. Die Entwickler des KDE-Teams sind sich offensichtlich der damit verbundenen Verantwortung bewusst und haben parallel zu der schon seit über einem Jahr laufenden Entwicklung für KDE 2.0 die Version 1 weiter gepflegt und verbessert. Anders als 1.1.1 und 1.1.2 wird KDE 2.0, das im Frühjahr 2000 erscheinen soll, eine komplett überarbeitete Version mit neuer Architektur, zusätzlichen Features und Programmen.

Im Dezember 99 stellte das KDE-Team die mit der internen Versionsnummer 1.89 versehene Krash-Release vor. Der Name ist Programm - Krash ist keine fertige Version für Endanwender, sondern eine Entwicklerrelease, die es Distributoren und Entwicklern erlauben soll, sich mit KDE 2.0 vertraut zu machen und eigene Programme an die neuen Schnittstellen anzupassen.

Und davon gibt es eine ganze Reihe. Unter der Haube von KDE 2 findet sich jetzt ein Komponentenmodell, das es Applikationen erlaubt, die Dienste anderer als Komponenten realisierter Programme zu nutzen. Hier gab es im Herbst 99 noch eine größere Umstellung: Die ursprünglich verwendete Common Object Request Broker Architecture (CORBA) [[#lit1 1]] hat sich für die lokale Kommunikation der Desktop-Applikationen als zu langsam und zu umständlich erwiesen. Deshalb haben die KDE-Entwickler ihr neues Desktop Communication Protocol (DCOP) jetzt direkt auf die X-Bibliothek libICE aufgesetzt.

Das Einbetten von Komponenten läuft bei Krash jetzt ebenfalls über ein schlankeres API namens KParts, das mittels Shared Libraries funktioniert und nicht mehr auf CORBA angewiesen ist. Interessanterweise nähert man sich damit immer mehr Microsofts ActiveX-beziehungsweise COM-Architektur an - vielleicht rührt daher der Codename ‘Kanossa’. CORBA kommt nur noch zum Einsatz, wenn tatsächlich Dienste zur verteilten Objektkommunikation benötigt werden.

Das klingt alles zwar reichlich abstrakt, bringt jedoch auch dem Endanwender konkreten Nutzen. So macht beispielsweise der neue File-Manager Konqueror bereits regen Gebrauch von KParts. Konqueror kann quasi beliebige Dateitypen im Browserfenster darstellen, sofern sich eine Komponente für den zugehörigen MIME-Typ registriert hat. Des weiteren unterstützt der Browser theoretisch Java (meine Versuche in diese Richtung führten allerdings zum Absturz), an JavaScript wird noch gearbeitet.

Auch das Surfen im Internet geht mit Konquerer komfortabler von der Hand. Über einen Service von http://navigation.realnames.com sucht er automatisch eine URL zu eingegebenen Begriffen. So landet man mit ‘kde’ automatisch auf http://www.kde.org. Scheitert diese Anfrage, liefert Konqueror für den Begriff automatisch das Ergebnis einer Suche auf http://google.com zurück. Außerdem finden sich im K-Menü Optionen, um im Internet direkt nach Web-Seiten, Dateien oder News-Artikeln zu suchen.

Das in der Krash-Release enthaltene KOffice profitiert am deutlichsten von der Abkehr von CORBA. Das Einbetten von Tabellen zum Beispiel funktioniert jetzt deutlich flüssiger. Die Textverarbeitung KWord stürzt zwar immer noch gelegentlich ab, der Funktionsumfang kann sich jedoch bereits sehen lassen.

Auch am Look & Feel des Desktops haben die KDE-Entwickler gearbeitet. Dazu haben sie das in 1.1.2 eingeführte Theme-Konzept [[#lit2 2]], das im Wesentlichen auf Fensterdekorationen beschränkt war, noch konsequenter umgesetzt. Über die in Qt 2.1 eingeführte Widget-Themes lassen sich nahezu alle GUI-Elemente wie Auswahlboxen, Slider und so weiter modifizieren - ähnlich wie beim Pluggable Look & Feel in Javas Swing. In den Display-Einstellungen kann der Benutzer zwischen verschiedenen Look&Feel-Varianten mit und ohne Themes wählen.

Die Krash-Release beinhaltet neben KOffice nur die Basis-Pakete von KDE (kdelibs, kdebase und kdesupport). Wer die neuen K-Applikationen ausprobieren will, muss sich deren Quellcode via Anonymous-CVS besorgen. Dabei ist allerdings nicht einmal sichergestellt, dass sich dieser dann auch übersetzen lässt - von fehlerfreier Funktion ganz zu schweigen.

Überhaupt sollte man berücksichtigen, dass Krash für Entwickler gedacht ist. Wer KDE produktiv einsetzen will, sollte vorerst noch bei KDE 1.x bleiben. Als Ausblick auf 2.0 ist Krash jedoch sehr vielversprechend. Stabilität und Geschwindigkeit haben sich im Vergleich zu den zwischenzeitlich sehr instabilen, trägen CVS-Versionen merklich gesteigert. Können die Entwickler den Code jetzt noch bis zum Erscheinen der fertigen Version im Frühjahr 2000 weiter stabilisieren und entwanzen, dann wird KDE 2.0 sicher ein Meilenstein für Linux. (ju)

[1] Torben Weis, ‘Kompositionen in 'K'’, Das CORBA-basierte Komponenten-Modell für KDE, c't 2/99, S. 152

[2] KDE-Themes

[#anfang Seitenanfang]


Eines der spannendsten Linux-Themen dieses Jahres hat nur am Rande mit dem Kernel zu tun: 3D-Grafik, wie sie Spiele, aber auch klassische Workstation-Anwendungen benötigen, entwächst den Kinderschuhen. Sowohl Software- als auch Hardwarehersteller haben das freie Betriebssystem als lohnende Plattform erkannt.

Unter Unix dient OpenGL als universelle Grundlage für alle 3D-Applikationen. Mit dem von Brian Paul entwickelten Mesa [1] gibt es für Linux eine freie OpenGL-Implementierung. Die entscheidende Schwachstelle von Mesa war bisher die fehlende Treiberschnittstelle, gegen die man Treiber für 3D-Hardware schreiben kann. Das bedeutet, dass Mesa die 3D-OpenGL-Aufrufe in reine 2D-Grafikoperationen umsetzt. Das entspricht einer reinen Software-Implementierung des OpenGL-APIs, die so langsam ist, dass sich beispielsweise Quake 3 nicht einmal auf einem Gigahertz-Athlon vernünftig spielen ließe.

Das Schreiben von 3D-Treibern für Linux wurde außerdem dadurch erschwert, dass es lange Zeit keine Dokumentation von den 3D-Chipherstellern gab beziehungsweise nur gegen ein Non-Disclosure-Agreements zu erhalten war. Diesen Weg beschritt Daryll Strauss, um die Glide-Treiber für Voodoo-Karten zu entwickeln. Glide ist ein herstellerspezifisches 3D-API von 3Dfx [2].

Mit Hilfe der Glide-Treiber entstand dann 1997 die erste 3D-Hardware-beschleunigte Version von Mesa. Diese wurde von David Bucciarelli entwickelt und stellt quasi einen Wrapper dar, der die OpenGL-Aufrufe auf Glide-Funktionen abbildet. (Deshalb benötigt man für OpenGL-Spiele sowohl Mesa als auch die Glide-Treiber.) Somit bietet Mesa Unterstützung für momentan alle verfügbaren Voodoo-Karten von 3Dfx.

Ein Nachteil des Wrappers ist, dass er nur Fullscreen-Darstellung ermöglicht, wenn man nicht auf den wesentlich langsameren ‘Window-Hack’ für 3Dfx-Addon-Karten zurückgreift. Dabei übernimmt der Addon-Chip das Rendern, und der Inhalt des Voodoo-Grafikspeichers wird danach an die erforderliche Speicheradresse der Grafikkarte kopiert. Außerdem kann mit dem Wrapper immer nur ein OpenGL-Programm die 3D-Hardware nutzen. Nichtsdestotrotz stellt dies zumindest für Spiele im Fullscreen-Modus eine zufrieden stellende Lösung dar.

Läuft jedoch die OpenGL-Applikation nicht auf dem gleichen Rechner wie der zur Darstellung verwendete X-Server, ist diese Lösung zum Scheitern verurteilt. Für solche Fälle hat das X-Consortium die GLX-Erweiterung entwickelt [3], bei der die OpenGL-Bibliothek komplette GL-Aufrufe über das Netzwerk an den X-Server schickt, der ihre Ausführung übernimmt und dazu die 3D-Hardware nutzen kann. Dabei implementiert die GLX-Erweiterung und nicht die OpenGL-Bibliothek die hardwarebeschleunigten OpenGL-Funktionen.

Mesa enthält zwar GLX-Aufrufe, es handelt sich dabei aber um einen Nachbau, der sie in normale X11-Funktionen umwandelt und so wiederum eine 3D-Hardwarebeschleunigung unmöglich macht. Deshalb hat Steve Parker echte GLX-Erweiterungen für XFree86 3.3 implementiert und Mesa entsprechend angepasst. Ein Projekt, das auf dieser Implementierung beruht, wird von Terence Ripperda geleitet und bietet bereits Hardware-beschleunigte 3D-Unterstützung für Matrox-G200/G400-Grafikkarten sowie die Riva-Serie (128/TNT/TNT2) von nVidia. Den Treiber für die Riva-Serie hat nVidia selbst entwickelt. Inzwischen tummeln sich auch prominente Entwickler wie John Carmack, der Chefentwickler von id Software, auf der GLX-Entwicklerliste.

Eines der Hauptprobleme dieser GLX-Implementierung besteht darin, dass der X-Server bei aufwändigen Rendering-Aufgaben nicht mehr bedienbar ist, da ein gemeinsamer Prozess sowohl für das Rendern als auch die sonstigen X-Aufgaben zuständig ist (bisher erledigte das Rendern ein externer Prozess). Gut zu sehen ist dieser Effekt, wenn man das Mesa-Demo ‘clearspd’ mit GLX-Unterstützung aufruft und dann versucht die Maus zu bewegen.

Anfang 99 hat Silicon Graphics die Referenzimplementierung von GLX im Quellcode freigegeben. Diese wird momentan von der Firma Precision Insight in das demnächst erscheinende XFree86 4.0 integriert und um die von Precision Insight entwickelte, im Quellcode frei verfügbare Direct Rendering Infrastructure (DRI) erweitert. Mit DRI [4] soll es in Zukunft möglich sein, relativ einfach 3D-Treiber für XFree86 mit GLX-Unterstützung zu entwickeln.

Direct Rendering Infrastructure
Vergrößern
Die von Precision Insight entworfene Direct Rendering Infrastructure (DRI) erlaubt X-Applikationen direkten Zugriff auf 3D-Hardware.

Neben einem GLX-Modul für den X Server und einer speziellen Mesa-Bibliothek sieht DRI auch ein Kernelmodul vor, das unter anderem DMA-Übertragungen ermöglicht. Ein DRI-Treiber im Prealpha-Stadium steht bereits für die Voodoo-3 von 3Dfx zur Verfügung. Treiber für die Rage 128 von ATI sind ebenfalls in Arbeit. Man darf also auf das Erscheinen von XFree86 4.0 im ersten Quartal 2000 gespannt sein.

Auch SuSE arbeitet an einer ähnlichen Treiberstruktur für Mesa, die sich MLX nennt und ebenfalls ein Kernelmodul vorsieht. Zunächst soll MLX [5] nur die Grafikchips von 3Dlabs unterstützen. Xi Graphics und Metrolink bieten mit ‘3D Accelerated X’ beziehungsweise ‘Extreme 3D’ ebenfalls 3D-hardwarebeschleunigte OpenGL-Lösungen an, die aktuelle Grafikchips von 3Dlabs, S3, SiS, nVidia, E&S, ATI und Number Nine unterstützen [6, 7].

Auch im Anwendungsbereich tut sich einiges. Mit Arcad (CAD System), Blender (Modellier- und Renderprogramm), Moonlight Creator (Modellierprogramm) sowie Performer (Real Time Grafikengine von SGI) gibt es bereits eine Reihe ernsthafter 3D-Anwendungen. Die Liste wird sich im Laufe des Jahres sicherlich beträchtlich erweitern. Auch was 3D-Spiele angeht, sieht die Situation sehr vielversprechend aus. Spiele wie FlightGear (Flugsimulator) und Unreal Tournament (Netzwerk Ballerspiel) laufen mit 3D-Hardware-Unterstützung. Mit Myth II (Glide Unterstützung) sowie Heretic II und Quake 3 Arena (beide Mesa Unterstützung) sind inzwischen auch die ersten ‘boxed products’ erhältlich [8, 9].

ju

[1] www.mesa3d.org

[2] www.3dfxgamers.com/

[3] http://glx.on.openprojects.net/

[4] www.precisioninsight.com

[5] www.suse.de/~sim

[6] www.xig.com

[7] www.metrolink.com

[8] www.linux3d.org/software.html

[9] www.lokigames.com

Kommentare

Anzeige