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!

Conclusion

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!

Advertisements

Setting up a FreeBSD/OpenBSD dual-boot with full disk encryption

A bit over a month ago, I bought my first refurbished laptop. Previously I used a ThinkPad (owned by the company I work for) for on-call duty. It’s running a Linux distro which would not be my first choice at all, it has a small screen and – it’s not my property. I wanted my own laptop and since we’re allowed to use whatever distro we prefer, I thought that I’d be going with Arch.

(I you’re just interested in the commands to enter, have a look at the end of this post where I put a list of them.)

*BSD in production

On a second thought: Why not use *BSD? For me it would mean going to use a *BSD desktop “in production” after only running it privately. Thanks to the great BSDNow! show I feel confident enough now to give it a try. The company that I work for is running some FreeBSD servers, too, so it’s not something entirely strange and unknown. I went with asking if using BSD for on-call was ok. The answer was what I expected: If I thought that it would work ok I should well try it. The only requirement was that I’d encrypt the disk (the same rule would apply to Linux, too, of course).

Next question: Which BSD to use? Since I’m just getting into *BSD, I’m not really familiar with all of them now. Net and Dragonfly would certainly be interesting, but since I need that box for work that’s not an option. I need something that I know enough to be able to work with. Of course it would be best if I could learn something at the same time… So, what’s the best way to learn more? Probably tracking -CURRENT! But what if something breaks? I cannot afford that. And which BSD to use anyway? I work with some FreeBSD servers, so more in-depth FreeBSD knowledge would make sense. Then again I’ve really come to like Puffy and all he stands for…

That would be a hard decision! Finally I decided not to decide – and to just install both instead. This also has the advantage of having a second system if either CURRENT should ever break!

Hardware: HP EliteBook

I bought an HP EliteBook 8470p. Why didn’t I go with Lenovo even though those are known to work best with *BSD and I obviously need something that seriously works? Well, there’s one reason for me: With the ThinkPads keyboards just totally suck. I have no idea who came up with that sad story of “Hey, let’s just put the Fn key where Ctrl belongs and vice versa!”. No idea whatsoever. But I know for sure that it drives me insane. No fun at all when you’re working on-call at four AM, barely awake, and nothing happens when you have to CTRL-C something quickly. I could never get used to it ever!

So for that very reason it had to be some other hardware. I had this older HP laptop that a friend sold me for a few bucks a while ago. I can’t remember which model exactly and cannot look it up since I don’t have it anymore. (When my mother’s old computer died as I was over on a visit, my father thought about replacing it with a Windows box since that’s the only thing that he knows. To avoid that, I set up said old HP laptop that I had with me as a replacement and gave it to her. She’s been using it happily since.) That laptop had been a pleasant experience when I had OpenBSD on it and so I decided to give that EliteBook a try.

It works fairly well for most things. On FreeBSD there was the problem with the Intel video driver but since I’m running 11-CURRENT video is all working great even when I quit X11. WiFi is detected according to dmesg but for some reason no iwn0 shows up if I run ifconfig. I didn’t have time to look into that further, however. On OpenBSD backlight gets turned off if I quit X and thus the screen is a bit dark then. Since I usually quit X to shut down the computer afterwards, anyway, that’s only a minor issue. WiFi is correctly detected and I confirmed it to work. Suspend works when I close the laptop but when it wakes up the keyboard does not work anymore. These are the only issues that I ran into so far.

What is the exact use case?

FreeBSD can use ZFS while OpenBSD cannot. I’m not sure if FreeBSD’s and OpenBSD’s UFS/FFS filesystems are compatible (I think OpenBSD’s implementation misses quite some of the newer features). The encryption methods used by the systems however are definitely not compatible. So it doesn’t matter anyway in this case and I’m free to choose whichever filesystem I want.

Since I’ll be compiling FreeBSD-CURRENT now and then (and in general plan to do some stuff that likes much memory to be available), I decided to go with UFS. Yes, there are scenarios where ZFS is simply overkill! There’s only one drive in the laptop, it’s not extremely big and it won’t hold any important data. I have no need any particular ZFS feature on that system, so going with UFS should be fine. (That plus the fact that I’m still reading Lucas’ and Jude’s excellent book on ZFS and intend to play with that filesystem on another machine)

