Top things that I missed in 2015

Another year of blogging comes to an end. It has been quite full of *BSD stuff so that I’d even say: Regarding this blog it has been a BSD year. This was not actually planned but isn’t a real surprise, either. I’ve not given up on Linux (which I use on a daily basis as my primary desktop OS) but it’s clear that I’m fascinated with the BSDs and will try to get into them further in 2016.

Despite being a busy year, there were quite a few things that I would have liked to do and blog about that never happened. I hope to be able to do some of these things next year.

Desktops, toolkits, live DVD

One of the most “successful” (in case of hits) article series was the desktop comparison that I did in 2012. Now in that field a lot has happened since then and I really wanted to do this again. Some desktops are no longer alive others have become available since then and it is a sure thing that the amount of memory needed has changed as well… ๐Ÿ˜‰

Also I’ve never been able to finish the toolkit comparison which I stopped in the middle of writing about GTK-based applications. This has been started in 2013 so it would also be about time. However my focus has shifted away from the original intend of finding tools for a light-weight Linux desktop. I’ve become involved with the EDE project (“Equinox Desktop Environment”) that uses the FLTK toolkit and so people could argue that I’m not really unbiased anymore. Then again… I chose to become involved because that was the winner of my last test series – and chances are that the reasons for it are still valid.

And then there’s the “Desktop Demo DVD” subproject that never really took off. I had an Arch-based image with quite some desktops to choose from but there were a few problems: Trinity could not be installed alongside KDE, Unity for Arch was not exactly in good shape, etc. But the biggest issue was the fact that I did not have webspace available to store a big iso file.

My traffic statistics show that there has been a constant interest in the article about creating an Arch Linux live-CD. Unfortunately it is completely obsolete since the tool that creates it has changed substantially. I’d really like to write an updated version somewhen.

In fact I wanted to start over with the desktop tests this summer and had started with this. However Virtual Box hardware acceleration for graphics was broken on Arch, and since this is a real blocker I could not continue (has this been resolved since?).


I wrote an article about HURD in 2013, too, and wanted to re-visit a HURD-based system to see what happened in the mean time. ArchHURD has been in coma for quite some time. Just recently there was a vital sign however. I wish the new developer best luck and will surely do another blog post about it once there’s something usable to show off!

The experiments with Arch and an alternative libc (musl) were stopped due to a lack of time and could be taken further. This has been an interesting project that I’d like to continue some time in some form. I also had some reviews of interesting but lesser known Linux distros in mind. Not sure if I find time for that, though.

There has been a whole lot going about both FreeBSD and OpenBSD. Still I would have liked to do more in that field (exploring jails, ZFS, etc.). But that’s things I’ll do in 2016 for sure.


I’ve played a bit with a Raspberry 2 and built a little router with it using a security orientated Linux distro. It was a fun project to do and maybe it is of any use to somebody.

One highlight that I’m looking forward to mess with is the RISC-V platform, a very promising effort to finally give us a CPU that is actually open hardware!

Other things

There are a few other things that I want to write about and hope to find time for soon. I messed with some version control tools a while back and this would make a nice series of articles, I think. Also I have something about devops in mind and want to do a brief comparison of some configuration management tools (Puppet, Chef, Salt Stack, Ansible – and perhaps some more). If there is interest in that I might pick it up and document some examples on FreeBSD or OpenBSD (there’s more than enough material for Linux around but *BSD is often a rather weak spot). We’ll see.

Well, and I still have one article about GPL vs. BSD license(s) in store that will surely happen next year. That and a few topics about programming that I’ve been thinking about writing for a while now.

So – goodbye 2015 and welcome 2016!

Happy new year everyone! As you can see, I have not run out of ideas. ๐Ÿ™‚

An interview with the Nanolinux developer

2014 is nearly over and for the last post this year I have something special for you again. Last year I posted an interview with the EDE developer and I thought that another interview would conclude this year of blogging quite fine.

In the previous post I reviewed Nanolinux (and two years ago XFDOS). Since I was in mail contact with the author about another project as well, it suggested itself that I’d ask him if he’d agree to give me an interview. He did!

So here’s an interview with Georg Potthast (known for a variety of projects: DOSUSB, Nanolinux and Netrider – to just name some of them) about his projects, the FLTK toolkit, DOS and developing Open Source software in general. Enjoy!

Interview with Georg Potthast

This interview was conducted via email.

Please introduce yourself first: How old are you and where are you from?

I am 61 years old and live in Ahlen, Germany. This is about 30 minutes drive from Dortmund where they used to brew beer and where the BVB Dortmund soccer team is currently struggling.

Do you have any hobbies which have nothing to do with the IT sector?

Not really. I did some Genealogy, which has to do a lot with IT these days. But now I have several IT projects I am working on.


You’re involved in the FreeDOS community and have put a lot of effort into XFDOS. A lot of people shake their heads and mumble something like “It’s 2014 now and not 1994…” – you know the score. What is your motivation to keep DOS alive?

I have been using DOS for a long time and wish it would not go away completely. So I developed these DOS applications, hoping to get more people to use DOS. But I have to agree that I have not been successful with that.

Potential software developers find only very few users for their applications which is demotivating. Also there is simply no hardware available today that is limited so much that you better use DOS on it. Everything is 32/64 bit, has at least 4 GB of memory and terabytes of disk space. And even the desktop PC market is suffering from people moving to tablets and smartphones.

People are still buying my DOSUSB driver frequently. They are using it mostly for embedded applications which shall not be ported to a different operating system for one reason or another.

Do you have any current plans regarding DOS?

I usually port my FLTK applications to DOS if it is not too much effort to do so. So they are available for Linux, Windows and DOS. Such as my FlDev IDE (Link here).

Recently I made a Qemu/FreeDOS bundle named DOS4WIN64 (Link here) that you can run as an application on any Windows 7/8 machine. This includes XFDOS. I see this as a path to run 16bit applications on 64bit Windows.

How complicated and time consuming is porting FLTK applications from Linux to DOS or vice versa?

It depends on the size and the dependencies on external libraries. I usually run ./configure on Linux and then copy the makefile to DOS where I replace-lXlib with -lNXlib plus -lnano-X. Then, provided the required external libraries could be downloaded from the djgpp site, it will compile if the makefile is not too complicated (recursive). Sometimes I also compile needed libraries for DOS which is usually not difficult if they have a command line interface.

You then have to test if all the features of the application work on DOS and make some adjustments here and there. Often you can use the Windows branch if available for the path definitions.

Porting DOS applications to Linux can be more complicated than vice versa.


For how long have you been using Linux?

