This doesn't mean what you seem you think it means. The man harmed his wife by making what a reasonable person (including his wife) saw as credible threats. If he had no intent whatsoever to assault her in any way, but had the intent to make her afraid by sending credible threats, then he did in fact intent to cause her harm.

They have to prove that he intended to make threats, not that he intended to follow up on his threats. I don't actually see this as much of a problem. I am sure he would have been convicted with the right jury instruction, but the right jury instruction was not given.

Not at all.

Courts sometimes get things wrong, and then SCOTUS steps in and tells them that they got it wrong. The courts then have to look at the matter again. They are supposed to do it right the next time. SCOTUS is not supposed to tell them how to do it right. They are not little children that need hand holding. They are assumed to get it right on their own most of the time.

Well, he is not getting away with it (not yet). It was decided that the judge gave wrong instructions to the jury. The wrong instruction was that the jury had to decide whether a reasonable person would think of his posts as threats. The correct instruction would have to be that the man himself knew that what he posted would be taken as threats.

So it's going back to court. I personally believe and hope that he will be found guilty with the correct jury instruction as well.

There's some overlap. Altera FPGAs have lots of fixed-function blocks on them, ranging from simple block RAMs to fast floating point units. There's a good chance that Intel could reuse some of their existing designs (which, after all, are already optimised for their manufacturing process) from things like AVX units and caches on x86 chips. A lot of the FPGAs also include things like PCIe, USB, Ethernet and so on controllers. Again, Intel makes these in their chipset division and, again, they're optimised for Intel's process so being able to stick them on FPGAs instead of the Altera ones would make sense.

The main reason that you're probably right is that Intel is generally pretty bad at getting their own internal divisions to play nicely together, let alone ones that are used to being in a completely separate company.

You might want to look at the papers from MS Research on their use of FPGAs in their data centres.

My guess would be coarse-grained reconfigurable architectures. Altera FPGAs aren't just FPGAs, they also have a load of fixed-function blocks. The kinds of signal processing that the other poster talks about work because there are various floating point blocks on the FPGA and so you're using the programmable part to connect a sequence of these operations together without any instruction fetch/decode or register renaming overhead (you'd be surprised how much of the die area of a modern CPU is register renaming and how little is ALUs).

FPGAs are great for prototyping (we've built an experimental CPU as a softcore that runs on an Altera FPGA at 100MHz), but there are a lot of applications that could be made faster by being able to wire a set of SSE / AVX execution units together into a fixed chain and just fire data at them.

That minimum wage guy is one of the major costs for a taxi company. The IRS rates miles driven in a car at a little under 60/mile, which should cover maintenance, depreciation, insurance and fuel. A taxi that only had these costs could be quite profitable at 70/mile. In New York, taxis cost $2/mile, which isn't that far off other places in the USA. The minimum wage guy needs to be paid even when the taxi is waiting for the next fare. With an automated car, you'd just leave them scattered around the city powered down and turn on the closest one when you got a new job.

They can already map the serial numbers of the currency to the account holder and the person in possession of PIN and card. And there already are cameras, except that currently they don't protect you from misuse of your card by a thief, but can only tell that it was a thief after the fact.

That's always the same on Slashdot. They come up with weird fantasies of kidnapping and so on.

Stealing or duplicating a credit card is relatively easy and no big risk. If you get caught, the punishment isn't too bad even if you stole a thousand cards. Kidnapping on the other hand doesn't give you any more reward, even a single attempt is dangerous for you, unlike normal kidnapping where you hide the victim you must bring the victim to a public place which hugely increases the risk, and if you are caught they never let you out again.

Not at all. If someone puts Joe Smith's card into the reader, and types in Joe Smith's card PIN, then they only need to compare the face of the person with a picture of Joe Smith, and nobody else. A crook can only get your money if by a huge coincidence that crooks looks the same as you. And that crook cannot get anybody else's money. There are no false positives, there is no reason to compare the face with the photo of anybody else.

FWIW, the law very rarely supports "finders keepers losers weepers". The short story on that is that "physical posession does not prove or establish transfer of ownership". The only time that has a chance of winning is when the loser fails to establish they ever had ownership. But in this case, she gave it to them, and that 100% transfers ownership. Legally, they owe her nothing, and would be unlikely to lose in a court case.

Someone above cited big business as above this law, such as a "bank error in your favor" getting yoinked back. No, in that case when you sign the paperwork to set up the account, there will be specific wording in there saying you agree that bank errors are NOT in your favor and you will be legally obligated to return any cash withdrawn under those circumstances. The only difference here as far as the bank is concerned is they didn't stop you before you got money from them (unlke say, a bounced check) and so now there's a bit of additional burden to having go to after you to get the money back. (it usually doesn't work that way, so that just tends to get them wound up)

what's with this "RTM" term?

I'm going to have sooo much difficulty not auto-translating that to "RTFM" when I hear or read it...

there are a lot of them for sale, they're very cheap. http://www.ebay.com/itm/221602... is the first one I spotted. They usually run on four AA. That one even has a light in it, that's a feature mine doesn't. (but hey, mine was free)

A Kickstarter-like model would work. Release a single for free, designate an amount that you think the full album is worth. If enough people are willing to pay, then you release the album for free. For the second album, hopefully enough people have copied the first that you don't need to do much to encourage them to pay for the second. As an added bonus, you can reduce your up-front costs by only renting the studio time to record the first track and only record the rest once people have paid for it.

Recording a song (at least, a song that people want to buy) requires talent, creativity, and often expensive instruments and studio time. Copying a song once it's recorded is basically free. Any business model that relies on doing the difficult thing for free and then trying to persuade people to pay for you to do the easy thing is doomed to failure. Imagine if Ford had noticed that people wanted coloured cars and decided to give away unpainted cars and charge for painting them, then bribed politicians to pass laws so that only Ford was allowed to paint cars Ford sold and driving an unpainted car on the road was illegal. It wouldn't take people long to realise that this was a stupid business model and that you could get rid of the laws and charge for the cars, but in the case of copyright people are still trying very hard to make the 'free car, expensive and exclusive paint' model work with different variations.

It's an ABI mismatch, and the summary is nonsense, saying almost the exact opposite of TFA (which I actually read, because the summary is obvious nonsense). The issue is that the Windows ABI defines long double as being a 64-bit floating point value (which is fine, because the only requirement for long double is that it have no less precision than double. If you're using it and expecting some guaranteed precision for vaguely portable code then you're an idiot). For some reason, MinGW (which aims to be ABI-compatible with MS, at least for C libraries) uses 80-bit x87 values for long double, so you get truncation. I forget the exact calling conventions for Windows i386, but I believe that in some cases this will be silently hidden, as the value will be passed in x87 register and so be transparently extended to 80 bits in the caller and truncated in the callee anyway. It's only if it's passed on the stack (or indirectly via a pointer) that it's a problem.

It's not obvious which definition of long double is better. On modern x86, you'll use SSE for 32- and 64-bit values, and may lose precision moving between x87 and SSE registers. You also get worse IEEE compliance out of the x87 unit, which may matter more than the extra 16 bits of precision. 80-bit floats are not available on any platform other than x86 (128-bit is more common, though PowerPC has its own special non-IEEE version of these and on some other platforms they're entirely done in software), so they're a bad choice if you want portable code that generates the same output on different platforms.