Particle beam deflector cannons mounted behind the grill.

Which is why the previous UK government was looking at road pricing, even going so far as a pilot study with four companies (I worked directly on this for one of them). And as cars move to alternative fuels/power many places that use tax revenue generated gasoline and diesel will be looking very seriously at doing this for real.

Europeans, when push comes to shove, are generally useless when it comes to standing up for what is right. So even though these are foreign, presumably European emails, residing on European servers, once the appeal process finishes Microsoft will start downloading the data to US servers. And then the EU nations will promptly call a summit, bicker amongst themselves till the download is complete, whine a lot, but ultimately do nothing. Just like they are doing with Ukraine. Given a choice of doing something meaningful that needs doing but might cause some discomfort and conflict, they would rather rationalize why they don't do anything. Kind of like Obama too (and I am not a Republican/conservative or libertarian... I'm independent).

Asking nerds what apps are good is like strolling into a literature forum and asking "I haven't read a book in 15 years - anything new out that you think is good?"

Well this "Twilight" series is a best seller. As is this "50 Shades of Grey".

I really with the old Twilight Zone was still running. I think that that premise would make a great episode.

I'm going to map my drive to work, by driving it a few dozen times.

And that is if you are the ONLY person with a robot car on that road. Which may be correct for the initial roll-out. But this is a great example of the "network effect". If 100 people in your state own robot cars then a LOT of your state will be continuously mapped / re-mapped / re-re-mapped / etc.

Are we really whining because a brand new technology can't do EVERYTHING for us? Because it only takes care of MOST of the drudgery?

There is space to be filled and page hits to be collected. Demanding instant perfection for every edge-case is a good way of doing both.

Google has logged over 700,000 miles in those vehicles. Without a single robot-controlled accident.

There might be problems in certain weather conditions. Or in certain other conditions. Or whatever. In which case the driver should take over.

And since it is software, eventually those problems should be solved.

Some cretins dreaming about bio-weapons does not give them any real capability. And no, they are neither easy to make nor cheap nor easy to use. This is just the usual exceedingly unethical fear mongering used to sell more copy and to keep the population docile.

It is also not a new tactics, but most people are still cretins that fall for it every time:

The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary. -- H.L. Mencken

Judging by how badly TFA was written.

If a new stop light appeared overnight, for example, the car wouldn't know to obey it.

Got it. So the cars cannot handle changes in traffic markers.

Google's cars can detect and respond to stop signs that aren't on its map, a feature that was introduced to deal with temporary signs used at construction sites.

So they cannot deal with new stop LIGHTS but they can deal with new stop SIGNS. WTF?

But in a complex situation like at an unmapped four-way stop the car might fall back to slow, extra cautious driving to avoid making a mistake.

And it would be "unmapped" for the first attempt. Right? Because the cars should be sending back data on road conditions and such to HQ. Right?

Maps have so far been prepared for only a few thousand miles of roadway, but achieving Google's vision will require maintaining a constantly updating map of the nation's millions of miles of roads and driveways.

And the car needs the map to drive, right?

Google's cars have safely driven more than 700,000 miles.

So they just drove over the same "few thousand miles of roadway" again and again and again and again? Until they got to 700,000 miles?

The car's sensors can't tell if a road obstacle is a rock or a crumpled piece of paper, so the car will try to drive around either.

As it should. Because you don't know if that piece of paper is covering a rock or a pothole or whatever.

For example, John Leonard, an MIT expert on autonomous driving, says he wonders about scenarios that may be beyond the capabilities of current sensors, such as making a left turn into a high-speed stream of oncoming traffic.

Isn't that one of the easier problems? The car waits until it detects a gap of X size where X is dependent upon the speed of oncoming vehicles and the distance it needs to cross PLUS a pre-set "safety margin".

No idea. I don't know if the instructions for computing PC-relative addresses in an ISA without an architectural PC are patentable. They also exist in RISC V (not sure which came first), so if they do then it's going to be a problem for Kriste et al. Nothing else in there is especially novel: like ARMv8, it's a nicely designed compilation target, but it doesn't do anything that's especially exciting.

I didn't look at the floating point stuff in much detail, so there may be something there, although the biggest changes in recent versions of the MIPS specs have been that they're more closely aligned with the IEEE floating point standards, so it's hard to imagine anything there.

