3+ months on TrueOS – a critical write-up

My journey into the *nix world has not been a completely straight forward one. I’ve used Linux (various distributions) exclusively for quite some time before I felt that more and more things were heading in the wrong direction. Sure, it’s all open source and I could do things my own way. In fact I did roll my own distribution for a short period of time but this was more because I wanted to experiment with things. And while there are examples (like Void Linux) that prove that a single person can keep a serious distro running, I’m far from having the knowledge nor the time (or even the urge) to do so. But even if I had all that there’s something wrong with parts of the Linux ecosystem and community that I don’t feel is fixable at the moment.

For those reasons I was pretty open to new things when I encountered actual FreeBSD servers at work. I came to love the *BSD way of doing things and used FreeBSD and OpenBSD systems on laptops and in VMs to play around with. In January I decided to put PC-BSD on my main machine but had to leave it for Linux again pretty soon, for various reasons. Over the time I really wanted my BSD back and get rid of the Linux trouble (that used not to bug me as I knew nothing better). I’ve written about my experience with PC-BSD and Linux again in my previous post in some detail. The time to give a FreeBSD based desktop another try came when TrueOS was released. So that’s what this article is about: Using TrueOS as your daily driver for some months!

TrueOS in general

When I found out about TrueOS sometime in July, I was very curious how different it would be from PC-BSD. So I downloaded the ISO and installed the OS on my primary machine (no risk no fun, right?). The installation went as smooth as it did with PC-BSD. My hardware was supported. It seemed like a good start and I thought that I’d probably only need a few weeks to adapt to Lumina and be a happy TrueOS user. That was a bit too optimistic. My experience with this system really is a mixed bag. It’s not all bad nor is it all great. There’s light and shadow. And to be honest: While it’s pretty much ok as a daily driver (it’s mostly stable and most features are there), I think it feels quite “beta” currently.

TrueOS installation: Simple but shiny

I tried to post problems that I had with it on the PC-BSD forums but didn’t have too much luck with that. One post has not had a single answer (after several month now). Another was hijacked by somebody else and then closed by a moderator even though my issues (being the thread starter!) had not been resolved. While I originally wanted to open bug reports after getting into the community on the forums, that experience didn’t really help holding up my motivation. Yes, I know: I should just have reported things in the proper place. But I’m a person who wants to have a deeper relationship to his OS. I don’t just want to use it. I want to be part of it! For that reason it’s important to me to get into the community around an OS early on. For me this did not work out on TrueOS. I didn’t feel like I was getting anywhere on the forums and I didn’t succeed in feeling at home on the OS level, either.

But that’s personal stuff. Let’s start with going into a bit of detail on some areas of the system, shall we?

Bad: Graphics acceleration

Most of the bad points that I mentioned for PC-BSD (see the previous post) were still valid: Startup time was a bit long, the system is rather heavy on the battery, I didn’t find a way to log in multiple users graphically, etc. But there’s more. I think that the single most important problem that TrueOS suffers from is the fact that graphics acceleration had been broken for quite some time now. It worked when I first installed the system. Up to the update on 9/11 things were fine, too, but the next one broke it and while I hoped that it’d be fixed soon, I’ve waited for that ever since.

A freshly installed Lumina desktop

So if I wanted to watch a video I had to reboot and select the boot environment from 9/11. This also affected my work with VirtualBox. Probably thanks to that issue I could no longer switch my VMs to full-screen mode which was rather annoying. So I often had to reboot and use an old BE to be able to actually use my PC as intended. The fact that after a Lumina update the old BE would no longer be able to show the panel didn’t help either… 😦 I love BSD and want it to succeed. Only for that reason I’ve been tolerating things like that (which mean major inconvenience, honestly) for quite some time. But certainly you don’t attract many new BSD users with a system that has such issues! I really, really hope that this one gets fixed soon…

Good AND bad: Display settings

Lumina comes with a monitor configuration utility which is an excellent program – at least in theory. What makes it great is that it not only allows you to set the resolution. It also offers a simple and elegant GUI solution to manage multiple monitors! Great stuff, I love that. My primary PC is a laptop that I mostly use at home with an external monitor instead of the laptop screen. The monitor configuration allows me to add the external monitor and deactivate the other one. I’ve played with this a bit and it all seems very nice and mature.

Adding a second screen in the ‘Lumina Monitor Configuration’

However… It simply won’t keep the settings! That means was always 8 clicks after each start before my monitor setup was the way that I needed it and I could begin to do some work. I have no idea why it won’t save the settings and remember them next time. This is completely unnecessary.

Screen resolution configuration

I’ve also noticed a little consistency issue is that most of the Lumina desktop is localized properly (for the screenshots here I’ve used an English system, though!). The monitor control for example isn’t. I speak English and thus I have no problems using it but it makes the tool feel a bit out of place.

Neutral: Insight

I’ve tried to become friends with Lumina’s file manager, Insight. It didn’t feel right at the beginning and sometimes it decided to dump core when I accessed a new directory. But I finally kind of got used to it after some time.

The old Insight file manager with the side bar

Then another update happened… Yeah, the new git functionality may be nice. But guys, really… What did you do to that sidebar with the icons for copy, cut, paste, etc? The one thing that made me accept Insight was gone all of the sudden and I have been unable to get it back… I must admit that it’s probably not that bad of a loss as shortcuts were finally implemented. Still it didn’t take that much space and for people who don’t use shortcuts (I’ve seen a lot of such people!) it still was a very nice feature. No idea why it was dropped entirely instead of making it opt-in. Same thing about the “action buttons” and the “show thumbnails” option. It’s simply gone.

The new Insight with dual column mode

Another update added the dual column mode. That’s pretty useful IMO. But it happened after I stopped using TrueOS as my main operating system.

Good: SysAdm

