| X Window System | |
|---|---|
twm、デフォルトのX11ウィンドウマネージャー | |
| 原作者 | プロジェクト・アテナ |
| 開発者 | X.Org財団 |
| リリース | 1984年6月19日 (1984-06-19)[ 1 ] |
| 安定放出 | |
| オペレーティング·システム | Unix、Unixライク、MVS、OpenVMS、DOS |
| プラットフォーム | クロスプラットフォーム |
| 前任者 | Wウィンドウシステム |
| タイプ | ウィンドウシステム |
| ライセンス | MITライセンス |
| Webサイト | x.org |
| リポジトリ |
|
X Window System ( X11、または単にX ) は、 Unix 系オペレーティングシステムで一般的なビットマップ表示用のウィンドウ システムです。X は、1984 年にマサチューセッツ工科大学(MIT)のProject Athenaの一部として誕生しました。 [ 4 ] X プロトコルは、1987 年 9 月以来バージョン 11 (そのため「X11」) となっています。X.Org Foundation がX プロジェクトを主導しており、現在のリファレンス実装であるX.Org Server は、 MIT ライセンスおよび同様の寛容なライセンスの下で、無料のオープンソース ソフトウェアとして利用可能です。
Xは、リモートグラフィカルユーザーインターフェースと入力デバイス機能のための、アーキテクチャに依存しないシステムです。ネットワーク端末を使用する各ユーザーは、あらゆる種類のユーザー入力デバイスを使用してディスプレイと対話することができます。
標準ディストリビューションは、ほとんどのUnix系オペレーティングシステムおよびOpenVMS上でグラフィカルユーザーインターフェースを構築するための標準ツールキットとプロトコルスタックを提供し、他の多くの現代的な汎用オペレーティングシステムにも移植されています。
Xは、このようなGUI環境を構築するための基本的なフレームワーク、すなわちプリミティブを提供します。具体的には、ディスプレイ上にウィンドウを描画・移動したり、マウス、キーボード、タッチスクリーンと対話したりするための機能です。Xはユーザーインターフェースを規定するものではなく、個々のクライアントプログラムがこれを処理します。プログラムは、ユーザーインターフェースを持たずにXのグラフィカル機能を利用することもできます。そのため、Xベースの環境の視覚的なスタイルは大きく異なり、プログラムによってインターフェースが根本的に異なる場合もあります。
以前のほとんどのディスプレイ プロトコルとは異なり、X は、内蔵または接続されたディスプレイ デバイスではなく、ネットワーク接続を介して使用するために特別に設計されました。X はネットワーク透過性を備えているため、ネットワーク (インターネットなど) 上のどこかのコンピュータで実行されている X プログラムは、ネットワーク上の別のコンピュータで実行されている X サーバーにユーザー インターフェイスを表示できます。X サーバーは通常、Xクライアントにグラフィック リソースとキーボード/マウス イベントを提供する役割を担います。つまり、X サーバーは通常、人間のユーザーの目の前のコンピュータで実行され、X クライアント アプリケーションはネットワーク上のどこにでも実行され、ユーザーのコンピュータと通信してグラフィック コンテンツのレンダリングを要求したり、キーボードやマウスなどの入力デバイスからのイベントを受信したりします。
ユーザーの目の前にあるソフトウェアに「サーバー」という用語が使われるという事実は、自分のプログラムがリモートコンピュータ上のサービスのクライアントであることに慣れているユーザーにとっては、しばしば驚きとなる。ここでは、リモートデータベースがローカルアプリケーションのリソースとなるのではなく、ユーザーのグラフィック表示デバイスと入力デバイスが、ローカルXサーバーによって、ローカルおよびリモートでホストされているXクライアントプログラムの両方に提供されるリソースとなる。これらのクライアントプログラムは、ユーザーと通信するために、ユーザーのグラフィックと入力デバイスを共有する必要がある。
X のネットワーク プロトコルは、X コマンド プリミティブに基づいています。このアプローチにより、別のコンピュータで実行されている可能性のある X クライアント アプリケーションによる 2D 操作と (GLX などの拡張機能による) 3D 操作の両方を、X サーバーのディスプレイ上で完全に高速化できます。たとえば、従来のOpenGL (バージョン 3.0 より前) では、多数のオブジェクトを含むディスプレイ リストをリモートの X クライアント プログラムによって X サーバー内に完全に構築および保存し、ネットワーク経由で単一の glCallList(which) を送信することでそれぞれをレンダリングすることができました。
Xは音声のネイティブサポートを提供していません。このニーズを満たすためのプロジェクトがいくつか存在し、中には透過的なネットワークサポートを提供するものもあります。

