リーナス・トーバルズのデスクトップ環境の選択は、常に耳目を集めている。所詮、万人を満足させるUIなんてない以上、好きなものを使えばいいし、主要なディストロは、標準のパッケージ管理コマンド、あるいはGUIから、デスクトップ環境を変えられるようになっている。ただ、リーナス・トーバルズは、何といってもその有名度と、Linuxカーネル第一人者なのにも関わらず、SlackwareやGentooやArchのような何だか名前を聞くだけで怖そうなディストロや、dwmやAwesomeやXmonadのようなド素人お断りのデスクトップ環境を使わず、UbuntuやLinux Mintのようなバカでも使えるディストロにGNOME、KDE、Xfceといった、これまた無難なデスクトップ環境を選択していることで有名だ。

リーナスのハードウェアの選択の点でも変わっており、Appleのクールな薄いデザインのラップトップを愛用している。性能こそ高いがやたらにゴツい弁当箱のようなラップトップではない。

それから、リーナスはどうも、自力で何でも設定できることをあまり重要視していないようで、デフォルトの設定が気に食わなければ容赦なく叩く。まあ、デフォルトの設定は非常に強い力を持つので、分からないでもないのだが、ことカーネル開発者で、いざとなれば自力で何でもできる能力のある人間としては、なかなかおもしろい。もちろん、リーナスは優れたGTK+プログラマーではないし、リーナスがどこかのインタビューで言っていたように「できるからといってやりたいわけじゃない」のだろうが。

Linuxカーネル開発者の中には、「真に重要なのはテキストだ。テキスト以外の情報はゴミだ。Xは、たまに複雑な描画を必要とする失礼極まりないドキュメントを見る必要に迫られた時だけ起動する」という猛者もいるというのに、

Sriram Ramkrishna - Google+ - I don't mind these GNOME forks so much.  But I would ho...

GNOME開発者の一人Sriram Ramkrishnaが、Google+でGNOME2のforkについて語った記事がある。

奴らがGNOMEを頻繁にforkするのはかまわないけどさ。GTK+みたいな内部コンポーネントに依存しているわけだから、労力を少しはGNOMEに割いて貢献して欲しいものだよね。

あと、GNOME 2と同等の機能に達した後、奴らはどうするんだろ。単にそのまま現状維持に務めるのかな。

最後に、新規ユーザーをどうやって引き寄せればいいんだ。タブレットや携帯みたいなタッチインターフェースで育ってきた若いユーザーに、Windows 95みたいな見た目をつきだしてそれでうまくいくのかな。あとラップトップ、特にWindows 8世代の、タッチスクリーン付きのラップトップはどうするんだ。そんなデザインでうまくやっていけるのかな。昔のインターフェースが新しいハードウェア機能で動くのかな。

インターフェースが変わるのは気まぐれじゃない。ハードウェアは日々変わってるんだよ。新機能が必要で、時には、一部の機能は寿命を迎えることもあるんだ。

リーナスがこれにコメントをしている。

じゃあ、何で機能を取り除くんだよ。ハードウェアの性能が変化しているから、新しいハードウェアでは、フォントサイズを変更するような機能は場違いってわけか？

GNOME 2を好む人間は、なにもGUIのデザインがイケてるからってわけじゃない。GNOME 3が機能を取り除いたり、作業を難しくしたから留まりたいんだ。

まず、「シャットダウン/リブート」のエントリーが消えた。David Millerによれば、今や、「ログアウト」のエントリーすら取り除かれたっていうじゃないか。ところで、新しいターミナルを立ち上げるような機能は、GNOME 3の標準機能ではないらしいね。

Sriram Ramkrishna君、君はいつもはそれほど物分かりが悪くないと思うのだけどね。GNOME 3の連中は、そもそもなんでforkを欲しがる奴らがいるのか考えてみたほうがいいんじゃないかい。もちろん、「新しいハードウェアのサポート」とは一切関係のない理由だよ。

Jason Brooksの返事

よくわからないんだけど、その程度の文句なら、デフォルトの拡張をいくつか使うだけでいいんじゃない。メニューとタスクバーはとっくの昔に消えてるし。大きな変更だったけれど、何でか理由はよくわからないね。

まあ、俺はGnome Shellを毎日使っているんだけど、Gnome 2モデルより優れている理由は分からない。

リーナス・トーバルズ、返事

+Jason Brooks: その通りだ。拡張を使えばGNOME 3はもっと使いやすくなる。そういう拡張はある。でも、それはGNOME 3の設計上期待された使い方じゃないし、オプションとして取り入れられることもないだろう。

+Sriram Ramkrishna、いやマジで、「GNOME 3」が嫌われてる訳じゃないんだ。「ウィース、オレわーってるス。わーってるから、いーよーにしてやるから、文句ゆーな」[訳注:ドイツ語なまりか？]

以後は長くなるのでかいつまんで抜き出すと。

この議論は前にもしただろう。リーナス、お前は自力で自分の好みに変更できるだけの能力があるじゃないか。そりゃ問題は常にあるさ。オレは、ショートカットキー設定して、ターミナルはAlt-Tで起動してるよ。ちゃんと動く。Winキーと"ter"を組み合わせてもターミナルを起動できる。デスクトップのショートカットバーを使うのでさらに便利だよ。つまり、デスクトップを自分の好きなようにできる機能は揃ってるんだ。

Sriram Ramkrishna

その手の「設定をいじってショートカットキーを設定しろ」ってのがいい例さ。書くのにはキーボードを使うさ、でもオレはターミナル起動にはアイコンがほしい。

なんで人の好みは違うという事をわかってくれないんだ。なんでオレの不満に、「オレのやり方でやれ」と答えるんだ。GNOME 3の思想の問題だというのに。

リーナス・トーバルズ

リーナスがターミナルエミュレーターのような基本的なソフトウェアですら、キーボードショートカットではなく、ターミナル起動のためのアイコンが欲しいというのは興味深い。カーネル開発者のステレオタイプなイメージと合わない。

