I'm Fed Up With Mono

This seems to nail it for me: http://www2.apebox.org/wordpress/rants/124/

I used to be "anti-mono", then became just vary of it, but right now I just don't see a good reason to be against it and in fact deem it silly of people to ask a project which they haven't developed to act as they please, which is exactly what anti-mono people are doing.

A project including mono by default is simply in no way equivalent to "forcing mono down your throat". I can't begin to express just how utterly ridiculous such a belief is. First of all it is YOUR choice to use Ubuntu (or any distro which includes mono) which by itself precludes all chance of anything being FORCED down your throat. Second of all, you are actually offered the ability to remove it and go on your marry way, which is exactly the opposite of being forced. It's choice.

As for the purported "patent clouds" after all these YEARS of screaming about mono I think it is the FOSS crowd which takes the prize of trumpeting the *anti-Linux FUD* more than anybody else. They've pretty much took the few blurts by few MS execs or employees and made ALL of the publicity and fear mongering for them.

Which can only have an exactly the opposite result of what their goal is (people switching to a Free OS).

In truth, as TC points out, end users are unlikely to be affected (which is probably 90% of all desktop Linux users) and if the worst case scenario that anti-mono people so love to talk about, there are multiple levels of defense plus an option of working around it which is unique to FOSS. I mean, even if anti-mono crowd is right about everything as far as the threat goes it's not anywhere near as dangerous as they want to portray it.

So in fact, they're their worst enemy, not Microsoft, by far.

Quoting: I would be interested in hearing you expand on this. Writing a library in one language and running it from another has been common practice for many years, at least since John Ousterhout started promoting Tcl and scripting languages. The purpose of scripting languages was originally to act as "glue" between functions written in low-level languages. Thus, I'm not following what you're saying.

So you are saying that I can invoke a python class, for example, from a C++ program? Sure one can embed a python interpreter and marshal data across, but that is way different from being able to invoke an API i.e. being able to access class and other structures seamlessly.

Since .NET produces a fairly powerful IL, it allows different languages to be used to do the same and exchange class/structures/generics etc. For example, one developer can write a class in python on .NET (using IronPython) making use of all .NET libraries, another can make use of that class from C# just like any other native C# class, and a third can make use of java on .NET (J# or ikvm), and someone else can use C++/CLI to do the same. Thus, in theory, a project can have developers comfortable in different languages using their language of choice with the .NET framework working on their modules, while other developers can make use of those modules (without any data copying or anything else of the sort) just like native .NET libraries (a misleading term but hopefully gets the point across).

As an example, the following in C#:

public class Foo { public int m;

public void doMe() { ... } }

can be compiled into a .NET dll and then made use from C++/CLI as below:

ref class Bar { private: Foo^ m_foo;

public: void doMe() { Console::WriteLine("Foo member is: " + m_foo->m); m_foo->doMe(); } ... };

Same for any other languages that can work on top of .NET like java, python etc. See this http://www.mono-project.com/Languages for languages supported by mono.

edit: Probably a better example would be as below.

C++/CLI: public interface class ITest { public: void doMe(); };

C#: class Test : ITest { void doMe() { ... } }

I've been on the fence with Mono since it's inception. What troubles me is the continuous handwaving about the favorable RAND licensing that is supposedly in place. What conditions does MS attach to the ECMA specifications? If these licensing stipulations exist, why doesn't the Mono team put them on the Mono website? It would clarify the issue and no one would be uncertain what to do about Mono.

On the other hand, does it really matter? Samba exists, Wine exists, ReactOS exists. Even vfat still exists. MS has tried a lot to get at FOSS. The SCO saga, the FUD campaigns, they even dropped a little patent bomb. So far they didn't get anywhere.

SCO made Linux stronger and put it on the map. MS' FUD only angered a lot of people and the Halloween documents really hurt their reputation. The little patent bomb so far was a disaster to MS. The OIN immediately went to DEFCON 1, the minute TomTom joined them. MS hastily withdrew their case under settlement. TomTom will remove vfat support, which IMO is a win, but OIN is still looking into the validity of the MS FAT patents. Vfat maybe freed afterall.

So what can MS realistically do, except rattle the patent sabre? It won't dare attack the big guns outright and the smaller outfits might sign murky "we-won't-sue-your-customers" agreements, not worth the paper they are printed on, but MS won't risk a full head on attack. They are too late, FOSS now has an arsenal of patents of it's own and will use it to bring MAD.

