Log in

No account? Create an account

Previous Entry | Next Entry

Mono/GTK# in GNOME

So, I spent two hours reading every email sent in April, May and July about including Mono as an official part of the GNOME platform and Tomboy as an official application of the Desktop. You might be thinking, Two hours is a lot of time to waste on this, but this argument is really, I think, one battle in the much larger war over whether JIT languages can be general use languages. Further, there are a lot of side issues which are complicating this.

Now, first, let me summarize - as objectively as I can - the two sides of the Mono argument. I have some experience in both camps. As the gnome-games maintainer, I oversee the maintenance of lots of C applications (and one Scheme); some of them very hard to maintain. On the other hand, I have written several commercial GUI apps. in GTK# using both Glade# and Stetic.

  • Pro-Mono people are arguing:
    • Lots of cool applications and innovations are happening in the Mono camp. There's apps. like F-Spot, Tomboy, Beagle, and Banshee being written way faster than they could be in C. Anti-Mono folks generally agree but think that high level languages should only be used for prototyping (the benefits of RAD don't outweigh the cons).
    • ISV's and corporate environments will benefit from the Monodevelop tool and the general availability of more RAD tools on the GNOME platform. Anti-Mono folks generally agree but argue that being able to install these separately isn't a barrier to their use for this purpose.
    • Mono needs the GNOME endorsement of official inclusion to heal the community divisions over it. If we don't include Mono, the community will split further. Anti-Mono folks argue that - even if Mono is included - distributors like Mameo and RHEL are going to pick-and-choose the parts of GNOME that fit their requirements (official inclusion really doesn't mean much in the way of platform endorsement).
    • Python is there, so why not Mono? Anti-Mono folks argue that - in some ways (Deskbar) - including Python was a mistake.
  • Anti-Mono people are arguing:
    • Mono applications will use, generally, at least twice as much memory as an equivalent C application. In some cases more because of the overhead of the VM. If such an application were part of the panel, for instance, that would be a huge drain on memory and start-up times. Pro-Mono folks agree about the memory figure but argue that the pros outweigh the cons. Pro-Mono folks disagree about start-up times and also argue that users will have to choose to enable those panel applets. Also, deep in the thread Miguel pointed out that Mono apps. can be compiled "AOT" which would allow them to share the "overhead" in the same sense that shared libraries work in C. (I should also note that some Anti-Mono folks seems to have had bad experiences with Beagle running away with their RAM - especially on older systems.)
    • C#/Mono is a Microsoft invention and therefore it might be used as a weapon against GNOME. Pro-Mono folks point out that this has already been argued against many years ago and that the argument is closed.
    • Mono is just like Java and, despite Java existing for a decade, no compelling desktop applications exist that run on Java. This shows that JIT platforms are generally too slow. Pro-Mono folks point out that the freeness of Java has been a factor but, despite this, GCJ/Classpath is progressing and some counter examples are Eclipse and Azureus.
    • There is a general effort to decrease GNOME's footprint and including Mono would continue to undermine that effort. Pro-Mono folks argue that optimizations are good all around and that, again, the pros of rapid development outweigh the costs. Also, Pro-Mono folks point to Evolution as an example of a C program that is clearly a memory hog.

SO, what is my opinion? Well, probably no one cares and I have to say that I don't know which side to take, right now. Both sides are making some compelling points.

What IS clear is that neither side seems to be arguing with very good real-world examples to back up their performance claims. For instance, no one mentioned the widely praised (with grains of salt) Shootout benchmarks of which all the languages in this discussion are included. Also, Anti-Mono folks keep saying or implying that, before Mono, C was the only language in GNOME. I would like to remind them that gnome-games, long included by default on every Linux distribution, depends on Scheme (the guile bindings).

Also, I think that the pink elephant in the room here is not Microsoft; it's Java, for a few reasons:

  • there are forces (Sun) in GNOME which would suffer at the promotion of Mono
  • Java's general failure as a desktop platform over the past decade has left a lot of bad-taste-in-mouth about JIT, in general,
  • and Sun is quickly wising up to their failures with regard to to The Linux Desktop and Java and Mono will soon be competitors in the same usage space - what will happen when Java programmers demand that Java be added as an official binding?

If Pro-Mono people want Mono included I think that - to win the argument - they need find a way to show people that Mono is not Java, that Mono can overcome any performance/memory issues raised (such as through the use of AOT) and finally, that including Mono in the platform will be a win for the GNOME community's solidarity. Whether those three things can be done, I don't know.

What about a compromise? Mono/GTK# gets included as a binding but never any GTK# applications in the Desktop? Or, what about vuntz's suggestion: GNOME stop the practice of endorsing desktop apps. A, B, C, etc. all together?


( 1 comment — Leave a comment )
Jul. 17th, 2006 07:42 am (UTC)
Release Sets
Sorry to be pedantic, but some of the terminology here could lead to confusion about what's being discussed at this point. It's about whether GNOME Desktop applications may be implemented with Mono/C#/Gtk#. This is the Desktop release set (you are the maintainer of one of its modules):

> including Mono as an official part of the GNOME platform

This has not been proposed. This is the GNOME Platform release set:

> what will happen when Java programmers demand that Java be added as an official binding

Java is an official binding already. This is the Platform Bindings release set:

Separately, here is also discussion about whether Gtk# should be in the Platform Bindings. The objection to that so far have been only about minor tarball/packaging issues.
( 1 comment — Leave a comment )


color, uphair, smile
Jason D. Clinton

Latest Month

September 2011


Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow