Thousands of these are claimed to have been deployed, and some of the other comments already explain just how easy it is to flash these and get rid of all the "security". Even the worst game console security features lasted longer than this.
But even if that weren't the case, there's a simple reason why these netbooks couldn't possibly have PS3-grade security: because such hardware doesn't exist in the PC world. Unless the Aussie government commissioned a special highly secure CPU from Intel, a special highly secure chipset from Intel, a special highly secure BIOS from some BIOS vendor, and a special highly secure hypervisor to watch over Windows from someone else. Sorry, no PC platform exists so far with security even close to that of the PS3, and it's reasonable to assume that the Australian government hasn't magically pulled one out of nowhere.
EFI isn't rocket science - in fact, lots of it is publicly documented, which is much better than the completely proprietary old-school BIOS implementations. You can already mod UEFI-based BIOSes without much trouble.
People keep assuming they even have or use a TPM chip to provide any kind of hardware security (if they don't, they don't even stand a chance). My bet is there is they don't.
Oh, it won't. This is a unified platform shipped to thousands. It will take a few weeks, then one person will come up with an automatic.exe that when run disables all of the firmware protection, and everyone else will run it. Nevermind that, this being a PC platform (and I doubt they have/use a TPM), the protection is pathetic compared with that of other devices (say, the iPhone) which nonetheless have also been hacked.
Encrypted bootup, a dedicated security SPU, encrypted memory, signing everywhere, a tightly controlled software environment, encrypted buses, a thousnd other things I'm forgetting, and actually being open to some degree ('Other OS' mode, which discourages homebrew users from attempting to crack the core system) are what it took to get that kind of actual resistance against attack. Call me back when these netbooks have equivalent security measures in place.
"Tracking software embedded at the BIOS level"? Last I checked, those "tracking schemes" just force-fed Windows some driver/app at the BIOS level. Install any other OS and it becomes useless (not to mention that BIOSes these days aren't even hard to hack). As for the RFID, I don't see how disassembling it and taking it out is rocket science. Nevermind that the students themselves are going to be owning any kind of app installation protection in the blink of an eye.
Sorry, using software to secure a platform against its physical holder has never worked for long, but even just trying to do it on an insecure platform like an x86 PC is beyond useless. None of this is has even a remote chance of working without the heaviest-handed TPM-on-CPU-die functionality and signing of each and every piece of software, but that has no chance of working because no one would want such a platform, it would be painful and expensive to develop, and it could never exist given the buggy and insecure nature of PC software in general.
Video game consoles with strong hardware security and tightly controlled software environments with little interoperability requirements get cracked all the time to run homebrew and/or pirate games, what makes these people think their little netbook won't be?
For what it's worth, Linux vs. Windows here makes little difference. The entire scheme is doomed to fail from the start due to the nature of a PC solution like this. Sounds like Microsoft just sold these guys a bunch of nonexistent security.
The Z buffer shouldn't be an issue. Just render objects on each CPU (pretend they're different scenes), and then merge the images using their Z buffers as a key. You only need to exchange the Z buffer once for the final merge. It doesn't matter that objects will be drawn that would normally be hidden under objects drawn by the other GPU, because the right pixels will be chosen during the final merge based on the Z buffers.
There are certainly questions to be answered, but the fundamental idea of rendering different objects on different GPUs shouldn't be too problematic. Of course, things get "slightly" harder when you factor in render-to-texture, effects, etc. But they can always take the cheap way out and just bail to single GPU when "incompatible"/unimplemented features are used.
I doubt this is vaporware. It may perform better or worse, but I think it's a perfectly real product.
Already in place. Look up the Spanish DNIe (e-ID card). The electronic signatures issued with it are considered to have the same validity as physical signatures.
Of course, there's the bit where all you need to sign as someone else is their ID card and their fingerprint (which likely is going to be on the card itself considering you probably touch it often). Whoever thought the idea of ATM-like machines that only need your fingerprint to reset your password should be shot. But other than the implementation failures, the idea is decent.
Now if only they didn't use retarded bin-blob drivers for it... reverse engineering the protocol is on my TODO list.
Overheating video cards have graphical glitches while overheating. This is different, it's a semi-permanent condition potentially caused by heat. My guess is that it's caused by thermal stress/cycling breaking poorly soldered connections.
The GPU can't doing anything. In fact, it can only be accessed by the Broadway CPU, and the same GPIO pin turns the PPC off and makes the LED go yellow, so it's physically impossible for the GPU to be in use while the LED is yellow as far as we know.
Thing is, there's no "GPU" chip on the Wii, the two main chips are the CPU chip and the "everything else" chip. "Everything else" includes I/O, an ARM926EJ-S processor, 24MB of RAM, the audio DSP, and all sorts of other stuff, much of which is definitely on during WC24 mode. I doubt the GPU is clocked in WC24 mode (though I wouldn't put it past them), but there's a good chance that it's powered at least and leaking current.
Also, the fan is controlled by the ARM (it's just connected to a GPIO pin), which means that Nintendo could push out an update for all IOSes that leaves the fan at, say, 50% speed when in WC24 mode (via PWM, which they already do for the front slot LED stuff - that LED is just another GPIO). If they have a temperature sensor, they could use that too (we don't know if there is one). And they could fix the retarded no-CPU-sleep issue. But given their track record of actual useful retroactive updates to IOS (0), I'd say it's not going to happen (unless Wiis start massively dying due to this at some point in the future).
The "DRM keys" aren't transferable (well, actually, they are because their security sucks, but they're not supposed to be). They need to issue/sign new ones to your new console. Thing is, they've been known not to do that for some people, resulting in the loss of all Wii Points and Wii Shop content. They don't appear to be completely consistent in the way they deal with paid content during repairs.
As far as save files, you're screwed if the console doesn't boot at all (read: nothing at all on the screen), most of the time. I'm not aware of Nintendo having absolutely any procedure to handle such cases. Their procedure at best seems to amount to popping in a save-backup disc (which backs up most stuff to an SD card) and possibly whatever device it is they use that performs the same function as a SaveMii (which would put the system menu into recovery mode). The Wii boot process is extremely fragile: that device is only going to work and that disc is only going to boot if everything on the console works fine up to and including the System Menu main() function (that's very roughly equivalent to, say, starting X11 on a Linux computer). If anything breaks before that (as it can and does happen), they can't fix it. There is no "pandora battery" for the Wii working at a ROM level.
In fact, save file loss is usually equivalent to "the whole unit [actually the motherboard] needing replacement" in all cases except of intermittent hardware failure (such as the GPU having issues). If the system can boot a recovery disc, then pretty much all hardware works (including the Bluetooth and WiFi daughtercards), and if there are any software issues they can be sorted out from there. If the system can't boot the recovery disc (either due to catastrophic hardware failure or a system issue), then you're screwed and you won't get your saves out of it.
The Wii has issues with what might also be poor soldering. On the Wii it causes pixel "snow" to appear, which is more prominent with some games than others. Mine started doing it and then spontaneously fixed itself. Others have had less luck.
People tend to blame the WiiConnect24 idle mode for it ("yellow LED mode"). The WC24 power design of the Wii is extremely poor (that's why it's such a power hog in that mode, even though the main CPU is, in fact,off). The secondary ARM core used for WC24 stuff lives on the same die as the GPU ("Napa"), and my bet is there's a lot of leakage current and they probably don't turn off power to the GPU part. It also doesn't help that the idiots at BroadOn didn't use a wait-for-interrupt instruction in the IOS idle loop: that ARM chip is running at 100% CPU utilization even during the idlest of moments in WC24 mode (the idle thread spins around endlessly). Even though it's an ARM core, it's shoehorned into a (relatively) power-hungry GPU process and runs at 243Mhz (full time, due to the stupid software issue above), so my bet is it chews up quite a lot more power than your average cellphone ARM core. You can prove that pretty much all of the Wii is on in WC24 mode, minus the CPU: there is power going to the expansion ports (easily measured), the main power buses are on (IOS needs NAND flash and the GDDR3 RAM, among others), and even the video output hardware is on (bugs in homebrew have at times caused a video signal to remain present on the output after switching to WC24 mode).
The fan is off in WC24 mode, so the end result is that the Hollywood chip gets quite warm for extended periods of time. People speculate that this causes the failures.
It's public key authentication no doubt (RSA likely). Forget about cracking it (unless they made some kind of really big huge mistake). We're way past the phase where crypto attacks show up. At this point all you can hope for are software bugs.
It is true that Mark's tools and a lot of knowledge will let you dig quite more into Windows than you'd expect. However, you still hit the inevitable brick wall that is closed source. At some point, if there's a bug in the source, you're not going to be able to figure it out without digging into assembly language, which is undesirable.
I also get the impression -and this may very well be caused by my relative inexperience with Windows internals as opposed to Linux internals- that Windows is more complicated on several levels, or at least requires tools that are more engineered and advanced, to diagnose certain issues. Again, this may just be my unfamiliarity with the OS, but it feels like stuff on Linux is just based around simpler system primitives (UNIX filesystem, pipes, sockets, command line, environment variables) that are easier to grasp, as opposed to the more complex APIs available under Windows.
As an example, this is what a system call trace of "ls" looks like. Compare that to a procmon trace of "cmd/c dir" on a nearly vanilla Windows install (and this only includes certain system call categories).
On the 3GS (not 3G, I was wrong about that) iTunes submits portions of the ipsw for hashing to Apple's servers before sending them to the device. Try restoring a 3.0.1 IPSW to a 3GS now: it won't work (even if that 3GS has an older version of the firmware). Apple's servers simply won't sign 3.0.1 any more. It's not that you can't downgrade, you simply cannot install anything but 3.1 on a 3GS now unless you obtained the signatures for your device from iTunes back when Apple did sign them (you can lift them from/tmp and whatnot).
When Linux "just works" it really does just work. However, when it doesn't, there's a good chance that you have to either dig up a strange workaround or ask a developer to fix things for you.
Things rarely "just work" on Windows, but the annoying installation step that precedes using most hardware/software usually has a higher overall chance of succeeding. However, when stuff breaks on Windows, it can be very bad too (anything from strange workarounds and processes that rival Linux manual configuration steps to "magical fixes" involving installing, uninstalling, or reinstalling specific versions of software). Windows has a handicap here in that sometimes it doesn't matter how experienced you are, the only way of fixing some stuff is with magic voodoo steps or a complete reinstall (under Linux, you usually can dig around enough to find the root cause and fix it).
So when things work as designed, Linux is easier, though things work as designed more often under Windows. When things break, it can equally suck for both OSes, and if you're an advanced user Windows can be even more frustrating.
Apple locks the baseband and the application processor. Newer phones (3G, 3GS) use bootloaders signed specifically for your CPU. This means not only will they only run officially signed software, they will only run officially signed software that Apple has specifically signed for your phone (this happens using a server that they own during the iTunes upgrade process). This also means that unless you have a dump of a vulnerable bootloader version signed for your phone, you can't downgrade without finding a vulnerability in the current version of the software.
A tax for cassettes made sense, since they were indeed used to copy music the vast majority of the time. This model breaks down with digital storage devices though, which is why there is a very strong opposition to this tax. I believe the two largest opposing political parties have stated that they will get rid of it if they are elected (let's see if they keep their word if and when they are).
We actually have such a fee in Spain already. However, the law also happens to state that so-called "private copies" of audiovisual works and the like (i.e. music, movies, books but not software) are legal as long as no profit is made off of them. This applies to file sharing. So we pay the equivalent of the MAFIAA (the SGAE here) a fee for CD/DVD-Rs, hard drives, writable media, flash cards, DVRs, printers, and even cellphones and all sorts off stuff (which is still extremely inane), but at least we can download whatever we want and they can do squat about it (well, they still make those "piracy is a crime" lying TV adverts, but it's not like anyone listens to them). I for one have made it a point not to buy absolutely anything from anyone remotely affiliated with the SGAE ever since they introduced this fee.
That's some intel-specific issue affecting full-screen modes. Flash video playing sucks across the board if you're scaling the video to any decent resolution: as you zoom into the web page, the picture starts getting jerkier and at full-screen it's unwatchable.
We're confusing two things here: some very specific issue in the Intel driver and the very crappy performance of Flash video no matter what card you use. Even with that patch, I highly doubt Intel users are going to get smooth full-screen video if they have an average CPU and are running at 1920x1080 or some other large resolution.
For everyone else, we don't give a flying fuck whose fault it is. We just care that it's broken, has been for a long time, and upon seeing countless changelogs that amount to little more than kernel hacker epeen comparisons, a lot of us have given up hope for a truly omnipotent Linux desktop.
That's because most of the work to improve the desktop happens outside the kernel. If you're looking for changelogs relevant to desktop stuff, look at Xorg or the KDE project or whatever.
Also, you forget one case where every Linux desktop and laptop runs out of memory: hibernation. Specifically, they reduce their memory usage to 0 when that happens, by paging out most stuff and then making an image of the rest. These changes should help post-resume performance after hibernation, during those initial seconds where switching applications takes a while as everything is being paged in. That's quite relevant to desktop usage, don't you think?
As for ACPI issues, do take note that manufacturers tend to suck at ACPI implementations. So some issues will come and go - Windows has an inherent advantage in that manufacturers explicitly test (and work around bugs) for Windows compatibility. I've had to fight with my laptop's ACPI support. Half got fixed with a few kernel patches to work around bugs, and half got fixed after the third BIOS update (one year after I bought the machine). None of the issues would have happened if the laptop's ACPI implementation weren't so buggy. Keep that in mind when you see complaints about ACPI issues - most often, they're the manufacturer's fault, and they take a while to get worked around or fixed.
Free-as-in-freedom, not free-as-in-beer. Look it up. Linux isn't a promise for zero monetary cost (you still have to buy a computer, don't you?)
Some hardware may work better for Linux, but it's not necessarily rare or expensive. Now keep in mind that, in fact, Linux runs on much lower cost systems than your average PC (for example, ARM-based platforms). You won't find Windows running on your $30 WiFi router.
You're right, WinModem is an inaccurate term (as I said, I've used "Win"modems under Linux), but it's well-known and has stuck (and besides, this is obsolete technology anyway), so let's not argue over terminology. I don't see how this extrapolates to rivalry. Somehow you've managed to extract a bucketload of hate from a single term.
The only real way around that obfuscation is making a fully compliant player. Video sites keep changing URL and keying schemes around. That's kind of the point. By the time you've broken the obfuscation universally, you've made a flash player clone (at least everything but the actual rendering to the screen).
Slashdot Mirror
Thousands of these are claimed to have been deployed, and some of the other comments already explain just how easy it is to flash these and get rid of all the "security". Even the worst game console security features lasted longer than this.
But even if that weren't the case, there's a simple reason why these netbooks couldn't possibly have PS3-grade security: because such hardware doesn't exist in the PC world. Unless the Aussie government commissioned a special highly secure CPU from Intel, a special highly secure chipset from Intel, a special highly secure BIOS from some BIOS vendor, and a special highly secure hypervisor to watch over Windows from someone else. Sorry, no PC platform exists so far with security even close to that of the PS3, and it's reasonable to assume that the Australian government hasn't magically pulled one out of nowhere.
EFI isn't rocket science - in fact, lots of it is publicly documented, which is much better than the completely proprietary old-school BIOS implementations. You can already mod UEFI-based BIOSes without much trouble.
People keep assuming they even have or use a TPM chip to provide any kind of hardware security (if they don't, they don't even stand a chance). My bet is there is they don't.
Oh, it won't. This is a unified platform shipped to thousands. It will take a few weeks, then one person will come up with an automatic .exe that when run disables all of the firmware protection, and everyone else will run it. Nevermind that, this being a PC platform (and I doubt they have/use a TPM), the protection is pathetic compared with that of other devices (say, the iPhone) which nonetheless have also been hacked.
Encrypted bootup, a dedicated security SPU, encrypted memory, signing everywhere, a tightly controlled software environment, encrypted buses, a thousnd other things I'm forgetting, and actually being open to some degree ('Other OS' mode, which discourages homebrew users from attempting to crack the core system) are what it took to get that kind of actual resistance against attack. Call me back when these netbooks have equivalent security measures in place.
"Tracking software embedded at the BIOS level"? Last I checked, those "tracking schemes" just force-fed Windows some driver/app at the BIOS level. Install any other OS and it becomes useless (not to mention that BIOSes these days aren't even hard to hack). As for the RFID, I don't see how disassembling it and taking it out is rocket science. Nevermind that the students themselves are going to be owning any kind of app installation protection in the blink of an eye.
Sorry, using software to secure a platform against its physical holder has never worked for long, but even just trying to do it on an insecure platform like an x86 PC is beyond useless. None of this is has even a remote chance of working without the heaviest-handed TPM-on-CPU-die functionality and signing of each and every piece of software, but that has no chance of working because no one would want such a platform, it would be painful and expensive to develop, and it could never exist given the buggy and insecure nature of PC software in general.
Video game consoles with strong hardware security and tightly controlled software environments with little interoperability requirements get cracked all the time to run homebrew and/or pirate games, what makes these people think their little netbook won't be?
For what it's worth, Linux vs. Windows here makes little difference. The entire scheme is doomed to fail from the start due to the nature of a PC solution like this. Sounds like Microsoft just sold these guys a bunch of nonexistent security.
The Z buffer shouldn't be an issue. Just render objects on each CPU (pretend they're different scenes), and then merge the images using their Z buffers as a key. You only need to exchange the Z buffer once for the final merge. It doesn't matter that objects will be drawn that would normally be hidden under objects drawn by the other GPU, because the right pixels will be chosen during the final merge based on the Z buffers.
There are certainly questions to be answered, but the fundamental idea of rendering different objects on different GPUs shouldn't be too problematic. Of course, things get "slightly" harder when you factor in render-to-texture, effects, etc. But they can always take the cheap way out and just bail to single GPU when "incompatible"/unimplemented features are used.
I doubt this is vaporware. It may perform better or worse, but I think it's a perfectly real product.
Already in place. Look up the Spanish DNIe (e-ID card). The electronic signatures issued with it are considered to have the same validity as physical signatures.
Of course, there's the bit where all you need to sign as someone else is their ID card and their fingerprint (which likely is going to be on the card itself considering you probably touch it often). Whoever thought the idea of ATM-like machines that only need your fingerprint to reset your password should be shot. But other than the implementation failures, the idea is decent.
Now if only they didn't use retarded bin-blob drivers for it... reverse engineering the protocol is on my TODO list.
Overheating video cards have graphical glitches while overheating. This is different, it's a semi-permanent condition potentially caused by heat. My guess is that it's caused by thermal stress/cycling breaking poorly soldered connections.
The GPU can't doing anything. In fact, it can only be accessed by the Broadway CPU, and the same GPIO pin turns the PPC off and makes the LED go yellow, so it's physically impossible for the GPU to be in use while the LED is yellow as far as we know.
Thing is, there's no "GPU" chip on the Wii, the two main chips are the CPU chip and the "everything else" chip. "Everything else" includes I/O, an ARM926EJ-S processor, 24MB of RAM, the audio DSP, and all sorts of other stuff, much of which is definitely on during WC24 mode. I doubt the GPU is clocked in WC24 mode (though I wouldn't put it past them), but there's a good chance that it's powered at least and leaking current.
Also, the fan is controlled by the ARM (it's just connected to a GPIO pin), which means that Nintendo could push out an update for all IOSes that leaves the fan at, say, 50% speed when in WC24 mode (via PWM, which they already do for the front slot LED stuff - that LED is just another GPIO). If they have a temperature sensor, they could use that too (we don't know if there is one). And they could fix the retarded no-CPU-sleep issue. But given their track record of actual useful retroactive updates to IOS (0), I'd say it's not going to happen (unless Wiis start massively dying due to this at some point in the future).
The "DRM keys" aren't transferable (well, actually, they are because their security sucks, but they're not supposed to be). They need to issue/sign new ones to your new console. Thing is, they've been known not to do that for some people, resulting in the loss of all Wii Points and Wii Shop content. They don't appear to be completely consistent in the way they deal with paid content during repairs.
As far as save files, you're screwed if the console doesn't boot at all (read: nothing at all on the screen), most of the time. I'm not aware of Nintendo having absolutely any procedure to handle such cases. Their procedure at best seems to amount to popping in a save-backup disc (which backs up most stuff to an SD card) and possibly whatever device it is they use that performs the same function as a SaveMii (which would put the system menu into recovery mode). The Wii boot process is extremely fragile: that device is only going to work and that disc is only going to boot if everything on the console works fine up to and including the System Menu main() function (that's very roughly equivalent to, say, starting X11 on a Linux computer). If anything breaks before that (as it can and does happen), they can't fix it. There is no "pandora battery" for the Wii working at a ROM level.
In fact, save file loss is usually equivalent to "the whole unit [actually the motherboard] needing replacement" in all cases except of intermittent hardware failure (such as the GPU having issues). If the system can boot a recovery disc, then pretty much all hardware works (including the Bluetooth and WiFi daughtercards), and if there are any software issues they can be sorted out from there. If the system can't boot the recovery disc (either due to catastrophic hardware failure or a system issue), then you're screwed and you won't get your saves out of it.
The Wii has issues with what might also be poor soldering. On the Wii it causes pixel "snow" to appear, which is more prominent with some games than others. Mine started doing it and then spontaneously fixed itself. Others have had less luck.
People tend to blame the WiiConnect24 idle mode for it ("yellow LED mode"). The WC24 power design of the Wii is extremely poor (that's why it's such a power hog in that mode, even though the main CPU is, in fact,off). The secondary ARM core used for WC24 stuff lives on the same die as the GPU ("Napa"), and my bet is there's a lot of leakage current and they probably don't turn off power to the GPU part. It also doesn't help that the idiots at BroadOn didn't use a wait-for-interrupt instruction in the IOS idle loop: that ARM chip is running at 100% CPU utilization even during the idlest of moments in WC24 mode (the idle thread spins around endlessly). Even though it's an ARM core, it's shoehorned into a (relatively) power-hungry GPU process and runs at 243Mhz (full time, due to the stupid software issue above), so my bet is it chews up quite a lot more power than your average cellphone ARM core. You can prove that pretty much all of the Wii is on in WC24 mode, minus the CPU: there is power going to the expansion ports (easily measured), the main power buses are on (IOS needs NAND flash and the GDDR3 RAM, among others), and even the video output hardware is on (bugs in homebrew have at times caused a video signal to remain present on the output after switching to WC24 mode).
The fan is off in WC24 mode, so the end result is that the Hollywood chip gets quite warm for extended periods of time. People speculate that this causes the failures.
It's public key authentication no doubt (RSA likely). Forget about cracking it (unless they made some kind of really big huge mistake). We're way past the phase where crypto attacks show up. At this point all you can hope for are software bugs.
It is true that Mark's tools and a lot of knowledge will let you dig quite more into Windows than you'd expect. However, you still hit the inevitable brick wall that is closed source. At some point, if there's a bug in the source, you're not going to be able to figure it out without digging into assembly language, which is undesirable.
I also get the impression -and this may very well be caused by my relative inexperience with Windows internals as opposed to Linux internals- that Windows is more complicated on several levels, or at least requires tools that are more engineered and advanced, to diagnose certain issues. Again, this may just be my unfamiliarity with the OS, but it feels like stuff on Linux is just based around simpler system primitives (UNIX filesystem, pipes, sockets, command line, environment variables) that are easier to grasp, as opposed to the more complex APIs available under Windows.
As an example, this is what a system call trace of "ls" looks like. Compare that to a procmon trace of "cmd /c dir" on a nearly vanilla Windows install (and this only includes certain system call categories).
On the 3GS (not 3G, I was wrong about that) iTunes submits portions of the ipsw for hashing to Apple's servers before sending them to the device. Try restoring a 3.0.1 IPSW to a 3GS now: it won't work (even if that 3GS has an older version of the firmware). Apple's servers simply won't sign 3.0.1 any more. It's not that you can't downgrade, you simply cannot install anything but 3.1 on a 3GS now unless you obtained the signatures for your device from iTunes back when Apple did sign them (you can lift them from /tmp and whatnot).
When Linux "just works" it really does just work. However, when it doesn't, there's a good chance that you have to either dig up a strange workaround or ask a developer to fix things for you.
Things rarely "just work" on Windows, but the annoying installation step that precedes using most hardware/software usually has a higher overall chance of succeeding. However, when stuff breaks on Windows, it can be very bad too (anything from strange workarounds and processes that rival Linux manual configuration steps to "magical fixes" involving installing, uninstalling, or reinstalling specific versions of software). Windows has a handicap here in that sometimes it doesn't matter how experienced you are, the only way of fixing some stuff is with magic voodoo steps or a complete reinstall (under Linux, you usually can dig around enough to find the root cause and fix it).
So when things work as designed, Linux is easier, though things work as designed more often under Windows. When things break, it can equally suck for both OSes, and if you're an advanced user Windows can be even more frustrating.
Apple locks the baseband and the application processor. Newer phones (3G, 3GS) use bootloaders signed specifically for your CPU. This means not only will they only run officially signed software, they will only run officially signed software that Apple has specifically signed for your phone (this happens using a server that they own during the iTunes upgrade process). This also means that unless you have a dump of a vulnerable bootloader version signed for your phone, you can't downgrade without finding a vulnerability in the current version of the software.
You're both right. The new slashdot is faster to use and ostensibly more usable. However, it's also horrendously slow and bloated and breaks at times.
A tax for cassettes made sense, since they were indeed used to copy music the vast majority of the time. This model breaks down with digital storage devices though, which is why there is a very strong opposition to this tax. I believe the two largest opposing political parties have stated that they will get rid of it if they are elected (let's see if they keep their word if and when they are).
Indeed. One hopes that artists will start to catch on and stop affiliating themselves with the mafia that is the SGAE.
I'm not saying that the system is by any means good, but it beats paying the tax and still breaking the law when you copy works.
We actually have such a fee in Spain already. However, the law also happens to state that so-called "private copies" of audiovisual works and the like (i.e. music, movies, books but not software) are legal as long as no profit is made off of them. This applies to file sharing. So we pay the equivalent of the MAFIAA (the SGAE here) a fee for CD/DVD-Rs, hard drives, writable media, flash cards, DVRs, printers, and even cellphones and all sorts off stuff (which is still extremely inane), but at least we can download whatever we want and they can do squat about it (well, they still make those "piracy is a crime" lying TV adverts, but it's not like anyone listens to them). I for one have made it a point not to buy absolutely anything from anyone remotely affiliated with the SGAE ever since they introduced this fee.
That's some intel-specific issue affecting full-screen modes. Flash video playing sucks across the board if you're scaling the video to any decent resolution: as you zoom into the web page, the picture starts getting jerkier and at full-screen it's unwatchable.
We're confusing two things here: some very specific issue in the Intel driver and the very crappy performance of Flash video no matter what card you use. Even with that patch, I highly doubt Intel users are going to get smooth full-screen video if they have an average CPU and are running at 1920x1080 or some other large resolution.
That's because most of the work to improve the desktop happens outside the kernel. If you're looking for changelogs relevant to desktop stuff, look at Xorg or the KDE project or whatever.
Also, you forget one case where every Linux desktop and laptop runs out of memory: hibernation. Specifically, they reduce their memory usage to 0 when that happens, by paging out most stuff and then making an image of the rest. These changes should help post-resume performance after hibernation, during those initial seconds where switching applications takes a while as everything is being paged in. That's quite relevant to desktop usage, don't you think?
As for ACPI issues, do take note that manufacturers tend to suck at ACPI implementations. So some issues will come and go - Windows has an inherent advantage in that manufacturers explicitly test (and work around bugs) for Windows compatibility. I've had to fight with my laptop's ACPI support. Half got fixed with a few kernel patches to work around bugs, and half got fixed after the third BIOS update (one year after I bought the machine). None of the issues would have happened if the laptop's ACPI implementation weren't so buggy. Keep that in mind when you see complaints about ACPI issues - most often, they're the manufacturer's fault, and they take a while to get worked around or fixed.
Free-as-in-freedom, not free-as-in-beer. Look it up. Linux isn't a promise for zero monetary cost (you still have to buy a computer, don't you?)
Some hardware may work better for Linux, but it's not necessarily rare or expensive. Now keep in mind that, in fact, Linux runs on much lower cost systems than your average PC (for example, ARM-based platforms). You won't find Windows running on your $30 WiFi router.
You're right, WinModem is an inaccurate term (as I said, I've used "Win"modems under Linux), but it's well-known and has stuck (and besides, this is obsolete technology anyway), so let's not argue over terminology. I don't see how this extrapolates to rivalry. Somehow you've managed to extract a bucketload of hate from a single term.
The only real way around that obfuscation is making a fully compliant player. Video sites keep changing URL and keying schemes around. That's kind of the point. By the time you've broken the obfuscation universally, you've made a flash player clone (at least everything but the actual rendering to the screen).