Re: Mono/GTK#/Tomboy

[Alvaro Lopez Ortega <alvaro 0x50 org>]

Miguel de Icaza wrote:

>>>> And while there were almost no objections to Python, there are
>>>> clearly many objections to Mono.
>>>
>>> What objections? So far, the only two objections I've heard are:
>>
>> Obviously, there are many.
>
> Please enumerate all the objections.

  We have been discussing the objections all these days, I thought you
  were reading. Anyway, here you have a few quotes from the thread
  (without any special order):


1 - Microsoft:
=========
> The answer is known: It is that enormous elephant standing in the
> corner that folks have been politely tip-toeing around, trying to
> ignore. The Mono project ultimately advances the interests of
> Microsoft, a company that is no friend to the open source
> movement. I question whether it is prudent for GNOME to be
> complicit.
=========

=========
> And you are ignoring the objections to relying on a techology that
> is controlled by Microsoft, who:
>
>  - want to destroy us, and have left open legal ways to do this.
>  - have a history of being technically incompetent, .
>  - have a history of ruining anything that their non-incompetent
>    people created, yet we must chase compatibility with them.
>
> Not many people are bothering to repeat these problems in this
> thread, because they are rather obvious and they shouldn't have
> to. I don't understand why it is necessary for some people to
> pretend that they are not real concerns.
>
> I am at least glad that we have at least have a consensus that Mono
> will never be used in the GNOME Platform, but as the Desktop becomes
> more integrated, it will still be difficult to remove parts of it if
> necessary.
=========


2 - Additional framework:
=========
> GTK# is not just a language binding - it's pulling in a whole
> platform in itself - Mono. And it worries me that this is opening a
> door for a slew of C# based applications into the core GNOME.
=========

=========
> I don't believe that you've adressed the memory problems, though
> these are not specific to Mono. We maybe can handle one highlevel
> runtime, but 2 highlevel runtimes seems to be getting silly.
=========


3 - GNOME is the only framework/desktop which could depend on another
    few additional frameworks:
=========
> Think of another desktop, choose the one you want.. let's say KDE:
> it's one framework, one desktop and innovative applications.  So,
> yeah, rather than something strange, it's the usual business for
> everybody else.
=========


4 - Resources:
=========
> Just think about what happens when a user logs into a desktop that
> has Python and C# based applets included with C based applets:
>
> - The panel starts
>  - It starts C/Bonobo based applets - the smallest of which already
>    consumes approx 40Mb of memory.
>  - It starts Python applets - each of these takes up approx 70Mb of
>    memory - and very little of this is shared
>  - It starts a C# based applet - and this pulls in Mono, which I'm
>    sure isn't that small, but I guess at least it does share memory
>    better than Python, but there is still quite a lot of additional
>    memory pulled in.
=========

=========
> A good start would be: let's take an old (but still existing)
> platform, like a pIII with 128 or 256 Mb RAM, and have a basic
> desktop running fine on it.

[..]

> As said elsewhere, temporary apps (like a menu editor) don't matter
> but long-running ones (mailer, panel, applets, filemanager) should
> have a deterministic, capped memory usage.
=========

=========
> Does it make sense to you to use have three or four different DOM
> parsers in memory at the same time? (libxml2, python, mono and java
> for example). In fact, if it was only that, it wouldn't be that bad;
> the problem is that there are many other pieces that are also
> overlapping with the GNOME framework
=========

