DDD #1: Situation of the Linux Desktop

It took me a bit longer to write this post (and when I finally did, I forgot to post it to the public). Sorry for that. But now it’s here – and like I promised, it’s introducing a new EERIE subproject!

Situation of the Linux Desktop

No, I don’t want to predict when the “final breakthrough” will happen nor do I care much for current market shares. And no, I’m also not going to repeat what Linus said about this topic – we all know it and if somebody really doesn’t, it’s easy to find out.

To be precise: I don’t mean the situation of the Linux Desktop at all but rather that of the Linux desktop. So – what’s noteworthy here? Well, I can’t put it better than a headline I read in a German magazine quite a while ago: “the desktop is fragmenting / splintering”!

Major desktop environments

Over the years many people have complained that Linux is not “successful” because there’s no standard desktop. There may or may not be something to this claim. The important thing is that it was raised in a time when there were essentially two big DEs which had such a high user base that other desktop environments were only playing underparts. Those two were KDE and GNOME.

Things have changed since then and ironically not in the direction that one of them established itself as the clear “winner”. What happened in fact is more like the contrary…

Forks

First KDE Plasma was released and left a lot of people perplexed. Some didn’t like the new style. Others found the system requirements to be ridiculously high (at that time). People who had used KDE for years were not happy with the direction Plasma was taking and were looking for alternatives. Some changed their default DE, some wanted to go on with KDE 3. Efforts of the later resulted in a new project: Trinity DE!

The other big desktop environment followed the same path; the idea was to modernize things. Some people liked the new GNOME 3, many others hated it (that word is not an exaggeration). The results? Same thing: Some former GNOME users were unhappy and switched their default DE and a few others decided to go on with GNOME 2’s codebase – and thus MATE was born.

Upward climbers

Of course this way DEs that were previously more or less underdogs were getting more and more popular. This is especially the case with Xfce which has been around for quite some time but has attracted many former GNOME 2 users since the release of GNOME 3. Another winner is surely the rather young LXDE: Anybody interested in Linux has at least heard of this light-weight DE today.

Other than that there are more noteworthy players now. First, there’s Unity. It’s one more modern DE that benefits greatly from nowadays being the standard desktop of the extremely popular distro Ubuntu. Another one is Enlightenment which already has a formidable user-base.

Outsiders

Apart from the DEs previously mentioned, new readers of my blog may be surprised just how many other desktop environments there are out there (I’ve blogged about them). Are those inferior to the more popular ones? Hell no!

The biggest problem with them is just that they are not well-known! However there are other problems as well. Many distros (especially the smaller ones) do not offer packages for these. Getting them to run on your distribution can be rather tricky and take some time and effort. In case of novice users it can also prove to be a barrier hard to cross.

The solution

Luckily many DEs offer Live-CDs so that you can easily take a look at them. But having to download multiple ISOs for that reason is also an unnecessary inconvenience. What about a single DVD image that comes with all Linux desktop environments?

This way each of them can be tested easily! It also has the advantages that you won’t miss some less-known DE and that you can compare them directly.

For those reasons I’d like to introduce project “DDD” which stands for “Desktop Demo DVD“!

What’s next?

I’ve already prepared the ISO for the DDD version 0.1. Expect it to be available during the next days!

Linux GUI toolkits

We’re going to examine 7 toolkits in just a minute after discussing how to deal with this topic. These 7 are:

Some people say that Linux is all about is choice. True or not: When it comes to toolkits, it’s usually the programmers who have to make a choice. They have to check if a toolkit provides all the features they want and if they feel comfortable with its syntax and so on. However this blog entry is not about recommendations for programmers (there’s probably enough material out there already).

From which perspective are we going to look at them, if not from a programmer’s? Simple! From the perspective of a distribution creator wannabe! ūüėČ

Distributions and toolkits

For a distro creator things are much easier here – he could decide at will or even decide not to make a decision for one but support several (or all) available toolkits instead. There are reasons why this makes sense. Many modern systems combine for example Qt and GTK+ since the users often “mix” applications of both TKs. You like the well-known VLC? Then you have Qt on board. Using GIMP, too? Not without GTK+! Thanks to the theming ability, you usually won’t even notice that your default applications relay on different toolkits.

However there’s also a very good reason not to provide several toolkits by default: They all use up valuable system resources! In the planing especially for a light-weight distribution, it’s a very good idea to make a decision towards one standard toolkit and package default applications which use this particular one.

However it’s not as easy as that in this case. There are lighter and heavier toolskits. Of course the lighter ones lack several features that the others provide. But even more importantly for us: There are huge differences in the number of applications available for each TK! Unfortunately it’s the lightest TKs which have the lowest number of programs using them… So let’s take a closer look at this post’s topic!

