2012-03-30

善のため、プロプライエタリなドライバーを根絶せよ

[Phoronix] Qualcomm Calls To "Kill All Proprietary Drivers For Good"
[Phoronix] Qualcomm Calls To "Kill All Proprietary Drivers For Good"
Let's Kill All Proprietary Drivers For Good

来週開かれる6th annual Linux Foundation Collaboration Summitで、Qualcommのプレゼンする内容は、「善のため、プロプライエタリなドライバを根絶せよ」というものだ。あの悪名高いQualcommが、ここまで姿勢を変えたというのは、なかなか感慨深いものがある。

なぜ一部のドライバーはクローズドソースなのか。これには、色々と複雑な事情がある。特に、ソフトウェア特許の問題がある。連中は、既存のソフトウェア特許への抵触を恐れるあまりに、ソースコードを開示しない。これは、実際にソフトウェア特許に抵触していることを連中が知っているかどうかとは別問題である。何故ならば、ソフトウェア特許に抵触しているかどうかを確かめるなど不可能であるし、そもそも、すでに大量のクズみたいな特許が認められている。だから、その手の特許ゴロに訴えられにくくするために、ドライバーのソースコードを公開しないのだ。

言うまでもなく、ソフトウェア特許は有害である。ソフトウェア特許の害悪の影響は、自由なソフトウェアやオープンソースの世界にとどまらない。なんの新規性もない単なる純粋な数式や手順が、ソフトウェアによって記述されただけで、特許になりうるのだ。クローズドソースによる難読化は問題の解決方法ではない。ソフトウェア特許は邪悪なのだ。

ところで、私もこの被害を受けているのだ。さきほど、サスペンドからの復帰に失敗した。なぜかXの応答がない。しかたなく、Ctrl+Alt+ファンクションキーでターミナルに切り替え、dmesgを実行してみたら、最後の二行に、nVidiaのプロプライエタリなドライバーがクラッシュしたとはっきり記録されていた。糞が。Xを再起動させる方法がわからなかったので、仕方なくリブートした。

調べたところ、UbuntuではXを再起動させるショートカットキーが、有名なCtrl+Alt+BackSpaceではない。Ctrl+PrintScreen+Kだそうである。変更した理由は、Ctrl+Alt+BackSpaceはうっかり押してしまう場合があって問題だから、あまり知られていない組み合わせに変更した、とのことである。

また、コマンドでXを再起動させるのも少し勝手が違う。Ubuntuのデフォルトではlightdmを使っているので、以下のコマンドになる。

sudo restart lightdm

ちなみに、GNOMEを使っている場合はgdm、KDEを使っている場合はkdmである。

再起動ではなく、止める場合はstop、開始させる場合はstartとなる。

本日の猫動画

映画と猫を組み合わせてみる。

最後に流れているのは、映画オズの魔法使いの歌、Over the Rainbowである。Nyan Catつながりなのだろう。どこかで聞いた気がするのだが、どこだっただろうか。

GNU/Linuxでfontconfigにより日本語フォントを優先させる方法

GNU/Linuxでは、fontconfigによりフォントの優先順位を設定している。この設定によって、フォントに存在しないグリフでも補完して表示できる。この機能は、モダンなOSなら大抵備えている機能である。しかし、もし、日本語と文字を共有している他言語のフォント、例えば簡体字や繁体字のフォントの優先順位が、日本語フォントより高い場合、そのフォントが日本語フォントより優先されてしまう。

どうも、この問題に対して、場当たり的に対処している人間が多いようだ。たとえば、該当の日本語以外のフォントを削除するという選択だ。PulseAudioの件と同じ場当たり的な対応である。なぜ問題の本質を探ろうとしないのか。そもそも、多言語環境を本当に実現したければ、重複数複数のフォントがあっても問題ないようにすべきである。問題を本当に解決するためには、フォントの優先順位の変更が必要だ。

日本人ならば、日本語フォントを優先したいだろう。そこで、GNU/Linux環境が日本語フォントを優先する設定になっていない場合、以下の手順で日本語を優先的に使用できる。

まず、できるだけシステム全体には影響を及ぼしたくないので、ユーザーごとの設定を行う。まず、設定ファイルをユーザーのホームディレクトリにコピーする

cp /etc/fonts/conf.avail/69-language-selector-ja-jp.conf ~/.fonts.conf

次にsedかawkを・・・といきたいところだが、この先の内容は環境によって異なると思われるので、残念ながらここに汎用的で自動的な方法を書くことはできない。まあ、そもそもfontconfigのディレクトリも環境により異なるかもしれないし、69-language-selector-ja-jp.confというファイル名だって、一致しているとも思えないが、それはさておき、とりあえず使い慣れたテキストエディタで開く

vim ~/.fonts.conf

ここから先は、環境によって異なるので、なんとも言えないのだが、Ubuntu 11.10の場合で説明する。以下の三行が何箇所かにあるので、すべて削除する。

<test name="lang" compare="contains">
    <string>ja</string>
</test>

このコードが、ロケールが日本語の場合のみ日本語フォントを適用するようにしている問題の本質だ。これを消せば、常に日本語フォントが適用される。この~/.fonts.confは、/etc/fonts/conf.avail/50-user.confから参照されている設定ファイルで、69-language-selector-ja-jp.confより優先される。

更にこの際に、日本語フォントの設定をお好みに合わせて変えておこう。ユーザーごとのホームディレクトリで行うので、どんな編集をしても安全である。もし失敗した場合は、~/.fonts.confを消して、最初からやり直せばよい。/etcにあるファイルは、今後のアップデートで書き換えられるかもしれないファイルである。書き換えるのはやめておこう。

じつは、これも問題の根本的解決ではない。根本的解決には、やはりシステム側でフォントの設定ツールを提供すべきではないのか。私は日本人なので日本語フォントが優先されることを好むが、中国人や台湾人は、簡体字や繁体字フォントを優先させたいはずだ。

と思ってみてみたら、zh-cnとかzh-hkとかzh-twには、上の三行のような条件指定がない。やはり不具合かもしれぬ。

追記:Ubuntu 12.10からは、.fonts.confの置き場所としてホームディレクトリ直下はdeprecatedになり、~/.config/fontconfig/下に置くべきだそうだ。

~/.fonts.conf は deprecated らしい - どせいけいさんき。

プリンスオブペルシャのソースコードが発掘された

Prince of Persia creator finds lost source code 23 years later – Video Games Reviews, Cheats | Geek.com

最初のプリンス・オブ・ペルシャは、Apple II向けに開発された。そのオリジナルのソースコードは、久しく失われていた。

この度、作者がソースコードを発掘したそうだ。

ソースコードの保存は非常に厄介な問題である。多くの文化的に重要なソースコードが、すでに失われてしまっている。自由なソフトウェアの意義はここにある。本来、ソースコードは公開するのが自然なのだ。ソースコードを公開しないのは反社会的であり、人道上の罪である。

参考:本の虫: なぜ歴史には海賊が必要なのか
本の虫: 最初のWebサーバーを保存せよ

GNU/Linuxのパフォーマンスはすばらしい

GNU/Linuxのパフォーマンスは素晴らしい。不自由なWindowsをブッちぎりで超越している。

もちろん、これは技術的に公平な比較ではない。まず、HDDが違う。不自由なWindowsで使っていたのは、かれこれ5年間も使っているSumsungの500GBのHDD、HD501LJであり、いまGNU/Linuxに使っているのは、新品のSeagateの3TBのHDD、ST3000DM001である。ただし、不自由なWindowsはBIOS上でのGPTを使ったHDDからのブートをサポートしていないので、このHDDからはブートすらできない。それから、アーキテクチャも違う。以前使っていたWindowsは32bit版だが、今のGNU/Linuxは64bitである。もっとも、これは当時のアカデミック版不自由Windowsが、なぜか32bit版しか提供されていなかったためである。それでも確か、1500円ぐらいした。一方、私の今使っている自由なGNU/Linuxを土台としたUbuntuは無料で、しかも64bitである。つまり、不自由なWindowsはインストールする時点で同じ土俵に立つことができないのである。だから、現実的には公平な比較である。そもそも、不自由なWindowsでは実現不可能な環境なのだ。

HDDの違いから、技術的に公平な比較は難しいが、GNU/Linuxで動かすプログラムのパフォーマンスは素晴らしい。不自由なWindowsの同じプログラムより高速に動作する。たとえば、FirefoxやChromiumの動作が非常に軽快だ。また非常の驚いたことに、SubversionやGitのパフォーマンスが素晴らしい。不自由なWindowsを使っていた頃には、私はプログラマーを自称しながら、バージョン管理システムに馴染めないでいた。理由は、パフォーマンスが非常に悪かったからである。しかし、GNU/Linux環境でのSubversionやGitのパフォーマンスを体験すると、これなら使ってもいいと、ようやく思うことができた。また、ターミナルが優れていて、CLIの使用が苦にならないのも利点である。

おどろいたことに、Chromiumが軽快に動作するのみならず、WebGLを利用したGoogle Mapsのパフォーマンスも、GNU/Linuxの方がはるかに上だ。もちろん、これにはnVidiaの不自由なバイナリブロブも関わっているが、グラフィックドライバーに関しては、Windowsも同じなので、公平である。

さて、このように快適なLinuxカーネルについて、少し学びたい。もちろん、Linuxカーネルのソースコードは真に自由なライセンスで公開されているので、いつでも読むことができる。しかし、いきなりLinuxカーネルのソースコードを読むのは敷居が高い。まず準備のために、Linuxカーネルの概要を解説した簡単な本が読みたい。不自由なWindows NTカーネルの詳細を噛み砕いて簡単に解説したWindows Internalsのような本のLinux版が欲しい。

色々と調べてみたところ、O'Reillyから出版されている、 Daniel P. BovetとMarco Cesatiの共著、Understanding The Linux Kernel が良さそうだ。日本語の翻訳では、詳解 Linuxカーネル 第3版がある。しかし、私は日本語訳というものを一切信用していないので、読むとしたら原著に限る。金が入ったら購入しようと思う。

Web上にも、いくつか興味深い書き物がある。たとえば、The Linux KernelとかLinux Kernel Newbiesなどは参考になりそうだ。

PulseAudioの問題

PulseAudioについては、悪い話しか聞かない。まだ私が不自由なOSであるWindowsを使っていた頃から、PulseAudioは酷評されていた記憶がある。

これが不思議だ。そもそも、PulseAudioというのは、低レベルAPIをラップする高レベルAPIである。PulseAudioによって、すべてのプログラムが、あたかもサウンドデバイスを独占的に使用できているかのような環境をエミュレートしている。その実装の質はともかく、思想は至って普通だ。モダンなOSなら、当然ハードウェアなどは通常のプログラムから意識させないようにするべきである。いまや、OSはサウンドデバイスの制限のあるミキシングに頼らないのだ。CPUは十分に速くなった。ソフトウェアでのミキシングは、現代のCPUならパフォーマンス上、なんの問題もない。いまや、完全なソフトウェアによるリアルタイムのミキシングやリサンプリングは当たり前である。

ところが、PulseAudioについて検索すると、まず出てくるのが、「お前を消す方法」である。これは一体どういうことか。大抵のディストリでPulseAudioはデフォルトで入っているのだ。入っているからには理由があるはずだ。理由とは、ハードウェアを仮想化するためである。

さて、この問題に、私もぶち当たった。なぜか、一部のプログラムでの音の再生に、周期的なノイズが乗るのである。私は当初、Linuxのサウンドドライバーを疑った。しかし、一部のプログラムだけに発生するので、ドライバーではあるまい。では、プログラム側の問題なのだろうか。このプログラムは非常にダメな実装をしているのだろうか。しかし、どうも実装の質による問題でもなさそうだ。

問題の根本的な理由は、この一部のプログラムが、ALSAを直接使っているためである。PulseAudioはALSAを仮想化するものだから、その仮想化に従わないプログラムがあると問題になる。

なるほど、一部の短気な人間が、PulseAudioをアンインストールすることによって問題の解決を図るのも納得だ。PulseAudioを消せば、すわなち、PulseAudioのサーバーを実行しなければ、とりあえず問題は解決する。PulseAudioの高レベルな仮想化の恩恵は受けられないが、ALSAを直接使っているプログラムは、正しく動作する。そして、ほとんどのGNU/Linuxで動く音声を再生するプログラムは、実行環境にPulseAudioがない場合を想定して、ALSAを直接使う動的なフォールバックを提供している。だから、PulseAudioがなくても、とりあえずは動く。

明らかに、これは間違っている。この手のことは個々のプログラムで行うべきことではない。システム側で一律に行うべきことだ。PulseAudioの実装の質はどうあれ、その理念は当然だ。

では解決方法はあるのか。真の解決には、すべてのプログラムが最終的にはPulseAudioを使うことである。PulseAudioを直接使うにせよ、OpenALとかlibabなどの更に高レベルなライブラリに頼るにせよ、最終的にPulseAudioを使うことが重要だ。しかし、ことGNU/Linuxの世界で、そのようなAPIの統一を図るのは不可能だ。ALSAを直接使うプログラムは依然として存在する。ソースコードが公開されていれば、自力で直すこともできようが、労力的に現実的ではない。

そこで、普通にALSAを使った場合は、PulseAudioが提供している仮想的なデバイスに入出力するようにするのだ。仮想的なデバイス経由で使われたPulseAudioは入出力を一手に引受、ALSAを使って、本当の物理的なハードウェアに出力する。

そのためには、.asoundrcか、あるいはシステムワイドな/etc/asound.confを設定する必要がある。詳しくは、以下を参照されたし。

freedesktop.org - Software/PulseAudio/Documentation/User/PerfectSetup

問題は、なぜUbuntuはデフォルトでこの設定をしていないのかということだ。不思議だ。まあもっとも、調べて設定するのはそれほど難しくないので、特に困らないが。

GNU/Linuxの問題は、ここにある。本来、このようなオーディオスタックは、単一の実装が低レベルから高レベルまで提供すべきなのだ。そうであれば、たとえ低レベルなAPIを使ったとしても、高レベルなAPIと強調できる。GNU/LinuxではALSAとPulseAudioが分離しているために、協調的な動作が難しい。選択の自由があることは素晴らしいことだが、運用を少しややこしくする。

2012-03-29

AdobeがFlashゲームのみかじめ料を要求しはじめた

Adobe Flash Player Premium Features for Gaming | Adobe Developer Connection
Got a Profitable Flash-Based Video Game? Adobe Wants a Cut | Webmonkey | Wired.com

Adobeの不自由なソフトウェアであるFlash Playerのプレミアムな機能を使っていて、$50000以上の売上のあるFlashで作られたゲームは、売上の9%をAdobeに差し出すこと。

この利用料を回避する方法は、プレミアムな機能を使わないか、売上を下げるか、今年の8月までにFlashゲームの公開を取り下げることである。

もちろん、我々が皆同意するように、不自由なソフトウェアであるFlashを使わないという選択肢が最も優れている。だから早く不自由なFlashの利用をやめるべきである。

何という馬鹿げた利用料金だろう。コンパイラーやライブラリに金を取るのはまだわかる。しかし、利用するときに売上に応じてみかじめ料を払わなければならないというのは馬鹿げている。しかも後出しだ。

ますます、自由なソフトウェアの存在価値を認識した。読者は一刻も早く、自由な開発環境に移行するべきである。プログラミングは根本的に自由が自然なのだ。不自由な開発環境などというのは反社会的かつ半倫理的である。

このブログのライセンスをCreative CommonsからGFDLに変更

このブログのライセンスを、今日より、CC-3.0-BY-SAからGFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Textsに変更することにした。

これは以前からGFDLとCCを比較して考えていたことである。

変更の理由は、Creative Commonsという名称のややこしさである。Creative Commonsは一枚岩ではなく、派生物を認めるかどうか、派生物は認めるがShare-Alikeかどうか、Non Commercialかどうかなど、それぞれ細部が異なるライセンスの集合である。お互いに互換性はない。だから、単にCreative Commonsといった際、非常に紛らわしいのだ。

また、Non Commercialという概念の定義も曖昧である。何を持って商用とするのかという定義が、国や法律どころか、人ごとに異なる。たとえば、このブログは閲覧に際し一切金銭を要求しないが、広告を設置している。これは商用だろうか。たとえば、私がNCなライセンスで提供されているコンテンツをネット上で公開するために、レンタルサーバーを借りて、そこにデータをホストさせたとする。しかし、このサーバーはコンテンツの利用に対し利益を得ている。これはどうなのか。

このため、Creative Commonsは真に自由なコンテンツを提供するためにはふさわしくない。

GFDLはどうか。GFDLは、商用非商用などといった区別を設けていない。これは当然のことだ。また、必ずcopyleftである。ただし、GFDLも天衣無縫というわけではない。Invariant Sectionsの問題がある。これは派生できない。翻訳はできるが、必ず原文を併記しなければならない。そのため、Invariant Sectionsなどを適用しないことにした。すくなくとも、Share-Alikeかどうかすら選択制になっているライセンスよりましだ。

また、GFDLの英語は非常に読みづらい。DRMに関する定義や、通過、非通過といった言葉の定義も曖昧である。SFDLのドラフトでは、英語は平易になっている。しかし、SFDLではInvariatn Sectionsこそ廃止したものの、様々な制限を受けるClauseを設けている。これはあまりよろしくない。また、通過、非通過の定義も、やはりあまりよろしくない。通過、非通過というもの規定することには同意するが、その定義がどうもよろしくないのだ。

また、今日のこの投稿から、このブログに対するコメントも、GFDLでライセンスされることにした。今日以前のコメントは、そのような規定を設けていなかったために、この限りではない。

ちなみに、明日以前のコンテンツは、すでにライセンスされたのだから、依然として、CC 3.0-BY-SAでも提供されている。ただし、GFDLを使うほうが望ましい。

2012-03-28

不自由なソフトウェアの時代は終わった

もはや、不自由なソフトウェアの時代は終わった。単純に終わったのだ。もうこれ以上、不自由なソフトウェアの未来はない。金銭的な価値はともかく、ソフトウェアの質は自由な方が圧倒的に高い。だからWindowsとかiOSとかAndoridが手元にあるならば、窓から投げ捨てるべきである。

こう言ったからとて、私は何も、フリーソフトウェア原理主義に改宗したのではない。今や、自由なソフトウェアの方が質が高くなっているからという至極単純な理由から言っているのである。私は質を優先する。不自由なソフトウェアの方が優れているのならば、いくら金を払っても構わないし、ソースコードが公開されていなくても構わない。しかし、事実として、今や、不自由でクローズドソースなソフトウェアは劣っている。自由か、最低でもオープンソースなソフトウェアの方が優れている。わざわざ不自由でクローズドソースなソフトウェアを使う必要はない。ましてや、劣ったソフトウェアに金を出すなんて論外だ。

10年前、私が初めて自分の稼いだ金を使って、コンピューターを所有しようしたとき、私はWindowsを選んだ、当時のGNU/Linuxの日本語サポートはおろそかだったからだ。5年前、今使っているコンピューターを買ったとき、私はまたもやWindowsを選んだ。当時学生だったので、アカデミック版が安かったからだ。

4日前まで、私はWindowsからGNU/Linuxへの移行に言い知れぬ恐怖を感じていた。なにしろ、10年間も使い慣れた環境である。勝手はわかっている。Windowsについては、ある程度理解しているつもりだ。Windows Internalsも、4thだが、読んでいる。MSDNの読み方も心得ている。今や、どんなWin32 APIだろうがらくらくと使えるようになった。この今までの経験が、すべて無になってしまうのだ。

もちろん、C言語やC++といった言語の文法知識は、GNU/Linuxでも通用するだろう。しかし、POSIXやLinux特有のAPIについては、Cの標準ライブラリの範囲しか知らないし、ましてやドキュメントの読み方もわからない。

Windowsでは、非常に有名なMicrosoft製の便利なIDEがある。しかしUNIXの世界では、エディタとビルドシステムはあまり密接に関係していないことが多い。もちろん、IDEもないことはないが、事実上、業界標準となっているIDEはないので、やはり広範な環境には対応できない。

そもそも、プログラミングどころか、UIも大幅に異なる。CLIの操作性も異なるし、GUIも勝手が違う。OSを変更するというのは、非常に怖いのだ。プログラマーこそ、最も変化に素早く対応しなければならない人種である。悲しいかな、我らもまた人間に過ぎず、旧態依然の環境に閉じこもっている。

ともかく、このままではならぬと、意を決して物理的に違うHDDにUbuntuをインストールし、Windowsの入ったHDDを取り外した。そして4日たった今、なぜあれだけWindowsにこだわっていたのか、すっかり忘れてしまった。このGNU/Linuxは、Windowsをブッちぎりで超越したのだ!! Ubuntuは利便性やパフォーマンスなど、すべての点においてWidnowsに優っている。

ターミナルや、GNU/LinuxのX環境でのターミナルエミュレーターは、Windowsよりはるかに優れている。一部の昔気質なユーザーが、いまだにCLIから移行しないのも納得だ。今はUbuntuデフォルトのUnityを使っているが、これも色々言われている割に、悪くはない。私はほとんどのソフトウェアを全画面で使うので、ごちゃごちゃとした高機能なランチャーやらメニューやらボタンやらは必要ないのだ。それより、compizの実解像度より広い画面を高速に移動できる方がいい

最も感動したのは、Debianのaptだ。これを使えば、コンパイル済みのソフトウェアのインストールはもちろん、ソースコードからのコンパイルも楽勝だ。あるソフトウェアをビルドするのに必要なツールやライブラリなどの依存関係を、すべて自動で解決してくれる。これにより、私の全くあずかり知らぬ言語とライブラリを使って書かれたソフトウェアのソースコードでも、簡単にビルドできる。

さらに、十分に有名なソフトウェアには、メンテナーが必要な調整を行ってくれていて、妥当なデフォルトの設定がされている。そのため、インストールしてすぐに使うことができる。調整や設定が気に入らない場合、自力での変更を妨げるような障害物は一切ない。

これでいて、ほぼすべてバイナリパッケージをインストールすることを前提にしたUbuntuなのだ。なぜこんなに他人の書いたソフトウェアのコンパイルが楽なのか。本当にこんなに楽をしていいのか。自前ビルド原理主義者のためのGentooやArchのようなディストロは、一体どうなっているのか。

環境を変えたために、学ぶことは膨大だ。しかし、実はそんなに学ぶ必要はないのだ。GNU/Linuxを使っていると、いかにWindowsが不自由であったかを思い知らされる。Windowsを使っていたときの「学ぶ」とは、本来、ユーザーのする必要がなかった「作業」でしかないのだ。有名ディストリには、そういう手間暇かかる面倒な作業をしてくれるメンテナーがいるおかげで、大多数のユーザーは、作業をせずにすむ。ありがたい。

ドキュメントだが、manとinfoはそれなりに使える。yelpから読むこともできるが、どうも今のyelpにはバグがあり、検索できないようだ。

ただし、今の私の環境には、ふたつの不自由なソフトウェアがある。nVidiaのプロプライエタリなバイナリブロブのドライバーと、AdobeのFlash Playerだ。

nVidiaのドライバーは、これは仕方がない。nouveauを使うと、ブートすらできないのだから、どうしようもない。nVidiaの公式ドライバーは、少なくとも、Winodows版と遜色ない出来であることは確かだ。しかし、Kernel Mode Settingに対応していないので、このままでは未来がない。Waylandのこともある。もしnVidiaが現状を維持するのであれば、次のGPUはAMDにする。すくなくとも、未来のないnVidiaよりはましだ。

Flash Playerは、実はほとんど必要ないのだ。事実、デフォルトのブラウザーであるChromiumでは無効にしている。ただし、たまにどうしてもFlashが必要な場合があるので、その時だけ、Flashを使うように設定したFirefoxを立ち上げている。なんにせよ、Flashにはもう未来がない。数年後には、アンインストールしても問題がなくなっているだろう。

もはや、不自由なソフトウェアは逝ってしまった。もはや先はない。止まった。天寿を全うして造物主のところに帰った。故ソフトウェアだ。停止した。逝去した。安らかに眠っている。既存のユーザーがいなければ立ち行かない。天界の妙なる鳴り物の音の列に加わった。かつてのソフトウェアだ。

clangにinheriting constructorが実装されない理由

Clangにopaque-enum-declarationがコミットされた。これで、残す機能はあと2つ、AttributeとInheriting constructorsだ。おそらく、最後に残るのはInheriting constructorsになるだろう。なぜか。誰も興味がないからだ。

freenodeでDouglas Gregorとチャットしていてこれを聞いたのだが、Inheriting constructorsが未だに存在しない理由は、興味を持つ者がほとんどいないからだそうである。それに、Inheriting constructorsの文面には、未だに曖昧な部分もあるとか。

実は、Inheriting constructorsとほぼ同等機能を、Variadic Templatesによってエミュレートできるのだ。これは、Douglas Gregorもペーパーで書いている。

US-65: Removing Inheriting Constructors

template<typename Mixin>
class add_color : public Mixin {
  Color color;

public:
  template<typename ...Args>
  add_color(Args &&...args)
    : Mixin(std::forward<Args>(args)...), color(Red) { }
};

この例では、テンプレートパラメーターであるMixinがどのようなコンストラクターを持つのかは、インスタンス化されるまでわからない。そのため、このMixinを基本クラスに据えようと思ったら、Inheriting constructorsが必要である。あるいは、エミュレーションだ。

std::forwardを使っているのは重要である。詳しくは、Perfect Forwardingなどのキーワードで調べること。

さて、このVariadic Teamplatesは正しく動くが、2つ問題がある。まずひとつは、Variadic Templatesなので、どんな実引数に対してもインスタンス化されてしまうことだ。エラーメッセージは、クラスadd_colorがオーバーロード解決可能なコンストラクターを持っていないというわかりやすいものではなく、テンプレートパラメーターMixinのコンストラクターがオーバーロード解決できないというものになってしまう。正しくコンパイルエラーにはなるものの、少しわかりにくい。

もうひとつの問題は、explicitやconstexprが引き継がれないことだ。たとえ基本クラスのexplicitコンストラクターであっても、派生クラスのコンストラクターはexplicitではないので、explicitの挙動はしない。さらに、constexprでもなくなってしまう。

しかし、この2つの問題は、些細なものである。Variadic Templatesによるエミュレーションは、十分実用的だ。

2012-03-27

precompiled header in clang

clangのprecompiled headerの使い方は、gccとは少し違う。まず、拡張子がちがう。.gchではなく.pchである。

まず、共通のヘッダーファイルを用意して、あまり変更されることのないヘッダーをincludeする。次に、以下のようにしてコンパイル済みヘッダーを生成する

clang++ -x c++-header header.h -o header.h.pch

ソースファイルをコンパイルするときは、-includeでヘッダーを指定する

clang++ -include header.h source.cpp

clangは、gccとは違い、同じ名前で拡張子.gchを付加したファイルを自動で探すことはない。自分で指定しなければならない。

Clang Compiler User's Manual

ffmpegとlibavの背景事情

ffmpegをインストールしようとしたら、なにやらちょうど一年前あたり、大規模なforkが起こったらしい。いまや、ffmpegとlibavに分裂している。forkは自由なソフトウェアではいたって普通の出来事だ。大抵の場合、開発者の間での意見の不一致により起こる自然な現象だ。自由なソフトウェアであれば、fork自体はそれほど悪いことではない。どちらも自由であるので、双方の開発者がIRCやMLで広角泡を飛ばしながら喧嘩しつつ、何事もなかったかのように相手のコードをこちらのコードベースにマージできる。なぜならば、どちらも自由なソフトウェアという共通点を持っているからだ。

しかし、ffmpegは、だいぶ巨大なソフトウェアだ。おそらく、現時点でこれ以上にでかい動画と音声のソフトウェアは、mplayerしかあるまい。mplayerはffmpegを包括しつつ、さらに変態的なことをしている。これについては後ほど述べるとして、まずはffmpegだ。どうやら、一年前に起こった出来事にも関わらず、ffmpegとlibavのforkの背景事情を説明する日本語の文献がないようなので、ここで解説する。

ffmpegは、世界一の規模を誇る動画と音声のエンコーダー、デコーダー集である。ffmpegはこの世に存在した、ありとあらゆる動画のエンコーダーとデコーダーを自由なソフトウェアとして提供する目的で開発されている。中には、大昔のゲーム専用機でしか使われていない、ドキュメントもない動画圧縮形式を、解析して実装することまでしている。ffmpegは、YouTubeを始めとしたあらゆる動画投稿サイトで使われている。なぜならば、このような動画投稿サイトにアップロードされる、それはそれは多数の圧縮形式を一手に引き受けて、正しくデコードし、さらに別の使いやすい圧縮形式にエンコードしてくれるのは、ffmpegをおいてほかにないからだ。ffmpegは、今日の動画サイトの舞台裏を支えているのだ。

そのffmpegがforkするというのだから、穏やかではない。いくら自由なソフトウェアとはいえ、物理的にコードベースが分離して、開発も分断されてしまうと、他方のコードでの変更点をこちらにマージするのは、一手間かかる。バージョン管理ソフトの自動的なマージ機能は、近年大幅に進化しているが、万能ではない。どうしても、人手による作業は避けられない。それでもなお、forkは起こる。

libavが発表されたとき、いち早くlibavに追随すると発表したのは、DebianとUbuntuである。実は、ここに問題の発端がある。問題は年々積もり積もっていたのだが、DebianとUbuntuも一枚噛んでいる。

Debianとその派生のUbuntuは、膨大なコンパイル済みのバイナリパッケージを提供している。パッケージはメンテナーによって、正しくコンパイルされ、適切に設定され、自動的にインストールされるよう調整される。このおかげで、ユーザーはCLIやGUIから、望みのパッケージを簡単にインストールできる。たとえば、ffmpegなら、以下のコマンド一行ですむ。

sudo apt-get install ffmpeg

あるいは、ソフトウェアセンターでffmpegと検索してインストールをクリックすれば良い。

無論、これは今さら言うまでもない。問題は、DebianとUbuntuにおけるffmpegのメンテナーが、バイナリパッケージをメンテする際のffmpegの問題をffmpegのトップの開発者、Michael Niedermayer(Lair Of The Multimedia Guru)にかけあった際、Michaelの対応がおろそかだったのだ。

さて、まずはlibav側の主張だ。

Ubuntu renaming FFmpeg to libav

問題とは、ffmpegがころころAPIやABIを変更することである。これでは長期的なサポートが難しい。だから、常にtrunkというわけではなく、stable版も提供してはくれないかという提案が出された。ところが、Michael Niedermayerはこの提案に否定的だった。さらに、Michaelはバイナリパッケージ自体にも、あまり興味を示さなかった。まるで、「ユーザーは常に最新版を自前でコンパイルして使うべきである」、といわんばかりの姿勢だった。

さらに、Michaelの指導下にあるffmpegは、機能の追加に対して保守的だった。たとえば、マルチスレッドによるデコード、ffmpeg-mtは、いまだにマージされない。しかも、「俺は絶対にffmpeg-mtなんかマージしねーよ」とまで明言した。

ここで、一部の開発者がより集まって相談した結果、forkするべきであるという結論に達した。Michael Niedermayerはこのforkに対して、口汚く罵り、身体上に危害を加えることを示唆するような悪質な冗談を繰り返したという。

FFmpeg
Libav

その後、お互いに相手のコミットを自分のコードベースにマージしたり、libavは名前をAPIをリファクタリングしたり名前を変更し始めたりと、やや不毛な作業も行われていたようだ。これが影響されたのだろう、Michael Niedermayer率いるffmpegはこの事件のあとすぐに、ffmpeg-mtをマージしたりしている。libavの方がバイナリパッケージのメンテナーの声をよく聞き入れる。DebianとUbuntuのlibavへの追随はこのためだ。

と、ここまではlibav側の主張である。Michael Niedermayerの主張は、また少し異なる。

Ubuntu renaming FFmpeg to libav

まず、Michael Niedermayerは、何も自前ビルドの原理主義者ではない。ただ、バイナリパッケージというものが大抵、一年以上も前のバージョンから更新されなかったりすることに不服だという。すでに多くのバグフィクスや改良、新機能の追加が行われているというのに、バイナリパッケージはいまだに大昔のままである。さらに、ffmpegをめぐるソフトウェア特許の問題もある。ソフトウェア特許に対処するためには、ソースコードの形で提供して、ユーザーにコンパイルさせた方がいい。

「ffmpeg-mtなんてマージしねーよ」というのは、単にIRC上でのチャットであり、その文脈上の冗談である。悪口というのも、たんなる冗談を本来の文脈から切り離して不当に評価したものである。

fork後にffmpeg-mtをマージしたのは、別に普通の作業であって、forkとは関係がない。

ABIの変化を気にかけないというのも不当である。というのも、MichaelはABI変化の問題を調査して、GNU ld.soにバグがあることをつきとめている。リンカーのバグ探しがなんで悪いのか。

ましてや、そのforkの方法たる、サーバーの管理者と協力して、MichaelのMLやソースレポジトリへのアクセスを禁止した。このような締め出しは開発者に与えられる正しい処遇ではない。

Lair Of The Multimedia Guru » ld.so GNU linker/loader

さて、プログラム的にみると、このforkの問題は少し厄介だ。まず、プログラム自体は、別の名前に変更されることになった。ただし、ライブラリの名前は変更されない。だから、このままでは、名前が衝突してしまう。両者とも比較的最近に、同じコードベースを共有していたのだから、ライブラリの互換性はあるが、混在はできない。ライブラリの名前を変えない以上、どちらかを選ばないといけない。GCCとEGCSのように、いつか和解して一つに戻る日がくるのだろうか。

DebianとUbuntuはlibav側に追随したし、Gentooも同じ影響を受ける。その他の有名なディストリはどうするのだろう。ffmpeg/libavは非常に有名なライブラリなので、ほぼすべての有名ディストリはパッケージに含んでいる。対応しないわけには行かないのだ。

ちなみに、冒頭の、mplayerはffmpegより巨大であるという話であるが、これはmplayerはffmpegを完全に包括するのみならず、Windowsのバイナリブロブを読み込むための機構を備えている。これは、Wineから拝借してきたコードである。数年前、コードを覗いてみたとき笑ってしまった。mplayerはLoadLibraryを自前実装しているのだ。

ちなみに、mplayerもforkされている。mplayer2という。より綺麗なコードベース(mplayerはffmpegのソースコードをコードベースに包括する。頻繁に更新されるffmpegは、外部に置きたい)、バグフィクスや改良などを含むという。mplayer2では、mencoderは提供されていない。

ちなみに、UbuntuのパッケージにあるChromiumは、ffmpegを使ったプラグインでvideoとaudioの対応形式を大幅に増やせる。このプラグインもlibavに変更されるのだろうか。

Google Summer of Code 2012では、ffmpegとlibavの両方が登録されており、両方とも似たような提案だらけだ。

FFmpeg Summer of Code 2012 - MultimediaWiki
Libav Summer Of Code 2012 - MultimediaWiki

clangを再コンパイルするときの注意点

clangのbinディレクトリにパスが通ったままだと、configureはデフォルトでclangを使おうとするので注意。もちろん、今のclangはセルフホスティング可能なレベルに達しているが、やはりtrunkから引っ張ってきたソースで、次のclangをコンパイルするのは不安だ。

さて、clangはmakeを多用している。ひとたびconfigureしたならば、clangをビルドする際のほとんどの作業は、makeで済ませることができる。

clangをSVNから引っ張ってきてビルドするには、最低でも三箇所から別々にチェックアウトしなければならない。もちろん、そんなことは手動でしたくないので、make updateを使う。これにより、自動的にすべての場所からチェックアウトしてくれる。

また、もしmakefileに変更があれば、再びconfigureする必要がある。もちろん、makefileのアップデートがあったかどうかを目diffするのは面倒なので、make preconditionsを使う。これにより、makefileの更新を確かめて、更新があればconfigureする処理を自動でしてくれる。

それにしても、UNIX環境ではmakeは変態的に活用されがちだ。たしかに、ほとんどのUNIX環境では、make、とくにGNU makeがまず存在する。だから使う気持ちもわからないことはないのだが、やり過ぎではないかと思うこともある。

不自由な環境に金が流れる事実

グリーは一体どこから道を間違え始めたのかという知られざる歴史まとめ - GIGAZINE

これはなかなか面白い。利益を追求する方向に進んでいったら、今の形になったというわけか。

それにしても、なぜ利益を追求しようとすると、ああいう不自由な形になってしまうのだろう。なぜ独占的で排他的な囲い込みに走ってしまうのか。Appleしかり、Microsoftしかり、Sonyしかり。事実として、利益が出ているのだから、認めるしかないが、それにしてもなぜこうなるのか。なぜ自由と利益は両立できぬのか。

ともかく、不自由なOSの使用をやめた身からすると、不思議でならない。今の私は、グラフィックドライバー以外は自由もしくはオープンソースなソフトウェアを使っているが、不自由なソフトウェアを使っていた時よりも、よほど快適だ。もっと早く移行するべきだったと後悔している。

ただし、私は今の自由なソフトウェアの環境を手に入れるために、一銭たりとも金を支払っていない。だから自由と利益は両立しないのかもしれない。ところで、ソフトウェアの質は、自由な方が圧倒的によい。ソフトウェアの本質から考えて、自由なソフトウェアの方が質が良くなるのは当然のことだ。しかし、事実として、金は不自由なソフトウェアの方に流れる。不思議だ。不自由なソフトウェアが優れているのなら、金を払う価値はあるだろう。しかし、自由なソフトウェアの方が優れていて、しかも安価で手に入るならば、なぜ不自由なソフトウェアに金を払うのか。

Unix - Wikipedia, the free encyclopedia

UNIXの歴史も興味深い。当初、UNIXはAT&TのBell Labで生まれた。AT&Tは当時、法規制によって、コンピューター産業への参入を禁止されていた。そこで、UNIXは無料でソースごと配布された。そのため、多くの大学機関でUNIXを採用した。後に、この法規制が解かれ、AT&TはUNIXで商売をやりだすようになった。その際、既存のUNIXの使用に対して、金を要求した。このため、オリジナルのUNIXの利用率は低下した。

その後、続々と自由なUNIX風OSが登場するわけだ。「自由」の定義は異なるが、少なくとも、ソースコードが公開されていて、改変できて、再配布できるという点では共通している。現在、広く使われているのは、このUNIXのようなOSである。

こちらは、不自由なソフトウェアが負けた例だ。もはや、オリジナルのUNIXは生き残っていない。パチモンに負けたわけだ。

2012-03-26

X11でクリップボードを操作しようと思ったら

Windowsでは、私はクリップボードを操作する簡単なツールを使っていた。たとえば、ブログにコードを貼り付けたりするとき、

template < typename T >
void f( T & ) ;

というコードは、実は、以下のようにエスケープしている。

template &lt; typename T &gt;
void f( T &amp; ) ;

もちろん、これも更にエスケープしているわけだ。CDATAセクションでも使わない限り、XML上で、&, <, >を直接書くことはできない。もっともBloggerはなんちゃってXHTMLを使っているので、実はちょっと変なHTMLにすぎないのだが。

このような変換を手sedで行うのはプログラマーたる者のすることではない。しかし問題は、私はいろんなソフトウェアを使っているということだ。vimやemacsのような一つの環境に閉じこもるならば、そのツール内で完結するコードを書けばいいが、実際には、テキストエディターは複数使うし、ブラウザーも複数使う。できるだけ広範囲で動かすには、クリップボードが最適だ。X11の練習がてら、さっそくC++で書いてみようと思った。

問題は、X11におけるクリップボードが使いづらいということだ。X11におけるクリップボードは、イベント駆動な仕組みになっている。クリップボードにデータを供給するには、その旨を通知した上で、さらに他のプログラムからの実際のデータの要求を待たねばならない。つまり、クリップボードに通知したあと、要求があるまで、ソフトウェアは起動したまま待たねばならない。私が今欲しいツールにはGUIなどいらないというのに、イベントループを回して要求を待たねばならない。もちろん、ウインドウを作ったりする必要はないが、たかだかクリップボード程度にえらく大げさなコードになる。

最近は、クリップボードサーバーがあり、プログラムの間の橋渡しをしてくれるので、一度要求を処理して終了してもクリップボードは維持されるようになった。しかし、結局コード上では通知して要求待ちしなければならないことに変わりはない。

なぜこう設計せねばならなかったのか。クリップボードのアイディアは、何もGUIを必須とするわけでもあるまい。GUIがなかった時代だって、プログラムごとにミニバッファなどと称して、クリップボードと本質的には大差ない機能をプログラムごとに実装していた。だから、クリップボードというのはそれほど新しい発送でもないはずだ。なぜ、/dev/clipboardみたいな仕組みがないのか。

Win32 APIのクリップボードも、あまりいい設計とは言えない。なにしろ、今となって古びたGlobalAllocを使わなければならないのだから。とはいえ、単純なクリップボードの読み書きごときにイベントループを回す必要はない。

というわけで、X11を直接使うのはやめることにした。聞説、Waylandなるものが将来、X11を完全に置き換えるらしい。とりあえず、今はGTK+でもいじって遊んでいよう。しかし、GTK+も概要を理解するだけで少し時間がかかるので、やはり面倒だ。

というわけで、未だに一行のコードも書いていないわけだ。ただし救いはある。私はいまGNU/Linuxを使っている。そのため、私は一行のコードも書くことなく目的を達成できるのだ。

顧客が本当に必要だったもの

#!/bin/sh
xclip -selection clipboard -o | sed "s/&/\&amp;/g;s/</\&lt;/g;s/>/\&gt;/g" | xclip -selection clipboard

clangのビルド

さて、Ubuntuの基本的な使い方に慣れたので、さっそく環境の構築に入る。まず、GNU/Linuxに移行した最初の目的である、clangを使うことにする。Ubuntuのレポジトリにはclangはあるが、残念ながら古すぎる。面白いことをするには、SVNから最新版を引っ張ってこなければならない。

clangをコンパイルするのは非常に簡単だ。とくに珍しいツールも必要ない。比較的新しいgccとGNU makeがあればいい。テストするには、もうすこしツールが必要だ。基本的にはClang - Getting Startedに従えばよい。ただし、SVNから取得すると、デフォルトのビルドがとんでもないことになるので、このままでは使いづらい。もちろん、普通に使うことは想定してないのだから、当然といえば当然だが、clangをハックするのでもなければ、やはり使いづらい。

まず、デフォルトでは、すべてのアーキテクチャ向けのクロスコンパイルができるようになっている。また、デフォルトではデバッグビルドかつassertが有効である。そのため、clangの単一のバイナリだけで、サイズが460MBぐらいになる。なかなか壮大だ。

configureしたあとでも設定を上書きできるのだが、どうせならconfigure時に指定してしまおう。

configure --enable-optimized --enable-assertions=no --enable-targets=host-only

これで、とりあえず試してみるだけのビルドができる。

ちなみに、SSVNではllvmとclangとcompiler-rtが分離されているので、アップデートするときは、ひとつひとつsvn checkoutするより、make updateを使ったほうが便利だ。

しかしまあ、なんとLinuxでは他人の書いたソフトウェアのビルドがたやすいことよ。これがWindowsなら、まずビルドツールからしててんでバラバラなので、非常に苦労する。

そんなわけで、clangを試してみたが、まあ、特にこれと言って面白いこともなく、普通に動作する。gccも頑張っているので、clangだけがサポートしている機能といえば、非staticメンバー関数のref-qualifierしかない。

#include <iostream>
#include <utility>

struct X
{
    void f() & { std::cout << "lvalue" << std::endl ;}
    void f() && { std::cout << "rvalue" << std::endl ; }

} ;

int main()
{
    X x ;
    x.f() ;
    std::move(x).f() ;
}

Getting Started with LLVM System
LLVM Makefile Guide

2012-03-25

なぜエロサイトの動画プレイヤーはYouTubeより高機能なのか

Redditで、以下の質問が注目を集めていた。

Why do porn sites have video players that are so much better than Youtube? : AskReddit

エロサイトの動画プレイヤーは、YouTubeのよりはるかにいい。すべての男と、おそらく大多数の女は、この事実を認めるであろう。YouTubeは動画中のコマを見ることができる機能を追加した。しかし、そんなのはエロサイトならとっくの昔に実装されていたことだ。エロサイトでは、動画のプレビューがある。単なる一枚の画像ではなく、アニメーションGIFのような形のプレビューだ。しかも、エロサイトはフルスクリーンへの切り替えにもたつくことはない。なんでエロサイトはGoogleよりよっぽどいいUIを提供しているんだ?

面白い質問だ。

評価の高かった書き込みの意見はどうか。曰く、エロサイトはYouTubeよりも競争が激しい。したがって、最新の技術を取り込まなければユーザーが得られない。一方、YouTubeはあまりにも巨大すぎて、大きな変更が難しい。UIをほんの少し変えただけで、多数のユーザーが文句を言う。

ただ、これは何も、エロサイトに限った話でもないと思う。実際、YouTubeは動画投稿サイトとして、現在のところ最大手であろう。他にも無料の動画投稿サイトは山ほどあるし、YouTubeとの差別化を図るため、様々な機能を追加している。しかし、やはりYouTubeには勝てない。そもそも、どうも多くのサイトは、YouTubeに勝つことを目的としていないように思われる。汎用的な動画サイトとなるよりも、独自性を売りに出すサイトの方が多い。

Ubuntuは便利だ

長年Windowsを使ってきたせいで、なかなかWindowsからは離れづらかった。そのため、Ubuntuのインストールも、あれやこれやと理由をつけて、なるべく引き延ばしていた。ともかく、これ以上机上で学んでも仕方がないので、意を決してインストールすることにした。

さて、今日一日、慣れるためにUbuntuを使っていたが、一切問題を感じなかった。ChromiumはWindowsと全く同じ操作性だし、IRCクライアントも、とりあえずXChatを選んでみたが、全く申し分ない。

最も感心したのが、ターミナルだ。なるほど、たしかにこれは使いやすい。未だにCLIでほとんどすべてを済ます猛者がいて、 dwmやxmonadやawesomeのような漢らしいウインドウマネージャが流行るのもわかる気がする。

現在悩んでいるのは、エディタだ。 geditはたしかに無難だ。必要な機能は全て揃っている。しかし、どうも面白みがない。nanoは素晴らしいエディタだ。ほんのちょっとテキストファイルを書き換えたい時には、nanoはとても便利なエディタだ。しかし、やはり機能が足りない。機能が少ないからこそ、nanoは優れているのだから、これは仕方がないことであるが、不足は不足だ。とすると、vimとemacsのどちらかを選ばざるを得ない。さて、どうするか。個人的には、vimの方がエディタとしては使いやすいのではないかと思う。emacsは、emacs自体を完成された一つの環境だと考える人間だけが価値を見出すのであろう。

もっとも手こずったのは、GeForce GTX 560Tiである。このデバイスは、Linux環境では一長一短だ。まず、長所としては、nVidiaのプロプライエタリなドライバーを使えば、満足の行くパフォーマンスが得られるということだ。ともかく、Windowsとほとんど遜色ないドライバーが提供されているのは利点だ。

問題も、このドライバーだ。このドライバーは、Kernel mode settingに対応していない。そのため、ブートやサスペンドからの復帰や、Ctrl+Alt+ファンクションキーでのターミナル切り替えなどで、画面が汚くちらつく。それに、時間もかかる。サスペンドからの復帰に数十秒かかり、しかもその間画面に描画がないので、本当に正しく動いているのかどうか不安になる。サスペンドからの復帰に数十秒もかかるのは到底納得できない。

ともかく、今となっては、なぜ昨日まであんなにWindowsにこだわっていたのか、さっぱり忘れてしまった。もっと早く移行しておけばよかった。 もはや、Windowsを使うべき理由は何もない。

2012-03-24

Ubuntuに移行した

そういうわけで、Ubuntuに移行した。Windowsを入れたHDDは、念のために残しておくが、おそらくもうWindowsに戻ることはないだろう。Ubuntuは十分に快適だ。

何が便利かと言って、膨大なオープンソースのソフトウェアが、公式レポジトリで提供されていることだ。有名どころのソフトウェアなら、まず確実に存在する。これにより、ソフトウェアの管理に煩わされることがない。しかも、コマンド一発でインストールできる。

そして、ソフトウェアのコンパイルも非常に簡単だ。

とりあえず、デフォルトではTakaoPGothicしか入っていなかったので、Takaoフォントを一式入れた。また、inconsolataもいれた。gitとsubversionやg++のインストールも一瞬で終わり、すぐに使える状態になった。これは便利だ。

ブラウザーには、Chromiumを使うことにした。Googleのアカウントと同期する設定にしておいたので、これまでのブックマークや拡張などがすべて自動で復元された。すばらしい。

さて、今日一日、色々と試してみたが、UbuntuはWindowsと遜色なく使えるのみならず、Windowsよりよほど使いやすいことがわかった。もっと早く移行しておけばよかった。

さて、とりあえず、今はUbuntuで満足している。ただ、Arch Linuxも気になるが、まあしばらくはUbuntuでいいだろう。とりあえず有名なものを使っておけば、それほど悪くなることはないだろう。

Victory!

So, I installed and am writing this from Linux. Well, GNU/Linux according to the famous fundamentalist. I choose Ubuntu a try because I don't want to worry about editing everything by hand or compiling everything from source. So far, so good. It works well.

The only problem I faced at the installing was kernel mode setting. The open source driver for nVidia graphic card, known as nouveau, didn't work well for my GPU, GeForce GTX560Ti. So, I had to manually gave kernel parameter of nomodeset. Aside that, the Installing was easy enough. Although I had to try twice.

If I checked to install proprietary software, the Installer automatically recognize my GPU and installed the appropriate nVidia's binary blob. But I think the description of this check box is misreading. It said, if I check this, I can get proprietary mp3 decoder. well, I don't need mp3 decoder. Even if I need it, I can install it later. So naturally, I skipped it the first time and got no binary driver, failed to boot(because of nouveau).

After the reboot, it had 364 security updates. which I installed. and another reboot.

さて、ここまで書いてmozcをインストールしたので、これ以降は日本語で書く。とりあえず、Ubuntuはどうしてなかなか悪くない。

2012-03-22

C++11のstd::swapはC++03のstd::swapとは互換性がない

C++11のstd::swapは、だいぶ大きく変更された。C++03までのswapは、<algorithm>にあり、CopyConstructibleかつAssignable(C++11のCopyAssignableに相当)を要求した。ところが、C++11では、<utility>に移されたあげく、MoveConstructibleかつMoveAssignableを要求するようになった。まるっきり別物になってしまっているのだ。果たして問題を起こさないものだろうか。おぼつかないものだ。

実装例は以下のようになる。

// C++03のswap
template < typename T >
void swap( T & a, T & b )
{
    T temp = a ;
    a = b ;
    b = temp ;
}

// C++11のswap
template < typename T >
void swap( T & a, T & b )
{
    T temp = std::move(a) ;
    a = std::move(b) ;
    b = std::move(temp) ;
}

ところで、Andrew Koenigは、swapはコピーやムーブ以上に基本的な操作だと書いている。

Object Swapping Part 1: Its Surprising Importance | Dr Dobb's
Object Swapping, Part 2: Algorithms Can Often Swap Instead of Copy | Dr Dobb's

C++11のswapはムーブになっているので、わざわざメンバー関数としてのswapを実装する必要はない。ムーブコンストラクターさえ実装しておけば、それがそのままstd::swapで使える。さて、koenigの理論を実践してみる。

class X
{
private :
    std::size_t size ;
    char * ptr ;

public :
    X( std::size_t size )
        : size(size), ptr( new char[size] )
    { }
    ~X()
    {
        delete[] ptr ;
    }

    X( X const & t )
        : size( t.size ), ptr( new char[t.size] )
    {
        std::copy( t.ptr, t.ptr + size, this->ptr ) ;
    }

    X ( X && t ) 
        : size( t.size ), ptr( t.ptr )
    {
        t.size = 0 ;
        t.ptr = nullptr ;
    }

    X & operator = ( X const & t )
    {
        if ( this == &t )
            return *this ;

        X temp = t ;
        std::swap( *this, temp ) ;
        return *this ;
    }

    X & operator = ( X && t )
    {
        if ( this == &t )
            return *this ; 

        std::swap( *this, t ) ;
        return *this ;
    }
} ;

なるほど、コピー/ムーブコンストラクター以外はすべてswapで実現可能なのだな。

BloggerのccTLDリダイレクトは相当ひどい

このブログでは、主に日本語を使っている。そのため、読者の大半は日本に属するIPからのアクセスである。したがって、最近のBloggerの変更により、自動的にcpplover.blogspot.jpにリダイレクトされる。既存のcpplover.blogspot.comはちゃんとリダイレクトされるので、すでに存在するリンクはそのまま動く。しかし、URLが異なるというのは、非常に問題だ。とくに、このソーシャル全盛の時代においては。

オンラインブックマークというサービスがある。これは、ブックマークをオンライン上で公開できるサービスである。多くのユーザーがブックマークするURLは、高価値の可能性が高い。Web検索の黎明期、多くの被リンクを得ているURLの価値が高いと判断されたのと同様だ。他にも、Twitterで多く言及されているURLは、価値が高い可能性がある。他にも、FacebookのLikeボタンやGoogle自らやっている+1ボタンのようなものも同様だ。これらのサービスは、URLに対して評価のカウントを与える。

ところが、既存のURLは、すべてblogspot.comを使っている。これがblogspot.jpに変更されたことにより、今までのカウントがすべてご破算になってしまうのだ。正確に言うと、既存のカウントがなくなるわけではない。しかし、これ以上既存のカウントは上がらない。新しいコンテンツは、.comではなく.jpでドメインでカウントされる。何にせよ、従来のカウントは、もうこれ以上上がらないのだ。つまり、このブログでは、従来の.comと今の.jpにカウントが分散してしまっている。

英語で書かれているブログはもっと悲惨だ。英語が母国語の国は多数ある。アメリカとイギリスとオーストラリアだけ考えたとしても、diggやredditに登録する時、Likeボタンや+1ボタンを押す時、それぞれ.com、.uk、.auに分散してしまう。

結局、Googleはソーシャルのことなど何もわかっていないのだ。既存のカウントが、評価が、どれだけ大事なのか全然わかっていない。

この問題は、独自ドメインを取得して使うことにより、回避できる。しかし、今まで独自ドメインを使って来なかったのに、今更やるのは、やはり同じ事だとも言える。既存の評価をすべて置き去りにしてしまうのだ。

ところで、Bloggerにはソーシャル系へ投稿するためのリンクを生成する機能がある。試してみたが、結局無効にしてしまった。なぜかというと、Google +1ボタンが、カウントを取得するためにJavascriptでカウント数を問い合わせる。これがページのロード時間を増やす。あほじゃなかろうか。

以前のテンプレートでやっていたように、自前のJavascriptコードを書くという手もあるが、やはり読者もロード時間の短い方を好むと思うので、やらないことにした。第一、ソーシャル好きな読者は、今みているURLをすぐにtweetなりlikeなりできるようにするブックマークレットなり拡張機能なりを導入しているだろうから、サイトごとにコロコロ変わる独自のtweetボタンなど余計なお世話だろう。それよりロード時間の方が重要だ。

汚いものは隠して解決?

Linuxについて調べていると、どうも引っかかることがある。それは、Linuxがどうも、汚いものは隠して解決するという文化を持っていることだ。

たとえばXだ。聞きかじったところによると、X11は相当に汚いらしい。使いづらいし、今となっては不必要な古びた機能が多数存在する。これは、ほとんどの文章にそう書いてあるし、また実際に人にたずねても、誰一人としてX11の醜悪を否定したりしない。XFree86からフォークしたX.Orgなどは、Xを直接使うなと公式に宣言している。GTK+とかQtなどの、汚いものを隠した上のレイヤーを使えと推奨している。

X.Org Wiki - Documentation

では、何故未だにX11が使い続けられているのか。もし、ある標準のAPIの設計が悪いとしたら、より優れた標準のAPIを設計すべきではないのか。なぜ悪い標準のAPIをラップした非標準のAPIを多数生み出すのか。これが理解できない。

IMEもそうだ。聞きかじった知識によると、XIMは非常に汚いそうである。しかし、なぜか明白で根本的な解決方法である、XIMの後継APIの再設計は行われない。XIMをラップした上でさらに機能を付け加えた、iBusとかSCIMとかuimが、雨後の筍のようにぽこぽこ登場している。

X11は非常に複雑なシステムだから、一から設計して実装するリソースがない、などという理由は信じない。GTK+やQtでは、結局ほとんどの機能は自前で実装している。開発リソースは十分にあるはずだ。互換性の問題とも思われない。今やほとんどのソフトウェアは、Xを直接使わずに、その上のレイヤーのライブラリを使っているのだから、バックエンドを変更するのは、比較的軽い変更と、ソフトウェアの再コンパイルで済むはずである。ソースコードを公開するという文化のあるLinuxでは、そのような破壊的な変更も、他のプラットフォームに比べて、比較的敷居が低いはずである。(もちろん、楽ではないだろうが)

なぜこうなってしまうのだろうか。どうもLinuxの歴史をみていると、ひとつの優れた標準のライブラリを開発するより、多数の互換性のないライブラリが独自に立ち上がっていることが多い。しかも、最終的に一つの優れたライブラリに統一されるのではなく、複数の主要なライブラリが生き残っている。

と、こう身の程知らずに偉そうなことを書くと、「じゃあお前が書けよ」と言われるかもしれない。しかし、仮に書いたところで、もう一つ規格が増えるだけだ。

状況:競合する規格が14個ある。
甲:なんやて14個? アホくさ。ワシらで誰でも使えるめっちゃえー規格作って、他の奴らなんか蹴散らしてやろうやないか
乙:そうや、そうや
状況:競合する規格が15個ある。

xkcd: Standards

といいつつも、Waylandには少し期待している。

LinuxカーネルがVMUFATをサポートするかも

[Phoronix] Linux Kernel May Gain VMUFAT File-System Support

LinuxカーネルにVMUFATの実装が取り入れられるかもしれない。とはいっても、誰も喜ばないだろうとおもうし、そもそもVMUFATが何であるかを知る読者もいないであろう。そもそも、この名前からして、正式なものではなく、仮に付けられた名前なのだ。

VMUFATとは、セガのドリームキャストで使われていたファイルシステムである。いったい今、ドリームキャストの実機でLinuxを動かす需要がどれだけあるのか。

ちなみに、動画ブログのBreaking Eggs And Making Omelettesで有名なこの人は、Dreamcastの実機で色々と遊んでいるようだ。

Dreamcast | Breaking Eggs And Making Omelettes

2012-03-20

なぜDOSのパスはバックスラッシュなのか

Why is the DOS path character "\"? - Larry Osterman's WebLog - Site Home - MSDN Blogs

基本的にDOSのパスはUNIX由来なのだが、スラッシュはすでにスイッチとして使われていたので、仕方なくバックスラッシュにしたらしい。

GCC 5はモジュール化できるか

[Phoronix] Talk Of GCC 5.0 To Be Modular, More Like LLVM
David Malcolm - GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

聞説、今のGCCのコードは、やや悲惨な部類に入るらしい。十分な実績があり正しく動くのは確かだが、コードはほとんどCで書かれており、名前空間もなく、グローバルな状態が多く、スレッドもない。これはつまり、GCCは他のソフトウェアに組み込むのが難しい。

一方、LLVMは、設計段階からモジュール化を念頭に置いており、GCCよりはるかに後発なのにもかかわらず、他のソフトウェアに組み込む用途で広く使われている。たとえば、 MesaのGallium3Dとか、OpenCLとか、Monoとかで、JITコンパイルを実現するために、すでに使われている。他にもLLVMを利用して、CやC++をJavascriptに変換するようなプロジェクトも生まれている。

GCCは歴史や実績こそ十分だが、このような組込用途には、現在のコードベースでは圧倒的に向いていない。そこで、GCCをLLVMのようにモジュール化して使いやすくしようという議論がある。

問題は、長年の歴史あるGCCのコードをモジュール化するための変更は相当にでかい。したがって、現実的な方法でモジュール化を進めると、GCCは短期的に、機能が少なくなり、最適化も悪くなり、あらゆる点で現行のGCCより劣ることになる。もしすべての現行機能をそのまま保とうとしたら、作業が莫大すぎて現実的に行えない。多くのGCCのコントリビューターは、すでにGCCを自社で使っている会社に雇われて働いている。そのような会社が、GCCの機能を、短期的に劣化させる作業に金を出したいと思うだろうか。

もうひとつの問題は、ライセンスだ。GCCはGPLv3で提供されているが、LLVMはより柔軟でpermissiveなライセンスで提供されている。たとえモジュール化をやり遂げて、組込用途でLLVMに対抗できるようになったとしても、GPLでは使えない企業も出てくるだろう。現時点で、GCCがいまさらライセンスを変更できるはずもない。一体どうするのか。

なんにせよ、今のLLVMの開発速度は驚異的だ。GCCは今の地位を保てるだろうか。明らかに今のGCCのケツには、やがて発火する煙がくすぶっているように思われる。

C++Now!行きたいなう

Keynotes! |

豪華過ぎる。clangのlibc++作者のHoward HinnantとEDGでC++ Templates作者のDavid Vandevoordeだなんて。

Howard Hinnantはrvalue referenceについて話すらしい。David Vandevoordeはなんと、現在策定中のモジュールについて話すとか。

ちなみに、モジュールについて知りたければ、N3347を読むといい。特に、某人はC++Now!に参加するそうだから、まだ読んでいないとしたら、是非とも読むべきである。

2012-03-19

Linuxの作法

どうもLinuxにおけるプログラムからのディレクトリの使い方の作法が難しい。

あるプログラムが、動作に設定ファイルとデータファイルを必要とする。これには、Linuxの作法では、それぞれbinとetcとshareを使うようだ。問題は、主要なものだけ挙げても、/binと/usr/binと/usr/local/binがあり、、etcとshareに関してもそれぞれ同じものがあるということだ。もちろん、これらのディレクトリの違いは解説されている。しかし、一体どうやって、どこに置いても正しく動作するプログラムを書けばいいのだろうか。

/usr/binに置かれたプログラムは、やはり/usr/etcを使うべきなのだろうし、/usr/local/binに置かれたプログラムは、/usr/local/etcを使うべきなのだろう。それ以外のディレクトリ下に置かれたプログラムも、やはりそこから見て相対的なetcやshareなディレクトリを使うべきなのだろうか。問題は、そのように振る舞うプログラムをどうやって書けばいいのだろうかということだ。実行可能ファイルが置かれている場所からの相対パスでも使うのだろうか。また、ある名前のディレクトリがどのような目的で使われているかというのは、ディストリごとに微妙に異なる。どうやってポータブルなプログラムを書けばいいのだろうか。すべてのディストロに対応するなどということは、到底小規模なソフトウェアでできそうなことではない。

調べてみると、その手の作業は、autotoolsなどのビルドのためのビルドツールの役割であるらしい。つまり、ソフトウェアはソースコードの型で提供する文化なのだから、コンパイル時にそのような変更をする簡単な方法を提供してやればいい。コンパイルや設定方法などのドキュメントを用意すれば、あとは使用者が自力で設定、コンパイルして使う。ソフトウェアに十分なユーザーがいれば、誰かしら、自分のディストロ用のパッケージなどを作成してくれるだろうから、自力で設定してコンパイルする知識のないユーザーでも、ビルド済みのそのディストロで動くソフトウェアを手に入れられる。

結局、GPLがどうとか、フリーなソフトウェアがどうとかという大義名分とは関係なく、UNIX環境でまともに動くソフトウェアを提供するならば、ソースコードを公開することは至って自然なことのように思える。

まあ少なくとも、プログラマーにとっては便利な環境であるとは言える。ただし、すべてのディストリで動くポータブルでジェネリックなバイナリなどというものを提供することはできない。これは、プログラマーではないユーザーにとっては難しい状況だ。

これを考えるに、LinuxがWindowsやMacを駆逐するということは無理だろう。やはり一般に普及するには、誰か強力な独裁者がひとつの環境を提供する必要がある。androidやUbuntuも、独断的な部分があるからこそ、ある程度の成功をおさめているのだろう。

それにしても、autotoolsを使うのに覚えることが多そうだ。とりあえず必要になるまで学ぶのは保留しておこう。

Linuxのディレクトリ構造について

Windowsにおける、ユーザーが見るディレクトリ構造は、ドライブレターを用いてる。これは、物理的なHDDなどの記憶装置による分割はもちろん、その上に構築されるパーティションによる論理的な分割もある。

一方、Linuxのディレクトリ構造は論理的なもので、ユーザー側からは、通常の利用においては、あまり物理的な記憶装置を意識しないようになっている。

もちろん、最近は両OSとも、古典的なファイルシステムや物理的な記憶装置、パーティション管理を捨てて、ソフトウェア側で複数の記憶装置を、あたかもひとつの巨大な記憶装置のように使う手法を提供している。Windowsでも、今やシンボリックリンクはサポートされている。とはいえ、依然としてWindowsではシンボリックリンクが一般的ではなく、本来そういったハードウェア上の詳細を知らなくてもいいはずの末端ユーザーでも、ドライブレターを意識しなければならない。もちろん、これはWindowsではシンボリックリンクが一般的ではなかったので、急にGUIのエクスプローラーにシンボリックリンク作成の機能を付け加えても、混乱が大きいことにもよろう。それに、Windowsの顧客層を考えれば、ドライブレターという従来の仕組みを急に捨て去ることは難しい。

Linuxの問題は、ディレクトリ構造がディストリごとに微妙に異なるということだ。一応、Filesystem Hierarchy Standardという規格はある。しかし、この規格は本当に基本的で大雑把な構造を規定しているだけだ。それに、標準的なディレクトリパスを取得する標準の方法がない。Windowsでいう、SHGetKnownFolderPath関数のようなAPIがないのだ。Linuxでディストロ間のバイナリ互換性を保証するのが難しい理由の一つに、ディレクトリ構造の差異によるものがあると聞く。

追記:FHSによれば、ユーザーのホームディレクトリを取得するには、getpwentを使うことが推奨されている。

それに、FHSはすべてのディストリで守られているわけではない。たとえば、DebianはFHSに完全には従っていない。とくに、DebianはFHSのmultiarchの場当たり的でx86とx86-64限定の対応に不満を持っていて、もっと汎用的な方法を独自に考案し、今移行中である。Ubuntu 12.04では移行するらしい。もっとも、/lib32や/lib64へはシンボリックリンクを貼るので、ある程度の互換性は保たれるようだが。

Debian Policy Manual - The Operating System
Multiarch - Debian Wiki

ともかく、慣習的に、Linuxではパスは大抵ハードコードされている。移植性を考えたソフトウェアは、使用時やビルド時にパスを指定する機能を提供している。これは、ユーザーは最低限のプログラミングの知識を有していることが期待され、ソフトウエアはソースコードの形で提供するというUNIX文化ならばうまく動く。また、主要なディストリには、公式なパッケージの仕組みがあり、需要のある有名なソフトウェアやライブラリには、専門のメンテナーがいて、そのディストリ用にあらかじめ調整してくれているので、大多数のユーザーは、そのような詳細にかかずらう必要がない。Debianが大胆なmultiarch対応を実行に移せるのも、このような文化の違いにもよろう。

もちろん、Windowsより優れている点もある。公式パッケージの仕組みもそうだし、ヘッダーファイルやライブラリファイルの標準のパスがあるので、ソースコードをコンパイルする際に都合がいいということだ。こと、他人の書いた大規模なソースコードをコンパイルする場合に関しては、Windowsよりよっぽど楽だ。あるソースコードをコンパイルするために、今まで使ったことがないコンパイラーやインタプリターやビルドシステムやライブラリの手動インストールに悪戦苦闘する必要はない。もちろん、これはソフトウェアをソースコードの形で提供する文化から生まれた必然性であろう。プログラマーは無駄な単純作業を忌み嫌うからだ。

いま理解に苦戦しているのは、Linuxでソフトウェアを作る際、どういう風にディレクトリを使えばいいのかということだ。どうも、binには実行可能ファイルだけをいれ、設定ファイルやドキュメントやその他のリソースは、それぞれ別の対応するディレクトリに入れるのが一般的らしい。しかし、binは単に/binだけではなく、複数あり、それぞれ役割が違う。それぞれの役割はFHSで規定されていて、ほとんどのディストリはこれを守っているようなので、とりあえず今はFHSを頭に入れておけば十分だろう。

ともかく、別のプラットフォームに移行するのは苦労する。このような、初心者でも当然知っているべき基本的なことから学ばなければならないのだから。もはやWindowsはプログラマーの使うデスクトップOSとして未来がない以上、しかたのないことだ。

なぜいまだにシステムプログラミングはCなのか

Programming Language Challenges in Systems Codes

システムコードにおけるプログラミング言語の挑戦、あるいは、なぜいまだにシステムプログラミングはCなのか。

著者がJonathan Shapiroであることが興味深い。Jonathan ShapiroはD&Eに頻出する名前である。Bjarne Stroustrupの記述からして、初期のC++の設計に多大な影響を与えた人物である。それに、最初にC++を使って本格的で大規模なプロジェクトを始めたのも、Jonathan Shapiroだ。しかし、今日、Jonathan Shapiroの名前はC++界では、あまり有名ではない。私はMLとかHaskellなどの言語には疎いので、この方面の話は知らなかった。

なぜシステム・プログラミングは、いまだに1970年代に開発された大昔の高級アセンブリ言語で書かれているのか。自動的に検証可能でガベコレもあってsound typeな、つまりプログラマーが直接にコードを書かずとも、条件を指定するだけで、自動的にチェックを生成してくれるような、そういう言語にとってかわらないのかという問題を考えている。

クライアントサイドでは、新しいプログラミング言語が頻繁に生まれ、一定の成功をおさめている。しかし、ことシステムプログラミングに関しては、プログラマーが直接管理できる言語が、依然として必要なのだそうだ。pre conditionやpost conditionの条件を記述すれば、自動的に検証してくれるような言語を作ろうとしたところで、そもそもシステムプログラミングでは、そのような方法で条件を記述することすら難しいのだそうである。加えてハードウェアの特性が、GCなどの高級な機能ではパフォーマンスが得られない。

インタラクティブなトラフィックにおいては、FoxNetは、当時のUNIX実装に比べて、0.00007倍のパフォーマンスを達成した。これはtypoではない。最も容易に実装できる例ですら、FoxNetはCによるネットワーク実装に比べて、11倍ものCPUロードを必要としたのである。

その後の改良で結果が向上したものの、今のUNIXの実装も当時よりさらに高速になっている。

何故こういう結果になるかというと、ハードウェアの都合上、データは正しくアライメントされていなければならなかったり、またCでは詳細なデータ構造とそのメモリ管理を手動で行うことができるからである。

2006年の結論として、結局CやC++には勝てないということである。2012年の現代でも結論は同じだろう。

2012-03-18

最近のLinuxのディストリ事情

10年前、私はLinuxの使用も検討していたが、結局、当時のLinuxはハードウェアや日本語のサポートが貧弱だったので、Windowsを選んだ。しかし、この業界では10年前というのは大昔である。今はどうなっているのか、ざっと調べてみた。

まず、私の記憶では、10年前の初心者用のディストリは、Red Hat系列が多かったように思う。Red Hat, Turbo Linux, Vine Linuxなどだ。特にVine Linuxは、日本語のサポートが優れていたので、どんなLinux関係の書籍でも、大抵取り上げていた記憶がある。しかし、2012年の今、どのディストリも生き残っていない。Red Hatは有料版のみになり、代わりに、Red Hatを受け継いだコミュニティで開発されているFedoraができた。春高楼の花の宴~♪

DebianとSlackwareはだいぶハードコアなユーザー向けのディストロだったように思う。Debianは大規模なパッケージを提供していて、Slackwareはミニマリスト向けでマイナーだが熱狂的な信者もいるという話だった。Slackwareの状況は、あまり変わっていないように思う。Debianはだいぶ丸くなった。現在人気のUbuntuとその派生ディストリは、結局はDebianからの派生だ。

それにしても、Debianがこの10年を生き残っているのはすごい。

今、ハードコアなユーザーの需要は、GentooやArch Linuxで満たされているように思う。Gentooは数年前に興隆したそうだが、今のArch Linuxの勢いに取って代わられているそうだ。freenodeでは、Archの利用率が高いようだ。

WindowsやMacは、10年前も今も、これほどの変更はない。ひとつの企業によって中央管理されたものだけがリリースされており、派生物が大量に出現しては消えるということはない。中身はだいぶ変わっているが、見た目や操作性に、それほど大胆な変更はない。いわゆる伽藍とバザールか。

しかし、やはりどうも、人気となるディストリには、強力な指導者と資金が必要であるようにおもう。Ubuntuしかり、androidしかり。

プログラマーとして嬉しいのは、主要なLinuxのディストリでは、ライブラリを自前で管理する手間がいらないということだろう。ほぼすべての有名なオープンソースのソフトウェアやライブラリーは、ディストリの公式なレポジトリに存在して、定期的にアップデートされている。そして、わずか数行のコマンドでインストール、アップデート、アンインストールできる。Windowsにもこのような仕組みがほしい。

Linux移行の踏ん切りがつかない

Linuxへの移行は必須である。もはやWindowsはプログラマーにとって快適なOSではない。clangのサポートも悪い。私はこれでもプログラミングをかじっている人間であるし、必要であればCUIにも抵抗はない。Live CDで試したところ、UbuntuのGUIは初心者にも使いやすい印象を受けた。では、なぜまだ私はWindowsを使っているのか。どうも踏ん切りがつかないのだ。

なにしろ、Winodowsは10年使ってきたOSである。勝手が分かっている。しかし、Linuxは未だに慣れぬOSである。どうもこの件に限っては、新しい環境に移行するのがためらわれる。プログラマーとしてはなかなか褒められたものではないが、しかし、プログラマーも人間である非常、やはり変化を嫌う。そうでなければ、CやC++などとっくに滅びていて、もっと使いやすい文法で同等機能を提供する言語が生まれていたことだろう。

ともかく、Windows NTからUnixへの移行はなかなか大変だ。Cの標準ライブラリは、いってみれば、POSIXのサブセットみたいなものなのだが、POSIXはもっと広い。いま、色々と読んでいるが、やはり全体像をつかむだけでも数年はかかるだろう。

The Open Group Base Specifications Issue 7
The Open Group Base Specifications Issue 6

Win32 APIの感覚をつかむまでにも数年かかったことを考えると、まあ、状況は10年前に戻ったわけだ。それにしても、当時といい今といい、私は第一級の資料を参照しなければ気が済まない性質があるようだ。Win32 APIの場合はMSDNだ。

それにしても、つくづく私は回りくどいことが好きと見える。結局、Win32 APIやPOSIXを学んだって、それを直接使うことはない。普通は、有名なクロスプラットフォームのライブラリを使う。だから、そういう低レベルな層について学ぶ必要は、本来ないはずなのだが、どうしてもやめられない。

2012-03-17

MSがOfficeのバイナリフォーマット仕様を公開

Microsoft、「.doc」「.xls」などのOfficeバイナリファイル仕様を公開:CodeZine
Microsoft Office Binary (doc, xls, ppt) File Formats

なんだか、今日はブログに書きたくなるほど面白いニュースが色々と飛び込んでくる。MSがついに、旧Officeのバイナリフォーマットを公開した。これはいい動きだ。というより、当然の動きだ。

すでにOfficeで作られた既存のバイナリブロブは山ほどある。もし、MSが規格を公開しなければ、これらのファイルは数十年もしないうちに読めなくなってしまう。何故ならば、後数十年もすれば、今のOfficeを動かすのが難しくなるからである。たしかに、現時点で実用的なPCエミューレーターはある。しかし、数十年後には、今のハードウェアやOSの操作方法を知っている人間がいなくなってしまうのだ。

何も私は非現実的なことを言っているのではない。MS-DOS 1.0が公開されたのは、今から31年前の1981年である。さて、今、DOSの操作方法を覚えている人間がどれだけいるだろうか。もちろん、まだ多数存在するし、十分なドキュメントが残っているので、知識のある者は操作方法を学ぶこともできる。しかし、可能だからといって、行われるとは限らない。たとえば、今の時代に草書体を学ぶことは可能である。しかし、誰も日本の昔の文献をテキスト化して保存しようとはしない。日本には非常に多くの文献があるのだ。文献とは、筆まめな一個人の旅日記であったり、家計簿であったりする。これは歴史上、文化上、非常に重要なのだ。しかし、あまりにも膨大な量があるので、そのほとんどは世に知られないまま、朽ちていきつつある。この話について詳しくは、網野善彦の著作を参考にされたし。

とにかく、仕様が公開されておらず独占的でユーザーを囲い込む技術に依存してはならない。歴史的文化的に重要な資料が、後世に残らなくなる。

追記:2008年にすでに公開されていたらしい。

ちょっとみないうちにClangがすごいことになってる

freenodeでチャットしていたら、Clang開発者の一人から、Clangは現時点で最も優れたC++11コンパイラーである、と言われた。またまたご冗談を。たしか数ヶ月前に確認した時、ClangはGCCより実装している機能の数で劣っていたはずだ。Clangには確かに将来性を感じるが、まだまだ時間が掛かるだろう。どれ、どれだけ進んだか、一応確認してやるか、と、Clangの状況を確認してみた。

Clang - C++98 and C++11 Status

なんだと!

コア言語では、Forward declarations for enumsとGeneralized attributesとInheriting constructors以外すべて実装し始めているではないか。このうち、ユーザーにも分かりやすい重要な機能はinheriting constructorぐらいなので、実質残すところの機能は後ひとつだけだ。一応、concurrencyのSequence pointsもコア言語と言えないことはないのが、文法上の機能ではない。inheriting constructor以外はSVNで実装しはじめている。これはすごい。

それにしても、Inheriting constructorsが最後の機能になるとは、予想しなかった。私の当初の予想では、主要なコンパイラーが最後に残すのはuser defined literalだと思っていた。いずれにせよ、Clangの開発速度はすばらしい。

3.1が楽しみだ。これでますます、Windowsを使う理由がなくなった。

BloggerがいつのまにかccTLDを変更していた

Bloggerがいつのまにか、閲覧者のあわせたccTLDにリダイレクトするようだ。2月から行われていたとのことだが、いま気がついた。今の時代にURLは、あまり重要ではなくなったからだろうか。このブログは、jpになるらしい。従来の.comはリダイレクトされているようだ。

理由は以下で説明されている。

Why does my blog redirect to a country-specific URL? - Blogger Help

Googleの説明によれば、これは表現の自由を守るためらしい。ある国で違法となる発言は、その国でしか閲覧不可にならないたとえば、私の投稿が日本国において違法であった場合、日本国からしか閲覧不可にはされない。だから、海外からは、普通に見ることができる。もちろん、逆もまた然りだ。これは民間企業ができる最低限の抵抗なのだろう。国を動かすのは企業ではないからだ。

このこと自体は2月から行われていたらしいが。これは全ブログが一瞬にして切り替わるのではなく、ブログごとに時差があるらしい。私のブログの場合、ちょうど今日だったわけだ。おそらく今日の午前11時頃切り替わったように思われる。

著作権法改正案に対する疑問

著作権法の一部を改正する法律案:文部科学省

変更点は、fair useの概念がある他国で認められている権利のいくつかを、日本の著作権の制限に追加しようというものと、電磁的方法を用いたDRM破りの違法化だ。DRM破りの違法化については、実はどうしようもないのだ。なぜなら、日本はすでに著作権に関する世界知的所有権機関条約に加盟しているので、これは単に条約違反だった国内法を整備したに過ぎない。もしこれが嫌ならば、条約から脱退するしかないのだ。

忌々しいDRMのことはさておき、どのような著作権の制限が付け加えられたかというと、写真の撮影等(写真のほかに、録音や録画も含む)の際に、仕方なくうつりこんでしまった著作物を付随対象著作物と定義し、複製と翻案を認めるというものである。はて、複製と翻案だけなのだろうか。じゃあ、公衆送信や頒布はどうなるのだ。私の部屋を撮影した際に、たまたまあの有名なネズミがうつりこんでしまったとする。この録画をYouTubeにアップロードすることは違法なのか? 氏名表示はどうなるのか。すべての付随対象著作物の氏名表示をしなければならないのか。それでは引用とどう違うのか。このままでは何の訳にも立たないのではないか。

概要によれば、著作物の利用となっているのに、実際の文面では、複製と翻案だけだ。これは一体どういうことなのだろう。

そろそろ、Creative CommonsのShare Alikeではなく、GFDLを用いることを検討するべきかもしれない。

Walmart同志が見張っているぞ!

Walmart buys a Facebook-based calendar app to get a look at customers' dates

これは非常に危険なニュースだ。Walmartが会社を一つ買収した。「なんだ、それだけか」と思うかもしれない。問題は、その会社とは、Facebookでカレンダーアプリを提供していた会社なのだ。しかも、1600万人ものユーザーがいるのだそうだ。

つまり、Walmartは会社をひとつ買収することで、その会社が得ていた1600万人分の誕生日やその他の予定などのプライバシー情報を得たことになる。しかもWalmartは、その情報を自社の販促に使うと明言している。

これが合法なのか? たしかに、法的には同じ会社になったのかもしれないが、これまでカレンダーアプリを使っていた人間は、そういうことに使われることを期待していなかったはずだ。これが合法なのか? プライバシーはどうなるのだ。

これは非常に危険な流れだ。もしこれが合法ならば、プライバシーポリシーの同意など存在しないも同義ではないか。プライバシー情報が欲しければ、会社を買収すればいい。Walmartのような大企業にとっては、Facebookのアプリを作っているちっぽけな会社を買収するなど、造作もないことだ。これは非常に危険だ。なぜこれがアメリカで合法なのか分からない。

これが日本の法律ではどうなるのだろうか。もしこんな馬鹿げた迂回方法が合法だとしたら。日本の個人情報保護法はザルだ。

そして、アメリカの会社の提供するオンラインサービスを使っている自分が恐ろしくなってきた。その会社がプライバシー情報を悪用していないだけでは安心できない。その会社が他の邪悪な会社に買収されれば、私のプライバシー情報は別の邪悪な会社に合法的に渡ることになる。祇園精舎の鐘の声には諸行無常の響きがあるのと同じく、たけき者も遂にはほろびるのだ。10年後、Googleが今の地位を保っている保証はどこにもない。もしGoogleが破産の憂き目にあった場合、Googleを買収する会社が出てくる。私のプライバシー情報は合法的に別の会社に吸い取られてしまう。たとえGoogleが邪悪を行わなかったとしても、結局は邪悪になってしまうのだ。

明らかに、法規制が必要だ。

C++11の新機能によるインターフェースの共通化

朝、目が覚めてぼんやりと考え事をしていた。C++11の新機能をどのように活用できるかということについてだ。唐突に、inheriting constructorsはすごく役に立つということに気がついた。

まず、できるだけインターフェースは統一したい。たとえば、std::vectorにT型の要素を入れるのならば、std::vector<T>を使いたい。しかし、もしTがユーザー定義のクラス、MyClassの場合には、必ず、独自のアロケーター、MyAllocを指定したい場合、インターフェースの統一は厄介だ。

std::vector< MyClass, MyAlloc> v ;

古き良きtypedef名を使うという手がある。

using MyVector = std::vector< MyClass, MyAlloc > ;

そして、ユーザーには、std::vector<MyClass>の代わりに、必ずMyVectorを使うようにコード規約で定める。

問題は、誰か一人でも、std::vector< MyClass>と書いてしまったならば、デフォルトテンプレート実引数であるstd::allocator<MyClass>が使われてしまう。コンパイルエラーにはならない。コンパイルエラーにならないコーディング規約は守りにくい。コンパイルエラーにならないのだからチェックも難しい。もちろん、お好きなスクリプト言語でソースコードの静的解析を行うことはできる。しかし、コンパイル時に、ソースコードに対して独自のコード規約確認用のスクリプトを走らせなければならない。そんなビルドシステムのメンテナンスは大変だ。そもそも、テンプレートの場合はどうするのだ。

template < typename T >
void f( T t )
{
    // TはMyClassかもしれない
    std::vector<T> v ;
    v.push_back(t) ;
}

この場合、TがMyClassであるかどうかは、コーディング時には分からない。コンパイル時にしか分からない。したがって、メタプログラミングによるstatic ifが必要になる。幸い、C++11の標準ライブラリにはメタプログラミングに便利なメタ関数が用意されているので、誰でもお手軽にメタプログラマーになれる。

template < typename T >
void f( T t )
{
    typename std::conditional<
        std::is_same<T, MyClass>::value,
            std::vector<T, MyAlloc>,
            std::vector<T>
    >::type v ;
}

いくら標準ライブラリに便利なメタ関数が含まれているからといっても、このコードをスラスラと書くためには、やはり自前でstd::conditionalとかstd::is_sameを実装できる程度の知識が必要になる。私のようなC++情報強者ならともかく、一般ピープルには難しい。第一、いくら知識があるからといって、こんなメタプログラミングを毎回書くのは面倒だ。そこで、メタプログラミングを書くのはライブラリ作者に任せる。

namespace hito {
template < typename T >
struct make_vector
{
    using type =  typename std::conditional<
        std::is_same<T, MyClass>::value,
            std::vector<T, MyAlloc>,
            std::vector< T >
    >::type ;
}

これにより、ユーザーはどのような型Tに対しても、hito::make_vector<T>::typeを使えばよくなる。しかし、これもやはり面倒だ。それに、std::vectorのインターフェースから離れてしまった。そこで、C++11のテンプレートエイリアスの出番だ。これを使うと、ユーザーがnested typeを書かなくても良くなる。

namespace hito {

template < typename T >
using vector = 
    typename std::conditional<
        std::is_same<T, MyClass>::value,
            std::vector<T, MyAlloc>,
            std::vector< T >
    >::type ;
}

これにより、ユーザーはhito:vector<T>を使えばよくなる。だいぶstd::vectorのインターフェースに近づいた。しかし、インターフェースの名前空間が異なる。それに、依然としてユーザーは、std::vector<MyClass>と書くことができてしまう。コンパイラーはstd::vectorを使ったことに対して、何の文句も言わない。さて、どうするか。

実は、ほとんどの標準ライブラリは、ユーザー定義型に対して特殊化することが、規格上明確に許されている。したがって、MyClassに対する特殊化を付け加えてしまえばいいのだ。C++11では、Inheriting Constructorがあるので、これを簡単にしてくれる。

namespace std
{
    template <  >
    struct vector< MyClass, std::allocator<MyClass> > : public vector< MyClass, MyAlloc >
    {
    public :
        using vector< MyClass, MyAlloc >::vector ;
    } ;
}

おそらく、このコードは動くはずである。Inheriting constructorを実装しているコンパイラーがないので、現時点では確かめられないが、規格の解釈を誤っていなければ、正しい。

これにより、ユーザーは型を気にせずに、std::vectorを使うことができる。もちろん、ユーザーが明示的にアロケーターを指定した場合を防ぐことはできないが、そういう明示的な場合を気にする必要はないだろう。

ちなみに、Inheriting constructorを使えない場合、C++03ならば、自前でただ単に基本クラスにデリゲートするだけのコンストラクターの書かなければならない。C++11の場合、ユーザー定義のコピーコンストラクターがあれば、暗黙のコピー代入演算子の宣言はdeprecatedであり、ユーザー定義のムーブコンストラクターがあれば、暗黙のムーブ代入演算子は宣言されないので、代入演算子もデリゲートする必要がある。その数、C++11では何と12個。もちろん、規格を調べて正しい方法で宣言しなければならない。この際、必ず、規格を参考にしなければならない。自分の使っているコンパイラーの実装を参考にしてはならない。なぜならば、規格は、STLの実装においてメンバー関数のシグネチャを一致させることを要求していない。ただ、規格の指定するシグネチャで関数を呼び出した場合、正しく動くことが要求されているのみである。[17.6.5.5]

何にせよ、Inheriting constructorなしでは不必要に難しい。

と、書いていて思ったのだが、やはりテンプレートエイリアスあたりで止めておいたほうが正解かもしれない。

2012-03-16

TwitterのAPIに大幅な変更が来る

API Housekeeping | Twitter Developers

今日、Google ReaderがTwitterのユーザーへのURLから、フィードのためのURLを自動生成する挙動が止まっていることに気がついた。昨日あたりまでは確かに動いていたはずなのに、何故だろう。仕方ないので、Twitter APIを調べて追加した。Twitter APIの利用は非常に簡単だった。

やれやれと安心していたら、このアナウンスだ。

API Housekeeping | Twitter Developers

5月14日をもって、バージョン番号がないAPIはすべて廃止される。deprecatedなAPIも廃止される。ATOMフォーマットも廃止される。RSSは残るらしい。やれやれ。

さて、これで気になるのはGoogle Readerだ。Google Readerは、TwitterのユーザーのURLを渡すと、そこからなぜかドキュメント化されていないAPIを使う。

http://twitter.com/statuses/user_timeline/xxx.rss

という形式のものだ。xxxにはユーザーIDが入る。しかし、Twitterのドキュメントには見当たらない。どういうことだろう。それに、バージョン番号もない。つまり、あと一ヶ月で、既存のフィードは動かなくなる。

ひょっとしたら、Google Readerがいま、TwitterのURLからフィードURLを自動生成しないのは、これに対処するためではあるまいか。

しかし問題は、Google Readerに登録されている既存のフィードだ。Google ReaderからTwitterを購読している人間は少なからずいるはずだ。だからこそGoogleは、自動的な変換を提供していたのだろう。これを一体どうするつもりだろう。既存のフィードに対して変換をかけるのだろうか。

それに、バージョン番号のないAPIはまだ広く使われているはずだ。それが後一ヶ月で動かなくなる。Twitterを嫌う私のような人間ですら、Twitterの購読を強いられるほど、今の世はどこもかしこもTwitterなのだ。これはかなり差し迫った危機である。

この業界では、下位互換性は非常に重要であり、必ず守らなければならない。しかし、Twitterが下位互換性を失うような変更をしたのは、たしかこれが初めてではない。前にもあったはずだ。やれやれ、これだからTwitterは信頼できぬのだ。

twitterのフィードURL

私のように、およそフィード可能なものはすべてGoogle Readerで読みたい人間は、TwitterもGoogle Reader経由で読む。いつもなら、何も考えずにユーザーのURLをsubscribeに放り込めばいいのだが、どうも今日はGoogle Readerでは、なぜか動かない。そこで、手動でやることにした。

TwitterはHTML内にフィードURLを指定していないが、フィードURLはREST APIを使うことで作成できる。使うAPIはこれだ。

GET statuses/user_timeline | Twitter Developers

http://api.twitter.com/1/statuses/user_timeline.formatがURLである。対応しているformatはXML、JSON、RSS、ATOMである。ただし、XMLやJSONでは、引数にinclude_rtsを含めないとRTは取得できない。今回はフィードURLを作りたいので、RSSかATOMを使う。ユーザーを指定するために、引数として、user_idかscreen_nameを与えてやればよい。user_idの取得は面倒なので、screen_nameを使うほうが簡単だ。

たとえば@twitterのフィードURLをRSSとして得たかったら、以下のようになる。

http://api.twitter.com/1/statuses/user_timeline.rss?screen_name=twitter

もちろん、SSLも可能だ。

https://api.twitter.com/1/statuses/user_timeline.rss?screen_name=twitter

追記:ATOMフォーマットは5月に廃止される。詳しくは、API Housekeeping | Twitter Developersを参照。

もし、読者が原理主義者ならば、ATOMを使うこともできる。

https://api.twitter.com/1/statuses/user_timeline.atom?screen_name=twitter

しかし、最近はRSSとATOMの論争も聞かなくなった。大抵のサイトでどちらもサポートしているが、結局使われるのは、RSSの方が多い。なにしろRSSが先発なのだから、そのぶん知名度も高い。xkcd: Standardsを思い出す。

ちなみに、Google Readerが自動的に使っていたのは、どうも不思議なAPIで、http://twitter.com/statuses/user_timeline/user_id.rssとなっている。user_idの部分を適切なuser_idで置き換える。

また、GET search APIを使えば、エゴサーチが簡単にできる。例えば、このブログに言及しているtweetをすべてみるには、以下のようなURLを使えば良い。

http://search.twitter.com/search.rss?q=cpplover.blogspot.com&result_type=recent

Mozilla、H.264を見直す

On H.264 Revisited | Robert Accettura's Fun With Wordage

さもありなん。H.264は、特許の問題があるにせよ、すでに広く使われている。H.264のハードウェアデコーダーは多く開発されているので、スマートフォンでも再生できる。一方WebMは、いまだに一部の原理主義者しか使っていない。ハードウェアデコーダーはどこにあるのか。Google Chromeはかつて、将来H.264のサポートをやめると公言した。一体いつになったらChromeから取り除くのか。

結局、様々な問題はあれど、H.264が、現時点では一番現実的な規格なのだ。

nVidiaにおけるLinuxのKMSの参考になるリンク

Feature Request: KMS support - nV News Forums
All about Kernel Mode Setting (or why your $500 nVidia card only displays in 16-colors) | Scott James Remnant
nouveau Wiki - CodeNames

しばらく、プロプライエタリなnVidiaドライバーによるKMSのサポートは期待できなさそうだ。

Fermi系列はnouveauでもサポートされているらしい。では何故動かないのか。恐らく、Ubuntu 11.10が古いからではないだろうか。

Not all of these cards already work well using Nouveau, development is in progress. It is recommended to use the Linux 3.1 kernel or newer (or a backported driver from this kernel).

というわけで、3.2.6カーネルをつかうUbuntu 12.04 Precise Pangolinを待ってみようか。

Ubuntu Live CDの感想

まだUbuntuを使うと決めたわけではないが、ともかくも有名なディストリであるからして、使い心地をためしてみることにした。

kernel mode setting以外には、さして問題はなかった。どの程度簡単に使えるかを試すため、あえて事前にUnityの操作方法を学ばずに試したが、ネットワークの設定以外は簡単であった。ネットワークの設定も、もうすこしUIが洗練されていて欲しいとは思うが、すくなくとも、すべてGUIから設定できた。

ネットワークの設定のUIの問題点は、どこで設定するのかわかりづらいということだ。私はルーターを使っておらず、DSLモデムに直接つないでいる。したがって、PPPoEの設定をしなければならない。いかにもそれらしい、左のドックから起動するシステム設定の項目がアイコンとしてズラリと並んでいる場所からでは、なぜか新しい設定を追加することができなかった。すでに用意されている設定は、ルーター用なので使えないようだ。新しい接続の設定を追加するには、なぜか、上部の細いバーの上にあるアイコンをクリックしてメニューを出し、そこから新しい設定を追加するという旨の項目を選ぶ必要があった。それさえ終われば、後は、認証すれば接続できた。Live CDなので試してはいないが、一度設定した後、起動時に自動で接続する項目もあるので安心した。サスペンドから復帰した場合も自動で接続してくれるのだろうか。インストール後に試そう。いや、まずサスペンドが正しく動くかどうかも確かめなければならぬ。

それ以外は、何の問題もなかった。NTFSでフォーマットされたHDDも読み込めるようだ。ただ、実際に使う際には、nVidiaの非フリーなドライバをインストールしなければならないだろう。日本語入力は試していないが、たぶん大丈夫だろう。

他のディストリの選択肢としては、DebianかFedoraを考えている。ただ、とりあえずUbuntuにしておいたほうが無難かもしれない。自前ビルドマニア御用達のGentooは問題外として、Arch Linuxも不必要に難しそうだ。Slackwareってまだ生き残っているんだろうか。確か10年前でもマイナーだったと思うが。

2012-03-15

nomodesetとLinuxにおけるGPUドライバーの問題

前回、コメントからヒントを得て、カーネルパラメーターにnomodesetを渡した結果、Ubuntu Live CDの起動に成功した。しかし、釈然としない。ともかく、調べた範囲を書いてみる。

まず、nomodesetは何をしているのかというと、kernel mode settingを無効にする。mode settingとは、画面の解像度やビット数を変更するための規格である。これは、カーネルスペース(Linux)で行うこともできるし、ユーザースペース(X)で行うこともできる。カーネルスペースで行う利点は、パフォーマンスやフリッカーのない変更などの様々な利点をもたらすし、セキュリティ上も、ユーザースペースで動くコードに不必要な権限を与える必要がないという点で優れている。Linuxカーネルは2.6.28でIntelからGEMを提供されて、カーネルスペースでのmode settingに移行した。

ところが、IntelやATIのGPUはそれなりにサポートされているのだが、nVidiaは相変わらずのバイナリブロブでドライバーを提供しており、この変更にも追従していない。結果として、ブートに失敗する。私はnVidiaのGPUを使用しているので、これは問題になる。

しかしよくわからないのだが、UbuntuのLive CDにはnVidiaのプロプライエタリなバイナリブロブは含まれていない。nouveauという、nVidiaドライバのリバースエンジニアリングの結果を元に開発しているフリーなドライバーが使われている。nouveauはmode settingをサポートしている(むしろnomodesetでは動かない)という触れ込みなのだが、事実として、nomodesetでなければ動かない。まったく釈然としない。

追記:kernel mode settingを無効にすると、フォールバックとしてnVidiaがかつて最低限のサポートのために公開していたオープンソースのドライバー、-nvが使われるらしい。

問題は、Linuxにおけるこれらの諸問題の情報が、全然まとまっていないということだ。このフォーラムにぽつり、あのフォーラムにぽつり、このディストリのwikiにぽつり、あのディストリのWebサイトにぽつり、X.orgのサイトにぽつり、といった具合に、バラバラに散らばっている。単体では問題の本質が理解できない。これだけのことを調べるのにも、ひと手間かかった。なにも、カーネル側でのmode settingは最新の機能というわけではない。Windows NTは大昔から実装しているし、Linux Kernelは2.6.28からなのだから、2009年の1月である。3年前からある問題が、いまだもって、こちらにぽつり、あちらにぽつりというのは、一体どういうことだろう。それも、nVidiaのGPUのような有名なハードの問題で、まともにブートできない深刻な問題なのだ。

もちろん、フリーを尊びプロプライエタリを拒否する原理主義者は、nVidiaのハードウェアなど使わないのかもしれない。しかし、現時点で真にフリーな個人用コンピューターは、Yeelong notebookぐらいしかないではないか。しかもRMSは、最新のYeelongを批難している。GPUにATIを選択肢したという理由でだ。ATIのドライバーは完全にオープンソースというわけではなく、一部バイナリブロブが残っているらしい。

ともかく、Linuxで何かするたびにこんな低レベルな問題に一喜一憂しなければならないとしたら、実際の作業はWindowsで行い、どうしてもLinux側で必要な作業はsshでLinuxに接続して行うという、一件不思議な使い方も、妥当に思えてくる。すくなくとも、Xを使わなければこういう問題は些細な事であろうから。

参考:
Mode setting - Wikipedia, the free encyclopedia
Graphics Execution Manager - Wikipedia, the free encyclopedia
X.Org Wiki - Home
その他多数のフォーラムや各種ディストリのWebサイト

Richard Stallmanへのインタビューがすごい

Richard Stallmanへのインタビューがすごい。

Richard Stallman | The GNU/Linux Action Show | Jupiter Broadcasting

Stallmanは聞きしに勝る高潔ぶりだ。ストールマンは、あらゆる創作物はフリーに共有できるべきだと考えている。例えば、誰かが壁に絵を描いて公開した場合、誰でもフリーにコピーできるべきだと考えている。たとえ、画家がコピーさせたくないと考えたとしてもだ。ストールマンによれば、フリーとはユーザー側にあるのだ。ユーザーはコピーするフリーを有しているというわけだ。例え画家がコピーされたくないフリーを主張したとしても、ユーザーのフリーが優先されるのだという。そもそも、フリーな世界ではあらゆるものは共有可能であるべきだからだ。フリーとはユーザーにかかるのだ。

皮肉なことに、ストールマンは現行のアメリカ合衆国の著作権法に反対しているが、ちゃんと現行法を守っている。GPLからして、アメリカ合衆国の著作権法を根拠に書かれているのだし、ストールマンは一切の非フリーなソフトウェアを排斥している。ストールマンの使っているコンピューターも完全にフリーなYeelongである。OSはUbuntuから非フリーなソフトウェアとプロプライエタリなソフトウェアのインストール方法を取り除いたgNewSenseである。

しかし、ストールマンの信じるフリーの概念を押し通すと、現代では、日々の生活の糧を得ることすら難しい。ストールマンは、非フリーなソフトウェアを作るなどということは、自由を失うことであり、そのようなソフトウェアは放擲すべきであると信じている。

しかしたとえば、ゲームを、ソースコードはおろかその他のリソースまで完全にフリーで売るのは難しい。なぜなら、フリーなコンテンツを売るということは、誰か一人さえ買えば、あとはカネを払わずコピーされてしまうからだ。現行のフリーなソフトウェアにしたって、多くはプロプライエタリなソフトウェアを売っている企業からの献金や、同じくプロプライエタリなソフトウェアを売っている企業に雇用された人間が開発している。もし、世界からプロプライエタリなソフトウェアがなくなれば、利益が減り、当然、フリーなソフトウェアの開発も縮小してしまう。ただし、ストールマンによれば、それでいいらしい。

ストールマンの考えでは、自由のない世界は、制限された栄えている世界より邪悪である。ソフトウェアがフリーである限り、たとえ、利益がないことによってフリーなソフトウェアの開発が止まったとしても、他人が開発を引き継ぐことができる。

「しかし、フリーだけになって産業の規模が縮小してしまっては元も子もないではないか、第一、フリーを実現するためにコピーされない権利の放擲など様々な制限を課さなければならないとしたら、果たしてそれをフリーと呼べるのか」という反論に対して、ストールマンは、「そもそもそんなことは問題ではない」と答えるのみである。自由がないアメリカ合衆国では、無実の者が弁護の機会も与えられずに拘束されていたりする。正当なデモの権利を行使した人間が拘束されている。そのようなフリーではない世界で、富が、現金が、一体何の役に立つというのか。

「すべてのソフトウェアがフリーな世界で一体どうやって利益を得るのか」という疑問に対する、ストールマンの唯一の答えは、カスタムソフトウェアである。

これを考えてみると、ソフトウェアをカスタマイズしてほしいという要求は常にある。自分にはソフトウェアをカスタマイズする能力がなかったり、例えあったしても、時間や労力がなかったりする。その場合、他人にソフトウェアのカスタマイズを依頼し、その作業に対し対価を払うということは、十分に妥当だ。この際、ソフトウェアのカスタマイズを必要としているのはユーザーである。もし、対価を払わなければ、ソフトウェアのカスタマイズは行われない。その結果、ユーザーはカスタムソフトウェアを入手できない。入手できないものは、フリーな世界であっても入手できない。ここに、利益を得る機会が生まれるのだろう。

しかし、そんな世界では、経済の規模はかなり縮小してしまうだろう。第一、Microsoftにしたって、Red Hatにしたって、数多くいる社員のうち、プログラマーはほんの僅かである。むしろ大企業ほどそうなのだが、プログラミング以外の作業は常に必要である。そのため、どんなソフトウェア企業でも、大抵はコードの書けない人間を雇っている。大企業の場合、プログラミング以外の作業が非常に多いため、社員のうちのプログラマーの割合は非常に低くなる。もし、すべてのソフトウェアがフリーな世界になれば、MicrosoftやRed Hatのような会社は、今の形では成り立たなくなるだろう。たとえ存続するとしても、大幅に規模を縮小することになるだろう。それでいいのだろうか。

ストールマンの言うことには、「そもそもそんなことは問題ではない」のだそうである。フリーかどうかが問題なのだ。

Javascriptを完全に理解しているための必須要件

大学で日本におけるエンジニアの地位の低下を象徴している求人見つけた [必須条件] ... - HAMPAD

必須条件がJavascriptを完全に理解していることとはすばらしい。思うに、Javascriptを完全に理解していると主張するためには、少なくとも以下の条件は最低でも満たしているはずである。

