プロトコルXに関する意見

2年前、 Awesomeの作業中に、 Freedesktopイニシアチブの一部であるXCBの開発に参加しました。 X11プロトコルの秘密と、それを取り巻く古代の神秘的な世界全体を学ぶ必要がありました。



過去数ヶ月にわたって、私はついにこのすべての汚物を洗い流しました。そして今、私は何十年も続いているこの混乱についての私の考えを共有する必要性を感じています。

私がまだ世界にいなかったとき...

... Totoは有名な曲 "Africa"をリリースし、何人かの賢い人がウィンドウシステム（X Window System（正式名称））で作業しました。XWindow Systemも（あまりにも）長い歴史があります。 プロトコルの最終バージョン（11日）は80年代に開発されました。 ストーリーの詳細については、 ウィキペディアの記事をご覧ください 。



2010年、私たちはディスコを聴き続け、80年代に開発されたさまざまなプロトコルを使用します（Xよりも前ですらあります）。 音楽は進化し、プロトコルは変わり、X11は止まりません。



問題は、X11が正しく進化しないことです。 MITの人たちや他のあらゆる賢い場所は、1984年にXの最初のバージョンを作成し、プロトコルの11番目のバージョンまで変更を加えました。 1987年にリリースされ、現在まで使用しています。 「早期リリース、頻繁な更新」モデルに完全に準拠して、3年間で11のバージョンがリリースされました。 理由はわかりませんが、次の23年間でこのアプローチの使用を停止しました（ただし、開発者は多くのプロトコル拡張機能を追加（および削除）しました）。



プロトコルXの最初の11のメジャーバージョンでどのような変更が行われたのかはわかりませんが、過去20年以上にわたって重大な変更を行う必要があることは間違いありません。



私の謙虚な意見では、X11は23年の寿命を期待して設計されていません。 確かに、私は誰のせいでもありません。私は4歳の子供で、プロトコルXの最新バージョンがリリースされたときにレゴをプレイしていました。

修正しません。 適応します

これはおそらく、近年のプロトコルXの主なスローガンです。 誤解しないでください：むち打つつもりはありません。



X11プロトコルは長年にわたって古くなり、開発者は拡張機能を追加し始めました。 長年にわたって、多数の拡張機能が追加されてきました。 Xの元の原則の 1つに厳密に従って：

システムとは何かを明確に定義することが重要です。 全世界のニーズに応えようとする必要はありません。 代わりに、適切な方法で追加のニーズを満たすことができるように、システムを拡張可能にする必要があります。

（alas and ah）X11プロトコルは、ビデオ、OpenGL、マルチモニター、楕円形のウィンドウの描画の楽しさなど、過去23年間に出現したすべてのものを提供していなかったため、例外なくすべて追加されました。 これらの拡張機能の一部は現在も使用されており、一部はすでに忘却の中に沈んでいます。



プロトコル拡張機能は悪くありませんが、 XFixesのような拡張機能を使用してプロトコルを修正しようとすることは、Keith Packardが従う可能性があるすべての善意にもかかわらず、私にとっては悪い考えのようです。

実際にはあなたが思っているより悪い

X11プロトコル（拡張なし）は、約120種類の要求を定義します：ウィンドウの作成、ウィンドウの移動など。



現在、それらの少なくとも25％は完全に役に立たない：サーバー側でのフォントの使用や正方形やポリゴンの描画は、現代のアプリケーションやツールキットでは使用されていません。 それらはすべて、 XRenderなどの拡張機能からのリクエストで再定義されます。



複数のモニターでの作業は完全に混乱します。 X11はZaphodモード（独立したモニター）で動作するように設計されました。 しかし、 Xineramaおよび最近のXRandRは完全に取って代わりました-X11プロトコルのコアの一部であるにもかかわらず、最新バージョンのXサーバー（2007年頃以降）はZaphodモードをサポートしなくなりました。



さらに悪いことに、DECの研究者による論文で説明されているように、多くのクエリには設計上の制限や欠陥が含まれています。Xが理想的なウィンドウシステムではない理由 。

さらに壊れた基準の上に積み上げます

Xは最初の原則に従ってポリシーを定義せず、適切に見えるメカニズムのみを提供します。



その結果、開発者は集まり、一連のルールとドグマICCCMを定義する仕様の作成を開始しました。 それは1988年の22年前のことです。 この仕様の多くのポイントがすでに絶望的に時代遅れになっていることを追加するのは無意味です。なぜなら、それらは多くの最新のテクノロジーを考慮していなかったからです。



