本の虫

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

2012-02-03T05:10:00.001+09:00

Why History Needs Software Piracy | PCWorld

SOPAとPIPAのような反海賊法を巡っての議論において、我々の関心は、主として現代と近未来に置かれがちである。職と利益に対する被害に対しては、今日、誰が被害をうけるのかということに着目しがちである。

ここでひとつ、ソフトウェア海賊に対して、別の視点からの関心ごとを述べてみようと思う。未認可のソフトウェアの複製が、短期的にみて、いくらかの商業的利益を損ねることに疑いはないが、ここで一歩下がってみると、すこし違った状況が見えてくる。歴史的に考えると、ソフトウェア海賊のもたらす利益は、短期的な損失を大幅に上回っているのだ。もし、技術史を気にかけるのであれば、許諾なくソフトウェアをコピーする連中がいることに、感謝しなければならないのだ。

一件奇妙に聞こえるかもしれないが、海賊が救ったソフトウェアの数は、破壊したソフトウェアの数より多いのだ。すでに、海賊は何万ものプログラムを絶滅から救っており、図らずもデジタル文化の守り手としての地位を証明している。

ソフトウェア海賊は、データをより簡易かつ記録媒体から独立させることによって、データの消失を防いでいる。巨大なシステムの一部として働く全体の知識を持たぬアリのように、デジタル海賊の献身的な行動は、全体として観察すれば、数多くのデジタルコンテンツを保存しているのだ。

海賊による保存効果とは、あまり良く知られてないが、何も目新しいことではない。何世紀にもわたり、石版、巻物、本に至るまで、その最も複製され、頒布されたものが、現代もっともよく保存されているのである。ホメーロス、ベオウルフ、ましてやキリスト教の聖書までも、もし未許諾の複製によらずんば、今日の図書館には残っていなかっただろう。

昔と今の違いは、ソフトウェアの劣化は、世紀という単位ではなく、年単位であり、複製による保存を違法行為にしてしまうのだ。これは深刻な問題である。何千もの文化的に重要なデジタルコンテンツが、今我々がこうして論じている間にも、虚無に消え去ろうとしているのだ。

ソフトウェアの消失

現代におけるソフトウェアの消失の問題は、磁気的媒体に起因する。かつてパーソナルコンピューターで広く使われた記録媒体であったフロッピーディスクは、約束された有限の寿命を持つ。推定寿命は、一年から、保存状態が良くてせいぜい三十年といったところだ。

フロッピーはプラスティックの円盤上の磁気変化によってデータを保持している。時間経過と共に、データを表現する磁気変化は、弱くなり、最終的にフロッピードライブが読み込めないレベルにまで低下する。その時点で、ディスクの中身は、実質的に、消失するのだ。

これは、三十年以上前に、パブリッシャーがソフトウェアをフロッピーディスクで出荷していたことを考慮すると、とても困ったことである。ほとんどの当時のディスクは、もはや読めない状態にあり、その上に記録されていたソフトウェアは、修復不可能なほどに損傷してしまっている。もし、読者が今からバックアップを進めようなどと思っているのならば、悪いニュースがある。時すでに遅からん[訳注：リンク先は、Web Archivesの運営者の一人が、どんなフロッピーでも保存するから送ってくれと頼んでいるサイト、しかし、すでに大半のディスクは手遅れな状態にあることを危惧している]

さらに悪いことに、1980年代のソフトウェアパブリッシャーは、数えきれないほどの人月をかけて、コンテンツの保存を妨害するように努めてきたのだ。海賊行為を妨げるため、彼らは様々な手法で、ソフトウェアをひとつの認可されたディスケット上にロックしようと試みた。ある有名なコピープロテクトの手法は、意図的に壊れたデータブロックをディスク上に配置して、コピー時のエラーチェック機能に引っかからせるようにしている。この手法は実によく働いたので、正規ユーザーの正規購入ソフトウェアの正当なバックアップすら妨げてしまった。

これらのコピープロテクトが、その意図通り、ド素人避けであり、著作権法に従うとすると、これらの手法を用いたディスクで出荷されたソフトウェアは、今や永久に失わてしまっていたであろう。多くの時代を主張する文化財が、メディアコントロールという強欲によって消失してしまったのだ。

危機にひんしているのはフロッピーディスクだけではない。ROMカートリッジによって出荷された何千ものゲームや、アーケード基盤は、今や見つけることすら難しい。しかも、これらは永遠の動作寿命を持たない電子機器上でしか動作しないのだ。パブリッシャーは、いくつかの有名なゲームについては、新しいプラットフォーム上でリリースしている。しかし、大多数のレガシーなゲームは、そのような処置を受けてはいない。海賊はこのようなデータをROMチップから解放し、ソフトウェア上のエミュレーションによって、新しいゲーム機やPC上で、プレイできるようにしているのだ。

また、海賊行為によって、歴史家が海外のゲームを研究するのを容易にしている。いくつかのゲームは、日本限定の書き込み可能なディスクにダウンロードする形で頒布されていたのだ。例えば、ニンテンドーパワーのフラッシュカートシステムやBS-Xサテラビューのような仕組みでだ。これらのゲームは、もし過去に違法にバックアップする試みがなされていなければ、西洋の歴史家からは手に入らなかった代物なのだ。

[訳注：Wiiを持っていないので詳しいことはわからないが、商業的に価値のあるほんの一部のゲームは、WiiのVCで提供されているかもしれない。余りはどうしようもない。これらを合法的に手に入れる方法は、現時点では存在しない。とくにBS-Xは、テレビの電波を利用した配信だったので、正規の方法で購入できるカートリッジがないのだ。もし当時、デジタル文化財の保存の重要性に気がついてバックアップしていなかったとしたら、お手上げである。ちなみにこれらのゲームは、1990年代後半に公開されているので、著作権法が今後も変わらないとしたら、ゲームは映画であるからして、今から約60年後の2070年あたりには、著作権が切れる。しかし、この記事でも言っているように、そもそも保存が難しいのだ。]

ソフトウェアの消失の問題の例として、ゲーム業界をみてみよう。Web上の最大のゲームデータベース、MobyGamesは、現在、約6万件のゲーム情報を載せている。約2万3千ほどのタイトルは、フロッピーディスクやカセットテープを記録装置や、配信媒体として使うコンピューター向けに出荷されていた。

2万3千ものゲーム！　もし、ゲームパブリッシャーと著作権法が横たわっていれば、このうちほとんどのゲームは、今後10年以内に、記録媒体の劣化によって、地上から一掃されてしまう。すでに、多くが失われている。

近年、コレクターと保存家は、ビンテージマシン（AppleIIとかコモドール64とかのたぐい）上で動く絶版になったソフトウェアを、ファイル共有サービスや、"abandonware"なウェブサイト上で交換している。この過程で、彼らは地下ソフトウェア図書館を作り上げているのだ。これは、新しいとはいえ、古代の失われたデジタル文明の記録を保存する図書館のようなものだ。

Abandonwareについて

abandonwareとは、すでに販売もサポートもされていないソフトウェアを頒布する大義名分である。これらのソフトウェアは、その著作者から「放棄(abandoned)」されたのだ。それにもかかわらず、ソフトウェアに著作権があり、著作者から、ソフトウェアの頒布許諾を得ていなければ、頒布はまだ違法なのである。

ジャーナリストかつ歴史家として、私はこのような海賊ソフトウェアを使って、仕事をしている[訳注：著者のBenj Edwardsは、コンピューター史とゲーム史専門の歴史家を自称している]。私だってこんなことはしたくないのだが、合法的な方法が存在しないのだ（詳しくは後述）。

この未来の歴史家にとって必要な資料である地下図書館による収集は、我々のデジタル遺産を保護するための、人類の反骨精神あふれる勇敢な行動である。この後に述べるように、ソフトウェア史における脅威は、過去にあるのではない。目前にあるのである。

何故ソフトウェアを保護するのか

さらにこの問題に詳しく踏み込む前に、そもそも、何故我々はソフトウェアを保護しなければならないのかという理由について考えよう。ソフトウェアは、そのあまりに短い寿命から、それほど重要視されていない。ソフトウェアとは電子による動的な表現を、コンピュータースクリーン上に投影したものであり、それ自体はさほどの意味をもたない。我々は、物理的な物体に価値を見出すのである。

しかし、ソフトウェアは強力な道具であり、我々の文明にとっても重要な意味を持つ。博物館を眺めると、道具の存在によって、ある社会がどのような状態にあったのかを知ることができる。もし、例えば、ある文明に脱穀機があったならば、我々はその文明が、100年前に比べて、麦の収穫をより速く行えたと知ることができる。これは、転じて、人口の爆発的増加を説明できるだろう。

同様にして、我々は人類の状態を、ソフトウェアツールを調べることで推定できるのだ。未来の歴史家は、今日の我々はいかにして音楽における音程調整を実現していたかとか、いかにしてCGIアニメーション映画を制作していたのであろうか、などという疑問を持つかもしれない。知識と、様々なバージョンのAuto-TuneやPixar RenderManやAdobe Photoshopの体験なくしては、彼ら歴史家が、そのような疑問を解き明かすことは難しいであろう。

ソフトウェアは娯楽でもある。文化である。本や、音楽や、映画と同じく、芸術がソフトウェアによって表現されている。多くはゲームだ。これらは各世代の文化を反映している。

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

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

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

我々には失うものが多すぎる

ソフトウェアの消失が過去の話であってくれればいいのだが、現代のソフトウェア市場においても、まだこの問題は存在する。App Storeやその他のデジタル配信システムは、よくヘンテコで制限されたライセンス契約をさせたがる。時には、デバイスすら制限することもある。我々がソフトウエアを所有することすら認めていないのだ。

横暴なDRMと統一された配信方法のおかげで、ほとんどのデジタル配信されているソフトウェアは、これらの配信ストアが廃止された場合、歴史的資料から消失する。これは事実である。彼らはいずれの日か、サービスを廃止する。もしこの事実に恐怖を覚えないとしたならば、歴史の授業が必要だ。

50万種類もの本が、急にその機能を終え、魔法のように世界中のすべての複製物が機能しなくなったとしたらどうであろうか。ポン。その中にあった情報は、消えてしまうのだ。紀元前48年のアレクサンドリア大図書館の焼亡に匹敵する文化的ダメージである。あの炎によって、それまでの西洋文化の歴史は、灰燼に帰したのだ。

さて、iTunes App Storeをみてみよう。デジタル文化の象徴である50万ものアプリを保持している。これは、たったひとつの企業によって支配されている。そして、将来廃止されるときには（もしくは、古いアプリをサポートしなくなった時には、Appleはすでに昔のiPodでやらかしている）、これらのアプリに対する合法的なアクセス方法も消え去るのだ。iDeviceに縛られた、購入したアプリは、このシステムが機能をやめた時、寿命を迎える。すでに、古いアプリは消え去っているのだ。なぜならば、開発者がアプリをストアに保持しておくための年会費100ドルを払わないがために。

歴史的にみれば、我々はハッカーと海賊たちが、iTunes App StoreやPlayStation StoreやWii Shop ChannelやXBox Live Arcadeやその他のオンラインのダウンロードサービスから入手できるあらゆるアプリを、秘密裏に保存してくれていることを願うしかないのだ。

クラウドソフトウェアはどうだ？　もし、我々のソフトウェアツールが中央管理され、インターネットを介して実行されるようになれば、海賊行為は困難になる。これは、保存されないということを意味する。歴史にとって、最悪である。

もし、古人類学者が、1万3千年前のやじりでバイソンを仕留めることができるかどうか疑問に思ったならば、単に槍の先にくくりつけて投げてみればよい。もし、やじりがその開発期間中、クラウドによって自動的にアップデートされていたならば、我々は最新設計のものしか知りえないことになる。やじりは現存していないであろう。我々は、古代のアメリカ原住民が、どうやって劣化ウラン弾でゲームをプレイしていたのかなどと疑問に思うことであろう。

考えてみたまえ。一年前のGmailのインターフェースってどんなだった？ストリートビューが搭載される前のGoogle Mapってどんなだった？　クラウドベースのソフトウェアツールの昔のバージョンにアクセスできない未来の歴史家は、スクリーンショットや個人の証言記録により、昔のツールがどのくらいの性能を持っていたのかを推し量るしかないであろう。もし、まだ存在していればの話だが。

クラウドではないソフトウェアならば、未来の歴史家は古いバージョンを試すことも可能だ。歴史家はやじりと同じようにツールを使い、当時の人間と同じ活動を再現できるのだ。たとえば、歴史家はAtari 800エミュレーター上でAtariWriter を実行して、1980年代のドキュメント作成を再現でき、これによって当時のフォーマットの必然性を実感できるであろう。

完全なるクラウド依存のゲーム（たとえばOnLive）は、脅威である。OnLiveにゲームソフトフェアの保存を期待するなどというのは、近所の映画館が、フィルムの歴史を保存していてくれるだろうを期待するようなものである。彼らは単に、その時点で商業的に価値のあるものしか上演しない。残りは破棄してしまうのだ。クラウドゲームも同じである。

新たな大図書館は、すでに焚書され始めている。我々はすでに、その煙を嗅いでいるのだ。

企業が歴史を支配すると、改変する

今日のデジタルApp Storeで使われているDRMは、将来の正しい歴史認識に対する重大な脅威である。そりゃ、ソフトウェアを作った企業は、製品に対する権利を、今は持っている。しかし、ひとたびコンテンツが消費され、大衆文化に取り入れられたならば、それは世代のものである。それは単なる商業製品以上の役割をはたすのだ。そして、コンテンツは文化財として、保護、保存されるべきである。

いつ変更され、消え去るとも分からないものを保護、保存するのは難しい。もし、VHSテープがApp Storeのように機能していたのならば、ジョージ・ルーカスは我々が購入したスター・ウォーズ映画を強制的に特別版にアップデートできるのだ（もちろん、ルーカスOSとの互換性を保つためである）。その過程で、昔のバージョンは上書きされてしまう。誰か知らん、将来、ルーカスは自分の映画が来に食わなくなり、Willowに書き換えてしまうかもしれない。法的な権利が彼にあったとしても、文化に対する窃盗である。

[訳注：日本において、Steamではすでに似たようなことが起きている。何故か正規購入したはずの日本語版が、後で英語版に差し替えられることがままある。そして、日本語版は購入不可能になる。]

iOSのアップデートの頻度に筆者は参っている。アップデートに伴い、過去のバージョンを消してしまうのだ。保存作業も面倒だ。確かに便利で強力な機能には違いないのだけれど、ダウンロードするたびに、歴史が書き換えられてしまうのだ。もし、1990年代からPhotoshopがこのようにアップデートされていたならばどうなっただろうか。レイヤーをサポートした最初のバージョンを持っている人はいるだろうか。そのような歴史的に重要なソフトウェアが消失してしまうのだ。同様に、もし我々が、すべてのPCアプリケーションに対し、完全にコントロールされた唯一の供給方式による自動アップデートを受け入れたならば―もうすぐそこに控えているよ、Windows 8のことさ―我々は、将来のデジタル遺産を破壊してしまうのだ。

制限的なDRMを受け入れた時、我々はソフトウェアとメディアのパブリッシャーに、デジタル文化の歴史を、意のままに削除、コントロール、捏造する力を与えているのだ。だからこそ、DRMは人類にとって根本的に悪であると感じるのだ。DRMは人類の正当たる文化遺産を破壊してしまうのだ。

もちろん、ソフトウェア作者は、今行われているように、ある一定の期間において、独占的な権利を与えられ、それによって対価を得るべきである。しかし、だからといって、歴史的な保存に対する妨害を許してはいけない。

アレキサンドリアで二千年前に起こった出来事を繰り返してはならない。大図書館の焚書を生き延びた巻物は、著作者の許諾なしに、複製され頒布されたものだけなのだ。残念なことに、当時の図書館職員は複製を防ぐために入館を厳しく制限していたので、焚書を生き延びた書物は非常に少ない。もし、我々がソフトウェアの保存に対する法的根拠を作らなければ、今から数千年先の文明には、海賊によって違法に複製されて頒布されたコピー品しか残らないであろう。

ソフトウェアの文化に与えた影響は、他の著作物に匹敵する。今こそ、書籍や映画と同等に、図書館で電磁的芸術品を合法的に保存するべきなのだ。そのような図書館を設置するのは、しかし、非常に難しいのだ。

デジタル図書館の困難性

もし、我々の文化の歴史を今日までたどって検証したければ、図書館に行くであろう。図書館には、無料で利用できる広範なアナログデータが収集されている。ソフトウェアを同じ方法で検証しようとしても、不可能だ。実用的で広範なソフトウェア図書館というものは、現在、合衆国では違法だからだ。

誤解しないで欲しい。ソフトウェア図書館を作るのは可能である。しかし、その実装は、現実的に役立たずなのだ。法律の範囲内で、実現可能な図書館というのは、公式に複製された物理的なソフトウェアの記録媒体を、物理的な書架に格納することである。つまり、記録媒体の劣化と時代遅れの問題がついてまわる。書架に陳列されているものが動く保証なんてどこにもない。

ソフトウェア図書館のより現実的な方法は、固定された記録媒体からデータを解放し、冗長化されたハードディスク群に収めることである。司書はハードディスクをアップグレードすることによって、劣化による消失を防ぐことができる。ソフトウェアは、ネットワーク間で自由に転送でき、エミューレーター（ソフトウェアのオリジナルなプラットフォームをシミュレートしている）上で実行されることにより、歴史的な検証に利用できる。

残念ながら、この実用的な方法は使えない。何故ならば、現在のところ、合衆国アメリカの著作権法においては、著作者の許諾を得ずして、ソフトウェアをコピー―オリジナルの記録媒体からの解放のために必要な作業―して、公衆で共有するのが、違法だからだ。（法律は合法的なバックアップを認めているが、他人と共有することはできない）。さらに、デジタルミレニアム著作権法においては、コピープロテクション技術を迂回して、そのような複製を作成することすら違法なのだ。

現在、フロッピーディスクを、まるで書籍と同じように、書架に収めている図書館が存在する。これらの団体は、本と同じように、十分に注意を払って保護すれば、コンピューターディスク上のデータは永久に保持されるなどという間違った思い込みをしているのだ。しかし、彼らにデータの消失を防ぐ方法は何もない。データは新しい記録媒体に複製されねばならないのだ。将来いずれ、法律が無視されるか―あるいは改正されるだろう。

著作権の時代遅れの前提条件

現在の合衆国アメリカの著作権法は、良い意図を持っているものの、デジタル財産の保存に対する大いなる脅威がある。なぜならば、電子的記録媒体の劣化速度と、フォーマットが時代遅れになる速さを考慮に入れていないからだ。

著作権法を制定した政治家は、19世紀風の法的な前提条件をもとにしている。著作物は、パブリックドメインになって自由に複製できるようになるまでまで、記録媒体に安全に固定されるという思い込みだ。例えば、紙の本だ。紙の本は保存条件次第で、数千年もの間、データを保存できる。

デジタルデータの場合、多くのプログラムは保護期間終了（合衆国アメリカでは著作者の死後70年）の数十年も前に、地上から消え去ってしまう。記録媒体の劣化と、フォーマットが時代遅れになることにより、どの図書館が合法的にバックアップするよりも速く、消え去ってしまう。

解決法のひとつとしては、ソフトウェアの著作権の保護期間を、妥当な期間に制限することだ。たとえば、最大で20年とか。そうすれば、保存家は、古いソフトウェアが忘却の異次元に消え去ってしまう前に保存できる確率が飛躍的に上昇する。

また、司書がソフトウェアを保存する目的でコピープロテクトを解除するのを完全に合法にする必要がある。現在のDMCAにおける一時的なDRM解除を可能にする条件は、あまりにも厳しすぎて、十分ではない。

別の解決法としては、新たな法を制定して、著作権保護を受けたいパブリッシャーは、DRMフリーなバージョンのソフトウェアを、合衆国アメリカの国立図書館の記録媒体に依存しないアーカイブに納めなければならないとする。ソフトウェアは後に、研究者のために提供される。必要であれば、このようなデジタル図書館のコンテンツは、商業的活動を保護するために、一定の猶予期間をおいた後に公開される。たとえば、5年とか。

ソフトウェアの消失を看過してはならない

我々の文明は、商業により支配されており、利益を受けている。そのため、商業に従事するものを保護したいと思う。その中で、とある連中が、目的を達成するため、海賊を厳しい法規制によって撲滅したいと考えている。しかし、海賊とデジタル配布とは切っても切り離せないものであり、自由を放棄しない限り、完全にコントロールすることはできない。そのような法規制は、海賊活動を地下に潜らせるだけで、むしろ海賊にかかわらない、正当な技術の発展を妨げる。その技術こそが、今日のソフトウェアの存在を成立させたというのに。

ソフトウェアの劣化を司る4つの力

ソフトウェアを消失に追いやる主な力が4つある。

力その１：物理的劣化

いかなるデジタル記録媒体も、データを永久に保持できない。すべてのコンピューターのデータの記録媒体は、時間経過に伴い、次第に劣化していく。その過程で、データは失われる。

力その２：記録媒体の時代遅れ

技術が進歩するにつれ、あらゆるストレージのフォーマットは、時代遅れになり、ついに、全く使われなくなる。これにより、将来データを取得するのが困難になる。

力その３：コピー防止

商業的理由により、ソフトウェアパブリッシャーは歴史的に、ユーザーがパブリッシャーの許諾なくソフトウェアを複製できないように細工してきた。このような手法は、ソフトウェアの正当な保存を妨げる。

力その４：商業的価値の消失

すべてのソフトウェアには、ある期間の商業的寿命がある。技術革新の圧倒的な速度によるものだ。これにより、ソフトウェアはある短い期間にしか、商業的に複製、頒布されない。

現在のところ、我々は、十分に頑張れば、いかなる娯楽品、あるいはソフトウェアプログラムであっても、無料で手に入れられる。いまだに何百万人もの人々が正規のソフトウェアや映画や音楽などの複製物を取得するために現金を払っているにもかかわらずだ。これにより、業界は大きく、より高売上になっている。

まだ人々がデジタル媒体を購入するという事実は、海賊というのはそれほど問題ではないということだ。実際、海賊というのは別の問題への解決方法なのだ。過剰に保護された知的財産という問題だ。あの無茶苦茶なDRMを使い、より過剰な反海賊法規制を支援する企業が、歴史的価値を保存するためには、多少の商業的利益の減少も致し方ないという見解をもってくれればいいんだが、それはフリーマケットですら目的ではないのだから、期待はできない。

今、この文化の歴史を保存するのは、この我々の世代にかかっている。我々は著作権法を改正し、海賊行為によらずに、ソフトウェアを歴史的資料として保存できるように働きかけねばならない。

ソフトウェアを愛するのであれば、買って、使って、作者を対価を与えるべきである。私はちゃんとやっている。私は製品によって金銭を得る権利を支持している。しかし、文化的権利の為に立ち上がることを恐れるな。もし無茶なDRMやコピープロテクトが、歴史の保存の脅威であると感じたならば、戦え。コピーしろ。安全な場所で確保しろ。そしていずれ共有して、消失しないようにしろ。

現代では、いくらかの連中から犯罪者だとみなされるかもしれないが、彼らは歴史の悪の方のいる連中だ。今から500年後に、古代のプログラムをロードして実際に検証するときに、当時から生存していてお前を著作権侵害者だなどとそしる者などいやしない。

一年前のGmailのインターフェースを覚えているかというところで、ハッとした。Gmailは毎日使っているのに、実際、覚えていない。もし、電子メールの歴史について書こうとしたならば、Gmailについて述べない訳にはいかない。Gmail以前にもクラウドベース（個人的に、クラウドという言葉はバズワード臭くて好きではないが。）のメールサービスはあった。しかし、Gmailが画期的な容量とインターフェースを提供したからこそ、爆発的に流行ったのだ。

MegaUploadで、まさに焚書がおきようとしている。FBIはキム・ドットコムと他の社員を逮捕し、会社の資産を差し押さえた。まだ裁判は始まってすらいない。キム・ドットコムが実際に犯罪者であるかどうかは、まだ裁かれていない。たとえ違法であったとしても、その利用者は、全員が違法な目的でサービスを使っていたわけではない。なにしろ、オンラインストレージである。しかし、MegaUploadの口座を凍結されているために、MegaUploadはサーバーの維持費が払えず、MegaUploadを合法的に利用していた人達のファイルが、いま消失しようとしている。アレキサンドリア図書館の焼失、秦の始皇帝の焚書坑儒は、いまだに行われているのだ。

もちろん、クラウドにデータを預ける危険性というのは、オンラインストレージやGmailだけではなく、このブログにも言えるわけだが。

だいぶ良くなってきた

2012-02-02T15:30:00.003+09:00

いまだにおかゆしか食べられないが、親知らずを抜いた後は、だいぶよくなってきた。とりあえず熱も下がり、頬の腫れもだいぶひいてきた。今は、むしろ糸に痛みを感じる。早く抜糸してもらいたいところだが、残念ながら来週まで待たなければならないとか。前回も、最終的には糸の存在が気になるようになった。

噛みごたえのあるものが食べたい。

2012-02-01T14:56:00.002+09:00

親知らずを抜いた後はまだ痛む。昨日は頬が腫れてふくれあがり、熱が出て頭がぼーっとし、悲惨な目にあった。今日は、熱はないし、腫れも治まってきているようだ。しかし、アゴを動かすと傷が痛む。唯一食べられるのは、水を米の10倍いれて作った、液体のようなおかゆだ。野菜も相当細かく刻まないと食べられない。ああ、何か噛みごたえのあるものが食べたい。

親知らず再び

2012-01-30T10:51:00.001+09:00

またもや親知らずのあたりの歯肉の盛り上がりが気になってきた。今日の午後、抜く手はずになってる。ああ、またひもじい思いをするのか。

前回の時は、四日間ほどゼリーしか食べられなかった。水をのむのも辛かった。おかゆや豆腐すら受け付けないとは予想外だった。

さて、レントゲンによると、私は親知らずが一本欠けているそうだ。一本はすでに抜いた。二本目も今日抜く。三本目はどうなるのだろう。今のところ、それほど問題にはなっていないが。

車をダウンロードする時代

2012-01-25T06:18:00.000+09:00

The Pirate Bay - The galaxy's most resilient bittorrent site
Pirate Bay To Offer Physical Item Downloads - Slashdot

The Pirate Bayが3Dプリンターのモデルデータ用のカテゴリーを作ったそうだ。アナウンスがぶっ飛んでいて面白い。

進化：新しいカテゴリー

我々はここThe Pirate Bayで、常に未来を見据えている。一つ確かなこととして、将来、我々の社会は、より共有をするようになるだろう。デジタル通信は共有を容易にし、これからもさらに簡単にしていくことに疑いはない。そしてインターネットの進化により、データはアナログからデジタルになった。更にここで次の一歩を進めるべきだろう。

今日、多くのデータは最初からデジタルで作られている。もはや、アナログからデジタルへの変換ではないのだ。もはや変換時の劣化を気にする必要もないのだ。なぜなら、デジタルでは一対一の完全なコピーが可能だからだ。音楽、映画、書籍等など、すべてがデジタル媒体になっている。しかし、我々は物理的な存在であり、依然として物理的な物に触れる必要がある。

思うに、コピーにおける次の進化は、デジタル媒体から物理的媒体となるだろう。これは、物理的な物体である。我々はこれを名付けて、Physiblesと呼ぶことにした。データは物質に変換可能なのだ。思うに、三次元プリンターやスキャナーは、その第一歩である。思うに、近い将来、車の交換部品を印刷できるようになっているだろう。20年もすれば、靴をダウンロードできるようになっているだろう。

この変化が社会にもたらす利益は多大である。もはや，物理的な物品を全世界に流通させる必要はなくなる。不良品の返品などといったこともなくなる。児童労働も撲滅できる。空腹ならば食物をプリントすればよい。もはや、レシピどころか料理そのものを共有できるようになるのだ。その気になれば、フロッピーを本当にコピーすることさえ可能だ。

思うに、共有の未来は、物理化可能なデータであろう。この辺で、ちょっと名前を、The Product Bayとでも変えてみるべきかもしれない。残念ながら、今、新しいロゴを作るアーティストがいない。しかし未来では、それすらダウンロードできるはずだ。（訳注：ロゴのダウンロードなのか、人間のダウンロードなのか・・・）

さっそく、海賊船の形状データへのリンクが登録されている。

3Dプリンターは非常に興味深い技術である。もちろん、今の3Dプリンターは、基本的にはインクジェットで、特殊な樹脂としてのインクを堆積させてプリントしているにすぎない。車を印刷するには、印刷後に金属と比較できるような特性を持ったインクが必要になる。靴を印刷したければ、ゴムのように変化するインクが必要になる。食べ物を印刷したければ、食べられるインクが必要になる。味や匂いを印刷したければ、もちろんそれもインクにしておかなければならない。そしてもちろん、3Dプリンターは相当の精度が要求される。

3Dプリンターはすでに現実化されているし、すでに大人のおもちゃを印刷できるほどの精度がある。木靴や下駄のようなものなら印刷できるだろう。しかし、このようなぶっ飛んだ構想を実現できる3Dプリンターが、はたして我々が生きているうちに現れるのだろうか。

MPAAの警告で、「車を盗んだりはしないだろう？」というのがあるが（そして、著作権侵害と窃盗の混同ということで叩かれているが）、果たして、車をダウンロードする時代は訪れるのだろうか。

日本人が知るべき記事

2012-01-22T12:25:00.004+09:00

Inside the Gaijin Dungeon at Narita Airport in Japan
Gulag for gaijin

事実だろうか。いかにも有りそうな話ではあるが。

追記、エコノミストに載ったので海外で色々と議論されているが、どうもこの話、100%真実かどうか怪しい。理由もなしに入国拒否を受けたと言っているが、VISAに関する情報を、弁護士と相談の上で、とか、プライバシー上の理由で（自分のWebサイトで名前も家族の名前も犬の犬種までも公開しているのに今更何のプライバシーがあるのか）とか、報道機関と独自契約を結んだからなどという理由で説明を拒んでいる。ひょっとしたら、観光客用のVISAで仕事をしていたのではないかとも言われている。

コダックモーメント

2012-01-22T10:22:00.002+09:00

What Happened To Kodak’s Moment? | TechCrunch

コダックの131年の栄華、デジタルカメラへの取り組みの遅さ、過去の栄光を捨てきれないプライド、富士フィルムとの戦い。結局何もなくなってしまったので、過去の膨大な特許を利用して、特許ゴロに成り下がった。そして、破産回避の再建手続きに至る。コダックの歴史と経緯をかなり掘り下げて、しかも簡潔にまとめてある。

一方、富士フィルムはどうなったかというと、コダックよりだいぶマシだ。今や、液晶ディスプレイに必要なフィルムのシェアの大部分を占めているそうである。また、化粧品や健康食品にも手を出している。個人的にはあまり好きではないが、儲かることは確かだ。古典的なカメラやフィルム事業は、規模を落として細々と続けているそうだ。まあ、会社の起源というプライドから続けているのだろう。社運をかけるほどではないから、経営に影響が出るほどの赤字にもならないということだろう。

ただ、どうもこれを読んでいると、既視感を覚える。いま、日本企業は技術の分野で振るわない。デジタルカメラでコダックを打ち破ったソニーなど、今はもう落ち目だ。思うに、時代がハードウェアからソフトウェアに移行しつつあるのに、いまだにハード屋の気概が抜けてないのではないだろうか。このまま、昔のアメリカ企業と同じ轍を踏むのだろうか。

2011-01 pre-Kona 2012 mailingの簡易レビュー

2012-01-21T09:06:00.000+09:00

2011-01 pre-Kona 2012 mailingが公開された。

最新のドラフト規格はN3337になる。今回は、単なる文面の細かい修正に留まる。したがって、これを最新のC++11の規格を学ぶために参照しても、恐らく差し支えないであろう。しかし、以前にもC++標準化委員会のMLで、規格書の値段の高さを冗談めかしたコメントにて、「今後公開される無料のドラフト規格は修正を含んでいるので、現行の400ドルもする正式な規格書よりベターといえるのではないか？」という疑問も沸く。閑話休題(あだしごとはさておき)。

N3322: A Preliminary Proposal for a Static if
N3329: Proposal: static if declaration

N3322とN3329の根本的な違いがわからない。なぜほとんど同じ提案のペーパーが二つ公開されたのだろうか。

コンパイル時条件分岐の提案。暫定的なキーワードとして、static_ifを使うとすると、以下のようにかける。

static_if( 条件 )
{

}
else
{

}

ifと何が違うのか。それは、条件分岐がコンパイル時に行われることである。たとえば、

template < typename T >
void f( T && t )
{
    static_if( std::is_same<T, std::vector<int>>::value )
    {
        t.push_back( 0 ) ;
    }
}

このようなコードが可能になる。従来のifでは、もし、テンプレートパラメーターTの型が、push_back(int)というメンバー関数を持っていなければ、コンパイルエラーになる。しかし、static_ifはコンパイル時に行われるので、コンパイルエラーにはならない。

これは、現在でも、テンプレートやオーバーロード解決を駆使することによって実現できる。実際、大昔のC++98においても、STLを正しく実装するためにはコンパイル時条件分岐のテクニックは必須である。であれば、最初から言語によるサポートをしたほうがよいのは当然だ。ちなみに、D言語ではネイティブでサポートされているとの由。どこからかD言語信者の勝ち誇ったかような雄叫びが聞こえてくるが、空耳であろう。

N3323: A Proposal to Tweak Certain C++ Contextual Conversions, v3

以下のコードを考える。

template< class T >
class Holder
{
public:
    Holder( ) = default ;
    Holder( T val ) : val( val ) { }
    operator T & ( ) { return val; }
    operator T ( ) const { return val; }
private:
    T val ;
} ;

まあ、よくある簡単なクラスだ。テンプレート引数の型を保持して、ユーザー定義変換で、あたかもその型のように振る舞うクラスだ。変換関数が非const版とconst版に分かれているが、これによって、オブジェクトがconstでも使えるようになる。さっそく使ってみよう。

    Holder<int *> p ;
    p = new int(0) ; // OK
    *p += 1 ; // OK
    int * pointer = p ; // OK

実に楽だ。では、使い終わったので保持しているポインターをdeleteしよう。

    delete p ; // エラー

残念ながら、これはエラーになる。なぜならば、ここではポインターへの暗黙の型変換が行われる。その際、「ポインターに暗黙に変換できる唯一の方法」を要求しているからだ。ところが、ポインターに変換する方法は二つある。よって、エラーとなる。

ではどうするか。明示的なキャストを使う方法もある。しかし、プログラマーというのは怠惰な人間なので、常に一文字でもタイプ数を減らす方法を模索するものだ。

    delete (p+0) ; // OK
    delete +p ; // OK

delete pが通らないのがバカバカしくなるコードだ。これを解決するために、TとTのリファレンス型を返す変換関数がある場合を認めようという提案。

N3324: Terminology: "indirection" versus "dereference"

規格の文面で、「ポインターを経由した間接アクセス」という意味の用語が統一されていない。そのため、すべてのdereferenceを、"indirecting through a pointer"という表現に置き換える提案。単純な置換えだが、かなり広範に渡る変更となる。

N3325: HTML for C++ Standards Documents

C++標準化委員会の公開するペーパーは、色盲やポータビリティを考慮して、HTMLにしようという提案。

ただし、主要ブラウザーがHTML5（というより、HTML5という名前自体に意味がないが）に進みつつあるなか、厳格なHTML 4.01に固執するのはどうかと思う。また、文字コードにはASCIIを使えというのも今時ありえない。第一、委員の多くが、ASCIIでは表現できない名前を持っている。したがって、作者は文字コードがASCIIだと信じていても、実はISO-8859-Xを使っていたりする。

そもそも、HTMLファイル内に、<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">などと書くのは、どのブラウザーからも機能しないと見放された太古の笑うべき仕様である。誰も正しい文字コードを指定しなかったから、信頼できないのだ。自己言及的なことに、同じく発表された、N3336が、HTMLファイル内ではWindows-1252であると主張しておきながら、"您好世界"という文字列を使っている。HTMLファイルの文字コードは、実際にはUTF-8である。こんなジョークでは何にでも笑う大阪人すら笑わせられない。

N3326: Sequential access to data members and base sub-objects

全世界の変態の皆様、特にBoost.Fusionユーザーの皆様、大変長らくおまたせ致しました。長年待ち望んでいたであろう機能の提案でございます。

unionではない任意のクラスのすべてのデータメンバーの型の一覧を、std::tupleでアクセスできる機能の提案。これさえあれば、メタプログラムがますます面白くなるだろう。

N3327: A Standard Programmatic Interface for Asynchronous Operations

非同期処理のためのライブラリの提案。

N3328: Resumable Functions

名前通り、レジュームできる関数の提案。これにより、非同期処理が実にシンプルに書ける。非同期処理のために単純なlambdaを複数書くのがめんどくさい人向け。

N3333: Hashing User-Defined Types in C++1y

C++11では、ハッシュテーブルを用いたコンテナーを追加した。unordered_setとunordered_mapである。そして、ユーザー定義型からハッシュを得るためのインターフェースも提供した。しかし、ユーザーがハッシュを実装するための補助は何もない。自分の用意したクラスをコンテナに入れたいユーザーは、自分でハッシュの算出を実装しなければならない。しかし、十分に強いハッシュ関数を実装するのは、一般人には困難である。現状を放置すれば、弱いハッシュ実装を使ったプログラムが世にあふれるであろう。そのため、ハッシュ関数の実装を助けるインターフェースを提供する提案。

この提案で用意されるのは、ひとつのプロセスがその回の実行に限り、ローカルにハッシュテーブルを構築するのに必要な強度のハッシュである。このハッシュ値は、プログラムの実行ごとに異なるものが出力される。つまり、ハッシュ値をディスクに格納して、次回の実行時に読み込んで使うということはできないし、複数のプログラムでハッシュ値を共有することもできない。また、文字列のハッシュ値を比較して、内容が一致しているかどうかを確実に確かめられるほどの強度もない。ましてや、セキュリティ上の目的でこのハッシュ値を使うことはできない。ハッシュ関数は目的毎に実装が異なり、すべての利用例をカバーしたハッシュ関数の実装が不可能なことはもちろん、ハッシュ関数のインターフェースの統一もいいアイディアではない。この提案されているハッシュ関数はあくまで、STLのコンテナに使うのに十分な強度のハッシュである。

N3334: Proposing array_ref<T> and string_ref

配列や文字列へのリファレンスというのは、現実によく使われる型である。しかし、どの型を使うかというと、定まった型がない。たとえば、std::vectorを使うことができる。しかし、何もstd::vectorにこだわる必要はない。たとえば、ポインターとその長さでもいい。文字列にしたって、std::stringのこともあれば、ポインターと長さのこともある。

もちろん、テンプレートを使って汎用的に実装することはできる。しかし、実装が複雑になり重複も生まれる。そのため、array_refというクラスを作り、どんな型でも、ある一定の操作方法さえ提供していれば、それを配列とみなして処理し、ユーザー側には統一されたインターフェースを提供しようというのが、このペーパーの提案だ。そのため、ユーザーコードは、わざわざこのような古典的な内容のために、クラスや関数自体をテンプレート化しなくてもよくなる。

N3335: Filesystem TR2 Proposal

TR2で採用する予定のFilesystemライブラリーの叩き台。Boost.Filesystem V3がベースになっている。

N3336: Adapting Standard Library Strings and I/O to a Unicode World

名前の通り、既存の文字列や入出力のライブラリーを、C++11で採用したUnicodeに対応させようという提案。TR2に採用予定。我々Unicodeに生きる日本人としては当然の変更である。

N3339: A Preliminary Proposal for a Deep-Copying Smart Pointer

unique_ptrとsmart_ptrをディープコピーできるようにする提案。ディープコピーとは、ポインターが指し示す派生関係にあるクラスの実行時のオブジェクトのコピーである。俗にクローンとも呼ばれている。

struct A { } ;
struct B : A { } ;
struct C : B {  } ;

A * get() ; // 実行時に型をnewして返す。

std::shared_ptr< A > p1( get() ) ;
std::shared_ptr< A > p2( /*ここで、p1の実行時の型のオブジェクトをnewコピー構築して渡したい*/ ) ;

p1は、実行時にA, B, Cのいずれかの型を取る。実行時に、この型のオブジェクトを何とかしてディープコピーしたい。

これらのスマートポインターは、いわゆるpimplのような実装を隠す手法に使われる。その際、ディープコピーができると嬉しい。そこで、ディープコピーを補助するためのインターフェースの叩き台を提案している。

N3340: Rich Pointers

コンパイラーの支援により強力なRTTIを提供するrich_ptrの提案。大規模な動的サーバーや分散システム、動的プログラミング言語の実装などに使われることを想定している。

N3341: Transactional Language Constructs for C++

2008年から始まった、C++にトランザクショナルメモリーを導入するワーキンググループの経過発表。

N3342: Digit Separators coming back

ユーザー定義リテラル「貴様のようなニューグラマーのなり損ないは、Rejectされる運命なのだ。わかるか！」
数値区切り「まだだ！まだ終わらんよ！」

C++11には入らなかった、区切り付き数字の提案。大きな数字、たとえば123456789が、アンダースコア区切りで、123_45_6_789と書けるようになる。何桁で区切っても構わない。正直、クソなユーザー定義リテラルよりこっちがC++11に入って欲しかった。提案された文法では、既存のクソなユーザー定義リテラルの文法とは曖昧にならない。

int x = 123_4_5_6_780 ; // 123456789

N3344: Toward a Standard C++ 'Date' Class

日付を表現する標準Dateクラスの提案。標準ライブラリーとして広く使えるライブラリーを作るのは難しい。

N3346: Defect Report: Terminology for Container Element Requirements - Rev 1

規格の文面の、コンテナー要素における、用語を統一する修正。

N3347: Modules in C++ (Revision 6)

近代的なプログラミング言語なら普通は備えているモジュールの提案。いつか#includeはもとより、プリプロセッサーのサポートを終了できる日を夢見て。もちろんC++だから、プリプロセッサーと共用できるように設計されている。

N3348: Scoping of operator new

現在、グローバル名前空間スコープとクラススコープでしか認められていないoperator newのオーバーロードを、名前空間スコープで宣言できるようにする提案。

N3349: Ease of using namespaces

本気で提案しているのかちょっと理解しかねる提案。namespace内の名前を無視させるディレクティブ"ignore namespace"の提案。以下のように使う。

namespace foo { class X { } ; }
namespace bar { class X { } ; }

using namespace foo ;
using namespace bar ;

void f()
{
    ignore namespace foo ;
    X x ; // bar::X 
}

このように、ignore namespaceディレクティブがある場所では、指定された名前空間内の名前をすべて無視する。こんなのが何の役に立つのか。おそらく、有名なライブラリのヘッダーをincludeする際に使うのだろう。

// C++11のインライン名前空間
inline namespace Win32 {
#include <Windows.h>
}


int GetLastError() ; // たまたまWin32 APIと名前が一致する関数

void f()
{

{// このスコープではWin32 APIは使わない。
    ignore namespace Win32 ;
    int result = GetLastError() ; // Win32 APIは無視される。
}

}

ある名前空間に属する名前をすべて無視するディレクティブなんて泥臭い機能である。それこそ、using namespaceよりひどい機能である。しかし、現実のプログラミングでは、どうしても変更できない巨大なライブラリ（しかも名前空間を使っていない）を複数組み合わせることを余儀なくされる。ライブラリが巨大であれば、どうしても名前の重複は避けられない。その際、わざわざスコープ解決演算子を使うのはめんどくさい。結局、これなしではもっと泥臭いコードになるのを回避する泥臭い機能なのだろう。それにしても・・・やはり泥臭い。

N3350: A minimal std::range<Iter>

そのまんま、Boost.Rangeの同等ライブラリのTR2への提案。

N3351: A Concept Design for the STL

C++11では却下されたSTLのためのコンセプト。一時C++11のドラフトに入っていたものより洗練されているとのこと。特に、たったの41のコンセプトしか定義せず、コンセプトマップを必要としない実装で、しかもテンプレートメタプログラミング臭いトリックが使われていないそうだ。

N3352: C++ Binary Fixed-Point Arithmetic

固定精度の整数と実数のライブラリの提案。これ上限が示されていないのだけれど、例えばcardinal<1024>にすれば、0 <= n <= 2^1024の範囲の整数クラスが使えるんだろうか。

N3353: C++ Concurrent Queues

同期キューライブラリの提案。

N3353: C++ Concurrent Queues

ストリーム(iostreamのストリーム)のためのロック機構の提案。しかし、ストリームなんてまともに使われていないから今更無駄だと思うのだが。

N3355: C++ Distributed Counters

マルチスレッドな環境で使えるカウンターの提案。頻繁にインクリメントされるが、読み出しは稀であるカウンターを想定している。複数のスレッドからのインクリメントは高速に行える。そのかわり、読み出しの遅さは許容する。

N3356: C++ Mutable Threads

スレッドプールより低レベルなライブラリーの提案。通常のスレッドは、あるひとつの関数を実行して、その関数から戻った際に、実行を停止する。しかし、ひとつの関数を実行するためだけにスレッドを作るのは非効率的な場合がある。例えば、小さな関数を大量に非同期に実行させたい場合などだ。そのような場合に使える、再利用可能なスレッドライブラリーである。このライブラリーは、スレッドプールの実装に使える。スレッドプールというには、やや低級なライブラリである。

以上。さて、今年こそC++本を完成させないといけないのだが、流石に疲れてきた。思うに、紙書籍という媒体には、もう未来がないと思う。それに、どうやら私はひとつのまとまった本を書く才能がないらしい。ブログなら簡単にかけるが、本は難しい。今の私を古人に擬すならば、橘成季だろう。

古今著聞集の作者である橘成季は理想主義者だった。彼は当時の公家らしく、様々な芸事に手を出した。競馬、詩文、作文、音楽、舞踊、はては絵までやっている。しかし、今日の我々は、橘成季を知らない。彼の作品はそれほど評価されず、残っていないからだ。彼は当時はやりだった説話集も作った。理想主義者らしく、説話を分類し、話の典拠を明記し、当時の公家日記に見つからないものはその旨も記した。しかし、古今著聞集は、一流にはなれなかった。読んでいても文章はつまらないし、量でいえば今昔物語に負けている。理想は高かったが、惜しいかな、本人の力量がどうしようもなく足りていなかったのだ。

思うに、もう少し軽いノリの本を作るべきだったと思う。ブログのような、あるひとつの主題に対して短い文章を書いたものをまとめた、それこそ説話集のような形式を取るべきだったのだと思う。代わりに今書いているのは、規格書の劣化コピーだ。それなら最初から規格書を読めばいいのだ。もし英語が読めないとしたら、その者は今日においてプログラマーとなる資格はない。

ともかく、始めたことは終わらせなければならない。初心者向けではない本でしかも自分ですら未熟だと思う内容なのだから、どうも売れる気がしない。しかも悲惨なことに、この数年、本の執筆だけを、如何にしてプログラミング言語の文法と機能を教えるかということだけを考えてきたので、まともにプログラミングできなくなっている。プログラマーとしては役立たずだ。これが終わったら、この業界からは身を引くべきなのかもしれない。C++を極めた挙句プログラマーにはなれませんでした、とは笑い草だ。いや、実際には、極めてすらいないのだ。

今日起きた企業による権力の悪用

2012-01-19T19:53:00.002+09:00

An abuse of power given the freedoms these companies enjoy in the marketplace today - Boing Boing

またもやCory Doctorowによる記事。

Xeniが火曜日に書いたように、MPAAはSOPAとPIPAに反対するブラックアウト運動がお気に召さないらしい。アメリカ映画協会の議長かつCEOである名誉会長のChris Doddは声明で、「今日起きた企業による権力の悪用」と称した。

お前が言うな。

あのスキップ不可なFBI警告（ひどく忌み嫌われていて、しかもDVDは他人に貸し出すことができないなどという法的に間違っている警告）をすべての商用DVDに付加させた団体のCEOはお前じゃないか。すべての映画にあの侮辱的な映画の違法ダウンロード警告をつけさせた団体のCEOはお前じゃないか。

しかも、お前がCEOをしている団体が、DMCAで、あの忌々しい警告や広告をスキップする機能をもったDVDプレイヤーの製造を違法にしたんだろ。

お前だって、「今日起きた企業による権力の悪用」の味は知っているはずだ。

そういえば、最近の映画やゲームには、スキップ不可な警告文やロゴやらが多すぎる気がする。海外ゲームのトレイラーに必ず付いているあのレーティング警告もうざい。

ハドソンを祭る文

2012-01-17T22:35:00.002+09:00

歳は辛辰に在り一月某夜、大恐慌の冬の赤字駅に停まりし時、一星忽焉として墜ちて声あり、嗚呼ハドソン死す矣、而して其光栄ある歴史は全く抹殺されぬ。

嗚呼汝ハドソンの事、吾人之を言うに忍びんや、想うに二十余年前、アタリのクソゲーいまだ余波を米市場に及ぼし、ゲーム興隆の宏謨は正に大頓挫を来すの時に方って、祖宗在天の霊は赫として汝ハドソンを大地に下して、其爆弾男の声を揚げ其十六連打を放たしめたりき、而して汝の父母は実に爆弾と鉄道を愛する神ゲーの正気なりき、実に世界を振蘯せるゲーム進歩の大潮流なりき。

是を以て汝ハドソンがゲーム興隆の為めに戦い、ゲーム進歩の為め闘うや、策略をもって爆弾で囲み貧乏神をなすりつけ、残機無きも屈せずコンティニュー無きも撓まず、凛乎たる意気精神、真に十六連打の慨ありき、而して今安くに在る哉。

汝ハドソンの起るや、世間の偏見は益々甚しく迫害は愈よ急也、ゲーム時間は制限せられたり、所有は禁止せられたり、請願は防止せられたり、而して捕縛、而して放逐、而して牢獄、而して電源遮断、而も汝の残機の減るを見るが如し、幾万のお小遣いを蘯尽して悔いざる也、幾百のセーブデータを損傷して悔いざる也、豈是れ汝が一片の理想信仰の牢として譲らざる信念のありしが為にあらずや、而して今安くに在る哉。

汝ハドソンは如此にして堂々たるゲーム会社になれり、幾多ゲーマー、暇人の五臓を絞れる熱涙と鮮血とは、実に汝ハドソンの糧食なりき、殿堂なりき、歴史なりき、嗚呼彼れ高橋や、毛利や、橋本や、桜田や、川田や、其熱涙鮮血を濺げる名人は、汝ハドソンの前途光栄洋々たるを想望して、従容笑を含んで宣伝に就けり、当時誰か思わん彼等忘却せられて即ちハドソンの死せんとは、彼等の熱涙鮮血が他日其仇敵たるヌルゲーとソーシャルゲーと劣化続編の唯一の装飾に供せられんとは、嗚呼彼熱涙鮮血や高難易度や今安くに在る哉。

汝ハドソンや、初めや聖賢の骨、英雄の胆、目は日月の如く、舌は霹靂の如く、攻めて取らざるなく、売りて売れざるなく、以て一たび鉄道ゲームの新天地を開拓し、リアルファイトを誘発するの偉業を建てたり、而も汝は発展の才に非ざりき、其死亡はスペランカーのジャンプより脆くして、直ちに旧態依然の怠惰の為めに征服せられたり、而して汝が光栄ある歴史、名誉なる事業今安くに在る哉。

更に想う、吾人年少にして友人の家にてファミコンを遊べるとき、無慚破戒の爆弾男は友人と吾人の貴重な時間を奪いたり。当時諸君の神ゲーのセンスは忘れざりき、而して見よ今や諸君は劣化続編のコナミ、パチンコ企業の忠実なる子会社となり、しかも消失に甘んじたり、而して吾人独り一枚のキーボード、多数のコピペ改変のみして、尚お神ゲーの復興の為めに奮闘・・・せざりき、汝ハドソンの死を吊し霊を祭るに方って、吾人豈に追昔撫今の情なきを得んや、かつての神ゲーのTAS動画を眺めて、慨然として賦して曰く、「ヌルゲー死ね、家ゲー死ね。一本道ストーリー重視クソ食らえ。昔ながらの硬派な2DのRPGと2Dのプラットフォームとスポーツ系FPSをよこしやがれこんちくしょう。バニーホッピングもストレイフもロケットジャンプもできないなんてふざけんな」。嗚呼大衆迎合の世は澆季なるかな、而も光栄ある汝の歴史は今や全く抹殺せられぬ、吾人唯だ此愚痴をつぶやきて以て汝を吊するあるのみ、汝ハドソン若し霊あらば髣髴として来り饗けよ。

The Pirate Bayは違法か？

2012-01-15T19:30:00.000+09:00

ここ数日、SOPAがらみの記事の翻訳をしたので、そのついでに、著作権問題の原因の一端を担っているともいえる、The Pirate Bayの最近の興味深い動きについて調べたことを書いてみようと思う。具体的には、The Pirate Bayが最近発表した、torrentファイルのホストをやめるという宣言だ。ただし、これはThe Pirate Bayの終了を意味するのではない。もっと間接的になるだけなのだ。最終的には、このブログ記事が違法かどうかという問題になるだろう。

The Pirate Bayとは、現在最大手の、マグネットリンクとtorrentファイルをホストしているサイトである。しかし、もうすぐ、torrentファイルをホストしなくなるであろう。マグネットリンクだけを載せるサイトになるはずだ。

まず前提の定義。

著作権者の許可を得ずに複製、公衆送信などをされるファイルを「違法ファイル」とする
違法ファイルのアップロード、ダウンロードを違法とする
プロトコルとその実装は違法ではないとする

この記事では、「違法ファイル」とは、複製、公衆送信すると著作権侵害となるファイルを意味する。

違法ファイルのアップロードやダウンロードが違法かどうかということに関しては、様々な議論がある。特に国内では、何をダウンロードするのかあらかじめ分からないのに、ダウンロード違法化とはどういうことだという議論もあるが、その懸念は、この場合、問題にならないから、とりあえず一律違法とする。

プロトコルとその実装は違法ではないということは言うまでもないことである。何故ならば、現在、最も著作権侵害に使われているプロトコルはHTTPであり、その実装はブラウザーだからだ。本記事で扱うBitTorrentプロトコルなど目ではない。HTTPプロトコルとその実装を違法化しようという試みは、無論、言うまでもなくカオスに失敗するであろう。

さて、The Pirate Bayというサイトは何をしているのか。その歴史を紐解けば、最初は、公開トラッカーサーバーであった。The Pirate BayのWebサイトは、The Pirate Bayという公開トラッカーサーバー上のtorrentファイルを検索、ダウンロードできるサイトであった。どんなファイルでも受け付けるので、当然、違法ファイルで溢れかえることになった。

技術的には、トラッカーサーバーは、ファイルのアップロード、ダウンロードは一切行なっていない。トラッカーサーバーが行うのは、ファイルのアップロード/ダウンロードをするノードの管理である。これは違法だろうか。ノードは違法行為を行うかもしれないが、ノードの管理は、果たしてどうであろうか。著作権侵害幇助だろうか。

さて、ノードの管理が違法かどうかはともかく、これは問題視され、実際に警察による捜査まで行われた。そこでThe Pirate Bayは、トラッカーサーバーの運営をやめてしまった。The Pirate Bayは、torrentファイルのホストと検索を提供するだけのサイトになったのだ。

技術的には、torrentファイルは、ダウンロード/アップロードするファイル自体のデータは含まない。ファイル名や、ハッシュ値などの情報を含む。BitTorrentプロトコルも発展し、今や、トラッカーサーバーを必要としなくなっている。ファイル名やハッシュ値に著作権保護などされるわけがないので、torrentファイル自体は違法ではない。私がこのブログに、あるファイルの名前とハッシュ値を書きこんでも、違法ではないはずである。さて、これは違法だろうか？　まだ幇助しているといえるのだろうか。

さて、最近のことだが、The Pirate Bayはマグネットリンクをデフォルトにすると発表した。また、将来的には、マグネットリンク一本でいくとも言っている。

技術的には、マグネットリンクは、ファイル名やハッシュ値すら含まない。ただ、torrentファイルのinfoセクションの抜粋である。実際、マグネットリンクとはBitTorrentとは関係ない、以前からあるただのURIの規格である。このURI schemeは、ローカルなアプリに任意の引数を渡して起動するURIである。たとえばこんなふうに記述される。

magnet:?xt=urn:btih:8ac3731ad4b039c05393b5404afa6e7397810b41&dn=ubuntu-11.10-desktop-i386.iso&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.ccc.de%3A80

このリンクは、Ubuntu 11.10のインストールディスクのISOイメージへのtorrentファイルへのリンクである。The Pirate Bayがubuntu-11.10-desktop-i386.iso (download torrent) - TPBで提供しているマグネットリンクは、たったのこれだけの単純な文字列だ。マグネットリンクに対応したBitTorrentクライアントをインストールした上で、マグネットリンクに対応したブラウザーを使えば、上記リンクをクリックすることで、BitTorrentクライアントが起動する。そして、マグネットリンクを経由して渡されたinfoセクションをもとに、torrentファイルを自動的にダウンロードする。その後、取得したtorrentファイルを使い、ファイル本体のダウンロードも自動的に始まる。

このように、The Pirate Bayの歴史は、私から見ると、迂回の歴史に見える。まずノード管理をやめ、今はtorrentファイルすらなくそうとしている。すると、ここで一つ疑問が持ち上がる。違法ファイルのホストは違法である。これはいい。しかし、違法ファイルにリンクしているThe Pirate Bayが違法であるとすると、The Pirate Bayにリンクしているこのブログ記事はどうなるのだ。違法なのだろうか。いや、リンクを貼るまでもない。今や、正確なURIなど示さなくても、"Pirate Bay"と記述すれば、Googleなどを使って、検索されてしまう。これは違法なのだろうか。

しかし、あるサイトにリンクはおろか、名前すら言及してはいけないとしたら、一体どうすればいいのか。某巨大匿名掲示板の例にならって、某巨大torrentファイルのinfoセクション検索サイトとでも書くべきだろうか。しかしそれは第二の名前をつけるだけだ。

ちなみに、日本のWinny裁判は、Winnyを開発したことが罪に問われたわけではなく、Winnyを開発したことが著作権侵害の幇助罪にあたるかどうかが争点になった。最高裁の判決の理由によれば、

他方，この点に関する被告人の主観面をみると，被告人は，本件Ｗｉｎｎｙを公開，提供するに際し，本件Ｗｉｎｎｙを著作権侵害のために利用するであろう者がいることや，そのような者の人数が増えてきたことについては認識していたと認められるものの，いまだ，被告人において，Ｗｉｎｎｙを著作権侵害のために利用する者が例外的とはいえない範囲の者にまで広がっており，本件Ｗｉｎｎｙを公開，提供した場合に，例外的とはいえない範囲の者がそれを著作権侵害に利用する蓋然性が高いことを認識，認容していたとまで認めるに足りる証拠はない

「例外的とはいえない範囲」とは一体どういった状態をいうのであろうか。たとえばThe Pirate Bayだ。The Pirate Bayは親切にもランキングを出してくれている。もっともランキングの高いtorrent Top 100を見ると、どうもタイトルやファイル名からして、ほとんど違法ファイルではないかと思う。もちろん、上記のマグネットリンクはThe Pirate Bayから直接コピペしてきたものなので、中には合法ファイルへのリンクもある。結局、The Pirate Bayがどんなファイルへのリンクでも受け付けるので、こうなっているのだが、はたしてどうなるのか。

かといって、Winnyだって、違法な目的に使われた場合のほうが多いはずだ。Winnyですら「例外的とはいえない範囲」の著作権侵害の割合であるとすれば、The Pirate Bayもそうなのであろうか。とすると、幇助ではないのだろうか。

思うに、今の技術に、法律どころか、我々の常識すら追いつけていないのではないだろうか。もちろん、私は楽観主義者なので、二、三十年ほどすれば、いまの問題はすべて白黒ついているのではないかと思う。もちろんその時は、また別の問題が出てきているだろう。たとえば、「家庭用3Dプリンターを使ってXBox5760やPS7やiPhone 16を印刷するのは合法か」とか、「電子化されてシミュレーション再現された故人に対する人権」とか。

参考文献：
BitTorrent Site The Pirate Bay Turns Away From Torrents
The Pirate Bay
The Pirate Bay - Wikipedia, the free encyclopedia
BitTorrent (protocol) - Wikipedia, the free encyclopedia
BitTorrent tracker - Wikipedia, the free encyclopedia
Torrent file - Wikipedia, the free encyclopedia
Magnet URI scheme - Wikipedia, the free encyclopedia

C++11ですみやかにプログラムの実行を終了する方法

2012-01-15T14:26:00.002+09:00

結論：C++11で新しく追加されたstd::quick_exitを使え。

プログラムの終了は、すみやかに行われるべきである。なにしろ、終了なのだ。終了にもたついていてはストレスがたまる。とくに、多くの実行環境では、プログラムの外部から、プログラムを強制終了させる方法がある。強制終了は大抵、プログラムの意志を無視して、強制的に一瞬で行われる。外部からできるのであれば、内部からできてしかるべきである。

なぜプログラムは終了時にもたつくのか。それは、終了時に特別な処理を必要とする場合もあろう。たとえば、数GBものデータを遅いHDDに書きださねばならない場合もあるだろう。これは妥当な理由である。では、確保したメモリやその他のリソースの解放処理はどうか。これは、疑問である。というのも、多くの近代的なOSでは、プログラムは個々に独立している。プログラムには独自の仮想メモリ空間が与えられ、必要に応じて物理メモリが割り当てられ、その他のリソースも独自に確保される。他のプログラムとは区別される。もし他のプログラムとリソースを共有したい場合は、なにか特別な方法を使わなければならない。そして、あるプログラムが確保したリソースは、そのプログラムの終了時に、OSが自動的に解放するようになっている。

プログラムの実行中に、必要のないメモリその他のリソースを解放せずに、延々と確保し続けるのは、これをリソースリークと呼ぶ。しかし、終了時には、どうせOSが解放してくれるのだから、自分でやるのは無駄である。

ここで未熟なプログラマー読者は思うであろう。解放するのがプログラムにしろ、OSにしろ、どちらかがやらなければならないのだから、どちらがやっても同じではないか。もし、プログラムによる解放が、OSに比べて極端に遅いとすれば、それは欠陥ではないのかと。問題は、ひとつのリソースを解放するというほど単純ではない。

例えばメモリだ。近代的なプラットフォームでは、仮想メモリ空間に割り当てる物理メモリはページ単位で確保する。これはたいてい、数KB単位である。しかし、現実のプログラムでは、もっと少ない単位（数十バイト）のメモリを大量に必要とする。これに対し、数KB単位のメモリを割り当てていたのでは、無駄である。そこで、現実には、まず一括してある程度の量のメモリを確保しておき、メモリ上に管理のためのデータ構造を構築し、そのメモリを必要とする小さな単位に切り分けて使う手法がとられる。これをヒープと呼ぶ。プログラムの実行中は、このヒープ内のメモリの確保と解放の処理は意味がある。しかし、プログラムが終了するのであれば、そんな処理は必要ない。ある仮想メモリ空間に割り当てられている物理メモリをすべて解放し、その仮想メモリ空間も破棄すればよい。これはすぐ終わる。ところで、近代的なプログラムであれば、マルチスレッドを使うのは当然である。ヒープに対する操作は、スレッドセーフではない。よって、ヒープの操作には排他的なロックをかける必要がある。プログラムの終了時に、すべてのスレッドが確保していたヒープ上のメモリを一斉に解放しようとしても、ヒープに対する操作は排他的であるので、いかに多数のCPUを搭載していようと、パフォーマンスは全くスケールしない。ましてや、ヒープ上のデータ構造の状態は、ヒープごとすべて破棄する場合には、全く関係ないのだ。結果として、遅くなる。

近代的なOSでは、ファイルやネットワークソケットなどといったその他のリソースには、リソースに対するハンドルが与えられる。リソースへの操作は、このハンドルを介して行われる。実行時に動的な数のリソースを確保するプログラムは、動的な数のハンドルを格納できるデータ構造を使う。一方、OS側でも、ハンドルと実リソースと紐付けるために、何らかの動的なデータ構造で情報を保持して置かなければならない。プログラムが明示的にすべてのリソースを解放する場合、プログラム側のデータ構造を巡り巡って、すべてのハンドルに解放処理を行う。ハンドルに対する解放処理を要求されたOSは、これまたOS側のデータ構造からハンドルに該当する実リソースを探し出し、解放処理を行う。しかし、最初から全てを解放するのだと分かっているならば、プログラム側の処理は二度手間である。

そう、ただちに終了するのであれば、プログラム側は何もしないほうがいいのだ。ところが、近代的なプログラミング言語では、「何もしない」というのは難しい。たとえば、C++にはクラスという機能がある。クラスにはコンストラクターとデストラクターがあり、これは、クラスの構築時、破棄時に、自動的に実行される。

C++においてプログラムを終了させる一般的な方法とは、main関数からのreturnである。しかし、main関数からreturnするためには、ネストして呼び出しているすべての関数からreturnしなければならない。

class X
{
    X() { /* リソースの確保 */ }
    ~X() { /* リソースの解放 */ }
} ;

void f1()
{
    X x ;
    // さあ、終了しよう
    return ;
}

void f2()
{
    X x ;
    f1() ;
    return ;
}

int main()
{
    X x ;
    f2() ;
    return ;
}

この例で、関数f1の中身を実行中に、プログラムを終了させたい場合、ネストされた関数を延々とreturnしなければならない。そればかりではなく、スコープの離脱に伴い、クラスXのローカル変数のオブジェクトxのデストラクターを走らせなければならない。たとえ、デストラクターの処理が、単なるリソースの解放であったとしても、デストラクターの実行を止めることはできない。

C++には、Cから受け継いだstd::exitがある。これを使えば、その場で終了できる。exitを呼び出した後に実行が続くことはない。ところが、このexitにも問題がある。グローバル変数とスレッド変数の破棄が実行されてしまうのだ。

X x1, x2, x3 ;

void deep()
{
    std::exit(0) ; // x1, x2, x3, x4のデストラクターが実行される
}

void f()
{
    thread_local X x4 ;
    deep() ;
}

int main()
{
    f() ;
}

では、終了中かどうかを判定するフラグを作って、すべてのグローバル変数とスレッド変数のデストラクターにチェックさせるべきなのだろうか。それでは、自動的なデストラクターの実行の意味がない。

他にも、C++11には採用されなかったが、他の言語では、ガーベージコレクションなどがある。これも速やかな終了の妨げになる。

多くのプラットフォームでは、プログラム自身の終了を止める独自APIが提供されている。プログラムのすべてのスレッドの実行を問答無用で停止して、終了処理を行うようなAPIだ。特定のプラットフォームだけを考えればいいのならば、そういうAPIを使えばいい。しかし、ポータブルなC++のコードを書く場合、できるだけそのような独自APIには頼りたくない。何故ならば、サポートするプラットフォームの数だけ、別々の実装が必要になるからだ。

C++11では、この状況に鑑み、std::quick_exitを用意した。使い方は、std::exitを全く同じだ。違いは、グローバル変数やスレッド変数の破棄が実行されないこと、Cのファイルストリームのフラッシュが行われないこと、終了前にstd::at_quick_exitで登録した関数が呼ばれることだ。

したがって、近代的なプログラムの終了手順は以下のようになる。

必要であれば、std::at_quick_exitでプログラム全体の終了処理を行う関数を登録する（プログラムの内部バッファーの書き出しなど）
その場で終わらせるべき処理を速やかに終わらせる
Cファイルストリームを使っていて書き込み結果が反映されて欲しいのであれば、フラッシュする
std::quick_exitを呼び出す

リチャード・ストールマンは常に正しかった

2012-01-14T01:16:00.002+09:00

Richard Stallman Was Right All Along

去年の年末頃、オバマ大統領はテロリストの容疑者を裁判や令状なしに拘束できる法に署名した。世界中で起こっている平和的なオキュパイ運動家は、権力者からテロリストだとレッテル貼りをされている。通信を監視するSOPAを成立させるような圧力もある。30年前、リチャード・ストールマンがGNUプロジェクトを立ち上げてからこのかた30年間、彼の極端な物の見方は、馬鹿げていてパラノイアじみていると嘲笑されたものだ。しかし、この2012年において、パラノイアだと思われていた予測が、現実のものになろうとしている。

ごく最近まで、リチャード・ストールマンを世間離れしたパラノイアの狂人だと一笑に付すことは簡単であった。まあ、いってみれば、奴は古臭いコンピューターヒッピーだ。地下室に引きこもって自分の世界に浸っているパソコンオタクだ。あのヒゲ、あの髪、あの服。我々の価値観からすれば、単に彼を笑い飛ばすのは、実に簡単であった。

彼の思想は常に常軌を逸していた。彼の持つ唯一のコンピューターは、Lemote Yeeloong Notebookである。なぜならば、これは、フリーなソフトウェアだけを使い、ファームウェアに罠はなく、BIOSすら非フリーではないという、完全にフリーなコンピューターだからだ。彼はまた、携帯電話を持たない。なぜならば、携帯電話は追跡を容易にするからだ。Yeeloongのような携帯電話が出るまで、ストールマンは携帯電話を持ちたいとは思わないのだ。そう、すべてのソフトウェアはフリーであるべきだ。フリーソフトウェア財団がいっているように

我々の社会がより一層コンピューターに依存する中、フリーな社会の未来を守るために、我々の実行するソフトウェアの果たす役割は重い。フリーなソフトウェアは、我々が家庭で、学校で、仕事で、コンピューターを使うあらゆる個人、商用の作業において、ユーザーによる技術の制御を実現してくれる。非フリーなソフトウェア企業や政府による制限や監視から逃れることができるのだ。

私自身も、ストールマンは極端にも程があると考えていた。フリーなソフトウェアで政府の支配や監視と戦う？　世界征服をたくらむ悪の企業？　プライベートな通信を監視するソフトウェア？　まあ、そりゃ、フリーでオープンソースなソフトウェアってのは大事だよ。もし非フリーなソフトウェアと同等機能を提供するフリーなソフトウェアがあるならば、もちろんそっちを選ぶさ。でも、ストールマンとフリーソフトウェア財団の非常識な主張にはうんざりだね、と。

しかし、2012年が始まるや、オバマはNDAA for 2012に署名した。これにより、アメリカ市民は、テロリストの容疑だけで、裁判や何らの令状手続きなしに、無期限に拘束され得るのだ。そして、SOPAだ。これがもし通れば、何らの裁判や令状なしに、Webサイトは消されるし、インターネットの通信を監視することも可能になる。さて、権力者がオキュパイ運動をなんとレッテル貼りしているか、テロリストである。さて、この先どうなるかは、明白である。

この動きを、中国や似たような全体主義国の傾向にみるのは、決して見当違いではない。アメリカ映画協会、すなわちMPAAでさえ、誇らしげに言っているではないか。中国、シリア、イランなどの国でうまくいっていることは、アメリカでもうまくいくに違いないと。中国のグレート・ファイアーウォールや似たようなフィルターシステムは、この自由であるべき世界に対して、実現可能な手法であると。

重要な点は、昔と違い、秘密警察と密告者によって通信を傍受しなくてもいいということだ。ただ、我々の使っているソフトウェアとハードウェアを支配すればいいのだ。我々のデスクトップPC、ノートPC、タブレット、スマートフォン、その他のあらゆるデバイスは、通信に使われる。リアルで体面すれば秘密を守れると思っているのかい？　ちょっと待ちたまえ。どうやって密会を取り持ったのかね？　まさか電話で？　ネットで？　しかも、そのポケットやバッグに入ってる、常にネットワークにつながっている状態のデバイスはなんだい？　

これこそが、ストールマンが30年も我々に警告してきた脅威なのだ。それなのに我々は、私も含めて、彼を真面目に取り合って来なかった。しかし、世界が変わろうとしている今この時、自分のデバイスで実行されているコードを検証できるということの大切さは、誰の目にも明らかである。もし、我々が、自分の所有するコンピューターを検証することができなければ、我々は奴隷だ。

これこそが、フリーソフトウェア財団とストールマンの信条なのである。すなわち、非フリーなソフトウェアはユーザーの支配力を奪うものであり、結果として深刻な脅威を引き起こすのである。特に今、我々はコンピューターに全てを依存しているのだから。ストールマンがこの事実を30年も前に気づいていたというのは、驚嘆すべきである。彼の活動は正当化される。この30年に及ぶフリーソフトウェア財団の活動も正当化される。

そして、この2012年において、我々は以前にも増して切実に、フリーかつオープンソースなソフトウェアを必要とするであろう。去年、ベルリンで開かれたChaos Computer Congressにおいて、Cory Doctorowは「汎用コンピューターに来るべき戦争（拙訳：本の虫: 汎用コンピュータ戦争）」と題して、スピーチを行った。その中で、Doctorowは汎用コンピューターに振りかかる脅威、特に、汎用コンピューターに対するユーザーの支配力に対する脅威に対して警告した。著作権戦争など、本当の戦争の前哨戦に過ぎないのだ。

「ウォークマンの世代として、僕が老いたときには、補聴器が必要になることに納得している。もちろん、僕が体に装着するのは補聴器ではなく、コンピューターである。僕が車に乗り込む時というのは、自分の体をコンピューターの中に押し込んでいるのだ。もちろん、補聴器も、僕の体の中に装着しているコンピューターだ。僕は、これらの技術に、何か秘密の機能が搭載されていて、僕の意志に反して動作の強制終了を拒否するようになっていないかどうかを確かめたい。」

上記は、ほんの一部の引用である。コンピューターが聴覚や移動などのあらゆることを補助する世界では、自分の支配できないコンピューターなどもってのほかだ。我々は内部動作を確認できる必要がある。我々が監視、検閲などなされていないように確認できる必要がある。我々は少し前まで、単なるパラノイアだと一笑に付していた。しかし、近年の動きを見るに、もはやパラノイアではない。現実である。

「未来の自由を守るためには、自分の使っているデバイスを検証できる必要がある。実行中のプロセスの検証と終了により、デバイスが自分に忠実なしもべであると確証できる必要がある。コンピューターが犯罪者や諜報機関や規制派のための道具に成り下がってはならない。我々はまだ、敗戦しているわけではない。しかし、我々はインターネットとPCを自由かつオープンに保つため、この著作権戦争に必ず勝利しなければならない。何故ならば、インターネットとPCは、将来の戦争のための武器だから、これ無くして来るべき戦争に勝つことはできない。」

だからこそ、我々は、たとえiPhoneの方が気に入っていたとしても、Android（GoogleではなくAndroid）をサポートしたほうがよい。たとえWindowsを使っているとしても、Linuxをサポートしたほうがよい。たとえIISを使っていたとしても、Apacheをサポートしたほうがよい。フリーである、オープンであるというのは、単にかっこいいだけでなく、必要となる時代が来るのだ。

リチャード・ストールマンって実は当時から一貫してすんげー正しかったんじゃね？　というお話。

汎用コンピュータ戦争

2012-01-13T19:30:00.001+09:00

28c3: The coming war on general computation

Transcript: transcript.md at master from jwise/28c3-doctorow - GitHub

今夜は、著作権に関しての話はしない。著作権の話はもうたくさんしてきた。文化とか創造性の問題というのは興味深いが、正直なところ、もううんざりだ。僕のようなフリーランスのライターの日銭を稼ぐ現状の変化については、YouTubeで僕の昔のスピーチ動画を探せばいい。今夜は、もっと重要な話をする。汎用コンピューターについてだ。

汎用コンピューターというのは、実際、素晴らしいものだ。あまりに素晴らしいので、我々の社会はまだその真価を完全に把握していない。なんのためにあるのか、なぜ動作するのか、どうやって付き合っていけばいいのか。この疑問は、残念ながら、著作権の話へとつながる。

何故ならば、著作権戦争の背景事情は、将来来るべき汎用コンピュータの命運をかけた戦いへの備えとなるからだ。はじめに、ソフトウェアのパッケージがあった。次に流通があり、そして、メディアコピーがあった。そこで、我々は包装され、段ボール箱に詰められたフロッピーディスクを、店頭に並べ、キャンディーや雑誌と同じように販売していたのである。コピーは簡単であったので、当然コピーは可及的速やかに、かつ、広範に行われた。これは、ソフトウェアを作成して販売する者の、悩みの種であった。

DRM 0.96の時代に入る。彼らソフトウェア作成者は、ディスクに物理的な制限をかけたり、ソフトウェアの実行時に存在を確認する物理的なものを導入した。ドングル、隠しセクター、コピーが難しい物理的な分厚い紙のマニュアルに記載されている事項を実行時に答えさせる認証。もちろん、これらの試みはすべて失敗した。理由は二つある。ひとつには、商業的に成功しなかったからだ。当たり前だ。彼らは正規ユーザーの利便性を損ねているのだし、しかもソフトウェアに対価を払わない連中は、そういう馬鹿げた仕組みにかかずらう必要はなかったのだ。正規品購入者は、バックアップが正しく動作しないことに不満を持ち、認証ドングルが無意味に通信ポートを占有するのを嫌い、ソフトウェアを実行するのに巨大なマニュアルを持ち歩く不便に閉口した。ふたつめには、これらの試みは、海賊行為を防げなかったのだ。ソフトウェアにパッチをあてて認証を回避するのなんて古典的な問題なのだ。大抵、必要な技術を持つ専門家や、ソフトウェアベンダーと同じ能力を持つ者らが、ソフトウェアを解析してクラック版を公開、即座に広まったのだ。このような技術と改造は、非常に高度な専門技能を必要とすると思われるかもしれない。しかし、そうではない。不具合のあるソフトウェアが何をしているのかを解析したり、ヘンテコなフロッピーディスクの欠損部分を迂回したりするということなどは、コンピュータープログラマーにとって必須のスキルであるし、当時のように、ヘンテコなフロッピーが広く出回っていて、場当たり的に対処するのが普通だった時代としては、なおさら必須のスキルだったのである。アンチコピー戦略は、ネットワークが広まっていくにつれ、ますます動かなくなっていった。我々がBBSやオンラインサービスやUSENETニュースグループやメーリングリストを手にした時、このような認証システムをクラックできた者はクラック用のファイルを配布していたし、ネットワークの能力が向上するに連れて、クラック済みのディスクイメージや、さらには実行可能ファイルを直接配布するようになっていったのだ。

これによって、DRM 1.0が起こった。1996年、政治家達は皆、なにか重要なことが始まろうとしていることに気がついた。「我々は情報経済の突入しようとしているのだ。どういう意味かさっぱり分からんがね」と。彼らは、情報経済とは、情報を売り買いできる経済のことであろうと推測した。今や、情報技術は物事を効率的にした。情報経済下における市場とはどうなるだろうか。本を一日だけ買う。映画を観る権利を１ユーロで売る、一時停止ボタンは一秒あたり１ペニーでレンタルされる。映画をある国ではこの価格で売り、別の国では別の価格で売る。等々。こういう時代の未来予測は、旧約聖書を元ネタに書かれたつまらないSFのようなものである。情報という名において挙げられる物を列挙し、それを売ることができるという考え方だ。

しかし、このようなことは、購入者のコンピューターの使用とファイルの送信をコントロールできなくては実現不可能だ。だいたい、ある映画を24時間だけ使用できる権利を販売したとしよう。あるいは、音楽をiPodに転送する権利を販売したとしよう。ただし、iPodから他のデバイスに転送する権利は売っていないとする。どうやったらそんなことが可能なのだ。一度ファイルを渡してしまえば、もうそれをどう使用するかは、ユーザー側の自由だ。このようなことを実現するためには、コンピューターに特定のプログラムの動作を禁止したり、ファイルやプロセスを監視する機能が必要になる。例えば、ファイルを暗号化して、特定の条件下でしかファイルをアンロックしないプログラムをユーザーに使用させることはできる。

しかしだ。インターネットでよく言うように、「問題はふたつになった（訳注：有名な正規表現のミーム、この問題を解決するのには正規表現を使えばいいだろう。問題はふたつになった）」。ファイルを削除する前に、ユーザーがファイルを保存することを防がなければならない。さらに、ユーザーがアンロックプログラムはどのように複合キーを格納しているのか解析するのを防がなければならない。何故ならば、もしユーザーがキーを見つけたら、単にファイルを復号化して、クソアプリとオサラバしてしまうからだ。

さあ、みっつ目の問題だ。ユーザーが復号化済みのファイルを他人と共有することを防がなければならない。さて、よっつ目の問題が出てきたぞ。アンロックプログラムの秘密を解析したユーザーが、解析方法を他人に教えることを防がなければならない。さて、いつつ目の問題だ。アンロックプログラムの秘密を知ったユーザーが、秘密の内容を他人に教えることを防がなければならない。

問題が多すぎる。しかし、1996年には、我々には解決方法があったのだ。著作権に関する世界知的所有権機関条約である。国際連合世界知的所有権団体によって制定されたこの法律は、アンロックプログラムの秘密を解析することを違法にし、実行中のアンロックプログラムから復号化されたデータを取り出すことも違法にしたのだ。さらに、アンロックプログラムから秘密を解析する方法を他人に教えることをも違法化する法律を作った。また、著作権保護された物や秘密情報をホストすることをも違法にし、インターネット上から情報を消し去るために、弁護士、裁判官などのクソを必要としない簡便な方法も法制化した。これにより、違法コピーは永久に撲滅されたのでありました。めでたしめでたし。情報経済は美しい花を咲かせ、全世界を美化したのであります。空母がよく言うように、「任務達成」とね。[聴衆の笑い声]

まあ、もちろん話はそこで終わりはしない。というのも、コンピューターやネットワークを理解している人間は、この法は、解決する問題よりも多くの問題を生み出すことを知っている。だいたい、この法律は、あるプログラムを実行中の自分のコンピューターの内部動作の検証を違法化する法律である。コンピューターの内部でどのような動作が行われているかを、他人に語るのを違法化する法律である。何が悪いということを一切証明せずに、インターネットを検閲できる法律である。つまり、彼らは現実に対し非現実的な要求を突きつけ、現実に無視されたのだ。そもそも、コピーはこの法律の文章が書かれている間にも、どんどん簡単になっていったのだ。コピーはますます簡単になることに疑いはない。今、この2011年は、もっともコピーが難しい時代である。あんたらのお孫さんは、クリスマスの食卓であんたらを囲んで、こう言う。「もっかい聞かせて、おじいさん。もっかい聞かせて、おばあさん。2011年ではどんだけコピーが難しかったの？　爪ほどの大きさのドライブで、今までに録音されたぜーんぶの音楽と、今までに作成されたぜーんぶの映画と、今まで発音されたぜーんぶの言葉、今までに撮られたぜーんぶの画像、ぜーんぶなんでも保存できて、コピーは気がつく間もないほど一瞬で終わる、そんなドライブがなかった時代、2011年ではどんだけコピーがアホくさかったのか教えて」と。そこで、現状が示されて、21世紀初頭は、我々の常識がいかにマヌケだったかというネタで、ひとしきり楽しい笑いを提供した後で、自由美を謳歌するのだよ。

まあ実際には、そこまでうまくはいかない。童謡のハエを捕まえようとクモを飲み込んだおばあさんのように、蜘蛛を捕まえるために鳥を飲み込み、鳥を捕まえるためにネコを飲み込みと、延々と続く。大衆に支持された規制が壊滅的な被害をもたらしたので、その穴をふさぐために、新しい規制を作ったのだ。さて、ここで話を終わらせて、立法者は阿呆か邪悪か、あるいは邪悪な阿呆であるかと結論づけるのはたやすい。あまり満足の行く結論ではない。何故ならば、結果は絶望でしかないからだ。この結論から導かれる考えとは、指導者から愚痴と邪悪を取り除かぬかぎり、この問題は解決しないということになる。ということは、この問題は永久に解決できない。僕は、またひとつ違った説を考えている。

立法者が情報技術を理解していないというのではないのだ。というのも、専門家でなくても、良い法律を作ることができるべきであるからだ。議員たちは、地方と人民を代表するために選ばれるのであって、宗教指導や問題の種をまくために選ばれるのではない。生物学者の議員はいないし、都市計画の権威である上院議員もいないし、児童保護の専門家である欧州議員もいない（たぶんいるべきだが）。彼らは法と政治の専門家で、技術には詳しくないものの、多くの場合、それほど変な規制を通したりはしない。これは、政府がヒューリスティックな手法を用いているためである。専門家や大多数の意見を調停するという仕組みである。

しかし、情報技術には、このヒューリスティックがうまく働かない。めちゃくちゃにしてしまうのだ。規制が目的にかなうかどうかというのは、それが正しく機能するかということにおいて重要だが、次に重要なのは、その規制を施行しようとすると、広範に影響を及ぼすということだ。今、私が、議会や議員やEUに、車輪を規制しようと働きかけたならば、確実に失敗するだろう。今、私が、「まあ、車輪というのはたしかに便利でありますな。しかし皆さんお気づきのように、銀行強盗は皆、車輪のよっつついた車に乗って、現場から逃げ去っております。何とかできないものでしょうか？」と主張したとしても、返答はノーだ。なぜならば、車輪の正規の目的で使う際の利便性を保ったまま、悪用を妨げるなどという方法が、思いつかないからだ。車輪というのは非常に便利なものであり、銀行強盗を防ぐために車輪を規制しようなどという論法は馬鹿げているからだ。たとえ大規模な銀行強盗が起こったとしても、それによって社会が大混乱に陥ったとしても、車輪の規制というのは正しい問題解決の方法ではないということは、誰もが知っている。

しかし、今、私が同じ政治団体に対して、私はハンズフリーフォンが車を危険にする確実な証拠を持っていると主張し、「私は車にハンズフリーフォンを設置するのを違法化する法を通したいのです」といったならば、政治家は、「そうだな。その主張はもっともだ。やってみようじゃないか」と言うであろう。その上で、この意見が良いものかどうか、あるいは、その証拠が正しいものかどうか、などといった議論は起こるであろう。しかし、「車からハンズフリーフォンを取り除いてしまったら、それはもう車ではなくなる」などと主張する人間はいない。こういう機能を取り除いたとしても、車は車なのだ。車は車輪と同様に、特殊化された目的を構成しており、ハンズフリーフォンを付け加えるなどということは、すでに完成された技術に対する追加にすぎないからだ。ここに、ヒューリスティックが用いられる。特殊化された目的の技術というのは複雑である。その技術から、根本的な機能を損なわないで、ある機能を取り除くことができるのである。

この原則は、議員にもよく働くが、こと汎用コンピューターと汎用ネットワーク、すなわちPCとインターネットに対しては、全く働かないのだ。なぜならば、もしあるコンピューターソフトウェアを機能とみたならば、これは表計算を動かすコンピューターであるからして、表計算機能を持つ。これはWorld of Warcraftを動かすので、MMORPG機能を持つ。その上で、このヒューリスティックを適用してみると、「表計算をしないコンピューターを作れ」となる。これは「ハンズフリーフォンを持たない車を作れ」ということと等しいようにみなされる。そして、もしプロトコルやサイトを機能とみたならば、「BitTorrentが動かないように、インターネットを直せ」、あるいは、「thepiratebay.orgが名前解決されないように、インターネットを直せ」などという規制が考え出されることだろう。そしてあたかもこれは、「警告音を変更せよ」とか、「ピザーラの電話番号を無効にしてくれ」などという規制と同じようにみなされ、インターネットの根本的な原理を破壊するような規制だとは思われないのだ。

車や建築物やその他の技術的な規制にはうまく適用できたこの原則が、インターネットに当てはまらないということを理解出来ない人間は、邪悪とか無知という言葉を持って表されるものではない。ただ単に、「チューリング完全」や「end to end」などといった言葉が無意味に聞こえる種類の人間と同じである。そこで、議員は深い考えなしにこれらの規制を通す。そして、現実世界の技術にもたらす影響に直面するのである。急に、インターネット上に書くと違法になる数字がでてくる。公開できないプログラムが出てくる。そして、まったく問題のなかった著作物が、急にネット上から消え去ってゆく。そこで、「え？　あれが著作権を侵害してたの？」と気がつくわけだ。規制の本来の目的を達成できはしない。この手の規制で著作権侵害は止まらない。著作権管理団体の根本的に間違った対処方法を受け入れているのだ。単なる自己満足である。「何とかせにゃならん。俺は何とかしてんだよ」と。規制に対する責は、規制内容を正しく考えなかったという批判になる。そもそも、その規制という考え方自体が根本的に間違っているのにもかかわらずだ。

根本的に間違った手法と対処方法は、様々な分野で起こる。私の友達で日用品の大手企業の役員を務めていた奴の話で、マーケティング部門が開発者に、素晴らしい洗剤のアイディアを思いついたと提案した。洗うたびに衣類を新しくする洗剤を開発しよう、と。いやまあ、開発者はマーケティング部門に、「エントロピー」の概念を理解させることができなかったらしい。そこで開発者がとった解決方法がある。「解決方法」、それは、酵素の働きによって、ほつれた繊維の端を断ち切るというものだった。衣類が古くなると繊維の端がほつれてきて、いかにも古くさくみえるからね。これによって、衣類を洗う度に、見た目が新しくなるというわけさ。でもそれは、洗剤が衣類を文字通り傷つけているからにすぎない。この洗剤を使うと、衣類を洗濯機の中で次第に崩壊させていくわけだ。これは、衣類を新しくするというアイディアの全く反対である。洗う度に衣類はダメージを受けていく。ユーザーがこの「解決方法」を適用する度に、衣類を新しく保つ方法が極端になっていく。新しい衣類を買わなくちゃならないんだ。だって古いのは溶けちゃうからね。

この手のマーケティング部門の連中に言わせると、「コンピューターはいらないんだ。必要なのは専用機だ。すべてのプログラムを実行するコンピューターなんてのはやめてくれたまえよ。ただ専用の動作、音声のストリーミングだったりパケットのルーティングだったり、XBoxのゲームだったりとかは提供して欲しいが、不正なプログラムや不利益なプログラムは実行できないようにしてくれたまえ」となる。これは一見すると、理にかなった要求のように聞こえる。ある専門の動作だけを実行するプログラムだ。ほら、ミキサーに電動モーターを取り付けることはできるし、食器洗い機にもモーターを取り付けることはできる。でも、ミキサーが食器洗いプログラムを実行する恐れなんてないだろ、とね。しかし、その手の要求を満たしたコンピューターは、話が違う。そういう要求によって作られた、とあるコンピューターは何か専門のアプリを実行するわけではないのだ。このコンピューターは、どんなプログラムでも実行できる。ただし、ルートキットやスパイウェアやコード署名といった技術を組み合わせて、実行中のプロセスを確認だとか、独自のソフトウェアをインストールだとか、実行されてほしくないプロセスの終了などというユーザーの動作を妨害しているだけなのだ。要するに、専用機というのは、機能を削減したコンピューターではない。完全なコンピューターにスパイウェアを仕込んでいるだけなのだ。

