IntelとMirにおけるドライバー開発者からの観測

Canonicalは、Intelの自由なソフトウェアによるグラフィックドライバーで、XMirをサポートするためのパッチを提出し、Intelに取り込んでもらおうとした。Intelは一端パッチを取り込んだものの、急遽、Intel社員のChris Wilsonsによって、不自然にもrevertされた。

xorg/driver/xf86-video-intel - Intel video driver

そのgitコメントに曰く、

我々はCanonicalの選択した方法を支持、サポートしない。
そしてXMirパッチをupstreamに受け付けない。
-管理部(-The Management)

どうやら、Intel社内で、なにか技術的理由に基づかない、政治的判断が行われたことを匂わせるコメントである。

これに対していくつも推測が挙がっている。Intelは前々からWaylandを推していたし、Mirはライバルとなるからサポートしたくないのだとか、MirはARM環境もサポートしていて、これはIntelに対しては競合相手であるから、ARMをサポートするようなMirを間接的にせよサポートしたくはないのだとかだ。

様々な憶測が飛び交っているが、明らかに、これは技術的理由ではなく、政治的理由による拒否にみえる。"-The Management"という記述も、Chris Wilsons本人の意志ではないことを伺わせる。

このrevertのコミットログは、phoronix.comによって目ざとく発見され、報道された。

[Phoronix] Intel Reverts Plans, Will Not Support Ubuntu's XMir

これに関して、昔SuSEで解析結果を元にした非公式の自由ソフトウェアによるグラフィックドライバーであるRadeonHDを開発し、今はARM SoCに搭載されているMali GPUを解析して、自由なソフトウェアによるグラフィックドライバーを開発している、Luc Verhaegenにより、感想が書かれている。とても興味深い。

libv: Intel & Mir: The point-of-view of a graphics driver developing bystander.

オープンソースソフトウェアが「コードとか設計とか正しく実装する」とかじゃなくて、「オープンソースソフトウェアとは権力と政治と企業の影響力とめちゃめちゃたくさんのノイズ」であることを書いてからまだ数日だというのに、Intelが行動で実証してくれたことはありがたいね。

これについて書く前に、どうやらこれは、Chris Wilsonsの判断や、あるいは望みの結果ではないようだ。Chrisは、明らかにされていない勢力あるいはIntel社内の党派に言われた通りのパッチを書いた。手を引けと。また、個人的にはCanonicalのやり方は気に入っていないものの、グラフィックドライバー開発者としては、Intelの方針は物事を悪くするだけだ。Intelはこの件に関して、あまり深く考えていないのではないだろうか。

問題

グラフィックドライバー開発者として、Mirには大きな問題は見当たらない。

CanonicalがWaylandを再発明しようとしたわけだ。あのヘンテコなcontribution agreement（単に貢献を阻害するだけだ）の他は、Mirは完全に自由なソフトウェアなわけだろ？　奴らが労力の無駄遣いをして、また奴らのユーザーが影響を受けるかもしれないが、何の問題があるんだよ？　Canonicalを支持しているというわけではないが、重大な問題があるわけでもない。

なんでCanonicalは独自にやることを許されないんだよ？

再発明爆発

頻繁に起こる再発明は好きではない。再発明はオープンソースソフトウェアを蝕む病気で、ためにLinuxが市場で成長することを妨げている。

何かが古臭いとか壊れてるとか近代的な需要を満たせないとかいう主張を聞くのは、これで何度目だ？　そして、なにか新鮮なものが新たに開発中であり、これは過去の「失敗」に学び、あと数ヶ月もすれば、すべてが最高になる、とかいう主張が続くわけだ。残念ながら、物事はそういうわけにはいかない。既知の「エラー」は修正されるかもしれないが、残りのすべてはぶっ壊れる。ぶっ壊れたところは再発明するか、移植するかしなければならない（でもいまだにぶっ壊れたままだ）。そして数年たった後も、まだ完全ではないので、誰か他の奴らが（時には、同一人物が）、またぞろ次のでっかいことをスクラッチから実装するわけだ。

何かちゃんと動くものが得られたためしはない。ぶっ壊れたものがぶっ壊れたままのものに変わるだけだ。しかも誰も失敗から学ぼうとしない。誰も、「ちょい待ち、これって3年前に聞いた話とおんなじじゃね？」とか言わない。

