Not to perpetuate the arguement (with an AC), but... BSD uses the (surprise) BSD partitioning. BSD and it's method of partitioning existed long before the IBM PC and this stupid four partitions method. One can setup linux to use the BSD partitioning, but people usually don't (on x86 hardware anyway.)
My alpha will partition the disk either way depending on what OS you have set it to run -- sadly, it was designed to run NT, but that ain't what it's running. If you want to be sick, you can setup a sparc/linux machine with a DOS style partition table (please don't do that.)
Placing it in the kernel doesn't automatically make it secure either. This isn't windows 95; serious thought and care needs to be used in placing code in the kernel. Alot of stuff wired into the kernel doesn't belong there -- we aren't reinventing a NetApp here.
You can "kill" proceses; you cannot "kill" part of the kernel.
Gez, they'll remove rarp saying "it's really a userland thing." But they'll wire nfsd and httpd into the kernel...
Yes, there are some significant gains from putting the nfs server in the kernel -- closer access to the files and networking plus access to the buffer cache. However, it introduces one hell of a security problem. Buffer overflows in userland typically kill the application -- or if crafted can run other stuff. But a buffer overflow in the kernel can do nine kinds of hell -- and a crafted overflow could erase the motherboard BIOS.
(I'm certain someone will say the BIOS could be killed from userland overflows as well, but not without alot more work.)
There are various reasons for that -- some are historic ties to the days when hard drives were too small to hold everything in one partition.
For the most part, "/" is tiny to reduce filesystem check times, reduce the chances of corruption (nothing changes very often), and better optimize the partition for the number of tiny files it holds. "/usr" is a partition so it can be mounted read-only -- this is a performance gain for some OSes. "/var" is it's own local partition as that's where volatile/transient/temporary stuff is kept -- you know,/var/run,/var/log,/var/adm, etc. Etc. Etc.
Linux systems tend to have only a single partition due to the (stupid) lack of space for partitions on "PC" hardware. This is one of a long list of stupid things in the "PC" world.
The answer to your question is "yes." There are many things that can be done to the system by and/or during the boot sequence. I will not provide any details, however -- this is left as an exercise for the reader.
There are a few road-blocks, however. Altering the boot record(s) requires direct access to the disk -- something that usually requires explicit priviledge. Additionally, priviledge is required to alter lilo's map file. AND, there are size constraints on how big lilo (and resulting virii code(s)) can be -- remember lilo starts in standard ("i can only see 1MB") mode with only BIOS calls at it's fingers.
Sure they can (and they have suggested it.) Firmware and microcode updates to drives and players. Software can obviously be rewritten.
I'm all for replacing CSS. If they want it to be protected from duplication then develop technology to prevent duplication not block all access to the damned disk entirely. Scrambling the data just makes it harder to play back; it does nothing to stop duplication. You can triple-DES encode stuff ten times; it's just as copyable in the end as it is at any point in the process.
I would like to point out that there are 500 Does on that suit. It would not be very difficult to put names to each of them. Also, all the injuction does is prevent them from distributing the stuff -- no one has ordered them to destroy their copies. (yet.)
While I don't like this at all, the judge is acting properly in doing this. Neither side has said anything to assure him who's going to prevail. He's 100% correct in saying the injunction does not harm the defendants -- they aren't going to go broke because they cannot distribute CSS. Failing to prevent further spread of CSS would be disasterous for DVD CCA should they win in a full court.
$10k bond:-) That's a nice gesture, but I'm sure DVD CCA will gladly pay that on the spot with a smile.
Trademark-wise, they have no legs to stand on (and I think they knew that to begin with, but lawyers need practice:-))
Copyright-wise, they have a fully loaded, double-barrel shutgun (and a box of shells.) I'm sure they've had a few words with Xing privately for not adequately protecting the CSS technology, but you cannot put the smoke back in the chip (you fan the smoke away and replace the chip.) It doesn't matter what DeCSS was intended to do; it's only commercially significant purpose (to use the DMCA terms) is to remove the copy protection of a DVD -- it copies files from protected DVDs, descrambling them in the process, to your hard drive. I'd like to see a lawyer convence this judge otherwise. (MPAA's got us on that one.)
DeCSS is a windows program -- that's not very useful to linux developers. Furthermore, DeCSS.zip doesn't contain any actual source code. I've never seen the DeCSS source code. At any rate, as I've been told, it's x86 assemble ripped (almost?) verbatum from the Xing player. (that's a clear copyright violation.) This source code was made available to Derek Fawcus (I hope I spelled that right) who took on the daunting task of turning that stuff into C code. (that's not so clearly a copyright violation.) Now, I'm sure Xing didn't write this stuff in asm -- I'd bet C++. Turning asm into C isn't blindingly simple; turning compiled C++ crypto code back into C is frighteningly complicated.
The css-auth code from Derek is very useful code. It can do the same thing DeCSS does, but that's clearly not its intent nor is that remotely its primary commercially significant purpose. My concern as a LiVid developer is not to decode the crap on the disk but to be able to authenticate the disk so I can see the files and thus present them to the decoder hardware AND be able to broker the titlekeys as the decoder has no direct communication channel to the drive to do it on its own (if it could, I sure as hell would make it do it.)
In my book, software decoding of DVDs is a serious waste of processing. Decoding MPEG-2 data is a very computational task best handled by hardware designed to handle it.
As for your comment on "pay[ing up]"... CSS licensing is free. However, it doesn't happen overnight. When the Matrox DVD add-on is sufficiently functional, then and only then will I make a case for getting an actual license for a player. Until we have a reason to need one, why bother asking? (The driver may be functional tomorrow and it may be six months. And ZORAN will be the first people to be asked for any licensing... we need their microcode -- currently, you have to have the Matrox Zoran SoftDVD software installed.)
Actually, it's both. In all seriousness, CSS is copy protection, albeit damned weak. You cannot access the disk (assuming the DVD drive follows the rules) without going through the first phase of CSS to authenticate yourself to the drive. Beyond that, "copy away." (files are files, to the computer, it's just a bunch of bits.) Of course, this is just as effective as the copy protection of playstation disks.
Then it becomes a rather effective playback protection as you cannot play the movie back without undoing what CSS does to the files. In some cases, the hardware doing the decoding can handle the actual descrambling once it has the appropriate keys (the dxr2 can do this and I'm sure the Vaddis III can too with proper microcode.) BUT, you have to jump through a few hoops to get the titlekeys for the descrambling process.
This is all a bloody mess. I would bet everyone involved with DVD technology knew this crap was crap from the get go -- I'm surprised they weren't better prepared to counter DeCSS.
The DVD movies already _are_ being reverse-engineered. Progress is being made on determining all the funky "magic" of the IFO and VOB file formats. However, no one has lifted a finger to prevent these actions or the spread of the information (yet.) Maybe this is plan C and maybe they know they have no legal recourse to prevent it outside of CSS scrambling the files.
Understanding of the file format is useless if you cannot read the file.
While the physical machine may be outside the country, you aren't. There may be some protection for the information on the machine, but there's little stopping "them" from holding you responsible for the contents of the machine and arresting you.
Yes, I've thought about this too with respect to export controlls on encryption, but as a US citizen (on US soil) I would still be responsible for "munitions" on the machine.
Laws can be soo damned annoying. (anyone want to colo on the moon?)
Small news flash... Ghostscript has a pdfwrite driver. Personally, I've never used it, but I compiled it in there. Also, try looking at StarOffice -- it's not perfect, but it fills a void and provides an excellent example.
I would guess they want something semi-portable that still has some markup. HTML is far from a usable document standard -- it's too browser specific and would require stylesheets and other bells to have the same level of markup.
I would recommend pdf format and pepper it with "sticky notes" and other external, cross-document links:-) (Oh, and use some pretty graphics too.)
In the modern "sue-happy" world, you're free to sue whomever you please, but I would ask that you leave Zoran out of the cross-hairs. They have put up no roadblocks to supporting their hardware -- they gave LiVid the specs to the Vaddis III (zr36710) chip. Every other vendor [*] (that I know of) has refused to release anything. [The dxr2 driver was reverse engineered before Creative branded it theirs.]
Despite the unwillingness of Matrox to say anything about their DVD add-on (which uses the Vaddis III), significant progress has been made in supporting it. (That's all I've done on the weekends for last month or so.) There's still alot of work to be done, tho'. At this point, I'm not concerned with CSS as I'm working with unencrypted VOBs from a "DVD" screen saver that came with the drive -- "tiny", simple, and self-contained.
Eventually, DVD CCA will have to come to some agreement towards (non-windows) licensing of CSS. Should they refuse to allow non-windows (non-x86) playback, then there certainly will be a legal backlash -- anti-competitive, monopolistic, etc. I hope they are thinking about these things. Personally, I'd much rather the decoder hardware handle the CSS crap (read: waste of time.) As I understand, RPC-2 allows for CSS key transfers directly between the decoder and the drive so CSS then becomes almost nothing at all. (Of course, that maybe in reference to set-top hardware.)
(B) is basically a re-wording of (A)... (B) stipulates that it is still illegal if it's only commercial significance is to break the copy protection even if that's not what it was primarily designed to do. For example, "slim-jims" would be illegal by this clause; even though it was NOT designed so people could break into your car, it "has only limited commercially significant purpose[s] or use[s] other than" to break into peoples' cars.
The CSS software does not fall to this clause either as its "commercially significant purpose" is in allowing a broader audience to view their DVDs -- I can play back my DVDs on an AlphaBook, for example. (In this context, it is irrelevant that the software is free.)
(C) makes it illegal for me to sell (as it were) you the software if I know you are only going to use it to break the copy protection. Thus, it would be illegal for me to sell you a plasma torch if I knew you were going to use it to break into a bank vault -- sortof like the laws preventing gun stores from sell you a gun if they know you're going to go out and shoot someone. [This is the only clause that has any merit -- weak as it is.]
For example, drills would be illegal if their primary purpose were to drill out locks on people's homes; plasma torches (very cool device) would be illegal if their primary purpose were to cut the doors off bank vaults.
The point to be made is that this CSS software, while certainly capable of removing the encryption for numerous illegal actions, is "primarily designed or produced for the purpose" of playing back a DVD movie on systems other than Windows.
If they (MPAA, RIAA, DVDCCA, et. al.) are so concerned about piracy, duplication, etc. then why is Philips allowed to make a dual deck CD-R and Go Video several dual deck VCRs -- which, I might add, will duplicate MacroVision intact with zero distorion.
Yeah, quantum is pretty good. The drives don't last as long as others after spinning for years, but they can take much more punishment than any non-milspec hard drive.
The last set of quantum IDE drives I bought (the 486's don't have SCSI -- drive speed is irrelevant to a 486:-)) have the same servo as the Atlas drives I have.
Allow me to point out one small problem with all this... the laser in a DVD drive is a visable spectrum (680nm?) red laser. The disk's "clock" would likely start the instant it was taken out of the foil wrapper.
I think you've confused USB with I2C... I2C is a serial bus with one master and up to 127 slaves. USB is daisychained point-to-point; it's slow and way too short. (Maybe you remember the Comadore serial device chain?)
I recommend SCSI for "the serious nut." Quality SCSI hardware+software can handle disk-at-once burning without CPU intervention. Basically, the software instructs the CDR to fetch and burn a set of sectors from a SCSI hard drive _directly_. Once the process is started, you could physically remove the CPU and the CDR would still finish. Basically, only a SCSI device or bus reset will stop the process -- I've locked up a few CDRs by instructing them to abort writing.
I will add, some scanners can do the same thing (in reverse.)
This is known as "multi-initiator mode." Not all SCSI chips can handle this and even fewer drivers can.
pfft, IDE ports are a silicon by-product of having a PCI bridge controller. There are no currently produced PCI bridges that don't have a few thousand transisters dedicated to an IDE interface. The early PCI based Macs were the only ones I know of that don't have any IDE hardware.
Hell, even Sun is using IDE hardware now -- even in things called "server". It's saving them, what, 12$ per 3000$ machine by not putting a SCSI controller on there? I gave up a 366MHz Ultra10 in favor of a 167MHz Ultra1 at work to get back to SCSI -- the U10 paid too much of a penalty for being IDE based (and yes, it was _very_ noticable.)
"Cheap" is a matter of opinion. Is the IDE drive a cheaper solution when you have to replace it three times over the life of the machine where a SCSI drive would move on to the next machine? And FYI, you can "yank" a SCSI drive and put it any SCSI equiped machine. In the PC world, neither IDE nor SCSI is telling the truth about the geometry of the drive. (Coming from a non-PC world, I really hate that.)
If you want the most G/$, then yes, IDE is the choice. However, "you get what you pay for." IDE _is_ slower than SCSI and much more likely to fail. I still have a Maxtor LXT-213S, 213M SCSI-1 (CCS) drive. That drive is over 10 years old and is still purring along -- it's living up to its MTBF.
CSS keys can be recovered in seconds (and have.) See the LiVid mailing list archives (www.linuxvideo.org) for several explanations, example code, and a large block of keys recovered with the code.
Slashdot Mirror
Not to perpetuate the arguement (with an AC), but... BSD uses the (surprise) BSD partitioning. BSD and it's method of partitioning existed long before the IBM PC and this stupid four partitions method. One can setup linux to use the BSD partitioning, but people usually don't (on x86 hardware anyway.)
My alpha will partition the disk either way depending on what OS you have set it to run -- sadly, it was designed to run NT, but that ain't what it's running. If you want to be sick, you can setup a sparc/linux machine with a DOS style partition table (please don't do that.)
From the people who recite the phonebook... That'd be enough for me to watch C-SPAN!
:-)
Placing it in the kernel doesn't automatically make it secure either. This isn't windows 95; serious thought and care needs to be used in placing code in the kernel. Alot of stuff wired into the kernel doesn't belong there -- we aren't reinventing a NetApp here.
You can "kill" proceses; you cannot "kill" part of the kernel.
Gez, they'll remove rarp saying "it's really a userland thing." But they'll wire nfsd and httpd into the kernel...
Yes, there are some significant gains from putting the nfs server in the kernel -- closer access to the files and networking plus access to the buffer cache. However, it introduces one hell of a security problem. Buffer overflows in userland typically kill the application -- or if crafted can run other stuff. But a buffer overflow in the kernel can do nine kinds of hell -- and a crafted overflow could erase the motherboard BIOS.
(I'm certain someone will say the BIOS could be killed from userland overflows as well, but not without alot more work.)
There are various reasons for that -- some are historic ties to the days when hard drives were too small to hold everything in one partition.
/var/run, /var/log, /var/adm, etc. Etc. Etc.
For the most part, "/" is tiny to reduce filesystem check times, reduce the chances of corruption (nothing changes very often), and better optimize the partition for the number of tiny files it holds. "/usr" is a partition so it can be mounted read-only -- this is a performance gain for some OSes. "/var" is it's own local partition as that's where volatile/transient/temporary stuff is kept -- you know,
Linux systems tend to have only a single partition due to the (stupid) lack of space for partitions on "PC" hardware. This is one of a long list of stupid things in the "PC" world.
The answer to your question is "yes." There are many things that can be done to the system by and/or during the boot sequence. I will not provide any details, however -- this is left as an exercise for the reader.
:-)
There are a few road-blocks, however. Altering the boot record(s) requires direct access to the disk -- something that usually requires explicit priviledge. Additionally, priviledge is required to alter lilo's map file. AND, there are size constraints on how big lilo (and resulting virii code(s)) can be -- remember lilo starts in standard ("i can only see 1MB") mode with only BIOS calls at it's fingers.
MILO on an alpha would be a much better target
Sure they can (and they have suggested it.) Firmware and microcode updates to drives and players. Software can obviously be rewritten.
I'm all for replacing CSS. If they want it to be protected from duplication then develop technology to prevent duplication not block all access to the damned disk entirely. Scrambling the data just makes it harder to play back; it does nothing to stop duplication. You can triple-DES encode stuff ten times; it's just as copyable in the end as it is at any point in the process.
I would like to point out that there are 500 Does on that suit. It would not be very difficult to put names to each of them. Also, all the injuction does is prevent them from distributing the stuff -- no one has ordered them to destroy their copies. (yet.)
:-) That's a nice gesture, but I'm sure DVD CCA will gladly pay that on the spot with a smile.
While I don't like this at all, the judge is acting properly in doing this. Neither side has said anything to assure him who's going to prevail. He's 100% correct in saying the injunction does not harm the defendants -- they aren't going to go broke because they cannot distribute CSS. Failing to prevent further spread of CSS would be disasterous for DVD CCA should they win in a full court.
$10k bond
Trademark-wise, they have no legs to stand on (and I think they knew that to begin with, but lawyers need practice :-))
Copyright-wise, they have a fully loaded, double-barrel shutgun (and a box of shells.) I'm sure they've had a few words with Xing privately for not adequately protecting the CSS technology, but you cannot put the smoke back in the chip (you fan the smoke away and replace the chip.) It doesn't matter what DeCSS was intended to do; it's only commercially significant purpose (to use the DMCA terms) is to remove the copy protection of a DVD -- it copies files from protected DVDs, descrambling them in the process, to your hard drive. I'd like to see a lawyer convence this judge otherwise. (MPAA's got us on that one.)
DeCSS is a windows program -- that's not very useful to linux developers. Furthermore, DeCSS.zip doesn't contain any actual source code. I've never seen the DeCSS source code. At any rate, as I've been told, it's x86 assemble ripped (almost?) verbatum from the Xing player. (that's a clear copyright violation.) This source code was made available to Derek Fawcus (I hope I spelled that right) who took on the daunting task of turning that stuff into C code. (that's not so clearly a copyright violation.) Now, I'm sure Xing didn't write this stuff in asm -- I'd bet C++. Turning asm into C isn't blindingly simple; turning compiled C++ crypto code back into C is frighteningly complicated.
The css-auth code from Derek is very useful code. It can do the same thing DeCSS does, but that's clearly not its intent nor is that remotely its primary commercially significant purpose. My concern as a LiVid developer is not to decode the crap on the disk but to be able to authenticate the disk so I can see the files and thus present them to the decoder hardware AND be able to broker the titlekeys as the decoder has no direct communication channel to the drive to do it on its own (if it could, I sure as hell would make it do it.)
In my book, software decoding of DVDs is a serious waste of processing. Decoding MPEG-2 data is a very computational task best handled by hardware designed to handle it.
As for your comment on "pay[ing up]"... CSS licensing is free. However, it doesn't happen overnight. When the Matrox DVD add-on is sufficiently functional, then and only then will I make a case for getting an actual license for a player. Until we have a reason to need one, why bother asking? (The driver may be functional tomorrow and it may be six months. And ZORAN will be the first people to be asked for any licensing... we need their microcode -- currently, you have to have the Matrox Zoran SoftDVD software installed.)
Actually, it's both. In all seriousness, CSS is copy protection, albeit damned weak. You cannot access the disk (assuming the DVD drive follows the rules) without going through the first phase of CSS to authenticate yourself to the drive. Beyond that, "copy away." (files are files, to the computer, it's just a bunch of bits.) Of course, this is just as effective as the copy protection of playstation disks.
Then it becomes a rather effective playback protection as you cannot play the movie back without undoing what CSS does to the files. In some cases, the hardware doing the decoding can handle the actual descrambling once it has the appropriate keys (the dxr2 can do this and I'm sure the Vaddis III can too with proper microcode.) BUT, you have to jump through a few hoops to get the titlekeys for the descrambling process.
This is all a bloody mess. I would bet everyone involved with DVD technology knew this crap was crap from the get go -- I'm surprised they weren't better prepared to counter DeCSS.
The DVD movies already _are_ being reverse-engineered. Progress is being made on determining all the funky "magic" of the IFO and VOB file formats. However, no one has lifted a finger to prevent these actions or the spread of the information (yet.) Maybe this is plan C and maybe they know they have no legal recourse to prevent it outside of CSS scrambling the files.
Understanding of the file format is useless if you cannot read the file.
Why do I get the feeling this is going to end up getting physically violent?
While the physical machine may be outside the country, you aren't. There may be some protection for the information on the machine, but there's little stopping "them" from holding you responsible for the contents of the machine and arresting you.
Yes, I've thought about this too with respect to export controlls on encryption, but as a US citizen (on US soil) I would still be responsible for "munitions" on the machine.
Laws can be soo damned annoying. (anyone want to colo on the moon?)
Small news flash... Ghostscript has a pdfwrite driver. Personally, I've never used it, but I compiled it in there. Also, try looking at StarOffice -- it's not perfect, but it fills a void and provides an excellent example.
:-) (Oh, and use some pretty graphics too.)
I would guess they want something semi-portable that still has some markup. HTML is far from a usable document standard -- it's too browser specific and would require stylesheets and other bells to have the same level of markup.
I would recommend pdf format and pepper it with "sticky notes" and other external, cross-document links
In the modern "sue-happy" world, you're free to sue whomever you please, but I would ask that you leave Zoran out of the cross-hairs. They have put up no roadblocks to supporting their hardware -- they gave LiVid the specs to the Vaddis III (zr36710) chip. Every other vendor [*] (that I know of) has refused to release anything. [The dxr2 driver was reverse engineered before Creative branded it theirs.]
Despite the unwillingness of Matrox to say anything about their DVD add-on (which uses the Vaddis III), significant progress has been made in supporting it. (That's all I've done on the weekends for last month or so.) There's still alot of work to be done, tho'. At this point, I'm not concerned with CSS as I'm working with unencrypted VOBs from a "DVD" screen saver that came with the drive -- "tiny", simple, and self-contained.
Eventually, DVD CCA will have to come to some agreement towards (non-windows) licensing of CSS. Should they refuse to allow non-windows (non-x86) playback, then there certainly will be a legal backlash -- anti-competitive, monopolistic, etc. I hope they are thinking about these things. Personally, I'd much rather the decoder hardware handle the CSS crap (read: waste of time.) As I understand, RPC-2 allows for CSS key transfers directly between the decoder and the drive so CSS then becomes almost nothing at all. (Of course, that maybe in reference to set-top hardware.)
(B) is basically a re-wording of (A)... (B) stipulates that it is still illegal if it's only commercial significance is to break the copy protection even if that's not what it was primarily designed to do. For example, "slim-jims" would be illegal by this clause; even though it was NOT designed so people could break into your car, it "has only limited commercially significant purpose[s] or use[s] other than" to break into peoples' cars.
The CSS software does not fall to this clause either as its "commercially significant purpose" is in allowing a broader audience to view their DVDs -- I can play back my DVDs on an AlphaBook, for example. (In this context, it is irrelevant that the software is free.)
(C) makes it illegal for me to sell (as it were) you the software if I know you are only going to use it to break the copy protection. Thus, it would be illegal for me to sell you a plasma torch if I knew you were going to use it to break into a bank vault -- sortof like the laws preventing gun stores from sell you a gun if they know you're going to go out and shoot someone. [This is the only clause that has any merit -- weak as it is.]
For example, drills would be illegal if their primary purpose were to drill out locks on people's homes; plasma torches (very cool device) would be illegal if their primary purpose were to cut the doors off bank vaults.
The point to be made is that this CSS software, while certainly capable of removing the encryption for numerous illegal actions, is "primarily designed or produced for the purpose" of playing back a DVD movie on systems other than Windows.
If they (MPAA, RIAA, DVDCCA, et. al.) are so concerned about piracy, duplication, etc. then why is Philips allowed to make a dual deck CD-R and Go Video several dual deck VCRs -- which, I might add, will duplicate MacroVision intact with zero distorion.
Yeah, quantum is pretty good. The drives don't last as long as others after spinning for years, but they can take much more punishment than any non-milspec hard drive.
:-)) have the same servo as the Atlas drives I have.
The last set of quantum IDE drives I bought (the 486's don't have SCSI -- drive speed is irrelevant to a 486
Allow me to point out one small problem with all this... the laser in a DVD drive is a visable spectrum (680nm?) red laser. The disk's "clock" would likely start the instant it was taken out of the foil wrapper.
I think you've confused USB with I2C... I2C is a serial bus with one master and up to 127 slaves. USB is daisychained point-to-point; it's slow and way too short. (Maybe you remember the Comadore serial device chain?)
(I2C has been around for decades.)
I recommend SCSI for "the serious nut." Quality SCSI hardware+software can handle disk-at-once burning without CPU intervention. Basically, the software instructs the CDR to fetch and burn a set of sectors from a SCSI hard drive _directly_. Once the process is started, you could physically remove the CPU and the CDR would still finish. Basically, only a SCSI device or bus reset will stop the process -- I've locked up a few CDRs by instructing them to abort writing.
I will add, some scanners can do the same thing (in reverse.)
This is known as "multi-initiator mode." Not all SCSI chips can handle this and even fewer drivers can.
(IP over SCSI. Let's see ya' try that with IDE.)
pfft, IDE ports are a silicon by-product of having a PCI bridge controller. There are no currently produced PCI bridges that don't have a few thousand transisters dedicated to an IDE interface. The early PCI based Macs were the only ones I know of that don't have any IDE hardware.
Hell, even Sun is using IDE hardware now -- even in things called "server". It's saving them, what, 12$ per 3000$ machine by not putting a SCSI controller on there? I gave up a 366MHz Ultra10 in favor of a 167MHz Ultra1 at work to get back to SCSI -- the U10 paid too much of a penalty for being IDE based (and yes, it was _very_ noticable.)
"Cheap" is a matter of opinion. Is the IDE drive a cheaper solution when you have to replace it three times over the life of the machine where a SCSI drive would move on to the next machine? And FYI, you can "yank" a SCSI drive and put it any SCSI equiped machine. In the PC world, neither IDE nor SCSI is telling the truth about the geometry of the drive. (Coming from a non-PC world, I really hate that.)
If you want the most G/$, then yes, IDE is the choice. However, "you get what you pay for." IDE _is_ slower than SCSI and much more likely to fail. I still have a Maxtor LXT-213S, 213M SCSI-1 (CCS) drive. That drive is over 10 years old and is still purring along -- it's living up to its MTBF.
Actually, he did say that (sort of) in an interview some years ago -- something to the effect of "linux is in my contract."
CSS keys can be recovered in seconds (and have.) See the LiVid mailing list archives (www.linuxvideo.org) for several explanations, example code, and a large block of keys recovered with the code.
CSS is laughablly weak.