Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 8:27 UTC (Thu) by wstephenson (subscriber, #14795)
In reply to: Repositioning the KDE Brand (KDE.News) by JoeF
Parent article: Repositioning the KDE Brand (KDE.News)

The tools are decoupled from the 'full english breakfast' session. If you couldn't get KDE 4 Kopete running in a KDE 3 session, you didn't have the KDE 4 libraries installed right. It's your responsibility as a user to either use a distribution which does this for you, or inform yourself how to do it yourself correctly.

The third option, moaning that KDE tells big fat lies in the comments here, may make you feel better, but just amuses the rest of us.

(Log in to post comments)

Posted Nov 26, 2009 11:38 UTC (Thu) by nye (guest, #51576) [Link]

There's always the fourth option - demean and put down anyone who thinks that saying "these versions are decoupled" shouldn't imply "as long as you have the degree required to figure out how to do it".

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 13:30 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]

We can't help packaging bugs. Any KDE app works anywhere if it is properly packaged. Even on win and Mac. 'KDE 3.5' doesn't influence the apps which work in there - to non-KDE-3.5 apps it acts as a mere windowmanager.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 2:45 UTC (Fri) by lysse (guest, #3190) [Link]

> We can't help packaging bugs. Any KDE app works anywhere if it is properly packaged.

Yes, but that phrase - "properly packaged" - covers a vast and growing multitude of sins. If something depends on 500 different libraries, then I'd say claiming that anyone who found it impossible to get all 500 in sync was at fault for not using a properly packaged version of that something is a huge abrogation of responsibility.

And whilst I don't use KDE - haven't for years; never really got on with it, and I'm not demanding enough of my desktops to warrant it - this is becoming an increasing problem with *everything* in the FOSS ecosystem. I've seen non-beta releases that don't even bother packaging up their in-house dependencies properly! And I'm sick of a situation that's got way, WAY worse than DLL Hell ever was, and is ludicrously worse than Windows is today - and frankly, this idea that you can shrug off any and all responsibility for not making your shit compile properly by carping "proper package!" has been a massive contributory factor.

Sorry, did you want constructive criticism? Well, here's a suggestion - if you're shipping a source package, then at least make your config/build systems capable of fetching and default-building any missing dependencies statically, automatically, within the same damned source tree! Anything less than that is just an abrogation of the responsibility of going beyond works-for-me that you implicitly accept when you seek other users for your software. Honestly, it's the software equivalent of learning that houses are not just magically tidied up by the cleaning fairy a few moments before guests arrive...

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 2:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

please name a single program which has it's build system setup to fetch the source code for all libraries that it depends on, configure them, and build them when you try to build the program

nothing does this, and there are good reasons why this is so.

do you want the developers tracking the details of all the libraries that they use, where to get them, how to configure them appropriately (for all different platforms no less), how to install them without conflicts on every distro out there, etc.

or do you want them working on improving their application and documenting that they need library X (version > y, tested up through version z) and let the users or distro maintainers pull, configure, and install the appropriate libraries?

personally, I want the developers to work on their own app.

kdesvn-build

Posted Nov 27, 2009 3:44 UTC (Fri) by sbishop (guest, #33061) [Link]

please name a single program which has it's build system setup to fetch the source code for all libraries that it depends on, configure them, and build them when you try to build the program

KDE, funny enough: http://kdesvn- build.kde.org/. I've used it on old RHEL systems to build a decent, up- to-date KDE. It was nice to have everything taken care of for me.

kdesvn-build

Posted Nov 27, 2009 4:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

WOW, you mean that it will fetch the code for glibc and compile it if the development packages are not already installed on the system? what about PAM libraries?

I suspect that the most it did was to grab other KDE specific libraries.

kdesvn-build

Posted Nov 29, 2009 18:17 UTC (Sun) by sbishop (guest, #33061) [Link]

glibc and PAM, huh? Well, you need to be careful. If you have the script handle the user-space component of your operating system, it must, of course, handle the kernel-space component as well. You will, if I remember right, end up running FreeBSD. (It's pretty popular with the KDE devs.)

Typically, however, kdesvn-build will only build and install Qt, taglib, CMake, and QCA, among others.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 3:14 UTC (Fri) by foom (subscriber, #14868) [Link]

> Honestly, it's the software equivalent of learning that houses are not just magically tidied
> up by the cleaning fairy a few moments before guests arrive...

My software house *is* magically tidied up -- Debian unstable or experimental generally has recent
enough versions of any library I need that I'm usually just an apt-get install away from having the
prerequisites for compiling other software of interest.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 7:00 UTC (Fri) by nix (subscriber, #2304) [Link]

You want everything's build systems to learn how to autobuild glibc for
you if your version is too old?! If not that, then where do you stop?

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 13:02 UTC (Fri) by lysse (guest, #3190) [Link]

The thing about rants (well, mine anyway) is that they're (a) born of deep
frustration, and (b) not necessarily 100% thought through, especially when
it comes to solutions.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 18:36 UTC (Thu) by JoeF (subscriber, #4486) [Link]

Right, I didn't have the KDE4 libraries installed "right" because I didn't have them installed, period.
That's the lack of decoupling right there. You essentially have to have the whole KDE4 installed because the bulk of KDE _are_ the libraries. Thanks for making my point.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 19:20 UTC (Thu) by yokem_55 (subscriber, #10498) [Link]

Um no. Kdelibs does not include things that make up the full desktop shell
like plasma, kwin, dolphin, konqueror, kate, etc. Most distros have no
problem installing both kdelibs3 and kdelibs4, thus making it easy to pull
in kde4 apps into the kde3 desktop shell.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 19:48 UTC (Thu) by JoeF (subscriber, #4486) [Link]

Yes, but not all distros have the kde4 libs.
_That's_ the issue. Decoupling means I can download a kopete package, and it runs. I shouldn't have to go and download or compile the whole kdelibs, kdepimlibs and kde-support stuff, with all the dependencies that entails (boost, etc. etc.) That's what I had to do to get things working. And that's certainly _not_ what "decoupling" means.
The competition, e.g., Pidgin, works without all that cruft.
I only went through all this because I don't particularly like Pidgin. Others with a lower pain threshold would probably have given up.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 20:02 UTC (Thu) by dkite (guest, #4577) [Link]

>Decoupling means I can download a kopete package, and it runs. I shouldn't
have to go and download or compile the whole kdelibs, kdepimlibs and kde-
support stuff, with all the dependencies that entails (boost, etc. etc.)

Are you suggesting that
1. developers encourage static linking, or
2. developers roll their own when it comes to, I dunno, C++ libraries,
contact information server, graphics primitives, icon and configuration
handling, etc.?

Try building something like gnucash. Same issue. I would rather the
developers use existing libraries. There are two benefits that come to
mind, first the developers will have more time to add features to their
application, and the libraries will be tested and improved for everyone
else.

This isn't a KDE issue.

Derek

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 21:44 UTC (Thu) by JoeF (subscriber, #4486) [Link]

It is about minimizing the dependencies. Kopete probably only uses a small fraction of the stuff in kdelibs.
And if it was packaged on its own, like pidgin, it would have to have the required libraries and _only_ the required libraries with it.
That doesn't mean that it has to be statically linked. That's a non-sequitur.
In fact, I was rather surprised that kopete wasn't a separate download. It for sure isn't a core component or KDE, so why in the world would it only be available as bundle with all the other kde stuff? Even in kdenetwork, there is a whole bunch of stuff in there that has nothing at all to do with each other, except that it is somehow network-related.

And again, the whole issue is not about kopete per se, but about the fact that at this point, there isn't all that much decoupling, making the name change stuff just some marketing BS.
What they should have done is actually _do_ the decoupling, and _then_ announce it.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 22:20 UTC (Thu) by aseigo (guest, #18394) [Link]

"Kopete probably only uses a small fraction of the stuff in kdelibs.
And if it was packaged on its own, like pidgin, it would have to have the required libraries and _only_ the required libraries with it."

This is what most distributions offer, in fact. Exactly, and precisely.

"In fact, I was rather surprised that kopete wasn't a separate download. It for sure isn't a core component or KDE, so why in the world would it only be available as bundle with all the other kde stuff?"

Good question; we offer the source code for those who would like to build it. Most of our users get it from our distributors, in your case that's Slackware. For those who decide to grab the sources and build, we've found that people appreciate being able to grab a representative "basic set" of tools for a given topic. For more advanced tools or vertical applications, we put those in Extragear and they are, indeed, shipped completely on their own.

Each item in the package that Kopete is in is buildable separately, however. You can configure the top level module and then simply cd into the kopete directory and build it from there. You don't need to build or install anything else in the KDE Network module / basic application set. The bundling of the sources is simply a convenience, one many of our from-source users appreciate.

However, many KDE distributors (most, in fact) split those packages up into smaller chunks, so that Kopete, for instance, appears on its own. Let me give you a practical example from OpenSUSE:

independence:~ # zypper search kopete
Loading repository data...
Reading installed packages...

As you can see, there is both Kopete built using the 3 and 4 versions of the KDE dev platform. Even one of the protocols (facebook) is broken out into its own package in this case. I can install one or all of those packages and everything is handled for me. If I wanted the version of Kopete from KDE SC 4.3 but I was using the KDE 3 desktop, I could just do "zypper install kde4-kopete" and Kopete along with the needed libraries would be installed (and nothing else; not the rest of kdenetork, not the KDE Plasma Desktop .. just the KDE 4 Dev Platform and other libraries that Kopete may use). I can even install the development headers so I can build third party plugins for Kopete from sources if I wish.

KDE makes this possible by ensuring that the apps in the main modules are buildable separately and by shipping all the non-"basic set" applications individually from Extragear. Distributors make this possible by making sound decisions for their end users.

Not all distributors will package things this way, of course, and that's one of the things about freedom: different people will do it different ways according to their needs, and those needs may not be yours. If Slackware doesn't package things the way you need them to then use someone else as your KDE distributor. (I know many people for whom Slackware does it "just right", so this isn't a slam on Slackware in any way. :)

None of this has anything, whatsoever, to do with the KDE rebranding, other than that the rebranding makes the KDE communication match the reality of what actually happens. e.g. Kopete available separately from the Plasma Workspace.

(As a thought experiment, how do you think it works on MacOS or Windows? :)

"What they should have done is actually _do_ the decoupling, and _then_ announce it."

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 6:22 UTC (Mon) by JoeF (subscriber, #4486) [Link]

For those who decide to grab the sources and build, we've found that people appreciate being able to grab a representative "basic set" of tools for a given topic.
Well, then count me as one who doesn't appreciate that. I'd like to be able to just grab the sources I need to compile and run one program, e.g., kopete.

Can we agree on this: let's ensure you have all your facts straight, and THEN let's hear what you think we should do? That seems to be the logical, not to mention the responsible, way to go about this.
If you try to insinuate that I don't have my facts right, try better next time. Insulting your users is never a good way to go about things.
I have wasted enough time to just get this whole kopete for KDE4 running just because KDE3 has become abandonware.
If you want a constructive answer, the logical way would be to continue to support KDE3 at least for some time and not let people who, for whatever reason, are not ready to switch to kde4 yet, standing in the rain. That, in my opinion, is more important than some pie-in-the-sky, marketing-driven rebranding.

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 15:36 UTC (Mon) by foom (subscriber, #14868) [Link]

Your problem appears to be with the source code layout of KDE, something that, quite frankly, doesn't matter for 99% of users. So it's rather silly to hear you complain so vociferously that their marketing is incorrect, when you're probably one of the only people in the world who both 1) builds from source 2) cares how big it is.

If you find compiling from source that horrendous, I'd recommend using a package manager to install your software, where the libraries and apps have already been split off into individual pieces. And let the KDE people lay out their source code however they find easiest for *development*.

Repositioning the KDE Brand -- v-- Build from source

Posted Dec 3, 2009 20:39 UTC (Thu) by brianomahoney (subscriber, #6206) [Link]

No, once again nonsense:

What I am really tired of is the 3-4 major sub-projects that an Open-Source distribution depends on eg: (1) KDE (2) Mozilla (3) OOO (4) Java/Mono which seem unable to (a) package their source, (b) provide a convenient build system, (c) list dependancies realistically.

I am all for innovation but do we really need UNDOCUMENTED uses of autoX, libtool, cmake, ant, python 'pyXXX' and many more ... all of which don't come outr of a SVN or GIT download and neet to be stitched together by hand with pre, co and postrequisites before you can say 'make' or whatever?

NO, this is sloppy junk, and BTW Google should stop adding to this mess with Chrome and Android.

Repositioning the KDE Brand -- v-- Build from source

Posted Dec 4, 2009 1:11 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, for KDE and Mozilla your points are wholly baseless.

The build system for Mozilla is a pretty boring Autoconf/Automake thing,
and has some (rather out of date) documentation. The build system for KDE
4 has lots and lots of docs (let's ignore the brittle KDE3
edge-of-the-Autoconf-world build system, it's dead).

The cmake and autoconf-driven build systems of Mzilla and KDE4 are
definitely convenient: fire and forget, literally. (Mozilla's problem here
is that a lot of its configure flags actually break the system if you turn
them on: I don't know why they're available. But the defaults work. KDE
doesn't have this problem.)

My autobuilder scripts for both KDE and Mozilla are less than two dozen
lines. (Of course this excludes the parts that do the ordinary boring
configure && make && make install stuff that most packages need. This is
KDE/Mozilla-specific stuff). So the build system is definitely not much
less conveneint than that of other packages.

Both Mozilla and KDE list their dependencies: KDE does so, again, to an
almost insane length. If you can't find it (three whole clicks from the
KDE front page) and can't work out the deps by consulting the source, you
probably shouldn't be trying to build directly from the VCS.

Your belief that generated files like configure scripts et al should be
stored in version control systems disagrees with that of everyone working
on free software projects I've ever talked to, and betrays a definite lack
of experience in the area. Generated files should not, ever, go into
VCSes, even if it adds dependencies: only the developers need such
dependencies, and the generated files will rapidly lead yo into conflict
hell.

Now, OOo is a sodding nightmare, I'll agree with that. Any project that
ends up producing forks just to fix the *build system* is in a bad way.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 18:46 UTC (Thu) by JoeF (subscriber, #4486) [Link]

The third option, moaning that KDE tells big fat lies in the comments here, may make you feel better, but just amuses the rest of us.

Decoupling means being able to run kopete without installing all the rest of KDE4.
Heck, pidgin can run on KDE3 just fine. Why can't the latest kopete? The answer is: because it is tightly coupled to KDE4.
No amount of arrogant posts changes the fact that at this point, the "decoupling" is indeed a "big fat lie." It is PHB-style marketing BS.
Get your act together and release a stand-alone kopete that runs on KDE3. _Then_ you would have a point.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 19:50 UTC (Thu) by aseigo (guest, #18394) [Link]

That's like asking for the KDE3 version of Kopete to run without KDE3's libraries, e.g. make it run with KDE1's libraries. Well, that's an impossibility.

However you can install just the KDE Dev Platform 4 libraries and runtime (something not easily achieved with KDE3, btw; we made this much easier by purposefully reorganizing parts of our source tree for the 4.x releases). This makes it no different in any way to any other application out there that uses shared libraries.

The libraries are, btw, less than 10% of the code of the overall KDE codebase.

"The answer is: because it is tightly coupled to KDE4."

That is factually incorrect. It only uses the 4.x libraries and is not tightly coupled to any other part of KDE's software outside of that. It isn't tightly coupled to other KDE appications and has no coupling at all to any KDE workspace (or non-KDE workspace, for that matter).

"Get your act together and release a stand-alone kopete that runs on KDE3."

The version of Kopete that comes with the 4.x series does run in the KDE3 workspace and aside other KDE3 apps just fine as long as you have the 4.x libs (and that's all!) installed; we also released a KDE3 version of Kopete, though that is no longer developed further. You are free to do so.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 21:56 UTC (Thu) by JoeF (subscriber, #4486) [Link]

The version of Kopete that comes with the 4.x series does run in the KDE3 workspace and aside other KDE3 apps just fine as long as you have the 4.x libs (and that's all!) installed

So, you essentially confirm that there is no decoupling at this point.

we also released a KDE3 version of Kopete, though that is no longer developed further. You are free to do so.

I've found the patches to get the Yahoo login working for kopete 0.12.7, and I am using that now, thank you very much.

But again, the whole issue is not about any particular program per se. The issue is that your announcement of decoupling is nothing more than basically meaningless marketing hogwash at this point.
I hope you add some meat, i.e., actually _do_ the decoupling you talk about.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 22:28 UTC (Thu) by aseigo (guest, #18394) [Link]

"So, you essentially confirm that there is no decoupling at this point."

No; you're evidently asking for Kopete not to use any libraries. That's not how software works.

What we're saying is that there is a development platform, workspaces and applications. The applications and workspaces use the dev platform, but applications and workspaces do not rely on each other.

As I explained above (the comment containing the example using Zypper) you can quite easily see this in action.

"I've found the patches to get the Yahoo login working for kopete 0.12.7, and I am using that now, thank you very much."

Great! :)

"The issue is that your announcement of decoupling is nothing more than basically meaningless marketing hogwash at this point."

The announcement is completely accurate. The decoupling talked about in the announcement is not at all what you are looking for (applications 'magically' using libraries they haven't been written for; in such a world the GIMP could use Qt and MS Office would run on Linux natively). From what we can gather from your previous comments you have some deep misconceptions about how things are put together within KDE's software. To be frank, that is something we do take part of the blame for: we have not been very clear in how we communicate "how things actually get put together" and so people end up with all sorts of odd ideas. This rebranding is one piece in the overall solution for that happening to people in the future.

But to reiterate: apps are not tied to the workspace; they are not tied to each other; they do depend on the development platform (which is the entire point of the dev platform, of course), but that is a relatively thin layer of libraries (relative to the bulk of applications above and software infrastructure below). This is exactly what the announcement tries to make clear, and this is exactly how it's been since at least KDE 3.0 if not even earlier. (IOW, this isn't even a "KDE4" thing)

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 6:30 UTC (Mon) by JoeF (subscriber, #4486) [Link]

No; you're evidently asking for Kopete not to use any libraries. That's not how software works.
I know very well how software works, I develop software myself.
But, I would not have my users jump through the amount of hoops that you apparently think is ok.
And I don't think I have misconceptions about how KDE works. I understand very well that kopete, for example, relies on certain libraries. But I don't think it relies on most of the libraries that need to be compiled in kdelibs. And it certainly doesn't need all the things in kdenetworks.
And I have a certain understanding of the word "decoupling", based on the English dictionary definition. It seems to me that the KDE people use a different definition.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 0:54 UTC (Fri) by malor (subscriber, #2973) [Link]

I have no dog in this race, and while I suspect this 'branding' idea is going to fail for the simple reason that it's too complex, I do want to show the output from Debian Lenny, coming from a server that's not presently running X Windows:

apt-cache show kopete [snip] Source: kdenetwork Version: 4:3.5.10-2 Replaces: konversation (<= 0.14.0-4), sim (<= 0.9.3-2) Depends: kdelibs4c2a (>= 4:3.5.9), libc6 (>= 2.7-1), libgadu3 (>= 1:1.8.0+r592), libgcc1 (>= 1:4.1.1), libglib2.0-0 (>= 2.12.0), libgsmme1c2a (>= 1.10), libidn11 (>= 0.5.18), libmeanwhile1 (>= 1.0.2), libqt3-mt (>= 3:3.3.8b), libstdc++6 (>= 4.2.1), libx11-6, libxml2 (>= 2.6.27), libxrender1, libxslt1.1 (>= 1.1.18) Recommends: qca-tls Suggests: kdeartwork-emoticons, khelpcenter, imagemagick, gnupg, ekiga

I did an 'aptitude install kopete', just to see what would be installed:

The following NEW packages will be installed: aspell{a} aspell-en{a} dbus{a} dbus-x11{a} dictionaries-common{a} esound-clients{a} esound-common{a} fam{a} hicolor-icon-theme{a} kdelibs-data{a} kdelibs4c2a{a} kopete libakode2{a} libart-2.0-2{a} libarts1-akode{a} libarts1c2a{a} libartsc0{a} libasound2{a} libaspell15{a} libaudiofile0{a} libavahi-client3{a} libavahi-common-data{a} libavahi-common3{a} libavahi-qt3-1{a} libavc1394-0{a} libdbus-1-3{a} libesd0{a} libfam0{a} libfreebob0{a} libgadu3{a} libgsmme1c2a{a} libiec61883-0{a} libilmbase6{a} libjack0{a} libjasper1{a} liblua50{a} liblualib50{a} libmad0{a} libmeanwhile1{a} libopenexr6{a} libraw1394-8{a} libsamplerate0{a} libspeex1{a} libtiff4{a} libvorbis0a{a} libvorbisfile3{a} libxaw7{a} libxpm4{a} libxslt1.1{a} libxtrap6{a} libxxf86misc1{a} menu-xdg{a} oss-compat{a} portmap{a} qca-tls{a} x11-xserver-utils{a}

That's not a completely trivial list, and it'll use 137 megs on disk to run, but that's not even vaguely the whole KDE4 distro. It looks like it's just grabbing the libs, and that whatever distro you're using has done a poorer job of packaging.

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 8:11 UTC (Mon) by JoeF (subscriber, #4486) [Link]

Thanks for actually making my point.
137MB for an f-ing IM client??? Give me a break.
That's Microsoft-style bloatware.
If kopete really needs 137MB of disk space to run, something is seriously wrong with it.

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 9:31 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

Two points.

By the looks of it, malor's system doesn't have any existing software using X11 or audio.
aptitude appears to have been configured to install Recommends: items by default.

Repositioning the KDE Brand (KDE.News)

Posted Dec 1, 2009 5:44 UTC (Tue) by malor (subscriber, #2973) [Link]

Did you actually read the list of required dependencies? This is on a fairly minimal server without X Windows, so getting all the dependencies installed requires a great deal more than it would on a server with X already on it.

If you look at the direct depends carefully, most of them are very basic libraries for sound and graphics, as well as a couple for talking on specific IM networks. The only two that are directly KDE-related appear to be kdelibs4c2a and libqt3-mt. kdelibs is about 10 megs, libqt3 is about 3.5, and kopete itself is 8 megs. So it's a total KDE-related footprint of about 21 or 22 megs, which is maybe a little high, but considering you're getting the QT and KDE libraries with it, not at all unreasonable. The rest of the dependencies are really basic things that you'd usually have installed if you were on X Windows, even if you don't have KDE at all.

Ubuntu is quite different; they've put a TON of dependencies on kopete, and even starting from X, you'll end up with an extra 215 megs of stuff. So the clean packaging is quite clearly optional. I presume that they've compiled more features into Ubuntu kopete, but I don't know that for sure.

Basically, it looks to me like the KDE claims of fairly strong differentiation between the desktop environment and basic requirements to run individual pieces of software are quite accurate. If I just 'aptitude install kde', it'll take 1,139 megs.

As a point of comparison, in a quick search, I don't see any GNOME applications that do the multi-network connection. GnomeICU does ICQ only, and takes 111 megs with dependencies.

For context: 'aptitude install gnome' requires 1,587.