どんなプログラムでも実行できる、ただし、実行されてほしくないプログラムや、法律に違反するプログラムや、不利益をもたらすプログラムは実行できないという汎用コンピューターの作り方を、我々は知らない。それに近いものは、スパイウェアを搭載したコンピューターである。コンピューターがユーザーのあずかり知らぬ所で、ユーザーの意思に反して、勝手に動作ルールを決めているコンピューターである。これこそが、DRMがマルウェア（悪意あるソフトウェア）たる所以である。

かつて、ある有名な事件があった。ソニーが六百万枚の音楽CDにルートキットのインストーラーを仕込んでいたのだ。このルートキットはひそかに実行されて、CDの音楽データの読み取りを監視し、妨害するのだ。しかも、カーネルを騙すことで実行中のプロセスとしては表示されず、ドライブ上のファイルとしても表示されない。もちろん、これは唯一の実例ではない。任天堂は出荷した3DSに対して、ファームウェアを更新する際に、既存のファームウェアに改変が加えられていないかどうかをチェックし、もし改変を検出した場合は、3DSを文鎮にしてしまうのだ。

人権団体は、U-EFIという新しいPCのブートローダーに対して非難声明を出している。これは、署名されたOSしか実行できないように制限をかける機能がある。これにより、政府は、政府の検閲や秘密捜査に協力的でないOSの署名を無効にするかもしれない。

これをネットワークに適用すると、ネットワークを著作権侵害に利用できないように政府が規制をかけるだろう。そこで、SOPA、合衆国アメリカのStop Online Piracy Act（オンライン海賊行為防止法）では、DNSSecのようなツールは禁止される。何故ならば、このツールを使えばDNSブロックを回避できるからだ。そして、Tor（訳注：匿名性の高い多段プロキシ―）のようなツールも禁止される。何故ならば、このツールを使えば、IPブロックを回避できるからだ。SOPAの擁護団体、アメリカ映画協会が、SOPAの考察メモに書いている内容によれば、「SOPAは多分うまくいくだろう。なぜならば、すでにシリア、中国、ウズベキスタンが同じ方法を用いており、とてもうまくいっていると報告しているからだ。だからアメリカでもうまくいくに違いない」とさ。

[聴衆から多大な笑い声と拍手]　僕に拍手しないでくれよ。するならMPAAにしてくれ。

さて、SOPAは著作権とインターネットにおける戦争を終わらせる一大事である。もし、我々がSOPAを撃破できたならば、PCとネットワークの自由を守りぬくことができるのだ。しかし、この話の最初に言ったように、これは著作権の話ではない。というのは、著作権なんて、これからコンピューターに振りかかるであろう戦火から比べたら、0.9ベータ版ぐらいなものだからだ。娯楽業界なんてものは、これから来るべき世紀に渡る紛争における、前哨歩兵みたいなものだ。まあ、彼らは善戦していると思うかもしれない。ベスト40に入る音楽とか、リアリティ番組や、アシュトン・カッチャーの映画を守るために、SOPAでインターネットを根本的に破壊しようとしているわけだから。

実のところ、著作権規制というものは、これ以上まともに進展することはないだろう。だからこそ、カナダの議会は、馬鹿げた著作権法案を毎回提出していながら、可決に至っていないわけだ。だから、SOPAという原子レベルまでクソの固まりを寄せ集めて、「バカ250」みたいになってるふざけたものが、クリスマス休暇の後回しにされてるわけだ。世の中にはもっと重要な、国家的に重大な議論が山ほどあるからね、例えば失業保険だとかさ。だからこそ世界知的所有権機関はアホの集まりがアホくさい著作権条約案ばかり出しているんだ。だからこそ世界各国が国際連合に送るのは、治水の専門家であって、著作権の専門家ではない。医療の専門家であって、著作権の専門家ではない。農業の専門家であって、著作権の専門家ではない。なぜなら、著作権というのはそれほど重要ではないからだ。

カナダ議会が著作権法を可決しないのは、カナダ国内の数多くの問題ごと、すなわち健康問題を始めとして、アルバータの石油問題や、フランス語話者と英語話者の共存や、国家の資源問題などに対して、著作権を修正するなんてことの優先度は限りなく低いからだ。著作権の問題なんてものは、その他の分野の経済がインターネットとPCみせる憂慮とに比べたら、ゴミカスみたいなものだ。なぜ別分野はコンピューターの規制に反対するのか。いや、そりゃ今の我々の生活はコンピューターに依存しているからだ。我々はもはや車には乗っていない。コンピューターに乗っている。我々はもはや飛行機には乗っていない。乗っているのは制御装置が多数取り付けられたSolaris機だ。3Dプリンターというのはデバイスではなくて出力装置であり、動作にはコンピューターへの接続を必要とする。ラジオはもはや鉱石ではなくて、汎用コンピューターに高速なADコンバーターとDAコンバーターを取り付けて、いくつかのソフトウェアを走らせているものなのだ。

不正コピーに対する懸念なんて、今このコンピューター依存の現実世界に対する脅威からみれば、ちっぽけなことだ。たとえばラジオだ。今日までのラジオというのは、製造された時点ですでに固定されたものであって、容易に変更できないものであった。手元のポケットラジオのスイッチをいじって航空管制の電波に割りこむなんてことはできない。しかし、強力なソフトウェアによって実装されているラジオは、実行するソフトウェア次第で、ポケットラジオを緊急無線や航空管制に変身させることができる。だからこそ今、アメリカの通信規制団体である連邦通信委員会は、ソフトウェア無線の導入がどのような影響をもたらすか懸念している。彼らは、すべてのソフトウェア無線は規制済みのコンピューター装置に組み込まれるべきではないかと議論しているのだ。要するには、すべてのPCはロックされていて、中央の権威が、実行を許可されるプログラムについて厳格な規制をしくことができるという考え方だ。

これはまだ問題の序章に過ぎない。考えてみて欲しい、今年はAR-15をフルオートに改造するオープンソースの形状ファイルが公開された年である（訳注：不詳。民間用AR-15は規制によってフルオート機能がない。フルオートに改造するための部品の形状をモデリングした3Dプリンターのためのデータのことか？）。今年は個人製作の遺伝子シークエンシングを行うためのオープンソースのハードウェアが登場した年である（訳注：OpenPCRのことであろう。PCRに必要とするハードウェアは原理的に、それほど複雑で精密ではない）。そして3D印刷が面白いことになっている。今や、大人のおもちゃすら印刷できると、アメリカ南部の裁判官とかイランの宗教指導者とかが知ったら、気絶するだろうね。3Dプリンティングは、麻薬密造やセラミックナイフと同じように、規制派の活動を活発化させるだろうね。

ファームウェアの書き換えが可能な自律運転車とか、航空無線に割り込み可能な装置や、化学、生物学上の各種装置などなど、SF作家を待たずとも、規制派が心配するような技術は、今や山ほどある。モンサント社（訳注：遺伝子組換えによる耐性作物を開発している会社。色々と黒い噂が絶えない）が将来、コンピューターが専用の出力装置を使って、彼らの飯の種を食べてしまうような生物を合成できないように、そのような生物を出力するプログラムを実行できないように規制するのは有意義であると主張しないと、どうしていえようか。これが杞憂であるかどうかはともかく、彼らのようなロビー団体や宗教団体、政治団体は、ハリウッドよりもはるかに高い影響力を持っている。そして将来、彼らは皆、同じ結論に達するだろう。「任意のプログラムを実行できるが、我々の利益を損ねるプログラムだけは実行できない汎用コンピューターを作れないのかね？　ある二点間において、任意のメッセージを任意のプロトコルで通信できるが、我々の不利益になるような通信は禁止するインターネットを作れないかね？」と。

将来、汎用コンピューターと付随する出力装置を使って、僕をも驚かすような何かをしでかすようなプログラムが現れるだろう。だから、将来ますます、人々は汎用コンピューターを制限することが有意義であると考えるようになっていくだろう。しかし、我々が著作権戦争で目のあたりにしたように、特定のインストラクションやプロトコルやメッセージを禁止するということは、問題そのものの解決には一切ならない。我々が著作権戦争で目の当たりにしたように、PCを制限する試みというのは、すべてルートキットに行き着く。インターネットを制限する試みというのは、監視と検閲に行き着く。だからこそ、この問題は重要なのだ。何故ならば、我々はここ十年来、ラスボスだと思われるものを相手に戦ってきた。しかし、実際には、序盤ステージの最後にいる中ボスでしかなかったのだ。そして、次のステージの難易度は、格段に上がる。

ウォークマンの世代として、僕が老いたときには、補聴器が必要になることに納得している。もちろん、僕が体に装着するのは補聴器ではなく、コンピューターである。僕が車に乗り込む時というのは、自分の体をコンピューターの中に押し込んでいるのだ。もちろん、補聴器も、僕の体の中に装着しているコンピューターだ。僕は、これらの技術に、何か秘密の機能が搭載されていて、僕の意志に反して動作の強制終了を拒否するようになっていないかどうかを確かめたい。

去年のこと、フィラデルフィアの中流の高級住宅街にあるローワー・メリオン高校に不祥事が発見された。この学校は生徒にPCを貸し出していたのだが、このPCにルートキットが含まれていて、ネットワーク接続と内蔵カメラを通じて、遠隔監視できるようになっており、彼らは生徒を何千枚も、校内、郊外、寝起き、着替え、裸に至るまで、盗撮していたことが発覚したのだ。また、現在の諜報機関は、PCやタブレットやケータイのカメラやマイクやGPSを秘密裏に操作できる法的根拠がある。

未来の自由を守るためには、自分の使っているデバイスを検証できる必要がある。実行中のプロセスの検証と終了により、デバイスが自分に忠実なしもべであると確証できる必要がある。コンピューターが犯罪者や諜報機関や規制派のための道具に成り下がってはならない。我々はまだ、敗戦しているわけではない。しかし、我々はインターネットとPCを自由かつオープンに保つため、この著作権戦争に必ず勝利しなければならない。何故ならば、インターネットとPCは、将来の戦争のための武器だから、これ無くして来るべき戦争に勝つことはできない。こういうと早計なように聞こえるが、何度も言っているように、まだこの戦いは始まったばかりなのだ。我々が今戦っているのは中ボスであり、より難易度の高いボスが、やがてやってくる。しかし、良きゲームデザイナーならば当然そうするように、我々に今、最初に与えられたのは、比較的弱いボスなのだ。我々には勝機がある。本物の勝機がある。もし我々が今、オープンかつ自由なシステムを維持し、我々と共闘してくれるEFF、Bits of Freedom、Edrie、Nets Politique、La Quandrature du Netなどの数多くの味方を維持できたならば、我々には勝機がある。戦争に必要な弾薬の準備をしておけ。

なかなか興味深い考え方だ。今我々が直面している著作権などというものは、中ボスでしかないという。本当のラスボスは、汎用コンピューターの自由を脅かす存在である。任意のプログラムを実行できるが、著作権侵害をおこすプログラムだけは実行できないような汎用コンピューターなどというものは存在しない。そんなものをつくろうと試みても、できあがるのは、スパイウェア入りのコンピューターである。DRMなどというものも、くだらない。DRMを解析するのを違法にするというのは、有名な正規表現ジョークと同じで、問題を二つに増やすだけである。

oldnewthing: なんでHeapFreeがERROR_POSSIBLE_DEADLOCKで失敗するのか？

2012-01-07T14:30:00.003+09:00

Why did HeapFree fail with ERROR_POSSIBLE_DEADLOCK? - The Old New Thing - Site Home - MSDN Blogs

ある顧客がassertに引っかかると報告してきた。何でも、HeapFree関数が、全く問題ないヒープブロックに対する操作に失敗し、GetLastError関数の結果は、ERROR_POSSIBLE_DEADLOCKだという。一体何がどうなっているのだ。

私の同僚が持ち前のエスパー能力を駆使して訊ねた。「ひょっとしてプロセスは終了中かい？」

「ええ、まあ。何で分かったんだい？」

プロセスはどのように終了するかという話を思い出して欲しい。まず最初に起こることは、プロセスの他のスレッドをすべて、強制的に終了させるのである。これにより、スレッドによって所有されていた同期リソースがロックされたままになる可能性がある。この場合、同期リソースとはヒープである。

ある関数がHeapFreeを呼んだ際、ヒープのコードはヒープをロックしようとするが、他のスレッドによって所有されているので、ロックできないことを検知する。そして、その他のスレッドはすでに終了しているのだ（他のスレッドはHeapFreeの操作の最中に強制終了される可能性がある）。ヒープのコードはこの状況を検知し、デッドロックを回避して、ERROR_POSSIBLE_DEADLOCKを返す。

これと同様に、プロセスの終了中に、メモリーを安全に確保することはできない。つまり、メモリーは確保も解放もできないのだ。前回学んだように、プロセスが終了中であるならば、クリーンアップなどすべきではないのだ。プロセスのアドレス空間が解放されるときに、メモリーはすべて解放される。手動で解放する必要はない。時間の無駄である。

Windowsにおいて、プロセスの終了中にリソースを解放する必要はない。この単純なルールを理解出来ないWindowsプログラマーは実に多い。そういうプログラマーの書いたコードは、プログラムの終了時にまぬけにも例外エラーを出したりする。

ベラルーシ、国外のサーバーの利用を禁止する法律を可決

2012-01-04T07:20:00.001+09:00

Belarus: Browsing Foreign Websites a Misdemeanor - Global Legal Monitor - Law Library of Congress (Library of Congress)

ベラルーシで、国外のサーバーの利用を禁止する法律が可決されたそうだ。

著作権の保護期間に思う

2012-01-03T03:31:00.001+09:00

来年、すなわち2013年には、吉川英治と柳田國男の著作権が切れる。楽しみで仕方がない。

ところで、一つ疑問がある。いま、各国の著作権の保護期間は、微妙に異なっている。たとえば、アメリカの著作権は、法人名義は公開後95年、個人名義は死後70年保護される。一方、日本では、それぞれ公開後50年（映画は70年）、ないしは、個人の死後50年である。ただし戦時加算と旧法の方が保護期間が長くなる場合に注意しなければならない。ということは、アメリカで公開された著作物が、日本では保護期間が満了しているものの、アメリカでは満了していないということが起こりうる。この時、一体どうなるのであろうか。

今、アメリカで作成、公開されたコンテンツがあるとする。日本では著作権が著作権が切れているが、アメリカでは切れていない。このコンテンツを日本国内で合法的に入手し、アメリカに持って行くとどうなるのだろうか。アメリカからみると、私のコンテンツの入手方法は、海賊行為である。しかし、日本からみると、著作権が切れているために、合法である。すでに私は合法な方法でコンテンツを入手したのだから、それは私の所有物である。私の所有物であるということは、アメリカ国内でも合法であろうか。しかし、私がアメリカ国内でも合法的に所有しているのであれば、コンテンツをアメリカ国内で販売できるはずである。まさか、所有はできるが販売はできないなどという中途半端な状態にはならないだろう。とするとやはり、私はアメリカ国内ではこのコンテンツを合法的に所有できないのだろうか。つまり、私アメリカに入国する際には、そのようなコンテンツを持っていかないように気をつけなければならないのだろうか。

これはやはり、博打や大麻とおなじであろうか。日本では、博打と大麻は禁止されている。しかし、外国では、禁止されていない国もある。大麻の場合は、大麻取締法の第二十四条の八に、「第二十四条、第二十四条の二、第二十四条の四、第二十四条の六及び前条の罪は、刑法第二条の例に従う。」と書かれてあることから、日本人が日本国外で大麻を摂取した場合は違法である。博打の場合には、そのような規定はないので、国外で行う分には合法である。

では、この著作権の保護期間の違いの場合はどうなるだろうか。

ChromeのNative ClientにMAMEを移植

2012-01-01T22:17:00.001+09:00

Case Study: Porting MAME to Native Client - Native Client — Google Developers

ChromeのNative Clientに、MAMEを移植した事例。MAMEというのは、複数のアーケード基盤のエミュレーターである。今はアーケードすら、中身は普通のPCだったりするが、昔のアーケードには、かなり数多くの特殊な基盤があった。MAMEは、有名な数多くのプラットフォームのエミュレーター集のフロントエンドとでもいうべきソフトウェアである。

MAMEをNative Clientに移植するには、結構な障害がある。なにしろ、Native Clientでは、セキュリティ上許可されていない操作が数多くある。たとえば、シグナルだとかディレクトリ操作はできないし、ファイルの入出力も、Chrome側で用意している特別なAPIを用いる必要がある。pthreadの高度な機能も使えない。手書きのアセンブリも問題だ。メモリの保護フラグの変更もご法度である。

MAMEの移植はだいぶ難しく、4日間かかったとのこと。

最近のゲームのグラフィックに思う

2011-12-30T23:40:00.001+09:00

グラフィックは、ゲームの面白さの本質ではない。しかし、やはりグラフィックは重要である。私が始めた遊んだPCゲームは、Mafiaであった。Mafiaは、当時としては素晴らしいグラフィックであり、私のGeForce 4 Ti4200で快適に動作した。

今から思うと、惜しいことをしたものだ。私はもっと早くからPCゲームに目覚めているべきだったのだ。DoomやWolfenstein 3DやDuke Nukem 3Dなどといった往年の名作ゲームが、今となっては楽しめない。もし当時、これらのゲームに触れていれば、楽しめたはずなのだ。しかし、私の最初のPCゲームはMafiaだったので、それより以前の時代のゲームを楽しめないのだ。これは実に残念なことだと思う。私はThe Elder Scrollsシリーズが好きだが、ArenaやDaggerfallは楽しめない。どちらも、今、公式に無料で提供されているゲームである。また、DOSBoxのようなx86上で動くMS-DOSエミュレーターを使えば、当時とほぼ変わらずに遊べるゲームである。それなのに楽しめない。実に惜しい。

ともかく、最近のゲームのグラフィックの流行は、スクリーンスペースのポストプロセスだろう。なにしろ、どんなシーンでも負荷が予測できる範囲なので、化石並の低スペックなコンソールでも使いやすいのだ。

SSAO（Screen Space Ambient Occlusion）

SSAOは最も有名であろうと思う。Crysis以降、多くのゲームはSSAOを採用した。nVidiaなどは、ドライバー側でSSAOを適用する機能までリリースしたのだ。また、DirectXのラッパーDLLをかませて、既存のゲームにSSAOをかける手法も開発されてきた。Depth Bufferの各ピクセルと、周囲のピクセルの差を比較して、それに応じてやや黒くするポストプロセスである。もちろん、いくらスクリーンスペースと入っても、大まじめに実装しようとするとパフォーマンス上厳しいので、大胆な手抜き方法を使う。見た目に分かりやすい結果としては、面と面が角度をつけて重なり合っているような部分が黒くなる。面白いことに、この効果は、実にうまく人間の脳を騙してくれる。SSAOを古いゲームに適用してみると、急にグラフィックの品質が大幅に向上したように感じる。

ただし、最近は、以前程SSAOが喧伝されなくなっている。代わりに、SSAOっぽい影をテクスチャに最初から書き込んでおく手法もみられる。

ポストプロセスによるアンチエリアス

具体的な名称としては、nVidiaの考案したFXAAが一番有名だが、Crysis 2で使われているSMAA: Enhanced Subpixel Morphological Antialiasingもなかなか面白い。基本的な考え方はどれも同じで、ジャギーをごまかすフィルターである。

そもそも、アンチエリアスの一番分かりやすい目的は、縁のギザギザ、つまりジャギーを目立たなくするというものである。最初に実装されたAAの手法は、目的の解像度より高い解像度で描画して、しかる後に目的の解像度までダウンスケールするというものである。これは原始的だが、最も効果的な方法である。問題は、パフォーマンスが最悪だということだ。今の最新のCPUをつかって、大昔のゲームがやっと動くというほど、パフォーマンス上の問題がある。近代的なゲームに使うことはできない。次に、MSAAというものが実装された。これは、頂点処理だけ高解像度で行い、ピクセルに落としこむ際には、目的の解像度で行うというものである。すくなくとも、ジャギーはだいぶ解消できる。問題は、これも最近のゲームに使うには、ややパフォーマンス上問題がある。

結局、やっていることはジャギーの低減なのだ。ジャギーは縁に発生する。静止画の縁を判定する方法は、大昔から研究されている。だったら、縁を判定して、その部分だけ賢くぼかせば、ジャギーはごまかせるではないか。ということで、FXAAなどのアンチエイリアスは、縁を判定して賢くぼかすピクセルシェーダーのコードで実装されている。

Screen Space Global Illumination、あるいはReal-time Local Reflection

Unreal Engine 3のSamaritanデモで、この技術が披露されている。

また、Crysis 2にDirectX 11パッチを当てると、Real-time Local Reflectionと称して、この技法が使われる。

これも、スクリーンスペースによる反射の実装である。水たまり、テーブル、壁などに、周囲の風景が写り込んでいる。

何にしても、化石スペックのコンソールが足を引っ張りすぎている。テッセレーションを活用したゲームはほとんどない。もっとも、テッセレーションは、その可能性あふれると裏腹に、普通に使っても、それほど見た目にはインパクトがない地味な機能なので、仕方がないのかもしれない。それに、ほとんどのゲームでまともに使っていないので、GPUベンダーもあまり力を入れていないのだと思う。ただし、将来に期待できる。個人的には、Normal MappingやBump Mappingには全然感動できないので、Parallax mappingやDisplacement mappingがもっと使われてほしいものだ。

変わり種としては、Rageが上げられる。伝説のプログラマーJohn Carmackは常に変わったことをする人である。ただし、常に主流の技法からは外れているのだ。今回、Carmackがこだわったのは、テクスチャーだ。Rageでは、使い回しのないテクスチャーを実現している。もちろん、テクスチャーの構築には、デカールを使い回しているが、テクスチャ自体はユニークである。Rageのグラフィックは、序盤の廃墟がすばらしい。ただし、ユニークなテクスチャーは、デザイナーにかなりの負担を強いるらしい。プレイ動画をみても、中盤以降はマップの構成が雑になっているし、ついには長いマップ作成を諦めて、狭い部屋に閉じ込めて、周囲から延々と沸く雑魚敵を相手に戦うような演出でごまかしている。残念なことだ。もう一つ残念なことに、テクスチャーを使いまわさなかったせいで、あんなに短いのに、DVD三枚ほどの容量を必要としている。もちろん、PCならばいまどき20GB程度のサイズは問題にならないが、博物館に陳列されるレベルの低スペックな現行コンソールではかなり問題になる。そして、今時Bump Mappingすらないのだ。まあ、個人的にBump Mappingは価値がわからないのでどうでもいいのだが、やはりないと寂しい物がある。Rageは色々と惜しいゲームであった。

マリオカート7が劣化していた

2011-12-29T21:51:00.001+09:00

たまたま、3DSのマリオカート7に触れる機会があったので、遊んでみたのだが、全然面白くなかった。レースゲームなのに疾走感がまるでなかった。

まずグラフィックが糞だ。加速時にFOVを狭めたり、ブラーをかけたりするなど、レースゲームならではの表現手法は、もう考案され尽くしているはずなのに、なぜこの2011年で、こんなにもしょぼい表現なのだろう。それに、マップが無駄に広い気がする。何故こんなに広いのだろうか。こんなに道が広くては、コースアウトして溝に落ちるとかダートに突っ込んで減速するといったスリルを味わえない。ただ惰性で操作しているだけで完走できるヌルい作りになってしまっている。こんなゲームのどこが面白いというのか。

結局、マリオカートというゲームは、スーパーマリオカートでその可能性を示し、マリオカート64で完成されたゲームなのだろう。これ以上何を付け足しても蛇足というものだ。マリオカート7をやるくらいなら、スーパーマリオカートやマリオカート64をやったほうが、よっぽど面白いはずだ。

なぜこうなってしまったのだろう。今や、ポータブルゲーム機ですら、ニンテンドー64をはるかに上回るスペックを持っているのだ。それなのに、なぜ当時よりつまらない劣化続編しか作れないのだろうか。そして不思議なことに、ゲーム市場は、当時よりはるかに大きく、売上本数も増えていることだ。これは一体どういうことだろう。世の中はクソゲーを望んでいるのだろうか。

Intel、ネットワーク越しに電源を入れる特許を取得

2011-12-28T23:48:00.000+09:00

Intel Receives Network-Power-On Patent

Intelが、ネットワーク越しに電源を入れる特許を取得したらしい。はて、そんなのは自明ではないのだろうか。すくなくとも、この特許が出願された2007年以前にも、そんな装置は山ほどあったと思うのだが。

鬼を笑わせる

2011-12-27T19:07:00.000+09:00

今年も残り少なくなってきたところで、鬼を笑わせるような未来予測をしてみたい。ところが、どうも今は、さっぱり希望がでてこない。というのも、PCの進化がどんどん遅くなっているようなきがするのだ。

たとえば、CPUの処理能力は、ここ数年、驚くほどの向上はない。少し向上はしているものの、その向上が目にみえて実感できないのだ。もはや、我々はMP3のエンコード速度を気にする必要はない。ゲームなど、もはやCPU依存ではなく、GPU依存になっている。動画のエンコードでは多少の実感ができるが、やはり一般的とは言いがたい。

GPUはCPUよりまだ希望がある。といっても、今のPCゲームは、低スペックなコンソールに足を引っ張られて、その性能はあまり意味がない。GPGPU（GPUによる汎用コンピューティング）は、あまりにも適用可能な範囲が限定的で、やはり一般人が直接その恩恵に与ることはない。

HDDの容量なんてもはや誰も気にしないし。SSDは値段が下がる程度の予測しかできない。

もうPCの世界からみると、ハードウェアの進化は止まっているも同然なのだ。

ただし、これがスマートフォンになると、かなり未来は明るい。スマートフォンのハードウェアは、年々進化している。もうしばらくすれば、グラフィック性能が現行コンソールに追いつくだろう。その時、果たしてゲームコンソール、すなわちゲーム専用機は、生き残れるだろうか。今より少しグラフィック性能を上げただけでは、果たして差別化出来るだろうか。十分なグラフィック性能をもったスマートフォンを誰もが持っている世界では、ゲーム専用機など無意味である。実はPCすら危うい。もし、ディスプレイとの接続がワイヤレスになれば、果たしてPCは生き残れるのか。

もちろん、無線によるディスプレイ接続は、帯域的にまだ現実的ではないが、いずれ実現されると考えている。鬼が一番笑いそうなのはここだろうか。

ただし、スマートフォンでひとつ気になるのは、自由が全くないということである。PCならば、どのハードウェアを使うか、どのOSを使うか、どのネットワークを使うか、ということは、自由である。ソフトウェアも、様々な配布形態がある。ところが、スマートフォンでは、こうは行かない。ハードウェアとOSは固定されており、ネットワーク提供者も、大抵固定されている。ソフトウェアは統一された唯一の中央マーケットから入手しなければならない。しかも、このマーケットでは、ソフトウェアには事前に検閲が行われているし、遠隔操作によるユーザー側のスマートフォンのソフトウェアの消去も可能なのだ。これはどういうことだ？　今年は1984年か？

PCならば、ハードウェアには様々な標準規格がある。しかし、スマートフォンにはそんなものはない。ハードウェアとOSがセットになったAppleはさておき、androidさえ、ハードウェアの仕様はころころ変わるので、昔のハードウェアに最新のandroid OSを入れるということが困難である。

さらに、特許の問題がある。スマートフォンの世界では、私のコモンセンスで考えるに、自明であるようなアイディアにまで、特許が与えられている。特許はアイディアに与えられるものだっただろうか。ユーザーの利便性と普及を考えれば、機能やデザインを統一するのは理にかなっている。キーボード配列やマウスは、信号は規格化されているし、レイアウトも規格化されている。スマートフォンにはこれがない。みなてんでバラバラに実装し、それぞれ独自発明であるとして特許を取得し、市場原理に則った競争をせずに、特許裁判に明け暮れている。

もし当時、キーボードのレイアウトやマウスの形状、またはその信号方式に、今のように激しく特許を主張し、各社ともてんでバラバラに実装していたとしたら、今日のPCの興隆はあっただろうか。

これをもってこれをおもうに、あと10年ほどは、PCのスマートフォンに対する優位性は揺るがないであろう。PCがはるかに優れているためではなく、スマートフォンが足の引っ張り合いで自爆しているためである。したがって、私は今、スマートフォンについて何か学ぶ必要は一切ないと結論できる。この不自由と特許の問題が解決されてから学んでも遅くはないだろう。

SOPAガキ

2011-12-27T12:24:00.001+09:00

Lauren Weinstein's Blog: "SOPA Lad" (The SOPA Song) - With Apologies to Gilbert and Sullivan

またLauren Weinsteinさんか。この人、本当にGilbert and Sullivanが好きなんだな。

元ネタはこれ、When I was a Lad.

ブログのデザインを変えた

2011-12-22T17:31:00.000+09:00

そろそろ、昔のテンプレートでは管理画面がまともに機能しなくなってきたので、仕方なく新しいテンプレートを使うことにした。HTMLの修正による変更はしたものかどうか悩んでいる。

Winny開発者の金子勇、無罪

2011-12-21T10:16:00.001+09:00

著作権侵害を幇助したとの疑いをかけられていたWinny開発者の47氏（最初に2chに開発宣言をしたレス番が47であった）こと金子勇が、無罪になった。当然である。ソフトウェアを開発、公開しただけで犯罪になってはたまらない。

ただし、Winnyはその仕組みからして、問題がある。ネットワーク内にたった一人の著作権侵害ノードがあるだけで、全員が推定著作権侵害になってしまうのだ。

Winnyの機能に、中継というものがある。これは、ファイルをアップロードするノードとダウンロードするノードの間にたってデータを横から横へ流す、いわばプロキシとなる機能である。この中継機能は、ユーザー外としていないデータまで中継する可能性がある。さらに、Winnyはキャッシュという仕組みによって、中継されたデータを保持し、その後も送信可能な状態におく。これが問題となる。

もし、中継機能がなければ、すなわち自分が明示的にダウンロードを選択したデータのみ、アップロードすることになる。これは、取得と公衆送信に、著作権上問題のないデータであれば、全く問題ない。ただし、中継という機能によって、意図しない著作権侵害かもしれないデータをダウンロード、アップロードしてしまう。つまり、Winnyネットワーク上にひとつでも悪意あるノードがいて、その著作権上問題となるデータをダウンロードしようという別のノードがいれば、自分が中継する可能性がある。よって、Winnyネットワーク内にひとつでも悪意あるノードがあれば、全ノードが推定有罪になってしまう。Winnyネットワークへは誰でも参加できるので、当然問題となる。

当時取るべきだった方法は、この問題を認識して、修正するように働きかけることだったのだ。それを、著作権侵害幇助などというどう考えてもおかしい理由で逮捕、起訴して、無罪判決まで七年もかける。問題のソフトウェアは修正されないまま放置されている。Winnyネットワークは中央管理サーバーを持たないので、全世界に核による絨毯爆撃でもしないかぎり、止められはしないというのに。これだから日本からはイノベーションは生まれない。

とはいえ、もし当時逮捕がなかったとしても、Winnyプロトコルが標準規格になるのは無理だっただろう。本当に普及させたいならば、まず仕様を文章で公開し、リファレンス実装をオープンソースで公開すべきだったのだ。まあ、あの当時はまだこの分野の夜明けのようなものだったので、似たようなプロトコルが乱立した。今となっては、Winnyプロトコルは、古びた時代遅れのプロトコルと言わざるを得ない。そもそも、ファイル共有自体に、新鮮な面白みもない。あの当時と比べて、ハードウェアははるかに進化した。ファイル共有程度であれば、別にP2Pを用いなくたっていいのだ。Dropboxのようなサービスが、当時よりはるかに安価で提供されている。もっとも、日本ではオンラインストレージは違法だというトンデモ判決がでているのだが。

では、今注目すべき技術は何かというと、やはりNamecoinだろう。合衆国でSOPAが議論されている今、中央管理のDNSへの信頼性が揺らいでいる。本来、名前解決のサービスに検閲や規制などがあってはならないのだ。名前解決というのは、著作権侵害や犯罪とは何の関係もないからだ。Namecoinは、ドメイン名の名前解決を、Bitcoinと同じ方法で行うものである。すなわち、P2Pで中央管理サーバーを持たず、信頼性が計算力により保証されたシステムである。

Safari for Windowsの日本語版の使用許諾書がひどい

2011-12-05T10:10:00.001+09:00

Safari for Windowsをインストールしようとして、使用許諾書を読んだところ、ひどい誤訳だらけで、何の意味もなしていないことを発見した。

たとえば、以下のような文面がある。

重要な通知：　このソフトウェアがマテリアルを複製するための範囲において、使用することができます。

これを素直に解釈すると、ユーザーである私は、このソフトウェアであるSafariを使って、自由にマテリアル（？）を複製して良い、と読める。

さっぱり理解出来ないので、英語版のライセンスを読んだところ、以下のようになっていた。

IMPORTANT NOTE: To the extent that this software may be used to reproduce materials, it is licensed to you only for reproduction of non-copyrighted materials, materials in which you own the copyright, or materials you are authorized or legally permitted to reproduce.

これは分かりやすい。この文章の意図は、「このソフトウェアは、著作物を複製する可能性がある」と警告しているのだ。翻訳では、文章の途中でぶった切ってしまっているので、訳のわからないものになっているのだ。一体どこの馬の骨が、materialをマテリアルと翻訳して、しかも具体的な定義を与えないことが、いいアイディアだと考えたのだろうか。英語におけるmaterialは改めて定義する必要がない法律用語であったとしても、日本語における「マテリアル」は、そうではない。

しかし、最も問題なのは、以下の文章だ。

２．許諾された使用方法およびその制限
A.　本契約の規定に従い、お客様は、一回につき一台のApple商標が付されたコンピュータにAppleソフトウェアを１部インストールし、使用するための限定的な非独占的ライセンスを付与されます。

Apple商標が付されたコンピュータ？　それはつまり、Appleが販売しているコンピューターのことであろう。しかし、このAppleソフトウェアは、Safari for Windowsである。私のコンピューターは、Appleが販売しているコンピューターではない。とすると、私はSafariの使用許諾の条件を満たしていないことになる。この条件を満たすユーザーとは、Boot CampでWindowsを使っているユーザーに限定されてしまう。

ちなみに、原文では以下のようになっている。

2. Permitted License Uses and Restrictions.
A. Subject to the terms and conditions of this License you are granted a limited non-exclusive license to install and use one copy of the Apple Software on each computer owned or controlled by you.

Apple商標が付されたコンピューターなどという文面はない。

JavaScriptの難読化におすすめのサービス

2011-11-26T18:47:00.001+09:00

aaencode - Encode any JavaScript program to Japanese style emoticons (^_^)

alert("Hello, JavaScript")

という何の変哲もないJavaScriptのコードが、

ﾟωﾟﾉ= /｀ｍ´）ﾉ ~┻━┻   //*´∇｀*/ ['_']; o=(ﾟｰﾟ)  =_=3; c=(ﾟΘﾟ) =(ﾟｰﾟ)-(ﾟｰﾟ); (ﾟДﾟ) =(ﾟΘﾟ)= (o^_^o)/ (o^_^o);(ﾟДﾟ)={ﾟΘﾟ: '_' ,ﾟωﾟﾉ : ((ﾟωﾟﾉ==3) +'_') [ﾟΘﾟ] ,ﾟｰﾟﾉ :(ﾟωﾟﾉ+ '_')[o^_^o -(ﾟΘﾟ)] ,ﾟДﾟﾉ:((ﾟｰﾟ==3) +'_')[ﾟｰﾟ] }; (ﾟДﾟ) [ﾟΘﾟ] =((ﾟωﾟﾉ==3) +'_') [c^_^o];(ﾟДﾟ) ['c'] = ((ﾟДﾟ)+'_') [ (ﾟｰﾟ)+(ﾟｰﾟ)-(ﾟΘﾟ) ];(ﾟДﾟ) ['o'] = ((ﾟДﾟ)+'_') [ﾟΘﾟ];(ﾟoﾟ)=(ﾟДﾟ) ['c']+(ﾟДﾟ) ['o']+(ﾟωﾟﾉ +'_')[ﾟΘﾟ]+ ((ﾟωﾟﾉ==3) +'_') [ﾟｰﾟ] + ((ﾟДﾟ) +'_') [(ﾟｰﾟ)+(ﾟｰﾟ)]+ ((ﾟｰﾟ==3) +'_') [ﾟΘﾟ]+((ﾟｰﾟ==3) +'_') [(ﾟｰﾟ) - (ﾟΘﾟ)]+(ﾟДﾟ) ['c']+((ﾟДﾟ)+'_') [(ﾟｰﾟ)+(ﾟｰﾟ)]+ (ﾟДﾟ) ['o']+((ﾟｰﾟ==3) +'_') [ﾟΘﾟ];(ﾟДﾟ) ['_'] =(o^_^o) [ﾟoﾟ] [ﾟoﾟ];(ﾟεﾟ)=((ﾟｰﾟ==3) +'_') [ﾟΘﾟ]+ (ﾟДﾟ) .ﾟДﾟﾉ+((ﾟДﾟ)+'_') [(ﾟｰﾟ) + (ﾟｰﾟ)]+((ﾟｰﾟ==3) +'_') [o^_^o -ﾟΘﾟ]+((ﾟｰﾟ==3) +'_') [ﾟΘﾟ]+ (ﾟωﾟﾉ +'_') [ﾟΘﾟ]; (ﾟｰﾟ)+=(ﾟΘﾟ); (ﾟДﾟ)[ﾟεﾟ]='\\'; (ﾟДﾟ).ﾟΘﾟﾉ=(ﾟДﾟ+ ﾟｰﾟ)[o^_^o -(ﾟΘﾟ)];(oﾟｰﾟo)=(ﾟωﾟﾉ +'_')[c^_^o];(ﾟДﾟ) [ﾟoﾟ]='\"';(ﾟДﾟ) ['_'] ( (ﾟДﾟ) ['_'] (ﾟεﾟ+(ﾟДﾟ)[ﾟoﾟ]+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ (ﾟΘﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_^o) +(o^_^o))+ ((o^_^o) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_^o) +(o^_^o))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+((ﾟｰﾟ) + (ﾟΘﾟ))+ (c^_^o)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟｰﾟ)+ ((o^_^o) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟΘﾟ)+ (c^_^o)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ ((ﾟｰﾟ) + (o^_^o))+ (ﾟДﾟ)[ﾟεﾟ]+((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟｰﾟ)+ (c^_^o)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟΘﾟ)+ ((o^_^o) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ (ﾟΘﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_^o) +(o^_^o))+ ((o^_^o) +(o^_^o))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ (ﾟΘﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_^o) - (ﾟΘﾟ))+ (o^_^o)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ (o^_^o)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_^o) +(o^_^o))+ ((o^_^o) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟΘﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_^o) +(o^_^o))+ (c^_^o)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_^o) +(o^_^o))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟｰﾟ)+ ((o^_^o) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟΘﾟ)+ (ﾟДﾟ)[ﾟoﾟ]) (ﾟΘﾟ)) ('_');

という、訳のわからないコードに変換される。

アルゼンチン、ビッグマック指数を操作

2011-11-22T00:15:00.001+09:00

ビッグマック指数へのある対策 - himaginaryの日記
 Sentences to ponder — Marginal Revolution

そこまでしてインフレ率を低く見せかけたいのか。ここまで来ると喜劇だ。

信じられん

2011-11-19T17:32:00.001+09:00

この工作精度はすごい。

Windowsに日本の歴史的な年号を追加する方法

2011-11-17T06:07:00.001+09:00

Extending the Windows Japanese Calendar Era information. - I'm not a Klingon

Windows 7/8ならば、レジストリに追加することで、日本の歴史的な年号を追加することができる。

もっとも、年号などいいかげんに滅びるべきである。我々はある時間を起点として線形にインクリメントされていく年号を採用すべきなのだ。年号に対する個人的な反対運動として、私は今年が平成何年であるかを覚えるのをやめている。

しかし、英語の月は数字を使っていないので、日本語と英語に関して言えば、日本が致命傷で引き分けといえるだろう。

Skyrimのデザインについて思う

2011-11-10T21:40:00.000+09:00

Skyrimの発売まで、間近になっている。まだ発売されていないとはいえ、Skyrimの内容については、事前の発表でだいたい明らかになっている。それをまとめているWikiも存在する。

Skyrim:Skyrim - UESPWiki

この情報を元に、Skyrimについて考察しようと思う。

Skyrimは、明らかに複雑性を減らす努力をしている。たとえば、Oblivionでは、八つの基本能力、Strength, Endurance, Intelligence, Willpower, Agility, Speed, Personality, Luckがあった。Health, Magicka, Fatigueなどは、これらの能力とレベルアップによる加算によって計算される従属的な能力であった。さらに、剣の威力は、剣自体の強さが、基本能力StrengthとLuck、スキルBladeによって修正された値であった。だいぶ複雑である。

Skyrimでは、この仕組が、だいぶ単純化されている。Skyrimにおける基本能力は三つ、Health, Magicka, Staminaだけである。もうStrengthやLuckは存在しないので、剣の威力は、単にOne-Handedによって修正されるだけである。

私は、この複雑性を下げることが、快適なゲームプレイにつながると思っている。かつてのゲームは、もっと複雑だったのだ。たとえば、Daggerfallでは、走る、泳ぐ、壁を登る、ジャンプするなどといった動作にそれぞれ独立したスキルが存在したし、避けるだとかクリティカルだとかいうスキルもあったし、ある種の敵と友好的になれるスキルもあった。これは、当時はハードの制約で、複雑性を誇れるものが、結局これぐらいしかなかったのである。

今や、ハードは素晴らしく進化した。リアルタイムなシェーダーによる3Dレンダリング、プロシージャルアニメーション、フルボイスは、全く珍しくない。とすれば、複雑性は、このような数値で実現する必要はないのだ。もっと別方法でいくらでも実現できる。

たとえば、MorrowindにあったMark/RecallやLevitationは、存在しない。これはべつに、技術上の問題ではない、自由にワープできたり空を飛べたりすると、ゲーム制作が非常に制限される。あらゆるダンジョンやらクエストは、ワープや飛行の存在を前提に設計しなければならない。聞説、Morrowindでは多くのクエストのアイディアが、「オゥイェア、そんなのレビテーションで切り抜けりゃいいじゃんHAHAHA」などというスタッフのツッコミによって、断念せざるを得なかったらしい。

興味深い話

2011-11-10T21:12:00.002+09:00

The assault on Los Alamos National Laboratory: A drama in three acts

まあ、一言で言うなら、お役所仕事。

うおおおお！

2011-11-08T18:15:00.001+09:00

Twitter / @Flast_RO: ｷﾀｰｰｰｰｰｰｰ喜べ野郎ども！！！！
Bug 45114 – implement C++0x alias-declaration

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

どうやら、Template Aliasまで含んでいるらしい。

JoystickAPIが欲しい

2011-11-08T01:44:00.003+09:00

JoystickAPI - MozillaWiki

これは是非とも欲しい機能だ。これさえあれば、もうゲームのプラットフォームはブラウザだけで完結できることになる。

TPPへの反対を表明する

2011-11-08T01:34:00.000+09:00

The complete Feb 10, 2011 text of the US proposal for the TPP IPR chapter | Knowledge Ecology International

5. Each Party shall provide that, where the term of protection of a work (including a photographic work), performance, or phonogram is to be calculated:

(a) on the basis of the life of a natural person, the term shall be not less than the life of the author and 70 years after the author’s death; and

(b) on a basis other than the life of a natural person, the term shall be:

(i) not less than 95 years from the end of the calendar year of the first authorized publication of the work, performance, or phonogram, or

(ii) failing such authorized publication within 25 years from the creation of the work, performance, or phonogram, not less than 120 years from the end of the calendar year of the creation of the work, performance, or phonogram.

アメリカの壊れた著作権法を押し付けられるいわれはない。これ以上著作権の保護期間を延ばす必要はない。今保護期間が延びるということは、将来も延びる可能性があるということだ。つまりそれは、著作権は永続するも同義である。

結局、戦前の死後30年の保護期間は、妥当だったはずだ。

Skyrimがやりたい

2011-11-03T20:27:00.003+09:00

Skyrimがやりたいが、やれない。

Skyrimがそろそろ発売される。もっとも、日本では12月まで待たなければならない。Bethesda公式ブログで11.11.11ワールドワイドなどと宣っているが、真っ赤な嘘である。

Skyrimは是非ともプレイしたいゲームだ。しかし、残念ながら、今プレイするわけにはいかない。金がないのだ。Skyrim自体はSteamで$59.99だが、Skyrimをプレイするためには、新しいGPUが必要である。まあ、GTX560あたりを買うと考えても、やはりしめてニ万はかかるであろう。

金のないだけが問題ではない。Skyrimはキリのないゲームである。まともに遊ぼうとすると、恐らく一年ほど飽きがこないであろう。当然、C++本の執筆にも差し支える。他の凡ゲーならば、せいぜい十数時間もあれば飽きてしまうから、まあ、息抜きに遊んでも、特に問題はない。ただし、Skyrimだけは別物なのだ。疑うことなく約束された神ゲーである。

まあ、どうせBethesdaのことだから、見切り発車で発売してバグだらけ、パッチに半年は待たなければならないだろうし、DLCもいくつか出るだろうし、MODも揃ってから遊んだほうが便利だが、やはり神ゲーを遊べないのはつらい。

思えば、今年は大作が多かった。それにもかかわらず、去年と今年は、一切ゲームをしていない。もちろん、すべて遊ぶ価値のないクソゲーだったからだ。もっとも、実際にプレイしたわけではなく、レビューやプレイ動画を見ての感想だから、所詮は動画評論家のそしりを免れないが、それでも、みているだけでつまらなそうなゲームは、実際つまらないに違いない。

まずBulletstormだ。これは、Trailerを見ると、面白そうだった。それに、Duty Callsというパロディゲームをマーケティング用に出したのも興味深かった。

ただし、実際のゲームは振るわなかった。つまらない単調な一本道ゲームだった。しかも、最後は続編を匂わせるクリフハンガーで終わるという、真につまらないゲームだった。

お次はCrysis 2だ。いや、Crysis 2に限って言えば、クソゲーというほどひどかったわけではない。ただ、どこにでもあるような平凡なゲームだったのだ。グラフィックはそれなりによかったが、戦略のカケラもない一本道ゲームだった。まあ、戦略はあった。Cloakで殆どの敵はやり過ごせるのだから。これまた、クリフハンガー的な終わり方をするプロットだった。まあ、確かにブランドは大事だが、露骨にクリフハンガーにしても面白いわけがない。思うに、Crysis 2はゲームなどではなく、CryEngine 3の技術デモだったのではあるまいか。それぐらい、ゲームらしくないゲームだった。

さて、いよいよDuke Nukem Foreverだ。最も、最近の若いもんはDuke Nukemもしらんじゃろうが、かつては伝説のゲームだったのじゃて。DNFが発売されてしまったのは、真に残念なことだった。夢は夢として、いつまでも夢見ていたほうが幸せなのだ。現実は常に夢よりクソである。Duke Nukem Foreverは、5年前に発売したならば、まあ、そこそこなゲームだったに違いない。クソゲーなことには変わりないが、まあ当時の水準ならば、普通以下程度の評価は得られたに違いない。今となっては・・・いや、よそう。もう何も言うまい。

Rageである。Rageも長い間開発していたゲームだった。Doom 3は真っ暗なゲームだった。私が思うに、Doom 3は全ピクセルに黒をアルファブレンドすれば、もっとも効率よく実装できたのではあるまいか。それぐらい暗かった。それはさておき、伝説のゲーム開発会社idと、伝説のゲームプログラマーJohn Carmackの送る最新ゲームRageは、非常に期待されていた。思うに、我々はRageを過剰に期待しすぎていたのではないだろうか。それも無理はない。何しろ、2008年のE3におけるTrailerが、今から見ると詐欺臭いほどのクオリティだったからだ。

これをみれば、過剰に期待するのも当然である。結果は散々だった。メガテクスチャーは20GBもの容量を使い、しかも視点を動かすだけで貼り遅れるという散々な出来であった。しかもボケボケで見るに耐えない。オープンワールドでもないのに、無駄に車や移動といった要素がある。聞説、FPS部分はよくできていたらしい。もっとも、頻繁に移動しなければならないが苦痛だったらしいが。それでも、プレイ時間はたったの十数時間と聞く。プロットなどあってないようなもの。エンディングもエンディングのようには感じられない。何もかもが中途半端なのだ。クリフハンガーですらないのだ。ひょっとしたら、もうこれ以上収集がつかなくなり、とりあえず開発資金を回収しようと、無理やり出荷したのではあるまいか。実際、開発に相当の金がかかっているはずである。最後はBethesdaに身売りまでしたのだから。

こうしてみると、今年は遊ぶべきゲームが一切なかったのだ。Skyrimは約束された神ゲーなので大丈夫だろうとは思う。遊べないのが本当に残念だ。

実は、今年はまだ、もう一本、大作（？）が控えている。Postal 3である。Postal 3も、DNFやRageに引けを取らないほど長く開発されているゲームである。何しろ土台がSourceエンジンなのだ。前作のPostal 2が神ゲーであったことは、議論の余地がない。しかし、長年の延期の末に、ようやくだして、果たして面白いものかどうか。その辺は疑問である。

Dartにおける代入可能について

2011-10-30T14:36:00.002+09:00

まず最初に英語で書いてから日本に訳すという方法で書いてみた。何か違いが出るだろうか。

Dartはoptional typeを採用している。ある変数に代入できない型を代入しようとした場合、静的型警告が発せられる。ただし、プロダクションモードで実行された場合は、実行に何の影響も及ぼさない。

int x = "hello" ; // static type warning

では、代入可能とは一体何か。どのように定義されているのか。13.4 Interface Typesで定義されている。

型Tが型Sに代入可能である場合、すなわち、s = t でtの型がTでありsの型がSである場合というのは、

TはSである。
```
int s = 0 ;
```
これは当然だ。.
Tはnullである。
```
int s1 = null ;
```
nullは、⊥という特別な型を持っている。これは、どんな型にも代入可能である。
TかS、あるいはその両方がDynamicであるとき。
```
void main()
{
    var s1 = 0 ; 
    s1 = 0.0 ; 
    s1 = "hello" ;

    var d = 0 ;
    double s2 = d ;
}
```
動的型intを持つdを静的型doubleを持つs2に代入しているが、これは代入可能である。したがって、static type warningは発せられない。確かに、実行時には型の不一致を起こすが、それは実行時にしか分からないので、静的警告は発しようがない。
SとTがジェネリック型I<...>であり、Tの型パラメーターが、それぞれSの対応する型パラメーターに代入可能な時。
```
void main()
{
    List<int> = <int>[] ;
    List<num> = <int>[] ;
    List = [ ] ; // List<Dynamic>
}
```

Assignable in Dart

2011-10-30T14:23:00.000+09:00

Dart use the optional type. When you assigned to a variable and it isn't assignable, a static type warning is issued. If the code is executed under the production mode, it doesn't affect run time behavior.

int x = "hello" ; // static type warning

So, what exactly is assignable? How is it defined? It's defined in 13.4 Interface Types.

A type T may be assigned to a type S, that is s = t where the type of t is T and the type of s is S, if

T is S
```
int s = 0 ;
```
This is obvious.
T is null
```
int s1 = null ;
```
null has the special type ⊥. It can be assigned to any type.
T or S(or both) are Dynamic.
```
void main()
{
    var s1 = 0 ; 
    s1 = 0.0 ; 
    s1 = "hello" ;

    var d = 0 ;
    double s2 = d ;
}
```
Notice assigning d(dynamic type of int) to s2(static type of double) is not a static type warning although it is incorrect in run-time. This is because it's assignable. If either T or S are Dynamic, it can't be determined in compile time. So it makes sense.
if S and T is a generic type of I<...> and T's type parameters are assignable to S's corresponding type parameters.
```
void main()
{
    List<int> = <int>[] ;
    List<num> = <int>[] ;
    List = [ ] ; // List<Dynamic>
}
```

What is it like buying a PC game in Japan?

2011-10-28T09:34:00.002+09:00

Today, I saw kotaku used an interesting metaphor to describe what is it like buying a PC game.
If Haruki Murakami's New Book Were Sold Like a Video Game

I think buying a PC game from Japan is also interesting to write about. Even without the metapher.

It started in January...

January
I've heard a famous game developer will release a new game in June. Wow that's too soon. I must pre-order it immediately. But I wonder where to buy it. And the most important thing is, is there a Japanese translation available?

February
It appears the game requires Steam activation. So the package means nothing. I don't need some junk toys they'll include in the package. I wonder who want that crap. I can't understand what Americans are thinking. Anyway, I pre-order it in so called Steam. It allows me to download a game. That's nice. The Japanese Steam listed it up and allows me to pre-order. So it should work. And I've heard they'll release console version of this game in Japan. So naturally, PC version must have Japanese translation.

March
They announced that Japanese translation will be released in August. Well, that's okay. I guess translation need some time. I've also heard they even translate the voice. That's fine. Perhaps I should try English version while waiting. It's completely incomprehensible for me. But who needs story in game anyway? This is not a dull linear JRPG. That's why I'll buy it. I'm so sick of crappy JRPG. Look at the world. Think globally. I can look up words from dictionary if I have to. I'll enjoy the combat in the English version. Then, I'll enjoy the story later in the Japanese version.

April
What Steam? What do you mean I can't buy it from the current location? I am Japanese and sure I live in Japan. Yes I know this is the English version. I want to play regardless and I'm willing to pay. Why don't you let me buy it? Don't you want my goddamn money? This is stupid. I can't understand it. I don't care how much you charge me. I've read from the online forum that we can bypass that check by using what they call it VPN or whatever. I don't know how that works. Also, there are pirates as usual. But I'm not one of them. Besides, I don't know how to pirate a game.

June
At last. The English version is released. I think some people who used VPN will write something in forum. I should better check it... What? Not only they play it today, But they play it in Japanese? How could that even be possible? Well, come to think of it, console game will be released in a few days. So technically, translation works must have been finished already. So what is the point of delay? Why do I have to wait two months!

July
Wow. This is hilarious. They said Steam deleted Japanese translation from their disks. Apparently, It wasn't supposed to be released. But why. Just release the Japanese version already. I don't want to wait any more. Also, why do they allowed to delete files in our disks? I don't understand.

August
What is this? What the FUCK is this? They said they'll delay the release until next year. No. Seriously. That can't be possible. I have enough of this Steam.

Dartがダウンキャストに警告を出さない理由

2011-10-22T23:52:00.001+09:00

Dartでは、ダウンキャストには警告を発しない。

class S { }
class T extends S { }

void main()
{
    S s = new T() ; // アップキャスト
    T t = new S() ; // ダウンキャスト
}

この例では、静的型Tの変数tに対して、静的型Sで、実際の型もSのインスタンスを束縛させているが、これは警告を発しない。アップキャストに警告を発しないというのは自然だが、ダウンキャストに警告を発しないというのは、オブジェクト指向に馴染みのない人からすれば、不思議に思われるかも知れない。現にこの場合、実際の型はTではないのだから、この場合に限っていえば、エラーである。しかし、これは正しい挙動である。では、なぜ警告を発しないのか。

なぜならば、規格に明確に書かれている挙動だからである（13.4 Interface Types）。クラスは暗黙のインターフェースを持つので、この項目はクラスにも適用される。

規格で定義されているとしても、理由はなぜか。それは、Dartの型システムは、ほぼ確実に間違いであろうと思われるコードを見つけるためにあるからだ。間違いである可能性があっても、正当なコードである可能性もあるコードに対しては、警告を発しない。

ダウンキャストは、オブジェクト指向言語ならば、当然行うことである。

class S { }
class T extends S { }

void main()
{
    S s = new T() ; // アップキャスト
    T t = s ; // ダウンキャスト
}

これは、正しいコードである。変数sに束縛されているインスタンスの型は、まぎれもなくTである。したがって、このダウンキャストは正しい。もしこのコードに警告が発せられるとするならば、それは誤りである。このコードに警告を発するようでは、プログラマーは警告というものを信用しなくなってしまう。警告というのは、ほぼ確実に誤りである場合にのみ発せられるべきなのだ。

SとかTなどのやや抽象的な話ではわかりにくい人もいるかも知れない。もっと具体的な話をしよう。Dartではすべてのクラスは暗黙にObjectのサブクラスである。以下のコードは当然動くべきである。

void main()
{
    Object obj = "hello" ;
    String str = obj ; 
}

明らかに、このコードは正しいコードである。

Bitcoinについて

2011-10-21T22:47:00.003+09:00

Coding Horror: Multiple Video Cardsが、Bitcoinのお陰で中古GPUを格安で手に入れられたと書いていたので、Bitcoinの歴史と現状をまとめて見ることにした。

そもそも、諸君はBitcoinを知っているだろうか。いや、知らなくても無理はない。日本では、あまり有名ではないように思う。だから、まずBitcoinとは何かという説明をしようと思う。

Bitcoinとは、演算保証によって信頼を得ている貨幣である。およそ、貨幣というものが広く一般に使われるには、貨幣に対する何らかの信頼が必要である。たとえば、貨幣が金と交換できる保証であるとか、国による保証などといった、信頼が必要である。そのような強い保証のない貨幣は、広く信頼を得ることができず、一般に普及することはない。

Bitcoinは、P2P技術によって実装されたオンライン上の仮想貨幣である。すべての貨幣のやり取りはP2Pによる演算で処理され、個々の貨幣のやり取りは匿名で行うことができる。と、こう書いただけでは、信用のカケラも存在しない貨幣のように思われる。金と交換できず、国家の保証もない貨幣が、どうして信頼できるというのか。だいたい、どうやって偽造を防ぐのだ。それは、演算力である。

Bitcoinを得るには、演算をする必要がある。それも、かなりの演算が必要である。Bitcoinの貨幣のやり取りをP2P上で信頼できるほどに処理するには、暗号を使わなければならない。この暗号処理には、かなりの演算力を必要とする。Bitcoinを得るには、オンライン上でのbitcoinのやり取りに必要な演算の一部を負担する必要がある。すると、Bitcoinを不正に入手するというのは、つまりは暗号を解読するということである。それには、Bitcoinを普通の方法で得るより、はるかに高い演算力を必要とする。このため、Bitcoinの偽造は割にあわないということになる。ただし、誰かがSHA256の画期的な脆弱性を発見した場合は、この限りではない。Bitcoinネットワークを攻撃するには、Bitcoinネットワーク全体の演算力を上回る演算力が必要である。その演算力は、現在のBitcoinネットワークの規模から考えて、現実的ではない。

つまり、Bitcoinの信頼は、演算力とSHA256の暗号強度に依存しているといえる。金銀に交換することはできず、国家の保証もないとはいえ、不正ができないという点で、信頼を得ているのである。

Bitcoinの他の利点としては、国家の影響を受けないということと、プライバシーを守れるということである。国家が貨幣を管理していると、意図的に貨幣の価値を上下させられる可能性がある。Bitcoinの価値は、ユーザーが決定する。そのような中央の権威の影響は受けない。プライバシーというのは、貨幣の動きを特定されないということである。これは、ともすれば麻薬取引などの違法な売買や、脱税などの金銭の動きにも使われがちであるが、それは、別にBitcoinに限った話ではなく、金銀や紙幣でも同じなので、Bitcoin特有の問題というわけでもない。

では、Bitcoinの作者は誰か。これが、どうも怪しいのだ。もちろん、記録は残っている。2008年にSatoshi Nakamotoと名乗る自称日本人によって、Bitcoinの理論と仕様を説明する論文が発表された。最初の実装も、彼によって書かれた。しかし、彼は一言も日本語を発していないし、実装にも日本語は一切使われていない。彼の2010年以降の消息は不明である。彼のメールアドレスは、無料のメールサービスを利用しており、すべての接続は、Tor経由で行われていた。つまり、彼はありとあらゆる方法を使って、匿名性を保つ努力をしていたのである。日本人を自称したのも、事によると、正体を隠すための方便だったのかもしれないとまで言われている。