そして一番興味深いのは、リーナスは今、GNOME 3を使っていると発言したことだ。

GNOME 3は改良されてる。不満はたくさんある。拡張は物事を悪くすることもある。GNOMEの連中はそれほど物分かりが悪いというわけでもないと思う。何にせよ、いい拡張があるから、俺は今、GNOME 3に戻っている。

Frippery + gnome-tweak-toolでだいぶ変わる。なんでGNOME 3の連中は取り込まないんだろう。

Israel introduces 'Palestinian only' bus lines, following complaints from Jewish settlers Israel News | Haaretz Daily Newspaper

イスラエルがとうとう、パレスチナ人専用バスを走らせるらしい。人種分離政策は着々と進んでいるようだ。

ところで、日本でも女性分離政策が進んでいる。最近では、女性専用道路を設けるべきだという意見も出てきた。たぶん儒教が復活したのだろうと思う。男女道を同じくせず。

xkcd: PGP

PGPを使ってメールが本人のものであると検証する方法

先頭のこの文字列を探す。

-----BEGIN PGP SIGNED MESSAGE-----

もしあれば、そのメールはかなりの確率で正しい。

PGP検証機能付きのメールクライアントを使っている人が少ないことのあてつけだろうか。

[Phoronix] Ubuntu Announces Mir, A X.Org/Wayland Replacement

Ubuntuが、従来のX.orgに変えて、公式に移行すると宣言されていたWaylandでも、あるいはかねてから噂されていたSurfaceFlinger(Android用のディスプレイサーバー)でもなく、独自に開発したディスプレイサーバーであるMirを使うことが明らかになった。その規格が公開されている。

MirSpec - Ubuntu Wiki

動機は、やはり多様なハードウェアに対応するためだという。特に、XのInputモデルが複雑で現代の多用な入力デバイスに対応できないとしている。タッチインターフェースに対応したいのだろう。また、セキュリティとしても、AppArmorのような外付けの機能に頼らず、最初からディスプレイサーバー側で必要最小限の権限しか与えないような作りにするという。

また、Xのグラフィックドライバーモデルは問題が多いとして、最近何かと流行りのOpenGL ESに迎合し、またドライバーへの依存も少なくし、既存のAndroid用ドライバーやハードウェアコンポジターを利用できるつくりになるとしている。

なぜWayland/Westonではないのか。入力イベントの扱いが、部分的にXに影響された作りになっており、おそらくXと同じ問題が発生するだろうということ。プロトコルのシェル統合の部分は必要以上に高い権限を要求する。Ubuntuの考えでは、ディスプレイサーバーのプロトコルにシェルを関わらせたくないそうだ。

ただし、Waylandの経験が完全に無になるというわけでもなく、一部のWaylandとして設計されてきたプロトコルについては、よく設計され十分に検証されているとして採用するそうだ。

また、既存の主要なツールキットであるQt/QML, GTK3, XUL等は、ツールキット側で対応するので、既存のソフトウェアに追加の対応は必要ないという。

Qt/QMLを一番最初に挙げているのは興味深いと読み進めたら、プロジェクトの一部として、Qt BindingであるQMirを開発するとわざわざ書いてある。推奨のツールキットはQtになるのだろう。

現在のMirのAndroid実装は、描画にSurfaceFingerを挟んでいるが、じきにSurfaceFingerに頼らず自力で描画するようになるのだという。

また、デスクトップでは、自由なグラフィックドライバースタックであるGBM(Graphical Buffer Manager)、KMS(Kernel Mode Setting)、DRM(Direct Rendering Manager)の上に動作するそうだ。

現在のところ、Mirは不自由なドライバーの上では動作しないが、これについてGPUベンダー各社と協議中らしい。なんでも、共通のEGLベースのドライバーモデルを開発して、ディスプレイサーバーの開発を容易にするのだとか。

ロードマップとしては、5月にMirとUnity Nextの開発を、シュルが実装可能なところまで進め、実験できるようにする。同年10月にはUnity NextとMirとシステムの統合を終え、Ubuntu Phoneで利用できるようにする。デスクトップやラップトップ向けには、Xを完全に置き換え、レガシーモードとして、必要に応じて既存のXクライアントを動かすため、root権限なしで動くXサーバーを起動する。

また、Mirスペックでは断片的にしか触れていないが、Unity Nextというのも気になるところだ。どうやらこれはUnityの新しい実装らしく、Qt/QMLで実装されるようだ。

C++に馴染みのあるものとしては、最初からC++ネイティブなQtになるのはいいことだといえる。

しかしまあ、あれだけGTK+にこだわって、QtはUnity 2Dを実装するときにしか使っていなかったCanonicalが、急にQtに移行するのはなかなか大転身といえるのではないか。

Unity NextがQtを使うことは、Phoronixでも取り上げられているので、面白いコメントが期待できそうだ。

[Phoronix] Ubuntu's Unity Written In Qt/QML For "Unity Next"

Canonicalがまったく新しいディスプレイサーバーであるMirを秘密裏に開発していたことは、衝撃を持って受け止められた。すでに、XやWayland開発者による非難の声が上がっている。Phoronixがまとめているので紹介する。

[Phoronix] Upstream X/Wayland Developers Bash Canonical, Mir

Wayland/Westonの作者であるKristian HøgsbergはGoogle+上で、「またいつものことさ」と書いている。MirSpecにある、Waylandの入力モデルが複雑すぎて非現実的だという批判には、Waylandではすでに実装済みで動くものが存在するとバッサリ。

また、長年のX.orgへの貢献者であるDaniel StoneがPhoronixのフォーラムによせたコメントによれば、やはり入力モデルの批判は見当違いで、Canonicalのやり方ではまともに動かないとしている。また、Waylandの将来性については全く問題ない。問題はむしろ、またもや新たな規格が出てきたことで、ツールキットやらドライバーやらハードウェアやらへの対応の負担が増すことだとしている。

