Berlin


b e r l i n

Home
FAQ

w i k i

Start here
Categories
Index
Recent changes

Edit this page
Delete this page
Find related pages

s e a r c h

 

WARNING: This Wiki is no longer maintained, and may be out of date! You probably want this page on the new Wiki, instead!

JapaneseFAQ

The Real FAQ

[FIXED: this text is encoded in ISO-2022-JP, I think, and took out all the offending chars.]

TheBerlinProject のよくある質問(FAQ)

Berlinって本当に実在するん?

する。ベルリンは本物の、実行できるプログラムなのだ――ダウンロードして遊べるのである。まだ、既存の各種ウィンドウシステムに完全にとってかわるようなものにはなっていないけれど、基本的なことはそこそここなすし、ほかの環境では結構面倒なことも、すでにやまほどできるようになっているぞ。

Berlinをインストールするとよいのはどんな人?

いまのところBerlinは、一般人には まったく使い物にならぬのである。我々は、自分たちのことをユーザインターフェース開発の実験台だと思っておる。だからといって、「一般人」に我々の成果物で遊んでいただきたくない、などとはゆめゆめ申?ぬ。ただ、まともな実用アプリケーションは まだ一つたりとも ないということは申し上げておく。XTerm (あるいは rxvt, kterm, gnome-terminal 等々のおなじみのターミナル) 程度の機能をもったターミナルすら、まだおじゃらぬ。

もしberlinの改良を手伝いたいとか、OSへの移植、あるいは単に試してみたいと思し召?れるのであれば、それは大歓迎。我々の問題点やうまくいった話を是非とも聞かせていただきたいものであるよ。

Berlin のインストールってむずかいしい?

いまでは autoconf を使っておる (Havard のお・か・げ)。これで、昔のバージョンに比べて、インストールはずっと簡単になっておるのだ。

まだバイナリ・リリースはおじゃらぬ。というのも、ソースでしかダウンロードできないライブラリに依存しておるものでな。こういうライブラリと Berlin をパッケージする暇のある御仁がおいでなら、ご一報をいただければ幸甚 :-)

Berlinを全部インストールするとどのくらいのディスク容量を喰うの?

我が輩のハードディスクだと、berlin は 52MB 喰っておる。でも、これはインストール サイズではなくて、ソースコードやプログラムやモジュールやライブラリ(それも中には、実は Berlin とぜんぜん関係ないのも混じっておるし)、フォントやmake中にできたいろんなファイルもおじゃる。でも現状では、berlin で遊ぶのに必要なディスク容量という意味では、まあこんなものではないかな :-)

サーバそのものはたった 133KB で、 C++-クライアントは 327KB, ライブラリディレクトリは 5.1MB でモジュールディレクトリが?らに 6.1MB。だからほんとうの「インストールサイズ」となると、12MB 前後といったところであるな。ほほう、思ったより大喰らいであった ;-)

Berlinなんているの? Xがあるではないか!

BerlinVsX (日本語訳は BerlinVsXja ) をよみたまえ。

X 互換レイヤーは作るの?

プロジェクトメンバーの何人かは、その手の話に興味を示しておる。理論的には、そんなにむずかしくはないはず――それをXF86なみに高速にするのは、手間かもしれないけれど、XF86/GGI (もうすでにまともに機能するのだ) への GGI visuals ができてしまえば、リリースのかなり初期にX互換レイヤーが登場する可能性はかなりある。もちろん、Xで完全に満足という人には、おそらく XF86 のほうが向いているだろうけれど、でもわれわれとしても、Xとの互換性がとても便利だということは認識しておるのだ。

どっちがクライアントでどっちがサーバ?

ここではX-Windowの用語法を採用しておる。つまり「おぬしが走らせてウィンドウを管理するプログラム」が『ディスプレイサーバ』であり、「サーバに接続するプログラム」が『ディスプレイクライアント』または単に『クライアント』でおじゃるな。最初はなかなかややこしく思えるけれど、でもプログラムから見てやれば、クライアント側のプログラムは確かに、イベントやディスプレイ領域をよこせと「要求」しているわけで、このイベントやディスプレイ領域というのは、『ディスプレイサーバ』によって多重化し管理してもらっておるのは確かであろうが。

