Mono & SourceGear Move Forward

miguel writes "The Mono project keeps evolving and is quickly becoming a mature platform for running .NET applications on Linux. SourceGear and Ximian have entered into a partnership to make their .NET-based Vault client software available to Linux and Unix users by implementing the missing web services support in Mono. The formal announcement is here and a developer overview is here. OpenLink has also contributed the functionality to turn Wine into a library that Mono is using to implement the System.Windows.Forms namespace. Another recent progress bit is the fact that Mono can run Eclipse with the IKVM Java VM for .NET"

How mature is it?

[Burb]

Let me say first off that I love the idea of Mono and wish it every success. Although it will one day (hopefully) have pretty comprehensive coverage of .NET features, right now it doesn't.

I've just downloaded the port for FreeBsd of mono 0.24 and was delighted to find that hello world works. True, not an exhaustive test but nice to see. Then, I thought, how about seeing if my current applications would be ported. So I looked for the System.DirectoryServices library only to find it wasn't there. OK, not a big deal for some but I need LDAP access. The JIT stuff seems pretty good, but the libs are incomplete.

So a qualified hurrah to all this. I'm delighed so far, but it won't run all .NET code today.

Re:What do you think they will do?

[Miguel de Icaza]

the entry level mono stuff is free but you will have to pay ximian & VC partners to get the connector stuff that actually makes it work.

theres your step 3.

the WINE projects been doing this for ages, WINE is free but if you want to run something like office xp you need a commercial versian/fork of WINE.

the differnce with mono is the core software is not actually GPL - it is more like a BSD license - so the commercial improvements don't have to be rolled back into core mono.

$$$ PROFIT! $$$

Re:How mature is it?

[sab39]

Interesting - are there any plans to open this up eventually?

Are there any other assemblies that are planned to be released in this way?

If someone in the community contributed an alternative implementation of DirectoryServices under the standard Mono license, would it be accepted?

Thanks,
Stuart (occasional mono user who had to #if out references to this namespace in some code to make it compile under Mono)

Re:I knew it!

[The Bungi]

But now they say they will use Wine. What a crock of shit! If .NET is crossplatform then so is MS Word!

Did you RTFA? They are using Wine to implement the forms package only. The rest of the non Win32-specific stuff runs without Wine just fine. There's even bindings for GTK if you're not interested in the full forms package.

Just another "Oh, Ximian/Miguel/et.al are in bed with Microsoft, they suck" uninformed post.

Re:I knew it!

[rhyd]

Well I have to say I find your reply a little bit harsh. Arandir had obviously 'RTFA' because they had picked up the whole Wine fiasco.

its like when the mplayer (don't get me wrong i love mplayer and use it every day) team announced the ability to playback Realplayer videos provided you installed the latest version of Realplayer....?

as i understood it the original goal of mono was to implement the EMCA c# CLR specs and nothing more. Now they are going way beyond that - and the problems they are hitting are because .NET is way to entangled in the win32 api to be truly crossplatform as is. Early adopters caught up in their enthusiasm are understandably disapointed when they hear Wine is the key to making their app crossplatform because they are really not much better off than before .NET. Infact it would be better to reverse the Ximian approach to the problem and implement a lightweight .NET compatibility service as a core Wine module - at least that would be consisistant with the current rule:

if you wanna run windows programs on linux use a Wine

I use KDE, java and Mozilla mail because yeah I do kindof suspect Ximian are in bed with Microsoft

ignorant question

[Anonymous Coward]

Has anyone done a comparison between Mono threading and Microsoft's C# threading library? The reason I ask is I've been testing the threading in C# for heavy weight service threads and it sucks. I will qualify this with an example. Say I have a daemon thread that needs to run inside a webserver ( in this case it's IIS). The reason it runs inside IIS is because it's a webservice. therefore using IIS allows me to use the stock soap and wsdl support. It also gives me stock HTTP protocol support. The problem is this. The current .NET caching mechanism is really meant for object caching. I could be reading the API wrong and mis-interpreted the articles on MSDN about the caching support. In this particular case, I can't use COM+, since COM+ runs in it's own processes and would mean serialization. the goal of this service thread is to get updates in a push fashion from a variety of remote sources. Basically, an event driven model, so that data updates happen in small increments when needed, not based on some pull interval. I don't want to query the database for data changes, since that will be hard to scale and likely kill the database connection pool under heavy loads.

the ideal situation is to have the database have C#, C, C++ or Java triggers that can push the new values to an application layer. Having that mechanism would make it easier to distribute processes into discrete categories and tiers. With an event driven architecture, processes can proceed in either sync or async manner depending on the runtime context. So back to the threads. I've read several MSDN articles that recommend 1 heavy weight thread per CPU. Specially the recommendation for tuning Sql Server recommends 1-to-1 ratio. So if you consider IIS a heavy weight thread and a COM+ (for data access) another heavy weight thread, it would take a system with a minimum of 3 CPU's to run IIS with a heavy weight service thread. Now if I want to have more than 1 service thread running inside IIS, that means scaling vertically. Looking at the current prices for systems with 5 or more CPU's it's not cheap. From my limited understanding, the thread limitation is due to the window's thread architecture, so C# isn't to blame.

If MONO can provide the flexibility of Unix threads with a compatible CLR, it would go a long way to show OSS can produce superior server software than microsoft. I've probably over generalized and made mistakes, but hopefully some one with more knowledge will correct me.

Mono is progressing nicely!

[r4lv3k]

I have an application that relies heavily on XML serialization, and am happy to report that the latest System.Xml.Serialization in CVS is now working as it as it should. All the Xml attributes are completely compatible AFAIK and I am seriously considering porting 5% of the code of my app that depends on Managed C++ to use P/Invoke and Mono.

This is a great leap forward for supporting SOAP/WSDL I imagine. My applications pretty much persist themselves into an XML language.

Great work Mono team!

BTW it would be awesome if Mono was optimized for the new AMD64 Opteron!

r4lv3k

80% of what programmers?

[phr1]

What programmers writing the class library liked the new license? In particular, were they volunteers, or getting paid to write it?

My own attitude towards these questions is I'm a relative GPL zealot when it comes to code that I write for free on my own time. I don't see why I should develop products for proprietary software companies without getting paid. However, if I am getting paid, then I'm not so fussy about the license. I suspect a lot of other programmers feel the same way at some level, though they may not be explicit about it.

So if it was paid programmers who liked the license switch, it's easier to understand, even if it means the project will attract fewer volunteers. If it was volunteers who wanted to switch, that just seems kind of self-defeating.

I hope project leaders thinking of choosing non-GPL licenses consider these issues. Some projects of course need volunteers more than others do.