[TAG] please share your experience

[Jimmy O'Regan]

Thomas Adam wrote:

> --- "J.Bakshi" <hizibizi at spymac.com> wrote:
> 
>>don't go for a H/W up-gradation frequently. I used my first
>>self-assembled PC for roughly 10 years. KDE  becomes gradually more
>>hungry as a result fatty too -:) . so it may happen that KDE makes
>>your 2/3 years old H/W ( cpu, RAM) obsolete . and then you may fell
>>switching over to other small and fast WM to continue with your
>>existing H/W. only KDE themselves allow you to continue with KDE by
> 
> 
> Well, yes.  My own opinion is that you shouldn't have to upgrade your
> PC from a few years ago, to satisfy the working of KDE (or some other
> application.)  If it is programmed well, then it ought to handle
> lower-end system just fine.  I suspect it's a trade-off though between
> users wanting more features, and the fact that the developers of KDE
> themselves have a lot of new shiny hardware, such that they're not
> aware of the slowness issues on older hardware.

"The trend in desktops, across all operating systems has been to 
continuously add features and graphics with each new release. 
Unfortunately, cool icons, animation and complicated multi-paned 
desktops have usually required increasingly capable machinery. For 
various reasons, Linux desktops seemed to have suffered less from this 
performance crunching bloat than other packages, such as Windows XP.

KDE 3.1 has actually reversed the trend. To prove my point, I loaded it 
on an antique 133 Mhz. Pentium desktop machine. The box had 128 MB of 
RAM, 256K of L2 cache, a 2.5 GB disk and Debian. Even though KDE took 
about two and 1/2 minutes to load, most of the programs, menus, icons 
and animations seemed to appear almost instantly and ran without a hitch."

http://www.linuxplanet.com/linuxplanet/reviews/4676/1/

KDE developers *do* know about the slowness of KDE. Heck, back in 2001 
Waldo Bastian wrote this paper 
(http://www.suse.de/~bastian/Export/linking.txt) about part of the 
reason behind it (ld.so isn't great at resolving C++ symbols) and wrote 
a module for KDE to work around it 
(http://webcvs.kde.org/kdelibs/kinit/). Michael Meeks is currently doing 
similar scary things with OpenOffice:
"Spent some time examining C++ symbol table creation in some detail; 
slightly amazed to see the amazing C++ vtable construction inefficiency 
in terms of bulk of symbols; GObject for all it's failings is extremely 
symbol efficient in that way."
(http://www.gnome.org/~michael/activity-to-2004-06.html)