2017-08-19

LLVMがWindowsのデバッグ情報フォーマットのPDBをサポート

LLVM Project Blog: LLVM on Windows now supports PDB Debug Info

この数年、clangをWindowsでソフトウェア開発するための世界級のツールチェインにするために尽力してきた。このことについては、すでに何度も書いてきたことだ。LLVMは完全なABI互換を実現した(ただしバグ互換ではない)。互換性を実現するのが難しい分野にデバッグ情報があるが、この2年間で、LLVMは飛躍的な発展をとげた。とりあえず結論を先に書くとこうだ。WindowsでClangを使うと、PDBデバッグ情報が出せる。

背景:CodeView VS PDB

CodeViewは1980年台の中頃にMicrosoftによって考案されたデバッグ情報フォーマットだ。様々な理由で、他のデバッガーはDWARFという独立したフォーマットを開発し、これは標準化されて、多くのコンパイラーとプログラミング言語でサポートされている。CodeViewは、DWARFと同じく、ソースコード行とコードアドレスのマッピングと、プログラムが使う型とシンボルのレコード集である。デバッガーはこの情報を使って、関数名でブレイクポイントを設定したり、変数の値を表示したりする。ただし、CodeViewはあまりよくドキュメント化されていない。最新の公式なドキュメントは少なくとも20年前のものだ。レコードの中にはドキュメント化されているものと同じフォーマットのものもあるが、まだドキュメント化されていない後々の追加のレコードもある。

ここで重要なのが、CodeViewは単にレコード集だということだ。もしユーザーが、「Fooの値を表示してくれ」といったときどうなるだろうか。デバッガーはFooについてのレコードを検索する。そして物事は更に複雑になる。どの最適化が有効にされていたのか? コンパイラーのバージョンは?(これはコンパイラーのバージョンによって一部のABIの非互換があったり、極度に最適化されたコードからバックトレースを再現する際のヒントとして使ったり、スタックが破壊されているかどうかの確認に重要だ)。プログラムには大量のシンボルがある。どうやって遅いO(n)にならずにシンボルを検索すればいいのか? どうやってコードを僅かに変更した時にインクリメンタルリンクを実現してデバッグ情報の再生成を回避すればいいのだ? 文字列の重複を省いて空間を節約するにはどうすれば? ここでPDBが登場する。

PDB(Program Database)は、その名前通り、データベースだ。これにはCodeViewが含まれているが、CodeViewレコードを様々な方法でインデックス化するための様々なものが含まれている。これによって型やシンボルを名前やアドレスで検索するのを高速化している。発想としては入力ファイルに対する「テーブル」と同等であり、ユーザーはその存在を気にすることはないものの、Windowsにおけるデバッグを快適にするのに貢献している。しかし問題がある。CodeViewはある程度はドキュメント化されているのに対し、PDBはまったくドキュメント化されていない。しかもその構造は複雑だ。

お手上げだ(ホントか?)

数年前、LLVMは開発の方向性として、CodeViewとPDBを出力する望みを一切捨て去り、以下の2つに注力することにした。

  1. clang-clはWindowsでDWARFデバッグ情報を出力する
  2. LLDBをWindowsに移植してWindows ABIに対応させる。これはVisual StudioやWinDbgをDWARFに対応させるより遥かに簡単だ(そもそもそんなことが可能であればの話だが。Visual StudioとWinDbgの拡張機能を使って実装可能なのだろうか)

実際、私はすでにブログ記事でこのことを2年前に書いている。作業の結果、LLDBをWindowsに移植して簡単なデバッグをさせることはできるようになった。

残念ながら、PDBのサポートは必須であることが明らかになった。LLVMの目標はWindowsエコシステムに囚われた開発者にとってできるだけ抵抗が少なくなるようにすることである。Windows Performance AnalyzerやvTuneのようなツールはとても強力でエンジニアの慣れ親しんだものである。企業はPDBファイルを保存、収集してクラッシュダンプを解析するインフラに投資している。PDBによるデバッグはとても高速だ。というのも、インデックスはファイルフォーマットで実現されていて、デバッガーが起動時にシンボルをインデックス化しなくてもいいためだ。それに、WinDbgのようなツールはすでにデバッグ用途に便利で、率直に言って、多くの(おそらくはほとんどの)Windows開発者がVisual Studioを手放すためには、彼らの死体の手からもぎ取る必要があるだろう。

私がとりあえずMicrosoftに協力を求めてみればええんちゃうと提案したときには皆から冷たいまなざしを受けたものだ。しかし、最終的に我々はMicrosoftに協力を求めた、そしてMSは協力した。協力はMicrosoft Githubにコード片を投下するという形で得られた。後はこのコードを解析するだけだ。Microsoftが公開できたコード片はPDBのコードの一部(我々は推測と解析をしなければならないし、そもそもコードは半分ぐらいかけているのでコンパイルすら通らないわけだが)だけであるが、実装をするだけの情報は得られた。

このコードを1年半解析し、試し、更に解析し、更に試しなどした結果、lld(LLVMリンカー)はついに機能するPDBを出力することができるようになった。基本的なことであるコード行や名前でのブレイクポイントの設定や、変数の表示や、シンボルや型の検索は、すべて動くようになった(ただし、もちろん、バグ互換はない)

PDBの詳細を調べたい人のために我々はツールも開発中だ。llvm-pdbutilと呼ばれるツールで、Microsoftのcvdumpユーティリティとよく似たものだ。このツールはPDBの内部情報をダンプして、PDBとyamlの相互変換、2つのPDBのdiffなどを実現している。llvmpdbutilの簡単なドキュメントはここにある。PDBファイルフォーマットの詳細の解説はここにある。この2年間に我々が解析したすべてが書いてある(まだ途中だ。私はドキュメントとPDBの実装の両方に時間を割かなければならないのだ)

バグをもってこい!

さて、ここで読者の協力が必要となる。我々はPDBで簡単なデバッグ状況をテストしたが、まだデバッグ情報の品質としてはアルファ段階だと考えている。是非試して、問題をバグトラッカーで知らせてほしい。始めるためには、まず最新のWindows用Clangのスナップショットをダウンロードしよう。この機能をテストする簡単な2つの方法は以下だ。

  1. clang-clにlldを自動的に実行させる

    clang-cl -fuse-ld=lld -Z7 -MTd hello.cpp

  2. clang-clとlldを別々に実行する。

    clang-cl -c -Z7 -MTd -o hello.obj hello.cpp

    lld-link -debug hello.obj

バグレポートがあふれかえるのをお待ちしております!

Microsoftが我々に協力してgithubレポジトリにコードをアップロードしてくれたことに心から感謝している。Microsoftの協力なしには実現できなかったことだ。

ところで、将来期待される歓喜すべきある事柄について読者の想像に委ねたい。ここに書いたPDBサポートはWindows特有のAPIやdllやライブラリに一切依存していない。100%移植性がある。ところで、君はクロスコンパイルに興味があるかね?

Zach Turner(LLVMのWindowsチームとして)

なかなか興味深い。

ところで、Microsoftが公開したMicrosoft/microsoft-pdbはMSVCのPDBを処理しているコードの一部だ。PDBフォーマットの詳細を開示するよう要請したところ、コード片が開示され、しかも、Microsoft自ら、「ソースコードは究極のドキュメントである」"Source code is the ultimate documentation :-)"、書いているところを見ると、果たしてMicrosoft社内にPDBの詳細なドキュメントはあるのか疑問だ。

OracleがJava EE 8の開発をコミュニティの手に委ねたいとか言い出す

Opening Up Java EE | Oracle The Aquarium Blog

Oracleがブログで、Java EE 8の開発をコミュニティの手に委ねたいと表明している。その文章がいかにも回りくどく面白かったので、とりあえず翻訳してみた。

Java EE 8についてOracleは目覚ましい進展を続けてきた。規格はほぼ固まり、この夏にリファレンス実装を提供できる予定だ。Java EE 8の提供とJavaOne 2017カンファレンスが近づいてくるにつれ、OracleとしてはJava EEの開発をより変容する業界と技術要求に対してアジャイルかつレスポンシブに対応できる開発体制を再考する余地があるのではないかと考える。

Java EEは競争的な市場において、互換性の高い実装、業界に広く採用されている技術、多大な既存のフレームワークとツール、エンタープライズとエンドユーザーに対する数限りない適用例でもって、大変に成功している。しかし、Java EEはJava EEコミュニティも参加するオープンソースで開発されているとはいえ、その開発体制は十分にアジャイルでフレキシブルでオープンではなく、特に他のオープンソースコミュニティと比較すると違いが顕著である。Oracleはよりベターにやりたい。

Oracle内部ではjava EE 8提供後のJava EE開発体制をいかにして改善できるかについて議論している。Oracleとしてはリファレンス実装とテスト互換キットを含むJava EE技術をどこかのオープンソース財団に移行するのが、よりアジャイルな開発体制、よりフレキシブルなライセンスの実現、管理体制の変革という点で、適切な方法であると信ずる。OracleはJava EEの開発をこの方向ですすめるべく、この可能性をコミュニティと我々のライセンシーといくつかの財団に掛け合う予定だ。

Oracleは開発者、エンドユーザー、カスタマー、消費者、貢献者、パートナー、ライセンシーに対する貢献を続けていく。そしてOracleは既存のJava EE実装と将来のJava EE 8実装に対するサポートを続ける。Orackeは将来のJava EE技術の発展に関与し続ける。しかし、単一のベンダーやプラットフォームの意向によらないよりオープンな開発体制は、イノベーションの促進によろしく、コミュニティの最大の関心を引きつけるところであると信ずる。

この件に関してコメントしたい人は、feedback@javaee.groups.ioにメールしてもらいたい。この件の進展についての詳細を告知する。

この件がWebLogic Serverに与える影響については、こちらを参照。

お断り

以上はOracleの一般的なプロダクトの方向性を示すものです。以上は情報提供の目的で提示されたものであり、将来に渡って何らかの約束をするものではありません。以上は何らかの財産、コード、機能の提供を約束したものではなく、購入選択において考慮すべき情報ではありませんOracleのプロダクトの機能の開発、リリース、その提供時期はOracleが決定するものであります。

Oracleの過去の前科から考えると、この手のコミュニティに開発を委ねるという方法で、市場価値の薄れてきたSolarisを殺し、SPARCを殺し、Star Officeも殺してきた。要するに旧Sun Microsystemsの製品を続々と殺し続けてきたわけだ。Java EE 8も後に続くのだろうか。

ただ思うと、JVMには未だに価値を認める人間が多いのに対し、Javaはそれほど空かれていない。だからScalaとかKotlinとかその他多くのJVMで動く言語が流行っているわけだ。JVMはともかくJavaの将来性はあるのだろうか。

2017-08-16

江添ボドゲ会 8月20日

8月20日に自宅でボードゲーム会を開催します。詳細はconnpassで。

江添ボドゲ会 8月20日 - connpass

2017-08-04

C++17の参考書がだいぶ完成してきたので査読大募集中

半年前から書き始めたC++17の参考書がだいぶ完成してきた。参考書はGitHubで公開している。不備を発見したら、どんどんPRを投げてもらいたい。すでに28件のPRを処理した。

EzoeRyou/cpp17book: textbook for C++17

昨日書きあげたばかりのC++17で追加された数学用の特殊関数の章は特に数学とC++の両方に詳しい人間の検証を必要としている。

cpp17book/045-cpp17-lib-mathematical-special-functions.md at master · EzoeRyou/cpp17book

さて、残りは小粒なライブラリと、ファイルシステムだ。

C++17にはposixのファイルシステム操作をC++風にラップしたファイルシステムライブラリが入る。これを一体どうしたものか迷っている。

というのも、ファイルシステムライブラリは膨大で、その解説には100ページ以上かかる。果たしてそんな解説をして、これ以上執筆機関を伸ばし、またページを増やしてもいいものだろうか。

とはいえ、今C++の詳細な参考書はなかなか出版が減っているし、かつC++のファイルシステムライブラリだけで一冊の本が出るとも思えないので、書いておくべきだろうか。

この参考書が完成したら、アスキードワンゴから出版をすることを見込んでいる。

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-07-24

濫用にあたる職務質問を受けたと考えたので弁護士と現場検証してきた

承前

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

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

さて、弁護士と職務質問を受けた現場にいって当時の流れを再現してきた。

ところで、私は今回の濫用に当たる職務質問を受けたことを弁護士に相談して、裁判費用と弁護士報酬を合わせて61万円を支払った。こう書くと、にわかにカンパを支払いたいという連絡が何件もやってきた。61万円は少ない額ではない。幸い、私には貯蓄と収入があるので、生活に影響を与える出費ではない。

この問題に身銭を切ってまで感心を寄せる人間がこれだけいるのだという可視化のためにカンパを受け取るというのも考えたが、現在、生活が困窮しているわけでもなく、またこれ以上の出費が見込まれるわけでもなく、かつ出所のわからない金をあまり受け取りたくはないというのもある。第一その金は61万の支出と相殺して所得はなかった扱いにしていいのかどうか、よくわからないところもある。

そこで、私は日頃から私がカンパしたいと思っているが、クレジットカードを持っていないために積極的にカンパしてこなかった団体へ誘導する形を取りたいと思う。私にカンパを送りたいと思うのであれば、私に直接送るかわりに、私がカンパを送りたいと思っている団体に直接カンパを送ればよい。そうすれば間接的に私にカンパを送ったことになるだろう。

賛助会員・カンパ募集中 - 明るい警察を実現する全国ネットワーク

これは今回、私が相談した弁護士が運営している団体で、その趣旨は警察官の働きやすい環境を作ることにあるのだそうだ。結局、末端の警察官というのは、公式には存在を認めていない職質ノルマにより、本来必要のない職質をしなければならない状況に晒されており、そういった警察官の置かれている状況を改善することが本来の目的なのだそうだ。

この団体への寄付は、シンポジウムの開催費用などに使われるそうだ。

Support the Free Software Foundation | Free Software Foundation

自由ソフトウェア財団は、RMSが創始し、GNUというOSを始めとした自由なソフトウェアの開発を行っている。私はGNUのソフトウェアの恩恵を受けている。

Donate | The Linux Foundation

Linux財団はLinuxカーネルに関わる啓蒙や標準化を行っている。私はLinuxカーネルの恩恵を受けている。

OpenBSD: Donations

OpenBSDはOpenSSHを開発している。私はOSとしてのOpenBSDは使っていないが、sshは毎日使っているので恩恵を受けている。

ウィキペディア創設者ジミー・ウェールズからのお願い

Wikipediaは、その情報の正確性は担保されていないものの、読み物として面白く、私も常日頃から恩恵を受けている。

sponsor Vim development : vim online

Vimというのは素晴らしい万人向けのテキストエディターであり、私も毎日使っている。したがって私はとてつもなく恩恵を受けている。このブログの文章もVimで書いている。もしVimがなければ私のテキスト入力作業の生産性は著しく下がるだろう。Vimはウガンダへの寄付を呼びかけている。

さて、まだ他にもカンパすべき団体はいくらでもいるのだが、今回はこのぐらいにしておこう。

2017-07-14

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

去る7月3日の午後の通勤途中に、私は職務質問を受けた。その次第は以下のブログ記事に職務質問を受けた当日書いて投稿した。ただし、投稿時に日付を超えてしまったので投稿日時は7月4日になっている。

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

さて、振り返って見るに、私は先日の職務質問が警察官職務執行法第一条に規定された、「目的のため必要な最小の限度」を超えていて、「濫用」にあたるのではないかと考える。というのも、

  1. 「下を向いて歩いていた」、「帽子を目深にかぶっていた」という理由は、同法二条にある「合理的に判断して何らかの犯罪を犯し、若しくは犯そうとしていると疑うに足りる相当な理由」にはならない。
  2. 仮に「疑うに足りる相当な理由」であったとしても、職務質問を開始してかなり早い段階で、その疑いに対して「重い荷物を背負って長距離を歩いたので疲れたのではないか」、「人間は下ぐらい向くものだ」、「日差しが強く帽子をかぶるのは当然だ」と回答しているので、疑いに対して合理的な理由を与え、職務質問は中止されるべきであった。
  3. 当日は事件が起きて容疑者が付近を逃走中といったような、特に集中して職務質問を行うべき緊急の理由もなかった。
  4. 当日の路上は通行人がそれほど多くなく、私は路上に止まっていても「交通の妨害」にはならなかったので、無人駐車場という私有地に移動させる根拠はなかった。
  5. 一時間以上も停止させて同じ質問をし、自発的に任意の所持品検査に応じない限り停止を解かないのは「必要な最小の限度」を超えている。

もちろん、これは私の常識の範囲内で判断したことであり、あるいは濫用にあたらない最小の限度かもしれず、またこの行為が適法な職務質問とするべき根拠となる法律や判例が存在するかもしれない。そこで私は、弁護士に相談をすることにした。

世の中に弁護士は大勢いるが、特に似たような事例で裁判を起こしているような弁護士のほうが、関連する法律や判例をすでに調べた経験もあり、適切な判断ができるだろうと考えた。

また過去の判例を調べると、2013年に秋葉原で職質を受けてビクトリノックスを押収されたという件で争った判例がある。この裁判を担当した弁護士であれば適任であろうと考え、調べたところ、「明るい警察を実現する全国ネットワーク」という団体の清水勉弁護士であることがわかったので、早速連絡を取ることにした。

FrontPage - 明るい警察を実現する全国ネットワーク

連絡を取ったところ、さくら通り法律事務所の相談料は30分につき5400円ということであったので、相談をしに行くことにした。

さて相談をしたところ、弁護士の意見では、今回の件は職質を始めること自体が違法であったということであった。つまり上記の1.の段階で私の判断が正しかったということになる。

さて、職務質問が違法である可能性が高いことを確認した上で、今後の行動を決定しなければならない。もし職務質問が違法であれば、私の権利が不当に侵害されたことになる。ましてや私は通勤途中に毎回1時間以上停止させられたくはない。弁護士と相談した上で今後私が取りうる行動としては、以下の選択肢がある。

  1. 何もしない
  2. 警察に対して違法な職務質問であったと話し合いをする
  3. 人権擁護委員会や弁護士会を通じて警察に違法な職務質問であったと話し合いをする
  4. 違法な職務質問を受けたので賠償を求めて訴訟を起こす

権利の上にあぐらをかいていても意味がなく、憲法に規定された国民に保障された自由と権利を不断の努力で保持するためにも、私は裁判を起こして判決を出すのが最も適切な行動であると判断したので、裁判を起こすことにした。

その場で弁護士に裁判を依頼した場合の費用を算出してもらったところ、裁判費用、裁判のためにかかる経費、弁護士への報酬を諸々合わせて、合計61万円であるという。今回の相談料は61万円の中に含まれるそうだ。不断の努力のためであれば、61万円は出してもよい額だ。また、事前に調べたところ、裁判を起こすのにかかる費用は5,60万円であるらしいので、61万円は相場通りの適正な額であろうと判断した。

そこで、裁判を依頼した。

ところで、弁護士に相談したところ、職務質問にまつわる証明しようのない話をいくつか聞くことができた。与太話として興味深い。

まず、職務質問にあいやすいのは、男で、スーツを着ておらず、大きなリュックを背負っている人間であるという。私の状況に偶然一致する。

私に職務質問をした警察官は3人組で、一人は若く、二人は中年であった。主に私と話をしたのは中年のうちの一人で、若い警察官も若干の話をした。残る中年の警察官とはほとんど話をしなかった。

弁護士の推測によれば、私は警察官による職務質問の練習台にされたのだということであった。若い警察官に職務質問を練習させるために往来で職務質問をさせる。私とよく話した方の中年警察官は職務質問を指導する立場にあり、ほとんど話をしなかった方の中年警察官は、指導を監督する立場にあったのではないかということであった。ただ、警察官が3人いるのは珍しいことで、通常は指導役と練習生の2人組であるという。OJTじゃあるまいし。

警察官は、皆申し合わせたように「お願い」とか「説得」という言葉を一貫して使った。これは職務質問の訓練マニュアルの存在を示唆するものであるが、実際、そのような訓練マニュアルは存在するだろうということであった。

警察官は「平時から犯罪を未然に防ぐため、こうして一日に5,60件の職質をしているわけです」と発言した。犯罪を犯しそうな怪しい人間が都合よく安定して一日あたり5,60人発見できるのは不思議で、これは職務質問のノルマの存在を示唆するものである。弁護士は職務質問ノルマが存在するのではないかと考えているが、警察はこれまでにノルマの存在を認めていないのだそうだ。

私は職質をされた後も、平日は同じ帽子、同じ服装、同じリュックを背負って同じ道を同じ歩き方で通勤のために徒歩で移動している。いまだに職務質問を再現できていないが、今回の件で私は警察に職務質問をすると面倒な相手として認識されたので、今後、職務質問はされにくいであろうということであった。

最後に、裁判は時間がかかるので続報はもう少し先の話になるだろう。弁護士によれば、1年から1年半はかかるとのことであった。

2017-07-13

江添ボドゲ会 7月16日

今月も7月16日の日曜日に自宅でボドゲ会をする。場所は木場で、詳細は以下の通りconnpassで募集している。

江添ボドゲ会 7月16日 - connpass

ボドゲを毎月していきたい。

2017-07-04

警察官に職務質問をされた話

とても日差しの暑い7月、木場の自宅から銀座にある職場まで5kmの道を、5kgはある荷物を背負って徒歩で通勤していた。その日の私の出で立ちは、日焼けを防止するための大きな帽子、OD色の即乾シャツ、クライミング用のジーンズ風ストレッチパンツ、半長靴であった。勝鬨橋を超えて自販機で飲み物を買うと、急に警察官が3人近寄ってきた。

警察官「ちょっといいですか」
私「何ですか」
警察官「荷物の中を確認させていただきたい」
私「嫌です」
警察官「なぜですか」
私「応じる義務がないからです」
警察官「危険なものが入っているのではないですか」
私「入っていません」
警察官「では見せて証明してください」
私「見せる義務はありません」

このような問答がしばらく繰り返された挙句、私は出社をしなければならないのでその場を離れようとした。すると、警察官は回り込んで私の往来を妨害してくるではないか。人の往来を妨害するのは刑法に定められた犯罪である。

私「私の往来を妨害しないでください。犯罪です」
警察官「妨害していない」
私「では通してください」
警察官「まだ職務質問の途中だ」
私「すでに応じました」
警察官「リュックの中身を確認していない」
私「私に見せる義務はありません」

警察官はなおも執拗に私の往来を妨害した。私は警察手帳を出して、名前と階級を明らかにするよう要求した。警察官はこの要求に答えなければならないと法律上定められている。

3人の警察官は即座に、それぞれ警察手帳を出した。3人の警察官は、私のメモによれば、渦乃博之、井口?労人、晝?石健のような名前だった気がする。私のメモは適当に書きなぐったので細部の漢字が曖昧だ。特に?の前の文字は怪しい。3人とも階級は巡査長であった。認識番号はメモしなかった。

警察官「我々も名前を明かしたのですから、あなたも身分を明かしてください」

確かにそれは一理ある。もとより私に身分を隠すつもりはない。そこで私は予備自衛官手帳を出した。警察官はそのようなものを見ることに慣れていないらしく、私を現職の自衛官だと誤認した。手帳の表に「予備自衛官手帳」と書いてあるのに不思議なことだ。私は誤解する警察官に現職ではなく予備であることを説明した。

警察官の私の往来を妨害する行為はなおも激しくなった。私は往来を妨害して正面を塞ぐ警察官に対して、迂回をしようとしたが、迂回した方向にも回られた。その際、警察官の一人が、「公妨だ」とか、「あ、拳銃に触った」などとわざとらしく声を上げた。警察官が私の往来を回り込み、身をもって執拗に妨害しなければ、私は警察官の体に触れることはなかったし、拳銃のホルスターに手が当たることもなかっただろう。私は公務執行妨害をする意図はなく、拳銃に触る意図もなかった。

やがて、パトカーが到着し、さらに追加で6,7人ぐらいの警察官に周りを厳しく囲まれることになった。そして、最終的には脇道にある無人駐車場という私有地に移動させられた。

警察官「あなたは道の真ん中で通行の邪魔になっているから移動しましょう」
私「あなたが私の往来を妨害するという犯罪をしなければ私が道の真ん中で止まることはないのですよ」
警察官「妨害していません」
私「では私はいまから道を進みたいのですが通してくれますね。あ、移動するのは億劫でしょうから私の方から迂回しましょうか」
警察官「リュックの中身を見せてくれればすぐに通します」
私「リュックの中身を私が見せなければならない法的根拠を示していただければすぐにお見せします」
警察官「さっきから何度も同じことを言っているではないですか」
私「同じことを言っているのはあなたです」

警察官は私の往来を妨害し続けたが、往来を妨害しているということは否定した。

警察官は皆、一貫して法律にはない用語を使った。

私「私の往来を妨害するのは犯罪です」
警察官「妨害していない。現在、説得中です」
私「説得とはなんですか。どういう法的根拠があるのですか」
警察官「お願いをしています」
私「お願いとはなんですか。どういう法的根拠があるのですか」

警察官は、法的根拠について答えることはなかった。それもそのはずで、法律には「説得」とか「お願い」とかいった文言が使われているはずがない。この、「説得」、「お願い」という言葉は、複数の警官が一貫して使っていたので、おそらく警察の職務質問の訓練マニュアルにでもあるのだろう。

警察官「君には受忍義務(じゅにんぎむ)がある」

はて、「受忍義務」とは何だろうか。法律用語のようにもきこえるが、私の知る用語ではない。しかし、私は警察官職務執行法の全文を読んだことがある。その私が思い出せない用語なのだから、おそらく法律用語ではないのだろう。

警察官職務執行法

私「受忍義務とはどのような法律や判例で定められていますか」
警察官「いや、法律とか判例はどうでもいい」
私「なんと、警察官が法律や判例をどうでもいいというのですか」
警察官「違う。本官に対してではない。君に対して言ったのだよ」
私「なんと、警察官が一般市民に対して法律や判例をどうでもいいというのですか」
警察官「そうじゃなくて」

「公妨」、「あ、拳銃を触った」に引き続き、とんでもない発言が出てきた。主語がどちらにあるにせよ、この警察官は法律や判例はどうでもいいそうだ。

私「受忍義務を定めた法律や判例を教えてください」
警察官「法律や判例ではなくて、職務執行を遂行するにあたり必要であるという解釈である」
私「解釈? 法律や判例ではなく」
警察官「そうだ」
私「法的根拠はないんですね」

警察官は、嘘をつかず、受忍義務に法的根拠があるとは言わなかった。捜査に必要であるという解釈だと主張した。

ちなみに、あとで調べたところ、受忍義務とは法律用語ではなく、また直接判例によって支持されている概念でもないようだ。警察は長年、この不文律の受忍義務というものが存在するという法律の解釈を主張している。

警察官「法的根拠は職務執行法第二条に基づいています」
私「ならば、その一条にある濫用をしてならないという条項も守っていただきたい」
警察官「濫用していません」
私「では私の往来を妨害しないでいただきたい」
警察官「妨害していません。説得しています」
私「説得は非法律用語です」

そして議論は堂々巡りを繰り返す。そもそも、なぜ私が職質を受けているのか。私を怪しむに足る納得できる理由があればもちろん自発的に協力してもよい。

私「なぜ私を職務質問しているのですか」
警察官「本官が怪しいと思ったからです」
私「現在、付近で事件が起きて容疑者が逃走中ですか。それでしたら納得の行く理由ですので持ち物検査にも協力します」
警察官「違います」

警察官は嘘をつくことができないという制約がある。少なくとも、法的根拠や現在発生中の事件について、嘘をつくことはできない。後々問題になるからだ。実際、警察官は用心深く、この点において嘘をつくことはなかった。法的根拠について答えられない場合は押し黙ったり話をそらした。

私「私のどういう兆候が怪しいと思ったのですか」
警察官「うつむいて、下を向いて歩いていた」
私「うつむいて下を歩くのは犯罪ですか」
警察官「違います」
私「犯罪者はうつむいて下を向いて歩きやすいものだという統計結果はありますか」
警察官「薬物中毒者はよくうつむいて下を向いて歩くものだ。本官は薬物中毒者を多数見てきた経験論から知っている。君とは社会経験が違うのだよ」
私「薬物中毒者ならば私も以前、シェアハウスに住んでいて何人も見たことがありますが、そういう傾向はありませんでしたね」
警察官「本官は何百人もの薬物中毒者を見ている。君がみた薬物中毒者はそうでなかっただけだ」

私はこの日差しの強い炎天下の中、5kgの荷物を背負って5kmの道のりを歩いてきたのだ。疲れてうつむきがちなのは仕方がないではないか。あるいはうつむいて歩くのは私の癖かもしれない。何にせよ、下を向いて歩いているだけで怪しいというのは、私の納得できる理由ではない。日本国民は下を向いて歩いてはならないという法はない。

警察官「君は帽子を目深にかぶっていて顔が見えなかった」
私「この強い日差しの中、帽子をかぶるのは当然でしょう」

この理由も、私が納得して自発的に持ち物検査に応ずるほどの怪しむに足る理由ではない。日本国民は帽子をかぶってはならないという法は極めて限定的な状況においてしかない。例えば衆議院規則と参議院規則には議場に入る議員は許可なく帽子をかぶってはならないと書かれているが、私は議員ではないし、ここは義場でもない。

警察官「警察官に職務質問をして大声を上げ、その場から逃げようとしたのは怪しい」
私「よく訓練された私のよりも背丈の高い男が3人がかりで私の体を掴み、往来を妨害するのであれば恐怖ぐらい感じるでしょう。それに私に応じる義務はありません」

これも私が怪しい理由として納得できない。

警察官「あなたも社会人で働いているのならばわかるでしょう。リュックの中身を見せてくれればすぐにでも行ってもらって構いませんよ」

法的根拠に基づかず往来を妨害し、義務ではない行為を行うまで拘束する警察官というのは私の社会人としての常識ではわからない。

警察官「なぜ持ち物を見せないのですか」
私「見せる義務がないからです」
警察官「見せると問題になるものがあるのではないですか」
私「ありません」
警察官「では見せて証明してください」
私「見せる義務はありません」
警察官「見せて問題のないものしか持っていないのならば、なぜ見せないのですか」

この質問をした警察官は、私のプライバシー権に対する理念(隠すものがないならば全て見せてもよいという論法はなぜ間違っているのか)、憲法論、はては日本国憲法は日本国民が不断の努力で守らなければならないとしているが、日本は国民に武器を持つ権利を認めていないので現行の法律はおかしい。私はアメリカ合衆国の修正憲法第二条にある規律ある民兵の条項に賛同するものである。しかし私は法律を守る善良な日本国民であるので現行の法律にはもちろん従っていて武器は持っていないなどという私の思想を延々と聞かされることになった。

警察官「あなたは今までに軽犯罪法で捕まったことはありますか」
私「ありません。ただし私は法律のすべてを暗記しているわけではないので過去に法律に抵触した行動をした可能性はあります。しかし、仮にそうであったとしても、私に犯罪を行う意図はなかった。なぜこのようなことを言うかと言うと、マイナスドライバーを持っていただけでピッキング用具として軽犯罪法で捕まった事例を知っているからだ。今、私のリュックの中にマイナスドライバーはおそらく入っていないはずだが、私は日常的にマイナスドライバーを使うのでひょっとしたら入っているかもしれない」
警察官「あなたの場合、マイナスドライバーは正当な理由があると認めます」
私「ペーパーナイフや尖った鉛筆などは」
警察官「それも正当な理由として認めます。ここにこれだけ警察官がいるのだから変なことはしません」
私「信じたいところですが、あなたはさっき、法律や判例はどうでもいいから、と言いましたね」
警察官「そうじゃない。ほら、この警官も帽子を脱いで頭を下げますから」
私「頭を下げたその警察官はさっき、公妨とか、あ、拳銃を触った、と言いましたね」

法律は無数にあり、すべての法律に抵触しないなどおよそ無理な話だ。例えば日本国政府は公共建築物等における木材の利用の促進に関する法律に常に違反し続けている。本来、木造でもよいはずの公共建築物を木造にしないことがあるのだから。

公共建築物等における木材の利用の促進に関する法律:林野庁

やがて、現場に追加でやってきた警官は去っていった。そして最初に私に職務質問をした3人の警官だけが残った。

パラノイアというTRPGのゲームがある。基本的には理不尽な圧迫面接をのらりくらりとかわしつづけるゲームなのだが、この今の取り調べはまさにパラノイアのセッションを彷彿とさせる。ただしパラノイアと違い、警察は嘘をつけない、警察は何時間でも私を路上に拘束し続けることができるのでセッションをやめられない、という制約はあるのだが。

さて、私は警察官職務執行法をすべて読んだことがあり、パラノイアのルールブックもすべて読んでいて、GM経験もあるので、このパラノイアのセッションのような不毛な議論(私の権利が不当に侵害されているので不毛ではないのだが)をいくらでも続けられるのだが、いい加減に職務執行法の一条を守って濫用をやめるか、自発的に捜査に協力するだけの納得できる理由を提示してほしいものだ。例えば、今ここで私がナイフを持っているのを見たと言ったのであれば私は自発的に捜査に協力するだろう。というのも、私はいかように悪意をもって解釈してもナイフだとは認定できないものしか持っていないのだから、ナイフを見たと信ずるに足る理由などあるわけがなく、真っ赤な嘘だとわかる。

しかし、警察官はよく訓練されていて注意深く嘘を避けていた。存在しない法的根拠を挙げることはない。何の法律や判例の支持もない受忍義務については解釈であると正しく答える。「法律や判例はどうでもいい」とぃうのは、およそ警察官にあるまじき発言ではあるが、意見であって嘘とか本当とかいった性質のものではないだろう。「あ、銃に触った」という発言は嘘ではないのかもしれない。ただし道を塞ぐ警察官を避けようと左に移動した私の往来を妨害する形で銃のホルスターをつけている右腰を私に押し付けたので、仮に私が銃を触ったとしても、それは私の意図ではないし私に責任はない。

嘘だと私が判断した発言は、「公妨だ」、「濫用していない」、「往来を妨害していない」ぐらいなものだろうか。

さて、駐車場という私有地に停止されての職務質問は2時間弱ほど続いた。警察官職務執行法に定められている濫用というのは、一体、何時間の停止からを言うのであろうか。

結局、最終的に警察官の提案した、リュックの上から触って調べることで怪しいものがないかどうか所持品検査を行うというのが、個人的に面白かったので、その方法で検査をさせることにした。

私「そんな方法で怪しいものがあるかどうかわかるものですかね」
警察官「私にはわかります。これはなんですか」
私「万年筆ですね」
警察官「あとで壊したとか言わないでくださいよ」
私「触っていいとは言いましたが、壊していいと言った覚えはありませんね」
警察官「これは何ですか」
私「メガネケースですね」
警察官「メガネケースの中に薬物を隠すというのはよくあることです。出して見せてもらっていいですか」
私「応じる義務はありませんね」
警察官「これは何ですか」
私「ラップトップですね」
警察官「ラップトップとはなんですか」
私「ノートPCとも呼ばれていますね」
警察官「これは何ですか」
私「ラップトップのケースですね」
警察官「ノートPCのケースがこんなに小さいものですか」
私「12.6インチでとても薄いラップトップです」
警察官「これは何ですか」
私「何でしょうねこれは。ああ、コンセントですね。ラップトップのACアダプターの」
警察官「とても重いリュックですね」
私「ラップトップ2台と周辺機器が入っていますからね」

そして開放された。

そういえば、私が人生で初めて職質をされたときは、神保町に行きたくて神田駅で降りたが、行き方がわからず、その近くの交番に大きな地図が見えたので、見るために入ったときであった。ちょうど秋葉原でナイフを振り回した事件の記憶もまだ浅い時期であった。

警察官「ちょっといいですか、荷物の検査をさせてください」
私「なぜですか」
警察官「最近物騒ですからね。ちょっと前も秋葉原でナイフを振り回す事件がおきましたし」
私「これから犯罪を犯そうという人間がわざわざ交番に立ち寄るのですか」
警察官「いえ、念のため・・・はい終わりました」
私「神保町へ行くための地図を見たかっただけなのに不思議だ」
警察官「なぜ早く言ってくれないのです。道は・・・」
私「地図さえ見れればそれでいいのです」

2017-06-19

マストドンとアカウント削除機能の是非について

マストドンの1.4.1に入ったアカウントの削除機能について、friends.nicoではまさらっきがアカウント削除機能を無効にした上で、本家にもアカウント削除機能の無効化を選択できるようにするPRを投げている。

setting-for-account-deletable by masarakki · Pull Request #3852 · tootsuite/mastodon

もし、ユーザーがアカウントと全データの削除を希望した場合、ユーザーの意思を尊重するインスタンスは当然ユーザーの希望通りに全データを完全に復旧不可能な方法で削除すべきだ。しかし、人間は完璧ではないので、様々な問題が起こる。ユーザーが後から削除を取り消したいとしても、それはもう不可能だ。

特に、ハラスメントが関わると問題はややこしくなる。

ユーザーに手軽にアカウントを削除できるUIが与えられていると、垢消せハラスメントが起こる。大抵の人間は貧弱なので、ハラスメントによって発生するストレスに対処できず、ハラッサーの要求に従い、アカウントを消してしまう。後日、思い直した貧弱な人間がアカウント削除の取り消しを希望しても、ユーザーの意思を尊重するインスタンスはすでに復旧不可能な方法でデータを削除してしまっているので、不可能だ。

垢消せハラスメントは、お手軽なアカウント削除UIがユーザーに提供されていなければ起こり得ない。アカウントの削除をするには管理者である人間に連絡を取って頼むぐらいのハードルの高さがあればこの手のハラスメントは起こらない。

しかし、これは根本的に何の問題も解決していない。発言を消せハラスメントとか、もうログインするなハラスメントとか、回線切って首吊って氏ねハラスメントは依然として起こる。根本的には、ハラスメントを抑止すべきだが、そのためには全発言を事前に完璧に検閲しなければならず、そんなことは不可能だ。ハラスメントを毅然として跳ね返す強い精神力を身につけるべきだが、残念ながら、そういう強い人間は数えるほどしか存在しない。そもそもメンタルが強い人間というのは何を言われても気にしないサイコパスであることも多い。

私は人間は強い精神力を持つべきで、アカウント削除機能は手軽にUIとして提供されているべきだと考えるが、この問題は理想ではうまくいかないようだ。

ドワンゴ広告

ドワンゴではhttps://friends.nico/というマストドンのインスタンスを立てているようです。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-06-05

ミニミニ入居安心サービスはクソだ

今いる賃貸物件は、私の嫁と大家との間に、株式会社ミニミニ中央という不動産屋が仲介に入って賃貸契約したものだ。なぜ私の名義で契約していないかと言うと、私は電話番号を所有していないため、保証会社が審査を拒否したためだ。審査に落ちるどころではない。審査の拒否だ。しかし、なぜか私の嫁名義で保証会社の審査を出したら、私を保証人に加えろと言ってきた。審査を拒否するほどの信用のない人間を保証人には加えるほど信用するのは不思議だ。

引っ越して2年たち、事前の契約通りに更新手続きの書類が株式会社ミニミニ中央から送られてきた。内訳は不動産業界の謎の慣習に従って、以下の通りだ。

  • 更新料(契約を維持して住み続けるだけで借り主がカネを払うのかよ? 更新料があるために引っ越されたら大家も家賃をとりっぱぐれて損するんだぞ?)
  • 火災保険料(俺が所有していない不動産の保険を借り主たる俺が払うのかよ?)
  • 保証料(家賃不払いのリスクを負うのは大家なのに保険金は借り主たる俺が払うのかよ?)
  • ミニミニ入居安心サービス料 16200円(なんだこれ?)

他の名目のカネはまだ納得できるとしても、「ミニミニ入居安心サービス」なる名目のカネは謎だ。一体何なんだこれは。

契約書類についてきたパンフレットによれば、「ミニミニ入居安心サービス」なるものは、以下のようなサービスらしい。

  • ホテル、飲食店、レジャー施設、レンタカーなどの割引クーポン(いらね。使うつもりもない)
  • 24時間365日対応の無料の相談コールセンター(後述)

結論として、この「ミニミニ入居安心サービス」は全く何の意味もないクソで、デフォルトopt-outで無効から提示されたとおりの契約で契約するしかないと思いこんでいるバカからカネをむしり取るための罠だった。

コールセンターは何の薬にも立たない。鍵とか水回りとか電気周りのトラブルの際に連絡すると、業者を派遣してくれるだけのサービスだ。業者はもちろん有料だ。

さらに、その内容も本当に意味がない。例えば、電気のトラブルで何をするかと言うと、ブレーカーの上げ下げだけだ。パンフレット曰く、

ブレーカーの仮復旧で解決しない、建物設備に関するトラブルは、大家様または管理会社様にご連絡ください。

何の意味もない。

そもそも、我々は単なる借り主であり、不動産を所有していない。不動産の不具合を修正するのは当然、大家の金で行うべきだ。仮に我々の金を使って建物を修繕、改修するとしてもだ、我々が所有していない不動産なのだからまず大家に交渉するだろう。

実際、この2年間住んでいて色々と電気周りの不具合には見舞われている。たとえばエアコンがショートしたため、エアコンのブレーカーを上げると即座にブレーカーが落ちる不具合があったので、これは大家にエアコンを取り替えさせた。また、新品の蛍光灯に取り替えても何故かある箇所の電灯が不意に消える不具合があったので、これも直させた。いずれも大家に交渉した上で、大家が契約している業者が作業に当たった。

するとこのコールセンターの価値はなんだろうか。

また、このサービスには、パソコンの不具合対応とかストーカー相談とか、やはりこれまた役に立たなそうなサービスがある。パソコンの不具合対応はもちろん業者に連絡するだけだ。

また、盗難時の補償というのもあるが、これはどうも盗難にあった時に引っ越す際の引越し費用を補助するだけで、盗難被害額の補償ではないようだ。そもそも盗難にあった時に引っ越しをするだろうか。執拗に付け狙われていて小物がちょくちょく盗難にあうとかいうストーカーのような盗難ならまだしも。

というわけで、ミニミニ入居安心サービスを我々は利用していないし、今後も利用するはずがないことが確認できた。これは大家ではなくて不動産屋である株式会社ミニミニ中央との契約になるので、早速交渉に入る。交渉には不動産屋の大好きな旧世紀の連絡手段である電話が用いられた。

「契約更新にあたり、ミニミニ入居安心サービスはいらない」
「ではその料金を含まない額をご入金ください。キャンセルしておきます」

何の抵抗もなく、間髪を入れずにこのような対応となった。ますます怪しい。

おそらく、これはデフォルトopt-outな契約にして、提示された契約をそのまま飲まざるを得ないと思っている情弱を騙して金を余計にむしり取るためのいやらしい手段に違いない。私のミニミニに対する信用が一気になくなった。とりあえず今は継続して済むとして、いずれ引越し先を探すことにしよう。

2017-06-02

江添自宅ボドゲ会6月11日

6月11日に自宅でボードゲーム会を開催することにした。

江添ボドゲ会6月11日 - connpass

最近のお気に入りのボードゲームとしては、電力会社のカードゲーム版やナショナルエコノミーメセナがある。

2017-05-11

constexpr ifの落とし穴

会社の同僚から、以下のようなコードが動かない、ネット上をググると解決策らしきものが見つかるがそれもいまいち納得できない、という相談を受けた。

template < typename T >
void f()
{
    if constexpr ( std::is_same<T, int>{} )
    {
        // Tがintのときのみ発動してほしい
        // 実際は常に発動する
        static_assert( false ) ;
    }
}

C++17にはconstexpr ifが追加された。これは条件付きコンパイルではない。条件付き実体化抑制だ。

constexpr ifは以下のように使う。

struct S
{
    int value() { return 42 ; }
} ;

template < typename T >
int to_int(T t)
{
    int value{} ;
    if constexpr ( std::is_same<T, S >{} )
    {
        value = t.value() ;
    }
    else if constexpr ( std::is_integral<T>{} )
    {
        value = static_cast<int>(t) ;
    }

    return value ;
}

int main()
{
    f(42) ;
    S s ;
    f( s ) ;
}

to_intは引数からint型の値を取り出すための関数だ。クラスSの場合、int型を取り出すためにメンバー関数valueを呼び出す特別な処理をする。

これをみると、constexpr ifは条件付きコンパイルのように思える。つまり、if文によって選択されるブランチのみをコンパイルする機能だ。しかし、それは間違いだ。

constexpr ifは選択されないブランチのテンプレートの実体化を抑制する機能だ。

テンプレートは、まず宣言を解釈され、その後、具体的なテンプレート実引数を与えられて実体化する。

template < typename T >
void f( T t )
{
    t.func() ;
} 

int main() { }

この例では、Tにint型を渡すとエラーとなる。なぜならばint型はメンバー関数funcを持っていないからだ。

しかし、この例はコンパイルエラーにならない。なぜならば、テンプレートfのテンプレート実引数にint型は渡されていないからだ。

テンプレートは、具体的な型をテンプレート実引数として渡され実体化して、初めてコードが正しいかどうか検証される。

というのは間違いで、テンプレートは宣言の時点でもコードが正しいかどうかを検証される。

template < typename T >
void f(T t)
{
    // エラー、名前gは宣言されていない
    g( 0 ) ;
}

template < typename T > void g( T ) { }


int main() { }

この例はエラーになる。なぜならば名前gは事前に宣言されていないからだ。C++は名前を使う際には、事前に明示的な宣言を求める言語だ。

しかし、以下のような例はエラーにならない。


template < typename T >
void f()
{
    // エラーではない
    T::g() ;
}

これはなぜかと言うと、名前T::gはテンプレート仮引数Tに依存しているからだ。テンプレート仮引数Tに依存している名前は、Tの具体的な型が与えられるまで、コードの合法性が検証できない。そのため、そのようなコードの検証はテンプレートの実体化まで遅延される。

まとめると、テンプレート仮引数に依存しないコードはテンプレートの宣言時に検証され、依存するコードはテンプレートの実体化時に検証されるということだ。

これを踏まえて、以下のコードが動かない理由を考えてみよう。


template < typename T >
void f(T t)
{
    if constexpr ( false )
    {
        // エラー、名前gは宣言されていない
        g() ; 
    }
}

名前gはテンプレート仮引数に依存していないため、テンプレートの宣言時に検証される。その結果、エラーとなる。

ここまでくれば、冒頭のコードが意図通りに動かない理由もわかるはずだ。

template < typename T >
void f()
{
    if constexpr ( std::is_same<T, int>{} )
    {
        // Tがintのときのみ発動してほしい
        // 実際は常に発動する
        static_assert( false ) ;
    }
}

static_assert(false)はテンプレート仮引数Tに依存していないため、テンプレートの宣言時に検証され、エラーとなる。

ではどうすればいいのか。たんにstatic_assertの中にconstexpr ifと同じ式をいれてやればよい。

template < typename T >
void f()
{
    static_assert( std::is_same<T, int>{} ) ;

    if constexpr ( std::is_same<T, int>{} )
    {
        // ...
    }
}

しかしこれは同じ式が重複してよろしくない。式を変えたいときは二箇所を同時に変更しなければならない。

式の重複を防ぐには、変数を使ってやればよい。

constexpr bool cond = expr ;
static_assert( cond ) ;
if constexpr ( cond ) { }

しかし、if文というのはネストさせたいものだ。

if constexpr ( E1 )
    if constexpr ( E2 )
        if constexpr ( E3 )
        { }
        else if constexpr ( E4 )
        {
            // static_assertしたい。
        }

このような複雑なネストしたif文に相当する式を書くのは面倒なので、constexpr ifの中に入れて、そのブランチが実体化されるときのみstatic_assertが働くようにしたい。

そのためにはどうすればいいかというと、static_assertのオペランドの式を依存式にすればよい。そうすればテンプレートの実体化まで評価を遅延させることができる。constexpr ifに囲まれていてテンプレートが実体化しないのであればstatic_assert(false)も発動しない。

using < typename ... >
constexpr bool false_v = false ;

template < typename T >
void f( T t )
{
    if constexpr ( std::is_same<T, int>{} )
    {
        static_assert( false_v<T> ) ;
    }
}

false_vというのは任意の型を取って常にfalseを返すテンプレートconstexpr変数だ。このテンプレートにテンプレート引数を与えてやれば依存させることができる。結果として、この関数fはTがint型のときのみstatic_assertを発動させる。

現在書いているC++17の参考書には、このような落とし穴も含めたC++17の新機能の解説を書いている。なるべく早く書き上げたい。そして、最近、C++の規格を学びすぎたために、こういうC++の初心者が陥りがちな落とし穴が何なのか自分ではわからなくなってしまっている。C++の落とし穴を教えてほしい。

2017-05-10

Rustのパッケージマネージャーでパッケージ名nulを作ったら全Windowsユーザーのパッケージマネージャーが壊れた話

How I Broke Rust's Package Manager for All Windows Users - sasheldon.com

非Windowsユーザーが何気なくRustでnulという名前のパッケージを作って公開した。すると、全Windowsユーザーのパッケージマネージャーが壊れた。

理由は、nulという名前はWindowsでは予約語だからだ。Win32サブシステム経由で、どのディレクトリであれ、nulというファイル名を使おうとすると、それはGNU/Linuxでいう/dev/nullと同じような扱いになる。nulに拡張子がついていても同じだ。

RustはWindowsサポートも重視しているので、これに対処してWindowsの予約語を禁止する変更がなされた。

Reserve windows crate names. by withoutboats · Pull Request #695 · rust-lang/crates.io

これはWindowsがクソだが、他のOSでもファイルシステムには様々な技術的な柵がある。例えばMac OSのファイルシステムはUnicode正規化が特殊でクソだし、POSIXの多くのコマンドは-をSTDINやSTDOUTとして特別扱いする。また、bashは/dev/tcp/host/portというファイル名でhost:portに対するTCP接続を行う。

マイクロソフトのWindowsに付属しているアンチマルウェアソフトウェアが最高にクソな件

マイクロソフトのWindowsに付属しているマイクロソフトが提供しているアンチマルウェアソフトウェアに脆弱性が発覚した。

1252 - MsMpEng: Remotely Exploitable Type Confusion in Windows 8, 8.1, 10, Windows Server, SCEP, Microsoft Security Essentials, and more. - project-zero - Monorail

脆弱性の発覚はよくあることだ。脆弱性というのは、大抵はバッファーのサイズチェック漏れなどの些細な間違いが原因となる。

今回のMSのアンチマルウェアの脆弱性も、根本的な原因としてはそのようなチェック漏れなのだが、起こるべくして起こったクソすぎる実装のせいで、そのような些細な間違いが実用的な脆弱性に発展してしまっている。そのようなチェック漏れが存在するだけでは実用的な脆弱性に発展しない。そのチェック漏れを悪用できるようなコード実行ができる状況が存在することで、実用的な脆弱性に発展する。

MSのアンチマルウェアソフトウェアには、NScriptというJavaScript風のインタープリターが入っている。これによってあるJavaScriptコードが既知の悪意あるソフトウェアのパターンに一致するかどうかを調べている。JavaScriptはいくらでも同等内容になるように変形可能なので、実際に実行しなければパターンに一致するかどうかわからない。したがってこのように実際に実行して挙動がパターンに一致するかどうか調べる仕組みが必要になる。

問題は、このインタープリターは極めて強い権限で実行され、サンドボックス化もされていない。これはセキュリティソフトウェアとして問題外の実装だ。任意の悪意ある可能性があるコードの挙動を実際に実行して調べるのに、不必要な権限の放棄や適切なサンドボックス化を行っていないのはありえない。

かつ、MSのアンチマルウェアソフトウェアはファイルシステムの変更を監視していて、ファイルシステムのどこに書き込まれようと、JavaScriptっぽいコードは全部、このNScriptインタープリターで実行して、パターン検出を行おうとする。これは任意のブラウザーなどのソフトウェアのキャッシュなどにも対応できるための実装だ。しかし、これによって、ファイルシステムにさえかきこめれば、どのような方法であっても脆弱性をつくコード実行が可能になる。

