2018-12-08

経済学上最適な行動は時として奇妙に見えるという話

極めて興味深い、経済学上合理的で最適な戦略は、時として奇妙に見える。例えば以下の例だ。

Amazonから注文もしていない商品が届き続けた件 | ハーバービジネスオンライン

まとめると以下のようになる。

アマゾンから注文していない雑多な商品が届くようになった。クレジットカードの不正利用ではないし、アマゾンの購入履歴にも存在しない。泥酔したり精神に不調をきたして記憶を失う習慣もない。そもそも自分から購入したいと思うものではない。一度だけ送り状が入っていたので、ギフトであることが判明した。しかしそのようなギフトを送る知人に心当たりはない。アマゾンに問い合わせたところ、ギフトであろうとの回答が来た。ギフトの送り主の個人情報は開示できないとのことであった。

商品の中に、以前マーケットプレイスで注文した商品によく似た商品が混ざっていることに気がついた。もしかしたら、以前利用したマーケットプレイスの出品者が送りつけているのかも知れない。しかしそれは、自分の出品を自分で購入していることになる。自分から自分にカネを動かしているのだから損はないかもしれないが、アマゾンの手数料と諸経費そして発送料の分は損をしている。なぜなのか。

ここでいくつか仮説が述べられている。見かけ上の売上を上げることによりアマゾンのランキング工作をしたいという可能性もあるが、一番合理的で納得の行く説は、商品の廃棄だ。

アマゾンのマーケットプレイスではアマゾンの倉庫に商品を保管できる。これには定期的な保管料がかかる。そのため、しばらく売れない商品は破棄し、これ以上保管料による損失がかからないようにする。これは合理的だ。保管を維持して商品本体の売上よりも保管料が高くなるのであれば、商品自体を破棄したほうがよい。

商品の破棄方法としては、自分自身へ返送して自分で廃棄する方法と、所有権の放棄してアマゾンに廃棄してもらう方法がある。しかしこれはどちらもコストがかかる。

自分自身へ返送する場合は、アマゾンに支払う返送料と宅配業者の送料がかかるほか、受け取りにコストがかかり、さらに何らかの方法で廃棄しなければならない。

所有権を放棄してアマゾンに廃棄してもらう方法もあるのだが、こちらも料金がかかる。

自分で自分の出品を購入して誰かにギフトとして送りつける場合、自分で自分に代金を支払うので、代金の大部分は自分に帰ってくる。かかるコストはアマゾンの手数料とギフトの送り先への送料だが、これが廃棄のコストを下回る場合、廃棄するよりギフトとして誰かに送りつけたほうが結果的に安くなる。

ではどこにギフトとして送りつけるかだが、すでに自分から商品を購入した人の住所に送りつけるのがよい。

これは違法だろうか。ギフトを送りつけられたことによって損害を被った場合は民事訴訟を起こすことができるだろうが、大抵の商品は損害額が小さすぎるために訴訟をする価値がない。まずアマゾンに個人情報の開示申立の裁判をし、その後にギフトの送り主と裁判をすることになるが、これだけで100万円単位の訴訟費用がかかるし、総額2万円ぐらいのゴミ箱やらシャツやらプロジェクターといった雑多で安価な商品を送りつけられたことによる損害に対する補償を求めるにはあまりにもコストがかかりすぎるので、訴えられる心配はまずない。実際、リンク先の記事の筆者も認める通り、このギフトによる実害は発生していない。

経済学とは不思議だ。インセンティブに従い、極めて合理的で最適な戦略を取った結果が、ハタから見ると奇妙に思える。

2018-12-03

三十路を超えたので体について考える

三十路を超えてからというもの、自分の体の無視できぬ変化について意識せずにはいられなくなった。

私は明らかに10年前より顔が変わった。10年前も、5年前より顔が変わったと思っていたのだが、その頃に思っていたよりもさらに顔が変わっている。

嬉しい変化としてはヒゲが伸びるようになったことがある。20代の頃、私は口ひげは数cmほど伸びるものの、あごひげはまばらにしか生えない体質だった。ヒゲを伸ばしたとは思っていたものの、あごひげは伸ばしてもみっともないので剃っていた。今、あごひげも少し伸びるようになってきた。それも、下唇の下は中心から一本の線を描くように伸び、両側は伸びないという生え方をしているので、気に入っている。

一番の懸念事項としては、体重が増え続けているということだ。これはよくわからない。というのも、それほど食べてはいないはずなのだ。特に最近は1日一食程度にまで食べる量を減らしているのだが、体重は減らないどころか増えていく。私は酒を飲む習慣はないし、したがって酒のつまみも食べない。ラーメンも食べない。野菜は好きな方だ。なぜこんなにも体重が増えていくのだろうか。

運動はしている。毎週ボルダリングをしているし、ジョギングもしている。ボルダリングによって筋肉量は数年前より相当上がっている実感があるのだが、体重も増えているために最近はボルダリングの腕も落ちている。ジョギングも10kmぐらい走れるのだが、特に体重の減少にはつながっているように思えない。

視力も落ちてきている。普段はメガネをしているので気が付きにくいのだが、数年に一度メガネを買い換える際に、常に度を一段階上げる必要があることに気がつくのだ。

とはいえ、まだ私は恵まれている方だろう。自覚できる肉体の変化で健康的に悪いことといえば、体重の増加と視力の低下ぐらいなのだから。今のところ、大した病気にはかかっていないし、精神的に不安定でもなく、認知能力の低下もない。

認知能力の低下というのは最近特に意識する問題だ。というのも、私の父親は明らかに認知能力が低下しているからだ。今の父親にとって、世上のあらゆる問題は中国人が原因だということになっている。風が吹けば桶屋が儲かる程度の理屈もなく、あらゆる問題は中国人のせいであるらしい。私の知っているかつての父親はそういう人間ではなかった。なので、上京して以来数年ぶりに帰郷して目の当たりにした父親の激変ぶりに戸惑っている。

父親の年齢はちょうど還暦を迎えた60歳。まだ60歳でしかないのだ。

思えば思い当たる節はある。父親は50歳ぐらいの頃、急に勤め先を退職したいと言い出した。母親は定年まで勤め上げれば給料や退職金がだいぶ違ってくるのでもったいないと言ったが、父親はもう能力的に働けないと主張していた。

[削除済み]

父親を見ると私の将来について一抹の不安を覚える。私も知的能力が必要とされる仕事をしているが、果たしていつまで知的能力は維持できるのだろうか。現在、私の知的能力に自覚できる低下はない。それどころか、英語の読解力は過去最高に上がっている。父親が50歳を超えて自身の知的能力の低下に気がついたのだとしたら、私には20年弱の時間しか残されていないことになる。

2018-11-25

Vimconf 2018のスタッフをしてきた

VimconfとはテキストエディターVimに関する発表をするカンファレンスだ。国際カンファレンスを意識し、発表の多くは英語で行われている。今年は他ならぬVimの作者であるBram Moolenaar本人を招待している。

去年のVimconf 2017には、雇用主のドワンゴがスポンサーをしていたので、スポンサーチケットで参加をした。

今年のVimconf 2018もドワンゴはスポンサーをしていたが、去年は私がスポンサーチケットを使ったので遠慮をして今年は別の同僚に譲った。自腹で行こうかと思ったが、チケット販売サイトはクレジットカードからの入金しか受け付けなかったので、購入を断念した。

残念、今年は参加できないか、と思っていたところ、運営スタッフから人手不足で当日のスタッフが足りないので来てくれと言われ、急遽スタッフとして受付のチケットもぎりをすることになったので、結果的に今年も参加することになった。他の運営スタッフとは違い、当日の、それも開場後前後の1,2時間程度しかスタッフらしいことはしなかったのだが、立派なスタッフ面をいて開場直後以外の発表はバックヤードから聞いていた。

Vimconfは国際カンファレンスを意識して基本的に英語で司会、発表が行われるのだが、無線イヤホン経由の英語と日本語の通訳がついている。去年のVimconf 2017ではプロの通訳ではない運営スタッフの一人が通訳を担当した。プロではないので、通訳内容はだいぶアレでソレであったと聞いている。

今回はなんとプロの通訳を手配したという。私は英語のリスニングができるので通訳の品質を確かめてくれと言われてイヤホンを聞いてみたのだが、さすがはプロだ。流暢な英語が流れてくる。英語は自然で発表内容とあっているように思われるが、本当に発表者の発言と一致しているかという検証は難しかった。というのも発表者の日本語と通訳の英語を同時に聞くのは困難だからだ。驚異的なことに、発表者の発話する日本語に対応して流れる英語の遅延が少ない。あらかじめ発表内容の台本を渡されてそれを翻訳して読み上げているのだろうかと思うぐらい遅延が少ない。さすがはプロの通訳だ。

発表はmattnさんから始まった。VimからTCP/IPのlistenできるようにするという機能の実装で、VimがNUL文字を扱えるようにBLOB型を追加するという内容だった。

いよいよBram Moolenaar本人が発表する番になった。Bram Moolenaarはあまり表に出てこない人だ。Vimconf 2018以前にBram Moolenaarに直接対面したことのある日本人は数えるほどしかいないはずだ。インターネット上でBram Moolenaarを検索すると決まって出てくる、あの有名な酒瓶を掲げたBram画像は11年前の2007年のもので、現在の本人は11年分の齢を重ねた姿になっていた。

Bram Moolenaarの発表はVimの歴史を軽く紹介したほかは、Vimが現在取り組んでいる新機能の現状についての説明があった。Vimscriptが遅いのでパース済みの中間表現を保持することで高速化するアイディアや、Vimscriptのスレッドによる並列読み込みといったアイディアが説明された。そしてプラグインの話になった。最初のプラグイン機構は単一のディレクトリにvimscriptを放り込むものであったが、最近はプラグインごとに独立したディレクトリを持つことができるようになり、だいぶ楽になった。プラグインの例として、なんとあのShougoさんのプラグインが言及され、開場からは驚きの声が上がっていた。思えば遠くまで来たものだ。その後、プラグイン間で共通のライブラリを使いたいという至極当然の欲求から、プラグインの依存関係を記述して解決するパッケージマネージャー機能のアイディアが説明された。

質疑応答では、Bram MoolenaarはLSP(Language Server Protocol)についてあまり興味がなさそうであった。しかしLSPをVimでサポートするのはなかなかよさそうなアイディアに思える。

昼になり弁当が配られた。国際会議なので様々な思想に配慮した結果、すき焼き弁当とベジタブル弁当が用意されていた。私はすき焼き弁当を取りそこねたので、余っていたベジタブル弁当を食べた。ベジタブル弁当の中身はとても品数が多く豪華であった。酒のつまみによさそうな中身だった。

昼休みの余興として、ホワイトボードに模造紙を貼って、Vimで書く言語についてのアンケートが行われた。

ありえないことにCとC++が"C/C++"とひとくくりにされていたので、分割した。

その他の欄には様々な言語が学んだ。まずMarkdownだ。当然ながらVimscriptもVimで書く。Markdownもそうだ。VimでVimを書く人もいた。これはVimでVimの開発をしているということだ。要するにC言語を書くことでもあるのだが。

Python 2を書いてみたところ、シールがいくつか貼られていた。まだPython 2を書かなければならないかわいそうな人たちも参加していたらしい。

ネタで書いたEmacs Lispにもシールが貼られていた。これはネタではなく理由のあることで、環境構築をする際にまずデフォルトで入っているVimでEmacsの設定ファイルを記述し、その後にEmacsをインストールするので、VimでEmacs Lispを実際に書くのだという。

更にわからないことに、Jupyter Notebookが追加されてた。Jupyter Notebookというのはプログラマーではなく科学者向けソフトウェアだ。科学者は頭のいい人間であり、研究に必要なコードは当然書ける。しかし彼らは本物のプログラマーではないので、プログラマーらしいコンピューターの使い方やプログラミング言語の環境構築は苦手だ。Jupyter Notebookはそういう手間を省き、科学者でも様々なプログラミング言語を使えるようにした環境だ。Jupyter Notebookというソフトウェア一つ入れれば、後は何も考えなくてもいい。そのJupyter NotebookをVimから使うとはどういうことか。聞けばVimからJupyter Notebookを操作しているのだという。それができる人間なら、Jupyter Notebookをわざわざ使わずともプログラミング言語の環境構築は簡単にできるはずなのだが、世の中はわからない。

午後の発表になった。Vimの従来のプラグインの機能は、実は今のVim標準の機能で代替可能であることを示す発表があった。Ctrl-Xから始まる各種保管の説明があったが、私は使いこなしていない。

今回の複数の発表によれば、Vimは就職活動に役立つらしい。

vim-historyレポジトリも興味深い。これは1991年にリリースされて27年の歴史を持つVimの更新履歴を単一のgitレポジトリで再現したものだ。Vimは当初、当時の慣習としてtarballで配布され、その後CVSで管理されるようになり、何度かのレポジトリの断絶を経て、今はgitで管理されている。レポジトリの全歴史をgitレポジトリで表現することにより、gitによる様々な操作が可能になる。例えば特定のコントリビューターは何件コミットしているのか。あるコントリビューターの最初のコミットはどれか。などといった、様々な変更の歴史がgitで検索できるようになる。

似たような試みはUNIXにもある。UNIXの歴史をgitレポジトリで再現するプロジェクトがある。

そして、:termdebug機能が言及された。この後の発表はあまり覚えていない。:termdebug機能のあまりの素晴らしさに発表を聞くのがおろそかになってしまったからだ。

:termdebugはVimにデフォルトで同梱されているVimによるGDBのフロントエンドを提供するプラグインだ。使い方は、":packadd termdebug"して、":Termdebug プログラム名"するだけだ。VimはGDBを起動してGDBと通信する。そして、GDBとやり取りするウインドウ、デバッグされるプログラムの標準入出力のウインドウが追加される。現在のウインドウはソースコード表示に使われる。

素晴らしいことに、マウスサポートを有効にしている場合、StepやNextといったボタンが現れ、クリックすら可能になる。そしてGDBに該当のコマンドを送る。

これがすべてVimの中で動くということは、リモートサーバーにsshして動かすことすら可能になるということだ。

しかし、使うとすぐにバグが見つかった。ブレイクポイントはソースコード上で表示されるのだが、break/deleteを繰り返すと存在しないブレイクポイントの表示が消えなくなるのだ。この問題は原因を特定したのだが、最新版のVimでは治っていることが判明した。

もう一つの問題は、Bram MoolenaarがC言語しか想定していなかったための機能不全だ。C++では複数の関数が同じ名前を持つことができる。

void f() {}
void f(int) { }
void f(long) { }

この状態で"break f"とすると、関数fすべてにブレイクポイントが設定される。termdebugはこれに対応していない。

この場合のGDBのブレイクポイント番号の付与は変わっている。"break f"とした場合、1.1(f()), 1.2(f(int)), 1.3(f(long))のようにメジャーブレイクポイント番号と関数ごとにマイナーブレイクポイント番号が付与される。結果としてブレイクポイントは3つできるが、それはすべてブレイクポイント番号1として扱われる。enableコマンドなどは"enable 1.1"のように指定できるが、deleteは指定できない。"delete 1"とするとブレイクポイント番号1に属するすべてのブレイクポイントが削除される。

termdebugはブレイクポイント番号をキーにしてmapでブレイクポイントを管理しているのだが、ひとつのbreakコマンドで複数のブレイクポイントが設定されることを想定していないし、ましてやその複数のブレイクポイントが一つのメジャーブレイクポイント番号に属することを想定していない。そもそもマイナーブレイクポイント番号があることすら想定していない。ブレイクポイント番号をキーにしてmapでブレイクポイントを管理していて、削除時にブレイクポイント番号をキーに検索して削除している。

現在のコードを大幅に変えずに関数のオーバーロードのブレイクポイント表示に対応するのは難しい。HandleNewBreakpointで"1.1", "1.2", "1.3"のようなキーで複数のブレイクポイント番号をキーにしてs:breakpointsに挿入し、HandleBreakpointDeleteで"1.1", "1.2", ...のようにマイナー番号の削除を見つからなくなるまで試みる実装が、とりあえず使えるだろうとは思う。

termdebugは素晴らしい。そして、Termdebugとそのバグのおかげで、Bram Boolenaarと会話ができたという思わぬ副産物もあった。VimconfにBram Moolenaarが来ると聞いて会話をしたいとは思っていたものの、特に話すべき内容は思いつかなかった。なるほど、私はVimを毎日使っているが、Vimの開発に参加しているわけはない。せいぜい挨拶をするのが関の山だと思っていたのだが、Termdebugの存在で会話内容ができてしまった。英語によるスピーキングは普段全くしていないので英語が口から一切出てこないのだが、不思議なことにtermdebugがC++をサポートしていないことについてとその原因についてであれば、英語で説明をすることができた。言語の利用には慣れた文脈が必要のようだ。

termdebugをなぜ今まで知らなかったのだろうと疑問に思っていたが、どうやら今年の7月にVimに入ったばかりのだいぶ新しい機能であるようだ。道理で知らないわけだ。termdebugの存在を知ることができたという理由だけでvimconf 2018のスタッフをしたかいがあった。

その後、もう一枚ホワイトボードが追加され、今度はVimに欲しい新機能のアンケートが行われた。人気の機能はVimscriptの高速化であった。私は、VimがtmuxやScreenのように、シェルからのdisownによるログアウト後の実行継続と、detach/attach機能がほしい。この機能があれば、tmuxはいらなくなる。Vimがtmuxの代わりを務めることができるのだ。リモートサーバーにsshしてvimでテキストを編集し、その編集中のvimの実行を継続したままログアウトし、後にログインして前回の続きから作業を再開したい時、今はtmuxの中でvimを実行しなければならない。これがvimだけで済むようになるのだ。

新機能では端末でエスケープシーケンスによるグラフィック表示をするSixelも人気があった。これは解せないことだ。Sixelはテキスト処理だけで完結するが、グラフィックの表現としては非効率的すぎる。効率を重視するならば、ビットマップデータを直接流し込むようなAPIがほしい。もちろんこれはNULも扱えるようにBLOB型が必要になるだろう。

Vimconf 2018は素晴らしかった。来年も開催されるだろうか。楽しみだ。

ワンナイト人狼とボードゲームの知的財産権について

なぜか一部のボードゲーム作者は、事実の羅列や純粋な思想、新規性も進歩性もない発明であるゲームルールに排他的な独占権を欲しがる。そのような権利が認められた場合、我々は日常会話すら困難になるのだが、そのことに思いが至ることはないようだ。

ワンナイト人狼と同等のルールがオリジナルを考案した我々の許諾なく販売されたと嘆いている。

「太刀打ち」という物騒な言葉まで用いて攻撃的な対立姿勢を明らかにしている。

しかし、本人も認めるように、事実の羅列や抽象的な思想にすぎないゲームルールは著作権では保護されない。特許として認められるほどの新規性と進歩性も満たしていない。

ライセンスというのは排他的な独占権があってはじめて成立するものだ。そのような権利を持たずして一体何を求めているのか。

唯一なにかできるものがあれば、「ワンナイトルール」という商標の有効性についてだけだ。

望む内容に注意せよ。期待通りの結果をもたらさないことがある。

2018-11-18

自転車を買おうか悩んでいる

私は職場から直線距離4kmの場所に住んでいるのだが、電車による通勤は40分ほどかかる。理由は自宅が駅から遠いことと、乗り換えが必要なためだ。

自宅から職場まで歩くと50分かかる。道なりに5kmほど歩くので、6km/hで歩くとそんなものだろう。

これを考えると、自転車通勤をしたほうがいいのではないかと思う。しかし、駐輪場に自転車を止めるのは面倒だ。では折りたたみ式の自転車を使えばいいのではないか。

と考えていると、同僚からCARRYMEを勧められた。これは10万円するとても小さな折りたたみ自転車の自転車だ。実際に載ってみたが、やはりホイール径が8インチでは乗り心地が悪い。するとBROMPTONという自転車を勧めらた。これは20万円する折りたたみ自転車でホイール径も14インチ。なかなか悪くないがまだ乗り心地が悪そうだ。調べたところDAHHONはホイール径が20インチの折りたたみ自転車だ。これはなかなかよさそうだが少し大きい。これならKHSのような普通の自転車を2つに折りたたみましたぐらいの自転車の方が乗り心地がよさそうだ。

