ネットスラングLOL表現の変遷

どうもインターネット上を眺めていると、ネットスラングLOL表現について自分の育った環境下が全体であるように理解している人が多く見受けられ、そもそも知らない人が増えているようなので、ここで一旦まとめておきたいと思う。

なお、これらは私の手元にある集積的データベースにおいて確認されている情報であり、少なくともそれなりの信頼性はあるはずだが、必ずしも事実ではない可能性があることをご了承いただきたい。

LOL表現の歴史

(笑)

「(笑)」という表現は非常に古く、少なくとも1991年には既に見られる。 fjなどで見た記憶はないが、パソコン通信、ワープロ通信において黎明期から広く使われていたものと考えられる。

JIS X0208の括弧を使う「(笑)」は1998年頃から衰退。 1997年頃から入れ替わるように右括弧を省略する「(笑」が登場してくる。 1996年頃から「(爆)」「(涙)」「(泣)」といった表現が増えており、やがて右括弧省略形に発展するような形。

「(笑」のような右括弧省略形も割と息が長く、この表現の展は噂の「(暗黒微笑」なんかにつながっていく。

1997年頃にはサブカルチャー作品でこのようなネットスラングを使うキャラクターが登場する。

lol表現以外に様々な表現が可能なのがこの表現形式のメリットだが、絵文字の普及と共に廃れてゆく。

藁, ワラ

藁やワラといった表現が登場するには2000年頃から。 ローカルにはそれ以前から散見されるが、主には2chで流行している。

ちなみに、「(わら」を含めて「(笑)」を「わら」と読むようになるのは、1998年以降、ネットゲームにおいてであり、それ以前は(変換の都合もあるが)「わらう」と読むのが主流である。1999年頃になると対談記事などにおいても普通に「(笑)」が登場するようになるが、「わらう」とふりがなが振られている場合が多い。 (個人的には「わらい」と読んでいたが、やや少数派)

「わら」と読んでいたのは1999年以降の新参が多い印象だが、またたく間にこの読みが普及し、「わら」という音で表現されるようになる。

このことから藁、ワラといった表現が誕生する

wara, w

2chで使われるようになるより以前から、ネットゲームでは「わら」という読みが一般化しており、チャットでの変換の手間を省いて「わら」と表現されるケースが非常に多くみられる。

これは、チャットでのタイピングが行いづらいネットゲームの特性によるものだろう。一般的なチャットでは「わら」という読み及び表現は普及していない。

2000年以降に「w」が登場する。これはさらなる簡略化を求めて「w」だけを打ったものであり、「ローマ字入力変換なし」に由来するため、当時のMS-IMEに依存し全角である。

半角wが使われるようになるのは2003年以降。この頃にはネットゲームに限らず使われるようになっている。 特に若年層に浸透し、「(笑)」という表現は「ダサい」とされるようになる。

このときの若年層というのは基本的にケータイ(今で言うガラケー)ユーザーであるため、「w」を打つことは利便性がないどころか打ちにくいはずなのだが、広く使われていた。

この流行により急速に「藁」「ワラ」といった表現と廃れていき、また表記する場合でも括弧を伴わなくなっていく。

もっとも、若年層に浸透するよりも早く普及した2chにおいては「w」という表現は従来「(プゲラ」と表現されていたものに対応していたため、かなり強く嘲笑のニュアンスがあった。

ところが、2008年頃からこの事情は逆転していく。 つまり、「w」が徐々に(というより急速に)嘲笑としてのニュアンスなしに使われるようになり、逆に「(笑)」と閉じ括弧まで含めた形式が嘲笑のニュアンスで使われるようになる。

これはかなり複雑な経緯で、そもそも「(笑)と書くのはダサい」という風潮を前提として、(笑)という表現を馬鹿にして用いた、ということに由来し、これによって「(笑)と書くことによって馬鹿にしているニュアンスが伝わる」という状況が発生し、故に「(笑)という表現自体が嘲笑のニュアンスに見える」という変遷である。

これを踏まえてか、あるいは他の類推からか、括弧を伴わない「笑」という表現も増加する。 これが嘲笑のニュアンスなしに感情を伝える良い判断である、ということのようだ。

「w」を否定的に感じない人、というのは実のところ割と限られた文化圏であり、 一方でwや(笑)に対して嘲笑のニュアンスを取る人も意外と少ない。

とはいえ、「w」を重ねることで強く嘲笑のニュアンスを表現するということは今に言ったても行われているし、そのことを含めて「w」が「品のない発言である」と伝わること(こちらは嘲笑のニュアンスに関係なく、そのようにとる人が多い)も理解すべきであろう。 インターネットは自分の可視世界が全てではなく、公言することには責任がある。

草生える → 草

「wを重ねる」というのは、2ちゃんねるでも特に民度が低いとされた一部だけの文化だが、これに影響を受けたのがニコニコ動画である。

そして、ニコニコ動画において「wを重ねた状態」つまり「wwwwwww」が「草に見える」ことから、これを「草を生やす」と言われた。 あるいは、タイミングとしては判定しがたいが、2ちゃんねる内でそのような一部板以外で「w」を重ねることに対して「草を生やすな」という窘めが行われていることから、こちらが先行かもしれない。

いずれにしてもニコニコ動画が流行していた頃はユーザーは若年層が多く、「かなりの部分2ちゃんねるのユーザーとかぶっていた」ということであるらしい。

この場合の「草を生やす」は笑うことではなく、「wを重ねること」を述べているのだが、w自体が浄化された結果、「草生える」という表現が嘲笑のニュアンス関係なく(嘲笑の場合もあって)「笑える」「おもしろい」という言葉として使われるようになった。

これはそもそも感情にフィットする語感の良い言葉がなかったところへ、簡潔かつsound goodな言葉がついた形になる。

さらに発展し、「草生える=笑える」を「草」と表現するようになる。 草自体が「笑える」ことを示すようになると、「草を生やす」という表現は衰退。「草原」といった表現は減少しつつも、そのペースは「草を生やす」と比べると遅い。

ちなみに、この表現がoriginなわけではなく、これ以前の「ワロス」の置き換えであり、後には「こんなん笑うわ」(これも「こんなんわろてしまうわ」からの派生)も登場している。

「HTML」とwebの話

最近、「webエンジニアは閉じた世界しか見ていないのだろうか?」と感じるようなことがいくつもあった。

例えば

  • Ruby on RilasとRubyを混同する
  • JavaScriptとJQueryを混同する
  • 言語処理系と言語を混同する
  • 著名なフレームワークを使うのが当然であり、それ以外は存在しないものと考える
  • 全く異なる分野や利用法で使われている技術だということを頑なに認めない
  • 自分が勤めている会社の構造や手法や評価尺度が社会的絶対基準であると信じる

などだ。

で、今回は「HTMLとwebを同一視し、HTMLをwebだけのものであると考える傲慢さ」についてである。

HTMLの歴史と経緯

HTMLとwebは根本的には同一である、というのは正しい。

多くの人が知るとおり、webはCERNにおいて論文共有・参照手段として登場し、HTMLもまたこのために登場している。

HTMLはHyper Text Markup Languageなわけだが、「Hyper Text」とはなにかといえば、ハイパーメディアの一部たるテキストである。 じゃあハイパーメディアとはなにかといえば、multimediaに関連性をもたせたものである。

この場合、ハイパーメディアといいつつも現実的に考えられるのは画像くらいのものであった。 だが、潜在的には画像や動画を含めることができることを意識していた。

それらを文書でつなぐ、それがHTMLの役割である。 実際、HTMLのアンカーは「ハイパーリンク」と呼ばれている。

ここでは「マルチメディア」というのがテキスト、文書を含むものであることを忘れてはいけない。 これもまた当然に立派なメディウムである。

HTML2の時点では構造化文書であることが非常に強く意識されていた。 と、同時に、これが視覚的メディアであることもまた強く意識されていた。 この時点では論理性というよりも、視覚的意味合いによって構造化されるという感覚が強く、この過程は同じく論文のためのフォーマットとして誕生したTeXへの意識(あるいはroffへの意識)が感じられるものであった。

そう、ここまで構造化文書というのは、「章立て」といった概念はあるにせよ、文書自体が論理的構造を持っている、というのとは少々異なった。 論理的構造と視覚は一体だったのだ。これが当たり前のことであった。

HTML3によってこれは混迷を極めた。「webをリッチにしたい」という欲求はとどまることを知らず、JavaScriptが誕生し、より装飾的な機能が多く追加された。

一方で、HTML3時代には2つの、異なる意味が生まれていた。

ひとつは、web技術の応用だ。 webをあくまでWWWの世界に留めるのではなく、より広く使いたいという考え方があった。 既にWWWはインターネットの主要コンテンツであり、コンピュータはインターネットのためのものになりつつあった。 競争に勝ち抜くにはweb界の覇者となる必要があり、そのために力を注いだ技術を他のところでも使いたいと考えた、という流れだ。 例えばWindows 98のActive desktopなどがそれである。

もうひとつは、文書フォーマットとしてのHTMLの普及だ。 従来ドキュメントフォーマットというのはあまり良いものがなく、恐らく最善なのはPDFであり、そこにいたるまでのTeXであった。 Windowsは(docドキュメントを含め)いくつものドキュメントフォーマットを持っていたが、それらは標準化されておらず、Microsoftに閉じた存在であった。 roffはman roffであっても「イケてない」と考えられていた。 なにより最大の問題は表示向きでなく、HTMLは圧倒的に表示に適しているということだ。

だから、HTMLはヘルプドキュメントをはじめ、幅広く使われるようになった。 単にドキュメントファイルとして使われるだけではなく、様々なところで組み込まれて使われるようになった。

HTML4は決断のフォーマットであった。 HTMLはドキュメントフォーマットである、という立場を明らかにしたのである。

その上で拡張の余地として、

  • 動的要素を必要とする場合はクライアントサイドスクリプトを
  • 視覚的要素を必要とする場合はstylesheetを

使用するように求めた。 ちなみに、stylesheetとはイコールでCSSのことではなく、それがわからない人はJSSやXSLTについて調べておくとスムーズに理解が進むだろう。

HTML4は至ってstableであった。 諸々の問題はあれど、それらは取り込まれることなく進んでいた。 XHTMLにおける変更は、微々たるものであると言って差し支えあるまい。

だが、WWWの世界ではその間に様々なことがあった。 HTML4以降の歴史を動かしたのはGoogleであったと言って差し支えないだろう。 Ajaxが注目されるに至るまでの流れもGoogleのものであったし、HTML5策定時のGoogleに影響力は果てしなかった。

そして、Googleは明確な「オンライン派」である。 そもそもユーザーが直接にドキュメントを扱うことを良しとしない。だから、「HTMLをオンラインのものにしたい」と考えた。 これに対して反対する声、つまりレガシーなTeXのようなHTMLを尊重すべきだと言う声も強く、初期ではどちらかといえば「ドキュメントフォーマットである」という既定路線を維持する状況にあった。

だが、WWWがさらに成長し、webアプリケーションが基幹を握るに至り、すなわちGoogleが世界を支配するようになると否とは言えなくなってくる。 最初から「オンラインHTML」寄りだったAppleの存在の存在も多少あるが、この過程においての存在感は小さい。結局のところGoogleに対して否を唱えられる存在は既におらず、競争力という点も鑑みてMozillaがこれに同調したことにより、HTML5は「ウェブアプリケーションを提供する基盤」として位置づけられるようになった。実際、CSSには大手ウェブサイトが導入しているトレンドデザインをより簡単に書く方向となり、ウェブレンダリングの挙動はこれらを優先する(これらとことなるレイアウトデザインを許容しない)方向に振れた。

だが、必ずしもそれをよしとしない考え方もあって、HTML5というのは様々な思惑が混ざりあった言葉になった。

HTMLとCSSとJavaScript(ECMA Script)

HTMLとCSSはW3Cが、JavaScriptの仕様であるところのECMA Scriptの仕様はECMAが標準を策定している。

重要なのはこれらが「独立したもの」であるということである。 HTMLがCSSとJavaScriptと共に使わなければならないわけではないし、CSSがHTMLと共に使わなければならないわけではない。 それぞれが独立したものであり、これらは「ハンバーガーとポテトとコーラ」のような関係であるといっていいだろう。

独立した存在であるというのは、それ以外が存在しなくても成り立ち、なおかつそれ以外のものとも組み合わせられる、ということを意味している。

そもそもECMA Scriptに関していえば、JavaScriptの標準というわけでもない。 JavaScriptはECMA ScriptにないDOMに関する機能があり、こちらはW3Cが策定している。 結果として、JavaScriptに明確な言語仕様というものがなく、複数の(ある程度の互換性を持つ)実装が存在するに過ぎない。

ちなみに、「JavaScriptの実装」というと、「ChromeとFirefoxでしょ」と言う人がいるのだが、これは間違っている。 まず、Crhomiumが採用する(そしてNodeやElectronも使う)v8 JavaScriptエンジンがあるが、MozillaはC/C++で書かれたSpiderMonkey(Firefoxで使われているもの)のほかに、JavaでかかれたRihnoを持っている。 Safariが使っているJavaScriptエンジンはKJSソフトウェアがベースでv8とも別物。 Internet Explorerの最終的なエンジンはChakraで、Edgeも独自の実装(EdgeHTML)だった。さらに、OperaはPresto(JavaScriptエンジンのコードネームはCarakan)を採用していた。 Prestoは独自エンジンであり、プロプライエタリなので現存しないが、KJS SoftwareベースのJavaScriptエンジンを使うブラウザは(プロジェクトが生きているかどうかは置いておいて)存在するし、w3m-jsなんてものもあったりする。

webから独立したJavaScriptといえばRhinoを搭載するソフトウェアが実は結構多い。 Javaで書かれているアプリケーションから利用するのが割と簡単なので、SpiderMonkeyが圧倒的にウェブで使われているのに対し、Firefoxでは使われていないRhinoはアプリケーションでプラグイン機能を実現するために使われるようなことが多い。

また、Node.jsもv8ベースで有名な非ウェブのJavaScript利用例と言えるだろう。 ElectronになるとHTMLやCSSも含めてChromiumの機能を利用する形なので、非ウェブと言い切っていいのかどうか疑わしいが、それでも非WWWであるのは間違いない。

CSSに関してはほぼHTMLに依存している。XMLで使うこともできるのだが、この場合「XMLをHTML扱いする」という意図になってしまう。 このような場合はどちらかといえばXSLTが好ましく、XML CSSは基本的にウェブブラウザでXMLを表示するためのテクニックだ。

ただし、HTMLの外観を定義するのはCSSだけというわけではない。 JSS(JavaScript Stylesheet)というのもあるし、これ以外に関しても仕様上制約されているわけではない。 JSSが使われることはごく稀だが、実際に限定的なHTML(あるいはそのサブセット)に対しCSSでもJSSでもないスタイルシートを定義している場合が見られる。近年はレンダリング部分を既存のものに委ねる傾向が強くあまり見られなくなってきてはいるが。

HTMLの用途と位置づけ

ウェブにしか関心のない人は知らないかもしれないが、HTMLは広くドキュメントフォーマットなのである。

基本的なものであるにもかかわらず、ドキュメントフォーマットというのは今に至るまで以外なほど発展していない。 Microsoft Wordの強さというのもあるだろうが、ドキュメントフォーマットが「印刷向け」であるのも大きい。

純粋なドキュメントフォーマットとしては、現在使われるものとしては

  • PDF
  • PostScript
  • DVI
  • Microsoft Word
  • Open Docuemnt
  • RichText
  • roff
  • ePub
  • DocBook
  • HTML

あたり。 それらを生成するフォーマットは多くて

  • Markdown
  • GFM
  • PHP Markdown Extra
  • Pandoc Markdown
  • その他Markdown方言
  • ReSTructured text
  • TeX
  • LaTeX
  • POD
  • RDoc
  • Plain2
  • Asciidoc

などなどかりなたくさんある。

これらは「印刷か表示か」という点で性格の違いがある。 例えばLaTeXはプリプロセッサが処理するための正しい情報になる論理性があるが、出力自体は「太字」など視覚的な定義になっている。 これは、印刷してしまう場合、内部的にどのような情報を持っていたとしても失われてしまうことになるので、視覚的な表現が重要になるからだ。

manroffなどは端末上で表示するためのものだから、端末で表現可能な内容に偏っている。

Windowsヘルプフォーマット(.HLP.CHM)やDocBookなどは対応する環境が少ない。 結果的にオンラインドキュメント1で汎用性・交換性が高い形式というのはHTMLに限られてしまう。

次いでePubということになるだろうが、ePubは書籍を前提としており、オンラインドキュメントに最適化されているとは言い難い。2

この状況で、人に配布する整形済みドキュメントフォーマットとしては「HTMLが望ましく、HTMLしかない」という状況が存在している。 もちろん、ここではHTMLのサブセットはHTMLに内包するものとする。

webの世界というのはドキュメントを基本とするものであり、「みんなアプリケーションなんだからHTMLもアプリケーション化すべき」などというのは乱暴を通り越して愚かである。 HTMLの世界はwebに限らず広がっている、というのは、基礎教養と言えるだろうし、それ以上に自分の了見でのみ物事を定めようとすることを愚かと呼ばずしてなんと呼ぼうかという思いだ。


  1. オンラインドキュメントとは、コンピュータ上で読むドキュメントという意味であり、ウェブという意味ではない。

  2. ちなみに、ePubはそもそもXML/XHTMLベースであり、CSSを使用するものだから独立したフォーマットと呼べるかどうかはあやしい。

「シェル」と「端末(ターミナル)」の違いと詳細

【超ざっくり解説シリーズ】シェル(Shell)とは?シェルについて初心者にもわかりやすく解説するよというnoteを読み、ちょっと内容がひどかったので、Twitterで言及したものの、ちゃんと説明したほうがよかろうと考えて急遽、この記事を書くことにした。

「シェル」「端末」「端末エミュレータ」「端末デバイス」については、Mimir YokohamaのLinux基礎初級「シェルとコマンドライン」の中でやっている。 この内容をやる時期としてはかなり難しい部類に入り、かつ重要であることから、最近は端末デバイスを直接叩くといったことを含めて2時間以上じっくり取り組むことが多い。

内容自体はそれほど難しくはないと思うのだが、理解に至るには

  • 入出力
  • デバイスと接続
  • カーネルとシステムコール
  • プロセス
  • ファイルディスクリプタ
  • デバイススペシャルファイル

に対する理解が前提となるため、ちゃんと認識できていないと難しいかもしれない。

なお、このあたりはOSによって非常に大きな差異があるところなので、ここではLinuxを前提に説明する。 ここに書かれている内容では理解に至るには足りないと感じられる方は、ぜひMimir Yokohamaの授業を受けてみてほしい。 じっくりと丁寧な説明とハンズオンによって理解できるまでしっかりと授業を行っている。

カーネル

カーネルはCPUの特権モードで動作するプログラムである。

実際に定義としてはそれしかなく、カーネルが実際にどのような仕事を担っているかというのも特に決まってはいない。

とはいえ、カーネルにやってほしい重要なこととして「リソース管理」というものがある。 最近のOSはタイムシェアリングシステムなので物理的な装置数以上のプロセスを起動することができるから、プロセスが好き勝手にリソースを使ってしまうと色々奪い合ってしまうのだ。 一番わかりやすいのは、「ハードディスクのアームをどっち方向にどれだけ動かすか」というモーター制御を奪い合ってしまうという状況ではないだろうか。

というわけでリソース管理をするためにカーネルとしてはプロセス管理をしなければならぬ、ということになる。

だが、カーネルというのは基本的にそういうことをする。 つまり、コンピュータを使う上で必要な環境を整える、コンピュータという舞台を作る、というのがカーネルの仕事だ。 ここが改善されるとそれを使う全てが改善されるため開発にも力が入るというものだ。

端末とコマンドライン

カーネルはプロセスを起動する仕組みを提供し、起動したプロセスを管理してくれるのだが、ここで問題になるのは「どうやってプロセスを起動するか」だ。

Linuxの場合、カーネルロード時にinitというプログラムを実行し、initが色々なプログラムを実行するようになっているのだが、 これでは任意のタイミングで必要なプログラムを実行するという方法がない。 また、プロセスやカーネルにユーザーが対話的にやりとりする方法がない。

いや、実際にそう時代もあったのだ。 コンピュータがパンチカードマシンだった時代、プログラムを実行するというのはパンチカードを差し込んで読み込ませることだった。

だが、タイムシェアリングシステム時代になると、ユーザーとコンピュータは「やりとり」をする必要が生まれた。 それも、できるだけ使いやすく。

ここで使われるようになったのが「テレタイプ」である。

テレタイプというのは通信機能(送受信機能)をもったタイプライタである。 言ってみればモールス信号とFAXの中間みたいな感じで、電話回線を通じて(手動交換機を通じて)ほかのテレタイプの紙に印字できる。

テレタイプ自体は1920年代には存在していたもので、1960年代にコンピュータに接続して使われるようになった。 当時の「最もポピュラーのコンピュータとユーザーが意思疎通するための機械」だったのだ。

ユーザーは、タイプライタ同様にテレタイプでタイピングをする、あるいは予め打ち込んで紙テープに出力したものを読み込ませることでコンピュータに対して意思を伝える。 コンピュータからの出力はテレタイプを通じて紙に印字される。

この仲介をするのがシェルなわけだけれども、この時点ではシェルと呼ぶようなものは必ずしも必須だったわけではなく、単純にテレタイプ・インタープリターのようなものであったし、 それ自体が「OS」と呼ばれることが多かった。

Linuxでも端末のことをテレタイプ(tty)と呼ぶが、実はUnixですらテレタイプは過去のものだった。 1970年代にはビデオディスプレイ端末が登場しており(Unixは1973年に登場)、Unixの端末というと紙テープではなく画面を使うもののイメージが強い。

紙テープから画面になることの違いは、「入出力環境が複数行になる」ということである。 例えばUnixのエディタコマンドとしてex(1)とvi(1)がある。 ex(古くはe, そしてee, ed)はラインエディタであり、一行で入出力ができる。つまり、紙テープに適している。 だが、ビデオディスプレイなら複数行を表示し、それを見ながら編集できる。それがvi(VIsual)なのである。

そして、もうひとつ大きな点として「表示上での削除が可能になる」ということがある。

だから、キーボードから打ったものをそのまま解釈してプロセスを起動する、という方法より「よりよい方法」が登場する。 それが「コマンドライン」である。

コマンドラインは、ユーザーはその意図を「行」に記述することができる。 行単位なので、改行したときがその意思の確定である。

このコマンドラインを快適なインターフェイスとして利用できるようにしたのが「シェル」である。

シェル

コマンドラインの基本的な考え方は前述の通りだが、Unix原初のシェルであるshは

  • 行を編集する機能
  • コマンドラインで複数のプロセスを起動する操作
  • ファイルディスクリプタをファイルに対して再オープンする操作
  • 出力ファイルディスクリプタを別のプロセスの入力ファイルディスクリプタへのパイプにする操作

など様々な機能を搭載した「超高機能インターフェイス」であった。 ユーザーは1行の「コマンドライン」の中で実に様々な操作を行うことができる。

今にすればshなんて貧弱極まりないのだが、当時の感覚からすれば「キーボードから打ったものがそのままコンピュータの動作になる」などというのと比べ信じられないほどいろんなことができ、様々に応用できるスグレモノだったのだ。

これがスグレモノである点として、「プログラムを記述する必要性が下がる」というのがある。 インターフェイスが単にキーボードから打った内容に基づきプロセスを起動するだけであるならば、全ての操作は事前にプログラムを用意しておかなければ行えない。 shは実に様々な操作をsh自身によって提供し、なにより応用が効くようになっていたので、圧倒的にプログラムを書くのではなくコマンドラインを打つことで目的を達成できるようになったのだ。

基本的には、bashであれ、zshであれ、それらの「機能が豊富で便利」という点を強化したにすぎず、基本的には変わらない。 シェル自身もプログラムであり、別に特別なものではない。ただ、「インターフェイスが何もなければ対話的にコンピュータを使うことはできないが、シェルはただ対話的に使えるだけでなく、対話的に 便利に 使えるインターフェイスだ」というだけの話である。

カーネルに対して特別にくっついているわけではないし、Linuxシェルはユーザースペースで動作し、別にシステムコールを直に叩くわけではなく汎用性のあるライブラリ(例えばglibc)をロードし、実行する「対話的プログラム」でしかない。

ただ重要な点がある。シェルが登場したとき、コンピュータとやりとりするための機械はテレタイプ、あるいはビデオディスプレイ端末であった、ということだ。

Unixはそれがどちらであっても、あるいはどこのメーカーのテレタイプであっても抽象的に扱えるように「デバイスファイル」という仕組みによって扱うようになっている。 そのため、「端末デバイス」という抽象化したレベルで取り扱うことができ、この端末デバイスは、テレタイプのような一行のものなのか、あるいはビデオディスプレイ端末のような複数行のものなのか、という情報と合わせて取り扱うことができる。

現在は端末デバイスではなく、ビデオデバイスを通じて出力し、キーボードを通じて入力するのが普通だ。 これは一般的には「X Server→ビデオデバイス(カーネルインターフェイス)→ビデオドライバ(カーネル)→ビデオカード(ハードウェア)」の構成であるが、シェルは依然として端末デバイスを必要とする。 普通、シェルは直接にX Server、あるいはビデオデバイスを扱う機能はもたされておらず、あくまでも端末デバイスを使って入出力を行うようになっている。

端末、仮想端末

だが、現在本当に端末に繋がっているコンピュータなんてまずないので、物理的に端末を意味する端末デバイスファイルが用意できない。

そこで、実際には端末はなくても、端末デバイスとして扱える仮想端末デバイスと、コマンドラインの入出力に適した仮想端末ソフトウェアが使用される。

「テキストモード」においては、「仮想コンソール」と呼ばれることが多いプログラムを使用する。 このプログラムは、ビデオデバイスによってテキストビデオモードを設定すると共に、(テキストビデオモードの)ビデオデバイスを通じた画面出力と、キーボード入力の処理機能、 そして仮想端末デバイスの提供(Linuxでは/dev/tty*)を行う。 その上でシェルを起動すれば、シェルは/dev/tty?を端末として扱うことができるわけだ。

ターミナルエミュレータは単なるX client(あるいはWaylandクライアント)である。 つまり、グラフィカルアプリなのだが、これはこれで仮想端末を提供する。Linuxでは/dev/pts/*である。 やはり、この上でシェルを起動すれば、シェルは/dev/pts/?を端末として扱うことができる。

だから、例えば

% ls -l /proc/$$/fd/0
lrwx------ 1 haruka haruka 64  6月  1 00:19 /proc/2835/fd/0 -> /dev/pts/0

ということである。

なお、端末エミュレータはキーボードを処理しない。X serverから受け取ったキー入力を仮想端末デバイスを通じて入力するようになっている。 だから、「シェルの標準入力はデフォルトでキーボードに繋がっている」というのは嘘で、対話的シェルは入出力ともに端末デバイスに繋がっている。 仮想コンソールの場合、シェル→端末デバイス→仮想コンソール→キーボードと間接的につながっているのだが、ターミナルエミュレータの場合は全く繋がっていない。

ちなみに、「端末」といえば、DECのVT-100である。 1978年にリリースされたビデオディスプレイ端末で、まぁとにかく売れに売れて、端末といえばVT-100というレベルだった。

だから、VT-100の仕様が一般的で、VT-100と互換仕様の端末も出たし、仮想端末もだいたいVT-100と互換になっていたりする(そして、その設定がある)。

そして、もうひとつ。

xtermは、それを端末として扱うための色々なものを、自前でもっていたりする。

【Manjaro/Arch Linux注意】Yaourtは廃止になりました

すごくニュースだと思うんだけれど、全然話題になっていないけれど。

AURヘルパーである YaourtはAURからなくなりました

もう随分長いこと「非推奨」とされてきたのだけれど、ついになくなった、というかたち。

AURヘルパーの中ではYaourtが最も親しまれてきたし、最も有名だった。 「Yaourtを使う」というのが当たり前になってもいた。

けれど、近年はセキュリティ上の問題があり、メンテナンスされていないことからobsolateになっていた。 で、今ついにAURからなくなった、ということ。

これに伴って、CommunityパッケージになっていたManjaroでもYaourtは廃止に。

今後はyayなり、Trizenなりを使っていくことになる。

そのうち「Yaourtを野良ビルドして使う」みたいな記事が出てきそうだけれども、 危険なのでやめましょう

Archwikiでは2019-05-20現在、日本語版はそのままであるものの、英語版はYaourtに関する記述自体が削除されている。

Axon7故障 → AQUOS R2 Compact購入

弱いAxon7

Axon7が壊れた。 画面が砂嵐になる、という症状だ。

どうもこれ、Axon7にとってはよくあることのようで、報告例が非常に覆い。 実際、私も以前この症状で一度交換している。

画面の接触の問題だそうで、強く押し付けたり踏んだりすると直ったりするし、 これで一時的に直してデータ移行をしたいのだが、画面がうつらなくなる可能性があるのではとても使えないので、嫌なタイミングではあるが機種変することにした。

Axon7に関しては、画面の問題以外にも、重量や発熱など基本的な部分に加え、やや不安定な挙動、WiFiをロストしがち、音楽再生中にオーディオボリュームを変えられてしまう、といった問題もあり、正直使っていてそんなにいいとは思えなかった。 ただし、Dolby Atomos, SD820, 3.5mmジャックありという構成自体は、音楽聴くにもゲームするにもよく、カメラ性能もそこそこ良いため、まぁまぁ活躍したのは確かだ。

移行先の選択

まず、前提としてサブ機である。

メイン機は6.4インチのOPPO R17 Proがある。ブラウジングや入力系、そして圧倒的なカメラの性能を踏まえてのカメラ機能に関してはこちらに任せることができる。 SD710なので、性能もまぁまぁ高い。また、画面が綺麗なので、写真を見たり動画を見たりするのも(スマートフォンではほとんどしないが)メイン機扱いで良い。

サブ機の主な役割はアカウントの使い分けという面を除外すれば、音楽を聴くこととゲームである。 そのため、

  • SDカードスロットと3.5mmジャックがある
  • オーディオエンハンスがある
  • SD820よりゲーミング性能が高い
  • 画面操作がしやすく、反応が良い
  • できれば小さく、軽い (ただし、ゲーミング性能を損なうなら非優先)

を条件とした。

SD820よりも性能を要求しているのは、主にはやっているゲームのためだが、 それ以外にもGPU的に重いアプリがいくつかあり、GPU性能が高いほうが快適性が高いためである。

最有力はAQUOS R2 Compactとした。

これは、登場時から、「SD845で、軽く、小さい。SDカードに対応していて3.5mmのジャックもある」ということから、まさにR17 Proの補完に最適であると考えていたからだ。 AQUOSスマートフォンは経験上、非常に上部で壊れない、という点も私を後押ししていた。 また、以前ASUS Zenfone 4 Selfie ProとZTE Axon7の性能・特性・得手不得手が似過ぎていて棲み分けが出来ない、という問題も踏まえている。

その上で店にいったのだが、日本語がやや拙いおねえさん(私にOPPOを推した人でもある。 でも購入したのは違う店だった)推奨のNova3が対抗の候補となった。 値段的にもR2 Compactより4割近く安いのは魅力的ではあった。

SDカードスロットがあり、オーディオエンハンスがあり、なおかつKirin 970を搭載しており、要件は満たすのだが、6.4インチでやはりR17 Proとの棲み分けが難しい。 また、Kirin970の性能、体感的にはSD710を搭載するR17 Proと比べても高くはないように感じられた。R17 Proは結構さくさく動くのだが、Nove3はフリップアニメーションなどがちょっと遅い。

もっと安い端末でめぼしい選択肢もなかったことから、当初の狙い通りR2 Compactを選択した。 大きな点としては、「Nova3もそんなに安いわけではないので、微妙に気の進まない端末を買うよりは愛用できる端末を買うほうが安い」という判断であった。

SH-M09 AQUOS R2 Compact 概要

SD845を搭載しながら、5.2インチディスプレイを搭載した145gのコンパクトスマートフォンである。

「5.2インチならそんなに小さくない」と思うかもしれないが、131*64*9.3(mm)で、132*66*9.6(mm)で4.9インチだった先代AQUOS R Compactよりも小さい。サイズ感としては、5インチスマートフォンよりも明らかに小さく、4インチ台だった昔のスマートフォンに近いサイズ感。重量も140gから135gへと軽量化された。

ただし、9.3mmという厚みは、6.4インチのR17 Proが7.9mm、特に薄かったZenfone 4 Selfie Proが6.85mmということを考えると、こちらもクラシカルで分厚い。アルミフレームだし、昔のiPhoneのようだ。

先代がSD660, 3GB RAM, 32GB ROMといったミドルクラスの性能を与えられていたのに対し、SD845, 4GB RAM, 64GB ROMというフルサイズのR2同様の性能が与えられている。「コンパクトスマートフォンはアンダークラス」という位置づけを破り、「R2のコンパクト版」に切り替えてきたわけだ。 画面が小さいので、自ずからSD845機の中でもベンチマークスコアは特に良い。

元々はソフトバンクキャリアで出ていた端末で、「らしく」、防水・防塵に対応。IPX5/8/IP6Xと本格的である。インカメラは8Mpxにすぎないが、アウトカメラは22.4Mpxと妥協なく、ディスプレイは2280x1080pxで120HzのハイスピードIGZO。 アウトカメラが22mm相当の広角レンズで、しかも光学式手ブレ補正つきあるという点も大きい。インカメラも画素数こそ少ないが、広角レンズで使いやすい。控えめな美顔機能もある。

「小さい」という点を除けば基本的にはハイエンド機の構成である。

さらに、最近のハイエンド機が失ってしまった、SDカードスロットと3.5mm4極のステレオヘッドセットジャックを持っている。

スマートフォンに全方位要求するが、手が小さいため大きい端末が選べないと歯噛みをしていた女性には最高の端末ではないだろうか。

ちなみに、特に女性向けというような売り方はしておらず、カラーラインナップも白と黒とくすんだ緑となんとも微妙。

使用感

速い

スマートフォンでここまで速いと本当に驚く。

私の印象ではスマートフォンというのは操作ごとのレスポンスが遅く、待ってばかりである。 指を離して次に指を置くまでの時間に操作が完了していないのは、もはや欠陥といっていいレベルだと思うのだ。

webの表示も遅く、快適性が極度に乏しい。 私がスマートフォンをあまり使わない理由がここにある。スマートフォンを10分使うなら、コンピュータを起動したほうが時間の節約になるし快適だ。

だが、R2 Compactは操作からして速い。 単純にアニメーション時間が詰められているのかもしれないが、アニメーションが速く、webの表示も速い。 さらにいえば、通信自体速く、Wi-Fiでのやりとりも速い。アップデートも速いし、アプリインストールも速い。 もう、「こんなに違うのか」と驚いてしまう。

120Hz描画のパワーもあり、さらに速さが強調される。最高である。

小さい。 軽いかどうかというと…

うちはたくさん端末があるのだが、パット見にR2 Comapctは古い端末に見える。 厚みがあってアルミフレームというクラシカルな外観も要因のひとつだが、いかにスマートフォンは大きくなっていくものだという認識が当たり前のものであったかというのを感じてしまう。

小さいだけに135gといいながらもった感じはむしろ重い。 ただし、持ち運ぶときは明らかに軽い。重さを感じるのは手で持っているときだけだ。

シャツの胸ポケットに完全におさまるサイズなのも良いところだ。

充電速度は弱点か

R17 Proは10分ちょっとで10%から90%まで充電してしまう超高速タイプであり、出かける直前に「あ、バッテリー」となっても着替えている間に間に合う。 Axon7もそこそこ速く、20%ほどでもごはんを食べている間に充電すれば60%は越える。

だが、R2 CompactはmicroUSB時代の急速充電と同等である。 1時間で20%くらいしか充電されないので、夜の間に充電しておくような戦略が必要になる。 USB Type-Cになってからはバッテリーマネジメントの戦略が不要になっている端末が多いだけに、この点は明確に欠点だと思う。

機能面は切り捨てられているレベル

ソフトウェア面で使いやすいかと聞かれると、「非常に使いにくい」とこたえざるをえない。

そもそもAndroid9が使いやすくない、という問題もあるけれど、それ以上に問題が山盛りである。

まず、「もつと画面点灯」が使いにくい。画面が拭けない。 これは「AQUOS便利機能→自動画面点灯→持つと画面点灯」でオフである。

Android9の問題である邪魔なGoogleアシスタントは、「Google→検索、アシスタントと音声→アシスタント→アシスタント→アシスタントデバイス→スマートフォン」でオフにできる。 深さに抵抗を感じる。

Android9の問題、WebViewでのフォーム入力をGoogleに送られてしまうことについては、「設定→Google→Smartlock for Passwords」でオフにすることで解消できる。

ゲーム中でも画面をスリープにされてしまうという問題は抑制する方法がない。画面スリープまでの時間を伸ばしておくのが現実的。

ナビゲーションバーは隠すように変更できるが、ナビゲーションバーを隠している場合、引き出す操作の反応はいまいち。 指紋センサーをマルチホームボタンとして使うことができるのだが、これはうまく操作するのは非常に難しい。ただし、指紋センサーのところにエッジがあるタイプの保護ガラスを使えば指紋センサーによるナビゲーションが現実的になる。

指紋センサーの反応はすこぶる良い。ただ、良すぎるため画面ウェイクアップを抑制しにくい。 指紋は、Android9の仕様に従いGoogleに保存される仕組みであり、嬉しくない。

導入されているアプリは

  • おサイフケータイ
  • からだメイト
  • OfficeSuite
  • SHSHOW
  • アルバム
  • コンテンツマネージャ
  • エモパー

と非常に少ない。 音楽プレイヤーすらない。今はサードパーティ音楽プレイヤーに対しては扱い厳しいのに。

ホームアプリも素のものに近いが、独自のものではある。

かといってGoogleアプリを入れまくっているわけでもない。

エモパーは大量の権限を要求する上に、現在地情報をオンにしておくことを要求する。 アルバムはカレンダーへのアクセスを要求する。

基本的な端末のハードウェアなどは悪くないので、設定などを練っていく手間をかけることになる。 OPPOはだいたいほしい設定になっているだけに、設定把握からはじまり面倒だ。

設定項目の追加などもなく、基本的には素のAndroidという感じ。 最近のAndroidが不十分であると感じている私にとってはいまひとつ。

良い点として、SH-SHOWはかつては「着メロ配信サイト」としての価値を担っていたが、現在においても色々と壁紙だったり、テーマファイルだったり、着メロだったり、あるいはS-Shoinの辞書だったりを配布していて、結構便利だったりする。 昔はパケット代を気にしてあまり使えなかったものだが。

ゲームはとても良い

私は「ゴシックは魔法乙女」というシューティングゲームをやっているのだが、反応が良いのでとてもやりやすい。 今のところ慣れないので被弾が増えてしまっているが、慣れてしまえば問題ないと思う。

ハイスピードIGZOのおかげで120Hz表示ができるのが良い。 何気に将棋ウォーズのエフェクトのなめらかさが際立っていたりする。 ちなみに、速さは将棋ウォーズでも生かされ、速く描画されるのでスピード戦である3切れはだいぶ有利。ただし、盤面が小さく、誤タップを警戒すると指すのはそんなに速くならないが。

「ゲームなら画面は大きいほうがよかろう」と思っていたのだけど、むしろこれこそいいのかもしれない。 重めの「カスタムキャスト」なんかももちろん問題ない。もたつきなく操作できる。

音楽は…悪くはない。

Dolby Atomosのインテリジェントモードはいまひとつであり、結局グライコがついているだけ、ということになってしまう。 疑似3D機能がなく、Axon7のものよりシンプル。

ただし、3.5mmジャックが上側にあり、グライコがあるというので十分でもある。

プレイヤーはPulserを使っているが、再生中はロック画面がアルバムカバーに置き換えられるのもまた良い。 ただし、そのせいでロック画面で文字がみづらく、ロック解除が困難になることもある。

優秀な日本語入力

日本語入力はS-Shoin。

画面が小さい、で最も最初に問題になるのは「スクリーンキーボードが打ちにくい」なのだが、S-Shoinは小さい画面でも打ちやすく、良好な予測変換を行う。私はATOKも買ってあるのだけれど、今のところS-Shoinを使いつつけている。

シャープ製端末はiWnnで、日本語入力に強いという印象はなかったのだが、2015年夏からS-Shoinが投入されたらしい。 これは大変良い。

なお、「Shoin」というのは恐らくシャープのかつてのワープロ「書院」から来ているのだろう。 なんとも懐かしい。 私はシャープ製のケータイ(フィーチャーフォン)を使ったことがないので知らなかったが、「ケータイShoin」なるものもあったそうな。

ちなみに、なぜかベトナム語と中国語のGboardが入っている。

留守電機能搭載

スマートフォンの非常に大きく、明快な機能的後退が端末の留守電機能がなくなったことだ。 キャリア製端末を使うのであれば、キャリアの留守番電話に加えて端末で使えることも多く、逆にMVNOユーザーとしてはどっちもなくて非常に困ることが多い。

私はほとんどの場合電話が出られない状況にあるので、留守番電話がない、というのは電話としての価値を大部分損なっているといっていい。

恐らく、Google的にはSMSがあるから必要ないという考えなのだろうし、実際欧米ではSMSが結構日常的に使われているのだが、 日本ではほとんど使われていないし、実際SMSが来ることはほぼないし、SMSを送ると「使い方がわからない」「受信者負担がある」といった理由で怒られることすらある。

AQUOS R2 Compactには「簡易留守録」という留守番電話機能が搭載されている。 ちなみに、AQUOS PHONE全般に搭載されており、AQUOSケータイにもある機能であるようだ。実際私はAQUOSケータイを持っているが、留守電機能は大変重宝している。 自動音声営業で埋め尽くされることも多いが。

この機能単独で選択理由になるレベルである。

持ちやすいけど、汚れやすい

基本的に端末はもちやすい。 が、どうも静電気強めのようで、ほこりがよくつく。しかも、背面ガラスなので指紋もよくつく。

結局、カバーとスクリーンガラスは必要だろう。 ただ、形状自体が持ちやすい上に小さいので、リング等を使わなくても、PVCカバーだけで十分機能を果たしてくれる。

Y!Mobileについて

ビックカメラ店頭でR2 CompactがY!Mobile非対応となっていたので気にしていたのだが、実際は問題なく使うことができた。

ただし、MMSに関するエラーが出てしまうので、Y!Mobileのページに従ってAPNを修正する必要がある。

評価は

★5である。

「使いにくい」を強調しておきながら…と感じるかもしれないが、結局のところ必要な機能が全てそろっていて、その機能が支障なくしっかり機能することは何者にも代えがたい。 目的に沿う、という理由で買っているので、それがしっかり果たされればそれだけで結構な満足ができる。

そして、SD710でも、Kirin970でも感じることのできなかった「速さ」が、明らかなストレス軽減につながっている。 機能面は設定やアプリ導入でかなりの部分が改善できるので、あまり深刻な問題ではない。OPPOのように明確なアドバンテージを生むことはできないが、それでもZTE端末や、HAUWEI端末でできる程度であれば何の問題もないと言える。

ハードウェア的な欠点、つまり「汚れやすい」「指紋センサーナビゲーションが使いにくい」が保護ケースや保護ガラスによって解決するため、ハードウェア的な弱点も残らない。

求める機能がしっかり機能し、その上でストレスがない、というのはもうその時点で満点をつけていい。

メイン機として考えれば、私はもうColorOSを知ってしまっているので、「メイン機はOPPOだろう…」という状態だからあまり話にならないが、もしOPPOがないとしたらメイン機でもぜんぜんおかしくない。 この場合、「ブラウジング用」あるいは「Twitter用」もしくは「YouTube用」にサブ機みたいな話になるのだろうか。 全方位強いのだが、「物理的に小さい」ことだけはいかんともしがたい。 ただし、それでも5.2インチ端末であり、「画面が小さい!!」というほどでもない。小さい端末いっぱいに画面というのはかなり強力なようだ。

解決できない問題を挙げるとしたら、充電速度になるだろう。 必要とされる直前に充電する戦略がとれず、出かける時間とバッテリー残量を気にしなければならないのはちょっとしんどい。

その点だけは明確に足をひっぱるのだが、Axon7においては決して快適とは言えない使い心地(特に日本語入力周りと重量、持ちにくさ)だったのに対し、小さく軽く、もちやすく、快適な性能と入力を備えるR2 Compactは、これ単独で持ち歩いくことが既にある。 Axon7時代は「Axonだけを持つ」ということはなかった (この端末は「プライベート電話、仕事ネットワーク」の構成である。メイン端末は逆で「仕事回線、プライベートアプリ」になっている) ので、これは体感的な使い心地を直接に表わしていると言えるだろう。

カスタムキャストでキャストデータを移行する

アプリとしての出来が悪いままのカスタムキャスト

ドワンゴのVTuber戦略は相当不調らしい。 まぁ、「当然だな」という越えがおおかったりもするのだが、登場当初は非常によく遊ばれ、期待も大きかったカスタムキャストがいまひとつ普及していないのも、その現れなのかもしれない。

カスタムキャストは元はアダルトゲームのカスタムメイドがベースになっている。 あれは、エディット機能自体は優秀なものの、DMM版含め出来がよくないという評判がもっぱらなので、必然なのかもしれない。 ありとあらゆる面でいまひとつであり、そのひとつとして「引き継ぎ機能がない」というのが挙げられていた。

やがて引き継ぎ機能が実装されたのだが、著しい「コレジャナイ感」が漂っている。

ほとんどの人は引き継ぎたいのはキャストデータだと思うのだが、キャストデータは対象外、というか引き継げるデータはほとんどない。 キャストデータを作るのは結構時間もかかるし、再現するのは困難なので、キャストデータが引き継げないとそもそも使い物にならないと思うのだが。

データをコピーすればOK

説明にある通り、キャストデータは端末に保存されている。 保存場所はAndroid/data/jp.customcast.cc2/以下である。つまり、このフォルダ以下をコピーすれば良い。 幸いにも現在データチェックは甘く、キャストデータをピンポイントに上書きしなくても、必要なデータを再ダウンロードする形で通してくれる。

ただ、私が試した限りだとgvfs MTPの制限なのか、このフォルダ以下にコピーすること自体ができなかった。 ただし、ファイルの作成や上書きはできるため、

のようなシェルスクリプト(これはサブフォルダ用)で処理できた。 これ以上深いディレクトリの中身は放置して良いし、cache以下は気にしなくて良い。

Windowsユーザーはどうすればいいか、という話は私が取り扱うべき話ではないから、 このフォルダをコピーすればいいよ、という情報を元にがんばっていただく方向で。

OPPOスマートフォンの「AR測定」がすごい

OPPOスマートフォン(R17 Pro)の先日のアップデートで新たに「AR測量」というアプリが追加された。

これは、カメラを使って距離や角度などを測ることができるアプリだ。

以前一部スマートフォンにレーザールーラーが搭載されていたが、これに代わるもの、というかはるかに強力なものになる。 せっかくのデュアルカメラだし、測量に活用できないかな、と思っていたので、まさに実現した感じである。

使い方としてては対象にカメラでピントを合わせるようにしてポイントすると、照準先のターゲットにアンカーを打ち込む。 これを複数打ち込むことで測定するわけだ。

ここがすごい

最初のアンカーに関してはレーザー測定なのか、離れていると打ち込むことができない。 ところが、ふたつめのアンカーからは結構離れていても打ち込める。

レーザールーラーは便利ではあるのだが、射程が2mほどしかないため、メジャーを当てにくい部屋や家具のサイズを測るのに使えない、という残念なポイントがあった。 ところが、このAR測定はそんなの関係なし、部屋のサイズだって測れちゃう。(ポイントを打ち込むときはレーザーの届く範囲に限られるが、打たなくても計測自体はできる)

また、距離計測でレーザールーラーの場合あくまでスマートフォンからの距離を測るのだが、AR測定の場合三角測量になっていて、カメラを計測対象のポイントに向けるだけでいい。距離の場合、第二ポイントに打ち込む前にポイントとの距離を出してくれる。 「端から端」をはかるとき、スマートフォンを端においてしまうと操作できないので、レーザールーラーは微妙に実用的ではなかったが、これなら非常に使いやすい。

計測できるのは「距離」「長さ」「角度」「面積」。 面積や、他でもカメラを持って移動するような場合は精度にやや不安があるが、だいたい分かれば良い場合は大変重宝する。

ポイントしたあとはその計測マークが画面上に残留する。ここが「AR」なのだろう。 カメラを移動させると、その測定したポイントを結ぶ線が空中に浮かんでいるように見える。 ちなみに、多分測量自体AR技術。

頭いいなぁ。数学の素養の問題なのだろうけど、ちょっとどうやったらこんな測定ができるのかわからない。 OPPOスマートフォンを選ぶ理由がまたひとつ増えてしまった。

フットプリントのおはなし

先日フットプリントの話題になったのだが、いまいちピンとこない人が多いようだったので、 情報技術におけるフットプリントについて解説する。

フットプリントとは

フットプリントは匿名の活動記録である。 それ単独の情報が固有である(ID代わりに利用できる)ものはフィンガープリントというが、フットプリントは単独の情報としてはそれほどの意味はない。 もちろん、統計上の価値はあるのだが、フットプリントという場合には、異なるアクティビティをつなげることを前提としている。

典型的なのはユーザーエージェントとアクセス元IPアドレスである。 IPアドレスは場合によっては固有であることもあるが、一般的には(普通のユーザーは)固有ではない。 よって、これらの情報は特にフィンガープリントとしては機能しない。

ただし、私の場合割と珍しい条件を揃えている。 まず、私のUAはMozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.122 Safari/537.36 Vivaldi/2.3.1440.61である。あまり特色がない、と感じるかもしれないが、(X11; Linux x86_64)の記載がある時点でだいぶ絞られる。さらにいえば、UbuntuやFedoraや(Vivaldiの場合どうかはわからないが)ディストリビューション名が入ったりするため、さらに絞られてしまう。

そして、私はIPアドレスも、固有ではないがかなり珍しい。 私の観測範囲においてはこの組み合わせを持つユーザーは他にいない。「観測範囲ではいない=活動範囲ではいない」であるため、逆に私の活動圏においてはこのUAとIPアドレスの組み合わせは私である、ということがわかってしまう。

これは割と珍しい例だ。例えば@NiftyでWindows 10のGoogle Chromeを使っているユーザーなんてたくさんいるだろうし、Softbank mobileのiPhoneユーザーもたくさんいるだろう。 ではこれらは全く特定できないか?というとそんなことはない。

まず、ある瞬間に同じIPアドレスを持つのは、同一のNAT内にあるコンピュータだけである。 ユーザーエージェントは意外と一致しない(ログをソートしても異なるユーザーで全く同一のユーザーエージェントを示すケースはかなり少ない)ので、連続的にアクセスしていた場合、そのユーザーの「特徴」を掴むことで同一人物であることを特定でき、またIPアドレスの変わり際はその「微妙に違うIPアドレスと行動の連続性」によって特定できてしまうので、追跡することができる。

IPアドレスとUA以外にも

  • 通信速度
  • 反応を返すまでの応答時間、ラグ
  • コンテンツ中のロードする内容
  • 滞在時間の傾向
  • 選択するリンクの傾向
  • ページロード中にページを離れる率とタイミング
  • タッチデバイスでの操作か否か
  • 表示領域のドット数とウィンドウのドット数
  • スクロール速度と量
  • スクロールを止める箇所
  • ページをクリックや反転させるクセがあるかどうか
  • ブラウザで有効化されている機能

などなどフットプリントとして機能するものは非常に多く、本気を出せば人物の同定は非常に簡単である。 避けることはできない。

もっとも、現実にはこのようなケースではトラッカーを使うほうがずっと簡単であるため、このような高度な行動分析は行われない。 このような高度な行動分析を必要とするのは、どちらかといえば私のように行動と心理に関する情報を必要としている者だ。

ちなみに、安心してほしい。 私はトラッカーが死ぬほど嫌いなので、私が提供しているサイトにはトラッカーはないし、不要にクッキーを使うようなこともしていない。1 統計的情報としての範囲を越える利用は全くしていない。

横断する恐怖のトラッキング

このようなフットプリントはローカルに持っていて、そこにとどまるのであればそれほど怖いものではない。 だが、横断すると話は全く別である。 横断すればその人がとっている一連の行動がわかる。ずーっとインターネットにおける活動を監視しているのと同じだ。期間が長くなってくれば、次の行動も予測できるようになる。

かなり大きいのは、Tポイントカード、Dポイントカード、楽天カードといったポイントカードの利用と、Suicaなど交通系ICカードの利用である。 これらはかなり利用を避けがたいのだが、ここに残っているフットプリントは結構致命的な内容である。 TポイントやDポイントやSuicaの内容がほいほい第三者に利用されていることについて、人々はもっと強く危機感を持つべきではなかろうか。

私は防衛型のハッカーなので、「まず自分が攻撃することを想定し、次にどのようにすれば防衛できるかを考える」という手順を取る。 これに則って考えれば、情報へのアクセス難易度や行動上の条件によって阻まれない、という前提のもとであれば、その人物が「どこに住み」「どのような生活サイクルで」「どのような手段でどこへ移動し」「どのようなクセを持っていて」「どのような行動を取るか」ということが把握できる。 どこに勤めているか、どのような生活をしているかはもちろんのこと、日用品が足りないのではないか、食料を買いにいかなければならないのではないか、ということも、次にどのタイミングでスマホでどのサイトを開くか…というのも手に取るようにわかるわけだ。 ここまで分かれば煮るなり焼くなりという状態である。ピンポイントにメールを送るも良し、フィッシングサイトで釣り上げるもよし、あるいはエンカウント数分前着程度の滞在時間で人気のないところで待ち伏せるもよし、である。

そんなまさかと思うかもしれないが、諜報機関ではこれくらいやる。 北朝鮮の拉致だって、今ならこのレベルでやるかもしれない。 というか、私で具体的方法を含めぱっと思いつくのがコレなのだから、ガチ勢はもっとやばいと思ったほうがいいだろう。

そして、このような横断してフットプリントを集めるという作業は日常的に行われ、私達は日常的に目にしている。 そう、ターゲティング広告だ。

「目立つフットプリント」は匿名化以上の損失になりうる

個人情報に紐付かないフットプリント の対応として適切なのは「森に入る」であり、なるべく紛れることである。

例えば匿名化ウェブプロキシでアクセスすると、身元が隠蔽されるため安全である、と考えるかもしれないが、実際のところ匿名化プロキシでアクセスしてくる人というのは非常に少ないので、大変に目立つ。 匿名化プロキシの効果でそれが誰であるか完全に特定できなかったとしても、そのようなものを使う人自体が大変少ないので、使っていること自体によってかなり絞り込めてしまう。

そもそもフットプリントから追跡対象を決めるときは「特徴によって決める」のが普通なので、目立つフットプリントはそれだけで目をつけられる可能性が高い。

検閲による効果は、検閲を回避する者にまで及ぶわけである。

特徴的な行動、少数派などは、フットプリントによる追跡からの防衛という観点から言えばなるべく避けたいのだ。

防ぐことの難しさ

正直なところ「祈るしかない」とは言える。

例えばテクノロジーに疎く、ケータイも持っていなくてSuicaも使わない、という人であれば追跡できないかというと、そんなことはないのが現代社会だ。 情報を過剰に収集している上に、あまりにもそれを濫用している。

現代社会においては極めて知悉した上で、細心の注意を払い、非文明的暮らしをすればフットプリントを限定的にできる。 だが、それはそれで「追跡しづらい、謎めいた人物」というフットプリントが浮かび上がってしまい、マークされることになるかもしれない。

このような不躾な追跡は、それが例え私の研究の進展に寄与するとしても、人の平穏な暮らしという観点から到底許されるべきではないと、私は思っている。


  1. WordPressを使っているサイトはWordPressが使っているかもしれない。それには私は関知していない。

論理的思考力 初歩

授業や講座でも人気の論理的思考力のおはなし。最近だいぶアップデートされたので、これをChienomiでも紹介することとする。

論理とは

周辺事情から間接的に事象を確定する(観測する)ことである。

論理は“真”または“偽”で表す。成り立つものが“真”、成り立たないものが“偽”である。 「部分的に成り立つ」ということはない。成り立たないこともあるのであれば成り立つことが証明できていないからだ。 偽であることは「必ずそうでない」ことを証明するのではなく、「必ずしもそうはならない」ことを証明するものである。

よって、物事は圧倒的に偽になる可能性が高く、真であることとは本質的に同一または包括関係であることが多い。 真であるとする証明が正しくないことを証明するためには、わずか一例でも成り立たない例を示せばよい。

論理は因果関係である。「Aであるならば、Bである」というものだ。 AとB(因果)を逆にしたものを「逆」という。 つまり、「BであるならばAである」ということだ。

逆は必ずしも成り立つとは限らない。特に、AがBを包括するとき、AであるときBは十分条件を満たすため真になるが、BはAの一部でしかないためBであってもAでない場合というのが存在することになる。 もし、AとBが同一であれば逆も真となる。

AとBが共に否定関係にあるものを「裏」という。 つまり、「Aでないならば、Bではない」というものだ。

これが成り立つためには、AがBにとっての必要条件である必要がある。 AがなくてもBを満たす方法があれば裏は成り立たない。 そして、「裏が成り立つ」と「AはBにとっての必要条件である」は等しい。

なお、論理的に言う「否定」とは「論理反転」を意味する。だから、「〜ない」を否定すると「〜である」になる。

「逆」と「裏」の両方にあたるものを「対偶」という。 「Bでないとき、Aではない」である。

対偶はあまり使わない。意味としては裏を逆にしたものであり、BがAの必要条件であることを意味する。 裏も対偶も真であるのに逆は偽である、というケースはだいぶ稀だ。 互いが必要条件であるならば、両者は密接な関係にあると考えて良いからだ。 ただし、必須の包括状態にある場合には、逆だけが偽になることもある。

これは高校数学でやるのだが、高校では数学をやらないケースもあるため、知らない人もいるだろう。 私も数学ではやっていない。

余談だが、「逆に言う」「裏を返す」は、まんま論理学的用語であるため、ちゃんと逆ないし裏になっていないと、私としては教養のない人だなぁ、という感想を抱く。

論理の初歩にナンプレを

ナンプレ(ナンバープレース)というパズルがある。

かなりメジャーなもので、やったことのある人も多いだろう。 一時期、Nintendo DSがリリースされたブームになったりもした。

ルールはシンプルだ。9×9の81マスがあり、各マスには1から9の数字が入る。 ただし、制約があり、縦列、横列、及び3×3で区切られた中には重複する数字を入れてはいけない。

ルールは以上だ。

このルールの時点で論理的に解法を求められる。 ちなみにもナンプレの攻略テクニックとしてこれ以外の方法があったりするのだが、ここはあくまで普通に論理的に解くこととする。

空行の候補は1から9の数字である。 これは、ルールによって定義されており、直接的に表現されている。

そして、ルールから「縦列、横列、または区画において出現している数字は除外できる」ということが導ける。 これら出現している数字をあてはめた場合、ルールに反することになるからだ。

ごく簡単なナンプレ問題では、このように除外することで候補がひとつしか残らないマスが出現する。 マスには数字を入れなければならないため、候補がひとつになった時点でそのマスの値は確定する。 このように順次確定することでマスを埋めることができる。

そのマスだけを見たとき、直接定義されているのは「1から9の数字が入る」ということだけだ。 だが、周辺事情によってそのマスの値は確定することができる。 それが確定するのは、そのマスの値が残された候補でないとき、そのパズルのマスを埋めることができない、という命題が真になるからだ。 よって、そのマスは最後に残された候補の値にならざるを得ない。

これは、「周辺事情によって他の可能性が消去される例」である。

もう少し難しいナンプレ問題だと、複数の候補が残る。 この場合、そのマスに値を入れるとその影響によって候補が残らないマスというのが発生する。

だが、そのマスの正しい値というのはわからない。候補1になるマスは存在しない状態だ。 しかし、いずれかの候補値を仮定すると、結果的に他のマスの値が確定することになる。

このとき、マスが「答を入れることができない」状態になることがある。残される候補が0になるのだ。 これはつまり、仮定した値が間違いであることがわかる。よって、仮定したマスの候補から除外できる。

これは、「Aの値がXであるとき、ゲームBはクリアできなくなる」が真になるため、「Aの値はXではない」が成立するのである。

このように問題を一旦仮定することで、成立しなければ除外するということができる。 これもまた、「周辺事情によって偽であること良いが明らかになる例」である。 先に述べたように「AであるときBではない」の裏「AでないときBである」が成立するわけではないことに注意してほしい。 例え仮定した結果成立したとしても、それによって真であることが証明されるわけではないのだ。

実際、ナンプレでも複数の値によって仮定しても確定する値が矛盾をきたさないこともある。 実のところ、ナンプレの場合は基本的には最終的には埋められる値は1つしかない。もっとも、数多い空きマスの全マスに対して仮定を適用するのは、人間にはちょっと無理だが。 だが、現実にはそうでない場合も少なくない。想定すべき全体像がわかっているとは限らないからである。 そのため、例え直ちに矛盾をきたさないことが、その仮定が正しいことを証明するわけではない―ただし、正しいのではないか、という推測は成り立つ。

パズルと論理

ナンプレに限らず、パズルではこのような論理性を持った論理パズルが多い。 クロスワードのような潜在的に特殊な論理性を要求するものを割と珍しい。もっとも、ビデオゲーム用のパズルは全く別だが。

このような最も基本的な論理の適用方法は消去法である。 まず現在の状態から採りうる候補を列挙し、状態の変化に合わせて消去していく。 回りくどい方法だが、「こうだからきっとこうだ」などと推測するよりはずっと正確だ。

ボードゲームも、総当りすることができるのであれば、このような論理ゲームとして成立する。 実際、マルバツゲーム程度であれば論理ゲームとして成り立つ。 ただし、実際はそれが不可能であるため、別の方法をとることになる。

「らしさ」と論理

ナンプレにおいては明確に制限された規則によって論理を求めることができた。 だが、実際にはそのような状況を設定することができないことのほうが多い。そこで、逆に規則のほうを設定して、「論理が成立する条件」を求めるという手法もある。

規則は前提条件である。命題自体には含まれていなくても、その命題が設定される時点で常に適用されるものになる。 例えば、ナンプレであれば、「ナンプレのルールにおいて」という規則がある。そして、ナンプレのルールという形で様々な条件が設定されている。

規則がまるで導入されていない状態で成り立つ論理というのは「真理」だが、これはかなり限定的であり役に立たない。 (さらにいえば、真理ですらも最低限、「この宇宙における法則において」という規則が導入されている)。 そこで、有益な論理を導出するために必要な規則を探すのである。

やってみればわかるのだが、規則が限定的になればなるほど論理を成立させるのはたやすくなる。 だが、実際には「規則は適切に限定されていなければならない」のである。これは、必要以上に限定的な規則では有益ではない、ということだ。 ちなみに、導入した規則の存在を忘れてより一般性がある論理であるかのように言うのは愚か者である。

基本的には成り立たない論理というのは、それが当てはまる場合と当てはまらない場合の両方が存在するわけだが、規則のほうを限定していけばいずれ成り立つ。だが、その場合、「命題が何かを証明しているわけではなく、規則によって結果が必然的である」ということもあり、このような場合は有益ではない。

有益な論理というのは、「規則、命題ともに適切に限定されており、同じことを指してより限定的である以外に成り立たせる方法がない」というものである。 そして、論理の追求とは発見している論理や規則を、これに限りなく近づけることである。

論理では確定的事象を扱うため、確率の話は基本的にはしない。 だが、観測においては「確からしさ」というものを取り扱う。これは、確率の話である。

勘違いされがちだが、確率というのは「割合」とは違う。観測された事象のうちN%が該当するから事象の成立する確率はN%である…というほど単純な話ではないのだ。 (もちろん、この物言いがやや統計学に喧嘩を売るものであることはわかっているが、確率が統計だけのものだと思ってもらっては困る)

それが真である確率を強調していうのに、語義は同じだが「蓋然性」という言葉を使うことが多い。 「真である確率」とは基本的には「真にならざるを得ない条件」の蓄積である。

例えば、「地球には雨が降る」という事象の蓋然性について考えるとき、まず地球圏に(十分な量の)水分が存在することに着目する。 そして、地球圏の温度が均一たり得ないことを踏まえて考えると、その水分は偏りを持って移動すると考えられる。

この時点で「地球には雨が降る」を偽たらしめるのは、水分が大気中に混ざったまま浮遊していられる量である場合や、地球上に雨となりうる温度条件が存在しない場合などだ。 気象の話を本格的にし始めると多くの読者を置き去りにしてしまうのでイメージの話にとどめておくが、これら「偽の可能性」はいずれも否定しうる。

結果として、「地球上には雨が降る条件が揃っている」「地球上で雨が降らない条件は満たすことができない」ことから「地球には雨が降る」を真とみなすことができる。

しかし、物事によっては「これ以上偽たらしめる条件がない」ことを確定できない場合がある。 あるいは、偽たらしめる命題が偽であることを証明できない場合もある。 これらの不確定部分を「確かであること」から差し引いたのが、事象の確からしさ、ということになる。

なお、この節は非常に短絡的に述べているのはわかっているし、それはブログとして書けるものの制約によるものなので、論理学・天文学・量子力学・統計学・気象学できる系諸兄にはお見逃しいただきたい。

予測可能性

事象は連続する、という自然な感覚がある。 これは、自然においてそうなっているからなのだが、感覚的にはそれを拡張して捉えようとする。

これは理系文系の違いであると言われることもあるが、基本的には法則性・規則性が強いほうが予見できる、というのは事実だ。 というよりも、法則性・規則性がないものは予見できない。

このようなものを我々が強く意識するのは命名規則においてだ。 例えばメソッド名にaddElement, delElement, editElementがあったとする。 この状態でaddGroupが登場すれば、きっとdelGroupeditGroupがあるに違いないと考える。 もちろんそうであるべきで、いきなりgroupDelchangeGroupValueなんてメソッドを導入すべきではない。

似たような話だと、Unix系ユーザーアカウント操作コマンドがある。 useradd, userdel, usermodは一連のコマンドなのだが、これとは別にadduser, deluserというコマンドもある。 これらは全く別の体系にあるコマンドであり、useraddusermodとはコマンド形式からして違う。

ところが、これだけ提示されるとmoduserがある、と予見してしまう。 実際にはなく、vipwを使うのが基本であった。ところが、いくつかのLinuxディストリビューションは、adduser及びdeluserを採用した上で、usermodだけを導入する、ということをしてしまった。これだと、「変更コマンドだけ語順が逆、しかも書き方も全く違う」という事態であり、大変な混乱をもたらす。実際、これによって混乱しになっていた。ている人は多かったし、LPICでも結構な間違いポイントになっていた。

コマンド関係で言うと、serviceコマンドは引数が「サービス アクション」の順なのだが、systemctlコマンドは「アクション ユニット」の順で、このあたりも予見可能性を低下させている。

このような予見は非常に強く働く。あるワードが登場した時点で、例え法則性を提示されなくても、法則性があるのではないかと考えてそれを探す、という行動は極めてよく見られるし、検索語句としてもよく現れる。 このことから、「人は非常に強く物事に法則性を見出そうとするし、予見可能性が低いものを非常に嫌う」ことがわかる。

もうひとつよくある話だと、+=演算子の話がある。

A = A + Bを表すのにA += Bと書けるのだが、四則演算は減算(-), 乗算(*), 除算(/)もあるから、-=, *=, /=があると考えるのが自然であり、多くの人はそのように予見する。 そして、そうなっている言語も多い。

だが、実はそうなっていない言語というのも結構ある。 例えばzshは+=しかない。

この理由は、そもそもzshは四則演算がArithmetic evalutionの中でしか行われず、裸で演算子を書くことができないからだ。 そして、+=は配列に対するpostpendとしてのみ書くことができ、-=は文意が不明瞭になるため実装されていない。 実際、Arithmetic evalutionを使って(( A += 10 ))のような書くことはできる。

+=を四則演算以外に適用できるようにするケースも多い。少なくとも文字列の追加には使えることが多いし、配列の追加にも使えることが多い。 Rubyでは+メソッドが定義されてさえいれば、A += BA = A + Bとして評価させることができる。(ただし、例によってAは一度しか評価されないので同一ではない)

そのため、+=は汎用的に使える、と予見しがちである。しかし、Perlでは+=は数値演算以外に使うことができない。 そもそもPerlでは+演算子事態が数値演算に限定されており、文字列連結は.演算子を使う。 Perlは最近の大抵の言語よりも古い言語なので、Perlに責任はないのだが、今は一般に+=を一般化して使うことができるようになっているため、Perlよりも新しい言語から学び始めた人はPerlの挙動に予見可能性が低いと腹を立てることになる。

さらにいえば、+=は非常にメジャーな演算子であるため、JavaScriptに+=演算子がないことを腹立たしく思う場合もある―私はとても思うのだが、検索してもあまりそのような意見は見ないので、ひょっとしたらマイナーな意見なのかもしれない。

この予見可能性は基本的に「その人の中で成立しているように感じている論理」に基づいている。 法則性というのは観測の限りであり、別にそうなるものだという証明がなされているわけではない。だが、見出した法則性というのはその人の中では成立している論理と等しく、これに反するものは非常に強く裏切られたように感じられる。

設計におけるユーザビリティとしては予見可能性を高く保つことは何よりも優先される。 これは、APIであろうが、UIであろうが、挙動であろうが全てに言える。 予見可能性の低いUXというのは、例えばゲームで爽快感の低い操作を強いられて、ようやく動きが出てきて操作に追従するようになってきたと感じた途端に長いロードが入る、というのを繰り返すような不快さを提供することになるのだ。

そして、予見可能性を高めるということは、その枠組みの中で成立する論理を提供する、ということでもある。 例えばvipwは古くからあるコマンドだが、これは/etc/passwdファイルに変更を加える。これはユーザー情報のファイルであり、であれば/etc/groupを編集するvigrがあるはずだ…と予見する。特に、後に/etc/sudoersを編集するvisudoが追加されたことから、vi$targetという法則性を見出すことができるようになったという点も大きい。 vigrはかなり長いこと存在しなかったが、やがて追加された。これは、「ユーザーアカウントに関する編集を行うコマンドはvi$targetである」という論理性を創造した、ということになる。

自分でコントロールできる範囲であればより積極的にそうすべきである。 例えば、parmas[user]パラメータがparams[user][name]のように連想配列として提供されるのであれば、params[group]のようなパラメータが例え項目がひとつしかないとしても、params[group]によって値を返すのではなく、params[group][name]のようにすべきであるる なぜならば、そのようにすることでparams[$type][$term]が予測できるようになるからだ。 良い名前は名前だけでそれが何に属するどのようなものかを推理する余地を与える。

論理的思考

「世に論理的思考と呼ばれているものは論理とは関係ない」とよく言われるのだが、ここではちゃんと論理に基づく思考を指して論理的思考としたいと思う。

論理的思考とは「AのときBたりうるか」に基づいて判断することである、と言ってよかろうと思う。 この思考が究極まで至ることができるならば、全てを知ることができるのだが、残念ながら観測を含めそうはならない。 そして、基本的には(思考停止しない限り)時間があれば論理的思考量は増やすことができるので、時間に対してこの検討がどれだけできるか、というのが論理的思考力、ということになる。

論理的思考において、既知の箇所はスキップすることができる(もし、既知であるという判断が間違っていたとしてもスキップしてしまうのだが)ため、論理的思考力によって論理的思考量が一律に決まるわけではない。 例えば将棋やチェスにおいては、必ずしも論理的思考力に優れる者が勝利するわけではなく、定石などを知っていればある程度確定した状態からスタートできるので、大きなアドバンテージを築くことができる。

また、将棋やチェスなどにおいては基本的に時間制限があり、考えうることを全て考えて指すことができるわけでもない。 このため、単純な論理的思考力によって決着がつくわけでもなく、思考経路によって大幅に左右される。 いい経路を選択すれば論理的思考量に対して得られる結果がよりよくなる。だから、現実にはよい経路を選択できる勘のようなものも非常に重要になってくる。

論理的思考において重要なのは「期待しない」ことである。 人はなにかに期待すると、そうではない結果を否定したい、というバイアスが働く。だから、論理を歪めたがる。 「情報は情報であり、事実は事実であり、論理は論理である」ということを見失わないことが大切だ。論理に血が通う必要などない。そんなものは、言動において通わせれば良いのであって、論理を歪めるために使うものではない。

また、論理の正しさを肯定しないというのは、自分の都合の良いように事実を肯定歪めようとすることである、ということも覚えておいたほうがいいだろう。

Chienomiは結論を提供しない

Chienomiに限らず、私が書く文章において結論は提供しない、というのは私の信条である。

なぜならば、人が思考する上で有益なのは情報であって結論ではない。 情報さえあれば、人はその論理的思考力と価値観によって結論を出すこともできる。

結論が声高な文章は不快なノイズである。 もちろん、経験に導かれる結論はあってもよいのだが、そこに一般性があるとするのはノイズ以上のなにかにはなりえないだろう。 これは、当人がいかなる結論を得たか、ということとは異なる。それは単なる情報であり、意味のあるものだからだ。

そして、私の書く文章は、何らかの特定の結論に達することを期待しているわけでもない。 なぜならば、私自身が特定の結論を持っているわけではなく、あくまでその時々の判断と判断材料にあるに過ぎないから、「この文章はこういうことを結論としているのだ」と感じ取ってしまっているのであれば、それは全くあなたの気のせいである。それは、もしかしたら現代教育の被害なのかもしれないが。

文面からしか文意を導けないのは、論理的思考力の欠如だろう。 私は何かを書くときには論理的完全性にはかなり気を使っているつもりなので、あなたの論理的思考力を活用すれば、より多くの情報が得られるはずだ。 もっとも、それが有益かどうかについては保証できるものではないが。

Hy Garden Leafs (はるかシステム) システムとストレージの構成 2019

さすがに無理をさせすぎたのだろうか。 マスター系ディスクに故障が相次ぎ、縮退運用となった。

従来であれば縮退運用中はなにもできないところであるが、今回は40万円近く出費しなければ置き換えられないこともあり、長期化は避けられない。 そこで、縮退運用について柔軟性をもたせた。これは以前のディスク故障からP720導入で行ったローカルシステムとグローバルストレージの併用を強化したもので、これが功を奏した形である。

ここまでの構成変化の歴史を振り返ろう。 なお、一時期運用されたがunstableで廃止されたものは除外する。

また、セキュリティ上の理由からマウントポイント等のファイル名はフェイクはフェイクである。

構成変化の歴史

最初期

SSD 64GB + HDD 500GB*4(LUKS, LVM Mirrored, XFS)であった。

SSDはルートファイルシステムなわけだが、として64GBと少ないため余裕が全くなかった。 そこで、500*4 (LVM mirror 1TB)のディスクを/homeにマウントする方式をとった。

システムとディスクは別々にLUKSで暗号化されており、データの集約はこのときから始まっていた。

問題は、データに関しては冗長性が保たれているためディスク故障にはある程度強いのだが、それでもこのストレージがマウントできないとほぼ使うことができないということだ。初期は/varもHDDにあったのだが、問題が多かったため廃止された。

まだこの時はシンプルな構成だった。

このときから3TBの初期に至るまでは、「LUKSが突然解除できなくなる」というトラブルに見舞われ、かなりのデータを失った。

3TBの導入

SSD 128GB + HDD 3TB*8。

単純に容量を拡大したようだが、大きな変更としてLVMをやめ、Btrfsに変更した。 実際はこの構成になってからかなり長い間従来と同じ運用をしていたのだが、LVMだとディスクは偏って使われることから分散して使ってくれるBtrfsに変更した。 ミラーレッグの追加がBtrfsのほうが簡単という理由もあった…のだが、実際はBtrfsのミラーレッグ追加はうまくいかないことが多く、理屈通りにはいかなかった。

また、LUKSで突然解除できなくなるトラブルを踏まえて、LUKSからdm-crypt plain(keyfile)に変更した。

従来は/homeにマウントする方式だったが、このときから~/.localにサブボリュームをマウントするように変更した。 この名前だけはフェイクではなく、~/.localというディレクトリがシステム的に使われるようになったときに困ってしまった。

定期snapshotもこのときから始まった。

2系統へ発展

( SSD 128GB + HDD 3TB * 8 ) + (HDD 500GB + HDD 3TB * 4)

Btrfs mirroredなマスター系に加え、Btrfs singleのスレーブ系が追加された。 この時期にはもっと台数の多い構成で様々なクラスタストレージを試したのだが、結局は内蔵しておくのが一番使いやすいという結論に達した。 そのため、かなり無茶な方法でケース内に、多いときは13台ものディスクを搭載していた。

この時期に様々な理由で内蔵できない時期があり、その場合SSHFSを使っていたのだが、低速であること、変なタイミングでI/Oが詰まること、rootがファイルを扱えないことなどから「いまいちである」という結論に達している。 また、ネットワーク不調などにより暗に切断されてしまうとファイルにアクセスしようとしたプロセスが固まるという問題もある。

スレーブ系統に対してはBtrfs sendを使ってデータを転送していたのだが、Btrfs send/receiveが途中で固まってしまうという問題に遭遇し、途中からrsyncによる運用に切り替えていた。 結局、これは「ATAエラーが出るとBtrfsはファイルシステムをreadonlyにする」という挙動に起因し、ディスク不調が原因だったのだが、Btrfsがディスク不調に非常に弱く、かつ適切なレポートをしないという問題は現在に至るまで解決されていない。Btrfsが変な挙動を示したらBtrfsの言うことではなくカーネルログを確認するというのが基本的手法と化している。

同期手法はクラスタファイルシステムのミラー機能なども試したのだが、最も「シャットダウンしやすく、家庭が使うには柔軟な方法」は任意のタイミングで転送を行うことだった。

マウントポイントは~/globalに変更された。

NAS導入

( SSD 256GB + HDD 3TB * N1 + HDD 3TB * N2…) : (x + HDD 4TB * N1 + HDD 4TB * N2…)

ホスト数1では対応しきれなくなったことから、複数ホストでストレージを構成することになった。 これに伴って、従来は中核ホストが全ブロックデバイスをまとめてBtrfsにしていたのだが、この構成となってから各ストレージターゲットは自身で「暗号化され、冗長化されたiSCSターゲットを提供する」という方式に変更された。暗号化処理がホストに分散されるようになったため、少し軽くなった。

また、基本的にはストレージをRAID5で提供するということにしたので、容量が稼ぎやすくもなった。非常に大きくなったディスクをカバーするため、ディスク単位以外にユニット単位での置き換えも可能になった。これは、イニシエータホストから見れば1ユニット(ホスト)で1台のディスクに見えるからだ。

一方、Btrfs RAIDはmeta mirror, data singleに変更した。これは、data mirrorであっても復元があまり現実味がないという事実を踏まえてのことだ。 実際に最もうまくいったケースですら、btrfs balanceの最中にディスクが故障して失敗したし、btrfs balanceは非常に時間がかかる。 もちろん、scrubによる修復も効かなくなるのだが、scrubで修復するようなケースで問題が解消したことがないので、素直に下層のRAIDに任せたほうがうまくいくという結論に達したのだ。

つまり、

  • ターゲットは冗長性とセキュリティ(ディスクの暗号化)を保証する
  • イニシエータはネットワーク経由で提供されるブロックデバイス(普通はiSCSI。AOEだと問題が出るケースがある)をBtrfsデバイスとしてmeta mirror. data singleで編成する

というルールである。

SSDが256GBになったこともあり、ある程度データをSSDに置くことができるようになった。 そこで、新たに~/intを追加し、ここに運用に必要なデータを置くように変更した。

この変更はかなり大きい。従来の方式だとグローバルストレージがマウントできない状態だと何もできない。 そもそも、XDGディレクトリがシンボリックリンクであり、そのポイント先がグローバルストレージにある場合、マウントしない状態でログインするとXDGユーザーディレクトリの設定自体がリセットされてしまう。 また、Clutter launcher(Cinnamonのアプレットとして標準のアイコンランチャ)は.desktopファイル自体が有効でない場合はlauncherの設定自体を破棄してしまうし、.desktopファイルで指定されたコマンドが実行できない場合はランチャから一時的に除外する。

このことから、~/intには日常的に作業で利用するXDG DOCUMENTSディレクトリ、~/binディレクトリ、自分のリポジトリ(~/devel)、フォント(~/.fonts)をはじめとするリソースファイル、ブラウザプロファイル1、メール(~/Mail)などが含まれている。

つまり、~/intがあることによってログインに支障が出たり、基本的な作業すらできなくなるという問題が解消され、ほとんどのデータにはアクセスできないが最低限ログインして作業はできる状態が保たれるようになった。

実はこのことはかなり大きく、グローバルストレージになんらかの問題が発生し、データにアクセスできない状況が発生するのは全く珍しいことではなかった。その間本当に「なにもできない」状態になっていたのだが、これを解消したのである。

果たしてその状況は現実に訪れた。複数ディスク故障により縮退運用に至り、これが長期化する見通しとなったが、もしこの作業をしていなかったらまるで仕事にならない状態が継続していたことになる。

Btrfs RAID5について

結論から言えば使い物にならない。

現状、Btrfs RAID5はbtrfs device replaceがうまくいく保証がない。btrfs device removeに関してはほぼうまくいかない。 完全にexperimentalである。

では気休め程度に使えるかというと、そんなことは全く無くて、Godavariマシン(A10-7870K)ではCPUが100%に張り付き、極めて不安定なI/Oを見せる。 連続で転送していると調子がいいときは2時間で200GB程度を転送できるが、調子が悪いときは17時間で20GBしか転送できない。 これは 書き込みだけでなく、読み込みでも発生する

ダメだ、ダメだと言っているばかりで誰も実用しないので実態がわからないから勇者になってみたのだが、まぁ、ひどい。

AOEとBtrfsについて

詳細はよくわからないのだが、まずAOEでmkfs.btrfsしたBtrfsボリュームはローカルにはマウントできないし、逆にローカルでmkfs.btrfsしたBtrfsボリュームはAOE経由ではマウントできない。

だけならいいのだが、マシンに複数あるブロックデバイスをAOEデバイスとして登録し、これをそれぞれAOEデバイスにした場合、そのBtrfsは再起動後マウント不能になる。


  1. 私は自作の、ブラウザプロファイルを選択した状態で起動できるプログラムを使用しているため、多数のブラウザプロファイルがある。