It's about time...
It's about time...
Posted Aug 4, 2005 3:41 UTC (Thu) by jabby (guest, #2648)Parent article: Our bloat problem
It's about time someone started making more noise about the bloat on the Linux desktop. It's sad when non-profits who can't afford newer computers to run a Microsoft OS more recent than Win98 look to Linux to reuse their older hardware and I have to tell them "Well, theoretically you can, but..."
Even after setting up LTSP on a reasonably powerful machine, it can only power about 4-5 terminals with KDE or GNOME and Firefox before the RAM on the LTSP server is exhausted. And LTSP is less than ideal because sound and local removable storage don't really work, yet (at least I couldn't get them working).
This is a sad commentary on the supposedly inclusive nature of Linux. Even though we all have access to the code, no one is spending time so that we can *all* run it!
Efforts like the RULE Project have sought to create streamlined installs of major distributions, choosing only lightweight apps and desktops. Other efforts include specialized distributions, which thereby isolate the user into a smaller, niche community. Both approaches can be successful, but the applications they use lack the depth of community support of their mainstream (bloated) cousins.
Nevertheless, these apps prove that the bloat is not necessary. Anyone who has used the ROX-Filer file manager knows that it is possible to write a GUI filemanager that runs blazingly fast on an old 586 box and uses very little of that precious RAM.
I agree with Jon's observation about the temporary rush for features to the detriment of performance. It is the bloated toolkits and all of the supporting libraries for the major desktops that have both allowed a sudden proliferation of apps and features as well as saddled those apps with unrealistic hardware requirements. My key example is KWrite. It's a simple text editor with a few extra features. It takes *seconds* to load on my 1GHz Athlon machine with 256MB of RAM. I can't imagine trying to use KDE 3.4 on a 586 with 32MB...
I like the suggestion in the first thread of creating a "bloat chart" so developers can measure and remedy their bloat. But I think developers and distribution maintainers really need to look at dependencies a lot closer and try to remove as many as possible. Rather than linking to a library because it's there and you can, really evaluate the trade-off between the functionality you're getting and the bloat you're dragging along to get it. If jg is right and most of those libraries don't need to be loaded, then breaking those false dependencies would go a long way toward solving the immediate logjam.
Posted Aug 4, 2005 4:36 UTC (Thu)
by hp (guest, #5220)
[Link] (6 responses)
http://www.joelonsoftware.com/news/20020407.html
Solid element of truth there.
Posted Aug 4, 2005 5:09 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (3 responses)
Posted Aug 4, 2005 5:53 UTC (Thu)
by hp (guest, #5220)
[Link]
Posted Aug 12, 2005 15:55 UTC (Fri)
by astrophoenix (guest, #13528)
[Link]
Posted Aug 12, 2005 23:28 UTC (Fri)
by obi (guest, #5784)
[Link]
(BTW Inkscape/GIMP start up in a fraction of the time needed for their commercial counterparts - which might have a bit more features, but I seriously doubt a lot of people use them)
Just to mention that it's not all bad.
Posted Aug 4, 2005 16:37 UTC (Thu)
by GreyWizard (guest, #1026)
[Link]
Meanwhile I'm typing on a 1.7 GHz laptop with 1GB of RAM where FC4 is quite snappy providing innumerable features I've come to think of as essential. Going back to RedHat 6 is simply not an option, even supposing it could be tricked into supporting the internal wireless card. Doing more with less is a worthy goal and I would be thrilled if some genius worked magic that made my iMac useful again, but until then I vote for bloat.
Posted Aug 4, 2005 20:47 UTC (Thu)
by jrigg (guest, #30848)
[Link]
I tried KDE recently after using WindowMaker and rxvt for the last few years. It was irritatingly slow even on a dual Opteron, so I reverted to my old setup. Maybe I'm impatient, but I prefer the speed of lightweight apps running on fast hardware.
Posted Aug 4, 2005 6:55 UTC (Thu)
by NAR (subscriber, #1313)
[Link] (2 responses)
As far as I remember, KDE was never a lean fast software, even the 1.0 version was considered to be a slow memory hog, so it's not surprising at all that it's still a bloat. Fortunately it's not compulsory to use KDE - on my desktop I have 512 MB RAM and it's very rarely swapping, if at all.
Posted Aug 4, 2005 11:20 UTC (Thu)
by pointwood (guest, #2814)
[Link] (1 responses)
I'm just a user, not a KDE developer, so won't claim to know much about the issue, however I do know that it is an issue the KDE developers have been working on for quite some time and if I recall correctly, the current KDE 3.X releases doesn't really use more memory than KDE 2 did, even though it provides a lot more.
I did a little google search and found these items as proof that the KDE developers are very much aware of this and continue to work on making KDE use as few ressources as possible:
I'm sure there are KDE developers that are reading LWN, so I I hope they'll chime in sooner or later with more accurate info about the work that's been done and is still going on.
Posted Aug 4, 2005 13:44 UTC (Thu)
by NAR (subscriber, #1313)
[Link]
I'm aware of this - I seem to remember that when KDE2 was released, the application startup was supposed to be faster in KDE2 than KDE1. Unfortunately my experience showed that KDE2 was slower than KDE1 because of the memory usage. I think this is really a feature issue: I use Opera and Firefox on both Linux and Windows and the Windows versions didn't seem to be faster.
Posted Aug 4, 2005 15:35 UTC (Thu)
by cdmiller (guest, #2813)
[Link]
Posted Aug 4, 2005 17:11 UTC (Thu)
by sbergman27 (guest, #10767)
[Link]
I have a client that has a 1266MHz PIII w/1GB running Fedora Core 2 which runs 16+ terminals, 8 of which are remote and use Xvnc making them much heavier since a virtual X server has to run on the FC2 box, plus 70+ telnet sessions of a curses based point of sale/accounting package that they use, plus a web server and postgresql database server. (The web and db servers are lightly loaded.)
It runs Gnome 2.6 and OpenOffice and does just fine.
To be honest, we did up it to 2GB recently, but that was more of a luxury than a necessity.
I just checked and with the 2GB, disk buffers (cache+buffer) is 783MB, with 64MB in swap and 48M free.
Posted Aug 12, 2005 13:55 UTC (Fri)
by ringerc (subscriber, #3071)
[Link]
OO.o, firefox, and Evolution, however, are lethal. Evolution in particular uses awe-inspiring amounts of RAM when working with large IMAP mailboxes. I've clocked it at > 250MB.
GNOME doesn't seem to be too bad with RAM use either. It looks a lot like the real issue is the apps.
It's significant that most people don't _use_ the "lightweight" apps, though, unless they really genuinely don't have the compute power.It's about time...
http://www.joelonsoftware.com/articles/fog0000000020.html
Unfortunately, we lack lightweight apps that can deal with Microsoft file formats.
It's about time...
Not sure you could have them - the MS file formats require all the MS application features. The hard part of implementing the formats is coding the features that use the stuff in the file.It's about time...
my friend was writing her Ph.D. dissertation in microsoft word. now that she has to get it formatted
to pass the university, I'm helping her convert it to LaTeX (we found a LaTeX class for her university
to handle the formatting). the first step was to filter the .doc through
antiword, producing a nice ascii file. even the
tables came out nice. her 400 page .doc file was converted to ascii so fast that I wasn't sure it
worked at first!
anti-bloating microsoft docs
Well, unlike OpenOffice Abiword and Gnumeric feel very light. Opening an Excel file in Gnumeric has _never_ failed for me (in my personal experience, 100% compatible - maybe I haven't used difficult documents enough), and on my 800mhz machine startup is nearly instant. Abiword is a bit less compatible with Word than I'd like it to be, but it's definitely usable, produces very nice output in XHTML, is kept simple - nice!It's about time...
On my desk I have an old iMac from 1999 with 32MB of RAM. Last week I tried to install Fedora Core 4 to on the poor thing, only to discover that it took thirty seconds from the time I moved the mouse to the time anything happened on the screen. That was just in anaconda (the installation program)! I'll have to try again in text mode when I get the chance, but I doubt I'll be running Firefox on that machine.Exactly Right
>It's significant that most people don't It's about time...
>_use_ the "lightweight" apps, though,
>unless they really genuinely don't
>have the compute power.
it can only power about 4-5 terminals with KDE or GNOME and Firefox before the RAM on the LTSP server is exhausted
It's about time...
Since KDE is a desktop environment, it's not surprising that it is not as lightweight as a "simple" windowmanager. There is no such thing as a free lunch. KDE uses more memory because it provides you with a helluva lot more than a windowmanager does, but that doesn't mean KDE is bloated. KDE and bloat
http://aseigo.blogspot.com/2005/07/death-to-dualism-eye-c...
http://aseigo.blogspot.com/2004/10/konsole-vs-xterm-or-pr...
http://kdemyths.urbanlizard.com/viewMyth.php?mythID=24
http://kdemyths.urbanlizard.com/viewMyth.php?mythID=57
KDE developers are very much aware of this and continue to work on making KDE use as few ressources as possible
KDE and bloat
Most folks who run thin clients or LTSP use a lightweight window manager rather than gnome or kde.It's about time...
> Even after setting up LTSP on a reasonably powerful machine, it can only power about 4-5 terminals with KDE or GNOME and Firefox before the RAM on the LTSP server is exhausted.It's about time...
My experience with LTSP at work is that the KDE and XFCE desktops both use minimal RAM. KDE seems to use a scarily small amount of additional RAM per instance after the first one - good use of static read only data etc I suspect.LTSP