Rubyist インタビュー特別編 小崎資広さん 前編

はじめに

2013 年 11 月 8 日から 3 日間の日程で、アメリカはフロリダ州マイアミビーチにて RubyConf 2013 が開催されました (るびまにも参加レポートがあります)。

その際に Ruby と Linux カーネルのデュアルコミッタとして有名な小崎資広さん (現在はボストン近郊在住) が参加されており、編集部からも数名が RubyConf 2013 に参加していたこともあり、せっかくですので (いつもの Rubyist Hotlinks インタビューとは別企画の特別編として) インタビューさせていただきました。二日間にわたるインタビューとなりましたので、前後編に分けてお送りします。

では、お楽しみください。

プロフィール

好きな言葉

「夜明け前が一番暗い」「生きてるだけで儲けもの」

尊敬する人

漆原教授 (動物のお医者さん)、ヴェルナー・フォン・ブラウン

インタビュー

聞き手

卜部さん (@shyouhei)

語り手

小崎資広さん

野次馬

笹田さん (@koichisasada)、松田さん¹ (@a_matsuda)、中村さん (@nari3)、瀬尾さん (@sonots)、菅井さん (@hokkai7go)、三村さん (@takkanm)、郡司さん (@gunjisatoshi)

日にち

2013 年 11 月 9 日、11 月 10 日²

場所

RubyConf 2013 会場ホテル (Loews Miami Beach Hotel) の瀬尾さんの部屋

目次

• はじめに
• プロフィール
• インタビュー
  • 目次
  • プロフィール
    • 生年月日、出身地、家族構成
    • 好きな言葉、座右の銘
    • 尊敬する人物
  • 代表作
    • テレビの組み込みブラウザ
    • malloc の解説
    • Linux Kernel Watch
    • Ruby と Linux への貢献
  • Ruby に関して
    • Rubyist になったきっかけ
    • 好きなメソッドと嫌いなメソッド
    • 現在の Ruby とのつきあい方
    • Ruby を使って成功した事例
    • キラーアプリ
    • Ruby の習得は簡単でしたか？
  • プログラミング全般
    • Ruby 以外のプログラミング言語あるいはテストの話
    • レビューをするかチケット管理をするか
    • Linux 界隈と Ruby コミッター界隈の文化の違い
    • カーネルサミット
    • C 以外の言語は？
    • 文字列操作
    • ソースコードの行数
    • 美しいソースコード
    • テレビの規格
    • 今興味があること
    • GNU プロジェクトへの著作権の譲渡
• 途中で

プロフィール

生年月日、出身地、家族構成

:

卜部 本日はよろしくお願いします。最初にプロフィールを簡単に聞かせてください。

小崎 1975 年生まれ。出身地は愛知県で、現住所はボストン³郊外のマサチューセッツ、東海岸の北側ですね。ニューヨークからは飛行機で北東に 1 時間くらい、と言うとけっこう離れてるように聞こえるけど、向こうの感覚では近い。家族構成はシングルです。

好きな言葉、座右の銘

卜部 好きな言葉や座右の銘は？

小崎 「夜明け前が一番暗い」かな。しんどい時にその頑張りに意味がないと思ってしまうと、どんどん気持ちが下を向いてしまう性格だから。ポジティブシンキングというよりも、ネガティブから派生したポジティブという感じ。 あとは「まだ生きてる」とか気づいたらつぶやいてる。宗教的な意味はないけど、どうも生きてる事に意味を見いだす性格みたいです。気が抜けたときにふっと。あんまり意識していなかったけど、若い頃に知り合いがばんばん死ぬ時期があって、そういう影響だと思う。リアルはフラグもなしに人が死ぬからよくないよね。現実はクソゲー。

尊敬する人物

卜部 尊敬する人物は？

小崎 架空の人物だと、「動物のお医者さん」の漆原教授。傍若無人だけど周りからは好かれているという。自分の目標です。正反対な性分なので (笑)。実在の人物で真面目に答えると、ヴェルナー・フォン・ブラウン。V2 ロケットを作りたいとなるとナチスに身を売って実現させてしまう、ポリシーのない所がいいですね。

卜部 「目的のためなら手段を選ばない」？

小崎 「目的のためなら手段を選ばない」というよりも、むしろ「手段のためなら目的を選ばない」かな。ロケットを作りたい、でも何に使われるかはどうでもいい、というところが理系っぽいじゃないですか。

一同 (笑)

小崎 色々言われる人物だけれど、ちゃんと成果を出して月まで行ったんだからね。素晴らしい。

代表作

卜部 小崎さんの代表作は？

小崎 特にないかな。あんまりものを作ったりしないし。

テレビの組み込みブラウザ

