デレオバサンジョ
2001 年 12 月
概要: このインタビューでは、GNOME と Ximian の創設者である Miguel de Icaza が UNIX コンポーネント、Bonobo、Mono、Microsoft .NET について語っています。 (6ページ印刷)
デデアオバサンジョ: 最近、Ximianの発表により、Microsoft .NET 開発プラットフォームのオープンソース実装を作成する予定です。 最近のフローの前に、あなたはGNOME とBoobo
Miguel de Icaza: 私は、その組織、ライブラリ、アプリケーションなど、さまざまな分野で GNOME プロジェクトに関して過去 4 年間働いてきました。 その前は、Linuxカーネルで作業していたので、SPARCポート、ソフトウェアレイド、Linux/SGIの作業で長い間働いていました。 その前に、私はミッドナイトコマンダーファイルマネージャーを書いていた。
大場三条をあえて: あなたの でUnixを吸わない シリーズでは、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 では、に対して半透明
: 間違いなく。 Mono は、GNOME 上の Bonobo を含む多数のシステムと相互運用する必要があります。
デレオバサンジョ: 多くの当事者が、Microsoft NETプラットフォームはJava™プラットフォームの貧弱なクローンであると主張しています。 これが当てはまる場合、Ximian が Microsoft .NET プラットフォームを複製するのではなく、Java プラットフォームの複製または使用を決定していないのはなぜですか?
Miguel de Icaza: 私たちは 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 が制限的であることが判明した場合に、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は Monoの開発コストをどのように支払うことを計画していますか? 具体的には、Ximianは自由ソフトウェア全般と Mono でどのようにしてお金を稼ごうと計画していますか?
Miguel de Icaza: Ximian では、サポートとサービスを提供しています。 最近、いくつかのサービスを発表しました。さらに多くの製品やサービスがパイプラインに入っており、今後 6 か月間に発表される予定です。
最近発表した内容は次のとおりです。
- Red Carpet Express: Red Carpet サーバーへの信頼性の高い高速アクセスを求めるユーザー向けのサブスクリプション サービスです。
- Red Carpet Corporate Connect: Microsoft は、Linux ワークステーションのネットワークを簡単に管理し、カスタム ソフトウェア パッケージのデプロイと保守を行うのに役立つ Red Carpet アップデーター テクノロジを変更しました。
- GNOMEデスクトップとエボリューションのサポートとサービス:最新のボックス製品は、当社が出荷するさまざまな製品のサポートサービスを販売する方法です。
また、無料のソフトウェアベースのソリューションを統合する人々のためのプロフェッショナルなサービスとサポートも提供しています。
Mono の特定のケースは興味深いものです。 開発コストの削減に向けて Mono に取り組んでいます。 非常に素晴らしい基盤が築かれ、ECMAに提出されました。 現在、その力を実現する他の関係者の助けを借りて、生産性の向上に役立つ Mono ランタイムと開発ツールを開発しています。
実際、Ximian で Mono に取り組んでいるチームは、過去に会社の残りの部分にインフラストラクチャの支援を提供したのと同じチームです。
Miguel de Icaza: 私はそれを多くの考えを与えていません, いいえ. しかし、私は、Netscape Communicatorがオープンソースになる前に、Microsoftでインタビューしたすべての人にオープンソースの Internet Explorer を依頼しました。
デデア・オバサンジョ・は、ジョージア工科大学のシニアで、コンピューターサイエンスの理学士号に向けて取り組んでいます。彼は、スラッシュドット、クロ5ヒン、アドボガトなどのオンラインフォーラムに投稿したり、プログラミングやソフトウェアに関する様々な記事を書いたりするのに自由な時間を費やしています。ラディアント・システムズ、i2テクノロジーズ、Microsoftなどの様々な企業でインターンをしており、現在は大学院の学位のメリットについて議論していますが、GA Techの時代が終わるとレドモンドで終わる可能性が最も高くなります。