単にわれわれが X の洗脳にはまりきっておるだけ、かもしれぬ。が、いずれにせよここではそういう用語でいくのだ。

Berlinと TheFrescoProject との関係は? そもそもFrescoとはなんぞや?

GraydonHoare が、berlin-designへの メッセージでこの話はきれいにまとめてくれておるのよ:

Date: 04/01/2000 23:02:16
From: graydon hoare 
Subject: [Berlin-design] BerlinのX Window Systemに対する優位性

(前略)
berlin はプロジェクトとして5歳ではありません。berlin プロジェクトが
正式に開始したのは、1997年頃(つまりわれわれは3.5歳のプロジェクト)
ですが、いまのberlinの姿というのは、 *ずうぅっと* 古いコードでできて
います。fresco(そしてそれ以前のinterviews)からのコード。およそ13年
分の作業。あなたが「berlin VS X」ページで挙げた話には、このコードは
比較的ちょっとしか入っていません(frescoとinterviewsは、いろいろあり
ますが実際にはX ツールキットとして動きましたから。ほとんどの作業は、
ぼくが見る限りでは、composition modelの完成につぎ込まれたよ
うですよ。

レゴみたいなものだと思ってほしいのです(これはぼくがよく引き合いに出す比
喩だけれど、最初に使ったのは stefan で、ぼくがきいたなかで最高の比喩で
す。)レゴ成功の鍵というのは、レゴのブロックが最高にクールとか、その
形が最高とかいうことではないでしょ。あれは、そのブロックがすごくうま
く _くっつく_ のが鍵なわけです。大きなものを作るためにレゴのブロック
を組み合わせるメカニズムは、ほぼ完璧。同じようにfresco (berlin) で、
ほんとうに大事な部分というのは、 scene nodes がすべておたがいに協調し
あってレイアウトをするってことで、イベント受信とフォーカス管理がすべ
てに組み込まれて、画面上のすべてが均質なタイプ(グラフィック)なので
無限に装飾したり、他のグラフィクスとネスティングできるってことなんで
す。

ある意味で、これはこのシステムの不幸な性質でもあって、どっか一つの部
分だけ示して「こいつのおかげでこのシステムはすばらしいのである」と
言うことはできないっす。システム的なんですわ。とても優れたシス
テム設計がしてある。この製品は、10 年以上も C++ コミュニティやグラフィク
ス専門家に叩かれてきてるんです。

これはどれも「われわれの」成果、つまり「berlin プロジェクトの成果」で
はありません。berlinのコードベースは、 1998 年 12 月 (0.1.0) というごく
最近の時点でも、この手のものは _何一つとして_ 備えていませんでした。
いまのわれわれは、この 0.1.0 のコードは *一切* 使っていません。いまの
われわれは、実は「全部frescoコード」なんです。なにが起きたかというと、
1998 年末から 1999 年はじめにかけてstefan がやってきて、新しい技術の開発
なんかあきらめて、fresco をサクっちゃえ、とぼくを説得したわけです。そ
れから、ほとんど独力で fresco コードベースを変更して、ぼくたちのもとの
想定にあわせてくれました。つまり GGI と omniORB の使用、ウィンドウシステ
ムの中で動くんじゃなくて、それ自体を完全にコントロールする、イベント
処理、もっと堅牢なイメージングプリミティブ、実行時のモジュールローディ
ング。みんながberlinとしてみているのは、実はそれなんですわ。stefanが
過去1.5年にわたってとりくんできた、巨大な移植、整頓、拡張の努力の結果
なんです。

というわけでして、きみの berlin と X に関するコメントは、みんながダウン
ロードして使ってみる動機づけとしてはありがたいんだけれど、fresco やこの
構造化グラフィクスモデルの重視という部分が見失われているように思います。
ここでみているテクノロジーは新しいものじゃなくて、解像度に依存しないと
か、アルファチャンネルの使用とかは、その御利益のほんの一部でしかありま
せん。プログラミングモデルがどんなにわかりやすくエレガントか知りたければ、
motif kit のコードを見てほしいな。

-graydon
これでおおむね話は尽きておると思うがの。

構造化グラフィックス、だって?!? Berlin ってアセンブラで書かれるはずじゃなかったの?

むかしはそうであったのよ。このプロジェクトにまつわる混乱というのは、こいつが名前はそのままで、何回かにわたってすっかり変わってしまったということからきておる。最初にこのプロジェクトを始めた人は、超軽量ウィンドウシステムをつくりたいな、と思っておった。そこらじゅうにIPCやアセンブラ用のパイプをつけて。これがcvsツリーの「berlin-classicブランチ」で手に入るものである。しかしこの最初の開発者たちは、ほかの関心事などもあって、だんだんと手を引き、しだいに GraydonHoare が主導権を握るようになってきた。というのも単に、コードをサブミットするのがほとんどかれだけだったから、という話ではあるのだけれど。こういう状況で一人残ることになり、創始者たちのビジョンもよくわからなかったGraydonは、自分がいちばんいいと思った形でプロジェクトを継続し、プロセス間通信には CORBA を使うほうに流れていった。この状況はしばらく続いたんだが、すでに興味を失った創始者たちと、まだ作業をしている人々の間でちょっとやりあいがあって、創始者たちは袂を分かったのである。そのしばらく後で、0.0.1 が出てきた。ちょうどこの頃、 StefanSeefeld がFrescoの福音を説きはじめて、大量のコードをBerlinに移植して、いまのアーキテクチャをつくりあげたというわけであるな。いま「Berlin」と言ったら、最近ではこの Fresco起源のコードベースのことで、この名を冠したプロジェクトの中ではいちばんうまく行っているものになっておるのだ。

[FIXME: これはぼくが集められた範囲での歴史――お願い、実際のできごとを見た人がいたら、なおしておくれやね]

TheBerlinProject と LibGGI とはどういう関係なの?

TheBerlinDisplayServer?LibGGI を低レベルのドローイングライブラリとして使う。これはいろんなデバイスにターゲットしなおせるのだ。GGI はグラフィクスのハードウェアに対し、安全で高速なアクセスを提供するメカニズムを検討しておる。Berlin は、カーネルインターフェースがあるシステムでは、ネイティブ・グラフィクスサポートをGGI経由でアクセスしようとするぞ。それ以外のシステムでは、LibGGI は自動的にもっと従来型のディスプレイシステムをターゲットする。 Berlin が明示的にGGIに頼るのはほんの数カ所くらいではあるのだが、われわれの開発者たちの多くはGGIプロジェクトにかかわっているし、みんな作業のためのすばらしいプラットホームだと考えておる。

OpenGL (または Mesa) って、えらく遅いんじゃないの?

それは使い方しだいであるな。まず認識してほしいことであるが、拙者らは実は OpenGL のイメージングモデルをすべて使っているわけではないのだ。拙者らの目標を達成するためには、どうせ書かなくてはならない部分を使っているだけだ――任意のリニア変形、サブピクセルの座標、マルチプルカラースペース(multiple colorspaces)、アンチエイリアシング、透過、NURBS、Z-ordering 等々。3Dサーフェス、複数光源、phong陰影、テクスチャマッピングおまけに透視投影まで、berlinにおいては切ってあるのだ。だからずっと高速に動く。また、拙者らとしても特に OpenGL にこだわらなくてはならない部分というのはまったくないのだ(それどころか、LibArt ベースのもっとスリムな DrawingKit が一部は使い物になってきておる)。OpenGL が選ばれたのは、単に目標にはやく到達したいからというだけなのである。もしそれが結果的に遅すぎるようなら、気のちがっておらぬ人間らしく、記録して最適化し、書き換えて、高速に動くようにするまでのこと。こういう順序で物事を進めるのは、なるべく機能を犠牲にしたくないからなのである。

MesaGGI なんつーもんはどうでもいいや、BerlinではオレのクールなDRIアクセラレーションつきGLX 版 Mesa をつかえないの?

ご愁傷様ではあるが、否。Berlin は、各種の DrawingKit がプラグインできるようなアブストラクション・レイヤーを持ってはおるのだが、主要 DrawingKit は必ず、どこか下のほうに GGI がなくてはならんのである。入力処理ルーチンは GII (GGI の入力ライブラリ)に直結しておるし、過去にはコードの一部に GGI フレームバッファに直接描き込むようなコードの部分もあった(いまだにあるかもしれん)。こういう問題を回避するようになにかをチャチャッとまとめることは、確かに可能ではあろう――まあたとえば、入力ルーチンの別バージョンをこしらえるとかすればよいわけだな。で、 DrawingKit を経由せずに GGI を直接使うようなコードなどというのは、バグであるという議論も、もっともではあろう。しかしながら、Berlin が X のもとで動くのは、主に開発のためなのだということをお忘れなきよう。長期目標は、Berlin を直接コンソールのもとで走らせることなのだ(そしてこれに成功したという報告も入ってきておる)。であるなら、Xの内部でのみ Berlin 動きを改善するような形にするためだけに、時間や労力を費やすのは徒労というものであろうが。それはそもそも拙者らの目標ではないのであるよ。

Berlinは試してみたいけれど、でも Quake 用超クールアクセラレーションつきドライバを手放したくない、という御仁には、手だては2つある。まず、別の Mesa ライブラリセットをインストールして、 LD_LIBRARY_PATH と autoconf でうじゃうじゃやって、 Berlin がそいつを使うようにする手があるであろう。あるいは LibArtDrawingKit を使うことであるな。これはまったく GL に依存していない。まだちょいとばかりバグが多いのではあるが、もちろんバグフィクスを手伝っていただけるなら大歓迎 :-)。 libArt DrawingKit を berlin ディスプレイサーバで使うには、次のコマンドラインを使う必要があるのである:

   server --drawing=LibArtDrawingKit

