Wandering Thoughts archives

The theoretical advantage of a separate /boot filesystem

To elaborate on something I said in a comment on here, the theoretical advantage of using a separate filesystem for /boot instead of just putting it on your / filesystem is that your root filesystem isn't limited to environments that GRUB (or the bootloader of your preferences) can understand. This matters (in theory) because GRUB more or less inevitably lags behind the operating system in general; first the code has to be written in and stabilized in the kernel, and then it has to be ported into GRUB.

Whether this an advantage in practice depends on what you want to do with your root filesystem. At the moment, I think that the only major limitation that most people are likely to run into is that GRUB apparently doesn't understand LVM, so this may not be much of an issue. (On the other hand, lots of Linux distributions seem to more or less default to LVM these days.)

People setting up more esoteric environments (or just wanting to be prepared for them) are more likely to run into this, especially if you want to live relatively close to the bleeding edge. (For example, I'm not sure if GRUB supports ext4 yet, which means that if you want to be able to upgrade your root filesystem to ext4 the moment it's supported in your distribution, you're going to want a separate /boot.)

Given the GRUB issues with LVM, I expect that I'll continue using a separate /boot filesystem just on general principles.

Using fully mirrored system disks on Linux

I'm on record as building systems that use mirrored system disks with plain /boot and swap partitions (that is, non mirrored, just duplicated), mostly through ancient caution.

You know what? I was wrong. Totally wrong. I've now built a system with a fully mirrored system disk and not only does it work, it works better than my old way. I will henceforth now mirror /boot and swap, in addition to all of the regular filesystems, on all future systems that I build with mirrored system disks.

With /boot, mirroring keeps things in sync automatically, and it means that the system will come up without manual intervention when there's only one disk. With a /boot and a /boot2, not only do you have to keep them in sync by hand (in practice we don't), but if a disk fails the system will pause in boot because one of your filesystems isn't there and you have to fix it by hand.

With swap, you probably don't need that much swap, it works, and while init scripts seem to be much more tolerant of missing swap areas than missing filesystems I don't see any reason to take chances if I don't have to. And 'mirror everything' is a very simple rule to keep straight.

(I don't have any idea of the performance tradeoffs of mirrored swap versus non-mirrored swap, but my view these days is that if you are worried about the performance characteristics of your swap space, something horrible has gone wrong to start with.)

How not to improve your CD player application

This is one of the rare entries that I have to present in pictorial form.

Here is a 65% size view of what kscd, the KDE CD playing program, looks like in Fedora 8 (where it is version 1.6, from KDE 3.5.10):

Here is what it looks like in Fedora 10, again 65% size:

(Links to full sized versions are here and here. Note that the Fedora 10 version is a shaped window; the black areas are normally transparent.)

One of these two applications is useful. The other one has been 'improved', presumably because people thought that the first one looked kind of boring (also, apparently, people wanted to be able to give the CD player 'skins'; there are several supplied with Fedora 10's kscd, all of them equally bad). In the process it has been made less useful and even less functional (they are playing the same CD, but only the older one displays the artist correctly).

Apparently I now need a new CD player program, just like last time. Which is a real shame, because kscd was a nice CD player once it started working reliably in Fedora 8.

(Alternately I need to figure out how to build the Fedora 8 version of kscd on Fedora 10. Hopefully the KDE libraries are compatible enough.)

What seems to use power on a Dell Mini 12

Since I had a Mini 12 around and I'd previously done similar measurements with an Asus Eee PC, here are some measurements about what seems to draw power on a Dell Mini 12. The necessary disclaimers are that all of these measurements are made with a power meter while the Mini 12 was on wall power, running Dell's version of Ubuntu.

(Ubuntu exposes a lot more controls for this than Asus's Eee setup, so I suspect you could duplicate these results on battery power or opt to reduce power consumption at the expense of things like a dimmer display.)

(I couldn't detect a power difference from turning the wifi off and on; either it doesn't draw much power, or Ubuntu can't actually turn the wifi hardware off and hitting the 'wifi off' key combination just stops Ubuntu from listening to it.)

Or in other words, the Mini 12 draws between 5 watts (if left sitting idle with the screen off) and 15 watts (at full activity). It draws 11 watts for my typical usage, with the screen at full brightness but the system mostly idle. As with the Eee, the best non-disruptive thing you can do to save power is to power down the screen; unfortunately there seems to be no screensaver setting to power the screen down immediately when it's invoked, so I resorted to using 'xset dpms force off' again.

Dell quotes the capacity of the Mini 12's normal battery at 24 watt-hours. At 11 watts for casual usage this predicts a bit over 2 hours of run time, which agrees with my experience. Given the power consumption for playing Youtube videos, the Mini 12 is probably not the machine to use for watching your own movies during boring airplane flights. (Well, not unless they give you power sockets. And I don't know if it has enough CPU power to play video at any significant resolution; I didn't test that.)

It's possible that Windows Vista can do better than Ubuntu here, but then you'd have to run Windows Vista and, trust me, you don't want to on the Mini 12. (Our evaluation Mini 12 actually came with Vista; it was achingly slow.)

(There is no power rating for suspend to RAM because as far as I could tell, the Mini 12 (under Ubuntu) didn't support it. The Mini 12 draws no power when suspended to disk or powered off, as you'd expect.)

The ASUS Eee PC versus the Dell Mini 12

I have an ASUS Eee PC (one of the original small ones) and I've recently been playing around with a loaner Dell Mini 12. Since it has to go back, now seems like a good time to do a short comparative review.

From my perspective, the Mini 12 has only three real advantages over the Eee PC: it has a significantly larger screen, it suspends to disk because it has a hard drive instead of a small SSD, and it runs a more or less standard Ubuntu. Of these, the screen is the most important change. The Eee's too-small screen was my only serious issue with it; the Mini 12's screen is large enough to be unapologetically usable.

The advantage of suspend to disk over the Eee's suspend to RAM is that suspend to disk draws no power, so I can just leave the Mini 12 suspended as long as I want to and then bring it back to action within seconds. With the Eee, I only suspend for short duration things; longer duration things force me to power it down. In practice, this is a significant convenience gain for the Mini 12.

(The Mini 12 probably has a better keyboard, although I still had some issues, and certainly it has a noticeably bigger one, but I don't find the Eee's keyboard particularly objectionable.)

The Mini 12's standard Ubuntu install is both an advantage and a drawback. In my experience, the Eee's software is generally better but more bizarre while the Mini 12's Ubuntu setup has various rough edges (and it inexplicably omits a PPTP VPN client in the default software install). I can see why ASUS did the Eee software the way they did, but the result is that the Mini 12's setup is more comfortable for me (despite the rough edges).

(Also, the process of handling the Mini 12's software fills me with more confidence than the handling of the Eee's. ASUS thinks that they are selling an appliance, while I am reasonably confidant that Dell gets that they are selling something with Linux on it.)

The result of all of this is that the Eee is a small thing that I carry places in order to access other machines, but the Mini 12 is a light laptop that I carry places in order to get real work done. Whether this difference is an advantage or a drawback depends on what you want.

My personal reaction is that after having an Eee I had no temptation to spend my own money on one, while after playing with the Mini 12 I have at least some temptation.

(It is not a very large temptation because I would like a netbook that has hardware with open source drivers so I could run whatever Linux I wanted on it; like the Eee PC, the Mini 12 requires some proprietary drivers, I believe for the wireless and for the graphics. Unfortunately I don't know if there is any 12" netbook that qualifies.)

Hardware wise I think it's about a wash between the two, with the Mini 12 ahead in some areas and the Eee ahead in others (eg the Eee has a better mouse pad (although worse mouse buttons), better audio, and more useful LEDs). They weigh about the same; the Mini 12 is probably heavier but it doesn't feel as dense. The Mini 12 has no fan and does not appear to get particularly hot, and draws somewhat less power than the Eee (but, in the small battery configuration, has no better battery life).

(It is hard to tell relative performance between the two, but for what it is worth the Eee actually feels snappier. This may in part be the price for having an actual hard drive in the Mini 12.)