Test criteria

As I said before, we won’t examine the TKs in their technical aspects (or distinguish between toolkit, development framework, etc). Of course things like FOX not supporting themes can be very relevant when deciding on the right standard toolkit for our distro. But that’s beyond the scope of this blog entry.

We’re just going look at the various TKs in terms of how “heavy” the are. To do this, we compare the amount of drive space they need, how long they take to compile and how many dependencies they have. The first is done with the Arch Linux packages for the particular TK and the rest on a fresh Gentoo VM (emulating a single core 2.66 GHz pc with 2 GB ram and compiling with -j1) with just X11 installed. There are however a few things which make our comparison a bit difficult – for that reason I’ll explain each toolkit on its own first and provide a table at the end of the post.

Qt4

I thought about including Qt3, too, for a moment. Why? Well, it would have made a nice comparison on how much heavier Qt4 is and besides that, Trinity DE still uses it. But Qt5 is already on its way and so I decided to discard it.

Qt4 is one colossus of a TK! The Arch package (qt-4.8.2-3-i686.pkg.tar.xz) is 21.0 MB in size and 80.4 MB uncompressed!

It’s so big that it was split into smaller packages on Gentoo (qt-script, qt-bearer, qt-sql, qt-xmlpatterns, qt-opengl, qt-core, qt-phonon, qt-test, qt-declarative, qt-demo, qt-mobility, qt-qt3support, qt-svg, qt-dbus, qt-multimedia, qt-webkit, qt-openvg, qt-assistand, qt-gui). 115 packages have to be compiled and installed and 386 MB downloaded from the net to do this! The source code for Qt alone (qt-everywhere-opensource-src-4.8.2.tar.gz) is 234 MB in size; the total compilation process takes 3:20:45 of which Qt alone takes 2:32:14!

GTK+3

GTK+3 is not actually a stand-alone TK but in fact extends and as such depends on the older GTK+2.

The Arch package (gtk3-3.2.3-3-i686.pkg.tar.xz) is 6.6 MB in size (together with GTK+2: 13.3 MB) and uncompressed it needs 51.5 MB (together with GTK+2: 106 MB).

Building it on Gentoo means compiling and installing 89 packages whose source code is 132 MB in size of which the GTK+3 source makes up 12 MB (together with GTK+2: 24.6 MB. Compiling takes 45:51 minutes of which 5:37 are for compiling GTK+3 (together with GTK+2: 11:27 minutes).

GTK+2

The Arch package for GTK+2 (gtk2-2.24.10-3-i686.pkg.tar.xz) is 6.7 MB in size and 54.4 MB uncompressed.

To install it on Gentoo, 88 packages have to be built and 120 MB of sources downloaded. GTK+2 source code makes up 12.6 MB of that. Compiling the whole thing takes 40:00 minutes and GTK+2 alone takes 5:50 minutes.

GNUstep

GNUstep, being based on the objective-c language, has the disadvantage that the whole GCC needs to be recompiled with OBJ-c enabled on Gentoo. This is of course a very big factor, but while I wanted to mention it, I’ll subtract the GCC recompile on the comparison.

GNUstep consists of several packages by default. The Arch packages (gnustep-back-0.22.0-3-i686.pkg.tar.xz, gnustep-base-1.24.0-3-i686.pkg.tar.xz, gnustep-gui-0.22.0-3-i686.pkg.tar.xz, gnustep-make-2.6.2-2-any.pkg.tar.xz) are together 3.9 MB in size and 16.7 MB uncompressed.

Building on Gentoo means installing 93 packages for which 206 MB of source code needs to be downloaded (including GCC recompile) or 92 packages, 141 MB in size (without GCC recompile). The packages (gnustep-base-1.24.0.tar.gz, gnustep-gui-0.22.0.tar.gz, gnustep-make-2.6.2.tar.gz, gnustep-back-0.22.0.tar.gz) are 7,0 MB in size. Compiling takes 1:27:13 (including GCC recompile), 43:51 minutes (without it) and 4:22 minutes for GNUstep alone.

FOX

The Arch package for FOX (fox-1.6.40-1-i686.pkg.tar.xz) is 3.9 MB in size and 13.8 MB uncompressed.

Building it on Gentoo means compiling 6 packages whose source is 5.0 MB in size of which FOX’s source code makes up 4.3 MB. Compiling it all takes 5:59 minutes and FOX alone takes 4:49 minutes.

OpenMotif

OpenMotif’s Arch package (openmotif-2.3.3-2-i686.pkg.tar.xz) is 3.3 MB in size and 10.3 MB uncompressed.

Installing it on Gentoo means building 4 packages for which 6.7 MB of source code has do be downloaded, 5.9 MB of source for OpenMotif alone. Building it takes 3:29 minutes while OpenMotif alone takes 2:58 minutes.

FLTK

FLTK (pronounced “fulltick”) is a very light toolkit. It’s Arch package (fltk-1.3.0-3-i686.pkg.tar.xz) is just 1.0 MB in size and uncompressed it only takes 4.7 MB of space.

To install it on Gentoo, 7 packages have to be built, which needs 7.2 MB of source code downloaded from the net. 4.0 MB of which is for FLTK source. Building only takes 2:42 mintes and for FLTK alone it’s as little as 1:04 minutes!

Comparison

Toolkit Arch size Gentoo Src size Build time (h:m:s)
FLTK 1.0 / 4.7 7 pkgs 7.2 / 4.0 0:02:42 / 0:01:04
OpenMotif 3.3 / 10.3 4 pkgs 6.7 / 5.9 0:03:29 / 0:02:58
FOX 3.9 / 13.8 6 pkgs 5.0 / 4.3 0:05:59 / 0:04:49
GNUstep* 3.9 / 16.7 92 pkgs 141 / 7 0:43:51 / 0:04:22
GTK+2 6.7 / 54.4 88 pkgs 120 / 12.6 0:40:00 / 0:05:50
GTK+3** 13.3 / 106 89 pkgs 132 / 24.6 0:45:51 / 0:11:27
Qt4 21.0 / 80.4 115 pkgs 386 / 234 3:20:45 / 2:32:14

All sizes in MB.
*) without recompiling GCC for OBJ-C support
**) Including GTK+2

