The most likely stable state the climate is going to end up in, compared to the interglacial we're in right now, is back into full glaciation.

There's no stable "hotter" state known (no matter the historical CO2 levels, which have been much much higher than we're projecting to ever reach) to science. The only question during an interglacial is whether the poles will be free of ice or not - and looking at the latest interglacial, the Eemian, we shouldn't be surprised if the arctic circle becomes ice free (still without any catastrophic effects whatsoever).

What do we need to do to get back into full glaciation?

Nothing. Absolutely nothing. Although - changing the albedo as proposed in the article might well bring us there sooner rather than later.

Caveat: This post reflects the current state of science accurately. Watch out for replies that don't.

Ah, yes, and "Preview"... Teach them to "Preview" posts too...

The right way is to talk to your kids about these things. Give examples of scams, tell them there is porn, there is violence, and always, always if they feel unsure about something they should talk to you (Mostly for scams, I'm pretty sure they'll handle porn. Hell, even weird porn isn't as bad as seeing ISIS chop someones head off). Software protection is just a crutch, the real protection is education and vigilance.The right way is to talk to your kids about these things. Give examples of scams, tell them there is porn, there is violence, and always, always if they feel unsure about something they should talk to you (Mostly for scams, I'm pretty sure they'll handle porn. Hell, even weird porn isn't as bad as seeing ISIS chop someones head off). Software protection is just a crutch, the real protection is education and vigilance.

If you're talking about the Unix epoch, shouldn't it ve 1970? While I know the 0 of the Unix Epoch, I have no idea what weekday it was.

Thank you. I didn't have to think about this ever since college.

There are also a plethora of "technically correct" answers. You could say: "I scp the file to your server", where you presume the server is secure, and ssh is secure, so the documents confidentiality is guaranteed. (Upload the file using https works as an answer too). Hey, just connect to the companies VPN and copy the file to a Samba share. Valid too!
The question of what kind of file it was, isn't even that dumb. I'm not familiar with PDF, but I could -for example- imagine there is a standard for encryption within PDF. Someone from with a document management background would most likely think of such solutions.

It's a vast field, and expertise of people is usually just a subset. I'm not even sure what the answer you you expected was, but I'd say: I'd use your public key to encrypt the file to you and then send it to you. Personally, I wouldn't know which commands to invoke to do this, but I know that's the theory.

So, should any developer know this? That is debatable. I've had very competent developers who had next to no clue about how DNS works. They could do their job just fine with that. Me? Personally, I'm not up to snuff with the finer points of SQL queries and all the joins that exists and when it makes sense to create an index, etc. Could I find out? Most likely, but I haven't had the need to recently.

The problem is, that you are mapping your knowlegde to "what people must know". I used to do that too, and I probably still do often enough. The DNS example above didn't come from nowhere: I had the case, and I was really thinking "how could such a competent person not know this", but then this person could probably enlighten me about dozens of things I don't know well enough.

It all comes down to what you define as "general knowgledge" for a developer should be and that is highly subjective.

TL;DR Hiring people is hard. Especially, technical people.

I tried the following. On the affected machine, I created a DomU (Virtual Machine), assigned it 4CPUs, 4GB RAM and two disks. A root disk on which I installed a minimal debootstrapped wheezy, and an empty disk for the dd test. I made sure the VM boots from the affected kernel.

The bug doesn't happen in that context:

root@minimal:~# ssh root@othermachine "dd if=/dev/vg0/remote-lv" | dd of=/dev/xvdb1
root@hammerhead's password:
31457280+0 records in
31457280+0 records out
16106127360 bytes (16 GB) copied, 2156,62 s, 7,5 MB/s
31457280+0 records in
31457280+0 records out
16106127360 bytes (16 GB) copied, 2164.91 s, 7.4 MB/s
root@minimal:~# uname -a
Linux minimal 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux

Of course, the situation is not exactly the same in a virtualized environment.

The thing is, this is the host, not the VM. I haven't seen it happen in a VM yet. (In Xen lingo, it's the Dom0 causing this). However, you're right, I should try to reproduce it in a virtual environment. I'll try to do so.

The functionality is available in the Bitcoin protocol. Your complaint is apparently about BitPay. It's like blaming RFC 5246 for an incomplete TLS implementation by Microsoft.

I have had no issues using Bitcoin for payments and didn't know there had been any (all the scams I've seen are about people storing their private keys with someone else).

From ebay. They sound great, they cost nothing. At $3 each, they're disposable. So when my four year old runs off with a pair, or destroys the ear pieces, I don't feel bad about ordering another set. They're also good for use with my cell phone and skype. Gone are the days of studio headphones, or big, clunky usb headsets. At least for me.

That's your choice. I was just pointing out that contrary to your claim the Bitcoin protocol fully supports M-N transactions (which credit cards do not) and by using that functionality some really cool escrow solutions can be developed and deployed - without me having to trust a single merchant.