Daemons and Dragons がつねにケースパイケースでおこなうものである。世間か すべき望ましい結果と避けるべき好ましくない結果につい ら隔離された環境に棲んでいるのでもないかぎり、これら て簡潔に書かれていなければならない。 の決定が大きく揺れ動くのは当然である。ほかの組織の誰 また、誰かが、、一線を越えて〃組織の基本方針を侵害す かさんがのたまう、、 USENET の精ネなる言葉は思わす るような事態に備えて、以下の点が明確に示されていなけ うっとりさせられるような響きに満ちているが、現実の世 ればならない。 界での基本方針の評価とは無縁のものである。 経営者たちが、自ら計算機資源を管理していることはめ 、、一線クは問題となる出来事が起こった後ではなく、起こ ったにない。しかし、実際は資源の所有者を管理する責任の る前に定義されていること。 、、一線〃は独陸和勺に決められるものでも、独占的な権威に 一端は彼らが負っている。これはどの組織についてもいえ よって作られ、実施されるものでもない。万一そのよう ることで、、、聖域〃たる大学でも営利企業でも同じである。 管理者や経営者は、潜在的な危険を予想し、合理的な基 な方法をとると、管理者は数々の厄介な問題を抱え込む 本方針にもとづいてあらかしめ対策を講しることに責任を ことになる。 負っている。にもかかわらす、通常は厄介な状況に直面し ・すべてのユーサーがその基本方針を読み、それについて て早急な対応が求められるまで、危険を察知すべき管理者 質問する機会が与えられていること。また、ログインす や基本方針を立てる経営者が責任を問われることはないの ることによってその意義を理解し、同意できるような仕 が実情である。 組みになっていなければならない。 事が起こってはしめて、状況に応した、、基本方針〃が突 ・文書化された基本方針は、簡潔かっ要領を得たものであ ること。さもなければ、もっとも肝心な基本方針の意図 然打ち出される。そのときになると、人びとは自分の立場 を認識し、事態に立ち向かう覚悟を決めている。しかし、 は理解してもらえない点を肝に銘しておかなけれはなら それはすでに損害を被った後であり、お世辞にもエレガン トな方法とはいえない。 ・基本方針の最終的な承認は、組織のできるかぎり上のレ 一般に、このような状況にたちいたると、経営者はすべ ベルでおこなわれること。 てのものがこの世から消え去ってしまえばよいというよう 繰り返すが、あなたが管理者であれは、基本方針を公式 な気分に追いやられてしまうものだ。しかも、損害の補填 にかかるコストは事前の対策の立案にかかるものよりも に発表する前にすくなくとも経営者の暗黙の同意を得てい つねに莫大である。 なければならない ( もちろん、はっきりした了解が得られれ はなおよい ) 。いすれにせよなんらかの承認が必要で、さも では、どうすればこの間題を解決できるのだろうか。そ なけれは危機に直面したときに基本方針の効果が弱めら れには、規則のもととなる基本方針をあらかしめ、、書面に〃 れてしまう。 己し、その論拠をユーサーに説明すればよい。 あなたが作成し、提案した基本方針の概要を前向きな議 その場合、かならすしもすべてのユーサーが示された論 論をとおして経営者に理解させることができれば、遅かれ 拠に同意する必要はなく、分かってもらえさえすればよい。 早かれあなたか望んだことはほとんど、あるいはすべて実 同意が得られれはそれに越したことはないが、そうでない 現するであろう。そのためには、実際に基本方針を作成す ときは彼らの懸念に注意深く耳を傾けねばならない。一般 る前に、その基本的な考え方について経営者から十分な理 に、それは意図が明確に伝わっていないことに起因するケ 解が得られるようにすべきである。 ースがほとんどである。 提示された問題点を明確に文書化する人間が、最終結果 文ヒにあたっての注意点 を左右するもっとも強い立場にある。あなたがシステム管 理者なら、あなたこそその人間であることを忘れてはなら 文書化された基本方針には、それカ甘是示されたとおりに 方針を立てる前に事件〃が起こるのを待っているよう 扱われなければならない理由と遵守の方法とともに、達成 1 一二ロ 87 UNIX MAGAZINE 1991.1

なら、怒り、焦った経営者にせきたてられるように方針を 作成しなけれはならなくなる。そのような場合、経営者は 事前に手続きを踏んで保証を受けたときと比べ、かけ離れ て厳格な態度で臨むことになるであろう。その結果、あな たはそれを無理矢理に実施せざるを得なくなる。こういっ た状況下では、あなたにとって望ましくない結果を受け入 れるよりはかに途は残されていない。 原則として、必要なこととその理由について経営者と合 意したうえで、基本方針の詳細を文書化すべきである。そ うすれは、基本的な部分については誰も驚くようなことは こまでたどり着いたら、承認のサインをもらうために 最終的な文書を提出する。これまでに述べたステップが滞 りなくおこなわれていれば、成功はもはや約束されたも同 然である。 属している組織がその成員の考えと感し方に十分な配 慮を惜しまないのであれば、提案された基本方針を検討す るためのユーザーによる審査会を作る許可を得たほうがよ い。そうすれば、苦もなく合意が形成できる。 基本方針の公表 基本方針を実行に移すのは簡単である。 ・基本方針をユーサーにオンラインで知らせる手段を準備 する ( 方針のメニューを表示するシェルスクリプトな ど ) 。 ・ユーサーにそれまでに用意が整った方針へのアクセス 方法を知らせ、発表された基本方針を理解したうえで遵 守しなければならない旨を書面で知らせる。 ・ユーサーに、すべての質問は直接システム管理者 ( あな た ) に寄せるように通知する。 方針が変更されたときは、 /etc/motd に変更点を簡潔に まとめた注意書きを記し、そのコピーをすべてのユーサー とくに経営者に電子メールで送るべきである。経営者がコ ンピュータを使っていないのなら、ハードコピーで送れば 基本方針ファイルの変更の記録や日付などを残すには、 RCS や SCCS を使えばよい。これは簡単で、そのうえ変史 Daemons and Dragons ー朝 88 を実施したときに生しる揉めごとを回避できる。繰り返す ようだが、できるかぎり簡潔にまとめなければならない。 骨格がいったん定まれは、基本方針の作成や実施に必要な オーバーヘッドはごく少なくてすむ。うまく作れは、頻繁 に変史する必要もない。 もしそうした基本方針を作りたいのなら、誰か上手に策 定できる人を外部から招くべきである。できれは、コンピ ュータについて何も知らない人のほうがよい。すこし時間 がかかるかもしれないが、基本方針はおそらくより優れた ものになるであろう ( 私の父が修士論文を書いていたとき、 父は私を校正者に選んだ。当時、私は 10 歳だったが、父は 私が理解できないところはたぶん論旨が不明確なのだろう と考えて手を加えていた ) 。 方針は、やたらに長い文書にするより、指定されたディ レクトリの下に題目ごとのテキストファイルを用意したほ うがよい。そうすれは保守管理も楽になり、前述したよう なメニューからも呼び出せる。 たとえは、現時点では、我々のサイトでのディレクトリ の内容は次のようになっている。 サイズ 922 846 1455 5123 317 . 名前 /usr/10ca1/adm/P01icy/back /usr/10ca1/adm/P01icy/gen /usr/10ca1/adm/P01icy/10gins /usr/10ca1/adm/P01icy.org /usr/10ca1/adm/P01icy/usenet 大半のファイルは、小さくまとめられている。このなか でもっとも大きいものには、本のディレクトリ構成と各 ディレクトリの内容が記載されている。基本方針の全容を 把握しようとして戸惑うであろう新しいユーサーと、シス テムの構成を知りたい人にとって、これははありがたいも のである。 私が組織内の基本方針を文書化するのに要した時間は 2 時間であった ( 私はシステム管理者であると同時に経営 者およびマシンの所有者でもあるので、この部分にはあま り時間を費さすにすんだ ) 。シェルスクリプトを書くのに使 った時間は 45 分ほどで、合計しても 3 時間弱である。現 在、私が抱えているユーサ、一はシステムがどのように使わ れているか ( または使われていないか ) を、次のような基本 方針メニューの選択によって知ることができる。 UNIX MAGAZINE 1991.1