This is one aspect where TrueOS really shines. Initially it felt quite empty and unpopulated but same of the updates added more and more options to it. SysAdm is a middleware that exposes an API to manage FreeBSD based machines locally or remotely.

The ‘Sysadm’ client for the local machine

I’ll be keeping an eye on this and look forward to install it on a FreeBSD server and try out remote management! But even the local client comes with a very nice GUI that has a lot of functionality now. Thanks and great work on that one TrueOS team!

Bad: Window manager

TrueOS uses the Fluxbox window manager with Lumina. Some people like it, some people don’t. I’m on the side of those who don’t but that’s not my main problem. People who’ve used *nix systems for any period of time probably know more than one wm and simply switch over to one that they like. The trouble is: It looks like Fluxbox is not meant to be replaced when you run Lumina! There’s no easy way to configure a different wm and in fact I didn’t find anything at all.

Lumina desktop settings

Worse: There are standards (the ICCCM in case of window managers). Following standards makes sense. Fluxbox doesn’t follow them. Window managers are meant to let other wms “take over” if you run your-favorite-vm –replace on the console. Fluxbox won’t cooperate which is very unfortunate. To replace it with sawfish (my wm of choice) I need to kill fluxbox first and then start the other wm… That’s not cool.

However I can fully understand that the small team that brings us TrueOS concentrates on supporting only one wm. Using sawfish I’ve experienced repeatable crashes (especially with Insight) where the system proved to be stable otherwise. And there’s another reason not to take this point too seriously: Fluxbox is not here to stay. Ken Moore has stated that he’ll write his own window manager to work perfectly with Lumina. So at some point Fluxbox will be replaced. I’m looking forward to this and hope that it’ll be a better replacement.

Neutral to good: Lumina DE

One of the core features of TrueOS is its native Lumina desktop. It was written from scratch, is BSD licensed and one of its design goals is being light-weight. Sounds excellent, doesn’t it? You bet it does! But does it live up to the high expectations? Like the whole TrueOS project its a bit of a mixed bag… First: A permissively licensed “BSD first” desktop is a dream come true. And I’m all for it being light-weight! The only problem here is… it isn’t.

It probably depends on what you compare it to. Sure thing: Compare it to KDE and you will find Lumina pretty light-weight. Then again – good luck finding any *nix DE that’s more heavy-weight than KDE is! If you compare Lumina to other desktops that state that they’re light-weight (be it Xfce, LXDE or even EDE), it clearly is quite a bit on the heavy side. In fact that’s no surprise due to the choice of toolkit that was made. Qt is the fattest toolkit out there. It does have it’s good parts, but being light-weight is nowhere near its strong points. However KDE (which uses Qt, too) has been the default DE of PC-BSD before and so Qt is what the TrueOS team knows best and that makes this toolkit a sensible choice despite the downsides.

Lumina panel configuration: Nice and flexible!

What Lumina does very well is being flexible. You can configure the menu the panels and just about everything to your liking. And you can do so using the GUI instead of having to edit config files. Even better: It’s pretty easy to do and after playing around with it a little you soon know how things work and where they are configured. Two thumbs up for that! I just miss the ability to right-click the panel to configure it. That’s probably the first thing newcomers try as everybody expects it to work.

Lumina is a desktop environment with lots of potential that already works quite well. It isn’t my favorite desktop and it does have some issues right now. However it works well and there are definitely people who prefer it over any other DE. And I’m pretty confident that it will continue to improve.

Good: Bootloader with BEs

PC-BSD used a modified version of GRUB2. While that program certainly works it’s not exactly my cup of tea. As stated above, I like light-weight software. And a bootloader that bears Grand in its name (and rightfully so) is not really my first choice. It’s alright if you need to dual-boot Linux or something but for just booting FreeBSD its more than I want.

TrueOS’s Bootloader – it supports BEs!

For TrueOS the team has decided to migrate back to the default FreeBSD bootloader after years of using GRUB. Excellent choice! Especially since it can now also use Boot Environments.

Good: PCDM

When it comes to display managers, I’ve come to like LXDM on Linux. Unfortunately it uses some linuxism in its code and for that reason could not be ported to *BSD. TrueOS offers another gem in this regard: PCDM. It’s a program that let’s you log in conveniently, providing all the features that you expect from a decent display manager – and more.

TrueOS’s display manager: PCDM

In PC-BSD I remember that I was initially unable to log in due to using a character that’s on the German keyboard but not on the US one. With TrueOS I no longer experienced such problems. On the contrary: I learned an alternative keyboard layout a while ago that offers better ergonomics and lets me type lots of foreign characters, too (e.g. the whole Greek alphabet). With PCDM I can use it to log in (allowing for nice, strong passwords, yay!).

Changing the keyboard layout in PCDM

I don’t have a 4k monitor, but it’s nice to see that PCDM is prepared for 4k already. The display manager lets you select various DPI options so that you don’t have the feeling of sluggish mouse movement when you use high resolutions.

PCDM’s DPI options: Ready for 4k

The only thing that bugged me quite a bit: The display manager was only displayed on the first screen, forcing me to open my laptop again to log in. I suggest to just show the login manager on every screen; this would be much more convenient.

Neutral to good: Update

The update mechanism of TrueOS has some advantages over the common desktop update methods. If you begin an update, it only fetches all packages and lets you continue to work in your current session. When you are about to shut down the system, it then asks if it should install the updates. Accept that and the system will shutdown the desktop and graphical mode and start updating. While it is doing that it’ll tell you not to turn off the computer and to change to the second TTY to see the details of the update process. When it’s done, the machine is powered down (or restarted if you chose that) like normal.

System update on TrueOS

But the really special thing is how the update is performed. A new Boot Environment is created, all packages are deinstalled and then reinstalled in their newest version. This has two advantages: It is the cleanest possible approach and it means that you can go back to any previous state by just selecting the respective BE! If you plan to do that, be sure to configure how many BEs the TrueOS update system keeps. Otherwise it will trash old ones (which may be a sensible default for space reasons).

What’s the downside? TrueOS is not a tiny operating system. Downloading all the packages with every update (can anybody say Noto fonts?) will require quite a few bits going over the wire. If you’re in a place with a slow connection, or worse, you have a monthly limit of how much you can download, then TrueOS’s way of doing things might not be for you.

Good: OpenRC

Ah, the bliss of a new init system! I’ve waited quite a while for that to happen. And when does it happen? About a week after I replaced TrueOS on my computer with another BSD operating system, Kris Moore (founder of PC-BSD/TrueOS) announces that they’re in the middle of switching over to OpenRC!

Truth be told: I didn’t expect this. When I heard Kris talk about nosh on the BSDNow show, I suspected that they might build that into PC-BSD. Then I had the impression that the team favored relaunchd (now renamed to jobd). And now it looks like OpenRC has landed!

TrueOS starting using OpenRC!

I’m fine with that as I already know it from Gentoo Linux. While I think it would have been interesting to see one of the other options get some attention, it now looks like OpenRC becomes the most significant alternative for people who don’t want to use Systemd! Maybe that’s not a bad thing at all.

While I don’t think that FreeBSD is going to adopt this change in the forseeable future (the BSD init system works well for servers after all) it totally makes sense to speed up the starting process for desktop machines. Thank you, TrueOS team! This takes care of another issue where FreeBSD just couldn’t compete with Linux.

Major differences from PC-BSD

The applications that come with TrueOS are pretty standard now. Initially the team provided some Qt5 alternatives like a browser I had never heard of and such. It’s a good decision to provide applications that people know but I also like the spirit of trying out new things and see if they work out. TrueOS in general is even more open to experiments than PC-BSD was – and even that was quite the opposite of a boring OS!

Obviously TrueOS has a new name. There are people who don’t like it. Some claim that it can be mistaken for another OS. But let’s be honest: Does “the average user” even know that there’s Tru64 UNIX? Most likely not. And people who know that it exists probably have enough *nix knowledge to tell the two apart. Other people criticise that it’s a bit of a big-mouthed name. Maybe it is but I don’t really care so much about that. In times of PC-BSD the server variant was already called TrueOS and for their new system the team wanted to rebrand the project without using a completely unknown name and so TrueOS actually was a sensible choice.

The biggest difference between the two is that PC-BSD was built from FreeBSD releases originally and ultimately headed towards the -STABLE branch. TrueOS takes this one step further and builds upon -CURRENT! This means that you always get the latest drivers and newest stuff but you may have to live with problems like broken graphics acceleration…

Another difference is that while PC-BSD begun its life supporting KDE and later leaving the user a choice between several desktop environments, TrueOS concentrates on the Lumina desktop. Some other DEs can be installed if you wish, but Lumina definitely is the standard.

And then there’s the newest addition to the project is TrueOS Pico, a variant meant to build ARM based thin-clients as well as a “Pico Server”. A very intriguing concept!


Looking back on more than three months of daily TrueOS usage, I must say that I went through highs and lows. There’s the painful moments where I had to grind my teeth and force myself to carry on. And then the opposite happened and I come across something that’s just amazing. All of that makes it not too easy to draw a clear conclusion. TrueOS is evolving at a very fast pace and at the present time my conclusion is that it is a unique OS that might work for you. There are operating systems where that’s more likely than with TrueOS but I’d bet that they are also far less innovative.

The TrueOS project is relatively young. I wouldn’t bet on even the team leader to know exactly where it’s heading. This is a good thing for us all, even for people who do not plan to use TrueOS. Why? Because it is not afraid to try new things and by doing so will continue to push FreeBSD forward in the desktop field!

PC-BSD’s goal was to provide a FreeBSD powered desktop that’s both easy and convenient to use for seasoned and new users alike. The rolling release character of TrueOS may not fit the former audience completely. It will be very interesting to see where the project will eventually find its place. Long time FreeBSD users who want the newest features on their desktop? BSD enthusiasts who want enjoy a permissively licensed desktop OS? Who knows! Time will tell (those who keep an eye on it). I may have switched to another OS for my daily work but TrueOS is far too exciting a project to just abandon completely. And if you love BSD you may want to give it a shot now and then. If you haven’t already tried it, correct your ignorance and download an ISO now!

Back and forth: Linux and *BSD

This is kind of the post that I wanted to write much earlier this year. After running a Linux-only environment at home for years, I had become less and less happy with the general direction things seem to be heading. I had run FreeBSD and OpenBSD on real hardware (old laptops) and several versions of PC-BSD in VirtualBox over the years. In January I decided to step forward and install PC-BSD (10.2) on my primary computer for daily usage. It remained a short episode – and this post will describe why. When TrueOS was released to the public I decided to try out that right away. But that will be another post.

Initial contact

I cannot remember when I first read about the BSDs. That must have been many years ago when I became interested in reading a bit about UNIX. I remember beastie and puffy and I remember that I failed installing a system in a VM because it was somehow too complicated. It likely was OpenBSD and the chance is quite high that I quit during the partitioning which probably was way over my head at that time.

While I never lost interest in it (Unix fascinated me) I decided to “learn Linux first” as that was the system I had chosen to run my computers with. As the Linux world was big enough for years (trying out the various desktops, doing a lot of distro hopping, …) I touched *BSD only rarely. Basically it was limited to installing PC-BSD in a VM when I found out that a new version was released. It seemed to be nice but I didn’t see any benefit over my Linux systems and so I stuck with that.

After studying something entirely different, I had made the decision to break up and get into the IT instead, even though was I well beyond the age that you usually start an apprenticeship. In my country that means that you apply to a company to work as an apprentice there half of the week and go to school the other days. Being somewhat of a Linux nerd I had only applied to companies that I knew weren’t using Windows – I had left that mess and was determined to avoid it in the future as far as possible. In the end I signed a contract of apprenticeship with a hosting company, moved into the area and started learning Linux a lot deeper than I had before. And… I came in contact with FreeBSD.

Being a hosting company that had been founded in the nineties, it had of course started on FreeBSD. Even though the focus of the company shifted to Linux years ago, there still were about 100 servers running FreeBSD. My colleagues generally disliked those servers – simply because they were different. And our CIO declared that he hated them and would love to get rid of them as FreeBSD was totally obsolete these days. If it hadn’t been for our boss to have a soft spot for them (as that had been what he started with and also what he had come to know best over the years) there definitely would have been far less FreeBSD servers around.

Digging into FreeBSD

Now for whatever reason I do have a heart for underdogs and so I begun to be interested in those odd systems quite a bit. Nobody wanted to touch those dinosaurs if he didn’t really have to. However somebody had to take care of them anyways, right? They were production servers after all! I volunteered. There were moments where I kind of regretted this decision but now in hindsight it was an excellent choice. I’ve learned a ton of little things that made me understand *nix and even the IT in general quite a bit better compared to what I would know now if I had followed the straight Linux path.

I also found out that only very few things that the colleagues hated about our FreeBSD boxes were things to actually blame FreeBSD for. By far the biggest problem was that they simply had been neglected for like a decade? Our Linux systems used configuration management, the FreeBSDs were still managed by hand (!). We had some sophisticated tooling on Linux, on the BSD boxes there were crude old scripts to (kind of) do the same job. Those systems were not consistent at all; some at least had sudo others made you use su if you needed to use privileged commands… Things like that. A lot of things like that. So it wasn’t exactly a miracle that the BSDs were not held in very high regard.

As I said, I didn’t really see any real advantage of BSD before. Linux even seemed to be easier! Think network interfaces for example: “eth + number” is easier than “abbreviation of interface driver + number”. But Linux has since moved to “enp0s3” and the like… And when you think again, it does make a lot of sense to see what driver an interface uses from the name. Anyways: I begun to like that OS! FreeBSD’s ports framework was really great and I realized the beauty of rc.config (Arch Linux did away with their central config file to get systemd. What a great exchange… – not!). Also I liked the idea of a base system quite a bit and /rescue was just genius. Would my colleagues lose their contempt for our BSD servers if they were configured properly? I thought (and still think) so.

My apprenticeship was nearing its end and I had to choose a topic for the final project work. I was advised to NOT do something Linux related because the examiners… *cough* lacked experience in that field (in the past an apprentice even failed because they have no idea what they are doing. He went before court and it was decided in his favor. A re-examination by people who knew Linux got him an A!). Now things like that make me angry and calls upon the rebel in me. I handed in a FreeBSD topic (evaluating Puppet, Chef, SaltStack and Ansible for orchestration and configuration management of a medium-sized FreeBSD server landscape).

So for servers I was already sold. But could *BSD compete on the desktop, too? I built two test systems and was rather happy with them. However I wanted to try out a BSD system optimized for desktop usage. Enter PC-BSD.

Working with PC-BSD

I was called nuts for making that switch just days before the final presentation of the written project work (“you need to pass this – your entire career depends on it!!”). But I didn’t want to do a presentation on a FreeBSD topic using a Linux machine! Well, in fact I had been too optimistic as the installation turned out to be… rather problematic due to a lot of bad surprises. To be fair: Most of them weren’t PC-BSD’s fault at all. The BIOS mode on my computer is broken in it not supporting booting off GPT partitions in non-UEFI mode. This lead to my drives disappearing after installation – and myself wondering if my classmates were right… Never change a running system! Especially not if you’re pressed for time!

After I found out what the problem was, installing to MBR was an easy thing to do. I still needed every single night that I had left but I got everything to work to at least the level that allowed me to hold my presentation. Another thing was that I had enabled deduplication on my ZFS pool. “24 gigs of memory should be enough to use that feature!”, I thought. Nobody had told me that it slows down file deletion so much that deleting about 2 GB of data meant to go and do something else while ZFS was doing its thing. Even worse: The system was virtually unresponsive while doing that so you could forget browsing the web or something like that in the meantime. But truth be told this was my own mistake due to my very own ignorance about ZFS and I can hardly blame PC-BSD for it.

I kept PC-BSD on my laptop for about 1.5 month before I needed to return to Linux – and I would in fact even have returned earlier had I had the time to reinstall. While some issues with PC-BSD vexed me, too, I could have lived with most of them. But my wife complained all the time and that of course meant the end for my PC-BSD journey.

So what were (some) of the issues with it? My wife mostly uses the PC to check email when our children are occupied with something for a moment. For her the very long boot time was extremely annoying. And really it took multiple times as long as the Linux system before (and that was still one with Upstart!). Keeping one user logged in and changing to another user quickly wasn’t possible – which meant that I had to shut down my multiple virtual machines and log out completely if my wife just wanted to quickly check mail or something. Not cool. Things like that.

And then there were a few things that annoyed me. It drew power from the battery much, much faster than the previous Linux system. When watching a video, the screen saver kept interrupting it. Firefox had strange issues from time to time and liked to crash. Working with EXT4 formatted disks was a pain. And so on and so forth.

Of course there were good parts, too. I had a real FreeBSD system at my hands with access to ports. Two firewalls (that are nothing like the mess that is netfilter/iptables!) to choose from. Excellent documentation. Nice helper tools (like the automounter, wifi manager, disk manager, etc.). Several supported desktops to choose from. And of course the well thought-out update system that I liked a lot. Thinking about it, there are a lot of good parts actually. Unfortunately even a ton of things nice to have have a hard time covering things conceived as no-gos. That’s life.

I had intended to update to 10.3 and then write a complete blog post about PC-BSD. My wife didn’t like the idea much, though. In addition to that I had little spare time and no alternative spare hardware, so there wasn’t a chance for me to actually do that.

Interlude: Linux

So it was back to Linux. With systemd this time. I’m not exactly friends with that omnivoristic set of tools that annoyed me perhaps just not enough to switch the system over to runnit or openrc. Other than that life was good again (as my wife was happy and I could do my work). But there was one thing in the short period of time with PC-BSD that had changed everything: I had caught the bug with ZFS!

Fourtunately there’s ZFSonLinux, right? So I installed that and created a pool to use for my data. In general that worked but it’s a bit more hassle to set up compared to FreeBSD where you basically get it for free without having to do anything special! If you don’t want to compile all packages related to ZFS yourself for each new kernel, there’s a third-party package repository for Arch. ZFS is not in the official ones. At some point the names of the packages changed and the update failed. I didn’t find anything about that and had to figure out myself what happened.

After another kernel and ZFS update that I did in the morning succeed. But when I came home, my wife told me that when she logged in, she was logged out again almost instantly. I booted the computer and logged in – the same thing happened. What was that? No error message, no nothing. The system simply dropped me back at the login manager… So I switched to text mode to take a look at what might be wrong with the system. Long story short: My pool “homepool” which held all user’s home directories was not available! And worse: zpool import said that there were no pools available for import… With the update, ZFS had stopped working! That hit me in the wrong moment whan I had very little time and so I had to downgrade as the quickest solution.

In the end I chose to compile the “solaris porting layer” and the other packages myself. This was not so bad actually but knowing that on FreeBSD I’d have access to ZFS provided by the operating system without having to do anything (and that nobody was going to break it without it probably being fixed again in no time) vexed me. Of course there were other things, too, and using FreeBSD on other boxes, I wanted it back on my main desktop machine as well.

What’s next?

I installed TrueOS and used it for over three months. The next post will be a critical writeup about TrueOS.

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. πŸ™‚

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!

Arch:E5 update and more repos (x11, gtk, fltk)

Finally I found some time to update and expand E5 a bit. The biggest news is surely the release of the e5-x11, e5-gtk and e5-fltk repositories. On the top of that packages have been updated and more than 80 new ones added (mostly to extra). This update also fixes a few issues that E5 had before.


Most notably the docbook issue has been resolved. It took me quite a while to figure out what was wrong there. I was able to narrow down the problem to be solely related to the docbook-xsl package as simply replacing the E5 one with the package from Arch solved the problem. This made me guess that probably some other E5 components (docbook-xml?) were semi-broken. I tried this and that to no avail. Finally I decided to build a package on a pure Arch system using the PKGBUILD from E5. Result: Broken package. Build the package again with an unmodified Arch PKGBUILD? Result: Working. Hm! Since it is an arch-independant package I hadn’t really changed anything except for setting the epoch value. And in the end it turned out: Leaving out epoch makes the package work, setting it breaks it!

Even though it bugs me to make an exception the epoch “rule” for this package, I’ve removed the epoch value for docbook-xsl for now. If anybody has any idea exactly what’s going on there, feel free to tell me. I’m very interested in it but don’t have the time to dig any deeper on the issue in the forseeable future.

For some reason I had forgotten to disable the libsystemd dependency on the polkit package. And since E5 doesn’t come with systemd, polkit could not be used. This bug has been corrected.

There were two or three smaller issues I was able to solve during the last weeks but I didn’t write them down and can’t really remember what they were.

The Equinox Desktop Environment on Arch:E5


Quite a few packages have been updated to newer versions. Most of them are from the skel or default repository but a few other ones were updated as well.

Here are some of the most important ones:

  • linux-libre-lts-5:3.10.33-1-i686.pkg.tar.xz
  • ignite-5:20140212-3-i686.pkg.tar.xz
  • eudev-5:1.5-1-i686.pkg.tar.xz
  • tzdata-5:2014a-1-any.pkg.tar.xz
  • bash-5:4.3-1-i686.pkg.tar.xz
  • openssh-5:6.5p1-2-i686.pkg.tar.xz
  • openldap-5:2.4.39-1-i686.pkg.tar.xz
  • pulseaudio-5:5.0-1-i686.pkg.tar.xz

New repositories

However the main news is clearly that the new repositories “x11”, “fltk” and “gtk” are available now. Like their names suggest, they hold packages which provide graphical programs which run on pure X11 or depend on the FLTK or GTK+ toolkits.

To install a very light-weight desktop, simply install the package “ede”:

pacman -S ede

Or if you want a full-blown, yet traditional desktop, the “mate” (and probably “mate-extra”) group(s) may fit your needs:

pacman -S mate

I had also intended to package a game for demonstration and since the new widelands beta was released not too long ago, I tried to prepare that. Arch:E5 has all the packages needed to build it and widelands compiles fine, too. Unfortunately it segfaults upon execution… And since I don’t have the time needed to look into that, it’s unfortunately no widelands right now. 😦

The new MATE 1.8 on Arch:E5

The furure

I think that Arch:E5 has already grown quite large for the quick project that it is. Right now it consists of 700+ packages which are roughly 1GB in size!

While it has been an interesting project, I’m not really sure what to do with it now. Most of what I was aiming for has been accomplished and the next step would now be bug hunting and adding even more packages. In other worlds: Nothing spectacular. In general I’m up to the challenge to maintain a linux distro for a longer time. However there’s of course no reason to maintain anything that isn’t of any use to anybody.

