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.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState