I think you’ve made a good point! I found those apps (the ones you mentioned, and some others, rather slow), but more importantly, your suggestion that “alternatives” shouldn’t die; more variety almost always produces more innovative, usable and efficient applications (in my opinion).

But: the Mono software currently promoted (i.e. F-Spot and Banshee) is bad compared to existing software. Don’t forget this! F-Spot is crashing and Banshee is unbearable slow with a real world music archive. Gnome-Do is quite good (but the Avant window navigator is too).

What I what to say is: don’t let the alternatives die and Distro should watch for the performance of their shipped default software. Not everybody gots a DualCore 3+ GHz machine and not everybody wants to!

A couple of months ago, when I heard rumours about a possible replacement for Rhythmbox, I decided to give Banshee a try. I must admit that at first I liked it, the way it was thought, its features, its polished GUI, the development promises behind it, etc. It had anything I actually wanted, and didn’t crash at all. But so did RB, anyway. However, in the meantime I also had the time to try other applications, like F-Spot, Tomboy. After more than one month I had become accustomed to it all. Then I bumped into a couple of exchanges which introduced me to this “MONO/anti-MONO war”. Nostalgically, today I decided to play some music in my good old RB: as soon as I hit the play button, the song started at once. Isn’t it silly that such a trivial fact surprised me at all? This brought me back to last year, and to the reason why I decided to ditch Windows: Linux did exactly what I told it to do, while Windows was whimsical and had me wait for it to complete whatever it was secretly doing in the background. Now, when I found extraordinary the fact that I told RB to play music and it did it instantaneously, I realised that Banshee took all the time it wanted to do the same – sometimes up to 6-7 seconds. And the same was when scrolling albums, opening menus, searching for songs (especially – while RB takes less than 1 sec!), and everything else – starting and quitting included. RB is as fast as light, which is really what I expect from my music player – and my OS as a whole. I don’t want my OS that tells me to wait, and makes me do what it wants: those were Window$ times. Now I uninstalled Banshee, F-Spot and Tomboy, and got back to use RB and Gnote (I didn’t really use a photo manager before, I only wanted to try one out, so I won’t miss it). And now I have my Ubuntu back: light apps, quick response, extraordinary performance. Here is the point, from a simple user: I must have a computer that does what I want, when it begins to be the other way around either something is wrong, or there must be Bill somewhere around (or both – watch out =)!). And I can swear that if Ubuntu is going to give me that distorted low-performance experience I will ditch it the very same day. No doubts about it!

In a distribution which is trying to reach the 10-secs boot-time goal I don’t think such delays are exactly what Canonical is expecting, and what its end-users would find acceptable. This is why, in my humble view, MONO will not find ample space in Ubuntu in the future. Conversely, it will not find me around anymore =), but that’s not as important… or is it?

Microsoft issues patent promise, dispels Mono legal concerns

Microsoft has announced that it will apply the Community Promise to ECMA standards 334 and 335, the specifications that describe the C# programming language and .NET Common Language Infrastructure. This means that Microsoft is providing a legally binding guarantee that it will not enforce its patents against Mono and other third-party implementations of the standards.

from http://arstechnica.com/microso.....ncerns.ars

1) Are ECMA standards allowed to be patent encumbered? Yes.

2) Are there patents covering the C# standard? Yes.

3) Can you get a license to cover those patents? Several people have tried and been unable to.

4) Can you safely use the standard without a patent license? Not in my opinion, but check with your lawyer.

5) Is C# really superior? No. It’s just another programming language.

So why all the excitement about Mono? It’s a poor man’s imitation (limited functionality), of a failed programming system (better uptake than Quick Pascal, but that’s not saying much), designed by a failed software company (read their SEC filings before you reply).

And that’s what has me suspicious of Mono. It doesn’t seem to offer any compelling features, so why are people pushing it so hard? The only answer I’ve been able to come up with is that there are ulterior motives behind the push for Mono, and I don’t trust ulterior motives. Unless they are mine.

I know this is off topic, but check this out, looks like Linux is the first to support USB 3.0? I caught this tweeted URL in my twitter stream: http://www.linuxdevices.com/ne.....35015.html

I am not sure what point you are really trying to make however. None of that seems to have any relevance to shipping Mono in Ubuntu, which was the original discussion.

The fact that it was implemented in way B from Microsofts A really doesn’t mean much as the design is there. What is to gather here?

MySpace was evaluating Mono w/ Linux for a year and a half. You know what happened to that effort? It was dropped as soon as MS dropped their prices. Just like that.

One last thing I forgot to say. I did mention before that its *harder* to leak memory in C#, not impossible… I don’t know why you think I said it was a cure all. I certainly did not sell it as such, however I will bet dollars to donuts a 101 C programmer leaks more memory than a 101 C# programmer. (maybe 201’s are needed to really get out of the stack?)

And to clear up something before, this does not on its own make C# a better language by any stretch of the imagination. I think the programmers and the community largely will determine the success of a language and the actual merits tend to take a second place.

Thats why I said I am not a lawyer =) Are you? However I think you are right, the best approach to these patent issues is to really find out whats going on and not just panic and guess.

I would like to stop here and note that everything I address from this point forward is *not* a reason to remove mono from the Ubuntu CD. Applications are developed in it and they work well. We don’t remove them because we don’t have a preference for the technology they are built on.

Vala:
As for the technical end of things, I feel more qualified to talk on this a bit. Vala is not a compelling thing to talk about right now, in many regards its still 2 or 3 years out from being ready, its API is constantly changing and source written for Vala 0.6 will not work with 0.7. This makes it unusable for large scale development or at least a major hassle. Mono is here and ready now for use.

Vala is also missing the following features:
- LINQ
- True closures (it has slightly leaky ones)
- A solid, well thought out framework underneath it (yes I know there is GObject, but it doesn’t compare to .NET)
- A large development community (currently its fairly small)

Vala is currently not very compelling, but in the future this may change. Also the fact that it compiles down to C and then to machine code will always make it a little awkward don’t you think?

10 MB of Memory (VM Memory):
As for the 10 megs of extra use. 10 megs of extra use for all running mono apps. I am not going to even pretend this is a big deal, it’s a complete non-event. This is not being targeted at a kernel module. Mono is by and large used by desktop applications, 10MB is a small price to pay.

JIT Memory:
I will look more into the JIT executable code going into swap, you may have a valid point here. I never said mono was perfect, but from a technical standpoint I can tell you it works well for me and my team. Thats all it really has to come down to. If you don’t like it, nobody is making you use it =)

Memory Leaks:
Of course they can leak, anonymous delegates are the biggest offender of all here. Garbage collection is not a cure all and a novice programmer can leak a storm of memory. However the advanced guys are well aware of these cases and the best part is, there are really only a couple of cases. For the most part it all comes back down to unhooking your event handlers, 90% of leaks in mono I have seen come from this one error. Train a programmer to do that and you fix most of their leaks.

Is C# Better?:
I did not mean to say it’s a better language over all, I don’t think I did. I do believe its a better language for building desktop applications due to its rapid development time. Observe, Banshee, GNOME Do, and Tomboy are relative newcomers to the game, yet are often considered the best app for the area.

Is C# really better though? Who cares… thats not at all the point. The point is some fine apps are written in it, it would be really nice to get those apps out to users. I don’t care if they are written in Chef (fun language) so long as they work well, do their job, and present the best user experience possible.

EMCA rules also have some problems. If a EMCA standard is covered by patents the creator of standard knows about creator does not have to tell anyone until they spring it on the users. Even the ISO standard MP3 has patents with the same conditions as EMCA.

Locating the so called patent statement from MS and others over .net would be help. Then doing audit on what is and what is not covered. So suspect sections of .net can be moved to branch just like other codecs where legal status is in question.

Personally I don’t like mono on technical grounds. Mono internal design really does not suit interfacing with gobject so requires fairly large wrappers. Vala + a bytecode engine could be the true correct path to get what .net people promise without the major overheads.

Memory management feature alone is not enough to justify mono. Vala also provides a memory management along with many other solutions.

10 megs of extra used memory is 10 megs of extra used memory. Linux kernel if you do get to a OOMKiller point does not care what caused the 1 block too many.

Major difference is type of memory. JIT in mono uses memory for executable code that must go into swap. Compared to native program executable code where the executable code can be freed and reloaded at a latter point. You want the least amount possible that is JIT due to how kernel memory management works.

Besides C# programs can leak memory in different forms to C. Its not a magical cure all. Its call chained objects. So even that a object really never be used again it stays allocated because it linked to a object somewhere that is still in use.

Common defense they use is redirect. See over here leaks more memory so we don’t have to worry. Sorry you are selling your language as better than C or C++. It god darn better be by good amount.