I think Mono isn't more dangerous than other projects that skirt the patent boundaries. The problem with Mono is the politics around it. The way the talking Mono heads handle the concerns of the community leave a bad taste in our mouths. The big question here, is shunning Mono because the politics stink, an effective way to handle it? Technologically, it's just another rapid development VM framework. We could just use it to our benefit.

If MS loses it and pushes the red button in the future, we could always port the Mono apps (if they're worth it) to other languages. That this is possible was demonstrated with Gnote. Meanwhile, if we accept the uncertainties around Mono, we could use Mono to draw some developers from the MS camp. We all know GNU/Linux needs that exposure and MS fears this the most, because they run the risk of losing their "Developers, developers, developers, developers!"

Not including it by default won't help deflect trouble, if trouble will ever materialize. Hosting it in your repo's already makes you liable for patent infringement.

First of all, I don't code, so I don't have much rights to complain or give my opinion I guess. Anyway, apart from the patent debate; there's an other consideration:

Quoting:We all know GNU/Linux needs that exposure and MS fears this the most, because they run the risk of losing their "Developers, developers, developers, developers!"

They won't loose many developers as Windows will always have the best .NET support as first OS - so therefore developers who are locked-in to .NET help the Windows lock-in. That's Microsofts intention, and its view on the matter. That's also the reason they're want to bring Silverlight to the iPhone and Android: It will help the Windows-lockin.

I don't know if they're right, but it sounds considered. If there's no good alternative to .NET - as krisum pointed out (dotGNU not ready I guess?) - then there's not much choice except for adding to the stronghold of the Windows platform. The same goes for Silverlight, apart from Flash there's not much of an alternative. TracyAnne already pointed out why developers would want to use SilverLight and that there's no good alternative except from Flash; which isn't much of an alternative at all.

My fear is this: If the whole internet uses the newest version of Silverlight (the one Moonlight doesn't support yet) and all kinds of apps are made in the newest version of .NET (the one Mono doesn't support yet), where does this leave alternatives to Windows such as Linux and BSD? Those are not a viable alternative if they don't run Silverlight-websites and don't run .NET apps. Last week I already saw some MS-fanboys (I give them the benefit of the doubt) claiming Linux isn't an alternative to Windows because it doesn't run .NET software - in which companies 'invested billions'.

So, both Silverlight and .NET are efforts to coerce* people to use Windows. Maybe failed attempts, but attempts anyway. Now I don't have problems with coercion by default, but I do have problems with the internet and applications coercing me to use Windows.

* Sorry to bring up that word; however regular readers will know why I did

Quoting:As they did with Javascript, they just did not follow the standards and their browsers seemed to always work differently.

Then the community will solve this. jQuery offers complete, cross platform Javascript to everyone, including buggy old IE6. It also includes full CSS3 selector support. I am pretty sure that if MS does not offer HTML5/CSS3 then someone else will make a plugin to compensate.

Quoting:c.f. their recent adoption of the ODF file format in their Office Suite.

I spent the last two days at the ODF Plugfest in The Hague in the Netherlands. Microsoft was there, as well as Oracle, IBM, KOffice, AbiWord and a multitude of other vendors (http://plugtest.opendocsociety.org/doku.php). ODF 1.1 support in MS-Office 2007 isn't quite as buggy as is made out to be. For example, we across an interesting issue where it turned out that MS was right and every other vendor was wrong[*]. Reality can be stranger than fiction :-)

Not saying that MSO2007 has such great ODF support though. There are plenty of other issues left. Rob Weir pointer out some other issues that are valid (like cell references) in his blog articles and the non-support of formulas is a bit of a cop-out IMHO. We'll see what further interop testing will bring. Microsoft committed to fixing the bugs that were found, so that's a good start.

[*] For the technically inclined, the issue was with certain references to charts. The ODF spec says they need to end in a trailing slash. MSO writes these documents with the trailing slash but none of the vendors could handle that. They all expected the reference without the trailing slash because that's how OOo does it (and it's wrong). MSO does load the document correctly if it is missing the trailing slash. "Be liberal in what you accept and strict in what you write". The other vendors are fixing this issue so it should go away.