[DE | EN | FR | JA | ES]

またまたGeorgのBrave GNU World にようこそ。 小さいけれど、比較的有益なプロジェクトで始めたいと思います。

sel

Thomas Klugeによるsel [5] は、 シェル・スクリプト用の快適なファイル・マネージャです。 selの補助により、利用者はファイルやディレクトリーの名前を選択し、 それにたいしてコマンドを実行できます。 簡単なechoコマンドの場合、シェル・スクリプトを書く人が望むように、 選択を標準エラー(訳注)でとることができます。

(訳注 2000-10-12) ドイツ語原文は``Standardausgabe''、 また英訳は``stdout''でしたが、 標準出力は実際、 端末への出力になっていて、 そのままでは使うことができませんでした。 がんばれば一応 VAR=`sel -c 'echo % >&2' * 3>&1 >&2 2>&3 3>&-` のように標準出力でもとれるのですが、 sel -c 'echo % >&2' * 2>FILE のように標準出力以外でとるのが素直でしょう。

比較的複雑でエラーだらけのダイアログ・スクリプトぬきでは、 このての機能をシェル・スクリプトに入れることは、 できませんでした。 selのおかげで今ではcursesライブラリーを基盤にした小さな (マニュアル・ページと説明文字列を含むCソース・コードのアーカイブが20kB) ツールが利用できるようになりました。

selはcurses自体の制限による制限があるので、 cursesライブラリーを使うことが唯一の真の弱点です。 selはGNU General Public Licenseの下でリリースされるFree Softwareで、 自分のニーズにあわせた修正を作者はあからさまにすすめています。

しかし今回、私の個人的意見はひかえておきましょう。 そのような小さなプロジェクトの作者たちが自分のプロジェクトに「価値がある」と考えずに、 私に連絡してこなかった、 ということが過去においてしばしばありました。 私は、これとは全く意を異にするものです。 これら小さなプロジェクトは、 私の目からは特に、運動の中の非常に有意な部分を構成しています。 たとえ、それらが時折新しい開発の洪水の中で多数の認識をえられなくても、です。

というわけで、 このコラムはこれら小さなプロジェクトにフォーラムを提供するには良い場だ、 と私は思います。 ですが私は、すべての所にいられるわけでも、 すべてのものを見られるわけでもありません。 だから、あなたの手助けが私にいるのです。 もしそんな小さなプロジェクトをあなたが書いたり、ネット上であたったりしたら、 どうか私までお知らせください。 最近は電子メールのアドレス [1] も十分につたわっているとは思いますが。

LinCVS

LinCVS [6,7] は、すでにかなり大きなものです。 これは、Concurrent Version System (CVS) のクライアントのフロントエンドです。 このプログラムのルーツは、 機能性や安定性についての自分の要求をみたすCVSのフロントエンドがGNU/Linux配下にないことをTilo Riemerが気づいた1999年の初頭にさかのぼります。 つまり、多くのプロジェクト同様、個人的な悩みの解消のために始まったわけです。

彼が参照したのは、WinCVSでした。 ところがこれは、 すでにCVSの管理ファイルにある情報を、ひっきりなしに利用者にたずねるのです。 その上、フロントエンドの多くは、複数のプロジェクトを管理することができません。 プロジェクトを始めたとき、Tilo RiemerはCVSの初心者でした。 だから彼にしては非常な使いやすさと高い安定性が、LinCVSに必要でした。

実際LinCVSの使用は並はずれて簡単です。 利用者があたえる必要のあるのは、 プロジェクトのインポートやチェックアウトの情報のみ、 ということが、 もっとも良い特性の1つです。 同様に多くの利用者にとっての利益であろうのは、 LinCVSでは、 CVSで管理しているプロジェクト全体のディレクトリー構造の検索や、 それを自動的に作業場所にくわえることができて、 さらに管理できるプロジェクト数の上限がないことです。 CVS管理されたファイルとそうでないファイルの分離は、 (マウスの右ボタンで出てくる) 情況メニューのように非常に直観的です。

GPLで許諾されるこのプロジェクトの作者は、 Tilo Riemer、Wim Delvaux、Helmut Koll、Sven Trogischです。 現在、 LinCVSの外で行われた変更の自動検出に処理能力をかなりとられているため、 これの最適化が最大の問題です。 また、このほかにしなければならないことのリストには、 sshの完全サポート、 旧版のチェックアウトの単純化、 枝のさらに容易な合併、 WinXXへの移植があります。 作者たちはみなLinCVSの作業を片手間でしているので、開発者、 特に文書化をしたい人たちをもとめつづけています。

