CDE (Common Desktop Environment)というと、大学に居た頃に情報系の友達のところに遊びに行ったりしたときに、机上に置かれていた、いわゆるランチボックス型の SPARCstation の筐体と共に、ある種の憧れを思い起こさせるものである。まあ、途中から嫌という程触れるようになって、なーんだ実は NeXT とか程洗練されてるわけじゃないのかぁ、などと思わされたわけだが、でも、ワークステーションのデスクトップと言えば、この CDE の感じを思い出すわけだ。
ところが、この CDE が何と今月からオープンソフトウェアとして公開される、という。時代も変わったものである。sourcesorge の CDE のページからダウンロードできる Linux 対応のソースは未だ alpha release だとのことだが、Wiki にあるビルドのインストラクション通りの作業を行って、手元の環境で build 可能であることは確認した。Debian（ただし non-free 扱いかもしれないが）でもパッケージが公開されればいいな、と思うが、実際に使うかどうかは……うーむ、XFCE4 でガッツリ環境構築しちゃってるしなあ。
【後記】現在の Solaris は GNOME ベースらしい……まあ、さすがに CDE はもう古いしなあ……
Linux 関連のコミュニティで defragmentation に関する質問をすると、脊髄反射としか思えない程のスピードで「Linux では defrag なんて不要なんですが何か？」という答が返ってくるものだった。しかしこれは嘘である。たとえ ext4 であっても、巨大なファイルを頻繁に読み書きしていたり、ディスクスペースが逼迫してきたりすれば、当然 fragmentation が生ずる。これは Microsoft が Windows NT 4 で defrag を外していたのが、Windows 2000 以降で復活させていたり、Mac OS X でもバックグラウンドで低負荷時に defragmentation を行っていたりすることからも容易に推測できることである。
少なくとも Debian GNU/Linux においては、distro はそんな脊髄反射的な思想に汚染されてはいない。最近は ext4 を defragmentate できる e4defrag というソフトがちゃんと /usr/sbin に入っている（もっとも、僕はこれを診断モード以外で使ったことがない……ディスクスペースに余裕がある限りにおいて、Linux と ext4 の組み合わせでは defrag が問題になることがないのは事実である）。僕のように Windows・Mac OS X・Linux の間を行ったり来たりしながら日常を過ごしている者としては、NTFS の defragmentation を Linux 上でできると便利なのだが、一時期出ると噂のあった ntfsck も話を聞かなくなったしなあ……と思っていたところに、興味深い記述を発見したのだった。
Advanced NTFS-3G Features というページを見ていたら……：
UltraDefrag for LinuxUltraDefrag is a powerful Open Source Defragmentation tool for the Windows Platform. It can defragment any system files including registry hives and paging file. Also one of the main goals of UltraDefrag is doing the job as fast and reliable as possible.
It is being ported to Linux and NTFS-3G for defragmenting NTFS partitions. Currently only a test version in console mode is available. Please read the included file README.linux for compiling and testing.
そしてページの下の方には、
ultradefrag-5.0.0AB.7.zip……beta 版だが、Linux 版 ultradefrag のソースへのリンクがあるではないか！
ultradefrag は、フリーの defrag ツールとしては Piriform Defraggler と並んでよく知られている。sourceforge で開発・公開がなされているというのもあるだろうけれど、この二つのツールはどちらも、パーティション全体だけでなく、ファイル単位での defrag にも対応していることが、その原因かもしれない。
とりあえず、上のリンクからソースの archive を取得してみる。展開して中の document を読むと……はぁはぁ、まだ configure とか使える段階ではないので、自分で Makefile を書き直してくれ、と。当たりをつけるために、ある程度書き換えてから make を走らせ、エラーメッセージを読みながら直して……を行うことにする。
まず、このソースをコンパイルするためには、ntfs-3g と ntfs-3g-dev をインストールしておく必要がある。僕の場合は既に入れてあるので、archive を展開してできる "ultradefrag-5.0.0AB.7" 内のディレクトリ src に入って、Makefile を書き換える。Makefile の修正箇所だけを抜き書きすると：
GCC=gcc
LD=ld
AR=ar
INCL=-I/usr/include/ntfs-3g -Iinclude
COPT=-DPPGC=1 -O2
GCCOPT=-DPPGC=1 -O2
LIB1=/usr/lib/x86_64-linux-gnu
LIB2=/usr/lib/gcc/x86_64-linux-gnu/4.7.1
NTFSLIB=/lib/x86_64-linux-gnu/libntfs-3g.so.*.0.0
……と、こんなところか。distro の違う人は適宜読み換えていただければよろしいだろう。このように Makefile を修正すると、make 一発で、udefrag というバイナリが生成される。このバイナリを /usr/local/sbin に移してから、/usr/local/man/man8 というディレクトリを切って、ultradefrag-5.0.0AB.7/src/man/udefrag.man を /usr/local/man/man8/udefrag.8 という名前でコピーしておけばよろしい。詳細は udefrag に何もオプション・引数を付けずに実行するか、man udefrag で参照していただきたい。
最後に強調しておくけれど、現時点ではこの Linux 版 ultradefrag はあくまでも beta version である。使用にはくれぐれも注意していただき、壊すわけにはいかないパーティションに適用するのは控えられることをお薦めしておく。
先の週末、ついに TeX Live 2012 が正式にリリースされた。僕が公開している『TeX Live を使おう──Linux ユーザと Mac OS X ユーザのために──』の記述も、既に TeX Live 2012 ベースに書き直してある。
鬼が笑うという来年の話だが、2013年までには、TeX Live 収録のフリーの日本語フォントセットで基本5書体をカバーできるようになっていてくれるといいなあ……と思う。TeX wiki の質問などでも分かるように、もう日本人以外で日本語を使うために TeX Live を使っている人達が存在するのだ。ここで、TeX Live を使えばフリーで日本語の活字媒体の様式を享受できる、という状況を整備しておくことは、世界レベルでの日本文化の認知・受容・評価にとって、極めて重要なことだろうと思う……いや、大袈裟な話じゃなくてね。
青空文庫に関しては、今更ここに説明を書く必要もないと思うけれど、著者没後50年以上が経過した小説・随筆等を電子化、公開している。
僕がどのようにこの青空文庫を利用しているか、というと、基本的には Windows Mobile で動作する PHS 上で『青空子猫』を使って読んでいるのだが、じっくり読みたい場合には、やはりちゃんとしたフォントで PDF 化して読みたい、ということになる。
青空文庫のフォーマットは、ルビ等をマークアップするかたちになっているので、XHTML や LaTeX 形式への自動変換が原理的には可能である。LaTeX 形式への変換は、OTF パッケージの作者である齋藤修三郎氏が『青空文庫を読もう！』で公開しているパッケージに収録されている ruby スクリプト aozora.rb で行うことができる。
しかし、齋藤氏はこのパッケージを最近はメンテナンスしておられないようである。無論、それは何も問題ないし、批判されるようなことでもないのだけど、今現在、僕の手元の環境でこのパッケージを使おうとすると、ruby1.8 用に書かれたスクリプトを 1.9 用に書き直す必要がある。まあ、書き直すと言っても、m17n 化されたのに合わせて、日本語のコード変換等に関わる箇所を削るだけで問題なくいけるはず……と思っていたのだが、少々甘かったようだ。
齋藤氏のスクリプトで変換を行う際、
、漢字《かんじ》
のように、句読点の直後から始まる漢字文字列に対してルビがふられている（お分かりと思うけれど、ルビをふる漢字の直後に《》で囲んでルビを書く書式である）場合、
、\ruby{漢字}{かんじ}
と変換されるべきところが、
、漢\ruby{字}{かんじ}
と変換されてしまうのだ。
この変換は、ruby の売りのひとつである強力なパターンマッチングを駆使して行われているのだが、僕は普段は ruby を使わない。う゛〜……と唸りながら、変換ルールの書き換えを試みていたのだが、あ゛ー、もうやっとれんぞ！ と、Twitter で齋藤氏に直接お聞きした。僕も自分でプログラムを書く関係上よく分かるのだけど、メンテをやめて大分経過してから、そのソースの解析を行わなければならない、というのは、これは書いた本人であっても多大なる苦痛を伴う行為である。それを知る者としては、氏に任せっぱなしというわけには断じていかない。うーん……とソースを睨み、メモをして……しかし作業は進まない。
改めて google the Big Brother にお伺いをたてると、『達人出版会日記』で該当部分を書き換えたスクリプトに言及されているのを発見した。変換ルールに関わる部分を github で公開されているスクリプトからいただいて移植すると……おお、これで問題なくできるじゃないか！ Twitter の方をチェックすると、齋藤氏もまさにそのスクリプトのことに言及されていた。齋藤氏には、いきなり不躾な質問でお手を煩わせることになってしまい、本当に申し訳ないことをしてしまった。ここに改めて謝意を表する。
……というわけで、昨夜から、頭の中でタスクの何割かを占めていたジョブを片付けることに成功して、今は気分がよろしい。いや、そもそも何のために青空文庫を PDF 化しようとしていたか、というと、宮沢賢治の『猫の事務所……ある小さな官衙に関する幻想……』をたまたま読んで、これに出てくる竈猫がまるで自分自身のように思われて、思わず落涙したからなのだけど。作成した PDF に一応リンクしておく。
http://www.fugenji.org/~thomas/pdf/nekono_jimusho.pdf