DAEM 〇 NS & DRAG 〇 NS 朝 システム管理の基本方針 •Bud Hovell 何が重要か ? Randy Kunkee 氏 (uunet!ficc!kunkee) は、米国南西 部の大規模なシステム・メーカーのシステム管理者である。 先日、彼はシステム管理のメーリングリストに次のような 質問を寄せた。 「私は、 Xenix および UNIX べースのシステム上に約 300 名のユーザーを抱える会社でサポート担当マネージャ ーを務めています。さて質問ですが、はかの大規模なサイ トのシステム管理者はニュースの投稿や署名の内容を管理 するためになんらかの対策を講しているのでしようか ? しつは、最近わが社ではニュースグルーフ。への投稿を控え ています。というのも、 部の社員が投稿するニ ュースの 内容がきわめて政治的かっ悪意に満ちたものだったので、 会社全体に悪影響を及はすと判断したからです。もちろん 私は無条件で言論の自由を支持しますが、経営者は会社が お金を払って参加している USENET のニュースサービ スにふさわしくない行為と考えています ( 私もこれには賛 成です ) 」 たしかに、世の中には自分の組織に悪影響を及はすこと などおかまいなく政治的な問題を口にしたり、人を不快 にさせるような意見の表明は、、権利〃であって、なんら罰 せられることはないと信している人が存在する。しかし、 結果的に決定された、、こと〃の細目よりも、管理者が、、い つ〃、、どのように〃この種の問題に直面するかという点のは うが大きな意味をもつであろう。したがって、それらの決 定がはかの組織の管理者の行動と合致しているか否かは 86 from UNIX REVIEW さほど重要ではない。 本当に問題なのは、通常、公式かっ首尾一貫した基本方 針は必要に迫られるまで立案されないという点である。ほ とんどの場合、経営者は危機的な状況が生しるまでこのよ うな基本方針の策定に直接関与することはない。だが、彼 らが実際に乗り出さなくてはユーサーのあいだに USENET に投稿してよいもの / 悪いものについての合意 は形成できない。 公式の基本方針 これまでにも、特定のサイトがあるユーサー ( もしくはあ るグループ ) を締め出すことで、いかにして米国西部の文化 を脅かしてきたかというテーマの大規模で激しい論争が USENET 上で交わされてきた。論議の対象となった事件 には、いすれも次のような特徴があった。経営者たちは、 なんらかの事態が生した後で、いわは後手に回った対策と して基本方針を定めているのである。結果的にいえば、こ れは経営の失敗である。 なぜ失敗なのか ? 答は簡単である。経営者は、組織の資 源 ( コンピュータによるサービスを含む ) を業務全体に役 立たせることに責任がある。したがって、意思決定が誤り や悪用によって損なわれないように保証すべきなのである。 いすれにせよ、これは経営者の仕事である。 各組織はそれぞれに固有の業務を遂行しているのだから、 業態の異なるはかの組織が遵守しているからといって USENET があらゆる組織に共通な規則を備えるべきだ というような稚拙な論理は排すべきである。実際にそれを 適用する場合、どのグループを支持するか、あるいはどの ューサーにどのような権利をえるかという決定は管理者 UNIX MÄGAZINE 1991.1

Daemons and Dragons 違反者を経営者より手厳しく審査するからである。 らったほうが効果的である。なぜなら、同僚のユーサーは あるよりも、同僚のユーサーに同等の立場から検討しても 輩格である経営者 ( またはあなた自身 ) が唯一の実行者で もっと大きな組織の場合、基本方針を実施するために先 く簡単な作業である。 削除、変史に応して拡張、縮小、変史される。これは、 このメニューは、私がファイル名や記述に施した追加や TO review a policy, type in subject : > usenet—requests for connection or q uit org—where we put things logins—responsibilities Of users gen—general overvlew back—who makes backups and when HOST 'WIZZ DIRECTORY OF LOCAL POLICY FOR [ 訂正 ] これまでの繰り返しになるが、あなたの作った基本方針 とめ UNIX MAGAZINE 1991.1 / sbin に入っているファイルは、 SunOS をプートするの を招くおそれが多分にあります。 せん。しかし、残念ながら SunOS を対象とした場合は誤解 UNIX の実装では必要であり、最悪の場合でも実害はありま いコマンドについて言及されています。これは、大半の この後、シングルューサー・モードで使えなけれは・ならな ( のみ ) が使えるわけである・・ まり、 / bin ( Sun の大半のシステムでは / sbin ) 上のファイル ・・シングルューサー・モードで作業することが多い。つ な記載がありました。 レードについて述べておられましたが、そのなかに次のよう い、復帰テスドについての記事で、ソフトウェアのアップグ 見であり、 Sun Microsystems を代表するものではない ) 。 重要な誤りがあるとの指摘があったにれは彼の個人的な意 号参照 ) のなかで、シングルューサー・モードに触れた部分に この連載の 12 回目の記事「復帰テスト」 ( 本誌 1990 年 10 月 読者の Grif Rosser 氏 (grif@Canada.Sun.Com/ から、 が次の条件を満たしていれは、おそらくなんの問題もなく 実施できるであろう。 ・ 10 歳の子どもにも理解できるくらい簡潔であること ・新聞や雑誌的なスタイル・言い回しで文書化されている ある ) ・官僚主義に陥らす、人間的であること ( ユーモアも必要で ・組織の業務に沿った機能的なものであること ・論理的に整がとれていること ・どこに何があるか誰もが知っていること きだった。ただし、これはソースがないと困難な仕事である。 るには、 -Bstatic で再リンクしなけれはならないと書くべ これらのコマンドを共有ライプラリなしに適正に実行す らです」 SunOS では実行可能な状態で動的にリンクされるものだか のも、コラムで推奨されているコマンドのいくつかは、 ならないと誤解するとかなり厄介なことになります。という mknod 、 mv 、 restore 、 tar などをインストールしなければ が彼らの Sun のマシンの /sbin に cat や fsck 、 ls 、 ifconfig 、 hostname 、 sh などが含まれているだけで、読者 に必要最低限のものだけなのです。 init や mount 、 UNIX REVIEW 1990 年 3 月号より 「 System-Administration Policies 」 く書かれたものである。 いるシステム管理のメーリングリストに送られてきた質間に答えるべ 回の記事は、 Bjorn Satdeva 氏 (bjorn@sysadmin.com/ が主宰して McCormick & Hovell lnc. の的辛管理および引画管理の専門荒今 ■ Bud Hovell ・経営陣 ( できればトップに立つ人 ) が正式に認めている 89 Rob Kolstad