For that reason I’ll just let Arch:E5 live for a while doing the occasional update now and then and see if it is at least remotely interesting for somebody.

What’s next?

There are a lot of things which I’d like to do next. However I haven’t really decided, yet. So it’ll have to be a surprise!

[Edit: Added pictures]

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.

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

Here’s the second part of the GTK terminal emulators test. It’s N – Z today. Again we have 9 terminal emulators to take a look at.

The candidates

Here are the candidates:

(Again: Since there’s a lot of them out there, I may well have missed some interesting ones. Feel free to tell me in this case!)

Not tested

Last time I forgot to mention 3 more terminal emulators which don’t run on my test system:

(If you happen to get any of these to work on Arch and care to tell me, I’d be happy for any comments.)

Testing system

The testing system was the same that I described in my previous post.


QuTerm is a Quake-style terminal emulator which uses GTK2.

LXDE with QuTerm


pacman -U quterm-0.1-1-i686.pkg.tar.xz (4868 / 5 KB)


Memory usage after starting up LXDE and opening QuTerm 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 LXDE QuTerm 0.1
MemTotal: 3625888 kb
MemFree: 3514496 kb
Buffers: 10508 kb
Cached: 61876 kb
Rootfs: 830984 / 812 MB
RAM used at startup: 111392 / ~109 MB
Disk space (less LXDE system): 13504 / ~13 MB


ROXTerm is a terminal emulator which uses GTK3.

LXDE with ROXTerm


pacman -S roxterm (230084 / 230 KB + 13 dependencies: 14899200 / 14,9 MB)


Memory usage after starting up LXDE and opening ROXTerm 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 LXDE ROXTerm 2.7.2
MemTotal: 3625888 kb
MemFree: 3506020 kb
Buffers: 10552 kb
Cached: 68612 kb
Rootfs: 933296 / 912 MB
RAM used at startup: 119868 / ~117 MB
Disk space (less LXDE system): 115816 / ~113 MB


Sakura is a terminal emulator which uses GTK3.

LXDE with Sakura


pacman -S sakura (40416 / 40 KB + 12 deps: 14899200 / 14,9 MB)


Memory usage after starting up LXDE and opening Sakura 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 LXDE Sakura 3.0.4
MemTotal: 3625888 kb
MemFree: 3508796 kb
Buffers: 10204 kb
Cached: 68288 kb
Rootfs: 929500 / 908 MB
RAM used at startup: 117092 / ~114 MB
Disk space (less LXDE system): 112020 / ~109 MB


Stjerm is a Quake-style terminal emulator which uses GTK2.

LXDE with Stjerm


pacman -U stjerm-git-0.16_19_g4038b07-1-i686.pkg.tar.xz (19564 / 20 KB)


