Personal computing discussed
Moderators: renee, Flying Fox, Ryu Connor
seeker010 wrote:a lot of drivers for linux were written with almost no specs anyway. a lot of reverse engineering going on to write quite a few drivers.
Flying Fox wrote:Charlie at the Inq already complained about it months back. To me, I will just deal with it like so-called "protected CDs": don't play it on the computer! Get a separate player for those crap. There will come a day when a combo player costs like $150 with no region restriction, may be it will also include the Chinese EVD format (the player is probably made in China anyway). This will be the time I get onto this "HD" scene, hopefully by then I can get SED TVs at reasonable prices.
just brew it! wrote:Well, unfortunately only geeks like you and me will care about this "collateral damage". The general public would not quite care and we will be taken along the ride.The linked article seems to be more about "collateral damage" than about the inability to play protected content on your (Windows-based) PC. It's a different (albeit related) issue.
just brew it! wrote:If hardware vendors are required to "lock down" their hardware specs to satisfy Vista's DRM requirements, this will only get worse.
Flying Fox wrote:If we want to talk about hidden costs, just look at PSUs these days. Instead of $20 PSUs, we are paying upwards of $120 now compared to before. I don't seem to see anyone complaining? Planned obsolescence has been a PITA in the tech world too. But that's another topic for another thread.
Stripe7 wrote:nVidia has broken they unified driver architecture for Vista with the 8800, but that may be because of the Dx10 hardware. The real hammer blow to Microsoft will come when Dx10 hardware gets fully supported by open source. We can then see the overhead of all that DRM crud in Vista.
seeker010 wrote:cass wrote:WTF are you going to open source your hardware from?
Then how are you going to writer open source drivers with no access to specs on how to write them?
a lot of drivers for linux were written with almost no specs anyway. a lot of reverse engineering going on to write quite a few drivers.
just brew it! wrote:A friend forwarded this to me today. I have not tried to independently verify the claims made in this document (I just finished reading it), but it seems plausible.
If indeed true, it raises some interesting (and disturbing) issues.
Bottom line: It looks like there's a lot of crazy sh*t going on under the hood in Vista, just to ensure that DRM can be implemented securely. As a result we as consumers all get to pay more for hardware with lower performance and decreased stability, while non-Vista (e.g. Open Source) solutions are cut completely out of the loop.
Disabling of Functionality
Vista's content protection mechanism only allows protected content to be sent over interfaces that also have content-protection facilities built in. Currently the most common high-end audio output interface is S/PDIF (Sony/Philips Digital Interface Format). Most newer audio cards, for example, feature TOSlink digital optical output for high-quality sound reproduction, and even the latest crop of motherboards with integrated audio provide at least coax (and often optical) digital output. Since S/PDIF doesn't provide any content protection, Vista requires that it be disabled when playing protected content. In other words if you've invested a pile of money into a high-end audio setup fed from a digital output, you won't be able to use it with protected content. Similarly, component (YPbPr) video will be disabled by Vista's content protection, so the same applies to a high-end video setup fed from component video.
Shintai wrote:Vista in itself don´t hold the DRM, drivers do.
..................................................................................
Or the 3rd option, use Vista with a set of supporting drivers from nVidia/ATI
Denial-of-Service via Driver Revocation
Once a weakness is found in a particular driver or device, that driver will have its signature revoked by Microsoft, which means that it will cease to function (details on this are a bit vague here, presumably some minimum functionality like generic 640x480 VGA support will still be available in order for the system to boot). This means that a report of a compromise of a particular driver or device will cause all support for that device worldwide to be turned off until a fix can be found. Again, details are sketchy, but if it's a device problem then presumably the device turns into a paperweight once it's revoked. If it's an older device for which the vendor isn't interested in rewriting their drivers (and in the fast-moving hardware market most devices enter "legacy" status within a year of two of their replacement models becoming available), all devices of that type worldwide become permanently unusable.
The threat of driver revocation is the ultimate nuclear option, the crack of the commissars' pistols reminding the faithful of their duty [Note B]. The exact details of the hammer that vendors will be hit with is buried in confidential licensing agreements, but I've heard mention of multimillion dollar fines and embargoes on further shipment of devices alongside the driver revocation mentioned above.
Consider a
medical IT worker who's using a medical imaging PC while listening to
audio/video played back by the computer (the CDROM drives installed in
workplace PCs inevitably spend most of their working lives playing music or
MP3 CDs to drown out workplace noise). If there's any premium content present
in there, the image will be subtly altered by Vista's content protection,
potentially creating exactly the life-threatening situation that the medical
industry has worked so hard to avoid. The scary thing is that there's no easy
way around this - Vista will silently modify displayed content under certain
(almost impossible-to-predict in advance) situations discernable only to
Vista's built-in content-protection subsystem [Note E].
In addition to the CPU costs, the desire to render data inaccessible at any
level means that video decompression can't be done in the CPU any more, since
there isn't sufficient CPU power available to both decompress the video and
encrypt the resulting uncompressed data stream to the video card.