Slashdot Mirror
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"
Popular business plan: Step 1: Design product that runs a proprietary Microsoft system. Step 2: Make it run on Linux, Windows' leading business threat. Step 3: ??? Step 4: Profit!!! If no one could figure it out, step 3 might be sell the code to (or settle with) Microsoft so that .NET is once again a Windows-only system. At least this would be my business plan.
We're only gonna die from our own arrogance, that's why we might as well take our time...
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.
Well, I am pretty sure that that is a fine achievement, but it looks like one of those scary organical molecules to me :-)
Not "as part of the GPL", but GPL-licensed. Microsoft can buy it (the copyright from every Mono copyright owner), pull it from public view, and you and I -- well, we can still fork it! From the source that I checked out from cvs just few seconds before the transaction. He.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
A mature platform? It's in version 0.24. As of today they state 77% of just the core library is implemented. Teamwork and recognition does not imply maturity. The term needs to be used correctly and more sparingly or it'll lose all meaning.
Developers: We can use your help.
Will Mono development switch from CVS?
For almost two years now I have been subjected to the religious proselityzing of the .NET cult. "It's platform neutral," they said. "It will run on Linux," they said. "Just trust Miguel and you will be saved," they said. But now they say they will use Wine. What a crock of shit! If .NET is crossplatform then so is MS Word!
.NET application, and Linux is a merely bootloader for Wine, then there will no longer be a need for Linux.
I see their fiendish plot now. When every application is a
A Government Is a Body of People, Usually Notably Ungoverned
This guy is a troll. This is the real Miguel de Icaza. Simply look at the troll's posting history as well as his journal entries and make up your mind.
This guy is a troll. This is the real Miguel de Icaza. Read the troll's posting history and rent a clue.
Actually, looks like a joke to me. Pretty funny one at that. Rent a goddarn humor to suit your name.
:)
hmmm *remembers reading somewhere that the bungi is a notorious troll*
dique
Oh, Ximian/Miguel/et.al are in bed with Microsoft, they suck
At least I sure-as-hell haven't been able to get Windows.Forms to work. :(
Only client-side GUI apps that use WinForms need WINE. All other .Net apps -- including ASP.Net, non-GUI apps, Web services, apps that use browsers for their UI, client-side GUI apps using GTK, etc. -- will run without WINE.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
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.
No
WineLib is there to aid people who want to write Windows.Forms (fat client) applications that are cross-platform. But you could write "pure" *nix stuff using the GTK bindings without using Wine, and you can write console mode and asp.net apps without Wine.
Has nothing to do with the desktop.
My point was really that Mono is about more than "the desktop".
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
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.
.. and I've had no problems writing multithreaded listeners and the like. In fairness, I should say that I didn't have a requirement for very high performance, but I didn't think it was a slouch either.