小崎 会社での代表作は、パナソニックのテレビのブラウザですかね。組み込み系の。データ放送って 2000 年代くらいから提供されてるんですが、中身は XHTML なんです⁴。コンテンツは HTML なので、それを表示するレンダリングエンジンの開発というイメージ。通信が一方向というのは帯域の活用という意味では最低 (笑)。パケットを 1 個とれなかったらどんだけロスが起こるか。その当時は機能も少なくてネット対応もしていなかったけど、それを対応させたりといったことをしていました。当時はブラウザの実装と W3C の規格との乖離が大きいし、ブラウザも色々種類があるしで、それぞれの挙動を見ながら規格を読んだりして、また Web ではこういう運用してるからテレビでも同じ運用するように縛りいれようと放送規格にフィードバックしたりして、そういう中で規格の読み方とかについてはだいぶ訓練されたかなあ、とか。

卜部 その経験は今でも役立っていますか？

小崎 多分。新人の頃、最初の仕事がこの BS デジタル対応だったんです。ブラウザってその当時では組み込みとしてかなり規模が大きくて、それまでが数十 KB で媒体が ROM だったのが、デジタル放送になってフラッシュ 2 MB でコードが 10 万行くらいに。規模の爆発ですよね。大規模ソースコードを見るコツがだいぶ養われた。みんな慣れてないから、ばっかんばっかんバグを埋め込む (笑)

malloc の解説

卜部 なるほど。プログラム以外の代表作は？　動画でもいいですよ？

小崎 昔 glibc⁵ malloc⁶ を解説した動画が未だにアクセスがあるみたいで。本人的にはああいうのって、時間が経つと「うおー！　直したい！」ってなるじゃないですか。話的に古くなってる訳ではないけど。

一同 (笑)

卜部 今からやるなら glibc malloc ではなくて、もっと変な malloc の解説をやるとか？

小崎 今やるとすれば、jemalloc との比較とか、ウケそうですね。色んな実装を調べて比較したり。

卜部 非同期割り込み可能な malloc とか楽しそうですね。元 HP で atomic_ops を実装してた Hans Boehm ⁷が書いてたやつですけど。シグナルハンドラの中から malloc が使えるようになる。するとシグナルハンドラの中から printf とかが使えるようになる。

小崎 でも malloc って性能が大事なので。そういうレアなケースで平気になったよと言われても (笑)⁸。

Linux Kernel Watch

小崎 あとは、「Linux Kernel Watch」ていう Linux カーネルの連載を Web でしばらくやっていました。

卜部 続ける予定はないんですか？

小崎 あれは正直ちょう辛い (笑)。仕事でやるなら良いけど、Web 媒体だとほぼ原稿料も入らないし。@IT は出してくれる方だけど、あれだけでは生活は成り立たない。

卜部 るびまでも Ruby の ML の解説を記事化するアイデアがあるんだけど、なかなか難しい。なかなか人がいなくて。Ruby でもそうなのに、Linux カーネルのコミット全部読むなんて死にますよ。

小崎 そんなの Linus でも読んでないよ。つまみぐい。あえて「主要なところだけ」って言いかたはしないけど。そもそも Linux カーネルの主要な所ってどこなんだ、という所から論争があるから (笑)

笹田 メモリマネージメントあたりのコミットはぜんぶ読んでいるのですか？

小崎 一時期は読んでいたけど、最近は忙しくて全部は読んでいないですね。

卜部 全部読まなくても仕事はできちゃう？

小崎 仕事によりますね。今僕がやっている仕事は、コアのどこかを弄っている訳ではないので。どこかのタイミングでキャッチアップは必要になるかも。

Ruby と Linux への貢献

郡司 代表作といえば、Ruby で問題になっていた所を Linux のバグとして直す、みたいなのがありましたよね。

小崎 わりと何個もあるので、どの話だろう (笑)。一番最初のは、select(2) で書き込み可能待ちをすると Linux の時だけハングすると akr ⁹ さんに教えてもらった現象があって。Linux の仕様だったんだけれども Ruby で都合が悪いから Linux の仕様を変えてもらって、全世界の Linux ユーザーに恨まれるという (笑)¹⁰。違いますね、きっと感謝されている、はず (笑)

卜部 もともとハングしていたものが、ハングしなくなったんだから。

小崎 そうですよね。僕も当時その理屈を使って説得したはず。Ruby の場合はどこにもドキュメントで保証されてない挙動についてオレの思ってた動きと違うからカーネル変えろとか言ってくるので色々言われました。テストケースで fadvise を使ってるから困るとか。

卜部 レアですね。いったいどういうケースなんだ？

小崎 IO#advise メソッド とかのテストコードでしょう。Linux の場合は、共有メモリファイルシステムなど一部のファイルシステムについては fadvise で先読みするメリットがないので、ENOTSUP とか特殊なエラーコードを返していた。Ruby 側ではそれを受けてシステムコールが失敗したら例外を投げる想定だったという話になって。じゃあ Ruby 側でも例外があがって嬉しいかというと、全く嬉しくない。ので非サポートの場合はエラーを返さないというふうに Linux の仕様を変更した。Eric Wong¹¹ と一緒に (笑)

卜部 代表作たくさんあるじゃないですか。ブログもありますよね？

小崎 最近はブログよりも Twitter で呟いてそれをまとめるだけという簡単な方法に (笑)。あと、Ruby の IO.select メソッドについて、POSIX の仕様からは若干逸脱した作りになっていて。POSIX では fd_set はスタック上に置く前提だから C 言語の制約で固定長にせざるを得なくて、ファイルディスクプリタの最大数が 1024 なんだけど、Linux でサーバやるときとかそれでは全然足りないから、みなさんカーネルパラメータをそれよりたくさんに変更してるんですよ。それで回避策としては一番お手軽なのは epoll(2) に移行することなんだけど、 Ruby の場合は別の解決策をとっていて、ファイルディスクプリタのビットマップだけを malloc でとってそれを渡すことをやっている。でも最近 glibc 側で select に渡すファイルディスクプリタの最大値をチェックして、1024 を超えていたら abort するというロジックを入れた方がいらっしゃいまして。

卜部 正しくないコードを見つけたときに、ライブラリの側でどう処理するべきかという議論が最近ありますよね。

小崎 最近の流れとして「セキュリティ的な意味で悪用されたら問答無用で処理を中断する」という方針がある。select も同じで、全然違うメモリ領域を buffer overflow で書かせる事ができてしまう。glibc 側でもこの理由があってチェックを入れたんですよね。

卜部 「どのファイルディスクプリタにビットがたっている」なんて制御できない¹²から、現実問題怪しげな事はどれくらいできるのか。任意のメモリ領域に書き込む事が出来るというのは理解できるけど、じゃあそれで具体的にどう攻撃できるのか。

小崎 俺もそう思う (笑)。でも glibc 側としてはそれはデフォルトでは OFF なんだよね。 _FORTIFY_SOURCE の設定で引数チェックをしていて、ON の時だけ追加でチェックをかけるから、それが嫌なら外せばいいじゃないかと言うんですね。 でも Ubuntu では gcc のコンパイルオプションを独自に変えていて、そこの設定がデフォルトで ON になっている。

卜部 Ubuntu は最近は EGLIBC に流れているのでは。

小崎 EGLIBC は glibc から派生したプロジェクトだけど、glibc の側のメンテナが交代した関係で最近また仲直りしたので、再統合しそう。¹³

卜部 GCC もそうだよね。昔 EGCS というバージョンがあった。モチベーションが尽きたときに放置されることも多いけど、本家に合流というのも良くある話。フォークした後もどちらもアクティブに開発し続けるというのが超レアなんですよ。XEmacs や BSD 位ですよね。

小崎 確かにね。そんなこんなで Ruby 界隈では Linux プラットフォームメンテナーという称号を頂戴しておりまして、バグが起票されたときにプラットフォームが Linux って書いてあると俺が見ないといけない (笑)

卜部 だいたい Linux じゃないですか。

一同 (笑)

小崎 理不尽に思う事も多くて。さっきの glibc の select の仕様が変わってましたとか、普通に使っていたら気がつかないだろ！　っていう。誰に振れば良いのか極めて難しい。

卜部 それで select はどうやって解決するつもりなんですか？

小崎 今は Ruby 側に workaround が入っているんだけれども、もうすぐ glibc 側を変えるパッチがマージできそう。

卜部 -D_FORTIFY_SOURCE=2 になっていても、それを無視するような？

小崎 まだ確定ではないけれど、もう一個 ON OFF のフラグをつけようかという話が進んでいる。-D_FORTIFY_SOURCE=2 はみんな ON にしたいから OFF したときにどうするのかと。もう一個フラグを作ってそっち側でフラグを OFF にしておけば解決できるかなという話。

卜部 でも Ubuntu ではデフォルトで ON になってしまう？

小崎 それは Ruby 側で上書きすれば済む話なので。select.h を読む前に #undef しておくと。超苦労した所は、Ruby ってなぜか GCC は -include を使うので真っ先に select.h が include されてしまう仕様になってる。なので泣きながら -include 周りを変えまくって。中田さんに戻されて。また壊れて。みたいな (笑)。しばらくせめぎ合いました。

笹田 でもそれで直るなら、glibc に手を入れる必要はなかったのでは？

