Press Enter ....

まずはこれを見てほしい。なかなかのスクリーンショットでしょう?


じゃぁ、今度はこれ。もう少しロングから：


見慣れている人はもう判ったでしょうか?

こ れは2005年10月22日に、 JAL 780便のエコノミークラス 18-Dで、自席についているモニターを撮影したものです。本来ならば、ビデオとかオーディオとかが楽しめるシステムなんですが、こいつを interactive モードにして『映画』を選択し、画面になかなか映画一覧が出てこないので思わず6連射をぶちかましたら出てきた画面がこれです。

たぶんベースは Monta Vista なんじゃないかなぁ、と思います。/rhs73/lib/の下にあるのが何なのか本当のところは判りませんが、ゲームか何かを実装する際に Red Hatのライブラリでも使ったのでしょう。


いや、何も飛行機の娯楽施設にLinuxが使われるようになったことを喜びたいわけでも、嘆きたいわけでもありません。今回得られた経験値はちょっと違うところにあります。


最初のほうの画像の最下段にはこうあります：

Please press Enter to activate this console.

しかし、「Enter キー」なんてありません。手元のコントローラーには。いや、もちろん、組み合わせもいろいろ試しましたとも。でも駄目です。どうしようもありません。

はっきり言いましょう。ものすごいストレスです。イライラします。要因は2つです。

1つめの要因は、『本来使えるはずの娯楽施設が使えない。回復させるための操作も出来ない』という事から来る、不自由感に基づいた不快感です。リブートさせれば直ると判っているわけですから、一刻もはやくそのような操作をして環境を回復したいのに出来ない不快感。これはこのような画面を見せられたユーザー誰もが感じることでしょう。

でも、そんなのは2つ目の要因に比べれば些細なことです。
『目の前にバグがあり、
勝手知ったる世界であり、
かつソースコードへのアクセスが阻害されている』
この不愉快さ。Richard Stallman が FSF を作るに至った不快感と本質的に同等な不快感です。
これを検出した瞬間に、GPL2.0では駄目だ!! と思いました。

GPL2.0では、結局GPLで配布されているバイナリの持ち主が、「ソースもくれ」と言えば、ソースコードがもらえる、という制約しかありません。今回バグを出したプログラムがGPLで公開されていたとしても、2つも問題があるのです。

1. ソースをくれと言って、ソースが手元に到着したころには飛行機は目的地に着いている
2. ソースをもらっても、キーボードがない環境ではデバッグも出来ないし、システムへの再インストールもできない
   

どちらも、「そりゃそうだ」としか言いようがない話に過ぎないように見えますが、これらはようするに

• GPL2.0 ではソースコードへのアクセス時定数という側面を考慮していない。
  つまり、ソースコードは「いつかは」手に入るだろうが、「それがいつになるのか」の保証がない、という事です。
• GPL2.0 ではソースコードへのアクセサビリティの保障という側面を考慮していない。
  つまりソースコードは得られるかもしれないが、それは、このジャンボジェットの座席システムのように著しくアクセサビリティの悪い環境でしか参照できないように細工されたメディアかもしれないのです。

という事なのです。

GPLに対して LGPL があるように、GPL3.0では是非、コントロールレベルを複数存在させてほしい。その中にはこれらのアクセサビリティ問題についても

「常にソースコードを参照し、
常にソースコードを変更できる環境を
ユーザーに提供しなくてはいけない」

などという一見非常識なほどの制約をかけたものも用意してほしい。そして、それを選ぶ自由を、プログラマに与えてほしい。


そんな思いが去来したのが、最大の成果でした。


なお、JALの名誉のために言っておきますと、離陸5分後にはリセットをかけていただきましたし、その後はちゃんと動作していました(6連射はやっていませんが)。周囲の座席への影響もなかったようです。

ただ、そのように復旧してしまったコンソールはただひたすらに退屈なものに過ぎず、私は映画も見ずに眠ってしまったのでした…。

