Well, in the IceWeasel vs Firefox situation, it only has to do with trademarks. Debian wanted to give their Firefox package a big make-over (change the logos, appearence), but still wanted to call it Firefox. And the Mozilla trademark policy is very strict in this area: you can't call something Firefox if it does not use Firefox branding and does not have the same look/feel/functionality as the official Firefox distribution.

And in a way it makes sense. Imagine that the debian package did have problems of its own because of the modifications, then by continuing to call the package "Firefox" it would reflect negatively on the "real" Firefox distribution that is endorsed by Mozilla.

Centos and RHEL both have their place, and the fact that RedHat's profits continue to grow every year means they are on the right track. The only difference is that Centos won't give you the same support that RedHat will, but if all you want is the distribution itself, then Centos is the way to go.

On the subject of GNOME vs KDE: GNOME will probably lose more ground with free-software purists as it moves over to .NET more and more. Sure its still open source, but .NET is Microsoft's development platform flagship product (and lock-in tool) and using it for a project like GNOME just....sounds insane! Yet you can already see the transition being made with some apps: Beagle, FSpot and Tomboy Notes.This article in The Resgister about GNOME's move to Mono/.NET reflects Miguel de Icaza's intentions clearly:

The article is a bit dated, but his objectives remain the same.(BTW, I'll continue packaging GNOME as long as its core components remain Mono-free and as long as the Mono dependent bits can be uprooted like weeds ).

Well, in the IceWeasel vs Firefox situation, it only has to do with trademarks. Debian wanted to give their Firefox package a big make-over (change the logos, appearance), but still wanted to call it Firefox.

Actually, it's NOT the look & feel stuff that they're concerned about. They allow things like using your own theme and putting it in your distro's native package format and still call it Firefox. What they don't want is distro-specific patches. Mozilla essentially says, "If there's an itch to be scratched here, put it in our bugtracker and submit your patch. Since it's open source, you're also welcome to put it directly into your version and release it. But because it's no longer in our codebase and we have no quality control over it, at that point you may no longer call it Firefox." The way I see it, the reason for this is pretty much the same reason Slackware uses a kernel more or less straight from kernel.org.

Firefox's build system has a branding switch built-in. One way, you get the official Firefox branding, the other way, you get a browser called Gran Paradiso or whatever you want. Gran Paradiso is the codename for Firefox 3, they use this name for development releases for testers, then turn on the Firefox branding for official, stable releases. From what I gather Debian's patches had, at least at one point, broken that switch.

One of the arguments I recall in support of forking FireFox was that Debian provided support for older FireFox versions than did Mozilla. If Debian sent bug fixes or backports upstream, Mozilla would say that version was no longer supported. If Debian incorporated the changes themselves, Mozilla would not let them call it "FireFox".

Logged

A complex system that works is invariably found to have evolved from a simple system that works.

Eh, I'm not nearly as paranoid about Mono as some. Not that I'm really crazy about it or anything, I could certainly live without it. But reports I've seen from people who've actually used .net/C# have been mostly quite positive.

One of the arguments I recall in support of forking FireFox was that Debian provided support for older FireFox versions than did Mozilla. If Debian sent bug fixes or backports upstream, Mozilla would say that version was no longer supported. If Debian incorporated the changes themselves, Mozilla would not let them call it "FireFox".

That's right, and it's something that had slipped my mind, as I haven't been using Debian much this year. Debian Stable provides support for several years, but there are no updates other than security patches to the versions already in Stable. In other words, if upstream fixes a bug in version 1.0 by issuing a new version, 1.1, they expect everyone to switch to the new version. But that's not how Debian Stable works. Debian will patch 1.0 and provide that as a security fix.

Eh, I'm not nearly as paranoid about Mono as some. Not that I'm really crazy about it or anything, I could certainly live without it. But reports I've seen from people who've actually used .net/C# have been mostly quite positive.

I understand that Mono can be very useful in certain situations, for example in which a company wants to migrate their .NET based application stack to Linux without having to re-write everything. In this case yes, Mono is very valuable.But why on earth rewrite native Linux apps using Mono?! And develop others with it too? Qt4 is already a great toolkit for providing cross-platform portability, and so is Java..NET is Microsoft's "Me too! I also want in with my own development platform!!".

What really fascinates me is De Icaza's obsession with infecting Linux with Microsoft's patent-riddled technology and "standards".

Neither of those is really an apples-to-apples comparison. QT is a widgets toolkit, Java is a programming language, and .NET is an application framework and interface between different applications and programming languages. Granted, there's some overlap between them, especially if you're bringing things like Jython in to give Java support for multiple languages.

Quote

But why on earth rewrite native Linux apps using Mono?!

Because... it's a damn good platform? Because it actually solves some problems better than what's already available in the *nix world? I know it's hard for some MS-bashers to believe, but not everything MS does is a POS.

Miguel's done plenty of interviews over the years explaining his views; I suggest reading a few. Here's one to start you off:

Neither of those is really an apples-to-apples comparison. QT is a widgets toolkit, Java is a programming language, and .NET is an application framework and interface between different applications and programming languages. Granted, there's some overlap between them, especially if you're bringing things like Jython in to give Java support for multiple languages.

I think the fact that KDE4 will also be available for Windows and MacOS X (also thanks to Qt4) speaks for itself. Qt4 has evolved quite beyond the realm of a "simple" widgets toolkit, by providing database, graphics and network backends, and by providing OS-specific integration features. Oh, Qt also ships with an interface designer that can integrate with many IDEs, including VisualStudio.

Hmm...lets not forget the fact that Qt's API's aren't subject to the whims of a megalomaniac corporation.

Quote

Because... it's a damn good platform? Because it actually solves some problems better than what's already available in the *nix world? I know it's hard for some MS-bashers to believe, but not everything MS does is a POS.

MS-bashers...well, its not like MS has given the FOSS community a reason to love them...And aside from the fact that .NET is only an ECMA standard (I guess we can agree on how much those standards are worth..*cough* ooxml *cough*), Mono is basically relying on MS's good-will not to screw around too much with the APIs.

If MS were really committed to allowing cross-platform implementations of its technology, then they wouldn't have screwed Samba's developers by purposefully adding unnecessary complications to SMB2.Listen to Leo Laporte's interview with Jeremy Alison which includes the SMB2 subject: http://www.twit.tv/floww14 (from minute 33, for convenience if you don't care much for the rest). I guess we can call SMB2 a POS, or not? What a classic example of what makes me hate Microsoft.

De Icaza says they can just continually create "double" implementations of the same API if they aren't backwards compatible...dunno, but how sustainable is that kind of development model....?

And for all the good points that .NET has: I don't believe they outweigh the potential problems its use may bring in the future.