Developerサイトに移行します。見た目やトピックエリアなど更新されますが、開発者に必要とされるコンテンツを引き続き提供していきます。:プロセス間通信)のことですが、数々の機能がD-BUSを「そこら辺にあるどうでもいいIPC実装」と言う屈辱的な烙印とは一線を画する存在にしています。様々な種類のIPC実装がこの世に存在し、それぞれが明確に定義された特定の問題の解決を趣旨としています。CORBAはオブジェクト指向プログラミングの複雑なIPCに対する効果的な解決法です。Environmentとうまく統合します。SOAPとXML-RPCはWebサービス向けに設計されていますので、HTTPをトランスポート・プロトコルとして使用します。D-BUSはデスクトップ・アプリケーションとOSのコミュニケーションに向けて設計されています。典型的なデスクトップは複数の実行中アプリケーションをともない、多くの場合それぞれが相互の通信を必要とします。DCOPはKDEに対する解決法ですが、それはQtに束縛され他のデスクトップ環境では使用されません。同様に、BonoboはGNOMEに対する解決法ですが、それはCORBAを基にしているので結構重たいです。それはGObjectに縛られていますのでGNOMEの外では使われません。D-BUSは簡素なIPCとしてDCOPとBonoboに取って代わり、それら2つのデスクトップ環境を統合します。D-BUSへの依存性を最小限にとどめさせているため、D-BUSを使用したい他のアプリケーションは依存性を膨張させることを気にかける必要がありません。System)は、カーネルだけではなくシステム・デーモンをも含みます。2.6版のdevfs)がある場合、(USBカメラのような)デバイスが挿入されれば、信号が発信されます。これによりデスクトップ上のハードウェアとのより固い統合を果たし、ユーザーの満足度を高める結果となります。D-BUSの機能D-BUSには様々な興味深い機能が備わり、将来性が高いと言えます。プロトコルは短い待ち時間と低オーバーヘッドを誇り、ラウンドトリップ(round-trips)を最小限に抑えるために小型にまとめられ効率を高めています。それに加えて、プロトコルは無駄の多いシリアル化のプロセスを排除する(テキストでは無く)バイナリーです。ユース・ケースはローカル・マシンでの処理に偏っていますので、全てのメッセージはネイティブのバイト・オーダーとして送信されます。バイト・オーダーはそれぞれのメッセージに記述されますので、D-BUSメッセージがネットワークを通して遠く離れたホストに流れても正しく構文解析されます。開発者の観点から見れば、D-BUSは扱いやすいのです。ワイヤー・プロトコルは簡単に理解でき、クライアントのライブラリーはそれを直感的な方法でラップします。ライブラリーは別のシステムにラップされるようにも設計されています。使ってラッパーをD-BUSの周りに作成し(これらは部分的に存在し、D-BUSをイベント・ループと統合させます。)、KDEがQtを使用して類似するラッパーを作成することが予測されます。Pythonのオブジェクト指向性と柔軟な型定義により、かなりより簡単なインターフェースを持つPythonラッパーがすでにあります。最後に、GNOME、KDE、そして他の分野から興味を抱いている業界人達が設計と実装に参加するfreedesktop.orgの傘のもとで、D-BUSは開発されていることをここに述べておきます。D-BUSの内なる仕組み典型的なD-BUSの設定は複数のバスを伴います。ブート時に起動する永続的なシステム・バスがあります。オペレーティングシステムとデーモンはこのバスを使い、このバスは任意のアプリケーションがシステム・イベントを偽装できないように堅く保護されています。