Think GNU 第 2 回

□1990 ワシントン USENIX 編□

CUJJ#6/'90.3.18 発売号掲載

0. はじめに

 GNU に興味のある人間がたくさん集まるイベントが、1 年に 2 回ある。それは冬と夏の USENIX(「GNU 単語帖」を参照) の BOF(「GNU 単語帖」を参照) である。このあいだの 1 月に、冬の USENIX がワシントンのホテルで開催された。筆者のうちの 1 人が出席した。今回は USENIX の開催中に近くの展示会場で、Uniforum(「GNU 単語帖」を参照) が開催された。それにも顔を出し、帰りがけにボストンへ北上して GNU の作業場所でのミーティングのために、MIT AI ラボに立ち寄った。

 GNU Make の特徴である並列 Make から始まって、並列処理の 2 つの形態を考察してみた。また、USENIX での GNU BOF の模様も伝えたい。「GNU ダイジェスト」の制作風景も紹介する。今月のニュースは NeXT のコンパイラと GNU C コンパイラの互換性に疑問を投げかけた記事である。さらに今月の記事のキーワードの説明も「GNU 単語帖」に示す。◆1,2

1. 近 況

 ワシントンとボストンへ出向いたあと、今はカリフォルニアのパロアルトにいる。

 今やっている仕事について少し触れる。GNU ソフトウェアの作業ではない。現在、一昼夜かけて試行錯誤を数回繰り返している最中で、コンパイル終了待ちである。最初はファイルを修正して、エラーがわかるまで 5〜10 分はかかった。その待ち時間は何かというと、Lisp 言語のコンパイルで、徐々に誤りが少なくなると、エラーを全て発見するまでの時間が段々長引いてくる。全体を正常にコンパイルするのに何分かかるのやら……。ちなみに、今コンパイル・エラーが正しくとれたかどうか確認するのに必要なコンパイル時間は、待ち時間がおよそ 4 時間、ユーザ時間が 4,800 秒、システム時間が 5,700 秒という非常に大きなシステムである。処理速度が 2MIPS あるマシン (メインメモリが 16M バイト) でスワップ領域を 51M バイトとっているのにこんなに時間がかかり、しかもまだ一通りコンパイルが終わっていない。プロジェクトの他の開発メンバは、Sun の SPARCstation(10MIPS、Lisp 開発用にメインメモリを 28M バイト、スワップ領域を 100M バイトに増強してあるマシン) を使用して、作業の効率をあげているのを横目で見ている今日このごろである。◆3,4

 ここまでは特にプロジェクト GNU *1 とは関係ない。この Lisp 関係のアプリケーションのユーザ・インタフェースとして GNU Emacs を使用している例が多い。もちろん、開発にも GNU Emacs を活用している。なぜ GNU Emacs を使用しているかというと、Lisp の専門家は Lisp マシンか、あるいは遡って DEC10/20 という汎用計算機を昔は使っていた。その両方のマシンにもともと Emacs が動作していたからである。その Emacs は、Free Software Foundation(FSF) の「社長」(と筆者らは Richard M. Stallman のことを呼んでいる) が作成したものに端を発するというわけである。

2. 並列処理の 2 つの形態

 先ほどのような CPU 能力を必要とする作業の効率を高める簡単な方法は、単体で高性能な CPU へ移行するか、あるいは普通の能力を持つ CPU を複数個使用して並列処理を行なうかである。

2-1.Make について

 Unix の世界であれば、通常、C という言語と Make *2 というコマンドを使う。しかし、Unix の世界の Make で行なっているのと同様のことを、Lisp の世界に浸って仕事をしている人達は自前でやってしまう。つまり、Lisp という言語はソース・ファイルのコンパイル手順がソース・ファイル自体と混然一体となっているのである。1 つのソース・ファイルに、Lisp マシンから Unix WS(ワークステーション) 用までのオブジェクト・ファイルを生成し、保守、更新、改良する手順が入っている。個人的な趣味から言えば、この手合いはあまり好きになれないが……。おそらくこういった言語仕様は、その昔の Lisp マシンでよく行なわれた慣習 (全てを Lisp で記述する) が現在に至って世界の人々に採用されるようになったのであろう。ソース・ファイルとは別に Make を使ったものの方が見通しが良いと思う。というのは、Make を使う場合、依存関係とコンパイルやリンクの手順が明確に別ファイルに記述され、わかりやすくなるからである。全てを Lisp で記述した場合は、どこまでが依存関係のチェックで、どこまでがコンパイル・コマンドかが、わかりにくくなる。

 以前聞いた話によると、スーパーコンピュータではソース・ファイルを分割し、それらを個々にコンパイルしてオブジェクト・ファイルを残しておき、次回のバイナリ・ファイル作成に備えるというやり方よりは、オブジェクト・ファイルを残さないで、なるべくソース・ファイルを 1 つにまとめておいた方が早くバイナリ・ファイルができる、という。結局これは、あり余るメインメモリや非常に早い CPU があり、それに比較して遅い I/O ディスクというマシン仕様の存在がもたらした現象であろう。◆5

 Make コマンドを使って、バイナリ・ファイルやオブジェクト・ファイルを生成することを「メイクする」、生成できなかったことを「メイクに失敗した」などと言う。もちろん、このコマンドの GNU 版もあり、GNU Make と呼ばれている。これは並列にコンパイルを行なうといった、一般の Make にはない特徴を備えている。

 この Make コマンドはもともと Unix の世界で作られたものである。現在では、MS-DOS のバージョンもある。DEC の OS の VMS にも同様のコマンドがあるというのを聞いたことがある。GNU Make は条件式の記述や簡単なテキスト処理が可能で、MS-DOS 上での動作も考慮されている。

