This is a classic FOSS old-wives' tale. The fact that we would like it to be true unfortunately doesn't alter the fact that it is complete nonsense.
In the real world diverse choices at one level (KDE vs. Gnome, let's say) result in reduced choice at another (I chose KDE but now need to run Eclipse etc.).
The trend is therefore precisely the opposite of what the parent poster pretends - rationalization will happen in response to the compatibility imperative and marginal products (XFCE etc.) will decline rather than increase.
Having a system that you trust does not imply or require a system that they trust.
The fact that the underlying trust implementations might be similar doesn't mean that you're obliged to accept the one when you're really looking for the other.
But most people will be doing this the other way around (starting with Dotnet development tools) and I doubt if their experience will be as lucky. Almost certainly not as lucky as mine in running a large Java GUI package developed for Windows on Linux.
Unfortunately for them Miguel and co. are rowing back from claims of Dotnet compatibility, which was the justification for the whole Mono exercise in the first place (as opposed to cloning Java, evolving Perl/Python etc.)
The point was that most of Dotnet isn't standardized (~10% of classes and declining), but there is a group of/. posters who continue to insert this claim into all Mono threads although they know better.
Of course, that probably has something to do with the relative value of a Dotnet compatible system (high) vs. a Dotnet-wannabee (low).
There are some decent arguments for using Mono over Java on Linux
If there are, I'd be interested to see them. Or, more empirically, we would expect to see some evidence of Mono take-up in the business world.
Right now, Java is everywhere in critical LoB applications and has huge support from IBM, Sun, Oracle, BEA and a cast of thousands. In terms of the investment being pumped into applications, in relative terms Mono is absolutely nowhere. And I'd be interested to see performance figures for applications using recent JVMs vs. Mono - certainly the JRockit JVM wiped the floor with Dotnet 1.1 on Wintel in my tests and I doubt if Sun or IBM's JVMs would be far behind.
Holding hands and chanting is no substitute for reality.
Sorry if this clarification still wasn't clear enough for some "developers": if the API changes then Mono is no longer compatible, QED. There is no grey area here.
Yes, this will only affect those applications using the new features, but in practice Mono will trail sufficiently for this to be a significant problem.
MS will do what is in their best interests financially, only the very naive would imagine that pleasing Mono developers would appear as a priority. But of course you and your deluded lieutenants have always preferred to gloss over the consequences of allowing MS to control the platform.
He means Mono compatibility is blown by any change to the API, like the Dotnet 1.0 to 1.1 changes.
Assuming that Mono ever got to be 100% compatible (which is questionable) the carrot would be jerked away again. Think of a spanish donkey with features resembling Miguel's.
As many people warned you at the outset of the Mono development, chasing Dotnet compatibility would be hard. But then if you didn't chase it, giving up at only 90% API coverage for example, the missing 10% would be enough to prevent the vast bulk of Dotnet applications from working on Mono.
So we've ended up with exactly the scenario predicted by some of us three years ago with Mono unable to deliver on its key differentiator.
The IETF's myopic mantra of "everything must be free" has inevitably failed and in its place is a system where the best sites have to pay for the privilege of having a big audience.
A more practical economic model would have ensured that the consumer paid instead of the producer. Now having married these systems in haste we get to repent at leisure.
No, but it might be time to back off from blatantly cloning the Microsoft platform (you know, the one they make half their money from) and try something a bit more original instead.
Unlike Java, Mono doesn't try to shove cross-platform development down people's throats.
Thank goodness someone has finally had the balls to stand up to this "portability" nonsense.
If we want to have the option of a low-cost port to another environment we'll damn well ask for it. And we're not exactly blind - after all, if we can't trust Visual.NET to reliably tie our applications to Windows, what can we trust?
As the parent no doubt accurately predicts, the biggest use of Mono will be the development of Gnome applications, Gnome being practically universal on corporate desktops these days.
Fortunately, as the poster goes on to point out, porting big Windows apps not originally written for Windows to Mono is only the second biggest use, so Adobe and Borland will be quite happy to wait a little bit longer for Mono to accurately support all those tricky little Windows APIs. It's only been 3 years so far. And yes, when they do, porting will be easy! Almost as easy as it is today for Adobe and Borland to port their Java applications, in fact.
I discovered Mono for my at-home-just-for-fun-stuff and I'm now able to leverage the experience by replacing non-Microsoft technologies at my day job with Dotnet.
For Bill Gates, this has probably been the greatest boon of having Mono. Hopefully other developers forced to work in Java or Python will now be able to bring more great software to Windows.
One would never accuse Microsoft of that. Or Miguel.
Unless you're saying that there's something really "fresh" in Dotnet that's not in Python, Java etc.?
Most companies I know using Linux already have a top quality cross-platform environment, transferring their Win32 applications to Solaris and Linux faster than you can decide whether today you're in a WinForms, Avalon or GTk+ mood.
Still, respect due for the brave prediction regarding Microsoft's dominance of the desktop.
Just curious: have you taken steps to inform other users that Mono APIs are not based on, and thus incompatible with, Dotnet APIs?
I ask this because one could easily form the impression from Mono promotional material that it is a complete and compatible implementation of Dotnet. For example, the first sentence in the Mono FAQ reads:
The Mono Project is an open development initiative sponsored by Ximian that is working to develop an open source, Unix version of the Microsoft.NET development platform.
Obviously a well-informed and experienced developer such as yourself is aware of the real situation, but I'm sure you will agree that it would be regrettable should prospective users of Mono be misled by statements such as the above into thinking that they can first develop in Dotnet and subsequently move to Mono.
Slashdot Mirror
This is a classic FOSS old-wives' tale. The fact that we would like it to be true unfortunately doesn't alter the fact that it is complete nonsense.
In the real world diverse choices at one level (KDE vs. Gnome, let's say) result in reduced choice at another (I chose KDE but now need to run Eclipse etc.).
The trend is therefore precisely the opposite of what the parent poster pretends - rationalization will happen in response to the compatibility imperative and marginal products (XFCE etc.) will decline rather than increase.
You've also fallen into their trap.
Having a system that you trust does not imply or require a system that they trust.
The fact that the underlying trust implementations might be similar doesn't mean that you're obliged to accept the one when you're really looking for the other.
No shit?
Proof, if proof were needed, that there's no more reliable guide to modern political thought in America than Mein Kampf.
and nearly six hours later it is still uncorrected.
An utter disgrace.
That's the trouble with the word "free".
Here it means "free" as in "dictated by Microsoft".
But most people will be doing this the other way around (starting with Dotnet development tools) and I doubt if their experience will be as lucky. Almost certainly not as lucky as mine in running a large Java GUI package developed for Windows on Linux.
Unfortunately for them Miguel and co. are rowing back from claims of Dotnet compatibility, which was the justification for the whole Mono exercise in the first place (as opposed to cloning Java, evolving Perl/Python etc.)
The point was that most of Dotnet isn't standardized (~10% of classes and declining), but there is a group of /. posters who continue to insert this claim into all Mono threads although they know better.
Of course, that probably has something to do with the relative value of a Dotnet compatible system (high) vs. a Dotnet-wannabee (low).
There are some decent arguments for using Mono over Java on Linux
If there are, I'd be interested to see them. Or, more empirically, we would expect to see some evidence of Mono take-up in the business world.
Right now, Java is everywhere in critical LoB applications and has huge support from IBM, Sun, Oracle, BEA and a cast of thousands. In terms of the investment being pumped into applications, in relative terms Mono is absolutely nowhere. And I'd be interested to see performance figures for applications using recent JVMs vs. Mono - certainly the JRockit JVM wiped the floor with Dotnet 1.1 on Wintel in my tests and I doubt if Sun or IBM's JVMs would be far behind.
Holding hands and chanting is no substitute for reality.
Sorry if this clarification still wasn't clear enough for some "developers": if the API changes then Mono is no longer compatible, QED. There is no grey area here.
Yes, this will only affect those applications using the new features, but in practice Mono will trail sufficiently for this to be a significant problem.
MS will do what is in their best interests financially, only the very naive would imagine that pleasing Mono developers would appear as a priority. But of course you and your deluded lieutenants have always preferred to gloss over the consequences of allowing MS to control the platform.
One that's an ECMA standard, no less!
Actually a lot less. Only C Sharp and the CLR are standardized, not Dotnet.
That's about 120 classes out of the 1200 or so in the 1.1 platform.
Welcome to the Dotnet-is-a-standard standard rebuttal btw, I suspect this won't be the last time you see it.
He means Mono compatibility is blown by any change to the API, like the Dotnet 1.0 to 1.1 changes.
Assuming that Mono ever got to be 100% compatible (which is questionable) the carrot would be jerked away again. Think of a spanish donkey with features resembling Miguel's.
Absolutely.
Until Mono came along I'd never even heard of Java.
That is why Mono implements two stacks
Two stacks means two platforms.
As many people warned you at the outset of the Mono development, chasing Dotnet compatibility would be hard. But then if you didn't chase it, giving up at only 90% API coverage for example, the missing 10% would be enough to prevent the vast bulk of Dotnet applications from working on Mono.
So we've ended up with exactly the scenario predicted by some of us three years ago with Mono unable to deliver on its key differentiator.
Bit late now.
The IETF's myopic mantra of "everything must be free" has inevitably failed and in its place is a system where the best sites have to pay for the privilege of having a big audience.
A more practical economic model would have ensured that the consumer paid instead of the producer. Now having married these systems in haste we get to repent at leisure.
No, but it might be time to back off from blatantly cloning the Microsoft platform (you know, the one they make half their money from) and try something a bit more original instead.
Right.
If there's one area where Dotnet can clearly win over Java it's the ease of calling Java class files. Let's not forget that.
And for those without the slightest interest in Perl or Python being able to call Perl or Python is unquestionably a huge advantage.
Long live F#!
It's an easy misconception to have, given what the Mono project writes about itself.
Yeah
Now, dig down a little deeper[...]
Well I tried
Bit complicated. I'll stick with Java, least that way I know it'll run. Thanks anyway.
Well thanks for the heads up.
I tried it and now I have 150 if/then statements around this one database call - is that OK?
Unlike Java, Mono doesn't try to shove cross-platform development down people's throats.
.NET to reliably tie our applications to Windows, what can we trust?
Thank goodness someone has finally had the balls to stand up to this "portability" nonsense.
If we want to have the option of a low-cost port to another environment we'll damn well ask for it. And we're not exactly blind - after all, if we can't trust Visual
As the parent no doubt accurately predicts, the biggest use of Mono will be the development of Gnome applications, Gnome being practically universal on corporate desktops these days.
Fortunately, as the poster goes on to point out, porting big Windows apps not originally written for Windows to Mono is only the second biggest use, so Adobe and Borland will be quite happy to wait a little bit longer for Mono to accurately support all those tricky little Windows APIs. It's only been 3 years so far. And yes, when they do, porting will be easy! Almost as easy as it is today for Adobe and Borland to port their Java applications, in fact.
What a coincidence!
I discovered Mono for my at-home-just-for-fun-stuff and I'm now able to leverage the experience by replacing non-Microsoft technologies at my day job with Dotnet.
For Bill Gates, this has probably been the greatest boon of having Mono. Hopefully other developers forced to work in Java or Python will now be able to bring more great software to Windows.
We do not simply make new things up
One would never accuse Microsoft of that. Or Miguel.
Unless you're saying that there's something really "fresh" in Dotnet that's not in Python, Java etc.?
Most companies I know using Linux already have a top quality cross-platform environment, transferring their Win32 applications to Solaris and Linux faster than you can decide whether today you're in a WinForms, Avalon or GTk+ mood.
Still, respect due for the brave prediction regarding Microsoft's dominance of the desktop.
Insightful? Look no further.
You are operating under the assumption that the main use of Mono is going to be to allow people to write .NET software
Strangely that assumption is quite widespread. I think I've tracked down the source though.
Lucky that for you portability from Dotnet to Mono is an added bonus. Let's hope that other Mono users will have an equally chilled attitude!
OK, thanks, will take a look.
Are you referring to Dotnet Remoting? Or is this something else / another name?
Just curious: have you taken steps to inform other users that Mono APIs are not based on, and thus incompatible with, Dotnet APIs?
.NET development platform.
I ask this because one could easily form the impression from Mono promotional material that it is a complete and compatible implementation of Dotnet. For example, the first sentence in the Mono FAQ reads:
The Mono Project is an open development initiative sponsored by Ximian that is working to develop an open source, Unix version of the Microsoft
Obviously a well-informed and experienced developer such as yourself is aware of the real situation, but I'm sure you will agree that it would be regrettable should prospective users of Mono be misled by statements such as the above into thinking that they can first develop in Dotnet and subsequently move to Mono.