ECMA 標準の使用: Miguel de Icaza とのインタビュー

 

大胆なオバサンジョ

2001 年 12 月

概要: このインタビューでは、GNOME と Ximian の創設者である Miguel de Icaza が、UNIX コンポーネント、Bonobo、Mono、Microsoft .NET について語ります。 (6ページ印刷)

大胆なオバサンジョ:あなたは最近、XimianMicrosoft .NET 開発プラットフォームのオープンソース実装を作成すると発表したため、プレスに参加しています。 最近の騒ぎの前は、 GNOME と Bonobo で行った作業で注目に値します。 以前のプロジェクトから Mono までのフリー ソフトウェアへの関与の概要を簡単に説明できますか?

Miguel de Icaza:私は過去4年間、さまざまな分野(organization、ライブラリ、アプリケーション)でGNOMEプロジェクトに取り組んできました。 以前は Linux カーネルで作業していたので、SPARC ポートで長時間働き、ソフトウェアのレイドと Linux/SGI の作業を行いました。 その前に、私は真夜中のコマンダーファイルマネージャーを書いていました。

大胆なオバサンジョ:Let's Make Unix Not Suck シリーズでは、UNIX 開発がコードの再利用の欠如によって長い間妨げられてきたことをメンション。 具体的には、Brad Cox のソフトウェア集積回路の概念をメンションしました。ソフトウェアは主に再利用可能なコンポーネントを組み合わせて構築されています。これは、コードの再利用がどのように行われるかを示すビジョンです。 UNIX は、再利用可能なコンポーネントを使用して、小さなプログラムの出力をパイプで接続してプログラムをビルドするという概念に基づいて構築されていることを述べ、多くの人が引数に反論しています。 この反論に対するあなたの意見は何ですか?

Miguel de Icaza: さて、この論文ではその質問に詳しく取り組みます。 "パイプ" は完全なコンポーネント システムではほとんどありません。 これは、情報を処理するために一部の既知のプロトコル (行、文字、バッファー) で使用されるトランスポート メカニズムです。 プロトコルには情報フローのみが含まれます。

