Luminescence

昨日、Linux-3.3-rc3 がリリースされたので、早速アーカイブを取得した（これを今書いている端末ももう 3.3-rc3 で動作している）。例の kernel.org 騒動があってから、アーカイブを取得するのは Linux Torvalds の github から取ってくるのだけど、そのページに Linus がこんなことを書いていた：

Linux 3.3-rc3 .. the number of the half-beast?

「獣の数字」というのは、新約聖書の最後にある『ヨハネの黙示録』13章に出てくる。この章は、神を冒涜して民を支配する獣、そして、その獣の後を受けて民を支配し、獣の偶像を拝むことを強制する獣について書かれているのだが、その「第二の獣」が偶像崇拝以外に強制したことに関して、以下のように記されている。

また、小さな者にも大きな者にも、富める者にも貧しい者にも、自由な身分の者にも奴隷にも、すべての者にその右手か額に刻印を押させた。そこで、この刻印のある者でなければ、物を買うことも、売ることもできないようになった。この刻印とはあの獣の名、あるいはその名の数字である。ここに知恵が必要である。賢い人は、獣の数字にどのような意味があるかを考えるがよい。数字は人間を指している。そして、数字は六百六十六である。

――『ヨハネの黙示録』13:16-18（新共同訳より引用）

聖書根本主義者達は、ティモシー・ラヘイの『レフトビハインド』よろしく、もはや偏執と妄想としか言いようのないこじつけに精を出すわけだけど、そういう人々はきっとクスリでもやっているじゃなかろうか、と思う。実際、この『ヨハネの黙示録』は、ニガヨモギの麻薬成分による幻覚の産物なのではないか、という説もある位なのだけど、クスリの助けを借りたかどうかはさておき、この「幻」として書かれた文書を、そのまま現実にリンクさせようというのは、あまりに想像力を欠いた教条主義的行為だとしか言いようがない。だって、ヨハネも書いているのだ：「ここに知恵が必要である」と。

上に引用した 666 という数字に関わる記述を読むと、記者が読者に一種の謎かけをしている、と取るのが自然であろう。その刻印なしに社会活動がみとめられなかった、という、この 666 という数字。そしてその数字を刻印した「獣」の行為を見ると、「獣」の強制した行為はキリスト教やユダヤ教でタブーとされる偶像崇拝であり、そして当時キリスト教を迫害したローマ皇帝ネロこそが「獣」の正体だと考えるのが、一番無理のないところだろう。

皇帝ネロ (Nero Caesar) をギリシャ語で書くと Νέρων Καίσαρ (Nerōn Kaisar)。これをヘブライ語で書くと נרון קסר (Nrwn Ksr) となる。ヘブライ語はローマ数字と同じく、文字が数に対応しているので、文字と数字の対応関係をみると、50 + 200 + 6 + 50 + 100 + 60 + 200 = 666 ……ということで、皇帝ネロ → 666 ということになる。

Linus は Linux-3.3-rc3 → 333 → "the number of half-beast" と連想したわけだけど、Linus は暴政の挙句王朝を滅ぼしたネロ程暴君ではないだろう……と、誰かツッコまなきゃいけないと思うんだけどなあ。

このところ、Emacs の make が OS X 上で通らない。ここにある Mac は Snow Leopard で、Xcode 3 と homebrew を入れてあって、bazaar で落とした trunk のソースから make しているのだけど、X 上で gtk ベースで動作するように configure を走らせると、xterm.c のコンパイルで止まってしまう。

ポインタの処理に関する ifdef を決め打ちにするように書き換えれば通せるのは分かっていたのだけど、GNU 関係の bug report にそれに該当する記述が見当たらなくて、どうも奇妙だなあ……と思っていたのだけど、先日、ようやくそれらしき記述を発見した：

Bug 21974 - XrmSetDatabase should reset XlibDisplayDfltRMDB unconditionally

しかし、これで問題が解決したわけではなかった。今度は：

alloc.c:766: error: negative width in bit-field ‘_gl_verify_error_if_negative’

これに関しては……うーん、bug#9713: emacs 24.0.90 alloc.c assertion failure ってやつか？ しかしこれって既に trunk には反映されているはずなんだが……と思っていたら、homebrew の gtk+ と pango が update された模様。これがそもそもちょっとアヤしいんだよなあ……ということで、そちらの更新終了後に改めて make してみる予定。

実は、僕の手元の Mac には morisawa passport が入っている。U の業務用なのだけど、正直言って、年間五万円の維持費（そう、morisawa passport は購入しても所有できるわけではない……あくまでも一年間の使用権を持てるだけに過ぎない）は楽ではない。しかし、プロレベルでの組版作業では、やはりこの水準のフォントセットが必要になってくるわけで、つい先頃、一年間のライセンスアップデートを済ませたところである。

僕の方は、普段はこのフォントセットを使うことはない。Mac にはヒラギノがバンドルされてくるし、この Mac には Adobe の一連のシステムが入っているので、これに加えて小塚フォント（明朝・ゴシック各6ウエイト）も入っている。僕に関しては、これで何ひとつ不満はないのである。しかし……まあ、せっかく使えるんだったら使わない手はないかもしれないなあ、ということで、font map をちょこちょこと書くことにする。

実際にリュウミン等のフォントを使用してみると……あれー、意外と痩せた感じになるんだなあ。勿論、小塚のようにいっぱいいっぱいのフォント、例えば「新ゴ」等を使えば、そういう感じでない組版も可能なのだけど、少なくとも僕にとっては、手元の既存のフォントだけでも十分なようだ。もし、camera-ready な原稿を自分で組版する場合でも、ヒラギノと小塚フォントだけで十分間に合いそう……なのは、僕が広告媒体などの組版をしないから、なのだろうけれど。

ターミナルソフト等で使うフォントを何にするか、というのは、実はなかなか悩ましい。これでいいかな、と思っていても、文字幅とか読み易さとかで少々不満が残る。だから半年位で、他に何か選択肢がないか探すのが習慣化してしまった。

丁度、今はそんな時期なのだけど、『プログラミング用フォント Ricty』というページにふと目がとまった。最近流行りの合成フォントというやつで、Inconsolata と migu を合成した、いわゆる等幅フォントである。ライセンス上の問題から、フォント本体ではなく、フォント合成用のスクリプトのみが配布されている。

Inconsolata は、大抵の distro ではパッケージ化されているだろうし、TeX Live にも収録されている。migu フォントは、上記配布元から取得できる（僕の場合は最初から入れている）。さくっと合成処理を行うと……ほー。正直言ってあまり見た目が美しいとは言い難いのだが、非常に実用的なフォントである。全角空白が破線になった "○" で表示されるところといい、ソースなどで厳密に文字数を揃えるような用途を意図しているであろう作りといい、使いやすそうな印象を受けた……ので、手元のターミナルソフトと GNU Emacs のフォントをこれに変更。まあ、しばらくはこれを使ってみることにしましょうかね。