前にも書いたように、 あるいは、 かずひこさんがパクっていた ように、 オープンソースと商用は排反ではありません。 なのに、 まつもとさんまで勘違い（？） していて、 ちょっとげんなりしてしまいました。 それが本論ではないことは分かっていますが、 オープンソースで飯を食いたい人間がこういう誤解を広めるのはやめてほしいです... 国境云々については全く同意なのですが。
ちなみに、ESPer2007で海外進出に関連した内容のことを話しましたが、 発表資料 (2.4MB, PDF) は公開してませんでした。 興味のある人はどうぞ。
どっちかと言うと、GoogleはOracleに似ていると思うんだけどな...
とかやってないで原稿書かねば。 うみゅー。
かなーりメタな話を書いてみる。
私は随分昔からHOWTO批判を繰り広げてきたが、 それを抽象レベルで一体どうしてなのかを考えてみた。
人間の脳味噌には構造的・機能的に多くの限界が存在する。 ここんところは、コンピュータと大差ない。 頻繁に問題になるのは、速度と容量である。 人間が考えられる速度はそう大したものではないし、 覚えていられる事柄についても量についても、 相当な限界がある。
記憶には短期記憶と長期記憶があることがよく知られていて、 一般的に、短期記憶は容量が小さく、すぐ忘れる代わりに、 アクセスは早い。 長期記憶は忘れにくく、容量もかなり大きめなようだが、 アクセスは遅いし、リンクが辿りにくいようだ。
しかも、人間の記憶力に相当深刻な欠陥があって、 本人はちゃんと覚えたつもりでも消失してしまうし、 もっと悪いことに、覚えた時と思い出した時で内容に一貫性がまるで保証されていない。 この失敗の確率はコンピュータの比ではない。 もちろん、認識レベルでの間違いってやつも当然あって、 記憶される以前に誤認されていることも多いのだが、 そこんところはコンピュータとあまり変わらないと言えるだろう。
しかし、必要な、あるいは、有用な情報量はすさまじい分量だ。 そこで人間の限界や嫌な特性を乗り越えるため、 さまざまな技術が、コンピュータ上であれ、生活の知恵みたいなものであれ、発展を遂げてきたわけである。
例えば、大量の文書に対処するという問題が考えられる。 ありとあらゆるデータは、少なくとも原理的には、文書化が可能なはずなので、単純にデータと言い替えてもよい。
これに対応する方法論には、私の思うところでは、基本的に二つの手法しか存在しない。 一つは、分類法である。 フラットな分類と階層化された分類が考えられるが、 いずれにしても、文書を何らかの概念に基づいてクラスタリングしてしまおうってわけである。 そうすると、一度に捉えなければならない数を著しく減少させることができるので、人間でも対処できるようになる。 一説によると、人間の「理解」とは「分類すること」であるとか、何とか。
もう一つは、キーワードを用いる方法である。 それぞれの文書にキーワードを単数または複数割り当てておき、 キーワードでクラスタリングを行う。 これのある意味極端な応用例が全文検索である。 全文検索とは、文書に表れる文字列（の一部）を片っ端からキーワード化することに他ならない。 キーワードの数が増えすぎるので、当然人間には全文検索方式は向いていないが、コンピュータを利用することである程度は克服できる。
ちなみに、理論的には、分類方式はキーワード方式の一例に過ぎない。 階層は親子関係を表現するキーワードを割り振っておけば表現できるからだ。 しかしながら、そこで必要になる計算量やアルゴリズムにはかなりの違いが生じるので、現実的な意味合いで同じだとは言えない。
さて、ここまで書いたことは静的な世界である。 つまり、すでに存在する静的データが存在していて、そこをどう探すか、 という問題だ。 コンピュータに慣れている人なら誰でも知っているように、 静的に対して、動的な概念というのも考えられるわけだ。
ものすごく極端な話をすると、 データをビット列として捉えてしまうと、 ビット列は関数で生成することができるわけだから、 比較的わずかな情報を覚えておくだけで再現することが可能である。 例えば、0208268042のような、さっぱりどう覚えていいかわからない電話番号があったとして、Pythonで書くと、
def f(x): return 3 * x + 2 v = 0 for i in xrange(5): v = f(v) print '%02d' % (v % 100)
で再現できるわけだ。
a * x + bという関数の形や初期値ゼロを無視すれば、
「3を書けて、2を足して、下二桁とってくることを五回繰り返す」
とだけ覚えればよいので、
データとしては四つの一桁の数字しかないわけである。
明らかに覚えるべきデータ量は減少している。
もちろん、こんなのは極論であって、こんな方法で電話番号を覚える人間が実在するとは信じていないが、 情報を動的に生成することも可能だと言いたいのである。 そして、実際に人間はそういうことを日常的にやっている。 それは普通、論理とか演繹とか類推とか、いろんな用語で呼ばれているが、 やっていることは動的生成なのである。
コンピュータにおける動的と静的に関する議論はストレートに人間にも当てはめることができる。 静的なものは融通が効かない、変更に弱い、しかし計算コストは低い（本当にそうかどうかは検索コストがあるので疑問視されるべきだが）。 動的なものはその反対。 必ず計算が入り込むので、オーバーヘッドが発生するのは避けがたいが、 応用がきくし、柔軟だ。
情報の変化が激しい世界においては、静的なやり方は困難を極める。 書き換えが多いからだ。 ディスクは読むより書く方が遅い。 人間の頭はもっとそうだ。 思い出すのは割合簡単だが、新たに覚えるのは大変だ。 どうせすぐに役に立たなくなることのために記憶力を費すのは、 人間の貧弱な脳味噌においては、あまりに惜しい。
だから、内容を覚えるよりも探し方を覚えろとか言われる訳である。 動的な作業が生じる代わり、圧倒的に記憶領域を節約することができる。 内容が変化しても、ほとんど影響を受けない。 この方がずっと効率がよく、優れていることは言うまでもあるまい。
というわけで、すぐ使えなくなるし、それ自体を知っていたからといって、 滅多と役にも立たないHOWTOを追いかける暇があるなら、 もっと応用のきく原理や概念や演繹能力を鍛えた方がずっといい。
と、ずっとぐだぐだ書いてきたが、実はここまではまだ前振りだったりする。 本当はHOWTOなんてもうどうでもよくって、単なるネタにすぎない。 それよりも、この「動的な脳味噌の活用」の方が本題。
いきなり、ソフトウェアの世界に限定した話になってみる。 ソフトウェアの開発の流れとは、一般に、 「設計→実装→導入→利用」である。 XPの好きな人なら「設計→テスト→実装」だとか、 いまだにウォータフォールを信じている人なら「設計→モジュール分割→実装→統合→ユーザテスト」だとか、 やれループがあるだ、やれ分岐があるだとか、いろんな声が聞こえてきそうだが、 ここではそんな細かい話は抽象化の妨げでしかないので、 無視することにする。
「実装」とは、唐突だが、「設計」のインスタンスである。 青写真の具体化に他ならない。 これは人間の「動的活動」である。 脳味噌だけの活動ではないという点において、上記の話からはみ出す部分もあるが、大部分は脳味噌の活動である。 人間の価値とは、動的生成のプロセスにこそ潜んでいる。
しかし、抽象的には、これらのあらゆる段階がインスタンス化だと言える。 「実装」はソフトウェアの存在という意味ではインスタンス化されているが、 「導入」によって、ある特定のコンピュータに存在するというインスタンスとなる。 そして、「導入」はコンピュータに入っているという点ではインスタンスだが、 実際のソフトウェアを利用した活動に反映されていないという意味で、 いまだ抽象の領域に留まっている。 これが「利用」によって、ある特定の日常活動に入り込むというインスタンス化が行われる。
実は「設計」もインスタンスである。 それの大元は、おそらく「思想」、「知性」、「概念」であり、 それらにもさらに上流が存在するのだろう。 しかしそこんところが本当に何なのかは私にはよくわからない。
先の議論にもあったように、動的なものは柔軟性があり、 変化に対応できるわけで、抽象的にはより一層大きな価値を持っている。 だから、ここで述べたものの中では、人間がどのように物事を捉え、 どのように方向性を与え、どういう演繹の仕方をするかという、 「思想」、「知性」、「概念」のレベルこそが最大価値を持つ。 こういう抽象レベルを軽視する人は、その分、損をする。
別の言い方をしてみよう。 静的なものは変えにくい。 インスタンス化の下流にあるものは動的に生成されているわけだから、 それなりのオーバーヘッドを覚悟すれば、作り直すことができる。 しかし、上が腐っていると、下は必ず腐るので、どんどん遡るしかなく、 工程が増加するので、オーバーヘッドはどんどん大きくなる。 だから、上流に行けば行くほど、その重要性は高まる。
例えば、駄目な概念で設計されたソフトウェアはどうあがいても駄目である。 駄目な設計で実装されたソフトウェアは、どんな天才ハッカーでも素晴らしいソフトウェアにはできない。 だから、実装が腐っているのは、設計が腐っていることほど重要ではないとも言える。
もっと考えていたことはたくさんあるのだが、 そろそろ書くのに疲れてきたので、この辺でやめる。 設計をインスタンス化するフレームワークがプログラミング言語であるなら、 導入や設計や思想における「プログラミング言語」とは一体何なんだろう、とか、 XPのような方法論を異なる段階に当てはめるとどうなるんだろう、とか、 下流から上流への逆方向へのフィードバックのこと、とか、 方向性が存在することにおけるSI事業者やソフトウェア利用者の役回りとその価値、 とかとか。
もう精神的に疲れ果てて、 全然他のことをやる気がおきません。 せめて中の人ぐらいは面倒かけないでくださいと言いたくなります。
しかし 野首さん を見ていると、何だか自分ももう少しやれそうな気がして、 勇気がわくのでありました。 でも、お互い、あんまり無理はしないようにしましょうと言いたくもなったり...
これだけだと気を悪くする中の人がいそうな心配があるので、 ちょっといいことも書いておきます。
人は、何か自分がやってないことや、やれそうにないことをやっている人を見ると、 すごい、自分もやってみたいと賛同の意思を示す人もいる一方で、 この人は自分とは格が違うのだとみなす人もいます。 しかし、果して本当にそうなのでしょうか。 もちろん、本当にそうだと言える場合もあるでしょうけれど、 それほど悲観するほど世間の人々に先天的な差異が存在するわけではないという気もします。
では、一体人が新しいことをやってみない背景にはどういったことが考えられるのでしょうか。
私自身は、とても新しいことが好きです。 その度、自分ができそうだと思うところから選ぶことはあんまりありません。 選んだところから、自分ができるようにしたことは何度もあります。 もちろん、できるようになれなかったこともあります。 しかし、自分が挑戦しなかったことで後悔したことならありますが、 挑戦して失敗して後悔したことはありません。 少なくとも、挑戦する精神力をもったことに誇りを感じることができましたし、自分の能力の限界や適性をよりよく理解することができたからです。
逆にマンネリがとても苦手です。 同じことばかりやっていると、気が滅入ってきます。 自分の成長が止まることをとても恐ろしく感じます。
もちろん、どう考えるかは人それぞれです。 みんなが自分のような生き方をするべきだとは、これっぽっちも思ってません。 しかし、自分のように新しいことに躊躇せず立ち向かおうとする人を応援したくなります。 私はそういう人が好きだし、頼もしく感じています。 今挑戦を続けている人はそのまま頑張ってほしいし、 今はしていないけど挑戦する意志を持っている人は是非一歩を踏み出してほしいと思います。
また漠然とした話になってしまいましたが、 伝わる人には伝わると思うので。
タイトルがほぼすべてを言い尽くしている気がするけど、 もうちょっと細かく書くと、 えー、前提として Openbrickが家庭内サーバとしていまだに活躍していたということがあげられます（多分世界で最後の現役だった）。 かつては外向きにもやってましたが、 今は dedibox を使っているので、 純粋に内部用途でした。 ところが、こいつが最近クラッシュして以来、とても調子が悪い。 カーネルパニックを起こしたりするし、 そろそろ限界かと感じて、 放置していたMac miniを少しは活用してやることにしたのです。
とりあえず、あっちこっち眺めて、 結局Legacy Bootで済ませることにして（何でいまだにGNU/LinuxディストリビューションはEFIを真面目にサポートしないんだ？）、 Boot Campはすでに使用不可になってしまっていたので（Mac OS Xが10.4.x）、 Mac OS Xは完全に捨てて、全部 Kubuntu にしてしまうことにしました。 Mac OS Xみたいな不安定で、（伝統的Unix派からすると）気味の悪いディレクトリ配置のOSなんて、メンテしたくないから。 不自由だし。
やり方はいたって簡単。 とりあえずMac OS Xを吹っ飛ばす前に、Firmwareを最新（1.1）にアップグレード。 それからMac OS X Install Disc 1で、Disk Utilityを起動して、 パーティションをMBR化。 ここんところがはっきりしないのだが、 EFIのファイルがちらほら散見されるので、 先頭にHFS+のパーティションをできるだけ小さく作っておく。 これが本当にいるのかどうかはよくわからん。
KubuntuのCDをつっこんで、Alt押しながら、例のセレクタを表示して、 CDから起動... しなくてもいいんだった。 Mac OS Xを吹っ飛ばした時点で、これしか起動できないんだった。 後は、最初のパーティションを触らないようにして、 Manualでパーティションをてけてけ作って、 ふつーにやればおしまい。 一度F12を押してもCDが出てこなくなって焦ったが、 Altでセレクタに行ってからF12押したら、ちゃんと出た。
まあ、ここまではよかったんだが、 Openbrickに入っているファイルをMac miniにコピーしようとして、 こっから泥沼。 rsyncでKernel Panicしやがったので、 これを再起動したら、e2fsckが死ぬようになってしまった。 下手に回復させようと頑張っても、e2fsckがsegfaultしてしまう。 しょーがなく、どっかからCFに書き込めるレスキューイメージを拾ってこようと探したが、 Openbrickなんてもう開発しておらんから、 手元のマシンにはちっとも残ってない。 会社サーバにも見付からないし、 うーむ、困ったと思っているとき、 ちょうどよくCEOから電話がかかってきたので、 ついでに適当なイメージをどっかに置いてたりしないかと訊いたが、 すぐに渡せるようなところには全然ないことが判明しただけ。 自分で作れってか。
しかし人間頑張ってみるもので、 自前のバックアップ用USB HDDを探索していると、 まだ日本にいた頃に作った古代のイメージが運良く残っていた。 ああよかったとこれでブートすると、 Kernel Panic。 もうやってられまへん。 ファイルシステムがおかしかったから、 HDD上のファイルが腐っているのかと思っていたら、 どうもメモリが腐っている、と言う方が正しいようだ。
と、この辺で諦めて、 Openbrickからファイルを救出するのはやめることにした。 それより、新しいKDEで遊んでみることにした。 この方がずっと楽しい。 しかし、K3BとAmarokはよくできているな！ rippingしながらCD playを選べてしまって（故意ではない）、 CDドライブが永遠に悲鳴を上げ始めたので、 Amarokをkillせざるを得なかった。 killすれば直るところは昔とちょっと違うが。 もうちょっとリソースの競合をちゃんと管理してくれないのかね。
Ulrich Drepperの例の論文ですが、一通り読み終わりましたよ。 システム・デベロッパならこれぐらいのことは大体おさえておいてよ、 という程度の内容なので、特に新しいことは書いてませんが、 よくまとまっているので、こういう文書が手軽に入手できるようになったのは喜ばしいことです。昔は持ち運ぶのも苦労するような馬鹿高い書籍しかありませんでしたからね。
ちょっぴり面白かったのは、HTの活用法として、 prefetch専用のthreadを使うというところ。 これまで、HTって、パフォーマンスの向上にどう役立てることができるのか、よくわかりませんでしたが、確かにこれは悪くない発想。 しかし、頑張る量が多い割に効果が少ないんだよねえ。
まあ、何というか、ハードウェアで頑張っている人たちはすげーなあと感動しますが、それでソフトウェアで何ができるかっていうと、 実は案外何もないんですね。 やってみても、運が良くて数倍、大抵は数パーセントの影響しかない、 しかもその時のコードにばりばり最適化するしかないので、 コードが進化したら一からやり直しだし。
だから、よっぽどシビアな場面でしか使えないことが多すぎるんですよね。 そりゃ、構造体のメンバーをalignしておくとか、 それぐらいは当たり前にやっておけばいいんですけどね。 でも、そんなこと今さら言われなくてもやってるでしょ？
と、少々否定的な書き方をしてしまったけれど、 あんまり知らない人は一読すべき論文だと思います。 何でかっていうと、 多分直接使えることは少ないだろうけど、 アイデアの源泉としては使えるから。 ここの主題はメインメモリとキャッシュメモリだけど、 基本的には「大きくて遅いもの」と「小さくて速いもの」で構成される場面なら、どこでも通用する概念とかテクニックが多い。 例えば、ディスクとメインメモリとか、 リモートマシンとローカルマシンとか、 インターネットとかイントラネットとか、 色んな所で同じような問題が発生する。 実際、prefetchのようなことはread aheadとか呼ばれて、昔からHDDに対して使われているし、 ブラウザの先読み機能とか、形態は違っていても、根本的には同じことをやっているわけ。
残念ながら、細分化の激しい業界なので、 他のところはさっぱり事情がわからんかったり、 用語がかけ離れていて意志の疎通がはかれなかったりするだけに、 こういうまとまった資料にたまに目を通すのは悪くないと思う。
P.S. それよりもっと驚いたのは自称オープンソースプログラマな人がUlrich Drepperの名前も知らないことであった！ 相当な有名人だと思うんだがな、少なくとも開発者の間では。
_ まつもと [ああ、そうか。「商用」と「オープンソース」が対立するように読めますね。 商売と国境は密接に関連しているので、ここで言..]