2012-04-30

なぜLinuxはクソなのか、なぜLinuxはクソじゃないのか

Lunduke.com

なぜLinuxは(相変わらず)クソなのか

あまりにもUIをコロコロと変えすぎる。ドライバーのサポートがひどい。特にX.orgがバージョンアップするたびに、ドライバーが壊れる。X.orgのバージョンアップのたびに、ドライバーがオープンソースかどうかにかかわらず壊れる。X.orgまじでクソだ。大規模なソフトウェア、すなわち画像や音声や動画の編集ツールがない。パッケージ化の規格乱立しすぎ。

なぜ大規模なソフトウェアがないのかというと、金がないからだ。Linuxカーネルには、相当の金がかかっている。多くの企業が金を出してLinuxカーネルを開発させている。編集ツールには十分な金が出ていない。優れたソフトウェアには、金が必要である。どんな方法でもいいが、ソフトウェアの開発に金がでるようにしなければならない。どんな方法になるかは検討がつかないが、利用者が開発者に金を払う仕組みと文化が必要である。

先進的なUI、高いカスタマイズ性と選択性。ドライバーのサポートは優れている。メーカー製ノートPCにパッケージ版のWindowsをインストールしたことがあるだろうか? 適切なドライバーがなくてまともに動きゃしない。ノートPC限定のWindows用ドライバーを入手するのは相当に面倒だ。しかし、Linuxではドライバーは最初から用意されている。ソフトウェアがない? Wineを使え。いやまじで騙されたと思ってWine使えよ。Linuxユーザーは頭がいいので、自分でやらずとも、tarballで出せば各種環境にパッケージ化してくれる。

2012-04-29

GNU/Linuxにおけるプロセス

GNU/Linuxでは、スケジュールの単位はプロセスである。スレッドというのは、ちょっと特殊なプロセスにすぎない。

Windowsでは、スケジュールの単位はスレッドである。プロセスというのは、スレッドを束ねる要素でしかない。たしかに、プロセスには優先度を設定できる。ただしこれは、スレッドの優先度が、スレッドに設定されている優先度とスレッドが属するプロセスに設定されている優先度から計算されるだけである。プロセスは実行の単位ではない。

プロセスを作るためのLinux Kernel APIとして、fork(), clone(), vfork()がある。Linux kernelでは、それぞれsys_fork(), sys_clone(), sys_vfork()として提供されている。また、その下にdo_fork()があって、実際の処理はこの関数がやっていたりする。ただし直接使うことはない。というのも、これらの関数は、いくつかの引数を普通に関数の引数として受け取るのではなく、定められた方法でスタックにつまれていたり、指定したレジスタに格納されていたりと、アーキテクチャごとに微妙に異なる引数の渡し方を要求する。そのため、glibcでは、使いやすくラップしたfork(), clone(), vfork()を提供している。ただし、現在のglibcの実装では、すべてclone()を使った実装になっている。

clone()というのは非常に柔軟なAPIで、プロセスを様々な状態で作成することができる。ただし、通常はclone()を直接使うことはない。使うのはカーネル外のライブラリでラップしたfork()やpthread_create()などである。

さて、とりあえずWindowsでは体験出来なかった、高速なforkの実装で遊んでみた。なるほど、確かに動く。

GNU/Linuxでforkが高速に動くのは、Copy-on-writeを使っていて、メモリを共有しているからである。子プロセスでは、書き込みされたストレージだけ、差し替えられる。ちなみに、Windowsではネイティブでforkを提供していないので、だいぶリベラルなことをしなければならない。cygwinの実装では、別プロセスをたちあげてロードされているモジュールをすべて読み込み、ハンドルを複製し、子プロセスのメモリを親プロセスから書き換えなどなど、相当な努力をしている。

しかし、LinuxベースのOSでPOSIXを実装するというのは、Linuxカーネルだけではなく、libcによるところも大きい。libcの最も有名な実装はglibcや、その派生物である。GNU/Linux、もしくはGNU+Linuxという言い方は、間違っていないというわけだ。

2012-04-27

Ubuntu 12.04の感想

Ubuntu 12.04がリリースされたので、11.10からアップグレードした。

アップグレードには、インストールしているソフトウェアすべてが更新されるので、所要時間は環境によって異なるのであろうが、私の場合、ダウンロードの時間を除けば、二時間半かかった。あらかじめダウンロード元をftp.jaist.ac.jpに設定しておいたが、ダウンロード速度は16Mbpsぐらいでていた。まあ、悪くない速度だ。

ひとつ感心したのは、インストールにかかる推定時間が、かなり正確だったという事だ。少なくとも、悪名高いWindowsのファイルコピーダイアログとは大違いだ。

xkcd: Estimation

「いまちょうど町外れにいるから、15分ぐらいで着くと思うよ」
「いや、やっぱり6日ぐらいかかるかな」
「いや違う。後30秒だな」

Windowsのファイルコピーダイアログの作者、友人宅を訪問すること

さて、いくつか気がついたことを挙げる。

日本語フォントのfontconfigの設定が修正されていて、日本語フォントが正しく選ばれるようになっている。

Unityのランチャーの挙動がだいぶ変わっている。以前は常に表示されていて、ウインドウが重なった時に自動で隠れ、マウスポインターを合わせると表示されるという挙動だった。12.04では、常に表示するか、常に自動で隠すかの選択性となっている。ただ、どうもAuto-hideにした場合の、マウスポインターの反応が非常ににぶく設定されている。sensitivityを最大にしても、マウスポインターの移動量が相当でないと出現しないようだ。これは、キーボードショートカットで出現させた方がマシなレベルになっている。たしかに、以前はあまりにも敏感にマウスポインターに反応しすぎていたので、時々邪魔に感じることもあったが、この挙動もどうかと思う。どうも挙動が両極端だ。

また、ランチャーにあるファイルマネージャーのNautilusのクイックリストに、新しいウインドウで開く項目が追加されている。ランチャーのソフトウェアがすでに実行されている場合、ランチャーのアイコンをクリックすると、既存のウインドウを表示するので、複数のworkspaceを使っていると、結構面倒だったのだ。これは当然の変更だろう。

また、12.04からは、ffmpegのサポートが打ち切られ、libavに切り替わっている。ffmpegのパッケージが空っぽになり、libavに依存するようになったので、ffmpegをインストールしているユーザーは、12.04のアップデートで、libavが入っているはずだ。

また、12.04では、ウインドウをドラッグしたときの明らかなラグがなくなっている。これは12.04で修正されると知っていたのだが、実際確認してみるまでは安心出来なかったのだ。

ちなみに、すでにカーネルイメージのアップデートが来ているので、12.04のインストール後はアップデートのために、もう一度最起動しなければならない。

GNU/Linuxの普及を妨げる最大の理由は、多くのディストロが、かなり変化に積極的なところだろうか。半年ごとに操作性がコロコロ変わっていては、やはり一般受けはしないのかもしれない。信じられないことに、未だにWindows XPのUIが一番いいと考える人間もいるのだ。

かっこ良すぎるバイク

このバイクはかっこ良すぎるにもほどがある。

2012-04-26

Google DriveのGNU/Linux版の予定はあるらしい

Google Drive for Linux Is on the Way | PCWorld Business Center

しかしまあ、Ubuntuユーザーとしては、Ubuntu Oneの方が使いやすいかな。

ビルドシステムについて深入りするのはやめた

GNU/Linuxに移行して未だによくわかっていないのが、ビルドシステムだ。特に、CやC++でそれなりのソフトウェアを書くとなると、やはりビルドシステムが必要だ。

現時点では、makeしかしらない。とりあえずmakefileを手書きしている。しかしどうやら、公開されている主要なソフトウェアは、単にmakeを使っているわけではない。大抵、makeファイルを生成するメタビルドシステムを使っている。

もちろん、makeを使わないビルドシステムもある。

単にコンパイルする以上に、インストールされているライブラリを調べたりと、色々と機能があるようだ。

色々と調べた挙句、結局、今は、特にビルドシステムについて深入りする必要はないと考えた。あまりにもビルドシステムの種類が多すぎる。特に必要のない限り、なにか一つのビルドシステムを深く学ぶ必要はないだろう。

結局、こういうことを考えなくてもいいスクリプト言語は楽だ。

2012-04-25

ValveのGNU/Linuxサポートが垣間見えてきた

ValveがGNU/Linuxをネイティブにサポートするという噂は聞こえていたが、なかなか音沙汰はなかった。この度、Phoronixの中の人がValveの中の人と会って、開発中の実物を見てきたらしい。

[Phoronix] Valve's Gabe Newell Talks Linux Steam Client, Source Engine

SourceエンジンをGNU/Linuxに移植して、Left 4 Dead 2をネイティブに動作させているところを見学できたらしい。

話によると、ValveのGNU/Linuxサポートは真面目に開発中で、しかも、そう遠くない時期にリリースされるのだという。L4D2を選んだ理由は、コードベースが安定していて、最初の移植を試す土台として使いやすかったからだそうだ。

Valveは今後、他のSourceエンジンを使う他社のゲームや、その他のゲームについても、GNU/Linuxをサポートするよう働きかけていくそうだ。

さらに話では、ValveのGabe Newellは、元MS社員とは思えないくらい、Windows 8を嫌っていて、Microsoftには将来性がないと考えているらしい。興味深い話だ。

GNU/Linuxがゲームプラットフォームとして一級市民になる日はくるだろうか。

bsnesがGBAエミュレーションを実装した

byuu's message board - View topic - bsnes v088 released

前回、最後に残っていたST018の実装を終えて、bsnesがすべての商用ソフトをサポートしたサイクル一致の精度のスーパーファミコン及びsnesエミュレーターになったことを書いた。ところで、ST018の実装で必要になったARMv3のエミュレーションの副産物として、GBAエミュレーションができたらしい。もっとも、GBAはARMv4を使っているので、簡単に対応というわけには行かなかったらしいが。

bsnesということで気になるのは高い精度だが、

On a side note, thanks to Cydrak and krom's hardware testing, we do have a nice milestone right out of the gate: proper OBJ mosaic emulation, which seems to be a first. At the very least, hopefully this will be helpful to other emulators.

の下りが気になるところだ。

また、あくまで精度の高いハードウェアのエミュレーションが目的なので、BIOSの高レベルエミュレーションは含まれていないそうだ。

その他に興味深いコメントとしては、

I just ... cannot debug ARM code. Too many registers, too much stack shuffling. I can't keep track of what's going on.

作者のbyuuという人間は理解できない。彼はすべての商用スーパーファミコン及びsnes用のカートリッジと箱と説明書を収集し、電子媒体に複製して保存する作業を行っている。ソフトウェアを正しく保存するには、当時と同じ環境で実行できなければならない。bsnesの開発動機の一端だ。

ただ、その動機がST018のエミュレーションまで進むのは理解が及ばない。ST018チップを利用しているのは、歴史上ただひとつの将棋ソフト、1995年に発売された早指し二段 森田将棋2だけである。しかも、現時点でまともにROMイメージを吸い出せる人間は限られている。たとえ非合法な方法で手に入れたとしても、やはり需要はないだろう。いまどきスーパーファミコンで動く将棋ソフトウェアなど、誰がやりたいと思うのか。あえて考えれば、コンピューター将棋の歴史書を編纂する歴史家が、すべての将棋ソフトウェアを網羅したいと考えたとき、必要になるだけだ。ソフトウェアの史書を書くならば、ソフトウェアを実際に実行して検証することは重要である。スーパーファミコンは有名なプラットフォームであり、当然歴史書に記す価値がある。

ところで、1995年に発売されたということは、もし、このゲームが映画だと判定されなければ、2046年に著作権の保護が切れる。映画だと判定された場合は、もう20年のびて、2066年である。ただおそらく、この将棋ソフトは動きがなさそうなので、映画とはみなされないのではないか。と、こう考えてみれば、何もそう遠い未来の話ではない。

bsnesは一体どこまでいくのやら。

参考:本の虫: bsnesがついに完成したそうだ

GSoC 2012の興味深いプロジェクト

現時点における、GSoC 2012で受け付けられた興味深いプロジェクトをいくつか紹介する。

Adding Static Profiling Capabilities to LLVM

LLVMに、プロファイルによるガイド付き最適化を実装するプロジェクト。他の競合する多くのCやC++コンパイラーが実装している機能だ。

Auto-vectorization for LLVM

LLVMに、自動的な並列化変換を実装するプロジェクト。私は未だに、どのコンパイラーにおいても、自動的な並列化が実用的になったという話を聞かないが、まあ、興味深い機能ではある。

Provide an alternative to libstdc++ with libc++

LLVMプロジェクトのC++の標準ライブラリの実装、libc++をDebianに移植してパッケージ化し、GNUによる実装であるlibstdc++と切り替えて使えるようにするためのプロジェクト。

これは非常に興味深い。現在、libc++はGNU/Linuxベースのシステムでも動くが、正しく使用するためのドキュメントが不足しているし、ディストロによるパッケージ化も存在しないので使いづらい。

Virtual Tables and RTTI in the Microsoft Visual C++ ABI

MSVCのC++ ABIのうち、Virtual tableとRTTIをClangでも使えるようにするプロジェクト。ClangをWindows環境で使うためには、MSVCとのABI互換性は重要である。

Implement missing functions in D3DX9

WineのD3DX9の実装のうち、よく使われているがいまだに欠けている機能を実装するプロジェクト。WineでDirectX 9を使うプログラムとの互換性が向上する。

GSoC project: Improve CJK font support

Wineにおける、CJKフォントのサポートを向上させるプロジェクト。

他には、ffmpeg向けに受け付けられたプロジェクトはないが、libav向けに受け付けられたプロジェクトなら存在するということか。

2012-04-24

GNU/Linux関連のニュース

Mark Shuttleworth » Blog Archive » Quality has a new name

Ubuntu 12.10のコードネームは、Quantal Quetzalになった。詳しい由来はリンク先を参照してもらうとして、Quantalはまたどうもいまいち日本語訳が思いつかない形容詞だ。Quetzal(ケツァール)は鳥の名前らしい。

[Phoronix] Ubuntu 12.10 Release Schedule Published

Ubuntu 12.10のリリース予定日は、10月18日。

[Phoronix] GPU Lockup Recovery For The Nouveau Driver

nVidiaのGPU用のオープンソースなドライバーNouveauで、GPUのロックアップを判定して復帰するパッチが公開された。

[Phoronix] Intel Core i7 3770K Ivy Bridge Linux Performance Review

Ivy Bridgeのベンチマーク。

Javaの権利にまつわるまとめがすごい

The Java IP Story | Software Research and the Industry

これはよくまとめてある。

これを読むと、GPLv3の重要性が分かるだろう。

旧Sunは、Javaの実装をGPLv2として公開した。GPLv2は、現在持ち上がっている問題に対処できない古いライセンスである。問題は特許だ。

Sunは、OpenJDKへの貢献は、著作権をSun側に引き渡すことという条件を課した。これにより、SunはGPLv2としてソフトウェアを公開しつつも、すべての著作権は保持しているため、プロプライエタリなライセンスでも提供できるというわけだ。

さらに、SunはJavaという商標も持っている。この商標を使うには、金を払ってJavaが規格準拠しているかどうか確かめる公式のテストをパスする必要がある。

金を払わないオープンソースなプロジェクトに対して、SunはJavaの商標を使うため、環境制限を課している。その実装を一部の環境で使わないという制限だ。一部の環境とは、組み込みとエンタープライズ分野だ。ほとんどのオープンソースライセンスに共通する理念に、ユーザーはソフトウェアをいかなる方法においても使用できる自由を有するというものがある。ソフトウェアの使用方法に制限をつけるのは、オープンソースではない。このため、オープンソース陣営は、この環境制限を受け入れられるはずがない。

しかし、これは商標の問題だ。GPLv2で公開されているのだから、別の名前さえ使えば回避できるのではないか。ここに、GPLv2の欠陥がかかわってくる。特許だ。

Sunとその関連企業はJavaの実装に関する特許を多数保有している。この特許の利用許諾を得るには、Javaという名称を使い、さらに規格準拠度を調べるテストにパスしなければならない。だから、ソフトウェアのライセンス自体はGPLv2なのでいくらでもforkできるが、特許の利用許諾は得られていない。特許侵害となってしまうのだ。

つまりまとめると、Sunが所有している知的財産権とは、

  • Javaという商標。
  • Javaの規格準拠度を調べるためのテスト群
  • Java実装のための特許

オープンソースを取り巻く環境としては、

Sunは邪悪な意図を持ってGPLv2を選択したのだ。GPLv2は特許をカバーしていないので、商標と特許と著作権を組み合わせることで、GPLv2ライセンスの元で公開されているソフトウェアであっても、自由を保証できなくしているのだ。

商標Javaを使うためには、環境制限を受け入れる必要がある。この環境制限はGPLv2に反するので、受け入れた時点でGPLv2違反、すなわち著作権侵害である。受け入れずにJavaの名を冠すれば商標権侵害である。

商標Javaを使わない場合、特許の利用許諾が得られない。特許侵害となる。

これが、GPLv2の問題だ。我々は一刻も早く、特許からの自由を保証するGPLv3に移行すべきである。

というわけで、Ubuntu 12.04への移行をきっかけに、OpenJDKもアンインストールしてみようかと思う。ちなみに、OpenJDKとそれに依存するソフトウェアを完全にアンインストールする方法は、

