■
そういえば、ここには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
-
side by sideによってDLL hellが無くなるというのが幻想だったので。 ↩