Per the European Edgar DB, Figure 2.4, American per capita in 2012, was 16.4. In Germany, it was just under 10. That is a factor of 1.5, and no where NEAR 3x.

in 2012, China's per capita was at ~7.2, while Europe's was at ~7.3. That was two years ago.
Since that time, Chinas CO2 emissions have risen more than 20%. China now accounts for more than 1/3 of the global emissions, with less than 1/6 of the world population.
And all of that is based on numbers that Chinese gov. has given up. OCO2 is about to shock the world and liars like yourself.

Per edgar, EU27 was at 4.12 in 1992. In 2012, you were at 3.74. That is a 10% drop.
Now, in the same time span, we increased heavily due to W (from 5->5.91), and then due to our cheap nat gas, we dropped BELOW 5, though, edgar shows America at 5.19 in 2012. However, other groups show that 2013 was a major drop for America, pretty much a fixed level for Europe (esp. due to Germany's killing of their nukes and their massive build-out of coal plants), and a REAL MASSIVE increase for China's emissions.

Several things wrong with that BS.
1) China has NEVER been transparent with their budget.
2) much of what is considered military in America and the west, goes under civilian budget, but military control, in china.
3) China is not a TRUE capitalism. As such, all those that work on the military side, are paid a fraction of what they are paid elsewhere. As such, building an AK-47 in China is a REAL fraction of what it would costs to build in America.

Far more important, is the speed with which China is growing their military, combined with the large number of military secrets that China has stolen from the west (esp. America).

btrfs sounds very interesting. It was not ready for prime time when I setup my current box, which is why I chose zfs instead. I'll have to try to murder it in a VM :)

Can you set btrfs to use arbitrary block devices or files? One of the things that made it easy to screw with zfs was it's ability to do so. I was able to set up a VM and do random writes to the "drives" it was using to see how it would respond. Anyway, to my surprise btrfs seems production-ready at this time so I'll have to play with it.

I teach physics. The most depressing part of my job is teaching a general-education class where I have to explain global warming.

Scientists don't have a private agenda. We would LOVE to be wrong about this, but:
- Temperatures are going up worldwide
- Global temperatures are historically very well correlated to CO2 concentrations
- CO2 concentrations have a straightforward and well-understood effect on infrared light produced by
earth's blackbody radiation
- Even small changes to global temperature will create big changes to local climates
- We can stop this, but only if radical action is taken right now
so
- We're all fucked.

This is not the time for the debate about whether the effect is real. This is the time for debate about just how MUCH we should be panicking. We're in the deep shit here. We're talking about large proportions of humanity not having enough food to eat. The resulting warfare and hardship will be devastating.

Yes, you can do this with zfs as well, but you need to be very, very careful or you won't have the redundancy that you think you do. There are crazy partition schemes that can let you do Drobo-ish things - but they get so complicated that you need to keep track of them in something like an Excel spreadsheet. :)

Besides, zfs seems to like having the entire drive.

I'd love for you to be right, but you haven't added any information to the discussion so it is hard to believe you.

and yet, Germany is the large per capita CO2 emitter in Europe at 9.7. In addition, with more coal plants coming on-line, again, Germany will jump up again.

No, because the corruption will be caught. I - and many others - have had controller failures and bad hard drives cause corruption on the drives, but this corruption was caught during the scrub. If the data is bad in-memory and then hashed and written to disk in that condition, the corruption will be silent.

ECC RAM will only correct 1 bad bit, but the system is supposed to halt on 2 bad bits. A halt is better than operating in an unknown state, IMHO.

Even if you aren't worried about the specific scenario where the whole pool goes down, taking all the trouble to run a filesystem with parity seems silly if you can't trust the error detection/correction to actually work. And since you are writing a hash as well as a file, you are doubling the opportunities to corrupt any particular file vs a regular file system.

I'd suggest some further reading.

Not something I would attempt. Personally, I accept this limitation and always add drives in pairs. Upgrading capacity then becomes a 2-drive cost instead of a number_of_disks_in_raid cost.

It's not THAT bad. You do this:
1. Put new disk in usb cradle.
2. Run 'zpool replace', swapping new disk for old disk.
3. Take the new disk and physically replace the old disk.
4. Repeat 1-3 for each new disk until you have the whole array running at the new capacity.
5. If autoexpand is not enabled, run the 'zfs online' command with the '-e' flag to use the new capacity.

I've only used FreeBSD, not Linux - but I presume this would work so long as you are giving ZFS the whole disk. ZFS does not care which interface disks are attached to... you can take them all out and shuffle them around and it will map them correctly.

I think the majority of the scientific publishing culture and industry is bad for science. That said, this is not a fair criticism. It's entirely reasonable to tell someone you expect to see more data in order to publish and to start a conversation among the editor, reviewers and PI as to what is necessary to prove a point. Research is not a perfect process and does not progress in an orderly, predictable manner. There are going to be typos and blind spots in any paper.

In this case, obviously Nature should not have published in the end. We can't know how that decision was reached unless we see all the correspondence between the editor, reviewers and PI. It would be much more useful to the scientific community to see how the PI managed to convince the reviewers to allow publication, rather than to debate what is really a standard rejection response.

I've been a member of the Church of Parity ever since I discovered that some of my dutifully backed-up family photos had not only gotten corrupted, but the backup dutifully copied the corruption as well. Ever since, I use backup tools which do a parity check (e.g. Unison) and I try to store important things on ZFS if I can.

In my case I was lucky and I had an older backup without the corruption. But lesson learned... Also, have more than one backup :)

Yes, ZFS is not a Drobo. You need to plan out your disk usage from the beginning, because you are kind of stuck with it.

For instance, if you have 5 disks and they are all the same size and you want 2 disk redundancy, it is almost a no-brainer to setup a raidz2. The downside is that if you ever want to make the vdev larger by replacing disks, you need to replace all 5 disks to the new larger size... a vdev is limited by the smallest disk. You can mitigate this by putting the same 5 disks into a pair of mirrors plus a hot spare. You will lose some initial capacity, but then later on you can add capacity by swapping out just two disks or by adding another pair to the pool.

And once you've added a vdev to the pool, you can never remove it... that's probably the biggest irritation for me personally. Even that isn't such a big deal, since it is so easy to clone the whole pool to another one.

If you decide to chance it, make sure you don't use the "scrub" functionality on ZFS. Scrub can cause memory errors to eat your pool like a cancer.

Or, just use ECC :)