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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