MV ファミリーに新シリー ADG 育メインメモリは標準で 64MB 、 64MB 日本・データゼネラル ( Tel 03 ー 438 ー 9860 ) は、 CPU チップを 1 個から 4 個まで 単位で 256MB まで拡張できる。 搭載、 5 ~ 19Mips の処理能力をもっ MV 価格は、小規冓成で 5 , 338 万円から。 ファミリーの上位機種、、 MV / 30000 シリ 出荷開始は 1991 年 1 月。初年度販売目標 ーズ〃、 3Mips のデスクトップ下位機種 は 50 台 「 MV / 3500DC 」の販売を開始した。 ◆ MV/3500DC ◆ MV / 30000 シリーズ 15.9 x 48.9 x 41.3cm ( H x W x D ) の 3.3GB までの大容量記憶装置を接続でき デスクトップ型。メインメモリは標準で 同社の CPU WASHI を 1 ~ 4 個使用す る。 8MB ( 最大 16MB)0 端末は、最大で 40 回 る 4 機種から構成される。ラックマウント 価格は、小規期冓成で 757 万円から。出 型で I / O プロセッサを 4 枚まで、 I / O イン 線まで接続できる。複数の通信回線を、同 荷開始は 1991 年 1 月。初年度販売目標は 時に複数のプロトコルで利用可能。また、 ターフェイス・ポードを 10 枚まで実装可 200 台。 開発セットと機能ごとに細分化した PC- 98 用 OpenDesktop UX / V ( Re13.2 ) 関連ソフトウェア 7 種が ある。 •NEC LM/X サーバーは、 MS-DOS 、 OS/2 日本電気と日本電気ホームエレクトロニ (The Santa Cruz Operation) の OS を および OpenDesktop システムでファイ はしめて日本語化したもの。 SystemV クス (Tel 03 ー 452 ー 8000 ) は、 PC98 用の ルやプリンタを共有するためのソフトウェ UNIX/ ウインドウ環境「日本語 Open- R3.2 をベースとして、 GUI やネットワー ア。 Desktop 」および「 LM/X サーバー」の販 ク機能などを統合している。 GUI は、日本 語化した OSF/Mtoif 、 X. Desktop をサ 売を開始した。 ネットワーク対応パックアップ / 日本語 OpenDesktop は、米 SCO ポートしている。基本セット、サーバー リカバリー・ソフトウェア •DTC ◆ PC-UX/V (Re13.2 ) 価格表 デジタルテクノロジー (Tel 03 ー 847 ー 名称 販売価格 アフ・リケーション・ソフトウェアを実行するための PC-UX/V(Re13.2) 200 , 000 円 4801 ) は、米 Legate Systems が開発した 基本ソフトウェア 日本語 OpenDesktop 基本セット 自重ルヾックアップ / リカバリー・ソフトウェ PC-UX/V(Re13.2) ー機能、 3 ューザー以上のマルチュー NFS のサー 200 , 000 円 ザー機能を提供 日本語 OpenDesktop サーパー ア「 NetWorker. 」の国内独占販売権を取 アフ・リケーション・ソフトウェア開発のための C 、ラ PC-UX/V(Re13.2) 300 , 000 円 得、販売を開始した。 イプラリなどを提供 日本語 OpenDesktop 開発セット PC-UX/V(Re13.2) 日本語 OpenDesktop 、日本語 MS-DOS 、日本語 MS 350 , 000 円 クライアント / サーバー・アーキテクチャ LM/X サーパー OS / 2 のンステム間でファイルやフ・リンタを共有す るための機能を提供 と TCP/IP プロトコルを採用。サーバー UNIX SVR3.2 に準拠の日本語アフ。リケーシ - ョン・ PC-UX/V(Re13.2) 180 , 000 円 はテーブドライプをもつ Sun のマシン、ク 基本セット インターフェイス (API) を装備した OS PC-UX/V(Re13.2) PC-UX/V(Re13.2) 基本セットでほかのシステムと ライアントとして Sun, DEC(UItrix) 、 60 , 000 円 TCP/IP 実行環境セット TCP / IP が実行できる通信ノフト HP 、 MIPS 、 Solbourne 、 IBM PC およ PC-UX/V(Re13.2) 基本セットで X11.4 に対応する PC-UX/V(Re13.2) 80 , 000 円 X Ⅵ′ indow 実行環境セット とともに、 OSF/Motif および X. Desktop の実行機 び互換機 (PC-DOS 、 TCP/IP 、 NFS をサ 能を装備したソフトウェア ポート ) が利用できる。ネットワーク fl のバ PC-UX/V(Re13.2) PC-UX/V(Re13.2) 基本セットで NFS のサー . , く 55 , 000 円 クライアント機能を提供するソフトウェア NFS ックアップおよびリカバリー作業を save 、 PC-UX/V(Re13.2) 基本セッドでフ・ログラムを開発 PC-UX/V(Re13.2) 70 , 000 円 プログラム開発セット するためのソフトウェア recover などの単一のコマンドで操作可 PC-UX/V(Re13.2) PC-UX/V(Re13.2) 基本セットで X や OSF/Motif 80 , 000 円 能で、 SunView 上のユーサー・インターフ 対応のフ。ログラムを開発するためのソフトウェア X Ⅵ ndow 開発セット PC-UX/V(Re13.2) PC-UX/V(Re13.2) 基本セットで TCP/IP を使用し 70 , 000 円 ェイスもある。また、 cron の利用も可能。 TCP/IP 開発セット たフ・ログラムを開発するためのソフトウェア サーバーマシンのディスク _E にファイル ※出荷は 1991 年 2 月下旬、たたし LM / X サーパーは 1991 年 4 月下旬 2 UNIX MAGAZINE 1991.1

