The real problem isn't bogus stats caused by line inflation. The real problem is that it only finds certain types of bugs. If a bug causes an incorrect result or improper behavior, but doesn't cause a memory leak or the like that crashes the program or system, then it isn't being found. It also isn't finding STUPID code - code that works but is ridiculously convoluted, slow, difficult to modify, redundant (writing 5000 lines of code to do some string manipulation and parsing that could be done just as easily and efficiently using a RE library, or use lex, or some other straightforward solution - I've seen code that re-implemented several of the standard library string routines, and to add insult to injury, did it poorly and with a memory leak - at least these guys would have found the memory leak, but their solution would probably be to fix the leak, not toss the whole routine). C++ programmers seem to do this kind of thing particularly often, although many "object oriented" programmers can screw things up in multiple languages with equal facility.
What are you doing to further your plans of being quite dead by then? Myself, I'm planning on being quite alive by then, though probably not on this planet.
Yeah, this was hardly "unimaginable" a few years ago. It was more like "what do you mean, none of this stuff really works the way it ought to?"
AJAX is just a hack on top of a kludge to try to make a stateless batch protocol into a persistent interactive "experience". HTTP works fine for what it was designed for, HTML works fine for what it was designed for, AJAX reminds me of the classic Yiddish joke about the tailor:
Schlumpf the tailor made a suit, but one sleeve was longer than the other. To the customer's complaint, he replied "Just pull your shoulder up a little, and then the sleeve will be okay." But when he pulled his shoulder up, the back of the suit hunched up a bit. The tailor said, "Just bend over a little to one side, it will be fine." So as the man walked away, two women observed him shuffling along, his shoulder and back hunched, bent, contorted. One said "Oh that poor man, but what a lovely suit!" The other replied, "Yes, it must have been made by Schlumpf the tailor, only he could make such a nice suit to fit a cripple like him."
No, it doesn't have pixels, but it does have a maximum bandwidth, which limits how sharp edges can be, for example, or how close two edges or color changes can be to each other. This is normally expressed as lines of resolution.
It took 3 years for a known crack to be found. Given the realities of code tracing, any serious attempt to figure out the algorithm and keys would have taken a fairly short amount of time, given ANY software implementation; thus, I postulate that it probably was cracked before DVDJon became newsworthy, you just never heard about it.
They've gotten smarter with HDCP - they've required hardened hardware implementations only - which means it could take a fair bit of effort to crack, and that will be more reason for the large-scale commercial copyright-infringing operation to keep it a secret once they've done so.
You haven't heard of a crack of HDCP yet because there's no real need for it yet, and anyone smart enough to crack it is probably smart enough to keep it quiet until the industry has locked itself into using it.
If the HDMI port doesn't support the version of HDCP that the player requires, it won't send a digital signal at all, they'll be forced to use the degraded analog signal.
If it weren't for the stringent controls on content, there are several ways you could bypass the stuff you don't want to watch.
For example, you could copy just the movie to your own disc, then watch it.
Or you could download a player program to run on your computer to play it and allow you to skip the parts you don't want (or, in fact, to automatically skip ANY part that is marked as unskippable).
Or you could buy or modify a player that doesn't prevent you from skipping - with no protection on the content, it would be difficult to prevent anyone from making a player that can do whatever it wants. If there were no DMCA, it would be legal to modify your player to work the way you want it to.
There are quite a few other files that affect the machine (and other users, if any) that can be modified by group=admin without needing to request privileges. Lots of things in/Library, for instance. They did fix some of the startup services handling in the latest version to require that those files be secure (owned and writable only by root) - in earlier versions, it was possible to install a startup service that would run as root at next system start. There are plenty of others.
I always set up machines with an administrator user, and make all other users be non-administrator. It is absolutely simple to do, and the only thing I've found that doesn't work right is, tada, the Microsoft Office Test Drive program... it requires you to be admin when you first run the program (by failing in non-obvious ways), and then fails in other non-obvious ways if you try to run it with a different user (admin or not). Good going, Microsoft!
I find a 3-blade razor does reduce irritation a lot for me. Single and two-blade cause a lot of problems, the 3-blade (Mach-3) was the first razor I found I could use without causing problems. It reduces the pressure and pull on each blade, seems to keep each blade sharper for longer.
Now the 5-blade version may be overkill, haven't tried it since the 3-blade works fine. It did remind me of the SNL "commercial", though.
This patent has absolutely NOTHING to do with rendering methods. It is strictly referring to doing 3-D transforms, whether it is rendered as vector-drawn line graphics or raster-based textured polygons.
The only thing I can see possibly being unique about this, comparing it to flight simulators and other 3-D programs from the '70s (one of the first programs I wrote was a 4-D transform (of which 3-D is a special case) - displayed a 4-D hypercube) is the phrase "the viewing space being movable at a selected radial distance around a selected reference point in the modeling space". So if you have a movable camera viewpoint (other than first person, which this clearly can't be talking about, since there is loads of prior art for that), don't make it be movable at a selected radial distance from some selected point - move the camera directly, not in reference to a fixed point in the environment. I'd think that a "chase plane" camera position would be fine, for example (it isn't a "selected radial distance" from a "selected point", it's a variable distance from a moving point. On the other hand, my hypercube viewing program specified a distance and a general rotation vector from which to view the hypercube, so even that sounds like it would be prior art. Just a 4x4 rotation matrix. Only difference for my simple program is that it always looked at the hypercube, didn't allow you to pan elsewhere. If there had been anything else in my little world, I think it would have been "obvious" to allow panning as well.
There was nothing magical or unique about doing 3-D transforms, panning, yawing, pitching or rolling, which is all this patent talks about, not in 1987, nor even in 1984 for the application this is a continuation of.
Actually, it depends on when the patent was issued - older ones are 17 years from issue, newer ones are 20 years from application. See the Wikipedia article. The cutoff date was June 8, 1995. In 2015 we won't have to worry about that any more, unless there's a REALLY deeply-submarined patent still pending...not sure if the rules on that would allow a pending application at that time to still be pending and still get 17 years after issue.
Also, if it's an old VCR, it might not be susceptible to Macrovision. Macrovision only worked on some VCRs, until Congress mandated that all VCRs make themselves actively detect it (and pay royalties to Macrovision for the privilege, since it is patented - you also have to pay royalties to Macrovision to turn on the bit on the DVD you're producing that tells the DVD player to turn on the Macrovision circuits, which, of course, had royalties paid by the player's manufacturer). Isn't it great to have Congress rescue your unreliable protection scheme by legislating that it WILL in fact work, and now (since it WORKS SO WELL) everyone must use it? Microsoft patenting zero has nothing on it!
Just look up Paramount and call them, explain what you want. You'll eventually be routed to the person who sends out replacement discs. I ended up talking to them when the box was damaged - once they had sent out all of the discs as replacements from a box, they sent it to me.
Is the software that you're reverse engineering protected (e.g. by encryption) to prevent you from making unauthorized copies? That's the only thing the DMCA protects against.
Doing something like running the software in an emulator in order to trace the hardware access it makes (and then playing man-in-the-middle to the real hardware) is not prohibited by the DMCA. You are not doing it to copy the software, the tools don't enable you to copy the software without authorization. Now, properly done, the real hardware is going to make it real difficult to do this, but doing it isn't a violation of anything in the copyright law.
Using what you find out to build a tool that allows you to make unauthorized copies of the operating system, or modify the operating system to allow you to make unauthorized copies of other things, is of course still not allowed. Using what you find out to build your own bootloader to load Linux is perfectly fine.
So far, however, all that the TPC seems to be doing is allowing the owner of the computer to secure content on it from users of the computer - owner being a business, user being an employee. While there are grave implications for third parties (e.g. Microsoft, RIAA) being able to lock out the owner of the computer from being able to do certain things, that can only happen if you let it - don't buy computers that only allow you to boot Microsoft-signed operating systems, don't buy content that doesn't let you use it the way you want to. Resist at all costs any attempts to allow Internet access only to "trusted" operating systems running on "trusted" hardware.
I think you overestimate the size of source code. I just looked at the NeoOffice package (Open Office for Native OSX); the binary install package is about 122.8MB, the source code is about 2.2MB. Barely a drop in the bucket. The disk image file is 123.9MB.
DMCA wouldn't prevent reverse-engineering this. The hardware might make it difficult, but there's no copyright being violated by figuring out how to load your own operating system. DMCA doesn't say you can't analyze or reverse engineer such a system, especially if it isn't being used to protect copyright!
True, but this is about distributing low-voltage DC throughout the house, NOT transmitting it long distances. You'd still want high-voltage in the house for high-power applications (electric dryer, AC, electric stove), but low voltage DC would be better for most electronics, maybe even for lighting if you switch over to LEDs or other "cold" lighting, where you don't need all that excess power to produce heat.
I've wondered about whether it would be possible to create a low-power converter that would take in any voltage, any frequency, ignore polarity, and put out whatever internal voltage was required, that would use microwatts when not in use. Plug it in to anything, from solar cells, rechargeable batteries (1, 2, or 20), 12VDC, 48VDC, 120VAC, 240VAC...
I get tired of battery powered devices that are designed to run on alkaline, and think a NiMH battery is almost out because it runs at a slightly lower voltage.
There was never anything inherent about SCSI that made it more expensive, just economies of scale. When 3.5" diskettes were first introduced for the Mac, a box of 10 400K diskettes cost about $50. It wasn't until the PC market decided to use them that they came down in price. If Dell, HP and Gateway had for some reason decided to produce a bunch of machines with SCSI, it could have become the standard instead of IDE, and SCSI disks would be the same price as IDE disks are today.
Saying that SCSI used a "proprietary chip" makes no sense. Pretty much ALL chips are "proprietary" - SCSI, IDE, USB, Firewire. None of them are inherently more expensive than the others, it all depends on volume.
SCSI IS more sensitive to cabling and termination, which makes it a bit more fussy to use. This is because it is more capable than IDE
for connecting multiple devices over longer distances. Since most home users don't need that extra capability, IDE probably was the right way to go.
"Zero knowledge proofs" don't mean you have no knowledge of the method of proof! Yes, you can show that you have some secret piece of information without giving that information away, but the actual method of doing the watermarking isn't going to be something you can prove to a court that it works without actually showing that it works. They can keep a secret key secret, so no one else can watermark their own works with their mark, but so what?
What they'd need to do is have an open-source program that, given the secret key, spits out the hidden watermark info. They take the file in question, put it on a court-provided computer with said program, enter in the secret key, and the defendant's name pops out.
Without the secret key, you wouldn't be able to tell if there is a watermark in a particular file, much less what the hidden information is, but you could use the knowledge of the watermarking method to figure out methods of defeating it.
There are schemes that are resistant to trying to combine/eliminate differences from several marked files, such that all of the files
involved can be traced. However, if you know the number of bits encoded in the watermark, you could probably bypass any such scheme by using at least that number of files to detect the differences.
Also, I haven't heard of any such schemes which are also resistant to passage through a digital-analog-digital route, or even simple
transcoding. Also, even schemes which are resistant to one form of lossy compression may not be resistant to another - so something that works great with MP3 may fail totally with Ogg. And many such schemes will fail totally if you add your own watermarking scheme to it, even if you can't extract the original, and of course if you have a pretty good idea of how the watermarking works, use the same to encode random information for maximum amusement.
I see no fundamental difference between saying "you can't use my software combined with other software unless all of that software combination can be modified" and "you can't use my software combined with hardware unless all of that software/hardware combination can be modified".
Just as you can't take my open-source code, stick it in a closed-source program, and think you can satisfy the GPLv2 by publishing only the open-source portion, why should you be able to do the exact same thing except you're using a chunk of closed-source firmware? Even if you publish the firmware, along with the public key it uses to verify binaries, the nature of hardware vs. software makes that firmware immutable without taking extraordinary measures. The very essence of the GPL is the freedom to tinker - GPL software should not be part of a software/hardware combination that prevents you from doing that.
At the same time, there is certainly value to having signed data for verification -but only at the option of the end-user. I have no problem with a box that has a user-settable option to allow unsigned binaries, or allow for additional signing keys. Obviously, any warranty would only cover factory-signed binaries (unless you could show deliberate malfunction solely because you're using "unauthorized" additions). Having the firmware be open source and easily re-flashable by the end-user would also be an acceptable option.
About the only thing using x86 chips gets you is faster Windows emulation, since you no longer have to emulate the instruction set. Being "compatible" won't magically make programs automatically run on Mac OS. The only real issue would be endian problems, or for the G5, word size, but those are so easy to handle in code (even in those cases where people aren't writing stuff in 20-layers-from-the-hardware) that, by now, it shouldn't be an issue. The x86 family created most of those problems in the first place.
Reminds me of when I was in a Sam's Club, they had a DVD player connected to a large widescreen TV, playing some widescreen movie. Except it was letter-boxed inside a postcarded screen. I checked the setup of the player, changed it to be screen type=16:9, and started it up again. Bing, nice widescreen image. I mentioned it to the guy in electronics about 10 minutes later, that it had been set wrong and I fixed it. He got all upset: "Customers LIKE it like that." he insisted. 20 minutes later, as I was leaving, he was STILL fiddling with the TV setup (not the DVD setup) trying to figure out how to make it look crappy again.
What plasma TVs only have 488 lines (are you talking horizontal "lines of resolution" or vertical scan lines?) All of the plasma sets I see are HD or at least ED, typically with 1024x768 for the former, the latter typically at 852x480 for a 42" set (which is about 36.6x20.6 inches; that gives about 28 dpi horizontally and 37 dpi vertically for the HD sets, or 23 dpi for the ED sets, if the screens are 16:9). You don't get full HD resolution until you get to bigger screens; even 50 and 63" plasma seem to be mostly 1366x767, at least it's a square resolution (31 dpi for the 50", 25 dpi for the 63"). Full HD resolution is 1920x1080.
Slashdot Mirror
The real problem isn't bogus stats caused by line inflation. The real problem is that it only finds certain types of bugs. If a bug causes an incorrect result or improper behavior, but doesn't cause a memory leak or the like that crashes the program or system, then it isn't being found. It also isn't finding STUPID code - code that works but is ridiculously convoluted, slow, difficult to modify, redundant (writing 5000 lines of code to do some string manipulation and parsing that could be done just as easily and efficiently using a RE library, or use lex, or some other straightforward solution - I've seen code that re-implemented several of the standard library string routines, and to add insult to injury, did it poorly and with a memory leak - at least these guys would have found the memory leak, but their solution would probably be to fix the leak, not toss the whole routine). C++ programmers seem to do this kind of thing particularly often, although many "object oriented" programmers can screw things up in multiple languages with equal facility.
What are you doing to further your plans of being quite dead by then? Myself, I'm planning on being quite alive by then, though probably not on this planet.
Yeah, this was hardly "unimaginable" a few years ago. It was more like "what do you mean, none of this stuff really works the way it ought to?"
AJAX is just a hack on top of a kludge to try to make a stateless batch protocol into a persistent interactive "experience". HTTP works fine for what it was designed for, HTML works fine for what it was designed for, AJAX reminds me of the classic Yiddish joke about the tailor:
No, it doesn't have pixels, but it does have a maximum bandwidth, which limits how sharp edges can be, for example, or how close two edges or color changes can be to each other. This is normally expressed as lines of resolution.
It took 3 years for a known crack to be found. Given the realities of code tracing, any serious attempt to figure out the algorithm and keys would have taken a fairly short amount of time, given ANY software implementation; thus, I postulate that it probably was cracked before DVDJon became newsworthy, you just never heard about it.
They've gotten smarter with HDCP - they've required hardened hardware implementations only - which means it could take a fair bit of effort to crack, and that will be more reason for the large-scale commercial copyright-infringing operation to keep it a secret once they've done so.
You haven't heard of a crack of HDCP yet because there's no real need for it yet, and anyone smart enough to crack it is probably smart enough to keep it quiet until the industry has locked itself into using it.
If the HDMI port doesn't support the version of HDCP that the player requires, it won't send a digital signal at all, they'll be forced to use the degraded analog signal.
If it weren't for the stringent controls on content, there are several ways you could bypass the stuff you don't want to watch.
For example, you could copy just the movie to your own disc, then watch it.
Or you could download a player program to run on your computer to play it and allow you to skip the parts you don't want (or, in fact, to automatically skip ANY part that is marked as unskippable).
Or you could buy or modify a player that doesn't prevent you from skipping - with no protection on the content, it would be difficult to prevent anyone from making a player that can do whatever it wants. If there were no DMCA, it would be legal to modify your player to work the way you want it to.
There are quite a few other files that affect the machine (and other users, if any) that can be modified by group=admin without needing to request privileges. Lots of things in /Library, for instance. They did fix some of the startup services handling in the latest version to require that those files be secure (owned and writable only by root) - in earlier versions, it was possible to install a startup service that would run as root at next system start. There are plenty of others.
I always set up machines with an administrator user, and make all other users be non-administrator. It is absolutely simple to do, and the only thing I've found that doesn't work right is, tada, the Microsoft Office Test Drive program... it requires you to be admin when you first run the program (by failing in non-obvious ways), and then fails in other non-obvious ways if you try to run it with a different user (admin or not). Good going, Microsoft!
I find a 3-blade razor does reduce irritation a lot for me. Single and two-blade cause a lot of problems, the 3-blade (Mach-3) was the first razor I found I could use without causing problems. It reduces the pressure and pull on each blade, seems to keep each blade sharper for longer.
Now the 5-blade version may be overkill, haven't tried it since the 3-blade works fine. It did remind me of the SNL "commercial", though.
It's not quite as bad as "Webinar". On the other hand, I just heard the term "webisode", and I rather like that one.
This patent has absolutely NOTHING to do with rendering methods. It is strictly referring to doing 3-D transforms, whether it is rendered as vector-drawn line graphics or raster-based textured polygons.
The only thing I can see possibly being unique about this, comparing it to flight simulators and other 3-D programs from the '70s (one of the first programs I wrote was a 4-D transform (of which 3-D is a special case) - displayed a 4-D hypercube) is the phrase "the viewing space being movable at a selected radial distance around a selected reference point in the modeling space". So if you have a movable camera viewpoint (other than first person, which this clearly can't be talking about, since there is loads of prior art for that), don't make it be movable at a selected radial distance from some selected point - move the camera directly, not in reference to a fixed point in the environment. I'd think that a "chase plane" camera position would be fine, for example (it isn't a "selected radial distance" from a "selected point", it's a variable distance from a moving point. On the other hand, my hypercube viewing program specified a distance and a general rotation vector from which to view the hypercube, so even that sounds like it would be prior art. Just a 4x4 rotation matrix. Only difference for my simple program is that it always looked at the hypercube, didn't allow you to pan elsewhere. If there had been anything else in my little world, I think it would have been "obvious" to allow panning as well.
There was nothing magical or unique about doing 3-D transforms, panning, yawing, pitching or rolling, which is all this patent talks about, not in 1987, nor even in 1984 for the application this is a continuation of.
Actually, it depends on when the patent was issued - older ones are 17 years from issue, newer ones are 20 years from application. See the Wikipedia article. The cutoff date was June 8, 1995. In 2015 we won't have to worry about that any more, unless there's a REALLY deeply-submarined patent still pending...not sure if the rules on that would allow a pending application at that time to still be pending and still get 17 years after issue.
Also, if it's an old VCR, it might not be susceptible to Macrovision. Macrovision only worked on some VCRs, until Congress mandated that all VCRs make themselves actively detect it (and pay royalties to Macrovision for the privilege, since it is patented - you also have to pay royalties to Macrovision to turn on the bit on the DVD you're producing that tells the DVD player to turn on the Macrovision circuits, which, of course, had royalties paid by the player's manufacturer). Isn't it great to have Congress rescue your unreliable protection scheme by legislating that it WILL in fact work, and now (since it WORKS SO WELL) everyone must use it? Microsoft patenting zero has nothing on it!
Just look up Paramount and call them, explain what you want. You'll eventually be routed to the person who sends out replacement discs. I ended up talking to them when the box was damaged - once they had sent out all of the discs as replacements from a box, they sent it to me.
Is the software that you're reverse engineering protected (e.g. by encryption) to prevent you from making unauthorized copies? That's the only thing the DMCA protects against.
Doing something like running the software in an emulator in order to trace the hardware access it makes (and then playing man-in-the-middle to the real hardware) is not prohibited by the DMCA. You are not doing it to copy the software, the tools don't enable you to copy the software without authorization. Now, properly done, the real hardware is going to make it real difficult to do this, but doing it isn't a violation of anything in the copyright law.
Using what you find out to build a tool that allows you to make unauthorized copies of the operating system, or modify the operating system to allow you to make unauthorized copies of other things, is of course still not allowed. Using what you find out to build your own bootloader to load Linux is perfectly fine.
So far, however, all that the TPC seems to be doing is allowing the owner of the computer to secure content on it from users of the computer - owner being a business, user being an employee. While there are grave implications for third parties (e.g. Microsoft, RIAA) being able to lock out the owner of the computer from being able to do certain things, that can only happen if you let it - don't buy computers that only allow you to boot Microsoft-signed operating systems, don't buy content that doesn't let you use it the way you want to. Resist at all costs any attempts to allow Internet access only to "trusted" operating systems running on "trusted" hardware.
I think you overestimate the size of source code. I just looked at the NeoOffice package (Open Office for Native OSX); the binary install package is about 122.8MB, the source code is about 2.2MB. Barely a drop in the bucket. The disk image file is 123.9MB.
DMCA wouldn't prevent reverse-engineering this. The hardware might make it difficult, but there's no copyright being violated by figuring out how to load your own operating system. DMCA doesn't say you can't analyze or reverse engineer such a system, especially if it isn't being used to protect copyright!
True, but this is about distributing low-voltage DC throughout the house, NOT transmitting it long distances. You'd still want high-voltage in the house for high-power applications (electric dryer, AC, electric stove), but low voltage DC would be better for most electronics, maybe even for lighting if you switch over to LEDs or other "cold" lighting, where you don't need all that excess power to produce heat.
I've wondered about whether it would be possible to create a low-power converter that would take in any voltage, any frequency, ignore polarity, and put out whatever internal voltage was required, that would use microwatts when not in use. Plug it in to anything, from solar cells, rechargeable batteries (1, 2, or 20), 12VDC, 48VDC, 120VAC, 240VAC...
I get tired of battery powered devices that are designed to run on alkaline, and think a NiMH battery is almost out because it runs at a slightly lower voltage.
There was never anything inherent about SCSI that made it more expensive, just economies of scale. When 3.5" diskettes were first introduced for the Mac, a box of 10 400K diskettes cost about $50. It wasn't until the PC market decided to use them that they came down in price. If Dell, HP and Gateway had for some reason decided to produce a bunch of machines with SCSI, it could have become the standard instead of IDE, and SCSI disks would be the same price as IDE disks are today.
Saying that SCSI used a "proprietary chip" makes no sense. Pretty much ALL chips are "proprietary" - SCSI, IDE, USB, Firewire. None of them are inherently more expensive than the others, it all depends on volume.
SCSI IS more sensitive to cabling and termination, which makes it a bit more fussy to use. This is because it is more capable than IDE for connecting multiple devices over longer distances. Since most home users don't need that extra capability, IDE probably was the right way to go.
"Zero knowledge proofs" don't mean you have no knowledge of the method of proof! Yes, you can show that you have some secret piece of information without giving that information away, but the actual method of doing the watermarking isn't going to be something you can prove to a court that it works without actually showing that it works. They can keep a secret key secret, so no one else can watermark their own works with their mark, but so what?
What they'd need to do is have an open-source program that, given the secret key, spits out the hidden watermark info. They take the file in question, put it on a court-provided computer with said program, enter in the secret key, and the defendant's name pops out.
Without the secret key, you wouldn't be able to tell if there is a watermark in a particular file, much less what the hidden information is, but you could use the knowledge of the watermarking method to figure out methods of defeating it.
There are schemes that are resistant to trying to combine/eliminate differences from several marked files, such that all of the files involved can be traced. However, if you know the number of bits encoded in the watermark, you could probably bypass any such scheme by using at least that number of files to detect the differences.
Also, I haven't heard of any such schemes which are also resistant to passage through a digital-analog-digital route, or even simple transcoding. Also, even schemes which are resistant to one form of lossy compression may not be resistant to another - so something that works great with MP3 may fail totally with Ogg. And many such schemes will fail totally if you add your own watermarking scheme to it, even if you can't extract the original, and of course if you have a pretty good idea of how the watermarking works, use the same to encode random information for maximum amusement.
I see no fundamental difference between saying "you can't use my software combined with other software unless all of that software combination can be modified" and "you can't use my software combined with hardware unless all of that software/hardware combination can be modified".
Just as you can't take my open-source code, stick it in a closed-source program, and think you can satisfy the GPLv2 by publishing only the open-source portion, why should you be able to do the exact same thing except you're using a chunk of closed-source firmware? Even if you publish the firmware, along with the public key it uses to verify binaries, the nature of hardware vs. software makes that firmware immutable without taking extraordinary measures. The very essence of the GPL is the freedom to tinker - GPL software should not be part of a software/hardware combination that prevents you from doing that.
At the same time, there is certainly value to having signed data for verification -but only at the option of the end-user. I have no problem with a box that has a user-settable option to allow unsigned binaries, or allow for additional signing keys. Obviously, any warranty would only cover factory-signed binaries (unless you could show deliberate malfunction solely because you're using "unauthorized" additions). Having the firmware be open source and easily re-flashable by the end-user would also be an acceptable option.
About the only thing using x86 chips gets you is faster Windows emulation, since you no longer have to emulate the instruction set. Being "compatible" won't magically make programs automatically run on Mac OS. The only real issue would be endian problems, or for the G5, word size, but those are so easy to handle in code (even in those cases where people aren't writing stuff in 20-layers-from-the-hardware) that, by now, it shouldn't be an issue. The x86 family created most of those problems in the first place.
Reminds me of when I was in a Sam's Club, they had a DVD player connected to a large widescreen TV, playing some widescreen movie. Except it was letter-boxed inside a postcarded screen. I checked the setup of the player, changed it to be screen type=16:9, and started it up again. Bing, nice widescreen image. I mentioned it to the guy in electronics about 10 minutes later, that it had been set wrong and I fixed it. He got all upset: "Customers LIKE it like that." he insisted. 20 minutes later, as I was leaving, he was STILL fiddling with the TV setup (not the DVD setup) trying to figure out how to make it look crappy again.
What plasma TVs only have 488 lines (are you talking horizontal "lines of resolution" or vertical scan lines?) All of the plasma sets I see are HD or at least ED, typically with 1024x768 for the former, the latter typically at 852x480 for a 42" set (which is about 36.6x20.6 inches; that gives about 28 dpi horizontally and 37 dpi vertically for the HD sets, or 23 dpi for the ED sets, if the screens are 16:9). You don't get full HD resolution until you get to bigger screens; even 50 and 63" plasma seem to be mostly 1366x767, at least it's a square resolution (31 dpi for the 50", 25 dpi for the 63"). Full HD resolution is 1920x1080.