Bootable backup

This isn't a big deal to me because I RAID everything; that's the appropriate use of RAID (it's not a backup; it provides stability). The appropriate use of backups is to preserve data, not provide stability. However, I understand that not everyone can afford to spend 3x the disk (1 for the original, 1 for the mirror, 1 for the disk), even taking advantage of cheap offsite backup services like Amazon S3, so I think your idea makes sense for those folks. Easy enough to add as an additional feature.

Sub-file increments

Agreed. Venti/fossil did these aeons ago and we can now. There's really no good reason not to, especially with offsite backups (saves transfer bandwidth and update costs). Merkle hash trees aren't rocket science!

Consistency

This is not a simple problem in any environment--this isn't just limited to Linux. A naive implementation might preserve a snapshot of a file when it's opened, and then delete it when it's closed. For databases and other systems, this could conceivably consume far too much space. A more intelligent implementation might improve on this, albeit at the cost of complexity and concomitant bugs. I don't know much about btrfs's solution. I don't think this is necessary for the home user, and the systems user is knowledgeable enough to know how to take snapshot or quiesce, or whatever, when needed.

Ease of use

That's probably easy enough to do with a special partition type (so it can be recognised as a backup on other systems; this also permits use of an efficient backup-oriented format rather than forcing backups to live atop ext* or whatever). On first insert, record the unique ID of the drive; if it's to be used for backup reformat. I would be concerned about foolish users just clicking through any number of dialogues and accidentally destroying their pre-existing data on the drive though--this happens a lot.

So...why don't you write it? I'm sure the world would love it! Compared to a lot of other software, it's really not all that complex. Just remember to encrypt the backups...

I have glumly come to the conclusion that if I want something equivalent to or better than MacOS's Time Machine on Linux for doing time-based incremental backups, I'm going to have to write it myself, and it's going to have to rely on LVM's snapshotting mechanism to do a consistent backup until BTRFS is ready.

You might take a look at using rsync for incremental backups. I've been doing this and it works great.

Essentially, getting caught leaving cookies otherwise should be evidence of the attempt, and bill them.

So you want to enter your username and password every time you reload a page, every time you post a comment &c.? Or you're cool with URLs which look like 'http://www.example.com/page?sessid=37a1-fb6c-9372-11de' instead or 'http://foo:bar@www.example.com/page' instead of 'http://www.example.com/page'?

Do you even know what cookies are, what they do or why they were added in the first place?

(defclass a () ((b :accessor b :initform 1 :type (integer 0 100))))

Although it's up to your implementation whether or not to enforce the type declaration.

Of course, what would be darkly ironic would be a screw-with-crackers script with a security vulnerability...

You are sounding rather limited in your own grasp of world history - many enlightened countries of the modern world prohibit weapons, and none of of them have totalitarian governments.

That's both a paetitio principi and a non sequitur. It begs the question because it assumes that weapons bans are enlightened (and hence not totalitarian; it doesn't follow because by banning weapons those countries are by definition totalitarian.