OSDLのF2F、金曜日は万里の長城と明墓観光ツアーです。その万里の長城でのこと。

坂の下のほうにある巨大な駐車場に、人民軍のものと思しきトラックが何台も停まっています。何だろうと思いつつバスは坂を登っていきます。と、なんと膨大な人民軍の皆さんが。

この写真は車から降りた後、撮影したものですが、後ろから来るわ来るわ、すごい数です。しかも機関銃を持ってます。

そして、駆け足で我々を追い抜いていきます。元気あるなぁ。

彼らは長城の中でもハードな方を登って行きました。
隊長のような人が定期的に何かを叫び、そのたびに皆さん、駆け足になるのですが、一瞬だけです。万里の長城を駆け足で登るなんて無理だって。

で、このようにずらーーーっと並んで、何かを大声で叫んでいる所を、本格的な機材で撮影している人達がいました。この右の写真を撮影している傍でもプロ用のデジタルカメラを数台使っていましたから、何かの撮影だったんでしょう。

私はというと、このシーンを撮るために簡単な側を負けないぐらいの速度で駆け上っていました(いや、足が死ぬかと思った)。

で、撮影が終わったのでしょう。ものの30分ほどで彼らは帰っていきました。


たぶん、彼らは本物の人民軍でしょう。そして機関銃も本物でしょう。偽者を作る理由はありません。人民軍を雇うほうがコストが安いですし、偽の機関銃をいちいち用意するより、官給品から弾丸を抜いたほうが手っ取り早いでしょうから。

しかし、これに付き合わされて、空とはいえ機関銃もって万里の長城を登らされる側の身にも…。
だって右の写真を見てください。人の身長と壁面のブロック2つ分の高さ、おおよそ同じですよ。

しかも、この部分、全体的に見ると局所的に緩やかな部分です(右上のほうの斜面が急になっている部分と比較すればわかります)。とんでもない急斜面で、撮影は実質5分足らず…。

たぶん、これ、鍛錬の一環として扱われるんだろうなぁ。

OSDL F2F 1日目:あるいは今回の頭痛の種

今回のお仕事で一番頭痛の種なのが実はこの人。
Andrew Tridgel 君。そう。Samba の開発者だ。

いや、何が頭痛の種かって、この人黙んないんだわ。喋る、喋る。まぁ、ペラペラペラペラ、よく口が回るなというぐらい喋る。他人の言うことなんざ聞いちゃいねぇ。

「OSDL オーストラリア代表」とか冗談をかましていたが、冗談抜きでオーストラリア全部の人たちの分まで喋る気じゃなかろうかというぐらい…。

自分が興味のあることだけをぶちかます、という意味では一番厄介で、逆に言うとこれを Linus にぶつけるのが一番丁度よいかもしれない、というそんな人物。

と、人物評ばっかりしてもしょうがないので、Samba 4 の話を少しだけすると。

Samba 4 は Samba 3 からは 根こそぎ 変更したものだそうだ。もう、根本構造から入れ替えて、一種のプロトコルコンバータとして成立させるらしい。すると、IDL で記述しやすくなるので、大半を IDL で書き直すそうだ。この結果、Samba 3 から Samba 4 へはコードシェアの分量が圧倒的に少なくなるらしい。

これに関してはよい点と悪い点。
よい点は IDL を使って記述するので、テストが自動生成しやすくなる、という点。
悪い点は Samba 2 で入れて、Samba 3 で蹴飛ばされたのでもう一度力で押し込んだ(しかも、Samba-JP の成果を自社だけの成果のように主張している会社がいるが実はそれは大間違いな) あの、MS-Kanji ⇔UTF-16 変換コードが、また落っこちる可能性が高い、という事だ。当人は、
「高橋基信 が作ったテストコードを通すから大丈夫だ」
と言っているが、さて。IDLで書き直してテストも入れ替えるのであれば、当然このテストに通すのを忘れる公算は高い罠。

と言うわけで、Samba4 は一から評価しなおす必要があるようだ。

