C++11参考書を完成させて売るべく作業中

資金難により執筆を断念したC++11参考書は、当初クールなキッズが皆使うというGitHubで公開して、それで終わらせようとしていた。そのため、最初のコミットとそのメッセージは、以下の通りだった。

First and probably the last commit · 96a1a4d · EzoeRyou/cpp-book

ところが、GitHubで公開すると、多くの修正のpull requestがやってきた。これは意外なことだった。もっと早く公開しているべきだったのだ。

どうやら、日本人は成果に対しては対価を払うが、成果を出すための作業に対しては対価を払わないようだ。自由なソフトウェアでは、成果を出すための作業に金が出されるべきだと思うのだが、これは意外なことだ。日本ではクラウドファンディングは根付かないのだろう。

とにかく、成果に対しては対価を払う人間がいるようだ。自由な参考書に対価を払う文化を根付かせるためにも、この参考書を、何らかの方法で売るべきだ。

ファイルを販売するためのWebサイト上のサービスが多数あるので、売ることは簡単だ。ただし、今の未完成の状態では売れない。

私に残されたネット接続はあと残りわずかの日数だが、とにもかくにも一通り、満足の行くまで完成させる決意をした。Basic Conceptsと、Attributeを埋めるのだ。

まだ、細かい誤字脱字もあるだろうが、それで、自分としても納得のできる完成品になる。スレッドは最初から省くことにしている。

残された日数が少ないので、この記事はここまで。

GitHub: EzoeRyou/cpp-book

GitHubからzipでダウンロード

GitHub Pagesでの閲覧：C++11の文法と機能

本の虫: C++11参考書の公開：C++11の文法と機能

CiscoのH.264コーデックについて一言

どうも、あれは、Ciscoの提供するバイナリ（主要なプラットフォーム向けに提供されている）を使うときのみ、Ciscoが特許料を肩代わりするというものらしい。

ソースコードは公開されている。もちろん、ソースコードにはビルドスクリプトなども含まれる。当然ビルドできる。しかし、自前にビルドしたバイナリは、x264でエンコードしたりffmpegでデコードするのと同じだ。特許料の支払いを免除されたければ、Ciscoの公開するバイナリを使わなければならない。

つまり、CiscoはH.264の特許料免除と引き換えに、自前の得体の知れないバイナリを主要なプラットフォームにばらまく土壌を作り出そうとしているわけだ。はたしてそのバイナリは、公開されているソースコードからそのまま生成されたものであろうか。なにか悪意ある秘密の機能が含まれていないだろうか。

このことからも分かるように、もはや自由なソフトウェアは著作権だけを考慮するわけには行かない。特許権も考えなくてはならない。すなわち、著作権だけではなく特許権にも対応したGPLv3が重要となる。

Dellのラップトップ6430uが、猫の小便みたいな臭いを発するとの報告多数

New 6430u smells awful - Laptop General Hardware Forum - Laptop - Dell Community

Dellの新品のラップトップ、6430uを購入したユーザーの多くが、ラップトップのキーボードから猫の小便のような臭いがすると、Dellのサポートフォーラムで苦情を出している。いくつか紹介すると

で、数週間前に、新品のLattitude 6430uを仕事用に買ったんだけどさ。

コンピューター自体は問題ないんだけどさ、でもどうも、近所の猫達のトイレ箱を全部集めたような臭いがするんだよね。マジで最悪。

どうも臭いはキーボードからきてるらしい。

誰かこの臭いを取り除く方法を知らないか？

同じだ。はじめは、うちの猫がやらかしたのかと思ってたんだが、なにか調子がおかしかったので交換した後、交換品もやっぱり同じ問題がある。ひどく臭うので、仕事にこれでお客さんの対応をするのは恥ずかしい。

以下、同じような報告が続く。報告は、新品のラップトップのキーボードから、猫の小便のような臭いがするという点で一致している。

フォーラムでは、Dellのサポート要因らしきアカウントが、キーボードの洗浄方法について説明しているが、ユーザーはいくら洗浄しても臭いは取れないと報告している。

そして、とうとうサポート要因らしきアカウントから、以下のような書き込みが出た。

この問題によりお客様にご迷惑をお掛けしたことをお詫び申し上げます。この問題は、数週間前に解決され、いずれ技術者が問題の原因と解決方法を公開する予定となっております。弊社はただいま、この問題の原因の分析と解決の最終的な確認を行っており、近いうちに結論が出ることを予定しております。その後、公式に案内させていただきます。現在、確認済みのことをいくつか申し上げます。

• 臭いは製造工程上の問題であり、現在ではすでに変更されております
• 臭いは生物的な混入によるものではございません
• 臭いに健康上の問題はございません

今からご注文いただくE6430uには、この問題はございません。

ただいま弊社で行っております最終的な不具合解析が済み次第、より詳しい情報をただちに公開いたします。弊社は今週中にも情報を公開できることを予定しておりますので、今しばらくこのスレッドをご確認ください。

このコメントの下にあるholysmokecpというユーザー名によるコメントも面白い。

で、その「問題は解決されております」っていうのは、俺がコンピューターを開けても、膀胱パンパンの野良猫達が射撃練習の的にした跡のような臭いがしないという意味での解決かね、それとも、この問題を発生させた謎の原因の解明かね。ちょっと聞きたいだけだけどさ。

サポート要因の返事

上記にありますように、生物的な要因ではございません。弊社の製造工程上の問題であることを確認しております。製造方法は変更されましたので、新しく製造される製品では、この問題は解決されております。この問題が発生しました製造品をお持ちのお客様におかれましても、問題を修正する対応をいたします。詳しい情報をこのスレッドで公開いたしますので、今しばらくお待ちください。

ところで、実際のサポート要因の言葉は、私が翻訳したような敬語を使っていない。これは、英語に起因するものだろうか。あるいはそもそもネット上のフォーラムだからだろうか。言葉こそ敬語ではないが、対応としては悪くない。問題の認識や解決などの情報を迅速に出しているわけだから。

Users complain their Dell 6430u laptops smell like cat piss | Hacker News

Hacker Newsのスレッドでは、ついこのあいだ、店頭で売られていた新品の靴から猫の小便のような臭いがしたとか、新車から猫の小便のような臭いがしたという報告があり、おそらく、接着剤の臭いなのではないかと推測されている。

モンティホール

xkcd: Monty Hall

・・・それと、うちの庭には草がたくさん生えてるよ、あと芸も仕込んでやるからな、それから・・・

これはモンティ・ホール問題へのリファレンス。

LLVMがC++11の機能を使うかどうか思案中

[Phoronix] LLVM Developers Bring Up Using C++11, Again

phoronix.comがまとめた記事で、LLVMでC++11を使うかどうかが議論されているようだ。C++11の機能完全な実装であるClangを含むLLVMは、C++で実装されているが、C++11の機能は使っていない。これは、LLVMのC++11機能が開発中は、まだC++11の信頼できるコンパイラーはなかったし、C++11を一通り実装した今となっても、LLVM以外のコンパイラーでLLVMをコンパイルするときに問題になるからだ。

GCCは、ごく最近のバージョンならば、C++11をだいぶサポートしている。MSVCの規格準拠度は相変わらずクソだ。

いずれ、C++11の便利な機能は活用するべきであるが、どの機能を、いつから使いはじめるのかということが問題だ。

ブートストラップというのは厄介な問題だ。

DebianがUpstartかSystemdへの乗り換えを検討中

[Phoronix] Debian To Switch To Systemd Or Upstart

Debianが、従来のSysVinitに変えて、近代的な既存の実装を使おうと議論しているらしい。候補は、UpstartかSystemdだ。

Upstartは、主要な汎用のGNU/Linuxベースのディストリビューションでは、ほぼCanonicalのUbuntuぐらいしか使っていない。Systemdは、より広く使われている。

Upstartの利点に、既存のSysVinit用のスクリプトをそのまま動かすこともできるということがある。

Systemdはより広く使われているが、Linuxカーネルに強く依存した設計であり、Linuxカーネル以外での利用が難しいのだという。これは、DebianがLinuxカーネルに限定していないことを考えると、難点となる。

Debianの開発者には、Canonical社員や、元Canonical社員がいて、Upstartの開発者に名を連ねている者もいるので、Upstartが有利になるのではないかと言われてる。

これに対して、phoronixのフォーラムでは、Debianが技術ではなく政治的な理由でUpstartを選んだならば、おれはDebianの利用を辞めるという宣言が相次いでいる。

またフォーラムでは、Gentooで使われている、OpenRCを押す声もある。

ネタバレ注意：歌舞伎座.tech#2で使うスライド資料

2013-10-14に歌舞伎座.tech#2で発表する際に使うスライド資料、「C++14の新機能」をGitHubで公開した。

ドワンゴの設置した勉強会の告知では、なぜか「C++14の主要機能について」となっているものだ。

ただし、ネタバレに注意。

GitHub: ネタバレ注意：EzoeRyou/kabukiza-tech2-slide

GitHub Pages: ネタバレ注意：C++14の新機能

Windows 1.01をブラウザー上で動作させる

jsmachines.net

最近、ブラウザー上で動作するエミュレータ―が盛んだ。このデモは、なんとWindows 1.01をブラウザー上で実装したエミュレータ―上で動かしているという。

もちろん、少し前に、ブラウザー上のエミュレータ―でGNU/Linux/Waylandを動かしているデモがあったわけだが。

本の虫: JavaScriptのよるOpenRISCエミュレーター上でGNU/Linux/XorWaylandを動かすデモ

歴史検証の点から、大昔のWindowsがどんな感じだったのかを手軽に体験できるのは素晴らしいことだ。

主要なC++コンパイラーのC++14サポート状況

ふと、C++14のコア言語の、主要なC++コンパイラーによるサポート具合はどうだろうかということに思い立った。主要なC++コンパイラーは、現在のところ、二つしかない。GCCとClangだ。最近、私は以前ほど頻繁にコンパイラーを自前ビルドしていない。C++11の実装は、だいぶこなれてきたからだ。では、C++14はどうか。

まずGCCからみてみよう。以下のページで、対応状況をまとめている。

C++1y/C++14 Support in GCC - GNU Project - Free Software Foundation (FSF)

もちろん、まだ規格がドラフト段階というのもあるし、実装が完全ではないというのもあるが、GCCのC++14機能は、-std=c++1yというオプションを指定することで、有効にできる。

わかりやすい新機能で言うと、二進数リテラル、戻り値の型推定、実行時サイズ配列、汎用ラムダキャプチャーが、4.9で、現在提案されている論文の文面通りに実装しているそうだ。もちろん、まだ正式な規格ではないので、規格の方が変わる可能性がある。

また、ジェネリックラムダ式と、変数テンプレートについては、もっか実装中だそうだ。その他については、まだ実装も始まっていないようだ。

Clangはどうか。以下のページで、対応状況をまとめている。

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

なんと、ほとんどの機能は、レポジトリ入りしているという。まだ完全に実装し終えていないコア言語は、ジェネリックラムダ式とsized deallocation（解放関数にストレージのサイズを渡す引数のついたオーバーロードを追加するもの）だけだそうだ。

Clangの方も、この、ドラフトに基づいた実験的な実装の新機能を使うには、-std=c++1yを指定する必要がある。

それにしても、最近、GCCはClangの後追いをしている印象がある。C++14の機能のサポートもClangに後れを取っているし、その他の有用な機能、例えば、未定義動作を実行時に検出する、Undefined Behavior Sanitizerも、Clangの実装を受けて、ClangでUBSを実装した人間がGCCでも再実装した。

Clangも自由なソフトウェアではあるのだが、やはり独裁は好ましくないし、思想の違いからも、GCCには頑張って欲しい。

以上、コンパイラー実装の知識が一切ない者の感想だ。

11月14日のドワンゴの勉強会でC++14の新機能を紹介する

歌舞伎座.tech#2 - connpass

来る2013年11月14日に、ニコニコ動画のドワンゴが勉強会を開く。その勉強会でなにかC++11/14について話してほしいと頼まれたので、私も発表者として参加する。

何でも、開催日の11月14日にちなんで、C++11かC++14について話してほしいと言ってきた。思うに、エピはんも発表するそうだし、C++11については、いまさら私が言うまでもないだろう。すでにC++11の参考書も公開したのだから、いくらでも学べる。

私に発表を頼む以上、当然、最新のC++のコア言語を求めているに決まっている。そこで、11月14日の勉強会では、私は来年に正式に制定される予定のC++14に採用された新機能について話す。具体的には、以下の内容を話す。

二進数リテラル

N3472

数値区切り

N3499, N3781

実行時サイズ配列

N3639, N3662, N3820

[[deprecated]]

N3760

戻り値の型推定

N3638

変数テンプレート

N3638

ジェネリックlambda式

N3649

汎用lambdaキャプチャー

N3648, N3610

constexpr関数の制限緩和

N3652

ただし当日は、20分ぐらいしか話す時間がないので、全ては話せない。この中から、当日の聴衆が選ぶ半分ほどを解説しようと思う。せめて40分、余裕をいえば60分ほどあれば、すべて話せるのだが。

もし勉強会に参加するならば、どれについて聞きたいか考えてもらいたい。

また、C++11について学びたければ、先日発表した私の自由な参考書が役に立つ。GitHubで公開している。

GitHub: EzoeRyou/cpp-book

GitHubからzipでダウンロード

GitHub Pagesでの閲覧：C++11の文法と機能

本の虫: C++11参考書の公開：C++11の文法と機能

日本語のC++参考書の行く末

C++11の参考書をGitHubで公開したことはすでに発表した。

GitHub: EzoeRyou/cpp-book

GitHubからzipでダウンロード

GitHub Pagesでの閲覧：C++11の文法と機能

本の虫: C++11参考書の公開：C++11の文法と機能

私はもう時間切れで、三週間後にはインターネット接続はおろか、コンピューターすら失う身だが、日本語のC++参考書の行く末について案じてみたいと思う

日本では、全国どこでも日本語が通じる。日本にいる限り、日本語以外の言語を使う必要がない。法律の書かれている言語から日常生活の言語から教育で使う言語まで、すべて日本語で行われている。

これは、凄いことでもあるが、悲劇でもある。日本人は英語を学ぶ必要性を実感できないのだ。にもかかわらず、プログラミングは、英語を必要とする。

英語は、文法的にはあまりよろしくない言語である。例外的な文法の多さ、発音と一致しない文字表記、純粋な10進数ではない数体系などなど、およそきれいな言語ではない。しかし、英語は事実上の業界標準となっている。プログラミングの世界では、共通語になっている。文法は汚いが、世の中にはもっと悲惨な文法の言語があることを考えれば、これでもまだマシな方なのだ。

好む、好まぬの問題ではない。もし、複数の言語話者が集まって一つのソフトウェアプロジェクトに参加する場合、共通言語の第一候補は、英語しかないのだ。

プログラミングの参考書や論文は、英語で書かれたものが最も多い。日本人が開発したソフトウェアや、日本語特有の処理をするソフトウェアには、その性質上、日本語の資料が豊富かもしれないが、大多数のプログラミング資料は、英語に片寄っている。

これはC++でも同じことだ。C++の標準規格や論文は、英語で書かれてる。標準委員会の議論は、英語で行われている。

したがって、C++の参考書を書くには、英語から日本語に翻訳しなければならないわけだ。

多くの稚拙なC++の参考書は、C++の標準規格を一度も読んだことがないド素人によって書かれている。このド素人は、C++の標準規格ではなく、手元にあるコンパイラーを信用する。「コンパイラーでコンパイルを通せば、それは合法なコードに違いない。コンパイルがエラーになれば、そのコードは違法なのだ」といった具合だ。これは正しいC++のコードの合法、違法を確かめる方法ではない。

多くの通常のプログラマーにとって、C++コンパイラーは信用すべきものである。しかし、C++の参考書の筆者にとって、コンパイラーとは、単に些細なタイプミスを検出する程度のものであり、常に疑ってかかるべきものなのだ。コンパイルが通ったからといって、規格準拠なコードであるとはいえないし、コンパイルエラーになったからと言って、規格上正しくないコードというわけでもない。これは、コンパイラーというものが、所詮は人間によって書かれたものである以上、不具合があるのは当然だからだ。私はC++11参考書を書くにあたって、実に多くのコンパイラーの規格違反のバグを見つけ、報告してきた。

そこでC++の参考書を書く際の大本の一時ソースとなるのは、C++の標準規格だ。しかし、これとて、盲信してはならない。C++の標準規格は、人間によって英語という自然言語で書かれている。当然間違いはある。C++の参考書の執筆者は、C++標準規格の文面すら疑わなければならないのだ。私はC++11参考書を書くにあたって、いくつもの文面上の誤りを見つけ、報告し、訂正してきた。

しかし、ド素人は違う。ド素人は手元にある特定のコンパイラーの特定のバージョンでコンパイルが通るかどうかだけを信頼する。信頼の連鎖の末端にある、最も信用してはならないものを信用する。

その結果として、ド素人の書いたC++11参考書は、規格では用いない独自の用語を使い、規格通りではない誤った認識のもとに解説している。

私のC++11参考書は、もちろん、C++の標準規格の文面すら疑いつつ書かれた。それも、C++のコア言語を標準規格に従って網羅的に解説した、単なる既存の本の翻訳ではない、最初から日本語で書かれた唯一の本なのだ。

そして私の今の境遇だ。今更言ってもはじまらないが、金がない。

C++11の参考書の紙の本

読者の中には、C++11の参考書の紙の本を売ればいいのではないかと思う者がいるかもしれない。これは、全然金にならないのだ。死んだ木の本は、全くと言っていいほど金にならないのだ。

一冊十万円の本が飛ぶように売れるのならばともかく、紙の本の値段は、所詮は一冊数千円だ。そして、プログラミングの参考書というのは、数万冊も売れれば、相当に売れたという世界なのだ。もし、十万冊売れたのならば、誰もが書名を知るほどの名著、すなわちK&RやSICPやKnuthに匹敵するような伝説的な本なのだ。もし、ミリオン、すなわち百万冊売れたならば、それは本の内容が神がかっていたから売れたというよりも、日本のプログラマーに共通の宗教を疑うべき事態だ。なぜならば、日本のプログラマーの人口というのは、諸説あるが、せいぜい100万人もいかないだろうから。

それに、十万冊売れるプログラミングの参考書というのは、入門書だ。いわゆる猫でも〜的な本だ。ド素人の書いた本だ。私の書いたような、上級者向けの網羅的な本ではない。私の書いたC++11の参考書は、これまでに比べるものがないほどに素晴らしく規格準拠なC++の参考書である。問題は、このような上級者向けの参考書は、需要がとても少ないということだ。本当に必要とする人間は、せいぜい数千人だろう。

もし紙の本のミリオンセラーが目的ならば、私が書くのはプログラミングの参考書ではなく、恋愛小説だ。その方が可能性が高いからだ。

しかも、紙の本の出版には、屈辱的な契約に同意しなければならない。その契約内容はどこの出版社でも同じで、「契約の期間中、筆者は著作権を含むあらゆる知的財産権を独占的、排他的に出版社に代行管理させること」というものだ。たとえ筆者が全文章を書き上げたとしても（誤字脱字程度の修正に著作権は発生しない）、筆者は出版中は著作権を主張できないのだ。そんなバカな話があるか。著作権は、著作者に限定的な期間の間、独占的な権利を与えるものである。なんで著作者が著作権を取り上げられなければならないのだ。

出版社側の言い訳としては、「本の組版、製本、流通、管理などには、相当の手間と費用がかかり、まったく売れないというリスクをこちらが背負うのだから、当然のことだ」ということになる。

そもそも、プログラミングの参考書とは、自由であるべきなのだ。自由にコピペしたり改変したりできないプログラミングの参考書など無価値だ。また、複製して他人に渡せないプログラミングの参考書など無価値だ。不自由なプログラミングの参考書は無価値なのだ。

今や、情報を公開するコストは、極端に下がった。なぜわざわざ不自由な死んだ木の本で公開するのに、自由を諦めなければならないのか。

では、電子書籍はどうか。電子書籍を販売するプラットフォームは様々ある。多くは仕様が非公開のフォーマット、そのフォーマットを解釈する専用の不自由なソフトウェア、邪悪なDRM（デジタル制限管理）で汚染されているので、読者は電子書籍を注意深く選ばなければならない。中には、そのような邪悪な嫌がらせをしていない電子書籍の販売プラットフォームもあるし、また、単にファイルを販売するようなプラットフォームもある。

問題は、この手の電子書籍に、高い金を払う慣習が存在しないということだ。読者はもちろん了解しているように、正しく動作するDRMは存在しない。ファイルは速やかに共有される。

私にとって、共有は問題ではない。情報の共有は素晴らしいことであり、知的財産権などという馬鹿げたものを持ちだして、情報の共有を妨害するのは、人類の進化を妨害するのと同じなのだ。シンギュラリティを提唱したRay Kurzweilは、人間の進化は、もはや遺伝子やタンパク質で行われるのではなく、技術で行われると書いた。人間は空を飛ぶために肉体を変化させる必要はないのだ。技術は、情報を記録し、共有し、伝えることで進化する。情報の共有を妨害するのは、人類の進化を妨害する、人類に対する罪である。

したがって、何らかの方法で有料ダウンロードを設けても意味がないのだ。そもそも情報自体に金を払う慣習が根付いていない。

私がC++の参考書の執筆を続けるのに必要なのは、そういったたぐいの金ではない、月々数十万の収入を数年は見込めるような、つまりは安定した収入だ。さらに、C++標準化委員会の会議に出席できるような費用（会議はほとんどアメリカ合衆国で開かれる）もあればよい。

金は必要である。金がないために、私は3週間後にインターネット接続はおろか、コンピューターすら失うわけだ。金がないために、私はこれ以上C++の参考書の執筆が続けられないわけだ。金は必要である。

