X Fenstersystem - X Window System

X Window-System

twm - der Standard-X11- Fenstermanager
Originalautor(en)	Projekt Athena
Entwickler	X.Org-Stiftung
Erstveröffentlichung	Juni 1984 ; Vor 37 Jahren ( 1984-06 )
Stabile Version	X11R7.7 / 6. Juni 2012 ; Vor 9 Jahren ( 2012-06-06 )
Betriebssystem	Unix , Unix-ähnlich , MVS OpenVMS , DOS
Plattform	Plattformübergreifend
Vorgänger	W Fenstersystem
Typ	Fenstersystem
Lizenz	MIT-Lizenz
Webseite	x .org

Das X Window System ( X11 oder einfach X ) ist ein Fenstersystem für Bitmap-Anzeigen, das bei Unix-ähnlichen Betriebssystemen üblich ist.

X bietet das Grundgerüst für eine GUI-Umgebung: Zeichnen und Verschieben von Fenstern auf dem Anzeigegerät und Interaktion mit Maus und Tastatur. X schreibt die Benutzeroberfläche nicht vor – dies wird von einzelnen Programmen gehandhabt. Daher variiert der visuelle Stil von X-basierten Umgebungen stark; verschiedene Programme können radikal unterschiedliche Schnittstellen aufweisen.

X entstand 1984 als Teil des Project Athena am Massachusetts Institute of Technology (MIT). Das X-Protokoll hat seit September 1987 die Version 11 (daher "X11"). Die X.Org Foundation leitet das X-Projekt mit der aktuellen Referenz Implementierung, X.Org Server, verfügbar als freie und Open-Source-Software unter der MIT-Lizenz und ähnlichen freizügigen Lizenzen.

Zweck und Fähigkeiten

X ist ein architekturunabhängiges System für entfernte grafische Benutzeroberflächen und Eingabegerätefunktionen. Jede Person, die ein vernetztes Endgerät verwendet, hat die Möglichkeit, mit jeder Art von Benutzereingabegerät mit dem Display zu interagieren.

In seiner Standarddistribution ist es eine vollständige, wenn auch einfache Display- und Schnittstellenlösung, die ein Standard- Toolkit und einen Protokollstack zum Erstellen grafischer Benutzeroberflächen auf den meisten Unix-ähnlichen Betriebssystemen und OpenVMS bietet und auf viele andere moderne Allzweck- Betriebssysteme portiert wurde Systeme .

X stellt den grundlegenden Rahmen oder Primitiven, für solche GUI - Umgebungen Aufbau: Zeichnen und Verschieben von Fenstern auf dem Display und mit einer Maus, Tastatur oder Touchscreen interagieren. X schreibt die Benutzeroberfläche nicht vor ; individuelle Client-Programme übernehmen dies. Programme können die grafischen Fähigkeiten von X ohne Benutzeroberfläche verwenden. Daher variiert der visuelle Stil von X-basierten Umgebungen stark; verschiedene Programme können radikal unterschiedliche Schnittstellen aufweisen.

Im Gegensatz zu den meisten früheren Anzeigeprotokollen wurde X speziell für die Verwendung über Netzwerkverbindungen und nicht auf einem integrierten oder angeschlossenen Anzeigegerät entwickelt. X bietet Netzwerktransparenz , was bedeutet, dass ein X-Programm, das auf einem Computer irgendwo in einem Netzwerk (wie dem Internet) ausgeführt wird, seine Benutzeroberfläche auf einem X-Server anzeigen kann, der auf einem anderen Computer im Netzwerk läuft. Der X-Server ist normalerweise der Anbieter von Grafikressourcen und Tastatur-/Maus-Ereignissen für X- Clients , was bedeutet, dass der X-Server normalerweise auf dem Computer vor einem menschlichen Benutzer ausgeführt wird, während die X-Client-Anwendungen überall im Netzwerk ausgeführt werden und mit kommunizieren den Computer des Benutzers, um das Rendern von Grafikinhalten anzufordern und Ereignisse von Eingabegeräten einschließlich Tastaturen und Mäusen zu empfangen.

Die Tatsache, dass der Begriff "Server" für die Software vor dem Benutzer verwendet wird, überrascht oft Benutzer, die daran gewöhnt sind, dass ihre Programme Clients für Dienste auf entfernten Computern sind. Anstatt eine Remote-Datenbank als Ressource für eine lokale App zu verwenden, werden die grafischen Anzeige- und Eingabegeräte des Benutzers zu Ressourcen, die vom lokalen X-Server sowohl lokalen als auch remote gehosteten X-Client-Programmen zur Verfügung gestellt werden, die die Grafiken und Eingabegeräte des Benutzers freigeben müssen mit dem Benutzer zu kommunizieren.

Das Netzwerkprotokoll von X basiert auf X-Befehlsprimitiven. Dieser Ansatz ermöglicht, dass sowohl 2D- als auch (durch Erweiterungen wie GLX) 3D-Operationen durch eine X-Client-Anwendung, die möglicherweise auf einem anderen Computer ausgeführt wird, auf der Anzeige des X-Servers noch vollständig beschleunigt werden. Im klassischen OpenGL (vor Version 3.0) konnten beispielsweise Anzeigelisten mit einer großen Anzahl von Objekten erstellt und vollständig auf dem X-Server von einem entfernten X-Client-Programm gespeichert und dann durch Senden einer einzelnen glCallList (welche) über die gesamte Netzwerk.

