2013-07-24

GNU/Linuxでお手軽に使えるCLIのファイル暗号化ツール

ふと思い立って、GNU/Linuxでお手軽に使えるCLIのファイル暗号化ツールを探してみた。

評価すべき点は、自由ソフトウェアであることはもちろんとして、主要なディストロでパッケージ化されるほど有名であることと、ファイルの暗号化目的に簡単に使えることだ。「ファイルの暗号化」とは、十分に強い共通鍵暗号で暗号化、復号化することだ。

そして、今回重要視したのは、パスフレーズにUTF-8を使えることだ。パスワードという言い方はあまり好きではない。パスフレーズと呼ぶべきだ。パスフレーズとは、普通の文を使うものである。例えば、

  • イスタンブールは昔コンスタンティノープル
  • 水平リーベー僕の船そー曲があるシップスクラークか
  • 数種類の奇妙な文字で文章を書く、親愛なる日本人の皆さん

などだ。

これらのパスフレーズは人間にとっては作りやすく、覚えやすい。それでいて十分な情報量があり、総当りにも強いので、コンピューターにとっては難しい。従来の、"pa$$w0rd1234"より、はるかに効果的なパスワードの作り方だ。必要なのは単純にある程度の長さだ。ASCIIの大文字小文字数字記号を混ぜるより、十分に長い文を使うべきである。どうせパスフレーズはハッシュ化されて、せいぜい数百ビットの鍵になるのだから。

そして、日本人としては、覚えやすいパスフレーズには、当然日本語を使わなければならない。したがって、UTF-8をパスフレーズにできるのは、日本人として必須機能である。人間は、使いにくいツールを使う際には、楽をしようとする。そのため、ASCII文字しか使えないような環境では、"pa$$w0rd#$%^"のような弱いパスワードを使いたくなってしまう。ローマ字は正しい日本語表記の方法ではない。

xkcd: Password Strength

The GNU Privacy Guard - GnuPG.org

GnuPGはGNUによるOpenPGPの実装である。GPGは、ファイルの共通鍵暗号にも使える。

暗号化

gpg -c --cipher-algo AES256 -o output input

復号化

gpg -d --cipher-algo AES256 -o output input

GnuPGは十分に有名であり、主要なディストロでパッケージ化されている。

問題は使い勝手だ。--cipher-algo AES256などと指定しなければならないのはいかにも面倒だ。設定ファイルを記述することで、デフォルトの暗号アルゴリズムを指定できるが、設定ファイルの書き換えを要するのは、「簡単に使える」とは言わないだろう。

さらに問題なのは、GnuPGはパスフレーズの入力に、エージェントと呼ばれる別のプログラムを使うことだ。多くのディストロのパッケージでは、このエージェントのデフォルトが、GTK+かQtのソフトウェアになっており、結局、パスフレーズの入力にXを使わなければならない。CLIツールなのに勝手にXを使うのは行儀が悪いにもほどがある。ncursesを使ったCLIのエージェントもあるが、デフォルトのエージェントの設定は、設定ファイルを書き換えなければならない。環境変数やオプションで指定する方法もあるらしいが、そのフォーマットが非常に難解でややこしい。一応、GnuPGでは、エージェントを使わない--no-use-agentオプションがある。

Xを利用するエージェントは、あまり出来がよくない。たとえば、ASCII以外の文字を入力できない。これは前述の通り、到底受け入れられない。

GnuPGでは、--no-use-agentを使い、ロケールをUTF-8にし、UTF-8をサポートした端末を使えば、とりあえずUTF-8のパスフレーズを使うことができる。ただし、GnuPG 2では、--no-use-agentは無効化されていて、エージェントが必須になっている。わけがわからない。

それに、GnuPGはあまりにも巨大で、お世辞にもお手軽とは言いづらい。そのファイルフォーマットも複雑だ。

OpenSSL: The Open Source toolkit for SSL/TLS

OpenSSLのCLIツールは、ファイルの共通鍵暗号、復号にも使うことができる。

暗号化

openssl aes-256-cbc -e -salt -in input -out output

復号化

openssl aes-256-cbc -d -in input -out output

もちろんUTF-8も使えるので、日本人でも正しく覚えやすいパスフレーズを使うことができる。

OpenSSLは十分に有名で、主要なディストロでパッケージ化されており、大抵の場合、opensslに依存するソフトウェアがあるので、デフォルトで入っていたりする。

ではお手軽に使えるかというと、そうでもない。たとえば、-saltの指定もそうだが、暗号化方式をオプションで指定しなければならないというのも、使い勝手に悪影響を与える。しかも、aes-256-ecbのような、字面がよく似ているが、使うべきではないような暗号モードも選べてしまう。

Peter Selinger: ccrypt

ccryptは、AES256をCFBモードで暗号、復号するCLIのソフトウェアである。これ以外の暗号方式はサポートしていないので、わざわざ暗号方式をオプションで指定する必要がない。

ccryptは、暗号と復号を、オプションで指定することもできるし、プログラム名で指定することもできる。

暗号化

ccrypt -e input
もしくは
ccencrypt input

復号化

ccrypt -d input
もしくは
ccdecrypt input

注意すべきこととして、ccryptは入力ファイルを上書きするという事だ。これは、ccryptがあるストレージ上のファイルの暗号化に特化しているための設計だそうだ。つまり、平文を残さないということだ。

ただ、復号化するときにも上書きするというのはどうにも解せない。一応、復号化に関しては、上書きではなく、stdoutに出力する-cオプションと、ccatが存在するので、シェルのリダイレクト機能を利用すれば、復号結果だけは、別のファイルに出力できる。

ccrypt -c -d input > output

暗号化にかんしてはどうしようもない。平文をstdinから読み込む機能もないようだし、自分で書き換えるか、ファイルをコピーするしかないようだ。

また、ファイルを直接上書きするというのは、プロセスやシステムの意図しない停止の際に、ファイルが壊れてしまうおそれがある。そのため、一時ファイルに書き込んでリネームするという-T, --tmpfilesオプションもある。これは、ストレージに平文が残ってしまう恐れもある。

ただ、最近のファイルシステムはジャーナリング機能などもあり、単なるファイルシステム上からのファイルの上書きだけでは不十分だ。本当にストレージ上に平文を残したくなければ、直接ストレージにランダムなビット列を何度も書き込むか、物理的に破壊するべきだろう。いずれにせよ、別のソフトウェアや、ハンマーとかシュレッダーとかを使うべきだ。この仕組みは、どうも現状にそぐわないように思われる。

追記:そもそも、ディスク全体を暗号化しておくべきじゃないのか。

2013-07-22

GNUのAutotoolsについて学んでいる。

C++の参考書も書かなければならないのだが、今、GNUのAutotoolsについて学んでいる。そもそも、何故必要なのか(なぜ手でMakefileを書かないのか)というところから調べている。

GNU Autoconf, Automake and Libtool

Autotools: a practitioner's guide to Autoconf, Automake and Libtool

GNU coding standards - GNU Project - Free Software Foundation (FSF)

今のところの背景事情の理解としては、以下のようなものではないかと思う。

はじめに、makeがあった。makeをとりあえず使うのは簡単だが、すこし高度なことをしようとすると、とたんに難しくなる。そのため、既存のよく書かれたものがプロジェクトからプロジェクトへと流用されていった。

利用者の環境や設定に応じてMakefileの内容を変えたいという状況があったので、しだいに、Makefileを作成するスクリプトが使われるようになった。たいていはbashで書かれたconfigureという名前のスクリプトだった。このスクリプトも、やはり高度なものを正しく書くのは難しいため、やはり既存のよく書かれたものが、プロジェクトからプロジェクトへと流用されていった。

Makefileやconfigureを手で書くのは問題がある。既存の別の目的に書かれたものを流用するのも問題がある。なにか汎用的なものがほしい。ユーザーがちょっとしたマクロを書くだけで、あとは全部生成してくれるような枠組みが欲しい。そんなわけで、1991年にautoconfの開発が始まった。

別の理由としては、makeやbashの実装は多数あり、どれも微妙に挙動が違うため、移植性のあるMakefileやbashスクリプトを書くのが難しい。やはり共通の枠組みが欲しいというのもあったらしい。

また、ソフトウェアをソースコードで配布する文化である以上、ビルドは共通の方法で簡単にできなければならないという事情もあった。そのため、allとかcleanとかinstallのような業界標準のターゲットも決まっていった。そういうのを手作業で全部書くのは面倒だ。

autoconfは、Makefile.inをもとにMakefileを生成する。autoconfはconfigureスクリプトの生成をしてくれるが、Makefile.inは、まだ手で書かなければならなかった。Makefile.inは、Makefileとほぼ変わらない。autoconfはすでに書かれたほぼ完全なMakefileから、Makefileを生成する。そのため、Makefile.inを生成するためのautomakeが開発された。

automakeは、Makefile.amからMakefile.inを生成する。Makefile.amには、簡単なマクロと、必要に応じてその他のmakeのコードを書く。Makefile.inは、configureスクリプトによってMakefileになる。

それから、移植性に優れたshared libraryを書くための枠組みとして、libtoolがある。

どうもUNIXの文化なのだろうか、既存のソフトウェアはそのまま土台として使い、その上により高級な機能を実装するというのは。

makeの機能も含んだ新たなビルドシステムを開発するのではなく、makeはそのままで、Makefileを出力するメタなシステムを開発するとは。

まあ、依存関係とファイルのタイムスタンプによるターゲットの生成ソフトウェアとしてのmakeは、もう完成されたものなので、わざわざ再発明する意味はないのかもしれないが。

結果としてメタメタで理解が難しい。

次は使い方を学ばなければ。

2013-07-20

完全に秘密を守るコンピューターシステムを求めて

朝風呂に浸かりながら、今の私の知識を総動員して完全に秘密を守るコンピューターシステムを求めたらどうなるだろうかと、ぼんやりと考えていた。その内容を書きだしてみる。

今は政府や犯罪組織の諜報機関が暗躍する時代であるから、コンピューターシステムが利用者の秘密を守れるかどうかを考慮することはとても重要だ。たとえば、私が「もはやソフトウェア特許という害悪を日本から除くには、暴力革命しかない」などと考えて、その実行計画をコンピューターを使って以下のように練ったとする。

「日本の市町村の中で、ハーグ陸戦条約第25条に基づく無防備都市宣言を条例で定めようという動きがある。もし、実際にこのような条例を可決する市町村が出た場合、すぐさま安全ピンと果物ナイフとピストル型ライターで武装して侵攻する。すでに発した無防備都市宣言により、一切の抵抗なく、無血で占領できるはずである。占領後、すみやかに軍による暫定政権を発足させ、日本国から独立を宣言し、ソフトウェア特許を廃止させる」

おお、あくまで例文であり、私が本当に計画しているものではないが、我ながら何と恐ろしい計画だ。この緻密かつ完璧な計画がバレてしまったら、筆者は内乱罪で死刑になってしまうかもしれない。(もっとも、その前にこのような事態を可能にする条例を可決した地方議員に内乱罪が適用されるだろうが)。なんとかしてこの危険な計画書の存在を隠さねば。

あるいは、政府が国際条約、憲法、法律に反する行為をしている場合を告発する場合にも、セキュアなシステムは重要になる。

大原則として、セキュリティを重視した結果、使い勝手が悪くなってはならないということがある。使い勝手の悪いシステムを使わされる人間は、必ず楽をしようと考える。その結果、セキュリティがないがしろになる。したがって、このセキュアなシステムは、既存のコンピューターシステムと何ら変わりなく、人間にとっては通過的に使える必要がある。

この記事では、とくに物理的な攻撃に対して耐えるシステムを考える。ストレージ全体を暗号化しておけば、単にコンピューターが盗まれた場合、秘密を保てる。問題なのは、物理的な攻撃により、システムを改変された場合だ。これは、例えばキーロガーなどをひそかにしこみ、利用者が安全だと信じている環境の操作、たとえばパスフレーズ入力だとかを、ひそかに記録することができる。

ハードウェアは信用できない

本の虫: ハードウェアの信用

まずハードウェアだ。ハードウェアは信用できない。これは、ハードウェアを検証する方法がほぼ存在しないがためである。たとえ、設計図がすべて公開されていたとしても、現物のハードウェアが、設計図通りに製造されている保証がないためである。検証する準備だけでも、パッケージをひっぺがし、回路を走査型電子顕微鏡で撮影するところからはじめなければならない。しかもこれは検証する以前の検証環境の構築作業であり、検証ではない。

ハードウェアは信用できない。したがって、ハードウェアによるセキュリティに頼ってはならない。たとえば、HDDやSSDやUSBドライブのようなストレージハードウェア自体に備わった暗号機能は、使ってはならない。信用できないからである。ストレージには暗号文を渡すべきである。たとえストレージに悪意ある機能が仕掛けられていたとしても、暗号文ではどうしようもない。

