To a large extent, we understand how to write bug-free programs andcode: you use and test the program until it doesn't crash or breakthings, produces the correct results, and doesn't do anything surprising(generate extra messages, pop up stray windows, and so on). There arevarious different ways to do this and people disagree about whichapproach is the most effective, but this is the broad view of how mostbug-free program development is done.

('bug-

Around here, our systems have layers of accreted history; scriptsthat are generating files that are used by, well, we're sometimes notentirely sure any more. Every so often we reach the point where we turnanother one of the file-generating scripts off (we take them out ofcrontabs, we remove invocations of them from other scripts and so on).

Having done this for a while now, I have a suggestion: when a data filebecomes obsolete and is no longer updated, you should

Here's an interesting and fun bug (in C) that I once ran across, yearsago. Suppose that you have a hash table, with entries chained off eachother in case of a hash collision, and a function to remove an elementfrom it that looks like this:

void remove(elem *mp){  elem *np;  np = table[HASH(mp)];  if (np == mp) {    table[HASH(mp)] = mp->next;    return

Suppose that you have several pools with a shared spare disk. One dayyou reboot your machine, and suddenly ' zpool status ' for most of yourpools starts reporting that your spare is faulted:

# zpool status tank  pool: tank[...]config:       NAME       STATE    READ WRITE CKSUM[...]       spares         cXtYdZ   FAULTED  corrupted data

Unless you are running a very recent version of OpenSolaris, you willprobably be unable to zpool remove these faulted spares. If thishappens to you, do not try re

Although ZFS commands like ' zpool status ' will generally not tell youthis, ZFS does not actually identify pool devices by their device name.Well, mostly it doesn't. The real situation is somewhat complex.

ZFS likes identifying pool-related objects with what it calls a 'GUID',a random and theoretically unique 64-bit identifier. Pools have GUIDs,vdevs have GUIDs, and, specifically, disks (in pool configurations) haveGUIDs. ZFS internally uses the GUID for most operations; for

One of the interesting things about modern servers is that they oftenhave the same sort of power-save support that desktops and laptops have,including the ability to be suspended in various ways. Usually this isharmless, but I am not convinced that it's a good idea in general. So,here's an amusing story to show why I feel that way.

We have some number of LTSP based X terminalsthat run regular X sessions on our collection of general login servers.This being the modern world

Here is a thesis that I have been mulling over lately:

One reason that security bugs are hard is that they aren't bugs. Inregular bugs, your code doesn't do things that you want it to. Insecurity bugs, the end result is that your code does extra things,things that let an attacker in. Ergo, security bugs are actuallyfeatures that you didn't intend your code to have.

(Often security bugs are created by low-level mistakes that are regularbugs.

Here's a sensible question about the lost+found directories thatvarious Unix filesystems stick in the top directory: why do they have toexist all the time? Yes, clearly fsck needs somewhere to put recoveredfiles, but in theory it could just create a lost+found directory whenneeded, and otherwise you wouldn't have it cluttering up the filesystem.

Part of the answer is that lost+found isn't just a normal emptydirectory; instead, it's usually substantially bigger, despite having

Like many Internet people of a certain generation, I don't like top-posting (and often have a semi-visceral reaction to it). For a long time Iavoided it almost entirely but these days I'm in an environment whereI'm reasonably exposed to it, and I've come to realize something aboutit.

Ultimately, the purpose of all quoting in email is to provide context,to remind people of the previous discussion if they don't remember itoff the top of