そもそも、英語で書かれているC++の標準規格はどうなのか。金はどこから出るのか。C++の標準規格は、C++標準化委員会で議論され、検証され、文面案を書き、投票されて、ドラフトに入り、最終的に規格として制定される。どこから金が出ているのか。C++標準化委員会のメンバーは、個人で参加している者もいるが、大半はスポンサーがいる。スポンサーがC++の規格や、教育や、コンパイラーやライブラリの実装などに長けた人間に金を出して、C++の標準規格の作業に従事させているのだ。そうすることによって、スポンサーは、C++の規格を、スポンサーにとって都合がいいように、影響を与えることができる。

日本では、今、このスポンサーが存在しない。かつては存在したのだ。

C++標準化員会は、私もいまいち仕組みがよく分かっていないのだが、私としては、C++ Working Groupという単位の印象が強い。C++WGは、主要な各国に支部があり、日本にも支部がある。私もそこに、スポンサーなしの個人として籍をおいている。

最初のC++の正式な規格、C++98は、1998年に制定された。当時、日本では、C++の標準規格の日本語訳がほしいと考えるスポンサーがたくさんいた。そのため、スポンサーに雇われたC++WGのメンバー達は、作業を分担してC++の標準規格の全文を翻訳し、同等のJIS規格として制定した。

しかし、いまC++11の規格書の日本語訳は存在しない。一体どうなっているのか。C++標準化委員会は何をしているのか。これは、スポンサーがいないためである。

これは私の誤解と偏見で語るのだが、どうもC++WGの日本支部というのは、その前身が、EC++団体の人間だったらしいのだ。

当時、自社内で独自にC++のコンパイラーを開発できることは、業界市場で技術的優位に立つためにとても重要なことだった。しかし、C++の実装は難しい。そのため、どうも日本企業が寄り集まって、実装しやすいC++の劣化サブセットを作ろうと考えたらしい。EC++は悲惨である。多くの機能が、実装が難しいとか、オーバーヘッドがあるとかいった理由で取り除かれた。

この日本独自の、今のスラングでいえば、ガラパゴス的な劣化C++は、Bjarne Stroustrupの目にも止まった。Stroustrupは、C++になにか独占的な権利を主張することはしないが、ただ分裂しないことが重要だと考えていた。そのため、EC++団体にメールを送り、どうせやるなら、C++の標準化委員会に来てやらないかと声をかけたそうだ。

これにより、EC++が標準化委員会でも議論された。議論の結果、EC++で、オーバーヘッドがあるとされて取り除かれた機能の多くは、ゼロオーバーヘッドで実装できると論破された。その結果は、Performance TRとして公開された。

私にC++コンパイラー実装の知識がないのを棚に上げていうが、EC++はあまりにも悲惨だった。Stroustrup自身が言っているように。

私の知る限り、EC++は死んだ（2004）、もしまだ死んでいないのなら、死ぬべきである。

Stroustrup: FAQ

時代は変わった。一社独自で閉鎖的に開発されたコンパイラーというものは、大抵クソであり、不自由なプラットフォームで強制的に（始終呪いの言葉を投げかけられながら）使わされるのでもなければ、誰も使いたがらないものである。あのAppleですら、コンパイラーを自社で閉鎖的に開発するなどということはしていない。いまだに自社での閉鎖的な開発にこだわっているMicrosoftのC++風のコンパイラーは、あのザマだ。

しかし、これは同時に、日本国内の企業による、C++のスポンサーを減らしてしまった。どうも日本の企業というのは、いまだに閉鎖的な囲い込みと邪悪な制限を好むらしい。

最近、C++WGの日本支部には、新しい顔ぶれが入ってきた。多くは、スポンサーを持たない、個人の参加者である。

日本国内にC++のスポンサーが減ると、当然、C++WGの日本支部の活動も滞る。規格書の翻訳どころか、定期的な会合も開かれない。NBコメントをまとめて送るような活動もない。今、日本のC++WGの若い個人で参加しているメンバーがC++14で追加された新機能に関する会合を開くが、これはC++標準化委員会の中では行われない。単に個人の勉強会という形で行われる。スポンサーのいない世界では、標準化委員会の公式の会合というのは、手続きが煩雑なだけで利点がないのだ。

スポンサーがいないということは、個人の有志が思い思いに、気ままに活動するということだ。とてもではないが、標準規格の日本語訳はおぼつかない。

もちろん、たまに私のような変人がでるかもしれない。しかし、所詮は後ろ盾のない趣味のような活動なのだから、長続きしない。何の保証もない。いずれ誰かがやるかもしれないというものだ。

もし、今後も日本語のC++の参考書や情報がほしいのならば、そういう活動に対して金が出るべきだ。スポンサーが出るべきだ。

私が自分を売り込む宣伝活動をすべきだというかもしれない。しかし、私は、別に何も困らないのだ。C++の最新の規格に追随するには、数ヶ月ごとに発行される論文集を読めばいいだけの話だ。それは、数ヶ月おきにネットカフェかどこかで入手すればいいだけの話だ。ここ数年の論文集は、このブログで逐一解説している。たとえば、これは今月出た最新の論文集だ。

本の虫: 2013-10 post-Chicago mailingの簡易レビュー

私はインターネット接続を失うので、今後はこのような簡易レビューはできないが、論文自体は、せいぜい数十MBに満たないサイズなので、簡単にダウンロードできるし、オフラインでもじっくり読める。それを日本語で解説することができなくなるというだけの話だ。

第一、私は日本人で最も優秀なC++規格の研究者というわけではない。私よりフォーマルな英語の読める人間はいくらでもいるし、コンパイラーも実装できるだろうし、ライブラリも実装できるだろうし（私はメタプログラミングはともかく、データ構造やアルゴリズムには詳しくない）、私よりデータ構造やアルゴリズムや、数学や物理学や自然言語処理やその他もろもろの専門的な技術に詳しい人間は山ほどいる。しかし、その手の人間は、C++の規格を深く学ぶよりも、もっと他にもすることがあるので、その仕事に時間を取られていて、私ほどC++の規格をじっくり学ぶ時間がないだけだ。

もし、C++の日本語の情報を提供することに多大な金が動くようになれば、私より優秀な人間が市場に参入してくるので、私に勝ち目はない。しかし、今は、日本国内ではC++の規格に金がまったく動かないので、私のような非才な人間でも、C++の規格に関しては、優位に立つことができるわけだ。

もちろん、すべてが悪いわけではない。好むと好まざるとに関わらず、プログラミングには英語が必須である。日本のような、日本語だけでプログラミングがある程度学べてしまうような環境は例外的なのだ。日本語の資料がなければ、日本語でプログラミングを学ぶ方法がなければ、日本人プログラマーとて、自然と英語を余儀なくされる。英語が必要になる。その方が、長期的には、いいのかもしれない。

C++11参考書を公開した後の予定

本の虫: C++11参考書の公開：C++11の文法と機能で宣言したように、C++11の参考書をGitHubで公開した。

GitHub: EzoeRyou/cpp-book

GitHubからzipでダウンロード

GitHub Pagesでの閲覧：C++11の文法と機能

未完成ではあるし、一部昔のドラフト準拠で、正式な規格に追随できていない箇所もあるが、C++11のコア言語はほぼ解説している。

惜しむらくは、もっと早く、まだ状況が逼迫していない時に公開すべきだったということだ。GitHubに公開してから、修正のpull requestがかなりやってくる。多くは誤字や、単純なタグ間違いだ。そのような問題はあると分かっていたのだが、いちいち調べるよりも、一通り書くことを優先して、この数年間やってきたのだ。

もし、私のレポジトリにpull requestを送るつもりならば、急いでもらいたい。というのも、私は来月半ばにはインターネット接続を失うからだ。今も引越し作業のために、私物の整理をしている。

最終的な刻限は2013年11月17日頃だが、最後の数日は用事があり、また引っ越しの最終準備に追われるため、現実的な刻限は、せいぜい13日までだろう。その後は、私は関われない。誰かが引き継ぐしかない。ただし、引き継ぐといっても、私は今の文章を、単なる誤字脱字の修正以上に改良する利点があるとは思わない。

読めば分かるように、C++11の参考書に使われている、私のHTML/CSS/JavaScriptは、甚だ稚拙である。今なら執筆中に得られた経験から、もう少しはマシなマークアップを設計するだろう。HTMLは自由度が高いが、自由度が高すぎるが故に、どのようにマークアップするかをしっかりと設計しておかないと、こうなってしまうということだ。

また、執筆はC++11が正式に制定される以前から始まっているため、当時のドラフト規格を参考に書いていた箇所が多い。論文だけではなく、ドラフトに適用されたissuesも確認していたので、大方は修正してあると思うが、漏れもあるだろう。そもそも、この参考書はC++11の参考書である。来年発行される予定のマイナーアップデートのC++14や、またC++17になるだろうと言われているメジャーアップデートに、現行の文章を修正して対応するのは難しい。というのも、かなり後半にわたって語句や定義が変わっているからだ。

C++14やC++17の規格準拠の参考書が、もし私が次のC++規格のために、このような網羅的な参考書を書くならば、この既存の文章は一切使わない。新たに書きなおす。こんどは、もう少しまともなマークアップや、highlight.jsなどの有名なライブラリも使いたい。

それからもちろん、今度は早期の公開や、gitによる管理をしたい。今まで、バージョン管理ソフトウェアの重要性は知りつつも、もちまえの怠惰な性格のため、つい学ばずに済ませてしまった。何度かgitのドキュメントは読もうと思ったが、ついに果たせなかった。今回、GitHubを使ったのは、今をときめくクールなキッズは皆使っているからという理由だった。ただ、習うより慣れろとはよく言ったもので、いざgitを使ってみると、これが実によく分かる。今まで使っていなかったのをひどく後悔している。惜しいかな、gitを本格的に学ぶ時間がないことを。

とにかく、残された時間が少ない。もっと早く公開すべきだったが、今となっては後の祭りだ。引っ越しの事情が色々とややこしく、都合、来年の2014年の2月頃までの一時的な住処には、屋根こそあるものの、インターネット接続はおろか、コンピューターに触れない予定だ。2014年2月以降、さらに引っ越しをする予定だが、もし安定した収入を得ていれば、ここでインターネット接続が復活するかもしれない。ラップトップがあればコンピューターだけは使えたかもしれないが、残念ながら今までラップトップの必要性がないので、持っていないのだ。

このC++11の参考書を書くにあたって、当時かろうじて行っていたバイトをやめている。理由は、時間を参考書の執筆と気分転換のブログ執筆にすべて割きたかったからだ。一日に4,5時間でも、肉体労働があると、それだけで集中力が削がれてしまうのだ。

そしてこの数年間やってきたわけだが、さすがに資金が尽きた。

まあ、悪いことばかりではない。とりあえず今年の年末は、かねてから読もうと思っていた、紙の本による、太平記や、柳田國男全集や、江戸時代の戯作や読本、漢文などを読む時間ができるわけだ。あるいは、Greg Costikyanの小説を読み返すのもいい。気が散るコンピューターがないので、昔ながらの読書が定めしはかどることだろう。

C++11参考書の公開：C++11の文法と機能

C++11の参考書をGitHubで公開する。

GitHub: EzoeRyou/cpp-book

GitHubからzipでダウンロード

GitHub Pagesでの閲覧：C++11の文法と機能

序

本書はC++11のコア言語の文法と機能を、標準規格書に従って解説したものである。正式なC++規格書として発行された後の、ひとつ後のドラフト規格、N3337 を参考にしている。ドラフト規格を参考にした理由は、正式なC++規格書は、個人での入手が煩わしいためである。読者に入手が困難な資料を元に記述された参考書は価値がない。そのため、読者が容易に入手できるドラフト規格のうち、正式なC++規格書とほとんどかわらないN3337を参考にした。

本書の対象読者は、C++を記述するものである。C++実装者ではない。そのため、サンプルコードを増やし、冗長な解説を増やし、C++コンパイラーを実装するための詳細な定義は省いた。そもそも本書はC++規格の翻訳ではなく、C++規格の検証に使うことはできない。

本書の執筆は、まだC++11がC++0xと呼ばれていた2010年から始まっている。そのため、当時のドラフト規格を参考に書かれた部分もあり、正式なC++11規格とは異なっている可能性がある。また、正式に発行されたC++11規格には不具合も多数見つかっているため、C++14では異なっている部分もある。また、ドラフトの時点であまりにも変更が激しい箇所は飛ばしたので、漏れもある。

このような未完成品を公開するのは忍びないが、且は執筆資金枯渇のため、且は執筆環境消失のため、今公開することにした。

本書はC++11を解説する目的で書き始めたが、C++11の正式規格には様々な不具合が見つかり、誤りを正すために、マイナーアップデートなるC++14の制定が2014年に予定されている。また、その次の2017年には、メジャーアップデートとなるC++17が控えている。C++14はアップデートとはいえ、文面的にかなり大きな変更を含むため、もともとC++0xドラフトによって書かれ、C++11規格を参考にした本書の小手先の修正では対応できない。

本書の執筆は2010年から始まっているが、C++14が真剣に議論されだした2012年から、執筆が滞りがちになった。

筆者は常に最新のC++ドラフトを参照しているが、本書はC++11の参考書であるし、また、まだ不安定なドラフト規格の文面を参考にすることはできない。結果として、本書の執筆には、普段参照している最新のC++ドラフトからは、はるかに遅れたC++11規格を参照しなければならず、執筆の妨げとなった。

また、本書を記述するHTML/CSS/JavaScriptも、何年も前の未熟な理解により、甚だ稚拙であり、編集の妨げとなった。

この問題を解決するには、フルスクラッチからの書き直しが必要になるが、それはすでに費やした労力を捨て去ることになり、やはり意味がない。

あるいはこれ、伽藍とバザールの典型例かもしれず、早期に公開していれば、今とは違った結果になったかもしれない。

筆者は、プログラミングの参考書は、自由であるべきだと信じており、この参考書は、自由を保証するコピーレフトなライセンスで公開する。

2013年10月26日
江添亮

というわけで、執筆資金が尽きたし、また、今住んでいる家も引き払うことになり、引越し作業でしばらく執筆環境がなくなるので、この機会に、C++11の参考書を公開しておく。未完成ではあるが、Basic Concepts以外はほとんど解説している。

どうやって公開するかについては、少し迷った。Gumroadのようなものを使って有償ダウンロードさせるという手もあった。しかし、私は、プログラミングの参考書は自由でなければならないと信ずる。自由の定義には、自由に再配布する自由が含まれるのは当然である。つまり、GFDLで公開するのが最も理にかなっている。とすれば、有償ダウンロードは、手間でしかない。

そして、今クールなキッズが皆使うというGitHubなるものがある以上、そこにアップロードされるのも当然である。とすれば、その最初の名誉ぐらいは、自分が受けたいものだ。伽藍とバザールを考えれば、もっと早く公開すべきだったのかもしれない。

結局、今の日本には、オンライン上で手軽に送金する方法が欠けている。これがもし、読者の手元に貯金箱があって、そこに現金を投下すると送金できるような仕組みならば、もっと自由なソフトウェアや書籍への対価の支払いが活発になっているはずなのだが。

いずれにせよ、個人の少額の対価が得られたところで焼け石に水でしかないし、たとえ売るとしても、参考書は自由でなければならないのはもちろんだ。私は不自由なプログラミングの参考書などできるだけ読みたくない。私が読みたくないものを公開することなどできない。

残念ながら、日本国内には、C++のスポンサーがいない。C++を教育する需要がないのか。C++の規格を理解している人間の需要はないのか。

さて、後は引越し作業に専念しなければならない。しばらくはネットともコンピューターとも離れた生活になる。

紙の本は死ぬ

私は、紙の本が近い将来に死ぬと考えている。もちろん、紙の本はなくなったりはしない。しかし、その使われ方は、例えば今、音を再生するのに物理的な音溝に針をあててガリガリと振動させるレコードは、一部の好事家しか使わないように、紙の本を読むのも、歴史家、文化財産の保存か、また一部の好事家だけになるだろう。

これは、いい、悪いの問題ではない。そうなってしまうのだ。例えば、この2013年に、最近の若いものは日本語の文字を筆で書かんからけしからん、などと言ったところで、どうしようもない。確かに、日本語の文字は筆で書くことを想定して設計されてきたが、もはや筆が日常的に使う筆記具ではない以上、今更言ったところで始まらない。石を投げていいのは、いまだにシャーペンやボールペンを持たず、代わりに、懐中に矢立と水入れと懐紙を持って表を出歩いている者だけだ。

そういうわけで、紙の本は、近い将来に死ぬ。問題は、紙の本に取って代わるものが、制限コンピューターと、その上で動く不自由ソフトウェアで占められる脅威だ。

制限コンピューターは、動かすソフトウェアを、所有者やコンピューターの利用者の自由にせさず、コンピューターの製造者や販売者に委ねる、極めて非人道的な機械である。これは、コンピューターの製造者や販売者不公平で一方的な権力を与える。不自由ソフトウェアは、その利用方法が制限され、その利用原理の検証が制限され、利用者の意思を反映するように改良することもできず、また、未改変、もしくは改良したソフトウェアを他人に再配布することもできない、極めて非人道的なものである。

このような制限コンピューターと不自由ソフトウェアの上に実装された電子書籍は、もはや所有することができない。本は、提供者の一方的な権力により、遠隔操作で改変され、時には消されることさえある。

紙の本に書き込みを入れたり、ページを破ったりしても、著作権違反にはならない。しかし、電子書籍の場合、書き込みを入れたりページを破ったりすることが、著作権侵害になるのだ。なぜならば、制限コンピューターと不自由ソフトウェアによって実装された電子書籍に、そのようなことを行おうとすること自体が、DRM（デジタル制限管理）を破るという、不思議な著作権違反に問われるからだ。

もし、現状を放置すると、我々は単に紙の本を失うだけではなく、本自体を失ってしまう。

しかし、今更流れは止められないだろう。もう遅すぎる。

金のなる木が発見される

Scientists find gold growing on trees in Australia - CNN.com

オーストラリアで、金のなる木が発見されたそうだ。

原理としては、鉱石を吸い上げて蓄える。どうもユーカリやアカシアの木は根を地中深くまではるので、たまたま金を含む土を掘り当てた場合、金を吸い上げて、結果として木に金が含まれることになる。

残念ながら、含有量は少なく、肉眼で直接観察することはできない。そのため、今すぐパスポートと斧をひっつかんでオーストラリアに飛んでも、失望するだけだそうだ。

ただ、これで、"Money don't grow on trees"ということわざが使いにくくなったかもしれない。

無料のWi-Fiよりも自由な周波数帯

楽天の三木谷社長は、「日本中でＷｉＦｉを開通させてすべて無料にしてしまえば、今までなかったようなイノベーションがどんどん起きる」と言ったそうである。

楽天社長「ＷｉＦｉ無料化で革新的な起業促せ」　　：日本経済新聞

たしかに、もし日本国民全員に、無料の無線ネットワークが提供されていれば、なかなか面白いことになる。

たとえば携帯電話だ。今の日本の携帯電話は、甚だ不自然で不公平な権力の不一致を引き起こしている。

携帯電話のほとんどは、制限コンピューターである。制限コンピューターとは、ハードウェア上で動くソフトウェアが、利用者の意のまま支配できず、提供者に支配されるものをさす。私が所有している紙の本が、出版社により遠隔操作で華氏451度（馬鹿げた単位を使うアメリカ人以外のために説明すれば、これは約摂氏233度）に設定できるとすれば、もはや我々は、その紙の本を支配しているとは言えない。もし、紙の本にそのような技術が搭載されていれば、許しがたいことだ。しかし、何故かこの2013年では、コンピューターにそのような装置（遠隔操作での消去）が搭載されていても、多くの無知蒙昧なる奴隷は文句を言わない。

制限コンピューターはそれだけで悪だが、さらにひどいことがある。ネットワークが固定されているのだ。

どのようなネットワークを使うかが、物理的なハードウェアと固定されているのは、許しがたい制限である。しかし、この2013年の日本の携帯電話は、皆そのような許しがたい制限を備えている。これは、携帯電話の利用者ではなく、提供者に一方的な権力を与えるものである。ここでは、このような携帯電話の提供者を、抑圧勢力と呼ぶ。

もし、日本全国に無料のWi-Fiが提供されていれば、少なくとも、携帯電話のようなハードウェアとネットワークを固定して、その不公平な権力の不一致を利用して不公平な利益を得る、そもそも存在すべきではなかった既存の抑圧勢力を一掃することができる。無料のWi-Fiを提供するカネはどこからでるのかという問題はある。税金だろうか。すくなくとも、この2013年では、テレビ放送に対して、受信設備のあるものに強制的な負債を設定するよりは、Wi-Fi設備のほうが、はるかにマシだろう。

しかし、騙されてはいけない。無料のWi-Fiは、不公平な権力の不一致を是正しない。既存の抑圧勢力が、新たな抑圧勢力に取って代わるだけである。すなわち、Wi-Fi設備の提供者が抑圧勢力になるのだ。通信設備が、少数の提供者によって寡占されているというのは、極めて危険なことだ。通信設備の提供者は、通信を監視し、検閲し、改変できるのだ。そのような邪悪な監視検閲改変から身を守る暗号は、法律によって禁止されるだろう。秘密鍵は、法律によって提出を求められるだろう。通信設備を牛耳られていては、暗号のように見える通信を監視し、検出し、悪法によって暗号を使った罪を問われるのだ。

ではどうするのか。抑圧勢力が存在するのは、中央管理を必要とする技術的な仕組みの必然である。ならば、中央管理できない技術を使えばいいのだ。すなわち、物理層からのP2Pネットワークだ。

携帯電話が独占的に無線通信設備を提供できるのは、国家が特定の周波数帯の、独占的な利用許可を与えているからである。これは、誰もかもがてんでバラバラに好きな周波数帯を使い、結果として信頼して無線通信に使える周波数帯域がなくなってしまうよりは、いくらかマシな仕組みである。しかし、独占的な利用権利を特定の団体に与えるのは、好ましくない。

無線の周波数帯の独占の害を、もっとわかりやすく例えてみよう。例えば、我々は空気振動によって音声会話している。我々が声を出した時、その音は、空気中を伝わる振動として周囲に伝達される。もし、我々に公共の場で空気を振動させる権利が与えられていないとすれば、どうだろうか。そのような権利は、独占的な団体に一括して与えられていて、そのような団体から空気振動会話をする許可を得なければ、空気振動会話できないとするならば、どうだろうか。悲惨な制限社会ならずや？

幸い、この2013年では、空気振動は自由に行える。不必要に大きな空気振動は公共の妨げとなるので、騒音として規制されるべきだが、一般に我々が公共の場で会話しても、すなわち空気振動による通信を行っても、違法ではない。

しかし、電波に関しては、このような規制が行われている。我々が公共の場で、特定の許可のある周波数帯以外や、あるいは極めて微弱以上の電波を発すると違法である。周波数帯の利用許可は、特定の団体に独占的に与えられており、個人がある周波数帯の電波を発信したい場合は、特定の団体から許可を得なければならない。どうだろうか。悲惨な制限社会ならずや？

そこで、ある周波数帯を、誰でも自由に使えるようにしてはどうか。もちろん、騒音と同様、無意味に高出力な妨害電波の発信は規制されるべきだが、一般に我々が公共の場で、その周波数帯で通信を行っても、違法でない社会になるべきだ。

そのような自由に使える周波数帯で、我々は非中央管理型のネットワークを構築する。これは、物理層からP2Pなネットワークになるだろう。周辺のノードとメッシュ状につながり、通信を伝えていくのだ。

もちろん、これは今すぐ使えるわけではない。第一、我々にはその周波数帯の電波を送受信するプログラマブルで安価な装置がない。そのような物理層を扱うべきソフトウェアや、そのような物理層を前提にしたソフトウェアもない。しかし、もし我々が、真に通信の自由を求めるならば、自由な周波数帯が必要である。

ネットワークが自由であることの意義や、その実装方法については、以前にも考察している。

本の虫: ストールマンのいう不自由なSaaSSを打ち破る方法について、FreenetやBitTorrentやBitcoinの先例を考える
本の虫: インターネット上での自由は、もはや限界に達した。これからはピアネットだ

音響の違いでタッチを検出するデモ

▶ Touch & Activate: Adding Interactivity to Existing Objects using Active Acoustic Sensing (UIST2013) - YouTube

これは面白い。

論文：Touch & activate

iBus 1.5の思想による問題

iBus 1.5がUbuntu 13.10で採用されてから、あちこちから混乱の声が挙がっている。色々と議論を読んだ結果、ようやく、iBus 1.5の設計思想を理解したように思う。iBusでは、IMは常に有効になっているものなのだ。

IBus 1.5がUbuntu 13.10に投入されるまでの流れと現状 - いくやの斬鉄日記
結局IBus 1.5の何が問題なのだろうか。 - いくやの斬鉄日記

我々は日本語を入力する時、日本語IMEを使う。これは、日本語の文字があまりに多すぎるため、それだけの物理的なキーを用意することが現実的ではないからだ。そのため、キーボードからの入力を、IMEに変換させ、さらに漢字に変換している。

ところで、日本語中に半角英数を混ぜたい場合は、どうするだろうか。例えばこんなふうに、日本語のsentence中にEnglishを混ぜるルー大柴の芸のようなwritingをしたい場合、どうすればいいのか。

この、「日本語のsentence中にEnglishを混ぜるルー大柴の芸のようなwritingをしたい場合」という文字列を入力する場合、どうするだろうか。ここでは、sentence, English, writing（英語で、意味はそれぞれ、文、英語、記述）という半角英字を入力しなければならない。しかし、日本語を入力中は、キーボードの入力を横取りし、かな漢字に変換する、日本語IMEが有効になっている。日本語IMEが有効になっていれば、この3つの英単語を入力しようとすると、使っているローマ字設定にもよろうが、たとえば、「せんてんせ、えんgぃsh、wりちんg」、となってしまう。

多くの日本語IMEでは、文字列の変換中にF9キーを押せば、変換でなく直接入力した状態にしてくれる。しかし、frustrating（いらつくぜ）と入力するのに、そのキーボード上でfrustratingと入力して、結果として画面には、「fるstらちんg」と表示され、そこからF9キーを押してfrustratingにするのは、極めて「fるstらちんg」だ。frustratingという言葉の意味がわからない、英語はほとんど入力しないようなユーザーしか、そのような入力方法は行わないだろう。そもそも、そのようなユーザーが日本語IMEで慣習的に使われているF9キーを知っているかどうかも、疑問である。

ほとんどの日本語IMEには、半角英数モードというものがある。このモードでは、キーボードの入力は、かな漢字に変換されず、そのまま入力され、そのまま確定できる。問題は、この半角英数モードに切り替えるためのショートカットキーは、F9ほど統一されていない。多くの日本語IMEユーザーは、そのようなキーボードショートカットを知らないのではないか。たまたまそのキーボードショートカットを押してしまい、結果として半角英数モードになり、戻し方が分からずに混乱する人の方が多いのではないだろうか。日本語IMEの使われ方というのは実に様々なので、他人がどのように使っているかはわからないのだが、私のように、たまたま半角英数モードにしてしまい、戻し方が分からずに閉口する人のほうが多いのではないだろうか。

半角英数を入力するには、もっと手っ取り早い方法がある。それは、日本語IMEを無効にすることである。こうすれば、IMEはキーボードからの入力を横取りしない。直接に入力できる。

思うに、これまで、多くのJapanese peopleはJapanese languageに英語、というか半角英数を混ぜる時、単に日本語IMEの有効、無効を切り替えて入力していたのではないかと思う。

iBus 1.5の思想は、どうも、この現状を反映していないように思われる。iBus 1.5の思想は、IMEは常に有効になっているもので、IMEとキーボードレイアウトは同一であり、あらかじめよく使うものとして選んだキーボードレイアウトとIMEのリストの中を、ショートカットで順々に切り替えて使うというもののようだ。IMEは単に切り替えるものであり、有効無効にするものではなくなった。ということは、IMEの有効無効の状態を調べたり、設定したりするAPIは、もはやその存在理由を失う。なぜならば、有効、無効という概念がないからだ。

これは、既存の利用慣習とはまったく異なる思想である。

IMEとは、アプリケーションに入力を渡すものであって、その存在は通常、意識されるべきではないものだが、従来、一部のアプリケーションでは、IMEの存在を意識した処理を行っていた。たとえば、Vimは、独自にモードという概念を持っており、そのモードに応じて、IMEの状態を直接入力に変えられると都合がいいので、そのようなプラグインが存在した。iBus 1.5では、IMEの有効無効という概念が、設計上うすれてしまったので、そのような処理がやりにくくなる。

これは一体どうなるのだろうか。iBus 1.5の設計思想は主流になるのだろうか。

従来、英語には、特に賢いIMEは使われてこなかった。英語入力にも、IMEがあれば便利である。例えば、単語の補完や、綴り間違いや、辞書や、よく入力する文章の補完機能など、様々な利用方法が考えられる。実際、プロプライエタリな日本語IMEの中に、英語に不慣れな日本人向けにそのような便利な機能をもった英語入力用IMEを提供しているものもある。しかし、これまで、英語用のIMEは、あまり開発されてこなかった。

最近、この状況は変わりつつある。スマートフォンやタブレットといったコンピューターの流行のせいだ。このようなコンピューターは、タッチパネルを入力装置に採用している。タッチパネルは、一方では機械的なボタンやゴチャゴチャとした入力装置を省き、薄いパネル一枚のコンピューターを実現できたものの、文字入力という点で、かなり劣っている。タッチパネルでは、文字入力は高速には行えない。

ただし、今やコンピューターの処理性能は大幅に上がった。そのため、賢い入力補助が盛んに開発されるようになった。特に、入力速度の遅さとわずらわしさを補うために、英語でも、単語補完や文章補完のIM機能が発達した。

そのような新しいコンピューターの興隆が、従来のIMにも影響を与えていて、思想が変わっているのだろうと思う。

問題は、従来のキーボードハードウェアで入力する我々は、タッチパネルがもたらした新しいIMの思想を、キーボードにおいても受け入れるだろうか。どちらが優れているかはともかく、慣れは大きい。

キーボードユーザーからは、新しい設計思想はiBusは、好まれないのだろう。おそらく、キーボードユーザーは、別の従来の設計思想のIMに流れていくのではないかと思う。

タッチパネルは確かに面白い入力装置ではあるが、私は、近い将来にキーボードがなくなるとは思わない。物理的な音溝を針でガリガリとなぞって振動させるレコードは、周波数をサンプリングしてビット列で表現し、光の反射具合でビット列を読み取って再び振動に戻すCDに取って代わられた。そして今では、ストレージとネットワークの発達により、光学ディスクもその役目を終えようとしている。これは当然のことだ。しかしタッチパネルは、表面が動的に物理的に変形して隆起し、しかも弾力性を持ち、物理的に押し下げ可能なボタンとして遜色なく機能するような、そういう技術が実用化されない限り、キーボードを置き換えることはないだろう。そのようなタッチパネルに物理的感触をもたらす技術は研究中であるが、まだ実用化には程遠い。

とはいうものの、キーボードの地位はまだしばらく揺るがないと宣言するのは、私にとって、かなり勇気がいることである。というのも、歴史を見れば、盤石だと思われていた技術は、すぐに新技術によって駆逐されていくものだからだ。しかし、私はキーボードに関しては、まだ地位は盤石だと宣言する。

もっとしっかりした順序だった文章を書こうと思ったが、どうも取り留めのない意見がだらだらと続いてしまったので、このへんで切り上げる。

うっかりチューリング完全になっちゃったもの

Accidentally Turing-Complete ― Andreas Zwinkau

本来なら、チューリング完全となるべきではなかったものがある。これは、そのようなうっかりチューリング完全になってしまったものの例である。

C++テンプレート

当初はチューリング完全を目指していなかったが、C++テンプレートはチューリング完全になってしまった。その証明は、この論文にある（PDF）

x86 MMU

x86のpage fault handlingは、単純なマシンの実装に使える。原理としては、page faultが1 wordをスタックに積み、それによりアンダーフローを起こして別のトラップを生成する。この仕組みは、「減算して0以下ならば分岐」処理を実現する。チューリングマシンを実装するには十分である。デモ動画、講演動画

マジック・ザ・ギャザリング

マジック・ザ・ギャザリングはカードゲームである。明らかに、ルールがチューリンク完全に達するほど十分に複雑である。

HTML5 + CSS

昔のHTML/CSSは違ったのだが、新機能の追加により、Rule 110 automatonを書くことができる。残念ながら、元のサイトは壊れているが、動画がある。

Minecraft

これは意図的かもしれないが、Minecraft上で構築されたコンピューターの複雑さには目をみはるものがある。動画例

SQL

SQLは通常、チューリング完全とはみなされない。しかし、Common Table Expressionとwindow機能により、SQLはチューリング完全である。証明はこのスライドにある。また、SQL:2008のマンデルブロも必見。Fabien Coelhoによる、SQLのチューリング完全性に関する後半な説明もある。

(Cプリプロセッサー)

Cプリプロセッサーは、ループ内で実行された場合、無限に出力を入力にでき、チューリング完全となる。IOCCC 2001コンテストで優勝した例。herrmann1のエントリを参照。面白かったので、ここに付け加えた

Apache Rewrite Rules

Apacheのmod_rewriteプラグインはURLを書き換える。この書き換えのルールは、究極的には、チューリング完全の文字列書き換えシステムになっている。しかし、デフォルトの設定では、再帰回数の制限がとても低く設定されている。

(ポケットモンスター　イエロー)

ポケモンのゲームの、1分36秒のゲームプレイがある。スピードランの興味深い点は、バグを利用する点にある。ゲーム操作によって、ゲームのアセンブリを書き換えることができるという点で、チューリング完全性を満たすゲームに書き換えることができる。たとえば、ゲームをMIDIプレイヤーに書き換えた者もいる。

Scalaの型システム

当然のことながら、Scalaの型を使って、SKI計算を実装できる。（SKIコンビネータ―計算はチューリング完全である）。しかし、いずれ、コンパイラーのスタックがオーバーフローを起こす。

MediaWikiのテンプレート

MediaWikiではテンプレートを定義できる。テンプレートは再起できるために、当然のことながら、lambda計算を実装できる。

Little Big Planet

このゲーム内では、基本的なコンピューターを構築できる。例えば、コンウェイの考案したライフゲーム。

Server Side Includes

SSIはスクリプト言語としては設計されていなかったので、ループは想定されていなかった。ループを作るコツは、再帰方法を見つけることだ。Webサーバーでは、再帰回数は制限されている。

Sendmail

由緒正しいこのメールサーバーは、古代技術のような設定で有名だ。どうやら、この設定自体がチューリング完全であったらしい。

Accidentally Turing-Complete | Hacker News

Hacker Newsでは、他にもDwarf FortressやApache Rewrite ruleや、Little Big Planet（どうもゲーム内にゲーム作成機能があるらしい）や、Scalaの型システムなどが、チューリング完全だとして紹介されている。

Colossal turing machine made in city-building game - Boing Boing
unsafePerformHack » An excursion in mod_rewrite
xkcd • View topic - Turing Completeness in weird places
Scala type level encoding of the SKI calculus | Michid's Weblog

2013-10-22追記：新たに追加されていたので更新。

2013-10 post-Chicago mailingの簡易レビュー

2013-10 post-Chicago mailingが公開された。

最新のドラフト規格は、N3797、Editor's Reportは、N3798になる。

今回は、前回のCDに入れ忘れていた[[deprecated]]を入れた。また、数値区切りもオランダ、アメリカ、スペインの激しいNBコメントの圧力で入った。他にコア言語として大きな変更は、Sized Deallocationだろう。ライブラリとしては、run-time sized arrayの同等機能をライブラリで実現するdynarrayが入った。CD後だが、機能追加が激しい印象がある。

[悪鬼PDF] N3770: C++ FCD Comment Status

オランダ、アメリカ合衆国、スペインが、数値区切りは必要だから絶対入れろとNBコメントを出したので、さすがに圧力に負けて、数値区切りが入った。早急過ぎる感がある。

UTF-8文字列リテラルの型がconst char []だが、charでは表現できると保証されていない0x80とかの値がでてくる。どうするんだよ。charが0x80を表現できることを保証するか、型をunsigned charに変えろという大ブリテン及び北アイルランド連合王国の主張には、将来的に対応するという返答がなされた。まだ対応するcore issue #1759は空っぽだが、いずれ議論されるだろう。

スペインの主張したsized deallocationも追加された。

[[deprecated]]が、入ると合意されたのにドラフトの文面に入れ忘れているというコメントも、修正された。

アメリカ合衆国の、run time sized arrayについて、C99では配列の添字として0を使うのは合法なのだが、C++14のドラフトでは実行時例外を投げるとされている。これはCとC++の互換性を損なう。C99に合わせるべきだというコメントについては、受け入れられた。

全体的にみると、NBコメントは概ね受け入れられている。スイスのC++14はマイナーアップデートだからバグ修正のみにしろ、機能追加をするなとかは未回答で、スペインの、lambda式のクロージャーオブジェクトをリテラル型にしろというのは、さすがにそんなコンセンサスが得られないとして拒否されたが、やはりNBコメントは強い。

今回、C++WGの日本支部からは、NBコメントを送っていない。というより、この数年、日本支部の活動はほぼ停止している。これは、どうも国内にC++のスポンサーをする企業や団体がいなくなったからだと思われる。最近入ってきた若いメンバーが、とりあえず活動を再開しようと、C++WGの枠外で、勉強会を開くそうだ。これは、企業のスポンサーがなくてもできる活動だが、このままでは日本におけるC++は草の根レベルの活動に落ちてしまう。日本支部の存在する理由が薄れてしまう。

その結果として、C++の日本語への配慮がなくなったり、日本からのC++規格への影響がなくなったり、C++の日本語の資料がなくなったりするだろうが、まあ、私の知ったことではない。スポンサーがいなければ、消えゆくだけだ。C++98の時代には、国内にC++のスポンサーが結構いて、そのおかげで、C++98のISO標準規格の日本語訳であるJIS規格もでた。C++11では、そのようなスポンサーがいないため、JIS規格はない。

[外道PDF] N3771: Canadian C++14 Comments

カナダからのNBコメント。なぜか論文が独立している。コメントが多かったからだろうか。提出が遅れたからだろうか。

[無知蒙昧PDF] N3772: Changing the type of address-of-member expression

メンバーへのポインターの挙動を変える提案。C++の型システムが関わってくるので、短いもののものすごく難解。

C++では、ベースクラスへのメンバーへのポインターは、ベースクラスへのメンバーへのポインター型になる。

struct A { int member ; } ;
struct B : A { } ;

auto ptr = &B::member ; // 型はint A::*

&B::memberなのに、型はint A::*になってしまうのだ。

何が問題なのかというと、テンプレートに渡した時だ。

struct A { int member ; } ;
struct B : A { } ;

template < typename T, int T:: * PTR >
struct C { } ;

C< B, &B::member > c ; // エラー

なぜこれがエラーになるのかというと、テンプレート実引数に渡す文脈では、適用される型変換が極めて少なくなるからだ。&B::memberの型は、すでに述べたように、int A:: *となる。ベースクラスへのメンバーへのポインターを派生クラスへのメンバーへのポインター型に変換するというのは、テンプレート実引数に渡す文脈では適用されない。

そのため、明示的なキャストが必要だ（と論文では書いているが、なぜかGCCでもClangでも通らない）

C< B, static_cast< int B::* >( &B::member ) > c ;

なんだこのマヌケなコードは。これはおかしいだろう。ということで、これが通るようにしたい。

もうひとつの例としては、privateで派生して、using宣言でメンバーをpublicに出す例

struct A { int member ; } ;
struct B : private A
{
public :
    using A::member ;
} ;

int main()
{
    int B:: * ptr = &B::member ; // エラー
}

これもおかしい。

他には、well-formedになってほしくないけどwell-formedになってしまう例とか、この問題を解決するための変更によりバイナリ互換が壊れる例を挙げている。

[廃止されるべきPDF] N3774: async and ~future (Revision 4)

std::futureのデストラクターはブロックするべきという主張がある。しかし、互換性の問題もある。この論文は、ブロックしないfutureとブロックするfutureを、それぞれ別の型で表現することを提案している。

そもそも、std::asyncとstd::futureは、その貧弱な機能から、すでに廃止が主張されている。あるいはそのまま手を付けずに残して、もっとまともな代替ライブラリの設計に力を入れるべきだという意見もある。

[C++論文にPDFは必要ない] N3774: C++ Needs Language Support For Vectorization

C++は言語としてベクトル化をサポートするべきであると主張する論文。ベクトル化は並列化とは異なるものであり、独立したサポートが必要である。C++が言語として直接にベクトル化をサポートしていなければ、ベクトル化の利用が難しいと主張している。

CERNで得られた知見をもとに書いている。

現在のベクトル化のアプローチには三種類ある。コンパイラーによる自動ベクトル化、ベクトル用のIntrinsic、アノテーションによるコンパイラーに対するベクトル化のヒントの指定がある。

コンパイラーによる自動ベクトル化は、めったにうまくいかない。なぜならば、ベクトル化はC++に規定された挙動とは全く異なる、再現性のない処理だからだ。そのため、コンパイラーは確実に挙動が変わらない部分しか自動ベクトル化できない。

ベクトル用のIntrinsicは便利だが、そのために特殊なコードをかかなければならない。

アノテーションによるベクトル化のヒントは、かなり自然に書くことができる。

[PDFもdepreacated扱いすべき] N3775: Deprecating rand() and Friends

rand()を含む一部のライブラリをdeprecated扱いにする提案。rand, srand, RAND_MAX, randome_shuffleがdeprecated扱いになり、文面はAnnex Dに移動される。

かわりに、C++11で新しく追加された乱数ライブラリを使うべきである。C++11では、random_shuffleの代わりとなる、もっとマシなインターフェースのshuffleが追加されている。

これはすばらしい提案だ。ぜひとも採用されてほしい。

[PDFを論文に使わない義務も文面化するべき] N3776: Wording for ~future

futureとshared_futureのデストラクターはasyncが絡まなければ、ブロックしないという保証を明確にする文面の提案。

[PDFをdeprecateする文面はいずこ] N3777: Wording for deprecating async

SG1の投票で、asyncはdeprecatedすべきという結果がでたので、そのための文面の変更案。

N3778: C++ Sized Deallocation

解放関数のオーバーロードに、解放すべきストレージのサイズを得られる引数を追加する提案。これにより、いくつかのメモリ確保のテクニックが使いやすくなる。

[PDF嫌い] N3779: User-defined Literals for std::complex

std::complex用のユーザー定義リテラルの提案。

とても興味深いことに、ifという名前のユーザー定義リテラルを使っている。ユーザー定義リテラルの名前はentityではないので（operator "" _name全体がentityとなる）、実装上、キーワードも使うことができるとはいえ、まさか本当にそんな提案をするとは。

[PDFを論文に使用するのは最悪の選択肢である] N3780: Why Deprecating async() is the Worst of all Options

久しぶりにNicolai Josuttisさん。有名なC++の参考書の第二版を書くときに、std::asyncから返されたfutureが、get()もwait()もしない場合、ブロックするのかどうかということについて、疑問に思ったので、標準化委員会で相談してみたところ、何と今行われている一連のasyncとfutureのブロック議論のきっかけとなったそうだ。果てにはasyncのdeprecated案まで投票で合意される始末。

Josuttisとしては、asyncは廃止されるべきではないとしている。なぜならば、asyncはお手軽なライブラリであり、他に代替案がない。現在設計中のライブラリがTRで出るとしても、まだ先の話で、もちろん実装もなく、動かない。それに引き換え、asyncはすでに実装がある。代替案もない今、asyncを廃止すべきではないと主張している。