Berlin には、どんなソフトが必要なの?

HelpDealingWithBerlin をご覧あれ。

CORBA のことはよく知らないけれど、でもBerlinの設計は腐ってると思うぜ!

よくあるコメントであるな。だがそもそも CORBA を理解せずして、Berlinについてとやかく言うのは、なにせ不可能なのであるぞ(ただし CORBA ノウハウがなくても、読み込まれた部分の一部についてできる作業はあるがの)。反 CORBA の大論戦を展開する前に、お願いだから CORBAHowBerlinUsesCORBA は読んでおくのだぞ。

これまたよくあるコメントなのであるが、CORBA はでかくて遅いので、Berlinはリソースを喰いすぎるであろう、と言われる。そういうコメントの一つに対するStefanSeefeld の回答を披露しておこう:

DATE: 02/14/00 13:36
SUBJECT: CORBAの使用 - これって無駄にでかくなるだけでは?

みんなが CORBA についている誤解の一つが、そのオーバーヘッドの問題
らしい。CORBA は、ロケーション透過性を提供する。だからといって、各
オブジェクトが別のアドレス空間にいなきゃならんわけじゃない。単に、
使う側はそれを気にしなくてすむ、というだけだ。collocation にはいく
つか最適化が入ってるので、メソッドコールはほとんどが、仮想メソッド
へのマッピングになっている。

 CORBA があらゆる問題を一気に解決してくれる「銀の弾」ではないのは
