Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:Nope (Score 1) 331

by Sqr(twg) (#48791173) Attached to: Would You Rent Out Your Unused Drive Space?

I wouldn't call it "covered". What is says is: "If randomly distributed, the probability of the same redundant piece being hosted on the same controlled node is statistically quite small." It does not attempt to quantify what "quite small" means. So I'll try to do that.

Assume that you have a million blocks stored in the network. Each block is stored as three identical copies. Then assume that 1 % of the storage network is taken down at the same time. The probability that all copies of an individual block got lost is one in a million. However, the probability that at least one out of your one million blocks was lost is approximately 1-1/e or 63 %. So in this scenario, you are more likely than not to have lost data.

Comment: Re:Were they hacked? (Score 1) 114

by Sqr(twg) (#48752585) Attached to: Hackers Steal $5M In Bitcoin During Bitstamp Exchange Attack

The bitcoin transaction chain is public, so in theory it is possible to track stolen bitcoins. People could arbitrarily decide not to accept bitcoin from tainted sources (or not to accept bitcoin at all) and that would make life much harder for thieves and extortionists. However, the accepted practice is that all bitcoins are equal. There is no governing authority that has the power to declare that certain transactions are "tainted".

If a mechanism for declaring bitcoin "tainted" would be introduced today, it would not only affect the original thieves, but also a large number of innocent extortionists and drug dealers who just happened to run their bitcoin through the same "tumbler" as the thieves. The whole system would collapse. So it's not going to happen.

Comment: Re:Wrong optimization (Score 1) 105

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.

Comment: Re:Really? .. it comes with the job (Score 1) 772

by Sqr(twg) (#48562235) Attached to: CIA Lied Over Brutal Interrogations

Another problem is that the interrogation techniques were not originally designed to get information. They were originally developed to get captured soldiers to admit to false confessions.

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.

Comment: Re:Not a strong chain if the IP is the strongest l (Score 1) 84

by Sqr(twg) (#48539151) Attached to: US Treasury Dept: Banks Should Block Tor Nodes

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.)

Comment: Re:Shyeah, right. (Score 1) 284

by Sqr(twg) (#48472565) Attached to: Is LTO Tape On Its Way Out?

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.

Comment: Re:Tape Culture Fallacy (Score 1) 284

by Sqr(twg) (#48464995) Attached to: Is LTO Tape On Its Way Out?

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.)

Comment: Re:Shyeah, right. (Score 1) 284

by Sqr(twg) (#48464887) Attached to: Is LTO Tape On Its Way Out?

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.

"Pull the trigger and you're garbage." -- Lady Blue