Conclusion

The winner and most light-weight toolkit is easily FLTK. It has the smallest installed size, smallest source and shortest compilation time, both including dependencies and on its own. Only in the number of dependencies it’s beaten by OpenMotif and FOX which are quite light-weight in the other aspects, too. With GNUstep things become a lot more heavy and GTK+ or Qt are of course full-blown toolkits which provide about every feature you’d need but are also very bloated.

We’ll drop FOX and GNUstep from now on, since there’s no working desktop environment using them at the moment (There’s a project to create a FOX DE, but it seems to be inactive since 2005 and √ątoil√® (GNUstep) is a mess right now) which makes them irrelevant for our purpose. There was of course some value in adding them to this comparison, though.

What’s next?

Before we go on with comparing TKs and DEs while running some standard applications somewhen next month, the next post will deal with creating a live-cd. This will be an essential task sooner or later and I also need it for “DDD”, one of Eerie’s sub-projects which was not yet revealed (don’t expect too much, though).

An extraordinary TK example!

The last blog post was a little introduction to toolkits in general – now it’s time for a truly special case! While it doesn’t really fit completely with what we’re doing here, it’s close enough to provide a fine example. (That and I like it enough to think that it deserves some more attention outside the narrow scene that’s usually interested in such a thing!)

An unusual distribution

Our example is a graphical distribution with a tiny display server (Nano-X), a simple window manager and FLTK (Fast Light ToolKit) as GUI toolkit. According to its site, FLTK is a cross-platform C++ GUI toolkit for UNIX/Linux, Windows and MacOS X. The uncompressed iso of the distribution is just a little over 60 MB in size. Now take a look at the desktop and guess, which operating system this is based on (and don’t look at the tags of this post if you don’t want to spoil the fun)!

“A graphical distribution using Nano-X and FLTK”

Which OS?

So what do you think from what you see? It looks fairly decent if maybe a bit unoriginal. Is it Windows? No, Windows knows no X11 and thus no Nano-X – and Windows hasn’t fit in ~60 MB for ages! MacOS? To big, too and we were talking about a distribution. So again: No. Linux then? Sounds likely. But a tiny Linux distribution with graphical abilities is nothing special and even less something revolutionary!

Want to see another screenshot? Here’s a FLTK application running:
FlWriter – a simple FLTK word processor

So is it Unix? Some BSD? Or Minix perhaps? No, none of these! A rather exotic thing then? MenuetOS or V2-OS (two operating systems written entirely in assembler!)? Nope. Something completely new? No, you know it, trust me. And it’s not ReactOS or anything like that, either. It’s far easier: This is… DOS.

No, I’m serious! Really, this is Nano-X and FLTK ported to DOS by G. Potthast. The distribution we’re talking about is XFDOS! If you still don’t believe me, just scroll down to the end of this post. There’s a link to the project’s page where you can download it and see for yourself!

It comes with quite some programs, so you can really call it a distribution. There’s a word processor, a spreadsheet application, a painting program, a picture viewer, a pdf viewer and some more.

