KubuntuにおけるMir

Mir in Kubuntu | Martin's Blog

Blue Systems社員でKDE開発者のMartin Gräßlinが、Mirについて書いている。

Jonathanのブログ記事にあるように、Mataro Sessions IIでKubuntuにおけるMirについて議論した。このことに関しては、あまり話したくない。しかし、自由ソフトウェア業界の流れからして、議論しなければならないし、我々の下流（KDEを利用する層）も、なぜ上流（KDE開発の本家）は、Mirを受け入れるのは妥当な選択ではないのかと判断したかについて知る必要がある。

これは、CanonicalがMirで生み出した多大な問題に焦点をあてるものだ。私はMirが選択肢に入らない理由として、単に、「Canonicalは糞だ」[1]と言うわけにはいかない。我々がMirと統合しない理由について、私は正当な技術的反論を打ち立てなければならない。私は違いや利点欠点を調査するために時間を割いた。私にはそのような意見があるので、その意見をブログ記事で共有するのはいいアイディアだと思う。

この議論は、Blue Systems社内で同僚にX11とWaylandに関するプレゼンをしている最中に始まった。私は、まずX11について説明することにした。というのも、X11を理解せずに、Waylandの必要性を理解することはできないと思うからだ。Mirについて議論するつもりはなかったが、どういうわけか、議論がそっちの方向にいってしまい、MirとWaylandの違いや利点についての当然の質問が出てきたからだ。その後に続いたのは、Ubuntuとanonicalに対する罵倒だ[2]。そういうわけでその週の後半に、私は「KubuntuにおけるMir」についてより詳細に議論し、下流に対して疑問に答える努力をした。

イントロダクション

フラストレーションとモチベーション

まず、ひとつ明白にしておくことがある。Canonicalは何を開発しようと勝手だ。現状は別にどうでもいいし、またまた別のディスプレイサーバーだと、独自OSカーネルだとかまたぞろデスクトップシェルだとかを新たに立ちあげようとも、これまたどうでもいいことだ。本当にどうでもいいのだ。CanonicalとMarkのカネなのだから、奴らが思うがままにつぎ込めばいい。プロプライエタリソフトウェアだろうと、私の知ったことではない。

気にする問題とは、虚偽にまみれた技術的意見をもちこみ、Canonicalが一切貢献していないソフトウェアに関して無知な声明を発表し、自由ソフトウェアエコシステムを引っ掻き回したことだ。これは到底許せないことだ。非常にいらだつことであったし、私にとって、Canonicalの信頼は大きく損なわれた。この信頼を取り戻すのは難しいだろう。Canonicalはこれが、普通の企業業界ではなく、自由ソフトウェア業界であることを感謝すべきだ。普通の企業業界ならば、法務が動くような声明だったのだから[3]。また、この事件は私のモチベーションをひどく損ねたし、自由ソフトウェアエコシステムの一員である価値についても疑わせた。お互いに協力するのではなく、エコシステムのメンバーが急に競合相手となり、ソフトウェアスタックを侮辱し始めるのだから。これはとてもいらだたしい事態だ。

Mirを開発する妥当でまともな理由はあるのだろう。残念ながら、彼らはその理由とやらを開示していない。もし理由とやらがあるのであれば、さっさと説明すれば、私や他のプロジェクトはもう少し風当たりも良かっただろうに。そうであれば、疑問がない以上、あの発表に苛立つこともこれほどではなかっただろうし、この議論もなかっただろうに。だがしかし、Canonicalは間違った技術上の理由で説明することにしたようだ。

まだ準備できてない

現在、Mirはまだ準備できてない。これは重要である。あの発表により、我々には現状に対して4つの選択肢がでてきた。

1. Wayland計画を続行し、Mirは無視する
2. Mirに切り替え、Waylandは無視する
3. MirとWaylandをサポートする
4. Mirが準備できるまで、選択を保留する

Plasma Workspace 2の開発予定とMirの開発予定のタイムラインを描いてみると、お互いに重ならない。Mirが準備できる前に、Waylandをサポートしたい。選択を遅らせるのはあまり良くない選択だ。出戻りになるだけだからだ。つまり、選択肢2も妥当ではない。Mirが準備できるまで遅らせねばならないからだ。そのため、妥当な選択肢は、MirとWaylandの両方をサポートするか、Waylandのみをサポートするかだ。現在、Waylandに加えてMirもサポートするのが妥当なアプローチかどうか判断できる段階までコードが準備できていない。前に私がソースベースを確認した時点では、スタブにいくつもぶつかったので、まだ検証するほどの価値もなかった。そこで、我々は現状の情報だけで判断するしかないが、これはMirにとってはあまりよろしくない。

Wayland vs Mir

MirがWaylandより優れているかも知れないこと