2-2. 並列 Make

 GNU Make の特徴である並列 Make は、なかなか気の利いたアイデアだと思った。Make コマンドがサブコマンドを並列に実行するのを知ったきっかけは、GNU ソフトウェアのソース・コード中の Make スクリプト (Make に与える入力ファイルのこと。Makefile とも呼ばれるが、必ずしもそのファイル名とは限らないので「Make スクリプト」と呼びたい) の中で、Sequent Balance という並列ミニコンピュータ用の定義の中に、並列 Make の定義らしきオプションがあった。少し気に留めておいた。その後、並列ミニコンピュータに実際にログインできるチャンスがあり、Make のオンライン・マニュアルを見たところ、並列 Make の機能が記されていた。オプションについても解説してあった。以前の推測が正しかったことがわかった。このミニコンピュータは、当時、NS(National Semiconductor) 社の 32032 という 32 ビットの CPU を複数個使用して、完全な対称並列計算機 *3 を構成し、並列 Make もサポートしていた。

 最新のコンピュータや OS の特徴を、ソース・コードから窺い知ることができるというメリットも、GNU ソフトウェアがソース・コードで提供されているからこそである。

 並列 Make のアイデアを知ったことと、筆者らの勤務する会社に WS がぼちぼち入り出した時期とは一致している。当時、10 台ほどの WS が個人のデスクトップに置かれ、日中は有効利用されている。しかし、いったん夜になると電源は入ったまま (この会社は通常、WS は四六時中通電しっぱなしである) で、時おりネットワーク・アクセス・ランプだけが点滅している (そのマシンの 1/5/15 分前の混み具合、ログインしている人数、マシンが立ち上がってからの時間をネットワーク上に接続されている他のマシンに定期的に知らせるためネットワークにアクセスする)。この風景を最初に見た当時は、どうも無駄に電源が入っているだけのように思えて、何か面白い実験はないものかと考えた。そのうちに、並列 Make のアイデアと結び付いて、ネットワークで接続してあるマシン同士でお互いに通信しあうような並列 Make ができないかとひらめいた。並列 Make であるから、それぞれの Make プロセスは別々のマシンの CPU で動いてまとまった作業を行なうわけである。

 例えば、3 つのソース・ファイル a.c、b.c、c.c をコンパイル、リンクして 1 つの実行形式を作る Make の手順を考えてみる。典型的な Make スクリプトはこのようになる。

a.out:a.o b.o c.o
   cc a.o b.o c.o
a.o:a.c
b.o:b.c
c.o:c.c

 これは次のような意味である。

  1. どれも C 言語のソース・ファイルであるから、C コンパイラでリロケータブル・バイナリ・ファイルを作る。

  2. 最後にできあがった全てのリロケータブル・バイナリ・ファイルと、ランタイム・ライブラリや C ライブラリなどとをリンケージ・エディタでリンクさせて、最終的な実行形式を作る。

 一般の Make を使用すると、まず a.c から a.o というリロケータブル・バイナリ・ファイルを作成し、さらに b.c から b.o を作成する。さらに c.c から c.o を作成して、できあがった a.o と b.o、c.o をリンクして a.out を作成する。

 並列 Make を利用すれば、リロケータブル・バイナリ・ファイルを作成する手順 1 は並列に行なえるというわけである。まず、このように並列でコンパイルする。ソース・ファイルが 3 つあるので仮に 3 台のマシンを使うとすると、逐次処理と比較して最大 3 分の 1 の時間でリロケータブル・バイナリ・ファイルが作成できる。

 それぞれのマシンでコンパイルし、全てのリロケータブル・バイナリ・ファイルが揃ったらリンクさせることになる。

 ここで「全てのリロケータブル・バイナリ・ファイルが揃ったら」と「リンクさせる」という 2 つの手順には、このままではマシン間にまたがることが考慮されていないので、これら 2 つの操作に何らかの同期をとる必要がある。

 さらに、「揃ったらリンクさせる」ために、それぞれのマシンで作成されたリロケータブル・バイナリ・ファイルを、リンクさせるマシンのファイル・システムに移動する操作も必要である。大きなオーバヘッドになるだろう。とにかく並列 Make を手っ取り早く動かしてみるには、ネットワーク・ワイド *4 なファイル・システムを使えばよいだろう。その場合に、それぞれのマシンが同じ時刻を示さなければならない。

 ネットワーク・ワイドなファイル・システムとして、例えば NFS を使うことを考えてみる。各 CPU で同じファイル・システムを共有し、各 CPU が同じ時計を持っていれば、時間を基にした依存関係から動作する Make はとりあえず正しく動作するだろう (未確認。常に正しく動作させるにはファイル・ロックの機能も必要になる)。

 時間があれば実験をしてみて読者に結果を報告したい (例えば、並列 Make を使うとシーケンシャルな Make(従来の Make) に比べてどの程度コンパイルやリンク時間が短縮されるか、など)。

 しかし、当時の GNU Make には並列機能はまだ入っておらず、そうこうしているうちにボストニアン *5(ボストン人、プロジェクト GNU への参画のため) になってしまった。当時のボストンでは、マシンはほとんど MIT から借りており、そのような実験ができる環境ではなかったので、沙汰止みになってしまった。しかし、いつかはきっとこの実験をするぞと思いつつ、周辺の情報に聞き耳を立てていた。

 3 年ほど前に、UCB(カリフォルニア州立大学バークリー校) の pmake と他の大学が GNU Make に並列機能を追加したものを (おそらく時期を同じくして) 発表していた。両方ともソース・ファイルを持ってきたが、実験できる環境が整うまでそのままにしておいた。

 日本に帰国して、たまたま半年間ほどディスクの空きが確保できる処理速度の速いマシン (5MIPS) があったので、それをデスクトップ・マシンとして作業を開始した。この新しい環境は、従来のマシンに比べて処理速度がかなり速い。しかし、そのマシン上での環境整備と GNU ソフトウェアのフォローに忙しく、並列 Make の実験はすっかり片隅どころかスタックの奥底に埋もれてしまった。◆6

2-3. 他の種類の並列処理

 別な観点から並列 Make の有用性を考えてみたい。並列 Make のための環境を、例えば、2〜4 台の WS 上で構築したとする。しかし、2〜3 年でマシンの処理能力 (CPU 処理速度) が 2 倍から 4 倍に向上するなか、Make の対象作業がもともと時間を費やさないような仕事 (例えば、全仕事時間の 10% 未満) ならば、わざわざ手間暇かけて並列 Make を行なう必要はないだろう。

 最初から並列処理用の並列コンピュータがあれば、並列 Make を行なうための環境は既に整っているから、この場合の選択は躊躇することはない。とにかくやってみればよいのである。

 並列処理の捉え方にはさまざまな方法がある。ここでは次の 2 種類の方法について考察する。

 1 つ目は、これまでに述べてきた並列 Make のように、コマンド・レベルで並列に処理を行なう方法がある。2 つ目は、処理単位をサーバとクライアントに見立てたサーバ・クライアント・モデルがある。

 サーバはクライアントの要求に応えて、あるサービスを提供する。サーバはいくつものクライアントを同時にサポートすることができるように作られている。この例として、先ほど触れたネットワーク・ファイル・システム (例えば、NFS) の他に、X Window System の表示方式もサーバ・クライアント・モデルと見なすことができる。

 サーバとクライアント間の通信プロトコルの標準化が進み、ネットワークの普及が進むにつれて、クライアントやサーバの機能だけに特化した製品が最近出現している。例えば、NFS 専用のサーバ・マシンや、X Window だけに効率良く動作するように設計された X 端末、ネットワークに接続されていて出力だけを行なうプリンタ・サーバなどである。また、既存の WS をサーバ専用として使うソフトウェアが増えてきている。電子メールの処理だけを行なうメール・サーバ、外部からのソース・ファイルやドキュメント・ファイル、バイナリ・ファイルのアーカイブを行なってそれらを提供する ftp(「GNU 単語帖」参照) サーバ、仮名漢字変換を行なうサーバなどがある。