ちなみに人物評に戻ると、この人はその口の回転速度以外は基本的に田舎者です。つまり、人柄的には悪い人じゃない。が、普通はその口の回転速度はオバチャンの独壇場だと思うのだが…。

Cool, yet Dangerous guy

中国、北京に来ています。お仕事です。
OSDLの全体合同ミーティングに出席するためです。

さて、会場のホテルでかっこいいものを見つけました。ガラスと金属ばねで出来た渋いやつ。左右対称形がきらりと光っています。

しかし、これは危険な奴です。体重計です。
ちょっと油が切れている感じがしているので、表示体重は若干少ない目に出るのがサービスかもしれませんが、まじめにメンテナンスするといい感じな数字が出てしまいます。

しかも場所は中国。ご飯が美味しい場所です。これからしばらく、こいつと同室する必要がある、というのが悩みの種…。

Book Stores were closed on Shibuya

渋谷へ行ってきた。ロットリング純正のコンバーターが欲しかったのだ。が、渋谷では手に入らなかった。それは良いとしよう。

問題は、渋谷の

• 旭屋書店
• 大盛堂

が両方とも閉店。楽しみが半減してしまった。

もう渋谷は駄目かもしれない。なのに、そのうち仕事場が豊洲だと?! 大手町も通らなくなるのか!?!
却下だ、却下。関東で丸善と紀伊国屋と神保町と秋葉原の最低限3箇所へ10分以内に到着できないところに、技術系の会社が開発部隊をおいちゃいかん！

「優先順位」は「優先順位」

万年筆、それも無印良品のそれについてのページをいろいろ探していたら面白いことを言っている人がいた。ので、これに反論してみたい。(あぁ、天邪鬼だ)

世に出回っている「仕事の仕方」指南書的なものによく書いてある
「優先順位をつけて優先順位の高いものからやる」
という仕事のやり方には、アルゴリズム的に考えて2つのポイントがある。

1. ソートの概念がある
つまり、仕事Aと仕事Bには、1次元的な価値基準で分類できる、という事だ。もしこれが直行する2次元、たとえば「Aは背が高い、Bは体重が重い」のような事を言われたら、比較できない。

2. 比較関数は「お金に換算しての優劣」をベースにしている
ぶっちゃけた話、あの手の本に書いている事を要約すると、ある仕事AとBでは、Aの方が「金になるから」優先するのである。一見似たような収入の仕事A, Bの場合も「A を先にやらないと、損害額がでかくなる」からAを優先する。つまり、収入期待値を使っているのだ。

さて。もうお判りだろう。このページの著者は、実は 1 については何も言っていない。むしろ同意している。2 が「収入期待値」じゃなく「自分がやりたい興味」にしたい、と言っているだけなのだ。

でも考えて欲しい。「優先順位をつける」のは別に「収入期待値でソートしなくてはいけない」という意味ではない。単に企業で働いている人の大半は収入期待値でソートしてくれないとたまったものではないから、その例を出しているのに過ぎない。し、またその説明を受けてそれ以外の発想が出てこない人は、それで十分なはずだ。だって仕事は「お金を得るために」やってるはずだからね、大半の人は。

じゃぁ、そうじゃない人は? つまり、比較関数を収入期待値以外にしたい人は どうすればいいのか?簡単だ。そのために「研究員」などの肩書きが存在する。この肩書きの分捕り合戦に勝てばよいのだ。そして、上記のように「ソートアル ゴリズムの存在」と「比較関数」のような考え方が出来れば、研究員程度の肩書きはどうにかちょろまかすことは可能なことだろう(おいおい)。

何のことはない。「自分の興味」を『優先』規則にできると思いつける人は、そういう職に就ける、というだけの話だ。残念ながら、研究員なら自分の興味を常 に優先できるとは限らない、というより実はそれ嘘、普通の開発の人たちの方がよほど自由よ、と話は続いてしまうのだがそれはさておくことにしよう。