MirとWaylandの違いは少ない。違いのうちの一つは、Mirはバッファをサーバー確保するのに対し、Waylandはクライアントサイドでのバッファー確保を行う。私はこれが利点なのか欠点なのか判じかねる。私はこの件に関しては、KristianとWayland開発者を信じることにする。

他の違いとしては、Mirはテスト駆動開発を行なっていることだ。私としては、開発手法は技術的な論点にはならない。私はユニットテストが行われているが動かないシステムより、ユニットテストが行われていないが動くシステムを使いたい[4]。また、KWinはテスト駆動開発をおこなっていない。もし、私がテスト駆動開発をより優れたものであると考えるならば、まず私は自分のところの開発手法を疑わなければならない。

まあ、この程度だ。現在のところ、Mirの利点となりうるかもしれない違いとして私が発見できたのは、これぐらいだ。もちろん、Mirがサイコーとなりうる利点はある。欠点については、私はもう少し長く書く。

ディストロ独自

現在のところ、Mirはたったひとつのディストリビューション専用である。現在のところ、他のディストリビューションでたとえMirが動くとしても、パッケージ化しようと興味を示しているところは存在しない。残念ながら、私は未来を見通す能力をもってはいないが、過去と現在から、未来を予測することはできる。過去を参照すれば、他にもCanonical独自のもので、他のディストリビューションには提供されていないものが存在する。私はUnityをパッケージ化している他のディストリビューションを知らないし、むしろ、UnityをUbuntu以外のディストリビューションでパッケージするのは不可能だとも聞いている。これを考えれば、Mirも同じ道を行くことはありうる話である。Unity用に設計されているのだから、他のディストロがUnityをパッケージ化しないのであれば、Mirだってパッケージ化する必要性がない。

これはMirの受け入れの可否に相当な影響を与える。KDE Workspace開発者で(K)Ubuntuを使っている者を、私は知らない。一体どういう開発が行われているのかとか、コードのレビューや保守はどうなっているかなど、私は一切わからない。これはつまり、受け入れる際には、ifdefで囲まれ、誰もコンパイルせず、誰も実行しないということになる。これでは朽ちていくのがあらかじめ約束されたようなものだ。そもそも、我々のCIシステムはopenSUSE上で動いているのだから、CIすら問題を検知できないということだ。もちろん、Kubuntuのような下流で開発されて、上流にパッチを送るという考えられるが、Kwinのソースコードを引っ掻き回すのは大事になるので、私はそういうことはしないことを大いに推奨する。また、我々が皆同意するように、下流パッチは邪悪である。我々はもはやそのような下流のユーザーをサポートできなくなるからだ。

アーキテクチャー

MirのアーキテクチャーはUnityを中央に据えている。Mirの仕様書はよくわからないBuzzワードだらけなので、Mirのアーキテクチャーを理解するのはとてもむずかしい[5]。私の分かる限りでいえば、Unity Nextとは、Mir上で実装されるウインドウマネージャとデスクトップシェルだ。これがどのようなものになるのか、私には分からない。とにかく、これはデスクトップシェルとウインドウマネージャを分離するという、我々の設計にはそぐわないし、我々はMirがそのような設計をサポートするかどうか分からない。また、MirがメインのターゲットであるUnity Next以外のデスクトップシェルをサポートするかどうかも分からない。一方Waylandは、複数のコンポジター実装を念頭に設計されている。Kwinをセッションコンポジターとするのは、規格の例にも示されている。

ライセンス

WaylandはXのようにMITライセンスでライセンスされていて、これはディスプレイサーバーとしてふさわしい。私はこれをとてもいいライセンスの選択であると思うし、Wayland開発者がこのライセンスに決めたことを嬉しく思う。MirはCLA付きGPLv3のみでライセンスされている。私はこのような部分のスタックにこのようなライセンスを使うのは不適切であり、KDE Plasmaから使うのはリスクに晒すと思う。KWin（とほとんどのKDEソフトウェア）は「GPLv2とそれ以降」なので、これが不可能になり、KWin（とMirサーバーに依存するソフトウェア）はMirの派生物となるので、我々のコードは「GPLv3のみ」にしてしまう。私は「GPLv3のみ」のソフトウェアを我々のアプリケーションスタックのコア部分に依存させるつもりはない。これは将来GPLv3と非互換のGPLv4がでてきたときに深刻な問題を引き起こす。私はCLA[6]が嫌いだ。そのため、ライセンスの点から、Mirは到底受け入れがたい。

Unity専用/プロトコルなし

