Using what encoding scheme? With a single mark the best I can think of is to treat it as a variable-length base 1 value; increment a Bignum for each atom until you hit the mark, and the final binary encoding of that is the data.

A 10TB LoC would make up a Bignum 87960930222080 bits long (and thus with a range of 0 - 2^87960930222080 - 1). Sadly with this encoding scheme the universe only contains enough atoms (~10^80) to encode about 32 bytes of that.

<?xml version="1.1" encoding="utf-8"?>
<random-data source="/dev/random">
  <quad>&#228;&#224;&#219;&#247;</quad>
  <quad>o&#8224;*&#8240;</quad>
  <quad>G&#8226;&#376;&#243;</quad>
  <quad>&#208;&#230;&#246;&#8230;</quad>
  <quad>&#179;&#191;&#217;G</quad>
  <quad>&#141;!s&#225;</quad>
</random-data>

For 4k of data:

-rw-r--r-- 1 freaky freaky 4096 2009-06-27 18:04 rand.dat
-rw-r--r-- 1 freaky freaky 30093 2009-06-27 18:04 rand.xml
-rw-r--r-- 1 freaky freaky 5618 2009-06-27 18:04 rand.xml.bz2
-rw-r--r-- 1 freaky freaky 7519 2009-06-27 18:04 rand.xml.gz

You missed the "encrypt it" step.

Print it, put it in a safety deposit box.

Shit. Someone tell all those people selling Amazon S3 based backup services.

Linux md RAID-1 (and a few other levels iirc) use a bitmap of changed blocks to reduce the IO required to resync a disk.

ZFS mirroring has similar behaviour, though I think they probably do something fancier with individual records rather than just a coarse bitmap of changes.

HAMMER mirroring certainly does; every write creates a new record ID and replicating systems, be they other disks or other machines entirely, can sync up their filesystem to whatever record they like, keeping around previous modifications depending on how they're configured. Yank a disk for 5 minutes, you get 5 minutes worth of writes for it to catch up on, not a resync of the entire disk.

Hibernate is only about 5 seconds faster than a normal boot here; X25-M, 12GB i7. Maybe it'll help more when you don't have a 9GB hiberfil.sys :)

You can have your cake and eat it in 7-STABLE with ZFS v13; it has functional L2ARC support.

Or go for both and use the SSD as cache.

Preferences -> Advanced -> Tabs -> Additional tab options. Check "Click on tab to minimise" and uncheck "Show close button on each tab".

Also, right click on tab bar, Customize -> Appearance, select "Wrap to multiple lines". Now you can see all your many tabs at once. You may also find it useful to have them down the left or right of the window.

If it Just Worked, we wouldn't need to keep an eye on UPDATING and jump through hoops when upgrading certain tricky things; e.g. perl-after-upgrade, the gnome upgrade scripts, knowing when you need to forcibly rebuild dependencies and when you can just upgrade a single package, and knowing what to do when you get it wrong and it starts doing weird things like try to install already installed packages.

Ports are a leaky abstraction; they don't try to deal with every possible situation automagically like some other packaging systems, and you do need to have some vague idea what you're doing to use them well. portupgrade and co are invaluable, but they're no apt; they can't be, because the ports system doesn't give them enough information to always do the right thing by themselves.

I have a 3008WFP, which replaced one of my 2 20" 1600*1200 displays. It hasn't made my secondary any less useful; it's just so nice being able to dedicate an entire monitor to terminals, far more so than faffing about trying to squeeze them next to other applications on my primary, no matter how big it might be.

Of course, in answer to this poll I answered "zero"; my main machine is a headless dual Opteron in a cupboard, exporting terminals to my desktop.

Message-ID's are controlled by the poster, you could embed content hashes in them quite easily; you'd just need to know any other parts of the field, which can either be fixed (content hashes should provide enough uniqueness), or detected by parsing a NZB with appropriately tagged segments. e.g:

Message-ID: <sha1-9c39cd34aa9f25e4e788479fb7c68dbd3118d7cb.256000+256000@bt.swarmable>

In a NZB, this is just another segment, and it could be posted exactly as existing posts are; a torrent client, wanting data with that SHA1 hash (and a probably unnecessary byte offset and length) could request that article without knowing anything else about it (other than maybe needing to know what group it's in for some NSP's; easily solved by crossposting to, say, alt.binaries.torrentable).

The main requirement would be that the torrent client and usenet post both use the same block size.

This has already been largely fixed in 7.1, with the kernel address space expanded to 6GB.

If you're still on 32bit, well, ZFS will hate you for that in Solaris too.

Both 7.1-STABLE and 7.2-PRERELEASE are in the same branch; stable/7 or RELENG_7.