しかし、折りたたみ性能と乗り心地は両立できないらしく、どちらかに振らなければならない。そして、10万、20万も出すのであれば、とても乗り心地のいい折り畳めない自転車が買える。であれば駐輪場の手間を考えても普通の自転車を買うべきだろうか。

2018-11-13

C++標準化委員会の2018サンディエゴ会議の結果

2018 San Diego ISO C++ Committee Trip Report (Ranges v1 TS for C++20; consensus on modules design; new Language and Library Evolution Incubators) : cpp

2018年サンディエゴ会議のトリップリポートが公開されている。今回も大きく変わった。

Range

Rangeが入った。Rangeは膨大なのでここでは解説しない。

Yet another approach for constrained declarations

autoと書くべきところをCocept autoと書けるようになった。


template <auto N >
auto f( auto x )
{
    auto y = x ;
}

というコードを、


template < Concept auto N >
Concept auto f( Concept auto x )
{
    Concept auto y = x ;
}

と書ける。

関数の戻り値の型と変数宣言の場合はautoを省略できる。


template < Concept auto N >
Concept f( Concept auto x )
{
    Concept y = x ;
}

こんなところがまだ変わるようでは、まだまだC++20参考書は書けそうにない。書いたそばから変わっていく。

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r2.html

必ずコンパイル時に評価されるconsteval関数が追加された。

consteval int f( int x )
{
    return x+1 ;
}

constexpr関数は実行時評価でよい場合は評価を実行時に遅延させてもよいという規定がある。consteval関数は必ずコンパイル時に評価される。

std::is_constant_evaluated

コンパイル時評価されているときにtrueを返すstd::is_constant_evaluatedを追加する。


constexpr double power(double b, int x) {
  if (std::is_constant_evaluated() && x >= 0) {
    // A constant-evaluation context: Use a
    // constexpr-friendly algorithm.
    double r = 1.0, p = b;
    unsigned u = (unsigned)x;
    while (u != 0) {
      if (u & 1) r *= p;
      u /= 2;
      p *= p;
    }
    return r;
  } else {
    // Let the code generator figure it out.
    return std::pow(b, (double)x);
  }
}

これにより、constexpr関数の中にコンパイル時処理と実行時処理を同時に書くことができるようになる。

少し異質なライブラリで、コンパイラーマジックでサポートされるので、ヘッダーファイルに依存せず使うことが可能となっている。

[C++標準化委員でなければ読めない] p1330r0.pdf

unionの有効なメンバーを切り替える処理をコンパイル時定数にする。std::stringやstd::optionalをconstexpr化するのに必要。

p1002r0.pdf

try, catchをコンパイル時処理では無視する。コンパイル時定数への対応ではない。標準ライブラリの多くをconstexpr化するのに必要。将来的に例外をコンパイル時定数に対応する可能性を閉ざすものではない。

Allowing dynamic_cast, polymorphic typeid in Constant Expressions

dynamic_castとtypeidをコンパイル時定数にする変更。すでにコンパイル時にvirtual関数を使えるようになっているため、制限する理由がなくなった。C++20ではC++コンパイラーはコンパイル時に確保されたオブジェクトの型を把握して適切にディスパッチする必要がある。

p1006r1.pdf

std::pointer_traitsをconstexprに対応させる変更。std::vectorをconstexprにするために必要。

今回はまだ入らなかったが、動的メモリ確保も次回あたりにコンパイル時定数になる予定だ。つまりコンパイル時に動的メモリ確保ができるようになる上、その他の例外やらvirtual関数やらunionやらといった処理もすべてコンパイル時定数になるので、std::stringやstd::vectorがそのままconstexprに対応することになる。C++20ではほとんどの処理がコンパイル時定数になる。これは静的リフレクションを入れるために必要な変更だ。

Misc constexpr bits

標準ライブラリのconstexprにできる部分を積極的にconstexprにしていく変更。

P0668R4: Revising the C++ memory model

C++のメモリーモデルの変更。一部のアーキテクチャのとても弱い保証に対応した。一部のアーキテクチャー、PowerやNVIDIAのGPUとARMは、memory_order_seq_cstに対応しつつrelease/aquireに対応できない。memory_order_seq_cstの存在を許すaquire/releaseを実装するためには、よりペナルティの高い強めのフェンスを挿入しなければならない。しかしそのような理論的な問題のためだけに強いフェンスを使いたくはない。そのために、memory_order_seq_cstには対応しない弱いatomic型を追加する。

P1236R0: Alternative Wording for P0907R4 Signed Integers are Two's Complement

符号付き整数型の値の表現は2の補数であることがC++の規格で保証する変更。

char8_t: A type for UTF-8 characters and strings (Revision 5)

UTF-8文字リテラル、UTF-8文字列リテラルの文字の型を表現するchar8_tを追加する提案。私が9年前にC++0xのときに提案したところ、「でもchatは生のバイト列を表現するのに適切な型だからー」と寝ぼけた主張で却下されたにもかかわらず、後になって「やっぱchar8_tにしとけばよかったなぁ」となったので変更された。私には愚痴を言う権利がある。

Nested Inline Namespaces

インライン名前空間をネストで書けるようにする。


namespace lib::container {
    inline namespace v1 {
        namespace node {
        }
    }
}


namespace lib::container {
    inline namespace v2 {
        namespace node {
        }
    }
}

のように中間のinline名前空間を書く際にはC++17に追加されたネストされた名前空間で書けなかったが、


namespace lib::container::inline v1::node {
}

namespace lib::container inline v2::node {
}

のように書けるようにする。

p1289r0.pdf

contractの中ではアクセス指定を無視する変更。

p1007r2.pdf

std::assume_aligned<N>(ptr)の追加。ポインターptrの指すアドレスがNでアラインされていることをコンパイラーにヒントとして与える


// intの配列から合計をSIMD演算で計算する関数
int sum_ints( int * ptr, std::size_t n )
{
    std::assume_aligned( ptr, alignof(int) ) ;    
    // アライメント要求のあるSIMD演算で合計を計算
    return 
}

実際に指定したアライメントになっていることを保証するのはユーザーの仕事だ。std::assume_alignedはアライメントが保証されていると仮定してよいとコンパイラーにヒントを与えることによって、コンパイラーがSIMD演算のようなコード生成を行うときに、アライメント調整用のコードを生成せずに住むようにする。

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1085r2.md

spanからoperator ==を取り除く変更。spanをregularにするために必要な変更。

STLの作者Alexander StepanovはC++では型はRegularであるとが重要だと力説した。型がRegularでない場合、もたらす利便性よりも混乱のほうが大きくなる。

コピーコンストラクターとコピー代入演算子は、オブジェクトの「値」をコピーする。

operator ==やoperator <はオブジェクトの「値」を比較する。

型がRegularであるためには、コピーと比較は同じ「値」を比較しなければならない。コピーと比較で「値」の定義が異なっている場合、混乱の元だ。

さて、spanはどうなっているか。spanのコピーはshallowだ。つまり、ポインターとそのサイズがコピーされる。一方、spanのoperator ==はdeepだ。つまり、ポインターの参照する先のストレージが比較される。

spanをRegularにするためには、spanのoperator ==を廃止する。

Smart pointer creation with default initialization

make_unique_default_init<T>/make_shared_default_init<T>を追加する。これはデフォルト初期化されたunique_ptr<T>/shared_ptr<T>を返す。

size_t型の引数nを取るものもあり、こちらはunique_ptr<T[]>/shared_ptr<T[]>を返す。


// デフォルト初期化されたint型の値の
// std::unique_ptr<T>
auto p = std::make_unique_default_init<int>() ;
// それぞれデフォルト初期化されたint型の値で要素数が5の
// std::unique_ptr<T[]>
auto a = std::make_unique_default_init<int>(5) ;

C++標準化委員会では、特定の分野について議論するStudy Groupが設置されるが、今回、新しいStudy Groupとして、SG19 Machine LearningとSG20 Educationが追加された。SG19は名前だけみると機械学習についてで、SG20は前から作ると宣言されていた教育に関するSGだ。

C++を発展させるEvolution Working Groupでは以下のような興味深い議論があった。

モジュールの中でmain関数を定義できる提案と、プログラムにデータを埋め込むstd::embed提案はより深い議論とフィードバックが必要だとされた。

void main提案は却下された。

興味深いのは、operator []の中の operator , の利用をdeprecatedにしようという決定だ。


int a[5] ;
a[1,2] ; // a[2]と同じ

このコードがdeprecated扱いになる。operator []の中のカンマは、多次元配列を実装するための何らかの新しい機能として予約される。

short float提案についてコンセンサスは得られなかった。

std::colonyはもっと作業が必要だとされた。

設計的には賛同できるのでC++20に追加する方向で進めるライブラリとして、テキストフォーマット(std::format)、スタックトレースライブラリがある。

SG13 Graphics Study Groupではオーディオに関する興味もあるらしい。またweb_viewに対するさらなる作業を推奨する雰囲気だ。

今後の予定としては、2019年春のKona会議でFeature freezeをし、2019年夏のドイツのCologne会議でCommittee Draftの文面を完成させる。つまり来年の半ばにはC++20の概要は決定するわけだ。

モジュールはおそらくC++23以降に延期される。コルーチンやExecutorも延期される。ネットワークライブラリはおそらくC++26以降になるだろう。

2018-11-10

かつてPSエミューレーターにスラップ訴訟を仕掛けたソニーのPSクラシック、自由ソフトウェア実装のPSエミュレーターであるPCSX ReARMedを使っていることが判明

かつてPSエミュレーターをスラップ訴訟により嫌がらせをして事実上の販売停止に追い込んだ邪悪なソニーが販売するPSクラシックには、自由なソフトウェア実装のPSエミュレーターであるPCSX ReARMedが使われていることが判明した。

Kotakuによるレビューによれば、PSクラシックの使用する自由ソフトウェアのライセンス表記の一覧にPCSX ReARMedが確認できたという。

PCSXは自由ソフトウェアによるPSエミュレーター実装で、2000年に公開された。その開発は停滞したが、2006年にPCSX-dfとしてforkされた。またPCSX-Revolutionいうforkもあった。2009年にはこの2つのforkを参考にPCSX-Reloadedいうforkも行われている。

PCSX ReARMedはPCSX-Reloadedのforkで、PCSXをARMアーキテクチャに移植する目的で開発されている。

さて、ソニーはPSエミュレーターに対して悪名高いスラップ訴訟を仕掛けてきた歴史がある。

Mac用のPSエミュレーター実装であるConettixのVirtual Game Stationの販売を著作権侵害のスラップ訴訟を起こして差し止めようとした。これは最終的にソニー側に不利な和解で終わっているが、その間VGSの販売が差し止められた。

また、Bleem CompanyによるPSエミュレーターBleem!を著作権侵害と不正競争防止法によりスラップ訴訟を起こして差し止めようとした。この訴訟でソニーが完全に敗北している。PSエミューレーターは不正競争防止法に反しないばかりか、宣伝に使ったPSゲームのスクリーンショット利用すら、著作権法に照らし合わせて正当な引用であるとの当然の判決が下った。しかし、物語はハッピーエンドには終わらない。長引く訴訟により膨れ上がった訴訟費用に耐えかね、Bleem Company は倒産。結果的に邪悪なソニーはBleemの販売を事実上差し止めることに成功した。

その悪名高い札付きのソニーが当時の愚かな行いに対する謝罪もなく、何食わぬ顔で自由ソフトウェアを使ったPS互換機を販売するとは、恥知らずにも程がある。ソニーはPSクラシックの販売にあたって、過去の過ちを認め、公に謝罪するべきである。

結局、抵抗は無意味であり自由ソフトウェアが勝利するのだ。

参考文献:

PlayStation Classic Plays Fine, But It’s A Bare-Bones Experience

Sony using open source emulator for PlayStation Classic plug-and-play | Ars Technica

Sony to sue Connectix over PlayStation emulator • The Register

Connectix Virtual Game Station - Wikipedia

Bleem! - Wikipedia

PCSX-Reloaded - Wikipedia

PCSX ReARMed

2018-10-29

帰ってきたきれいなリーナス・トーバルズ、無作法な開発者をたしなめる

Linus Torvalds Shows His New Polite Side While Pointing Out Bad Kernel Code - Phoronix

人の心の読み方を学んで復帰したリーナス・トーバルズは、さっそく無作法なプルリクエストをたしなめている。その文章は大文字センテンスも4文字言葉も使っていない優しいものに変わっている。

問題はプルリクエストはBigBenゲームコントローラーに対するドライバーの追加で、このドライバーはデフォルトで有効にされていた。これはLinuxカーネルの慣習にそぐわないものだ。新しく追加された名前もきいたこともないようなデバイス用のドライバーが、いきなりカーネルでデフォルトで有効にはされないものだ。新参者のドライバー開発者は、大抵自分のドライバーはとても重要で、自分の所有しているデバイスは全員所有しているのでデフォルトで有効にするのは当然だと傲慢にも考えている。このような既存の慣習に従わない傲慢な態度は、通常、リーナス・トーバルズによって発見され次第、罵詈雑言を持って鼻っ柱を叩き折り、厳しくしつけられる。

それがなんと以下のように穏やかなメールになっている。

新しいポッと出のドライバーがデフォルトで有効にされることは「ない」。そのデバイスが聞いたことのないような名前の場合は「特に」ありえない。

にもかかわらず、このマージ期間で新しく追加された「BigBenインタラクティブ」ドライバーとやらはまさにそういうことをしている。

そういうことはするな。

分かってる分かってる。開発者は全員、自分のドライバーはとても特別で魔法のように重要なので、当然デフォルトで有効にされるべきだと考えているものだ。だが違う。何千ものドライバーがあるなかで、ポッと出の新しいドライバーが、一部の開発者が特別だと思っているという理由だけで、デフォルト有効にされることはない。

そういうわけで、コミット256a90ed9e46 ("HID: hid-bigbenff: driver for BigBen Interactive PS3OFMINIPAD gamepad")の

default !EXPERT

は完全に間違いだ。プリーズこういうことはしないでくれ。

リーナス

比較のために、去年の11月に似たような問題をたしなめたリーナスのメールを見てみよう。

テメーは新しいドライバーを追加してデフォルトonにしただと。

(大文字)コイツァゼッテーに受け付けらんねーッ。

何でこの俺が直々にマージ期間のたびに毎回言わなくちゃなんねーんだよ。だがもっかい言ってやるぞ。

開発者として、テメーは自分のドライバーとか機能が超絶最高に重要なものだと思ってて、しかもテメーは対応するデバイスも持っているわけだ。

(大文字)だがそんなのァ誰も気にしちゃいねぇんだよ。

これ読んで泣きベソでもかいとけ。オメーのハードウェアが超絶に普及してない限り、全員の設定でデフォルトでデフォルト化されているべきじゃねぇ。

(一部単語が大文字)このブランチで追加されたすべての"defult"の行は間違ってる。

こういうことはやめろ。みんなの期待を裏切る行為だぜ。俺が"make oldconfig"したとき、ポッと出の新しいハードウェアドライバーが有効にされてほしくはない。

もう一つリーナスの忍耐力を試すイベントがあった。リーナス様の環境がKernel oopsをお出しになったのだ。

俺のラップトップが今のgitツリーでカーネルページフォルトを出した。今の所怪しいコミットは

9ee3e06610fd ("HID: i2c-hid: override HID descriptors for certain devices")

これだが、そう思った理由は単に今回のマージ期間でこの辺をいじってるコミットがこれしかないからだ。

oopsは以下の通り

(省略)

だから俺は新しいi2c_hid_get_dmi_hid_report_desc_override()のコードを疑ってるわけだ。

思うに問題はi2c_hid_dmi_desc_override_table[]がNULLエントリーで終端されていないことなので、今からテストする。

この問題はすごく悲しい。これはつまりこのコードは文字通り誰にもテストされてないってことで、誰もこのリストにエントリーを入れてないってことだ。

ちなみに以前、リーナスがパッチを適用したカーネルをブートするだけで確実にカーネルoopsを発動させるような初歩的なミスを発見した場合は、大文字で「テストされてないクソ」となじり、罵詈雑言あふれるメールが飛ぶものだ。

2018-10-24

C++標準化委員会の10月の興味深い文書

2018-10のC++標準化委員会の文書集が公開されていたので、興味深い新機能の提案に限って紹介する。

secure_val

セキュリティ上の理由でメモリの内容を破棄したい場合、コンパイラーの最適化によって意図通りのコードが吐かれないことがある。


void decrypt()
{
    char password[64] ;
    // パスワードを取得
    get_password(password) ;

    // 複合処理
 
    // パスワードをメモリから破棄
    std::memset( buffer, 0, 64 ) ;
}

このコードでは最適化の結果memsetが省略されるかもしれない。なぜなら、bufferはmemsetの後に使われていないから、memset自体が不要だとコンパイラーは判断できるからだ。

そのために、最適化によって消えずに値を消去できるライブラリを提供する。


void secure_clear( void * data, size_t size ) noexcept ;
template < typename T >
void secure_clear( T & object ) noexcept ;

この提案はさらに、secure_val<T>クラスを提案してる。secure_valはT型を保持するクラスで、デストラクターはT型をセキュアに破棄する。T型の値にアクセスする方法は関数オブジェクトを指定するもので、コピーを許さない。


void decrypt()
{
    std::secure_val<char [64]> val ;

    val.access([]( auto & data )
    {
        get_password( data ) ;
    } ) ;

    // 複合処理

    // valのデストラクターがセキュアにメモリ上の値を廃棄
}

unique_val

secure_valに似ているunique_val。これはT型をコピーせずにムーブするクラスだ。

ムーブしたあとのT型はデフォルト初期化された値になる。

ポインターやシステムリソースへのハンドルを扱うのに使える。

Remember the FORTRAN - p1300r0.pdf

C++に現在提案されているモジュールの実験的な実装はFORTRANが30年間解決できなかったパフォーマンス上の課題を抱えていると警鐘を鳴らす文書。

GCCのモジュール実装では、モジュールのソースファイルをコンパイルして.nsmファイルを作成しその後そのモジュールをimportするソースファイルをコンパイルすると、該当する.nsmファイルを使う。

FORTRAN-90はモジュール機能を備えており、これは今のC++のモジュールと原理的に同じ機能を同じ実装で提供している。つまりFORTRANは30年前からモジュール機能がある。

あるモジュールをimportするソースファイルをコンパイルするためには、事前に依存するモジュールをコンパイルしなければならない。モジュールは別のモジュールをimportできる。つまりモジュールをコンパイルするには事前に依存する別のモジュールをすべてコンパイルしなければならない。

これはビルドシステムととても相性が悪い。ビルドシステムが複数のソースファイルからなるプログラムをビルドするとき、モジュールの依存関係を把握してDAGを構築し、適切な順序でモジュールをコンパイルしなければならないということだ。つまりビルドシステムはC++ソースファイルを解釈する必要がある。

IntelのFORTRANコンパイラーのマニュアルは「プログラムが依存するモジュールのファイルは事前に生成しておけ」という。Intelという超巨大で世界的な大企業ですら、莫大な利用料を支払う顧客に対して、「依存してるモジュールは事前に全部コンパイルしとけよ」ぐらいの助言しか与えられていないのだ。

著名なGNU Fortran開発者ですら、Fortranのプログラムをビルドするときは、「Makeを成功するまで十分な回数実行する」と言っている。

モジュールを正しくコンパイルするにはモジュールの依存関係の解析が必要で、そのためにはソースファイルの解釈が必要になる。Makeやninjaのような汎用的なビルドシステムにC++を解釈する機能をつけることは現実的ではないので、C++コンパイラーが依存関係を解決する機能を提供するようになるだろう。

ところで、Windowsはプログラムを起動するパフォーマンスが極めて悪い。1ソースファイルごとにC++コンパイラーを1回起動して依存関係を解決するような実装はWindowsではパフォーマンスが悪い。

