N00b question: Can't you just compare the hashes of the shipped binaries and the ones you compiled from the sources you're reviewing to check that they match?

There's a bunch of different criteria you might use, such as how much they play, how many games they buy or how much money they spend, but I would define as gamers people who self-identify as gamers. I strongly doubt all the women in that data consider themselves gamers.

Taking down someone else's past work right when they're trying to get funding for their next project? Absolutely abhorrent behavior by Sony. If you want to help the BF dogfood Blender on an actual feature film project, you can pledge on gooseberry.blender.org. All of the film's production files will be open sourced after it's done :)

That's a rather inaccurate statement. Apple has declared they'd work with the Blender devs to get the Cycles OpenCL render backend to compile at all on AMD's dodgy OpenCL compiler implementation. The Cycles OpenCL backend has been working fine with both Nvidia and Intel OpenCL compilers for over two years now, but it has never worked on AMD. AMD has been in contact with Blender devs for a long time, but so far they haven't managed to improve the compiler situation at all. No extraordinary effort is going on to optimize Blender in general that would not benefit Blender users on all platforms.

I read it thrice and still can't figure it out. Like what? Wifi? Bluetooth?? How is the use or non-use of wires relevant at all?

Which is why you need native HDR sensors. Like these: http://www.new-imaging-technologies.com/news/33-new-product-announcement--nsc0905fo-an-hdr-sensor.html

I actually meant half precision 16-bit float per channel. More is always nice, but the kind of sensors you can put 36 of in a throw ball are not precise enough anyway. And you're just going to be using this for lighting anyway.

As long as this takes HDR photos, this would be immensely useful for 3d graphics work. And no, I don't mean the useless bad-HDR-lookalike postprocessing found in phones. I mean real, honest to goodness 16-bit, not-viewable-on-most-screens HDR.

Actually, I was curious so I did it. 1.8 GB. Worked fine if slightly sluggish in the Tab Groups view. Now somebody try the same thing with Chrome.

Making the user responsible? That's ridiculous. When you're running a business it doesn't matter that Jane the receptionist is "responsible" for accidentally leaking out your next year's product designs, by that point the damage is done. You want an OS and security procedures that make her incapable of doing any damage to your company.

Monitor switching is a nice idea, but it also doesn't work because it disallows any drag-and-drop actions. Like dragging a layer from one monitor to another. And if I am to keep my tools on my primary monitor, I'd like them nicely organized so that they don't waste so much space. Single window mode does some of that. Actually, what I'd really like is customizable tool shelves where I can put my often-used tools from various windows and contexts and just turn everything else off most of the time. But I guess that's just too radical a concept for GIMP (and Photoshop too).

You're missing cases where you have data other than an actual image that you want to manipulate. Like a heightmap.

I have two monitors too and moving tools to the second one doesn't work for a single reason - you have to reach your tools with your pointer. Now, as long as you don't mind waving your mouse-arm like a madman every two seconds it's ok. But as soon as you pick up your stylus you're faced with the hard choice of either squeezing your two monitors into your tablet's space, effectively dividing its useful surface area by a factor of about 2.5 to 4, or confining the cursor to one of the monitors, in which case you can't reach your tools with your stylus. It means that for any tablet-wielding professional multi-window mode is mostly useless. Effective UI hiding and workspace organization is vastly preferable.