小崎 Ruby では確かに直るけれども理由が 2 つあって、1 つ目は、Ruby 以外にも困ってるプロダクトはあるはずということ。もう 1 つは _FORTIFY_SOURCE が OFF ってことは、すべてのチェックが OFF になってしまう。でも Ruby が OFF にしたいのは select の件だけ。あと poll(2) に変えればいいという意見も貰ったんだけど、poll と select とセマンティクスが違うので。

笹田 無理矢理シミュレーションする必要がある？

小崎 Linux だとそれらのメソッドがカーネル内で合流しているからシミュレーション出来るんだけど、System V 系だと中の処理が全く別物で、どうやってもシミュレーションできないケースが発生してしまう。Regular file とかの超王道はいいとしても tty とかは歴史的な理由という名の下に、どうしようもない (笑)。メソッド名が select である以上、select セマンティクスを期待するのは極めて自然な訳ですよ。なので、もしやるのであれば Ruby のなかで select バージョンと poll バージョンを 2 つ作ってどっちもメンテしないといけなくなるから、それは避けたいね、と。

nari3 ライブラリを変えよう、という発想には普通ならない気がします (笑)

小崎 いやいやそんなことないですよ。松田さんだって、作っている Rails アプリが思う通りに動かないと Rails を変えると言ってましたよ¹⁴。

nari3 本人が Rails の開発をやっているから、というのもありそうですね。

小崎 確かに。システム開発者やカーネル開発者から見ると、こういう使い方もあるんだっていう知見をくれる人は重要なんですよ。ユースケースがふにゃふにゃしていると議論が迷走しがちですから。そんな感じのバトルが他にも色々あったりなんだけど、だいたいうまく収まっていて、最近は Linux は Ruby に最適なプラットフォームです。なぜなら Ruby の都合で Linux 変えちゃうからと言ってます。宣伝宣伝 (笑)

卜部 昔 Ruby で sprintf を #define していた時期があるんですよ¹⁵。Linux で -D_FORTIFY_SOURCE=2 にすると、glibc で引数チェックのある sprintf に #define してしまう。 #include 順序によってどっちになるのか変わってしまって、とあるファイルでは死ぬけど別のファイルでは死なないというという話になって。辛かったですね。結局 ./configure で回避した記憶があります。

小崎 そうやって下回りの開発者がいると、割とすぐに分かるんだけれどね。

卜部 gcc -E でマクロ展開して、ようやく全部気づいたレベルです。ちょうつらい。

小崎 Ruby さんはマクロを使い過ぎ (笑)。変な置換とか。アプリから libruby.so をリンクしている人は辛いだろうなって思います。close を ruby_close に差し替えるとか、あの辺はすごいなと思ったけど。malloc とか sprintf みたいに差し替えるのは良いんだけど、拡張ライブラリとか、libruby を使う他のアプリがみえるような公開ヘッダーで差し替えるのがすごいなっていう。Ruby の中で完結していない。普通プライベートヘッダーでやるだろう、っていう。

卜部 難しい話で。プライベートヘッダーに書いてしまうと、デバッガとかプロファイラとかやる人達からは拡張ライブラリの側から見せてくれという話になったり。なので結構せめぎあいなんですよね。「Ruby の AST ライブラリを作った」と言われて見てみると、Ruby のヘッダーが丸ごとコピペされていたり。

小崎 (笑)。でも他に方法はないですよね。

卜部 全部公開して「それを使ってね」とするか、隠しておいてコピペされるのを諦めるか。

小崎 今は ruby.h が #include されて全部取り込まれちゃう。「手動で #include したときだけ追加のヘッダーが入る」って方法だと良さそうなんだけど。

卜部 確かに。昔は ruby.h が小さかったから良かったのかもしれない。Ruby のソースコードが大きくなるにつれて、そういう問題も出てきていますね。Ruby が小さかったときは 1 ファイルに全部書かれていて、コントロールできていたんだけれど。

Ruby に関して

Rubyist になったきっかけ

:

卜部 そもそも Ruby をやるようになったきっかけは？

小崎 当時カーネル開発をしていて、どうもユースケースに疎い部分があるなと感じて。なにかプロジェクトに参加したいなと思いつつ、忙しさもあって実行に移せていなかったんです。 そんな時たまたま Ruby の IRC に入ったときに「Ruby が全く分かっていない」という話をしたら、shinh ¹⁶さんという方が Ruby の Hello World の書き方を教えてくれて。そのときは C しか分からなくて、ライトウェイト・ランゲージとか全く分からない状態だったんだけれど、「Ruby は C と同じだ」と言われて。彼は polyglot のエキスパートでもあるから、その場で C と Ruby の両方で valid なプログラムを書き始めて。「ほら同じでしょ」とか言いながら #include <stdio.h> とか見せるわけ。# がコメントとか知らないから「おおー、おなじだー」とすごく感動して、俺でも出来そうだ、と。