結果として、マイクロソフトのアンチマルウェアの脆弱性を悪用するには、悪意あるJavaScriptコードをメールで送る、Webブラウザーで閲覧させるなどの何らかの方法で、ファイルシステム上に書き出させればよい。ユーザーがメールを実際に閲覧するとかソフトウェアを実行するといった操作は必要がない。

あるJavaScriptコードが悪意あるものであるかどうかを実際に実行して調べるセキュリティ対策のソフトウェアが存在するせいで強い権限による任意のコード実行につながるというのは、極めて皮肉だ。

私が平生から主張しているように、アンチマルウェアソフトウェアというのは詐欺だ。使ってはならない。アンチマルウェアソフトウェアはセキュリティではない。世の中のすべてのアンチマルウェアソフトウェアは実装がクソだ。アンチマルウェアソフトウェアを使った人間

「追加のソフトウェアは追加のリスク」という古き良きシステム管理者の格言はなぜ失われてしまったのか。

超会議2017でマストドンブースの運営スタッフをした

私は江添亮、ドワンゴ社員だ。超会議2017で運営スタッフをした。このブログ記事は個人的なものだ。株式会社ドワンゴの見解ではない。こう書かなければならないのは悲しいことだ。結局、国語教育で存在しない作者の意図を答えさられた人が多いようだ。ちなみに、この文章はマストドンとfactorioがやりたくて仕方がない合間を縫って後ろ髪を引かれながら書いた。もし将来、この文章を使って「作者の意図を答えよ」という問題が出題されたときには、「作者はマストドンとfactorioの中毒者であるが我慢しながらこれを書いた」と答えるのが正解だ。

超会議2017リハーサル

概要 | ニコニコ超会議2017 公式サイト

超会議2017での私の割当は、神エクセル方眼紙で公開された。自由な表計算ソフトウェアであるLibre Officeでみてみると、私はゲームエリアにアサインされていた。

やった。事前に提出した希望通りだ。ああ、入社して苦節3年、ようやく希望通りのアサインが行われた。ハッカソンやら馬車やら焼きそばやらと、私は常に変わった場所に割り当てられていた。それがようやく、ゲームエリアのアナログゲームブースでボードゲームのインストをするスタッフになったのだ。今度の超会議では好きなボドゲのインストができる。

そして、ドワンゴがマストドンのインスタンス、friends.nicoが公開された。そして全てが変わってしまった。

マストドンは面白い。なるほど、マストドンは技術的にはクソだ。しかし面白い。しかも自由だ。マストドンには未来がある。Twitterの時代は終わった。これからはマストドンが圧倒的に流行する。既存の不自由なSNSは滅びる。

そして、超会議開催の直前の土日に、マストドンブースの設営が決定された。これは行くしかない。強引に根回しをしてブースのリアサインをする。ああ、せっかく希望通りのボードゲームのインストスタッフになれたのに。いやしかしこれもマストドンのためだ。

超会議前日、リハーサルのために幕張メッセに行き、マストドンブースを確認する。いかにも急造したらしきブースがぽつねんとある。大きめのディスプレイがあり、friends.nicoのLTLをニコニコ動画風の右から左に流れるコメント形式で流している。

私は引き戸になっているブースの下を改めた。ここがマストドンブースであるならば、当然あるはずだ。人権が、インターネット回線が。あるはずだ。果たしてEthernetポートはあった。ある。人権がある。当日はライブマストドンができるぞ。

マストドンブースの確認と、ユーザー記者の控室などにマストドン体験端末の設置などの雑用をする。あとは超会議のリハーサルの体験だ。

超人スポーツのジャンピング竹馬が面白かった。アマゾンで中国製が2万で売られているので、即座に購入した。届くのが楽しみだ。ただし、これはだいぶ危険なので、プロテクターとヘルメットを用意した上で、受け身の練習もしなければならないと思っている。

そして、マストドン会議に参加した。

本の虫: マストドン会議で技術と自由を語る

マストドン会議ではマストドンの実装とプロトコルの設計がいかにクソか、そして自由の素晴らしさを語った。

マストドンは自由だ。自由は素晴らしい。

TwitterはTwitter社が独占している。そのため、Twitterがお前のアカウントをBANすると言ったならば、お前のアカウントはBANされる。お前の相撲取り画像は肌色成分が多いのでエロ画像だと言われたならば、それはエロ画像だ。Twitterに逆らうことはできない。

マストドンでは誰もがインスタンス(サーバー)を立てられる。あるマストドンの運営が「お前の相撲取り画像は・・・」などと馬鹿なこと言い出したら、そんなインスタンスは使わなければよい。どのインスタンスも機に食わなければ、自分でインスタンスを立てればよい。自由を保証するには拒否できる力が必要だ。

これは政治家や政党にとっても都合がいいだろう。ご存知の通り、アメリカ大統領選挙ではTwitterやFacebookが恣意的な検閲を行い、トランプとヒラリーのどちらかに有利な検閲を行った。マストドンではこういう恐れがなくなる。政党や候補者自らインスタンスを立てればよいのだから。

近々マストドン会議2が行われるらしく、ドワンゴからも2人ほど発表するそうだ。なんとか次も発表枠で潜り込めないか交渉している。

超会議

超会議では、私はひたすらマストドンブースに張り付いてマストドンの宣伝を行った。

マストドンブースは超演奏してみたブースの向かい側で、始終うるさかった。なかでも特に多くかかった音楽は、けものフレンズの主題歌と、逃げるは恥だが役に立つの主題歌だった。

超会議では様々な人間がマストドンブースを訪れた。特に印象深かった人間が何人かいる。

マストドンブースにほぼ張り付いていた人間がいた。マストドンの中毒性を考えればコレは当然のことだ。

マストドンをしていて、しかもプログラミングのできる中学生や高校生がやってきた。私は自由なコンピューターの必要性を説いた。プログラミングをするには自由なコンピューターが最も便利だ。不自由なコンピューターではろくなコードが書けない。第一、不自由なOSはその動作を確認できないし、改造もできない。

ある中学生は、プログラミングに興味があるが、いまは不自由なコンピューターであるスマフォしか持っていないといった。私はぜひとも自由なコンピューターを買い、その上の自由なOSをインスールして、プログラミングを本格的に学べと教えた。その子はママに相談すると言って帰っていった。

お母さん、息子の将来のためにはプログラミングができるべきだ。そのためには自由なコンピューターを使うべきだ。

ある高校生はRaspberry PiにDebianを入れて使っているという。ああ、私が高校生の頃にRaspberry Piがあればなんと良かったことだろうか。今の子どもたちは恵まれすぎている。そんな恵まれた環境で育った子どもたちが社会に出る頃には、我々のような老人プログラマーは皆、戦力外通告を受けることだろう。未来は明るい。

マストドンブースに来た政治家達

重ねて書くが、これは私の個人的なブログであって私が雇用されている会社の見解ではないし、書かれている以上の「作者の心情」とか「作者の意図」を見出してはならない。

さて、超会議ではマストドンブースに二人の政治家が来た。政治家であるという理由だけでわざわざ書くというのは、これから私が主張する内容と矛盾する。しかし彼らは政治家であるために例外的な対応を求めたので、例外的に書いてもいいだろう。

東京都知事の小池百合子

急に、マストドンブースにスーツが近寄ってきて、「都知事の小池百合子がまもなくやってくる」と私に告げた。私は事前に連絡を受けていない。上司に連絡を取ると、「把握している。小池百合子のスケジュールは警備上の理由で秘密である」と告げられた。

やがて、怒涛のように小池百合子とその取り巻き御一行様がやってきた。まるで北朝鮮の総書記の視察を受けているかのようだ。小池百合子の周りをスーツが厳しく取り囲んでいる。その中心に光るように目立つ小池百合子。一触即発のアトモスフィア。スーツのうちの何人かは物理的なペンと物理的な紙のメモ帳を手にして激しく首を縦に振りながら何やら一心不乱に書き込んでいる。上司が小池百合子にマストドンの説明をする。そして、小池百合子が去っていった。まるで嵐がやんで晴れ渡ったかのような安堵感が広がる。

これは文化に対する理解と尊敬がない。超会議は誰であれ身一つでそのへんをフラフラと歩いて楽しむべきだ。実際、有名人が何人もそれと気づかれずにフラフラと周りを歩いているのを私は何度も目撃している。小池百合子の査察を受けている間、そのホールは厳しい警戒態勢になり、乗合馬車なども待機を余儀なくされた。都知事ともなると身辺警護が厳しいのはわかる。それはわかる。しかし、文化への尊重も必要だ。

民進党の枝野幸男

超会議2日目の開始直後、急に、マストドンブースにスーツが2,3人ほど近寄ってきて、「これから・・・のユキオが来る」と私に告げた。はて、一体何のユキオだろう。周りが騒がしくて聞き取れない。重ねて聞くが、やはり「・・・のユキオ」としか聞き取れない。名前よりもその役職のほうが重要だ。私はその名前を知らない可能性のほうが高いのだから。

スーツが去ろうとするので慌てて呼び止めて再度聞くと、今度は、「エダのユキオです。政治家の」と答えた。エダのユキオ・・・、なるほど、助詞の「の」ではなく、民進党の枝野幸男(えだのゆきお)か。

もし枝野幸男本人が何も根回しをせず無名の一般人としてやってきたのならば、私も通常通りマストドンの説明と、マストドンのソフトウェア実装が自由であることの価値を説いただろう。しかし、そのような特別対応を求めるのであれば、やはり私としても上司に連絡をする。

上司からの返事がないまま、スーツが再びやってきた。「今から15分後に枝野幸男が来る」ということを私に告げた。

スーツ曰く、「枝野幸男はマストドンにアカウントを作ることを所望している。いまブースに設置してるコンピューターで枝野幸男のマストドンのアカウントを作ることは可能か?」

可能か? 技術的にはイエス。セキュリティ的にはノー。もちろん答えはノーだ。

自分のアカウント登録は自分の所有するコンピューターで行うべきだ。なにしろ、メールアドレスへのアクセスが必要なのだから。

程なくして枝野幸男本人がマストドンブースにやってきた。物々しい目立つ護衛や取り巻きはいない。上司も間に合う。上司が枝野幸男にマストドンの説明をする。

枝野幸男は文化を理解していた。枝野幸男のマストドンのアカウントの名前は本名ではない。かつ、本業には言及しない。それでいい。自分の管理していないインスタンス経由でマストドンに参加するのであれば、無名の一般人として参加すべきだ。そしてどうでもいいバカなことをつぶやくべきだ。そして、他人も本人の意志を尊重し、わざわざ本業についての質問をぶつけるような無粋なことをするべきではない。民進党の政治家、枝野幸男として意識の高い発言をするのであれば、自分でサーバーを建てるべきだ。なぜならば、自分の管理するサーバーは一番信頼できるからだ。

このブログを書いている今も、枝野幸男はわかる人にだけわかる本名ではない名前で、政治家としてではなく一個人として、マストドンで雑談をしている。このまま続けたいだけ続けて、やめたいときにやめるべきだ。

マストドンの保証する自由は、政党や政治家にも利点がある。なぜならば、自らサーバーを立てて情報を発信することで、マスメディアによる脚色のない一次情報を自ら発信できるからだ。

マストドンでは誰でもインスタンス(サーバー)を建てることができる。どのインスタンスを経由してマストドンに参加しているかを意識する必要はない。TwitterやFacebookのように、サーバーを独占され、唯々諾々と決定に従うしかない不平等で不自由な時代は終わった。これからはマストドンの時代だ。

2017-05-05

5月7日に江添ボドゲ会をやるかも

江添ボドゲ会5月7日 - connpass

5月7日に木場にある江添の自宅でボドゲ会を開くかもしれない。connpassで4人集まれば開く。詳細は上記connpassリンクを参照のこと。

2017-04-29

マストドン会議で技術と自由を語る

マストドン会議というものがあり、清水亮も登壇するというので行ってきた。

マストドン会議 ―― その無限の可能性を、いま語らずしていつ語らう! ~コミュニティもマーケティングも揺るがすTwitterのライバル出現~ | Peatix

マストドンは日本ではやってからまだ2週間しかたっていない。一体そんな状況で誰が集まるのだろうか。主催は角川が絡んでいるらしいが、まあ、あまり期待はせずに行くことにした。

その日は来るべき超会議2017のリハーサルの日だった。会場の幕張メッセではマストドンブースが設営されていた。私が担当なので当然私も現地にいた。そして少し遅れてマストドン会議の会場に着いた。清水亮は私よりも更に少し遅れて会場入りした。

会場に入ってみると、ぬるかる氏のmastdn.jpにサーバーを提供しているさくらインターネットの人とぬるかる氏が、サーバーの運営上の話をしていた。とても技術的な話だった。よかった。技術の話をしている。これが、「えっとぉ、マストドンはぁ、やっぱりぃ、Twitterをオープンなプラットフォームに持ってきたってところがいいと思うんですよねぇ。ユーザーがソーシャライズされてぇ」などと宣うアホで埋まっていたら会場に向かうまでの時間が圧倒的に無駄であった。何しろ、明日は超会議2017のマストドンブースのために、早朝に会場入りしなければならないのだから。

mastdn.jpの運営は技術的な話と、違法な発言を削除したり犯罪的な名誉毀損発言を繰り返すユーザーをBANしたりといった管理上の話だった。

私がぬるかる氏が話すのを見たのはこれが初めてだが、想定していた人物像と印象と全く違った。私が想定していたぬるかる氏は、陰鬱で物憂いナード青年だった。しかし、この壇上ではなすぬるかる氏はどうだろう。120人の聴衆を前に、一切物怖じせず、言い淀まず、冷静にゆっくりと話を続ける。ぬるかる氏何者?

読者は100人の聴衆の前で話ができるだろうか? 私はできる。私はそれだけの場数を踏んでいて経験があるからだ。私は十分に経験を積んでいるのでストレス耐性があり、緊張することはない。しかし、一度もそのような経験のない一般人は、100人の聴衆を前に事前にほとんど準備も練習もなしで話などできるはずがない。しかるに、ぬるかる氏はほとんど準備も練習もできなかったはずなのに、この冷静さ。ただものではない。

ぬるかる氏が話す途中で、第一部が終わった。

その後、津田大介が誰でも言えるようなくだらない一般論をのたりくたりと話し始めた。一体何なんだこいつは。というよりなんで津田がここにいるのだ。津田はマストドンで何かしたのか? というかお前、最近見かけないな。

津田はラリホーでも唱えているかような眠気を誘うどうでもいい話を延々と行う。誰か津田を止めろ。違うだろ。本当に自由の価値を追求する人間は「オープン」なんて言葉を使わない。秋葉原のオタク文化をいきなり語りだしてどうした。どうでもいいだろ。

技術の話をしろ。

結局、津田という人間はこういう人間なのだろう。かつて、津田が勉強会に参加して登壇者の発言をTwitterで要約して流すという行為に「Tsudaる」という言葉が割り当てられた。それは真実だったのだ。津田というのは人の話を要約して議事録を作成するには向いているのかもしれないが、自分の意見を語りだすとこうもどうでもいい一般論ぐらいしか語れない人間なのだ。

と、こう考えているうちにも津田が延々とのたりくたり。もういいから津田を黙らせろ。ぬるかる氏に話をさせろ。

というところで、清水亮に話が振られた。これは正解だった。清水亮は今まで胡散臭いポエマーだと思っていたが、ただこの業界でやっているだけある。一瞬で雰囲気を激変させた。

清水亮は、まず他の登壇者を退場させた。

「お前ら一旦ハケてくれる?」と。

この一言で、会場の空気は完全に津田の辛気臭い話から怒涛のプレゼンスタイルに激変することになる。

清水亮が話す。声が大きい。津田のラリホーで眠っていたものも叩き起こすような声だ。清水亮の話も、結局誰しもが考えるものである。

  1. TwitterやFacebookでは本音で話ができない。バカな発言をすると炎上する。というか家族が見ている。マストドンでは本音で話ができる。
  2. ユーザーが犯罪予告、わいせつ物、名誉毀損などの発言をしたら削除する必要があるし、BANする必要もある。この管理を人間がやるのはダルい。AIにやらせるべきだ。
  3. マストドンの今の秘密会話は全然秘密ではない。インスタンスがユーザーの意思を尊重して秘密にすることに依存している。アリスとボブが秘密の通信をするときはそれぞれローカルで公開鍵暗号を使って安全に鍵交換を行って暗号文でやり取りすべきだ。

たしかこの程度のことを話したはずだ。これはどれもいまさら言うでもない当然の話で、一般論に過ぎない。しかし清水亮のプレゼン力は優秀で、聞いているものを叩き起こした。

そして私に話が振られる。この流れはよい。大声で話すことならば私とても心得ている。準備とても何もないが、津田がのたりくたりと話している間にmarkdownで書いた数枚の話す要点だけメモ書き程度に書いたものがあったので、これを急ぎpandocでreveal.jsに変換してスライドとする。

技術

まず技術の話だ。ここにきてプログラマーとして登壇して技術の話をしないのはタイヘンシツレイにあたる。