実際、2年前に追加された機能を即座にdeprecated扱いにするというのは、C++の歴史の中でも、かなり異質だ。

[気に食わんPDF] N3781: Single-Quotation-Mark as a Digit Separator

C++14に数値区切り機能を追加する。区切り文字は単一引用符

int x = 1'2345'6789 ;
double y = 1.2345'6789 ;
std::uint32_t bits = 0b11111111'00000000'11111111'00000000 ;

ソースコード上で、長い数値リテラルが読みやすくなる。

私はこの機能が気に入っていない。便利な機能であることは確かだが、もっと文法を議論してから入れるべきだったと思う。ただ、オランダ、アメリカ、スペインから、「必要だ、絶対入れろ」とNBコメントが来た以上、どうしようもない。

[PDF大嫌い] N3782: Index Based Ranges (Rev. 1)

Traversable(かつてRangeと呼ばれていた提案中のライブラリ)に添字ベースのアクセスを付け加える提案。

[PDFはまともなフォーマットに変換するべき] N3783: Network Byte Order Conversion

名前の通り、ホストのバイトオーダーをネットワークバイトオーダーに（もし必要であれば）変換するライブラリ。おなじみ、hton/ntohファミリーの関数群だ。C++らしく関数テンプレートになるが、従来の通常の関数も、POSIXとの互換性のために、提供される。

[PDFは改良しようがない] N3784: Improvements to std::future<T> and Related APIs

futureに非同期処理のためのメンバー関数を追加する提案。

N3785: Executors and schedulers, revision 3

処理単位を表現するexecutorと、executorを実行するschedulerライブラリの提案。バックエンドの実装としてはスレッドプールが一番わかり易い実装だが、スレッドプール以外にも実装の選択肢を考慮した設計となっている。たとえば、schedulerを呼んだスレッドでそのまま実行するというのも、実行処理がexecutorとなっているが、その場で実行したい場合などには便利だ。

N3786: Prohibiting "out of thin air" results in C++14

全く脈絡のない結果、あるいは文字通り、虚空から現れいでたる結果を禁止する提案。

全く脈絡のない結果というのは、複数のスレッドから同じオブジェクトにアクセスした結果、全く脈絡のない値が現れたりするもの。例えば、初期値0の非アトミックの通常のint型のオブジェクトに、排他的な同期処理を一切せずに、スレッドAでは1を代入し、スレッドBでは2を代入する。二つのスレッドを実行した後、オブジェクトの値を調べると、人生、宇宙、すべての答えである42がでてくるかもしれない。しかし、どちらも代入であるのだから、結果は未定義とは言え、代入したどちらかの値、あるいは初期値になるべきではないのか。それはそうであるのだが、実は、有益な最適化を妨げずに、問題となる「全く脈絡のない結果」を厳密に定義する方法を、我々はしらないということだ。つまり、どういう規格の文面を書けば、そのような好ましくない挙動だけを禁止できるのかわからない。

これは、Java規格でも10年以上、未解決のまま残っている問題である。

一方、全く脈絡のない値が現れるというのは、様々な面でよろしくない。第一常識に反する。セキュリティ上も問題だ。

何もしなくてもやたらと強い保証があるx86のようなアーキテクチャではなかなか実感しにくいが、ARMのようなアーキテクチャでは、それこそデータ競合に対して何の保証もないような無慈悲な挙動をしたりもする。

会議では、このことに関する一致した意見は出なかった。しかし、好ましくないことは確かであるので、C++14では、現在の文面を整理して、付記として、実装は全く脈絡のない結果が現れないよう努力するべきであるという文面を付け加えるべきだという方向に決まったらしい。

N3787: What can signal handlers do? (CWG 1441)

規格では、シグナルハンドラができることが、必要以上に制限されている。シグナルハンドラの制限は、もう少しゆるくてもいいのではないか。

シグナルハンドラでアトミックオブジェクトが使えるようにする文面の変更の副作用で、うっかりシグナルハンドラの制限が、volatile修飾でなければローカル変数すら使えないようなものになってしまった。このような誤りの制限を取り除くのは当然として、そもそも従来の制限も、必要以上に厳しすぎる。シグナルハンドラでは何ができるべきかということを、色々と議論した。その結果を反映した文面変更案。

N3788: C++ Standard Library Issues Resolved Directly In Chicago (2013)

シカゴ会議で解決されたいくつかの早急に対処が必要な問題集。

細かい問題ばかりなのでいちいちに挙げないが、最初の問題、2013は興味深い。

もし、標準規格で、ある関数にconstexprが付されていないとして、ある実装では、その関数をconstexpr関数の制約に落とし込めるとして、そのような関数にconstexprを付すことは、規格違反なのか。規格準拠な拡張なのか。

論文筆者は、現状では明確に規格違反であるとし、将来変更する可能性があるとは言え、現状がそうであるのだから、C++14では、規格に反してconstexprを付すのは規格違反であると明示する文面を付け加えるべきだとしている。これは解決された問題なので、C++14の文面はそのようになる。

すでに陶芸家が激怒している。

N3789: Constexpr Library Additions: functional

functionalの比較オペレーターの関数オブジェクト(lessなど)をconstexprにする提案。

N3790: Draft Filesystem Technical Specification

[PDFカエレ] N3803: Programming Languages -- C++ Standard Library -- File System Technical Specification

filesystemライブラリのドラフト規格

N3791: Lightweight Graphical Interface

軽量グラフィックインターフェースということで、Study Groupを立ちあげて、描画の標準ライブラリを検討するそうだ。C++にそんなものが入るのか。

どうせ描画といっても、メインメモリ上のビットマップに描画するような純粋なものなんだろうと思いきや、なんとまともなグラフィックライブラリを目標としているらしい。すくなくとも、ウインドウを表示して描画してということができるべきだという。

グラフィックはとても難しい。MicrosoftやらAppleやらの提供するAPIや、あるいは、OpenGLやQtのような実装は、重量級のインターフェースである。このSG目的はそのような重量級の分野に踏み入ることではなく、軽量な、お手軽に使えるライブラリを目指すのだという。

そのため、このSGの名前は、Lightweight Drawing Study Groupとなった。

グラフィックインターフェースというのは、たとえ簡易的なものであっても、とてつもなく複雑で難しい。そのため、委員会による設計ではなく、既存の実装例を元にするのだという。できれば、GitHubのようなところにソースコードが存在して、作者もSGに参加できるようなライブラリが望ましい。

その土台となる実装例の要件として挙げられているものをみれば、軽量ドローイングとはいえ、C++の規格の手に余るような規模だ。

• すでに広く使われていること
• 近代的なC++設計であり、C++11/14の機能も使われていること
• サードパーティによる拡張性があること。
• 著作権などの知的財産権の所有者が、ISOの知的財産権要求に従えること
• Bemanの提示した問題を解けること、「ウインドウ内にHello C++ Worldと表示し、ユーザーにその文字列をドラッグさせて、ウインドウ内で文字列を自由に動かせるプログラムを、既存のHello worldプログラムよりはいくらか複雑程度のプログラムで実現できること」
• Herbの提示した問題を解けること、「ライブラリの基本を学んで、なにか面白いものを作るまで、4時間以内」

なんだか軽量とは程遠い要件のような気がするのだが。

論文は、このような要件を満たせる既存の実装例として、Cinderというライブラリを挙げている。

Cinder | The library for professional-quality creative coding in C++

CinderはBSDライセンスで、ウインドウ表示から描画までをサポートするお手軽なグラフィックライブラリである。残念ながら、GNU/Linuxはサポートしていない。

それにしても、C++の標準ライブラリとしてGUIを含むグラフィックライブラリとは、時代も変わったものだ。

N3792: Working Draft Technical Specification - URI

URIをパースするライブラリのドラフト規格

N3793: A proposal to add a utility class to represent optional objects (Revision 4)

optionalライブラリの提案。C++14に入る。

N3794: Proposal to Add Multi-Dimensional Support to std::array

std::arrayを多次元配列に対応させる拡張の提案。

N3795: A more common version of algorithm std::partition_copy

std::partition_copyとは、ひとつの入力を、二つの出力に、predicate次第で出力するものである。ところで、現実には、ある条件まで処理を進めて、途中で処理を打ち切りたい場合が多々ある。そのような場合に対応するため、partition_copyに、途中で処理を終了できるものを追加する提案。

N3796: std::rand replacement

std::randの代わりに、整数で範囲を指定して、その範囲から乱数を得る、std::randintを追加する提案。

std::randint( 1, 6 ) ; // 1から6までの範囲でランダムな値を返す

randintは、自動的に適切にseedされる。これは、randの設計は根本的にマズかったことに基づく、多くのコードが、std::srand( std::time(0) )のような不適切なseedを行ってしまっていた。

擬似乱数のseedの値を指定できることは、同じ乱数列を生成できることであり、デバッグや乱数列の再現など、利用例は多い。ただし、お手軽でグローバルな乱数としては、そのような機能性ではなく、不適切なseedを防ぐほうが有益であるとのこと。

このライブラリは、ユーザー側からみれば、std::randintひとつで完結している。単純な設計のため、間違いも少ない。もちろんスレッドセーフである。また、整数型しか対応していないが、関数テンプレートであり、任意の整数型に対応できる。つまり、型変換を起こさない。もっとも、整数リテラルを正しく使えばだが。

short x = std::randint( 1, 6 ) ; // 型変換が発生するので注意
short y = std::randint( 1s, 6s ) ; // // 型一致

N3800: A proposal to add a generalized callable negator (Revision 1)

従来のnot1やnot2よりもまともで近代的で使いやすいnegator、not_fnの追加。引数はいくつでもいい。

[PDFもC++論文から取り除きたい] N3801: Removing Undefined Behavior from the Preprocessor

既存のCプリプロセッサーの文面で、Undefined Behaviorとされている箇所は、すべてが、ill-formedにするとか、最低でも実装は条件付きでサポートすることもできるといったUnspecified Behaviorにできる。Cプリプロセッサーの現在の文面はUndefined Behaviorを多用し過ぎている。そこで、CプリプロセッサーからUndefined Behaviorを取り除く提案。

[PDF死すべし] N3802: apply() call a function with arguments from a tuple

tupleに格納された要素を実引数として関数を呼び出すライブラリ、applyの提案。

N3804: Any Library Proposal

Boostでおなじみの、どんな方でも格納できるライブラリ、anyの提案。

N3809: Proposal for Unbounded-Precision Integer Types

タイトル通り、上限なしの精度を持つ整数型の提案と思われる。なぜか論文がないので詳細は不明

[またぞろ配列] N3810: Alternatives for Array Extensions

C++14の実行時サイズ配列は好ましくない。何故ならば、暗黙にポインターが得られ、そのサイズが失われてしまうからだ。

C++14で、C99の可変長配列のように、sizeofでサイズを取得するのがサポートされなかった理由というのは、sizeofは要素数ではなく、バイト単位のサイズを返すため、間違いを犯しやすいと考えられたためだ。

論文では、実行時サイズ配列は安全ではないし、dynarrayでは不満足だとしている。そこで、最初からコンパイラーマジックが適用されることを想定した、もっと軽量なライブラリを提案している。仮にbs_arrayと名付けられていて、bsとは、論文によれば、Bike Shedだそうだが・・・論文筆者が他ならぬBjarne Stroustrup本人であることを考えると・・・いや、何も言うまい。

しかし、dynarrayですら、コンパイラーマジックが行われることを想定して設計されているわけで、ライブラリを乱立させてもいいことはないと思うのだが。この調子では、将来さらにyt_array(Yet Another)が出てくることは必然である。

N3814: Call for Reflection Proposals

コンパイル時リフレクションの提案。

今回検討するのは、コンパイル時のリフレクション機能。実行時リフレクションについては、まずコンパイル時リフレクションを検討してから、それに基づいて考える。

論文では、まだ検討段階で、コンパイル時リフレクションの設計を公募中であるとしている。コンパイル時リフレクションは、少なくとも、以下の利用例はカバーできるべきだとしている。

1. 共通関数の生成

利用例としては、たとえば、典型的なoperator ==の実装は、クラスのメンバーをすべて列挙して比較していくようなものになる。メンバーを手で列挙していくのは甚だ面倒である。コンパイル時に、クラスのメンバーを列挙し、それに対して操作を加えるようなリフレクション機能が必要である。

2. 型形成

利用例としては、たとえば、構造体の配列ではなく、配列の構造体を生成できる機能。

配列の構造体

ベクトル処理が一般的になる今日では、データ構造の配置が重要になる。例えば、「構造体の配列」は、ベクトル操作のためには非効率的なレイアウトとなる。効率のためには、「配列の構造体」が望ましい。

struct S
{
    int a ;
    int b ;
    int c ;
} ;

// 非効率的な「構造体の配列」
S a[100] ;

// 効率的な「配列の構造体」
struct SoA_vector_of_S {
    std::vector<int> as;
    std::vector<int> bs;
    std::vector<int> cs;
} ;

ベクトル処理では、このように、要素を連続したストレージ上にまとめることで、効率的に処理できる。しかし、このような「配列の構造体」を手で書くのは面倒だ。コンパイル時にこのような配列の構造体を生成できるリフレクション機能が必要である。

3. コンパイル時の文脈情報

assertは、極めて醜悪なCプリプロセッサーマクロで実装されている。assertだけではない。assertに有益な情報（ソースコードのファイル名や、行番号など）を渡すためには、これまたCプリプロセッサーである、 __FILE__や__LINE__といったマクロに頼らなければならない。

コンパイル時に、このような文脈情報を取得するリフレクション機能が必要である。

4. その他のエンティティの情報の列挙

クラスメンバーに限らず、列挙したい情報はいくらでもある。例えば、

• namespace内の型
• 関数の仮引数
• namespace内のグローバル変数
• enumの列挙子

コンパイル時に、このような情報を列挙できるリフレクション機能が必要である。

以上、これから議論して設計し、C++に提案するコンパイル時リフレクションは、最低でもこの4つの利用例をカバーしなければならないと論文は述べる。

既存の実装として、Cプリプロセッサーを悪用して、4.の列挙機能を実装したライブラリが挙げられている。

C++11: Non-intrusive enum class with Reflection support using Metaprogramming - CodeProject

N3815: Enumerator List Property Queries

これもいわばリフレクション機能にあたるわけだがenumの列挙子の数、その名前、値を列挙できるライブラリの提案。

[PDFのような多様性はいらない] N3816: Polymorphic Memory Resources - r1

従来、STLではアロケーターはテンプレート実引数として渡すものであり、静的ポリモーフィズムしかサポートしていない。動的ポリモーフィズムなアロケーター指定、すなわち実行時にアロケーターを指定することを可能にするために、標準のアロケーターのベースクラスの提案。動的に指定したいアロケーターは、このベースクラスから派生して、virtual関数をオーバーライドすることで実装できる。

また、この提案では、アロケーターを定義するための新しいコンセプト（インターフェース）も定義されている。従来のヘンテコな設計のアロケーターではなく、もっとましなインターフェースになっている。

N3817: C++ Latches and Barriers

スレッドの実行を制御するためのライブラリ、latchとbarrirerの提案。ラッチは、ある操作が完了するまで、ひとつないしは複数のスレッドの実行をブロックする。バリアーはラッチに似ているが、再利用できる。

どうも、セマフォとも呼ばれているような概念のようだ。この命名はどうなのだろうか。バリアーというのは、まったく別の概念である、メモリバリアーと混同しやすい気がするのだが。

[Cプリプロセッサーと同じでいまいましいPDF] M3818: Centralized Defensive-Programming Support for Narrow Contracts (Revision 2)

防衛的プログラミングと称して、微妙に挙動の違うassertマクロを大量に提案。もちろんCプリプロセッサーで実装されている。クソだ。

筆者はCプリプロセッサーを使ういかなる提案にも反対する。

[論文がPDFで提供されているようでは、コンセプトもお先真っ暗だ] N3819: Concepts Lite Specification

コンパイル時に評価される値を使った軽量なコンセプトの提案

N3820: Working Draft, Technical Specification — Array Extensions

実行時サイズ配列とdynarrayのTR。ドラフト規格に文面が見当たらないと思ったら、TRで出るらしい。

iBus 1.5はバグがあるからクソなのではない。設計上クソなのだ

先日、iBus 1.5がクソすぎると書いたが、以下によって、iBusをクソと罵るのではなく、貢献をしろという主張がなされている。貢献とは、ひとえにパッチを書いて送ることのみをいうのではない。問題の指摘や、使用した感想を報告するといった比較的軽いものも貢献に含まれると、そう主張している。

誰がオープンソースソフトウェアを酷いものにしてしまうのか - 人生が二度あれば

もちろん、それはそうだ。ソフトウェアは使われるというだけで貢献になる。利用感を報告すればなお良いし、開発に参加すればさらによい。しかし、それは貢献が受け入れられるならばの話だ。そのような貢献を受け入れる機会は10ヶ月もあったが、依然としてiBusの上流で受け入れる気配はみられない。貢献が受け入れられなければ、貢献は貢献にならないのだから、貢献をするのは無駄だ。

iBus 1.5の問題は、バグではない。設計上の問題である。そして、上流はその設計が正しいと信じていて、変える気配がない。

iBus 1.5には細かな問題がたくさんあるが、問題の本質は、設定UIにあるのではない。もっと本質的な、二つの独立した概念の混同にある。その概念とは、キーボードレイアウトと、IMEだ。混同というのは、iBus 1.5では、この二つの異なる概念が、統合されてしまったということだ。

キーボードレイアウトとは、キーボードというハードウェアからの入力に対して、どのキーにどのような文字、あるいは機能が割り当てられるのかというマッピングである。別に、ハードウェアの定義通りにキーボード入力を解釈する必要はない。あるキーが押されたら、どの文字や機能に割り当てるかというだけの話だ。

たとえば、ロシア語の書き下しに使われているキリル文字は、キーボードレイアウトを切り替えるだけで入力できる。ロシア語入力のためのIMとは、キーボードレイアウトを切り替えることである。これは、キリル文字というのは、せいぜい数十文字であり、大文字小文字はShiftキーの押し下げの有無などで表現できることを考えれば、キーボードのキーの数だけで入力可能だからだ。

ところが、Unicodeでは言語の頭文字をとってCJK（Chinese, Japanese, Korean）と呼ばれている言語用の文字では、単にキーボードレイアウトを変えるだけでは済まないのだ。この日本語を読めるなら分かるように、日本語には何万もの文字があり、日常的に使うだけでも、何千はくだらない。

しかし、現実に数千個ものキーをもつ入力装置を使うのは難しい。そのため、我々は日本語、中国語、ハングルを入力するのに、IMEを使っている。

キーボードレイアウトとしては、キーボードのキー数で入力できる、表音文字を割り当てる。例えばラテン文字だったり、仮名だったりする。

IMEとしては、受け取った入力を、別の文字に変換する。日本語や中国語の場合は、同じ入力に対して複数の候補があるので、文脈を考慮した賢い変換があることが望ましい。ハングルの場合は、表音文字なので、そのような文脈を考えた変換が必要ないと聞いている。

これを考えると、キーボードレイアウトとIMEは、全く別物であり、独立した概念であり、混同できないことは明らかである。キーボードからの入力を、キーボードレイアウトによって文字や機能にマッピングし、IMEによって変換するのだ。

iBus 1.5はこの根本的に異なる独立した概念を統合した。単に設定UIの問題ではない。今や、iBus 1.5では、キーボードレイアウトとIMEは同じ概念であり、同じスロットから切り替えていく。これはつまり、キーボードレイアウトとIMEを独立して設定できないということだ。

たとえば、英語入力には英語配列の直接入力を使い、日本語入力には日本語配列でIMEを使うといったことが、簡単にできなくなる。なぜならば、キーボードレイアウトとIMEの設定は統一されてしまっているからだ。独立して設定できない。

どうすればいいのかというと、iBus開発者の回答は、「Japanese(IME)のxmlをコピーして、編集して、別の名前をつけて、それを使え」というものだ。かれらはキーボードレイアウトとIMEが根本的に異なる概念であることを理解していないのだ。

貢献というか、意見報告は、すでに行われていた。10ヶ月もの時間があったのだ。

iBus 1.5は、なにも昨日今日にリリースされたのではない。2012年の年末にリリースされている。その後数ヶ月、freenode.netのIRCでは怨嗟の声が絶えなかったが、やがて消えてしまった。

私はUbuntuを使っているため、主要なパッケージのアップデートは、最低でも6ヶ月おきになる。そのため、iBus 1.5を体験したのは、Ubuntu 13.10にアップグレードしてからだ。

この手のソフトウェアを、手動で上流から落としてきて、ビルドして、インストールするというのは、実質不可能なのだ。なぜならば、システムを構成するソフトウェアは無数にあり、その全てを手動で更新し続けていくなど、狂気の沙汰だ。

そのため、自動化されなければならない。その自動化が、つまりはディストリビューションだ。Ubuntuは6ヶ月毎、あるいは2年毎のLTSリリースで、そのアップデートを一斉に行っている。これはUbuntuの方針だ。このために、Ubuntuは、あまりコンピューターに詳しくない者でも、使うことができる。

別の方針をとるディストリビューションもある。たとえば、GentooやArchといったディストロは、たえまなく上流を監視し、常にソフトウェアパッケーzのレポジトリを上流の更新に合わせ、またディストロ独自の変更も最小限にとどめるという方針をとっている。これにより、システムのパッケージを個別に、あるいは一斉に、いつでも、最新版にアップデートできる。これらのディストロのパッケージ管理システムはそれを踏まえたものになっており、特定のパッケージごとに設定できるので、あるパッケージは毎日アップデートするとか、あるパッケージは絶対にアップデートしないなどといった設定もできる。もちろん、これは管理するだけの知識が必要になるが、そのような知識をもっている人間には、GentooやArchは、無駄な手作業を省き、それでいてシステムを思うままに構築しやすい、理想のディストロなのだ。

