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

  • [アーティクル]

 

大胆なオバサンジョ

2001 年 12 月

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

大胆なオバサンジョ:あなたは最近、Ximian が Microsoft .NET 開発プラットフォームのオープンソース実装を作成すると発表したため、プレスに参加しています。 最近の怒りの前に、あなたは GNOME とボノボで行った仕事のために注目されています。 以前のプロジェクトから Mono までの無料ソフトウェアへの関与の概要を簡単に説明できますか?

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

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

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

詳細は論文に 掲載されています。 [ありがた— 「Unix コンポーネント: 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 は毎日直面する問題を解決するため、私たちは CLR に興味を持っていました。 Java VM はこの問題を解決しませんでした。

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

  • ソフトウェアを記述するための新しいプラットフォームである .NET 開発プラットフォーム
  • Web サービス
  • Microsoft Server アプリケーション
  • 新しい開発プラットフォームを使用する新しいツール
  • 雹雹は、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: さて、1つのために、私たちはゼロからすべてを書いている。

私たちは特許に関して安全な側にとどまろうとしています。 つまり、私たちは過去に使用されていた方法で物事を実装し、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 と Microsoft の両方で可能です)。

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

Miguel de Icaza: 状態 Web ページには、ユーザーが作業を "要求" したクラスが反映されます。 状態 Web ページは、コードの重複を避けるために、"Hey, I am working on this class as this date" (この日付の時点でこのクラスに取り組んでいます) という単なる言い方です。 誰かが何かに取り組むための関心を登録し、しばらくしてから何もしない場合は、クラスを回収できます。

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

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

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

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

大胆なオバサンジョ: Ximianは、特に最近のベンチャーファンド、インドルマ、イーゼル、グレートブリッジのようなフリーソフトウェアベースの企業の多くが失敗し、残りのフリーソフトウェアベースの企業のかなりの割合がロープに乗っているという事実の後、Monoの開発コストをどのように支払う計画がありますか? 具体的には、Ximianは一般的にフリーソフトウェアと Monoでお金を稼ごうとどのように計画していますか?

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

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

  • レッドカーペットエクスプレス:レッドカーペットサーバーへの信頼性の高い高速アクセスを望む人のためのサブスクリプションサービス。
  • Red Carpet Corporate Connect: Red Carpet アップデーター テクノロジを変更して、Linux ワークステーションのネットワークを簡単に管理し、カスタム ソフトウェア パッケージをデプロイおよび管理できるようにしました。
  • GNOMEデスクトップとエボリューションのサポートとサービス:当社の最新の箱入り製品は、当社が出荷する様々な製品のサポートサービスを販売する方法です。

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

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

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

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

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

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