MIRACLE
メールサービス申込 ユーザー登録 パートナー情報
お問い合わせ FAQ サイトマップ
MIRACLE LINUXの特長 製品紹介 サービス案内 購入 サポート 技術フォーラム

プロフィール

吉岡 弘隆 - よしおか ひろたか

日本OSS推進フォーラム ステアリングコミッティ委員
OSDL Board of Directorsを歴任
カーネル読書会主宰

2000年6月、ミラクル・リナックスの創業に参加。
95年~98年、米国OracleにてOracle RDBMSの開発をおこなっていた。
98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。
2008年6月取締役CTOを退任し一プログラマとなった。

ミラクル関連リンク

採用情報

サイト検索

2008年9月

  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

« 2007年5月 | メイン | 2007年7月 »

OLS 2007 (3) -- TOMOYO Linux BOF

6/29は下記の講演を聞いた。http://www.linuxsymposium.org/2007/schedule.php

午前中
Asynchronous System Calls
How Virtualization Makes Power Management Different
Hybrid-Virtualization - Ideal Virtualization for Linux
技術的な詳細は別途記すことにして、簡単にふれると、Asynchronous System Callsはシステムコールを非同期にしようという話で、通常のシステムコールだと、処理が終るまでカーネルから制御は戻ってこない。同期しているわけだ。それを非同期にすると何がうれしいかというと、IOみたいなレイテンシーの大きい処理については、他の処理ができて、スループットが上る。Oracleの人間が発表していて、いろいろ性能向上が著しいというデータを出していた。

昼飯は、原田さん、武田さん、熊猫さん、三浦さん、吉藤さんらと(誰か忘れていたらごめんなさい)タイ料理で辛いものを食べた。吉藤さんご推薦のベトナム料理に行こうとしたのだが、店が発見できなかったということは、ここでは触れないことにする。

2月8日にカーネル読書会で、TOMOYO Linuxの話をしてもらった時に、OLSに乗り込むべきっすよ、カーネルコミュニティへデビューですよ、とか無責任にがんがん言ったおかげで、ここOttawaでタイ料理を原田さんと食べることになる。 

このポイントは非常に重要である。これについては別途記すことにする。なんか別途記すばっかりになってしまうな。

午後は下記を聞いた。
Supporting the Allocation of Large Contiguous Regions of Memory
Djprobe - Probing the Kernel With the Smallest Overhead
djprobeは平松さん、大島さんのコンビでいい感じで発表をしていた。SMP環境の時fence命令を入れないと同期しないのではないかと思ったのだが、明日あたり質問してみよう。

Thin Clients/PHAT results - Are we there yet?
Jon maddog Hallのキーノートはthin clientsをという話で、あまりに面白い話なので、スライドをせっせと写真に撮って撮りまくった。BOFまで時間があったので近所を散歩していた時にカメラを会場かどっかに忘れてきたことを思い出し、青くなる。ことの顛末は、はてなの日記(未来のいつか/hyoshiokの日記)に記したので、参照してほしい。

BOFs
Distributed Cluster Computing on Cell/PS3
TOMOYO Linux

さて、TOMOYO Linuxである。BOFである。約5ヶ月前、原田さんをたきつけて、とうとうOttawaまで引っぱり出してしまったBOFである。

(続く)

OLS 2007 (2)

6/28のセッション。Ottawa Linux  Symposium 2007

以下を聞いた。
Greg Kroah-Hartman, Linux Kernel development, who is doing it, what are they doing, and who is sponsoring it (with pretty graphs and a few posters)
Corey D Gough, Kernel Scalability: Expanding the Horizon Beyond Fine Grain Locks Martin Bligh, Linux Kernel Debugging on Google-Sized Clusters
Len Brown, ACPI in Linux -- Top 10 Myths vs. Reality

内容については別途詳細に報告するとして、Gregのおはなしは先日のカーネル読書会で聞いたバージョンとほぼ同様の内容である。前回彼の話を聞いた時、パッチを書いた人がどこに所属しているかというスクリプトでmiraclelinuxがどこに所属しているかというで、メールをしたのだけど、今回の発表でもリストアップされていなかった。むむむ。納得いかないぞう〜

ols(Ottwa Linux Symposium)初日

来ました、オタワ(Ottawa)に。もちろんLinux hackersの祭典Ottawa Linux Symposium(OLS)に参加するために。

シカゴ経由でオタワについたのは現地時間の午後5時ころ。ホテルにチャックインして、そのままOLSの会場へ。初日のプログラムは滞りなく消化されているようで、わたしはBOFのセッションから参加。GoogleのTシャツを着ていたら、「Googleに勤めているのか?」というようなことを聞かれる。まあ、愛嬌である。午後8時からIntelスポンサーのレセプションに参加する。日本人がいっぱいいるので、どもども、お久しぶりですとご挨拶をしつつ、「やるよ、カーネル読書会」とわたしの野望を披露する(笑)。

Kernel Summitが英国で開催されるらしいという情報をSONYの上田さんから仕入れる。むむむ、Kernel Summitを日本で開催したいよねということで盛り上がる。来年はオタワということで決まっているらしいので再来年(2009年)は日本に招聘しよう、できれば横浜で。YLUGがボランティアで仕切りましょう、とか勝手なことを言って、わたしの妄想はピークに達する。しかし、不可能ではないと思っている。OLSにはじめてきたのが2003年で、その時、いつかはOLSで発表したいなあと思っていたのだが今年そのユメがかなう。ならばKernel Summitを日本で開催するというユメがかなわないわけがない。いつの日か日本でKenrl Summitを開催しようと勝手に思ったオタワの夜である。それまでに、日本という地域からどれだけカーネルに影響力のあるパッチを投稿できるか。それがわれわれの課題だ。

YLUG(横浜Linux Users Group)の世界デビューの日も近い。

6月28日オタワで出張カーネル読書会BOFをゲリラ開催します。ビールを飲みましょう。:-)

カーネル読書会のめざすもの

YLUG(横浜Linux Users Group)カーネル読書会FAQページがあまりにも古いので更新しようと思ったのだが、どっから手をつけていいやら。

この手のFAQは個別のエントリに回答を重ねて更新する事はもちろん可能なのだが、ロードマップというかカーネル読書会をなぜ開催したいと思ったのかとか、なぜ続けているのかとか、どうしたいのか、とかいう明確な意志の表明なんかがあるといいかもしれないと思った。企業のビジョンステートメントみたいなものである。

おいおい、たかが趣味の世界でビジョンステートメントはいくらなんでもやりすぎだろう。大袈裟すぎやしないか、という声もある。そう思う人もすくなからづいそうだ。わたしもそう思わなくもない。

コミュニティ(?)のビジョンとかミッションというのは通常明文化されないし、されたためしも(ほとんど)ない。LinusのJust For Funという書籍は、ある意味その手のものかもしれないけど例外である。あ、StallmanのGNU Manifestというのがあるなあ。これは例外中の例外だ。

まあ、楽しいから続けていたら続いちゃったというのが本当のことであるが、どうせなら試しに、カーネル読書会にまつわる「よしおかの野望」を明示しておこうと思う。

わたしは、90年代中頃、シリコンバレーの大手データベースベンダーでRDBMS(リレーショナル・データベース管理システム)の開発をしていた。シリコンバレーのフリーペーパーには各種ユーザー会や勉強会の日程が載っていて、その量とバラエティに圧倒された。プログラマとしてプロフェッショナルな道を歩むために、ぜひその手の会合に出ようと思った。機会をみつけて参加したいと思った。たまたま参加した、SVLUG(Silicon Valley Linux Users Group)の活気、熱気には圧倒されたことを鮮明に覚えている。

会社の壁とか人種とか国籍とか性別とか年齢とか、そんなもの一切合切関係なく、ひとつのことについて自由に語りあっている場というのが、どんなにか素晴しいかというのを実感した。

99年に日本に帰ってきて、自分の生活圏にそーゆー場があったら素敵だなと思った。

これからはオープンソースでしょ。みたいなノリもあった。

自由命みたいなノリもあった。

自分が勤めている会社とは対極にあるムーブメントにしびれていたのである。

日本に帰って、たまたまYLUGというのを発見し、早速メーリングリストに参加した。特に会費も会則もないのが気にいった。時々宴会をしているらしい。楽しそうである。

そこで、カーネルのソースコードを読む宴会(?)というのを提案したところ、あれよあれよという間に参加者が集まって第一回のカーネル読書会が開催されたのである。

前半の勉強会形式のディスカッション、後半の宴会という黄金のパターンも第一回で確立された伝統芸みたいなものである。

当初は結構地味にソースコードを追っていたのであるが、何度もやるとさすがにあきるし、準備も大変なので、もちっとお気楽に行こうということで、お題提供者が適当にお題を披露する形式になった。

