西田 亙の本：GNU 開発ツール -- hello.c から a.out が誕生するまで --
Categories Books | Hard | Hardware | Linux | MCU | Misc | Publish | Radio | Repository | Thoughts | Time | UNIX | Writing | プロフィール
思えば、苦節３日間、長い道のりでありました。suExec が犯人だった訳だが、それにつけても Apache 解説文書群のお粗末さよ。誰もがいい加減な内容しか書いていないものだから、世界中で私と同じ問題で未だに悩んでいる人がいるらしい。本気で調べ上げれば、これは Apache をネタにした新しい本が１冊書けますな。UNIX 上の「サーバークライアント」プログラミングを実践を通じてマスターする上で、Apache のソースは意外と良い教材になるかもしれない・・とも思う。さて、次は Mailman じゃ〜〜〜！
実は、既に Mailman はおろか、 も動いていたりする。WikiWorks にも食指が伸びつつあったのだが、色々検討した結果、今私が挑戦べきは LISP であるような気がしてきた。
で、当然 Gauche の解説を読んでみたが、やはり「実体」が明らかにならないと、一体どこに Scheme の本質があるのかが、分からない。調べてみると Shcemix は TinySchme に基づいているらしい。そして、この TinyScheme は、さらに Mini-Scheme から派生したものということ。驚いたことに、Mini-Scheme は日本人 Kida Akira 氏によるものであった。
Mini-Scheme は1989年頃の環境下で作成されており、コンパイルスイッチには TURBOC という懐かしい名前も見られる。ソースコードはＣで記述されており、総計2460行である。
十分小さいのだが、最初に取り組むにはまだデカイ。そこで、google してみると、見つけた！なんと、AWK で記述されたものだ。名前も「walk」と洒落ている。ソース一式は次のURLからゲットした。
学生時代に挫折した LISP に、四十を過ぎて再挑戦だ。早速、Amazon.com で LISP 関連書をしこたま注文。こうして本棚が太っていくのね・・。
8/27(水)に新専用サーバーが http://www.wnishida.com で起動した。最初はバカチョン式にtDiaryをインストール。本日は、腰を据えて再び挑戦。WiLiKiを意識して、スタイルはWikiだ！
ドロップダウンカレンダーが不穏な動きをする。なんでじゃ？まず、最初に行った修正は、uconvライブラリーのインストール。RedHat RPMの中に、uconvは存在しなかったからだ(本当はどこかにあるの？)。「こんな時、Debianなら簡単に探し出せるのに〜〜」と歯ぎしり・・。
dropdown_calendar プラグインを指定しても、プルダウンメニューが現れたり、通常の calendar タイプだったりと、不安定な動きをする。いや〜な感じ。真相を究明すると泥沼になりそうなので、./plugin/00default.rb 中に記載されている def calendar の中身を、そっくり dropdown_calendar.rb の内容と入れ替えた。これで、無事安定してドロップダウン式のカレンダーが表示されるようになった。tdiary.conf / @header 部分の <%= calendar %> はそのままで。
後は、skel/footer.rhtml や各種メッセージなど細かな部分を修正。tDiary/Wiki、なかなかいいじゃん、わたくし気に入りました。
それでは、早速本ページを http://www.skyfree.org/jpn/ で公開することにしよう。UNIX USER、初デビューから約２年。いよいよ、第二ステージに突入だ。
Subversion 導入を睨んで、Apache をインストール時の 2.0.40 から 2.0.47 に入れ替え、マニュアルインストールしてみた。
昨晩より qmail がダウン、６時間ばかり奮闘したが原因は不明。仕方なく再度インストール。この機会に /usr/local/qmail へ配置した。今日は、インストール日和か・・。こんなことなら、フルスクラッチでサーバー用ディストリビューションを作った方が速いし、何より見通しが良いのでは？(マジ)
ここ最近、qmail を始めとするDJ Bernstein 氏の作品を片っ端からインストール中。ひとつ困った点は、glibc の改変に伴い、氏のソース中 errno を使用している部分がエラーになってしまうことである。解決するためにはソースの訂正(ごく一部分)が必要だが、ひとつひとつ手作業というのは大変。と思っていたら、ftp://moni.csi.hu/pub/glibc-2.3.1/index.html という素敵なサイトを発見。DJB パッチ集がズラリと勢揃いしている。ありがたいことです。
ここのところ clockspeed に注目。例によって、オリジナルサイトは無愛想この上なし。日本語では http://tehanu.hpcl.titech.ac.jp/time/clockspeed/ 、http://quox.org/tips/server/clockspeed.html などがお勧め。面白いのは、前者のページで紹介されている FreeBSD の閏秒対応方法。tz.c で確認すると、Linux は閏秒には対応していないらしい。これではアカンだろうということで、しばし検索を続けた末にやっと発見。ftp://elsie.nci.nih.gov/pub/ で公開されている tzcode/tzdata パッケージが目指すブツのようである。「時間」というテーマは深く面白く、かつ重要なものだ。これは本腰を入れて調べる価値がありそう。
すっかり頭の中が閏秒で染まってしまった。時刻に関する検索をさらに深めたところで、タイトルの文献を発見。アイルランドはトリニティー大学で公開されているものだが、これがなかなかの名著。特にイントロは秀逸だ。DJ Bernstein 氏もこれぐらいのドキュメントを書く力量があれば、Richard Stevens 氏の再来になれていたのにねぇ・・。
定番の Linux-HOWTO シリーズにも、クロック関連のものが存在した。ざっと見た限りでは、clockspeed が取り上げられているものの、名前だけである。具体的な解説はなされていない。記事中で紹介されていた http://www.linuxsa.org.au/tips/time.html もチェックしておこう。
「時間城」とも言うべき総本山は International Earth Rotation and Reference Systems Service (IERS) にある。このサイト中に存在するタイトルのページを訪ねれば、時間に関する疑問が氷解する。ここまで紹介してきた資料だけでは、どうしても数多くの疑問が残るのだが、IERS の資料をひとつひとつ読み込んでいけば、そのほとんどは解決するだろう。
「新しいテーマに取り組むときはリファレンスに当たるべし」、これ鉄則也。しかし、この大きな地球が私達人間と同じように不規則なリズムをもって自転しているとは驚きだ(心拍数と一緒だね)。生物は揺れの中を生きている。地球もしかりだったとは、面白い！
以上で、時間を巡る旅は一旦終了。連載もの数回分に匹敵する資料が集まった。後は、カーネルやユーティリティーソースを検証して、細かな肉付けを行えば完成だ。
さて、これから子供を連れて森林公園へ出発。久しぶりに二人で汗をかこう、地球のブレに思いを馳せながら・・。
文書環境が劣悪の Linux には OpenBSD に見られるような、man pages が整備されていない。ちなみに glibc を提供している GNU もしかり。Stallman 氏の Linux への苦言はよく耳にするが、ユーザーへの説明責任を果たしていない GNU もどうかと思う。
この点、BSD ではソースディレクトリ中にソースと共に man ファイルが共存しており、さすがだ。カーネルと密接な関係にある標準ライブラリーを外部に依存するべきではない。Linux と glibc はお互いが利害関係だけで結ばれており、プログラマーは蚊帳の外。結果として、include, man ファイルの整備は放ったらかしだ。どうして誰も両者を厳しく追及しないのだろうか？
いじけていても仕方がないので、前向きな話もしておこう。Linux/GNU がやらないのであれば、ワシがやる！ということで、立ち上がった人達がいる。
上にも述べた通り、Linux における include/man files は鬼門である。本来開発者がやるべきことをディストリビューターや個人がサポートしているため、無法地帯と言っても良い。基本セクションに関しては、ftp://ftp.win.tue.nl/pub/linux-local/manpages/ から最新ターボールを入手可能。
2001年5月に出版された "それがぼくには楽しかったから" を遅まきながら、第９章まで読んでみた。面白い、実に面白い。
この本は「一般」の読者を対象にしたもののようだが、本来の読者対象は間違いなく「ハッカーの卵達」である。ハードウェアを直接操作した経験がない人達が読んでも、Linus 氏の真の意図は伝わらないだろう。もしくは、共著者である Diamond 氏はそのあたりも計算して、構成を練っているようにも見える。
私は本を読む時、共感した部分は耳を折る癖があるのだが、今数えてみると156ページまでで18ヵ所ある。そのうち、耳折りだけでは我慢できず、思わずオレンジのラインマーカーで印をつけたのが、６ページ。
さて、これは私の経験からのアドバイスだが、本を読む場合、漫然と読めば良いというものではない。たとえ相手が書物であっても、一対一でディスカッションしている位の緊張感で臨むべきである。貴重な人生の限られた時間を割くのであるから、なにがしかを得なければならない。
残念ながら、どんなに優れた書籍であっても、得られる情報というのはたかが知れている。数百ページの書籍であっても、大切な部分は数行にも満たないものだ。逆に言えば、読後に一言でエッセンスを表現できるか。これが、大切。
「それがぼくには楽しかったから」の読者は世界に五万といるだろうし、感じるところは人それぞれだろうが、私が前半156ページの中から抽出したエッセンスは次の一行である。
136ページに記載された、この一言が私の全身を貫いた。原文が読めないのが極めて残念だが、Linus 氏の気持ちは痛いほどに理解できる。と当時に、私が現在いくつかの連載を通じて読者に訴えようとしていることは、まさに Linus 氏がこの本で語っている経験を現在に再現することなのだと、確信を得た。Linus 氏は142ページで次のようにも述べている。
奇しくも12年前の明日だ。なんという偶然！実は、GCC プログラミング工房の第４部では Linux 0.01 を題材に用いて、連載を展開するつもりであり、まさに先週あたりから下調べを始めたところだったのである。
JUST FOR FUN、良い言葉、そして良い響きだ。私の使命は、Linus 氏の経験をより多くの人達に再体験してもらうことにある。最後に、第５章プログラミングの美しさから引用。
明日、じゃなかった今日、早速原書を注文しよう。
明けて、amazon.co.jp にて検索。なんと原書の JUST FOR FUN には、ＣＤやカセット版まであるらしい。凄いなぁ・・。一体誰の声で吹き込まれているのだろう？Linus 氏？せっかくなので、奮発してハードカバー版を注文。特に急がないので、今回は国内発注。８〜９日かかるらしい。もう少し早くならないものか。
本日の到着書籍、その１。先日、amazon.com で偶然発見した、GNU Bash のリファレンスマニュアル。昨年暮れにイギリス Netowork Theory Ltd. から発刊されたもの。かねてから、余計なことが書かれていない「薄い」Bash マニュアルが欲しかった。オライリー本はチャチャ入れすぎ＆厚すぎ。かと言って info を印刷するとかさばってしまうし・・。
この点、届いた本は理想的。サイズもコンパクトでナイスだ。定価(29.95US$)のうち１ドルは FSF にフィードバックされるらしい。元原稿はオリジナルサイトで PDF ファイルとして公開されている。地味ではあるが、こういう出版も大切だろう。願わくば、binutils/GCC 系も是非とも出版して欲しい。ちなみに amazon.co.jp を介して注文すると「通常3〜5週間以内に発送します」らしい。あのねぇ・・。
先日ふとしたことから、Schemix の存在を知った。Schemix は William Bland 氏が行っている、「Scheme interpreter の Linux kernel への組み込み」プロジェクトである。私は今のところ、Scheme どころか LISP もチンプンカンプンなのだが、このサイトのフロントページに示されている Schemix session を見て、頭がクラクラしてきた。これは危険だ、あまりにも魅惑的過ぎる・・。
Schemix に近いアプローチとしては、Forth engine を積んだ、OpenBIOS が有名である。実は、私も若き日は Riggy Forth に憧れた一人だが、いかんせん Forth は所詮 Forth。OpenBIOS のような限られた分野であれば威力も発揮するのだろうが、柔軟性・応用性に欠けることは否めない。その点、Bland 氏が示した実例はその将来性と発展性を強烈に感じさせるものがある。LISP 門外漢である私の目から見てもだ。
しかし極めつけは、氏が示した Roadmap にある。0.3.0 あたりでも十分インパクトがあるが、0.4.0, 0.5.0 と進むにつれて思わず我が目を疑う内容になっている。時間的なズレはあろうとも、もしもこの Roadmap が着実に実現されていくならば、Linux カーネルは新しいひとつの転換期を迎えることになるだろう。これは Torvalds 氏が予想もしなかった展開に違いない。
Schemix の動向に大いに期待すると共に、Schemer としての修行も今から積んでおく必要あり・・と、ちと焦る。こりゃ、当分寝られないね。
Scheme が話題に上れば、忘れちゃならないのが Gauche: A Scheme implementation だ。何と言っても、日本が誇る Hyper-lisper、川合史郎さんによる国産インタープリターである。UNIX USER 2003' 7月号の特別企画「使って遊ぶ! Gauche による Scheme スクリプトプログラミング」で、その名前を知った人も多いだろう(何を隠そう私もその一人だ＜オイ！)。
「随分文章のうまい人だなぁ・・」と思って拝見していたら、あるネット記事で、なんと Gauche の作者その人だと知る。渋い、渋すぎる。おまけに、このインタビュー記事が面白いこと。川合さんは、その後 UNIX USER 2003' 9月号で、特集「スパムメール一掃大作戦」を執筆されているが、これがまた近年まれに見る名著である。
コードが書けて、文章も書ける。こういう人には滅多にお目にかかれるものではない。川合さんをライターとして迎えた UNIX USER 編集部に心底恐れ入ると同時に、もっと氏の記事を読みたいと願うのであります。
今日は、余り知られていない binfmt_misc という Linux カーネルモジュールに関する TIPS を紹介しよう。ご存じの通り、UNIX は実行可能ファイルの先頭に位置する Magic number を識別することで、スクリプトファイルや ELF 実行ファイルの切り替えを行っている。Perl スクリプトファイルの先頭についている #!/usr/bin/perl という、アレである。この場合、#! が Magic number という訳だ。ちなみに file コマンドが識別のために利用しているのも、この Magic number である。
さて、Windows では拡張子に基づいたプログラム自動起動が行われる訳だが、UNIX では不可能なのだろうか？一々、Ruby スクリプトの先頭に #!/usr/bin/ruby という一行をエディターで挿入するよりは、test.rb というファイル名と実行属性を付けるだけで、ruby が起動する方が自然というものだ。
しかし、ご心配なく。Linux では先ほど紹介した binfmt_misc モジュールを使うことで、いとも簡単に実現することができる。まずは組み込み型式でも、モジュール型式でも良いから、CONFIG_BINFMT_MISC を有効化する。モジュールの場合は、insmod も忘れないように。
binfmt_misc の解説は Documentation/binfmt_misc.txt に記載されているが、実はここに大きなピットフォールが隠されている。Linux カーネルに含まれている、このドキュメントを読んだだけでは、binfmt_misc の機能は使えない。「なんでやねん？！」私も原因が分からずしばらく悩んだのだが、答えは binfmt_misc のホームページ に記されていた。
なんと、明示的にルートファイルシステムにマウントしなければならないのだ！こんな事はカーネルソース内の binfmt_misc.txt には一言も書かれていない。どうもカーネルメンテナの一人が、原作者の意志を無視して、ルートファイルシステムにマウントしなければ、register/status ファイルが可視化されないという仕様に変更してしまったようである。これに怒った Richard 氏は、binfmt_misc.txt の修正を行わず、そのまま放置。でも、ユーザーから質問が浴びせられるものだから、自分のホームページ上で弁明・・ということなのだろう。
全てとは言わないが、Linux カーネルというのは、一事が万事この調子だ。私はこれまでの苦い経験から、Documentation ディレクトリに置かれている文書群の内容は最初から疑ってかかるようにしている。信じることが出来るのは、ソースリストだけ。良い意味でも、悪い意味でも、このＯＳは「アマチュア」だと思う。プロとアマの違いは、コードではなくドキュメントに現れるからだ。
本題に戻ろう。以下に実例を示す(binfmt_misc.o モジュールは組み込み済み)。
23:16:21 root@mebius ~ # ls -al /proc/sys/fs/binfmt_misc/ total 0 dr-xr-xr-x 2 root root 0 Sep 19 23:16 . dr-xr-xr-x 3 root root 0 Sep 19 23:16 ..
ご覧の通り、カーネルに binfmt_misc モジュールを組み込んだだけでは、/proc/sys/fs/binfmt_misc/ ディレクトリは「空っぽ」である。ここで殆どの好奇心旺盛なユーザーは途方に暮れていることだろう。次に、アドバイス通り mount コマンドを実行する。
23:16:45 root@mebius ~ # mount -t binfmt_misc none /proc/sys/fs/binfmt_misc 23:17:26 root@mebius ~ # ls -al /proc/sys/fs/binfmt_misc/ total 0 drwxr-xr-x 1 root root 0 Sep 19 2003 . dr-xr-xr-x 3 root root 0 Sep 19 23:17 .. -r-------- 1 root root 0 Sep 19 2003 register -rw-r--r-- 1 root root 0 Sep 19 2003 status
確かに、register と status ファイルが出現した！(ずっと利用する場合は、/etc/fstab を変更しておこう)。それでは、早速 .rb ファイルを直接実行できるようにセットアップしてみる。
23:25:07 root@mebius ~ # echo ':Ruby:E::rb::/usr/bin/ruby:' > /proc/sys/fs/binfmt_misc/register
binfmt_misc の指定方法は、ホームページ上の解説を参照してほしい。上の例では、.rb 拡張子を持つ実行可能ファイルの場合は /usr/bin/ruby で起動するように指定している。
一見、何事も起こっていないようであるが、カーネルの中身は大変身しているのである。実験してみよう。
23:25:49 root@mebius ~ # cat hello.rb puts "Hello, world!" 23:26:07 root@mebius ~ # chmod +x hello.rb 23:26:13 root@mebius ~ # ./hello.rb Hello, world!
なんと、スクリプトファイルの先頭に #! /usr/bin/ruby がないにもかかわらず、実行属性をつけるだけで、ruby が起動した。素敵！この辺りは、Linux カーネルならではの楽しさと言えるだろう。
CQ 出版ホームページ曰く、「Design Wave Magazine 10月号は，お蔭様でご好評をいただき，弊社在庫分は売り切れました．お近くの書店にてお求めください」。発売前から、日本全国の FPGA 野郎達を興奮させた Cyclone FPGA 基盤付き Design Wave Magazine が完売の様子。私も２冊、買っておけば良かったかなぁ・・。
「技術の真髄を問う」のだそうである。内容は現物を見ていないので何とも言えないが、今の時期に年間契約 12000円 は、なかなか厳しいのではなかろうか？基盤もの第二弾である Design Wave Magazine 10月号が売れ切れる背景を、良く考えてみる必要があるだろう(第一弾が完売になったという話は聞いていない)。
今日から秋休み(?)。この１週間は書籍化の作業と、新サーバー上での WiLiKi ページのセットアップにいそしむことにしよう。
数多くの読者の方々から「まだか、まだか」と催促を頂き続けている GCC プログラミング工房の書籍化だが、第一部・二部に分かれた出版になりそうである。これも一重に皆様から頂いた応援の賜物であります。あと、これは表面的には見えてこないけれども、本連載誕生から現在に至るまでサポートして頂いている、渡辺・新編集長からの強力なバックアップも多大。
さて、当初は連載記事に若干手直しを加えたものを出版するつもりでいたのだが、ここしばらく真剣に全体の構成を練り直した結果、ほとんど一から書き直すことになりそう。
なぜなら、この２年間に私自身が成長しており、今の目で 2001年7月号を見直すと、全く物足りないからだ。説明が言葉足らず、進行がギクシャク、疑問点が解明されないまま進んでいる、など何ともお恥ずかしい限り。
で、この休みの間に先頭導入部を３章分ほど一気に書き下ろす予定。プロットは次の通り。
という感じだ。今回のポイントは、第二章においてオリジナルの最小実行ファイル形式を実装する点にある。UNIX USER 上での連載記事は全体を通じて ELF を前提に解説を行っているが、実は ELF は極めて複雑な体系であり、学習の導入部にはふさわしくない。かと言って a.out は中途半端。
そこで、余計な機能を極力省き、MS-DOS の .COM 型式に相当するような、最もシンプルな実行ファイル形式を新たに作成することにした。この結果、UNIX 上のプログラムの本質は一体どこにあるのかが、より鮮明になるだろう。
さらに第４章以降において、セクション構造が登場するが、連載の中では「なぜセクションが必要になったのか」が明らかになっていない。この点についても、オリジナルの実行ファイル形式に R/W section, R/O section のふたつをサポートさせることで、その理由を体得することが可能になるだろう。
このように、基本路線は同じであるものの、書籍の中身は様変わりすることになりそう。まずは、最もシンプルな実行ファイルシステムを実装することから始めよう。
Linux における実行ファイル型式関連のソースは、先日紹介した fs/binfmt_* 関連に納められており、下調べは終わっている。プログラムがプロセスに至る仕組みは、詳解 Linux カーネルでも解説されているが、残念ながらこれだけでは不十分。結局、カーネルソースを解読した上で、実際にコードを書き下ろすしか、真に理解する方法はない。
ちなみに、このあたりになると、ネット上にさえ参考になる資料は存在しない。「雑誌や書籍は役に立たない、インターネットで検索した方がよっぽどマシ」という意見をよく耳にするが、実は「本当に知りたいこと」というのは、どこにも書かれていないのだ。自分で調べるしかないのだが、ここをクリアーできるかどうかが、良質な記事を提供できるかどうかの分かれ目だと、私は思う。
JUST FOR FUN ネタ、再び。先日、「それがぼくには楽しかったから」の第２部・第９章を読み終わってから、メモを書き留めた。実は、あれから続きは読んでいない。私的には、この本のクライマックスは第２部・８章で終わっているからだ。残りのページは、タイトルを斜め読みしただけだが、興味をそそられる内容ではなかった。
JUST FOR FUN、このたった１０文字に、本書のエッセンスが凝縮されている。そして、このエッセンスは１３６ページで最高潮に達し、後は潮が引いていくような印象を持った。
「個体発生は系統発生を繰り返す」という有名な学説がある。これは、私達ヒトが胎内で成長する過程において、魚類・両生類・爬虫類・哺乳類という進化上の歴史を辿る事実を指している。
私はＯＳ学習もまた、系統発生を繰り返すのではないかと思う。Linus 氏が祖父の Commodore VIC20 に始まり、Sinclair QL、IBM PC/AT と愛機を乗り換えた末に 386 上でターミナルプログラムの作成、タスクスイッチ、HDD I/O、システムコール、POSIX kernel、シェル、のコーディングを経験し、最終的に Linux 0.01 に至った経過は、まさに「系統発生の繰り返し」そのものではないだろうか？彼ほどではないが、私自身も似たような体験をしている。JUST FOR FUN を読みながら、若かりし頃の Hacking の思い出が、話の展開に折り重なるようにフラッシュバックしたものだ。
Linus 氏の過去を知り、改めてハードウェアプログラミングの重要性を再認識した。ハードウェアプログラミングとは私の造語であるが、一般的なアプリケーションプログラミングとはことなり、CPU や周辺 I/O を直接操作することを指している(FPGA の登場により、Real-hardware-programming が現実のものになってしまったが・・)。
「車輪を二度発明するな」という言葉があるが、私の立場は全く逆であり、Linus 氏と同じ軌跡を辿ることで、初めてＯＳの理解が可能になると考えている。また、この軌跡にこそプログラミングの醍醐味、FUN の源泉が存在することを Linus 氏は私達に伝えたかったのではなかろうか？
先日 amazon.com に注文していた、Scheme 関連書籍３冊が到着した。
最初の本は SICP として世界的に有名なリファレンステキスト。その内容はまるでダイアモンドのように堅い。思わず背筋を伸ばして、正座してしまいそうだ。難攻不落の城塞のようにも見えるが、最終第５章「Computing with Register Machines」が燦然と光彩を放っている。想像するに、本書に挑戦した読者の多くが最初の１〜２章で力尽きてしまったのではなかろうか。ちなみに本書の日本語翻訳本も発売されているが、ネット上の評価によれば、その訳文は？らしい。英文自体は簡潔明瞭なので、迷わず原書を手に取るべきだろう。個人的には、魔術書を彷彿とさせるような、おどろおどろしい扉絵がお気に入り。真ん中のラムダは何やら、梵字を連想させる。
２冊目は表紙の森の写真の中に熊さんが立っていたりする、なんとも不思議な感じの書籍。が、中身はまともかつ平易だ。今回購入した３冊の中では最も敷居が低い。SICP の詳細な解説とは対照的に、ラフに流す入門書・・といった印象か。１週間もあれば十分読破できるだろう。本書の英文も素晴らしく簡明だ。日本語訳はまだないようだが、誤訳・妙訳されるぐらいであれば、翻訳されない方が幸せというものだろう。この本の特徴は１３章の Compilers and Interpreters および、１４章の Operating Systems にある(この２章を目次で見つけたから買ったのだが)。特に後者は驚くべき内容で、Scheme を用いてなんと Scheduler を記述している！すっげ〜〜〜！！！やはり、Linux カーネルと Scheme の組み合わせ(Schemix)から感じ取ったインスピレーションは本物かもね。
３冊目。これは失敗したかも・・。今のところ、心の琴線に触れるもの、ゼロだ。
ということで、この休みの読書週間の対象は Exploring Computer Science with Scheme に決定！この本を一気に読んだら、返す刀で SICP の最終章に挑戦だ。
午後、車で松山紀伊国屋に出かける。自宅から１５分ほどで、到着。駐車場も空き空き。田舎は良いです。
１階で雑誌を物色。お目当ては Software Design 10月号の第２特集「未来形ＯＳ探索隊出動！」。この企画のネーミングとイラスト、どこかで見たような・・。ひょっとして、UNIX USER 渡辺編集長の影響を受けてる？さて、その内容に目を通してみたが、ピンと来るものなし。逆にこの号に散らばったキーワードから湧いてきたイメージを、後日書き留めておくことにしよう。
UNIX MAGAZINE 10月号も思わず購入。扉最下段に書かれた「FreeBSD のブートプロセスをみる」に反応したからだ。「Linux のブートプロセスをみる」の白崎氏が再び連載を始められたようだ。そうですか、今度は BSD ですか。出来れば「Linux の実装と読み比べると面白いかもしれません」ではなく、「読み比べて」ほしいなぁ・・。
ところで、巻頭特集で始まった「自宅で使う UNIX」は、ありゃなんだ？内容はもとより、文章はブツ切れにして稚拙。読者からお金が取れるレベルに達していない記事を掲載するのは、いかがなものか。
ふと目をそらすと、派手なオレンジ色の扉絵をまとった BSD magazine vo.17 が視界に飛び込んできた。縦書きで右に「自宅サーバー実践構築法」、左に「カーネル -私の読み方-」という面白いレイアウト。素敵！
もちろん、左の垂れ幕に誘われて購入(編集部の思うツボ)。で、ざっと目を通してみたが Darwin OS で活躍している浜田直樹氏の「カーネルのまるかじり」が、最高に面白い。「How to read UNIX kernels? -- a practical approach --」とでも題して英訳すれば、これは恐らく世界一のリファンレンステキストだろう。mmap や loadable-module の origin が MULTICS にあったとは、鳥肌もんだね。この一行を読めただけでも、1886円の価値があったというものだ。惜しむらくは、５ページに終わってしまっていること。最低でも１０数ページの分量で読みたかった。浜田氏にもっと活躍の場が与えられますように。
Software Design 誌に刺激されて、以前入れ込んでいた Be File System (BeFS) が首をもたげる。一言書いておこう。
BeFS は、ハッカーにして優れたライターでもある Giampaolo 氏の作品。BeFS の詳細は Practical file system design に述べられており、本書をもとに日本人である Kato Makoto 氏が、Linux への移植を行った(ただし、Read only)。Kato氏の移植作業は途中で止まっていたが、その意志を Dyson 氏が引き継ぎ SourceForge 上で BeFS の開発が行われている。このプロジェクトも昨年春以降進んでいないようだが、Giampaolo 氏の聖典と読み比べることで理解は深まるだろう。
さきほど、とんでもない情報を見つけた。思わず、Scheme や Linux も吹っ飛んだほどの衝撃。その原因は MYCOM BOOKS から 9/29 発刊予定の「CPU の創りかた」にある。なんと TTL IC で、4ビット CPU を作り上げるらしい。
悔し〜〜〜い、完全に先を超された、完敗である。早速「立ち読み」。一抹の不安が残るが、これを最近の人達は「萌え」というのか？訳分からん・・。しかし、内容は大いに期待できそうで、早速 amazon.co.jp に予約注文。ゲッ、アマゾン売り上げランキングが既に２０位ですってよ。あ〜、到着が待ち遠しい。久しぶりにハンダの煙、吸っちゃおうかなぁ。
昨晩、Exploring Computer Science with Scheme の４章までを読んだ・・が、分かったようで分からない。平易でスムースな解説に騙されそうになるが、ハタと立ち止まってみると「全然分かっていない」ことに気づく。Ｃ言語テキストでよく見られる「変数は箱です」、と同じこと。「こんな中途半端な理解で読み進んでも意味がない」と途中で諦め、ふて寝。
翌朝「やっぱ、こいつですかぁ？」と、分厚い SICP を手に取りエイヤっと気合いを入れて読み始めたのだが(大袈裟)、「ちょっと皆さん、この本凄いっすよ」と大声で叫びたくなるほどの出来。
１時間ばかし読んだところで、子供とその友達を約束していた公園へ連れて行く。子供の城へ行くつもりが、運動公園へ。「パパ、ここ違うよ」、「いいのいいの」と無理矢理進む。頭の中は小脇に抱えた SICP の続きを読みたい一心。園内でちょうど良い椅子と机を見つけ、子供は遊園地、パパは読書。台風の影響で強い風を浴びながら、読む、ひたすら読む。盛り上がってきたところで、「もう飽きた」と子供達。
「ほんじゃ、子供の城へ行きますか」と、一路新緑に囲まれた遊び場へ。しかし、松山というのは、なぜこれほどまでに、子供のための施設が充実しているのであろうか？
今度は、日当たりの良いテラスに設けられた椅子で読書。考えてみたら、子供の城で SICP を読むオジサンというのも、ちと危ないよねぇ。でも、面白いのだ。ひたすら集中して、子供達が帰ってくる頃にちょうど第１章を読み終わる。なんだか、回りの景色が昨日とは変わって見える。新しいプログラミング人生の始まりだろうか？詳細は、後日。
あなたが、これから Scheme を学ぶのであれば手にすべきは Structure and Interpretation of Computer Programs だ。他の書籍は必要なし。邦訳本を買うなど、言語道断。細心の注意で書き下ろされた、奇跡のように明快な解説を、一言一言深く味わいながら読みこもう。
SICP の続編・・と行きたいところだが、余りにも書きたいことが多すぎるため、日を改めて挑戦することとしよう。が、その前に一言。
SICP はテクニカルライターにとっての聖典でもある。用意周到に選ばれた言葉の巧みさ・正確さ・分かりやすい表現は、比類ないものだ。日本の中学生英語のレベルでここまで完璧な英文を書き上げた著者達の力量には感服させられる。本当に優れた文章というのは、誰が読んでも平易であることを示す、最高のお手本と言えるだろう。
しかし、気を付けるべきは、あまりに流麗な文章であるため、時として重要なキーワードを見逃してしまう点にある。SICP の著者達は、膨大な手間暇をかけてひとつひとつの言葉を壮大なストーリーの中にはめ込んでいる。決して、さらさらと書き流したものではないことを肝に銘じながら熟読しよう。
そして、もうひとつ大切なことは、このテキストが英語で書かれているという事実である。残念ながら、言語の違いはいかんともし難い。Scheme で書かれたプログラムをＣ言語で書き直すことは出来ないように・・。著者達が愛情を込めて拾い上げ、名付けた言葉達は英語である。言葉には意味だけでなく、リズムや音韻が備わっている。もちろん、文法が影響するところも大きい。
このような状況下において、私達の母国語である日本語は、Computer Science を記述するには、あまりにもハンディキャップが大きいように私は感じる。
さて表題の件だが、日本で出版される翻訳書のレベルは総じて低い。他言語の翻訳書を読んだ経験はないが、おそらく世界的にも見ても地を這うほど低いレベルにあると思われる。なぜか？
答えは簡単だ。真に実力を持った作家であれば、他人様が書いた文章の翻訳に貴重な時間を割くよりも、自分オリジナルの著作に挑戦したいだろう。結果として、自らの発想で新たな本を書き下ろす力はないが、自身の経験に基づき翻訳は可能な人達が、担当することになる。この時、原著者と双璧の実力を持った人が担当すれば、適切な訳注も備わった素晴らしい翻訳書が誕生するが、ほとんどの場合は、さにあらず。訳文が日本語にすらなっていない本が、いかに多いことか。
最近はページ数の多い出版物が増えており、単独では到底翻訳しきれないことも問題を助長している。監訳本の類がそうであるが、その現状たるや目を覆うばかりである。これは、翻訳の遙か以前、その人の国語力の問題だ。そして、この国語力をきちんと指導できる人達が絶望的なまでに不足しているのが、今の日本の現状である。
それではどうするか？簡単である。これからの技術者や学生は、みんな英語の原書を読めば良い。実際、アジアの技術者達は皆、英語で情報を入手している。日本の技術者だけが、大きな口を開けて親鳥が翻訳書を運んでくれることを待ち続けているのである。しかも、その親鳥が運ぶ餌ときたら・・・。なんという悲劇だろうか。
実際、高いお金を出して買った誤訳・珍訳本が理解できず、「こんな有名な本が理解できない俺って、なんてアホなの・・」と、心に深い傷を追った読者は数知れないことだろう(私もその一人)。今の日本のマスコミに、「この翻訳は最低です、読んではいけない！」と警鐘を鳴らす勇気ある書評は存在しないのだから、無理もない。
インターネットの普及は都会と田舎の格差を打破しつつある。実際、私は四国にいながらにして、世界中のライター達と対等に渡り合うことができる。東京に身を置く必要など微塵も感じない。私にとって最も大切な情報源であるソースリストはネットワークを通じて瞬時に手に入れることができるし、必要なリファレンスや絶版書は amazon.com から購入できる。そして、日々の連載執筆のために使用している情報源のほとんどは、ソースも含め海外である。恐らく、中国やインドの技術者達も同様だろう。
本屋で翻訳書を手に取るのは楽だ、簡単だ。しかし、その安易さの代償として、若い人達が失うものはとてつもなく大きい。そして、この積み重ねが、日本の産業に将来どのような影を落とすのか。悩みは尽きない。
昨日「翻訳書を手に取るなかれ」と書いたが、これだけでは読者の方々に不親切というものだろう。実は、英文の原書やテキストを手にするにあたり、もう一点注意しなければならないことがある。それは、目的の文献が「Comfortable English」で書かれているか、否かということだ。
Comfortable English については、昨年旧サイトでショートエッセーを公開しているが、再度今の私の言葉で書き直してみよう。
コンピューター英語をきっかけとした私の英文との付き合いはすでに２０年を超えるが、十数年以上経過してようやく分かってきたことがある。それは「アメリカ人と言えども、全員が良質な英文を書ける訳ではない」という事実だ。考えてみれば、 私達日本人が書く文章にも雲泥の差がある訳だから、欧米においても同様であろうと類推できる。しかし、悲しいことに多くの人達はこの事実に気づいていないし、声高にその重要性を叫ぶ人もいない。
私自身、当初この知識を持っていなかったために、随分余計な回り道をしてきた経験がある。結果として、膨大な時間とお金を無駄に費やしてしまった。あの頃、私に適切な指導を身近で与えてくれる教官がいれば、私の人生は変わっていたかもしれない。いや、確実に変わっていただろう。以下、私が長い間にわたる放浪の果てに到達した結論を記しておく。
今の時代、技術英語が読めるかどうかは技術者にとって死活問題である。オンラインで出回っている膨大なページの中から、自分が真に必要としている文書を選び出し、そのエッセンスを抽出。自分なりに情報を消化し、生きた知識として大脳に固定化する。
この一連の作業の中で最も重要になるポイントはなんであろうか？そう、一にも二にも「優れた技術文書」を情報源として選ぶことだ。言葉は悪いが、決して「カス」を選んではならない。インターネットの普及や出版物の増大により、一昔前に比べるとリソースは膨大な数に膨らみつつある。まさに玉石混淆の状態だが、困ったことに「玉」を見つけ出すことは、砂金探しと同じぐらい骨が折れる作業になってしまった。このため、現代の技術者には最小限の苦労で「玉」を探し出すことができる、犬並みの(?)優れた嗅覚が求められているのである。
優れた英文技術書の条件とは、情報が正確に誤りなく書かれていることはもちろんだが、英文として読みやすいものかどうか、「Comfortable English」であるかどうかが、最も重要な因子となる。日本語に訳すと「気持ちの良い英文」という意味になるが、この表現の背景には「学歴のあるアメリカ人は論点を簡潔かつ明快に表現することを comfortable と感じる」という事実がある。
ここで「学歴のある」という限定語が付加されている点に注目してほしい。残念ながら、日本では「学歴」という言葉に対して Negative なイメージを持つ人が多い。「人前でそんな言葉をむやみに使ってはいけません」というところか。これは裏を返せば、日本人の多くは、学歴を社会の中でステップアップしていくための「最終目的」としてしか捉えていないことを意味している。つまり、学歴が持つ教育的意義を完全に見失っているのだ(受験生も親も学生も教官までも)。
面白いことに日本で高学歴と言えば「○○大学卒業」を意味しているが、欧米では学位取得者(Ph.D.; Doctor of philosophy)を指す。学歴社会と言われる日本だが、蓋を開けてみると一流企業と言えども採用しているのは大卒がほとんど。一方、欧米企業は多くの博士号所有者を雇用しており、「日本企業の低学歴現象」を指摘する経済学者もいるほどである。それではなぜ欧米の企業は高い給料を払ってまで、Ph.D. を採用するのだろうか？
これは私の憶測だが、欧米企業の評価のひとつには、本人が Ph.D. を取得する過程で徹底した writing/public speech/presentation のトレーニングを受けている点を重要視しているのではないだろうか？分かりやすく言えば、自分の考えを簡潔かつ明快に表現できる能力だ。実際、欧米の著名経済人達は「あなたがこれまで受けた来た教育の中で、最も役立っているものは何ですか？」という問いに対して、異口同音に「それはプレゼンテーション能力だ」と答えている。
私のつたない経験からしても、このようなトレーニングを存分に受けることができるのは、大学院しかない。大学院で徹底したスパルタ教育を受けたアメリカ人の学術論文は、本当に素晴らしい。もちろん全てとは言わないが、たまに読んでいて思わず溜め息がもれるような「Comfortable English の名作」に出会うことがある。Comfortable English とは単純に文章の出来だけを指している訳ではない。論文の構成、論理の明確さと正しさ、話の展開、起承転結、これらすべてが水が流れるごとく自然に読者に受け入れられる文書のことを表現しているのだ。このために、アメリカの一流研究者は推敲に推敲を重ねると聞く。「学歴のあるアメリカ人」は高学歴を裏付けるだけのトレーニングと技術、そして絶え間ない努力の上に成り立っていると言えるだろう。
こういう背景を踏まえながら、コンピューター英語の世界を観察すると、首をかしげざるを得ないような状況に多々出会う。この傾向は特にオープンソース界で激しく、中でも Linux 関連文書は最大の問題児だ。例えば Linux について情報を求める人達は、まず最初に Linux Documentation Project (LDP) の HOWTO 集を手に入れることだろう。Linux カーネルソースツリー内部の Documentation ディレクトリに納められた文書も参考にするだろう。しかし、私の目から見ると、この中の大多数の文書は非常に読みづらく、著者が何を言いたいのかが分からない。
難解な文書の著者の多くは、おそらく学術論文を書いた経験がない、もしくは writing に関するトレーニングをほとんど受けていないのではないだろうか？我流のスタイルで書き下ろしているために、結果として英文に無駄が多く論旨も不明瞭になっている。問題はこのような未熟な文書群が、野放しになっているどころか、次から次へと増殖している点である。悪いことに、日本ではさらに「和訳」というフィルターがかかる。ボランティアーによる作業であるから、誰も責任を問う訳でもなく、酷評もしないのだろうが、若い人達への影響を考えると事態は深刻である。
よって、日本で後輩を指導する立場にある人達は、まずは「良書のリスト」を示してあげなければならない。英文読解力が未熟なうちは、英文の善し悪しが判断できないからだ。「この英文の意味が分からないのは自分の英語力が未熟なせいだ、後でもう１回読み直そう、トホホ・・」と、悪文相手に苦労している技術者はかなりの数に上ることだろう。私自身、どれだけ無駄な時間を費やしたことか。
美術、音楽そして料理と同じく、自分の中に「文章のリファレンス」を持つことが大切である。そのためには、SICP のような高度に洗練された本物の書物達を、数多く読み込まなければならない。そして、それ以上に大切なことは、日本語英語に関わらず「駄文を回避する」ことである。失われた貴重な時間は、二度と戻って来ないのだから。
本日、amazon.co.jp より、先週注文した JUST FOR FUN のハードカバー版が到着した。まず表紙に彩られた、オレンジ色の蛍光ラインマーカーに目が眩む。「こりゃまた随分派手な表紙だねー、目が痛いよ」。で、ふと見ると LINUS TORVALDS の名前の横に添えられた言葉が目に止まる。そこには「CREATOR OF LINUX」とある。ちなみに先日紹介した翻訳本では「Linux 開発者」だ。「何これ、全然意味違うじゃん・・」
第２部において、Torvalds 氏は繰り返し、プログラマーの誰もがコンピューター上で創造主になり得ることの素晴らしさ、その楽しさを説いている。 CREATOR の文字は、恐らく本文の内容を踏まえてのことだろうが、残念なことに和訳本ではその雰囲気は全く伝わってこない。
次に驚かされたのは、原書のレイアウトである。和訳本では、表紙(カバーの下)にペンギンの集団がカラーで登場する以外は、至って単調な装丁になっている。原書でも同じく表紙にはペンギンが登場するが、こちらは表情豊かな Torvalds 氏の笑顔とペンギンが交互に登場している点がことなる。本文で Diamond 氏が語っている通り、Linux が成功した背景には私利私欲を超越した Torvalds 氏の人柄が強く影響していることは間違いない。表紙に並んだ氏の笑顔は、読者にその事実を納得させるだけの力を持っていると言える。これに対して、和訳本の表紙は単なる「おちゃらけ」。思わず小学館のセンスを疑ってしまう・・。
いや、表紙はどうでもいいのだ。もっと大切なことがある。原書のページをめくると、タイトルページが２ページに渡っている。左のページは真っ黒なページの上に Just の文字。右の白いページの上に for FUN、そして著者の名前が記されている。黒と白の対比が非常に美しく、印象的なのだが、この漆黒のページは以降４回登場する。最初は第１部の幕開け「Birth of a NERD」、次は第２部の冒頭「Birth of an OPERATING SYSTEM」、そして第３部の冒頭「King of the BALL」
「あれ、後一回足りないじゃん？」そう、実は残りの黒ページは第２部第５章の冒頭で登場する。黒をバックにして、友人の Vierumaki 氏の言葉、そして Torvalds 氏の妹である Sara からのメッセージが白インクで綴られている(美しく印象的なページだ)。以下、原書７２ページより一部抜粋。
... Linus turned back to his computer and pressed some function key combination -- another login screen appeared. A new login and a new command prompt. Linus showed me four individual command prompts and explained that later they could be accessed by four separate users. That was the moment I knew Linus had created something wonderful. ...
Vierumaki 氏が Torvalds 氏のオタク部屋に招待されたのは、丁度 Linux 0.01 がほぼ出来上がった頃なのだろう。最初は DOS に毛が生えた程度と思われたものが、実は４つの仮想コンソールを切り替えることが可能なマルチタスクＯＳであることを知った時の心情を語ったものである。私はこのコメントを読んだ時、まるで自分がその場に居合わせたかのような錯覚を覚えた。Diamond 氏の手腕、恐るべしだ。
For me, it meant mainly that the phone lines were constantly busy and nobody could call us... At some point, postcards began arriving from different corners of the globe. I suppose that's when I realized pepople in the real world were actually using what he had created.
サラの優しさと暖かい理解に溢れた素敵な文章である。もっとも最近の人達は「lines were constantly busy」と聞いても、一体これが何を意味しているのか、理解できないだろうが。ちなみに、どちらのメッセージにも create の言葉が使われている点に注目してほしい。原書の CREATOR OF LINUX という肩書きに、特別な思いが込められていることは、明らかである。DEVELOPER にはあらず、だ。
残念ながら、この二人のメッセージは和訳本では、特に区別されることもなく、回りの文章と同じトーンで印刷されている。もはや、日本の読者達は、このメッセージに託された深い意味を知る由もないのである。
さて、この２つの印象的なメッセージを左ページに置いて、第２部第５章はスタートする。逆に言えば、原作者達は Chapter V: The Beauty of Programming 以降を、この本の中でも特別な章として捉えていることが分かる。その証拠に、第５章の出だしを見てみよう。
I don't know how to really explain my fascination with programming, but I'll try.
何と、あの寡黙な Torvalds 氏が、語り始めているのである。曰く、
The operating system is the basis for everything else that will happen in the machine. And creating one is the ultimate challenge.
この他にも興味深い言葉が並んでいるので、是非本物を読んでみてほしい。続く第６章では、ターミナルエミュレーター(昔懐かしい、モデムを介した通信プログラム。ちなみにかっての私の専門領域？)を改良していく過程が、手に汗握るような(少なくとも私にとっては)筆致で書かれている。再び曰く、
The next moment I realize it's accumulating so many functions that it has metamorphosed into a new operating system in the works.
来た来た、来ましたよ〜〜お兄さん。こうして、第７章のクライマックス、「Let There Be Light」に続くのである。
それにしても、日本語であろうと、英語であろうと、何度読んでもワクワクさせられる。良く練られた原書の場合はなおさらだ。これから先、もしもコーディングや連載で行き詰まった場合は、本書を手にして奮い立たせてもらうことにしよう。そして願わくば、この日本においても JUST FOR FUN を体験し、理解し、そしてお互いに共有できる人達が輩出せんことを。
蛇足ながら、日本のマスコミはこの書を「オープンソース本」として捉えているようだが、今回原書を手にして、著者達の意図はそれとはことなることを確信した。本書は世界的ハッカーの自叙伝であり、極めて素直な心の発露が語られている。そして、第２部に込められた彼の思いを理解できるのは、ハッカーをおいて他にはいないだろう。
Torvalds 氏にとっての FUN とは、マシンいじりであり、coding であり、OS の構築である。そして、Linux-0.01 が誕生した原動力は、純粋な好奇心以外の何物でもない。これが FUN の前に "JUST FOR" が冠されている理由だと、私は思う。
今日は最後の休日。嫁さんと待ち合わせて、久しぶりに「踊るうどん」を訪れた。数えてみると、１０ヵ月ぶりぐらい、いやほとんど１年近い。昨年は毎週のように出かけていたのだが、免停というとっても悲しい事件をきっかけにして、足が遠のいていたのである(うらめしや、高知のオービス)。
昔は知る人ぞ知るお店だったのだが、今では松山一有名なうどん屋さんになってしまった。そう、一ファンとしては「しまった」という表現が正しい。なぜなら、昼過ぎには玉切れ状態となり、それでなくとも短い営業時間(10:30AM~2:30PM)が、さらに短縮されてしまうからである。
今日はそこを見越して、11:30AMにはお店に到着。まだ、店内は半分くらいのお客さん。みんな醤油うどんが運ばれてくるまでの間、黙々と大根をシュッシュッとすりおろしているところが、何やら宗教的儀式のようで面白い。独特の静寂感が漂う、不思議なお店である。
さて、私は醤油うどんの中盛り(もちろん５０円増しでスダチ付き、ちなみにデフォルトの薬味は檸檬である。そうそう、大根も当然デフォルトである)、嫁さんは「ひやあつ」を注文。ひやあつの意味が分からない人は、メニューを参照のこと。うどん全般については、讃岐うどんの聖典「恐るべきさぬきうどんシリーズ」を参照されると良いだろう。
このお店はうどんもさることながら、ダシが抜群にうまい。以前、店主の永木さんに「是非このダシだけをメニュー化してちょうだい」と懇願したことがあるのだが、残念ながら実現はされなかった。今時珍しい「うるめ」を贅沢に使った踊るうどんのダシは、この世のものとも思えない旨味を備えている。関東からやって来たお客さんは、このダシを飲んで「何これ、味がしないじゃない」と宣うそうだが、私が店主だったら「あんたら醤油に毒されすぎ、この天然の魚の旨味が分からんのかね！」と小一時間問いつめたい。
冗談はさておき、松山在住の方々は、是非一度同店の「うどん講習会」に参加されると良いだろう。私も娘と一緒に、始めの頃の講習会に参加したことがあるが、この場で出される出来たての「うるめだし」ときたら、口に含むだけで天にも昇る代物である。醤油も何も使っていないのに、このダシはため息が出るほど美しい黄金色を呈している。「最後の晩餐」というコーナーがあるが、私が死にゆく前に最後に口にしたいのは、きっと永木さんのうるめダシだろう。この店に来るたびに思うのだが、ガンの末期の患者さんに、このうるめダシをふるまうことが出来れば、どれだけ多くの人達が喜び、救われることかと。病院で出される流動食というのは、それはそれはひどいものなのだ・・。
ということで、西田家はこのお店を訪れた時は、必ず分担して、醤油うどん、ひやひや、釜玉を注文し、めんとダシを確保するのである。特に、たっぷりの冷えたうるめだしに浮かんだ、うどん(口に含めばまさにぶるぶると踊る、そして心が躍るのだ)は、絶品である。
ただし、このお店には致命的な欠点がある。それは、「ほとんど閉まっている」こと。日曜・月曜日は休み、営業日もピンポイントで出撃しなければ、玉切れの憂き目にあってしまう。また、メジャーになればなるほど、休店日が増えているように見えるのは、私の思い過ごしだろうか？事実、店内には１０月の２週間にわたる長期休暇が宣言されていた。聞いてみると「知り合いのお坊さんと一緒に、ミャンマーへ修行に行ってくる」のだそうである。COOOOOOL だ。
で、何が言いたいのかという言うと、永木さんもまた、Torvalds 氏と同じく JUST FOR FUN を体現した人なのだ。むしろ、踊るうどんは、Linux の一歩先を行っているのかもしれない。永木さんは人生を楽しみながらおいしいうどんを打つ。営業時間と休みの多さから分かる通り、同氏は Torvalds 氏と同じく、私利私欲を超越した人だ。お客さんは、彼の打ったうどんとダシに、舌鼓を慣らし、お腹に幸せな感触を残しながら、ありがとうの一言と共に店を後にする。
素晴らしきかな、JUST FOR UDON。
さて、私もうどんとうるめの力を借りて、書籍の原稿を仕上げてしまおう。
今日は、久しぶりの出勤。先週まで、たわわに実り頭を垂れていた稲穂達が、いない。どこにもいない・・。日頃、「いやぁ、今日も緑がきれいやねぇ」とか、「ほほぅ、お日さまの光一杯浴びて、色っぽい黄色になってきましたなぁ・・」などと、完璧に感情移入していたものだから、なんだか寂しい。仲の良い友達が転校してしまった気分である。
農家の皆さんは、私が家でゴロゴロしている間に、稲刈りに励んでおられたらしい、ご苦労様です。新米は、さぞかしおいしいことだろう。考えてみれば、毎日出勤途中に田んぼの真ん中を走りながら、季節感を満喫できるというのも、贅沢な話だ。
休みの間に新たなるプロジェクトを思いつく。名付けて、Let There Be Light、すなわち「光あれ」プロジェクト。Torvalds 氏が辿った軌跡を、連載を通じて再現しようというものだ。世の中に Linux カーネルの解説は多いが、読後に「光」を見た読者は、ほとんどいないだろう。それもそのはず、Torvalds 氏が体験した感覚を、自らの手・目・心で感じるためには、彼と同程度の深いハードウェア知識が必要になるからである。また、Linux-0.01 を再現するためには、併せて GNU 開発ツールを使いこなせるだけの力量も求められる。
両者を独学で学ぶことは極めて難しいが、幸い GCC プログラミング工房を通じて、後者の問題はほぼ解決しつつある。残された課題は、PC/AT の周辺 I/O そして i386 プロテクトモードを「しゃぶり尽くせるかどうか」にかかっていると言えるが、これは現在の第３部を通じて、一つずつ解決できるだろう。実際、キーボード回りと VGA に関しては、これまでの連載の内容で十分 Linux-0.01 相当のキーボードドライバー、コンソールドライバーを作成することは可能だ(割り込み処理の解説が残っているが)。さらに、１１月号、１２月号では、本格的な VGA register programming の解説にまで及ぶので、この時点で１０年前の Torvalds 氏を読者の皆さんは追い抜いてしまうことになる。2004年の始めには、いよいよ RS-232C (正確には 8050 互換チップの制御)プログラミングが登場し、Torvalds 氏が最初に取り組んだターミナルエミュレーターの自作に挑む。という調子で行くと、来年の今頃には「光あれ」の境地まで達することができるのか？達したい、いや達するのだ！
まずは下準備として、Linux-0.01 の Bootstrap loader およびプロテクトモード移行部分までをフルスクラッチで書き直す作業から始めよう。Linux, *BSD にかかわらず、システム起動部分のコーディング技術は稚拙である。なぜなら、開発ツールの潜在能力を十二分に発揮できていないからだ。特に .code16gcc を使いこなせていないのは痛い。.code16gcc を使えば、可読性の低いアセンブリソースは、ブートセクターのごく一部だけで済むはずなのだ。個人的には、１ページ以上のアセンブリソースは御免被りたい。年を取ると、解読のための集中力が続かないのである。文章もソースも、単純明快が一番。
先日、紀伊国屋で面白い本を見つけた。深沢千尋氏の「文字コード超研究」という分厚い本だ。６００ページ以上にもおよぶ力作であるにもかかわらず、値段は２９８０円と内容の割には安い。恐らく、財布の中身に秋風が吹いている学生さんや、新入社員の人達に配慮した値段設定なのだろう。初版は今年の８月２日であるから、まだ出版されて間もないようだ。
で、私はそのタイトルから文字コードに関する集大成本を想像して、手に取ったのだが、内容はさにあらず。なんと、「文字コードをお題にしたプログラミング解説本」だったのだ！くぅ〜〜〜〜、また負けた。完璧に先を越された。実は、私は以前から「文字コードというのは、初心者のプログラミングテーマとして最高じゃん」と考えていた。いつか機会があれば、書いてみたいものだと思っていたところに、この本に遭遇してしまった訳だ。
でも、いいのである。この本の出来は大層良い。まえがきに書かれている、本書の４つの基本理念「原理主義、実験主義、Perl 主義、実際主義」というのが、いい。内容も正確であり、良く調べ上げられている。そして、何より文体がいい、楽しい、幸せになれるかも。
細かいところは、また時間がある時に拝読させて頂くとして、私が購入を決めたのは２５３ページの図を見たから。そこには、「KAIJUU ARAWARU (怪獣現る)」という打電文が、紙テープとして出力されている様子が分かりやすい絵で示されている。スプロケット穴、偶数パリティ、0x7F (DEL) の意味。白状すると、私は本屋でこの絵を立ち読みしたとき、不覚にも目頭を熱くしてしまいました。そのまま足早にカウンターに立ち寄ったことは、言うまでもありません。
分野を問わず「原理」というのは大切である。原理主義者、深沢氏の次回作に大いに期待しております。
本日とあるコーナーを歩いていると「GPS MANIAXX」という怪しげなタイトルの本を発見。サブタイトルに「パソコン/PDA ユーザーのための・・」とさらに危ない誘い文句が添えられている。この発行人、分かっとるなぁ・・と思いつつ、手に取る。パラパラと５章までをめくる。どうっちゅうことはないのぅ。が、６章まで来て目が点になる。
GPS コンシューマーガイドと名打たれたこの章は、世界中のハンディ GPS レシーバーのカタログとなっていたのである。ここで初めて、GARMIN 社の eTrex シリーズなるものを知る。
ほほぅ〜〜、安いのは２万円から手に入るですか。なんと、入出力信号は RS-232C と来ましたか、マジっすかぁ？！こりゃターミナルエミュレーターが動いたら、そのまま GPS reader の出来上がりじゃないですか！
もう少しページを進めると、次は「GPS コア」という、とってもとっても危ないページが登場する。
ゲゲッ、こいつは先日勉強した 1PPS (UTC に同期した１秒パルス)も出力できるんすか？！思わずその場で、1pps と名付けたデーモンをコーディングしている自分の姿を夢想するのであった。
本書が今手元にはあるのは、言うまでもない。で、早速調べてみた。最安値帯でシンプルなトカゲ印の Geko 201がよさげだが、なんと amazon.com で扱っているんですな、これが。価格は、約１２０ドル。いんや、ちょっと待て。日本でも、１７７００円だよ、お兄さん。為替と送料を考えると、日本かしらん。でも、３０１も魅力的よねぇ。
まぁ、しかしだ。問題は、入出力データフォーマットが公開されているかどうかだな。これがなけりゃ、ただの物欲箱と化すだけだ。
と、かろうじて理性を保ちながら、GRAMIN 社のサイトを探す。応答が遅いが、簡単にブツが見つかってしまった。やるな、GARMIN、ここまでは合格じゃ。どの程度のドキュメントが書けるのか、おじさんがチェックしてやろう、どれどれ。
まず最初に simple text output を見る。あかん、頭クラクラしてきた。タイムスタンプは UTC format と来たよ。ダメだ、やられた。
いや、まだ生ぬるい。これはただの「出力」フォーマットだよ。問題はホスト側との communication protocol がきちんと公開されているかどうかだ。と、ほとんど死にかけの理性の声に促されて、Garmin Communication Protocol をチェック。
正直予想はしていた。タイトルを見た時点で、私の秘孔は突かれていたのだ・・。
GARMIN 社、恐るべし。もちろん、このようなケースが全てとは言わないが、欧米の優れた会社は、まず間違いなくドキュメントも一流だ。これに反して、日本は商品は一流であっても、ドキュメントは最悪のケースが多い、いやほとんどだろうか。具体例はいつかご紹介しよう。
とか良い子ぶって、GPS core どうすんのよ！＞我
明けて日曜日。昨日の深夜は、なにか頭の中で衛星がグルグル回っていたような気がする。そのためか、起床後 GARMIN 社を訪ねる。
と、いきなりトップページに Forerunner 201 という怪しいタイトルを発見。歳とっても、なぜかこういう嗅覚だけは落ちていくどころか、益々磨かれていくから不思議・・。
で、まるで誘蛾灯に誘われるがごとく "Enlarge image" ボタンを押す。泣く。カッコよすぎるっすよ。黒ベルトに GARMIN ロゴ、渋いなぁ。おまけにこの大きさで、１２衛星のトラッキングOKなんすか？２年分の移動(トレーニング)データを記憶可能ですか(ホンマ？)。値段は１６０ドル、ポッキリっすか？
無意識のうちに "Add to cart" ボタンを探している自分が怖いが、幸いなことにこの商品の出荷は１１月予定らしい。危ない、危ない。
「発売予定ですか、そうですか」と引き下がるほど素直な性格にはあらず。念のために、入手先をチェックしておく。で、とんでもないお店を発見。
GPS オタクは、GPSCity.com を前にして「みな、たなごころを合はせて随喜の涙をもよほしける」 ことだろう。全く鬼のような品揃えである。OEM Sensor GPS というコーナーまで用意されている。値段も、予想していた価格帯よりも遙かに安い。GPS が、ここまで普及していたことに驚く。考えてみれば、コギャル(古い)もみんな GPS 携帯を持っている時代だ。単なる私の勉強不足ということだろう。
しかし、一点だけオヤッと思ったことがある。それは Manuals というコーナーだ。このページには、驚いたことに GARMIN 社 GPS 製品の印刷マニュアルがズラリと並んでいる。
当然のことながら、商品には印刷マニュアルが添付されているようだ。さらには、GARMIN 社のホームページではマニュアルのＰＤＦも無料で公開されている。それでもなお、ユーザーのために印刷物も販売している同社の姿勢は大したものである。気に入った。私は、この事実と先日のプロトコル仕様書を見ただけで、すっかり GARMIN 社のファンになってしまった。
しかしだ。翻って我が日本を見るにつけ、悲しくなってしまう。GPS について調べていると、日本では SONY が "GPS エンターテインメント" と銘打ち、HGR3 というハンディー GPS を売り出したらしい。そのコンパクトさは４０ｇという驚くべきものだが、現在は品切れのようである。ホームページを見ても、昔の勢いはなく「アップグレードエリアの運営は終了いたしました」というメッセージが寂しく残されている。まぁ、撤退は良いのだが、問題は SONY と GARMIN 社のドキュメントに対する姿勢の違いである。両者の間に存在する、天と地ほどの落差は、一体何を意味しているのだろうか？
週末の google。一見、何気ない物欲回遊の旅のようにも見えるが、得られるもの、見えてくるものは意外と大きく、深い。
ついでにもうひとつ、超弩級の GPS サイトを紹介しておこう。中澤和夫氏のホームページだが、凄い。私はこのサイトを訪れた時、思わず言葉を失った。「日本にもこんな凄い人がおったんか・・」
GPS、国土地理院、空間データ、GARMIN communication protocol。フレーズのひとつひとつが、頭の中でこだまする。プログラマー魂がうずくなぁ。どうしよう＜何を？
しかし、このサイトである意味一番面白いのは、トップページにある "参照状況" ですな。毎月のトップ１０には日本の大企業がアクセス元として名を連ねている。私が上司なら、間違いなく「お前らプロだろう。プロなら、自力で調べんかい！」と一喝しているところだ。
ところで、このサイトに張られていたリンクを訪ねると、「愛媛県松山市を例にとって説明しましょう」という展開になってきて、ビックリ。なんと、著者である小林さんは愛媛大学の方らしい。灯台もと暗しだねぇ。今度、インタビューに行ってみようかしらん。日頃、病院・大学という閉ざされた環境で暮らしているため、私は分野が違う人と会うことが、ことのほか好きなのだ。
昨日の「GPS MANIAXX」に引き続き、「図解雑学 GPS のしくみ」を読む。１〜２時間でスラスラ読めるほど、分かりやすい。なるほど、概略は分かった。いや、正確には分かったような「気がする」と言うべきか。
しかし、私が知りたいのは、衛星から送られてくる航法メッセージと、C/A データを用いて、NAVSTAR 衛星の原始時計とホスト環境とを、可能な限り正確に同期させるための方法なのだ。
秒速３０万kmでやってくる電波が相手ともなると、1ミリ秒の誤差は実に３００kmの誤差を生む、1マイクロ秒であっても３００ｍの誤差である。５０ナノ秒の誤差でようやく１５ｍまで収束する訳だから、GPS 内部での時間管理がいかに厳密なものであるかが良く分かる。
これに対して、有名な NTP (Network Time Protocol)が想定している時刻同期精度は何と１ミリ秒以内である。桁違いというレベルではなく、４〜５桁もの差が存在することになる。もちろん、NTP サーバー自身は原子時計や GPS 機能を用いることで、マイクロ秒以下の精度を有しているのだが、ネットワークを経由することで、精度がガタ落ちになってしまうのである。
幸い、ミリ秒オーダーの誤差は、ほとんどの UNIX サーバーにとって支障を生じる事態には至っていないが、中には「こんな好い加減な代物、到底使えんぞ！」という現場も存在するだろう。
で、調べてみた。するとあった。それも我が日本で。筑波(KEK)におけるビーム射出時間と、２５０km 離れたスーパーカミオカンデでの計測時間を同期させるため、GPS が使われているのである。詳細は KEK GPS Clock System に詳しい。
こうなってくると、昨日の情報検索がいかに甘ちゃんであったかが、良く分かる。「表層」しか見ていなかったのだ。これでは、GPS 携帯を手にして喜んでいるコギャル達とちっとも変わらんな・・。猛省することしきり。
で、再び本気で検索しまくる。今度はさすがに手強く、なかなか思うような情報源にヒットしない。目指すは、NAVSTAR 衛星から送られてくる「生データ」をもとに、「自力」で位置・時刻を計算すること、そのために必要な minimum なハードウェア環境は何なのかを突き止めること。おそらく「GPS プロセッサをバイパスして」、生データをリアルタイムでホスト CPU に伝達する方法が、一番のポイントになるだろう。しかも、予算は２００ドル前後で実現できなくてはならない。読者が追試できるためには、この辺りの金額が限界だから。
当然のことながら、日本では見つからなかった。が、ついに私と同じことを考え、既に教育現場で実践している人を発見！場所は、当然アメリカである。これはいつも感心させられるのだが、アメリカ人というのは、本気で学生のことを考える。教材の値段は必ず１００ドル前後、高くても２００ドル以内だ。なぜこんなことが可能なのか？
アメリカでは企業が Educational kit を１００ドル前後で提供する風土がある。アメリカの将来を担う学生達が、最小限の負担で、優秀な教材を使った学習を行うことができるよう、国全体でバックアップしていることになる。しかも、その教材は極めて優れたものが多い。
これはまた機会を改めて紹介する予定だが、アメリカで販売されている 有名な FPGA 学習キットは、日本の会社が販売しているものなど、到底勝負にならないほどの出来である。値段は１００数十ドル。
日本では、この手の評価キットは５〜７万円もする。しかも、内容は貧弱。使えない。ドキュメントがなっていない。「何とかならんのか」と、いつも思うが、基本的にこの状況は私が初めてパソコンに触った２０数年前と何ら変わっていないような気がする。
さて、問題の「手作り GPS」のサイトであるが、その名は「OpenSourceGPS」。副題は "A starting point for learning about GPS with Open Source Software" となっている。これぞまさしく私が求めていた情報だ。根性入れて探してみるものである。
ただ、オリジナルは ISA バス対応といささか古いので、OpenGPSRec で公開されている、PCI バス対応バージョンの方が良いだろう。こちらは、Realtime Linux kernel にも対応している。ちなみに、このプロジェクトで使われているドイツ製の PCI 評価ボードは秀逸だ。こいつを何としてでも手に入れたいなぁ・・。それと、同ボードの紹介記事が掲載されていた Elektor という雑誌も、おいでおいでをしているよなぁ。困った。
で、心臓部の Superstar ボードが欲しくなったら Navtech へどうぞ(タイトルに添えられた GPS education という文字に注目！)。昨日紹介した GPSCity.com は素人さんのお店、こちらは玄人指向である。上には上がいるものだ。井の中の蛙ではダメだね。
以上で、GPS と時刻をテーマにした場合の素材選びは、ほぼ出揃った感じ。相手にとって不足はないけれども、こいつを組み伏せるのは大変だろうなぁ・・。でも、相手は宇宙だ。高度 20200km を秒速 4km でビュンビュン飛び回っている、重量 900kg の衛星約３０基だよ。Linus のおじさんも辿り着けなかった境地が、ここには確かにある。男のロマンって、奴ですか？
ネット上の検索を続けていくと、我が日本に超特大のリソースを発見した。それは、電子航法研究所(名前がカッコイイ！)の福島氏が航空無線に寄稿された「理解するための GPS 測位計算プログラム入門」という連載記事である。航空無線という雑誌の存在は、私も初めて知ったが、これは航空保安無線システム協会が発行しているものである。
同誌と福島氏のご好意により、３回連載分の全ＰＤＦファイルが公開されている。ここで、「理解するための」というフレーズが重要。本来、GPS 測位計算は３回の連載に収まるほど、簡単な代物ではない。しかし、要素を適切に絞り込むことで(これが最も難しいのだが)、読者が理解できるだけのエッセンスに凝縮されている。実際、中身は努めて平易に書かれており、具体例も豊富である。世界広しと言えども、これだけ簡潔にして当を得たリファレンスは存在しないだろう。日本語で読めることに感謝しよう。
本メモを読み返すと、9/14 に DJB 氏の clockspeed に着目したことが分かる(記録は偉大だ)。clockspeed に目が止まったのは、簡単な理由からだ。新サーバー設定にあたり、Red Hat 9 デフォルトの sendmail を引っこ抜いて、qmail に入れ替える最中、DJB site 中に発見したのである。
ちなみに、今回 qmail の解説書４〜５冊を購入したが、ベストは与儀丈二氏による「qmail で作るメールサーバ徹底攻略」であった。daemontools などへの言及も含め、実によく書き込まれており、無駄がない。qmail ファンは、これ１冊を買えば「十分ですよ、十分」だ。
話を元に戻そう。白状すると、clockspeed そのものについては、この１ページしか読んでいない。ソースターボールもまだ解凍すらしていない。しかし、Bernstein 氏によるこの「ぶっきらぼう」とも言える、短い文章を読むだけで、同氏が目指したことはおおよそ理解できたような気がする。
つまり、clockspeed のエッセンスを一言で表現すれば、「RDTSC 命令を PC/AT の時刻精度管理に応用した」点にあると言える。この点さえ理解できれば、後は細かなソースなど読む必要もない。
しかし、ここから「閏秒とはなになのか？」、「そもそも時刻とは何なのか？」、「究極の時計とは何なのか？」という、放浪の旅が始まった。
まだ、現時点では上記の問いに対する正確な答えは出ていないけれど、２万円程度の投資で愛機の時刻精度を数十ナノ秒のオーダーまで引き上げるための方法は、ほぼ目処がついたように思う。GPS の出力データと RDTSC 命令とを組み合わせれば、さらなる改善も見込めそうだ。
ちなみに NOVASTAR 衛星は、セシウムおよびルビジウム原子時計をそれぞれ２台、計４台搭載している。さらに、これらの原子時計はアメリカ海軍天文台(USNO)に安置されている６０台以上にもおよぶ原子時計をリファレンスに用い、相対論的効果まで考慮された補正(GPS 衛星上での時間は地球表面上とは異なる)を、通常１日３回受けている。参考までに、原子時計のお値段は一台１０万ドル級らしい。
安全保障と同じく、時刻管理にはお金がかかるのである。古来、「日本人は水と安全をタダと考えている」と揶揄されてきたが、この中に「時報」も加えるべきであろう。
さて、時間城の全体像も掴めたことであるし、いよいよ実践に挑戦してみよう。とりあえずは、小手調べに RDTSC 命令に挑戦だ。CPU 内部における、クロックの進み具合をこの目で確かめてみる。