KDE2 Release Delayed One Week

Due to the popular sentiment that KDE 2.0 is not quite ready for prime time, Matthias Elter, the release coordinator, has announced that a second release candidate is being prepared. RC2 will undergo scrutiny and testing by developers and packagers alike so that those final showstoppers can be found and squashed. KDE 2.0 final tarballs have been delayed one week and are now scheduled to be released to packagers on the 16th, with a public release of the packages on October 23rd. Update 10/9 3:15 PM by D: We've received word from Matthias that the RC2 tarballs will be released tomorrow, Oct. 10, on the KDE ftp servers, most likely here. Stay tuned -- we'll give you the details when we get them.

Dot Categories: 


by Mats Eriksson (not verified)

Good descition by the KDE team to delay the release date instead of releasing unfinished software.

by Frank Hellmuth (not verified)

I guess there will be a lot of reviews in computer mags covering KDE2, esp. after all this gnome foundation stories, many of them will read like a contest between them. A buggy release *now* will do bad harm to KDEs reputation.

And for future releases: Spread the beta releases
wider, CVS is a good thing for active devolpers, but there should be an easier way for interested users to get a preview. Maybe there should be something like a monthly "Linux for real man" CD
containing the latest snapshots of the kernel, KDE, gnome, gimp, ... but that's another topic.


by Agree (not verified)

Indeed. Have been following KDE snapshots for more that 6 month (almost daily) and recent snaphots are worse than those released roughly around 12 September. I guess this depends on which apps you are using but khtml is not going entirely forward right now. It's fast but fonts are all f...ed up.


by Navindra Umanee (not verified)

KDE2 was ready for me, personally, when I got the latest debs working just fine on my P120 w/ 32M of RAM + crappy harddrive. ;) I use it as my everyday desktop on that machine now. Previously I had been switching back and forth between KDE 1.1.2 and Fvwm2.

It's handy having such a machine around... makes a good benchmark. hristo doichvev, you listening? Didn't get your email address... :)

(I have been using KDE2 for months on my Celery 400 w/ 64M, of course.)


by Martijn Klingens (not verified)

You mean KDE2 has reasonable performance with 32Mb?

I'm typing this on a 64Mb machine using KDE 1.94 (i.e. not RC1) and it is not all that fast.

At home KDE2 runs just great with >128Mb memory, but with this 64 Mb machine I can't but wonder who would run KDE2 with even less memory.

Cheers, Martijn

by AArthur (not verified)

I'm running KDE 2 (since August 31) as my primary Desktop Enviroment. It's good. It runs fairly well on 32 MB of RAM, at least on my PowerMac 4400/200. Some apps are still sluggish, but it's apparent it's getting better, as everytime I get new debs of it, apps keep launching faster, and in general it runs smoother. While having tones of RAM is cool, it's not at all neccessary to run KDE 2.

Except for slower app launch times (which are improving all the time), KDE 2 is as fast as KDE 1.1.2 on this machine.

by Navindra Umanee (not verified)

Yes, it does. It's a 8-bit color crappy video card too. It takes a while initially to load (about the same as KDE 1.1.2) but once loaded I get reasonable performance and speed (about the same or better than KDE 1.1.2). Enough to show off the various styles and themes and Konqueror. ;) I do have swap, though. About 10-14M of it is used initially, if I recall correctly. What's cool is that with konsole, I don't need tons of xterms/rxvts open anymore.

I've been running KDE2 for months on my Celery 400 w/64M and I'm a bit puzzled about your impressions of slowness. How does it compare to KDE 1.1.2? Hmmm, I should benchmark the two.


by Martijn Klingens (not verified)

Maybe it's because I'm running my server apps on my 'old' machine, so the slugginess may be my own fault.
But even if I close them for a while it's no fun to have multiple web pages open or some KOffice documents on a 64Mb box.

Anyway, I haven't seen Linux with X perform even close to Windows 9x on 64Mb machines. Personally I don't care, because Linux is more stable, but many novice users don't. Also, it's the novices who are the majority of the 64Mb users and the novices at who KDE2 is targeted.
I can only hope that the RCx and the final versions of KDE2 are better in that respect as my 1.94 version.

Cheers, Martijn

by Rikard Anglerud (not verified)

