2012-10-31

リーナス曰く「2560x1600がラップトップの標準になってるべきだろボケ」

Linus Torvalds - Google+ - So with even a $399 tablet doing 2560x1600 pixel displays,…

リーナス・トーバルズがGoogle+で、ラップトップの解像度だけが全然向上していない現状に吠えてる。

399ドルのタブレットですら2560x1600ピクセルのディスプレイなんだぜ。ラップトップの解像度の標準もそれぐらいにしてくれよマジで頼むし。もちろん11インチでもだ。頼むし、"retina"とかいうクソな名前で呼ぶのはやめれ。単に、「まともな解像度」と呼べ。ラップトップがここ10年ほど、あんまり進化してないのは残念すぎるだろ。

俺は弁当箱みたいなラップトップは欲しくないが、1366x768とかいうのは旧世紀の遺物だろ。マジで、じきに携帯電話すらラップトップのクソな解像度を笑うようになるぜ。

もし自称技術ジャーナリストとやらが、これ以上、フォントが小さくなるとか抜かしやがったら、もれなく核爆カンチョーしてやるぜ。高品質のフォントにはピクセルが必要であり、俺はフォントサイズを小さくしたいんだ。「高解像度」というのは「小さいフォント」を意味しないんだ、技術音痴の自称識者めらが。

目が悪かったら、シャープで高品質なフォントの方がいいんだぜ。#言い訳無用

高解像度にするとフォントが小さくなると、一部の自称識者がいうのは、PPIが環境ごとに異なることを考えていないダメなソフトウェアが、フォントサイズを実ピクセル数で指定しているからである。完全にソフトウェア実装の問題であり、高解像度ディスプレイの問題ではない。

いわゆるデスクトップとラップトップ向けのディスプレイパネルのPPIは、一向に向上していない。思うに、11インチで2560x1600のデスクトップ向けディスプレイとかは売れないと考えているのだろう。私は売れると思うのだが。

しかし、デスクトップ向けには、さすがにもう少し大きいパネルが欲しい。しかし、解像度はもう限界に近い。パネルの問題もあるが、帯域の問題もある。DVIやDisplay Portといったケーブルの帯域が、もう限界に近いのだ。だから、これ以上解像度を上げたければ、真剣にGPUからディスプレイに送る信号の圧縮を考えなければならない。少なくとも、PPIが十分に高ければ、RGBで送る必要はない。YUV 4:2:2などでも十分だ。PPIさえ高ければ、違いは人間の目ではまずわからないが、帯域の節約になる。

Christ! Linus guy use the word like "atomic wedgie". It's the pain in my ass to translate it to the Japanese, you know that? So I decided to take my liberty to use whatever word I think close enough.

流行の絵柄と没個性

日本のマンガやアニメの絵柄には、強い流行があるように思われる。以下を見てふと思った。

「アルプスの少女ハイジ」最近の挿絵かわいすぎワロタwwwラノベかよwwww : はちま起稿

昔も今も、皆申し合わせたようにその時流行している似たような絵柄を使う。なぜなのだろうか。

絵心はまったくないが、なぜ絵柄は流行に左右されるのだろうか。絵なのだから、もっと個人の画力とか個性が強く出るべきではないかと思うのだが、なぜか皆、個性のない絵になる。無難であることは確かだが、どれも同じでつまらない。

どちらの絵柄が優れているかとか、どちらの絵柄がより画力を必要とするかという問題ではない。どちらもいい絵であることには違いない。しkし、なぜ絵かきは皆、画一的な個性のない流行の絵柄を使うのだろうか。

Pixivを眺めていると、とてもいい絵が見つかる。Pixivには、画力が優れているわけではないが、非常に個性的ですばらしい絵を画く人々がいる。しかし、どうしたわけか、数年すると、そういう個性的なすばらしい絵を画いていた人は、次第に最近の流行の絵柄に影響された、没個性的な絵を画くようになってしまう。

これはとても残念である。明らかな画力の向上は認められるものの、個性が失われてしまうのだ。そして、不思議なことに、個性が失われれば失われるほど、閲覧数や評価数やブックマーク数は増えている。私にとっては、その個性を見るのが楽しいのに。未だ無名の最近絵を書き始めたばかり人間によって描かれた、まだ流行に影響されていない、個性が残っている絵はすばらしい。

有名な商業マンガとなると、どうしてもリスクを避けるためか、無難な流行の絵柄を使い、無難な筋書きになってしまう。私が今、有名な漫画雑誌を楽しめなくなったのは、そういうところにもあるのだろう。

しかし、こう書いてみると、資朝卿が盆栽を捨てた例が思い出されて仕方がない。

2012-10-28

インターネットアーカイブにより消失を免れた貴重な情報が10ペタバイトに達した

10,000,000,000,000,000 bytes archived! | Internet Archive Blogs

インターネット上のデータを保存する崇高な目標を掲げて活動中のインターネットアーカイブの情報量が、ついに10ペタバイトに達した。多くはすでに消失してしまっただろう。インターネットアーカイブのおかげで、かろうじて消失すべきところを救われたのだ。

非同期入出力の残念な現状

asynchronous disk I/O | libtorrent blog
Libtorrent experience - the poor state of async disk IO | Hacker News

libtorrentの作者が、ディスクI/Oをパフォーマンスを向上させるために非同期I/Oを試した結果、どの環境でも残念なので、ブロックI/Oをスレッドプールで行う擬似非同期I/Oで実装したとブログを書いている。その問題について、Hacker Newsでも議論されている。

非同期I/Oは、話を聞くとたのもしい機能に思える。読み書きが完了するまでブロックせずに、完了したらOSが通知するという仕組みだ。

問題は、その実装がどの環境でも貧弱だという事だ。

環境というのは、主にOS側のことだ。多くのモダンなOSは非同期I/Oを提供している。特に著名なのがみっつある。

  • Linux AIO(Linuxカーネルが提供している)
  • Posix AIO(Posix互換のほとんどのOSが提供している。Linux、Max OS X、BSDなど)
  • MS WindowsのIO完了ポート(MS Windowsが提供している)

移植性を高めるには、この三種類のAPIによる実装をそれぞれ用意しなければならない。

ところが、Posix AIOは、標準で定める機能があまりに貧弱であり、近代的な用途には使えない。そのため、環境依存の拡張機能を使わなければならない。さらに実装が膨れ上がる。

Linux AIOを使うには、ファイルをO_DIRECTでオープンしなければならない。また、読み書きやバッファやサイズなどは、512バイトに正しくアライメントされていなければならない。これを正しく行うのは、恐ろしい手間がかかる。

Posix AIOでは、完了通知の方法が、実質シグナルしかない。シグナルはプロセスのどれかのスレッドに送られるのであり、非常に使いづらい。それに、ライブラリとしてシグナルを使うのは難しい。というのも、ユーザー側でも独自のシグナルハンドラを使っているかもしれないからだ。

シグナルではない方法で、どれかのスレッドに通知される機能もあるが、どのスレッドが通知を受け取るか指定できないので、非常に使いづらい。ライブラリとは関係ないプログラム中のスレッドも通知を受け取ってしまう。

Mac OS Xなどは、スレッド通知を実装していない。そのため、そのような環境ではシグナルを使うしかない。

いくつかの実装では、完了通知のユーザー定義の情報を含めることができる。これにより、どの入出力が完了したのか総当たりで確かめる必要がない。Mac OS Xは、この機能を提供していない。そのため、Mac OS Xでは、完了通知は、すでに発行した入出力のどれかが終わったということを告げるに過ぎず、自分で総当たりして、完了した入出力がどれであるか確かめなければならない。これはパフォーマンス上、非効率的だ。

aio_suspendにより、完了したかどうか確認することもできる。これはselectと同じであり、selectと同じパフォーマンス上の問題がある。

Linux AIOは、Posix AIOよりいくらか改良されているものの、やはり問題はある。

WindowsのIO完了ポートが、APIのインターフェースとしては一番優れているように思える。ところが、本当の問題は、実装が貧弱だという事だ。

LinuxもMac OS XもWindowsも、実装が貧弱である。API上からはブロックしない非同期処理のはずだが、実際に使ってみると、なぜかブロックするような自体が頻発する。

そして、どの非同期入出力APIを使っても、非同期化できるのは読み書きだけである。open(), close(), stat(), rename()などの操作は、非同期ではない。

そういうわけで、ブロック入出力をスレッドプールで使い、擬似的な非同期処理を行ったほうがマシということになる。ブロック操作なので実装が理解しやすい。移植性が高い。すべての操作を非同期にみせかけることができる。

libtorrentライブラリも、ネイティブな非同期入出力を使うのは諦めて、スレッドプールの実装にしたそうだ。

Hacker Newsなどでも議論されているが、非同期入出力の実装の質がどの環境でも等しく悪いという問題は深刻である。スレッドプールはスレッドスケジューラーやスレッド切り替えのコストがかかるものの、現在主流のストレージは十分に遅いため、無視できる。大規模データベースなどのソフトウェアは、実装の質が悪く移植性の低いネイティブな非同期入出力より、スレッドプールを使っている。

非同期入出力が使われないという事は、実装を改良する需要もないという事だ。実装が改良されないので、ますます使われないという悪循環に陥っている。

2012-10-26

ext4の変更を辞めて新しくext5を作ったらどうかという意見に対するTheodore Ts'oの回答

EXT4 Data Corruption Bug Hits Stable Linux Kernels - Page 5

つい先日、ext4をぶっ壊すバグが発見されたことを報じたPhoronixの記事に対するフォーラムで、「もうこれ以上ext4を変更するのを辞めて、新しくext5を作ってはどうか」という意見があり、それに対してTheodore Ts'oが回答している。

それは検討したことがある。現在、新機能は実験的機能フラグやマウントオプションで追加されている。そういうデフォルトで有効になっていない実験的な新機能を使う利用者は問題に出くわしやすい。デフォルトで有効になっていない新機能を試したがる利用者を止めることなどできやしない。本番サーバーでext4のかわりにext5を使うことを止めることができないのと同じだ。メタデータチェックサムのようなものがデフォルトで有効になっていないのは、まだ使うべきではないからだ。新機能を試す勇者は貴重であり、テストのためにはありがたいことだ。開発者の環境やregressionテストで見つけられないバグを振るい出すのには、其れしか方法がないのだから。何にせよ、選択するのは利用者だ。実験的な機能を有効にするのは利用者の責任だ。

コードベースをforkして新しい"ext5"を作り出すのにはコストがかかる。すでに、問題は起きている。ext4では修正されたバグが、ext3では修正されていないということだ。今日も、僕はext3では修正されていたマイナーなバグが、ext2では修正されていなかったのを発見した。というわけで、時々、バグがextNでは修正されているが、extN+1に移植するのを忘れてしまうということが起こる。"ext5"とやらを持ち込むと、問題がますます悪くなるだけだ。というのも、バグ修正の移植を忘れる可能性が3倍になるわけだから。

バグ修正といえば、変更を完全にやめるなんてことはできない。なぜなら、バグは常に見つかるからだ。だいたい、ext4を利用するというのは、何百万台ものGoogleのデータセンターのコンピューターで利用するという事で、大量に利用しないと見つからないようなバグもあるのだ。バグを見つけて修正したあとで調べると、全く同じバグがext3にも見つかる。かれこれ10年もエンタープライズlinux環境の、IBMやRed Hatといった大企業で、テストされてきたのにもかかわらずだ。実際、何度か引っかかっているはずだが、とても珍しい事象であり、テスターはおそらく、ハードウェアの故障か宇宙線が原因だと考えたはずだ。実際、大量のコンピューターから得られた、ほとんどがハードウェア障害である大量の失敗報告を観察して、パターンを見つけたからこそ、発見できたバグなのだ。

問題は、時に、バグ修正は新たなバグをもたらすことがある。今回のケースのこのバグは、バグ修正がstableカーネルにbackportされたから、問題が頻繁に起きて、発見できたのだ。冗談ではなく、本当に「すべての変更を止める」と言うのは、一切のバグ修正を行わないという事だ。古いバージョンのLinuxに留まりたいなら、好きにすればいい。RHEL 5やRHEL 4や、時にはRHAS 2.1が選ばれるのは、そのためだ。

2012-10-25

Raspverry PiのGPUドライバーはクソだった

[Phoronix] Raspberry Pi GPU Driver Turns Out To Be Crap

先ほど、Raspberry Piのユーザースペースのグラフィックスタックのソースコードが公開されるという期待できるニュースを伝えたのにもかかわらず、短時間のうちに、残念ながら完全なクソであったことが判明した。

Raspberry Piのグラフィックスタックが自由なソフトウェアになるというニュースは、賞賛を持って受け止められたが、実際にフタを開けてみると、何の意味もない公開であったことが判明したのだ。

今回、Raspberry Piが誇らしげにプレスリリースまで出しているが、全く無意味な誇大広告であったのだ。

Open Source ARM userland | Raspberry Pi

