The person/entity you are doing the transaction with will get the right data. It is random people/programs elsewhere in the cluster that might be behind the times. I don't care when the NSA learns what my insurance premium is. A couple of minutes delay is fine. Also for Google trying to figure out what ads to show me, also the business intelligence part of the vendors stack, etc... there are many, many perfectly reasonable business applications where ACID is not necessary.

cheap performance trumps pointless reliability in a surprisingly large number of cases.

Completely agree with that. It only emphasizes that people who insist on using SQL for data safety and security reasons are doing it out of a kneejerk reaction. There is no magic tech that will just make stuff work. Folks need to understand the application. Choice of tools/engines is largely a matter of taste, and success a matter of the skill of the craftsmen in selecting and applying the chosen tools.

Why do people insist that NoSQL means losing data and inconsistency? What you are losing with NoSQL real-time consistency horizontally across large number of instances spread over multiple data centres. When you are doing a transaction, and it should be "eventually consistent." meaning on the order of minutes. So if someone, somewhere else, who you do not know about and are not interacting with asks about your data, it might be a few minutes old. ACID makes it so that random person will get an upto the milli-second accurate answer. That makes transactions orders of magnitude slower, and much more complicated to scale. When you relax that constraint and let the people doing the transactions (the person, and the providers they are dealing with) get the right answer immediately, but just post the transaction so that the backups etc... get informed in due course, you gain much simpler scaling. The choice of NoSQL vs. SQL is not about the importance of the transaction. It is about application scaling and design, and the biases (tastes?) of the team doing the work.

Most people put total nonsense in their cloud storage, so that's fine... (hint: foreign speaker alert! "Sensible" does not mean the same thing it means in French (at least, perhaps some other language in question. for Spanish speakers, try translating "No me molestes!" for fun...)

yup. nexus 5 works fine on a nexus 4 qi port, except that on the nexus4 the coil works almost anywhere on the phone, but on the nexus 5 you have to be nearer the centre. I'm using both while waiting for the new charger for my 5.

fwiw... It's 230 K, not 22 K$. but doesn't change your point. ECG is so nerdy... He should emphasize other uses, and try to market based on that. He could call it a "biorhythmic training device for understanding the crystals, and getting in touch with your aura. or talk up the "biofeedback" aspects of it, how it will help with meditation. That will sell to one crowd. Figure out how to use it as a kind of game controller, and the internet will fund in a (wait for it!) heartbeat.

It is native code but still running in a sandbox.
https://developers.google.com/native-client/dev/overview#security
The only interaction between this process and the outside world is through sanctioned browser interfaces.

As in collectively the three of them are going to have CGI drag a cross on their back around the country for a few months, before they have the company install the cross, and they will nail CGI to it in a standing, sunward facing position? On Good Friday, they will go into Chapter 11. only to return a few days later, clean up some left over bills, and then disappear for good?

I think the point is that when an AI is driving, an accident will be a rare occurrence that people will want to understand, because it will be rare, and because the AI can be improved so that that problem does not happen again, and because if it happens for one person, the AI will do the same thing for other people, and if someone wants to sue, after the first time it happen, they will have a much stronger case for negligence on behalf of whoever is responsible for the AI.

Everything possible will be done to ensure that the same thing doesn't happen again, to avoid liability and/or a satire piece (like the Pinto gas tanks) that will kill the model involved. So a autonomous car accident will look more like an airline accident, with an investigative team coming in from wherever, and really nailing what went wrong, because just like an airline crash, hundreds of lives, sales, and big-time law suits will be on the line. That focus will change the numbers.

Look at fatality stats. When are normalized by distance travelled, it is 7.97/0.03 --> 266 times more likely to die in a car today than an airplane. That's where the direction things are going to go, only more so, because airplanes are still driven by humans, and there is an upper limit of reliability of humans that is much lower than can eventually be achieved by automation. So the airline numbers should continue to improve as automation is further refined.

In the past, there was always something humans could do that machiness could not. When people went off the farm, they could do mechanical assembly work, they could clean, serve food, judge whether someone was likely to pay back a loan, or know how to build something. Computers and robotics are progressing such that there are fewer and fewer tasks that they cannot do. Eventually the number of tasks that need humans will be very small. Humans will either need to compete fiercely for the few jobs available, or be born into independence. If the normal state of affairs is 80% or 90% unemployment, and robots can do any task that a human can do cheaper, faster and better, it makes no sense to employ humans to do that task.

If almost everyone shouldn't work, the value of human labour being practically nil, maintaining social stability and order become a problem and you need more labour to maintain order, robotic labour. Expressions like "Peace, Order, and Good Governance", "the american dream", "social justice", "life, liberty, and the pursuit f Happiness" change their meaning.

Hard to say how it will turn out...

Insteon is low power, low range, low bandwidth... 2800 bit/s. If I don't have any other insteon equipment, why would I have a bridge? I wouldn't. I already have a wifi point because it is useful for general purpose (computers, smartphones, gaming devices, etc...) I prefer general purpose network that uses a medium thoroughly, rather one that uses multiple media and needs to share all of them and worry about multiple networks interfering. I prefer to debug interference with one PHY at a time. Granted... Insteon is going to be at a completely different wavelength, being so slow, but that also means I cannot see the packets going by without an Insteon sniffer... I'd rather just be able to use tcpdump on a wifi or ethernet port.

It isn't about whether Insteon works, It does. And it is here now... and it will be crushed by wifi and homeplug as adapters for those get cheaper/easier to incorporate into hardware because they are far more flexible future facing. What these people are doing, using existing networks instead of inventing your own is just a better way to solve the problem over the long run.

I like wifi better because it is already here, rather than having to add more hardware and have to support yet another network with yet another addressing scheme routing, etc... And Insteon is not IP, uses both RF and powerline..., and very low bandwidth... interesting but I prefer to use general purpose networks, say Wifi for RF, and HomePlug for powerline, both of which can be used by many more devices (in terms of compatibility), so reducing the total RF flying around.

Why use IR, phones have cameras and LED flashes... better to use visual spectrum...

allocating 1ms in 10 to a process on a process sounds pointless because in an environment with that many cores, getting a cpu will not be a problem. It's a bit like implementing QoS for VOIP on a gigabit ethernet link. Your voip channel is what a few kbps at most... a millionth of the available resource? What is the point of managing/scheduling it? That management overhead dwarfs the benefit in all but very rare cases.

What I suspect they are really about is assigning (ie. dedicating) groups of processors which are geometrically localized (patches or polygons on the compute surface) together, so they can run multi-processor apps on the surface without getting bogged down by noise of general purpose processes. This is well known in supercomputing, and is often termed reducing OS jitter, and is very important. It is about reducing contention for scheduling by undoing the last 50 years of OS work to share CPUs. CPUS are cheap, so dedicate them. It is typically the job of the batch scheduer, but I can see how pushing this down to the OS itself, in these days of many core on a chip, is a useful improvement.