In the end, the problem is that people just want a "default tool". They don't want to think about their requirements for data consistency. The really scary bit is that while RDBMses are the "default tool" of yesterday and slacker DBs are the "default tool" of tomorrow, neither of them are really the "problem".

The "default tool" attitude IS the problem. Unless you carefully weigh your data consistency requirements, you shouldn't be making that call at all.

I welcome the slackers and all of their new options along the spectrum of speed versus consistency. It's just that most of the people developing applications scare the shit out of me. They're so cavalier (or should I say, "agile", or maybe "pragmatic") about requirements that it's truly disturbing.

That said, if you're really interested in all of the options, I also recommend checking out memcachedb, memcacheq, and redis.

Maybe it's a declarative language?

I don't know why, but "They dropped dolomite on it." made me think of http://www.imdb.com/title/tt0072895/

Actually, this isn't that much voodoo.

It's just saying that, if someone has a 1/10,000 chance of being wrong, their assurance that there is a 1/1,000,000,000 chance of something isn't that good of a bet. In other words, if you want the latter level of certainty, you don't really have it, because of the fallibility of the research itself.

This is actually rather obvious. If Jimbo tells you that there's a 1% chance that your tire will go flat if you don't fix it, that's not 1% if Jimbo is wrong 50% of the time. At best, it's 50.5%. Or something like that.

Assuming his brother Jethro is just as bad (but uncorrelated) with him, then their dual recommendation that it will go flat only gets you 25.25% certainty, not 1% (or 0.01%). The numbers may not be exactly right (my stats are rusty), but you get the point.

Basically, they're saying that the research provides a wider error bound than it may claim, assuming that scientists uniformly make logical mistakes--which they very probably do.

The implication, then, is that the LHC estimates should be independently done by other teams. This is, well, the basis of the scientific method, so essentially this study provides a statistical analysis of what we already know--after enough work, science gets results. Of course, the base theories assumed by all of the researchers could be wrong, which would be unfortunate, but the LHC is going to nail that one pretty quickly. :)

This is not surprising, but not voodoo either.

Free markets != no regulation. Unregulated markets generate monopolies. These are clearly bad.

For a market to function as free, it must be uncontrolled by any coercive forces. Monopolies control markets. Most big corporations try to do so today. It's appropriately called "Marketing", which doesn't just mean "advertising" as most people think.

Governments are pretty much the only response to that, short of riots. Democracy, being a civilized mob, is effectively that. Of course, the government can fail at keeping the market free, but it's hardly worse than the alternative.

At some point, you've got to draw a line that says "This is the limit of a player's coercive effect on a market". The government is the only place to do that. Unless you think the buyers should. Oh wait, we're (in theory) a democracy, same thing.

Do you live in a magical world where markets are free without government intervention? If you "criminalize" market manipulation and then get the government to "enforce the law", you just regulated the market.

Similarly, free market != 100% employment. Especially when the market trades in a currency. Monetary policy is a big deal. You can't avoid this without participating in civics. I'm sorry that you're civically lazy. Time to get back to work.

If you want our democracy to function, I'm fully willing to support you fixing that. If you want our market to function freely, I'll gladly support whatever regulations will achieve that. The problem is, in general, a lack of civic spirit. People don't want to work together to make the government functional. A lot of it is due to people with highly unrealistic ideologies. People that are not unlike you.

Ummm, Hobbes wasn't really predicting any sort of future. The entire "nasty, brutish, and short" thing is presupposed upon a continual condition of war. I don't think that Afghanistan, Iraq, or Palestine support any statement that war doesn't cause a man's life to be "solitary, poor, nasty, brutish, and short". He seemed to imply that humankind's natural state was war, which is debatable, but not entirely unsupported by average conditions for much of the world's populace.

That said, predictions are based on assumptions. We produce tons more food, and we're trashing our coastlines with the agricultural run-off. We're producing less food by fishing. Right now, it's a drop in the bucket. What percentage of the world's food is disappears when fishing is no longer viable?

Of course, we can change course for most things. We can fight run-off and protect fishing. The whole point of TFA was that we can't reverse dissolved carbon dioxide levels or ocean temperatures. Similarly, we can't immediately un-melt glaciers. We can't adapt ourselves out of basic facts of chemistry. We're working on relativistic physics, though.

Humankind's ability to adapt has dick to do with heat and carbon in the ocean. The only thing we need to do is hit a certain carbon-level. If you think getting the Chinese or Indians to curb industrializing will be as easy as getting people to switch from horses to cars, I truly fear for us all. I suppose we could bomb them, but I don't think that'll help.

The horse analogy is a good one. However, we can't innovate ourselves out of every problem. When we abandon this rock as unlivable, I'm sure someone will point to innovations in spaceflight. That's great. Of course, we could have just not flooded our coastlines, killed our oceans, and wiped out our forests.

It appears your argument is "we've always found a way before". Well, that's just as good of as the assumption that we'd all have been riding horses right now. Apparently not liking the result of a model somehow correlates it with failed models.