I have been using Linux on and off. I began using SCO-Unix. However, I did not like setting things up with configuration files (case sensitive) scattered over many directories. It took me over a week to get serial communications to work to connect a modem. When I asked Linux developers for help they recommended to recompile the kernel first – which means they did not know how to do that either. So I returned to DOS at that time. But I have been using Linux a lot for several years now.

What is your distribution of choice and why?

I mainly use SUSE but I think Ubuntu may work just as well. This may sound dull but you do not have to spend time on adding drivers to the operating system or porting the libraries you need. The mainstream Linux distributions are well tested and documented and you do not have to spend the time to tailor the distro to your needs. They do just much more than you need so you are all set to start right away.

My own distro, Nanolinux, is a specialized distro which is meant to show how small a working Linux distro can be. It can be used on a flash disk, as an embedded system, a download on demand system or to quickly switch to Linux from within Windows.

However, if you have a 2 Terabyte hard disk available I would not use Nanolinux as the main distribution.


Which programming languages do you prefer?

I like Assembler. To be able to use X11 and FLTK I learned C and C++ which I currently use. I have not done any assembler in a while though.

You seem to like the idea of minimalism. Do you do use those minimalist applications on a daily base or are they more of a nice hobby?

Having a DOS and assembler background I always try not use more disk space than necessary. Programming is just my hobby.

Many of your projects use the FLTK toolkit. Why did you choose this one and not e.g. FOX?

I had ported Nano-X to DOS to provide an Xlib alternative for DOS developers. In addition I ported FLTK to DOS as well since FLTK can be used on the basis of Nano-X. So I am now used to FLTK.

Compared to the more common toolkits, FLTK suffers from a lack of applications. Which three FLTK applications that don’t exist (yet) do you miss the most?

I think FLTK is a GUI toolkit for developers, so it is not so important what applications are available based on FLTK.

If you look at my Nanolinux – given I add the NetRider browser and my FlMail program to the distro – it comes with all the main office applications done in FLTK. However, the quality of these applications is not as good as Libre Office, Firefox or Gimp. I do not expect anyone to write Libre Office with a FLTK GUI.

When you awake at night, a strange light surrounds you. The good FOSS fairy floats in the air before you! She can do absolutely everything FOSS related; whether it’s FLTK 3 being completed and released this year, a packaging standard that all Linux distros agree on or something a bit less unlikely. ๐Ÿ˜‰ She grants you three wishes!

As with FLTK 3 I wish it would change its name and the development would concentrate on FLTK 1.3.

Regarding the floating fairy I would wish the internet would be used by nice and friendly people only. Currently I see it endangered by massive spam, viruses, criminals and even cyber war as North Korea apparently did regarding the movie the ruling dictator wanted to stop being shown.

Back to serious. What do you think: Why is FLTK such a little known toolkit? And what could be done about that?

I do not think it is little known, just most people use GTK and so this is the “market leader”. If you work in a professional team this will usually decide to go for GTK since most members will be familiar with that.

What could be done about that? If KDE and Gnome would be based on FLTK I think the situation will change.

From your perspective of a developer: What do you miss about FLTK that the toolkit really should provide?

Frankly speaking, as a DOS developer the alternative would be to write your own GUI. And FLTK provides more features than you could ever develop on your own.

What I do not like is the lack of support for third party schemes. Dimitrj, a Russian FLTK developer who frequently posts as “kdiman” on the FLTK forums, created a very nice Oxy scheme. But it is not added to FLTK since the developers do not have the time to test all the changes he made to make FLTK look that good.

What do you think about the unfortunate FLTK 2 and the direction of FLTK 3?

I think these branches have been very unfortunate for FLTK. Many developers expected FLTK 2 to supersede FLTK 1.1 and waited for FLTK 2 to finish before developing an FLTK application. But FLTK 2 never got into a state where it could replace FLTK 1.1. Now the same seems to happen with FLTK 3.

So they should have named FLTK2/3 the XYZ-Toolkit and not FLTK 2 to avoid stopping people to choose FLTK 1.1.

Currently there is no development on FLTK 2/3 that I am aware of and I think the developers should concentrate on one version only. FLTK 1.3 works very well and does all that you need as a software developer as far as I can say.

Somebody with a bit of programming experience and some free time would like to get into FLTK. Any tips for him/her?

I wrote a tutorial which should allow even beginners in C++ programming to use FLTK successfully (Link here).


You’ve written quite a number of such applications yourself. Which of your projects is the most popular one (in terms of downloads or feedback)?

This is the Nanolinux distro. It has been downloaded 30.000 times this year.

NanoLinux… Can you describe what it is?

Let me cite Distrowatch, I cannot describe it better: Nanolinux is an open-source, free and very lightweight Linux distribution that requires only 14 MB of disk space. It includes tiny versions of the most common desktop applications and several games. It is based on the “MicroCore” edition of
the Tiny Core Linux distribution. Nanolinux uses BusyBox, Nano-X instead of X.Org, FLTK 1.3.x as the default GUI toolkit, and the super-lightweight SLWM window manager. The included applications are mainly based on FLTK.

After compiling the XFDOS distro I thought I would gain more users if I would port it to Linux. The size makes Nanolinux quite different from the others and I got a lot of downloads and reviews for it.

The project is based on TinyCore which makes use of FLTK itself. Is that the reason you chose this distro?

TinyCore was done by the former main developer of Damn Small Linux. So he had a lot of experience and did set up a very stable distro. Since I wanted to make a very small distro this was a good choice to use as a base. And I did not have to start from scratch and test that part of the distro forever.

NanoLinux uses an alternative windowing system. What can you tell us about the differences between NanoX and Xorg’s X11?

Nano-X is simply a tiny Xlib compatible library which has been used in a number of embedded Linux projects. Development started about 15 years ago as far as I recall. At that time many Linux application developers used X11 directly and therefore were willing to use an alternative like nano-X for their projects.

Since nano-X is not fully compatible to X11, a wrapper called NXlib was developed, which provides this compatibility and allows to base FLTK and other X11 applications on nano-X without code change. The compatibility is not 100% of cause, it is sufficient for FLTK and many X11 applications.

Since nano-X supported DOS in the early days I took this library and ported the current version to DOS again.


The project you are working on currently is NetRider, a browser based on webkit and FLTK. Please tell us how you came up with the idea for it.

Over the years I looked at other browser applications and thought how I could build my own browser, just out of interest. Finally Laura, another developer from the US, and I discussed it together. She came up with additional ideas and thoughts. That made me have a go at WebKit with FLTK.

What are your aims for NetRider?

I wanted to add a better browser to my Nanolinux distro replacing the Dillo browser. Also, as a FLTK user I wanted to provide a FLTK GUI for the WebKit package as an alternative to GTK and Qt.

There’s also the project Fifth which has quite similar aims at first sight. Why don’t you work together?

Lauri, the author of Fifth, and I started out about the same time with our FLTK browser projects, not knowing of each other’s plans. Now our projects run in parallel. Even though we both use FLTK, the projects are quite different.

We have not discussed working together yet and our objectives are different. He wants to write an Opera compatible browser and competes with the Otter browser while I am satisfied to come up with something better than Dillo.

I did not ask Lauri whether he thinks we should combine the projects. I am also not sure if this would help us both because we implemented different WebKit APIs for our browsers so we would have to make a WebKit library featuring two APIs. This could be done though. Also he is not interested in
supporting Windows which Laura and I want to support.

Would you say that NetRider is your biggest project so far? And what plans do you have for it?

Setting up Nanolinux and developing/porting all the applications for it was a big project too, and I plan to make a new release beginning of next year.

As with NetRider it depends if people like to use it or are interested to develop for / port it. Depending on the feedback I will make my plans. Recently I added some of the observations I got from beta testers, did support for additional languages, initial printing support etc.

The last one is yours: Which question would you have liked me to ask in addition to those and what is the answer to it?

I think you already asked more questions than I would have been able to come
up with. Thank you for the interesting questions.

Thanks a lot Georg, for answering these questions! Best wishes for your current and future projects!

What’s next?

I have a few things in mind… But I don’t know yet which one I’ll write about next. A happy new year to all my readers!

Tiny to the extreme: Nanolinux

It has been more than two years since I wrote about XFDOS, a graphical FreeDOS distribution with the FLTK toolkit and some applications for it (the project’s home is here.)

Mr. Potthast didn’t stop after this achievement however. Soon afterwards he published Nanolinux. And now I finally found the time to re-visit the world of tiny FLTK applications – this time on a genuine Linux system! And while it shows that it is closely related to XFDOS (starting with the wallpaper), Nanolinux does not follow the usual way at all according to which newer things are “bigger, badder and better”. It is rather “even smaller, more sophisticated and simple to use”!

I needed three attempts to catch the startup process properly because Nanolinux starts up very fast. Probably the most important difference from the DOS version is that Nanolinux can run multiple applications at the same time (which is something that goes without saying today). But there’s of course some more to it. If it weren’t then this review wouldn’t make much sense, would it?

The startup process of Nanolinux

TinyCore + NanoX + FLTK apps = Nanolinux?

Yes, that is what Nanolinux basically is. But that’s in fact more than you might expect. The first thing that is noteworthy is the size of Nanolinux: Just like the name suggests, it’s very small. It runs on systems with as little as 64 MB of RAM – and the whole iso for it is only 14 MB in size.

The Nanolinux desktop (second cursor is from the host machine)

While many people will be impressed by this fact I can hear some of you yawn. Don’t dismiss the project just yet! It’s true that people have stuffed some Linux 2.2 kernel on a single floppy and still had enough space remaining to pull together a somewhat usable system. But Nanolinux can hardly be compared to one of these. You have a Linux 3.0 kernel here – and it features a graphical desktop together with a surprisingly high amount of useful applications!


Speaking of applications: Most of which are part of XFDOS can be found in Nanolinux, too, like e.g. FlWriter, FlView and Dillo. There are just a few exceptions as well: The DOS media player, PDF viewer etc. However there are also a few programs on board which you don’t know from the graphical DOS distribution. I’m going to concentrate on these.

Showing off the Nanolinux menu

A nice one is the system stats program: As you would expect it gives you an overview of system ressources like CPU and RAM usage. But it does a lot more than that! It also lists running processes, shows your mounts, can display the dmesg – and more. Pretty useful small tool!

Then we have Fluff from TinyCore. It is a minimalist file manager. Don’t start looking for icons or things like that. It follows a text-based approach you may know in form of some console file manager. It’s small but functional and works pretty well once you get used to it.

System stats and the Fluff file manager

Want to communicate with others on the net? Not a problem for Nanolinux. While it comes with Dillo, this browser is not really capable of displaying today’s websites correctly. But Nanolinux also has FlChat – a complete IRC client! So it allows you to talk to people all over the world without much trouble.

FlChat – a FLTK IRC client!

Or perhaps you want to listen to music? In this case you’ve got the choice between two FLTK applications: FlMusic and FlRadio. The former is a CD player and the second let’s you listen to web radio stations. Since Nanolinux runs from RAM after it has started, it is no problem to eject the CD and put in some audio CD of your choice instead.

FlMusic and FlRadio for your ears


Even though that’s a pretty formidable collections of programs, there’s of course always the point where you need something Nanolinux does not provide. Like it’s mother, TinyCore, Nanolinux supports Extensions in this case. These are binary packages which can add pre-build applications to your system.

Let’s imagine you want to burn a CD. Nanolinux has an extension for FlBurn available. After clicking on it from the extension list, the system downloads and installs the extension. Once this is finished, FlBurn will be available on the system.

FlBurn installed from the extensions

There are a few extensions available for you. And what to do if you need a program that has not been packaged for Nanolinux? Well, you can always try to build it yourself. If you feel like it, there’s the compile_nl package for you which provides what you need.

Don’t be too ambitious however! Nanolinux comes with Nano-X, remember? That means any program which depends on some Xorg library won’t compile on your system. You’ll just end up with an error message like the one shown in the screenshot below!

Compiling your own packages with “compile_nl”


Nanolinux builds upon the core of the TinyCore Linux distribution – and while it remains below the ordinary TinyCore in size, it comes with many useful applications by default. It can run on a system with as little as 64 MB of RAM and is extensible if you need any programs which did not fit into the 14 MB iso image.

This little distribution can do that thanks to the use of Nano-X (think X11’s little brother) and a special version of the FLTK toolkit modified to cope with that slim windowing system. It is definitely worth a try if you’re at all into the world of minimalism. And even if you’re not – it can be a nice playing around just to see what is possible.

What’s next?

While I do have something in mind which would be fitting after this post, I’m not completely sure that I’ll manage to get it done within the remaining time of this year. Just wait and see!

GTK-based applications #1: Terminal emulators summary (3/3)

Here’s the summary of the GTK terminal emulator test. It provides four tables for easier comparison of the results.

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 Lwt 20130625
02 Mt .1
03 Lilyterm
04 Ftjerm 0.12.3
05 MLTerm 3.2.0
06 Stjerm 0.16_19
07 Tinyterm svn-20100223
08*) Lxterminal 0.1.11
09 QuTerm 0.1
09 Tilda git-20130625
10 vTerminal 13
11 Sakura 3.0.4
12 Evilvte 0.5.1
12 Termite 6
12 Xfce4-Terminal 0.6.2
13 ROXTerm 2.7.2
14 Gnome-Terminal 3.8.3
15 Dwt 0.3

*) Needed disk space not measured for Lxterminal

RAM usage

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

<110 MB 110 – 115 MB 116 – 120 MB >120 MB
Rank DE Version Memory usage
01 Lwt 20130625 106 MB
01 MLTerm 3.2.0 106 MB
02 Lilyterm 107 MB
02 Tilda git-20130625 107 MB
03 Lxterminal 0.1.11 108 MB
03 Mt .1 108 MB
03 Stjerm 0.16_19 108 MB
04 Ftjerm 0.12.3 109 MB
04 QuTerm 0.1 109 MB
04 Tinyterm svn-20100223 109 MB
05 Termite 6 113 MB
05 vTerminal 13 113 MB
06 Sakura 3.0.4 114 MB
07 Evilvte 0.5.1 115 MB
08 ROXTerm 2.7.2 117 MB
08 Xfce4-Terminal 0.6.2 117 MB
09 Dwt 0.3 120 MB
10 Gnome Terminal 3.8.3 121 MB

Drive space needed

Here’s the next table:

<5 MB 5 – 10 MB 11 – 100 MB >100 MB
Rank DE Version Disk space used
00 Lxterminal 0.1.11 not measured
01 Lwt 20130625 +4.6 MB
01 Ftjerm 0.12.3 +4.6 MB
02 Lilyterm +5.3 MB
03 Mt .1 +8.0 MB
04 Tinyterm svn-20100223 +12 MB
04 Stjerm 0.16_19 +12 MB
05 Tilda git-20130625 +13 MB
05 QuTerm 0.1 +13 MB
05 vTerminal 13 +13 MB
06 Xfce4-Terminal 0.6.2 +17 MB
07 Evilvte 0.5.1 +104 MB
08 Sakura 3.0.4 +109 MB
09 Gnome-terminal 3.8.3 +111 MB
09 Termite 6 +111 MB
10 ROXTerm 2.7.2 +113 MB
11 MLTerm 3.2.0 +115 MB
12 Dwt 0.3 +137 MB

Download size

And here’s the last one:

<50 KB 51 – 500 KB 501 KB – 5 MB >5 MB
Rank DE Version size
01 Lwt 20130625 ~4 KB
01 Mt .1 ~4 KB
01 Tinyterm svn-20100223 ~4 KB
02 QuTerm 0.1 ~5 KB
03 Stjerm 0.16_19 ~20 KB
04 Ftjerm 0.12.3 ~25 KB
05 vTerminal 13 ~53 KB
06 Lxterminal 0.1.11 ~70 KB
07 Lilyterm ~160 KB
08 Tilda git-20130625 ~193 KB
09 Xfce-4-Terminal 0.6.2 ~699 KB
10 Evilvte 0.5.1 ~14,6 MB
10 Sakura 3.0.4 ~14,6 MB
11 ROXTerm 2.7.2 ~14,7 MB
12 Termite 6 ~14,9 MB
13 Gnome-terminal 3.8.3 ~15,7 MB
14 Dwt 0.3 ~16,6 MB
14 MLTerm 3.2.0 ~16,6 MB


The range of needed RAM on startup is not very large. Still on machines which have little memory available it makes a huge difference if the system with LXDE and a terminal emulator on top of it needs 106 MB or 121 MB of RAM! The range of drive space needed is a lot larger. Here it’s primarily GTK2 applications vs. GTK3 ones. Same thing for the download size: GTK3 brings in a few dependencies which means there’s quite a bit more to download.

What’s next?

The post will begin with a GTK+ file manager test.

An interview with the EDE developer

It’s summer solstice today and thus the longest day of the year. I promised something special and here it is: Sanel Zukan, the man behind the Equinox Desktop Environment (EDE) agreed to give me an interview (or to answer a few questions if you will).

If you’re not familiar with EDE, I tried to summarize it up for you before the interview.

EDE in short

What is EDE? It is a full DE you might not even have heard of despite it being one of the older *nix desktop environments. Of course it’s older than Unity, MATE, Razor-qt and the likes. But it is also older than LXDE and – hard to believe – E17! At the same time it’s more light-weight than any of these – including the ones which were created as light-weight alternatives themselves.

Said DE is something special. Where others talk about being light-weight, EDE seriously means it and takes the gloves off. Not making any compromise, it’s the only full DE which is based on FLTK (Fast Light Toolkit), a GUI toolkit which also lives up to its name.

Not being packaged by any major distribution, today EDE is mainly used on older pcs or other systems which are low on resources. It doesn’t provide its own applications for everything nor does it want to. Driven forward more or less by one lone fighter, it surely doesn’t have to hide and fear comparison with other DEs. Taunted as “poor man’s KDE” by some and appreciated as an insider’s tip without all the knick-knack by others it’s just going its way. And if it rightfully deserves one label that would be “No bloat here”. Seriously.

Interview with Sanel Zukan

The following interview was conducted by email.

Please introduce yourself first: Who are you, how old are you and where are you from?

I’m 32, from Sarajevo. By day I’m doing java/python stuff for a small local company and by night I try to hack various OSS projects; of course EDE, too.

Do you have any special interests aside the IT sector you would like to mention here?

Martial arts! ๐Ÿ™‚ It is quite challenging to combine IT work with regular training …

For how long have you been using Linux?

Let’s see… For approximately 10 years.

Which is your distribution of choice and why?

Slackware. Because it is simple, lean and very, very stable. I really admire Patrick (Slackware author and maintainer) because he is showing us how a complex project can be and should be maintained.

Is there anything in the Linux or FOSS world you are not really happy with?

The idea to reinvent the wheel all over again. PulseAudio, systemd, gdbus, kdbus, *Kit, are some examples. Instead of improving the current state, those guys focus on rewriting it, making another set of mistakes which brings the full idea back to the beginning: a half balked product.

Also this is quite hard to follow from a developer’s perspective because APIs are changing often; no wonder that developers are going to OS X or *BSD land. This whole way of thinking makes Linux look bad, especially from a novice user’s perspective.

There are more than 15 desktop environments in use in the Linux world. Why did you decide to dedicate your time to EDE?

I like fast, simple and responsive environments without much of bloat that don’t get in your way. Desktops should be invisible and the user should be able to focus on daily tasks more than on desktop effects.

And I like to revive old computers: they are still usable for daily tasks so why to throw them away? Now, the last thing on those computers you want is a desktop that eats all of your memory or cpu power.

What can you tell us about early EDE?

Not much because I’m not familiar with its early history. When I came in, the project was pretty much dead and all original developers had left it. Not sure about the reasons because I never got any reply from them.

What do you think were the most remarkable achievements of versions 1.x?

The project gained some traction and people started to talk about it. One of the reasons for this were regular releases (5-6 months).

Most developers retired from working on EDE. Can you tell us the reason for that? Was it due to technical problems? Real-life issues? Or perhaps the fact that EDE never became popular and remained an underdog to this day?

Maybe a little bit of everything. Working on a desktop isn’t an easy task because there are a lot of pieces involved in it: UI development, low-level stuff, application incompatibilities, etc. Also, doing it in your free time requires dedication.

Do you still have contact with the retired devs and do you know if they still care for EDE (though not actively participating)?

Only with Vedran. Others (except Dejan) never bothered to even reply to my mails.

You took over EDE – and managed to rebuild the DE from scratch with version 2.0. Why did you continue to work on it and did anybody help you? Where did you draw your motivation from?

Sure, there are a lot of people who come and go, give some ideas, fix issues; this project would not be alive without their help that’s for sure. Why do I continue to work on it? Because there is no desktop that satisfies my needs: be simple and stable. And it is fun.

“eFLTK” – can you tell us what that was and why it was created?

eFLTK was a fork of the never-released FLTK 2.0 and it was created with the idea to speed up FLTK 2.0 development and make desktop development easier.

FLTK, following true UNIX philosophy, is a GUI only toolkit and you need much more for a functional desktop environment. That is the main reason I still prefer FLTK over other popular GUI libraries; I’m paying only for what I use.

This modified toolkit was one of the main reasons to start over with 2.0, right?

Yes. Maintaining a desktop and a complex toolkit (eFLTK got a tons of new stuff) isn’t an easy task so we decided to drop it and go on using something with much better support.

Why are you using FLTK? Why not for example FOX (which has its own desktop project that however seems to go nowhere)?

Probably by accident. ๐Ÿ™‚ When I started to use and develop for Linux, I didn’t have much experience with UI development, so I searched for something that is easy to pick up, small enough to grasp and have good OpenGL support.

I needed OpenGL because, in that time, I tried to build some level design tool for my pet game.

According to their site, LXDE considered using FLTK as well. In the end it was rejected in favour of GTK+ because it offered too little internationalization support. What about EDE in this regard?

One of the main reasons why we pushed eFLTK for so long is because FLTK 1.1.x, in that time, didn’t have UTF-8 support, which is probably the reason why the LXDE guys ditched it.

Do you use EDE on a daily basis? What other DEs do you like?

Yes. I’m using it on all my computers, including on work; that is why I’m focused on stability so much. It is not good idea to lose all of your daily work because of a bug in the WM or panel.

Other DEs I like? I like ร‰toilรฉ ( because they are doing some really cool stuff; I’m not sure what the current status is because the project looks dead to me, which is quite sad.

Those who followed the development of EDE mostly thought that the project was dead when all of a sudden 2.0 final was released. What had happened?

We (Vedran and I) went silent to focus on 2.0 development and release it as soon as possible. It took some time because there was a lot of work to do, and we did it twice!

To explain this, I need to tell some of FLTK’s history which greatly affected EDE. FLTK project had two main branches, stable 1.1.x and 2.0.

FLTK 2.0 promised a lot of new and shiny things, like namespace support, UTF-8, advanced X stuff (RandR, Render and etc.). EDE initially started to use FLTK 2.0 (even before I joined) which was forked at some point and eFLTK created.

After some talk with the FLTK 2.0 devs, they promised us to make a release soon; we ditched eFLTK, started to rewrite EDE in FLTK 2.0 and started to contribute to that toolkit.

Unfortunately that library (as if it was cursed) never got released. I got really mad and rewrote everything (with Vedran’s help) again in FLTK 1.1.x and never regretted it. This should have been done long time ago.

Are you happy with 2.0 in general?

Pretty much.

What about EDE users – do you get a lot of feedback? Are there any features which are often asked for?

Yes; I’m getting more feedback by mail than on the EDE forum, which isn’t good as people new to the project tend to think it is inactive. However, I understand why people sent me the mails: SourceForge forums are extremely bad and they get a reply much faster. ๐Ÿ™‚

Main features asked for are more configuration support, a file manager and support for internationalization. Funny thing: no one ever asked for compositing or blinky blinky stuff.

EDE 2.1 is on its way and might be available soon. What new features can EDE users expect from it?

More stability, more speed and tons of little improvements including full panel configuration.

Let’s talk about the future. What are your plans for EDE after 2.1? What is your “goal” with EDE?

Truth to be told, after the 2.0 rewrite I learned not to do any big changes anymore but small incremental ones instead. So after 2.1 I’m planning to add a File Manager, fix remaining bugs and add more DBus support.

Ultimate goal? I really like and admire Smalltalk environments (like Pharo) where you can change, adapt or remove programmatically any part of it. I would like to add some of those things in EDE but it will be quite challenging, because Pharo is powered by Smalltalk and EDE is done in C++ which isn’t suited for runtime dynamism. That is why I added a Scheme interpreter and plan to use it more often in the future.

A little statistics: How many daily hits does the project homepage currently have in average?

Huh not sure; the last time I checked EDE had ~5000 hits per hour; now if half of that are bots, the stats aren’t bad considering the last release was a year ago and the project isn’t mentioned much in the media.

However, there are very big peeks each time a new version is released.

What do you think are the reasons for EDE to be still quite unknown among Linux users despite existing for more than 10 years? How to change this fact?

Probably a few things:

1) lack of frequent, predictable releases
2) more advertizing
3) support from a big company

If you remember, LXDE gained wide traction when RedHat created a Fedora spin for LXDE.

There’s also the FLTK applications project – but it hasn’t really released anything, yet. Do you know anything about that or about any FLTK applications in the making?

Not much. It was probably some attempt to document and collect popular applications, but never got significant traction. Probably one of the reasons is that more people develop commercial applications with FLTK, because it still has a quite liberal license.

You awake at night, a strange light surrounding you. The good FOSS fairy is floating in the air before you! She can do absolutely everything FOSS related; whether it’s doxygen with zero dependencies, FLTK 2 revived and actively developed or something a little less unlikely. ๐Ÿ˜‰ She grants you three wishes!

LOL. Well:

1) Live kernel update
2) File system with good snapshot and history support (like ZFS)
3) Webkit with FLTK backend

Ok, back to serious. A coder with some time on his hands is searching for a new project. He stumbles over EDE and likes it. If he asked you how he could help with it what would you advice him to do?

He could try to fix things he don’t like or create applications he would like to see. I’m always open to ideas and ready to give some guidance.

Which FLTK application that was never made do you miss the most?

Webkit with an FLTK backend. There was some project a long time ago including even a screenshot, but author never made any code public.

