As long as DRM-enabled hardware runs non-DRM-enabled software...
Therein lays the heart of the problem. Soon enough you won't be able to run non-certified binaries on DRM hardware, and DRM will be a requirement for the binaries to be certified... erm, digitally signed.
And don't think of it as a doomsday scenario, it's already happening on certain embedded devices (see the 2nd generation TiVo hardware).
Why does everything have to be so US-centric? Maybe people in the rest of the world don't want to have the DRM-ridden Intel platform pushed on them - then they'll have alternatives. As for those in the US, maybe the next time they'll think twice about whom they vote for.
So is the issue with the compiler at compile time or at runtime? In other words, is it:
a. compile on an AMD CPU, compiler detects that it runs on an AMD and generates a binary that runs slower on both AMD and Intel CPUs, or...
b. compile anywhere, generated binary checks whether it runs on Intel or AMD and runs slower on AMD?
First one is easy to check for - compile the same source on each of the 2 architectures and compare binaries. If not the same, QED. The second one is sneakier and needs debug/tracing.
Compare this to a Pocket PC, which has separate storage and program memory, and loading a program from the SD card works just like loading it from storage memory
Same holds true for PalmOS. There are separate areas in the memory for storage (storage memory) and for execution (dynamic memory or heap). To execute a program it has to be copied from a storage area (either internal storage memory or external card) to the heap. Then it executes the same no matter where it came from.
Doc Ruby: take foot, insert in mouth. Bonehead here is one of the early hackers of TiVo, he's been on the scene since 2000. He does know what he's talking about. Circumventing the protection measures on the series 2 is easy.
As for defeatism - it's you who displays such, not him.
Re:Finally catching up with Apple...
on
Longhorn Preview
·
· Score: 1
Apple switches to i386? Good heavens! I thought it was Pentium4!
Re:Finally catching up with Apple...
on
Longhorn Preview
·
· Score: 1
LOL. True if you only compare the desktop systems. If you compare the two in terms of uses as servers or embedded, you could as well read it the other way around.
Don't get me wrong - I appreciate geek history as much as the next... geek. I just never happened to come across this particular bit before. Thanks for sharing!
It's not in places like Portland and Burbank that you find the questionnable types, but in big airports like JFK in New York. Not long ago I have personally overheard there a conversation between two overweight women working for the TSA. They were making fun of the anatomy of a certain person waiting in line to be screened. I am so nauseated by that incident that I will strongly oppose ever being searched, even remotely like in this proposition, by any TSA employee. Even if it means missing my plane.
My local Best Buy store always has in stock at least 1 model of Bluetooth kb+mouse. Been thinking of getting one for some time, but at $150 they'd better not suck.
Heh, I just searched bestbuy.com and they sell an Apple keyboard with Bluetooth for $80 and an Apple Bluetooth mouse for the same price.
This sort of thing has indeed been going on for a long time, and was invented by "granddaddy" Intel. The oldest example of a chip manufacturer turning off some capabilities on their chips and selling them as a lower end product that I'm aware of happened in the 486 era. Intel released the 486DX as a high end, expensive product with integrated FPU for the first time. Then they released the 486SX as a low end budget priced chip. The 486SX did not have a FPU, but what Intel didn't tell (though it became known rather quickly) was that the SX chips were identical to the DX except that the FPU was turned off in the fab. Thus the same assembly line produced both DX and SX chips.
And Intel even went the next step. They later marketed an "upgrade" for the 486SX which "added" a FPU to those systems. That was the 487DX, which was supposed to be installed in a separate socket on the motherboard and work in tandem with the existing 486SX. Again what Intel didn't say was that the 487DX was in fact a 486DX, and when it was installed on the motherboard it would simply turn off the SX altogether and take over. You could remove the SX chip and throw it away and it wouldn't make a difference. The 487DX was priced below the 486DX, but you ended up paying more for the 486SX+487DX than for a regular 486DX. And to prevent people from buying 487DX chips and use them instead of 486DX, they made the socket pinouts incompatible.
Slashdot Mirror
As long as DRM-enabled hardware runs non-DRM-enabled software...
Therein lays the heart of the problem. Soon enough you won't be able to run non-certified binaries on DRM hardware, and DRM will be a requirement for the binaries to be certified... erm, digitally signed.
And don't think of it as a doomsday scenario, it's already happening on certain embedded devices (see the 2nd generation TiVo hardware).
Why does everything have to be so US-centric? Maybe people in the rest of the world don't want to have the DRM-ridden Intel platform pushed on them - then they'll have alternatives. As for those in the US, maybe the next time they'll think twice about whom they vote for.
Well then there'll be Via. Or some other Taiwanese/Indonesian/3rd world company that the US laws don't touch.
So is the issue with the compiler at compile time or at runtime? In other words, is it:
a. compile on an AMD CPU, compiler detects that it runs on an AMD and generates a binary that runs slower on both AMD and Intel CPUs, or...
b. compile anywhere, generated binary checks whether it runs on Intel or AMD and runs slower on AMD?
First one is easy to check for - compile the same source on each of the 2 architectures and compare binaries. If not the same, QED. The second one is sneakier and needs debug/tracing.
Compare this to a Pocket PC, which has separate storage and program memory, and loading a program from the SD card works just like loading it from storage memory
Same holds true for PalmOS. There are separate areas in the memory for storage (storage memory) and for execution (dynamic memory or heap). To execute a program it has to be copied from a storage area (either internal storage memory or external card) to the heap. Then it executes the same no matter where it came from.
Nah, I grew up.
Defeatism, as in your stating that it's impossible to modify the tivo software because the author of the article said so?
:)
Have some more foot, please.
Hi bonehead - long time no see. ;)
Doc Ruby: take foot, insert in mouth. Bonehead here is one of the early hackers of TiVo, he's been on the scene since 2000. He does know what he's talking about. Circumventing the protection measures on the series 2 is easy.
As for defeatism - it's you who displays such, not him.
Grammar is passé dude, get with the program. ;)
...and TotalRecorder does the same on Windows.
LOL good thinking. Conspiracy theorists unite!
Apple switches to i386? Good heavens! I thought it was Pentium4!
LOL. True if you only compare the desktop systems. If you compare the two in terms of uses as servers or embedded, you could as well read it the other way around.
"Attempted surgery" that's a new classic for my list. Thanks for the laugh!
No, it will be vaporware in 3 to 5 years. :)
The parent may have been modded funny, but that doesn't make it any less true.
Gives format C: a whole new meaning.
Don't get me wrong - I appreciate geek history as much as the next... geek. I just never happened to come across this particular bit before. Thanks for sharing!
It's not in places like Portland and Burbank that you find the questionnable types, but in big airports like JFK in New York. Not long ago I have personally overheard there a conversation between two overweight women working for the TSA. They were making fun of the anatomy of a certain person waiting in line to be screened. I am so nauseated by that incident that I will strongly oppose ever being searched, even remotely like in this proposition, by any TSA employee. Even if it means missing my plane.
Well in the '70s I was barely learning to read, and I wasn't around in the '60s so I have no experience with those. :)
But I did personally experience the 486 marketing ploy.
LOL
My local Best Buy store always has in stock at least 1 model of Bluetooth kb+mouse. Been thinking of getting one for some time, but at $150 they'd better not suck.
Heh, I just searched bestbuy.com and they sell an Apple keyboard with Bluetooth for $80 and an Apple Bluetooth mouse for the same price.
No, but you can run it on two 6800GTs and end up with 32 pipelines.
This sort of thing has indeed been going on for a long time, and was invented by "granddaddy" Intel. The oldest example of a chip manufacturer turning off some capabilities on their chips and selling them as a lower end product that I'm aware of happened in the 486 era. Intel released the 486DX as a high end, expensive product with integrated FPU for the first time. Then they released the 486SX as a low end budget priced chip. The 486SX did not have a FPU, but what Intel didn't tell (though it became known rather quickly) was that the SX chips were identical to the DX except that the FPU was turned off in the fab. Thus the same assembly line produced both DX and SX chips.
And Intel even went the next step. They later marketed an "upgrade" for the 486SX which "added" a FPU to those systems. That was the 487DX, which was supposed to be installed in a separate socket on the motherboard and work in tandem with the existing 486SX. Again what Intel didn't say was that the 487DX was in fact a 486DX, and when it was installed on the motherboard it would simply turn off the SX altogether and take over. You could remove the SX chip and throw it away and it wouldn't make a difference. The 487DX was priced below the 486DX, but you ended up paying more for the 486SX+487DX than for a regular 486DX. And to prevent people from buying 487DX chips and use them instead of 486DX, they made the socket pinouts incompatible.