X Window-System

Betreuer:	X.Org-Stiftung
Stabile Version:	7.1 [ +/-]
Vorschauversion:	7.2RC1 Git (Entwicklung) [ +/-]
SIE:	mehrere
Verwenden:	Fenstersystem
Lizenz:	MEINE Lizenz
Webseite:	www.x.org

WO 3.5 Gnom 2.14.0

Beim Rechnen ist die X Window-System (häufig X11 oder X ) ist ein Protokoll und zugehörige Software zur Bereitstellung von Fenstern auf Bitmap-Anzeigen. Es stellt das Standard-Toolkit und -Protokoll bereit, um darauf grafische Benutzeroberflächen (GUIs) aufzubauen Unix , Unix-ähnliche Betriebssysteme und OpenVMS und wird von fast allen anderen modernen Betriebssystemen unterstützt.

X bietet das Grundgerüst für eine GUI-Umgebung: Zeichnen und Verschieben von Fenstern auf dem Bildschirm und Interaktion mit Maus und/oder Tastatur. X schreibt die Benutzeroberfläche nicht vor – einzelne Client-Programme kümmern sich darum. Daher variiert das visuelle Styling von X-basierten Umgebungen stark; verschiedene Programme können radikal unterschiedliche Schnittstellen darstellen.

X zeichnet sich durch Netzwerktransparenz aus: Die Maschine, auf der Anwendungsprogramme (die Klient Anwendungen) ausgeführt werden, kann sich von der lokalen Maschine des Benutzers (der display Server ). Die Verwendung der Begriffe 'Client' und 'Server' durch X kehrt das um, was die Leute oft erwarten, da sich 'Server' auf die lokale Anzeige des Benutzers ('Display-Server') und nicht auf eine entfernte Maschine bezieht.

X entstand 1984 am MIT. Die aktuelle Protokollversion, X11, erschien im September 1987. Die X.Org Foundation leitet das X-Projekt, mit der aktuellen Referenzimplementierung, Version 11 Release 7.1, verfügbar als freie Software unter der MIT-Lizenz und ähnlichem zulässige Lizenzen .

Das X-Client-Server-Modell und Netzwerktransparenz

X verwendet ein Client-Server-Modell: an X-Server kommuniziert mit diversen Klient Programme. Der Server akzeptiert Anforderungen für die grafische Ausgabe (Windows) und sendet Benutzereingaben (über Tastatur, Maus oder Touchscreen) zurück. Der Server kann wie folgt funktionieren:

• eine Anwendung, die in einem Fenster eines anderen Anzeigesystems angezeigt wird
• ein Systemprogramm, das die Videoausgabe eines PCs steuert
• ein dediziertes Stück Hardware.

Diese Client-Server-Terminologie – das Terminal des Benutzers als „Server“, die entfernten Anwendungen als „Clients“ – verwirrt neue X-Benutzer oft, weil die Begriffe vertauscht erscheinen. Aber X nimmt die Perspektive des Programms ein und nicht die des Endbenutzers oder der Hardware: Die lokale X-Anzeige stellt Anzeigedienste für Programme bereit, fungiert also als Server; Jedes Remote-Programm verwendet diese Dienste und fungiert somit als Client.

In diesem Beispiel nimmt der X-Server Eingaben von Tastatur und Maus entgegen und zeigt sie auf einem Bildschirm an. Ein Webbrowser und ein Terminalemulator laufen auf der Arbeitsstation des Benutzers, und ein Systemaktualisierungsprogramm läuft auf einem entfernten Server, wird aber von der Maschine des Benutzers gesteuert. Beachten Sie, dass die Remote-Anwendung genauso ausgeführt wird, wie sie es lokal tun würde.

Das Kommunikationsprotokoll zwischen Server und Client arbeitet netzwerktransparent: Client und Server können auf demselben oder auf unterschiedlichen Rechnern laufen, eventuell mit unterschiedlichen Architekturen und Betriebssystemen, aber in jedem Fall gleich. Ein Client und ein Server können sogar sicher über das kommunizieren Internet indem die Verbindung über eine verschlüsselte Netzwerksitzung getunnelt wird.

Um ein Remote-Client-Programm zu starten, das auf einem lokalen Server angezeigt wird, öffnet der Benutzer normalerweise ein Terminalfenster und telnet oder ssh mit dem Remote-Computer und weist ihn an, auf dem Computer des Benutzers anzuzeigen ( z.B. [Computer des Benutzers] auf einem Remote-Rechner, auf dem bash läuft), und starten Sie dann den Client. Der Client stellt dann eine Verbindung zum lokalen Server her, und die Remote-Anwendung zeigt auf dem lokalen Bildschirm an und akzeptiert Eingaben von den lokalen Eingabegeräten. Alternativ kann die lokale Maschine ein kleines Hilfsprogramm ausführen, um sich mit einer entfernten Maschine zu verbinden und dort die gewünschte Client-Anwendung zu starten.