確かだ。かなり高次のアーキテクチャで、やりとりの必要なオブジェクト
も高次のものであれば、きみのアプリケーションにはしっくりくるだろう。
CORBA と X をまぜるときの問題がこれだ。X プロトコルはかなり低レベル
のもので、マーシャリングでいちいち IIOP コールがたちあがるから、確か
に送り出す X イベントごとにこれをやっていたら速度は死ぬほど落ちる。
Berlinプロトコルはそれも考えたうえで設計してあるよ。

あるいは古い FAQ にもこの話は出てくるのである。質問は「CORBA って個別の putpixel() コールをマーシャリングしようたら悲惨なくらい遅くなるんじゃないの?」もし何百万もの個別の putpixel() を一つ一つマーシャリングしようとしたら、うむ、確かにそうなるであろう。しかしながら berlin の肝というのはだ、共通の、意味的に豊かなドローロジックが、ディスプレイサーバ側に完全に置かれる、ということなのだ。Mesaライブラリのパス・レンダリングから、完全にバッファしてあるメディア再生ウィジェットまでな。クライアントアプリケーションが、ビデオカードに対してすごい帯域幅を必要として、ドロー用のコードをサーバに移動しないほうがいいような例外的な場合(たとえば、ゲームなどであるな)にも、X式の共有メモリセグメントをクライアントとサーバでネゴシエートすることは十分に可能であるぞ。