Well, I'm running it on a P200 w64Mb RAM, and it feels significantly slower than 1.1.2.

by Lawnman (not verified)

It was a real sloth on my Toshiba laptop. P100 w/32RAM. EVERYTHING took a long time to load and screen redraws were painful. Of course that was due more to a low performance graphics card. I ended up taking it off and going back to 1.1.2.

by fura (not verified)

If you want to to have reasonable perfomance, you _must_ compile Qt with exception handling disabled (it's enabled by default). Add -fno-exceptions flag to CXXFLAGS.

Is disableing the Qt-exceptions really a good idea? IMHO the exception-handling was bulit into Qt for some reason. May turning off the exceptions affect stability?

It has nothing to do with stability, but reduces memory usage a _lot_ (think about megabytes per single runing application).

That was the reason, why KDE 1.x.x is known as slow and bloated - developers didn't care a lot, and distributors were stupid enough to build both Qt and all of the KDE with exception handling enabled which made KDE unusable on boxes with less that 64MB of RAM. Cleverly built KDE1 runs great with 32MB of RAM ( actually I used KDE1 a lot on 486/24Mb box - worked perfectly). But you won't get correctly precompiled packages anyware - the only way is to grab the source and build it yourself.

The same applies to KDE2 - if you want to feel the real power of KDE2 - build it (and Qt) from the source, and do it correctly.

by Mats Eriksson (not verified)

Anyone knows if the Mandrake packages (KDE and Qt) are compiled with exceptions disabled?

If not, how do I compile KDE and Qt with exceptions disabled?

KDE2 is built with exception handling disabled by default (luckily), only khtml library, which uses exceptions is built with enabled exception handling, at least in theory. But I had problems when building shanpshots, and had to disable exception handling "by force" (on Bourne shell):

CXXFLAGS='-O2 -fno-exceptions' ./configure

Talking about Qt - it's very easy to see if Qt is compiled corectly simply checking the file size of the library. On my FreeBSD/i386 box file size of libqt.so.2.2.0 is ~5MB (thats with libpng and other stuff built in IIRC). If the size is more like 10MB, than you need to rebuild Qt (these numbers are for i386, libqt on Alphas should be much bigger ;-) ). The difference is ~5MB and most of these 5MB is _unshared_ and _unused_ code. So, with every KDE app runing you'll waste ~5MB of memory. If you run 10 applications, you waste 50MB.

To fix this nonsense,
open $QTDIR/configs/linux-g++-shared (or freebsd-g++-shared or whatever you use) with text editor and add "-fno-exceptions" to SYSCONF-CXXFLAGS. Then ./configure and make.

That's very easy and gives huge usability boost.
Rebuilt Qt should be even binary compatible (no need to rebuild apps depending on it).

This really gave my box(pp200 96m) a boast.
Before kde2 were slow unresponsive, kinda useless.

took 10 - 15 seconds to start kword now i takes 2.
I Compiled with pgcc-2.95.2
and added flags -mpentiumpro -fno-execptions to qt.

Sounds interesting. Does the KDE team have any response to this?

Still waiting...

I heard that Qt 2.2.2 will come with exceptions disabled.

"On my FreeBSD/i386 box file size of libqt.so.2.2.0 is ~5MB (thats with libpng and other stuff built in IIRC)."

Great, that means Slackware builds the libraries correctly.

-rwxr-xr-x 1 root root 5737500 Jun 4 13:25 libqt.so.2.1.1*

That's from the qt-2.1.1 package in the contrib dir for Slackware. I'm assuming the 1.4.4 with KDE1 is also built correctly, as KDE 1 in Slackware has always been nice and fast for me. I guess some distributions do get it right, because they care about speed and stability. :-)

Anyone else find -O2 on xml/qxml.cpp made the compiler think for three minutes then finally die with an assembler error? I compiled that one module by hand without -O2; hopefully that won't be a big hit. (LinuxPPC 2000 + Helix GNOME 1.2, G4/400)

by Martijn Klingens (not verified)

That explains a lot to me!

I don't like to compile each and every program I use, so I normally stick with binary rpm or tar files when they are available.

I guess that's the reason that both KDE 1 and 2 run sluggish on low-memory configurations...

