If XYZ company decides to invest in building an OpenCable "tuner" card for a PC, then that's perfectly do-able, and the software API exposed by that card is irrelavent to the OpenCable standards.
It's not exactly irrelevant, since the robustness requirements mandate strong DRM out the wazoo in every OpenCable device.
Heh, you fell for the "IPv6 will be completely encrypted" myth. Sure, IPv6 "MUST" include IPSec, but who enforces it? And even if your OS MUST include it, no one said you have to turn it on.
Smart cards won't make PGP that much easier to use. Read "Why Johnny Can't Encrypt" for some sobering facts about how hard it is to just get PGP set up right.
It's actually the box makers who don't want consumers buying or anybody else making their own digital cable boxes.
You're right: I'm sure Motorola and Scientific Atlanta don't want any competition to challenge their duopoly. But Sony, Panasonic, Toshiba, etc. want to get into the cable box market, and that's what they're getting.
You'll probably never see an OpenCable PCI card or a DirecTV PCI card. We can't have that "valuable content" traveling over an unencrypted bus, now can we?
Actually, the whole point of OpenCable is that you'll buy your own box in the future. Renting a $500 cable box for $5/month isn't a business the cable companies want to be in.
It's not really P2P when all of your traffic is going through a third party. And WHO is that third party?
A supernode, aka some random poor schmuck with lots of bandwidth and no firewall who ends up relaying Skype calls for other people without knowing about it.
I don't want my private conversations bounced off some shmuck at Kazaa who can listen in at his leisure.
End-to-end crypto. (Not that you should believe it, since it's undocumented.)
Re:Two questions, and a suggestion for an alternat
on
New VOIP App. Profiled
·
· Score: 2, Informative
SourceForge has an amazing feature called CVS that stores source code.
This is the whole point of the debate between Shirky and McCloud! Shirky argues that even with zero overhead, mental transaction costs doom micropayments to failure.
You haven't read any of the literature about micropayments, have you? Overhead costs are not just a solved problem but they've been solved a half-dozen different ways.
That is a very good point, although my answer is the same: the best design approach is to separate applications into security-critical and non-security-critical parts, and minimize the size of the security-critical code. Luckily some people are already doing this.
"This standard will enable mass production of a class of operating systems that meet the minimum expectations of consumers for security and general reliability by establishing a floor for these characteristics."
This sure looks like it's about real security, not DRM.
Slashdot Mirror
the R300 has a binary-only DRI/xfree86 module for x86. Fine, but do they have it for PPC?
Of course not.
I'm also assuming the Airport Extreme card is still unsupported in Linux?
Yep.
(And I doubt you can put an old Airport card in them - if I remember correctly they didn't have the same interface)
Correct.
The PowerBooks are basically no good for Linux.
The old 12" didn't have Mini-DVI at all.
Does anyone know if this is possible or is the 2 Ghz the only configuration able to support dual G5's?
It's not easy; the socket for the second processor is missing on the single-processor model.
Can one purchase a single 2.0Ghz and add a proc later?
No. This question is answered on Apple's site BTW.
If XYZ company decides to invest in building an OpenCable "tuner" card for a PC, then that's perfectly do-able, and the software API exposed by that card is irrelavent to the OpenCable standards.
It's not exactly irrelevant, since the robustness requirements mandate strong DRM out the wazoo in every OpenCable device.
Heh, you fell for the "IPv6 will be completely encrypted" myth. Sure, IPv6 "MUST" include IPSec, but who enforces it? And even if your OS MUST include it, no one said you have to turn it on.
Smart cards won't make PGP that much easier to use. Read "Why Johnny Can't Encrypt" for some sobering facts about how hard it is to just get PGP set up right.
It's actually the box makers who don't want consumers buying or anybody else making their own digital cable boxes.
You're right: I'm sure Motorola and Scientific Atlanta don't want any competition to challenge their duopoly. But Sony, Panasonic, Toshiba, etc. want to get into the cable box market, and that's what they're getting.
The content has to be secure all the way to the phosphors on the screen; it can't exist unencrypted anywhere that Bunnie could tap into it.
You'll probably never see an OpenCable PCI card or a DirecTV PCI card. We can't have that "valuable content" traveling over an unencrypted bus, now can we?
Actually, the whole point of OpenCable is that you'll buy your own box in the future. Renting a $500 cable box for $5/month isn't a business the cable companies want to be in.
It's not really P2P when all of your traffic is going through a third party. And WHO is that third party?
A supernode, aka some random poor schmuck with lots of bandwidth and no firewall who ends up relaying Skype calls for other people without knowing about it.
I don't want my private conversations bounced off some shmuck at Kazaa who can listen in at his leisure.
End-to-end crypto. (Not that you should believe it, since it's undocumented.)
SourceForge has an amazing feature called CVS that stores source code.
Yeah, where are the 1GB PC3200 ECC DIMMs? Forget LEDs; let's talk REAL memory.
If you want to do memory profiling, use a profiler; it's much cheaper than buying funky RAM and staring at the blinkenlights until you go cross-eyed.
That sounds just like IBM's Light Path Diagnostics.
This is the whole point of the debate between Shirky and McCloud! Shirky argues that even with zero overhead, mental transaction costs doom micropayments to failure.
I think you'll find that governments are a bigger impediment to digital cash than patents.
You haven't read any of the literature about micropayments, have you? Overhead costs are not just a solved problem but they've been solved a half-dozen different ways.
That is a very good point, although my answer is the same: the best design approach is to separate applications into security-critical and non-security-critical parts, and minimize the size of the security-critical code. Luckily some people are already doing this.
You just can't go over millions of lines of code and spot every bug that can result in a security breach
That's why really secure OSes don't have millions of lines of security-critical code.
"This standard will enable mass production of a class of operating systems that meet the minimum expectations of consumers for security and general reliability by establishing a floor for these characteristics."
This sure looks like it's about real security, not DRM.
AFAIK the Windows PLAFs have always checked whether they're running on Windows or not.
I don't know why you'd want the GTK PLAF, but I think it was only introduced in 1.4.2.
It sounds like Hushmail should write clean Java code.
Read the specs. They do support external monitors.
Although I think it's silly to pitch an iBook/PowerBook to someone who wants a headless desktop.
Check out Gnomemeeting, linphone, Asterix, and Bayonne.