Praktische Beispiele für Remote-Clients sind:

• Grafische Verwaltung einer entfernten Maschine
• Ausführen einer rechenintensiven Simulation auf einem entfernten Unix-Rechner und Anzeigen der Ergebnisse auf einem lokalen Windows-Desktop-Rechner
• Ausführen von grafischer Software auf mehreren Computern gleichzeitig, gesteuert von einem einzigen Display, einer Tastatur und einer Maus.

Gestaltungsprinzipien von X

1984 legten Bob Scheifler und Jim Gettys die frühen Prinzipien von X dar:

• Fügen Sie keine neue Funktionalität hinzu, es sei denn, ein Implementierer kann eine echte Anwendung ohne sie nicht fertigstellen.
• Es ist ebenso wichtig zu entscheiden, was ein System nicht ist, wie zu entscheiden, was es ist. Diene nicht allen Bedürfnissen der Welt; sondern machen das System erweiterbar, so dass zusätzliche Anforderungen aufwärtskompatibel erfüllt werden können.
• Das einzige, was schlimmer ist als die Verallgemeinerung von einem Beispiel, ist die Verallgemeinerung von überhaupt keinen Beispielen.
• Wenn ein Problem nicht vollständig verstanden wird, ist es wahrscheinlich am besten, überhaupt keine Lösung anzubieten.
• Wenn Sie für 10 Prozent der Arbeit 90 Prozent des gewünschten Effekts erzielen können, verwenden Sie die einfachere Lösung. (Siehe auch Schlechter ist besser.)
• Isolieren Sie die Komplexität so weit wie möglich.
• Stellen Sie eher einen Mechanismus als eine Richtlinie bereit. Legen Sie insbesondere die Richtlinien für die Benutzeroberfläche in die Hände der Kunden.

Das erste Prinzip wurde während des Designs von X11 geändert, um: 'Fügen Sie keine neue Funktionalität hinzu, es sei denn, Sie kennen eine echte Anwendung, die dies erfordert.'

X hat sich seitdem weitgehend an diese Grundsätze gehalten. Die Referenzimplementierung wurde im Hinblick auf eine Erweiterung und Verbesserung der Implementierung entwickelt, während sie nahezu vollständig mit dem ursprünglichen Protokoll von 1987 kompatibel bleibt.

Benutzeroberflächen

X enthält bewusst keine Angaben zur Benutzeroberfläche der Anwendung, wie z. B. Schaltflächen, Menüs, Fenstertitelleisten usw. Stattdessen liefern/definieren Benutzersoftware – wie Fenstermanager, GUI-Widget-Toolkits und Desktop-Umgebungen oder anwendungsspezifische GUIs wie Point-of-Sale – all diese Details. Daher hat sich die „typische“ X-Schnittstelle im Laufe der Jahre enorm verändert.

Ein Fenstermanager steuert die Platzierung und das Erscheinungsbild von Anwendungsfenstern. Dies kann eine Schnittstelle haben, die der von ähnelt Microsoft Windows oder von der Macintosh (Beispiele sind KWin in KDE oder Metacity in Gnom ) oder radikal andere Steuerelemente haben (z. B. einen Kachelfenstermanager). Der Fenstermanager kann Barebones sein ( z.B. twm, der grundlegende Fenstermanager, der mit X geliefert wird) oder bieten Funktionalität, die an die einer vollständigen Desktop-Umgebung grenzt ( z.B. Aufklärung).

Viele Benutzer verwenden X mit einer vollständigen Desktop-Umgebung, die einen Fenstermanager, verschiedene Anwendungen und eine konsistente Benutzeroberfläche enthält. Gnom und KDE sind die beliebtesten Desktop-Umgebungen. Die Unix-Standardumgebung ist das Common Desktop Environment (CDE). Die Initiative freedesktop.org befasst sich mit der Interoperabilität zwischen Desktops und den Komponenten, die für einen wettbewerbsfähigen X-Desktop benötigt werden.

Da X für die Tastatur- und Mausinteraktion mit grafischen Desktops verantwortlich ist, wurden bestimmte Tastaturkürzel mit X verknüpft. Control-Alt-Backspace beendet die aktuell laufende X-Sitzung, während Control-Alt in Verbindung mit einer Funktionstaste zur zugehörigen virtuellen Konsole wechselt .

Implementierungen

Die X.Org-Referenzimplementierung dient als kanonische Implementierung von X. Aufgrund der liberalen Lizenzierung sind eine Reihe von Variationen erschienen, sowohl kostenlose als auch proprietäre. Kommerzielle UNIX-Anbieter neigen dazu, die Referenzimplementierung zu nehmen und sie an ihre Hardware anzupassen, indem sie sie normalerweise stark anpassen und proprietäre Erweiterungen hinzufügen.

