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.
Every mono aplication I've run across is slow and breaks strangely. Because of this, I've always considered mono as truth in advertising. Are there any good examples that might change my opinion?
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.
Only on the same level as us making programs for mono. Considering that slashdot crowd is smart enough to STAY FAR FAR AAWAY from mono, I think that speaks for itself.
Why using an MS technology, on Linux? Technology that will probably be made obsolete by MS in a couple of years, by a new shiny replacement .XYZ+++ in order to SCAM more MS fan boys (all wearing their Tinfoil Hat).
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.
Can I watch netflix streaming through mononucleosis? If not I don't care...
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
Mono is great to develop multi-platform code. Easier than C/C++ and almost as fast. You can even run WinForms code in MacOSX, Linux and even Solaris (http://codicesoftware.blogspot.com/2008/12/opensolaris-and-mwf.html). The only thing they miss is a debugger on all platforms. Their problem seems to be the lack of focus. Please folks: - A debugger now on all platforms!! - Eclipse integration (whatever, slick edit is enough but...) - Qt *real* support And then lots of people would jump to Mono/C# from C/C++
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?
The main problems aren't so much the language as the lack of a useful standard library. No cross-platform networking, no cross-platform threads, no thanks.
This is slowly being addressed, so it may be less of a problem in the future. OpenMP is slowly becoming a threading standard, and it looks like boost now has a sockets library. But it's a huge hassle of #ifdefs for now.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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...
While the likelihood of Mono being a trap has come down over time, I'm still not very keen on installing or using it. So unless something important enough to me comes along that requires it, I will avoid anything which requires it.
I want to know what the mysterious magical patents are that makes Mono somehow more dangerous than Java, or Flash, or any other framework.
What patents does Microsoft have on .NET? What could they do that magically would make already written and deployed .NET apps on Linux require licensing?
Frankly, I think Microsoft has the best possible situation. They can take the high-road by claiming it is an open standard, but drop little hints like "you know... we could patent it..." so that people won't use it. Win-win for them. Oh, and the resulting in-fighting, and waste of developer time putting effort into a project that nobody uses. So make that Win-Win-Win.
C# and .NET are the absolute best set of development tools I've ever seen. I hate to see fearmongering cause us to not use it, and Microsoft gaining the advantage.
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(); }
}
I currently research methods to improve cancer treatment using proteomics. Bioinformatics plays a key role. Thanks to Mono, we were able to port existing software to Linux and run in our cluster. Indeed, it must be recognized that Mono is contributing to this field and many others.
That should be:
class MyClass<T> where T : new()
{
public T GetNew() { return new T(); }
}
I didn't think of the HTML formatting not liking the <T> bit
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.
Because the Unity platform uses Mono technology under the hood, developers can code their game once and then target Windows and Mac OS X simultaneously.
Yet the tools themselves only run on Mac...
For starters, unlike Microsoft .Net, Mono is cross-platform. It runs not only on Linux but on other Unix-like operating systems as well -- including Mac OS X. It even runs on Windows.
Shouldn't mono be completely irrelevant if done correctly? That is to say - if I can't compile a .net app of any complexity on Windows with Microsoft's tools, then run it on Linux under Mono; or vice-versa , then it's failed at being cross-platform.
that is the stupidest thing I've heard all day. Play with Mono because of you play with it alot, Microsoft is going to be _less likely to fire a slug in your head_. Wow, sure makes me want to play.
don't the Comes docs show that Microsoft is still the same old Microsoft? didn't the ISO issues show that Microsoft is the same old Microsoft? Hasn't the bazaar patterns OEMs have been in with regards to Linux on netbooks( or really XP on netbooks ) enough to show that Microsoft is the same old Microsoft? Seems they are still paying off people to write stories for them or else the author is just plain thick.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
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.
"The more Mono evolves, the less likely Microsoft is to use patent claims or some other dirty trick to bring down the platform"
The words 'less likely' do not inspire confidence. I cannot think of a time where Microsoft has not used every tool available to further its market position in every area it can... when it is in a position to do so and it furthers its profit margins or market size.
I have never used .net, so I cannot speak of its power or weakness as a platform tho.
Good luck to the Mono team in pealing yourself away from MS and being accepted by open source developers
I agree that nothing bars C# form running on a JVM, but I am not falling for a common fallacy either. I never said that the generics implementation would make it impossible. Just far from straightforward. Combined with all of the other differences e.g. framework, lambda expressions, unsafe code and so forth would make it at the very least extremely difficult.
What the author misses entirely is while he feels it is less likely to happen less likely is still more likely than utterly impossible. There are other technologies available, such as Qt, where microsoft has no potential for a valid claim over the language. Why, as a developer, would I choose to put my code in a position where this concerns exist instead of taking a path that avoids it entirely?
... instabilities and other security hazards. Install Mono? I think not.
That is for a Texas jury to decide, not you.
Link
If you want your life to be different, live it differently.
The question is, "Do we really need C#?"
I think that with Python, Java, Python, QT, and Python we don't need that Mono thing at all, especially when with Python we can de everything we would ever want or need.
Some people may say that Python is slow, but it's like that because it's too easy to code, and programers often forget about performance, but Python can ve very f*ck*n fast!
4 - A robot may not masturbate, except where such action would conflict with the Second Law.
Is memory loss common in this community?
Author, Shell Scripting : Expert Re
I think what you outline is a possibility, but it is not mandatory. I don't believe that Samba, for instance, makes Linux a second class citizen. Far from it...
Most folks that I know would much rather run Unix based Samba servers than Windows, and I do believe that Samba has reached such a degree of penetration that breaking it would not be in Microsoft's interest: think of the number of media servers designed to share with windows systems that are actually running an embedded Linux.
I'm certain there are other cases where the open source implementation is better than the proprietary one.
And I say unto you, well played, sir.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I just don't see some kind of great advantage of the CLR over a JVM. There really is very little difference between the technologies and 100% of the existing Java APIs are already available on every platform.
I suppose in some version of the future that may come to pass where .Net becomes as well supported and Java somehow fades into the twilight then maybe I'd switch to .Net based technology. I seriously doubt I'd really notice the difference.
As it stands now I'm just annoyed at MS's selfish desire to control their VM to the exclusion of everyone else. What purpose did that serve? Its here and it isn't going away, but it was a fairly pointless move from the rest of the world's perspective and now we're stuck with a fragmented VM technology landscape.
It is kind of sad really, but Java continues to do what we need it to do and there is no convincing reason to WANT to switch.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
I originally redicted Mono's demise in Dec, 2005 (reconfirmed in Jan, 2006), well before Neil McAllister and received quite a bit of jeering and obnoxious commentary -
http://www.realmeme.com/roller/page/realmeme?entry=mono_meme_update_mono_still
However, as we all know now, it has indeed been dead for the past 2 1/2 years and it will stay dead. Check out the relative trend strength for Mono versus Silverlight or Ruby.
http://www.indeed.com/jobtrends?q=linux+mono,+silverlight,+ruby&l=
He's still dead, Jim.
I'll agree with you that C++ sucks. OpenMP is looking good though. Right now I use pthreads-w32 for Windows and POSIX threads elsewhere (Linux, BSD, OS X).
It is true that programming for platforms is sort of an issue with a bunch of #idefs but I find #ifdefs to be a lot better than starting from scratch.
With something like Qt (speaking of the GUI toolkit and ONLY that), you will have very few #ifdefs in my opinion because MOST of the code is completely cross-platform.
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.
2. Unless there is a hard requirement, development time is more important than raw performance.
But there are plenty of hard requirements in common scenarios. For one thing, the signal processing inherent in live TV production or video games must finish in 16 milliseconds or end up dropping frames. And applications running on handheld devices need to be efficient at keeping the CPU asleep as long as possible; otherwise, the battery won't last through an 8-hour shift.
3. Hardware is cheaper than developers.
If so, then why don't more mass-market computer software publishers bundle hardware with their software?
In all seriousness, the fusion of .NET and Office, using Visual Studio Tools for Office, makes for some interesting possibilities indeed. I mean, the Web may be all the rage, but, if you tell some people that they can use Excel as a front end into anything, they are going to jump on it, and if they are paying, I'll be happy to help them out, in a heartbeat, if I thought I could get a deal done, especially in this economy.
Sure, let someone walk in with a sucky table and javascript based grid on a web page and babble on about Web 2.0 and Linux, because I'll be there with the whole damn front end in Excel, and showing them how they can cut and paste and get data from everywhere, and have it all in Excel. And on top of that, I would probably even stoop so low as to talk about leveraging the COM Interop of .NET to talk to legacy VB6 objects and to kick out form letters in Word, and I'd could even see myself throwing in a blurb about how I could use WPF to implement a Clippy like guy that doesn't suck, so...
that when the dust all settles, my client would be able to pull all their enterprise data into Excel, click on a cell, and get a clippy like guy to help them prepare a form letter for mailing to a prospective client, using of course an Active X control to capture the signature in just a perfect way. The whole thing would probably way in at 100MB for about 2000 lines of code, but, you see, the secret of Office integration is not that you have all of this bloated stuff, its that, you are just adding on to what they already know so that it makes it easier for them to learn, and easier for me to get the sale, and, then, for the next step, then I can babble on about web 2.0 and Linux, or Windows, or whatever they prefer me to babble about!
This is my sig.
Konqueror reports that the site has bugs. Hmm... Should I trust this guy?
Damn. I apparently checked "Post Anonymously" by accident. Please pretend the above post says, "AKAImBatman" on it.
Javascript + Nintendo DSi = DSiCade
read more about it http://en.wikipedia.org/wiki/Infectious_mononucleosis
16 milliseconds is a yawn-fest for nearly any language.
Not on a handheld device. PDAs, phones, and PSPs tend to have 0.2 GHz single core CPUs, or even slower in the case of Nintendo DS.
Because it's easier and cheaper to write "Minimum Requirements" on the side of the box, where "Minimum Requirements" hits at least 80% of the hardware on the market?
For one thing, I seem to recall that 80 percent of PC users did not have hardware capable of running something like EA's Crysis at a solid 60 fps on medium settings on launch day. Nor do 80 percent of users own an HDTV or other PC-compatible monitor larger than 19 inches. Families with children, which make up a large part of the target market for E-rated PC games, tend to have other expenses that force them to make do with obsolete PC hardware.
Why? Where is the need? .Net/Mono is yesterday's solution.
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/
Comment removed based on user account deletion
Mono is not dead—it just smells funny
It's a very dark ride.
"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
What's the point of Mono?
Reasonable question.
Even without answering it, it's obvious that there is a good answer, because Mono is seeing uptake by serious projects. For example, the Unity game engine and the popular virtual world Second Life.
As for a concrete answer: For starters, if you want something like Java - a virtual machine, with a nice language that manages memory for you, and can also run multiple scripting languages as well - then Java vs. Mono is somewhat like GTK vs. Qt. Yeah, for a long time Qt was arguably better, but Qt was GPL while GTK was LGPL, so just because of that GTK saw a lot of use (there were other reasons as well, but this was a major one). Ditto here, Java is GPLed while Mono is LGPL (with class libs as MIT and a few other details), which makes corporate adoption much simpler. Yeah, technically Java has better performance - say by a factor of 2 - but licensing is also a serious consideration.
Other reasons: Some people prefer C# to Java (I'm not arguing either way, just pointing out that some people think that way - and some think the opposite), some people want to leverage existing C# code that they have, some people want an implementation of Python with native threads (IronPython on Mono does that; Jython on Java was inferior for a while, but might finally be catching up just recently), etc.
Ive got several devices around in my room right now, ive programmed for each and every one of them.
HTC Tytn II ( Kaiser ) - 400 mhz arm9, running winMobile 6
PSP - dual MIPS cores @ 300 mhz, running uITRON
NintendoDS - 66mhz ARM9
A wireless router - 300mhz BroadCom MIPS, running uCLinux
A couple of bare AVR devices @ 8 - 16mhz - running straight metal code
What were you trying to say, again ?
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
If MS starts threatening Mono with patents, simply move development and implementation out of the US.
If Mono is not very good, the US benefits.
If Mono is a good tool, the ROTW benefits.
This is is how Patents are an aid to innovation and job creation!
When Javascript was submitted to ECMA and became an open standard I didn't hear of loads of people saying "Don't use it, its a trap, Sun will pull the plug any day now and sue you for using their (now standardised) language". But loads of people say that about the ECMA standardised .NET. What's the difference? I'm sure you're about to tell me.
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.
Individual programs should be judged on their own merit not based on their language of implementation. I've seen some pretty fast Java programs and I've seen some poorly performing C++ programs.
Back in the 90's many people used to look down their nose at programs written in VB, especially in the shareware communities. Where having MSVBVMxx.DLL in your installables was looked upon as a mark of shame. When instead people should have been looking at the programs for their own merit.
I wish timothy would only publish articles like this so I could ban him and increase my slashdot SNR. However, I can't ban him from my RSS and thus I will be stuck with his MS-spun articles for years to come...
-- I was raised on the command line, bitch
Admiral Ackbar knows the truth...IT'S A TRAP!
Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
Right, all of the #ifdefs are in the library itself. I'm not saying that is good or bad.
No reasons he can give would be good enough. The English language does not really contain sufficiently scathing terminology to articulate my disdain for Mono, but I'll make a brief attempt anyway...
.NET thing was a solution in desperate need of a problem in the first place, *even* if you're only concerned, ever, about supporting the Microsoft Windows platform.
.NET looks pretty good (a premise I am not entirely willing to grant), there is no reason to believe that will be the case five years from now. If the Mono team wanted to develop a *useful* development platform, they would decouple themselves from compatibility with .NET and instead build something that can go in whatever direction the open-source community needs it to go in the future. As it stands, Mono is shackled to Microsoft, the king of bad design decisions. Why on earth would I want to develop software for a platform that has no future?
The whole
Cloning it for *nix systems was and remains an inherently brain-damaged idea, a worse-than-useless thoroughly misguided disaster, *both* in terms of open-source ideology *and* practicality. Not only will it *never* have any hope of accomplishing the original stated goal of widespread cross-platform compatibility, but it also fails badly as a development platform generally.
In terms of open-source ideology, Mono is an abdication of platform design to a proprietary monopolistic corporation. Even though the implementation is not proprietary, it still has to follow the design put forward by the proprietary corporation, and that makes it totally unacceptable to anyone who is serious about software freedom.
In terms of practical issues, which are more important to me, Mono is an abdication of platform design, not just initially but also going forward, to an organization with a long history of some of the worst platform design in the industry, not only from a security perspective but also in terms of the impact the platform has on how software developers do their work. *Even* if the design of the current version of
Mono servers no useful purpose whatsoever and instead actively detracts from the open-source community.
Cut that out, or I will ship you to Norilsk in a box.
There wasn't even a cease and desist in that case, it was just one microsoft project manager who unofficially contacted the guy. Hardly a smoking gun.
If you need web hosting, you could do worse than here
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.
The situation with Mono is no different than with C or C++: a lot of code is cross platform simply because it gets by with the common core library. GUI code in Mono is not cross-platform by default, but if you really want them, there are cross-platform GUI libraries available for Mono.
As C and C++ have shown, that's the right choice, while Java has conclusively demonstrated that the alternative, forcing everybody to use cross-platform libraries all the time, does not work.
Mono's mix of a common core library, platform specific libraries, and cross-platform libraries is a big advantage of Mono over Java.
What's the point of Mono?
Reasonable question.
I didn't feel the article did a good job of answering that, either.
"Mono isn't trying to replace Java -- or .Net, for that matter. It's trying to do a lot more, and that makes it a project well worth watching."
It's trying to do a lot more than just be another Java or a compatibility layer for .Net. Like what, specifically?
I am not so biased that I can't see some value to it - there's real value to a language which is more expressive than C or C++, but also more efficient than Python or Ruby. There's real value to having solid mechanisms in place for component wrapping, object brokerage, or whatever you choose to call non-trivial IPC with a consistent interface. But I also can't escape Microsoft-related FUD about Mono's future (it is a real danger, as far as I'm concerned) - and as long as developers believe in that danger, Linux as a system won't fully exploit Mono.
Having to run things under the CLR was one of my big problems with Mono, though - I'm glad to see they got native compilation in there. It just seems ridiculously stupid, once your program's working nicely, not to provide the efficiency of a good native compilation.
Even without answering it, it's obvious that there is a good answer, because Mono is seeing uptake by serious projects. For example, the Unity game engine and the popular virtual world Second Life.
I remain unconvinced. So people are using it. Does that mean I want to use it?
Let's put this another way - it's not all about this doom & gloom scenario, that Microsoft may someday decide to cause trouble for Mono - whether that means using its existence as an excuse to try to charge licensing fees to Linux developers or whatever else... Though that does concern me, honestly. (It's kind of an unavoidable part of this whole equation, I think...)
There's this issue of adoption. I don't really want to stand behind a technology that I don't have faith in. The question isn't why don't I have faith that Mono is the right direction, it's more, why should I? Again, the CLR was a big stopping point for me, and the tie to Microsoft (and specifically the potential that they could use that to cause trouble) still is. There's value to what it offers and value in the fact that, being related to Microsoft's efforts with .NET, it will continue to move forward in the foreseeable future... But I don't want the baggage of CLR (thankfully not a problem now) and I don't want an environment that is too alien to the Unix approach of doing things. (I don't know the extent to which that is an issue...)
Bow-ties are cool.
Before you declare that you're any different, think of how you put gas in your vehicle.. Do you care how the fuel pump works? If you're like me you only throw a fit when the clip that holds the fuel lever open is broken, but otherwise don't pay much attention.
Guess what time it is?
It's time for a CAR ANALOGY!
Bow-ties are cool.
The current work that I did in C# is moving to Java. C#, as a language, is better then Java. However, we're part of a distributed application that uses SOAP. Java's SOAP support is much better then Mono's support; and in my opinion, much better then Microsoft's SOAP frameworks. We chose to move to Java because of our strong preference for SOAP.
C# really isn't a "write once, run everywhere" language like Java; it's really more of an improvement over C and C++. C# on Mono has a different set of APIs then C# on .Net. This really means that C# is a better choice if you don't need truly portable code, or if you can deal with having separate Mono and .Net portions of a program.
No, I will not work for your startup
"Toonami is presented in full, rich mono. Stereo is vastly overrated."
Bow-ties are cool.
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.
There are a few other Mono apps out there, though I certainly don't have anything like a comprehensive list. The source control software I used at a summer internship some 2.5 years ago had a nice graphical interface that was easy to use and looked good (I use Subversion these days and am contemplating moving to Git, but at the time I'd never used version control before and found this one quite easy to get the hang of). It ran on .NET 1.1, but the company officially supported the product on Mono as well. At the time, Linux was still not widely known, never mind used - I see it even on non-CS students' laptop now, but certainly didn't then - but this company was willing to put resources into ensuring that their software ran on Linux, simply because Mono was so easy to target.
There's no place I could be, since I've found Serenity...
You're missing the point. The day Microsoft sues Samba and wins in court, distros just stop distributing it as it is not vital to the majority of Linux users. If we base our apps and frameworks on Mono, the Microsoft sues and wins, we're totally screwed. Got it?
Check out my cross-platform apps
Your problem isn't with 'webapps' - which can do EXACTLY what you've just described, and we do it all the time in Flex and Flash. Your problem is with 'terrible webapps'
Oh, and as long as you bother to twiddle with the paths so it knows where to look, those apps DO run locally if you want them to - OR on the web. But voila, no platform issues, and the local disk access is optional.
Any "IE-only" web app is not a good web app, in my opinion.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot