I know, and this problem has been solved for ages now (think christmas lights). All you need is a device in parallel with each LED that will deliberately fail short when exposed to higher voltage (an antifuse), in order to bypass the bad LED. Then you use current regulation for each string, so other LEDs aren't affected when one fails (the current going through them is still the same).
The issues aren't a result of the series string, they're a result of a poorly thought out design based on series strings.
I first watched Avatar on a theatre equipped with XpanD 3D. I don't know if it was the projector, the glasses, or a combination, but the colors with the glasses on looked like those produced by a really bad LCD monitor, only less bright. Everything was greenish, blacks were badly crushed, and the heavy shutter glasses really hurt the immersion. I kept taking them off in some scenes in order to be able to see darker areas!
I rewatched it on a theatre that used RealD 3D, and the experience was much better. It wasn't perfect (some judder), but at least it wasn't worse than consumer gear. If there's one thing I expect when going to the cinema it's at least reasonable display standards and calibration - otherwise I'd much rather just torrent it and watch it in the comfort of my house.
The LEDs are probably wired in series strings. If one fails open, the entire string fails. If one fails short, the rest are subject to more current and are more likely to fail.
This isn't a problem with LEDs, it's a problem with bad circuit design.
Except that surely it would be jarring in a different way to have all of this background noise but then not have the characters speak?
Not at all, you get used to it pretty quickly. What you can do is replace the voice with some gibberish noises. For example, Zelda games tend to use vocal "calls" (think "hey!", a laugh, or some other attention-calling noise) but then the actual dialogue is text. Quite a few RPGs just make some sort of semi-random gibberish noise as the dialogue text is being scrolled onto the screen. It all works pretty well. You don't have to hear actual voices to convince yourself that the characters are speaking.
700W is just for ridiculous gaming rigs. PCs don't actually use anywhere near the rated power of the PSU. Buying a decent power supply with a higher power rating is good because pushing a PSU to its limits is a recipe for trouble or disaster. I have a 620W PSU in my quad-core desktop (4 HDDs too), but real power usage is more like 100W idle, 150W with all CPUs running at their max. A gaming video card running at full throttle or two would start pushing the power envelope up, but I'm happy with an cheap nVidia as long as it does video decoding in hardware.
If you want power efficiency, get a desktop-replacement laptop. You'll have a near full-featured PC that runs on less than 90W with the CPU and GPU pegged. With some judicious power management you can easily get regular use in under 30W battery, or 40W or so from AC (the PSU has its own inefficiencies). And if you don't need the power of a desktop, just get a regular / smaller laptop and enjoy your sub-20W average power consumption. Actual AC power figures from my huge 18.4" 2-HDD dual-core desktop-replacement laptop: 80W max (maxed out CPU and GPU), 56W idle with no power saving, 44W with lower screen brightness and more power saving, and 40W with some extra power saving. Yes, we can compute with less than 50W just fine, and that includes the monitor.
You do want a video card that accelerates mpeg-2/h.264 video playback though. A 2.4GHz dual-core will NOT play some 1080p h.264 HD content at full speed, nevermind a 1Ghz single core. HD video decoding is a huge computational power hog. Dedicated decoding hardware is much more power efficient and effective.
I don't use my real name for login names (IRC etc.). Not because I want to hide it, just because I prefer to use my standard login name. It's worth noting that said nickname (which is actually "marcan" these days) is actually a contraction of my last names itself:-)
You'll see me using my real name for mailing lists and the like, and I'll type my name into the "real name" box of most sites, including Slashdot. I'm not sure if you can actually see it or not though, but on most places you can. The point is it isn't secret nor do I attempt to keep it a secret.
Slow down, my friend. ICs aren't created equal, and you can't just throw everything on one die. Processes can be vastly different and what is optimal for one IC isn't optimal for another. For example, you can't manufacture standard DRAM on a CPU process - RAM processes are vastly different as they need to create capacitors. WiFi needs specific RF circuitry and often requires external ICs with exotic processes for switching/etc (GaAs or silocon on sapphire). Bluetooth will probably still need some funky silicon structures, even if not as much as WiFi. Other external interfaces like DVI and Ethernet are often not worth integrating (then you get separate chips to perform the physical layer encoding, even if the control logic is embedded into your CPU).
Besides, on a PC, being able to mix and match hardware is critical to get flexibility. If you want integrated everything, go for a cheap netbook, or the newer ARM-based tablets/netbooks that will (hopefully) be coming out. Those already integrate many more things into one die. Systems like these already use SoC chips that implement many things in one; for example, I have an ARM single-board computer that's the size of a credit card. The CPU includes basic peripherals, an Ethernet MAC (no PHY though, that's a separate chip), memory controller, PowerVR SGX GPU, and many other things. The memory is physically soldered on top of the CPU (package-on-package technology), and it's actually a combo package with one 512MB Flash die and two 256MB RAM dies, so, in fact, the whole shebang is four silicon dies stacked on top of each other with a total height of about 2mm. However, WiFi and Bluetooth are on a separate Marvell multi-die module, because it includes parts made with a vastly different process. The DVI encoder is also separate (not everyone needs DVI, and TMDS encoders aren't worth integrating), and so is the Ethernet PHY (that also isn't easy/desirable to integrate). So the main ICs on this board are CPU+RAM, Ethernet PHY, DVI encoder, Wireless, and the power controller (which also integrates an USB 2.0 OTG PHY, the RTC, clock generator, and an audio codec). At this stage, I think this is plenty of integration. One die for everything would be more trouble than it's worth.
I use my real name most of the time (except for throwaway accounts), because quite frankly I don't like to appear as "hiding" behind an online nickname, and names aren't exactly sensitive information. Usually the only time I'm asked my address is when I want to buy something; 99% of the other cases it's scammy/spammy/throwaway sites that I'm typing junk info into anyway. As for birth date, I tend to make that up, but not always. I'm quite a bit less paranoid than most people I know though; e.g. if you want my address (feel free to send me cool stuff:P), all you have to do is perform a WHOIS lookup on my domain.
But really, it all boils down to not using public websites for private stuff. The only website that I use that can be considered to be a social networking site is Twitter, and I use it to engage in public conversation anyway. If I want to talk in private, I use e-mail or IRC, preferably on private servers. If I put something on-line, chances are I probably want you to be able to find it.
Server logs are logs of server activity. If no server activity is generated for certain user actions, why do you need logs? There's no fundamental difference between logs of user-visible URIs and logs of backend AJAX calls; in fact, AJAX API URIs can be made just as descriptive for server log purposes.
If you want to track user actions, then obviously you'll have to add an explicit tracking bug, which negates some of the advantages of dynamic sites without necessarily triggering server activity for each user action, but that's your choice.
but what about the millions who will be reassured by the url displayed and end up handing their banking credentials over?
What part of as long as the site portion remains the same did you miss? All you'll be able to change is the path portion within your site, which you already control anyway.
Ever since AJAX and DHTML, sites have had full control over what pages actually display, regardless of the URL they were accessed through. Websites can already manipulate the URL bar at will through javascript, it's just that those manipulations forcibly trigger a page reload. As long as the new URL remains within your site, you can show whatever you want for the new page.
Practically speaking, the only change is that now you can change the URL bar without triggering a from-scratch page load, which is great for AJAX apps. As long as the browser prevents you from forging a URL that appears to "leave" your site, this is no different from what we have now other than letting AJAX apps more easily use consistent URLs while minimizing or eliminating full page loads.
Horrible ads? Adblock/Flashblock. Flash cookies? Delete them. What people care about is, erm, having a Linux version of Flash that isn't a horrible smoking pile of excrement, performance- and stability-wise.
That's H.263, which is a horrible piece of crap. It's what youtube used before H.264 and they still do for the low-quality version of videos. There's no question that Theora beats the old flv H.263.
Sounds OK to me as long as the site portion remains the same. This isn't any different from other cross-site scripting or impersonation problems. For all I care sites can do whatever they want to the URL bar as long as the site-identificating portion remains constant.
That's a tricky question. Testing and finding bugs ought to allow you to put more trust in your testing methodology, which subsequently can increase your trust in your software once you stop finding bugs. Testing and finding no bugs, hard as you try, quite likely means you aren't trying hard enough. Very rarely will software reach a ceiling of reasonable test-proofness before being shipped that cannot be improved with subsequent, more dedicated, more specific testing after some issues are detected in the field.
The more (and better) you test without finding bugs (or the bugs you want), the higher your chances of the target bugs not existing. Finding other, unrelated bugs helps ascertain that you are, in fact, performing a useful level of testing. If Toyota had found, say, three or four controlled panic style bugs (caused by defensive programming) that would cause engine shutdown (which is probably safer than unintended acceleration) but nothing related to acceleration, then in my mind it would be better evidence against the acceleration bug existing in software. The types of bugs do matter though - finding flimsy memory corruption or race condition type bugs might instead mean that the code has been written without proper programming practices and might lower my trust on it.
Ultimately though, it's true that no level of testing can conclusively prove the absence of bugs.
Voltage is relative. A hollow coin will prevent anything inside it from being able to perceive any voltage potential difference. It doesn't matter if you plug the thing into a 120kV line as referenced to ground, the microSD card still won't feel a thing. So no, it doesn't need to be grounded.
The fourth generation of the iPhone is getting NFC/RFID capabilities, much like some other phones already have.
This isn't new. The only new thing they could possibly bring to the NFC table would be (gasp) actual security, given that RFID/NFC devices are notorious for being horribly insecure most of the time.
Which is still going to be just as unfair the only change is that it might be different people who are paying for nothing.
I submit that making ISPs pay the levy is fairer, as 1) they are the ones who profit directly from downloads, 2) people connecting to the Internet are more likely to correlate to people who download (especially with higher-speed connections, which are marketed quite blatantly as being for faster downloads), at least more so than levies on blank media. Blank media isn't a good match because many people download onto their computer's master hard drive (which isn't levied), many people require mass storage for things other than downloaded media (including companies), and blank media producers don't necessarily profit from downloads, at least not nearly as much.
Nothing will ever be 100% fair, because the premise is that you just cannot control distribution of audiovisual works. This is why the levies were introduced, back in the day when the government realized that they couldn't do anything against people copying music on cassette tapes, and instead levied the blank tapes.
No, because audiovisual works don't have EULAs, and even if they forced them upon buyers, a clause preventing you from legally sharing it noncommercially would probably not be enforceable.
As a copyrighted work, software is considerably different from just media.
Here's how it (roughly) works over here (Spain): - Audiovisual works can be shared noncommercially, but we pay levies on all kinds of media and copying devices (CD/DVD-Rs, hard drives, media players, cellphones) - Software is protected and P2P sharing of software is not legal
Now, there's a huge SNAFU going on here with our RIAA-equivalent (the SGAE), who are lying bastards and cheaters, the levy system isn't ideal (many people get charged who don't use P2P, and the devices/consumables that get levies are just stupid - I think it'd be better to charge levies on internet connections instead of consumables and devices), and the way the levies are distributed is completely backwards (SGAE execs have been known to use some privately, transparency is nil, and small artists get squat). Nonetheless, the basic premise isnt all that bad: legalize audio/video/book file sharing, but impose some reasonable sort of cash stream from the people very likely to use P2P to the people who very likely have their works shared.
You also need to realize that legalizing file sharing does not imply removing all copyright. All it says is that sharing copyrighted files is fine (authors have less control over how their work is distributed noncommercially), but it doesn't imply licenses are invalid: You still can't produce a GPL'd derivative work and not provide source, you still can't violate the attribution/share-alike/non-commercial provisions of Creative Commons, etc. I don't think anyone is seriously arguing that copyright should be abolished - there's a huge difference between that and just making the usual P2P scenarios legal.
It's in B&W without backlighting / in the sunlight. It's in full color with the backlight on and at moderate to low ambient light, and somewhere in between as you reduce the backlight level and increase the abient level. Which is pretty good, considering that most laptop screens are fairly unusable in direct sunlight.
Hunt and peck is the opposite of touch typing, but touch typing is not synonymous with "proper" typing technique. I never learned to type "properly", and I tend to use four fingers instead of five, but I don't look at the keyboard while typing and I can get over 100wpm (I just tested myself at 95wpm right now) - the fact that I don't look means I'm a touch typist, whether I use the "proper" technique or not. Obviously hunt-and-peck at over 100wpm is bullshit, but you can easily type at moderate to quite fast speeds even if your typing technique isn't "standard" or ideal.
The PS3 attack was very obvious (i.e. the hypervisor lives in external memory, essentially unsecured), and the Cell chip is fairly well documented itself. That's breaking security by obscurity (where obscurity is the high-speed memory bus), and isn't really comparable to what this article talks about. Also, it doesn't rely on tweaking CPU voltage to produce internal errors, but rather on glitching the memory bus. This is a lot easier, and has a (small - the PS3 hack as performed by geohot is highly unpredictable) chance of working and not screwing up the rest of the system (as long as the rest of the system is essentially quiescent). Keep in mind that the PS3 attack also relies on privilege escalation; it wouldn't work at all if you couldn't already run your own code under the hypervisor. Privilege escalation is a lot easier than breaking into a system from scratch.
All the juicy PS3 crypto stuff does live inside the CPU (in an isolated SPE), and that's nowhere near broken yet. Heck, even with full physical access, I'd be very surprised if someone were able to use this article's technique to recover console-private RSA keys from the isolated SPE, even though you can glitch the Cell's power supply:)
Really, the RSA hack is a very interesting mathematical procedure for recovering keys from glitchy signatures, but the physical attack as presented is pretty much impossible in practical systems, at least as presented.
Also, Intel chips, like Nehalem, actually have voltage converters on the chip which change 12V and 5V inputs to the 1.5V or so that the CPU needs. So your Core i7 system is quite safe against this attack. (Yes, it overclocks. See above)
Nope. The 12V to 1.xV converters are always on the motherboard (right next to the CPU). Modern CPUs might have smart power switching, but they definitely don't have on-board regulators. DC-DC voltage conversion requires large inductors, which you can't get on a chip anyway, and fabricating large chunky MOSFET transistors would be a ridiculous waste on an expensive CPU fabrication process.
It's "physical access" beyond most would even dream of... SPARC sounds like they're using an off-the-shelf computer system. They aren't. They downloaded the open source SPARC core (as in the source code to the CPU itself) and implemented it as a soft-processor in an FPGA chip. They're basically using their own custom computer system, with complete control and the ability to know exactly how it works, down to the deepest logic in the CPU.
Call me when they implement this on an off-the-shelf secure embedded system (I'm going to assume this is pretty much impossible on an off-the-shelf PC, so I'm not even going to ask for that).
Slashdot Mirror
I know, and this problem has been solved for ages now (think christmas lights). All you need is a device in parallel with each LED that will deliberately fail short when exposed to higher voltage (an antifuse), in order to bypass the bad LED. Then you use current regulation for each string, so other LEDs aren't affected when one fails (the current going through them is still the same).
The issues aren't a result of the series string, they're a result of a poorly thought out design based on series strings.
I first watched Avatar on a theatre equipped with XpanD 3D. I don't know if it was the projector, the glasses, or a combination, but the colors with the glasses on looked like those produced by a really bad LCD monitor, only less bright. Everything was greenish, blacks were badly crushed, and the heavy shutter glasses really hurt the immersion. I kept taking them off in some scenes in order to be able to see darker areas!
I rewatched it on a theatre that used RealD 3D, and the experience was much better. It wasn't perfect (some judder), but at least it wasn't worse than consumer gear. If there's one thing I expect when going to the cinema it's at least reasonable display standards and calibration - otherwise I'd much rather just torrent it and watch it in the comfort of my house.
The LEDs are probably wired in series strings. If one fails open, the entire string fails. If one fails short, the rest are subject to more current and are more likely to fail.
This isn't a problem with LEDs, it's a problem with bad circuit design.
Not at all, you get used to it pretty quickly. What you can do is replace the voice with some gibberish noises. For example, Zelda games tend to use vocal "calls" (think "hey!", a laugh, or some other attention-calling noise) but then the actual dialogue is text. Quite a few RPGs just make some sort of semi-random gibberish noise as the dialogue text is being scrolled onto the screen. It all works pretty well. You don't have to hear actual voices to convince yourself that the characters are speaking.
700W is just for ridiculous gaming rigs. PCs don't actually use anywhere near the rated power of the PSU. Buying a decent power supply with a higher power rating is good because pushing a PSU to its limits is a recipe for trouble or disaster. I have a 620W PSU in my quad-core desktop (4 HDDs too), but real power usage is more like 100W idle, 150W with all CPUs running at their max. A gaming video card running at full throttle or two would start pushing the power envelope up, but I'm happy with an cheap nVidia as long as it does video decoding in hardware.
If you want power efficiency, get a desktop-replacement laptop. You'll have a near full-featured PC that runs on less than 90W with the CPU and GPU pegged. With some judicious power management you can easily get regular use in under 30W battery, or 40W or so from AC (the PSU has its own inefficiencies). And if you don't need the power of a desktop, just get a regular / smaller laptop and enjoy your sub-20W average power consumption. Actual AC power figures from my huge 18.4" 2-HDD dual-core desktop-replacement laptop: 80W max (maxed out CPU and GPU), 56W idle with no power saving, 44W with lower screen brightness and more power saving, and 40W with some extra power saving. Yes, we can compute with less than 50W just fine, and that includes the monitor.
You do want a video card that accelerates mpeg-2/h.264 video playback though. A 2.4GHz dual-core will NOT play some 1080p h.264 HD content at full speed, nevermind a 1Ghz single core. HD video decoding is a huge computational power hog. Dedicated decoding hardware is much more power efficient and effective.
I don't use my real name for login names (IRC etc.). Not because I want to hide it, just because I prefer to use my standard login name. It's worth noting that said nickname (which is actually "marcan" these days) is actually a contraction of my last names itself :-)
You'll see me using my real name for mailing lists and the like, and I'll type my name into the "real name" box of most sites, including Slashdot. I'm not sure if you can actually see it or not though, but on most places you can. The point is it isn't secret nor do I attempt to keep it a secret.
Slow down, my friend. ICs aren't created equal, and you can't just throw everything on one die. Processes can be vastly different and what is optimal for one IC isn't optimal for another. For example, you can't manufacture standard DRAM on a CPU process - RAM processes are vastly different as they need to create capacitors. WiFi needs specific RF circuitry and often requires external ICs with exotic processes for switching/etc (GaAs or silocon on sapphire). Bluetooth will probably still need some funky silicon structures, even if not as much as WiFi. Other external interfaces like DVI and Ethernet are often not worth integrating (then you get separate chips to perform the physical layer encoding, even if the control logic is embedded into your CPU).
Besides, on a PC, being able to mix and match hardware is critical to get flexibility. If you want integrated everything, go for a cheap netbook, or the newer ARM-based tablets/netbooks that will (hopefully) be coming out. Those already integrate many more things into one die. Systems like these already use SoC chips that implement many things in one; for example, I have an ARM single-board computer that's the size of a credit card. The CPU includes basic peripherals, an Ethernet MAC (no PHY though, that's a separate chip), memory controller, PowerVR SGX GPU, and many other things. The memory is physically soldered on top of the CPU (package-on-package technology), and it's actually a combo package with one 512MB Flash die and two 256MB RAM dies, so, in fact, the whole shebang is four silicon dies stacked on top of each other with a total height of about 2mm. However, WiFi and Bluetooth are on a separate Marvell multi-die module, because it includes parts made with a vastly different process. The DVI encoder is also separate (not everyone needs DVI, and TMDS encoders aren't worth integrating), and so is the Ethernet PHY (that also isn't easy/desirable to integrate). So the main ICs on this board are CPU+RAM, Ethernet PHY, DVI encoder, Wireless, and the power controller (which also integrates an USB 2.0 OTG PHY, the RTC, clock generator, and an audio codec). At this stage, I think this is plenty of integration. One die for everything would be more trouble than it's worth.
I use my real name most of the time (except for throwaway accounts), because quite frankly I don't like to appear as "hiding" behind an online nickname, and names aren't exactly sensitive information. Usually the only time I'm asked my address is when I want to buy something; 99% of the other cases it's scammy/spammy/throwaway sites that I'm typing junk info into anyway. As for birth date, I tend to make that up, but not always. I'm quite a bit less paranoid than most people I know though; e.g. if you want my address (feel free to send me cool stuff :P), all you have to do is perform a WHOIS lookup on my domain.
But really, it all boils down to not using public websites for private stuff. The only website that I use that can be considered to be a social networking site is Twitter, and I use it to engage in public conversation anyway. If I want to talk in private, I use e-mail or IRC, preferably on private servers. If I put something on-line, chances are I probably want you to be able to find it.
Server logs are logs of server activity. If no server activity is generated for certain user actions, why do you need logs? There's no fundamental difference between logs of user-visible URIs and logs of backend AJAX calls; in fact, AJAX API URIs can be made just as descriptive for server log purposes.
If you want to track user actions, then obviously you'll have to add an explicit tracking bug, which negates some of the advantages of dynamic sites without necessarily triggering server activity for each user action, but that's your choice.
What part of as long as the site portion remains the same did you miss? All you'll be able to change is the path portion within your site, which you already control anyway.
Ever since AJAX and DHTML, sites have had full control over what pages actually display, regardless of the URL they were accessed through. Websites can already manipulate the URL bar at will through javascript, it's just that those manipulations forcibly trigger a page reload. As long as the new URL remains within your site, you can show whatever you want for the new page.
Practically speaking, the only change is that now you can change the URL bar without triggering a from-scratch page load, which is great for AJAX apps. As long as the browser prevents you from forging a URL that appears to "leave" your site, this is no different from what we have now other than letting AJAX apps more easily use consistent URLs while minimizing or eliminating full page loads.
Horrible ads? Adblock/Flashblock. Flash cookies? Delete them. What people care about is, erm, having a Linux version of Flash that isn't a horrible smoking pile of excrement, performance- and stability-wise.
That's H.263, which is a horrible piece of crap. It's what youtube used before H.264 and they still do for the low-quality version of videos. There's no question that Theora beats the old flv H.263.
Sounds OK to me as long as the site portion remains the same. This isn't any different from other cross-site scripting or impersonation problems. For all I care sites can do whatever they want to the URL bar as long as the site-identificating portion remains constant.
That's a tricky question. Testing and finding bugs ought to allow you to put more trust in your testing methodology, which subsequently can increase your trust in your software once you stop finding bugs. Testing and finding no bugs, hard as you try, quite likely means you aren't trying hard enough. Very rarely will software reach a ceiling of reasonable test-proofness before being shipped that cannot be improved with subsequent, more dedicated, more specific testing after some issues are detected in the field.
The more (and better) you test without finding bugs (or the bugs you want), the higher your chances of the target bugs not existing. Finding other, unrelated bugs helps ascertain that you are, in fact, performing a useful level of testing. If Toyota had found, say, three or four controlled panic style bugs (caused by defensive programming) that would cause engine shutdown (which is probably safer than unintended acceleration) but nothing related to acceleration, then in my mind it would be better evidence against the acceleration bug existing in software. The types of bugs do matter though - finding flimsy memory corruption or race condition type bugs might instead mean that the code has been written without proper programming practices and might lower my trust on it.
Ultimately though, it's true that no level of testing can conclusively prove the absence of bugs.
Given practical software engineering conditions though, a) is highly unlikely while b) is highly likely.
Voltage is relative. A hollow coin will prevent anything inside it from being able to perceive any voltage potential difference. It doesn't matter if you plug the thing into a 120kV line as referenced to ground, the microSD card still won't feel a thing. So no, it doesn't need to be grounded.
The fourth generation of the iPhone is getting NFC/RFID capabilities, much like some other phones already have.
This isn't new. The only new thing they could possibly bring to the NFC table would be (gasp) actual security, given that RFID/NFC devices are notorious for being horribly insecure most of the time.
I submit that making ISPs pay the levy is fairer, as 1) they are the ones who profit directly from downloads, 2) people connecting to the Internet are more likely to correlate to people who download (especially with higher-speed connections, which are marketed quite blatantly as being for faster downloads), at least more so than levies on blank media. Blank media isn't a good match because many people download onto their computer's master hard drive (which isn't levied), many people require mass storage for things other than downloaded media (including companies), and blank media producers don't necessarily profit from downloads, at least not nearly as much.
Nothing will ever be 100% fair, because the premise is that you just cannot control distribution of audiovisual works. This is why the levies were introduced, back in the day when the government realized that they couldn't do anything against people copying music on cassette tapes, and instead levied the blank tapes.
No, because audiovisual works don't have EULAs, and even if they forced them upon buyers, a clause preventing you from legally sharing it noncommercially would probably not be enforceable.
As a copyrighted work, software is considerably different from just media.
Here's how it (roughly) works over here (Spain):
- Audiovisual works can be shared noncommercially, but we pay levies on all kinds of media and copying devices (CD/DVD-Rs, hard drives, media players, cellphones)
- Software is protected and P2P sharing of software is not legal
Now, there's a huge SNAFU going on here with our RIAA-equivalent (the SGAE), who are lying bastards and cheaters, the levy system isn't ideal (many people get charged who don't use P2P, and the devices/consumables that get levies are just stupid - I think it'd be better to charge levies on internet connections instead of consumables and devices), and the way the levies are distributed is completely backwards (SGAE execs have been known to use some privately, transparency is nil, and small artists get squat). Nonetheless, the basic premise isnt all that bad: legalize audio/video/book file sharing, but impose some reasonable sort of cash stream from the people very likely to use P2P to the people who very likely have their works shared.
You also need to realize that legalizing file sharing does not imply removing all copyright. All it says is that sharing copyrighted files is fine (authors have less control over how their work is distributed noncommercially), but it doesn't imply licenses are invalid: You still can't produce a GPL'd derivative work and not provide source, you still can't violate the attribution/share-alike/non-commercial provisions of Creative Commons, etc. I don't think anyone is seriously arguing that copyright should be abolished - there's a huge difference between that and just making the usual P2P scenarios legal.
It's in B&W without backlighting / in the sunlight. It's in full color with the backlight on and at moderate to low ambient light, and somewhere in between as you reduce the backlight level and increase the abient level. Which is pretty good, considering that most laptop screens are fairly unusable in direct sunlight.
Hunt and peck is the opposite of touch typing, but touch typing is not synonymous with "proper" typing technique. I never learned to type "properly", and I tend to use four fingers instead of five, but I don't look at the keyboard while typing and I can get over 100wpm (I just tested myself at 95wpm right now) - the fact that I don't look means I'm a touch typist, whether I use the "proper" technique or not. Obviously hunt-and-peck at over 100wpm is bullshit, but you can easily type at moderate to quite fast speeds even if your typing technique isn't "standard" or ideal.
The PS3 attack was very obvious (i.e. the hypervisor lives in external memory, essentially unsecured), and the Cell chip is fairly well documented itself. That's breaking security by obscurity (where obscurity is the high-speed memory bus), and isn't really comparable to what this article talks about. Also, it doesn't rely on tweaking CPU voltage to produce internal errors, but rather on glitching the memory bus. This is a lot easier, and has a (small - the PS3 hack as performed by geohot is highly unpredictable) chance of working and not screwing up the rest of the system (as long as the rest of the system is essentially quiescent). Keep in mind that the PS3 attack also relies on privilege escalation; it wouldn't work at all if you couldn't already run your own code under the hypervisor. Privilege escalation is a lot easier than breaking into a system from scratch.
All the juicy PS3 crypto stuff does live inside the CPU (in an isolated SPE), and that's nowhere near broken yet. Heck, even with full physical access, I'd be very surprised if someone were able to use this article's technique to recover console-private RSA keys from the isolated SPE, even though you can glitch the Cell's power supply :)
Really, the RSA hack is a very interesting mathematical procedure for recovering keys from glitchy signatures, but the physical attack as presented is pretty much impossible in practical systems, at least as presented.
Nope. The 12V to 1.xV converters are always on the motherboard (right next to the CPU). Modern CPUs might have smart power switching, but they definitely don't have on-board regulators. DC-DC voltage conversion requires large inductors, which you can't get on a chip anyway, and fabricating large chunky MOSFET transistors would be a ridiculous waste on an expensive CPU fabrication process.
It's "physical access" beyond most would even dream of... SPARC sounds like they're using an off-the-shelf computer system. They aren't. They downloaded the open source SPARC core (as in the source code to the CPU itself) and implemented it as a soft-processor in an FPGA chip. They're basically using their own custom computer system, with complete control and the ability to know exactly how it works, down to the deepest logic in the CPU.
Call me when they implement this on an off-the-shelf secure embedded system (I'm going to assume this is pretty much impossible on an off-the-shelf PC, so I'm not even going to ask for that).