kouさんのツッコミから。
あと、バザールの基本は好きな者に好きなようにつついてもらう点だと思うのですがSC○みたいなのに粘着されてモチベーション下げるような事も避けたい所ですし。
SCO問題は、Linuxが主題になっているのでオープンソース問題であるかのようにとらえられがちだが、 実際にはオープンソースとはまるで関係ない。彼らの主張は法廷と法廷外で全く違う点に注目する必要がある。
法廷での彼らの主張はこのようなものだ。
IBMはSCOとの契約に反して、SCOが権利を持つUNIXに含まれる技術をLinuxに持ち込んだ
つまり、その本質は「契約違反」である*1。 それは真実かもしれないし、そうでないかもしれない。 が、少なくともこの論理ではSCOと契約を結んでいないものは関係ない。 そもそも契約を結んでいないのだから、契約違反は発生しえない。
つまり、たまたま訴訟の一部に(オープンソースソフトウェアである)Linuxが関連しているという以上には、 この訴訟とオープンソースソフトウェアは関係がない。 これはオープンソースでない他のソフトウェアでも発生しうる問題だ。
ところが、法廷外ではSCOは
LinuxにはSCOが権利を持つコードを含んでいる。 だから、その権利によってLinuxを利用するためにはSCOとライセンスを結ぶ必要がある。
でなければ、(IBMのように)訴えるぞ。
とほのめかしたのである。みごとなFUDだ。
こちらの主張が真実である可能性はかなり低い。 迷惑な話だが、上のような「ほのめかし」程度では罪になるとまでは言えないような気がする。 粘着されるのはたいへん迷惑な話であるが、オープンソースが世間的に注目されるようになると、 なんらかの攻撃の対象になるのは避けられないことのような気がする。
静かにほそぼそとフリーソフトウェアを開発していた頃は平和だった。 が、それで飯を喰える状態ではなかった。
オープンソースが注目される今は、飯は喰えるが、粘着される危険性は高くなった。
なかなか、万事うまくいくとは行かないものだなあ。
*1 最近、SCOは著作権を争点に加えたが、成功しているとは言えないなあ
続いてkouさんのツッコミの前半から。
つい最近こういう記事もありました。
>「UNIX開発者のバックドアを思い出せ」−Linuxの軍事利用に警鐘
><URL:http://www.itmedia.co.jp/enterprise/0404/14/epi04.html>
この記事を読んで思ったことは、Eric Raymondが語った「沢山の目があれば、どんなエラーも恐くない」*1という言葉は誤解されているということだ。
もちろん、ソースコードが公開されていて、チェックすることができる人がたくさんいれば、 バグは早く見つかるし、対応も速い。
が、だからと言って、どんなにレビューアーがいようと、何人開発者がいようと、 ただそれだけでは、問題が発生する前にバグが発見されるなんてことは決してないということだ。 Ken Thompsonがバックドアを仕込んだ経緯は知らないが、 そのバックドアは14年間決して利用されず、問題は発生しなかったのだろう。 よって積極的にはチェックは行われず、発見もされなかった。
オープンソースの良さは、問題が起きちゃったらすぐに対応できる点だ。 一度でも問題が起きたら困るケースで、 問題が発生する前にバグを発見するためには、地道なテストスイート作成と 繰り返しテストすること、積極的なコードレビューが必要だ。 それはオープンソースだろうとそうでないソフトだろうと同じこと。
さて、ITmediaで紹介されていた。「ダン・オダウド氏」なる人物の主張は
前二者には限定付きで同意できないことはない。 確かに、アメリカと利害関係が対立する人物がLinuxにコードをcontributeして、 そのコードに発見しにくい巧妙なバックドアを仕掛ける「陰謀」が存在する余地が まったくないと断言するのは難しい。
もっとも、そのためにはバックドアは
という相反する要求を満たし、 かつバージョン管理でそのコードがいつ誰によってコミットされたかが明らかになる危険性をかいくぐる必要がある。 もちろん、天才的コーディングでバックドアを用意し、 バージョン管理サーバーもクラックするのだろう。映画みたいだ。
そのような危険性があるので軍事関係にはLinuxを使わないとする。 だとしても私はいっこうに構わないのだが、仮にLinuxを使わないのだとすると、 代わりになにを使うべきか。「安全だと立証されたソリューション」とはなにか。
Windows? Solaris? AIX?
上記の困難を乗り越えてLinuxにバックドアを仕込むという 陰謀説を信じることができる人が、WindowsやSolarisなら大丈夫と言える感性が私には不思議だ。 アメリカ企業たるMicrosoftによって作られているソフトウェアなら安心ということだろうか。 私には、ロシア人開発者よりもマイクロソフトの方がよっぽど野望を持ちそうに思えるのだが。 第三者が検証することは事実上不可能だし。
たいへん(アメリカ的)愛国心のある話ではあるが、論理的ではない。
あるいは「安全だと立証されたソリューション」とは、 身元がはっきりした人間だけを用いてコンピュータは使わないことか。 論理的だが、現実的ではない。
いや、身元がはっきりしているはずの人間が内通者になるのはスパイ映画では常道だ。 誰も信じてはいけない。安全などないのだ。Trust no one.
追記:
KLさんのツッコミによれば、
「安全だと立証されたソリューション」...というのは、Green Hills SoftwareのOS(フットプリントがLinuxに比べ極めて小さく、ソースコードは米航空連邦局の監査をパスしている)ということになります。
だそうだ。うーん、それならそれで論理的ではあるが...。
ということは、軍事目的のOSはすべてそのような小さなOSしか使うなって主張なのかな。 論理的ではあっても、非現実的ではないかなあ。
*1 正確な文言は忘れちゃいました。後で調べておきます
7月6月4日にRails Dayが開催される。
これは24時間の間にRailsを使ってどのようなアプリケーションを作ることができるかを競うコンテストである。
ルールは以下の通り。
Your application must be written in Ruby on Rails
アプリケーションはRuby on Railsで記述されなければならない。
Your application must use MySQL
アプリケーションはMySQLを使わなければならない
Your application must be under a license where the code may be viewed by the general public (for inspiration and as a reference). The rest is up to you.
ソースコードは一般に対して公開されなければならない。ライセンスは自分で決めてよい
Your application should be written totally within the 24 hour period. Photoshop comps, CSS and Javascript are included in this time.
アプリケーションは24時間で記述されなければならない。Photoshopによる画像作成、CSSおよびJavaScriptもこの時間に含む
Only libraries installable via gem are allowed. However no gem that uses any of the components of rails is allowed.
RubyGemでインストールできるライブラリだけが使用可能。ただし、Railsのコンポーネントを利用したGemは利用不可
Up to 3 people are allowed to work on a single entry.
ひとつのエントリには三人まで
You are allowed to dream up the idea before the competition you can also do paper mock-ups of database schemas and UIs. No digital mockups any more complex than a paper napkin drawing are allowed before the competition begins.
事前にアプリケーションを夢想するは許される。 スキーマやインタフェースのプロトタイプを紙の上でまとめるのもOK。 ただし、実際のプログラムやペーパーナプキンのメモ書き以上のものは競技開始前は禁止
The applications will all be hosted on the competition server. You will have 24 hours of subversion and ssh access to the server to upload and test your app.
アプリケーションは競技用サーバーでホストされる。競技中は24時間のsubversionとsshアクセスが許される。
You must use subversion and checkin your work at least 12 times at various stages of development
競技中はsubversionを用い、開発のそれぞれの段階で最低12回はチェックインすること。
審査員
著者校正。今回は手紙文ということで、編集がほとんど手を入れなかったのと 引用部の文字幅がやや狭いのでなんと27行オーバー。記録だ。
あちこちをごそごそと削る。 本当は「4大マイコン誌」の話とか、 昔話を一杯書きたかったんだけどなあ。
最近、「CommonLispはLisp-2で、SchemeはLisp-1である」という文章を読んだが、 恥ずかしながらLisp-1とかLisp-2ってなんのことだかわからない。 Lisp 1.5なら知ってるんだけど。
ので、調べてみた。
で、その結果、名前空間がひとつ(関数と変数に区別がない)のがLisp-1で、 区別があるのがLisp-2であるということだそうだ。なるほど。
だとすると、PythonやJavaScriptはLisp-1で、RubyはLisp-2だな。
スクリプト言語に欠けているもの、という話。
まあ、最後のものはともかく(Javaよりも開発者が少ないという意味らしい)、 残りについては自覚はしている。次第に改善されるんじゃないかな。
Ruby 2.0ではぜひAST(Abstract Syntax Tree)が欲しい、という話。
一度公開しちゃうと変更できなくなって面倒だから、 という非常に開発者の都合で公開していないんだが、 やっぱりAST機能欲しいんかねえ。
いっそ、RubyのソースコードからS式を吐くフロントエンドを作るというのはどうだろう。 で、S式からYARVバイトコードを作るとか、Gaucheに喰わせるとか。
その場合、Rubyってのは本当にLispの一種になっちゃうね。 なんとなく先祖帰りな雰囲気。
「毎秒、11,000アクセスというのはすごいけど、それDBアクセスいらなくね？」という話。
確かに毎秒11,000回DBにアクセスすると大変なことになりそうだけど、 Twitterの性質をよく考えてみると、そもそもDBに格納する必要のない情報ではないだろうかと。 ActiveRecordのおかげでDBアクセスが簡単になって、 DBを単なるストレージのように扱えるが、本当はSQLデータベースに向いてない使い方も されているんではないだろうか、という指摘。
あと、毎秒11,000アクセスってのは純粋にものすごい数で、 それってAPの設計の見直しでもうちょっと下げられるような気もする。
「なぜRailsはRubyでしか可能にならなかったのか」という話。 TurboGearとかDjangoの人とかは「Pythonでもできたぞ」とか言いそうだけど。
それはRubyismのおかげだそうで、で、「Rubyismとはなにか」ということは、 『Rubyisms in Rails (Digital Short Cut) - $9.99』を読むとわかるんだそうだ。
そうかぁ。 $9.99かぁ。
Rubyのメタプログラミング機能を使ってプロパティやプラガブルタイプを実現する、 という話。
ところで、例題に
property :speed {|v| v >= 0 && vn< 300 }
というコードがあるが、これはSyntax Errorになる。 これはRubyのパーザーが「:speed {|v| v >= 0 && vn< 300 }」をメソッド呼び出しと 解釈しようとするからだが、数値、文字列、配列、シンボルなど 識別子以外のものの後ろのブレースの優先度が高すぎるのが原因だ。
ということで、1.9の文法を少々いじって、文法エラーでなくすことにした。