This is incorrect for Reed-Solomon based RAID (levels 6 and higher such as RAID Z3). RAID6 can correct bit rot on a single disk and in general for t parity disks, floor(t/2) random errors per RS code can be corrected. All the RS-based RAID systems I've seen essentially store the RS code across devices using a GF(2^8) code, meaning that up to an entire byte could be corrupted by bit rot at a given logical address across all the stripes and still be corrected. All the details are on Wikipedia. Not all RAID-6+ implementations actually check the parity when reading, and I have no idea how many can solve the error locator polynomial for each RS code to actually identify and correct bit rot in multiple locations in different codes versus just dealing with known bulk errors (e.g. failed disks).

Any proper file system will have a large enough transaction/intent log that can be replayed to correct partial data/metadata writes due to power failure and the RAID write hole, etc.. Most file systems in use are not proper, of course, but at least a few are available.

The problem is double-spending. You have to check the whole blockchain to make sure an address hasn't already spent the coins it's trying to give you. I had thought of adding explicit back-references to the last block/transaction that an address is referenced in so that you only have to backtrack to specific blocks to find a trustworthy balance for an address, but it would be a major protocol change and old addresses from before the change would still need the full ~13GB of blockchain. You'd also have to trust the metadata a bit more; it's easy to check all transactions, but trusting that clients and miners have properly verified the back-references without being lazy is more dangerous.

And it's basically a no-brainer; set the prices in dollars or other local currency and do real-time conversion to bitcoin prices using the recent exchange history. It's almost certainly going to be converted to another currency at that exchange fairly quickly anyway. Bitcoin will be a payment method and not a stable currency for, in my guess, quite a long time to come. If not because of the speculation but because of its tiny market cap compared to global markets. As such, bitcoin will never become useless until its market cap is smaller than the smallest purchase one might want to make, or if all the exchanges die. In fact, the lack of exchanges would tend to stabilize the currency value so it could still be used to send a few dollars worth of value across the Internet.

Financial markets like MtGox could easily maintain fractional reserves because many account-holders don't withdraw their entire balance of bitcoins every night. There is plenty of opportunity for the exchange to do whatever they want with a portion of the deposits. In essence "mtgox bitcoins" are already a fiat currency that are payable in real bitcoins upon request. They just haven't started paying out at less than 1 bitcoin per mtgox bitcoin yet, like half of the other bitcoin exchanges/banks/whatever have when they got hacked.

Of course the certificate expired in April, but it's the thought that counts.

To give the rods a heave out of the tube perhaps? I'm not sure how many of you have personally de-orbited anything from LEO, but you can't just "drop" things on the Earth from up there.

That's obvious. If you are restricted from possessing a small, machined piece of steel then you are not very free. Guns are inert without ammunition and yet it is the rare government that actually makes this critical distinction. Possessing harmful or dangerous chemicals is the real problem; more specifically possessing dangerous potential energy is what society unfortunately has need to regulate because of people's harmful intentions and simple incompetence. Unfortunately for gun-control advocates, addressing the real danger would logically require giving up gasoline, natural gas, and other volatile fuels, or implementing heavy-handed restrictions such as only allowing trained, licensed professionals to dispense gasoline into vehicles with fines or jail time for the irresponsible nuts who dared to open the gas cap or do mechanic work on the fuel system without authorization.

And, of course, the typical response is "Oh, but gasoline is NECESSARY! It's USEFUL!" but it ultimately kills far, far more people when it's mixed with self-driven vehicles than ammunition fired from a gun. So which is it; do you advocate the freedom to drive yourself around instead of being forced to walk or use mass transit or do you advocate serfdom so that you can feel safe from guns that have less of a chance of killing you than your car does? For that matter, statistically twinkies and big macs will kill you with a much higher success rate than guns. Banning personal vehicles or unhealthy food or dangerous sports or mountain climbing (have you seen the death rate for climbing Mt. Everest?) would only require people to give up portions of their lifestyle which is no more than gun-control advocates ask of gun/ammunition owners. Wouldn't it be better to give up just some of your personal freedom for just a little more safety and security?

Points taken; I spend a lot of time in the man pages and other references. I think the part I misinterpreted was the "I couldn't write a quicksort to save my life", which if taken literally means an inability to write simple programs. What I think you meant was "I couldn't write a quicksort in a few minutes without spending some time looking up reference material." I think anyone who has studied computer science should be able to come up with quicksort given enough time and motivation (and pencil and paper, at least). The concepts of divide and conquer and in-place array operations are just too basic to programming for something like quicksort to not eventually be developed by a competent programmer.

That is kind of sad. Could you describe how quicksort works, at least? Does divide and conquer ring a bell? How about a pivot element? I'm not going to require you to do it in-place or anything. If you've forgotten how to program I'm not sure what to say, except that you have my condolences.

The first time they pick up some megablocks or other imitations, they get a pretty good idea.

Comparative (not competitive) advantages are disappearing. When walmart (or, more likely, amazon/google/some-other-tech-company) can plop a robotic liquor store in your neighborhood the microbreweries and corner stores are (nearly) history. They become a luxury item instead of a commodity, and while luxury beer will always have a market it's a much smaller market than the general liquor market. Eventually, robotically microbrewed local beer will have the comparative advantage if it's marketed as Luxury Robot Beer (Hand-Programmed Limited Edition).

TFA is about the shrinking number of comparative advantages that human labor has. You're not competing against Walmart, you're competing against automation that won't leave you with any comparative advantages in the end. Become a pure capitalist because labor won't pay. Buy/build robots.

Not only that, but consumers are free to not buy products at prices that ultimately lead to their own lowered wages.

Uh oh, I see the problem. There is no perfect economic information and so large hierarchical entities can collude to manipulate market prices and wages because of their ability to solve the coordination problem for the actions of their independent agents more efficiently than free individuals who have trouble just avoiding the tragedy of the commons, not to mention the problems of self-governance.

Corporations are more efficient processes for accumulating wealth. The problem is that corporations have no intrinsic terminal value for individuals, and so a society of individuals must constantly enforce its own terminal values at the expense of corporate values.

And there's a new article for preventing that attack. In short: compile your candidate compiler with two other compilers (call them A and B), and then compile the candidate compiler with C and D, producing E and F. Compare E and F; if they're identical it's highly unlikely you suffer from a compromised compiler; if you did then either A or B would generate a compromised compiler (C or D), but it's highly unlikely that A and B would be compromised in exactly the same way, leading to identical binaries for E and F. There's some practical work in making A and B and C and D produce deterministic output, but the author of the paper that I am too lazy to look up did it.

Pics or it didn't happen.

Seriously, stick that video on youtube and get yourself a nice civil lawsuit going when it goes viral.

It sounds like reality. Do you really think that every month or two when Adobe or Oracle patches a remote exploit that's in 90% of computers it's a bug introduced within the last patch cycle? Of course not. Software is riddled with bugs and they're found incrementally. If you can find bugs faster than the public researchers you will have a database of zero-days, end of story.