Why was EDE’s own WM replaced with PekWM? What are your plans for the future of the WM used in EDE?

To speed up the release. Developing a WM from the scrach, or porting it to another toolkit, is quite time-consuming so I used pekwm as temporal replacement. There are plans to replace it, but I’m not thinking about it right now, because there are more important things to be done, like the file manager.

Thanks a lot for taking the time to answer these questions – and of course for EDE! I wish you success with your further work on it.

What’s next?

My next blog entry will be about EERIE turning 1 year old and about what has been accomplished so far.

Qt-based applications #3: Text Editors (2/2)

The last blog entry was about a test of 9 Qt-based text editors (those which I could get to run on Arch Linux). And since the comparison of so many programs and values is not really an easy thing, here’s a second post providing some tables which show the programs sorted not by name but by values.

Overall ranking

Here’s the table with the overall results. The text editors were compared 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:

Rank Text editor Version
01 Minerva GIT20130220
02 CuteNotes 0.9
03 TEA editor 34.0.1
04 Catlooking Writer 1.0
05 JuffEd 0.8.1
06 FocusWriter 1.4.1
07 KoalaWriter 1.0
08 Marave 0.7
09 kWrite 4.10

RAM usage

Here’s the table comparing memory use:

<10 MB 10 – 25 MB 26 – 50 MB > 50 MB
Rank Text editor Version
01 Minerva GIT20130220 4 MB
02 TEA editor 34.0.1 6 MB
03 Cutenotes 0.9 8 MB
03 JuffEd 0.8.1 8 MB
04 Catlooking Writer 1.0 15 MB
05 FocusWriter 1.4.1 26 MB
06 KoalaWriter 1.0 36 MB
07 kWrite 4.10 64 MB
08 Marave 0.7 78 MB

Drive space needed

Here’s the drive space table:

<20 MB 20 – 100 MB 101 – 200 MB > 200 MB
Rank Text editor Version Disk space used
01 Cutenotes 0.9 +1 MB
02 Catlooking Writer 1.0 +2 MB
03 Minerva GIT20130220 +5 MB
04 TEA editor 34.0.1 +6 MB
05 JuffEd 0.8.1 +7 MB
06 FocusWriter 1.4.1 +9 MB
07 Marave 0.7 +154 MB
08 KoalaWriter 1.0 +363 MB
09 kWrite 4.10 +582 MB

Download size

And the download size table:

<1 MB 1 – 10 MB 11 – 50 MB >50 MB
Rank Text editor Version size
01 CuteNotes 0.9 +143 KB
02 Minerva GIT20130220 +319 KB
03 JuffEd 0.8.1 +973 KB
04 Catlooking Writer 1.0 +1.2 MB
04 TEA editor 34.0.1 +1.2 MB
05 FocusWriter 1.4.1 +2,4 MB
06 Marave 0.7 +24 MB
07 KoalaWriter 1.0 +77 MB
08 kWrite 4.10 +126 MB


When it comes to Qt-based text editors, we can see huge differences between them. With Minerva there’s an editor that really deserves the MIN in its name: It does good in all aspects and is the winner in this test. Rank 4 for the Catlooking Writer shows that even those non-distracting writers don’t necessarily have to be extremely resource-hungry. And well, no surprise: kWrite scores the last rank since it depends on the super-heavy kdelibs.

What’s next?

Next I’d like to pick up the DDD again and create a new version. Then I’ll examine the basic GTK+ applications.

This post was written on 02/27 and automatically published. If I didn’t remove that line that means that I still don’t have a working internet connection.

Qt-based applications #3: Text Editors (1/2)

In this post we’ll take a look at some Qt-based text editors. Just like with the file managers I’ll split my post in two parts because there’s quite a number (I found 15!) of such editors out there.

While compiling my list of Qt-based editors, I came across something I hadn’t heard of before. A kind of application which is called non-distracting writer. At first I wasn’t sure whether to include these here, but they don’t fit into the category “Office application” either.
From my point of view they are close enough to text editors to include them here (they are written with the idea that the text is the only thing really important – and that’s pretty much what qualifies them as a text editor, though not a classical one).

The candidates

Here are the text editors that were tested (in alphabetical order):

Not tested

Many of the editors didn’t work right away. I got some of them to work in the end, but these are the ones that wouldn’t work at all and thus were not tested:

If anybody can get one or more of these to work on Arch, please let me know (send me PKGBUILDs?). And also tell me if you think that I forgot anything interesting!

Testing system

For this test I’ve set up the VMs as in my first Qt application test + Virtualbox guest additions this time. Here are the new values:

Arch Linux + Razor-qt (0.5.1)
MemTotal: 4052828 kb
MemFree: 3810544 kb
Buffers: 9972 kb
Cached: 80280 kb
Rootfs: 936560 / 915
RAM used at startup: 242284 / ~237 MB

Catlooking Writer

The Catlooking Writer is a non-distracting writer based on Qt. It’s a full-screen application that’s intended to let you focus on the text only.

Razor-qt with Catlooking Writer


pacman -U catlooking-git-20130217-1-x86_64.pkg.tar.xz (1222156 Bytes / 1,2 MB)


