Mini KDE for a Lightweight Desktop

Do you need a memory hog of a desktop environment simply to run a few essential programs? This experiment says you might not.
Preparation

First of all, I cleaned up my computer running Fedora Core 3. Partly, this was done to make some extra room, but the main reason was to build the packages in a clean environment. After some checking and thinking, I removed the following packages, which I originally had installed from Fedora Core or KDE/Red Hat repositories: kdeedu, kdeartwork, KOffice, kdesdk, kdevelop, kdepim, kde, kdebase, kdelibs and kdelibs-devel.

Here's the other reason to perform such trimming exercises: you can learn a lot about how packages relate to one another. Specifically, you discover unneeded dependencies and packaging errors that remain hidden when distributions simply bundle software together without paying attention. For example, I learned that, at least on Fedora, I couldn't remove redhat-menus-3.7.1-3.4.3.kde, because it is needed by apparently unrelated stuff, including htmlview, gnome-vfs, openoffice.org-1.1.2, Evolution, XMMS and Nautilus.

The same happened with arts, the modularized sound system for KDE, and its development complement, arts-devel. Users of older desktops certainly are able to survive, even when they have a sound card, without acoustic effects. However, those two packages are needed by many more applications, including gstreamer plugins, gnome-applets, Evolution and so on. Some of these dependencies do make sense once you find them, but others still make me wonder. In any case, there seems to be a lot of opportunities for space savings at this level.

After cleaning my hard disk, I installed the latest stable source RPMs of kdelibs, kdebase, kdepim and KOffice from apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable. When I started, they were:

  • kdebase-3.4.1-1.0.kde.src.rpm

  • kdelibs-3.4.1-1.0.kde.src.rpm

  • kdepim-3.4.1-1.1.kde.src.rpm

  • koffice-1.3.5-3.0.kde.src.rpm

I chose the KDE for Red Hat Project instead of official Fedora Core packages, because I find them more polished than the standard ones. They also usually offer newer versions of the packages.

How I Did It

When you install a source RPM, you get all of the source code in a .tar.bz2 archive and the instructions to build everything in a .spec file. Normally, to build the package, you need to issue only the command:


rpmbuild -ba <package_name>.spec

To reduce disk space, I basically did two things, both relatively simple even for nonprogrammers. The first was to massage the compile and installation options in the .spec files. For example, I compiled everything without sound, adding -without-arts to the configure section. When available, I also added similar options to ignore other multimedia libraries or support for devices such as cell phones and PDAs. Then, I commented out all the Require and BuildRequires directives that check whether libraries for audio, video and modern peripherals are available before starting the process. I also removed the Provides directives for all the binaries I left out. Finally, I commented out the instructions that pack into the binary RPM files that I had not compiled or didn't need.

My complete .spec files are available in the Mini KDE section of the RULE Web site.

The second and most important trick was to insert a proper inst-apps file inside each KDE source tarball. It turns out that the configure scripts of these programs have a section that more or less says something like this (from kdelibs):

ac_topsubdirs=
if test -s $srcdir/inst-apps; then
  ac_topsubdirs="`cat $srcdir/inst-apps`"
elif test -s $srcdir/subdirs; then
  ac_topsubdirs="`cat $srcdir/subdirs`"
fi

$ac_topsubdirs is the list of all the subdirectories whose code must be compiled and installed. By default, this variable is loaded with everything written in the subdirs file. But, if you copy subdirs into inst-apps, remove from the latter all the unneeded items and then tar and compress everything again, only the applications you want are compiled. This also works when installing directly from source.

Generally speaking, to figure out what you could or could not remove from inst-apps, look at the README file in each subdirectory. The following is a short summary of what I did for each package.

kdelibs

I removed only the following items: arts, kdoctools, kate, libkscreensaver and doc. In the %configure section, I excluded xinerama, alsa and artsd support. I also commented out the Requires: arts directive, as well as those for jasper and openexr.

______________________

Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

can you provide the mini kde

Anonymous's picture

can you provide the mini kde binary files for download??

vexed by daemons

box opener's picture

so we're talking about saving a few mb of diskspace here?

i'd love to know how to use a KDE app without the intractible 'lag' feeling which occurs on even modern machines, probably due to all the layers of abstraction built up ..first libc, then xlib, then qt, then kdelibs, then the app.. the feeling is similar to running OSX on my G3, and my G3 is a lot slower..

or how to use a KDE app without having to twiddle your thumbs for 30 seconds while waiting for a gravy-train of daemons to startup like kdeinit, kded, kcminit, klauncher, dcopserver, arts, ksmserver, knotify,etc.. it rains on the parade of otherwise-nice apps like konqueror or amarok in a dreadful way.

the problem seems to have been compounded with the move to 64bit, the sheer number of pointers means reading thru a hundred or two mb of libs which on a laptop hd is arduous torture at best.

its just funny to see apps written in "slow" scripting languages like TCL/Tk startup instantly and behave just as reponsively as those in "fast" C++, just due to the sheer number of abstractions that had to be built on top of C to be able to easily build usable/flexible apps like those of KDE..

So what do you recommend ..

Anonymous's picture

So what do you recommend .. ???

Speedup KDE

Anonymous's picture

Use Prelink it greatly speeds up KDE startup and application loading.

http://www.linuxforum.com/man/prelink.8.php

I use it and it halves the startup time.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix