[DE | EN | FR | JA | ES]

Georg の Brave GNU World 第13号にようこそ。 今回はまたちょっぴり技術的になりますが、 みなさんに興味のあるものが見付かればと願ってます。

Gcompte

Fabien Marchewka 作の Gcompte [5] は私が常に公開討論の場を提供してあげたいと思っている、 GNU GPL でライセンスされた小さなプロジェクトの一つです。

今回、それは GNUcash のような似たプロジェクトよりもうちょっと単純で小さな、 個人の財務状況を記録するためのプログラムです。 現在のこのような目的向けのプログラムが大き過ぎる、あるいは、遅過ぎると感じ、 基本的に単一の預金口座だけを管理したいと思っている人々にとって、 Gcompte は とりわけ興味深いでしょう。 Gcompte は内部ファイル形式として標準的な XML を使用しており、 HTML や LaTeX をエクスポートできるので、 ファイル形式を上手く選ぶことによって、その魅力を増していると言えるでしょう。

Gcompte はまだ幾分幼いプロジェクトです - 現在、バージョン 0.3.8 です - ので、たくさんの機能がなお計画段階に留まっています。 この中には、 「Quicken」ファイルのインポートやグラフや自動操作などが含まれています。 GNU Autoconf/Automake のおかげで設定やインストールはかなり簡単ですので、 初期のバージョンだからと躊躇せず、 興味のあるユーザは試してみると良いでしょう。

次の話題もおそらく大抵の人々に興味を持ってもらえるでしょう。

Scwm

「Scheme Constraints Window Manager」 (Scwm) [6] はチューリング完全でさえある、拡張可能なウィンドウ・マネージャです。 元々は Maciej Stachoviak によって書かれ、 現在は Greg J. Badros によって大部分の作業が行われています。

その設定と拡張用言語は Guile Scheme であり、 ウィンドウの位置や大きさの規則の組を設定することを可能とする、 高度な「constraint solver」があります。 さらに、C や (特別なアダプタの助けによって) Fvwm2 のモジュールを動的に組み込むことができます。 後者は、Scwm は本来 Fvwm2 のソース・コードを基盤としていたために可能なのです。 Scwm が constraint solver と伴に上手く役割を果たすことも顕著でしょう。

Scwm の大なり小なり標準的と言える機能の中には、 テーマが利用可能なこと、組み込みの相互作用や解説のシステム、 GNOME 準拠、 設定用のグラフィカル・ユーザ・インターフェース、 WindowMaker の proplist を組み込むことのできる「proplist」モジュールなどがあります。 非常に注目すべきなのは、 合成されたキー・プレス・イベントを生成することが可能なことです。 このことは一部の人々によく分からないかもしれないので、 おそらく少々言葉を費すべきでしょう。 X ウインドウ環境は基本的に「イベント指向」、あるいは、幾分「差異的」です。 四六時中何でも質問 - そして、送信する - のではなく、 プログラムはあらかじめどのイベントに興味があるかを決定します。 そのようなイベントは、例えば、マウスがあるウィンドウに出たり入ったりとか、 キーが押されたとかです。 合成のキー・プレス・イベントを生成できるということは、 例えば、マウスが全然触られてもいないのに、 あるリンクがクリックされたと Netscape に伝えられるということです。 x86 GNU/Linux の下では IBM ViaVoice パッケージもサポートされていると教えてあげたら、 あなたの幻想をさらに助長する必要はありますまい。

もっと顕著な機能がありますが、それらを詳細に記述すると、 きっとあっと言う間に手に負えなくなってしまうでしょうから、 本当のイベントのための XTest モジュールだけでなく、 配置手順の状況における「guile-gtk ウィジェット・バインディング」と 「拡張ウィンドウ・マネージャ・フック」もあるということだけを話に出しておきます。 これがあなたにとって技術的に難解なものでしかなくても、 Scwm はそれらがなくったって、非常に満足して使えると安心してください。

しかしもちろん、解決しなければいけない問題がまだあります。 Greg によると、一番大きな問題は、訳なく20秒もかかってしまう、 起動の遅さです。 幸運なことに、設定変更は動的に適用されるので、 再起動はほとんど滅多に必要ありません。 将来の計画にはイベント処理機構の再設計が含まれています。 おそらく、Guile オブジェクト指向プログラミング・システム (GOOPS) に基くでしょう。 さらに、ウィンドウの装飾はもっと上手く、もっと頑強に設定できるよう、 手が加えられるべきです。

Scwm のほとんどあらゆるものが GNU General Public License でライセンスされているので、それはフリーソフトウェアです。 唯一残存しているうずうずするところは「Cassowary constraint solver」で、 そのライセンスは研究目的には自由に利用できます。

次は「Emacs 教会」に容易に関係し得るプロジェクトです。

eev

最初 Eduardo Ochs 作の eev [7] に直面したとき、 その説明はとても曖昧で、 一体何の役に立つのやら私には分からなかったことを認めねばなりません。 eev manifesto [8] はきっと助けになったのですが、 私はしばらくそれで遊んでみた後に、実際に見てみました。 この実験的段階のおかげで、 あなたが理解するのがちょっとでも簡単になればと思います。

