SourceForge.JP: Open Source Software

LoginCreate AccountAdd BookmarkHelp

OpenSource Downloads

(7,965) Cabos
(3,068) 7-Zip
(2,483) Tera Term
(2,009) CrystalDiskInfo
(1,669) HandBrake Japanese Language Version
(1,252) CrystalDiskMark
(921) ffdshow
(669) Tween
(667) Boookends
10  (569) Amateras
11  (563) ギコナビ
12  (502) MergeDoc
13  (436) VirtualDubMod-jp
14  (422) えこでこツール
15  (375) SMPlayer
More >>

最近ブックマークされた記事

MonoによるMac OS Xの対応状況

2006年09月19日 11:57
  • スラッシュドットにタレコむ
  • あとで読む
今時のLinuxユーザであれば、Mono Projectについて話を聞いたことがあるだろう。これはMicrosoftの.Net Frameworkと同等の実行環境をフリーに実装しようというプロジェクトであり、実際、関連する開発ツールからはいくつかの優秀なアプリケーションが生み出されていて、今ではいくつかの主要なLinuxディストリビューションにおけるデフォルトリリースでも同梱されるようになっている。ところでMono側の謳い文句では.Netに対するクロスプラットフォームな代替品という紹介がされているが、その言葉の真偽を確かめるべく、今回はMac OS Xにおける現在の対応状況を検証してみた。

Monoが正式にサポートしているプラットフォームは、Linux、Mac OS X、Windows、Solarisおよび、BSD系のビッグスリー(FreeBSD、OpenBSD、NetBSD)だ。なおMono創設者のMiguel de Icaza氏によると、BSDへのポート作業は完全なコミュニティ形式で運営されているが、SolarisおよびOS Xへのポート作業については、Novellという企業スポンサーをもつプログラマによって維持されているとのことである。

WindowsユーザをMonoに転向させることは、誰の目にも苦戦が予想されるが、それはMicrosoft製のネイティブアプリケーションとして.Netそのものが存在するためである。とは言うものの、Windowsポートの現状を見てみると、既にGTK+などのLinuxを起源とした多数のツールキットやライブラリが利用可能な状態になっている。そうした状況を鑑みると、将来的に純正の.Netアプリケーションと共存させる形でMonoアプリケーションを併用するというのも、それ程あり得ない話ではないだろう。

Monoの特徴の1つは、コアとなるECMA/ISO .Net Frameworkだけではなく、GNOMEやMozillaなどの各種テクノロジとこうしたフレームワークとの統合に必要な一連のライブラリも実装する点である。つまりLinuxユーザにとってお馴染みのF-SpotBeagleBansheeといったMonoアプリケーションの大半は、GTK#などの外部ライブラリを活用することで、前述した.Net系以外のコンポーネントとの統合を行っているのだ。

ここでの1つの朗報は、GTK#、GNOME、Mozillaなどのコンポーネントの多くで、他のUnix系システムに向けた開発が現在進行中である、というニュースである。このことは、BSDおよびSolarisでF-SpotやBeagleなどのMonoアプリケーションを使う際のハードルが低くなることを意味する。

現段階におけるMacのサポート状況

Mac OS Xの世界では、Apple純正のネイティブAPIと他のオペレーティングシステムから移植されたコンポーネントとの統合が潤滑に行われていないことが、Linux起源のアプリケーションを動かす際の障壁となっていた。

結論から言うと、100% .Netのアプリケーションであれば、これらはOS X上でもスムースに動作する。例えばNovellはiFolderをOS X用に提供しているが、この製品についてはWindowsおよびLinuxと同等のサポートが行われている。また、De Icaza氏から紹介された注目ソフトとして、3DゲームエンジンUnityおよびインスタントメッセージ/ソーシャルネットワーク用コンボのimeemというサードパーティ製アプリケーションも存在している。

これらはいずれもWindows/Macの両用製品であるが、前者は.Net、後者はMonoをプラットフォームに用いている。そしてエンドユーザ側の負担を軽減する目的で、いずれのOS X用製品もMonoランタイムがバンドルされているが、そうした点をエンドユーザが意識する必要はまったくない。

こうして見ると、Mac純粋主義者にとってもMonoは注目株の1つのはずである。ただし、先に挙げたようなLinux系アプリケーションを動かすとなると、状況は一気に複雑化する。BSDやSolarisの場合とは異なり、AppleはもとよりMono Projectそのものが、Linuxコンポーネントのインポートをサポートしていないからだ。特に問題となるのは、Mono用に記述されたLinuxアプリケーションは、そのほとんどすべてがGTK#というGTK+ツールキット用の.Netバインディングに依存している点である(GTK#には他のGNOMEライブラリのバインディングも用意されているが、最も重要なものがGTK+である)。

OS Xを使うLinux中毒患者の大半が、彼らのフリーソフトウェアに対する渇望を満たす手段として依存しているのがFinkの進めるポーティングおよびパッケージングプロジェクトだ。現行リリース(0.8.1)におけるFinkでは、OS Xポート用に6,500以上のパッケージが使用でき、その中にはGNOMEデスクトップ環境の全体がカバーされている。

Mono on OS Xのオフィシャルなインストールガイドを見ると、Finkを用いて依存関係のインストールを行い、その後GTK#をソースからコンパイルすることが推奨されており、それに要する手間は「a little effort-intensive」(多少手間がかかる)とのことだ。

ところが実際には、Bansheeなどお馴染みのMonoアプリケーションをOS X上で実行しようと思うと、現状では途方もない労力が要求されることになる。というのも、まずはOS X用のMonoパッケージをインストールしてから、ポートされたLinuxライブラリの一群をFink経由でインストールし、その後でようやくGTK#をソースからコンパイルするという手順になるからだ。

ネイティブGTK+ -> ネイティブGTK# -> OS X対応Linuxアプリケーション

いろいろ不備な点を突いた形にはなったが、ごく近い未来に明るい展望が見えつつあるのも事実である。De Icaza氏も指摘しているように、仮にGTK+をインストールしたとしても、それを使用するMonoアプリケーションは依然としてAppleによるX11実装に依存し続けるのであって、OS XのネイティブGUIツールキットで賄われる訳ではないのである。ところが同氏によると、GTK+についてのネイティブなOS Xへのポート作業が現在進行中だというのだ。

この作業が実用段階に達した暁には、Mono ProjectによるGTK#インストーラへのパッケージ化およびOS X用Monoへのバンドルが可能となるだろうが、その恩恵は、インストール手順の簡単化やアプリケーション統合度の向上として現れるはずである。

現在、GTK+のOS Xポート作業の最前線を突き進んでいるのは、Imendio ABという独立系開発ハウスである。Imendioの活動では、開発者が必要な時間を確保するためのサポートを行うことに主眼が置かれており、OS X用に新たにコードをフォーキングさせるのではなく、GTK+のメインブランチ内部で作業を進めるようにしている。

こうした作業の進捗状況は、Imendioの企業wikiにあるプロジェクトホームページで確認できる。ここを見ると、ロードマップ開発予定リストを始めビルド用のガイドも用意されている。なお現行のガイドでは、OS X用にGTK+をビルドした場合、GNOME CVSによるコードのチェックを経ることが求められている。

フリーソフトウェアは、プロプライエタリ系オペレーティングシステムの世界においても重要な役割を果たしている。Mac愛好者については(遺憾なことながら)Linuxアプリケーションをポートしてくることに反感を抱いているという評判が立ってしまっているが、そうした噂の源泉は、OS XはLinuxよりも“優れた”Unixであり、Linuxアプリケーションは格下な存在であるとの偏見にあるようだ。これはあくまで仮定の話だが、Monoなどのクロスプラットフォームはこうしたユーザたちの目を開かせ、自分たちが知らない優れたアプリケーションが他にも存在することに気づかせてくれるかもしれない。もっとも、そうした理論上の可能性が実現するとしても、それは少し先の話になるだろう。

NewsForge.com 原文

Nathan-Willis(2006年9月14日(木))
2007年07月01日 19:05 更新