=========
> Also, Tomboy is an applet, intended to replace the commonly-used
> sticky notes applet, so it's likely to take up memory all the
> time. (I haven't had a response to my notes->tomboy transistion
> questions [1] but that's a non-mono issue.)
>
> deskbar-applet has the same problem, of course. When we approved
> python I don't think we necessarily approved this particular
> use. That was a separate thing.
=========


5 - Managed / Interpreted code
=========
> Jits on the desktop are usually bad not just because they do take
> more memory but also because you need the build system of mono
> installed which means more bloat.
=========

=========
> Every compacting GC automatically doubles memory use - you have two
> managed heaps ergo twice the RAM required. If you copy MS and go for
> a three generation one then you risk trebling memory use over using
> a non-compacting one.
>
> (malloc and free do not return memory to the OS on linux and most
> other systems - the memory is retained for reuse for the app).
>
> Mmap'ping blocks of memory can be returned to the OS but they are at
> least 5x slower than malloc/free and are only worth using with
> memory pools.
>
> In the end you have to choose between fast garbage collection (and
> up to 6x memory use) or slow garbage collection with more modest RAM
> requirements - there is no perfectly efficient *and* fast GC out
> there and they have been searching for it for the last 50 years.
=========


6 - Original authors didn't manage to use it:
=========
> As for .NET, even Microsoft themselves had to pull back from
> using it for core functionality due to performance reasons - why
> do we think we will do any better?
=========

======
> Everything in Longhorn was supposed to be written in C# and to be
> managed code. But managed code was going to require machines that
> weren't going to be available for five years or more. So now Microsoft
> is rewriting everything in Longhorn, the developer says. Developers
> claim that the Windows team actually began rethinking Microsoft's .Net
> Framework
======

======
> Yes, innovation comes in the form of prototypes - that doesn't mean
> the final solution should also use these - e.g. in MS Windows how
> many final applications use VB, most used VB for the prototyping,
> but then switched to C++/MFC for the final versions.

> This is where I think the main strength of C# or Python lie.
======


7 - Complexity:
=========
> For the core GNOME desktop upto gnome 2.12, I only need to
> compile and build platform and desktop sources everything run
> fine. With gnome 2.14, I now need to compile the binding stuff
> with python. With proposed tomboy, I have to compile the binding
> stuff gtk#. In the future when there is a nice Java [1] app comes
> along to be accepted as core GNOME app. I will have to compile
> and deliver the Java binding etc.
>
> I just want to highlight this dependencies and hence the growing
> complexities of the GNOME Desktop. Is this the way we as the
> community want to see GNOME to go in this direction?
=========


8 - Why Python can, and Mono doesn't..
=========
> We should not even care about which one is less hoggy.  This is a base
> problem: "Do we need two (or more) development frameworks for a single
> desktop?".
=========

=========
> My opinion: the Python adoption was a mistake. In any case, it's too
> late for that, so let's stop worrying about Python.
>
> BTW, that "if Python did, Mono should do as well" doesn't make
> sense.  Will we do the same with Java? anc C++? and ObjectiveC? Ada?
>
> How many languages and extra platforms do we need to keep everyone
> happy?
=========


9 - Political

  GNOME is a pro-common developed by many people and companies. There
  are people who don't agree with the use of Mono (because of the
  previous problems), and companies that won't/can't ship it, so it
  seems that if we want to keep the pro-common "common" we ought to be
  very careful making this decision.

=========
> Someone mentioned that "everyone is already shipping Mono" - but
> that's not true either - maybe many of the major Linux distros are -
> but what about others like maemo, RedHat Enterprise Linux (don't
> know the plans on this in the future though) and Solaris. There are
> too many legal risks with a full Mono platform - some parts are
> fairly open, but there are others which are not - it's this latter
> part that worries us here in Sun the most (at least that's my view
> on things) - we're sick of fighting with MS and we don't want to
> give them yet another reason for one ;)
>
> Again - this is why I think there needs to be the choice to say "No"
> to mono - it may be that we do consider doing something - but we
> certainly don't want to be forced into it.
=========

=========
> I'm all for innovation - as long as it doesn't exclude people from
> using the Core desktop - including Mono or Python, and misusing it
> for everyday apps (like Beagle) could have a negative effect in the
> long term since these would no longer be optional compilation
> elements since they are part of the Core.
=========


10 - Human Resources

  The more frameworks we use, the more difficult that is going to be
  to fix bugs up.

  If a Mono+GNOME application crashes, it can be either problem of
  GNOME or Mono, so people will have to look all along the stack (a
  much longer stack than previously) to find the problem.. and that
  could be interpreted as that on some occasions GNOME human resources
  would go in to fixing Mono. (and, no.. it isn't like for the libc or
  the kernel, those pieces are needed).

-- 
Greetings, alo.
http://www.alobbs.com