不自由で低能なWindowsはプロセスの作成もスレッドの作成も遅いし、ましてやファイルの作成に至っては、i7でNVMeのSSDを積む高性能なコンピューター上で動くWindows 10がRaspberry PiとSDカード構成のRaspbianにすらパフォーマンスで負けるという信じられないほどの低能を誇っている。

Benchmarking OS primitives – Bits'n'Bites

そして、ソースファイルの一部だけを変更した後の部分的なビルドですら、モジュールの依存関係が変わるかもしれないので依存関係の解決が必要だ。

モジュールはビルド時間を削減するべきであって、ビルド時間を増やすのは本末転倒だ。

FORTRANが30年かかっても解決できていない問題は解決できそうにない。

P1283R0: Sharing is Caring

Linuxのshared libraryやWindowsのDLLのためにエンティティをexportする属性、sharedの追加の提案。

P1282R0: Ceci N’est Pas Une Pipe: Adding a workflow operator to C++

新しいワークフロー演算子として<|と|>を追加する提案。


// 右から左
a <| b ;
// 左から右
a |> b ;

C++20にはレンジやExecutorやコルーチンやモナドが提案されているがこれらの提案は右から左、もしくは左から右といった処理の流れを記述する。例えば以下は1から始まる整数列を生成し、奇数だけをフィルターした整数列にし、その先頭から5個だけを取り出した整数列にするレンジのコードだ。


iota(1) | filter(odd) | take(5) ;

これは処理の流れがわかりにくい。すでにoperator >>はあるが、これは演算子の評価順序の関係で使えない。operator >>=なら使えるがこれは汚い。

そこでオーバーロード可能なワークフロー演算子を追加する。


iota(1) |> filter(odd) |> take(5) ;

これはほしい。

P1281R0: Feature Presentation

本当の条件付きコンパイル機能の提案。

constexpr ifは条件付きコンパイルではなく、条件付きテンプレート実体化抑制機能だ。そのために意味上エラーとなるコードを書くことができない。

この提案では、条件付きコンパイル機能を提供する属性により、文法上正しいが、意味上エラーとなるコードを書けるようにする。


[[ feature("key")]] 

[[feature()]]はキーとなる文字列を受け取る。このキー文字列が宣言されていないか、ブロックリストに入っている場合は、その属性がある宣言とその中身がASTから取り除かれる。

利用例は以下の通り。


struct [[feature("vulkan")]] Device {
  [[feature("glsl-to-spirv")]]
  static Shader compile(std::filesystem::path filename);
  static Shader load (std::filesystem::path spirv_file);
};

struct [[feature("direct-x")]] Device {
  [[feature("hlsl-to-spirv")]]
  static Shader compile (std::filesystem::path filename);
  static Shader load (std::filesystem::path spirv_file);
};

いまグラフィックAPI用のライブラリを書きたいとする。このライブラリはVulkanとDirectXを両方サポートする。ただしコンパイル時の環境では、VulkanかDirectXのどちらかしか提供されていない。上のようなコードで、"vulkan"か"direct-x"のどちらかのキー文字列だけを宣言することで、2つのDeviceクラスの実装のうち、どちらか片方だけを有効にできる。無効な属性のクラスはまるごとASTから取り除かれる。

さらにこのライブラリはシェーダー言語であるGLSLやHSSLからSPIR-Vへの変換機能を提供するが、条件次第ではこの機能を提供しないことも選択できる。

文法上妥当である必要があるので、比較的穏当な条件付きコンパイルだ。#ifdefはいずれ廃止したいものだ。

P1280R0: Integer Width Literals

ビット長を指定した整数型intN_tとuintN_tに対するユーザー定義リテラルとして、operator "" iNとoperator "" uNを追加する提案。


using namespace::literals ;

auto a = 0i16 ; // std::int16_t
auto b = 0i32 ; // std::int32_t

auto c = 0u8 ; // std::uint8_t
auto d = 0u64 ; // std::uint64_t

便利だ。

P1279R0: std::breakpoint

プログラムからブレイクポイントを設定できるライブラリstd::breakpointの提案。


using namespace std::literals ;

int main()
{
    std::breakpoint() ;
    std::cout << "hello"sv ;
    std::breakpoint() ;
    std::cout << "world"sv ;
    std::breakpoint() ; 
}

P1278R0: offsetof For the Modern Era

std::offsetofの提案。offsetofはマクロでstandard layout classにしか使えない。std::offsetofはstd::bit_castで実装できるが、std::bit_castはconstexprではない。std::offsetofはconstexprになるべきだが、議論が必要だ。

P1277R0: Subscripts On Parade

operator []で複数の引数を取れるようにする提案。


struct S
{
    int & operator [] ( int a, int b, int c ) ;
} ;

int main()
{
    S s ;
    s[1,2,3] = 1 ;
}

多次元配列ライブラリが提案中だが、多次元配列へのアクセスをできるだけ直感的に書けるようにしたい。

P1276R0: Void Main

void mainを認める提案。すでにmain関数は空のreturn文を認めていて、その場合は0を返したものとみなされる。ならばvoid mainも認めてよいはずだ。

P1275R0: Desert Sessions: Improving hostile environment interactions

C++にプログラムの引数の参照と、環境変数を参照、変更できるライブラリを追加する提案。C++風にイテレーターでアクセスできる。

P1274R0: Bang For The Buck

識別子としてダラーサイン($)を認める提案。さらに、識別子の最後に限り驚嘆符(!)と疑問符を(?)を認める。

これにより"set!"や"empty?"のような関数名も使えるようになる。

$は静的リフレクションのキーワードreflexprの代わりに使えるようにすべきだという声もあるが、著者は識別子として使えるようにしたほうが有益だと主張している。

私としては$はreflexprの代わりに使いたい。jQueryのように・・・というと縁起が悪いが。

Pattern Matching - p1260r0.pdf

パターンマッチの提案。文法は比較的穏健。

整数の例


// Before
switch (x) {
    case 0: std::cout << "got zero";
    case 1: std::cout << "got one";
    default: std::cout << "don't care";
}

// After
inspect (x) {
    0: std::cout << "got zero";
    1: std::cout << "got one";
    _: std::cout << "don't care";
}

文字列の例


// Before
if (s == "foo") {
    std::cout << "got foo";
} else if (s == "bar") {
    std::cout << "got bar";
} else {
    std::cout << "don't care";
}

// After
inspect (s) {
    "foo": std::cout << "got foo";
    "bar": std::cout << "got bar";
    _: std::cout << "don't care";
}

tupleの例


// Before
auto&& [x, y] = p;
if (x == 0 && y == 0) {
    std::cout << "on origin";
} else if (x == 0) {
    std::cout << "on y-axis";
} else if (y == 0) {
    std::cout << "on x-axis";
} else {
    std::cout << x <<','<< y;
}

// After
inspect (p) {
    [0, 0]: std::cout << "on origin";
    [0, y]: std::cout << "on y-axis";
    [x, 0]: std::cout << "on x-axis";
    [x, y]: std::cout << x <<','<< y;
}

他にもvariantの例、ポリモーフィック型の例、式を評価する例がある。

pattern_matching

別のパターンマッチの提案。こちらはどの関数型言語からやってきたんだというぐらい既存のC++にそぐわない異質な文法になっている。

enumの例


enum color { red, yellow, green, blue };