Waylandにおける重要な点は、プロトコルを拡張できるという事だ。これはXでも重要な機能になっていて、ICCCMやEWMH上で我々の独自拡張を使って、追加の機能を実装している。もちろん、我々のworkspaceにも独自のアイディアがあり、これを興味のあるよそのためにも、「標準化」できることは重要である。これはプロトコル拡張のおかげだ。
Mirには本物のプロトコルがない。「内部コア」は、「プロトコル無保証」と記述されている。我々が使うにあたっては問題になる。我々のアーキテクチャは、上記の通り異なったものであり、デスクトップシェルとコンポジターの間にプロトコルが必要になる。Mirがそのようなプロトコルを提供しないのであれば、独自プロトコルを使うしかない。その独自プロトコルはすでに存在していて、「Wayland」と呼ばれている。とすると、MirをサポートするのにWaylandプロトコルが必要になるのか？！？　わけがわからない。必要な機能を得るためにMir上でWaylandを走らせる必要があるというのならば、そもそもMirを走らせる必要があるのか？

なおさら悪いことに、MirサーバーとMirクライアントの間のプロトコルは、安定とはされていない。実際、いずれ互換性を壊すと約束されている。これは重大な問題だ。これは致命的な障害物だ。Canonicalにとってみれば、これは問題ない。Canonicalは全体を支配しているので、QMirのようなプロトコルを使って全体を変更できるからだ。

我々にとっては、全く別だ。プロトコルがいつ何時でも変更されうる上、すべてがUnityのためだけに開発されていることを考えれば、サーバーライブラリにバイナリ互換はなく、サーバーライブラリの古いバージョンは最新版のクライアントライブラリとお話できないということが予測できる。我々は常に不安定で互換性を破壊する土台の上で開発しなければならなくなる。これはとても批判的にみえるかもしれないが、私はあるCanonicalのプロトコルがリリースサイクルの後期になって変更され、Kubuntuの同プロトコルを使うアプリケーションを完全にぶち壊した例を知っている。この経験から、リリース前にプロトコルが変更されてKubuntuが出荷できなくなる事態が起こらないと信頼することなどできやしない。

これはサイコーではなくサイテーだ。KWinはMir上でまともに動くことはない。

この考察で、KDE Plasma workspaceの中でMirを使うのは選択肢に鳴らないという事を示せたと思う。MirがWaylandより優れているということは一切なく、同時に、Mirを統合できず、Waylandとともにサポートするという事もできない障害物が複数ある。不安定プロトコルとライセンス選択は明らかに受け入れられない。

Kubuntuはどうなるのだろうか。

疑問符

CanonicalによるMirへの移行は、Kubuntuに疑問をもたらす。回答できる疑問もある。上流はサポートの興味なし。サポートのためのパッチ受け入れもまずなし。上流がMirを使わない以上、UbuntuがMirに移行した後の、Kubuntuのグラフィックスタックはどうなっているのだろうか。この疑問には今答えることはできないが、おそらくあまり良くはないだろう。

スタックへのパッチ

Ubuntuは常に、自由ソフトウェア界における最悪のグラフィックスタック環境である。バグトラッカーから明らかだ。UbuntuのMesaスタックの品質はとても悪い。MirではUbuntuはMesaスタックをさらに激しくパッチしなければならないだろう。実に見たくない光景だ。しかも、MesaはWaylandサポートを有効にした状態でパッケージ化されなければならない。しかし、Canonicalは継続してそんなことをするのだろうか。もししないとなると、Kubuntu（や他のUbuntuフレーバー）は、独自のMesaスタックをつまなければならなくなるのだろうか。もし、Canonicalによる変更があまりにも大きく、標準MesaスタックがUbuntuスタックの上で動作しなくなったらどうするのか？

Switching Sessions

セッション切り替え

自由ソフトウェアの利点のひとつに、デスクトップ環境をログインマネージャから選択できるという事がある。Mirの世界ではこれが不可能になるのではないか。UnityはMirシステムコンポジターとLightDMの上で動作する。KDEはXサーバーかWaylandシステムコンポジターを必要とする。従って、ログインマネージャから直接、別のシステムコンポジターを使うセッションを立ち上げることが不可能になる。同じシステム上でUnityとKDE Plasmaの両方を使うことがいつまで可能だろうか。UnityとKDE Plasma（あるいはGNOMEやXFCEなど）のセッションを同時に立ち上げることは、不可能になるのではないか。

システムコンポジター

システムコンポジターはシステムのどこまで奥深く潜りこむのだろうか。Mirシステムコンポジターを無効にしてXやWaylandに切り替えることは可能なのだろうか。パッケージがコンフリクトしたらどうするのだろうか。KubuntuとUbuntuを同じッシステム上にインストールすることは、今後も可能なのだろうか。Canonicalがそういうことを気にするだろうか。システムコンポジターとは、いずれGRUBでUbuntuかKubuntuを選択して切り替えるレベルにまで落ちるだろうか。

Packages from Where

どこからパッケージ

