There are corners of the Internest where foolish people congregate, and invent stories. These foolish stories are then read as gospel by trusting people, and reposted, until the original made-up source is concealed from view. As an attempt to stem this flow of disinformation, here are some commonly held – but incorrect – beliefs about the Mono framework, and an explanation of the reality of the situation, as far as I understand it.

The next Mono version is co-developed with Microsoft

There is a grain of truth behind this one, but it’s a gross mischaracterisation. Mono 2.8, when it ships, will bundle, for convenience, a number of Free Software libraries, which are released by Microsoft under a license considered Free Software by the Free Software Foundation, the Ms-PL. These are:

System.Web.Mvc and System.Web.Mvc2: ASP.NET MVC, a library for writing ASP.NET web pages with a model-view-controller design, similar to Rails for Ruby. This is not news – System.Web.Mvc has been bundled in Mono since ﻿Mono 2.4.2 (June 25th 2009). System.Web.Mvc2 has been bundled in Mono since ﻿Mono 2.6.7 (July 14th 2010).

System.Numerics: Mono re-uses Microsoft’s implementation of BigInteger.cs from the Dynamic Language Runtime (see below). This is indeed new to Mono 2.8, as it is part of .NET 4.0 (Mono 2.8 targets .NET 4.0 compatibility by default).

﻿﻿System.Data.Services.Client: The OData SDK client library. This is indeed new to Mono 2.8.

System.ComponentModel.Composition: The Managed Extensibility Framework, a library for writing and using plugins. This is similar in scope to the existing Mono.Addins project. This is indeed new to Mono 2.8, although it was added to Mono Trunk in 2009.

System.Web.Extensions: Microsoft Ajax, a library for using Ajax inside ASP.NET projects. This is not news – MicrosoftAjaxLibrary has been bundled in Mono since Mono 1.2.6 (11th December 2007).

Microsoft.Scripting.Core and Microsoft.Dynamic: The Dynamic Language Runtime is a framework permitting implementation of dynamic languages (such as Python or Ruby) on top of the core .NET runtime. It is used for IronPython and IronRuby, amongst others. The DLR has very recently changed license from Ms-PL to Apache 2.0, but the version bundled in Mono is still under the older license. This is not news – the DLR has been bundled in Mono since Mono 2.6 (14th December 2009).

So, to summarise, there are five Free Software libraries written by Microsoft under the Ms-PL included in Mono 2.8 – but only two of those five are new, and none of them were “co-developed” in any meaningful sense.

Mono development is dead

There have been reports that Mono development has ended, on the basis that no commits have been made to Novell’s Subversion server for a few weeks. However, these reports miss one minor detail – Mono has moved to Github.com. There were 35 commits from 9 different people to the main mono.git repository (of dozens of repositories under the main Mono project) in the last 2 days, at time of writing – far from dead.

Mono lacks features found in Microsoft.NET

Mono lacks libraries found in Microsoft.NET, such as the Windows Presentation Framework GUI toolkit. In terms of features, i.e. things implemented at a compiler or runtime level, Mono is typically more advanced. This is helped in no small part by Mono’s Free Software development model, allowing experimentation and “what if” changes to the core runtime which a sluggish corporate behemoth like Microsoft cannot accommodate.

To give three real-world examples, Mono allows embedding of its compiler as a service, and provides a REPL shell – this is a planned feature for .NET 5.0, but has been available for years in Mono; Mono.Simd provides a number of data structures which will run on any version of Mono or Microsoft.NET, but will use optimized CPU extensions like SSE when run on a sufficiently new version of Mono, on an appropriate architecture – as far as I’m aware, there is nothing like this available or planned for Microsoft.NET. Mono is able to produce fully compiled, static executables which do not need to JIT anything at runtime – this is used for iPhone compilation, for example, where JITters are not permitted. There is no comparable feature in Microsoft.NET.

Clearly, Microsoft.NET can only be thought of as more featureful if one defines “features” in terms of “does it have lots of libraries?” – in terms of functionality, Mono is ahead.

Mono can “sneak onto” your system without your knowledge

If you don’t have the “mono-runtime” package installed, you can’t run Mono apps. It is possible to install some Mono apps alongside the awful-yet-popular “mononono” equivs package, since the popular equivs script fails to place Conflicts on the correct packages (F-Spot will be blocked, Tomboy will not). No package in Debian or Ubuntu embeds its own copy of the Mono runtime, and we have no plans to make any changes to packaging which would allow execution of any C# application without mono-runtime installed. If one is using a different OS, then things may be different – e.g. The Sims 3 for Mac & PC uses embedded Mono, which you wouldn’t know about without looking.

Canonical are pursuing a pro-Mono agenda, and are responsible for it being “pushed” in Debian

Mono development has been happening in Debian for longer than Canonical has existed – the first upload was made in April 2002. Ubuntu is made primarily from software already available in Debian deemed of sufficient quality, and when F-Spot and Tomboy became parts of the default Ubuntu desktop system in 2006, both pieces of software were already available in Debian and deemed of sufficient quality. Nobody working on Mono in Debian is paid by Canonical… actually, that’s not entirely true, three packages related to accessibility are officially maintained by someone who was hired by Canonical after doing the initial packaging work when he worked for Novell. But the Mono runtime itself, Canonical have no influence over its direction in Debian. As for a “pro-Mono agenda”, they’ve always taken an extremely pragmatic approach to language choice, never showing any real preference for one language or another when it comes to app selection. They don’t exhibit any overt anti-Mono policies, which is not the same thing. The names of people contributing to Mono in Debian are not secret – check the pkg-mono team page on Alioth.