Red Hatの開発者であるLennart Poetteringは、「Mirには輝かしい将来が横たわっていると言えるね。bazaarやUpstartやProject Harmonyのようなさ」と皮肉る。

bazaarはCanonicalによって開発されたバージョン管理システムで、主にCanonicalのlaunchpadだけで使用されている。UpstartはCanonicalによって開発された新しい初期化デーモンで、sysvinitとの互換性を保ちつつ改良されている。これは主にUbuntuと・・・、こちらは一応、Ubuntu以外でも使われている。もっとも、Systemdの方が主流だが。Project Harmonyは貢献の際のライセンスなのだが、失敗というか、まああまりいい評判は聞かない。

Red Hat所属で長年X.orgとMesaに貢献してきたDavid Airlieは、「次のUbuntuのリリースはJumping Sharksと呼ぶべきだね。奴らにディスプレイサーバーを開発出来るだけの力はないだろう。Waylandに見当違いの批判をしているのがその証拠さ」とコメント。

等など、いずれもCanonicalのWaylandへの技術上の批判は完全に間違っていると切り捨てている。

Canonicalが全く新しいディスプレイサーバーであるMirを発表した。Mirは去年からかれこれ9ヶ月ほど秘密裏に開発されてきたらしい。当然沸き起こる疑問がある。一体誰が開発しているんだ。

Canonicalは、これまでX.orgやMESAやWaylandやグラフィックドライバーにはそれほど貢献してこなかった。つまり、Canonicalには十分な知識を持った人材がそれほどいないはずなのだ。

[Phoronix] The Developers Behind The Mir Display Server

Phoronixが、このたびCanonicalが公開したMirのBazaarレポジトリから、コミットの名前をカウントして、主要な開発者を洗い出している。

元Compizの開発者や、X.org/MESAのメンテナー、GNOMEコンポーネントやUnityなどの開発者の名前が挙がっている。Phoronixの意見では、多少は知識がある者たちだが、いずれも既存のX.orgやMESAなどの多大な貢献者というわけではないし、やはり不十分だとしている。

人材もさることながら、時間が圧倒的に足りない。計画では、2014年の4月のUbuntu 14.04にはリリースできるようになっているはずなのだ。これまでX11の開発者達が長年かけてWaylandを設計、開発して、いまだにWaylandは実用とは程遠いのに、いったいどうやって間に合わせるのか。

[Phoronix] Building & Running The Ubuntu Mir Display Server

さらに、Phoronixは公開されたレポジトリから、Mirを試みている。

Mir自体はC++で実装されており、Boostライブラリが使われている。

レポジトリ自体は去年の6月に作成されており、これまでのところ461件のコミットがある。

現在のところ、公開されているうちの全ソースコード（cmakeなどのファイルも含めて）は、たったの14661行である。

現在のMirは、自由なグラフィックドライバースタック上のみで動く。つまりIntelか、AMDの有志開発の自由なドライバーでしか動かない。Nouveauでは動かないそうだ。AMDやnVidiaとは協議するといっているが、もしすでに秘密裏に協議して対応の約束を取り付けていたとしても、やはり対応には相応の時間がかかるだろうし、一体どうするつもりなのか。

やるべきことが多すぎる。現時点では、Mirはシェルを動かせるレベルに達していない。今公開されているMirのデモは、動作にX.orgを必要とし、単に画像をスクロール表示させる文字通りのデモにとどまっている。

Canonicalは、まだ何かとんでもないサプライズを隠しているのだろうか。

Linus Torvalds - Google+ - Toys, toys, toys.. Hey, I've joined all the cool kids in…

リーナス・トーバルズが、Chromebook Pixelを気に入ったそうだ。メインのラップトップはこれにしたいとまで言っている。するとは言っていないが、えらい気に入りようだ。

まあ、これは驚く話でもない。Chromebook Pixelはハードウェア的にはなかなか悪くないからだ。Chrome OSが余計だが、そんなものは消せば良い。SSDの容量が少なすぎるのが難点だが、交換できるのだろうか。

本の虫: Chromebook Pixelがなかなか興味深い

先月にも紹介したように、興味深いのはディスプレイだ。239PPIでアスペクト比が3:2のディスプレイとなっている。「Retinaとかいうクソな名前で呼ぶな、まともな解像度と呼べ」と言っていたリーナスならば気に入るのも道理だろう。

よう、オレっちイケてるしヤバいし、最新のGoogle "Pixel" ラップトップ、ま、よーするにChromebooksぐらい持っててトーゼンじゃん。マジマジ、これ画面キレーだし、マジこれオレのメインのラップトップにしてもいーくらいだし、いやマジで。オレ、ラップトップはもうちっとばかしちっこいのがいいんだけど、まあ、この1.5kgのバケモノなら許容範囲かなっていうかラップトップはやっぱ1kg以下に限ると思ってるんだけどさ。

でもマジ画面きれいすぎんだよね、これたまんねー。

ピクセル数だけじゃねーんだよ。オレ、こないだまでワイドスクリーンはあんまり気に入ってなかったけど、この3:2を見ろよベイベー。

いやマジマジ、なんで「ブラックバー」がどうのこうのいう奴らがいるのかわっかんねーな。「ピクセルが存在しない」ってのと何が違うんだ。アホみてーなワイドスクリーンってみんなそうじゃん。

んで、おれまだChromeOSを動かしてるんだ。まあ、メールの読み書きぐらいには使えるかな。まあ、すぐにモノホンのディストロを入れっけどね。やっぱマジにラップトップ使うこと考えたら、メールの読み書きだけじゃちょっとなー、やっぱコンパイルしたいし、gitレポジトリも持っときたいしー。