詳細は紙に 記載されています。 [Dare— "Unix Components: Small is Beautiful" というタイトルのセクションを確認してください。

大胆なオバサンジョ: Bonobo は、基になるベースとして CORBA を使用して UNIX コンポーネント アーキテクチャを作成しようとしました。 代わりに Mono に焦点を当てることにした理由は何ですか?

Miguel de Icaza: GNOMEプロジェクトの目標は、不足している技術をUnixに持ち込み、デスクトップアプリケーションの現在の市場で競争力を持たせました。 また、言語の独立性が重要であることを早い段階で認識しました。そのため、GNOME API は標準を使用してコーディングされ、API を他の言語用に簡単にラップできるようになりました。 Microsoft の API は、Unix 上のほとんどのプログラミング言語 (Perl、Python、Scheme、C++、Objective-C、Ada) で使用できます。

その後、API をカプセル化するためにより優れたメソッドを使用することにしました。また、CORBA を使用してコンポーネントへのインターフェイスを定義し始めました。 再利用可能な言語に依存しないコンポーネント、コントロール、複合ドキュメントを簡単に作成するためのポリシーと標準的な GNOME インターフェイスのセットで補完しました。 このテクノロジは Bonobo と呼ばれます。 Bonobo へのインターフェイスは、C、Perl、Python、Java 用に存在します。

CORBA は、粗いインターフェイスを定義する場合に適しており、ほとんどの Bonobo インターフェイスは粗いです。 唯一の問題は、Bonobo/CORBA インターフェイスが小さなインターフェイスに適していないということです。 たとえば、Bonobo/CORBA コンポーネントを解析する XML は、C API と比較して非効率的です。

私はまた、ある時点で書いた:

.NET に対する私の関心は、.NET が行うことの一部を達成するために GNOME プロジェクトで以前に行った試みから来ています。

  • 複数の言語に公開されている API
  • 言語間統合
  • コントラクト/インターフェイス ベースのプログラミング

そして、私はいつもJavaについて様々なことを愛していました。 私はちょうどあなたが与えるか、取ることになっていたJavaコンボを愛していませんでした。

共通のオブジェクト ベース (GtkObject) を持ち、API コントラクトと、他のユーザーがプログラミング言語用に API を簡単にラップできる形式に従って、多くの言語に公開される API を試しました。 ラッパーをすぐに生成するために使用される API のスキームベースの定義も用意されています。 このソリューションは、多くの理由で最適なソリューションです。

CORBA で行ってきた言語間統合は、COM のようなものですが、マーシャリングペナルティが課されます。 これは、inProc 以外のコンポーネントに対してかなりうまく機能します。 しかし、inProcコンポーネントの場合、ストーリーはかなり悪いです:私たちが使用できるCORBA ABIがなかったため、結果はとても恐ろしいので、私はそれを説明する言葉がありません。

この問題の上に、ライブラリが急増しています。 そのほとんどは、コーディング規則に非常に正確に従っています。 しばらくの間、彼らはそうしないか、私たちは他の誰かによって書かれたライブラリを採用するでしょう。 これにより、強力な結果として、複数のプログラミング モデルを実装するライブラリが混在し、場合によっては割り当てと所有権ポリシーが異なる場合があります。しばらくすると、5 種類の "ref/unref" 動作 (CORBA ローカル参照、不明なオブジェクトの CORBA オブジェクト参照、オブジェクト ラッパーの参照カウント) が処理され、これは大きな混乱に変わっていました。

私たちはもちろん、これらすべての問題を修正しようとしていますが、物事はより良く見えています(GNOME 2.xプラットフォームはこれらの問題の多くを解決しますが、それでも)。

.NET は Win32 開発者向けのアップグレードのように思えました。長年にわたって設計された API を扱うときと同じ問題があり、多くの不整合がありました。 だから私は自分のアプリケーションを構築するためにこの新しい「新鮮な空気」のいくつかを利用できるようにしたいと思います。

大胆なオバサンジョ: Bonobo は COM と OLE2 に若干基づいています。Bonobo インターフェイスはすべて Bonobo::Unknown インターフェイスに基づいており、オブジェクトの有効期間管理とオブジェクトの機能検出という 2 つの基本的なサービスを提供し、次の 3 つのメソッドのみが含まれています。

   module Bonobo {
      interface Unknown {
         void ref ();
         void unref ();
         Object query_interface (in string repoid);
      };
   };
      

これは、次のメソッドを持つ Microsoft の COM IUnknown インターフェイスによく似ています

HRESULT QueryInterface(REFIID riid, void **ppvObject);
ULONG AddRef();
ULONG Release();

.NET が COM の終わりが近くにあるという事実は、Mono が Bonobo の終わりを綴るということを意味しますか? 同様に、.NET が半透明の COM/.NET 相互運用性を持つ予定であることを考えると、Mono と Bonobo の同様の計画はありますか?

Miguel de Icaza: 間違い なく。 Mono は、GNOME 上の Bonobo を含む多数のシステムと相互運用する必要があります。

大胆なオバサンジョ: 多くの関係者が、Microsoft NET プラットフォームは Java™ プラットフォームの不適切な複製であると主張しています。 これが該当する場合、Ximian が Microsoft .NET プラットフォームを複製する代わりに Java プラットフォームを複製または使用することを決めなかったのはなぜですか?

Miguel de Icaza: 私たちは CLR に興味を持っていました。これは、毎日直面している問題を解決するためです。 Java VM はこの問題を解決しませんでした。

大胆なオバサンジョ:Mono Rationale ページでは、Microsoft .NET 戦略には次のような多くの取り組みが含まれていると指摘されています。

  • ソフトウェアを記述するための新しいプラットフォームである .NET 開発プラットフォーム
  • Web サービス
  • Microsoft Server アプリケーション
  • 新しい開発プラットフォームを使用する新しいツール
  • Hailstorm は、Microsoft Windows XP に統合されている Microsoft .NET Passport で一元化されたシングル サインオン システムです。

また、Mono は単なる .NET 開発プラットフォームの実装であることを指摘します。 .NET 戦略の他の部分を実装するための Ximian による計画はありますか?

Miguel de Icaza: この時点ではありません。 現在、開発に取り組んでいます。

  • x86 CPU 用の JITer を使用した CLI ランタイム
  • C# コンパイラ
  • クラス ライブラリ

上記はすべて外部共同作成者の助けを借りて行います。 これは大きな事業であり、時間、専門知識、コードをプロジェクトに寄付した様々な人々がいなければ、すぐに完全な製品を提供する機会さえないことを理解する必要があります。

私たちは利己的な理由でこれを行っています:LinuxとUnixアプリケーションを自分で開発するためのより良い方法が必要であり、CLIはそのようなものとして見えます。

とはいえ、Ximian はサービスとサポートビジネスに携わっても、Mono プロジェクトを新しいプラットフォームに移植したり、JIT エンジンを改善したり、Mono の特定の領域に焦点を当てたりするための取り組みを拡張することを気にしません。

しかし、これ以外に、私たちが行った3つの基本的な発表を超える計画は、現時点ではありません。

大胆なオバサンジョ: Mono プロジェクトと摩擦があるように見える無料のプラットフォームで .NET の他の部分を実装している他のプロジェクトも多数あります。 Portable.NET FAQ のセクション 7.2 は、dotGNU メーリング リストからの Martin Coxall の禁止と同様に、Mono プロジェクトと競合していることを示しているようです。 これに対するあなたの考えは何ですか?

Miguel de Icaza: 私は DotGNU のメーリング リストからマーティンの禁止の実際の詳細に注意を払いませんでした。 Usenetとインターネットメーリングリストは独自の文化であり、これは通常インターネット上で起こることのもう一つの例だと思います。 それは間違いなく悲しいです。

Mono と .NET の焦点は少し異なります。C# のような高度な言語でできる限り多くのことを記述し、再利用可能なソフトウェアを記述しています。 Portable.NET は C で記述されています。

大胆なオバサンジョ: Ximian と Microsoft の関係に関する競合するレポートが存在します。 一方で、.NET と GPL を管理するライセンスの間にライセンスの問題がある可能性があることを示すレポートがあります。 一方、Microsoft 内の一部が Mono に熱心であることを示しています。 では、Ximian と Microsoft の現在の関係と、Mono が制限的であることが判明した場合に.NET 上の Microsoft のライセンスに違反しないようにするために何が行われるのでしょうか。

Miguel de Icaza: さて、一つのために、私たちはゼロからすべてを書いています。

特許に関しては安全な面を保ち続けようとしています。 つまり、私たちは過去に使用されていた方法で物事を実装し、Monoで非常に複雑または効率的なことをまだ行っていません。 私たちはまだそれから非常に遠いです。 しかし、既存のテクノロジと手法を使用するだけです。

大胆なオバサンジョ: Sun が標準プロセスから Java を少なくとも 2 回取り消したことが指摘されています。何らかの理由で .NET がオープン標準でなくなった場合、Mono プロジェクトは続行されますか?

Miguel de Icaza: 開発プラットフォームのアップグレードには、標準であるかどうかに関係なく、価値があります。 Microsoft が標準機関に仕様を提出したという事実は、これらの問題を知っている人が問題を見て、相互運用性の問題を特定できるため、役立っています。

大胆なオバサンジョ: 同様に、Dan Kusnetzky の予測が実現し、Microsoft が将来 .NET API を変更した場合はどうなりますか? Mono プロジェクトは追いつくのか、UNIX プラットフォーム上の .NET の互換性のない実装になりますか?

Miguel de Icaza: Microsoft は、API の下位互換性を維持することに非常に優れている (これは、プラットフォーム ベンダーとして多くの成功を収めた理由の 1 つです)。 だから私はこれが問題にならないと思う。

これで、これが問題であったとしても、常に同じ API の複数の実装を用意し、実行時に適切な "アセンブリ" を選択して正しいものを使用できます。 アセンブリは、ソフトウェア バンドルを処理する新しい方法であり、アセンブリの一部であるファイルを暗号化的にチェックサム化し、それらの API をプログラムでテストして互換性をテストできます。   [図—.NET Framework用語集のアセンブリの説明を参照してください。

そのため、最初のリリースから逸脱した場合でも、下位互換性のあるアセンブリを提供できます (Microsoft と自分自身の両方で可能です)。

大胆なオバサンジョ:Mono クラスの状態ページを見ると、Windows フォーム、ADO.NET、Web サービス、XML スキーマ、リフレクションなど、多数の .NET クラス ライブラリが Mono に実装されていないことに気付きました。 つまり、Mono と .NET が最終的にリリースされると、.NET 用に記述されたアプリケーションは Mono に移植できない可能性が非常に高くなります。 将来これを修正する計画はありますか、それとも Mono プロジェクトの目標ではない移植可能な .NET プラットフォームを作成していますか? 同様に、Mono プロジェクトの短期的および長期的な目標は何ですか?

Miguel de Icaza: 状態 Web ページには、ユーザーが "要求" して作業するクラスが反映されます。 状態 Web ページは、コードの重複を避けるために、"この日付の時点でこのクラスに取り組んでいます" という言い方にすぎません。 誰かが何かに取り組むための興味を登録し、しばらくしてから何もしない場合は、クラスを再利用できます。

私たちはプロジェクトの初期段階にいるので、エンドユーザークラスよりも基礎クラスの作業が多く見えます。

私は非常に多くの偉大で才能のあるプログラマーがプロジェクトの早い段階で貢献することを期待してさえいなかった。 私の最初の予測は、最初の3ヶ月間は外部のコントリビューションなしで公の場でハッキングを過ごすだろうということですが、私は間違っていることが証明されています。

Mono プロジェクトの目標は、Ximian の目標だけではありません。 Ximian には一連の目標がありますが、プロジェクトのすべての共同作成者には独自の目標があります。一部のユーザーは学びたい、C# で作業する人、Linux で完全な .NET 互換性を望む人、言語の独立性を望む人、コードを最適化したい人、低レベルのプログラミングを好む人、Microsoft と競争したい人もいます。 .NET サービスの働き方が好きな人もいます。

そのため、プロジェクトの方向性は、プロジェクトに貢献する人によって導かれています。 多くのユーザーは、Windows 以外のプラットフォームに互換性のある .NET 実装を用意することに非常に関心があり、それらのギャップを埋めるのに貢献しています。

大胆なオバサンジョ: Ximianは特に、最近のベンチャーファンド、フリーソフトウェアベースの企業(Indrema、Eazel、Great Bridgeなど)が失敗し、残りのフリーソフトウェアベースの企業のかなりの割合がロープに乗っているという事実の後、Mono開発のコストをどのように支払う予定ですか? 具体的には、Ximianは一般的にフリーソフトウェアとモノでお金を稼ぐ方法を計画していますか?

Miguel de Icaza: Ximian は、サポートとサービスを提供します。 最近、いくつかのサービスを発表しました。さらに多くの製品やサービスがパイプラインに入っており、今後 6 か月間に発表される予定です。

最近発表した情報は次のとおりです。

  • Red Carpet Express: Red Carpet サーバーへの信頼性の高い高速アクセスが必要なユーザー向けのサブスクリプション サービスです。
  • Red Carpet Corporate Connect: Red Carpet アップデーター テクノロジを変更して、Linux ワークステーションのネットワークを簡単に管理し、カスタム ソフトウェア パッケージをデプロイおよび保守できるようにしました。
  • GNOME デスクトップおよびエボリューションのサポートとサービス: 最新のボックス化された製品は、出荷するさまざまな製品のサポート サービスを販売する方法です。

また、無料のソフトウェアベースのソリューションを統合する人々にプロフェッショナルなサービスとサポートを提供しています。

Monoの特定のケースは興味深いです。 開発コストの削減に取り組んでいます。 非常に素晴らしい基礎が築かれ、ECMAに提出されました。 今では、その力を実現する他の関係者の助けを借りて、生産性の向上に役立つ Mono ランタイムと開発ツールを開発しています。

実際、Ximian で Mono に取り組んでいるチームは、過去に会社の残りの部分にインフラストラクチャのヘルプを提供したのと同じチームです。

大胆なオバサンジョ:インターネット エクスプローラーの SPARC ポートで作業するために Microsoft にインタビューしたことがあるのは、おそらくいくつかのコーナーではほとんど知られていないでしょう。 それ以来、フリー ソフトウェア コミュニティに与えた影響を考えると、Microsoft の従業員になった場合の人生はどうなるか疑問に思ったことはありますか?

Miguel de Icaza: 私はそれを多くの考え、いいえを与えていません。 しかし、Netscape Communicator がオープンソースになる前に、Microsoft でインタビューしたすべてのユーザーに、インターネット エクスプローラーをオープンソースするように依頼しました。

ダレ・オバサンジョは、コンピューターサイエンスの理学の学位に向けて取り組んでいるジョージア工科大学のシニアです。彼はスラッシュドット、黒5hin、アドボガトなどのオンラインフォーラムに投稿したり、プログラミングやソフトウェアに関する様々な記事を書いたりするのに自由時間を費やしています。放射システム、i2 テクノロジ、Microsoft などのさまざまな企業にインターンをしており、現在は大学院の学位のメリットについて議論していますが、GA Tech の時代が終わるとレドモンドで終わる可能性が最も高くなります。