今回Broadcomが公開したのは、GPUドライバーのうちのユーザースペースの部分である。つまり、ユーザーランドのプログラムにOpenGL ESなどをインターフェースを提供するライブラリだ。Raspberry PiのカーネルGPUドライバーが、Linuxのmainlineに受け入れられない理由は、ユーザースペースのソフトウェアが不自由だったからだ。たとえカーネル自体は自由であったとしても、利用に際してユーザースペースの不自由なソフトウェアに依存しなければならないにであれば、意味がない。今回のユーザースペース側のドライバーの公開により、mainlineに取り入れられる可能性も出てくるわけで、当然皆、ぬか喜びをした。

問題は、その公開したユーザースペースのコードは、何の意味もないものだったということだ。本当の実装は、巨大なバイナリ・ブロブであるファームウェア内で行われていて、公開されたユーザースペースのコードというのは、単に薄いラッパーにすぎないのだ。

つまり、実装を改良することもできないし、バグを修正することもできないのだ。なぜなら、本当の実装は、未だにブラックボックスのファームウェア内で行われているからだ。

この事実の判明により、名だたるLinux開発者達は皆落胆した。Linuxのmainlineに取り入れるなんてとんでもない。

2012-10-24

Linuxのstableカーネルにext4をぶっ壊すバグが発見される

[Phoronix] EXT4 Data Corruption Bug Hits Stable Linux Kernels

このバグは、3.6.2でもたらされ、以前の安定版カーネルにもback-portされているので、3.4の最新の安定版カーネルにまで影響が及ぶらしい。

Theodore Ts'oによれば、この問題は、カーネルを短期間で二度正常にリブートすることで起こるのだそうだ。そのため、一般の普通のディストロを使っている利用者は、まずこのバグに出くわすことはない。しかし、サスペンドやハイバネートのかわりにリブートを使うラップトップ利用者や、カーネル開発者には、容易に問題が起こりうるのだとか。

なんだかだいぶ反響があるので追記。Theodore Ts'oのメールより

LKML: Theodore Ts'o: Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)

多分問題が分かった。問題のコミットは、おそらく、 14b4ed22a6 (upstream commit eeecef0af5e):

jbd2: don't write superblock when if its empty

初出はv3.6.2。

このバグを含むコミットによって、問題が極めてまれに起こる原因は、ジャーナルの開始ブロックがゼロであるとき、ファイルシステムをアンマウントするときにジャーナルのtruncateに失敗するからだ。これは、マウント、アンマウントを極めて素早く行い、ログのwrapがなされないと起こる。一度起きたとしても、問題ではない。ジャーナルを再生できるので、追加のトランザクションを再生すればよい。しかし、二度起きると、古い真当なトランザクションのアップデートされないにもかかわらず、前回のマウント時より新しいトランザクションが、さらに最新のトランザクションにより書き込まれる。この時、追加のトランザクションの再生を行うと、メタデータブロックが、とても変な状態になる。

やれやれ、このパッチを僕がレビューしたときに問題に気がつけなくてごめん。以下のパッチでバグを解決できると思う。他のext4開発者のレビューを受けたならば、ただちに、Linuxにプッシュするよ。

というわけで、正確にはリブートではなく、二度素早くマウント、アンマウントする場合に問題になる。あまりに短時間で頻繁にマウント、アンマウントを繰り返し、しかも最近のstableカーネルを使っている環境のシステム管理者は震え上がるのだろうか。

Raspberry Piのユーザースペースのグラフィックスタックのソースコードが公開される

Raspberry Piに使われているBCM2835のグラフィックスタックのうち、ユーザースペースの部分、つまりOpenGL ESとかEGLとかOpenVGとかOpenMAX ILなどの実装のソースコードが公開された。ライセンスは修正BSDの模様。

これで、ファームウェアより上は、完全に自由なソフトウェアのみで構築することも可能になる。ファームウェアは、まだ不自由なバイナリブロブを読み込まねばならぬ。

また、この公開により、BCM2835用のコードが、Linuxカーネルのmainlineに取り入れられる可能性がでてきた。というのも、たとえカーネルコードとしては自由なソフトウェアであっても、動作にあたって不自由なユーザースペースのソフトウェアを必要とするカーネルのコードは、利用者に不自由なバイナリブロブの使用を強制してしまうということで、Linuxカーネルのmainlineに取り入れることは拒否されているのだ。

持っていると誤解されそうなUSBメモリ

985215 Bali-USB Product Detail

バタフライナイフのような機構がついたUSBメモリ。これで端子を保護できるに違いない。

ただし、材質はプラスチック製とのこと。

2012-10-21

Steamユーザーの93%は1月1日生まれである

Valve: "93% of Steam Users Born on January 1st"

SteamというDRM付きの邪悪なゲーム配信プラットフォームを提供しているValveのGabe Newellによれば、Steamユーザーの93%は、1月1日生まれであるという。

つまり、不自由なソフトウェアとDRMをキニシナイゲーマーには1月1日生まれが極端に多いらしい。いやぁ、すごい偶然もあるものだなぁ。

Doom 3 BFGのソースコードをGPLでリリースする承認がなされた

John Carmackのtweetによれば、Doom 3 BFGのソースコードをGPLで公開する承認が得られたそうだ。まだ実際に公開されたわけではないのだが。

もちろん、ソースコードは不自由なWindows向けであろうから、完全に自由なOS上で動かすには、移植作業を必要とする。また、リソースは自由ではないので、どうにかして合法的に入手しなければならないだろう。

最大の問題は、Doom 3は面白くないという事だ。リメイクをしたって元が面白くないものを面白くすることはできないだろう。私はDoom 3をやっていないので批評する資格はないのかもしれないが、少なくとも、実際のプレイ動画を見た限り、面白そうではない。

実のところを言うと、私はそれほどオールドスクールのFPSゲーマーというわけでもない。DoomもDoom 2もやってはいない。今からやってみたところで、やはり面白くは感じないだろう。というのも、やはり当時遊んでいなかったゲームを今遊んでも面白いとは思わないからだ。

しかし、Doom 3は別の理由で面白くない。その理由は、狭く暗い通路を行く平凡なゲームだからだ。Zero Punctuationで有名なYahtzeeがPainkillerのレビューで語っているように、

Some people refer to Painkiller as the unofficial Doom 3 since the actual Doom 3 tripped over something in the dark banged its head and forgot that it wasn't System Shock

Painkillerは非公式Doom 3だと考える人もいるというのも実際のDoom 3は真っ暗な中で何かにつまづき頭を打ち自分はシステムショックではないということを忘れてしまったからだ

The Escapist : Video Galleries : Zero Punctuation : Painkiller

思うに、Doom 3のすばらしいグラフィックとやらは、単に黒を全ピクセルにアルファブレンドするだけで実現できるのではないか。ただし、懐中電灯を使った時のみ、中央は丸く開ける。

画面が見えなくなるほど真っ暗にして、何がしたいというのか。シャドウボリュームによる影の生成はたしかに綺麗だが、シャドウボリュームに使うためだけの、直接描画には関係ないポリゴンを仕込んでおかなければならず、結果としてポリゴン数の増大を招き、パフォーマンスを維持するためにポリゴン数を落とさねばならず、なぜか見た目には造形がしょぼくなってしまった。

まあ、当時はようやくシェーダーが出てきたばかりで、HDRなどまだ現実的ではなかったわけで、濃淡の濃い光を実現しようとすると、必然的に真っ暗になってしまう。時代が早すぎたともいえる。シャドウボリューム用のポリゴンの問題も、ジオメトリシェーダーがあればあらかじめモデルに仕込んでおく必要がないのではないかとも思うし、今実装したらどうなるのかというのも興味深い。

2012-10-20

Partial Orderingの理解

とりあえずPartial Orderingに関して理解できたこと。

クラステンプレートのpartial orderingは、14.5.5.2に定義されている。その定義によれば、二つのクラステンプレートを比較する際、ある手順に従って、クラステンプレートを関数テンプレートに変換して、関数テンプレートのpartial orderingとして比較する。つまり、関数テンプレートのpartial orderingの定義に丸投げしているわけだ。

関数テンプレートのpartial orderingは、14.5.6.2に定義されている。その定義によれば、二つの関数テンプレートの家、一方にある変換を加えて、変換されたテンプレートと、他方の変換されていないオリジナルのテンプレートを、14.8.3.4にしたがって比較する。これは、二つのテンプレートの両方向に対して行われる。

14.8.2はテンプレート実引数推定であり、その下にある14.8.2.4は、partial orderingの際のテンプレート実引数推定について定義している。

一方の関数テンプレートの関数仮引数の型を他方の対応する関数仮引数の型と比較して、関数テンプレートのすべての型が、少なくとも同じほど特殊化されており、またある型に対しては、より特殊化されている方が、より特殊化されているテンプレートであるとする。これは、オーバーロード解決と同じだ。

しかし、肝心の個々の型同士の比較方法は、14.8.2.5に丸投げされている。

しかし、14.8.2.5は、どちらがより特殊化されているかということは直接定義していないように思う。ただ、推定が失敗するという記述ならある。

比較は両方向に対して行われるので、ある方向で失敗して、他の方向で成功した場合、より特殊化されていると言えるのだろうか。よくわからない。

Partial Orderingがよくわからない

C++のPartial Orderingがいくら文面を読んでもよくわからない。

最終的には、二つのテンプレートを比較する際、一方をある方法に従って変換し、他方は変換しないまま、それぞれの対応する型に対してtemplate argument deductionを行うということを、両方に対して行うように読めるのだが、どうやってより特殊化されているのかを決定するのか、よくわからない。

結局は、14.8.2.5がやたらに複雑なのだ。この形の場合はこう、あの形の場合はこうと、ものすごく場合分けされている。

そして、未だに14.8.2.5の結果が、14.8.2.4にどのようにして、「より特殊化されている」かという判断を与えるのか理解できていない。

理解できないものは説明もできないので、このままでは、C++の参考書には、「Partial Orderingにより、より特殊化されている方が選ばれる」以上の説明が書けない。困った。

2012-10-19

インターネットをセキュアにするな。犯罪は必要だ

Don't secure the internet, it needs crime: Diffie | ZDNet

先日、暗号の専門家が、インターネットを安全にすることに異を唱えた。

かなりミスリードしやすいタイトルだが、正しくは、「物理層を安全にする意味がない」ということだ。正しく設計された暗号を使えば、たとえ通信経路が盗聴されていたとしても秘密は守れるし、通信経路で改変されていたとしても、検出できる。

あとは、その暗号で使う鍵を、いかにして安全に共有するかという問題だけだ。

日本の無能な警察が、インターネットを安全にするために規制が必要だなどと抜かしているようだが、そんなのは無意味だ。

Ubuntu 13.04の機能は秘密裏に開発されることに

Key parts of Ubuntu 13.04 will be developed in secret, to escape the critics’ ire | ExtremeTech
Mark Shuttleworth » Blog Archive » Raring community skunkworks

Ubuntu 13.04の、「high “tada!” value」を提供するある機能が、秘密裏に開発されるそうだ。

Mark Shuttleworthによると、せっかく便利な機能を開発しても、すぐに批判されるからだという。

宇宙飛行士の養蜂家が何と言おうとも、ローカルのファイルやソフトウェアを検索する意図を持って入力した検索クエリーがデフォルトでオンラインに駄々漏れというのはプライバシー上の悪夢でしかない。

「Canonicalが信用できなければ、そもそもUbuntuを使えないはずではないか。その気になれば、CanonicalはUbuntuのソフトウェアアップデート機能を使って悪意ある機能をすり入れることもできるのだから」という反論は馬鹿げている。イタズラにリスクを増やして何になるというのだ。

キーロガーを搭載し、無線通信で製造会社に送信するようなキーボードがあったとする。ここで、キーボード製造会社が「我々、製造会社を信用しなければ、キーボードは使えないではないか。我々はこっそり搭載することもできるのだ」と公言しているとする。そんなキーボードを使いたいだろうか。

あるところを信用するからといって、必要以上に秘密の情報を渡しても、リスクを増やすだけだ。

Canonicalとて企業である。法律に違反することはできない。政府が、「ユーザーの検索クエリーを国家に提供しなければならぬ法」を定めたならば、Canonicalは政府に渡さなければならないだろう。なぜならば、拒否するのは違法だからだ。たとえ拒否した所で、政府は合法的に押収できるのだから。

Ubuntu以外のディストロも調べなくては。

高度な犯罪の例

この脅迫状を送った犯人は、郵便局の消印で住所の範囲の絞り込みを防ぐために、公共交通機関を利用して遠く離れた郵便ポストに脅迫状を投函したものと見られる。また、脅迫状には差出人の住所が書かれていなかった。これは極めて高度な住所隠匿技術である。

この押し売りは、「すみませーん。消防署の方から来たんですが、法律で一家に一台消化器を置かないといけないことになってまして」という物言いで、あたかも自分が消防署の職員かその委託を受けて、各家庭への消化器の設置が法律上の義務であるかのように装い、消化器を売りつけた。これは非常に高度な職業偽装の技術である。