マストドンは技術的にはクソである。

  1. マストドンは教科書的なRuby on Railsで実装されている。つまり富豪的プログラミングだ
  2. マストドンはReactで実装されている。我々がHTMLとCSSとJavaScriptを分離してきたのに全部一緒くたにしてしまう。これではPHPに逆戻りだ。しかも生成されたDOMがクソだ
  3. マストドンの元となったGNU Socialは流行らなかった。その理由はOStatusプロトコルにある。
  4. そもそもOStatusプロトコルのドキュメントがない。存在しない。ネットから消えている。Internet Archiveは我々の友達だ。
  5. OStatusプロトコルはスケールしない。リモートフォローによってインスタンス同士のプッシュ通知で大量にトラフィックとストレージを浪費する

そのため、私はプログラマーとして技術的に判断を下した結果、「マストドンはクソだ」と結論した。

本の虫: そろそろマストドンについて語っておくか

しかし、内部実装が技術的にクソかどうかと、利用者にとって面白いかどうかは、全く関係のない話だ。マストドンは面白い。それは純然たる事実である。スケールしない問題など、インフラを分厚い札束で殴ればいいのだ。

自由

さて、技術について語ったので、次は自由について語る。

まず、そもそも会場の聴衆がどれだけ自由なソフトウェアについて知っているのか。自由なソフトウェアについて知らないならば、その解説から始める必要がある。

「GNUを知っている者は挙手せよ」

なんと、ほとんど全員の手が上がったではないか! なんということだ。聞き間違いではないか。いや、文字に起こせばGNUだが、口頭でいうと「ぐにゅー」だ。そんなへんてこなものを何かと聞き間違えるはずがない。ああ、なんということだ! RMSの地道な活動はついに実を結び、ついにGNUを誰もが知るところとなったのだ。自分は今、猛烈に感動している。

全員、GNUを知っているとなれば話は早い。自由なソフトウェアについて説明する必要はない。

さて、我々のソフトウェアは、RMSとFSFとGNUによってほぼ自由になったが、自由に対する新たな脅威が持ち上がっている。SaaS(Software as a Service)だ。

SaaSとは、例えばGMailであったり、Google Docsであったり、あるいはTwitterやFacebookなどだ。今や、ほとんどのWebサイトはSaaSといってよい。

我々がWebサイト上で何かをするとき、その処理の大半自分の所有するローカルのコンピューターではなく、サーバーが行っている。我々はサーバーを所有していないし、サーバーを支配していない。ということは、我々のローカルのコンピューターは自由かもしれないが、サーバーは自由ではない。そして、今や処理の殆どはサーバーで行われている。

これは非常に辛い問題で、我々が所有も支配もしていないコンピューターは、我々の自由にならないのは当然の話だ。私のコンピューターは私の所有しているものであり私が支配している。私のコンピューターが他人の意思で私の望まない処理をされてほしくはない。その理屈で、我々はサーバー側に自由を求めることができない。自由はコンピューターの利用者にかかるもので、サーバーのコンピューターの利用者は、我々ではないからだ。我々は利用者の慈悲によって処理を肩代わりしてもらっているだけだからだ。これはGPLでもどうしようもない。

そこで、AGPLだ。AGPLはGPLと非互換なライセンスで、サーバーに対しても適用される。AGPLなソフトウェアをサーバー上で動かして、それによってサーバーが提供するサービスの利用者には、AGPLに従ってサーバーで動くソフトウェアを自由にしなければならない。つまりユーザーに対してソースコードを公開しなければならないし、その気になればユーザーが全く同じ互換サーバーを立ち上げることも可能になる。

マストドンのライセンスはAGPLである。

そして、マストドンは流行った。ぬるかる氏が2週間前にマストドンのインスタンスを立ち上げてからというもの、この日本で圧倒的にマストドンが流行した。すると、個人や企業が先を争ってマストドンのインスタンスを立てたがる。しかし、そうやって立てる? それにはマストドンを使うしかない。マストドンはAGPLだ。AGPLにしたがってソースコードを公開しなければならない。もし、自分のインスタンスに何らかの改変を加えた場合、それも正直に公開しなければならない。

マストドンの互換サーバーを独立して実装すれば、そのソフトウェアは自分の好きにできる。しかし、そのようなソフトウェアを開発すには、半年、1年、場合によってはもっとかかる。今、この瞬間にマストドンのインスタンスを立ち上げるには、マストドンしかない。ところでマストドンはAGPLである。

この状況は、社内政治などをすっ飛ばしてAGPLを強制させた。いまマストドンを建てないと流行に乗り遅れる。その機会損失と、未だに根強い自由ソフトウェアへの抵抗を天秤にかけて、機会損失が勝ったのだ!

今や、プロプライエタリな製品を販売していた不自由な企業まで、先を争ってAGPLなサーバーを立てるようになったのだ! なんという素晴らしい世界だろう。一体どんな奇跡が起こったというのだ! 私は信じられない光景を目にしている。ああ、自由が尊重されている!

そう、すでに変化はドワンゴ社内にも起こっている。自由ソフトウェアの忌避はドワンゴとても例外ではない。結局社内のリソースを割いて書いたコードを表に出すには、色々と社内政治や偉い人たちの判断などが必要になる。マストドンは最初からAGPLなので、もはや社内政治などと言っている場合ではない。自由になるか、使えないかだ。

そして、本当に奇跡のような展開が起こる。

ドワンゴのエンジニアであるまさらっきが、マストドンに脆弱性を発見したので、修正するPRを送った。

use Twitter::Extractor for creating links by masarakki · Pull Request #2502 · tootsuite/mastodon

すると、マストドンの開発者のオイゲンが、ABCanGを呼び出して、問題を見るように指示する。ABCanGはPixivのエンジニアである。なぜPixivのエンジニアが呼ばれるのかと不思議に思ったら、どうやら該当部分を実装したのはABCanGだそうだ。なるほど、納得だ。

しかし、実はこれは画期的なことである。

そもそも、ドワンゴとPixivはお互いに競合するサービスを提供している企業である。Pixivは絵の投稿サービスを提供していて、ドワンゴもニコニコ静画などの絵の投稿サービスを提供している。このため、基本的に両社は商売敵である。

一時期、Pixivはニコニコ静画へのリンクを検閲するというような強硬な処置さえ行った。

『pixiv』にニコニコのURLを貼ると「有害サイト」として削除される!? ニコニコ担当「非常に残念」 | ガジェット通信

その犬猿の仲であるPixivとドワンゴが相手の不具合を修正して助けているだと。ああ、自由の価値ここに極まれり。

自由は素晴らしい。

しかし、この自由が今、脅かされつつある。スマフォアプリだ。

そもそもスマートフォンは不自由なコンピューターである。iPhoneもAndoridも不自由だ。しかも、AppleやGoogleが提供するアプリの流通プラットフォームは、利用者に不自由なEULAへの同意を求めるので、GPLと互換性がない。スマートフォンを使う時点で不自由で、配布されるアプリも不自由だ。スマートフォンは不自由の塊なのだ。

そして、マストドンのにわかの流行により、雨後の筍のようにぽこぽことマストドンクライアントアプリがストアに並び始めている。いま開発中のものも大勢いるだろうから、今後はもっと増えるだろう。

しかし、よく考えてもらいたい。マストドンは自由だ。自由の価値は素晴らしい。その自由をあえて放擲するのか。不自由なクライアントで閲覧するマストドンは美味いか?

不自由なコンピューターであるスマートフォンの利用は拒否すべきである。

Twitter独占の弊害

なぜマストドンはTwitterより優れているのか。それは、誰もがマストドンのインスタンス、つまりサーバーを建てられるからである。Twitterではこうは行かない。

Twitterでは、Twitter社は正しい。Twitter社の判断は正しい。もしTwitter社がユーザーをBANしたのならば、もちろんそれは正しい。疑問を差し挟むことは許されない。Twitterの判断を疑うことは反逆でありBAN対象である。そのスモーレスラーの画像はわいせつ物なのでBANするのは当然だ。さすがTwitter様。完璧なTwitterユーザーは完全に幸福です。実際、幸福は義務です。ユーザー、あなたは幸福ですか?

現実のTwitterはここまでひどくないかもしれない。しかし、Twitter社がこのような運営をしても、逆らう方法はない。我々はTwitter社の慈悲にすがるしかないのだ。

自由なマストドンではこの恐れはない。あるインスタンスが気に入らなければ、別のインスタンスに行けばよい。自分の思想を受け入れるインスタンスがなければ、自分でインスタンスを立てればよい。自分の思想を受け入れるクラウドやVPSベンダーがなければ、自前でサーバーを立てればよい。もし、自分の思想を受け入れるISPが存在しなければ、それはシーランド公国にでも行くしかないだろう。

そして、マストドンではユーザーがインスタンスの違いをほとんど意識することがない。自由の圧倒的勝利だ。ああ、なんて世界だ!

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

2017年4月40日、5月1日に幕張メッセで開催される超会議2017には、マストドンブースがあります。江添亮がブース担当です。ドワンゴが立てたマストドンのインスタンス、https://friends.nicoのインスタンスの宣伝、マストドンステッカーの配布、マストドンについての質問、江添亮がライブマストドンするなどのさまざまな楽しいイベントがあります。

その他にも様々なブースがあるので楽しめますよ。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-04-27

KaTeXを使ってみた感想

ブラウザー上で動いて、texの数式を描画するライブラリには、有名なMathJaxの他に、KaTeXがある。

Khan/KaTeX: Fast math typesetting for the web.

KaTeXにはMathJaxにない様々利点があるが、欠点も多い。

マストドンで数式描画をするのにMathJaxの代わりにKaTeXが使えないかと試してみたが、結論から言うと、KaTeXはマストドンで使うのに適さない。

KaTeXは以下の用途で使うのに適している。

  1. 自分一人、あるいは十分に訓練されて連絡を密に取り合う人間だけで編集された文書
  2. 数式に間違いがなく、KaTeXで処理できること

以下のような場合には適さない。

  1. 不特定多数の人間が数式を入力する
  2. 数式は文法的に誤りを含む可能性がる

KaTeXの利点

KaTeXはMathJaxに比較して様々な利点がある。

速い。文句なくMathJaxより速い。

KaTeX and MathJax Comparison Demo

実装が軽量で依存がなくWebサイトに組み込みやすい。

JavaScriptファイル一つ、CSSファイル一つ、あとはフォントファイルしかない。

KaTeXはかなり理想的なのだが、問題がある。

数式のパースエラーに非寛容

数式がtexの文法違反だったりするとすぐに例外を投げる。例外を無効化もできるが、基本的にパースエラーを出した時点でそれ以上の処理を拒否する。

CJK文字に対応していない。

これは本当に耐え難い問題だ。我々は$力=質量\times加速度$を書くときは、

$力=質量\times加速度$

と書きたい。しかし、KaTeXはCJK文字に対応していない。

一応、\text{}で囲めば使えるらしいが、それは式の意味を買えてしまうし、第一、

$\text{力}=\text{質量}\times\text{加速度}$

とは書きたくない。そもそも意味が変わってしまう。不特定多数のユーザーがいる場合にこれを守らせるのも難しい。それにこうしてもやはりCJK文字の扱いには問題がある。

それ以外にも、基本的にエラーを出すと処理を中止するようになっていて、本当に使いづらい。

このため、KaTeXはマストドンで使うのに適さない。

2017-04-26

どんなWebページでもtexによる数式描画を追加できるブラウザー拡張

EzoeRyou/inject-mathjax: どんなWebページにもMathJaxをロードするブラウザー拡張

任意のWebページにMathJaxを読み込ませてtexによる数式表現を化膿するChromium, Google Chrome向けブラウザー拡張。

インストール


git clone
vim whitelist_urls.conf
make

してからChromiumにインストールする。

whitelist_urls.confには一行にひとつ、MathJaxを読み込ませたいURLをマッチパターンで記述する

Match Patterns - Google Chrome

特徴

このブラウザー拡張はwhitelist_url.confに記述したマッチパターンのURLに対し、

  1. CSP(Content Security Policy)を無効化する
  2. MathJaxをロードする
  3. MathJaxを定期的に呼び出す

という処理を行う。

類似のブラウザー拡張より優れている点

すでに類似機能を提供しているブラウザー拡張があるが、コンピューターリテラシーのないユーザーのためにあまり洗練されていない実装になっている。

CSPの普及により、多くのWebサイトでは外部ドメインのスクリプトがロードできなくなっている。CDN経由でMathJaxをロードするには、まずCSPを無効化しなければならない。CSPはセキュリティを向上させるものであり、不必要に無効化すべきではない。そのため、MathJaxをロードする必要があるURLのみ無効化すべきだ。 Chromium, Google ChromeでCSPを無効化するには、レスポンスヘッダーをブラウザーが解釈する前に改変するブラウザー拡張用の機能を使う。そしてCSPの部分を削除する。

これは以下のようなコードになる。


for (var i = 0; i < details.responseHeaders.length; i++) {
    if ('content-security-policy' === details.responseHeaders[i].name.toLowerCase()) {
        details.responseHeaders[i].value = '';
        // 実際にはCDNを追加するのでもう少しマシ
    }
}

巷に出回っているブラウザー拡張は、このレスポンスヘッダーからCSPを削除するためのコールバック関数を、すべてのURLに対して読み出す。そして、自薦に設定したURLのみに適用するように条件分岐する。


function( details ) {

    if ( !is_whiltelist_urls(details.url) )
        return ;
}

ブラウザー拡張側のコードでURLを判定している。

理想的には、ブラウザー拡張のmanifest.jsonのpermissionsで適用されるURLを厳しく指定すべきだ。しかし、そのためにはユーザーがmanifest.jsonを変更する必要がある。

このブラウザー拡張は、whitelist_urls.confに記述されたマッチパターンをpermissionsにもつmanifest.jsonを生成して、ブラウザー拡張をユーザーが作るようになっている。

2017-04-24

マストドンで数式を表示するブックマークレット

読者はすでにマストドンをしているだろうか。マストドンは自由なSNSで未来がある。もはや不自由なSNSであるTwitterやFacebookの時代は終わった。今年中にも滅びるだろう。

さて、マストドンで不便な点として、数式が表示できないという問題がある。しかし、これは自由なソフトウェアであれば改良が可能だ。

以下のリンクをブックマークバーまでドラッグするか、URLをコピーしてブックマークとして追加しよう。

#mathトドン

そして、マストドンを開いたタブで、ブックマークをクリックするのだ。

すると、