私のような愚直なドライバー開発者としては、WaylandはXの再発明にすぎないように見える。過去の過ちから学んだサーバー/クライアント型のディスプレイアーキテクチャーの実装、でも全部ぶっ壊れている。2009年からずっと、細かい問題がすべて解決されるのを待ちぼうけてる。しかもある時点で、Waylandにネットワーク機能[1]が追加されたので、さらにX代替品臭くなった。

そして、Mirが発表sあれ、急に世間が騒がしくなった。宗教戦争が盛んに起こり、Mark Shuttleworthはフォーラムで火あぶりにされた。筆者も当初、Mirには皮肉めいたものを感じていて、反発が起こるのも当然だろうと考えていたが、その後、この記事を読んだ。これは他ならぬ再発明者が、自分のことを棚に上げて、CanonicalがWaylandを再発明したと避難しているだけだ。これはひどい。

一体誰がこいつらに再発明の専売特許を与えたのだ？

Intelは何を恐れているのか？

なぜMirがWaylandの脅威となりうるのか。

Intelは相当にでかい企業で、グラフィックに割いているオープンソース開発者の規模もおそらく最大だろう。この業界で最も優れた、最も影響力のある人間を雇っている。しかも、Waylandのほうが早く始まったし、枯れる時間もより多くあったし、より多くのアプリケーションやツールキットも移植されたし、多数派である。多くの者が、Waylandの未来は確固たるものであると考えている。

では、Intelのグラフィックドライバー開発者達がXMirをサポートするなと言われるほどのWaylandへの脅威が、どうしてMirにあるのか、一体Mirの何がそんなに優れているのか。これを考えると、このような対抗策に出た以上、Mirが何か技術的にはるかに優れている何かを持っているのか？　もし、Intelがこのような抵抗を示さねばならぬと感じたとしたのならば、それはつまり、Waylandが明らかに完全に役立ずということであり、むしろタオルを投げてMirに参加すべきではないのか。

自己の欠点を覆い隠すということか。

ソフトウェアファシズム

Intelは、Waylandが直接Mirと競合するより、X.orgグラフィックドライバーと馴れ合う必要があると思ったらしい。

このような力比べはよろしくないし、思っているよりも深い痛手である。ソフトウェアが、公平で平等な立場で競争する機会を妨げ、その結果として、まともな競争ができないことにより、我々全体に損失を与えているし、競争なんてものには関わり合いになりたくない手合にも損失だ。そういう動きは大抵、もっと技術的に劣っていて、倫理的に不適切な選択がなされるものだ。

これに関して思いつくいい先例がRadeonHD対Radeonの戦い[2]だ。RadeonHDは2007年9月にまともなオープンソースドライバーで、ATIを打ち負かしていた。そこで、我々SuSEは、エンタープライズデスクトップ向けにまともなオープンソースドライバーを提供する目標を発表した。3ヶ月後、Radeonが同じハードウェア向けのサポートを出してきた。技術的に劣っていたし、radeonHDの労力を大量にパクっていた上、よくわからないゴミを付け加えていた。さらにひどいことに、X.orgコミュニティを自称する奴らが、ソフトウェアファシズムを発揮して、Radeonドライバーの方を推奨しだした。これはまず、当然あるべきメーリングリストの拒否に始まり、RadeonHDをxserverのビルドスクリプトから削除することで陰湿さをまし、そしてかつてない規模のいやがらせとして、RadeonHDドライバーが死んでから2年後に、RadeonHDレポジトリの破壊（告発者は辱められ、犯人は、「速やかな」自白により赦された）

で、誰が勝ったの？

まあ、勝者はRadeonHDではないな、Novellが大部分のニュルンベルグのSuSE開発者をクビにした2009年にRadeonHDは死んだわけだし。運悪く、同時期に、AMDも経理上の問題を抱えていて、SuSEのRadeonHDプロジェクトの支援を続行しなかった。しかし、Radeonは生き残ったとはいえ、勝ったわけではない。ATIが勝ったのだ。AMDは負けたのだ(AMDはまともなオープンソースドライバーを欲していたが、ATIは真剣に取り扱わなかった)。というわけで我々は皆負けた。Fglrxは今日でも優位を保っている。まあでも、昔ほど悲惨ではない、というのも、枝葉のドライバーが、fglrxには満足しないユーザーに対する代替案とはなっているからだ。だが、radeonドライバーはATI fglrx開発者が推奨するままの方法を取り入れ、RadeonHDのような観測的事実に基づく選択を行わないので、radeonドライバーはもっとまともになれるのにそうはしない。

ソフトウェアファシズムは単に競争を阻害するだけではない。常に、ソフトウェア自体に悪影響を及ぼすのだ。Intelドライバーは今後一切、愚かな決定に振り回されることはないと、誰が言えよう。