apt-get purge openjdk-\* icedtea-\* icedtea6-\*

まだ実際にpurgeを実行してはいないが、ためしにこのコマンドを実行して、取り除かれるパッケージを確認してみたところ、Ubuntu 11.10には、openjdkに依存するソフトウェアというのは入っていないようだ。LibreOfficeも、もはやJavaには依存していない。

ちなみに、Monoを取り除く方法は、

sudo apt-get purge cli-common mono-runtime

monoの場合、Ubuntu 11.10のデフォルトインストールでは、Banshee、GBrainy、Tomboyなどが依存するので、まとめて取り除かれる。

2012-04-23

幕末に活躍した人物の末裔のまとめがすごい

【写真あり】幕末の偉人たちの子孫が意外過ぎる人生を送っている | 幕末ガイド

これはすごい。よく調べたものだ。

ひとつ前から気になっていることとして、日本人の何割ぐらいが、歴代天皇の子孫なのだろうかという疑問がある。思うに、割合は「割」という単位で表せるほどであると思う。確実に存在したと言える天皇は千五百年ほどさかのぼることができる。だから、日本人は結構な割合で、天皇の子孫であると思うのだ。

さて、私のルーツはというと、まあ、そんなに歴史上名のある人物ではないはずだ。父方の祖父母は、佐渡ヶ島の人らしい。佐渡というのはなかなか興味深い場所だ。あそこは流刑地だったのだ。流刑地といっても、江戸あたりで特に仕事もなくぶらぶらしている人間を、奴隷のような強制労働要因として送り込んでいたのだが。祖母は佐渡で電話交換手をしていたらしい。祖父は戦後仕事がなくて、自衛隊に入っていたそうだ。祖父は非常に器用で多趣味な人間だった。

母方の祖父母は、京都の人だ。詳しく覚えていないのだが、たしか、祖父は桐の箱とかカンナの刃とかを作っていたらしい。祖母は知らない。間違っているかもしれないので、あとで確認する必要がある。

ともかく知る限り、私のルーツは、由緒正しき名のある人物というわけでもなさそうだ。

PythonとJulia

Julia, Python and Cython - julia-dev | Google Groups

Cythonの開発者が、JuliaのMLに登場して議論している。

Cythonとは、PythonコードからCやC++への変換をするソフトウェアである。このため、独自の拡張により、PythonからCやC++のコードを簡単に呼び出せるようにもなっている。

なぜCythonを使うのかというと、速度である。Pythonのリファレンス実装、CPythonはバイトコンパイルによるインタプリターであり、JITはない。そのため、科学技術計算のためには、非常に遅い。Cythonは、科学技術計算をする研究者に人気がある。

The Julia Languageは、高速に動作することを目的とした動的プログラミング言語である。LLVMによるJITコンパイルにより、高速に動作する。また、数値演算ライブラリとして、BLASの代わりに、Intelのプロプライエタリなライブラリを用いることもできる。これにより、GCCと比べても、最低で数倍程度しか遅くならない、非常に高速な動的プログラミング言語を実現している。

さて、Cythonの開発者は、まず、Juliaが非常に高速で、科学技術計算の用途に耐えることを褒めたたえている。その上で、Juliaの現在の問題点を上げている。ユーザーとライブラリの欠如である。

Pythonで科学技術計算をすると言っても、すべてをPythonで行うわけではない。特にクリティカルな処理は、CやC++を使って書き、Pythonから呼び出す形を取る。また、Pythonにはすでに、豊富なライブラリがある。また、Python上級者のユーザーも多数いる。現時点でのJuliaには欠けている点である。

これを解決するために、JuliaとPythonを相互に呼び出せるようにしてはどうかと提案している。

なかなか興味深い話だ。動的な言語は、プロトタイプ的な実装が非常に簡単だという利点がある。科学技術計算というのは門外漢で全く分からないが、結局、すべてがクリティカルな処理ではなく、言語による分業があってもいいのだろう。

思うに、ハードウェアだけではなく、プログラミング言語も、どんどんHeterogeneousになっていくに違いない。すべての要求を満たす言語の設計は不可能だ。現在でも、並列演算に特化したGPUなどのハードウェア用には専用言語があるものだ。

2012-04-21

プリンスオブペルシャのソースコードを救ったギーク達

The Geeks Who Saved Prince of Persia's Source Code From Digital Death | Game|Life | Wired.com

プリンスオブペルシャのオリジナルのソースコードが発掘され、GitHubで公開されたことは記憶に新しい。しかし、その裏話はしっているだろうか。昔の電磁的記録のサルベージがいかに難しい作業であるか、認識しているだろうか。wired.comですばらしい記事がでたので、翻訳する。

WiredのGus Mastrapaはロサンゼルスで、ゲーム史に残る重要な財産を発掘する作業に立ち会った。

Jordan Mechnerは何でも保存してきた。

彼は、兄弟が近所で飛び跳ねる様を撮影した1985年に撮影したビデオテープを保存している。この動画から、彼はApple IIのPrince of Persiaのアニメーションを作成したのだ。彼はプリンスオブペルシャの制作日誌を保存している。プリンスオブペルシャ制作の上でのあらゆる出来事が記された貴重な資料だ。

2002年に、Prince of Persia: The Sands of Timeの仕事をしていたとき、この新作ゲームのプログラマーは、プレステ2用の移植に、イースターエッグとして、オリジナルのゲームを付け加えたいと考えた。そこで、Mechnerに、まだソースコードを持っているかどうかたずねた。

「ノープロブレム」とMechnerは考えた。「私はなんだって保存しているんだ」と。

Apple IIの完成されたゲームは、インターネット上で容易に手に入る。しかしソースコードは、Mechnerが自ら、自分の使っていたApple IIのために書き上げたオリジナルのプログラムは、どこにも見当たらなかった。Mechnerはできる限り探し、ソースコードを持っていそうな人物に知る限りたずねたが、ついに発見できなかった。

十年後、Mechnerの父親は、押入れの奥に埋もれていた昔の私物が入っている箱を送ってきた。そこには、まだ未開封のヨーロッパ版プリンスオブペルシャの間に挟まって、ホコリまみれになっているフロッピーディスクがあった。ラベルには、「プリンスオブペルシャ ソースコード (Apple) ©1989 Jordan Mechner (オリジナル)」と書かれていた。

ディスクは見つかった。しかし、データはどうするのか。

こういうとき、Xファイルのエージェント、Fox Mulderが技術的な問題を抱えていたならば、ツテのギーク達、すなわちThe Lone Gunmenを呼ぶものだ。Mechnerも、ツテのギーグ部隊に連絡した。4月のある月曜日の朝、彼らをロサンゼルスの自宅に呼びつけた。

Jordan Mechnerの邸宅は、ロサンゼルス通りのハリウッドヒルの下にある。この場所にしては非常によく手入れの行き届いている邸宅である。

白い小型トラックが停車し、ビンテージコンピューターコレクターのTony Diazがやってきた。彼はオーシャンサイドから、はるばる80マイルも車を走らせて、Mechnerの失われた文化財産を発掘するためにやってきたのだ。彼はトラックから何箱もの機材を積み下ろした。大昔のApple IIコンピューター、ドライブ、ケーブルの類である。彼は今日この日のために必要となるかもしれない機材をすべて持ってやってきたのである。もし、そのディスクに情報が含まれているならば、吸い出すのだ。

機材のいくつかは、錆び付いていたり塗がはげていたりしていた。しかし、Diazには本物のスキルがある。この男は、小一時間でApple IIのフロッピーディスクドライブを分解、再結合できる男である。機材はいくつかは、みすぼらしい見た目をしている。しかしこの男の本物のスキルによって、この長年、動作する状態に保たれてきたのだ。

The Internet Archiveの活動家、Jason Scottも、この日のために、はるばるニューヨーク市からKryoFluxディスクリーダーを携えて飛んできた。これはソフトウェア保存家御用達の、大昔の磁気記録データを読み込むための機材である。

昔のゲームデザイナーは、自分が文化財産の上に座っているとは思いもしないものだ。Scottの目的は、かつての先進的な著作物を、消失から救うことである。

「彼らにしてみれば、単なる古物に過ぎない」とScottは言う。「その価値に気づかせてやるのだ」。スタンフォード大学や、アメリカ議会図書館、The Strong National Museum of Playのような団体には、ソフトウェアを保存するための部門がある。Scottが今日、ここにやってきたのは、昔のゲームや製品を、ホコリまみれの電子墓場から救うための長年の活動の一環である。

MechnerとScottとDiazは、トラックからMechnerの家に機材を運び込んだ。裏庭には、こじんまりとした来客用の小屋がある。ハリウッドライターなら誰でもそうするように(Mechnerはゲームのみならず、グラフィックノベルや台本の仕事にも関わっている)、彼はゲストハウスを自宅の事務所に改装しているのだ。小屋の中には、来客用の皮のソファーがあり、書架には台本や獲得した賞が山積みになっている。

Mechnerの作業場は、その一角にある。整理されたデスクに、アップルのモニターが鎮座している。近くの壁に、誰かが標語を貼りつけたらしい。「コンピューターの前に座り、次に何をすべきか考えることなかれ」と。

Diazは木製のテーブルの上に機材を設置しはじめた。彼はベージュ色のApple IIコンピューターのプラスチックのケースや、ディスクドライブやモニターを接続した。その大昔の機器が組み立てられていく様は壮観であった。

ギーク達の目的は、単にこのMechnerの昔のディスクが動作するかどうかを確かめるだけではない。今日はまさに、昔のコードを電子墓場から発掘して、インターネット上に公開せんとする日なのだ。だからこそ、彼らは単にApple IIコンピューターのみならず、Diazの機材が必要なのだ。DiazはコンピューターをEthernetケーブルと接続した。DiazはモダンなDellのノートPCを使って、今日発掘されるであろう文化財産を吸い出すつもりなのだ。

まず最大の目的であるプリンスオブペルシャのソースコードディスクに挑戦する前に、すこし軽いものから始めることにした。箱の中には、Mechnerが、試したいフロッピーディスクは山とあったのだ。ディスクのラベルによれば、この何十年、日の目を見てこなかった、初期のMechnerの作品が入っているはずだからだ。

まずDiazは機材が正しく動作するかどうか確かめるために、それほど重要ではないディスクから始めた。彼はLocksmith 6.0というツールを実行した。この大昔のツールは、コピープロテクトされたディスクを複製するためのツールである。最初に試した数枚のフロッピーは、完全な状態でなかった。スキャン結果はモニター上にASCII文字列で表示されていった。ドットは正しくスキャンされたセクター、数字は読み込むのに時間のかかったセクター、Dは時間をかけても読み込めないデータである。Dがいくつかあった。結果はあまり喜ばしくない。

Mechnerはディスクを段ボール箱から取り出し始めた。段ボール箱はフロッピーの重さを支えるため、透明な荷造り用のテープで補強されていた。積み重なったディスクは箱を半インチほど歪めていた。「最初発見したとき、ディスクにはホコリが積もっていたんだ」とMechnerは言った。

Diazはホコリについては心配していなかった。「おれはエラーだらけのディスクを取り扱ったこともある」と彼は言った。「コケが生えていたり汚れていたりするんでね」と。彼はフロッピーディスクを洗浄する方法について語り始めた。なんと、ケースから取り出して流しに持って行き、食器用洗剤で洗うのだという。この作業はソフトウェア保存家のJason Scottを震え上がらせた。「好きにすればいいさ」と彼は言った。幸運にも、そのような極端な作業は必要なかった。

MechnerのApple DOS 3.3は正しく複製できた。「今まで読み込まれたものがないものに取り掛かろう」とMechnerは 言った。「Quadris」からやろう。

このゲームの名前は、ある有名な古典的ゲームの別宇宙版のようである。実際の所、ほぼ同じである。Mechnerが最初のゲームであるカラテカを作ってイェール大学を卒業してから彼はBroderbundというゲームパブリッシャーで働いた。会社に入って数ヶ月して、製品候補が届いた。そのゲームは、テトリスという名前であった。

「当時、社内でこのディスクが大はやりしてね」とMechnerは言った。「プログラマーは全員、このゲームにハマッてしまったのだよ。仕事を放り出してテトリスのハイスコア合戦をやったもんさ」

それにも関わらず、Broderbundはテトリスを却下した。「まあ」と上司は考えた、「うちんとこのオタクなプログラマーはこのゲームにハマっているが、しかし一般大衆にはウケんだろう」と。

「ディスクは送り返し、テトリスのコピーは全部破棄しなきゃならなかったんだ」とMechnerは言った。「持ち続けているのはよくないことだったんだけどね」と。しかし、会社の社員は全員、テトリスにはまってしまったので、プログラマーのRoland Gustafssonは、一日かけてゲームをリバースエンジニアリングし、非正規のクローンをQuadrisと名付けたのだ。

Apple IIのディスクドライブが動き始めた。ソフトウェアはDiazのドライブにコピーされた。「動かしてみたい?」と彼はたずねた。皆、首を縦に振った。

Mechnerはキーボードに向かい、初心者レベルを選んで開始した。ブロックが画面を落ち始めた。しかし彼は、どのキーで回転、降下させるのか覚えていなかった。mechnerは一つづつキーを押して、辛抱強くキーを探し始めた。彼があるキーを叩いたとき、テトリスが画面から消え失せて、退屈そうなユーティリティ画面が現れた。

何が起こったのか最初に把握したのは、Diazであった。「ボスキーだな」と彼は言った。「遊んでないで仕事をしているように見せかけるのさ」と。Gustafsonは、他の多くのコンピューターゲームプログラマーと同じように、Quadrisで遊んでいる最中に上司がやってきたときのため、仕事をしているようにみせかけるパニックボタンを実装していたのだ。

「傑作だ」とMechnerは言った。

Quadrisのデータを確保できたTony Diazは、ディスクをJason Scottに渡した。単に昔の失われたゲームをプレイできたというだけで満足する者もいるだろう。しかし、Scottは将来の世代のことを考えているのだ。完全なる磁気読み取りによって初めて、すべてが正しく読み込まれて保存されたことを確証できるのだ。

「インディアナジョーンズみたいなものさ」とMechnerは言った。「墓に入って、彫像をつかんで、逃げ出すのさ。黄金の彫像を手に入れたんだ」

MechnerはさらにDiazにディスクを渡し、黄金の彫像は発掘され続けた。この当時のコンピューター少年なら誰でもするように、Mechnerは古いフロッピーに、新しいデータを書きこんでいた。「どれかに、Time ZoneというRoberta Williamのアドベンチャーゲームが入っていたんだ」とmechener。「今では、自分の初期の作品が入っているわけだ」

「これは貴重だぞ」と彼は言った。「これは別のゲームで、プリンスオブペルシャと共に、とっくの昔に失われたと思っていたゲームだ」と。ソースコードのみならず、完全なゲームが入っていた。「私はこのゲームのプログラミングに一年かけたんだ」と彼は言った。「しかし、存在していたという証拠はなかった」

Diazはディスクをタイムマシンに差し込んだ。そしてMechnerに、どのような名前をつけるべきかたずねた。

「アステロイド」と彼は答えた。

若いプログラマーとして、Jordan Mechnerは、何か商業的価値のあるものをつくろうとしていた。彼はApple IIでよく売れたゲームをみて、アーケードゲームのスペースインベーダーのクローンは、よくできていると考えた。そこで、彼はAtariのアステロイドを試みた。しかし、彼のクローンが完成する前に、ゲームパブリッシャーはパクリを糾弾するようになったので、開発は止まってしまった。

アステロイドの復旧はQuadrisのようにスムーズにはいかなかった。Diazがゲームをロードしてみると、Mechnerはグラフィックが正しく描画されていないことに気がついた。小惑星はバグっているような挙動を示した。オリジナルのコードのエラーなのだろうか。Mechenerの大学のApple IIとDiazの機材は別の設定を使っているのか。ディスクはデータを正しく保存できていないのか。Mechnerのアステロイドは救われたが、修復作業が必要だ。

最後に、最大の黄金の彫像を発掘する時がきた。「プリンスオブペルシャ ソースコード (Apple) ©1989 Jordan Mechner (オリジナル)」とラベル書きされた昔のディスクだ。Diazはディスクを差し込んだ。「きっとうまくいくさ」とMechnerは言った。

Diazのコンピューターが嬉しい結果を出した。エラーなし。「コピーができたぞ」と彼は言った。「さて、ディスクの中に何が入っているかみてみるか」

巨大なカレッジリングをつけたDiazの指が、昔のApple IIのベージュ色のキーの上で踊った。ディスク上のディレクトリを読み進めていき、"Source Images and levels"を見つけた。

「よし」とMechenerは、ファイル名やタイムスタンプを見ながら言った。「これだ。これは正しい。これこそがファイルの名前だ」

「探しているものは、99パーセント、これだ」と彼は言った。「もしこれが読み込めなかったとしたら、もうおしまいだった。永久に失われるところだったのだ」

ソースコードは救われた。さてどうする。Mechnerはどうすべきかを知っている。世界に公開するのだ

「これで、プリンスオブペルシャのソースコードに興味があるものは、誰でも読むことができるのだ」と彼は言った。「検証し、改造できる」

「公開はいつからにしますか」とJason Scottが言った。

「今夜だ」と躊躇なくMechnerは言った。