Memory usage after starting up LXDE and opening Stjerm via run (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 Stjerm 0.16_19
MemTotal: 3625888 kb
MemFree: 3515092 kb
Buffers: 10552 kb
Cached: 61552 kb
Rootfs: 829620 / 811 MB
RAM used at startup: 110796 / ~108 MB
Disk space (less LXDE system): 12140 / ~12 MB


Termite is a terminal emulator which uses GTK3.

LXDE with Termite


pacman -U vte3-select-text-0.34.6-1-i686.pkg.tar.xz (356904 / 357 KB 12 dep: 14899200 / 14,9 MB)
pacman -U termite-6-1-i686.pkg.tar.xz (19520 / 20 KB)


Memory usage after starting up LXDE and opening Termite 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 LXDE Termite 6
MemTotal: 3625888 kb
MemFree: 3510272 kb
Buffers: 10220 kb
Cached: 67108 kb
Rootfs: 931076 / 910 MB
RAM used at startup: 115616 / ~113 MB
Disk space (less LXDE system): 113596 / ~111 MB


Tilda is Quake-style a terminal emulator which uses GTK2.

LXDE with Tilda


pacman -U tilda-git-20130625-2-i686.pkg.tar.xz (64824 / 65 KB + 2 deps: 133120 / 133 KB)


Memory usage after starting up LXDE and opening Tilda 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 LXDE Tilda git-20130625
MemTotal: 3625888 kb
MemFree: 3516252 kb
Buffers: 9800 kb
Cached: 62824 kb
Rootfs: 830976 / 812 MB
RAM used at startup: 109636 / ~107 MB
Disk space (less LXDE system): 13496 / ~13 MB


Tinyterm is a terminal emulator which uses GTK2.

LXDE with Tinyterm


pacman -U tinyterm-svn-20100223-1-i686.pkg.tar.xz (4180 / 4 KB)


Memory usage after starting up LXDE and opening Tinyterm via run (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 Tinyterm svn-20100223
MemTotal: 3625888 kb
MemFree: 3514148 kb
Buffers: 10520 kb
Cached: 62804 kb
Rootfs: 829576 / 811 MB
RAM used at startup: 111740 / ~109 MB
Disk space (less LXDE system): 12096 / ~12 MB


vTerminal is a terminal emulator which uses GTK2.

LXDE with vTerminal


pacman -U vterminal-13-3-i686.pkg.tar.xz (11988 / 12 KB + 2 deps: 40960 / 41 KB)


Memory usage after starting up LXDE and opening vTerminal via run (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 vTerminal 13
MemTotal: 3625888 kb
MemFree: 3510000 kb
Buffers: 12940 kb
Cached: 62480 kb
Rootfs: 831176 / 812 MB
RAM used at startup: 115888 / ~113 MB
Disk space (less LXDE system): 13696 / ~13 MB


Xfce4-Terminal is a terminal emulator which uses GTK2.

LXDE with Xfce4-Terminal


pacman -S xfce4-terminal (300188 / 300 KB + 4 deps: 399360 / 399 KB)


Memory usage after starting up LXDE and opening Xfce4-Terminal 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 LXDE Xfce4-Term 0.6.2
MemTotal: 3625888 kb
MemFree: 3505716 kb
Buffers: 11160 kb
Cached: 63488 kb
Rootfs: 835304 / 816 MB
RAM used at startup: 120172 / ~117 MB
Disk space (less LXDE system): 17824 / ~17 MB

What’s next?

The next post will be a summary of the GTK terminal tests and provide a table for easy comparison.

[Update (08/10): Corrected Termite’s disk usage values – copied the wrong ones before.]

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

Today we’re in for taking a look at the various terminal emulators out there which are based on GTK+. This first part deals with the ones which start with A to M.

The candidates

Here’s the list of available GTK+ terminals I got working on Arch:

(Since there’s a lot of them out there, I may well have missed some interesting ones. Feel free to tell me in this case!)

Not tested

Here’s the list of GTK-based terminal emulators which I didn’t test because they didn’t work (since there are so many available I didn’t have much time to mess with these here):

(If you happen to get any of these to work on Arch and care to tell me, I’d be happy for any comments.)

Testing system

For the coming tests I set up a new, clean Arch VM (25.06.2013). The basic system looks like this (after cleaning pacman cache):

Arch Linux “base”
MemTotal: 3625888 kb
MemFree: 3586228 kb
Buffers: 5404 kb
Cached: 18556 kb
Rootfs: 488660 / 478 MB
RAM used at startup: 39660 / ~39 MB

Then I installed a typical LXDE:

pacman -S xorg-server xorg-xinit xf86-video-vesa lxde (132 packages; size: 59914 Bytes / 59 MB)

Memory usage right after starting up LXDE (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.5)
MemTotal: 3625888 kb
MemFree: 3522368 kb
Buffers: 9740 kb
Cached: 58860 kb
Rootfs: 817480 / 799 MB
RAM used at startup: 103520 / ~101 MB
Disk space (less basic system): 328820 / ~321 MB


DWT is a terminal emulator which uses GTK3.

LXDE with dwt


pacman -U dwt-0.3-1-i686.pkg.tar.xz (7272 / 7 KB + 19 dependencies: 1689000 KB / 17 MB)


Memory usage after starting up LXDE and opening Dwt 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 LXDE dwt 0.3
MemTotal: 3625888 kb
MemFree: 3502520 kb
Buffers: 11648 kb
Cached: 67740 kb
Rootfs: 958252 / 936 MB
RAM used at startup: 123368 / ~120 MB
Disk space (less LXDE system): 140772 / ~137 MB


Evilvte is a terminal emulator which uses GTK3.

LXDE with Evilvte


pacman -U evilvte-0.5.1-1-i686.pkg.tar.xz (28244 / 28 KB + 13 deps: 14899200 / 15 M)


Memory usage after starting up LXDE and opening Evilvte 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 LXDE Evilvte 0.5.1
MemTotal: 3625888 kb
MemFree: 3508236 kb
Buffers: 10292 kb
Cached: 68140 kb
Rootfs: 923508 / 902 MB
RAM used at startup: 117652 / ~115 MB
Disk space (less LXDE system): 106028 / ~104 MB


Ftjerm is a terminal emulator which uses GTK2.

LXDE with Ftjerm


pacman -U ftjerm-0.12.3-1-i686.pkg.tar.xz (24968 / 25 KB)


Memory usage after starting up LXDE and opening Ftjerm via run from 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 LXDE Ftjerm 0.12.3
MemTotal: 3625888 kb
MemFree: 3514480 kb
Buffers: 10556 kb
Cached: 62180 kb
Rootfs: 822280 / 804 MB
RAM used at startup: 111408 / ~109 MB
Disk space (less LXDE system): 4800 / ~4.6 MB


The gnome-terminal is a terminal emulator which uses GTK3.

LXDE with Gnome-terminal


pacman -S gnome-terminal (16056320 / 16 MB)


Memory usage after starting up LXDE and opening Gnome-terminal 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 LXDE Gnome-terminal 3.8.3
MemTotal: 3625888 kb
MemFree: 3501640 kb
Buffers: 12000 kb
Cached: 69792 kb
Rootfs: 931004 / 910 MB
RAM used at startup: 124248 / ~121 MB
Disk space (less LXDE system): 113524 / ~111 MB


Lilyterm is a terminal emulator which uses GTK2.

LXDE with Lilyterm


pacman -S lilyterm (163840 / 160 KB)


Memory usage after starting up LXDE and opening Lilyterm 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 LXDE Lilyterm
MemTotal: 3625888 kb
MemFree: 3516284 kb
Buffers: 9748 kb
Cached: 62648 kb
Rootfs: 822928 / 804 MB
RAM used at startup: 109604 / ~107 MB
Disk space (less LXDE system): 5448 / ~5.3 MB


Lwt is a terminal emulator which uses GTK2.

LXDE with Lwt


pacman -S lwt-20130625-1-i686.pkg.tar.xz (4380 / 4 KB)


Memory usage after starting up LXDE and opening Lwt 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 LXDE Lwt 20130625
MemTotal: 3625888 kb
MemFree: 3517248 kb
Buffers: 9776 kb
Cached: 62272 kb
Rootfs: 822204 / 803 MB
RAM used at startup: 108640 / ~106 MB
Disk space (less LXDE system): 4724 / ~4.6 MB


Lxterminal is a terminal emulator which uses GTK2.

LXDE with Lxterminal


Included with LXDE


Memory usage after starting up LXDE and opening Lxterminal 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 LXDE Lxterminal 0.1.11
MemTotal: 3625888 kb
MemFree: 3515556 kb
Buffers: 9728 kb
Cached: 62020 kb
Rootfs: same as LXDE
RAM used at startup: 110332 / ~108 MB


Mlterm is a terminal emulator which uses GTK3.

LXDE with Mlterm


pacman -U mlterm-3.2.0-1-i686.pkg.tar.xz (622240 / 622 KB + 19 deps: 16404480 / 16 MB)


Memory usage after starting up LXDE and opening Mlterm 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 LXDE Mlterm 3.2.0
MemTotal: 3625888 kb
MemFree: 3517600 kb
Buffers: 10120 kb
Cached: 61444 kb
Rootfs: 935600 / 914 MB
RAM used at startup: 108288 / ~106 MB
Disk space (less LXDE system): 118120 / ~115 MB


Mt is a terminal emulator which uses GTK2.

LXDE with Mt


pacman -U mt-.1-2-i686.pkg.tar.xz (4260 / 4 KB)


Memory usage after starting up LXDE and opening Mt via run from 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 LXDE Mt .1
MemTotal: 3625888 kb
MemFree: 3515324 kb
Buffers: 10504 kb
Cached: 61212 kb
Rootfs: 825676 / 807 MB
RAM used at startup: 110564 / ~108 MB
Disk space (less LXDE system): 8196 / ~8.0 MB

What’s next?

The next post will deal with the rest of the GTK+ terminal emulators which I got running.

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Γ© (http://etoileos.com) 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.

Situation of the Linux Desktop #2: Habemus tumultum…

… qui nomen nominatur “pacem”!

Wow, Latin! Oh er, welcome back! Wonder what that strange sentence does there – and what it may have to do with the Linux Desktop? Well, due to unforeseeable incidents when moving houses along with some family matters, I was more or less cut off from any news. I didn’t have internet connection for about one month and was not in the mood to buy a newspaper (and since TV and radio programs are more or less useless to disgusting and a total waste of time, I don’t own a TV or a radio). You can probably imagine how surprised and amazed I was yesterday when I finally read what had happened in the meantime!

The news of not even a handful of weeks missed – and all of a sudden the Roman Catholic church has a new pope (even though the old one didn’t die!). That was what inspired my headline which translates (or at least should translate) to: “We have a turmoil… which is called (the name) peace!”


“Peace”?! Yes, peace. It’s one possible translation of the Russian word in the sub-headline above. Others are “world” or even “universe”, but I couldn’t resist to put together peace and turmoil. πŸ˜‰ What the heck am I talking about? Alright, alright. You’ll know what I mean right away. “ΠœΠΈΡ€” is pronounced… Mir!

Well, Mir! You’ve probably heard of the new display server which Canonical (makers of Ubuntu) announced. Even this announcement had a huge impact in the Linux world. A lot has already been written about it. But this is one topic that clearly affects the subject of my blog – the Linux Desktop. While I tried not to be too biased about Ubuntu in the past, Canonical are giving me a hard time once again.

Closed graphic drivers

My position on the efforts of Canonical, Valve and others was one of cautious confidence that it could be of great value to the Linux community. I’m not one of those Linux fans who want this operating system to “succeed” and I don’t really care for market shares and things like that. But there’s certainly some truth to the fact that we’d all benefit from good drivers provided by the companies who build the hardware. Yes, while I prefer open drivers (for obvious reasons), I don’t have a problem with closed drivers being available, too. It’s one additional option for those who need the performance, reliability, etc.

It’s common knowledge that X11 is really old now and that this is not just beginning to show. For the conservative desktop environment X will remain the display server of choice but the general next step, the future of the modern Linux Desktop would be Wayland. Almost everybody agreed with that – at least until early march. A few years ago even Canonical had praised Wayland and planed migrating to it in the future. Now said Company is developing their own display server Mir…

Canonical’s Mir and Wayland

Alright, Canonical have abandoned the classic desktop with Unity and are clearly aiming for the mobile market. That’s ok, I guess. But developing a new display server and convincing Nvidia (who already hesitated to support Wayland!) to support it instead of Wayland is not a nice move at all. Doing so at this particular time (before Wayland could actually play any role) really looks like an attempt at backstabbing that other display server for me!

Thanks to Canonical, Nvidia will be even less motivated to offer drivers compatible with Wayland. Canonical’s founder even boasted of Mir possibly running on more devices than Wayland! That sounds like a plan. A plan that may be very profitable for Canonical but also a plan that can prove to be devastating for the Linux community. How to treat the new situation? Curse and boycott Mir? That’s probably overreacting. Embrace and praise Mir? Certainly not at this time. Anyway all this is a development that we should eye closely. Perhaps Mir will provide a few interesting features in the future. Right now it’s just a concept – and a splitting one. Let’s see what happens next.

GNOME 3 and Consorts

Another thing has happened since I wrote the first “Situation of the Linux desktop” in November. MATE is no longer the only promising GNOME fork. Now there’s also Consort.

The difference between them is that MATE picked up the dead GNOME 2 and remains based on the GTK+2 toolkit. According to the makers of Consort, this is “dead technology” and their effort is maintaining a classic GNOME desktop based on GTK+3. GNOME 3 will be dropping their “GNOME classic” or “fallback” mode with the upcoming version 3.8. This mode resembles GNOME 2 in many ways – but the most important thing for many people is the fact that it does not require hardware graphics acceleration. So Consort will be picking up where GNOME 3 Classic left.

Currently Consort doesn’t work with Arch Linux so I didn’t test it, yet. So I can’t say much more about it right now.

The situation!

The Linux Desktop has fragmented even more since my last post. With Consort there’s a new desktop environment in preparation and with Mir there’s even a new display server in the making. The later could even be seen as a hostile attempt to sabotage Wayland. More than ever the situation is getting unclear and confusing. Probably a good time to work on the DDD again?

What’s next?

Next I’d like to release a new version of the DesktopDemoDVD.