Well, I guess there ain't many of you, but if you happen to be a parent considering taking your child to see Bridge to Terabithia:

DON'T.

Unless said child is at least 30 and very emotionally mature.

Not that it's a bad movie. It's fantastic. It's just nothing at all like the trailer leads you to expect. It is not a happy heroic fantasy movie pitched somewhere between Narnia and the Neverending Story. It's not about fantasy at all, really. And out of four reasonably cynical people I saw it with this afternoon, three of us were crying through the entire final third of the movie. And I checked, and the fourth actually is made of stone. I hate to think what a ten year old kid would make of it.

Damn good movie, though.

Just to get the word out - most Mandriva-related mailing lists are down. A hard drive died on the ML server, it's proving difficult to fix. Nic is hoping to bring it back up by tonight (Paris time).

No, I don't know when the hdlists will be fixed...

Wow, I'm on a roll today!

After getting VirtualBox going earlier, I came across a blog post from Ross Burton. He and I have been in the same situation for a while. We both have laptops with Intel chipsets that we use regularly with external displays. For both of us, our external display has a different (larger) resolution than the internal display. We want to be able to switch from one display to the other, have the desktop resize appropriately, and carry on using the system. Seems simple enough, but with current stable X.org stuff it's actually impossible. It's not really capable of detecting the available modes for more than one connected display. xrandr will only ever give you the correct mode for one of the displays; if you try and switch to the other and use xrandr to resize the display appropriately, the correct mode just won't be available.

However, the bleeding edge code is very different. Keith Packard is currently implementing a new version of the randr stuff, 1.2, which is able to detect all connected displays and the resolutions of which they're capable at all times. It's fine with you connecting and disconnecting monitors, and it will be trivial to write daemons and tray applets etc which will be able to do pretty much whatever you like for any number of connected displays, change status on plugging / removal of a display, etc. For now, all there is is the new version of the command line tool xrandr, but it's good enough for me.

After seeing Ross' post I went off and built all the mentioned stuff directly from tarballs, and...it didn't work. X wouldn't start as user due to privilege issues (missing some patches from our x11-server RPM package), and starting it as root, there was a problem with libdrm. So I decided I'd go another route - rebuild the Cooker SRPMs with the appropriate code.

This seemed a bit ambitious as I've never really built modified packages before and the X server didn't exactly seem an easy place to start, but what the hell. I know just enough from doing straight rebuilds and looking inside .src.rpms to get me in trouble, so I went ahead, figuring out the rest of the stuff as I went along. Basically it came down to installing the .src.rpms, replacing the source tarballs with tarred up versions of the git snapshots for all the randr 1.2 stuff, fixing a few things (had to remove a patch, change some file references etc), adding changelog entries and bumping the release versions. To my frank shock and amazement, this all worked first time: I got each RPM built and installed, restarted X, ran xrandr, and lo and behold:

[adamw@lenovo ~]$ xrandr Screen 0: minimum 320 x 240, current 1680 x 1050, maximum 1680 x 1200 VGA connected 1680x1050+0+0 (normal left inverted right) 433mm x 271mm

...

LVDS connected 1280x800+0+0 (normal left inverted right) 261mm x 163mm

Using the appropriate xrandr commands, I can now switch between my two displays easily without restarting X. It's brilliant, it'll make it much easier to just wander around the house when the feeling takes me, or to take my laptop out with me.

I won't be submitting the packages to Cooker as, apart from the fact they're slightly hacky (I couldn't figure out how to do pre-release version tags based on dates, as is the policy, so I just pretended everything was 1.2.0 final, and some other little things), they're useless to anyone who DOESN'T have an Intel chipset. In fact they're probably harmful, as I don't think xrandr 1.2 will work at all - even with restricted functionality - on any other chipset. But I'm happy to provide them for anyone with an Intel chipset who wants to take a look. Obviously no guarantee they won't blow up in your face, but they work here. The binaries are for Cooker, I can provide .src.rpms for anyone on 2007.0, not sure if they'd build clean there though.

ATTENTION GOOGLERS: Both sections of this page are now out of date. If you want to move from VMware to VirtualBox, what you really, really want is VirtualBox 2.1 or later. As of that version, VirtualBox fully supports VMware's VMDK disk image format, so you can simply load your VMware disk image into VirtualBox, which makes the entire first half of this page obsolete. VirtualBox 2.0+ also features a much-improved networking system, which makes the second part of this page obsolete. So please consider this page as of historical interest only.

My tests with VirtualBox went well enough that I decided to move my webserver and mailserver VMs to it (from VMware Workstation 6 beta). VMware does the job great, but VBox is open source and a little faster. So the machine serving this page to you is now running in VirtualBox :)

The conversion process isn't exactly straightforward, though. Unfortunately there's currently no tools which can convert a VMware hard disk image into a VirtualBox one. So with help from the guys in #mdv-cooker IRC - especially Colin Guthrie, thanks Colin - I used the following method.

Basically we're going to keep the VMware machine running, create a new VirtualBox machine with an empty hard disk, boot it with a rescue CD, and rsync the entire system from the VMware machine to the VirtualBox one.

So, first of all, make the VMware machine as static as you can - stop all unnecessary services, etc. Just so no changes get lost in transition.

Now, run VirtualBox, create a new machine with whatever settings you like. Get the System Rescue CD image, and set that image as the CD drive for the VirtualBox machine. Boot it up.

Now set up the partitions on the hard disk - sysresccd has gparted, but I didn't use it, I just used fdisk, mkfs.ext3 and mkswap. It's obviously easiest if you're just going with a / and a swap partition, but you can adjust this for more complex cases. Once the partitions are done, mount them somewhere - I just used a single partition, and mounted it as /mnt/new .

You need to have rsync installed on both machines, and an ssh server running on the VMware machine and an ssh client on the VirtualBox machine. You also need to be able to transfer files as root from the VMware machine to the VirtualBox machine, so you must either set up keys appropriately or set the ssh server config to allow password-based login and allow direct root login. Obviously change these settings back to something more secure afterwards.

Once all that's set up, run this command:

rsync -avWHS -e ssh --exclude /proc --exclude /sys --exclude /dev --delete root@vmware:/ /mnt/new

where 'vmware' is the name or IP address of the VMware machine, and /mnt/new is wherever you mounted your new root partition on the VirtualBox machine. Then wait for a while. The entire machine will be rsynced across.

Now there's just some cleaning up to do. First, check /mnt/new/etc/fstab - I'd switched from hda1 as swap and hda5 as root to hda1 as root and hda5 as swap, so I had to adjust that. Also check /mnt/new/etc/lilo.conf for similar issues, and /mnt/new/etc/modprobe.conf (depending on what hardware you had set up in the VMware and what you have in the VirtualBox, you may have to change something here). Also, create the directories /mnt/new/proc and /mnt/new/sys (Mandriva at least will fail to boot if these don't exist).

Finally, you need to create the /dev tree and install the bootloader, and to do that, we have to chroot. Do chroot /mnt/new. If it complains about /bin/zsh not being found, you don't have zsh installed on the VM - just copy the file from /bin/zsh to /mnt/new/bin/zsh and try again.

In the chroot, simply run makedev /dev and then lilo (assuming lilo is your bootloader, of course). Now everything is done. You won't be able to power down normally, so just shut off the machine via the VirtualBox menu. Unmount the CD image and boot up again, and the machine should boot just as normal.

The other thing I had trouble with was setting up host-based networking - bridged networking, effectively. As with VMware, you need this method of giving the VM a network connection if you want the machine to be accessible from the outside world (as I obviously do). The instructions in the VirtualBox manual don't work as printed, they seem to be incomplete. I'm very grateful to the author of this post on the Ubuntu forums, who figured out the whole process. You need the tunctl and brctl utilities. In Mandriva, they're in the tunctl and bridge-utils packages respectively. These are the commands you have to run, on the host machine, as root:

tunctl -t tap0 -u user (where user is the user who runs VirtualBox) chmod 666 /dev/net/tun (or add user running VirtualBox to the 'tun' group, on MDV) brctl addbr br0 ifconfig eth0 0.0.0.0 promisc (where eth0 is the interface to be bridged) brctl addif br0 eth0 dhclient br0 brctl addif br0 tap0 ifconfig tap0 192.168.1.50 up (where 192.168.1.50 is an arbitrary unused IP in the same subnet as your local network) echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp route add -host 192.168.1.5 dev tap0 (where 192.168.1.5 is the IP address of the host machine) arp -Ds 192.168.1.5 eth0 pub (where 192.168.1.5 is the IP address of the host machine)

After that, I had to figure out how to create additional tap interfaces, as I want to run two VMs and they can't share. You don't need a second bridge, you can use the same one. These are the necessary commands:

tunctl -t tap1 -u user (where user is the user who runs VirtualBox) brctl addif br0 tap1 ifconfig tap1 192.168.1.51 up (where 192.168.1.51 is an arbitrary unused IP in the same subnet as your local network, not the same as tap0) echo 1 > /proc/sys/net/ipv4/conf/tap1/proxy_arp route add -host 192.168.1.5 dev tap1 (where 192.168.1.5 is the IP address of the host machine)

Obviously you can adjust that set of commands to create a tap2, tap3 etc - as many as you need. Then you just assign one tap* interface per VirtualBox machine.

With these settings, if all goes well, the VirtualBox machine can get its own IP address on your local subnet, just as with VMware's bridged networking mode.

VirtualBox is currently only packaged for Cooker in Mandriva. As my VM host machine runs 2007.0, I backported it to 2007.0 for this setup. The packager doesn't want to put the current version into the official 2007.0 /backports repository as he doesn't consider it stable enough, but if anyone's interested in my backported packages (I also backported tunctl, which isn't in 2007 either), I can provide them on request.