X bietet keine native Unterstützung für Audio; Es gibt mehrere Projekte, um diese Nische zu füllen, einige bieten auch eine transparente Netzwerkunterstützung .

Softwarearchitektur

Einfaches Beispiel: Der X-Server empfängt Eingaben von einer lokalen Tastatur und Maus und zeigt sie auf einem Bildschirm an. Ein Webbrowser und ein Terminalemulator laufen auf der Workstation des Benutzers und ein Terminalemulator läuft auf einem Remote-Computer, wird jedoch vom Computer des Benutzers aus gesteuert und überwacht

X verwendet ein Client-Server-Modell: Ein X-Server kommuniziert mit verschiedenen Client- Programmen. Der Server akzeptiert Anforderungen für die grafische Ausgabe (Windows) und sendet Benutzereingaben (von Tastatur, Maus oder Touchscreen) zurück. Der Server kann funktionieren als:

• 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 ist der Server und die Anwendungen die Clients – verwirrt neue X-Benutzer oft, weil die Begriffe umgekehrt erscheinen. Aber X nimmt die Perspektive der Anwendung und nicht die des Endbenutzers ein: X stellt Anwendungen Anzeige- und E/A-Dienste bereit, ist also ein Server; Anwendungen nutzen diese Dienste, sind also Clients.

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

Ein X-Client selbst kann einen X-Server emulieren, indem er anderen Clients Anzeigedienste bereitstellt. Dies wird als "X-Verschachtelung" bezeichnet. Open-Source-Clients wie Xnest und Xephyr unterstützen diese X-Verschachtelung.

Um eine X-Client-Anwendung auf einem Remote-Computer zu verwenden, kann der Benutzer Folgendes tun:

