[TAG] please share your experience
jimregan at o2.ie
Tue Sep 20 00:07:22 MSD 2005
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."
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."
More information about the TAG