Memory usage after starting up Razor-qt and opening Catlooking Writer via the menu (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+ Catlooking Writer 1.0
MemTotal: 4052828 kb
MemFree: 3795300 kb
Buffers: 9992 kb
Cached: 87616 kb
Rootfs: 938696 / 917M
RAM used at startup: 15244 / ~15 MB
Disk space (less razor system): 2136 / ~2 MB


CuteNotes is a simple text editor based on Qt.

Razor-qt with CuteNotes


pacman -U cutenotes-1.0-1-x86_64.pkg.tar.xz (142740 Bytes / 142,7 kB)


Memory usage after starting up Razor-qt and opening CuteNotes via the menu (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+ CuteNotes 0.9
MemTotal: 4052828 kb
MemFree: 3802112 kb
Buffers: 9988 kb
Cached: 82472 kb
Rootfs: 937596 / 916M
RAM used at startup: 8432 / ~8 MB
Disk space (less razor system): 1036 / ~1 MB


FocusWriter is a full-screen, non-disctracting text editor based on Qt. It offers basic support for formats like RTF and ODT, too.

Razor-qt with FocusWriter


pacman -U focuswriter-1.4.1-1-x86_64.pkg.tar.xz (721800 Bytes / 721,8 kB)
(other packages downloaded as dependencies: 1720320 Bytes / 1,7 MB)


Memory usage after starting up Razor-qt and opening FocusWriter via the menu (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+ FocusWriter 1.4.1
MemTotal: 4052828 kb
MemFree: 3784348 kb
Buffers: 10472 kb
Cached: 89492 kb
Rootfs: 946180 / 925M
RAM used at startup: 26196 / ~26 MB
Disk space (less razor system): 9620 / ~9 MB


JuffEd is a tabbed editor with syntax highlighting based on Qt.

Razor-qt with JuffEd


pacman -s juffed (972800 Bytes / 972,8 kB)


Memory usage after starting up Razor-qt and opening JuffEd via the menu (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+ JuffEd 0.8.1
MemTotal: 4052828 kb
MemFree: 3801856 kb
Buffers: 10272 kb
Cached: 88012 kb
Rootfs: 943344 / 922M
RAM used at startup: 8688 / ~8 MB
Disk space (less razor system): 6784 / ~7 MB


The KoalaWriter is a non-distracting writer based on Qt. It offers beautiful backgrounds and can even play relaxing music so that you can completely stick to what’s actually important: Your text! It’s a bit heavy-weight, though.

Razor-qt with KoalaWriter


pacman -koalawriter-1.0-1-x86_64.pkg.tar.xz (16714076 Bytes / 16,7 MB)
(other packages downloaded as dependencies: 60160000 Bytes / 60,2 MB)


Memory usage after starting up Razor-qt and opening KoalaWriter via the menu (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+ KoalaWriter 1.0
MemTotal: 4052828 kb
MemFree: 3774164 kb
Buffers: 11544 kb
Cached: 100784 kb
Rootfs: 1308516 / 1.3G
RAM used at startup: 36380 / ~36 MB
Disk space (less razor system): 371956 / ~363 MB


kWrite is the default text editor of KDE. It’s quite a bit on the heavy side.

Razor-qt with kWrite


pacman -S kdebase-kwrite (126095360 Bytes / 126,1 MB)


Memory usage after starting up Razor-qt and opening kWrite via the menu (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+ kWrite 4.10
MemTotal: 4052828 kb
MemFree: 3745412 kb
Buffers: 17548 kb
Cached: 108860 kb
Rootfs: 1532732 / 1.5G
RAM used at startup: 65132 / ~64 MB
Disk space (less razor system): 596172 / ~582 MB


Marave is a non-distracting writer based on Qt. It’s meant to let the user focus on the text rather than the application.

Razor-qt with Marave


pacman -U marave-0.7-6-any.pkg.tar.xz (1011384 Bytes / 1,0 MB)
(other packages downloaded as dependencies: 23367680 Bytes / 23,4 MB)


Memory usage after starting up Razor-qt and opening Marave via the menu (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+ Marave 0.7
MemTotal: 4052828 kb
MemFree: 3730568 kb
Buffers: 11232 kb
Cached: 121844 kb
Rootfs: 1093932 / 1.1G
RAM used at startup: 79976 / ~78 MB
Disk space (less razor system): 157372 / ~154 MB


Minerva is a tiny tabbed text editor based on Qt.

Razor-qt with Minerva


pacman -U minerva-git-20130220-1-x86_64.pkg.tar.xz (319276 Bytes / 319,3 kB)


Memory usage after starting up Razor-qt and opening Minerva via the menu (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+ Minerva GIT20130220
MemTotal: 4052828 kb
MemFree: 3806888 kb
Buffers: 9988 kb
Cached: 81580 kb
Rootfs: 942040 / 920M
RAM used at startup: 3656 / ~4 MB
Disk space (less razor system): 5480 / ~5 MB

Tea Editor

The Tea Editor is an advanced editor based on Qt. It offers a lot of features and is still both small in size and frugal in terms of ram usage.

Razor-qt with Tea Editor


pacman -S tea (1239040 Bytes / 1,2 MB)


Memory usage after starting up Razor-qt and opening Tea via the menu (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+ Tea editor 34.0.1
MemTotal: 4052828 kb
MemFree: 3804856 kb
Buffers: 10172 kb
Cached: 84644 kb
Rootfs: 942756 / 921M
RAM used at startup: 5688 / ~6 MB
Disk space (less razor system): 6196 / ~6 MB

What’s next?

My next post will provide tables which will make it easier to compare the important values of the programs tested here.

Don’t worry if it takes me a while to publish it – I’m moving houses so time is an even more scarce resource than usually and I might be left without a working internet connection for a while.

Qt-based applications #2: File managers (2/2)

In the last blog entry I tested 8 Qt-based file managers (those which I got to run on Arch Linux). Since that’s quite a bit of stuff, I’d like to present a nice table in this post for easier comparison.

Overall ranking

Here’s the table with the overall results. The file managers were compared 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:

Rank File manager Version
01 Dfilebrowser 1.1
02 ScOpe GIT20130121
03 QtFM 5.1
04 Dino 0.5
05 NewBreeze 1.1.1
06 Andromeda 0.2.1
07 Hamsi Manager 1.1
08 Dolphin 4.9.5

RAM usage

Here’s the table comparing memory use:

<250 MB 251 – 275 MB 276 – 300 MB > 300 MB
Rank File manager Version
01 Dfilebrowser 1.1 230 MB
02 ScOpe GIT20130121 233 MB
03 QtFM 5.1 236 MB
04 Dino 0.5 240 MB
05 NewBreeze 1.1.1 252 MB
06 Andromeda 0.2.1 260 MB
07 Hamsi Manager 1.1 305 MB
08 Dolphin 4.9.5 306 MB

Drive space needed

Here’s the drive space table:

<50 MB 50 – 100 MB 101 – 300 MB > 300 MB
Rank File Manager Version Disk space used
01 Dfilebrowser 1.1 +2 MB
02 Dino 0.5 +3 MB
02 QtFM 5.1 +3 MB
02 ScOpe GIT20130121 +3 MB
03 Andromeda 0.2.1 +64 MB
04 NewBreeze 1.1.1 +74 MB
05 Hamsi Manager 1.1 +295 MB
06 Dolphin 4.9.5 +598 MB

Download size

And the download size table:

<5 MB 6 – 25 MB 26 – 50 MB >50 MB
Rank File Manager Version size
01 Dfilebrowser 1.1 +70 KB
02 QtFM 5.1 +200 KB
03 ScOpe GIT20130121 +243 KB
04 Dino 0.5 +256 KB
05 NewBreeze 1.1.1 +528 KB
06 Andromeda 0.2.1 +13 MB
07 Hamsi Manager 1.1 +51 MB
08 Dolphin 4.9.5 +109 MB


Not too many surprises here. There are some light-weight file managers and a few which offer more features but are also much more heavy weight. Especially in terms of drive space needed and download size the light-weight ones are rather close to each other. Because of that the RAM comparison came out to be identical to the overall rating. Dfilebrowser is the clear winner in our comparison – it scored the first rank in all three categories. ScOpe and QtFM are doing very well, too. Hamsi Manager is a rather ressource heavy file manager and it’s not surprising either that KDE’s Dolphin is the most heavy of the tested applications.

What’s next?

The next entry will take a look at the Qt-based text editors (of which there’s also quite some around).

Qt-based applications #2: File managers (1/2)

In this post we’ll take a look at some Qt-based file managers. Since there’s quite a lot of them, let’s start right away!

All screenshots from this entry on are in 1024×768 resolution. So if you click on any of the pictures you’ll get a bigger one where you might actually see something…

The candidates

Here are the file managers that were tested (in alphabetical order):

Not tested

Some of the file managers didn’t work right away. These are the ones that I could not get to work at all and that were not tested:

  • Double Commander (“Total Commander” inspired. Would have been especially interesting since it’s written in Pascal. However it won’t compile on my current Arch VM.)
  • Qefem (Won’t compile.)
  • QtCommander (Also “TC” inspired. Doesn’t work with Qt4.)
  • QtFileMan (Won’t compile.)
  • Synopson (Available as binary only, no source. Unacceptable.)

If anybody can get one or more of these to work on Arch, please let me know (send me PKGBUILDs?). And also tell me if you think that I forgot anything interesting!

Testing system

For this test I’m using the same VM as in my previous Qt application test. I haven’t updated it since then.


Andromeda is a cross-platform file manager based on Qt.

Razor-qt with Andromeda


pacman -U andromeda-0.2.1-1-x86_64.pkg.tar.xz (1094280 Bytes / 1,1 MB)
(other packages downloaded as dependencies: 11448320 Bytes / 11,4 MB)


Memory usage after starting up Razor-qt and opening Andromeda via the menu (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+ Andromeda 0.2.1
MemTotal: 4053592 kb
MemFree: 3787652 kb
Buffers: 10716 kb
Cached: 97100 kb
Rootfs: 960924 / 939M
RAM used at startup: 265940 / ~260 MB
Disk space (less razor system): 66000 / ~64 MB


Dfilebrowser is a Qt file manager meant for mobile devices – but of course it works on the pc, too.

Razor-qt with Dfilebrowser


pacman -U dfbrowser-17-1-x86_64.pkg.tar.xz (68688 Bytes / 68,7 kB)


Memory usage after starting up Razor-qt and opening Dfilebrowser via the menu (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+ Dfilebrowser 1.1
MemTotal: 4053592 kb
MemFree: 3817596 kb
Buffers: 10148 kb
Cached: 76348 kb
Rootfs: 897172 / 877M
RAM used at startup: 235996 / ~230 MB
Disk space (less razor system): 2248 / ~2 MB


Dino is simple Qt file manager that does however come with some nice features (like a built-in text editor and such).

Razor-qt with Dino


pacman -U dino-dfm-0.5-1-x86_64.pkg.tar.xz (256116 Bytes / 256,1 kB)


Memory usage after starting up Razor-qt and opening Dino via the menu (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+ Dino 0.5
MemTotal: 4053592 kb
MemFree: 3807736 kb
Buffers: 10468 kb
Cached: 79112 kb
Rootfs: 898044 / 877M
RAM used at startup: 245856 / ~240 MB
Disk space (less razor system): 3120 / ~3 MB


Dolphin is the standard file manager of KDE. As such it has a lot of dependencies and is very heavy!

Razor-qt with Dolphin


pacman -S kdebase-dolphin (108677120 Bytes / 108,7 MB)


Memory usage after starting up Razor-qt and opening Dolphin via the menu (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+ Dolphin 4.9.5
MemTotal: 4053592 kb
MemFree: 3739960 kb
Buffers: 17320 kb
Cached: 124660 kb
Rootfs: 1507336 / 1.5G
RAM used at startup: 313632 / ~306 MB
Disk space (less razor system): 612412 / ~598 MB

Hamsi Manager

The Hamsi Manager is an advanced Qt file manager with a lot of extras.

Razor-qt with Hamsi Manager


pacman -U hamsimanager-1.1-1-any.pkg.tar.xz (1173980 Bytes / 1,2 MB)
(other packages downloaded as dependencies: 49428480 Bytes / 49,4 MB)


Memory usage after starting up Razor-qt and opening Hamsi Manager via the menu (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+ Hamsi Manager 1.1
MemTotal: 4053592 kb
MemFree: 3741396 kb
Buffers: 14596 kb
Cached: 107632 kb
Rootfs: 1197212 / 1.2G
RAM used at startup: 312196 / ~305 MB
Disk space (less razor system): 302288 / ~295 MB


NewBreeze is a reasonably light-weight Qt file manager.

Razor-qt with NewBreeze


pacman -U newbreeze-1.1.1-2-x86_64.pkg.tar.xz (528288 Bytes / 528,3 kB)


Memory usage after starting up Razor-qt and opening NewBreeze via the menu (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+ NewBreeze 1.1.1
MemTotal: 4053592 kb
MemFree: 3795320 kb
Buffers: 10776 kb
Cached: 93268 kb
Rootfs: 969916 / 948M
RAM used at startup: 258272 / ~252 MB
Disk space (less razor system): 74992 / ~74 MB


QtFM is meant as a light-weight Qt file manager but it is already a bit on the heavy side. However it’s rather feature rich.

Razor-qt with QtFM


pacman -S qtfm (200108 Bytes / 200,1 kb)


Memory usage after starting up Razor-qt and opening QtFM via the menu (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+ QtFM 5.5
MemTotal: 4053592 kb
MemFree: 3811512 kb
Buffers: 10312 kb
Cached: 79556 kb
Rootfs: 897684 / 877M
RAM used at startup: 242080 / ~236 MB
Disk space (less razor system): 2976 / ~3 MB


ScOpe is the file manager that belongs to the “Sapphire Desktop” project. It’s developed with focus on usability.

Razor-qt with ScOpe


libdelta-git-20130121-1-x86_64.pkg.tar.xz (139548 Bytes / 139,5 kB)
scope-git-20130121-1-x86_64.pkg.tar.xz (103936 Bytes / 103,9 kB)


Memory usage after starting up Razor-qt and opening ScOpe via the menu (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+ ScOpe GIT20130121
MemTotal: 4053592 kb
MemFree: 3815308 kb
Buffers: 10300 kb
Cached: 78244 kb
Rootfs: 898332 / 878M
RAM used at startup: 238284 / ~233 MB
Disk space (less razor system): 3408 / ~3 MB

Whatโ€™s next?

Since all these values can be a bit confusing, I’ll dedicate another post to the file managers. The next one will feature a table so that comparison is easy. That’s why this post goes without a conclusion for a change.

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.


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 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).


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, 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.


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’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 (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!


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


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).