ハードウェアは信用できないし、信用してはいけない。とはいえ、普通の個人は、専用Fabを所有していないし、シリコンに回路を刻めるほど器用な手先もしていない。したがって、やはり市販のハードウェアを使わなければならない。たとえバックドアが仕掛けられていても、悪用が難しいハードウェアと、悪用が簡単なハードウェアがある。たとえば、CPUにバックドアを仕掛けるのは難しい。その発動条件はどうするのか。例えばレジスタを特定の値にして特定の並びの命令を実行とかにするのか。それはかなりバレやすい。あるいは、内部にこっそりと不揮発メモリを組み込んでおいて、その値次第でバックドア発動条件を変えるような実装も考えられる。こちらは少し発見が厄介だ。

マザーボードは少し難しい。EFIでは、マザーボード自体に少量の不揮発メモリが内蔵されていることが規格上要求されている。したがって、マザーボードに不揮発メモリが組み込んであっても、あまり怪しまれない。フラッシュメモリの技術向上により、キーボードからの入力ぐらいなら、何年分も記録しておけるような量の不揮発メモリが組み込まれて、悪用されたならば脅威だ。そのようなマザーボードをしばらく使わせておき、後で回収してパスフレーズを調べるようなことが可能になってしまう。

プリンターは、一切信用してはならない。現状では、プリンターを所有するのは危険だ。なぜか。ほぼすべての現行のプリンターは、印刷に秘密のドットパターンをすりこませている。このドットパターンは、肉眼では確認できないほど微小だが、プリンターの固有番号や印刷日時といった情報をエンコードできるほどの情報量を持っている。したがって、プリンターとは、印刷物から、プリンターの個体が特定され、身元特定にもつながるハードウェアであり、セキュリティ上の脅威だ。また、プリンターのドライバーには不自由なバイナリブロブを必要とするものが多いのも危険だ。

バイナリブロブといえば、GPUも問題だ。バイナリブロブは、物理的なプロセッサーよりは検証が容易だとはいえ、やはり検証が難しいという点で脅威となる。利用にバイナリブロブ、とくにカーネルモジュールとして読み込まれるようなバイナリブロブが必要なハードウェアは避けなければならない。

ほとんどのセキュリティ上の対策は、ソフトウェアで行うべきである。ソフトウェアはハードウェアより検証がしやすい。たとえストレージやNICに悪意ある機能が実装されていたとしても、暗号文しか渡さず、またハードウェアから直接他のハードウェアを操作できなければ、それほどの害はない。

たとえハードウェアの実装に悪意がなかったとしても、実装が正しくない可能性がある。たとえば、IntelのSSDの暗号機能に不具合があり、実際には暗号化できていなかったとして、リコールされたことがある。

Intel, Kingston Issue SSD Recalls Due to Defective Encryption Chips

ハードウェアは検証だけでなく、修正もしにくいのだ。

さて、ソフトウェアについて考える前に、今一度、物理的な脅威について考えなければならない。コンピューター以外の脅威だ。

例えば、諜報機関は、読者のコンピューターを使う部屋に、盗聴、盗撮の装置を隠して設置するかもしれない。もしそのような装置が設置された場合、ディスプレイに映された内容や、キーボードの押し下げられたキー、あるいは声に出して唱えたパスフレーズが筒抜けになってしまう。コンピューターを使う前には、盗聴、盗撮の装置が仕掛けられていないか確認し、またそのような装置の死角となる場所で操作し、またみだりに秘密の内容を読み上げないように注意する必要がある。

ソフトウェア

ソフトウェアを考える上で問題になるのは、ハードウェアのファームウェアだ。現代の多くのハードウェアは、もはや単なる物理的な機械ではなく、動作にソフトウェアが必要になる。このようなハードウェアにROMや、あるいは書き換え可能なフラッシュメモリに格納されているファームウェア、あるいはハードウェアを使う際にOSから読み込ませないといけないファームウェアは、自由ソフトウェアであることが望ましい。しかし、現状では、ほとんどのファームウェアはバイナリブロブである。

さて、ようやくOSに入る。OSは当然、完全に自由なソフトウェアで構成されているべきである。ここで問題になるのは、誰を信用すべきかということだ。

OSのあらゆる部分を、全て自前で構築するのは非現実的だし、個人でできることではない。セキュリティアップデートに対応するだけで日が暮れてしまい、コンピューターを使っての作業に割ける時間がなくなってしまう。したがって、誰か他人の手で保守されているシステムに頼るべきだ。世の中には、すべてを利用者の環境でコンパイルする電力の無駄遣いなGNU/Linuxベースのディストロや、あるいは利用者に設定ファイルを書かせて詳細に設定させる漢らしいGNU/Linuxベースのディストロもある。しかし、これらとて、やはり他人が提供するシステムであり、結局誰か他人を信頼しなければならないことに変わりはない。

ストレージすべては、LUKSとLVMのような、通過的な仕組みを使って、全体を暗号化するべきだ。特定のディレクトリだけ、特定のファイルだけの暗号化ではだめだ。なぜなら、そのような個別の暗号化は煩わしく、利用者に楽をさせたがる理由を与えてしまうからだ。利用者に何も明示的に行動させない、通過的な暗号化が好ましい。

さらに、OSを構成するプログラムデータを暗号化しないということは、たとえば諜報機関にOSの一部を差し替える攻撃を許してしまう。コンピューターの設置されている場所にひそかに侵入し、こっそりとカーネルやシェルやテキストエディターのような重要なプログラムを差し替える。これにより、利用者による操作をこっそりと記録する。あとでコンピューターを盗めば、記録からパスフレーズから秘密の計画から何でも筒抜けだ。したがって、ストレージ全体を暗号化する必要がある。

GNU/LinuxベースのOSで、ストレージ全体の暗号化をする際に、唯一暗号化できないのが、/bootだ。これは現在のハードウェアの都合上、どうしようもない。ただし、/bootは非常に小さいため、容易にハッシュチェックを行える点が救いだ。

また、セキュアブートの仕組みを使い、マイクロソフト鍵とマザーボードベンダーによって出荷時に設定された鍵を無効化し、自前の鍵を登録し、OSをすべて自前の鍵で署名するという方法もある。これは、ハードウェアとファームウェアがセキュアブートを正しく実装していれば、だいぶ効果的だ。ただし、これは物理的なアクセスへの対策にはならないので、あまり意味はない。

あるいは、/bootをコンピューターに常時接続するストレージには格納しないという方法もある。たとえば、/bootはUSBメモリーに格納しておき、コンピューターを起動する際には、そのUSBメモリーを使う。こうすれば、諜報機関がコンピューターに物理的にアクセスして、/bootを改変するという攻撃を防ぐことができる。このUSBメモリーは首から下げ、あるいはパンツの中に入れるなどして、メシを食ってようとクソしてようと、常に肌身離さず保管すること。

その他の身の安全を図る手段

国家の悪事を内部告発する者は、常に不当不法な方法で処分されてきた。特にそのような始末から身の安全を図るための方法も考えておくべきだ。

異性との接触を避ける

過去の多くの内部告発者が、異性と接触しているという点で避難されてきた。「ひそかに情を通じ、これを利用して」というわけだ。異性との接触は生殖活動に必須であり、全員が行う必要はないとはいえ、種としての人間を絶滅させないためには、誰かが行わなければならない行為であるはずなのだが、なぜか異性との接触が出てきた時点で、その内部告発者の他の面や、内部告発の内容が完全に無視され、そのことのみに注目が集まることが多い。また、異性との接触を理由にした逮捕監禁が、非常に多く行われている。

このため、安全のために、我々は異性との接触を避けなければならない。もし、異性が強引に接触を試みてきた場合、諜報機関の手先だとみなし、全力で逃走しなければならない。また、録画、録音のような証拠も残すべきだろう。

暴露できる秘密の可能性を残す。

多くの内部告発者は、いざという時のために、爆弾を残している。まだ暴露しない秘密を保有し、もし自分の身に何かが起こった場合は、秘密が暴露される仕組みを作り上げている。もしハッタリでなければの話だが。

これを可能にするには、秘密爆弾を暗号化して公開し、複合鍵を信頼できる他人に預ける。その他人は、自分の身に何かが起こった場合、少なくとも複合鍵を世間一般に公開出来るだけの時間的猶予を持つものでなければならない。

もし、自分の身に何かが起こる前に複合鍵を公開されたくないが、そこまでの信頼に足る人物がいない場合、秘密共有の仕組みを使い、鍵を分散することもできる。複合鍵を秘密共有で暗号化し、その秘密共有鍵を3人に託し、三人の鍵が揃わなければ複合鍵が得られないようにするとか、10人に託し、その内の任意の5人の鍵が揃わなければ複合鍵の暗号が解けなかったりという仕組みにできる。

このような秘密共有の自由なソフトウェアによる実装として、ssss: Shamir's Secret Sharing Schemeがある。Debianならパッケージ化もされており、apt-get install ssssでコンパイル済みのバイナリをインストールできる。このソフトウェアはその名の通り、Shamirという人が考案した数学的に機能する秘密共有の仕組みを実装したものだ。

以上、色々と妄想はしてみたものの、どうもあるxkcdの話が思い出されてならない。5ドルのレンチはどこに売っているのだろうか。

本の虫: xkcd: セキュリティ

xkcd: Security

暗号ヲタの妄想:
「奴のラップトップは暗号化されてやがる。百万ドルのクラスタ組んで解読しようぜ」
「いやダメだ。これは4096bit RSAだ」
「クソ、我々の邪悪な計画もここまでか」

現実に起こりうること:
「奴のラップトップは暗号化されてやがる。パスワード吐くまで、この5ドルのレンチで傷めつけてやれ」
「了解」

2013-07-19

Apache C++標準ライブラリが終了したそうだ

[Phoronix] Apache Kills Off Its C++ Standard Library

stdcxx-dev mailing list archives

phoronix.comはこの手の情報をどこから見つけてくるのだろう。Apatchのstdcxxとも呼ばれているApacheのC++標準ライブラリの実装が、開発を終了するそうだ。アナウンスがML上でなされている。

もっとも、stdcxxは、2008年から更新が途絶えていたそうだ。

ApacheのSTL実装は、一体誰が使っているのか謎だった。コンパイラーに付属しない、GCCやMSVCといったコンパイラーや、POSIXやWindowsといったOS上で動作する、結構移植性の高いSTL実装なので、面白いと言えば面白かったが、やはり用途が謎だ。

2013-07-16

LinuxカーネルのMLにおける悪口の励行についての議論勃発

Linuxカーネルのメーリングリストは、常に罵詈雑言に満ち溢れているが、そういうのは辞めて大人になろうという主張がSarah Sharp[1]によってなされた。なかなか面白い。

きっかけは、いたって日常的な罵倒混じりの議論に、Sarah Sharpが横槍を入れたところから始まった。

LKML: Sarah Sharp: Re: [ 00/19] 3.10.1-stable review

On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org> wrote:

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:

-rc4の後はそういうのは後回しにしてるんだ。だってお前はGregより怖いからな

お前リアルでGregみたことあんの? 奴は巨漢だぜ。奴はマジ怖いぜ。奴はお前程度なら一瞬でぶちのめせるぜ。

Gregが人を一瞬でぶちのめせるにせよだ、それは単なる物理的な脅威でしかなく、本物のカーネルハッカーが恐れるような脅威ではない(薄暗い地下室に対する脅威なんてほとんどない。あるとすれば、地震とか、ガンマ線隆起とか、コンピューターの周りを掃除しようとするカーチャンとか)

そういうわけでGreg君、現状を変えたいのなら、本物の脅威を作り出すべきだ。貢献者にはもうちょっと率直になって、時には罵るべきだ。そうすればメールの件数も半分ぐらいには減らせるよ。マジで。

On Fri, 12 Jul 2013 08:22:27 -0700, Linus wrote:

Greg、お前のところにstableパッチが大量にやって来るのは、お前さんが都合のいい玄関マットだからだ。明らかに、一部の連中は、「こいつぁLinus様の手を煩わせるほど重要なパッチじゃねーな、でもGregってやつなら受け付けてくれそうだ。待ってりゃ勝手にstableになる」とか言ってるぜ。

お前さんは人に怒鳴るということを覚えるべきだ。

ちょっとマジィ? あんたら? stableを改良するのにそんなことが必要ってわけ? Linus Torvaldsさんがここで罵倒を推奨しちゃってるよ。Ingo MalnarとLinusがいまここで罵倒をオススメしちゃってるよ。

マジ、サイアク。暴力なんて物理的なのも、言葉の上なのもダメでしょ。メーリングリストではもっと大人になろうよ。

これを面と向かって話せるカーネルサミットでやってみようよ。アタシにどなってみなよ。アタシ、どなりかえしちゃうからね。今までトップのメンテナーにどなられたみんなの分よ。アタシだっていい子にしてらんないわ。

Sarah Sharp

という具合に、サラ・シャープが、しばしば暴力的な言葉で溢れかえっている現状を批判した。

Linusの返答。

LKML: Linus Torvalds: Re: [ 00/19] 3.10.1-stable review

On Mon, Jul 15, 2013 at 8:52 AM, Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:

アタシにどなってみなよ。アタシ、どなりかえしちゃうからね。今までトップのメンテナーにどなられたみんなの分よ。アタシだっていい子にしてらんないわ。

それでいい。

Gregはお前を正しく導いたようだな。お前は恐怖を克服している。さあ、怒りに身を任せろ。怒りなくしては私を倒すことはできん。

ダークサイドに来い、サラよ。クッキーがあるよ。

Linus

Sarah Sharpの返答。

LKML: Sarah Sharp: Re: [ 00/19] 3.10.1-stable review

でも、でも、ライトサイドにはブラウニーケーキがあるの。大麻ブラウニーでみんなフワフワのネムネムよ。あ、でももっと大麻ケーキ食べたくなるかも。

Sarah Sharp

Linusの返答。

LKML: Linus Torvalds: Re: [ 00/19] 3.10.1-stable review

ふむ、その件に関してはカーネルサミットで密会を開くべきかもしれんな。

俺は普通のクッキーを持って行くよ。

Linus

Sarahの返答。

LKML: Sarah Sharp: Re: [ 00/19] 3.10.1-stable review

オランダじゃないから、カーネルサミットに大麻ブラウニーは持ち込めないと思うわ。

とにかく、こっちは真面目よ。Linus、あんたは罵倒にかけちゃサイアクよ。

http://marc.info/?l=linux-kernel&m=135628421403144&w=2[2]
http://marc.info/?l=linux-acpi&m=136157944603147&w=2[3]

もういいかげんウンザリだわ。

Linusの返答。

LKML: Linus Torvalds: Re: [ 00/19] 3.10.1-stable review

そうだね。だってそれが俺だし、歯に絹着せるとか人当たりのいい奴ってのは感心しないからね。

問題は、俺の意見がどうなのか知らせる必要があるということだ。単に「そういうことはしないでいただけるとありがたいんだけど」とか言ったんでは伝わらない。それじゃ聞いてくれないんだ。「ネット上では丁寧な奴ほど無視される」と、俺は思ってる。

それと、俺は人を放っておきたくはないんだ。過去に起きたことだからね。あるアプローチは気にいらないと十分に強く伝えられなかったばっかりに、勝手に実装が進められて、いざ俺が受け付けないと知ると怒りだした連中とかね。

Sarah、まず俺にできることはそんなにないし、礼儀正しいとか言葉狩りだとかに意味があるとも思えない。君が文化的風習をあげつらって、一部の文化圏は気分を害すると主張するのは自由だ(それと性別についても自由に主張してくれたまえ、性別だって多分に文化的なものだからね)。その際には、「異文化への配慮」とやらをぜひとも持ちだしてもらいたい。俺も「異文化への配慮」を持ち出すからね。俺の文化に対しても配慮してもらいたいね。

"Management by perkele"でググれ。[4]

マイノリティを抑圧したいのかい? フィンランド人は他の国に比べれば相当にマイノリティだよ。異文化への配慮を主張するなら、俺も乗るよ。ただ、俺の文化には罵倒も含まれるんでね。

上記はすこし茶化して書いたものの、真面目だよ。俺は真剣に、議論に対して感情に忠実で率直であるのはいいことだと思っている。メール越しに人を読み解くのは難しいので、メールではより率直である必要がある。僕は基本的に良い人だよ。いつもそうじゃないけど。

カーネルサミットでこれについて議論するのはいいけど、君の「高慢」とやらは、それほど高くはないことを知るだろうよ。

Linus

[1]: Sarah Sharpは30週間で30人のLinuxカーネル開発者インタビューを受けているが、なかなかべっぴんさんである(この記述は男性的でありポリティカルコレクトネスに反する)

30 Linux Kernel Developers in 30 Weeks: Sarah Sharp | Linux.com

[2]: リーナスの罵倒として有名な一例。Linuxカーネルの変更がpulseaudioの挙動を変えたという報告に対し、pulseaudioのバグだと指摘する声を遮って、カーネルがユーザープログラムの挙動を変えたなら、それはカーネルのバグだと罵倒するもの。

'Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1)' - MARC

On Sun, Dec 23, 2012 at 6:08 AM, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:

つまり戻り値が-EINVALじゃなかったらpulseaudioが変なループに陥るわけ? それはpulseaudioのバグじゃないかな。

Mauro、テメェ黙りやがれ。

バグだ。カーネルのバグだ。お前何年メンテナーやってんだよ? それでいて、いまだにカーネル保守のひとつめのルールすら学んでねーのか?

もし、変更がユーザープログラムを壊す結果になれば、それはカーネルのバグだ。ユーザープログラムを決して咎めてはならない。こんな簡単なことも理解できないのか?

そもそも、コミットf0ed2ce840b3は、たとえ何も壊さなかったとしても、明らかにどうしようもないクソだ。ENOENTはioctlの妥当な戻り値じゃない。ありえん。ENOENTは「該当のファイルやディレクトリーが存在しない」という意味で、パス操作のためにあるのだ。ioctlはすでに開かれたファイルに対してのもので、ENOENTが妥当な場合なんて存在するわけねーだろ。

で、一見すると、これはregressionではないようだね。カーネルではなく、pulseaduioとtumbleweedに深刻なバグかregressionがあるようだね。

黙れMauro。俺はこんな馬鹿げたクソ発言をカーネルメンテナーからは二度とクソ聞きたくない。クソマジに。

お前がRafaelのパッチを検証するまで待とうかと思ってたんだが、俺のメールボックスに、v3.8-rc1でKDEのメディアアプリが全部ぶっ壊れたってエラー報告があるんでな。しかもお前はこの問題に積極的じゃないときた。俺がこの手で今すぐ直接パッチを適用してやる。

「ユーザースペースを壊してはならない」

マジで、何でこんな簡単なルールが理解できねーんだよ? クソでユーザースペースをぶっ壊すようなことはしない。てめーのメールが、根本的に間違ってて、ぶっ壊した原因のパッチが明らかにクソだから、俺は怒ってるんだぜ。パッチは全体的にありえんほどぶっ壊れたクソだ。このパッチはありえんエラーコード(ENOENT)を追加して、そのありえん変更に対応するため、さらに別の場所を直している("ret == -ENOENT ? -EINVAL : ret")

しかも、テメーはユーザースペースをぶち壊した「言い訳」をしていて、動いていた既存の外部プログラムのせいにしているのは、赤っ恥もいいところだ。ここじゃそーゆーふうにはやってねーんだよ。

テメーのクソ「検証ツール」とやらを直しやがれ。明らかにぶっ壊れてるからな。それからテメーのカーネルプログラミングのやり方も改めろ。

Linus

[3]: あるパッチによりUSBにregressionが発生したので、とりあえず該当のパッチをrevertしたいが、きれいにrevertできないという発言に対し、Rafaelが、「そもそも件のパッチは修正のためのパッチなのだから、revertできるものではない。すでにその修正パッチに依存した別のパッチがたくさんある」と答えたところ、Linusから大喝を受けたもの。Linusは「目的が修正にせよ何にせよ、regressionがあったらrevertするのだ。regressionなしは大原則だ」と言っている。

'Re: [GIT PATCH] USB patches for 3.9-rc1' - MARC

On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:

revertはしない。それに依存したものがたくさんある。それに、そのパッチは修正だ。だから、revertするというのはいいアイディアではない。

Rafael、そんなクソ発言は二度と書かないでもらいたいね。

それが「修正」にせよ、それ以外のものにせよ、revertはする。ルールは、「regressionなし」だ。「修正」かどうかなんて関係ない。既存のものを壊したなら、revertされる。

マジさぁ、なんで俺がこんな事言わなきゃなんないわけ? なんでマージ期間のたびに毎回毎回おんなじことをいわなきゃなんないわけ?

これは新しいルールってわけじゃねーんだ。

ところで、このルールが絶対的なルールとして存在する理由ってのは、マジなところサスペンド/レジュームとACPIのためだぜ。過去にこの手の、「この問題は直して、別の場所をぶち壊そうぜ」という無限ループがあったからだ。だからお前はこのルールはよく知っているべきなんだ。だからお前がこんなクソな発言をするとはマジ驚きだぜ。

regressionに言い訳は通用しない。それも「修正だから」なんてのは最悪の言い訳だ。

regressionを生じさせたコミットは、つまるところ、「修正」じゃないのだ。お願いだからそんな馬鹿げたことは二度と言わないでくれよ。

既存の動くものは、今まで動かなかったものより、百万倍は重要だ。

そんなわけで、こいつはソッコーで直す必要があるし、誰か早く何とかするべきだ。何もしないならrevertだ。

「でも修正なんだよぅ」なんて何の意味もない。むしろ、さっさとrevertしておかなかったのを俺に後悔させるほどだ。なぜなら、メンテナーはregressionの重要性を理解していないのだからな。

なぜかこちらは、pleaseの利用率が高い。相手がRafael J. Wysockiだということとなにか関係があるのだろうか。

[4] : "Management by perkele"(罵倒による統制) フィンランドの長々とした議論ではなく、素早い直接の実行で問題を片付けるやり方を、スウェーデンが茶化して名付けたもの。perkeleとはフィンランド土着信仰の邪悪な神の名前で、フィンランドでは、「バカ」とか「クソ」のような罵倒語として使われている。

2013-07-14

ハードウェア乱数生成器は信頼できるか

How secure is Linux's random number generator? | Hacker News

Hacker Newsで話題になっていたので。

主に暗号用途には、予測不可能な乱数が必要となる。予測不可能というのは、実装と内部状態が知られていても、なお将来の乱数が予測できないということだ。

たとえば、擬似乱数としてよく使われる線形合同法(Linear congruential generator)は、以下のように書ける。

namespace lcg { 

thread_local unsigned int seed ;

void srand( unsigned int seed )
{
    lcg::seed = seed ;
}

int rand( void )
{ // glibcの使っている値を拝借
    seed = (1103515245 * seed + 12345) % 0x80000000 ;
    return static_cast<int>(seed) ;
}

}

この線形合同法は、高速に乱数を生成したい場合には便利だが、残念ながら予測可能なので、暗号用途には適していない。

Linuxカーネルが提供している/dev/randomは、様々なハードウェアやデバイスドライバーから生成される予測不可能な値をエントロピープールとして貯めこみ、ハッシュ化して予測不可能な乱数を作り出す。

問題は、そのような予測不可能な値というのは、それほど多くないし、頻繁に生成されない。そのため、/dev/randomの乱数生成の速度は非常に遅い。どのくらい遅いのか確認したければ、以下のように試してみるといい。

$ cat /dev/random

以前のLinuxカーネルは、エントロピープールのサイズを増やすことができた。ただ、プールが大きすぎると、乱数がある程度予測可能になってしまうという攻撃手段が見つかったので、今ではその機能は削られた。以前のLinuxカーネルはもっと多くのドライバーから値を取得していたが、多くのデバイスから得られる値は、外部からの操作によってある程度予測可能になるということが判明したので、今では/dev/randomのプールに使うデバイスもだいぶ減った。

予測不可能な乱数を高速に生成する需要はかなりある。そこで、IntelのIvy Bridgeでは、rdrandという命令が追加された。これは、CPUに組み込まれた乱数生成器によって、予測不可能な乱数を高速に生成することができる。

rdrandは十分に高速なのだが、別の問題がある。ハードウェアは信頼できるかという問題だ。IntelのCPUは信頼できるのか。

乱数が真に乱数らしいことを確かめるツールには、Dieharderがある。もちろん自由ソフトウェアだ。DieharderはDebianならパッケージ化もされており、apt-get install dieharderするだけでコンパイル済みのバイナリが入れられる。使い方も、乱数であることを確かめたいビット列をpipeで流しこむだけと簡単だ。

もちろん、rdrandは誰でも使える命令であり、すでにDieharderのようなソフトウェアもある以上、検証している人もいる。

A Smackerel of Opinion: Intel rdrand instruction revisited

ただし、Intelがその気になれば、rdrandの実装は、インクリメントされるカウンターをAESで暗号化したものにできる(暗号鍵はもちろんIntelやNSAが保持しているのだ)。この実装は、Dieharderのようなテストもパスする。

