Just because you don't have a Facebook profile doesn't mean that people can't upload compromising pictures of you to Facebook. Furthermore, you can still be tagged by name in photos even if there's no profile to link to.

To the Canadians out there, if this gets big, do you think he'll be able to collect on the Blank Media Levy?

As it stands, every blank CD-R sold is subject to a 21-cent levy (77 cents if it's an Audio CD-R). The question is, which part of the retail chain gets to take the hit on the levy? Retailer, Distributor, Label, Artist, or Consumer? Who will get to see those 77 cents at the end of the day?

This might be a neat way for those starving artists to finally start collecting payment for their work -- selling blanks for fun and profit.

We've been joking about it for years, but we finally have an answer for the ages-old question of "why would I need an IP address for my fridge?"

Now, we just need some compelling reasons for networked sinks, sponges, cutlery, and microwaves. Not Talking Toasters though. They'd keep us on IPv4 for another decade.

There aren't any strict rules saying that people have to pull straight from your laptop.

In terms of non-distributed VCSes, would you ever host a your repository on a machine that other people couldn't access? It would always be somewhere publicly accessible.

For this kind of situation, you'd probably have a public development repo that's separate from your official repository. This would give you a set of repositories that looks like:

official - The authoritative repository, controlled by some kind of integration manager

jim-dev-public - Code that Jim is ready to unleash upon the world, but not upon the official repository
jim-dev-private - Code that Jim is currently working on from his blimp with irregular Internet access

fred-dev-public, alice-dev-public, bob-dev-public - These are the only ones that you need to pull from. Fred, Alice, and Bob can have as many private repositories as they'd like, and will share their work when it's ready.

Why wait for a new project? Git and Mercurial both support some bidirectional SVN integration. This means that you can pull changes from the SVN repo, and do your own DCVS thing, then push your commits back to SVN. Your project partner can keep using the SVN repository, and generally doesn't even know that you're trying something new on your end.

Assuming that you're using the conventional SVN project structure, all you need to do is a quick git svn clone --stdlayout file:///path/to/your/repository and you'll be up and running. You can make your changes, commiting to your local git repository, then just git svn dcommit to push your changes back up to SVN. If it bothers you about uncommitted changes just wrap it up in a git stash; git svn dcommit; git stash pop to store your working copy (eg, your project file, temp files, partially edited config file containing passwords and whatnot) commit and then restore all your extra files. To pull changes from SVN, you just need to git svn rebase to apply your changes to the current head.

Do note that branches and tags aren't propagated back up to SVN if they're created in Git, but that's not such a big deal. You can still merge stuff down into master and push it up to the SVN repo. (There might be a way to get it to work with branches, but I haven't looked at it)

Go give it a try on a private repository. There's plenty of documentation out there (for once), so it's easy to get started. Just beware -- you might like the new workflow.