• Öffnen Sie auf dem lokalen Computer ein Terminalfenster
• Verwenden Sie ssh mit dem X-Weiterleitungsargument, um eine Verbindung zum Remote-Rechner herzustellen
• lokalen Anzeige-/Eingabedienst anfordern (z. B. wenn SSH nicht mit aktivierter X-Weiterleitung verwendet wird)export DISPLAY=[user's machine]:0

Die entfernte X-Client-Anwendung stellt dann eine Verbindung zum lokalen X-Server des Benutzers her und stellt dem Benutzer Anzeige und Eingabe bereit.

Alternativ kann der lokale Computer ein kleines Programm ausführen, das eine Verbindung zum entfernten Computer herstellt und die Client-Anwendung startet.

Praktische Beispiele für Remote-Clients sind:

• Grafische Verwaltung eines Remote-Computers (ähnlich wie Remote-Desktop, jedoch mit einzelnen Fenstern)
• Verwenden einer Client-Anwendung, um sich mit einer großen Anzahl anderer Terminalbenutzer in kollaborativen Arbeitsgruppen zusammenzuschließen
• Ausführen einer rechenintensiven Simulation auf einem Remote-Rechner und Anzeige der Ergebnisse auf einem lokalen Desktop-Rechner
• Ausführen von grafischer Software auf mehreren Computern gleichzeitig, gesteuert über ein einziges Display, Tastatur und Maus

Benutzeroberflächen

Grafische GNOME- Benutzeroberfläche

Grafische Xfce- Benutzeroberfläche

X definiert in erster Linie Protokoll- und Grafikprimitive – es enthält bewusst keine Spezifikation für das Design der Anwendungsbenutzeroberfläche, wie zum Beispiel Schaltflächen-, Menü- oder Fenstertitelleistenstile. Stattdessen definiert und stellt Anwendungssoftware – wie Window-Manager, GUI-Widget-Toolkits und Desktop-Umgebungen oder anwendungsspezifische grafische Benutzeroberflächen – solche Details bereit. Infolgedessen gibt es keine typische X-Schnittstelle und mehrere verschiedene Desktop-Umgebungen sind bei den Benutzern beliebt geworden.

Ein Fenstermanager steuert die Platzierung und Darstellung von Anwendungsfenstern. Dies kann zu Desktop-Oberflächen führen, die an die von Microsoft Windows oder an den Apple Macintosh erinnern (Beispiele sind GNOME 2, KDE, Xfce) oder radikal andere Steuerelemente haben (wie ein Kachelfenstermanager wie wmii oder Ratpoison). Einige Schnittstellen wie Sugar oder Chrome OS verzichten ganz auf die Desktop-Metapher und vereinfachen ihre Schnittstellen für spezialisierte Anwendungen. Window-Manager reichen in ihrer Komplexität und Komplexität von einfachen ( z. B. twm, dem grundlegenden Window-Manager, der mit X geliefert wird, oder evilwm, einem extrem leichten Window-Manager) über die umfassenderen Desktop-Umgebungen wie Enlightenment bis hin zu anwendungsspezifischen Window-Manager für vertikale Märkte wie Point-of-Sale.

Viele Benutzer verwenden X mit einer Desktop-Umgebung, die neben dem Window-Manager verschiedene Anwendungen mit einer einheitlichen Benutzeroberfläche enthält. Beliebte Desktop-Umgebungen sind GNOME , KDE Plasma und Xfce . Die Standardumgebung von UNIX 98 ist die 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 erforderlich sind.

Implementierungen

Die X.Org-Implementierung ist die kanonische Implementierung von X. Aufgrund der liberalen Lizenzierung sind eine Reihe von Varianten erschienen, sowohl freie als auch Open Source und proprietäre. Kommerzielle Unix-Anbieter neigen dazu, die Referenzimplementierung zu nehmen und sie für ihre Hardware anzupassen, sie normalerweise anzupassen und proprietäre Erweiterungen hinzuzufügen.

Bis 2004 stellte XFree86 die gängigste X-Variante auf freien Unix-ähnlichen Systemen zur Verfügung. XFree86 begann als Portierung von X auf 386-kompatible PCs und war Ende der 1990er Jahre die größte Quelle technischer Innovationen in X und der De-facto- Standard der X-Entwicklung. Seit 2004 hat sich jedoch der X.Org Server, ein Fork von XFree86, durchgesetzt.

Obwohl es üblich ist, X mit Unix zu assoziieren, existieren X-Server auch nativ in anderen grafischen Umgebungen. Das OpenVMS-Betriebssystem von VMS Software Inc. enthält eine Version von X mit Common Desktop Environment (CDE), bekannt als DECwindows, als Standard-Desktop-Umgebung. Apple hat X ursprünglich in Form von X11.app auf macOS portiert, aber das wurde zugunsten der XQuartz- Implementierung eingestellt. Zu den Servern von Drittanbietern unter den älteren Betriebssystemen von Apple in den 1990er Jahren, System 7 und Mac OS 8 und 9, gehörten Apples MacX und eXodus von White Pine Software.

Microsoft Windows wird nicht mit Unterstützung für X ausgeliefert, aber es gibt viele Implementierungen von Drittanbietern, wie kostenlose und Open-Source-Software wie Cygwin/X und proprietäre Produkte wie Exceed, MKS X/Server, Reflection X, X-Win32 und Xming .

Es gibt auch Java-Implementierungen von X-Servern. WeirdX läuft auf jeder Plattform, die Swing 1.1 unterstützt, und läuft als Applet in den meisten Browsern. Der Android X Server ist eine Open-Source-Java-Implementierung, die auf Android-Geräten ausgeführt wird.

Wenn ein Betriebssystem mit einem nativen Windowing-System X zusätzlich hostet, kann das X-System entweder seinen eigenen normalen Desktop in einem separaten Host-Fenster verwenden oder es kann rootless ausgeführt werden , d.h. der X-Desktop ist ausgeblendet und die Host-Windowing-Umgebung verwaltet die Geometrie und Darstellung der gehosteten X-Fenster innerhalb des Host-Bildschirms.

X-Klemmen

Ein X-Terminal ist ein Thin Client, der nur einen X-Server ausführt. Diese Architektur wurde populär, um kostengünstige Terminalparks für viele Benutzer zu bauen, um gleichzeitig denselben großen Computerserver zum Ausführen von Anwendungsprogrammen als Clients des X-Terminals jedes Benutzers zu verwenden. Diese Verwendung entspricht sehr der ursprünglichen Absicht des MIT-Projekts.

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, die als Clients zugelassen sind. Einer der Client-Hosts sollte einen X-Display-Manager ausführen .

Eine Einschränkung von X-Terminals und den meisten Thin Clients besteht darin, dass sie außer Tastatur, Maus und Anzeige keine anderen Ein- oder Ausgaben ausführen können. Es wird davon ausgegangen, dass alle relevanten Daten ausschließlich auf dem entfernten Server vorhanden sind, und dem X-Terminal-Benutzer stehen keine Methoden zur Verfügung, um Daten von einem lokalen Peripheriegerät zu speichern oder zu laden .

Dedizierte (Hardware) X-Terminals wurden nicht mehr verwendet; Ein PC oder moderner Thin Client mit einem X-Server bietet in der Regel die gleiche Funktionalität zu gleichen oder niedrigeren Kosten.

Einschränkungen und Kritik

Das Unix-Haters Handbook (1994) widmete den Problemen von X ein ganzes Kapitel. Why X Is Not Our Ideal Window System (1990) von Gajewska, Manasse und McCormack detailliert Probleme im Protokoll mit Empfehlungen zur Verbesserung.

Probleme mit der Benutzeroberfläche

Das Fehlen von Designrichtlinien in X hat zu sehr unterschiedlichen Schnittstellen und Anwendungen geführt, die nicht immer gut zusammengearbeitet haben. Das Inter-Client Communication Conventions Manual (ICCCM), eine Spezifikation für die Client-Interoperabilität, hat den Ruf, nur schwer korrekt zu implementieren. Weitere Normungsbemühungen wie Motif und CDE konnten die Probleme nicht lindern. Dies hat Benutzer und Programmierer frustriert. Grafikprogrammierer adressieren nun im Allgemeinen die Konsistenz des Look-and-Feel und der Kommunikation von Anwendungen , indem sie in eine bestimmte Desktop-Umgebung oder in ein bestimmtes Widget-Toolkit codieren, wodurch auch der direkte Umgang mit dem ICCCM vermieden wird.

X fehlt auch die native Unterstützung für benutzerdefinierte gespeicherte Prozeduren auf dem X-Server, ähnlich wie bei NeWS  – es gibt keine Turing-vollständige Skriptfunktion. Verschiedene Desktop-Umgebungen können daher ihre eigenen (meist untereinander inkompatiblen) Möglichkeiten bieten.

Probleme mit der Computerzugänglichkeit

Auf X basierende Systeme können Zugänglichkeitsprobleme aufweisen , die die Nutzung eines Computers für behinderte Benutzer erschweren, einschließlich Rechtsklick , Doppelklick , Mittelklick , Mouse-Over und Fokusstehlen . Einige X11-Clients gehen besser mit Zugänglichkeitsproblemen um als andere, sodass Personen mit Zugänglichkeitsproblemen nicht von der Verwendung von X11 ausgeschlossen sind. Für X11 gibt es jedoch keinen Barrierefreiheitsstandard oder Barrierefreiheitsrichtlinien. Innerhalb des X11-Standardprozesses gibt es keine Arbeitsgruppe für Barrierefreiheit, jedoch werden die Anforderungen an die Barrierefreiheit von Softwareprojekten adressiert, um diese Funktionen zusätzlich zu X bereitzustellen.

Das Orca- Projekt fügt dem X Window-System Unterstützung für Barrierefreiheit hinzu, einschließlich der Implementierung einer API ( AT-SPI ). Dies ist mit GNOMEs ATK gekoppelt , um die Implementierung von Barrierefreiheitsfunktionen in X-Programmen mithilfe der GNOME/GTK-APIs zu ermöglichen. KDE bietet einen anderen Satz von Eingabehilfen-Software, einschließlich eines Text-zu-Sprache-Konverters und einer Bildschirmlupe. Die anderen großen Desktops (LXDE, Xfce und Enlightenment) versuchen, mit ATK kompatibel zu sein.

Netzwerk

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

Ein X-Client kann im Allgemeinen nicht von einem Server getrennt und wieder an einen anderen angeschlossen werden, es sei denn, sein Code sieht dies ausdrücklich vor ( Emacs ist eines der wenigen gängigen Programme mit dieser Fähigkeit). Daher ist es im Allgemeinen nicht möglich, eine gesamte Sitzung von einem X-Server auf einen anderen zu verschieben. Ansätze wie Virtual Network Computing (VNC), NX und Xpra ermöglichen jedoch den Zugriff auf eine virtuelle Sitzung von verschiedenen X-Servern (ähnlich wie bei GNU Screen in Bezug auf Terminals), und andere Anwendungen und Toolkits bieten entsprechende Möglichkeiten. Workarounds wie x11vnc ( VNC :0 Viewer ), Xpras Shadow-Modus und NXs nxagent-Shadow-Modus sind ebenfalls vorhanden, um den aktuellen X-Server-Bildschirm verfügbar zu machen. Diese Fähigkeit ermöglicht es, die Benutzeroberfläche (Maus, Tastatur, Monitor) einer laufenden Anwendung von einem Ort zu einem anderen zu wechseln, ohne die Anwendung zu stoppen und neu zu starten.

Der Netzwerkverkehr zwischen einem X-Server und entfernten X-Clients wird standardmäßig nicht verschlüsselt. Ein Angreifer mit einem Paket-Sniffer kann es abfangen, wodurch es möglich wird, alles anzuzeigen, was auf dem Bildschirm des Benutzers angezeigt oder von ihm gesendet wird. Die gängigste Methode zum Verschlüsseln von X-Datenverkehr besteht darin, einen Secure Shell (SSH)-Tunnel für die Kommunikation einzurichten.

Wie bei allen Thin Clients können bei der Verwendung von X in einem Netzwerk Bandbreitenbeschränkungen die Verwendung von Bitmap- intensiven Anwendungen verhindern, die eine schnelle Aktualisierung großer Teile des Bildschirms mit geringer Latenz erfordern, wie z. B. 3D-Animationen oder Fotobearbeitung. Selbst ein relativ kleiner unkomprimierter 640x480x24 Bit 30 fps Videostream (~211 Mbit/s) kann die Bandbreite eines 100 Mbit/s Netzwerks für einen einzelnen Client locker übertreffen. Im Gegensatz dazu verfügen moderne Versionen von X im Allgemeinen über Erweiterungen wie MESA, die es ermöglichen, die lokale Anzeige der Grafiken eines lokalen Programms zu optimieren, um das Netzwerkmodell zu umgehen und die Grafikkarte direkt zu steuern, um Vollbildvideos, gerenderte 3D-Anwendungen und andere zu verwenden solche Anwendungen.

Client-Server-Trennung

Das Design von X erfordert, dass Clients und Server getrennt betrieben werden, und die Geräteunabhängigkeit und die Trennung von Client und Server verursachen Overhead. Der Großteil des Overheads kommt von der Netzwerk -Roundtrip-Verzögerungszeit zwischen Client und Server ( Latenz ) und nicht vom Protokoll selbst: Die besten Lösungen für Leistungsprobleme hängen von einem effizienten Anwendungsdesign ab. Eine häufige Kritik an X ist, dass seine Netzwerkfunktionen zu übermäßiger Komplexität und verringerter Leistung führen, wenn sie nur lokal verwendet werden.

Moderne X-Implementierungen verwenden Unix-Domain-Sockets für effiziente Verbindungen auf demselben Host. Für eine schnellere Client-Server-Kommunikation kann zusätzlich Shared Memory (über die MIT-SHM- Erweiterung) verwendet werden. Allerdings muss der Programmierer die Shared-Memory-Erweiterung noch explizit aktivieren und verwenden. Es ist auch notwendig, Fallback-Pfade bereitzustellen, um mit älteren Implementierungen kompatibel zu bleiben und um mit nicht lokalen X-Servern zu kommunizieren.

Konkurrenten

Einige Leute schreiben Alternativen versucht haben, und Ersatz für X. Historische Alternativen umfassen Sun ‚s NeWS und NeXT ‘ s Display Postscript , sowohl Postscript - basierte Systeme zur Unterstützung benutzerdefinierbaren Displayseite nach Verfahren, die X fehlte. Aktuelle Alternativen sind:

• macOS (und sein mobiles Gegenstück iOS ) implementiert sein Windowing-System, das als Quartz bekannt ist . Wenn Apple Inc. NeXT gekauft und verwendet Nextstep zu konstruieren , Mac OS X , ersetzt es Display Postscript mit Quarz . Mike Paquette , einer der Autoren von Quartz, erklärte, dass, wenn Apple alle Funktionen unterstützt hätte, die es in X11 enthalten wollte, es sowieso nicht viel Ähnlichkeit mit X11 hätte und auch nicht mit anderen Servern kompatibel wäre.
• Android , das auf dem Linux-Kernel läuft , verwendet ein eigenes System zum Zeichnen der als SurfaceFlinger bekannten Benutzeroberfläche . Das 3D-Rendering wird von EGL verarbeitet .
• Wayland wird von mehreren X.Org-Entwicklern als potenzieller Ersatz für X entwickelt. Es arbeitet über DRI direkt mit der GPU- Hardware zusammen . Wayland kann als Client einen X.org-Server betreiben, der rootlos sein muss. Eine proprietäre Portierung des Wayland-Backends auf den Raspberry Pi wurde 2013 abgeschlossen. Das Projekt erreichte 2012 die Version 1.0. Wayland basiert wie Android auf EGL.
• Mir war ein Projekt von Canonical Ltd. mit ähnlichen Zielen wie Wayland. Mir sollte sowohl mit mobilen Geräten mit ARM-Chipsätzen (ein erklärtes Ziel war die Kompatibilität mit Android-Gerätetreibern) als auch mit x86-Desktops arbeiten. Wie Android waren Mir/UnityNext EGL-basiert. Die Abwärtskompatibilität mit X-Client-Anwendungen wurde über Xmir erreicht. Das Projekt hat sich inzwischen zu einem Wayland-Kompositor entwickelt, anstatt einen alternativen Anzeigeserver zu sein .
• Andere Alternativen versuchen, den Overhead von X zu vermeiden, indem sie direkt mit der Hardware arbeiten; solche Projekte umfassen DirectFB . (Die Direct Rendering Infrastructure (DRI), die eine zuverlässige Schnittstelle auf Kernel-Ebene zum Framebuffer bereitstellen soll , könnte diese Bemühungen überflüssig machen.)

Weitere Möglichkeiten, eine funktionale Form der "Netzwerktransparenz"-Funktion von X über die Netzwerkübertragbarkeit grafischer Dienste zu erreichen, umfassen:

• 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
• Remote Desktop Protocol (RDP), das dem VNC ähnlich ist, aber auf Microsoft Windows entstand, bevor es auf Unix-ähnliche Systeme portiert wurde; cf NX , GotoMyPc usw.
• Citrix XenApp , ein X-ähnlicher Protokoll- und Anwendungsstack für Microsoft Windows
• Tarantella , das einen Java-basierten Remote-GUI-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 Apollo Computer kam Display Manager (1981). Von Apple kamen die Lisa (1983) und der Macintosh (1984). Die Unix- Welt hatte das Andrew Project (1982) und das Blit- Terminal von Rob Pike (1982).

Die Carnegie Mellon University produzierte eine Fernzugriffsanwendung namens Alto Terminal, die überlappende Fenster auf dem Xerox Alto anzeigte und entfernte Hosts (normalerweise DEC VAX-Systeme mit Unix) für die Behandlung von Fensterbelichtungsereignissen und die Aktualisierung von Fensterinhalten bei Bedarf verantwortlich machte.

X leitet seinen Namen als Nachfolger eines Fenstersystems aus der Zeit vor 1983 ab, das W genannt wird (der Buchstabe vor X im englischen Alphabet ). W lief unter dem V-Betriebssystem . W verwendet ein Netzwerkprotokoll, das Terminal- und Grafikfenster unterstützt, wobei der Server Anzeigelisten verwaltet.

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 DEC , MIT und IBM , um allen Studenten einen einfachen Zugang zu Computerressourcen zu ermöglichen) benötigte ein plattformunabhängiges Grafiksystem, um seine heterogenen Systeme mehrerer Anbieter miteinander zu verbinden; das Fenstersystem, das damals im Andrew-Projekt 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 Remote-Ressourcen aufrufen konnte. Mitte 1983 lief eine anfängliche Portierung von W auf Unix mit einem Fünftel seiner 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 war 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, der sich damals auf die Veröffentlichung seiner ersten Ultrix- Workstation vorbereitete , hielt X für das einzige Fenstersystem, das wahrscheinlich rechtzeitig verfügbar sein wird. DEC-Ingenieure portierten X6 auf das QVSS-Display von DEC auf MicroVAX .

Im zweiten Quartal 1985 erwarb X Farbunterstützung für die DEC VAXstation -II/GPX und bildete die Version 9.

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. 1986 hatten externe Organisationen begonnen, nach X zu fragen. X10R2 war veröffentlicht im Januar 1986, dann X10R3 im Februar 1986. Obwohl das MIT X6 gegen eine Gebühr an einige externe Gruppen lizenziert hatte, beschloss es zu diesem Zeitpunkt, X10R3 und zukünftige Versionen unter der so genannten MIT-Lizenz zu lizenzieren , um X weiter bekannt zu machen und , im Gegenzug, in der Hoffnung, dass viele weitere Anwendungen zur Verfügung stehen würden. X10R3 war die erste Version, die eine breite Bereitstellung erreichte, wobei sowohl DEC als auch Hewlett-Packard darauf basierende Produkte herausbrachten . Andere Gruppen portierten X10 auf Apollo und auf Sun- Workstations und sogar auf den IBM PC/AT . Demonstrationen der ersten kommerziellen Anwendung für X (ein mechanisches computergestütztes Engineering-System von Cognition Inc., das auf VAXen lief und auf PCs mit einem von Jim Fulton und Jan Hardenbergh portierten X-Server remote angezeigt wird) fanden auf der Autofact-Messe statt. Zeit. Die letzte Version von X10, X10R4, erschien im Dezember 1986. Es wurden Versuche unternommen, X-Server als Echtzeit-Collaboration-Geräte zu aktivieren, ähnlich wie Virtual Network Computing (VNC) später die gemeinsame Nutzung eines Desktops ermöglichte. Eine dieser frühen Bemühungen war das SharedX- Tool von Philip J. Gust .

