I've kind of written about this before ,but real blog usability drives home why calendarwidgets in blogs are a waste of space for most purposes: as anavigational element, they are at best very weak hooks to get people toexplore the rest of your blog. There are two parts of this.

The first is that they give people very little or no information on whatthey'll get when they click on a link (or even when they look at it andthink about whether or not to click

For my sins I sometimes build programs from source that use standardautoconf-created configure scripts. The whole autoconf system has anumber of problems, which you can read people rant about at length,but my problem is that I almost invariably build things using variousdifferent non-default arguments. Which leads to what I call the'configure memory problem': when it comes time to rebuild the packagefor whatever reason, how do I remember which configure arguments Iused and recreate them? Especially, how do I have

Given my rxterm and sshterm scripts, I need some way to run them in order to do useful things. Theobvious thing to do is just to run them from the command line, butthis requires that you have a command line sitting around and in my disposable environment this isgenerally not the case.

tkrxterm and tkssh are two very simple TCL/TK programs that do essentially the same thing. They each throw up awindow with a label and a text entry field, let me enter text, and thenrun

Many moons ago, Jacob Nielsen wrote an entry about 'blog usability',which I reacted to at the time . But as Inoted back then, Nielsen's advice seemed aimed mostly at what I called'commercial' blogging, and ever since then I have had simmering in mymind the idea that it misses the true usability issues for typical blogs(then and now). Today I feel like letting things bubble over and finallywriting down my thoughts.

To start, let's ask two important questions

Relatively modern versions of the Linux kernel on some architecturesdefault to logging a kernel message about any process that receivesvarious unhandled signals. The exact details depend on the architecture,but I think it is common for the architectures to log messages aboutunhandled SIGSEGV s, ie segmentation faults.

(Most architectures are capable of logging these messages if the featureis turned on, but not all architectures turn it on by default. Itappears that x86 (both 32-bit and 64-bit) and SPARC

It's getting popular these days for RAID implementations to support whatI've heard called 'shared spares'; spare disks that are shared betweenmultiple RAID arrays, so that that they can be used by any array thathappens to need them. This is an attractive idea because it gives youbetter protection against moderate problems than you could get withdedicated spares. (If you have large problems you run out of spares, ofcourse.)

The problem with shared spares is that they are pretty muchintrinsically hard

I have been writing a bunch of Python code lately which involves turninglists of lists into plain lists. As it happens Python does not havea flatten() built-in, but people have come up with any number ofingenious ways to do this, some of which I actually like.

First, a stupid non-way that is worth writing down for posterity:

reduce(lambda x,y: x.extend(y), somelists, [])

This version is a classic mistake (one I

I was reminded today of one of the reasons that I am nottoo fond of Sun Support, by encountering this bug entry through a message in the ZFS mailing list.

This is a public OpenSolaris bug report. Except it is not; almost all ofthe text is an email message from me to Sun Support that was one partof our ongoing adventure with FAULTED ZFS spares .We have a commercial Sun support contract and we made our bug reportsvia it (and worked on Sun Support through it). We were

The more I look at the statistics logged by various systems andprograms, the more I've come to a conclusion: logging calculated statsas well as the raw stats is almost always a waste of time. Log analysisprograms can just as well change units, compute (nominal) averageper time interval, and so on, and in the mean time logging both justclutters up my logs (and sometimes subtracts clarity, often when it isnot obvious that it is a calculated stat instead of a real one)