一同 (笑)

小崎 Ruby は printf も exit もあるし。int main は書けないけども main の中では exit が書けるんですよ。int が NoMethodError になる前に、exit で閉じてしまう。

一同 (笑)

小崎 なので Ruby でも C でも正当なコードは書けるんだけれど、それを教えるかっていう (笑)

卜部 Rubyist になったキッカケは、だいたい浜地さんのせいだと。

小崎 (笑)。3 年くらい前ですかね。気持ち的にはまだ新人のつもりなので、Ruby Prize とか来年また応募したいですね。今年も応募したけど、かすりもしなかった。受賞した近永さんとかラスボス度が高すぎて。

好きなメソッドと嫌いなメソッド

小崎 文字列操作や正規表現は C よりも楽になってるから好きですね。嫌いなメソッドはいっぱいあるけど、一番嫌なのは Thread#raise とかのスレッド周りのおかしな仕様 (笑)。raise して何が嬉しいのっていう。

卜部 Thread#raise は悩ましいですよね。外に向かってスレッド間通信の代わりに使えるんですよね。

小崎 Thread#raise はタイミングが選べないから、スレッドを殺したいときにしか有用じゃないんじゃないかなと。スタック上に実行履歴が積まれていて巻き戻すときには意味があるけど、他のスレッドに raise させるっていうのは巻き戻しとは違うセマンティクスなので、あんまり使い道がない。まず名前から気に入らない (笑)

卜部 その昔、タイムアウトを実行しようとすると Thread#raise を使うしかなかったと聞きますね。タイムアウトなら待ってる方のスレッドは既に止まっているので、そこに raise してもあまり問題がなかったので。

小崎 タイムアウトもあれはあれで、もうちょっとなんとかならんのかと思うけど。Ruby は 1.8 以前と 1.9 以降でスレッドの仕様が大きく違うので、いろんな矛盾がね。1.8 ではグリーンスレッドが表に見えちゃって、API 仕様はまあありかなと。Thread.exclusive するのもある意味アリだよね。1.8 のスレッドを最初に読んだときは、ここまで割り切るのもアリなんだ、と、その時はプラスの評価だったんですよ。1.9 で Thread.exclusive はない。

笹田 がらっと変えたけど、全然苦情来てない。だれもそこまで真面目に使っていない。

小崎 Mutex 待ちをしている所に ^C したらロック取らずに抜けてくるとか。これはまだ例外があがってくるけど、条件変数で ^C したときには例外があがってこない。

卜部 嫌いな所はスレッド、と。

一同 (笑)

小崎 それも難しくて、Ruby に Thread クラスがなかったら俺コミッターになれなかった気がする。自分がソースコードを見て明らかにおかしい所が残ってないとコミット無双モードに入れない (笑)

nari3 Ruby のソースコードはどのくらい読んでるんですか？

小崎 そんなに読んでない、得意分野だけ。僕がよく直してる process.c や io.c、thread.c とか。システムコールから遡って読んでいくだけだから。

笹田 あまりそういう読み方はしない (笑)

小崎 まあ grep かけたところから。Ruby の parse.y から初心者が入ろうと思ったら、結構きついと思う (笑)

卜部 挫折する人結構いますよ。parse.y とか。

小崎 笹田さんと一緒に学生向けのプログラミングキャンプをやったことがあるんだけれど、学生さんは文法拡張したがるから、あそこは避けられない。でもなぜその魔窟を選ぶのかと。残り数時間で (笑)

卜部 文法もなんとかしたいですけどね。でも「文法をなんとかしたい」と「スレッドと割り込みをなんとかしたい」というのを比べると、割り込みの方をなんとかした方が、と思っちゃう。文法はそこまで困らない。

現在の Ruby とのつきあい方

小崎 バグ登録を監視していて、プラットフォーム Linux の申告があると確認する。あとは ABI 非互換を検出する仕組みを作っていて RubyCI に組み込んだり。リリースのときに非互換が出ないようにする仕組みを機械的に作ったりとか。機械的チェックはやっぱり必要ですよね。

卜部 昔はそういうツールがないのに ABI 非互換はありませんとか。言っちゃった以上やる他ないので結構大変でした。Ruby のスクリプトでアプリを作って使うというような事はあまりしない？

小崎 そうですね。カーネルを直したときに、デバッグのテストツールで出力したログに対して、おかしな組み合わせを検出したり、というのはやってますね。さっきも言った文字列操作や正規表現がありがたいっていうのは、このあたりかな。

Ruby を使って成功した事例

