[CN | DE | EN | FR | JA | ES | KO | PT | ZH]

Brave GNU Worldのまた別な号へようこそ。 第48号 [5] の一部 ("Free Software Laptops") を削除したドイツのLinux-Magazin誌と、 Brave GNU Worldのあいだで問題になり、 先月、 休載になったことをおわびしたいと思います。

このことで、 あまりいい気分でなくなり、 先月は書けなくなってしまいましたが、 相当の議論の末、 これは過去の話となり、 二度と起きないでしょう。

Skidbladnir

今月の最初の記事は、 何人かの人の説明と同じくらい神秘的かもしれないSkidbladnir [6] プロジェクトです。作者のLars Brandは、 Computer Aided Innovation (コンピュータ補助機能) むけのプログラムや情報のツールボックスである、 と言っています。

この背景はおそらく未知ですが、 多くの読者のみなさんの興味と、 Larsの提供努力もあるので、 これをここで差し控えるべきではないでしょう。

Skidbladnirの科学的背景は、 英語ならば "Theory of Inventive Problem Solving;" (発明的な問題解決理論) の略であるTIPSといい、 ドイツ語やロシア語ではTRIZというものです。 この理論は、 1946年当時、 陸軍の特許技士であったAltschuller教授にさかのぼります。

Altschuller教授が、 自分の理論の始まりについて知らせる手紙をスターリンに送ったとき、 彼は即刻、 拘束され、 不審対象者キャンプに送られました。 拘束期間中、 さまざまな科学分野の教授らと多く会い、 多数のさまざまな原理についての知識を組合せることを知りました。

キャンプから解放され、 望ましからざる人物として60年代末から70年代半ばまでを過ごし、 自分の科学的労作のための基金を調達するため、 彼はその成果をSF小説として出版し始めました。 G. S. Altow著 "Der Hafen der steinernen Stürme" ("Harbor of stony storms") を参照。 (著者のコメント: 題名は実際、 どう英訳されているのか、 というより、 そもそも英訳されたのかどうか、 よくわかりませんでした。 情報求む。 (訳注: 題名を直訳すれば「石のような嵐の港」ですが、 これが和訳されたかどうか、 訳者にもよくわかりませんでした))

TIPS理論は、 しばしば繰り返されている抽象的問題とその解放、 科学の学科や産業分野からの独立という原理に基づいています。 4万件のとびぬけた特許を分析したとき、 これらすべてが、 だいたい40とおりの基本解を基にしていることがわかりました。

この理論のもうひとつの基本原理は、 技術体系の発展が、 ある傾向にしたがうこと、 そして基本的な発展には、 異分野からの科学成果の流入である、 ということです。

この記述は、 問題解決戦略の抽象化で、 よく使われる例は、 「一辺が1mの鋼鉄の立方体を、 クレーン、 ロープなどの道具を使わずに、 深い穴から出す。 ただし投げるのは禁止。 10分間で3つの解法を出すこと」 というものです。

ソフトウェアでこういう問題などを解くいちばんおなじみのプロジェクトは、 たぶん ―この分野ではありがちなことですが― 独占的で、 非常に高価なTechOptimizerです。

Skidbladnirは、 Free Softwareでこの機能を提供しようとするものです。 インストール用のものをのぞくと、 このプロジェクトの構成要素には、 技術的矛盾を解決する基本原理をふくむandax、 ウェブでのブレーンストーミング用のsporadikus、 250種類もの影響度をあげられるperplexusがあります。

プロジェクト自体は、 完結していませんし、 まだとても使い易いとはいえません。 また影響度データベースは、 Larsが思っているほど大きくはなっていません。 特に、 効果的な組合せのできるようになる影響度のネットワークには、 拡張が必要でしょう。

以下に簡単な例を挙げます。 (a) 発光物質が紫外線を可視光に変える (b) 適度な粒度の散布金属が発光を抑える (c) エンジンの可動部が故障する前に、 金属の小片が油に落ちる この3つの事実を組合せることで、 油に発光物質を混ぜておけば、 油の発光が止まった時点で、 機械の故障に先立って、 交換すべき部品がわかる、 ということになります。

