Slashdot Mirror
Mono-culture And The .NETwork Effect
Sun Tzu writes "This article discusses the dangers posed by a very successful Mono project. Microsoft has several means at their disposal to effectively shut down Mono if it should ever gain critical mass. Unfortunately, Linux would be the big loser if that were to happen."
Unlike the UNIX braintrust, Microsoft makes sure their products are a moving target to prevent people from copying them.
By the time Mono has finally reverse-engineered NET 1.1, Microsoft will be releasing NET 2.0. They'll keep adding to the APIs, they'll hook into Windows, leave parts undocumented, whatever it takes to ensure that nothing comes close. Mono will be stuck running trivial or toy programs.
This is just like the Wine project -- for years people have been promising that you'll just be able to install Wine and fire up any Windows app. But there's always another and another and another API that Wine hasn't gotten around to yet.
Man, the dude writing that stuff is sure one paranoid fellow. A paranoid fellow with little or no vision. No offense, but the guy is drowning in a quite empty glass of water.
.NET APIs while they remain open, and will continue to use open protocols whenever possible (for example, our System.DirectoryServices implementation talks LDAP).
.NET APIs we have been actively implementing our own framework that maps into the Unix world.
.NET binaries.
Lets take the following premise:
`Mono succeeds, and Microsoft then changes the APIs so Mono can not catch up, hence Linux looses'.
Lets take a sample that is closer to us: Linux and Unix. Linux and GNU are implementations of a fairly popular and interesting technology: the Unix operating system.
Now, if the Unix creators introduced a new API, or changed a Unix API when Linux was successful, did that change the success of Linux?
For example, lets assume that tomorrow SCO introduces a new API call into SCO Unix, lets call it "hasuseraclue()" [1]. The system call is highly proprietary and undocumented. Now, will Linux and GNU users suffer from the lack of this API? I am going to leave that as an exercise to the reader.
[1] Note: by reverse engineering the code, we know that above system call return 0 when ran on the system of the author of the previous paper.
In a world where Mono is vastly successful, if Microsoft changes/introduce new APIs, do you think it will matter?
We will continue to implement the
But Mono has not stopped at implementing the
For example, Microsoft has chosen XML Schema for representing, mhm, XML schemas. But the world of XML has been leaning towards Relax NG. Well, we implement Relax NG.
We implement Mozilla bindings, OpenGL bindings, Gtk+ bindings, Qt bindings, Unix bindings.
They implement support for 3 databases, we implement support for 11 databases.
Mono ships with plenty of other libraries, like a BigNum library and APIs to manipulate
miguel.
The only thing is that office is a huge code base, my guess is that it will never be converted. I remember reading somewhere (possible Joel on Software, not sure) that the Excel team still maintains their own C compiler to compile Excel. It would therefore make it an even bigger task than a simple port.
.net installed to use them. Maybe I wrong on that but I don't see .net being a prereq on any of their products.
Also as far as I am aware Microsoft has so far released no products that require
Go out and get sailing!
From the Joel on Software story, it seems the C compiler for the Excel team dates back to the 80's. And this news releases states that Microsoft Business Solutions CRM "is the first Microsoft business application built on .NET infrastructure."
You seem to be confused between specification and implementation. It doesn't make sense to claim that Java isn't Open Source, since there are various Open Source and Free Software implementations of Java compilers, runtimes and libraries in addition to the proprietary ones. Here is a good list. Some of these Free implementations have been around much longer than Mono. Mono isn't the only Free implementation of DotNet; there's also DotGNU.
Not given the number of times this has already been discussed on /. I suppose.
My impression (from a far from neutral viewpoint) is that each time it comes up the discussion has progressively become less "that's a neat thing to do" and more "sounds risky, a bit unimaginative, and isn't it ultimately pointless?"
Probably the hardest thing to gauge is the risk from MS - we'll carry on debating this until, and probably after, the C&D orders hit the doormat.
The "unimaginative" and "pointless" accusations are easier to get a handle on. Once it's conceded that portability of an application from Windows to Linux is unlikely to be fully realized (at least, not without an equally comprehensive yet-to-appear WINE layer), then the bottom-line value of Mono is immediately suspect. If I can't actually port my source code, what's it to me whether Mono uses the same bytecode format or not?
As has been mentioned before, DotGNU is perhaps more worthy of support since it has tied itself less completely to MS's apron strings - Java bytecode is supported in principle if not in practice, for example. However, the Python and Parrot efforts are perhaps the projects closest to the goals of OSS that are capable of delivering the same benefits as Java and Dotnet.
Lastly, it should be kept in mind that Java on Linux is huge, probably the biggest factor driving Linux in the enterprise - IBM, BEA and Sun all have high quality JVMs for Linux. If it were possible to compare investments. The investment going into Mono is infinitesimal in comparison.
The mono developers (in particulap Miguel) have had enough meetings with Microsoft not to be too worried here. In addition, some of the patent issues fall apart since Microsoft has failed to defend it.
Although not all of mono is protected by the EMCA standard, the core is. Furthermore, since the implementations used in mono have (well, at least should) be independent from the
Lastly, the
After doing some research, they are very close:
FY2003
Client (Windows) $10,394
Server Platforms (SQL, Backoffice, etc) 7,140
Information Worker (Office) 9,229
Source: Microsoft.com