The biggest difference between MIPS64r6 and ARMv8 is that the MIPS spec explicitly reserves some of the opcode space for vendor-specific extensions (we use this space, although our core predates the current spec - it's largely codifying existing opcode use). This allows, for example, Cavium to add custom instructions that are useful for network switches but not very useful for other things. ARMv8, in contrast, expects that any non-standard extensions are in the form of accelerator cores with a completely different ISA. This means that any code compiled for one ARMv8 core should run on any ARMv8 implementation, which is a big advantage. With MIPS, anything compiled for the core ISA should run everywhere, but people using custom variants (e.g. Cisco and Juniper, who use the Cavium parts in some of their products) will ship code that won't run on another vendors' chips.

Historically, this has been a problem for the MIPS ecosystem because each MIPS vendor has forked GCC and GNU binutils, hacked it up to support their extensions, but done so in a way that makes it impossible to merge the code upstream (because they've broken every other MIPS chip in the process) and left their customers with an ageing toolchain to deal with. I've been working with the Imagination guys to try to make sure that the code in LLVM is arranged in such a way that it's relatively easy to add vendor-specific extensions without breaking everything else.

Imagination doesn't currently have any 64-bit cores to license, but I expect that they will quite soon...

This is the primary problem with "sweep" methods of collecting data.

There MIGHT be something in the "sweep" that MAY impact a current investigation. Therefore, ALL of the "sweep" must be hidden from the public.

Bullshit. There shouldn't be any difficulty in removing the items relevant to a current investigation. The should already be tagged as such. Then release the rest.

This is a case of "collect EVERYTHING and keep it FOREVER" so that anyone can be backtracked if the cops or politicians decide to do so. Where do you go? When? Why? What do you do there?

Now imagine a cop tracking your daughter to find out where she lives and where she works and which college she goes to and when she leaves for classes.

Assuming that your code doesn't do anything that is vaguely MIPS specific. If it is, then there is little benefit in using MIPS32r2 now - ARMv7 is likely to be closer than MIPS32r2 to MIPS32r6 in terms of compatibility with C (or higher-level language) source code compatibility.

Basically, because the MIPS ISA sucks as a compiler target. Delay slots are annoying and provide little benefit with modern microarchitectures. The only way to do PC-relative addressing is an ugly hack in the ABI, requiring that every call uses jalr with $t9 in the call, which means that you can't use bal for short calls. The lwl / lwr instructions for unaligned loads are just horrible and introduce nasty pipeline dependencies. The branch likely instructions are almost always misused, but as they're the only way of doing a branch without a delay slot there's often no alternative.

While that certainly plays a role, it is a minor one. It does stand in the way of solving things, but if you do not have developers that can do secure software engineering competently (and that is the normal case), then giving them too little time and money to do secure software engineering does not matter. The other thing is that people that actually understand software security are much less likely to declare something finished or secure than those with only a superficial understanding of things. Software security really is an additional, and exceedingly hard to obtain, qualification. That most "programmers" these days struggle even with simple things (see http://blog.codinghorror.com/t... , for example) is not the root cause.

There's no price yet because they're giving away the first production run to people who are going to do interesting things with them. Unfortunately, this is a really bad time to do anything MIPS related (and I say this as someone who hacks on a MIPS IV compatible softcore and the LLVM MIPS back end). Imagination has just released the MIPS64r6 and MIPS32r6 specs. These are the biggest revisions to the MIPS ISA since MIPS III, which introduced 64-bit support. They've removed a load of legacy crap like the lwr and lwl instructions and the branch-likely instruction family and added things like compact (no delay slot) branch instructions, the requirement that hardware supports unaligned loads and stores (or, at least, that the OS traps and emulates them), and added much better support for PC-relative addressing. The result is a nice ISA, which is not backwards compatible with MIPS32r2 or MIPS64r2, the ISA that these boards use. Any investment in software for MIPS now is going to be wasted when products with the new ISA come out.

For building big C++ projects, as long as the disk (yay SSDs!) can keep up, you can throw as many cores as you can get at the compile step and get a speedup, then sit dependent on single-thread performance for the linking. I got a huge speedup going from a Core 2 Duo to a Sandy Bridge quad i7, then another noticeable speedup going to a Haswell i7 in my laptop. The laptop is now sufficiently fast that I do a lot more locally - previously I'd mostly work on a remote server with 32 cores, 256GB of RAM (and a 3TB mirrored ZFS array with a 512GB SSD for ZIL and L2ARC), but now the laptop is only about a factor of 2 slower in terms of build times, so for developing individual components (e.g. LLVM+Clang) I'll use the laptop and only build the complete system on the server.