These excerpts from one of Brewer's talks seem to substantiate my "misunderstanding": Eric Brewer on Why Banks are BASE Not ACID - Availability Is Revenue

segedunum:

When the system is functioning normally, the difference between strong consistency and eventual consistency is on the order of a few milliseconds. I don't think that leaves much of a window for abuse. The fundamental question is what do you do when there is partitioning? Or as you call it, system degradation. If you take an ACID approach then you shut down everything until the partitioning has been repaired. If you take a BASE approach then you still provide at least some functionality by sacrificing strong consistency. The CAP theorem says you cannot have both strong consistency and availability when there is partitioning.

The fact that you have any functionality at all when there is non-trivial degradation is due to using an overall BASE strategy instead of an ACID strategy. I have no doubt that one or more ACID databases are used as parts of the system but an overall BASE strategy is used by banks when there is partitioning (system degradation).

Remember, this thread started with an AC claiming that you would have to be an idiot to use anything other than ACID for storing data. People responded by saying there is also a place for BASE systems and that the banking industry uses an overall BASE strategy. Perhaps I misunderstand what you are saying but it seems like you are saying that as long as an ACID database is part of the system (or a central part of the system) then the overall system must be ACID which makes little sense to me.

I don't think anyone here is suggesting:

The point I've been trying to make is that just like there is a place for ACID systems there is also a place for BASE systems. In addition, as the data sets become larger and more complex and more spread out, the ACID approach becomes more and more untenable due to the CAP theorem. For most (but not all) cases, high-availability and eventual consistency will trump strong consistency.

There clearly seems to be a failure of communication here. Since you did not like my dumbed down explanation, perhaps you would prefer to hear what Eric Brewer has to say. He seems to have gotten a whole lot of awards for someone who is a "NoSQL nutter".

Eric Brewer on Why Banks are BASE Not ACID - Availability Is Revenue:

There are more details here and in many other places.

Are you saying you think the CAP theorem is false? I'm assuming large distributed data sets so partitioning is inevitable. According to CAP this means there is a trade off between consistency and availability. RDBMS provide strong consistency so they cannot also provide high availability when there is partitioning.

Sarcastic ad hominem attacks are an extremely poor substitute for reasoned debate.

I think you missed the underlying reason. This is just another facet of the elaborate internationally coordinated "global warming" hoax. Once they convince you the ice caps are melting then it is a slippery slope down to allowing Fluoride in our drinking water or believing men landed on the moon or even believing the Earth is round.

Perhaps this is where you have gone astray. The opposite of ACID is BASE where the "E" stands for eventual consistency. The beauty of this is that it DOES NOT lose completed transactions and at the same time it allows for high availability.

Strict consistency (the "C" in ACID) is a much more stringent requirement than eventual consistency. In particular it conflicts with high availability. This is the essence of the CAP theorem. In many industries, including banking, eventual consistency plus high availability (NoSQL) is preferable to strict consistency plus lower availability (RDBMS). Of course there are many other factors involved in selecting a database architecture.

One way to see this is by noting the three typical things you can do at an ATM: deposit, withdrawal, and show balance, commute (in a sense) when you are only worried about eventual consistency but they don't commute when you require strict consistency. This is why relaxing the requirement to eventual consistency gives you higher availability (when the database is partitioned). Transactions can be logged and later merged when the partition has healed. It is true that "show balance" does not strictly commute with deposits and withdrawals but: a) this does not cause the system to lose track of your money, and b) no one expects it to strictly commute. There is usually a warning that it may take X hours or days before a transaction shows up on your balance. IOW the balance will eventually be correct after you stop making transactions.

The strict consistency alternative you think is better will mean that all ATMs have to stop working whenever the database is partitioned. For most customers this is totally unacceptable especially since the only value it adds is ensuring that the "show balance" function always includes all of the latest transactions. Even the average person on the street would tell you this approach is really "stupid". No one wants the ATMs to be broken most of the time just to be sure "show balance" is always perfectly up to date.

"From the article: "Fiction author Michael Crichton probably started the backlash against the idea of consensus in science. Crichton was rather notable for doubting the conclusions of climate scientists—he wrote an entire book in which they were the villains—so it's fair to say he wasn't thrilled when the field reached a consensus."

