Matzにっき
2003年07月07日 七夕
_ [OSCON]発表資料
出発前日になってやっとスライドが完成。長かった。疲れた。
しかし、今までの経験だと60枚のスライドでは、そのままだと３０分ほどしか保たないので、 いろいろスライドに書いてない台詞をしこまないといけない。
一番失敗がないのは原稿を書いてしまうことだろうが、プレゼンテーションとしての質は落ちるしなあ。 まあ、木曜日までにどれだけ準備できるかだな。
とりあえずスライドはこちら。
_ [OSCON]資料間違い
タイプミスが複数ありました。今spell checkしましたので、もう大丈夫です。 ただ単語のミスはispellで発見できても、文法ミスは見つけられないんですよねえ。
英語だけでいいから文法ミスや文体チェックをしてくれるソフトがあればいいのに。 昔Grammatikという商用ソフトがあったと聞いたことがあるけど。
_ [OSS]オープンソースには法的問題あり
インターネットウォッチの記事。見出しを見て「どきっ」としたけど、 どうやらこれはドイツ法でだけ成立する話。 日本の法律ではこの問題はないはず。
ところでこの記事の途中に「著作権放棄」という表現があるけど、 GPLは著作権放棄を求めている部分はないよね。 FSF管理のソフトウェア以外のオープンソースソフトウェアでは、 パッチの著作権の扱いは曖昧のままのものが多いけど、Rubyを含めて*1。
それはともかく日本を含む各国の法律がオープンソースを想定していないのは確かで、 運動していく必要があるのは事実だろう。どんな運動があり得るのかなあ。 ロビイスト(lobbyist)を雇う？ そのお金はどこから？
ルビイスト(rubyist)なら少々いるんだけど*2。
2004年07月07日 七夕
_ [OSS]オープンソースによる互換性の喪失
mimiさんからのツッコミをいただいたが、 十分に理解できた自信がない。
オープンソース化されれば、差別化、重視になるでしょう。
一部のコミュニティが互換性を無視することに対してコミットして、互換性は失われる方向になる。
オープンソース化すると、誰にも互換性の維持はできない。
と考えています。
分からなかったのは、
- 「差別化、重視」とは、誰が、何を、どのように、行うことを想定しているのか。
- 「コミュニティの一部が互換性を無視することに対してコミットする」とは、 誰が、何を、どのように、行うことを想定しているのか。
という点だ。
前者についていえば、あるオープンソースプロジェクトに対して「差別化を行う」ということは、 差別化できる存在を新たに作る、すなわちフォークを意味すると思われる。 それ以外の差別化はオープンソースであるなしに関らず発生するからだ。 しかし、実際にはフォークはめったに起きないし、 起きたとしてもどちらのプロジェクトが「正当」であるかは明らかなので、 互換性を重視する人がどちらを選ぶかは明白だ。
後者については、「コミュニティの一部が互換性を無視することに対してコミットする」という表現は、 やはりフォークを想起させる。 たとえオープンソースであろうとも、プロジェクト管理者(JavaならSun)が望まない修正は取り込まれないし、 ローカルパッチは決して広く受け入れられないからだ。 結局はフォークを心配しているのね。 しかし、上に述べたように、フォークは重大な問題ではありえない。
想定できる問題として「互換性はないが、より優れたフォーク」が登場した場合に 発生しうる混乱があるが、これは心配しなくてもいいんじゃないかなあ。 フォークが発生したとしても、まずフォークした方は長期的には生存できないと思う。 Sunやその他の人々がJDKに注力しているリソースを考えると、 それを越えるのは容易ではないし、そんなことを考えるのはマイクロソフトくらいだ。
それもArtisticライセンスのようにプログラム名を担保するとか、登録商標を駆使するとかで、 少なくとも「Javaの名前」は守れるだろう。 名前が違ってしまえば、それは「Javaに似たなにか」であり、 違うものであるのでそもそも互換性は問題ではない(それがC#か)。
多くのオープンソースプロジェクトが互換性を重視していないのは事実だが、 それはそれだけのコストを払っていない(払いたくない)からであって、 オープンソースだからではない。 Sunは互換性維持のためにこれまで十分コストを払ってきたと思うし、 その努力にはオープンソース化してもあいかわらず有効だと思う。
と、いうことで楽観的な私の結論は、
- オープンソースかどうかと、互換性の維持のコストはほとんど関係ない
である。
mimiさんには「オープンソース化すると、誰にも互換性の維持はできない」という結論を出す 論拠なり、実例なりがあるのだろうか。 Javaくらいのプロジェクトだとフォークが頻繁に起きることが予想できる理由がある、とか。
それから、現状のJDKはGosling自身の言葉のように
「われわれは、(Javaの)ソースコードをコミュニティーに提供することで、多大な恩恵を受けている。唯一の難点は、ライセンス条件が一部の人が望むより、少し面倒だという点だ」
であり、ソースコードは入手可能で、ライセンス上の問題以外はオープンソースとさして変わりはない。 もっとも、その問題が重要だと考える「開発者」は多いだろう。 逆に上記のHotWiredが声を聞いた「ユーザ」にとっては技術上の些細な点に過ぎない。
私は、この「ライセンス上の面倒」の解決は、 Sunにとって大きなメリットがあり、デメリットはほとんどないのではないか、 と私は思うんだけど、どうなんだろうねえ。
2005年07月07日 七夕
_ [原稿] UNIX USER 9月号
まだ8月にもなってないのに9月号とは。 日本の出版業界の慣行はまったく。
などと愚痴をこぼしてもしょうがないのだが、 9月号である。普段ならわずか2ページのしかもお気楽な内容が多い「ハッカーズライフ」は わりと手早く書けてしまうのだが、今回は全然進まない。
テーマはわりと早く決まったのだった。前回のを書き終わった直後に、 今度は使わなかった「言語重要」に決めたのだった。 しかし、そこからがいけない。全然、書けないのだ。 スランプか。
「緑川先生ったらもうとっくに〆切過ぎているのに」とロコちゃんのお父さんに言われそうな*1勢いである。
人間はプレッシャーが強まると仕事ができなくなるものらしいが、 私は特にそれが強い。今月はいつもと同様の
- UNIX USER 9月号
- 日経Linux 9月号
に加えて
- 8日の オープンソースカンファレンス2005 in Hokkaido
- 14日、15日の筑波大学集中講義
があるので、どれから手を付けてよいのか気持ちの上で軽いパニック状態が続いているらしい。
とはいえ、いつまでも遊んでいるわけにもいかないので、集中してなんとか書き上げた。 今度は日経Linuxか。
*1 「とっとこハム太郎」という番組で「ハム太郎」の飼い主ロコちゃんのお父さんの仕事は編集者である。だいぶ前にテレビでこの「とっくに〆切過ぎてるのに」というセリフを聞いて苦笑したのは〆切商売の性(さが)か。
_ [OSS] 北海道
で、明日は北海道への移動日なのですが、11時半に新千歳についてから、 夕方6時に宮原さんたちと合流するまで手が空きました。 どうやって時間をつぶそうか。
いや、どこかネットのつながるところを確保して原稿を書いてた方が良さそうな気もするけど。
_ まつもとゆきひろの写真
山口花能の新・煩悶日記: bounce jack live と増山麗奈個展オープニングパーティーより。
写真左の人物はbounce jackのギタリスト、まつもとゆきひろさんである。 いや、「松本」は珍しくない名字だし、「ゆきひろ」も「ひろゆき」よりは少ないにしても そんなにありえない名前じゃない。 実際、私の漢字の名前「松本 行弘」と同じ名前の人物が世の中に少なくとも後3人いることは確認している*1。しかし、わざわざ重複しないように選んだひらがなの名前まで重なるとは。
私は楽器が全然ダメなのでギタリストとは憧れるなあ。 しかし、彼は自分の名前を検索すると私がたくさん出てきて迷惑してるかもなあ。
*1 三人の松本 行弘は、東京証券取引所にひとり、朝日新聞社にもうひとり、あとのひとりは布団屋の専務をしているらしい
2006年07月07日 七夕
_ Pickaxe2校正
『プログラミングRuby』の校正も行う。 こちらは分量が多いからなかなか進まない。
_ 『情報処理』
情報処理学会学会誌『情報処理』*1のコラム「オープンソース事情」の原稿を。
Rubyの歴史と発展をまとめ、オープンソースソフトウェアのライフサイクルと 成功の秘訣について考察する、というような内容なのだが、 それを真似したら他のプロジェクトでも成功できるのかは断言できない。 記事にそんなことは書けないけど。
キーワード「ガイアツ」
*1 「情報処理学会学会誌『情報処理』」って重複が多いな。早口言葉みたい
_ [知財] Open Tech Press | 知的財産推進計画2006によせて(1)
「バーチャルネット法律娘 真紀奈17歳」氏による提案。
権利保護したい人は保護できる「二階建て制度」には賛同する。 私は誰かから権利を奪いとりたいわけではなく、 十把ひとからげに「保護」されて、私の権利(の可能性)が奪われるのが嫌なだけだから。
権利保持者にも、保持する意向があるかぎり保持できるこの方式はメリットがあるんじゃないかなあ。
2007年07月07日
_ [Ruby] Ruby なんて遅くて使えないよねって言ってみる - Akasata's Page（あかさたのページ）
タイトルは「遅くて使えない」となっているが、 実際に呼んでみると「使えないわけではない」というような論調。
いや、別に「Rubyが遅い(特に1.8が遅い)」って言われても、 「はぁ、そうですか」としか思わないんだけど(性能を目指して実装してないし)、 パフォーマンスと言うのは非常にFUDに満ちあふれた分野であるので、 誰かが「遅い」とか「遅くて使えない」と言った場合には、 その真意を見極める必要がある。
で、「遅くて使えない」って言った人が、 その根拠にGreat Language Shootoutを 持ち出してくるようなら、その人の言うことは聞かなくてもいい。
Shootoutは娯楽としては面白いけど、 実際の仕事の参考になるようなベンチマークではない。 これが測っているのは主にインタプリタの性能(メソッド呼び出しや単純な計算)だが、 実際のアプリケーションの性能は、そのような部分よりも アプリケーションフレームワークの性能や、ライブラリ実装の品質などの 影響の方がはるかに大きい。
YARV (Ruby 1.9)がリリースされたあかつきにはShootoutの順位はずいぶん変化すると思う。 YARVは現在のPHPやPerlやPythonよりも速い。 テストによっては現在のRuby (1.8)の数倍から数十倍高速になる。
じゃあ、速度の問題はこれで解決かというとそんなことはない。 YARVになってもRailsの性能は改善されないからだ。 要するにRailsが遅いのだとしてもそのボトルネックはインタプリタ性能にはないってこと。
このことを見るだけでも、実際の局面でShootoutがいかに意味がないかはわかると思う。
さて、とはいえ、新しいVMを導入したのにRailsの性能が改善しないというのは あまりにもナンなので、12月のリリース前にはRailsをベンチマークにして、 ボトルネックを探して改善する計画がある。本番ではRailsも高速になるから。多分。
_ BabelStone: What's new in Unicode 5.1 ?
2008年以降の「いつか」にリリースされるUnicode 5.1で増えるもの。 これによって総文字数は100,823文字とはじめて10万文字を越える(5.0は99,024文字)。
誰だよ、65536文字表現できれば十分だなんて言ったのは。
とはいえ、もうこのレベルになると追加されるのはもうほとんど使われないような文字ばかり。 特に台湾から来たものとかは「ある特定の個人の名前に使われているだけ」とか ちょっとどうなのよ、というものもある。その人が死んだらもう歴史的文字になっちゃうね。
自分が死んだ後に歴史に名を残すのはなかなか難しいことで、 大半の人たちは200年もしないうちに存在すら定かではなくなってしまう。 それを思うと、Unicodeという国際規格に自分の名前を残すというのは 良い考えかも……迷惑だから、やめてください。ダメ、ぜったい。