Obwohl X10 interessante und leistungsstarke Funktionen bot, war offensichtlich, dass das X-Protokoll ein hardwareneutraleres Redesign verwenden könnte, bevor es zu weit verbreitet wurde, aber das MIT allein hätte nicht die Ressourcen für ein solches komplettes Redesign zur Verfügung. Zufällig fand sich das Western Software Laboratory von DEC zwischen den Projekten mit einem erfahrenen Team wieder. Smokey Wallace von DEC WSL und Jim Gettys schlugen vor, dass DEC WSL X11 bauen und unter denselben Bedingungen wie X9 und X10 frei verfügbar machen sollte. Dieser Prozess begann im Mai 1986, das Protokoll wurde im August fertiggestellt. Alpha-Tests der Software begannen im Februar 1987, Beta-Tests 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 ausführlich auf offenen Mailinglisten im entstehenden Internet diskutiert, die mit USENET-Newsgroups verbunden waren. Gettys zog nach Kalifornien, um die X11-Entwicklungsarbeit an der WSL vom DEC Systems Research Center zu leiten, wo Phil Karlton und Susan Angebrandt das Design und die Implementierung des X11-Beispielservers leiteten. X stellt daher eines der ersten sehr groß angelegten verteilten freien und Open-Source-Softwareprojekte dar .