小崎 成功した事例ってほどでもないけど、さっき言ったテストツールかな。日々の検証で地道に使っています。テストツールはバグ発見というよりも修正できたかの確認。自分はバグを発見するタイプではないので。

卜部 田中さんは自分でバグを発見するタイプですよね。

小崎 そもそもなぜそのテストをしようと思ったのか、っていう (笑)。どうやったらその発想ができるのか。正解を知って逆算してるのでは、と思ってしまったり。たまに自分もしますけどね。ソースコードを追って怪しそうな所を見つけてから狙い撃ちしたり。

一同 (笑)

小崎 数少ない Ruby への貢献では、昔は Ruby って大きい文字列を作るといろんなメソッドが落ちてたんです。原因は alloca を使っていたので、スタックがあふれるという単純なものだった。その辺はソースコードを見ながら alloca を使っている所を狙ってテストケースを作り報告しましたね。結局中田さんが必要な所は malloc を使うように修正してくれたり。

卜部 配列はまだ大きいと落ちちゃうんですよね。大きい配列をスプラットに渡そうとするとスタックがあふれて落ちる。お話しいただいたのはマシンスタックの話で、これは VM スタックの話なので、別ですが。たしかにマシンスタックの alloca はもうないですよね。結局 alloca の引数に外から来た任意の引数を渡してしまうとまずいという話で、固定長はまだ残ってたかな。

小崎 そこから数年経った今まさに glibc でも同じ話になっていて。インプットをそのまま alloca に渡していて、一掃作戦をかけています。　

卜部 alloca 使いたい気持ちも分かるけど、前後にチェックを挟むとそこまで速くならないし。

小崎 そうですか？　ぜんぜん速度違うと思うけどな。malloc したら CPU とかロック競合を考えないといけない。Ruby みたいに GVL だから関係ないのかもしれないけど。

卜部 alloca だと、alloca 出来ないときにどうするのか考える必要があるのが手間かなと。スタック足りなかったりとか。

キラーアプリ

卜部 自分のとってのキラーアプリとは？

小崎 アプリではないけれど GitHub ですね¹⁷。僕の人生を変えかねない位のインパクトが。

卜部 Linux って GitHub をどれくらい使ってるんですか？

小崎 ほとんど使ってない。個人的には、カーネルは色んなマシンでテストしたくなる訳だけど、色んなマシンに push できて超便利とか。後は人様のプロジェクトを見るときに分かりやすい。ブラウザで見れるし。GitHub なかったら、Git の普及ってもっと遅かったと思う。コマンドだけだと何を操作しているのかイメージしづらいし。GitHub は目で見て分かる。Git のコマンドって便利だけど理解するまでが (笑)。GitHub だとワンクリックで fork が出来る。

nari3 この間 Mozilla のリポジトリに使ってないマクロがあって。消すためのパッチを作ろうとすると、Mozilla は独自のバグトラッキングシステムを持っていて、再現性を問われたりアカウントを作らないといけなかったり。結局マクロ 1 つ削るのに 3 ヶ月もかかりました。GitHub にあればいいのにって (笑)

小崎 Mozilla はレビューの割り振りが均等でない感じがする。

卜部 あと、GitHub を使っている人はコミットログをちゃんと書いてほしいですね。「#123」みたいに書いてる人がいるんだけど、GitHub だとリンクとして表示されるけど、他では困ってしまう訳で。ちゃんと書いてほしい。

小崎 キラーアプリはその位かな。Ruby 界隈では tDiary を使っていないと Rubyist を名乗れない、みたいな感じがありますけど。僕使ったことなくて。

卜部 いやいや。そんな事ないですよ (笑)

Ruby の習得は簡単でしたか？

小崎 何一つ分からないのでソースコードを読むまで分からなかった感じですね。

卜部 メソッドの振る舞いの話ですよね。文法はどうですか？

小崎 文法は完全に理解してないですよ。複雑な事はしていないし。Ruby のテストプログラミングに頼っているので、そこで使っていない method_missing みたいなメタプログラミング系の知識は未だに全然ないです。

プログラミング全般

Ruby 以外のプログラミング言語あるいはテストの話

:

卜部 Ruby 以外のプログラミング言語は何を？

小崎 普段使いは Linux のカーネルのテストを C で書いてます。Linux 独自のシステムコールは C からしか叩けないから、もう得手不得手関係なしに C。

卜部 それはテストケースの話ですよね。テストドライバーみたいなものは無いんですか？

小崎 無いでーす。一つひとつ手で実行する。Linux にも LTP っていうテストプロジェクトはあるけれども、Linux の中心的開発者で使っている人は見たことはありません。 みんな自分が作ったところは自分の手でテストしている。

nari3 Ruby は大きな修正の時にテストを走らせないでコミットすると怒られますね。