ところでさ、オレっちNexus 10も持ってんだよね。こいつもピクセル多め、でも使い道はなさそうだな。そりゃ、Webブラウザぐらい走らせられるし、テキスト小さくもできるけどさ、キーボードなしじゃなにも書けやしねーし、フルLinuxディストロいれられないんじゃ、オレのラップトップの代わりにはなんねーな。青歯のキーボード使うってのもダッセーしな。

Chromebook Pixelゲットして思ったんだけどさ、いわゆる今のフツーのラップトップってクソすぎんだよな。なんでPCメーカーはなにもしねーんだよ。PC業界がうまくいってねーのもトーゼンだな、うん、クソをひりだして、ジャジャーン、「フルHDでーす、1080pでーす」なんてやって売れると思ってんだからさ。

リーナスさんマジ若い。

[Phoronix] Ubuntu 13.04 Will Be Released, Rolling Fate Unknown

Canonicalが雇用している開発者の間で、Ubuntuをローリングリリースモデルに移行すべきだという声が高まっているが、4月にリリースされる予定のUbuntu 13.04は、予定通りリリースされるそうだ。

[Phoronix] Ubuntu Plans To Move To Systemd's Logind

Ubuntuがログインユーザーの管理を、ConsoleKitからSystemdのLogindに移行する計画を立てている。ConsoleKitはもはや保守されなくなるためだ。

GNU/Linuxにおける初期化デーモンとして今一番使われているのはSystemdだが、Ubuntuは初期化デーモンとして、自前のUpstartを利用している。LogindはそのSystemdの一部であり、Systemdに依存している。ただし、それほど深く依存しているわけではないので、Upstartを使いながらLogindを使うようにするのは、それほど難しい作業ではないそうだ。

最近はSystemdにudevも統合されて、Systemdの天下かと思われていたら、GentooがudevのSystemd統合に反発してudevをforkするなどと、まあ、自由ソフトウェアの業界はひとつにまとまることがない。

中島敦の草稿を読んでいるのだが、だいぶ変わっている。

例えば名人傳だ。完成版は青空文庫にあるが、草稿のテキストは、現在インターネット上には存在しない。

まず、「述而不作と孔夫子は言ふ。私もその顰みに倣はうと思ふ。創意無しとの批難は甘んじて受けよう。た々゛、この話の真実なことだけは信じて頂きたい。」と始まる。

草稿では、紀昌は最初から弓の名手で、百歩を隔てて柳の葉を射切ることができる。その腕前を披露しているところに、飛衛がやってきて嘲笑する。勝負の結果負けた紀昌は弟子入りし、そこから先は修行が始まる。

冒頭の話がだいぶ変わっている。

文字禍も、草稿は文字という題名で、直接博士と関係ない話が多数書いてある。

草稿を読んでみると、中島敦は同じ作品を何度も書きなおして整えていったのだという感じがする。

まあ、世の中には某エスペラント狂の遺稿のように、何度も書きなおした挙句、元の話がすっかり消えてしまい、しかし完全に消えもせずところどころに違和感のある記述が残る矛盾だらけの作品もあるのだが。私にはあの田舎者の文章の良さは理解できない。

Mark Shuttleworth » Blog Archive » Not convinced by rolling releases

Mark Shuttleworthが自分のブログで、Ubuntuのローリングリリース化への要望や、Ubuntuの独自実装の傾向について、コメントを出している。

ローリングリリースにはときめかない。

Ubuntuの「ローリングリリース」化の噂が盛んだ。ユーザーコミュニティから一番よく挙げられる要望でもある。また、Canonicalの開発者（多くはコミュニティ出身であり、コミュニティの思想を受け継いでいる）の間でも強い要望がある。

私にとっての問題は単純だ。ローリングリリースは、そもそもリリースなんかじゃないという事だ。確実なものが欲しいユーザーに、その肝心な確実性を提供できない。それに、日々の開発リリースで、需要は満たせているはずだ。開発リリースは、Canonicalとコミュニティによるリリースサイクルを経た日々の品質テストにより、（開発者にとっては）非常に使いやすい。

そういうわけで、私はこれまで、ローリングリリースについては興味がなかった。

今年、この議題がまた浮上し、その要望の強さから、Canonicalの開発チームは、実際のところを調査して、利点と欠点を洗い出し、議論のたたき台を提供できるようにした。Rickは先週、そのたたき台を提出した。明らかだが、Rickはこの意見に強く賛成の立場であり、だからこそこういう話が出てきたのだが、彼一人の意見で物事が決まるわけではない。

Rickの立場をもってUbuntuの最終的な立場とするのはあたらない。Technical Boardは賛成していないし、Community Councilもまだ立場を決めかねているし、私も賛成していない。そういうわけで、浮き足立った者たちは、少し落ち着いて、議論に参加すべきだ。

意外な発見

Rickのチームの調査により、いくつかの興味深く、（私にとって）意外な発見が明らかになった。

一つ目に、定期リリースに混乱がある。現在の方法では、12.04 LTSと14.04 LTSの間には、3つの定期リリースがある。これに混乱する人が多い。ISV[訳注: Independent Software Vendor、Canonicalと協力関係にあるソフトウェアベンダーのこと]は、quantelとraringとssなんちゃら[訳注：Ubuntu 13.10のコードネームは規則通りならばSから始まる]対応を目指すべきなのか？　データを元にして言えば、彼らは出来ないし、実際やらない。PPAは定期リリースごとに不整合である。これをもって考えれば、最先端リリース一本（PPAは豊富なソフトウェア環境でビルドできる）と、複数のLTSリリースならば、コミュニティの分断に対処しやすいのではないか。

二つ目に、LTS定点リリースで新しいハードウェアと新しいソフトウェアへ対応するという仕組みは、うまく行く事が証明された。例えば、クラウドアーカイブは最新のOpenStackのリリースを12.04 LTSに対応させ、現在のところ、OpenStackを利用する最も人気の方法である。定点リリースは新しいカーネルと新しいOpenStackと新しいUnityを12.04 LTSに導入した。我々がこの動きを加速させない理由はない。stableリリースにこだわる人間にとって良いかどうかは議論すべきところだ。

