コンテンツへスキップ
ものがたり
戻る

2006-01-10

そういえば、ここにはMonoの情報を期待している人もいるんだった。たまには読者サービスしないと。

Mono 1.1.13 and 1.2

一番最初の頃は2004年12月頃にはリリースされるはずだったMono 1.2だが、Managed Windows Formsがfeature completedになったことで、現実にリリース計画が動き始めている。既にMonoライブラリのpublic APIはフリーズとなっていて、RELAX NGコードの最適化をしていて関数を追加しようと思っている僕も、これらをpublicにすることは出来ない。

それとは微妙に関係がないのだけど、1.1.12のリリースが正式に行われていないうちに(少なくともアナウンスは出ていない)、早くも1.1.13が計画されている。これは実のところNovell製品 - たぶんNLD (Novell Linux Desktop)だと思うけど僕は把握していない - の新バージョンに合わせて出すもので、しばらくtrunkと並行してメンテナンスが頻繁に行われるものになりそうだ。

追記: いやNLDじゃなくてSLESかな

2つのブランチがどれくらい上手く管理されるものかは、僕は個人的には懐疑的だけど1、とりあえず羮と膾の2つを用意する方向で進もうとしているようだ。

Mono on Fedora Core

一部の消息筋で噂になっていたけど、ようやくMonoがFedora Coreに含まれることになったようだ

Monoチームとしては歓迎すべきことで(いや実際素晴らしい話です)、SUSEチームとしては、SUSEのアドバンテージがひとつ無くなったことになる。Fedora Coreにこの方面でディスアドバンテージがあったことは事実で、これまでpatent policyがどうのこうのと言っていた連中には、言行不一致を改める必要がありそうだ。

ところで、これはほとんどGNOMEのアドバンテージということになる。KDE開発者にとっては、Mono bindingを作る作業はそれほど簡単ではないし、その苦労にアドバンテージが見合うと考える開発者はおそらくあまり居ない。すなわち、Cをベースとしていて、DllImportを経由するライブラリのネイティブバインディングが容易なGNOMEに対して、KDEは基本的にC++カルチャーなので、DllImportとは親和的ではない。C++カルチャーということは、基本的にオブジェクト指向でもあるし、KPartsのようなコンポーネント指向のフレームワークも存在しているので、Monoによって得られるメリットというのは、せいぜい安全なプログラミングくらいであろう。もちろん言語としてのC++やC#の学習コストを度外視しての話だけど(C#の学習コストがどれほどのものかはよく分からない)。


コメント

KENZ — 01/11/2006 04:55:29

ひゃっほう!グッドニュースです。と、FedoraユーザかつMonoユーザ(ウォッチャーくらいかも?)なので喜んでみます。読者サービスありがとうございます。

atsushieno — 01/11/2006 11:39:41

やや、それはよかったです。monoに触れる人も多くないと思うので、誰も気にしないかも、とか思っていました(笑)

Footnotes

  1. side by sideによってDLL hellが無くなるというのが幻想だったので。


この記事を共有:

前の記事
Mono 1.1.13 and 1.2
次の記事
derivativeアルゴリズムについて(3)