KDE2 Release Delayed One Week

Monday, 9 October 2000 | Numanee

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.

Comments:

Strong move by the KDE team - Mats Eriksson - 2000-10-09

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

Re: Strong move by the KDE team - Frank Hellmuth - 2000-10-10

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. Frank

Re: Strong move by the KDE team - Agree - 2000-10-11

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. /jarek

but does it run on a pentium? - Navindra Umanee - 2000-10-09

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.) Cheers, Navin.

Re: but does it run on a pentium? - Martijn Klingens - 2000-10-09

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

Re: but does it run on a pentium? - AArthur - 2000-10-09

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.

Re: but does it run on a pentium? - Navindra Umanee - 2000-10-09

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. Cheers, Navin.

Re: but does it run on a pentium? - Martijn Klingens - 2000-10-10

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

Re: but does it run on a pentium? - Rikard Anglerud - 2000-10-09

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

Re: but does it run on a pentium? - Lawnman - 2000-10-10

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.

Re: but does it run on a pentium? - fura - 2000-10-10

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.

Qt-Exceptions, was: Re: but does it run on a pe... - Thrax - 2000-10-10

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?

Re: Qt-Exceptions, was: Re: but does it run on a pe... - fura - 2000-10-10

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.

Re: Qt-Exceptions, was: Re: but does it run on a p - Mats Eriksson - 2000-10-10

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?

Re: Qt-Exceptions, was: Re: but does it run on a p - fura - 2000-10-10

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).

Re: Qt-Exceptions, was: Re: but does it run on a p - Leif - 2000-10-10

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.

Re: Qt-Exceptions, was: Re: but does it run on a p - Phator Que - 2000-10-10

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

Re: Qt-Exceptions, was: Re: but does it run on a p - Phator Que - 2000-10-11

Still waiting...

Re: Qt-Exceptions, was: Re: but does it run on a p - David Faure - 2000-10-12

I heard that Qt 2.2.2 will come with exceptions disabled.

Re: Qt-Exceptions, was: Re: but does it run on a p - Inoshiro - 2000-10-12

"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 <a href="http://www.slackware.com">Slackware</a> builds the libraries correctly. <tt>-rwxr-xr-x 1 root root 5737500 Jun 4 13:25 libqt.so.2.1.1*</tt> 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. :-)

Re: Qt-Exceptions, was: Re: but does it run on a p - rhd - 2000-10-13

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)

Re: Qt-Exceptions, was: Re: but does it run on a pe... - Martijn Klingens - 2000-10-10

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

Re: Qt-Exceptions, was: Re: but does it run on a pe... - Michael S Czeiszperger - 2000-10-12

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?

Re: Qt-Exceptions, was: Re: but does it run on a p - Wilke Havinga - 2000-10-14

Exceptions tend to create quite a performance hit, both in code size and speed. Take a look at this <A href="http://www.javaworld.com/javaworld/jw-04-1997/optimize/Benchmark_Results.html">Java benchmark</A> 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...

Re: Qt-Exceptions, was: Re: but does it run on a p - Michael Czeiszperger - 2000-10-16

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?

Re: Qt-Exceptions, was: Re: but does it run on a p - S. Loisel - 2000-10-24

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.

Re: Qt-Exceptions, was: Re: but does it run on a p - Foogle - 2000-10-24

"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.

Re: Qt-Exceptions, was: Re: but does it run on a pe... - anand - 2004-03-27

i got error while executing make command in qt for ex : qmake simple-dialog.pro then make command it is giving error as undefined reference to 'main' please let me know the solution of the above problem.. thank u

Re: but does it run on a pentium? - d721970 - 2000-10-11

THANK YOU!! 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, Dave

Educating package makers - Shai - 2000-10-11

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?

Re: Educating package makers - Phator Que - 2000-10-11

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

Re: KDE2 Release Delayed One Week - Christian A Strømmen [Number1/NumeroUno] - 2000-10-09

Great! :) KDE2 is not finished yet, there's still a lot of bugs that needs to be removed... :) This was a smart decision!

Re: KDE2 Release Delayed One Week - jorge - 2000-10-09

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...

Re: KDE2 Release Delayed One Week - Sven Niedner - 2000-10-09

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, Sven 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 deadlines!

Re: KDE2 Release Delayed One Week - Navindra Umanee - 2000-10-09

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. Cheers, Navin.