Linuxでrdrandをサポートする際にも、ハードウェアを信頼できるのかという議論がされている。

LKML: Matt Mackall: Re: [PATCH 1/2] random: Add support for architectural random hooks

Linusによれば、rdrandを直接使うのではなく、既存のエントロピープールに他の値と一緒に混ぜ込んでハッシュ化するので、まず問題にはならないだろうとしている。

2013-07-12

カスパロフ、ロシアから脱出

Kasparov Flees Russia on Detention Fears Amid Putin Crackdown - Bloomberg

元チェスチャンピオンで、今はプーチン政権を批判しているカスパロフが、司法による逮捕のおそれがあったため、ロシアから脱出したそうだ。

Linux LLDBの現状

Linux debugger bits: State of LLDB on Linux

先週、ゲーム開発ツールを開発しているRAD Game Toolsが、LLDBをGNU/Linux用に開発するために人を募集していた。この求人に対して、「LLDBはもう出来上がってるじゃん。今さら何すんだよ。ちょこちょことバグ直したりお手軽に使えるようにしたりするセコい商売でもするのか?」という意見が多かったらしく、RAD Game ToolsのJeff Robertsが反論している。

[Phoronix] RAD Game Tools To Take On Linux Debuggers

もう同じ質問が何度か上がっている。だいたいこういうのだ。「なんでRadとValveはLinux向けのLLDBを開発してるんだよ。もう出来上がってるじゃん?」。中には憤りを覚えたものもいるらしい。

ロバーツの野郎は「もっと詳しく言うと、RADはデバッガーを書く開発者を募集している。弊社は今、Linux向けのlldbを開発している」とかtweetしてる。

マジで? 開発はほとんどAppleがやってるじゃん。RADは適当に乗っかって過剰広告でもするんだろうな。奴らがするのは小さなテストとかバグトラッキングとかで、LLDBがLinuxでぶっ壊れないようにすることだろうよ。LLDBはもう一年はLinuxで動いてる。

インターネットでゴングショー[訳注:芸をやらせて詰まらなければゴングを鳴らして即退場という形式のテレビ番組、ゴングショーにちなんだ言葉]が出来ればいいのになぁ。

ここ最近、優秀な人間が相当に開発して、Linux LLDBはだいぶ進歩した。Intelの4人の開発者や、AppleやFreeBSDやその他の何人かだ。だが、まだLLDBでL4D2やTF2をデバッグできるようになるには、多大な作業が必要だ。そもそも、LLDB自体をデバッグするとか、それどころか32bit版のprintf("talking out our asses!");をデバッグすることすらできていない。

数カ月前、我々が開発を始めた時には、まだLLDBは現在実行中のLinuxプロセスを列挙したり、プロセス名によってアタッチしたりできなかった。スレッドやらシンボルの分割といった主要な機能は、ごく最近追加された。一ヶ月前までは、まだマルチスレッドアプリケーションをデバッグできなかったし、シンボルやソース付きのシステムライブラリにステップインすることもできなかった。

現状で、まだコアファイルをロードすることはできないし、32bit Linuxアプリケーションのデバッグは基本まともにうごかない。i386テスト集には今日とりかかりはじめたところなのだ。

DWQRF4シンボル(gcc 4.8のデフォルト)は動かない。

Expressionは怪しいしbacktraceを使うには愛が必要だ。

私は今、assertとかnss shared libraryをロードするとクラッシュするところに取り掛かっている(前回のブログ投稿を見よ)

テスト集のいくつかのテストは64-bit Linuxでは失敗する。

262件のうちの33件のテストは32-bit Linuxでは失敗する。

Linux LLDBはしょっちゅうハングするし、ありえないほど長いロード時間も発生する。

Linuxでリモートデバッグできない。

後はlldbバグデータベースを参照。

http://llvm.org/bugs/buglist.cgi?resolution=---&op_sys=Linux&query_format=advanced&component=All%20Bugs&product=lldb

LLDB 3.3に関するいいブログ投稿が、最近llvm.orgにあがっていて、読むべき価値がある。

http://blog.llvm.org/2013/06/lldb-33-and-beyond.html

LLDBの良い所はたくさんあるし、コミュニティや開発も楽しい。gdbを捨ててLLDB一本で行くにはまだやるべきことがたくさんある。ここに書いてあることが面白そうに思えたら、参加して手伝ってくれ。

動機が不自由ソフトウェアの開発のためという不純なのは哀しいことだ。GNU/Linux用の不自由ソフトウェアのゲームのデバッグツールとして、LLDBにかなりの労力が注がれている。何故だろうか。GPLv3のような優れた自由を保証するライセンスではなく、不自由ソフトウェアとして組み込める弱いライセンスのためだろうか。GCCは不自由ソフトウェアで使いにくくするよう、意図的に機能毎に分離して使いづらい設計になっている。GDBのコードもそのようになっていて、汚いからだろうか。

2013-07-10

Mark Shuttleworth: Mir二週間

Mark Shuttleworth: Two weeks with Mir

Mark ShuttleworthはMir(より厳密には、XMir上で動くUnity 7)を二週間試し、そのパフォーマンスに満足したようだ。また、体感的に、X.Orgよりも動作がスムーズになったとまで書いている。

この二週間、私のラップトップ上で、Mirはスムーズに動いている。このラップトップはIntelのみのDell XPSなので、Ubuntuにおけるドライバースタックはとてもクリーンなのだ。とはいえ、Mir以前よりもシステムがスムーズになったように感じるのは、驚きだ。このMirを動作させているSaucyは更新が激しく、新しいバージョンのXやCompizも使われているので、そのせいなのかもしれない。しかし、全体を観察してみると、XorgとCompizが、Mirの元では、Xがハードウェアを直接扱うより、メモリー消費量もCPU利用量も少なくなっている。

Mir開発部門と話したところ、他の者も同じ体験をしているそうで、彼らによれば、ハードウェアに対するリクエストを、より効率的なバッファリングで行うことが寄与しているのだという。「ご使用の環境により、効果は異なります」とはいえ、試すべき価値はある。私が気がついたバグはひとつだけ、CHromiumがグラフィックスタックの問題によりディスプレイをフリーズさせるという事だ。Alt-F1を押すとフリーズは治る(どうもこれにより、Compizになんらかの働きをさせ、GPUを正常な状態に戻すようだ)。私への報告によれば、この問題は些細なもので、将来のPPAのアップデートで解消されるそうだ。

私の全体的な感想としては、Mirは私が期待していたものを提供してくれる。すでに試みられた手法--SurfaceFlinger、Wayland、X--を検証したというアドバンテージがあるということもあろうが、パフォーマンスと効率が一番の懸念事項である、モバイルのレンズを通して問題を観察したからという事もあるだろう。とにかく、軽快で、効率的で、高品質で、レガシーXスタックを実行するのですら、恩恵を受けるのだ。

我々がUbuntuに下すあらゆる決定に疑念の声があがるのは、多くの人々が影響を受けるからだ。しかし、私が開発部門に念押ししているように、行動が必要とされている時に行動しないという失敗は、間違った行動による失敗と同じぐらいひどいものである。ユーザーからすれば我々には難しい領域に挑戦する責任がある。過去の多くの難しい決定は、今日の広範な利用者に、我々のお役立ち度の基礎となっているのだ。

グラフィックスタックを作るというのは、気軽に行われた決定ではない。午後のハッキングとはわけが違う。この決定は技術的ファクターを注意深く考察した結果取られた。我々には、様々なデスクトップ環境で一貫したユーザーエクスペリエンスの品質を提供するために、広範なハードウェアで動く、信頼性が高いグラフィックスタックが必要なのだ。

もちろん、ここには競争が存在するし、私はこれを健全なものと考えている。私はMirが競合相手より、我々の選択した基礎的な違いや決定のため、より素早く進化すると信じている。例えば、拡張するしか能のない凝り固まったプロトコルのかわりに、我々はAPIを提供している。このAPIの実装は、時間と共により優れたパフォーマンスへと進化するだろうが、固定プロトコルを話しているのでは、同じ事をするのは難しい。Xで我々が味わったように、固定のレガシープロトコルと、絶え間ない拡張群の作り続け、しかも拡張自体にバージョンが存在するというのは、物事をやたらと変な方向に持っていく。すでに私よりも適任な他人が、Mirの具体的な技術上の詳細をまとめているので、Mirの違いや、他のスタックから学んだことや、Mirのアーキテクチャの利点について興味を持ったならば、読むといい。

Mirをオプションとして提供するのは簡単だ。Mirはスタックの一部であり、たとえば、initシステムよりは、アプリ開発者をいじめる触手やそっとつするような要素が少ない。つまり、優れたパフォーマンスを出すために調整しなければならないコミュニティが少ないという事だ。ディストロはSystemDよりMirでやったほうが簡単だ。例えば、すべてのパッケージに影響を及ぼすより、少数のパッケージだけを調整するだけで優れた結果が出せる。QtとWebkitコミュニティとで調整した結果、好意的なエクスペリエンスが得られた。例えば、それらのアプリがすっ飛んでMirとネイティブにお話できるとか。良きupstreamはコードを広い環境で役立つものにしたいと思うもので、関連するツールキットは、Mirの改良された性能を引き出すパッチが提供されたならば、受け入れるだろう。また、我々はMirで高パフォーマンスのXスタックが提供できると確信しており、Xを話すすべてのアプリケーションや、Xを話すすべてのデスクトップ環境は、Mirで普通に快適に動作するので、Mirの提供するシステムコンポジターのその性能のおかげで、スムーズな移行が可能になる。

Ubuntuでは、我々はMirですべてのデスクトップ環境が、Xであろうと直接的にであろうと、快適に動作するように注意を払っている。我々はUbuntuコミュニティ全員が満足するまでMirにゴーサインをかけない。他のディストリビューションも、軽快でクリーンなグラフィックスタックの恩恵をたやすく受けられるだろう。我々はすべてのアプリとすべてのデスクトップ環境が、変更なしに、13.10のMir上で快適に動くように、Xパフォーマンスの最適化で忙しい。我々はネイティブで超高速なMirアクセスの必要な機能をサポートしてほしい人からのパッチも受け付けている。ディストリビューションはMirをオプションとして提供することが容易に可能であるはずだ。Xに対するパッチは極めて小さい(500行以下だ)。現時点では、試したければ、最も簡単な方法はUbuntu PPA経由だ。我々のQAとリリースチームが、非常に広範なテストができるだけの準備が整ったと判断したならば、すぐさま13.10に搭載される。

一応、公平のために書いておくと、ツールキットのコミュニティは、Mirにあまり好意的ではない。表向きにはWaylandをサポートすると言いながら、裏で秘密裏に開発されていたというのもある。また、凝り固まったプロトコルといずれ発生する際限ない拡張の山のかわりにAPIを提供していると書くと聞こえはいいが、そもそもMirのドキュメントによれば、MirのAPIは将来予告なく変更される可能性があり、何らの互換保証もなく、従って一切依存できないものである。

2013-07-08

盲人、視覚障害、その他の印刷物に対する障害者への公開された作品に対するアクセスを調停するマラケシュ条約について思うこと

海外書籍を早く読みたい視覚障害者に朗報 世界185カ国が著作権者の許諾なしに点訳できる条約採択(1/2ページ) - MSN産経west

あの利用者の環境で動作するソフトウェアを利用者が制御することを禁止した条例、すなわち、DRM破りを違法とした不自然な著作権に関する世界知的所有権機関条約を創りだした著作権に関する世界知的所有権機関により、点字の各国間の扱いに関する条約が作成され、いま各国が署名しようとしている。

条約の正式名称は、Marrakesh Treaty to Facilitate Access to Published Works for Persons who are Blind, Visually Impaired, or otherwise Print Disabled(盲人、視覚障害、その他の印刷物に対する障害者への公開された作品に対するアクセスを調停するマラケシュ条約)といい、以下から文面を閲覧できる。

Marrakesh Treaty to Facilitate Access to Published Works for Persons who are Blind, Visually Impaired, or otherwise Print Disabled

これを読むと、点字だけではなく、あらゆる視覚障害やその他の印刷物や文字の読解に支障がある者に対する、利用可能なフォーマットの複製物(accessible format copy)の作成を認めている。

利用可能なフォーマットの複製を作成するのは、政府により認可された存在に限られる。またその目的も、非商用目的で、教育や訓練や障害者への利用を提供するものに限られる。

そう、基本は非商用目的だ。ただし、利用可能なフォーマットの複製物を作成するにあたってかかった費用を請求することは認められている。

なぜこの条約を取り上げたのかというと、産経の記事だけを読むと、なかなかおもしろいハックができそうに思えたからだ。

