I bought an AMD E-350 motherboard and a Chenbro case with 4 removable drive bays. It takes a slimline optical drive (which actually has a BD-RE drive, because they weren't much more expensive than DVD drives, although in the 3 years since I bought it I've yet to burn a single BD).
It's running FreeBSD, booting from a RAID-Z array (so cheap snapshots, block-level checksums, single drive failure recovery, and all of that good stuff). The GPU is now supported and so it runs XBMC connected to my projector for video playback too.
There's also an e-SATA port that I should be using for external backups, but am not currently...
That doesn't really make sense. The architectures of the three main GPU vendors are sufficiently different that it's highly unlikely that the can benefit much from tricks in the drivers (which are basically compiler optimisations these days, since the performance-critical part of the driver is the shader compiler). nVidia uses something that looks more or less like a scalar CPU (with some SIMD) but with SIMT so that if you run threads in lockstep they just do one decode but execute several steps at once. AMD is a VLIW-inspired design. Intel is a more classical SIMD architecture, but with the tweak that their vector register set is 2D and each operand encodes a start and a stripe size, so you can do vertical or diagonal stripes through the register set and don't have to do vector permutes. Intel and AMD put more of the parallelisation into the compiler (drivers) than nVidia, but the transforms that they do are quite different.
There's more of a chance that AMD drivers would help Broadcom than anyone else, but AMD and Broadcom aren't really in the same markets, especially since AMD sold Qualcomm their mobile GPUs (Radeon became Adreno)
Flat panel screens have the same yield issues as ICs (the process for creating them is vaguely similar). If you go from a 4" screen to a 8" screen, you quadruple the area, which quadruples the chance that there'll be a manufacturing error that will result in a dead / stuck pixel. This means that your yield drops by a factor of four.
Eventually, some one will figure out a way of creating really big panels and then cutting them to size, and then we'll have a large variety of screen sizes depending on where the defects happen to lie in a particular run.
300dpi for print is actually a lot lower than 300ppi for displays. Each dot for print is, depending on your technology, either black, cyan, magenta or yellow, or one of a very small (typically 4-16) shades of these colours. For a display, you have at least 2^16 shades of colour for each pixel. This is why the output from a 300dpi inkjet looks a lot worse than a 70dpi monitor. For print, you typically use 2400dpi, which comes close to approximating 300ppi.
Personally, I find you hit diminishing returns after about 200ppi. It's easy to tell 70-100ppi apart from 200ppi, but 400ppi is only better if you look really carefully. 600ppi is a marketing gimmick (and will need more frame buffer memory and more CPU power to use, so is likely to drain the battery faster). On the plus side, hopefully this will mean that the 225ppi panels will become cheaper and I'll be able to get a cheap phone with a nice screen...
Finally, people who go to Microsoft Research tend to disappear and never be heard of again. No one knows why.
That's only true if you never go to any computer science conferences: if you do, you'll find a lot of good papers written by MSR people. They do, however, have an appalling track record of turning them into products. This has improved a bit over the past few years, but until then MS and MSR were effectively run as two different companies and ideas from MSR were unlikely to be exploited in MS products.
The cynical explanation is that MSR exists to provide talented people with a well-funded sandbox where they will play and not create companies that compete with MS. The more likely explanation is that MSR has a budget of around $5bn annually, has separate premises, and does not provide any incentive to its employees to get their work into products.
Unix soit qui mal y pense [Unix to him who evil thinks?]