連載 An lntroduction to X Window System X の認証メカニズム % X10g0 -display achira: 0 xhost の設定では、たとえサーバーの利用者本人であっ / ' ーバーの利用が可能となるものです。 に際して鍵を要求し、適切な鍵の呈示があってはしめてサ なわれました。これは、クライアントがウインドウの利用 これに加えて新たに認証のためのプロトコルの実装がおこ よる利用制限のみが提供されていました。 X11R4 からは、 X11R3 までは、前回説明した xhost によるホスト名に 、、、ても登録のないコンピュータ上で起動されたクライアント は受け付けませんでした。しかし、繰り返しになりますが、 xhost に登録されていさえすれば誰が起動したクライアン トであろうと受け付けられてしまいます。 X11R4 て導入された認証のためのプロトコルを用いれ ば、適切な鍵を示せばどのコンピュータからでも利用でき るようになります。一方、たとえそのコンピュータの利用 権があっても、鍵が示されないかぎりウインドウの利用は 許されません。このようなクライアントが鍵をもたすに利 用しようとすると、 XIib : comection to "achira: 0.0 " refused by server X1ib : C1ient is not authorized tO connect tO Server Error: Can 't Open display とま色されます。 鍵の実体はファイルに収められたサー ごとのデータ で、このデータには暗号イヒの方法とデータが収められてい ます。鍵がファイルの形態になっているのは、コマンドの 引数で直接鍵のデータを渡すと ps コマンドで覗かれてし まうからです。また、各クライアントが用いる X の基本ラ イプラリ ( Xlib ) にはこの認証のための仕組みが組み込ま れており、鍵となるファイルを適切な名前で用意すれば自 動的にこの認証の手続きが実行されます。したがって、 の鍵となるファイルを用意するか、場合によってはあらか しめ用意された鍵となるファイルの内容を適切に更新する だけで利用できます。 別の見方をすれば、鍵の管理は UNIX のファイル管理 に委ねられているといえるでしよう。ですから、鍵の入っ たファイルを誰にでも見せるようでは無意味になってしま うわけです。そこで、鍵を扱うためのプログラム (xauth) は、個々のユーサーの所有になり、かっ所有者だけカ売み 書きできる設定でファイルを作成するようになっています。 また、ネットワーク上で 1 つの鍵ファイルをあちこちから 同時に更新する場合に備えて、ファイルロックの機構も用 意されています。 ふんふん、なるほど便利だけれど R3 以前のクライアン トの混在に対しては・・・・クと心配される向きには、 xhost の 設定があれは従来どおりホスト名によってのみ利用許可 が出るようになっています。 UNIX MAGAZINE 1991.1 鍵となるファイルの設定 定しなくてもかまいません。注意すべき点としては、以下 れる形式と同しです。ただし、スクリーン番号はとくに指 サーバー名は、基本的には -display オプションで用いら プロトコル、および鍵データが必要です。 登録には、対象となるサーバー名、鍵を暗号化して送る 認証の登録 は、基本的なコマンドの利用について説明しましよう。 です。コマンドには、表 1 に示すものがあります。ここで % xauth コマンドコマンド引数コマンド引数・ 一般的な利用法は、 のオプションをつけて xauth を起動します。 とは別のファイルを指定したいときは、、、一 f ファイル名ク ていればそこで指定されたファイルが使われます。これら で作られます。また、環境変数 XAUTHORITY が設定され ーサーのホームディレクトリに、、 . Xau 出 ority 〃という名前 とくに指定しないかぎり、認証のためのファイルは各ユ ますので、 X の環境外でも実行できます。 X のサーバーを介することなく対象ファイルを直孑欝作し 容を確認するためのプログラムが xauth です。 xauth は、 X の認証を扱うための鍵ファイルを設定したり、設定内 の 2 つがあります。 143

