コミュニティのしきたりによるOSSプロジェクトの違い
あるいはオープンソースといいつつ、同じライセンスでもそのオープンさには差があるということ。
OSSプロジェクトと言えば、
- ソースコードに自由にアクセスできて
- プロジェクトへの参加も自由である
というイメージですが（個人的には）、いくらライセンスがOSS互換ライセンスでも、実は後者はプロジェクトコミュニティの性質によってえらく変わってしまうなあ、という気がしています。
1. OSSライセンスだが、プロジェクトに参加しにくい、あるいは出来ない。
私が知っている限り、この様な状態のプロジェクトは3種類あります。
- 一つは企業などがGPLでソースコードだけ公開しているけれども、そもそも開発コミュニティが存在しないケース。Linux向けドライバではよくあるケースですね。
- もう一つは、開発コミュニティが存在しているけれど、開発はさらに内輪の限られた人しかしないケース。外部からのパッチは、ほとんどが無視されてしまうし、プロジェクトの方向性も、内輪の面々が勝手に決めてしまう。レアですが、LinuxでいうとL○Mとかがいい例ですね。
- 最後の一つは、開発コミュニティが存在していて、パッチは投げれるけれど、主要開発者が書き換えた上でコミットしてしまうケース。これはMySQLなど後々ライセンスが気になる企業がやっている（やっていた？）例を聞いたことがあります。GPLでも、著作権者はパッチ作成者になってしまうので、後々ライセンス変更したい場合大変なことになります。（GNUのツールもそうなんだっけ）
2. OSSライセンスで、プロジェクトへの参加もオープン
これは一般的なOSSプロジェクトの形態ですね。コミュニティの構成人員によっては、参加しにくい例もあるのかもしれませんが、だいたいは、バグ修正パッチなどを投げると、喜んで取り入れてくれるし、それを利用した別のプロジェクトがあっても、特に気にはしません。
3. OSSライセンスで、プロジェクトへの参加が強制的
LKMLでメンテナの意見などを見ていると、Linuxカーネルコミュニティというのは、out-of-treeのコード（たとえそれがGPLであれ）を極端に嫌う傾向があります。nouveauドライバの話も、ツリー外部で作らず、マージしてくれという要望に応えたケースですし、Androidの話は、これに応えられなかったケースですね。もちろん、これにはドライバAPIが流動的なので、out-of-treeのコードはすぐ陳腐化してしまうという、きちんとした理由があるのですが。
ただ、このタイプのコミュニティでの開発は、時として非常に難しくなります。他のメンバに機能の必要性や、コードレビューなどを通してから採用されることになるし、機能の実装方法やデザインが議論の結果によって変わってしまったりすることもざらです。機能自体否定されることだって考えられます。一定期間内に予想した成果を挙げていかなければならない企業にとっては、非常にやっかいなケースですね。
AndroidはGoogleが進めているOSSプロジェクトと言っても、やはり彼らのビジネススケジュールにしたがってリリースすることが求められるので、Linuxカーネルコミュニティと折り合いをつけてやっていけるようになるには、しばらく時間がかかることになると予想します。
娘のお食い初め
ちょっと早めだけどお食い初めをした。
鯛の姿焼き
黒い鯛は焼いても黒い。なぜか海老みたいに焼いたら赤くなると思い込んでいた・・・orz。まあマダイはボストンでは入手困難だし、おいしかったから良し。
紅白なます
大根よりにんじんが多くなってしまった。にんじんは少なめの方がおいしい。
お吸い物
蛤がないのでLittle neckを使ったんだけど、なんか香りが違う・・・。まあ砂だしはうまくいったようだし、よしとする。
煮物
芋たこ大根を作ってみた。結構おいしい。たこは大根と煮ると柔らかくなってかなりgood。芋はタロ芋を使ったんだけど、タロ芋にも固い芋(煮ても柔らかくならない？)と柔らかい芋があるらしいことを知った。
赤飯
赤飯は乾燥赤飯みたいなのを使ったので、特に問題無し。おいしかったです。
Android騒動
そういえば何か書こうと思って忘れていたんだった。
http://www.kroah.com/log/linux/android-kernel-problems.html
Linuxカーネル開発者としては、Androidのカーネルパッチがいつまでたってもまともにマージされる気配がなければ、「もう古いし捨てちゃおうか」と思われても仕方がないと思う。GregがAndroidのドライバを切ったのも宜なるかなというところ。Androidの開発者に悪気はなかったんだろうけど。「Don't be evil」とはいうが、GoogleのAndroid開発者は、何もしないことが時としてevilと受け取られることも意識したほうがいいと思う。
Linuxカーネルにフリーライドするのは簡単だし、その成果を勝手に公開するのも簡単だけれど、Linuxのメインツリーに還元するのは至難の技だ。でもLinuxはオープンソース的手法で作られていることに価値がある。メインツリーの開発者に説明して、その成果が本当に価値があることを納得させ、コミュニティへ還元することこそ本当に価値のある行為だ。明らかに、Androidそのものの開発に価値はあるとは思うけど、いつまでもメインツリーからフォークしたままGoogleの資力の下開発が進められるのであれば、それはもう、GoogleがLinux開発コミュニティにとってevilになったということなんだろう。
そしてこのことは、多くの開発者が踏んできた（今も踏んでいるところはあるが）轍である。LKSTとSystemtapの開発に携わった(今もそうなんだけど）人間が言うのだから間違いはない（笑）。
続きを読むLinux Instrumentationの今後？
http://lwn.net/Articles/370715/rssで、LinusがNAKしてマージが難航しているutraceですが、その後の展開をみると結構おもしろいことになっています。
Linusが言うことにも一理あるわけで、utraceだけ見ればptraceしか普通のユーザは使わないから、utraceみたいなレイヤは不要だということになります。確かに個人的な経験からしても、LinusあるいはLinuxメンテナたちは、汎用的になるからという理由だけで新しいレイヤを付け加えるという意見には賛同しないでしょう。私見では、Linuxの場合、大体次のシナリオを通ると、汎用レイヤの実装がすんなり行くのではないかと思います。
- 一般化できる可能性があるが、特定の目的に特化した機能が一つ入る。
- その機能のコードの一部を複製したような(機能的に重複する)別の目的の機能が入る。
- 時として、さらに同じような機能が追加される。
- それらを統合してメンテナンスを楽にしよう、ついでに将来を考えて汎用的にしようということでレイヤ分けをする。
今回の場合、utraceはptraceが汚すぎ、拡張性がないからという理由で開発されているのですが、肝心のutraceのユーザがptraceしかない状態です。他の有効な使い道を示せていないため、Linusが難色を示すのも頷けます。でもuprobeとSystemtapがあるじゃないか、という意見もありますが、uprobeについては今後の方向が議論されているものの、残念ながらいまだsystemtapはLinux開発者たちに人気がないというのが現状です。systemtapの一部に、カーネルモジュールのコードが含まれており、そのコードがLinuxカーネルの開発ツリーと同期していないのがその理由です。つまり、オープンソースにもかかわらず、プロプラエタリなドライバと同じ問題（カーネルのAPIが変更されるのについていくことができない）を抱えていると認識されています。機能的には優れた部分がたくさんあり、現在のところDtraceのような汎用Instrumentationに使えるツールとしては、これしかないのですが(用途を選べば他にも選択肢はありますが、LTTngとか)。
それで、その後perf/ftraceのメンテナのIngo Molnarが議論に参加してくるのですが、相変わらず興味深いアイデアを出しています。
Right now we support simple C-syntax expressions like: perf record -R -f -e irq:irq_handler_entry --filter 'irq==18 || irq==19' More could be done - a simple C-like set of function perhaps - some minimal per probe local variable state, etc. (perhaps even looping as well, with a limit on number of predicament executions per filter invocation.)
(適当に意訳)今のところフィルタルールは'irq==18 || irq==19'みたいな簡単なものしかサポートしていないが、これをもっと拡張して、Cの関数みたいな機能を持たせたい。多分ループも使えるようにできる。
IMHO that would be a superior concept for security modules too: there's no reason why all the current somewhat opaque security hooks couldnt be expressed in terms of more generic filter expressions, via a facility that can be used both for security and for instrumentation. That's all what SELinux boils down to in the end: user-space injected policy rules.
(超適当に意訳)この機能をセキュリティフックに当てはめれば、セキュリティフックの動作をコントロールするプログラムを書いてSELinuxを置き換えられるだろう。
今後Linuxでも、DTraceみたくバイトコード(あるいはインタプリタ)をサポートする方向にいくかもしれません。さらにその上で、それを使ってSELinuxを置き換えたりするのかもしれません。そんなに簡単には行かないと思いますが、できるなら個人的にはiptablesまわりも置き換えてほしいですね;-)。
発声の発生とか。
娘が声を出すようになって約一ヶ月。だいぶ馴れたようで、「ふぅー」というような声から、「あぅー」、「あーあーあー」「キャー(裏声?」など多彩な声をあげるようになってきました。泣くときにも、何かを言おうとしているような節があって、「おあーあん」と言っているようにも聞こえます。意外と「おかーさん」というのは原始的な発声にもフィットする言い方なのかもしれないと思ったり。
ところで最近は週末になると家事手伝いというか主に料理を担当しているのだけど、今夜は関西風雑煮を作りました。ボストンでは日本食用の食材といっても限られるので、適当に材料を集めているのですが、里芋の代わりに使ってみたタロ芋が意外とおいしいことに気づきました。