そう考えるのは私だけではありません。 2つの主要なデスクトップ環境であるKDEとGNOMEになったプロジェクトの作者は、これを90年代にすでに見ました。 そして、彼らはEWMHを書きました。これはICCCMの上に積み上げられた別の標準で、それに多くの素晴らしい機能（最大化、フルスクリーンモードなど）を追加しました。



問題は、この標準が、環境（GNOME、KDE、およびそれ以上）で同時に作業した、あまり先見の明のない人々によっても書かれたことです。 これらのデスクトップ環境には、デスクトップの動作方法を決定するいくつかの強力な概念があります。「ワークスペースが必要」、「ウィンドウは1つのワークスペースにしか存在できません」、「表示できるのは一度に1つの職場」、「複数の画面はありません」など。

心配しないでください。ツールキットがあります！

GTK +やQtを含む、EWMHを実装するすべてのアプリケーションまたはライブラリのデスクトップがどのように機能するべきかという考えは、今では大理石で刻まれています。



その結果、今では誰もが標準を忘れてしまいました。 ツールキットは独自にそれらを実装し、X11プロトコルの制限と欠陥をバイパスし、誰も振り返ることを望みません。



そして、これらのツールキットを使用すると、人々は標準と同じように気軽に扱われます。 これにより、不快な副作用が生じることがあります。 たとえば、スイッチジョブとしてのOpenofficeなど 。

振り返りたくないですか？ さらに悪いことに、私たちはどこから来たのか忘れていました！

これらの設計が不十分な標準をすべて備えたデスクトップは、10年にわたって進化を続けています。 新しい標準は引き続き追加されます。最新の標準は、たとえば、 デスクトップ通知仕様やKDEで開発された最新のステータス 通知仕様など、D-Busに基づいています。



Status Notifierは、古き良きXEmbedベースのシステムトレイの新しい実装ですが、現在はX11の代わりにD-Busメカニズムを使用し、システムトレイにアイコン以上のものを表示する機能を追加しています。



ドラフト仕様には、Wolfgang Draxfinger がXDGメーリングリストへのアピールで強調した重大な設計欠陥が含まれています 。 Wolfgangは、Xはネットワーク指向のプロトコルですが、D-Busはそうではないと指摘しています。 したがって、D-BusとStatus Notifier仕様を使用してシステムトレイイベントを送信することはお勧めできません。コンピューターBでコンピューターAからグラフィカルアプリケーションを実行すると、間違ったホストのトレイが更新されます。



通信を読んで、これが一部のKDE開発者を怖がらせないことは明らかです。

もちろん、この奇妙な特殊なケースについてはあまり心配しないでください。 少なくとも、自分でそれに出くわすまで（何かをテストしたり、洗練されたキオスクを設定したりして）、そのように考えるでしょう。」

オズワルドが特別なケースとして説明しているのは、私たちのほとんどにとって最も典型的な状況です。 一般的に、幸運な人。



私の意見では、これは間違った方向への後退です。 しかし、Xのネットワーク部分は、少なくともKDEにとっては役に立たなくなったと結論付けることもできます。

XCBを信じたい

Freedestopに入社したとき、XCBライブラリであるXC Bindingで作業する必要がありました。 XCBには、X11プロトコルを操作するための、すてきできれいな21世紀の技術ベースのAPIがあります。 そのコードは、プロトコル記述を含むXMLファイルに基づいて自動的に生成されます。



比較のために、Xlibは80のコードからなる泥だらけのコードで構成されており、ほとんどコメント化されておらず、ハードコードされたものでいっぱいです。 国際化やXKBの実装など、その一部を理解できるのはごく少数です。 そして、彼のコードはすべて同期的です。



まだ知らない人のために説明します。Xは、応答を受信するために要求（HTTPのGETなど）を送信する必要があるネットワークプロトコルです。 Xlibは、要求に対する応答をアプリケーションに待機させるため、Xサーバーが応答を送信するまでアプリケーションはブロックされます。 XCBはアプリケーションをブロックしません。これにより、一連の要求を送信し、待機中に何か便利なことを行ってから、回答を得ることができます。



ブラウザーがWebサーバーに一度に1つのリクエストを送信し、最新の画像がアップロードされるまでページが表示されるのを待つように強制するとします。



Xとそのすべてのクライアントが同じコンピューター上にある場合、遅延は小さく、知覚できないため、XCB非同期の利点はわずかです。 ただし、低速ネットワークでは、 XCBでxlsclientsを書き換えることによりPeter Harrisが証明したように、パフォーマンスが大幅に向上する可能性があります。