  • ECMA-262 5thの全文を暗唱
  • 過去にV8程度のパフォーマンスをもつJavascriptライブラリを実装
  • Brendan EichやJohn ResigやDouglas Crockfordとは、ファーストネームで呼び合う仲である

そんな人材がゴロゴロしている職場か。なかなか楽しそうだ。

2012-03-14

Linuxが起動しない

なぜか分からないが、今使っているPCでLinuxが起動しない。UbuntuとKNOPPIXのLive CDを試してみたが、途中で止まってしまうようだ。せっかく新しいHDDを買ってきたのにこれは困った。

Ubuntuでは、32bitと64bitのLive CDを両方試し、またUSBとDVDの両方を試したが、皆、同じ結果に終わる。なにやら、udevd[128] : /sbin/modprobe -bv pci:xxxの次に、terminated by signal 9(killed)と表示された後、マウスやキーボード、HDDやUSBメモリやDVDドライブを認識した旨を表示して、そこで止まってしまう。画面には、キーボードからの入力がそのまま表示される。ただ入力がそのまま画面に表示するばかりで、コマンドなどは使えないようだ。Ctrl+Alt+ファンクションキーには反応するが、ただ何も表示されない画面に切り替わるだけだ。

KNOPPIXは、何やらメッセージらしきものを一瞬だけ表示した後、すぐに何も表示されない画面になってしまう。CDも回転していないし、5分ほどまってみたが、何も起こらない。あまりにも早くて、何が起こっているのかわからない。Ctrl+Alt+ファンクションキーもきかない。あるいはきいているのかもしれないが、分からない。

せめてUbuntuのメッセージが完全に読めればいいのだが、modprobe云々の興味深いメッセージの後に、マウスやらキーボードやらを認識したメッセージが入るので、上に押しやられてしまう。Xとか贅沢なことは言わないので、せめてシェルが起動するところまでいければ、dmsegコマンドでメッセージを読めるのだろうが。

念のためisoイメージのハッシュ値をチェックしてみたが、一致する。ダウンロードの際にファイルが壊れたのでもなさそうだ。

さて、どうするか。Debian系列以外のディストリを試してみる手もあるが、どうも問題はそこにあるのではない気がする。あるいは、Live CDが動かないのだろうか。Ubuntuのalternate installerを試すべきかもしれない。

BIOSのメニューをみても、特に影響しそうな項目は見つからない。レガシーOSへのUSBマウスのサポートだとか、ACPIを使うかどうかなどといったことぐらいだ。

最も手っ取り早い解決方法は、新しいPCを買うことだろう。

ちょうどこれを思い出した。

How to fix any computer - The Oatmeal

どんなコンピューターでも直す方法

Windows

手順1. 再起動

直った? 直らなければ手順2へ。

手順2. HDDをフォーマットしてWindowsを再インストールする。今までのファイルが全部消えちゃう。泣きべそかく。

Apple

手順1. アップルストアにもってく

直った? 直らなければ手順2へ。

手順2. 新しいMacを買う。借金でクビが回らなくなる。泣きべそかく。

Linux

手順1. C++を学ぶ。カーネルを再コンパイルする。その辺に転がってるシリコンでCPU作る。もいっかいカーネルの再コンパイル。ディストリ変える。もっかいカーネルの再コンパイル、ただし今度は、土星からの光エネルギーでCPUを動かす。ヒゲをたくわえる。サン・マイクロシステムズのせいだと決め付ける。寝室をサーバールームに改造し、けたたましいファンの騒音の元で10年寝る。もっかいディストリを変更。風呂に入るのをやめて手も洗わず過ごす。プログラマーが血の涙を流すような正規表現を書く。Javaを学ぶ。もいっかいカーネルの再コンパイル(ただしこんどは、お守りの靴下をはいて行う)

直った? 直らなければ手順2へ。

手順2. WindowsやMacに戻る。泣きべそかく。

まだ6年しかたってない

たまたま、Andrew Koenig氏と技術的ではないメールを交わす機会があったので、氏がBarbara Mooと共著したRuminations on C++は、まだ私がプログラミングやC++の基礎を勉強していたころ、たいへん役に立ったと感謝の意を述べたのだが、そこでふと気がついた。

私が初めて、Rumminations on C++読んでから、まだ6年しかたっていないという事実である。なんということだ。まだ6年しかたっていないのか。私がRuminations on C++を読んだのは、もうだいぶC++について理解していた2006年だったのだが、それでも、あの本の簡単な英語と、その内容の濃さと、しかも本が1996年頃書かれたという、この業界ではもはや古典とみなされる大昔に書かれたのにもかかわらず、一向に古びていない内容に驚いた。この2012年でも、まだこの本には価値があるのだ。なぜか、世間ではEffective C++(Scott Meyers著)だのExceptional C++だの(Herb Sutterの著作)、Accelerated C++(同じくAndrew KoenigとBarbara Mooの共著)が評価される傾向にあるが、私はこの、Ruminations on C++が、C++のテクニックを解説する最も優れた本であると思う。むしろ、C++以外にも適用できる本であると思う。

非常に簡単な英語で書かれているので、原文で読むことをおすすめする。

まだ考案されたばかりだったC with Classesに対してAndrew Koenigが与えた影響は大きい。この本はC++の言語を解説した本というよりも、もっと一般的な、あまり好きな名前ではないが、デザインパターンと呼ばれるような作法を説明しているような本だ。C++の言語自体の解説は少ない。だから、古びないのも当然だ。第一、古びて使いものにならないデザインパターン、アルゴリズム、データ構造などというものが、いいデザインパターンのはずがない。(もっとも、当時のハードウェア事情から、今は価値がないが当時は価値のあった技術や知識は、当然あるのだが)

ところで、Barbara Mooも執筆に一枚噛んでいるC++ Primer 5th が今年の夏に発売される。

さらに今後、Andrew KoenigとBarbara MooによるAccelerated C++の書き直しが予定されているらしい。

さらにメールで教えてもらったのだが、Andrew Koenigは、Andrew Koenig's Bio | Dr Dobb'sで、Ruminations on C++のようなコンセプトで記事を書いているらしい。

2012-03-12

邪悪なJSONライセンス

JSON.org License Literally Says it "shall be used for Good, not Evil" | Javalobby
JSON.org License Literally Says it "shall be used for Good, not Evil" | Hacker News

JSONライセンスというものがある。

The JSON License

このライセンスは、見たところ、MITライセンスに一行加えたもののように思われる。

Copyright (c) 2002 JSON.org

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The Software shall be used for Good, not Evil.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

追加された文面が実に危険な響きだ。"The Software shall be used for Good, not Evil."とある。すなわち、「本ソフトウェアは善をなすために使うべし、悪をなすなかれ」

さて、いうまでもなく、これは非常に危険である。善とは何か。悪とは何か。その定義が一切与えられていない。すると一般的な意味での善悪になるのであろうが、一体何をもって善悪とするのかは、このソフトウェアを使用する該当の国や文化や集団、個人によって、甚だ異なる。単に法律に違反しないのみが悪ではないのだ。このソフトウェアは、ライセンスに違反せずに安全に使うことは出来ない。

さて、AppleのiOSは、このJSONライセンスの影響を受けるらしい。Appleファンボーイの読者も大変だ。Appleの独占的なプラットフォームの奴隷に甘んずるだけでは飽きたらず。善悪に言及するライセンスに縛られるのだから。

しかし、使用に際して善悪の定義を持ち出すというのは、オープンソースの精神に反する。このライセンス自体が、私からすれば邪悪なライセンスだ。MITライセンスにこんな子供の悪ふざけのような文面を付け加えたばかりに、すでにJSONライセンスされているソフトウェアを過去に一度でも使ってしまった企業の顧問弁護士が頭を抱えることになるだろう。

2012-03-07

bsnesがついに完成したそうだ

byuu's homepage
SNES Coprocessors — The Future Has Arrived
via: Bsnes has emulated every SNES DSP | Hacker News

bsnesというオープンソースのスーパーファミコンのエミュレーターがある。このエミュレーターは、スーパーファミコンを極限まで正確にエミュレートする目的で開発されていた。正確というのは、ソフトごとのハックなしに、実機とサイクル一致で、すべての商用ソフトを実行するということだ。このたび、bsnesはすべての商用ソフトをサポートした。最後に残っていたプロセッサーは、1995年に発売された、「早指し二段 森田将棋2」で使われていたST018である。

これで、百年、千年後の未来の歴史家は、ゲームの歴史について学ぶ時、すべてのスーファミのゲームを正確に再現して研究することができるようになる。

スーパーファミコンの仕様は公開されていないので、エミュレーターを開発するには、ハードを解析する必要がある。問題は、スーファミはカセット側に独自のチップを載せられるので、スーパーファミコン本体だけをエミューレートしたのではどうしようもない。また、エミュレーターの実装が正確ではなく、動作が実機と異なってしまう場合がある。従来のエミュレーターは、そのような場合、ソフトごとのハックを用いていた。あるソフトは、特定の状況で動作速度が落ちるので、処理速度を上げてやるとか、そういったたぐいのハックだ。bsnesには、ソフトごとのハックが存在しない。

また、ひとくちにプロセッサーの正確なエミューレートといっても、二種類ある。プロセッサーの内部実装を調べて、同じ挙動をするコードを書く。これは低レベルエミュレーションといい、理想だが、プロセッサーの仕様が分からない場合、不可能である。もうひとつの方法は、プロセッサーをブラックボックスと見立て、外から観測する方法である。可能なあらゆる入力を与えて、対応する出力を記録し、その結果から、同じように動作するコードを書く。これを高レベルエミュレーションと呼ぶ。

仕様のわからないプロセッサーの解析というのは、チップを基盤から剥がし、カバーを取り除き、電子顕微鏡で撮影することから始まる。非常に手間と技術のかかる作業である。bsnesの作者は最近、その技術をもつ人間を見つけたらしい。しかし、解析にはカネがかかる。そんなわけで、作者はここ数年寄付を募っていた。その寄付によって、これまで仕様が判明していなかった、DSP-1、DSP-2、DSP-3、DSP-4、ST010、ST011、ST018、Cx4を解析できたそうだ。

それ以前にも、bsnesはSPC7110を世界ではじめてエミューレートし、またサイクル一致の SPC700、 SuperFX、スーパーゲームボーイのエミュレーションを始めて実装したエミュレーターでもある。最後のスーパーゲームボーイは重要である。なぜならば、スーパーゲームボーイはスーパーファミコン上で動くので、完全なスーパーファミコンのエミュレーターを目指すならば、当然スーパーゲームボーイも漏らしてはならない。

さて、最後に残ったのはST018である。これはたった一つのソフトにしか使われていない非常に珍しいプロセッサーである。ソフトの名前は、「早指し二段 森田将棋2」。将棋ソフトは処理速度を必要としたので、独自プロセッサーをカートリッジ側に搭載したのも分かる話だ。

その解析裏話も面白い。どうやら、ST018にはデバッグコマンドがあり、プログラムや内部ROMをダンプする機能があった。デバッグコマンドを実行するのは難しいが、Blarggというこれまた有名なエミュレーター作者によって、スーパーファミコンにシリアルポートをつなぎ、PC側から任意のコードを実行させることができるツールが提供された。さて、ダンプはできたのだが、一体どのような言語なのかわからない。そのバイナリを実行するHLEコードもない。幸運なことに、Cydrakなる人物がバイナリを一目見ただけで、ARMv3 CPUだと鑑定してくれたので、実装を終えることができた。

それにしても、当時スーパーファミコンでARMプロセッサを搭載した将棋ソフトがあったとは驚きだ。コンピューター史としても興味深い。検索してみると、当時のソフトの価格は14900円だったらしい。

ところで、最初のスーパーファミコンのソフトが発売された年を覚えているだろうか。1990年である。

スーパーファミコンのゲームタイトル一覧 - Wikipedia

ということは、映画ではないゲームは2041年から、映画であるゲームは2061年から、徐々に著作権が切れ始めるということだ(ゲームが映画であるかどうかは個別の判断になる)。老後が楽しみだ。

ちなみに、作者はすべてのスーパーファミコンのソフトをコレクションしたいそうである。後残っているソフトは35本、ちょっと近所の中古屋を回ってみようかと思う。

List of Missing Boxes

追記:どうもいくつかの中古品はAmazon.co.jpにありそうである。

追記2:bsnesはポータブルなコードであり、またC++11の機能もふんだんに使っているので、ソフトウェアとしても興味深い。

Chrome 17.0.963.65のアップデートが停止されたわけ

Chromeのstable release 17.0.963.65が、5日に出ていた。

Chrome Releases: Chrome Stable Update

しかし、なぜかアップデート出来ない。どうしてかと思ったら、深刻なバグがあったかららしい。

Issue 116789 - chromium - Javascript getElementsByClassName result list no longer changes on class changes - An open-source browser project to help move the web forward. - Google Project Hosting

GetElementsByClassNameで返されるNodeListはliveであり、動的に変更される。例えば、クラス名を変更したらNodeListから削除される。なんとも実装が面倒そうな仕様だが、そういう仕様になっているのだから仕方がない。

こういう仕様のもとでNodeListを実装しようとしたら、二度目以降の要求に対しては、あらかじめ内部的に確保しておいた「何か」を渡すような実装になっていてもおかしくない。なぜなら、NodeListは生きているからだ。Chromeはどうもそういう実装なのか、クラス名を動的に変更した後、二度目以降のGetElementsByClassNameで、変更が反映されることがなくなってしまうらしい。そのバグが重複として上がっている。

Issue 116955 - chromium - getElementsByClassName failed to get modified data - An open-source browser project to help move the web forward. - Google Project Hosting

17.0.963.65がこの挙動をぶち壊してしまったので、急遽止めてまで修正していたらしい。いまは、17.0.963.66が出ている。

ちなみに、新しめのAPIであるquerySelectorAllの返すNodeListはliveではない。

Selectors API Level 1

さすがに、こんな仕様には懲りたのだろう。新しいAPIにも従来の変な挙動を持ち込む必要はない。

2012-03-06

バイトをはじめることにした

そろそろ食費にすら事欠くようになったのでバイトをすることにした。一日数時間の掃除だ。おそらく、C++本の執筆にはさほど影響しないだろう。

結局、結果からいえば、当初の目論見であった、貯金の続くうちに、全力でC++本を完成させるというのは、無理だったわけだ。やれやれ、最初から働きつつ執筆すべきだったのか。

C++本は、ようやくオーバーロード演算子まで進んだ。といっても、途中のBasic Conceptsに当たる部分は飛ばしたし、コピーとムーブも飛ばした。コピーとムーブはどう書けばわかりやすくなるのか分からない。純粋なコア言語機能だけ説明してもわかりにくいし、かといって、プログラミングテクニックまで説明するのは本書の範疇ではないように思う。コア言語に絞ってさえこの分量なのだから、最初の壮大な野望通り、標準ライブラリまで手を広げようと思ったら、いつまでかかるか分からない。

そもそも、一冊のまとまった本という形式が、もう時代遅れなのかもしれない。まとまった本を書くには何年もかかるが、その間に技術はさらに先にと進んでいる。この数年、C++の規格を読み、C++の文法と機能を考え、いかに短いサンプルコードでC++の言語機能を説明するかという、参考書を書くための能力ばかりに苦心してきたので、コーディングからだいぶ離れてしまった。最近のプログラミングの環境や、その周辺の支援ツールなどの状況にも疎くなっている。

つまり、私は、どんどんプログラマーとして劣化しているのだ。何とかしなければならないが、なんともならない現実もある。私は日本のC++プログラマーを済度するべく努めてきたのに、全然うまくいっていない。

理想をいえば、本物のC++プログラマーとして働きつつ、余暇に、ブログでC++について書くべきだった。そうすれば、最新の技術から取り残されることもない。完全な本を書き上げるのは無理だが、短い記事なら書ける。いまだにこのブログの昔のC++記事にも検索から飛んでくる人間がいることから考えても、昔、拙い知識で書いた記事の方が、よほど日本のC++プログラマーの役に立っている。あるいは、執筆中の本をGFDLのような自由なライセンスで公開して、一人ではなくコミュニティで作成する自由な著作物として発展させていくべきだったのかもしれない。直接に金銭的な利益は得られないとしても、より優れた日本語のC++のドキュメントが得られる。その方が、よほど日本のC++プログラマーを利する結果になっただろうに、ああ、失敗した。

問題は、私の働くべき職場がないのだ。本物のC++プログラマーを必要とする職場が日本にないのだ。かつて何社も求人広告をあたってみたが、C++を本気で使うような職はみつからなかった。たとえあるにしても、新卒既卒のお手軽学歴フィルターを採用しているので、私などは門前払いなのだ。学歴フィルターがなかったとしても、本物のC++プログラマーを必要とする仕事は、C++以外の高度な技能、自然言語処理とかコンパイラーとか3Dプログラミングとか数学とか物理学とかを必要とするので、結局、私では役に立たないのだ。詰んでいる。

一体どこで間違えたのだろう。英語を学んだことに問題はないはずだ。C++を選んだことにも問題はないはずだ。C++の他に許せる言語はJavascriptしかなかったが、Dartのある今、Javascriptはすみやかに滅ぶべきである。新しい技術を学ぶことにも抵抗はないが、どうも好みが激しい。JavaやObjective-Cなどは死んでも使いたくない。これでは、まともな仕事が見つからないわけだ。

おそらく、ソーシャルが理解できないというのが問題なのかもしれない。私はいまだにTwitterをやらないし、ソーシャルゲームなど見向きもしない。携帯も嫌いだ。少なくとも、携帯というプラットフォームが囲い込みをやめ、自分の所有するコンピューターの動作を自分で検証できるようになり、すなわちPCと同じぐらい自由になるまでは、携帯は嫌いだ。私は時代に遅れているのだろうか。Twitterの興隆は、情報をあまりにも細かくしてしまった。情報は140文字で表されるため、ブログのようにまとまった文章にならないし、検索もしにくい。ソーシャルゲームは・・・ゴミだ。あんなものは本当のゲームではない。そりゃ、実装には技術的な困難もあり面白いかもしれないが、ゲームとしては面白くない。パチンコにハマる客層を相手にしているのだ。擬似乱数と喜んで戦い、数字がゆっくり加算されていくのを眺め、デフラグ画面を楽しむような人種のためのものだ。もっとも、私の好きなゲームのプラットフォームはスーパーファミコンなので、やはり古い人間なのかもしれない。それにしても・・・。

ともかく、好むと好まざるとにかかわらず、今、技術的に面白いことは、ソーシャル系のサービスに集中していることは事実だ。しかし、私にはソーシャルが理解できない。ああ、言うをやめよ。

2012-03-05

githubとEgor Hamakov

Egor HomakovがGitHubから蹴られたようだ。
Egor Homakov: i'm disappoint, github

彼はrailsのセキュリティ上非常に問題を起こしやすい仕様を報告したが、まともに取り扱われなかった。
Issue #5228: Mass assignment vulnerability - how to force dev. define attr_accesible? · rails/rails · GitHub

問題はrails限定というわけでもないのだが、平均的なユーザーがこれを防ぐには、正しく問題を知っていなければならない。そういう問題は、ユーザーではなくソフトウェア側で対処すべきなのだ。

しかし、無視された。そこで彼は、railsの最も有名なサイト、GitHubで実証した。GitHubにすらこの問題で間違いを犯していたのだから、どんなサイトでも間違いを犯している可能性がある。

Egor Homakov: How-To

そしてGitHubから蹴られた。文化的ではない対処法だ。

2012-03-04

Linuxについて少し調べた

実は、私はLinuxについては、だいぶ前、まだコンピューターを持っていなかった頃、少々学んでいた。というのも、当時まだコンピューターを持っていなかった私は、書物(当時はまだ紙の本に価値があったのだ!)の知識から、どうもLinuxの方が優れているOSだと思っていたらしい。宗教論争を引き起こしそうな話題はともかく、当時の私は、結局、日本語環境の貧弱さとゲームとを理由に、Windowsを使うことに決めた。今から10年以上前の話だ。

どうも私は変人と思われているらしく、twitterをエゴサーチしてみると、私がLinuxにダメ出しするだろうというtweetを目にする。まあ、確かに、私は常に物事を否定するところの霊であった。中学時代からの私の友人は、「何事にも否定的」と評した。否定した結果、今の位置にいるのだとすると、あまり否定すべきではないのだろう。

閑話休題、今のLinuxはどうなっているだろうかと、最近の事情について調べたところ、どうも、色々と思うところがある。

まず、「選択肢がありすぎる」ということだ。選択肢というのは難しい問題だ。テキストエディターならいくら選択肢があっても構わないが、そういう問題ではない。フリーなソフトウェアなのだから、別に存在しても構わないだろいう意見もあるかもしれないが、そのフリーは、問題の原因の一部かもしれない。問題は、あまりにも一般ユーザーが気にするべきことではない選択肢が多すぎるのだ。

例えば日本語入力の仕組みだ。Linuxでの日本語入力の実装は、クライント/サーバーのような形になっている。サーバーはかな漢字変換を提供し、さらに目的のアプリケーションとかな漢字変換のサーバーとの間の橋渡しをする仕組み、IMがある。かな漢字変換のソフトウェアに選択肢があることはいいことだ。ただし、橋渡しの役割をするIMまで多数の選択肢がある。これはどういうことだ。

端末とMuleに関する問題はひとまずおく。X Window Systemの問題を考える。Xには、XIMというIMがある。しかし、現代ではXIMはかな漢字変換サーバーからは、あまり使われていない。Xが別のAPIを制定したのかというと、そうでもない。Xの外でXIMへの互換機能を提供しつつ、さらに独自機能を提供するIMが乱立しているのだ。例えば主要な三つを上げると、SCIM、iBus、uimだ。誰もが、自分の使っているIMこそが一番優れていると主張して譲らない。だから、どういうことになるかというと、変換サーバーからそれぞれのIMへのバインディングが提供されている。どれを使っても動くというのは素晴らしいことだが、特にこだわりのないユーザーまでもが、どれかを選ばなければならない。何故一つに統一しないのか。そもそも、なぜX本家の仕様をアップデートしないのか。

もちろん、何もこれはXに限った話ではない。ことIMEに関して言えば、Windowsだって、IMM32からTSFとの移行があまりうまくいっていない。しかし、少なくともWindowsユーザーは、IMM32とTSFの何たるかを知らずに日本語入力ができる。

およそ一般的なユーザーは、猿程度の知能を備えていると考えるべきである。彼らはプログラミングが何を意味するのか分からず、コンピューターとOSとインターネットとブラウザーとGoogleの区別がつかない。テキストエディターやブラウザーを変更させるのだに相当の労力がかかるのだ。いわんやIMをや。IMという低レベルなソフトウェアは、およそ一般ユーザーが気にすべきものではない。たとえどんなに簡単なGUIの設定プログラムを用意したって、使いやすい自動化されて統一されたパッケージシステムを用意したって、低レベルなものは低レベルなのだ。学ぼうと思えば、いくらでも詳細は学べるが、すべての詳細を学ぶのは現実的ではない。これでは、いつまでたってもLinuxは一般ユーザー向けのデスクトップOSとしては普及しない。普及する技術が、オタクの考える技術的に優れているかどうかは、また別の問題なのだ。

これは、フリーなソフトウェアの問題である。フリーなソフトウェアはforkするのが容易なのだ。だから、多数の選択肢ができてしまうのだ。選択肢が増えるのは、良い事ばかりではないのだ。

もちろん、これらの低レベルな選択は、ディストリの仕事だろう。ディストリによって適切なデフォルトのソフトウェアがあらかじめ設定してあるべきなのだ。

思うに、UbuntuがコアなLinuxユーザーから批判されているのは、Ubuntuがあまり選択肢を提供していないからではないかと思う。特に、Ubuntuのデフォルトの設定は、かなり独断的に行われている。しかし、Ubuntuも他のLinuxディストロと同じように、変えようと思えばいくらでも変えられる。だから、Ubuntuを批判しているのは、自力で変更する知識と能力のないユーザーではあるまいか。

その他の感想として、wineがある。どうも調べたところ、最近のwineは結構やるらしい。またwinegccが非常に興味深い。これは、いわば逆Cygwinともいうべきgccをラップしたスクリプトで、mingw用のコードをほぼ改変せず、Linux用のコードを吐くgccで、winelibを使ってコンパイルできる。もちろん、実行にはwineが必要だが、これを使うと実に面白いことができる。Cygwinの逆ができるのだ。つまり、Linuxネイティブなバイナリからwineの実装によるWin32 APIを使うことができる。もちろん、Linuxのsyscallも可能だ。

2012-03-03

ハードウェアの信用

The Invisible Things Lab's blog: Trusting Hardware

少々古いが、面白かったので紹介する。

なるほど、君はパラノイアにとりつかれているんだね。自分のマシンでは、LinuxとかGNUとかのオープンソースなソフトウェアしか走らせたくないってわけね。やろうと思えば、全ソースコードを自分の目で検証可能だって安心してるわけか(実際やらないんだろうけどさ)。パラノイア病がもっと進行してきて、オープンソースなBIOSとかにまで手を出し始めちゃった。バカな奴らがWindowsみたいなクローズドソースのシステム使ってるなんて訳がわからないよ。とまあ、こう満足してるわけだよね。

でーも、所詮そこまでなんだよね、君は。だってまだハードウェアを信用しなきゃならないでしょ。ハードウェアベンダーが、ネットワークカードのマイクロコントローラーにバックドアを仕込んでないことを信用しなきゃならないでしょ。

某ベンダーからノートパソコンを買いました。そのベンダーは完全に民主主義というわけでもない国の企業です。バックドア仕込まれてないなんて、そんなのまさかね。アメリカ人のみならず、自国民までスパイするような国がだよ。ところで君、マザボに載ってるPCIデバイスを全部解析したことってあるの?

怖くなってきたでしょ。

そこでこのIOMMU(Intelの名称ではVT-d)の出番。OSとVMMを対応させれば、この技術はほとんどのハードウェアのバックドアの問題に対処できちゃいます。たとえばこのVT-dをサポートしたXen 3.3なら、ドライバーを権限の少ないドライバー専用の枠組みに隔離できちゃいます。そのため、PCIデバイスのDMAはドライバーに割り当てられたメモリ領域のみに制限できちゃうんです。

ネットワークカードのマイクロコントローラーは、依然としてネットワークカードドライバーとお話できちゃうけど、所詮そこまで。通信を常に暗号化しておけば、ネットワークカードドライバーができることは、DoSぐらいしかありません。ディスクドライバーにしたって、ディスクを完全に暗号化して使えば(もちろん、これは当然だよね)、低級層のディスクドライバーからできることはあんまりないってわけ。

そういうシステムを、特に、デスクトップ用途に設計するのは、簡単じゃないし、よくよく注意が必要だけど、でも今や、技術的にできちゃうんです。新しい仮想化技術のたまものですね。

これで、悪意ある可能性のあるハードウェアから身を守れるわけだけど・・・でもまだ、ひとつだけ信用しなくちゃならないものがあるんです。IOMMUを実装しているCPUとメモリーコントローラー(またの名をノースブリッジ、またの名をチップセット)だけは信用しなくちゃならないんです。

AMDシステムでは、メモリーコントローラーはとっくの昔にプロセッサー側に統合されちゃったよね。Intelも最近のNehalemプロセッサーで、メモリーコントローラーを同じダイ上に載せちゃった。

つまりこれで、信用しないといけないのは、ひとつのベンダー(IntelかAMD)と、ひとつの部品、つまりプロセッサーだけってことになるよね。でも、本当に信用しちゃっていいのかな? IntelやAMDにとって、自社製品のプロセッサーにバックドアを仕込むなんて朝飯前だよね。例えばこんな簡単なのでも、

if (rax == MAGIC_1 && rcx == MAGIC_2) jmp [rbx]

CPUにほんのちょっとゲート追加すればいいだけでしょ、たぶん。Core i7には7.8o億ものゲートがあるんだから、ほんの少し付け足してもそんなに変わらないよね。パフォーマンスにも影響しないよね。どんなシステムやプログラムからでも利用できちゃうのに、電子顕微鏡と正しいスキルと知識がないと調べることができないってわけ。

こんなのはアタシがちょっと数分ほどかけて考えただけだから、もっと簡単で利用しやすい方法はきっとあるはずよね。つまり、CPUベンダーだったら、バックドア仕込むなんて簡単なの。

おかしいよねコレ。欧州政府機関とかは、Windowsみたいなクローズドソースなソフトウェアを使いたがらないらしいじゃない。Microsoftがバックドア仕込んでいるかもしれないって理由で。でも、アメリカ合衆国の会社が作ったプロセッサーを使うのは特に問題にしてないよね。だいたい、Microsoftがバックドア仕込むのなんてリスクありすぎじゃない。ちょっとスキルある坊やがIDA Pro使えば見つけられるんだもん。でも、IntelとかAMDの場合、誰も見つけれないよ。

だからさ、将来、米国外の政府や大企業とかが、IntelやAMDにプロセッサーの設計図を要求するようになっててもおかしくないよね。もうすでにMicrosoftにはNDA結んでソースコード見せてもらってるんでしょ。でしょ? なんでプロセッサーの「ソースコード」には開示要求しないの?

でも、プロセッサーベンダーは客相手には、実際のプロセッサーに焼きこむのとは別の設計図を渡すことができちゃうよね。だから、製造過程を検証できる必要があるよね。例えばさ、独立した研究者グループを雇って、電子顕微鏡で無作為に抜き出したプロセッサーを検査させたりとかさ。そういうこと喜んでやる人達、アタシは知ってたりするよ。

ここまでの話についてこれなかった人達のためにまとめると、