Alright, it’s still not of much value for daily use. While it even features USB support, there’s no multitasking for example and quite a few other things disqualify XFDOS as a primary OS. But that’s not what it’s meant for, anyway. It’s a great achievement and a neat example of what can actually be done. And it’s surely a huge step ahead of what a DOS GUI usually looks like! You don’t know what I mean? Heh, this gives me a good reason to set up a FreeDOS VM quickly and install OpenGEM again to show you (yes, I really worked with that before – but it’s been years…)!

OpenGEM – a DOS GUI running on FreeDOS

A toolkit in action

This exotic example now gives us the chance to compare a FLTK program running on two entirely different platforms. First take a look at the DOS port of the web browser Dillo:

Dillo – a FLTK-based browser (DOS version!)

And now compare it with Dillo running on a bare-bone Gentoo system running only X11+twm:

Dillo – a FLTK-based browser (on Gentoo)

As you can see, Dillo looks alike on such different platforms as DOS and Linux. Ok, the screenshots show quite some differences… But this is mainly the window bar which is a task of the window manager. Other than that there are a few differences thanks to the fact that XFDOS uses Dillo 3.0 and my Gentoo build is 3.0.2. Also some buttons are grayed out on the later but you can take my word for them to look alike if they both were active.

Even though in the first example the application is running in full screen while in the second it is not, it becomes clear that the application has the same style (buttons, scroll-bar, etc.) on both platforms and this is actually all I wanted to show here: GUI toolkits provide typical graphical elements so that the programmer doesn’t have to care for how they look on other platforms!

Interested in XFDOS?

You can explore the projet’s site here: http://code.google.com/p/nanox-microwindows-nxlib-fltk-for-dos/wiki/XFDOS

What’s next?

In the next post we’ll take a look at the various GUI toolkits available for Linux.

Toolkits – an introduction

The topic of this post is GUI (Graphical User Interface) toolkits. As I wrote before, the EERIE blog is for both Linux veterans and novice users. This entry is meant for the later. If you already have more than a rough idea about what toolkits are, save yourself some time and skip it.

Why to give thought about toolkits?

The importance of the decision which desktop environment to use is pretty obvious. In case of GUI toolkits this is less self-explanatory. However deciding on the right TK is a crucial issue when planing a new distribution. But what are toolkits and what do they do?

While this is not too complicated a subject, it can also be a bit confusing. Especially since there are several commonly used terms which mean the same thing and also some often used in a semi-wrong way that can easily lead to misunderstandings. But let’s shed some light on this topic!

Low-level and high-level programming

With any pc it’s the CPU that can execute a number of instructions. While the set of special instructions grew bigger and bigger (think of MMX, SSE, etc.) over time, it’s generally a big hassle to create more complex programs entirely by doing low-level programming.
Here’s one example in Assembler:

MOV AH,BX

This line translates more or less to “put the value of register AH into register BX“. It’s not hard to imagine that coding like that is complicated, tedious and not very intuitive at all (the programmer has to keep an overview of what is in which register in our example).

For this very reason high-level programming languages exist: it’s far easier to do complex tasks in a more abstract way that is closer to what the human brain works like. It’s not hard at all to tell what the following line does:

PRINT "Hello world!"

Yes, this code fit for the language Basic just prints the well-known message to the screen. Basic is for the main part an “interpreter language”. This means that a set of commands is “translated” into machine code by the interpreter. While Basic provides a fine example here, it’s a little too simple to be fit for serious programming today. There are many high-level languages available, probably the most common being C and C++.

Source code, compilers & libraries

If a programmer wants to create a new program, he or she writes the source code (all the commands which produce the program in the end) for it in his or her prefered language. Afterwards the source code gets compiled (and linked) and the result is an executable program file.

While all high-level languages offer a certain set of commands, it would still be very cumbersome if all programmers had to stick to just these. It absolutely makes sense not to re-invent the wheel each and every time but to simply use some advance routines. Those are often provided by various libraries which are not by themselves programs for the end-user but in fact act like collections of functions which can be called by other programs.

Printing some string on the screen is a typical example. Almost every program needs to have this ability. Every programmer could write his or her own routines or just use an external one to do it. In the later case the programmer also has to decide how to ensure that his program can relay on the external resources. There are two ways to do this!

Static and dynamic linking

It’s possible to append the library to your program executable – this is called static linking. This is obviously the safest way. The drawback however is that this increases the size of the executable. In case of bigger projects which use a lot of libraries this is not a good idea at all. In addition this may be a wast of disk space if you have several programs on your computer which use the same library and each one has it statically linked!

The other possibility is to use dynamic linking. In this case the external resource stays external: the program relays on a library that needs to be installed on your computer. These libraries are called *.so (shared object) on Linux systems and *.dll (dynamic link library) on Windows. To use these is much more efficient in terms of space. However it can be a nuisance if a program depends on a lot of libraries and it can also be a problem if one program relays on an old version of a library and doesn’t work with a newer one while another program needs the latest one…

GUI toolkits

A GUI toolkit, also known as widget toolkit or sometimes widget library is a special kind of library. Their purpose is to provide a set of “widgets” (like a button for example) which other programs can use. This ensures that any e.g. a button drawn by any application using the same TK follows the same style (i.e. looks alike). Many toolkits do not just support one platform but are cross-platform TKs. This means that you could write a program based on sometoolkit which could then run e.g. on Linux, MacOS and Windows without having to care about how the particular system manages drawing graphics on the screen!

However there are several toolkits available – some a bit lighter, some a lot heavier. Of course they work differently and offer a different function volume. But those things will be discussed at a later time.

What’s next?

The next post will be about something really neat that I discovered recently. I won’t spoil it yet, but it’s something that probably nobody would ever expect. I just have to write about it! After that we’re going to examine the toolkits a little closer.

Linux desktop comparison summary – 20 solutions for your desktop!

Our first Linux desktop comparison is over. I took a look at quite some projects during the last weeks. 20 of those (including modes that are behaving differently) proved to be full DEs which should be covered by a broadscale test.

Some others, like UDE for example, had to be skipped. While it does have a very interesting concept, it’s not currently a DE but only offers a window manager (despite the name “Unix Desktop Environment”). In the end 18 DEs were actually tested (I failed to get the other two to run on Arch).

Problems

Comparing DEs over the time of several weeks on a rolling release system might not really wield the best results. I also wanted to add something new to this post so that it’s not just a boring summary for those who have read the past entries. Therefore I decided to add the size of the packages that are downloaded to install the DE, too. After all network traffic can still be an issue for some people. Well, and for some DEs new versions have been released in the meantime and I’d feel stupid to write a new entry by just warming up old stuff.

For these reasons I repeated most of the tests last Monday and Tuesday and use the new values here (which sometimes make a huge difference!). Only CDE uses the old package; I was able to build a current package but did not succeed in making the DE start. Unity2d is now obsolete just like the old GNOME 2 (which I essentially added so that MATE can be compared to it, anyway).

Overall Ranking

I’ll begin with the overall rating here since that’s the most important thing. I’ve compared all DEs in terms of 1. memory consumption (most important for me and thus weighted *3), 2. disk space used (weighted *2) and 3. size of packages to download. So, here’s the result:

Rank DE Version
01 OpenCDE 620
02 Equinox DE 2 2.0
03 CDE 2.2.0a/b
04 LXDE 0.5.x
05 ROX DE 0.41.0
06 Enlightenment 17 svn-75246
07 Razor-Qt 0.4.1
08 Xfce 4.10.0
09 Sugar 0.94.1
10 MATE DE 1.4
11 Cinnamon UI 1.5.7
12 GNOME 3 Classic 3.4.2
13 GNOME 3 Shell 3.4.2
14 Trinity DE 3.5.13
15 Unity 3D 6.4.0
16 KDE Plasma 4.9.0

RAM usage

Here’s the table that compares memory usage of the tested DEs:

<101 MB 101 – 200 MB 201 – 300 MB >300 MB
obsolete not working
Rank DE Version Memory usage
00 Arch Linux 08/2012 37 MB
00 X11, VBoxadds, xterm 08/2012 54 MB
01 OpenCDE 620 57 MB
02 Equinox DE 2 2.0 71 MB
03 CDE 2.2.0a 72 MB
04 ROX DE 0.41.0 72 MB
05 LXDE 0.5.x 83 MB
06 Enlightenment 17 svn-75246 97 MB
07 Xfce 4.10.0 104 MB
08 Razor-Qt 0.4.1 117 MB
09 Sugar 0.94.1 122 MB
10 GNOME 2 2.32 137 MB
11 MATE DE 1.4 139 MB
12 Trinity DE 3.5.13 202 MB
13 GNOME 3 Classic 3.4.2 211 MB
14 Cinnamon UI 1.5.7 224 MB
15 GNOME Shell 3.4.2 253 MB
16 Unity 3D 6.4.0 312 MB
17 KDE Plasma 4.9.0 354 MB
18 Unity 2D 6.0.0 404 MB
xx Ètoilè 0.4.2 ??
xx Mezzo ?? ??

Drive space needed

Here’s the next table:

<301 MB 301 – 600 MB 601 – 1.2 GB >1.2 GB
obsolete not working
Rank DE Version Disk space used
00 Arch Linux 08/2012 561 MB
00 X11, VBoxadds, xterm 08/2012 +68 MB
01 OpenCDE 620 +83 MB
02 Equinox DE 2 2.0 +174 MB
03 CDE 2.2.0b +192 MB
04 Razor-Qt 0.4.1 +226 MB
05 LXDE 0.5.x +325 MB
06 Enlightenment 17 svn-75246 +340 MB
07 ROX DE 0.41.0 +497 MB
08 Xfce 4.10.0 +559 MB
09 Sugar 0.94.1 +604 MB
10 GNOME 2 2.32 +630 MB
11 MATE DE 1.4 +675 MB
12 Cinnamon UI 1.5.7 +947 MB
13 GNOME Shell 3.4.2 +1023 MB
14 GNOME 3 Classic 3.4.2 +1023 MB
15 Unity 3D 6.4.0 +1121 MB
16 KDE Plasma 4.9.0 +1232 MB
17 Trinity DE 3.5.13 +2098 MB
18 Unity 2D 6.0.0 ??
xx Ètoilè 0.4.2 ??
xx Mezzo ?? ??

Download size

And here’s the last one:

<51 MB 51 – 100 MB 101 – 200 MB >200 MB
Rank DE Version size default / max
00 Arch Linux 08/2012 123 MB
00 X11, VBoxadds, xterm 08/2012 +15 MB
01 OpenCDE 620 +19 MB
02 Equinox DE 2 2.0 +38 MB
03 CDE 2.2.0b +49 MB
04 Razor-Qt 0.4.1 +53 MB
04 LXDE 0.5.x +53 MB
05 ROX DE 0.41.0 +75 MB
05 Enlightenment 17 svn-75246 +75 MB
06 Xfce 4.10.0 +82 / 99 MB
07 Sugar 0.94.1 +89 MB
08 MATE DE 1.4 +119 /169 MB
09 Cinnamon UI 1.5.7 +147 / 347 MB
10 Unity 3D 6.4.0 +163 /302 MB
11 GNOME 3 Shell 3.4.2 +167 / 366 MB
11 GNOME 3 Classic 3.4.2 +167 / 366 MB
12 KDE Plasma 4.9.0 +306 / 774 MB
13 Trinity DE 3.5.13 +485 MB

Conclusion

The most light-weight DE tested is OpenCDE, based upon Motif. The second best is Equinox DE using FLTK as its toolkit. The lightest GTK+-based DE is LXDE, ranked No. 5 and the lightest Qt one Razor-Qt which scored rank 7. So these will be the candidates to examine closer in a future testing series.

What’s next?

The next entry will deal with what Eerie’s last two letters stand for.

Linux desktop comparison (pt. 5): Exotic DEs

This is the final part of our desktop testing series. We’ll deal with the rather exotic desktop environments in this entry. Most of them are built on top of some unusual toolkits.

These are:

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

OpenCDE

OpenCDE was a project to recreate the proprietary Unix desktop CDE. However the original CDE has been open-sourced recently and OpenCDE is likely to be discontinued since its developers joined the developement of CDE. It is however a very light DE but also quite incomplete.

The OpenCDE desktop

Installation

pacman -S xorg-server xorg-xinit virtualbox-archlinux-additions libxpm
pacman -U opencde-620-4-i686.pkg.tar.xz

Statistics

