Raw Matter

Since I've never blogged about movies before, here's the “best of”, in more or less random order and from the top of my head.

• Brazil (Not the Love Conquers All version, though.)
• Kill Bill (Distinctly Vol. 1. Al Hirt is a hero on the soundtrack, too)
• Tron
• Lost Highway
• Twelve Monkeys
• Pulp Fiction
• Dark City
• Chat Noir, Chat Blanc (Pit Bull Terrier! That song alone...)
• Lock, Stock and Two Smoking Barrels
• Dune (but only because the book is outstanding already.)
• Minority Report
• Dead Man
• A Clockwork Orange (Heavy, though.)
• Iris (one of the very few movies that really got to me)
• The Meaning of Life
• Dogville
• The Great Dictator

Not quite on the list, but still worth mentioning.

• The Matrix
• The Lord of the Rings (impossible to separate them out)
• Snatch
• The Hitchhiker's Guide to the Galaxy
• Helvetica

Just watched Minority Report last week. Quite good, disappointing ending. Should stop ca. 6 min earlier, when it becomes clear that precrime collapses (and after the resolution of the plot.) The tagged-on happy-end seemed artificial and implausible to me (implausible by the standard of the world of the movie, that is :-).

Somebody should convince Linus that he should give Debian a try. His implicit claim that Debian is hard to install might have been true up to potato or woody, but I've always found sarge and certainly etch a pleasant experience to install, in some aspects even much better than the leading commercial distributions (not loading X and a huge graphical installer from a slow CD drive speeds up installation enormously!)

Reader Comment: Chris Camacho says: “I read that too, and worse still it probably means he's disregarded Ubuntu as being just a debian off shoot and therefore not worth looking at. I've turned a number of ex-windows on to using Ubuntu and they all claim to a (wo)man that its easier than windows to use. go figure...”

Joey's fortunes collection brought me a Linux Torvalds quote today:

I'd almost prefer to just put the zombie children on a separate list. I wonder how painful that would be...

What kind of horror movie torture master would keep lists of zombie children? Anybody bored and skilled with The Gimp?

I use apt's preferences to give decreasing priorities to our Debian releases/suites. On my server, sarge has 800, etch has 750, lenny has 700 and unstable has 600. There are addtional values for backports and some other repositories. Generally, the newer, the lower the priority. So I can mix and match between these repositories and have aptitude upgrade generally do the "right thing" (and aptitude's dependency resolution is great to solve even complex issues). This is, for me, one of Debian's strongest points.

But sometimes, there are these strange effects... Like when I decided that I'd follow etch and etch-volatile for clamav (the server is still in progress from sarge to etch), but then the new available version in sarge-volatile is higher than the currently installed version, which came from etch-volatile. I'm not sure if a "correct" solution is possible or if I would even want one - after all, I did specify sarge on a higher priority than etch, and by using volatile I stepped basically a bit "outside". It's probably just to keep me on my toes... But still, the clamav people win the award for the most illustrating use of multiple repositories and apt priorities I've seen so far.

clamav:
  Installed: 0.91.1-1~volatile1
  Candidate: 0.91.2-0volatile1
  Version table:
     0.91.2-1 0
        600 http://sunsite.cnlab-switch.ch unstable/main Packages
     0.91.2-1~volatile1 0
        750 http://mirror.switch.ch etch/volatile/main Packages
     0.91.2-0volatile1 0
        800 http://mirror.switch.ch sarge/volatile/main Packages
     0.91.1-1 0
        700 http://sunsite.cnlab-switch.ch lenny/main Packages
 *** 0.91.1-1~volatile1 0
        100 /var/lib/dpkg/status
     0.91.1-1~bpo.2 0
        740 http://www.backports.org etch-backports/main Packages
     0.91.1-1~bpo.1 0
        200 http://www.backports.org sarge-backports/main Packages
     0.90.1-3.1lenny3 0
        700 http://security.debian.org lenny/updates/main Packages
     0.90.1-3etch4 0
        750 http://security.debian.org etch/updates/main Packages
     0.90.1-3etch2 0
        750 http://sunsite.cnlab-switch.ch etch/main Packages
     0.84-2.sarge.17 0
        800 http://security.debian.org sarge/updates/main Packages
     0.84-2.sarge.15 0
        800 http://sunsite.cnlab-switch.ch sarge/main Packages

Update 2007-10-11: Another Dell story. And one extra for free, even.

There was a time that a small-ish (ca. 70 office workplaces) company bought almost all of its IT products from Dell, with 3 year on-site warranty to be on the safe side. There was a time when all was well and, in the rare cases that something needed to be replaced, a gentlemen would arrive and magically fix all that needed fixing.