Re: KDE2 Release Delayed One Week - Sven Niedner - 2000-10-10

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.)

Re: KDE2 Release Delayed One Week - Massimo - 2000-10-09

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.

Re: KDE2 Release Delayed One Week - J. J. Ramsey - 2000-10-10

"But is there any stress test application to crash proof the api and functionality ?" Yeah, lots and lots of users. :-)

Re: KDE2 Release Delayed One Week - Reza Prime - 2000-10-10

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

There are plenty of test tools on Unix - Abs - 2000-10-10

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 !!

Re: KDE2 Release Delayed One Week - Manuel Román - 2000-10-09

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

Gee what a lot of precise "bug reports" - AC - 2000-10-10

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.

Wrong URL - AC - 2000-10-10

It should be something under: http://ftp.de.kde.org/pub/KDE/unstable/distribution/

Re: Wrong URL - Navindra Umanee - 2000-10-10

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

FreeBSD Packages? - benmhall - 2000-10-10

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?) Thanks, Ben

Re: KDE2 Release Delayed One Week - Smári P. McCartyh - 2000-10-10

Thank god. I can sleep well now ;)

Slooooooow - Anonymous - 2000-10-10

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.

Re: Slooooooow - fura - 2000-10-10

Please, read another thread about exception handling code.

Re: Slooooooow - Andreas Joseph Krogh - 2000-10-10

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. -- Andreas

Not true - Anonymous - 2000-10-11

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.

Re: Slooooooow - Manuel Zamora - 2000-10-10

Hey, you're right! I tried to run KDE2 as my all-day-working environment. It is stable enough for that task, but it is SO SLOW on my machine (P200MMX with 48 megs of RAM). On my machine in the office with 128 Megs and 450Mhz it's still really slower than KDE1 and GNOME. Is there any clue to improve speed or do i have to invest some money into RAM? cu Manuel

Re: Slooooooow - Rinse - 2000-10-11

Hmm, one thing that makes the KDE2 beta's slow is the debugging code... Does your version of KDE2 use include debugging?? Rinse

Re: Slooooooow - Manuel Zamora - 2000-10-11

I am not a coder --- I used the official binaries. Do they include debug-code? How do I "strip" the debug-code from the sources? Is there any ./configure - option? Manuel

Get rid of debug code! - ac - 2000-10-11

"./configure --disable-debug" is a must! You might also want --enable-final!

Re: Get rid of debug code! - hanh - 2003-04-29

this debuging thing is really on my nerves and sometimes it kick me off the internet while I was in a middle of something.Somethimes it Ican't do nothing about it that I need to get off the internet.I want this to stop as soon asI can find out a way.please help me!

Re: Get rid of debug code! - anthony william glean zielke - 2006-01-15

i got told that i had to reformat my computer but i dont no hot to do i am only 15 years old

Re: Slooooooow - Thierry GRAUSS - 2000-10-11

If you don't want to recompile KDE, try a 'strip' Type "man strip" to know more about it. Oh, and be carreful, do not use it when KDE runs as it could crashs KDE, ... and have some very bad consequences on the whole system. You can use this command to strip all the a.out and elf binaries (Imagine the glibc, before strip : 87MB, and after strip : 16MB :))) but DO IT ONLY FROM A RESCUE DISK WHERE EVERYTHINK IS LOADED IN A RAMDISK AND NOTHING FROM THE SYSTEM TO STRIP WAS LOADED!!!! I had bad experiences, because I didnt do it :((

Re: Slooooooow - fura - 2000-10-11

You don't need to invest into RAM. Simply you should not get precompiled binary packages (as packagers are plain stupid), but grab the source of Qt and KDE2 and build it yourself with exception handling disabled. Please, read the thread about Qt exceptions, to find instructions how to do a correct build .

Re: Slooooooow - Manuel Zamora - 2000-10-11

Thanx! Will try that. Manuel

KDE2.0-rc2 rpms for redhat 7.0 - edscott wilson garcia - 2000-10-11

OK, I have been trying for days to compile the current snapshots on redhat 7.0 only to find that the distribution gcc is a "development" version and that I should use gcc 2.95.2. But this gcc won't compile the c++ libraries because it is "incompatible" with the glibc shipped with redhat 7.0 (2.1.94 as I write). How did you manage to compile the 2.0r2.rpm's for redhat-7.0? I am intrigued.