グラフィックドライバーの責務

グラフィックドライバーの責務は、グラフィックハードウェアの利用者をサポートすることだ。もし、ベンダーに雇用されているのであれば、利用者はハードウェアを購入した者たちのことで、もし満足すれば、また再びハードウェアを購入するだろう者たちだ。だから、利用者のオペレーティングシステムやインフラをまともにサポートするのは、ビジネス上必要なことである。しかも、オープンソースソフトウェアでは、利用者は単なる客ではない。テスターでもあるのだ。

Canonicalの計画とマーケティングは、どうやらだいぶ効果的なようで、地球の半分が、LinuxイコールUbuntuだと思い込むほどだ。UbuntuはおそらくLinuxデスクトップ市場で大きな地位を占めているだろう。これはつまり、Ubuntu利用者はIntelの利用者層のうちの結構な割合を締めることになる。ハードウェアベンダーとして、（そしてディスプレイサーバーの開発は副次的なものだとして）、Intelはこのような利用者のサポートを拒否したり、あるいは異端者のごとく扱ったりはできないのだ。CanonicalはMirこそが将来のUbuntuリリースのディスプレイサーバーになると決断したのだから、それはつまり、IntelにはMirをサポートする責務が存在するのだ。

Intelのグラフィックドライバー用のXmirパッチは最小限のもので、それほど込み入ったものではない。そしておそらく、Intelのグラフィックドライバー開発者とUbuntu開発者の間で直接の対話が行われただろうことは間違いない。MirはUbuntuの次期バージョンで出荷されるので、XmirコードをIntelのグラフィックドライバーでテストするユーザーは相当な規模になるだろう。Xmirのコードが近い将来にやく立たずになることはなく、Intelがこのコードにかける必要のある労力は最小限である。

良きドライバーを書く秘訣は、素早く簡単なデバッグ方法を提供することである。グラフィックハードウェアは複雑で、そのハードウェア用のドライバーもまた複雑で、どちらも完璧ではないので、バグ解決の機会は最大化しなければならない。すなわち、ユーザーと対話を容易にし、ユーザーに変更をテストさせる簡単な方法を提供し、まともな感想を素早く得られるようにしなければならない。ユーザー向けに十分に簡単な方法を提供しなかった場合、バグが修正されないし、問題が大きくなるにつれ、ドライバーにとっても状況は悪くなる。

このパッチを取り込まないことで、IntelはUbuntuユーザーのバグリポート先をUbuntuのみに限定してしまう。これはつまり、実際のドライバー開発者に届くバグリポートの数が減ってしまうという事だ。同時に、Ubuntuユーザーは単に追加のデバッグや修正が含まれたupstreamのコードをテストすることもできなくなる。さらに悲惨なことに、この狂気が続けば、IntelがMir下のみ再現できるバグの修正を拒否するようになることが容易に想像できる。たとえそのバグが、とてもとてもたかいかのうせいで　実際のドライバーのバグであり、たまたまMirによって発覚しただけかもしれないのに、だ。

実際問題として、Intelは、MirやCanonicalより何よりも、自分自身のグラフィックドライバーを損ねてしまっている。

Linuxのandorid化

Linuxのインストールベースとして最大のものは、androidである。その規模は何桁ものレベルで違う。不幸にして、androidと呼ばれているlinuxは、単にlinuxカーネルと、その上の、いくつかの比較的真新しいオープンソースインフラにすぎない。これは、ある意味、オープンソースソフトウェアへの追い風ではあるのだが、申告な脅威でもある。もし注意深くなければ、ハードウェアに完全に囲い込まれてしまう。カーネルのGPLを守らせるのが、とても狭い範囲になってしまい、オープンソースのユーザースペースのドライバーを得る可能性が実質なくなってしまうのだ。これは現在巷にあふれているlinuxハードウェアの有効性を制限してしまう。そして、デスクトップとモバイルの興隆により、完全なオープンソースが提供されているハードウェアの存在も危うくしてしまう。さらに、この手のハードウェアを大量に製造するエレクトロニック企業が、オープンソースに貢献する利点を見いだせなくなってしまい、また貢献する方法を学ぶことも難しくなってしまう。

だからこそ、私はlimaドライバーを立ち上げたのだ。だからこそ、何人かの勇敢なる戦士たちがGPUの逆解析プロジェクトを立ち上げるのだ。我々はこの危険性を認識し、人生を犠牲にしてまでも、壊滅的状況を防ごうと戦っているのだ。たとえ物事が期待しているほど速やかに、また簡単には進まないとしても、すでに多くのことを成し遂げてきた。