第8回から場所を渋谷マークシティのサンブリッジのセミナールームにうつしてそれが2001年末まで続き、その後天王町(保土が谷)OSDLジャパンの会議室で2004年にOSDLが引越すまでお世話になった。その後、固定した会場をもたない流浪の旅がはじまったのだが、NTTデータ、ミラクル・リナックス、日本SGI、日本HPなどおかりして開催し現在にいたる。
YLUG年表参照(http://www.ylug.jp/modules/pukiwiki/index.php?history)

時々出張か〜ねる読書会というのをやって新規参加者のリクルーティングをやっているのだが、なかなか思うように参加者が増えない。特に若い人と女子が少ないというのが構造的な問題だと認識している。やはり新規参加者が少ないとマンネリ化してしまうし刺激が少ない。

YLUG年表を見ると、よくもまあこんなにバラエティのあるお題を継続してやったなあと思う。発表者と参加者の皆様に心より感謝したいと思う。また会場を提供していただいた関係各位にも深く感謝したい。どうもありがとうございました。(ぺこり)

一つ一つの発表に思い出がつまっている。どれも大変楽しかったし、勉強になった。多くのことを学んだ。感謝につきない。そんなこんなで現在まで続いているのである。

と、ここまで書いていて、歴史を振り替えるところで力が尽きてしまって、「よしおかの野望」を記すまでには行かなかった。カーネル読書会のめざすところは次に記すことにする。(続く)

Community Based Development

オープンソースソフトウェア(OSS)の力はバザールモデルとして知られるコミュニティによる開発(Community Based Development)だと思う。

OSSの特徴としてフリーなライセンス(利用、変更、再配布の自由など)があげられる事が多いが、それはあくまで必要条件であって、十分条件ではない。ライセンスをフリーにしたからと言って、コミュニティが自然発生するとは限らない。商業ソフトウェアベンダは自社製品をプラットフォームとするために、あの手この手を使ってコミュニティを形成しようとするが、それには相当なコストと時間がかかる。

大雑把にソフトウェアを分類してみる。

最初のカテゴリは、プログラム。これは実行可能なソフトウェアで、趣味で作ったり学校の課題で作ったりする小規模なものとする。規模も小規模でせいぜい大きくても数千〜数万行程度のものである。おもちゃのプログラムに毛がはえた程度のものだ。もちろんサポートもなんにもないし、商業的な価値を見いだすことも難しい。

その次は、ソフトウェア製品。これは商用、非商用にかかわらず、ある程度のドキュメントと、利用者がついて、継続的に修正、改良されているソフトウェアである。製品というと商用のイメージがつきまとうが、他にいい名前を思いつかなかったので、とりあえずソフトウェア製品とここでは言うことにする。ブルックスはプログラミングシステム製品と呼んだが、わたしにはちょっとピンとこなかったので、ここではソフトウェア製品と呼ばせてもらう。非商用のソフトウェア製品というのが、ブルックスの時代(60〜70年代)には一般的ではなかったが、オープンソースの時代になって、星の数ほどでてきた。

最後は、ソフトウェアプラットフォーム(プラットフォームと略すことにする)。多くの利用者がつき、その上で重要なアプリケーションが稼働するようになる。あるいは、そのソフトウェアに依存するようなソフトウェアが多数生まれてくる。Linuxはまさにプラットフォームである。コンパイラのgccもプラットフォームと呼んでもさしつかえないと思う。商用製品で言えばデータベース管理システムのOracleもプラットフォームと呼べるだろう。そしてプラットフォームにはコミュニティの形成、存在が必要不可欠なのである。

上記の分類はあくまでざっくりとしたイメージで各カテゴリに明確な線引きがあるわけではない事をあらかじめお断わりしておく。

成功したOSSを見てみると、一人のプログラマの趣味からはじまったプログラムが、ある日誰かに発見され、利用が口コミで広がり、ドキュメントなどが整備されていって、それとともに、利用者、開発者コミュニティなどが自然発生的に生じ、ソフトウェア製品と言ってもいいほどになり、その後、そのソフトウェアを前提としたプログラムないしソフトウェア製品が次々と出てきて、商用サポートやトレーニングを提供する企業や、解説書の出版などがあいつぎ、プラットフォームの地位を確立するという発展をとげている。

Rubyというプログラミング言語を例にとると、93年にまつもとゆきひろ(Matzと呼ばれている)が自分の趣味で楽しいから自分用プログラムを作ったのが発端である。fjというインターネットのNewsシステムで発表され徐々にひろまっていったのが90年代後半である。最初のRubyの参考書が出版されたのが、99年で、英語の書籍は2000年である。2001年には初のRuby Conferenceが米国で開催され、2004年にはRuby on Railsという開発フレームワークが発表され、現在大ブレーク中という事である。

Rubyの開発は、当初はまつもとが一人で行なっていたが、徐々にメーリングリスト等でのバグの指摘、パッチの投稿など、まつもと以外の貢献の比率が増えてきて、より先進的な機能を実装するプログラマや、Sun MicrosystemsやMicrosoftに代表する大企業の開発者の参入など、開発者の層もひろがってきている。

Rubyはまつもとゆきひろが開発したソフトウェアであるが、徐々に彼以外の開発に関する影響力が増えているというのも事実である。

Rubyはプラットフォームと呼んでもさしつかえないだろう。プラットフォームには健全な開発者および利用者のコミュニティが存在する。

先日のRubyKaigi 2007キーノートスピーチ(感動的な素晴しいスピーチであった)でDave Thomasは、コミュニティが、その発展によってどのような影響を受けるか、そしてどのように対処するべきかということをユーモアを交じえて熱く語っていた。
http://jp.rubyist.net/RubyKaigi2007/Log0610-S5.html

Rubyは成長している。ティーンエイジのように気難しいが、親はその健全な成長を望んでいる。Rubyにはまつもとゆきひろ(Matz)とコミュニティというよい両親がいる。コミュニティは素晴しい。最近ではRubyはデートもしている。Rubyに迫りくる危機というのもある。爆発的な成長が新しい人を沢山呼ぶ。Rubyのお作法を理解していない人達もいっぱい来る。新しい人々を歓迎する準備をしよう。彼らから学ぼう。

愛に満ちたスピーチであった。成功したオープンソースソフトウェアはコミュニティに依存している。開発はコミュニティに依存している。新規参入者も排除されない懐の深さがある。分断の危機もあるが、それを乗り越えたコミュニティは強い。Rubyコミュニティはまさにそのような岐路にいる。

これは奇跡である。まつもとゆきひろという人間のパーソナリティがそれを可能にした。

Rubyはコミュニティによって開発されているというと、まつもとは相当違和感を持つかもしれないが、もはや彼の力の及ばないところで車輪が動きはじめているというのも事実なのである。彼が最も影響力のある人物である事は間違いないのだが、ティーンエイジのようにRubyは一人歩きをはじめて、その流れは、もはやまつもとですらコントロールできないところまで来ているのである。

コミュニティをコントロールする事は誰にもできない。しかし強い影響力を持つことができる。影響力はコミュニティに対する深い愛と貢献によって得られる。現時点で、最も影響力の大きいのは彼であるが、彼の右腕と呼べる何人かのハッカーが育ってきているのも事実ではある。

わたしはRubyの成長のプロセスを見て、かつてLinuxが発展していった姿に重ねあわせて見た。まつもとはLinusになる必要はないしなるべきではないとは思うが、linuxがたどってきた道はRubyのコミュニティにとっても大変参考になると思う。

RubyKaigi 2007には400人強の参加者があった。世界中から集まった。今後はSIベンダーやハードウェアベンダーのネクタイを締めたおじさんたちもいっぱい参加するようになるだろう。

Rubyのお作法、OSSのお作法を知らない傍若無人なやからも大挙することであろう。しかし、たとえそうであってもlinuxが上手に立ち回ったように、Rubyも上手にいなすと思う。

Community Based Developmentの奇跡である。ビジネスパーソンはこの価値の創造メカニズム、ソフトウェア開発方法論について理解を深めた方がいいと思う。わたしのミッションは、彼らにCommunity Based Developmentの革新性、有効性、持続可能性についてを伝えて、この波に参加することが彼らのビジネス(経済的な利益)にも繋がりうるということを理解させることである。

コミュニティは新しい人達の参入を歓迎することによって、さらに学び発展する。

愛だよ、愛。


6年前、アメリカでfirst Ruby Conferenceで私が受けたStanding Ovationを今年は日本でDave Thomasに返すことができてとても良かった、という話。

こういう話を聞くにつれ、Daveのキーノートは本当に感動的だったんだなあ、と思う。ただ単に「面白い話」では、人の心は動かない。彼が真摯に愛について語ったからに違いない。

Matzにっき


日曜のDave Thomasの講演の時に総立ちになったとき、思い起こしたのはもちろんあの日のことでした。Dave Thomasへのstanding ovationは、6年の歳月を経て、海外のRubyistからもらった賛辞に対しての、日本のRubyistからのお返しを象徴するものだと思います。2001年は40〜50人くらいだったように記憶していますが、2007年は約400人もの参加者がいました。ほぼ10倍です。ここまで大きくなったのは、6年もの間、まつもとさんと内外のRubyistたちが行ってきた努力や貢献の賜物以外の何物でもないでしょう。海外への普及の最重要人物であるDave Thomas氏に対し、残念ながら(とてもとても残念ながら)同席できなかったまつもとさんに代わり、盛大な拍手を返すことができたのは、Ruby communityにとって非常に意味のあることだったと思います。

6年後のStanding ovation/思っているよりもずっとずっと人生は短い。

長寿企業大国にっぽん

NHKスペシャル「長寿企業大国にっぽん」というのをやっていた。

100年を越える歴史を持つ長寿企業が日本には数万社あるそうだ。日本はなんと「長寿企業大国」なのである。

研究者たちの調査によれば、「決して“本業”をはずれない」「世の中が変わったら、“本業”からはずれない中で、社会のニーズに合わせていく」「危機は何十年かに一度襲ってくるもの。そこから逃げずに企業そのものを変革する」という共通の特徴があるらしい。

本業をはずれない。原点回帰というのが一つのテーマなのかもしれない。

金剛組の創業は1400年前にさかのぼるそうだが、宮大工がその伝統をうけついでいる。一時期マンション建設やコンクリート建設に業態を変えようとしたが、うまくいかなかった。木造を徹底的につきつめていくとコンクリート建設よりも長く利用できる建築物にたどりつく。確かに日本には何百年も前に建てられた木造建築物がいっぱいあるがそれを作ってきたのが金剛組のような宮大工の集団だったわけだ。その良さが最近見直されている。木造建築の知恵の結集が宮大工によって伝統として継承されている。彼等の仕事は文化資産である。

そこには普遍的な価値がある。仕事の価値があるのである。

次の10年

梅田望夫「サバイバルという言葉が嫌いなら使わないで話そうか」(My Life Between Silicon Valley and Japan)が、なかなか刺激的な事を言う。

「次の十年」、いまの大学生が三十代に入る頃、さらに加速した変化が「仕事をめぐる世界」「職業をめぐる世界」に起きているだろう。いまは「そういう時代なんだ」ということを認識して「緊張感を持って生きる」ってどういうことかを考えてほしいな。

わたしは、若い人に向かって、「〜してほしい」とか「〜すべきだ」なんてことは決して言わない。言うつもりもない。ましてや、「その「異常な事態」を誰かのせいにして何もしない言い訳にして今日を明日をのんびり無為に過ごしたら、そしてそれを続けたら、十年たって本当に後悔すると思うよ」なんて事も言わない。

人の人生である。一人一人の人生である。彼らから直に聞かれたら、何がしかを答えるかもしれない。実際約10年前にそんなことを若いプログラマ志望に答えたことを思いだした。

長くなるが、転載する。1998年4月12日のシリコンバレー日記だ。

-------------------------
プログラマになるということ

呑み会での席の話だ.

わたしは単なるヨッパライのおやぢである.へらへら酒を呑んでいたら隣に座っていた若いプログラマ志望者がわたしに聞いた.

プログラマってどんな仕事ですか?

一気に酔いが覚める気がしたが,それでもへらへらしながら,随分難しいことを聞くねえとか答えた.プログラマってどんな仕事なんだろうか?なんのために好き好んでこんな仕事をしているのだろうか?なんでまたプログラマの仕事なんかはじめたのだろうか?自分で自分に聞いてみる.よく分からない.

わたしは聞いた.

きみはプログラムを作る事が好きか?

はい好きですとその若者が答えた.

でもわたしにできるかどうか自信がないんです.とその若者は続けた.

きみは何をしたいんだ?

それがよくわからないんです.

わたしも20代のころは何をしたいかなんてわかっていなかった.いまですら何をしたいかなんか正確には答えられたためしがない.誰だってそうだ.自分がプログラマに向いているか向いていないかなんて正確に分かるわけがない.向いているか向いていないかではなくて,プログラマをしたいかしたくないかではないのか?プログラムを書く事が好きか嫌いかなのではないだろうか?プログラムを書く事が好きでそれを職業にしたければすればいい.おぢさんにはそのくらいのことしか言えはしない.

プログラマになるにはなにをしたらいいんですか?

若者の質問は続いた.国家資格があってその免許を持っていないとつけないとかいう医師とか弁護士とかそーゆー職業でない事だけはたしかだ.プログラマはプログラマである.

Cという言語を覚えればいいのか?それともC++か,あるいはJavaという言語か?もちろんそんなことはどうでもいい事だ.

わたしは若者に言った.プログラムをたくさん読む事だ.人に負けないくらいいっぱい読む事だ.いいプログラマはいいプログラムをいっぱい読んでいる.

きみが小説家になろうとしていたら,人の作品を読んで読んで読みまくるはづだ.映画監督になりたかったら,映画を見て見てみまくるはづだ.どうして人のプログラムを読まずにそれ以上いい作品を作れると言うのだ.ちまたにはフリーのいいプログラムがソースコードごとごまんと転がっているではないか?なぜそれを読まない.読んで読んで読みまくるんだ.

それを楽しめるか?それを好きでやれるか?やれるんだったらそれを10年続けてみる.そうしたら一人前のプログラマになっているだろう.読みつづける事だ.それがひょっとしたらいいプログラマになるコツかもしれない,などと偉そうにヨッパライのおぢさんは,へらへら笑いながらその若者に言ったのだった.

サンフランシスコの大学でコンピュータサイエンスを学ぶその若者がおぢさんの戯言に同意したのかしなかったのかはわたしは知らない.しかしプログラムを読まないいいプログラマはいないと言う事だけは確かだと思っている.

---------------
シリコンバレー日記、(ブラウザの文字コードをshift_jisにしてお読みください)
http://web.archive.org/web/20010530084301/www.best.com/~yoshioka/d/98/i980412.html

結局のところ、人は自分の人生しか歩めない。約10年前、若手プログラマ志望者に言った言葉は、自分に向けて言った言葉だ。わたしの信念として、プログラマになりたければプログラムの良い読み手になれと言う言葉は自分に向けて放った言葉である。

10年たって、わたしは自分の人生の中で、プログラマとして十分な仕事ができたかというと、随分寄り道をしているような気がする。会社を起して、コミュニティにコミットして、随分寄り道をしているような気がする。だけど、プログラマとしての成りたい自分は、10年前とそれほど変っていない。

変らない自分と変った自分。10年という時間は長いようでいて実は短かい。

コードには力がある。世界を変える力がある。(未来のいつか/hyoshiokの日記)
http://d.hatena.ne.jp/hyoshiok/20060621#p1

NDD (Nomikai Driven Development)

昨日、日本SGIソリューション・キュービック・フォーラムのOSS/Linux パネルディスカッション−第4回目『OSSはビジネスの道具。もっとクリエイティブな作業を 』に参加した。

モデレータの高澤さんとは旧OSDL時代からのおつきあいで彼の要請であれば出ないわけにはいかない。カーネル読書会の会場にSGIホール(恵比寿)をお借りしているのでおなじみの方も多いと思う。

さて、自己紹介のあと、日本のIT産業が学生や若い人に人気のない3K職種じゃないかという刺激的な横河フィールドエンジニアリングサービス株式会社の丸茂さんのお話から口火を切ったのだが、とりあえづそれを受けてのわたしのお話が下記のNDDだ。

わたしは、カーネル読書会とかいろいろな勉強会で若いWeb2.0系にお勤めの人とお話をする機会があるのですが、彼らは本当に仕事が好きで、毎週金曜日に飲み会かなんかをよくやるそうで、そうすると仕事が好きなものだから、仕事の話になっちゃって、朝までブレーンストーミングみたいな感じになるそうです(若いから朝までオールでもへいちゃら)。そんでもって、いいアイデアかなんか出ると(飲み会の時は自分は天才じゃないかなんてよく思うもんなあ)、そのまま会社に戻って、土日つぶしてちゃかちゃかプロトタイプ作って月曜日にデリバーですよ。アイデアから実装まで数日。まあ、飲み会ドリブンデベロップメント(NDD)ですね。

一方で従来型の開発だと要求定義に半年、実装に半年、テストに半年とか、そーゆー単位で、今回の開発は速くて数ヶ月だったなんていく感じです。経験というのは何回そのサイクルを回したかできいてくるので、2週間で一回経験値を積むのと2年で経験値を積むのでは、その学習曲線の立ち上がりが全然違う。

さらに言えば、mixiなんてのはバタラさんが一人で自分のPCでプロトタイプ作って、会社の人に見せて、10人ユーザで、そのユーザが友達招待して100人で、その次1000人で、1万人、10万人、2年半で500万人ですよ。つい最近1000万人突破っていうプレスがでてましたけど、3年で1人から1000万倍スケールしちゃったわけです。1000万ユーザの基幹システムというのはあるけど、ユーザが10倍になるというのを設計時点で作りこんでいるというのはほとんどない。開発の方法論がまったく違う。mixiはミッションクリティカルシステムではないけど、そーゆーシステムの作りかたが従来のSI現場とは違うところでおこっている。

先週末RubyKaigi2007というのがあって、プログラミング言語のRubyというのがあって、まつもとゆきひろさんという人が一人で作ったんだけど、その会議に400人参加していて、情報を交換している。オープンソースの場合、技術情報というのは社内にあるのではなく、社外にある。自分の問題と同じ問題を持っている人は社内にいるのではなく社外にいて、そーゆー人たちとカジュアルに気楽に情報交換をして教えあっている。コミュニティベースで開発して助けあっている。そーゆー勉強会がいたるところにあって、情報共有をWeb2.0系の人たちは自然にやっている。

その人達の学習曲線は驚異的で一年もたてば、その道のエキスパートになっている。そーゆー世界がいまここにあるのだけど、なかなか大手企業の偉い人たちには、彼等のレーダにはそーゆー世界の話がうつっていない。

わたしが言うとすぐに大企業批判みたいに受けとられちゃうけど、そうではなくて、聞いたこともないちっちゃな会社と大手企業のコラボレーションができたらおもしろいなあと。

日本という地域でもっともっとコミュニティーベースの開発というのを根付かせたい。企業の壁をのりこえた開発の素晴しさ。それば企業にとってもビジネスになるし、利益にもなるということをもっと訴えたい。

というようなヨタ話(記憶にもとづいて書いているので相当脚色構成あり)をかましたのだけど、伝わっただろうか。

パネルで話したエピソードのまとめ。(順不同)

従業員意識調査のはなし。(人手が足りないという状況と、会社をもっともっと良くするために貢献したいというモチベーションの高い従業員)
人材/ユメのチカラ

http://blog.miraclelinux.com/yume/2007/01/post_6962.html

mixiのスケーラビリティのお話。(たくさんブックマークされている(58個))
500万倍のスケーラビリティ/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/07/post_7ad0.html

mixiのスケーラビリティをささえるアーキテクチャ。
LiveJournalのアーキテクチャ/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/07/livejournal_a718.html

金曜日の飲み会でアイデアを得て土日開発し月曜日に公開するという、おじさんには理解不能なスタイル。
Web2.0時代のソフトウェア開発のスピード/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/web20_5b1a.html

国内OSベンダーでISO/IEC 15408を取得しているのは弊社だけ。歯を食いしばってもOSを作らないといけない。
ISO/IEC 15408の取得/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/02/isoiec_15408_6bd3.html

ISO/IEC15408認証を取得しました/アジアのペンギン
http://blog.miraclelinux.com/asianpen/2007/02/isoiec_15408_e90c.html

Linux Kernel 2.6.20を開発した人の所属はどこかを調べた記事の紹介。それによると日本の企業でリストにはいっているのはMiracle Linux1社だけで、18位であった。
Who wrote 2.6.20? 誰がlinux 2.6.20を書いたのか?
http://blog.miraclelinux.com/yume/2007/06/who_wrote_2620__4b18.html

RubyKaigi 2007については下記
日本Ruby会議2007/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/ruby2007_cdaf.html

RejectKaigi2007/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/rejectkaigi2007.html

RejectKaigi2007

RubyKaigi 2007がおわって撤収作業中に、RubyKaigiでreject(採択にならなかった)ネタをあつめての一人2分半でのプレゼンテーションがRejectKaigi2007だ。2分半という時間は絶対で、ノートの設定用30秒も含めて、2分半たつと強制的に打ち切りで画面が切られる。

まとめページはTAKESAKOさんのページを参照。
http://labs.cybozu.co.jp/blog/takesako/2007/06/rejectkaigi2007.html

全部で19人、一人2分半の持ち時間でも結構しゃべれるのね、と思いました。

こんな素晴らしい発表をリジェクトするなんて、本家RubyKaigi2007のCFPの応募がいかに充実していたのか想像できます。むしろ、リジェクトしたことを後悔させるぐらいの意気込みだったのかも。発表者の皆さん、スタッフの皆さん、大変楽しい時間をありがとうございました&お疲れ様でした。

さてわたしの持ネタ(笑)のキャッシュミス。キャッシュミスを削減する方法というのは昔はいろいろ大変で素人にはなかなか手が出せなかったのだが、昨今はツールも充実しプロセッサの機能も豊富になってきたので、お手軽にためせるようになった。ハードウェアエンジニア(プロセッサのアーキテクト)でなくても、各種ツールでキャッシュミスを測定できる。linuxだったらoprofileだ。

さて、発表した持ネタは下記のブログを再構成したものである。時系列でまとめるので、参考にしてほしい。

そもそものきっかけは、カーネル読書会で小崎さんがmallocのお話をして、そのとき、ささださんがGCでの動作の質問をして、ふとキャッシュミス測定してみたら面白いんじゃないと思ったのがはじまりである。

その時のビデオも公開しているので参考にしてほしい。質問が聞きとりにくいとか、いろいろ限界もあるのだけど、雰囲気だけでも感じとってね。

今回もmalloc/freeのコストについてRubyの笹田さんがRubyでのメモリ管理の観点から細かい突込みを入れていたが、OSとアプリケーション(この場合はプログラミング言語の実装)の境界を越えて、いろいろ議論できるのが楽しい。

第67回カーネル読書会、ビデオ公開
http://blog.miraclelinux.com/yume/2006/09/67_8c37.html

まづ手始めに自分のノートで測定してみた。ノートPCなので、acpi関係のロードが大きい。

Rubyのプロファイリング (ユメのチカラ)
http://blog.miraclelinux.com/yume/2006/10/ruby_0b0e.html

そこで会社のXeonで測定してみたのが下記。os_each_obj にキャッシュミスを多発している部分を発見する。

ソースとoprofileの結果をつきあわせてみて特定した。
  for (;p < pend; p++) {
      if (p->as.basic.flags) { /* ここの部分 */
  ...
というコードなので、prefetchでいけるだろうと考えた。

Rubyのキャッシュミスを測定する。(未来のいつか/hyoshiokの日記)
http://d.hatena.ne.jp/hyoshiok/20061002#p2

でquick and dirty hackが
        for (;p < pend; p++) {
+         if ( (p+1) < pend) {
+               __asm__ __volatile__ (
+                  " prefetch (%0)\n"
+                  : : "r" ((p+1)->as.basic.flags) );
+           }
みたいなパッチになる。

L1 キャッシュミスを約41.8%削減した。実行スピードにはほとんど影響をあたえなかったが(とほほ)。

Cache Aware Ruby Patch (未来のいつか/hyoshiokの日記)
http://d.hatena.ne.jp/hyoshiok/20061003#p1

最後に上記の実験で得た知見をまとめたのが、「コードを読むな、理解しろ」である。

コードを読むな、理解しろ (ユメのチカラ)
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html

詳細は「コードを読むな、理解しろ」を参照していただくとして、キャッシュミスの削減という従来であれば「深い技術」が、オープンソースと各種ツールの整備のおかげで、いとも簡単に実装実験できる「浅い技術」までおりてきたのである。

わたしが実施しお見せしたような事が、このブログを見ているキャッシュミス削減なんか考えたこともないプログラマや、あるいはベテランなんだけどもオープンソースに土地勘のないプログラマにも再現可能な事として誰でも実施できるようになったのである。

研究のコモディティ化(?)である。こんなに楽しいことを大学や企業の研究室の中だけで閉じこめておくのはもったいない。

カーネル読書会というオープンソースのコミュニティの議論をきっかけにあたらしい知見が生みだされたという実例なのである。つくづく恐しい時代になったものだなあ(笑)

RejectKaigi2007に参加して、そんなことを思ったのだけど2分半のプレゼンには全然もりこめていない。

発表資料は下記。
http://blog.miraclelinux.com/yume/files/rubykaigi070610.pdf

Happy Hacking!

Asianux Server 3 β版レビューキャンペーンと、よしおか賞

Asianux Server 3 β版レビューキャンペーンだ。いまさらβ版でもなかろう。いまさらレビューキャンペーンでもなかろう。そう考えているあなた。ちょっとまった。単なる未承諾広告としてスキップしないでほしい。お願い(ぺこり)。
http://www.miraclelinux.com/products/linux/axs3/campaign.html

結果をフィードバックしていただいた人の中から、わたしの独断と偏見で「よしおか賞」を贈呈したい。世界で「よしおか賞」と名がつくものはこれだけである。(だからどーだというツッコミは却下)

芥川賞は知っていても「よしおか賞」は知らない。そーゆー知名度のなさにも相の手を(よーぽんっ)ではなく、愛の手を(むむむ、さむい)

賞品も用意した。
ベストよしおか賞:1名様 デジタルハイビジョンレコーダー。
よしおか賞:5名様 iPod nano(2G)
ここだけの話。自分が欲しい。

今なら倍率も低いので(うーん寒い)、ゲットできる確率は宝くじを買うより遥かに高い。

まあ、Web1.0的なキャンペーンだと思わなくもないが、それでもやらないよりは全然いい。仕事でやって、賞品ゲットというのも、勤務先がOKするのなら弊社としては歓迎である。

ゆくゆくはβ版のレビューだけではなく、Asianuxの開発そのものをバザールモデルのようにオープンにできるようになったらウレシイのだけど、それにはもうすこし時間がかかるかもしれない。

評価の申込ページも用意したので、今すぐクリックだ。
https://www.miraclelinux.com/products/linux/axs3/entry.php

おねがいします(ぺこり)

ほめる技術

先日弊社でコミュニケーション研修というのがあった。「ほめ言葉ハンドブック」著者の祐川京子さんを向かえての講習であった。

この研修のきっかけは、児玉さんのブログにもあるように、彼が「ほめ言葉ハンドブック」を読んで、それが面白かったものだから、直接祐川京子さんに連絡をして研修をお願いしたという突撃スタイルなんだけど、その行動力さすがである。見習わなければならない。

言われて嬉しいほめ言葉を5分で30個リストアップするというワークショップがあるのだけど結構これが難しい。自分が言われて嬉しい言葉は10個くらいはすぐでるかと思うのだが、それを20個30個リストアップするというのは大変だ。ほめ言葉のボキャブラリが貧困であるということはそれだけ人を誉めていないということにも繋がる。

ワークショップでは30個リストアップした先着4名様には祐川京子さんの「ほめ言葉ハンドブック」を贈呈というニンジンがぶらさがったものだからガチンコ勝負をしてどうにか3番目でゲット。

日頃使っていない脳の部分を使ったという感覚の一日であった。

なお祐川京子さんはとってもチャーミングですごいエネルギッシュな人だった。

誉める言葉とアファメーション/烏龍の旅
http://blog.miraclelinux.com/asianux/2007/06/post_d19d.html

日本Ruby会議2007

行ってきましたよ。Rubyの祭典。日本Ruby会議2007。400以上のRubyistが集まりましたよ。御茶の水に。Rubykaigi070610_17150001

2007年6月9日(土)、10日(日)という土日を2日間つぶすという会社員にとっては、それはそれなりに厳しいスケジュールであるが、仕事というよりも、ファンの集いみたいなものだから、這ってでも参加しないといけない。前日飲み過ぎだとしても。





Rubykaigi070611_07240001

それはともかく、参加記念のRuby会議公式トートバックをもらってうきうき、初日ささださんのRuby 1.9のお話などから聞く。ささださんの開発版(1.9)と卜部さんの安定版(1.8)それぞれのメンテナのお話はコードを書いてメンテナンスする人のご苦労がしのばれた。いろいろ大変なんだろうなあと。青木さんのリファレンス・マニュアルのお話も量的な問題があり、相当大変だというのはよくわかった。JRubyはSunがRubyの実装をするとこうなるよという話で、企業とコミュニティとのアライアンスという意味でのヒントがいくつかあったような気がする。

まつもとさんの基調講演はいつもどおりの愛に満ちたもので、会場を笑いの渦にまきこみつつ未来に対する楽観的な方向性をしめしていた。会場の400人は彼のファンだから何を言っても許されると思うのだけど、観客を驚かせるような発表はなかった(笑)。Railsで仕事をしている人という会場への問いは2〜3割の人が手をあげていたので、昨今のRailsブレークを象徴しているようで興味深かった。

Railsでお仕事とかRubyでお仕事などというのはほんの2〜3年前には考えられなかったので、世の中変われば変わるものである。(Railsが3年前にあったかというツッコミは却下)

SunのJRubyをはじめとしてエンタープライズRubyというキーワードがそこかしこにでてきたのも今年の特徴かもしれない。昔、わたしの脳内プロジェクト(単なる妄想のこと)で、Rubyのスケーラビリティをがしがしやって大規模SMPマシンで動かすんですよ、それをEnterprise Rubyプロジェクトっていうんですが、どーですかね?みたいなことを飲み会でまつもとさんに言ったのだが、当時は冗談みたいなものであったが、昨今では半分マジな感じになりつつあり、世の中わからないものである。

そのうち、Ruby World Expo/Tokyoなんてのがお台場ビッグサイトで開催されちゃったりするのだろうか。スーツを着たおじさんたちが、わらわら疲れた顔をして参加しちゃったりするのだろうか。エンタープライズ・ルビーの戦略とかいうパネルディスカッションに大手ハードウェアベンダーの部長さんとかSIベンダーの役員が難しい顔をして自社製品の宣伝なんかをしちゃうのだろうか。とかいう妄想もあながちありえなくないという予感もあったりして。(あんまり面白くなさそうだけど)

会場ではRuby関連本の展示即売会をやっていて、世の中にこんなにRuby本があるとはとびっくりした次第である。

司会の鈴木さんのゆっくりめの進行もラブリーであったが、会場には女性の少なからずいて、Ruby女子率高いなあと思った次第である。やはりWeb2.0系の職場には女性が多いのだろうか。女子カーネルハッカーを発掘したいと強く思った。

懇親会はチケットを入手していなかったので不参加であった(残念)。

二日目。

仕事系やスポンサーセッションなど今後の「Rubyでメシを食う」方面としては参考になった。楽天とかニフティなどの大手ベンダがどうコミュニティとアライアンスを組んでいくのか、その距離感をどうとっていくのかなど興味はつきない。担当のがんばりだけではどうしようもない壁というのがあるのではないだろうか、そんな感想を持った次第である。その点、ドリコムとかベンチャーの方が顔が見える分圧倒的(?)に有利である。

ビジュアル系セッションで注目の「モテるRuby!Rubyで画像編集のあの手この手」舘野さん。Rubyでモテるようになるにはというテーマ(?)でがんばってこられた。暖かく見守りたい。

最後の基調講演、Dave ThomasはコミュニティとRubyの関係についての議論は感動的ですらあった。RubyはMatzが作ったもので、皆がそれを愛し、はぐくみ、ティーンエイジャーのように手間がかかって難しいけど健全に成長することを望んでいる。どきどきしながら見守っている。

その後Reject会議という採択されなかったアイデアを2分半で発表するLightning Talksのさらにlight版がもたれた。rubykaigi070610.pdfをダウンロード

会場では、チケットをゲットする情報を教えてくれたKanasansoftさんにお目にかかれることができた。その節はどうもありがとうございました。あなたのおかげです。(奇跡である)(下記参照http://blog.miraclelinux.com/yume/2007/04/ruby_7488.html#comment-1037686)

最後に、今回の日本Ruby会議を運営してくれた全ての皆様に感謝を申しあげたい。素晴しい会議であった。実行委員会の皆様、ボランティアの皆様、発表者の皆様、参加者の皆様、そしてRubyの父、まつもとゆきひろさんに感謝を。素敵な会議でした。どうもありがとう。

日本Ruby会議
http://jp.rubyist.net/RubyKaigi2007/
http://jp.rubyist.net/RubyKaigi2007/TrackBack.html

Rubyって何よ/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/ruby_86e4.html

日本Ruby会議(チケットゲットして狂喜乱舞)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/ruby_7488_1.html

日本Ruby会議(チケットゲットできづ枕を涙でぬらす)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/ruby_7488.html

BITS2007

恒例のパネルディスカッションに参加した。メインフレーマーの経験、知恵とオープンソースとの融合などが課題となる。

メインフレームの時代には、ハードウェア、OS、ミドルウェア、SI、すべて一社で供給していた。オープンシステムの時代になって、それぞれ別々のベンダーから調達し、SIベンダーが供給するようになった。各コンポーネントは標準化されていて(デファクト標準)、価格競争力がないと競合に置き換えられてしまう。その結果、メインフレーム時代に比較して、リーズナブルな価格になった。

問題はそのように作られたシステムでなんらかのトラブルが発生した場合である。プロプライエタリな製品で構築されていると、その製品にトラブルが発生するとSIベンダーには手も足もでない。垂直統合型(メインフレームの時代)の場合、自社ですべての製品を提供しているので、OSだろうがミドルウェアだろうが、トラブってもどうにかするのである。

そのような何が何でもどうにかするというのがメインフレームの信頼感、安心感を支えていた。オープンシステムの時代には一歩後退してしまった部分である。

そこでオープンソースの時代である。ソースコードがあるので、SI事業者、あるいはサービスプロバイダが、技術力さえあれば、とことんサポートできるのである。OSカーネルのサポート、RDBMSのサポート等々とことんがっつりいけるのである。

さらに言えば、メインフレーム時代に培われた信頼性向上の方法論、技術、あるいはその根底にある技術的な思想などをOSSの世界に投入することが差別化要因になりうるのである。そのような期待感をわたしは持つ。メインフレームのパラダイムで生きてきた技術者とOSSの技術者のシナジー効果を期待したい。

強くそのように思ったパネルディスカッションであった。

ムーアの法則を理解すること(その2)

アーキテクチャの設計寿命でもふれたが、Alpha AXPのアーキテクチャの設計ゴールは下記のとおりであった。
http://blog.miraclelinux.com/yume/2007/02/post_e9f1.html

   1. 高性能
   2. 寿命が長い事
   3. VMSとUnixが動くこと
   4. VAXおよびMIPSからの容易なマイグレーション

1と2については達成されたと考えていいだろう。3および4はDECが当時おかれていた状況から考えてまっとうな設計要求である。しかし、このゴールはDECという会社が消失してしまった以上達成はかなわなかった。

高性能のアーキテクチャを設計することは緻密なエンジニアリングを行っていれば、(もちろん簡単ではないが)達成不可能ではない。むしろ容易な範疇にある。

本当に難しいゴールと言うのは、マーケットに求められているものをタイムリーに提供し市場で受け入れられることである。こればっかりはエンジニアリングチームばかりではどうしようもない。マーケティング、営業、サポート、等々全社的な活動となる。企業の総合力が問われているのである。

世界で最高速のマイクロプロセッサを作っても売れなければなんの価値もないのである。こう言ってしまうと身も蓋もないが市場経済というものはそういうことである。

世の中で最も利用されているマイクロプロセッサのアーキテクチャはIA32である。命令セットに直交性がなかったり、CISCの典型的なアーキテクチャではあるが、互換性をキープしながら性能向上を図ってきた。

IA32の性能向上のアイデアは先行した多くのRISCマシンに見られるがそれを集大成しバイナリコンパチビリティをかたくなまでに守ってきた。

64ビット拡張ではIntel IA64があるが、Alpha同様、以前のアーキテクチャ(この場合はIA32)と互換性がない。今にいたるまでIA64の市場は広がっていない。

世界最大のマイクロプロセッサベンダであるIntelの力をもってすらアーキテクチャの移行というのは容易ではないのである。

マイクロプロセッサの命は命令セットであり、それを変更することはソフトウェアの重さから考えて容易ではない。結局、『増加したトランジスタ(向上した集積度)をどう使うか』という問題に対する回答は、互換性の維持に使われる、といういささかユメのないことになるのである。

多くのコンピュータアーキテクトがこの問題にチャレンジして、屍の山を築いてきた。汎用プロセッサのエリアでは、互換性が最も重要な設計ゴールとなっているのである。

このゲームのルールを変えるには勝負する土俵を変える必要があってゲームや携帯などの組み込み系から攻めていくというのが当面の流れかと思う。

一方でオープンソースがソフトウェアの重さ(膨大なソフトウェア資産の慣性)を軽くすることができるのだろうか?新しいチャレンジがそこにはあるような気がする。

ムーアの法則を十分理解した上での新しいソフトウェア設計、製造、保守のモデルとしてのバザールモデルへの熱い期待である。

ムーアの法則を理解すること/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/post_e653.html

ムーアの法則を理解すること

Matzにっき (2007-05-30)
インテル:「ソフトウェアもムーアの法則に従う必要がある」 - CNET Japan
http://www.rubyist.net/~matz/20070530.html#p07

「今まではハードがどんどん高速化してきたので、ソフトウェアの皆さんは(マシンのアップグレードで)自動的に性能向上を享受できていましたが、これからは諸般の事情でそういうことはできなくなります。ソフトウェアの皆さんもご協力を」という話。

っていうか、最初からそういう風に言ってほしいものだ。

このブログの読者ならご存知かと思うが、わたしは昔DEC (Digital Equipment Corporation)という会社に勤務していた。わたしがエンジニアリングのイロハを習った会社である。VAXそしてAlpha AXPというコンピュータ史に残るアーキテクチャを開発した会社でも知られている(若い人は知らないかもしれないけれど)。商業的にはその後コンパックに売却され、コンパックはHPに売却され今はその名はない。

さて、そこでソフトウェアエンジニアとしてのキャリアを積んでいったのであるが、そのエンジニアリングコミュニティは間違いなくムーアの法則をコミュニティとして理解していた。(マルチプロセッサ向けソフトウェアパラダイムとは、マルチプロセッサ向けソフトウェアパラダイムとは?(その2)を参照のこと)

Alphaの開発チームはVAX開発チームの後継で、ある意味DNAを受けついでいるのだが、当時の論文(90年ごろ)で、マイクロプロセッサのスケーラ ビリティを、クロックの向上で10倍、アーキテクチャの進歩で10倍、マルチプロセッサで10倍、10x10x10=1000倍の性能向上を達成するとか しないとか書いてあって、感心したのを覚えている。

http://blog.miraclelinux.com/yume/2007/01/post_ab8c.html


アーキテクチャの設計寿命で紹介した論文をふたたび引用する。1992年の論文であることに注意されたい。
Alpha AXP Architecture
by Richard L. Sites

http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art1.pdf

The remaining factor of 10 will come from multiple processors. A single
system will contain perhaps ten processors and share memory. We therefore
designed a multiprocessor memory model and matching instructions
from the beginning. This early accommodation for multiple processors
also distinguishes the Alpha AXP architecture from many other RISC
architectures, which try to add the proper primitives later.

今後15年から25年のレンジで性能向上をはかるためにクロックレートで10倍、それ以外の設計要素(投機的な実行、Out of Order、スーパーパイプライン、スーパースケラー等々)で10倍、そして残りはマルチプロセッサ技術で10倍、合計10*10*10=1000倍のスケーラビリティを確保する、という事である。

この論文が発表されたのは92年でAlpha AXPの開発が開始されたのは88年あたりだからAlpha AXPチームは約20年前には、間違いなく今後の性能向上にはマルチプロセッサの技術が必要になるというビジョンを持っていた。

商用OSはSMP性能でのボトルネックを発見し修正するという地味な作業を延々おこなってきたし、ミドルウエア(RDBMSなど)もSMPでの性能向上に力をそそいできた。今後も益々SMPの重要性は増すであろう。

そして、ソフトウェアコミュニティでも、それを理解する必要がどんどん増しているのである。

つい最近までハードウェアの性能向上にあぐらをかいてソフトウェア側の性能向上の努力というのはほとんどなかった(というのは言いすぎかもしれないけれど)。汎用的な性能向上という点から言うと進歩はゆっくりしていると言っても過言ではない。

ムーアの法則をもう一度よく理解する必要がある。

そして、もう一つ重要な点、増加したトランジスタ(向上した集積度)をどう使うかについては、後に記す(かもしれない)。

インテル:「ソフトウェアもムーアの法則に従う必要がある」
http://japan.cnet.com/news/biz/story/0,2000056020,20349605,00.htm

アーキテクチャの設計寿命/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/02/post_e9f1.html

マルチプロセッサ向けのソフトウェアパラダイムとは/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/01/post_ab8c.html

マルチプロセッサ向けソフトウェアパラダイムとは?(その2)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/01/post_95e7.html

マルチプロセッサとマイクロカーネル/ひら
http://d.hatena.ne.jp/hira_sosuke/20070604/1180968495

Who wrote 2.6.20? 誰がlinux 2.6.20を書いたのか?

http://lwn.net/Articles/222773/

先週のカーネル読書会でGreg KHがLinux Kernel開発コミュニティのお話をしていて、その中で開発の量的な側面についていろいろ紹介していた。そのスクリプトを眺めていたら、元ネタは、Jonathan Corbetという人が書いた「Who wrote 2.6.20」というLWNの記事ということをREADMEファイルから発見した。そこで早速Googleしてみた。それが上のリンク。

その記事はざっくり言うと、Linux Kernel 2.6.20を誰が開発し、その人はどこの会社に雇用されているかというのをgit(Linuxのコード管理システム)のログから定量的に解析したものである。

Linuxは多くのボランティアの自発的な貢献によって開発されていると良く言われているが、それがどのくらい正しいのか、そうでないのかを検証している。

2.6.19から2.6.20への変更を調査した。それによると4983の変更が741人の開発者によってなされている。286,439行追加され、159,812行削除され、その結果126,627行増えたことになる。

開発者ごとのうちわけは、Al Viro 241回(4.8%)を筆頭に、以下、Andrew Morton 92(1.8%)、Jiri Slaby 92(1.8%)と続く。20位まで出ているが、20位は美田さんで43回(0.9%)である。上位20人で全体の28%コードを貢献している。

コードの量で計測すると若干ことなる順位になる。回数は少ないが大量のコードの変更をしている場合があるからである。Jeff Garzik 20712行(6.0%)でトップ、日本人は佐藤嘉則さんが13位で5232行(1.5%)である。

削除した量の順位もあって、Jeff Garzik 19862行(12.4%)で、日本人は6位の根本さんで1425行(0.9%)である。

投稿されたパッチは、メンテナーのsigned-offによって受けいれられる。ピアレビューをした人という事である。その順位はAndrew Morton 1422回(13.7%)、Linus Torvalds 1366回(13.2%)、David S. Miller 483回(4.7%)となる。先日カーネル読書会に飛び入り参加してくれたGreg Kroah-Hartmanは269回(2.6%)で第5位である。

多くのパッチはサブシステムのメンテナのレビューだけで直接Linusの管理するメインツリーにマージしていることになる。すくなくてもLinusはsigned-offしていないので、そのパッチのメインのレビューアではないと言える。

誰が開発者を雇用しているか?

電子メールのアドレスを元に所属している会社を計測した。例えばメールアドレスがibm.comであればIBMの社員と考えた。それによると、不明 1244 (25.0%)、 Red Hat 636 (12.8%)、 なし 383 (7.7%)、 IBM 368 (7.4%)、 Novell 295 (5.9%)、以下 Linux Foundation/Intel/Oracle/Google、日本企業はMiracle Linuxの18位で43 (0.9%)である。不明というのは、所属企業が不明だったもの、なしというのは純粋に自分の時間を利用して開発していたと思われるものである。

65%のコードは企業に所属する人間が開発している。残りの部分(全体の約1/3)がボランティアによって開発されていた可能性がある。(多く見積もった場合)

下記には日本人のLinux hackerについてまとめたサイトがあるのであわせて紹介しておく。
http://wiki.livedoor.jp/linuxfs/d/Japanese%20Linux%20hacker

カーネル読書会/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/post_da8e.html

若者との会話

びぎねっと主催のオープンソースパーティ2007に参加した。今年は120人を越える参加者ということで、会場がごったがえしていたので、落ち着いて話をすることはなかなか難しかったが、それでも懐しい顔にいっぱいあえて楽しかった。前日はカーネル読書会だったので2日連続で会う人も少なくなかった。特にオープンドリームの皆様には、あ、どーも、とか言う感じであった。

入口近くには、びぎねっと勢が陣どっていて、Linux World Expo3日間の疲れかテンション低くまったりとしていた。

その一人大内さんとお話をする。まだ10代のハッカーである。はりぼてOSの会で、自分OSを作っている若者である。

はりぼてOSの会は、「30日でできる! OS自作入門」に触発されて自作のOSを作ろうという狂気(誉めています)の集団である。わたしみたいな人間はOSを自作しようなんていう発想にはまったくもってついていけないのであるが、若者はいとも簡単に、そーゆー事にチャレンジをしてしまう。「最近多いですよ、OS作る人」とか事もなげに大内さんは言うのだが、おじさんは、ひえ〜と退けぞるだけである。

いいなあ、元気があって。おじさんはエネルギーを貰ったよ。という感じである。

彼はまだ19歳なので、お酒は飲めないのだが、わたしは十分へべれけでいろいろ話を聞く。

最近のモチベーションというか、いろいろ聞くうちに、ちょっとしたヒントを言う。

自分がしたいことをリストにしてみる。すぐにできる事、すぐにできない事、簡単な事、難しい事、やりたい事、やりたくない事などなどともかくリストにしてみる。そして、それをやりたい順にソートして書き出してみる。

そのリストをわたしは見たい。そ