It's almost like TFA doesn't know that at best, consensus ~= truth but they're often just nothing to do with each other. Jury is still out on whether Crichton was right, certainly no warming in sixteen years doesn't help the other side.

Also: "97%+ of geologists agreed the continents were stable. It was Settled Science. Hundreds of research papers supported it. Overwhelming consensus. And wrong. And, oddly (not really, if you think about it a moment), it was not a geologist but a meteorologist, Alfred Wegener, who ultimately showed all the mutually agreeing geologists they had it all wrong; the continents move." - Dr. Michael K. Oliver

I also suggest you read CAP Twelve Years Later: How the "Rules" Have Changed by Eric Brewer. He concludes with:

You can claim Eric Brewer is a fucking idiot as much as you want. Eventually all you will do is destroy your own credibility.

They are using Riak which is currently being used by 25% of the Fortune 50 (fifty, not five-hundred).

The CAP theorem states there is a trade off between: Consistency, Availability, and Partitioning tolerance. Riak sacrifices consistency (although it does have eventual consistency) in favor of availability and partitioning. The people who wrote Riak (in Erlang) actually seem to be very smart. They say they are firmly in the "right-technology-for-the-right-job" camp. They are not crusading to replace all RDBMS with NoSQL.

The availability and partitioning tolerance of Riak are amazing. For certain applications these strengths greatly outweigh sacrifices in atomicity and consistency. Due to the CAP theorem, there is no one single database architecture that will be optimal for all applications. Granted, a completely different mindset is needed to use Riak if your previous database experience is all RDBMS.

From a cursory look, Riak seems to have some excellent documentation. I suggest you look at their page that explains the trade offs between using Riak and a traditional RDBMS. It also contains links to similar documentation.

I remember a site like this about 5 years ago. Seems the owner was arrested and the site taken down for "interfering with an ongoing investigation" and "Aiding and abiding the commission of a Class A Felony"

Seems one of the undercover cops who's information was posted was shot and killed. They linked it back to the site and charged the owner.

Though I agree with the idea and agree that making it public is a great idea, just know that they will do anything they can to keep there actions hidden from the public.

RMS seat space

Say you've been told you have Ebola but have read this. What do you do?

http://jid.oxfordjournals.org/...

Say, "oh, it sounds too risky, I'll tough it out"? I'm guessing not.

Any chance this is astroturfing for the company with the Ebola drug? The natural antibodies are a fierce competition to what is now a multi billion dollar market.

People live with HIV. Ebola, not so much.

In 1933 the only psychiatrist to ever win a Nobel prize did so for discovering Malaria cures syphilitic dementia. Malaria is no joy but it's better than your brains turning to soup (three years later antibiotics were discovered).

You might die of HIV. You will almost certainly die of Ebola.

Correction: Bukkit contains decompiled, deobfuscated Minecraft server code. This code is already being made available. Why on earth would Mojang have to also make their original source code available? At worst, Mojang will have to LGPL the decompiled code they are already distributing as if it were LGPLed.

If I GPL a crippled version of my source code with all the comments stripped out, I am not obligated to give you the commented version for free.

This may be the most nonsensical thing posted thus far. If company A is distributing my GPL or LGPL code then I don't have to sign a damned thing in order for company B to buy company A. Yes, company B should make sure there are no license violations going on in company A, but that is all. Once my code released under the GPL then I cannot revoke that license in order to try to screw company B.

If this unfounded claim were correct then the takedown notice would be valid and the Minecraft owners would be complete and utter morons. Why on earth would they go to the trouble of replacing the decompiled code with their original source code? It makes no sense. It adds no value and it means they are now only distributing CraftBukkit in binary form which would be an obvious copyright violation of the LGPL code in CraftBukkit.

What is actually going on is the Minecraft owners are distributing source and binaries of CraftBukkit which includes decompiled code of their original Minecraft server as well as LGPLed code. At most, Minecraft would have to LGPL this decompiled code that they are distributing but since they are already acting like this decompiled code is LGPLed I see no problem here.

Decomplied != reverse engineered

Anyone can decompile. It takes work to reverse engineer. If decompiling removes all copyright obligations then copyright on source code is worthless. I just compile then decompile and distribute.