この状況が、にわかにひっくり返りつつある。現状を短期的に打破するため、Jolla開発者のMunkはlibhybrisを作った。これはandoroidのドライバーをglibcの上で使えるようにする、つまりは通常のLinux環境で使えるようにするためのラッパーライブラリだ。筆者は、このようなハックを極めて危険だと見る。というのも、ベンダーを勝手に満足させ、andoroid方式のバイナリドライバーをデフォルトにする現状を強固なものにしてしまうのだ。我々の最大のモバイルにおけるオープンソースの希望、Sailfish、Firefox-OS、Ubuntu-Phone Mirは、すでにこの方法を採用している。

私はいまだに、JolalやMozilla財団やCanonicalから、我々のオープンなARM GPUドライバーのやり方を採用する気配を感じ取れないでいる。我々はすでに相当の労力をこれにつぎこんでいるのだ。これらの企業は、他の平均的なandoroidベンダーよりはるかに、オープンソースソフトウェアに依存しているし、オープンソースのやり方も知っている。にもかかわらず、andoroid限定のバイナリドライバーに依存するやり方を採用していて、現状を変える気概を一切見せていない。

私はMirよりWaylandを推す理由は、CanonicalがすぐさまMirでlibhybrisを採用する道を選んだからだ。Waylandは、現在のところ、libhybrisに対するパッチが存在していて、Waylandも哀しいことにMirと同じレベルにまで落ちるだろう。グラフィックドライバーの視点としては。

Intelはオープンソースソフトウェア、特にオープンソースグラフィックドライバーに対して小規模な軍隊を雇っている。しかし、Intelはグラフィックドライバーに関しては他の部署も存在し、私はよく把握していないが、おそらくIntelはandoroid用のバイナリ限定のドライバーを出荷しているのではないかと思う。

Canonicalはlibhybrisで満足しているが、現在のところは、将来の製品では、まともなグラフィックドライバーに好意を寄せている。この好意は、今や急激に冷めてしまった。Intelは今や、最後のオープンソースグラフィックドライバーの利用者を、andoroid用のバイナリのみを排他的に使う場所に追い立て、その過程で、OSTCドライバー開発部署の縮小を進めている。

終末

これまでのところ、IntelはWayland対Mirの状況に対しては、倫理的に恥ずかしくない立場をとっていた。Xmirパッチをrevertするという些細な決断により、この状況は大いに後退してしまった。

おめでとう。

[1] 当初、Waylandはネットワーク越しに使うことは想定されていなかった。確か当時のドキュメントには、「モダンなデスクトップ処理は画像を多用するので、ネットワークプロトコルは単に動画ストリーミングに過ぎず、そういうのはディスプレイサーバーの外でやったほうがいい」と書いてあった記憶がある。

[2] 筆者のLuc Verhaegenは、かつてS.u.S.Eで、Radeonを解析して非公式ドライバーを書いていた。まだATIがAMDに買収される前の話だ。

というわけで、状況は悲惨だ。Linuxカーネルは、時代遅れのGPLv2でライセンスされている。GPLv2は、Tivoizationの害悪を防ぐことができない。このままでは、いや、実際にすでにそうなっているのだが、Linux環境で最大規模を占めるAndoroidを動かす実ハードウェアは、邪悪な制限コンピューターだけに成り下がってしまう。

Tivoizationとは何か、なぜTivoizationは邪悪なのか。それを理解する前に、まずソフトウェアの自由について学ばなければならない。

ソフトウェアが自由であるといった時、それは何を意味するのか。自由とは何か。リチャード・ストールマンは、自由について以下のように定義した。

もし、プログラムの利用者が、4つの根本的な自由を有する時、そのプログラムは自由ソフトウェアである。

• プログラムを、いかなる目的にも、実行する自由(自由0)
• プログラムが如何にして動作するのかを調べ、変更し、その結果コンピューターを自分の意のままに動作させる自由(freedom 1)。ソースコードへのアクセスはこの自由への前提条件である。
• 複製物を再配布して、隣人を助ける自由(freedom 2)
• 改変版の複製物を他人に配布する自由(freedom 3)。これを行うことによって、コミュニティ全体が、自分の変更による恩恵を受けることができる。ソースコードへのアクセスはこの自由への前提条件である。

利用者がこれらの自由を有する時、プログラムは自由ソフトウェアである。

What is free software? - GNU Project - Free Software Foundation

