One of the sessions of the university's yearly technical conference that I went to today was on two-factorauthentication using USB crypto tokens (augmented by software on theclient). In the talk, it came up that token-aware software can noticewhen the USB token is removed and do things like de-authenticate youor break a VPN connection. It struck me that this creates a perfectillustration of the tradeoff between security and usability, which Iwill frame through a question:

When the screen locker activates

One of the morals that you can draw from our near miss that I describedin yesterday's entry , where we might have lost alarge pool if things had gone a bit differently, is that the righttime to replace a disk with read errors is TODAY . Do not wait. Donot put it off because things are going okay and you see no ZFS-levelerrors after the dust settles. Replace it today because you never knowwhat is going to happen to another disk tomorrow.

Well, maybe.

I've said nasty things about ZFS before and I'll undoubtedly say some inthe future, but today, for various reasons, I want to take the positiveside and talk about how ZFS has saved us. While there are a number ofways that ZFS routinely saves us in the small, there's been one bignear miss that stands out.

Our fundamental environment is ZFS pools withvdevs of mirror pairs of disks. This setup costs space but, among otherthings, it's safe from

Back in this entry I bemoaned the fact thatPython's syntax for relative imports (' from . import fred ') is onlyvalid inside modules. The reason to have it valid outside modules isfairly straightforward; it would allow you to import and run the samePython code whether or not you were doing ' import module.thing ' fromoutside the module's directory or sitting inside the module's directorydoing ' import thing '. The way things are in Python today, once youstart using relative

In the middle of an excellent comment gently correcting my ignorance,a commentator on yesterday's entry wrote:

[RISCs requiring people to recompile programs] has some truth toit, but I would disagree that it was a big bet of RISC. Rather, itwas a function of the market niche that classic RISC was confinedto: Customers that paid tens or hundreds of thousands of dollars for ahigh-performance RISC machine would be willing to recompile their codeto eke out the best possible performance.

I have to

As I've written about before , in some quarters thereis a habit of saying that everything added to Unix needs to be 'Unixy'.One of the many problems with this is that a number of aspects of Unixitself are not 'Unixy'. I don't mean that in a theoretical way, wherewe debate about whether a particular API or approach is really 'Unixy'.I mean that in a concrete sense, in that Bell Labs, generally regardedas the home of Unix and the

At the time, performance oriented RISC was presentedas the obviously correct next step for systems to take. Even today Ican casually say that x86 won against RISC mostly because Intel spentmore money and have people nod along with it. But I'mnot sure that this is really the case, because I think you can make anargument that the whole idea behind (performance) RISC rested on somebig bets.

As I see them, the main big bets were:

1. CPU speeds would continue to be

Here's something that's potentially very important, as it was for metoday: if you're using an ordinary basic virtualization system (whereyou have guest OSes on top of a regular host OS), your virtual disksalmost certainly have the performance characteristics of 4K physicalsector size disks .

(In some situations they may have even bigger effective physical sectorsizes.)

This happens because in a standard basic virtualization system, theguest OS disks are just files in a host OS filesystem and that host

I know, I've been harping on xargs a bit lately. But this stuff isimportant because most people's vague intuitions about how xargs behaves is actually wrong.

If you're like most people, you probably vaguely think that xargs operates on lines of input and the purpose of the GNU -0 extension to xargs (and find et al) is so that some joker putting a newline in afile name doesn't cause the world to blow up. Actually it's much worsethan that