Das MIT-X-Konsortium und das X-Konsortium, Inc.

In den späten 1980er Jahren war X, so schrieb Simson Garfinkel 1989, "Athenas bisher wichtigster Einzelerfolg". DEC glaubte angeblich, dass sich allein durch seine Entwicklung die Spende des Unternehmens an das MIT gelohnt habe. Gettys trat dem Designteam für die VAXstation 2000 bei, um sicherzustellen, dass X – DEC nannte es DECwindows – darauf laufen würde, und das Unternehmen beauftragte 1.200 Mitarbeiter, X sowohl auf Ultrix als auch auf VMS zu portieren. 1987, als sich der Erfolg von X11 abzeichnete, wollte MIT die Führung von X aufgeben, aber bei einem Treffen mit neun Anbietern im Juni 1987 teilten die Anbieter MIT mit, dass sie an die Notwendigkeit einer neutralen Partei glaubten, um eine Zersplitterung von X zu verhindern der Markt. Im Januar 1988 bildete sich das MIT X Consortium als Non-Profit-Verkäufergruppe mit Scheifler als Direktor, um die zukünftige Entwicklung von X in einer neutralen Atmosphäre einschließlich kommerzieller und pädagogischer Interessen zu leiten.

Jim Fulton kam im Januar 1988 und Keith Packard im März 1988 als Senior- Entwickler , wobei Jim sich auf Xlib , Schriftarten , Fenstermanager und Dienstprogramme konzentrierte; und Keith, der den Server neu implementiert. Donna Converse, Chris D. Peterson und Stephen Gildea kamen später in diesem Jahr hinzu und konzentrierten sich auf Toolkits und Widget-Sets, wobei sie eng mit Ralph Swick vom MIT Project Athena zusammenarbeiteten. Das MIT X Consortium produzierte mehrere bedeutenden Änderungen an X11, die ersten (Release 2 - X11R2) im Februar 1988 Jay Hersh das Personals im Januar 1991 an der Arbeit auf der verbundene PEX und X113D Funktionalität. Ihm folgten kurz darauf Ralph Mor (der auch an PEX mitgearbeitet hat) und Dave Sternlicht. Im Jahr 1993, als das MIT X-Konsortium sich darauf vorbereitete, das MIT zu verlassen, kamen R. Gary Cutbill, Kaleb Keithley und David Wiggins zu den Mitarbeitern.

Gemeinsame Desktop-Umgebung

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

Die offene Gruppe

Im Januar 1997 übergab das X-Konsortium die Führung von X an The Open Group , eine Anfang 1996 durch die Fusion der Open Software Foundation und X/Open gebildete Anbietergruppe .

