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

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

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

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.

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

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

LXDE with QuTerm

Installation

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

Statistics

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

ROXTerm is a terminal emulator which uses GTK3.

LXDE with ROXTerm

Installation

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

Statistics

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

Sakura is a terminal emulator which uses GTK3.

LXDE with Sakura

Installation

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

Statistics

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

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

LXDE with Stjerm

Installation

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

Statistics

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

Termite is a terminal emulator which uses GTK3.

LXDE with Termite

Installation

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)

Statistics

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

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

LXDE with Tilda

Installation

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

Statistics

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

Tinyterm is a terminal emulator which uses GTK2.

LXDE with Tinyterm

Installation

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

Statistics

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

vTerminal is a terminal emulator which uses GTK2.

LXDE with vTerminal

Installation

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

Statistics

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

Xfce4-Terminal is a terminal emulator which uses GTK2.

LXDE with Xfce4-Terminal

Installation

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

Statistics

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