Berlin, Moscow? , Warsaw, Prague?…… こういうのって、いったいナニモノ?

Berlin というのはプロジェクト名であると同時に、ソフトの主要な一つである /Berlin Server/ の名前であるのだ。 Warsaw というのは、Berlinサーバが実装するオブジェクト指向ウィジェットAPIのコードネーム――ほかにも互換性ある実装はできるかもしれないけれど、それは実はBerlinプロジェクトの産物ではないかもしれない。 Moscow? はデスクトップの API。 Warsaw よりずっと高次のサービスへのインターフェースを提供する。たとえばセキュリティやセッション管理、インストール、メディアとのネゴシエーションなど。 Prague? は、Berlin のラッパーでPOSIX機能を提供し、もとは OffiX? ツールキットの一部であった。使うと移植が簡単になるであろうぞ。以下のポンチ絵は、以上を多少なりとも明瞭にすべく意図したものではある:

Berlinのポンチ絵

クライアント・ライブラリはあるの?

ある。これが上述の Warsaw なのであるが、でもこれは X で使い慣れているような代物ではないのであるぞ。 Berlin クライアントライブラリは、CORBA スタッブ・オブジェクトでできたアプリケーションフレームワークになる。であるからクライアントライブラリは、warsaw IDL を CORBA スタッブ・コンパイラに通してから、その結果を機械語にコンパイルしてやれば再現できるのである。ほとんどの画面上のウィジェットの実際の実装は、おそらくはディスプレイサーバプロセスの中にいて、これが応答性をかなり改善するであろう。特にネットワーク化につながった環境では。もちろん、クライアントはいつでも好き勝手にプロセスをローカライズしてよろしい―― CORBA は、各コールはクライアント/サーバとしてモデリングしてある一方で、マルチピアモデルでもあるのだ。

GTK+とかQTとかを使えばすむ話ではないの?

ほかのツールキットはほとんどが、ピクセル単位でXとやりとりするように設計してあるのであるよ。おかげで、これをピクセル描画レベルでberlinに橋渡ししてやるのはまるっきり意味がないということになる。それならそのままXを使うのと何の変わりもないからな。しかしながら、 berlin ウィジェット API と他のツールキットのウィジェット API を橋渡しするのに興味を示しておる。コールをディスプレイサーバに転送し、インプロセスの処理にして、それについてくるもっと高度なイメージングやスレッドモデルもアクセスできるようにしようというわけであるな。 CORBA プロクシを使えば、別のツールキット用に設計してあるクライアント・アプリケーションの関数のポインタやメンバ関数に対して、従来型の「コールバック」を仕込むのは、それほどむずかしい話ではないのだ。

Naming.idl はmakefileに含めておく必要はあるの?

退屈で細かい技術的な質問なのに、この話は毎週のようにきかれるので、拙者が答えておこう。否。必要ない。すでに omniORB? ライブラリに含まれているし、libwarsawディレクトリに入っているのは、LifeCycle.idl のコンパイル時に読み込まれるからというだけ。makefileには入れないで。一時間かけてコンパイルしたあげくに、コンパイルが中断しちゃうだけだから。