Bis 2004 war XFree86 die am weitesten verbreitete X-Variante auf freien Unix-ähnlichen Systemen. XFree86 begann als X-Portierung für 386-kompatible PCs und war Ende der 1990er Jahre zur größten Quelle technischer Innovationen in X und den USA geworden de facto Verwalter der X-Entwicklung . Seit 2004 hat sich jedoch die X.Org-Referenzimplementierung, ein Fork von XFree86, durchgesetzt.

Während Computerliebhaber X am häufigsten mit Unix assoziieren, existieren X-Server auch nativ in anderen grafischen Umgebungen. Das OpenVMS-Betriebssystem von Hewlett-Packard enthält eine Version von X mit CDE, bekannt als DECwindows, als Standard-Desktop-Umgebung. Apples Mac OS X v10.3 (Panther) und höher enthält X11.app, basierend auf XFree86 4.3 und X11R6.6, mit besserer Mac OS X-Integration. Server von Drittanbietern unter Macintosh System 7, 8 und 9 enthalten MacX.

Microsoft Windows bietet keine Unterstützung für X, aber es gibt viele Implementierungen von Drittanbietern, beides freie Software wie Cygwin/X, Xming, WeirdMind und WeirdX; und proprietäre Produkte wie Xmanager, X-Deep/32, WiredX, Exceed und X-Win32. Sie dienen normalerweise dazu, entfernte X-Clients zu steuern.

Wenn ein anderes Windowing-System (wie das von Microsoft Windows oder Mac OS) X hostet, läuft das X-System im Allgemeinen 'rootless', was bedeutet, dass die Host-Windowing-Umgebung sich um das Root-Fenster (den Hintergrund und die zugehörigen Menüs) kümmert und die Geometrie von verwaltet gehostete X-Fenster – obwohl einige Server (z. B. Exceed) auch das Root-Fenster erstellen können, damit die Remote-Clients es als separates Fenster im Hostsystem anzeigen können.

X-Terminals

Ein NCD-88k X-Terminal von Network Computing Devices.

Ein X-Terminal ist ein Smart Terminal, auf dem ein X-Server als Thin Client läuft. Diese Architektur wurde populär, um kostengünstige Terminalparks zu erstellen, in denen viele Benutzer gleichzeitig denselben großen Server verwenden können. Diese Verwendung stimmt sehr gut mit der ursprünglichen Absicht des MIT-Projekts überein.

X-Terminals erkunden das Netzwerk (die lokale Broadcast-Domäne) unter Verwendung des X Display Manager Control Protocol, um eine Liste verfügbarer Hosts zu generieren, von denen sie Clients ausführen können. Der anfängliche Host muss einen X-Display-Manager ausführen.

Dedizierte (Hardware-)X-Terminals sind seltener geworden; Ein PC mit einem X-Server bietet in der Regel die gleiche Funktionalität zu geringeren Kosten.

Einschränkungen und Kritik an X

Das UNIX-HATERS-Handbuch widmete ein ganzes Kapitel, 'The X-Windows Disaster', den Problemen von X in den späten 1980er und frühen 1990er Jahren. Warum X nicht unser ideales Fenstersystem ist (1990) von Gajewska, Manasse und McCormack detailliert Probleme im Protokoll mit Empfehlungen zur Verbesserung.

Videohardware

Der Leistungsvorsprung für grafische Berechnungen liegt jetzt in den fortschrittlichsten Grafikfunktionen. Hersteller implementieren diese normalerweise in proprietären Treibern und schreiben im Allgemeinen für Windows (der größte Verbrauchermarkt) zuerst. XFree86 und der X.Org-Server haben rückentwickelte Treiber für viele ältere Karten. Da der Markt für Hochleistungsvideos jedoch Produkte auf dem neuesten Stand der Technik anbietet, betrachten einige Anbieter Programmierdetails als Geschäftsgeheimnisse oder als patentierbare Erfindungen, die sie nicht preisgeben möchten.

Funktionen der Benutzeroberfläche

X enthält absichtlich keine Spezifikation hinsichtlich der Benutzeroberfläche oder der meisten Kommunikation zwischen Anwendungen. Dies hat zu mehreren sehr unterschiedlichen Schnittstellen und zu Anwendungen geführt, die nicht immer ganz zusammengearbeitet haben. Das ICCCM, eine Spezifikation für Client-Interoperabilität, hat den Ruf, schwierig korrekt zu implementieren zu sein. Weitere Bemühungen um Standards wie Motif und CDE brachten keine Abhilfe. Dies hat Benutzer und Programmierer lange Zeit frustriert. Grafikprogrammierer adressieren nun im Allgemeinen die Konsistenz des Look-and-Feel und der Kommunikation der Anwendung, indem sie für eine spezifische Desktop-Umgebung oder für ein spezifisches Widget-Toolkit codieren, was auch vermeidet, sich direkt mit dem ICCCM befassen zu müssen.

