It is basically impossible to make a return trip to Mars because of the fuel requirements, which is why there has not been any manned missions, and will likely not be any in the near future. It takes a lot of fuel to deliver a very small amount of fuel to Mars. There'd have to be a long series of fuel delivery flights before a manned mission. For those, fuel efficiency is of course priority one.

As was the case here. The the Bush/Cheney administration knew that they wouldn't get any useful intelligence from torture, but they wanted "evidence" pointing towards Saddam, so that they could start another war.

I use Mint on my desktop, but write "Ubuntu" when I search on google. I think a lot of people do this.

You get more/better hits when you search for "Ubuntu" and the proposed solution will work on Mint 99.9 % of the time.

It's not meant to be the strongest link in the chain. Just a link in the chain. If, every time someone connects in a suspicious way, you call their cell-phone to verify, or ask for an extra one-time password, or at the very least send them an email, then you can detect/prevent a lot of fraud. (This applies not only to Tor, but to any type of "unusual" connection, for example connecting from Russia five minutes after using a credit card in the U.S.)

It was probably because of what this guy said.

You use long division for any of those things???

Rsync will happily detect and copy changes without propagating whole files, yes. But only on network transfers, and it requires reading the entire file on both ends. When backing up to a local (removable) hard drive, which is what we are discussing here, it is usually faster to copy the file once than to checksum it twice, so that is what rsync does by default.

I have compared the tools, and I do know what they do. I found a hundredfold improvement in the time to backup a set of virtual machines on a linux server after switching from rsync to ZFS.

If the file server uses a file system with checksums, and those checksums are also backed up, then it's a simple matter of reading through the tape and verifying the checksums. You don't need to compare to the original files.

(The probability of a corrupted backup server accidentally creating a correct checksum can be made arbitrarily small. Usually it's something like 2^-256.)

You might want to look at using ZFS instead of rsync. I switched a while back, and it was definitely worth the initial effort of changing the file system on the server.

With rsync you can get inconsistencies because not all files are backed up at the same instant. ZFS snapshots get around this.

If you modify a large file (say a 100 GB virtual machine), rsync will re-backup the entire file. ZFS will keep track of the part that changed and only copy that.

Also if a file on one of your multiple backups is subtly corrupt, you might not notice. Or even if you do compare the copies, you might not know which one is correct. With ZFS, the entire file system is checksummed and a raid or mirror can heal itself.

If you don't live in NYC or near another major metro/subway position, and you're too fucking stupid to call a cab instead of driving home drunk, then drinking becomes very dangerous.

FTFY.

In that case I'm sure you're doing something like this:

\newif\ifdraft
\drafttrue % or \draftfalse

\ifdraft
(should we cite the fine Gabor paper here?)
\fi

The paper in question was most likely not written in LaTeX, or they would have put a percent sign in front of the comment when they first put it in.

That will be an issue only for the OS and library developers. To the applications developer there will be no noticeable difference. It is already the case that you need to use specialized libraries to get maximum performance on common types of tasks.

For example, if you want to use an FFT on a modern "general purpose" processor, you will get much better performance using a standard library function than you would if you wrote your own. There are so may issues with memory access patterns, core and cache utilization, etc. that you will never have time to figure out if you just want to use the FFT (rather than do research on the algorithm itself.)

If a future CPU gets a built in FFT, then the standard library will be updated, and your application will just run faster. No modification necessary.

Keeping the press away is a matter of National Security. That's how it is in every police state.

I used to hang out in a swedish photography/videography forum. Bandwidth is cheap in Sweden, so a lot of these guys were on 100+ Mbit connections and liked to keep a backup in the cloud. Whenever a new "unlimited" storage service came around they'd hop on and upload tens of terabytes of photos/videos. (None of wich could be de-duplicated, since it was all original work.)

Inevitably, the storage service would update its TOS within a year, or go bankrupt.