“With autonomy, the edge cases kill you, so you’ve got to build out for all the edge cases,” Mr. Khosrowshahi said at a conference in November.

That is, the edge cases kill you, my listeners, and the public.

Perhaps this is an artifact of the video compression algorithm or the camera itself.

It could also be the effect of increasing brightness, couldn't it? If in the raw footage the light levels are all between 0% and 20%, if you raise the brightness, what used to be 1% will now be 5-10%, at which point there will be a hard cliff down to 0, no?

1. What the heck is wrong with you

2. How the heck do you have a default '2' score with that obviously trollish attitude

3. You're awfully brave when you're hidden behind the internet, aren't you?

4. Absolutely I hope people like you stay a million miles a way from any project I'm associated with.

So saying things like drug abuse or being overweight is unhealthy, or that anchovies are gross, is a violation.

So wait, you go around your open source projects telling the fat people that they're unhealthy? Or worse yet, you go around trying to get people to stop eating anchovies? I definitely don't want you in my project.

(Note saying you don't like anchovies is not a problem; making unwelcome comments about other people's anchovie preferences is.)

This one is a real winner. So you have to ask for permission to *hug* them.

Um, yes? Why do you think you have a right to go around touching people who don't want to be touched?

This is exactly the point -- there are people who want to hug, and people who don't want to be hugged. We have exactly two options:

1. 1. Make "OK to hug unless asked not to" the default, and put the burden of saying 'no' on the person who doesn't want to be touched
2. 2. Make "Not OK to hug unless you're confident the person is OK with it", and put the burden of finding out if touching is OK on the person who wants to do the touching

#2 seems like the obviously right choice to me.

I mean, seriously -- if you want to borrow something from a friend, do you just take it, or do you ask first? With a good friend you might just take it, but you'd better be darn sure they're OK with it before you do so. Why should hugging be any different?

Technically, the iPhone wasn't any more innovative than what Palm had already created.

Whatever. Dude, I owned a Palm back in the 90's. I also, shortly before the iPhone came out, bought my first "smartphone" -- a Symbian device -- which made me conclude that there just wasn't really any use for having a smartphone.

The iPhone completely changed the game for smartphones. They made it actually useful. Just like they did for mp3 players back in the day.

You don't know what you're talking about. Meltdown only applies to normal user processes; it doesn't apply to KVM because you're in a different address space. Google Project Zero's blog clearly says they used "Variant 2" -- one of the Spectre vulnerabilities -- to read host memory from within a KVM guest.

There is still nothing really useful gathered from using it that makes it a security risk.

They were able to read the entirety of host RAM from inside a KVM VM.

You seem to have a very strange definition of "security risk".

Spectre is a red herring - there is no known way it can be exploited.

Google has exploited it. Look at Google Project Zero's write-up of these bugs. Spectre corresponds to "Variant 1 and Variant 2" in that blog post. You'll see that they successfuly exploit both, the second from a KVM guest.

It is true that Google cheat a little here, by using Linux's eBPF JIT engine (which, I hear, is normally disabled by default). From the blog post:

To be able to actually use this behavior for an attack, an attacker needs to be able to cause the execution of such a vulnerable code pattern in the targeted context with an out-of-bounds index. For this, the vulnerable code pattern must either be present in existing code, or there must be an interpreter or JIT engine that can be used to generate the vulnerable code pattern. So far, we have not actually identified any existing, exploitable instances of the vulnerable code pattern; the PoC for leaking kernel memory using variant 1 uses the eBPF interpreter or the eBPF JIT engine, which are built into the kernel and accessible to normal users.

There's a pretty good summary in the XenProject Security Advisory:

Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution".

Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained.

Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme):

SP1, "Bounds-check bypass": Poison the branch predictor, such that operating system or hypervisor code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes.

SP2, "Branch Target Injection": Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that exists in the hypervisor.

SP3, "Rogue Data Load": On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level.

The "some processors" for SP3 means Intel.

AMD seem to think they're not affected by Meltdown:

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

BTB it is almost certainly this email, sent on 26 December, which led to the Meltdown vulnerability being made public, causing the disclosure timeline to be moved up.

It was obvious then and it's obvious now. There's a great deal of social expense surrounding bogus patents, infringement, and patent trolls.

The patent office makes money from granting patents. If, when a patent was overturned in court, the office had to pay back four times the patent fee, there'd be an incentive to grant patents less than 25% likely to be overturned.

From the first paragraph of TFA:

Exposed within the repository are massive data sets belonging to Alteryx partner Experian, the consumer credit reporting agency, as well as the US Census Bureau, providing data sets from both Experian and the 2010 US Census.

So Alteryx got data from a credit bureau and screwed it up. This should at least open them up to a massive lawsuit from Experian for breach of contract.

A good friend of mine insists on being Republican and I ask why he says "I'm gonna change it from the inside".

Well in some areas of the country, the probability of a Democrat winning are close to zero. So the real election actually happens at the primary, when the Republican candidate is chosen. But because people don't think of these as the real election, or even an important one, it's an easy target for extremists to hijack -- and therefore, an important place for moderates to defend.

If in "red" districts, everyone voted for a moderate Republican in the primares, I think we'd be in a lot less of a mess.

I would have thought the same thing, but when I recently actually looked at rent vs mortgage in my area, mortgage did in fact turn out to be cheaper.

Remember that there's a barrier to entry to getting a mortgage. Lots of people are never going to be able to save up 25% for a downpayment to get the most preferential mortgage rates (which is what would be required to have decent mortgage payments). (Yet another way it's expensive to be poor.) Additionally, if you're living in a really transitional area, it may be more cost-effective to rent for 2-3 years than to buy, even if you could afford the downpayment.

Well it shouldn't be accepted as fact. Ideally the courts would instruct the jury to treat the software's output as similar to a human being saying, "This is my expert opinion." You can submit your own software's "opinion" as evidence as much as you can get your own expert human to testify on your behalf.

It is true that you can't cross-examine it; but ideally, that should make the software less reliable. If you had an expert who, upon cross-examination, always responded, "I don't know, it just seems that way", then he wouldn't have much credibility. Ideally, software that can't justify its "opinion" should be treated the same way.

I have said "ideally" here several times, recognizing that it may well be the case that this isn't how people actually think. But I think a more constructive response to this misplaced trust is to help inform courts and defense lawyers more clearly (who should in turn inform the juries).