eev は 標準的な方法で Emacs に組み込むことのできる、Emacs-LISP ライブラリです。 インストールしたら、 それをいわゆる「e-script」をインタープリットするのに使うことができます。 それは - ちょうど普通のシェル・スクリプトのように - コマンドの列が書かれた、単なる ASCII ファイルです。 一度そのスクリプトは問題を解決するための手段ではないと捉れば、 それは興味深くなります。 その目的はむしろ、 ある問題を Unix で解決するためにどうすれば良いかを他のユーザに示すことです。 これを行うために、e-script は大抵一つの問題や様々な (望むらくは関連する) 問題に対するいくつもの解決策を含んでいます - だから、 それをひとまとめにインタープリットすることはあんまり有用ではありません。

これを使うのは結構簡単です。 e-script を Emacs に読み込んで、興味のある部分にユーザが印を付けます。 後で、印の付いた領域のコマンドを含む、 本当のシェル・スクリプトを生成する「eev」コマンドによって、 この部分がインタープリットされます。 そして、そのシェル・スクリプトは Emacs の shell-mode で実行することができます。 その出力は Emacs で監視できます。 それゆえ、e-script はユーザによって部分的に実行できる、 あるいは、一行ずつさえ実行できる、いくつものシェル・スクリプトの集合です。

これの一番良い部分は、e-script を解説するために Emacs の LISP 能力を利用するという発想です。 man や info、 ウェブページから全セクションをスクリプトに切り出して貼り付けるのではなく、 その解説は LISP 式から成り立ち、 それらは、例えば、man ページを開いたり、 info ファイルの特定の場所にジャンプしたりします。 これらの式は「C-x C-e」によってインタープリットすることができ、 それによって Emacs は指定された情報の箇所に訪れるわけです。 だから、これは LISP における「ハイパーリンク」のようなものです。 ソース・コードの参照でさえ、このやり方で容易に実装できます。 e-script の助けを借りれば、ある問題に対する解決策を知ることができるばかりか、 この解決策への道筋をすっきりした効率的な方法で獲得することもできるのです。

だから、これは実際、全く複雑な発想ではないのです。 たくさんのユーザにとって Unix をはるかに簡単に学ぶことができるよう、 ネット上に、ある標準的な問題の解決策のアーカイブを作成することも可能です。 この目標を達成するために、eev を GNU Emacs の標準的な部品としたり、 「vi」のような他のエディタにどうやって移植できるかを理解することが計画されています。 e-script のデータベースはすでに作成段階であり、 Eduardo は Debian パッケージに e-script を付けて供給することだけでなく、 Debian GNU/HURD のインストール作業や使用法、 障害対処のためのスクリプトを作成することを計画しています。

次のプロジェクトは読者によって紹介されました。 彼がメールを送ってくれたのは、基本的に、 このプロジェクトは本当に面白そうなんだけど、よく理解できないので、 それを理解する方法を探って、記事を書いて欲しいということでした。

Pliant

Hubert Tonneau による Pliant [9] は今や15年以上にも渡る設計作業を行ってきた、 GNU General Public License バージョン2に基く、非常に野心的なプロジェクトです。 しかし、Pliant とは一体？

まず第一に、Pliant は C のような低級言語と Java や LISP のような高級言語の間にある障壁を取り除くことを目的とした、 プログラミング言語です。 これを達成するために、 Pliant は二つの階層に取り組んでいます。 まず、「Expression」階層があり、 そこでは Pliant はいくつかの観点から LISP に似ており、 かなり強力な「eval」セマンティクスを包含しています。 二つ目の階層は「Instruction」階層で、 それは大変 C のサブセットに似ています。 Pliant の概念では、コンパイル過程は Expression から Instruction 階層へプログラムを移行させる以外の何者でもありません。 これは動的コンパイラに、 プログラムやライブラリによって提供される、 付加的な「meta function」を加えることによって行われます。 Instruction 階層が低級であることによって、 Pliant のプログラムは理論的には C で書かれたものと同じぐらい高速になります。

Pliant はまた、謎めいた設定ファイルの必要性を取り除きます。 というのも、それらも動的に解釈される Pliant コードとして実装されるからです。 このことが意味するのは、 設定ファイルもまた、 条件文やインクルード文などの全ての性質を持っているということです。 しかしその最も大きい利点は、 あらゆる設定に対して単一の文法を利用できるということです: つまり、 Pliant です。

これを使うためには、アプリケーションはもちろん Pliant で書かれていなければならず、 そのことが Pliant が伝統的な機能性を提供する、 標準的なアプリケーションの一組でもある理由です。 HTTP や FTP、SMTP、POP3 用のサーバはすでに存在します。 この文脈において、Pliant は TCP、HTTP、FTP や SMTP を含む、 ファイル・システムを持っているということにも注意すべきで、 URL を普通のファイルのように取り扱えることを意味しています。

