Linux desktop comparison (pt. 3): Qt-based DEs

This is part 3 of our desktop testing series. We’ll deal with the 4 Qt-based desktop environments in this entry.

These are:

For test criteria and the basic Arch system, please refer to the first part of this test.

KDE Plasma

KDE was the first big Linux desktop project. In the beginning it was inspired by CDE (Common Desktop Environment), the classical Unix desktop. Depending on the at that time unfree Qt toolkit, many people stated that a free DE should rather be based on something else (This was in fact why the coding of GNOME begun). Qt was later released under the GPL so this is no longer an issue. KDE has become a heavy-weight DE in the meantime – it consists of a huge amount of applications and there’s probably nothing you would ever miss there. All these programs are coordinated so that they provide a assortative experience and feeling. Since KDE version 4 the whole project has been renamed to “KDE Software Compilation” and the former actual “K Desktop Environment” is now known as “Plasma Workspaces”. KDE has always tried to offer a visually appealing desktop. Many people also like it because it is multi-functional, very configurable and highly customizable. Others call it a classical example for unneccessary bloat.

The KDE Plasma desktop

Installation

pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions kdebase

Statistics

Memory usage right after starting up KDE Plasma (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + KDE Plasma (4.9.0)
MemTotal: 1030652 kb
MemFree: 650340 kb
Buffers: 18348 kb
Cached: 181256 kb
Rootfs: 2001712 / 2.0G
RAM used at startup: 380312 / ~371 MB
Disk space (less basic system): 1347424 / 1.3 GB

Razor-Qt

Razor-Qt is a rather young project with the aim to deliver a light-weight DE based upon the Qt toolkit. So far it is rather “bare bones”: it doesn’t come with a lot of its own applications (e.g. no default file manager!) or its own WM (Openbox is suggested). It just offers a simple, light-weight DE; nothing more and nothing less. It’s a bit like “LXDE on Qt” – in its early stages. Definitely a promising project!

The Razor-Qt desktop

Installation

pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions openbox
pacman -U razor-qt-0.4.1-3-i686.pkg.tar.xz

Statistics

Memory usage right after starting up Razor-Qt (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + Razor-Qt (0.4.1)
MemTotal: 1030652 kb
MemFree: 911849 kb
Buffers: 9724 kb
Cached: 58784 kb
Rootfs: 885320 / 865M
RAM used at startup: 118803 / ~116 MB
Disk space (less basic system): 231032 / 226 MB

Unity 2D

Unity2d is merely the “fallback mode” of the Unity UI on machines that do not provide hardware accelerated 3D graphics. Except for it being build upon Qt, it’s more or less the same thing without too many differences. It is more than questionable whether this desktop will continue to be developed in the future.

The Unity2D desktop

Installation

pacman -U freetype2-ubuntu-2.4.10-1-i686.pkg.tar.xz
pacman -U fontconfig-ubuntu-2.8.0-10-i686.pkg.tar.xz
pacman -U libxft-ubuntu-2.3.1-1-i686.pkg.tar.xz
pacman -U glew1.7-1.7.0-1-i686.pkg.tar.xz
pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions
Additional repository “unity”: http://unity.xe-xe.org/$arch
pacman -S $(pacman -Slq unity)

Statistics

Memory usage right after starting up Unity2D (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + Unity2D (6.0.0)
MemTotal: 1030652 kb
MemFree: 616580 kb
Buffers: 25884 kb
Cached: 163848 kb
Rootfs: 2862336 / 2,8G
RAM used at startup: 414072 / ~404 MB
Disk space (less basic system): 2208048 / 2,15 GB

Trinity DE

The Trinity DE is a fork of the former KDE series 3. Not everybody was happy with what Plasma is all about – not even every KDE user. Because of this some people have volunteered to continue development of KDE 3 under the name Trinity DE. The next version which is expected some time this fall should fix all incompatibilities so that KDE 4 and Trinity can be installed on the same machine. HAL will still be used in this version but will be replaced in the future. Quite some new features have been implemented since the latest 3.x release of KDE. Trinity DE is for KDE 3 what MATE is for GNOME 2: More than just a “keep-alive-project”! If you used KDE in the past but did not like the way that Plasma took, take a look at Trinity!

The Trinity desktop

Installation

Additional repo “tde3513”: http://archlinux.us.to/3.5.13/i686/
pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions tde-base

Statistics

Memory usage right after starting up Trinity (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + Trinity (3.5.13)
MemTotal: 1030652 kb
MemFree: 823912 kb
Buffers: 18272 kb
Cached: 97764 kb
Rootfs: 2720876 / 2.6G
RAM used at startup: 206740 / ~202 MB
Disk space (less basic system): 2066588 / 2.02 GB

Conclusion

The Qt-based DEs are quite a bit on the heavier side in terms of general RAM usage. Trinity is rather high and KDE Plasma even higher, just as one would expect. Only Razor-Qt is a lot more slim than the others and doing rather good. I guess, we don’t need to even talk about Unity2d and the demand of RAM…

What’s next?

The next entry will cover some of the less common desktop environments.

Advertisements

Linux desktop comparison (pt. 2): Traditional GTK+ DEs

This is part 2 of our desktop testing series. We’ll deal with 4 traditional gtk+-based desktop environments in this entry.

These are:

For test criteria and the basic Arch system, please refer to the first part of this test.

GNOME 3 Classic

GNOME 3 Classic – also called “fallback mode” – is a re-implantation of GNOME 3 resembling the “GNOME 2 way”. It offers the familiar panel instead of the shell. However it is not on an equal footing with the shell but really meant only for those machines which cannot run the later (most likely because of missing 3D acceleration). It’s not working exactly like GNOME 2 as there are a number of (mostly annoying) differences but it may be dropped anyway in the future.

The GNOME 3 Classic desktop

Installation

pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions gnome

Statistics

Memory usage right after starting up GNOME 3 Classic (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + GNOME 3 Classic (3.4.2)
MemTotal: 1030652 kb
MemFree: 804524 kb
Buffers: 15868 kb
Cached: 94984 kb
Rootfs: 1732056 / 1.7G
RAM used at startup: 226128 / ~221 MB
Disk space (less basic system): 1077768 / 1.1 GB

MATE desktop

The MATE desktop begun its life as a complete fork of the latest version of GNOME 2. Many people doubted (or continue to do so) if the project will last. While it started with one developer renaming all the applications (to avoid incompatibility with GNOME 2 and 3), in the meantime some people have joined the project, additional features have been added and with Linux MINT a big distribution has adopted it as one of its standard DEs. To just name one of the new features: Caja, the file manager (formerly Nautilus), now has an undo option available in the menu (this was actually something that I had been missing since I left the Windows world)!

The MATE desktop

Installation

Additional repo “mate”: http://repo.mate-desktop.org/archlinux/$arch
pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions mate

Statistics

Memory usage right after starting up MATE (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + MATE (1.4)
MemTotal: 1030652 kb
MemFree: 878688 kb
Buffers: 13536 kb
Cached: 58112 kb
Rootfs: 1348280 / 1.3G
RAM used at startup: 151964 / ~148 MB
Disk space (less basic system): 693992 / 678 MB

Xfce

Xfce started as a light-weight desktop environment but over time it has grown into a full DE. It’s still quite a bit lighter than GNOME/KDE, of course. But if you’re looking for something really light, Xfce may no longer be what you may want to install on your machine. If you however want a good compromise between a rather light-weight DE and great usability, give it a try. In some aspects it’s somewhat like a less bloated GNOME 2 but it’s going its own way in other cases.

The Xfce desktop

Installation

pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions xfce4

Statistics

Memory usage right after starting up Xfce (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + Xfce (4.10.0)
MemTotal: 1030652 kb
MemFree: 918092 kb
Buffers: 11388 kb
Cached: 49092 kb
Rootfs: 1226416 / 1.2G
RAM used at startup: 112560 / ~110 MB
Disk space (less basic system): 572128 / 559 MB

LXDE

LXDE is currently the most popular light-weight desktop environment available for Linux. It’s designed with low resource usage in mind and build completely modularly. If you just need some of the applications it consists of, you are encouraged to do so. It is in a rather early state, however, and people who are spoiled by a full-grown DE might miss quite some features which LXDE simply does not provide. Yet if you are not looking for something that is primarily appealing visually but just want a working DE with the basic functions – LXDE might well be your desktop environment of choice.

The LXDE desktop

Installation

pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions lxde

Statistics

Memory usage right after starting up Xfce (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + LXDE (0.5.x)
MemTotal: 1030652 kb
MemFree: 938660 kb
Buffers: 9744 kb
Cached: 41816 kb
Rootfs: 986260 / 963M
RAM used at startup: 91992 / ~90 MB
Disk space (less basic system): 331972 / 324 MB

Conclusion

Well, no surprise: These GTK+ based non-3D-desktops are generally quite a bit lower on system resources. While it shows that GNOME 3 Classic is not optimized in this regard, even the full-grown MATE does rather well in comparison. Xfce is yet a little lighter and LXDE the smallest DE so far.
I’ve dropped the “minimal RAM” thing this time as it is not of much use with these DEs. Each one can run actually with as little 32 MB – with heavy swapping of course. Like one would expect, GNOME 3 Classic is totally useless in this case while LXDE is a lot more responsive (but still far from being useful).

What’s next?

The next entry will cover the QT based desktop environments.

Linux desktop comparison (pt. 1): Modern GTK+ DEs

This is part 1 of our desktop testing series. We’ll deal with the 3 modern gtk+-based desktop environments in this entry.

These are:

Test criteria

I’m just going to fire up the desktop to see how many RAM is used at that time. No windows opened, no menu clicked. That means the value is the amount of RAM that the system has allocated on a 1 GB RAM virtual machine. When actually using the desktop, the needed amount of RAM will of course increase, often multiply.

I’ll also tell you the amount of space the DE takes up on the hard disk and, just for fun, test what the minimal amount of RAM is that the DE really needs just to start up. This value is not of much use actually, since the system will relay heavily on swapping then and even just starting the DE may literally take several minutes. Of course productive working is absolutely impossible under these circumstances.

Basic Arch system

I’m using a virtualbox VM that I’m cloning for each of the desktop tests so every one has the same base on which to build up.

Installation

Our basic test system is a clean Arch installation with only “basic” pacstrapped onto the new partition. No development tools are needed since I build a binary package for everything that is not on the repos on another virtual machine.

Memory usage right after booting up (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux 08/11 2012
MemTotal: 1030652 kb
MemFree: 992524 kb
Buffers: 5500 kb
Cached: 14988 kb
Rootfs: 654288 / 639M
RAM used at startup: 38128 / ~37 MB
Absolute RAM minimum to still boot: 27 MB

GNOME 3 Shell

The GNOME 3 Shell is the default interface of GNOME 3. It works entirely different from the old GNOME 2, bringing in “a new desktop metaphor”. The old panel is gone and instead GNOME 3 offers “activities”. While some people like the approach, there are a many former GNOME 2 users who state that they can’t work with a desktop like this. 3D graphics are obligatory for the Shell; on systems without it, a fallback mode is provided.

The GNOME 3 Shell desktop

Installation

pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions gnome

Statistics

Memory usage right after starting up GNOME 3 Shell (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + GNOME 3 (3.4.2)
MemTotal: 1030652 kb
MemFree: 773200 kb
Buffers: 14888 kb
Cached: 114584 kb
Rootfs: 1732056 / 1.7G
RAM used at startup: 257452 / ~251 MB
Disk space (less basic system): 1077768 / 1.1 GB
Absolute RAM minimum to still start up: 81 MB

GNOME 3 Cinnamon UI

Cinnamon is an alternative shell for GNOME 3. It was born when the developers of Linux MINT realized that GNOME was not going into the direction that they had in mind for their distribution. They started a project called “Mint Gnome Shell Extension” but soon realized that this did not give them enough control of how things developed. Then they decided to fork the GNOME Shell and this was the beginning of Cinnamon. It aims towards a more classical desktop metaphor.

The Cinnamon desktop

Installation

pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions
pacman -U gnome-menus2-3.0.1-1-i686.pkg.tar.xz
pacman -U muffin-wm-1.0.6-1-i686.pkg.tar.xz
pacman -U cinnamon-1.5.2-2-i686.pkg.tar.xz

Statistics

Memory usage right after starting up GNOME 3 Cinnamon UI (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + Cinnamon (1.5.2)
MemTotal: 1030652 kb
MemFree: 781996 kb
Buffers: 14936 kb
Cached: 107280 kb
Rootfs: 1620556 / 1.6G
RAM used at startup: 248656 / ~243 MB
Disk space (less basic system): 966268 / 1 GB
Absolute RAM minimum to still start up: 72 MB

GNOME 3 Unity UI

Unity is another alternative Shell for GNOME 3. It’s developed by Cannonical, the company that is famous (or infamous, depending on whom you ask) for Ubuntu Linux. It’s “going new ways” – and that shows. For fans of the classical desktop this one is a total mess whereas other people prefer to call it inovative. Anyways it’s the default desktop of Ubuntu since that is without any doubt a big distribution, it has a solid user base despite all objections towards it. It uses the rather uncommon nux toolkit. Unity is basically a Compiz-plugin and thus needs 3D graphics. A Unity-2D variant, build upon Qt also exists.

The Unity desktop

Installation

Unity is currently incompatible with glew1.8. Also I had to install the whole unity repo because just installing the basic unity package and its dependencies does not give me the full system (e.g. no menu to shut down in the upper right corner etc.).

Forbid updating of glew1.7
pacman -U freetype2-ubuntu-2.4.10-1-i686.pkg.tar.xz
pacman -U fontconfig-ubuntu-2.8.0-10-i686.pkg.tar.xz
pacman -U libxft-ubuntu-2.3.1-1-i686.pkg.tar.xz
pacman -U glew1.7-1.7.0-1-i686.pkg.tar.xz
pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions
Add additional repository “unity”: http://unity.xe-xe.org/$arch
Accept to uninstall and replace several conflicting packages in next step
pacman -S $(pacman -Slq unity)

Statistics

Memory usage right after starting up GNOME 3 Unity UI (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + Unity (6.0.0)
MemTotal: 1030652 kb
MemFree: 637268 kb
Buffers: 26052 kb
Cached: 148020 kb
Rootfs: 2862336 / 2.8G
RAM used at startup: 393384 / ~384 MB
Disk space (less basic system): 2208048 / 2,15 GB
Absolute RAM minimum to still start up: <64? MB

Conclusion

Like one would expect, the 3D desktops are quite a bit on the heavy side when it comes to their resource needs. It’s no surprise that the more traditional Cinnamon needs a little less RAM compared to the GNOME 3 Shell and that Unity needs by far the most. The needed disk space loses a little comparative value since with Unity I had to install the whole repo while for both Gnome 3 Shell and Cinnamon I just installed the full basic package.

In terms of absolute minimal RAM needed to launch I was quite surprised to find GNOME 3 Shell and Cinnamon as low as 81 and 72 MB! While they are far from usable with that little RAM, it was an interesting find (at least for me). While these two seem to check for a minimum of available RAM, Unity doesn’t seem to do such a thing and tries to start with however little RAM the system has, even though it takes minutes to load with 64 MB of RAM! I didn’t have the patience to try even lower values.

What’s next?

The next entry will cover the traditional GTK+ desktop environments.

Switching to… Arch Linux!


Alright, now it’s official: Project E.e.r.i.e. abandons Gentoo and switches to Arch!

Moving away from Gentoo

The biggest downside of Gentoo ist surely that you compile everything from source and it takes way to long to set up bigger programs like a desktop. Half a day for re-compiling your system with a new USE variable and emerging GNOME 3 is not at all an exaggeration. Even on modern multicore processors like the i7 of the system I run my tests on. Every Gentoo user knows the phenomena of “overnight-emerge” – meaning that you begin emerging before going to bed and have the computer work all night. Dependent on how long you sleep and on how big the program(s) you are merging is/are, it may be done when you wake up…

Also the problems I had with the portage tree lately were rather annoying and a pure waste of time. I’m about one month behind with the tests I wanted to publish here.

But of course there are quite a few strong points of Gentoo – I still like this distribution and thus don’t want to leave that unmentioned. Thanks to the USE variable and the complexity of the portage system, Gentoo’s flexibility is simply unique. There’s nothing that comes even close to it. Oh you don’t want the default version of your package? No problem! Just unmask a newer one and hope it works well, if you feel like it. Or mask the default one and portage will simply provide you with an older version! I got used to think this goes without saying, but of course this is not necessarily the case with other distributions – like Arch. Actually it is one of the things that will be painfully missed.

Arch Linux

Well, Arch Linux is a “simple, light-weight” distribution. Sounds nice, eh? Sure it does. You can have the default basic system with as little as about 650 MB of used space, which is pretty nice. Other than Gentoo, Arch uses binary packages by default. It does however provide a rather good buildsystem, too.

The repos are split into “core”, “extra” and “community”. And if something is not in there, there are additional custom repos, which you can add to your pacman.conf. Oh, and you can always have a look at the AUR, the Arch User Repository. It doesn’t provide binary packages, but there are thousands of PKGBUILD files there which contain the information on how to build a certain package (kind of similar to Gentoo’s ebuilds, but far less complicated). Thanks to the AUR there’s ton’s of programs available for Arch which are not in the official repos. However it is completely user-maintained so there are many PKGBUILDS which are outdated, buggy or even orphaned, no longer maintained by anybody. Still it’s a very nice thing to have!

First impression

Pheakuser suggested using Arch from the beginning. Well, it follows the rolling releases system, too, and when I first wanted to try it out (perhaps five to six weeks ago), just on that very day, it was broken due to a default driver switch. The new one was added as a dependency but the old one not yet removed – and so pacman wanted to install both of them. However they were conflicting packages… Fortunately Arch lets you select which packages from a group you actually want to install. So this problem is easily fixable from the users side. But it’s thinks like that which I really despise and what makes me think that fixed releases really are not such a bad thing…

Working with Arch

Anyway: I’m getting along with Arch pretty well already and did not encounter such a glitches again in the last few days. Just following the desktop tests I’m doing is probably giving you a good impression of what it’s like.

First I’ve installed GNOME 3 from the main repos. No problem at all. Next I’ve installed Cinnamon from the AUR. Working fine. Then I tried to install Unity. Well… Things got a lot more unpleasant here. The ArchWiki (a really great source of information) pointed me to the Ayatana custom Arch-repo. However this repo seems to be seriously broken. It provides a package for Unity (version 5.x) however lacks at least some of its dependencies! Alright looking for those in the AUR. Nope. Hm!

Allright… Let’s try out the Unity package from the AUR. Ok, it’s marked “outdated”, but let’s try it out, anyway. Needs dependencies. Ok, download the PKGBUILDs for those from the AUR, too. Some work, some don’t. Time to take a look at the PKGBUILD. Looks clear and easy to understand. Spend about two hours getting into the PKGBUILD system and trying to fix things. No luck.

Well! Removing all these directories, I decided writing my first own PKGBUILD. A few minutes later it downloads the Unity source (this time the new version 6.0.0) from launchpad. Ok, taking a look at its docs, there’s a lot of dependencies. A long story short, I spent the whole rest of the day writing PKGBULDs, building package after package. Only to browse the forums before going to bed tiredly – and to find out that there’s another Unity repo which has a working version 6… I have no idea why this is not in the wiki! But well, the many hours were not a complete waste of time since I learned quite a bit about Arch in that process.

Downsides of Arch

I found out that there are no -dev packages with Arch. All the headers and stuff is in the main package. I guess, this is where “simple” beats “light-weight”. If you ask me, it should be vice-versa. The average desktop user who wants a light-weight system and never compiles his own packages, simply does not need all that ballast of the -dev packages!

Also, like I wrote above, it’s not really easy to get an old package installed. Keeping an old one is no problem. You can easily forbid to update it in pacman.conf. But older packages are simply not kept on the repo mirrors! After finding the right repo, installing Unity was no problem. However I was experiencing severe graphic glitches. I read a little on the forums and understood that this was due to Unity not being compatible with glew1.8. Luckily there’s a PKGBUILD for glew1.7 on the AUR as there’s no possibility to simply install an older version from the main repos. This is the point where I miss my Gentoo! But well – you just can’t have the best of both worlds, I guess.

What’s next?

The next blog entry will finally start with the desktop tests! Comparison of the modern GTK+ desktops should be ready on sunday.

Rolling Release trouble

Sorry that it took me so long to write a new entry. And since this is obviously not the test that I promised in the last one: Sorry again.

As a less funny coincidence I had a lot of trouble with the Rolling Release model of Gentoo just after talking about it in the New Team Member! post.

Gentoo, Portage and Rolling Release

On several occasions in the past I had problems with my Gentoo – starting with my very first day where I set up a Gentoo test system. Something did not work at all and after trying to get it working myself for hours, I asked in a forum. In the end the problem was not my stupidity but something broken in the portage tree. I was advised to “wait about a day”, resync and “see if it works then”. This was actually the case so this strange experience did not make me abandon Gentoo right away. There were so many new things that fascinated me.

As I stated before, this was not the only time something like that happened. And so it has happened again during the time when I wanted to do my tests. When everything went well as I prepared the test about four weeks ago (I had a working GNOME 3 system and a KDE one), I was content with it and confident that everything would go well. Unfortunately the next week I was unable to emerge GNOME 3. Yes, I did it right the same way that had worked before on exactly the same virtual machine. I knew this already and so I decided to postpone things (it was a rather busy week and I only had one day at the weekend for my testing).

One week later, I had a new problem: This time I could not even emerge GNOME 2 (which is the base for GNOME 3 on Gentoo – you don’t install the latter directly but install it over GNOME 2)! I tried to mess with package.accept_keywords and force portage to give me a working version. However this was rather time-consuming and in the end I was forced to postpone everything again.

So what’s the status now?

I used this sunday to give it a try again. Since my VM was quite old now (and for the sake of comparability I did not want to update the base), I set up a new Gentoo VM. For a change I chose to build a genkernel this time, since I’ve always wanted to give it a try but never found the time to do so. Then I changed profile, USE variable and rebuilt my system. Next I emerged GNOME 2 – things were working again. After that: GNOME 3. Success! But when I wanted to start it, GNOME 3 reports an error and advises me to log out and try again. Which however does not help…

Scanning through Xorg.0.log, I saw that there were problems with virtualbox’ graphic drivers. For the rest of my time I tried to get things working: Setting the video card in /etc/make.conf, putting both the driver and the guest-additions in package.accept_keywords for the newest version, updating the system… Well, everything failed. It seems like I can’t get it to work soon.

What’s next?

[update 08/07:] When writing this entry, I had intended to skip the 3D-desktops and start with the other ones. But due to some more issues that have arisen in the meantime, I’m really fed up with it all. Always compiling everything simply takes ages. I wouldn’t mind that if things were working afterwards! But since that has not been the case a little bit too often now, I’m going to try out something different. It’s likely that I’ll be switching my test distribution.[/update]