It was on the BBC news this morning, which probably counts as more reliable than 4chan. Most interesting was the claim by one of the women involved that the photos had been deleted. If this is true, then it would be a great example of the fact that just because something is 'deleted' in the cloud doesn't mean that malicious people can't get at it in the future...

If I'm going to report errors in a map, I'd rather do so with a map that releases its data under a license that allows reuse. Since such a map already exists and doesn't have the errors in Google Maps, I don't see much incentive. Google can pull the data from there if they want. This is actually one case where Microsoft has been a bit nicer: they allowed OSM to trace their satellite images to improve maps. Google Maps, in contrast, is very protective over their data.

NFC payment cards in Australia/Europe cryptographically sign a challenge from the terminal, using basically standard crypto. It's EMV all the way. In-person magstripe payments are carefully controlled and risk analysed to ensure they only occur if, for example, the card is broken - or outright banned.

NFC payments in the USA involve the phone sending regular magstripe data to the terminal, with only the CVC code being some kind of cryptographic derivative - a three digit number (less than 1000). The reason for this crazy setup is so merchants don't have to update their backend/PoS systems that still expect magstripe data. There is no plan to perform a complete upgrade thus old style transactions cannot be phased out. It's a dramatically less secure system.

Your card was declined because they're totally different and incompatible technologies. NFC payment cards from outside the USA aren't the same as "NFC payments" inside the USA (which require mobile phones as far as I can tell).

More importantly, the underlying technology is totally different. VISA Europe is not at all the same as VISA USA. VISA in Europe is a coalition of banks, VISA USA is a private company. America has never rolled out EMV, making its banking industry a ridiculous joke compared to, well, everywhere else. You don't get reports of major European supermarket chains getting their PoS systems hacked and magstripes skimmed like you do in the US, because EMV is a much more secure system.

The NFC payment cards that are rolling out around the world (outside USA) now are basically a variant of EMV/Chip and PIN. The underlying crypto is the same. The card signs a challenge from the terminal. They're upgrading to elliptic curve crypto at the moment actually, not sure if all NFC cards do that or not but it would not surprise me. NFC as tried by Google in America is actually a very minor variant on just sending your magstripe data via radio. I believe the CVC code rotates (three digits of entropy lol) and the tech is based on a Secure Element hard-wired to the NFC radio. But the phone has minimal control over the actual payment transaction, thus doesn't add much value beyond being a big battery, and that's why the tech largely stalled. Also they screwed up the compatibility testing and the terminals were full of bugs that meant transactions just sort of randomly failed.

So don't be fooled. The "NFC payments" that we know outside of North America is totally different to what they call "NFC payments", which is an unfortunate piece of linguistic confusion.

Not sure what post you think you're replying to, but the quoted line didn't appear in my post...

Here's a tip, my Russian friend: if you want to pretend to be a neutral observer on the Ukrainian conflict in an internet forum, then you'd do better to proofread your post again and again until you manage to remove the little telltale signs that your native language is Russian. No informed reader of your post above is going to be convinced you don't have a significant dog in this fight.

You know, maybe some of us should complain to Slashdot about the Obama/Poroshenko-bots that reliably and consistently troll every single story about this conflict? You know, the ones who imply that anyone who even slightly skeptical about the propaganda we're all being fed, must be Russian or a paid Kremlin propagandist?

Suck on this. I'm a native English speaker from the UK, I have never been to Russia, I have been reading Slashdot for about 14-15 years, posting for most of that time too. And the Anonymous Coward tells it like it is. Poroshenko has claimed Ukraine was invaded like ten times already. He claimed he was being "invaded" by a fucking aid convoy, including after Putin's honesty about it's contents had been verified by international journalists and the Red Cross. In fact he asserted he'd shell said convoy, so the Red Cross chickened out, but the crazy Russians just drove right in there and delivered that aid anyway.

So as a native speaker, please heed my call - let's all stop abusing the English language shall we? We know what an invasion looks like. It looks like what the USA did to Iraq. It looks like Russian flags flying above Kiev and Russian tanks rolling down the streets to the parliament building. It does not look like journalists scrabbling around presenting the testimony of a milkmaid in a farcical attempt to find an army, as the Guardian did only a few days ago. Now condemn Putin for militarily supporting the rebels if you like (though the proof of this is wafer thin as well), just be aware that this is something many countries do, including the ones that are currently being most shrill about Ukraine. So such an argument doesn't have much impact, unfortunately, though I wish we lived in a world where it did.

I don't know about rural Japan, but I found the OSM data far better when I visited Tokyo a few months ago. Google didn't know building names and placed a load of things that we were trying to visit a few blocks away from where they actually were. This was very frustrating as the web site that we were using to find vegetarian restaurants used Google maps - we spent half an hour one lunchtime walking in the wrong direction, because we'd come to a junction and, according to the Google map needed to turn left and would then see our destination on the right. It turned out, when we eventually found it, that we should have turned right.

I use OSMAnd on my phone[1], but my girlfriend recently bought a Windows Phone and I've been very impressed with Nokia's mapping app (I actually like a lot of what Microsoft's done with Windows Phone 8, but it's a strange mix of very polished and well-designed UI parts and completely unfinished parts with missing features). It's good to see more competition with Google maps, which is becoming increasingly entrenched in spite of the fact that the UI is pretty poor in many regards and the mapping data is terrible. For example, here they're missing (or have in the wrong places) most of the cycle paths, which ends up with people regularly getting lost if they rely on Google, in spite of the fact that all of this data is in OpenStreetMap.

[1] For me, it's the killer app for Android. Offline maps, offline routing, and open source backed by high-quality mapping data from OpenStreetMap. I use the version from the F-Droid store, which doesn't have the limitations of the free version from Google Play and it's one of the few open source apps that I've donated money to.

Remember when the SoundBlaster Live! came out and Creative Labs were telling you that it had as much processing power as a Pentium 166MHz MMX, dedicated entirely to sound processing? Well, it turns out that now you can have far more CPU power than that dedicated entirely to sound processing without custom hardware...

They're a pain for people on both sides of the ISA.

The compiler has to find an instruction that can run after the branch. This is normally trivial for calls, but for conditional branches within a function it's often difficult to find an instruction that you can put there. It has to be one that is either from before the jump (or in both basic blocks after the jump), but that the branch doesn't depend on (because it's executed after the branch instruction). This means that you quite often end up padding the delay slots with nops, which bloats your instruction cache usage. On a superscalar implementation this is the only cost, but on a simple in-order pipeline it's also a completely wasted cycle.

On the other side, it's a pain to implement. It made sense for a three-stage pipeline in the original MIPS, because you always knew the next instruction to fetch. A modern simple pipeline is 5-7 stages though, so your branch is still in register fetch (if there) by the time the delay slot is needed. It doesn't buy anything and it means that, if you're doing any kind of speculative execution (even simple branch prediction, which you really need to do to get moderately good performance) then you have an extra dependency to track - you can't just use the branch as the marker and flush everything after it, you need to do some reordering. In a superscalar implementation, you need to do even more complex things in register renaming to make it work.

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...

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.

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.