[FIXME: ちなみにぼくはこの質問にはお目にかかったことがないし、この問題がまだあるのかも確信が持てないんだけれど...]

berlin はナニナニ描画モデル / 言語のバインディング / フォントファミリー をサポートしているの?

Berlin は、なるべく面倒をかけずに、できる限りオープンで拡張可能なように配慮してある。自分のお気に入りの描画、プログラミング、レンダリング、あるいはその他もろもろが拙者らのwebページに見あたらなければ、それを拙者らのディスプレイサーバに追加してくれる作業に取り組んでもらえば大歓迎。あるいは、CORBA で自分の好きな実装にラッパーをつけたりして、ネットワーク透過性を持たせることもできる。具体的には、 Python, C++, Perl はすべて、部分的にせよ機能するデモができておるし、お好きな言語がつかいものになる CORBA バインディングを持っているなら、ものの数時間もあればそいつをベルリンにつなげるようにできるはずであるぞ。

わぁ、あんたらってクール! なんかお手伝いすることは?

もちろんおじゃる! 作業してほしいことの一覧を見るには、TaskListを見てくれたまえ――そしてこの中で、ウィザード級のコーディング能力を要求するようなものは、一つもないとは言わんが、ほとんどないことに注目してくれたまえ。デバッグとかドキュメンテーションとか、Webページ管理とか、コードのレビュー( review? )は、だれにでもできることである。サーバ自体のコーディングですら、一人前になるにはしばらくかかるにしても、余人のよく為し得ない黒魔術のたぐいではないのだぞ。やることはたっぷりあるのだ。

特に、このfaqをきれいにして、構成をきちんとして、出てきた質問を追加してくれる仕事をかたがわりしてくれる御仁が出てきてくれるとよいのであるが……

自分のアプリケーションを、あとでBerlinに移植するにはどんな準備を?

  • ロジックとフロントエンドを切り離すこと。
一般的に、persistance(ストーレジ)、モデル(ロジック)フロントエンド(UI)を完全に分離しておくほうがよろしいのである。モデルとフロントエンドの部分については、MVC パターンが役にたつかもしれぬぞ。

以下のような覚悟をしておくがよかろう:

  • フロントエンドは1から書き直すことになる(設計までやりなおすことになるかも
  • でもその作業は、Xの場合より(たぶんずっと)簡単になる
  • CORBAを勉強すること
Berlin のインターフェースは CORBA に基づいているので、使い方を知っているとか、インターフェースや実装を自分で書けても、罰はあたらないぞ。

この手の話で、もっと情報を得られるようなとこってある?

CORBA やその他のウィジェット・ツールキット、タイポグラフィー等々……についての詳しい情報がほしいのであれば、 RecommendedLinks ページか、 Books カテゴリーをご覧あれ。


ロゴ、かっくいーではないの。なにを表してるの?

Berlinロゴの三角形3つは、Berlinを支える三本の支柱を表現しておる:勇気、栄誉と冷凍ピザ。

赤い三角形は、Berlinの中核となる基盤のシンボルであり、青は中央と橋渡し役をしめすことでBerlinの試練を表現しておる。そして緑は山頂をあらわす。これはBerlin開発の頂点を示し、われわれが到達しようと苦闘しているものを表現しておるのだ(そして解釈としては「もうすぐ実現、いやホント」というところじゃの)。

以上はすべて、Berlin公式神秘学者にして過渡的 KeeperOfTheLore (伝?継?者)たる NathanielSmith に依る。

もちろんこのロゴ、単にゼリーキャンデー3つを表しただけかもしれぬ。インターネットの伝?なんて、そんなものよ。

-- NiklasElmqvist .

関連ページ: Documentation

Translated by YamagataHiroo

Fixed by Akubi


 
Web Design by Alexander Johannesen