2012-05-31

全プログラマーが知るべきレイテンシー数

Latency numbers every programmer should know — Gist

L1キャッシュ参照 0.5ナノ秒
分岐予測失敗 5ナノ秒
L2キャッシュ参照 7ナノ秒
Mutexのロックとアンロック 25ナノ秒
メインメモリー参照 100ナノ秒
Zippy[Snappy]による1KBの圧縮 3,000ナノ秒
1Gbpsネットワーク越しに2KBを送信 20,000ナノ秒
メモリーから連続した1MBの領域の読み出し 250,000ナノ秒
同一データセンター内におけるラウンドトリップ 500,000ナノ秒
ディスクシーク 10,000,000ナノ秒
ディスクから連続した1MBの領域の読み出し 20,000,000ナノ秒
パケットを、カリフォルニア→オランダ→カリフォルニアと送る 150,000,000ナノ秒

Jeff Dean著(http://research.google.com/people/jeff/)
元ネタはPeter Norvig (http://norvig.com/21-days.html#answers)
素晴らしく実感できる比較版: https://gist.github.com/2843375

いくつかのレイテンシーは、時間ではなくサイクル数で数えるべきなのだろうが、まあ、簡単な比較のためには、時間でもいいのだろう。

ディスクシークが今も昔も10ミリ秒かかるのは何ともならん。SSDなどのフラッシュメモリベースの記憶装置の大容量化が待たれる。

追記:すこし参考文献が追加されていたので追記。

だいぶ反響があるようだが、メインメモリーへの読み書きは今も昔も遅い。だからこそレジスターがあり、キャッシュがありと、メモリーの遅さを何とか隠そうとする方法が発達した。

2012-05-30

おお、見よ、Fedora 17 Beefy Miracle、ついに我らがもとに至る

Announcing Fedora 17. Relish it.

我らが希望、Fedora 十七 牛肉の奇跡(Beefy Miracle)、まさに発行されたり。これ、開発者MLによる予言を証するためなり。すなわち、

幾千ものホットドック料理人の熱気に促され、Fedoraの第十七の発行が、世界各地の貢献者らによりて、まさに焼きあげられんとす。これ、牛肉の奇跡なり。その進捗はマスタードに教わる。

六ヶ月に渡り、Fedora計画の参加者はディストリビューションの発行に自由に貢献し、その精神に四あり、すなわち、自由、友、機能、原始なりき。しかもその味わい楽し。こは楽しからざるコミュニティは、太陽なき日と同じなればなり。

発行におけるや、この自由にしてオープンソースなるオペレーティングシステムは皆に等しく、多様なる味わいをもって供されんとす。すなわち、かのエンドユーザーや、システム管理者や、開発者や、皆その意を同じくす。否、これ単に我らが皆ホットドッグを愛するのみがためにあらず、ことも愚かや、我ら皆これを知る。すなわち、Fedoraは牛肉と野菜のために作られ用いられることを。自由とは、我が友よ、自由とは偉大なる味わいなり。そは牛肉の奇跡の利用者に等しく、創造と共有と行をもたらせり。

ザワークラウトの書、第十二章、五百二十九節

牛肉の奇跡が降臨なされたり。見よ、そは下なるところにてダウンロードできよう:
http://fedoraproject.org/get-fedora

さらに見よ、この発行における深淵なる智識は下なる発行書に書かれたり:
http://docs.fedoraproject.org/en-US/Fedora/17/html/Release_Notes/

2012-05-28

LLVMpipeはまだ前途多難

[Phoronix] LLVMpipe Still Doesn't Work For Linux Gaming

UbuntuがUnity2Dを捨てる決定をしたことは記憶に新しい。代わりに、UbuntuはOpenGLのソフトウェア実装である。Gallium3DとLLVMpipeを使い、通常のUnityを、OpenGLに対応できないコンピューター上でも実行する。

とまあ、理論上は素晴らしい話だが、残念ながら、どうあがこうとも、CPUとGPUは目的が違うので、OpenGLをソフトウェア実装するのは、パフォーマンス上の問題がある。

そもそも、最新のIvy Bridgeで、ようやくUnityやGnome shellあたりなら、なんとか実行できるという状況だ。OpenGLに対応できるGPUがない環境では、CPUもそれほど速くないだろうし、はたして実用になるのだろうか。

2012-05-27

xkcd: ネットワーク

xkcd: Network

「どうだ、かわいいだろ」
「なにこれ?」

「仮想Windows機同士でネットワーク構成して、インターネットからの入力を流し込んでいるのさ。自動的にメールの添付を実行したり、ファイルの共有をしたりしてる、しかも、セキュリティパッチは一切あててない」
「このネットワーク間においては、あらゆるウイルスがはびこっているんだ」

「メールトロイだろ、ワームだろ、変態的な変異型ウイルスだってあるぞ。監視システムが仮想機の追加と削除をランダムに行っている。画面にはネットワーク上のウイルスの動きが表示されているんだ。ネットワーク内で増殖しようと必死にもがいているんだよ」

「ねぇ、普通の人は、アクアリウムとかやるんじゃないの」
「おはようBLASTER君、W32.WELCHIAとは仲がいいみたいだね。みんないいウイルスだね。いい子、いい子」

ML名古屋の感想

昨日、ML名古屋 - [PARTAKE]で発表してきた。

勉強会というの初めてだったので、感想を述べておくと、この手の勉強会というのは良し悪しだ。良しというのは、広範な分野の人間と出会えるという事だ。プログラミングというのは非常に分野専門的な仕事であるので、どんなにその分野の天才でも、一歩離れると素人になってしまう。自分の職場などでは、幅広い専門家に出会うのは難しい。悪しというのは、勉強会といっておきながら、とくになにか実用になるわけでもないという事だ。たしかに、短い時間で発表するためにまとめるのは、ある程度の勉強になるかもしれないが、自分の専門分野と聴衆の専門分野が一致しない。そのため、発表内容も、簡単なものにならざるを得ない。

私の発表は、MとLをタイトルに入れるという条件と、10分間という発表時間を考慮して、Missing Language Features in C++というタイトルで、C++11の規格に入っているものの、おそらく使われることのない機能について話すことにした。後に発表時間が20分に伸ばされたので、だいぶ発表が楽になった。とはいえ、20分もやはり短いし、ましてや聴衆のC++の知識には差があるはずで、C++を知らない者もいるだろうから、何かC++自体で面白いことは書けない。私は、スライド資料をW3CのSlidy2で書いたので、単にブログにコピペして公開することにした。本の虫: ML名古屋での発表の際に使ったスライド。ちなみに、当日に資料のコピーを受け取った人は、資料のVariadic TemplatesでInheriting Constructorsをエミュレートするコードは間違っていたので、注意して欲しい。また、当日の資料は、Aキーを押せばスライドではなく、通常のスクロールするドキュメントとして閲覧できる。

他人の発表で、特に興味深かったものを挙げる。

@sunflatさんのMSX Laungage。これは、スライドのプロジェクターへの出力に1チップMSXを使い、MSX Basicでスライドを記述するという斬新な方法で発表された。残念ながら、あの感動を再現することは難しいが、出力を画像にしたものが、MSX Languageで公開されている。ただし、MSX Basicで記述するのは非常に苦痛なので、実際のスライド作成はScalaで行い、DSLを実装してMSX Basicに落としこむという手法が取られた。詳しくは、MSXでプレゼン - サンフラットの開発日記を参照。

ちなみに、この1チップMSXは極少数しか生産されなかった、非常に貴重なハードウェアである。あるとき、freenodeの外人に、1チップMSXがどうしても欲しいのだが、どこで買えばいいのか教えてくれと訊ねられたことがあった。「君、諦めたまえ。残念ながら、それは同人によって限定生産された高価なおもちゃなのだよ」と答えておいた。外人はひどく失望していた。

@aster_ismさんのcMos Layout。これは、CPUの設計から製造までを非常に簡潔にまとめていて興味深かった。ただし、私は先天的に電子回路を理解する部分の脳の一部を持たずに生まれているためか、電子回路というのは、うまく頭に入ってこない。ともかく、CPU設計と製造の大まかな流れが開設されていた。今でも、CPUのC言語風の上級言語を、VHDLやVerilogのような言語に、まともに変換するツールは存在しないらしい。だから、変換は未だに手動で行われるそうだ。それでも最初に高級な言語で書くのは、検証を用意にするためなのだとか。残念ながら、当日に使ったスライド資料は公開されていないようだ。「45ナノでCPUを設計して製造してもらうにはおいくら万円かかりますか」という質問に対しては、「45ナノ高いんですよね。まあ、一億ほどあれば十分かと」という答えであった。

@deco_lequeさんのeMacs と vi で Lisp コード編集。これは、Lisperが普段どのようにコードを書いているのかというのを実演する内容であった。小指が腱鞘炎を起こすのではないかと心配するほど頻繁に、Emacsのショートカットキーを使っていた。曰く、「Lispにとって括弧は空気」と。

プレゼン自体は専門外で全く理解出来なかったのだが、LINQ(マイクロソフトの開発したクエリー用言語機能)の発表をするのに、MacBook(アップルの販売しているOSおよびノートPC)でスライドを出力するという不思議な人間がいたことを記しておこうと思う。どちらも不自由で囲い込みをするプラットフォームを提供している会社だが、どちらがより強く囲い込んでいるかということを如実に示す例だろう。

他の発表では、いかにWindowsやMacが不自由かつ不便なプログラミング環境であるかを嘆き、その状況を少しでも緩和しようと、自由なソフトウェアを移植するような発表があった。そこまで自由の価値を認識していながら、なぜ不自由なOSを使い続けるのか、私には理解できない。まるで、奴隷が自身を縛り付ける鎖を綺麗に塗装して喜んでいるようなものだ。いかに綺麗に塗ろうと、鎖は鎖だ。私は、不自由なソフトウェア環境の話には全く興味がない。

総合的な感想としては、MSX Languageの発表のために、この勉強会に参加する価値があった。

ML名古屋での発表の際に使ったスライド

Missing Language Features in C++11

C++11の黒歴史

C++11で規格入りしているが、おそらく使われることがない機能。

  • 継承コンストラクター
  • 属性

問題

既存のクラスから派生して、ごく簡単な機能を付け加えたい。

// 有名ライブラリの優れたクラス
class SuperUltraDeluxeClass
{
// 高度な実装
} ;

// 自分の書いたラッパー
class MyClass
    : public SuperUltraDeluxeClass
{
// ちょっと便利な機能の付け足し
} ;

自分のクラスは、基本クラスと同じように振舞ってほしい。

継承されないコンストラクター

しかし、コンストラクターは通常、継承されない。

class Base
{
public :
    Base() ;
    Base( int ) ;
    Base( double ) ;
} ;
class Derived : public Base 
{ } ;

Derived d( 0 ) ; // エラー

このままでは、基本クラスと同じように初期化できない。

コンストラクターの手動継承

コンストラクターは自分で書くしかない。

class Derived : public Base
{
public :
    Derived() ;
    Derived( int i ) : Base( i ) ;
    Derived( double d ) : Base( d ) ;
} ;

面倒だ!

継承コンストラクター

C++11では、この問題を解決すべく、継承コンストラクターが導入された。

class Derived
    : public Base
{
public :
    using Base::Base ; // コンストラクターを継承
} ;

Derived d( 0 ) ; // OK

簡単だ!

継承コンストラクターの詳細

継承コンストラクターは、using宣言でコンストラクターを指定することにより発動する。

struct B
{
// コンストラクターの宣言
} ;
struct D : B 
{
    // コンストラクターの継承
    using B::B ;
} ;

とてもわかりやすい機能であり、初心者でも簡単に使える。

  • 教えるのは簡単
  • 書くのも簡単
  • 使うのも簡単

以上、めでたしめでたし。

ならず。

継承コンストラクターの問題点

有名なコンパイラーはどこも実装していない。

C++11規格制定の最終段階で、実装経験のない機能を取り除こうという提案が出された。

すると各地から実装例の報告がなされ、結局、ほとんどの機能は、すでに実装されていることが明らかになった。

継承コンストラクターの実装例もあったので、除去は免れた。

なぜ誰も実装しないのか

継承コンストラクターが実装されない理由

  • Variadic Templatesでエミュレートできる
  • 実装が意外と面倒

Variadic Templatesによるエミュレート

N3258: US-65: Removing Inheriting Constructorsを参照。

template < typename BaseType >
class Derived 
    : public BaseType
{
public :
    template < typename ... Types >
    Derived( Types && ... args )
        : BaseType( std::forward<Types>(args)... )
        // 追加のメンバー初期化
    {
        // 追加の初期化処理
    }
} ;

しかも、追加でメンバー初期化や初期化処理が実行できる。

さて、読者はstd::forwardの意味がわかるだろうか?

エミュレートの問題点

  • 一般人がVariadic Templatesを使うのは難しい
    • しかも、Perfect Forwardingの知識まで要求される
  • Variadic Templatesは何にでもインスタンス化してしまう
    • インスタンス化を防ぐ方法はある。しかし・・・
  • Variadic Templatesのエラーメッセージは読みにくい。
    • エラーメッセージを読みやすくする方法はある。しかし・・・

エミュレーション問題の解決?

自動的なインスタンス化を防ぐ方法

template < typename ... Types ,
    typename Dummy = typename std::enable_if<
        std::is_constructible< BaseType, Types...>::value
    >::type 
>
Derived( Types ... args )
    : BaseType( std::forward<Types>(args)... )
{ }

読者はこのコードの意味がすぐに理解できるだろうか。ちなみに、我々C++プログラマーの世界では常識である。

エラーメッセージを読みやすくする方法

template < typename ... Types >
Derived( Types ... args )
    : BaseType( std::forward<Types>(args)... )
{
   static_assert( std::is_constructible< BaseType, Types...>::value
    , "BaseType is not constructible from given argument list." ) ;
}

これは言うほど難しくないのだが、やはりC++に不慣れな人間は、これだけでも黒魔術的コードだと錯覚するであろう。たんに標準ライブラリのis_constructibleと、コア言語機能のstatic_castを使っているだけなのだが。

発表当日では、私はこのコードの意味を忘れたふりをしてウケを狙った。あまりウケなかったようだ。

Variadic Templatesは難しい

Variadic Templatesは、一般人には使いこなせない。

だからこそ継承コンストラクターが提案された。

継承コンストラクターは使いやすい。

では、実装はどこ?

なぜ実装されないのか

継承コンストラクターの実装は困難である。

  • 規格の文面が曖昧
    • 誰も実装していなかったから問題点が洗い出されなかった
    • そもそも、using宣言の文法を流用したのは失敗だった
  • 新しい専用の呼び出し規約が必要
    • C言語から受け継いだ可変引数に対応するため

Clang開発者の声

Clang開発者の声

Douglas Gregor、「継承コンストラクターは意外と難しい。それに、誰も気にかけてない」

zygoloid、「継承コンストラクターはC++11のexportになるべきだ」
Douglas Gregor、「賛成」

Douglas Gregor、「たかが継承コンストラクターのために新しい呼び出し規約を作るのは面倒」

予想

継承コンストラクターは、C++11のexportになる。

問題

コンパイラー独自の機能を付け加えたい。

  • アライメント
  • 最適化の強制、抑制
  • 関数の呼び出し規約の指定
  • その他多数

独自機能は必要である。

現状

プリプロセッサーや独自のキーワードが用意されている。

// MSVCの独自マクロ
#pragma ...

// MSVCの独自キーワード
__declspec( ... )

// GCCの独自キーワード
__attribute__( ... )

どのコンパイラーも、てんでばらばらに実装している。

既存の独自機能の多くは、単純なプリプロセッサーやキーワードで指定する、ちょっとしたアノテーションである。

機能の指定方法を統一できないものか。

理想的な解決方法

C++11では、汎用的な機能の指定方法の文法として、属性が導入された。

[[ ... ]]

これにて文法が統一されるはず。

無問題

属性には問題がない。

  • 規格制定前に試験的に実装されたことがある
  • 既存の文法との衝突は少ない(配列の添字の中のlambdaの問題は解決された)
  • 既存の独自文法を置き換える柔軟な配置場所(ほぼ、どこにでも配置できる)

属性の現実

  • 既存のコードは自動的に書き換わらない
    • コンパイラーは、既存の文法も残しておかなければならない
    • 移植性のない独自機能のために新しい文法を学びたいか?
    • 移植性のないコードをほんの少し規格準拠に書きたいか?
    • 誰も既存の完璧に動くコードを書き換えたくはない
  • どうせ環境依存の独自機能なのだから、文法に互換性があっても意味がない

2012-05-25

xkcd: クラウドソーシング

xkcd: Crowdsourcing

「我々はデザインプロセスをクラウドソーシングすることにより、卓越したデザイン技能をもつ人々を、すでに確立されたソーシャル・ネットワーキングのプラットフォームで結びつけることにより、外部の製造と流通と営業の垣根を超えることを実現するものであります。」

この計画に、「我々」が一切関わっていないことに気がついている者はいないようだ。これでは単に、誰か他人が、製品を作って売っているだけだ。

100ナノ秒ぐらいの分解能をもつクロック実装

可能であれば、100ナノ秒ぐらいの分解能を持つクロックを実装してみた。

POSIX版。

class nano_resolution_clock
{
public :
    using rep = std::chrono::nanoseconds::rep ;
    using period = std::chrono::nanoseconds::period ;
    using duration = std::chrono::nanoseconds ;
    using time_point = std::chrono::time_point< nano_resolution_clock > ;

    static const bool is_steady = true ;

    static time_point now()
    {
        timespec ts{} ;
        clock_gettime( CLOCK_MONOTONIC, &ts ) ;

        return time_point( duration(
            static_cast<rep>( ts.tv_sec ) * static_cast<rep>( 1000000000 ) + static_cast<rep>( ts.tv_nsec )
        ) ) ;
    }

} ;

Win32 API版のnowの実装(コンパイルすらしてない)

static time_point nano_resollution_clock::now()
{
    LARGE_INTEGER counts ;
    QueryPerformanceCounter( &counts ) ;

    LARGE_INTEGER freq ;
    QueryPerformanceFrequency( &freq ) ;

    return time_point( duration( 
        static_cast<rep>(counts.QuadPart) * ( static_cast<rep>(1000000000) / static_cast<rep>(freq.QuadPart) )
    ) ) ;
}

さて、実際の精度はどうかというと、まずナノ秒は無理である。現在の最新のIBM互換機で達成できる最高の精度は、せいぜい100ナノ秒といったところだろう。なぜかというと、精度は環境のハードウェアに左右されるからだ。

IBM互換機では、複数のタイマーハードウェアがある。最も精度が高いのは、Time Stamp Counter(TSC)である。TSCはCPUの専用のピンが割り当てられており、CPUクロックと同期してカウントされるので、当然、精度が高い。たとえば、1GHzのクロックで駆動されるCPUであれば、1ナノ秒の精度を持つ。ただし、現代では信用できない。なぜならば、モダンなCPUは、省電力や発熱を抑えるなどの理由から、クロックが可変になっているからだ。また、マルチプロセッサー環境(マルチコアではない)では、カウンターは共有されていないので、プロセスを実行する物理プロセッサーが途中で切り替わると、悲惨な結果になる。

次に精度が高く、現実的に理想のタイマーは、High Precision Event Timer(HPET)である。これは、IntelとMicrosoftが猛烈にプッシュした比較的新しいハードウェアだ。規格上、10MHz以上の周波数が保証されているので、100ナノ秒の精度が保証されていることになる。たとえば、私の使っているマザーボードに載っているHPETは、14318180Hzで駆動しているらしい。つまり、私のマザーボードに搭載されているHPETは、約70ナノ秒ぐらいの精度をもっていることになる。

次なるはACPI Power Management Timerである。これは、ACPIを実装しているマザーボードならば必ず搭載しているハードウェアである。ACPI Power management Timerのクロック周波数は規格により固定されていて、きっちり3579545 Hzである。つまり、約280ナノ秒の精度がある。

これより先は、まともな精度が望めない。たとえばProgrammable Interval Timer(PIT)があるが、この精度はマザーボードによりけりだ。たいてい1ミリ秒の精度があるが、マザーボードによっては、実質10ミリ秒程度の精度しかないこともある。Real Time Clock(RTC)もあるが、これはマザボに載っている、電源がなくても動くようバッテリー駆動されている時計だ。一応2Hzから8192Hzまでの範囲でプログラム可能だが、所詮はマザボの時計なのだから、精度は期待できない。

ちなみに、この知識はUnderstanding the Linux Kernelで得た。この本は非常に素晴らしいので万人におすすめできる。

2012-05-24

GCCエクスプローラー

GCC Explorer - an interactive take on compilation — Matt Godbolt’s blog
mattgodbolt/gcc-explorer · GitHub
GCC Explorer

GCCへの入力に対するアセンブリ出力を、重要な部分だけ整形して表示してくれるツール。すごすぎる。

libc++のビルド方法

[cfe-dev] Building libc++ on Linux

LLVM公式のC++のSTLの実装であるlibc++のビルド方法には、まともなドキュメントがない。これは、libc++のビルドは、そう簡単ではないからだ。実は、libc++自体のビルド自体は、他のいわゆる.soにコンパイルされるライブラリと何ら変わらない。結局、ソースコードを全部まとめて、ライブラリファイルとしてコンパイルすればいい。それこそ、根本的にはたったの一行のコードですむ。

clang -std=c++11 -shared *.cpp -o libc++.so

ただし、このコマンドラインには、一つ重要な指定が欠けている。C++のランタイムライブラリである。

C++のランタイムライブラリとは、RTTIや例外機構、デマングルなどの低級な機能を提供するライブラリである。慣習的に、UNIX風の環境では、C++の低級なランタイムライブラリの実装とSTLの実装を分割している。ランタイムライブラリには、定まった規格があるわけではないが、多くのUNIX風環境のコンパイラが採用している、業界標準とも呼ぶべきものがある。

Itanium C++ ABI

というわけで、C++のランタイムライブラリのヘッダーへのパスとライブラリファイルを指定しなければならない。ランタイムライブラリの実装は多数ある。ランタイムライブラリの選択は、技術的、政治的理由により難しい。主な候補は3つある。

libsupc++
最も古いGNUによる実装である。stdlibc++で使われているC++ランタイムライブラリの実装でもある。GCC標準のランタイムライブラリであるので、実績は十分にある。通常のGCCとのバイナリレベルでのC++互換性を実現したいならば、これを使うしかない。ただし、実装に問題があるそうだ。また、ライセンスもstdlibc++と同じなので、GNUの定義する自由が気に入らない人間には、使いづらいライセンスである。もっとも、STLというのはソースコードの形でリンクして使うので、リンク例外があるのだが。
libcxxrt
比較的新しいPathScaleの実装であり、GNU/LinuxやFreeBSDやNetBSDやSolarisといった環境で、実用的に使われている実績がある。FreeBSDは、libcxxrtを標準で使っている。現在のところ、最も完成されたC++ランタイムライブラリであると言える。ただし、GCC互換性がない
libc++abi
最も新しいLLVM公式プロジェクトによる実装である。まだまだ開発途中で問題も多いそうだ。

どれを使うかというのは、GCCとのバイナリ互換を目指すか、無難に実用的なlibcxxrtにするか、あるいはLLVM公式の実装を使うかという、非常に難しい選択を迫られる。

つまり、単なるユーザーが気軽にlibc++をコンパイルして実用的な環境に投入するのは、おすすめできない。これは、環境を構築する者の仕事だ。たとえばGNU/Linuxのディストロとか、FreeBSDとか。

C++11の時間ライブラリは美しさを追求したあまり、かえって使いにくくなっているのではないか

C++11の時間関係のライブラリは、非常に美しい設計をしている。

まず、経過時間そのものを表すdurationがある。Cライブラリでいえば、time_tの値の単位を指定するクラスだ。Cライブラリでは、time_tの値は秒であったが、C++では、単位を指定できるのだ。

durationでは、単位ライブラリであるratioを使って、秒、ミリ秒、マイクロ秒などといった時間単位を表現している。

秒
std::chorno::seconds 
ミリ秒
std::chrono::milliseconds
ナノ秒
std::chrono::nanoseconds
時
std::chrono::hours

それ以外の、独自の刻みがほしいとしても、簡単に作成できる。

4分33秒
using four_minutes_thirty_three_seconds = std::chrono::duration< long, std::ratio< 4 * 60 + 33 > > ;

duration同士は、たとえ異なる単位系であっても、足し引きできる。たとえば、10秒と3分を足したら、結果は190秒になってほしい。durationではそういう計算が可能だ。

int main()
{
    std::chrono::seconds sec( 10 ) ;
    std::chrono::minutes min( 3 ) ;

    // 結果の型はstd::chrono::seconds
    auto result = sec + min ;
    
    // 190
    std::cout << result.count() << std::endl ;
}

また、単位時間の変更も非常に楽だ。たとえば、180秒を分に変換したいとする。それには、専用のduration_castが用意されている。

int main()
{
    std::chrono::seconds sec( 180 ) ;
    auto min = std::chrono::duration_cast< std::chrono::minutes >( sec ) ;

    // 3
    std::cout << min.count() << std::endl ;
}

次に、durationを使って、ある起点からの経過時間を表す、time_pointがある。つまり、Cライブラリではtime_tに当たる機能を提供するクラスだ。調べた限りでは、どうやら起点時間がいつであるかは、規格では指定されていない。ただし、起点時間を確かめるポータブルな方法はある。time_pointとtime_tを相互に変換する方法があるので、古き良きCライブラリで調べることができる。C++で新しいライブラリを用意しなかったのはなぜだろうか。時間が足りなかったのだろうか。

// 起点時間を表示するプログラム
int main()
{
    auto tp = std::chrono::system_clock::time_point() ;
    std::time_t t = std::chrono::system_clock::to_time_t( tp ) ;
    std::cout << std::ctime( &t ) << std::endl ;
}

少なくとも、Cライブラリには十分な実績があることは確かだ。

最後に、現在のtime_pointを取得するclockクラスがある。Cライブラリではtime()にあたる関数だ。このクラスは、オブジェクトとしては使わない。ネストされた型名やstaticメンバー関数を使う。クラスは複数あるが、通常は、std::chrono::system_clockを使っておけばよい。より精度の高いクラスとして、std::chrono::high_resolution_clockがある。また、ちょっと特殊なのだが、絶対に時間が逆転しないことが保証されている、std::chorno::steady_clockというものもある。これ以外のクロックは、例えばシステムの日付を過去に戻した場合、以前に返したtime_pointより昔のtime_pointを返す可能性がある。steady_clockは、そのような場合でも一律に進むようになっている。

clockの使い方は簡単で。clock::durationやclock::time_pointが、そのまま、そのclockが使う型になっている。現在のtime_pointは、staticメンバー関数のnowで取得する。

// 美しいC++ライブラリの使い方
auto tp = std::chrono::system_clock::now() ; // 現在時間のtime_pointの取得
auto d = tp.time_since_epoch() ; // durationの取得
auto r = d.count() ; // 経過時間の内部表現の取得

設計自体は美しいと思う。時間という概念を、単位、経過時間、起点からの経過時間というコンセプトに分けて、これらをまとめてクロックというコンセプトにした。

問題は、これらのコンセプトを学ぶのに、労力がかかるという事だ。私は規格を読めるし、Boostや標準化委員会での議論の経緯も知っているからいいものの、通常のユーザーがプログラミング言語をただ使うためだけに、規格や規格制定時の議論や背景の理解を必要とするべきではない。

さて、Cライブラリはどうか。Cライブラリでは、単位を変更することはできない。必ず秒単位である。ただし、単に日付として使いたい場合は、これでも差し支えない。さらに、time_tはtime_tである。これ自体が内部表現であり、何らかの整数型なのだ。time_tはこのまま、整数型として、printfで表示できる。なにもメンバー関数を呼び出す必要はない。メンバーを使うということは、そのクラスについて知っていなければならないという事だ。つまり、ドキュメントをひっくり返して、メンバーの一覧から、望みのメンバーを見付け出さなければならない。これは果てしなく面倒だ。

参考に、Cライブラリで書いてみよう。

// 古き良きCライブラリの使い方
time_t t ;
time( &t ) ;

なんと、これだけのことをするのに、C++では覚えなければならない概念が多すぎる。

第一、そのtime_pointやdurationの型は、テンプレートを使用しているため、非常に長ったらしい型になっている。この記事では、C++11の新機能であるautoを使ったため、読者はそのような恐ろしい型を直接扱わずにすむようになっている。しかし、いざ詳細を学ぼうと思うと、まずテンプレートの詳細を学ばなければならない。なぜならば、クラスはテンプレートの高度な機能を使っており、テンプレートの理解なしでは、本当に理解することができないからだ。

C++11の時間ライブラリは美しく設計されたライブラリである。ユーザーは望みの単位系を使うことができるし、単位系の変換コードを自前で書く必要はない。ましてや、ポインターとは無縁の世界だ。しかし、覚えるべきコンセプト(概念)が多く、また詳細はテンプレートという難しい機能で隠されている。

もちろん、Cライブラリだって、使うとなればドキュメントが必要だ。しかし、Cライブラリのドキュメントは豊富だが、C++のドキュメントは、C++03時代のライブラリでさえ、まれである。多くは、すでに時代遅れで使い物にならない。ましてや、日本語のドキュメントとなると、さらに少ない。時代遅れの英語のドキュメントの翻訳があるだけで感謝しなければならない。

このような状況は、ドキュメントを執筆している私のような人間には、ある程度有利であると言える。世の中には良きドキュメント執筆者が不足している。競争は少ない。規格さえ読めればC++のドキュメントを書くのは難しくない。

しかし、こんなことでいいのだろうか。私には、どうも、美しさを追求した挙句、むしろ学びにくくなっているのではないかと思われてならない。

2012-05-23

C++11による高精度なカウンター

パフォーマンスを計測するには、高精度なカウンターが必要である。このカウンターは、決まった周期で値が刻まれることにより、正確な経過時間の計測ができる。

最近、GNU/Linuxに移行したので、またどうもこの環境に慣れていない。ともかくGNU/Linuxで高精度なカウンターを使う方法を調べることにした。つまり、Win32 APIでいうところの、QueryPerformanceCounterのようなものがほしい。

まず見つかったのはPOSIXのclock_gettimeだ。これを使えば、ナノ秒単位での分解能が得られる。ただし、timespec構造体が非常にややこしい作りになっている。秒とナノ秒に分かれているのだ。これは面倒だ。こんなインターフェースでは間違えたコードを書いてしまいそうだ。

また、未だにGNU/Linux環境におけるライブラリのリンク方法がよくわからないのだが、どうもclock_gettimeを使うには、rtと呼ばれるライブラリとリンクしなければならないらしい。が、しかしそんなのはmanページには書いていない。さらに不思議なことに、そのオプションの渡し方が解せない。

gcc -lrt hoge.c 

ではだめで、

gcc hoge.c -lrt

は動く。理由が謎だ。わけがわからない。GNU/Linux環境にはまともなドキュメントが不足している。

そこで、C++11の登場だ。C++11では、もっと簡単なライブラリが用意されている。しかもポータブルだ。ただ、現時点ではまともな資料が少ないので、使いにくいかもしれない。それに、ポータブルといっても、現状ではPOSIXの方が実装が多いように思う。

使い方としては、std::chrono::high_resolution_clock::now()を呼び出すだけだ。つまり、パフォーマンスを計測するのであれば、

auto time_point = std::chrono::high_resolution_clock::now() ;

// ここにパフォーマンスを計測したい処理を書く

auto duration = std::chrono::high_resolution_clock::now() - time_point ;

これだけでいい。問題は、ここから先だ。std::chrono::high_resolution_clock::now()が返すのは、time_pointクラスである。time_point同士を引き算すると、durationクラスになる。durationクラスのカウント数は、メンバー関数countを呼び出すことで得られる。

std::cout << duration.count() << std::endl ;

問題は、high_resolution_clockの精度が、規格では定められていないということだ。そのため、単にこのduration.count()の返す値は、このままでは一体何秒を意味するのかわからない。

そこで、このdurationの型が何であろうと関係ないポータブルなコードを書く必要がある。それには、duration_castが使える。

auto count = std::chrono::duration_cast< std::chrono::microseconds >( duration ).count() ;

このコードは、durationのテンプレート引数がなんであれ、マイクロ秒に変換する。したがって、countは、そのままマイクロ秒数として扱うことができる。ちなみに、他の単位も豊富に用意されている。必要とあれば、自分で単位を作り出すこともできる(例えば、5分単位の刻みだとか)

と、ここまで書いて思ったのだが、これを一体どうやって教育すればいいのだろうかということだ。QueryPerformanceCounterやclock_gettimeは、とても低級なCの関数である。引数に渡すのも、とても低級な構造体である。ポインターを使わなければならない。その結果は、あまりにも低級で生々しい値なので、実際に使用するためには、正しく加工しなければならない。すなわち、単位の変換だ。この加工作業は、単純ではあるものの、かなり難しい。私は変なことを書いているのではないし、世の中のプログラマーの能力をみくびっているわけでもない。多くのプログラマーは、こういう加工作業や、バージョン確認などといった、一見単純に思えるコードの記述を間違える。でなければ、ブラウザーやAdobe Flash Playerやドライバーのバージョンが上がっただけで動かなくなるソフトウェアがこんなにも多いはずがない。

しかし、Cプログラマーは、ポインターを正しく使えることが期待されているし、どんなに些細で単純なコードでも、自力で正しいコードを書くことが期待されている。したがって、これは問題にはならない。

その点から見ると、C++11のライブラリは非常に高級である。time_pointクラスは、ある起点からの経過カウント数であり、time_pointクラス同士を引き算した結果は、durationになる。これは当然だ。引き算した結果は、起点からのカウント数ではなく、単なるカウント数なので、durationになるのだ。ポインターも必要ないし、余計な加工もいらない。演算子のオーバーロードにより直感的に扱えるし、型同士の変換もduration_castが用意されている。

C++ユーザーは、C言語で必要な低級な能力を必要とされない。

問題は、time_pointやdurationが、任意の精度を取れるように、精度をテンプレート引数として指定可能なことだ。たとえば、gccのSTL実装では、std::chrono::high_resolution_clock::time_point、すなわちnow()の返す型は、

std::chrono::time_point<std::chrono::system_clock, std::chrono::duration<long, std::ratio<1l, 1000000l> > >

という、途方もない型になっている。何気ないコードで、こんな恐ろしい型が使われているのだ。

C++11では、auto指定子のおかげで、表面上はこのような恐ろしい型を目にせずともすむ。しかし、ユーザーが標準ライブラリを本当に使いこなそうとすると、やはりこういう詳細を知ることが重要になってくる。この詳細を理解するためには、テンプレートの詳細な理解が必須である。はたして、普通のユーザーにできるだろうか。これを考えると、ポインターとか生の値の加工とかが、可愛く見えてくるではないか。

一日中、C++規格を眺めて暮らしている私のような人間はいいとして、C++を単に道具として使いたいユーザーが、貴重な時間をこんな詳細の理解に割きたいと思うだろうか。

今でも乗除算をビット演算に展開する意義はあるんだろうか

昔は、乗除算のオペランドの片方が定数であれば、たとえCPUに乗除算の命令があったとしても、ビット演算に展開したものである。これは、乗除算命令は、ビット演算に展開するよりも遅かったからだ。

深いパイプラインやマイクロコードへの変換が一般化した今はどうなっているのだろう。2の累乗のような綺麗な例はともかくとして、そういう二進数的に綺麗な数ではない場合、複数のビット演算を組み合わせなければならない。その分コードサイズが膨れ上がり、コードがキャッシュに乗らなくなり、また命令をマイクロコードに変換するデコーダーが一度に読み取る命令数からも溢るような気がするのだが。

まあ、一番重要なことは、もはや一介のプログラマーが、そんな些細なビット魔術を知らなくてもよくなったということだ。実際、この2012年では、もはやコンパイラーの吐き出すアセンブリを確かめる気にもならない。

LLVM 3.1がリリースされた

LLVM 3.1 Release Notes
Clang 3.1 Release Notes

なんでリリースが遅れたのかはわからない。IRCでは、gcc4.7では、ほとんどのSTLが動かない。リリース前までに直す必要があるということが議論されていたように思う。

とにかく、LLVM 3.1のリリースは、C++的になかなか興味深い。

まず、このリリースによって、C++11のコア言語のほとんどの機能はサポートされた。特に、lambda、initializer list、constexpr、user defined literalのサポートは大きい。というより、サポートしていない機能を挙げたほうが早い。サポートしていないコア言語の機能とは、AttributeとInheriting Constructorsとthreadlocalぐらいなものである。thredlocalは必要だが、AttributeとInheriting Constructorsの優先度は非常に低く、とくにInheriting Constructorsは問題があり、開発者のやる気がでないらしい。

そのへんの話については、26日の勉強会で話すつもりだ。

ちなみに、今回はatomicもサポートされたそうだ。

libc++は、GNU/Linux環境で試すことぐらいはできると思うのだが、とりあえずユーザーがコンパイルするための簡単なドキュメントからして存在しない。存在しないからには、まだ時期尚早なのかもしれない。調べたところによると、libc++の他に、C++のランタイムライブラリ(ABIとかRTTIとかの低級実装)が必要だそうだ。これは様々な実装があるが、gccと互換性を保ちたければ、gccのライブラリを使う必要がある。ちなみに、FreeBSDは、libc++を標準で含めている。FreeBSDは、「自由」の定義の相違から、GNUとは距離を置きたいらしく、当然の動きと言えるだろう。

ちなみに、今年のGSoCで、Debianでlibc++をパッケージ化するプロジェクトが受け付けられている。その過程で、ドキュメントなんかも整備されたりはしないかと期待している。

廃止された機能もある。LLVM 3.1では、Cバックエンドが廃止された。廃止理由は、「そもそもまともに動かねーよ」ということらしい。また、LLVM 2.9のバイトコードとの互換性が打ち切られた。今後のリリースは、LLVM 3.0以降の吐き出すバイトコードとの互換性を保つそうだ。

それから、Clangをコンパイルするのに、今までPerlが必要だったのだが、これがPythonに変わった。また、公式のPython bindingなども3.1から入ったようだ。詳細はよくしらないが、世の中はますますPythonになっていくのだろう。思うに、Pythonは非常に素晴らしいスクリプト言語なので、C++プログラマーは学ぶべきだろう。

2012-05-19

演算力は無限になっとる

Living in the Era of Infinite Computing Power

めちゃカンタンな計算が、昔は遅かったんや。8bitプロセッサーで一万回ループしようとおもたらな、内側256回ループする外側で40回ループしたほうが速かったんや。16bitの加算と比較を行うために複数の命令を使わんでもええからや。

掛け算と割り算が、昔は遅かったんや。そもそも、そんな計算するCPU命令なんてなかったんやで。掛け算のオペランドの片方が定数やったら、加算とビットシフトに分解できるんやが(Nに44を掛けるには、N 左シフト 5 + N 左シフト 3 + N 左シフト 2や)、まあ、世の中そんなに都合よういってくれへんわな。

浮動小数点数が、昔は遅かったんや。FPU以前、浮動小数点数の計算はめちゃめちゃ遅いソフトウェアで行われていたんや。はじめのハードウェアは、マシなんはマシやったが、そんなすごいことあらへん。いっちゃんはじめの8087コプロセッサーは、カンタンな浮動小数点数の足し算に少なくとも90サイクル、割り算やと200サイクル以上もかかってたんやで。千サイクル以上かかる命令もあったんや。

グラフィックが、昔は遅かったんや。昔はな、320x200のディスプレイをまともな速度で更新するのが難しかったんや。640x480なんていうめちゃすごい解像度でゲームができるなんて夢のまた夢やったんや。

こういう問題が、いまや漫才みたいに解決してしもうた。今のCPUは複数の64bitの値を同時に一サイクルで足し算できるんや。浮動小数点数も同じや。掛け算もやで。ソフトウェア描画されてたスプライトとかポリゴンは、別のめっちゃ並列化されたプロセッサーで処理されてて、メインの複数コアのCPUと同時に走るんや。

1990年代のどっかで、Pentium IIのクロックが300-400MHzに達した時、演算力はもう無限になったんや。そりゃ例外はある。動画圧縮とかハイエンド3Dゲームとかめっちゃ高画質な画像編集とかやな。でもな、ワシインタプリタ実行されたErlangで快適に開発しててん、複雑なPerkスクリプトを、パフォーマンスなんか気にせず実行しててん。

ワシが初期の66MHzのパワーマッキントッシュでグラフィカルなゲーム作ってた頃に比べたらな、ワシが20MHzのSUNのワークステーションで商用通信ソフトウェアを書いてた頃に比べたらな、ワシがションベンみたいな8bitのAtariで開発してた頃に比べたらな、1990年のPentium IIは奇跡みたいなもんやった。

あれから、演算力ってのはもう進歩してへんな。そりゃ、千二百万画素の画像を吐き出すカメラはある、Windows 7はWindows 98よりオーバーヘッドがある、モニターの解像度もえらく上がっとる。あんまり高速に処理できひん問題はいくらでも転がっとる。どっかのハードウェアのレビューサイトが、「チップセットXはチップセットYより、あるベンチマークにおいて8.17%高速である」とかいうのがどうでもようなる問題は常にある。

お前ら、無限の演算力を有効につこうてるか? 低級なパフォーマンスを気にしないようにしとるか? 最適化なんかのちっぽけな問題のためにプロダクティビティっちゅうやつを無駄にしとらへんか? お前ら、最終的な結果が便利になるように、余計なこと気にせんでもええようなスタイルでプログラミングしとるか?

まあ、こういうとSeth Godinみたいに聞こえるけどな。今時、誰も気にせえへんことをぶつくさいうとるようやがな。せやけど、iOSやろ、Androidやろ、Webアプリやろ、こいつらは昔のソフトウェア開発がどんなだったか全く分からへん奴らによって開発されてて、昔なら非効率的と言われてたツールセットをつこてて、しかも、どんなプラットフォームでも、当然のように処理能力を全然気にせえへん奴らによって開発されとる。

お前らこの記事が気に入ったらやな、速いってどんだけ演算力がいるねん?も気に入ると思うで。

カンタンなんがええのにワケわからへんもんをつくる

We Who Value Simplicity Have Built Incomprehensible Machines

8086のAAA命令っちゅうやつは、まあ昔はよかったんや。1970年代は、二進化十進数、つまり一バイトで二桁を表す必要がある時代やった。BCDって何がそんなにええんや? おっきな数字が、マルチバイトの掛け算とか割り算とかせえへんでもカンタンに表示できるんや。加算した後はASCII化(ASCII Adjust After Addition)やからAAAっちゅうわけで、x86ハードウェアに三十年以上前から居座っとる。そこらにあるi7プロセッサーは全部、AAAをマイクロコードでエミュレートしとる。

Cライブラリ関数のmemcpyっちゅうやつも、まあ昔はよかったんや。memmoveはそこそこ早くて、もうちょいと器用なやっちゃ。コピー元とコピー先がオーバーラップする場合でもちゃんとええ感じにやってくれる。でもな、そのために数命令ほど余計に必要ってのは、そりゃ気にするがな、もういっこ、最適化されたメモリーコピールーチン、つまりmemcopyがほしいがな。そやろ。そないなわけで、ワシら似たような関数が二個もあつこうてるわけや。まあ、未だにオーバーラップ対応の必要がないmemcpyが重宝される場合もあるわけやけど。

libpngっちゅうやつも、まあ昔はよかったんや。つまりあれやがな、カンタンでプラットフォーム非依存な方法でPNGファイルの読み書きしまっせちゅうやつやな。まあ、実際、動くし、プラットフォーム非依存なわけやけど、でもな、このワシがあんだけドキュメント読んで、いまだに画像一枚読み込む方法が分からへんのは、まあ、あのライブラリぐらいなもんやで、ホンマ。ワシ、いつも「カンタン libpng サンプル」でググって見っけた二十行ぐらいの関数をコピペしとるんや。

UNIXのlsっちゅうやつは、まあ昔はよかったんや。いかにもUNIX風のやり方っちゅうやつやな。ひとつのことだけめっちゃようできるちっぽけなツールや。つまり、ファイル名の一覧を表示するっちゅうことや。せやけど、どのファイル名をどんなフォーマットで表示するかってことで、35個以上ものコマンドラインスイッチがあるんやで。あんまり恥ずかしなったのか、BSD版のmanページのいっちゃんはじめには、「下位互換性を維持するため、オプション間の関連性は非常に複雑である」って書いてあるんやと。

どれひとつとっても、今のコンピューターをワケわからへんもんにはしてへん。これだけの理由で、SDKに200ページもの概要を説明するドキュメントがついてきて、APIを説明する数千ページのドキュメントのどのへんを読めばええか説明する理由にはなってへん。

けどな、こういうむつかしいことが積み重なり、そもそも最初からいらへん一つの機能がふたつの機能で分かれたり、誰かのすでに書いたコードをぶっ壊すかもしれへんからと直さずいたから、積もりに積もってまともやなくなるんや。ワシらが満足している裏で、システムが理解できひんようになっとる。

ワシらのせいや。ワシらカンタンなんがええといってるやつらのせいや。そんなに意味あれへんしょーもない些細な設計を行なっている最中に、ワシら止められたはずやないか、「まちなはれ、やめなはれ」と。まあ、ぐうたらで、変更した方が楽な場合でもや、何千ものユーザーが出てきて、いまさら後にひけんようになる前に、問題を修正できたはずやないか。なんでワシら、せえへんかったんや。

お前らこれきにいったんなら、演算力は無限になっとるってのも気にいるとおもうで。

本の虫: 演算力は無限になっとる

2012-05-18

ふたこぶラクダのテストを採用試験に使う方法

本の虫: 60%の人間はプログラミングの素質がないという記事に対して、こんなTweetが目についた。

なかなか面白そうだ。この問題をプログラマーの採用試験に適用するには、Javaのような有名な言語ではだめだ。なぜならば、このようなよくある文法は、すでに知られているからだ。

究極的に、この問題とは、「未知の言語に対して規則を生成して一貫して適用できるか」どうかをみるものである。そのため、すでに言語を知っているものにはうまく働かない。

そのため、絶対に知られていない言語を使うべきである。マイナーなプログラミング言語というだけではこの用の役には立たない。そこで、独自の言語を定義する必要がある。そして、言語の定義を知らせずに、言語の規則に従った文を複数見せて、評価結果を答えさせる。

たとえば、001100111011000111100だ。

さて、このあとが難しい。この試験結果を採点するには、どのような規則を推測したかということは考慮せず、推測した規則を一貫して適用したかをみる。どのような規則を推測したか、被験者に聞いてはならない。あくまで、外からの観測から採点しなければならない。この問題を正しく採点するのは難しい。採点しやすい言語を考案する必要もあるだろう。

したがって、問題の出題と採点には、形式言語の知識などが必要であろう。実はこの手の規則を見つけるのがものすごく得意な人間がいる。暗号解読の研究者だ。ある有名な暗号解読の研究者は、子供の頃、友人が作ったどんな暗号でも、数日で解いてしまったという。未知の規則性のある言語から、その規則性を見つけるのが得意な人間がいるのだ。

ということは、暗号解読や、ある種のパズルの才能のある人間は、プログラミングの才能もあるのだろうか。

ちなみに、上記の言語の意味は、直訳すると、「生命の危機に瀕している場合、ベラベラしゃべる者の隣に立つな」である。これを正しく答えられたものは、相当にオタクである。しかし、今日ではGoogleという存在があるので、本物のオタクを見分けるのが厄介だ

ゲームとインフレ

ドラクエ9の合成はなぜ間違いで、ディアブロ2の合成はなぜ正しいのか。 - 真性引き篭もり

なかなか面白い。

ゲームはインフレする。無尽蔵に湧く敵を倒せばゴールドやアイテムが手に入るのだから、無制限に通貨発行をしているようなものなのだ。それゆえインフレする。だから、ゲームスタート地点では、数ゴールドのひのきのぼうとか、数百ゴールドのどうのつるぎぐらいしか売っていないものが、ゲーム終盤になると何十万ゴールドもする、まじんのかなづちとか、はかいのてっきゅうとかが出てくる。宿屋からして、ゲーム終盤はボッタクリ価格である。

インフレの極みに到達した時、ゲームは遊びつくされて終わる。ユーザーはまた別のゲームを、まだ自分の中でインフレしていないゲームを求める。

オフラインゲームならば、これでもいい。所詮、ひとつのゲームを飽きずに永久に遊べるわけもない。むしろ、ある程度遊んだら、満足した上で飽きて欲しい。そうすれば、別のゲームを買うだろう。ゲームに満足したならば、続編も必ず買ってくれるに違いない。

ところが、オンラインゲームでは、それは困る。オンラインゲームでは、ひとつのゲームを遊び続けてくれないと困る。月額課金にせよアイテム課金にせよ広告にせよ、オンラインゲームは遊び続けてくれるからこそ、パブリッシャーは儲かるのだ。そのため、オンラインゲームにおけるインフレは存亡に関わる。一方、全くインフレしないゲーム、すなわち何時間やり続けても成果が残らないゲームは、やはり面白くない。

そのため、オンラインゲームの開発者は知恵を絞って、一定時間立たないと出現しないボスを作った。このボスは一時間に一回とか、一日に一回などという定期的な時間間隔でしか沸かない。さらに、十分の一とかの低確率でレアアイテムを落とす。インフレしてユーザーが貯めているゴールドは、このレアアイテムと取引される。無限に供給されるゴールドではなく、供給量を制御できるレアアイテムに価値を移転したのだ。インフレの速度は下がった。

しかし、やはりインフレは続く。ユーザーはひたすらボスを狩り続けるため、レアアイテムも市場に飽和する。

オンラインゲームの会社として有名なブリザードは、このインフレ制御に長けていたのだ。いまだに、大昔のDiablo 2が遊び続けられているのには理由がある。

Diablo 2では、ギャンブルによって、大量の金を消失させ、ひょっとした強いかもしれないアイテムを生成する。金はユーザー間を移動するのではなく、消え去るので、インフレを抑えることができる。金の他に、宝石がある。この宝石の入手効率は、初心者でも廃人でもそれほど変わらない。入手できる宝石は、かけらとかひび割れていて、クズである。しかし、Diablo 2には合成がある。クズでも五個集めて合成すると、一ランク上の宝石になる。ランクは五つあり、完璧な宝石が最も価値が高い。宝石と他のアイテムを合成すると、より良いアイテムが得られる。ただし、合成をすると宝石は消えてしまう。

このように、Diablo 2では、価値のあるアイテムを焼くことによって、インフレを制御している。

しかし、いくらインフレを抑える努力をしたとしても、結局時間が経てばインフレすることには変わりない。そこで、ブリザードエンタテイメント社は、他ならば絶対にできないことをする。オンライン上のデータをすべてリセットするのだ。データはローカルには残るが、オンライン上ではリセットされるので、使えない。また最初からやり直しだ。

リセットされる少し前に、リセット予告が出る。そうなったらお祭り騒ぎだ。今まで廃人が溜め込んでいた金や宝石やアイテムが、全て放出される。お祭りだ。すべてを放出して最後のお祭りを楽しもうとする。

ドラクエ9は、この方法を考えもなしにパクった。そもそも基本的にオフラインゲームのゲームなのに、インフレ抑制の手段まで含めてパクった。ドラクエでは、アイテム合成はともかく、インフレ抑制の機能までパクる必要はなかったのだ。しかも、ドラクエの合成は一瞬にして終わらず、無意味に時間がかかる。

まあ、日本のゲームは終わったのだろう。

2012-05-17

ストールマン:不自由でDRM付きのゲームがGNU/Linuxに来ることの是非について

Nonfree DRM'd Games on GNU/Linux: Good or Bad? - GNU Project - Free Software Foundation

リチャード・ストールマンがSteamがGNU/Linuxに進出することについて声明を出している。

デジタル制限管理付きの不自由なコンピューターゲームを配信していることで有名なValveという会社が、GNU/Linuxにもゲームを配信すると発表した。この是非はどうだろう。

思うに、有名で不自由なプログラムがGNU/Linux向けに提供されるという事は、システムを受け入れやすくするであろう。しかし、我々の目標は、単にシステムの成功をもって終わるものではない。目的とは、ユーザーに自由をもたらすことである。故に、この動きがユーザーの自由にどのように影響するかということが問題だ。

不自由なゲームは、他の不自由なプログラムと同じく、ユーザーの自由を否定するがために、非人道的である。自由を欲するのであれば、このようなゲームを自分のコンピューター上に入れないことだ。これは明白である。

しかし、どうせこのようなゲームを使うのであれば、Microsoft WindowsよりGNU/Linuxを使ったほうが、いくらかマシである。少なくとも、Windowsのユーザーの自由に及ぼす害から逃れることができる。

そのため、実情を考察すると、この動向には利点と欠点の両方をもたらす。これによって、GNU/Linuxユーザーにこのようなゲームのインストールを促すかもしれないということと、ゲームのユーザーはWindowsの代わりにGNU/Linuxを使うようになるかもしれないということだ。思うに、直接的な利点は欠点を上回るのではないだろうか。しかし、間接的な影響もある。このようなゲームの利用が、我々のコミュニティの人々に与える影響はどうだろうか。

このようなゲーム配信のソフトウェアを提供するGNU/Linuxディストロは、ここより先は自由ではないということをユーザーに通知するだろう。GNU/Linuxディストロにおける不自由なソフトウェアは、すでに我らの自由の敵である。このようなゲームをディストロに加えることは、敵の勢力を増すことになるだろう。

もし、自由を宣伝したいのであれば、この悪因を防ぐために、このようなゲームがGNU/Linuxで提供されていると吹聴するべきではない。代わりに、Liberated Pixel Cupの自由ゲームコンテストや、LibrePlanet Gaming Collectiveの自由ゲーム集会を吹聴すべきである。

60%の人間はプログラミングの素質がない

Coding Horror: Please Don't Learn to Code
Please Understand Learning to Code

Coding Horrorで有名なJeff Atwordが、ある州知事が今年の目標としてプログラミングを習得することを挙げていることに対し、そもそも税金を払う我々市民は、政治家にはプログラミング習得以上に重要な、政治家にしかできない問題の解決を望む、よってプログラミングを学ぶのをやめてくれという記事を書いた。これに対して、反論が多数上がっているが、Jeffも読んでいるある論文をあげて、この議論の参加するためには、必ずこの論文を知っておくべきであると書いた人がいる。この論文は有名で、非常に興味深いので、全プログラマーが読むべきである。

ふたこぶラクダという名前で知られている有名な論文がある。この論文では、60%の人間にプログラミングの素質がないと推定している。翻訳ではなく、まとめ的な感想として紹介してみる。

The camel has two humps

なぜふたこぶラクダなのかというと、プログラミング学習者の集団において、その成績をグラフ化すると2つの山があるからだ。低成績の山と高成績の山だ。大学でのプログラミング教育の中で、経験的に、プログラミング学習者には三種類いることが知られている。全然できない者と、かろうじてできる者と、すばらしくできる者だ。その中間はほとんど存在しない。できない者とかろうじてできる学習者は、授業の進み方が速すぎると文句を言い、すばらしくできる者は授業の進み方が遅すぎると文句を言う。こんなに学習にばらつきがあっては、すべての初学者向けのプログラミング教育ができない。

この傾向は、年齢、性別、教育レベルの差にかかわらず、等しく起こるものであることも、経験的に知られている。どうやら、世の中にはプログラミングを理解できる人間とそうでない人間がいるように思われる。

もちろん、教育者達は生徒の問題にして逃げたりはしなかった。彼らは教育方法がまずいのであろうと考えた。なにしろ、生徒というのは大学生のコンピューターサイエンス科に入学した学生である。彼らは基礎的な教育を受けていて、世界でも指折りの有名大学に入学できるほどの基礎的な学習能力や環境に恵まれていて、しかもプログラミングの学習に対して意欲的な人間である。それが、毎年毎年、初年度のプログラミング入門講座で半数近くが脱落して学科を変更していくのだから、自体は深刻だ。教育に問題があるに違いない。

教育の改良には、過去に様々な試みがなされた。より簡単な言語を使ってみたものの、結果は大差なかった。教育用の言語を作ってみたものの、やはり結果は同じだった。マウスだけで操作できるIDEのような、より簡単な開発ツールも作られたが、結果はまったく変わらなかった。

学習者に対する調査も様々行われた。お茶に招き話を聞いたり、コンピューターの経験や、自宅の寝室の横にコンピューターはあるかなどの調査を行った。調査結果と、プログラミング能力には、相関性があるようには思えなかった。

オックスフォードとケンブリッジからしかプログラマーを雇用しないある大企業は、新規の雇用者に対して、専攻や実績にかかわらず、必ず一からプログラミングの社内教育を行なっている。IBMなどは一度、コンピューターサイエンス科を専攻した集団より、古典を専攻した集団の方が、良いプログラマーを輩出する確率が高いとまで発表した。

多くのプログラミング学習者が理解に苦しむ問題を調査した所、以下のような結果が得られた。

  • 代入とシーケンス実行
  • 再帰と繰り返し実行
  • 並列実行

再帰やループはたしかに難しい。並列実行はとても難しいが、多くの挫折者はそこまで到達しない。しかし、代入とシーケンス実行という、プログラミングの最も基本的である概念の理解に苦しむとはどういうことか。

人間はどうやってプログラミングを学んでいるのか。ある説によれば、人間は与えられた状況に対して、メンタルモデル(規則)を形成しているのだという。そのメンタルモデルのルールにしたがって状況を解釈する。メンタルモデルが間違っていれば修正を行う。最終的に、メンタルモデルとプログラミング言語が一致するようになる。

そこで、今からプログラミングを学ぼうとする、それまでプログラミングに一切触れたことのない生徒に対して、プログラミングを教える前に、次のようなテストを行った。

テストは、複数の問題からなるが、すべての問題は、基本的に同じものである。

  1. Javaで書かれたふたつかみっつの変数の宣言と、それに続く、ひとつからみっつまでの代入文。
  2. 解答群
  3. 余白

例えば、以下のようになる。

以下の文を読んで、正しい答えをチェックしなさい。

int a = 10;
int b = 20;

a = b;

aとbの新しい値は:

解答群と、解答群に正解がないと考える場合の解答欄。

余白

生徒は、全員プログラミングに触れたことがないが、少なくとも皆、=が数学では等号記号を意味することを知っているだけの数学の基礎的な教育は受けているはずの者たちであった。

もちろん、プログラミングについて何も知らない人間なのだから、Javaのコードとして解釈した場合の代入の挙動を正しく回答したことが正解になるのではない。=は変数の値を変更しないのかもしれない。代入だとしても、右から左ではなく、左から右への代入かもしれない。代入ではなく、移動なのかもしれない。つまり、代入した後の変数は0になるかもしれない。あるいは、値の交換なのかもしれない。

この問題では、解答群の「新しい」という言葉の使用によって、値がなにか変化するものであると推測することを期待している。

どのような規則で回答するかというのは問題ではない。このテストでの評価は、ひとつの規則を、複数の似たような問題に首尾一貫して適用できたかどうかをみた。つまり、=は値を交換するという規則を推測したとしたら、ほぼすべての問題に対しておなじ交換の規則を適用した結果を回答した場合のみ、一貫したグループ(consistent group)とした。問題毎に違う規則で答えたものを、一貫していないグループ(inconsistent group)とした。何も書かずに提出したものを、空欄グループ(blank)とした。

割合としては、一貫したグループが44%、一貫していないグループが39%、空欄グループが8%であった。

既存のコンピューター科学者に意見を求めた所、空欄グループがもっともプログラミングの適正があるグループであろうと予想された。「彼らは、理解していない問題に憶測で答えることを拒否する種類の人間なのだ」と。「したがって、もっともプログラミング適正があるに違いない」

しかし、結果は異なっていた。もっとも高成績のグループは、一貫したグループであった。一貫していないグループと空欄グループに属する人間は、プログラミングの理解に苦しみ、試験の成績も低かった。

プログラミングを教え始めて3週間後に、また同じテストを行った。このとき、最初のテストで一貫していないグループと空欄グループに分類された人間で、一貫した回答に変わる者が半数ほどいた。この一貫に変わったグループに属する者は、変わらなかった者に比べて、高い成績を出した。ただし、試験の高得点は、最初から一貫した回答をしたグループだけしか達成出来なかった。

プログラミング言語とは、それ自体は無意味なものである。ある一定の一貫した規則に従って解釈した結果、これまたそれ自体では無意味な結果を出す。つまり、プログラミングの素質は、構築したメンタルモデルを、ブレずに一貫して適用できるかどうかにかかっているようだ。

無意味な文脈から一貫した規則を形成して適用できる人間は、プログラミングの素質がある。無意味な文脈から多くの規則を生成してバラバラに適用する人間は、プログラミングを学ぶのが難しい。白紙回答した人間は、無意味な文脈に対して規則を生成することを拒否する人間である。この種類の人間も、プログラミングを学ぶのは難しい。

一貫していないグループと空欄グループにプログラミングを教育するのは難しい。教育の結果、プログラミングを規則ある系であると諭すことは可能であるかもしれないが、難しい。

一貫したグループにプログラミングを教育するのは、はるかに簡単である。このグループは、観測的に、さらにふたつに分かれるようだ。ひとつは、プログラミングを非常に簡単に感じ、プログラミングを楽しみ、その後も成長してソフトウェアを書く良いプログラマーになるグループ。もうひとつのグループは、プログラミングはできるものの、それ自体には楽しみを見出さず、管理職になってUML図に溺れるグループ(やれやれ)。

プログラミングの素質がある人間の割合は、年齢や性別や教育レベルでは変わらないようだ。プログラミングの素質のある人間は、40%ぐらいであろう。つまり、残りの60%は、プログラミングの素質がないのだ。

つまり、コードが書けるとしたら、その時点ですでにエリート階級に属しているのである。もし、良いコードが書けるとしたら、指折りのエリート階級に属しているのである。

さて、プログラミングのできる恵まれた諸君に告ぐ。諸君は常人が有していない貴重な才能を有しているのである。諸君は自分の才能を正しく使っているだろうか。諸君の行なっているプログラミングは、本当に自分の人生にとって重要なプログラミングだろうか。

優れたプログラマーは常に不足してることを考えると、皆にプログラミングを教えてみるべきである。皆がプログラミングをする必要はないとしても、自分にプログラミングの素質が備わっているかどうかを見極めるのは重要である。もし、プログラミングが不可能だと感じるのであれば、それは才能の問題である。プログラミングの素質は、たいてい、学び始めて数週間で判明する。数週間学んでプログラミングを簡単だと思えなかったら、素質がないのかもしれない。

ちなみに、ふたこぶラクダの論文はとても素晴らしいので、ぜひとも読むべきである。念の為、もう一度リンクしておく。

The camel has two humps

追記:早くも誤解されている。タイトルが悪かったのかもしれないが、いきなり「ふたこぶラクダ」では、何のことかわからないだろう。

まず、このテストでは、無意味な文脈(JavaのわからないものにJavaのテスト)に対して、メンタルモデルを形成して、そのメンタルモデルを一貫して適用できるかどうかをみている。この素質は、プログラミングや、似たような問題(一部の数学など)にはよく働くが、それ以外の問題にもよく働くかどうかはわからない。ましてや、行動が一貫しているかどうかと関係しているわけではない。

政治方針が一貫しているかどうかとは関わりがないし、ましてや、この素質が政治家の素質としてふさわしいのかどうかもわからない。だから、Jeff Atwordなどは、政治家にはプログラミングをかじるより重要なことがあると言ったのだ。また別のものは、仮にそうだとしても、皆にプログラミングを学ばせてみるべきだと反論している。

2012-05-16

非商用の曖昧性と危険性

多くの不自由な著作物は、「非商用に限り利用可」などという利用許諾、あるいは利用契約を発行している。このような許諾のある著作物は、著作権が制限を受ける場合を除いて、利用してはならない。このような著作物の契約は、結んではならない。なぜならば、著作者は無知か、あるいは邪悪な意図をもってこのような設定をしているからである。

なぜ問題になるのかというと、ほとんどの場合、「非商用」の定義が明確に与えられていないからだ。定義が与えられていない場合、日本語における一般的な「非商用」の意味に従うと解釈するべきである。

派生物の複製物の譲渡や公衆送信を受け取る際に対価を支払わねばならないとしたら、多くの者が、それは商用であるとするだろう。これは納得できる。

では、無償で入手できるが、広告付きのWebページから公衆送信している場合はどうか。Web広告は、現代ではいたるところにある。Web広告では、金銭を受け取る。これは商用であるとする者もいるだろう。

つまり、非商用に限り利用可という許諾や契約の著作物は、広告付きWebページでは使えないことになる。

派生物自体は無償だが、派生物が、自分の他の商用製品を宣伝する広告である場合はどうだろうか。派生物を直接商用目的に使っていないものの、その目的は商用製品を宣伝するためである。これも商用だとみなす者は必ずいるだろう。

そもそも、その派生物をインターネット上で公開するという事は、サーバーにホストさせるという事である。派生物を複製し、公衆送信するのは、サーバーの仕事である。まさか有料のレンタルサーバーを使っていないだろうか。レンタルサーバーは万人が同意する商用である。したがって、非商用の条件に一致しないので、レンタルサーバーの運営者は著作権侵害となる。そもそも、著作権侵害を起こした主体は運営者ではなくレンタルサーバーの利用者なので、派生物を作った自分が著作権侵害者となる。

無料で広告もないレンタルサーバーか、あるいは自前のサーバーならば非商用だろうか。しかし、無料で提供されているレンタルサーバーも、何らかの方法で商業的利益を得ているだろうし、そもそもインターネットのインフラを提供する商用のISPに頼っているので、商用ではないのか。

つまり、インターネット上において、定義が曖昧な「非商用」で著作物を利用する方法は存在しない。

利用許諾に一致しない利用は著作権侵害である。契約違反は契約違反である。刑法、民法に反する行為である。

故に、著作物を「非商用利用のみ可」とする利用許諾や契約を発行している著作者は、無知か、あるいは邪悪な意図を持って、これを行なっていると考えるべきである。我々はそのような契約に応じてはならないし、著作権の制限を受ける場合を除いて、利用してはならない。

自由な著作物かどうかを見極めるのは、かくも難しい。

2012-05-15

61歳の農夫、寝ずに走ったためウルトラマラソンの若い世界級アスリートを打ち負かす

The Legend of Cliff Young: The 61 Year Old Farmer Who Won the World’s Toughest Race - Elite Feet

クリフ・ヤングの伝説は、ランナーの間ではよく知られている。もし、読者がまだ知らないとすれば、この話はすばらしい読み物となるだろう。

あり得べからざる挑戦者

毎年、オーストラリアではシドニーからメルボルンまで543.7マイル(875キロメートル)の耐久レースが開催される。これは世界一過酷なウルトラマラソンとして知られている。レースの完走には5日かかり、通常は、このイベントのために専門に訓練してきた世界級のアスリートしか参加しない。参加するアスリートは、たいてい30歳以下で、ナイキなどの大企業のスポンサーを持っている。

1983年、クリフ・ヤングという男が、レースの開始地点にやってきた。クリフは61歳であり、オーバーオールを着て、作業靴を履いていた。皆が驚いたことに、クリフは観戦者ではなかったのだ。彼はゼッケンを受け取り、位置についた。

報道陣と他のアスリートたちは不思議に思い、クリフに質問した。「あんた気は確かかね。完走できるわけないだろう」と。彼の答えは、「いんや、できるさ。わしゃぁ貧乏な農場育ちでな、馬やトラクターなんて買えなかったんだ。ワシは若い頃から、嵐になるたんびに、羊達を集めなきゃならなかったんだ。2000エーカーの土地に2000匹の羊だ。時にゃ、ワシは羊を探して2,3日走らにゃならんこともあった。時間はかかるが、ワシは必ず羊を捕まえられる。ワシはきっとこのレースを走れるさ」

レースが始まった時、プロ達は素早くクリフを引き離した。観客とテレビ視聴者にとってはなかなか楽しめるネタであった。というのも、クリフの走り方はまともではなかったからだ。彼はブラブラと走っていた。多くのものは、老農夫の健康を心配した。

兎と亀

プロのアスリート達は、レースを完走するには5日かかることを知っていた。完走するためには、一日18時間走り、残りの6時間で睡眠をとるのだ。問題は、クリフは知らなかったのだ。

2日目の朝、皆、驚いた。クリフはまだレースを続けているのみならず、一晩中ジョギングを続けていたのだ。

途中で、クリフはレースの戦略について訊ねられた。信じられないことに、彼の主張によれば、最初から最後まで寝ずに走るのだそうである。

その後もクリフは走り続けた。夜ごとに、彼は先頭集団に追いついていった。最後の夜、彼はすべての、若い、世界級のアスリート達を追い抜いた。終点に最初にたどり着いたのは彼であり、新記録を樹立した。

クリフが優勝賞金の一万ドルを与えられた時、彼は賞金があるなど知らなかったといい、金のために走ったのではないと主張して譲らなかった。彼は結局、賞金をすべて、他のランナー達に分けて与えた。この行動は全オーストラリアの賞賛を浴びた。

伝説は続く

翌年、クリフは同じレースに出場し、7位になった。レース中に股関節を脱臼したのにも関わらず走るのをやめなかった。

1997年、クリフは御歳76歳にして、ホームレスの子供のための募金を得るため、オーストラリアの外周を走るキャンペーンを行った。彼は16000km中の6520kmを走って中断した。理由は、同行者が病気になったためだった。クリフは2003年に81歳で亡くなった。

今日では、「ヤング・シャフル」走法はウルトラマラソンのランナーに取り入れられている。何故ならば、この走法は効率がいい走り方であると考えられているからだ。少なくとも、シドニーメルボルンレースの三人の優勝者が、レースに勝つためにシャフル走法を使った。さらに、現代のシドニーメルボルンレースの参加者は、睡眠を取らなくなった。今やレースで優勝するには、クリフ・ヤングがやったように、徹夜で走る必要があるのだ。

1994年のバルバドス対グレナダ戦では、オウンゴールを意図的に行い、また相手のオウンゴールを阻止する戦法が行われた

Barbados vs. Grenada in '94: The Most Bizarre Match Ever | Bleacher Report

サッカーにおける、基本的な勝利の方法とは、ポストの間にボールを蹴り入れることである。ポストとは、もちろん相手側のポストである。このことに最も長けているチームが、試合に勝利するのだ。

ほとんどの場合、これは事実である。しかし、1994年の悪名高いバルバドス対グレナダ戦では、この論理が逆転してしまった。

カリビアンカップのトーナメントの最終グループの試合において、バルバドスが決勝戦に進むためには、グレナダに二点差で勝利する必要があった。90分間の試合の結果が引き分けである場合、延長戦に持ち込まれるが、問題は、バルバドスは二点差で勝利しなければ、グレナダの代わりに決勝戦には進めないのだ。興味深いことに、主催者はゴールデンゴールの得点を2点にするよう、ルールを定めていた。

[訳注:この当時のサッカーは、ゴールデンゴール制を採用していた。ゴールデンゴールとは、サッカーの延長戦である前後半15分づつの計30分の中で、どちらか一方が一度ゴールしたならば、そのゴールをゴールデンゴールと名づけ、その時点で延長戦を打ち切るというルールである。バルバドスが2点差を付けなければ、真の意味で勝利できないこの状況では、ゴールデンゴールの得点が1点では、バルバドス側に延長戦を行う利点はない。主催者は、勝利が単純に、この戦いのみで決定されるフェアなルールにしようと考えたのであろう。]

バルバドスが2-0でリードしていたが、残り7分というところで、グレナダが2-1に差し戻した。バルバドスがこのまま得点できなければ、試合は終わってしまう。

あるバルバドス選手は,残り数分というこの状況で、防御に徹するグレナダを相手にゴールを決める望みは薄いと判断した。むしろ、勝利する可能性は、この試合を延長戦に持ち込み、2点が得点される特別なゴールデンゴールを決める方が高いと判断した。

そこで、彼は戸惑うゴールキーパーをよそに、自分のゴールポストにボールを蹴りいれた。

さて、グレナダ側にとって、ここで、どちらのゴールポストでもいいのだが、ゴールを決めなければ、決勝戦出場を決める延長戦に突入してしまう。グレナダ選手は、はじめ相手のオウンゴールに驚いたが、すぐにその意図を理解した。そこで、彼らも自分のゴールポストに疾走した。

[訳注:グレナダ側にとっては、1点差で負けても決勝戦に進めるので、この時点でどちらのゴールに決めても勝利する。]

さて、喜劇の始まりだ。バルバドス選手はこの動きを予想していたので、延長戦のホイッスルが鳴るまで、自分のゴールに加えて、グレナダ側のゴールを守るために走った。こんな奇特な小説は、誰が書けるというのか。

結果として、バルバドス側の悪賢い戦法は功を奏した。延長戦の4分というところで、バルバドスのストライカーがゴールを決めることに成功し、バルバドスが決勝戦に進むことになったのだ。

予想通り、グレナダ側はまったくもって感心しなかった。グレナダのマネージャーであるJames Clarksonは怒りもあらわに言った。「これはセコいやり方だ。こんなルールを考えだした人間はマッドハウス送りにするべきだ」

「フィールド上に混乱した選手だらけの試合などあっていいはずがない。我々の選手は、自分のゴールと相手のゴールとで、どちらを攻撃すべきなのかもはっきりしていなかった。こんな試合は見たことがない。サッカーでは、勝つためには相手側に対して得点を決めるべきであり、自分側ではない」

証拠としては、この動画を見るといい

これは、ゴールデンゴールルールのない、つまり打ち切りのない延長戦ルール下でも起こりそうだ。

2012-05-14

PyPyによるxmlパーサーのパフォーマンス向上

Stefans Welt » Blog Archive » XML parser performance in CPython 3.3 and PyPy 1.7

なかなか悪くないな。しかし、やはり本格的なものが欲しければ、Cなどの別言語での実装のバインディングを使うことになるだろうが。

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ゲームが開発されることがあれば、移植作業をすると発言している。

さて、どうなることやら。

そもそも、私は最近の、昔のゲームの続編という形で、全く違うジャンルのゲームを出すのが好きではないのだが。

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

ゴノレゴFlashの作者へのインタビュー

ASCII.jp:そんなことより聞いてくれ、&&1よ――「ゴノレゴ」が変えた10年

ゴノレゴの作者へのインタビューらしい。面白い。

今となっては昔の話だなぁ。

TIOBE indexをみて考えた

TIOBE Software: 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が先行してマージを実行している。

Features/UsrMove - FedoraProject

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を排除する動きをみせている

もちろん、物理的店舗に置く商品の選択は物理的店主が決めるように、デジタル店舗に置くソフトウェアの選択はデジタル店主が決定権を持つ。しかしそれは、誰でもデジタル出店ができるという世界で初めて公平になる。もし、公式のデジタル店舗が唯一のソフトウェア配布プラットフォームであれば、もはや自由はない。

ソフトウェア配信システムは悪ではない。実際、私だって、ソフトウェア配信プラットフォームの運営者は、提供するソフトウェアに品質やセキュリティを保証してほしいし、ソフトウェアはもちろんコード署名され、配信途中に第三者により書き換えられることがないように保証して欲しい。これを実現するためには、ソフトウェア配信システムは不公平な選択をし、ソフトウェアの実行には技術的制限をほどこさねばならない。これ自体は悪ではない。しかし、もし公式なソフトウェア配信システムが、唯一のソフトウェア配信プラットフォームであり、それ以外にソフトウェアを導入する方法がないとしたら、この実装は邪悪になる。

もし自由なソフトウェアのみで構成されたプラットフォームがあり、ソフトウェア配信プラットフォームのプロトコルも自由な規格であれば、誰でも技術的に同様のソフトウェア配信が可能になる。ソフトウェア配信プラットフォームの追加は、単にサーバーリストに追加する程度の手間で済む。もちろん、規格自体が気にいらなければ、別の規格を設計、実装することもできる。自由なソフトウェアでは、技術的な制限を取り除くことが容易だ。公式のソフトウェア配信プラットフォームが気にいらなければ、自分で別のプラットフォームを立ち上げることができる。この点で、自由なソフトウェアは重要である。

近い将来、ソフトウェアは自由なソフトウェアと不自由なソフトウェアに二分される。もちろん、自由なソフトウェアは実行に制限を設けないので、条件次第で、不自由なソフトウェアでも使われるだろう。また、不自由なソフトウェア陣営の利益になると判断した部分だけは、自由なソフトウェアへの貢献があるだろう。しかし、ユーザー側からみれば、基本的なソフトウェア環境であるプラットフォームの実装は、完全に自由なソフトウェアか、不自由で制限されたソフトウェアかのどちらかになるだろう。

世界は二分される。

Oracle対Googleに対するFSFの声明

FSF statement on jury's partial verdict in Oracle v Google — Free Software Foundation — working together for free software

内容、「特許の話だとばかり思ってたら、まさかAPIに著作権を主張する不思議な主張だとは思わなかった。」

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で終わるだろうか。

詳しい内容やビルド環境の構築、ビルド方法については、以下のホームページ等で熟知すべし。

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は分裂するのか

How were some language communities (eg, Ruby and Python) able to prevent fragmentation while others (eg, Lisp or ML) were not? - Programmers - Stack Exchange

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によって間接的な金銭的価値が創出されているのも、結局、課金アイテムに価値を認める人間が多数存在するからである。

課金アイテムをサービスと見たならば、価値が存在することも、納得できないことはない。自由ソフトウェアにも、価値はソフトウェアの配布や改変を制限することではなく、付随するサービスによって創出されるという思想がある。

無形のサービスに価値を見出す時代になるのだろうか。