Computer "Apple 1" sold at auction for half Million Euros! The Record
なんと、実働するApple 1がオークションに出品され、50万ユーロ以上もの値をつけたらしい。
"Apple 1"というのは、最初のAppleのコンピューターである。つまり、スティーブ・ジョブズの親の家のガレージで作られた最初のAppleのコンピューターだ。
現在、世界に実働するApple 1は6台しかないのだとか。
2012-11-28
2012-11-27
DOOM 3 BFGのソースコードが公開された
id-Software/DOOM-3-BFG · GitHub
ゲームデータは含まれない。
製品版との違いは以下の通り。
Steamに関わるソースコードは含まれない。
動画フォーマットのBinkに関わるソースコードは含まれない
Depth fail、あるいは俗に、カーマックリバースという名前で知られているStencil Shadowの描画技法は含まれていない。Creativeの特許がいまだに有効なためと思われる。
その他、GPLと互換性があるがGPLではないライブラリが列挙されている。
私はDOOM 3をやったことがないのだが、評判を聞いたり動画を見たりする限り、あまり面白そうなゲームではない。
2012-11-22
Sandy島を未発見したニュース
Sandy Island on Google Earth: Scientists Undiscover Pacific Island
Sandy島という名前の、オーストラリアとニューカレドニアの間の地図に載っている島がある。Google Mapもこの島を載せている。
また、多くの航海地図や気象地図にも載っている。
ところが、この島は実際には存在しないのだという。
実際に現地に向かってみても、やはり何もなかったという。面白いことに、現地に向かう際に使った船の航海地図や気象地図にも、やはりこの島は存在した。
地図会社が、著作権侵害を検出するために、実在しない道や地名を紛れ込ませることはある。しかし、航海地図では、そのようなことは一般的ではない。
またボジョレー・ヌーボの季節だ
どこもかしこもボジョレー・ヌーボだらけだ。ほとんどのコンビニでボジョレーを置いているのだから、一体日本だけでどれだけのボジョレーが存在するのやら。
ハイエクは自由市場こそ最も効率的な流通方法であると言ったので、自由市場が何をどれだけ売ろうが私の知ったことではないが、ボジョレーは廃棄も多いのではないかと思う。
私には酒の良さがわからないし、仮に飲むとしても蒸留酒を舐めるように飲むほうが好きで、ビールやワインをがぶがぶ飲むのは好きではない。したがって、ボジョレーは未だかつて飲んだことがない。
日本人は初物を好む文化があるとはいえ、今誰も、初がつおを争って食べたりなどしない。お茶や米は、古いより新しいほうが好まれるかもしれないが、何も先を争って食べるものではない。米については、少し古い米を使ったほうがいい料理もある。
というわけで、ボジョレー・ヌーボは、単に商業主義のマーケティングの結果、無理やり流行らせようとしている賞品である。
バレンタインならば、ブロックチョコレートが安く売り出されるので、それなりに利点もあるが、ボジョレー・ヌーボは私にとって何の利点もない。
と、取り留めのないことを書いた。
2012-11-21
発信機の装着を拒否した生徒、退学処分にあう
Student expelled for refusing to wear RFID tracking chip badge | ZDNet
John Jay高校は、全生徒に対し、発信機を内蔵したネックレスを装着することを義務付けた。この発信機により、全生徒の学校内の居場所がトラック可能である。
そのネックレスの装着を拒否したある生徒は、退学処分にあった。現在、弁護士が退学処分を取り消しべく争っている。
Big Brother is watching you.
Linux財団が自前軽量ブートローダーをMSのUEFI鍵で署名してもらうのに四苦八苦
[Phoronix] Linux Foundation Struggles With Microsoft UEFI Signing
Linux財団が過去に発表したUEFIに対する方針とは、自前の軽量ブートローダーを用意し、それをMS鍵で署名して、その軽量ブートローダーが実際のブートローダーをブートするという仕組みを作るというものだ。問題は、その軽量ブートローダーの署名プロセスに手間取っている。
まず、ブートローダーを署名してもらうためには、VerisignかSymantecの認証局による署名鍵が必要だ。それを超えたらMSの秘密鍵でブートローダーを署名してもらうために、マイクロソフトのWebサイトでブートローダーをアップロードするのだが、このWebサイトのアップローダーが、こともあろうかSilverlightで実装されている。MonoベースのMoonlightでは正しく動作せず、結局、ブートローダーのアップロードには不自由なWindowsを使わなければならない。
今時Silverlightを使うとは何と時代錯誤な。私にとっては、FlashやSilverlightは、パンチカードと同等に聞こえる。
さらに、マイクロソフト側でも何かおかしいことが発生しているらしく、特別な後から無効化できる鍵を関連付けるのではなく、単なる汎用の鍵で署名するのみだという。これでは使えない。UEFIは、後から特定のバイナリを無効化できるからこそ、暗号理論的にはまともであるのに、その無行こうかができないとは。
しかし、Linux財団の方針は、UEFIの思想とは合わないような気がする。
UEFIは、ブートローダーレベルからバイナリを認証する。この認証というのは、バイナリが改変されていないことを保証する。これにより、例えばマイクロソフトの出荷から、顧客の手元に届くまで、ブートローダーが悪意ある者により改変されていないことを保証できる。
そして、UEFIの思想に従えば、UEFIによって制御が渡された最初のブートローダーも、その後のより高機能なブートローダーや、あるいは直接OSを認証して、改変されていないことを保証する。OSも、ドライバーを認証して、改変されていないことを保証する。と、このように認証が連続して続くべきなのだ。
この方法は、あくまで途中の改変を防ぐだけであり、大本からして悪意あるプログラムを認証して配布する問題は防げない。ただし、特定のバイナリは、後から認証を取り消しできる仕組みがある。これにより、悪事が発覚した後は、広範な影響を与えることが難しくなる。
この仕組みは、UEFIだけではなく、SSLでも同じだ。SSLが保証するのは、経路途中の改変や傍受がなされていないことであり、Webサイトに悪意がないかどうかは保証しない。ただし、ひとたび特定のWebサイトに悪意のあることが発覚したならば、認証局は取り消しができる。
UEFIで問題になるのは、最初のUEFIによって認証されるブートローダーを認証する公開鍵だ。この公開鍵は、あらかじめUEFI側に格納されていなければならない。UEFIに格納するというのは、マザーボードの出荷段階で書き込んでおかなければならない。では、その秘密鍵は誰が管理するのか。認証局は誰が引き受けるのか。
UEFIはマイクロソフトが音頭を取って主導したので、今のところ、マイクロソフトが唯一の認証局として機能している。マイクロソフトは、いかなるバイナリでも、Verisignの認証を受けた者が提出したバイナリであれば、機械的に署名する。バイナリに問題があれば、あとから無効化する。
FedoraのUEFIへの対応は、UEFIの思想にあうものだ。まずマイクロソフト鍵により署名された軽量ブートローダーをUEFIに認証させて制御を移し、軽量ブートローダーは署名されたブートローダー（GRUB2）を認証して制御を移し、GRUB2はOS（Linuxカーネル）の署名を認証してOSに制御を移し、Linuxカーネルはモジュールを認証する。
ところが、Linux財団の方針を聞いている限りでは、どうも違うような気がする。署名されたLinux財団の軽量ブートローダーは、その後一切認証せずに設定されたバイナリに制御を移すそうだ。これではUEFIの目的が損なわれないだろうか。そのようなブートローダーは無効化されるのではないか。
UEFIは、本当に正しく実装されれば、すばらしいものである。何故ならば、利用者はマイクロソフトの鍵をUEFIから取り除いて、マイクロソフトの不自由なソフトウェアの実行を拒否することができるからだ。しかし、経験的に、マザボベンダーのファームウェアの実装はひどいものであり、複雑なUEFIの実装には、まず確実に欠陥が生じるだろう。
少なくとも、マザボベンダーは、ともかくもWindowsをブートすることに注力するので、たまたまWindowsは特定のUEFIの規格違反の実装でも起動するところ、その他のOSは起動しないということが、頻繁に起こる。従来のBIOSでも頻繁に起こっているのだから、より仕様が複雑なUEFIではなおさら頻繁に起こるだろう。そのような規格違反のUEFIの実装による認証が信頼できるだろうか。
2012-11-17
Appleがページめくりの特許を取得
Apple Now Owns the Page Turn - NYTimes.com
United States Patent: D670713
Appleが先週、電子書籍において紙の本のようにページをめくるアニメーションのUIに関する特許を取得したそうだ。提出日は、2011年12月19日付けになっている。はて、この手のページめくりUIはかなり前からあったような気がするのだが。
発明者は、Elizabeth Caroline (San Francisco, CA), Inose; Mikio (Cupertino, CA), Lemay; Stephen O. (San Francisco, CA)となっている。
アメリカの特許の壊れっぷりは限界を知らないらしい。
LenovoのUEFIのアホくさい実装
mjg59 | More in the series of bizarre UEFI bugs
UEFI自体の問題ではなく、実装の問題。
なぜかLenovo Thinkcentre M92pをUEFIモードにして使うと、インストールしたFedoraがブートできない。インストールは可能だが、なぜかブートできない。Windowsは正しくブートする。
Windowsのブートエントリと比較してみても、なぜか違いがわからない。最終的に、Windowsのブートエントリを変更してみることにした。するとWindowsのブートにも失敗した。
変更箇所は、ユーザーにブートメニューを表示する際の項目名。なぜか。"Windows Boot Manager"でなければブートしない。しかし、この項目はファームウェアがパースすべき部分ではない。なぜここが影響するのか。しかし、この現象は、ファームウェアがブートエントリの項目名をパースしているとしか思えない。
ファームウェアをダウンロードして解析してみると、まさにこのとおりだった。Lenovo Thinkcentre M92pのファームウェアは、ブートエントリの項目名をパースするようになっていた。そして、特定の項目名でなければブートしないようになっている。興味深いことに、Windowsだけではなく、Red Hatも通すようになっていた。しかし、当然ながら、Fedoraは通さない。
一体どこのアホがこんな実装にしたのだ。
ハードウェアとそのファームウェアには、相当に多くのバグがある。主要OSはその尻拭いをさせられているのだ。たとえば、あるマザーボードでは、OSに処理を明け渡した後も、特定のメモリ領域に読み書きをするなどだ。そのような場合、OS側で個別に汚いハックを用意し、このマザーボードはクソなので特定のメモリ領域にアクセスしないように特別なはからいを設けなければならない。
この問題はPhoronixの該当記事のフォーラムでも議論されているが、なかなか興味深い。
Lenovo UEFI Only Wants To Boot Windows, RHEL
Microsoftはこの手のバグが出ることが分かっているから変な規格を提案するんだという意見まである。というのも、Microsoft Windowsなら、たまたまバグに引っかからず動作するから問題ない。他のOSのことなんて知るものかというスタンスで、事実上MS以外のOSの動作を妨害しているという意見だ。まあ、ハンロンの剃刀なのか邪悪なのかは知らないが。
2012-11-14
観測史上最も高速な質量を持った粒子は、オーマイゴッド粒子と呼ばれている
Oh-My-God particle - Wikipedia, the free encyclopedia
このオーマイゴッド粒子は、1991年にユタ州で高エネルギーの宇宙線として観測された。ひとつの亜原子粒子に野球ボール（時速100kmで移動する142gの質量を持った物質）ほどの運動エネルギーがあると推定されている。
その速度は、なんと0.9999999999999999999999951cだと推定された。光とこの宇宙線を一光年競争させた場合、たったの46ナノメートルしか遅れない事だ。あるいは、0.15フェムト秒遅れるとも言える。
これが人類の観測史上、質量を持つ最も早い粒子の観測例である。
Old New Things: Raymond ChenによるMicrosoft Moneyの非公式パッチ
私も昔はx86アセンブリにハマっていたものだ。今やすっかり忘れてしまったが。内容は、まあ何もそれほど複雑というわけでもない。
ところで、この記事のボーナスチャプターが面白いので紹介する。
ボーナスチャプター：このパッチを友人に見せた時、このパッチは退職した同僚のJeffを思い出すという話をした。Jeffはとんでもないプログラミング作業を暇なときにやってのけるのだ。彼の部屋に助けを求めに行くと、何か今まで見たことのないプログラムを起動し始めた。
「何だそれ？」と聞くと、
「ああ、これは俺の書いたデバッガーさ」と何気なしに答える。
あるいは、あるプログラムを渡して申し訳なさそうに、「すまん、x86用にしかコンパイルしてないんだ。Alpha版はないよ」
「いいよ、俺のエミュレーターで動かすから」と当然のごとく答える。
（Microsoftを退職した後も衰えることはなかった。彼のJavaScriptで書かれたIBM PC Model 5150エミュレーターを見よ。）
私が言ったこととは、「Jeffみたいだな。誰がこんなことをモーニングコーヒーの前にやってのけるというんだい」
Jeffによる訂正、「俺がコーヒーの前になにかしているとするならば、それは徹夜でやっていたのだ。集中 >= 才能」
2012-11-13
誤爆、あるいは不自由なソフトウェアを使った報い
ある不自由なiOS上で動く不自由な辞書ソフトウェアに、海賊版を検知して、
"How about we all stop using pirated iOS apps? I promise to stop. I really will. #softwarepirateconfession"
「iOSアプリを海賊して使うのはやめないか。俺は辞める。絶対辞める。#ソフトウェア海賊の懺悔」
というtweetを流す機能が搭載されていたようだ。
問題は、この機能が大いに誤爆して、真当に買った人間も影響を被っている。
海賊行為の有無にかかわらず、このような挙動は邪悪である。不自由なソフトウェアを使った報いとも言える。なぜならば、不自由なソフトウェアでは、ソフトウェアの挙動を検証する自由がないからだ。
これを契機に、早く皆が自由なソフトウェアの価値に目覚めればいいのだが。
そもそも、自由なソフトウェアに海賊などは存在しない。ソフトウェアの共有は正しいことであり、犯罪ではない。正しいことを、船を襲う犯罪行為と同等にみなすのは邪悪なレッテル貼りである。
我々は、ソフトウェアの共有を妨げる不自由なソフトウェアを使ってはならないのだ。
ハワード・ヒューズが人生がキチガイすぎる
Howard Hughes - Wikipedia, the free encyclopedia
Hughes H-4 Hercules - Wikipedia, the free encyclopedia
モルモンの遺言書で有名だが、生前もキチガイすぎる事業ばかりやっていたようだ。
VMwareにも男性社会的な定数が発見される
以前、マイクロソフトが、LinuxカーネルをHyperVでサポートするパッチに、定数として0xB16B00B5を使っていたことが、物議をかもした。これは、BIG BOOBS（デカパイ）と読める。
Linux開発者の中でフェミニズムの第一人者として知られているMatthew Garrettなどは、特に強く抗議した。
ソースコード中で、定数としてユニークな数値が必要であるが、数値自体はどうでもよい場合、かといって、0とか1などといった簡単でよく使われる数値は避けたい場合、プログラマーは大抵、面白い数値を考えだすものだ。hex speakで解釈したり、ASCIIで解釈すると単語になるような数値だ。
「プログラマーというのは、いまだに高い割合で男が占めており、そのために強い男性社会の特徴が現れ、けしからん。このような男性社会的な定数を選択したことは、その顕著たるものである」というのが、フェミニズムプログラマーの主張だ。
マイクロソフトはこの批判に応じて、ソースコード中の定数を記述するリテラルを、16進数リテラルから、10進数リテラルの2976579765に変更した。
さて、そのMatthew Garrettであるが、同じ問題をVMwareをLinuxカーネルでサポートために提供されたソースコードにも発見したらしい。
mjg59 | VMware are as bad as Microsoft
git.kernel.org - linux/kernel/git/torvalds/linux.git/blob - drivers/net/vmxnet3/vmxnet3_defs.h
VMwareは有名なエミュレーターであるが、LinuxカーネルをVMware上で動作するように対応するため提供されたソースコード中に、
#define VMXNET3_REV1_MAGIC 0xbabefee1
なる行がある。0xbabefee1は、明らかにbabe feel（感じるネーチャン）と読める。
それにしても、HyperVといいVMwareといい、どちらも仮想化ソフトウェアである。仮想化ソフトウェアの開発者が特別に卑猥なhex speakを好むと言うよりも、ある特定のハードウェアをエミュレートするより、直接OSにドライバーを提供したほうが都合がよく、しかしmainlineで取り入れられるためにはGPLv2であることを要求するLinuxの存在があり、市場規模からしてもLinuxは無視できないためにソースコードを提供し、たまたま表に現れているだけなのだろう。
MicrosoftやVMwareのような、基本的に不自由なソフトウェアを開発する、堅そうな大企業にあっても、そのような文化が失われないのは興味深いことだ。おそらく、プログラマーとしての能力は、ユーモアの有無に左右されず、他の職業のようにユーモア欠落症に陥ることがなく、また、プログラマー文化としても、ユーモアを大いに推奨しているために、このようなことが起こるのではないか。
しかし、これまでのLinuxカーネルやGNUにおいて、こういった話は聞いたことがない。MicrosoftやVMwareのような、基本的に不自由なソフトウェアを開発している企業が、にわかに自由なソフトウェアに貢献しだすと発覚する。思うに、不自由なソフトウェアを開発する企業では、ソースコードを検証する人間が限られているために、このようなことが起こるのではないか。自分と直接関係ないソースコードを読む人間はすくない。しかし、社内のみの公開と、全世界への公開では、全世界への公開のほうが、全く関係のない人間によって読まれる可能性が上がるために、発覚するのではないか。
2012-11-11
また体のかゆくなる季節がやってきた
またも、一年ぶりに体のかゆさに悩まされた。
毎年冬になると、多少の温度変化で体がかゆくなる。食事や運動のたびに体がかゆくなるし、外に出てもかゆくなる。一時間もしないうちにおさまるのだが、とにかくかゆくて仕方がない。
ネット上には、「冬は体が乾燥するからかゆくなるのだ」とか、「冬に体を洗いすぎると痒くなるのだ」とか、「温度や汗に反応する蕁麻疹の一種だ」などといろいろ書かれているが、とにかくかゆい。
しかも、症状は年々ひどくなっているように思われる。何とかならないものか。
UTC(協定世界時)は何の頭文字か
ふと、UTC(協定世界時)は何の頭文字なのか気になった。そこで調べてみると、なんだか面白い理由でUTCに決まったことが分かった。
協定世界時の略語を決定する際、すべての言語で共通の略語にする同意がなされた。GMT(グリニッジ標準時)は、定義が曖昧で、非公式にはUTCと同じ意味で使われていたものの、真面目な文章では避けられていた。そこで、英語圏は、"Coordinated Universal Time"の頭文字であるCUTを提案した。一方フランスは、"Temps Universel Coordonné"の頭文字であるTUCを提案した。結果として、UTCとなった。UTCは、UT(Universal Time)とも似ているので、都合が良かった。
2012-11-07
Microsoftが見張っているぞ(Microsoft is watching you!)
Microsoft Patent Lets Hollywood Watch You with Camera
Microsoftが申請した特許に、キネクトなどのカメラを使って、視聴者の挙動を監視し、コンテンツの提供をコントロールするものがある。
例えば、一人用にライセンスされたコンテンツに対し、カメラが二人の人間を検出したならば、コンテンツの提供を停止し、追加のライセンス購入を促すような機能が、特許で説明されている。
1984の世界が現実になろうとしている。
Microsoft is watching you!
DOWN WITH MICROSOFT
DOWN WITH MICORSOFT
DOWN WITH MICROSOFT
2012-11-06
2012-11 post-Portland mailingの簡易レビュー
ISO/IEC JTC1/SC22/WG21 - Post-Portland mailing 2012-11
Post-Portland mailingが公開されている。最新のドラフトはN3485。今回はだいぶ変更が加えられているが、いずれも文面の修正や表現の統一 であり、極端な変更はないようだ。
今回は、ペーパーとしては公開されていない、会議前のペーパーに対する議論も紹介してみようかと思う。
N3386: Return type deduction for normal functionsには、少々の落とし穴もあるようだ。
再帰で戻り値の型を推測するには、型を推測できるreturn文が字句的に先行していなければならないそうだ。
存在を憂いていた、N3398: String Interoperationには、案の定、問題が噴出している。
結局、C++11でUTF-8リテラルを導入したのに、UTF-8型を導入しなかったのが問題なのだ。意見しても、C++の思想として、型は文字エンコードを表現しないという反論でそのままになった。
そしていま、UTF-8のライブラリ側での取り扱いをめぐって問題が起こっている。それみたことか。
実際、UTF-8リテラルと通常の文字列リテラルの型が同じだというのは、非常に問題がある。たとえば、UTF-8文字列リテラルを書こうとして、プレフィクスu8を書き忘れてしまったならば、通常の文字列リテラルとしてエンコードされてしまうが、その問題はコンパイル時に検出できない。同じ型だからだ。UTF-8文字は独自の組み込み型を与えられてしかるべきだったのだ。
std::stringは暗黙にUTF-8とみなしていいんじゃないというぶっきらぼうな意見まで飛び出す始末。その方が楽になるのだが。
N3405: Template Tidbitsも、注目していた。
template < typename T t >
というテンプレート仮引数の宣言で、任意の型の非型テンプレート実引数を受け取れるようにしようという提案である。
議論の結果、コンパイラー開発者から、elaborated type specifierと文法が曖昧になる問題を指摘された。解決には文法の変更が必要になる。
会議の場で仮に提案された文法は、
template <auto<class T> T n>
というものだが、これは見た目に分かりにくい。ただし、非型とその型の仮引数名を記述できる。
別の提案としては、
template <auto m>
というものがある。これは見た目に簡単だが、これで名前を付けられるのは非型だけで、非型の型を得るには、メタ関数を使わなければならない。
どちらも一長一短で賛成しがたい。さらなる議論と発想が必要であると思う。
N3444: Relaxing syntactic constraints on constexpr functionsはどうか。
「許可されている機能のリストなどというのは気に食わない。costexpr関数でもループ構文が使えるべきだ」などという主張もなされた。Stroustrupなどは慎重派で、現行のconstexpr関数の制限を緩めるには、相当の理由を提示すべきだと主張した。そこで、いろいろな利用例や具体的なコードが示された。結論としては、少なくとも提案されているだけの制限の緩和はするべきだろうという意見になった。
N3332とN3329のstatic ifであるが、Stroustrupは導入に慎重なのが以外だった。問題は、static ifのような簡単なコンパイル時条件分岐を導入してしまうと、必要以上に多用されるだろうということだ。それでも、現行のテンプレートメタプログラミングよりは簡単で、メタプログラミングの門戸を開くことにつながるだろうという肯定的な意見も出た。
モジュールについては、現行のドラフトを元に、Clangで実装が進められているとのこと。
特に興味深いものだけを取り上げたが、これ以外の本の虫: 2012-09 pre-Portland mailingのあまり簡易ではないレビューで取り上げたペーパーについて、会議の概要を知りたい人は、知らせてくれればあとで書く。
さて、今回のペーパーの簡易レビューといこう。
N3456: Range arguments for container constructors and methods, with wording
Range復活。
皆が待ち望んでいたあのRangeが戻ってきた。コンセプトなしの提案だ。
RangeがC++11に導入されなかったのは悲劇だった。もちろん、あのままコンセプトを取り入れていても、取り返しのつかない問題になっただろうが。
もっとも、規格に入るのはRangeという要求だけで、BoostにあるようなRange adaptorは入らない。しかし、Range adaptorとともに使うこともできる。ペーパーでも強調して使うことが想定されている。
N3457: Algorithm std::iota and its modifications.
ひどいHTMLコードを見た。まあ、メールでのやりとりをそのままペーパーにしたので、メールを正しく表現するには当然pre要素を使うべきなのだろうが、しかしこれは・・・。
まあともかく、内容は、std::iotaを変更するというものだ。すでにあるstd::fillのスタイルに合わせて、iotaを似せるべく変更する。
しかし、くどいようだが、iotaは名前が符丁のようでわかりにくい。このようなギーク的な命名はどうかと思う。それこそ、incremental_fillとでもしておけばよかったのではないか。私は、タイプ数を減らすよりも分かりやすい名前を好む。まあ、今更言っても始まらない。
N3458: Simple Database Integration in C++11
PDFは死滅せよ。
既存のデーターベース操作のAPIは非常に汚い。たとえば、以下はODBCのコード片である。
SQLHandle statement ;
SQLAllocHandle (SQL_HANDLE_STMT, cconnection ,& statement ) ;
SQLPrepare ( statement , " select a , b from foo where c=? and d=?" , 38 ) ;
SQLLen len1 =3;
SQLBindParameter ( statement , 1 ,SQL_PARAM_INPUT,SQL_C_CHAR,SQL_VARCHAR, len1 , 0 ,
" foo " , len1 ,&len1 ) ;
SQLINTEGER val =1234; SQLLen len2=sizeof( val ) ;
SQLBindParameter ( statement , 2 ,SQL_PARAM_INPUT,SQL_C_SLONG, SQL_INTEGER, len2 , 0 ,
&val , len3 ,& len2 ) ;
SQLExecute ( statement ) ;
while ( SQLFetch ( statement )==SQL_SUCCESS) {
double a , b ;
SQLGetData ( statement , 1 ,SQL_C_DOUBLE,&a , 0 , 0 ) ;
SQLGetData ( statement , 2 ,SQL_C_DOUBLE,&b , 0 , 0 ) ;
cout << a << " " << b << endl ;
}
なんとも残念なコードではないか。ODBCはC bindingであるために、多くのボイラープレートなコードを必要とする。さらに、データベースのインターフェースは、関数呼び出しとして提供されている。さらに、コードは動的片付けであり、コードとクエリー結果の結びつきも貧弱である。
そこで、もっとC++らしいAPIを提案する。提案では、上記と同等のコードが、以下のように書ける。
prepared_queryps=conn.prepare_query( " select a , b from foo where c=? and d=?" ) ; double a , b ; for ( auto row : ps ( " foo " , 1234 ).into ( a , b ) ) cout << a << " " << b << endl ;
何とすばらしく簡潔に書けることか。
N3459: Database Access Comparison
実際にアメリカで使われている郵便システム(オラクルのproprietaryな言語であるPL/SQLで書かれている)のコード片を、C++で提案されているデータベースライブラリで書き換えた例。実際のコードは原文を参照すること。
不自由なプログラミング言語はけしからん。
N3462: std::result_of and SFINAE
std::result_ofをSFINAEでも引っかかるようにする改良。詳細は前回解説した。
以下の内容のソースファイルには、移植性の問題がある。
int main() { }
なぜか。それは、ソースファイルの文字のエンコードが規定されていないからである。そのため、このソースファイルをあらゆる環境でコンパイルするためには、環境に合わせたエンコードの変換を行う必要がある。
このために、Boostのソースファイルは、いまだに©などの文字を使えないし、開発者の名前も正しく表記できない。
のみならず、環境が対応していない可能性のある文字は、ユニバーサル文字や代替文字やトライグラフを使わなければ、新に移植性の高いソースファイルとはいえない。
いいかげんにせい、もう2012年なのだUTF-8エンコードされたソースファイルへの対応は義務である。
というわけで、C++1yの実装は、少なくともUTF-8エンコードのソースファイルを受け付けなければならないようにしようという提案。
これは至極当然の提案だ。
また、バイトオーダーマーカーである0xEFBBBFも受け付けることを義務付ける。Unicode Technical Committeeは、「0xEFBBBFバイトオーダーマーカーの有無は規格準拠のUTF-8であるかどうかの判断に左右しない」と言っている。しかし、0xEFBBBFは空白文字なのだから、真にUTF-8対応のソフトウェアは、空白文字として扱うべきなのだ。
N3465: Adding heterogeneous comparison lookup to associative containers for TR2 (Rev 2)
すまん、よく分からん。
内容としては、2001年にDave AbrahamsがN1313: Binary Search with Heterogeneous Comparisonで提起した問題が、連想コンテナではいまだに修正されていないので、修正するというものだ。
その問題というが、残念ながら数学的にチャレンジドな私の頭では理解できない。いわゆる比較関数がstrict weak orderingかどうかという問題なのだが。
N3466: More Perfect Forwarding
threadやbindは、実引数をリファレンスで取らない。
void f(int &i) { i = 2; /* ... */ }
int i;
f(i); // iはリファレンスで渡される
thread tf = thread(f, i); // iはリファレンスで渡されない
これは、テンプレートの実引数推定がそうなっているためだ。
しかし、だからといって単にthreadやbindの実引数をrvalueリファレンスで取ればいいというものではない。取ったとしても、正しくforwardingできないのだ。関数オブジェクトの仮引数の型を取得する方法がないからだ。
そのため、仮引数の型を取得できるコンパイラーの支援のメタ関数、std::signatureを追加する提案。
これはいわゆるコンパイル時リフレクションの一種だ。よりパーフェクトなforwardingができるようになる。
N3467: Runtime-sized arrays with automatic storage duration
動的に大きさを指定できるautomatic storage durationの配列を追加する提案の改良案。
細かい変更に留まるので特に説明しない。ヒープ上に構築できるようになったのは大きいかもしれない。もっとも、見逃していただけなのだが。
N3468: User-defined Literals for Standard Library Types (version 2)
標準ライブラリにユーザー定義リテラルを追加しようという提案の改訂版。
さすがに、二進数リテラルをユーザー定義リテラルというライブラリとして提供するという提案は、コア言語の領域だということで、コア言語グループに投げられた。また、コンパイル時atoiとして提供するという代わりの提案も却下された。汎用的なコンパイル時atoiなど提供できるわけがない、というのがその理由だ。
Constexpr Library Additions v3: chrono
Constexpr Library Additions v2: containers
Constexpr Library Additions v3: utilities
既存の標準ライブラリをconstexpr対応にする些細な変更。
N3472: Binary Literals in the C++ Core Language
PDFは死滅せよ。
コア言語で二進数リテラルを追加する提案。プレフィクスは0b/0Bになる予定。すでにGCCやClangで拡張機能として実装されており、またJavaやDなどといった他の言語でも実装されているので、実装経験は豊富であり、入るとすれば問題なく入るだろう。
数値リテラルのセパレーターについては、この提案では考慮せず、別の独立した議論である。
N3477: C++ Internet Protocol Classes
PDFは早く死ね。
もはや、C++にも標準のネットワークライブラリを考慮しなければならない時代になっている。この提案では、ネットワークの中でインターネットを取り上げ、その中でも特に、IPアドレスに関するライブラリについて提案している。このライブラリの設計は、有名な既存のネットワークライブラリであるPOCOを元にしている。
N3478: Core Issue 1512: Pointer comparison vs qualification conversions
この提案では、ポインターの比較について変更を加える。
提案では、以下のコードをill-formedにする。
void f(char * p)
{
if (p > 0) { ... }
if (p > nullptr) { ... }
}
また、以下のコードはwell-formedにする。
void g(int **p1, const int**p2)
{
if (p1 == p2) { ... }
}
N3479: Priority Queue, Queue and Stack: Changes and Additions
PDFは滅せよ。
std::priority_queueの改良案。実装のオプションをコンパイル時にテンプレート実引数として指定できる。
イテレーター、値の変更、マージの効率化、安定ソート、比較。
C++標準のネットワークライブラリとして、URIに特化したライブラリの提案。
PDFで構築した視覚効果激しいプレゼン用の画面集をペーパーとして公開するのはやめようぜ。
TLS(Thread Local Storage)は、C++11にもthread_localというキーワードと、thread storage durationという形で取り込まれたが、この機能は現実の三種類の利用例に一致していない。三種類の利用例に一致するTLSを、言語なりライブラリなりで提供すべきであり、現行のthread_localは、この三種類のうちの利用例のどれかに一致するように変更しようという提案。
どうも中身がない気がする。
N3489 - A Rational Number Library for C++
C++に標準の有理数ライブラリを追加する提案の改訂版。議論の末、改良を加えた。
N3490: Controlling Argument-Dependent Lookup
title要素のないHTMLはill-formedでありけしからん。
これはDaveはんの提案なんやな。この人昔から、ADLを無効にする方法を追加しよう言うてはるんや。
この提案では、ADLを無効にする方法を追加する。特に、演算子以外のADLを向こうにする方法を追加する。ADLが最も必要とされるのは、グローバル以外の名前空間スコープの型に対する演算子のオーバーロードなのだから、演算子以外でADLを無効にする機能が欲しい。さらに、演算子も含めてADLを完全に無効にする機能も提案している。
さらに、一部の名前だけ、宣言されたスコープ内においてADLを有効にする機能も提案しているが、これはすでに用いられてきたusing宣言のトリックと非常によく似ている。
N3492: Use Cases for Compile-Time Reflection (Rev. 2)
外道祭文。PDF地獄。スカラカ、チャカポコチャカポコチャカポコチャカポコ。
コンパイル時リフレクションの利用例を紹介したペーパーの改訂版。さらに利用例が増えているようだ。
Serializationなどのリフレクションを必須とする利用例を始めとして、enumの情報取得や、デフォルト実引数の取得など、なにやら面白い利用例も上がっている。ある関数オブジェクトを完全にラップするためには、デフォルト実引数をコンパイル時に取得できることが必要になるのは、言われてみれば当然だが。
2012-11-03
リーナス・トーバルズ、再びKDEに切り替える
Linus Torvalds - Google+ - I'm trying out KDE after a long absense. It still looks a…
以前、GNOMEやKDEを嫌ってXfceに走ったリーナス・トーバルズであるが、また再びKDEに戻ってきたようだ。
久しぶりにKDEを試している。
まだちょっとマンガみたいで、デフォルトのウィジェットとplasmoidにマウスを合わせた時、即座にコントロールを表示するのが超いらつく。ウィジェットをロックすれば、落ち着いたまともな挙動になる。これがデフォルトの挙動なのは変だろ。
まあでも、設定できるわけだ。いまだにウインドウが落ち着かないな。
GNOMEの連中がKDEは設定できることが多すぎるだろと考えるのは分からないでもない。「何でも設定できるぜ」ってのはちょっと変だしな。
たとえば、デスクトップウィジェットを好きなように回転できるとかさ。「このウィジェットコントロールバーの変な回転はなんだろ。うーむ、なんだか目が回ってきた」
結果として、今、俺のターミナルとWebブラウザーのボタンは酔いどれデブがデスクトップ上で暴れまわったみたいになってる。まあ、いずれ退屈に上部に並べて表示するとしよう。（まあ、俺はそういう退屈な配置をするのだから）。まあでも、とりあえず今はこの不安定な挙動を楽しむとするか。
KDEのデフォルトの設定のいくつかが、デフォルトで設定されているべきではないだろと不満たらたらながらも、とりあえずしばらくKDEに戻ることにしたらしい。
Xfceの欠点については一切言及していない。
さあ、宗教戦争の始まりだ。
2012-11-01
高PPIディスプレイへの対応の難しさについて
高PPIディスプレイへの対応は難しい。というのも、既存のソフトウェアは勝手に書き換わってくれないし、ましてや今から新しく書くのであっても、ライブラリは既存のものを使うので難しい。
未だに、低レベルなAPIでは、多くのディスプレイ上のUIの大きさを、ピクセル単位で指定する。
フォントには、ポイントという単位がある。これは歴史的な単位で、1ポイントは約0.3514mmである。
もっと高レベルな実装でも、あまり問題は変わらない。たとえば、CSSで長さを指定する単位には、いまだにピクセルが存在する。
なぜ、ピクセル数で長さを指定すると問題になるのかというと、ピクセルの大きさが、環境ごとに違うからである。
最新の携帯電話の画面のピクセルの大きさは極めて小さい。屋外に設置する巨大なディスプレイなどは、ピクセルが大きい。
したがって、10ピクセル分の長さというのが、環境ごとに異なる。
伝統的に、1ピクセルあたりの大きさを言うよりも、1インチあたりにピクセルを何個敷き詰められるかという表現をする。また、印刷からの伝統で、ピクセルではなくドットという呼ばれ方もする。DPIとは、Dot Per Inchの頭文字なのだ。インチのような劣った長さの単位は、今やアメリカやイギリスのような劣等国しか使わないが、慣習的に使われている。
現在、デスクトップ向けのディスプレイでは、96PPIのディスプレイが非常に多い。96PPIとは、1インチあたり96個のピクセルを並べることができるという意味である。
さて、96PPI環境において、ラテンアルファベットは、12ピクセルあれば十分に表現可能であると感じたとする。96PPI環境での1ピクセルは265マイクロメートルなので、12ピクセルは約3ミリメートルになる。これが文字の大きさだ。
さて、携帯電話やタブレットのような小さなディスプレイでは、もはや300PPIも珍しくない。300PPI環境で真面目に12ピクセルで文字を描画すると、文字の大きさは約1ミリメートルになる。これでは読めない。
したがって、正しいソフトウェアの実装方法は、文字を「3ミリメートル」という論理的な長さで描画するということになる。問題は、低レベルなAPIの実装は、フォントサイズをメートルで指定することはできないので、ソフトウェアごとに変換をしなければならない。つまり、実行環境のPPIを何らかの方法で特定して、3ミリメートルは何ピクセルになるのかを計算しなければならない。
さらに問題なのは、多くの環境で、ディスプレイのPPIを取得する方法がない。それに、PPIの違う複数のディスプレイを使っている可能性だってある。
ところで、CSSではピクセル単位で長さを指定することができる。例えば、ブラウザーがCSSの指定を尊重したとすると、以下の文字は12ピクセルで描画される。
この文字列は12ピクセルで描画される。
さて、このページをプリンターで印刷したらどうなるだろうか。プリンターは、個人向けの安いものでも、1000DPIを超える。実質のピクセル数でも、やはり300PPIはある。このページをプリンターで印刷すると、上記の文字列は読めないほど小さく印刷されるのだろうか。
実際には、主要なブラウザーの実装では、印刷の際にCSSのピクセル数指定に従うことはない。主要なブラウザーは、固定のあるPPI(たとえば96とか)においてピクセル数が指定されたという扱いをする。そのため、プリンターの実PPIに合わせて適切にスケールされるのだ。
WindowsなどのOSでも、この戦略を使っている。ピクセル数指定は、あるPPIにおいて指定されたピクセル数だとみなし、実際の環境のPPIに合わせて、まるごとスケールするようにしているのだ。Windowsの場合、ソフトウェアが明示的にスケールを無効にするAPIも用意されている。明示的に無効にしない場合、自動的にウインドウごとスケールされる。
なんといっても、今のソフトウェア実装は、歴史的な設計の問題により、複数の極端にPPIが違うディスプレイが使われるという状況に対して、あまりうまく動かない。
ここまでは、ベクトルデータであるフォントを描画する際の問題だ。ベクトルデータではない画像は、もっと問題になる。
画像のピクセル数が十分に多ければ、優秀なスケーリングアルゴリズムにより、綺麗にスケールは可能だ。しかし、96PPI環境において使われることが想定されている数十ピクセル程度の大きさのアイコンなどは、どうしようもない。
理想的には、アイコンのような小さい人工的な画像は、すべてベクトルフォーマットにすべきである。実風景を写した写真などは、できるだけ高解像度にして、優秀なスケーリングアルゴリズムを使うべきだ。
といったところで、世の中は簡単にベクトルフォーマットを使うようにはならない。コンピューターの性能やストレージ容量は、いまだに有限である。
まだまだ時間がかかる。
映画アルマゲドンででてきた、BB銃で電車を止めるたとえの考察
映画アルマゲドンで、NASA職員は隕石をレーザーで撃つことに対して、「電車をBB銃で止めるようなものだ」と言っている。暴走電車をBB銃だけで止める場合、どうなるのか。
--Charles James O'Keefe
まず明言しておくと、隕石をレーザーで撃って防ぐのは、すばらしい方法である。電車をBB銃で止めるのは難しい。
Red Ryder spring-priston レバーアクション空気銃は、標準規格の0.177キャリバー、0.33gの鋼鉄BB弾を、秒速100メートルの速度で発射できる。
GE Genesis シリーズIの電車の重さは、12メトリックトンであり、秒速45メートルで移動する。
一発のBB弾を電車の真正面に打ち込むと、日速30cmほど速度を減じることができる。
電車を止めるには、秒間1発において、およそ二日と20万発のBB弾がかかる。その時には、すでに電車は勝手に止まっているであろう。（このページによる電車にかかる抵抗の計算式による。机上の計算では、時速160キロから時速32キロまで、10分から15分で減速することになる）
明らかに、Red Ryderでは力不足だ。
エアガンオタクですら恐れるような世界的に強力なものを使うべきだ。
Tactical Edition Blackbirdは、ハイエンドBBマシンガンである（世の中にはBBマシンガンというものがあるのだよ）。一分間に1200発も発射でき、発射速度は秒速200メートルを超える。この速度では、標準BB弾で骨折させることができる。
残念ながら、一瞬で電車の真正面から600発を撃ち尽くしたとしても、わずかにしか減速しない。
一人がBB銃で止められないのなら、人を増やせばいいのではないか？
一人あたりに横60cm縦120cmの面積を割り当てる。少々混み合っているが、これにより、他人の肩越しに射撃が可能になる。電車の前方の両サイドに対し45度で配置するようにしたのならば、10メートルで100人、20メートルでさらに300人、30メートルでさらに550人、40メートルでさらに750人を追加で詰め込める。
ほとんどの射手は、電車を正しく狙撃できるだろう。射撃角度の違いを考慮して計算すると、理想の配置（すべての銃が電車の真正面に配置されているもの）にくらべて、90%以上の効率を持つ。
BB弾には強い抵抗がかかる。そのため、遠くから撃たれた弾は、電車に衝突する速度が遅くなる。このページでは、様々な速度で移出されたBB弾のうける抵抗を推定している。インターネットはすばらしい。
これらのことを念頭に、集団でBBマシンガンを撃って電車を止める場合をみてみよう。ところで、人間には腕が二本あるので、一人あたり二丁割り当てることにしよう。
t=0において、電車から50メートル圏内にいる、2500人の人員が、引き金を引き、秒間10万発のBB弾が発射される。電車の前進に合わせて、真正面に配備された人間は魔法のように線路から左右によけるものとする。これは非現実的だが、人間の体をつかって電車の減速させるのはインチキなのでできない。
最初の人員が発砲をやめるとき、さらに後ろに控えている人員が射程に入り、発砲をはじめる。電車はとても早く動いているので、電車が過ぎ去るまえに、一人あたり数十発しか当てることができない。
任意の瞬間において、4万5千発のBB弾が空中に存在することになる。これは問題がある。鋼鉄球が電車の前で跳ね返った時、単に消え去ることはないからだ。射手の方へ跳ね返り（射手の目にあたるかもしれない）、射線に入るのだ。最大で、この反射した跳弾は、1%近い弾を、BB弾同士の衝突により、阻害する。これは好ましくない効果だが、作戦の遂行にあたっては、それほど問題にはならない。
残念ながら、この鋼鉄の雨でも、電車の停止には数分かかり、距離にして数キロメートルを必要とする。これはつまり、10万人の射手を線路沿いに配備しなければならないということであり、必要な費用は5000万ドルに上る。
もっとマシな方法があるはずだ、BB銃を使うという前提を、少しやわらげてはどうか。
AK-47の発射速度は秒速715メートルであり、発射される弾はBB弾の25倍重い。弾の速度が早すぎるため、電車を貫通してしまう（これは、運動量を伝えるのが非効率的であるということでもあるが、特に問題にはならない）
計算によれば、2500人の人員がそれぞれ二丁のAK-47を発砲すれば、距離にして30メートル、時間にしてわずか1.5秒で電車を止めることができる。作戦成功。
もっとやればどうなる？
うーん。
マシンガンの弾は、鋼鉄球にくらべて、受ける抵抗が少ない。つまり、より長距離からの狙撃を可能にする。50メートルではなく、200メートルの範囲にしてみよう。
t-0において、4万人の人員が一斉に発砲する。通常、AK-47は30発のマガジンを使い、秒間10発ほど発射する。0.3秒ほどで、25万発の弾が空中に舞う。狙いの外れた弾が前方の人員を撃ちぬくのは疑う余地がないが、よく訓練された狙撃手ならば、大部分の弾は、的に当たるだろう。
t=15ミリ秒において、電車が50センチメートル前方に進み、弾幕の先頭を浴びることになる。
t=30ミリ秒では、電車は1ミリ秒あたり数十発の弾を受けることになる。
t=150ミリ秒において、電車は前方に6メートルほど進むが、1ミリ秒あたり数百発の弾を吸収する。これにより、前進する運動量が減少し始める（そして粉々になるだろう。ここでは、弾は衝撃を均等に分散する特殊な材質を使っていると仮定しよう）
t=300ミリ秒において、25万発の弾が空中に存在することになる。ほとんどの射手は、二丁あわせて6発ほどの弾を発射している。前列で撃った弾は、後列で撃った弾と衝突することもある。頻繁には起こらないが、確実に起こる。
電車は7メートル前方に移動し、7メートル半になり、7メートルと3/4進み、そして7メートル半に戻る。
成功だ。
しかし、射手はまだ十数発しか打っていないのだ。マガジンにはまだ弾がほとんど満タンで残っている。
t=1秒において、100万発の弾が発射される。電車は後方に、およそ秒速100メートルで押し戻される。t=2秒において、電車の後方への加速は減少する。これは、電車が射手の射程外に移動するためでもあるが、電車が音速に近い速度で移動しているためでもあり、弾が電車に追いつきにくくなるのだ。追いついたとしても、相対速度がほとんど変わらないので、それ以上加速させることができない。
この時点では、空気抵抗が電車にあたえる力が最大になる。電車の後方が浮き上がり、電車は脱線しだす。そして最終的には、弾幕により粉々になる。
さて、隕石に適用しよう。
「隕石をレーザーで撃つなんて、電車をBB銃を撃つようなもの・・・」
「めちゃくちゃカッケーぞ」
Ubuntu 13.04はLinuxカーネル3.8を目指す
[Phoronix] Ubuntu 13.04 To Target The Linux 3.8 Kernel
2013年の4月にリリースされる予定のUbuntu 13.04は、Linuxカーネルの3.8の採用を目指しているようだ。現在の予定では、Linuxカーネル3.8は2013年の3月半ばにリリースされる予定であるので、ぎりぎり間に合う算段になる。
EXT4のバグが修正された
[Phoronix] The EXT4 Corruption Bug Is Fixed
git.kernel.org - linux/kernel/git/torvalds/linux-2.6.git/commitdiff
LWNやPhoronixやSlashdotで話題になった、ext4のデータ損傷バグの原因を修正。
このバグは、非標準のマウントオプション（journal_async_commitやjournal_checksum)が有効にされて、ファイルシステムが正しくアンマウントされなかった時にしか、発現しない。原因は、inodeビットマップ変更が正しくジャーナルされていなかったからだ。
これにより、変で運が悪かったワークロードの時における、正しくないシャットダウンが行われた場合、些細なファイルシステムの損傷が起こる。ただし、journal_checksumやjournal_async_commitが有効にされている場合は、深刻な損傷になる。