Das X-Protokoll bietet keine Möglichkeiten zum Umgang mit Ton, sondern überlässt es dem Betriebssystem, Unterstützung für Audiohardware und Tonwiedergabe bereitzustellen. Da Benutzer zunehmend Sound erwarten, hat dies zu verschiedenen inkompatiblen Sound-Subsystemen geführt. Die meisten Programmierer verwenden einfach lokale, betriebssystemspezifische Sound-APIs. Die erste Generation von Client-Server-Soundsystemen umfasste rplay und Network Audio System. Neuere Bemühungen haben EsounD (GNOME) und ARts (KDE) hervorgebracht. 2001 kündigte die X.org Foundation die Entwicklung des Media Application Server ( ABER ) um dieses Problem zu beheben. Keines davon wird jedoch im Allgemeinen als Lösung für das Problem verwendet.

Netzwerk

Beispiel für das Tunneln einer X11-Anwendung über SSH.

Derzeit ist es nicht möglich, einen X-Client oder eine X-Sitzung von einem Server zu trennen und an einen anderen anzuschließen, wie es beim Virtual Network Computing (VNC) der Fall ist. Es wurde damit begonnen, diese Funktion zu X hinzuzufügen. Problemumgehungen ( VNC :0 Zuschauer ) vorhanden, um den aktuellen X-Server-Bildschirm über VNC verfügbar zu machen.

Der Netzwerkverkehr zwischen einem X-Server und entfernten X-Clients hat keine Standardverschlüsselung. Ein Angreifer mit einem Packet-Sniffer kann es abfangen und auslesen. Die meisten Benutzer lösen dieses Problem, indem sie X über SSH tunneln; Die meisten SSH-Implementierungen unterstützen das Tunneln von X-Anwendungen, obwohl es manchmal standardmäßig deaktiviert ist.

Client-Server-Trennung

Das Design von X erfordert, dass Clients und Server separat betrieben werden, und die Geräteunabhängigkeit und die Trennung von Client und Server verursachen Overhead im Vergleich zu einem Betriebssystem, bei dem die Grafik in das Betriebssystem integriert ist, wie z. B. frühe Versionen von Microsoft Windows oder MacOS. X-Befürworter empfahlen 4 bis 8 MB RAM für eine angemessene Leistung; bis Mitte der 1990er Jahre wirkte dies im Vergleich zu Windows oder Mac OS aufgebläht.

Aktuelle Versionen von Windows und Mac OS X Quartz haben eine interne Subsystem-Trennung ähnlich der Client/Server-Trennung in X und eine vergleichbare Leistung und Ressourcennutzung wie X mit KDE oder Gnom . Der größte Teil des Overheads entsteht durch die Netzwerk-Round-Trip-Verzögerungszeit zwischen Client und Server (Latenzzeit und nicht durch das Protokoll selbst): Die besten Lösungen für Leistungsprobleme beinhalten die Beachtung des Anwendungsdesigns . Ein weit verbreiteter Irrtum ist, dass die Netzwerkfunktionen von X zu übermäßiger Komplexität führen, wenn sie nur lokal verwendet werden, und dass die Netzwerkfunktionen von X zu einem unerwünschten Leistungseinbruch führen. Moderne X-Implementierungen verwenden lokale Sockets und gemeinsam genutzten Speicher, was sehr wenig Overhead erfordert.

Konkurrenten von X

Für die Grafik verwenden Unix-ähnliche Systeme fast überall X. Dennoch haben einige Leute versucht, Alternativen und Ersatz für X zu schreiben. Zu den historischen Alternativen gehören NeWS von Sun, das auf dem Markt scheiterte, und Display PostScript von NeXT, das schließlich zu Apples Quartz für Mac OS X wurde.

Moderne Versuche, der Kritik an X entgegenzuwirken, indem sie es vollständig ersetzen, umfassen Berlin/Fresco und das Y Window System. Diese Alternativen haben jedoch nur eine vernachlässigbare Akzeptanz erfahren, und Kommentatoren bezweifeln weitgehend die Realisierbarkeit eines Ersatzes, der die Abwärtskompatibilität mit X nicht bewahrt.

Andere Konkurrenten versuchen, den Overhead von X zu vermeiden, indem sie direkt mit der Hardware arbeiten. Zu solchen Projekten gehören DirectFB und das sehr kleine FBUI. Die Direct Rendering Infrastructure, die darauf abzielt, eine zuverlässige Kernel-Level-Schnittstelle zum Framebuffer bereitzustellen, kann diese Bemühungen überflüssig machen.

Andere Möglichkeiten, um Netzwerktransparenz für grafische Dienste zu erreichen, umfassen:

