Bobulate

I’ve been using VirtualBox (the Open Source Edition) a fair bit recently. My desktop machine fairly hefty: an i7 860, 4 core HT and 8GB RAM. I leave it running Kubuntu and VirtualBox on top of that. Then I have a workable, if by now slightly dated, desktop and all the KDE applications that I need. In VirtualBox I run the machines I’m interested in for development. That’s an OpenSolaris instance and a FreeBSD one (just resurrecting that interest now and I haven’t even gotten around to checking out area51 yet). I also keep a Fedora and a Kubuntu VBox around for comparison purposes. So plenty of ways of using up the CPU power. Next to the desktop machine (also under my desk) is my spare box, which is an amd64 6250e, dual core, 6GB RAM.

The guest additions make the applications running in the VBox interact with the host machine without mouse or keyboard grabs; then the KDE application running inside GNOME in OpenSolaris is very nearly just another window on my desktop.

I use the OpenSolaris VBox to compile KDE packages. In a very simple test — building QScintilla — I find that the virtual machine outperforms the physical machine sitting next to it. Compile goes from 3 minutes to two, running the same software stack. I’m very much surprised, because the clock speed difference isn’t that great and I’d expect there to be some non-trivial virtualization overhead.

The fact I can share a folder between the host OS and the VBoxes is quite useful, since it means I only need a single checkout of KDE SVN. I can patch from inside each virtual machine, experiment and eventually push things back out. FreeBSD doesn’t support directly shared folders, but I can still network-mount everything. This then means that it’s become much easier for me to test changes across OSsen. No longer will I horribly break Linux builds with a little Solaris patch (er .. I don’t think I’ve done that before, or maybe I just don’t remember).

What would be really keen is appliances: a VBox image that is an instant FreeBSD / OpenSolaris / OpenSUSE development environment. That would work for FreeBSD and OpenSUSE, I think, but the license terms of Sun Studio presumably preclude redistribution. That’s unfortunate, because it makes it harder to get development done (although, come to think of it, a system which has everything installed except for the one tarball of Studio might not be encumbered). It would serve a different purpose than the SuSE build service which does builds for many many different OSsen — desktop development in a separate environment.

One thing I intend to add to the stable is a Linux VBox with Sun Studio for Linux installed on it, so I can try some stuff related to the compiler. I recently finished up packages for KDE-PIM and there were many patches needed; there’s some template magic that the Sun compiler just doesn’t understand, leading to dozens of KCalCore::Incidence::Ptr() cast constructors being patched into code that’s otherwise a model of tidyness. Only once I’ve got something sensible set up will it be possible to apply power machinery (in casu KDAB Marc, C++ template guru) to the problem. In any case, we have packages for all the parts tagged as KDE 4.5.68 (snapshot from trunk) for OSOL except for bindings, edu, kmix and plasma-addons. The problem in kde-edu is actually a bug with Boost and Sun Studio, so that’s going to take a little more work to fix.

For some of the things I would like to do with the EBN code-quality checking machine — things outside the immediate realm of quality checking — I need some VMs beyond what FreeBSD’s jails give me.

In particular, I need Solaris running on the machine as well as FreeBSD, so I looked into VirtualBox. I’ve used it on Solaris for various purposes (including running FreeBSD) so it seemed appropriate. There’s no binary version of VirtualBox for FreeBSD, but you can compile the Open Source Edition from ports, so that’s what I did. The results — missing USB passthrough and no RDP — are things I can live with, as it just means I’ll do most of my work on the VMs through ssh.

Installation (of VirtualBox OSE 3.1.6) is pretty non-eventful, the remember-to-load-the-kernel-driver reminder at the end of installation useful, and it just works.

For testing purposes and to satisfy some curiosity on my part I decided to install the Maemo development environment provided by Nokia (hey, maybe I’ll write my first GTK+ program like that). This turns out to be a VMDK (VMWare) file, not a OVF file, so a little bit of fiddling about was necessary. There are installer scripts available with lots of disclaimers for VBox 2, but none for version 3. So I tweaked and twiddled a little, and ended up with this installer script that calls VBoxManage a bunch of times to set up the machine. This is largely cribbed from Nokia’s script, adapted for new syntax in version 3.

