If you have a normal DVD player, go out and rent the movie "The Sixth Sense". Slap it in the player. Watch as previews for other movies come up on the screen. Reach for your remote and push the "DVD Menu" button. Watch as your DVD player says "no".
That's what the MPAA wants the DVDCCA to protect: the "right" for them to control how you use the intellectual property they've sold you; or, as they'd have it, the intellectual property that they've given you precisely constrained access to. That's why DVD player manufacturers have to sign away their souls, and that's the real threat of DeCSS: if it's an open-source project, then somebody will port it to a mainstream platform like Windows, and then Mom and Dad can play DVD's without any manufacturer controls.
Imagine a world where Lawn Boy figured out a way to control a lawnmower engine so that it'd only mow a particular type of grass. Got St. Augustine in the front yard and Bermuda out back? Fine, just buy the St. Augustine lawnmower for the front yard and the Bermuda mower for the back. Lawn Boy would of course license the technology to every other lawn mower manufacturer, all of whom would be ecstatic to have such a sales-boosting technology at their disposal. Then, of course, they'd all get together and tell the government that people who tinker with their lawnmowers to disable the "Grass Security System" are just doing it because they want to kidnap children and use the modified mowers for terrorist acts and drug-related murders. As a society, we must stand up to the criminal element and outlaw illegal mower mutilation.
Nobody would willingly put up with a world like that except the people who'd stand to reap windfall profits. But that's really exactly what the MPAA wants.
Alternative DeCSS Publishing
on
More on LinDVD
·
· Score: 2
How useful would a non-source-code paper about CSS and DeCSS be? A document describing the encryption algorithm and how it is used in thorough detail, but not in the form of source code in some programming language, would be much closer to the "protected speech" most judges are familiar with. Yes, it could still be challenged on trade secret grounds, I suppose.
You don't want to guarantee that a task gets X% of the CPU. That's not usually the way a real-time system works. What you want to do is guarantee that an event can be responded to within a well-defined maximum time window. That translates into the kernel being able to preempt a running thread and start up a waiting thread as fast as possible.
To do that, it's necessary to minimize the amount of time spent in hardware-locked interrupt routines. The kernel can't context switch while it's handling a low-level interrupt. You therefore have to get out of those as quickly as possible and transfer control to a thread that does the bulk of the handler work.
Context switching in real-time systems is generally an area of great optimization, since it reduces the maximum response time.
No, actually all these claims that real-time imposes a lot of additional overhead are totally false, or at least not necessarily true by any means. Real-time systems have to compete on response time, and you don't get response time any better by slowing things down.
Back when I was at Lynx (a long long long time ago), we benchmarked simple things like round-trips into the kernel versus SVR3 (the current competitor) and noted that our kernel was at least 10 times faster. User experience bore out the tests, as Lynx in use was just tremendously faster than System V.
The main problem with real-time systems is that the preemptive scheduler is not tuned for "multi user" or "time sharing" behavior. If a high-priority task gets the CPU, then it gets it completely. As long as it doesn't block, the kernel will only preempt it for higher-priority threads. That's not necessarily what you want in a general-purpose server, but on the other hand a web server might actually benefit (assuming somebody took the time to configure the system appropriately).
Slashdot Mirror
If you have a normal DVD player, go out and rent the movie "The Sixth Sense". Slap it in the player. Watch as previews for other movies come up on the screen. Reach for your remote and push the "DVD Menu" button. Watch as your DVD player says "no".
That's what the MPAA wants the DVDCCA to protect: the "right" for them to control how you use the intellectual property they've sold you; or, as they'd have it, the intellectual property that they've given you precisely constrained access to. That's why DVD player manufacturers have to sign away their souls, and that's the real threat of DeCSS: if it's an open-source project, then somebody will port it to a mainstream platform like Windows, and then Mom and Dad can play DVD's without any manufacturer controls.
Imagine a world where Lawn Boy figured out a way to control a lawnmower engine so that it'd only mow a particular type of grass. Got St. Augustine in the front yard and Bermuda out back? Fine, just buy the St. Augustine lawnmower for the front yard and the Bermuda mower for the back. Lawn Boy would of course license the technology to every other lawn mower manufacturer, all of whom would be ecstatic to have such a sales-boosting technology at their disposal. Then, of course, they'd all get together and tell the government that people who tinker with their lawnmowers to disable the "Grass Security System" are just doing it because they want to kidnap children and use the modified mowers for terrorist acts and drug-related murders. As a society, we must stand up to the criminal element and outlaw illegal mower mutilation.
Nobody would willingly put up with a world like that except the people who'd stand to reap windfall profits. But that's really exactly what the MPAA wants.
How useful would a non-source-code paper about CSS and DeCSS be? A document describing the encryption algorithm and how it is used in thorough detail, but not in the form of source code in some programming language, would be much closer to the "protected speech" most judges are familiar with. Yes, it could still be challenged on trade secret grounds, I suppose.
Just a thought.
Alpha runs the Alpha AXP instruction set. It's kinda MIPS-like. Definitely not x86.
The key to doing this right is to have a very, very limited microkernel with fast message-passing.
Well, that's certainly the QNX way of doing things, but I think it's a stretch to call it "the key".
You don't want to guarantee that a task gets X% of the CPU. That's not usually the way a real-time system works. What you want to do is guarantee that an event can be responded to within a well-defined maximum time window. That translates into the kernel being able to preempt a running thread and start up a waiting thread as fast as possible.
To do that, it's necessary to minimize the amount of time spent in hardware-locked interrupt routines. The kernel can't context switch while it's handling a low-level interrupt. You therefore have to get out of those as quickly as possible and transfer control to a thread that does the bulk of the handler work.
Context switching in real-time systems is generally an area of great optimization, since it reduces the maximum response time.
No, actually all these claims that real-time imposes a lot of additional overhead are totally false, or at least not necessarily true by any means. Real-time systems have to compete on response time, and you don't get response time any better by slowing things down.
Back when I was at Lynx (a long long long time ago), we benchmarked simple things like round-trips into the kernel versus SVR3 (the current competitor) and noted that our kernel was at least 10 times faster. User experience bore out the tests, as Lynx in use was just tremendously faster than System V.
The main problem with real-time systems is that the preemptive scheduler is not tuned for "multi user" or "time sharing" behavior. If a high-priority task gets the CPU, then it gets it completely. As long as it doesn't block, the kernel will only preempt it for higher-priority threads. That's not necessarily what you want in a general-purpose server, but on the other hand a web server might actually benefit (assuming somebody took the time to configure the system appropriately).