この犯人は、事件を引き起こした後、盗難車を使って高速道路上を逃走した。高速道路の国民監視装置であるNシステムにより、車の所有者が運転しているものと判断された。これは極めて高度な偽装技術である。また、類似の事件として、ナンバープレートを覆い隠して逃走した犯人がいる。このように高度な偽装技術は、裏で手口を研究開発して販売する組織の存在を認めざるを得ない。

参考:本の虫: xkcd : CIA(クラッキングに対する一般人とコンピューター技術者の反応)

なんと犯人は高度なハシゴ技術を有している。

Ubuntu 13.04のコードネームはRaring Ringtail

Mark Shuttleworth » Blog Archive » Not the Runty Raccoon, the Rufflered Rhino or (even) the Randall Ross

Mark Shuttleworthは自身のブログで、Ubuntu 13.04のコードネームが、Raring Ringtailとなることを発表した。

Ringtailは、アライグマ科カコミスル属に属する動物で、英語ではRingtail catと呼ばれているが、猫ではない。

Ring-tailed cat - Wikipedia, the free encyclopedia
カコミスル - Wikipedia

13.04はもちろん来年の四月の話だが、明日あたりにリリースされるUbuntu 12.10には、いろいろ興味深いことも多い。

Ubuntu Linux 12.10 review: Better, but slower | ZDNet

たとえば利用者がローカルファイルとローカルアプリを検索するために入力した検索クエリーをすべてCanonicalに駄々漏れに垂れ流して、Canonicalでも更にアマゾンなどに販売する unity-lens-shoppingがある。これはプライバシー上とても危険であり、無効にするだけではなく、安全のためにアンインストールするべきである。

また、興味深いことに、Ubuntu 12.10では、デフォルトのファイルマネージャーであるNautilusを3.4にとどめている。これは、GNOME 3.6によるNautilus 3.6の変更が不評であるかららしい。

また当初、Ubuntu 12.10で、CanonicalはPython 3.2に移行し、Python 2系列はデフォルトではインストールしない予定だった。Python 3はPython 2に対して破壊的な変更を含んでいる。つまり、Canonicalが直接サポートするソフトウェアでPythonを使うものは、すべてコードをPython 3.2で動作するように移植しなければならない。残念ながら、その移植作業は間に合わず、結局Python 2系列も、引き続きデフォルトでインストールされるようだ。

もうひとつ重大な変更は、Unity 2Dを廃止したことだ。Unity 2Dは、Unityとその母体であるCompizを動作させることができないGPUしか持たないコンピューター向けのフォールバック機能だったのだが、Qt上で実装されており、そのオリジナルの開発者がCanonicalを抜けたことや、同等機能を二つのコードベースで提供する煩わしさを嫌って、廃止されることになった。今後は、LLVMpipeにより、OpenGLをソフトウェアでエミュレートすることにより、Unityを動かす。ここ数年に発売されたx86系CPUならば、とりあえずGUI程度は動かせるパフォーマンスらしい。

グラフィックスタックのソフトウェアエミュレーションは、近年非常に有名になっている。たとえば、ChromiumもWebGLを描画する際、十分なGPUを搭載していないか、あるいは極端に古い問題のあるバージョンのドライバーを使っている場合は、ソフトウェアエミュレーションにフォールバックするようになっている。

DirectXやOpenGLといった汎用グラフィックスタックを使ったコードを書き、対応していない環境ではソフトウェアエミュレーションを用いるのは、直接ハードコードするのに比べて無駄が多いように思われるが、これにより、同等機能を提供する複数のコードを持つ必要がなくなるので、開発の手間が下がるというわけだ。

2012-10-14

Ubuntuのバグ報告:grep -Rが自動的にAmazonを検索しない

UbuntuのUnityレンズにアマゾン検索を追加することが発表されて、先月末に面白い皮肉なやりとりがあったようだ。この手の皮肉なバグ報告は、自由なソフトウェアのバグ報告では、たまに見られる。Ubuntuでは結構多いように思う。

Bug #1055766 “grep -R doesn't automatically search amazon” : Bugs : “gnome-terminal” package : Ubuntu

親愛なる「所有欲の権化」へ。

grepを再帰的に使っても、ローカルの結果しか得られない。

