KDE is more integrated and one of the major reasons is the use of Qt/C++.
I'd note that while KDE may be more integrated, your average KDE desktop is not, as I'd guess most desktop users use apps like OpenOffice, XMMS, Mozilla, Wine and so on, none of which are part of KDE nor GNOME.
I think that's a pretty fundamental thing. The idea that everything will be alright if there are enough KDE apps, if nobody uses C anymore, is just flawed. On Windows you have COM, and that means apps can be written in the right language for the job - Delphi for databases and generic desktop apps, VB for prototypes, JavaScript on IE for web apps, Visual C++ for, well, other stuff:)
Linux has no equivalent to COM. Until it does, arguments about whether C++ is better than C is sort of pointless, I'd rather use Object Pascal to write my APIs in, but that's not an option today:(
The reasons GNOME uses C are well documented, and it's not because it's easier to do objects in C.
He has found that OO supported by the language is best as his focus on Mono and C# have shown.
The main issue isn't what's best to develop in, it's how hard it is to share code. If I write an object using GObject, it's fairly trivial to use it from C or C++ (or many other languages). Now, you can bind C++ to C as well, but it's not as easy, nowhere near. The need to manually bind objects is just a total pain in the ass, and something Windows slapped down with COM years ago. CORBA could have been it, but has a bad rap for various reasons.
So the real question now is not, what is it better to develop apps in, but, how can I share my code with everyone, while using my preferred programming paradigm.
One of the points behind Glib is that it is a cross language technology. You don't have to write stuff in C to use GObject, they are (supposedly) fairly easy to bind to other languages. I guess you'd know, as you wrote the KDE GStreamer bindings.
The idea behind.NET is similar - code sharing between languages. The lack of pretty much any automatic-binding (like corba or com) object model at all, means GObject is the best we've got.
So, if people prefer Qt/C++ then that's cool, GObject lets you use that. I don't know C++, and I don't want to learn it unless I have to, so I can use C, or Python, or Perl, or C# etc etc
One of the biggest problems in making KDE and GNOME integrate well and feel consistant is the lack of a standard object model. As Havoc pointed out, some kind of "hub" would be great in future, allowing people to share Qt/C++ code with GLib/C with.NET with Python with Perl.
Unfortunately, getting such a thing into KDE looks set to be next to impossible. A small but vocal minority appear to be dead-set against using even GObject, which only tackles a small subset of the problem of code sharing - the idea of using GObject seems to scare them witless.
I wouldn't normally name names, but it's starting to get very irritating. Neil Stevens and Zack Rusin in particular, (there are others) consistantly object whenver the possibility of using something based on GObject (even when wrapped in the KDE style) is brought up. I've yet to see them state what is wrong with GObject, beyond "it's not appropriate" or "KDE developers should only have to use Qt C++".
To be honest, this isn't the first time I wish KDE had gone with CORBA. Unfortunately, by dropping it before it matured, they blew a hole in the consistancy of the Linux desktop a mile wide, leaving their answer to "how do we get consistancy" to be "only use KDE apps".
If Havoc and Waldo are serious about integration then this problem will have to be addressed in earnest. I do not want to see KDE come down a level in technology just so that GNOME apps can integrate into KDE.
The real problem that needs to be addressed in earnest is the idea that C++ and KDE are fundamentall superior to GObject C/GNOME. While certain KDE developers persist in having a "KDE is perfect, GNOME is teh suck" attitude, the biggest barrier to integration is attitude, not technology.
There's a similar thread on the GNOME desktop-devel-list, basically a debate about DBUS vs CORBA turned into some KDE users (developers? maybe) having a go at GObject yet again.
The main sticking point seems to be GObject, but I've yet to find a KDEer elucidate what is so bad about it, especially considering it was designed with language bindings in mind.
Oh my, did you ever consider it might be self-depreciating humour? I've met several Microsoft employees who refer to themselves as "the borg" or whatever, it's turned into a running gag it seems - I seriously doubt whoever wrote that had a serious look on their face as they typed it.
(1.5). i think i remember reading that "real" employees have different colored shirts than "temp" employees.
IIRC it's different coloured badges, at least in the UK
2. they don't hire they're internal postal mail staff, pitney bowes runs it.
So? That's quite common. Hell, where I work all the site services are contracted out, they do everything from running the network to installing office furniture.
Can't happen, the very nature of distributed development prevents it. This article is basically about geeks going "wow, cool" when faced with stupendous concentrations of wealth that is then spent by other geeks. It's computer-person utopia.
Unfortunately, the real world is not such a utopia. The real world is what you get when the market economy actually works, as opposed to the computer industry, where it's been warped and twisted into a smoking pile of slag.
Open source and free software are about sharing the (intellectual) wealth around, making it available to anybody, not concentrating it in one place. It's a people thing.
This article is the modern day equivalent of stories of how rich and opulent the Kings palaces are, how his staff and manservants live in stunning surroundings and how much they love the King for it. Interesting reading, and it certainly sounds like a cool place to work, but not sadly reflective of anything that can be really recreated while we use our current economic system.
Oh BTW, I might as well remind you that some say it's all built on a house of cards. Is it true? I don't know. Make up your own mind.
No, you READ. I told you, the chances of a unified One True Toolkit is slightly above absolute zero, so a common theming standard makes more sense.
Sorry, but you don't have a clue what you're talking about. Learn about the situation, and then maybe people will take you seriously. Not even Windows or MacOS have one toolkit, this is hardly something unique to Linux.
Its difficult to configure (something you SHOULD NOT HAVE TO DO)
Completely automatic configuration is a stated long term goal of the XFree team.
KDE is easier for average Joe to walk up and use then WindowMaker. Since KDE is slow and bloated its also not worth while for Average Joe to use as his primary OS.
Then use GNOME, which is faster, or upgrade your hardware.
A possible solution would be a new X11 Compatable system for those who want it and a solid fast easy to use UI for it for those who dont. I also think we need a Unified UI Toolkit so everything across applications is the same.
Not going to happen, there are already god knows how many toolkits, and some apps have their own in the name of portability. A better idea is for a theming standard - that'd be very useful, but nobody has done it yet.
I hate this term. Goddamn do I hate this term. I paid $200 retail for my copy of windows 2000 and..... [snip]
The relative quality of your experiences does not change the fact that for the vast majority of the population, it is perceived that one has no option but to pay for Windows. Therefore, it's a tax. The term describes the current status quo quite well really.
2) So you no longer have a problem with code sharing and code reuse? Now you want to argue instead about two different mechanisms for two different problems? Apps are Apps, and Frameworks are Frameworks, and one does not necessarily rely on the other, depending on the direction of transitivity.
I think most/all apps will rely on at least one or more Frameworks, simply because that's how the MacOS APIs come, in much the same way that every Linux app (ignoring the rare static ones) links against some shlibs.
Even if you don't like the way Mac uses Bundles, a Bundle as a generic container is not a bad idea, wherein disparate related files are maintained in a structured manner.
I never said bundles weren't a good idea, I said the lack of strong dependancy checking discouraged code reuse.
I think you make too much of my throwaway comment about inconsistancy. My point was that the culture is one of mostly monolithic applications, whereby all shared code that the app needs external to what comes with MacOS is packaged inside the app. Now installers can fix that yes, but because App Folders are preferred, it's often easier to simply shove it in and give the user an appfolder, so you don't get the level of granularity that you get on Linux or even Windows.
The main problem with that is that you can't rely on the presence of another application usually.
So, if you want to use the functionality in GeeWhiz.framework, it can be located either in the system library, or in the application bundle, or in another applications bundle.
Problem is, the only one you can actually rely on is your own bundle, so that's where you're going to put it.
1) Appfolders have loads of other problems besides this one, there's a discussion on the website in my sig of this in the FAQ.
2) I thought the whole point of the Mac was consistancy. If there are (at least) 2 different ways of installing software, how is that consistant.
3) It discourages code sharing psychologically. Mac users like AppFolders. Therefore, it's easier to just throw this framework you're using into the bundle, than use an installer. But, code sharing suffers.
Really, if developers are being told, use appfolders, except when you want to do a, b, or c then that means appfolders are slightly broken imho.
Not that I haven't been through this debate a thousand times already or anything.....
Yeah, but do you really expect your users to manually download and drag frameworks to the right places? I wouldn't, so if you want to upgrade say QuickTime, you have to package them both in an installer.... at which point you've got installers, just like Windows, which is what the first poster was talking about (MacOS doesn't need installers, cos it's all inside the app).
How does Linux deal with the issue of linked libraries? I'm assuming it has something similar.
It has a lot of things. The first is, as another poster pointed out, what's called soname or libtool versioning. That is, you append the major version number, which represents a specific ABI (not to be confused with API) to the end of the filename, and then apps link against that name , for instance, libfoo.so.2
The actual file on disk is more likely called libfoo.so.2.0.22 - as long as they have the same major version number, they are compatable (in theory). GTK for instance preserves ABI compatability between all 2.x versions, so if you have an app written for GTK 2.0, you can install GTK 2.4 and all the apps will still work.
For some libraries, they are very big and it doesn't make sense to install a totally new copy of the library when perhaps the only thing that's changed is one function. Then we use something called symbol versioning, which is like lib versioning except the actual symbols are renamed. glibc uses this, as do a few other things. In future Wine may do this as well. Symvers are somewhat complex and can't always be applied though. In particular they aren't portable.
Finally, both the developer and user can control the process. Developers can bind to a specific sub-version of a library, if they so wish, although that's rarely used. Developers can also link relative to the binary itself, so you can ship private versions of a library if you don't want to statically link. Users can control the process by setting environment variables.
Having said that, although using these mechanisms Linux avoids "DLL Hell", it has other forms of hell. If you don't use a distro with a large library of prepackaged software (ie anything other than debian or gentoo basically), resolving dependancies is hard.
Sometimes, you encounter "Symbol Fixup Hell", which is one most people aren't aware of, as it's mostly masked by the fact that people prepare binaries for individual distros (and therefore individual sets of libraries). It tends to bite the people packaging stuff for a distro, rather than users. That's when you have 2 versions of the same library mapped into a process at once (ie, libpng) at different points in the link tree. The linker mixes up the symbols and the app segfaults. The glibc team are aware of this, but the fix is complex and they are busy with other stuff:( Hopefully it'll be fixed soon.
Also note that MacOS has long done a great job at packaging applications together so that the installer is unecessary.
I might as well note that this approach has some serious problems as well as the benefit of added simplicity, like:
Only Apple can update the OS. That suits Apples goal of selling more copies of MacOS X, but shafts the customer slightly when they find that a few months after a new release comes out, applications start requiring it. See DirectX for contrast.
Note that there is nothing wrong with a 3rd party application install upgrading parts of the OS, it's just that historically Windows has sucked at it. Look at Debian for an example of how this can be done well.
Code reuse is stifled. On Windows, for the longest time JabberCOM was the de facto Jabber library. Most clients used it, and if you had more than one client installed, they'd share the same copy. There is no real mechanism for doing that, save shipping the framework inside every app, causing enormous bloat. So it doesn't happen very much.
Modules are much "coarser" than say on Linux. I can't imagine MacOS developers getting together to share say 60k of code in a framework, it's just not worth it. That sort of thing happens all the time on Linux, and to a slightly lesser extent on Windows. Again, there's nothing wrong with depending on lots of shared code, it just has to be done properly.
Eliminating some of the key code sharing technologies (true dependancy management, strong component model) from MacOS X was I think a pretty big mistake - it bought them short term simplicity while making sacrifices in the longer term.
Good man:) That's what happened to me, I started off convinced X should die, GNOME was pointless and everybody should use KDE and that Bonobo was a mess:) Well, Bonobo is still a mess if you use C, but try and find the Bonobo Python tutorial, it shows that corba can be very easy with a good high level language.
According to the VP, they'd use Mono exclusively if it had forms support.
As nobody else has done so, I might as well point out that Wine is in the process of being ported to NPTL threads, so in future it should be possible to link Mono into WineLib while using the garbage collector, paving the way for System.Windows.Forms support. Rock on:)
3) GNOME spends a lot of time concerning itself with enterprise customers, whose needs are often very different from those of your local Slashdot user.
I'd just like to point out, as some people seem confused on this, that by addressing the needs of enterprise users, GNOME are also addressing the needs of non-geeks (ie, pretty much everybody). "Enterprise users" sounds like a scary term, but in fact enterprises are made up of humans, like the secretary you might fancy down the hall. One requirement of enterprises is that they have a desktop usable by everybody, not just geeks.
So, although the term might make it sound like GNOME is only interested in seemingly far off and remote user needs, in reality it's very much closer to home than people might imagine. It's the first step along the road to a desktop for your own family. Just a thought.
* I haven't done much kde programming, and no gnome programming. Qt and dcop feel very clean and powerful, integrated. Gnome doesn't have the same feel, but this is just a conception on my behalf. What is Gnome like?
GNOME in general seems to be more "distributed" than KDE. The KDE technologies seem to be more of a "you're either with us, or against us". Qt, KParts and DCOP are a good example of this. When KParts was first being designed, back then it was called Canossa, Waldo Bastian made the following comment here:
Well, you don't see me cheering about that, do you? So instead of improving
this situation we will make it worse. Instead of making KDE a open desktop
environment we keep coming up with solutions which nobody but KDE
and our Troll-friends use. It might be that we are giving away the source,
but or the rest of it we are becoming more proprietary than MS.
Waldo BTW is a well respected and noted KDE developer. He has a point. In many ways the KDE technologies are more integrated, because they are more proprietary. A lot of stuff produced by GNOME is reused outside of the desktop project, for instance libxml2, librsvg, GTK and so on.
I can configure every option I want, upcoming versions are going to have VIM integrated into stuff such as the kmail application, etc. I have no idea where Gnome stands but it seems to be removing all power.
GNOME isn't about removing power. GNOME is about having clean user interfaces. A lot of the "powerful features" in the old gnome were, as their delightful expression goes, "crack features". They were working around stuff that was broken elsewhere. They put insane amounts of configurability into the GUIs themselves, slowing everything down. The new GNOME still has power, but it's revealed in the right place - the more esotoric options are stored in a hierarchy of documented preferences, and the more common options are put into the GUI.
Why do both Gnome and KDE think they should imitate Microsoft on this retarded idea?
I think this particular piece of desktop wierdness came out for the following reasons:
Microsoft did it, mostly to destroy Netscape by "integrating it" with the OS
It's a cool demo of the power of component technology. The temptation to show off KParts/Bonobo by making a generic "document shell" that could in theory view or edit anything was pretty tempting. In contrast, since they dropped OpenDoc MacOS doesn't appear to have any equivalent to Bonobo/ActiveX/KParts.
They are semantically similar, in that they both involve "addresses", they both tend to have back and forward buttons (though actually i think file managers should only have up, a la rox filer)
These days, Nautilus is more a file manager than a web browser, and is still improving. Go look at some GNOME2 screenshots, the Nautilus UI doesn't really "morph" any more like it used to.
Slashdot Mirror
I'd note that while KDE may be more integrated, your average KDE desktop is not, as I'd guess most desktop users use apps like OpenOffice, XMMS, Mozilla, Wine and so on, none of which are part of KDE nor GNOME.
I think that's a pretty fundamental thing. The idea that everything will be alright if there are enough KDE apps, if nobody uses C anymore, is just flawed. On Windows you have COM, and that means apps can be written in the right language for the job - Delphi for databases and generic desktop apps, VB for prototypes, JavaScript on IE for web apps, Visual C++ for, well, other stuff :)
Linux has no equivalent to COM. Until it does, arguments about whether C++ is better than C is sort of pointless, I'd rather use Object Pascal to write my APIs in, but that's not an option today :(
The reasons GNOME uses C are well documented, and it's not because it's easier to do objects in C.
The main issue isn't what's best to develop in, it's how hard it is to share code. If I write an object using GObject, it's fairly trivial to use it from C or C++ (or many other languages). Now, you can bind C++ to C as well, but it's not as easy, nowhere near. The need to manually bind objects is just a total pain in the ass, and something Windows slapped down with COM years ago. CORBA could have been it, but has a bad rap for various reasons.
So the real question now is not, what is it better to develop apps in, but, how can I share my code with everyone, while using my preferred programming paradigm.
The idea behind .NET is similar - code sharing between languages. The lack of pretty much any automatic-binding (like corba or com) object model at all, means GObject is the best we've got.
So, if people prefer Qt/C++ then that's cool, GObject lets you use that. I don't know C++, and I don't want to learn it unless I have to, so I can use C, or Python, or Perl, or C# etc etc
Unfortunately, getting such a thing into KDE looks set to be next to impossible. A small but vocal minority appear to be dead-set against using even GObject, which only tackles a small subset of the problem of code sharing - the idea of using GObject seems to scare them witless.
I wouldn't normally name names, but it's starting to get very irritating. Neil Stevens and Zack Rusin in particular, (there are others) consistantly object whenver the possibility of using something based on GObject (even when wrapped in the KDE style) is brought up. I've yet to see them state what is wrong with GObject, beyond "it's not appropriate" or "KDE developers should only have to use Qt C++".
To be honest, this isn't the first time I wish KDE had gone with CORBA. Unfortunately, by dropping it before it matured, they blew a hole in the consistancy of the Linux desktop a mile wide, leaving their answer to "how do we get consistancy" to be "only use KDE apps".
The real problem that needs to be addressed in earnest is the idea that C++ and KDE are fundamentall superior to GObject C/GNOME. While certain KDE developers persist in having a "KDE is perfect, GNOME is teh suck" attitude, the biggest barrier to integration is attitude, not technology.
The main sticking point seems to be GObject, but I've yet to find a KDEer elucidate what is so bad about it, especially considering it was designed with language bindings in mind.
Oh my, did you ever consider it might be self-depreciating humour? I've met several Microsoft employees who refer to themselves as "the borg" or whatever, it's turned into a running gag it seems - I seriously doubt whoever wrote that had a serious look on their face as they typed it.
IIRC it's different coloured badges, at least in the UK
2. they don't hire they're internal postal mail staff, pitney bowes runs it.
So? That's quite common. Hell, where I work all the site services are contracted out, they do everything from running the network to installing office furniture.
Unfortunately, the real world is not such a utopia. The real world is what you get when the market economy actually works, as opposed to the computer industry, where it's been warped and twisted into a smoking pile of slag.
Open source and free software are about sharing the (intellectual) wealth around, making it available to anybody, not concentrating it in one place. It's a people thing.
This article is the modern day equivalent of stories of how rich and opulent the Kings palaces are, how his staff and manservants live in stunning surroundings and how much they love the King for it. Interesting reading, and it certainly sounds like a cool place to work, but not sadly reflective of anything that can be really recreated while we use our current economic system.
Oh BTW, I might as well remind you that some say it's all built on a house of cards. Is it true? I don't know. Make up your own mind.
Sorry, but you don't have a clue what you're talking about. Learn about the situation, and then maybe people will take you seriously. Not even Windows or MacOS have one toolkit, this is hardly something unique to Linux.
Completely automatic configuration is a stated long term goal of the XFree team.
KDE is easier for average Joe to walk up and use then WindowMaker. Since KDE is slow and bloated its also not worth while for Average Joe to use as his primary OS.
Then use GNOME, which is faster, or upgrade your hardware.
A possible solution would be a new X11 Compatable system for those who want it and a solid fast easy to use UI for it for those who dont. I also think we need a Unified UI Toolkit so everything across applications is the same.
Not going to happen, there are already god knows how many toolkits, and some apps have their own in the name of portability. A better idea is for a theming standard - that'd be very useful, but nobody has done it yet.
The relative quality of your experiences does not change the fact that for the vast majority of the population, it is perceived that one has no option but to pay for Windows. Therefore, it's a tax. The term describes the current status quo quite well really.
I think most/all apps will rely on at least one or more Frameworks, simply because that's how the MacOS APIs come, in much the same way that every Linux app (ignoring the rare static ones) links against some shlibs.
Even if you don't like the way Mac uses Bundles, a Bundle as a generic container is not a bad idea, wherein disparate related files are maintained in a structured manner.
I never said bundles weren't a good idea, I said the lack of strong dependancy checking discouraged code reuse.
I think you make too much of my throwaway comment about inconsistancy. My point was that the culture is one of mostly monolithic applications, whereby all shared code that the app needs external to what comes with MacOS is packaged inside the app. Now installers can fix that yes, but because App Folders are preferred, it's often easier to simply shove it in and give the user an appfolder, so you don't get the level of granularity that you get on Linux or even Windows.
So, if you want to use the functionality in GeeWhiz.framework, it can be located either in the system library, or in the application bundle, or in another applications bundle.
Problem is, the only one you can actually rely on is your own bundle, so that's where you're going to put it.
1) Appfolders have loads of other problems besides this one, there's a discussion on the website in my sig of this in the FAQ.
2) I thought the whole point of the Mac was consistancy. If there are (at least) 2 different ways of installing software, how is that consistant.
3) It discourages code sharing psychologically. Mac users like AppFolders. Therefore, it's easier to just throw this framework you're using into the bundle, than use an installer. But, code sharing suffers.
Really, if developers are being told, use appfolders, except when you want to do a, b, or c then that means appfolders are slightly broken imho.
Not that I haven't been through this debate a thousand times already or anything.....
Yeah, but do you really expect your users to manually download and drag frameworks to the right places? I wouldn't, so if you want to upgrade say QuickTime, you have to package them both in an installer .... at which point you've got installers, just like Windows, which is what the first poster was talking about (MacOS doesn't need installers, cos it's all inside the app).
It has a lot of things. The first is, as another poster pointed out, what's called soname or libtool versioning. That is, you append the major version number, which represents a specific ABI (not to be confused with API) to the end of the filename, and then apps link against that name , for instance, libfoo.so.2
The actual file on disk is more likely called libfoo.so.2.0.22 - as long as they have the same major version number, they are compatable (in theory). GTK for instance preserves ABI compatability between all 2.x versions, so if you have an app written for GTK 2.0, you can install GTK 2.4 and all the apps will still work.
For some libraries, they are very big and it doesn't make sense to install a totally new copy of the library when perhaps the only thing that's changed is one function. Then we use something called symbol versioning, which is like lib versioning except the actual symbols are renamed. glibc uses this, as do a few other things. In future Wine may do this as well. Symvers are somewhat complex and can't always be applied though. In particular they aren't portable.
Finally, both the developer and user can control the process. Developers can bind to a specific sub-version of a library, if they so wish, although that's rarely used. Developers can also link relative to the binary itself, so you can ship private versions of a library if you don't want to statically link. Users can control the process by setting environment variables.
Having said that, although using these mechanisms Linux avoids "DLL Hell", it has other forms of hell. If you don't use a distro with a large library of prepackaged software (ie anything other than debian or gentoo basically), resolving dependancies is hard.
Sometimes, you encounter "Symbol Fixup Hell", which is one most people aren't aware of, as it's mostly masked by the fact that people prepare binaries for individual distros (and therefore individual sets of libraries). It tends to bite the people packaging stuff for a distro, rather than users. That's when you have 2 versions of the same library mapped into a process at once (ie, libpng) at different points in the link tree. The linker mixes up the symbols and the app segfaults. The glibc team are aware of this, but the fix is complex and they are busy with other stuff :( Hopefully it'll be fixed soon.
LD_PRELOAD is a part of the ELF specs, which are followed by nearly every form of UNIX I know of (except macos, but well, let's not go there ;)
I might as well note that this approach has some serious problems as well as the benefit of added simplicity, like:
- Only Apple can update the OS. That suits Apples goal of selling more copies of MacOS X, but shafts the customer slightly when they find that a few months after a new release comes out, applications start requiring it. See DirectX for contrast.
- Code reuse is stifled. On Windows, for the longest time JabberCOM was the de facto Jabber library. Most clients used it, and if you had more than one client installed, they'd share the same copy. There is no real mechanism for doing that, save shipping the framework inside every app, causing enormous bloat. So it doesn't happen very much.
- Modules are much "coarser" than say on Linux. I can't imagine MacOS developers getting together to share say 60k of code in a framework, it's just not worth it. That sort of thing happens all the time on Linux, and to a slightly lesser extent on Windows. Again, there's nothing wrong with depending on lots of shared code, it just has to be done properly.
Eliminating some of the key code sharing technologies (true dependancy management, strong component model) from MacOS X was I think a pretty big mistake - it bought them short term simplicity while making sacrifices in the longer term.Note that there is nothing wrong with a 3rd party application install upgrading parts of the OS, it's just that historically Windows has sucked at it. Look at Debian for an example of how this can be done well.
Good man :) That's what happened to me, I started off convinced X should die, GNOME was pointless and everybody should use KDE and that Bonobo was a mess :) Well, Bonobo is still a mess if you use C, but try and find the Bonobo Python tutorial, it shows that corba can be very easy with a good high level language.
As nobody else has done so, I might as well point out that Wine is in the process of being ported to NPTL threads, so in future it should be possible to link Mono into WineLib while using the garbage collector, paving the way for System.Windows.Forms support. Rock on :)
I'd just like to point out, as some people seem confused on this, that by addressing the needs of enterprise users, GNOME are also addressing the needs of non-geeks (ie, pretty much everybody). "Enterprise users" sounds like a scary term, but in fact enterprises are made up of humans, like the secretary you might fancy down the hall. One requirement of enterprises is that they have a desktop usable by everybody, not just geeks.
So, although the term might make it sound like GNOME is only interested in seemingly far off and remote user needs, in reality it's very much closer to home than people might imagine. It's the first step along the road to a desktop for your own family. Just a thought.
Agreed about the rest of your points though.
GNOME in general seems to be more "distributed" than KDE. The KDE technologies seem to be more of a "you're either with us, or against us". Qt, KParts and DCOP are a good example of this. When KParts was first being designed, back then it was called Canossa, Waldo Bastian made the following comment here:
Waldo BTW is a well respected and noted KDE developer. He has a point. In many ways the KDE technologies are more integrated, because they are more proprietary. A lot of stuff produced by GNOME is reused outside of the desktop project, for instance libxml2, librsvg, GTK and so on.
I can configure every option I want, upcoming versions are going to have VIM integrated into stuff such as the kmail application, etc. I have no idea where Gnome stands but it seems to be removing all power.
GNOME isn't about removing power. GNOME is about having clean user interfaces. A lot of the "powerful features" in the old gnome were, as their delightful expression goes, "crack features". They were working around stuff that was broken elsewhere. They put insane amounts of configurability into the GUIs themselves, slowing everything down. The new GNOME still has power, but it's revealed in the right place - the more esotoric options are stored in a hierarchy of documented preferences, and the more common options are put into the GUI.
I think this particular piece of desktop wierdness came out for the following reasons:
These days, Nautilus is more a file manager than a web browser, and is still improving. Go look at some GNOME2 screenshots, the Nautilus UI doesn't really "morph" any more like it used to.