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.

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.

The same is true of university exams. My undergraduate exams, for example, mostly required that you answer two of three questions per exam. To get a first (for people outside the UK: the highest classification), you needed to get 70%. Most questions were around 40% knowledge and 60% application of the knowledge. If you could predict the topics that the examiner would pick, then that meant that you could immediately discard a third of the material. To get the top grade, you needed to get 100% in one question and 40% in another. This meant that you could understand a third of the material really well and understand another third well enough to get the repetition marks, but not the understanding ones and still get the top grade. This meant that you could study 50% of the material and still do very well in the exams, as long as you picked the correct 50%. And some of the lecturers were very predictable when setting exams...

What jobs do you imagine existing in 10-20 years that don't require some understanding of programming? I thought my stepfather, as head greenskeeper at a golf course might have had one before he retired, but it turns out that the irrigation system that he had to use came with a domain-specific programming language for controlling it. A lot of farm equipment is moving in the same direction. Office jobs generally require either wasting a lot of time, or learning a bit of scripting (hint: the employees who opt for the first choice are not going to be the ones that keep their jobs for long). Jobs that don't require any programming are the ones that are easy to automate.

But, of course, we don't need to teach our children to write. After all, they can always hire a scribe if they need to and there really aren't enough jobs for scribes to justify teaching it to everyone.

Why would I be stuck with the connector? For one thing, you can easily install adaptors - even if you'd rolled out USB A or B sockets, they'd still be supported everywhere and you can buy adaptors very cheaply. The main problem with a USB A socket (which is really the only one of the previous ones that you'd consider for charging) is the low power - it can only provide about 10W, even if you have some adaptor. USB C can provide 100W, and 100W seems like enough for a DC supply for quite a while.

But if I'd rolled out USB A sockets in 1995, I don't think I'd object strongly to replacing the faceplates on the sockets with USB C ones in the next five years, if the wires in the wall could supply the required power.

No one you know has a MacBook Air? Most of the next generation of mobiles are going to have USB C (Apple and Google are among the bigger backers), so expect to see a lot of them appearing.

If you connect one of these to the existing AC main, then you're just moving the well wart into the socket. You still have one AC to DC converter for each device, and that particular device can only provide 2.1A at 5V, which is well below what USB-C supports (no charging a MacBook Air from it, for example).

The Open Group claims the copyright on the POSIX specifications. If APIs can be copyrighted and this copyright includes all implementations, then it would be problematic for all open source *NIX systems. Of course, they might decide to provide a license that's valid for everyone except Oracle (though writing such a license in a way that's GPL compatible would be very hard, so glibc might be in trouble).

The thing that killed DC in the war of the currents was that step up and step down transformers for AC are easy and cheap to build, but doing the same thing for DC caused a lot more loss (one of the simplest ways of doing it was to convert to AC, do the voltage change, and then convert back to DC). For long hauls on the grid, you want a much higher voltage than in houses. Now, however, it's relatively cheap (both in terms of convertors and in terms of loss) to produce DC-DC converters. USB-C supports 5V (up to 2A), 12V (1.5-5A) and 20V (3-5A). It's fairly easy to imagine 48V between rooms and then a converter in the sockets able to provide USB voltages. You wouldn't want to run a heater or a vacuum cleaner from it, but it would be nice for a lot of consumer electronics.

We're not talking grid back-haul though, we're talking a few tens of metres maximum within a house. I've wondered for a while if it would be more efficient to have moderately high voltage DC room-to-room and then low-voltage DC in rooms. Given the number of things in my house that would prefer a DC supply and so end up with (cheap and inefficient) AC to DC convertors per plug (and especially if you use LED lighting), it seems like it ought to be a win. And now seems like a good time to do it, as USB-C is a consumer connector that can provide up to 100W via something that's designed to be very cheap to produce in the lower power variations.

Top 10% probably. Take a look at a global rich list calculator. You can live very comfortably in a western country with 9% of the world's population being richer than you. If you're in some parts of central or eastern Europe, or a few parts of south-east Asia then you may be near the bottom of the top 20% and still living very comfortably. The '1%' that people talk about in the USA are well in the top 0.1% globally, but 'the 1%' makes a better soundbite than 'the 0.1%'.

Fewer seamen suffer from PTSD than VB coders.