Unix システムは，我々とはまったく異なる世界に住んでいる人々の手によって70年代に設計，開発されたものであるが，低迷してきている．Unix はなかなか高品質だったこともあり，我々を回り道させてきた．しかし，Unix における問題はますます明白になってきており，我々の発展を妨げている．よい意味で厳しく Unix を見つめ，何がおかしいのかを認識し，それを修正するときが来た．この記事において，私は我々フリーソフトウェア界が直面しなければならないいくつかの問題について述べ，GNOME プロジェクトが取り組もうとしている方法について議論する．
オタワ Linux シンポジウム[訳1]における最近の発表を，Unix は最悪だという話から始めた．これは Unix におけるコードの再利用，一貫性，ユーザビリティに関する数々の問題を解決するために取り組んでいる GNOME プロジェクトにおいて，我々のビジョンを紹介するのによい殺し文句だと思ったからである．これは GNOME プロジェクトのビジョンであり，私の講演の主題だった．
私はオタワ Linux シンポジウムに出席していたフリーソフトウェアコミュニティのソフトウェア開発者に語りかけた．私の講演は Unix の多くの欠点をさらけだして，どうすればこれらの問題に取り組むことができるかという具体的な提案を示すようになっていた．このビジョンの実現を手助けしてくれる開発者に要求を伝えることが狙いだった．
私は白熱した聴衆に語りかけていた．それは面白い講演だった．私は聴衆が講演を楽しんでくれたことを望んでいる．その講演は，残念なことに一つの殺し文句「Unix は最悪だ」だけではなく，主な三つの段落の要約でも十分に表せるものではない．
Slashdot と LWN への投稿の後，代替オペレーティングシステムに関する大量のメールを受け取った．私の講演での説明は完全に不正確であった．たしかに Unix は現存する最高のシステムではないが，我々はこの問題を修正するつもりである．私の講演の意図は人々に何が間違っているか認識させ，このような問題に取り組んでいる GNOME プロジェクトにおいて，我々が持っている共通したビジョンを伝えることだった．
この講演の内容は Usenix での発表について考えている間に，Nat[訳2] と一緒に企てた．この講演の準備を手伝ってくれた Nat に深く感謝したい．
いくつかのオペレーティングシステム(Plan9，BeOS，Windows NT，MacOS X)は「マシだ」と提案してくれた人々がいた．そして彼らは「それほど Unix を嫌うなら，それらを使えばいい」と言ってきた．しかし，私の講演の目的は Unix の問題に光を照らすことであり，その問題に取り組むための具体的な解決案を示すことであった．私は主に GNU/Linux や BSD ファミリのようなフリー Unix システムに関心を持っている．
この文書では Free Software Foundation で使われてる文脈での「フリー」という言葉を使っている．詳細は次のページから読むことができる．http://www.gnu.org/philosophy/free-sw.html
GNU プロジェクトの一部として，我々はフリーソフトウェアを人々にもたらそうとしている．我々は伝統的なソフトウェア会社があなたに認めようとしてこなかった多くの自由を与えようとしている．
3年前の GNU と Linux の状態は「素晴らしいフリー Unix の実装」の一つだった．我々は Unix と同じくらい強力で，ユーザフレンドリなシステムを手に入れた．
GNU と GNOME プロジェクトの目的は，できるだけ多くの人々にこのソフトウェアをもたらし，自由を与えることである．これは使いやすく，直観的で，魅力的で，エンドユーザに対して「正しい」と感じさせるソフトウェアを提供することを意味する．大多数の人々がエンドユーザなので，エンドユーザは重要である．
混乱しないでほしい．大多数の人々はプログラミングするためでも，どうやって nroff を使うかを学ぶためでも，Web サーバを動かすためにでもコンピュータを使うのではない．大多数の人々は自分たちの生活を楽にするためか，人々とコミュニケートするためか，仕事をさせるためか，楽しむためにコンピュータを使う．
我々の仕事は技術のための技術ではなく，人々にフリーな技術をもたらすことである．
Unix は非常に強力な基盤である．それはすでに存在し，我々は完全に新しいシステムを再発明する代わりに，その上に構築することができる．
Unix は 70年代に設計され，広範囲にわたって非常に興味深い概念的特徴を含んでいた．Unixは設計された当時において，我々がオペレーティングシステムについて考える方法についての新しい標準として明確に設定されたものである．それは大きな成果である．
だからといって，我々が Unix 上で展開した現在の抽象化は十分であり，不足はなく，まったく素晴らしい思うことは愚かだろう．
次の 10年，Unix は今備えているものだけでもうまくやっていけるとか，30年前に設計されたすべての基盤となる部品は十分であり，基盤を賢くさせるような作業は必要なく，新しいアプリケーションが要求されているだけであると思うことは愚かだろう．
我々はデスクトップ環境と生産的なアプリケーション群を作る作業を行っており，この過程を通し，我々は他のシステム(まさに Unix が存在しなくても)で利用可能な数々の技術を発見してきた．そして，これらを提供するための努力をしていない．
3年前の Unix を思い出してみよう
より規模の大きい Unix アプリケーションにおいてほどんどコード再利用が起こらず，そして，人々がアーキテクチャ的に影響のない，非常に小さな改善に集中していたことが，Unix を低迷させたと我々は信じている．
まれに Unix の主要なサブシステムが再設計されたケースがあったが，これらの再設計はプロプライエタリな拡張に留まった．これは大局的に見れば意味はなかった．例えば，Display Postscript について考えてみよう．フリーな実装が存在しなかったため，今日でも標準的なフリーシステムの一部になっていない．プロプライエタリな革新は我々には何の意味もない．
そして，我々はすべてが共通のコードベース，つまりオープンソースコードベースで作業する場合にだけ，Unix 界における革新がやってくると信じている．ひも付のソフトウェアは，ソフトウェアの部品として単に採用されなくなるだろう．
Unix を競争的に保つために新しいソフトウェアを生産する方向へ働いていたいくつかのフリーソフトウェアの努力は協調動作しておらず，かろうじていくらかの標準と相互互換機能を持っている．
様々なウィンドウマネージャとそれらを設定している言語を考えてみよ．Unix におけるいろいろなプログラミング言語を考えてみよ．Unix におけるいろいろなキラーアプリケーションを考えてみよ．誰もまったくコードを共有してこなかった．
UNIX カーネルにおいて，伝統的に実装ポリシは存在しない．このアプローチと哲学は全 UNIX システムに浸透している．
例えば，X-Windows[1] でさえ，すべてのポリシを確立することを避けている．
結局，我々が得ることになったのは，究極のプラグ可能なシステムであり，究極の「あなたが好きに書ける」オペレーティングシステムである．
開発者達は考え得るすべての作業のために，考え得るすべての背景を持った，考え得るすべてのユーザを満足させようとして，すべてをオプション機能にしてしまう．結局，何も標準化せず，ポリシをアプリケーションに任せている．
個々のアプリケーションにポリシを任せることは，各アプリケーションがそのポリシ，ユーザインタフェース，設定ファイル，それ自身の方法を決定することを意味するという問題がある．
これはグラフィックアプリケーションでの完全な一貫性の欠如に至る．それは単にツールキットフラグメンテーションの問題ではない．あなたが Motif アプリケーションを比較するとしても，一般にオペレーティングシステム，ユーザプリファレンス，環境を扱うとき，根本的に異なる振舞いをすることがわかるだろう．
もちろん，統合環境を持つことの対価として，究極のプラグアンドプレイシステムを持つことなる．
今日，Unix は時代遅れで緩やかに結合されたツールの集合である．その結果，ユーザにとっては極めて低品質な思いをすることになる．
過去にはほとんどコード共有が起こらなかった．この問題には次に示すような様々な理由が考えられる．
GNOME プロジェクトにおいて，我々は異なるアプローチをとった．GNOME プロジェクトにおいて，
我々は現代的なアプリケーションの様々な要求に取り組むライブラリを作っており，開発者がこれらのライブラリを使うことを勧めている．これらのライブラリを使うことによって，あなたは基本的に我々がすでに書いたコードを書くことを避けることができる．そして，よりよいことは我々がそのライブラリを改善したとき，あなたのアプリケーションも同様に改善されることである．
私は他のオペレーティングシステムの悪い点と Unix のよい点を比較することによって Unix の偉大さを死守している人々に何度も出会って来た．以前，私自身もそうだった．
ここに次のような共通の問題がある．人々は彼らにとって大事なものになると，利点に集中して，欠点を無視する．さらに悪いことに，別の競合相手と比較するとき，彼らはその弱点に集中して，利点を無視する．
このようにものごとを見るアプローチの問題は，結局，競争相手があなたに追い付くことである．これをあなたが理解したとき，彼らはすでにあなたの機能を獲得しており，あなたは彼らの何も獲得していないことになる．
そういうわけで，あまりに遅くなる前に，自己批判のアプローチを保持するように改善することは非常に重要である．
例えば，私は Linux が始まったころの栄光の日々を思い出す．Win 3.1 対 Linux 1.0 の比較は，常に毎回 Linux の勝ちで終った．我々はマルチタスク OS，一種の高信頼システム，よいネットワーク抽象化，やや遅いウィンドウシステム(まぁとは言うものの，誰が X を使ったんだろう? 我々はまさにテキストコンソールを望んでいた．)を持っており，我々のマシンの外で Web サーバなどを動かすことができた．我々は Windows (それが，マルチタスクシステムを持っていなかったので)が決してなし得なかったことを実現できていた．
それから Windows95，そして Windows NT が登場した．現在，それらのシステムは我々に追いついていた．もちろん信頼性に関してはまだ貧弱だが，彼らのユーザインタフェースはよい(そして我々に欠けていたものである)，そしてアプリケーションを持っている(これらも我々に欠けていた)．
そして Windows 2000 がリリースされた．確かにまだクラッシュはするが，あらゆるリリースよりもよくなっており，ユーザに対してそれほど大きな影響を与えなくなりつつある．
訓練されていない目には，このときに起きたこれらのオペレーティングシステムのコアに対する大きな刷新は知られていない．元々，他の問題を解決するために開発されていた COM コンポーネントアーキテクチャが，ソフトウェア開発にとってのスケーラビリティ問題からコード再利用や一貫性に対する多くの問題に対する非常によい一般的な解であるとわかってきたのだ[2]．
我々はプロプライエタリの商品より10倍よいシステムをもたらすことができるだろうか? 私はそうすべきだと考えている．
私はフリーソフトウェアが現在の形態で成功するだろうとは思わない．今日のユーザに対するニーズに取り組むためには，多くの仕事が必要である．
これは人々の生活をより楽にするためのソフトウェアであることを忘れるな．
ソフトウェアは人々の問題を解決するために書かれる．我々はソフトウェアが人々のニーズに適応するようにこそ設計すべきである．
Unix はその設計の簡潔さにもかかわらず複雑なシステムである．しかし，エンドユーザのために用意されているシステムではない．そして，これが GNOME プロジェクトが既存の Unix 基盤の上で構築しようとしていることである．[訳4]
あなたがアプリケーションを開発するとき，エンドユーザのことを心に置きなさい．
この記事の残りで，私は Unix が現在取り組んでいない，もしくは非常に貧弱なソフトウェア問題のいくつかの具体例について述べる．そして，GNOME プロジェクトがこれらの問題をどのように解決しようとしているかを示す．
Brad Cox は再利用可能なソフトウェア部品であるソフトウェア集積回路(ソフトウェア IC)のコンセプトを押している．彼の考えの核心は，ハードウェア屋が様々な方式でコンポーネントを素早く再利用することができる再利用可能なコンポーネント機構(集積回路)をなんとか開発してきたことにある．
TTL マニュアルを持ったどんな電子工学科の学生でも，すぐにコンポーネントを再利用し始め，かなり驚くべきものを組み立てることができる．
この問題に対して Brad Cox の提案した解答は，オブジェクト指向プログラミング，具体的には Objective-C 言語であった[訳5]．
オブジェクト指向プログラミングは，コードを再利用するすばらしい手段であり，部品を抜き差しするすばらしい手段である．オブジェクトが世界または「インタフェース」への契約を維持するならば，そのコードのユーザはインタフェースが変わらない限りこのオブジェクトを使うことができることを知っている．
一つ実用上の問題がある．オブジェクトは一般的に OOP 可能なプログラミング言語によって実装され，これらのオブジェクトはそのプログラミング言語にだけ(インタフェースを)公開される．(たとえ他の言語に公開できるとしても，これは一般的にあまり単純ではなく，実際にはほとんどなされない．)
あなたが Perl で HTML パーザのすばらしい実装を作ったとしたら，専門的な離れ技をすることなく，Python，C++，C から直接使いたいと思うだろう．
オブジェクトは偉大なプログラミングツールであるが，すべての問題が解けるわけではない．まだコードの複製がたくさんある．(演習: HTTP ハンドラ，上記の言語のための XML パーザを探せ)
様々な人々は Unix 哲学は小さなプログラムが本当に一つのことを，そうたった一つのことを実行することであると主張する．これらの個々のコンポーネントは共に組合せ，より複雑なアプリケーションを作ることができる．
その考えは個々のコンポーネントは独立して作られ，パイプを介して接続され，テキストデータがそれらのコンポーネント間で交換され，リッチなシステムを作ることである．
これらの再利用可能な Unix コンポーネントのインタフェースは，fork/exec，コマンドライン引数，環境変数の設定，入出力ストリームである．
Unix フィルタは型のないストリームを扱う．そのツールは各文字，各行，または全バッファを処理することにより動作する．
例えば，あなたが XML と HTML に精通しているならば，HTML を越える XML の大きな利点の一つが情報にコンテキストをタグ付けできることであることであり，それが情報をリッチにすることができることを知っているだろう．もはやテキストのためにフォーマッティングコマンドを記述したファイルを扱う必要がなく，その代わりに高いレベルでテキストを操作できる．タグ付けされたデータを扱い，タグ付きデータはデータに関してより多くのことを知ることができるというように．
また，パイプラインはこのように見える:
command | filter1 | filter2
情報は，command から filter1 に，そして最終的に filter2 に流れる．filter2 にとって command や filter1 と通信したり，相互作用する方法はない．
パイプは Unix における非常に強力なコンセプトではあるが，コンポーネントからアプリケーションを作成するための最終解答ではない．次に証拠を示そう．[訳6]
サーバ空間におけるもっとも人気のある Linux アプリケーション(Samba，Apache，NFSD，innd，sendmail，in.named，ftpd そして ssh)を調べてみよう．
これらのアプリケーションを調査すれば，それらのタスクを実行するためにいくつかの Unix 「コンポーネント」をかろうじて「使っている」ことに気付くだろう．しかし，再利用されていたとしても，偶然の副作用であることが多い．
それよりも悪いのは，これらのアプリケーションが UNIX libc 以外のいなかるコードも共有していない事実である．あなたはこれらのデーモンがいくらかのコードを共有していると考えるだろう．例えば，タイムアウトハンドリング，メインループ統合，アイドルハンドラ，デーモン化ルーチン，設定解析ルーチン，セキュリティライブラリ，不正利用防止ルーチンなど．
しかし，そうなってはいない．もっとも基本的な Unix サービス以外は，まったくコードを共有していないのだ．本当にまったく何も．[訳7]
様々な人々は Microsoft を「大きくなりすぎたモノリシックアプリケーション」を生産する理由で批判することが好きである．我々が Microsoft を批判する前に，GNOME の外側にある Unix 上のエンドユーザアプリケーション(Netscape，GhostView，XDVI，Acrobat，Mathematica，Maple，Purify，FrameMaker，Star Office)を見てみなさい．
これらのアプリケーションの共通項は libc と xlib だけである．いくつかは Motif も共有しているが，それくらいがコード共有の限度である．そして，もちろん Unix 「コンポーネント」はこの要因において何の役割も演じていない．それらは基本的に使われることはない．(私にはプリンタスプーラデーモンで使われていると思い付くぐらいである．そして，この場合においてさえもオペレーティングシステムを横断する互換性がない．)
今，再び Microsoft の「大きくなりすぎたモノリシックアプリケーション」である「Internet Explorer」を見てみよう．
Internet Explorer はあなたが考えるかもしれないように単一の実行可能モジュールではない．Internet Explorer は COM コンポーネントの集合から作られる．これらのコンポーネントは個々に開発，デバッグ，公開され，結局，すべては統合化アプリケーションの幻想を作っている．
現在，これの美徳はこれらのコンポーネントが Internet Explorer 外部で再利用できることである．Microsoft 以外のプログラマは彼らのアプリケーションでこれらのコンポーネント(HTML レンダリングエンジン，XML エンジン，JavaScript エンジン，ツールバー，彼らのスクリプティングエンジンなど)を使うことができる．
Microsoft アプリケーションは Internet Explorer の部品を再利用する．
確かに，我々は小さくてすばらしいコンポーネントを持つが，それらの使用有効範囲はまだ限られている．私の命題は，我々が伝統的な方法よりも多くよりよい方法で再利用できる小さなコンポーネントを構築できることである．
要約すれば，Unix アプリケーションではほどんどコードが再利用されていない．Unix は現代的で一貫したアプリケーションを構築するための現代的なコンポーネントシステムを欠いている．
Unix のフィルタベースのコンポーネントシステムは強大なアプリケーションのニーズに取り組むには不完全である．
Bonobo は，Unix における再利用可能なソフトウェアコンポーネントを作り，「小さいは美徳である」の精神を保つ我々の提案した解答である．各コンポーネントは，完全で適切なインタフェースと機能の集合を実装することに集中する．
我々はコンポーネントアーキテクチャのための基盤として CORBA を選択した．CORBA は我々が開発している数多くの興味深い機能を持つ．
それらを個々に見ていこう．
コンポーネント間の契約は CORBA インタフェース定義言語(CORBA IDL)によって表現することができる．
サービスが実装されるとき，サービスの機能は CORBA IDL による契約を通して公開される．これらの契約は，CORBA 用語でインタフェースと呼ばれている．
オペレーティングシステムにおけるブロックデバイスドライバを模倣する例を使おう．
interface BlockDevice {
typedef char Buffer [512];
void init ();
void seek (in long block);
Buffer read (void);
void write (in Block block);
};
インタフェースは非常に簡単である．seek メソッドは，デバイスに特定ブロックへ行くように要求する．read メソッドは，現在のブロックからデータをロードするために使われる．write メソッドは，現在の位置にブロックを書き込むために使われる．
ここで興味深い部分は，完全に異なるオブジェクト(テープドライブ，ハードディスク，フレームバッファ，通常ファイル)が上記のインタフェースを実装することができることである．
上記の「BlockDevice」インタフェースを実装しているオブジェクトへの参照を持っているユーザは，実装の詳細について気にする必要はない．そして，上記インタフェースを持つ異なる実装が存在することができる．
CORBA インタフェースをハードウェアインタフェースと等価なソフトウェアとみなせる．例えば，同じプロトコルを話し，同じインタフェースを使うので，あなたはパラレルポートにいかなるパラレルプリンタを接続することができることを知っている．互換性があるので，SCSI バスに SCSI ハードドライブを接続できることも知っている．
これは CORBA インタフェースが我々に提供するものと同じである．
CORBA オブジェクトは通常パッケージとして出荷される．パッケージは共有ライブラリ，独立したプロセスまたはリモートプロセスであるかもしれない．例えば，「evolution-mail.so」と呼ばれるファイルは様々な Evolution 関連のメールオブジェクトが含まれるかもしれない．そして「evolution-calendar」と呼ばれるプロセスは，Evolution メールクライアントにおけるカレンダハンドリングに関連する複数のオブジェクトを含むかもしれない．
CORBA オブジェクトはどこにでも存在することができ，アプリケーションはそのオブジェクトがどこに位置するのか，どこから来るのか知る必要がない．
CORBA オブジェクトは同じアドレス空間，または同じコンピュータ上の分離したプロセス，または異なるコンピュータ上にに存在するかもしれない．
アプリケーションとコンポーネントのニーズにしたがって，上記のシナリオから一つの方法で，CORBA オブジェクトを実装することを選択できる．
あなたは気付いたかもしれないが，上記の例の IDL 定義にはいかなる実装の詳細も含まない．IDL はまさしくあなたのオブジェクトが実装する契約を指定する．
CORBA インタフェースを実装したコードと同様に CORBA のコード実行メソッドは，非常に多くのプログラミング言語で書くことができる．CORBA 標準はプログラマが CORBA オブジェクトにアクセスするか，CORBA サーバ/オブジェクトを実装するための仕様を含んでいる．
CORBA メソッドを実行したり，CORBA サーバを実装するために非常に多くのプログラミング言語を選択することができる．これらは一般的に「CORBA バインディング」と呼ばれている．
GNOME では C バインディングのために ORBit を使っている．Owen Taylor は ORBit を使った Perl 用の CORBA 実装を書いた．さらに Python，C++ 用のバインディングも存在する．
Bonobo は CORBA 上に構築されたコンポーネントアーキテクチャである．Bonobo は 一連の CORBA インタフェースを含む．
Bonobo コンポーネントモデルはそのシステムを介して利用する一連のインタフェースを定義している．Bonobo における Bonobo インタフェースの主要なカテゴリを次に挙げる．
Bonobo のベースインタフェースは Bonobo::Unknown と呼ばれており，Bonobo における他の部品を使うほどんどのインタフェースのためのベースインタフェースである．
Bonobo::Unknown は次に示すように非常に単純なインタフェースである．
interface Unknown {
Unknown query_interface (in repoid);
void ref();
void unref();
}
このインタフェースはオブジェクトの参照カウンタを通してオブジェクトのライフサイクルを管理し，動作中のオブジェクトにおける利用可能な機能を発見するために使われる．
Bonobo はあなたのシステムにおけるコンポーネントを起動し，アクティベート(活性化)するために，GNOME におけるオブジェクトアクティベーション機能を利用する．
コンポーネントをアクティベートするには次に示すような複数の方法がある．
各コンポーネントにはコンポーネントを識別するためのユニークな識別子が割り当てられている．ユーザはこのオブジェクトをアクティベートするために，実行時に要求して，コンポーネントを起動することができる．
ランタイムはファクトリコンポーネントを使うことで，コンポーネントのインスタンス生成の面倒をみている．ファクトリコンポーネントは通常のコンポーネントのインスタンスと同様にユニークな識別子を持っているが，Bonobo::GenericFactory インタフェースをサポートしている．それは要求時に新しいインスタンスを返すことができるインタフェースであり，C++ におけるクラスの「new」メソッドと等価である．
通常，ファクトリコンポーネントはシステムの名前サービスに自身を登録し，その後，任意のアプリケーションからの要求に対して，この与えられた型を持つオブジェクトのための工場になる．[ファクトリパターンをチェック!]
モニカは複雑なセットアップ操作やオブジェクトの初期化のために複数オブジェクトプロセスを要求するようなオブジェクトのインスタンスをアクティベートする手段を提供する．
例えば，該当するオブジェクトに至るすべてのステップを解決することによって，コンパウンドドキュメント内に存在するオブジェクトをアクティベートできる．
次のように gnumeric スプレッドシートに埋め込まれた数式で使われているフォントの「Color」インタフェースと対話することができる．
demo.gnumeric!Sheet 1!Equation 1!3:x^2
このオブジェクトは「Color」インタフェースに対して解決される．
現在，Bonobo におけるモニカの実装は最適状態には及ばない．そしてこの大部分は私のミスに原因がある．
私はモニカに関する Microsoft の文書に目を通しながら，「あぁ，疑いなく，これらの人々は彼らが思い付くもっとも複雑な方式でこれを実装した．」と考え続けた．私は複雑さがあった理由とそれが意味をなす利用シナリオが何であるか理解するのに数ヵ月かかった．
しかし，その詳細はあなたを退屈にさせるだろう．我々がモニカインタフェースを再訪問していると言うためにはそれで十分である．[訳8]
オブジェクトの標準フォームプロパティ(「Color」，「Font」，「Orientation」)を公開するために使う Bonobo コアにおける他の機能がある．これらは Delphi プロパティに似ている．
オブジェクト永続性やコンパウンドオブジェクト永続性インタフェースは，コンポーネントシステムの汎用的な利用パターンに十分に取り組むために存在する．「オブジェクト，このストリームにあなたの状態のすべてを保存してください．」とか「オブジェクト，あなたは悪い子のようだから，私の言うことにしたがって，このストリームインタフェースからあなたの状態をリストアしてください．」といったことを行なうためのインタフェースである．
しかし，Bonobo は，コンピュータサイエンスが唱える抽象的ながらくたの単なる寄せ集め以上のものである．Bonobo システムもまた，アプリケーションウィンドウにコンポーネントを埋め込んだり，コンパウンドドキュメントを作ったり，印刷したりなど，コンポーネントベースアプリケーションの視覚面を扱う機能を含んでいる．
Bonobo はコントロールインタフェースと呼ばれる一連のビジュアル埋込みインタフェースを通してこれを行なう．例えば，Bonobo は次のようなことを可能にする．
これは本当に単純に聞こえるかもしれないが，本当に興味深いことをもたらす．Bonobo インタフェースの普遍的な性質のために，アプリケーションは埋め込まれたコンポーネントについての具体的なデータをほとんど必要としない．これはすばらしいアプリケーションレベルの柔軟性となる．そして，それは本当にユーザのためになることを意味する．
例えば，Evolution はメールデータに対して任意のプラグ可能ビュー(pluggable views)を適用するために Bonobo コンポーネント埋込みを使っている．通常はフォルダディスプレイコンポーネントを利用してメールを見ることができるが，カレンダディスプレイコンポーネントを使ってカレンダとして，またコンタクトコンポーネントを使って一連のコンタクトとして見ることもできる．
カレンダコンポーネントを使えば，議論の時系列をトレースできる．(「あぁ，Bob は最初のメールへの返事に3日かかり，それから Jim が飛びついて3時間に26通ものメールを送ったんだな」とか．) コンタクトコンポーネントを使えば，ある議論グループに参加している人々のリストを見ることができる．そして，もちろん pine ユーザのように普通にメールを見ることもできる．
単純でモジュール単位のコードを持つ普遍的なインタフェースを組合せれば，多くの興味深い可能性が出現する．
Bonoboのビジュアル埋込み能力の重要なもう一つの利点は，我々がモノリシックアプリケーションを書くことを避けるようになることである．過去にフル機能を持った文書エディタを書きたかったならば，それはコアテキスト編集機能に加え，基本的なイメージエディタ，数式エディタ，表組みツールやユーザ人口の一部が要求する数多くの小さな機能を実装しなければならないことを意味していた．
Bonobo を使うことで，各々の補助的なコンポーネントは一度書かれる必要があるだけで，すべてのコンテナアプリケーションから利用可能になる．埋込み可能な数式エディタコンポーネントがあれば，ワープロ，表計算，ダイアグラムデザイナ，Evolution，プレゼンテーションプログラム，DTP アプリケーションから使うことができる．これらの個々のアプリケーションはよりスリムで，モジュール性が高く，実装が簡単である．ハッカーはより多くのコードが再利用されるので，彼らのアプリケーションについて本質的な問題に集中することができる．
さらに，これはアプリケーションプロジェクトにおいて，ハッキングのためのエントリ障壁を実際に下げることになるだろう．ウィークエンドハッカーが一つのアプリケーションに貢献できる前に，何百万行のコードの特徴を学ぶことは合理的ではない．しかし，イメージビューアコンポーネントがどのように動くのかを学ぶために二千行のコードをざっと読むことは気にならない．大きなものより小さなコードベースに対して貢献することから始める方がより容易である．すなわち，我々のゴールは多くの小さくてコンポーネント化されたプロジェクトが，普遍的で完全なデスクトップ環境を作るために協調して動作することである．
Bonobo についてのさらなる情報は，私の Bonobo の紹介記事が利用可能である．[訳9]
Unix システムを設定することは伝統的にシステムファイル(典型的に /etc 以下に置かれ，ファイルに保存されている)を編集することが必要とされてきた．そして，様々なプログラムやシステム上のプロセスが変更をピックアップするか，この変更を知らせる必要があるデーモンに通知しなければならない．
これらのファイルは人的なエラーによって簡単に破壊されるから，これはまったく理想的な状況ではない．そして，ツールによって，異なったファイル編集の手段が必要となる．
例えば，/etc/passwd を考えてみよ．このファイルを編集することは vipw コマンドを使う必要がある．それは保存する前にファイルの整合性に対するいくつかの基本的なチェックを行う(ロッキングも同様に適切に)．しかし，「lock」，編集，他のシステムファイルを検査する等価なコマンドは存在しない．
そこで，各ツールごとにユーザ/管理者は次のようにする必要がある．
Unix の美徳のいくつかの例を見てみよう．
/etc/inittab の場合: 設定をリロードするために telinit q を使う．
Red Hat 6.1 付属のマニュアルページに見られるように，人的なエラーのエラーハンドリングは悲しい．
「/sbin/init は，あるエントリーが2分間に10回以上繰り返して再生成されるのを発見すると，コマンド文字列に誤りがあると仮定してシステムコンソールにエラーメッセージを表示し，5分以上経過するかシグナルを受け取るまでそれ以上そのエントリを再生成する事を拒否する．こうすることによって，/etc/inittab 中に綴り間違いがある場合や，そのエントリで使用するプログラムが削除されている場合に，システム資源を使い尽くしてしまうことを防いでいる．」
私はこれを知り，「ひどい」と思うしかない．
/etc/group の場合: 変更はシステムによって自動的にロードされる．ファイルにエラーがないことをただ祈るだけだが，さもなければおかしな振舞いを始めるだろう．
いくつかのテストと /home で ls することは，事態があまり変わってなければ，発見のためのよい戦略である．
再び痛ましい．
httpd.conf の場合: システムによって，いくつかの次のようなコマンドを使うことができる．
ここでは計画について述べる．これは実装されていないが，我々はこのアプローチが十分に分別があり，十分によいと信じている．それは，上記の問題に取り組むことができると同時に，よりよいものを提供する．
我々は UNIX システムサービスをいつでも CORBA インタフェースを通してアクセスできるようにすることを望んでいる．
例えば，ユーザ管理サブシステムのサンプルコードは次のようになるだろう．
add_guest_user (void)
{
User user;
uid_t uid;
user = System_Admin_Users_add ("guest", -1, -1,
"Guest user", "/home/guest",
"/bin/bash", &ev);
if (ev._major != CORBA_NO_EXCEPTION){
if (error_is (ev, ex_System_Admin_Users_name_exists)
error ("User already exists");
if (error_is (ev, ex_System_Admin_Users_invalid_shell)
error ("Invalid shell");
error ("default error handler");
}
uid = System_Admin_User_get_uid (user, &ev);
...
System_Admin_User_set_password (user, "PowChickaPowWow", &ev);
printf ("User guest was added, and its uid is: %d\n", uid);
}
例えば，次のインタフェースの断片は，プリンタサブシステムに対する可能なオプションを示している．
module System {
interface PrinterQueue {
JobList get_job_list (void);
void pause_job (in JobID id);
void abort_job (in JobID id);
void resume_job (in JobID id);
void submit_file (in string file);
void submit_input (in Stream stream);
PrinterStatus get_status ();
string get_status_as_string (in string locale);
...
}
interface PrinterQueues {
PrinterQueueList get_list_of_queues ();
void add_printer_queue (in QueueDefinition queue);
...
}
}
次のもう一つの断片は，ローカルメール配信エージェントの設定の一つである．
module System {
module MailDeliveryAgent {
interface Relay {
void enable_relay ();
void disable_relay ();
void add_relay_host (in string host_match);
void remove_relay_host (in string host_match);
RelayList get_relay_list ();
...
}
interface Config {
void set_masquerade (in string domain);
void set_use_mailhub (in string mail_hub);
...
}
...
}
}
次は，DNS サーバである．
module System {
module DNS_Server {
interface Domain {
void set_timeout (in long timeout);
void get_timeout ();
...
}
interface DomainHandler {
Domain get_domain (in string domainname);
Domain add_domain (in string domainname);
void remove_domain (in string domainname);
...
}
...
}
}
などなど．これらは単なる例であるが，我々は明らかにこれらを長期に渡ってサポートしていくことを望んでいる．
これらは複数の段階で展開することができる．
Helix Code において，我々はエンドユーザのために様々な方法でシステム管理を簡単にするいくつかのツールを開発している．我々は「Helix セットアップツール」に取り組んでおり，それらのツールには前述した考えを取り入れる．
これらのツールは様々な制約の下で開発され，次のようなよい混合を生み出すことを試みた．
フロントエンド フロントエンドによって変更が要求され，値を処理するために CORBA インタフェースを公開しているので，これらのツールのそれぞれのバックエンドは，オペレーティングシステムやディストリビューションを検出し，値をロードし，ファイルを編集する責任がある．
各バックエンドは，順番にその状態を XML フォーマットでダンプすることができて，XML ファイルからシステム状態をリストアすることができる．リストアはシステム設定値の適切な編集を行うだろう．
Perl ハッカーが，バックエンド(それは，実際に動作のコアを実行する)を修正し，拡張し，改善し，維持し，バグフィックスするために，Gtk+，GNOMEか他の何かについて何も知る必要がないので，我々はバックエンドとして Perl を選択した．Owen Taylor の CORBA のための Perl バインディングは使うことが楽しいので，バックエンドとしての Perl もまた魅力的である(CORBA を認識するアプリケーションを作ることはまさにすばらしい)．
フロントエンドはすべてのユーザインタフェースの好みが生じ，一般的に C プログラムとして実装される．ここでの考えは，複数のオペレーティングシステムで同じフロントエンドをつかうことである．あなたが Unix のどのような種類(Linux ベースディストリビューション，BSD，Solaris，その他)を使っているかは，問題ではない．
次のようなたくさんの興味深い機能は，現在利用可能である．
例えば，活動的な義理の息子がやってきてコンピュータの設定を彼の ISP を使うように変えてしまい，そのままの状態で去ってしまったので，あなたの叔母はそれを直せない．例えば，家に帰って来たエネルギッシュな息子を考えよ．彼は ISP を使うようにコンピュータの設定を変更し，壊れた状態でマシンを残して行った． [訳10] そこで，我々は N 時間，N 日前の状態に設定をロールバックさせるスライドバーを提供する．
例えば，デフォルトプリンタキューはあたたが実際に居る場所によって異なるだろう．あなたが自宅で作業しているときは，/dev/lp があなたのプリンタであり，オフィスに居る間は，ボスのオフィスそばの大きな PostScript プリンタを使いたい．そして，コンピュータサイエンス研究室にいる間は，ドットマトリックスプリンタを使うことに耐えている．
ネットワークオプションも同様である．あなたの位置するところによって，異なるネットワーク設定を使いたい．自宅では，エアポートと DHCP を使いたい．オフィスでは，静的 IP とイーサネットネットワークを使い，旅行中は，モデムを使っている．
自動検出でも手動選択でも，パネル上であなたの位置を選択することを通して，あなたにとってすべての設定がされる．
一つのホストが，ローカルコンピュータサイエンス研究室のネットワーク上で，すべてのデスクトップコンピュータを管理するだろう．
そして，もちろん，上記へのWeb ベースバックエンドもまた可能である．
Bonobo は「ピグミーチンパンジ」としても知られている．彼らはコンゴに住んでいるが，存亡の危機に瀕している．私はあなたに彼らと彼らを救うために手伝う方法のより詳しい情報のために，http://www.gsu.edu/~wwwbpf/bpf/ を訪れることを勧める．
あなたは我々がフリーソフトウェアの未来を変えることを手伝うことができる．すべての人が影響を与えることができる．毎日が贈り物である．
我々はあなたの助けを必要としている! 行動に移せ! 戸締りして，荷作りしろ! さぁ，行こう! 牛は納屋に入れろ! Nat! 私は君と話している! 一人で羊を見捨てるな![どう訳せばいいの?]
[1] はい，私は正しい名前が「X Window System」であることは知っているが，単に X-Windows と呼ぶ方を好んでいる．
[2] ある友人がしばらく前に COM オートメーションを使うと何が可能になるのか見せてくれて，「わぉ，そいつはすごい．Unix でできるようになったらどうだろう」と思ったことを覚えている．その時は，どのようにオートメーションを実装すればいいかなんて少しもわからなかった．
別の友人は「Unix は COM を必要としている．どうしてそのような作業をしないのか」と話してくれた．それを理解しようとしている間に，別の友人が「COM は必要ない．COM は単にポインタのポインタで手続きを呼ぶためのシステムじゃないか．」と言った．
The library contains functions for memory allocation, bit arrays, configuration files, comparing standard C types for qsort and bsearch, error messages, expression parsing and evaluation, filenames, hash tables, integer sets, log files, the Linux Software Map, NNTP, priority queues, normal queues, editor buffers, stacks, and strings.
(何か人物関係が無用に複雑な気が… つまり、あなたの叔母さん夫婦が住んでいるところに、 あなたのいとこ夫婦 (妻が叔母さん夫婦の娘にあたる) が訪ねてきて、その時に いとこの旦那さんは休暇にもかかわらずネット接続に勤しむために設定を変えて (だからEnergetic?)、いとこ夫婦が帰ったあとで叔母さんは設定をもとに戻せず あなたのところに助けを求めに来た、ってことなのか?)