A couple of frequency/temperature/power gotchas

/proc/cpuinfo's processor speed is misleading
In the absence of anything close to Apple's "System Profiler" on Linux, I often look at /proc/cpuinfo for some of the basics. One thing to watch for on AMD CPUs is that the processor frequency (the "cpu MHz" line) in there tells you the current frequency. On an idle system, this is likely to be the lowest of the CPU's available frequencies rather than the "maximum" frequency (the one you were probably expecting to see; "the one on the box").

For example, a 2.2GHz AMD system might report this in /proc/cpuinfo:

cpu MHz : 1000.000

You can find the full details in the /sys file system. The figure you were probably expecting to see is available thus:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq

The complete list of available frequencies is available thus:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2200000 2000000 1800000 1000000

Although the current frequency is an equally valid interpretation of "cpu MHz" as my assumption of the maximum frequency, personally I'd have been tempted to just replace the field with a different one for frequency-scaled processors, along the lines of scaling_available_frequencies in /sys, but perhaps with the current frequency listed first. That at least would be a strong clue to the reader that there's something special about this machine.

A warm reboot doesn't reset everything
Another interesting fact is that, at least with some Linux distributions and some BIOSes, this scaling seems to survive a warm reboot. (I don't actually know what power-saving measure it is that survives, but this would be an obvious candidate.)

If you're using the BIOS' CPU temperature display to see how hot your processor runs when idle, as I was recently, you may well get very different results when you power on and go straight into the BIOS compared to when you boot, tell your OS to reboot, and then go into the BIOS. On one machine I played with, the difference was that going straight into the BIOS made the processor close to 20C hotter.

As an alternative measure of the difference, the difference in the computer's power consumption measured at the wall socket was about 40W, from 145W when going straight into the BIOS down to 108W when going via the OS.

(Interestingly, Linux itself takes less still when idle; around 97W. Even switched off, the machine uses 1.5W. I remember when that would have been enough to run a computer! I'd be curious to see how this compares with other OSes, but I won't buy Windows, can't legally run Mac OS on AMD, and am too lazy to install Solaris again.)


GNOME "focus stealing prevention" a sick joke

Yet another in the long line of things that sound like a good idea on paper but work terribly in practice is GNOME's so-called "focus stealing prevention". Supposedly, this is supposed to ensure that a new pop-up window doesn't steal the focus from what you're doing. In practice, it means that:

  • Clicking on the Firefox icon in the GNOME panel opens a new Firefox window, but doesn't give it the focus. So you start typing into Google's search box, or hit control-L or whatever, and the application you were using before you clicked to start Firefox gets those keystrokes instead of Firefox. Despite the fact that the user's action clearly said "I want to work with Firefox now".

  • Clicking on links in other programs opens a new Firefox window, but again, focus stays where it was so it's a pain to interact with this new window, pretty much forcing the use of the mouse. Also, the new window won't necessarily be on top. Despite the fact that the user's action clearly said "I want to follow this link now". (The actual default behavior, at least on Ubuntu 6.10, is even worse: if you already have a Firefox window open, you'll get a new tab in one of your existing windows, so not only has the computer done something non-obvious, it's done a decent job of hiding the fact that it's done anything at all.)

  • Java programs that want to pass the focus between their own windows can no longer necessarily do what they want. Despite the fact that this may be in response to a clear and explicit user action. (Fixed in Java 7, I believe, though it will be some time before that's of any use to most users. Presumably fixed in such a way that well-behaved and badly-behaved applications alike can go back to doing what they like.)

  • Programs like Evolution – one of the most important GNOME programs – still happily steal the focus. I was writing a mail earlier (Evolution's bad behavior prompted this rant) and Evolution popped up some dialog that was dismissed by one of the keys in "ing", since I was part-way through typing the word "thing". I've no idea what that dialog said, since all I saw was a flash. I've also no idea what my response to it was, or what that caused to happen, and what problems/misconfiguration lie in store for me now. Despite the fact that the user's clear intention was to keep writing the damn mail.

I just don't believe that focus stealing was a technological problem in the first place. It was a social problem of getting developers to write well-behaved programs. There will always be a need for a program to pass focus around between its own windows based on user actions to smooth out the user's work flow. There will always a need for programs to hand focus (and topmost window status) to other programs based on user actions. So you can't take those abilities away (though you can make them harder to make use of, as we've seen with GNOME). And as long as you have these two abilities, you'll be able to write crappy programs like Evolution or GAIM that consistently and uselessly steal the focus.

Not only do naughty programs like Evolution get to continue to misbehave, but funnily enough, Firefox, which suffered the heavy usability damage described above (Firefox bug 223492) from this GNOME "feature", is one of the best-behaved programs on any of my desktops when it comes to not stealing focus. It carefully places what would traditionally be error dialogs inside the window as content instead (such as the "Try Again" button when a page fails to load), leaving focus wherever it used to be, be that with another program or elsewhere in Firefox.

Finally, although some authors whose programs may have improved their programs now breakage has forced them to become educated, that doesn't help future authors. Adding something to your library that provides Firefox-style in-window dialogs or whatever, though, and/or documentation that explains the problems of focus and includes suggestions of alternatives that may work for various kinds of application: that wouldn't break existing (well-behaved!) applications, and would potentially get us into a much better position. If they wanted something to break, why didn't they break the dialog popping-up code? Alternatively, they could have submitted patches to annoying applications they cared about. Evolution's the only application I use at the moment that's badly-behaved. (Though it's difficult to submit a bug report when you've not the faintest idea what the accidentally-dismissed dialog was.)

What we have at the moment, though, just makes everything slightly worse.

Some days I'm vaguely optimistic about Linux on the desktop. Firefox, for example, is pretty damn good on Linux. But other days, I despair. For example: if people want a technological problem to fix, how about making the clipboard persist when applications exit, like it does on Mac OS and Windows? We've only been waiting for that for 20 years now...


Review: Evolution 2.8.1

It's strange to think that just ten years ago, Linux wasn't really useful to me. It didn't have a decent web browser, it didn't have a decent Java VM, and it didn't have a decent mailer. Even if there had been some kind of killer app, I still couldn't seriously have used it. Sun fixed Linux's Java VM woes (and soon we'll know no-one will be able to take it away from us, either), Firefox fixed Linux's web browser woes, and, well, Linux still doesn't have a decent mailer.

A friend has been fighting Thunderbird lately, and since I've been trying to use my Linux box more and my Mac less (because largely giving up the Mac to my girlfriend seems easier than inflicting Linux on her), I thought I'd give Evolution another go.

It's been a while since I last used Evolution. I hated it last time, and stuck with it for less than a week. (I tried Thunderbird the week after, and it lasted about as long.) I've been through three different Ubuntu releases since then, and it seemed like time to try again.

Installation was free; Ubuntu ships with Evolution installed, and there's a little envelope with a clock on it in the GNOME panel. I don't know why there's a clock. Maybe to remind you that Evolution is really slow? Or that you'll sit around waiting a lot while it's locked up? Truth in advertising.

Configuration wasn't bad. The buttons to "Check for Supported Types" when choosing authentication for receiving and sending mail didn't work at this point, so I guessed, but guessed wrong. Luckily, when you're then presented with a barrage of errors (that don't offer to take you to the preferences dialog, even despite the fact that this is your first attempt to connect) and make your way to the preferences dialog, those same buttons now work, and draw a line through the options that your server doesn't support.

