Speaking of FUD, Dotnet is not an ECMA standard, only C# and the CLR are.
I have no illusions that, despite having personally rebutted this assertion over 50 times on/., it will continue to be made, probably by the same group of people, and, ludicrously, even as de Icaza is preparing his exit strategy from the whole Mono raison d'etre - Dotnet compatibility.
Hmmm, I don't know about the "quickly" part. A huge amount of effort has been spent getting Java on all kinds of platforms from phones to mainframes.
I think you're talking about 6 years or so to replicate this assuming Mono took off, and right now its take up in the commercial world (vendors and users) is negligable.
If the community were smart, they would take Miguel's suggestion, and start on a competitive stack
Actually this is what the community would do if they were exceptionally stupid.
There's no value in being vaguely similar - Mono has to be fully compatible to have any value over other platforms. The fact that Mono C Sharp programs look like Dotnet C Sharp programs means nothing if the code doesn't actually run - it might as well have a different bytecode, language and CLR too.
Retaining the API is one option, but not the only one they talk about - "removing code" is another.
If this looks like nit-picking, consider the implications for porting a Dotnet app to Mono: if 80% of API coverage is achieved instead of 100% it could easily make the port uneconomic.
This is the problem with the Mono value proposition - it drops exponentially in relation to compatibility, and you don't have to drop far until you've brought the whole cloning strategy into question, the question being whether there was a need to make Mono any closer to Dotnet than Dotnet is to Java.
OK, you've confirmed my understanding of your previous statement - Mono for you is a multiplatform environment in its own right, not a "bridge" from Dotnet that is "helping people migrate their existing knowledge and applications to Unix" as described in the Mono Roadmap. That's fine.
We can then move on to look at the merits of Mono, Java, Parrot etc. from the same standpoint. Regarding the VM, I'd be interested in your source indicating that the Mono VM is safer and more reliable than the "Java" VM. You don't mention whether it's the Sun, IBM, BEA, Kaffe or some other one that was tested - I'm sure you appreciate that such details will be important to someone seriously evaluating these platforms.
The "ECMA and ISO ideas" only cover a small part of Dotnet, the rest is proprietary.
The problem is that Mono falls between two stools: it's neither a complete Dotnet clone, meaning that users get no true Dotnet/Mono portability; nor has it confined itself to merely "adapting" ideas from Dotnet - it's similarity is a good deal closer than that.
Mono is therefore asking its users to risk infringing MS's IP without delivering the associated benefit of real portability. There's little likelihood of Mono ever being a route for getting Photoshop-sized applications from Windows to Linux, for example.
Now of course Mono itself may be multiplatform, meaning that applications are portable from one Mono environment to another, but shifting to this goal (as you appear to be doing in your last sentence) immediately negates the value of the cloning effort. If applications are only written for Mono, there's no reason to stick to MS APIs, languages or bytecode - Mono doesn't need to be any closer to Dotnet than Dotnet is to Java, meaning that the FOSS world will be "free to innovate", to borrow an expression.
You're not alone in being misled by the gap between Mono's stated goals and the reality, and indeed my impression is that leading Mono proponents see little to gain at the present time by clarifying the situation.
The Mono project is public. If you participated or at least followed it...
Fortunately I have better things to do than participate in the mindless cloning of products merely to extend Microsoft's mindshare in the development community.
I take the above as confirmation that there is in fact no such legal opinion available able to offer any assurance on the patent question and that this "advice" is therefore just more arm-waving.
If you want a legal opinion, go pay for it.
I guess you offer the same advice to all prospective users of "your" platform?
What is standardized about C# is obviously ECMA C#. I neither stated nor implied anything more.
Your complete sentence is as follows:
Furthermore, Microsoft has publicly stated that it is their intention that people can implement ECMA C# (which includes a lot of.NET libraries) freely.
So you do make a coy little promise of free Dotnet. But of course you had to - after all the platform would offer virtually zero portablity without the main libraries, right? Wonder if we'll ever see the day when a Mono proponent comes clean and makes a clear distinction between language and libraries.
Regarding Dotnet patents:
There is no "assumption" there, there simply are no such patents.
Really? Then you'll be updating this section of the Mono FAQ soon then:
The controversial elements are the ASP.NET, ADO.NET and Windows.Forms subsets. [...] The Mono strategy for dealing with these technologies is as follows: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless. Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono. The patents do not apply in countries where software patents are not allowed.
1) Which "Mono lawyers" and what review are you referring to? Have these findings been made public? If not, on whose authority are you asserting that Dotnet is unthreatened by patents? And which of MS's patents have they told you they regard as Dotnet related? It seems to me rather cavalier to assume that MS will not use expensively acquired patents to protect their core platform, especially as Ballmer is on record as saying that it is precisely their intention to do so.
2) No you didn't say that Dotnet was a standardized platform, you implied it by stating that C Sharp "includes a lot of.NET libraries". Be aware that Mono proponents have a lot of "previous" regarding this particular bait-and-switch manoeuvre so anyone still trying it on is likely to be quickly "apprehended".
3) I have no idea what reassurance we're supposed to find from the statement that all MS IP is "out in the open". Are you implying that it is now somehow in the public domain?
Responding to questions about the opening-up of the.NET framework, Ballmer announced that there would certainly be a "Common Language Runtime Implementation" for Unix, but then explained that this development would be limited to a subset, which was "intended only for academic use". Ballmer rejected speculations about support for free.NET implementationens such as Mono: "We have invested so many millions in.NET, we have so many patents on.NET, which we want to cultivate."
As for the lame "standards" pitch
Microsoft has publicly stated that it is their intention that people can implement ECMA C# (which includes a lot of.NET libraries) freely.
this statement has been repeated and immediately refuted so often on/. one really has to question the motives of someone still making it.
For the record, Dotnet consists of approximately 1200 APIs (classes) of which 120 were "standardized" as part of C Sharp and the CLR. Not by any stretch of the imagination can Dotnet constitute a standardized platform.
The best way to protect silly people from themselves is to have them run a secure platform.
The potential havoc that an ActiveX control can wreak is the problem of the platform, not the user.
Java, for example, has the notion of permissions for various sorts of access - file I/O, network access etc. If an application needs these rights the platform, not the application, is the appropriate agent to confer them in consultation with the user.
Mono was create to keep interoperability between operating systems, not to copy and be a 'me too'
Unlikely.
If "interoperability" (I guess you mean portability) was Mono's goal it could have easily built on Python, Java or Lisp.
But Mono isn't innovative like Python, Java or Lisp - Mono is slavish copying of Dotnet to no purpose and with no redeeming features.
If that sounds harsh, search Slashdot for the number of times the "Dotnet compatibility" claim is made and then backed down from again. Mono proponents know that this carrot will always remain out of reach, but every day is "Dotnet compatibility day" in Mono marketing land. I fully expect that these people to repeat this mantra undeveloped and unqualified until their final hour at Novell.
I think you've given an argument against both idea and implementation.
Differences of interpretation like the example you give are inevitable, also it would be impossible to catalog every example of unexpected and undesirable behavior - changing the clock, tinkering with modem settings... the list is endless.
I think that in future the early 21st century IT scene will be noted for its curious inability to deal with programs as information. Today it seems perfectly normal to have encrypted (binary) forms of programs forced on us, which then trigger the development of bandaids like the proposal above in an attempt to make their behavior slightly more visible.
I expect that distribution of programs as "source" (as ASCII or in a more structured form) to become the norm in a decade or so, the problems discussed here being the tip of an iceberg that we are currently heading towards.
How can you implement Dotnet "independent of MS influence"? MS own Dotnet.
Nice bait-and-switch from Dotnet to the published standards by the way, Miguel would be impressed. Needless to say, the chances of the community extending (never mind embracing) the bulk of Dotnet are slim.
This is a valid criticism, but only when compared with the Oracles and Microsofts of the world.
FOSS projects have roadmaps, but there's no strategy at the level of platforms or information systems in general - each project is an autonomous part of the IT elephant. This means that no one can rationalize and coordinate between projects.
Is this a problem?
It might be. Look at Dotnet vs. Linux + Java or Mono or PHP. If MS got their act together they could simplify the Dotnet world a lot, offering a consistent and complete environment for information management. Meanwhile, we'll still be dealing with such mixed bags as file permissions, database permissions, htaccess files and Java security policies since these are all separate projects with no prospect of rationalization or consolidation.
Fortunately, at least with present MS management silos, this is unlikely to happen, however the general air of complacence concerning the unstoppable march of FOSS is probably misplaced.
As an outsider it's rather touching to see claims like this being made. What might simply be seen as devil-may-care arrogance is arguably not that at all - it looks more like a genuine delusion concerning the extent to which US values are shared by others.
If by "nobody" you mean countries other than the US, Australia and Russia, then yes, "nobody" is agreeing to abide by it. Meanwhile the EU and Japan continue to have economies and not to feel too threatened by Kyoto.
The protocol has a trigger clause in it for it to come into force - countries accounting for at least 55% of 1990 carbon dioxide emissions must be signed up. Right now there are 44%, Russia being seen as the critical guy to enlist as it would be sufficient to reach the target.
Slashdot Mirror
Speaking of FUD, Dotnet is not an ECMA standard, only C# and the CLR are.
/., it will continue to be made, probably by the same group of people, and, ludicrously, even as de Icaza is preparing his exit strategy from the whole Mono raison d'etre - Dotnet compatibility.
I have no illusions that, despite having personally rebutted this assertion over 50 times on
But I thought the point was that there already were lots of apps?
Java GUIs typically try to imitate their host OS in terms of GUI
Like Micosoft Office did, I seem to remember. And in fact like Dotnet is doing - although it can reuse ActiveX controls, the core set is a rewrite.
Are the "provided libaries" the ones from MS or the ones you're proposing that we write?
Either way, I see no Big Thing yet, just a Big If.
Good question.
In 5 out of 5 big time SuSE customers I've worked with, SuSE is there to run Java applications.
But maybe you have a friend who is planning to experiment with Mono on his SuSE box sometime?
Anyway, hope that helps.
But those statements would equally justify doing an open-source JVM.
But then that project already had a leader didn't it?
Real-world software requires support for databases, security, performance, productivity, reliability...
The presence of enums would be about criterion number 10006 in a realistic evaluation of Java and. Mono platforms.
Hmmm, I don't know about the "quickly" part. A huge amount of effort has been spent getting Java on all kinds of platforms from phones to mainframes.
I think you're talking about 6 years or so to replicate this assuming Mono took off, and right now its take up in the commercial world (vendors and users) is negligable.
If the community were smart, they would take Miguel's suggestion, and start on a competitive stack
Actually this is what the community would do if they were exceptionally stupid.
There's no value in being vaguely similar - Mono has to be fully compatible to have any value over other platforms. The fact that Mono C Sharp programs look like Dotnet C Sharp programs means nothing if the code doesn't actually run - it might as well have a different bytecode, language and CLR too.
Switching from WinForms to GTK is rather more than a configuration change.
I work for a big company but it is unlikely to be able to induce a package supplier to make this kind of customization.
Retaining the API is one option, but not the only one they talk about - "removing code" is another.
If this looks like nit-picking, consider the implications for porting a Dotnet app to Mono: if 80% of API coverage is achieved instead of 100% it could easily make the port uneconomic.
This is the problem with the Mono value proposition - it drops exponentially in relation to compatibility, and you don't have to drop far until you've brought the whole cloning strategy into question, the question being whether there was a need to make Mono any closer to Dotnet than Dotnet is to Java.
OK, you've confirmed my understanding of your previous statement - Mono for you is a multiplatform environment in its own right, not a "bridge" from Dotnet that is "helping people migrate their existing knowledge and applications to Unix" as described in the Mono Roadmap. That's fine.
We can then move on to look at the merits of Mono, Java, Parrot etc. from the same standpoint. Regarding the VM, I'd be interested in your source indicating that the Mono VM is safer and more reliable than the "Java" VM. You don't mention whether it's the Sun, IBM, BEA, Kaffe or some other one that was tested - I'm sure you appreciate that such details will be important to someone seriously evaluating these platforms.
The "ECMA and ISO ideas" only cover a small part of Dotnet, the rest is proprietary.
The problem is that Mono falls between two stools: it's neither a complete Dotnet clone, meaning that users get no true Dotnet/Mono portability; nor has it confined itself to merely "adapting" ideas from Dotnet - it's similarity is a good deal closer than that.
Mono is therefore asking its users to risk infringing MS's IP without delivering the associated benefit of real portability. There's little likelihood of Mono ever being a route for getting Photoshop-sized applications from Windows to Linux, for example.
Now of course Mono itself may be multiplatform, meaning that applications are portable from one Mono environment to another, but shifting to this goal (as you appear to be doing in your last sentence) immediately negates the value of the cloning effort. If applications are only written for Mono, there's no reason to stick to MS APIs, languages or bytecode - Mono doesn't need to be any closer to Dotnet than Dotnet is to Java, meaning that the FOSS world will be "free to innovate", to borrow an expression.
You're not alone in being misled by the gap between Mono's stated goals and the reality, and indeed my impression is that leading Mono proponents see little to gain at the present time by clarifying the situation.
The Mono project is public. If you participated or at least followed it...
.NET libraries) freely.
Fortunately I have better things to do than participate in the mindless cloning of products merely to extend Microsoft's mindshare in the development community.
I take the above as confirmation that there is in fact no such legal opinion available able to offer any assurance on the patent question and that this "advice" is therefore just more arm-waving.
If you want a legal opinion, go pay for it.
I guess you offer the same advice to all prospective users of "your" platform?
What is standardized about C# is obviously ECMA C#. I neither stated nor implied anything more.
Your complete sentence is as follows:
Furthermore, Microsoft has publicly stated that it is their intention that people can implement ECMA C# (which includes a lot of
So you do make a coy little promise of free Dotnet. But of course you had to - after all the platform would offer virtually zero portablity without the main libraries, right? Wonder if we'll ever see the day when a Mono proponent comes clean and makes a clear distinction between language and libraries.
Regarding Dotnet patents:
There is no "assumption" there, there simply are no such patents.
Really? Then you'll be updating this section of the Mono FAQ soon then:
The controversial elements are the ASP.NET, ADO.NET and Windows.Forms subsets. [...] The Mono strategy for dealing with these technologies is as follows: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless. Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono. The patents do not apply in countries where software patents are not allowed.
1) Which "Mono lawyers" and what review are you referring to? Have these findings been made public? If not, on whose authority are you asserting that Dotnet is unthreatened by patents? And which of MS's patents have they told you they regard as Dotnet related? It seems to me rather cavalier to assume that MS will not use expensively acquired patents to protect their core platform, especially as Ballmer is on record as saying that it is precisely their intention to do so.
.NET libraries". Be aware that Mono proponents have a lot of "previous" regarding this particular bait-and-switch manoeuvre so anyone still trying it on is likely to be quickly "apprehended".
2) No you didn't say that Dotnet was a standardized platform, you implied it by stating that C Sharp "includes a lot of
3) I have no idea what reassurance we're supposed to find from the statement that all MS IP is "out in the open". Are you implying that it is now somehow in the public domain?
Did they ask Steve Ballmer?
Here's what he said in 2002:
As for the lame "standards" pitch
this statement has been repeated and immediately refuted so often on
For the record, Dotnet consists of approximately 1200 APIs (classes) of which 120 were "standardized" as part of C Sharp and the CLR. Not by any stretch of the imagination can Dotnet constitute a standardized platform.
.NET is not an ECMA standard.
.NET).
You are probably thinking of C# and the CLR (~120 out of the ~1200 classes in
Anyway, welcome to Mono Groundhog Day!
The best way to protect silly people from themselves is to have them run a secure platform.
The potential havoc that an ActiveX control can wreak is the problem of the platform, not the user.
Java, for example, has the notion of permissions for various sorts of access - file I/O, network access etc. If an application needs these rights the platform, not the application, is the appropriate agent to confer them in consultation with the user.
Mono was create to keep interoperability between operating systems, not to copy and be a 'me too'
Unlikely.
If "interoperability" (I guess you mean portability) was Mono's goal it could have easily built on Python, Java or Lisp.
But Mono isn't innovative like Python, Java or Lisp - Mono is slavish copying of Dotnet to no purpose and with no redeeming features.
If that sounds harsh, search Slashdot for the number of times the "Dotnet compatibility" claim is made and then backed down from again. Mono proponents know that this carrot will always remain out of reach, but every day is "Dotnet compatibility day" in Mono marketing land. I fully expect that these people to repeat this mantra undeveloped and unqualified until their final hour at Novell.
I think you've given an argument against both idea and implementation.
Differences of interpretation like the example you give are inevitable, also it would be impossible to catalog every example of unexpected and undesirable behavior - changing the clock, tinkering with modem settings... the list is endless.
I think that in future the early 21st century IT scene will be noted for its curious inability to deal with programs as information. Today it seems perfectly normal to have encrypted (binary) forms of programs forced on us, which then trigger the development of bandaids like the proposal above in an attempt to make their behavior slightly more visible.
I expect that distribution of programs as "source" (as ASCII or in a more structured form) to become the norm in a decade or so, the problems discussed here being the tip of an iceberg that we are currently heading towards.
Who'd have thought that .NET could actually lead developers away from Microsoft[?]
You and Miguel?
How can you implement Dotnet "independent of MS influence"? MS own Dotnet.
Nice bait-and-switch from Dotnet to the published standards by the way, Miguel would be impressed. Needless to say, the chances of the community extending (never mind embracing) the bulk of Dotnet are slim.
3) Lack of roadmap
This is a valid criticism, but only when compared with the Oracles and Microsofts of the world.
FOSS projects have roadmaps, but there's no strategy at the level of platforms or information systems in general - each project is an autonomous part of the IT elephant. This means that no one can rationalize and coordinate between projects.
Is this a problem?
It might be. Look at Dotnet vs. Linux + Java or Mono or PHP. If MS got their act together they could simplify the Dotnet world a lot, offering a consistent and complete environment for information management. Meanwhile, we'll still be dealing with such mixed bags as file permissions, database permissions, htaccess files and Java security policies since these are all separate projects with no prospect of rationalization or consolidation.
Fortunately, at least with present MS management silos, this is unlikely to happen, however the general air of complacence concerning the unstoppable march of FOSS is probably misplaced.
No, the US is not like other countries.
As an outsider it's rather touching to see claims like this being made. What might simply be seen as devil-may-care arrogance is arguably not that at all - it looks more like a genuine delusion concerning the extent to which US values are shared by others.
If by "nobody" you mean countries other than the US, Australia and Russia, then yes, "nobody" is agreeing to abide by it. Meanwhile the EU and Japan continue to have economies and not to feel too threatened by Kyoto.
The protocol has a trigger clause in it for it to come into force - countries accounting for at least 55% of 1990 carbon dioxide emissions must be signed up. Right now there are 44%, Russia being seen as the critical guy to enlist as it would be sufficient to reach the target.