I recently read Daniel Ehrenberg's Why not mmap? and ranacross the following snippet:

mmap() is a system call, implemented by the kernel. Why? As far as Ican tell, what I described above could be implemented in user-space:user-space has page fault handlers and file read/write operations.

One way to put the reason that the kernel handles mmap() isthat there is a good argument that the reason mmap() exists isshared libraries. And shared is

The usual description of VCS bisection is that it performs a binarysearch to determine the changeset that introduced a bug. Unfortunately,there is a fundamental limitation with this model of bisection; it onlyworks well when the bug was only introduced once. Otherwise you will getresults that are technically correct but not really useful.

Suppose what actually happened was that the bug was unknowinglyintroduced, accidentally fixed, and then later reintroduced. Doing abisection will 'work' in that it will give you a changeset where thebug appeared

One of those 'vigorous debates' in version control is whether youshould make frequent use of rebasing changes in order to present aclean version history or whether you should preserve the original,real development history of changes, warts and merges and all. As ithappens I am a somewhat involved bystander in this, so I have a grumpysysadmin's answer: if you are an open source project of moderate size orlarger, you should absolutely rebase patches. In fact it would be goodif you went further than

As I've written before , I don't think we're goingto see any great use of 10G Ethernet in our immediate future; it's stilltoo expensive to see it routinely start showing up on machines. But I'verecently been thinking about what we could feasibly use 10G Ethernet forin the relatively near future, if (for example) we got money to buy amodest amount of 10G gear.

(I think that this is an interesting question in

In an earlier entry I gave a nice simpledescription of how our network looks atthe logical level of subnets and so on. Today, it's time for a look athow it's actually implemented with switches and so on. As before, thispicture is somewhat simplified.

The core of our physical network is a string of core switches. It's astring because each switch has only two 10G ports, so we have to chainthem together in order to get all of them connected

I recently wrote up our network layout andmentioned that while most of our private 'sandbox' networks are routedinternally, we had a few that are unrouted for various reasons. This isthe story of the most interesting unrouted one.

We have a number of firewalls. Because we are cautious people andthese are very important systems, we have hot spares. Now, there areat least two ways to handle hot spare firewalls; you can have themphysically plugged into the production networks but with their networkinterfaces not configured

Yesterday I mentioned in passing that we had acolour scheme for network cables, at least in our machine room and somewiring closets. To illustrate our environment, here's the cable colourswe currently use:

Today, I feel like talking about how our networks are organized at the logical level of subnets and routing andinterconnections (instead of the physical level of switches and soon; that's another entry). This will be simplified somewhat becausegoing into full detail would make it feel too much like work.

We have a single connection to the campus backbone; these days it uses atouchdown network that connects to our core router (although it didn'tused to, which caused some issues ). Hangingoff

Current versions of Solaris have a ' -F ' option for zpool import and zpool clear , which is documented like this:

Initiates recovery mode for an unopenable pool. Attempts to discardthe last few transactions in the pool to return it to an openablestate. Not all damaged pools can be recovered by using this option. Ifsuccessful, the data from the discarded transactions is irretrievablylost.

The current Oracle documentation hasa somewhat more detailed explanation, which mentions that this isspecifically (only) for recovering from damaged pool