grep -R fish_t /home/noob/fish_game/*

/home/noob/fish_game/fish.h: struct fish_t {
/home/noob/fish_game/fish.c: struct fish_t eric_the_ fish;

これは二つの理由によりバグである。

  1. 出力がつまらない
  2. ターミナルは二行以上ある。画面を効率的に使っていない。

思うに、これはgrepが私の真に発見したい事項について、ローカル上でしか検索を行わないためである。

そして、grepがデフォルトでアマゾンも検索してはどうかと提案している。

さらに、Ubuntuのbashにデフォルトで搭載されている、command-not-foundで似たようなコマンドやレポジトリ上のコマンドを探しだす機能に飛び火して、

command-not-foundはUbuntuソフトウェアセンターと統合するべきではないか、例えば、

you@home:~$ portal2
base: portal2: command not found...
Would you like to buy and install Portal 2 via Steam for $7.49 ? [Y/n]

さらに投稿主からの返答として、

そうだ。それに<TAB><TAB>の結果はこれだけしか返さない。

akeane@awesome-haX0r:~$
Display all 2717 possibilities? (y or n)

以下のように返すべきだ。

akeane@awesome-haX0r:~$
Display all 3,141,596,254 results possibilities? (y or n)
Do you feel lucky? (y)

違うかな?

このバグ報告は、ただちに「無効」とマークされ、以下のようなコメントが付された。

皮肉をやめろ。
我々は真面目にバグを修正しているのだ。

返答では、

>皮肉をやめろ。

なぜ私のバグ報告が「皮肉」なのかね。私は私がUbuntuにおいてバグであると信ずる事項を真面目に報告したのだよ。すなわち、GUIに追加された、多くの者が頼る機能が、CLIツールには首尾一貫して追加されてはいないという事項なのだよ。

貴君は私のバグ報告を「無効」とした。それは貴君の当然の権利であり、私としても尊重するつもりである。

悲しいかな、提案された技術上の問題には目を向けず、貴君の個人的な侮辱を含めるとは。(皮肉呼ばわりされたので、うっかり単眼鏡を取り落としそうになってしまったよ)。

>我々は真面目にバグを修正しているのだ。

私もUbuntuをより良くしようとしているのだよ・・・

私自らgrepをハックしてパッチを投下すれば状況は変わるかね?

と、さらに皮肉な返答をしている。

よほど、おもしろかったのか。このバグ報告は「複数の利用者に影響する」ため、「確認済み」の状態に差し戻された。

その後しばらく面白いやりとりが続いた後、結局は閉じられた。

ストールマン、UbuntuのUnityレンズについて

Richard Stallman: Canonical will be forced to hand over data to various governments - Benjamin Kerensa dot Com

UbuntuのUnityレンズに、アマゾン検索を搭載することについてストールマンに意見を求めたところ、「Canonicalは政府にデータを引き渡さなければならなくなるだろう」という答えが得られた。

これは当然だ。政府はあるデータが存在すると知ったならば、知りたがるからだ。政府は、データを引き渡さないことを違法にできる。そのため、Canonicalがいかに信頼できるとしても、遵法のためには、政府にデータを渡さざるを得ない。

また、ストールマンは以前から、アマゾンはDRMを推進し、労働者の待遇がひどく、書籍の検閲を行い、さらに労働組合の抑制や住居に侵入した者は問答無用で撃ってよい法律などを推進している右翼ロビー団体ALECのメンバーであるので、アマゾンから物を買ってはならないとも主張している。

Amazon

何度も言うが、Unityレンズはローカルのファイルやソフトウェアを検索するために用いられている。ローカルのファイルやソフトウェアのみを検索する意図で入力した検索クエリーを外部に漏らすなど論外である。

Ubuntu 12.10では、以下のコマンドを実行すべきである。

sudo apt-get remove unity-lens-video unity-scope-video-remote unity-lens-shopping unity-lens-music unity-lens-photos unity-lens-radios

あるいは、ディストロを変えたほうが良い。Ubuntuを使うという事は、このようなプライバシー漏洩行為を推奨しているとみなされる。

2012-10-10

初代スーパーマリオブラザーズのコイン取得時の音の楽譜

Mario Piano Sheet Music - Coin Sound

近藤浩治による任天堂エンターテイメントシステム向けのオリジナルの楽曲
Joseph Karamにより、正確な譜面化並びにピアノで演奏する際の運指の最適化。

正確に譜面化したそうだ。うーん、なんだかシュールだ。

IPアドレスという確証がある

明治になって、全国の名主に米を支給して郵便局になってもらい、郵便網を発達させた時、果たして以下のような拷問が発生しただろうか。

「俺はやってない」
「まだそんな白々しいことを言うか。消印という確証がある。この手紙はお前の住所のすぐ近くの郵便局から出されたものだ。つまりお前が出したに決まってるだろう」
「消印は個人を特定しない」
「今認めれば罪が軽くなるぞ。早く釈放できるしな。急ぐ必要はない。なにしろ時間はたっぷりある。いくらでも勾留できるからな」

あるいは、昔は以下のような浄瑠璃があっただろうか。

「斯様に候者は、名も無き弓矢取りに候。こたび、我が家より矢の飛び出して人を射殺すによって、其、厳しく咎めを受け、すでに誅せられ畢。我が家より矢の飛び来たるも、我が射たる証拠ならず、そも、我はその時、家には居らじ、と陳じしかども、弓箭の家に生まれてなんぞ見苦しき、早く自害して、名を汚す事なかれと責め立てられ、かくて長く世に別れ侍りぬ。あな口惜しや」

むろん、こんな拷問は馬鹿げている。しかし、同じことが現代では起きているのだ。人類のむしろ馬鹿になっているのではないか。

「警察・検察聞く耳持たず」PC感染で釈放男性 : 社会 : YOMIURI ONLINE(読売新聞)

遠隔操作型とみられるウイルスに感染した男性2人のパソコンから犯罪予告のメールが送られるなどした事件で、大阪府警に逮捕されたアニメ演出家の北村真咲(まさき )さん(43)(釈放)が、大阪市のホームページ(HP)に送られた犯罪予告メールについて、「文面にある『ヲタロード』という言葉さえ知らないし、市のHPも見たことがない」と周囲に話していることが、関係者への取材でわかった。

北村さんは「警察、検察の取り調べでも伝えたが、全く聞く耳を持ってくれなかった」とも訴えているという。

関係者によると、北村さんは7月中旬、ノートパソコンに買い替え、無料ソフトを数本ダウンロード。問題のメールは同29日に送られた。8月26日の逮捕まで10回前後、府警に任意で事情聴取され、「第三者がメールしたに違いない」「脅迫文の書き込み自体知らない」などと無実を訴えたが、逮捕。府警や大阪地検に「IPアドレスという確証がある」と聞き入れられず、「認めたら罪が軽くなる」と持ちかけられたという。

日本航空の顧客対応窓口に送られたとされる、日航機を爆破するとの内容のメールについても、北村さんは関与を否定している。北村さんは「精神的につらかった。釈放されてホッとしているが、警察から連絡があるたびに怖くなる」と話しているという。

しかし、なぜIPアドレスが個人を特定すると誤解されているのか。所詮、契約者名義までたどれるだけで、それ以降はどうしようもないではないか。ある車が犯罪に使われたとしても、車の登録名義と、実際の運転者が同じであるとは限らない。ハンコや署名があっても、本人が行ったものであるとは限らない。常に盗用の恐れがある。

リチャード・ストールマンは、Googleなどの検索エンジンを使うときは、自分の所有していない、不特定多数の人間に使われている状態にある回線とコンピューターを使う。リチャード・ストールマンがあるWebサイトを閲覧する必要があるときには、彼はURLを自分のサーバーに送る。サーバーは、メールに書かれたURLをwgetしてリチャード・ストールマンに送り返す。

wgetサーバーは手間を省くためだとしても、個人が特定される環境ではWeb上のサービスを使わないというこの姿勢は、というよりも、このような防衛をしなければならない現状は、極端である。

リチャード・ストールマンは、利用者の支配下にないソフトウェアが、ソフトウェアの提供元に不公平な権力の差をもたらすと知っているからだ。

クライアントソフトウェアたるWebブラウザーは自由だとしてもWebサーバーから送られてくるデータを解釈する際に、プログラムの実行に等しい挙動が起こる。であれば、このデータは、すでにプログラムであり、Webサイトの閲覧は、プログラムの実行である。このプログラムは、たとえば、自分の入力していない検索クエリーで検索するかもしれない。利用者の意思に反して動作するのだ。プログラムを実行する前に、その挙動を自分でいちいち検証するのは現実的ではない。これが従来のプログラムならば、多くの互いに係累なき人によって検証されたプログラムを実行することもできるが、他人の管理するWebサーバーという、利用者が所有しておらず、支配力も及ばないブラックボックスから送られてくるプログラムはどうしようもない。

自由なクライアントソフトウェアを使っていてなお、不自由なプログラムの実行は避けられない。もし、クライアントソフトウェアに悪意があり、自分の知らぬままに実行されていたならばどうか。

なぜかよくわからないがBloggerがおかしい

なぜか、書き上げたある記事が投稿できない。不思議だ。

追記。HTMLタグの>をひとつ書き忘れていたからだった。それならそうと警告してくれればいいのに。

2012-10-09

疲れた

長岡京で免許更新をした帰り、金もないし、運動不足だし、せっかくだからJR駅まで歩くかと、適当に西に向かって歩き始めた。程なくしてブックオフの看板に誘われて、後先を考えずにふらふらと看板の方向へ向かって前進し入店、特に興味深い本もなかったので失望して店を出たが、、そこでふと気がついた。ここはどこだ。

東に一本線路が見え、西にも線路がある様子。どちらかがJR線で、どちらかが阪急のはずだ。阪急でも京都市には帰れるが、阪急線は自宅とは少し離れている。できればJR線に乗りたいものだ。それに、南北のどちらに行けばいいのだろう。線路に沿って行けば、いずれは駅があるはずだが、できれば駅の近い方向に行きたいものだ。

運を天に任せ、西側の線路に沿って、南に向かった。すると、阪急の長岡天神駅に着いた。残念。

仕方なくそのまま東に向かい、JR線に乗って帰宅。とても長い距離を歩いたように思うのだが、今更べてみると、たったの4kmしか歩いていない計算になる。はて。

2012-10-08

Red Dwarf Xが始まっていた

油断しているうちに、BBCで放送されていた伝説的なsitcomであるRed DwarfのシリーズXの放送が始まっていたようだ。全6話で、すでに各話のあらすじは公開されているようだ。

Red Dwarf (series X) - Wikipedia, the free encyclopedia

主要な4キャラである、Dave Lister、Arnold Judas Rimmer、The Cat、Krytenは、当時のキャストがそのまま演ずる。男ホーリーのNorman Lovettは、Back To Earthの制作時点でギャラで揉めたらしく登場しない。思うに、Krytenがホーリーの役割をどんどん奪っていったことだし、ホーリーを登場させても存在が薄いと思う。

そもそも、Red Dwarf本編は1999年放送のシリーズVIIIを最後に終わっていたはずだが、なぜ9をすっ飛ばして10なのか。というのも、この間に、Red Dwarf: Back to Earthという、三回に分けて放送された作品があり、これをもってシリーズ9に当てるという事らしい。また、Red Dwarfの内容がどんどん変な方向に行ってしまったこともあり、ストーリー上、そのまま続行するのが難しいので、わざと一つ欠番にして、「おっと、途中を飛ばして観始めたようだね」という効果も狙っているらしいということも、考察されているようだ。

何にせよ、これまでのストーリーを踏襲するとなると、シリーズVIIでNanobotが、分解したRed Dwarfを、乗員まで含めて再構成してしまったため、宇宙にただ一人生き残っているのはDave Listerだけではなくなってしまったし、Arnold Rimmerもホログラムではなくなってしまう。

シリーズXでは、原点回帰らしき工夫が見られる。というのも、Red Dwarfはシリーズを重ねるごとに、どんどん当初のコメディから離れてしまったからだ。とくに、最後のシリーズVIIIはひどいもので、やたらに特殊効果だけが強調された作品に成り下がってしまっている。

ただ、どうしても役者の年齢が50代なので、色々と苦しい部分もある。それでなくてもカチャンスキーの役者は一度交代しているのだが、やはり魅力的な若い女性という役割を演じるには、どうしても年齢上の問題がある。Back To Earthでも、最後の数分、厚化粧した状態で無理やり登場させただけだった。

ただし、熱狂的なファンなら誰でも思うだろうが、カチャンスキーを主要キャラとして出してしまうと、作品が面白くなくなってしまう。シリーズVIIの中盤からはひどいものだった。なにしろ、カチャンスキーは若く魅力的な女性というだけでなく、階級的にも相当に上のNavigation Officerなのだ。秀才なキャラであり、一部の機械よりも下の階級、Skutterよりは上という落ちこぼれキャラの中で、浮いた存在になってしまうからだ。

今回のシリーズXを見ると、老けて落ち着いた顔になっているChris BarrieがpratなRimmerを演ずるのは、やはり少し違和感がある。

2012-10-07

昨日IRCで聞いたスウェーデンの変な法律の話

昨日、IRCで各国のおかしな法律の話に及び、あるスウェーデン人から、スウェーデンにおける変な法律の面白い逸話を聞いた。

スウェーデンで未だに有効な古い法律を調べていた学生が、ある面白い法律を発見した。学生に試験を課した大学は、学生に対し、無料で一食の食事を提供しなければならないという法律である。

さて、大学で試験のあった日、同学生は自己の権利である無料の食事を大学に対して要求した。大学はその要求を認め、実際に同学生に無料の食事を提供した。

しかし、後に法律違反が判明し、同学生は食事代を請求された。というのも、その古い法律によれば、無料の食事を要求するにあたって、学生は剣を帯する義務があったのだが、同学生は剣を帯していなかったのだ。

残念ながら、今ではこの問題は修正され、件の古い法律は無効になってしまったのだとか。

2012-10-06

DNTが特許紛争に巻き込まれる。アメリカよ、お前の特許システムはクソだ

Do Not Track gets support in iOS 6, but patent woes loom | ZDNet

United States Patent: 8156206

IEがデフォルトでDNTヘッダーを有効にする選択を行ったことは記憶に新しいが、DNTヘッダーというおよそ特許性のかけらもないような規格が、特許紛争に巻き込まれている。 U.S. Patent number 8,156,206が該当する特許で、その内容は、まさにDNTと同じものであると解釈できる。

「トラックすんなよ」という意思表示を、20年前から存在するHTTPプロトコルのヘッダーに記述するのに新規の特許性が認められるとは、アメリカの特許システムはどこまで腐りきっているのか。

2012-09 pre-Portland mailingのあまり簡易ではないレビュー

2012-09 pre-Portland mailingが公開された。久しぶりなのですっかり忘れていた。今回はやたらと多い。もちろん、もはや正式規格発行後なので、差し迫った変更はない。細部の疑わしい文面の変更とか、大雑把な提案とか、将来C++への追加の可能性のある機能が、現状ではどのように独自な拡張やライブラリで実装されているのかなどの紹介といったところだ。今回は、紹介も非常に多く、規格への提案というよりも、C++11でライブラリはどのようになるかといった紹介が多いように思う。

とにかく今回は数が多い。疲れた。非常に疲れた。無償でやるのも不毛だ。

C++11は、2000年中に制定されることが期待されていたので、だいぶ最近までC++0xと呼ばれていた。C++0xという呼称を最初に使ったのは他ならぬBjarne Stroustrupだが、次の規格の呼称もすでに生まれている。C++1yという。現在のところ、2017年の制定を目標にしているが、まあおそらく、あと5年では無理ではないかと思う。

N3386: Return type deduction for normal functions

通常の関数で、戻り値の型の指定を省略して、推定させるもの。すでに、lambda expressionではこれが可能である。C++11でも、せっかくlambda expressionはそうなっているのだし、新しい関数の宣言文法も導入したのだから、通常の関数でも認めればどうかという話は当然出るわけで、実際に議論されたのだが、時間がないので、将来の規格改訂に先送りすることにしたのだ。

このたび、GCC開発者のJason MerrillがGCC上で実験的な実装を行い、C++1yに追加するだけの十分な実装経験が得られたとして、その経過や所感を報告している。

まず問題になるのは、前方宣言だ。戻り値の型を省略した前方宣言は認められるべきだろうか。

auto f() ;

// 戻り値の型はint
auto f() { return 42 ; }

これはC言語の汚らしい仕様である、暗黙のintを思い起こさせるが、一方、クラスのメンバー関数の定義を外部に書きたい場合、これが許されてくれないと困る。

struct X
{
    auto f() ;
} ;

auto X::f() { return 42 ; }

これは当然書きたい。もしこれを言語として許すのであれば、他の場所でも当然、戻り値の型を省略した前方宣言が許されるべきである。しかしAlisdairが言うように、問題は、これをSFINAEに持ち込むと、普通のユーザーにとっては、非常に奇妙な結果になるという事だ。

auto f(int) ;
template <class T, int = sizeof(f(T()))> void g();
void h1() { g<int>(); } // no match, g() disqualified by SFINAE
auto f(int i) { return i; }
void h2() { g<int>(); } // OK

しかし、Merrillによれば、すでにincomplete class typeを使えば同じ状況にはなるわけで、いまさらどうということはないとのことだ。

Jason Merrillの今回の提案では、戻り値の型を省略した関数の宣言を許そうではないか。ただし、すべての宣言が全く同じ型であればだ。

auto f(); // return type is unknown
auto f() { return 42; } // return type is int
auto f(); // redeclaration
int  f(); // error, declares a different function

もちろん、定義が現れる前にそのような関数をexpressionの中で使った場合、ill-formedである。

auto f() ;
int i = f() ; // エラー
auto f() { return 1337 ; }
int j = f() ; // OK

明示的特殊化の場合、autoテンプレートにはautoを使わなければならないと提案している。

template <class T> auto f(T t) { return t; } // #1
template auto f(int); // OK
template char f(char); // error, no matching template
template<> auto f(double); // OK, forward declaration with unknown return type

template <class T> T f(T t) { return t; } // OK, not functionally equivalent to #1
template char f(char); // OK, now there is a matching template
template auto f(float); // OK, matches #1

また、同じ型であると推定される複数のreturn文の記述を許そうという提案もしている。

auto negate( bool b )
{
    if ( b )
        return false ;
    else
        return true ;
}

関数内のすべてのreturn文の型が同じかどうかを判別することは可能なので、これを禁止する理由はない。

ただし、再帰は話が違ってくる。単純に再帰する関数の戻り値の型は決定できないので、当然ill-formedになる。

// エラー
auto f() { return f() ; } ;
ただし、もし他のreturn文から戻り値の型が推測できれば、それによって再帰が書ける。そのようなコードは許そうではないかと提案している。
auto sum(int i) {
  if (i == 1)
    return i;          // 戻り値の型はint
  else
    return sum(i-1)+i; // OK
}

autoに対する宣言子も働く。

auto & f()
{
    static int x ;
    return x ;
} 

N3387: Overload resolution tiebreakers for integer types

standard conversionはsignedからunsignedへの極めて強い暗黙の変換を行うので、これがオーバーロード解決の際に問題になる。

たとえば、多長精度の正の整数を表現するクラス、BigUnsignedIntを実装したいとする。手軽に使うために、コンストラクターで整数リテラルを受け取るが、負数を渡してほしくはない。しかし、単にunsignedな整数型を使った場合、standard conversionにより負数がunsigned型に変換されてしまう。

struct BigUnsignedInt
{
    BigUnsginedInt( unsigned long long ) ;
} ;

int main()
{
    BigUnsignedInt b = -1 ;
}

では、signed型のコンストラクターも追加して、オーバーロード解決で振り分けようとしても、曖昧になる。

struct BigUnsignedInt
{
    BigUnsignedInt( unsigned long long ) ;
    BigUnsignedInt( long long ) = delete ;
} ;

int main()
{
    BigUnsignedInt b = 5 ; // エラー、曖昧
}

この問題は、standard conversionのためである。この問題を解決するには、すべての整数型をオーバーロードして振り分けるしかない。

残念ながら、この問題を完全に解決するには、既存のコードをほとんど壊してしまうので無理だ。そこで、オーバーロード解決を少し変更することで、この問題だけは修正しようという提案。

N3388: Using Asio with C++11

Asioの紹介、並びにC++11で実装したらどうなるかという実験的実装。AsioのようなライブラリをC++の標準ライブラリに採用するには、相当な困難が待ち受けているであろうが。

ソースコードはgithubで公開されている。

chriskohlhoff/asio at cpp11-only · GitHub

N3389: Urdl: a simple library for accessing web content

AsioとOpenSSLの上に構築された、URLを使って参照されたWeb上のデータをダウンロードするためのライブラリの紹介。標準ライブラリへの提案というのではなく、Asioを使った上位層のソフトウェアの実装紹介の意味合いが大きい。

ソースコードはSourceforgeで公開されている。

Urdl C++ Library | Free software downloads at SourceForge.net

N3390: Any Library Proposal

そうか。ついに来たか。

xkcd: So It Has Come To This

女「キャットフードを切らしてしまったわ」
男「そうか。ついに来たか」

笑いどころ解説:何と言うべきか思いつかない場合は、「そうか。ついに来たか」と言っておけばいい。このセリフは一瞬にして緊張感をもたらし、どのようなシチュエーションでも使うことができる。

標準ライブラリにAnyライブラリを提案。

AnyはBoostのライブラリのひとつで、Type Erasureという技法により、どんな型でも格納できるクラスである。その強烈な見た目に反して、実装はとても簡単である。仮想関数を持つ非テンプレートなクラスから派生するクラステンプレートを内部的に使用することで実装できる。

実のところ、Anyというのはとても単純で基本的なライブラリであり、std::functionやstd::bindなどは、Anyの技法の特殊な実装とでも言うべきものである。

N3391: ISO C++ SG1 Meeting Minutes for May 2012
N3392: Minutes, WG21/SG4 Meeting 8 May 2012 Redmond, Washington, USA

5月に行われた会議の様子の報告。C++11にはもっと多くの標準ライブラリが必要なので、ライブラリに関する話になっている。

N3394: [[deprecated]] attribute

属性にdeprecatedキーワードを付け加える。これにより、古くて使用を推奨しないエンティティをマークして、ユーザーが利用した時に警告を発することができるようになる。

すでに、同等の機能は、gccとclangとMSVCとEmbarcaderoで実装されている。文法の違いはあるが、挙動はどれもほぼ同じとなっている。すなわち、

  1. deprecatedされたエンティティが使用された場合、コンパイラーはdiagnostic messageを出す
  2. deprecationにはメッセージを付加することができ、その場合、コンパイラーは付加されたメッセージをdiagnostic messageに含める
  3. このdiagnositic messageのデフォルトの挙動は、「警告」である。

この機能は問題なく規格に取り入れられるだろうと思う。

N3395: C++ Stream Mutexes

現時点で、ストリームは競合を起こさないことが保証されている。しかし、その結果については保証しないので、結果を保証させたい場合、自前で排他的制御を設けなければならない。そこで、ストリームにロック機能を付加した、stream_mutexを提案する。

N3396: Dynamic memory allocation for over-aligned data

現在、規格では、動的に確保するストレージのアライメントが正しい保証はない。それに、ユーザー定義のアロケーション関数の場合、アライメントを知るすべがない。これをどうするのか。

この提案では、様々な議論を挙げた結果、アライメント数を受け取るアロケーション関数とデアロケーション関数を新たに追加することにしている。どうなることやら。

N3398: String Interoperation

文字列などの変換を行うライブラリ。

この提案は、char8_tをunsigned charのtypedef名としている。signed char, unsigned char, charは区別されるので、通常のcharとは区別できるから問題ないとしている。そんな奇妙な解決方法は嫌だ。char8_tは本物の型であるべきだし、そもそもUTF-8文字リテラルとUTF-8文字列リテラルは、char8_t型であるべきだったのだ。

char8_tをunsigned charのtypedef名とする、この提案はクソだ。それならない方がましだ。

N3399: Filesystem Proposal

Filesystemライブラリの提案の改訂3版。

N3400: A proposal for eliminating the underscore madness that library writers have to suffer

そうか。ついに来たか。しかし計画とはだいぶ異なるな。

ユーザー定義されたマクロ展開による意図せぬ意味の変更を防ぐため、C++11実装のライブラリは、ダブルアンダースコアーを多用している。

template< typename __Iter >
void sort( __Iter __first, __Iter __last) ;

このコードは、ユーザーがIterとかfirstとかlastなどというマクロを定義しているかもしれないことを考慮して、すべての名前をダブルアンダースコアから始めている。規格上、ダブルアンダースコアから始まる名前は実装に予約されているので、安全に使えるためだ。

このコードは汚いし、何よりユーザーのライブラリには、同等の機能が提供されていない。

過去に、横暴なマクロ展開を何とかしようという試みは何度も行われてきたが、ことごとく失敗した。理由は、解決策がどれも机上の空論で、現実にはまったく使えなかったからだ。

過去に最も議論されたものとしては、プロプロセッサーにスコープを設けるという方法があった。しかし、既存のコードでマクロは多用されており、一律にマクロを無効化してしまうプリプロセッサーのスコープは、現実的には無価値だった。

今回の提案は、プリプロセッサーに優先度を設けるというものである。この優先度は、実装が定めるもので、規格では定めない。優先度の高いソースコードに対して、優先度の低いソースコードのプリプロセッサーのマクロは展開されない。これにより、C++の実装やシステムの実装は、ユーザーが定義したマクロの展開を恐れる必要はなくなるし、サードパーティライブラリも、ユーザーが定義したマクロの展開を恐れる必要はなくなる。

これは机上の空論ではなく、筆者のJonathanが考案し、実装もした結果であるとのこと。

いつかプリプロセッサーがなくなるその日まで。

ワシはプリプロセッサーなど大嫌いだし、今でも嫌いだ。スコープや型やインターフェースからなるプログラミング言語において、文字とファイルからなるプリプロセッサーは根本的におかしい。

Cプリプロセッサーが打ち棄てられるのをこの目で見たい。

Bjarne Stroustrup、D&E、Cプリプロセッサーについて

N3401: Generating move operations (elaborating on Core 1402)

move constructorがいつdeleted定義されるのかという条件について、色々と問題が多い。変更しても結局問題が多い。

N3402: User-defined Literals for Standard Library Types

STLのstd::basic_stringとかstd::complexやstd::chrono::durationなどにユーザー定義リテラルを提供しようという提案。さらに、二進数のユーザー定義リテラルも提案している。

コンパイル時定数にするために、実装がテンプレートメタプログラミングを多用したコードになってしまう。また、2進数リテラルは、ライブラリではなくコア言語で定義すべきだと思うのだが。8進数10進数16進数はプレフィクスの違いで表現するのに、2進数はライブラリベースの実装でポストフィクスというのは混乱を招くだけだと思うのだが。

コンパイル時atoiの存在は嬉しいにしても、やはり整数リテラルはコア言語で定義したほうがいいと思うのだが。

N3403: Use Cases for Compile-Time Reflection

そうか。ついに来たか。

C++にリフレクションを追加するための議論の題材として、リフレクションはどのように使われるのか。その利用例にはどのような機能が必要かということを、いくつかの例を挙げて紹介している。これが全てではないが、まあ、議論をはじめる材料としてはいい。

もちろん、C++でリフレクションといえば、コンパイル時の静的リフレクションである。

利用例として挙げているのは以下の通り。

  • Serialization
  • Parallel hierarchies
  • Delegates
  • Getter/Setter generation
  • Generating user interfaces to call functions and constructors

必要な機能としては、

  • クラスのメンバーと基本クラスを、privateなものも含めて列挙できる機能
  • クラスのメンバーを作り出す機能と、それに伴うコンパイル時文字列
  • 関数の仮引数を列挙する機能と、仮引数を参照する機能

その他、最後の"Generating user interfaces to call functions and constructors"に関して、ソースコードのコメントが列挙できればDoxygen風の利用ができるので、便利ではないかとも記述している。

ともかく夢のある機能だ。

N3404: Tuple Tidbits

tupleに型で要素にアクセスする機能と、関数オブジェクトと実引数のペアのtupleを用意すれば呼び出せる機能の提案。

N3405: Template Tidbits

テンプレートにちょっとした改良を加える提案。ただし、相当に便利な機能である。

非型テンプレート仮引数は、型を指定しなければならない。

struct X
{
    void f() { }
} ;

struct Y
{
    void f() { }
} ;

template < void (X::* member )() >
struct traits { } ;


int main()
{
    using x = traits< &X::f > ; // OK
    using y = traits< &Y::f > ; // エラー
}

どんな型の非型テンプレート実引数でも受け取るテンプレートは、以下のように書ける。

tempalte < typename T, T t >
struct traits { } ;

ただし、使うのは面倒だ。

using x = traits< decltype(&X::f), &X::f > ;
using y = traits< decltype(&Y::f), &Y::f > ;

この最初のテンプレート仮引数は、コンパイラーが推定できるべきである。そのために、そのような文法を追加する。提案では、以下のように書けばいい。

template < typename T t >
struct traits { } ;


int main()
{
    using x = traits< &X::f > ;
    using y = traits< &Y::f > ;
}

これで、任意の型の非型テンプレート実引数を取れるようになる。Tは非型テンプレート実引数の型が、tは非型テンプレート実引数を受け取る。

提案では、この機能は非型テンプレート実引数の情報を表示するtraitsが動機であるというが、そのサンプルコードが興味深い。

struct A {
  void f(int i);
  double g(size_t s);
};
/* ... */
cout << describe<&A::f>::name;   // Prints "f"
cout << describe<&A::g>::arity;   // prints 1