もし、点字翻訳に著作権が及ばないのであれば、あらゆる著作物は、点字翻訳を介して配布すれば、著作権が及ばない。点字エンコードと点字デコードを自動化すれば、なんと著作権を回避できるのだ。

しかしあらゆるものが点字で表現可能ではないという心配はご無用。あくまで可逆変換できればいいのだ。BASE64の点字版を作ればいい。

都合のいいことに、Unicodeにおける点字は、U+2800からU+28FFまでだ。つまり、あらゆる8bit単位のバイナリデータは、8bitごとに0x28を挿入すれいい。前に挿入すれば規格準拠のUTF-16BEエンコード、後ろに挿入すれば規格準拠のUTF-16LEエンコードされた点字テキストデータとして扱うことができる。逆変換も容易だ。

もし条例が、物理的に凹凸のある従来の点字印刷に限定していたとしても、世の中には、何十万、何百万とカネを積まないと手に入らないようなデジタルデータ(不思議なことに数百年前の科学論文とか)や、そもそもカネを積んでも著作権の利用許諾が得られないデジタルデータがある。十分に点字スキャナーと点字OCRを開発する需要がある。

とまあ、妄想は膨らむが、残念ながら実際の条約の文面を読んだところ、これはできそうにない。

条約では、「政府の認可を得た存在」を始めとして、「悪用しない」とか、「正しく」とか、「原著作者の利害と衝突しない」とかいった言葉がしっかりと使われている。これはハックの余地がない。

GCCの最適化オプション

郷に入っては郷に従えというが、GNU/Linuxのプログラミング環境にはまだまだ慣れない。とりあえず今のC++本執筆作業には、最新のClangでコンパイルできればそれで用が足りるので、Clangのビルドが楽なGNU/Linux環境は悪くない。欲を言えばlibc++もまともに動くようになってほしい。Ubuntu 12.10でlibsupc++を使ってlibc++をビルドしてみたところ、RTTI周りのABIに問題があるらしく、virtual関数呼び出しすらできなかった。

しかし、GNU/Linuxにおけるプログラミングはどうにも学ぶことが多すぎる。GNUのgdbの使い方もそろそろ覚えたいし、Autotoolsの使い方も覚えたいものだ。幸い、GNU/Linuxで一般的なテキストエディターであるVimは、特に何も学ばなくても使えるので楽だ。たかがテキスト編集作業に、多数のキーボードショートカットを覚えなければならないEmacsのようなOSは間違っていると思う。

とりあえず今のところ使い道はないが、GCCの最適化オプションを一晩学んでみた。

Optimize Options - Using the GNU Compiler Collection (GCC)

GCCには多数の最適化のためのオプションがあるが、最も一般的なものをまとめて有効にできるオプションがある。また、ドキュメントによれば、個々の最適化オプションを個別に有効になるよう指定しても、適切な-Oレベルが指定されていない場合は、単に無視されるのだという。

-O0

何も指定しない場合、これがデフォルトとなる。コンパイル速度を重視し、デバッグの際にも予期しないような結果にならない。

-O, -O1

これは最適化を有効にするオプションだ。これによって有効化される最適化はそれほど多くない。デバッグに支障のないものだけが有効化されるようだ。

-O2

GCCでデバッグを考慮せず最適化オプションを指定するというと、基本的にこれになる。ほとんどの最適化オプションはこれ一発で有効になる。

-O3

-O2では有効にされない最適化オプションをいくつか有効にする。効果の程は疑問だ。

とまあ、基本的にはこれだけだ。-O3でも有効にされない最適化オプションもあるが、それらは極端に限定的な効果だったり、また規格違反を犯す代わりに速くなるかもしれないといったようなオプションで、通常は使われない。後は例えばデフォルトで有効化されるが、無効化したい最適化オプションを個別に無効化するということもある。

その他にも興味深いオプションがある。

-Os

速度ではなくバイナリサイズが小さくなるように最適化する。-O2からバイナリサイズが大きくなる可能性のある最適化オプションを取り除いたもの。

-Og

これはGCC 4.8で追加された新しいオプションで、デバッグ機能を維持しつつ、速度も最適化するというオプションだ。デバッグ機能に支障をきたさない最適化オプションが有効にされる。編集してコンパイルしてデバッグといった作業にオススメだ。

-flto

LTO(Link Time Optimization)を有効にするオプション。これにより翻訳単位を超えた最適化が可能になる。

手元で怪しいマイクロベンチマークをしてみたり、またUbuntuのレポジトリにあるソフトウェアなどを最適化オプションを変えて自前でビルドしてみた結果、だいたい以下のような感想を持った。

-O2は明らかに効果が実感できる。-O3と-O2の違いは、コンパイル速度、実行速度ともに全く実感できない。LTOはコンパイル時間が極端に伸びるだけで、まったく効果が実感できない。一部のソフトウェアはLTOでビルドすると実行時に即座にセグフォる。

最後に、

-march, -mtune

これは特定のプラットフォームでのみサポートされているオプションで、特定のCPU向けに最適化する。とくに、いくつかプラットフォームで、-march=nativeとすると、コンパイル環境のコンピューターのCPUが判定され、そのCPU向けの最適化を行う。

と、特にこのようなプラットフォーム固有のコンパイル環境に特化した最適化オプションについて学ぶと、Gentooを入れたくなってしまう。しかしそれは、危険な誘惑だ。

このGentoo誘惑に負けそうな要因としては、最適化オプションを学ぶ際の余興として、普段使っているUbuntuのレポジトリにあるバイナリパッケージをいくつか、自前でCXXFLAGS='-O2 -march=native'などしてビルドしてみると、なんとパフォーマンスが実感できるほど向上したという事実がある。これはもだしがたい。

2013-07-06

Novenaオープンラップトップ(GPUとWi-FI以外バイナリブロブフリーでFPGA標準装備)

Building my Own Laptop « bunnie's blog
Update on Our Laptop (aka Novena) « bunnie's blog

オープンなラップトップを作ろうとしているプロジェクトらしい。

このラップトップは、できるだけオープンな部品を組み合わせてあり、また仕様は全て公開され、もちろんNDAを結ぶ必要はないので、誰でも自由に自作できるらしい。

オープンなハードウェアを作るというプロジェクトは過去にもいくつかあったが、いずれも、ソフトウェアはともかく、実際のハードウェアの技量や、製造の困難さから、途中で頓挫している。このプロジェクトは興味深いことに、すでに試作品の基盤を製造させているのだとか。これをもとにさらに設計を練り直すという。

いつ完成品を販売するのかとか、値段とかは、まだなにも決定していないそうだ。いずれ、それなりに出来上がったら、当初は「資格ある者」に限定して販売するそうだ。これは、まだド素人でも扱えるほどの完成度ではないので、無駄なトラブルを避けるために、「オープン」の意味がわかり、自力でハックできる能力をもった資格ある者のみに限定するそうだ。これにより、ユーザーサポートよりも開発に時間を費やせるとしている。

ムーアの法則がそろそろ通用しなくなり、また基盤設計や作成にかかるコストも、相対的にかなり安価になっている。今後もますます安くなるだろう。いずれ、ハードウェア・ルネッサンスのようなものが花開くのではないかという声もある。

具体的にどういうハードウェアになるのかというと、まずCPUはARMだ。FreescaleのiMX6Qを使う。

i.MX6Q Product Summary Page

GPUはVivante社のものを使うらしい。残念ながらこれは、不自由なバイナリブロブのファームウェアを必要とする。

Wi-Fiをつける場合にも、やはり不自由なバイナリブロブのファームウェアが必要になる。

GPUとWi-Fi、やはりこのふたつは現代における自由ソフトウェアの厄介事だ。ただし、ディスプレイもWi-fiもいらないというのであれば、バイナリブロブのファームウェアを使わずブートして動作させることも可能だそうだ。

その他は、まあ普通のラップトップにあるような外部ポートである、USBとか1Gbit ethernetとかもある。

面白い機能として挙げられているのが、とても興味深い。なんと、FPGAを搭載しているのだという。なんとも面白そうなオモチャだ。

そのほか、ディスプレイパネルも今の試作品で使っているのはLG LP129QE: 12.85″, 2560 x 1700 pixels (239ppi)だったりと、なかなか興味深い。

まあ、販売するとしても、今はまだお高くなりそうなオモチャだ。

2013-07-05

AMDがウケ狙いでドキュメント財団(LibreOffice)の相談役に加入、その他のLibreOffice 4.1のニュース

まあ、タイトルは煽りすぎたかもしれない。しかし、ウケ狙いとしか考えられないのだ。

AMD joins The Document Foundation Advisory Board to accelerate LibreOffice | The Document Foundation Blog
via [Phoronix] AMD To Exploit OpenCL Potential In LibreOffice

AMDが、LibreOfficeのドキュメント財団に、相談役として加わったという事が発表された。発表では、AMDの次世代HSAがどうたらこうたら。AMDの革新的なコンピューティングアーキテクチャーがなんちゃらかんちゃら、GPUによる並列性が云々、AMD APUユーザーはより大きな表をより高速に計算できる等々、営業がひねり出したような文句が並んでいる。

これがよくわからないのだ。LibreOfficeは主に、一般人でも使える文書レイアウトとか、表計算とか、プレゼンテーションなどのソフトウェアだ。それなのに発表では、GPGPUに言及し、また文字通り「より大きな表をより高速に計算できる」と書いてある。

LibreOfficeのような表計算ソフトウェアにGPGPUがどう役立つのだろうか。GPGPUが必要なほどの大規模な計算は、もっと数値計算に特化したソフトウェアとか、プログラミング言語などでやるべきではないのか。

追記:phoronix.comのコメントに、まさにこのことをキャプション付き画像で表現したものが貼られていた。

AMD To Exploit OpenCL Potential In LibreOffice - Page 3

「スプレッドシートが重すぎる・・・動かすのにOpenCLが必要だ」

スプレッドシートが重いという事は、その問題を解くためにはクソ間違ったツールを使ってるんだよ。

ましてや、移植性の高い方法でGPGPUを実装となると、OpenCLを使うことになるが、AMDのOpenCL実装は、公式の不自由バイナリブロブ、非公式の自由ドライバーともに悲惨だ。AMDはLibreOfficeのまえにやることがもっとあるのだ。

例えば、まともなOpenCL実装をするとか。

Problem with AMD and Cycles

BlenderはGPGPUを使う理由のあるソフトウェアである。BlenderのGPGPUを使ったCyclesレンダラーは、AMDのGPUでは動かない。これはBlenderのせいではなく、AMDの不自由なドライバーのOpenCL実装が極めて貧弱なためである。AMDの不自由なドライバーのOpenCL実装は規格に対応していると宣伝しているが、AMDのコンパイラーは、ちょっとでも大きな、つまり現実的なコードをコンパイルをさせるだけで、メモリ不足のエラーをだしてクラッシュするそうだ。実行以前の問題である。

nVidiaの不自由なCUDAは、個人的にとても残念なことに、とても使いやすいそうで、残念なことに広く使われている。またnVidiaの不自由なドライバーのOpenCL実装も、AMDの不自由なドライバーよりまともだそうだ。

とはいえ、現状ではOpenCLはどうも実装が未熟だそうだ。結局、nVidiaのCUDAのようなnVidiaのGPUでしか動かない独自のプロプライエタリな実装が使われている。例えば、BlenderのCyclesレンダラーも、デフォルトの実装はCUDAだ。OpenCL実装もあり、nVidiaの不自由なドライバー環境ならば、一応は動くそうだ。ただ、OpenCLの実装はどこも未熟なので、結局CUDAのような独自スタックに囲い込まれる。哀しいことだ。

追記:それなりに対応はしているようだ。

What's wrong with this file? | AMD Developer Forums

AMDはLibreOfficeのような有名ソフトウェアに席だけおいて宣伝に勤しむより、もっと根本的なソフトウェア実装をまともにする必要がある。どんなにハードがよかろうと、ハードを操作するソフトウェアが動かなければ、単なるヘアドライヤーにすぎない。ヘアドライヤーならもっと高機能なものがいくらでもある。もっと熱発生の電力効率がよくて、奇妙な電源コードを必要としたりしない。

ただし、発表にOpenCLの文字は一度も出てきていない。あるいは、AMDの独自スタックでやるのかもしれない。

せっかくLibreOfficeについて書いたのに、AMDのウケ狙いのことしか書かないのは残念なので、LibreOffice 4.1について紹介している以下の記事から、特に興味深いものを、いくつか紹介する。

Stuff Michael Meeks is doing

LibreOffice 4.1では、ビルドシステムが劇的に向上する。従来、LibreOfficeではdmakeを独自に改良したものを使っていた。dmakeとは、makeの実装の一つで、まあ大半のmakeと同じような機能をそなえているそうだ。