// Before
const Vec3 opengl_color = [&c] {
  switch(c) {
    case red:
      return Vec3(1.0, 0.0, 0.0);
      break;
    case yellow:
      return Vec3(1.0, 1.0, 0.0);
      break;
    case green:
      return Vec3(0.0, 1.0, 0.0);
      break;
    case blue:
      return Vec3(0.0, 0.0, 1.0);
      break;
    default:
      std::abort();
  }();

// After
const Vec3 opengl_color =
  inspect(c) {
    red    => Vec3(1.0, 0.0, 0.0)
    yellow => Vec3(1.0, 1.0, 0.0)
    green  => Vec3(0.0, 1.0, 0.0)
    blue   => Vec3(0.0, 0.0, 1.0)
  };

あまりにもC++として異質すぎる。

クラスに対するパターンマッチの例


struct player {
  std::string name;
  int hitpoints;
  int lives;
};

// Before
oid takeDamage(player &p) {
  if(p.hitpoints == 0 && p.lives == 0)
    gameOver();
  else if(p.hitpoints == 0) {
    p.hitpoints = 10;
    p.lives--;
  }
  else if(p.hitpoints <= 3) {
    p.hitpoints--;
    messageAlmostDead();
  }
  else {
    p.hitpoints--;
  }
}

// After
void takeDamage(player &p) {
  inspect(p) {
    [hitpoints:   0, lives:0]   => gameOver();
    [hitpoints:hp@0, lives:l]   => hp=10, l--;
    [hitpoints:hp] if (hp <= 3) => { hp--; messageAlmostDead(); }
    [hitpoints:hp] => hp--;
  }
}

あまりに既存のC++の文法とは違いすぎる。

p1235r0.pdf

implicit constexprの提案。

constexpr関数の制約は今後ますます減っていき、コンパイル時定数式にしたい処理は今後ますます増えていく。

C++17ではlambda式のoperator ()は暗黙にconstexprだ。この結果、以下の同じように見えるコードの挙動が異なる。


int f( int x ) { return x ; }
auto g = [](int x ) { return x ; }

// Error
constexpr int a = f(0) ;
// OK
constexpr int b = g(0) ; 

そこですべての関数を暗黙にconstexprにしてしまおうというのがこの提案だ。

C++ Compile

C++のコンパイル方法を標準化しようという提案。C++の教育SGが提唱されたり、パッケージシステムも議論される中、必要な提案ではあると思うが、果たして受け入れられるだろうか。

この提案では、コンパイラーのオプション指定は+で指定する。長いオプションは++で指定する。

cpp hello.cpp ++output=hello

まず<compile>ヘッダーにコンパイラーを呼び出すライブラリが追加される。


namespace std
{
  int compile(int, char * *) noexcept;
  int compile(vector<string>) noexcept;
}

一つ一つの文字列がargumentとして処理される。+で始まらないargumentはソースファイル名だ。

+で始まるのはコンパイル時のオプションで、例えばヘルプメッセージの出力、出力ファイル名、デバッグといったC++コンパイラーによくあるオプションを定義している。

コンパイル方法を標準化することによって、教育や提案中のパッケージシステムで使いやすくなる。

ファイルシステムライブラリも標準C++にある今、C++ライブラリとしてのビルドシステムという不思議な概念が浮かんだ。

p1177r0.pdf

パッケージシステムの全容の提案、コンパイラーAPI、ビルドシステムAPI、パッケージ依存解決API、パッケージ検索APIによって構成される。

P1214R0: Pointer to Member Functions and Member Objects are just Callables!

メンバーへのポインターをINVOKEのように振る舞わせる提案。


struct Foo
{
    int data ;
    int func( int x ) { return x ; }
} ;

int main()
{
    int (Foo::*data_ptr) = &Foo::data ;
    int (Foo::*func_ptr)(int) = &Foo::func ;
    Foo obj ;

    // Before
    obj.*data_ptr = 123 ;
    (obj.*func_ptr)(123) ;

    // After
    data_ptr(obj) = 123 ;
    func_ptr(obj, 123) ;
}

ジェネリックコードで大量の特殊化を書く必要がなくなる。

p1227R0: Signed size() functions

符号付き整数を返すsize関数としてssizeの提案。

std::vector<int> v ;
for ( int i = 0 ; i < v.size() - 1 ; ++i )
{ }

このコードは"0u-1"を実行してしまうので意図通り動かない。ssizeがあれば、"v.ssize() - 1"と書ける。

P1108R1: web_view

画期的に使いやすいグラフィックライブラリ、webviewの提案の改定案。変更点としては議論が追加されている。これはHTMLとCSSをブラウザーで表示し、JavaScriptを注入できる極めて簡単なライブラリだ。

2018-10-23

SQLiteの行動規範がキリスト教徒の戒律を全文引用していて香ばしすぎる

Code Of Conduct

SQLite creator crucified after code of conduct warns devs to love God, and not kill, commit adultery, steal, curse... • The Register

SQLiteの行動規範(Code of Conduct)は大真面目に西暦500年の聖ベネディクトの作った72か条の戒律を全文引用している。この行動規範はSQLiteの利用者が同意する必要はないが、開発者は同意しなければならない。結果としてSQLiteは危険すぎるので使ってはならない。なぜならばSQLiteの開発者は全員キリスト教原理主義者で奴隷制度を肯定し非武装でキリスト教徒に改宗すらさせた敵をジェノサイドしたカルト宗教の信奉者であり、キリスト教の教義に合わないコードは書かず、異教徒を攻撃するだろうからだ。

聖ベネディクトが西暦500年ごろに作った72か条の戒律のほとんどは現代の価値基準に照らし合わせて香ばしい。

  1. まず第一に、主たる神をまつたき心、まつたき魂、まつたき力を以って愛せよ
  2. しこうして、汝の隣人を汝がごとく愛せよ
  3. 殺すなかれ
  4. 姦淫するなかれ
  5. 盗むなかれ
  6. 欲するなかれ
  7. 偽証するなかれ
  8. 皆を敬え
  9. 汝自身にせぬことを他人にするなかれ
  10. キリストに従うために汝自身を否定せよ
  11. 汝自身を折檻せよ
  12. 喜びに耽るなかれ
  13. 断食を愛せよ
  14. 貧者を慰撫せよ
  15. 裸人に服を与えよ
  16. 病人を訪れよ
  17. 死人を埋葬せよ
  18. 艱苦を救え
  19. 嘆きを慰撫せよ
  20. (訳注:異教徒どもの罪深い)世界とは手を切れ
  21. キリストへの愛のほかには何も好むな
  22. 怒りに身を任せるな
  23. 遺恨を養うな
  24. 心に偽りを抱くな
  25. 偽りの和平を結ぶな
  26. 寄進を惜しむな
  27. 呪うな、汝自身を偽るがゆえに
  28. 心からの真実のみを口にせよ
  29. 邪悪に邪悪をもって返すな
  30. 他人に邪ならずして、汝への邪は甘んじて受けよ
  31. 汝の敵を愛せよ(訳注:敵の存在も神の思し召しなるがゆえに)
  32. 汝を呪うものを呪うな。祝福せよ
  33. 正義のために懲罰を受け入れよ
  34. 誇るなかれ
  35. ワインを痛飲するなかれ
  36. 鯨飲馬食するなかれ
  37. 寝ぼけるなかれ
  38. 怠けるなかれ
  39. 愚痴るなかれ
  40. 中傷するなかれ
  41. 望みを神に託せ
  42. 汝にかかる良きことは汝の功にあらずして神の功とせよ
  43. 己の行いは邪にして己の責に帰すことを思え
  44. 審判の日を恐れよ
  45. 地獄を恐れよ
  46. 全身全霊で永久の命を欲せよ
  47. 毎日死を見つめよ
  48. 人生における行動に常に気をつけよ
  49. 神はすべての場所を見張っていることを確実に知れ
  50. 邪なる思いが胸中に生ずるときはただちにキリストに帰依し、精神の父なることを認識せよ
  51. 邪なる言葉を口にするなかれ
  52. 饒舌を愛するなかれ
  53. うぬぼれや笑いをもたらす言葉を話すなかれ
  54. やかましい笑いと行き過ぎを愛するなかれ
  55. 聖書の朗読を積極的に聞け
  56. 頻繁に祈れ
  57. 祈りにおいては毎日己が神に対する罪に落涙嘆息し、かかる邪を将来に償うことを思え
  58. 肉の欲望を満たすなかれ
  59. 己が意思を憎め
  60. 神が権威を託した者の命にすべて従え。たとえ権威者が自ら率先せずとも従え(そは神の禁じたもうことなり)。主のかの言葉を思い起こせ「他人の言葉を汝行い、他人の行いを汝行うなかれ」と
  61. 己の至らぬのに聖人と呼ばわるることを望まずして、呼ばわるるところの聖人たらんとせよ
  62. 神の戒律を日々満たせ
  63. 禁欲を愛せよ
  64. 誰をも嫌うな
  65. 嫉妬羨望するなかれ
  66. 諍いを好むなかれ
  67. 傲慢を避けよ
  68. 目上を敬え
  69. 目下を愛せよ
  70. 汝の敵にキリストの憐憫を祈れ
  71. 日没までに汝の反対者と和平せよ
  72. 神の慈悲に悲嘆するなかれ

2018-10-22

江添誕生日ボドゲ会@10月28日

江添誕生日ボドゲ会@10月28日 - connpass

10月は誕生日なので週末の28日に昼からボドゲ会、夕方からすき焼き会をすることにした。参加表明はconnpassから行える。

2018-10-14

消費税について考えたこと

「消費税10%は100円が110円になると考えるのではなく、1000万円が1100万円になると考えるべきだ」というつぶやきを目にした。しかしこれは言っていることが同じだ。

私はむしろ、消費税とは手取りに対する税金ではないかと考えている。貯蓄をしない家計では、消費税は実質手取りに対する税金だ。貯蓄をしない家計にとって、消費税10%とは、手取り20万円が18万円になることだ。

もっとも、この考え方にも問題はある。というのも貯蓄をしない家計は賃貸住宅に住んでいるだろうが、不動産の貸付料である家賃には消費税はかからない。手取り20万円の家計で家賃6万円の場合、14万円が12万6千円になるということだ。

消費税と言えばイタリアは先進国だ。1973年という昔から12%の消費税を導入し、1997年には20%に引き上げられた。そのイタリアでは、表に出ず消費税を脱税した地下経済とマフィアが発展した。

消費税が10%ともなると、日本でも地下経済と、地下経済の信用取引を履行させるためのヤクザが発展するだろうか。

日本ではヤクザの人権を剥奪する法律によりヤクザの人口が急激に減りつつある。また個人間の送金手段は経済に悪影響を及ぼすほど厳しく規制しているので地下経済も発展しにくい。

とはいえ、消費税があまりにも高くなれば地下経済は発展するだろうし、地下経済が発展したならば、その信用取引を確実に履行させるための機関としてヤクザが必要になり、ミカジメ料を支払うようになるのでヤクザも再び興隆するだろうか。

ということを考えながら、消費税制度の解説を眺めていたところ、興味深い定義を発見した。

「郵便切手類、印紙、証紙、物品切手の譲渡は非課税取引」

興味深い定義だ。すべての取引が地下経済に潜ることはできない以上、我々は表の取引もする。であれば、一部の取引を切手や印紙による取引とするのは現実的ではないだろうか。素晴らしいことに地下経済にする必要すらない。単なる非課税取引をしたにすぎないのだから。

具体的に考えよう。君は牛を二頭持っている。今君は牛を一頭売る契約をしたので契約書作成の税金を収めるため収入印紙を貼る必要がある。君は残りの牛一頭のミルクを売って現金を得て消費税を払い、残りの現金で収入印紙を買う。もし、君がミルクと収入印紙を直接交換したならば、消費税を支払う必要はない。

すばらしい。我々は現金ではなく収入印紙で支払うことによって消費税を節税することに成功した。消費税を支払わない分、ミルクの値段を下げるか、利益を上げることができる。

こう考えると、消費税の存在は貨幣経済に対する足かせであるように思えてくる。

しかし収入印紙は日本国に対する支払いにしか使えない用途の限定された通貨だ。現金という汎用的な通貨ではない。この問題をどうすればいいのだろう。

収入印紙には需要がある。需要があるものは汎用的な通貨である現金と交換できる。例えば金券ショップでは、収入印紙は額面の95%ぐらいで交換できる相場だ。ところで今の消費税は8%である。収入印紙で取引して収入印紙を現金化した場合の損失が、消費税率を下回る場合、これは得をしたと言えるのではないか。しかも合法だ。つまり収入印紙での取引は合法的な節税になるのではないか。

私は経済学にも消費税制度にも詳しくないのだが、この解釈は正しいのだろうか。

2018-10-07

Steven WeinbergのTo Explain The Worldを読んだ

邦訳では「科学の発見」という題名がついているSteven WeinbergのTo Explain The Worldを読んだ。

著者のSteven Weinbergはノーベル物理学賞の受賞者でイスラエルの熱烈な支持者だ。

冒頭で「本書で筆者は過去を現代の基準で批判する愚を犯す」と書きながら、この本は科学がどのように発展してきたかを解説している。

本書はまず、古代ギリシャにおける万物を構成する元素の説について取り上げる。古代ギリシャの哲学者が、元素は水だとしたり、火だとしたり、水、火、土、空気の4種類だと主張している歴史を取り上げる。

ここまではまあいいとして、プラトンの提唱した説を取り上げて悶絶する。プラトンは四大元素である火、水、土、空気について、とても小さい元素が存在し、5種類ある正多面体をそれぞれ割り当てた。たとえば火は正四面体で、水は正二十面体といった具合だ。その仮説を立てるのはいいとして、割り当ては一体どういう理由で行われたのか。プラトンは単にそれが理想だからとしか語らない。

科学というものは、まず観測し、観測結果から仮説を立て、仮説が観測結果に従うことを検証するものだ。

しかし古代ギリシャでは、科学は科学ではなく哲学で、単に理想を追求するものでしかなかった。なので万物を構成する元素は元素は火や水といったわかりやすい理想的なものになり、元素は5種類ある正多面体であるとし、完全数を尊びといった、現実の観測結果より理想を追求し、理想が現実に従わないことは無視されていた。

その後、本書の大半は天体の運行の予測を通じた科学の発展に費やされる。

天体の運行には規則性があり、古代から占星学などの存在により、天体の運行を正確に予測する需要があった。

古代ギリシャ時代から地球が中心で月、惑星、太陽、その他の恒星は全て地球の周りを回っている説が主流であった。

古代ギリシャ時代にはすでに地球を中心とした天体の運行を予測する数式モデルが考案されていたが、他の天体はすべて地球を中心とした真円で回るなどと定義されていたため、現実の観測とは大いに異なっていた。しかも、それぞれの天体が謎の理由で割り当てられた正多角形に内接する真円で回るなどという、これまたプラトンのように理想を追求したモデルであった。

天体は地球を中心に真円で回転するモデルを使うと、惑星はある時期だけ逆方向に回りだしたりする。惑星が大抵の言語で語源からして、惑う星であるのも、これが原因だ。

そこでプトレマイオス説が考案された。この説では、天動説で現実の観測結果に近似させるために、あまりにも無理やりな天体のモデルを考案した。天体は太陽を中心に真円で回っている。この真円を従円と呼ぶ。天体は従円を線上を中心としてさらに真円で回っている。この真円を周転円と呼ぶ。

プトレマイオス説は複数の真円を組み合わせ、真円の大きさをパラメーター化することで、惑星の運行を現実に近似させることを試みた。その結果、かなりの制度で現実の観測に近似した天体モデルを作ることに成功した。

プトレマイオス説は科学だ。観測から観測結果に従う数式モデルを作ったわけで、これは科学と言える。

プトレマイオス説は哲学者からは理想ではなく天体の予測のための方便であるとされていた。天文学者(この時代の天文学者は占星学をかねる)は積極的に使っていた。というのも、プトレマイオス説は現実の観測結果の近似していて、予測に役立つからだ。

その後、様々な天文学者がプトレマイオス説により複雑な周転円を追加することで、さらに現実の観測結果に近づける努力が行われた。

太陽を中心として天体が公転している地動説は以前にも理想として提唱されたことはあったが、現実の観測結果を説明できる具体的な数式モデルはコペルニクスによってまず作られた。ただし、コペルニクスの数式モデルは精度が悪かった。というのも、コペルニクスは天体は太陽を中心に真円で公転していると定義したが、実際には太陽は中心ではなく、天体の公転軌道は真円ではないからだ。

本書は中東の科学についても解説している。中東の科学はイスラム教の普及によって妨害されるまでヨーロッパより進んでいた。ギリシャ時代の学説は中東からもたらされる形でヨーロッパに再発見された。その後イスラム教の普及により中東の科学の発展は阻害された。

そしてガリレオ・ガリレイの時代までやってくる。ガリレオ・ガリレイは優秀な望遠鏡を発明し、望遠鏡によって精密な天体観測をした。その結果地動説を唱えるわけだが、その上でパトロンであるローマ教皇を天動説を信じているなどと批判したので宗教裁判にかけられて地動説を封印する。後世に残る逸話によれば、このときガリレオは「それでも地球は回っている」とつぶやきながら法廷を後にしたと言われる。

宗教裁判の後、ガリレオは晩年まで自宅に軟禁状態におかれるわけだが、ガリレオの科学への情熱は冷めていなかった。ガリレオは落下する物体の速度について研究していた。落下する物体の速度を観測するのは当時としては難しい。というのも、速度が速すぎるために正確な観測ができないためだ。

ガリレオはこの落下速度の問題に対し、科学的な観測方法を考案する。緩やかな傾斜面を転がる球を使うことで速度の計測を可能にした。時間の計測には水時計を使った。傾斜角を変えることでガリレオは速度は傾斜角に比例することを示し、傾斜角を転がる球は落下速度の計測の代わりに使うことができることを示した。もちろん現実には、球と傾斜面の摩擦にもエネルギーが使われるが微々たるもので当時実現可能な観測方法としては十分なものだった。ガリレオは傾斜角を転がる球を机の端から飛ばし、その軌道が放物線であることも観測している。

本書はニュートンの説明に移る。ニュートンによって科学革命はクライマックスを迎えるわけだが、しかしこのニュートンという人物はなんという奇人だろうか。ニュートンは生涯、イングランドのごく狭い地域より外に出ることはなかった。ニュートンは潮の満ち引きについて多大なる関心を持っていたにもかかわらず、生涯一度も海を見ることはなかった。中年に至るまでニュートンは身近に女を寄せ付けることがなかった。母親とて例外ではない。50代になってから親戚の美しい娘を家政婦として雇っているが、この2人の間に男女関係はなかった。ニュートンは科学以外にも、非科学的な錬金術や宗教について多大な著作を残している。

ニュートンの研究者の間でよく言われることには、ニュートンは最初の科学者ではない。ニュートンは最後の魔法使いである。時代が魔法から科学に変わる節目の時期にあって、魔法から科学への橋渡しをした人物だ。

ニュートンの法則を記述したPrincipiaは、単に重力を説明し得たために偉大だというわけではない。ニュートンはPrincipiaによって、物理的現象は簡単な数学的原則と、その原則の応用で説明できることを示したのだ。

中国の悪意あるハードウェアの細工を見破る方法

中国で生産されているハードウェアに悪意あるチップが取り付けられておりAppleやAmazonが被害にあっているとする報道があり、真偽について議論がある。

これに関連して、Hacker Newsで興味深いコメントが寄せられていた。

I have worked in card payment industry. We would be getting products from China ... | Hacker News

俺はカード支払い業界で働いている。中国から送られてくる製品にクレジットカード情報を送信する装置が取り付けられていることがある。これは国家による攻撃ではない。装置は生産ラインの途中で取り付けられている。大抵は賄賂を受け取った従業員によるものだ。装置が組み立てられた後は、改造防止の機能が動くので、改造を検知させずに装置を分解するのは不可能だ。

この問題が発覚してから、我々は製品の重さを計測することにした。我々も製品を分解することはできないからだ。分解したならば改造検知により装置は動かなくなる。

攻撃者は重さの計測に気がついたので、製品内部の必須ではないプラスチックを引っぺがして装置を追加することによって増加した重さの調整をしてくるようになった。

結局、我々は特別な土台を使い製品の角運動量(訳注:慣性モーメントか)を計測するようになった。とても高価な装置で角運動量を計測する。俺が作った土台を使って2つの角度から角運動量を計測している。2つの製品の角運動量がどの角度からでも一致するならば製品は同一というわけだ。すべての角度から角運動量を計測できないが、今のところ破られていない。

角運動量ではなく慣性モーメントだろうという用語の甘さや、慣性モーメントは3軸を使って全角度を測定できるのではというツッコミが入っているが、この話自体はよくあるものらしい。

なんでそんな製造段階で悪意ある細工が混入した製品を送ってくるところと取引を続けるんだというコメントに対し、この製品を製造しているのは今や中国をおいて他にないとか、中国の商習慣では信頼を前提としない契約による取引に応じてくれないとか、中国と取引するには製品の欠陥は自前で発見できなければならない、発見できないのはマヌケな顧客であり欠陥品で十分だとみなされる、などの中国のお国柄を指摘するコメントが続いている。

2018-09-20

健全なP2Pネットワークの信用のためには全利用者の参加が必須であるという話

「Zaifが5966BTCやられたようだな」
「ククク、あれは後発取引所ゆえ保有量が最弱」
「85万BTCを溶かした余の足元にも及ばぬ」

また一つ暗号通貨の取引所が失敗した。人はいつになったら学ぶのだろうか。中央権威のないP2Pネットワーク上の信頼は、利用者全員が参加することでしか担保できぬと。

信じられないことに、暗号通貨の利用者の中でも、なぜ暗号通貨が信用できるか、というより暗号通貨の何を信用しているかを理解しているものは少ない。皆暗号通貨と日本円などの国家通貨の交換レートしか気にしていない。国家通貨との交換レートなど、暗号通貨の実現している技術的な価値に比べればチリほどの価値もない。暗号通貨の価値は、中央権威のない通信越しに偽造できない通貨の取引を実現したということにある。

問題を簡単にするために、暗号通貨とは違う例で考えよう。

アリスとボブが仕切りを隔てて音声による会話しかできない状況に置かれている。この状況で、アリスとボブはコイントスによる勝負をする。コイントスは投げたコインが表か裏のどちらを上にして落ちるかで勝敗が決まる。アリスが表で勝つのであれば、ボブは裏で勝つ。アリスが裏ならばボブは表で勝つ。

アリスとボブが賭ける表裏を音声による会話で選択したとして、一体どうやって信頼できるコイントスをすればいいのだろうか。アリスとボブのどちらか一方がコイントスをして結果を相手に伝える場合、音声による会話しかできないので、相手はコイントスの結果を信用できない。アリスとボブ以外に勝負の審判をしてくれる都合のいい第三者はいない。

実は、この状況でアリスとボブがどちらも信用できるコイントスを行うことは数学的に可能だ。

では問題を変えよう。ここに60億人の人間がいる。全員、音声による会話しかできない。60億人のうちのある一人のアリスが、ある一人のボブに自分の持っている通貨の支払いたい。支払った後のアリスは通貨を失い、ボブは通貨を得る。しかし全員音声による会話しかできないのに、どうやったらそんな取引が信用できるのだろうか。

これも、数学的に信用できる方法がある。bitcoinを始めとする暗号通貨が行っているのはこれだ。

信用を担保するには、60億人が全員同じ方法で数学的な計算を行い、不正がないことを確かめなければならない。もし、30億人と一人が不正のための計算に協力したならば、アリスが支払ったはずの通貨はアリスの手元に残り、ボブの手元には通貨がない常態にすることも可能だ。しかし、そのような参加者の過半数を超える大規模な計算は難しい。

ただし、この方法で信用できるのは、ある暗号通貨の取引だけだ。暗号通貨と日本円の取引とか、物の取引は暗号通貨の信用の範囲外だ。

残念ながら、世の中の暗号通貨利用者の大半はズボラで、自ら信用を担保することを考えていない。こういうマヌケ共は、自ら信用のための計算をせずに、取引所と呼ばれる他人に計算を任せる。本来ならば証明された数学と計算力を信用すればよいはずの暗号通貨を、他人の信用に置き換えてしまう。こうなるともはやその計算を任された取引所が権威となり、単一障害点になってしまう。その結果、取引所が失敗すると任せていた全員が失敗する。

人はいつ学ぶのだろうか。

そういえば、CloudflareがIPFSのゲートウェイを提供するという興味深いニュースがあったので、今はIPFSについて学んでいる。今学んだ限りでは、名前解決であるIPNSを除けば、IPFSが喧伝していることはBitTorrentプロトコルに対するフロントエンドで実装できそうで、あまり目新しい価値はないように思える。そして、Cloudflareのような大手がゲートウェイを提供し、皆が自前でフルノードを動かさずにゲートウェイに依存することで、健全なP2Pネットワークの信用が損なわれてしまうだろう。

2018-09-17

Linus、今までの行いを謝罪し一時的にカーネルメンテナーの立場を退いて人の気持ちを勉強してくると発言

完全に背景事情を調べ上げたわけではないのだが、どうもLinusが毎年参加しているLinuxカーネルの会議に、Linusがスケジュールを間違えて参加できなくなるという事態が発生した。当のLinus本人はもう20年も続いている会議だし自分がいなくてもやっていけるだろうと楽観視していたが、会議自体がLinusの都合にあわせてリスケジュールされた。

LinuxにおいてLinus Torvaldsといえば第一人者であり極めて重要な存在で、そのLinusが毎年参加している重要な会議にLinusが参加できないとあれば、その他のあらゆるコストを度外視して根回し調整を行い、Linusが参加できるようにイベント全体のリスケジュールを行うのは人間の感情から考えて当然である。しかし当のLinus本人は他人の感情が読めず、そこまでの大事になるとは考えていなかった。その認識の差が今回の騒動に発展した。

Linux 4.19-rc4 released, an apology, and a maintainership note - Linus Torvalds

[ その他の長々しい話 ]

いつもの発表とは違う先週のことについて。メンテナーとカーネルコミュニティについての、公になっているカーネルサミットによるものと様々なプライベートなやり取りの議論について。議論の一部は俺がメンテナーサミットのスケジュールを間違えたから起こったわけだが。

こういう議論は今週になって初めて始まったわけでもない。メンテナーとコミュニティについては長年議論してきたわけだ。プライベートでもメーリングリストでもたくさん議論されてきた。カンファレンスでも毎回トークがあるし、これも、一般向けのものと、廊下を歩きながら話す種類のものがある。

先週がいつもと違ったのは、俺の反応と、俺が反応しすぎたためだ(判断は読者に任せる)

要するに議題は2つある。

ひとつは俺がメンテナーシップサミットのスケジュールでヘマをやらかしたことに対する俺の反応だ。いや、実際日付を間違えたのは失敗だったが、でも正直なところ、俺がここ20年ぐらい参加していたカーネルサミットに今回ぐらい参加しなくてもいいんじゃないかと思っていたのだ。

実際には、サミットがリスケジュールされたし俺の「俺なしでもやれるんじゃない」って意見は覆されたわけだ。だがこの状況が別の議論の呼び水になった。これが議題の2つめにかかってくるわけだが、俺は気がついたんだよ。俺って人の気持ちが読めないんじゃないのってことに。

要するに「鏡で自分の顔を見てみろよ」って瞬間だな。

というわけで、俺がついに気がついたこととして、俺が毎年のカーネルサミットを今回ばかりパスするのは面白くもないしいい兆候でもないってことと、俺は今の今までコミュニティの気持ちを汲み取れていなかったということだ。

何というかな。無視できるってものは、だいたい俺が首を突っ込みたくないものなんだな。

これが俺という人間の現実だ。俺は他人の感情を読み取るのが得意ってタイプの人間じゃないし、そのことはみんなも当然気がついていただろうから驚きはないだろう。俺以外はな。俺が長年、他人の気持ちを読み取れずにいて、大人でない環境を作り出していたってのは良くないことだ。

今週、コミュニティ内の人間は俺が人の感情を理解できていないということについて批判してきた。俺の反論は大人気なかったし良いものでもなかった。特に俺個人の問題としたことについてだ。俺がよりよいパッチを追求することについて、これは俺の中では当然のことだ。これはどうもよろしくない態度だと気がついたわけで、正直すまんかった。

こうくどくど書き連ねているのはつまり俺が誤りを認めて、おいおい、お前は態度を改めなければならんぞ、という辛い思いをかみしめているのであって、俺の態度で気分を害したりカーネル開発から抜けてしまった人間にあやまりたい。

ちょっとここらで休みを取って、他人の感情を理解する方法と、適切な応対の方法について、誰かから学んでくる。

別の視点で考えると、カンファレンスに呼ばれた時、俺はよく、カーネル開発の厄介な問題点はたいてい技術的な問題ではなくて、開発フローと態度の変化の問題なのだというトークをよくする。

この厄介な問題点というのは、パッチを管理する方法とか、やり方の大規模な変更とかだ。「パッチとtar-ball」によるリリース(15年前に「Linusはスケールしない」という厄介な議論が持ち上がった原因)から、BitKeeperを使う方法に変わり、それも無理になってきたのでgitを使う方法に変わった。

そういう厄介な問題点は、ここ10年ぐらいなかったわけだ。だが今週、それに匹敵する厄介な問題点が見つかった。

これを4.19-rc4のリリースに結びつけると(いや、実際関係しているのだが)、4.19はなかなかよいものになると思うよ。このリリースサイクルは「落ち着いた」期間になるし、Gregに話はつけておいたので、Gregが4.19を取り仕切ってくれる。その間に俺が休みを取って、俺の態度について修正してくるわ。

これは「俺はもう燃え尽きた。もう逃げ出したい」っていう休みじゃない。Linuxのメンテナーを辞めたいなどとは思っていない。実際逆だ。俺はこの30年近く関わってきたプロジェクトをまだ続けたい。

これは前にもあったように、"git"という小さなツールを書くためにカーネル開発をちょっと停止するひつようがあったように、今回もちょっと休憩して、誰かに手伝ってもらって、態度を改め、俺のツールとワークフローの問題を修正するということだ。

実際のところ、修正の一部はツールで解決できるかも知れないのだ。例えば、メールフィルターをかまして、俺が罵詈雑言を含むメールを送信しようとしたら差し止めるとか。ほら、俺はツールの信者だからさ、一部の問題は、簡単な自動化で防げるかもしれないだろ。

俺が本当に「鏡を見た」とき、明らかに俺に必要なのは変化だけではないわけだが、いや、ほら・・・何か提案があったらメールで送ってくれよな。

メンテナーサミットで会えるのを楽しみにしているよ。

Linus

2018-09-10

TempleOSの作者Terry Davisが列車に引かれて死んだ

Man killed by train had tech following | The Dalles Chronicle

Man killed by train had tech following By Neita Cecil As of Friday, Septem - Pastebin.com

両親と喧嘩をして勘当され路上生活をしていたTerry Davis(Terrance Davis)が8月11日に列車に引かれて死んだことが確認された。享年48歳。

Terry DavisはTempleOSの作者だ。

TempleOS

読者の多くはTempleOSを知らないだろう。TempleOSとはx86-64 Ring-0上で動作するOSだ。プロセス分離はなく、メモリ保護もなく、そもそも仮想メモリではなく物理メモリアドレスを直接使うOSだ。コンセプトは古き良きCommodore 64の現代版だ。あの頃のPCはメモリアドレスは直接メモリアドレスであって、仮想メモリによってどこか不定の物理メモリアドレスにマッピングされたりなどしなかった。

TempleOSはキリスト教の影響を受けておりキリスト教の聖書やキリスト教に由来するゲームが多数入っている。

TempleOSはHolyCで書かれている。HolyCはC言語に似た文法を持っている。TempleOSのシェルはHolyCのJITコンパイラーになっていて、シェルに書き込むと、HolyCがJITコンパイルされ実行されるようになっている。

作者は統合失調症を患ったOS開発者で、大抵のインターネット上のフォーラムからは出禁の扱いを受けていた。なぜならば、Terry Davisの発言には必ず人種差別と罵詈雑言が含まれていたからだ。彼にとってほとんどの人間は「ニガーでCIAのスパイ」だと認識されていた。

Terry Davisは統合失調症の症状が強く現れてからは職を辞め、両親と同居して、キリスト教の神の神殿をコンピューター上に再現するTempleOSを開発していた。

何年もそういう状況であったが、2017年に両親とだいぶひどいいさかいを起こし、ホームレスになっていた。

ホームレスになった後も定期的に動画が上がったりなどして生存が確認できていたが、ここ最近、死亡説が噂されていた。それが確認されたことになる。

悲しい

GitHubからDXVKレポジトリが消失

GitHubのDXVKレポジトリが500を返すようになった。

https://github.com/doitsujin/dxvk

DXVKはDirectX 10/11の自由なVulkan実装だ。DXVKによってWineやProtonはDirectXの使われたWindows用ゲームをGNU/Linuxで実行することができる。DXVKにより不自由なMicrosoft Windowsはとうとうゲーム用OSとしても完全に敗北し、その座をGNU/Linuxに明け渡すことになる予定だが、どうしたことだろう。

DXVK github not found and valve's copy throws error? Whats happening? : linux_gaming

どうやら、DXVKの作者のGitHubアカウントが謎の理由でBANされたそうだ。

DXVK github not found and valve's copy throws error? Whats happening? : linux_gaming

作者によってすぐにGitLab上でDXVKが公開された。

Philip Rebohle / dxvk · GitLab

Redditでは「そういえばGitHubはMicrosoftに買収されるんだよな」というジョークが書き込まれているが、ジョークで済むだろうか。

追記2018-09-10 9:14: 復活した。

2018-09-03

江添ボドゲ会@9月8日

自宅ボードゲーム会を以下の要領で開催します。

江添ボドゲ会@9月8日 - connpass

2018-09-02

DNAの読み取りについてプログラマーが誤解していること

世の中にはDNAの読み取りを使った技術が実用されすぎている。DNAを使った生物の共通祖先の判定、人間の出アフリカ以降の移動の推定、特定の病気にかかりやすい遺伝子を持つかの判定、親子鑑定、刑事裁判におけるDNA鑑定などなど。

あまりにもDNAの読み取りを使った技術が実用化されすぎているため、世間ではDNAの読み取りは簡単なものだと考えている。プログラマーとて例外ではない。

大抵のプログラマーはヒトDNAの読み取りを以下のように考えている。

「一本の長い磁気テープを先頭から末尾までシーケンシャルにリードする」

より現実的に例えると以下のようになる。

  • 長さ30kmの長大な磁気テープをだいたい長さ1cmのテープ片に切断する
  • 上記1cmのテープ片を数百本複製する
  • 上記複製した数百本の1cmテープ片をマイクロメートル単位のテープ片にズタズタに切り裂いて混ぜ合わせる
  • 上記混ぜ合わせたマイクロメートル単位のテープ集合からランダムでテープ片を手当たりしだいに読み込み、組み合わせパズルを解いて元の1cmの磁気テープ分の正しいデータ配列を決定する
  • 残りの29.999999kmのテープについても同様に1cmづつ処理する

マイクロメートル単位のテープ片をランダムに読み取って組み合わせパズルを解き、元の1cmのテープ分のデータ配列を決定するのはソフトウェアにより実装されている。読者はそのようなパズルを解くプログラムをバグなしで実装できるだろうか。

ただし、より例え話を現実に近づけると、1cmのテープ片をマイクロ単位のテープ片に切り裂くのはランダムではない。この1cmのテープ辺には数百-2ビットから数千-2ビット程度のデータが記録されている。テープをマイクロメートル単位に切り裂くカッターは、テープの末尾の2ビットの値がn回目に出現したmであるときに切断するという条件付きカッターだ。これにより、00, 01, 10, 11のいずれかの2ビット値の1回目の出現、2回めの出現、3回目の出現といった単位でテープをカットできる。

マイクロメートル単位のテープ辺を読むリーダーはあまり融通が聞かない。すでに読んだテープ辺と同一内容のテープ編を何度も読み込むことになるし、同一内容のテープ辺は同じ回数読み込まれるわけではない。読み込みエラーが発生して任意の2ビットが別の値になってしまうかもしれない。なのでできるだけ何度も読み込み、まれにしか現れない異端データを読み取りエラーと判断して除外する処理も必要だ。

これを考えると、プログラマーとしての私は、DNA読み取りを使う技術が信頼できなくなってしまう。私のDNAを読み取った結果、特定の病気になりやすい遺伝子が含まれているとか、ある人物と親子関係にあるとか、犯行現場に残されていたDNAと一致したなどと言われても、その結果は信頼することができない。なぜならばDNAを読み取るという処理が極めて大雑把で信頼できない確率的な統計処理だからだ。

現実のDNA読み取りはどうしているかと言うと、30億塩基配列ほどあるヒトDNAを、数百塩基から数千塩基のサイズに分割し、たまたま高温に耐える都合のいい細菌から得たDNA複製酵素と一緒に容器の中に放り込み、定期的に温度を上げ下げする装置を使い、ポリメラーゼ連鎖反応を起こしてDNA片を複製する。そして特定の塩基配列に対してのみ反応してDNAを切断する酵素を使い、n回目に4種類ある塩基(アデニン、グアニン、シトシン、チミン)の特定の一種類が現れたDNAをそこで切断させる。そうやって切断されたDNA片を片っ端から読み込み、組み合わせパズルを解く。

実際、アメリカではDNA鑑定の結果が証拠として信頼できないとして、DNA鑑定に使われたソフトウェアを検証するために開示請求がなされたこともある。

せめてプログラマーだけでもDNA読み取りの正しい理解をしてほしいものだ。

ssh経由のtmuxの中で動くvimのウインドウサイズ変更にマウスを使う方法

私はマウスが好きだ。

30行以上、100列以上の文字が表示できる端末を使っている私にとっては、マウスは必須である。画面上に表示される任意の1文字にカーソルを合わせたい場合、キーボードだけでカーソルを移動させるのはとてもつらい作業である。一方、マウスならばその場にカーソルを動かすだけでよい。

端末を分割して複数の画面にする時、それぞれの画面のサイズをその場で微調整するには、キーボードで画面サイズの数値を指定するよりは、やはりマウスで直感的にドラッグしたい。

例えばvimだ。以下のようにすると

:set mouse=a

Vimはマウスを扱えるようになる。端末の任意の文字にカーソルを合わせるのにマウスを使えるのみならず、マウスでスクロールやマウスで範囲選択もできる。

Vimは画面を複数のWindowに分割できる。

:split
:vsplit

このとき、マウスを有効にしているとウインドウの枠をドラッグすることでサイズを直感的に変更できる。

tmuxも重要なソフトウェアだ。

tmuxは.tmux.confに以下の設定をすれば、

set -g mouse on

マウスを使えるようになる。マウスでスクロール、範囲選択ができるし、

Ctrl-b "
Ctrl %

で作ったtmuxのpaneのサイズもドラッグで直感的に変更できるようになる。

ところが、tmuxのなかで実行したvimのウインドウのサイズをマウスで変更できないことに気がついた。

調べた結果、これは.vimrcに以下のように書き込めばできる。

set mouse=a
set ttymouse=xterm2

どうやらxterm2にあるドラッグ中もマウス入力を通知し続ける機能を使うそうだ。tmuxも対応している。

これで問題は完璧に解決したと思ったが、もう一つ問題に出くわした。ssh先のリモートで実行したtmuxの中で実行したvimではマウスによるウインドウのりサイズができない。

これは.tmux.confに以下のように書けばできる。

set -g mouse on
setw -g alternate-screen on

man tmuxをみるとデフォルトでonになっているはずだが、なぜかUbuntu server 18.04ではonになっていないようだ。

これで以前からやりたかったssh越しにも違和感のまったくない環境を作ることができた。

2018-09-01

ポータブルオーディオプレイヤーは二極化している

今のポータブルオーディオプレイヤーは二極化している。格安のゴミみたいな製品と、オーディオフィリ向けのクソみたいな製品があり、その中間がない。

最近、減量のためにジョギングを再開した。ジョギングは一回あたり1時間ほど行うのだが、これが思いの外ヒマだ。この時間を有意義に使いたい。走っている最中にできることは音を聞くぐらいなものだ。音楽に興味はないが英語の朗読を聞くのは有意義なことのように思われる。例えば筆者はまだシェイクスピアのハムレットを読んだことがない。ハムレットを読むには時間がかかるが、ジョギング一回あたりの1時間を使えば、何度か走るだけでシェイクスピアを通して聞くことができる。

そこで早速、ジョージ・オーウェルの1984やシェイクスピアのハムレットを朗読した自由な録音をダウンロードした。

LibriVox

元々が低音質なソースであるのだから、それほど高級な製品はいらない。そこで、アマゾンでよく購入されていた適当な格安ポータブルオーディオプレイヤーであるAGPTEK A01Tと、格安BluetoothイヤホンであるSoundPeats Q30を購入した。

さっそくハムレット朗読のmp3ファイルをコピーするが、なぜか再生の順序がファイル名の文字列順にソートされない。どうやら、FAT32のファイルのディレクトリーエントリーの順番で再生されるようだ。そこで仕方なく、以下のようにして問題を解決した。

ls | while read file ; do mv $file path-to-mp3-storage/$file

いざ聞いてみると、今度は片耳にしか音が聞こえてこない。どうやらこの格安ポータブルオーディオプレイヤーは、モノラルmp3ファイルに対して片耳しか出力しないようだ。残念ながらモノラルmp3ファイルを再エンコードなしでステレオにすることはできないので、以下のようにして無駄にステレオにした。

ls | while read file ;< /dev/null do ffmpeg -i $file -ac 2 -b:a 320k path-to-mp3-storage/$file

当初動かずに困惑したが、ffmpegが標準入力を食べてしまうことが原因だった。

そしてGNU Parallelを使ったほうがよかったことに実行した後に気がついた。

mp3のエンコード速度はそれほどパフォーマンスを重視していない私のラップトップでも175倍速だった。たしか私がmp3プレイヤーを使っていた15年ほど前はせいぜい20倍速に満たない程度だった気がするのだが、いい時代になったものだ。私の一つ上の世代は、mp3をリアルタイムデコードするためにCPUをオーバークロックしたと聞く。

本の朗読を聞くために買ったのだからあまり期待はしていなかったものの、この格安ポータブルオーディオプレイヤーはあまりにもひどい品質だ。おまけに、文字コードの対応もひどい。どうやらいまだにUCSに対応していないらしく、本体の言語設定をした文字に引きづられる。例えば言語をEnglishに設定するとASCII以外が文字化けし、日本語に設定するとシフトJIS外の文字が文字化けするようだ。これは解せない。ファイルシステムであるFAT32はファイル名をUCS-2で管理しているのだから、文字化けを起こすのはわざわざ何かとてもバカなことをしているとしか思えない。

不思議なことに、このポータブルオーディオプレイヤーにはFMラジオとかテキストリーダーとか万歩計とか録音とか動画再生などの様々な機能がありながら、ファイル名によるソート機能すらない。

ではもっとマシなポータブルオーディオプレイヤーはないものか。実は今ポータブルオーディオプレイヤーは二極化しているのだ。

ひとつには私が買ったような数千円で変えるクソのような格安の粗悪品。もう一つには、最低数万円から数十万円もするようなオーディオフィリ向けのバカのような高級品だ。中間層の市場はスマフォが完全に支配してしまったため、ポータブルオーディオプレイヤーは格安と高級品に二極化してしまったのだ。

では高級なポータブルオーディオプレイヤーとはどのようなものだろうか。安いものでも数万円から、高いものになると30万円ぐらいする。30万円だ。嘘ではない。本当だ。曰くハイレゾ、曰く超高性能DAC、曰くUSB Audio/DACに両方とも対応。厳選された高性能で高品質なキャパシタ、コイル、メッキなどなど。

ちょっとまってもらいたい。人間の可聴域は若者でもせいぜい20kHz程度であり、だからこそせいぜい40KHzのサンプリング周波数で20kHzまでの音を再現できるようにしているのだ。ハイレゾに意味はない。USB Audioに対応しているのはともかくとして、なぜUSB DACとして使える必要があるのだ。そして高級なキャパシタやコイルに至っては完全にオーディオフィリの領域だ。

5000円ぐらいでまともなUIを備えたポータブルオーディオプレイヤーはないものか。そもそも格安プレイヤーにすらいらない機能が多すぎる。必要なのはファイル名によるソート、シークバー、Bluetoothだ。自由にプログラミングできればなおよい。

という愚痴を漏らしていると、物好きな同僚がRaspberry Pi Zero WHを進めてきた。初代Raspberry PiのSoCを使い、WiFiとBluetoothが搭載された低電力なボードだ。Raspberry Piはその普及によって圧倒的に自由なソフトウェアスタックを得た。その性能はmp3やoggのリアルタイムデコードを難なくこなせるであろうし、Bluetoothも使える。しかも値段も2千円程度。確かに理想的なポータブルオーディオプレイヤーのように思える。

問題はUIをどうするかだ。タッチパネル付きのディスプレイをつけるのが一番いいように思える。考えてみよう。

2018-08-23

Steam Playで不自由なWindows用ゲームをGNU/Linux上で実行するにはPython 2が必要

Steam Playが発表されたので、早速使ってみた。

Steam PlayというのはWineからforkしたValveのProtonを使ったGNU/LinuxでWindows用ゲームを実行する機能だ。なぜWineをforkしているかというと、ProtonではWineにまだ入っていない変更を使っているからだ。例えばDirectXをVulkanで実装したdxvkや、同期処理をユーザースペースで行うValveが開発したWineに対するパッチesyncを使っている。

https://github.com/ValveSoftware/Proton

Steam Playを使うには、まずSteamクライアントのSettings→Account→Beta participationからSteamクライアントBetaを使う設定であるSteam Beta Updateに切り替え、Steamクライアントをアップデートする。

すると設定にSettings→Steam Playが追加されているのでこれを有効にする。Valveが検証したゲーム以外のすべてのゲームでSteam Playを有効にするには、その設定項目のEnable Steam Play for all titlesを有効にする。これでGNU/LinuxのSteam クライアントでもWindows用ゲームがインストール、実行できるようになる。

ここまではSteamクライアントで必要な変更だ。GNU/Linux側でも必要な用意がある。Steam PlayにはVulkanに対応したかなり最新のグラフィックスタックが必要になる。

詳しい内容は

https://github.com/ValveSoftware/Proton/blob/proton_3.7/PREREQS.md

に書いてある。

NvidiaのGPUを使っている場合は、不自由なバイナリブロブドライバーを396.51以上のバージョンにしなければならない。Ubnuntu 18.04のドライバーはLatest Long Lived Branchである390を使っているので、最新のバージョンをインストールしなければならない。

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt install nvidia-driver-396

AMDとIntelのGPUを使っている場合は、最近のMesaとLLVMをインストールしなければならない。

sudo add-apt-repository ppa:paulo-miguel-dias/mesa
sudo apt dist-upgrade
sudo apt install mesa-vulkan-drivers mesa-vulkan-drivers:i386

AMDでVRゲームを実行する場合は、以下のパッケージが必要だ。

sudo add-apt-repository ppa:kisak/steamvr4pk
sudo apt dist-upgrade
sudo apt install linux-generic-steamvr-18.04

現在、IntelのGPUによるVRゲームはサポートしていないそうだ。

DirectX 11を使ったゲームを実行するには、NVIDIA 396.51以上、もしくはMesa 18.1.xが最低でも必要だ。LLVM 7も推奨されている。

OpenCLを使ったゲーム(DOOM 2016, Google Earth VR)を実行するには、Mesa 18.2.x以上が最低でも必要になる。

一部のディストロでは1プロセスあたりのfd limitが低いので、これを変更しなければならない。4096は1990年台には妥当な値ではあったかもしれないが、この2018年には少なすぎる。DebianとUbuntuでは上限が引き上げられているので問題はないそうだ。

そして最後にとても重要なソフトウェアをインストールする。Python 2だ。

sudo apt install python-minimal

こともあろうかこの2018年にProtonとgit submoduleしているffmpegがpython 2に依存している。

これでSteam Playを使う用意が整った。いくつかのWindows用の不自由なゲームを実行してみたが、いずれもよく動いている。

GNU/Linuxにおけるゲームは卵が先か鶏が先かという問題に直面していた。ゲーム開発者はGNU/Linuxゲーマーの需要がわからないのでGNU/Linux用のゲームを出さず、GNU/Linuxユーザーは対応しているゲームが少ないので仕方がなくWindowsかWineを使うので、結果として潜在的なGNU/LinuxゲーマーはWindowsゲーマーとしてカウントされてしまう。するとゲーム開発者はGNU/Linuxゲーマーの需要がわからないというデッドロック問題だ。

Steam Playによるゲームの実行は、GNU/Linuxユーザーとしてカウントされ、ゲーム開発者に通知されるしSteamの統計にも出る。これにより我々GNU/Linuxゲーマーの時代が訪れる。Microsoftの不自由で不便で非効率的なWindowsは最後の砦であったゲーム環境としても滅ぶのだ。未来は明るい。

2018-08-14

江添ボドゲ会@8月18日

江添自宅ボドゲ会を以下の要領で開催します。

江添ボドゲ会@8月18日 - connpass

2018-08-12

違法な職務質問を受けたので国賠訴訟を起こした裁判の傍聴のお知らせ

私の裁判の傍聴をしたいという人が何人かいるので、ここで証人尋問の傍聴の告知をしておく。

  • 日時: 2018年9月19日 水曜日 13時30分から16時頃まで
  • 場所: 東京地方裁判所631号法廷

傍聴をするためには、指定の日時の少し前に東京地裁に行き、金属探知機のある入り口を通過し、そのままエレベーターで6階まで上がって時間通りに631号法廷に行くだけだ。特に予約や手続きは必要ない。また、途中退出してもよいそうだ。

裁判の内容だが、私は約1年前に警察官から違法な職務質問を受けたので東京都を相手に起こした国賠訴訟だ。

本の虫: 警察官に職務質問をされた話

本の虫: 濫用に当たる職務質問を受けたと考えたので弁護士に相談して訴訟を起こすことになった話

裁判を起こすことになって初めて知ったのだが、警察というのは地方自治体の行政であるので、東京都内で生じた警察の行為について裁判を起こす場合、被告は東京都になる。

裁判は公開かつ口頭で行われるということになっているが、その実態としては、口頭で話すべき内容をすべて書面にまとめておき、あらかじめ裁判所に提出する。書面にすべてがまとめられているので、実際の期日に物理的な裁判所でやることはほとんどない。

実際に裁判所で行われる「儀式」は以下のようになる。

裁判官「原告/被告からは準備書面が提出されていますが、これは?」
原告/被告「陳述します」
裁判官「では次回期日ですがX月Y日のZ時からでは?」
原告/被告「その日は差し支えです/大丈夫です」

事前に提出した書面について「陳述」する宣言と、証拠の原本の確認と、次回期日を決めることしかしていない。

このようなやり取りが数カ月に一回発生するのが裁判だ。1回あたり5分から10分で終わる。この裁判の傍聴もできるのだが、傍聴しても退屈なので、これまで特に案内はしてこなかった。

今回は証人尋問が行われる。証人は原告である私と、職務質問の最初から最後まで現場にいたという警察官だ。当事者ではない第三者が傍聴して退屈ではない裁判というと、まず証人尋問だろう。

ところで、今回の裁判で気になる点としては、裁判官が頻繁に交代することだ。前々回でいきなり3人全員が同時に交代したかと思ったら、前回はさらに2人同時に交代した。裁判官の一部が交代するのはよくあることだが、それでも普通は一人ぐらいは最初から最後まで同じ裁判官を残すものだという。さもなければ、判決を書く裁判官はこれまでの裁判の口頭弁論も証人尋問も直接聞かず、書面だけで判断することになるからだ。一人でも最初から担当していた裁判官が残っていればその裁判官が物理的に見ているわけだから、その裁判官が知っているということにできるが、3人同時に交代してしまってはその手法も使えない。

今後の想定としては証人尋問を経て年内には判決が出る見込みだそうだ。

2018-07-31

GCCのgit移行が難航中

GCCはgitへの移行を計画しているが、GCCの既存のsubversionレポジトリをgitレポジトリに変換する作業が難航している。

GCCの移行作業を検証しているのは他ならぬEric S. Raymond(ESR)だ。

ESRお手製の変換ツール、reposurgeonはsubversionからgitへの変換ができる。

Resource page for reposurgeon 3.44

しかしGCCは30年もの歴史を持ち、そのsubversionレポジトリも複雑だ。

ESRはGCCのためにreposurgeonのバグを潰し、勢い変換しようと試みたが、意外な障害に出くわした。メモリ不足だ。

GCC's Conversion To Git Is Being Held Up By RAM, a.k.a. Crazy DDR4 Prices - Phoronix

ESRの所有する64GBのメモリを詰んだマシンではメモリ不足で処理できない。そしてDDR4メモリの値段は高騰している。GCCのビルドサーバーに128GBのメモリを詰んだものがあるからそれを使わせてくれとか、reposurgeonをPythonからGoに移植すればメモリ消費量は減らせる可能性があるが移植は困難を極めるとか、ESRに投げ銭してメモリを買わせようなどと議論をしていたのが7月はじめ。

さて、今はメモリ以外の問題に出くわしている。

GCC's Conversion To Git Is Still Turning Out To Be A Massive Headache - Phoronix

どうもGCCの膨大で複雑な歴史を正しくgitで表現する方法について議論の余地がある他、変換結果が壊れることもある。問題を解決したいが、変換自体がとても遅いため、デバッグが困難だという。

https://gcc.gnu.org/ml/gcc/2018-07/msg00322.html

トンネル出口の明かりが見えたと思ったら対抗列車が突っ込んできやがった。

もう変換はほぼほぼ終わりだと思っていたのに。俺はtrunkとブランチすべてがクリーンに変換されるのを確認したのに。捨ててもいいことに同意した失敗ブランチただ一つを除いては。

後残っているのはexecute-permission propagationとかmid-branch deleteをどうするかという問題だけで、前者はすでに解決済みだし、後者も解決に取り掛かっている。最終的には年末には、たぶん8月とか9月には、完了できるはずだったのに。

そしたらこのザマよ。俺の最新の変換がtrunkで間違った結果を出しやがった。これは実際ヤバイ問題で、GCCレポジトリがあまりにも巨大すぎるので調査するのに時間がかかりすぎる。SVNダンプファイルをreposurgeonで読み込むだけで4.5時間かかるし、フル変換に9時間はかかる。レポジトリは俺が最適化を考えるのと同じぐらい早く増大しているぜ。

しかも悪いことに、クリーンな変換ができるコミットまで戻っても失敗する。たぶん俺がへんてこなブランチコピーの対処を実装した結果こうなってるんだと思う。

パーティーに遅れてやってきた奴のために説明してやると、Subversionのダンプファイルの処理シーケンスの解釈は単純で検証も楽だ。ブランチコピー操作を除いてはな。ブランチコピーが他の操作に及ぼす影響だけはマジで闇が深い。

Subversionのコードが何をすべきかっていう正しいセマンティクスは存在するわけだが、古のSubversion開発者が理解していたことは、今や失われている。ダンプフォーマットはまともにドキュメント化されていない。今の不完全なドキュメントが存在する理由は、他でもない俺が解析したからだ。でも俺のドキュメントも疑問だらけだし、その疑問にはSubversion開発者も回答できないできる。

なのでレポジトリを変換する際にブランチコピーに関連した謎の挙動に出くわすのはよくあることだ。普通、おれは問題のコミットをbisectして、

  1. ダンプを問題が再現する最小のセグメントに切り取る
  2. content blobsをsource commitを識別できるunique small cookiesに置換する処理を行って結果が正しいことを検証
  3. topological reduceしブランチコピーもプロパティ変更でもない無価値なコミットを除去し、結果が正しいことを検証
  4. 手動で不必要なブランチをreposurgeonで削除

いつもなら、俺は今頃、問題を再現できる割と小さめのレポジトリ(今までで200コミットを超えたことはない)を作ってる。デバッグレベルを上げて変換を観察し、何が起こっているのかを観察する。そして問題を修正し、問題を再現する最小例は新たなテストケースになるって寸法だ。

これによって、ダンプファイル解析を着実に改善していき、Subversionのコードがやっていることをより忠実にエミュレートしていく。簡単な仕事ではないが、エッジケースを埋めていくほど楽になる。今まではこれでうまくいってきた。

GCCレポジトリのサイズでは、この戦略がうまくいかない。軽く計算するだけで、bisect一回で最短でも18日かかる。現実的には一ヶ月近くかかるだろう。

つまり、現状ではゲームオーバーで負けたってことだ。GCCレポジトリはでかすぎる上に変すぎる。

この問題を現実的に解決するには、俺のツールはすっげー速くなる必要がある。だいたい桁違いに早くないといかん。

ハードウェア性能を上げるのは無理だ。シングルプロセスを1.3GHz以上にあげたコンピューターはこの世に存在しないし、問題は並列化できない。

ソフトウェアの変更でうまく行く可能性はある。俺はreposurgeonをPythonからGoに移植するということについて考えている。repocutterで実験してみたところ、{Python版の40倍高速化した。reposurgeonではそんなに高速化するとは思えないが、問題を現実的に解決できるぐらいには高速化できるだろうと踏んでいる。40倍の半分だったとしても、9時間のテストランが13分になるわけだから。

この計画の問題点は、GOに移植するのは困難を極めるってことだ。めっちゃむずい。どのくらい時間がかかるかわからんが数カ月単位でかかる。

GCCはどのくらい辛抱強く待つのか決める必要があるな。現状だと、今のソースツリーの状態をそのままgitにしていちからはじめるほうがマシかもしれん。歴史は記録だけに留めるとして。

2018-07-24

しないでマイクロソフトのスタイルガイドライン準拠の翻訳

マイクロソフトは将来的に買収する見込みのGitHubで.NETのドキュメントを公開している。ハロウィーン文書が公開された頃のマイクロソフトからは考えられないほど変わったものだ。

https://github.com/dotnet/docs.ja-jp

その中にある変数名の命名規則に関するスタイルガイドラインについて書かれたドキュメントの文章がおかしい。

https://github.com/dotnet/docs.ja-jp/blob/live/docs/standard/design-guidelines/names-of-type-members.md

しないで動詞または動詞句は、メソッドの名前を指定します。

しないで名詞、名詞句、または形容詞を使用してプロパティの名前を付けます。

しないで次の例のように、"Get"メソッドの名前に一致するプロパティがあります。

しないで後に"List"または"Collection"単数形の語句を使用する代わりに、コレクション内の項目を記述する複数形の語句でコレクションのプロパティの名前を付けます

日本語として極めて不自然な文章になっていて意味がわからない。

原文は英語で書かれている。

https://github.com/dotnet/docs/blob/master/docs/standard/design-guidelines/names-of-type-members.md

原文を確認するとようやく意味がわかる。

DO give methods names that are verbs or verb phrases.

DO name properties using a noun, noun phrase, or adjective.

DO NOT have properties that match the name of "Get" methods as in the following example:

DO name collection properties with a plural phrase describing the items in the collection instead of using a singular phrase followed by "List" or "Collection."

なるほど、"DO"を間違えて「しないで」と訳してしまったのだな。"DO NOT"も「しないで」と訳されている。翻訳する上で間違えて機械的に置換でもしたのだろう。原文の文章の形をなるべく維持したまま日本語に訳すならば、"DO"を「正:」、"DO NOT"を「誤:」とでもすればいいのだろう。ただ、その場合"DO NOT"を使った文中で代替案も示してしまっているのが問題なので、これはできれば原文自体を「すべきこと」と「すべきでないこと」に分割すべきだろう。

そして間違いが20日にissueで指摘された。

https://github.com/dotnet/docs.ja-jp/issues/118

そして土日を挟んで今日、マイクロソフトから正式に回答があった。

https://github.com/dotnet/docs.ja-jp/issues/118#issuecomment-407202477

こんにちは、@megascus

言語に関するフィードバックをお寄せいただきありがとうございました。

お寄せいただいたフィードバックの内容を Microsoft の言語チームで検証いたしましたところ、残念ながら、マイクロソフトのスタイルガイドラインに従わない という理由で、承認基準に完全には適合していないという結果になりました。

記事の品質向上にご協力いただき誠にありがとうございました。引き続きお客様からの貴重なフィードバックをお待ちしています。

敬具

Microsoft DOCS International Team

そしてissueはclosedされた。

ん? である。問題は日本語の翻訳にあるのであってソースコードのスタイルガイドラインとは何の関係もない。上記の日本語を読解できるだけの日本語能力があるならば容易に気がつくはずで、まるでBOTによってなされたような回答だ。

その結果、マイクロソフト用語では"DO"は「しないで」を意味するのだとか、マイクロソフト社内では"DO"と"DO NOT"は同じ意味を持つのだとか、Google翻訳のほうがよっぽどマシな翻訳をしてくれるとか、ユーモラスなコメントが並ぶことになった。

マイクロソフト用語を使うと以下のようになる。

DO fix the document which has a translation error.

しないで誤訳を含むドキュメントの修正

DO translate with MS style guideline conformance.

しないでMSスタイルガイドライン準拠の翻訳

押すなよ、絶対押すなよ(押せ)、というダチョウ倶楽部メソッドを久しぶりに思い出してしまった。

2018-07-13

NPMのESLintのパッケージにマルウェアが混入された問題

Postmortem for Malicious Packages Published on July 12th, 2018 - ESLint - Pluggable JavaScript linter

https://github.com/eslint/eslint-scope/issues/39

要約

2018年7月12日に、攻撃者がESLintメンテナーのnpmアカウントを不正利用し、悪意あるコードが混入したeslint-scopeとeslint-config-eslintパッケージをnpmレジストリに公開した。インストール時に、悪意あるパッケージがダウンロードされ、pastebin.comからコードを実行し、このコードはユーザーの.npmrcファイルの中身を攻撃者に送信する。通常.npmrcファイルにはnpmでパッケージを公開する際のアクセストークンが含まれる。

悪意あるパッケージのバージョンはeslint-scope@3.7.2 並びに eslint-config-eslint@5.0.2であり、すでに両方共npmから非公開になっている。このパッケージが使っているpastebin.comのリンクもすでに取り下げられた。

npmは2018-07-12 12:30 UTC以前に発行されたすべてのアクセストークンをrevokeした。この結果、この攻撃により不正に取得されたすべてのアクセストークンは利用不可能になっているはずだ。

アカウントを不正利用されたメンテナーはnpmパスワードを複数の他のサイトに使いまわしており、かつnpmアカウントに2段階認証を有効にしていなかった。

我々、ESLintチームは今回の出来事について謝罪いたします。この失敗を他のメンテナーは他山の石としてnpm全体のセキュリティを高めることを願っています。

影響を受けたパッケージ

  • eslint-scope@3.7、このスコープ解析ライブラリは他の有名な複数のパッケージから依存されている。これには古いeslintと最新のbabel-eslintとwebpackが含まれる。
  • eslint-config-eslint@5.0、これはESLintチームによって内部的に使われている設定用のパッケージであって、よそではほとんど使われていない。

独自のnpmレジストリを運営している場合、これらのパッケージから悪意あるバージョンを非公開にすべきである。npmjs.comレジストリはすでに非公開にした。

攻撃手法

攻撃手法の詳細についてはhttps://gist.github.com/hzoo/51cb84afdc50b14bffa6c6dc49826b3eを参照。

推奨

今回の事例から、我々はnpmパッケージメンテナーとユーザーが今後取るべき推奨事項をいくつか提案する。

  • パッケージメンテナーとユーザーは同じパスワードを複数の違うサイトに使いまわすことをやめるべきである。1PasswordやLastPassのようなパスワードマネージャーは使いまわさなくても済むような利便性を提供してくれる
  • パッケージメンテナーは2段階認証を有効にすべきである使い方のドキュメント。Lernaを使っているのであれば、ここも参照
  • パッケージメンテナーはnpmの公開権限を持つ人間を精査、制限すべきである。
  • パッケージメンテナーはauto-merge dependency upgradesを提供するサービスの使用に慎重を期すべきである。
  • アプリケーション開発社はlockfile(package-lock.json、もしくはyarn.lock)を使い、新しいパッケージの自動インストールを差し止めるべきである。

時系列

  • 問題発生前:攻撃者はおそらくメンテナーがよそで使いまわしたメールとパスワードが流出しているのを発見し、これを使いメンテナーのnpmアカウントにログインした。
  • 2018年7月12日早朝:攻撃者はメンテナーのnpmアカウントで認証トークンを生成した。
  • 2018-07012 09:49 UTC: 攻撃者は生成された認証トークンを使い、eslint-config-eslint@5.0.2を公開した、これには悪意あるpostinstallスクリプトが含まれ、このスクリプトはローカルマシンの.npmrcの認証トークンの取得を試みる。
  • 2018-07-12 10:25 UTC: 攻撃者はeslint-config-eslint@5.0.2を非公開にした。
  • 2018-07-12 10:40 UTC: 攻撃者はeslint-scope@3.7.2を公開した。これには悪意あるpostinstallスクリプトが含まれる。
  • 2018-07-12 11:17 UTC: ユーザーがeslint/eslint-scope#39"を投稿、ESLintチームに問題を通知。
  • 2018-07-12 12:27 UTC: pastebin.comにある悪意あるコードが貼り付けられたリンクが取り下げられた。
  • 2018-07-12 12:37 UTC: ESLintメンテナーから連絡を受けたnpmチームはeslint-scope@3.7.2を非公開にした。
  • 2018-07-12 17:41 UTC: ESLintチームはeslint-scope@3.7.1のコードをeslint-scope@3.7.3として公開した。これによりキャッシュは新しいバージョンを使えるようになる。
  • 2018-07-12 18:42 UTC: npmは2018-07-12 12:30 UTC以前に生成されたすべてのアクセストークンをrevokeした。

リンク

2018-07-11

C++20の汎用エイリアス宣言の提案

P0945R0: p0945r0: Generalizing alias declarations

提案に誤りが有りすぎる。

C++のドラフトに入る見込みが高そうな提案に、汎用エイリアス宣言がある。

C++では、名前に別名をつけることがよく行われている。

型はtypedef指定子やエイリアス宣言によって別名を付けられる。

typedef int type ;
using type = int ;

関数は転送関数を書くことにより、実質別名を付けられる。

int f( int x ) ;

int g( int x )
{
    return f(x) ;
}

ただし、値は完璧に転送できないし、関数のアドレスも異なるものになってしまう。

変数はリファレンスで別名を付けられる。

int x = 0 ;
int & y = x ;

非staticデータメンバーはストレージを消費せずに別名をつけることができない

enumeratorはconstexpr inline変数によって別名を付けられる。

enum { value } ;

constexpr inline auto flag = value ;

ただしinline変数は名前空間スコープでしか使えない。

名前空間は名前空間エイリアスにより別名を付けられる。

namespace a { }

namespace b = a ;

型テンプレートはエイリアステンプレートで別名を定義できるが、デフォルトテンプレートパラメーターまで再現しなければならない。

template < typename T, typename Allocator = std::allocator<T> >
using vec = std::vector<T, Allocator> ;

ただし、この別名は別のテンプレートとして解釈されてしまう。

コンセプトは別のコンセプトを定義すれば別名を付けられる。

template < typename T >
concept newConcept = oldConcept<T> ;

名前の種類によって別名を宣言する文法が異なるし、単なる別名以上の意味を持つものもある。

この提案では、別名の宣言をエイリアス宣言に集約する。


using alias_name = name ;

型は今までどおりだが、その他

 型、今までどおり
using type = int ;

// 関数
int f(int) ;
using g = f ;

// 変数
int x = 0 ;
using y = x ;

// 非staticデータメンバー
template < typename Type, typename Value >
struct map_node : std::pair<Type, Value>
{
    using std::pair<Type, Value>::pair ;

    using key = first ;
    using value = second ;
} ;

[]{
    map_node< int, std::string> n( 123, "123") ;
    n.key ;
    n.value ;
} ;

// enum

enum { value } ;

using flag = value ;

// 名前空間

namespace a ;
using b = a ;


// 型テンプレート

using vec = std::vector ;

vec<int> v ;

// コンセプト

using newConcept = oldConcept ;

だいぶすっきりする。とくに非staticデータメンバーがよい。

2018-07-10

C++に提案されている静的例外

C++に静的例外が提案されている。

[PDF] P0709R1: Zero-overhead deterministic exceptions: Throwing values

例外はそのパフォーマンスへの影響が懸念され、一部のC++プロジェクトではコンパイラーオプションによって例外自体が無効化されていた。

これは由々しき事態だ。というのも、例外は標準C++の機能の一部であり、標準ライブラリは例外の存在を前提にして設計されている。例外が無効化されているということは、それはもはやC++ではない。C++風の別言語を使っていることになる。

なぜ例外は忌避されるのか。例外のパフォーマンスが非決定的だからだ。例外の実装はスタックからの確保ではなくヒープからの動的なメモリ確保が必要で、例外のキャッチにはRTTIによる型情報の比較が必要だ。

ifとgotoによるエラー処理のパフォーマンス特性は決定的に見積もることができるが、動的メモリ確保のパフォーマンス特性は決定的に見積もることができない。非決定的なパフォーマンス特性を持つ処理は、例えば数ミリ秒以内に必ず処理を終えなければならないような状況で使うことはできない。

この提案では、従来の例外を動的例外とし、新たに静的例外を追加して、例外のパフォーマンスを決定的にする。

まず、静的例外では例外としてthrowできる型が制約を受ける。特別に用意した何らかのstd::error型を投げる。このerror型は内部的には整数型で、デストラクターを実行する必要がなく、サイズは最大でもポインター2つ程度を想定している。標準はこのような型をrelocatableな型として規定する。

この標準のerror型はstd::error_codeを拡張したようなクラスで、様々な一般的にエラーに用いられるカテゴリーわけされた整数を返すことができる。このerror型はC++の標準の例外型は数値で表現できるようになっているので、静的例外と動的例外は標準の範囲であれば相互に変換可能になっている。

静的例外を扱う関数、静的例外関数を追加する。静的例外関数は静的例外指定によって明示的に指定する必要がある。提案では仮に、thorwsキーワードを用いる文法を提案している。


string f() throws
{
    if ( is_error() )
        throw error::something ;
    else
        return "hoge"s ;
}

静的例外関数はあたかもnoexcept(fase)が指定されたかのように振る舞う。したがってnothrow系のtraitsもそのように振る舞う。

静的例外関数が例外を外に投げる場合、例外を従来のスタックアンワインディングを伴う例外の仕組みを使わず、戻り値で返す。つまり静的例外関数はunion { R ; E ; } + boolのような型を内部的に戻り値として返す。ようするにexpected<T,E>のような型と同等の機能を提供する型を返す。

静的例外というのはerror型の値に変換できる値を投げるthrow式のことだ。それ以外のthrow式は動的例外となる。

// 静的例外
throw error::foobar ;
// 動的例外
throw "error"s ;

静的例外関数のなかで静的例外がthrowされ、その関数のローカルに対応する例外ハンドラーがある場合、該当する例外ハンドラーにgotoでとんだものと同じ挙動をする。

 string f() throws
{
    try {
        // ローカルのcatchにgotoで飛ぶのと同じ
        throw error::something ;
    } catch ( error e )
    {
        // ここにgotoで飛ぶのと同じ
    }
}

静的例外関数のローカルに該当する例外ハンドラーがない場合、errorは戻り値として返される。そのため、上の関数は実際には、union { string ; error ; }という型とどちらのunionメンバーが有効かを示すbool値を返したものとみなされる。これは従来のreturnと同じ仕組みで実装できるので、パフォーマンス特性も決定的になる。

静的例外関数が別の静的例外関数を呼び出し、静的例外によるerror型が返った場合は、その場で静的例外がthrowされたものとみなして処理する。

string f() throws 
{
    // 内部的にはerrorがreturnされる
    throw error::something ;
}

string g() throws
{
    try { return f() ; }
    catch( error e )
    {
        // ここにgotoで飛ぶ
    }
}

静的例外関数の中で従来の動的例外が投げられた場合、それが直接throw式で投げられたにせよ、呼び出した関数を通じて間接的に投げられたにせよ、直ちにその場でキャッチされ、適切な例外ハンドラーが選ばれる。

string f() ; // 非静的例外関数
string g() throws ; // 静的例外関数

string h() throw
{
    try {
        auto a = f() ;
        auto b = g() ;
        return a + b ;
    }
    // 静的例外
    catch( error e )
    {
    }
    // 動的例外
    // 従来の非決定的なパフォーマンス特性を持つ
    catch( std::bad_alloc e )
    {
    }
}

もし、静的例外関数から従来の動的例外が投げられ、関数の中に該当する例外ハンドラーがない場合、例外の型がerrorであれば静的例外としてreturnされ、それ以外であればstd::exception_ptrで束縛されてreturnされる。

string fail()
{
    throw "always error"s ;
}

string f() throws
{
    return fail() ;
}

この関数fは、string型をstd::exception_ptrで束縛してreturnする。

std::exception_ptrはC++11から追加された例外のオブジェクトを束縛できる機能だ。もう7年前の大昔に追加された機能なので読者は当然知っているはずだ。

呼び出した静的例外関数がstd::exception_ptrをreturnした場合、その場でただちに例外オブジェクトが取り出され、例外処理が行われる。もし例外オブジェクトがerror型の場合は静的例外が、そうでない場合は動的例外として処理される。

一部のC++の標準例外は、error型に変換される。例えばstd::bad_allocはerror型である(名前は仮のものだが)std::errc::ENOMEMに変換される。

非静的例外関数が静的例外関数を呼び出して例外を受け取った場合、もしerrorに対応するstd::exception型(たとえばerrc::ENOMEMからstd::bad_alloc)があるならば型を変換して動的例外がthrowされる。std::exception_ptrの中身がerror型の場合は取り出してerror型がthrowされたものとして処理される。それ以外の例外は動的例外がthrowされる。

string f() throws
{
    // 動的メモリ確保に失敗するコード
    // return std::errc::ENOMEM ; と同じ
    string s( std::numeric_limits<std::size_t>::max(), 'x') ; 
    return s ;
}

string g()
{
    // throw std::bad_alloc; と同じ
    return f() ;
}

この提案は従来の動的例外と組み合わせて使えるパフォーマンス特性が決定的な、つまりifとgotoを使うのと全く変わらないエラー処理を、例外の文法で実現する、静的例外を提案するものだ。これによりゼロオーバーヘッドの原則を満たした例外が扱えるようになる。

興味深いので入ってほしい。例外はすべてのC++で有効化されるべきだ。例外の使えないC++はC++風の別言語なので、利用者が分断されてしまう。 

2018-07-06

江添ボドゲ会@7月15日

以下の要領で7月15日に自宅でボドゲ会を開催します。

江添ボドゲ会@7月15日 - connpass

2018-07-05

プロフェッショナルIPv6の執筆経緯が興味深い

「プロフェッショナルIPv6」が出版されるそうだ。

すごいIPv6本を無料配布!:Geekなぺーじ

この本の執筆経緯が面白い。クラウドファンディングで金を集めている。

すごい技術書を一緒に作ろう。あきみち+ラムダノート『プロフェッショナルIPv6』 | クラウドファンディング - Makuake(マクアケ)

クラウドファンディングでは結果的に400万円ほど集まったそうだ。これはラムダノートと著者の連名のクラウドファンディングなので、著者の総取りというわけでもないだろうが、それにしても400万円は現代の技術書としては異例だ。

技術書とカネの話をしようと思う。私自身、技術書を出版してカネを得た経験がある。

技術書一冊の相場は数千円だ。売上一冊あたりの著者の収入は数百円だ。では著者が数百万円を稼ぐためには何冊売ればいいのだろうか。1万冊だ。問題は技術書で1万冊も売れる本は稀だということだ。1万冊売れる本というのは、技術書と言うよりはド素人に技術の仕組みをやんわりと教える本だ。詳細な解説をすればするほど、技術書は売れなくなっていく。千冊も売れればいいほうだろう。結果として、参考書を執筆して著者が得られるカネというのは数十万円だ。これでは経費を差し引くと給与所得者が確定申告に必要な雑所得の20万円すら下回る程度の利益しか得られない。そもそも技術書を執筆するためのまともなPCは数十万円するので、数年に渡って分割して経費にしなければならず、一台PCを買うだけで毎年本を出版しても数年は雑所得が確定申告が必要なレベルに達しない。

詳細な技術書を書くためには数年の時間がかかる。百万円台の収入では割に合わない。数年の執筆期間を維持するためには一千万円台の収入が必要だが、それには10万冊規模の売上が必要になる。日本で10万冊売れた技術書というのは、プログラマーたるもの読んだことがなければモグリのそしりを免れないような伝説的な本になるだろう。

ちなみに、100万冊売れた技術書は日本の全プログラマーが必携必読の書であり、このブログを読む読者は全員、手の届く範囲にその本を置いているような本になるはずだ。

さらに桁を上げるとどうなるのか。ありえないことだ。1000万冊売れる技術書などというものは存在するはずがない。それでもあえてそのような状況を発生させる条件を考えるとするならば、1000万冊売れた技術書の著者は新興宗教の開祖であり国内に何百万人もの信者を抱え、サイバークライムを救済されシリコンヘブンに行くためには免罪符として自著を購入しなければならない教義を説いているはずだ。

それにしても考えてみれば規模が小さい。現代の商業的な一般の書籍の流通に乗り、一般的な書店に並ぶ技術書の大半は千冊売れる程度なのだ。もはやコミケ以下だ。これでは技術書の執筆者は技術書を執筆するだけでは食べていけない。その結果、いま技術書を書いて生計を立てているような執筆者はいない。かの結城浩ですら、今は何をやっているかというと数学ラノベを書いている。

昔はこうではなかった。現代の感覚ではにわかに信じられないことであるが、昔は技術書を執筆するだけで生計を立てているプロの執筆者がいたと聞いている。一体どうしたらそんなことが可能になるのか。本の値段は何十年も変わっていない。むしろ最近のほうが安くなっている。一冊あたりの著者の印税も最近は安くなっているが、桁違いというほどではない。つまり昔は大抵の技術書が1万冊単位で売れていたということだ。事実、そうであったらしい。

昔は技術書が多く売れていた理由は、技術書が相対的に安かったからだ。今はインターネットの通信費用が限りないほど安価になっている。もはや日本では水と電気とインターネットは無料だと言ってもいい。紙の書籍は相対的に高い。しかし、昔は違った。通信費用は青天井に高かった。インターネットに接続するというのは、ISPの提供する基地局にモデムを介して電話をかけるということだった。そしてISPの基地局は都合よく同一市内の20km以内の場所に存在してくれたりはしない。帯域は本当に狭かった。当時の最後の時代の最高のモデムが56Kbpsだ。そもそも56Kbpsのカタログスペックがフルに出たりなどしない。たったの1MBをダウンロードするために何分もかかる、電話代は数百円かかるだろう。それを考えると、数千円で買える技術書が相対的に安くて売れるのは当然だ。

通信費が高いために、インターネット上にはそれほど情報がなかった事情もある。

現代ではインターネット上に情報が豊富にある上、最新の情報はインターネット上にしかない。本の執筆には時間がかかり、物理的に印刷して書店に並ぶには更に時間がかかる。しかも、今の技術の一次情報はすべて英語だ。すると、著者が英語を読んだ上で日本語で書くというオーバーヘッドもある。紙の本は出版された時点ですでに時代遅れなのだ。

さて、表題の本に戻ろう。今回クラウドファンディングで400万円を集めているわけだが、これはまだ低い。もう一つ桁が上がらなければ執筆に数年かかるような技術書は出せない。ただ、今回クラウドファンディングをしたことで圧倒的な宣伝効果を得たはずで、金銭以外の利益はあったはずだ。

不思議な時代だ。カネを払って宣伝をするのではなく、カネをもらって宣伝をするとは。結局、市場が小さすぎるのが悪い。

技術書の未来はどうなるのだろうか。私は今の傾向が続けば、もはや技術書などというものは滅びると思っている。そうなればプログラマーは皆日本語を捨てて余計なオーバーヘッドが排除されるので、長期的にはいいはずなのだが。

2018-07-04

C++17をすでに現場で使っているというキャディ株式会社に話を聞いてきた

CTOが「日本のC++のトップ人材の過半数が所属するイカれた会社にする」という宣言をした会社がある。なんとも壮大な話だ。C++プログラマーの業種は多岐にわたっているので、文字通りに考えると、そのような会社は自動車や旅客機の製造業であり、防衛庁の入札に参加する受注業者であり、OSや独自のプロセッサーを開発するためC++コンパイラー開発者も雇い、さらにはゲームもブラウザーも検索エンジンもクラウドホスティングもと挙げ続ければきりがないほど多方面に展開する大企業である。おそらくすでに名の知れた有名なIT系の大企業をほとんど買収すればそのような状態にはなるのではないかと思うが、金がいくらあっても足りない。

それはともかく、すでに現場でC++17を使っているという。

C++17は2017年に出たばかりの規格で、まだGCCもClangもコア言語はともかくライブラリーまでは完全に実装し終えてない状況だ。そのような状況で今C++17を使えるということは、最新の安定版のGCCやClangを本番環境で使える会社ということだ。果たして何をしているのか。

というわけで、その会社、「キャディ株式会社」に話を聞きに行った。

https://caddi.jp/: 板金加工なら【キャディ株式会社】―即日見積、5日納品、全国配送

Webサイトを見ると、板金加工をする会社だという。これだけではまだC++を使う理由がわからない。

話を聞いてみるとこうだ。

小規模な板金加工の受注生産というのは、小規模ないわゆる町工場が行っている。これまで板金加工をするには、町工場と直接交渉する必要があった。この顧客と町工場の間の交渉には、これまでほとんど技術革新がなかった。キャディはこの顧客と町工場の間に交渉に技術革新をもたらす、いわば仲介業か一次請けのような役割を果たす。

顧客は加工したいモデルデータをキャディのWebサイトからアップロードする。キャディはモデルデータを処理し、加工に必要な費用を見積もって表示する。この見積もりは一瞬で行われる。顧客が発注するとキャディは提携先の町工場に加工を依頼し、完成品を顧客に引き渡す。

顧客の送信したモデルデータから加工費用を一瞬で見積もるために、モデルデータの処理が必要だ。この処理にC++を使っている。

なるほど、C++を使う理由はわかった。ではどうやってこの比較的早い段階にC++17を使うことができるのか。その理由は簡単だった。規模の小さい新興企業だからだ。

現時点で従業員10人超、プログラマーが5人。そのような小規模な開発だからこそ可能になるのだろう。

大企業であればプログラマーとは別に専門のインフラ部署があり、インフラ屋はプログラマーとは少し違う目標を持っている。システムの安定性だ。新しすぎるソフトウェアは問題を引き起こす可能性がある。既存のソフトウェアに問題があるとしても、既知のものであり十分に情報があるので対処可能であるが、新しいソフトウェアの新しい問題は情報も少なく対処も難しい。この結果、インフラ屋はソフトウェアのアップデートに対して保守的になる。特にGNU/Linuxであればとても重要なC++コンパイラーであるGCCにはとても慎重になる。なぜならばGCCは他のほとんどのソフトウェアをコンパイルする重要なソフトウェアなのだから、GCCに問題があればシステムの全てに問題があることになる。

その結果、RHELのようなC++コンパイラーのアップデートが信じられないほどに保守的で時代遅れのディストロが使われる。

プログラマーが数人ですべてをやるような場合、この問題はない。

また、既存のコードが存在しないのも大きいのだろう。既存のコードが存在する場合、新しいコンパイラーによって不具合が修正され、その不具合に依存していたコードが壊れることがあるので、なかなかコンパイラーのバージョンを上げられない問題がある。

C++17をすでに現場で使っている話を聞くと、なんと私が過去に最新のClangを使っていて遭遇した問題に、同じく遭遇していた。

Clangは一時期、glibcのxlocale.hに依存していたことがある。これは非標準のglibcの独自ヘッダーでかなり昔からdeprecated扱いであり、最近削除された。

ディストロのパッケージにある安定版のClangを使いたい場合、私は空のxlocale.hを用意していた。パッケージ管理されたClangのヘッダーファイルを手動で書き換えるよりマシだ。

最新のClangでは修正されている。

Clangはvirtualデストラクターのある基本クラスをvirtual private派生で間接的に持っていた場合、デストラクターのアクセス指定を正しく判断できないregressionがある。Clang 3.3までは正しい挙動だったのだが、3.4から壊れてしまった。

30916 – If a class has indirect private virtual base with non-trivial public destructor, a class cannot access virtual base's destructor.

もう一年以上前にバグは報告してみたが、まだ修正されていないどころか何の反応もない。

こうして考えてみると、最新のC++コンパイラーには不具合も多い。既存の膨大なコードを修正するコストはかなり高い。常に最新のC++コンパイラーを使うのも茨の道だ。しかし、古いコンパイラーを使うということはこれ以上に莫大な既知の規格違反の不具合に対処する不思議なコードを書かなければならなくなるわけで茨の道であることに変わりはない。

ところで、このキャディ株式会社であるが、C++のプログラマーを随時募集しているらしい。応募方法はウェブサイトに記載されているメールアドレスに連絡してほしいとのことだ。

https://caddi.jp/: 板金加工なら【キャディ株式会社】―即日見積、5日納品、全国配送

2018-06-27

プログラミング入門書の執筆という手探りの活動

ここ最近、まともにブログを書けていない。最新のC++の提案も追えていない。それもこれも、C++によるプログラミングの入門書を書いているためだ。

およそプログラミングが個人でもできるようになって何十年もたとうとしているのだから、いい加減にプログラミングの入門書を書くお作法が成立しても良さそうなものだが、そういった定石は一向に確立されていない。名著と呼ばれる入門書は何冊もあるが、どれもその時代に特化した記述をしていて、その構成を模倣しても現代の入門書としては不適切だ。

結果として、入門書の執筆は自分の感性を信じつつ手探りで書き進めることになる。

よくC++の教育において批判されるのは、ポインターや配列といった低級な要素を最初に教える時代錯誤な点だ。たしかに、現代のC++はポインターや配列を使わなくても書ける。しかし、アドレスやメモリ上の連続したオブジェクトといった概念を理解しないまま優秀なコードが書けるだろうか。ポインターはアドレスを扱うには文法上の罠が多く、配列もメモリ上の連続したオブジェクトを扱うには文法上の罠が多い。

今書いているC++の入門書では、ポインターも配列も教えずに、vectorとイテレーターを教えている。しかし、コンテナーのカテゴリーやイテレーターのカテゴリーについては教えていないので、vectorとランダムアクセスイテレーターを前提にした記述になってしまう。

本当はコンテナーのカテゴリーやイテレーターのカテゴリーについて網羅的に教えたいのだが、そうすると具体的なコードがなく抽象的な分類とサポートされる操作といった文章が延々と続くことになってしまう。入門書では直接的なコードがすぐに書けるほうがよいと判断したのでvectorと実質ランダムアクセスイテレーターだけを教えているが、どうにも釈然としない思いがつのる。

プログラミングの入門書の冒頭では、どのようにしてコードを実行するかについて説明するものだ。既存の毎年改訂版が出るような使い捨ての入門書では、この説明のために、例えばVisual Studioのインストール方法の解説からはじめる。しかもご丁寧にいちいちスクリーンショットを載せ、ここのボタンをクリックしてなどといった本当に何のためにあるのかわからない解説が続く。

私が書いている入門書では、そのようなスクリーンショットは一切載せない方針にした。さらに、今年出たばかりの新しいツールに依存してしまうと、数年後に時代遅れになって使えなくなってしまう可能性が高いので、20年前に持っていっても使えるような安定したツールだけを使うことにした。その結果、使うツールはbashとGCCとGNU Makeになった。20年前から変わらないビルドシステムは、おそらく20年後もこのまま使えるはずだが、印刷される書物としてタブ文字と空白文字を区別するように説明するのはつらい。

今書いている入門書はあらゆることが手探りで進められている。例えば変数の宣言方法は以下のとおりだ。

// 整数
auto x = 0 ;
// 浮動小数点数
auto y = 0.0 ;
// 文字列
auto z = "hello"s ;

変数をいきなりこのような方法で教えるC++の入門書は今まで読んだことがないが、思うに最近の言語は強い静的型付けがないか、強い静的な型推論がある言語ばかりで、このような変数の書き方が自然になってきているので、これでよいだろう。

この調子で、最初に教える関数も以下のようになった。


auto plus = []( auto x, auto y ) { return x + y ; } ;

C++では、厳密にはこれは関数ではなくてラムダ式なのだが、こう書くことによって型を意識しないですむ。

ラムダ式を最初に教えることで、関数を渡す関数も自然に教えられるようになった。


int main()
{
    auto for_each = []( auto first, auto last, auto f )
    {
        for ( auto iter = first ; iter != last ; ++iter )
        {
            f( *iter ) ;
        }
    } ;

    std::vector<int> v = {1,2,3,4,5} ;

    for_each( std::begin(v), std::end(v),
        []( auto value ) { std::cout << value ; } ) ;
}

実際、std::for_eachは概ねこのような実装になっているのだと教えている。もちろん、これは本当のstd::for_eachの実装ではないし関数でもないので、厳密には違うが、初心者ならばこの説明でいいだろうと妥協している。

さらに一歩を踏み込んで、vectorの初期化を以下のようにできるのだが、おそらく混乱するだろうからまだやめている。これはC++17で採用されたdeduction guideによるものだ。


// std::vector<int>と同じ
std::vector v = {1,2,3,4,5} ;

今、ようやくアルゴリズムまで進んだのだが、今までに教えたことしか使っていない結果、関数はラムダ式で、コンテナーはvectorしか教えておらず、イテレーターはランダムアクセスイテレーターで、クラスはまだ教えておらず、テンプレートも当然教えていない。lvalueリファレンスだけは無理やり教えたがCV qualifiersは教えていない。

この状態で一体どこまで教えればいいのだろうか。C++を本格的に使うには、当然既存のC++のコードも読む必要があるだろうから、ポインターや配列を理解しなければならず、クラスやテンプレートも学ぶ必要がある。動的メモリ確保も必要だ。しかしこれらの概念を網羅的に解説するのはあまりにも抽象的すぎて、今想定している入門書では難しい。

今書いている入門書は本当に読者に想定していることが少ないので、C++のビルド方法からはじめ、エラーメッセージの読み方も解説したし、gdbの簡単な使い方も解説したい。

それにしても、今はC++を学ぶ対象読者の想定が難しい。一昔前ならばC言語をすでに学び終えた人間を想定すればよかったのだが、今はJavaScriptとかPythonかRubyぐらいしか触ったことのないプログラマーが増えている。彼らはコンパイルしてリンクして実行という仕組みに触れたことがない。

さらに、一昔前ならば想定することができなかった競技プログラマーという人種がいる。彼らは数学力は凄まじいがプログラミング言語には大して執着がなく、必要な計算を最小限のコードで実現できればそれでいいというとても割り切った使い方をする。プログラミング言語の文法をほとんど理解していないのに問題を解くコードは書けるというよくわからない人種だ。

そして入門書は浅く簡略化した解説を続けながらアルゴリズムまで来た。

この後はgdbの使い方、クラス、テンプレート、ポインター、動的メモリ確保、派生クラスあたりの順番で書こうかと思っている。C++の機能の依存関係の解決が辛い。すでに教えている機能だけを使う縛りを入れているので、早く機能を教えないといつまでも簡略化した説明を続けるハメになるが、いきなりポインターを教えても実感が沸かないだろうから、ポインターは相当後になる。

2018-06-14

xkcd: お客様特典

xkcd: Customer Rewards

23ドル3セントになります。

ところで、あなたの本名を教えていただけるのならば24セントお支払いたします。家族構成を教えていただけるのであれば35セント、電話番号に79セント、あなたのスマフォをこの場で貸していただいてあなたのFacebookの投稿一覧を確認させてもらえるのであれば1ドル20セントお支払します。

ポイントカードと特典は、独立した取引として考えた場合、とても奇妙なものになる。

title="うちの製品をSNSに投稿していただけるのであれば1ドル47セント、グループチャットで毎回話題に持ち出すのであれば2ドル5セント、運転中にうちの広告を通過した場合乗員一人に付き11セントお支払します。"

そういえばレシートを1枚10円で買い取るサービスが流行っているようだ。

2018-06-12

coinhiveが不正であるというナンセンスについて

coinhiveの設置者が不正指令電磁的記録取得・保管罪で略式起訴を受けたので正式に裁判して争う発表をした。

仮想通貨マイニング(Coinhive)で家宅捜索を受けた話 - Webを楽しもう「ドークツ」

高木浩光@自宅の日記 - 懸念されていた濫用がついに始まった刑法19章の2「不正指令電磁的記録に関する罪」

6月10日の高木宏光の記事では具体性がなかったのでよくわからなかったのだが、こうして具体例を目にしてみるとこの件がとてもひどいことがわかる。

裁判は多少のカネと時間がかかるがそれほど労力はかからない。数カ月に一度、提出した書類道理の陳述するという儀式をするだけのものだ。みんなもっと積極的に裁判をすべきだ。

法律の解釈は裁判をして判例を作ることで成り立っているので、おかしいと思った法律解釈には積極的に裁判をしないとどんどん悪い判例が積もっていく。

それはそれとしてcoinhiveは嫌いなので広告と同じくブラウザー拡張でブロックするべきだ。

2018-05-31

江添ボドゲ会@6月10日

下記のごとく毎月定例の江添ボドゲ会を開催します。

江添ボドゲ会@6月10日 - connpass

2018-05-29

世の中にはプログラミングを理解できない人間が存在する

現在、C++によるプログラミングの入門書を書いているので、初心者のプログラミングの学習過程にとても興味がある。私自身も初心者の気持ちを取り戻すためにHaskellを学んでみた。最初の数日は頭が痛くなるほど難しかったが、そこを過ぎてみれば後は楽になってしまった。結局、初心者の気持ちはあまりわからなかった。結局、プログラミングの基礎はすでに学んでしまっているので、

先日、FizzBuzzがわからないから教えてくれという知人がいたので、これは初心者の気持ちを知るいい機会と話を聞いてみたところ、想像を絶する世界が見えてきた。

まずこれが動かないと悩んでいたコードだ。


for ( int i = 0 ; i <= 100 ; i++ )
{
}
else if ( i % 15 == 0 )
{
    Debug.log("FizzBuzz") ;
}
else if ( i % 3 == 0 )
{
    Debug.log("Fizz") ;
}
else if ( i % 5 == 0 )
{
    Debug.log("Buzz") ;
}
else
{
    Debug.log(i) ;
}

一見するとそれらしいソースコードのようにみえるが、そもそも文法が間違っている。文法が間違っている箇所を指差しても納得しない。for文の文法を説明しようとするが聞く耳を持たない。「これが間違っているなら参考にしている教科書も間違っている」との一点張りで誤りが存在していることを頑なに認めない。参考にしているらしいスライド資料にのっているコード例と比較させても間違いの箇所を判断できない。for文の文法の説明をもう一度試みるがやはり聞く耳を持たない。

そしてソースコードの見た目を適当に書き換えてなんとか問題を「修正」しようと試みる。私はいつシェイクスピアの名作が出来上がるだろうかと考えながらその様子を見守っていた。

ややあって、奇跡的にソースコードが適切な形に「修正」された。しかし出力は期待通りにならない。当然だ。なぜならこれはUnityで、使っているのはデバッグログ用の機能であって、重複は省かれるからだ。出力は、1, 2, "Fizz"というメッセージが何件, 4, "Buzz"というメッセージが何件, 7, 8...と続く

そもそも基礎的なプログラミングの知識が十分ではないのだから、Unityはやめてもっと罠の少ないCLI環境でプログラミングの基礎を学ぶべきだと諭しても、「Unityは私がやりたいことを実現できる環境であり私のモチベ維持のために重要であるからUnityでやる」といって改めようとしない。

これは一体どうすればいいのだろう。こういう人間は教育不可能だ。この人物の経歴を見るに、どうもそれらしく見えるモックアップをでっち上げてきたアート系の人間のようだ。本人は今の時代は科学とアートは同じものでありアートを融合することでユーザービリティを考慮したUIが云々などと、まるでピタゴラス派のようなことを言う。世界は人間にとって美しい数字とか法則で定義されるべきであり、定義が観測結果に従わないとしても定義は正しいと主張したのがピタゴラス派だ。アートに引きこもっているならそれでいいのだが、それは科学ではない。コンパイラーのソースコードの解釈はこの自然界には珍しいことに冪等性を持っているのだから、見た目をでっち上げるのではなくて本質を理解すべきなのだ。たとえその本質が自分の美学に合わなかったとしてもだ。私は本棚にあったアラン・ソーカルの著書、知の欺瞞を手に取らせてみたが、あまり興味は示さなかったようだ。

こういう人間によって書かれたソースコードは一見もっともらしく見えるが、文法違反の間違ったコードとなる。どこかからか発見してきたコードをコピペしてツギハギしてそれらしい見た目のソースコードをでっち上げる。人間相手であれば、いかにも主題について理解したかのようにもっともらしくでっち上げた小論文を書いて読ませれば筆者は主題を理解していると読者を騙すことは可能だが、ことコンパイラーが相手では文法違反のソースコードを騙すことなどできない。

思うに、先天的に、あるいは幼少期の教育の結果、プログラミングに向かない学習方法に最適化されてしまった人間がいるのではないだろうか。物事の本質を完全に理解するにはコストがかかる。しかし、不完全な理解だがそれらしいものをでっち上げるにはコストがかからない。そして、人間には、それらしくでっち上げられた偽物と、本質を理解した上で作られた本物を判別するのが難しい。一方コンピューターは違う。コンパイラーはソースコードがいかに本物のソースコードらしい見た目をしていようとも、文法違反のソースコードを判別できる。コストを書けずに結果を出すためにそれらしくでっち上げる学習方法に最適化されてしまった人間は、コンパイラーに対して、それらしくでっち上げられたソースコードを食わせてコンパイラーが騙されてくれることを期待する。しかしコンピューターは騙されない。そもそも騙しようがない。コンパイラーは定義済みの規則に則って判断するだけで騙すという概念すらないのだから。

2018-05-17

ポルノ本意制の通貨が登場したことにより今後予想される問題について

ポルノ動画サイトの最大手であるポルノハブが仮想通貨Vergeによる支払いを受け付けているそうだ。

世界最大のポルノサイトが仮想通貨「verge」に対応、アクセスしてみるとびっくり! ポルノ業界が急激に進化中!

これはとても面白い事象である。というのも、この通貨はポルノと交換できることがポルノハブによって保証されているわけだ。すなわち、これは金本位制ならぬポルノ本位制である。しかもこの話は単なる空想に終わらない。ポルノハブは実際にこの通貨とポルノの交換を行っているわけで実態がある。ここにポルノ本位制の通貨が登場した。

ポルノ本位制の通貨が存在する社会はどのように変革していくのか、ポルノ本意制の通貨を使うときには何に気をつければよいのか。我々人類は通貨と経済学について長い歴史があるので、歴史から学ぶことで今後の動向は予測できる。本記事ではポルノ本位制の通貨がもたらすシュールな世界を紹介しよう。

ある通貨はポルノと交換できることが保証されているとして、一体どのようなポルノと交換できるのだろうか。ポルノはどのようなものであってもポルノであり、したがってポルノとしての価値を持つはずだ。質の高いポルノを生産するのにはコストがかかる。すると、世の中には質の悪い製造が容易なポルノが量産されるだろう。通貨と交換品の価値に差が生じた場合、人々は通貨と交換するポルノには質の悪いポルノを使い、質の良いポルノは貯蓄するようになる。これを「悪ポルノは良ポルノを駆逐する」といい、グレシャムの法則とも呼ばれている。

経済学的にポルノの価値を考えると興味深い事情がある。ポルノの価値はまだ誰も見たことのない市場に出回っていない新作ほど高い。みんな見たような市場に出回りすぎたポルノは価値が低い。これを考えると、ポルノは金のように価値が安定しておらず、消費財である。しかし金の生産量は簡単に増やせないが、ポルノの生産量は裸の人間とカメラさえあればいくらでも生産できる。しかも一人の人間に複数のカメラを使うことで並列生産も可能だ。中には車とドラゴンをポルノだとみなす人もいるが、ドラゴンの用意はやや難しい。最近は地図上にもドラゴンの住まう地と書かれる土地が少なくなったからだ。

ポルノ本意制の社会では、実経済に出回っている通貨がいつポルノとの交換を要求されるかわからない。そこで、銀行は十分な量の価値の高い未公開ポルノを戦略的に備蓄しておく。これを準備ポルノという。

なぜ実経済が存在するポルノより多い通貨を動かすようになるのだろうか。それは借金の存在のためだ。まだポルノを所有していない人間が、将来ポルノを所有する信用によって通貨を借りる。その通貨でポルノを生産し、借金を返す。このとき、生産したポルノによって借金以上の価値が生まれれば得をする。ところで、借金をしたときまだポルノは世の中に存在していなかったわけだ。しかし借金をしなければポルノは生産されなかった。したがって、実経済では常に準備ポルノ以上の通貨が動いているのだ。

現実には、市場に出回る通貨すべてを一斉に換ポルノしたときの需要を満たすほどの準備ポルノを用意することはできないだろう。皆が一斉に通貨とポルノ交換、すなわち換ポルノを要求したとき、取り付け騒ぎが起き市場が混乱する。このような取り付け騒ぎはめったに起こらないが、たまに些細な噂が拡大解釈されて発生することがある。例えば女子高生が何気なくつぶやいた、「最近ポルノハブ危ないんだって」という言葉からポルノの取り付け騒ぎが発生し、準備ポルノの少なかった弱小ポルノサイトが閉鎖に追い込まれることは十分にあるだろう。そのような自体に陥った場合、まず自殺したと噂される理事長自ら生存を主張し、巨大スクリーンでポルノを映すことにより準備ポルノは十分にあることをアピールすべきだ。

不況時には、ポルノが十分に国内に供給されない。このとき、国内にすらポルノ供給が足りていないのに海外にポルノを輸出するのはけしからんという極めて素朴で単純な考え方が国民に芽生え、そのような狭い思想の政治家が当選する。結果として、国家はお互いにポルノ輸出を禁ずるようになり、各国が経済的に鎖国し始める。

こうしたことから、ポルノ本意制はいずれ破綻し、廃止しなければならなくなるだろう。どうやって廃止するのかを歴史に学んで今から対策しておこう。国家は通貨とポルノの法定為替を一方的に定め、国民の所有するポルノ財産をすべて法定為替で強制的に買い上げるかもしれない。

そして、今と同じようにポルノと通貨は変動為替に移行し、取引所に直結したアルゴリズムトレード勢がマイクロ秒単位でポルノ価値を判断して先物取引をするようになるだろう。

他にも面白い思考実験として、フィクションの世界では水本位制がある。これはFalloutというゲームの世界の設定だ。全面核戦争の後に清潔な飲料水が貴重になり水が価値になった。しかし水を持ち運ぶのは手間なので、ある有力な水商人が水とボトルキャップを交換するようになった。なぜボトルキャップなのかと言うと、もはやボトルキャップを製造する技術や設備は存在しないからだ。つまり、ボトルキャップは偽造が実質不可能で、全面核戦争前に製造されたものしか残っていない。偽造が不可能であれば貨幣として使うには十分だ。

2018-05-14

OpenBSD、1985年に追加されたIntelの最新の誇大広告された機能を使わないことにより脆弱性を華麗に回避

“We didn't chase the fad of using every Intel CPU feature” | Hacker News

'Re: CVE-2018-8897' - MARC

前回の記事であるIntelの古いマニュアルを誤読したために生じた脆弱性では、IntelのCPUがスタック切り替えるためにss/spレジスターをアトミックに更新する汚いハックとして、ssレジスターが変更された直後の1命令は割り込みが遅延される古い仕様があるが、多くのOSはこの古い仕様を把握していなかったため、ssレジスターを変更した直後の1命令でカーネルモードに入り、かつハードウェアブレイクポイントが設定されたことにより割り込みを起こせば、カーネルモードに入った直後にカーネルのコードを1命令たりとも実行していない状況でカーネルモードとしてユーザーの割り込みが実行される脆弱性を引き起こしていた。

さて、各OSが対応に追われるなか、セキュリティに万全の体制を取ることで定評のあるOpenBSDでは特に何事もなくのほほんとしているので、MLにこのことについて質問をするものがいた。

OpenBSDが影響を受けないという理由について教えてほしいんですけど?

バカな質問ですみませんが、このFreeBSDもこの問題に引っかかっているのに、なぜOpenBSDは平気なのか不思議です。

事前に把握してたんですか?

昨日、一面記事になったような大ニュースになぜOpenBSDは引っかかっていなかったのか気になります。

これに対するTheo De Raadtの返事。

Intelの誇大広告まみれのCPU機能を全部追いかけるようなマネはしていないんでな。

We didn't chase the fad of using every Intel cpu feature.

強すぎる。

この機能というのはi386から追加されたハードウェアブレイクポイント機能のことだ。なんとOpenBSDではユーザースペースからx86のハードウェアブレイクポイント機能の使用を許可していない。ではgdbのようなユーザースペースのデバッガーはどうやってブレイクポイントを実装しているのかと言うと、古き良きソフトウェア実装を用いている。ブレイクポイントを仕掛けたい部分のコードを割り込み命令(int 3とか)とか無効命令(ゼロ除算)で置き換えておき、例外割り込みをブレイクポイントを仕掛けたい場所で発生させることによる移植性の高いソフトウェア実装だ。

ちなみに、IntelのCPUがハードウェアブレイクポイント機能を実装したのは1985年のi386にまで遡ることができる。

結果として、OpenBSDは今回の主要なOSが軒並み影響を受けた問題に対して何の影響も受けていないので、結果的に正しかったと言えるが、いやしかし凄まじい。OpenBSDのセキュリティにかける情熱を過小評価していた。

2018-05-11

Intelの古いマニュアルを誤読したために生じた脆弱性

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs | Hacker News

8086でスタックを切り替えるには、ssレジスターとspレジスターを両方変更する必要がある。しかし、ssレジスターだけを変更してまだspレジスターを変更していないときに割り込みがかかると問題だ。そこで、8086は粋なはからいによって例外的にこの問題に対処した。ssレジスターを変更した直後の1命令では割り込みが発生しない。仮に割り込みが起きたとしても1命令を実行するまでは遅延される。

もし、ssレジスターを書き換えた直後の1命令でカーネルモードに入った場合、この粋なはからいが問題になる。カーネルモードに入ったあと、カーネルコードを1命令たりとも実行していない段階で割り込みが発生する可能性があるからだ。しかも実行はカーネルモードだ。

2018-05-08

glibcのabortマニュアルの中絶方針ジョークについて

Who controls glibc? [LWN.net]

「glibcのabortのマニュアルにはabort(終了)とabortion(中絶)をかけた中絶ジョークがあり、これはマニュアルとして有益ではなくて混乱の元なので削除するというパッチが提出され、受け入れられたが、RMSの反対により差し戻された」

これだけ読むとくだらない出来事のように思えるし、人によってはこのジョークの存在が好ましくないとか下品だと思うかもしれない。しかし、これは単に下品なジョークで片付けてよい問題ではない。実は音はもっと深いのだ。

まず、ジョークの内容は中絶ジョークではなく、中絶方針ジョークなのだ。

glibcのabortのマニュアルには以下の記載がある。

将来の変更警告:連邦検閲規制委員会に提案された方針によれば、この関数を呼び出すことができる可能性についての情報を我々が与えることが禁止されるかもしれない。我々はこれがプログラムを終了する適切な方法ではないと言わざるを得なくなるかもしれない。

問題の方針とは、メキシコシティポリシーと呼ばれているアメリカ合衆国では歴史の深いものだ。

Mexico City policy - Wikipedia

メキシコシティポリシーとはアメリカ合衆国政府の方針で外国籍のNGOがアメリカ政府から出資、健康補助、HIV補助、妊婦及び子供の補助を受ける場合「中絶の実施、並びに中絶を家族計画の方法として積極的に宣伝する」ことをしてはならない、というものだ。

これはアメリカ合衆国で中絶の違憲判決が出ていなかった時代から続く方針だ。歴史的に右翼である共和党はこの方針を肯定し、左翼である民主党は否定している。アメリカ合衆国における右翼とはキリスト教原理主義者を指し中絶は違法であるとの立場を取る。左翼はリベラルであり中絶は合法であるとの立場を取る。

メキシコシティポリシーの名前は1984年に共和党のロナルド・レーガン政権が名付けたものだ。これは1993年に民主党のビル・クリントン政権で撤回されたが、2001年に共和党のジョージ・W・ブッシュ政権で復活し、2009年に民主党のバラク・オバマ政権で撤回され、そして当然、2017年の共和党のドナルド・トランプ政権では復活した。

ちなみに、ブッシュ政権のときにメキシコシティポリシーの違憲性を問う訴訟で、アメリカ政府が外国籍のNGOを補助するときに中絶への立場を考慮することは違憲ではないという判決が出ている。

さて、話をglibcに戻そう。glibcというのはGNUであり自由ソフトウェア財団である。RMSが始めたGNUはその当初から左翼主義が全面的に出ており、ソフトウェア開発は政治活動だと考えている。その思想に基づけば、この20年前からマニュアルに存在する中絶方針ジョークは必要不可欠でありたやすく取り除いてはならないものである。

今回はRMSが強権を発動し、ジョークは残った。

この問題の背景事情を考えるに、私はこの中絶方針ジョークは残すべきであると思う。

2018-05-03

LLVMで5番目に貢献の多い開発者、LLVMの最近のSJW運動に反対して開発をやめると表明

One Of LLVM's Top Contributors Quits Development Over CoC, Outreach Program - Phoronix

[llvm-dev] I am leaving llvm

Rafael Avila de Espindolaは2006年からLLVMに対して4300以上もコミットした開発者で、現在LLVMの全Authorの中で第5位のコミット数を保有する開発者である。Rafaelは最近のLLVM Code of Conductと今年のアウトリーチプログラムへの参加を、「社会不正義」(Social Injustice)だと吐き捨ててLLVMの開発をやめる声明を出した。

LLVMのCode of Conductは以下の通り。

LLVM Community Code of Conduct — LLVM 7 documentation

  • 仲良く辛抱強くやれよ
  • 新参は歓迎しろよ
  • 迷惑かけんなよ
  • 尊敬しろよ
  • 言葉遣いには気をつけるのと、あと親切にしてやれよ

Code of Conductは、過去に様々な自由ソフトウェアコミュニティが取り入れて、その結果政治的な問題を引き起こしてきた歴史がある規約だ。そもそも存在自体が政治であるものを入れると純粋な技術から遠ざかり、些細な言葉遣いのような揚げ足取りの政治に終始するのは当然であると言えよう。

アウトリーチプログラムというのは現在コミュニティでマイノリティである属性を持った開発者を新規に確保するための優遇措置だ。属性というのは主に性別で、具体的には女性のことだ。しかしこれは純粋な技術力ではない性別のような条件で人を優遇するということであり、これはまさに性差別そのものである。これをやりだすと人物が純粋な技術力で評価されず、たまたまマイノリティの性や宗教や門地のような属性を持っていたというだけで優遇される。

私がさる理由はコミュニティの変化のためだ。現在のライセンス変更の議論は私がGCCの開発をしていた頃の自由ソフトウェア財団の政治を彷彿とさせるものがある。これだけではまだ去るほどの理由ではない。コードと同じように、LLVMはまだ最適なライセンスを選択しているし、コミュニティの変化というのがライセンスの変更だけであれば、まだ続けることもできた。

私が受け入れられないコミュニティの変化は社会不正義運動がはびこっていることだ。私がLLVMに参加したとき、誰も私の宗教や政治信条について疑問を呈するものはいなかった。我々は皆、良きコンパイラーフレームワークを作ることに注力していた。

ここ最近、Code of Conductやらが採用された。これによれば、コミュニティはすべての「政治信条」を歓迎するよう務めるとある。しかし、Code of Conductの存在に反対する政治信条を持つ者は歓迎できない。そして、カンファレンスに参加するにはCode of Conductへの同意が必要であるからして、私はもはや参加することができなくなった。

トドメの一撃は、LLVMがある団体と手を組んだことで、この団体は公に性別や門地による差別を行っている。これは私の倫理と真っ向から対立するものであり、私はこの手の輩と一緒くたにされないために、プロジェクトを去る必要がある。

RafaelのMLへの投稿は、最後に"So long, and thanks for all the bugs,"(さよなら、いままでバグをたくさんありがとう)と締めくくっている。銀河ヒッチハイクガイドへのリファレンスのようだ。