• das SVG-Terminal, ein Protokoll zum Aktualisieren von Scalable Vector Graphics (SVG)-Inhalten in einem Browser nahezu in Echtzeit
• Virtual Network Computing (VNC), ein System auf sehr niedriger Ebene, das komprimierte Bitmaps über das Netzwerk sendet; Die Unix-Implementierung enthält einen X-Server
• Citrix MetaFrame, ein X-ähnliches Produkt für Microsoft Windows
• Tarantella, das einen Java-Client zur Verwendung in Webbrowsern bereitstellt

Geschichte

Vorgänger

Mehrere Bitmap-Anzeigesysteme gingen X voraus. Von Xerox kamen der Alto (1973) und der Star (1981). Von Apple kamen die Lisa (1983) und die Macintosh (1984). Das Unix Welt hatte das Andrew Project (1982) und Rob Pikes Blit Terminal (1984).

X leitet seinen Namen als Nachfolger eines Fenstersystems namens W aus der Zeit vor 1983 ab (der Buchstabe X folgt direkt auf W in der Lateinisches Alphabet ). W Window System lief unter dem V-Betriebssystem. W verwendete ein Netzwerkprotokoll, das Terminal- und Grafikfenster unterstützte, wobei der Server Anzeigelisten verwaltete.

Herkunft und frühe Entwicklung

Die ursprüngliche Idee von X entstand 1984 am MIT als Zusammenarbeit zwischen Jim Gettys (vom Project Athena) und Bob Scheifler (vom MIT Laboratory for Computer Science). Scheifler benötigte eine brauchbare Anzeigeumgebung zum Debuggen des Argus-Systems. Project Athena (ein gemeinsames Projekt von Digital Equipment Corporation (DEC), MIT und IBM zur Bereitstellung eines einfachen Zugriffs auf Computerressourcen für alle Studenten) benötigte ein plattformunabhängiges Grafiksystem, um seine heterogenen Systeme mehrerer Anbieter miteinander zu verbinden; Das Fenstersystem, das damals im Andrew Project der Carnegie Mellon University entwickelt wurde, stellte keine Lizenzen zur Verfügung, und es gab keine Alternativen.

Das Projekt löste dies, indem es ein Protokoll erstellte, das sowohl lokale Anwendungen ausführen als auch entfernte Ressourcen aufrufen konnte. Mitte 1983 lief eine erste Portierung von W nach Unix mit einem Fünftel der Geschwindigkeit unter V; Im Mai 1984 ersetzte Scheifler das synchrone Protokoll von W durch ein asynchrones Protokoll und die Anzeigelisten durch Grafiken im Sofortmodus, um X Version 1 zu erstellen. X wurde die erste Fenstersystemumgebung, die echte Hardware- und Herstellerunabhängigkeit bot.

Scheifler, Gettys und Ron Newman machten sich an die Arbeit und X machte schnell Fortschritte. Sie veröffentlichten Version 6 im Januar 1985. DEC, das sich damals auf die Veröffentlichung seiner ersten Ultrix-Workstation vorbereitete, beurteilte X als das einzige Fenstersystem, das wahrscheinlich rechtzeitig verfügbar werden würde. DEC-Ingenieure haben X6 auf das QVSS-Display von DEC auf MicroVAX portiert.

Im zweiten Quartal 1985 erwarb X Farbunterstützung, um in DEC VAXstation-II/GPX zu funktionieren, was Version 9 bildete. Obwohl das MIT X6 gegen eine Gebühr an einige externe Gruppen lizenziert hatte, entschied es sich zu diesem Zeitpunkt, X9 und Zukunft zu lizenzieren Versionen unter der sogenannten MIT-Lizenz. X9 erschien im September 1985.

Eine Gruppe an der Brown University portierte Version 9 auf den IBM RT/PC, aber Probleme beim Lesen nicht ausgerichteter Daten auf dem RT erzwangen eine inkompatible Protokolländerung, die Ende 1985 zu Version 10 führte. Bis 1986 hatten externe Organisationen begonnen, nach X zu fragen die Veröffentlichung von X10R2 fand im Januar 1986 statt; die von X10R3 im Februar 1986. X10R3 war die erste Version, die eine breite Bereitstellung erreichte, wobei sowohl DEC als auch Hewlett-Packard darauf basierende Produkte veröffentlichten. Andere Gruppen portierten X10 auf Apollo und auf Sun-Workstations und sogar auf IBM PC/AT. Demonstrationen der ersten kommerziellen Anwendung für X (ein mechanisches Computer-Aided-Engineering-System, das auf VAXs lief und auf PCs angezeigt wurde, auf denen ein X-Server lief) fanden damals auf der Autofact-Messe statt. Die letzte Version von X10, X10R4, erschien im Dezember 1986.