Thought it was about time to write a bit of an update on what's been happening with Mandriva lately.

Yesterday I went out and picked up a 1GB RAM module to upgrade my laptop to 1.5GB. (Took me ten minutes to convince the salesman that yes, I could use a 1GB module to upgrade my 512MB system, and no, I wouldn't be back in an hour demanding a refund...sigh). This gives me enough headroom to go back to messing around with virtualisation stuff - 512MB just isn't enough room to start running VMs alongside my regular desktop system.

Fortuitously, at around the same time, VirtualBox showed up in Cooker, having recently been open sourced by its writers. To be frank it's a fairly close ripoff of VMware, but it is a little more elegant in some ways (doesn't have that hacky vmware-config.pl to worry about - the host kernel module comes in a nice dkms package, at least on MDV - and the guest OS tools install rather more elegantly too). And, of course, it's open source. After a few false starts (it doesn't like reading a real DVD from the host system, or maybe my DVD is just damaged, but it's fine with a .iso) I got a full install of 2007 Free up and running nicely inside it. I'll start doing installs of the competition today. Good piece of software, worth checking out, especially if you're looking for a free VMware alternative.

After that, I started in on an almost identical install in VMware, to create a Mandriva appliance we can get on the VMware website (something dbarth asked me to do months ago - sorry, David). I'm just finishing off that install now, then it'll be available probably from the VMware site and also possibly from our public mirrors.

We're working on the next release, Mandriva Linux 2007 Spring (the 'formal' name) / Mandriva Linux 2007.1 (the 'technical' name). We're trying something a bit new - we're back on a six month release cycle, but the base system for 2007.1 will be the same as 2007.0 (that basically means the kernel, glibc and a few other very low level bits). This should provide a basis of stability and continuity to build the rest of the distro on. Otherwise it'll be very up to date - GNOME 2.18, KDE 3.5.6, OO.o 2.1 etc. It will include the Metisse accelerated desktop we previewed recently in One Metisse: drak3d will let you choose between AIGLX and Xgl as it did in 2007.0, but also between compiz, beryl and metisse. I'm happy that we're still considerably ahead of the pack on 3D desktop stuff - the rest of the distro world seems to be just about catching up to 2007.0 now.

I've wound up being rather involved in the process of providing updates for 2007.0, as I've become the de facto maintainer of the Errata page. We introduced a new procedure for doing updates for 2007.0, alongside the new media structure which provided an /updates repository for contrib (which never had one before) along with /testing and /backports repositories for both contrib and main. To introduce an update to /main/updates , a packager identifies a specific bug or security issue that needs fixing, builds an update that should fix it, tests it himself, then uploads to /main/testing where it can be tested by users experiencing the problem. After this stage, the maintainer writes an advisory text for the update and provides a step-by-step procedure for reproducing the bug, and passes it on to the QA team, who verify that they can reproduce the bug and the fix and that the package causes no other problems. They then pass it on to the security team, who test it again, rebuild and resign it, and ship it out as an official update with the advisory text.