メンバーの情報を返すリフレクションtraitsとなっているのだが、名前を文字列で返すらしい。今のC++11には、そのような機能はない。このようなことを特に言及するでもなくさらりと書いているのだから、C++1yには、もしかすると静的リフレクションが入ってしまうかもしれない。

また、長年議論されている、クラステンプレートのコンストラクターからArgument Deductionできるようにしようという提案もある。

template < typename T >
struct X
{
    X( T ) ;
} ;

int main()
{
    X x( 0 ) ; // X<int>
}

いままでなら、make_Xのようなヘルパー関数テンプレートを作る必要があったが、その必要がなくなる。

さらに小さな変更だが、仮引数パックを型と非型で区切れるようにしようという提案もある。たとえば、以下のようなコードが動くようになる。

template < typename ... T, T ... t >
struct X { } ;

int main()
{
    X< int, double, int, 1, 1.0, 1 > x ;
} ;

型と非型で区切り目が明らかに区別できるのだから、これが認められてもいいじゃないかという提案だ。

そして、完全に特殊化されていた場合に限り、メンバー関数テンプレートをvirtualにできるようにしようという提案もある。これは、Modern C++ Designのsection 3.1を受けたものだ。

N3406: A proposal to add a utility class to represent optional objects (Revision 2)

Boostにあるoptionalを標準ライブラリに入れる提案。

N3407: Proposal to Add Decimal Floating Point Support to C++

10進浮動小数点数の提案。ライブラリでの実装になる。

N3408: Parallelizing The Standard Algorithms Library

STLにある既存のアルゴリズムの、並列実行版を追加する提案。thrustを元にしている。従来のSTLのアルゴリズムに親しんだC++プログラマーならば、そのまま使えるインターフェースになっている。

なぜ並列実行アルゴリズムのライブラリを標準化するのかとか、このライブラリを標準化するのは正しいのかとかなどの疑問にも回答している。

現在の環境ごとのスレッドモデルには様々な違いがあり、また制約も多い。特にベンダー独自の仕組みが多く、移植性がない。STLのなじみあるアルゴリズムを並列実行版として提供して、実装は各自に任せるという方法が最適であると結論している。

N3409: Strict Fork-Join Parallelism

N3408とはうってかわって、こちらはstrict Fork-Joinという実行モデルのサポートのために、コア言語による文法としてのサポートが必須であるという主張になっている。

この提案に規格の文面が存在するわけではないが、土台としてはIntel® Cilk™ Plusコンパイラーの文法を改良したものになっている。さらに、タイトルにもあるように、Fork-joinという、多数の実行単位を発生(fork)させて、実行の終了を待つ(join)という実行モデルを採用している。さらにstrictという概念があって、色々とその意味や、この実行モデルを採用する理由について解説している。

N3410: Rich Pointers with Dynamic and Static Introspection

C++に静的動的両方のリフレクション機能のうち、型やポインターの参照先の型情報を詮索する機能の提案。コンパイラーによる支援とライブラリの二本立てになっている。

この機能により、関数型の戻り値の型や仮引数の個数とそれぞれの型、クラスの基本クラスやメンバーなどの情報を、静的、動的の両方で列挙してアクセスできる。

コンパイル時はもとより、実行時の型情報も重要である。C++は極めて単純な実行時型情報の機能を提供しているが、これは十分ではない。もっと詳しい詮索がしたいものだ。Bjarne Stroustrupも書いたように、ある言語にある機能が存在しないならば、プログラマーはその言語上で実装する。実装するコストが割りに合わないのであれば、言語で直接サポートしたほうがよい。

既存の例として、QtやGoogle Protocol Buffersが挙げられている。Qtはプリプロセッサーマクロを多用して 手動で実行時型情報のためのテーブルを構築するものであり、Google Protocol Buffersは、専用のコンパイラーを使って機械的に生成するものである。どちらも、専用のフレームワーク内でしか動かない。

N3411: Additional Searching Algorithms

検索アルゴリズムにBoyer–MooreとBoyer-Moore-Horspoolを追加する提案。Boyer-Mooreは効率のいい文字列検索で有名なアルゴリズムだ。ただし、検索前に検索用テーブルを構築しなければならず、そのテーブルのためにメモリ消費量が多いアルゴリズムなのだが、それなりの量のデータ列から、複数の要素の連続したパターンを探す場合には、テーブル構築によるロスはすぐにかき消される。Boyer-Moore-Horspoolはその変種で、テーブル構築の一部を省略することで、メモリ消費量が少ない代わりに、worst caseで劣るアルゴリズムである。

Boyer-Mooreといえば検索前にテーブルを構築しなければならないのだが、narrow character以外の多数の状態をもつような型に対しては、ハッシュテーブルを用いるらしい。なるほど。