小崎 Linus さんがテストしないでコミットする人だからしょうがない。

nari3 どっかで聞いた話ですね (笑) ¹⁸

レビューをするかチケット管理をするか

卜部 GitHub が出てくるまでは Ruby ではあんまりレビューをしなかった。パッチを送ってきてレビューするという文化がない。コミットしてからバグに気づく。 その代わりちゃんとチケットを管理している。

小崎 Linux で偉いのはパッチをメイリングリストに投げてみんなでレビューしているところ。 Ruby は仕事じゃないのにリリース前にチケット総ざらえするのが偉いよね。 kernel.org にもバグ管理システムはあるんだけどだっれも見てへん。Linus が見てない以上……。

笹田 そういう意味じゃ、まつもとさんも見てないじゃん。

一同 (笑)

Linux 界隈と Ruby コミッター界隈の文化の違い

nari3 Linux 界隈と Ruby コミッター界隈の文化の違いとかありますか？

卜部 日本語が通じるかどうか？

小崎 Ruby の方がコミッターどうし仲が良いかな。IRC でだべってるし、数も多くないし。顔を覚えなくちゃいけないのは 30 人くらい。 いっぽう、Linux は名前覚えなくちゃいけないのが 200 - 300 人くらい。 カーネルサミットの会場に限界があって 80 - 100 人くらいしか呼べない。どういう基準で選んでも居ないやつがいるから議論が成立しないんですよね。

卜部 まあしゃあないですよね。世界中から 300 人とか呼んでもみんなは来られない。

カーネルサミット

nari3 カーネルサミットはどこでやるんですか？

小崎 全世界を転々と。今年はイギリス、去年はアメリカだったと思う。日本でやったこともあるじゃないですか。

郡司 Linus が来て、よしおかさんがカーネル読書会に呼んで¹⁹。

小崎 Windows 7 の発売セールやってるアキバのヨドバシで親指を立てて (笑) ²⁰ カーネルサミットは年 1 回やってます。毎回行ってるわけじゃないけど。発表したこともあったかもしれないけど英語がよくわからないとかいって同僚の誰かに押し付けることが多い。

笹田 行くと 300 人くらいいて顔と名前は一致する？

小崎 残念ながらほとんどわかってへん。向こうから話しかけてきた人だけは、顔と名前が一致する。

菅井 RubyKaigi とかだと Ruby を作ってる人も使ってる人も来るけれど、カーネルサミットは？

小崎 Linux を作ってる人も全員来られるわけじゃないけれど、サブシステムごとにミニサミットをやっている。 一番大きいのは LSF/MM (ストレージ、ファイルシステム、メモリ)。それが 60-80 人くらいで、僕も毎年呼ばれてるので、年に一度ツイートしてると思います。 「今年はこういうことやることになりました」って。

卜部 と言ったはなしを、「Linux Kernel Watch」で書いてくれれば良いんだけど。

C 以外の言語は？

小崎 昔は C++ とか Java とかホビーに使ってたけど使わなくなったなあ。 大学生とか新人の頃に Java が流行り始めて。Ruby のスレッドは明らかに Java からの影響を感じられるよね。

卜部 Java でアプリケーションを書こうと思ったことは？

小崎 Java とカーネル屋さんの二足の草鞋を履くには JVM を知らないといけないからちょうつらい。 ちょっと時間ができたから見てみよっかなー、というには太刀打ちできないレベルになってる。 Ruby は行数を見て、ああこのくらいだったら理解できるかな、と。

卜部 さっき言ってたテレビのブラウザは？

小崎 C。組み込みはほとんど C。C でブラウザを書くのはつらいけれど、Mosaic の頃は C で、どこかで分岐した Mosaic が組み込みでは延々と使われている。

卜部 バグってても武器が無さすぎてどこでメモリが壊れてるかわからないですよね？

小崎 それは Ruby も一緒じゃん。

卜部 でも Ruby はどこを注目すれば良いかはある程度明らかですよね？

小崎 それは結局ソースコードを習熟すれば明らかだということ。結局最初はちょうつらいんだけども、ソースコードを何回も読んでると、だいたいこの辺じゃないの？　というのがだんだんわかってくるので。

文字列操作

卜部 あまり僕は C では文字列操作はやりたくないな。

小崎 特に web 系の文字列操作はね。 Ruby のパーズが幸せなのは、文字列が全部そろってから始められること。 組込みブラウザの時は、パケットが全部来てなくてもパーズを始めなくちゃいけないじゃん。 次のパケットが来たら、「解釈間違ってましたぁ」みたいなことも起きるし、

卜部 そこそこ速く動かなくちゃいけないので、先頭からやりなおすわけにも行かないし。