Obwohl X10 interessante und leistungsstarke Funktionen bot, war offensichtlich geworden, dass das X-Protokoll ein hardwareneutraleres Redesign gebrauchen könnte, bevor es zu weit verbreitet wird; aber das MIT allein hätte nicht die Ressourcen für eine solche komplette Neugestaltung zur Verfügung. Zufällig fand sich das Western Software Laboratory von DEC zwischen den Projekten wieder. Smokey Wallace von DEC WSL und Jim Gettys schlugen vor, dass DEC WSL X11 bauen und es unter den gleichen Bedingungen wie X9 und X10 frei verfügbar machen sollte. Dieser Prozess begann im Mai 1986, und das Protokoll wurde im August fertiggestellt. Der Alpha-Test der Software begann im Februar 1987, der Beta-Test im Mai; die Veröffentlichung von X11 erfolgte schließlich am 15. September 1987.

Das Design des X11-Protokolls unter der Leitung von Scheifler wurde während seiner Entstehung auf offenen Mailinglisten ausführlich diskutiert Internet . X stellt damit eines der ersten sehr großen Freie-Software-Projekte dar.

Das MIT X Consortium und das X Consortium, Inc.

1987, als sich der Erfolg von X11 abzeichnete, wollte das MIT die Führung von X aufgeben, aber bei einem Treffen im Juni 1987 mit neun Anbietern teilten die Anbieter dem MIT mit, dass sie an die Notwendigkeit einer neutralen Partei glaubten, um zu verhindern, dass X zersplittert der Markt. Im Januar 1988 wurde die MIT X-Konsortium als gemeinnützige Verkäufergruppe mit Scheifler als Direktor gegründet, um die zukünftige Entwicklung von X in einer neutralen Atmosphäre unter Einbeziehung kommerzieller und pädagogischer Interessen zu lenken. Jim Fulton kam im Januar 1988 und Keith Packard im März 1988 als leitende Entwickler hinzu, wobei Jim sich auf Xlib, Schriftarten, Fenstermanager und Dienstprogramme konzentrierte; und Keith, der den Server neu implementiert. Donna Converse und Chris Peterson kamen später in diesem Jahr hinzu, konzentrierten sich auf Toolkits und Widget-Sets und arbeiteten eng mit Ralph Swick vom MIT Project Athena zusammen. Das MIT X Consortium produzierte mehrere bedeutende Überarbeitungen von X11, die erste (Release 2 - X11R2) im Februar 1988.

1993 wurde das X Consortium, Inc. (eine gemeinnützige Gesellschaft) als Nachfolger des MIT X Consortium gegründet. Es veröffentlichte X11R6 am 16. Mai 1994. 1995 übernahm es die Verwaltung des Motif-Toolkits und der Common Desktop Environment für Unix-Systeme. Das X-Konsortium löste sich Ende 1996 auf und produzierte eine endgültige Überarbeitung, X11R6.3, und ein Vermächtnis mit zunehmendem kommerziellen Einfluss auf die Entwicklung.

Die Offene Gruppe

Mitte 1997 übergab das X Consortium die Verwaltung von X an The Open Group, eine Anbietergruppe, die Anfang 1996 durch die Fusion der Open Software Foundation und X/Open gegründet wurde.

Die Open Group veröffentlichte X11R6.4 Anfang 1998. Umstritten war, dass X11R6.4 von den traditionellen liberalen Lizenzbedingungen abwich, da die Open Group versuchte, die Finanzierung der Entwicklung von X sicherzustellen. Die neuen Bedingungen hätten seine Übernahme durch viele Projekte (wie XFree86) und sogar durch einige kommerzielle Anbieter verhindert. Nachdem XFree86 mit einem Fork gedroht hatte, lizenzierte die Open Group X11R6.4 im September 1998 unter der traditionellen Lizenz neu. Die letzte Veröffentlichung der Open Group kam als X11R6.4 Patch 3.

X.Org und XFree86

XFree86 entstand 1992 aus dem X386-Server für IBM-PC-kompatible Geräte, der 1991 in X11R5 enthalten war, von Thomas Roell und Mark W. Snitily geschrieben und von Snitily Graphics Consulting Services (SGCS) an das MIT X Consortium gespendet wurde. XFree86 entwickelte sich im Laufe der Zeit von nur einer Portierung von X zur führenden und beliebtesten Implementierung und der de facto Verwalter der Entwicklung von X .

Im Mai 1999 gründete die Open Group X.Org. X.Org überwachte die Veröffentlichung der Versionen X11R6.5.1 und höher. Die X-Entwicklung war zu dieser Zeit sterbend geworden; Die meisten technischen Neuerungen seit der Auflösung des X-Konsortiums fanden im XFree86-Projekt statt. 1999 trat das XFree86-Team X.Org als ehrenamtliches (nicht zahlendes) Mitglied bei, ermutigt von verschiedenen Hardware-Unternehmen, die an der Verwendung von XFree86 mit Linux und seinem Status als beliebteste Version von X interessiert waren.

Bis 2003, als die Popularität von Linux (und damit die installierte Basis von X) anstieg, blieb X.Org so gut wie inaktiv, und die aktive Entwicklung fand größtenteils innerhalb von XFree86 statt. Innerhalb von XFree86 entwickelte sich jedoch ein beträchtlicher Dissens. Das XFree86-Projekt litt unter der Wahrnehmung eines viel zu kathedralenartigen Entwicklungsmodells; Entwickler konnten keinen Zugriff auf CVS-Commits erhalten und Anbieter mussten umfangreiche Patch-Sets verwalten. Im März 2003 schloss die XFree86-Organisation Keith Packard aus, der nach dem Ende des ursprünglichen MIT X-Konsortiums XFree86 beigetreten war, mit beträchtlichem Unmut.

X.Org und XFree86 begannen, eine Reorganisation zu diskutieren, die geeignet war, die Entwicklung von X angemessen zu fördern. Jim Gettys drängt seit mindestens 2000 stark auf ein offenes Entwicklungsmodell. Gettys, Packard und mehrere andere begannen, die Anforderungen für eine effektive Steuerung von X mit offener Entwicklung im Detail zu diskutieren.

Als Echo des X11R6.4-Lizenzstreits schließlich veröffentlichte XFree86 im Februar 2004 Version 4.4 unter einer eingeschränkteren Lizenz, die viele Projekte, die sich auf X stützten, für inakzeptabel hielten. Die hinzugefügte Klausel zur Lizenz basierte auf der Werbeklausel der ursprünglichen BSD-Lizenz, die von der Free Software Foundation und Debian als unvereinbar mit der GNU General Public License angesehen wurde. Andere Gruppen sahen weitere Einschränkungen als gegen den Geist des ursprünglichen X ( OpenBSD zum Beispiel eine Fork bedrohen). Das Lizenzproblem, kombiniert mit den Schwierigkeiten, Änderungen einzubringen, ließ viele das Gefühl haben, die Zeit sei reif für einen Fork.

Die X.Org-Stiftung

Anfang 2004 gründeten verschiedene Leute von X.Org und freedesktop.org die X.Org Foundation, und die Open Group gab ihr die Kontrolle über den Domainnamen. Dies markierte eine radikale Änderung in der Governance von X. Während die Verwalter von X seit 1988 (einschließlich der vorherigen X.Org) Anbieterorganisationen waren, wurde die Foundation von Softwareentwicklern geleitet und verwendete Community-Entwicklung auf der Grundlage des Basarmodells, das sich darauf stützt auf externes Engagement. Die Mitgliedschaft wurde für Einzelpersonen geöffnet, wobei die Firmenmitgliedschaft in Form von Sponsoring erfolgte. Mehrere große Unternehmen wie Hewlett-Packard und Sun Microsystems unterstützen derzeit die X.Org Foundation.

Die Foundation übernimmt eine Aufsichtsrolle über die X-Entwicklung: Technische Entscheidungen werden nach ihrem Wert getroffen, indem ein grober Konsens unter den Community-Mitgliedern erreicht wird. Fachliche Entscheidungen werden nicht vom Vorstand getroffen; in diesem Sinne ist es stark an die technisch nicht eingreifende GNOME Foundation angelehnt. Die Stiftung beschäftigt keine Entwickler.

Die Foundation veröffentlichte im April 2004 X11R6.7, den X.Org-Server, basierend auf XFree86 4.4RC2, wobei die Änderungen von X11R6.6 zusammengeführt wurden. Gettys und Packard hatten die letzte Version von XFree86 unter die alte Lizenz genommen und durch die Betonung eines offenen Entwicklungsmodells und die Beibehaltung der GPL-Kompatibilität viele der alten XFree86-Entwickler an Bord geholt.

X11R6.8 kam im September 2004 auf den Markt. Es fügte bedeutende neue Funktionen hinzu, darunter vorläufige Unterstützung für durchscheinende Fenster und andere raffinierte visuelle Effekte, Bildschirmlupen und Thumbnails sowie Möglichkeiten zur Integration mit immersiven 3D-Anzeigesystemen wie Sun's Project Looking Glass und The Croquet Projekt. Externe Anwendungen aufgerufen Compositing-Manager Richtlinien für das visuelle Erscheinungsbild bereitstellen.

Zukünftige Richtungen

Mit der X.Org Foundation und freedesktop.org hat die Hauptlinie der X-Entwicklung wieder begonnen, schnell voranzukommen. Die Entwickler beabsichtigen, aktuelle und zukünftige Versionen als brauchbare fertige Produkte zu veröffentlichen, nicht nur als Basis für Anbieter, auf denen sie ein Produkt aufbauen können.

