「笠原一輝のユビキタス情報局」より。
前回筆者は、今の日本のコピーワンス方式は容認できないと書いた。なぜなら利便性や自由度を損なうという、ユーザー側の論理だけでなく、日本の産業界にとっても、そして結果的にはそれを強いている放送業界の側にとっても有害なモノであると思うからだ。
(中略)
日本の機器ベンダが日本独自の事情に振り回されているうちに、海外のベンダがどんどん魅力的な製品を作り、それを海外でどんどん投入されたら、どうなるか。今後、デルなどのIT系企業がデジタルAVに参入してきた時に、高コストの日本企業は太刀打ちできなくなる可能性がある。日本向け製品と海外向け製品で別の製品を作らされることになれば、それだけ日本の機器ベンダの競争力が低下していくからだ。
(中略)
その結果、日本企業は広告に回せる費用が無くなり、広告を出すことが難しくなる。そうなれば、広告収入に頼っている放送業界にとってもかなり痛い状況になるのではないだろうか。これは言ってみれば“最悪のケース”だが、このまま突き進めば、こうなるのは目に見えているのではないだろうか。
それなのになぜ、良い点だけしか視聴者に示さず(放送業界からコピーワンスの件について聞いたことはない、隠しているとは言わないまでも、触れたくないとは思っていそうだ)、「破滅への道」を突き進むのか。
音楽業界でも同じようなことが起きた(起きつつある)。
なぜ、ネットワークウォークマンが受け入れられなかったのか、それはソニーの幹部が認めているとおり、サポートするコーデックの著作権保護(DRM)を厳しくしすぎたため、ユーザーにそっぽを向かれたからだ。
しかし、そんなことになる前に、もっと緩やかな著作権保護を採用するなどの選択肢はなかったのだろうか? おそらく、ソニーの関係者も心の中では「こんなモノだめだ」と思っていたのだと、筆者は思う。実際、筆者もある機器ベンダの社員に「こんなのじゃ受け入れられないと思いますよ」と何度も言ってきた。そうした時に、機器ベンダの関係者から帰ってきた答えは「それはよくわかっている、でも駄目なんです」というものだった。
駄目だとわかっているのに、できなかったのだ。なぜかと言えば、レーベル側が強行に駄目だと言い続けてきたからだ。
目先の利益しか見えない経営者たちによってコンテンツホルダー、ベンダー、ユーザーすべてが不幸になる。 それがコピーワンスや強ＤＲＭのたどる道だ。手遅れにならないうちに手が打てないものか。
本国で不調な言語ビジネスを引き取った(株)カールが生き残るために模索を続けている。
最近のAjaxやJSON*1のようなテクノロジートレンドの前にはますますCurlは不利のような気がするけど、それでもなお、Matzにっきは言語ビジネスに果敢にチャレンジする(株)カールを応援します。
年＄５０でホスティングを、というのはあまり珍しくないし、単にRubyが使えるというのだと普通の話だが、
までサポートするのはちょっと珍しい。それだけではない。ここは更に
までサポートしているそうだ。なんと勇気があることだ。
出社前に妻と二人で電子ピアノを二階の子供部屋からリビングへ移動。 子供たちが最近一階にばかりいてちっとも練習しないから、というのが理由だが、 練習嫌いの子供たちには別の動機づけが必要なのかもしれない。
それはそれとして、電子ピアノとはいえ結構重い。 腰を壊すかと思った。
「本田雅一の週刊Mobile通信」より。
カリフォルニア州マウンテンビューにあるComputer History Museumに見るコンピュータの歴史。 ハードウェアが着実に、安く、速く、小さくなっていく歴史を目で見ることができる。 この博物館には一回行ってみたいな。
しかし、ソフトウェア、特にプログラミング言語の方はさほど進化していないなあ。 少なくともFortran、COBOL、Lispが生まれた５０年代のコンピュータと現代のコンピュータほどの違いはない。 それどころか時代がやっとLispに近づいてきた程度ではないかと。
まあ、言語ってば基本的には「思考のための記法」なので、 人間がすぐには進歩しない以上、そんなに急激には変われないんだけど。
アップルは年に2〜3回新製品を発表するが、その度にマック・ファンが熱狂して、マスコミの目を引く。アップルは、その狂騒に乗じて広報活動を行っている。オープンソース・プロジェクトは、こうしたアップルのやり方に学ぶべきである。広報こそ新しいユーザーを獲得する鍵であり、新しいユーザーはオープンソース開発モデルの活力なのだから。
なるほど。考えてもみなかった(だからダメなんだ)。
となると、1.8.4のリリースはOSCONの会場からというのはどうだろう。
問題は宣伝文句だな。完全安定期に入った1.8系では目新しい機能は入りそうにない。 人目を引くためには、もっとたくさんの機能が追加されたリリース、つまり1.9系を打ち上げるしかない、か。
それは開発者サイドにはあんまりうれしくないかも。
上のエントリでも触れたJSONはJavaScript Object Notationで、 JavaScript(やPython)で読み込める記法でオブジェクトを表現しようという試み。
過去に私が「私はなぜXMLを愛していないか 〜 言語屋の視点から」で書いた XMLへの不満に対する答えにもなっている。
JSONは以下のような「XMLは優れている」という主張ひとつひとつについて、 「少なくとも同程度には優れている」ことを丁寧に示している。
詳細は上記JSONページを見ていただきたいが、 要約すると「JSONはXMLと違って拡張(新規タグの定義)とかはできないし、 ドキュメントマークアップ言語ではないが、 データ表現フォーマットとしては単純性、相互運用性、可読性において同等か、より優れている」ということだ。
Rubyに変換するのも簡単だ。 YAMLとどっちが優れているか、決めるのはちょっと難しいかも。
単純さではJSONの勝ちだが。
*1 正確にはJSONはAjaxではなく、XMLやYAMLと同類のテクノロジーである。Ajax的アプローチでXMLの代わりにJSONを使うことが注目されているというだけのこと。
コンパラの実装技術も歩みはのろいですね。
Todd Proebstingは、ムーアの法則をもじって「コンパイラの最適化の性能は18年で二倍になる」と言っています。
Rubyのロゴを決めます！とか。
コンペをやるといろいろと取り上げられると思うのです。
＃もちろん出来レースで、無難に宝石ルビーをあしらったものに決まる
パパと一緒に連弾とか、かずひこと一緒に連弾とか...＞動機づけ
> 効果的なリリース
そこで肉の日リリースですよ。
＞コンパラの実装技術も歩みはのろいですね。
去年は「GPUをCPUのように利用する・・・」でした
コンパイラの最適化技術の確立はプロセッサ登場から4〜5年は掛からないと難しく、GPUのように短期間に仕様が劇的に改良されてしまうプロセッサでは、コンパイラ技術の進化が追いつかず、
http://pcweb.mycom.co.jp/articles/2004/08/09/gp2/001.html
今年はCell が出たのでSPEのマルチコア使いが注目されるでしょう。