One thing to note here is the invocation with –usb on. That could be combined with other calls to VBoxManage, but since the OSE has no USB passthrough, this will fail. For those using the non-OSE version, the call will succeed. Run the script with either –add or –remove from the directory containing the .vmdk file and it’ll set things up or tear them down.

In the resulting VM I haven’t gotten any further than starting esbox and quitting it again — but it shows that the VM works, that the apps work. I can ssh in for whatever command-line work I need to do.

The upshot — after all, the Maemo dev environment is just an experiment — is that a Solaris VM will happen real soon now. I was hoping for something jeos-like, but I hear that the people responsible for that have left Oracle now (this looks like a common theme: all the nifty Open Source but non-revenue projects are bailing out). So I’ll have to find another means of installing a fairly-minimal OpenSolaris version into the VM (which, thanks to Jignesh, is a matter of VBoxManage import). For my purposes no X is needed, so that saves us at least one (if not two) desktop environments in the disk image.

Credits where credit is due: to Jignesh Shah for the OSOL image and to Miwi for not only porting KDE4 to FreeBSD but also acting as source of information for VirtualBox.

As I mentioned previously, I’ve updated some of my machines to OSOL 2009.6. Only some, though. It refuses to start on my AMD 760G based machine — gets through grub, shows the splash and then hangs. I haven’t sat down to debug that one. It does run quite nicely on my new laptop (some folks asked: it’s an MSI GX620, which is nominally a “gamer’s laptop”. Poor battery life, but I realised that I don’t use the lappy in planes and on the longer train trips I have there’s power. GF9600, P8600, 4GB, 320GB — it’s slightly more powerful than my desktop machines. The keyboard is OK, takes a little getting used to because some of the punctuation is slightly smaller than usual. It has a numeric keypad, which as far as I’m concerned could have been left out for some bigger keys. The machine is a little noisier than I might have wanted, too.). There’s also a really nice VirtualBox image for OSOL 2009.6. That one only gets you a text login, though.

On the KDE4 front on OSOL, we hit some issues similar to what happens on Windows (and to a lesser degree on FreeBSD). I’ll quote Christian Ehrlicher from his recent “stopping Windows development” blog entry:

Another problem I’ve is that I could not fix bugs in kdelibs just because the dependencies are moving fast and since we have to take care for all system libs (png, xml, openssl, pcre, …). Making sure that they’re up-to-date can take a lot of time. And when I finally managed to compile a KDE program I hit compiler errors. This is all fixable but not when you’ve only a little amount of time for KDE development.

Pavel has been hacking up a veritable storm in updating our KDE builds to 4.3-beta, and I’ve been following along trying to update dependencies (gpg and friends, lzo, akonadi, …) as well. And then we hit new dependencies (what is openslp?) all of a sudden, which means backtracking and packaging some other bit of Free Software first.

All this hacking happens in the publicly writable kde4-specs-42 Mercurial repository on solaris.bionicmutton.org. It’s publicly writable so that anyone can contribute, but that also means that it sometimes gets screwed up. By me, for instance, because I pushed something last week that broke all 64-bit builds in it. Gah. Anyway, that’s cleaned up now, and the current status is: KDE 4.3-beta builds, runs ok (oh joy of konsole compared to GNOME-terminal). In VirtualBox there are rendering issues. Those will go away in time, I imagine, or once someone fiddles around with default themes and such.

My intention is to release a OSOL 2009.6 KDE 4.3-beta VirtualBox appliance as soon as I have something that works “well enough.” That means that you need to be able to log in from a display manager (gdm or kdm, I don’t care — I haven’t gotten either of them to start up properly on the appliance yet) and get at least the KDE Plasma Desktop functionality, with Konqueror and Konsole as applications. That would make me happy, as a new milestone in the ever-shifting race to keep up with KDE development.