しかし、まだ一日は終わっていない。コピーし、スキャンすべき財宝、昔のディスクはまだまだたくさんある。Mechnerのボランティアチームのエキスパート達はこの機会を有効に活用する予定である。まだ仕事はたくさんのこっている。Mechnerの妻子は、母屋で彼を待っていた。書かれるべき台本もある。新しいゲームも作らなければならない。しかし今、Mechnerはそんなことに関わるべき意欲を見いだせない。

「これ以上に楽しいことは何もない」と彼は、別の昔の箱を開けながら言った。

これが、ソフトウェアの発掘作業である。ソフトウェアを保存するのはなぜ難しいのか。それは、磁気を利用した記録装置の寿命は、どんなに理想の状態でも、せいぜい数十年だからだ。数十年前の記録装置を読み込むには、とんでもなく面倒な作業が必要になる。

そして、記録媒体が情報を保持できる期間は、新しい記録媒体ほど短くなっている。今のHDDは、動作に高度な精度を要求するので、可動部がすこしズレただけで動作しなくなる。HDDを分解して修理できる技術者はそういない。HDDはまだましな方だ。単に分解してディスクの磁気情報を高い精度で読みこめば復元できる望みもある。フラッシュメモリはさらに難しい。フラッシュメモリの保持期間は、FDやHDDより短い。フラッシュメモリは、単にディスクの磁気情報を読み込むというわけにも行かない。

ソフトウェアは保存されるべき重要な文化財産である。ソフトウェアは将来の世代のために、完璧な状態で保存し、歴史家の研究資料となるべきである。現代の著作権法とDRMは、ソフトウェア保存の大いなる脅威である。もし、これを読んでなお、DRMは必要だと考えるだろうか。電磁的記録を固定する媒体の寿命は、せいぜい数十年。データを保存するためには、常に新しい媒体に複製していかなければならないのだ。だから、ひとつの媒体に固定されて複製できないデータは、著作権による保護期間が切れるはるか前に、読み出せなくなってしまう。

事実、多くのソフトウェアはすでに失われている。皮肉なことに、現代において、ソフトウェアの保存活動をしているのは、海賊である。

本の虫: なぜ歴史には海賊が必要なのか

2012-04-20

GNU Globalが面白そうだ

GNU GLOBAL source code tagging system
ソースコードを快適に読むための GNU GLOBAL 入門 (前編) - まちゅダイアリー(2009-03-07)
ソースコードを快適に読むための GNU GLOBAL 入門 (中編) - まちゅダイアリー(2009-03-08)
ソースコードを快適に読むための GNU GLOBAL 入門 (後編) - まちゅダイアリー(2009-03-09)
L'eclat des jours(2009-03-08)

これは面白そうだ。GNU/Linuxに移って不足していると感じていたのは、C++のコーディング支援機能だ。単純な名前補完をはじめとして、エディターで閲覧しているソースコード中の名前から、そのまま宣言や定義箇所に飛ぶような機能がほしかった。Visual Studioではおなじみの機能だ。C++でこのようなツールを提供するのは、残念ながらだいぶ難しい。

GNU Globalは、静的ではあるが、ソースコードを解析してくれる。すばらしい。

ちなみに、Linux Kernelにも適用できる。どのようになるかは、以下のサイトで確認できる。

The UNIX Kernel Source Tour!

これは予想以上にすごい。

というわけで、この記事を書いている途中で、さっそくインストールしようとしたところ、一瞬で終わった。ああ、aptはすばらしい。なぜ今までこんなに自由で便利なOSを使わず、不自由なWindowsを使っていたのか。10年前に不自由なWindowsを選択した自分を叱りつけたい気分だ。

sudo apt-get install global

Linux Kernelに言及したので、今読み進めているUnderstanding the LINUX KERNELの冒頭を読んだ感想を少し書く。

冒頭で説明されているOSの一般的な知識は、すでに知っていることが多く、とりあえずは分かる。ただ、signalとforkは、Windowsでは一般的ではない概念だ。Windowsでは、signalはほとんど使われない。Cの標準ライブラリにあるため、CRTで申し訳程度に実装してあるのみだ。Windowsでいえば、SEHが機能的に対応するだろうか。forkは、Win32サブシステムにはネイティブで存在しない。まあ、それほど難しい機能ではないのだが、このへんの違いは興味深い。

WindowsとLinuxにおける、プロセスとスレッドに関する考え方の違いは興味深い。Windowsでは、Linuxに先んじてスレッドが発達してきた。Windowsにおけるスケジュールの単位はスレッドである。ところが、Linux Kernelでは、2.6までネイティブなスレッド、つまりOSからスケジューリングされるスレッドというのは、実装されていなかった。Linuxでは、今も昔も、スケジュールの単位はプロセスであるそうだ。ネイティブなスレッドが実装された今も、Linux Kernelからは、メモリ空間を共有している特殊なプロセスとしてみているらしい。

代わりに、昔からforkが実装されていた。もっとも現代では、書き込みも含めたメモリ空間を共有した複数の実行単位としてのスレッドが重要になっているので、ネイティブなスレッドの実装は当然である。しかし、2.6までネイティブに実装されなかったというのは興味深い。

Native POSIX Thread Library - Wikipedia, the free encyclopedia

2012-04-19

Understanding the LINUX KERNELを入手

@akiradeveloperさんからUnderstanding the LINUX KERNELを頂いたので、早速読む。だいぶ長い本なので、一息にというわけにはいかない。しばらくかかるだろう。

将来カーネルハッカーに慣れるかどうかは分からないし、デバイスドライバーを書くようになるかも不明だが、Linuxカーネルの概要を学んでおくことは重要である。

この本の唯一の不満は、プロプライエタリなドキュメントだということだ。幸い、日本国では情報に著作権は与えられないので、学んだことをブログに書いていこうと思う。ただし、なにぶんLinuxベースのシステムの利用歴が浅いので、まだ色々と不慣れだ。第一、GNU/Linux特有のプログラミング作法も、まだよく理解していない。

まったく、私は色々と間違った選択をしてきた。最大の失敗は、10年ほど不自由なOSにこだわってきたことだ。この遅れを取り戻すのはなかなか難しい。何年かかるか分からないが、やるしかない。

やるべきことが多すぎる。C++の参考書の執筆、Pythonの習得、GNU/Linux環境でのプログラミング作法の習得、さらにLinuxカーネルの概要の理解だ。生活を維持できる安定した収入を得る方法も探さねばならない。

ところで、pythonはとても簡単な言語だということが分かり安堵している。公式のチュートリアルがわかりやすい。残念ながら、十分にフォーマルな言語仕様書はないが、読みやすい言語リファレンスはある。

今のGNU/Linuxシステムが非常に簡単に使えるのは救いだ。当初、プログラミングどころか、GNU/Linuxに慣れるために数ヶ月はかかるかもしれないと懸念していたが、初日から問題なく使うことができた。これはすばらしい。事実、もはやGNU/Linuxの利便性はWindowsを凌駕している。ほとんどのソフトウェア需要は、自由なソフトウェアで事足りる。事足りるどころか、不自由なソフトウェアより圧倒的に優れている。しかも、事実上無料で手に入れられる。自由なソフトウェアのドキュメントも、多くは自由なドキュメントである。そのため学ぶための障害は少ない。

しかし、まさかこんなにも急激に自由なソフトウェアの信奉者に転身するとは思ってもいなかった。あとは自由なソフトウェアのみを扱う職が見つかればいいのだが。

GNU/LinuxにおけるWeb上のゲーム

さて、前回書かなかったゲームのプラットフォームがひとつだけある。それは、Webだ。ただし、Web上のゲームは非常に混沌としているので注意が必要である。

今回、考察するのは、純粋にブラウザー単体で動くゲームのことだ。GNU/Linuxには規格準拠度の高い自由やオープンソースなソフトウェアのブラウザーがあるので、ブラウザーのプラットフォームは自由である。問題は、ゲームが自由なソフトウェアかどうかだ。自由なソフトウェアを使うことは非常に重要である。自由を何よりも重視する我々は、いかなる誘惑があろうとも、決して不自由なソフトウェアを使ってはならない。ここでは、Web上のゲームが自由なソフトウェアかどうかを確認する際に重要な項目を説明する。

ここでも問題にするのは、あくまでソフトウェアの自由である。リソース(画像、動画、音声、テキストなど)の自由は問題にしない。また、オープンソースライセンスも許容範囲とする。

まずブラウザーだ。ブラウザーが自由なソフトウェアか、最低でもオープンソースライセンスであることを確認すべきだ。もちろん、不自由なソフトウェアのブラウザープラグインを使っていないことを確認することも重要である。

HTMLには、video要素とaudio要素があり、動画や音声を生成できる。あらかじめ静的に生成された動画や音声は、ゲームでよく使われるリソースである。このとき、動画や音声のフォーマットが、自由かどうかを気にしなければならない。何故ならば、圧縮技術には多くの特許が取得されているからだ。純粋なアルゴリズムや数学が、ソフトウェアで実装しただけで特許を認められるというのは非常に不思議だが、世の中の法律がそうなっている以上、受け入れるしかない。

さて、著作権や特許は、実は、自由なライセンスの妨げにはならない。むしろ、自由なライセンスを助けるものである。何故ならば、これらは著作物やアイディアに独占的権利を認めるものである。自由なライセンスは、この独占的な権利を賢くハックすることにより成り立っている。

だから、動画や音声のフォーマットが自由なライセンスで提供されているかどうかを確認することは重要である。何故ならば、フォーマットのエンコーダー、デコーダーを自由なソフトウェアで作成するには、自由なフォーマットであることが重要だから。ここで問題にしているのは、あくまでフォーマットの自由であり、そのフォーマットで表現されたリソースの自由ではない。

HTMLには、canvas要素があり、スクリプト言語から操作することによって、2Dや3Dの描画ができる。このスクリプト言語には、事実上の業界標準として、JavaScript言語が用いられる。JavaScriptは本物のプログラミング言語である。ソフトウェアを実装するJavaScriptコードは、当然自由でなければならない。そこで、自由なソフトウェアに賛同する者は、JavaScriptのコードが自由なライセンスで提供されているかどうかを確かめなければならない。

まず、自由なソフトウェアの定義する「ソースコード」が提供されているかどうかを確かめるべきである。ソースコードは人間の読める形式でなければならない。一般的に、エンドユーザーの実行するJavaScriptコードは、コードサイズを削減するために、圧縮変換されている。これ自体は悪ではない。JavaScriptの圧縮には妥当な理由がある。しかし、自由なソフトウェアであるためには、圧縮前のソースコードが提供されていなければならない。

また、他の言語やツールからJavaScriptコードを生成することも一般的に行われている。例えば、CoffeeScriptやDartなどだ。この場合、ソースコードとは、プログラムであるJavaScriptを生成した元ソースコードである。もし、JavaScirptコードの生成に特別なビルドシステム(makeなど)が使われているならば、そのビルドシステムを動かすためのソースコード(makefileなど)も公開されていなければならない。

ただし、リソースを表現するためにJSONを使うことも一般的である。JSONはJavaScriptの文法から考案されたフォーマットであるが、プログラミング言語ではない。JSONがゲームに必要なリソースを記述するために使われている場合は、ソフトウェアの実行に必須ではない限り、ソースコードではない。

HTMLやCSSは、それ単体ではソフトウェアとはなりにくい。もちろん、HTMLやCSSを変態的に使えば、プログラミング的挙動をさせることも可能かもしれないが、基本的には、単なるマークアップ言語やスタイル指定のための言語である。ただし、もしJavaScriptのコードが、その実行のために特定の記述がされたHTMLやCSSを必要とするならば、それもソースコードに含まれる。ただし、リソースと混同してはならない。Webアプリのゲーム中で使われるリソースをHTMLでマークアップするのは自然であるし、スタイル指定をCSSで行うのも自然だ。

また、ChromiumにはNaCl(Native Client)という機能がある。これは、x86のネイティブコードを、x86環境のChromiumがサポートしているOS上で、最低限の安全を保証した上で、互換性を保って実行させる機構である。この機構を利用したゲームでは、ネイティブコードを生成するためのソースコードが自由なライセンスで提供されているかどうかを確かめなければならない。

その他にも、FlashやSilverlightやJavaアプレットなどといったブラウザのプラグインとして提供されているプラットフォーム上で動くゲームがある。これについて深く解説はしないが、ゲームが自由なソフトウェアであるかどうかの確認はもとより、そのプラットフォームの実装が自由なソフトウェアであるかどうかも気にしなければならない。

2012-04-18

pythonでも学ぼうかと思う

UbuntuのCLIのツールは便利だ。しかしふと気がつくと、多くのツールは実はスクリプト言語で書かれているのだ。これは、その作業はネイティブコードによる実行速度を必要としないからである。大半の処理は、テキスト処理やファイルのコピーや削除なので、ネイティブコードを使う意義は薄い。

多くのスクリプト言語は、わかりやすい文法を採用しているので、よほど言語独自の機能を変態的に使ったコードでもない限り、読む分には差し支えない。しかし、書くとなると、やはり知識が必要だ。いよいよなにかひとつ、スクリプト言語を学ばねばなるまい。

私は、詳細を学ばねば気が済まないたちである。とすれば、すべての言語を学ぶことはできない。ではどの言語を学ぶべきか。

perlは古臭くて文法も汚い。rubyは何でもできて、手早く仕事を終わらせるにはいいかもしれないが、言語としての面白さを感じない。schemeは文法がわかりにくい。とすると、pythonが最適なのではないかと思う。

それにpythonには、Boostにもバインディング用のライブラリがある。Boostにライブラリがあるからには、C++プログラマーとしても覚える価値があるに違いない。

せっかくだから、最新のPython 3.xを使いたい。Ubuntuでは、2.x系と3.x系は別のパッケージで提供されていて、混在できるようだ。思い立ったらすぐにインストールできる環境はすばらしい。

とりあえず、チュートリアルを読むことから始めている。

The Python Tutorial — Python v3.2.3 documentation

2012-04-17

GNU/Linuxにおけるゲーム

コンピューターにとって、ゲームは欠くべからざるものである。UNIXはゲームを動かすため作られたという有名な逸話もある。能書きはともかく、ゲームはコンピューターの操作方法を覚えるのに最適なソフトウェアである。多くのデスクトップ用OSが、必ずゲームのひとつやふたつを含めているのには、理由があるのだ。

さて、GNU/Linuxにおけるゲームの状況はどうかというと、あまり芳しくない。これは、GNU/Linux環境は多様なため、自由とかオープンなどという以前に、移植性を確保したいならば、コンパイルできるソースコードを提供しなければならないからだ。もちろん、すべてのソフトウェアは、本来自由であるべきだ。不自由なソフトウェアは人道上の罪である。しかし、頭の硬い典型的なゲーム業界には、なかなか理解されない。

そもそも、ひとくちに自由なゲームということはできない。例えば、自由なソフトウェアであるためには、ソフトウェアが自由であればいいのだ。リソースまで自由である必要はない。もちろん、そのリソースがなくても、ソースコードからプログラムの生成や実行を妨げないという条件は必要だが、リソースはソフトウェアではない。だから、ソフトウェアだけ自由で、リソースが自由ではないソフトウェアが存在する。完全に自由なOSに含まれるゲームは、当然、リソースまで含めて自由でなければならない。

ともかく、自由、不自由に関わらず、GNU/Linux環境におけるゲームの現状について、いくつか書こうと思う。

Ubuntuでは、デフォルトでいくつかのゲームがインストールされる。ソリティアやフリーセルやマインスイーパー、数独などといった、有名なゲームがある。また、Mahjonggというゲームがある。正式名称がよく分からないのだが、上海麻雀とか麻雀ソリティアなどと呼ばれているもので、重なりあった麻雀牌の同一牌を消していくゲームだ。また、ゲームに分類されるかどうかは曖昧だが、GBrainyというソフトウェアもある。これはC#で書かれているIQテスト的なパズルや単語の関連性や、ちょっとした数学などの問題集である。Ubuntu 12.04では、デフォルトでMonoがインストールされないために、GBrainyもデフォルトインストールから外された。

では、その他の自由なゲームはどうか。UbuntuのUniverse公式レポジトリには多数のゲームがある。ざっと見たところ、パズル、カードゲーム、ボードゲームなどが多いようだ。これらのゲームは、ロジックの占める割合が多く、純粋なプログラミングの勉強素材としても最適で、シナリオやマップ構築などの、コーディングとは関わりが薄いが労力のかかる作業が比較的少ないために、盛況なのだろう。

UNIX系OSといえば忘れてはならないのが、ローグ系のゲームである。自由なローグ系ゲームは多数ある。私も、かつてAngbandにハマっていたのだが、全然上達しなかった。ローグ系ゲームを一般に普及させたトルネコの大冒険はなかなかよくやったと思う。

スポーツ系オンラインFPSもいくつかある。

不自由なソフトウェアはどうか。