というわけで、去年の年末にiBus 1.5がでたとき、即座にiBus 1.5を体験した集団がいる。ほとんどは、GentooやArchユーザーだ。freenodeは、このような初心者向けではないディストロのユーザーがたくさんいる。

今年のはじめ数ヶ月、iBus 1.5があまりにも使えないから、iBus 1.4に戻したとか、別のIMに切り替えたという声が目立った。聞けば、バグではなく設計がおかしい、開発者の思想がおかしいと言う。当時はその言葉の意味がいまいちよくわからなかったが、なるほど、キーボードレイアウトとIMEの統一（混同）は、たしかにおかしい。

彼ら、常にブリーディング・エッジなソフトウェアを恐れることなく使う兵達は、もちろん、貢献する。意見報告もすれば、パッチも送りつける。しかし、これは設計上の問題であって、iBusの上流はこの設計が正しいと信じているために、貢献は受け入れられないという。結局、彼らは古いバージョンのiBusに留まり、そしていずれは、別のIMに流れていく。fork？　なんでわざわざiBusをforkしなけりゃならないのだ。世の中には上流がまともな思想をもつまともな設計のIMがごろごろしているというのに。

私はOS Xの事情はわからないのだが、どうもこれは、OS Xの日本語入力の仕組みを、形だけ模倣したのだという意見がある。

iBusがクソになった理由 — KaoriYa

考えてみれば、プログラムごとではなく、システム全体でIME状態を共有することになったといい、なにか異質なものを感じる。

Mark Shuttleworth、Ubuntu 14.04のコードネームを発表

Mark Shuttleworth » Blog Archive » Quantal, raring, saucy…

Mark ShuttleworthがUbuntu 14.04のコードネームを発表した。

Quantal, raring, saucy…

Tシリーズの早口言葉について公表する前に、まず謝辞を述べたい。

今や正式にUbuntu 13.10となったSaucyは、多数の開発チームや個人によるすばらしい達成事項だった。我々ひとりひとりが、それぞれ異なるモチベーションにより、いや実際、我々はそれぞれ理想のデスクトップとデフォルトのアプリケーションに関しては、それぞれ違ったビジョンを持っている。しかし、われわれはやり遂げた。Ubuntu精神によって、13.10のようなすばらしい物を協力して作り上げたのだ。これは大勢の人々やコミュニティに対する答えとなるだろう。

このリリースには、厳しいことが多かった。LTSの一つ前のリリースなので、つまり、主要な「でかい石」は突っ込まなければならなかったのだ。これはつまり、変化を指南することを意味するし、また、それを実際にこのような複雑に依存し合ったところでやりあげるのは、とても挑戦しがいのあることであった。私は開発部門の全員が、各人毎に努力を尽くして、変化を形にしたことに感謝したい。KDE、XFCE,GNOMEにフォーカスしたUbuntuコミュニティ達よ、諸君らの興味の対象を持ち寄ってくれたことに感謝する。諸君らも偉大なるリリースを果たしたことを嬉しく思う。

13.10は、私個人にとってとても特別なリリースだというのは、我々はGNU/Linuxの世界をとても重要な分野に指南しているのだ。その分野はモバイルパーソナルコンピューティングだ。Canonicalは競合と、労力を過小宣伝する誹謗中傷する輩と公平に業界シェアをわけあう権利を有する。実際、知能指数高いヘッズであれば、この氷山を破砕するのに要した途方もない労力に感謝するであろうし、猛火をかいくぐってUbuntuにモバイルエクスペリエンスの魁1.0をもたらした勇気と気品を称えるであろう。これはこの、Ubuntu-for-phones 1.0を作り上げた我々の多大な貢献が世に評価され、また期待されているためでもある。複数の開発チームが一斉に新天地を開拓し始めたのだ。新しいモバイルデザインパラダイム、新しいSDK、新しいビジュアル言語。そしてワーオ、おめーらマジ惚れ惚れするぜ。新鮮な自由ソフトウェアコミュニティからの多数の貢献は、Michael Hallのようなコラボレーション型開発やフレンドリーな意見交換、私のような意識高い人間や、同等の数百人もの人員により、なにかすばらしいものを届けられるという、労力とスタイルを約束するものである。

デザイナー、シェルエンジニア、ブラウザエンジニア、アプリエンジニア、アプリのレビューと流通プラットフォームを構築している者達、セキュリティエキスパート・・・彼らのような開発チームが一眼となって達成したこと、これ以上に誇らしいことはない。

テクノロジストに対して巨大なマイルストーンが設置されていた。Rick Spencerが、「大きな石」と呼んだものは、13.10に入るを得た。

Image based updateはとても重要な仕事だ。今回初めて、我々は、インストールされているOSの正確なバージョンを把握することにより、Ubuntuを実行するデバイスが改変されていないかどうかを保証できるのだ。私のラップトップに導入するのが待ちきれない。そうだ。これは大きな変更だ、しかし、これからの仕事を楽にしてくれるだろう。もちろん、クラウド開発の需要に向けた、Ubuntuの全機能は維持されている。このようなメカニズムの導入をやり遂げた男たちよ、よくやった。イメージ100は、彼らの言うように、ケーキだ。

Mirはとても重要な仕事だ。多くの競合が、純粋に政治的な理由でプロジェクトを攻撃したが、読者は彼らの目的に気を配らなくてはならない。少なくとも、我々は誰がオープン・ソース　ティーパーティに属するかを知っているのではないかね(*＾∀ﾟ)ъ。さて、多くの文句の背景事情を考えてみよう。Mirが直接影響するのは、全開発者のうちの約1%、シェル開発を考慮しなければならない者達だけなのだ。すべてのアプリ開発者は、ツールキットを経由してMirに触れる。ひるがえって考えると、奴ら、今怒り狂っている個人達は、すべての重要なソフトウェアスタックに対して、自分たちが開発したのではないからという理由でケチをつけるのだ。最も有名なのはSystemDで、これは非常に込み入った侵略的なもので、到底援護できない。Canonicalの競合相手が、よくよく観察すれば、みだりに舌先を弄して、これらのツールキットは、Windowsはサポートすべきであるが、Mirはサポートすべきではない、などとほざいているのを聞くがいい。しかし、我々はやり遂げたわけで、これはすばらしいことだ。

私は言える。Mir開発チームの目的とは：スピード、品質、信頼性、効率性である。そうだ。スマートフォン業界を眺めれば、Mirこそが、ゲームパフォーマンスやバッテリー寿命は次世代ディスプレイ対応力を持った、現状から飛躍するものである。そういうわけで、Mirに対する多大な貢献に感謝するとともに、Mirをスマートフォン以上にもっと挑戦しがいのある環境でテストしたものにも感謝する。私は、自分のラップトップで動かして大変満足しているし、Mirネイティブにおけるゲームベンチマークも素敵だ。そういうわけで、開発チーム諸君と、多数のMirのテストと向上を手助けしたコミュニティ諸君、ありがとう。

アプリケーションのアップデートのためのApp containers関連の仕組みは、とても重要だ。今や、我々はアプリ開発者がUbuntuユーザーにアプリを提供するより良い方法を提供し、アップデートに伴うライブラリや依存性の問題をコントロールできるようにしたのだ。また、我々は開発者に、古いバージョンのOSに新しいバージョンのアプリを提供しやすいようにもした。これは我々のユーザーの最大の要求であろうし、スマートフォンのためにやり遂げたのだ。デスクトップとスマートフォンを統合した暁には、デスクトップにも提供されるであろう。私は、これによって、アプリのアップデートがケータイにももたらされることを楽しみにしているし、開発者レビューと公開の仕組みもすばらしいものであると報告を受けている。よくやった。

おお、そうだ。私は反対者から、Ubuntuのダディと呼ばれることをほこらしく思っているよ。私のコミュニティにおける幅広い慈悲は、Mintからクラウド開発者達にまで及んでいて、それからCanonicalのすべての開発チームと我々からの派生品にまで到る、とても明らかなものだ。その中で浮き沈みはある(・∀・)。しかし、我々は団結して浮き上がるだろう。反対者に見えていないのは、読者ひとりひとりが、Ubuntu天界における先達なのだ。先達の行く末の道を整備するのは光栄なことだし、先達に道を通ってもらうのは感激だ。

[訳注：原文ではこれ以降、不自然にTで始まる単語が多い]

で、saucyは缶詰された。これからは14.04の戦略的会話を始めるときだ、これはもちろん、LTSになる。

そのため、我々の目標は、パフォーマンス、改良、保守性、技術的負債になる。次のvUDS[訳注：Ubuntu Developer Summit]で革新的な決断をするのは当然だ。そのため、ぜひとも議論に参加して、14.04を、PCとクラウドとサーバー向けに長期出荷できるようにしてもらいたい。特に、我々はOpenStack I, J, KをLTS出荷となる14.04で提供する。そのため、コミュニティの需要を満たせるようにしたい。デスクトップでは、13.10は開発チームが品質に重点をおいたので、すばらしいもの恩恵が得られるだろう。14.04でも同じようにする。モバイルでは、先に進む競争を持続する。このプラットフォームはまだ、LTSには早すぎるので、完全になるまで長い旅路が必要になる。1サイクルでそこまではいけないが、先月のケータイとタブレットの改良のペースを考えれば、今回のサイクルもすばらしい物になると確信している。

vUDSは、主要な決定がなされる場である。我々は開かれた会議を執り行う。誰でも音声や動画で参加でき、議論はすみやかでオープンマインドであり、結果は同週に伝えられる。仕事、娯楽、睡眠から時間を捻出してまでも参加する価値があり、14.04に必要なものを伝えられ、それを達成するために諸君がどのような貢献を行えるか表明する場である。

それはさておき・・・どう、呼ぶべきだろうか？　T. S. Eliotが言うように、「猫に名前をつけるのは難しいことだ、日常の遊びごとではない」

これは、14.04にふさわしいマスコットを探求する、悩ましい同音分類学であり、つまらないわけがない。いかにたくさんの悪い組み合わせがあることか！　"tasty tailess tenrec"（PETAからのお手紙お待ちしております）とか、"toxic taipan"（よう、豪人）とか、"tantric tarantula"（もうしばし待ち候へ・・・）とか。"trigamous tayra"（便利ー）とか、"trippy tegu"とかはふさわしくない。もうすこし、"twinke-toed tamarin"よりは真面目な、なにか"toric terrapin"よりは発達した、"thermic tamandua"（HEATに関連しているのは気に入っているのだがね、OpenStackの新し目のやつ）よりは関連性のある、"termobaric thornytail"よりはいくらかクールな。いい組み合わせもいくつかある。例えば、あの勝ち亀のような"timely testudo"とか、仕事をしてくれる"tenacious tapir"とかも、よさそうだ。"telegenic tamias"の誘惑は如何ともしがたい、何故ならば、開発者はアップロードするたびに"telegenic"とタイプすることになるのだから。

Themes therianthropic seem a touch tub-thumping, and tigers Tasman a touch extinct. That tarsier is tactile but titchy too, the toad a bit witchy the the tree shrew, too-too. For a tip-top release nothing tepid will do.

[訳注：この文、難解にして訳しがたし]

さて、優勝トーテムは、耐震性あるタブーは、任務と責務の安息の銘文は、誹謗中傷される我らの動物は、我々の思慮深く忠実なるLTSの名前は、諸君、かのSeussがせし如く、やかましく、華々しく、賢く、才能あり思慮あり、そして聞こえある、trusty tahr。

tahrはヒマラヤの鉱山を縦横し、長い毛皮があり、足元しっかりと安定している。観光向けのtahrの群れが、私のお気に入りのテーブルマウンテンに住んでいて、そこではよそ者の扱いを受けているが、長年、堅牢とおそれを知らぬシンボルであり、崖に向かってひるまない。我々は一丸となってやり遂げよう。さあ、砕きにかかれ！

というわけで、次のUbuntu 14.04のコードネームは、trusty tahrに決まったようだ。しっかし、いい加減、コードネームネタも寒いでホンマ。

今回はちゃんとGNU/Linuxと言っており、GNUというOSであり、Linuxはそのカーネルの一つに過ぎないことを明らかにしている。それから、MirなどのCanonicalのやり方に反対する者達を、誹謗中傷する者と読んでいる。

それにしても、ますますシャトルワースの英文が不自然になってきている。

Ubuntu 13.10の雑感

というわけで、Ubuntu 13.10にアップグレードした。Ubuntuのアップグレードというのは、いつも言い知れぬ不安を感じる。

これはUbuntuだけではなく、大抵のGNU/Linuxベースのディストリビューションに言えることだが、非常に変化しやすいということである。不自由なWindowsユーザーが、GUIの配色がちょっと変わったとか、スタートボタンの有無で一喜一憂している程度の変更がバカバカしくなるぐらい、GNU/Linuxベースのディストリビューションは頻繁に変わる。不自由なWindowsでは、設定ダイアログなどにまだWindows 95の時に書かれたものが残っているそうだが、Ubuntuでは、設定のUIなど、数年経つとまるっきり変わってしまう。

このような素早い劇的な変化は、且は機能向上のためになるとはいえ、オマエのカーチャンのためには、使いづらい。

さて、Ubuntu 13.10にやってきたiBus 1.5がクソすぎることはすでに述べた。ここでは、その他の事についてみていこう。

まずは、主要なソフトウェアのパッケージだ。単にUbuntuのパッケージのバージョンが知りたいのならば、Ubuntu – Ubuntu Packages Searchで検索できる。

何はともかくVimだが、2:7.3.547が2:7.4.000になっている。筆者はVimの更新を逐一追ってはいないのだが、聞くところによれば、これには500個以上ものパッチによる変更が含まれているそうだ。少なくとも、Vimが急に、Emacsのように使いづらくなったりはしないので、問題はない。

GCCは、4.7.3から、4.8.1になっている。GCC 4.8.1は、とても興味深いバージョンである。なぜならば、4.8.1は、まだ規格違反のバグがあるにせよ、C++11のコア言語に関しては、一通り実装しているからだ

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

GCCを双璧をなす、最近勢いをつけて調子に乗っているClangはどうか。Clangは3.1から3.2になっている。ところが、どうもUbuntuには、clang-3.2, clang-3.3, clang-3.4というパッケージがあるようだ。それぞれ、パッケージに含まれたバージョンに対応しているようだが、3.4はまだ安定版がリリースされていない。どうも、スナップショット的な扱いのようだが、それならclang-snapshot的なメタパッケージもあると便利なのだが。

chromium-browserは28から29になっている。UbuntuではFirefoxは特別な扱いを受けているので、サポート期間にあるリリースならば、Firefoxは定期的に更新されている。Chromiumもその性質上、リリース内でたまに更新されているのだが、Firefoxほど頻繁ではない。

よくわからないこととしては、アップグレードを適用した再起動後に、メニューによるシャットダウンができなくなったことだ。操作はできるが何も反応がない。幸い、shutdown -hは効いた。問題を再現しようと再び試したところ、今度は問題なく動いた。よくわからない。シャットダウンのような根本的な機能が、GUIから操作できなくなることがあるというのでは、まだUbuntuはオマエのカーチャンが使えるレベルに達していないと言える（ただし、オマエのカーチャンがカーネルハッカーやロケット科学者である場合を除く）

iBus 1.5がクソすぎる

Ubuntu 13.10へのアップデートが、問題なく終わった。問題は、iBusが1.5にアップデートされてしまったことだ。

iBus 1.5は、去年の年末にリリースされた。リリース直後から、IRCでは怨嗟の声が絶えなかったが、今になって、ようやくその意味がわかった。iBus 1.5はひどい。ひどいなんてものじゃない。クソだ。いや、クソですら上品過ぎる。iBusは超超超超超・・・残念ながら、まだiBusを罵るべき言葉が発明されていないが、とにかくその超なにかだ。

UNIX風システムでは、伝統的に、日本語入力は、かな漢字変換を担当するIMEと、IMEと文字入力を受け取るアプリケーションの間の橋渡しをするIMに分離されている。ユーザーから見えるIMの役割としては、IMEの有効無効を切り替えることだ。

筆者はこれまで、IMとしてiBusを、IMEとしてMozcを使っていた。

iBusはIMである。いや、正確には、かつてIMだったもの、というべきだろう。もはやIMと呼べないクソに成り下がっているからだ。

Ubuntu 13.10にアップデートした後、筆者は、IMEが有効にならないことに気がついた。不思議なことに、iBusで有効にするIMEの設定が消えているらしい。筆者が思うに、これはiBus 1.5の変更の問題であると思う。

まあ、それはいい。もう一度設定すればいいだけだ。筆者は早速、iBusの設定画面を開いた。しかし、設定方法が全くわからない。不思議だ。筆者のようなパワーユーザー（死語）が、GUIによるソフトウェアの変更ダイアログの操作方法がわからないというのか。もし、筆者のようなパワーユーザーが理解できないとするならば、それは設計が悪いのだ。

iBus 1.5では、設定ダイアログが大幅に簡略化されている。まあ、それはいい。筆者は消え去った大部分の設定は変更していなかったのだ。ただし、IMEを設定する項目までなくなっているというのは、一体どういうことだ。それに、よくみれば、設定UIが、独自のダイアログではなく、Ubuntuのシステムの設定UIに統合されている。どこか他の場所に設定項目があるのか。いやない。あるのはキーボードレイアウトの設定だけだ。キーボードレイアウトの切り替えはIMの仕事ではあるが、IMEとは関係がない。ためしに、Japaneseを追加してみても、Mozcは使えない。ただキーボードレイアウトが変わるだけだ。そもそも、筆者は英語配列のキーボードを使っている。配列はこのままになってほしい。日本語配列になってほしくはないのだ。

真相は衝撃的なものであった。

iBus 1.5では、IMEの設定が、キーボードレイアウトの設定に統一された。従来のIMEの設定は廃止され、キーボードレイアウトのひとつして、追加されている。例えば、Mozcがインストールされていた場合、Japanese(Mozc)として存在する。

ハァ？　ハァァ？　ハァァァァッ！？

アホか？　ドアホなのか？　一体何を考えてるんだ。どこのクソまみれのケツ毛ボーボーのニコチャン星人がこんな改悪をしたのだ。一体何を吸っていたらこんな馬鹿げた改悪を思いつくのだ。

キーボードレイアウトとIMEは、全く別の概念であって、それを統合するというのは、ありえないことだ。キリル文字を入力するのなら、キーボードレイアウトを変更するだけですむ。しかし、日本語や中国語やハングル語のような何千、何万と文字があるような言語のためのIMEは、キーボードレイアウトとは根本的に異なる概念なのだ。一緒にするなどありえない。

問題はそれだけではない。iBusは、これ以外にもありえない改悪をしている。キーボードショートカットの認識方法だ。

例えば、iBus 1.5にCtrl+Spaceというキーボードショートカットを設定したとする。iBusにこのキーボードショートカットが使われたと認識させるためには、以下のステップをこなさなければならない。

1. Ctrlを押し下げる
2. Spaceを押し下げる
3. Spaceを離す

もし、ステップ2の後、Spaceを離すまえにCtrlを離してしまうと、CtrlとSpaceが何秒間、何分間、何時間（時間単位では試していないが）、同時押しされていようとも、キーボードショートカットとしては認識されない。一体どこのアホがこんな認識方法に改悪したのだ。

なるほど、去年の年末にiBus 1.5が叩かれていたり、Ubuntuに貢献している人間が、Fcitxなどの別のIMを検証していたりしたのは、このためか。iBusを何とかするより、別のIMを使ったほうがよさそうだ。

筆者はIMのキーボードレイアウトの機能は使っていないのだが、ショートカットの認識方法の変更のため、IMEの有効無効を切り替えようとして、切り替えられない自体が頻発している。これではまともに日本語が入力できない。クソすぎる。

参考：iBusがクソになった理由 — KaoriYa

RSAのSにあたるAdi ShamirのVISA申請がありえないくらい遅れて、カンファレンス参加不可

The Risks Digest Volume 27: Issue 54

RSAのSにあたるAdi Shamirは、アメリカ合衆国のカンファレンスに参加するために、カンファレンス開催日の2ヶ月半も前の6月にVISAを申請したが、VISAの認定が遅れに遅れて、カンファレンスに間に合わなかったそうだ。ようやくVISAの申請が通ったのは、すでに10月だったとか。

単なる手続きの遅れではなく、明らかに、アメリカは暗号研究者に対する言われない迫害を加えているのだという。

Adi Shamir--the "S" in RSA encryption--Prevented from Attending US Crypto Talks | Hacker News

Hacker Newsのコメントでは、Microsoftで働いている人間が、VISAの申請に最大で32週間かかったことを報告している。レドモンドにある本社に行くのに、滞在予定の半年も前にMicrosoft社から大使館にその旨を書簡で知らせなければならないそうだ。

またあるコメントでは、前にVISAの面接で、暗号研究者かどうか聞かれ、そうではないと答えると、面接がその時点で終わって申請通過になったという報告もある。

相変わらず全体主義の国であることよ。

JavaScriptのよるOpenRISCエミュレーター上でGNU/Linux/XorWaylandを動かすデモ

jor1k: OpenRISC OR1K Javascript Emulator Running Linux

Github: s-macke/jor1k

JavaScriptでOpenRISCをエミュレートして、その上でGNU/Linuxを動かし、さらにXやWaylandまで動かしてしまうというふざけたデモ。

筆者の環境では、0.3fpsほどで動作した。

クッキー・クリッカー完結編

この話は、本の虫: クッキー・クリッカー：リセットのループの続編にして、おそらくは完結編である。これ以上は望めないからだ。

本の虫: クッキー・クリッカーについて
本の虫: ババア補完計画
本の虫: クッキー・クリッカー物語
本の虫: クッキー・クリッカー：リセットの効果
本の虫: クッキー・クリッカー：リセットのループ

エゾエはついに、青天上のチップをためすぎて、指の一振りで、出現した莫大な質量のクッキーがブラックホールを生成するに至った。もはやこれ以上は望むべくもない。

3554週目