Xはクライアント・サーバーモデルを採用しており、Xサーバーは様々なクライアントプログラムと通信します。[ 5 ]サーバーはグラフィカル出力(ウィンドウ)の要求を受け付け、ユーザー入力(キーボード、マウス、タッチスクリーンからの入力)を返信します。サーバーは以下のように機能します。
クライアントとサーバーという用語(ユーザーの端末がサーバー、アプリケーションがクライアント)は、用語が逆になっているように見えるため、X を初めて使うユーザーを混乱させることがよくあります。しかし、X はエンドユーザーの視点ではなく、アプリケーションの視点に立っています。X はアプリケーションに表示サービスと入出力サービスを提供するのでサーバーであり、アプリケーションはこれらのサービスを利用するのでクライアントなのです。
サーバーとクライアント間の通信プロトコルはネットワーク透過的に動作します。クライアントとサーバーは同じマシン上で動作することも、異なるマシン上で動作することもでき、その場合、アーキテクチャやオペレーティングシステムが異なっていても構いません。クライアントとサーバーは、暗号化されたネットワークセッションを介して接続をトンネル化することで、インターネット上で安全に通信することも可能です。
Xクライアント自体が、他のクライアントに表示サービスを提供することでXサーバーをエミュレートすることができます。これは「Xネスト」として知られています。XnestやXephyrなどのオープンソースクライアントは、このようなXネストをサポートしています。[ 6 ]
リモートマシン上でXクライアントアプリケーションを実行するには、ユーザーは以下の手順を実行できます。
ssh -Xリモートマシンに接続しますリモートのXクライアントアプリケーションは、ユーザーのローカルXサーバーに接続し、ユーザーに表示と入力を提供する。
あるいは、ローカルマシン上で小さなプログラムを実行し、リモートマシンに接続してクライアントアプリケーションを起動することも可能です。
リモートクライアントの具体的な例としては、以下のようなものがあります。


X は主にプロトコルとグラフィックスのプリミティブを定義しており、ボタン、メニュー、ウィンドウのタイトルバーのスタイルなど、アプリケーションのユーザーインターフェイス設計に関する仕様は意図的に含まれていません。[ 7 ]その代わりに、ウィンドウマネージャ、GUI ウィジェットツールキット、デスクトップ環境、アプリケーション固有のグラフィカルユーザーインターフェイスなどのアプリケーションソフトウェアが、そのような詳細を定義して提供します。その結果、典型的なX インターフェイスは存在せず、さまざまなデスクトップ環境がユーザーの間で普及しています。
ウィンドウマネージャは、アプリケーションウィンドウの配置と外観を制御します。これにより、Microsoft WindowsやApple Macintoshを彷彿とさせるデスクトップインターフェイス(GNOME 2、KDE Plasma、Xfceなど)が実現する場合もあれば、全く異なる制御方式(wmiiやRatpoisonのようなタイル型ウィンドウマネージャなど)を採用する場合もあります。SugarやChromeOSなどの一部のインターフェイスは、デスクトップメタファーを完全に排除し、特定のアプリケーション向けにインターフェイスを簡素化しています。ウィンドウマネージャの洗練度と複雑さは、必要最低限の機能を持つもの(Xに付属する基本的なウィンドウマネージャであるtwmや、非常に軽量なウィンドウマネージャであるevilwmなど)から、 Enlightenmentのようなより包括的なデスクトップ環境、さらにはPOSなどの特定市場向けのアプリケーション固有のウィンドウマネージャまで多岐にわたります。
多くのユーザーは、ウィンドウマネージャの他に、一貫したユーザーインターフェースを使用する様々なアプリケーションを含むデスクトップ環境とともにXを使用しています。人気のデスクトップ環境には、GNOME、KDE Plasma、Xfceなどがあります。UNIX 98の標準環境は、共通デスクトップ環境(CDE)です。freedesktop.orgイニシアチブは、デスクトップ間の相互運用性と、競争力のあるXデスクトップに必要なコンポーネントに取り組んでいます。
X.Orgの実装は、Xの標準的な実装です。寛容なライセンスのおかげで、フリーかつオープンソース(FOSS)なものからプロプライエタリなものまで、数多くのバリエーションが登場しました。商用Unixベンダーは、リファレンス実装を採用し、自社のハードウェアに合わせてカスタマイズしたり、独自の拡張機能を追加したりする傾向があります。
2004年まで、XFree86はフリーのUnix系システムで最も一般的なXの派生版を提供していました。XFree86は386互換PCへのXの移植版として始まり、1990年代末までにはXにおける技術革新の最大の源泉となり、 X開発の事実上の標準となりました。しかし、2004年以降は、XFree86から派生したX.Org Serverが主流となっています。
XはUnixと関連付けられることが多いが、Xサーバーは他のグラフィカル環境にもネイティブに存在している。VMS Software Inc.のOpenVMSオペレーティングシステムには、標準デスクトップ環境としてDECwindowsとして知られる共通デスクトップ環境(CDE)を備えたXのバージョンが含まれている。Apple は当初、X11.appの形でmacOSにXを移植したが、現在はXQuartz実装が推奨されているため、非推奨となっている。1990年代のAppleの旧オペレーティングシステムであるSystem 7、Mac OS 8、および9では、サードパーティ製のサーバーとしてAppleのMacXやWhite Pine SoftwareのeXodusなどが存在した。
Microsoft WindowsにはXのサポートは標準搭載されていませんが、 Cygwin/Xのようなフリーでオープンソースのソフトウェアや、 Exceed、MKS X/Server、Reflection X、X-Win32、 Xmingなどのプロプライエタリ製品など、多くのサードパーティ製実装が存在します。
JavaによるXサーバーの実装も存在します。WeirdXはSwing 1.1をサポートするあらゆるプラットフォームで動作し、ほとんどのブラウザでアプレットとして機能します。Android Xサーバーは、Androidデバイス上で動作するオープンソースのJava実装です。
ネイティブのウィンドウシステムを備えたオペレーティングシステムがXをホストする場合、Xシステムは別のホストウィンドウで独自の通常のデスクトップを使用するか、ルートレスで実行することができます。ルートレスとは、Xデスクトップが非表示になり、ホストのウィンドウ環境がホスト画面内のホストされたXウィンドウの形状と外観を管理することを意味します。
X端末は、Xサーバーのみを実行するシンクライアントです。このアーキテクチャは、多数のユーザーが同時に同じ大型コンピュータサーバーを使用して、各ユーザーのX端末のクライアントとしてアプリケーションプログラムを実行できる、安価な端末群を構築する際に広く利用されるようになりました。この利用方法は、MITプロジェクトの当初の意図と非常に合致しています。
X端末は、 Xディスプレイマネージャ制御プロトコルを使用してネットワーク(ローカルブロードキャストドメイン)を探索し、クライアントとして許可される利用可能なホストのリストを生成します。クライアントホストのうち1つは、 Xディスプレイマネージャを実行する必要があります。
X端末やほとんどのシンクライアントの制約として、キーボード、マウス、ディスプレイ以外の入出力機能がないことが挙げられます。関連するデータはすべてリモートサーバー上にのみ存在すると想定されており、X端末のユーザーはローカル周辺機器からデータを保存したり読み込んだりする手段を持っていません。
専用の(ハードウェア)X端末は使用されなくなっており、PCや最新のシンクライアントにXサーバーを接続すれば、通常は同等の機能をより低コストで提供できる。
『Unix嫌いのハンドブック』(1994年)では、Xの問題点について1章を丸ごと割いて解説している。 [ 8 ] Gajewska、Manasse、McCormackによる『なぜXは我々の理想的なウィンドウシステムではないのか』(1990年)では、プロトコルの問題点を詳細に説明し、改善のための提言を行っている。
X には設計ガイドラインがないため、インターフェースが大きく異なり、アプリケーション同士がうまく連携しないという結果が生じています。クライアントの相互運用性に関する仕様であるInter-Client Communication Conventions Manual (ICCCM) は、正しく実装するのが難しいことで知られています。MotifやCDEなどのさらなる標準化の取り組みも問題を軽減しませんでした。これはユーザーとプログラマーを苛立たせています。[ 9 ]現在、グラフィックス プログラマーは、特定のデスクトップ環境または特定のウィジェット ツールキットに合わせてコーディングすることで、アプリケーションの外観と操作性、および通信の一貫性に対処しており、ICCCM を直接扱う必要も回避しています。
Xには、NeWSのようにXサーバー上でユーザー定義のストアドプロシージャをネイティブにサポートする機能がありません。つまり、チューリング完全なスクリプト機能が存在しないのです。そのため、様々なデスクトップ環境がそれぞれ独自の(通常は互換性のない)機能を提供している場合があります。
X をベースにしたシステムには、右クリック、ダブルクリック、ミドルクリック、マウスオーバー、フォーカススティールなど、障がいのあるユーザーがコンピュータを利用する際に支障となるアクセシビリティの問題が存在する可能性があります。X11 クライアントの中には、アクセシビリティの問題にうまく対処しているものもあれば、そうでないものもあるため、アクセシビリティの問題を抱えるユーザーが X11 を利用できなくなることはありません。しかし、X11 にはアクセシビリティ標準やアクセシビリティガイドラインは存在しません。X11 標準化プロセスにはアクセシビリティに関するワーキンググループはありませんが、X をベースにこれらの機能を提供するソフトウェアプロジェクトによって、アクセシビリティのニーズへの対応が進められています。
Orcaプロジェクトは、API(AT-SPI [ 10 ])の実装を含め、X Window Systemにアクセシビリティサポートを追加します。これはGNOMEのATKと連携し、GNOME/GTK APIを使用してXプログラムにアクセシビリティ機能を実装できるようにします。[ 11 ] KDEは、テキスト読み上げコンバーターやスクリーン拡大鏡など、別のアクセシビリティソフトウェアセットを提供します。[ 12 ]他の主要なデスクトップ(LXDE、Xfce、Enlightenment)は、ATKとの互換性を目指しています。