Meanwhile, the people who are going to try to innovate and prevent our way out of this mess will be paying attention to good research and data like this study, instead of trivializing it out of some sort of fearful reliance on manifest destiny.

This should freak you out. Maybe not a lot, but it should be of concern. There is absolutely no solid reason to say "it's probably not accurate". There is reason to say "let's be calm about this". In the meantime, let's just hope nature doesn't decide to take us down a peg.

Funding has to come from somewhere.

Some innovations don't happen without a ton of investment, and private individuals have limited capital. In the end, it usually happens funded by either a corporation, a university, or a government.

Make it patents sanely approved, nontransferrable, affordable to litigate, and have minimum royalties. Then, maybe individuals will sit on top of the innovation train. Until then, government funding may be the last, best hope for personal innovation.

Or are you waiting for Richie Rich and Bruce Wayne to privately innovate money-clip helicopters and batmobiles for us all?

I love it. Score: 5 (Flamebait).

Ironically, SPSS was cloned fairly early on in the OSS wars.

http://www.gnu.org/software/pspp/

I've found that making employees accountable for knowing their software is a huge benefit. Before a number of OSS shifts I've administered, nobody knew what was important. The entire workflow was undocumented. In some ways, tracking down this information is quite valuable in it's own right--and you'd never get it if you couldn't make people's jobs depend on it.

The key is to do it in responsible phases. Pick a representative set of really good people in your workflow. Make them into a "conversion team". Incentivize them to make the conversion process a success. Just doubling existing incentives works really well for sales people. They are notoriously hard to sell on OSS, but 2x-commission brings out the gambler in them. Most importantly--listen to them when they "can't do their work". If you've picked the right people, it'll be due to legitimate concerns.

Go department by department. Be tactical. Allow islands of resistance to form. If they can't be ignored, exploit existing divisions in the company to prevent them from uniting. When they're all that's left in a sea of OSS users, they're easier to deal with. Let their case be about real needs, not "everybody's doing it". Indeed, you don't even have to argue it, their arguments change on their own. It's a remarkably social phenomenon.

The legal department can be your friend. Most organizations are woefully out of compliance in licensing. If legal is made aware of this, they often just can't ignore it and will take it to the top. Ignoring it any any level can make people personally liable. The lawyers will tell them this.

Conversely, if you are in compliance, accounting is your friend. When software licenses are properly budgeted, they show up and they're ugly. It's also fairly easy to demonstrate that, once stabilized, OSS departments require less administrative labor than proprietary ones.

Most importantly, determine where there aren't OSS alternatives. In a big enough organization, you'll invariably have a few MS boxen just for interoperability or niche software. It's fine. That's what virtualization is for, and you can deal with that at your leisure. Rest assured that this is a dwindling list of software.

Be careful. Like any large IT shift, a bad roll-out can negate years of cost savings. No vendor, especially not the OSS community, should be blamed for your botched implementation.

In the end, the dream of an OSS organization is achievable. It can be worth the trouble. Rather you breathe Unix, sleep with a copy of the GPL, hate that your company is probably way out of license compliance, or just want that money in your bank instead of Redmond, there are plenty of reasons to do it.

Keep in mind that credit score represents how likely you are to be able to pay back debt.

People who have never had debt before are a bigger risk. Not incurring debt is wholly different that managing debt once you have it. How many people do you know who talk about how everything was okay until they got a credit card?

The fact is that some credit history shows some skill. Lack of credit history isn't causing a penalty for being a saver, it's just judicious use of good statistics.

Of course, if you look at it from a market incentive perspective, I suppose the bank is discouraging the people with the most money, but I wouldn't say that it's likely to affect payback likelihood, which is the bank's overriding concern.

In some ways, it already functions this way. There's just a lot of people waiting to be replaced with shell-scripts.

For debugging, New Relic provides some awesome tools that allow introspection of delay and timing at a function dispatch level. If you're serious about Rails, New Relic is for you.

As for file-backing your Rails app, my company has had huge success with GFS. It can be a beast to maintain sometimes, but it will crank out the IOPS behind very hungry RoR apps fairly well. It also requires shared block devices, though, so it may not be for you. The S3 plugins for Merb and Rails also go a long way to scaling everything but the code itself (which should be manageable on even the surliest NFS deployment).

We've done some really good work with Rails deployment. There are a ton of ways to deploy it, but I think that is more reflective of the variance in people's deployment requirements more than anything else. Phusion's Passenger and Engine Yard's deployment work are helping to lay down best practices here, and we'd be glad to talk to you about smoothing out the deployment process.

Rails is definitely a good application for teasing out some of the pathological behavior in NFS, but that's not necessarily a bad thing about Rails. It's already used by some to test the pathological niches in new Ruby releases (e.g. "Does it pass the Rails test?").

Working with Yehuda and Ezra on a daily basis, I can safely say that you can expect to see a lot of attention to performance and refactoring some of the cruft that has inevitably popped up in Rails' large codebase. DHH has a great vision and Yehuda has great attention to detail. I don't want to imply that "Rails needs Merb" or "Merb needs Rails", but I expect some really good results from the collaboration.