状況は実際、 ふつうもっと複雑で、 大きな影響度データベースが必要であり、 技術的著述を収集しなければなりません。 それはたいくつで、 作業集約的な仕事です。

Skidbladnirは、 Perl、 PHP、 MySQLで書いてあり、 GNU General Public License (GPL) の下で公開されています。 独占的なプロジェクトとくらべると、 Skidbladnirには比較的少しの影響度しか登録されていませんが、 その中には、 たぶんその類の中で最初のものとしてのソフトウェア影響度はもう入っています。

どんなかたちでも、 特にフィードバックをくださる開発者、 利用者の手助けは、 歓迎です。 実生活の問題や影響度についてのさらなるデータも、 いただければ幸いです。

中長期的に、 Free Softwareがこの分野で並はずれて成功するであろうことを、 Larsは確信しています。 それは、 TIPSとFree Softwareが、 知識を保存し、 入手しやすくする、 という考えに基づいているからです。

こういう洞察、 手法をだれでも使えるようにするのは、 百科辞典と似ていなくもない、 支援に値する、 とても重要なプロジェクトといえます。

多くの潜在的な利用者には、 独占的な解を使う余裕のないせいで、 この分野の市場参入障壁も、 減ることになりますので、 副作用として、 技術分野の復興の手助けも可能になります。

この分野の方や、 興味をおもちの方は誰でも、 ご覧になることをおすすめします。 背景についてのさらなる情報は、 ウェブ [7] にもあります。

Lush

今回2番目のプロジェクトも、 科学指向の労作ですが、 それにかぎられてはいません。 Lush [8] は、 大きな数値や、 グラフィカル・アプリケーションのいるエンジニア、 実験家、 科学者を主に対象とした、 オブジェクト指向のプログラミング言語です。

Lushの設計では、 3とおりの別々なプログラミング言語アプローチの強さを1つに合わせよう、 としています。 Lushは実際、 3つのプログラミング言語を1つにしています。 第1は、 自動ゴミ集めと、 弱い型づけをもち、 解釈される、 動的なLISP風言語です。 第2の言語は、 コンパイルされ、 同じ構文で強い型づけをもつ辞書的言語です。 第3の言語はCで、 1つのプログラムや、 単一の関数の中でさえ、 Lushの構文とまざりあいます。

Lushは1987年に、 当初は「SN」という名前で、 神経ネットワークのシミュレーション用スクリプト言語として開発され、 コンパイラつきの、 完結したプログラミング言語に発展しました。 開発の立役者は、 米国ニュージャージー州Holmdelのベル研 (後の「AT&T研」)、 フランスはパリのNeuristique S.A.、 米国ニュージャージー州PrincetonのNEC研です。

Lush/SNがAT&Tで部内研究や開発プロジェクトに何年も使われた後、 関係者らは、 GNU General Public License (GPL) に同意し、 LushをFree Softwareとして再ライセンスしました。

今日、 このプロジェクトは、 Brave GNU Worldのアンケートに答えてくれたYann LeCun、 Princetonの「NEC Labs America」に所属し、 世界中の多数のボランティアたちから支援を受けているLeon Bottouらが管理しています。 ボランティアたちの名前を一部挙げると、 Fu Jie Hang、 Patrice Simard、 Patrick Haffner、 Yoshua Bengio、 Pascal Vincent, Jean Bourrelly、 Xavier Drancourt、 Secil Ugurelたちです。 ボランティアはいつでも歓迎です。

最初には科学者、 研究者、 学生用のFree Softwareでの代替Matlabとして開発されたのですが、 Lushは、 完結した多目的の言語となっています。 Cとの安直な統合のおかげで、 Lushは、 快適なGUIアプリケーションで、 分散機能を収集するための統合や、 スクリプティングにとても向いています。

Lushには、 GNU Scientific Library (GSL; 第35号 [9] 参照) のような、 数値科学ライブラリー、 グラフィカル・ライブラリー、 オーディオビジュアル・ライブラリーへのひもづけがあるので、 既存のライブラリーの統合も、 前述の統合で非常にやさしくなるわけです。