3つ目に、日々の品質テストはすばらしい。品質チームによるすばらしい仕事は、Ubuntuに多大な期待と貢献をもたらした。raringは今すぐ利用可能だし、何か変なことが起こる危険性は非常に少ない。raringを使っている開発者は増え続けているし、結果としてUbuntuを押し上げている。もちろん、エンドユーザーが使えるほどの品質ではないが、どうしたらそのレベルの品質にできるのか考える価値はある。

raringとは今年の4月にリリースされる予定のUbuntu 13.04のコードネームであり、この文脈では、もっか開発中のUbuntuを指す。Ubuntuの開発版を日々の作業に使うことは可能であり、Ubuntuの開発者の中には実際に使っている者もいる。開発版はソフトウェアのパッケージが頻繁にアップデートされるので、いわばローリングリリースにだいぶ近い状態にある。ただし、その品質や安定性は、広くエンドユーザーが使えるレベルではない。そのため、通常のユーザーは、開発版のUbuntuは使わず、来月まで待つべきである。さらに安定を求めるユーザーは、二年ごとにリリースされるLTSリリースのみを使うべきである。それはさておき。

非現実的な期待

議論の中で、非現実的な期待の声も目にした。

例えば、Ben Collinsの、PowerPC OEMの必要性についてだ。Benは友人であり昔の同僚であるから、私としても賛同したいのだが、アーキテクチャーのサポートは、Ubuntuの非商業活動としては不向きだ。昔、IBMとCanonicalは、UbuntuをPowerPCアーキテクチャーに提供することも議論したが、山積みの課題は独りCanonicalのみで解決できるものではなかった。UbuntuがBenにとって使いやすければ私としても嬉しいのだが、いや、実際彼の仕事として最高のプラットフォームであることは確実であるが、このことに何百万ドルも金を費やすよりも、クラウドコンピューティングとかモバイルに費やしたほうがいい。そっちのほうが社会とコミュニティや、我々の商業活動に対する影響も大きい

根拠のない妄想

天地が崩墜することなんてないよ

いやマジで。

Ubuntuは共通の目的を持つ有志の集まりである。その目的を達成するのは、我々の役目であり、皆が意見を持ち、貢献できる。Canonicalの貢献は多大だ。Canonicalが他の誰よりも「我を通す」なんてのはナンセンスだ。実際、私の要望は半分も通っていない。そうはいかないのだ。多くの人が各々の能力の限りを尽くした結果がUbuntuだ。

Canonicalとコミュニティの共同作業こそがこのすばらしい傑作を作れるのだ。世の中には多くの純粋なコミュニティだけで成り立っているディストロもある。まあみてみなよ。彼らはやたらと内部の政治闘争や不満や買収や失望に満ちあふれている。何故か？　人は人で、作業は難しく、協力作業はもっと難しいからだ。これはCanonicalに限った話ではなく、人生のあらゆることに言える。実際、私が知り、また参加したほとんどの純粋なコミュニティプロジェクトにおける一番の関心ごとは、「ああ、誰か厄介事を片付けてくれる奴がいたらなぁ」というものだ。UbuntuにはCanonicalという奴いる。我々の協力作業により、Linuxファンの仲で最も人気のプラットフォームにしているのだ。

Ubuntuに愛想が尽きたなら、去ればいい。それは普通のことだ。なにか別のことをしたいからといって、昔の井戸に毒を投げ込む必要はない。

我々が統合から指南に軸を移したのもこのためだ。

我々はその初め、最高のオープンソースの調べを提供したいと宣言した。見た目を決定するのはKDEやGNOMEやXFCEの役目であり、我々は単に統合して提供した（これも難しい問題ではある）。2009年になって、私はとうとう、既存の自由ソフトウェアコミュニティの中に、今のプロプライエタリな指導者に挑戦できる見た目を提供できるものはいないと分かった。そこで、我々が本気で自由ソフトウェアが標準となる夢を実現しようとすれば、我々が指南しなければならないのだ。

その結果がUnityだ。UnityはケータイやタブレットやPCやその他のデバイスに広く受け入れられる見た目だ。もちろん、これは破壊的な変更であり、既存のコミュニティの一部のメンバーは拒絶した。思うに、人ごとに好みは違うのだろう。そこで、我々は、無制限ではないにせよ、多大な労力を注いで、KDEやGNOMEやその他のデスクトップ環境をUbuntu傘下で提供している。また、我々はUnityとその他のデスクトップ環境を両方サポートしたい開発者も引き入れている。しかし、我々が単なる物好きのためのプラットフォーム以上の存在になるためには、我々はUnityに注力して、AndroidやChromeやWindowsやAppleと戦っていかなければならない。これは我々の自由ソフトウェア標準の夢を共有しない連中の需要を満たすよりも重要なことだ。

人生一度きりの機会

オープンソース界で一目おく人間は皆、ひとつの夢を抱いている。例外なく、自由ソフトウェアが標準になってほしいのだ。Ubuntuはその夢を実現できる唯一の方法であり、だからこそ私は人生を捧げており、大勢の人たちが多大な時間を割いているのだ。

私は変人になりたいと願う烏合の衆には何の関心も持たない。オタク御用達。「Linuxはバカ避けのために難解であるべきだ」とか宣うのは、頭のいい連中のたわ言だ。人は人であり、そういう価値観の頭のいい連中もいるということだ。

私の関心は、消費者とエンタープライズコンピューティングの指南車である、自由にしてオープンなプラットフォームを作れる、この人生一度きりの機会だ。