純粋なJVMやCLRの上で実行されるゲームは、GNU/Linuxでも動くものが多い。たとえば、かの中毒性のある不自由なMinecraftは、GNU/Linuxでも動くらしい。私はMinecraftの面白さが今ひとつ分からない。3Dモデリングがしたいならば、3Dモデリンツツールを使えばいいし、2D絵が書きたいならば、ドローイングソフトを使えばよい。プログラミングがしたいのならば、プログラミング言語を使えばよい。Minecraftでは、剣を使ってモンスターを攻撃できるので、その点は一応、ゲームと呼ぶことも可能ではあろうが・・・やはりよく分からない。もっとも、フライトシミュレーターやSimCityや牧場物語やTHE・コンビニのようなソフトウェアも、世間一般にはゲームと認識されているので、やはりゲームというのはかなり広い分野を指す言葉なのだろう。

ただし、自由なソフトウェアにこだわるならば、自由なJVMやCLRの実装を使うことが必須である。

Flash上で動くゲームも、GNU/Linux上で問題なく動く。ただし、たとえFlashゲーム自体が自由なソフトウェアであったとしても、その土台となるFlash Playerは不自由なソフトウェアである。Flashの自由な実装もあるにはあるが、あまりはかばかしいことは聞こえてこない。

その他のゲームとしては、他のプラットフォーム向けのゲームをエミュレーター上で動かすというものがある。GNU/Linux上で動くエミュレーターは多数ある。もっとも、GNU/Linuxから正規の方法で入手するのが難しいソフトウェアもあるのだが(入手にプロプライエタリなソフトウェアを使わなければならないなど)

たとえば、私はまだ試していないのだが、Wineを使えば、不自由なWindows用のSteamクライアントを実行してゲームをダウンロード、アップデートし、さらにゲームまで実行できるという。それも、10年前のゲームのみならず、SkyrimやCrysis 2などといった、最近の人気のゲームまで動作報告がある。いい時代になったものだ。ただし、これも不自由なソフトウェアの実行を許容するという条件がつく。

昔のゲームはGOG.comなどで販売されている。惜しむらくは、私は昔のゲームをあまり遊んでいなかったということだ。Apple 2とかMSXとかIBM PC上のDOSのゲームで、現在も正規の方法で入手できるゲームは多数あるが、残念ながら、私はその当時のゲームに親しんでいなかったので、たとえ精度の高いエミュレーターを使ったとしても、楽しめない。それに、多くの昔のゲームはプロプライエタリである。

たとえば、The Elder Scrollシリーズは、プロプライエタリであるが、ArenaとDaggerfallが公式からダウンロードできる。DOSBoxという精度の高いエミュレーターもある。しかし、残念ながら、私はその操作性に慣れることは出来なかった。

興味深いところとしては、id Softwareのゲームがある。id Softwareは、昔のゲームのソースコードをGPLで公開している。リソースはプロプライエタリなので、別途購入しなければならないが、ソースコードがGPLで公開されているため、GNU/Linux向けの移植も存在する。ソフトウェアの自由にのみこだわるのであれば、id Softwareの昔のゲームは悪くない。

さて、最近の面白い動向といえば、Wastelandだろう。このゲームは、あのFalloutの元ネタとなったゲームなのだ。本来、FalloutはWastelandの続編として開発される予定だったのだが、権利関係で折り合いがつかず、しかたなく別のブランドを立ち上げることにしたのだ。そのWastelandの原作者が、続編開発のためにKickstarterで出資を募っている。今現在、結構な出資が集まっている。150万ドルの出資を得ればLinuxへの移植もすると明言していたのだが、すでに出資額が150万ドルを突破している。果たして約束は果たされるのか。まともに移植性を確保したければ、最低でもコンパイル可能なソースコードの形で提供しなければならないが、受け入れるのか。なかなか興味深い。

あとは、Linuxのディストロ作成シミュなんてものもある。

オリジナルのプリンスオブペルシャのソースコードがgithubで公開された

jmechner/Prince-of-Persia-Apple-II · GitHub

アセンブリか。

きな臭い著作権ニュース

市役所のホームページの内容を無断で自分のブログに転載したとして、千葉県警サイバー犯罪対策課と流山署は16日、著作権法違反の疑いで同県八千代市米本の無職、影山万亀夫容疑者(25)を逮捕した。調べに対し、転載は認めているが「法には違反していない」と話しているという。

逮捕容疑は昨年10月23、24、29日ごろに自身のブログ「流山日日新聞」上に、無断でコピーした同県流山市公式ホームページ内の「先輩職員からのメッセージ」3人分を掲載し、同市の著作権を侵害したとしている。

同署によると、流山日日新聞を名乗る人物からメールで苦情を受けていた流山市が、同名ブログに職員を誹(ひ)謗(ぼう)する内容や、市のホームページの無断転載があるのを確認。昨年11月10日ごろ、同署などに相談していた。

個人ブログに市のHPをコピペ 著作権法違反容疑で無職男を逮捕 - MSN産経ニュース

なんだか非常に引っかかるニュースである。

言及されている流山日日新聞 ™(titleママ)をみてみると、どうも、別件逮捕くさい。おそらく、クレーマーをしょっぴいたのではないか。

しかし、もし本当に誹謗ならば名誉毀損などを問うべきではないのか。著作権侵害というのは非常にきな臭い別件逮捕の予感がする。そもそも、本当に著作権侵害なのだろうか。「同市の著作権」という言い方が非常に気にかかる。著作権法の第十三条二項によれば、

第十三条 次の各号のいずれかに該当する著作物は、この章の規定による権利の目的となることができない。

二 国若しくは地方公共団体の機関、独立行政法人(独立行政法人通則法<平成十一年法律第百三号>第二条第一項に規定する独立行政法人をいう。以下同じ。)又は地方独立行政法人(地方独立行政法人法(平成十五年法律第百十八号)第二条第一項に規定する地方独立行政法人をいう。以下同じ。)が発する告示、訓令、通達その他これらに類するもの

著作権法

とある。市のWebサイトは、この条件に当てはまるのではないだろうか。

というより、なぜこのニュースは警察発表を丸写ししたような本文なのだろうか。何も調べていない感がある。

宗教音楽がすばらしい

ふと発心して、いろんな宗教音楽を聞いてみた。神楽、読経、グレゴリオ聖歌、コーラン。どれもすばらしい品質だ。

当然だ。これらの音楽技術は、百年、千年の単位で開発され続けてきたのである。まだ数十年しか立っていない一年単位で使い捨ての昨今の音楽とはわけが違う。

最近、聞くべき音楽がないと思っていたが、そんなことはなかった。およそ、発明されるべき音楽はすでに発明されてしまったのだ。今あるのはその上澄みの搾りかすみたいなものだ。そして、著作権がどんどん不自由になっていくこの時代、新たに作られる音楽に未来はない。

これからは、すでに完成された音楽を発掘する時代になるだろう。もはや音楽の進化は止まっている。石のなかから多少ましな石を選ぶより、玉の山から優れた玉を選ぶべきである。

20世紀には、複製技術が著しい発展を遂げた。すなわち、音を録音できるようになったのである。また最近では、録音の複製が容易になった。このことから、著作権が不自然に強化されていくこととなった。そして、今後も著作権は継続的に強化されることに疑いはない。数十年ごとに、もう数十年ほど、著作権の保護期間を延長するのだ。これにより、我々は永遠の著作権を得ることになる。

しかし、強い著作権の下では、音楽は発展しない。当然だ。音楽は自由に歌われてこそ発展するのだ。自由に歌うことが制限された世界では、音楽は衰退するばかりである。証拠が欲しくば、今の音楽をみよ。まるでつまらないではないか。

しかし、希望はある。現時点で、すでに著作権者が故人となって数十年を経過している著作物は、おそらくギリギリで、この永遠の著作権から解放されるだろう。むろん、その頃には、私は鬼籍に入っているだろう。しかし、我々の次の世代は、音楽がまだ力を持っていた最後の時代の、本物の音楽を、自由な表現物として手に入れることになる。ここに希望がある。音楽は死んだが、本物の音楽が失われることはない。

2012-04-16

なぜGNU/Linuxは流行らないのか

疑う余地なく、GNU/Linuxは他の不自由なOSより優れている。パフォーマンス、利便性、カスタマイズ性、何をとっても最高である。ではなぜ、GNU/Linuxは未だにデスクトップOSを独占できないのだろうか。

ソフトウェアが欠乏しているのだろうか。しかし、私は今、nVidiaのバイナリブロブなドライバー以外の不自由なソフトウェアを使っていない。それどころか、ソフトウェアの質は自由か、もしくはオープンソースなソフトウェアの方が圧倒的に良い。唯一欠けているのはゲームだ。しかし、本物のPCゲームは、2004年のPainKillerが最後である。PainKiller以降、まともなPCゲームは存在しない。

では何が欠けているのか。

ひとつ思うのは、世の中には物事を自力で調べられない人種がいるのだろう。本当に自分に最適なようにカスタマイズするとなると、自力で調べる必要があるということだ。といっても、このインターネット全盛の時代、調べる手間は格段に下がっている。だから、これとてそれほどの障害でもあるまい。それに、変更といっても、設定ファイルを数行書き換えるとか、コマンドを数行実行するとか、その程度のことだ。なにもそれほど難しいわけではない。

ただ、根本的な、なぜデフォルトがこうなっているのかという設定がいくつかあるので、それをいちいち変更しなければならないのは面倒だ。とはいえ、一度変更してしまえば済む話だ。

とにかく、自由なソフトウェアは不自由なソフトウェアより圧倒的に優れているので、ぜひとも移行するべきだ。

Ubuntuでファイル名のソートがおかしい問題の修正

日本語のファイルを多数入れたディレクトリを、UbuntuのデフォルトのファイルマネージャーのNautilusで見たところ、不思議な挙動に気がついた。ファイル名のソートがなにかおかしい。不思議に思ってlsを使ってみると、やはりソートがおかしい。なぜか。Ubuntuのデフォルトのロケール設定のためである。

Ubuntuでは、デフォルトのLC_COLLATEは、en_US.UTF-8になっている。このままでは、ASCII内の文字ぐらいしかソートされない。CJK文字のソートは、どうもよく分からない不思議な順序で比較される。

ロケールというのは厄介だ。たとえば、ある言語では、アクセント記号の有無で別のコードポイントが割り当てられている文字があるが、そのような文字は同じ文字として扱ってほしいため、その言語のロケールの文字の比較は、そのように振る舞う。しかし日本語では、あまりロケールでなにかして欲しくない。思うに、日本語文字はやや複雑すぎて、何か賢そうなことをしようとすると、かえって悪い結果になるのだと思う。日本語環境における文字のソートは、単に生のコードポイントの大小比較の方がよっぽどましだ。

というわけで、日本人ならUbuntuのLC_COLLATEを"C"に変更すべきである。

  1. テキストエディタで、"~/.profile"を開く。
  2. 「export LC_COLLATE="en_US.UTF-8"」を、「export LC_COLLATE="C"」に書き換える。
  3. ログインしなおす

lsやNautilusがCJK文字をコードポイントの順序でソートしていることを確認する。

2012-04-14

John Cleese、創造性について語る

Boing Boingで紹介されていた少し古い動画。相変わらずJohn Cleeseは話がうまい。

John Cleese on Creativity - YouTube

本物のC++プログラマーはいまどきcore issue 1123の実装ごときに歓喜しない

なぜならば、そんなのはとっくの昔に実装されていて当然だからだ。某鉱物君のようにはしゃいだりはしない。

#include <iostream>

struct X
{
    ~X() { }
} ;

int main( )
{
    X x ;
    std::cout << std::boolalpha << noexcept( x.~X() ) << std::endl ;
}

今をときめく本物のC++プログラマーはclangを使う。

ところで、boolalphaをうっかりtypoしてboolaphaと入力してしまい、そのままコンパイルに通してしまったところ、clangは、「もしかしてboolalpha?」とささやいてくれた。すばらしい。

真の乱数を得る斬新な方法

Quantum random number generator

なかなか斬新な方法で真の乱数を生成する方法が発表された。

その方法とは、光をふたつにわけ、それぞれ光の強さを計測する。光というのは量子化されているから、わけられたそれぞれの光の強さは増減する。この増減の情報は、真の乱数として利用できる。

私は常々、すべての通信を暗号化することが重要になる将来、コンピューターは真の乱数を高速に生成するデバイスを搭載するべきではないかと考えているのだが、なかなか実用化されない。まあ、放射性物質とガイガーカウンターと外部の影響を遮断するための分厚い壁からなる真の乱数生成デバイスは、普通のPCに組み込むにはだいぶ敷居が高いのだが。

LLVMによるC++/CLIコンパイラー

LLVM Europe 2012: A Portable C++/CLI Compiler

まあ、面白いアイディアだとは思うが、誰が使うんだ。

.net Frameworkは、Windowsにおけるサポートや、最近のゲームライブラリの方のUnityの興隆により、やけに人気だ。ただ、.net frameworkの全機能を駆使するCILを吐かせたかったら、普通はC#を使うはずだ。何もツギハギにツギハギを重ねたようなC++/CLIを使う必要はあるまい。

ちなみに、これを使ってユーザーモードLinuxをSilverlight上で動かすことに成功したらしい。

There are other fascinating integration points like a pretty neat Objective-C++/CLI bridge.

Objective-C++/CLIなんてのも、なかなか面白そうだよね。

おいおい。

ちなみに、開発者が想定している主目的は、ゲーム内のスクリプト用途らしい。最もこの研究は、やや余興的なものらしいが。

2012-04-13

GNU/Linux関連のこと

最近のGNU/Linux関連で興味深いものをいくつか。といっても、Ubuntuを使っているため、Ubuntu関係が多い。

もうすぐUbuntu 12.04がリリースされる。今回のリリースでは、Monoがインストールディスクから取り除かれる。もちろん、公式レポジトリからMonoは提供されるが、デフォルトではインストールされない。

これに伴い、Banshee(音楽再生ソフト)、Tomboy(メモ取りソフト)、GBrainy(論理パズルゲーム)もデフォルトインストールから取り除かれる。デフォルトで入る音楽再生ソフトは、BansheeからRhythmboxに置き換わる。Tomboyは、もし非monoな代替ソフトが欲しければ、Gnoteがある。GBrainyの直接の代替ソフトは思いつかない。なかなか面白いソフトである。IQテストに出てきそうな問題が多数含まれている。

もちろん、11.10や10.04からアップグレードする場合には、monoは削除されない。Ubuntuからmonoとmonoランタイムに依存するソフトをパージするには、以下のコマンドを使うとよい。もちろん、このコマンドを実行すると、monoランタイムはもちろん、monoランタイムに依存するソフトである、Banshee、Tomboy、GBrainyも削除されてしまう。これらのソフトウェアを使いたい場合は、monoランタイムを取り除くことはできない。

sudo apt-get purge cli-common mono-runtime

Ubuntu 11.04 - Removing Mono, intentionally easy? | http://linuxtweaking.blogspot.com

Monoを取り除くに至った理由はどうもよくわからない。少し検索してみたが、大雑把なメモしか見つからない。思うに、monoは十分に自由とは言えないからではないだろうか。monoには特許の問題がある。それに、C#を使った自由なソフトウェアも少ない。これは私も同意するところである。JavaやC#は、その背景事情をみると、十分に自由とは言えない。

No-Mono-by-Default - Ubuntu Wiki

どうも、Ubuntu 12.04では、HUDによって、メニューを検索できるらしい。これは、実際に使ってみないと便利かどうかわからないだろう。それから、Workspaceが動的に追加削除されるらしい。まだ試していないが、面白そうだ。固定数のworkspaceというのは少し不満だった。時に、もっとworkspaceがほしいと思うことがある。しかし、常に大量にほしいわけではない。workspaceの数の動的な変更は面白そうだ。もちろん、実際に使ってみるまではなんともいえないのだが。

その他の興味深いニュースとしては、nVidia関連のものが多い。

[Phoronix] NVIDIA 295.40 Closes High-Risk Security Flaw

以前のnVidiaのプロプライエタリでバイナリブロブなドライバーにセキュリティホールがあったそうだ。

[Phoronix] A NVIDIA Tegra 2 DRM/KMS Driver Tips Up

Tegra 2の自由なドライバーがDRM(Direct Rendering Manager)とKMS(kernel Mode Setting)をサポートしたらしい。最近、nVidiaはLinux Foundationに加入している。Tegra 2のドライバーの開発は、nVidiaが支援するコミュニティによって行われているらしい。興味深い話だ。これでデスクトップ用のGPUのドライバーも自由だったらいいのに。

[Phoronix] Open-Source NVIDIA Driver Approaches Stable State

リバースエンジニアリングをもとに作られたnVidia用の自由なドライバーであるNouveauが安定してきたようだ。本当だろうか。いまだに問題が多いのだが。

雑感

GNU/Linuxを使うのは非常に簡単だが、その詳細を学ぶとなると、だいぶ難しい。たとえば、dpkgやapt-getを使うのは簡単だが、じゃあ実際に自分でPPAを作ったり、debファイルを作ったりするにはどうすればいいのかというと、まださっぱりわからない。ソースコードが公開されていて、ドキュメントも整備されているとしても、学ぶには時間がかかる。しかし、今後もUbuntuを使い続けるならば、いずれ学ばなければならないと思う。

もちろん、不自由なWindowsを使っていたときも、インストーラーの仕組みについては学ばなかった。Windows InstallerとかInstallShieldとかNSISなどの使い方は、常には知りたいと思いつつも、学ばなかった。だから、同じ事だとも言える。何でもかんでも詳細を学んでいてはキリがない。ただ、私は性格上、どうしても詳細が気になってしかたがないのだが。

Ubuntuの開発になにか貢献してみたいと思いつつも、まだGNU/Linuxに移って日が浅く、自分の手足のように使いこなせているわけではないので、まだ敷居が高い。GNU/Linuxにおけるプログラミング作法も、まだ全然実感がつかめていない。せめて翻訳でも、と思うのだが、私はUbuntuを英語UIで使っていて、特に日本語UIにするつもりはないので、やはり貢献できそうにない。自分で使わない翻訳がまともな翻訳になるはずがない。

ANSIからC++11の規格書が$30で販売されている

INCITS/ISO/IEC 14882-2012 Information technology -- Programming languages -- C++

ISOで何百スイスフランも払えないという人にはおすすめ。

ちなみに、単にC++11の規格を読むだけなら、N3337をみればよい。C++11規格制定後に作られたドラフトで、変更点はtypoの修正ぐらいしかないので、ほぼ現行のC++11規格と同じだ。

ppa-purgeについて

Ubuntu 11.10のレポジトリにはないが、12.04のレポジトリには存在するソフトウェアが結構ある。そういうソフトウェアは、大抵メンテナーによって、テスト用のPPAが公開されているものだ。私も早速そのPPAを使い、ソフトウェアをインストールしてみた。

さて、ここでひとつ疑問がある。二週間後に控えている12.04へのアップグレードの時、このPPAからインストールしたソフトウェアはどうなるのだということだ。このソフトウェアは、特にシステムの根幹に関わるものではないので、それほど危険ではない。しかし、やはり気になる。

調べてみると、どうやらそういう場合のために、ppa-purgeなるbashスクリプトが用意されている。これは、引数として与えたPPAに属するすべてのソフトウェアを、公式レポジトリのバージョンにダウングレードしてくれるスクリプトだという。なるほど、たしかにそれなら安全だ。しかし、今のバージョンのUbuntuのレポジトリに存在しないソフトウェアはどうなるのだ。そのまま残るのか。それとも削除されるのか。

そこで、ppa-purgeを読んでみることにした。まだbashスクリプトは完全に習得していないが、読むぐらいならできるだろう。

vim /usr/sbin/ppa-purge

ppa-purgeの実装は、まず与えられたPPAに属するソフトウェアのリストを作成し、その中からインストールされているソフトウェアのリスト(つまり該当PPAからインストールしているソフトウェア)を作成する。
次に、インストールされているソフトウェアをすべて削除する。
そして、PPAを取り除く。
その後、インストールされていたソフトウェアを、インストールしようとする。つまり、該当PPAが取り除かれた後でインストールするので、他のPPAで同じソフトウェアを提供していなければ、公式レポジトリからインストールされる。
もし、パッケージが見つからない場合は、そのまま無視するようだ。

なるほど、実にわかりやすい。しかし、bashスクリプトは非常に強力だ。UNIXでは、スレッドよりもプロセスやパイプが発達したというのは実に興味深い。今まで意識していなかったが、多くのコマンドは、bashスクリプトやpythonスクリプトで書かれている。

今使っているPPAとソフトウェアの数は、手動で取り除くことができるだけの数であるが、このようなツールが提供されているのは心強い。

そして、必要であれば、いつでもソースコードを読んで実装を確認できる環境はすばらしい。

しかし問題は、アップグレード後もPPAによる最新で頻繁にアップデートされるソフトウェアを使い続けたい場合、いったいどうすればいいのだろうか。PPAを有効にしたままアップグレードしても安全なのだろうか。

2012-04-12

xkcd: バルマー・ピーク

どうもアルコールの摂取が問題解決能力を上げるという記事が話題なので、

Medical Daily: Drinking Alcohol May Significantly Enhance Problem Solving Skills

関連したxkcdを紹介する。

xkcd: Ballmer Peak

縦軸:プログラミングスキル
横軸:血中アルコール濃度(%)

この現象はバルマー・ピークと呼ばれております。80年代後半、マイクロソフトによって発見されたものであります。理由は不明ながら、血中アルコール濃度の0.129%から0.138%の範囲において、超人的なプログラミング能力が発揮されるのであります。

しかし、この作用の調整には細心の注意が必要であり、この結果を元に、すぐさまコーダー達にウィスキー一年分を与えて、さあ仕事に取り掛かれ、と命じるわけにはいきません。

「そんな馬鹿なこと試したところがあるのかね?」
「Windows MEのことは覚えていらっしゃいますか?」
「なるほど、道理で!」

大学に行くべきだったのか

C++の参考書は、ようやくテンプレートまで進んだ。この項目は、大胆な割愛や、簡略化した説明をしなければならないだろう。テンプレート仮引数とテンプレート実引数を完全に分離して説明するのは、さすがにわかりにくい。

しかし、いまさらになって、大学に行かなかったことが失敗ではないかと思いつつある。

理由はいろいろあるが、私は当時、大学に行かなかった。親の別居やら引越しやら、その理由を当時の外部要因に求めることはたやすいが、結局、大学に行かなかったのは私の責任である。

そして今、私がC++を学ぶために何をしているかというと、規格や論文の読解である。私は一度も、論文の構造とかプログラミング言語の規格書の構造について学んだことはないが、なんとなく感覚で会得していった。

これは正しくない学び方だ。最初に、学問を学問として、系統だてて学んだ方が良かったと思うのだが、いまさら悔やんでも始まらない。もちろん、論文の構造は、大学に行かなくても学ぶことはできるが、必要でないものは、なかなか学びにくい。

思えば、私は常に、物事を感覚で学ぶ人間であった。英語だって、私は未だに感覚で使っている。そのため、「お前の英語はおおむね正しいが、articleやpluralなどの基本的な所が抜けている」とよく言われる。これは、どうしても感覚で覚えるのが難しい、基本的な文法である。このような基本的な文法に違反することが、いかに不自然であるかは、日本語学習者の使う日本語を見ればわかる。

といっても、今から大学に行くのは難しい。まず金だ。金がないから仕事を探しているのに、金の必要な大学に行くのは本末転倒もいいところだ。奨学金と称する学費借金はあるが、結局、問題を先送りするに過ぎない。今日の金に困っているのに、さらに何百万の借金を負うのだから。

さらに、高校を卒業してだいぶ間が開いてしまったので、大学入試を突破するのも難しいだろう。この間、半ば趣味として今も向上している知識は、古文、漢文、英語だけである。私の目的とするプログラミングの分野とはかけ離れている。

それに学位取得自体には、まったく魅力を感じない。

なぜこうなったのか。私の目的とは、プログラミング言語やソフトウェアの歴史を学ぶことであって、それには英語の読解力が必要だった。私は昔から読書好きで、言語に関しては興味があったので、古文、漢文、英語は自然と身についたのだ。今でも古文漢文はよく読む。

しかし、数学とか化学、物理、生物とか、単純な暗記力を必要とする歴史や地理や政治社会は、どうも身につかない。説話集とか、平家物語の諸本に関してはだいぶ読んだが、治承が西暦何年で、崇徳院が流されたのはいつで、壇ノ浦の戦いは西暦何年に起こって、などといったことは、全く頭に入らない。それよりは、頼朝が院宣を持して宇治川に臨んだとか、平家軍は羽音に驚いて逃げたとか、頼朝は手水うがいして神仏に感謝したとか、そういったことの方が頭に入る。

だからどうも、私がプログラミングといったとき、実用的なコードを書くのではなく、プログラミング言語やプログラミング周辺の背景事情や歴史などを学びたがるのは、どうも生まれ持った気質ではなかろうかと思う。

そういえばひとつ気になるのが、私の記憶では、C++ Working Group日本には、大学機関に所属する博士がいないということである。というより、皆企業の代表か個人で参加している人間だったはずだ。博士号取得者がいるとしても、企業に属する博士しかいないはずだ。この事実は一体何を意味するのであろうか。

C++を教育している日本の大学はあるはずだ。もし、日本でC++を研究している博士がいたならば、C++WGの日本支部に籍をおいているはずである。しかし、みあたらない。はて。

アカデミックなところは理解できない。

2012-04-11

プログラマーの求人はたくさんある

もう一度、本気で就職活動をしてみようと考えている。探せば、未経験でも応募できる求人はある。ただ、この手の求人には、どうしても嫌な思い出があるのだ。

労働基準法違反を指摘しても開き直っていたり、面接でタバコを取り出したりと、本当に嫌な思い出が多数ある。

それでも、探すしかないか。これ以上どうしようもないのだから。

2012-04-10

マリオブラザーズの未開封品がeBayに出品

Original Mario Bros. Silver Seal Nintendo,1986 NES VGA 90 Q-NM+/MT Arcade Series (734060045496) | eBay

なんと、北米版マリオブラザーズの未開封品が、eBayに出品されている。落札価格は、1.75万ドルからスタートとなっている。コレクター魂はわからん。

もちろん、値段の妥当性について云々するつもりはない。納得して払うマニアがいるなら、それだけの価値があるということだ。ただし、一体どうやって確かめるというのだろうか。およそ、これをこの価格で落札する人間は、まず開けたりなどしないだろう。マリオブラザーズの動作する中古カートリッジなんて、まだいくらでも手に入る。未開封品であることが重要だからだ。だから、開けるわけには行かない。開けられないとすると、本物かどうか確かめられないではないか。

X線撮影などを用いれば、中にカートリッジが入っているかどうかは確認できる。しかし、やはり動作する本物のカートリッジかどうかはわからない。本物かどうか確かめる唯一の方法は、箱を破り開けて、フーフーして、NESに差し込んで 、実際にプレイしなければならない。が、すでに述べたように、そんなことは不可能だ。

したがって、本物のコレクターが落札した場合、物の真偽を確かめる方法はない。単に高い値段を払って所有しているという自己満足で終わってしまう。

まあ、コレクター魂なんてそんなものか。

2012-04-09

Goは32bit開発に不適

Do Not Use Go for 32bit Development

私は今、大量のGoのコードをCに書き換える作業をしている。時間は金で買えない。主たる開発者として、金はここで止まってしまう。わたしは顧客と話し、責任を負った訳だ。私の過ちは、Goを信頼したことだ。私は自分のモットーを思い出すべきだったのだ。Nullius in verba(政治信教の言を入るべからず)

Goは1.0がリリースされたが、もし、32bitサポートが必須であれば、Goを選んではいけない。

32bit Goには多くのバグがあるが、特に問題なのがひとつある。

実行開始の初期化時に、Goは512MBの仮想アドレス空間を予約しようとする。予約できなければ、クラッシュする。Goは、ガベージコレクションのためにこの空間を必要とする、おそらく、すべてのGC言語、いや、すべての言語は、メモリ管理に対して、似たような手法を用いているだろうから、この問題は潜在的にひっかるであろう。32bitのWindowsにおいては、プロセスは2GBのユーザー空間のメモリーにしかアクセスできない。このユーザー空間は、フラグメントを引き起こす。例えば、512MBの確保のまえに、DLLを読み込んだりなどすれば、可能性がある。結果として、Goランタイムが空間を予約するのを妨げる。

Goは単一の巨大なブロックの確保をあてにしている。おそらく、他のGC言語では、より小さな単位のメモリーを使う仕組みを実装しているのだろう。

この問題は再現とテストが難しい。ほとんどの場合、Goは全く問題なく動くからだ。どうやら、リブートは問題の解決に役立つのではないかと思う。また、この問題に直面するのはWindowsだけではないかとも思う。Linuxではこのバグリポートは上がってこなかった。Goの開発者は、この問題をすでに把握しているが、優先順位は低い。

Goでのプログラミングは素晴らしいものだ。私はRob Pikeの「プログラマーは問題を解決する代わりに文句ばかり言う」という言も、もっともだと思う。残念ながら、私はGoランタイムコードに慣れていないため、ソースコードの中に飛び込んで、新たなバグを生み出さずに、メモリ管理の問題を修正できる自信はない。それに、納期に追われていて、時間もない。時間がとれたら、この問題の修正を試みるつもりだ。

追記:Goの開発者はとても親切で、問題の理解を助けてくれたことは追記しておく。ただし、彼らのいう解決方法は一貫して、「64bitに移行しろ」であった。

なるほど、16bitから32bitへの移行は、セグメント管理が面倒だから起こった。物理メモリ量もムーアの法則を裏切らないように増えていったが、やはり単一の32bitアドレス空間でないとプログラミングが面倒だったのだろう。32bitから64bitへの移行も、物理メモリの量ではなく、仮想アドレス空間の欠乏から起こるのかもしれない。

2012-04-08

Twitterの感想

Twitterである。私は、最後までTwitterに反抗し続けてきた人間の一人である。Twitterの問題点は、情報が細切れになってしまうことと、後から読み返すのが難しいということである。

私がTwitterを危険視していたのは、私は以前から購読していた多くのブログが、更新をやめた理由が、Twitterであるように思われたからだ。ちょうどTwitterが流行りだした頃、多くのブログが、「Twitter始めました」などと書き残して、それっきり更新を絶ってしまうことがしばしばあった。あるいは、ブログがTwitterのログを垂れ流すだけになってしまった。以前ならまとまった情報がブログで提供されていたのに、書き手がTwitterに移行してからというもの、細切れの情報しか出てこなくなった。

よく言われるのが、Twitterは敷居が低いということである。たしかに「今どこにいる」だとか、「さっき何を食べた」などの細かい情報を、わざわざブログに書きこむのは、敷居が高い。そんな小さな情報のために、わざわざ文章を書くのは難しい。だから、そのような小さな情報を発信するためのサービスが流行るのはわかる。しかし、だからといって、ブログがなくなるはずがない。ブログは、Webサイトほど大規模や複雑ではない、投稿単位の情報に対しては、依然として有効なはずだ。第一、Twitterで話題になるブログ記事も多いではないか。

とはいえ、時代の流れには勝てない。何事も経験してみるしかないので、Twitterを始めてみた。

始めるやいなや、一気に100人以上ものfollowerが現れた。多くは、私がGoogle Readerで一方的に購読していたアカウントだったので、自然とfollowし返すことになった。この際、TwitterのUIは、ページ遷移を伴わない作りになっているので負担が低い。そして気がつくと、初日で200人ものfollowerとfollowが行われた。

TwitterのWebサイトのUIは、マウスを必要とせず、キーボードショートカットで全てを行えるUIになっているので、使い勝手もなかなか悪くない。気がつくと、すでに自分のtweetsが100を超えていた。

なるほど、たしかにコミュニケーションの敷居は低い。ただし、対話はその場限りの刹那的なもので、すぐに膨大なtweetsの山に埋もれてしまう。消して消えるわけではない。URLを指定すればあとで読み返すこともできる。ただし、Twitterの検索は最近の発言しか表示しないし、たとえ検索できたとしても、やはり後から読み直すのは難しい。

このTwitterでリアルタイムに発言されている情報が、推敲されてブログ記事になればいいのにとも思うが、やはり、そのような敷居の高さでは、これほど活発な対話は行われないだろう。難しいものだ。

まあ、流行っているからには、流行るだけの理由があるのだということを思い知らされた。

となると、今流行りのソーシャルゲームであるが・・・いや、そこまで踏み込むのはやめておこう。金もないし、不自由なソフトウェアを所有したいとも思わない。そもそも、所有しているかどうかすら不明だ。

GNU/Linuxユーザーの恋愛観

またもやxkcdから面白い漫画を紹介。日本人はもっとxkcdを知るべきだと思う。今回は、画像のtitle textもちゃんと翻訳した。わからない者はわからなくて結構。

 Command Line Fu

xkcd: Command Line Fu

「昨日の晩、彼女と映画観てたんだけどさ、省電力機能は無効にしてたのに、モニターの電源がなぜか切れるんだよ」
「あらら」
「でも! マウスポインターをちょこっと動かすスクリプト書いて、なんとかしたよ」
「あんまりいいハックとはいえないけど、まあ、Linuxには問題があるにせよ、問題を解決するツールも提供されてるってことだね」
「いや、実はその後、30分ぐらいかけてスクリプトのドキュメント書いてたら、彼女が服着て帰っちゃったんだ」

色気よりプログラミング?

Orphaned Projects

xkcd: Orphaned Projects

Debian Linux開発室

問題:開発者の一人が、週末にデートするそうだ。交際なんかしだしたら開発が滞る。

「どうするんだ?」
「あいつの為にデートのコーチを雇ってやった。最後の恋のはじめ方に出てくるウィル・スミスみたいなコーチだが、しかし悪いアドバイスをする手はずになっている」

「いいか。会話の秘訣は建設的な反論だ」
「いかに自分が知的であるか見せつけてやるんだ」
「なるほど、当然だな」

Debianの開発者の男が「建設的な反論」など始めた日にはデートなど台無しである。

DCPU-16用LLVMバックエンド

DCPU-16のLLVMバックエンドが登場した。

krasin/llvm-dcpu16 · GitHub
LLVM backend for DCPU-16 | Hacker News
0x10 ͨ

マジかよ。早すぎるだろ。まだ肝心のゲームも公開されてないのに。

知らない人のために簡単な解説。DCPU-16とは、あのMinecraftを開発したNotchが、もっか開発中のゲームに登場するCPUである。LLVMバックエンドができたということは、ゲームでC99やC++11やObjective-C、その他LLVMフロントエンドとして実装されている言語を使えるということである。

xkcdで面白い漫画をいくつか紹介

xkcd: Supported Features