すべてを考慮にいれて、私は個人的にかなりLinCVSを気にいっています。 作者らはQtの使用を決めたのですが、そのツールキットの選択のみが、残念です。 これとautoconf/automakeによる構築能力の欠如が、 私に発見できた唯一の消極面でした。

Dia

特に、 もしあなたが構造をもった図の作成に頼っているのなら、 Dia [8] は、きっと興味深いことでしょう。 このプロジェクトは元来、Alexander Larssonによって始められましたが、 昨年末以降、James Henstridgeが管理者です。 もちろんDiaの開発に関係した人々はもっと多くいましたが、 そのリストはあまりにも長すぎて、ここでは示すことができません。

Diaの機能性は、独占的なプログラムである「Visio」のそれに匹敵します。 その仕事は、標準的な対象物からできている構造をもった図の作成です。 ですのでその中には、たとえばフローチャート、 ネットワークやUMLの図のためのモードがあります。 しかし、単純な図面の作成のため、若干の一般的な図形関数もあります。

このプログラムは、 EPS、SVG、CGM、PNGのように膨大な数の出力フォーマットをもっており、そして、 基盤としているGTK+ツールキットのwin32への移植のおかげで、 win32配下でも使うことができます。 これで (UNIXとwin32で使用する人の間での) 情報交換の問題もおきないでしょう。

非常にすばらしいのは、拡張性です。 もしあるタイプの図が未サポートであったら、たいていの場合、新しい対象物は、 プログラミング技術の不要な、簡単なXMLファイルで追加できます。 未知の形式のために取込みフィルタを作成することだけは、まだ少し難しいですが、 これがもっと簡単になるよう作業中です。

「Visio」の図の取込みフィルタは、 特に多くの利用者が切実に待ち望んでいたものです。 しかし、Visioは独占的なプログラムの独占的な形式です。 取込みフィルタを作ることは、見た目ほど簡単ではありません。 これは、 制御もアクセスもできないデータ形式で利用者データがはめられた典型例といえます。

作者たちには現在、 この形式を自由にリバース・エンジニアするだけの能力がありませんが、 Visioのファイルを読み書きできるライブラリーを書くことに成功した人への報酬が、 Free Software BazaarのID 990524Aで見つかるでしょう [9] 。 私がこれを書いている時点で、提示されている報酬は、3000 USDです。 ですから、もしたまたまあなたに余暇が少しあってお金を少し必要としているならば、 見にいってみるとよいでしょう。

他の計画は、更に多くの図のタイプの実装と、Pythonとの結び付きの完成です。 またDiaには、文書がもっと多く必要で、ボランティアは、大歓迎です。 もし情報がもっと必要ならば、Diaのメーリング・リストを見るといいでしょう [10] 。

次の2つのプロジェクトは密接に関係しているので、まとめて紹介したいと思います。 これは、多かれ少なかれやがて起こるだろう技術についての記事なのですが、 ほとんどの人たちに関心があるにちがいない、と私はまだ思ってます。

libCIMとPaulA

LibCIMとPaulA [11] は、 ドイツの会社ID-PROのいま評判のプロジェクトで、 両方ともGNU General Public Licenseのもと、 Free Softwareの精神で配布されています。

特徴をわかりやすくするため、 背景について簡単に紹介をしておいた方がきっといいでしょう。 CIMとはCommon Information Modelのことで、 システム情報をモデル化するためのオブジェクト指向の概念です。 その起源は、TivoliやOpenViewなどのような、 いわゆるNetwork Management Systems (NMS) です。 それらの役目は、大きなネットワークの中で情報の交換と、 その交換された情報に基づくシステムの管理、という分野にあります。

別々なNMS間で通信できるように、共通のプロトコルが必要でした。 XMLにおけるカプセル化やHTTPによる転送と同様、 CIM標準を定義した "Web-Based Enterprise Management" (WBEM) イニシアチブは、 この要求から生まれました。 上記の標準は、 "Distributed Management Task Force" (DTMF) [12] で公開されました。 背景は以上です。

2つのNMS間の通信の場合、片方はクライアントで、 もう片方はいわゆる "CIM Object Manager" (CIMOM) というサーバーになります。 クライアントがサーバーにアクセスを行うとすると、 サーバーのシステム情報を読んだり、変えたりできます。 CIMがあらゆるタイプの構造のネットワークをモニターできるよう設計されたために、 少し複雑すぎるのでここでは詳細を述べません。 原理の理解のためなら、 CIMが基本と派生のクラスを定義することを知ることだけが、重要です。 サーバーが読んだり、 操作したりしているこれらクラスから具体化されたのが、 オブジェクトになります。

もし上記があなたの技術的理解をこえていたならですが、 次のことは単に信じてください。 この原理により、 ハードウェアやOSの具体的詳細を知らずにネットワークを管理できるのです。

libCIMは、CIMオブジェクトでのプログラミングを可能にするPerlのライブラリーで、 オブジェクト群をXMLで直列化し、HTTP経由で転送する機能もあります。 つまりlibCIMは、CIMのクライアントやサーバー (CIMOM) の作成に使えるのです。

PaulAは、libCIMを使ってCIMオブジェクトを実装するサーバー/CIMOMです。 PaulAの1つの可能な用途は、 別々なシステムのうごくディストリビューションについて知る必要なしに、 標準化された方法でGNU/Linuxシステムを管理することでしょう。 明らかにこれは、管理者の生活を更に安直にしてくれることでしょう。

現在の状態は、まだ「α以前」です。 したがって、日常的に使うことができるまでにはもうしばらくかかるでしょう。 ですが、libCIMとPaulAの開発者のAxel Miesen, Volker Moell, Eva Bolten, Friedrich Fox, Marcel Hildは、 数か月以内に安定した「正式版」 (production system) ができると望んでいます。 この正式版は、色々なCIMシステム間での相互運用性の照合に使われるでしょう。 しかし今のところ、 多くのプロバイダ (実際の作業をするコード) を、書かなければなりません。

これは間違いなく非常にホットな分野ですし、 Tivoliのようなソフトウェア・パッケージのライセンスは極めて高価ですし、 まれにしかこういった技術のエキスパートがいません。 ですから、 このプロジェクトへの参加に興味のある開発者は、 是非そうすることをおすすめします。

Hans Fuchsの要請により、 比較的定期的に尋ねられる疑問に答えるため、紙面の残りを使おうと思います。

Sourceforgeについてどう考えるか?

Hans Fuchsは、Sourceforgeマシン [13] の成功についての意見を書いて、 電子メールで送ってくれました。 Sourceforgeは、Free Softwareの開発者に、ウェブ空間、FTPサーバー、 メーリング・リスト、 「プロジェクト.sourceforge.net」ドメーンといったインフラを、無償で提供します。 彼の意見は、サーバーの所有権と運営がVA Linuxであるという事実に基づいています。

私は個人的に、会社の利他主義についてはこう考えています。 GNU/Linux分野の会社は、 「何らかのものを還元する」という動機以上のものを期待する場合も少なくはありませんが、 これにはたいしては、若干の健全な程度の懐疑心をもつのがよい、という立場です。 我々は利他主義に頼る必要はない、と私は思います。 この分野の他の会社のように、VA Linuxは、 活発で健全なFree Softwareの開発によってなりたっています。 ですから、Sourceforgeのサービスは、自分自身の基盤強化に役立っているのです。 さらに、このサービスはVA Linuxの大衆イメージにプラスの効果をあたえ、 多くの興味深いプロジェクトを注目できることになるのです。

しかし、 他の場所へのサーバーのミラーがコミュニティーに横槍を入れることになるかもしれない、 という潜在的な脅威があらわれるでしょうか?

私は個人的に、この危険は比較的小さいと見なしています。まず第一に、 プロジェクトへのアクセスを食いものにしようとすることによってVA Linuxがかちとれるものは、何もありません。 その結果生じるイメージ損失は厳しくて、利得多様性を越えてしまうでしょう。

作者はすべて、ソース・コードのローカルなコピーをもってもいるはずで (ネット上にひろまったリリースはいうまでもないでしょう)、 開発はどこででもできるでしょう。

その用途があることとFree Softwareの開発に役立つことを私が信じる理由は、 そこにあります。 しかし、 それほど中央集権化されてない情況のある、 別な場所でこの概念を実行することも、 支障にはならないでしょう。

...そして飛行機に

今月はここまで。 私はまさにあと数時間でカリフォルニア行の飛行機に乗っているでしょう。 それでも電子メール [1] は届きますので、 話題になりそうなこと、お考え、質問、プロジェクトの提案は、 ためらわずにお送りください。