Ubuntu(とUnity)によって、我々にはその機会がある。これはすばらしいことだ。考えてもみたまえ、史上初めて、自由ソフトウェアプラットフォームが、モバイルやクラウドといった分野で、実際に革新的な指導力を発揮していると評価されているのだ。これに君の時間とエネルギーを注ぐのは、真に世界に影響を与えるのだ。まさに参加すべし。オタクな連中の中を見回し、袖をめくって、改良に興味のあるものを探し、参加しろ。己の能力向上だけでなく、自分の欲しいものが手に入るのだ。理想だけで物事が勝手についてくると考えているのなら、一生実現しない。

我々がさらに開発を進め、そして共同開発したならば、Ubuntuはケータイ、タブレット、PCに大きく広がったプラットフォームとなる。何百万人もの人々に日々使われるツールを設計し、開発し、修正する満足感を得られる。実に価値のあることだ。一体どうやって目的を達成するのが一番かと常に問いかける我々の手法に注目すべきだ。この手法により、定期リリースは評価と進化のための目的なのだ。

さらに早く

つまり、ローリングリリースは真のリリースではないわけだ。

しかし、定期リリースは悪くない。リリースは難しいとはいえ、己を律する良き主人だ。リーンソフトウェア開発における決まりがある。何かが難しければ、より頻繁にやれ。そうすることにより、労力を難しい問題に集中させ、上達させ、簡単にするからだ。アジャイル開発やdevopsやjujuなどの根底に流れる思想がこれだ。

Webが主流となる世界では、ソフトウェアの成長速度は過去最高になっている。6ヶ月は十分に早いと言えるだろうか？

だから、こう問うてみてはどうか。もっと早く出来ないか？　年にもっと多くリリースできないか？　そのプロセスを自動化して、エンドユーザーにも使えるように出来ないか？

これが、ローリングリリースにおける議論の前提となるべきだ。

• 定点間のアップデートのプロセスをもっと安定させられないか？　今アップデートするのは可能である、しかし、多数のアップグレードを経てシステムをクリーンに保つのは、APTのスキルが必要になる。
• LTSにおける定点リリースをもっと強くして、定期リリースをもう少し軽く出来ないか？
• リリースの管理を、例えば月例にして、しかもスナップショットではなく本物のリリースに出来ないか？

日々の品質テストにより、Ubuntuの開発版リリースは、開発者にとっては利用可能になっている。これは重要な達成といえる。さて、エンドユーザーにした約束をよく考え、さらなる革新が行えないか考えてみよう。我々がその昔、Ubuntuを6ヶ月定期リリースにしたことで革新を起こしたように。

まあ、Mark Shuttleworthはなかなかの理屈家だとは言える。

まあ、UnityをもってUbuntuを批判するのはどうかと思う。Ubuntuは公式レポジトリで主要なデスクトップ環境を提供していて、標準のパッケージマネージャーを使って一発でインストール、アンインストールが可能だからだ。気にいらないなら変えればいいだけの話だ。それに、いざとなれば手動で変えるという手もある。手動によるデスクトップ環境の変更を妨げる邪悪な制限もないわけだ。どこぞの不自由なOSは、デスクトップ環境を変更したければ、非公式なバイナリパッチをあてて無理やり書き換えるしかないらしい。哀れみすら覚える。

ただし、Mirは少し疑問だ。はたして、Canonicalにディスプレイサーバーを独自実装するだけの力があるのだろうか。しかも、あれだけWaylandを持ち上げておいて、いきなり手のひらを返してMirを発表したというのも解せない。

Google and MPEG LA Announce Agreement Covering VP8 Video Format | Business Wire

GoogleがVP8を発表してより、H.264の特許管理団体であるMPEG LAは忙しく対VP8用パテントプールを構築すると宣言した。x264の開発者の言によれば、VP8は明らかにH.264と似通った部分もあるので、おそらくMPEG lAが管理する中で抵触する特許もあるだろいうとのことであった。

Googleの戦略としては、「こちらもVP8のパテントプールを保有している。もし誰か、VP8に特許侵害を申し立てる者がいれば、こちらのパテントプールを使って反撃する」というものだった。

特許戦争は、もはや戦略核の様相を呈しており、お互いにパテントプールと称する大量の特許群を保有して、もし特許侵害を申し立てられたならば、こちらの保有する特許の中で、相手が侵害しているものを探しだして、逆提訴するという戦略が取られている。結果として、大抵の特許紛争はやたらと結論を引き伸ばした挙句、最後は和解で終わることが多い。実に労力の無駄であると言える。そのパテントプールを構築する特許も、たいていはクズ特許の塊であり、いざ裁判となればどんどんその有効性が否定されたり、解釈の結果抵触していなかったようなものばかりであるが、まあ、おどしの料にはなるだろう。

この戦略は、実際には特許を使って商売していない特許ゴロには通用しないが、その手の特許ゴロが使う特許は、たいていクズ特許なので、まあだらだらと裁判を続けることになる。

実に、昔も今も特許は技術革新を阻害している害悪であるが、まあ人間のやることは理解しがたい。

そして、今回のプレスリリースだ。興味深い不思議な表現が並ぶ。

Google Inc. and MPEG LA, LLC announced today that they have entered into agreements granting Google a license to techniques that may be essential to VP8 and earlier-generation VPx video compression technologies under patents owned by 11 patent holders.

"may be essential"(抵触しているかもしれない)とはなかなか興味深い表現だ。MPEG LAが実際に対VP8に使える特許の洗い出しが出来なかったのか、あるいはGoogleの面を立てるべく、Googleの営業部門がそういう表現を使うよう要求したのか。

ともかく、Googleとしては、MPEG LAの特許に抵触しているかもしれない技術を、他者にライセンス提供することが可能になった。これは、Google以外のVP8の実装も含むそうで、つまりはffmpegのようなソフトウェアによるVP8のエンコーダー、デコーダーの実装に特許上の懸念がなくなったということでもある。

また、次の表現も興味深い。

It further provides for sublicensing those VP8 techniques in one next-generation VPx video codec.

VP8のひとつ次の技術も、この同意に含まれるのだそうだ。まあ、しばらく先の話だろうが。