LibreOfficeは、GNU makeへの移行を進めてきたが、まだ移行が完全に済んでいないので、gnumakeとdmakeを併用しなければならず、またとてもおかしなシェルスクリプトを実行しなければならない。

このおかしなシェルスクリプトは、コンパイルに必要となる環境変数群を設定する。そのため、このシェルスクリプトは環境変数をシェルに留めるため、sourceで実行しなければならない。環境変数をビルドのために変更するので、笑えることに、一度ビルドしたシェルで、再びビルドすることが不可能なのだそうだ。もう一度ビルドしたければまっさらなシェルを起動しなければならない。さらにPerlで実装された独自ビルドシステムで2レイヤー式の並行ビルドを実現したりとか、わけのわからないことになっている。

ビルドは以下のような感じだそうだ。

# old and awful
autoconf
./configure --enable-this-and-that
source LinuxIntelEnv.Set.sh
./bootstrap
cd instsetoo_native
build --all

LibreOffice 4.1では、126000個のターゲットと1700個のmakefile、つまりすべてを完全にGNU makeに移行させた。

新しいビルドの感じ

# LibreOffice configure & make as of now:

./autogen.sh --enable-this-and-that
make

単純だ!

LibreOfficeのソースコードには、ドイツ語で書かれたコメントが多数あるそうだ。国際的な貢献を得るためには、コメントは全て英語で書かれていることが望ましい。そのため、今ドイツ語のコメントをすべて英語に翻訳する作業が進められている。LibreOffice 3.3では5万件以上あったドイツ語のコメントが、LibreOffice 4.1では、あと1万6千件強といったところまで減らせたらしい。ドイツ語の分かる貢献者を募集中なのだとか。ドイツ語のコメントを探すためのツール、bin/find-german-commentsも用意されている。

LibreOfficeは、Javaへの依存度を減らすべく努力してきた。これはすばらしいことである。特に、Javaランタイムを宗教上の理由で排除している私のような人間にはとても好ましい。LibreOfficeでいまだにJavaを使っている部分としてよく言われるのが、一部のウィザードとデータベース関連だ。LibreOffice 4.1では、Javaで書かれたウィザードを、すべて完全にPythonで置き換えたそうだ。

2013-07-04

Arch Linuxの意味と由来

昨日、本の虫: GNU/Linuxベースのディストロの名前の意味と由来を書くために、主要なGNU/Linuxベースのディストリビューションの名前の意味と由来を調べた。しかし、Arch Linuxの意味と由来だけは、どうしても発見できなかった。

答えは意外なところで見つかった。

Archive.org。まさかそこに答えが保存されていようとは。

Arch Linux

[Q] Arch Linuxと名付けたのは何故?

[A] dictionary.comより:

arch (ärch)
形容詞

  1. 主要な、第一の: 第一の敵(their arch foe.)
  2. イタズラ好きな、有害な、わんぱくな: やんちゃな一瞥(an arch glance.)

本で使われているarch-enemy(主要な敵)から、私はarchというのが、「第一の」とか「主要な」といった意味を持つものと考えていた。そういう言葉がまっさきに頭に浮かんだのだ。Arch Linuxの実情を示すものとしては似つかわしくないにせよ、私は誇りに思っている名前だ。さて、二つ目の定義については、合うかもしれないし合わないかもしれない。どのようにコンピューターを使っているかによるだろう(^_^;)

ローリングリリースモデルを採用していて、アップデートするとXが起動しなかったりブートすら不可能になったりするほどシステムが壊れることもあるが、そういう場合でも、ユーザーは淡々と自力で修復できるほどのスキルを持っていることが期待されているディストロとしては、二つ目の定義の方が合うのではないか。

ちなみに、Arch Linuxの不安定性に対して挑発的な言葉を投げかけると、私の知る複数のArch Linuxユーザーは、まるで申し合わせたかのように、「たとえぶっ壊れようとも、bootable USBドライブさえ用意しとけば何の問題もない。すぐ直せる」と答える。Arch Linuxユーザーとはそういう人種なのだろう。それは発生した不具合への対処方法であって、不安定性への根本的解決ではないと私は思うのだが。

ところで、Archive.orgが保存していたのは、2002年当時のarchlinux.orgである。たったの11年前なのに、もう公式サイトではベイポライズされている。それどころではない、公式サイトで、恥ずかしげもなく、Arch Linuxの昔の開発歴史を調べたければarchive.orgを参照せよと書いているのだ。

History of Arch Linux - ArchWiki

これは憂うべきことである。もっと歴史資料の保存にも気をつけるべきだ。前に、pcworld.comの記事、なぜ歴史には海賊が必要なのかを訳したが、ゲーム歴史家が、歴史資料であるゲームとその動作環境の保存は海賊に頼らなければならない現状を嘆いていた。

マリオが誰であるかを知らない15-35才のアメリカ人がいるであろうか?(もしそんな奴を見つけ出してきたとしたら、そいつは1980年から1999年にかけて、地下室に監禁されていたに違いない)

法律に抵抗する保存家達の活動に感謝するべきである。これによって未来の歴史家はマリオが文化に与えた影響をより深く考察することができる。「なぜ古代人はみな、ドット絵のキノコ人間がプリントされたTシャツを着用していたのであろうか」とか、「どのゲームにマリオが登場したのか、それはなぜか」などという疑問も、明らかにすることができるであろう。

任天堂がこの先200年生き延びることは、可能である。しかし、彼らはこのような疑問に全て正しく答えることはできないであろう。企業は顧客に見せられる商業的価値のあるものしか残さないものだ(例えば、スーパーマリオブラザーズ3を繰り返しみせる)。歴史家は、すべてを見せる。ホテルマリオ[訳注:CD-iで公式な許諾を得て発売されたお世辞にも出来がいいとは言えないマリオのゲーム、アメリカ限定]、マリオルーレット[訳注:コナミから発売されたアーケードゲーム、いわゆるメダルゲー、日本限定]、アイアムアティーチャー スーパーマリオのセーター[訳注:ディスクシステムにてこのタイトルで発売されたマリオをつかった編み物の教育ソフト、日本限定]。これらのゲームは、海賊によらなければ、200年を生き延びることはできない。なぜならば、任天堂はこのような低品質のゲームを、やや恥じており、著作権法で封印して、朽ちるに任せているからだ。

2013-07-03

理想の世界

片山さつきが初音ミクが死ぬという表現を使ったのは極めて不快であり、公の秩序のためにセディシウスパーソンであるので、片山さつきはベイポライズすべきである。

同時に、片山さつきにたいして極端な反対意見を表明する勢力を構築する要素を持った初音ミクという架空キャラクターも公の秩序のためにセディシウスマテリアルであるので、ベイポライズすべきである。

後日、名無しが101号室にて。

「同志は先日、「初音ミクがデッドならば」と発言した。さて、初音ミクはデッドなのかね」
「死んでません」
「間違いだ。職員同志、一段階上げ給え」
名無しの悲鳴の声
「さて、もう一度アスクしよう。初音ミクはデッドなのかね」
「死んでます」
「間違いだ。職員同志、一段階上げ給え」
気絶

「さて同志、もう一度アスクしよう。初音ミクはデッドなのかね」
「生きているか死んでいるのか分かりません。どちらでもあなたの好きな方にします」
「だいぶマシになったな。同志、初音ミクはデッドではないしリビングでもない。パーティがデッドだとするならばデッドだし、リビングだとするならばリビングなのだよ」

「残念ながら、リハビリテーションの後期課程はバジェットリデュースのためにカットされてしまった。同志はユアセルフでやりたまえ。プリパレーションにはケージとラットが必要だ」

「おめでとう。同志はすっかりヒールされた」

治療後、新たな名前と仕事を与えられた元名無しは、自宅で勝利ジンをやりながら、ぼんやりと外を眺めていた。初音ミクのITアドミニストレーターサーティフィケイトのポスターが壁に貼られているのがみえる。何の感情も浮かばない。すぐさまダブルシンクを使って考える。あらゆるものは合法であると同時に違法であり、パーティの発表は常に正しいのだ。自分は何という反社会的、テロリスト的過ちを犯してしまったのだろう。パーティが正しい道徳的規範に導いてくれて、本当に感謝している。

対応する例外ハンドラーがなくstd::terminateが呼ばれる状況で、stack unwindingが行われるかどうかは実装依存

C++の規格上、対応する例外ハンドラーがないと、std::terminateが呼ばれるわけだが、その状況で、stack unwindingが行われるかどうかは実装依存となっている。

つまり、

struct X
{
    X() ;
    ~X() ;
} ;

int main()
{
    try {
        X x ;
        throw 0 ;
    } catch( double ) { }
}

このようなコードがあった時、対応する例外ハンドラーが存在しないので、std::terminateが呼ばれるわけだが、xのデストラクターが呼ばれるかどうかは実装依存となる。

ファイル転送とか万能ソフトウェアとか

今考えているとりとめのないモヤモヤとした思いを書いてみる。

先日、本の虫: xkcd: ファイル転送(と、その解決手段としてのTCP simultaneous openの可能性)で、インターネットができてから何十年も経つのに、いまだに特定の二者間で第三者サーバーを介さずにファイル転送をする簡単な方法がない現状について書いた。

Sharefestというものがある。これは、WebRTCを利用して、ブラウザー上でBitTorrentプロトコルもどきを実装したものだ。まあ、面白い試みではある。ただ、その「面白い」というのは、「HTMLのtable要素で絵を作った」とか、「CSSで絵を作った」という試みに対して感じる「面白い」と同等の感想であって、実用的とか使いたいといった感想ではない。

ピクセル単位で表現された画像が使いたければ、BMPやJPEGやPNGのような画像フォーマットがあるし、ベクトルで表現された画像が使いたければ、SVGのような画像フォーマットがある。これらの画像フォーマットはすでに実績があり、仕様が環境やプログラミング言語非依存で詳細に説明されており、独立した自由なソフトウェア実装も複数存在する。

もちろん、WebRTCはブラウザー間の通信を目的として設計されたAPIであり、WebRTCをBitTorrentプロトコルもどきの実装に使うのは、tableやCSSを画像表現に使うよりは、まともだと言える。問題は、そもそもなんでそういう実装をしなければならないのかという事だ。

BitTorrentプロトコルが使いたければ、単に既存のBitTorrentプロトコルを実装したソフトウェアを使えばいいのだ。あるいは、ブラウザーでBitTorrentプロトコルをサポートすればいいのだ。BitTorrentプロトコルはすでに実績があり、仕様が環境やプログラミング言語非依存で詳細に説明されており、独立した自由なソフトウェア実装も複数存在する

Sharefestは、ソースコードがApache 2.0で公開されているので、自由なソフトウェアであるが、実績、ドキュメント、複数の独立した実装などという点で、既存のBitTorrentプロトコルに劣っている。

もちろん、既存のBitTorrentクライアントが、初心者には使いづらいという現状はあるかもしれない。また、特定の二者間でのファイル転送といった用途に手軽に使えるよう作られていないという現状もあるかもしれない。しかし、だからといって、ブラウザー上に実装されたWebRTCをJavaScriptで操作して劣化BitTorrentプロトコルの実装を作りましたというのはなにかおかしい。

そもそも、なぜ人は、単独で何でもできる万能ソフトウェアを欲しがるのだろうか。UNIXの、「ひとつのことのみうまくやる」という思想はどこへ消えたのか。検索をうまくやるgrepや、テキスト置換をうまくやるsed、複数のファイルをうまくまとめるアーカイバーとしてのtarや、ファイル圧縮をうまくやるxz。複数の機能が欲しい時は、これらを組み合わせればいいのではないか。

現実は、そのようにはなっていない。すべてのテキスト処理が行えると豪語するEmacsや、すべてのオンライン処理を担おうとしているブラウザー、クソバカがクソ画像一枚を送るのにも使うマイクロソフトのクソ不自由なクソExcelなど、単独で何でもできる万能ソフトウェアがもてはやされる。

ところで、最近書いたブログ記事に、本の虫: 自由ソフトウェア財団がBitTorrent Syncを高優先度ソフトウェアプロジェクトに指定というものがある。BitTorrent Syncとは、複数のコンピューター間でファイル共有を行う不自由なソフトウェアだ。自由ソフトウェア財団は、BitTorrent Syncの自由ソフトウェアによる実装が取り急ぎ必要だとしている。先日はBitTorrent Syncなんて誰が必要としているのかと疑問だったが、現状でファイル転送を第三者サーバーを介さずに手軽に行う方法がない以上、案外必要なのかもしれない。

この記事に特に結論はない。

2013-07 mailingの簡易レビュー

2013-07 mailingが公開された。

CD(Committee Draft)はN3690、Working DraftはN3691だ。

C++14としては、もうCDがこれ以上大幅に変更されることはないだろう。

また、今回の論文は、C++14のCDを変更するものではなく、C++14以降の将来の変更の方向性を示すものであると書かれている。

N3692: C++ Editor's Report, May 2013

C++ドラフトの編集者による、今回の変更部分の報告。今回はかなり詳細にまとめられている。

N3693: Draft Filesystem Technical Specification

Filesystemライブラリの文面案。

よくぞここまできっちり書き上げたなぁと思うぐらい、詳細に書かれている。世の中の仕様書もこれぐらい詳細に書かれていたら、世のプログラマーの仕事は相当に楽になるであろうに。

N3694: Feature-testing recommendations for C++

Cプリプロセッサーを使って機能テストをする際に役立つ、実装によって定義済みのマクロの推奨。

C++11実装のコンパイラーやライブラリが発展段階の現状、ある機能が実装によってサポートされているかどうかを調べるために、例えば以下のようなクソ汚いクソプリプロセッサーが書かれている。

#ifndef __USE_RVALUE_REFERENCES
  #if (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__ >= 3) || \
      _MSC_VER >= 1600
    #if __EDG_VERSION__ > 0
      #define __USE_RVALUE_REFERENCES (__EDG_VERSION__ >= 410)
    #else
      #define __USE_RVALUE_REFERENCES 1
    #endif
  #elif __clang__
    #define __USE_RVALUE_REFERENCES __has_feature(cxx_rvalue_references)
  #else
    #define __USE_RVALUE_REFERENCES 0
  #endif
#endif

このコードの目的は、rvalue referenceがサポートされているかどうかによって、__USE_RVALUE_REFERENCESマクロ定義を0か1にすることである。このマクロは、コードの別の場所で、実装をコンパイル時に切り替えたりするのに使える。

このようなクソコードはクソ書きたくない。第一、新しいC++実装をサポートするたびに書きなおしだ。どうせこのようなコードが必要悪なのだとすれば、ある機能をサポートしているかどうかの定義済みマクロを、実装が提供しているべきではないのか。あるいは、実装が提供しておらず、ユーザーが定義しなければならないとしても、マクロの名前は推奨の業界標準があるべきではないのか。

というわけで、そのような定義済みマクロの名前と値の推奨を行う論文。これは実装への強制ではなく、単なる推奨となる。

たとえば、実装が二進数リテラルをサポートしている場合、__cpp_binary_literalsが定義される。

マクロの値は、該当機能の論文が投票でworking draft入りに可決された年と月を示す。たとえば、二進数リテラルのマクロ__cpp_binary_literalsの値は、2013年4月にドラフト入りが可決されたので、201304となる。

これにより、例えば後のドラフトで機能変更が起こった場合でも、マクロの値を見ることによって、いつ可決されたときの仕様なのかが分かる。

また、この論文では、現行のC++14 CDには入っていない、ある名前のinclude fileが存在するかどうかを調べる__has_includeが、C++14に採用されることを前提にしている。

私は、クソプリプロセッサーは一刻も早く廃止すべきだという立場なので、クソプリプロセッサーを使うあらゆるクソ機能に断固としてクソ反対する。

[立場上でなくても当然クソ反対するクソPDF] N3695: SG5: Transactional Memory (TM) Meeting Minutes 2013/03/11-2013/06/10

Transactional Memoryの会議の議事録。

N3696: Proposal to extend atomic with priority update functions

atomic操作で一般的な操作として、値を読み込み、何らかのpredicateで比較し、predicateがtrueを返す時に、値を更新するという操作がある。この操作で、predicateとしてよく用いられるのは、less thanやgreater thanである。このような操作は、任意のpredicateに対して汎用的に実装できるので、ライブラリとして提供する提案。また、よく使われるless thanやgreater thanに対しても、それぞれfetch_minとfetch_maxという名前で提供する。

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

template <typename V>
T priority_update(T value, V predicate)
{
  T read = this->load();
  while (predicate(value, read) {
    if (this->compare_exchange_weak(read, value))
      return read;
  }
  return read;
}

T fetch_min(T value)
{ return priority_update(value, less<T>); }

T fetch_max(T value)
{ return priority_update(value, greater<T>); }

これは、atomicクラスのメンバー関数として実装し、さらに外部の関数テンプレートとして、atomic_priority_update, atomic_fetch_min, atomic_fetch_maxも提供する

N3699: A proposal to add a generalized callable negator

汎用的なnegatorであるnot_fnを追加する提案。従来のnot1やnot2は、引数の数がひとつかふたつに限られている。Boostでfunctionやbindの実装が研究され、またVariadic Templatesがある今、もっと汎用的なnegatorを提供できる。

N3700: Hierarchical Data Structures and Related Concepts for the C++ Standard Library

汎用的なツリー構造を、STLのコンテナーのようなインターフェースのライブラリとして提供する提案。利用者がツリー構造の実装の詳細に関わらずに、ツリー構造を使えるようになる。

元々は、Google Summer of Code 2006でBoostに含めるべく実装が試みられたもので、いまだに実装は完成していないのだが、ソースコードはGitHubで公開されている。

grafikrobot/boost-tree · GitHub

setやmapといった特別な用途の実質バイナリツリーではなく、もっと汎用的に使えるツリー構造のライブラリというのは面白い。ただし、既存の実装例がなく実装中で、まだBoostに正式に取り込まれておらず、実装例の利用例も乏しい現状では、もうすこし成熟するのを待ったほうが良さそうだ。実際に利用してみないとインターフェースの良し悪しは分からない。

[まるで暗い未来を暗示するかのようなPDF] N3701: Concepts Lite

もうすでに紹介したが、Concept Liteの論文。[PDF注意] N3580の改訂版。

[title要素のない失礼なHTML] N3702: Introducing an optional parameter for mem_fn, which allows to bind an object to its member function

mem_fnに仮引数を追加してクラスオブジェクトを割り当てられるようにする提案。

例えば以下のような関数があったとする。

double integrate(
    std::function<double(double, double, double, double, double)> f,
    double x1, double x2, double y1, double y2, double z1, double z2,  double a1, double a2, double b1, double b2
) ;

fに渡される実引数は、残りの実引数から計算される。

この関数の最初の実引数に以下のようなクラスのメンバー関数A::faを関数オブジェクトとして渡したい場合、

class A
{
     double p;
 
public:
     A(double p1):p(p1) {}
     void set_param(double p1) {  p = p1; }
     double fa(double x, double y, double z, double a, double b);
};

なんとかして、A::faの呼び出しには、クラスAのオブジェクトを結び付けなければならない。

それにはいろいろ方法がある。

1. bindを使う方法

double r =  integrate( std::bind(&A::fa, &a, _1, _2, _3, _4, _5),
    x1, x2, y1,y2, z1, z2, a1, a2, b1, b2);

わざわざ_1から_5まで指定しないといけないのが強烈に面倒だ。

lambda式を使う方法

double r = integrate(
    [&a](double x, double y, double z, double a, double b) { return a.fa(x, y, z, a, b);},     
    x1, x2, y1, y2, z1, z2, a1, a2, b1, b2); 

わざわざ仮引数、と実引数をforwardするのが強烈に面倒だ。

グローバル関数でラップする方法

// 何らかの方法でクラスAのオブジェクトを取得
double f(double x, double y, double z, double a, double b) { return a.fa(x,y,z,a,b); }

double r = integrate(f, x1, x2, y1, y2, z1, z2, a1, a2, b1, b2);

汚い。

この問題は、単にメンバー関数にクラスオブジェクトを束縛できるライブラリがあれば、とても簡潔に書ける。

double r = integrate(some_binder(&A::fa, &a), x1, x2, y1, y2, z1, z2, a1, a2, b1, b2); 

そこで、mem_fnにそのような機能を追加しようという提案。

[titleのない失礼なHTML]N3703: Extending std::search to use Additional Searching Algorithms (Version 3)

N3606の改訂版。既存std::searchを拡張し、BMなどの検索アルゴリズムを引数で指定できるようにする提案。

GNU/Linuxベースのディストロの名前の意味と由来

有名なGNU/Linuxベースのディストリビューションの名前の意味と由来を調べてみた。

本文ではディストロやプロジェクトの名前を使っているので、LinuxカーネルとGNUユーザーランドを使ったシステムであっても、Arch LinuxとかGentoo LinuxMandariva LinuxとかFedora LinuxなどはGNU/Linuxではなく、そのまま表記している。

Slackware

ディストリビューションのさきがけともいえる存在だが、もともと、Slackwareは広く一般向けのディストリビューションを目指してはいなかった。そのため、真面目に受け取られることを防ぐ目的で、わざとふざけた名前が付けられた。slackというのは、どうもパロディ宗教のChurch of the SubGeniusに由来するようだ。

Slackware - Wikipedia, the free encyclopedia

Debian

Debian創始者のIan Murdockの嫁の名前Debraから三文字debをとり、ianを付け足して、Deb + ianと名付けた。

A Brief History of Debian - Introduction -- What is the Debian Project?

また、Debianはカーネルやユーザーランドに応じて名前を付け足すので、Debianには、Debian GNU/LinuxとDebian GNU/kFreeBSDとDebian GNU/Hurdが存在する。

Ubuntu

アフリカの思想の用語らしい。意味は、「人への思いやり」といったものらしい。

Ubuntu (philosophy) - Wikipedia, the free encyclopedia

Red Hat Enterprise Linux

Red Hatは文字通り「赤い帽子」を意味する。開発元の社名もRed Hatだ。その由来は、Red Hatの共同出資者のBob Youngへのインタビューによれば、西洋では、赤い帽子は昔から自由のシンボルとして使われていて、アメリカやフランスの革命の際にも着用されていたのだという。

テープに録音されたBob Youngの言葉によれば、「西洋史では、赤は自由や権威への挑戦のシンボルだった」とのことだ。

How Red Hat got its name

もともとは今のFedoraとRHELを合わせた性格のRed Hat LinuxがRed Hat社によって開発されていたが、一般向けのディストロの開発はコミュニティベースのFedoraに移し、Red Hat社としてはエンタープライズ向けのディストロに専念するため、今の名前になった。

Fedora

フェドラとは、帽子の一種の名前だ。おそらくはRed Hatの帽子の意味つながりでこの名前にしたのだろうが、名前決定の一次ソースが発見できなかった。経緯としては、もともとFedora Linuxという、Red Hatにソフトウェアを追加する有志のプロジェクトがあり、Red Hatがエンタープライズ用になった今、従来の一般向けのディストロ開発はコミュニティベースのFedoraに引き継がれた。

Fedora (operating system) - Wikipedia, the free encyclopedia

Arch Linux

由来不明。意味も不明。意味はArchitectureかArchwayではないかと思われるのだが。

一般に英語でのArchの読みは、Archwayのようなアーチと、Noah's Arkのようなアークの二通りが考えられるが、MLでの議論によれば、Arch Linuxの正式な読みはアーチだそうだ。

linux.arch.general - Re: Pronnounciation of our beloved distribution's name - msg#00254 - Recent Discussion OSDir.com

Gentoo Linux

Gentooは、ペンギンの一種の名前である。Gentooペンギンは、最も泳ぎの速いペンギンであり、Gentooのすばらしい改良速度と動作するプラットフォーム向けの最適化を示すものとして選ばれた。ちなみに読みはジェンツー。

Gentoo Linux - Wikipedia, the free encyclopedia
ジェンツーペンギン - Wikipedia

openSUSE

openSUSEは、SUSEというディストリビューションが元になっている。SUSEはもともとS.u.S.Eと表記されていて、これはドイツ語で、"Software und System-Entwicklung"の頭文字である。これは英語では、"Software and systems development"という意味であり、日本語では、「ソフトウェアとシステム開発」といった意味だ。

SUSEの商標はNovellに買収されたが、NovellはSUSEの開発自体はコミュニティによって行われたほうがいいと考えたので、開発の資金援助などはしているが、開発自体はコミュニティで行われている。

openSUSE - Wikipedia, the free encyclopedia

Mageia

ギリシャ語に由来し、意味は「魔法」。

退屈な由来としては、以下に詳しい。

[Mageia-discuss] origin of the name "mageia"?

多くの名前候補のなかから、既存の商標やドメイン名との衝突を避けて選ばれたのがMageiaだったらしい。

MageiaはMandriva Linuxからのforkだが、特にfork元の意味に似通ったものにするとか、Mから始まる名前にこだわったということはないらしい。

Mageia - Wikipedia, the free encyclopedia

Mandriva Linux

もはや活発に開発されていないディストロだが、名前変更の経緯が面白かったので紹介。

最初は、Linux-Mandrakeという名前で公開したが、後にMandrake Linuxとなった。既存の商標と衝突し、裁判で負けたため、空白を除去した、Mandrakelinuxになった。

開発元のMandrakeSoftが買収されたことや、以前からの商標の問題をきっかけに、会社名とともにディストロ名もMandrivaに改名した。

Mandrakeとは、日本でもマンドレイクやマンドラゴラなどと音訳されて呼ばれている植物だ。この植物は幻覚作用があることから、魔術的な意味合いを付けられていて、しまいには、抜くと金切り声を上げる、この金切り声を聞いたものは死ぬ。そこで、この魔法の草の採取には、縄を繋いだ犬を走らせ、また人間はできるだけ遠いところから耳にロウを詰めて防衛することなどとおかしな伝説まで広まった。

Mandriva Linux - Wikipedia, the free encyclopedia

とりあえず、それなりに有名で、現在も活発に開発が続けられていて、利用者も大勢いるディストロについて調べた。

Fedora 19がリリースされた

Announcing the release of Fedora 19!

Fedoraプロジェクトは喜ばしくFedora 19(シュレディンガーの猫)のリリースをアナウンスする。箱を開けて中身を確かめよう!

Fedora 19がリリースされた。コードネームはSchrödinger's Cat(シュレディンガーの猫)なので、「箱を開けて中身を確かめる」とネタにされている。

Fedora 19は以下からゲットできる。

Fedora Project - Download Fedora and try it.

やはりコードネームネタはFedora 17 Beefy MIracleが最も面白かった気がする。

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

と、コードネームのネタだけ紹介するのも何なので、Fedoraは使っていないのでよくわからないが、一応興味を引いたところを紹介していく。

OpenSCAD, Skeinforge, SFACT, Printrun, RepetierHostなどの、3Dモデリングや3D印刷のためのソフトウェアが追加されたらしい。

MySQLに変わって、MariaDBがデフォルトになった。

日本人としてとても気になるのは、Fedora 19には新しいIMEである、kkcがパッケージ化されて入っているということだ。

Features/libkkc - FedoraProject

何でもValaとかいうあまり聞かない言語で書かれているらしい。出来が気になるところだ。

ただし、デフォルトは依然としてAnthyなのだとか。

2013-07-01

xkcd: ファイル転送(と、その解決手段としてのTCP simultaneous openの可能性)

xkcd: File Transfer

親戚にファイルを送ってもらいたいって? 簡単だよ、メールで・・・え、25MBだって。そっかー。
どっちかFTPサーバー持ってる? 持ってない? そっかー。
Webホスティング使ってるならアップロードして・・・
うーん、どっかのMEGASHAREUPLOAD的なサイトもあるんだけど、あの手のはいまいち信頼性にかけるしエロサイト広告満載だし。
AIMダイレクトコネクトはどうだい。え、そんなのいまどき誰も使ってないって?
そうだ、Dropboxがあった。数年前に始まったよさげなスタートアップでね、コンピューター間でフォルダを同期してくれるんだ。ただアカウントとってインストールして・・・
え、ちょうど親戚がUSBディスクもって家まで車でやってきた?
まあ、それもひとつの手だね。

もうインターネットは数十年もあるのに、「ファイルを送る」という事に関して、いまだに決定的な方法がないのは笑える。

一般人が、インターネット越しにファイルをやり取りするのは、意外と難しい。一般人は自前のサーバーなど持っていないし、レンタルサーバーを借りているなどという事もない。

ファイルのアップロードサイトは多数あるが、どれも微妙で、しかもエロサイト広告やマルウェアのインストールを促すような広告で溢れかえっている。個人間でのファイルのやり取りにはあまり向いていない。

AIMとかIRCなどは、とっくに一般人には廃れている。

Dropboxのような複数のコンピューター間でのファイル同期サービスもあるが、まずアカウントを取得して専用の不自由ソフトウェアを使わねばならず、しかも動作は第三者のサーバーに依存する。

結局、ストレージを足で運ぶスニーカーネットに負けてしまう。

現状で、インターネットの末端のホスト同士が直接接続して通信するのは、とても難しい。直接接続してファイルを転送するようなソフトウェアはあるが、まず、お互いに何とかしてIPアドレスとポート番号を教えなければならない。

しかも最近はNATの普及により、直接接続が一層難しくなっている。NATの設定には知識が必要だし、自分が管理者であるのならばまだしも、自分がNATを設定する権限を持たない場合は、どうしようもない。

もちろん、NATを超える技術はいくつも考案されているし、第三者のサーバーに依存しない、すなわちP2Pのファイル共有プロトコルも多数考案されているが、やはり特定の二者間でファイルを転送するには、時間や手間がかかりすぎるプロトコルが多い。

なぜこのxkcdを今更訳したのかというと、Hacker NewsでTCP simultaneous openの仕様が話題になっていたからだ。

TCP simultaneous open and peer to peer networking | Hacker News

TCP simultaneous open and peer to peer networking

TCPで、ふたつのホストがお互いのIPアドレスに、ephemeralポート以外のポートを使って、お互いに同時に接続要求をかけた場合、なんと一本の接続として成立するのだという。これは仕様上明確に定められており、お互いに自分からの接続なので、NATを超えることができる。

問題は、同時に接続というのが難しい。同一のLAN内だと、あまりのレイテンシーの低さに、タイミングがシビアすぎて失敗してしまう。また、予期しない接続要求に対してRSTパケットを送り返すデバイスが間にある場合にも、うまく行かない。

しかし、末端の一般人のインターネット越しの通信では、レイテンシーが高いため、同時接続要求が成立するタイミングは何度か試せば成功するほどの高確率であるし、また個人用のルーターでは、どこの馬の骨かもわからないホストからの予期しない接続要求に対して、わざわざRSTパケットを律儀に送り返す実装をしているようなものもほとんどないらしい。つまり、TCP simultaneous openは十分に実用的に使える可能性がある。

つまり、IPアドレスとポートを何らかの方法でお互いに知ることが出来れば、TCP simultaneous openでNAT越しにも接続できる。IPアドレスのマッチングは、それほど帯域を利用しないので、第三者サーバーで実装するコストも安く済む。

と、TCP simultaneous openはなかなか面白い仕様なのだが、現実には全然使われていない。NAT越えを考慮したP2Pプロトコルでも、UDP hole punchingを使うことが多い。

UDP hole punchingもまた面白い技法だ。これは仕様上保証された技法ではない。もとより、NATがどのように実装されるかということについての仕様などない。

NATの実装で一般的な方法は次のようなものだ。NATは外からのパケットは基本的に弾く。ただし、NATの内側のあるホストから、外側のあるホストへのパケット送信があった場合には、外側のホスト情報と、内側のホストとその時に使ったポート情報を記録しておく。この記録は、ふたつのホスト間の最後の通信からしばらくの間(数十秒から数分)、持続する。外側から特定のポートに対してパケットが送られた場合、この記録に対応する内側のホストがあれば、そのホストにパケットを届ける。

ほとんどのNAT実装で、UDPの場合は、外側からの任意のホストからのパケットを受け付ける。つまり、NAT越えをしたい内側のホストは、一体別の第三者サーバーにUDPパケットを送信する。これによりNATにしばらく記録が残る。その記録が残っているうちに、本当に通信したい別のホストがNATのIPアドレスのそのポートに対してUDPパケットを送りつける。NATの実装にもよるが、結構な実装で動く。

耳をすませばと眼鏡越しの空の恋愛模様に感じる違和感

ふとTwitterをみたら、こんなtweetがretweet経由で目に入った。

耳をすませばを当時みた感想としては、あることにものすごい違和感を感じた。主人公が、図書館の紙の図書カードに書かれている借りた人の名前が気になり、そこから恋愛が始まるというところだ。

昔、図書館では本の貸出履歴を記録するために、紙のカードを使っていた。その紙の図書カードは、通常本に挟んでおくので、図書館では誰でも閲覧可能な状態になる。したがって、ある本を誰が借りたのかがまるわかりになる。そんなプライバシーのかけらもない世界が、1995年当時から信じられなかった。

借りた人間の情報を一時的に保管しておくのは分かる。返さず忘れている人間に催促状を送る必要もあるからだ。しかし、なぜ借りた履歴が他人にまるわかりな状態である必要があるのか。

当時、私が物心ついて図書館を利用するようになった時からすでに、借りた人間の情報はコンピューターで管理するようになっていた。コンピューター管理は新たな問題を生む。ちゃんと履歴は不必要になった時点で消されているのかどうかだ。さもなければ、電子化されたプライバシー情報は大規模な統計処理に使えてしまう。その裏側はともかく、本の貸し出し履歴が誰にも公開されるようにはなっていなかった。

映画の「耳をすませば」は、スタジオジブリにより1995年に公開されている。参考のためにリンクしているアマゾンで販売されている製品はDVDであり、CSSという邪悪なDRMを含むので注意。VHSの方にリンクしようかと思ったが、どうせVHSも邪悪なコピーガードノイズを含むだろうから同じだと思って、DVDにした。

耳をすませば [DVD]

その1995年当時でさえ、このプライバシー駄々漏れ状況が理解できなかった。今調べると、「耳をすませば」には、実は原作があるという。少女漫画雑誌のりぼんに1989年8月号から1989年11月号まで連載された柊あおい名義の同名の漫画作品だという。マンガ公開時の1989年の感覚では、紙の図書カードで貸し出し者履歴がダダ漏れなのが一般的だったのだろうか。

耳をすませば (集英社文庫―コミック版)

また、DREAMS COME TRUEという名前の音楽グループの作品に、「眼鏡越しの空」というものがある。この歌詞に、やはり他人が図書カードの履歴を閲覧しているらしい記述がある。

図書館で借りた 空の写真集
カードに つよくてきれいな あなたの名前がある

眼鏡越し空、The Swinging Star(1992)収録

これも恋愛の話だ。この歌は、The Swinging Starという1992年に公開されたアルバムに収録されている。これはどうやら、好きな人間が借りた本なので借りているのだろう。1992年当時、好きな人間の図書館の貸し出し履歴を探すというストーカーまがいの行為がよしとされていたのだろうか。

1990年前後といえば、まだ私は文字の読み書きができるような歳ではなかったし、ほとんど記憶がないので分からない。

もちろん、1990年前後の作品といえども、作っている人間はその年に生まれたのではない。

漫画耳をすばせばの作者柊あおいは1962年生まれ、

柊あおい - Wikipedia

眼鏡越しの空の作詞者の吉田美和は1965年生まれ、

吉田美和 - Wikipedia

どちらも1960年代だ。1960年代に生まれた人間は、好きな人間の図書館の貸し出し履歴を探すというストーカーまがいの行為でプレイバシーダダ漏れの状況に疑問を感じなかったのだろうか。

時代精神というのはよくわからない。

XWaylandのパフォーマンス

[Phoronix] XWayland 2D Performance Appears Better Than XMir

phoronix.comがXMirとX.Orgをベンチマーク比較をしたのを受けて、XWaylandとX.Orgをベンチマーク比較をして報告した人がいるらしい。詳細な環境や設定やスコアは何も公開されていないが、XWaylandはX.Orgと同等のパフォーマンスであると報告してきたらしい。

ただし、XWaylandではOpenGLを利用したソフトウェアが動作せず、またgtkperfを実行しようとするとWeston(Waylandのコンポジターのリファレンス実装)がsegfaultするとも報告された。

環境や設定の詳細が公開されていないので、何も判断できない単なる一報告でしかないのだが、XWaylandでもOpenGLは動くはずで、動かないというのは、なにか設定が悪いのだろうか。Waylandはまだ設定方法に難ありといったところだろうか。

どうもXWaylandは、ウインドウマネージャーはWaylandネイティブで動かし、Xを利用するレガシーソフトウェアだけ、XWaylandで動かすような運用をするらしいが、XMirは、レガシーなウインドウマネージャーやコンポジターすらその上で動かせるらしい。これにより、lightdmのログインセッションからウインドウマネージャーの切り替えも、今までどおりできるようになるのだろう。

もちろん将来的には、UnityはMirネイティブになるが、それは次のUnity 8の話で、現行のUnity 7はXMir上で動くことになる。Unity 8は予定では14.10の話で、13.10から一年間は、UnityといえどもXMir上で動作する。CompizまでそのままXMir上で動かすとはだいぶ無理矢理感がある。まあ、そこまで互換性があるのなら、しばらくは既存のウインドウマネージャーはXMir上で動かせるという事だろうか。

追記:よく読んだらハードウェアとベンチマークスコアへのリンクはあった。

Xwayland-2d-x11perf Benchmarks - OpenBenchmarking.org