なんにせよ、Bitcoinの仕組み自体には、未だに脆弱性が見つかっていないし、Bitcoinで使う有名な暗号、SHA256も、未だに画期的な脆弱性は見つかっていない。

さて、Bitcoinは不正が難しいので、最低限の信頼性を備えていることは分かった。Bitcoinの仕様はすべて公開されており、オリジナルの実装以外にも、いくつかの別の実装がでてきた。とくに興味深いのは、演算にGPUを利用した実装である。GPUはCPUほど汎用的ではないが、うまく使えば、CPU以上の演算力を発揮できる。このため、Bitcoin mining（Bitcoin炭鉱業）と呼ばれる、いわばゴールドラッシュのような現象が起きた。高価なGPUが、Bitcoinを稼ぐために多数売れたのである。

Bitcoinはその期待によって、現実の貨幣（例えば米ドル）と交換する所が現れた。その交換レートが高かったので、高価なGPUと電気代を差し引いても、利益が出せたのである。

しかし、ゴールドラッシュが長く続くわけがない。Bitcoinはその多大な期待によって、実価値以上に高い交換レートで、現実の貨幣と交換されてきた。今や、そのバブルがはじけて、Bitcoinの現実貨幣に対する交換レートは暴落し、Bitcoin炭鉱業は以前ほど儲からなくなってしまった。国家や中央銀行のように、貨幣の価値を一定に保つ権威が存在しないのだから、これは当然である。ゴールドラッシュで儲けたのは、シャベルとツルハシを売っていた者であるというのはよく言ったものだ。ハイエンドGPUが山ほど売れたのだ。

そのため、ハイエンドGPUが中古市場に溢れ、冒頭でも言ったように、Jeff Atwoodとかのゲーマーがその恩恵を受けている。

もちろん、これはBitcoinの為替が適正なレートに下がっただけであり、Bitcoinの暗号自体は、未だに破られていない。

Bitcoinの合法性であるが、独自通貨の発行が合法かどうかということにかかっている。これは、国ごとに違うので、なんとも言えない。ただし、オンラインでの売買の興隆をみれば、独自通貨の発行自体は、将来的には大抵の国で合法になる方向に動くだろう。さもなければ、ゲームやPaypalのようなサービスが成り立たない。

私自身はBitcoinには興味がなかったのだが、知り合いに、Bitcoinの仕組みに共感し、自分でも実装を書き、ハイエンドGPUでせっせと掘っている人物がいるので、近況を聞いてみた。彼は、単に技術的な好奇心のためにやっているのであって、小遣い程度の金には興味がなく、したがって、最近のBitcoinと現実貨幣の交換レートの暴落は気にしていないらしい。

私はふと、このBitcoinが、一時期のP2P技術を利用したファイル共有に対する期待に似ているのではないかと思った。あの当時、P2P技術を利用したファイル共有には、なにかゴールドラッシュのような期待があった。確かに、現時点では違法かもしれないが、それは法律が現実に追いついていないだけであって、将来的には素晴らしい可能性を秘めているのではないかという期待があった。

現実としては、法律は一向に変わらず、P2P技術は、Skypeを始めとする通信、ソフトウェアのアップデートの配布などの、裏方技術には使われているが、表立って存在を意識するほどではなくなってしまった。Bitcoinも同じような過剰の期待に押されていたのではないだろうか。

このような意見を、かの知り合いにぶつけてみたところ、彼はこれを認めた。曰く、「たしかに、そういう過剰な期待があるのかもしれない」と。「Bitcoinに触発された後発の仕様もいくつか出ている。Bitcoinは、実際の価値はさておき、コンセプトとして一定の価値があることは確かだろう」とも言っていた。

国家に左右されない貨幣が主流になる時代は来るのだろうか。

アイドック株式会社、紙書籍と電子書籍の抱き合わせ商法を発表

2011-10-21T19:42:00.002+09:00

デジタル著作権管理（DRM）ならキーリング｜愛読者カード運営代行サービス「i 読（あいどく）」提供開始！！
i読…愛読者カード運営代行サービス
via : これで自炊は不要？愛読者カード返送者にのみ電子書籍を配信する「i読」 -INTERNET Watch

レコードをカセットテープに録音する？　おいおい、何言ってやんでぇ。そんなのオイラの目の黒いうちゃぁ許しちゃおけねぇよ。レコード針やターンテーブルの生産会社が潰れちまうだろうがよ。代わりにこれ、レコードを買うと録音したカセットテープをプレゼント。あ、ほら、もう録音なんてする必要がねぇってもんだ。これにて一件落着。あっぱれあっぱれ。

DTP？　よしてくれよ、写植職人が路頭に迷うぞ。最低限でもだな、今の写植と同じ仕組みでなければな。もちろん操作方法も同じだ。

活版印刷？　おいおい、版木職人を飢え死にさせる気か？　まあ仕方がないから、版木本を買えば、活字本もおまけしてやろうじゃないかい。

版木？　そんなの許しちゃおけねぇ。真の書というものはよく手書く者によって写されるべきなんだよ。このままだと、写本職人が失業するだろうがよ。そこでこれ、写本を買うともれなく版木本をプレゼント。

紙？　おいおいバカ言っちゃいけねぇや。日常の文章は木簡や竹簡に書いて、高級な文章は絹に書くのが常識だろうがよ。紙なんていう最近できたもんに字なんか書けるかってんだ。

字？　おまえなぁ、生きておる智慧が、字などという死物に書きとどめられるはずがない。絵にならまだしも画けようが。それより口伝の続きじゃ。さて我がご先祖は～、怨敵をことごとく討ち平らげ～、この地に来たりて安住し～。さあ覚えるんじゃ。

EUがRFC 3751の実装を検討中

2011-10-20T17:28:00.000+09:00

EU Parliament Debates Installing A Black Box On Your Computer
via: EU Debates Installing a Black Box On Your Computer - Slashdot

EUがRFC 3751の実装を真剣に考えているらしい。

RFC 3751 - Omniscience Protocol Requirements

Dartで誤って無限ループに陥るコード

2011-10-19T07:00:00.002+09:00

Dartは非常にシンプルな言語であるが、恐らく初心者が、誤って無限ループに陥ると思われる箇所がいくつかある。

ファクトリーコンストラクター

class X
{
    factory X() =>  new X() ; // 無限ループ
} 

void main()
{
    X x = new X() ;
}

このコードは、無限ループに陥る。なぜならば、new X()というのは、ファクトリーコンストラクターXを呼び出す式である。これは、つまり自分自身を再帰呼び出ししていることになる。結果として、無限ループになる。

正しいファクトリーコンストラクターの書き方は、別のコンストラクターを呼び出すものである。

class X
{
    X.internal() { }
    factory X() => new X.internal() ;
}

クラスのゲッターとセッター

クラスのゲッターとセッターは、クラスの変数への簡単な読み書きを提供するための特殊なメソッドである。これは、暗黙に生成される。

class X
{
    int val = 0 ;
// 以下のようなゲッターとセッターが暗黙的に生成される
    // int get val() => val ;
    // void set val( int value ) { val = value ; }
}

void main()
{
    X x = new X() ;
    x.val ; // ゲッター呼び出し
    x.val = 0 ; // セッター呼び出し
}

ご覧のように、セッターとゲッターは関数であるが、特別な文法で呼び出すことができるのだ。

サブクラスでは、この暗黙のゲッターとセッターをオーバーライドすることができる。つまり、ゲッターとセッターで、なにか複雑な処理を行うこともできるのだ。

class X { int val = 0 ; }
class Y extends X
{
    int get val() => val ; // 無限ループ
}

これは無限ループとなる。なぜか。考えてみて欲しい、クラスYのスコープにおけるvalとは何なのか。それは、もちろんYのスコープで宣言されているvalである。つまり、Yのゲッター関数valということになる。これは、自分自身の再帰呼び出しである。つまり、無限ループになる。

正しいサブクラスによるゲッターとセッターのオーバーライドは、スーパークラスのゲッターとセッターを呼び出すものである。

class X { int val = 0 ; }
class Y extends X
{
    int get val() => super.val ;
 
}

これで、再帰呼び出しは起こらない。

ちなみにいうと、ゲッターとセッターはトップレベル関数でも使える。

int _val = 0 ;

int get val()
{
    print("このままでは菌類が死滅してしまう") ;
    return _val ;
}

void set val( int value )
{
    print("勉強でも仕事でも　楽しんでやったものが、一番自分の力になるものさ。") ;
    _val = value ;
}

void main()
{
    int x = val ;
    val = 1 ;
}

ChromeがText-to-Speech APIを提供

2011-10-19T06:20:00.002+09:00

Chromium Blog: New Text-to-Speech API for Chrome extensions

Chromeがエクステンション向けにText-to-Speech APIを提供するらしい。これは面白そうだ。

Dartの興味深い機能

2011-10-18T20:09:00.000+09:00

named parameterとnamed argument

void f( int x, [ int y = 0, int z = 0 ] ) { }

void main()
{
    f( 0 ) ; // f( 0, 0, 0 )
    f( 0, 1 ) ; // f( 0, 1, 0 ) 
    f( 0, z : 1 ) ; // f( 0, 0, 1 ) 
}

まあ、コードを読めば一目瞭然の機能だろう。省略可能なのは、named parameterだけである。名前を指定できるのも、named parameterだけである。normalFormalParameterは省略も名前指定もできない。

noSuchMethod

class X
{
    void noSuchMethod( String function_name, List args )
    {
        print("$function_name") ;
        for ( var elem in args )
        { print("$elem") ; }
    }
}

void main()
{
    X x = new X() ;
    // 関数名と実引数が表示される
    x.f() ; 
    x.hoge(1,2,3,4,5) ;
    x.fuga("All base is belong to us.")
}

これは解説が必要だろう。もし、クラスからメソッド名のlookupに失敗した場合、そのクラスからnoSuchMethodという名前のインスタンスメソッドが探され、第一引数としてメソッド名を、第二引数として、実引数のリストを渡し、呼び出されるのだ。もし、noSuchMethodという名前のインスタンスメソッドがなければ、NoSuchMethodExceptionが投げられる。

ということはだ、noSuchMethodというインスタンスメソッドを定義していれば、あたかもoperator .を定義したかのように振る舞うのだ。もちろん、実際にはoperator .はないし、メソッド呼び出しにしか適用できないが、DSLオタクは歓喜するだろう。

typedef

typedef int func_type(int) ;

void f( func_type func )
{
    int x = func( 0 ) ;
}
main()
{
    f( (int x) => x + 1 ) ;
}

typedefは、静的型の別名を定義するための構文である。現在のところ、関数の静的型の別名を定義することしかできない。

これはなぜかというと、関数は、具体的な静的型を直接に指定するのは面倒なのだ。こんなふうになってしまう。

void f( int func(int) ) { }

インターフェースFunctionはあるが、あまりにアバウトすぎる。だから、厳密な静的型を意味する識別子を定義するために、このtypedefが存在する。

べつに、これを使う必要はない。たとえば、varで受けても問題ない。DartはOptional Typeを採用しているからだ。静的型は実行時には、ほとんど意味がない。

量子浮遊

2011-10-18T04:35:00.002+09:00

こいつは最高にクールだ。

さっそくDartの規格上のバグを発見

2011-10-17T19:12:00.004+09:00

私の唯一誇れる能力は、読解力である。そのため、私がプログラミング言語の規格を読むのを好むのは、自然なことである。このたび、Dartの規格上のバグを発見した。なかなか笑えるので紹介する。もちろん、実装者にとっては洒落にならないが。

以下のコードは、現行ドラフトの文面に従うと、well-formedなDartコードである。

main()
{
    a : { break a ; }
    b : { continue b ; }
}

なぜかというと、現行のDartのドラフト規格は、ラベル付きのbreak文とcontinue文は、label文の中に入ることができるとされている。ラベル文には、文を書ける。また、ブロック文も文である。よって、Label : { } はwell-formedなDartコードであり、その中でbreakやcontinueを使うのもwell-formedである・・・はずだ。

傑作だったのは、現行の実装が、このコードを実際にコンパイルできてしまうということだ。break文の方は、期待通りに動いた。つまり、

a : { print("before") ; break a ; print("after") ; }

は、beforeを出力する。

continue文の方は、コンパイルは通るが、実行時に、不思議なエラーを吐いて強制終了してしまう。もし規格通りに動いていたならば、無限ループになったはずだ。

この件はすでにバグ報告済みである。

DartのFlorian Loitschとのチャット

2011-10-17T12:11:00.001+09:00

IRCのチャットで興味深かったチャットの断片をいくつか。

ezoe: 単項マイナス演算子をユーザー定義するにはnegateを使わないといけないのはちょっと驚きだね。
floitsch:何か代案でも？
ezoe:いや、別に不満ってわけでもないけど、理解するのに戸惑ったし、パースでも早くなるのかな？
floitsch:-は二項演算子にすでに取られてるからね。
floitsch:もちろん、引数の数を見て判断することもできるけど、それは他ではやってない処理だから、"operator negate"を導入することにした。
ezoe:なるほど、つまり例外的なルールを作りたくなかったのか。

ezoe:そういえば~/演算子ってのもあるけど、他の言語でこの演算子を使ってるのは知らないな。
floitsch:多分ないよ。
floitsch:切り捨ての除算が欲しかったんだ。
TheSheep://?みたいな？
floitsch:そうそれ。
floitsch:それも考えたんだけど、すぐ却下した。
TheSheep:他の言語でも使ってるよ。
TheSheep:特にpythonとかｗ
ezoe:一行コメントみたいだね。
TheSheep:あ！
floitsch:ほらね
floitsch:他の言語で、/や//以外で、切り捨て除算の演算子があるなら、教えてほしい。

ezoe:ふーむ、>>>演算子もあるね。
floitsch:イエス
floitsch:僕が推したやつだよ。
ezoe:どのコアライブラリが何のために使ってるの？
floitsch:なにも。
ezoe:えーと、まあ、ユーザー宣言可能な演算子が増えるってのはいいことだけど、でもコアライブラリすら使ってないんじゃ・・・
floitsch:>>>はunsigned shiftを意味する。
ezoe:>>は？
floitsch:signed shift
floitsch:そもそも、無限の精度をもった整数のunsignedな値って何さ？
floitsch:だから、コアライブラリでは>>>を定義していないんだ。

TheSheep:dartのintってjavascriptではどの型に対応するの？　number？
floitsch:そう、JSのnumberさ。
TheSheep:それ固定精度じゃないじゃん。
floitsch:まあ、JSにコンパイルされたらdoubleさ。
floitsch:もちろん、それに起因する驚くべき挙動もそのままさ。
ezoe:なんだって？
floitsch:すべてのdartの数値は、JSのdoubleにコンパイルされる。
TheSheep:JSで動くツケさ。
floitsch:その通り
ezoe:そんなの整数じゃない・・・DartCが特別なコードを生成して多長演算をしてくれるかと思ってたのに。
floitsch:そりゃ遅すぎる。
TheSheep:そりゃ「遅い」
floitsch:そんなに悪くはないよ。
floitsch:ほとんどの数値は32bit以下だからね。
floitsch:それ以上が必要な場合は、開発者は分かるはずだ（Javaのlongとか）
ezoe:dart VMは任意の精度の数値を提供しているの？
floitsch:イエス

（末尾再帰最適化の話がでた後で）
ezoe:ファクトリーコンストラクターから同じコンストラクターをnew経由で呼び出してしまったことがある。俺は何を期待してたんだっていうｗ
floitsch:はは、結果を長く待たずに済んだことを祈るよ。
ezoe:でも、初心者は同じ間違いをすると思うんだ。
floitsch:直接の再帰呼び出しは、簡単に判定できるはずさ。
floitsch:IDEによって補足されて警告が出せるようになるといいかも。
ezoe:そうなってほしいな。うっかり書くこともありえると思う。

DartCではDartの数値をJavascriptのNumberにそのまま割り当てているとは驚きだった。JavascriptのNumberは、御存知の通り、内部的には浮動小数点数なのだ。まあ、大抵の場合は、その精度が気になることはないとはいえ、まさか規格で無限精度と定められているものを無視するとは。まあ、JSへのコンパイルは、移行措置のようなものなので、その程度の実装でも困らないのだろう。それより、数値計算の遅くなってしまうほうが問題だ。

ファクトリコンストラクターの条は、私がファクトリーコンストラクターを試したときに遭遇したうっかり間違いである。とりあえず、手っ取り早くファクトリーの文法を確かめようとして、以下のように書いてしまった

class X
{
    factory X()
    {
        return new X() ; // 再帰による無限ループ
    }
}

ファクトリークラスからは、別のコンストラクターを呼びださなければならない。

class X
{
    X.detail() { }
    factory X()
    {
        return new X.detail() ; // ファクトリーではないコンストラクターを呼び出す
    }
}

main()
{
    X x = new X() ; // ユーザーコードからはX.detailを使う必要はない

}

数学を学ぶべきなんだろうか

2011-10-16T02:46:00.001+09:00

Dartの規格に、次のような文がある。

The static type of null is ⊥.

The decision to use ⊥ instead of Null allows null to be assigned everywhere without complaint by the static checker.

現行のドラフト規格にはbeがニ連続するtypoあり。

この⊥が何を意味するのか分からなかった。しかたがないので、IRCで人に聞いた。

私：この⊥ってやつはなんだ？
人："bottom"
私：bottom？　何かプログラミングか数学の用語なのか？
人：lattice theoryから来てる。
人：top（本当は特別な文字があるけど）ってのがすべての上にたつ汎用的な存在で、たとえばObjectだね。
人：bottomは何よりも特殊な存在なんだ。
私：つまり、bottomであるnullからみれば、すべての型はスーパークラスのようなものだということか。
人：そういうこと。

ちなみに、topの記号は⊤で、UnicodeではU+22A4である。⊥はU+22A5である。

なぜか、昔から数学はさっぱり理解できなかった。高校生の時、理系クラスに進もうとしたら、親に反対された。特に普段、勉強しろとも言わない親ではあったが、子供の勉強を反対するというのも奇妙だ。その時の言葉が印象に残っている。

「あんたに数学は無理よ。私達にだってできなかったんだから」

まるで、なにか遺伝的、先天的に数学ができないかような物言いだったのである。私の両親はそれなりに高学歴である。これは一体どういうことか。

親の案の定、私は数学をさっぱり理解できず、高校時代は、古文、漢文、英文を読んで過ごした。なぜか、私の親と同じ道をたどっているのである。

思えば、私も変な子供だったものだ。何故か昔から読書が好きだったし、小学生の頃には、すでに古事記や論語や徒然草などを読んでいた。もちろん、これは親がそのような本を家に置いていたし、「論語のどこそこ」とか、「徒然草の第何段」といった会話が成立するほどの教養を持っていたからということもあるのだろうが、やはり不思議なことだ。何か、遺伝的なものがあるのだろうか。

今だって、私の感じるプログラミングの面白さとは、コードを書くのではなく、プログラミング言語の文法を理解することなのだ。何故こうなってしまったのだろう。

DartのOptional Typeについて

2011-10-15T17:32:00.002+09:00

Dartの素晴らしさがまだ分からない無知無識の者が、Dartの型システムについて深刻な誤解をしている。ここでは、Dartの型システムであるOptional Typeについて、ひとつ解説をする。これを読めば、Dartの如何に大昔のJavascriptより優れているかが、一目瞭然であろう。

強い静的な型付けは、C++のような、ほとんどを静的に決定する言語では非常に便利である。しかし、動的な言語では、むしろ邪魔にさえ感じる。

Dartの型システムは、Optionalである。型を明示的に書こうが書くまいが、自由である。

変数には、型を指定してもしなくてもよい。

var x = 0 ;
int x = 0 ;

関数の引数には、型を指定してもしなくてもよい。

int f( int x ) => x ;
f( x ) => x ;

ジェネリックのタイプパラメーターには、型を指定してもしなくても良い。

List<int> l = <int>[ 1, 2, 3 ] ;
List l = [ 1, 2, 3 ] ;

異なる型を代入することもできる。

int x = "肩のうしろの2本のツノのまんなかにあるトサカの下のウロコの右" ; // static type warning

これでは、型の意味が無いではないかと思う者もいるだろう。それは、Dartにおける型の目的を理解していないからである。Dartにおける型システムは、最適化のためにあるのではないのだ。ツールを助けるためにあるのだ。

まず、Dartの変数について一言説明しておかなければならない。Dartの変数とは、「メモリー上のストレージの場所を示す」ものである。これは、Javascriptのような言語に親しい物には、馴染み深い概念である。そのような言語に馴染みのないものには、とりあえず、ポインターだと考えておけばよい。もちろん、ポインターは、実際には異なる概念である。ポインターとは、やはり、メモリー上のストレージの場所を指し示す、すなわち「アドレス」を格納するために必要なだけのサイズのストレージであって、Dartの変数ではない。DartやJavascriptのような言語では、変数はすべてメモリー上のストレージへの参照であり、その参照を格納するストレージを意識することはない。

Dartにおける変数とは、内部的には、単にオブジェクトへの参照なのだから、型という仕組みがなかったとしても、不思議ではない。たとえば、DartやJavascriptでは、

var x = 0 ;
x = 1.5 ;
x = "肩のうしろの2本のゴボウのまんなかにあるスネ毛の下のロココ調の右" ;

このようなことができる。Dartにおける「代入」とは、単に変数が参照する場所を変えているだけである。変数自体は、固定されたストレージを持たないのだ。もちろん、実装上はストレージを持つが、それはユーザー側からは隠されている。

しかし、Javascriptのように、ソースコード上では、変数が型情報を持たないとすると、少々厄介である。

たとえば、ある変数はある型だと想定して使っているのに、うっかりと別の型を代入してしまったばかりに、型が変わってしまう。もちろん、コンパイルエラーどころか、警告すら出せないので、このバグを探すのは非常に難しい。プログラマーは、自分の目でバグを探さなければならないだろう。

Dartにおける型とは、言わばannotationなのだ。

int x = 0 ;
x = 1 ; // OK
x = 1.5 ; // Static type warning.

このように、型が合わない場合、コンパイル時に警告を出すことができる。そのため、プログラマーは目でコードを探す必要がなくなる。

現代では、IDEによるコード支援が盛んである。例えば、識別子を補完したり、メソッド名を補完したりしてくれるのは、非常に便利である。ところが、Javascriptのように型がないと、これは少し難しい。

var x = "肩ぐるまして後ろ向きに乗り2本のゴボウを持った歌舞伎顔の男" ;
x. // ←ここに注目

xという識別子に続いて、ドットを使っているのに注目してもらいたい。賢いIDEならば、ドットを打った時点で、プログラマーはメソッドを呼び出したいのだと解釈し、メソッドの一覧を表示してくれることだろう。ただし、この場合、xの型を静的に求めるのは難しい。

上記のような二例であれば、静的な解析でも可能である。ところが、Javascriptには、不可能な場合もあるのだ。

function f( x )
{
    x. // xは何かって？　(´・ω・`)知らんがな
}

これはどうしようもない例である。

Dartでは、型をannotationのように指定することができる。そのため、静的ツールは静的に型を決定することができる。

f( String x )
{
    x. // Dartならば、IDEによってメソッド名の一覧を表示可能(｀・ω・´)ｼｬｷｰﾝ
}

文法上、型を書くことができるというのは、コメントで書くよりもずっと分かりやすい。

var x = 0 ; // type of x suppose to be int. 
int x = 0 ; // horay! no comment is needed!

しかし、実行時に型が一致しなくても、エラーとはならない。つまり、実行を続けることができるのだ。ただし、警告は出るので、バグを見つけることができる。もし、型を固定したくなければ、varを使うこともできる。自由である！

Dennis Ritchieに関する良記事

2011-10-14T16:47:00.001+09:00

Rob Pike - Google+ - I just heard that, after a long illness, Dennis Ritchie…

氏の死去を始めて公にしたページ。

Dennis Ritchie, 70, Dies, Programming Trailblazer - NYTimes.com

NY Timesの記事。個人的な経歴もまとまっていて、なかなかの良記事。

Dennis Ritchie « Sutter's Mill

Herb SutterによるRitchieの回顧。Ritchieは、それまで不可能だと言われていた、portableでefficientな言語を発明した男である。

Interview with Dennis Ritchie, Bjarne Stroustrup, James Gosling

Herb SutterによるRitchieへのインタビュー。Ritchieは、ほとんどインタビューを受けない男であったので、貴重である。

何故Dartが史上最高の言語なのか

2011-10-13T22:19:00.001+09:00

史上最高にして、恐らく今世紀最高となるプログラミング言語は、Dartである。DartはC++以外の既存のプログラミング言語のほとんどを駆逐する事ができる潜在性能を持っている。これからの真のプログラマーは、C++とDartという二大言語に加え、目的に応じて、アセンブリやシェーダーなどの専用言語を学ぶことになるだろう。

Dartの美しさを理解出来ない近眼者が、愚にもつかぬ批判をしている。恐らく、彼らは規格書が読めないのであろう。曰く、「Javaのパクリ」、曰く、「目新しい新機能がない」。Javaのパクリという阿呆は、Javaのような聳え立つ糞の信者なのだろう。ただJavaと同じようなキーワードや文法を使っているからといって、それがJavaのパクリであるとは片腹痛い。Dartからみれば、Javaなど歯牙にもかけぬ愚物である。目新しい機能がないという批判もあたらぬ。およそ斬新な新機能というのは、人目を引くのは確かだが、一般に普及しがたいものである。

Dartは、すでにその価値を証明されている機能を、ごく自然に提供している言語である。いや、重要なのはむしろ、提供していないモノにこそある。Dartは、他の言語にあるような、不必要なクソを提供していない。例えば、パースが難しかったり、時間がかかるようなcontext sensitiveな文法はないし、複雑怪奇な暗黙の型変換も存在しない。この点において、改行が終端記号とみなされるJavascriptは、近い将来にDartの後塵を拝する事になるであろう。

Dartの主目的である、Javascriptの置き換えという目的には、ソースコードのコンパイルを高速に行えることがまず第一である。それには、パースが難しかったり、文脈に依存して意味が変わったりするような文法を、極力避けるべきである。Dartはこの点において、特に優れている。

例えば、Dartでは、二項マイナス演算子と、単項マイナス演算子をオーバーロードすることができる。二項マイナス演算子のオーバーロードには、おなじみの、-という記号を使えばいいのだが、単項マイナス演算子のオーバーロードには、negateというキーワードを使用する必要がある。

class C
{
    C operator - ( C other ) => this ; // binary minus
    C operator negate () => this ; // unary minus
}

main()
{
    C c = new C() ;

    c - c ; // binary minus
    -c ; // unary minus
}

これは恐らく、パースを高速にするためであろう。operator -と読み込んだならば、その時点で、それは二項マイナス演算子のオーバーロードであると決定できる。

例えば、Dartには正規表現ライブラリがあるが、正規表現リテラルは存在しない。これも、パースを高速に行うためであろう。そのかわりに、DartにはRaw String LiteralやMultiline string が存在する。

// Raw string literal
@"\n\r\f" ; 

// Multiline string
"""もんちゃらへっぴー
もけもけさー""" ;

まだ書きたいことは様々あるのだが、ともかくDartの規格書をすべて読んでしまわないことには、詳しい説明をすることができない。Dartを批判する前に、まず規格書を読んでみるべきである。今の実装はまだ不完全で、バグも多い。言語を実装によって判断するのは愚か者のすることである。とにかく重要なことは、Dartは今世紀最高のプログラミング言語であり、輝かしい未来が約束されているということだ。

デニス・リッチー逝去

2011-10-13T13:02:00.001+09:00

Rob Pike - Google+ - I just heard that, after a long illness, Dennis Ritchie…

Steve Jobsより、こっちの方が大ニュースだ。しかし、リッチーは世界に多大な影響を与えたにも関わらず、あまり表にでない人物であった。もしリッチーがいなければ、今日のプログラミング言語は、かなり別の文法を使っていたかもしれない。

Dartすごい。マジすごい。美しい

2011-10-12T20:27:00.000+09:00

Dart : Structured web programming

というわけで、Dartが発表されてからこのかた、Dartの規格を読んでいたのだが、これはすごい。マジですごい。ヤバイほどすごい。美しすぎる。

私が多少なりともかじっている言語は、C++とJavascriptとアセンブリである。私は、もうこれ以上、学びたいと思う新言語が出てくるとは思っていなかった。たしかに、C#はWindowsでアプリを作るには面白そうだし、PythonやらRubyやらは、かなり人気だ。しかし、これらの言語を学びたいとは思わなかった。昔、Schmeに興味を持ち、SICPを買った。しかし、未だ綺麗なまま、本棚の中に眠っている。Haskellに興味を示したこともあったが、やはり最初の感動が覚めると、学ぶ気にはならなかった。つまりは、わざわざ学ぶほどの魅力がなかったのだ。しかしどうやら、私は間違っていたようだ。Dartが来た。

Dartは美しい言語である。規格書を読むと、その美しさが一目瞭然である。従来のどの言語にもない完璧なまでの美しさを備えている。

Dart Programming Language Speci cation

まず、規格書が短い。現在のドラフトは、たったの78ページしかない。この規格書は、コア言語だけを定義している。この短さには理由がある。Dartのコア言語は、美しいほどにシンプルだからである。

たとえば、Dartには、暗黙の型変換が、boolean conversion以外に存在しない。Javascriptのように、改行が文脈によっては終端記号と解されるような仕様もない。この美しい言語を設計したのは神ではなかろうか。よくぞここまで思い切ったものだ。

ときくと、そんな厳格な言語がWebのクライアント言語として使えるはずがないと思う人もいるかもしれない。実は、暗黙の型変換のチェックは、コンパイルエラーとはならない。静的型警告（static type warning）が発せられるだけで、コンパイルには影響を及ぼさない。たとえば、

void main
{
    int x = 0.1 ; // static type warning
    print("${x}") ;
}

これは、静的型警告を出すが、コンパイルや実行には、何の影響もない。もちろん、出力も、0.1である。これは、あたかもvar x = 0.1 ;と書いたかのように振る舞う。

記述は厳格に、実行は寛容にというのが、過去に成功したWeb上でのクライアント言語に共通する理由である。HTML然り、Javascript然り。Dartはこの点からみても、失敗する余地はない。