emacs 入門 This front end uses the ト旧 ma11 system, which uses different conventions lnc(orporate) new m 1 ()o arg) or scan a 忸 { ma-ll box (arg given) ・ (autoload ー ma 土 1 " 1 ー e " 図 28 loaddefs. el の一部 from the usua1 ma11 system 3 t) (autoload 'mh-smail 'tmh—e'l Send mall using the { mail system. t) M—x load—library ( 亘ー Load library: mh—e LOADING mh—e . e1. . . done サーチパスではなく、 Nemacs が独自に覚えているもので 込みます。ただし、この、、サーチパス〃は shell コマンドの ファイルを探し、 mh ー e. e18 があればそのプログラムを読み とします。このとき、 Nemacs はサーチパスにしたがって ・ Nemacs の変数 (load-path) に決まりますが、 ・ Nemacs のコンノヾイノレ時 す。これの設定は基本的には、 サーチパスに入っていないファイルをロードしたいとき によって変更することもできます。 ・ shell の環境変数 (EMACSLOADPATH) とします。 LOADING mh—e . el . . done Load file : &/emacs/lisp/mh-e M—x load—flle 〔 0 ー /emacs/lisp" ディレクトリの下にあるなら、 にはヨ oad ー fi 厄を使ってください。たとえば、 mh-e. el が . el UNIX MAGAZINE 1991.1 8 m ト e. el の代わりに mh ー e. elc のこともあります。 ンストールされていることが大前提ですが。 でしよう。もちろん、 MH の基本的なコマンドがすでにイ ログラムさえ手に入れれば mh ー e コマンドを実行できる きるので、 mh ー e の環境が設定されていないサイトでも、プ この方法なら、ファイルの糸寸パスを指定することがで コマンドの登録とオートロード もう一度、 Nemacs を起動してみましよう。起動したば かりの状態で、 M-x mh(SÉCJ load-file コマンドを実行するのは面倒だな〃と思っている 読者のサイトで mh-e をサポートしておらす、ヾ毎回、 ァイルをロードするように指定しています。 または mh-smail コマンドが実行されたら $mh-e. e1″フ すべきファイルを指定する関数です。ここでは mh-rmail autoload は、あるコマンドが実行されたときにロード 数名です。 て、、、 ( 〃の直後の文字列 ( ここでは autoload) が Lisp の関 ( ) で囲まれた部分は 1 つの Lisp の関数の実行を表してい 分で mh-rmail と mh-smail を定義しています。丸括弧 図 28 は私の使っている loaddefs. el の一部で、この部 があるはすです。 に、 mh-rmail あるいは mh-smail とⅱ当丕されている部分 プログラム、、 loaddefs . el" を探してみてください。どこか はすでに mh ー e が使えるように変更されています。 Lisp もし、同しような状態なら、あなたのサイトの Nemacs だってまだ実行していないのに をなぜ Nemacs が知っているんだろう ? load-library でも待てよ、あとから付け加えたプログラムのコマンド が表示されたでしようか。 mh-smail mh-rmail を知ることができます。 2 つのコマンド、 とすれは、、、 mh ー〃で始まるどのようなコマンドがあるのか 127

00 飛 e ー e ・高桑昌男著 ・アスキー ・ A5 判、 9 ページ ・し 800 円 CG レイトレ物語 ℃ G レイトレ物語→ この本のタイトルにある、、レイトレ〃とは、コンピュ ータ・グラフィックスでのレンダリング ( 画像生成 ) の方 法の 1 つ、、レイトレーシン 7(ray-tracing: 光線追跡 法 ) 〃を略したものである。このレイトレーシングは、と くに写実的なにの世界ではそのままカタカナで、、フォト リアリスティック〃などとも呼ばれる ) 表現をするのによ く使われている。 その基本的なアルゴリズムは、視線と物体表面、そし て光源への光線を追跡し、スクリーン上の画素の色を決 定するという比申知勺単純なものである。しかし、本来は 単純なアルゴリズムでありながら、計算コストがかかる という欠点があった。そのため、計算コスト軽減を目的 とした高速化や扱える曲面や形状の不頁を増加させたた め、アルゴリズムも複雑化、肥大化の一途をたどってき た。革命的なアイデアが出なくなったという意味におい ては、著者が述べているようにレイトレーシングはすで に、、渇れた〃技術であるかもしれない。もっとも、一方 では今なお新しい技術が発表され続けている。このよう な状況でレイトレーシングの本像を擱むのはなかなか 困難だが、本書はその概要を分かりやすく、そしてある 程渡醒めた目でまとめてあるのでありがたい。 目冫冓成は、 1 レイトレーシングあれこれ 2 章交差判定 3 マッピング 4 シェーディング 5 ェリアシング 6 CSG UNIX MAGAZINE 1991.1 7 章オプジェクテイプ・レイトレーシング 8 章その他のレイトレーシング 9 章おまけのラジオシティ法 となっていていかにも教科書ふうであるが、内容は読み 物としても読めるようになっている。 著者は、写実的な表現だけが CG の究極の目的ではな いという立場をとりながらも、タイトルにあるようにあ くまで物語ふうに各種の去ーーそれもかなり新しいも のまで含めて分かりやすく紹介している。たとえは、各 種シェーディング、エリアシング、マッピング、メタポ ール、オプジェクテイプ・レイトレーシング、逆方向レ イトレーシング、 CSG などといった頻出するキーワード の概略とその限界や間題点などが要領よくまとめられて いる。まえがきにも記されているように、もともと教科 書として書かれたわけではないようだが、そのかいあっ て ( ? ) やさしく噛み砕いた説明は教科書では途中で挫 けてしまいそうな箇所でも先へ読み進ませる力がある。 レンダリング方程式など、いきなり、、天ードり式〃にい くっかの数式が飛び出す部分もあるが、それらの導出や 簡略化の説明などは本書の目的とするところではなく、 それらを読み飛ばしてもおおよその意味は汲みとれる。 巻末に掲げられている豊富な参考文献のリストも便利 である。ただし、 1987 年に刊行されたものまでしか挙げ られておらす、本文中に記載のある新しい動向を反映し たものが欠けている点が残念である。 ÅSCII 坂本文著『たのしい UN Ⅸ ・ A5 判、 368 ページ ・定価 L900 円 (ASTEC 長谷川均 ) UN Ⅸへの招待 本誌に好評連載中の「 UN Ⅸへの招待」の前半部が単行本に なりました。ⅵをはしめ、著者が愛用する数々の道具ー UNIX コマンドについて、使い方だけではなくその背景にある、、考 え方〃も懇切丁寧に説明しています。 105

UNIX REVIEW 誌提携 MAGAZINE CONTENTS 91 / 1 UNiX タイトルページ てくてく TEX パイプライン UNIX 流フログラミング MH NemacsX 門 on 入門 ( 2 ) LittIe Language システム里の方針 Daemons&Dragons AWL FreeSoftware の世界 mwm(3) OSF/Motif のすべて ネットワーク・アプリケーション ( 5 ) UNIX Communication N0tes 連載 news & notice マジカル・ミステリー・ツアーいたしましょ・ ワークステーションのおと 標準化動向 ・ Co ん m 蠅 雑誌から見た最近の IJ N Ⅸ市場動向 ワークステーション・ガイド SPARCstation SLC 2 ) jus シンホジウム報告 製品評価 :Nexpert Object ・ INTEROP'90 ■ Notice •News HP SoftBench 環境 . HP EncapsuIator シェルプログラミング ( 6 ) UN Ⅸへの招待 X のセキュリティ An lntroduction tO X Window System 表紙デサイン・甲斐みどり / 表紙写真・守屋ー於 BOOKS JUNET 便り 1991 年 1 月号 目 ・・齊藤明紀・山口英 ・・久保山正文 ・・ P. D. StaIImen ・ Bud H ovell ・ srekcah @sra. CO. JP 次 38 50 71 86 90 1 1 1 ・・荒井美千子 ・・今泉貴史 130 ・・藤浦はる美 135 142 ・・中村眞 ・坂本文 ・ Brian D. Fromme ・・山口英 ・ Dan iel W. Rasmus ・・今泉貴史、権藤克彦 ・・武藤多恵子 ・ Shane McCarron ・・坂下秀 ・・竹岡尚一 ・・みるく 147 55 1 13 21 25 28 12 79 82 99 106 105