$$
 \mathsf{K}_\nu(x) =
  (\pi/2)\mathrm{i}^{\nu+1} (            \mathsf{J}_\nu(\mathrm{i}x)
       + \mathrm{i} \mathsf{N}_\nu(\mathrm{i}x)
       )
  =
  \left\{
  \begin{array}{cl}
  \displaystyle
  \frac{\pi}{2}
  \frac{\mathsf{I}_{-\nu}(x) - \mathsf{I}_{\nu}(x)}
       {\sin \nu\pi },
  & \mbox{for $x \ge 0$ and non-integral $\nu$}
  \\
  \\
  \displaystyle
  \frac{\pi}{2}
  \lim_{\mu \rightarrow \nu} \frac{\mathsf{I}_{-\mu}(x) - \mathsf{I}_{\mu}(x)}
                                  {\sin \mu\pi },
  & \mbox{for $x \ge 0$ and integral $\nu$}
  \end{array}
  \right.$$

$$ \mathsf{K}_\nu(x) = (\pi/2)\mathrm{i}^{\nu+1} ( \mathsf{J}_\nu(\mathrm{i}x) + \mathrm{i} \mathsf{N}_\nu(\mathrm{i}x) ) = \left\{ \begin{array}{cl} \displaystyle \frac{\pi}{2} \frac{\mathsf{I}_{-\nu}(x) - \mathsf{I}_{\nu}(x)} {\sin \nu\pi }, & \mbox{for $x \ge 0$ and non-integral $\nu$} \\ \\ \displaystyle \frac{\pi}{2} \lim_{\mu \rightarrow \nu} \frac{\mathsf{I}_{-\mu}(x) - \mathsf{I}_{\mu}(x)} {\sin \mu\pi }, & \mbox{for $x \ge 0$ and integral $\nu$} \end{array} \right.$$

と表示される。ちなみにこれはIrregular modified cylindrical Bessel functionだ。

これで、マストドンで数式を表現できる。このブックマークレットを使っているもの同士ならば、数式で会話できる。

ちなみに、コードは以下の通り。

(function(){

var config = document.createElement( "script" ) ;
config.type = "text/x-mathjax-config" ;
config.appendChild( document.createTextNode( 'MathJax.Hub.Config({tex2jax: {inlineMath: [["$","$"], ["\\\\(","\\\\)"]]}});' ) ) ;

document.head.appendChild(config) ;

let script = document.createElement( "script" ) ;
script.type = "text/javascript" ;
script.async="async" ;
script.src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS_SVG" ;

let inner_script =
    'window.setInterval( function() { MathJax.Hub.Queue(["Typeset",MathJax.Hub]); '
+   'let textarea = document.getElementsByClassName("autosuggest-textarea__textarea")[0] ;'
+   'if ( textarea !== null && textarea.value === "" )'
+       'textarea.value = "#math " ;'
+   '}, 1000 ) ;' ;


script.appendChild( document.createTextNode( inner_script ) ) ;

document.head.appendChild(script) ;
})() ;

ちなみに、このコードはデフォルトで入力欄に#mathを入力する。この挙動が気に入らない人は、以下のブックマークレットを使うとよい。

mathトドン

コードは以下の通り。

(function(){
var config = document.createElement( "script" ) ;
config.type = "text/x-mathjax-config" ;
config.appendChild( document.createTextNode( 'MathJax.Hub.Config({tex2jax: {inlineMath: [["$","$"], ["\\\\(","\\\\)"]]}});' ) ) ;

document.head.appendChild(config) ;

let script = document.createElement( "script" ) ;
script.type = "text/javascript" ;
script.async="async" ;
script.src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS_SVG" ;

let inner_script = 'window.setInterval( function() { MathJax.Hub.Queue(["Typeset",MathJax.Hub]); }, 1000 ) ;' ;



script.appendChild( document.createTextNode( inner_script ) ) ;

document.head.appendChild(script) ;
})() ;

2017-04-20

ここらでもう一度マストドンについて語っておくか

オレが間違っていたぞ、清水亮。

なんで「オレが間違っていた」と最初に書けないのか。つまんねープライドもってんなー

-- 清水亮

https://mstdn.onosendai.jp/users/shi3z/updates/1002

前回、前々回と、マストドンについての批判を書いた。結論を先に書くと、私の技術上の懸念以外の懸念はすべてあたらなかった。

本の虫: そろそろマストドンについて語っておくか

本の虫: マストドンが直面している問題はすでにP2P技術が15年前に遭遇した問題だ

そうこうしていると、ドワンゴがマストドンのインスタンスを立ち上げた。

https://friends.nico/

これはなかなか興味深い。というのも、私はドワンゴに雇用されているので、ドワンゴが悪意を持っているかどうかについては内部の情報があるため判断しやすい。マストドンはインスタンスの管理者が悪意を持っているかどうかが極めて重要だ。内部の情報をもって判断した結果、今は信用できそうだ。

そこでものは試しとアカウントを作ってみた。

EzoeRyou

そして、感動した。これだ。久しく忘れていたインターネットがここにある。何ということだ。

そこにあったのは、黎明期の怪しげな雰囲気を持つインターネットだった。今から20年ほど前の2chやIRCの雰囲気だ。インターネットよ、私は帰ってきた。

ともすればインターネット老人会とも揶揄される環境がそこにあった。我々はぬるぽにガッされ、ゴノレゴが吉野家のにわか客に文句を言い、ペリーに開国を迫りミキコにピアノを教えるあの空気が再現されていた。

そうだ。当時もこうして、夜遅くまで寝不足になりながらインターネットを閲覧したものだ。そうこうしているうちに、誰かがセンシティブなコンテンツのフラグが立てられた画像が投下される。みてみるとうまそうな飯テロ画像であった。「これはけしからん、無修正じゃないか」と文句を言うと、こんどはモザイクをかけた飯テロ画像が投下される。

開始当初のマストドンのドワンゴインスタンスには優れた点が二つある。まずエロが投下されないことと、誰も煽り合わないことだ。放っておいても人はエロを探すし、勝手に煽りあう。そういうものだ。

インターネットからきらめきと魔術的な美がついに奪い取られてしまった。2chや、IRCや、アングラサイトがユーザー達と共に中二病を誇り合い、徹夜でチャットにあけくれ、不毛なネット議論を繰り広げる。そんなことはもう、なくなった。

これからのインターネットユーザーは、安全で静かで、物憂いスマフォを握って、画面を受動的にタップ操作のみする。一方何千というコンテンツ達が、アルゴリズム一つで機械の力によってフィルターされ、検閲される。これから先のインターネットは、安全と引き換えにその娯楽性を完全に殺すだろう。

やがてそれぞれのプラットフォームには、大規模で、限界のない、一度発動されたら制御不可能となるような検閲のためのシステムを生み出すことになる。

人類ははじめて自分たちが手に入れた自由な情報流通手段を、みすみす自ら手放すことになる。これこそが人類の栄光と苦労のすべてが最後に到達した運命である。

結局、Twitterなどの大手のSNSはあまりにも有名になりすぎ、あまりにも大衆化しすぎたために、つまらなくなってしまったのだろう。大衆受けを目指すと、きらめきと魔術的な美が失われてしまうのだ。

この歴史は連続している。パソ通が、あめぞうが、2chが、ニコニコ動画が、開始当初はこの黎明期特有の怪しいきらめきを有していたが、大衆化に伴って消失してしまったのだ。これはどうしようもないことだ。大衆化の過程で、より多くの、より幅広い人間に受け入れやすくなり、その結果利益を出すことができ、その利益をプラットフォームの維持と拡張に使うことができる。大衆化をしない場合、利益が出ずにプラットフォームが継続できないとしたら、結局大衆化するしかない。

もちろん、これはドワンゴのマストドンインスタンスとて例外ではない。いずれはユーザーが集まりすぎて大衆化して万人受けにはなるが陳腐化するか、ユーザーが集まらず過疎化してひっそりと消失するかのどちらかになるだろう。どちらにしても、現在のこの魔術的な美は速やかに失われるだろう。

せめて今は、この雰囲気を楽しむとしよう。

さて、ポエムを書くのはここまでにして、技術的な話をしよう。

マストドンと元になったGNU Socialは、OStatusというプロトコルを使っている。このプロトコルの詳細な内容を筆者は知らない。

というのも、OStatusプロトコルの網羅的なドキュメントが存在しないからだ。5年前は存在していたのかもしれないが、散逸してしまっている。本来ドキュメントをホストしていたはずのURLのドメインの所有者が変わって全く関係ない内容になったりしている。

それでも散らばっているドキュメントを読んでキーワードを拾っていくと、ユーザーの発見にWebFinger、購読にPubSubHubbub、メッセージのやり取りにSalmonを使っていることなどがわかった。あるいは、OStatusプロトコルという単一のものはなくて、細分化されたプロトコルの寄せ集めでできているのかもしれない。

さて、プロトコルの技術的な詳細は後で調べるとして、筆者の理解する限りでは、OStatusプロトコルはスケーラビリティの問題を抱えている。おそらく現在の設計では、規模が拡大したときに、負荷がとても増えていくはずだ。なので、Twitterを代替するほどの規模で成立できるかどうか疑問だ。

また、ユーザーの認証がサーバーに結びついているのも問題だ。ユーザーの発見と認証のプロトコルであるWebFingerを調べたところ、どうやらユーザーには絶対に変わらない永続URLが必要なようだ。これではサーバーレスな実装は困難だ。

したがって、規模の小さい今はこのままOStatusプロトコルを使うのはいいとしても、早急に別のより優れたスケールするプロトコルを設計すべきだろう。

ただし、この技術的にスケールしないという問題は、実は問題にならないかもしれない。というのも、1インスタンスに数万人もユーザーが殺到するような状況を作り出さなければいいのだ。したらばやRedditのように、ユーザーが自分の管理するインスタンスを立ち上げるようなサービスにして、1インスタンスあたりのユーザーを抑える文化を作り出せば、スケールは問題ではなくなる。たかだか1万に満たない程度のユーザーを処理するならば、どんなに富豪的な設計でも耐えられる。ユーザーがジャンルごとにインスタンスを作り、自治を行う。楽しい世界だ。

例えば支持政党ごとにインスタンスがあり、自民党支持者は自民党インスタンスに、民進党支持者は民進党インスタンスに登録する。そしてインスタンス間の戦争が起き、連結が遮断される。「我々自民党インスタンスは民進党インスタンスとの連結を解除した。これは民進党が我々の党議に賛同しないからである」などといった具合だ。

さて、最後に自由の話をしよう。

マストドン、GNU Socialにとって、自由は極めて重要だ。なぜならばその開発目的が、SNSプラットフォームの独占の打倒にあるからだ。

マストドンとGNU Socialでは、サーバー実装が自由なライセンスであるAGPLで公開されているので、誰でも必要なインフラさえあれば、マストドンでは「インスタンス」と呼んでいるサーバーを建てることができる。あるインスタンスの管理が気に食わないのであれば、別のインスタンスを使えばよい。気に入るインスタンスがないのであれば、自分で立ち上げればよい。これによりTwitterやFacebookのような一企業に独占され、一企業の一存で好きなように検閲される問題を解決できる。

すでに解説したように、大抵のユーザーは自前のインスタンスを立ち上げるのではなく、有名なインスタンスに集中する。大勢のユーザーの負荷に耐えられるインフラを運営するには、企業でしか支えられないほどの資金と労働者が必要だ。すると特定のインスタンスが独占的な地位を得て、ユーザーを囲い込み、外部との連結を無効化するという邪悪に走るだろう。そう考えていた。

たしかにその懸念はあるのだが、現実は違った。そのような鎖国を嫌う文化が生まれていれば、利用者の期限を損ねないように、そのような邪悪を行わないインセンティブが生まれる。

ああ、先見性というのは難しいものだ。すっかり見誤った。

結果として、マストドンは流行るだろう。もうTwitterに独占される必要はないのだ。

2017-04-16

マストドンが直面している問題はすでにP2P技術が15年前に遭遇した問題だ

Media content caching strategy · Issue #1847 · tootsuite/mastodon

日本勢がマストドンに目をつけ始め、Pixivがマストドンのインスタンスを立ち上げてからというもの、マストドンは2つの問題に直面している。

  1. 日本国内で合法である現実に基づかない純粋な思想の表現である絵が海外基準では児童ポルノであり違法なデータである
  2. 画像投稿を主目的とするPixivの利用形態により大量のトラフィックとストレージがキャッシュとして消費されるため貧弱なインフラでは耐えられない

これにより、Pixivによるマストドンのインスタンスは海外で主流のマストドンのインスタンスから遮断された。

現在、マストドンのコミュニティではこの問題に対する議論が行われているが、この問題には見覚えがある。15年前のP2P技術が流行した時代と同じ問題だ。我々は歴史に学ぶべきである。

今をさかのぼることおよそ15年前、P2P技術があらゆる問題を解決する夢の技術として期待されていた。当時、P2P通信により、インターネット上に分散メッシュネットワークを構築し、その分散メッシュネットワーク上に、ファイル共有、掲示板、チャット、ブログ、Webページ、その他あらゆるネットワーク通信を実装していた。純粋な分散メッシュネットワークでは、すべての参加者が、計算機、ストレージ、トラフィックなどの資源の大小を別にすれば、平等である。

その実装方法は様々で、例えば特定の機能に特化した実装、例えば、ファイル共有や掲示板のWinny、ファイル共有のBitTorrent、チャットのSkypeのような実装もあれば、Webページのようなより汎用的な機能を提供するfreenetのような実装、あるいは分散メッシュネットワークを構築した上でローカルsocksプロクシーサーバーとして動作して通過的にTCP/IPをアプリケーション層に提供するような実装もあったはずだ。

その具体的な実装方法については様々な方法が乱立して試されたが、どれも同じ問題を抱えていた。現在のマストドンが抱える問題と同じだ。

  1. 著作権侵害、児童ポルノ、その他の違法なデータ(ドイツにおけるナチ党のシンボルなど)がネットワーク上に蔓延する
  2. ネットワークに参加するノードがキャッシュとしてデータを溜め込むためにネットワークに参加するための計算機、ストレージ、帯域などの資源が莫大になり、個人が参加しづらくなり、結果としてゲートウェイ経由での参加が増える

その結果どうなったか。まず、ソースコードを公開せず、プロトコルの仕様も公開しないような閉鎖的な実装であるWinnyは滅びた。純粋な分散メッシュネットワークにこだわったfreenetのような実装は問題2.によってスケールせずに非効率性によって実質的に廃れた。

当時を生き延びて今も使われている実装もある。例えばSkypeとBitTorrentだ。

Skypeは当初P2Pな分散メッシュネットワーク(完全に平等ではなく、特にトラフィックに余裕のあるノードがスーパーノードとして局所的な管理サーバーの役割を果たし、NAT超えのために通信を仲介するリレーノードも存在した)によるチャットの実装であったが、今ではMicrosoftの管理するところとなり、その実装はサーバークライアント型の中央集権的で効率的な実装に切り替わった。もはや、今のSkypeはP2Pではなくなってしまった。とはいえ、表向きの末端のユーザーに対する利便性には違いがないので、よく使われている。

BitTorrentプロトコルは当初、純粋な分散メッシュネットワークではなかった、サーバーでファイルのメタデータやファイルを保有しているシードと呼ばれるノード、ファイルをダウンロード中のピアと呼ばれるノードを管理する。ファイルをダウンロードするには、すでに完全なファイルを保有しているシードの他に、現在部分的にファイルを保有しているピアからも分散してダウンロードを行う。後にファイルのメタデータに対するハッシュ値だけで、ファイルのメタデータとピア/シードの取得も分散メッシュネットワークを介して行う実装も追加されたが、依然として最初のハッシュ値を分散メッシュネットワーク単体で検索したりする機能は提供されないので、やはり何らかの中央管理的なサーバーは必要だ。

P2P技術を利用したファイル共有には著作権侵害などの負のイメージがつきまとうが、BitTorrentプロトコルは数あるファイル共有プロトコルの中でも、特にサーバー側で多大なトラフィックが必要ないという点から、今でも自由なOSのISOイメージの配布とか、ソフトウェアのアップデートを全コンピューターに行き渡らせるためなどの目的で活用されている。

当時のP2P技術を考え、現在の実用化された例を参考にすると、問題の解決方法が見えてくる。

問題1.を解決するには、結局有人の検閲を設置するしかない。問題2.は解決できない。純粋な分散メッシュネットワークによりすべての参加者が平等であることを目指すのであれば、すべての参加者が平等に全ネットワークのコストを負担するので、ネットワークの規模が拡大するほど参加者の負担が増えてしまう。

さて、話をマストドンに戻そう。マストドンはOStatusプロトコルの実装で、もともとは当初StatusNetと名乗り、今はGNU Socialと名乗っているソフトウェアの互換実装だ。その目的は、単一の企業からのSNS支配の解放だ。

その思想と設計はこうだ。TwitterやFacebookのような一企業がSNSの実装とインフラを独占しているから不平等な権利格差が発生するのだ。SNSの自由な実装を提供し、誰もがSNSのインスタンス(サーバー)を立ち上げることができればこの権利格差は解消する。インスタンス同士がデータを相互にやり取りできるように互換性のあるOStatusプロトコルで通信できるようにしておけば、どのインスタンスを選ぶかという問題は、どのインスタンスが便利で信頼に値するかという問題になる。既存のインスタンスのどれもガキに食わないのであれば、自分でインスタンスを立ち上げればよい。

考えようによっては、サーバー同士がゆるくわずかにP2P風に繋がっていると考えることもできる。もちろん、分散メッシュネットワークほどの強い結びつきではない。RSSをすこし強力にしたようなデータ共有用のOStatusプロトコルでお互いにデータを共有できるという程度の薄いつながりだ。

さて、問題1.に対処するには、有人の検閲を設置するしかない。有人の検閲を設置するには、結局企業としての資本や雇用が必要だ。企業による支配から脱却することを目指しているマストドンとしては皮肉なことに、企業が必要になる。自分のインスタンス内のデータの適法性については十分な資本と労力さえかければ検閲できるが、よそのインスタンスのデータはどうしようもない。すると、外から内へのリモートフォローは無効化せざるを得ない。

問題2.に対処するには、強力なインフラが必要だ。大規模なデータセンター、ストレージ、トラフィックを提供する必要がある。これにも、企業による資本が必要だ。ネットワークの規模が大きくなっていくと、これまた皮肉なことに個人ではその規模のインフラを提供できず、企業には勝てない。そして、規模が大きくなっていくと、すべてを無制限にスクレイピングできるAPIを外部に提供することがパフォーマンス上難しくなっていくだろう。そこで、内から外へのリモートフォローも無効化せざるを得ない。

こうして、マストドンのインスタンスをまともに運営できるのは十分な資本と、最低でも数百人規模の労働者を雇用している潤沢なインフラを提供できる企業だけになるだろう。個人がマストドンのインスタンスを立ててももはやマストドン全体のデータを格納できるだけのトラフィックとストレージを用意することすら難しくなる。現在のマストドンは、個人でもインスタンスが建てられるような小規模な実装になっている。ユーザーが増えていくと、企業はマストドンを大規模なインフラ上でスケールさせるために実装を改善していくだろう。そのような大規模にスケールする実装は、個人でインスタンスを立てるのが難しくなってしまうだろう。

そして、自らが管理するインスタンスだけで何十万、何百万ものユーザーを獲得した企業は、もはや外のインスタンスと連携する必要すらない。自らのユーザーだけで自己完結できるのだから、検閲上、パフォーマンス上の理由も合わせて、外部との連携を断つ。これは企業として適切な判断ではあるが、結果としてユーザーは分断される。

その結果実現される未来は、現在のTwitterの実装が公に公開される程度の未来だ。誰でもTwitterと同じサービスを提供するサーバーを立てることは技術的に可能だ。ソフトウェア実装はすべて公開されている。ただしインフラの規模は個人で実現できる範囲を大幅に超えている。

結局、マストドンは思想的にも設計的にも、当初の目的である単一の企業からのSNS支配の解放を達成することはできないだろう。仮にマストドンがTwitterを置き換えたとしても、マストドンのインスタンス運営のためには十分な資本、労働者、インフラ、政治ロビー活動ができる企業が必要になり、現在のTwitterと同じ問題が発生する。ユーザーはマストドンが極めて抑圧的であると不満を持ち、やがて、「既存のマストドンの代替する分散型のSNS実装を公開する。これは単一のマストドンコミュニティにより我々のコミュニケーションが独占されるリスクを防ぐ!」などという運動が持ち上がることだろう。歴史は繰り返す。

唯一の救いは、マストドンのライセンスはAGPLであるので、その実装が公に公開されるということだろう。

追記:Winnyの金子勇が自著でプロトコルを公開したのは、金子勇が刑事裁判に巻き込まれてからであり、もはやWinnyは廃れて、競合の同等機能を提供する他のP2Pファイル共有ソフトウェアの方に人は移行していた。

2017-04-15

そろそろマストドンについて語っておくか

世間ではマストドンが流行っている。結論から言うとマストドンは思想的にも設計的にも失敗しているのでお祭りのように一時の話題になった後、急速に忘れ去られる運命にある。

マストドンを語るには、まずマストドンが実装しているプロトコルであるOStatusについて説明する必要がある。これはもともと、StatusNetというソフトウェアが提唱したプロトコルで、Twitterようなマイクロブログの更新通知のためのプロトコルだ。StatusNetは今は名前を変えてGNU Socialとして自由ソフトウェア財団の傘下になっている。

マストドンはいうなればGNU Socialの互換実装だ。その基本的な思想や設計はGNU Socialと同じだ。どちらも現在の大手ソーシャルネットワークサービスに共通の問題に対処しようとしている。

問題とは何か。権力の一極集中である。TwitterにしろFacebookにしろGoogle+にしろ、そして現在ブログの文章を主にホストしているBloggerやGitHubも、筆者より強い権限を持っている。もしこの文章の内容が、彼らの気に食わないものである場合、彼らの一存のよりこのブログは削除、改変、監視といった検閲を受ける。これはTwitterやGoogleが技術的にサーバーを管理しているために生じる問題だ。

この問題に対処するにはどうすればいいのか。我々全員がサーバーを運営できるようになればいい。インターネットの当初の目的は、全員がサーバーを運営できるようになることだった。残念ながら、ハードウェア資源の制約、IPv4アドレスの枯渇、NAT、不思議な日本国内の法律(プロクシーサーバーを運営する出稼ぎ中国人を日本国政府が都合よく別件逮捕するのに使われている通信事業者法)により、我々は自由にサーバーを運営できるようにはなっていない。しかし、少なくともサーバーの実装であるソフトウェアを提供し、サーバーの設置をかんたんにしてはどうか。

GNU Socialやマストドンはこのような思想で設計された。Twitter社の方針が気に入らないのであれば、別のサーバーに移住すればよい。どのサーバーも気に入らないのであれば、自分でサーバーを立ち上げればよい。

思想としては悪くはないのだが、技術的にはあまりよろしくない。GNU Socialの前身StatusNetは2010年から開発が始まっているが、一向に主流とならない。主流となっていないソフトウェアには主流になれない問題があるのだから、その互換実装を作っても主流となるわけがない。では一体何が問題なのか。

サーバーの設置は自由なソフトウェア実装が存在するだけではだめで、十分な性能を持ったコンピューターと十分なネットワーク帯域が必要になる。GNU SocialはPHPで実装されているし、マストドンはRuby on Railsで実装されている。実行には普通にWebサーバーを運営するのと同じだけの煩わしさがある。

これだけサーバーの実行が面倒だと、結局、既存のサーバーを利用するものが大半だろう。その結果、どこかの学生が1個人が運営している怪しげなサーバーに人が集中する。これはとても問題だ。

信用の話をしよう。Twitter社と一個の人間、どちらが信用できるだろうか。これは圧倒的にTwitter社である。何故かというと、邪悪に至るまでの障害の多さによる。

一個の人間が運営するサーバーで邪悪を為すのは簡単だ。一個の人間が邪悪になるだけでよい。一方、Twitter社は法人格として登録をしており、税金の支払いのために収支を国家に報告する必要がある。Twitter社には現在3000人以上の被雇用者がいる。Twitter社が邪悪をなして、それが露見しないようにするのはとても難しい。Twitter社内の一個の人間がなした邪悪は、速やかに発覚する。Twitter社が社をあげて邪悪をなそうとした場合、3000人以上いる社員のうちの少なくとも数十人から数百人はその邪悪が為されていることを知るだろう。そのうち、一人でも正義感あふれる人間がいて公に邪悪を暴露した場合、邪悪が露見する。

したがって、一個の人間によって管理されたサーバーより、何百人何千人もの人間が関わる法人の方が邪悪に至るまでの障害が多いという点で、信用できるのだ。

事実、マストドンの初期の主流サーバーでは検閲が行われている。どのような検閲かと言うと、ドイツやフランスの法律の法律に違反しないように、ナチ党のシンボルであるハーケンクロイツ、ホロコーストの否定といった内容が検閲されていた。マストドンはむしろ検閲をやりやすくするプラットフォームであると言える。権力を一個の人間に委ねると、その人間の裁量で検閲が行われるわけだ。もちろん、これは効率のいいハラスメント対策にもなるという主張もあるだろうが、それはつまり独裁政権は一人の独裁者の判断だけで政治が進むので効率的というのと同じだ。たしかに効率的だが、失敗に至る道も効率的にたどることができる。かの毛沢東も国力を増そうと大躍進政策を行い、かのポル・ポトも子供によりよい教育を施そうと子供を家庭から取り上げて国家が管理する完璧な教育を施そうとした。かのルーズベルトとトルーマンは日本に降伏させて日本の民間人を守るために日本を無差別爆撃し核爆弾を二回投下し、日本の民間人の虐殺に貢献した。地獄への道は善意で舗装されているというわけだ。

一個の人間がサーバーを管理する場合に憂うべきことは単に恣意的な検閲や改変だけではない。大半の人間はパスワードを再利用するという問題だ。

xkcd: Password Reuse

なんか適当に便利な利用に登録が必要なWebサービス作ったらユーザーIDとパスの組み合わせが大量に手に入るじゃん。やったね。さあ邪悪を行おうぜ。でもなにする?

そして、日本のマストドンのサーバーで注目を集めてユーザーの急激な増加を得た管理者が、某クラウドベンダーからホスティングを促されたり、別の某クラウドメンバーでホスティングしようと動いているなどという話をみるにつけ、もはや悪いとこ取りの様相を呈している。一個の人間が管理する上に、インフラは自分で所有していない。

マストドンとGNU Socialは残念ながら設計的に間違っている。結局、やっていることはTwitter風サーバーのソフトウェア実装を提供したというだけで、解決しようとした問題は何一つとして解決していないばかりか、大半のコンピューターリテラシーの低い者にとっては悪い結果になるだろう。

では、本当に技術的に正しい設計とは何か。まずすべての参加者はサーバーでもありクライアントでもある、完全にP2Pメッシュネットワークを構築し、その上にマイクロブログサービスを実装すべきである。自分のデータは全てローカルに保持する。

問題は、これは15年前、P2P技術が夢の技術のように叫ばれていた時代に試みられたことだ。あの当時は様々なP2Pメッシュネットワーク上に構築されたチャット、掲示板、ブログ、Webページ、ファイル共有などの実装が乱立していた。その実装はどれもすべての参加者はコンピューターの性能やネットワーク帯域を別にすれば平等であり、全員がローカルで同じソフトウェアを実行する作りであった。

そのような状況ですら、当時も今と同じ問題を抱えていた。ローカルでそのようなソフトウェアを実装するのは大変にコストがかかるので、大半のものは他人が実行しているサーバーにアクセスして、そのサーバー経由で参加していた。残念ながら当時のP2Pメッシュネットワークによる全員が平等なネットワークの構築は失敗した。当時の実装の殆どは秘密で不自由なプロトコルやソフトウェア実装で非効率なため打ち捨てられ、残ったのは、BitTorrentプロトコルのような詳細が公開されていて当時のソフトウェア実装も自由で使いやすかったものだ。BitTorrentプロトコルは大容量データの配信に都合がいいもので、これは今も自由なOSのISOイメージの配布とか、ゲームやサーバーのアップデートパッチの全コンピューターへの効率的な配布といった健全でまともな用途にも使われている。その他の当時の有象無象のP2Pプロトコルは、筆者の知る限り絶滅した。

筆者が思うに、真に自由な通信手段のためには、物理層からのP2Pメッシュネットワークの構築が必須だ。例えばコンピューターが無線通信装置を搭載して近隣のコンピューターと通信したり、ストレージをスニーカーを履いた足で運んだりして、物理層からのP2Pメッシュネットワークを構築し、その上にNamecoinのようなP2Pかつ計算資源の多いものが正しいという名前解決の仕組みを導入し、公開鍵署名によって特定の秘密鍵にアクセスできるものによって発信されたデータだと証明できる通信でチャットや掲示板やWebページやメールの仕組みを実装し、すべてのネットワーク参加者は平等である仕組みがほしいが、これとて最終的には計算資源とネットワーク帯域と電力の強いものが正しい弱肉強食の世界になることが予想されるので、世の中は難しい。

とりあえずの対策として、筆者はこのブログの内容をgitで管理している。そのgitレポジトリはGitHubでもホストしていて、GitHub Pagesでも閲覧できる。こうすることによって、BloggerとGitHubが同時に検閲された場合でもローカルに全て残っているので、私はデータを失わない。外部のホスティングサービスがすべて検閲され、かつ、私の所有するストレージが全て強奪、破壊されたときのために、今、誰でも簡単に"git clone git@github.com:EzoeRyou/blog.git"というコマンド一発で複製できるようにしておくのも重要だ。gitレポジトリの複製が存在する限り、私は最新のコミットの40文字のハッシュ値を覚えておけば改変されていないことが保証できる。

2017-04-06

もしスマートフォンが自由だったら今頃実現していた社会

CanonicalがUbuntuをスマートフォンに対応させることを諦めた。これで、スマートフォンにまともなOSを移植するという大きな資本が入っているプロジェクトは、ほとんど全部潰れたことになる。これは当然の話だ。現在のスマートフォンのハードウェアは極めて不自由なので、まともなOSを移植することは不可能なのだ。このため、筆者はスマートフォンの所有を拒否している。

スマートフォンの害悪について詳しくは以下を参照。

本の虫: インターネット端末のシェアでスマートフォンがPCを上回ったというディストピア

しかしもし、スマートフォンが自由だったら、今頃どうなっていただろうか。以下はスマートフォンのハードウェアが完全に自由なコンピューターの将来実現したであろう未来である。

江添亮は13時に目が覚めた。今日は比較的早起きをした方である。江添は眠たい目をこすりながら枕元のスマートフォンを操作する。そう、なんと江添亮はスマートフォンを所有しているのだ。

このスマートフォンは、ファームウェアを含めてあらゆるソフトウェアが自由なコンピューターである。江添亮は自由なファームウェアを使い、その上に自由なブートローダーを使い、自由なカーネルを起動し、完璧に自由なユーザースペースソフトウェアを実行している。もちろんベースバンドプロセッサーの仕様とファームウェアとOSも自由だ。当然だ。不自由で不便で修正されない既知の脆弱性、アメリカ政府が保有している未公開の便利な脆弱性とバックドアが満載のAndroidやiPhoneなどは、とっくの昔に自由競争に破れて滅んでしまったのだから。

今日は休日だが外出する用事があるので、江添は家を出る。歩きながら、公衆無線ネットワークに参加する。今や、無線周波数帯のほとんどは、国民の自由な通信のために開放されている。なぜならば、表現の自由を脅かされない分散型の強い障害耐性を持つ通信ネットワークは、今や電気や水道と並んで重要なインフラであり、基本的人権の一部だからだ。テレビやラジオのような一方的に情報を垂れ流すだけの情報格差の発生する用途に周波数帯が専有、浪費されることはもうない。十分に広い道路を確保すると物流を改善し経済を回す。ネットワークと道路は同じだ。すべての周波数帯は国民の通信ネットワークに再優先で割り当てるべきなのだ。不必要に強い電波を発射する悪意ある電波発信者さえ取り締まればよい。

かつて、日本がまだ不自由だった時代、スマートフォンの通信は中央集権的な仕組みで行われていたと聞く。個々のスマートフォンの発信する電波は微弱で、今のように近隣のスマートフォンと通信して分散型ネットワークを構築するのではなく、強力な基地局を中心とするツリー型のネットワークを構築していたそうだ。これは基地局の管理者に、ネットワークの監視、検閲といった不平等な強権を発生させる極めて危険なネットワークである。

移動中の江添は、もっぱら情報の消費のみをする。これは手のひらサイズのタッチスクリーンで操作するコンピューターだ。このような制限された非効率的な入力装置では、まともなコードや文章を書くことは不可能だ。

さて、江添は目的地についた。しかし待ち合わせの時間にはまだ早い。珍しいことだ。いつもの江添は待ち合わせの時間になった頃に家を出るというのに。どこかで時間を潰す必要がある。そこで江添は、近くにあったターミナルカフェに入る。

「粉末ティーライクひとつとダイミョクラスの入力装置」
「ハイ、ヨロコンデー!」

ターミナルカフェとはドリンクを頼めばコンピューターを快適に操作するための端末と個室も一緒にレンタルできる実際安い作業場だ。江添は端末としてスマートフォンを持っているので、入力装置だけをレンタルすることにした。大画面高解像度のディスプレイ、Cherry MSの青軸を採用したキーボード、そして高精度なマウスをレンタルした。所有しているスマートフォンとは極めて信頼性の高い低遅延広帯域の無線接続が行われる。

作業をしていたが処理能力が足りない。やはり128コアしかない上にメモリが1TBしかない貧弱なスマートフォンでは、基本的人権が保証されない。江添は自宅に設置してあるコンピューターにssh接続をした。これでいい。これでこそ人権があるというものだ。この時代における人権とは、計算力がモノをいう。計算力の強いものは正しい。

計算力、懐かしい言葉だ。そうだ、もう計算力の時代ではなかった。トゥーメニーコアが主流となった今では、もはや計算力は問題ではなくなった。実際、江添が自宅に設置しているコンピューターのコア数は3メガ個ほどある。いや、4メガ個だっただろうか。コア数が1メガを超えた辺りから、もうそのへんはどうでも良くなってしまった。昔、まだ江添が若かった頃、ひとつのコアの計算時間を複数の処理でシェアしていたものだ。今は違う。CPUコアは実質無料である。本当の計算コストは、電力だ。たしかに、江添が自宅に設置しているコンピューターをフル稼働させれば、理論上は、大昔のRSA-4096程度は一時間もあれば任意の秘密鍵に対する公開鍵が計算可能である。ただし、その計算にかかる電力で江添の家計はカーオンファイヤー(ブッダになれなかった死者を乗せる地獄行きの車、転じて家計が苦しい時に使う)になってしまう。

そうこうしているうちに、待ち合わ汗の時間になった。それにしても、今はいい時代になったものだ。後は物理肉体を物理場所まで運ぶという技術的制約を解決できればいいのだが。

Wandboxのスポンサーになるべく、めるぽんに肉をおごってきた

WandboxというWebサイトがある。これはコードを与えるとコンパイルメッセージと実行結果を返してくれるサービスを提供している。コードとコンパイルメッセージと実行結果を保存してURLで共有する機能もある。

ここまではよくあるサービスだが、Wandboxが他のサービスと差別化を図っているのは、コンパイラーの種類だ。様々な言語のコンパイラーをサポートしているのみならず、同じコンパイラーでも複数のバージョンを提供している。これにより、あるコードの挙動がコンパイラーのバージョンで異なる場合の特定ができる。

なぜそんなサービスが必要なのか。コードぐらい自分のローカル環境で実行すればいいではないか。リモート環境にしたって、今日びVPSなど月数百円から使うことができる。ブラウザーから入力する程度の短いコードをコンパイルして実行するぐらい低スペックの格安VPSでも足りるではないか。

問題は、バージョンの異なるコンパイラーの混在と切り替えはだるいということだ。

例えばGCCを3-stage bootstrapでビルドするには1,2時間はかかる。しかも、数GBものストレージを消費する。ということは、GCCの過去のバージョンを10種類用意しようと思ったら、数十時間と数十GBが必要になるということだ。

C++コンパイラーはGCCだけではない。Clangもある。Clangの過去のバージョンを10種類用意しようと思ったら、また別に数十時間の数十GBが必要になる。

プログラミング言語はC++だけではない。Javaは? PHPは? Pythonは? Rubyは? これらの言語にはそれぞれ複数の実装があり、実装ごとに複数のバージョンがある。全部ビルドするには何百時間、何百GBも必要になる。

ほんの数行のコード辺のバージョン間の挙動を、たまに確かめたい時に、ローカルにそんな環境を用意するのはやりたくない。Wandboxの価値はここにある。

さて、そんな便利なWandboxだが、最近スポンサーを募集している。ドワンゴもスポンサーになっている。

Wandboxにはとてもお世話になっているので、ぜひともスポンサーになりたいところだ。しかし、私はクレジットカードという匿名性のない上に不必要な第三者に記録される送金手段を使いたいとは思わない。思えば、Wandboxのめるぽんとは久しく会っていない。めるぽんは無頼の肉好きであるので、めるぽんに直接、肉をおごることでスポンサーになることにした。

さて、めるぽんはグルメでいらっしゃるので、粗悪な肉でもてなすことは大変失礼に当たる。銀座にあるような高級ステーキ店ならば、めるぽんの舌も満足することであろう。しかし、店を探すのは難航した。というのも、店がまともな食事を提供するには、終日全面禁煙であることがまず必要となるからだ。ニコチン中毒の客にまともな味がわかるはずがないから、そのような店は味で客を得る努力をしていないはずで、味による市場の淘汰を経ていない。

さて、結論から言うと、筆者による店探しは完全に失敗した。これは私が携帯電話を持っていないために店の予約ができなかったためである。しかたなくめるぽんの行きつけの店に行くことにした。はじめからこうすればよかったのだ。めるぽんは肉が主食であり、普段から肉を食べ慣れているので、どこにでも行きつけのステーキ店の一つや二つはあるはずだ。

目的の店に向かう道すがら、我々はコンパイラーのブートストラップ問題の話をした。

ブートストラップ問題とは、あるプログラミング言語のコンパイラーが同じプログラミング言語で書かれている場合に起こる問題である。あるプログラミング言語で書かれたソフトウェアをコンパイルするにはコンパイラーがいる。コンパイラーもプログラミング言語で書かれたソフトウェアである。コンパイラーをコンパイルするにはどうすればいいのか。

答えとしては、まずコンパイラーを別の言語で実装するかハンドアセンブルするなどして作成する。そのコンパイラーを使ってコンパイラーをコンパイルする。後は、コンパイラーが前のバージョンのコンパイラーでも正しくコンパイルできることを保証すればよい。

GCCは歴史が長く、かつ多くの環境で標準のCコンパイラーでもあることから、ブートストラップへの対応は極めて優秀だ。かなり昔のバージョンのGCCでも最新のGCCがコンパイルできる。GCCの標準的なコンパイルは、3ステージブートストラップと呼ばれている。まず、システムのC++コンパイラーを使ってGCCをコンパイルするための最小限のC++コンパイラーと周辺ツールをコンパイルする。出来上がったC++コンパイラーで1ステージGCCをコンパイルする。1ステージGCCで2ステージGCCをコンパイルする。2ステージGCCで3ステージGCCをコンパイルする。2ステージと3ステージのGCCをテストして挙動に差がないことを確認する。テストが通れば、3ステージGCCは最低限のテストは通過したコンパイラーということになる。

他の言語はどうか。まず、ブートストラップ問題のない言語がある。あるプログラミング言語のコンパイラーが同じ言語で書かれていない場合、例えばCやC++などで書かれている場合、これは簡単だ。なぜならばGCCは極めて安定したコンパイラーであるので、ある程度最近の安定バージョンのGCCでコンパイルすればよい。

ブートストラップ問題を抱えている歴史の浅いプログラミング言語は問題だ。歴史の浅い、まだ発展段階のプログラミング言語の実装はとても急速に変わる。そのため、古いバージョンのコンパイラーは最新のコンパイラーでコンパイルできないという自体に陥る。そのためソースコードからのビルドが難しく、Wandboxではあまりにも古いバージョンのコンパイラーを提供できない。

このような話をしていると、我々は目的のステーキ店についた。空いていてタバコの害もなく高級な肉を出す店だった。

肉を食べながら、我々の話は、いかにしてめるぽんはプログラミングを学んだかという話題に移った。

人がプログラミングを学ぶ方法は様々だ。プログラミングの教育法はまだ学問として完全に固まっておらず、したがって多くのプログラマーは独学で学んでいる。筆者は幼い時にコンピューターがない環境で育ったので、参考書を読んで言語の文法と意味を脳内で理解するという作業のみしていた。さて、後にコンピューターを手に入れて、コードを書き、そのコードが想定通りに動いた時、筆者は目標を失った。なるほど、私の理解は正しかった。私はC言語の文法とその意味を理解している。ソフトウェアを書くことができる。しかし、今の自分の技術力で完成することがわかりきっているコードなど書いて楽しいのだろうか。そこに学びは何もないし、やりがいもない。自分ができるかどうかもまだわからないことに挑戦してこそ、やりがいというものは生じるものだ。そこで私はC++の規格書を読み始めた。そして今に至る。

めるぽんの経歴を知らない読者には、めるぽんがどうやってプログラミングを学んだかということに対して興味を抱かないだろう。この業界は実力主義で、ほとんどのプログラマーは独学でプログラミングを学んでいる。この業界では中卒と博士が机を並べて仕事をすることだって珍しくない。めるぽんがコンピューターサイエンスの学位や博士号を持っていないのにプログラミングができるというのは不思議でも何でもない。そう思うことだろう。我々は義務教育を不登校気味だった中卒がバリバリコードを書き、コンピューターサイエンスの学位を得た者がFizzBuzzすら書けないという話はいくらでも聞いてきた。しかし、めるぽんのような例は聞いただろうか。

めるぽんは高校時代、アマチュア・レスリングで優秀な成績を収めた。高校卒業と同時に自衛隊に入った。自衛隊では体育学校にいた。自衛隊は数年でやめた。自衛隊をやめた数年後には、すでにフリーランスのプログラマーとなっていた。

いったいめるぽんはどうやってプログラミングを学んだというのか。

めるぽんは高校時代、アマチュア・レスリングで優秀な成績を収めた。つまり、めるぽんは高校生まで相当な量の運動をしていたはずで、ガチガチの体育会系の人間だったはずだ。もちろん文武両道な人間はいくらでもいる。しかし、問題はその後だ。

めるぽんは高校卒業と同時に自衛隊に入った。自衛隊では体育学校にいた。自衛隊の体育学校というところは、運動中毒の人間だけが生きていける特殊な世界だ。世の中には運動中毒の人間がいる。「自衛隊に入ったら毎日、一日中、好きなだけ走ることができて、しかも給料が出る。最高だ」などと発言する人間のいる世界である。そして、この発言をした自衛隊員は何百kmも走るウルトラマラソン大会の走者で、実際に、文字通り一日中走っている。

運動こそ人生。仕事は一日中体を鍛える訓練。そんな環境でプログラミングの勉強ができるだろうか。

めるぽんは中学生の一時期、怪我をして柔道の練習ができなくなったことがあるそうだ。そんなめるぽんに、中学校の教師は、ではコンピューターをやれ、といってPC88だか98とプログラミング雑誌を渡したそうだ。当時はN88BASICの世界で、コンピューターを使うということはBASICでプログラミングをするということであった。当時のコンピューターは単純だった。電源を入れるとBASICインタプリターのプロンプトが表示される。BASICで書く。実行される。それだけだ。当時のめるぽんは、意味もわからないままに雑誌に記載されたBASICコードを入力し、当然入力間違いによりシンタックスエラーを起こし、その「シンタックスエラー」というものが何を意味するのかもわからないままにコンピューターを使おうとしていたそうだ。そして、わからないことがあると中学校の教師に質問に行った。

めるぽん「その教師、図画工作の教師で、他にも当時CADを使った授業とかがあって」
筆者「その教師、当時としてはおかしくないか?」
めるぽん「そういえばおかしい気がしてきた。なんであんな教師がいたんだろう」

さて、高校生になっためるぽんは、家の中で偶然にもBASICの教科書を発見する。なぜそんなものが家にあったのかはわからない。これによってめるぽんは、これまで意味もわからずに写経していたBASICのコードの意味を理解することとなる。

高校を卒業後、自衛隊に入り、その体育会系の空気とあまりの運動中毒に、自分には合わない場所だと判断してやめて、ゲーム会社に一年半ほど雇われた後、フリーランスになった。

肉がやってきた。めるぽんは肉が主食であるが、サラダも注文しておいたので、多大な説得の末、多少の野菜を食べさせることにも成功した。なぜめるぽんは肉を食べるのか。

めるぽん「肉と野菜のどちらを食べるかという選択が与えられた場合、これは当然肉を選ぶに決まっている」
筆者「なるほど、そして肉を食べた後は、野菜を食べるわけだな」
めるぽん「いや、肉を食べる」
筆者「寿司ではトロに満足した後は光物がほしくなるように、肉に満足したら野菜を食べたくなるものでは」
めるぽん「肉を選ぶという選択肢は依然として残っている。選択肢にある以上、肉を選ぶのは当然だ」

肉を食べ終えた後、我々の話題はバージョン番号に移った。

バージョン番号はソフトウェアの開発者が勝手気ままにつけるものである。今ではSemantic Versioningなどと叫ばれているが、本当にバージョン番号には何らの規則性もなく、したがってソートできない。Wandboxでは、バージョンの新しい順にコンパイラーを表示しているが、これは手動で順番をハードコードしているのだという。

自動でソートをしたかったが、数値や文字列による比較を拒否するバージョン文字列が多すぎて、例外ルールだらけになるので、結局手でやるのと手間が変わらない。

バージョン番号の付け方にも謎のルールがある。例えば、PyPyはマイナー番号の偶数と奇数で、Python 3.0対応版とPython 2.7対応版を分けているらしい。他にも、リリース版にもかかわらずバージョン文字列にrcと書いてあるものもある。

肉を食べ終えた我々は店を後にした。久しぶりに本物の肉を食べた実感がある。。

ドワンゴ広告

ドワンゴはWandboxのスポンサーになった。Wandboxはドワンゴの社員がコンパイラーのバグと思われるものを見つけた場合に、バージョンごとの挙動の違いを調べるのに役立っている。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

UbuntuがUnityを捨てる予定

Growing Ubuntu for Cloud and IoT, rather than Phone and convergence | Ubuntu Insights

朝からなかなか衝撃的なニュースが飛び込んできた。結論から言うとこうだ。

Ubuntu 18.04ではデフォルトのデスクトップをGnomeにする。Unity8の開発は中止する。スマフォ対応は中止する。おそらくMirの開発もやめる。

CanonicalのMark Shuttleworthは、Ubuntuをスマフォ対応させて、どこでも同じ環境が実現できるという目標をやめて、UbuntuをクラウドやIoTに向けて発展させると発表した。

これはなかなか衝撃的だ。たしかに、Unity8とMirはこの長年開発しているが、さっぱり日の目を見ないソフトウェアだった。4年も開発していまだに実用化に至っていないデスクトップサーバー、コンポジター、デスクトップ環境は見切りをつけるのは当然だ。また、スマフォは根本的に不自由なコンピューターである。不自由なコンピューターに対応するためにリソースを割くのは無駄だ。

convergenceとやらも無意味だ。もしスマフォが本当にまともなデスクトップコンピューターと同じ使い心地であれば、iPhoneやAndroidのような不自由OSとてデスクトップコンピューターと同じUIを採用していたはずだ。それが採用していないのだから、スマフォは根本的に使いづらいコンピューターで、だからこそおもちゃのようなUIを採用しているのだ。

Canonicalがサーバー用に家事を取るのは当然だし、ぜひ鈍重なRHELを駆逐してもらいたい。すべてのコンピューターは最新の安定版のGCCを使えるべきであり、RHELは業界の癌だ。

さて、個人的な影響で言うと、Unityがなくなることだ。私はあまりデスクトップ環境にこだわらないので正直何でもよいが、Unityのデフォルトのキーボード・ショートカットは気に入っていただけに残念だ。

2017-04-04

インターネット端末のシェアでスマートフォンがPCを上回ったというディストピア

Report: Android overtakes Windows as the internet’s most used operating system | TechCrunch

最近の調査で、インターネット上の閲覧に使うOSのシェアにおいて、2017年3月現在、AndroidのシェアがWindowsのシェアを抜き去ったそうだ。

これはつまり、いまインターネットに接続している個人が使うコンピューターは、デスクトップやラップトップではなく、圧倒的にスマートフォン(AndroidかiPhone)であるということだ。

何というディストピアな世界だろうか。

私が子供の頃、世の中の大人の大半がコンピューターを使いこなせず、我々の社会の日常生活が極めて非効率的であることに不満を持っていた。

しかし、当時の私は物事を楽観的に考えていた。何故といって、我々の世代は個人でも安価にコンピューターが所有できる世代である。コンピューターの性能は年々上がり、価格は年々下がっている。すると、我々の世代が大人になる頃には、全員がコンピューターを使いこなせるようになるはずだ。将来、コンピューターを使えないのはしぶとく生き残っている死に損ないのジジババだけになる。すると、我々の社会はコンピューター利用が当然で、誰もがコードを書ける社会になるはずだ。

残念ながら、そのような未来は来なかった。

「スマートフォン」と呼ばれるものの誕生が、我々をバカにしてしまった。スマートフォンではコードが書けないのみならず、まともな文章も書きにくい。スマートフォンの利用者の大半はただ与えられた情報を消費するだけの愚かな存在になりさがってしまった。情報を与える特権を持った者は、キーボードという効率的な入力装置を使いこなせる者だ。

我々の世代と、我々の次の世代は、スマートフォンという名の毒物によって汚染されてしまった。この手のひらサイズのタッチパネルを搭載した貧弱なコンピューターは、今や大半の人間が使う唯一のコンピューターになってしまっている。

筆者はスマートフォンの所有を拒絶している。我々の社会はとてもスマートフォンの利用が当然な社会になってしまったので、スマートフォンを所有しないということは、日常生活において大変な不便を強いられる。しかし、筆者は利用者によるOSの入れ替えやOSの改変を妨害し、コードや文章を書くのが非効率的なコンピューターを所有するのは利便性を上回るリスクであると考えている。

何というディストピアな世界だろうか。

2017-03-27

C++標準化委員会の文書: N4643-N4661

また新たなC++標準化委員会の文書が公開された。

[PDF] N4643:National Body Comments for PDTS 19216, C++ Extensions for Networking

ネットワークライブラリに対するNBコメント

[PDF] N4644: National Body Comments for PDTS 21425, C++ Extensions for Ranges

レンジに対するNBコメントコメント

[PDF] N4645: WG21 Telecon Minutes

電話会議の議事録。

[PDF] N4647: Working Draft, Extensions to C++ for Modules

#includeに変わる機能、モジュールのドラフト

[PDF] N4648: Editor's Report for the Module TS

モジュールのドラフトの変更点。さほど変更はない。

[PDF] N4649:Working Draft, Technical Specification on C++ Extensions for Coroutines

軽量な実行媒体、コルーチンのドラフト。

[PDF] N4650: Editor's report for the Coroutines TS

コルーチンの変更点。目新しい変更はない。

[PDF} N4651:Working Draft, C++ Extensions for Ranges

レンジのドラフト。

N4652: Editor’s Report for the Ranges TS

レンジのドラフトの変更点。だいぶ変更があるようだ。

[PDF] N4653: 2017-02 Kona Record of Discussion ISO/IEC

内容はN4654とほぼ同じだがなぜか標準化委員しかみられないようにBASIC認証がかかっている。

[PDF] N4654:WG21 2017-02 Kona Minutes

Kona会議の議事録。

[PDF] N4656: Working Draft, C++ Extensions for Networking

ネットワークライブラリのドラフト。

[PDF] N4657:Networking TS - Editor's Report

ネットワークライブラリの変更点。それほど大きな変更はない。

[PDF] N4658:Alternative accommodation (student residence) for the 2017-07 Toronto WG21 Meeting

2017年7月のトロント会議のために近くのホテルに割引を交渉した。

Pros: 安くて近い。

Cons: クーラーがない。7月のトロントは暑くなります。

[PDF] N4659:Working Draft, Standard for Programming Language C++

ドラフトC++規格

[PDF] N4660:C++17 DIS Ballot Document

C++ DIS(Draft International Standard)。もうこれ以上の変更はほとんどないはず。これが実質C++17となる。

N4661 Editors' Report -- Programming Languages -- C++

C++ドラフトの変更点。std::byteが入った。

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-03-23

4Kディスプレイを買った

出社中にふと思い立って秋葉原に立ち寄って27インチの4Kディスプレイを買った。今や、4Kディスプレイは5万円で買える時代だ。通勤途中にふらっと衝動買いできる程度の値段でしかない。

そして設置して今に至るが、もっと早く、10万円を切った頃に、いや買えるようになった時点で即座に4Kディスプレイを買っておけばよかったと後悔している。4Kディスプレイによってもたらされる圧倒的に快適な作業は素晴らしい。結局、我々健常者はコンピューターからの出力を目で得ているので、眼球にできるだけ多くのピクセルをぶち込むのが最も効率的な出力なのだ。

筆者の今使っているラップトップに内蔵のディスプレイは4Kなのだが、物理的な画面サイズが12.6インチしかなく、あまり4Kの恩恵を実感できていなかった。たしかに高いPPCMによりフォント描画は素晴らしい。フォントサイズを小さくしても、ピクセル数が多いので読むことは可能だ。しかし、物理的なサイズには限界がある。

そこで、今回は27インチとやや大きめのディスプレイを買うことにした。本当は33インチぐらいのディスプレイが欲しかったのだが、そのサイズのディスプレイは10万から15万ぐらいするのでやめておいた。

それにしても、10年前はひたすら高PPCMのディスプレイを待ち望み、サイズが小さくてもいいから高PPCMのディスプレイがほしいと思っていたのだが、まさかPPCMはもう十分だからサイズの大きなディスプレイがほしいと思う時代が来るとは思わなかった。

とにかく、27インチの4Kディスプレイを得たことでC++の規格書の閲覧がはるかに楽になった。C++の参考書執筆のためには必要な自己投資だ。

Ubuntuがブート時にmanual fsckが必要だとしてinitramfsで止まった時

Ubuntuが塊操作不可能になったのでREISUBでリブートしようとしたら、以下のようなメッセージを表示して止まった。

/dev/mapper/ubuntu--vg-root contains a file system with errors, check forced.
Inodes that were part of a corrupted orphan linked list found.

/dev/mapper/ubuntu-vg-root: UNEXPECTED INCONSISTENCY; Run fsck MANUALLY.
    (i.e., without -a or -p options)

fsck exited with status code 4.
The root file system on /dev/mapper/ubuntu--vg-root requires manual fsck

これはエラーメッセージの通りファイルシステムに不整合な問題が発生している。おそらく原因は先程正しくunmountできなかったためで、ストレージの故障ではないだろう。おそらくBを早く押しすぎたのだ。

この問題を解決するには、そのまま、fsck /dev/mapper/ubuntu--vg-root とコマンドを入力すればよい。そしてaと入力すると、運が良ければファイルシステムの不整合が修正される。