![[image of a world with a GNUs horns]](/brave-gnu-world/rungnu/brave-gnu-world-logo-sm.jpg){kind=logo}
(jpeg 7k)
(jpeg 17k)
「We run GNU」イニシアティブからのロゴ
no gifs due to patent problems
Georg の Brave GNU World にようこそ。 先月の GNU と Java の話題に付け加える形で今月号を始めます。 きっと見出しになるだけの価値はあります。
gcj
Cygnus [5] の Tom Tromey が、gcj [6] の進展を知らせるために、メールで連絡をくれました。 これは、しばらく前に egcs と合体した、gcc [7] 用の Java フロントエンドです。 gcj は Java のソースコードもバイトコードも理解し、 実行形式を作成することに加え、 クラス・ファイルを出力することもできます。
gcj のおかげで、 Java は今や他のプログラミング言語と同様に扱うことができるようになり、 そのコンパイル過程によって、性能が劇的に向上します。 その実装では、C++ と Java オブジェクトは同じように扱われるので、 それらを簡単に織り交ぜることができます。 プラットホームからの独立性が非常に高い gcc に基いており、 GNU のデバッガ、gdb がすでに gcj でコンパイルされたプログラムのために修正されているので、 非常に移植性に富んでいるという利点もあります。
もちろん、そのプロジェクトにはまだわずかな欠点があります。 最大の問題は明らかに AWT と Swing が欠けていることであり、 さらに 圧縮されたクラスや JDK 1.1 の拡張が動かないのです。 最優先なのは、 gcj を JDK 1.1 や JDK 1.2 に準拠させることと、 GUI ツールキットを取り入れることです。 しかし、これはそんなに長くはかからないかもしれません。 GTK+ に基いた AWT がすでにあるという噂が流れています。
今のところ、Cygnus から5人、そして3人のネットからの貢献者が gcj に取り組んでいます。 ところで、私にこのことを伝えるとき、 ネットからの貢献者がこの作業の非常に重要な部分を手掛けている、 という事実を Tom Tromey は強調しました。 例を挙げると、彼らの中の一人がインタープリタを記述しました。
次のプロジェクトも、大なり小なり開発者の範疇に入ってしまいますが、 カーテンの後ろを覗き見するのが好きな「普通のユーザ」にも興味を持ってもらえるかもしれません。
GNU Pth
Ralf S. Engelschall による GNU Pth [8] は GNU Portable Threads を表し、 UNIX システム上で、プリエンプティブでない、 優先度に基くマルチスレッディングを行うためのライブラリです。 今まであらゆる実装は深刻な欠点を持っていました。 POSIX スレッドに完全には準拠していなかったり、 あるいは、非常にプラットホームに特化されていたり、 大抵はその両方でした。 このことは移植性を損う原因となるので、 多くのプログラマはスレッドの利用を差し控えていました。
GNU Pth の開発で最も優先度が高いことは、 プラットホームから独立していることです。 この目標を追い求めるために、アセンブラによって解決したり、 プラットホームに特化した芸当を使ったりしないようにしています。 さらにあらゆる UNIX から派生した OS 上で利用可能な機能だけが使われています。 Unix95/98 の仕様書に載っている機能でさえ存在すると仮定していません。 次に重要なのは完全であることです。 ほとんどのスレッドの実装 - 例えば、Linuxthreads - は POSIX スレッド標準を不完全にしか実現していません。 今では、GNU Pth の実装はすでに 元となった FreeBSD の実装である uthread よりも完全であり、 まだどのような実装でも実現されたことのない、 共有メモリ標準をカバーすることが計画されています。
我々の中にいる開発者のために、いくらか技術的な詳細を差し加えておくと、 GNU Pth は完全に ANSI-C に基いており、 真のユーザ空間 M 対 1 マッピングを行っています。 このために、プログラムが実際にいくつのスレッドを持っているかに拘らず、 カーネルはたった一つの普通のプロセスしかないと考えるでしょう。
今では GNU Pth のバージョン 1.1 がすでにいくつかの性能試験に合格し、 非常に満足の行く結果を出しています。 Peter Erikssons の マルチスレッド化された FTP サーバ、pftpd が上手く動作し、 実験段階の Apache のバージョン (Apache/MPM) が、負荷が高い状況でも、良好な動作を見せました。 GNU Pth のおかげで、Apache/MPM - MPM は「複数プロセス・モデル (multi process model)」 を表します - は POSIX スレッドが元々サポートされていないプラットホームでも、 あらゆるプラットホームで使えるようになりました。
続けて、 Ralf S. Engelschall が今年 GNU プロジェクトに寄付したもう一つのプロジェクトを紹介します。
GNU Shtool
GNU Shell Tool [9] は、 小さくて、安定していて、非常に移植性の高いシェル・スクリプトを、 単一のシェル・ツールに寄せ集めたものです。
今日では、ソフトウェア・パッケージを自動的に設定し、インストールするために、 たくさんの人々が好んで GNU Autoconf [10] や GNU Automake を使っています。 この処理の間、 少なくともそのインストール過程はたくさんのシェル・スクリプトを甚だしく当てにしており、 それらの主な目的は、 一部のプラットホームでは欠けている、ある特定の機能を提供することです。 しばらくして、このことが小さなスクリプトの動物園を結果として生み出してしまい、 それらの多くは異なる場所に存在しています。 GNU Shtool は、この動物園が生み出した、 管理や配布における問題を解決しようとしています。 その主要な目的は、 ソース・ツリー中のいくつかのシェルの仕事を行うための手段を提供する、 「ブラック・ボックス」として振る舞うことです。 こうして、 共有ライブラリの作成を単純化する GNU Libtool [11] を補うものとなります。
フリーソフトウェアに関連する暗号法の重要性を十分に強調し尽くすことはできないので、 あらゆる人が次の部を読むべきです。
GnuPG
かなりの期間に渡って、Werner Koch はいくつかの利点を持つ PGP の代わりの物となる自由な実装、GNU Privacy Guard [12] に取り組んできました。 このプロジェクトに関わっている人は他にも、Michael Roth、Remi Guyomarch、 Matthew Skala など、もっとたくさんいます。 長期間の開発と試験的な期間を過ごし、 ついにこの9月の初頭にバージョン 1.0 が公開されました。
どうして GPG に変更すべきなのでしょうか。 まず第一に、GPG はドイツで開発されたので、アメリカの輸出規制が適用されません。 印刷して、郵送し、復元するという遅くて不便なやり方は不要です。 GnuPG は Open PGP standard (RFC2440) を忠実に守っており、 特許に縛られたアルゴリズムを全く使っていません。 GPG で使われている本来のアルゴリズムは 公開鍵のための DSA と ElGamal や、 対称的な暗号化の 3DES、CAST5、Blowfish や Twofish です。 さらにもっと必要であるなら、GnuPG に他の暗号モジュールを組み込むのは容易いことです。
でも、明らかに最大の利点は GnuPG はフリーソフトウェアであるという事実です。 これは企業が金をかけずに利用できることを意味するだけではありません。 もっとはるかに重要なのは、非フリーソフトウェアと比較して、 ずっと高い信頼性を実現できるということなのです。
またすでに、GPG に関連する非常に大きなアプリケーションの一団があります。 Werner Koch 自身が GNU Cryptography Library や、 自由な SSH v2 の代わりである、GNU Secure Transport Initiative に取り組んでいます。 次の開発過程に対する彼の計画として、 必要ならハードウェア・トークンに含めることのできるように、 秘密鍵をデーモンに保管することも挙げられます。
Brian Warner は Solaris や HP のようなシステム上で優れた乱数を生成できるように、 Entropy Gathering Daemon (EGD) を記述しました。 Michael Roth による pgpgpg プログラムは、 古いプログラムが改変なしに GPG を利用できるように、 PGP のコマンドライン変数を GPG 用に変換してくれます。 彼はまた、GnuPG の高水準のライブラリである、 Private Guard Glue (PGG) に取り組んでいます。
十分たくさんのメール・プログラムがすでに GPG をサポートしており、 GNOME や KDE、Tcl/Tk のフロントエンドがすでに存在するので、 GPG に切り換えるのはそう大変なことではないはずです。 他に興味深い事と言えば、GPG を使うのに、 ドイツ政府による制限を決して受けないということがあります。 ドイツ連邦経済省 (BMWi) はフリーソフトウェアだけが安全性を提供できるので、 GnuPG に基く暗号プロジェクトに資金を提供することを考慮しています。
次のプロジェクトはメイリングリスト管理者の分野に由来します。
Mailman
Mailman [13] は Python で知られる John Viega によって書かれたメーリングリスト管理ソフトウェアです。 その開発者の集団は、Barry Warsaw、Harald Meland、Ken Manheimer や Scott Cotton を加えて、「Mailman 同人グループ」へと発展しました。
これを読むと、 長い間使用されたプログラムで十分やり尽くされた分野ではないかと思われるかもしれませんが、 確かに注目してみるだけの価値が、この Mailman にはあります。 ウェブ・インターフェースを経由して管理することができるといった、 よく使われる特徴はさておいて、 それには SPAM 対策機能が組み込まれており、 メールをニュースに変換するゲートウェイが統合されているのです。 また、一つのリストに管理者やモデレータが複数人居ても構わないし、 たくさんの人が好んでいる MIME 形式でダイジェストを送ることだってできます。 ストレスの溜まったメイリングリスト管理者のみなさん、 よく見てみた方がいいですよ。
最後に幾つかの考えを挙げて、今月号を終えることにします。
おしまいに...
まず第一に、Amiga が Linux カーネルを基盤にした新たなオペレーティング・システムを作ることを公表したために、 GNU/Linux 命名法を使用する理由はさらに重要性を増したようです。 このシステムが自由でないのは明らかです。 これは退行的だと思いますが、我々のシステムとの違いを明確にするため、 異なる名前を掲げるべきであることを示しています。 このことにより GNU/Linux が良い選択肢であるように思われるのです。
また、皆さんが「We run GNU」イニシアティブ [4] の紹介の後、 好意をもってフィードバックして下さったことに感謝しています。 ここ二週間というもの、次々と新たな絵が送られて来ましたから、 ウェブサイトを更新しなかった日はありませんでした。 - これは私が望んでいたことです。 今回、特に上記のロゴを作られた Stefan Kamphausen には感謝しています。
最後に、私は有志を探しています。 10月の終りに、 大きな「Linux-Park」のあるミュンヘン(ドイツ)で「Systems」が開催されます。 この時、私は水曜日に GNU プロジェクトについてスピーチをします。 GNU/Debian/GNOME の場所には、一日か二日の間、 番をしてくれる有志がまだ必要だという計画です。
手助けしてくださるみなさん、ならびに、もちろん意見、批判、 質問や特集記事の要望をお持ちの方は、 下記の電子メールアドレス [1] までお願いします。
| 情報 |
|
[1] 意見、批判や質問は Brave GNU World <column@gnu.org> まで
|
GNU のホームページに戻る。
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
Please send comments on the Brave GNU World column to column@gnu.org, send comments on these web pages to webmasters@www.gnu.org, and send other questions to gnu@gnu.org.
Copyright (C) 1999 Georg C. F. Greve, German version published in the Linux-Magazin
Permission is granted to make and distribute verbatim copies of this transcript as long as the copyright and this permission notice appear.
Updated: Last modified: Mon Sep 6 17:31:28 JST 1999