Five Pounds of Flax

Every culture has a burrito.

What the...?

Monday, April 23, 2007posted by Michael Rothwell @ 5:29 PM

A kernel thread crashing, perhaps?




Date/Time: 2007-04-23 17:27:05.258 -0400
OS Version: 10.4.9 (Build 8P2137)
Report Version: 4

Command: ???
Path: ???
Parent: ??? [0]

Version: ??? (???)

PID: -1
Thread: Unknown

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x21000080
(null)
Unknown thread crashed with i386 Thread State:
eax: 0x00000000 ebx: 0xb80f678c ecx:0xb831c7c0 edx: 0x21000080
edi: 0x82008064 esi: 0x3fffeb47 ebp:0xb0099c08 esp: 0xb0099bc0
ss: 0x0000001f efl: 0x00010246 eip:0xb80f6874 cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs:0x00000000 gs: 0x00000037


I *heart* Unix

Wednesday, April 04, 2007posted by Michael Rothwell @ 12:15 AM

Doing a remote backup of a server across the internet over an encrypted channel is one of many things that are easy on Linux and the Mac with built-in tools, but either impossible or non-obvious on Windows with built-in tools. It's one line of shell code on Unix. I don't know how I'd do it on a standard Windows installation (any flavor), or if it's even possible.

It's accomplished using "tar over ssh" to dump a compressed backup of specified files and directories to a remote server:

tar jcvf - /target/directory | ssh user@remotehost "cat >backup.tar.bz2"

It says to tar: create a bzip2-compressed archive file of the specified items on standard output. That data is piped into an ssh command's standard input, which logs into a remote server (set up host keys to avoid the password prompt) and pipes the data into a remote command -- in this case, "cat", which redirects its output into a file named "backup.tar.bz2". Nice!

You can run it out of cron each day, even, and have nice named backup files by doing something like this:

tar jcvf - /target/directory | ssh user@remotehost "cat >backup-`date +%F`.bkp.tar.bz2"

That will produce files named "backup-2007-04-04.tar.bz2" and "backup-2007-04-05.tar.bz2", etc.

The reverse -- restoring a file from a remote backup -- is just as easy.

I <3 Unix!


Applications should never, *ever*, steal focus.

Tuesday, April 03, 2007posted by Michael Rothwell @ 10:38 PM

No software is ever more important than the user. It should not ever, for any reason, steal focus from the user. It's especially stupid and counter-productive to steal focus while the user is typing to put up a dialog box with buttons that can be activated by keys the user is pressing. Windows is especially bad about this. I've seen many flashes of dialog boxes, with no idea what they said because I happened to hit Enter or the Space Bar or whatever when the dialog box flashed up.

Apple Mail is occasionally misbehaved in this way. Sometimes it has trouble writing a message to the "drafts" folder on my IMAP server (*shakes fist at dovecot*), so it helpfully interrupts my typing (sometimes once every minute or so) to tell me this. You know what? I don't care! Not right now, anyway. I was typing a message! Please be quiet and let me do the thing I'm trying to do. Let me know about the error in some more unobtrusive way and I'll deal with it later.