Die Open Group veröffentlichte X11R6.4 Anfang 1998. Kontroverserweise wich X11R6.4 von den traditionellen liberalen Lizenzbedingungen ab, da die Open Group versuchte, die Finanzierung für die Entwicklung von X sicherzustellen, und XFree86 ausdrücklich als nicht wesentlich zu X beitrug neue Bedingungen hätten X zu keiner freien Software mehr gemacht : Null-Kosten für die nicht-kommerzielle Nutzung, aber ansonsten kostenpflichtig. Nachdem XFree86 kurz vor der Abspaltung stand , lizenzierte die Open Group X11R6.4 im September 1998 unter der traditionellen Lizenz neu. Die letzte Version der Open Group kam als X11R6.4 Patch 3.

X.Org und XFree86

XFree86 entstand 1992 aus dem X386- Server für IBM-PC-Kompatibel, 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 hat sich im Laufe der Zeit von nur einer Portierung von X zur führenden und beliebtesten Implementierung und zum De-facto- Standard der Entwicklung von X entwickelt.

Im Mai 1999 gründete The Open Group X.Org. X.Org betreute die Veröffentlichung von Versionen ab X11R6.5.1. Die Entwicklung von X war zu diesem Zeitpunkt im Sterben begriffen; Die meisten technischen Neuerungen seit der Auflösung des X-Konsortiums hatten im XFree86-Projekt stattgefunden. 1999 trat das XFree86-Team X.Org als ehrenamtliches (nicht zahlendes) Mitglied bei, ermutigt von verschiedenen Hardwarefirmen, die daran interessiert waren, XFree86 mit Linux zu verwenden und in seinem Status als beliebteste Version von X.

Im Jahr 2003, während die Popularität von Linux (und damit die installierte Basis von X) anstieg, blieb X.Org inaktiv, und aktive Entwicklung fand größtenteils innerhalb von XFree86 statt. Innerhalb von XFree86 entwickelte sich jedoch beträchtlicher Dissens. Das XFree86-Projekt litt unter der Wahrnehmung eines viel zu kathedralenartigen Entwicklungsmodells; Entwickler konnten keinen CVS- Commit-Zugriff erhalten und die Hersteller mussten umfangreiche Patch- Sets pflegen . Im März 2003 wies die XFree86-Organisation Keith Packard, der nach dem Ende des ursprünglichen MIT-X-Konsortiums zu XFree86 gekommen war, mit einem erheblichen Missempfinden aus.

X.Org und XFree86 begannen, eine Reorganisation zu diskutieren, die geeignet ist, die Entwicklung von X richtig zu fördern. Jim Gettys hatte sich mindestens seit dem Jahr 2000 stark für ein offenes Entwicklungsmodell eingesetzt. Gettys, Packard und einige andere begannen, ausführlich die Anforderungen an eine effektive Governance zu diskutieren von X mit offener Entwicklung.

Schließlich, als Echo des Lizenzstreits von X11R6.4, veröffentlichte XFree86 im Februar 2004 die Version 4.4 unter einer restriktiveren Lizenz, die viele Projekte, die auf X basierten, inakzeptabel fanden. Die zur Lizenz hinzugefügte Klausel basierte auf der Werbeklausel der ursprünglichen BSD-Lizenz , die von der Free Software Foundation und Debian als mit der GNU General Public License unvereinbar angesehen wurde . Andere Gruppen sahen es als gegen den Geist des ursprünglichen X. Theo de Raadt von OpenBSD , zum Beispiel, drohte gabeln XFree86 unter Berufung Lizenz betrifft. Das Lizenzproblem, kombiniert mit den Schwierigkeiten, Änderungen vorzunehmen, ließen viele das Gefühl haben, die Zeit sei reif für eine Gabelung.

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 x.org Domainnamen . Dies markierte einen radikalen Wandel in der Governance von X. Während die Stewards von X seit 1988 (einschließlich der früheren X.Org) Anbieterorganisationen waren, wurde die Foundation von Softwareentwicklern geleitet und nutzte Community-Entwicklung basierend auf dem Basar- Modell, das sich auf über das Engagement von außen. Die Mitgliedschaft wurde für Einzelpersonen geöffnet, wobei die Firmenmitgliedschaft in Form von Sponsoring erfolgte. Mehrere große Unternehmen wie Hewlett-Packard unterstützen derzeit die X.Org Foundation.

Die Foundation übernimmt eine Aufsichtsrolle über die X-Entwicklung: Technische Entscheidungen werden nach ihrem Verdienst getroffen, indem ein grober Konsens zwischen den Community-Mitgliedern erzielt wird. Technische Entscheidungen werden nicht vom Verwaltungsrat getroffen; in diesem Sinne ist es stark an die technisch nicht-interventionistische 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 mit den X11R6.6-Änderungen zusammengeführt. 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 ins Boot geholt.

Während X11 in den 1990er Jahren Erweiterungen wie OpenGL-Unterstützung erhalten hatte, blieb seine Architektur im Laufe des Jahrzehnts grundlegend unverändert. Anfang der 2000er Jahre wurde es jedoch überarbeitet, um eine Reihe von Problemen zu lösen, die im Laufe der Jahre aufgetaucht waren, darunter eine "fehlerhafte" Schriftarchitektur , ein 2-D-Grafiksystem, "das immer erweitert werden sollte und" /or ersetzt" und Latenzprobleme . 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 anspruchsvolle visuelle Effekte, Bildschirmlupen und Miniaturansichten sowie Möglichkeiten zur Integration in immersive 3D-Anzeigesysteme wie Suns Project Looking Glass und das Croquet Projekt . Externe Anwendungen, die als Compositing Window Manager bezeichnet werden, stellen Richtlinien für das visuelle Erscheinungsbild bereit.

