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をどうするかだ。タッチパネル付きのディスプレイをつけるのが一番いいように思える。考えてみよう。