XCB開発者の長期目標の1つは、Xlibアプリケーションを最終的に削除して、X11アプリケーションの速度を上げ、応答時間を短縮することです。 これを行うには、多くのライブラリを移植する必要があります。Cairoを除くほとんどのライブラリはXCBをサポートしていないためです。



私の観点からは、今ではこれはかなり役に立たない仕事です。 デスクトップの世界はGNOMEおよびKDEプロジェクト、つまりGTK +およびQtに委ねられています。 同時に、これらのツールキットのいずれもXCBまたはプロトコルXの作業に関心がないようです。Xの既存の制限と欠陥を回避するために多大な努力をし、依然として松葉杖と悪意のある実装の山の上に座っています。設計基準によります。 これらのすべてのレベルを振り返り、どのように改善できるかを見たいと思う人はいないようです。



彼らはあまりにも高く登って見下ろし、どのような反動が起こるのかを確認しました。



EFLによる 啓発は、XCBバックエンドを持つ最初のツールキットでした（Vincent Torriのおかげです）。 残念ながら、このバックエンドはサポートされなくなり、誰も気にしません。 私が最後にそれを取ったとき、それはコンパイルさえしませんでした。

X12？

Freedesktop wikiには、修正が必要なすべてのものをリストするX12というページがあります。 残念ながら、このリストは成長しているだけであり、X12で作業することについてどもりはありません。



一方、自由時間でXKB2に取り組んでいる人が何人かいます。これは、「try-fix-keyboard-part-protocol-written-23-years-ago-extension」の2番目の拡張機能です。



全体として、X12は今後10年で登場するようには見えません。

代替案？

代替Xはありますか？ Waylandがありますが、これまでのところかなり価値がありません。 DirectFBもありますが、移植は不十分です。 私の意見では、Xを置き換える候補はありません。



いずれにせよ、メインツールキットのいずれもこの代替をサポートしていません。 GTK +はかつてDirectFBをサポートしていましたが、私が知る限り、現在は何も機能していません（ Josselin Mouetteがメモしています ） Debianインストーラの最新バージョンがグラフィカル部分でXを使用するようになったのはそのためです（Cyril Bruleboisの仕事のおかげ）。

おわりに

XCBは5年以上存在していますが、それに興味を持つ人はほとんどいません。 私が見る限り、誰もXプロトコルの使用に興味がなく、誰もがそれを高レベルAPIでカプセル化して、できるだけ早くそれを見るのをやめようとしています。 これは、ひどいハッキングに満ちた不十分な記述のアプリケーションとツールキットの出現につながります。



これはすべて、XCBに基づいた新しいアプリケーションとツールキットの作成は非常に興味深いプロジェクトであるべきことを意味しますが、QtやGTK +を含む先人によって長年にわたって導入されたXプロトコルの欠陥を回避する方法を理解するには時間がかかりすぎます。



メインツールキットは、Xの暗い海に戻っても勝つことはほとんどありません。ほとんどの開発者は、誰にとっても最高の基盤を再定義するよりも、ジオロケーションに基づいた美しい3D効果に取り組むことを好みます。



ワールドXの労力は少なすぎます。 DebianでのXメンテナーの不足は、この状況の単純な結果です。 もちろん、非常に有能で資格のあるX開発者がいます。PlanetFreedesktopのブログを読むことで簡単に確認できます（数えません）。 残念ながら、入力デバイス、グラフィックスデバイス、新しいプロトコル拡張機能の仕様など、Xの範囲全体をカバーするには数が十分ではありません。 サーバーXはかなり後期の開発であり、ほとんどの開発者は、プロトコル自体ではなく、サーバーXでの作業に関心があります。 これは理解できます。



私たちはこれらすべてを数年のうちにどこで手に入れるのだろうか。 今まで、私はXと呼ばれるボイラーで3年間煮沸してきましたが、遅かれ早かれKDEとGNOMEに代わるすべてのものが消滅すると感じています。 数十の「モダンな」ウィンドウマネージャーから選択できる時代が過ぎました。



最後に、コンピューターソフトウェアに適用した場合、それは単純なダーウィニズムかもしれません。



翻訳者注：この記事の著者は、Awesomeのウィンドウマネージャー開発者であるフランス人プログラマーJulien Danjouです。 元の記事はこちらにあります 。 これが私のレーンです。私は長い間翻訳を練習していませんので、訂正と説明に感謝します。