Guest post by A developer from the Qumranet team, developers of the KVM virtual machine and Spice Protocol has written about the team’s experience in porting the RHEV-M software from C# to Java as a means of making the application cross platform and open sourcing it. The team considered several options including Mono which they discarded as too immature for the job, and Grasshopper technology was discarded as an option since the goal was to open source it and eventually settled on a semi-automated workflow using Java. Red Hat is well on its way towards the goal of making a cross-platform and open source management tool for managing virtual machines in the servers and desktops.
Step on dog poop, how lovely.
If you are already in the C# framework frame of mind then look at the 4.5 class set:
http://qt.nokia.com/doc/4.5/index.html
There is enough there to build about anything and when you are done it might actually run at a reasonable speed would run on Windows, Mac, and, oh yeah, Linux.
Slots and Signals allows RAD dev in Qt Creator.
If you stick to the Qt collections and QStrings you probably will not have much problem with mem-leaks, etc.
Forgot to mention it is C++.
Probably because they probably had to find a way to convert C# to Java, possibly automatically. They detail this in the article.
Personally, I would have assigned more resources and time to this project as it will be essential from a maintenance point of view in the future that you get it right. Sometimes when you’re faced with something that simply doesn’t run well on your platform(s) of choice then the only option is too largely write from scratch and stop lots of firefighting later.
The hardest part of the project has probably only just begun……….
Anyone know of such a thing?
The closest thing I can think of is Rhino, but it’s not a source-to-source compiler.
There’s no enterprise level VM Management software for Linux… VMware Virtual Infrastructure, RHEV and Hyper-V are Windows only software. This port is really good news.
OTOH this proves that Mono was an enormous waste of time for the open source community, .NET software is and will be Windows-only.
Java is the number 1 Linux ally in enterprise enviroments… I can’t understand why Linux fanboys hate Java so much. It’s sad.
I’m curious as to what exactly was lacking in Mono..nowadays it’s pretty feature complete.
The only real problem you’ll have is a lack of a cross platform UI toolkit.
That’s just a matter of waiting for Moonlight to get OOB working in Full Trust. I haven’t tried in a while.
Well, there is the problem that Mono is covered by patents and Red Hat won’t ship it in their products. You can add it to Fedora, but I don’t think it will ever be included in the default distro build. Not to mention, a large part of the code base probably uses the parts of .Net that aren’t in Mono, like ASP, and the widget set.
That and the fact that many standard .Net libraries are not available in Mono.
It is nice that we got to have Mono available in Linux, but I never really understood Miguel’s love for Microsoft technologies.
For me .Net is a nice set of managed languages, but it only makes sense in Windows development shops.
Like which libraries? Let’s get specific. Sure there are some rough edges, but overall a vast majority of .NET is available on Mono.
And the reasons listed are bs, I asked for specifically the ones the article complained of, not your pet peeves you may/may not have experienced personally.
If you want to clarifications from the blog author, posting to the blog would be more obvious than posting here and expecting others to do mind reading
You’re absolutely right, though I posted it here instead in order to offer context as to why I thought overlooking Mono was a mistake.
Then again, the people who know their project best are the programmers on it..which is why I was curious.
Red Hat already has a large investment on JBoss and the Java platform and it makes sense to align the team with it.
Mono is not really much of a choice for Red Hat. Most of the development for Mono is from Novell which has a fairly large team to manage that and it is never going to be feature complete and always playing catch up. Not to mention the patent concerns over the non-standard parts of the technology which pretty much every real world application relies on.
If you want to get comments from the development team, the blog is the obvious place for that.
Well, since the app is a web interface, ASP is probably the language used to code it, and ASP is NOT covered at all by the Mono license. That alone is a BIG chunk of code that they would have to rewrite.
See, this is a constructive post. Speculation supported by reasoning.. not some superficial bashing of Mono and downplaying of the hard work that’s gone into the project.
Easy, just check the compatibility page:
http://www.mono-project.com/Compatibility
What I like specially are the “no plans to implement” or the “will implement later version” lines.
No serious .Net project can make fully use of Mono, unless it is written from the ground up to make use of Mono as well.
Are you serious? Any .NET programmer worth his weight in reference types would see that the “partial” and “will not implement” portions are very rarely used portions of .NET
The only biggie is the partial support for WCF, but that’s only improving.
The vast majority, as in over 90% of the important parts of the .NET Framework (ie not the obscure parts that no one except a few edge cases use) are implemented fully or partially in Mono.
The elephant in the room is really WPF, but with Moonlight and OOB looming on the horizon..it’s necessity is diminished greatly.
WPF lacking is more of a man power, it’s an absolutely HUGE platform. Endlessly massive. I wouldn’t blame them for not even trying.
Most (enterprise) Java projects I know are Windows only.
Not to say that they couldn’t run on another platform, just that the organization doesn’t want to test for it so they advertise Windows only.
In Europe most Java server applications are deployed in some flavor of Unix, while Java desktop applications are running mostly on top of Windows.
On the Enterprise level, many Java desktop applications are actually based on top of Eclipse or Netbeans runtimes.