Gnome 2.18.1KDE 4.10Xfce 4.6.1Zusammenwirken von X Server und X Client. Im oberen Teil der Grafik ist ein Benutzerrechner schematisch dargestellt, auf dem ein X Server die Tastatur, die Maus und den Bildschirm verwaltet. Der X Server interagiert in dem Beispiel mit drei X Clients: einem lokalen Browser, einem lokalen xterm (zur Interaktion mit Unix-Shell) und einem entfernten xterm
Es stellt einen Standardbaukasten und das Protokoll zum Bau einer grafischen Benutzeroberfläche zur Verfügung. Dazu gehören Zeichnen und Bewegen von Fenstern auf dem Bildschirm sowie das Behandeln der Benutzereingaben mit Maus und Tastatur. X schreibt keine spezielle Benutzerschnittstelle vor, sondern überlässt dies seinen Client-Programmen. Deshalb können X-basierte Umgebungen in ihrem Aussehen sehr variieren. Mithilfe von Desktop-Umgebungen – die bekanntesten, KDE und Gnome sind rechts abgebildet – wird dem entgegengewirkt. Endanwender kommen auf modernen Unix-Desktops mit den Kernprogrammen des X Window Systems kaum noch in Berührung.
Frühere Anzeigeprotokolle konnten nur eingebaute oder direkt angeschlossene Anzeigen verwalten. In Erweiterung dazu wurde X spezifisch als Client-Server-System entworfen, was neben der lokalen auch eine netzwerktransparente Verwendung ermöglicht.
Die X.Org Foundation betreut heute das Projekt und hat am 6. Juni 2012 die Version 7.7 der Referenzimplementierung als freie Software unter der MIT-Lizenz herausgegeben. Eine weitere, in den 1990ern weit verbreitete Implementierung ist XFree86. Als Nachfolger soll Wayland dienen.
X wurde 1984 im Projekt Athena in Zusammenarbeit des MIT, DEC und IBM entwickelt.[1] Die erste Version wurde am 19. Juni 1984 vorgestellt und 1986 wurde X 10.4 mit großem Erfolg gegen eine Schutzgebühr an alle Interessierten verteilt, womit X erstmals eine große Verbreitung auf den Unix-Rechnern jener Zeit erreichte. X10 war jedoch inkompatibel zum späteren X11.[2] Im September 1987 schließlich folgte das erste Release von X11.
Als 1988 die Popularität immer größer wurde, wurde das nicht-kommerzielle X-Konsortium gegründet, das die weitere Entwicklung übernahm. Es veröffentlichte verschiedene Versionen, die letzte große war X11R6 1994. Danach übernahm The Open Group die Entwicklung und Standardisierung. In der gleichen Zeit erreichte die freie X-Implementierung XFree86 einen immer größeren Bekanntheitsgrad und wurde zum De-facto-Standard der X-Implementierung. 2003 aber gab es projektinterne und lizenzrechtliche Probleme bei XFree86, die im Endeffekt zur Auflösung des Entwicklerteams führten. Unter dem Dach der daraufhin neu gegründeten X.Org Foundation wurde fortan eine Abspaltung des alten XFree86 weiterentwickelt, die unter dem Namen X.Org-Server größtenteils in dessen Fußstapfen trat. Seit etwa 2005 gilt er als der meistverbreitete X-Server und damit die meistverbreitete X-Implementierung.
Technik
Mögliche Fensterverteilung durch einen X11-FenstermanagerX11-Fensterelemente, Beispiel mit Fenstermanager FVWM2
Der X-Server steuert die Ein- und Ausgabegeräte wie unter anderem Zeigegeräte (z. B. Maus), Tastatur, Bildschirm und Grafikkarte. Dazu kommuniziert er in der Theorie mit dem Betriebssystem-Kernel, in der Praxis wird der Kernel aber auch umgangen. Das zugrundeliegende Konzept ist eine Erweiterung des Terminal-Konzeptes auf grafische Benutzeroberflächen: Ein Programm verlässt sich für die grafische Eingabe (Maus) und Ausgabe (Fenstertechnik) auf die Dienste eines anderen dafür spezialisierten Programms (X-Server), die Kommunikation läuft immer über das Netzwerk.
Die Darstellung bei X ist die eines Rastergrafik-basierten Fenstermanagers, der verschiedene Funktionen bereitstellt. Dazu gehört das Zeichnen und Bewegen der Fenster, die ereignisorientierte Handhabung eines Zeigegeräts, z. B. einer Maus, die Interprozesskommunikation und teilweise auch die Verwaltungsfunktionen für Druck und Audio-Ausgabe. X ist also ein Minimalsystem, bei dem zum Zeichnen lediglich Primitive wie Linien, Muster etc. bereitgestellt werden.
Das eigentliche Aussehen und Verhalten des Fenstersystems wird deshalb nicht von X bestimmt, sondern von dem Fenstermanager, der wie eine normale Anwendung einfach als Client des X-Servers läuft. Für das Aussehen der Programme selbst ist er aber nicht verantwortlich, das übernimmt meistens das sog. GUI-Toolkit, welches das Zeichnen und Verwalten der typischen Elemente einer grafischen Oberfläche wie z. B. Menüs und Buttons übernimmt. Siehe dazu auch Desktop-Umgebung.
Der X-Server läuft auf dem Rechner am Arbeitsplatz und stellt seine (grafischen) Dienste den X-Clients zur Verfügung. Er enthält den Grafikkartentreiber sowie Treiber für Tastatur, Maus und andere Eingabegeräte (wie z. B. Grafik-Tablets) und kommuniziert mit dem X-Client mittels Interprozesskommunikation.
Der X-Client ist das Anwendungsprogramm, das die grafischen Ein/Ausgabe-Dienste des X-Servers benutzt. Er kann auf demselben oder auch auf irgendeinem entfernten Rechner laufen (sofern eine Netzwerkverbindung zwischen beiden besteht). Der X-Client benutzt die Dienste des X-Servers, um eine grafische Darstellung zu erreichen und empfängt von ihm die diversen Ereignisse (events) wie Tastenanschläge, Mausbewegungen, Klicks usw.
X-Terminal
Das in der Großrechner-Welt bekannte, textbasierte Terminal-System (dort meistens proprietäre wie IBM 5250 und 3270; unter DigitalsVMS die bekannten seriellen Terminals wie z. B. VT100) erlebte seine grafische Weiterentwicklung zum X-Terminal; ein Rechner, auf dem nichts anderes als ein X-Server läuft. Diese X-Terminals werden häufig genutzt, um mit leistungsschwachen Rechnern auf rechenintensive Anwendungen zuzugreifen: Die Anwendung selbst läuft auf einem Server, das X-Terminal übernimmt nur die Anzeige der grafischen Oberfläche.
Statt spezieller Hardware für X-Terminals hat es sich letztlich durchgesetzt, auf Standard-Hardware von PCs zurückzugreifen. Mit dieser können die Funktionen von X-Terminals zum Beispiel in Form von Thin Client preiswert umgesetzt werden.
3D-Beschleunigung
Um schnelle 2D- und 3D-Beschleunigung zu ermöglichen, stellt das X Window System die Schnittstelle Direct Rendering Infrastructure (DRI) bereit, über die Programme direkt auf die Grafik-Hardware zugreifen können. Das geschieht bei freien Treibern durch die OpenGL- und Vulkan-Implementierung Mesa 3D, im Fall von proprietären Treibern durch jeweils proprietäre Implementierungen davon.
Mit Hilfe von 3D-Erweiterungen wie AIGLX und xgl werden im X.Org-Server darüber hinaus 3D-Effekte auf dem Desktop selbst unterstützt.
Stärken
Das X-System wurde von Anfang an für den effizienten Netzwerkbetrieb konzipiert. Die Kommunikation zwischen Client und Server läuft über ein standardisiertes Protokoll ab, das nur relativ geringe Transferraten benötigt. Der Quellcode des X-Systems ist zwar objektorientiert, aber dennoch in C geschrieben, so dass eine Übersetzung auf nahezu jedem Unix-Rechner möglich ist. Das X-System ist im Gegensatz zu aktuellen MS-Windows-Versionen kein Bestandteil des Betriebssystems, weswegen ein Absturz von X in der Regel keinen Einfluss auf dessen Integrität hat: Stürzt der X-Server ab oder reagiert nicht mehr, können die Clients reagieren und z. B. auf einen Neustart des X-Servers warten oder sich (was meistens der Fall ist) beenden. Weiterhin hat der Fenstermanager (die „Bedienoberfläche“) im Prinzip denselben Status wie ein X-Client: Im laufenden Betrieb kann ein Fenstermanager durch einen anderen ersetzt werden. Bereits mit sehr kleinen Fenstermanagern (z. B. twm, rund 140 KB) kann komfortabel gearbeitet werden.
Durch den durchdachten, hierarchischen Aufbau des Systems ist beispielsweise Folgendes möglich:
An einem X-Server mehrere Bildschirm-Arbeitsplätze betreiben.
Für Entwicklungs- und Testzwecke einen X-Server in einem Fenster eines anderen X-Servers laufen lassen.
Programme an einem Rechner mit völlig anderer Hard- und Software als dem Bedienrechner ausführen.
Die Weiterentwicklung von X läuft im Vergleich zur Hardware auf großen Zeitskalen und mit nur geringen Veränderungen ab. Kompatibilitätsprobleme treten daher nicht auf, wenn nur Standardbibliotheken verwendet werden. Allerdings benutzt ein großer Teil der X-Clients heute Erweiterungen wie Xft, XVideo oder Xinerama.
Die strikte Trennung des X Window Systems von der Benutzeroberfläche führt zu einem vergleichsweise flexiblen System, das aber auch sehr uneinheitlich erscheinen kann: Da das Design der Oberflächenelemente im Gegensatz zu Windows oder Mac OS nicht aus dem eingestellten Design des Haupt-GUI-Toolkits stammt, sondern es verschiedene Toolkits (unter anderem Qt und GTK) mit verschiedenen Eigenschaften gibt, die verschiedene Designs verwenden, kann es durchaus vorkommen, dass jedes der genutzten Programme ein unterschiedliches Aussehen und Verhalten zeigt.
Schwächen
Mit xinput list und xinput test id fungiert der X-Server als Keylogger, wobei selbst das sudo-Passwort ausgelesen werden kann. Voraussetzung für diese Art des Angriffs ist aber, dass bereits ein X-Server mit root-Rechten läuft. Viele Linux-Distributionen verhindern deshalb in der Standardkonfiguration die Anmeldung als root.[3] Das erstmals 2008 vorgestellte Wayland-System soll den X-Server ablösen, dessen historisch gewachsene Schwachpunkte vermeiden und deutlich weniger Sicherheitslücken aufweisen.[4][5]
Ansätze zur Verbesserung
Übertragungsgeschwindigkeit
Es wurden mehrere Ansätze entwickelt, um die Übertragungsgeschwindigkeit zu verbessern:
Anlegen eines Caches für schon übertragene Daten und
Reduzierung des Einflusses der Paketumlaufzeit zwischen X-Client und X-Server durch effizientere Programmierung.
Mehrere Projekte versuchen, diese Techniken umzusetzen. Die XCB-Bibliothek ist eine Neufassung der Xlib-Bibliothek, die im X-Server den Datenverkehr zwischen Client und Server regelt. Bei der Entwicklung von XCB wird insbesondere Wert auf eine gesteigerte Effizienz gelegt.
Einen hohen Bekanntheitsgrad hat ebenfalls das NX-Projekt des italienischen Unternehmens NoMachine, das mit Hilfe eines Caches und Datenkompression X auch über Modem-Leitungen nutzbar macht.
In der Vergangenheit arbeitete auch das Low-Bandwidth-X-Projekt von Keith Packard in diesem Bereich. Es war gedacht, eine Erweiterung des X-Protokolls zu erstellen, um dessen Netzwerktransparenz auch für niedrige Bandbreiten nutzbar zu machen. Mit der Veröffentlichung der von X11R6.3 durch das X-Konsortium im Dezember 1996 wurde LBX eine volle Erweiterung des X-Protokolls. Da es aber nie großflächig genutzt wurde und auch nur für einen Teil der Probleme eine Lösung bieten konnte, wurde das Projekt im Laufe des Jahres 2000 von Keith Packard für tot erklärt.[6]
Gesteigerte Einheitlichkeit
Eine gesteigerte Einheitlichkeit wurde ebenfalls von mehreren Projekten verfolgt. Ansätze waren die Erstellung einer Desktopoberfläche mit einheitlichen Oberflächenbibliotheken oder aber das Ersetzen von X durch ein auf höherem Niveau angelegtes System, das von Beginn an eine einheitliche Behandlung von Oberflächenelementen beinhaltete. Das Fresco-Projekt und das Y Window System entwickelten jeweils Lösungen, um den zweiten Ansatz umzusetzen, die Projekte ruhen aber zurzeit.
Ein anderer, aktiv verfolgter Ansatz ist der Versuch, durch gemeinsame Richtlinien für Benutzerschnittstellen und Verhaltensweisen der Software Einheitlichkeit zwischen den verschiedenen Toolkits zu erlangen. Dieser Ansatz wird vor allen Dingen im Rahmen des freedesktop.org-Projekts verfolgt und führte dort z. B. zu einheitlichen Standards für Icons.
Sonstiges
In den frühen 1990er-Jahren war die komplette X11-Distribution oft die größte Datei (rund 10 bis 50 MB) auf Unix-Rechnern. Da sie zudem frei war, wurde sie gerne als Mailbombe verwendet oder zumindest damit gedroht. „Soll ich Dir ein X11R3 schicken“ war daher im Usenet ein Running Gag, um Newbies auf Fehlverhalten hinzuweisen.
Die X11-Farben sind heute Grundlage der Farbnamen in CSS.
↑Jürgen Seeger: Das X Window System wird 30. Am 19. Juni 1984 lief der erste Prototyp des netzweiten, grafischen Fenstersystems X, das bis heute Standard auf Unix- und Linux-Systemen ist. In: Heise online. 20. Juni 2014, abgerufen am 20. Juni 2014.
↑The X Window System. In: Guidebook, Stand: 25. Juni 2005 (englisch); ursprünglich in der Byte, Ausgabe 1/89, S. 353–360; abgerufen am 31. Mai 2013.