X クライアントは、コードで明示的に許可されていない限り、一般的にあるサーバーから切り離して別のサーバーに再接続することはできません ( Emacs は、この機能を備えた数少ない一般的なプログラムの 1 つです)。そのため、セッション全体をある X サーバーから別の X サーバーに移動することは一般的に不可能です。ただし、Virtual Network Computing (VNC)、NX、Xpraなどのアプローチにより、仮想セッションに異なる X サーバーからアクセスできます (端末に関するGNU Screenと同様の方法)。また、他のアプリケーションやツールキットも関連機能を提供しています。 [ 13 ]現在の X サーバー画面を利用可能にするための回避策として、 x11vnc ( VNC :0 ビューア)、Xpra のシャドウ モード、NX の nxagent シャドウ モードも存在します。この機能により、実行中のアプリケーションのユーザー インターフェイス (マウス、キーボード、モニター) を、アプリケーションを停止して再起動することなく、ある場所から別の場所に切り替えることができます。
XサーバーとリモートXクライアント間のネットワークトラフィックは、デフォルトでは暗号化されていません。パケットスニファを使用する攻撃者はこれを傍受できるため、ユーザーの画面に表示される内容や送信される内容をすべて閲覧することが可能です。Xトラフィックを暗号化する最も一般的な方法は、通信にセキュアシェル(SSH)トンネルを確立することです。
すべてのシンクライアントと同様に、ネットワーク経由で X を使用する場合、帯域幅の制限により、3D アニメーションや写真編集など、低遅延で画面の大部分を高速に更新する必要があるビットマップ集約型アプリケーションの使用が妨げられる可能性があります。比較的小さな非圧縮640×480×24 ビット 30 fps ビデオ ストリーム (約 211 Mbit/s) でさえ、単一クライアントの 100 Mbit/s ネットワークの帯域幅を簡単に超えてしまいます 。これに対し、最新バージョンの X には、一般的にMesaなどの拡張機能があり、ローカル プログラムのグラフィックスのローカル表示を最適化してネットワーク モデルをバイパスし、ビデオ カードを直接制御できるため、フルスクリーン ビデオ、レンダリングされた 3D アプリケーション、その他の同様のアプリケーションで使用できます。
X の設計では、クライアントとサーバーが別々に動作する必要があります。デバイスの独立性とクライアントとサーバーの分離により、オーバーヘッドが発生します。オーバーヘッドの大部分は、プロトコル自体ではなく、クライアントとサーバー間のネットワーク往復遅延時間(レイテンシ) に起因します。パフォーマンスの問題に対する最良の解決策は、効率的なアプリケーション設計に依存します。[ 14 ] X に対する一般的な批判は、ローカルでのみ使用すると、ネットワーク機能が過度に複雑になり、パフォーマンスが低下するというものです。
最新の X 実装では、同じホスト上での効率的な接続のためにUnix ドメイン ソケットを使用します。さらに、共有メモリ( MIT-SHM拡張機能経由) を使用することで、クライアントとサーバー間の通信を高速化できます。[ 15 ]ただし、プログラマは共有メモリ拡張機能を明示的に有効化して使用する必要があります。また、古い実装との互換性を維持するため、およびローカル以外の X サーバーと通信するために、フォールバック パスを提供する必要もあります。
Xの設計にはサンドボックス機能がないため、どのアプリケーションでもキーボード、マウス、ディスプレイ、クリップボードの内容にアクセスして操作できてしまう。
設定が不十分なシステムでは、X11 を root 権限で実行し、権限昇格を許してしまう可能性があります。過去には、権限のないアプリケーションが権限を取得するためにこれを悪用していました。[ 16 ] [ 17 ]
Xの代替となるシステムや後継システムを開発しようと試みた人々もいる。歴史的な代替システムとしては、Sun社のNeWSやNeXT社のDisplay PostScriptなどがあり、どちらもPostScriptベースのシステムで、Xにはなかったユーザー定義可能な表示側プロシージャをサポートしていた。現在の代替システムとしては、以下のようなものがある。
Xの「ネットワーク透過性」機能の機能的な形態を、グラフィカルサービスのネットワーク伝送性を通じて実現するその他の方法としては、以下のものが挙げられます。
Xに先立って、いくつかのビットマップ表示システムが登場した。ゼロックスからはAlto ( 1973年)とStar(1981年)が、アポロコンピュータからはDisplay Manager(1981年)が、アップルからはLisa(1983年)とMacintosh (1984年)がそれぞれ登場した。Unixの世界では、Andrew Project(1982年)とRob PikeのBlitターミナル(1982年)があった。
カーネギーメロン大学は、Xerox Alto上でウィンドウを重ねて表示するAlto Terminalと呼ばれるリモートアクセスアプリケーションを開発しました。このアプリケーションでは、リモートホスト(通常はUnixを実行するDEC VAXシステム)がウィンドウの表示イベントを処理し、必要に応じてウィンドウの内容を更新する役割を担っていました。
Xという名前は、1983年以前に存在したW (英語のアルファベットでXの前の文字)と呼ばれるウィンドウシステムの後継に由来する。WはVオペレーティングシステム上で動作し、端末ウィンドウとグラフィックウィンドウをサポートするネットワークプロトコルを使用し、サーバーがディスプレイリストを管理していた。
差出人: rws@mit-bold (Robert W. Scheifler) 宛先: window@athena件名:ウィンドウシステムX 日付: 1984年6月19日09:07-EDT (火曜日) ここ数週間、窓について書いていた VS100用のシステム。かなりの量のコードを盗用しました。 W から、非同期で囲まれました 同期インターフェースよりも優れており、それをXと呼んだ。 パフォーマンスはWの約2倍のようです。 現時点ではコードはかなりしっかりしているように見えるが、 まだいくつか改善すべき点がある。 LCSではWの使用をやめ、現在は X上で積極的にアプリケーションを開発している人は他にいますか? Wは真剣に切り替えを検討すべきだ。これは 究極の窓システムですが、良いものだと思います 実験の出発点。まさに今この瞬間 XにはCLU(およびArgus)インターフェースがあります。 インターフェースは開発中です。既存の3つ アプリケーションはテキストエディタ(TED)、Argus I/O インターフェースと、原始的なウィンドウマネージャがあります。 まだドキュメントはありません。 ボランティア?いつかやるかもしれないね。 デモをご覧になりたい方はどなたでもお気軽にお立ち寄りください。 NE43-531ですが、3-1945に電話することもできます。 まず。コードが欲しい人は誰でも、 テープ。ハッキングの欠陥に興味のある方は、 お気軽にお問い合わせください。