標準化動向ー① ている人も多い。いすれにせよ、この 2 つの通信手段のお かげで、移植性とインターオペラビリティという夢の実現 に近づいたことに間違いはない。 それぞれのオープンシステム システムペンダー インターオペラビリティと移植性はオープンシステムに 欠かせない要素だが、ところでオープンシステムとはそも そも何なのだろう ? その意味の捉え方は、人によって異な る。理念のうえでは、異なった分野の個人の集団がアプリ ケーション開発のための確固とした基盤を提供することに よって多くのアプリケーション開発者を引き寄せ、その結 果自分や競合者にとってより有利な市場を作り出せる能力 であるといえよう。これらのシステムペンダーは、企業間 競争の激化は避けれられないものの、同時にそれが自分た ちにとっても有利に働くと考えている。さらに、そのこと で開放化への流れを無視する競合者に不利な条件が作り出 せるとも判断しているのである。 だが、理念だけでは食べていけない。小さなシステムペ ンダーはより現実的な視点に立ち、オープンシステムによ ってアプリケーション開発者を特別に引き寄せることはで きなくても、それは市場に喰い込むための手段であると考 えている。ソフトウェア基盤カ寉固としたものになるより も前に市場がオープンシステムを求めるということは、 の流れのなかから生した予期せぬ利益であった。以前から オープンシステムを主張してきた自分たちのビジョンが、 業界にとっても正しい方針であることが証明されたわけで ある。ビジョンの正当性以 - E に重要なのは、オープンシス テムによってシステムペンダーたちはより広範な市場に自 分たちのシステムを売り込めるようになったということな すなわち、オープンシステムの標準が保証する高いレベル の移植性とインターオペラビリティという公約が果たされ たことになる。 営業活動に携る人びとにとって、オープンシステムとい う言葉は見込みのありそうな顧客を納得させる道具である 場合が多い。熱心な販売担当者から、「オープンシステムを サポートしています」という言葉を 1 度ならす聞かされた ことのある人も多いだろう。また、ユーザー側でもそうし 80 た言葉を期待しているのだ。ことの真偽はともかくとして、 そうした言葉の使われ方は、、販売〃というマーケティング 上の寄せ餌ともなっている。残念ながら、オープンシステ ムとは営業マンにとっても同様に曖昧な意味しかもたない ものなのかもしれない。 大半の主要な専有型システムのべンダーは、当初、オー プンシステムを邪道と考えていた。工ンドユーサーがオー プンシステムに吸い寄せられている今日では風向きが変わ り、彼らもそれを支援するか、あるいは屈服するか、もし くは支配しようとする方向に方針を転換している。さいわ い、標準化のプロセスは、それを意のままに操ろうとして も正々堂々とおこなわないかぎり不可能な仕組みになって いるので、今のところべンダーによるそうした試みは抑止 されている。今日、かっての専有型システムの大手べンダ ーが、オープンシステムの過程に正々堂々としかも精力的 にかかわっていることがみてとれる。それはかりか、独自 システムを犧牲にしてもオープンシステムを生み出そうと していることが多い。 アプリケーション開発者の場合、オープンシステムをめ ぐる動きはスローベースである。それには「卵が先か、 ワトリが先か」という古くからの問題がある。つまり、開 発者は売れないプラットフォーム向けのソフトウェアを書 きたいとは考えないし、そのプラットフォームはソフトウ ェアなしでは売れないのである。これまで、多くの大手ソ フトウェア開発者は、業界の分裂状態から利益を得てきた。 システムペンダーは評判の高いソフトウェアを新しいプ ラットフォームに移植するために、かなりの金額を彼らに 支払ってきたのである。プラットフォームカ昿範に利用で きるようになるにつれ、互換性の欠如から利益を得てきた これらの企業は収入源を失いつつある。 しかし、移植収入の減少は、広範なシステム上で利用で きるソースコードの入手による利益と十分に相殺できるは すだ。この場合、すこしでも理念に沿った正しい方針が勝 ちをおさめそうである。つまり、より移植性に優れたアプ リケーションが開発されるということだ。このアプリケー ションのべースは、やがて市場を支えるために必要な臨界 工ンドユーザー 点に達するであろう。 次にエンドユーサーがいる ( 顧客をユーザーと呼ぶ業界 UNIX MAGAZINE 1991.1