Stefans Welt » Blog Archive » XML parser performance in CPython 3.3 and PyPy 1.7
なかなか悪くないな。しかし、やはり本格的なものが欲しければ、Cなどの別言語での実装のバインディングを使うことになるだろうが。
2012-05-14
Python話者からみたDart
Coder Who Says Py: My (very shallow) thoughts on Dart
欠点：コンストラクターの種類が多すぎ。
確かに、Dartにはコンストラクターの種類が多すぎるとは思う。特に、Factory Constructorの機能は、少し難しい。
筆者は、この膨れ上がったコンストラクター仕様は、Javaの影響だろうと推測している。
Wasteland 2の開発はUnity Engineで行われることに決定したようだ
Wastelandは、本来続編が出るはずだったのだが、権利関係がこじれていたため、別の名前として出された。その名前とは、Falloutである。そのWastelandが続編を開発するために、資金をKickstarterで募っていたのは記憶に新しい。興味深いことに、150万ドル以上集まれば、GNU/Linuxへの移植も行うと明言していたことだ。すでに150万ドル以上集まっているのだが、果たして約束は果たされるのか。
最近、公式フォーラムで開発者の求人が投稿された。それによると、Unity Engineを使うことに決まったらしい。
Wasteland Survival Guide • View topic - We are hiring engineers!
Linux対応の可能性が高まってきた。ゲームエンジンとしてのUnityは、今はまだGNU/Linuxに対応していない。しかし、Unity Technologiesは過去に、GNU/Linuxゲームが開発されることがあれば、移植作業をすると発言している。
さて、どうなることやら。
そもそも、私は最近の、昔のゲームの続編という形で、全く違うジャンルのゲームを出すのが好きではないのだが。
2012-05-13
FreeBSD 10はGCCからLLVM/Clangに移行する
[Phoronix] FreeBSD 10 To Use Clang Compiler, Deprecate GCC
FreeBSDのGCC離れが加速しているようだ。FreeBSD 10では、Clangがデフォルトのコンパイラーとなり、GCCはdeprecated扱いとなる。FreeBSDの思想からすれば、GNUのツールチェインからなるべく離れたいのは分かる。Clangのライセンスは、FreeBSDにとって非常に都合がいい。
すでにFreeBSDのカーネルは、Clangによって警告なしでコンパイルが通るそうだ。FreeBSDのパッケージも、「Clangでビルドできなければバグ」とみなして、問題の洗い出しを進めているそうだ。
LLVMとClangは、最近、目覚しい発展をしている。GCCがコードベースのモジュール化を検討するほど危機感を持つのも分かる。
その他のFreeBSDの動向については、[Phoronix] FreeBSD Achieved A Lot In Q1'2012
近未来のコンピューター
ここ数日、近未来のコンピューターという考え方が頭から離れないので、書きだしてみることにする。
未来を予測するのは難しいが、一つだけ確かなことがある。プロセスルールの微細化が、少なくとも今後10年以内に終わる。つまり、ムーアの法則が破れることになる。
ムーアの法則というのは、物理法則でも何でもない。本来、ムーアの予言とか約束などと呼ばれるべき言葉だった。1965年、Intelのゴードン・ムーアが論文を出して、それが他人に引用されるうちに広まった考えで、最も単純化された考えとしては、「集積回路のトランジスタ数は18ヶ月で倍になる」というものである。
製造の裏方では相当な努力があったにせよ、ムーアの言葉通りにトランジスタの密度は増え続けた。同時に、クロック周波数も上がり続け、コンピューターの実性能も、倍々に増えていった。しかし、クロック周波数の上昇は、すでに限界に達した。もちろん、まだもう少し上げることはできるが、商業的に成り立たない。一方、集積回路の微細化は、まだしばらく続いた。
いま、最新の商業的に製品が出荷されているプロセスルールは22nmまで達したが、そろそろ限界が近づいている。私の予想では、一桁nmの製品が出るとは思えない。おそらく2022年頃には、プロセスルールの微細化は止まるだろう。
するとどうなるのか。再びクロック周波数の上昇を目指すのだろうか。しかし、そんなことは今でも行われている。もはや、CPUのクロック周波数は固定ではなく、動的に変化するようになっている。それほど極端には伸びないだろう。
トランジスタ数とクロック数の現実的な上限が示されたとき、何が起こるのか。まず真っ先に考えつくのが、アーキテクチャの抜本的な改善である。フルスクラッチから設計した全く新しいアーキテクチャで性能向上を目指すのだろうか。
おそらくうまく行かないだろう。アーキテクチャを変えた所で、極端な性能向上はないだろうし、過去のソフトウェア資産も捨てられない。カリカリに最適化されたベンチマークコードのスコア上昇のために、過去のソフトウェアをすべて諦める人間はいない。
さて、この状態で数十年経つと、過去の特許が切れ始める。技術を自由に使えるようになり、少しだけ技術発展があるかもしれない。しかし、性能向上は微々たるものだろう。より安価なハードウェアや、自由なハードウェアが登場すれば、ユーザーの利便性は向上するかもしれない。
極端に並列化できる処理は、専用のAPUに任せるHeterogeneousなアーキテクチャのコンピューターの時代になるかもしれない。すでに、GPGPUは一部の分野では素晴らしい性能を発揮している。しかし、極端に並列化できる処理というのも、結構限られている。
全く異なる動作原理のコンピューターは、まだしばらく実用化されないだろう。タダ飯の時代は終わるのだ。
2012-05-12
TIOBE indexをみて考えた
IIOBE indexは、毎月、有名な検索機能を提供しているサイトからプログラミング言語を検索して、結果に基づき、言語のランク付けをしているサイトである。もちろん、そのランクが実情と合っている保証はないが、なかなか面白い。詳しい集計方法は、TIOBE Software: Tiobe Index Definitionを参照。あくまで、プログラミング言語のランキングなので、HTMLのような言語は含まない。SQLもプログラミング言語ではないので含まれないが、PL/SQLはプログラミング言語なので含まれる。
さて、今月興味深いこととして、Objective-CがC#を抜いて4位になったのだ。やはり最近のAppleの影響力は強いのだろう。
先月から、CがJavaを追い抜いて第一位に返り咲いた。もっとも2004年のJavaの一時的な下落は、Googleの検索アルゴリズムの変更によるものなので、過去10年で初めて一位になったというべきか。TIOBEは2004年の一件以来、複数の検索エンジンを含めるようになっている。
ではCのランクが上がったのかというと、そういう訳でもない。ここ数年はやや上昇しているように見えるが、10年でみると、2.5%下がっている。とはいえ、まだCの地位は安泰だ。このペースで下がり続けるとしても、あと70年は持ちこたえることができる。この業界で70年と言えば、永遠だ。もっとも、下がるとなれば急激に下がるだろう。ただし、すでにCで書かれたソフトウェア資産や、いまだに活発に開発が続いているCで書かれたソフトウェアをみると、Cの地位はまず安泰だろう。
Cのさしあたっての問題は2038年問題だろう。おそらく、Cは今後も22年以上使われることは疑いようがない。また、多くの言語の実装はCに依存している。そのため、ほとんどの言語は2038年問題の影響を受ける。たとえ標準ライブラリによらない日付管理を実装しているとしても、やはり怖いことは怖い。一体どうやって解決するつもりなのだろうか。多くの不自由なソフトウェアは、すでにソースコードが失われている。修正しようがない。SF小説的な考え方をすれば、2030年代後半に、既存の多くのソフトウェアの日付がUNIX時の起点時間まで逆転し、正しく動作しなくなる。コンピューターに頼り切っていた社会は混乱し、未曾有の人災が引き起こされるとなるだろう。
Cで気にかかるのは、どうも世代交代がうまく行っていないという事だ。相変わらず昔のC、つまりC89が使われている。C99やC11はなかなか受け入れられていない。
第二位はJavaだ。ただし、Javaは死につつある言語だ。もはや未来はない。まだJavaを使っているとしたら危機感を持つべきである。
第三位のC++も安定している言語だ。ただ、やはりどうも下がりつつあるような気がする。
第四位はObjective-C。ただし、この言語は専らAppleの不自由なデバイスのためのソフトウェアを書くのにしか使われていない。Appleの興隆に伴い、仕方なく使われている。個人的には嫌いな言語である。
第五位はC#。出た当初は、第二のVBとして、MS専用言語に成り下がるかと思っていたら、どうも最近調子に乗っている。monoのおかげでマルチプラットフォーム化したので、かなり広く使われている。今月のランクは下がっているが、かなり上昇傾向にある。
第六位はPHPだが、ここ数年、ランクが下がりつつある。PHPについては、プログラミング言語として、いい噂を全然聞かないのだが、Webサイトには非常に広く使われている。言語としてかっこいいかどうかというより、泥臭くとも動くほうがいいのだろう。
第七位はVisual Basic。ただし、Basic系言語をすべて含むらしい。とはいえ、もはや今使われているBasicはVBやVBAぐらいなものであろうから、実質VBといってもいいだろう。まあこれは・・・未だに過去の栄光は強いと言ったところか。
第八位はPythonだ。Pythonは個人的に気に入っている言語であり、将来はスクリプト言語として標準の地位を占めるのではないかと思うのだが、今の所、爆発的にランクが上がる傾向にはない。
第九位はPerl。未だに根強い信者のいる言語だ。個人的には、文法が汚くて好きになれないのだが。
第十位はJavaScript。これはやや不思議だ。JavaScriptはもっとランクが高くてもいいはずなのだが、なぜか下にとどまっている。個人的には、C#とObjective-Cの上に位置すべきだと思うのだが、何故か低い。今や、ほぼすべてのWebサイトがJavaScriptに頼っていることを考えると、このランクは非常に意外だ。思うに、JavaScriptは本物のプログラミング言語としては、いまいち意識されていないのか、あるいはあまり表に出てこないのか、それともTIOBEの集計方法に問題があるのか。
UbntuにGNOME版が来るか？
[Phoronix] A GNOME Flavor Of Ubuntu - "GNOME-buntu"
GNOME Flavor - | The Summit Scheduler
UbuntuにGNOME版が来るかもしれない。
まあ別に、今でもパッケージとしては存在するから、入れようと思えば入れられるのだが、やはり最初からデフォルトで入っていて、GNOME関連の他のソフトウェアもデフォルトで追加されていて、しかもテストされているインストールディスクというのが、欲しい人も入るのだろう。
2012-05-11
Ubuntuで/と/usrがマージされるかも
UNIXシステムでは、伝統的に、ルートディレクトリに/bin、/sbin、/libがあり、また、/usr下にも同名構造のディレクトリがある。ルートディレクトリでは、システムの基本的なツールやライブラリを入れておき、/usrでは、それ以外のものを入れておくという使い方がなされている。
/usrはシステムに必要不可欠ではないから、/usrをマウントせずともシステムはブート可能であるという伝統的な思想がある。しかし、今や話はそんなに単純ではなくなった。今のシステムは、GUIやら何やらと色々あり、/usrに依存せずブートするというのは不可能だ。では、/usrのうちブートに必要なものはすべてルートディレクトリに移すべきだろうか。そもそも、なぜ今時分ける必要があるのだ。ディレクトリが複数あると、管理が面倒だ。バックアップにしたって、なるべくディレクトリは少ないほうがいい。
というわけで、Ubuntuでは/とusrをマージする計画がある。従来のルートディレクトリ下にある/binや/sbinや/libは、それぞれ、/usr/bin、/usr/sbin、/usr/libへのシンボリックリンクになる。
これは、なにもUbuntuが初めてというわけではない。すでにFedoraが先行してマージを実行している。
2012-05-10
囲い込みの代償
韓国は、政府によるインターネット整備が抜きん出ていた国である。アメリカ合衆国が暗号を武器とみなし、輸出を制限していた頃、鍵長が40bitのSSLに不安を感じ、独自の暗号規格、SEEDを開発した。さらに、法律を制定して、オンライン上の通貨取引には、かならずこの暗号を使わなければならないと定めた。
暗号としてのSEEDは、鍵長が128bit固定であることを除けば、今のところ、大した欠陥は見つかっていないようだ。問題は、その実装にある。
ブラウザー上のSEEDの実装はActive Xのみなのだ。他のブラウザーはサポートしていない。唯一、FirefoxだけがSEEDを実装しているらしいが、暗号としてのSEEDを実装しているだけで、他の部分の規格を実装していないので、それだけでは役に立たない。つまり、韓国でのオンラインでの銀行取引やネットショップなどは、必ずIEを使わければならない。さもなければ、法律違反となる。（AmazonとかPaypalなどはどうしているのだろうか）
つまり、韓国民の大多数は、いまだにMS WindowsとIEに縛られているのだ。
もちろん、韓国政府とて、いい加減に、現状の悲惨さには気がついており、法律を一部改正して、少なくとも三種類のブラウザーをサポートすることを条件として、Active Xプラグインの法律による強制をやめた。しかし、官僚主義の弊害は残っている。
もし、Active Xの使用を辞めたい場合、同等の保護をもたらす政府によって認可された暗号技術を使わなければならない。政府による認可を得るには、該当の部署に届けなければならないが、この部署は、いままでに一度もそのような認可を下したことがない。
まだまだ囲い込みの弊害は続くのである。
思うに、国家の法律制定速度というのは、技術の向上速度に比べて、あまりにも遅いのではないか。そのため、あまりに具体的な指定をすると、すぐに時代遅れの法律になってしまう。
South Korea Still Paying The Price For Embracing Internet Explorer A Decade Ago | Techdirt
将来、世の中は自由なソフトウェアと不自由なソフトウェアに二分される
私の予想では、今後世の中は、自由なソフトウェアと不自由なソフトウェアに二分される。ユーザー側からみれば、両者の溝は厚く、完全にお互いを遮断するだろう。
AppleやMicrosoftといった不自由なソフトウェアの信奉者は、自己のプラットフォームには、己の期待するソフトウェアしか提供されないように努力する。たとえば、気にいらない競合ソフトウェアは、公式のソフトウェア配信システムには載せないようにし、また、プラットフォーム自体にも、公式のソフトウェア配信システム以外からソフトウェアを導入できないように制限を加えるだろう。制限を迂回するには、暗号を解くか、OSを構成するソフトウェアに非公式なパッチを当てなければならなくなるだろう。
AppleやMicrosoftは、オープンソースに貢献しているではないかという意見もあるだろう。たとえば、AppleはClangにだいぶ金と人を出しているし、ついこの前、Linuxカーネルへのパッチ数での最大の貢献者はMicrosoftであると発表されたばかりだ。これには理由がある。自分に都合のいい貢献なのだ。
たとえば、Appleの場合、自分のプラットフォームのためにまともなコンパイラーがほしいという理由がある。もはや、コンパイラーを伽藍方式で開発する意義は薄れた。コンパイラーが正しく動作するかどうか検証し、もし動作しないとしたらすぐに修正できる体制をつくるには、もはや長時間の閉鎖的な開発の末に完成品を公開するという伽藍方式では立ちゆかないのだ。
MicrosoftのLinuxカーネルへの貢献は、主に、自社の仮想化技術の上で、Linuxカーネルが動作するような変更である。Linuxカーネルのサーバーにおける普及率の高さから考えて、サポートしなければ、自社の仮想化製品に魅力がなくなるからである。
つまり、人は自分に都合のいい貢献しかしない。
ソフトウェア配信システムは、必ず不公平になる。胴元は、あらゆる理由で、自分の意にそぐわないソフトウェアを排除する。自己のソフトウェアと競合する、セキュリティ上の懸念、リソースの浪費、彼らの定義によれば悪用される可能性があるなどという理由でだ。
たとえば、Google PlayはNiftyの動画再生ソフトウェアを不思議な理由で拒否した。Google Web Storeは2ちゃん専用ブラウザを不思議な理由で拒否した。Appleについては、もはや個別の例を挙げるまでもあるまい。Microsoftが提供するソフトウェア配信プラットフォームだって、似たようなものになるだろう。すでにMSはARM版WindowsからFirefoxを排除する動きをみせている。
もちろん、物理的店舗に置く商品の選択は物理的店主が決めるように、デジタル店舗に置くソフトウェアの選択はデジタル店主が決定権を持つ。しかしそれは、誰でもデジタル出店ができるという世界で初めて公平になる。もし、公式のデジタル店舗が唯一のソフトウェア配布プラットフォームであれば、もはや自由はない。
ソフトウェア配信システムは悪ではない。実際、私だって、ソフトウェア配信プラットフォームの運営者は、提供するソフトウェアに品質やセキュリティを保証してほしいし、ソフトウェアはもちろんコード署名され、配信途中に第三者により書き換えられることがないように保証して欲しい。これを実現するためには、ソフトウェア配信システムは不公平な選択をし、ソフトウェアの実行には技術的制限をほどこさねばならない。これ自体は悪ではない。しかし、もし公式なソフトウェア配信システムが、唯一のソフトウェア配信プラットフォームであり、それ以外にソフトウェアを導入する方法がないとしたら、この実装は邪悪になる。
もし自由なソフトウェアのみで構成されたプラットフォームがあり、ソフトウェア配信プラットフォームのプロトコルも自由な規格であれば、誰でも技術的に同様のソフトウェア配信が可能になる。ソフトウェア配信プラットフォームの追加は、単にサーバーリストに追加する程度の手間で済む。もちろん、規格自体が気にいらなければ、別の規格を設計、実装することもできる。自由なソフトウェアでは、技術的な制限を取り除くことが容易だ。公式のソフトウェア配信プラットフォームが気にいらなければ、自分で別のプラットフォームを立ち上げることができる。この点で、自由なソフトウェアは重要である。
近い将来、ソフトウェアは自由なソフトウェアと不自由なソフトウェアに二分される。もちろん、自由なソフトウェアは実行に制限を設けないので、条件次第で、不自由なソフトウェアでも使われるだろう。また、不自由なソフトウェア陣営の利益になると判断した部分だけは、自由なソフトウェアへの貢献があるだろう。しかし、ユーザー側からみれば、基本的なソフトウェア環境であるプラットフォームの実装は、完全に自由なソフトウェアか、不自由で制限されたソフトウェアかのどちらかになるだろう。
世界は二分される。
2012-05-09
Ubuntu 12.10ではUnity 2Dが廃止される
[Phoronix] Unity 2D To Go Away In Ubuntu 12.10
Ubuntu 12.10では、Unity 2Dが廃止されるそうだ。Unity一本に開発リソースを集中するつもりらしい。
では、OpenGLを十分にサポートしていないハードウェアはどうするのかというと、LLVMpipeを使うらしい。
LLVMpipleというのは、OpenGLのソフトウェア実装である。LLVMを使うことにより、ネイティブコードを生成して実行できる。そのため、ソフトウェア実行でも、ある程度のパフォーマンスが得られる。ゲームができるほどではないが、UIとしては実用に耐えるパフォーマンスとなる。
それにしても最近、LLVMpipeがにわかに脚光を浴びている。なかなか面白い。
追記：
Unity 2Dが廃止されるのは、そもそもUnity 2Dの開発者であるAurelien Gateauが、とっくの昔にCanonicalを辞めて、Blue Systemsで職を得たからである。Unity 2Dは、実はQt上で実装されているのだ。Canonicalにはおそらく他に、Qtに関する十分な知識を持った他の技術者がいないだろうし、開発中止は必然である。
LLVMpipeは魔法の技術ではない。所詮はOpenGLのソフトウェア実装に過ぎない。まともに使えるパフォーマンスを得られるのは、マルチコアのx86かx86_64アーキテクチャぐらいに限られるだろう。ARMやMIPISなどでまともなパフォーマンスが期待できるわけがない。そもそも、ARMやMIPSは、スマートフォンやタブレット、極小のノートPCなど、パフォーマンス重視ではないプラットフォーム向けでよく使われている。まあ、そのような環境では、大抵OpenGLを実装したGPUも提供されているのだが、問題は、大抵不自由なドライバーを必要とする。
たとえUIを使える程度のパフォーマンスを出せたとしても、かなり重い処理になる。つまり、CPUを酷使することになる。すると、電力消費が増える。GUIを動かすだけでCPUがフル稼働していては意味がない。GPU的には比較的軽い処理っであるCompizでさえ、ゲーマーからオーバーヘッドの問題を非難されているのに、OpenGLのソフトウェア実装の稼働を必須にした日にはどうなることか。
そもそも、ムーアの約束が敗れる日は旦夕に薄っている。これ以上、集積回路の密度が上げられない日が近い将来やってくる。実際、すでにCPUのシングルコアの性能はわずかしか上がってない。コンピューターのハード構成がHeterogeneousになっていくのは当然である。だから、コンピューターはCPUとGPUを両方搭載すべきであるし、GPUもある程度のプリエンプティブ性を確保して、GUIを提供するぐらいで極端なオーバーヘッドを引き起こさないようにならなければならない。
問題は、今のほとんどのGPUを動かすには、不自由なソフトウェアを使わなければならない。この状況は、近い将来覆されるだろう。Waylandへの移行が進めば、もはやGNU/LinuxはKMSに追随できない不自由なドライバーを切り捨てる。不自由なデバイスを切り捨てるのは当然だ。不自由なデバイスに固執するベンダーは、不自由な環境でほそぼそと生き残るか、自由に転校するかを迫られるだろう。
自由なソフトウェアの未来は明るい。
アブラハム・リンカーンは1845年にFacebookの特許を出願していた？
Abraham Lincoln Filed a Patent for Facebook in 1845
アブラハム・リンカーンは1845年にFacebookのような仕組みの特許を出願していたらしい。
画像が怪しいとかツッコミも入っているが、さて。
それにしても、いまどき墓標から発見があるとは。
2012-05-08
x32 ABIの簡易的なまとめ
x32とは、現在規格制定や開発が進められている、新しいABIである。これは、32bit ABIのx86と、64bit ABIのx86_64のいいとこ取りを狙ったABIである。
x86_64の利点は多数ある。まず、汎用レジスタが増える。CPUによるレジスタリネーミングだとかなんだとかいって、CPU側でこっそり隠しレジスタを用意して差し替える仕組みもあったが、やはり汎用レジスタの増加は、わかりやすいパフォーマンスアップに繋がる。もちろん、レジスタが増えるという事は、それだけプロセス切り替えのコストもかかるのだが、それを差し引いても、一部の純粋な数値演算のパフォーマンス向上は得られる。
また、仮想アドレス空間が大幅に広くなるのもすばらしい。実際、一部のソフトウェアでは、仮想アドレス空間が足りないという問題はすでに起きていた。確かに、PAEを使えば36bitのアドレス空間が得られるが、やはり一つのプロセスから直接見えるのは32bitアドレスであり、使いづらい。x86_64では、48bitものアドレス空間により、とりあえず仮想アドレス空間の枯渇の問題を、しばらく先送りできる。
しかし、問題もこのアドレス長にある。確かに、一部のソフトウェアは広い仮想アドレス空間を必要とするが、大多数のソフトウェアは、そんなに広い仮想アドレス空間を必要としない。無駄に広いアドレス長は、むしろオーバーヘッドになる。
しかし、そのようなソフトウェアでも、汎用レジスタの増加によりパフォーマンスが増加する場合もある。
そのような需要のために、アドレス長だけ32bitの64bitコードという、なんとも都合のいいABIが提案された。これが、x32である。ベンチマークの結果、一部のソフトウェアは、x86とx86_64の両方を上回るパフォーマンスが得られたという。
x32を使うには、ハードとソフトの両方のサポートが必要である。まず、ハードとしては、x86_64をサポートしているCPUでなければならない。ソフトは、多岐に渡る。
OSには、最低でも、Linux Kernel 3.4 x86_64が必要となる。コンパイラーには、今の所、gccが対応している。もちろん、gccもx32アーキテクチャをサポートする設定でビルドされていなければならない。x32に対応したデバッガーも必要だ。GDBが対応している。もちろん、x32に設定したビルドが必要だ。glibcを含めたライブラリも、当然x32に対応し、もちろんx32向けにコンパイルされていなければならない。ビルドツールにも特別な対応が必要だ。
と、このように、x32への対応は結構面倒である。すでにx86とx86_64両方でコンパイル、実行できるソフトウェアならば、コード自体には、よほど特殊なことをしていない限り、それほど変更は必要ないだろう。しかし、現時点ではビルド環境を整えるだけでも一苦労だ。もちろん、x32が普及すれば、構築済みのビルド環境を、よくメンテされたディストロのパッケージとしてインストールするだけで済むのであろうが。
x32は流行るだろうか。それとも、過渡期の実験的なABIで終わるだろうか。
詳しい内容やビルド環境の構築、ビルド方法については、以下のホームページ等で熟知すべし。
完全に自由なソフトウェア環境を求めて
完全に自由なソフトウェア環境のPCを手に入れるのは可能だろうか。少し考えてみた。
まず、BIOSが自由でなければならない。とすると、マザーボードの選択は非常に限られる。
Supported Motherboards - coreboot
corebootのサポートは、AMD用のマザーボードの方が圧倒的に優れている。これは、AMDはcorebootのために、チップセットのドキュメントを提供しているからだ。Intel用のマザーボードの対応はひじょうにおろそかだ。
もちろん、これだけではまだ不自由だ。なぜならば、マザーボード上には、BIOSではないソフトウェアがある。たとえば、NICやGPUやRAIDコントローラーなどだ。これらもすべて自由なソフトウェアでなければならない。
これを突き詰めるとどこまで行けばいいのかわからない。たとえば、マザーボードのソースコードである設計図は公開されているべきだろうか。公開されていたとしても、今使っているマザーボードが、本当に正しくソースコード通りに製造されたのかどうか、確かめるすべはない。第三者の検査機関が、電子顕微鏡を使って、製造ラインから無作為の抜き打ち検査を行うことで、初めてソースコード通りのマザーボードが製造されているかどうか確かめられる。
マザーボードに接続するデバイスでも、今やソフトウェアはふんだんに実行されている。NICやGPUはわかりやすい問題だ。とくに、GPUは、直接目にするものだけに、非常に気になる。現在、十分な3D描画性能を提供しているGPUの二大会社であるAMDとnVidiaは、どちらも大差がない。強いて言えば、AMDはRadeonの一部のドキュメントを公開しているだけ、マシだともいえる。しかし、全部ではない。それをいうと、nVidiaだってTegraに関しては、十分なドキュメントを公開している。そもそも、Tegraに関しては、公式ドライバーをコミュニティ主導の開発に任せているようだ。
本当の問題は、我々が普段、あまりソフトウェアを実行していると意識していないハードウェアにある。HDDやSSDといったストレージ上でも、BIOSとしてソフトウェアが実行されている。今や、マウスやキーボードやディスプレイにだって、ソフトウェアが使われている。これも全て自由でなければならない。しかし、これらのハードウェアは、あまり強く自由なソフトウェアの必要性が叫ばれていないようだ。
現時点では、ハードウェアに組み込まれているソフトウェアをすべて自由なソフトウェアにするのは困難だ。とりあえず、corebootがサポートされているマザーボードだけで、今は満足しておこうか。
さて、ソフトウェアである。OSのカーネルに自由なソフトウェアを使うのは当然である。これを実現するには、今の所、Linuxカーネルか、BSD系列のいくつかのカーネルに限られる。Linuxカーネルは、もちろん不自由なファームウェアを使わない設定でビルドされていなければならない。
もちろん、OSを一から構築するのは面倒なので、ディストリビューションに頼ることになる。FreeBSDなどなら統一されているが、GNU/Linuxには非常に多数のディストロがある。多くのディストロでは、不自由なソフトウェアを含めている。少なくとも、自由なソフトウェアと不自由なソフトウェアを明確に分離して、自由なソフトウェアのみをインストールできる仕組みを備えたディストロを使うべきである。
こう考えていくと、結局現時点では、ハードウェアにおいては、かなりの妥協が必要である。今まで、自由なソフトウェア環境構築の障害は、マザーボードやGPUにあるとばかり思っていた。しかし、注目されないハードウェアの方がもっと厄介だ。もちろん、これらのハードウェアのBIOSは、必ずしも書き換え可能なフラッシュメモリに格納されていないこともある。とはいえ、不自由なソフトウェアを許容する理由にはならない。
Oracle対Google、APIは著作権保護されるべきか
Oracle対Googleの訴訟で、まずOracleが一本とった。
もし、APIに著作権が認められるのならば、GoogleはOracleの著作権を侵害しているという判断である。
これにより、合衆国の司法は次に、APIには著作権が認められるのかという判断をしなければならない。
もし、APIに著作権保護が認められるのならば、合衆国ではまともにプログラミングができなくなるだろう。
ちなみに、日本ではとっくの昔に、プログラミング言語や規約や解法は著作権保護されないと法律に明確に書かれている。したがって、APIは著作権保護の対象ではない。EUでも最近、そういう判決が出た。
ただし、日本国ではソフトウェア特許が認められているので、現時点でも、まともなプログラミングはできない。
ともかく、APIとは何か。プログラミングに馴染みのないものには、よくわからない話だろうと思う。そこで、なるべく簡単に説明してみようと思う。
APIとは、Application Programming Interfaceの略である。プログラムのコードを書くには、あらかじめ定められたAPIに頼ることになる。たとえば、
class Hoge
{
public static void main(String[] args)
{
System.out.println("Hello World!") ;
}
}
というコードがある。このコードの意味は気にする必要がない。重要なのは、System.out.printlnだ。これはJavaの標準のAPIである。この場合、出力ストリームに文字列を出力する。
プログラマーが正しいコードを書くには、このSystem.out.printlnが、どのような挙動をするのかが、明確に定められている必要がある。APIに著作権が認められるというのは、その挙動に対して著作権が認められるという事である。
しかし、この挙動というものは、果たして著作権が認められるべきものなのだろうか。たとえば、将棋やチェスのコマの動きなどと同じく、単なるアイディアとか情報ではないのか。アイディアは著作権保護の対象にはならない。少なくとも日本では。
もちろん、APIの挙動を定義したドキュメントや実装は、著作権保護されるべきだ。将棋やチェスのコマの動きを解説したドキュメントが著作権保護されるのと同じことだ。しかし、挙動という単なるアイディアは、著作権保護されない。少なくとも日本では。
今回の裁判は、APIに著作権が認められるという前提のもとに判断すると、Googleは著作権侵害をしているという判断であり、別に驚くべきことではない。そもそも、その前提が間違っているのだから。しかし、アメリカ合衆国のことだから、ひょっとするとAPIに著作権性を認めるかもしれぬ。その時、アメリカでは純粋なアイディアが著作物になるのだ。
2012-05-07
高優先度自由ソフトウェアプロジェクト
High Priority Free Software Projects — Free Software Foundation — working together for free software
自由ソフトウェア財団では、「高優先度自由ソフトウェアプロジェクト」と題して、自由ソフトウェアの注目を集めるためのプロジェクトを発表している。多くは、すでに同等機能を持つ不自由なソフトウェアの存在がある。なぜ優先度が高いのかというと、自由なソフトウェアが不自由なソフトウェアと同等以上にすばらしいことを見せつけ、人々をもっと自由なソフトウェア側に転身させるためである。多くの不自由なソフトウェアは、対価を要求する。しかし、その金を自由なソフトウェアの開発に当てれば、同等以上の機能を持ち、しかも自由なソフトウェアが実現する。その点で、いくつかの自由ソフトウェアのプロジェクトは重要である。
どうも、最近変更があったらしいので（どこが変更されたのか不明だが）、そのリストを紹介しようと思う。
ただ、どうも、自由ソフトウェア財団のリストは、万人の同意するところではないように思われる。
自由なソフトウェアによるFlash Player
自由なソフトウェアによるFlash Playerの実装は重要である。自由ソフトウェア財団が直接支援しているプロジェクトとして、GNU Gnashがある。これは昔のバージョンのFlashには、ある程度対応している。YouTubeも、かなり機能は限定されるが、みることはできる。しかし、最近のFlashにはどうも、すぐに対応できる様子がない。まだ開発は続けられているが、どうも開発速度は早くない。
その他に、Lightsparkというソフトウェアがある。これは、最新のFlashに対応すべく開発されている自由なソフトウェアである。LLVMを使ったJITなど、なかなか技術的にも面白そうだ。ただし、まだ未実装機能が多く、非常に不安定で、実用には程遠い。
自由なBIOS
今、OSから上を完全に自由なソフトウェアで構成されたシステムにすることは可能である。しかし、その下はどうしようもない。とくに、BIOSが問題だ。BIOSはソフトウェアであるので、自由であるべきだが、残念ながら、ほぼすべてのマザーボードのBIOSは自由ではない。
corebootというプロジェクトでは、自由なBIOSを開発している。だいぶ動くものはできているそうだ。しかも、起動時間が競合の不自由なBIOSに比べて早いそうだ。
問題は、どんなに優れた自由なBIOSを開発したとしても、使われなければ意味がない。しかし、BIOSのインストールは、OSのインストールほど楽ではない。何しろ、失敗すればハードウェアが機能しなくなってしまう。そこで、自由なBIOSが成功するためには、ベンダーが自由なBIOSを使うようにならなければならない。
ただ、corebootの高速な起動時間は、GoogleがChromebookに搭載するBIOSとして考慮されているらしい。
自由なソフトウェアによるSkypeの代替品
Skypeとは、今更言うまでもなく、ボイスチャットのソフトウェアとして高いシェアを誇っている。Skypeのクライアントは不自由なソフトウェアである。通常、自分が不自由なソフトウェアを使っても、それは自分一人の責任である。他人に不自由なソフトウェアの実行を押し付けることはない。問題は、Skypeの使用は、自分だけではなく、他人にも不自由なソフトウェアの使用を強いてしまう。そのため、自由なソフトウェアのためにも、Skypeは使ってはならないのだ。そこで、自由なソフトウェアによる同等品が必要になる。
単に自由なソフトウェアでボイスチャットができる実用的なソフトウェアなら、いくつかある。しかし、残念ながら普及率の点でどれも本当に実用とはならない。普及率は重要である。しかし、使われなければ普及しない。なんとも困ったジレンマだ。
自由なソフトウェアによる動画編集ソフトウェア
動画編集は重要なソフトウェアである。自由なソフトウェアである動画編集ソフトは、結構たくさんあるが、どれも不自由なソフトウェアに対抗できるほど完成されてはいない。
自由なソフトウェアによるGoogle Earth
はて、Google Earthはそんなに優先度の高いソフトウェアだろうか。私は一度も使ったことがないので、その面白さがわからない。
GNU/Linuxディストリビューションが自由になるよう働きかけること
これは、難しい。というのも、自由ソフトウェア財団の定義する「自由」というのは、不自由なソフトウェアを一切含まないことだからである。しかも、単に不自由なソフトウェアを分離しているだけではダメで、公式からも一切提供しないことを要求している。DebianやUbuntuのようなディストロは、この基準に合格しない。なぜならば、自由なソフトウェアのみをインストールするオプションがあり、またレポジトリでも自由なソフトウェアと不自由なソフトウェアを明確に分けているが、公式で不自由なソフトウェアを提供するレポジトリも公開しているので不合格となる。
自由ソフトウェア財団の定義する「自由」は、What is free software? - GNU Project - Free Software Foundation (FSF)に書かれている。すなわち、
- 任意の目的でプログラムを実行する自由(freedom 0)
- プログラムがどのように機能するか検証し、望む動作をするように変更する自由(freedom 1)。ソースコードへのアクセスはこの自由を保証する前提条件である。
- 複製物を再配布して隣人を助ける自由(freedom 2)
- 他人に改変版の複製物を再配布する自由(freedom 3)。これにより、コミュニティは変更の恩恵を受ける。ソースコードへのアクセスはこの自由を保証する前提条件である。
多くの、一見許諾的に見えるライセンスが、この自由には合致していない。たとえば、改変版を再配布してもいいが、名前を変更することなどという条件のソフトウェアもある。そのようなソフトウェアは、自由ソフトウェア財団の定義する「自由」ではない
自由なソフトウェアによるMatlabの代替品
Matlabは数値計算のソフトウェアとして人気の高い不自由なソフトウェアである。自由ソフトウェア財団が直接支援するプロジェクトに、GNU Octaveがある。これは、ある程度は成功しているようだ。
OpenDWGライブラリの代替品
OpenDWGとは、CADファイルのフォーマット規格及び不自由なソフトウェアライブラリの実装である。自由なソフトウェアによる実装として、LibreDWGがある。
GDBによる逆転デバッグ
逆転デバッグとはデバッガーによる、すでに行われた実行の取り消しである。まあ、面白い機能ではあるし、ある種のデバッグ作業の助けにはなるだろう。しかし、この機能が人々の注目を自由なソフトウェアに集めることになるだろうか。その辺は疑問だ。ただし、今TASと称するプレイ動画が人気であることを考えると、実行をなかったことにするこの機能は、結構人気が高いのかもしれない。
ちなみに、Windows用の32bitプログラムでTASを実現するデバッガーとして、hourglassというものがある。これには逆転実行はないものの、スナップショット機能がある。
自由なソフトウェアによるネットワークルーターのドライバー
まあ、ネットワークルーターに限らず、自由なソフトウェアによるネットワーク周り、特に無線LANのドライバーは、常に欠けている。
自由なソフトウェアによるOracle Formの代替品
DB関連には疎いのでよくわからない。
自動的な字幕書き起こし
いわゆる音声認識のことである。音声を認識して、自動的に字幕を生成する機能だ。「YouTubeはこれを実装している。しかし、出来ればこの機能は、自分のコンピューター上で、自由なソフトウェアを使って行いたいものである」とのことだが、はたしてこれが人々を自由なソフトウェアに惹きつけるようになるのだろうか。
PowerVRドライバー
PowerVRというのは、組み込みの分野では有名なGPUである。このGPUの自由なドライバーが存在しない。問題は、PowerVRは非常に有名でよく使われているハードウェアなので、強欲な契約が行われているのだ。評価用のハードウェアやSDKやドキュメントを入手するには、NDAを結ばなければならない。そのため、PowerVRのドライバーを開発できる知識を持つ人間は、契約により自由なドライバーを開発できないし、ドライバーを開発したい人間は、必要な知識を得られない。
PowerVRに限らず、GPU周りは、自由なドライバーが欠けている分野である。
爆笑ものの英語
腹が痛い。インデペンデンス・デイの発音練習を思い出した。
しかし、中国人の作る宣伝は、どうも優れた製品の宣伝ではなく、よく訓練された人間の宣伝のように見えるのはなぜだろうか。あの有名なシャベルの動画もそうだ。
なぜLispやMLは分裂するのか
stackexchange.comで、面白い話題が議論されていた。LispやMLというのは、いわば、Lisp風言語、ML風言語の総称である。実際には、Common LispやらSchemeやらArcやらと、多数の互換性のない言語が存在している。一方、RubyやPythonには、特に大きな分裂は起きていない。CPythonに対してPyPyのような、異なる実装は出ているが、言語は分裂していない。なぜなのか。一体、RubyやPythonは、分裂を防ぐために何をしているのか。
色々と議論されているが、まず一番わかり易い説は、高徳な独裁者（Benevolent Dictator）の存在である。Rubyにはまつもとゆきひろが、PythonにはGuido van Rossumが、高徳な独裁者として存在する。
また、規格の存在をあげる者もいる。CやFortranだって、規格ができるまでは、互換性のない実装が氾濫していた。
また、単純に古い言語だからという理由を挙げるものもいた。
また、分裂していないという見方は間違っているという意見もある。実際、Python 2とPython 3は分裂している。これは、Python 3が互換性を壊す変更を導入したためである。
Lispは素晴らしく強力なので分裂するのは必然だ、そもそも、今の言語はすべてLispのパクリだ、などというLisp信者らしき書き込みもある。
2012-05-05
Elder Scrolls Onlineのトレイラーがでたが・・・
なんだかものすごく地雷臭がするのは気のせいだろうか。
画像も一枚、公開だかリークだかしているが、どこかチープな印象を受ける。まるで、グラフィックを変えたWoWのような雰囲気だ。
自由なソフトウェアによるFlash
ついに、今使っているPCからAdobeの不自由なFlash Playerを取り除く決意をした。不自由なソフトウェアの使用は最小限に留めたい。実際、Flashにはほとんど頼っていなかったとはいえ、Flashなしというのもつらい。なぜならば、YouTubeでは、広告付きの動画は、いまだにFlashを必要とするからだ。それに、往年の名作Flash動画が見られなくなるのも辛い。
そこで、Flashの自由な実装を試してみることにした。GnashとLightsparkである。
Gnashはある程度完成されて、安定した実装だ。最新のFlashには追いついていないが、Flashアニメが全盛だった昔のFlashならば、問題なく再生できる。また、YouTubeも再生できる。ニコニコ動画の外部プレイヤーは見られないようだが、もとよりニコニコ動画のアカウントは、SPAMメールまがいの通知メールを送りつけはじめ、しかも無効にする設定が面倒だった時に消したので、もはやどうでもいいことだ。
Ubuntuでインストールするには、以下のコマンドを使えば良い。
apt-get install gnash
ブラウザープラグインをインストールするには、以下のコマンドを使う。
apt-get install browser-plugin-gnash
さて、Flashの自由な実装にはもうひとつ、Lightsparkというものがある。これは、最近にわかに注目を集めている実装で、最近のFlash規格を実装している。ただし、現時点では、まだ未完成かつ不安定で、実用にはならない。
apt-get install lightspark browser-plugin-lightspark
一応試してみたが、まずYouTubeでは、UIが表示される、さらに再生しようとすると途中でクラッシュする。ニコニコ動画の外部プレイヤーでは、未実装エラーがでる。昔のFlashは、Gnashにフォールバックするので、結局はGnashだ。Lightsparkはまだ実用の域には達していない。
ともかく、これで不自由なソフトウェアといえば、nVidiaのバイナリブロブしかなくなったはずだ。特許に抵触している恐れのあるソフトウェアはあるものの、そもそも、あらゆるソフトウェアは潜在的に特許に抵触している恐れがあるのだ。ヘルプアイコンですら特許申請を通ったのだから、何だって通る。
2012-05-04
ADLはKoenigの発明ではなかった
A Personal Note About Argument-Dependent Lookup | Dr Dobb's
先週の記事のコメントで、C++のArgument Dependent Lookupはよく、"Koenig lookup"と呼ばれていると書いてあった。実際、現時点（2012年5月1日）でのWikipediaでも、私が発明したと書いてある。私は発明していない。残念ながら、誰が発明したのか私は知らない。だから、誰が名誉を受けるべきなのか、あるいは非難されるべきなのかもわからない。私の名前がArgument Dependent lookupに関連付けられているのは、私が発明したわけではないものの、私は当時、名前空間の導入が、ADLか何かの機能を必要とする問題を持ち込むだろうと認識していたからだ。
[中略：ADLが必要な問題例についての解説]
だが、記事の冒頭でいったように、この問題を解決したのは私ではない。他の誰かだ。誰だったのかは覚えていない。おそらく、Usenetのcomp.lang.c++ニュースグループでの議論の中だったと思う。私が考えたのは、この問題例である。これにより、名前空間の導入は問題を起こす、これはC++標準規格が制定されるまでに、何らかの方法で解決しなければならないと、標準委員会を説得できた。当時、時間がおしていて、ある解決方法があった。そして誰も、より良い解決方法を思いつかなかったのだ。
後の話は、よく言われるように、昔の話さ。
なんと、D&EにすらKoenig lookupと書かれているのにも関わらず、Koenigの発明ではなかったのか。
The Elder ScrollsがMMOになるそうだ
June Cover Revealed: The Elder Scrolls Online - Features - www.GameInformer.com
The Elder ScrollsのMMOがでるそうだ。しかも、来年だという。さらに、実に初代Areanから久しかった、Tamriel全土が出るという。私の個人的に期待している、Kahjiitの故郷であるElsweyrもでるとは嬉しい。
舞台はTES5: Skyrimの千年前、Molag BalがTamriel全土を支配しようとしている。
Malag Balというと、いまいち印象の薄いDaedric Princeだ。いままで、あまり物語には関わってこなかった。アーティファクトのメイスを手に入れる短いクエストぐらいしかない。一応、最初のバンパイアの親とされているのだが。
どうやら、Mac版のクライアントはでるそうだが・・・、はたしてGNU/Linuxでは動くのか。Wineに期待しよう。そもそも、どういう課金方式になるのか。
2012-05-03
EA、新作ゲームを売るために旧作を動作不可能にすること
Original iOS 'Rock Band' Shutting Down at the End of May | Touch Arcade
EAは新作のゲームを買わせるために、金を払って買った旧作を動作不可能にするそうだ。
これが、不自由なソフトウェアに起こる悲劇である。これがために、我々は不自由なソフトウェアを使ってはならないのだ。不満であれば、今すぐ自由なソフトウェアに切り替えるべきである。不自由なソフトウェアを使うのならば、このようなことも、甘んじて受け入れなければならない。何故ならば、ユーザーはソフトウェアの自由を有していないからだ。当然の結果である。当然予期すべき事態である。
もちろん、技術的にはゲームの動作に必要なサーバーの稼働を停止するということである。しかし、もしサーバーのプロトコルなどが自由なライセンスのもとに公開されて、ゲームのソフトウェアも自由であれば、互換性のあるサーバーを立ち上げることができる。不自由なソフトウェアとプロトコルとフォーマットでは、その自由がない。
このようなニュースは、ますます一般大衆に自由なソフトウェアの価値を認識させる好ましいニュースである。
2012-05-02
どのプログラミング言語を学ぶべきか
新手该学哪门编程语言 | 酷壳 - CoolShell.cn
via :Which programming language should I learn first? | Pixelstech.net
最近、フォーラムでこんな質問を目にした。質問とは、「どのプログラミング言語を学ぶべきか」というものであった。ある人の答え。
それは目的によるな。
- 表現力が高いパワフルな言語でプログラミングしたい場合： Python
- 手っ取り早くWebサイトを立ち上げたい場合： PHP
- 「ロックスター」を自称するプログラマーと触れ合いたい場合： Ruby
- 本当にプログラミングを学びたい場合： C
- 悟りを得たい場合： Scheme
- 抑圧感を得たい場合： SQL
- 遺伝的に淘汰されたい場合： Microsoft Visual Basic
- ひどく平凡でつまらないが安定して給与が支払われるファイナンシャル・アプリケーションを代わり映えしないオフィスで開発したい場合： Java
- 資格と肩書きが欲しい場合： C#
- 大人になって失ってしまった幼い頃の情熱を取り戻したい場合： Objective C
- 毎日、ファックと叫びたい場合： JavaScript
- 何でもできる神になりたい場合： アセンブリ
自分のバージョンを付け加えておこうと思う。
- コンパイル時メタプログラミングをしたい場合: C++
- コンパイル時メタプログラミングを本当にしたい場合： D
- メタプログラムをまともに書きたい場合： Common Lisp
- 毎日、ファックと叫びたくない場合： Dart
なぜValveはGNU/Linux対応を急いでいるのか
Valveが目下、GNU/Linux用にSteamクライアントを開発し、Sourceエンジンを移植しているという噂は、Phoronixの中の人がvalveを訪れてより確定し、広く公の知るところとなった。
Phoronixの中の人の話によれば、Valveの創始者であるGabe Newellは、GNU/Linuxを賞賛し、逆にWindowsには未来がないと表明したというのだ。特に、Windows 8はひどいのだそうだ。
もちろん、これから開拓する市場であるGNU/Linuxユーザー向けのリップサービスかもしれないが、元Microsoft社員で、しかも一番最初のWindowsから13年もの間、MicrosoftでWindowsの開発に携わり、その稼いだ金を元手にValveを立ち上げた経歴を持つGabe Newellとしては、お世辞にしても極端な転身ぶりだ。
しかも、ValveのSteamは、昔も今も、Windowsが最大の市場である。この事実は、もうしばらく変わらないだろう。なぜWindowsには未来がないのか。
GNU/Linuxは疑いようなく優れているが、ゲーム用途としては、まだWindowsには及ばない。理由はいろいろある。ゲームのプラットフォームとして、GNU/Linux環境向けには、あまり真剣にゲームが開発されてこなかった。開発環境がGNU/Linuxということはありえるが、エンドユーザーによるゲームの実行がGNU/Linuxで行われるというのは、まだ小規模だ。そのため、ゲーム開発の経験が少ないし、開発フレームワークも、Windowsに比べて劣っている。
DirectXは、かなりゲームを意識して設計されている。単にDirectXと書いた場合、グラフィックの描画はもちろんのこと、音声や動画のデコードと再生、文字列描画、その他の補助的なライブラリまで、幅が広い。OpenGLは、むしろ汎用的で移植性の高い3D描画用途として設計されている。そのため、DirectXほど末端の高級な機能まで用意されていない。これは、OpenGLを支援している企業や団体が、OpenGLにはそのような設計を望んでいるからである。
幅広い環境も問題だ。Windows環境でさえ、ハードウェアの差異を意識しなければならない。GNU/Linuxでは、ソフトウェアの違いも意識しなければならないのだ。
もちろん、GNU/Linuxが真剣にゲームプラットフォームとして使われだしたならば、フレームワークなどが多く開発され、環境の差異もフレームワーク下で吸収されるだろう。しかし、この業界においては、「今できる」ことが重要であり、「来年できる」というのは、「できない」のと同じである。
ではなぜ、ValveはGNU/Linux対応を急いでいるのか。先日、この記事を読んで気がついた。プラットフォームとしてのSteamの存在が脅かされているからだ。
たとえばスマートフォンだ。iPhoneやAndroidといった環境では、統一されたソフトウェア配布の公式プラットフォームが存在する。このプラットフォームは、そもそもの元締めであるAppleやGoogleによって提供されている。これらのスマートフォンで、統一されたプラットフォーム外のソフトウェアを実行しようと思うと、かなり手間がかかる。技術的な手段を持って制限されている場合もある。これは、不自由なソフトウェアを使う者は当然予期しているべきなので、当然の報いである。
さて、ここで不穏な動きがある。AppleのPCハードウェア用のOSであるMac OS Xにも、そのような統一されたソフトウェア配布の公式プラットフォームが提供されている。どうも最近の動きとして、最新のMac OS Xは公式プラットフォームから提供される、コード署名されたソフトウェア以外は、デフォルトで実行しないように設定されているとのことだ。もちろん、この設定は変更できるが、はたして将来どうなるだろうか。今はGUIから設定できるかもしれない。しかし将来、端末からコマンドを入力しなければ解除できないようになるかもしれない。更に進めば、設定ファイルを手動で変更しなければならなくなるかもしれない。最終的には、OSのソフトウェアに非公式のパッチを当てて解除しなければならなくなることも予想される。そうなったとき、Appleの公式ソフトウェア配布プラットフォームであるApp storeは、Mac OS X唯一のソフトウェア供給プラットフォームとなるのだ。そこにSteamが入り込む余地はない。
実は、Windowsもこの動きに追随する様子がある。Microsoftも公式のソフトウェア配布用プラットフォームを開発中だ。
つまり、今現在のところ、WindowsはSteam最大の市場であるが、Windowsを開発するMicrosoftは、Valveの競合相手となるのだ。MicrosoftがValveのSteamを参入しにくくする機能、すなわち公式プラットフォームから入手したコード署名されたソフトウェア以外は、デフォルトで実行しない機能を実装しないとは、どうしていえようか。これは、不自由なソフトウェアを使う者ならば、当然予期しているべきなので、当然の報いである。
もちろん、コード署名は邪悪ではない。コード署名は当然使うべき技術である。コード署名によって、我々は入手したソフトウェアが、発行元から我々に届けられるまでの間、悪意ある第三者によって改変されていないかどうかを確かめることができる。むしろ、ソフトウェア配布のプラットフォームはコード署名を積極的に使うべきである。
しかし問題は、ある環境が、ひとつのプラットフォームからのコード署名しか許可しないとなれば、別のプラットフォームが参入することはできない。解除する設定方法を提供したとしても、やはり参入の生涯になる。デフォルトの設定は強い。エンドユーザーにデフォルト設定の手動での変更を強いるようなソフトウェアが普及することは難しい。
もちろん、デフォルトの設定をそのようにするのは、邪悪ではない。たとえば、Windowsは通常のソフトウェアを、管理者権限では実行しない。これは当然の機能である。もし、あるソフトウェアが、理由もなしに管理者権限を要求するならば、怪しまねばならない。ソフトウェアのインストール、アンインストール、Windowsの設定を変更するような設定項目（たとえばファイルの関連付け、自動起動の設定、右クリックのコンテキストメニューへの追加など）を除いて、、およそ普通のソフトウェアは、管理者権限で実行する必要はない。このようなデフォルトの設定は、邪悪ではない。
しかし、MicrosoftがAppleに追随している現状は憂うべきである。このままでは、プラットフォームとしてのSteamを提供するのが難しくなる。第一、OSの開発元が公式にソフトウェア配布のプラットフォームを提供しているのであれば、わざわざサードパーティのプラットフォームを使う必要は薄れるだろう。
ここに、自由なソフトウェアの価値が出てくる。不自由なソフトウェアは信頼できないのだ。Steamがどこまで自由なソフトウェアを尊重するのか。どうせ囲い込みをするのではないかなど、懸念事項はたくさんある。しかし、SteamのGNU/Linuxへの参入は歓迎すべきだ。なぜならば、GNU/Linuxは自由なソフトウェアだからだ。Steamが気にいらないあれば使わなければいい。もし、使用中のディストロがSteamから金をもらってSteamクライアントを組み込んできたとして、それが気にいらないのであれば、Steamを取り除いたforkを新たに立ち上げればよい。
都合がいいことに、今PCでゲームをする顧客層というのは、比較的GNU/Linuxに移行しやすい層なのだ。初歩的な話だが、OSを自分でインストールするとか、グラフィックカードを交換するなどの作業は、PCゲーマーならば必須のスキルである。だから、GNU/Linuxへの移行もそれほど難しくはない。そうでないヘタレは、とっくの昔にコンソールに移っている。
2012-05-01
射幸心と価値
世はソーシャルゲームが盛りである。今や、どこもかしこもソーシャル化している。実際、ソーシャルゲームの売上はすばらしいし、何よりも利益率の高さは目を見張るものがある。私自身は、不自由なソフトウェアを所有したいとは思わないし、所有という概念のない課金アイテムを使う権利を得たいとも思わない。しかし、現にソーシャルゲームが流行していることは認めざるを得ない。使えば壊れる1500円の物理的に存在しない釣竿が飛ぶように売れる時代に、もはや六千円程度でやりこみ要素のある、よく作りこまれたゲームを出すなどバカバカしい。
しかしなぜなのか。なぜ人はソーシャルゲームに金を落とすのか。
ここでは、ソーシャルゲームの射幸心を煽る作りの善悪とか違法性などの是非については考えない。そもそも、結論めいたことも書かない。ただ、現状の不思議な状態を記録としてとどめておきたい。
およそ、射幸心を煽る仕組みは、ビデオゲーム以前から存在した。例えばガチャガチャやUFOキャッチャーだ。あの手のゲームは、かなり射幸心を煽るゲームである。しかし、ソーシャルゲームと違うのは、遊んだ結果として、物理的な物を所有できるという点にある。ガチャガチャは、金を入れてハンドルを回した結果、たいてい何かが出る。UFOキャッチャーも、技量や運に応じて、何かしらの物理的な景品をゲットできる。少なくとも、結果は物理的な品物として残り、所有できるのだ。
もちろん、もっと直接的な賭博もある。公営ギャンブルとして貧乏人の負け犬から金をかき集めるか、警察に袖の下を通して認めてもらうか、あるいは地下に潜るか、その方法は違えど、賭博が違法とされている我が日本国でも、賭博は行われている。賭博では、非常に期待値が低いものの、入力した以上の金銭あるいは金銭的価値があるものが出力される可能性がある。賢い人間は、入力より期待値が低い行動は行わないものだ。しかし、賭博では、ありえないほど低いものの、入力よりはるかに高い出力を得られる可能性が設定されている。このため、正しく期待値の計算ができない非論理的な人間は賭博にハマる。
しかし、ソーシャルゲームは、この点が根本的に異なる。ソーシャルゲームの課金アイテムは、物理的な物ではないし、そもそも、所有しているわけですらない。課金アイテムは、画像やソフトウェアではないのだ。一体、課金アイテムとは何か。それは、ソーシャルゲームの公式サーバー内で記録されている、ユーザーアカウントの情報を書き換える権利である。ユーザーは何も所有していないのである。
現代のほぼすべての不自由な電子書籍の販売形態は、ライセンスである。契約によれば、我々は不自由な電子書籍を所有していないのである。単に、使用する権利を購入しているだけなのだ。このため、我々は不自由な電子書籍や、そもそも不自由な紙書籍を買うべきではないのだが、それはまた別の話だ。ここでは是非を論じない。
しかしソーシャルゲームの課金アイテムは、名実ともに、何も所有しない。ガチャガチャやUFOキャッチャーのように景品が手に入ることもないし、画像やソフトウェアを購入しているわけでもない。単に、サーバー上の情報を書き換えて、課金アイテムをゲーム内で有効にする権利を購入しているのだ。権利を所有しているといえば、その通りなのかもしれないが、やはりものすごく弱い所有である。
ソーシャルゲームは、直接に金銭的価値に結びつかない。たしかに、RMTと称して、課金アイテムを売買する市場はある。しかし、その市場は非常に不安定であり、何の保証もない。もし、課金アイテムの実体が、サーバー上の情報を書き換える権利であるとすれば、課金アイテムの本質は権利であるので、所有者が売買できてしかるべきだ。しかし、権利の売買が成立するには、権利に価値を見出す人間がいなければならない。ソーシャルゲームを賭博だというのは、いささか論理の飛躍のように思われる。第一、全員が賭博目的でソーシャルゲームをしているのならば、まともな売買市場が成立するわけがない。RMT参加者全員が博徒であれば、短期的な転売を繰り返した挙句、一瞬でインフレして終わるだろう。
もちろん、一見価値のないように思えることに、資源をつぎ込むのは、今に始まった話ではない。RPGが好きな人間なら誰でも、何らかのレベル上げ作業を経験しているだろう。レベル上げは、技術的には、単にコンピューターのメモリの値を変化させているだけである。それ自体には何の価値もない。時間という資源を浪費しているだけだ。また、ワンショット何万円もする酒に、喜んで金を払う人間もいる。正常な判断力のもとに自由意志で購入するならば、個人の勝手だ。しかし、今の時代、フレーバーというのはとても簡単に作り出せる。単にアルコールの陶酔作用を求めるだけならば、もっと安上がりな方法がいくらでもある。これも、金銭という資源を浪費している。
もちろん、我々はレベル上げ作業で貴重な時間を浪費すべきではないし、たかが数十ミリリットルのアルコール水溶液に多額の金銭を払うべきでもない。しかし、価値をみいだす人間が現に存在する。
つまり、ソーシャルゲームの課金アイテムには、本来、価値などないはずだ。課金アイテムは所有できないし、金銭的価値もない。しかし、現に課金アイテムは社会問題になるほど購入されているし、RMTによって間接的な金銭的価値が創出されているのも、結局、課金アイテムに価値を認める人間が多数存在するからである。
課金アイテムをサービスと見たならば、価値が存在することも、納得できないことはない。自由ソフトウェアにも、価値はソフトウェアの配布や改変を制限することではなく、付随するサービスによって創出されるという思想がある。
無形のサービスに価値を見出す時代になるのだろうか。
Subscribe to:
Posts (Atom)