現在のところ、XとWaylandとMesaはCanonicalによってパッケージ化されている。しかし、将来はどうなるだろうか。Xのパッケージは存在するのか、Waylandのパッケージは存在するのか。存在しないとしたら、どこから持ってくればいいのか。大方はDebian unstableだろう。しかしDebianは停滞するかもしれない。そもそもUbuntuスタックでXとWaylandのDebianパッケージを使うという事が可能なのだろうか。KDE Plasma[7]の要件を満たすのだろうか。もしCanonicalがWaylandパッケージを提供せず、universeに落としたならば、mainのMesaには依存できない。WaylandサポートのMesaをどうすればいいのだろうか。

未来は未来にならないと分からない

このような疑問には、今答えることができない。MirがUbuntuスタックに統合されるまで待たなければならない。その後に、Kubuntu開発者はスタックがどこまでぶっ壊れるのかを知るであろう。私は、Mirへの移行が完了した後に、Ubuntuフレーバーを提供可能であると楽観的に考えてはいない。CanonicalがUbuntuの上に作られるコミュニティ提供のディストリビューションにそれほど興味を持っているとは思わない。そのような兆候が様々な些細な変更点から察せられる。まあ、いずれ分かるだろう。あるいは、私は批判的すぎるのかもしれない。

[1] CanonicalがWaylandに対する誤った情報を流しつつMirを発表したことを考えれば、この技術を却下するにあたって、これも技術の可否を選択する妥当な手法ではないかと思う。

[2] 我々のバグトラッカーがUbuntuリリースのあとに、また膨れ上がったので、まあUbuntuにはいらついていたのだ。

[3] 実際、KwinがMir上で問題なく動くという声明を出したときは、KDE e.V.(訳注:ドイツのKDE登録協会)に言って、Abmahnung(訳注：ドイツ法における法的要請)を送ってもらおうかとも思っていたのだ。

[4] 実際のところ、私はテスト駆動開発を、その一部には便利なところもあるが、無意味で無価値な手法だと考えている。

[5] 「我々のプロトコルと、プラットフォーム不関与アプローチによって、我々はプラットフォーム群とデバイスフォームファクターにおける一貫して美しいユーザーエクスペリエンスのゴールに到達できる」

[6] もちろん、QtにもCLAはあるし、私も署名している。しかし、QtにはKDE Free Qt Foundation agreementがある。

[7] 先週、KWinに入った機能は、私にはテストも利用もできない。なぜならば、Debian testingのX_serverは古すぎるからだ。

WaylandとMirの流れを追っていない人のために解説しておく。

まず、現在UNIX互換環境で主流のディスプレイサーバーはX11を実装したX.Orgである。しかしX11は大昔に設計されたものであり、色々と時代にそぐわなくなってきている。そこで、全く新しいプロトコルを新規に設計して実装しようという動きがある。それがWaylandで、最近設計され、実装が進んできた。

Canonicalは当初、UbuntuをWaylandに移行させると発表してきたが、突然、秘密裏に独自開発してきたディスプレイサーバーであるMirに移行することを発表した。

この発表で、自由ソフトウェア界は大いに揺れている。

さて、このブログ記事であるが、ブログコメントや、Hacker Newsで議論されている。議論の内容は、部外者でも議論しやすい、テスト駆動開発とライセンスに集中しているようだ。

Martin Gräßlinは、あまりテスト駆動開発を評価していないようだが、テスト駆動開発の信奉者が激しい反論を始めている。また、ライセンスがGPLv3のみで貢献にCLA必須というのも、それほど悪いことかと反論されている。

CLAとは、貢献者が著作権をソフトウェアプロジェクトに譲渡するものだ。ある程度の規模の自由ソフトウェアプロジェクトならばどこもCLAを採用している。その目的は、将来プロジェクトのライセンスを変更する必要が生じた場合、貢献者ひとりひとりに個別に同意を求めるのは不可能だからだ。Martin Gräßlinの主張では、Qtは将来ソフトウェアをLGPLやGPLv3でも提供し続ける約束をしているのでCLAに安心して同意できるとのことだが、あまり変わらないのではないかと思う。

ディスプレイサーバーがGPLv3であることの是非についてだが、GPLは著作権と特許権をもとにしたライセンスである以上、ディスプレイサーバー上で動くクライアントにまで著作権が及ぶはずもなく、クライアントソフトウェアからは問題がないのではないかと思う。クライアントソフトウェアから使うライブラリは、LGPLなどのもう少し制限のゆるいライセンスを使うだろうし。もしディスプレイサーバーがGPLであることが問題だとするならば、カーネルだってGPLが問題になるはずだ。

ただし、KWinはその性質上、Mirを取り込む場合、Mirの派生物になるので、GPLv3のみで、しかもライセンスの選択がCanonicalに握られているのは、問題になるかも知れない。