Sure. This router is not 802.11n compatible, but it is 802.11g compatible, and thus it can be Wi-Fi certified. The Wi-Fi Alliance doesn't care if a product has non-standard extra features (MIMO in this case) as long as it is compliant with the current standard (802.11g).
Encryption only protects against sniffing, but the copyright enforcers are not sniffing. They don't want to sniff, since it's so expensive. They can just log in to the latest P2P system, start downloading some warez, and see what IP address it is coming from.
If the computer dies, you swap the drive into a different ThinkPad and boot. It will ask you for the drive password, which you then type in. It will then boot normally.
Only if they have changed the actual encoding of data on the disk in such a way as an older player was incapable of actually decoding what was on it. But that would have to use differing encryption methods, and I question wether or not the resulting disk could ligitimately be identified as being compatible with the DVD spec.
You nailed it. VCPS uses different (not CSS) encryption, therefore VCPS discs are technically not DVDs at all. So it is not surprising that a DVD player will not play a VCPS disc. The problem is that the marketing weasels will try to tell you that a VCPS recorder is a DVD recorder even though it is not.
If Kazaa users indeed followed the strategy of always-defect then it would be impossible to download anything from Kazaa.
I never tried Kazaa, but that was pretty much my exact experience with Gnutella and Napster. Every download request either timed out or came in at ~100 bytes/second.
There's no conspiracy; many HD vendors have publicly stated that they see only a small market for huge drives, so they just aren't going to make them. 5 years ago 5-platter drives were common; the technology still exists, but almost no one uses it now. Most drives have just 2 or 3 platters, because that is the sweet spot of the market.
What are you talking about? They did get SATA right; it supports 48-bit sector addressing IIRC. SATA II is mostly pointless, but you don't have to worry since it's backward and forward compatible.
This isn't an SAS drive. I can understand why you would want 300MB/s links between the SAS controller and the expanders, but between the expanders and the drives, 150MB/s is more than adequate.
Of course, operating system limits have nothing to do with motherboard limits. SATA uses 48-bit sector numbers IIRC, so that's a limit of 2^57 bytes. And 32-bit operating systems can use 64-bit filesystems (e.g. XFS) which have no practical size limits.
I think some people might like to store the songs they purchased from the iTunes Music Store on the media hub. However, HP would probably need to use an "illegal" hack to deal with Apple's DRM in Linux.
Sounds like a good idea to me. But there's no need for hacks; HP has a partnership with Apple, so they can just license FairPlay.
shouldn't he be asking Apple to make the iPod more Linux-friendly?
What's wrong with it? Linux can mount an iPod already. The index file format is not publicly documented, but HP can just license it from Apple.
What if you could rip directly from CD onto the media hub, and then sync from the media hub onto an iPod? No computer needed, which some people might see as a benefit.
As was mentioned in the Linux-based portable media player thread, it makes no difference to the user whether these devices run Linux or not. You can't install any applications, you probably can't get a shell, and you can bet that HP will release the minimal amount of source that is legally required, so hacking will be frustrating.
And it looks like this device might break a record for the number of different kinds of DRM in one system...
Public key B is then encrypted using 100 million other keys and each version is saved in a different place on the disk. These encrypted versions of B are small and take up very little space.
Let's say 16 bytes * 100,000,000; that's 1.6GB, or 10% of a single-layer HD DVD. (Someone else already mentioned this objection elsewhere in the thread.)
BTW, there's no need for A and B to be separate; you could use a single symmetric key.
I don't care how secure the encryption is, as everyone has already said, all it takes is a "legal" DVD player outputting a high quality signal into a capture card, and you have a decrypted copy.
And where can you buy an analog HD component capture card?
I doubt that the industry is foolish enough to force consumers to upgrade their televisions to support some form of signal encryption
They did; it's called HDCP. If your HDTV doesn't support HDCP, you'll only get an analog signal.
Slashdot Mirror
Sure. This router is not 802.11n compatible, but it is 802.11g compatible, and thus it can be Wi-Fi certified. The Wi-Fi Alliance doesn't care if a product has non-standard extra features (MIMO in this case) as long as it is compliant with the current standard (802.11g).
why not give it an HDMI connector so I could record off equiptment that has HDMI out?
And what is your Mac going to do with a >100MB/s uncompressed video stream? Oh, and HDMI is often encrypted.
Encryption only protects against sniffing, but the copyright enforcers are not sniffing. They don't want to sniff, since it's so expensive. They can just log in to the latest P2P system, start downloading some warez, and see what IP address it is coming from.
Have you looked at the Roku SoundBridge?
Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
This is not correct if your OS supports confinement. It's a bad sign when the first item in the list is wrong.
If the computer dies, you swap the drive into a different ThinkPad and boot. It will ask you for the drive password, which you then type in. It will then boot normally.
Akimbo already sells this, although it's not as cheap as you'd like. (Can you serve ~1GB of data for 24 cents? What about transaction costs?)
Will the cable companies work with Tivo to get this going or will they do what another poster said and reverse engineer.
Cable is now standardized (OpenCable), so the cable companies will not work with Tivo and Tivo will not have to reverse-engineer anything.
I really do wonder though how long it will take before someone out-Tivo's Tivo.
I think that's called Moxi.
Only if they have changed the actual encoding of data on the disk in such a way as an older player was incapable of actually decoding what was on it. But that would have to use differing encryption methods, and I question wether or not the resulting disk could ligitimately be identified as being compatible with the DVD spec.
You nailed it. VCPS uses different (not CSS) encryption, therefore VCPS discs are technically not DVDs at all. So it is not surprising that a DVD player will not play a VCPS disc. The problem is that the marketing weasels will try to tell you that a VCPS recorder is a DVD recorder even though it is not.
If Kazaa users indeed followed the strategy of always-defect then it would be impossible to download anything from Kazaa.
I never tried Kazaa, but that was pretty much my exact experience with Gnutella and Napster. Every download request either timed out or came in at ~100 bytes/second.
There's no conspiracy; many HD vendors have publicly stated that they see only a small market for huge drives, so they just aren't going to make them. 5 years ago 5-platter drives were common; the technology still exists, but almost no one uses it now. Most drives have just 2 or 3 platters, because that is the sweet spot of the market.
What are you talking about? They did get SATA right; it supports 48-bit sector addressing IIRC. SATA II is mostly pointless, but you don't have to worry since it's backward and forward compatible.
This isn't an SAS drive. I can understand why you would want 300MB/s links between the SAS controller and the expanders, but between the expanders and the drives, 150MB/s is more than adequate.
Of course, operating system limits have nothing to do with motherboard limits. SATA uses 48-bit sector numbers IIRC, so that's a limit of 2^57 bytes. And 32-bit operating systems can use 64-bit filesystems (e.g. XFS) which have no practical size limits.
Think about it from the opposite perspective: what if they simply don't write any code that allows non-media files to be transferred onto the device?
I think some people might like to store the songs they purchased from the iTunes Music Store on the media hub. However, HP would probably need to use an "illegal" hack to deal with Apple's DRM in Linux.
Sounds like a good idea to me. But there's no need for hacks; HP has a partnership with Apple, so they can just license FairPlay.
shouldn't he be asking Apple to make the iPod more Linux-friendly?
What's wrong with it? Linux can mount an iPod already. The index file format is not publicly documented, but HP can just license it from Apple.
Yes, device makers benefit from using Linux, that's why they do it. But there's no point in advertising it.
HP sold a Linux-based Digital Entertainment Center about 5 years ago, but it was too expensive for basically an audio jukebox.
What if you could rip directly from CD onto the media hub, and then sync from the media hub onto an iPod? No computer needed, which some people might see as a benefit.
Broadcast flag? Check. It's required by law.
OpenCable DRM? Check. It's built in to the standard.
As was mentioned in the Linux-based portable media player thread, it makes no difference to the user whether these devices run Linux or not. You can't install any applications, you probably can't get a shell, and you can bet that HP will release the minimal amount of source that is legally required, so hacking will be frustrating.
And it looks like this device might break a record for the number of different kinds of DRM in one system...
Intel already has their own x86-to-IA64 translator called IA-32 EL.
Public key B is then encrypted using 100 million other keys and each version is saved in a different place on the disk. These encrypted versions of B are small and take up very little space.
Let's say 16 bytes * 100,000,000; that's 1.6GB, or 10% of a single-layer HD DVD. (Someone else already mentioned this objection elsewhere in the thread.)
BTW, there's no need for A and B to be separate; you could use a single symmetric key.
DVI recording hardware does not exist, and what would you do with a >100MB/s stream anyway? And the DVI signal is encrypted with HDCP...
I don't care how secure the encryption is, as everyone has already said, all it takes is a "legal" DVD player outputting a high quality signal into a capture card, and you have a decrypted copy.
And where can you buy an analog HD component capture card?
I doubt that the industry is foolish enough to force consumers to upgrade their televisions to support some form of signal encryption
They did; it's called HDCP. If your HDTV doesn't support HDCP, you'll only get an analog signal.
But that doesn't make sense. How can the content key be encrypted with (e.g.) 100 million different player keys?