Image may be NSFW.
Clik here to view.![]()
このページは、Emacs Advent Calendar が空いていたので、休日の暇な午前中を使って、こっそり駄文を仕込むものです。読んでも1ビットもEmacsの利便性は向上しませんので、その点をご覚悟とご了承の上、お読みいただければ幸甚です。
GNU Emacs が誕生してから、31年が経過しました。最初のUnixのEmacsである、Gosling Emacsから数えても35年目です。流石に歳を取りました。
31年前といえば、日本の Unix 界隈ではまだJUNETだのシグマプロジェクトだのがてんやわんやだった頃(のよう)です。インターネットは、まだ一部の大学や研究機関にしかない時代(だったよう)です。64kbpsの回線がバックボーンと呼ばれ、常時接続するだけで、毎日、ウン十万円のお金が取られていた(らしい)時代です。資金に余裕のある中小組織は、3.4Kbpsで常時接続していた時代(だそう)です。そんな時代にできたEmacsが、まだ使われているのです。(伝聞系なのはなかなか資料が見つからないためで、古老の話を聞くしかないためです。)
1985年頃、Gosling Emacs をシグマプロジェクト向けに日本語対応させたシグマEmacsが誕生し、これが日本のEmacsユーザ普及の嚆矢となります。のちにシグマEmacsは、ソニーのNEWSワークステーションにも搭載されました。ただ、シグマは色々とアレだったそうですし、高価な商用ソフトウェアであったため、「無料で、ソースコードが読めて、かつ自分で自由に改造できる」テキストエディタ、GNU Emacsの爆誕は当時のUnixな人々に、救世主のように見えました。
ただし当時は、個人はおろか、中小企業ですらGNU Emacsのソースコードをネットでダウンロードするなんて夢のまた夢でした(そうです)。新しいバージョンが出る毎に、マサチューセッツにあるGNU本部から航空便で最新バージョンのソースコードを磁気テープで送ってもらい、それを東京都内の某ソフトハウスでコピーして、有志がバイクで各地を周り、希望者に配布していました(らしい)。ソースコードが自由にいじれるため、日本語対応を試みる人も雨後の筍のように現れました。とはいえ、Emacsの8bitに最適化されたsyntax や category等の日本語対応は困難で、フルスクラッチで書き直す人々がでる一方で、本家Emacsの日本語対応は電総研の日本語Emacs(NEmacs) に収斂していきます。
さて、30年以上前からメンテナンスされているソフトはそれほど多くは無いと思います。GCCもまだ28年です。思いつくのは、X Windows System (1984年生まれ)、LaTeX (1985年生まれ)、Emacs(1985年生まれ)くらいしかないのではないでしょうか。その中でも未だに、各種メジャーOSで利用でき、毎日、多数のメンテナからパッチがコミットされているのは Emacs くらいなものではないかとも思っています。
30年前も重すぎると叩かれていた Emacs ですが、当時に比べてCPUもメモリもネット帯域も何千倍も進化した今でも重いとか言われるのはいったいどういうことなんでしょうか。(お
これだけ長い間使われていると、利用者の年齢分布も、10歳代台から60歳代まで、幅広く分布してきます。1980年代・90年代に活躍したEmacs開発者を過去の変更履歴から検索すると、すでに鬼籍に入っている人も少なくありません。
話が脇道にそれますが、Emacsであまり知られていない特筆すべき特徴の一つとして、30年以上の変更履歴をきちんと保存してきたことにあります。Emacsのバージョン管理は、VC, CVS, Bzr, Git と変遷を続けてきました。そして新しいバージョン管理システムに移行するたびに、過去の変更履歴は細心の注意をもって移行されてきたのです(ただし、残念ながら開発初期の履歴は相当が失われています)。そのため、我々はたとえば「この変更はいつ行われたのだろう?」という疑問を、1990年代まで遡って調べることができるのです。これは、実は凄いことです。この履歴を git の log機能で見ると、色々と気付かされます。きちんと手入れされたご長寿ソフトウエアは、多くの場合、当初に比べてソースコードが読みやすくなります。古く汚いコードは手入れされ抽象化されて見やすくなり、不要な機能は削ぎ落とされていくからです。
さて、話を戻します。開発者が幅広い年齢層に分散し、ソースコードの経緯を知る人々が高齢化すると、意思決定が遅くなるのは仕方がないです。そして、その遅さのために、今、Emacsの存亡の危機が刻一刻と迫ってきています。そして開発コミュニティはなかなか身動きできていません。いわゆる unexec 問題です。
unexec とは、exec の逆です。execとは、実行バイナリをファイルからメモリに読み込んで実行することですが、unexecは、実行バイナリをメモリからファイルに書き出し(ダンプ)ます。そしてこの機能は「Emacsの中核部分だけはCで書いて、残りは別言語(Emacs Lisp)で書く」という役割分担のために利用されます。すなわち、Cで書かれた中核部分(temacs) と、lispで書かれた部分をコンパイル・リンクして、実行ファイルを生成するまでの仕組みがEmacsに入っています。
一言で言えば、unexecの肝は「リンカ」なのですが、リンカをOSに頼らずに実現することはできません。そのため、Emacsでは、Linux,Windows、Macなど、各種プラットフォーム用にばらばらに unexecが用意されています。Linux版のEmacs はこれを実現するために、glibcの malloc() の途中状態を操作する、malloc_get_state() および、mallc_set_state()関数を使っています。
しかしこれら2関数は、10年年以上、Emacs以外では使われていない関数でした。かつては、TeXもEmacsと同様に、中核のtexにマクロをコンパイルしたものをダンプしてptex や latexを生成していましたが、この仕組は2000年代までになくなりました。このEmacsのためだけにしか使われない関数のため、glibcのmallocは最新のメモリ管理技術についていけなくなり、お荷物となっています。そして1年以上前から、glibcの開発メンバーは、Emacs開発者グループに対策を求めてきました。
今年の10月、glibcの先端ブランチから、malloc_get_state と、malloc_set_state は削除されました。これらの関数がない glibc2.25が、予定されてる2017年2月にリリースされると、Emacsは使えなくなります。(さらっと言いましたが、この間には多くの議論がありました。詳しく知りたい人は巻末のリンクを参照)。
すなわち、Emacsはいよいよ、 unexec から脱却しなければいけません。その1つの有力な代替方法は portable dumper です。
portable dumperの最初の実装と提案は、2002年に京大から行われ、Meadowに取り入れられました。しかし、portable dumperの最大の困難点は、その性質上、Emacsの最深部を劇的に変更する上に、インクリメンタルな開発とデバッグが困難なところにあります。当時もMeadowyに入った portable dumperを、本家Emacsに入れようとする動きはありました。しかし、誰も20年以上、無事に動き続けているソフトウェアの根本を変更してリスクを犯す勇気はなく、結局、本家のEmacsに入ることはありませんでした。そして、今、この状況を打開するために、新たに Portable Dumper が提案されています。最初の提案から14年、EmacsのCのオブジェクトデータ構造も大きく進化しており、当時に比べてもさらに Portable Dumper の実現は難しくなっています。
長寿ソフトウェアの最大の欠点は、そのモーメンタムが大きくなりすぎて、大きな改造に躊躇が入ることです。Emacsの高齢化は、若年層のC部分の開発者の少なさの問題となっており、高齢なEmacsの開発者は、「自分たちの手が負えないのではないか」「若い人たちがEmacs開発コミュニティに入ってこなくなるのではないか」を恐れて、なかなか意見がまとまりませんでした。
はっきり言います。もはや、EmacsのC部分の全貌をきちんと把握しているアクティブな開発者は、片手で数えるくらいしかいないのです。能力の衰えを感じたり、興味を失ったり、別の職業についたり、管理職として忙しくなったり、不慮の事故や病気で死んだ多くの初期メンバーは去って消えました。
さて、タイムリミットである 2017年2月は刻一刻と迫ってきています。portable dumperのテストブランチもなんとか動き始めました。しかし、未だにEmacs開発者MLは揺れ続けているように見えます。30年無事に動いてきたシステムの根幹を変更する責任を負う勇気を、古参は誰もなかなか持てないのです。傍観者として見ていると、誰とは言いませんが、権力は強いけど保守的な人が、自分に責任がふりかからないよう、逃げているようにも見えます。しかし、私もそろそろ、高齢者の仲間入りになりそうなお年ごろです。若い時には理解できなかった、「たとえ放置していたら大変なことになるとわかっていても、大幅な変更をするリスクの方が怖い」気持ちを何となくわかってくるようになりました。
Emacsは衰退しました。
そして来年の2月、glibc 2.25 のリリースと同時に、死ぬかもしれません。
多分、死なないと信じています。ここにきて急激に、Portable Dumper ブランチのテストが盛り上がっています。しかし、事態はここに至っても流動的です。
参考文献
http://lc.linux.or.jp/lc2002/papers/nagano0920h.pdf
http://dev.ariel-networks.com/Members/matsuyama/dump-emacs/
https://news.ycombinator.com/item?id=11001796
https://lwn.net/Articles/673724/
https://lwn.net/Articles/707615/