2-4. サーバ・クライアント方式の長所と欠点

 サーバ・クライアント方式は並列処理の 1 つの形態であることを述べた。実際の例を示して、長所と欠点を考えてみる。

 これまで米国で見てきた 2 つの例から言うと、想像以上にディスクレス・マシン *6 が教育機関や企業に導入されている。例えば MIT では Sun-3/260(5MIPS のサーバ・マシン *7 が 4 台あって、900M バイト前後の CDC 社のハードディスクが 1 つのサーバに 4〜8 台付き、1 台のサーバで約 20 台のディスクレス・マシンをサポートしていた。ディスク付きのマシンもそのサーバを利用していた。バイナリ・ファイルは当時 Sun-3 用のみであったが、最近は HP の WS のバイナリもそのサーバに置いて、Sun-3 と同様のディスクのディレクトリ構造で、HP のディスクレス・マシンへのサービスを開始していた。

 MIT の AI ラボの各階ごとにプリンタ・サーバ用の WS が 1 台ずつ設置されていた。9 階には、メール・サーバ用の WS がある。これらの WS はビットマップ・ディスプレイ付きのディスクレス Sun-3 であるが、プリンタあるいはメール・サーバ専用であり、通常の用途には使われていなかった。

 その他に学生の演習用として、パブリック・スペースと呼んでいる廊下にディスクレス WS や Symbolics(Lisp マシン) が置かれている。1988 年の中ごろまで、Richard Stallman はパブリック・スペースにあるディスクレス・マシンを自分のホーム・マシンとして使っていた。ちなみにそのホスト名 *8 は frosted-flakes である。筆者らも 1988 年 3 月から 4 カ月間ほどは、このパブリック・スペースのマシンにお世話になっていた。◆7

 クライアントやサーバ・モデルの問題は、システム全体の信頼性がサーバのそれで抑制される点にある。事実、MIT の AI ラボではそのようなことが頻繁に発生した。4 台のファイル・サーバのうち 1 台でもディスクの調子が悪く、さらにそのディスクがスワップ領域だったりすると、たいていの場合はシステムがガタガタになってしまう。Unix は基本的に、スワップ領域にバッド・ブロック (読み書きでエラーが生じる領域) があるとシステム・ダウン (「落ちる」 こと) する。

 AI ラボでは、4 台のファイル・サーバで約 40 台前後のディスクレスやディスク付きの WS をサポートしているだけでなく、互いにサーバでありクライアントであるようなマウント *9 の方法 (クロス・マウント) を採用している。

 だから、4 台のファイル・サーバのうち 1 台でもこけると、他の 3 台のファイル・サーバはハングアップ (マシンとしては動作しているのだが、ユーザからの入力を受け付けない状態) し、関わりを持つマシンはほとんどマヒしてしまう。さらに悪いことに、その調子の悪いサーバが、MIT の AI ラボと LCS(Laboratory of Computer Science、コンピュータ科学研究所) のゲートウェイ *10 になっているマシンだと、ハードディスク付きのマシンには被害がなくても AI ラボと LCS とのリンクが切れてしまう。さらに、その先の DARPA ネット *11 にアクセスできなくなる。当然、メール・サーバ・マシンはディスクレス WS なので、ハングアップしてメール・サービスは一時中断という雪ダルマ式の事態があれよあれよという間に起こるのである。

 もちろん、サーバが落ちたら迅速に対処し、ディスクが悪いのならばそのディスクをシステムから外してリブート (再立ち上げ) する。ディスクの I/O ドライバ・ボードが悪い場合は、その I/O ドライバを持つファイル・サーバをシステム全体から外してしまう (論理的にそのマシンをアクセスしないようにする) 方法も採られる。

 このように欠点もあるモデルであるが、さまざまなサービスに用いられている。例えば、MIT の AI ラボの人に教えてもらったのだが、英々電子辞書 (ウェブスタ) サーバに使われている。これはなかなか便利であった。あるサーバが故障した場合にシステム全体 (そのサーバを使用している全てのマシン) の信頼性を上げるために、サーバ・マシンの候補を複数個持てるようにしたサーバも出現してきた。

2-5. 並列処理の必要性

 CPU が高性能になり、複数の CPU を 1 人で使える時代がやって来た。例えば、会社で 1 人 1 台の WS なりパソコンなどを使っていたとする。それらがネットワークで接続されており、プリンタ・サーバとレーザ・プリンタも接続されていると、WS やパソコンの I/O プロセッサやキーボードの制御のみに用いられている CPU を除いたとしても 1 人 1 個以上の CPU を使っているのも同様になる。

 このような使い方はパソコンの世界にまで浸透しつつある。例えば、CPU として Intel 社の 80486(32 ビットの CPU) を使い、グラフィック数値演算プロセッサとして同じく Intel 社の 860(これも 32 ビットの CPU) を使うといった構成のものも今後市場に出てくることだろう。

 32 ビットの CPU で Inmos 社のトランスピュータは、最初からマルチ CPU 用に設計されている。複数のトランスピュータが搭載された IBM PC や NEC の PC-98 用のアドインボードも発表されている。今から何に使うかを考えていても遅くはないのでは……。

3.USENIX

 USENIX に出席すると心機一転した気分になる。今回は冬の USENIX で 2 月 22 日から 26 日まで開催された。USENIX は一般に 5 日間の日程のうち、前 2 日間はチュートリアル・セミナー、後 3 日間はテクニカル・セッションに分かれる。チュートリアルは、当たり外れは多少あるが大概面白い。無論、自分が参加したいものは事前にエントリしなければならない。1 回だけ、エントリするのが遅れて第 1 希望に当たらなかった時はつまらなかったことを思い出す。チュートリアルとテクニカル・セッションに参加すると、世の中の動向 (特に Unix の世界) や、これからどういった製品が出てくるか (テクニカル・セッションの中には製品紹介そのもの、という時もたまにある) がわかってくるから面白いのである。JUNET や uunet などの電子掲示板だけでは窺い知れないものが見えた気になる。

 特にテクニカル・セッションは 1 日中行なわれるので、そのテーマについてじっくり考え、整理することができる。新しい見方や展開をまとめたものが前述の並列処理と Make にまつわる話なのである。

3-1.GNU BOF

 USENIX に参加したもう 1 つの目的はインフォーマルな夜の集まりである GNU BOF への参加である。この GNU BOF でも「GNU's Bulletin」と日本語訳の「GNU ダイジェスト」を配布している。GNU BOF 以外の主な配布場所は、パンフレットを自由に置くことができる長机の上で、大きな各セミナー会場の近くや、ターミナル・ルームの中にあり、英語版オリジナルと日本語版を並べて置く。

 この「GNU ダイジェスト」は、USENIX が開催される 2〜3 日前に完成する。筆者らが参加できるときは持参し、そうでない場合は国際宅急便で開催会場のホテルまで送る手はずになっている。前回 (バルチモア) は、ホテル側のミスで USENIX での日米同時配布は実現できなかった。

 今回の GNU BOF は、Len Tower をチェア・パーソンとして 2 日目の 20:00 から始まり、21:30 には散会した。今回は部屋の両サイドまでテーブルが寄せられているせいか、皆ちゃんと椅子に座っていた。その後で Len を囲んで個人的な Q&A などで話がはずみ、実際には集会は 23:00 ごろまで続いていたようである。

 GNU ソフトウエアや GNU プロジェクトへの貢献者の表彰の後、ディスカッションや Q&A がひとしきり行なわれる。それを区切りとして、あとは自由ミーティングになる。ここで帰ってもいいし、さらに相手と場所の都合がつけば夜を徹して話し合うこともできる。あっという間に Len の周りに人垣の山ができる。

 さて、GNU BOF とは何をするものかをもう少し紹介しよう。

 Len Tower の目印は独特の小さなポシェットをウェストに付け、ロングヘアーを下の方でたばね、長いヒゲに黒ぶちのぶ厚いめがねをかけている。そんな Len がまず、机の上に座り GNU BOF 開催宣言を静かに行なう。続いて Len の自己紹介である。GNU にかかわって 5 年経ち (当時)、ボストン大学にも所属、Richard Stallman と GNU を設立し、現在、メーリング・リストなどの情報管理を行なっているという。次に、GNU ソフトウェアを簡単に紹介しながら次のようなアンケートをとる。

John Donnely
USENIX Association
2560 Ninth Street, Suite 215
Berkeley, CA 94710
U.S.A.

 最後のアンケートから、GNU プロジェクトに寄付をしてくれた人々に Len が GNU バッジを配る。これが GNU BOF 式の表彰である。GNU に貢献したと思う人は、自己申告制で立って自分の名前と電子メール・アドレス、その内容について簡単に発表する。そして、Len が謝辞を述べ GNU バッジ (今回は黄色) を渡して、会場の拍手と共にその人を励まし、その他の人々をも励ます。筆者の 1 人もその場で筆者らの分ということで 2 つバッジを受け取った。◆8

 バッジが表彰者への記念品では質素だと思う読者もいるかもしれないが、特製バッジに込められた Len の、GNU への思いや励ましを慮っていただきだい。

 そして Len がこの GNU バッジの紹介をする。ちなみにこの GNU バッジは Len Tower の個人的なプロジェクトで作成している。これは、USENIX のたびに色が変わる「GNU's Bulletin」の表紙と同じ背景色で、GNU と書かれたバッジである。そのバッジを GNU BOF の夜に、プロジェクト GNU に貢献のあった人達に配る。残ったバッチは 1 個 5 ドル以上の現金と交換で BOF の散会後にその会場で寄付を募る。GNU バッジのイラストのもとであるファイルは、PostScript で記述されており copyleft の保護下にある。

 続いて、マニュアルの紹介や GNU プロジェクトの意味、FSF の役割を述べ、GNU 関係の質問用の電子メール・アドレス (gnu@ai.mit.edu) をアナウンスした。これらについての詳細は「GNU's Bulletin」か、あるいは「GNU ダイジェスト」 を参照のこと。

 この後、オープン・ディスカッションが行なわれた。その話題の中から何が今人々に注目されているのか、そしてプロジェクト GNU からの wanted(一部) をまとめたものを次に示す。

 この中で Len がわからない点や重複する点は、メーリング・リストに質問するように、あるいは「GNU's Bulletin」を参照するようにという回答も多かった。

 これでいったん BOF は散会し、Len を囲んで個人的な質問や政治的な Q&A に入った。

 次に、ここでも頻繁に参照されている「GNU's Bulletin」を翻訳、加筆して「GNU ダイジェスト」と題し、GNU BOF などでの配布に至るまでの制作舞台裏について触れてみたい。

4.「GNU ダイジェスト」とは

 「GNU ダイジェスト」は「GNU's Bulletin」の完訳に、日本で役に立つと思われる情報を加えた GNU 情報誌である。原著名は「GNU's Bulletin」だが、日本語に訳す時に Bulletin ではこの情報誌の性格が出ないので、あえて「GNU ダイジェスト」とした。原著は毎年 2 回、USENIX に合わせて発行されるのに対して、「GNU ダイジェスト」は、さらにその途中で更新したバージョンを発行することもある。日本側での情報の追加や補足などはなるべく脚注や付録を使って、原著の体裁や内容を維持している。

 「GNU ダイジェスト」を制作し始めてもう 2 年以上経つ。その発行でもって GNU への正しい理解や興味を持っていただければ筆者らの幸いである。詳細は 「GNU ダイジェスト」を参照されるか、あるいは、筆者までご連絡いただきたい。なお、こういった筆者らの一連の作業は全て、ボランティア・ベースで行なっていることをご理解願いたい。

4-1.「GNU ダイジェスト」の制作工程

 さて、どのようにして「GNU's Bulletin」や「GNU ダイジェスト」が制作されるのかを紹介しよう。

 USENIX の 1 カ月ほど前になると、アウトラインについて fsf-hq(FSF 専用のメール・グループ) を通じてその登録メンバーと電子メールで話し合う。構成が決定すれば、すぐに執筆を開始する。プロジェクト GNU の進捗報告は、rms のディレクトリの下にドラフトができているのでそれを用いる。rms 自身の記事は、彼が最後の 1 分まであきらめずに編集しているので、たいていは他ができあがったころに最後の挿入となる。加筆・修正などの編集まとめ役は rms を頭に Len や Bob が行なっている。しかし、そういった編集の情報は、そのたびごとに全て fsf-hq 全員へ電子メールで流される。修正に異議があれば、すぐに彼らにリプライすればよい。

 このようにしてできあがったドラフトは、プリンタ出力して MIT の Richard の部屋の前の壁に貼り出す。そこの廊下を通る人は誰でもそのドラフトに赤を入れることができるようになっている。掲示期間は 1 週間である。このころになると、かたや日本の筆者らは telnet コマンドでドラフトが置いてあるマシンにログインしてドラフトの進捗具合をチェックし始める。

 ようやく最終原稿がプリンタから出力されると、イラストと共にすぐに印刷へ回される。印刷・製本は業者にまかせる。色付きの表紙にホチキス 2 つの中綴じで、A5 サイズの簡易製本である。毎年発行部数は確実に増えている。USENIX での配布数 (今年は 5,000 部) だけでなく、注文の (テープの注文に同封される) 数も増えているからである。最終原稿ができた知らせを筆者らがもらうと、指定のファイルを ftp(「GNU 単語帖」参照) で入手し、すぐに訳を開始する。ぐずぐずしていると同じ体裁の「GNU ダイジェスト」数百部を USENIX 会場へ送れなくなる。

 「GNU ダイジェスト」の送付は遅くとも GNU BOF の日までに間に合わせなくてはならない。GNU BOF はたいてい火曜日 (USENIX 2 日目) の夜に行なわれる。

 訳す側はふだんは会社の業務があるため、就業前後や昼休み、土日、通勤途中、あるいは家で徹夜といった具合に受験生顔負けで何とか時間の算段をしている。イラストだけは電子的なやりとりが困難なので、日本側で適宜決定している。

 無事に終われば、USENIX にて日米の小冊子が顔を合わせることになる。これで日米同時発行とあいなる。

 なぜ USENIX に持ち込みたいかというと、GNU BOF が開かれるだけでなく、世界中からいろいろな考え方を持った人間が集まる大きなイベントのために主張のしがいがあるからだ。まして、英語で無料展示されているパンフレットなどが、のきなみ並んでいる中に、翻訳版も肩を並べて発行されているというのは、非常に人目を引く。英語圏で日本語版がおめみえするという、一見矛盾したようなこの効果は「GNU ダイジェスト」に関しては大である。大切にしたい。

 日本からの USENIX 参加者が数百人もいるわけではないが、GNU BOF の資料としてだけではなく、米国の人々は日本語のわかる友達に渡したり、おみやげ用、自分のライブラリ用、コレクション用といろいろな用途で持っていってくれるために、数百という単位は十分にはける。余った「GNU ダイジェスト」は USENIX 終了後、GNU BOF のチェア・パーソンをつとめた Len Tower に頼んで FSF へ持って帰ってもらう。日本から FSF へテープを注文した際に、ソフトウェアやマニュアル送付担当の Stacey が同封してくれる。

4-2.「GNU ダイジェスト」の清書方法

 次に、「GNU ダイジェスト」の内部的な話をしてみよう。このテキストは Unix 上で作成される。清書プログラムには、原著では TeX(「GNU 単語帖」参照) を採用し、さらに GNU 固有のマクロ texinfo を使っている。日本語版では日本語 TeX(「GNU 単語帖」参照) を採用し、GNU 固有のマクロ texinfo を日本語 TeX に対応させた修正版 jtexinfo を使っている。もともとの texinfo には 3 種類の体裁 (小冊子タイプ、A4 タイプ、レター・サイズ) を選択できるようになっている。その中にはこの小冊子用に出力する体裁も含まれている。

 この GNU マクロ texinfo の日本語化には、ちょっとした繁雑な背景があった。プロジェクト GNU の作業場所である MIT には漢字プリンタなるものはあたりまえのように当時なかった。周囲の環境は完璧に日本語皆無の世界だった。近くにあったのは Apple Laser Writer と IMAGEN プリンタだけだった。当初は、作業用のマシンを確保できず、持参の Macintosh から Apple Laser Writer へ 1 ページずつ出力した。プリンタ・キューがすぐにパンクするので 1 ページずつしか出せなかった。そこで MIT の Macintosh を借りて 2 台で筆者らが編集と出力を交互に行なった。rms の怒りを抑えるのも大変だった (look and feel 訴訟問題がプロジェクト GNU の存亡がかかった問題なので、rms は Apple 製品の不買運動を行なっていたからだ)。しかし、Macintosh を使わざるをえなかった。不可抗力だった。

 しばらくすると、やっとプロジェクト GNU へ寄付された WS を 1 日中使うことができるようになった。そこで、IMAGEN 用にコード変換するコマンドが当時の NTT 版 jTeX(これも日本語化された TeX) に入っていたので、jTeX をインストールした。ところが、GNU マクロ texinfo を使うには致命的なバグ (現在は修正されている) が NTT 版 jTex にあった。texinfo を日本語化して使う場合に数式モードが必要なのだが、その数式モードで日本語をサポートしていなかったのだ。簡単に言えば、数式の中に日本語を入れることを考慮していなかった、ということである。さらに、無理矢理数式モードの中で日本語を入れたので、自前で日本語の禁則処理をする前処理コマンドをとりあえず作った。フォントも指定し直さないといけなかった。jTeX や jtexinfo に対してこのようなことができたのは、ソース・コードで提供されていたから、構文解析自動生成ツールや字句解析ツールを使って手直しすることができたのである。本当にソース・コードの存在はありがたいと身をもって感じた。ちなみに、もとの texinfo を修正することについては FSF の許可が必要であり、もちろん jtexinfo についてはすでに許可が得られている。

 筆者らの会社にインストールされているのはアスキー版日本語 TeX だけだった。また、jtexinfo を書き換えるかと思いきや、こちらはフォントの再指定だけで済んだ。この jtexinfo を電子掲示板で配布したところ、さっそく NTT 版 jTeX 用の修正が流れたので、作成者の了解を得て、手元の jtexinfo にその修正を反映させた。

 両バージョンに通じる問題点として、英語の出力ではきれいに清書されても、同じフォントと行間で日本語を出力しても同様の美しさは期待できないので、そのへんの調整も施さなくてはならなかった。日本語化された TeX が何版であろうと、一貫した使い勝手と結果をユーザに提供して欲しいものである。

4-3.「GNU ダイジェスト」に出会うには

 最後に、GNU 情報誌「GNU's Bulletin」と「GNU ダイジェスト」の配布形態について紹介しよう。両誌を入手する方法は、

  1. FSF へテープを注文すれば同封される

  2. USENIX の資料が展示されているテーブルを探す

  3. USENIX の GNU BOF に参加する

  4. 「The C Users Journal Japan」および「C JOURNAL」のバックナンバーを見る

  5. 筆者ら (引地美恵子担当) の連絡先に郵送料として 1 部につき 175 円切手を送る (継続購読は 175 円切手を複数枚送付。大量の場合は宅急便で着払い)
      連絡先〒102 東京都千代田区平河町 1-1-1
             株式会社 SRA
                引地美恵子 (または引地信之)
                電話番号 (03)3234-2611(大代)
                電子メール h-mieko@sra.co.jp(引地美恵子宛て)
                           hikichi@sra.co.jp(引地信之宛て)
    
  6. JUNET のニュース・グループ fj.sources に投稿された「GNU ダイジェスト」のテキスト・ファイルと jtexinfo マクロを拾う

などがある。製本されたものは 1 から 5 にあたる。6 は Unix ファイルを投稿しているので、拾ったサイトは各自改めて日本語対応の TeX と jtexinfo マクロを使って清書したものをプリンタに出力することになる。暇を見て、オンラインで見られるようにフォーマットし直したものをそのまま投稿したい (このオンライン形式はもともとの texinfo マクロに備わっている機能で、info 形式と呼ばれる)。

5. 今月のニュース「NeXT 社と gcc 編」

 今月のニュースは、米国で uunet を介して、NeXT マシンと GNU C コンパイラなどにまつわる話題があがっていた。その概要を次に載せる。これで NeXT マシンの周辺の様子がざっと掴めるかと思う。

 NeXT ボックスで動作する C コンパイラにはどんなものがあるかというと、NeXT の「標準」C コンパイラとして gcc(最新版ではないが) の修正版を基本システムとして組み込んでいる。

 余談ではあるが、この NeXT ボックスという呼称についてだが、たいてい箱型のものはこう呼ばれている。NeXT だけについている呼び名として「キューブ」というのがある。◆11

 その他に、なるほど思うのは SPARCstation や Sun-3/80 が「ピザ・ボックス」、Sun-386i やそれと似た形の外部記憶装置が「シュー・ボックス」(くつ箱) である。

 気になるところはその信頼性である。いくつかの言語の拡張が行なわれているが、gcc はほとんど ANSI に準拠したコンパイラである。また、NeXT システムの C コンパイラは、gcc をベースにしているとはいうものの GNU C コンパイラの現行のバージョンと互換性が徐々になくなっている。それは、gcc にとっては扱い方を知らないはずの (知ろうとも思わないが) 新型のプリプロセッサ命令を NeXT が捏造した (あるいは借りた) からである。どういうことか Ron Guilmette の調査をもとに技術的に解説しよう。

 その命令は #import と呼ばれている (らしい)。多くのファイルで使われており、NeXT に最低必要なシステムも含む。後述の理由から、その命令を〈sys/file.h〉などのように典型的な C 言語プログラムにも入れなければならない。

 これに対して、Chris Whatley がこのように反論していた。#import は Objective C プリプロセッサに対する命令で、Objective C のうまい実現の方法を採用して、C コンパイラやプリプロセッサから完全に独立させたものである。

 この Objective C プリプロセッサを gcc 内部に組み込むことによって速度が向上する。#import 命令は、現在は Objective C で書かれた移植性のないアプリケーション・キット・ヘッダの中で用いられている。標準インクルード・ファイルの中には #import 命令を見かけない、と。

 gcc はこの命令をある良い理由 (後述) のために認識していない。ファイルを含むシステム内での使われ方は、ささいなプログラムを除けば、NeXT 上で何かをコンパイルする時に、gcc の最新バージョンを仮想的に使えないようにしている。まして、gcc はますます頑強になり信頼性が向上しているのだから、その差が開くことは目に見えている。

 #import 命令というのはある 1 点を除いてこの #include 命令と共通である。この相違点とは、コンパイルをしている間は、コンパイラに対して同じファイルを再度インクルードさせないようにしていることである。

 最新の gcc では、これと同様の機能をうまいやり方で実現している。それは #pragma once と呼ばれている。コンパイル中に各ファイルを多くても 1 度だけインクルードする。だから、gcc は #pragma once を使うことによってこの情報をプリプロセッサに明示的に与えることができる。そのため、pragma は多くても 1 回だけインクルードされるべきファイルの中に埋め込まれる。

 #pragma once には、NeXT マシンの #import の抱える問題を解決するような次の利点がある。

 GNU C コンパイラの作成者兼保守担当の rms は、こういった問題を考慮した上で、現在以後の gcc のリリースでは #pragma once をサポートする予定でおり、#import のサポートは全く考えていない。

 結局、NeXT 社がこれらの事実を鑑みて gcc 互換のインクルード・ファイルの機能を組み込む時期かもしれない。そうでないと、刻々と改良される gcc のバージョンを使っても NeXT マシンでは動かなくなっていくので NeXT ユーザは苦しむことが予想される。

 NeXT ウィンドウ・システムと X Window System の共通点は 1 つだけである。クライアント・サーバ・モデルが基本となっている点である。NeXT ウィンドウ・サーバは DisplayPostScript で通信し、X11 と互換性はないが、X Window プロトコル (クライアントとサーバ間の通信規約) を解釈して、PostScript 言語の字句 (トークン) に変換するような NeXTStep 環境下のウィンドウがもうすぐできるかもしれない。◆12

6.GNU 単語帖「GNU word」

 ここでは、GNU 独特のテクニカル・タームでなくても GNU の話題をフォローする目的で単語を選択しているので一読されたい。

6-1.USENIX[ゆーずにっくす]

 毎年 2 回定期的に行なわれる世界の Unix ユーザのためのチュートリアル、テクニカル・コンファレンスの総称である。1 月と 6 月に開催されるので、それぞれ冬の USENIX、夏の USENIX と呼ばれている。チュートリアルは最新技術に関するセミナーで、1 日中行なわれる。4.3BSD や AT&T System V のカーネルの内部に関するものもあり、これらの参加申込みにはたいていソース・ライセンスのコピーの提出を求められる。

 これまでで比較的多かったチュートリアルの話題は Sun の NFS に関するものと CMU(カーネーギー・メロン大学) の Mach カーネルに関してである。ちょっと変わった題材では、GNU C コンパイラの内部に関するセミナーを、rms(GNU C コンパイラの作成者) と Tieman(GNU C コンパイラを NS(National Semiconductor) 社の 32K や Sun の Sun-4 に移植したり、GNU C++ コンパイラを作成した人) が行なった。

 テクニカル・コンファレンスは論文発表の場でもある。その他に USENIX 主催のパーティが行なわれたり、後述する Uniforum が並設されていない時は製品の展示会が行なわれる場合もある。

 参加者は全て登録制になっている。USENIX Association がその主催団体で、基本的に非営利な目的で活動している。活動内容は、情報誌「;login」などの発行やいろいろなワークショップ (例えば、グラフィックスや C++ など) の開催、4.3BSD Unix マニュアルの配布などを行なっている。1990 年 1 月現在の会費 (入会金はない) はこのようになっている。

個  人   US$40.00

教育機関   US$125.00

学  生   US$15.00(身分証明書の写しを同封)

企  業   US$75.00

 興味のある方は次の所まで連絡を乞う。

USENIX Association
2560 Ninth Street, Suite 215
Berkeley, CA 94710
U.S.A.

6-2.BOF[びーおーえふ、ぼふ]

 BOF を、日本では「ぼふ」と呼ぶ人もいる。英語圏においては「びーおーえふ」の方が通じ易い。BOF とは `Birds Of a Feather' の頭文字をとったものである。

 この頭文字だけでは鳥の羽ばたきのように、集まった人々がわいわいがやがや思う存分話し合い、情報交換をしている様子のように想像できる。事実そうなのだが、英語の諺に `Birds of a feather flock together.'(類は友を呼ぶ) というのがあるのをご存知であろうか。一癖も二癖もありそうな輩の「種族」がこうも集まるものだろうかという第一印象を持つのがこの BOF なのである。

 USENIX がフォーマルな昼型コンファレンスであるのに対して、こちらは完全夜型のインフォーマルな集まりで、誰でも参加できる。インフォーマルだから参加しなくてもよいわけで、それだけに本当に参加したいテーマのところに集まってくる。集まってくる人々の目的意識は日中のセッション以上で、人も BOF の個性もかなり強くなっている。中でも GNU BOF は回を重ねるごとに参加者が急増し、最近では USENIX セミナーの大会場と同じ規模 (200〜300 人) の会場を借りるほどである。

6-3.Uniforum[ゆにふぉーらむ]

 たいてい USENIX の開催地近くで同じ時期に行なわれる商用ベースの Unix 関係のショー。ソフトウェアや、Unix 関係の本や雑誌、ハードウェアにおいてはマイクロコンピュータからスーパーコンピュータに至るまでの展示やデモが行なわれている。こまめに歩いてノベルティーを集めるのもいいだろう。

6-4.ftp[えふてぃーぴー]

 ftp は file transport program の略である。当初 ARPANET 用に設計されたファイル転送規約 (FTP、File Transfer Protocol) を使用したネットワーク上の遠隔システムとの間でファイル転送を行なう。

6-5.TeX[てっく、てふ]

 Unix 上で動作する PDS(Public Domain Software) の清書プログラムである。

 Donald Knuth が作成した。もともと roff で数式を書くのが非常に不便だったので、自分でこの TeX を作成してしまった、と聞く。TeX について定期的に詳細な情報を知りたい場合は TUG(TeX Users Group) の会員になればよい。ちなみにこの表記法は、正しくは TeX の e を大文字で段下げして表記する (TEX) のだが、それができない場合は、TeX のように小文字にしてその代用とする。プロジェクト GNU でも TeX とオリジナルのマクロ texinfo を使って、ドキュメンテーションを行なっている。TeX に興味のある方は次の所まで連絡を乞う。

●会誌「TUG Boat」に関する問い合わせ先
TeX Users Group
c/o American Mathematical Society
P.O.Box 9506
Providence, RI 02940-9506
U.S.A.
●Unix 用 TeX の配布窓口
Northwest Computing Support Center
DW-10, Lewis Hall 208
University of Washington
Seattle, Washington 98195
U.S.A.

6-6. 日本語 TeX[にほんごてっく、にほんごてふ]

 (株) アスキーが開発した日本語対応の TeX。VAX 11、SONY NEWS、Sun-3 上で動作するらしい。アスキー版を「日本語 TeX」、NTT の斉藤版を「jTeX」と呼称を分けている。

7. おわりに

 今回は USENIX と GNU BOF を紹介した。USENIX に参加すれば、チュートリアルやテクニカル・セッションは知的好奇心を高め、リフレッシュさせてくれる。また、開催地 (今回はワシントン) の観光も楽しい。しかし、その開催中に併設される GNU BOF への参加は筆者らにとって、今や大きな定例行事となっている。

 日ごろ考えていることが USENIX の参加中にまとまったので、並列処理 (GNU Make を例として個々のコマンドの並列化と個々のサービスの並列化) について書いてみた。

 そして、「GNU ダイジェスト」の舞台裏についても触れ、筆者らはさらにきれいなダイジェストの制作について研究していること (例えば、PostScript のイラストを組み込むことなど) を付け加えておく。

 最後に、この記事を書くためにたくさんの人にお世話になり、また、いろいろな論文も参考になった。その数はあげきれないが、論文を書いた人も含めてかかわる人々に感謝する次第である。

参考文献

★1

Pamela Samuelson,"Why the look and feel of software user interfaces should not be protected by copyright raw", Communication ACM, May 1989 Vol. 32, #5.

★2

本文では参照していないが Make コマンドの作り方 (内部動作) は次の本が参考になる。

Alfred V. Aho, Brian W. Kerninghan and Peter J. Weinberger,"The AWK Programming Language", Addison-Wesley, 1988. (邦訳、足立高徳訳「プログラミング言語 AWK」トッパン、1988)


Think GNU 連載第 2 回【脚注】

◆1

「GNU 単語帖」でも説明しているが、「USENIX」について少し補足する。USENIX という米国の Unix のユーザ・グループがある。年に 2 回コンファレンスが開かれる。コンファレンス自体を USENIX と呼ぶこともある。

◆2

今回は分散処理について触れている。そこで良く出てくる言葉として、「ローカル」と「クライアント」がある。自分が使用しているマシン側を「ローカル」といい、ネットワークあるいは回線を介して接続してあるマシンを「リモート」と呼んでいる。

◆3

「ユーザ時間」、「システム時間」、「待ち時間」という言葉を使用している。待ち時間はあるコマンドを起動してから終了するまでの待ち時間のことを意味し、ユーザ時間はそのコマンドの実行のためにユーザ空間で CPU が費やした時間、システム時間はカーネル空間で費やした時間 (システム・コールなどの処理時間) のことを意味する。TSS などのマルチタスク処理システムでは、処理プロセスが多ければ待ち時間が長くなる。

◆4

「スワップ領域」は、OS 用の作業領域である。BSD 系 Unix(4.3BSD 以前のもの) では、一度に起動できるプロセス領域の総量はスワップ領域までである、という制限がある。

*1

プロジェクト GNU…一般には「GNU プロジェクト」と呼んでいる。しかし、ボストンの GNU の作業場所の入口には「プロジェクト GNU」と書いてあった。気に入ったのでこの呼び方を使っている。

*2

Make…複数のソース・ファイルをコンパイル、リンクする手順を記したファイル Makefile(あるいは makefile) に従い、手順の時間的な依存関係を調べて、必要最小限のコンパイルやリンクを行なう。

◆5

一般にスーパーコンピュータでは、2 種類のディスクを使用する。1 つは磁気ディスクで、もう 1 つは半導体ディスクである。作業用のファイルは半導体ディスク上に割り当てられる。すぐリンクされる可能性のないオブジェクト・ファイルは、磁気ディスクに割り当てられるので、半導体ディスクに比較して時間を要する。一方、半導体ディスクに割り当てられる作業用ファイルを用いれば、短時間で実行ファイルが作成できる。

*3

対称並列計算機…これはどの CPU のタスク (機能) も動的に決定できる計算機という意味である。それに対して、非対称並列計算機というのは、各々の CPU のタスクが静的に決定されている計算機を指す。後者の例を示すと、ディスク CPU はディスク専用、I/O CPU はディスク以外の I/O 専用、これら以外のタスクとしてメイン CPU といった具合に、役割分担が決定されているシステムである。

*4

ネットワーク・ワイド…いくつかのネットワークをまたがっても 1 つのファイル・システムと見なせるようにしたファイル・システムのこと。代表的なものに、Sun が開発した NFS(Network File System) と AT&T が開発した RFS(Remote File System) がある。

*5

ボストニアン (Bostonian)…ボストン在住の人間をこのように呼ぶ。場所がニューヨークならばニューヨーカー、カリフォルニアならばカリフォルニアンというわけである。

◆6

複数の WS を使用して 1 つのまとまった作業を行なうアイデアについて述べたが、いまだにその実験を行なっていない。本文でも触れたが、環境を整備するよりも、高速の WS に移行していくほうが手っ取り早い。しかし、別な意味での並列処理は現実のものとなっている。例えば、ネットワーク・ファイル・システム (例えば Sun NFS) や仮名漢字変換サーバといったサーバ・クライアント・モデルに基づいた処理である。

*6

ディスクレス・マシン…一般の WS はハードディスクとキーボード、イーサネット、インタフェースを備えており、単独 (スタンドアロン) でも使用できる。ディスクレス・タイプの WS は、この構成からハードディスクを除いたもので、騒音や発熱も少なく軽量で広い場所を必要としない。

*7

サーバ・マシン…サーバ・クライアント・モデルでは、サービスを提供する側をサーバ、提供される側をクライアントと呼ぶ。さまざまな WS などのクライアントのために高速ディスク I/O サービスを提供するマシンで、大容量高速ディスクと一般にはバックアップ装置を有する。

*8

ホスト名…マシンについている論理的な名前。ネットワークで接続されている場合の ID で、遠隔操作の際に用いられる。

◆7

frosted-flakes というホスト名が出てきた。これは米国の朝食によく登場するシリアルの製品名である。MIT の中の AI ラボはテックスクエア (Tech. Sq.) という場所にあるが、そこで使用されているサーバのホスト名や WS のいくつかにはこういったシリアルの名前が付いている。おそらく、どのスーパーマーケットにも置いてあり、CM も頻繁に放映されて覚えやすいからであろう。9 階にあるマシン・ルームに入ると混み入ったところにサーバが 3 台並んで置いてあり、自分のホスト名を示すシリアルの空箱が筐体の上に置かれている。trix、alpha-bits、wheaties という名前である。

*9

マウント…物理的には 1 つのファイル・システムではないが、この操作によって別のディスクをそのファイル・システムに取り込める。この状態を解除する操作がアンマウント。

*10

ゲートウェイ…物理的に直接接続されていないネットワーク同士を論理的に接続する装置のこと。その装置が正常に動作しないと論理的に切れた状態になる。

*11

DARPA ネット…国防総省先端技術計画局が先端技術の研究のために作成したネットワーク同士を結ぶ広域ネットワーク (Internet とも呼ばれる)。

◆8

GNU バッジ…以前のデザインは、GNU という文字に作成年の「©告知」(著作権告知) がなされており、背景は USENIX ごとに「GNU's Bulletin」の表紙に合わせた色を使用していた。しかし、最近は毎回独自のデザインを採用している。ちなみにバッジは「ボタン」と発音しており、会社の宣伝だけではなく、個人的に自分の考えをボタンにして配ることも多い。最も強烈なものは rms が作った、りんご (Apple) を食べている蛇のデザインである。強烈な主張が感じられる。

◆9

GNU Emacs バージョン 19 は、1992 年ではまだリリースされていない。

◆10

最新の gdb(バージョン 4.7) では既に MIPS マシンをサポートしている。

◆11

立方体の外観から「キューブ」と呼ばれる。

◆12

Sun の NeWS ウィンドウ・システムは X11 プロトコルと PostScript 言語のプロトコルの両方を解釈できるものである。