GSLのサポート度をPythonとLushでくらべると、 Lushでは約4000個もの関数がサポートされていて、 現時点で数百をサポートしているPythonにくらべ、 なかなか良さそうです。 構文は、 Perlよりも明白で、 Schemeを学ぶよりは簡単なはずです。 そして、 OctaveやMatlabと速度をくらべると、 環境にもよりますが、 15〜300倍も高速です。

このような長所により、 Lushは、 興味深い選択肢、 そして、 一見の価値あるもの、 といえるでしょう。 Lushは既に、 素朴な月面着陸のようなゲームにも使われていて、 Lushのホーム・ページでスクリーンショットを見ることができます。

LushはCで書いてあり、 伝統的にGNU/Linux、 Solaris、 Irix、 OpenBSDで動作します。 また、 2003年2月からはCygwin Windowsへの移植も有効になりました。

このプロジェクトの問題には、 コンパイラの設計が10年以上前であったために、 奇妙で融通のきかない制限があることが、 あげられます。 そのため、 コンパイラの書き直しが、 ToDoリストに載っています。

このリストには、 文書体系の改良と同様、 さらなるライブラリーのサポートの追加もあります。 Lushへの雛型機構の追加も、 中間目標として計画されています。

さらに、 Mac OS-Xへの移植にも意欲的で、 ボランティアをさがしています。 Lushへの自動的取込み (automagical inclusion) のための、 C/C++のヘッダー・ファイル用に自動化されたパーサーも、 非常に便利なプロジェクトになることでしょう。

もし米国にお住まいであれば、 もう間接的にLushと接触している機会をおもちです。 NCRによるATMの一部では、 預け入れられた小切手の累計を自動的に読み取る埋込みDSPプロセッサで、 Lushの生成したコードが使われています。 そして、 Lushで書いた高速小切手読取りエンジンは、 米国では、 預金された小切手のうち約一割を読みとっています。

jMax

Brave GNU Worldの常連読者のみなさんならご存じでしょうが、 Free Software Foundation Europeは、 AGNULAプロジェクト [10] と提携しています。 このプロジェクトは、 職業的なオーディオ・ユーザー用のFree Software GNU/Linux 配布物件をまとめあげることを目的としています。

その他にAGNULAプロジェクトと提携しているのは、 "Institut de Recherche et Coordination Acoustique/Musique" (IRCAM) つまり、 フランスはパリのCentre Pompidouの音楽センターです。 (ドラフト注: 仏語を英訳すると``Institute of Research and Acoustic Music/Coordination''あたりか? となると、「生音楽調整/調査研究所」?) IRCAMの書いたアプリケーションのひとつには、 jMax [11] があります。 これは、 対話的マルチメディア・アプリケーション用のグラフィック開発環境です。

伝統的に、 音響アプリケーションには、 しばしば特定のハードウェア用に書かれ、 そのためプラットホームに依存する、 という問題がありました。 ハードウェアの短期開発のせいで、 常に3年おきに、 新しいプラットホーム用のため、 プログラムは書き直しが必要で、 さもないとそのプログラム用の音楽が失われる、 という危険があったのでした。

そこで、 特定のプラットホームと無関係な、 純粋ソフトウェア解決策の開発が、 動機付けられたわけです。

jMaxで採用されたこの方法論で、 振動発生、 信号フィルター、 音効、 入出力モジュール、 スライダ、 DSP、 アンプといった基本要素群をお互いに組み合わせ、 いわゆる「パッチ」へと組み上げることが、 可能となります。

こういったパッチで、 構成要素を統合したり、 ほぼ無限の複雑さをもつ構成に組み合わせたりすることができ、 デジタル信号処理、 音効、 合成のあらゆる型、 種類の実装が一般的に可能です。

この方法論の実装のひとつは、 ミュージシャンたちの間ではそこそこおなじみの、 独占的な「Max」です。 Maxのプラットホーム独立版の作成を意図して、 1995年、 jMaxが始まりました。 1999年中ごろ、 GNU General Public License (GPL) の下で、 Free Softwareとして公開されました。

François Déchelleと、 Patrice Tisserandを中心とした、 IRCAM jMaxチームが、 このプロジェクトに取り組んでいます。 Brave GNU World標準のアンケートに回答してくれたFrançoisは、 jMaxの主な特長を、 GNU/Linux、 Mac OS X、 Windowsでうごくという、 プラットホームからの独立性、 そして、 MaxやPDのような同一方法論の他の実装と比較したときの高い柔軟性である、 とみています。

