Here is a simple yet unpleasant thing (one that I have circled aroundand implied before, but never stated outright):

Any time you propose a security system that uses a 'web of trust'model to validate anything, you've failed; the system is not secure inpractice. You can demonstrate all of the math that you want, but in theend it comes down to the users must pick the right people to trustin order for the system to be secure . And they will not. This

All of the explanations of metaclasses that I've read have startedout by talking about the whole background and theory of operation ofmetaclasses. This approach doesn't work for me; by the time they get outof the background, I'm either asleep or my eyes have glazed over. So I'mgoing to tackle metaclasses from the other end, covering what you can dowith them.

Part of the reason that metaclasses are complicated and confusing isthat they can be used to do a number of

There are two leading models for checking identity via public keycryptography. When someone demonstrates that they know the privatekey for a given public key, you can either check that you know thepublic key itself (the SSH model) or check that the public key isitself signed by an authority you approve of (the SSL CA model).In theory SSL can be used for either model; in practice, many SSLtools and APIs seem to be strongly convinced that you should usethe certificate authority model. The problem

In the spirit of my old entry on things that could happen to yourbackups and to reinforce yesterday's entryon not trying to archive things , there's an incompletelist of things that have been known to go wrong with archives. If you'rethinking of doing archives, you should be thinking about how you'regoing to avoid these.

• you aren't archiving everything you need to archive.
• the archive program doesn't work right; it writes a corrupt orincomplete archive, fails to

Once upon a time, not that long ago, when we were perhaps smaller andswitches were certainly more expensive, we put our switches in networkracks over on one side of the machine room, all of our servers in serverracks, and ran cables under our machine room's raised floor from theservers to the switches. Please learn from our painful experience anddon't do that; put almost all of your switches in server racks .

Yes, really. Even if this requires putting a stack of switches

Today, the following got asked on a university-wide mailing list forsysadmins:

I've had a request from a research lab about the availability of longterm (10 years) backups. The amount of data will be roughly 10 - 20Tby the end of that period growing at an estimated 1T/yr. [...]

(This isn't really backup, this is archiving .)

My view is the right answer is not to archive the data at all.

This one is creative, and best presented in point form.

• the nameservers for co. are ns1.cctld.co through ns6.cctld.co.
• if you query them for the NS records of hotmail.co, all of thempoint you to NS1.MSFT.NET., NS2.MSFT.NET., and NS5.MSFT.NET.

  (They do this slightly oddly, with the aa bit unset ,but nameservers for other important zones also do this so I assume

Yesterday I wrote about the obstacles thatfaced the Linux kernel in delivering true kernel-level asynchronous fileIO. In that entry I wrote:

Revising all of this [synchronous filesystem] code to workasynchronously is a lot of work and so didn't get done for a while.

Well. That's the real reason in a nutshell. To wit, writing callbackbased non-blocking code in conventional languages, especially in C,is hard and a pain in the rear. It takes what is simple straight

Although I believe that this may now have changed, Linux for a long timedidn't fully support asynchronous file read IO although it supportedsome sorts of other async IO. One reason for this is that doing genuinefully asynchronous file IO is a lot more complicated than it looks.

In theory you might think that this is an easy feature to add to afilesystem. After all, the kernel can already do asynchronous readsof a data block; it's just that the normal path for read() issues