Prior to version 5.9 (released after I originally wrote this), OpenBSD only really supported the MBR partitioning scheme so going with that was an easy choice. I’ll stick to it for now because I need some time to play with it first. I’m going to do everything again in a VM so I can take screenshots for this article.

Installing FreeBSD

The installation begins just like an ordinary FreeBSD install: Boot up the installer media and make your way through the setup questions. When the installer asks about the partitioning however, we’re going to do that by hand.

Choosing to partition by hand

The pure bourne shell is not very comfortable for interactive use, so it generally makes sense to use a more advanced shell (like tcsh) for convenience features like auto-completion. Should you not know which drives your machine has, camcontrol can help you. If you want to start with a clean drive, you can zero out everything with dd (when I bought my laptop it had Windows 7 on it that I wanted to get rid of).

Zeroing out the disk

If you’re not familiar with what partitions and slices are, you may want to have a look at an older post where I wrote up a little excursion about that topic.

First an MBR is created and then two slices are added to it. The first one gets 100 gigabytes, the other the rest (which is also 100 GB in my case). Both slices are created aligned to 4k sector size of the hard drive. Then a BSD disklabel is added in the first slice. After that, boot0 (a simple boot manager) is written on the drive and the standard bootcode into the first slice. Finally the first slice is marked as active for booting.

Slicing the disk

Now three partitions are created inside the BSD label: One for boot (which will hold the kernel and cannot be encrypted), one for swap and one for the system (which will be encrypted). Glabel is used to give these partitions a more meaningful name than ada0s1a and the like. Since the system partition will be encrypted, it makes sense to write some garbage all across it so that it is impossible to see which part holds data and which does not. This takes quite a while and you could of course skip this. As long as your patience lives up to paranoia, that little bit of extra security is worth the wait!

Creating and labeling BSD partitions

Next the system partition is initialized with GELI, one of FreeBSD’s two military grade encryption methods. I only use a passphrase to unlock but you can also use a key (or both) if you wish. After attaching the new GELI partition, a new GEOM provider, system.eli is available with the clear data for you (and your programs) to use.

Creating and attaching the GELI partition

Now it’s time to format the two data partitions (the swap partition does not need any formating). You could also use journaling UFS for the boot partition but it’s usually not necessary.

Creating filesystems

Copy over the boot directory and add two lines to loader.conf so that you’ll have the chance to unlock your GELI partition during system startup. What remains is writing a fstab. Notice that for some reason I’ve forgotten to put swap.eli in there on my screenshot (even though that’s what I have in my script). What this does is using a one-time key for your swap on each boot, thus making sure that any data that remains on the swap partition is useless once the system was powered down once. You do not have to initialize GELI for this. FreeBSD knows what to do when it sees swap.eli.

Mount the decrypted system partition on /mnt as that’s where the installer expects it. And don’t forget to create the clear directory as we demand that in fstab and the system would not boot up correctly if it was missing. Then exit the shell and continue with the installer.

Copying over /boot and writing loader.conf and fstab

Once the installation has finished, the installer will ask you if you wish to make any final modifications. Answer yes and it will drop you into a shell in a chroot of your new system. Delete /boot (that directory lives on the encrypted system partition and the bootloader could not find the kernel there anyway) and make it a symlink pointing to /clear/boot instead. This step is not actually required. But if you don’t do it, you won’t be able to update your system the normal way. If you want to only mount the real /boot by hand whenever you upgrade, that’s fine, too, of course.

Chosing to make final modifications

Exit the shell, reboot and remove the boot media. Then reboot. Your boot manager (boot0) will offer you two FreeBSD systems. Hit F1 to boot up FreeBSD. Don’t hit F2. There’s no system there, yet.

Installing OpenBSD

The OpenBSD installer is neither pretty nor does it offer any kind of menu system. However it is simple, effective and straight-forward. Choose to install OpenBSD, set your keymap, enter a hostname, configure the net and set a root password.

Hostname, network and password configuration

Choose to run an SSH server by default, whether to prepare the system for X11, if you want the display manager XDM to be started automatically. Create a user now or do so later. When asked for the timezone, give a ! instead to drop into a shell.

Going to a shell

If you don’t know your disks, look inside the dmesg for the name. Now use fdisk to change the type of the second partition from A5 (FreeBSD) to A6 (OpenBSD). Then use disklabel to create a swap partition and a main partition. Make absolutely sure that the later has the type RAID!

Partitioning for OpenBSD

Encrypt the new softraid with bioctl then exit the shell. Now enter the correct timezone and choose the newly created softraid for the installation! Dedicate the whole softraid disk to OpenBSD but edit the partitions to fit your need. You do not need a swap partition on the softraid because we created a separat one on the real disk, remember? For that reason, after OpenBSD formated the partitions you created, the installer will ask you if you want to add any other disks before you start the actual installation. You DO because there’s the swap area.

Preparing crypto softraid

Once the installer has finished, reboot the machine. Now the boot manager says “F1 – FreeBSD” and “F2 – BSD”. The second one is your OpenBSD. The manager knows only the partition type and has no clue which system is on there.

Plain text summary

Here’s what you could type in for the shell parts of both installers:

FreeBSD


In the partitioning shell:
tcsh
dd if=/dev/zero of=/dev/ada0 bs=1m
gpart create -s mbr ada0
gpart add -a 4k -t freebsd -s 98G ada0
gpart add -a 4k -t freebsd ada0
gpart create -s bsd ada0s1
gpart bootcode -b /boot/boot0 ada0
gpart bootcode -b /boot/boot ada0s1
gpart set -a active -i 1 ada0
gpart add -t freebsd-ufs -s 2G ada0s1
gpart add -t freebsd-swap -s 4G ada0s1
gpart add -t freebsd-ufs ada0s1
glabel label clear /dev/ada0s1a
glabel label swap /dev/ada0s1b
glabel label system /dev/ada0s1d
dd if=/dev/random of=/dev/label/system bs=1m
geli init -b -s 4096 -l 256 /dev/label/system
geli attach /dev/label/system
newfs /dev/label/clear
newfs -j /dev/label/system.eli
mount /dev/label/clear /media
cp -Rp /boot /media
echo 'vfs.root.mountfrom="ufs:/dev/label/system.eli"' >> /media/boot/loader.conf
echo 'geom_eli_load="YES"' >> /media/boot/loader.conf
echo '/dev/label/system.eli / ufs rw 1 1' >> /tmp/bsdinstall_etc/fstab
echo '/dev/label/swap.eli none swap sw 0 0' >> /tmp/bsdinstall_etc/fstab
echo '/dev/label/clear /clear ufs rw 1 1' >> /tmp/bsdinstall_etc/fstab
mount /dev/label/system.eli /mnt
mkdir /mnt/clear
exit
exit

In the "final modifications" chroot:

rm -r /boot
ln -s /clear/boot /mnt/boot

OpenBSD


i
de
puffy
em0
dhcp
none
done
password
no
yes
no
no
!
dmesg | grep [ws]d0
fdisk -e sd0
setpid 1
A6
quit
disklabel -E sd0
a b
ENTER
4G
swap
a a
ENTER
ENTER
RAID
w
q
bioctl -c C -l /dev/sd0a softraid0
exit
Europe/Berlin
sd1
whole
e
Your layout here
w
q
sd0
OpenBSD
w
q
done
http
none
openbsd.cs.fau.de
pub/OpenBSD/5.9/amd64
done
done

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

OSes

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.

Hardware

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.

DOS

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.

Linux

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.

FLTK

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

Nanolinux

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.

Netrider

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!

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

Extensions

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”

Summary

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.

Fixes

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

Updates

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 0.9.9.2
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 0.9.9.2 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 0.9.9.2 +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 0.9.9.2 ~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

Conclusion

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.