Despite seeming to be more complex than the old 'procedure' (which was never written down but basically consisted of bugging the security team, who had to do everything), this has resulted in far more updates being built, and those updates being of a higher quality. We used to do very well on security issues but not so well on bugfixes, with those bugs that were fixed taking a long time (remember the X.org issue with 2006) and some serious ones remaining unfixed. Now there's a sensible procedure which splits the work up more or less equally and is unequivocally written down, everyone's buying into it pretty well and bugfix updates are coming much faster and in greater numbers - just take a look at the resolved issues section of the Errata.

Having /contrib/updates has also been great as contrib packagers now have a good place to push bugfix and security updates when they do want to provide them, whereas previously they went to the community tree, which no-one knew about, to die. There have been almost as many updates for /contrib as there have been for /main, despite its officially unsupported status.

Another nice recent development to do with packaging has been the public /non-free section, which I've been pushing for a while. In Cooker there's now a /non-free section on the public mirrors alongside /main and /contrib which contains the most important non-free packages - drivers and firmware like the NVIDIA and ATI drivers, the firmware for Intel Centrino wireless chipsets etc. This used to be provided only on commercial editions and to Club members through the Club Commercial repository. In the past this was an advantage for us as few others provided it at all, but these days it's turned into a disadvantage as distros like Ubuntu and SUSE provide it on public mirrors. So I'm happy to see us move into doing that too. On a technical level, it also means that building non-free packages and updates works the same as free ones, which should increase the quality and transparency of that packaging and hopefully allow us to ship updates for non-free packages much better in future. The final benefit of this is that it's just easier for users to access - even though Club members currently have access to this stuff, setting up the Club Commercial repository to get at it is kind of a pain.

We're also planning in future to have the other non-free stuff provided the same way, except it won't be accessible to all. It will be in a section named non-free-restricted which will be present on the public mirrors (or at least some of them), but only visible and accessible to Club members who log in to the servers using their Club email address and password. We have most of the technology available to do this, it's just a question of pulling it all together and getting some of the mirror admins on board. If we can manage this, it will allow us to finally ditch the Club package server, which has always been more of a hack than the main mirror setup. It's not going to be done for 2007.1 though.

So, yes, I know I don't get time to update much about work, but rest assured, we're still busy and improving on things all the time :)

so just after I re-schedule my trip back to the U.K. to be in March instead of my birthday in February, I find out that Ash (possibly my favourite live band ever) are playing in Manchester on my birthday.

Curses.

If you are at all interested in any way in playing any form of media on any computer, you need to read this. Yes, even if you don't run and never intend to run Vista.

It's an amazing analysis, and it's this kind of thing that really gets my goat about Microsoft and the RIAA / MPAA.

So, the author of that article got my email and rewrote the article.

Score one for Science!

Ah, so as this Independent article on the same subject makes clear, the idiot was the journalist, not the curator of the Zoological Society. It seems the theory was that the parthogenesis ability evolved in the normal fashion and the reproductive advantage was that a female who evolved this ability swam to / was washed up on an island alone, and was able to reproduce. The BBC journalist then utterly misunderstood the theory. Well, my confidence in the Zoological Society is restored, at least. The BBC need to send their reporter back to high school, though.

I find it deeply worrying and hard to believe that either a science journalist with the BBC or the curator of the Zoological Society has no idea how evolution works, but it would appear to be the case. Spotted this gem in this BBC story about parthogenesis in giant lizards:

"[The curator of the Zoological Society] said the lizards could have evolved the ability to reproduce asexually when, for example, a lone female was washed up alone on an island with no males to breed with."

No. No, they couldn't. Given the terms of the scenario the only possible way such an ability could develop in that situation is during the lifetime of a single female giant lizard, which is expressly not an evolutionary change (and is extremely unlikely to have happened). The change is only evolutionary if it appeared through natural genetic variation in the child of a pair of lizards who did not have the ability, and if it then gave that child a reproductive advantage which resulted in the ability spreading through the population.

I mean, Christ, I know this based on high school biology. There's no excuse for a science journalist to mess it up.