Memory usage right after starting up OpenCDE (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 + OpenCDE (620)
MemTotal: 1030652 kb
MemFree: 971424 kb
Buffers: 7348 kb
Cached: 28084 kb
Rootfs: 739756 / 723M
RAM used at startup: 59228 / ~58 MB
Disk space (less basic system): 85468 / ~83 MB

CDE

CDE or “Common Desktop Environment” is the original Unix desktop that was often bundled with retail Unix versions. It was quite innovative in its time but today it shows that the opened source code of the program is really dated (it was last worked on in about 1999). And while this DE is not extremely popular with Linux users, it does have a certain user base and is actively worked on again. It comes with the full load of tools that were part of the DE back then.

The CDE desktop

Installation

pacman -S xorg-server xorg-xinit virtualbox-archlinux-additions
pacman -U ncompress-4.2.4.4-1-any.pkg.tar.xz
pacman -U openmotif-2.3.3-archcdepatched-1-i686.pkg.tar.xz
pacman -U cde-git-20120828-1-i686.pkg.tar.xz

Statistics

Memory usage right after starting up CDE (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 + CDE (2.2.0a-alpha)
MemTotal: 1030548 kb
MemFree: 956616 kb
Buffers: 8748 kb
Cached: 34344 kb
Rootfs: 756248 / 739M
RAM used at startup: 73932 / ~72 MB
Disk space (less basic system): 101960 / 100 MB

Equinox DE 2

The Equinox Desktop Environment is the result of a project aiming to create an extremely light-weight DE. It has been around for a while but never got much attention. With version 2.0 released this year the project proved to be alive even though many people thought that it was already dead. This new version is a huge step ahead: EDE 2 is now fully FreeDesktop.org compatible. It just offers a simple DE – no more, no less. A very promising project!

The EDE 2 desktop

Installation

pacman -S xorg-server xorg-xinit virtualbox-archlinux-additions libxpm
pacman -U edelib-2.0.1-1-i686.pkg.tar.xz
pacman -U ede-2.0-3-i686.pkg.tar.xz

Statistics

Memory usage right after starting up EDE 2 (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 + EDE 2 (2.0)
MemTotal: 1030652 kb
MemFree: 959044 kb
Buffers: 8084 kb
Cached: 30896 kb
Rootfs: 832676 / 814M
RAM used at startup: 71608 / ~70 MB
Disk space (less basic system): 178388 / 174 MB

√Čtoil√©

√Čtoil√© aims to be a resource-saving, modular and easy to use DE. It uses the GNUstep toolkit and kind of resembles the Mac OS X style in many aspects. The last stable build is quite old now and the newest versions are not in usable shape right now (not even recommended by the developers). So if you like the idea of this DE, it’s more or less something to keep in mind for the future.

The √Čtoil√© desktop

Installation

I have not been able to compile and install it on a current Arch machine. The screenshot is from a modified Ubuntu version from 2009. It *might* be possible to get the DE to work with a current Arch system, but that would most likely be a lot of work and it surely is far beyond my skills. If anybody is up to that challenge – please tell me! I would be very much interested to get the last stable version 0.4.1 (spring 2009!) working!

Mezzo

Mezzo was a DE that tried to go new ways. It places control icons in all four corners of the screen; system-related items are in the upper left, file-management in the upper right, restarting / shutting down in the lower right and applications in the lower left. It avoids nested menus and tries to abandon the concept “the desktop is a folder”. This innovative DE was developed as part of the now discontinued SymphonyOS and was never really available outside of it.

The Mezzo desktop

Installation

I have not been able to compile and install it on a current Arch machine. The screenshot here is from the 2008 edition of SymphonyOS which was the only one I could still find on the net. There has been a 2011 release as well, but I had no luck finding it. Honestly, I have not even been able to even find the source code for Mezzo, the DE I’m actually interested in. Looks like it’s gone (which is a real shame). Perhaps it’s not gone for good?

Conclusion

We have two DEs that could not be tested this time; √Čtoil√© and Mezzo are interesting projects for sure but not available right now.
OpenCDE is really tiny in every aspect – with less than 60 MB of RAM needed and just about 80 MB installed (including Xorg)! However it also doesn’t offer much and is most likely dead. CDE does well with little more than 70 MB of RAM. It’s quite old now but actively developed again – yet it’s uncertain if it can be turned into a modern DE without breaking the CDE concepts. And then there’s EDE 2. This one is very frugal with about 70 MB of RAM needed. A great DE with a classical feeling perfectly fit for systems with low RAM.

What’s next?

The next entry will be a summary of all five parts of our test.

Linux desktop comparison (pt. 4): Less common GTK+ DEs

This is part 4 of our desktop testing series. We’ll deal with some of the less common desktop environments in this entry which by chance are are all GTK+ based.

These are:

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

GNOME 2

GNOME was the most used Linux desktop before the new version 3. GNOME 2 is quite old now but it is still a standard desktop in several more conservative distributions. And while it is not nearly as common anymore as it once was, it may still be the most used DE of this part of our test!

The GNOME 2 desktop

Installation

Using mirror from 04/30/2011 (Kernel 2.6.38)
pacman -S xorg-server xorg-xinit dbus xf86-video-vesa gnome

Statistics

Memory usage right after starting up GNOME 2 (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 2 (2.32)
MemTotal: 1028476 kb
MemFree: 888080 kb
Buffers: 15672 kb
Cached: 63488 kb
Rootfs: 1299288 / 1.3G
RAM used at startup: 140396 / ~137 MB
Disk space (less basic system): 645000 / 630MB

ROX DE

ROX is best known for ROX-filer, a widely used file manager. A little less common is the ROX desktop. Like one would expect, ROX-filer is the heart of it, but there are several other parts which form the ROX DE together. In its default shape it is very simplistic – and certainly not nice-looking. But don’t be fooled: With a little customization it can look a lot better than it does on this screenshot!

The ROX desktop

Installation

pacman -S xorg-server xorg-xinit dbus dbus-glib virtualbox-archlinux-additions gconf libxxf86vm openbox rox
pacman -U rox-session-0.41.0-5-i686.pkg.tar.xz
pacman -U appearance-0.9.1.ml-1-i686.pkg.tar.xz
pacman -U rox-clib-2.1.10-2-i686.pkg.tar.xz
pacman -U appfactory-2.1.5.ml-2-i686.pkg.tar.xz
pacman -U archive-2.2.git.ml-1-i686.pkg.tar.xz
pacman -U mini-clock-2.0.0.ml-2-any.pkg.tar.xz
pacman -U resolution-0.3.ml-1-any.pkg.tar.xz
pacman -U rox-edit-2.2-1-any.pkg.tar.xz
pacman -U rox-font-0.9.2.ml-2-any.pkg.tar.xz
pacman -U rox-keyboard-0.11.1.ml-1-any.pkg.tar.xz
pacman -U rox-mouse-0.10.1.ml-1-any.pkg.tar.xz
pacman -U rox-trash-0.3.0.ml-2-any.pkg.tar.xz
pacman -U traylib-0.3.2.1-1-i686.pkg.tar.xz
pacman -U rox-trasktray-0.7-1-any.pkg.tar.xz
pacman -U python-pyalsaaudio-0.7-1-i686.pkg.tar.xz
pacman -U rox-volume-0.4.14122008-1-any.pkg.tar.xz
pacman -U systemtray-n-0.3.2.1.ml-2-i686.pkg.tar.xz
pacman -U tasklisk-0.5.ml-1-i686.pkg.tar.xz

Statistics

Memory usage right after starting up ROX (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 + ROX (0.41.0)
MemTotal: 1030652 kb
MemFree: 955128 kb
Buffers: 10084 kb
Cached: 36784 kb
Rootfs: 1087652 / 1.1G
RAM used at startup: 75524 / ~74 MB
Disk space (less basic system): 433364 / 423MB

Enlightenment E17

Enlightenment started as a hacked window manager that was amazingly customizable. E16 is the current stable version. With E17 however, so many things have been added that it is no longer considered just a WM but in fact a real DE. E17 is officially in beta stages but it is already pretty stable and used for everyday work by many users.

The E17 desktop

Installation

pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions e-svn

Statistics

Memory usage right after starting up E17 (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 + E17 (snv-72693)
MemTotal: 1030652 kb
MemFree: 934808 kb
Buffers: 8772 kb
Cached: 50312 kb
Rootfs: 896992 / 876M
RAM used at startup: 95844 / ~94 MB
Disk space (less basic system): 242704 / 237MB

Sugar

Sugar is not really a general-purpose desktop. It’s a DE made for children. It would probably not be known by many people if it wasn’t the standard DE on the sub-notebooks of the well-known “One Laptop Per Child” project. It’s also available as an optional package in some of the bigger distributions.

The Sugar desktop

Installation

pacman -S xorg-server xorg-xinit dbus virtualbox-archlinux-additions python-pygame
pacman -U sugar-base-0.94.0-2-i686.pkg.tar.gz
pacman -U python2-xapian-1.2.10-1-i686.pkg.tar.xz
pacman -U sugar-datastore-0.94.0-1-i686.pkg.tar.xz
pacman -U icon-slicer-0.3-5-i686.pkg.tar.xz
pacman -U sugar-artwork-0.94.0-1-i686.pkg.tar.xz
pacman -U sugar-presence-service-0.90.2-1-i686.pkg.tar.xz
pacman -U hippo-canvas-0.3.1-2-i686.pkg.tar.xz
pacman -U sugar-toolkit-0.94.0-1-i686.pkg.tar.xz
pacman -U sugar-0.94.1-1-i686.pkg.tar.xz

Statistics

Memory usage right after starting up Sugar (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 + Sugar (0.94.1)
MemTotal: 1030652 kb
MemFree: 911100 kb
Buffers: 12092 kb
Cached: 57340 kb
Rootfs: 1272052 / 1.3G
RAM used at startup: 119552 / ~117 MB
Disk space (less basic system): 617764 / 603MB

Conclusion

GNOME 2 is the biggest DE this time and it’s doing a little better than MATE in terms of RAM needed. Sugar needs some less RAM but it’s not a DE many people will want to use, anyway. E17 is beautiful and still rather memory-saving. And the ROX desktop is by far the most frugal one so far when it comes to memory usage!

What’s next?

The next entry will cover some rather exotic Linux desktop environments.

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.

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.