Am 21. Dezember 2005, X.Org freigegeben X11R6.9, der monolithische Quelle Baum für ältere Nutzer und X11R7.0, die gleichen Quellcode getrennt in unabhängige Module, die jeweils wartbar in separaten Projekten. Die Foundation veröffentlichte X11R7.1 am 22. Mai 2006, etwa vier Monate nach 7.0, mit erheblichen Funktionsverbesserungen.

Die Entwicklung von XFree86 wurde noch einige Jahre fortgesetzt, 4.8.0 wurde am 15. Dezember 2008 veröffentlicht.

Nomenklatur

Die Eigennamen für das System sind auf der Handbuchseite als X aufgeführt; X Window-System; X-Version 11; X Window-System, Version 11; oder X11.

Der Begriff "X-Windows" (in Anlehnung an das später veröffentlichte "Microsoft Windows") wird nicht offiziell gebilligt – mit X-Consortium-Release-Manager Matt Landau sagte 1993: "So etwas wie 'X Windows' oder 'X' gibt es nicht Window', trotz des wiederholten Missbrauchs der Formen durch die Lumpen" – obwohl es seit Beginn der Geschichte von X informell gebräuchlich ist und bewusst provokant eingesetzt wird, zum Beispiel im Unix-Haters Handbook .

Schlüsselbegriffe

Das X Window System verwendet eine Reihe von Begriffen im Vergleich zur üblichen Verwendung nuanciert, insbesondere "Anzeige" und "Bildschirm", von denen hier der Einfachheit halber eine Untermenge angegeben wird:

Gerät

Ein Grafikgerät wie eine Computergrafikkarte oder der integrierte Grafikchipsatz eines Computer-Motherboards.

Monitor

Ein physisches Gerät wie ein CRT oder ein Flachbild-Computerdisplay.

Bildschirm

Ein Bereich, in den Grafiken gerendert werden können, entweder durch Software allein in den Systemspeicher wie bei VNC , oder innerhalb einer Grafikvorrichtung, von denen einige gleichzeitig auf mehr als einem Bildschirm rendern können, entweder gleichzeitig oder austauschbar. Austauschbare Bildschirme sind oft fiktiv links und rechts angeordnet und springen von einem zum nächsten, wenn der Mauszeiger den Rand des Monitors erreicht.

virtueller Bildschirm

Mit diesem Begriff sind zwei unterschiedliche Bedeutungen verbunden:

• Eine Technik, die es ermöglicht, einen Monitor um einen Bildschirm herum zu schwenken, der mit einer größeren Auflösung läuft, als der Monitor derzeit anzeigt.
• Ein Effekt, der von einem Fenstermanager simuliert wird, indem Fensterpositionsinformationen in einem größeren Koordinatensystem als der Bildschirm beibehalten werden und das Schwenken durch einfaches Bewegen der Fenster als Reaktion auf den Benutzer ermöglicht wird.

Anzeige

Eine Ansammlung von Bildschirmen, die häufig mehrere Monitore umfassen, die im Allgemeinen so konfiguriert sind, dass die Maus den Zeiger an jede beliebige Position innerhalb dieser Bildschirme bewegen kann. Linux- basierte Workstations sind normalerweise in der Lage, mehrere Displays zu haben, zwischen denen der Benutzer mit einer speziellen Tastaturkombination wie Strg-Alt- Funktionstaste umschalten kann, wobei gleichzeitig alle Monitore von der Anzeige der Bildschirme eines Bildschirms auf die Bildschirme eines anderen umgeschaltet werden .

Der Begriff „Display“ sollte nicht mit dem Fachjargon „ Zaphod-Display “ verwechselt werden . Letzteres ist eine seltene Konfiguration, die es mehreren Benutzern eines einzelnen Computers ermöglicht, jeweils über einen unabhängigen Satz von Anzeige, Maus und Tastatur zu verfügen, als ob sie separate Computer verwenden würden, jedoch zu geringeren Kosten pro Arbeitsplatz.

Veröffentlichungsverlauf

Im Hinblick auf zukünftige Versionen heißt es auf der X.org-Website:

X.Org entwickelt und veröffentlicht weiterhin die Softwarekomponenten des X Window Systems.

Diese werden einzeln veröffentlicht, wenn jede Komponente fertig ist, ohne auf einen allgemeinen Veröffentlichungsplan für das X Window System "katamari" warten zu müssen - siehe das jeweilige X.Org-Release-Verzeichnis für Downloads und die xorg-announce-Archive oder Git-Repositorys für Details zu den enthaltenen Änderungen.

Es wurde kein Veröffentlichungsplan für eine Rollup-Katamari-Version von X11R7.8 vorgeschlagen.

Siehe auch

• Bitstream Speedo-Schriften
• Kairo (Grafik)
• DESQview/X
• DirektFB
• Allgemeine Grafikschnittstelle
• Geschichte der grafischen Benutzeroberfläche
• Liste der Unix-Befehle
• Mikrofenster - Nano-X
• rio – das Fenstersystem für Plan 9
• SVGALib
• VirtualGL
• X/GEM
• X11 Farbnamen
• Xgl
• Xmark

Anmerkungen

Verweise

Externe Links

• Offizielle Website