(I'm no nuclear scientist so the following is what I've found after googling for a bit.)
That map is measuring in milli-roengen per hour which is a unit of Exposure, the nature article is talking about micro-sieverts which is a Equivalent Absorbed Radiation Dose measurement. The difference is basically that roengen is measuring how much energy something is beaming out, the Absorbed Dose is how much energy (of that type) human tissue absorbs, and equivalent dose is a normalized measurement of how much damage an absorbed dose does to living tissue.
To rephrase, the chart you linked is talking about how much light is given out at a specific point. The absorbed dose is how much of that light is converted to heat as it interacts with your skin. And the Equivalent dose is talking about what that heat is doing to your body.
There are ways to convert between these units but I'm guessing it depends on what type of radiation you're talking about.
It's also worth mentioning that Google has done some work to help developers with compatability. There was a talk about it on IO this year as well: Google I/O 2012 - Multi-Versioning Android User Interfaces (http://www.youtube.com/watch?v=amZM8oZBgfk).
I own a Drobo FS and would recommend that you get something else. (I've read good things about Synology, but haven't tried it myself nor do I personally know anyone who has tried it.)
It's pretty slow (I rarely get over 20MB/s read or write over gigabit ethernet) and the way they handle "applications" is pretty scetchy and seems a bit problematic. A few times applications have stopped responding and I've had to reboot the Drobo.
You also need a Windows or OSX machine to get started. At least when I got it it was impossible to do the first configuration without the special software. After that you can do most of the work (but not all) over the web interface (which runs as one of the previously mentioned rather scetchy applications).
It has noticed and warned me when a drive failed though. So that was nice. I'm not entirely sure that the "self healing" did the work properly though as some videos have seemed a bit wonky afterwards. (The entire point of self healing is to avoid bit rot.) Really I'd rather use a good established system for that (like ZFS or perhaps Btrfs) than something "home grown" where they keep the details secret.
For anyone interested in this I recommend taking a look at Shut Up & Sit Down (http://www.shutupshow.com/). It's a pretty funny show where they review a couple of board games with a specific theme ever episode. Well worth watching and they tend to be pretty funny as well.
If you use the simplistic style of raytracing then yes, but there are many additions which make it possible to do extremely realistic scenes.
The fundamental problem is that ray tracing is only half of the puzzle. Typically you trace from each pixel on a "screen" into the 3d scene and look at where that ray intersects with an object. You then calculate the color of the object at that point and this becomes the color of that pixel on the screen. (In a real scenario you typically calculate multiple rays per pixel.)
The problem is how you calculate the color, with simple algorithms (such at color of the surface and distance and angle to the nearest light-source) then the effect is not very realistic. But global illumination methods like photon mapping (where you basically first run a ray tracing from all light sources which "light" the scene and then run a screen ray tracing and use the data from the first run to calculate the color of pixels become a lot more advanced) or image based rendering (where you use an HDR image as a light source) can produce very good results.
There is a reason why most professional rendering is done using ray-tracing techniques. It may be slow, but if you can trade speed for quality you can get very realistic results.
I think the term you're looking for regarding "normal" graphics cards is "rasterising". Both rasterisation and ray-tracing are examples of rendering, which is the general term for turning data into an image. (Typically 3D data onto a 2D screen.)
Intel have been trying this technique of putting x86 cores on a board for quite some time now. But they still seem to be struggling to figure out a good use for them. One thing traditional GPUs have going for them is that they are rather dumb and limited in their capabilities. They basically do a lot of calculations, very fast, and that's it. Intel is obviously hoping that their "one trick pony" x86 will be able to do some new things here. But in the end you have a limited amount of transistors and at least so far putting lots of more limited GPU cores on there have outperformed putting fewer more complex x86 cores there instead.
If you want more on this topic PCPer did a few interviews with John Carmack on this topic. First one in 2008 regarding rasterisation vs raytracing (http://www.pcper.com/reviews/Graphics-Cards/John-Carmack-id-Tech-6-Ray-Tracing-Consoles-Physics-and-more, there is a podcast for that too which I recommend). Back then Carmack talks about the possibilities of a combined raytracer and rasteriser. (Because a rasteriser is a lot more efficient, and for most of the things in a game you will not see much of a difference.) There is also one from last year (http://www.pcper.com/reviews/Editorial/John-Carmack-Interview-GPU-Race-Intel-Graphics-Ray-Tracing-Voxels-and-more, there is a video for that online as well) where he has updated his research a bit. And Carmacks speech at QuakeCon is also interesting if you want to hear more (http://www.youtube.com/watch?v=00Q9-ftiPVQ).
Well worth reading/watching/listening to if you want a more critical view on the possibilities of these (and other future) technologies.
You mean struggling to build enough units of the previous version to keep it on shelves? (http://www.tgdaily.com/mobility-features/55579-asus-eee-transformer-sold-out-on-best-buy)
It seems like the version has some problems but it also seems like ASUS acknowledged them and delayed the launch. Hopefully they will be fixed on the devices which reach consumers.
The article (and report) conclude that "24 percent of 16-74 year olds across the 27 countries in the European Union have never accessed the Internet". Meanwhile in the parts of the EU with the highest Internet use (such as in the Scandinavian countries) the rate of Internet access (ie people who actively use the Internet, not people who've used it only once) is in the 90%.
I would assume part of the reason for the statistic is that 16-74 is a pretty big age span. Particularly when it comes to new technology. It wouldn't surprise me if the "never used internet" population is almost entirely in the 50+ age bracket. Unfortunately the article, and report, doesn't give that information.
Because that's the point of the HAL: Hardware Abstraction Layer. To software running above the HAL everything looks like normal. But the HAL and the stuff underneath make sure that's the case.
Often the drivers will handle the nitty-gritty details of how to communicate with the hardware and the HAL will call the driver (and other systems) to fulfill the API defined by the common HAL interface.
I work with camera stuff, but other systems have similar behavior. So if you're playing a video file you want that to be routed to your super-fast hardware chip. But in order to use it you need the HAL to set it up properly (different chips behave in different ways) and then handle feedback to the UI and stuff like that.
I'd recommend anyone interested in complex computer systems to take a look inside Android. It's way more complex than you'd expect at first. But quite a lot of fun.:-)
I have found many problems in CM releases that would typically not have made it into a real manufacturers release. (Eg, on a my Desire HD I find that sometimes the "open application tray" button disappears every now and then.)
And manufacturers do have internal beta tests, that's why sometimes prototypes are found in bars and other places.:-)
It is quite hard to develop software on hardware that isn't finished with drivers and an OS that isn't finished. And to do it in typically very short time as well. (Not saying that customers should accept buggy phones though, that pisses off me as well when it happens.)
(And yes, I work as a mobile phone developer. But not at a company making phones.)
Fascinating that none of the articles mention that the dudes are virtual as well. And they don't use any guys in the example images either. (If you visit the HM website it's easy to find some obvious body-doubles for swimming trunks.)
Focusing on issues with body images is not necessarily a bad thing, but only focusing on women is a bit sexist IMHO. Kind of ironic considering that's the drum they are banging on.
There is a guide for Android X86 on VirtualBox on their wiki (http://www.android-x86.org/documents/virtualboxhowto).
I've tried Gingerbread and Honeycomb before and they work reasonably well. (OpenGL isn't well implemented yet, so Honeycomb and likely ICS will have some performance problems.) I haven't tried to use them as emulator replacements though, not sure how much work it is to actually make it possible to get ADB working with Android X86 in VirtualBox.
Just make sure you disable "Enable absolute pointing device" in the VirtualBox motherboard settings to get the mouse to work.
Previously I've used the Eee PC build of Android to get it to work, I haven't tried getting the ICS port to work in VB yet (there isn't a Eee PC build of it yet).
One alternative use for this is to use it as a "simulator" for developing Android applications.
The emulator that is included in Android SDK really emulates ARM code (it's actually running QEMU with ARM v5 code). The problem with this is that it's rather slow, even on high end computers. Anything that runs opengl is extremely slow and not usable.
The Android X86 project makes it possible to run Android in eg VirtualBox. You can then test applications in a much better environment. (Well, currently OpenGL still doesn't work, but it's a work in progress.) Since this is actually running the full Android environment, but compiled for X86, it's possible to get pretty close to real Android behavior on the system.
So that's one nice benefit of the system. Otherwise I imagine that it could be useful to run Android on an old netbook which has problems running a full OS. (And to be frank, many netbooks with Atom seems to have this problem. At least mine does.)
Good news everyone! (Actually, it is pretty good news.)
It seems like the Hobbit will be filmed in 48 FPS (http://www.variety.com/article/VR1118035338) and IIRC Cameron has said that his next project will also be higher than 24 FPS. And any movie that isn't heavily relying on special effects should have a fairly easy time to go into 48+FPS. (For special effects heavy movies twice the frames will mean twice the work, at least to some extent.)
I think it will be interesting to see the fallout of these attempts. No doubts a lot of cinemaphiles will get upset. But they tend to be perpetually upset that things change. (3D! Digital! Surround sound! Color! Sound! Motion!)
This might be considered a slight spoiler, or just a hint of what to come..
We've seen TARDIS-like consoles in two episodes. The first was in the Lodger, in the "upstairs apartment" where people were being zapped while being forced to try to power the ship. The second time was in The Day of the Moon, in the sewers with the Silence.
In the confidential to the day of the moon they mentioned that the console room used by the silence is in fact the same set as in the lodger. (But more gritty.) So it's not impossible that there will be a callback to that in future episodes.
I was very anxious to see the first ending in the Moffat led show (with Matt Smith and Karen Gillian). My main gripe with RTD's series enders where that they always tended to be quite cheap.
If you haven't seen it yet I'll only say that it was one of my favorite pieces of 1 hour television ever. After the opening when one of the main characters say "Right, this is where it gets a bit complicated." follows 50 minutes of brilliance.
And while those 50 minutes are quite complicated (certainly more complicated than what eg Inception managed in 2.5 hours) it's not hard to keep up because the viewer is given small clues all the time. This is rather well explained by Moffat in the Confidential for that episode, where he points out that if the viewer understand what is going to happen right before it happens, they have no problem following along.
I also really like that Moffat is very fond of turning the ordinary and close to us into a monster. In "the empty child"/"the doctor dances" it's a small boy in a gas mask. In the "girl in the fireplace" it's a ticking clock in your room. In "silence in the library"/"forest of the dead" it's shadows. Blink has gothic statues and now we have the silence.
In a way the Daleks and Cybermen are like supervillans. They may be hellbent on destroying you, but you always know where they are because they put up a big show. The horrors that lurk in the corner of your eye, you're never really sure if they are gone...
The reason for this is actually to put the spotlight on some new Swedish childpornography laws.
It used to be that there were no age limit on child pornography, basically pornographic material of people who were not sexually mature was child pornography. That was changed due to pressure from the EU to add the 18-yo limit as well. (Basically, this makes pornography of people who are sexually mature, but under the age of 18, NOT child pornography unless is explicitly states that they are under 18.)
In Sweden there is also a law that drawings of children can also be considered child pornography (under the same rules) in order to not incite child predatory behaviour.
The DOA games have existed before in Scandinavia, but in this new games there is a "camera" mode (with up skirt potential). And the characters have their "ages" written out.
So one guy on a Swedish forum decided to inform the police of this potential child porn in order to test the law. (Previously a swedish manga translator has been charged with possession of child porn under the same law.) After this the Scandinavian Nintendo distributor decided to not carry the game. The guy who contacted the police was informed (by them) that they did not consider it child porn.
I think his point was that your manager was obviously willing to work and improve. Since he actually became good at the job he was not clueless and incompetent.
Just as there are employees who can be trouble makers there are managers who can be the same. The problem is that an incompetent developer will typically only look bad himself, but an incompetent manager will make everyone "underneath" them look bad.
I'd say one legitimate reason to actually talk about it with your coworkers is as a form of collective group therapy.
Working somewhere where you don't trust your leadership is extremely demoralizing. Talking about this with your coworkers can help the situation. (And perhaps they'll give you insight into things you hadn't thought of.)
Although it might be a bit of culture difference as well. Some cultures seem to put more effort into "do what the boss tells you" even if you know it's wrong. Personally I think that borderline irresponsible behavior from an employee to silently march into machine gun fire.
This method (like all motion compensating algorithms) can correct for some motion blur but it will add other defects to the image. So while it might "save" a picture already captured it's better to take a new photo.
I'm pretty sure that I saw people doing this on the Meant to be seen DIY forums (http://mtbs3d.com/phpBB/viewforum.php?f=26) quite some time back. In that case they did use two different consoles plugged into the different machines of course; and they used polarized glasses. It might be that this is supposed to be a complete system for it. (All the way from console rendering the frames to syncing the glasses.)
As an aside I can recommend anyone who has access to an old "silver screen" to make their own 3D projector setup. Just bring a couple of disposable 3D glasses from a movie, tear one pair apart and put the different glasses over two different projectors. (It seems like you need DLP projectors as LCD tend to have different polarization on the different colors.) (And if you separate the lenses completely you could make your own set of "split screen glasses" to play.)
Slashdot Mirror
(I'm no nuclear scientist so the following is what I've found after googling for a bit.)
That map is measuring in milli-roengen per hour which is a unit of Exposure, the nature article is talking about micro-sieverts which is a Equivalent Absorbed Radiation Dose measurement. The difference is basically that roengen is measuring how much energy something is beaming out, the Absorbed Dose is how much energy (of that type) human tissue absorbs, and equivalent dose is a normalized measurement of how much damage an absorbed dose does to living tissue.
To rephrase, the chart you linked is talking about how much light is given out at a specific point. The absorbed dose is how much of that light is converted to heat as it interacts with your skin. And the Equivalent dose is talking about what that heat is doing to your body.
There are ways to convert between these units but I'm guessing it depends on what type of radiation you're talking about.
It's also worth mentioning that Google has done some work to help developers with compatability. There was a talk about it on IO this year as well: Google I/O 2012 - Multi-Versioning Android User Interfaces (http://www.youtube.com/watch?v=amZM8oZBgfk).
I own a Drobo FS and would recommend that you get something else. (I've read good things about Synology, but haven't tried it myself nor do I personally know anyone who has tried it.)
It's pretty slow (I rarely get over 20MB/s read or write over gigabit ethernet) and the way they handle "applications" is pretty scetchy and seems a bit problematic. A few times applications have stopped responding and I've had to reboot the Drobo.
You also need a Windows or OSX machine to get started. At least when I got it it was impossible to do the first configuration without the special software. After that you can do most of the work (but not all) over the web interface (which runs as one of the previously mentioned rather scetchy applications).
It has noticed and warned me when a drive failed though. So that was nice. I'm not entirely sure that the "self healing" did the work properly though as some videos have seemed a bit wonky afterwards. (The entire point of self healing is to avoid bit rot.) Really I'd rather use a good established system for that (like ZFS or perhaps Btrfs) than something "home grown" where they keep the details secret.
There is quite a lot of material he's made on YouTube (and one of his records is on Spotify).
Eg his interview on Conan is often linked online regarding entitlement: http://www.youtube.com/watch?v=8r1CZTLk-Gk (Everything is amazing and nobody is happy).
For anyone interested in this I recommend taking a look at Shut Up & Sit Down (http://www.shutupshow.com/). It's a pretty funny show where they review a couple of board games with a specific theme ever episode. Well worth watching and they tend to be pretty funny as well.
If you use the simplistic style of raytracing then yes, but there are many additions which make it possible to do extremely realistic scenes.
The fundamental problem is that ray tracing is only half of the puzzle. Typically you trace from each pixel on a "screen" into the 3d scene and look at where that ray intersects with an object. You then calculate the color of the object at that point and this becomes the color of that pixel on the screen. (In a real scenario you typically calculate multiple rays per pixel.)
The problem is how you calculate the color, with simple algorithms (such at color of the surface and distance and angle to the nearest light-source) then the effect is not very realistic. But global illumination methods like photon mapping (where you basically first run a ray tracing from all light sources which "light" the scene and then run a screen ray tracing and use the data from the first run to calculate the color of pixels become a lot more advanced) or image based rendering (where you use an HDR image as a light source) can produce very good results.
There is a reason why most professional rendering is done using ray-tracing techniques. It may be slow, but if you can trade speed for quality you can get very realistic results.
I think the term you're looking for regarding "normal" graphics cards is "rasterising". Both rasterisation and ray-tracing are examples of rendering, which is the general term for turning data into an image. (Typically 3D data onto a 2D screen.)
Intel have been trying this technique of putting x86 cores on a board for quite some time now. But they still seem to be struggling to figure out a good use for them. One thing traditional GPUs have going for them is that they are rather dumb and limited in their capabilities. They basically do a lot of calculations, very fast, and that's it. Intel is obviously hoping that their "one trick pony" x86 will be able to do some new things here. But in the end you have a limited amount of transistors and at least so far putting lots of more limited GPU cores on there have outperformed putting fewer more complex x86 cores there instead.
If you want more on this topic PCPer did a few interviews with John Carmack on this topic. First one in 2008 regarding rasterisation vs raytracing (http://www.pcper.com/reviews/Graphics-Cards/John-Carmack-id-Tech-6-Ray-Tracing-Consoles-Physics-and-more, there is a podcast for that too which I recommend). Back then Carmack talks about the possibilities of a combined raytracer and rasteriser. (Because a rasteriser is a lot more efficient, and for most of the things in a game you will not see much of a difference.) There is also one from last year (http://www.pcper.com/reviews/Editorial/John-Carmack-Interview-GPU-Race-Intel-Graphics-Ray-Tracing-Voxels-and-more, there is a video for that online as well) where he has updated his research a bit. And Carmacks speech at QuakeCon is also interesting if you want to hear more (http://www.youtube.com/watch?v=00Q9-ftiPVQ).
Well worth reading/watching/listening to if you want a more critical view on the possibilities of these (and other future) technologies.
You mean struggling to build enough units of the previous version to keep it on shelves? (http://www.tgdaily.com/mobility-features/55579-asus-eee-transformer-sold-out-on-best-buy)
It seems like the version has some problems but it also seems like ASUS acknowledged them and delayed the launch. Hopefully they will be fixed on the devices which reach consumers.
The article (and report) conclude that "24 percent of 16-74 year olds across the 27 countries in the European Union have never accessed the Internet". Meanwhile in the parts of the EU with the highest Internet use (such as in the Scandinavian countries) the rate of Internet access (ie people who actively use the Internet, not people who've used it only once) is in the 90%.
I would assume part of the reason for the statistic is that 16-74 is a pretty big age span. Particularly when it comes to new technology. It wouldn't surprise me if the "never used internet" population is almost entirely in the 50+ age bracket. Unfortunately the article, and report, doesn't give that information.
Because that's the point of the HAL: Hardware Abstraction Layer. To software running above the HAL everything looks like normal. But the HAL and the stuff underneath make sure that's the case.
Often the drivers will handle the nitty-gritty details of how to communicate with the hardware and the HAL will call the driver (and other systems) to fulfill the API defined by the common HAL interface.
I work with camera stuff, but other systems have similar behavior. So if you're playing a video file you want that to be routed to your super-fast hardware chip. But in order to use it you need the HAL to set it up properly (different chips behave in different ways) and then handle feedback to the UI and stuff like that.
I'd recommend anyone interested in complex computer systems to take a look inside Android. It's way more complex than you'd expect at first. But quite a lot of fun. :-)
I have found many problems in CM releases that would typically not have made it into a real manufacturers release. (Eg, on a my Desire HD I find that sometimes the "open application tray" button disappears every now and then.)
And manufacturers do have internal beta tests, that's why sometimes prototypes are found in bars and other places. :-)
It is quite hard to develop software on hardware that isn't finished with drivers and an OS that isn't finished. And to do it in typically very short time as well. (Not saying that customers should accept buggy phones though, that pisses off me as well when it happens.)
(And yes, I work as a mobile phone developer. But not at a company making phones.)
Fascinating that none of the articles mention that the dudes are virtual as well. And they don't use any guys in the example images either. (If you visit the HM website it's easy to find some obvious body-doubles for swimming trunks.)
Focusing on issues with body images is not necessarily a bad thing, but only focusing on women is a bit sexist IMHO. Kind of ironic considering that's the drum they are banging on.
There is a guide for Android X86 on VirtualBox on their wiki (http://www.android-x86.org/documents/virtualboxhowto).
I've tried Gingerbread and Honeycomb before and they work reasonably well. (OpenGL isn't well implemented yet, so Honeycomb and likely ICS will have some performance problems.) I haven't tried to use them as emulator replacements though, not sure how much work it is to actually make it possible to get ADB working with Android X86 in VirtualBox.
Just make sure you disable "Enable absolute pointing device" in the VirtualBox motherboard settings to get the mouse to work.
Previously I've used the Eee PC build of Android to get it to work, I haven't tried getting the ICS port to work in VB yet (there isn't a Eee PC build of it yet).
One alternative use for this is to use it as a "simulator" for developing Android applications.
The emulator that is included in Android SDK really emulates ARM code (it's actually running QEMU with ARM v5 code). The problem with this is that it's rather slow, even on high end computers. Anything that runs opengl is extremely slow and not usable.
The Android X86 project makes it possible to run Android in eg VirtualBox. You can then test applications in a much better environment. (Well, currently OpenGL still doesn't work, but it's a work in progress.) Since this is actually running the full Android environment, but compiled for X86, it's possible to get pretty close to real Android behavior on the system.
So that's one nice benefit of the system. Otherwise I imagine that it could be useful to run Android on an old netbook which has problems running a full OS. (And to be frank, many netbooks with Atom seems to have this problem. At least mine does.)
There's an article on Wired on why this kraken "science" is complete bullshit and an indication of the sad state of scientific "reporting".
http://www.wired.com/wiredscience/2011/10/the-giant-prehistoric-squid-that-ate-common-sense/
Good news everyone! (Actually, it is pretty good news.)
It seems like the Hobbit will be filmed in 48 FPS (http://www.variety.com/article/VR1118035338) and IIRC Cameron has said that his next project will also be higher than 24 FPS. And any movie that isn't heavily relying on special effects should have a fairly easy time to go into 48+FPS. (For special effects heavy movies twice the frames will mean twice the work, at least to some extent.)
I think it will be interesting to see the fallout of these attempts. No doubts a lot of cinemaphiles will get upset. But they tend to be perpetually upset that things change. (3D! Digital! Surround sound! Color! Sound! Motion!)
This might be considered a slight spoiler, or just a hint of what to come..
We've seen TARDIS-like consoles in two episodes. The first was in the Lodger, in the "upstairs apartment" where people were being zapped while being forced to try to power the ship. The second time was in The Day of the Moon, in the sewers with the Silence.
In the confidential to the day of the moon they mentioned that the console room used by the silence is in fact the same set as in the lodger. (But more gritty.) So it's not impossible that there will be a callback to that in future episodes.
I was very anxious to see the first ending in the Moffat led show (with Matt Smith and Karen Gillian). My main gripe with RTD's series enders where that they always tended to be quite cheap.
If you haven't seen it yet I'll only say that it was one of my favorite pieces of 1 hour television ever. After the opening when one of the main characters say "Right, this is where it gets a bit complicated." follows 50 minutes of brilliance.
And while those 50 minutes are quite complicated (certainly more complicated than what eg Inception managed in 2.5 hours) it's not hard to keep up because the viewer is given small clues all the time. This is rather well explained by Moffat in the Confidential for that episode, where he points out that if the viewer understand what is going to happen right before it happens, they have no problem following along.
I also really like that Moffat is very fond of turning the ordinary and close to us into a monster. In "the empty child"/"the doctor dances" it's a small boy in a gas mask. In the "girl in the fireplace" it's a ticking clock in your room. In "silence in the library"/"forest of the dead" it's shadows. Blink has gothic statues and now we have the silence.
In a way the Daleks and Cybermen are like supervillans. They may be hellbent on destroying you, but you always know where they are because they put up a big show. The horrors that lurk in the corner of your eye, you're never really sure if they are gone...
The reason for this is actually to put the spotlight on some new Swedish childpornography laws.
It used to be that there were no age limit on child pornography, basically pornographic material of people who were not sexually mature was child pornography. That was changed due to pressure from the EU to add the 18-yo limit as well. (Basically, this makes pornography of people who are sexually mature, but under the age of 18, NOT child pornography unless is explicitly states that they are under 18.)
In Sweden there is also a law that drawings of children can also be considered child pornography (under the same rules) in order to not incite child predatory behaviour.
The DOA games have existed before in Scandinavia, but in this new games there is a "camera" mode (with up skirt potential). And the characters have their "ages" written out.
So one guy on a Swedish forum decided to inform the police of this potential child porn in order to test the law. (Previously a swedish manga translator has been charged with possession of child porn under the same law.) After this the Scandinavian Nintendo distributor decided to not carry the game. The guy who contacted the police was informed (by them) that they did not consider it child porn.
You can find the discussion at Flashback (in Swedish): https://www.flashback.org/t1525412
I think his point was that your manager was obviously willing to work and improve. Since he actually became good at the job he was not clueless and incompetent.
Just as there are employees who can be trouble makers there are managers who can be the same. The problem is that an incompetent developer will typically only look bad himself, but an incompetent manager will make everyone "underneath" them look bad.
I'd say one legitimate reason to actually talk about it with your coworkers is as a form of collective group therapy.
Working somewhere where you don't trust your leadership is extremely demoralizing. Talking about this with your coworkers can help the situation. (And perhaps they'll give you insight into things you hadn't thought of.)
Although it might be a bit of culture difference as well. Some cultures seem to put more effort into "do what the boss tells you" even if you know it's wrong. Personally I think that borderline irresponsible behavior from an employee to silently march into machine gun fire.
Is it a requirement for a tech reporter to be completely clueless?
No; but it helps.
This method (like all motion compensating algorithms) can correct for some motion blur but it will add other defects to the image. So while it might "save" a picture already captured it's better to take a new photo.
From reviews it seems like the Bamboo pads don't work very well for touch input. They are glitchy and produce bad input data.
I'm pretty sure that I saw people doing this on the Meant to be seen DIY forums (http://mtbs3d.com/phpBB/viewforum.php?f=26) quite some time back. In that case they did use two different consoles plugged into the different machines of course; and they used polarized glasses. It might be that this is supposed to be a complete system for it. (All the way from console rendering the frames to syncing the glasses.)
As an aside I can recommend anyone who has access to an old "silver screen" to make their own 3D projector setup. Just bring a couple of disposable 3D glasses from a movie, tear one pair apart and put the different glasses over two different projectors. (It seems like you need DLP projectors as LCD tend to have different polarization on the different colors.) (And if you separate the lenses completely you could make your own set of "split screen glasses" to play.)