こうしたこと全てが相俟って、 Pliant はプログラミングと設定の間にある境界を曖昧にしてしまいますが、 そのことが開発動機の一つでした。 設定のために使われる言語の枠組と同じものがプログラミングのために使えるわけですから、 プログラミングを始めるために乗り越えねばならないステップは低くなるのです。

そして最後に、Pliant はまた「高級」オペレーティング・システムでもあります。 それは Linux カーネルの上で直接、あるいは、標準の Posix 上や Windows システム上で動作します。 すると、Pliant はグルー・コードや過去の遺物から自由に働くことのできる、 唯一のユーザ空間プロセスになります。 HTTP サーバを動作させるのに、たった一つのプロセスしか必要にならないわけなので、 そのシステムは潜在的に非常に安定しています。

これら全ての側面が Pliant です。それでは現状を述べます。

現在の主要な問題は、 標準のコード生成プログラムは一般に広まっている最適化を備えておらず、 i386 プロセッサ用のコードしか生成できないことです - 「Posix」コード生成プログラムのおかげで Pliant は GNU/HURD を含む、 いくつものシステムで動作できるのですが。 このことから将来の計画へとすぐに話を運びましょう。 まず第一に、Hubert は Intel チップ用のコード生成プログラムか、 Alpha プロセッサへの移植に取り組んでくれる人を探しています。 彼は現在データベース・システムと、Pliant ワードプロセッサの基盤となるであろう、 グラフィカル・ツールキットを記述するという計画に取り組んでいます。 スプレッドシートはグラフィカル・ツールキットの完成とワードプロセッサの間のどこかで登場するはずです。 というのも、Pliant でそれを実装するのは非常に容易なはずだからです。

このプロジェクトはおそらく、主に内部に通じている人に興味深いでしょうけど、 このなかなか面白い発想をある程度は伝えられたと期待しています。

コンピュータ科学に直接は関係しないプロジェクトで締め括りたいと思います。 なぜなら、それは「自由な科学 (Free Science)」の問題に踏み込んでいるからです。

世界規模の植物学データベース

Jean-Marc Vanel は「世界規模の植物学データベース (Worldwide Botanical Database)」 [10] のための、彼のホームページへのアドレスを送ってくれました。 現在、 我らの惑星の植物相に関する知識はたくさんの図書館や植物標本館に分散しており、 そのために科学者たちは情報に到達するために旅しなければなりません。 このことによって、しばしばその科学の進行を遅らされてしまったり、 全く停止させられたりします。

我々の惑星上の種を効果的に保護するために、 まずその種について知ることが最も重要です。 だから、彼の目標は地球上の全ての植物に対して、 解説や写真、地理的分布を含む、植物のデータベースを作成することです。 彼は似たような目標を持った別のプロジェクトについて言及しましたが、 今日ではお金が基本的に生命工学へ流れていくので、 そのプロジェクトは資源の欠如が原因で停止してしまったようです。

不運なことに、 大抵のコンピュータ科学者は必要とされる生物学的背景を持っていない一方、 生物学者は通常そのようなプロジェクトを実現するための、 必要な情報を欠いています。 これ故に、Jean-Marc Vanel はプロジェクトが実現できるよう、 コンピュータ科学と生物学出身の興味を持っている人々みんなに、 彼と連絡を取ってもらうよう、お願いしています。

...次回までに

またまた、最後の言葉となりました。 まず最初に、 ノルウェーから少々悲しいお知らせがあります。 合法的に購入した DVD を再生できる機会を人々に与えてくれた仕事に対し、 ノルウェー政府は Jon Johansen を告発しました。 フランスのような国々で建設的な進展を見ていたときだけに、 フリーソフトウェアの開発に法的措置を与えることは本当に疑わしいものを感じます。 私はこのコラムが発表される以前に、 その問題全体が解決されていることを大いに望んでいます。 もしそうでなかったら、私は抗議運動を探し、それらに参加するよう呼びかけます。 もし可能であれば、Brave GNU World か私の個人的な GNU のホームページ上に何らかのリンクか情報を作成するつもりです。

しかし良い知らせもあります。 心からの感謝の気持ちを Linux Magazine France の Denis Bodor に送ります。 彼はパリで開かれた Linux Expo/Linux World で雑誌の大きな山を私にくれました。 私はようやくこのコラムがフランスで印刷されているという、 物質的な証拠を掴みました。

しかし今のところはこれでおしまいにします。 質問や意見、批判、特集されるべきプロジェクトがあれば、 ためらうことなく、私に連絡してください [1]。

日本語版翻訳者より

私が Brave GNU World を知ったのは、Georg Greve が Hurd の現在の状況に関して、 メーリング・リストに問い合わせてくれたときでした。 GNU のことを日本にも伝えることができればと、 それ以来約一年間に渡り、翻訳を続けてきましたが、 今回をもって引退することにしました。 これまで読んでくれたみなさんに感謝いたします。 とりわけ、校正係として援助してくれた明嵐さんと松嶋くんに感謝します。 もちろん、 長い間一緒に取り組んできた Georg Greve に最大の感謝の気持ちを送ります。 最後に、 この日本語訳を引き継いでくれる人が誰か現れることを大いに期待しています。