Am 21. Dezember 2005 veröffentlichte X.Org X11R6.9, den monolithischen Quellbaum für ältere Benutzer, und X11R7.0, denselben Quellcode, der in unabhängige Module unterteilt ist, die jeweils in separaten Projekten gewartet werden können. Die Foundation veröffentlichte X11R7.1 am 22. Mai 2006, etwa vier Monate nach 7.0, mit erheblichen Funktionsverbesserungen.

Für ausreichend leistungsfähige Kombinationen aus Hardware und Betriebssystemen plant X.Org, auf die Videohardware nur über OpenGL und die Direct Rendering Infrastructure (DRI) zuzugreifen. Der DRI erschien zuerst in XFree86 Version 4.0 und wurde in X11R6.7 und später zum Standard. Viele Betriebssysteme haben damit begonnen, Kernel-Unterstützung für Hardware-Manipulationen hinzuzufügen. Diese Arbeit geht schrittweise vor.

Nomenklatur

Leute in der Computerbranche kürzen den Ausdruck 'X Window System' üblicherweise zu 'X11' oder einfach zu 'X'. Der Begriff 'X Windows' (in der Art von 'Microsoft Windows') wird nicht offiziell unterstützt, obwohl er seit dem frühen Beginn der Geschichte von X allgemein verwendet wird und absichtlich für literarische Effekte verwendet wurde, beispielsweise in der UNIX-HATERS-Handbuch .

Release-Geschichte

Ausführung	Veröffentlichungsdatum	Wichtigste Änderungen
X1	Juni 1984	Erste Verwendung des Namens „X“; grundlegende Änderungen, die das Produkt von W.
X6	Januar 1985	Erste Version, die an eine Handvoll externer Unternehmen lizenziert wurde.
X9	September 1985	Farbe. Erste Veröffentlichung unter MIT-Lizenz.
X10	Ende 1985	IBM RT/PC, AT (mit DOS) und andere
X10R2	Januar 1986
X10R3	Februar 1986	Erste Veröffentlichung außerhalb des MIT. uwm hat einen Standard-Fenstermanager erstellt.
X10R4	Dezember 1986	Letzte Version von X10.
X11	15. September 1987	Erste Veröffentlichung des aktuellen Protokolls.
X11R2	Februar 1988	Erste Veröffentlichung des X Consortiums.
X11R3	25. Oktober 1988	XDM
X11R4	22. Dezember 1989	XDMCP, twm als Standard-Fenstermanager eingeführt, Anwendungsverbesserungen, Shape-Erweiterung, neue Schriftarten.
X11R5	5. September 1991	PEX, Xcms (Farbmanagement), Schriftartserver, X386, X-Videoerweiterung
X11R6	16. Mai 1994	ICCCM v2.0; Inter-Client-Austausch; X-Sitzungsverwaltung; X Synchronisationserweiterung; X Bilderweiterung; XTEST-Erweiterung; X-Eingang; X Große Anfragen; XC-MISC; XFree86-Änderungen.
X11R6.1	14. März 1996	X Double Buffer-Erweiterung; X-Tastaturerweiterung; X Datensatzerweiterung.
X11R6.2 X11R6.3 (Broadway)	23. Dezember 1996	Webfunktionalität, LBX. Letzte Veröffentlichung des X-Konsortiums. X11R6.2 ist das Tag für eine Teilmenge von X11R6.3, wobei die einzigen neuen Funktionen gegenüber R6.1 XPrint und die Xlib-Implementierung für vertikales Schreiben und benutzerdefinierte Zeichenunterstützung sind.
X11R6.4	31. März 1998	Xinerama.
X11R6.5		Interne X.org-Veröffentlichung; nicht öffentlich zugänglich gemacht.
X11R6.5.1	20. August 2000
X11R6.6	4. April 2001	Fehlerbehebungen, XFree86-Änderungen.
X11R6.7.0	6. April 2004	Erste Veröffentlichung der X.Org Foundation, die XFree86 4.4rc2 enthält. Vollständige Endbenutzerverteilung. Entfernung von XIE, PEX und libxml2.
X11R6.8.0	8. September 2004	Fenstertransparenz, XDamage, Distributed Multihead X, XFixes, Composite, XEvIE.
X11R6.8.1	17. September 2004	Sicherheitsfix in libxpm.
X11R6.8.2	10. Februar 2005	Fehlerbehebungen, Treiber-Updates.
X11R6.9 X11R7.0	21. Dezember 2005	EXA, Umgestaltung des Hauptquellcodes . Aus derselben Quellcode-Basis wurde die modulare Autotool-Version 7.0 und die monolithische Imake-Version wurde bei 6.9 eingefroren.
X11R7.1	22. Mai 2006	EXA-Verbesserungen, integriertes KDrive, Verbesserungen der AIGLX-, Betriebssystem- und Plattformunterstützung .
X11R7.2	2006	Entfernung von LBX und dem eingebauten Tastaturtreiber, X-ACE, XCB, Autokonfigurationsverbesserungen, Aufräumarbeiten.