There was also a time, a bit later, when this enterprise wishes it could get rid of all the remaining Dell devices immediately (but of course you don't buy 100-odd desktops, servers and printers just because you no longer like the vendor.)

One, if I buy a 4h-reaction-time warranty contract and tell them that I have a problem and that probably a part needs replacing, I don't expect to have to play ticket ping pong for a whole week until they agree that there even is a problem.

Two, if there is a problem with a range of computers (leaking condensers) and more than half of our workstations are affected, I'd expect Dell to care about this and be at least ready to discuss mass-replacing the faulty motherboards in one go instead of having to send a tech every three days for yet another case of this problem. I'd think it's cheaper for them as well....

Three, not that I really care, since it's covered under warranty so I don't pay for it, but if I have two defective computers at the same site I'd expect one tech to fix them both, not two techs to come out (missing each other by 5 min) to fix one computer each. Again, you'd think they'd do the maths on how much these techs cost.

Four, wouldn't it be nice if you could buy two laser printers and the toner cartridges would even be the same? HP, for example, manages to use the same toner cartridges for a whole range of printer models. Dell apparently can't do this. (Admittedly, I've only seen it in the case of the 5100cn/5110cn printers, and sometimes there are reasons to change the toner cartridges. But then I'd expect the printer model to be significantly different. Those two printers look exactly the same from outside, and the innards also look identical at first glance, including the toner cartridges, except for some coded plastic pieces ensuring that the cartridges don't match.)

Five, wouldn't it be nice if toner cartridges could be bought at your regular office supply store, where we buy every other brand of cartridges? No, of course nobody but Dell themselves sells Dell supplies. Since supplies are not dealt with by IT staff, this is really annoying. Especially beacuse Dell has repeatedly, for unclear reasons, disabled our login to the Dell online store (and we can't just create a new login as we have special discounts, so our account needs some special handling.)

Six, how long is the usual life expectancy of a Laptop battery? For the Inspiron 9300 80Wh and the 53Wh battery, it's apparently 18 months, after which the battery doesn't charge anymore or only holds power for 2 minutes. Dell customer support confirms this is normal behaviour for these batteries and this is not covered under warranty accordingly.

What now? Printers: HP. Desktops, Displays and Laptops: Lenovo. Servers: IBM. Network Switches: D-Link. Not sure if these choices are ok, but so far we've had fewer problems than with Dell. But of course the Dell stuff is older and so more prone to failure, so probably we'll just have to re-evaluate 3 years from now.

Update 2007-09-04: To be fair: the information that Laptop batteries are not covered was from Dell's support web pages' "comment" feature. Today, I phoned them up and was surprised to hear that Dell batteries are, apparently, covered under warranty in certain circumstances, so I should be getting a new battery by tomorrow. But, 30min later, the same persion calls me back to tell me that no, he was wrong, he won't be sending me a battery. So it's still official by Dell's support people: batteries don't last longer than a year.

In answer to Russel's recent “tips for new contributors” posting, I give you the answer to the ultimate question about life, the universe and “How can I contribute?”:

Find an area that you really care about.

Or, rephrased in a less friendly way: “If you have to ask, don't.”

And answering Russel's real question (one sentence to give to somebody who wants to contribute): “Know the community. Respect the people who are in the project much longer than you.” Knowing the technology isn't important - it's always possible to learn technology. But not knowing the community leads to frustration very quickly, and the new contributor will possibly not even have the chance of having the technical side of things even seriously looked at. (Of course, you may still come to the conclusion that you know more than “them” and that the people running the project right now are morons. If this sentiment persists, perhaps it's time to fork the project?)

Ganneff's reply is also worth thinking on.

Since I seem to be the last person these days who doesn't run his servers inside Xen, Vserver, kvm, lguest or whatever, I decided to finally evaluate Xen. Not having spare hardware and not wanting to really touch my main workhorse, I started with Qemu.

Installing etch inside a Qemu (why can't qemu have working tun/tap setup scripts by default?), then xenifying this according to Ganneff's excellent slides, I was stopped while booting into the Xen kernel with a hard freeze in the boot process (Inside Qemu, so no harm done.) Talking to some people in #xen resulted in me disabling kqemu, and a few minutes later I had a working dom0.

Debootstrap is slooooooowwww (well, inside a non-accelerated Qemu machine...)! So I decided to use cdebootstrap instead. Sadly, xen-create-image has debootstrap hardcoded, so I had to "ln -sf /usr/bin/cdebootstrap debootstrap". (I decided to do this when debootstrap was still calculating dependencies after several minutes.) After that, creating and booting a domU Just Worked(tm).

Having a running Xen environment, I finally wanted to play around with live migration (mostly I was just curious how robust this Qemu + Xen setup is...) So, just clone the qemu disk and boot them both. Whereupon the two qemu machines have the same MAC address, hence networking is not reliable. Change the MAC of the second Xen dom0, curse udev for thinking that now the network interface should be eth1 (persistent device naming is a good thing, generally. I'm not sure there is a sane solution possible that can cover all/most cases. Computers with only one network interface might warrant some special logic ... Oh well.) Having restored the networking setup, enabling the relocation service in the Xen configuration is trivial.

After thinking about using plain files on NFS and seeing a Novell tutorial which uses iSCSI, I decided that I should try AoE because it should be much simpler to set up. And by installing the 'vblade' package, it is indeed possible to have an AoE server running within a few minutes (the vbladed command doesn't take the -m option, though.) And the client side is just as simple, just install the aoetools package, and /dev/etherd is automagically created and lists all available devices. That's how SANs should work! (Note: I had the AoE devices in the dom0 and passed them to the domU. A next experiment would obviously be to pass AoE directly to the domU as root devices. Not sure what the implications would be, though.)

Ok, after all this, I have two dom0 machines and a domU. Just for fun, I've installed xdaliclock inside the domU and started a live migration. Result: it works stable (modulo some scary kernel messages popping up when booting the domU. I didn't experience any crashes in this light test), xdaliclock stops for a mere 20s (yes, seconds, not milliseconds. Remember, this is two layers of virtualisation without hardware support.) Normal migration (pausing the domU), the migration takes roughly 2 min (both dom0 have 384M RAM assigned in Qemu, the domU has 128M in Xen, the host is a 3GHz P4 with 1G physical ram. There is some swapping going on (I use KDE, so some of the RAM is lost there. I also didn't stop beagle for this experiment.) The full live migration takes about twice as much time. But this said, if you're using Xen inside qemu, timing values are not what you're after... I was, frankly, astonished at how well this worked.

Hmmm. I wonder, if I can stack some other virtualisation layer somewhere in there? Just to see how silly it might get.