コア言語側には、組み込み型というものがない。intやdoubleといった基本的な型でさえも、ライブラリである。

そして重要なことに、DartはJavascriptの代替として、Chromeに組み込まれることが決定している。もちろん、DOMも使える。

とにかく、Dartは信じられないほどに美しい言語だ。早くこの言語でプログラミングがしたい。Dartが使えるようになれば、Javascriptなどは即座に絶滅してしまうだろう。

おいおい、オメーのブラウザ、Dartも使えねーのかよ。さっさとDartが使えるブラウザーにしろよ。

下駄の鼻緒が切れた

2011-10-12T12:49:00.001+09:00

「下駄の鼻緒が切れると縁起が悪い」という迷信があるが、あれは迷信などではなく、事実である。

私はここ二年ほど、下駄を愛用している。何故いまどき下駄なのかと不振に思う人もいるだろう。これは、特に下駄を履くことによる不利益がないからである。

まず、下駄の値段は数千円であり、通常の安い靴と何ら変わりない。私の使用頻度では、下駄は一年ほど使えるので、この点においても、安物の靴と何ら変わりない。走るのではなく、長距離を行くのでもなければ、靴と比較した場合の不利益がほとんどないと言って差し支えない。

唯一の不利益といえば、下駄を履くと足が汚れるので、玄関先で足を洗ってから上がらなければならないことぐらいだ。歌舞伎や昔の時代劇などで、家に上がる前に、足を拭く動作がみられるのも、このためである。

ところで、今朝、下駄を履いて歩いていると、突然、下駄の鼻緒が切れた。見ると、下駄の歯があまりにも擦り切れていて、鼻緒をかけている縄が地面に接触するようになったため、次第に縄がすり切れていき、とうとう切れたらしい。以前の下駄は、そうなるまえに下駄の歯が完全にすり切れてしまったので、鼻緒が切れる前に買い換えたのだった。

当然、その場で思い当たったのは、「下駄の鼻緒が切れると縁起が悪い」という迷信である。今日、私は、この迷信が、実は事実であるということを身を持って思いしらされた。

下駄の鼻緒が切れたせいで、その下駄を履いて歩けなくなってしまったのだ。仕方なく、私は下駄を脱ぎ、裸足で歩いて帰らざるをえなかった。この不便は、下駄の鼻緒が切れたという事象によってもたらされたものである。下駄の鼻緒が切れたという直接的な理由で不便を被ったのだから、「下駄の鼻緒が切れると縁起が悪い」という迷信は、実は正しいと言える。

ISOによるC++11規格発行のプレスリリース

2011-10-11T14:55:00.001+09:00

ISO - News - C++ language gets high marks on performance with new ISO/IEC standard

欧陽修の未発見の書簡、発見さる

2011-10-07T00:11:00.001+09:00

日本で宋・欧陽修の書簡…中国で「盗んだ」、「韓国でなくて幸い」 2011/10/06(木) 17:38:42 [サーチナ]

九州大大学院比較社会文化研究院の東英寿教授は3日、宋代の政治家で詩人・文筆家として知られる欧陽修の書簡96篇を発見したと発表した。中国でも同ニュースは報じられた。かつては「13世紀に鎌倉幕府が設立した金沢文庫が収蔵していたもの」と紹介されたが、「日本が中国から盗んだものだ」などのコメントが寄せられた。「発見されたのが韓国でなくて幸いだった」との書き込みもある。

天理大学付属天理図書館が所蔵していた1191－96年に編纂（へんさん）された欧陽修全集「欧陽文忠公集」に、これまで知られていなかった欧陽修の書簡96篇が掲載されていた。同「公集」は木版による原刻本。中国国家図書館や日本の宮内庁も所蔵しているが、天理図書館所蔵の原刻本は、編纂作業が終わってから、抜け落ちていた書簡を追加した版であるとみられる。

環球網などの記事は「（日本側が古い時代に）中国で購入し、13世紀に鎌倉幕府が設立した金沢文庫が収蔵していたもの」「日本では国宝に指定」などと紹介したが、コメント欄には「日本が戦争中に中国から盗んだものだ」、「中国の文化財だ」などの書き込みが相次いだ。

「幸いなことに、（発見場所は）韓国でなかった」などと主張する書き込みも多い。「『欧陽修は韓国人だった』とされてしまう可能性が100％」だからという。

どうせ中国にあっても度重なる革命や、記憶に新しい文化大革命で焚書されてるだろうに。それにしても、このニュースは自己言及的である。なにしろ、あの欧陽修である。あの日本刀歌をつくった欧陽修である。

徐福行時書未焚
逸書百篇今尚存
令厳不許伝中国
擧世無人識古文

スティーブ・ジョブズ死亡

2011-10-06T09:00:00.002+09:00

Apple - Remembering Steve Jobs

Apple社はヴィジョンとクリエイティビティあふれる天才を失い、世界は驚嘆すべき男を失った。幸運にも彼を知り、ともに仕事をした者は、最良の友であり師でもある人物を失った。スティーブは彼以外に成し遂げられぬ会社を後にして旅立った。彼の魂は、Apple社に生き続けるであろう、永遠に。

スティーブ・ジョブズ：自分の立ち上げた会社をクビになったが、後に買収しなおした、世界一カリスマのあった男。すい臓がんにより2011年に没す。享年五十六歳。

非staticデータメンバーの初期化子

2011-10-06T00:46:00.000+09:00

今月にビルドされたgcc4.7で対応していることを確認。

struct S
{
    int member = 123 ;
    S() = default ;
    S( int value ) : member(value) { }
} ;


int main()
{
    S s1 ; // s.member == 123
    S s2(456) ; // s.member == 456
}

なお、非staticデータメンバーの宣言にauto specifierを使うことはできない。これは、auto specifierが、ブロック、名前空間スコープ、for文の初期化句にしか使われてはならないとされているためである。

struct S
{
    auto member = 0 ; // error
} ;

ちなみに言っておくと、staticデータメンバーにはauto specifierを使うことができる。これは、staticデータメンバーが、実は名前空間スコープであるからだ。staticデータメンバーは、クラス定義の中に書かなければならないとか、クラス名による修飾をしなければならないなどの制約はあるが、名前空間スコープに属する名前である。

struct S
{
    static auto const member = 0 ; // OK, type is determined to be "const int"
} ;

もちろん、staticデータメンバーに初期化子が許されているのは、constなリテラル型だけであるので、autoがそれ以外の型に推定された場合は、エラーとなる。

struct S
{
    static auto member = 0 ; // Error, the type of static member is not const literal type.
} ;

ちなみに、gccには七ヶ月前、上記のコードを通してしまうバグがあったが、バグレポートを送ったところ、現在では修正されている。

花粉症？

2011-10-03T19:36:00.001+09:00

ここしばらく、体はだるくないし熱もないが、謎のくしゃみと鼻水と目のかゆみに悩まされている。一日中というわけではなく、起きた直後がひどいように思われる。

さて、思いつく病気は花粉症だが、果たして。

火の用心に効果はあるのか

2011-10-01T20:24:00.000+09:00

毎年この時期になると、拍子木をやかましく打ち鳴らして「火の用心、火の用心」と叫ぶ集団が出現する。果たして、あれはなにか意味があるのだろうか。あれを聞いたことで、用心を心がける人間が、果たして存在するのだろうか。近所迷惑だとは思わないのか。

目の前に火鉢や囲炉裏がある時代は知らず、現代では、常に火を灯している場面は、少なくなっている。

たとえば、電子機器や配線からの発火は、少なくとも発火するまでは、火は存在しない。それに、発火するまで事前の兆候がなく、またコレといった対策も取りづらい問題である。

そもそも、現代の火災の原因の最上位は、「放火」である。

参考：総務省消防庁

放火は、いくら個人が用心しようとも防ぎようがない。ある人間が火をつけようと考えたならば、その手段を手に入れるのは、この日本ではたやすいことであるからだ。

次いで、「たばこ」が原因としてあげられる。これは、用心できる種類の原因である。

ということは、あの集団は「火の用心、火の用心」と叫ぶよりも、「禁煙、禁煙」と叫んだほうが効果的ではないだろうか。

それにしても日本は、廃品回収といい、古紙回収といい、騒音に対する規制が緩いように思われる。

ついさっきも、家の前を「火の用心」と叫びつつ通過する集団がいたので、このような疑問をぶつけてみた。彼らの言い分は、実に不思議である。

私「何故このようなことをしているのか、近所迷惑だとは思わないのか」
翁「町内会で決まっている。学校からも要請がある」
私「それで何の疑問も抱かずやっているのか」
翁「そうだ」
私「誰が決めたのか」
翁「町内会の代表である私が決めて、私がやっている」
私「自分で決めて自分でやっているのか」
翁「町内会で誰も反対しなかった」
私「そもそも、効果があるのか」
翁「ついこの間もこの近所で火事があって云々」
私「それで効果はあるのか」
翁「これを聞いて用心する人が少しでもいればそれでいい」
集団「この人頭おかしいんやわ、ほっといていこいこ」

集団は、なおも質問しようとする私を、「頭がおかしい」と言い捨て、過ぎ去っていった。この翁は、いつも家の前でタバコを吸っている翁である。ために、公道が煙たくてしょうがない。火災の原因No.2の喫煙者が火の用心を叫ぶのは不思議だ。

今年のイグ・ノーベル賞の日本人受賞者は8人

2011-09-30T16:46:00.001+09:00

まず、名誉ある受賞から、今井真（滋賀医科大学講師）、漆畑直樹、種村秀輝（シームス）、田島幸信（香りマーケティング協会理事長）、後藤秀晃、溝口浩一郎（エア・ウォーター防災）、村上純一（琵琶湖病院）の七名の者は、イグノーベル化学賞を受賞した。これは、眠っている人を起こすのに最適な空気中のわさび濃度を発見したためである。これは、火災などの警報器で、聴覚障害者を起こすのに使われる技術である。

不名誉な受賞は、麻原彰晃とその他大勢の終末予言者、世界は1997年に終わると予想し、数学的予想と計算には注意すべきだと、世界に知らしめたことをもって、イグ・ノーベル数学賞を受賞した。

クッキーモンスター

2011-09-27T22:05:00.001+09:00

「オ゛ー、ミ゛ー　ラ゛フ゛　ク゛ッキ゛ー　オ゛ー　イ゛ェア゛」
～都道府県ドメインについて、クッキーモンスター

「ちょっと待てや」
～都道府県ドメインについて、高木浩光

高木浩光＠自宅の日記 - JPRSに対する都道府県型JPドメイン名新設に係る公開質問

以下は素人丸出しの説明である。

cookieは、今日のWebサイトにとって、非常に重要であると同時に、プライバシー、セキュリティ上、気を付けなければならない機能でもある。あるWebサイトによって設定されたcookieが、全く別のWebサイトによって読み込まれることがあってはならない。このため、cookieにはsame origin policyがある。異なるドメイン間では、基本的にcookieを共有できないのだ。example.comで設定されたcookieは、example.orgからは読み込むことはできない。

ところで、今私がexample.comというドメインを取得し、Webサイトを運営したいとする。この場合、第三レベル以降のドメインは、自由に名付けることができる。自作の音楽は、music.example.comで公開し、ブログはblog.example.comで公開するとしよう。この二つのドメインは、異なるものであるから、cookieは共有できない。しかし、このドメインは、どちらもexample.com下にあるものであり、私の所有するドメインであり、私の運営するWebサイトである。したがって、このふたつのドメイン間でcookieを共有できたとしても、セキュリティ上の問題にはならない。

そこで登場するのが、super cookieである。このcookieは名前の通りスーパーなクッキーなので一部ドメインを指定しないことができる。たとえば、.example.comを指定すれば、music.example.com、blog.example.comまた他のあらゆる、「任意.example.com」で共有することができる。

しかし、もしこのスーパーなcookieを、.comに対して指定すればどうなるだろうか。この場合、私の所有するexample.comだけではなく、トップレベルドメインがcomでさえあれば、どのドメインからでもスーパークッキーの読み書きができる。これはまずい。

もちろん、問題はcomだけではない。トップレベルドメインはもっとたくさんある。では、トップレベルドメインに対するスーパークッキーを禁止すれば、問題は解決するのだろうか。

例えば、example.co.jpは、co.jpまでがパブリックなサフィックスである。トップレベルドメインの禁止だけでは、この問題を解決できない。

問題の解決方法とは、パブリックなサフィックスのリストを作成し、スーパークッキーの指定が、そのリストに該当するときは、使用を禁止することである。これは、クソなサイトからユーザーを守るためにも、ブラウザー側で対処する必要がある。

今、都道府県のサブドメインを導入するということは、日本全国の47都道府県の分だけ、パブリックサフィックスが相当に増えることになる。もし市町村も導入ということになれば、1722市町村。もちろん、これはブラウザーをアップデートすることで対処しなければならない。誰がやるというのか。アップデートされないブラウザーはどうしようもない。

明らかに、極東の小国は非常に重要なので、時にはこんな乱暴も許されるのだろう。

GCC 4.7で非staticデータメンバーに初期化子が使えるようになったらしいが

2011-09-26T12:31:00.000+09:00

C++0x Support in GCC - GNU Project - Free Software Foundation (FSF)

なんと、Non-static data member initializersがGCC 4.7で実装されているという。早速試してみようと、昨日ビルドされたばかりのgccのバイナリを落とした。さっそく試してみたが、sorry, unimplementedと表示される。何故だろう。

struct X
{
    int member = 0 ;
} ;

説経

2011-09-25T23:54:00.002+09:00

今日は気分転換に、本物の日本語を読むことにした。私の言う本物の日本語とは、数百年前に書かれて、今なお読まれている文章のことである。まだ書いた当人の生きているような新しい文章は玉石混淆であり、しかもほぼすべて石である。数百年前以前に書かれて、今なお読まれている文章は、名文の可能性が高い。路傍の石の中から玉を拾うより、世間から何百年も玉だと言われ続けている石の中から玉を探すほうが簡単である。ちょうどブックオフで、新潮日本古典集成の説教集が投げ売られていたので、それを読むことにした。

今からたったの400年ほど前、日本には説経説き、または説経者と呼ばれる下層階級の芸人がいた。彼らは当時、三十三間堂の境内で、大きな傘をかざし、ササラと呼ばれる、竹で作った、こすりあわせて音を鳴らす原始的な楽器を擦り鳴らしながら、地蔵や仏像の由来を往来の人々に説き聞かせ、おひねりを得ていたのである。

三十三間堂の近くに住む者として、これがどうにも実感がわかない。今の三十三間堂は、決して無料見はさせじとばかりに周りを厳しく塀で取り囲み、たった一箇所の入り口から、拝観料を払って入る、まあなんとも近代的で罰当たりな商業施設である。地獄で銅の湯を飲ませられることは、まず間違いあるまい。それが、かつては人通りの激しい往来であり、しかもこのような所謂「ササラ乞食」の商売の場所であったとは。今の四条大橋のような雰囲気だったのだろうか。

さて、恐らく説経の中で一番有名な話は、「さんせう太夫」であろう。これは、森鴎外の「山椒大夫」という小説のためである。しかし、実際に説経のさんせう太夫を読んでみると、森鴎外の作品は、単なる劣化コピーに過ぎないことが分かる。もちろん、当時の説経説きと森鴎外とでは、力の入れどころが違うというのもあるが、原典はさすがに強烈である。安寿は凄惨な拷問によって焼き殺されるし、返り咲いたつし王丸がさんせう太夫に行う報いも、やはり残酷な処刑である。また、誓文の文句も興味深い。

スライム冒険記が面白い

2011-09-23T18:16:00.001+09:00

コンビニでは、懐かしのマンガを再録したペーパーブックが売られている。今日、ふと売り場を見ると、興味深い本が売られていた。スライム冒険記である。

スライム冒険記とは、かねこ統によって描かれ、当時のVジャンプで連載されていた、ドラクエの世界観を元にしたギャグマンガである。灼熱炎が吐けるボケキャラのスライムのスラきちと、ツッコミ役の山賊ウルフのウルフ、その他のドラクエにおなじみのモンスター達が、なんとなく勇者を目指す物語である。

作風は、随所に鳥山明へのオマージュが感じられる。

なんとなく、ドラクエ4コママンガ劇場を読み返したい気分になった。思えば、ドラクエ4コマからは、かなり良質なマンガが生まれた。衛藤ヒロユキしかり、柴田亜美しかり。思えば、エニックスは、ゲームだけではなく、出版事業でも、結構新しいことをしていたのだな。今は見る影もないが。

しかし、どうも今、ドラクエ4コママンガ劇場は売られていないようだ。中古を手に入れるしかないのだが、近所のブックオフには見当たらない。クレカさえあれば、アマゾンの中古市場から買えるのだが。

早いところ執筆を終わらせて、まじめに働かなければなるまい。

日本語の限界を感じる

2011-09-21T09:48:00.002+09:00

C++の参考書を書くのがつらい。どうも、日本語という言語の限界を感じる。

日本語で技術書を書くのは、苦痛極まりない。どんなにわかりやすく言葉を選ぼうと、結局やっていることは、英語の翻訳でしかない。それならば、最初から英語で書けばいいではないか。明治になってから、医学はドイツ語から翻訳されたオランダ語ではなく、元のドイツ語で学んだように、プログラミングも英語で学ぶべきなのだ。確かに、一般人は翻訳で学んだが、専門家たる医者は原語で学んだのだ。専門家であるプログラマーも原語で学ぶべきである。

実際のところ、今や、もはや参考書というもの自体が時代遅れなのではないかと思う。何故ならば、誰もが一次ソースたる規格書を読むことが出来るからだ。まあ、C++はISOの規格なので、規格書は無料ではない。とはいえ、たったの352スイスフランだ。クソの役にも立たぬ参考書を何冊も買うより、規格書を買ったほうがいい。

むしろ、今の時代に日本語のプログラミングの参考書を出しても、害悪でしかないのではないかと思い始めている。日本語の資料がなければ、まともにプログラミングを学びたいものは、自然と英語を学ぶようになるはずだ。かつて私は、プログラミングを学ぼうとしたが、まともな日本語の参考書がなかったので、まず英語から学ぶことにした。この2011年になっても、まともな日本語の参考書が存在せず、世間一般に良書とされている日本語の参考書は、すべて英語からの翻訳（それもかなりひどい翻訳）であるという事実からしても、私の取った戦略は正しかったといえる。

とすれば、日本語の参考書をこれ以上増やしても、害悪でしかない。

結局、今の私は、自分自身が全く必要としていない、それどころかむしろ、害悪であるとまで考えるような参考書を書いているわけだ。道理でつらいわけだ。

追記：確かに、352スイスフランは、個人で買うにはちょっと高い。恐らく来年頃には、ANSIから数十ドル程度の値段で、規格書が買えるようになるはずだ。

プログラミングの魔導書 Vol.2の予約受付中

2011-09-16T06:25:00.002+09:00

株式会社ロングゲート - 製品案内
 『プログラミングの魔導書 Vol.2』予約開始！ - Faith and Brave - C++で遊ぼう

プログラミングの魔導書 Vol. 2の予約受付が始まった。今回、私はDave Abrahamsへのインタビューを敢行し、また、constexprの入門記事を書いている。

Dave Abrahamsは、C++プログラマーでその名前を知らなければモグリであるほどの有名なプログラマーである。

私自身のconstexpr記事は、constexprを紹介する入門的な記事である。まだ、constexprの具体的な活用例が少ないので、応用よりもむしろ、基礎を書いたほうがいいと思ったのだ。constexprをまったく知らない読者は、この記事を読めば、constexprの機能と使い方は、ひと通り分かるであろう。逆に、constexprの応用を期待している読者は、失望するかもしれない。

紙媒体が好きな人は、紙を注文できるし、電子媒体を好む人は、お世辞にも電子書籍として優れているとは言えないフォーマットであるPDFを買うこともできる。

ともかく、ようやく二冊目の刊行となったわけだ。今回は、前回のように理想を語るのではなく、批判をしようと思う。魔導書はこれから、方向性を変えるべきであると思う。電子媒体に絞るべきなのだ。

紙媒体は、すでに終わっているコンテンツである。コンテンツを印刷物で公開するのは、非常に労力がかかる。今の規模では、まあ、年に一冊が関の山だろう。これは思えば、非常に不思議である。何故ならば、今日び、コンテンツというものは、一瞬にして全世界に公開できるからだ。

たとえばこのブログだ。この本文は、書き終えた後、即座に公開されている。この文章は念入りに校正されていない。おそらくはtypoを含むだろうし、同じ助詞の連続などの、読み易くない文章も含まれている可能性もある。とはいえ、そんな誤りは些細なものである。感じの誤変換であるとか、てにをはな間違いだあるとかは、一見して明白であり、読者は容易に本来の意図した意味を推測できるであろう。それよりも、コンテンツの作成、公開にかかる労力を削減できれば、コンテンツ作者はより積極的にコンテンツを作成することができるようになり、世の中により多くの良質なコンテンツをもたらすのだ。

現代の技術を持ってすれば、一瞬で可能なことに、半年以上もの時間を費やす。無駄の極みにはあらずや。例えば、いまだに活字拾いから始めたり、写本したり、レコードで音楽を聞いたりするような無駄さ加減だ。もちろん、道楽としての活字拾いや写本やレコードを否定するつもりは毛頭ないが、それは趣味や道楽だからこその芸当であって、真面目なプロジェクトでは、やはり無駄である。

しかるに、プログラミングの魔導書は、いまだに紙媒体に固執しているため、実際の記事自体は何ヶ月も昔に完成しているというのに、印刷という障害物のせいで、半年がかりの労力になっている。これは明らかに、時代遅れである。

追記：組版自体は一ヶ月ほどでできるらしい。

たとえば、インタビューも今年の前半に行われたが、公開するまでに何ヶ月もたってしまっていては、せっかくの価値も減じてしまう。私の書いたconstexpr記事だって、当時のドラフトを参照にしていたので、最終的なC++11とは少し違ってしまっている。これはできるだけ修正したが、どうしても付け焼刃的な感は拭えない。FDISが当時読めていたならば、こうは書かなかっただろうという箇所も多い。これは、C++11発行の最終段階のツメの作業を行なっている途中での執筆だったので、仕方がないといえば仕方がないが、魔導書の発行が遅すぎるとも言える。

PDFの問題は厄介だ。PDFは印刷を前提としたフォーマットであり、電子書籍のフォーマットには適していない。電子書籍は、あくまでコンテンツを記述するフォーマットを使うべきである。コンテンツをどのように表現するかというのは、クライアント側の仕事だ。フォント、文字色や背景色、余白、さらには禁則処理や文字のツメやアキなどといった組版は、クライアント側が表現すればいいのだ。

C++11のattributeは流行らない

2011-09-15T05:34:00.000+09:00

世間では、Windows 8（仮称）の詳細の発表に湧いている。とうとう、Windows 8のDeveloper Preview版が公開されたのだ。同時に、かねてから噂されていた、Metroの詳細や、プログラミング方法も公開されている。

Building your first Windows Metro style app using C#, C++, or Visual Basic

では、さっそくC++のコード例を見てみることにしよう。

// C++
// ...
void HelloWorld::MainPage::HelloButton_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
    DisplayText->Text = "Hello World";
}

ん？　何か違和感を覚える。非常に気になるが、先に進もう。

Platform::String^ _title;
Platform::String^ _author;
Platform::String^ _pubDate;
Platform::String^ _content;

何じゃこのdeclaratorらしき^は？

はよう、MSの独自規格スパゲッティ量産言語、C++/CLIというものならん。

と考えた私の予想はるかに上回るクソ仕様であった。

Windows Runtime objects and ref new

Note that you use the ^ (“hat”) symbol instead of the pointer dereference operator (*) when declaring the variable

そんな馬鹿な。C++/CLIではない、通常のネイティブコードを生成するC++に対する拡張だというのか。やおれMSよっく聞け。そちはC++を何と心得る。偉そうに口ヒゲなど生やしてる場合か。もっとも、最近は剃っているそうだが。そもそも、declaratorとしての*は、declaratorであり、ポインターデリファレンス演算子ではない。爾、C++規格を知らざる者にドキュメントを書かせたるか。

結局、これがMSの選択か。attributeではなく、特別なdeclarator、^を選んだということか。

もちろん、MSを標準規格に従わない、常に独自規格を再発明する、独裁者だと批判するのは容易であるが（実際、その通りであるが）、もう少し考えてみる。MSはdeclaratorに^を使うことには、合理的な理由がある。C++/CLIで全く同じ構文を提供しているので、実装経験と実績があるのだ。この構文に決定するにあたって、既存のC++コードとの互換性を保てるかどうか、相当な検証を行ったはずである。C++/CLIとは、既存のC++のコード資源が使えるという利点のみが、C#より優れているのであって、C++のコード資源の利用が必要なければ、まともな頭をしていれば、普通はC#を選ぶはずだ。

もちろん、attributeも互換性に関しては申し分ないが、実装経験の差で、選ばれなかったのだろう。実際の実装で使われないならば、規格には意味がない。

言語拡張自体は、悪いことではない。C++の標準規格は、どの実装でも必ずサポートされるべき最小限の必須機能だけを規定している。たとえば、C++98の時点では、アライメントの指定は、あらゆる環境でサポートされるべき必須機能ではなかった。それ故、MSVCやGCCその他の、アライメント指定を必要とするコンパイラーは、#pragmaや独自のキーワードを用いた言語拡張によって、アライメント指定をサポートしていた。

C++11では、このような言語拡張の中でも、とくにコードに付加的な意味を与える要素に着目して、attributeという文法を付け加えた。これを使えば、独自の汚いキーワード（例：__declspec、__attribute__）を導入することなく、言語拡張が行えるはずであった。少なくとも、机上の理論ではそうであった。

しかし、__declspec(hogehoge)と[[hogehoge]]では、汚さには余り変わりはない。むしろ、attributeの方が見た目に宜しくないとも言える。

だいたい、C++11の機能からして、当初attributeで提供されるはずだった、アライメント指定やoverrideやfinalといった機能は、「公式な標準規格の言語機能は独自のキーワードを与えられる資格がある」という理由で、独自のキーワードを与えられた（厳密に言うと、キーワードではなく、contextual keywordなのだが）。あとに残ったのは、carries_dependancyとnoreturnという、まあ、言わば、それほど重要ではない機能だけである。

おそらく、attributeはasmと同じ轍を踏むだろう。どの実装からも顧みられることなく、黒歴史となるのだ。

EUで音楽の著作権が70年に延長されるそうだ

2011-09-13T02:14:00.002+09:00

BBC News - Rock veterans win copyright fight

ビートルズの録音は、あと数年で著作権が切れるはずだった。しかし、この法改正で、著作権は存続するようになった。情けない話だ。どうせ、20年後にも、保護期間をさらに延長するように法改正されるに決まっている。過去の栄光にしがみつくようでは、音楽はこれ以上成長しないだろう。

日本ではどうなるのだろう。ビートルズの最初の音楽、Love Me Doは、1962年に録音、発表されている。日本では、映画以外の団体名義の著作物の保護期間は、50年である。ビートルズは団体であろう。とすると、日本では、2013年以降は、Love Me Doの当時の録音の著作権が切れるのだろうか。

問題は、たとえビートルズの著作権が切れた所で、私にとってはあまり意味がないということだ。世代が違いすぎる。まだレコードという物理的な音溝に針をあてて音を再生する古代の装置を使っていた時代の話なのだ。

post-Bloomington mailingの簡易レビュー

2011-09-12T22:25:00.002+09:00

post-Bloomington mailingが公開された。

ISO/IEC JTC1/SC22/WG21 - Papers 2011-09

N3301: Defect Report: Terminology for Container Element Requirements

見逃していた文面上の僅かな誤りを修正。

N3302: Constexpr Library Additions v2: complex
N3303: Constexpr Library Additions v2: chrono
N3304: Constexpr Library Additions: containers
N3305: Constexpr Library Additions: utilities v2

それぞれのライブラリーで、constexpr化できる関数をconstexprにする変更。

N3306: A Proposal to Tweak Certain C++ Contextual Conversions, v2

幾つかの場所では、式の評価には、ある種の制限が課せられる。例えば、if文やwhile文のオペランドの式を評価した場合、boolに変換可能であることが求められる。このような制限を、規格では、contextualという用語を用いている。

ところで、規格の文面中に、このcontextualとよく似た意味を、それぞれ別の言葉を使って表現している箇所が、4箇所ある。その箇所では、オペランドがクラス型であった場合、期待される型への、「唯一の非explicitな変換関数」が求められている。

この4箇所の言葉を統一するために、新たな用語、contextually implicitly convertedを定義して、その用語に置き換えようという提案。

N3307: Issues Found Implementing C++0x

C++0xを実際に実装している途中で見つかった不具合集。多いので説明はしないが、興味深い問題も多い。特に、constexprと例外指定に関する問題が多いように思われる。例外指定は、私の印象では、些細なものが多いが、constexprは厄介だ。

しかし、いくつかの問題を解決するためには、それなりに大きな変更が必要になる。例えば、ある問題を解決するためには、テンプレートコンストラクターも、コピー/ムーブのコンストラクターとし、他のあらゆる箇所を、それに対応して修正し、さらに既存のコードの意味を変えないために、テンプレートなコピー/ムーブのコンストラクターは、暗黙のコピー/ムーブのコンストラクターの生成を妨げないという条件も付け加えなければならない。

N3308: constexpr consternation

constexprの原案では、constexpr関数を前方宣言することはできなかったし、定数式の入力に対しては、常に定数式を出力しなければならなかった。そのような制限は後に変更されたが、文面上では、その変更を正しく適用できていない箇所がいくつかある。その修正案。

ちなみに、今回のcore active issuesは、タイトルだけで詳細が書かれていないものが多い。これは、次のmailingで修正される予定らしい。

しかし、今書いているC++の参考書は、ある部分では1年以上前のドラフトを参考にして書かれたので、今とはだいぶ異なっている。constexprのような、明らかに多大な変更が入るであろう機能は、当時執筆を保留したが、実際にFDISを読んでみると、殆どの項目で、一年前とは文面が改良されている。問題は、そのような改良を、参考書にも適用しようとすると、ほぼ書きなおしになってしまうということだ。これでは、いつまでたっても本が完成しない。結局、不完全でも僅かな修正だけで済ますしかないだろう。やはり、C++の参考書を日本語で書くべきではなかったのだ。しかし、英語でいいとなると、なおさら今書いている本のようなものは必要ない。英語でいいのならば、規格を読めばいいからだ。なんともニッチな需要であることよ。

