One of the reasons I think we can go with our planned backup schedule is how I think that users will perceiveit. This matters because unless you're lucky enough to have a specificbackup schedule mandated from high, part of setting up your backupsystem is managing user expectations of what you can deliver and makingsure that they feel that it's reasonable.

(Let us take it as given that you cannot just ask the users what theywant and then deliver all of it. Users don't want

Part of the fun of backups is trying to work out how much backup storageyou need in order to do a decent job of recovering from mistakes. Unlessyou are lucky, you will not have a specific mandate about how much tosave for how long, which means that it is up to you to figure out ascheme that you can afford, that provides enough coverage, and thatpeople will be happy with; there are no one size fits all answers.

We didn't do anything sophisticated for our old

As if the first irritation wasn't enough,there's another problem with the Gnome settings stuff. It is this:modern Gnome applications keep all of their settings locked up insidegconf, even things that you enter and that in another, simpler erawould have been stuck in dotfiles somewhere.

This has a practical issue that I have been running into after learningabout convenient ssh in Gnome ; it's hard tomove settings for something from machine to machine. Consider themini-commander applet macros, which

At one level, the whole issue of program energy efficiency is nothing new; it is yet another round of theeternal conflict between the costs of development and the costs ofoperation. These have pretty much always been in conflict, in that youcould do more development work to lower the costs of running a program,but since development isn't free there is always a point where moredevelopment is not economically justifiable, where you can't lower yourcost of operation by more than you'd spend on development

Suppose that you want to extract all of the IP addresses used by your(OpenBSD) firewall's PF rules, so that you can (for example) validatethat all of the internal addresses mentioned still exist.

(For the purposes of this exercise we can ignore IP addresses in PFtables, because those are already easy to dump. Also, I am ignoring IPaddress ranges, netblocks, and so on; I am just interested in specificIP addresses.)

If you think that parsing PF's pf

I've been grumpy for quite a while about how Sun's Java RPM mutilatesyour system . Since I don't like my systems mangled,I've avoided installing Sun's Java on any of my systems unless Iabsolutely had to, and if I had to I tried to do it on an expendabletest system. This has been vaguely annoying, because even in Fedora 10there are things that don't work with the substitutes.

(One of them is the KVM over IP portion

Suppose that you're building some custom storage backend that issimply too big to be backed up, so you have only redundancy; thisis probably common if you're building a cloud-style environment or are otherwise dealing with a hugevolume of data. This leaves you with the redundancy history problem , where you're protected againsthardware failures but any mistakes are 'instantly' replicated to theredundant copies.

Suppose that you want to do better than this; you somehow want togive your redundant storage system

Despite what I wrote last entry , I think thatthere is an energy efficiency optimist's view and that it has a lot ofvalidity. It goes like this:

First, there are an increasing number of interesting devices on whichpower efficiency really does matter significantly, either because itsaves you money (such as compute clouds where you are charged veryprecisely for resource usage) or because it lets you run at all (laptopson battery power, low-power netbooks, cellphones, and so on).

Second

There's been somewhat of a movement of late to make programs be energyefficient (both for applications that might be running on laptops andfor applications that might run in a cloud computing environment withdetailed charging). This all sounds very good and worthwhile, and hardto argue against.

But it has a problem (the same problem as always, really). Ingeneral, such efficiency is not free since development time is notlimitless. Saying that applications should be optimized to be 'green' inthis way