So now I was set.

Evolution didn't like my mail server's certificate. I had to manually download and install the certificate from cacert.org before Evolution would stop informing me "Signature: BAD". I'm sure it could usefully have been a little more specific there. As my friend says, "for some reason Free [software authors] don't think security should be free". The certificate installation process was a little odd, too. The "Certificates" icon in the preferences dialog was noticeably lower-resolution than the others, and scaled up. When I chose to open my downloaded certificate from the open dialog, another dialog appeared in the top left corner of the display; dragging it to the middle of the display revealed that this new dialog was actually below the old open dialog in the z-order. When I finally had the certificate installed, it wasn't obvious that it was installed because it appeared under "Root CA" (rather than the "CAcert" I was expecting) and Evolution made no attempt to highlight the newly-added entry in the list (or even ensure that it was showing).

So now I was really set.

Disappointingly, Evolution makes no attempt to actually go and get your mail. I manually checked "Copy folder content locally for offline operation" in the INBOX folder properties, but that neither causes it to automatically download message bodies and attachments until I view them, nor does it actually seem to obviate the need for Evolution to block while it goes to the network every time I click on a message. The status bar says "Retrieving message 2345 (...)". I don't know what the ellipsis means, nor why it's in parentheses. Maybe it's some kind of emoticon I'm not familiar with. Going off-line is faster when you've got fewer new mails for it to cache, but still: why isn't this happening automatically in the background?

When I am shown message content, for reasons known only to itself Evolution will sometimes position the scroll-bar as if I'm already well into the message. So I manually scroll back to the top so that I can read the beginning. Apple's Mail does this too, but very rarely. Evolution is already, after less than a day, really wearing my patience thin. (This turns out to be the fault of "Caret Mode", which can be enabled or disabled on the view menu. Caret mode does not, despite what I'd hoped, allow me to edit messages in my inbox.)

CSS support in HTML mail continues to be lacking. I wondered why Netflix's mail still looked right, even though my commit mails look wrong. "View Source" suggests it's because they're doing everything with tables and bgcolor attributes and images, presumably because they found that mailers don't do CSS very well.

If you tell Evolution you want to work offline, only at that point does it decide that it needs to start "Preparing folder 'INBOX' for offline (1% complete)", and then slowly start downloading messages. Despite the fact that it's been online for almost 24 hours now. No, it won't cache anything until the very moment you tell it you're going off-line. Obviously no-one ever does that when they're in a hurry; that's probably not even a feature laptop users have any call for. Anyway, once you've done this, Evolution's performance sucks a lot less. But this is tiresomely manual.

(On a similar note, when does Evolution actually get rid of junk mail? I flagged a mail as junk 12 hours ago, and although I can't see it in Evolution, Apple's Mail shows me it's still there. Am I really destined to end up this time next year with an INBOX carefully storing every junk mail I ever received, on the mail server?)

On the bright side, I'd forgotten how much I like Evolution's attachment handling. I really like their inline display, and the fact that they still have them conveniently collected at the top of the mail.

Mail editing is a bit strange. For some reason, when I reply, my text is wrapped; I don't know if it's soft or hard wrapped because I haven't checked. If Evolution crashes or has to be killed (and remember, this is my first day back using Evolution; it's been a long time since Apple's Mail or even MS Outlook last crashed on me or ran amok), and I start editing the last saved draft, my text is no longer wrapped.

Editing quoted text is pretty good; better than I remember it being in the past. It's more transparent than most mailers, and its behavior is less surprising. It also doesn't seem to mangle long lines when it quotes them, which I'm sure used to be one of my complaints. It's not as good for HTML messages as plain text, where its behavior is every bit as opaque and surprising as other mailers. Worse, I haven't found a way to convert a reply to plain text, which is my usual work-around.

The spelling checking continues to be fine.

While I was editing one reply, Evolution decided it needed all my physical memory. This made my computer understandably unhappy, and I ended up using control-alt-f1 to log in on the console and kill it. (By the time I accepted that it wasn't going to just come back of its own accord, it had already made the desktop completely unresponsive.) Again, not an awesome first impression, and it wasn't like I was doing anything fancy.

Search is poor. It isn't as-you-type, and there's no progress feedback while it searches. It feels like someone should buy these C programmers a second thread. It's reasonably fast now I've manually "prepared folder 'INBOX' for offline" (whatever that means), but it's not impressively fast; not as fast as it ought to be with as small an inbox as I have at home.

In summary, Evolution 2.8.1 is very slightly better than the last version I used, which I think was 2.6, and it's not bad enough that I'm uninstalling it as I write, but it do wish something decent would come along and put it (and me) out of its misery.


Finding old Apple computer specifications

For a long time I've used the lowendmac web site to answer questions about what exactly was in a particular Mac. One thing it was always useless for, though, was optical drives. Apple's tendency to label the best drive they offer at any given time a "SuperDrive", and the only alternative they ship at the same time a "ComboDrive" combined with lowendmac's verbatim use of those terms meant that you often couldn't tell what a particular machine's options were.

It turns out that all this time Apple themselves have had a better collection of their specifications at http://support.apple.com/specs/.

So, for example, I find that my dual G5 had:

SuperDrive (DVD-R/CD-RW)

Or, in more detail:

"Optical drive bay with SuperDrive (DVD-R/CD-RW) installed; writes DVD-R discs at up to 8x speed, reads DVDs at up to 10x speed, writes CD-R discs at up to 24x speed, writes CD-RW discs at up to 10x speed, reads CDs at up to 32x speed.

Finally, the build-to-order options were:

SuperDrive (DVD-R/CD-RW), Combo drive (DVD-ROM/CD-RW)

This contrasts with lowendmac's rather useless "8x SuperDrive standard on all models". I suggested to them a few months ago that they could usefully be a little more specific, but received a reply that made me wonder if they even spoke English.

Obviously, if you're on the console, you can ask System Profiler exactly what's fitted, and even find the manufacturer, model number, and firmware version. But sometimes you're not at the console, or you want to know what someone else's computer might have, or you're trying to remember what an old machine you no longer own had. Sometimes, as yesterday, you want to answer a question that the computer itself is unlikely to help with, such as "how heavy was my iPod?".

"apple specs" appears to be the most convenient Google string. I don't know why I've never come across it before. I'll have to remember to use Apple instead of "lowendmac" in future.


Bidi text input in Swing is enabled by default

I helped someone out last week when they had trouble with a text field in a Java application. The symptom was that they were using their application's find functionality, entering a search string, and the text had "suddenly" become right-justified in the field. At the same time, the caret had grown a little triangular ear.

It was obvious (to me; the user was mystified and convinced it was a problem with the application) that they'd accidentally switched to right-to-left text entry, but it wasn't obvious how to switch back. It was probably a toggle, but if they couldn't remember what they'd pressed in the first place – and they couldn't – that was of no help.

I tried searching the web, but didn't find anything explaining how to toggle between left-to-right and right-to-left text entry in a Java Swing application. This post is so that next time I need this information, I don't have to read the JDK source again.

It had to be part of the DefaultEditorKit, so I started looking there. Sure enough, there's a ToggleComponentOrientationAction there. It's in the collection of default actions, but its name isn't public, for some reason. (There are a few other actions whose names aren't public too.) Anyway, searching for the value of the constant, "toggle-componentOrientation", it turns out to be bound in all of the standard LAFs to "control shift o".

So if you're using a Java application and your text entry is suddenly right-justified and caret looks slightly strange, hit control-shift o and things will go back to normal.