old new thing: 他人の尻拭い、rundll32にまつわる悲壮悲劇

2011-09-12T20:35:00.002+09:00

Throwing garbage on the sidewalk: The sad history of the rundll32 program - The Old New Thing - Site Home - MSDN Blogs

Windows Vistaの開発中、アプリケーション互換チームは、rundll32の呼び出し規約の仕様に従わない関数を無理やり呼び出した挙句のスタック破壊の問題を抱えていた。

訳注：Windows上で動く32bitコードにおいては、関数の呼び出し規約が統一されていなかったので、呼び出し規約の誤りによるスタック破壊はよくあることである。もっとも、呼び出し規約が統一されていたからとて、意図的にスタックポインターをずらされてしまってはどうしようもないが。

問題は複雑だ。例えば、rundll32を間違った方法で使っていたバッチファイルが動かなくなった。なぜならば、rundll32プロセスが終了しないからだ。スタックアライメントの誤りは、スタックからのレジスターのリストアの誤りを生じさせ、rundll32の終了時のコードを動かなくさせてしまうからだ。以前のバージョンのWindowsは、この問題を、たまたま、避けることができていた。Windows Vistaで使っているコンパイラーは、最適化方法が異なるので、スタックやレジスターの使い方が異なり、以前のバージョンのWindowsでは、たまたま問題にならなかったスタック破壊が、問題になるのだ。偶然は何度も続かないものだ。

私はこのrundll32の問題を解決して、間違った方法で使っていた人々を救うよう、命ぜられた。つまりは、他人のバグの尻拭いというわけだ。

解決方法とは、関数を呼び出す前に、呼び出された関数がスタックから余計にpopする可能性を考えて、スタックをあらかじめ数百バイトほど余計にpushしておくのだ。そして、スタックポインターをグローバル変数に保存しておく。関数から戻ったら、関数がスタック操作を誤った場合に備えて、そのグローバル変数からスタックポインターをリストアする。たしか、他のレジスターもグローバル変数に保存しておいたような気もするが、何だったかは忘れた。

もちろん、これを悪用してはならない。コンビニの前にゴミを投げ捨ててはいけないのと同じ理由だ。

訳注：アプリケーションの互換性を保つためのworkaroundは、ユーザーのためにあるのであって、プログラマーのためにあるのではない。

Project Gutenbergの創始者、Michael S Hart逝去。

2011-09-09T12:35:00.000+09:00

Michael S. Hart - Gutenberg

Project Gutenbergの創始者が亡くなっていたらしい。残念なことだ。享年64歳。まだ若かったのに惜しい。

それがおたくの書籍ってやつか

2011-09-06T19:43:00.001+09:00

出版社からスキャン代行業者への質問状を全文公開、潮目は変わるか - 電子書籍情報が満載! eBook USER

それなら俺にも考えがある。長えことジョジョとゴルゴ13のファンだったが、今日限りだ。

今や、あらゆるコンテンツは物理的な媒体の拘束を受けずにすむのだ。これは不可逆な時代の流れであり、誰も抗うことはできない。仮に対抗しようとしたとて、かの進化神は歩みを緩めず、障害物を物ともせずに蹴散らし、より一層荒々しく、物事を先に進めるだけである。故に、かの進化神の途上に横たわる障害物を除くのは、我々、今を生きる者の努めである。写本は死んだ。版木は死んだ。活版印刷は死んだ。いかに紙書籍のみ、無常の理を逃れんや。

bloggerの新しいレイアウト

2011-09-01T16:56:00.002+09:00

とりあえずテスト投稿してみる。どうも慣れない。

次期VC++のIDEに関する情報

2011-08-26T02:16:00.003+09:00

First Look at the New C++ IDE Productivity Features in the Next Version of Visual Studio - Visual C++ Team Blog - Site Home - MSDN Blogs

コードの強調表示がより強力になる。仮引数はイタリック体で表示される。

これは改悪だ。私はイタリック体とボールド体が大嫌いなのだ。現にChromeでも、* { font-weight : normal !important ; font-style : normal !important ;}というCSSを全ページに挿入するエクステンションを自作して使っている。わざわざ設定を変えるのが面倒そうだ。

リファレンスハイライト：あるシンボルにカーソルを合わせると、同じシンボルがすべてハイライトされる。単に名前が同じだけの違うシンボルはハイライトされない。

まあ、それなりに便利だろう。

ソリューションエクスプローラーが改良され、ソースコードを展開して、ソースコード内の関数や型などの一覧をみることができる。

これは、今のIDEにも、クラスビューとして存在するが、ソースコード単位で、しかもソリューションエクスプローラーからみられるところは、便利だろう。

インテリセンスのメンバーリストの自動表示。今までは、ショートカットキーを押さなければならなかった。

今でも自動表示されるような気がするが、たぶん、::とか.などに反応しているのが、もっと自動的に出るようになるのだろう。

メンバーリストフィルター。一致する名前だけが表示される。一致検索はファジーで、pbでpush_backが表示されたりする。このファジーな検索は無効にして、単に先頭からの一致に変えることもできるし、フィルターを無効にすることもできる。

コードスニペット。C#などでおなじみのコードスニペットがC++にもやってくる。

米軍の言語専門家の無駄遣い

2011-08-25T22:32:00.003+09:00

Lost in Translation: How The Army Wastes Linguists Like Me | Danger Room | Wired.com

抄訳。

2006年の冬のこと、私は軍隊に、言語専門家として志願した。外国語の翻訳を担当する兵士だ。軍の採用担当は、大学で何年もアラビア語を履修した私のジェイムズ・ボンド的技能を信用しなかったようだ。ともかく群の採用担当は、実地における経験を積めるよう配慮すると約束した。そこで、私は入隊して教育訓練を受けた。

2年間の教育訓練の後、国内でのアラビア語関連の仕事を経て、ついに2009年の3月、私はデルタ基地に着陸したブラックホークより降り立った。イラク南部のアルクートに近い基地だ。私の仕事は、傍受したアラビア語の通信を翻訳して、前線兵士に警告を出すことであろうと、私は考えていた。

任地で私を迎えた曹長の専門言語が朝鮮語であると知った時の、私の驚きを想像してもらいたい。どうやら、私の配属された5人班の半分は、朝鮮語話者であるようだ。イラクの砂漠で、朝鮮語の需要がどれだけあるというのか。これが、私の配属は、訓練内容とまったく合っていないのだと知る、最初の兆候であった。

イラクでの任務が始まり、私は、誰が言語を英語に翻訳しているのかという事実を、すぐに知った。それは、中年の巨漢なアラブ人であった。私ではない。モースル生まれのネイティブであり、我々の配属が必要としている翻訳の半分をこなす、民間人からの任用者であった。噂では、彼は20万ドル以上儲けているらしい。私の給料の優に5倍の額である。その間、私の班員は、暇そうにそこらへんに座り、装備をいじったり、パソコン画面を眺めたりして、退屈な時間を過ごしていた。

どうやら、どこの班でも事情は同じらしい。私は8ヶ月の勤務中に、35冊の本を読み終えた。そのうちの一冊は、Fiasco: イラクにおけるアメリカ軍兵士のアドベンチャーであった。

例えば、イランの国境に近いアマラーの基地にいる、ある兵士は、ペルシャ語を流暢に話す。もし、彼が通信兵に配属されたならば、非常に便利であろう。では、彼は代わりに何をしているのか？　彼は同僚がWoWで遊ぶのを観察するという非常に忙しい任務に付いている。

私の知る限り、軍隊内の言語専門家は、皆同じ問題を抱えている。

こんな状況ならば、そもそも軍は言語専門家など派遣するべきではないのだ。戦地に派遣されなかった言語専門家は、NSAとかのインテリジェンス部門で働いている。海外に派遣された者とは違い、彼らは実際に言語技能を活用して、派遣された兵士の力になっている。毎日の仕事によって、彼らの言語技能は維持されている。ある防衛会社などは、言語専門家を遠隔通信で前線にいる兵士とつなぎ、必要な翻訳を担当させるようなことまでしている。

一方、現地に派遣された言語専門家は、全く関係ない退屈な仕事をしている。他の兵士と何ら変りない。専門の言語技能は必要とされず、技能を維持することすら難しい。多くの者は、技能確認のテストに落第してしまう。

少なくとも、軍は我々言語専門家を、どこにでも使える万能要員のように扱うのを辞めるべきだ。我々の技能は専門的である。朝鮮語話者は朝鮮にいるべきであって、アルクートにいても仕方がない。スペイン語やフランス語専門の者は、ラテンアメリカとかNATO軍とかに配属されるべきなのだ。

まあでも、軍は私の代わりに、民間任用者を多数雇用して仕事をさせている。むしろこっちの方が優れているのだろう。ネイティブの技能には、太刀打ちできるわけがない。金はかかるが、品質も悪くない。

セロ弾きを妨害する猫

2011-08-25T09:36:00.001+09:00

あまりに可愛いので貼らずにはいられまい。

explicitデフォルトコンストラクターと空の初期化リスト

2011-08-24T09:24:00.002+09:00

規格を読む限り、explicitデフォルトコンストラクターを持つクラスを、空の初期化リストでリスト初期化できると思う。

12.3.1 [class.conv.ctor] p2

A default constructor may be an explicit constructor; such a constructor will be used to perform default-initialization or value-initialization (8.5).

とあり、デフォルト初期化か値初期化が可能である。また、リスト初期化で初期化リストが空の場合、

8.5.4 [dcl.init.list] p3

If the initializer list has no elements and T is a class type with a default constructor, the object is value-initialized.

単にデフォルトコンストラクターと言っているので、explicitかどうかは問わないはずだ。

今日学んだ英単語：defenestrate

2011-08-23T22:24:00.002+09:00

defenestrate [diˌfɛnəˈstreɪt]
動詞
窓から（人、物を）投げ捨てる

そんな動詞があるのか。

Defenestration - Wikipedia, the free encyclopediaによると、それなりに歴史のある言葉らしい。

Bastionが興味深い

2011-08-23T13:42:00.004+09:00

Bastionというゲームが、非常に興味深い。実際にプレイしたわけではないが、プレイ動画を見るかぎり、かなり面白そうだ。

特徴的なのは、動的なナレーションだ。ゲームを止めることなく、プレイヤーの行動にあわせてナレーションが流れる。いままで、こういうゲームはなかったと思う。

最近のゲームは、やたらとストーリーを重視し、やれカットシーンだのQTEだのと、ゲームを途中で止める変な要素を入れたがる。ゲームはユーザーの入力に反応するから面白いのであって、単に映像をみるのならば、それは映画と変わらない。この仕組は、ゲームの流れを止めないという点で、優れている。

Zero Punctuationもレビューしている。

Zero Punctuation: Bastion and From Dust

コピーとムーブが本当に難しい

2011-08-21T09:16:00.001+09:00

どうやって説明したものやら。

Firefoxがしかるべき方向に動いている

2011-08-16T04:49:00.004+09:00

Mozilla takes Firefox version numbers to the next level… by removing them | ExtremeTech

Firefoxが、バージョン番号というものを、ユーザーには意識させないようにするそうだ。これは当然である。ブラウザーは、常に最新にしておくべきであり、もはや特定のバージョン番号に留まるなどということがあってはならない。

これは良い方向に動いていると言える。

C++11という名称は定着するのか

2011-08-15T20:35:00.004+09:00

C++0xのFDISに、どの国の支部からも文句がつかなかったので、めでたく正式なISO規格として承認された。それは今さら言うでもない。しかし、この名称は一体どうなるのだろうか。

もちろん、正式名称はC++である。しかし、規格ごとの区別をつけるため、我々は俗称を用いてきた。1998年に承認された最初のC++規格を、C++98と呼び、2003年にマイナーアップデートされた規格を、C++03と呼んでいる。C++0xは、200x年に正式に発行される予定だったので、C++0xと呼ばれたわけだ。それが、結局色々あり、2011年までかかってしまった。xは実は16進数なのだというジョークはさておき、一体どうなるのだろうか。こればかりは、規格で決めるものではないので、自然の成り行きをみるより他はない。

現在、C++11という呼称を、一部の人間が使っているが、果たしてC++0xより定着するのだろうか。疑問だ。

日本語に句読点要らぬ

2011-08-14T20:17:00.002+09:00

先日通俗三国志の本を得て読み侍りしが句読点なき由いと不審なりとはいへ本来日本語には句読点てふもの存せずまた読むに不都合なしさらば句読点てふもの畢竟無用なり。

通俗三国志

2011-08-13T20:21:00.006+09:00

今行われている、下鴨納涼古本まつりで、面白い本を見つけた。表紙には、軍談三国志と書いてある。中には、通俗三国志と書いてある。明治四十五年発行の本だ。興味深かったので買うことにした。

あとで調べたところによると、三国志演義の翻訳らしい。元禄の頃に成立したのだとか。内容は簡潔ですばらしい。興味深いのは、句読点が一切ないことと、御、申、候といった漢字に対して、特殊なくずし字のようなものが使われていることだろうか。それから、おそらくは「やう」だと思われる言葉が、「よふ」と表記されているのも気になった。また、細かいところでは、閑話休題のルビが、「あだしごとはさておき」となっているのが興味深かった。

それにしても、これはいい本を手にいれたものだ。昔、本の価値は文章量によって決まるのだと考えていたが、今は、簡潔な文章を好むようになっている。だらだらと長文を弄して説明するだけなら誰にでもできる。真の文章は、最低限の長さで内容を伝えることにあるのだ。吉川英治の三国志は、この点であまりよろしくない。いつも最期まで読もうとして、途中で諦めてしまっている。文章が無駄に長すぎるのだ。それが、この通俗三国志では、まだ44ページ目だというのに、もう呂布が死んでいる。かといって、三国志で重要な話を省略していたりはしない。なかなか表現力の高い文章だ。気に入った。

例外オブジェクトとしてのクラス

2011-08-11T19:20:00.007+09:00

追記。正しくは、例外オブジェクトは、コピーかムーブのどちらかをサポートしていなければならないというものであった。つまり、コピーするのならば、ムーブは必要ないし、ムーブしかできないクラスも、例外オブジェクトたりえる。したがって、この記事の内容は誤りである。

例外として投げるオブジェクトのことを、例外オブジェクトという。例外オブジェクトがクラスのオブジェクトである場合、コピーコンストラクター、ムーブコンストラクター、デストラクターにアクセス可能でなければならない。（たとえ、使われなかったとしても）

struct X
{
    X() = default ;
    X( X const & ) = delete ;
} ;

void f()
{
    throw X() ; // エラー、コピーコンストラクターにアクセスできない
}

しかし、これは非常にわかりにくいと思う。例えば、以下のコードは誤りである。

struct X
{
    X() = default ;
    X( X const & ) { } // ユーザー定義コピーコンストラクター
} ;

void f()
{
    throw X() ; // エラー、ムーブコンストラクターにアクセスできない
}

なぜかというと、ユーザー定義のコピーコンストラクターがある場合、ムーブコンストラクターは暗黙にdefault化されないからだ。よって、エラーになる。どうやら、今のC++コンパイラーは、まだこの挙動を正しく実装していないようだ。

これは、コピーコンストラクターに限った話ではない。ユーザー定義のコピー代入演算子や、ムーブ代入演算子、デストラクターがある場合、ムーブコンストラクターは暗黙にdefault化されない。

また、暗黙のコピーコンストラクターは、ユーザー定義のコピー代入演算子や、ムーブコンストラクター、ムーブ代入演算子、デストラクターがある場合、default化される。しかし、この挙動はdeprecatedである。将来的には、廃止されるだろう。とすると、将来、C++の改定されたときに、以下のコードは動かなくなる可能性がある。

struct X
{
    X() = default ;
    X( X && ) { } // ユーザー定義のムーブコンストラクター
} ;

int main()
{
    throw X() ; // C++0xではOK。ただし、将来的には不安。
}

もちろん、これは例外に限った話ではない。C++0xで、暗黙の特別なメンバー関数が欲しい場合は、明示的にdefault化すべきだろう。

Walmartがオンライン音楽販売を停止

2011-08-11T08:10:00.008+09:00

Walmart pulling the plug on its MP3 store, but not its DRM servers

Walmartが、オンラインでの音楽販売をやめるそうだ。すでに購入した客のために、DRMサーバーは残すそうだ。ただ、すでに中止されたサービスのためのDRMサーバーがいつまで残っているのかは、疑問だ。

DRM付きのコンテンツを買うということは、常にこの問題に悩まされる。したがって、我々が取るべき戦略は、DRM付きコンテンツをボイコットすることである。音楽など聞かなくても、死にはしない。第一、すでに著作権、著作隣接権とも切れた録音は、山ほどある。DRMの存在は、正規のユーザーに対する侮辱である。

GMailのフォワード警告が全然消えない

2011-08-10T18:51:00.005+09:00

最近、GMailはForwardするフィルターがある場合、警告を表示するようになった。これは、意図せずメールをフォワードするフィルターが何らかの方法で設定されてしまっている場合を考えてのことであろう。自分で設定しなかったフィルターは、なかなか確認されない。ましてや、大部分のユーザーは、フィルターを使っていないだろう。

ただ、私の場合、そのフィルターは自分で設定したものなのだ。どうも、私の父親は、私にメールを送る場合、過去のメールに返信するという形をとっているため、携帯に送るべき時でも、GMailに送られてくる。そのため、親から送られてきたメールは、携帯にも転送するようにしているのだ。

Googleが言うには、警告が表示されるのは、一週間程だという。ただ、もう二週間ほど表示されっぱなしなのだが、どうにかならないものか。あまりにウザイので、しかたなく、このフィルターを消した。

二期はクソの法則

2011-08-07T17:09:00.004+09:00

アニメの二期は必ずクソになる法則があるのではないだろうか。少なくとも、私の好きなアニメは、皆クソになっていた。

例えば、魔法陣グルグルだ。一期はすばらしかった。作画もネタも最高であった。ところが、二期はどうも毒が抜けたのか、つまらなくなってしまっていた。二次使用料の不払い絡みに関連する、ニケの声優の変更も痛かった。

THEビッグオーも、二期はひどかった。謎は謎のままにしておけばよかったと思うのだが、何もあんな方法で解決することもあるまいに。

.hackは.hack//SIGNしか認めない。

私のアニメの知識は、10年ほど前で止まっているので、最近のアニメについてはわからない。

もちろん、アニメに限らず、大抵の続編はつまらない。例外は本当にごくわずかしか存在しない。Back To The Futureなどは、稀有な存在であろう。

何故こうなるのか。思うに、二期を制作するにあたって、一期とまったく同じ制作環境が用意できるわけではないからだろう。

QuakeCon 2011 - John Carmack Keynote

2011-08-07T06:36:00.008+09:00

90分間もある、John Carmackの講演。

25分経過、内容は、現行コンソールの貧弱なハードウェアに対する愚痴になっている。

32分経過、PCのハードウェアはコンソールの10倍も優れているのに、60fpsを保証できないことを愚痴っている。

ソースコードの静的解析ツールを熱烈に推奨している。

言語をHaskellとかOcamlに移行したいとも言っている。しかし、周りのプログラマーが全員移行できるわけではないので、やはりC++のサブセット（未初期化配列、未初期化ポインターなどの禁止）を使ったほうがいいと言っている。

モバイル向けのゲーム。モバイル機はハードウェアが貧弱なので、昔のハードでプログラミングしてた頃の知識が役に立っているのだとか。

いくつかのアメリカのISPは検索クエリーをハイジャックしているらしい

2011-08-06T09:05:00.006+09:00

Widespread Hijacking of Search Traffic in the United States | Electronic Frontier Foundation
I need to fill out a CAPTCHA to search google. - Web Search Help

いくつかのISPでは、Googleなどの検索エンジンへのアクセスが、DNS鯖への細工によって、不思議なプロクシを経由して行われるそうだ。このプロクシは、appleとかdellとかkindleとかの検索クエリーを検知して、検索エンジンではなく、該当の公式サイトなどに飛ばすらしい。それ以外の場合は、単にユーザーと検索エンジンとの間のトラフィックを通過させるだけなので、ユーザーはその存在に気がつかない。

技術的には、通常の検索クエリーを監視、記録したり、書き換えたりすることも可能である。実際、この不思議なプロクシを運営している会社は、そのような特許まで取得しているのだとか。

これは非常に危険だ。そろそろWebサイトは、常にSSLを使うということを、真剣に考えるべきだろう。

フィンランド人から送られてきた画像

2011-07-31T10:25:00.006+09:00

知り合いのフィンランド人からこんな画像が送られてきた

近所の服屋で売っているのを発見したらしい。フィンランドはさだめしカオスな国なのであろう。

モルグ街の殺人が難しい

2011-07-30T21:38:00.003+09:00

モルグ街の殺人（The Murders in the Rue Morgue）を読んでいるが、思いの外に英語が難しい。考えてみれば、もう160年ぐらい前の文章なのだから、今の英語と違っているのは当然なのだが。

ともかく、モルグ街の殺人は、探偵小説の初めとなった小説である。ファンタジー小説における指輪物語にあたる本だ。

The Murders in the Rue Morgue

16ドルで家を手にいれた男

2011-07-28T06:00:00.009+09:00

あるテキサス人が、放棄されていた家を16ドルで手にいれた。

動画によると、この家は放棄されていて、誰も所有権を主張していなかったそうだ。元の住人は賃料が払えず手放し、家を管理していた不動産会社は倒産した。そのため、家の権利は宙ぶらりんで、誰も権利を主張していない状態であった。

そこで、この男は、一ヶ月もの間、テキサスの法律を調べ、この放棄された家の所有権を主張する法的な申請を行った。その申請手続きにかかった金が16ドルとのこと。このまま三年間、元の所有者か、倒産した不動産会社の負債をもっていた銀行に権利を主張されずに住み続ければ、完全にこの男の所有物になるそうだ。しかし、元の所有者が権利を主張するには未納の賃料を払わねばならず、銀行が権利を主張するには、相当に複雑な手続きをしなければならない。だから、誰からも権利を主張されることはないだろうと男は踏んだそうだ。なんとも賢い男である。

しかし、お隣のレイシストな白人ビッチは、どうもこのやり方を気に入っていないようだ。

ストーム・トルーパーのデザインはすでに著作権切れ

2011-07-27T21:27:00.006+09:00

BBC News - Lucas loses Star Wars copyright case at Supreme Court

ストーム・トルーパーの衣装をデザインした人物が、その衣装を作って売っていたのだが、それに対してジョージ・ルーカス側が文句をつけた。

問題は、当時、明確な契約というものが存在しなかったらしい。

今回、イギリスの最高裁で、ジョージ・ルーカスは販売差し止めの権利を持たないという判決を下したそうだ。

イギリスの著作権法はよく分からないのだが、記事では、工業意匠の著作権の保護期間は15年であると言っている。そういうものなのだろうか。

しかし、これはルーカスの他の映画のデザインにも影響しそうだ。

追記：オリジナルの設計者の主張は、コスチュームは芸術品ではなく、実用品だというものらしい。イギリスの法では、そういう工業意匠の著作権の保護期間は15年間なのだとか。

CSSで垂直方向の中央に配置するのがややこしい

2011-07-27T17:54:00.005+09:00

CSSで、画像や動画を垂直方向の中央に配置したいと考えた。さっそくどのプロパティを使えばいいかググったのだが・・・どうもプロパティ一発というわけにはいかないようだ。もちろん、この問題は、いまさら知らなければモグリであるほどの古典的なものだが、CSSグルではない私は知らなかったので、書いておこうと思う。

もちろん、垂直に中央配置する方法はある。しかしどの方法も、汚いハックなのである。さらに、大抵の初心者が陥る問題がある。

まず誤解しやすいのが、vertical-alignプロパティであろう。これは名前が宜しくない。vertical-alignは、インライン要素のラインボックス（つまり文字列のレイアウト）の垂直方向の配置を指定するためのプロパティである。残念ながら、凡人が期待するようには動かない。

ただし、テーブルセルにvertical-alignを適用した場合のみ、凡人が期待するように動く。つまり、要素自体のアラインを垂直方向に対して指定できる。

CSS 2.1: vertical-align
CSS2.1: Table height algorithms

つまり、vertical-alignには、二つの全く異なる機能が混在しているといっていい。なんとも悲惨な仕様である。

ただし、このテーブルセルの仕様は利用できる。つまり、displayプロパティで、要素をtable-cellに変えてしまえば、vertical-alignが使えるのだ。ただし、その要素を囲むdisplayプロパティがtableな要素が必要になってしまうのが欠点だが。

<div style=" display : table ; ">
    <div style=" display : table-cell ; vertical-align : middle ; ">
        <!-- 実際のコンテンツ -->
    </div>
</div>

この方法は、コンテンツのheightをあらかじめ知っておく必要はないし、コンテンツのheightを動的に変えても問題のない、現時点で最良の方法である。IE8以下では動かないようだが、CSSの信奉者は、IE8などという劣ったブラウザーはもとより使わないので問題はない。

一応、CSS 3には、Flexible Box Modelというのが提案されているようだが、どうも仕様が二転三転して、未だに固まっていないように思われる。現時点では、まだ使うべきではない。

gccとclangのC++0xサポートの比較

2011-07-26T19:17:00.008+09:00

C++0xの規格はほぼ固まり、もはや変更されることはない。恐らく、このまま規格制定されるものと思われる。さて、今C++の主要なコンパイラーを上げるとすると、gccとclangをおいて他にはない。MSVCはオモチャだ。右の両コンパイラーは、C++0xの新機能を実装し始めている。もちろん、まだ不完全な実装も多いが、とりあえず遊べる程度には実装できている機能も多いので、比較してみることにする。

gccのC++0xサポート状況は、以下のページに簡易な一覧がある。

C++0x Support in GCC - GNU Project - Free Software Foundation (FSF)

clangのC++サポート状況は、以下のページに簡易な一覧がある。

Clang - C++ and C++'0x Status

面白いことに、どちらか片方のコンパイラーでしか実装されていない機能が、結構ある。ここで少し比較をしてみようと思う。もちろん、細かく観ていくときりがないので、大きな機能だけを紹介する。また、どちらのコンパイラーでも実装されている機能は省く。実装されていない機能は紹介する。

gccしか実装していない機能は、以下の通りである。

初期化リスト

std::vector<int> v = { 1, 2, 3, 4, 5 } ; // 便利便利

lambda

std::string str("表示するよ：") ; // キャプチャもできるよ
std::for_each( v.begin(), v.end(),
    [=](int i){ std::cout << str << i << std::endl ; }
) ;

ローカルクラスと無名クラスをテンプレート実引数に取る

template < typename T >
void f(T) { }

void g()
{
    struct X { } ;
    std::vector<X> v ; // ローカルクラスはOK

    enum { e1 } ;
    f( e1 ) ;　// 無名クラスもOK
}

生文字列リテラル

char16_t const * ptr =
uR"(
ここには何でも書ける。
もちろん、\とかも書けるし、
この改行だって、ちゃんと改行として反映される。
ただし、\に続くuとUは使えないので注意。
"に続く(とか、)に続く"も書けない。
もちろん、連続しなければOK。
)" ;

unionの制限取っ払い

union U
{
    int x ;
    double d ;

    // 普通のクラスは余裕で持てる。
    std::string s ;

    // コンストラクターだって楽勝。
    U() : s("initialize") { }

    // メンバー関数もOK。virtual関数はダメだけど
    void f() { } 
} ;

constexpr

constexpr int twice( int x ) { return x * 2 ; }
template < int I > struct X { } ;
X< twice(100) > x ; // X<200>

clangしか実装していない機能は、以下の通りである。

コンストラクターのデリゲート（丸投げ）

struct X
{
    X( int i ) : X(i, 0) { } // 丸投げ
    X( int i1, int i2 ) { }
} ;

非staticデータメンバーの宣言の初期化子

struct X
{
    int m = 0 ;
    X() { } // mは0
    X( int i ) : m(i) { } // mはi
} ;

テンプレートエイリアス（エイリアス宣言も含む）

using A = int ;
A a ; // int
template < typename T >
using B = T ;
B<int> b ; // int
template < typename T >
using C = std::vector< T, CustomAllocator > ;
C<int> c ; // std::vector< int, CustomAllocator >

まだどちらも実装していない機能

アトリビュート

[[]] int [[]] x ;

アライメント

struct X { int x ; double d ; } ;

void f()
{
    alignas(X) char a[100] ; // X型に要求されるアライメントを指定
    alignas(16) char b[100] ; // 16バイトアライメントを指定
    alignas(X, 4, float) char c[100] ; // X型と4バイトとfloat型とで、一番強いアライメント要求を指定

    alignof(int) ; // int型に要求されるアライメント（定数式）
}

コンストラクターの継承

struct Base
{
    Base() { }
    Base(int) { }
    Base(double) { }
} ;

struct Derived : Base
{
    // コンストラクターを継承
    using Base::Base ;
} ;

Derived d(0) ; // OK

ユーザー定義リテラル

void operator "" _owata ( char16_t *, std::size_t ) { }

int main()
{

uR"(
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
　　　　　　　　　　　 　 　 　 　 　 　 |
　　 　 　 ＿＿＿＿.＿＿＿＿ 　　 |
　　　　　|　 　 　 　 | 　 　 　 　|　　 |　 　
　　　　　|　 　 　 　 | ∧＿∧　|　　 | 　
　　　　　|　 　 　 　 |（　´∀｀）つ ミ | 　　
　　　　　|　 　 　 　 |/ ⊃　 ﾉ　|　　 |
　 　 　 　￣￣￣￣'￣￣￣￣　 　 | 　　 ミ　ユーザー定義リテラル

)"_owata ;

}

Twitterが検索用URLの仕様を変えた

2011-07-26T15:40:00.007+09:00

今までは、

http://twitter.com/search?q=文字列

だったのに、今日からは、

http://twitter.com/#!/search/エスケープされた文字列

になってる。URIの文字、, / ? : @ & = + $ #などを、たとえばJavascriptでいうencodeURIComponent()を使ってエスケープしなければならない。

URLのエスケープは、Bloggerのテンプレートのexprではできないので、Javascriptを使って行うことにした。

また、すべての検索を表示するには、http://twitter.com/#!/search/realtime/というURLになっている。