Die Woche: Das Ende von X11?

Aber was ist eigentlich das Problem mit dem X Window System, dass Shuttleworth es unbedingt loswerden möchte? Nun, seine grundlegende Architektur ist 25 Jahre alt. Das ist an sich nicht schlimm (viele grundlegende Ideen in Unix und Linux sind noch älter), aber viele Designentscheidungen würde man heute anders treffen. Als das X Window System 1984 entwickelt wurde, kannte Unix beispielsweise noch keine Shared Libraries (die kamen erst 1986 mit System V Release 3). Damit nicht jedes grafikfähige Programm dieselben Routinen zum Zeichnen von Linien und Mustern, zum Darstellen von Bitmaps und Text mitschleppen muss (RAM und Plattenplatz waren teuer damals), kam man auf die Idee, den ganzen Grafikcode in einem Grafik-Server – dem X-Server – zu sammeln.

Grafische Anwendungen – X-Clients – sagen dem Server dann nur noch "Male dieses Pixel rot", "Zeichne eine Linie von hier nach dort", "Gib an dieser Position den String 'foo' in Courier 12 Punkt aus" oder "Male jene Bitmap in die Ecke links oben". den Rest erledigt der X-Server. Er kümmert sich um die Hardware, initialisiert die Grafikhardware, verwaltet die Farbmodi und Auflösungen der Grafikkarte, fragt die Eingabegeräte ab. Der X-Server koordiniert den Zugriff verschiedener Anwendungen auf den Grafikspeicher und leitet Eingaben an den richtigen X-Client weiter. Er verwaltet die Schriften, rendert Text und stellt den X-Clients eine Vielzahl grafischer Primitiven zur Verfügung.

Dabei kann die Kommunikation zwischen X-Server und X-Client über ein Netzwerk erfolgen: Der Raytracer, der verteilt auf dem dicken Cluster im Keller läuft, kann als X-Client das gerenderte Bild direkt auf dem X-Server ausgeben, der auf dem Schreibtisch-PC läuft. (Im Zusammenhang mit dem X Window System ist, anders als sonst üblich, das Endgerät mit Display, Tastatur und Maus der Server und die Anwendung – egal, ob lokal auf dem Desktop-PC oder auf dem Supercomputer im Rechenzentrum – der Client.)

Allerdings haben sich die Anforderungen an ein Grafiksystem in den letzten zweieinhalb Jahrzehnten drastisch verändert. 1984 war Farbgrafik fast unbezahlbar, und unter Highend-Computergrafik verstand man ungefähr das, was ein Plotter zu Papier bringt – Linien, Muster und Schrift. Wenn Sie eine Idee von der Grafik bekommen wollen, auf die der X-Server optimiert ist, starten Sie mal den X-Server-Benchmark X11perf mit

x11perf -all -time 1 -repeat 1

und sehen Sie sich an, was da so über den Bildschirm flimmert. Mit den Anforderungen moderner Desktops – Farbverläufe, Anti-Aliasing, Schattenwurf, Transparenz, 3D-Effekte – hat das nicht das Geringste zu tun. Trotzdem steckt der Code für alle diese grafischen Primitiven heute noch im X-Server. Installieren und starten Sie doch mal den aus den 80er Jahren stammenden Fenstermanager twm, den auch heute noch jede Linux-Distribution mitbringt. Starten Sie dann ein xterm, dazu vielleicht noch xclock, xcalc, xeditor oder xfontsel. Jetzt haben Sie einen Eindruck, auf welche Art von Grafik das X Window System optimiert ist. Selbst Keith Packard, in den letzten Jahren einer der wichtigsten X-Entwickler, hat in seinem Vortrag auf der Linux Plumbers Conference einen Abgesang auf das X Window System angestimmt.

Heutige Desktops und GUI-Anwendungen verlassen sich nicht auf die grafischen Fähigkeiten des X-Servers, sondern zeichnen GUI-Elemente, Grafiken und Text über Toolkits wie Qt oder Gtk+ und Grafikbibliotheken wie Cairo und Xft. Der X-Server erhält nur noch die fertigen Bitmaps zur Darstellung. (Das ist jetzt ein bisschen arg vereinfacht – der X-Server leistet über Erweiterungen wie XRender eine Menge mehr als früher –, aber beschreibt die Tendenz.) Und auch bei der Hardware hat der X-Server immer weniger zu tun: Das Initialisieren der Grafik-Hardware und das Umschalten zwischen verschiedenen Bildschirmauflösungen wie auh das Abfragen der Eingabegeräte erledigt heutzutage der Kernel.

Für die verbliebenen Aufgaben – im Wesentlichen die Darstellung von Bitmaps und das Weiterleiten von Eingabeereignissen an das zuständige Fenster – reicht ein simpler Display Server wie das von Mark Shuttleworth (und auch von Intel) bevorzugte Wayland völlig aus. Wayland übernimmt auch gleich das Compositing (also die 3D-Manipulation der Fenster vom Schattenwurf bis zur Rotation), was die Festerverwaltung vereinfacht – der X-Server muss dazu ziemlich komplex mit einem Compositing Manager interagieren.

Dabei ist für Kompatibilität mit den bestehenden Anwendungen gesorgt: Da die aktuellen Toolkits kaum noch Funktionen des X-Servers nutzen, lassen sie sich relativ einfach auf das Wayland-Protokoll umschreiben – danach kann man alle Gnome/Gtk+- und KDE/Qt-Anwendungen mit minimalem Aufwand portieren. Und die Wayland-Architektur erlaubt es, einen X-Server als Wayland-Client zu betreiben – für die verbleibenden X-Anwendungen.

Klingt fast zu schön, um wahr zu sein: Ein modernes, schlankes Grafiksystem für Linux, befreit von den Altlasten der letzten 25 Jahre, optimiert auf die Bedürfnisse heutiger Desktops und kompatibel mit allen existierenden grafischen Linux-Anwendungen – da muss es doch einen Pferdefuß geben? Leider gibt es sogar zwei Pferdefüße. Zum einen ist Wayland noch nicht so weit, dass es das X Window System ablösen könnte – ein Menge Detailarbeit bleibt noch zu tun (einige Stichworte: Fenstermanagement, Keymaps, Zugangshilfen). Aber das wird kommen – auch Shuttleworth will ja nicht in den nächsten sechs Monaten umsteigen.

Zum anderen verzichtet Wayland auf die Netzwerktransparenz des X Window System – ein absolutes Killerkriterium, glaubt man den Kommentaren im Heise-Forum. Aber übers Netz kriegt man GUI-Anwendungen auch ohne X – mittels RDP oder VNC. VNC überträgt meinen gesamten Desktop inklusive Firefox über DSL mit 6**MBit/s flüssig, während das Firefox-Fenster alleine, via X auf das Notebook zu Hause geholt, fast unbedienbar ist. Das zeigt, was die Netzwerktransparenz des X Window System mit heutigen Anwendungen noch wert ist.

Ich glaube, es ist höchste Zeit für etwas Neues. Es stimmt, in den letzten zehn Jahren hat der Linux-Desktop gewaltige Fortschritte gemacht – aber nicht wegen, sondern trotz X. Ich erinnere mich noch an die Zeiten, als jede X-Anwendung eine eigene Farbtabelle installierte und der Wechsel in das Netscape-Fenster den ganzen Desktop in einen psychedelischen Farbrausch tauchte. Als Mausklicks keine Wirkung hatten, wenn die NumLock-Taste gedrückt war (weil NumLock+Maustaste ein anderes Event ist als Maustaste ohne NumLock). Als man X-Konfigurationsdateien austauschte, um das X Window System auf einer bestimmten Hardware überhaupt zum Laufen zu kriegen. (Das Unix-Haters Handbook enthält in seinem Kapitel über das X Window System noch mehr Beispiele.)

Aber mit all dem muss man sich heutzutage nur deswegen nicht mehr herumschlagen, weil unglaublich viele Arbeitsstunden talentierter Programmierer in das X Window System, in X-Server-Erweiterungen und in die Toolkits geflossen sind, die die Desktop- und Anwendungsentwickler von den X-Untiefen abschirmen. Dass X dadurch gezähmt ist, heißt nicht, dass es ein tolles Grafiksystem ist. Ich jedenfalls bin gespannt, wann Wayland benutzbar ist, wann die Liste der Wayland-Clients mehr als ein paar Demos umfasst – und wann die erste Distribution tatsächlich das X Window System ersetzt. (odi)