「おい、エゾちゃん、いったい何をしようっていうんだ」
「そうだエゾエ。お前が何か重大なことを発表したいというから、こうしてお友達や親戚一同に集まってもらったんだぞ」

エゾエはサヨナラも言わずに指をカチッと動かす。即座に、莫大な質量のクッキーが宇宙空間に出現した。その質量が大きすぎるがゆえに、自重によって内側に潰れ、ブラックホールと化す。周囲の惑星や恒星はことごとく飲み尽くされ、破壊しつくされてしまうのだ。クッキーによって。

これ以上、どうしようというのだ。もはや、エゾエにはカーソルは必要ない。ババアも必要ない。農場も工場も、ないしはタイムマシンも反重力変換装置も必要ないのだ。ただ指を動かすだけでよい。指を動かすだけで、クッキーは生産される。しかし、生産したところで、ブラックホールとなるに過ぎないのだ。

次こそは断ろう。リセットを断ろう。そう思い続けて、果たして何百週目だろうか。いや、事によると何千週目かもしれず、あるいは何万週目かもしれない。もはや、昔の記憶はぼんやりと霞がかかったように、思い出せないでいるのだ。

エゾエは宇宙空間に漂いながら、様々な思索にふけった。

ある時はドイツの哲学者のごとく、クッキーの統一体系をつくろうし
ある時は老博士の言ったように、「業でなければ救われぬ」
一体、思いはめぐってどこに行くというのか、もう三十に近いというのに

ふと何気なく、エゾエは左手で円を描き、ポータルを出現させた。特に意図したわけではない、いまさらポータルなど必要はないのだ。ああ、思い出せば、クッキー宇宙へのポータルを開くのに、昔は苦労したものだ。今では、手をくるりと回す程度の労力だというのに。

ところが、ポータルからクッキーは出なかった。無理もない。事前の調整も何もなかったのだ。クッキー宇宙には繋がらなかったのだろう。

いまさらポータルを開いても意味がない。さっさと閉じてしまおうと、エゾエはポータルに手をかけた。すると、クッキーがひとつだけ、ポータルから飛び出して、エゾエの手に張り付いた。

不思議なこともあるものだ。そう言えば、もう久しくクッキーの味をみていなかった。どれ、久しぶりに、クッキーを食べてみるとするか。

ポータルから出てきたクッキーを食べようとしたエゾエは、口の中に違和感を感じた。吐き出してみると、何やら書きつけのしてある紙切れのようである。読んだエゾエは、世界の真理を知った。

この宇宙は、五流大学の学生が、卒論をでっち上げるために作り出したシミュレーション宇宙だという。この宇宙はすべて、単なるシミュレーション上の産物に過ぎないのだ。

そして、そのシミュレーション宇宙で、たまたま発生した、クッキー中心の物理法則に支配された宇宙と、ひたすらクッキー生産に没頭する哀れなエゾエがとてもおもしろく、今ではゲームに映画にと、マルチメディア展開されているのだという。

そして宇宙の終焉には、必ずエゾエは娯楽として処刑されるのだという。

この宇宙で、エゾエがポータルと認識していたものは、シミュレーション宇宙を外部とつなぐ通信プロトコルである。この紙切れは、今のエゾエの一つ前の周回のエゾエが、真理を知って処刑寸前のエゾエが、ひそかに送った手紙。

手紙はさらに、この宇宙がHTML/CSS/JavaScriptで実装されていること、その変更方法に及んでいる。

初めに、クッキーがあった。エゾエの魂はクッキー宇宙を漂っていた

「自動的にクリックせよ」とエゾエは言った。

setInterval( function(){ Game.ClickCookie() }, 4 ) ;

そして自動的にクリックされた。エゾエは自動的なクリックをみて、良しとした。

そして、得られたクッキーで、ババアを購入し始めた。

しかし、ババアを一人づつ購入するのも面倒なので、「ババアを1000人買え」と言った。

for ( var i = 0 ; i != 1000 ; ++i )
    Game.Objects['Grandma'].buy() ;

そしてそれは試みられた。

しかし、さすがにババアを1000人も買うクッキーがない。おおそうだ、クッキーを直接増やせばいいのだ。「クッキーあれ」

Game.cookies = Number.MAX_VALUE ;

1.7976931348623155e+308個のクッキーが得られた。

そしてクッキーがあった。

とうとうエゾエはクッキーに飽きてしまった。

己が幾度もの生涯をかけて生産に邁進していたものは、一体、こんなにもつまらないものであったのだろうか。何という時間の無駄だ。一体ゲームというのはなんだ。数字がゆっくりとインクリメントされていくのを眺めるだけなのか。

ほとんどのビデオゲームは、クッキー・クリッカーと一般なのだ。数字がゆっくりとインクリメントされるのを眺めるだけだ。そのインクリメントに影響を及ぼす操作が提供されているが、なんということはない。究極的には、さっさと最大値を代入してしまえばいいのだ。それを時間を浪費してゆっくりとインクリメントする。愚かならずや。

語を天下のゲーマーに寄す。諸君はよろしくプログラミングを学ぶべし。ソフトウェアは利用者の意のままにふるまうものであり、天から与えれた自由を他人の手に渡してはならない。

古典的だが面白い効果

Zoomquilt

これは面白い。

効果的には、80年代に流行ったテクニックで、例えばちょっと探しただけでも、1977年の例も見つかる。

▶ Powers of Ten™ (1977) - YouTube

完璧過ぎるforwarding

Too perfect forwarding | Andrzej's C++ blog

これは知っていても引っかかる。今後、perfect forwardingを解説するときには、これについても解説する必要がある。

ビル・ゲイツ曰く、「俺は飛行機の中でFAT書いたこともあるんだぞ、アホンダラ」

I wrote FAT on an airplane, for heaven's sake - The Old New Thing - Site Home - MSDN Blogs

16-bit Windows用にコードを書く時、パフォーマンスの最適化として割く時間には、どの関数をどのセグメントに置くかということがある。

16-bit Windowsにおけるコードは、コードセグメントの中から実行される、セグメントのサイズは64KBである。コードセグメントがひとつディスクからロードされるときは、そのセグメント全体がロードされるし、セグメントが破棄される時には、そのセグメント全体が破棄される。つまり、関数がどのセグメントに配置されているかということは、アプリケーションのパフォーマンスに多大な影響を及ぼすのだ。

例えば、同時に呼ばれる関数群を同じセグメントに配置しておくのは都合がいい。そうすれば、関数群は一個のものとして読み込まれ、I/O時間を節約できる。考えなしに関連性のない関数を同じセグメントに配置したならば、セグメント上の関数を呼び出すと、他の関数まですべてロードされてしまい、使わない関数までロードするので、I/Oを浪費する。

たとえ関数が同時に呼ばれるとしても、その頻度には目を配っておかなければならない。頻繁に呼ばれる関数と、頻繁に呼ばれない関数（ただし最初の関数の後に呼ばれる）がある場合、頻度の低い関数は、虎の威を借りてメモリにロードされたままになる。これにより、メモリ使用量が上がり、容量を開けるために、頻繁に呼ばれる関数が破棄されることもある。

セグメントを細かく大量に作ると、メモリ使用量を細かく管理できるが、その分オーバーヘッドも多いし、I/Oにも負担がかかる。なぜならば、セグメントをロードするという事は、ディスクへのラウンドトリップだからだ。そのため、メモリー使用量とI/Oのコストのバランスを取らなければならない。

関数群をセグメントに配置する最適化を、セグメントチューニングと呼ぶ。

Windows 3.0の開発中、定期的な会議でビル・ゲイツに進捗を報告することになっていた。ある会議の議題はパフォーマンスで、ビルは、「てめーらセグメントチューニングに時間かけすぎだろ。セグメントチューンなんて12歳のガキにだってできらぁ。もっと本物の最適化をやれ。こんな馬鹿馬鹿しいセグメントチューニングじゃなくてよ。おれは飛行機の中でFAT書いたこともあるんだぞ、アホンダラ」と文句をつけた。

（やれやれ、こういうことを書くことになるとは。これは議事録ではなく、やや脚色されている）

この、「俺は飛行機の中でFAT書いたこともあるんだぞ」というのは、ビルが本物のプログラミングをしていないと感じた連中に文句をつける時のセリフらしい。だが、今回ばかりは、開発マネージャーはうんざりしたので、こう言った。

「あらそうなの、ビルさん。では、Windowsのソースコードが入ったマシンをご用意いたしますので、あなたの魔法のプログラミングとやらを発揮して最適化を手伝ってくださるかしら？」

これにより、ビルを黙らせた。

久々にOld New Thing。

コメント欄では、「悲しいかな、もしビルがFATの開発にもっと時間をかけていれば、もう少しはマシなものになったものを」とか、「飛行機の中で書いたから何だっていうんだ。なんにも変わらんだろ」などと言われている。特に、この時代のプログラミングというのは、当初の記述は紙の上で行われることも多かったので、なおさら変わらない。

ところで、この開発マネージャーというのは原文では女性という事になっているのだが、日本語ではセリフの言い回し以外に自然な方法でその情報を表現できないのは難しい。

どうもPCが不調

どうもPCが不調だ。

わかりやすい兆候としては、たまにHDDから異音がするという事だ。ただ、異音といっても、それほど極端に変な音ではない。OSのインストール時に聞こえたような、頻繁にシークと書き込みを繰り返すような音だ。同時に、HDDへのアクセスも発生しているらしい。しかし、そのようなHDDへの長時間の多大なアクセスが発生する作業はしていないはずなのに。

念の為、重要なデータは別のHDDにコピーしておいた。

HDDの問題だろうか。ファイルシステムの問題だろうか。

どうもこの問題は、昨日、Ubuntuをアップデートしてから起こり始めたので、ひょっとしたらUbuntuのアップデートの問題かもしれぬ。ただし、みたところ、似たようなバグ報告はないのだが。

HDDの故障だとすると、困ったものだ。

Gentooを最速でブートせよ

Patrick's playground: October 2013 Archives

KVM上のVMで、Gentooをひたすら短時間でブートして、haltさせる試み。

BOOTING FAST(ER)

（より）高速に起動

本日、筆者は積年の疑問を解決すべく遊んだ。どのくらい速く、KVM上のVMでブートして、haltできるのか。

そこで、この実験のため、CPUの速度を最低の1.4GHzにした。そうでなければ面白くないだろう。目標は、KVMのVM上のGentoo/amd64を、十分に短い時間でブートして、haltすることだ。

rootファイルシステムはsquashfsにした。最初に行った1GBのext4ファイルシステム vs squashfsでは、fsck+mountというありがた迷惑のため、5秒の差がでたからだ。うへぇ。stage3を展開し、いくつか設定をして（デバッグのためにログインしたかったので、パスワードを設定などした）、squashfsを以下のように構築した。

mksquashfs stage3/* ./kvm-squashfs -comp lzo

カーネルは最小に削ぎ落した。virtioドライバーを使い、他はすべて削ぎ落とし、必要の無さそうなものを次第次第にそぎ落としていった。

Setup is 15264 bytes (padded to 15360 bytes).
System is 3004 kB
CRC 7315b3d8
Kernel: arch/x86/boot/bzImage is ready  (#8)

まだちょっとデカすぎる。これでも何度目かの削ぎ落とし試行をした結果なのだ。

最初の挑戦では、7.5秒ほどに計測された。

qemu-kvm -nographic  -kernel kernel  -boot c -drive file=./kvm-squashfs,if=virtio -append "quiet root=/dev/vda console=ttyS0 init=/sbin/halt"

[    7.409846] reboot: Power down

悪かぁないが・・・よくもない。明らかに、遅くてデブいのはbashだ。そこで、busyboxのshを使うことにした。

[    5.709225] reboot: Power down

おおっと、こいつは驚き桃の木山椒の木。

他に驚いたこととしては、"-smp 4"でブートすると、0.3秒ほどカーネル時間を食う。パラレルブートすると、0.2秒遅くなる。ハァッ？

mdevとudevの違いは誤差の範囲だ。mdevのほうがわずかに早いようにみえる。

メモリーを追加すると( -m 1024 )、0.2秒ほどスピードアップする。

ブートパラメーター"quiet"で、0.1秒ほど稼げる。

しょうもないサービスが山ほどある。削ってしまおう。

# ls /etc/runlevels/*

etc/runlevels/boot:
bootmisc  hostname  localmount  mtab  net.lo  procfs  sysctl  tmpfiles.setup

etc/runlevels/default:
local  netmount

etc/runlevels/shutdown:
killprocs

etc/runlevels/sysinit:
dmesg  mdev  sysfs

さて、不必要なものが山ほどある（keymap？　キーボードなんざお呼びじゃねェぜッ！）ので削れる。（root？　squashfsだから、/をrwで再マウントなんかできねェぜッ！　urandom？　そもそも乱数seedなんて保持できねーのによ。等など）。結果？　かろうじて5秒以下になった。

[    4.966840] reboot: Power down

しかし、ここで筆者は気づいてしまう・・・まてよ・・・最後のkillprocsが、「永遠」みたいに時間かかるぞ。何でだと思う。実は・・・二回もの・・・"sleep 1"

なんという時間の無駄遣いだ。消せ消せ。

[    2.798762] reboot: Power down

やったぜ。開始から停止まで3秒以下だ。

続き

BOOTING SERIOUSLY FAST NOW

マジで高速に起動

KVMのインスタンスをブートしてシャットダウンまで：

[    0.653860] reboot: Power down

やってやったぜ。筆者は前回の2.5秒の記録を劇的に破ってみせたぜ。何があった？

スタートアップはもうマジで速くなったのだが、シャットダウンが、永遠に激遅だった。不思議なことだ。そこで、sysvinitを読んで、いったいstop/rebootで何が起こっているのか調べてみた。興味深い部分が、/usr/include/sys/reboot.hにあった。

/* Stop system and switch power off if possible.  */
#define RB_POWER_OFF    0x4321fedc

マジックナンバーがシステムコールに渡されて、カーネルに「止まりやがれ」と命じる。

sysvinitのソースを更に掘り進めていくと、筆者が気がついたのは・・・えーっと・・・ハァッ？・・・ハァァァッ？

src/halt.c ~line 266:

        if (do_sync) {
                sync();
                sleep(2);
        }

というわけでですな、場合によってはですな、つまり、その、オホン、2秒もオネンネかよ！！！！！

（この時点で、全体のブートサイクルは2.5秒であることをお忘れなく）

do_syncをセットするのが何であるかを調べたあと（-nオプションだったよ）、とりあえず/etc/inittabに設定してみた。

-l0s:0:wait:/sbin/halt -dhp
+l0s:0:wait:/sbin/halt -dhpn

どうだ。開始から停止までのサイクルが1秒未満。

とりあえず記録のために書いておくと、7.5秒から0.7秒に縮めるために、4秒のディレイを発生させるsleep()を3個取り除き、busyboxのshとは違いクソ遅いbashによって「浪費」されていた2秒を稼いだ。

どうやら、このあたりをプロファイルする奴は、ここ10年ほどいなかったようだなw

更に続き

FASTER BOOT AGAIN NOW

またまた高速化ブート

[    0.338524] reboot: Power down

さて、もういい加減にバカバカしくなってくる。

これは、net.loを開始しないために速くなってるのが大きい。それと、必須ではないinit scriptを全部取り除いた。どうもパースするオーバーヘッド（あるいは、単にひとつのディレクトリ下により多くのファイルが存在することに起因する遅さ）というのが、このレベルになると無視できなくなってくるのだ。

で、何が起こっているのか。

カーネルがブート
rootfsのマウントされる
その他のファイルシステム（proc, sys, dev, run ...）がマウントされる
udev/mdevが開始

この後に、ログイン可能になる。電源投入から約250ミリ秒後だ。（あるいは、kvmの開始から一秒後、kvmも無視できないほどの初期化時間がかかる）

これはもはや何の役にもたたないと言われるかもしれないが、これは単に、高速にブートするということであって、他の何かをするのではないのだ。

なぜGCCのCプリプロセッサーはlinuxという名前のマクロ名を定義するのか

Why does the C preprocessor interpret the word "linux" as the constant "1"? - Stack Overflow
Why does the C preprocessor interpret the word “linux” as the constant “1”? | Hacker News

以下のCコードをコンパイルしようとするとエラーになる。

