Your work at Samsung involves making EFL a great library for designing touch-based interfaces for use in a future Linux-based smartphone platform, presumably Tizen. But every time I've heard about Tizen in the press Samsung has made a big deal about HTML5 being the development platform. How do these two development platforms play together? Also can you provide any information about when we can expect to see the first Tizen phones hitting the US?

I hadn't seen it at the time of posting either, but have now. It did have longer action scenes than I was expecting, but I didn't have trouble keeping up with it at 24fps (the 3D 48fps showings around here have been sold out).

Jackson has stated that they used post processing to do the 48 to 24 down-conversion rather than just dropping frames. And many (most?) films these days perform color correction in post processing. I would expect that anyone who is making the jump to 48fps digital won't be shy of using modern digital post processing.

Agreed. Which is why I don't think the Hobbit was the best film to introduce high framerate. Transformers or any other action flicks with "jumbled mess of motion that you can't follow" scenes would have done a much better job of showcasing the technology.

Post processing by averaging frames is definitely practical, especially as these were shot on digital cameras to begin with. Of course, you loose most of the benefit of the higher frame rate if you do that, but it is entirely possible if they decide they don't like the raw results.

Lets consider two scenarios here.

In the first case, the camera is not panning, but just filming the scenario as it is, and projector playing it back at the filmed rate. Thus viewing the projection is the same experience as looking at the scene in real life, to within the fidelity of the playback. Notably, there is no depth (or a poor simulation of depth with forced focus), but apart from that higher fidelity should be more realistic. The viewer's eyes will be jumping around the big screen and blinking just like normal so there is absolutely no reason to try to "simulate" that; you have the real-life effect already occurring. Same with motion blur; the eye will supply the same amount of blur that it does in real life, so there is no reason to simulate it, beyond compensating for too *low* of a frame rate, which requires a longer integration time to avoid appearing choppy.

And yet it is exactly this sort of scene that was causing people to deride 48fps as being "soap opera like". They talked about how watching the Hobbits slowly walk down the hill towards them looked epic in 24fps, and looked like a documentary in 48fps. It destroyed the suspension of disbelief for them, and made them think they were looking at actors not Hobbits. That has nothing to faking limitations of human vision. It is completely psychological; whether that psychological effect is inherent in the medium or the result of prior conditioning is debatable, though.

The second scenario is where the camera is panning, and thus forcing visual motion on the user even though they didn't initiate it. This is identical to being smoothly flown around a scene, and how "realistic" it is will depend on whether that would actually happen in real life. In situations where it is realistic my argument above would apply; the eye will be looking around the moving scene just like it would be when looking out a train window.

On the other hand, in situations where panning is being used to simulate human motion, I would argue that 48fps could allow the filmmaker to have more realistic view changes if they want them. Low rate 24fps forces the director to have slow gradual pans less they create a choppy or blurry mess as a result in the limitations of the rate. However, as you pointed out, the eye doesn't work that way. It jumps around, taking time to settle and focus each time. If you tried to do that at 24fps the viewer would get lost, unable to follow the transitions. In large part this is because in real life they are controlling the transitions so they know in advance where the view is changing to, but to a lesser extend this is due to the limitations of the frame rate. Faster frame rates will allow for more abrupt translations that are still possible to follow.

And should the HFH and ACLU and all the other newsletters I subscribe to be blocked as spam as well? They send far more than 400k emails a month. Email is more convenient than RSS or worse Twitter, and is newsletters are a perfectly legitimate use of the medium.

Because those 31 64-core piledriver machines won't be able to push the same amount of IO as 1000 2-core Atom machines.
These things aren't for compute intensive tasks. Intel's own advertising comparing to Xeons show the Atoms having twice the performance-per-watt for scale-out tasks, but half the performance-per-watt for compute intensive tasks. It is about providing another option to better match the processor to the task. And it is here today while 64-bit ARM is still a year into the future.

No he's right. On the desktop Safari and Chrome both use heavily modified versions of webkit for rendering, and they use completely different javascript engines. On iOS Chrome is forced to use the exact same webkit as Safari and a crappy interpreted javascript engine, rather than V8 (it's own JIT engine) or even Nitro (Safari's JIT engine). Chrome is prevented from changing anything that matters for the browser so it really is just a skin of UIWebView.

If this happens, it will be using BGA pads which is fairly difficult to solder at home.

What if I do like the contract, but they break it? Then I go to court to resolve the matter. Oh, wait I can't, I have to go to arbitration, where the result is already determined against me.

If a contract isn't enforceable by law than it isn't a contract anymore. It is a bundle of official looking lies with no weight. Such a thing is unconscionable. It violates the very foundation of market based societies of law, and is tantamount to fraud.

While very little of NASA's work is classified, the vast majority of their technical work is covered by ITAR and export control laws, and has to be protected from dissemination outside of the US. Export control can be very over-reaching, and needs to have a major overhaul, however some of the restrictions are on things that could easily be militarized.

Well the reality is that 200 million Chinese manage to generate the carbon footprint of 300 million US Americans while the other 1.1 billion Chinese generate very little. Both the US and China need to get their shit together, while India should be commended for being able to ramp up their economy without generating so many greenhouse gases. For bargaining purposes, a more fair arrangement is to agree to a limit of X tons/person + Y tons/GDP.

It's much more murky than that. In the end what matters is whether the proprietary work is considered a derivative work as interpreted by the courts in various countries. Different people, including different Linux contributors have different opinions on what constitutes a derivative work. Some believe that anything that links against GPL code is a derivative work. In fact this was/is the belief if the GPL authors, otherwise the LGPL wouldn't have been needed. Others don't have a problem with proprietary drivers. It turns out that the original author's intent is fairly important in determining whether infringement is willful, and to a lesser extent whether infringement occurred at all. So EXPORT_SYMBOL_GPL was created to allow individual contributors to express their intent that only GPL compatible code cannot be linked against those symbols. From the legal arguments I've read this makes the question of whether infringement was willful or not pretty clear cut, but it doesn't have nearly as much bearing on whether infringement occurred or not. For more details, read some of Alan Cox's posts on this matter (in this thread and elsewhere).

That said, your interpretation of what those headers mean is very common, and has created a lot of confusion and misinformation, hence my subject title.

Except RTS is in full agreement that they are using modules containing code committed by third parties, including those that Andy has pointed out. They have not disputed this at all. What is in dispute is whether combining their proprietary module with the GPL kernel and other GPL modules and is a GPL violation. They are pushing the boundary of the "using APIs is not a derivative work" argument to it's limits.