X の原案は、1984 年に MIT で、Jim Gettys ( Project Athenaの) とBob Scheifler ( MIT コンピュータ科学研究所の) の共同作業によって生まれました。Scheifler は Argus システムのデバッグに使える表示環境を必要としていました。Project Athena ( DEC、MIT、IBMの共同プロジェクトで、すべての学生がコンピューティング リソースに簡単にアクセスできるようにすることを目的としたもの) は、複数のベンダーの異種システムを連携させるためのプラットフォームに依存しないグラフィックス システムを必要としていました。当時、カーネギー メロン大学のAndrew Projectで開発されていたウィンドウ システムではライセンスが提供されておらず、代替手段も存在しませんでした。
このプロジェクトは、ローカルアプリケーションの実行とリモートリソースの呼び出しの両方が可能なプロトコルを作成することでこの問題を解決しました。1983年半ば、WのUnixへの最初の移植版はV上での5分の1の速度で動作しました。1984年5月、シェイフラーはWの同期プロトコルを非同期プロトコルに、表示リストを即時モードグラフィックスに置き換え、Xバージョン1を作成しました。Xは、真のハードウェア非依存性とベンダー非依存性を提供する最初のウィンドウシステム環境となりました。
シェイフラー、ゲティス、ロン・ニューマンは開発に取り掛かり、Xは急速に進歩した。彼らは1985年1月にバージョン6をリリースした。当時、初のUltrixワークステーションの発売を準備していたDECは、Xが間に合う唯一のウィンドウシステムであると判断した。DECのエンジニアは、X6をMicroVAX上のDECのQVSSディスプレイに移植した。
1985年の第2四半期に、XはDEC VAXstation -II/GPXで動作するためのカラーサポートを獲得し、バージョン9となった。
ブラウン大学のグループがバージョン 9 をIBM RT PCに移植したが、RT 上でアラインメントされていないデータを読み取る問題により、互換性のないプロトコル変更を余儀なくされ、1985 年後半にバージョン 10 がリリースされた。X10R1 は 1985 年にリリースされた。[ 23 ] 1986 年までに、外部の組織が X を求め始めた。X10R2 は 1986 年 1 月にリリースされ、続いて X10R3 は 1986 年 2 月にリリースされた。MIT は X6 を一部の外部グループに有料でライセンスしていたが、この時 X10R3 と将来のバージョンを、後にMIT ライセンスとして知られるようになるライセンスの下でライセンスすることを決定し、X をさらに普及させ、その見返りに、より多くのアプリケーションが利用可能になることを期待した。X10R3 は、DEC とヒューレット・パッカードの両方がそれに基づいて製品をリリースし、広く展開された最初のバージョンとなった。他のグループは X10 をApolloやSunワークステーション、さらには IBM PC/ATに移植した。 X の最初の商用アプリケーション (Cognition Inc. の機械設計支援エンジニアリング システムで、VAX 上で動作し、Jim Fulton と Jan Hardenbergh が移植した X サーバーを実行する PC にリモート表示される) のデモンストレーションは、当時開催されていた Autofact 展示会で行われた。X10 の最終バージョンである X10R4 は、1986 年 12 月にリリースされた。仮想ネットワーク コンピューティング(VNC) が後にデスクトップの共有を可能にするのと同様に、X サーバーをリアルタイムのコラボレーション デバイスとして使用できるようにするための試みが行われた。そのような初期の試みの 1 つは、Philip J. Gust のSharedXツールであった。
X10は興味深く強力な機能を提供していたものの、Xプロトコルが広く普及する前に、よりハードウェアに依存しない再設計が必要であることは明らかだったが、MITだけではそのような完全な再設計に必要なリソースはなかった。ちょうどその頃、DECのWestern Software Laboratoryは経験豊富なチームを抱え、プロジェクトの合間にいた。DEC WSLのSmokey WallaceとJim Gettysは、DEC WSLがX11を開発し、X9やX10と同じ条件で無償で提供することを提案した。このプロセスは1986年5月に始まり、プロトコルは8月に最終決定された。ソフトウェアのアルファテストは1987年2月に始まり、ベータテストは5月に開始され、X11のリリースは1987年9月15日に行われた。[ 24 ]
シェイフラーが主導したX11プロトコルの設計は、黎明期のインターネット上の公開メーリングリストで広く議論され、それらのメーリングリストはUSENETニュースグループに接続されていた。ゲティスは、フィル・カールトンとスーザン・アンゲブラントがX11サンプルサーバーの設計と実装を主導していたDECのシステム研究センターからカリフォルニアに移り、WSLでのX11開発作業を主導した。したがって、Xは、非常に大規模な分散型フリー・オープンソースソフトウェアプロジェクトの最初期のものの1つと言える。
1980年代後半までに、Xは「アテナのこれまでの最も重要な単一の成果」となったと、シムソン・ガーフィンケルは1989年に記している。DECは、Xの開発だけでもMITへの寄付に見合う価値があると信じていたと伝えられている。ゲティスは、DECがDECwindowsと呼んだXがVAXstation 2000上で動作するように、 VAXstation 2000の設計チームに加わり、同社は1,200人の従業員をUltrixとVMSの両方にXを移植するために割り当てた。[ 25 ] [ 26 ] 1990年までに、IBMとモトローラは独自のX端末を発表した。ディスクレスワークステーションでX端末と競合していたサン・マイクロシステムズのビル・ジョイは、Xは技術的に欠陥があり、ネットワークを圧倒する可能性があると主張した。[ 27 ]
1987年、X11の成功が明らかになるにつれ、MITはXの管理権を手放したいと考えていた。しかし、同年6月に9社のベンダーと会合を開いた際、ベンダー側は、Xが市場で細分化されるのを防ぐためには中立的な組織が必要だとMITに伝えた。そこで1988年1月、商業的利益と教育的利益の両方を包含する中立的な環境の中でXの将来的な発展を方向付けるため、シェイフラーをディレクターとする非営利ベンダーグループとしてMIT Xコンソーシアムが設立された。
ジム・フルトンは1988年1月に、キース・パッカードは1988年3月にシニア開発者として入社し、ジムはXlib、フォント、ウィンドウマネージャ、ユーティリティに重点を置き、キースはサーバーを再実装した。ドナ・コンバース、クリス・D・ピーターソン、スティーブン・ギルデアは同年後半に入社し、ツールキットとウィジェットセットに重点を置き、MITプロジェクト・アテナのラルフ・スウィックと緊密に協力した。MIT XコンソーシアムはX11にいくつかの重要な改訂版を出し、最初の改訂版(リリース2 – X11R2)は1988年2月にリリースされた。ジェイ・ハーシュは1991年1月にスタッフに加わり、PEXとX113Dの機能に取り組んだ。その後すぐにラルフ・モア(彼もPEXに取り組んでいた)とデイブ・スターンリヒトが続いた。 1993年、MIT XコンソーシアムがMITを離れる準備をしていたとき、スタッフにR.ゲイリー・カットビル、カレブ・キースリー、デビッド・ウィギンズが加わった。[ 28 ]