Thanks, Martijn

by Michael S Czeis... (not verified)

In a C++ program the usual way of handling error conditions is through exceptions. Unless KDE is written in a very unusual way, no exceptions means no error handling, just crashes.

If KDE doesn't use exceptions to handle errors, what does it use?

by Wilke Havinga (not verified)

Exceptions tend to create quite a performance hit, both in code size and speed.

Take a look at this Java benchmark for example. Good, taken your point that Java isn't C++, I guess it says something about exceptions (those guys at Sun aren't that stupid, right?)

So I guess it must have to do with the idea of exceptions, not only with a crappy implementation.

Other methods to handle problems exist, like for example those often used in plain C. Examples are: returning error codes, solving the problem at the place where it occurs (not always possible) or setting global error flags. Whatever you like...

by Michael Czeiszperger (not verified)

C++ extensions when they are thrown are slower than just normal code, which is why you just use them for errors. In my 12 years of using profilers with C++, I've never seen a speed increase just by turning off exceptions.

The way you're supposed to deal with exceptions and performance, is to not use them critical performance areas. Since the events that trigger exceptions are supposed to be "exceptional", this isn't problem. Exceptions are only supposed to be thrown when there's an error, so there isn't a performance problem.

All this being said, the reason I posted was that if the program is written as a modern C++ program, it definitely will use exceptions for error handling, so what happens to error handling when you turn off extensions?

Actually, "new" can throw an exception if it runs out of memory. Many people consider that "new" can be called in a performance critical section.

"Performance-critical" sections are usually segments of code that are being called repeatedly. One of the first things anyone should look at in code like this is whether or not they are allocating any new memory. When possible, a really optimized piece of code will not allocate any new memory, but re-use existing memory.

i got error while executing make command in qt

for ex :
qmake simple-dialog.pro


make command

it is giving error as

undefined reference to 'main'

please let me know the solution of the above problem..

thank u

by d721970 (not verified)


I was already thinking that KDE2 is nifty, but with the 25% - 50% speed boost that I got by following your post, I'm awestruck. On my old PII-300, it makes a world of difference. Now it really is better _and_ faster than KDE1 (and others).

Maybe this should be included in the build instructions on kde's website. I've also seen a lot of speed complaints on comp.windows.x.kde. Maybe a post there would be a good idea, if someone hasn't already done so (haven't checked in a while).

Thanks again,

by Shai (not verified)

This thread is very interesting. I tried to compile
KDE 2 myself but since my environment is so complex
it just didn't work. So I installed the RPM's.

It works fine on my computer but not great (I have
a duel PIII 500 with 256mb and Matrox G400).

My point is... Shouldn't the KDE PR team offer tips
for distribution vendors on how to build the package
correctly or possibly make the release builds into
the defaults?

by Phator Que (not verified)

...and get some information from the KDE team how the current packages are built...

by Christian A Str... (not verified)

Great! :)

KDE2 is not finished yet, there's still a lot of bugs that needs to be removed... :)

This was a smart decision!

by jorge (not verified)

I agree 100% on the decision to hold it back a week. It's stable for me, but I'd rather be safe than sorry. One of the things I love about KDE is the "when it's done" attitude, an embarrasing but in KDE2 would be really bad...

by Sven Niedner (not verified)

I really appreciate this decision -- I am currently using the acutal CVS version
and it is really great and stable. However, some of the functionality is flawed.
When you use it on a daily basis, you get used to it and feel that it is "acceptable",
but in fact -- it isn´t. I think this is a clever decision not because actually KDE2
is not stable, but just because it is so stable that every single error has the potential
to spoil the impression.

So I encourage every developer to finish their great work and fix the last bugs...

... looking forward to the release,


PS: Never mind... have a look at the kernel... they are delayed, too, and for good
reasons as well. Thank god we're not in the corporate world and don't have no

by Navindra Umanee (not verified)

Well, KDE 2.0 is not the end of the line whatever happens. KDE2 will only be delayed for real show stoppers. No release can be perfect, no matter what users think or expect but things can only get better from there. ;)

Here's to more incremental releases, more early and more often and not another repeat of the KDE1->KDE2 transition phase.

Just MHO.


by Sven Niedner (not verified)

OK -- on the one hand, yes. But when there
are GUI elements that do not function as
promised, and when certain features do not
work reliably, we shouldn't even call it
a ".0"-release, but a beta. I have strong
feeling about keeping up the quality standards
of free software, where a beta is often more
stable than an off-the-shelf commercial
product. The KDE release should try not
to ruin this reputation.

(I admit that a complete GUI has more
possibilities for errors going undetected
than, say, a compiler or LaTeX, and it is
a relatively new project.)
So, my opinion: Fix the last bugs, IMHO there
are very few which are really important, and
then draw a line and ship. (However, drawing
a line becomes more difficult on larger
project - this was my remark on the Linux kernel.)

by Massimo (not verified)

i agree that decision too.

But is there any stress test application to crash proof the api and functionality ?

i mean a tool like in Winblows that make random calls to kde's api and log errors.

by J. J. Ramsey (not verified)

"But is there any stress test application to crash proof the api and functionality ?"

Yeah, lots and lots of users. :-)

by Reza Prime (not verified)

Sorry asking, but what are those tools and where I can get 'em?

but I bet they haven't been used too extensively. test frameworks like deja-gnu are old but for KDE probably some perl or pythong scripts could exercise things a bit :-)

I'd like to see KDE thrown throug purify and other commercial profiling tools etc. too.

As for the users being the testing tool - there haven't been enough of them. **Especially** for KOffice which has no documentation (the idea I guess is you just use MS Office and then switch over to the less stable and buggy KOffice and use the same "instinctive approach" or something). Sorry KOffice is a great project and all that and maybe in 5 years **if people use it** it will be solid and low on bugs and maybe even have good searchable manual etc.

The problem is not very many people are going to use it so many bugs will remain ... Emacs got so stable because a ton of motivated programmers used it alot. I'm not sure KOffice will get the same treatment (look at the gimp a 5 year old project barely out of verion 1.0 and not too polished).

The main thing KDE has going for it is Qt which is a *fantastic* and well documented piece of technology - kudos to Troll (too bad for me it's C++ which I hate :-P perhaps Troll could take over GNUStep or GTK now?). KDE is the best test of Qt there is around !!

by Manuel Román (not verified)


It's a great decision. Now, is very stable, but in some cases.... KDE 2 is a little crazy.

If the comments on this page are any indication I hope you people aren't filing bug reports. What exactly is "a little crazy", or "not finished" or "GUI elements that don't work"? Where?

If you *do* file bug reports try to be a little more accurate and precise.

by AC (not verified)
by Navindra Umanee (not verified)

Thanks, we'll fix it once there's an actual URL / public release. Packagers working on the binaries, as I understand it.


by benmhall (not verified)

I have noticed that my FreeBSD 1.94 machine has some bugs that the Mandrake 1.94 didn't have, does anyone know if there are newer binary packages for FreeBSD to test?

I've sent in a couple of bugs wrt 1.94 on BSD, and really want to help to make 2.0 run well on BSD...

(Alternatively, does anyone know how to make the 1.94 port work with newer builds?)



by Smári P. McCartyh (not verified)

Thank god.

I can sleep well now ;)

by Anonymous (not verified)

KDE 2 (including apps) runs *much* slower than KDE 1 or Gnome 1.2 on my machine (Pentium 166 MMX with 48 MB RAM)

I think it's a bit too integrated ;-)
All that DCOP stuff will only slow down things, and I really don't see why every KDE 2 app use DCOP.
Isn't it just a communication protocol like CORBA or something?
Why does an editor have to communicate with other programs?

BTW is there any way to disable the one-click-to-do-it-all "feature" ala Winblows 98?
I hate it.

by fura (not verified)

Please, read another thread about exception handling code.

by Andreas Joseph Krogh (not verified)

It doesn't, apps only use DCOP when communicating with other components. If you think DCOP is slow, have you tried programming with a CORBA ORB(probably not when making the statement above)? DCOP is _REALLY_ light-weighted.


by Anonymous (not verified)

Gnome's Bonobo components here are *much* faster than DCOP.
ORBit (Gnome's CORBA implementation) is also much faster than DCOP.
To my experience, they are 2 times faster than DCOP.

CORBA is not slow.
Or at least, the Gnome implementation is not slow.