「いやー、このパッチ書くの苦労したよ。でもこのパッチのおかげで、Linuxは4096個までのCPUに対応できる。以前の制限は1024個だったんだぜ。」
「Flashの全画面再生がスムーズになるようにしてほしいんだけど」
「は? そんなの誰が欲しがるんだよ?」

Linuxハッカーと一般人の需要はずれているというお話。

xkcd: Open Source

忍者「リチャード・ストールマン! お前のオープンソースライセンス運動は少々厄介になり始めた」
忍者「GPLは食い止めねばならん」
忍者「そのソースから」
忍者「つまりお前だ」

RMS「ふん、マイクロソフトの手先め。ついに来おったか」
RMS「この血なまぐさい日を待っていたわい。ストールマン死すとも自由なソフトウェアは死せず。GNUの夜明け! 自由!」
RMS「おい、どこ行くんじゃ」

忍者「おいおいマジだったな。お約束すぎる展開だぜ」
忍者「次、エリック・レイモンド行ってみようか」
忍者「あとリーナス・トーバルズとかな。奴はヌンチャク持って寝てるって話だぜ」

これに影響されて、リチャードストールマンは刀をプレゼントされたり、講演の最中に忍者に襲われたりした。

xkcd: X11

縦軸:人生における幸福度
横軸:XORG.CONFを開かなければならない事態に陥ってからの経過時間

X11の設定ファイルを編集するのはそれほど苦痛であるということ。

xkcd: Real Programmers

「nano? 本物のプログラマーはemacsを使うんだぜ」
「ちょっと、本物のプログラマーはvimを使うのよ」
「いや、本物のプログラマーはedを使うのだ」
「違う。本物のプログラマーはcatを使う」
「本物のプログラマーは磁気針と精密動作をする手を使うのじゃ」
「待ちたまえ。本物のプログラマーはバタフライ効果を使うのさ」

「こうやって手をかざして一度振ると、」
「外部に及ぼした大気の振動が、上空の大気圧の変化をもたらす。この変化によって磁気ポケットが発生し、」
「レンズのように働いて宇宙線を収束させ、ドライブのプラッターを直撃して、任意のビットを反転させる」

「そりゃいいな。たぶんEmacsにそれするコマンドあるだろ」
「だよな。昔ながらのC-x M-c M-butterflyあたりが・・・」
「Emacsめ・・・」

ちなみに、最新のEmacsにはC-x M-c M-butterflyが実装されている。

なぜCtrlキーを押しながらタスクマネージャの新しいタスクを選択するとコマンドプロンプトが開くのか

Why does holding the Ctrl key when selecting New Task from Task Manager open a command prompt? - The Old New Thing - Site Home - MSDN Blogs

Adam SはなぜCtrlキーを押しながらタスクマネージャの新しいタスクを選択するとコマンドプロンプトが開くのか質問した。

隠し機能さ。

Windows XPはビジュアルスタイルを導入した。ビジュアルスタイルをデバッグする際に問題になることは、もしビジュアルスタイルエンジンが暴走した場合、まともに見えなくなるということだ。ビジュアルスタイルの開発者がしばしば直面した問題に、実行ダイアログが動かなくなるというものがあった。実行ダイアログがなければ、問題を検証するためにデバッガーを起動することすらできなくなる。

解決方法として、Ctrlキーを押しながらタスクマネージャの新しいタスクを選択すると、実行ダイアログをすっ飛ばして、コマンドプロンプトを起動できるようにした。コマンドプロンプトから、デバッガーをインストールしてデバッグができる。この手法は、Windows XPのコンソールウインドウはテーマが適用されないという仕様上、都合よく動く。ビジュアルシステムが壊れたとしても、コンソールウインドウは動くのだ。

その後、ビジュアルスタイルのバグは潰されていき、隠し機能は必要なくなった。しかし、どういうわけか、取り除かれずに残ったのだ。

ちなみに、なぜ仮想環境を使わないのかという疑問に対しては、そもそもWindows XPの開発当時、仮想環境はまだ発展途上だったからだ。

2012-04-07

GNU/Linux移行の感想

GNU/Linuxへ移行してから、今日で二週間たった。だいぶ慣れてきたので、今の状況のまとめと感想を記録しておこうと思う。結果からいうと、私の当初のGNU/Linuxに対する不安は、杞憂で的外れだったことになる。もっと早く移行すべきだった。

まず、GNU/Linuxのパフォーマンスは素晴らしい。Windowsより快適だ。もちろん、私の使っていたWindows Vistaは32bit(何故かアカデミック版が32bitしかなかった)で、HDDも古かったから、単純な比較はできない。公平に比較するためには、同じHDDに最新の安定板であるWindows 7の64bit版をインストールして比較するべきだろう。ただし、今の私にはその比較をする金がない。無料で手に入る自由なソフトウェアが満足できるほど優秀であれば、わざわざ高価で不自由なWindowsを使う理由はない。

私は、十分に調べなければ、モノを安心して使えない性質である。10年前も、WindowsとGNU/Linuxを、まだ所有もしていないのに使い方を調べていた。当時、まだ実際にコンピューターを所有していないのに、GNU/Linuxで一般的なコマンドや日本語環境の構築方法、Xの設定方法、nVidiaのドライバーのインストール方法などを調べていたものである。今回もだいぶ調べてから移行した。結果から言うと、机上の学習に時間を割くよりも、すぐに移行するべきだった。今や、Ubuntuは事前に学ばずとも、簡単に使えるOSになっていたのだ。

Wineについては、私がコンピューターを所有する前からその存在を知っていた。二週間前、つまりGNU/Linuxをインストールする前までは、私はGNU/Linuxに移行して、まずまっさきにインストールしなければならないのはWineであろうと考えていた。ところが、いざ移行してみると、特になければ困るWindows専用のプログラムはほとんどないことが明らかになった。だから、未だにWineはインストールしていない。インストールは簡単だが、インストールする必要性を感じないのだ。思うに、今はコンピューターの利用の多くを、ブラウザーを介したWebに頼っているからに違いない。Chromiumは、Windows版と同じエクステンションを使うことができる。なぜならば、エクステンションはHTML/CSS/Javascriptで書かれているので、OSに依存しないのだ。Webサイトのサービスも、OSに依存しない。

Ubuntuに付属していたPDFを表示できるEvinceは軽くて使いやすい。日本語も正しく表示できるようだ。GUIのテキストエディターも複数ある。今はgeditを使っているが、パフォーマンス的にも問題ない。むしろWindowsで使っていたnotepad++よりパフォーマンスが良い。geditも、Windows環境で試しに使ってみたところ、あまり好感が持てなかったが、GNU/Linux/X環境で使うと、見違えるようだ。思うに、GTK+のWindows移植は、とりあえず動くというレベルなのだろう。

GNU/Linux環境でうれしいことは、主要なディストリでは、ソフトウェアのコンパイルが楽だということである。全く知らない言語とライブラリを使って書かれ、全く知らないビルドシステムを使ってコンパイルするソフトウェアであっても、GNU/Linuxでは非常に簡単にコンパイルできる。ビルドのためのツールや必要なライブラリは、ディストリに付属のパッケージ管理ツールで簡単にインストールできる。不自由なWindowsでは考えられない快適さだ。これならば、プログラミングについて何も知らないユーザーでも、ソフトウェアを自力でコンパイルできるはずだ。

フォントについても、全く不便を感じない。Windowsでおなじみのいわゆるリョービフォントやメイリオフォントはないが、IPAフォントをもとにしたTakaoフォントは十分に実用的だ。

フォント描画に関しては、Windowsネイティブの描画とはだいぶ違うので、最初は戸惑った。しかし、悪いというわけではない。むしろ、DLLラッパーによってWindowsのフォント描画を高品質にするという触れ込みの怪しいgdippの類とよく似た描画方法になる。たしか、gdipp系のDLLラッパーがやっていることとは、目的のフォントサイズより大きなサイズで描画して、優秀なスケーリングアルゴリズムを使い、目的のサイズに縮小するだけだったはずだ。実は、もっとも高品質なアンチエイリアスとは、まさしくその方法である。目的のサンプル数よりも高サンプルでレンダリングして、優秀なスケールアルゴリズムを使い、目的のサンプル数に縮小する。もっとも、3D描画などでは、このような愚直なアンチエイリアスは、パフォーマンス的に現実的ではないから、最近はもっと賢いアンチエイリアス方法が日々考案されているのだが。

結論として、今や、GNU/LinuxはWindowsを代替するのに十分な力を持っている。むしろ、Windowsより優れている点もある。ぜひとも移行すべきだ。特に、プログラミングを学ぶなら最適だ。プログラミングに必要なツールやライブラリのインストールに苦労しなくても済む。ターミナルも高性能だ。自由とかオープンソースなどの利点を持ち出すまでもなく、単純にプログラミング環境の構築が容易なのだ。プログラミングをしないとしても、やはりGNU/Linuxに移行すべきである。圧倒的に使いやすい。

Twitterを始めることにした

どうも時代の流れには抗いがたい。そこで、Twitterを始めてみることにした。なんだか時代に負けた気がするが、まあ、仕方がない。

Ryou Ezoe (ezoeryou) on Twitter

とりあえずいくつかtweetしてみたが、どうもUIがごちゃごちゃとしている。おすすめのfollowすべき5人などを延々と紹介してくる。まあ、5人followしろということなのだろうが。

NでTweetを入力するダイアログを開けるが、肝心の入力を完了するショートカットがない。タブでTweetボタンに合わせなくてEnterを押すのが最も手っ取り早いようだ。

やはり、ブログのほうが情報がまとまっていて読みやすいと思うのだが、どうも人は楽な方を選ぶようだ。

2012-04-06

GPGPU時代のハッシュアルゴリズム

Coding Horror: Speed Hashing
xkcd: Password Strength

GPGPUが一般的になった現代では、従来のハッシュアルゴリズムは十分な強度ではないというお話。一般人が五百ドル程度で購入できるハイエンドグラフィックカードは、現在のハイエンドCPUより150倍も高速にハッシュ計算ができる。しかも、GPGPUで高速に計算できるということは、並列性が高いということを意味する。つまり、GPUを増やせば容易にスケールするので、さらに危ない。

もはや、MD5やSHA-1、SHA-2の時代は終わった。これからの開発者は、GPGPUに対しても十分な強度を持つ、容易に並列化できないハッシュアルゴリズムを採用しなければならない。

ユーザーは、長いパスワードを使わなければならない。現時点でのJeff Atwoodのおすすめは、12文字以上である。1(xY%08などという、人間にとって覚えにくい、辞書にも載っていないパスワードは、もはやなんの役にも立たない。なぜならば、たった一枚の家庭用グラフィックカードは、USキーボードに刻印されている文字の組み合わせならば、二時間弱で7文字を総当りできるからである。

したがって、2012年現在、パスワードは12文字以上(長ければ長いほどよい)にすべきである。記号や数字を含めるよりも、辞書に乗っている単語を避けるよりも、単純な長さが重要になってくるのだ。たとえ単語が辞書に載っていたとしても、組み合わせて長くしたほうが、人間にとって覚えにくいパスワードよりよほどいい。何故ならば、もはや本当の敵は人間ではなく、SIMD演算に特化したコンピューターだからだ。このような長いパスワードを、メモに残さずに覚えるためには、パスフレーズというテクニックを使うとよい。つまり、パスワードを単語とするのではなく、文章にするのだ。たとえラテンアルファベット小文字しか使っていなくても、20文字のパスワードの方が、記号や数字だらけの10文字のパスワードより安全である。

LLVMベースのGoによるGoコンパイラー、llgo

axw/llgo · GitHub

llgoはLLVMをベースにした、Goで書かれたGoコンパイラーである。実用を目的として開発しているわけではないそうだが、それでも興味深い。現時点では、LLVMバイトコードを吐けるのみなのだとか。

GOG.comで初代Falloutが48時間無料

GOG.comで初代Falloutが48時間無料だそうだ。

Fallout - GOG.com

私はこの世代の時代にゲームをしていなかったので、初代Falloutは楽しめないだろう。これは実にもったいないことだと思う。もし当時PCゲームで遊んでいたら、Falloutは私にとって神ゲーだったはずだ。

さて、Wineで動くのだろうか。動く場合もあり、動かない場合もあり、workaround満載と、なかなか面倒だ。

WineHQ - Fallout

そろそろWineも試してみたいが、いま特に実行したいWindows用のソフトウェアが存在しないのだ。GNU/Linuxに移行する前は、何はともかくWineをインストールして、と考えていたのだが、未だにWineをインストールするべき理由が思いつかない。ほとんどのWindows用ソフトウェアは、自由なソフトウェアで代替できる。これは予想していなかった事態である。

いまWaylandが熱い

Waylandは、将来的に、Xを代替する目的で開発されている、相当に野心的なソフトウェアである。

今、GNU/LinuxでまともにGUIのソフトウェアをつくろうとしたら、Xは直接使わない。GTK+やQtなどといったライブラリを使う。これらのライブラリは、様々なバックエンドを持っている。たとえば、SVGやHTML5バックエンドなどもある。だから、これらのライブラリを利用していれば、Waylandへの移行は、理想的には、再コンパイルだけで済むはずである。とはいえ、現実には、再コンパイルだけで済むことはないだろう。

XからWaylandに移行するためには、Waylandが使われるようにならなければならない。しかし、既存のXバックエンドのソフトウェアが動かないのでは意味がない。そこで今考えられているのは、XとWaylandを両方動かすというものである。

Waylandが裏で必要に応じてX Serverを動かすのだ。ここしばらくの更新内容の簡潔なまとめが上がっている。

[Phoronix] X/Wayland Is Coming Along Nicely, But Work Is Left

色々と今の状況を観察するに、次のGPUはIntelという選択肢が、案外現実的に思えてくる。つまり、もはや外部のグラフィックカードを取り付ける必要はなくなるのだ。

IntelはnVidiaやAMDよりよっぽどLinuxカーネルに貢献している。今のKMSやDRMだって、Intelの貢献が大きい。残念ながら、Sandy Bridgeのグラフィックのパフォーマンスは、nVidiaやAMDのグラフィックカードの最底辺と比較できるレベルである。しかし、それも将来、変わっていくのではないか。今のミドルクラスのグラフィックカード程度のパフォーマンスが、CPUとGPUの統合チップで提供されるならば、もはや外部のグラフィックカードを使う理由は薄れる。

ただし、もう5年か10年はかかると思う。

しかし、サウンドカードが廃れ、グラフィックカードも廃れる兆しが見える今、次に廃れるものはなんだろうか。

GCC 4.8のビルドはデフォルトでC++になるかも

Diego Novillo - Switching to C++ by default in 4.8

GCC開発者の一人でGooglerのDiego Novilloは、今月の3日にMLで、GCC 4.8のビルドをデフォルトでC++にしようと提案している。これは、GCC自体をビルドする際のデフォルトの言語をC++にするという意味である。GCCがコードをデフォルトでC++としてコンパイルするのではない。現在のGCCビルドシステムの言語モードをC++に切り替えるのは非常に簡単で、必要なのはテストだけだという。

2011年、GCCの実装で、C++を使用可能にする採択が受け入られている。GCC自体のコンパイルをデフォルトでC++にすることは、GCC実装におけるC++の利用を更に加速するだろう。

GCCにおけるC++利用のコーディング規約は、目下作成中である。コーディング規約が完成する前に、GCCのビルドをC++に移行することは意義がある。

GCCの実装でC++を使うというのは、だいぶ感慨深いものがある。とうとうC++もそこまで枯れてきたということだ。

GCCの実装がC++になると、マイナーな環境におけるGCCのコンパイルが、少し難しくなる。というのも、C言語はいまだに、ネイティブコードを吐く言語としては最大の移植性を誇っている。ほぼすべてのコンピューターシステムに、GCCをコンパイルできるCコンパイラーが存在する。そのコンパイラーでGCCをコンパイルして、さらに出来上がったGCCでもう一度GCCをコンパイルすれば、そのシステム上での、GCCによるネイティブGCCをビルドできる。正しく動作する自分自身をコンパイルすることを、セルフホストと言い、コンパイラーの完成度をはかる上でひとつの目安となっている。clangは2010年にセルフホストを達成した

GCCのビルドシステムにおけるブートストラップは、3ステージある。その概要は、以下のページで解説されている。

Installing GCC: Building - GNU Project - Free Software Foundation (FSF)

  • システム上のCコンパイラーを使い、GCCのビルドに必要なツールをビルドする。
  • ステージ1 GCCをビルドする。
  • ステージ1 GCCを使い、ステージ2 GCCをビルドする。
  • ステージ2 GCCを使い、ステージ3 GCCをビルドする。
  • ステージ2とステージ3を比較して、一致することを確かめる。
  • ステージ3 GCCでランタイムライブラリをビルドする。

これが、C++コンパイラーに変わる。問題は、おそらく相当な制限がかかるであろうGCCにおけるC++利用のコーディング規約であっても、将来のGCCをコンパイルできる、十分に規格準拠なC++コンパイラーというのは、数えるほどしかないということだ。いま思いつくのは、GCC、EDG、Clang、あまり列挙したくないがひょっとしたらMSVC。とすると、今後のC++を使ったGCCを既存のあらゆるシステム上でビルドする際には、まずC++で書かれたGCCを正しくコンパイルできるCで書かれたバージョンのGCCが重要になってくる。

ブートストラップ問題はややこしい。おそらく、ブートストラップ問題から一番離れている言語は、LISP系の言語であろう。Wikipediaによると、史上初のセルフホスト可能なコンパイラーは、LISPコンパイラーだという。

Bootstrapping (compilers) - Wikipedia, the free encyclopedia

いつかSchemeを完全に理解したいものだ。少なくとも、セルフホスト可能なサブセットのLISPを完全に理解することは可能である。セルフホスト可能なサブセットのC++やJavaScript(ただし、evalはチート)を完全に理解するのは不可能だ。

2012-04-05

やはりclangも規格の範囲内だったか

コード

static_assert( false, u8"テスト" ) ;

結果

error: static_assert failed u8"\343\203\206\343\202\271\343\203\210"
    static_assert( false , u8"テスト" ) ;
    ^              ~~~~~

規格でもBasic Source Character Set外の文字を扱わなくても良いとされているので、規格準拠の動作なのだが。でもせっかくソースコードを表示してくれるのだから、そのまま表示してくれたならば、非ラテンアルファベット圏の人間にもやさしいのに。

詰んだかも

GNU/Linuxに移行してより、あらゆることが新鮮で充実した日々を送っている。急に身長が伸びたりはしないし、彼女もできないし、宝くじにも当たらないが、幸せだ。

ただ、どうも、道を誤った感がある。

ここ数年というもの、C++の参考書の執筆に専念してきた。規格書の読解、日本語による説明、ひとつの機能だけを使った完結なサンプルコード、そんなことを考えて日々を送っていた。その結果、C++の規格の知識は大幅に増えたが、その他の技術からは遠ざかってしまった。向上したのは、英語の読み書き能力とドキュメントを読む力だけだ。一部の能力だけに特化した結果、汎用的なプログラマーとしての力は、むしろ衰えてしまった。

新しい環境で新鮮な気持ちになり、久しぶりに色々とコードが書きたくなった。驚いたのは、ドキュメントを読む力が格段に上がっていて、全く馴染みのない環境やライブラリでも、楽に学べるようになっていることだ。問題は、コードを書く力が落ちているのだ。

何しろ、この数年、コンパイラーに頼れない生活を送ってきたのだ。たしかに、gccはC++11のほとんどの機能をサポートしているが、まだまだバグが多く、コンパイルが通るといっても、気休めにしかならない。正しいC++11のサンプルコードを書くには、いちいち規格にあたって確認しなければならない。そういう生活を送ってきたので、一行書くたびに、規格やライブラリのドキュメントを参照して、本当に間違いがないかどうか確認する癖がでてしまう。これは困った。

やはり、結論としては、フルタイムでプログラミングの参考書を書くべきではなかったということだ。参考書の執筆という作業は、本物のプログラミングとはまた違った地味な能力を要求される。そのため、本を執筆ばかりしていると、本物のプログラミングから離れてしまう。

某信徒だって、今はプログラミングの参考書ではなく、専ら数学書を書いていると聞く。それから、あの大御所の大先生は、果たしてご存命のうちに全十二章からなる大著を完成させられるのか、おぼつかない。

詰んだか。詰んだのか。あまりにも知識を特化しすぎたのか。しかし、どうしろというのだ。こうでもしなければC++のコア言語の詳細を解説する参考書は書けないのだ。

ともかく、C++の参考書を書き上げよう。GNU/Linuxへの移行で、gccより優れたC++11コンパイラー、clangを手に入れたので、執筆がはかどる。それにしても不毛だ。

iconvがクソすぎる

思うに、私が最初のOSに不自由なWindowsを選んだのは正解だったかもしれない。すくなくとも、Win32 APIはPOSIXよりはるかに使いやすい。

問題はiconvだ。一体どこの糞が何をキメながら設計したらこうなったんだ。狂っているにも程がある。

size_t iconv (iconv_t cd,
              const char ** inbuf, size_t * inbytesleft,
              char ** outbuf, size_t * outbytesleft) ;

ポインターのポインターであるには理由がある。iconvは、すべて書き換えるからだ。ポインターを書き換えるのでポインターへのポインターを要求する。当然だ。当然であって欲しくないが当然だ。

なんでそんなに馬鹿げた副作用を持ち込むんだ。それでは必ずlvalueを渡さなければならないし、大抵の場合、もとの値を保持しておきたいから、オブジェクトのコピーを作って渡さなければならない。

簡単なラップを書けば、それ以降この異常な副作用に悩まされることはない。しかし、なぜ設計がこうなっているんだ。もちろん、今の私はポインター演算ぐらい完全に理解しているが、だからといって直接使いたいとは思わない。

Win32 APIは少なくとも、そんな馬鹿げた副作用を持ち込むことはなかったし、読むオブジェクトと書くオブジェクトは明確に分けている。たとえば、Win32 APIの流儀に従うと、inbytesleftやoutbytesleftは、それぞれconst size_tとsize_t *の2つの引数に分割し、読み込みと書き込みを分離する。

私がCを学んでいたとき、Cの標準ライブラリがあまりにも使いづらかったので、すぐにWin32 APIに移行した。また、C言語自体が気に食わなかったので、すぐにC++に移行した。思うに、これは正解だった。おかげで私は、POSIXの汚い設計に苦しめられることはなかった。

ちなみに、今のUbuntuのiconvパッチを当てたunzipにはバグがある。シフトJISやCP932でエンコードされた半角カナが多い文字列をUTF-8に変換することができない。なぜならば、バッファの確保が単に元の文字列のオクテット数の二倍になっているだけだからだ。半角カナは、UTF-8でエンコードすると3オクテット必要である。

どうも、unzipは変換元文字列の6倍のバッファを確保しているらしい。Twitter / @mattn_jp: んーunzipで領域2倍しか取ってないっての話、ちゃ ...

しかし、現在のUbuntu 11.10や12.04のレポジトリのソースコードのパッチを読むと、

Ubuntu -- Details of package unzip in precise

やはり2倍の確保になっている。

2012-04-04

GNU/Linuxの方がWindowsより日本語サポートが優れている

今や、GNU/Linuxの方が不自由なWindowsより日本語サポートが優れている。これは純然たる事実である。

私は、UIが日本語化の質を論じているのではない。私はUIの言語を英語にしているので、UIの日本語の質についてはわからない。ただ、2012年となった今では、GNU/Linux/Xの環境の方が、圧倒的に日本語を扱う環境が優れていると考えているのだ。

まず、現行のまともなディストリは、文字エンコードをデフォルトでUTF-8にしている。このため、不自由なWindowsにおける、カオスな大量のマルチバイト文字コード混在環境の問題は存在しない。確かに、不自由なWindowsのネイティブの文字エンコードはUTF-16だが、下位互換性を保証するために、既存のマルチバイト文字をすべて継続してサポートしているために、未だにカオスな状況になっている。多くのプログラムは、嘆かわしいことに、いまだにANSI版のWin32 APIを使用しているのだ。

もちろん、我々は未だにテキストファイルや、zipなどの文字コードが規定されていないアーカイブ形式のファイルで、Shift JISやEUC-JPやISO-2022-JPやらJISやらの、既存の文字コードを扱わなければならない。しかし、そういう問題は、OS側でなくても対処できるので問題ない。実際、Ubuntuのunzipは文字コードを指定するオプションが追加されている。素晴らしい。

そして、ターミナルだ。UbuntuのデフォルトのGNOMEターミナルエミュレーターは、UTF-8ロケールなので、日本語も描画できる。iBusを使えば、なんの煩わしい設定やへんてこなプログラムの起動なしに日本語入力もできる。vimでさえ日本語入力を受け取る。

不自由なWindowsはどうか。いまだに不自由なWindowsのコンソールはカオスなマルチバイト混在環境を引き継いでいる。UTF-8ロケールにはできない。

もちろん、不自由なWindowsにも利点はある。既存のプログラムとの互換性が完璧なのだ。こればかりはどんなにMicrosoftを嫌っている人間であろうとも、認めざるを得ない。Microsoftはこの殺伐としたソフトウェア業界で、最も下位互換性を最優先で守る企業である。Microsoftが互換性と言ったとき、それはバイナリ互換性を意味する。不自由なWindowsのバージョンがひとつ上がったぐらいで動かなくなるソフトウェアは、相当馬鹿なことをしているはずである。ただし、不自由なWindows下においては、自由なソフトウェアの文化がないので、なかなかユーザーの目にはわからないのだが。

GNU/Linuxにおいては、バイナリ互換性などほとんど守られていない。もともと、環境ごとにディレクトリ構造が異なっているのだから、バイナリ互換性など考えるだけ無駄なのだ。自由なソフトウェア文化の元では、バイナリ互換性など些細な問題なのだ。ただ、これはユーザーにとってもあまり好ましい状況ではない。たとえば、ドライバーはカーネルのヘッダーに依存するので、安全を期すためには、常にカーネルと同じヘッダー、同じコンパイラを使ってコンパイルしなければならない。Linuxでは、多くのドライバーはカーネルごとコンパイルして内蔵する形になっているので、これでもいいのだが、やはりドライバーを外部から読み込みたい需要も常にある。そして、カーネルを歳コンパイルしたときに、外部モジュールのドライバーの再コンパイルを忘れて問題を引き起こす。

こと、GNU/Linuxのドライバーのバイナリ互換性に関しては、FreeBSDの方がよっぽどましなのである。FreeBSDはわざわざLinux互換レイヤーを設けてまで、GNU/Linux用のバイナリのほとんどをそのまま実行できるようにしている。これには、ドライバも含まれる。

話がそれた。不自由なWindowsの互換性における取り組みは、たしかに認めざるを得ない。不自由なWindows環境では、もはや、ソースコードの失われたプロプライエタリなバイナリが山ほどある。Microsoftとしては、この過去の資産をぶち壊すわけには行かないのだ。

ただし、この互換性は、プログラマーを怠惰にさせる。問題を本当に解決する方法、Unicodeへの移行を遅らせる。いまだに、多くの不自由なWindows用の不自由なプログラムは、Unicodeを使っていない。長期的に考えて、ソフトウェアは自由であるべきなのだ。自由なソフトウェアであれば、ソースコードが公開されているので、そのソフトウェアに価値がある限り、ソースコードは誰かが保存している。そのため、バイナリ互換性については、それほど真剣に考えなくても良いのだ。また、互換性が失われたとしても、ソースコードが公開されていれば、修正も可能だ。

不自由なWindowsは、マルチバイトサポートとANSI版Win32 APIのサポートを打ち切る勇気を持つべきである。たしかに、移行は痛みを伴うが、長期的な利点が大きい。もちろん、これは理想論であり、実際には実行できない。何故ならば、不自由なWindowsで動くソフトウェアは、ほとんどすべて不自由なソフトウェアだからだ。

GNU/Linuxは、UTF-8への痛みを伴う変更をやり遂げた。これは、ソフトウェアが自由だからである。誰でも、自由にソフトウェアを検証して改変し(Freedom 1)、改変版を再配布できる(Freedom 3)からである。そして、その恩恵は皆が享受できる。2012年の今現在、GNU/Linuxは不自由なWindowsに大勝利している。

OS外の状況も、近年大幅に改善された。オープンソースライセンスのIPAフォントのおかげで、我々は高品質なフォントを手に入れた。GTK+環境におけるフォント描画の質は、不自由なWindowsのClearTypeを大幅に上回っている。オープンソースライセンスのMozcのおかげで、日本語入力も改善された。自由ではないのが残念だが、オープンソースライセンスであるだけ、プロプライエタリよりはましだ。

ああ、哀れ不自由なWindowsよ。汝、いつまで下位互換性という大義のために、カオスな状況を容認するのだ。未来はないぞ。

GNU/Linuxには誘惑が多すぎる

さて、とりあえずGNU/Linux下でC++の参考書を執筆する環境はほぼ整えた。またvimを習得していないが、さしあたってはgeditでもいいだろう。ゆくゆくはvimを習得すべきだと思う。

しかし、GNU/Linuxには誘惑が多すぎるのだ。本の虫: 危険な誘惑もそうだし、なにより、プログラミングの環境に関しては、不自由なWindowsより圧倒的に恵まれているのだ。

たとえば、schemeの処理系に恵まれている。私は過去に二度、schemeを学ぼうと決意したことがあるのだが、ついに果たせなかった。SICPは買っているのだが、まだ全然読んでいない。理由の一つに、不自由なWindowsで動くscheme処理系が、今ひとつ貧弱だというものがある。コンソールも貧弱でひたすら苦行だ。

ところが、GNU/Linuxにおいては、scheme処理系は幅広い選択肢がある。しかも、ターミナルエミュレーターが素晴らしい。これなら楽しく学べるかもしれない。

問題は、そんなことをしているとC++の参考書の執筆に差し支える。悩ましい誘惑だ。

clangは現在最強のC++コンパイラー

clangを検証した結果、現在入手できるC++コンパイラーの中では、最強だということが判明した。C++11の主要な機能はほぼすべて網羅している。さらに、規格準拠度では、gccよりも信頼できる。

あとは、標準ライブラリだ。clangはgccとABI互換を持っているので、gccのstdlibc++とABIライブラリが使える。ただし、llvmで開発中の標準ライブラリがある。libc++だ。

"libc++" C++ Standard Library

ただし、まだドキュメントが不足している。それに、これだけでは使えない。この下に更に、ABIライブラリが必要になる。これも、llvmで開発してる。

"libc++abi" C++ Standard Library Support

こちらはさらに時期尚早だ。

このふたつが完成すれば、clangは完全になるだろう。いまclangへの移行を阻むのは、過去の資産とgccの膨大なターゲットアーキテクチャぐらいなものか。ただし、clangには未来を感じる

ところで、いまclangを不自由なMSVCに対応させるべく頑張っている開発者の怨嗟の声が聞こえてくる。次の不自由なMSVC11も、やはり悲惨な出来らしい。もはや、不自由なWindowsには未来がないのでどうでもいいのだが。

ちょっと見ないうちにBoostのビルドが楽になっている

最近、標準ライブラリにほしい物はあらかた入ってしまったし、Boostよりも設計が洗練されているので、Boostの最近の変更はあまり追いかけていなかった。

そんなわけで、今Boostを確認してみたところ、Windows、UNIXライク両方の環境で、ビルドがだいぶ楽になっている。

また、ライブラリにも面白そうなものが多数追加されている。やれやれ、本なんか書いている場合じゃなかった。

しかしこれは悩ましい問題だ。本を執筆しようと今の規格を深く検証し始めると、最先端の動向に取り遅れる。まあ、Boostをただ使うのは簡単だからいいのだが、やはり実装の詳細も気になる。

clangを使うべし

tupleのネスト

template parameter packを固定長のtemplate parameter listに展開するのは、gcc 4.6では未実装である。ただ、gccのエラーメッセージが、これを正しく判定できない場合がある。

template < typename T1, typename T2 >
struct A { } ;

template < typename T, typename ... Types >
void f( T, Types ... )
{
    A< T, Types ... > a ;
}

int main(int argc, char* argv[])
{
    f( 0, 0 ) ;
}

この場合は正しく未実装だというコンパイルエラーになるが。

template < typename T1, typename T2 >
struct A { } ;

template < typename T, typename ... Types >
void f( Types ... )
{
    A< Types ... > a ;
}
 
int main(int argc, char* argv[])
{
    f( 0, 0 ) ; 
}

この場合は、一見して訳のわからないエラーメッセージが吐き出される。

4.7では確か実装されていたはずだが、なんにせよ、今やC++コンパイラーはclangを使うべきである。gccの栄光は過去のものになった。

2012-04-03

危険な誘惑

というわけで、私がGNU/Linuxに改宗してから10日たった。この間、新しい環境に慣れるため、色々と試している。必要なソフトウェアをインストールしたり、気に入らない設定を変更したりなどだ。本当に自分の好みに合うように調整しようとしたならば、結局、設定ファイルを手動でいじったり、CLIのツールを使う必要がある。これは、私にとっては、さほど問題ではない。私は自力で調べて解決するのが好きだし、英語も読めるのでドキュメントにも困らない。しかし、やはりこの状況は、一般人がデスクトップOSとして使うには、少々難しいことは否めない。

さて、ここで危険な誘惑がある。それは、現状に満足できないという状況だ。たとえば、今使っているソフトウェアは、最新のバージョンではない。たとえば、今この文章を入力するのに使っているMozcのバージョンは1.1.773.102だが、最新の安定板のバージョンは1.3.975.102である。このブログに投稿するために使っているブラウザー、Chromiumのバージョンは17.0.963.79だが、すでに最新の安定板は18.0.1025.142である。

Ubuntuのアップデート方針は、緊急を要するセキュリティ上のアップデートでもない限り、半年ごとのバージョンアップ時にまとめてアップデートにするというものである。

主要なソフトウェアはきちんとメンテされていて、半年おきにアップデートされるから、特に問題はないのだが、やはり、最新のソフトウェアにも憧れる。もちろん、手動でコンパイルすることはできる。ただし、手動で入れたソフトウェアは、手動で管理しなければならない。バージョンアップも手動だ。これは非常に面倒だ。

mozcやChromiumといった有名なソフトウェアであれば、公式レポジトリ外でビルドを提供しているPPAがあるから、それを追加すればいいのだが、やはり、そういうのではなしに、公式レポジトリさえ使っていれば、すべてのソフトウェアが常に最新になっているような状態にも憧れる。

となると、ArchやGentooやFuntooのようなディストリに目が行くわけであるが・・・これは非常に危険な誘惑である。ややもすると、コンピューターを使うのではなく、コンピューターを管理することに喜びを見出すようになってしまうからだ。

xkcd: Cautionary

Linux: 実際にあった話:第一週

もしもし、あたしあたし、姪だけど。新しいパソコン手に入れたんだけどさ、Windowsとか入れたくないのよ。Linuxとかいうやつのインストール手伝ってくれない?

いいよ

第二週

XORGが壊れたって。XORGって何? どうすればいいの
「manページ教えるよ」

第六週

autoconfigがうまくいかないんでUbuntuからDebianに変えることにする
「えっ」
Gentooにするかも
「やばい」

第十二週

「最近電話に出ないけど」

寝らんない。カーネル、コンパイル、しなきゃ。

「手遅れか」

親に告ぐ:誰か他人に教わる前に、子供にLinuxを教えるべきである。

Boostに対する感覚

WindowsからGNU/Linuxに改宗した身として、WindowsとGNU/LinuxではBoostに対する感覚が違うことに気がついた。ここで問題にするのは、threadとかfilesystemとかの環境に依存した低級なライブラリの話である。regexなどの環境にあまり依存しない高級なライブラリは除く。

Windowsユーザーから見ると、BoostはWin32 APIの極めて限定的なサブセットをC++でラップしたライブラリである。WindowsでC++が必要な本物のプログラムが書きたければ、やはりWin32 APIを使わなければならない。どうせWin32 APIを直接使うなら、なぜ機能が削減されたBoostなど使う必要があるのか疑問だ。そのため、Windowsユーザーだった私は、Boostの低級なライブラリには興味を示せないでいた。移植性はあるだろうが、それ以外には魅力がない。STLに入ったライブラリは追いかけていたが、Boostまでは気にかける価値を感じなかったのだ。

ところが、GNU/Linuxユーザーから見ると、Boostは極めて高機能なライブラリである。もうこれなしではC++プログラミングなどできない。BoostはPOSIXの汚い設計を隠してくれるし、環境ごとの差異も隠してくれる。素晴らしいライブラリだ。

どうも、プログラマーとしてどっちが恵まれている環境なのか判断しかねる。Windowsは公式でスタイルが統一された高機能なAPIを多数提供している。GNU/LinuxがXを加えた環境で提供しているのは、機能は少ないしスタイルはバラバラで暗号的なAPIだ。ただし、今はWindowsでC++プログラミングなど冗談もいいところだ。WindowsではまともなC++コンパイラーは期待できない。GNU/Linuxの方が圧倒的にC++に恵まれている。

ああ、Windowsのように統一された低級から高級まで幅広くカバーするリッチなAPIに、GNU/Linuxの自由なソフトウェア文化と便利なパッケージシステムを兼ね備えたような環境が欲しい。世の中うまく行かないものだ。

POSIX使えねー

Win32 APIに慣れた身としては、POSIXが使えなさ過ぎて困る。

まず、あまりにも機能が少ない。もちろん、POSIXは環境が用意するべき最低限の保証なのだから、こういうものなのかもしれないが、低機能は低機能だ。さらに、低級だ。

そもそも、APIの設計からしてひどい。まず、関数名が暗号のように短い。Windowsのやり方DoSomethingOrOtherExW(多数の引数)が最適とは言わないが、すくなくとも、Win32 APIの方が、どういう意味なのかはわかりやすい。関数名が十分に長いので検索もしやすい。さらに統一されたドキュメントもある。今の時代、関数名が長すぎて困るということはないのだ。当時のCコンパイラーが認識する識別子の長さに関係していたのか、あるいは単にUNIX文化が略語を好むのか。

POSIXのドキュメントと格闘した挙句、結局、ほとんどの場合、Boostにもっとマシなライブラリがあるから、Boostを使ったほうがはるかに快適だということに気がついた。不思議だ。Win32 API環境でのプログラミングで、このように思ったことはない。むしろ、ネイティブのWin32 APIに比較してなんとBoostは低機能なのだろうと思ったほどだ。ところが、POSIX環境と比較すると、Boostは高機能すぎて泣けてくる。私はネイティブなやり方が好きである。ところが、POSIXの環境にきて、そのネイティブな方法が、あまりにも貧弱だということに困惑している。これは一体どういうことだ。UNIX環境ではプログラミングの整備が遅れているのか。

必然というべきなのか、UNIX環境では、多くのサードパーティによるライブラリがある。そして多くの場合、使いやすい設計と、他の環境への移植性を謳っている。

今になって気がついたのだが、Boostというのは、主にUNIX向けのライブラリなのではなかろうか。GNU/Linux環境におけるBoostは非常にありがたい存在だ。しかし、Windows環境では、それほどありがたいとも思わない。単にWin32 APIの一部の機能をC++でラップしたぐらいにしか思わない。

あるいは、やはり文化の違いなのかもしれない。Windowsではありとあらゆる便利な統一されたAPIを公式に提供しているが、UNIX環境では、そういうものはユーザー側のライブラリに任せる文化なのか。

一昔前、DirectXかOpenGLを学ぼうと考えていて色々と調べていたとき、DirectXは高機能で便利だが、OpenGLは低機能すぎるという感想を持った。なにしろ、OpenGLには文字描画さえないのだ。これも何か関係があるのだろうか。GNU/Linuxで動くOpenGLをバックエンド利用した高機能な文字列描画ライブラリは山ほどある。

そもそも、Linuxカーネルと、Win32サブシステムを含めたWindows全体を比較するのが間違っているのだろう。とはいえ、やはり統一された高機能なAPIがないのはつらい。

2012-04-02

Cコンパイラーの比較

Willus.com's 2011 Win32/64 C Compiler Benchmarks

これはすごい。Windows上で動くCコンパイラーを様々な面から比較している。ベンチマークに使ったソースコードは、すべて純粋なC言語である。アセンブリやインラインアセンブリは無効にしてある。これは純粋なCコンパイラーの性能を図るためだからだ。

まず、コンパイラー自体の問題がある。Intelのコンパイラーは、デブすぎるにもほどがある。Intelのパッケージだけで1.6GiBもあるのに、これにさらにVisual Studioを別途インストールしなければ使えない。さらに、Intelのインストーラーは40個以上もの別個のソフトウェアをインストールする。それぞれ、バッチスクリプト用にPATHを追加するので、PATH環境変数に何十個も追加されることになる。Windows 7では、インストール済みのソフトウェアのソートができるが、この時ほど便利だと思ったことはない。インストールすると10GiBぐらいのディスク容量を食う。ちなみに、Intelのコンパイラーをアンインストールするには、リアルで10分もかかった。これと対極にあるのはTCCだ。小さい!

次に、いくつかのコンパイラーは、巨大な静的配列のコンパイルに問題を抱えている。特に、Digital MarsやMSVCは1990年代に生きているらしく、64KiB以上の文字列リテラルが静的に初期化できない。Digital Marsは3MiB以上もの文字配列を使っているコードをコンパイルしようとするとメモリが不足する。コンパイラーは32bitコードだから、2GiBのメモリが使えるはずであるのにも関わらずだ。

今回試したコンパイラーでC99をサポートしているのは、gccとIntelだけなので、x264のテストはこのコンパイラーでしか行えない。

実行時のパフォーマンスが一番良かったのは、Intelのコンパイラーである。ただし、2002年と比べて、Intelの優位性は下がっている。自動的な並列化は、Intelの圧勝となっている。gccはこの点で大きく遅れている。gccの自動的な並列化は、並列化させるための意図的なコードを書いてようやく発現させられるレベルである。また、プロファイルによる最適化は、Intelでは明白なパフォーマンスの向上がある。gccでは、パフォーマンス向上はほとんどない。また、64bitコードへのコンパイルは、全体的にパフォーマンスを上げる。ただし、MSVCでは何故かパフォーマンスが下がる場合があるのだが。

ちょっとした謎:ata1: SRST failed (errno=-16)

今使っているGNU/Linuxがサスペンドから復帰するときに、一瞬だけ表示されるメッセージがある。なにやらSRST failedとなっている。気になるので、dmesgをgrepしてみた。

[46838.852006] ata1: link is slow to respond, please be patient (ready=0)
[46843.388006] ata1: SRST failed (errno=-16)
[46844.368036] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

ふーむ。特にサスペンドからの復帰が遅いと感じることはない。nVidiaのKMSに対応していないプロプライエタリなドライバを利用しているので画面の描画が一瞬乱れる問題があるが、ここでは関係ない。SATAにはHDDひとつしか繋げていないので、これはHDDであるが、HDDの利用には特に問題があるようには感じられない。はて。

このメッセージについてぐぐっても、特に情報らしい情報もなかった。ただ、SST failedを繰り返した挙句HDDが認識されないという症状がいくつかあるが気になる。

ちなみに、このメッセージはサスペンドからの復帰の時のみ出ているようだ。ブート時には見当たらない。まあ、特に今は問題になっていないようだが・・・はて。

たまには古いコンピューターでも

Macintosh 512Kでお絵かきをする動画。

たった一枚の画像を保存するのに何枚もFDの交換が必要だ。もちろん、読み込む際にも交換しなければならない。

Ubuntuを最低なスペックで動かす動画。

詳細はDmitry Grinbergを参照。

CPUはATmega1284pである。なんと8bit。メモリはSDRAMを使った。メモリのリフレッシュも自前で実装している。ただしCPUが非常に遅いため、メモリの速度は300KB/sといったところである。ストレージには1GBのSDフラッシュを用いている。

ただし、このCPU向けのコンパイラーがないので、ARMエミューレーターを実装することによりGNU/Linuxを動かしている。

もちろん、あまり早いとは言えない。ブートしてbashが表示されるまで二時間、Ubuntuが完全に起動するまで、その後さらに四時間かかる。Xを起動するとなるとそりゃもう長い時間がかかる。コマンドを入力して結果を見るのは、一分ぐらいで済むらしい。

btrfsの圧縮規格をめぐる争い

btrfsという、現在開発中のファイルシステムがある。これは、既存のextの系譜に変わるべく開発されているファイルシステムである。ext系列のファイルシステムはすでに十分な実績があるが、いかんせん土台とする技術が古い。これは、extのオリジナル作者であるTheodore Ts'oも認めている事実である。つまり、抜本的な革新のためには、全く新しいファイルシステムを開発する必要がある。

そこでbtrfsだ。btrfsは、近代的な技術を使った新しいファイルシステムである。内部の実装はさておくとしても、ユーザーにとっても便利な近代的な機能を多数提供している。スナップショットやサブボリュームのサポート、ファイルシステムによるRAIDや圧縮のサポート、オンラインデフラグ、オンライン動的ディスクの追加と削除、さらには、将来的には暗号化などもサポートする予定である。

これらの機能は、従来、ファイルシステムの外側に実装されていた。しかし、やはりファイルシステムに直接実装した方がいい。

ただし、btrfsはまだ、実際に使うには早すぎる。たとえば、ファイルシステムのチェックがまだ未完成だ。計画によれば、オンライン、オフライン両方のファイルシステムチェックをサポートするらしい。聞くところによると、オフラインチェックの実装は、いまオラクル内部でテスト中であるとか。オフラインチェックは当然あるべき機能であるが、オンラインチェックも欲しい。もはや、HDDはその容量からして、全域にオフラインチェックをかけるのは現実的ではない。

さて、圧縮である。昔、ファイルシステムによる通過的な圧縮のサポートといえば、容量の節約という意味が大きかった。しかし現代では、容量ではなく、パフォーマンス上の理由もある。HDDのパフォーマンスは、実はそれほど変わっていないのだ。確かに、高密度化により、ある程度シーケンシャルな読み書きは速くなったが、劇的な性能向上というわけではない。シーク時間は今も昔も10ミリ秒ぐらいかかるので、ランダムアクセスは遅い。そこで、圧縮により読み書きのサイズを削減してやれば、パフォーマンスの向上になる。

問題は、圧縮によりCPU時間を浪費してしまうと、せっかくのパフォーマンス向上が台無しになってしまう。CPU時間は依然として貴重であり、ディスクアクセスにCPUが多大に浪費されることがあってはならない。そこで、圧縮アルゴリズムは、高速でなければならない。

現在、btrfsに公式に取り込まれている圧縮アルゴリズムは、gzipaとLZOである。しかし、さらにsnappyと、lz4が候補に上がっている。

どうも、btrfsの圧縮アルゴリズムは戦国時代のようである。どれが一番優れているのか判断するためには、もうしばらく時間が必要である。

2012-04-01

自由なドキュメント

自由なソフトウェアの力は素晴らしい。とすれば、自由の威力はドキュメントにも及ぶはずだ。現在、ほとんどの紙書籍は不自由である。Web上にホストされている検索可能なドキュメントの多くは、後述する通り、複製や公衆送信や翻案を暗黙に許しているわけだが、たいてい、明示的な許諾が与えられていない。そのため、Web上のドキュメントは真に自由なのではなく、ある程度は自由のように振る舞うことを黙認されているだけである。この現状は不自由である。

いかに現行法が実情にそぐわないものであったとしても、今を生きる我々は現行法に従わねばならぬ。コピーレフトなライセンスは、著作権法を利用した賢いハックである。著作権法は、著作物の利用の独占を許している。本来、独占は禁止されているが、著作権法や特許法や商標法などは、独占を実現することが目的なので、独占を禁止する法律の適用外である。独占者たる著作者は、著作物の利用許諾を与えるに際し、条件を課す。例えば、金線による利用料の支払いだ。コピーレフトなライセンスは、この条件に、派生物はこの同じライセンスに従うという条件を課した。このため、自由なライセンスの派生物も、自由であることが保証されるのだ。

さて、自由なライセンスを利用した自由なソフトウェアは成功した。今や、自由なソフトウェアの質は、競合する不自由なソフトウェアを完全に凌駕している。我々はここでさらに一歩を進めて、自由なドキュメントについて真剣に考えるべきである。

今、この2012年において、ある事柄について調べたいとすれば、一体どうするだろうか。近所の本屋に行って不自由なドキュメントを探すだろうか。近所の図書館に行って不自由だが無料で閲覧できるドキュメントを探すだろうか。否、我々はインターネットの検索サイトで検索を行う。もはや、検索できない情報や著作物というものは、存在しないも同義なのだ。

ところで、この検索が機能するためには、Webサイト上の著作物は、著作権法で独占を認められたいくつかの権利の無断利用を黙認しなければならぬ。検索サイトは著作物を複製し、検索しやすい形に翻案し、さらに検索した者に対して、概要が見られるように翻案して公衆送信しなければならない。しかるに、Web上の多くの著作物は、明示的な許諾を与えていない。いまや、Web上の検索サービスの有用性を疑うものはいないにも関わらず、許諾がない。故に、これらの著作物は不自由な著作物である。

もちろん、これは現行法があまりにも実情とかけ離れているために起こる問題である。そのため、根本的な解決には、法律を改正しなければならない。日本国では、日々新たに生ずる、新しい状況での著作物の妥当な無断利用を許すべく、正確に言うと、妥当な場合には著作権が制限されて権利が及ばないように、常に変更されている。日本の著作権法は、実に改正が多い。何故ならば、日本ではfair useの概念を認めておらず、すべて明示的な著作権の制限という形で列挙しているからだ。もっとも、fair useとて、有能な弁護士を雇う権利だと揶揄されるように、万能ではない。これは、現行の著作権法が根本的に実情に合っていないために起こる問題である。

とはいえ、先に述べた通り、我々は現行法に従わなければならぬ。しかし、自由なソフトウェアが自然なように、自由なドキュメントもまた自然なのだ。従来の法律では、著作権の無断利用となる検索サービスが一般化したことは、自然なことなのだ。自由は自然で当然だからだ。

ここに、自由なドキュメントのためのライセンスの存在意義がでてくる。すべてのドキュメントは、本来自由であるべきなのだ。我々は自由なドキュメントを明示的に自由であると宣言し、不自由なドキュメントの所有を拒絶するべきである。不自由なドキュメントには、もはや所有する価値がない。不自由なドキュメントは反社会的かつ半倫理的で、人道上の罪である。

これをもってこれを考えるに、今私が執筆しているC++の参考書は、自由なドキュメントとして公開するべきだろう。ただし、私は商業的利益を放擲するわけではない。自由かつ商業的利益も得られる方法を模索する。

自由なドキュメントというと、WikiやGitHubのような仕組みの上でバザール型の執筆をするという案がある。しかし、おそらくこれは、参考書の執筆にはうまく働かないだろう。すでにひと通りのまとまった自由な参考書が存在していて、それを土台としてWikiで編集するならばうまく行くだろうが、無から創り上げるのはうまく行かないだろう。やはり、誰かが、十分なコミュニティが形成されるまでの間、孤独に耐えて最初の土台を作らなければならぬのだ。

ともかく、C++の参考書の完成が先決だ。私の現在の参考書執筆の環境は、自由なソフトウェアと許諾的ソフトウェアライセンスのclangにより、飛躍的に向上した。もっと早く不自由なソフトフェア環境から脱却していなかったのが悔やまれる。

参考:Why Free Software needs Free Documentation - GNU Project - Free Software Foundation (FSF)