The Case For Supporting and Using Mono
snydeq writes "Fatal Exception's Neil McAllister argues in favor of Mono, asking those among the open source community who have 'variously described Mono as a trap, a kludge, or simply a waste of effort' to look past Miguel de Icaza and Mono's associations with Microsoft and give the open source implementation of .Net a second chance, as he himself has, having predicted Mono's demise at the hands of open source Java in 2006. Far from being just a clone of .Net for Linux, McAllister argues, Mono has been 'expanding its presence into exciting and unexpected new niches.' And for those who argue that 'developing open-source software based on Microsoft technologies is like walking into a lion's den,' McAllister suggests taking a look at the direction Mono is heading. The more Mono evolves, the less likely Microsoft is to use patent claims or some other dirty trick to bring down the platform."
Ok, sure. I can do that. In fact, I wrote just such a journal entry in mid-07:
It is quite obvious to anyone using the platform that the Mono team is not in bed with Microsoft. In fact, it would seem that the Mono team is explicitly trying to warn you away from .NET technology. Otherwise, why would they make it SO GODDAMN HARD TO DEVELOP FOR?
Read More: A Day Without Mono is like a Day Without a Bullet in my Head
Ooooh. That wasn't positive at all, was it? Huh.
Javascript + Nintendo DSi = DSiCade
Mono has been 'expanding its presence into exciting and unexpected new niches.'
Yes, just recently there have been several more!
Here at the Mono bar, we play every kind of music - country *and* western!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
For bit rates less than 24 Kbps I prefer mono.
(What, RTFA ? Who has time for that ?)
A third party implementation of a standard defined by the first-party implementor is always going to lag behind the original. Even if .Net is technical nirvana, if your platform's only implementation comes from a third party, your platform is a second-class citizen.
The case against Mono has nothing to do with the technical niceties he presents, nor do the fears of Microsoft "pulling out the rug" matter... What matters is that when developers and end users pick a technology, they pick the leader, not the follower. Accepting Mono is giving up and giving in to Microsoft vendor lock-in.
Microsoft has a history of using patents to protect its desktop market share. They attempted to scare people out of using open source software because it supposedly violated 235 of their patents. Therefore, I believe it is prudent that the open source community remain sceptical of Microsoft as well as implimentations of any of its technology including the .net platform.
Sigs are too short to say anything truly profound so read the above post instead.
Mono is in a precarious, teetering position. Somewhere between tepid and antagonistic reaction amongst professional and casual developers, a designer community that is seen as a puppet or apprentice to the hegemony, and not even a clear path forward for compatibility. Be distinct, or be identical, but there's no way to be both.
[
The thing is, everyone associates Java with slow psudo-3-D games that take forever to load on a cell phone or browser. People associate other (sometimes slower) languages such as Python and .NET/Mono to be much, much, faster. Now, this isn't really correct, but if I was going to learn a new language, it probably would be .NET or Mono and not Java.
Taxation is legalized theft, no more, no less.
With Qt 4.5 going LGPL in March, one would have to wonder why you would use Mono over Qt or Java.
There are legitimate reasons - the CLR for instance or the multi-language support. But Qt has a Java API if you're addicted to virtual machines, and the C++ toolkit compiles anywhere with a modern C++ compiler. It supports Javascript (QtScript) and Python bindings. But unlike Mono, which is Microsoft derived, there will be no patent worries. Nokia really does want Qt everywhere.
The picture is getting more and more complicated when it comes to software development, and I think that's wrong. I liked .Net as an idea. We could all code to one platform, but the business/IP aspects prevented that technical utopia. I am hoping that LGPL Qt will, while a little more limited be that multi-platform toolkit that everyone can use to solve new problems, instead of continually recoding the old ones.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Now that Java is open source, wouldn't it make more sense to use the JVM as the standard runtime, instead of something that "might" not get sued for copying the .NET runtime?
Java has already been made to run on .NET. I wonder if it'd really be that hard to get standardized C# running on the JVM?
With Mono you can run C# code (even WinForms) not only on Linux, but also MacOS and it seems also on Solaris (http://codicesoftware.blogspot.com/2008/12/plastic-on-solaris-10.html, http://codicesoftware.blogspot.com/2008/12/opensolaris-and-mwf.html). The only thing they miss is a decent debugger on all platforms (currently only on Linux). It's unfortunately not easy to develop on Mono right now, but IMHO only due to the debugger. If they had one, more and more people would be jumping into it. Performance is very, very good, close to C/C++, but coding in C# is easier.
Until Mono gets WPF support there isn't going to be much cross-compatibility. Any Windows .NET developer with any sense is writing in WPF already. WinForms is dead.
But Mono seems quite content to ignore WPF for now. One can't help but think it was part of that Novell/Microsoft deal.
The subset of WPF in Moonlight is useless for non-web development. It's great way for MS to pretend their Flash-killer format is multi-platform though.
Sorry, I will never trust Microsoft enough to put them in a position to control a key technology. So that means there is no discussing the issue as far as I'm concerned. There is NO rational basis to argue. I don't trust em.
And I don't trust the judgement of anyone who isn't themselves suspicious of Microsoft and Miguel's motives.
Mono is a trap if it is allowed to be deployed beyond a browser plugin to support .net content in the browser. Come the day my current distro of choice loses any finctionality when removing the mono packges I'll be running something different as soon as bittorrent can supply me a new install image. Again, that position is 100% non-negotiable. I have used binary drivers in the past, bought closed source apps and committed many 'sins' against the Church of GNU but this is one case where compromise simply isn't possible. They want us dead, you can't compromise with that.
Democrat delenda est
Next question?
de Icaza can go to Hell along with his bosses at Microsoft.
you had me at #!
Most people think of Qt as a GUI toolkit. They're not wrong, but that's like calling a Swiss Army Knife a "pocket knife." That's only one thing it does, and the characterization completely misses the point. Qt is an application framework. It fixes every gripe developers have with C++.
Qt promotes clean and well-developed code that is easily ported to Windows, X11 (Linux et al), Mac, and Embedded (Linux sans-X11). That's something even Java doesn't do well (have you ever tried porting between J2SE and J2ME? nothing works!), even disregarding the whole performance loss from the JVM emulation-like interpreting that goes on.
The LGPL relicensing of Qt coming this spring will change the entire programing language landscape. Nokia is moving in to crush Java. C#/.NET and it's mediocre OSS implementation in Mono aren't even on the radar.
I cite the LGPL announcement because that's the kiss of death, placing Qt firmly above GTK (GTK being an incidental casualty on the way to said crushing of Java). With Mono relying so heavily upon GTK#, that puts it behind the game already (the Qt# project is cited on the Mono page as completely dead).
Recall that Nokia is a phone company. They need not make money from the software. Freeing and promoting Qt (and getting it to supplant J2ME) merely feeds this primary function. And while they're at it, they're sweeping in a wonderful set of perks for software engineers in and out of the Free Software community, on both embedded platforms and desktops.
Use my userscript to add story images to Slashdot. There's no going back.
There's simply no overwhelming reason to use this when alternatives exist.
to the casual observer, a copy of a not very successful proprietary virtual machine and framework that has been partially abandoned by its own masters-- it does not sound like a super idea.
You might recall Microsoft spent like three years rewriting parts of Windows in .NET and then gave up on it, for all the obvious reasons. Maybe we can learn from their very expensive learning experience?
Mono developer = Microsoft .NET developer, but a Microsoft .NET developer != Mono developer.
And that's a good thing? If Mono were merely a separate 'take what you like and leave the rest' clone of .NET it wouldn't be so bad, I guess. It might be yet another potentially portable platform (albeit one that carries vague patent threats).
But Miguel has actively promoted it as a way to get all that great .NET code being developed out there onto Linux. And that it is not. Probably never will be. Microsoft certainly doesn't want it (or won't once they displace Flash), and Miguel can't do it in any practical way.
He'll come close. Achingly close. But Mono code will be limited practically to Linux. Or it might work on Windows in whatever limited way GTK stuff works there today. Certainly not likely to work on Mac's or various phone platforms.
And there are technologies that already work on all those platforms. If Microsoft wanted it (and if anybody would - or could - ever trust them), .NET could work on all those platforms. But they don't, and it won't.
So keep working on Mono. It may someday be a nice technology in its own right. But *please* stop trying to justify it by saying that someday it'll make all Windows code 'just work' on Linux. Does anybody really believe that?
Posted from my Android phone. Oh, I can change this? There, that's better...
There's no reason it can't. I recently bought some new virtual instruments. Those are large sets of samples of real instruments, combined with playback software for making music on the computer. They came with a new sampler I'd never used before, developed by the company that sells them (EastWest Play, if you are wondering). I was mildly surprised that as it was installing I saw Qt4Core.dll, Qt4Gui.dll and QtNetwork4.dll were copied to my system directory. Turns out they decided that QT would be good to use for drawing the GUI. Probably in part because it's Mac and PC.
At any rate, there was no additional install of QT required. The necessary libraries were included in the installer, and installed to the system with the software. So if you wish to use QT for your program, go for it. Windows programs very frequently include third party libraries (FMOD would be a popular one with games). You just have the installer handle it.
However comparing QT to .NET is kinda off base, they aren't the same. The reason to use .NET is because it is a managed framework, just just because it can do GUI easily. Visual C++ provides easy GUI tools and will compile to native code.
Also using .NET doesn't preclude using QT, there are bindings for QT to C#.
Java has already been made to run on .NET. I wonder if it'd really be that hard to get standardized C# running on the JVM?
The longer answer is that for anything written targeting the .NET Framework (Mono or otherwise) version 2.0 and beyond, it would extremely difficult if not flat out impossible. The first thing that comes to mind is the runtime erasure of the type parameter(s) for Java's generics. This does not exist in .NET and that has some significant implications. There would simply be no straightforward way to get the following C# class to work in the Java Runtime:
class MyClass where T : new()
{
public T GetNew() { return new T(); }
}
There was a famous story about Sun and IBM that got aired a lot during the MS antitrust trial. It goes like this:
One day, a bunch of IBM patent lawyers show up at Sun's headquarters, saying that Sun is infringing on patents A, B, C, etc. They demand a hefty license fee. Sun engineers (remember, it started as a company of engineers) sit down in a boardroom with the lawyers, look at the patents, and are surprised--they're for various obvious things like mathematically adding a variable stroke to a line, and such. The engineers walk the lawyers through their own patents, explaining how they're all obvious and wouldn't stand up in a court of law. The lawyers remain silent until they're done. Then the chief lawyer says "Perhaps you're right. But after one big court case dragging on for years, we'd just come back with another set of patents and repeat the whole process. Eventually we'd find something that you'd infringed on, and then you'd have to pay damages rather than a licensing fee."
Sun signs a cross-licensing agreement with IBM the next day.
That's the worry. It's not that Microsoft has patents that can allow it to launch SCO 2.0 with a better hope of success. It's the worry that, if they decide to snuff out Mono, they can launch a legal crusade to so encumber Mono in litigation and FUD that it dies an ignominious death. Then all that effort is wasted, OSS and Linux get a bad name in the process, and a lot of developers and customers are soured on Mono, Linux, and anything that doesn't come from a Fortune 500 company. This is why Novell signing a patent cross-licensing agreement caused such bad blood--it implies that MS does have patents that are or could be infringed. On the fateful day that MS decides to crush Mono, Novell's agreement strengthens MS's case, if only in PR terms.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
I know the story, but I don't see how it is relevant here. Microsoft could do the same thing to Java, or anything else for that matter. If the only argument is that "Microsoft might strong-arm you out of the market" then nobody else on the planet should write software.
I agree with you about Novell - my hatred for them is the strongest reason I avoid Mono.
It's not just that MS might come after you. It's that Mono, being an OSS implementation of .NET, would appear to be uniquely vulnerable to being crushed by MS if the beast deems it to be too great a threat, in a way that Java isn't as an independent technology.
C# and the CLR are ECMA standards, and as part of the standardization process, MS gave up the ability to make any patent claims. The idea that Microsoft might somehow be able to torpedo Mono is pure fantasy.
Hell, there's not even much reason to think Microsoft would want to torpedo Mono. They wouldn't have submitted their standard to ECMA if they didn't want it to be implemented.
Of course, all the logic and explicit legal agreements in the world won't change the minds of the folks here who are dead-set on this conspiracy theory.
Visual IRC: Fast. Powerful. Free.
WinForms isn't dead. In some circles, I'd say WPF is stillborn, and if there's anything good that came out of it, it was in fact Silverlight.
In fact, I would say that while WPF has its plus sides, its got a few drawbacks as well. Its -really- slow compared to WinForms, the nested control architecture isn't as good, the layouts and sizing aren't as flexible, and worst of all, there's no datagrid.
I understand the inspiration. Microsoft tried to make a modern client gui toolkit that gives you some of what html does, but I frankly think they missed the mark. If anything, WPF will inspire the idea that developer's have choices in control and widget sets and that will lead developers to look at things like Qt and Java or even Webkit, as I have done.
This is my sig.
Compiling C# for JVM would indeed be a huge undertaking. However in the particular example you give you've fallen for a common fallacy. Hypothetical C# on JVM compiler would not need to generate a line for line equivalent in Java. Taking your example a possible translation maybe :-
class MyClass<T> {
private Class t;
public MyClass(Class t) { this.t = t }
public T getNew() { return (T) t.newInstance(); }
}
The compiler would then have to supply the class type when instantiating MyClass. By no means would this look nicer than the original but then it's auto-generated right and not for humans.
There are a couple of languages that have been written for JVM. One of the more interesting ones is Groovy which has many features that are not in the Java language like closures. So the point is just because the Java language does not implement a feature does not necessary bar a language that does have it from being written for the JVM.
Come on, this debate's been over since the mid-1960s. Stereo won, Mono lost... end of story.
Multiplayer Gaming (defined): Sitting around, discussing single-player games with my friends, at the bar.
Nope. ECMA has not forced Microsoft to give up its patent claims. The only requirement with respect to patents is that they be available under "reasonable and nondiscriminitory" terms -- which basically means that Microsoft can charge whatever it wants for patent licences, as long as it's the same fee for everyone. So MS can still threaten to sue for patent violations. And any fee of significant size is of course fatal for free software. So you are wrong.
it just dawned on me...
Microsoft is giving Linux Mono!
I guarantee, if you grep the source, you'll find epstein-barr.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Here's one that covers ADO.NET and parts of ASP.NET:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6920461.PN.&OS=PN/6920461%3Cbr%20/%3E&RS=PN/6920461
Is that good enough for you? Because there are more. Lots more. Search the US Patent Office site for them.
Basically, Microsoft could enforce its patents to make Mono drop support for ADO.NET, ASP.NET and WinForms. Sure, they aren't part of the CLR, but Mono would be useless without them (especially in the eyes of Windows developers who the Mono team thought would flock to Linux if it had .NET support). It would basically kill Mono (although it seems pretty much dead now anyhow).
Yep that's right. I remember back in the day, I worked at a Microsoft "Very Valued" Partner which basically meant they could screw you over whenever they wanted just because and if you didn't comply, no more partner for you (*yank MSDN library and cheap licensing*). I almost brought the company to the brink of losing their partnership just by recommending Linux machines (which we did sell but apparently not advertised) to users that needed a xAMP stack.
Either way, the company had to build their own ERP (simply because they wanted to - this was the .com era) and Microsoft somehow got involved which trumpeted Visual Basic everywhere, the early releases of .NET were not stable yet and according to them .NET was not yet ready for business. Of course, if you ever did VB you would know that once you're done, the code looks like crap, the thing is as slow as hell and crashed every so often. 2 months later, the same people told us that it would be better to do it in .NET (which was then just out as 1.0) and it would all be very well. If you ever worked with VB.NET back then you would know that it was just as buggy as classic VB although 'neater' to code for and the functionality was all well so the company folded to the MS pressure and rebuilt it. All fine and dandy until MS came out with C#. All of a sudden early .NET (preview and 1.0) became largely deprecated (what, this was supposed to be a stable and EXTENDIBLE language!) and with it also VB was heavily modified to fit the 1.1 framework and so there was another rebuild of some code. Of course some parts were still in classic VB and old .NET code and in the mean time new programmers had come and external things had started to happen so just rebuilding pieces of the application started breaking. Also major security holes were found, were patched and broke stuff and thus the application had to be rewritten from the ground up (again) in C# for .NET to fit the thing.
I left the company later after that. In the mean time 2.0 and 3.0 came out. I wonder if they have been rewriting stuff for almost a decade now. Maybe if they just stuck to PHP and C++. I read a good (older) book recently on C++ and it said a good extensible program (algorithm) in an OO language is written twice: once to know what classes you are going to need to build, second time to apply what you got to know in well documented code, classes and libraries. I believe writing something more than 3 times just because the libraries you got to rely on changed is just bad practice.
Custom electronics and digital signage for your business: www.evcircuits.com
Time to look at Scala on the JVM: classes written in the Scala-language runs almost as fast as ones written in the Java language. Also Scala looks a lot like the Java language. http://www.scala-lang.org/
Mono is not dead—it just smells funny
It's a very dark ride.
There are some pretty significant differences between the two technologies actually. While there are analogous tool types available for both, the implementations of each are quite different. Certainly enough for a difference to be noticed. Just in terms of windowing toolkits, WPF and WinForms are quite different from Swing and SWT. Microsoft's control of the CLR has upsides and downsides. It does allow them to very quickly add new features to the framework. However, this tight control leads to complications with alternative compatible runtimes. Java has the JCP, which is also has it's benefits and drawbacks. While open and transparent, changes are made quite slowly. However, this openness, coupled with now being open source, allows for viable alternative runtimes with no concern over patent infringement. I'm not quite sure what there is to fail to understand or be annoyed by. Computing is a finite thing. Therefore, there is simply no "best" solution to all problems. Compromises must always be made and they are going to serve one end to the detriment of another.
"If it gets too powerful, or too feature full, who's to say if MS doesn't retract their promise and claim that Mono is infringing on their patents, suing whatever company might have worked on said products?"
MS patents are going to be general (as all patents with "business goodness" are). In other words, MS isn't going to limit any patent description in such a way that only .NET implementations would be in violation. If mono violates a MS patent it's very likely that Java and many other projects will violate it too. The mere fact that Mono is an attempt to implement a sub-set of .NET doesn't mean it has any greater risk than other projects.
In any case, I seriously doubt that MS has any desire to start a patent war anyway. Between the DOJ and IBM, it wouldn't be a winning strategy.
AFAICT people use mono to go MS 'native' - meaning .Net - when needed. The only non-trivial application in Mono I can think of right now is Unity, and that's a closed-source RT3D toolkit for x-plattform developement on Mac OS X. And apparently a very good one at that. They are being bugged left, right and center to deliver on Windows. And are preparing that now.
I have to admit that Mono has gotten me curious, because Monodevelop is a very neat looking IDE, C# doesn't seem so much of a PITA than C++ or Java and it appears to be more suitable for stronger ties to multimedia hardware than Java. I still haven't seen a convincing multimedia app in Java in 10 years, allthough the current 3D stuff with native OpenGL does look and run well.
On top of that it appears to me that Mono apps are easyer to deploy that Java apps. I'd expect Java developement to get up to speed fast in any revent Version of Netbeans. However, I catch myself still trusting Mono for good performance more than Java.
Bottom line:
Going Mono to me basically means nothing other than spending time learning C# and watching out that no MS dependancies sneak into my work. A risk I'd be willing to take, given that it has evolved into a feasable tool recently. However, the don't-trust-MS arguments delivered here are valid, and you ought to know what you're doing and calculate your risks well when dicking with MS-controlled tech.
We suffer more in our imagination than in reality. - Seneca
Really?
http://www.indeed.com/jobtrends?q=linux+.NET%2C+silverlight%2C+ruby&l=
This search is moot, the querry ignores the '.', you just searched for Linux network-related jobs.
Comment removed based on user account deletion
A third party implementation of a standard defined by the first-party implementor is always going to lag behind the original.
Linux, GNU, GNU C++, libc, and many other tools that we take for granted all started out as clones of proprietary software from a litigious, monopolistic company. So did many other open source projects. If people had followed your reasoning, free software and open source software wouldn't exist. .. What matters is that when developers and end users pick a technology, they pick the leader, not the follower. Accepting Mono is giving up and giving in to Microsoft vendor lock-in.
Lucky for us, then, that Mono is not a follower. There are dozens of Mono-based desktop applications, and they are not based on .NET, but instead on Gtk# and other Linux technologies.
The situation with C# is really not much different from C++. There is an open language standard, there is a large set of Linux-native libraries, and there is a large set of Microsoft APIs. For C++ on Linux, you get GNU C++, Gtk+ and other FOSS libraries, plus WINE if you want it. For C# on Linux, you get the Mono C# compiler, Gtk# and lots of other FOSS C# libraries and bindings, plus a separate set of .NET libraries if you want them. Mono's .NET libraries seem to be used about as much as WINE, which is to say, not a whole lot. The FOSS C# libraries are just a lot better.
Well, lets take WPF as an example. There are, and have been for years, equivalent Java frameworks. SWT and Swing really aren't the same thing at all, they're widget toolkits, not presentation frameworks.
What would have stopped WPF from being implemented on Java? Nothing. Nothing except the narrowly self interested strategy of one company, who could have provided a technology that EVERYONE could use on a mature platform, but instead we have no such thing. Instead man lifetimes worth of engineering talent had to be wasted on reproducing basically a clone of Java so that MS could 'control the technology'.
I don't really criticize MS for that, it is a result of the way business operates and it makes perfectly good sense from their standpoint to do it that way, but MS's standpoint has no relevance to me or other developers. It is just that simple, and IMHO it would be nice if the marketplace were to just slap down that sort of self interested ploy. I'm really not trying to take sides either, I'd have the same opinion if Sun's and MS's positions had been reversed.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
I've given Mono a fair bit of consideration. I should give it more, because I feel like it's important to evaluate carefully these technologies that might be useful to me...
For interoperability I think Mono is a good thing, end of story.
But I don't think it's a technology that I want as an integral part of my Linux system. There is the whole "Microsoft may decide to be bitches" thing, which kind of puts me in the position of liking what Mono can offer but not wanting to rely on it too much... But there's also the fact that it's kind of a little bit alien. I want a Unix system based around Unix concepts... Mono has at least a few Windows-isms to it (.exe extensions, for instance) but I don't know if it goes deeper than that. That's OK for a package I'm installing to gain the ability to run .NET software, but it's not something I want in a package that I'm going to use to build new applications and such for Linux. I wouldn't want to treat Mono as a core part of a Linux system if it has too much Windows flavor to it. It's just not the kind of system that I want. I like the technology (especially now that Mono supports native compilation) but I feel like it's also important for the technology to fit the system where it's to be used.
I do feel there's a need for some of the things Mono has to offer: I love what .NET does in terms of promoting cooperation between different programming languages (the various .NET versions of scripting languages and other programming languages, built to take advantage of the CLR, and so on) - it should be easy to pass objects from one programming language to another, and it should be easy to bind existing libraries to different programming languages - and .NET does that. Scripting languages benefit from having a good, efficient intermediate bytecode form - that is also provided by .NET. This is why, despite being a bit uneasy with Mono (partly, I'll freely admit, due to long-standing prejudice and grudge regarding Microsoft) it's still appealing to me.
Bow-ties are cool.