月: 2003年9月

　[ NowonDVD.net ]　\3900
　GNU ProjectからLinux, Open Source Movementの関係者のインタビューをまとめたドキュメンタリー。Proprietary陣営への直接インタビューはなく，公平性を重んじる向きにはちと不満なところがあろうが，これだけの重要人物の肉声による証言はそれだけで貴重であり，買っておいて損はないDVDである。個人的にはこれと同じスタンスでThe Internet創世期のドキュメントがあれば申し分ない。どちらもお互いに絡んでいる所がたくさんあるので，大きな歴史のうねりを知るには必要な情報なのである。
　ドキュメント中，StallmanがGNU Hurdについて，Linuxよりデビューが遅れた理由を説明する下りがあったりして，それなりにGNU/Linuxの歴史は知っているつもりでも，これは新発見だった。発売元がマイナーレーベルだけに，これがリリースされたことすら知らない人も多かろうが，Open Sourceに興味を持つ向きにはお勧めしておきたい佳作である。

　夕食を壱番館のカレーで手早く済ませて帰宅したら睡魔が襲ってきて，そのままバタンキュー。目が覚めたらまだ日が変わる前であった。仕方がないのでこうして日記を付けているという次第。
　それにしても昨日は暑かった。関東以西は秋雨前線を押し上げた蒸し暑い暖気の影響で残暑がきつく，静岡でも30度を優に超えた。
　そんな日に，実験講座で使用するために一旦ばらしたCS-PCCLUSTERを再度組み立てようと，PCの移動を敢行したものだから，暑いの何のって。黒い無地Tシャツを着ていたので，作業終了後にクーラーに当たって涼んでいたら汗が乾いて白い塩がふき出てきてしまった。
　と言う訳で，CS-PCCLUSTERのBefore/After。

　やっぱりPC Clusterはラックに収まっているべきものであるな。
　ちなみに，Test runの後，最初に繋いだ8port Repeater Hubは16portのSwitching Hubに変更された。並列DKA法でガンガン回していたら，数十分後に必ず一台のNIS/NFS接続が切れてしまうのである。MPIとNIS/NFSとを同じIP net上で使うというズボラなことをやっていた報いであろうか。で，取り替えて様子を見ているという次第である。
　PC Watchのソニー副社長のロングインタビュー。GridとCell computingの話が出てくる。まだ実験段階であるだけに抽象的な言い回しが多くなっているが，ビジネスとしてそーゆー話が出てくる時代になったのだな，と感慨深い。
　思えば，CPUが登場し，hippieが大型計算機のantiとしてのPersonal Computerを作り出し，downsizingが進み，アーキテクチャがPC/AT compatibleへと収斂していきつつ，Webをkiller applicationとしてThe Internetが全世界に普及して，IT革命を謳歌した途端にITバブルが弾けて今に至る訳だが，この間，高々30年足らずである。修士時代，混雑するS-810をちょろっと触っていた程度のわしが，並列分散処理を手かげることになるとは夢にも思わなかったが，それもこのような時代の変遷の影響を受けてのことである。
　以前，東大を定年退官されたI先生が講演の中で「一体いつになったら計算機の環境はfixするのか」と半ば呆れて慨嘆されていたが，わしはそれを聞いて，あの元気なI先生に「老い」の影を見ると共に，「変化する環境と共にあるのが『応用』的学問じゃないのか」と，少し反発する気持ちを持ったのである。

　何だか蒸し暑くて目が覚めてしまった。9月に入ったというのに，残暑は根強く残っているようである。
　今日は防災の日。駿河湾で大地震が発生，という想定で防災訓練が行われるようだ。全く当事者としては胃に良くない設定である。緊急時連絡カードなるものも常時携帯するように配布されており，わしがどっかで何かの下敷きになったりしていなければ，いざその時には職場に駆けつけ，カードに書いてある連絡先に電話をし，生存が確認できるようにしておかねばいけないらしい。自身はもういつきてもおかしくない状況だそうだが，具体的な日時の予測は難しいから，全く待たされる方はもどかしい。早く来ないかな(違う？)。
　今日は雑用に追われる一日であった。午後からは企業の方が来訪されて，研究話。SCOの訴訟があってから，Linuxがらみのビジネスからは一端手を引いたということであった。それなりに効果はある訳ね。ヤクザのミカジメ料みたいなもんを請求しているらしいが，はてさて判決はいかばかりか。
　注文していた”Revolution OS”が届いたので，作業をしながら流してみる。音楽のセンスがイイし，インタビューしている人選もナイスである。詳細はちゃんと見てからここに書くことにしよう。
　で，それを見つつ思いついたのだ。Open Sourceのビジネスってのは技術的には高いレベルを要求されるのだなあってね。
　結城浩さんが書かれた固有IDのシンプルシナリオ流に単純化して，例を示してみる。
(1) 企業Aはプログラマaにあるシステムを発注する。
(2) プログラマaは，Open Sourceのパッケージαにコードを付け加えて改良し，パッケージα’として完成させて，企業Aに納品する。
(3) プログラマaはパッケージα’をOpen Source Communityにて公開する。
(4) Open Source Communityから別のプログラマbがパッケージα’を入手する。
(5) プログラマbは「私はプログラマbより安い費用でパッケージα’をメンテナンスできる」と，企業Aに自らを売り込む。
　まあ実際には人が作ったものをその人以上に理解して改良できるかと言えば難しいことが多いだろうし，そんなズーズーしいことを平気で実行できる厚顔無恥な輩は少ないだろうから，(5)のようなことはあまりないと言える。んでも
(5)’ パッケージα’をサポートしてくれるプログラマを捜している企業Bが，ツテを辿ってプログラマbに依頼する。
もしくは
(5)’’ プログラマBが，パッケージα’をサポートできる旨，それを求めていた企業Bに自らを売り込む。
ことは枚挙に暇がないし，そーゆー繋がりを通じて，Open Sourceが広がったという側面は見逃せない。
　ソースが公開されているってことは，それをサポートする上で，言い逃れが出来ないってことにもなる。勿論土台となるパッケージの出来が悪ければ改良にも限界はあるが，そうでなければ，不具合が直せないのはソースを読み解く力がないか，サボっているためにそれを回避する手段を見いだしていない，ということになる。しかも，ユーザ数は多いから，モタモタしていては自分以外の人間がさらなる改良を施してしまう可能性が高い。Proprietaryであれば，バイナリだけをユーザに渡し，自分の能力の及ぶ限りにおいて，差分パッチをリリースしていけばいい。勿論，あまりにヒドイ不具合があればそのうちライバルが出現して来る可能性は出てくるけど。
　してみれば，Open Sourceのビジネスモデルでは，技術スキルが不可欠要素となり，言い訳の効かない世界であると言える。うーん・・・。