N3412: Runtime-sized arrays with automatic storage duration

すでに2月のmailingで出されたが、配列の長さを実行時に指定できるようにする提案。C99に存在し、またGCCも早くから独自拡張として提供していた機能だ。

使い方は以下の通り。通常の配列の宣言の添字をコンパイル時定数にしなくてもよくなるだけだ。

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

N3413: Allowing arbitrary literal types for non-type template parameters

そうか。ついに来たか。

非型テンプレート仮引数に任意のリテラル型を許可するぶっ飛んだ提案。

もはや浮動小数点数がどうとかいう話ではない。リテラル型ということは、条件を満たせばクラスでも可能だという事だ。constexprを使えばコンストラクターも持てる。

struct L
{
    constexpr L( int v ) v(v) { }
    int v ;
} ;

template < typename T >
struct S { } ;

S<L(1)> s ;

すると問題になるのは, リテラル型を非型テンプレート実引数に取るテンプレートの型が等しいかどうかを判定する方法だ。型が等しいかどうか判定するには、非型テンプレート実引数が等しくなければならない。クラスである以上operator ==で比較すべきだろうか。問題は、constexprがある以上、リテラル型でもoperator ==は実装できる。

struct L
{
    constexpr L( int v ) : v(v) { }
    int v ;
    constexpr bool operator == ( L x, L y ) { return true ; } 
} ;

すると、S<L(1)>とS<L(2)>は同じ型という事になる。

何が困るかというと、C++は、古典的なリンカーで実装できるように設計されている。C++では、テンプレートの特殊化である実際の型には、シンボル名にテンプレート実引数などの情報を埋め込んでいる。これをname manglingという。リンカーは、単にシンボル名が完全一致するかどうかで、型が同じかどうかを判断できる。

このペーパーでは、operator ==を使うのは実装上難しいので、メンバーごとの比較にしてはどうかと提案している。このあたりはさらなる議論が必要そうだ。実装経験がないのも懸念される。

N3414: A Rational Number Library for C++

タイトル通り、有理数ライブラリの提案。

数学の知識がないのを棚にあげて言うのだが、この手の数学的な簡易なクラスのライブラリが実際の現場で使われることがあるのだろうか。<cmath>にあるような基本的な関数はともかくとして、この手の複素数やら有理数やらの汎用的で簡易な実装が、現実に使えるものなのだろうか。

N3415: A Database Access Library

C++にデータベースにアクセスするためのライブラリを設計するとしたら、そのインターフェースはどのようになるかという可能性を示す提案。もちろん、C++のすべての実装にデータベースライブラリの実装を要求するのはありえないので、これは技術規格への提案ではなく、Technical Reportへの提案の形を取っている。

N3416: Packaging Parameter Packs

そうか、ついに来たか。

純粋なパラメーターパックに名前をつけられるようにする提案。もっと具体的に言うと。型リストをコア言語でサポートするという提案。

従来、型リストはライブラリでサポートされていた。C++で型リストを積極的に使った有名な本は、Modern C++ Designである。ただ、Lokiの実装は古い。最近では、型リストにコンテナーやイテレーターの概念を持ち込んだBoostのMPLがある。もっともこれも古い実装だ。C++11の機能を十分に活用した全く新しい型リストの開発が望まれる。標準ライブラリのtupleは、非常に貧弱である。

なぜ型リストをコア言語でサポートする必要があるのか。「既存の型リストのライブラリの存在と利用から分かるように、型リストは有益である。しかし、現状のライブラリは、言語に制限されている。したがって、型リストの実装を助けるようなコア言語の機能が必要である」というのが、この提案の主張らしい。この提案は、コア言語で型リストを完全に実装するのではなく、ライブラリの実装を助けるコア言語の機能の提案である。

この提案は、パラメーターパックリテラルというものを導入する。パラメーターパックリテラルは、<>で囲まれたテンプレートパラメーターリストである。

< int, short, 1, double >

型と非型を両方とも含めることができる。おそらく、テンプレートも含められるだろう。

パラメーターパックリテラルには名前を付けられる。

typedef<signed char, short int, int, long int, long long int> signed_integral_types;
cout << contains<signed_integral_types, int>::value; // Prints true

これにより、テンプレート外からでも、型リストを簡単に使える。

containsというのは仮に考案されたライブラリで、テンプレートパラメーターリストに与えられた一つ目のパラメーターパックリテラルから、二つ目のテンプレート実引数が含まれているかどうかを探すものだろう。

この使用例からも分かるように、パラメーターパックリテラルは、それ自体を区別して、展開されないままに、テンプレート実引数に取ることができる。

// Inherits from true_type if typelist TL includes all the types in TL2
template< <typename...> TL, <typename...> TL2> struct contains;

<typename...> という記法が、非展開のパラメーターパックリストを受け取る文法だ。

また、この提案の副産物として、型や非型を区別せずに受け取るテンプレートを記述できるようになる。...に対して、.を使う珍妙な文法になるのだが。

N3417: Proposal for Unbounded-Precision Integer Types

そうか。ついに来たか。

無限精度の整数型ライブラリの提案。

基本型の整数型の精度では足りないという事がよくある。その時、無限精度の整数ライブラリが標準ライブラリにあればいいのにと、いつも思う。実際、多くのプログラミング言語は、無限精度の整数演算を提供している。C++にもあってしかるべきだ。

このライブラリは、C++に標準ライブラリとして存在しないのが不思議でならない。たしかに、すべての環境で必要なライブラリではないだろうが、標準ライブラリに入っているべきだ。

思うに、このライブラリに対する要求が、人それぞれ甚だ異なるからではないだろうか。ある者は最高のパフォーマンスを求め、またあるものは、正しく動き、手軽に使えるライブラリを求める。

Boostでも、無限精度の整数ライブラリがレビューにかかるたびに、いつも賛否両論のレビューが寄せられ、結果として、より議論を深めてからということで、お流れになる。

理由は、パフォーマンスだとか使い勝手だとか様々だ。思うに、万人を満足させる無限精度整数ライブラリなど不可能だ。現実に、このライブラリは必要とされている。このライブラリは、純粋にプログラミングの問題だから、実装は楽しい。多くのプログラマーは、プログラミング学習の一環として実装したりもする。しかし、だからこそ、自前で実装するべきではないライブラリともいえる。そのようなライブラリは、気軽に自前実装するべきものではなく、十分に検証された実装を使うべきだ。

誰もがその必要性を認めながら、細部で同意が得られないために、なかなか採択されないライブラリというのは、不幸なことだ。

N3418: Proposal for Generic (Polymorphic) Lambda Expressions

ジェネリックlambda式、あるいはポリモーフィックlambda式の提案。

今のlambda式は、ジェネリックではない。例えば以下の関数テンプレートに渡すlambda式を書くことは難しい

template < typename Func >
void f( Func func )
{
    func( 123 ) ;
    func( 0.001 ) ;
    func( "hello" ) ;
} 

これは、現状のlambda式がジェネリックではないためである。lambda式の引数には、具体的な型を指定しなければならないのだ。もちろん、Boost.Anyのようなクラスを引数に取るlambda式なら書けるが、ここではそのような方法は使いたくない。

しかし、lambda式を使わずに、従来のクラスで実装した関数オブジェクトを使えば、この関数テンプレートに渡す関数オブジェクトは、簡単に実装できる。

class FuncObj
{
public :
    template < typename T >
    void operator ()( T t ) const ;
} ;

int main()
{
    FuncObj funcobj ;
    f( funcobj ) ;
}

単なるシンタックスシュガーであるlambda式に、これができないのは理不尽だ。以下のようにかけたら何とすばらしいことか。

f( []( x ) { } ) ;

つまり、lambda式の引数の型を省略して、テンプレートのように振舞わせるのだ。

ジェネリックlambda式は、C++11にlambda式を採用する際にも考慮されたのだが、コンセプトと併用した場合の見解決の問題があったために、却下された。コンセプトは最終的にC++11に採用されなかったが、ジェネリックlambda式の復活はなかった。検証する時間も足りなかったので、妥当な判断だったと思うが、次の規格改訂には是非とも採用して欲しい機能だ。

lambda式に使い慣れたテンプレート仮引数リストの文法を記述できるようにし、複数のlambda式を渡して優先順位を付けられるようにする機能も提案されている。

また、関数の本体を式にすることも提案されている。たとえば、

[]( x ) { return x + 1 ; } ;

というlambda式は、

[]( x ) x + 1 ;

と書けるようになる。

また、この文法を利用して、通常の関数テンプレートを、lambda式の形で書くことができるようにする提案もされている。つまり、

template < typename T >
T const & min( T const & x, T const & y )
{ return x < y ? x : y ; }

と書いていたのが、

[]min( const & x, const & y ) x < y ? x : y ;

と書けるようになる。私は冗長な文法でも特に構わないと思うのだが、lambdaを好む人間は、冗長な文法を嫌う傾向にあるので、このほうが好ましく感じるのだろう。分からないでもない。私はむしろ、D言語のように、関数の宣言には、functionのようなキーワードを使うほうが、わかりやすくていいと思うのだが。

N3419: Vector loops and Parallel Loops

新しいループの文法として、ベクトルループとパラレルループを追加する提案。パラレルループは、ループの本体を順不同で同時並行に実行するものである。パラレルループはループ終了の条件に厳しい制限があり、またループ本体でも、returnやbreakやgotoなどといったループ内外に制御を移すことができないといった制限がある。ベクトルループは、ループの実行前にループ回数が分かっているカウンタブルループに対してのみ使うことができるループである。

どちらのループも、制限が多く、すべてのループに適用できるわけではない。しかし、もはや純粋にCPUのパフォーマンスが向上する時代が終わり、並列実行を本格的に考えなければならない時代、やはりこのような機能も考えていかなければならないのだろう。

N3420: A URI Library for C++

URIを扱うライブラリの提案。URIをパースして妥当性を検証したり、各コンポーネントに分割したり、また各コンポーネントを結合したり、パーセントエンコードやノーマライゼーションなどといった、各種URIに関わる処理ができるライブラリ。

N3421: Making Operator Functors greater<>

<functional>のgreaterなどの比較用のクラステンプレートを、テンプレート実引数なしで使えるようにするもの。

思うに、そもそもクラステンプレートとして実装する必要はなかったと思うのだが。むしろ別の名前空間に同名のクラスでメンバーテンプレートを持っているものを作ったほうがいいのではないか。

N3424: Lambda Correctness and Usability Issues

Lambda式の正しい使用が、時として困惑をもたらすことについて。

ほとんどのプログラマーは、プログラミング言語を、規格書や文法定義から学んだりしない。たいていは、参考に書かれたサンプルコードなどをみて、思い込みのメンタルモデルを構築するものだ。それは悪くない。もし、ある言語が、その見た目から想定外の挙動をするならば、それは言語の設計が悪いのだ。

lambda式が採用され、実装され、使用経験が積もってきた所で、ユーザービリティの問題が浮上してきた。

lambda式を多用している巨大なコードベースを持つある顧客が、lambda式に起因するバグを調べたところ、ほとんどのバグはある一つの言語の誤解から生じているが判明した。暗黙のthisのキャプチャーである。

ちなみにこのペーパーの著者はMicrosoftのHerb Sutterなので、顧客というのは、Visual Studioの利用者だろう。

lambda式のキャプチャーにおいて、thisはやや特別な扱いを受ける。thisというのは、ポインターである。そのため、キャプチャーするのもポインターだ。lambda式の中における、クラスのデータメンバーは、thisポインターを経由して使う。ということは、データメンバーを値でキャプチャーするということはできない。

struct Foo
{
    int z ;
    void f( int x )
    {
        int y ;
        auto l = [=] { // すべての変数を暗黙的に値でキャプチャー
            x ; // 値でキャプチャー
            y ; // 値でキャプチャー
            z ; // キャプチャーしたthis->z
        } ;
    }
} ;

Herb Sutterが関わったプログラマーは全員、ここでzがthisポインターを経由して使われることを期待してはいなかった。キャプチャーリストで、すべての変数を暗黙的に値でキャプチャーするように指定したのだから、zは値でキャプチャーされるべきだと考えていた。実際には、thisを経由して使われるので、実質的には、リファレンスである。

さらに、多くのプログラマーが、データメンバーといえども、個々に値でキャプチャーしたいと考えていることが判明した。現状のC++11では、データメンバーを値でキャプチャーする方法はない。どうしても値でキャプチャーしたければ、同名のローカル変数でデータメンバーの名前を隠すしかない。

事実として、この仕様はすべてのプログラマーに誤解を引き起こしている。しかし、修正するとなると、互換性を壊すような修正になる。しかし、すべてのプログラマーが誤解する機能であれば、修正したほうがいいのではないか。

提案されている中でもっとも良い修正案では、データメンバーも個々にキャプチャーできるようにし、データメンバーを参照したい場合は、this->zのように、明示的にthisポインターを使わなければならなくするように提案している。

もうひとつの誤解は、値でキャプチャーした変数は、デフォルトでconst修飾されているという事だ。

void f()
{
    int x = 0 ;
    [=]{ x += 1 ; } ; // エラー、mutableが必要
} 

コピーキャプチャーされた変数を書き換えるには、明示的にmutableキーワードを使わなければならない。

[=]() mutable { x += 1 ; }

この機能は、安全のために取り入れられた。というのも、コピーキャプチャーされた変数は、クロージャーオブジェクトのデータメンバーであるので、クロージャーオブジェクトのoperator ()を呼び出すたびに、変更されてしまう。しかし、すべてのプログラマーは、この挙動に不審を覚える。余計なお世話ではないか。すでに明示的にコピーすると宣言しているのに、なんでデフォルトで変更できないようになっているのだ。そもそも、C++は、コピーした値がデフォルトでは変更できないようにはしていない。

void f( int x ) // 変数は値渡しされるという意味は明らか
{
    x = 0 ; // OK、コピーされた値の変更は許可されている
}

このコードが全プログラマーが同意する挙動である。もし、このコードが、mutableをつけない限り拒絶されるとしたら、それこそ「余計なお世話」である。

そこで、lambda式のmutableを廃止しようという修正を提案している。

N3425: Concurrent Unordered Associative Containers for C++

ロックフリーでデータ競合を引き起こさない要素の追加や検索を実現するunorderedコンテナーを追加する提案。

unorderedコンテナーをロックフリーに実装する方法が確立されている。提案されているコンテナーは、eraseやbucket操作などを除けば、安全に使用できる。

提案では、eraseなどの操作は、ロックフリーにしないほうがいいとしている。そのため、unsafe_eraseなどのような名前をつけることを提案している。ただし、clearやswapのような有名な名前は、名前自体が有名であるし、その要素を取り除く意味が明らかであるので、そのままにするべきだとも提案している、ロックフリーに実装することもできるが、パフォーマンスに与えるコストが大きいため、実装するとしても、デフォルトでは無効にしておき、テンプレート仮引数で有効を切り替えるような実装にするべきだと提案している。

N3426: Experience with Pre-Parsed Headers

Googleが社内でGCCを改良して、ヘッダーファイルのビルドのパフォーマンスを向上させようとした経験からの報告。なかなか興味深い。この経験は、プリプロセッサーによるテキストの取り込みの代わりになる、モジュールの機能を議論する際に参考になるだろう。

GCCも含めて、多くのC++コンパイラーは、コンパイル済みヘッダーという機能を提供している。これは、すべてのソースファイルからincludeされるほとんど変更しない共通のヘッダー群をあらかじめコンパイルしておいて、その結果を読み込むことで、ヘッダーのコンパイルを省略し、もってパフォーマンスの向上を図る機能である。問題は、Googleのコードベースには、そのような、すべてのソースファイルからinlucdeされるほとんど変更しない共通のヘッダー群など存在しない。

そこでGoogleが試したのは、パース済みヘッダーだ。パースを行った結果のGCCの内部表現を吐き出し、あとで必要になった時に読み込むというものだ。これにより、単一の巨大なプリコンパイル済みヘッダーファイルに依存することがなくなり、あらゆるヘッダーファイルが変更される環境でも、ヘッダーファイルに対応するパース済みヘッダーファイルのみが影響を受けるだけになる。

問題は、ヘッダーファイルの意味は、その前にincludeしたヘッダーファイルのマクロ定義によって変わってしまうということだ。したがって、モジュラーなヘッダーを、以下のように定義する。

  1. インクルードガードを使っている
  2. 単離した環境でプリプロセスしてパースできる
  3. グローバル名前空間にincludeされる

調査の結果、ほとんどのアプリケーションのヘッダーは、モジュラーであった。問題は、システムヘッダーの多くが、非モジュラーなヘッダーだったのだ。

ある社内のプロジェクトに結果を適用してみた結果、パースにかかる時間が半分になり、結果として全体のビルド時間が5倍になった。

しかし問題はある。パース済みのヘッダーは、依然としてヘッダーであることにはかわりがないので、プリプロセスは依然として行わなければならない。そのため、プリプロセッサーマクロは保持して、パース済みヘッダーを読み込む際に再生しなければならない。

同じパース済みヘッダーが二度includeされる状況に対応するために、同一のシンボルはマージしなければならない。

GCCは、従来のヘッダー処理のために、多くの箇所で最適化の仕組みがある。この最適化は、パース済みヘッダーのためには、むしろ邪魔である。そのため、いちいち潰したり、問題にならないように対処したりする必要がある。

さらに、GCCのパース済みヘッダーの内部表現は、一度書きだして後で読み込むといった利用方法のことは考慮されていないので、コード生成に必要なヒントなどの情報を含み、無駄が多い。

もっと問題になるのは、Googleのビルドシステムだ。Google社内のビルドシステムは、極端に並列化されている。ただし、マルチコアシステムが一般的になった今、ビルドシステムが並列化されているのは、Googleだけの特殊な環境ではないと言える。

ビルドの過程には、並列化できない依存関係がある。並行ビルドを行う前に、そのような依存関係をすべて洗い出してビルドに必要な依存グラフを構築しなければならない。ところが、パース済みヘッダーファイルを生成するということは、新たな依存関係を持ち込むという事である。このために、依存関係が複雑になり、巨大なコードベースにおける依存グラフの構築にも時間がかかるようになった。

さらに、シンボルのマージは、実装が難しく多くのバグを誘発した。処理にも時間がかかる。

もっと問題なのは、問題の種類が変わってきたことだ。

GCC本体の最適化により、プリプロセスやパースにかかる時間が減ってきた。さらに、ビルドプロセスには、コンパイル以外の他のツールも関わるようになった。例えばソースコードの静的解析ツールなどだ。googleのビルドシステムでは、clangでもビルドして、静的に発見できるコード上のエラーを見つける試みもしている。

結果として、ビルド時間全体の80%を占めていたパースは、今や全体の60%の時間しかかからず、パースのパフォーマンスを倍にしたとしても、結果は5倍ではなく2.5倍の向上に留まってしまった。

よほどマージの実装に苦労したらしく、さらにマージの問題点やら、バグに悩まされたことやら、マージをしなくてもよければパフォーマンス向上はすばらしいなどと続く。

パース済みヘッダーの経験からのまとめ。

C++ヘッダーモデルは生産性の妨げになっている。

従来、下位互換性といえば、既存のコードをそのまま同じようにコンパイルできることを意味していたが、今はソースコードの自動変換技術も発達したので、自動変換できるかどうかで判断すべきであること。

モジュール機能の設計にあたっては、ビルドシステムのことを無視してはいけないこと。

必要なだけのシンボルを外部にエクスポートできる機能があれば、パフォーマンスの向上につながること。

シンボルのマージは非常に高くつき、また実装の難しい処理であること。

あるひとつのシンボルはあるひとつのモジュールだけで提供されていることは重要であること。モジュール機能は、シンボルの再定義を禁止すれば、パフォーマンス向上につながるのではないか云々。

現状で、アプリケーションヘッダーは十分にモジュラーであるが、システムヘッダーはモジュラーではない。モジュール機能のためには、従来のシステムヘッダーを書きなおす必要がある。

ああ、Cプリプロセッサーが廃止される日をこの目で見たい。

N3427: Shared Locking

読み手は多いが書き手は少ない状況に向けた、やや効率的なロック機構を実装できる。mutlple-readers single-writer locking patternをサポートする、shared_mutexライブラリの提案。

N3428L A Standard Programmatic Interface for Asynchronous Operations

入出力の非同期処理は非常に重要になってきている。std::futureを改良して、非同期処理にも十分に対応できるようにしようという提案。

N3429: A C++ Library Solution To Parallelism

ライブラリで並列実行をする際に、どのような機能を提供できるかという考察。

N3430: Proposing std::split()

文字列をデリミターによって分割する処理、いわゆるsplitは、汎用プログラミング言語には極めて一般的なものである。ところが、C++にはそのようなライブラリがない。そのため、各自で実装しなければならない。

たとえば、以下のような関数になるだろう。

std::vector<std::string> my_split(const std::string& text, const std::string& delimiter);

しかし、別のコンテナーで返したいだとか、デリミターを正規表現にしたいだとかいった些細な違いによって、文字列の分割処理は同じだが異なる実装を創りださなければならない。

Google社内では、現実のコードで、50ものそれぞれ微妙に異なるsplitの実装が使われている。

そこで、Google社内で汎用的なsplitを設計して実装したところ、評判が良かったので、標準ライブラリとして提案するそうだ。

N3431: "quoted" proposal

iostreamでは空白文字がデリミターとして扱われ、入力と出力が一致しない。そこで、空白文字も含めて引用符的な動作をするマニピュレーターを追加しようという提案。

私が思うに、iostreamはテキスト処理をするべきではなかった。純粋に入出力のみを扱うべきだった。今のiostreamは使いたくないのでどうでもいい。

N3432: C++ Sized Deallocation

グローバルなoperator deleteのオーバーロードは、解放すべきストレージのサイズを得ることができない。一方、メンバー関数によるoperator deleteでは、受け取ることができる。モダンなメモリアロケーターはサイズごとにカテゴリ分けされた実装を使う。ストレージの近くにサイズを記録しておくことはない。そのため、現行の実装では、アドレスのみが渡されるので、どこから確保されたのか、検索しなければならない。これはパフォーマンス上コストがかかる。そもそも、コンパイラーはストレージのサイズが分かっているのだから、operator deleteに渡すべきだという提案。

すでにGoogleによってGCCとTCMallocで実装されており、実装経験があるという。

N3433: Clarifying Memory Allocation

動的ストレージの確保はパフォーマンスに直結する問題である。ストレージの確保戦略は、プログラムの動作にあわせて、動的に変更できるべきである。しかし、規格の文面では、ある種の最適化を許していないように解釈できる。

現行の規格の文面を厳格に解釈すると、CとC++の規格は、ストレージ確保は、前後のストレージ確保要求に影響されずに行われなければならないとある。つまり、プログラムのストレージ確保の仕方にあわせて、動的にストレージ確保の戦略を変えるような最適化は、規格上許されない。

たとえば、あるプログラムが大きさや頻度などに特徴のあるストレージ確保を連続して発行した場合に、しばらく同じような特徴を持つ確保が続くだろうと予測して、そのような場合にストレージ確保を最適化するような確保関数の実装は許されない。

現行の規格の文面を厳格に解釈すると、実装はそれぞれの関数呼び出しに対し、それぞれ個別に外部関数を愚直に呼び出さなければならないとある。つまり、複数のストレージ確保をまとめてひとつのストレージ確保として発行するような最適化は、規格上許されない。

たとえば、複数回ストレージ確保を行うコードがあるとして、実装がそれをまとめてひとつのストレージ確保として発行して、ひとつの連続したストレージを得て、分割して使うような最適化は、規格上許されない。

このような最適化を許すように、制限を緩和する。

すなわち、確保関数の呼び出し回数はプログラムから観測可能な挙動ではない。確保関数の仮引数と戻り値は、プログラムから観測可能な挙動ではない(ただし、確保するストレージは、アライメントなどの調整以上に、指定されたサイズを超えてはならない)

つまり、複数回のストレージ確保が、実装により、一度のストレージ確保にまとめられる可能性があるという事だ。つまり、今までならば、

int main()
{
    new int ;
    new int ;
}

と書いた場合、::operator newは二回呼ばれることが保証されていたが、この提案が受け入れられたならば、実装により、一回にまとめられる可能性もあるという事だ。

N3434: C++ Concurrent Queues

concurrent queueライブラリの提案。

N3435: Standardized feature-test macros

機能テスト用のマクロの提案。

そもそも、Cプリプロセッサーは一刻も早く滅びるべきであるのに、今さらこのようなマクロを導入するのは気にいらない。Cプリプロセッサーの存在に頼る新機能を導入することは、Cプリプロセッサーの廃止の妨げになる。

かわりに、強力なstatic ifを導入すべきだと思う。コンパイル時に選択されない分岐は、たとえ文法違反でも無視するような仕様であれば、マクロに頼る必要はない。

N3436: std::result_of and SFINAE

std::result_ofは、関数のシグネチャの中で使った場合、SFINAEが発動しない。decltypeを直接使うと、SFINAEが正しく発動する。

ペーパーで使われているサンプルコードはあまりわかりやすくない。そこで、decltypeを使うとコンパイルが通るが、result_ofを使うとエラーになるコードを書いてみた。

struct X
{

    // SFINAEにより、Tがクラス型の場合は選択されない
    template < typename T, 
        typename Dummy = typename std::enable_if< !std::is_class<T>::value >::type
    >
    void operator () ( T ) ;

    template < typename T >
    void operator () ( T ) ;
} ;


// OK、decltypeを直接使うとSFINAEが発動する
template < typename T >
decltype( std::declval<X>()( std::declval<T>() ) ) f() { } // #1