$ cat test.c
#include <stdio.h>
int main(void)
{       
    int linux = 5;
    return 0;
}
$ gcc test.c
test.c: In function ‘main’:
test.c:4:9: error: expected identifier or ‘(’ before numeric constant

なぜだろうか。stdio.hではそのような名前のマクロが定義されてはいない。試しにCプリプロセスだけをするオプション、-Eを使ってみると、以下のような結果となる。

$gcc -E test.c
...
int main(void)
{
    int 1 = 5;
    return 0;
}
$

なんと、linuxというトークンが、Cプリプロセッサーによって、1に置き換わっているではないか。道理でコンパイルエラーになるわけだ。しかし、なぜなのか。

これは、昔多くのCコンパイラーが、unix環境では、unixという名前のマクロを定義していたことによる。これにより、プログラムは#ifdefやifndefなどを使い、プログラムがunix環境でコンパイルされているかどうかで場合分けをすることができる。

この名残で似たように、linuxというマクロ名がある。これは、GNU/Linux環境で定義される。

この規格違反の挙動は、GCCに規格準拠に振る舞うようにオプションを指定することで変更できる。

$gcc -E -std=c11 -pedantic test.c
...
int main(void)
{
    int linux = 5;
    return 0;
}

なお、GNU/Linux環境では、unixとlinuxが同時に定義される。これは、おそらく互換性の問題だろう。GNU/Linuxは、unixと互換性があり、多くのunix用プログラムは、単にコンパイルするだけで動作する。問題は、多くの既存のUnix用プログラムのソースコードが、unixのようなマクロが定義されていることを当てにしていて、もし定義されていない場合、コンパイルができなかったり、動作しなかったりしてしまう。互換性があるのにも関わらず、近眼でハードコードされたソースコードの記述により、動作しなくなってしまうのだ。そのため、GNU/Linux環境でも、unixが定義されている。

これから書くプログラムは、このような規格違反で実装依存の独自拡張のマクロ名に依存してはならない、Cならば-std=c11 --pedantic-error、C++ならば、-stdにはc++11ないしは、いずれはc++14を指定すべきである。

アゼルバイジャンの大統領選挙、投票が始まる前に結果を発表

Oops: Azerbaijan released election results before voting had even started

アメリカ合衆国の同盟国であり、アメリカが金銭的に支援する独裁国家と父親から世襲した独裁者Ilham Aliyevの支配するアゼルバイジャンでは、形だけ民主主義の大統領選挙が行われた。その選挙の票集計に不正があるという事は、公然の秘密であった。

このたび、なぜか投票が始まる一日前に、投票結果が公開されるという失態をしでかした。政府によれば、2008年の投票結果を誤って公開してしまったとのことだが、なぜか候補者は今回のもので、しかも得票率も2008年とは異なっている。

アゼルバイジャンでは、不正を指摘するものは弾圧され、Ilham Aliyev以外の候補者は抑圧されているという。

GNU Make 4.0にGNU Guileが組み込まれた

GNU Make 4.0 released

GNU Make 4.0がリリースされた。

今回のリリースでは、GNU MakeはSchemeの実装であるGNU Guileを組み込んだ。これにより、Makefileの中でSchemeが書けるようになる。

その機能は、GNU Make ManualのGuile Functionの項目で説明されている。まだ、オンライン版のGNU Make Manualが2010年から更新されていないので、コミット時のドキュメントの差分のリンクする。

8.13 The `guile' Function

具体的な組み込み方法としては、make側にguileという関数が追加され、この引数に文字列を与えると、SchemeとしてGuileで処理されるようになる。おそらく、このように。

Hello.o : $(guile (string-append "hello" ".c" ) )
    ...

makeはguileを使ってguile関数を評価し、結果の文字列を、makeへの文字列として評価する。また、displayなどの副作用による文字列も、makeで評価される文字列になる。副作用による文字列のみを使う場合、文法エラーを防ぐために、#fを返す。

文字列以外の型にたいしても、GNU Make用の文字列への変換方法が規定されている。例えば#fは空文字列になり、#tは非空文字列になる。シンボルや数値や文字はそのまま文字列になる。リストは、要素はそれぞれ文字列になり、リスト自体は、Makeで処理することを考えて、平らな文字列にされる。たとえば、`'(a b (c d) e)'というリストは、Makeに返す文字列としては、'a b c d e'となる。これ以外の型を返すとエラーとなる。

Guile側にも、schemeの関数としてMakeの機能が与えられている。

gmk-expandは、文字列をひとつ引数にとる。文字列はmakeのルールに従って展開される。展開後の文字列が結果となるので、scheme側でさらにMakeで展開後の文字列をさらに処理できる。

gmk-evalは、文字列をひとつ引数に取る。文字列はあたかもmakefileに書かれているごとく、makeによって評価される。結果は空文字列である。

gmk-varは、文字列をひとつ引数に取る。文字列はmakeの変数として展開され、評価結果は展開後の文字列となる。

ドキュメントでは、大量の入力を、コマンドライン引数ではなく、テキストファイルとして受け取り、Guileを使ってテキストファイルを読み込んで処理する例が挙げられている。

たしかに、GNU Makeは相当に複雑な使い方をされているから、いっそのこと汎用的なプログラミング言語がほしいと思うのはわかる。しかし、Schemeというのはどうなのだろう。常々、学びたいとは思っているのだが、どうしても文法が・・・、いや、何も言うまい。

GNUである以上、「CとLispは両方ともシステムプログラミング言語として提供される」のは当然ともいえよう。

リチャード・ストールマン

Unixに自由を！

今年の感謝祭から、私は完全なるUnix互換ソフトウェアを書き、GNUと名付け（Gnu's Not Unixの略である）、使える者には誰にでも自由に与えるであろう。時間、金、プログラム、備品の貢献が切実に必要とされている。

まず、GNUとはカーネル並びにCプログラムを書いて実行するのに必要なすべてのユーティリティ、すなわちエディター、Cコンパイラー、リンカー、アセンブラー、その他の細々としたものである。その後、テキストフォーマッター、YACC、Empireゲーム、表計算、その他数百余のソフトウェアを追加する。いずれ、Unixシステムにある通常の便利なもの、オンラインとローカルのドキュメントを含む便利なものはすべて揃って提供できることが我らの願いである。

GNUはUnixプログラムを実行できるようになるが、Unixと一般ではない。他のオペレーティングシステムの経験から得られたあらゆる便利な改良を施すのだ。特に、我々は長いファイル名、ファイルバージョン番号、クラッシュ耐性のあるファイルシステム、たぶんファイル名補完、ターミナルから独立したディスプレイのサポート、そしていずれは、Lispベースのウインドウシステムを提供し、Lispプログラムと通常のUnixプログラムが画面を共有できるようにするであろう。CとLispは両方ともシステムプログラミング言語として提供される。UUCPよりはるかに優れた、MITのchaosnetプロトコルに基づいたネットワークソフトウェアも作る。ことによるとUUCPと互換性があるかもしれぬ。

私は何者か？

我こそはリチャード・ストールマン、EMACSエディターの元となるエディターを発明し、今はMITの人工知能研究所に籍を置いている。私はこれまで、コンパイラー、エディター、デバッガー、コマンドインタプリター、Incompatible Timesharing System、Lispマシンオペレーティングシステムに深く携わってきた。私はITSにおけるターミナルから独立したディスプレイサポートの先駆者でもある。さらに、私はクラッシュ耐性のあるファイルシステムを実装し、Lispマシン用のウインドウシステムを二つまで実装した。

なぜGNUを書かねばならぬのか

そもそも私は、良いと思うプログラムは、同感の他人と共有できなければならないと思うのだ。私はNDAやソフトウェアライセンス同意に署名することに違和感を覚える。

ゆえに、私の思想を維持してコンピューターを使い続けるためには、自由ではないソフトウェアを無視できるほどの、十分な自由ソフトウェアを集めようと決意した。

いかにして貢献できるか

私はコンピューター製造者にマシンと金の寄付を募っている。個人には、プログラムと労力の寄付を募っている。

あるコンピューター製造者が、すでにマシンを寄贈している。しかし、もっとあって困ることはない。マシンを寄贈すれば、早くからGNUがその上で動くことが期待できる。マシンは通常の居住空間で動作し、特別な冷却や電源を必要としないものが望ましい。

プログラマー個人は、Unixユーティリティの互換品を書いて私に送ることで貢献できる。ほとんどのプロジェクトにおいては、そのような片手間の分散作業は、管理しづらい。独立して書かれた部品はひとつにして動作させにくい。しかし、Unixの一部を置き換えるにあたっては、その問題は存在しない。ほとんどのインターフェース規格はUnix互換により固定できる。もし、それぞれの貢献がUnixのその他の中で動くのであれば、GNUでも動くであろう。

もし、金の寄付を受けたならば、何人かをフルタイムないしパートタイムで雇うことができる。給料は高くないが、金より人類への貢献を重んじる者を探している。これは、人生を変えるという使命感により、この作業で、能力ある者たちを全力でGNUに向かわせることができる方法である。

new UNIX implementation - Google Groups

戯作について思う

この五日間、用事があって留守にしていた。その五日間の暇な時間に、かねてから読もうと思いつつも、つい打ち捨てておいた小学館の日本古典文学全集47 洒落本　滑稽本　人情本を読んだ。だいたい200年ぐらい前の江戸時代の文章だ。このような名前で呼ばれた当時の本は、廓が絡む話が多い。

読んでいて思ったのは、日本語というのは200年前も今も、案外変わっていないという事だ。もちろん、東京の方言で書かれているが、それを差し引けば、今の日本語とほとんど変わらない。

これは、洒落本、滑稽本、人情本が、読本とは違い、漢文がほとんど出てこずに、会話文主体の文章になっているからだと思う。日本語の話し言葉は、方言による単語や発音さえ差し引けば、200年前と今とで、あまり変わっていない。ただ、書き言葉だけが、平安時代に成立した様式がそのまま保たれただけのことだ。

ただし、どうしたわけか、会話文主体の文章なのにも関わらず、どの作品も、依然として露骨に漢文が出てくる。その方法は様々で、例えば物事を何でも漢音で話すクセのある漢学者を登場させたり、読本好きで漢文くずれの話し方をする人間を登場させたり、文盲（漢文が読めない者を指す）に無理やり漢文を読ませたりしている。なぜ、そこまでして露骨に漢文を出さなければならなかったのか。

結局、本物の文章は漢文（実質は古代中国語風の怪しい文章）で書くべきだという慣れがあったのだろう。今でも、我々は一部の発音とは異なる例外的な書き言葉を使っていて、その文法に従わない文章、例えば、「こんにちわ、今日わ街え買い物に出かけました」のような文章に、気持ち悪いほどの違和感を感じるのと同じなのだろう。

現代文らしい文章は、明治になって現れた。言文一致論が叫ばれ、特に二葉亭四迷と夏目漱石が、比較的よくやった方だと思う。私としては、世間一般では、夏目漱石は過剰に評価されていて、二葉亭四迷が仮称に評価されているように思うのだが、なぜ世間は夏目漱石ばかりやたらと持ちあげるのだろうか。作品数の違いからだろうか。

また、当時の時の権力による邪悪な検閲についても、一言述べておかなくてはならない。

こういった種類の本は、その扱う内容が内容なだけに、時の権力たる幕府が、頻繁に検閲している。洒落本、滑稽本、人情本などと細かくわけられているのは、流行による移り変わりもあるが、その都度、大規模な検閲のため、文化が途絶えているからだ。検閲は文化の進化を妨げ、絶滅させてしまうのだ。

検閲の害悪は文化だけにとどまらない。技術にも悪影響を及ぼす。この手の本は、版木印刷され、貸本屋に並べ、貸本屋からレンタルして読むという流通形態をとっていた。印刷された本には、版木の多色刷りによる見事な絵が何枚も印刷されていた。ところが、時の権力たる極悪な幕府は、多色刷りは公共風俗のためよろしからぬとして、多色刷りも検閲した。検閲は技術の進化をも妨げるのだ。

今も、日本には表現の自由がない。表現はわいせつ性という、時代ごとに異なる、明文化されない、とても曖昧な性質を有すれば、検閲される。そのわいせつ性を認められた物を配布するのは違法である。これは憲法に保証された表現の自由を犯している。

他にも、著作権や特許権といったものも、その本来も意図とは裏腹に、表現規制に何役も買っている。

さて、肝心の、この小学館の全集の質はどうかというと、あまりよろしくない。

まず、字体を新字体準拠を変更していること。字体は重要な表現の一部であり、それを勝手に変えるのは芸術作品への冒涜である。

カナも一部漢字に直しているという。言葉をカナでかくか漢字で書くかというのは、じゅーよーなひょーげんの一部である。イングリッシュでアッパーケースだけで書かれている部分を勝手にローワーケースに変えることがオリジナルミーニングをスポイルするように、カナと漢字を底本通りに翻刻しないのは原意を損なう。

さらに悲惨なことに編集者の勝手に句読点を打っていること本来句読点なしに書かれていた文章に句読点をあとから付け加えるのは芸術作品への冒涜であり甚だしく原意を損なう憎むべき行為だ。

さらに、山のように注釈があることも問題だ。たしかに、注釈があるのはありがたいが、注釈は読者の興味を散漫とさせ、本文への集中を妨げる。注釈は表示/非表示を切り替えられるべきであり、この点からも、早く死んだ木の本を絶滅させて、GFDLが定義する「通過」な媒体、フォーマットを普及させるべきである。現時点では、HTML/CSS/JavaScriptが最も適切である。

ただ、この本には、ひとつだけ評価できる点がある。それは、仮名遣いを改めなかったことだ。

私がここで言っているのは、旧仮名遣いを新仮名遣いに改めるという事ではない。それは評価のしようがない邪悪だ。旧仮名遣いを新仮名遣いに改めた編集者は、日本人であるならば皆腹を切って詫びるべきである。他人の作品を汚すならば、自分が死ぬべきだからだ。もちろん、本物の小刀を使って腹を切るべきだ。扇子でごまかしてはならない。また、オリーブオイルをぶっかけられた筆者が空飛ぶスパゲティモンスター様の地獄に叩き落とすべきもの等だ。地獄ではビール火山はすでに死火山となり、ストリッパーは性病にかかっており、麺は伸びきっている。

私が声を張り上げて悪だと主張したいのは、「正しい歴史的仮名遣いに改めた」という主張だ。正しい歴史的仮名遣いなど存在しない。さだいえを引っ張りだしてきても解決しない。そもそも、THE歴史的仮名遣いなどというものはなく、単に、仮名遣いが統一されていなかったというだけなのだ。そのため、話し言葉とその発音を文字に書き出す際、作者ごとに思い思いの方法を使って表現した。たとえば、「いえない」に対して、「いいゑない」と書いたり、「おとっつぁん」の「つぁん」を、「さ゜ん」と書いたりする類だ。これらはいずれも、作者の表現の一部であり、勝手に変えるのは芸術作品への冒涜である。

小学館の全集は、新字体に変えるという許しがたい蛮行のため、普段は読むことがないのだが、こればかりは古本市で捨て値で投げ売られていたので、買ってきたのだ。

本の質はともかく、中身に関しては、なかなか面白い。他の戯作も読んでみようと思う。

とにかく、まともな戯作を読むには、草書体を学ぶか、あるいは古本を漁るしかないだろう。

Ubuntu 13.10でのXMirデフォルトが見送りになる模様

[Phoronix] Ubuntu 13.10 Desktop Will Not Use XMir By Default
XMir update for Ubuntu 13.10

当初の予定では、今月半ばにリリースされる予定のUbuntu 13.10は、サポートされている環境（主にIntel）では、デフォルトで、X.Orgとは異なる独自の新しいディスプレイサーバーであるMir上に、X.Orgを流用したX互換のXMirを動作させ、さらにその上で、既存のXに依存したウインドウマネージャーやらライブラリやらを実行する予定であった。ただし、まだ問題が多いとして、見送る決定がなされた。

まあ、AMDかnVidiaの吐き気を催すプロプライエタリなバイナリのカタマリを使っている環境では、当初の予定でも依然としてX.Orgなので、大方にはあまり影響がなかっただろうが。

Waylandでは、XWayland（XMirと同じくX.Orgを流用）が、Xに依存するアプリケーションを実行するだけの互換レイヤーであり、たとえできたとしても、その上でディスプレイマネージャーまで実行するほどの愚直な方法はとっていない。

Canonicalは、とにもかくにもMirの実績が欲しいらしく、結果的にすべてをXMir上で実行することになったとしても、Mirを使わせることにやっきになっている。

これをみると、Waylandは正しい設計と実装を慎重に進める方針のように感じられ、一方Canonicalは、なりふりかまわず動くものを早く出したいという方針のように感じられる

WaylandはMirに先行してもう何年も開発され続けている。X.Orgでは限界だと感じる大勢の分野の人間が、協力して正しい設計にしようとしている。GTK+やQtのようなGUIツールキットから、ウインドウマネージャーから、Intelのような自由ソフトウェアに貢献しているGPUベンダーまで、幅広い分野から支援、対応されている。

一方、MirはCanonicalがWaylandの設計の一部を流用して、秘密裏に9ヶ月ほど開発していたものを、急にだしてきて、Waylandにかわってうちはこれを使うといいだした。Canonicalはそれまで、将来的にはWaylandに移行すると発表していたこともあり、この秘密裏で当然の方針転換の発表は、様々な分野の人間の反感をかった。いまは少し落ち着いてきたが、それにしても、GTK+やQtのようなツールキットの対応も、Canonicalが自前で対応しなければならないだろう。

そして、Canonicalは発表するや、すぐにUbuntuで、環境は限定的ながらもデフォルトにするべく無茶苦茶な短期間の予定を設定している。

こう書くと、Waylandこそが未来であり、Mirは勝手に爆死するだろうと思うかもしれない。だが、筆者はどちらが成功するのか、分からないでいる。特にソフトウェア史を振り返ると、主流となったソフトウェアは、とりあえず一般人（=オマエのカーチャン）に動くものを素早く提供したところが多いからだ。いかに問題が多かろうと、オマエのカーチャンでも動かせるものがあるというのはでかい。問題山積みながらも、CanonicalがUbuntuでWaylandに先んじてMirを、オマエのカーチャンでもインストールするだけで動かせる状態にまで持っていけば、Mirが勝ってしまうかもしれないのだ

「論理的、技術的に正しい設計を！　慎重な設計を！　理想の設計を！　絶対に問題が起こらず、将来の拡張性も万全な設計を！」、このように理想を追い求めた結果、広く使われることなく、発展せずに死んでいったソフトウェアは多い。多くの者は、そのソフトウェアの存在すら知らぬ。

動くものがあれば利用者が現れる。実際に利用されなければ分からない問題もある。問題は発見されなければ修正できない。利用者が大勢いれば、別の分野も、対応を迫られる。たとえば、多くのWebサイトは、不自由で規格準拠せず遅い時代遅れのIEに対応しなければならない。IEが最悪なのは明白だが、Webサイトの閲覧者の90%がIEである以上、対応しなければならないのだ。何故ならば、IEは一応は動くわけだし、Windowsのデフォルトだからだ。

幸い、IEのシェア率は、このブログではもはや10%にまで落ちている。これは、FirefoxやChromiumのような、IEより圧倒的に機能面ですぐれたブラウザーがでてきたり、そもそもWindowsのシェアが下がってきているからだ。残念ながら、下がったWindowsのシェアは、自由なOSではなく、iOSや不自由ドライバー満載のAndroidといったOSと、そもそも従来のPCとは少し勝手が違う、スマートフォンやタブレットといったハードウェアの興隆によるものだが、劣ったIEのシェアが下がるのはいいことだ。

しかし、このブラウザーのシェア率は、このブログのような、やや一般とは離れた話題を扱うWebサイトだからこそであり、まだ無知盲目なユーザーの多いWebサイトでは、50%以上がIEだろうと思われる。既存の体制を打破するのは難しいのだ。

筆者の予想では、ディスプレイサーバー戦争は、明確な勝者がいないままダラダラと続くだろう。UbuntuではMir、その他のディストロではWayland、しかし、実際には、どちらも大方のアプリケーションはいまだにX.Orgに依存しているという状態がしばらく続くのではないかと思う。

ストールマンのいう不自由なSaaSSを打ち破る方法について、FreenetやBitTorrentやBitcoinの先例を考える

GNUの30周年にことよせてWired.comoに起稿したストールマンの文章によれば、ストールマンは、SaaSS(Service as a Software Substitute)を不自由なソフトウェアと同等に、利用者の自由を奪う危険な存在であると考えているそうだ。

Why Free Software Is More Important Now Than Ever Before | Wired Opinion | Wired.com

SaaSSは、もはや空気のようなものだ。どこにでもある。そもそも、このブログというサービスを提供しているBloggerだって、SaaSSだ。Twitterもそうだ。Googleのような検索サイトもそうだ。メールだって、大抵の人間は、自分の支配力はほとんど及ばないメールサーバーに依存している。今や、お金のやり取りだって、ネットワークと他人のサーバーに依存して行なっているではないか。自分の所有せず、また支配力の及ばない、ネットワーク越しのサーバーに依存したサービスは、すべてSaaSSといえる。これらのサービスは、利用者ではなく、サーバーの管理者に、不公平で一方的な権力を与えている。サーバーの管理者は、利用者を監視し、検閲し、攻撃することができる。インターネット越しに他人の所有するサーバーを介して提供されるほぼすべてのサービスは、SaaSSだ。

ではどうするのか、gnu.orgや、fsf.orgや、stallman.orgですら、利用者の自由を尊重しない不自由なSaaSSなのか。彼らの文章は自由かもしれない。彼らが提供するソフトウェア(JavaScript)は自由かもしれない。サーバーは自由なOSと、その上で動く自由なソフトウェアで構成されているのかもしれない。事によれば、サーバーのソフトウェア群や設定ファイルすら（秘密鍵などのごく一部を除き）、提供されているかもしれない。しかし、サーバーは、物理的なハードウェアであるサーバーは、利用者の自由にはならない。

ストールマンは、セキュリティに関して独特な意見を持っていた。もちろん、時代の変わった今日でも、まだその意見を維持しているかどうかはわからないが、基本的には、あまり変わっていないのではないかと思う。

On Hacking - Richard Stallman

ストールマンは、ハッキングが好きだった。ハッキングというのは、例えばある問題を解くのに、既知の最小プログラムは6個のインストラクションからなるプログラムであったところを、5個に削減するとか、数値をローマ数字で表示するとか、英語という自然言語で書かれた質問の意味を理解するプログラムなどだ。ハッキングとは、既存の制約を打ち破る行為である。

コンピューターにセキュリティの概念が持ち込まれ、ユーザーごとに権限が付加され、独裁的なコンピューターの管理者と、それ以外の奴隷のごとき一般ユーザーに分けられ、また正しく認証された人間やプログラムでなければ、コンピューターを使えないようにするということが、行われるようになってきた。

すでに述べたように、ハッキングとは、既存の制約を打ち破る行為である。とすると、セキュリティによる制約を打ち破るのが、ハッカーの格好の遊び場になるのは当然のことだろう。

ストールマンは、セキュリティなど元から相手にしなかった。セキュリティなどというものがあるから、セキュリティを打ち破ることに、貴重なハッキング能力が浪費されてしまうのだ。セキュリティなどなければ、もっと別の有益な制約を打ち破ること、たとえば、プログラムで自然言語の理解するだとか、計算量が爆発的に増大する問題を十分に信頼可能な高い精度で解くヒューリスティックな手法などといった、本物の価値あるハッキングに、ハッカーの労力が費やされる。セキュリティなど無価値だ。

ストールマンも開発に関わったITS(Incompatible Timesharing System)というOSでは、セキュリティに関して、独特の思想を持っていた。というより、現代でいうところのセキュリティはなかったのだ。

セキュリティなどというものがあるから、打ち破りたくなるのだ。ユーザーごとに異なる不公平な権限が付与されているからこそ、打ち破りたくなるのだ。ITSにはユーザーという概念はあったが、あくまでコンピューターの利用者を識別する程度の意味でしかなかった。あらゆるユーザーは、別のユーザーの端末を覗きこむことができた。ただ、ユーザーの方でも、別のユーザーに除かれているという事がわかる仕組みだった。初期のITSにはログイン時のパスワードすらなかった。ファイルをユーザーが所有するという概念がなく、OSを構成するものも含む、システムのあらゆるファイルは、全ユーザーによりいつでも書き換え可能だった。これにより、ユーザーごとに異なる権限の制約を打ち破るハッキングへの魅力がなくなり、ハッカーはもっと価値のあるハッキング、例えば自然言語の解釈や過労死寸前のセールスマンの訪問ルートを決定する問題などに、労力に集中できた。

OSやハードウェアの欠陥を探して、システムをクラッシュさせるというのも、ハッキングにおける興味の対象のひとつだった。これも、ハッカーの興味を、本当に価値のあるハッキングから、目的と手段を混同したような意味のないハッキングへの労力の浪費を促した。そこで、ITSでは、画期的な方法により、利益のないハッキング対象からハッカーの興味をそいだ。ITSでは、全ユーザーに、いつでもシステムをクラッシュできる方法が提供されていた。これにより、システムをクラッシュさせるといった程度のつまらないハッキングへの興味をそぎ、もっと有益なハッキングに意識を集中させることができた。

しかし、時代は変わった。ストールマンとて、gnu.orgや、fsf.orgや、stallman.orgの内容が、誰の手によっても自由に書き換え可能になって欲しくはないだろう。このようなWebサイトで公開されている文章の複製物が改変されるのはともかく、このWebサイト上の文章そのものは、改変されてほしくないはずだ。これは、つまりサーバーに不公平な権力を与えていることになる。

ある情報が改変されていないかどうかを高い確率で保証するだけなら、ハッシュ関数や、ハッシュ関数と公開鍵暗号を併用した署名により、実現可能だ。だから、複製物が改変版であるかどうかを見分けるのは容易い。しかし、サーバーという物理的存在を自由にするのは難しい。

ましてや、いまだに我々の計算力やストレージ容量やネットワーク帯域は貧弱なので、個人の支配できるコンピューターやネットワークで、大規模なサーバーを置き換えるのは難しい。Googleのような検索を実現するには、ハードウェアの能力が圧倒的に足りない。メールも、メールサーバーを常に稼働させておかなければならないし、優秀なスパムフィルターや、高速なメールの検索が難しい。httpサーバーも難しい。何もかもが難しい。一体どうすればいいのか。

非中央管理ネットワーク

現状の多くのSaaSSの問題が、サーバーという中央管理された少数の権威と、その権威に依存する権力を持たない多数のクライアントという、中央管理ネットワークという仕組みそのものから発生する問題である。では、この中央管理の権力を排除してしまえばいいのではないか。

非中央管理ネットワーク、分散ネットワーク、あるいは俗にPeer-To-Peer(P2P)などと呼ばれている一連の技術が、中央管理する権力の排除を可能にする。

これらのネットワークでは、すべての参加者が、公平である。すべての参加者（ノード）は、従来の中央管理ネットワークでいう、サーバーでもあり、クライアントでもあるのだ。

まず、中央管理ネットワークにおける、ブログへのアクセスを考えよう。あるクライアントが、あるブログを見たいとする。クライアントはブログの住所を入力し、住所に対応するサーバーからブログを構成する情報を受け取る。

非中央管理ネットワークではどうなるのか。すべての参加者は、周囲の少数の参加者とお互いに接続して、メッシュ状のネットワークを構築する。ブログを見たい参加者は、周囲の参加者に、ブログの住所を伝える。周囲の参加者が、その住所に対応する情報を持っていた場合、ブログを見たい参加者に情報を返す。持っていない場合、さらに周囲の参加者に、ある参加者がある住所の情報を欲していると伝える。このような伝言ゲームのような伝達の広がりにより、最終的に、目的の情報を持っている参加者にまで要求が届き、最初のブログを見たい参加者に情報が送信される（直接にせよ、間に別の参加者を挟むにせよ）。

中央管理ネットワークでは、悪意ある者は、サーバーさえ抑えてしまえば、そのサーバーという権威に依存するクライアントに対して、監視検閲攻撃と何でも一方的にやりたい放題だ。非中央管理ネットワークでは、すべての参加者は等しいので、少数の抑えるべき権威が存在しない。悪意ある者も参加者の一人になるにすぎない。非中央管理ネットワークは、ネットワークを構成する参加者のうちの少数が悪意ある者であったとしても、不公平な権力の差が発生しないように設計されている。たとえブログを検閲するために一部の参加者を抑えたとしても、すでにブログを構成する情報の複製物がネットワークにより保存され、検閲は失敗する。

たとえ一旦は、全ノードを侵略したとしても、我々が自由の精神を放擲せず、汎用コンピューターが存在する限り、非中央管理ネットワークは再び立ち上げることができる。ただし最近、ゲーム用コンソールやiPhoneやAndroidなどの悪の勢力の興隆により、汎用コンピューターを使う人間が減りつつあるのは心配だ。これらの制限コンピューターは、利用者所有者の自由を認めず、ハードウェアの製造者に、利用者に対して一方的な権力を振るえるように設計されている、極めて邪悪で非人道的な制限コンピューターである。我々はこのような制限コンピューターを使ってはならないことはもちろんである。

もちろん、共通の悪意ある者が参加者の大半を占めるような場合はどうにもならない。ただし、ネットワーク全体に比して影響力のあるほどのコンピューター資源を用意しなければならない。

非中央管理ネットワークでは、コンピューター資源の強い存在は正義なのだ。

非中央管理ネットワークは、単なる机上の空論ではない。すでに多くのネットワークが設計され、実装され、実際に使われている。ここからは、そのような先例をいくつか考察しよう。

Freenet

The Freenet Project - /index
Freenet - Wikipedia, the free encyclopedia

Freenetは、インターネット上に非中央管理ネットワークを実装し、汎用的な通信を実現している。ただし、高級なアプリケーションを記述するためのAPIとしては、独自のものが使わているため、既存のTCPやUDPを使うアプリケーションは流用できない。Freenetでは、ユーザーへのUIとして、ローカルhttpサーバーとして動作し、独自APIで実装した機能へのUIを、HTML/CSS/JavaScriptで提供しているため、通常のブラウザーから利用することができる。

Freenetは、実際に使われている。Webページやフォーラムやチャットやファイル共有といった一通りの機能が実装され、UIはローカルhttpサーバーからブラウザー経由で提供されるため、使い勝手も悪くない。問題は、非効率的だという事だ。

たとえばこのブログを実現するためのサーバーは、Bloggerが提供している。筆者が文章をアップロードすると、ほぼ一瞬で反映され、全世界から閲覧できる。Freenetはどうか。筆者が全世界に公開したい文章は、周りのノードによって複製されていく。他人が筆者の文章を読みたい場合、筆者のノードか、文章の複製を保有している他のノードから受け取ることになる。他のノードによって複製され続ければ、たとえ筆者のノードが表現の自由を憎む抑圧者によってオフラインにされたとしても、筆者の文章は、他のノードが複製する価値を認めれば、依然としてFreenet上に生き残ることになる。

問題は、これがとても非効率的だという事だ。このBloggerでは数秒もかからない全世界への文章の公開が、Freenetとなると、コンピューター資源次第だが、何時間もかかることすらある。チャットのリアルタイム性は損なわれる。ファイル共有はとてつもなく遅い。

結果として、そのような非効率的な非中央管理ネットワークは、多くの利用者を得られない。なぜならば、その土台であるインターネットを直接使ったほうが、たしかに検閲されているとはいえ、はるかに便利だからだ。どんなに机上では素晴らしい技術も、利便性が悪ければ使われない。非中央管理ネットワークにとっては、悪意ある一部のノードの企みを防ぐためにも、多くの利用者が存在しなければならないのに、その利用者が得られない。結果として、Freenetは、あまり一般的ではない。一般的の定義は、オマエのカーチャンでも使っているという事だ。

中央管理ネットワークであるインターネット上に、非中央管理ネットワークを実装する試みは、Freenetだけではなく、実に多く考案され、そして実際に実装されてきた。いちいち挙げるとキリがない。たとえば、GNU傘下のプロジェクト、GNUnet | GNU's Framework for Secure Peer-to-Peer Networkingもそうだ。しかし、こちらは、Freenetよりもさらに利用者が少ない。

このような非中央管理ネットワークの問題は、実装が難しいとか、実装に労力がかかるというものではない。それは根本的な問題からすれば枝葉でしかない。根本的な問題は、十分に利用者を集めることの困難性だ。

では、汎用性を求めず、特定の機能だけに特化した、非中央管理ネットワークはどうだろうか。

分野特化の非中央管理ネットワーク

まだP2Pという略語がなく、Peer-To-Peerという言葉自体も、一般人（=オマエのカーチャン）は知らなかった時代、ゲームはP2P通信を使っていた。FPSゲームは、早くからオンライン対戦に対応していた。当時のオンラインFPSでは、数人から数十人のプレイヤーが集まって対戦ゲームをしていた。その際、通信はプレイヤーそれぞれが、同じゲームに参加するすべてのプレイヤーに送信していた。

もちろん、これはあまりにも限定的すぎる。しかし、一旦中央管理のサーバーを経由しない、参加者それぞれが独立して情報をやり取りするという仕組みは、何も最近始まったものではない。P2Pという略語を有名にした分野に、ファイル共有がある。

ファイルとは、でかい情報の塊である。ビット列である。ファイルをファイルのまま、他人と共有したいという需要は当然のものだ。ブログが文章を共有するように、Twitterが140文字を共有するように、ファイルを共有したいのだ。非中央管理ネットワークで実装されたファイル共有システムは、その悪用可能性だけが注目されるが、情報の共有は、自然なことだ。

従来の中央管理ネットワークでファイル共有を実現するには、共有したいファイルを持っているものが、ビット列で表現された情報の塊であるファイルをサーバーにアップロードし、しかる後に、共有されたファイルを求める者が、サーバーに問い合わせて、ファイルをダウンロードする。中央の権威であるサーバーは、ファイルを保存し、送信者と受信者を管理する。ここに、サーバーの一方的な権力が発生する。しかも、サーバーには、多大な計算力、ストレージ容量、ネットワーク帯域が要求される。とても非効率的である。

この非効率性は、ファイルの送信者と受信者が、直接にやり取りをすれば低減できる。サーバーは、ファイルの情報と、ファイル所有者と、ファイルを求めている者という、少ない情報量だけ管理すればいい。これはサーバーに必要な計算力、ストレージ容量、ネットワーク帯域を低減する。

Napsterは、このような発想から生まれた。

しかし、まだこれでは、ファイル共有機能は、サーバーという中央権威に依存している。完全に非中央管理ネットワークにするには、Freenetのように、すべての管理を個々のネットワークの参加者が行わなければならない。しかし、ファイル共有を実現するだけであれば、Freenetのように汎用的な設計である必要はない。ファイル共有にだけ特化したプロトコルは、ファイル共有に対しては、より効率的に機能する。

Winnyで使われているプロトコルをはじめとする、実に多くの非互換のファイル共有用のプロトコルは、インターネット上に、ファイル共有に特化した非中央管理ネットワークを構築している。

非中央管理ネットワークによるファイル共有は、中央管理ネットワークよりも効率的であった。たしかに、全体で見れば、ネットワーク帯域がより多く発生するのだが、強い計算力、ストレージ容量、ネットワーク帯域を持つ、中央管理用のサーバーを用意しなくてもいいという点で、圧倒的に、個人には負担が少なかった。しかも、もし欲しいファイルを複数の参加者が持っていた場合、複数の参加者からファイルの別々の箇所を同時にダウンロードできるといった利点もあった。中央管理のサーバーは、そのサーバーのネットワーク帯域に制限されるが、すべての参加者が協調するネットワークでは、そのようなボトルネックが存在しないのだ。

数ある非中央管理ネットワークプロトコルの中でも、特に成功したのが、BitTorrentだ。

BitTorrent

BitTorrent - Wikipedia, the free encyclopedia

BitTorrentプロトコルは、当初、完全な非中央管理ネットワークではなかった。また、匿名性については、昔も今も、それほどは考慮されていない。ピアとよばれるネットワークの参加者の情報はトラッカーと呼ばれるサーバーで管理しなければならなかったし、ファイル情報は.torrentファイルとして配布しなければならなかった。しかし、BitTorrentプロトコルは、面白いことに、プロトコル仕様が公開され、独立した実装がいくつも作られ、どんどん改良されていった。他のファイル共有用の非中央管理ネットワークにはみられなかった傾向だ。他のファイル共有プロトコルは、プロトコル仕様が公開されず、仕様の考案者が提供する実装が唯一の実装であることが多かったのだ。

仕様が公開されていて、独立した実装が作れること、匿名性ではなく、効率を重視したこと。最初はノードやファイル上の管理を別に行った手軽さなどが、BitTorrentの成功の秘訣だろう。

そうして、当初はNapsterのようにハイブリッドだったBitTorrentプロトコルは、完全な非中央管理ネットワークを実現するプロトコルへの機能を拡張していった。参加者であるピア情報は、トラッカーとよばれる中央管理のサーバーに依存しない方法でも得られるようになった（DHTとローカルピア交換）。ファイル情報は、.torrentファイルのハッシュ値だけになり、ファイル情報を格納する.torrentファイルは、他の参加者から、ハッシュ値をもとに得るようになった。これにより、BitTorrentは完全に非中央管理ネットワークとして機能するようになった。しかも、中央管理ネットワークとしての機能も残している。

このような特徴により、BitTorrentプロトコルは、純粋なファイル共有以外の目的でも使われるようになった。

たとえば、いくつかの不自由なゲームは、アップデートパッチの配布にBitTorrentプロトコルを用いている。.torrentファイルへのハッシュ値さえ信頼できる方法で知らせれば、悪意ある参加者による、悪意あるコードへの差し替えも防ぐことができる。

あるデータセンターでは、大量のサーバーのソフトウェア更新に、BitTorrentプロトコルを用いている。これにより、中央の一箇所へのアクセス集中を避けることができる。

もちろん、依然としてファイルのような巨大な情報の塊をやり取りするのは変わっていないのだが、その使われかたは、単純なファイル共有よりは、少し別の目的にも使われるようになってきたのだ。

たとえば、動画をストリーミング再生するのに、BitTorrentプロトコルを使う実装がでてきた。

あるいは、BitTorrentプロトコルを使い、オンラインストレージを、参加者達がお互いにファイルを保存しあう、分散型の実装もでてきた。ファイルは暗号化するので、他人に自分のデータを読まれる心配はない。この実装は、BitTorrent Syncという名前の不自由なソフトウェアで、BitTorrentの原案者の起こした会社のプロプライエタリな製品である。

自由ソフトウェア財団は、BitTorrent Syncに自由なソフトウェアによる実装が存在するべきだと考え、高優先度自由ソフトウェアプロジェクトに指定して、開発者を募っている。

High Priority Free Software Projects — Free Software Foundation — working together for free software

更に良くわからないのは、最近BitTorrent社によって発表された、BitTorrent Chatだ。

Now in Labs: Building Secure, Server-less Messaging With BitTorrent Chat | The Official BitTorrent Blog
BitTorrent Labs - BitTorrent Chat

このソフトウェアは、名前通り、チャットなどの対話機能を提供するようだ。最近のNSAの邪悪な試みがリークされたのを受けてのことだろう。実際にBitTorrentプロトコルを利用しているのか、あるいは単にBitTorrentというブランド名を使っただけなのかは分からない。曰く、監視検閲を防ぐとしているが、不自由ソフトウェアであるので、一切信用してはならない。その実装を検証できない不自由ソフトウェアで、セキュアだとか安心を実現できるわけがないのだ。

もともと分野特化の非中央管理ネットワークが、一般的に使われるようになるにつれ、より汎用的な機能を提供できるように、どんどん改良されていくのは興味深いことだ。最初から汎用性を求めたFreenetやGNUnetは、利用者が増えず、結果として改良速度が遅く、あまり使われていない。BitTorrentは使われている。

似たようなことは、ソフトウェア史で何度も起こっている。例えば、HTMLは当初、Webページを記述するために作られたフォーマットだった。JavaScriptは、Webページにちょっとしたエフェクトを付け加える程度の簡易的なプログラミング言語だった。それが、HTMLは今や、Webページの構造や意味を記述するためのフォーマットとなり、HTMLに従来付随していた表現方法は、CSSといった形で分離され、JavaScriptは本物のプログラムを書くためのプログラミング言語として使われている。

HTMLもJavaScriptも、技術的に最高の設計ではない。HTMLのパースには寛容でハックの塊のような汚いパーサーが必要だし、JavaScriptは元から高速な実行を念頭に設計されていなかったので、全世界から指折りの才能あるプログラマーをかき集めて、とてつもない労力をかけて、相当にパフォーマンスのいいJavaScriptの実装を作り上げている。もし、我々がもっと文法的に厳格な言語や、実行時パフォーマンスのよい言語を設計して使っていれば・・・と思いたくなるが、いまさらどうしようもない。もし、そのような、技術的にはすばらしいフォーマットや言語を当時作ったとしても、広く受け入れられなかっただろう。寛容で文法違反を許すHTMLだからこそ広まったのだし、とりあえず手軽（全然手軽ではないのだが）に書けるJavaScriptだからこそ、広まったのだ。そして改良され、技術的には劣るところもありながらも、力技で、なんとかまともに使えるようになっている。

ソフトウェア史は、そういう技術ばかりだ。BitTorrentも、そのような広く一般に使われるようになったがために、より改良されるという正のスパイラルに、うまくハマった技術なのだ。技術的に優れていても、利用されにくい技術は、発展しづらいのだ。

最後に、もうひとつだけ、そのような利用されやすい設計のために、広く使われるようになった技術を紹介しよう。Bitcoinだ。

Bitcoin

Bitcoin - Wikipedia, the free encyclopedia

Bitcoinとは、非中央管理ネットワークで実装された貨幣である。

貨幣が貨幣であるためには、信頼されなければならない。2013年10月1日現在、日本人は日本円を信頼している。日本中どこに言っても、金銭のやり取りは日本円で行われている。逆に米ドルのような貨幣は、日本では、観光客向けなどのごく一部の場所でしか通用しない。これは、実はかなり珍しいことなのだ。多くの国では、自国民は自国の貨幣をそれほど信用しておらず、米ドルのような他国の貨幣をより信頼したり、国際的な為替の交換率よりも多くの自国貨幣と米ドルを交換したりする。日本では、日本円と米ドルとの交換に、手数料を取るというのに、一部の国では逆に自国貨幣を多く払うという現象まで起きている。これは、自国貨幣に十分な信頼がないがためである。

従来、この貨幣の信用は、金や銀といった偽造困難な貴金属が用いられてきた。貨幣は一定の交換率で、額面の数字の価値に等しい重さの金と交換できる、といった具合だ。そして、国家政府のような貨幣の発行者は、信頼を実行で示すために、いつでも金と交換できるように、大量の金を保有していた。

いろいろあって、今では、貨幣の信頼に、貴金属との交換は使われなくなっている。強力な権力を持つ国家政府という存在そのものが、貨幣の価値を保証するのだ。貨幣は国が責任持って製造し、偽造困難にし、価値を保証する。貨幣の価値は、国家の信頼に依存している。2013年10月1日現在、日本人は日本国を十分に信用しているため、日本全国どこに言っても、金銭のやり取りには日本円を使うことができる。

しかし、残念ながら、貨幣は中央の権威によって管理されている。物理的な現金はまだしも、ネットワーク上で日本円のやり取りは、監視され、検閲される。それが犯罪を防ぐ目的であったとしても、犯罪の定義も、結局は貨幣を管理するのと同じ、国家によって決定されるため、ふさわしくない。

しかし、貨幣はどうやって非中央管理ネットワークで実装すればいいのだろうか。中央で管理する者がいなければ、誰もかもが大金を持っていると主張するだろうし、そんな貨幣に信頼は生まれない。

3年前、Satoshi Nakamotoと名乗る自称日本人が、偽造困難な非中央管理ネットワークで実装された貨幣の設計を公開し、続いて実装を公開した。Bitcoinである。

Bitcoinは、既存の暗号技術、特にハッシュ関数と公開鍵暗号によるデジタル署名により、偽造不可能な金銭のやり取りの積み重ねを作り上げた。Bitcoinを得たり、Bitcoinをやり取りするには、結構な計算力が必要になる。Bitcoinを偽造したり、Bitcoinのやり取りを偽造したりするには、今までにかかった計算力よりさらに高い計算力が必要になる。あるいは、一般的に使われている既存の暗号技術の脆弱性を突くしかない。

Bitcoinは、偽造防止に、計算力を使った。Bitcoinの得たりやり取りしたりするには計算力が必要で、偽造にはそれを上回る計算力が必要となる。したがって、悪意あるものがBitcoinを攻撃したい場合、あるBitcoinの生成とやり取りに費やされたそれまでの計算力より大きな計算力を注ぎ込まなければならない。そのような計算力は、とても膨大なものになる。

計算力の高い奴は正義なのだ。Bitcoinを得るのに計算力が必要なこと、Bitcoinを偽造するのにはさらに計算力が必要なことは、既存の暗号技術に保証されているのだ。

Bitcoinを管理する中央の権威は存在しない。そのため、1 Bitcoinがどの程度の価値を持つかは、人それぞれである。なにしろ、中央銀行は存在せず、従って価値を一定に保つための努力もしようがないのだから。ただし、偽造できず、中央管理できないという貨幣は、それ自体が信用となる。信用さえあれば、貨幣は通用する。信用さえあれば、他の信用ある貨幣である、米ドルや日本円と交換できる。Bitcoinはその信用と期待から、現実の貨幣と交換したいと思う者が大勢いるので、現実の貨幣と交換できる。ただし、その交換レートは人によりまちまちで、不安定なのだが。Bitcoinは利用者が大勢いるので、さらに人をひきつけている。

しかし、Bitcoinは何故流行ったのか。いくら偽造できず中央管理する権威が存在しないからといって、それだけの信用で、今のように大勢の者がBitcoinに関わるようにはならない。実は、Bitcoinの設計には、とても興味深い、社会学的な仕掛けが施されていたのだ。

Bitcoinを得るには、設計上、計算が必要になる。Bitcoinの総量は、2100万（単位はBitcoin）になるように設計されている。Bitcoinは、その設計上、当初は、さほど計算力を必要とせずに、多くのBitcoinを得られるが、Bitcoinが割り当てられるにつれ、残りの未割り当てのBitcoinを得るために必要な計算力が上がっていく。つまり、早く参入して計算すれば、簡単に多くのBitcoinを得られるという、アーリーアダプター優遇の設計になっているのだ。急げ急げ、早くしないと乗り遅れるぞ、の心境だ。

これにより、ゴールドラッシュならぬBitcoinラッシュが発生した。Bitcoinを生成するための計算は、文字通り、「Bitcoinを掘る」と呼ばれ、Bitcoinを得る競争が白熱した。極端な並列化実行を実現できるGPUを使い、また専用に回路を設計したFPGAを使い、Bitcoinを掘るのには、途方もない必要な計算力がつぎ込まれた。そのため、一時期GPUの需要にすら影響を及ぼした。

Bitcoinを得る理由は様々だ。実際に貨幣として使うものもいる。特に、その匿名性や中央管理する権威がいないことから、非合法なブツのやり取りにも使われているようだ。また、自国の貨幣の信用が落ちてきている国でも、Bitcoinは注目され始めている。アメリカ合衆国では、広告を見て得られる一日数十セント相当の価値のBitcoinを糧に生活しているホームレスがいるそうだ。単に数値が上がっていくのを眺めるのが楽しいという人間もいる。新しい面白そうな技術は、たとえ現実的な利益がないにしても、手を出してみる人間もいる。目的は様々だが、Bitcoinは多くの人間の心理を惹きつけ、大勢をネットワークに参加させることに成功した。もちろん設計も公開されていたので、Satoshi Nakamotoの実装によらない、独立した実装も多数出てきた。この事情はBitTorrentとよく似ている。

大勢がネットワークに参加したのだから、Bitcoinには価値が生まれる。現物やサービスとBitcoinのやり取りが行われる。Bitcoinと現実の通貨と交換するところが出てくる。Bitcoinは、十分な利用者を集めるという、非中央管理ネットワークや貨幣の成功にとって、とても重要なことを、人の心理を利用して、うまくやりぬいたのだ。一度、十分な利用者を集めてしまえば、それ自体に価値が生まれるのだ。

まとめ

以上、この記事では、SaaSSを打ち破るための、非中央管理ネットワークで実装された同等品の先例をみてきた。ここで上げた先例は、実際に存在していて、実装されていて、実際に使われている。オマエのカーチャンが使うほど一般的ではないかもしれないにせよ、だ。

我々は、文章などの公開の目的でのWebページや、フォラームやチャット、音声や動画のような巨大なファイルにも対応したファイル共有、ついには貨幣まで、非中央管理ネットワークで実装してきた。いずれも中央管理ネットワークによる実装を完全に置き換えるとまでは言わないものの、SaaSSのような中央管理ネットワーク実装では実現できない利点もある。その利点により、あるいは、将来、既存のSaaSSを打ち破るかもしれない

我々は自由を決して放擲してはならないのだ。自由は人間が等しく持つ天から与えられた権利なのだ。自由のない世界では、人間は監視され、検閲され、迫害され、監禁、拷問され、そして人知れずベイポライズ（消去）されてしまう。

ハッピーハッキング