自由0は当然である。たとえば、ソフトウェアの提供者がキリスト教徒で、異教徒と異教徒の主張を広げる行動には、自分のソフトウェアは利用してはならないと決めたならば、そのようなソフトウェアは自由ではない。自由1も当然である。ソフトウェアは、利用者の意のままに動かなければならない。そのためには、利用者はソフトウェアを改変できなければならない。自由2と自由3が分かれているのは、そのどちらかの自由しか認めたくないという人間が結構いるからだ。そのため、明確にどちらも自由の定義に含めるために、分けられている。

リチャード・ストールマンの定義では、自由とは、利用者の自由であることに注目して欲しい。提供者の自由ではない。

ある者は言う。「自由というのであれば、俺にはソースコードを公開しない自由があるはずだ」と。それは、プログラムを提供する側の自由である。これは言い換えれば、「ソフトウェア提供者たる俺には、利用者の自由を制限する自由があるはずだ」となる。提供者がそのような自由を行使すると、利用者の自由が制限される。これは典型的な、自分の自由と他人の自由が衝突する例である。

リチャード・ストールマンは、自由とは常に利用者側に存在すべきであると考えた。そこで、リチャード・ストールマンが提唱した「自由ソフトウェア」の定義も、利用者側の自由を優先するものになった。

さて、Tivoizationとは何か。これは、TiVo社がGPLv2でライセンスされたソフトウェアを、自社の邪悪で制限的なハードウェアに搭載した事件から名付けられた言葉だ。日本語にすれば、Tivo化となる。

Tivo社のハードウェアは、GPLv2でライセンスされたソフトウェアを搭載していた。GPLv2に関しては、守られていた。ソースコードは公開されていたし、改変してビルドすることもできた。問題は、実ハードウェアに搭載されたソフトウェアを書き換える方法がなかったことだ。

これは単に、ソフトウェアがROMに記録されていて、書き換えられなかったという話ではない。Tivo社は改変されたソフトウェアが動かないように、妨害する機能を追加していた。そのため、製品の利用者には、実ハードウェアのソフトウェアを改変する自由がなかった。

リチャード・ストールマンは、このような姑息な妨害により、自由が阻害されると判断した。そのため、GPLはTivoizationの害悪を防ぐために改良され、GPLv3が発表された。

今、世に出回っているAndoroidは、そのほぼすべてが、邪悪なTivoizationを行なっている。また、不自由なバイナリブロブのドライバーを搭載している。これは、Linuxカーネルがいまだに時代遅れのTivoizationに対する脆弱性を抱えたままのGPLv2でライセンスされているためである。そのため、 Androidが動作するハードウェアの利用者には、自由がない。

OSが独自のハードウェアを扱うには、その独自ハードウェアの操作方法を隠匿してOSが汎用的に操作できるようにするソフトウェアが必要である。これをドライバーと呼ぶ。Linuxカーネルでは、多くのドライバーがカーネルスペースで実装されている。ドライバーはカーネルに読み込まれ、カーネルの一部として動く。ドライバーが不自由ソフトウェアであると、ハードウェアを自由に扱うことができない。

モバイル（このマーケティング臭い用語は嫌いだが）は、今特にアツい分野である。モバイルコンピューターでも、自由ソフトウェアのみによる環境が構築できるべきである。しかし、残念ながら、既存の邪悪なハードウェアベンダーは、Android用の不自由なバイナリドライバーしか提供していない。

AndroidはLinuxカーネルを利用しているものの、我々がデスクトップで使うGNU/LinuxベースのOSとはだいぶ違う。たとえば、Androidのlibcはglibcではなく、Bionicを利用している。BIonicはglibcに比べて、提供している機能の点で貧弱である。しかもglibcと互換性がない。そのため、バイナリドライバーはLinuxカーネルにglibcを組み合わせたGNU/Linuxでは動かない。

libhybrisというのは、Andoroid用の不自由なバイナリドライバーをGNU/Linuxで利用できるようにするためのラッパーライブラリである。これで醜悪なハナが曲がるほどクサいAndoroid用のバイナリブロブも、一応はGNU/Linuxで使うことができる。ひどく臭うが。

たとえ不自由なバイナリドライバーを使うとしても、大部分が自由ソフトウェアで構成されたOSを提供できる方が、利点も多いかもしれない。不自由極まりないAndroidよりは多少はマシかもしれない。そんなわけで、CanonicalとかMozilla財団とかが、クソみたいなバイナリドライバーに汚染された多少は自由なモバイル用OSを開発している。