1993年、MIT X Consortiumの後継として、非営利法人であるX Consortium, Inc.が設立されました。1994年5月16日にX11R6をリリースしました。1995年には、MotifツールキットとUnixシステム用の共通デスクトップ環境の開発に着手しました。X Consortiumは1996年末に解散し、最終版であるX11R6.3と、開発における商業的影響力の増大という遺産を残しました。[ 29 ] [ 30 ]
1997年1月、XコンソーシアムはXの管理権をオープン・グループに引き継いだ。オープン・グループは、1996年初頭にオープン・ソフトウェア財団とX/オープンが合併して設立されたベンダーグループである。
Open Group は 1998 年初頭に X11R6.4 をリリースしました。物議を醸したのは、X11R6.4 が従来の自由主義的なライセンス条項から逸脱していたことです。Open Group は X の開発資金を確保しようとし、特にXFree86 がX に大きく貢献していないと指摘しました。 [ 31 ]新しい条項では、X はもはやフリー ソフトウェアではなくなり、非商用利用の場合は無料ですが、それ以外の場合は料金が発生します。XFree86 がフォークする準備が整ったように見えた後、[ 32 ] Open Group は1998 年 9 月に X11R6.4 を従来のライセンスで再ライセンスしました。 [ 33 ] Open Group の最後のリリースは X11R6.4 パッチ 3 でした。
XFree86は、1991年にX11R5に含まれていたIBM PC互換機用のX386サーバーから1992年に誕生しました。このサーバーはThomas RoellとMark W. Snitilyによって作成され、Snitily Graphics Consulting Services(SGCS)によってMIT X Consortiumに寄贈されました。XFree86は、Xの単なる移植版から、時を経て最も普及している実装、そしてX開発の事実上の標準へと進化しました。 [ 34 ]
1999 年 5 月、The Open Group は X.Org を設立しました。X.Org は、X11R6.5.1 以降のバージョンのリリースを監督しました。この頃の X の開発は停滞していました。[ 35 ] X Consortium が解散して以来、ほとんどの技術革新は XFree86 プロジェクトで行われていました。[ 36 ] 1999 年、XFree86 チームは、 Linux で XFree86 を使用することや、X の最も人気のあるバージョンとしての地位に関心を持つさまざまなハードウェア企業 [38] に後押しされ、名誉会員(無報酬) として X.Org に参加しました。[ 37 ]
2003 年までに Linux の人気 (したがって X のインストールベース) が急上昇する一方で、X.Org は活動を停止したままであり[ 39 ]、活発な開発は主に XFree86 内で行われていました。しかし、XFree86 内ではかなりの意見の相違が生じました。XFree86 プロジェクトは、あまりにも大聖堂のような開発モデルであるという認識に悩まされていました。開発者はCVSコミットへのアクセス権を取得できず[ 40 ] [ 41 ] 、ベンダーは広範なパッチセットを維持する必要がありました[ 42 ] 。2003年 3 月、XFree86 組織は、元の MIT X コンソーシアムの終了後に XFree86 に参加した Keith Packard を、かなりの不満とともに追放しました[ 43 ] [ 44 ] [ 45 ] 。
X.OrgとXFree86は、Xの開発を適切に育成するのに適した再編成について議論を始めた。[ 46 ] [ 47 ] [ 48 ]ジム・ゲティスは、少なくとも2000年以来、オープンな開発モデルを強く推進していた。[ 49 ]ゲティス、パッカード、その他数名が、オープンな開発によるXの効果的なガバナンスの要件について詳細に議論を始めた。
最後に、X11R6.4 のライセンス紛争の反響として、XFree86 は 2004 年 2 月に、X に依存する多くのプロジェクトが受け入れがたいと考える、より制限的なライセンスの下でバージョン 4.4 をリリースしました。[ 50 ]ライセンスに追加された条項は、オリジナルのBSD ライセンスの広告条項に基づいており、フリー ソフトウェア財団とDebian は、これをGNU 一般公衆ライセンスと互換性がないとみなしました。[ 51 ]他のグループは、これをオリジナルの X の精神に反するものと見ていました。たとえば、OpenBSDのTheo de Raadt は、ライセンスの懸念を理由に XFree86 をフォークすると脅しました。[ 52 ]ライセンスの問題と変更の導入の難しさが相まって、多くの人がフォークの時期が熟したと感じました。[ 53 ]
2004年初頭、X.Orgとfreedesktop.orgの関係者がX.Org Foundationを設立し、Open Groupはx.orgドメイン名の管理権を同財団に譲渡した。これはXのガバナンスにおける根本的な変化を象徴するものであった。1988年以来(以前のX.Orgを含め)Xの運営を担ってきたのはベンダー組織であったが、Foundationはソフトウェア開発者によって主導され、外部の関与に依存するバザールモデルに基づくコミュニティ開発を採用した。会員資格は個人にも開放され、企業会員はスポンサーシップという形で提供された。現在、ヒューレット・パッカードなどの大手企業がX.Org Foundationを支援している。
財団は X の開発を監督する役割を担っており、技術的な決定はコミュニティ メンバー間で大まかな合意を得て、そのメリットに基づいて行われます。技術的な決定は理事会によって行われるのではなく、この点で、技術的に非介入的なGNOME Foundation を強くモデルにしています。財団は開発者を雇用していません。財団は、 XFree86 4.4RC2 をベースに X11R6.6 の変更をマージしたX.Org Serverである X11R6.7を 2004 年 4 月にリリースしました。ゲティスとパッカードは、古いライセンスの下での XFree86 の最終バージョンを取得し、オープンな開発モデルを重視し、GPL との互換性を維持することで、多くの古い XFree86 開発者を参加させました。[ 51 ]
X11 は 1990 年代に OpenGL サポートなどの拡張機能を受けていましたが、そのアーキテクチャは 10 年間を通して基本的に変更されていませんでした。しかし、2000 年代初頭には、長年にわたって表面化していた「欠陥のある」フォントアーキテクチャ、常に拡張および/または置換されることを意図していた 2D グラフィックス システム、レイテンシの問題など、多くの問題を解決するために全面的に見直されました。[ 54 ] X11R6.8 は 2004 年 9 月にリリースされました。半透明ウィンドウやその他の高度な視覚効果の予備的なサポート、スクリーン拡大鏡とサムネイル、Sun のProject Looking GlassやCroquet プロジェクト などの 3D 没入型ディスプレイ システムとの統合機能など、重要な新機能が追加されました。コンポジティング ウィンドウ マネージャと呼ばれる外部アプリケーションが、視覚的な外観のポリシーを提供します。
2005 年 12 月 21 日、[ 55 ] X.Org は、レガシー ユーザー向けのモノリシックソースツリーである X11R6.9 と、同じソース コードを独立したモジュールに分割し、それぞれを個別のプロジェクトで保守できる X11R7.0 をリリースしました。[ 56 ] Foundation は、7.0 から約 4 か月後の 2006 年 5 月 22 日に、大幅な機能改善を施した X11R7.1 をリリースしました。[ 57 ]
XFree86の開発はその後数年間続き、2008年12月15日に4.8.0がリリースされた。[ 58 ]
システムの正式名称は、マニュアルのページに X、X Window System、X Version 11、X Window System、Version 11、または X11 と記載されています。[ 59 ]
「X-Windows」という用語は(後にリリースされた「Microsoft Windows」と同様に)公式には承認されておらず、 X Consortium のリリース マネージャーである Matt Landau は 1993 年に「業界誌が繰り返し誤用しているにもかかわらず、『X Windows』や『X Window』というものは存在しない」と述べている[ 60 ]。ただし、X の歴史の初期から非公式に広く使われており[ 61 ]、例えばUnix-Haters Handbook [ 8 ]のように、挑発的な効果を狙って意図的に使用されたこともある。
X Window Systemでは、一般的な用語の使い方と比べて、特に「ディスプレイ」や「スクリーン」といった用語の使い方が微妙に異なっています。便宜上、ここではその一部を以下に示します。
「ディスプレイ」という用語は、より専門的な用語である「ザフォッドディスプレイ」と混同してはならない。後者は、1台のコンピュータを複数のユーザーがそれぞれ独立したディスプレイ、マウス、キーボードで使用できるという、珍しい構成である。まるで別々のコンピュータを使っているかのように利用できるが、1席あたりのコストは低くなる。
将来のバージョンについては、X.orgのウェブサイトに次のように記載されています。[ 79 ]
X.Orgは、X Window Systemのソフトウェアコンポーネントの開発とリリースを継続しています。
これらは、X Window System 全体の「塊」リリーススケジュールを待つことなく、各コンポーネントの準備が整い次第個別にリリースされます。ダウンロードについては、各 X.Org リリースディレクトリを、含まれる変更の詳細については、xorg-announce アーカイブまたは git リポジトリを参照してください。
X11R7.8ロールアップ版カタマリのリリース計画は提案されていません。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)の管理者は、約 5、6 年前にほとんど何もなくなってしまいました。テクノロジーの進歩に追いついていませんでした。