Re: Mono/GTK#/Tomboy

[Alvaro Lopez Ortega <alvaro 0x50 org>]

Miguel de Icaza wrote:

>    1. Microsoft, the FUD argument, I wont say anything more that has
>       not been addressed in the past, other than from a legal
>       standpoint we created the "Open Invention Network" to protect
>       open source with teeth.
>
>       Status: FUD.

  I'm not that sure it's FUD.  Well, certainly if it's FUD is due to
  its current market share numbers. However, if GNOME becomes more
  popular I'm really afraid it'd become a real problem.

>    2. Additional Framework: yes, it is an additional and *optional*
>       framework.  Nobody is forcing you to use it.
>
>       Status: minor concern, its optional.

  Minor concern? What an optimistic point of view.  For me this is a
  major concern.

  If we open the door to more additional frameworks, we are allowing
  anyone to base every type of applications on it, which is something
  that will bring a bunch of problems that we don't want to suffer.

>    3. GNOME is the only platform which would depend on an extra
>       framework.
>
>       Status: debunked.
>
>       You quoted KDE, and I pointed to you that KDE has support for
>       Mono, Ruby, Python, JavaScript and Perl. You conveniently
>       have ignored the evidence contrary to your statements.

  There are not basic KDE written on anything but C++. I'm right.
  They can have Mono binding, Python binding, and whatever they want,
  but there aren't important applications based on them.

  So, yeah.. it seems that GNOME is the only desktop with people
  interesting on doing such thing.

>    4. Resources: yes, Mono takes more memory, we are not making it
>       mandatory for Mono applications to be part of the core desktop.
>
>       It is optional;  Dont like it, dont run it.
>
>       Status: Minor concern.

  Ey, that would be fair enough, the consensus solve.  But, for don't
  running it, we have to ensure that all the basic desktop apps are
  based only on the GNOME framework.  It is fine if there are "Mono +
  GNOME" applications out there, but not inside the basic GNOME
  desktop.

  So, again, this is a quite big concern.  Have you read Darren's mail
  on this issue? It's pretty interesting.

>    5. Managed/interpret code is slow/larger
>
>       Yes, it is.   So we should block any managed/interpreted systems
>       to provide bindings to Gnome, because everyone must use
>       C/C++/another compiled language?

   Why should we should do something that radical? :-?

   The only thing we shouldn't do is to allow they use of the basic
   GNOME desktop application.

>       Status: Minor issue.

   I'm sorry to disagree.  Slow code is not a minor issue, no matter
   how positive you're trying to be.

>    6. Original authors could not use it.
>
>       You used a gossip article, I pointed to you to the real
>       reason for the Longhorn failures, which you conveniently
>       ignored.
>
>       You did not reply to whether we can do better than Microsoft
>       (again, conveniently ignored).
>
>       But in addition, Microsoft has a lot of .NET code in shipping
>       products, so the whole argument goes down:
>
> 	http://blogs.msdn.com/danielfe/archive/2005/12/16/504847.aspx
>
>       Status: debunked.

  Miguel, you know way much more than me about Microsoft and .NET,
  that is crystal clear.  So there was no point on arguing on that
  with you.  In anyway, the fact is that they haven't used it.. and
  despite the reasons, that tells me something.

>    7. Build Time Complexity
>
>       A real issue, but someone has pointed out that every Linux distro
>       has already sorted that out.   Besides, Mono is only one extra
>       tarball dependency.
>
>       And its only a dependency for the Gtk# binding, what we are
>       discussing.
>
>       If we are going to have an issue over adding a new tarball as a
>       dependency, we might as well not even have a process to expand
>       Gnome in the first place.
>
>       Status: unless we are willing to make a case for no-new-packages
>       I do not consider this an issue.

  It is not the same to add a new library than to add a new huge
  development framework: a bast class library, compilers and stuff.

  So, again, we shouldn't be that radical, we can perfectly extend
  GNOME but take care of what we use to extend it.

>    8. Why Python can and Mono cant.
>
>       Its hard to argue with someone that thinks that Python was a
>       mistake in the first place (from your email).
>
>       Status: pending.

  Why is that difficult? Is it that difficult to understand that I
  don't want to waste a few megabytes of memory in my desktop just
  because there is an applet written in a convenience language?

  By the way, I do like Python. However, I also think that a GNOME
  applet that is shipped by default is not the right place for it.

>    9. Political
>
>       Your company does not have to ship Mono, it is not mandatory,
>       and the core is not being rewritten to use it.
>
>       That being said, your company, Sun, of all companies, has a patent
>       license to all Microsoft technologies, so there are no technical
>       or legal barriers.
>
>       There are merely strategical and ideological barriers that
>       are barring Sun from shipping Mono.
>
>       Status: Sun's problem.  Not Gnome's.

  You did notice that I'm not writing from my Sun account (you even
  put it on the top of one of your replies). I did that on purpose.

  We have been arguing on this topic for years. We started arguing
  about this, how many? 3 years ago before I joint Sun? And you know
  that my point of view remains the same. So, as you can see there is
  not "your company" on this.

  I guess this problem is pretty clear. GNOME is the only desktop to
  suffer is kind of political problems just because there are a few
  quite big companies involved, and each one has its own interests.

  Novell is pushing for Mono at all cost because it can bring them a
  strategic piece of the Linux environment. So, from that point of
  view I'd say that pushing for Mono in GNOME is "a bit" selfish.

  And, yeah.. to put accept Mono as dependency would be an issue for
  many people, not just for Sun, and that is something that has to be
  taken in to serious consideration:  Mono is not a wide accepted
  technology.

>   10. Human Resources
>
>       Status: minor.
>
>       Your argument assumes that Gnome and Mono can not grow, that
>       they are frozen in time.
>
>       I do not believe for a second that Gnome has reached its peak,
>       if anything more developers are joining the effort.
>
>       Those choosing to use Mono will depend on Mono bug fixes for
>       its bug fixes.  But so does anyone depending on any other
>       library, language and framework.

  It shouldn't depend on another framework. The GNOME framework is
  meant to be the framework in which the GNOME desktop is based
  on. This is a pretty basic premise.

  I'm gonna explain it again with an example in order to make it
  clearer: if in two years time, there is a Mono based applet in the
  default GNOME desktop, and there is something wrong with it, I may
  have to end up debugging Mono to fix the problem... and I'm meant to
  work in GNOME.  Do you see that I meant?

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