template < typename T >
void f() { } // #2

// エラー、result_ofにSFINAEは発動しない
template < typename T >
typename std::result_of< X( T ) >::type g() { }

template < typename T >
void g() { } 

int main()
{
    f<int>() ; // OK、#2が選ばれる
    g<int>() ; // エラー、曖昧
}

この問題を解決し、SFINAEが発動するように、result_ofのネストされた型であるtypeは、decltypeを使った式がwell-formedの場合のみ存在するように変更する提案。

N3437: Type Name Strings For C++

C++にリフレクションを入れるにあたって提出されている提案に欠けている重要な事項に、型名を文字列で表現するということがある。現在、typeinfo::name()は、実装依存の人間に読める型を表現する文字列を返すと定義されている。実装依存であるので、この文字列を元にした移植性のあるコードは書けない。

C++にリフレクションを入れる際には、型名を文字列で表現する方法について規格化するのがいかに重要か。どのように利用できるかということを紹介するペーパー。

利用例では、SerializationとType introspectionとLanguage bindingが挙げられている。

N3441: Call Stack Utilities and std::exception Extension Proposal

コールスタック情報の取得と解析の標準ライブラリの提案。さらに、std::exceptionを拡張して、例外が投げられた場所のコールスタック情報を持つようにする提案。

ソフトウェアをデバッグする上で、コールスタック情報を人間が読める形に整形して検証できることは重要である。プログラム内から、コールスタックを取得する標準的な方法が存在するべきである。さらに、例外は、投げられた場所のコールスタックが重要であるから、標準の例外クラスであるstd::exceptionを変更して、コールスタック情報を持つようにする。

提案しているライブラリの、GNU/Linux上で動く実装も公開されている。

http://freeshell.de/~amelinte/lpt.tgz

N3442: string_ref: a non-owning reference to a string

文字列への参照は重要である。多くの場合、呼び出された関数側では、文字列がどのように表現されているかということは重要ではない。生の配列にせよ、クラスでラップされているにせよ、重要なのは、文字列だ。従来、そのような場合に文字列を受け取る場合には、以下の三種類の方法が使われてきた。

  1. std::stringを使い、文字列が所有されている場合は、コピーを要求する。
  2. char *と長さを受け取る。あるいはNULL終端であるとみなす。
  3. 関数の呼び出された実装をテンプレート化し、実装をヘッダーファイルに移す。柔軟ではあるが、弱いイテレーターコンセプトを使わなければならず、コンパイル時間やコードサイズの増加を引き起こし、バグの温床である。

GoogleとLLVMはどちらも、独立して、このような実引数の差異を隠匿する文字列を参照するライブラリを実装している。そのような文字列を参照するライブラリ、string_refを提案する。

N3443: Priority Queue Changes and Additions

現行のpriority_queueを改良する提案。ヒープに対するイテレーター、要素の変更、ヒープの効率的なマージ、安定したソートを選択可、ヒープの同一性の比較の機能を追加する。

N3444: Relaxing syntactic constraints on constexpr functions

そうか、ついに来たか。

constexpr関数の制限を大幅に緩和する提案。

constexpr関数でも、普通に複数の文を書けるようになる。

ただし、いくつかの制限はつく。ローカル変数はリテラル型のみで必ず初期化されなければならず変更することもできないし、ループ構文も使えないし(ループがしたければ再帰)、switch文とgoto文は禁止され、関数が定数式を返すパスが存在しなければならない。

とはいえ、constexpr関数といえども、普通に書けるようになる。

筆者のRichard Smithによるclangでの実験的な実装がgithubで公開されている。

zygoloid/clang at liberal-constexpr · GitHub

Pass by Const Reference or Value

プログラマーは、コストのかかるコピーを避けるためconstなlvalueリファレンスを多用しがちである。リファレンスはポインターのような文法上の汚さがない代わりに、ポインターと同じ問題がある。エイリアシングである。

extern type ra1(const type& input);
extern type ra2(const type& input);

void rf1(type& output, const type& input) {
    output += ra1(input);
    output += ra2(input);
}

このようなコードがある場合、もし、関数を呼び出すユーザーが、outputとinputに同じオブジェクトを渡した場合、問題が起きる。

エイリアシングに対処するためには、inputを常にコピーして使うとか、outputとinputのアドレスを比較してエイリアシングを検出するなどの方法がある。しかし、コピーを防ぐためにリファレンスにしたのに、常にコピーしては本末転倒であるし、アドレスを比較するということは、条件分岐をもたらし、深いパイプラインが当たり前になっている今日のCPUアーキテクチャ上では、コピーより高くつく場合もある。

Cのrestrictのような機能は、エイリアシングが起きたら未定義と言うに等しく、C++に導入すべき機能ではない。

ともかく、エイリアシングの問題を考慮しないプログラマーがconstリファレンスをパフォーマンスのために盲目的に使うのが問題であって、効率的に引数として渡す文法を導入してはどうか。つまり、コンパイラーが自動的に、コピーのほうが効率がいい場合はコピーし、リファレンスのほうが効率がいい場合はリファレンスに決定するように支持する文法があればいい。

ペーパーでとりあえず提案されている文法は、以下のようなものである。

extern type oa1(const type| input);
extern type oa2(const type| input);

void of1(type& output, const type| input) {
    output += oa1(input);
    output += oa2(input);
}

なんだかよりわかりにくくなったと思うのは、この文法に慣れていないためであろうか。まあ、この文法はあくまで提案であるのだが。

N3446: C++ Mapreduce

またもやGoogleによる、Mapreduceライブラリの提案。Googleならお得意だとは思うが、それにしても、本当にGoogle由来の提案が多い。今が盛りという事か。10年後はどんな企業に取って代わるのだろうか。

N3448: Painless Digit Separation

数値のリテラルに区切り文字の使用を許す提案は、以前から議論されてきた。

int x = 123_456 ;

あまりに長い数値は、読みやすくするため、途中で区切りたいものだ。

問題は、区切り文字がアンダースコアであると、ユーザー定義リテラルと曖昧になるという事だ。そこで、区切り文字をシングルクオートにする提案。

int x = 123'456 ;

N3449: Open and Efficient Type Switch for C++

ものすごく本格的な論文らしい論文。もちろん、ここで紹介したすべての文章は"paper"であり、日本語に訳せば論文となるのであろうし、一応、すべて論文の体裁は取っているのだが、ここまで本格的な体裁のC++WGの論文は、なかなか珍しい。

内容は、実行時の型による効率的なswitchを実現するライブラリである。標準規格への提案ではなく、技法の紹介のようだ。

Bjarne Stroustrupも共著に名前を載せている。まあ、これは当然のことで、氏はこの手の動的な型による条件分岐が好きなのだ。本音としては、マルチメソッドがC++に採用されて欲しいのだろうが。

Bjarne Stroustrupが共著に載っているためなのかどうかはわからないが、ソースコードにプロポーショナルフォントを用いている。氏はソースコードにプロポーショナルフォントの利用をためらわないことは有名だとはいえ、非常に読みにくい。

ライブラリの実装は以下で公開されている。

Supporting material for OOPSLA-2012 publication

個人的な意見では、このライブラリはクソである。私の基準では、Cプリプロセッサーのマクロの使用が必須のライブラリは例外なくクソだ。このライブラリは、switch文のような文法をエミュレートしようと、Cプリプロセッサーのマクロを多用している。

N3450: Iterator-Related Improvements to Containers

コンテナーにイテレーター関連の極めて些細な改良をいくつか加える提案。この提案されている改良は、現状でも問題なく行えるが、標準で備わっていることにより、教育しやすく、ユーザーコードを短くする。

last

コンテナーは、最初の要素へのイテレーターと、最後の要素の一つ先の終端としてのイテレーターを返す。しかし、時として、最後の要素を指す普通のイテレーターが欲しい場合がある(reverse iteratorではない)。現状では、end()の返すイテレーターから1を減じるしかない。最後の要素へのイテレーターを返すメンバー関数、last()をコンテナーに付け加えてはどうか。追加対象は、forward_listを除く、basic_stringとすべてのコンテナー。

イテレーターとインデックスの相互変換

イテレーターとインデックス(何番目の要素であるか)を相互変換したい場合がよくある。問題は、現状でその変換を正しく行うのは、非常にややこしい。しかも、size_typeとdistance_typeという、二つのネストされた型名を使わなければならない。コンテナーに変換用のメンバー関数、to_iteratorとto_indexを追加してはどうか。追加対象は、basic_string、array、deque、vector。

ペーパーにはdistance_typeと書いているが、そのようなtypedef名はなく、differene_typeの誤りであろう。

Nullイテレーター

コンテナーのオブジェクトに関連付けられていない、何も指していない状態のイテレーターが欲しい。そのため、Nullイテレーターという概念を導入してはどうか。

Mapped typeイテレーター

mapを使っていると、キー要素にマップされた要素だけをイテレートしたいことがよくある。しかし、そのイテレーターはキー要素とマップされた要素のpairなので、わざわざ->secondと書かなければならず、非常にコードが汚くなる。

そこで、mapのアダプターであるmapped_adaptor_tを追加してはどうか。このアダプターを経由してイテレーターを得ると、マップされた要素を返すイテレーターが得られる。

N3451: async and ~future

futureとshared_futureのデストラクターはブロックしない。ただし、futureに関連付けられているasyncはブロックする。すると、futureのデストラクターも結果としてブロックする。この要求を廃止し、futureのデストラクターはブロックしないようにする提案。

2012-10-05

楽天の詐欺くさいLTEによる自称「高速通信」サービス

業界初!LTEの高速通信が月額980円で利用できる楽天ブロードバンド LTE」提供開始

NTTドコモのLTE網を利用したデータ通信サービスが急拡大する中、月額1,000円以下でデータ通信可能なサービスが続々とリリースされています。しかし、その殆どが100kbps~150kbpsの速度制限を課した低速通信であり、LTE網の最大のメリットである下り最大75Mbps(※)の高速通信を利用するためには、追加で各社が用意する速度制限解除用のオプション等を購入する必要がありました。

そこで、フュージョンと丸紅無線は、安価で快適なモバイルデータ通信サービスを求めるユーザのニーズに応えるため、業界で初めて月額1,000円以下で速度制限解除オプション無しにLTEの高速通信が毎月200MB分利用可能な「楽天ブロードバンド LTE 980円エントリープラン」(以下、エントリープラン)の提供を開始いたします。

転送量がたったの200MBに達した時点で速度制限を受けるような契約で、「高速通信」と謳うのは詐欺ではないか。

ちなみに、下り最大が75Mbpsであると書いているので、最大速度が出た場合、200MB分の転送量には、22秒で達することになる。さすが「高速通信」

邪悪なEPUBを支援してはならない

日本のEPUBの策定団体が、時間の問題で政府の支援を受けられないから支援してくれといっているが、支援してはならない。なぜならば、EPUBは邪悪だからだ。

EPUBの規格は、設計的な欠陥であるDRMを利用を許可している。これは許しがたい蛮行であり、人道上の罪である。

EPUBは本来、必要のないフォーマットである。すでに、HTMLやCSSといったドキュメントや表現方法の記述言語は、直接使うことができるのだから、それを使って書けばいいのだ。現に今読んでいるこの文章は、HTMLやCSSを直接使っているではないか。もちろん、通信経路で圧縮することはできるとしても、それは通信経路の話だ。複数のデータをまとめる必要があるにしても、アーカイバや圧縮方式には多数の有名なフォーマットがあるので、どれかを使えばよい。書籍のような広範な表現方法をもつもののパッケージ方法をひとつに定めることは不可能だ。

大抵のEPUBの内部のHTMLは、細かく分割されており、非常に使い勝手が悪い。

縦書きなどの表現方法のために、HTMLやCSSを改良するのはいいことだが、EPUBのようなDRMの利用を許す邪悪なフォーマットを策定してはならない。

Ubuntu 12.10にAmazonレンズを無効にする設定項目が加わったらしい

Ubuntu 12.10 Adds an Option to Disable Amazon Search Results ~ Ubuntu Vibes | Daily Ubuntu Linux Updates

なんにしても、まだオンライン上の動画検索はあるし、また12.10ではインターネットラジオ検索も追加される。12.10をインストールした後にやるべきことは、以下のコマンドを実行することだ。

sudo apt-get remove unity-lens-video unity-scope-video-remote unity-lens-shopping unity-lens-music unity-lens-photos unity-lens-radios

2012-10-03

世界各国の人口ピラミッド予測

Population Pyramid of Japan in 2010 — PopulationPyramid.net

これはすごい。世界各国の人口ピラミッドが、年代別の記録と、将来の予測でみることができる。

2012-10-01

SFW: 無修正サーバーポルノ

Server Porn

メカノフィリアにはたまらない完全無修正むき出しのサーバーのポルノ画像を日々紹介するWebサイト。

有名なオンラインゲーム用のブレード一枚から、大企業や国家組織のデータセンターまで豊富な取り揃え。うひひひ、たまんねーな。