プレスリリースでは、Google側の結果についてのみ言及しており、MPEG LAが見返りに何を得たのかということを一切明らかにしていない。まあ、私の無責任な推測では、はした金が動いたのではないかと思うが。

[Updated] Mir – An outpost envisioned as a new home | tvoss@work

CanonicalのMir開発者であるThomas Voßのブログに、興味深い追記がある

中身は、Ubuntu Specで語られている内容と同じなのだが、特に興味深いのは

[Updated] More to this, we are working together with NVIDIA towards a more unified driver model sitting on top of EGL.

[追記] さらに、我々はnVidiaと協力してEGLを土台としたより統一されたドライバーモデルの構築をしている。

EGLは、OpenGLの下の低レベルインターフェースの規格で、WaylandもEGLを土台に実装されている。もし、nVidiaの邪悪でプロプライエタリなバイナリブロブが、Mir対応のためにEGLを実装したとすると、それはつまりWaylandにも対応することになる。ちゃんと実装していればだが。

AMDは非公式の自由なドライバーで対応しているし、Intelは公式の自由なドライバーで対応しているので、nVidiaが対応すれば、とりあえずはPCで主要なGPUは対応したと言えるのではないか。

TOM-Skype Research

TOM-Skypeの解析結果による、監視検閲の単語リストが公開されている。

不自由ソフトウェアであるSkypeは、特に邪悪なことで知られている。Skypeの利用は自分だけではなく他人にも不自由ソフトウェアの利用を強いる。それだけでなく、政府の要求により監視と検閲も行なっている。

Microsoftは中国にSkypeを提供し、中国はTOM-Skypeとして知られている特別版を開発して自国民に配布している。その意図は、中国人民の監視と検閲である。

単語リストは最初から入っているものと、別途ダウンロードされるものがあるが、それを解析した結果が公開されている。

六四（天安門事件）とかいった単語まで検閲されている。ちなみに、Pythonのあるバージョンは64という文字列を含むため、中国のグレートファイヤーウォールに引っかかってダウンロードできず、特別に対処されたものが提供されている。

読者はこのような邪悪なSkypeを利用してはならない。

Force companies to change language from "buying" to "licensing" when dealing with DRM-restricted goods. | We the People: Your Voice in Our Government

ホワイトハウスの署名サイトで、興味深い署名が始まっている。現在、多くの電子媒体がデジタル制限管理により、利用者の権利を、従来の"buying"や"purchasing"による所有権の譲渡とは異なり、不当に制限している。このような媒体に対して、「購入」という言葉を用いるのは虚偽である。そのため、「ライセンス」（許諾契約）という言葉を使うようにしろ。これに従えば、「今すぐ購入！」ボタンのごときは、「今すぐライセンス！」ボタンに変更される。

これは実に理にかなった要求だと言える。多くの電子媒体の販売は、譲渡されていない。ライセンスされている。理不尽な契約により、本来、著作権や特許権などの法律で保護される範囲や、著作権法には著作権が及ばないと規定されている制限を無視し、利用者の権利を法的根拠無く不当に制限しているのだ。日本ではライセンスという言葉をどう訳したものか曖昧だが、許諾契約とでもしておこうか。

テンプレートのstaticデータメンバーの明示的特殊化の宣言は、初期化子がない限り宣言にすぎない。また、デフォルト初期化する場合は、文法上の理由により、braced-init-listを使わなければならない。

template < typename T >
struct X
{
    static int data ;
} ;

// 宣言、定義ではない
template < >
int X<int>::data ; 

// エラー、関数int ()の宣言
template < >
int X<int>::data () ;

// 定義
template < >
int X<int>::data { } ;

今まで何故知らなかったのかと疑問に思ったが、そもそも、staticデータメンバーの明示的特殊化なんて使った覚えがない。使った覚えがない以上、知らないのも当然だ。

それにしても、braced-init-listのないC++03では、さぞやstaticデータメンバーの明示的特殊化のデフォルト初期化が面倒だったことだろう。いや、そもそもまず使われないか。

と、こんな些細なことまで解説しているC++の参考書。今年は何としても完成させなければ。

完全に間違った記事跡地。

声優の納谷悟朗が亡くなったそうだ。

ルパン三世の銭形警部の声優で有名だが、他にも、風の谷のナウシカのユパの声優でもあるそうだ。

納谷悟朗 - Wikipedia

Usage Statistics of Flash for Websites, March 2013

w3techs.com調べによれば、WebサイトのFlash利用率が、とうとう20%にまで下がったそうだ。

調査方法はWeb Technologies Statistics and Trendsに書かれている。それによれば、

上位100万件のWebサイトを毎日調査。ランキングはAlexaより取得。Webサイトを構成するページひとつに、特定の技術が使われていれば、Webサイト全体が特定の技術を使っているとみなす。サブドメインを別のWebサイトとして扱わない。リダイレクトされるドメインはカウントしない。ここで定義するWebサイトは、Alexaの定義するWebサイトとは異なるため、実際に集計されるWebサイトの数は、100万件よりすこし少ない。

この調査結果では、一年前に比べてWebサイトのFlash利用率が5%も下がったそうだ。

Flashが死につつあるのはいいことだ。

[Phoronix] Intel Comes Up With A Linux Graphics Driver Installer

Phoronix.comで、IntelがGNU/Linux用のグラフィックドライバーのインストーラーを公開したことを記事にしている。せっかくなので、この機会に、GNU/Linuxでは、自由であれ、不自由であれ、グラフィックドライバーを手動でインストールすることがいかに難しいかということについて、書いてみよう。

普通の不自由なWindowsユーザーのゲーマーならば、グラフィックドライバーは常に最新版を入れておくのが当然だ。また、最低でも年に一度はグラボを交換するのも常識だ。ゲーマーとはそういう人種だ。その際、グラフィックドライバーが自力で導入できない者はいない。今のところ、まともなゲーマーのグラボの選択肢は二つしかない。nVidia製かAMD製かだ。nVidiaもAMDも、公式サイトで最新の不自由なグラフィックドライバーのインストーラーを配布しており、単に落として実行するだけでインストールが完了する。それだけのことだ。

インストーラーは何をやっているのか。基本的には、不自由なドライバーの実装であるプログラムとしてのバイナリブロブを然るべき場所に配置して、システムがそのバイナリブロブをドライバーとして認識するよう、システムの設定を書き換える。それだけだ。GNU/Linuxでも基本は同じだ。ドライバーは最終的にバイナリになり、必要に応じて使われるべく、設定される。

不自由なソフトウェアが蔓延しているWindows環境では、バイナリ互換は絶対だ。Microsoftは不毛なまでの労力をかけて、バイナリ互換を壊さないようにしている。たとえある挙動が好ましからぬとしても、不具合であるとしても、その挙動に依存して、たまたま問題なく動いてしまっているソフトウェアがあるならば、Windowsはその挙動を簡単に変更できない。もし変更したならば、今までたまたま問題なく動いていたソフトウェアが動かなくなる。たとえそれが、カーネル空間に読み込まれるドライバーであってもだ。実に、不自由なソフトウェアの信奉者は無駄な苦労をしていると言える。

Linuxカーネルでも、バイナリ互換は重視されている。ただし、ユーザーランドの話だ。カーネルの変更でユーザーランドのソフトウェアの挙動が悪い方向に変わってしまったとしたならば、それはカーネルの不具合だ。ただし、カーネル自体は話が別だ。カーネルはカーネルだ。Linuxカーネルのソースコードは自由なのが当然なのだから、カーネル内のバイナリ互換など考慮する必要がない。なぜならば、カーネルはコンパイルして使うものだからだ。

さて、不自由ソフトウェアの非常識をLinuxカーネルに持ち込むと、非常に困ったことになる。もちろん、基本的にはそう変わることがない。したがって、グラフィックドライバーの実装をプロプライエタリなバイナリブロブとして提供することも可能だ。ただし、それは自己完結する部分だけであり、Linuxカーネル側の特定のデータ構造を操作したり、関数を呼び出したりしたい場合、問題になる。そのためにはデータ構造や関数へのアドレスを指すシンボルが必要になる。このアドレスはカーネルごとに異なる。シンボルを得るためには、ユーザーの環境のLinuxカーネルのヘッダーを使ってプログラムをコンパイルしなければならない。あらかじめコンパイル済みのバイナリだけでは、このシンボルが得られない。

では邪悪な不自由ソフトウェアの信奉者であり、何としてもソースコードを公開したくないnVidiaやAMDはどうやってプロプライエタリなバイナリブロブのグラフィックドライバーを提供しているのか。彼らは、シンボルを取得する部分だけ、ソースコードを公開し、ユーザーの環境でコンパイルする。不自由なバイナリブロブは、そのコンパイルされたバイナリを経由して、Linuxカーネルの必要なシンボルにアクセスする。

ユーザーの環境でコンパイル。これが難しい。もちろん、コンパイルは自動化できる。しかし、コンパイルに必要なもの（お使いのLinuxカーネルのヘッダー、コンパイラー、その他のツール）については、ユーザーが自力で用意しなければならない。

主要なディストロでは、利用者の手間を省くべく、nVidiaやAMDといった有名なGPU用のドライバーは、標準のパッケージ管理ソフトウェアでインストールできるよう、あらかじめ調整してくれている。しかし、今日リリースされたばかりの最先端のドライバーを利用したい場合は、どうしようもない。

実に、邪悪で不自由なソフトウェアの信奉者は面倒だ。

では、自由なソフトウェアのグラフィックドライバーの手動インストールは簡単かというと、これが、遺憾ながら、不自由なドライバーより難しいときている。

GNU/Linuxにおける自由なグラフィックドライバースタックは、単一のソフトウェアではなく、大量のソフトウェア群である。ドライバーの一部はLinuxカーネルに、一部はMesaに、一部はX.Orgに、一部はLLVMに、といった具合に、広く分散している。従って、単にカーネルモジュールをひとつコンパイルして読み込むというわけにはいかない。関連する依存ソフトウェアをすべてアップデートしなければならない。しかし、MesaやX.OrgやLLVMは、グラフィックドライバーだけが利用するソフトウェアではなく、グラフィックドライバーの都合だけで気安くアップデートするわけにはいかない。ましてや、ドライバーの実装が最新のLinuxカーネルのバージョンに依存している場合、Linuxカーネル本体をアップデートしなければならない。グラフィックドライバーの都合だけで、Linuxカーネルのアップデートなどできるわけがない。通常は。

結局これは、重複する機能をそれぞれのドライバーで独自に実装せず、共通の実装にして使うという文化からきている。ソフトウェアが自由であり、ソースコードが公開されていて、気軽にコンパイルできる環境だからこそ可能な文化だが、残念ながらこの文化は、ドライバーのアップデートをとても難しくしてしまう。ドライバーのアップデートをするには、依存関係から、システム全体のアップデートが必要になるからだ。

で、このIntelオープンソース・テクノロジー・センターの提供する、Intel Linuxグラフィック・インストーラーは何をしているかというと、要するにUbuntuとFedora用の依存するソフトウェア群のサードパーティレポジトリの提供だ。

Intel Linux Graphics Installer | Linux Graphics

インストラーを実行すると、aptやyumにIntelの保守するレポジトリを追加し、そこからUbuntuやFedoraに合わせて必要な適切に設定されたソフトウェア群をインストールするという仕組みになっている。

そのため、ローリングリリースモデルを採用していない初心者にも使いやすい安定志向のディストロでは、自由なドライバーの大規模なアップデートは、次のディストロのリリースを待たねばならない。この現状はもう少し何とかならないものか。