The System.Windows.Forms namespace is protected by Microsoft patents

The truth is, nobody knows for sure if SWF, or any other part of Mono, or any other framework such as Vala or Python, is covered by Microsoft patents. The way the US patent system is contrived, it is actively dangerous to check whether something contains any patents when you write it, as you are liable for triple damages should it later emerge that there WAS a patent, even if your searching missed the fact. You cannot patent an API or namespace – only a specific implementation of a software concept, in those countries where software patents are permitted. There has never been any evidence shown that Mono’s implementation of SWF, or indeed any part of Mono, infringes any Microsoft-held patents, because if that were the case, then the code would be rewritten to avoid the issue – much like the approach taken by Linux kernel developers when a patent becomes apparent.

The belief within the Mono community is that the core parts of Mono as defined in ECMA334/335 are safe (they are covered by the Microsoft Community Promise patent grant); any of the Ms-PL libraries mentioned above is definitely safe (Ms-PL includes an explicit patent grant); and the rest of the package is likely safe too (on the basis that it is a named component of the Open Innovation Network’s list of protected software – and on the basis that there’s unlikely to be anything patentable in one of many implementations of basic ideas like database connectors). Nobody knows for sure, because that’s how the system works. But, again, nobody knows for sure that Microsoft patents don’t apply to other frameworks such as Python – there is simply a belief and an assumption that they do not.

MonoDevelop contributors removed GPL code from MonoDevelop, in an attack on the GPL

This is somewhat disingenuous, given MonoDevelop is LGPL.

The MonoDevelop team excised the remaining GPL code (and there wasn’t much of it) in order to grant greater Freedom to developers. Previously, the entire MonoDevelop IDE was a GPL combination, meaning any add-ins for the IDE also needed to be GPL, regardless of developer choice. Now, any developer can write an add-in for MonoDevelop, using the license of their choice, whether another Free license like the Mozilla Public License, or a proprietary closed-source add-in. They are still welcome to produce GPL add-ins, if they want to, as well.

Actually, this one is often true. When developers write apps for Windows primarily, they rarely take the time to think “is this the correct way to do it?” and will often plough on with an assumption about the Windows way of doing things. It might be simple things like filesystem assumptions (assuming a case-insensitive filesystem, or assuming a backslash is used to separate directories, not a forward slash). It might be more involved, such as using P/Invokes into Windows-specific C libraries, when a more cross-platform alternative is possible. So, often, random applications for Microsoft.NET won’t run on Mono. The reverse is also true – F-Spot or GNOME Do are fairly heavily tied to Linux (or to UNIX-like OSes with X11, at any rate), through the libraries they invoke being fairly platform-specific. You can write platform-specific Java, with one quick piece of JNI, too.

It should be noted, however, that Mono makes the chance of .NET applications being ported to Linux (and/or Mac) much more likely, since even in the worst case scenario, a company only needs to fix a portion of their source to make it cross-platform. The Mono team have a tool called MoMA, which will scan an application and its libraries, and give you detailed reports on the app’s portability. This info is used at both ends – by app vendors who want to become more portable, and by the Mono team who want to fill in the most frequently encountered blanks.

And, it should be stressed, writing cross-platform apps is entirely possible if one desires it – e.g. the IRC client Smuxi is pure cross-platform C#, and the executables compiled on Mono on Linux will run fine on Microsoft.NET on Windows. Portability in this direction is important too – consider how many people have been introduced to Free Software thanks to availability of Free apps on Windows like OpenOffice.org, Firefox, Pidgin or GIMP. You can download Tomboy for Windows, and work is ongoing on fixing Banshee portability issues (which are mostly caused by gStreamer).

Mono on Android is a terrible idea which will be super slow

There are two efforts to enable developers to write Android applications with Mono – a paid proprietary product from Novell called MonoDroid, and an untitled porting effort by big-name Android hacker Koushik Dutta. I have no insight into MonoDroid since it hasn’t been released yet, but Koush did some benchmarks of his work which exhibited some remarkable figures compared to Dalvik (and even compared to Sun Java for ARM). Those numbers haven’t been updated to reflect the Froyo Dalvik JITter, but Mono on Android is still very exciting from a performance perspective.

Mono isn’t really Free Software

The source code is all available under Free Software licenses. So, um, yes it is.

We don’t need Mono because we have $LANG

By the same logic, we don’t need $LANG because we have Mono. By all means, use the language of your choice – other developers will use the language of their choice too. If you want to use Vala or Python or Java, then by all means, go ahead. It doesn’t mean there’s no room for more languages, better suited to other usage patterns. Haskell is great for some types of development, so is Fortran, and so is C#.

You might not need Mono because of $LANG, but there are others in the world with different needs.

Mono apps are all slow, and crash your computer, and stuff

No userland app can crash your Linux system, unless there’s a bug in the kernel, or you have some severe problems with your hardware. If you’ve ever observed a crash as a result of running a Mono app, then it’s really coincidence that Mono is tickling whichever part of your system is busted. As for slow… startup time may well be slower than for apps written in C or Vala. There’s a delay due to the JITter needing to compile all the libraries used by the application (we may AOT the most common libraries in a future Mono package version, at upstream’s recommendation). Once an app is running, it should be fast compared to a Python app, and memory-light compared to a Java app. The new garbage collector in Mono 2.8 should also offer significant improvements to performance, especially under heavy workloads.

Ubuntu’s default GTK+ themes require Mono

This is my favourite recent nonsense to emerge from the Internest. There are reports – mostly restricted to IRC and blog comments, that (paraphrasing here) “removing Mono removes the Ubuntu themes”. Here’s the reality: in Ubuntu 10.04, a new visual style was implemented throughout the distro. As part of this, small icons (e.g. notification area icons) were set to be black-and-white by default, and colourised when attention is needed (e.g. the power-off icon turns red when a reboot is needed, the messaging indicator turns green when there’s a new message). All of these new monochrome icons are in a package named “ubuntu-mono”. Removing the ubuntu-mono icon package will also remove the new Ubuntu GTK+ themes, in the “light-themes” package. So there’s your explanation: the themes have a dependence on some monochrome icons, not on the Mono framework.

“a license considered Free Software by the Free Software Foundation, the Ms-PL.”

Well, that is true, but stops short. The FSF also says it is a weak Free license and that it is not compatible with the GPL. They urge people not to use it. If this is targeting Linux and other systems that favor Free Software (using FSF’s definition of Free Software), incompatibility with the GPL is kind of a huge thing to over look (http://www.gnu.org/licenses/license-list.html)

“The truth is, nobody knows for sure if SWF, or any other part of Mono, … is covered by Microsoft patents.”

This is mostly true, but even the true part misses a significant point. MS originated this technology that Mono duplicates. MS has made statements that the own patents on C#, .Net, CLR and related technologies for which they are the original developers. We might not know what patents there are, but Microsoft would. They could enumerate those patents and make it clear that they intend the licenses for these patents to be compatible even with the GPL if they wanted to. They chose not to do any of this. Others have made clear patent pledges. Microsoft could if they wanted to.

MS is not the originate of UNIX, which the Linux kernel duplicates. It is true that there is some concern about patents in any peice of software. But in the case of Mono, we know it orignated with Microsoft and that they are very likely to have patents on it. (Even bad ones.) Microsoft has stated (repeatedly) that they intend to use patents against Linux and that they would do it by hiding them in standards. Microsoft’s vague language about their patent pledges are consistent with those previous statements. (Someone could probably ask for link for this, but if so they aren’t paying attention and simply want to believe Microsoft is playing nice. I’m not looking up the Halloween documents, the threats to Asian government officials and many statements in the press for anyone who is that unobservant.)

“…core parts of Mono as defined in ECMA334/335 are safe (they are covered by the Microsoft Community Promise patent grant…” I could say the Microsoft Community Promise patent grant is not safe, but I’ll Let the Software Freedom Law Center do it.

In the end I’ll say I believe Mono should be developed as a migration crutch, but it should never be used for the development of new Free Software so long as the problems such as GPL incompatibility and the patent pledge exist. At that point is might become just another development environment with the usual holy-war issues and regular patent ambiguities. Right now it looks like a weapon and it is incompatible with the single most popular Open Source software license on the web. (http://www.dwheeler.com/essays/gpl-compatible.html)

@Eddward, there are lots of important Free licenses which the FSF recommend you don’t use because they’re GPL incompatible. CDDL, CPL, EPL, MPL and the OpenSSL license, are widely used, and undeniably Free.

@studentz, erm, those are licenses not technologies. And you’re saying that IBM and Oracle licenses don’t have powerful, monopolistic companies behind them?

Eddward Reply:September 18th, 2010 at 6:27 pm

@directhex, It’s not just that Microsoft is a monopoly. It’s that they have been actively working to undermine Open Source and Linux in particular. I had mentioned that already. I would say trust IBM blindly and I would be cautious when dealing with Oracle these days, but neither have earned the level of mistrust that Microsoft has.

Regarding your previous point, using a non-GPL compatible license in an Open Source application is foolish since it could cut you off from a huge amount of code reuse. Likewise doing it in a library is a great way to make sure the code gets reimplemented. Putting a GPL-incompatible license on the base libraries of a new programming environment like Mono is either a stupid or strategic way to turn away the largest population of Open Source community.

Rafael Teixeira Reply:September 18th, 2010 at 9:58 pm

@Eddward, Well there’s a sizable group of open source developers, which include me, that prefer to stay away from over-restrictive licenses like GPL. For me, Mono’s option for using simpler and less-restrictive licenses is a plus, and one more reason I like to hack on it and use it on my own open source projects.
I don’t know how many devs do really prefer GPL over other FOSS licenses, but I have the right to have a different opinion and still contribute to the shared pool of free and open source software.

@Eddward, your lack of discerning is appaling. You can’t just tag one company evil, and another one perfect. You say you trust IBM, while they are specialists at locking consumers into costly and proprietary technologies and sitting on open standards. There is only one thing you should trust: the code. Whoever it comes from, free code is free code.

As for non-GPL-compatible licenses, Microsoft are not the first ones to do that. Apache did the same and their software is doing fine, thank you. The FSF is doing that too with the GFDL, and to a lesser extent with the GPLv3. Furthermore the affected modules are clearly not “base libraries”.

Eddward Reply:September 19th, 2010 at 1:50 am

@Np237, Ouch! I meant to say “I would say don’t trust IBM blindly…”. What a gaff. You are right to call me on it. I’m surprised noone else did.

We shouldn’t trust IBM, Sun, Oracle or any company like that blindly. Their directions can change with their leadership, the stock market or any other number of things. (see Oracle) My bad. It was a typo. Honestly.

That said IBM has been playing along with the Open Source community. So have several other proprietary companies to varying degrees. Watch them for sure, but I still say they have not earned the level of distrust from the Open Source Community that Microsoft has.

About non-GPL licenses, there are several I find to be good. Being GPL incompatible is undesirable to me. I think it is the safest and most sustainable of the open source licenses. It actively discourages unnecessary forks and it helps to prevent the balkanization that pretty much destroyed UNIX.

As far as those modules list above not being base libraries, they ship with the runtime. Are they not actually necessary? I don’t want to the legal ambiguity attached to them on my systems. Especially since Microsoft is not attempting to dispel that ambiguity. They could if they wanted to.

>>I would say trust IBM blindly and I would be cautious when dealing with Oracle these days, but neither have earned the level of mistrust that Microsoft has.

I’m sorry but are you insane?? How can you trust Oracle over MS who is now actively engaged in litigious patent war over generic patents they’ve acquired with their purchase of Sun and Java. Where not even having a GPL version of Java is safe from their patents surrounding it. Its one thing to have defensive patents, its another to actively litigate on them.

Microsoft have only made patent *threats* in the past. The C#/CLR (aka .NET Framework) was an open standard from the start. In more recent times they’ve made an open community promise (http://www.microsoft.com/interop/cp/default.mspx) not to sue on implementations of their specifications. Not to mention they’re donating a large portion of their new .NET technology under an OSS licence which allows it to be used in MONO.

How anyone can think the Java/JVM is a legally safer platform than C#/CLR today is beyond me.

For the uneducated, it is probably worth you adding to the post a few points not explicitly mentioned such as that:
a) Mono can be installed on Windows if you want the exact same framework on Windows/Linux/Mac (regarding cross platform application compatibility).
b) Gtk# has been implemented on Windows.

So when discussing running Microsoft.NET apps cross platform, also point out the alternatives such as targetting Gtk# (instead of Windows Forms or Silverlight/Moonlight) and running on Windows and also just installing MONO itself on Windows, etc.

There is another important myth that needs to be busted: that Canonical is “aware” of problems involving Mono due to an interview that Matt Zimmerman gave a while ago.

Regardless of what Matt said in the interview, it reflects his own thoughts and not an official Canonical stance. The official Canonical stance on the issue has been published in the Ubuntu Forums a long time ago.

@Np237, it seems to be popular amongst certain sectors of the academic community, as it approaches problems in a similar way to how they learnt maths. I’d personally like them to stop using it (and we recently spoke with a group using FORTRAN 4 code in production), but I’m not going to begrudge them their choice.

@directhex, the historical reason for using Fortran is performance, which comes from it being a very simplistic language. Apart from that, it completely sucks if you intend to write anything that does more than arithemetics. Starting from Fortran 90, you lose the performance advantage since they introduced pointers, and over time the specification became even more complex than that of C++.

@Np237,
I know it’s a rather late answer, but Fortran is still actively used in research in physics and astrophysics.
Some researchers today write their number-crunching programs from scratch in Fortran. And it’s not only that the oldest academics do it. It generally has an excellent performance for computational physics when compared to other languages, and it’s an excellent tool for large scale simulations in clusters.

@directhex,
Well, Fortran has several advantages over C for numerical computations, and Matlab is not so fast nor convenient for large scale/parallel computation. (And licensing is expensive!)
Anyway, my point is that the statement “Fortran is not useful for ANY kind of development” is simply false.

As normal.
“Windows Presentation Framework GUI toolkit.” What most visual studio written graphical .net applications use. So missing major feature weakness. Lacks Libraries critical to compatibility,
“in terms of functionality, Mono is ahead.” Again functionality how measured. If measured in numbers of working applications on Linux Mono is behind. Does not matter how much functionality Mono has other than can what the user want to happen be done. Currently Mono is failing.

“Mono can “sneak onto” your system without your knowledge” That is a distribution issue altering default packages when upgrading without asking users. Something that should not be going on with anything. Also package bundling leading to installing like evolution and end up with mono being installed as well. Not like mono-runtime is small.

“ECMA334/335 are safe (they are covered by the Microsoft Community Promise patent grant);” Is mono exact to ECMA334/335 or does mono diverge to be MS.net compatible or to add own features. The important bit any diverge means you did not implement ECMA334/335 so the patent protection truly does not apply.

This is the big problem with the Microsoft Community Promise. With java I have a test suite that if implementation passes is legally fine. With .net no such thing exists. So one coding error annoying lawyer could argue that it was not ECMA334/335 so all patents protected by the community promise could be used against mono.

Legally the promise alone is not worth the paper it written on. You need a way to prove you are ECMA334/335 to the best of you ability so you were in your rights to believe you were patented covered. While that is lacking mono is legally a sitting duck. Maintaining a map of what is legally safe either by Microsoft staff providing code or by passing tests.

Java is still legally ahead of .Net. At least you can find everything in java you need to be legally sure of coverage. Test suite provided by the patent holder to prove standard conformance is the best. Ie it was there test suite with the error so you cannot have you patent grant revoked.

Yes currently mono is still in a location where is patent grant could be pulled out from under it.

@oiaohm
I think that FUDding is not the way that things go forward. FYI Mono goes implementing ECMA 334/335 initially and as a second priority they will go to be 100% compatible with .NET. They don’t tend to be in spirit and in fact a .Net clone.
Also please do not take some things and add doubt without having any specifics. Go to Google Patents, search all patents that are licensed by Microsoft, and after this go and look in Mono’s implementation. After this please point in mailing list or whatever you want. If not, you do not have any argument.
The features vs library talk is a part that is really important. Microsoft creates .NET with a full package, and have resources in selling the final package, meaning the IDE, the SQL Server, WPF tooling, Silverlight and so on, when Mono is an Free/OSS solution for a runtime. WPF is a big piece of software, and there is no problem per se that is not imlemented in Mono. In fact the WPF usage as the norm in .Net software is not always as you state on. I can agree that most new applications use WPF, but all applications created before VS 2008, almost all applications that need integration with C++ Win32GDI code, and such, will mostly require Windows.Forms. Also you discount the Silverlight applications that more or less are running on Moonlight, the ASP.NET applications and so on, which do not rely on any WPF/SWF libraries.
At the end: Java is ahead or not on .NET. Probably it is. The problem that Java do not solve, is not the hotspot compiler, that it can run distributed JBoss instances eating half of gigabyte of RAM, is that as contributions goes in F/OSS software, there are almost no desktop applications that people can use them (I know Vuze, do you know and use another!?). About legality, is FUD. No one in this talk bring FUD that Sun, then Oracle attacked a different implementation of Java by Microsoft or Google. Probably you should close your computer, as your CPU is covered by patent, and also your graphical card, and if you use your A4Tech keyboard, some layouts of keys were also patented.
At least if you will live in your box, being sad of what injustice Mono creates to Linux, you will lose some applications that you may need and have a good implementation. But is better to use a broken but in your mind politically correct application.

@Ciprian Mustiata, I can tell you, I will not search for patents as that could be dangerous. The FUD was created by Microsoft making threats against Open Source regarding patents for years combined with vague claims of patents in .NET. If Microsoft wants to clear any FUD, they alone have the power to do it. They chose not to.

It’s better in my mind to avoid something that is meant to create a cloud of FUD over Linux. Linux doesn’t need Mono to begin with. Allowing it to become a major dependency of a Linux system given it’s ambiguous legal state is irresponsible.

@Eddward, you can build your own Linux system without Mono if you want. Just let people who build Linux systems build it the way they want. If we are at legal risk with Mono, it is our problem, not yours. We thought about it a lot, and we think we are safe. So you can disagree, and build your own distribution without Mono, but stop telling people what they should do.

If there is one thing that is dangerous to Linux, it is not only FUD, but your SDD: Scare, Disrupt and Destroy tactics. You are scaring people away from good free software by assuming the Microsoft patent claims are correct. Suppose we removed Mono from our distributions, you would find another thing that is not “pure” enough. And yet another one. And remove anything but GNU Hello.

Read my comment correctly. I do provide a solution that does not take patent searches. Validation framework.

“Mono goes implementing ECMA 334/335 initially and as a second priority they will go to be 100% compatible with .NET. They don’t tend to be in spirit and in fact a .Net clone.”

Its how you address this that is critical. Does not take much digging to find where MS .net does not follow ECMA 334/335 documentation in its implementation. There is no existing ECMA 334/335 test-suite to confirm conformance. This means mono is walking on quick sand. Now ideal is MS write the test suite then it cannot be disputed. If that is not possible mono should write the test suite and run it against MS .Net and Publicly print where it don’t follow and go after documented extensions to the ECMA 334/335 promise.

Sliverlight usage is almost non existent so not really worth talking about. But notice you expanded the area of weakness. So old .net applications for windows don’t work nice.

And yet, having a test suite is not a requirement to get the CP. The only requirement is to be a complete implementation or a super set, and Mono qualifies as both.

How do we know? Well, for one, because we run Silverlight, which is a strict superset.

Before you split hairs again, I will preemptively state that we have receive the Microsoft test suites for conformance for Silverlight and Mono passes them.

oiaohm Reply:September 19th, 2010 at 11:11 am

Miguel error as normal. Does the Silverlight test suites state they are for testing ECMA 334/335 conformance. Answer no. Count of law your Silverlight tests are worthless for knowing if you have ECMA 334 and 335 coverage or not.

Other thing about the Silverlight tests do they state clearly that they only stick to MCP covered implementation? Not extend outside to third party patents. Yes legal annoying questions but you could have taken poisoned cup and been drinking from it.

The test suites is about protecting our legal ass’s Miguel. That if mono ever gets challenged before a count test suites can be presented as evidence that you attempted to conform to the best of our ability. So should be given time to correct any issue without restraining orders and the like.

“And yet, having a test suite is not a requirement to get the CP. ” Ok how do you prove it to a count of law without test suites that you conform as per the requirements of the MCP. Answer you don’t so you have no evidence that you have any right to be using the MCP due to failing at the first clause. If you don’t have the test-suites you can be held in injunction until they are written.

Basically unless you can prove Conformance as per Spec Sheets you don’t have MCP coverage. It is foolish to think you have MCP coverage if you don’t have the items to back it up. Google class mistake in progress with java but this is Novell with .Net.

Test suites as well as making sure Mono is quality work. So you should be seeking a testsuite exactly covering ever MCP granted part individually.

See next down the Microsoft Community Promise wording does not automatically grant on a super set automatically due to it wording.

By law unless the Spec document states you can extend you cannot to be Conforming. Due to the fact MCP used the word Conforms. You must follow the spec sheet to Conform. If you extend and it does not say you can extend you now have a non Conforming implementation so are not covered by MCP.

Anything past the approved specs is not protected by the MCP and due to the word Conforms being used in the MCP unless the spec sheet some where clearly states that Super setting is allowed the ECMA 334/335 and other specification parts provided under MCP should be independent parts. Ie in this part is this spec implementation. So mono could installed perfectly matching what is MCP protected and legal.

“The only requirement is to be a complete implementation or a super set, and Mono qualifies as both.” So please point me to the document that grants this. It must hidden away in the spec sheets somewhere, Its not the MCP. Microsoft was very careful writing the MCP to prevent supersetting and subsetting past particular points.

Thinking Microsoft has used super-setting to destroy competition they wanted to make sure it could not be done to them.

I hope its not a case of miss reading conforms and thinking you are legally fine.

MS Java case MS tried to say they conformed to Java and added extensions. Same trap wording in the Java agreements back then. After that SUN cleared up the wording. So yes MS knows the legal meaning of conforms because they there bank balance hit by it once.

@directhex: “The new garbage collector in Mono 2.8 should also offer significant improvements to performance, especially under heavy workloads.”

Yes. However, it should be noted that the new GC won’t be enabled by default before Mono 3.0, as it’s not quite ready yet. But at least, it can easily be used by passing a command line parameter, no need to recompile anything anymore.

@David Taylor: “Mono can be installed on Windows if you want the exact same framework on Windows/Linux/Mac (regarding cross platform application compatibility).”

However, there are a couple of important differences between OSes. For example, on Windows, Mono uses the Windows GDI+ library rather than libgdiplus (the Mono-made library used on Linux and Mac). Meaning you can’t test libgdiplus from Windows, as you’re stuck with the same GDI+ lib that the .NET framework uses. Also, another random example: WinForms sucks on OSX.
So you can’t just assume an app works fine on other OSes just because it works on one. Just clearing that up, as “exact same framework” can be misleading.

Winforms looks native on Windows and you can create some very amazing applications with it, for example, SharpDevelop.

Mono’s WinForms on Linux and MacOS is not as good as it could have been, but in general there was a lack of interest compared to other components like ASP.NET and the use of Mono with native toolkits like Gtk#.

A faster, smoother Winforms is possible, Chris Toshok had a design for a new update/rendering system that would have pushed it forward, but we never implemented.

The other general problem is that Winforms apps tend to hardcode object locations with pixels (or units if you are luck) and that translated very poorly to OSX and Linux. Although new controls were added in 2.0 to alleviate this problem, most developers never switched their code over.

@Miguel, I think WinForms support has been neglected a bit too much (but at least, I’m glad it’s not discontinued).

I can understand it’s not really motivating to work on the WinForms implementation for several reasons (being convinced we already have superior GUI toolkits, the fact MS hasn’t clearly stated that reimplementing WinForms was fine, and also the fact even MS has moved away from WinForms…).
On top of this, the Mono team wasted time rebuilding their WinForms implementation from scratch twice. I can only imagine how much mature it’d be right now if the right approach had been taken from the start.

I think having a rock-solid WinForms implementation (and while we’re dreaming, a designer too!) would probably attract more .NET developers, especially professional ones.

This makes me think about something… 2 weeks ago, I went to a job interview, and one of the guys noticed I had put “Mono” on my CV, and mentioned that his team keeps making jokes about Mono. :p
If people mix the maturity of Mono as a whole, with the maturity of its WinForms implementation, then that doesn’t put Mono under a good light.

Instead of giving 1 dollar to each feature and spreading ourselves too thin, we have decided to focus on a couple of areas and make those areas shine. Spreading ourselves too thin merely means that we will get “all features” but 10 times slower.

This is why you do not see us at Novell working on entity framework, wpf, workflow and doing so minimal maintenance on winforms.

If these are technologies that the community cares enough about, they will step up, as for example Codice Software has for Winforms.

But my 10 dollars are fixed, there is very little I can do other than slowing everything down to accelerate and improve Windows.Forms.

WPF is not that popular. Silverlight is – but that is implemented by mono (moonlight). People are choosing to use silverlight for their applications, portability being one of those reasons. Anyone who plans to write portable apps will take that into account before starting to write them.

As for the patent. Mono implements ECMA334/335 entirely and is safe there. The patent agreement has no restrictions on adding new features to the runtime, only removing them in such a way that mono would no longer implement the entire spec. There are good reasons to keep it that way even if it would be desirable to remove features – because modifying it would break the portability we aim for. If there was a problem with the implementation that didn’t conform to the standard, that could quite quickly be resolved anyhow – it wouldn’t affect developers or end users.

@sparkie, and, something oiaohm purposefully ignores, is that Oracle’s patent grants for Java forbid adding any new functionality to the core library – the MCP does not forbid adding new functions to ECMA334/335.

sparkie and directhex you need to visit lawyer. MCP may not forbid it but it does not grant adding extra functionality to the core libraries either.

Legally you don’t have to forbid things. If you have not been granted the rights todo particular things you are on quicksand. Oracle openly has stated the way it has to be ie. No alterations to core libs. So we know exactly where we stand. Where is Microsoft statement saying alteration to core libs is permitted. And that alteration of core libs will still be classed implementing standard.

ECMA334/335 standard can be updated yes then the MCP would apply.

“Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation, to the extent it conforms to one of the Covered Specifications, and is compliant with all of the required parts of the mandatory provisions of that specification (“Covered Implementation”), subject to the following:

This is a personal promise directly from Microsoft to you, and you acknowledge as a condition of benefiting from it that no Microsoft rights are received from suppliers, distributors, or otherwise in connection with this promise. If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you. To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement the required portions (which also include the required elements of optional portions) of the Covered Specification that are described in detail and not those merely referenced in the Covered Specification.

This promise by Microsoft is not an assurance that either (i) any of Microsoft’s issued patent claims covers a Covered Implementation or are enforceable, or (ii) a Covered Implementation would not infringe patents or other intellectual property rights of any third party. No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppel, or otherwise. ”

Find me the words that you have the right to extend please I don’t read them in the promise. Copy is provided of the MCP. Key word is conforms. Prove the implementation does not conform for any reason and the complete grant is void. Extending can be grounds for classing as something as not conforming to a standard.

So yes extend to your own risk thank you. And the extends is what makes mono legally stuffed.

Why we have to develop in Mono if there is a plethora of platforms in the Linux world?

You don’t “have to” do anything. Some developers choose to use a different platform to you, and choose Mono. Bear in mind Mono has been around since 2002 or so – it’s hardly fair to say it’s unnecessary due to existing platforms, when most people argue in favour of far younger choices like Vala.

Does the web need .net or iss?

I can’t comment on IIS, as I’ve never used it. I don’t really think Windows is a serious platform for web hosting. As for .NET, it needs .NET as much as it needs any other development framework, i.e. “yes if it helps developers make good things”.

Why do we have to replicate efforts and create DIVISION among the communities?

Let me be the first to say that it’s not what this guy is saying. At least, that’s not how I understand it. The quote is “If you can’t compete, you are declaring open. This masks incompetence.”. Even though I don’t agree with it, what you and the article you link to are making of it, is the reverse, and that’s a lie.

Also, given how their recent display of attitude change towards open source projects and open source development, I think it’s fair to say that their stance is not what the media, based on ones misinterpreted quote, makes of it.

I find it almost funny that people still regard Microsoft as the big enemy. In case you haven’t noticed it yet, Microsoft has lost most of its significance, influence and power in the last ten years. Microsoft is not an innovative force, it’s just playing catch-up and “me too”. Nobody in his right mind is afraid of them anymore. Today’s big players and technological leaders are Apple, Google and, since they bought Sun and their IP, Oracle – and each of them is more dangerous to your individual freedom than Microsoft ever was.

Whoever is or was afraid of Mono and its potential patent risks should more be afraid of having a Java implementation on his system. Oracle has recently sued Google for the violation of Java patents although Java was open sourced by Sun quite a while ago. So in reality, an open source license won’t protect you if a patent owner has an own agenda. Patents are more powerful weapons than licenses, and they cover CONCEPTS, not specific implementations or products.

Unlike Microsoft, Oracle and Apple have always been very aggressive about their patents and IP and sued the crap out of everybody that came to close to their turf. Really, if you want to worry, worry about them.

@Winfried Maus, I do worry about Oracle and Apple. But Java implementations are safe as long as they implement the java spec without supersetting or subsetting. If you do that, then you’re covered by a specific patent grant from Sun (Oracle). Google didn’t do that, though: android doesn’t have some things from the spec (subsetting), and includes things that aren’t in the spec (supersetting).

It doesn’t apply to Perl and Python themselves. It applies to systems that provide the .NET API to multiple languages (including Perl and Python). In other words, it’s about the combination of the CLR (which allows for language interoperation) and the .NET API.

It’s hard to read claim 12 (the only place where the words “perl” or “python” show up) because the claim is so long, but if you cut out the big long list, it looks like this:

========
A method implemented at least in part by a computer, for exposing resources using an application program interface, the method comprising:

exposing a first group of services related to creating Web applications, the first group of services comprising:

[big long list]

wherein, the different program languages are selected from a plurality of programming languages, the plurality of programming languages comprising:
Visual Basic;
C++;
C#;
COBOL;
Jscript;
Perl;
Eiffel; and
Python.
========

@kangamono, yes, the MCP covers the contents of ecma 334 and 335. If you only implement those standards, then you’re covered by the MCP. However, those ecma standards don’t include the entire .NET standard library; there are some parts, like windows forms, that aren’t mentioned in the ecma standards. And some of those elements, which fall outside of ecma, are mentioned in the patent I linked to. So an implementation that tries to compatibly implement the entire .NET API will infringe on the patent, and it won’t be covered by the MCP.

@Mitch, you are quoting the web services component of the patent. This and another dozen patents put Microsoft in control of anything that is exposed as an API over the web, REST, SOAP or anything similar to it.

Speaking of which, did you know that building client-side menus with Ajax is one of the patents that Microsoft owns? It came up recently on the Microsoft vs Sales Force lawsuit. It was one of those patents that they bought from Silicon Graphics before it went bust.

This puts pretty much every open source CMS using jQuery or any other fancy library for menus under jeopardy. Perhaps you would like to troll those groups and demand that WordPress, SugarCRM and all those others remove those features.

Oh, and while you are advocating the removal of features that Microsoft has patents on, you might want to approach Fedora and Ubuntu and tell them that they need to rip out the software update stack, because guess who has a patent on software updates? That’s right. Microsoft does.

So show us how concerned you are about patents and post links to your demands that Redhat, Ubuntu and every other Linux distro using software updates removes the feature because they infringe on 5,845,077

“Why we have to develop in Mono if there is a plethora of platforms in the Linux world?

Does the web need .net or iss?

Why do we have to replicate efforts and create DIVISION among the communities?”

So without Mono there wouldn’t be a division among the communities? Are you kidding? There are already three languages for the P in LAMP, and just look at how divided those three communities alone are.

Then look at the tons of competing frameworks for Java that all serve the very same purpose. Then do the same for the “P” in LAMP and be surprised that somebody thought this wasn’t enough and invented… Ruby on Rails.

This “division of communities” is also known as DIVERSITY, and although it brings chaos to the platform and cluttering of resources, it also is what makes this platform so attractive. You CAN do what YOU want with it. Mono just gives you another choice. There’s NOTHING wrong with it. Actually, it’s GREAT to have this additional choice.

“Mono is able to produce fully compiled, static executables which do not need to JIT anything at runtime – this is used for iPhone compilation, for example, where JITters are not permitted. There is no comparable feature in Microsoft.NET”

That is what I call an advantage…

But where is this functionality for Windows/MacOS/Linux?

If it was true that one could compile to a regular .exe file Mono apps would be thriving.

Dear directhex, I believe no effort from your side will convince the “foolish” people talking about open-ass (yeah, that’s the right description for those) of software projects, most of them without actually contributing to one.
So, please, don’t waste your time. The people who use mono, or will use in the near future (MonoDroid, I’m waiting for you), are well aware of its strengths and awesomeness. They don’t need any more encouragement and their number is only growing, I think.

Lets take this in 3 steps
Step 1: The problem for me with Mono is it relies on the benevolence of Microsoft with regards to Linux. All we have to do is look at Microsfts track record concerning Linux. At time they want to kill it, at times they just apply a heavy layer of FUD. At times they just remain silent to allow a specter to remain in the air.

Step 2: Microsoft wants to promote silverlight. Yet they have done no real work on Mono or Moonlight. If they wanted a real silverlight client on linux they could do it themselves or partner with others. Still 4 years later and no real silverlight on Linux. There lackluster performance in this regard does not inspire confidence in Microsoft desire to see anything succeed on a Linux platform

Step 3: What is the point of Mono? If it is having a CLR in linux and having C# or VisualBasic as a language tied to GKT, then that is cool, we are likley in the clear as far as patants go. On the other hand, if compatibility with Windows or being able to easily port software between platforms, then things like WinForms are a real issue. With a name like WinForms do you really belive that Microsoft does not have it pattented from one end to the other? Mono steps on to much Microsoft software that is not covered by any sort of patent protection to make it a good idea for Linux usage as a language that can run on Linux and Windows.

Step 2: Microsoft has contributed controls and test suites for Moonlight. From what I’ve read, Moonlight is the part of Mono that MS has helped the most with.

This is kind of funny… As directhex pointed out, some people have been spreading FUD about MS co-developing Mono. On the other hand, other people are unhappy about the fact MS doesn’t help enough. Whether MS helps or not, it’ll be seen as a bad thing. :p

Step 3: Mono has more than one goal. Miguel and others already explains that times and times again. tl;dr: first, having a nice development environment on Linux (and then other OSes). Second, being compatible with .NET.

If Microsoft was serious about Moonlight, then Netflix would have been able to stream videos in Linux two years ago.

If you drop compatibility with .NET then MONO would just be a C# compiler for linux with GTK bindings. This would be cool. Because that portion is an EMCA standard. It is everything that lives out of the standard that MONO tries to duplicate that is a big hazy question mark.

It is not only patents that are a risk. The risk is that any time they feel like it, M$ releases new code that they choose not to be free. Lot of new software uses this code. Where does this leave you, poor developer? Do you want to invest vast amounts of your time to develop something that M$ could pull the rug out from under at any time?

[…] Jo Shields (aka directhex) has posted some great information and the truth about some mono myths which appears on the internet. For all mono critics and mono users/lovers out there read the blog post: Mono mythbusting, September 2010 edition […]

“Clearly, Microsoft.NET can only be thought of as more featureful if one defines “features” in terms of “does it have lots of libraries?” – in terms of functionality, Mono is ahead.”

Why *wouldn’t* you define it that way? If one didn’t care about libraries, plenty of other languages are far, far ahead of where .NET or Mono is, e.g., your REPL is neat but I can name a dozen languages with REPLs back in the 20th century. Libraries are the only reason I’m using this platform at all.

“The MonoDevelop team excised the remaining GPL code (and there wasn’t much of it) in order to grant greater Freedom to developers”

And allow developers to restrict freedom (why do you capitalize it?) for users. That’s always the tradeoff. Since I’m a user of far more software than I’m a developer of, I think this is unfortunate. I guess if I was a full-time Mono developer I’d lean the other way.

“By the same logic, we don’t need $LANG because we have Mono. By all means, use the language of your choice – other developers will use the language of their choice too.”

This is kind of funnysad. Do you really think that people use a programming language because they looked at the available options and found it to be the best choice for their situation? In 100% of projects I’ve ever worked on, the language in use was chosen by somebody years before I joined, who later regretted the choice — including the one using C#.

Language choice is exactly as political as license choice. If costs of switching language were zero, there would be much less need for a .NET workalike.

This admittedly has nothing to do with Mono or C#, but it’s kind of hilarious that people keep saying things like this. If there’s a kernel that *doesn’t* have a bug, let me know which one it is so I can switch to that! Linux is up to 2.6.38.5 and so there were at least 5 bugs which were found *and* fixed in just the past 2 weeks since 2.6.38!

If you assume that it’s possible to make a crash-proof kernel, then it sounds like it would also be possible to make a crash-proof language platform, so why does Mono ever crash itself? Where’s bug-free Mono? 🙂