カギとなる特長のひとつは、 jMaxが2つの構成要素でできていることです。 中心的構成要素は、 Cで書いたリアルタイム・エンジンのサーバーで、 これが仕事を全部こなします。 GUIでエンジンをうごかすとき、 別なGUIとして書くことも、 プラグイン環境 (LADSPA) にエンジンを統合することもできます。

サーバーはふつう、 Javaで書いたクライアントから制御します。 問題を最小にしつつ、 なるべく多くのプラットホームでクライアントがうごくように、 Javaを選んだわけです。 残念ながら、 Javaの状況は、 Free Softwareにかんして問題がないわけではありません。

Javaへの依存性

Javaの問題とは、 技術仕様や、 実装のことではありません。 一部の方は違うご意見をおもちでしょうが、 それがFree Softwareでの問題の原因、 というわけではないのです。

問題の原因とは、 Java自体の開発、 頒布のされかたです。 基本的に、 ひろく普及している実装は、 たった2つでしかも独占的だからです。 つまり、 片方はSun、 もう片方はIBMが、 管理をしています。 許諾料金なしで頒布される場合もありますが、 Free Softwareとするに必要な自由を提供してはくれません。

結果として、 これらのプラットホームでうごく各アプリケーション ―たとえそれがFree Software許諾の下であったとしても― は、 利用者の自由を危険にさらすことになります。 ちょうど、 Windows上でうごくFree Softwareと似てなくもない状況です。

JavaをすべてFree Softwareで実装しようとする先導者たちや、 アプローチが、 一部にあります ("GNU and the Java language" [12] 参照)。 しかし、 支配的な参照実装が独占的なので、 自由なプロジェクトでも、 独占版の機能を再実装する必要があります。

必ずしもすべての開発者が、 勝てないかもしれない、 えこひいきされた競争に、 参加したいわけではないかもしれません。 Free Softwareが不利になり、 そのため機能の一部が提供できないのであれば。

Javaアプリケーションの開発者たちが、 独占的なJava実装のすすんだ機能を使うときには、 たいてい、 Free SoftwareのJava実装ではさっぱりうごかないことがあり、 結果として、 独占的なプラットホームに依存してしまうことになります。 Windowsだけでうごいて、 Free Softwareのオペレーティング・システムで使うことのできないFree Softwareと、 全然似てなくもない状況です。

これがまさにjMaxクライアントの問題です。 AGNULAに独占的ソフトウェアを追加するなどということは、 全提携者にとって問題外ですから、 jMaxに、 GUI機能を完全装備させることは、 AGNULAに可能ではないかもしれません。

pyMax

どの選択肢も問題解決を保証してくれなさそう ―詳細がFSF Europeのホーム・ページ [13] にあります― なため、 クライアントからJavaをのぞいて、 Pythonで再実装することが、 決断されました。

Pythonの選択は、 Javaとならぶプラットホームからの独立性、 短期開発の可能なこと、 そして本質的には、 完全なFree Softwareであることから、 感化されたものです。

しかしIRCAMがクライアントを時間どおり完成できるのかどうかは、 明らかではありません。 そこで、 jMaxのPythonクライアントを書く手助けをしてくれるボランティアが、 求められています。

Françoisによると、 IRCAMは、 大きな約束はできないものの、 Pythonクライアントに取り組む人たちへの優先的サポート提供と、 営業日で24時間以内の応答保証を申し出てはいます。 もしご興味がおありであれば、 jMax開発者メーリング・リスト [14] をのぞいてみるといいでしょう。

このへんで

今月のBrave GNU Worldはこのへんで。 もしかして興味深いプロジェクトを見かけたら、 お知らせください。 宝石を見つけてくれるのは、 往々にしてコラムの読者なのです。 たとえばLushの記事は、 Brave GNU Worldロゴの作者である、 Stefan Kamphausenからの助言によるものでした。

いつもどおり、 一般的なコメント、 ご質問、 お考え、 コメントをいつものアドレス [1] までお願いしておきます。