  1. ほとんどのシステムはハードウェアのバックドアへの対策がない。例えばネットワークカードのコントローラーとか。
  2. Intel VT-dのような新技術は、特別に設計されたOSたとえば、Xenを使えば、悪意ある可能性のあるハードウェアを防御できる。
  3. ただしプロセッサーのバックドアをのぞく
  4. Microsoftを信用出来ないなら、なんでIntelとかAMDは信用できるの?

著者はJoanna Rutkowska。2006年のBlack Hatカンファレンスで頭角を現したホットな女ハッカー。今は、セキュリティを高めたLinux系のシステム、Qubesを開発している。仮想化技術とプロセス分離によって、OpenGL以外はセキュアな環境なんだとか。

続き:The Invisible Things Lab's blog: More Thoughts on CPU backdoors

補足:誰も続きを読まずにtweetしているようなので、続きからの抄訳。

すでに同じ事を考えて、自分で実装を試みた者がいる。Loic Duflotは、QEMU(残念ながら、彼は個人用プロセッサー製造ラインを持っていないのだ)を改造してそのようなCPUの可能性を探った。

まず、CPUにバックドアを仕込んでも、競合他社によって発見されるだろうというのは、現実的ではない。なぜなら、競合他社が手に入れられるのは設計図ではなく製品である。カバーを剥ぎ取り回路を電子顕微鏡で撮影するところから始めないといけない。そして何億ものゲートを検証する。そんなのは労力的に不可能である。同等の製品を作っているのだから解析ぐらいできるだろうと考えるのは素人である。たとえソースコードが提供されていたとしても、すべてを検証する労力は現実的ではない。「Adobeは巨大なソフトウェアを開発する能力があるからして、同等規模のソフトウェアを解析する能力もある」と考えるくらい馬鹿げている。

そして、プロセッサー内にバックドアを仕込んだとしても、外部からの観察はどうしようもない。たとえば、サーバーならば当然、ネットワークを監視する、プロセッサとは独立した装置を使っているだろう。たとえバックドア付きプロセッサが、そのプロセッサ上からは悪意あるコードが実行されてことを隠し通せたとしても、外からの観測にはどうしようもない。もし大規模に使われているプロセッサーであれば、サーバーの管理者の誰か一人ぐらいは、なぜか本来ありえない場所と通信している記録に気がつくだろう。そして検証の結果、各レジスタの値があるマジックナンバーであれば、特権命令を実行できるなどといった挙動、すなわちバックドアのトリガー条件に気がつくであろう。当然、その発見は直ちに公になる。

これを隠すためには、バックドアのトリガー条件を、よほど賢く仕込まなければならない。同じ条件では二度と発動しないような仕組みが必要だ。例えば、プロセッサーがEEPROMを搭載していて、トリガーの発動ごとに値をインクリメントしていくような仕組みであれば、容易にトリガーを発見することはできないはずだ。したがって、EEPROMを搭載しているプロセッサーは怪しい。とはいえ、やはり難しい。

もちろん、このような原始的な研究は、すでにIntelやAMDはとっくの昔に通過したものなのかもしれない。つまり、彼らはもっと画期的に発見されないバックドア技術を完成させているかもしれない。ひょっとしたら、彼らはこれを読んで、笑っているかもしれない。まあ、実際どうなのかは分かりようがない。バカの考え休むに似たり。

クラステンプレートとエイリアステンプレートの違い

C++11では、新しくエイリアス宣言をテンプレート化できる。これを、エイリアステンプレートと呼ぶ。エイリアステンプレートは、エイリアス宣言をテンプレート化するのだから、簡単なメタ関数ならエイリアステンプレートだけで実装できるし、また、クラステンプレートを利用したメタ関数のラッパーとしても使える。

template < typename T >
using add_pointer = typename std::add_pointer< T >::type ;

template < typename T >
void f( T )
{
    typename std::add_pointer<T>::type p1 = nullptr ;
    add_pointer<T> p2 = nullptr ;
}

また、メタ関数にかぎらず、広くクラステンプレートをラップする目的にも使える。

template <class T, class Allocator = std::allocator<T> >
using vector = std::vector< T, Allocator > ;

template < typename T >
void f( T )
{
    std::vector<T> v ; // これは簡単
    typename std::vector<T>::iterator iter = v.begin() ; // なんじゃこりゃ?
    vector<T>::iterator iter = v.begin() ; // typenameなんて必要なし!
}

こうしてみると、エイリアステンプレートのほうがメタ関数としてはるかに使いやすく感じる。余計なtypenameやら::typeやらが必要ないのだ。なぜ標準ライブラリはエイリアステンプレートを使わないのか。それには、TR1の設計段階では、エイリアステンプレートがッ規格上存在しなかったこともあろう。しかし、もうひとつ理由がある。ユーザーが特殊化を追加できないのだ。なぜならば、エイリアステンプレートには特殊化や部分的特殊化が存在しないからだ。ユーザー定義型に依存する型は、条件を満たせば、ユーザーが自由に特殊化を追加できる。それがクラスや関数のテンプレートの強みなのに、それができない。

これは、もし規格がエイリアステンプレートを使い、その実装方法を未規定にしていれば、ユーザーの特殊化を防ぐことができるという副次的な利点もある。C++11では、そのようなライブラリは入っていないのだが。

それに、規格はいつでも、ユーザーによる特殊化を、文面により明示的に禁止できる。だから、その目的でエイリアステンプレートを使う必要もない。

2012-02 post-Kona mailingの簡易レビュー

2012-02 post-Kona mailingが公開された

最新のドラフトはN3376、変更点は、N3338 - Editor's Report 2012-01に書いてある。今回は、単なる字句修正以上の変更が入った。例えば10年越しの問題、C++ Standard Core Language Active Issues 388などが興味深い。実際には、issue 388は解決されていない。文面上の変更はない。なぜならば、この問題を解決するには、ABIの変更を伴うので、もう少し議論を煮詰めた方がいいと判断されたようだ。もちろん、これはドラフトなので、頼ってはいけない。

N3360: Networking Library Status Report

TR2に提案予定のネットワークライブラリの土台となるBoost.Asioの現状報告。すでに何千ものプロジェクトの現場で使われており、当初の目的であったネットワーク以上に発展していった背景を説明している。

N3361: C++ Language Constructs for Parallel Programming

kona meetingで、並列プログラミングについてIntel® Cilk™ Plusを例に、Intelがプレゼンした際に使ったスライドのようだ。これはTR2の提案ではなく、Intelの開発してきた補助ライブラリのプレゼンである。本物の提案は、次回、発表されるらしい。一口に並列プログラミングといっても様々だ。スレッドは明確に実行コンテキストが独立するので分かりやすい概念だが、スレッドの作成にはコストがかかる。そこで、スレッドよりも軽い単位の並列実行である、タスクを説明している。また、コンパイラーがSIMDコードを生成できるよう補助する機能も説明している。

N3362: Terminology: "indirection" versus "dereference" (revision 2)

用語を統一するために、dereference a pointerという表現を、indirection through a pointerに置き換える。この変更が適用されれば、デリファレンスという用語は規格上、ポインターを経由した間接的なアクセスを意味する用語としては正しくなくなる。もちろん、これは規格の文面をより厳格にするためである。現実では、派生と継承がごちゃまぜになっているように、規格外では何も変わらない。

N3363: A Rational Number Library for C++

TR2に有理数ライブラリの提案。この提案は、むしろ今後の議論の叩き台にするためにでっち上げたようなものだろう。有理数ライブラリは、過去に一度提案されたこともあるし、Boostにも転がっている。どちらも、内部の数値表現型をテンプレート化している。この提案では、初心者に簡単に使えることを目指し、有理数クラスは非テンプレートである。内部的にはstd::intmax_tを使うようだ。

素人考えでは、そのようなあまり汎用的ではない簡易な数値計算のライブラリは、全員の要求を満たすことができず、参考書の外は誰も使わないオモチャライブラリに成り下がると思う。

N3365: Filesystem TR2 Proposal

TR2にファイルシステムライブラリの提案。Boostのファイルシステムライブラリを土台としている。ファイルの名前の取り扱いやサイズ取得やコピー、ディレクトリの作成、シンボリックリンクやハードリンクの作成など、一般的なファイルシステムに対する操作を提供している。ファイルを読み書きするライブラリではない。

しかし、このついでに、もっと使いやすいシンプルな設計の入出力ライブラリが欲しいと思うのは私だけだろうか。私の考えでは、入出力と文字列処理は、明確に分けるべきである。iostreamのように、入出力ライブラリが文字列操作をするべきではない。また、ロケールなどという考え方も馬鹿げている。そんなライブラリは実用にならないし、そもそも現実には、文字列をなにか一つの言語や文化に縛るこということも馬鹿げている。

だれかIOライブラリの提案を書いてくれないかな。ASIOは結局、iostreamに頼っているのでダメだ。

N3366: Runtime-sized arrays with automatic storage duration

実行時にサイズを指定できる自動ストレージ上に構築される配列の提案。C99にもこの機能がある。ただし、C++では、C99ほど馬鹿げた仕様にはならない。たとえば、多次元配列はサポートされないし、関数のシグネチャにもならないし、sizeofは実行時のサイズを返したりしない。typedefも変更なし。

void f( int n )
{
    int a[n] ;
}

ライブラリによる実装は、いずれも完全ではない。たとえば、動的にサイズを変えるクラスなどというのは、コンパイラーのサポートが必要になるし、allocaは型安全ではない上、コンストラクターやデストラクターも自動で実行されない。std::vectorなどはヒープ上に構築されるので使えない。さらに、固定サイズ+動的なヒープなライブラリという案もあるが、やはりこれもヒープから確保するので使えない。

N3370: Call for Library Proposals

ライブラリの提案の公募の告知。TR2に提案したいライブラリがある人は、このペーパーを読んで、提案すべし。

N3371: Status List for Library Proposals

今までに採用されたライブラリと提案、考慮されたライブラリの一覧。

N3374: SG4: Networking

Kona meetingで、ネットワークを研究するためのグループが結成されたようだ。TR2には本当にネットワークライブラリが入るかもしれない。

N3375: Proposal for Unbounded-Precision Integer Types

無限精度整数ライブラリの提案。やはりこの手のライブラリは、標準で用意すべきだ。

N3378: A preliminary proposal for work executors

GoogleによるTR2へのスレッドプールライブラリの提案。いや、スレッドプールというとスレッドを少しラップしただけの低級なライブラリという誤解を招く。むしろ、ワークという小粒な単位の実行を実現する高級ライブラリである。

2012-03-02

Google Chrome 18のエクステンションの仕様に破壊的変更が来る

Chromium Blog: Writing Extensions More Securely
Chromium Blog: More secure extensions, by default

Chrome 18でManifest Version 2を指定した場合、インラインscriptが使えない。evalも使えない。Background Pagesの仕様も変わっている。

つまり、今までエクステンションで、

<html xmlns="http://www.w3.org/1999/xhtml" >

<head>

<script type="application/javascript">
/* Javascriptのコード */
</script>

</head>

</html>

としていた場合、Javascriptのコードを別のファイルに分離して、

/* sample.js*/

/* Javascriptのコード */

それをscript要素のsrc属性で読み込まなければならない。

<script type="application/javascript" src="sample.js"></script>

セキュリティに関しての変更もある。デフォルトでは、パッケージ内のリソースしか使えない。詳しくは、Content Security Policy (CSP) - Google Chrome Extensions - Google Codeを参照。

とりあえず、青空縦書きリーダーに必要な変更をした。おそらく動くはずだ。background pageだけは、Chrome 18にならないと検証できない。そのため、Chrome 18のstableがリリースされるまでは、アップデートはない。

しかし、インラインJavascriptの禁止はかなりでかい変更だ。対応は、単に別ファイルに移すというトリビアルな作業とはいえ、かなりのエクステンションが、ちょっとしたことはインラインJavascriptで処理していただろうから、対応は面倒だ。しかし、必要でもある。インラインJavascriptを一律に禁止して、デフォルトのセキュリティで、パッケージ内のリソースしか読み込まないようにしておけば、エクステンションのセキュリティは大幅に上がる。外部のリソースに頼るということは、DNSが乗っ取られたり、あるいは中間に悪意ある者がいた場合(オープンなWifiを信用してはならない)、そのリソースを差し替えられてしまうからだ。インラインjavascriptの全面禁止は納得できる。しかし、今まで普通に使えていて、サンプルまでインラインJavascriptを多用していたのに、いきなり全面禁止はつらい。もちろん、deprecatedなマニフェストバージョン1を使っていれば、今までどおり使える。しかし、将来を考えたエクステンションは、バージョン2に移行するべきである。

2012-03-01

Linux移行に向けて

将来的にはLinuxへの移行が必須であると切々に感じている。そこで、Linux移行の障害になりそうな要素を考えみたが、これが、ほとんど存在しないということが分かった。

まず、BIOSによるHDDの容量の問題は、ことLinuxでは、存在しないことが明らかになった。GRUBはBIOS下のGPTを使ったブートをサポートしている。なぜなら、UEFIでもMBRは同じ仕様らしく、したがってブートローダーは互換性を保つことができる。あとは、ブートローダーとOSがGPTをサポートしていればいいのだ。

ソフトウェアだが、今日では、ほとんどのことをブラウザーで行なっているということだ。今主に使っているGoogle ChromはLinuxにも提供されている。私はFlashを毛嫌いしていて無効にしているので、この点でも問題ない。唯一、Flashを必要としていた日常使うサービス、Google Analyticsですら、もはやFlashは使っていない。

しかし、今やほとんどのローカルなネイティブのアプリケーションが、知らず知らずのブラウザーに置き換えられてしまったというのはおどろくべきことだ。私は今や、2ch専用ブラウザーですら、Chromeのエクステンションを使っている。read.crx 2という拡張だ。

PDFは嫌いなフォーマットだが、残念ながら読まなければならない場合がある。LinuxにもPDFビューワーはある。これも問題がない。

エディターは実際に使ってみなければわからないので気がかりだが、まさかエディターで宗教戦争が起こるような環境で、まともなエディターがひとつもないなどということは考えられないだろう。

IMEについては気がかりだ。

後は、どのディストリにするかという問題が残っている。多分、無難にUbuntuあたりにしておくべきだろう。ユーザー人口の多いほうが何かと便利なはずだ。

ゲームだが、もはや、PCゲームはコンソールゲームの移植に成り下がってしまったので、全く期待できない。遊ぶゲームがない以上、ゲーム目的でWindowsを使う理由もない。

調べたところ、最近のWineはなかなか向上しているらしく、Steamのクライアントを動かしてゲームをダウンロードすることはもちろん、SkyrimとかCrysis 2のような最新のWindows用のゲームまで動かせるらしい。もちろん、パフォーマンスは劣るそうだが、実に興味深い。昔はWineといえば、運が良ければ動くかも程度の存在だったような記憶があるのだが。