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.
http://www.cgisecurity.net/development/dot-net.sh
http://www.cgisecurity.net/development/xml.shtml
http://www.cgisecurity.net/development/java.shtml
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.
Yes and no. I thought we should recognize FUD by now.
.NET standards. Changing, as if Microsoft would want old software to stop working (maybe they want this, but it would stall adoption of .NET). DMCA only applies to encrypted data and mechanisms (something won't work). And did Patents stopped any other software development? It only makes developing harder.
Take this for example: the author warns: please, don't use MONO, don't develop MONO. Where does this takes us? It's the same as asking us not to develop an office package, please. Or do not develop a PageMaker clone, please.
And what's the threat? Because of Patents, DMCA and Microsoft changing
You all should have more faith in Free Software developers. Trey are very aware of these old tricks.
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
http://www.go-mono.org/faq.html#patents
.NET Framework is divided in two parts: the ECMA/ISO covered technologies and the other technologies developed on top of it like ADO.NET, ASP.NET and Windows.Forms.
.NET Framework, and what has been patented by Microsoft falls under the ECMA/ISO submission. Jim Miller at Microsoft has made a statement on the patents covering ISO/ECMA, (he is one of the inventors listed in the patent): here.
Question 135: Could patents be used to completely disable Mono (either submarine patents filed now, or changes made by Microsoft specifically to create patent problems)?
First some background information.
The
Mono implements the ECMA/ISO covered parts, as well as being a project that aims to implement the higher level blocks like ASP.NET, ADO.NET and Windows.Forms.
The Mono project has gone beyond both of those components and has developed and integrated third party class libraries, the most important being: Debugging APIs, integration with the Gnome platform (Accessibility, Pango rendering, Gdk/Gtk, Glade, GnomeUI), Mozilla, OpenGL, extensive database support (Microsoft only supports a couple of providers out of the box, while Mono has support for 11 different providers), our POSIX integration libraries and finally the embedded API (used to add scripting to applications and host the CLI, or for example as an embedded runtime in Apache).
The core of the
Basically a grant is given to anyone who want to implement those components for free and for any purpose.
The controversial elements are the ASP.NET, ADO.NET and Windows.Forms subsets. Those are convenient for people who need full compatibility with the Windows platform, but are not required for the open source Mono platform, nor integration with today's Mono's rich support of Linux.
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.
For Linux server and desktop development, we only need the ECMA components, and things that we have developed (like Gtk#) or Apache integration.