小崎 バッドノウハウの塊なので、心を無心にして読まないと、むきーって。 でも、当時はわからなかったけれど、ブラウザの世界はけっこう狭いから、人の交流のせいで似た設計になる。ひとつ理解すると、他社のブラウザもわかる。

ソースコードの行数

卜部 ところで Ruby のソースコードの行数は、C の部分で 20 万行ぐらいでしたっけ。

小崎 ユーザー空間でそれはずいぶん少ない。OpenOffice は 1 千万って聞いたけど。

卜部 コンパイルする時間を考えても。OpenOffice は一日がかりだしね。 Gentoo っていうディストリビューションがあって、だいたい全部コンパイルするので、絶対的な行数はわからないけれど、相対的な規模がそれなりにわかる。 Emacs とカーネルは同じくらいとか、それに比べて ghc は明らかに遅いとかわかって楽しい。 今は日和って Ubuntu を使ってますけど。

小崎 そういう意味では Linux もずいぶん小っちゃくって、ドライバを全部合わせて 1 千万レベルだから、 カーネルのコアだけなら数万行で Ruby とそんなに変わらない。

笹田 目的があれば見てみようかな、っていうレベルですね。

卜部 システムコールは読みたくないな。土地勘ができるまで大変。libc なら土地勘があるんだけど。

美しいソースコード

卜部 今まで読んだなかで最も美しいソースコードは何ですか？

小崎 感銘を受けたのは『Lions’ Commentary on UNIX』。Unix like operating system に対する土地勘がたったの 1 万行のソースコードで得られる。 もうひとつ挙げるとすれば X²¹。今から見るとちょう汚ないんだけど、業務で普段みてるヘッポコソースと比べると突然まったく関係ない処理が顔を出さないので感動した。まあフォローしておくと、組み込みはいろんな事情があって汚くなるのは避けられないんだけど。

テレビの規格

小崎 そういえば、テレビの描画は X のプロトコルでやってる。X にはエクステンションがいろいろあって、僕が選んだのは横に 2 画面あるのを同じ座標に 2 画面重ねるようなもの。テレビは日本の規格では、昔のゲームのスプライトみたいのを 5 画面重ねてる。動画、JPEG 用、データ放送用 (文字とか PNG の軽いやつ)、あと、字幕が 2 つ。字幕は、番組連動のものと、野球速報や地震津波の警告みたいに番組に連動していないものと。こうしておくと録画した番組を見ているときは速報字幕みなくてすむからって。でも、せっかく規格をつくったのに結局実際の運用では、地震警告は動画にはりついてる。録画とかしたものに変な警告が張り付いちゃってるのは、元テレビ屋さんとしては残念。せっかく苦労して仕組みつくったのにって。

郡司 それは全部のテレビに実装されていないから？

小崎 いやいや。アナログテレビはもう無いし、デジタルテレビは全部実装されてる。

今興味があること

卜部 今興味があることは何ですか？

小崎 トランザクション・メモリ。Haswell が発売されたので何かネタないかなと。Linus 先生が VFS のロックを書き換えてちょう速くなったって言ってた。UNIX のファイルシステムは全部ルートからつながってるからルート近くでロックが競合する。実際にはファイルはほとんど競合しないから、楽観的な仕組みにすればすごく性能が上がる。そんなわけでトランザクション・メモリとはすごく相性が良いんです。

卜部 じゃあ効くところでは効くっていう感じですね。Intel が入れると言った時は本気か？　と思ったけどアリなのかもねという感じもしてきました。Haswell の入ってる Mac とか。

小崎 MacBook Pro。欲しいんだけど高くて買えない。

卜部 何かのグラントをもらって買えばいいんじゃないですか？　「とりあえず Ruby を速くします」って Kickstarter に登録してみるとか。

小崎 それでできなかったら、恥かしいね。もう 1 個やりたいのは glibc malloc の高速化。jemalloc や tcmalloc より遅い理由を何個か知ってるけど upstream にコミットできていないので、そのうちやりたい。

GNU プロジェクトへの著作権の譲渡

小崎 でも GNU の場合は面倒くさい。ほとんどの会社では、従業員が業務時間内に書いたコードの著作権は会社のものになる。そのコードが業務時間外に書かれたものだという証明は困難なので、GNU にコードを貢献するには、フリーランスでもない場合は、会社の責任のとれる人のサインがないとコードを受け付けてくれないんだよね。VP レベルの人のサインが必要なので、特に弊社みたいな大企業だと結構大変で。偉い人すぎるとね。

(後編に続く)

途中で

小崎さんインタビューの前半はここでおしまいとなりました。 翌日おこなわれた後編のインタビューに続きます。お楽しみに。

(インタビュー：卜部、テープ起こし＆編集：小林、zunda)

---