Re:Voodoo 3 In 1995?
on
The 1991 "X-Box"
·
· Score: 2, Informative
This guy says that according to USENET archives, the Voodoo 3 was available in 1995? umm no
I was wondering about that myself. I just recently retired my two Voodoo3 3000s, and when I got them in 1998 they were top-of-the-line.
And, the Voodoo with TV-Out was the 3500, not the 3000 that he mentions.
Hell, in 1995 I believe 3D cards were of the "pass-thru cable" variety -- I don't think any 2D/3D combo cards were even out yet. The original Voodoo might have been out, but certainly not the Voodoo3...
And I don't believe TV-Out was easily available except through an expensive "scan converter"...
Anyway, much of what he says is conflicting even with the other things he says, and then there are a few technical and chronological problems.
I won't say it's bullshit, but I am pretty skeptical (not to mention X-Box -- I don't think people called a PC a "box" back then, and he has no real reasoning for having come up with the name...)
The whole reason the GPL was created was to create software which saw computer users as a community of citizens assisting one another. not a consummers of software services. That is it was designed to encourage the free sharing of information in a communal fashion. TCPA/Palladium is designed to encourage the restriction of information to the appropriate parties.
I'm not sure I follow your argument. So SSH is bad? SSL and PGP are bad?
That's what security and privacy is all about -- keeping others out. I don't want anyone sniffing my sessions when I'm working on the server, so I use SSH (to connect from one GPL Linux box to another, no less).
I don't think the GPL is about *everything* being open and free. While I don't fully agree with much of the GPL, I do know that the GPL doesn't restrict using secure, encrypted protocols to keep sensitive information private. If it did, that'd just be one more thing I didn't agree with in the GPL.
Or perhaps I'm missing your point?
Think about third-party hardware crypto cards/modules. To me, TCPA is just that, but on-board, and with more hooks to ensure that the operating environment is secure (or at least is in a known state). I don't think it matters what OS is being used at all -- just that it hasn't been comprimised.
The availability of GPL drivers does not change the fact that this is an enabling technology for DRM and not much else.
I still don't see this. Can you explain how TCPA hardware enables DRM? How would you implement a DRM scheme using the TCPA hardware?
TCPA isn't about that, really, and I don't see why you think that it is. I have explained this a few times already here, so I'll just link to one of my other comments.
My personal view (an oversimplification which may not be accurate) is that DRM and TCPA are mostly mutually exclusive ideas, and that Palladium is a union of the two.
I'm not sure I'd say mutually exclusive. It's more like DRM and security are similar, but different issues. Different in that security is about not trusting the outside world, where DRM is about not trusting the user.
Both problems can be solved with similar technologies (public/private key pairs, secure, hardware-based key storage, etc). But since the goals are different the overlap isn't that big (DRM would require physical tamper-proofing as well as NO user access to the chip's functions).
Palladium is in fact a union of the two, however. Personally I think Palladium's only intention was for DRM, and the "trusted computing" thing was an idea stolen from someone else (possibly the TCPA?) for the sole purpose of marketing Palladium as a Good Thing, and thus added to the Palladium spec.
I just hope more people will read either these whitepapers, or the actual spec if they don't trust IBM, and really understand the issues. I have no problem with informed arguments; I can't stand when people put together entire websites of uninformed garbage.
> It's one thing I hate about Mozilla (why can't they use the native menus and widgets?)
Because they wouldn't be able to comply with CSS.
A couple people have corrected me on this, and I now understand. As I said, I do use Mozilla pretty much exclusively, and lately most of my previous gripes with Mozilla's widgets have gone away. The text box IS much better, and the menus work okay under multiple monitor systems (it had issues back in... geez, M12 I think it was. Moz has sure come a long way)
It does seem that the web will sorta need its own toolkit, and with this in mind, Mozilla's approach is pretty decent. For MSIE to update widgets, it has to update the OS widgets (which it *does* do from time to time; this is why so many programs that have nothing to do with the web require a certain IE version to be installed).
So in short, I'm convinced, I agree, and I like Mozilla even more now:)
But this spec also allows it from what I got out of the paper.
Funny, I got this from the paper:
The TCPA chip does not and cannot control execution!
Which means it will NOT prevent any operating system from booting. It will prevent an operating system environment from decrypting data with the chip if it's not the OS that was used when the data was encrypted -- but that works in both (all) directions.
Plus, of course the features offered by the chip can be disabled in the BIOS.
I can easily envision them integrating it into their WMP 9 technology and preventing all those without TCPA access to the media.
TCPA isn't needed for this, and in fact doesn't really do much to help this type of DRM. How can you encode files on your machine, that require a chip on my motherboard -- well, to do what, exactly?
---
Imagine a cracker breaks into your machine one way or another. He can currently find your PGP key, your SSH keys, etc, very easily.
Now imagine if those keys were instead generated and stored on a special chip on the motherboard. The chip itself handles the decryption, so the key never needs to leave the chip. Even further, if something changed in the environment (specific things that might indicate a virus, worm, or other breach), the chip will not decrypt the data.
Wouldn't that be pretty damned secure? Well, basically that is TCPA.
TCPA is not particularly well suited to DRM applications, as this was not its intent.
Maybe the OS will encode all recorded music with your public key so it's unplayable on any other machine? Who knows, the possibilites really are limitless.
Why does an OS need TCPA to do this? In fact, IIRC Windows Media Player does something like this now, by default even. TCPA doesn't enable this (or more correctly, absense of TCPA doesn't make this impossible).
TCPA is basically this:
- Generates key pairs (a fast DSP) - Stores key pairs - Performs encryption/decryption, only if everything is okay
The "everything is okay" part simply means that the BIOS hasn't been messed with, and the OS is in a known state. Yes, this will prevent (say) using Linux to decrypt data that you encrypted while in Windows -- but it also goes the other way (data encrypted under Linux can't be decrypted under Windows). That's the beauty of it; an attacker can't just pop a boot disk in and try to read your data.
I think the confusion is that the term "Trusted Computing" sounds a lot like what we all heard about Palladium -- but it is NOT the same thing. Palladium asks for a lot more than TCPA, and at the present Palladium isn't designed for TCPA. They want (and have patents on) their own hardware implemented, as well as CPU hacks, and other junk.
actually, the reason for that statement is to disclaim any bias the author may have against DRM.
I have to disagree. We seem to have taken two different interpretations, but the author in fact did state that he is against DRM, and in one of the papers he specifically says:
My personal opinion (not speaking for IBM) is that DRM is stupid, because it can never be effective[6,7], and it takes away existing rights of the consumer. But this is not the place for that debate.
But I believe this document was targeted at the Linux community (perhaps even the/. crowd specifically), so his including that tries to show early on that this is not a pro-DRM issue. His intent is to show that TCPA is NOT DRM, and he further implies that if it were he wouldn't be pushing for TCPA (by showing his dislike for DRM).
My response was probably more long-winded than it needed to be... but hopefully it makes sense:)
It's unfortionate to see White Papers, which in my opinion, should present fact, be so biased.
I agree that the whitepapers seemed to use the phraze "I personally" a bit too much (one calls DRM "stupid"!) -- but to me it seems like they wanted to quickly put something together to help inform the Linux community (and possibly the Slashdot community in particular) of what TCPA is all about.
I'm glad they released something to help curb all the negative FUD that I keep seeing. It still doesn't seem to be helping much, since over half the comments here are anti-TCPA FUD themselves (and most of the "facts" I'm seeing in this story's comments are in fact addressed in the rebuttal document linked in the story).
I'm not entirely sure if this is sarcastic, serious, or what, but in any case, could you elaborate? Do you have an actual opinion on this, or is that all you wanted to say?
If you mean it seriously, and you mean to imply that the TCPA is inherently a bad thing, you obviously didn't read the whitepaper (and thus aren't well suited to present us with a "summary"). I think with IBM on board with this, we (Linux users specifically, other "alternate OS" users as well) should feel a lot better about this. Hell, we already have GPL drivers for Linux TCPA applications...
Good to see??? umm... I hope your joking, cause otherwise, you have NO FUCKING CLUE WHAT YOU'RE TALKING ABOUT!!!
I'm honestly not sure what you mean here, but from your.sig link to notcpa.org, I guess you're not a supporter of the TCPA.
So tell me -- did you read the whitepapers mentioned in the article? Or are you simply going by the FUD presented at notcpa.org?
Seriously, whether you are for or against the TCPA, read the white-papers IBM put together. Note that it has nothing to do with DRM or Palladium, and the author of one of the papers says "DRM is stupid, but that's another paper".
Or go read the specifications yourself.
In short:
1) The TCPA is NOT Palladium 2) It does NOT protect against physical tampering (thus not being well suited for DRM usage) 3) It doesn't use any cert authority or "code signing" or anything like that. This again is not Palladium, and this is not the XBox.
It really is about helping to protect you against crackers or viruses/worms from obtaining your private keys (be it SSH, SSL, PGP, or whatever future application comes up).
And IMO it is good to see IBM on-board. They've already written GPL drivers for Linux, and are showing massive support from the very beginning -- something you rarely see with *any* new specification or proposed standards. Any Linux user should be glad IBM is on-board as well.
Would it damage your geek-manliness if your OS of choice was actually easy to use?
You misinterpreted my post. I think it's fine if developers work toward making Linux easy to use. I'm just not one who really cares if Linux is accepted on the desktop by the average person. Linux works for me (I run with and without X, depending on the purpose of the particular machine).
It seems like any time someone (rather, some company) starts to focus on "Linux on the Desktop", it fails. Sometimes miserably, and sometimes the effort takes away from other aspects of the distro.
RedHat 8.0 is perty when you boot it up, and a lot of nice things happened. It worked on my laptop out-of-the-box and required zero X configuration on my part. I was quite impressed with the installation procedure, and that everything but the Winmodem worked right away.
But on the command-line side, I don't see much of anything changed from 7.x. The transition from 5.x to 6.x provided a lot of nice additions, and 7.x added more (2.4 kernel, journaling file system by default, etc). 8.x looks (from the console) like 7.x (minus any mp3 utilities). It seems that each release focuses more and more on the desktop side of things...
Anyway, my point is this: push for Linux on the desktop, or don't -- it doesn't make a difference to me. I'm not against it, but I'm not specifically hoping for it either. I like Linux for what it is already great for -- servers, embeded applications, etc. But again, I'm not against it either -- it's not an elitist (or "geek-manliness") issue at all.
Why must we fight this "battle"? Who cares if Grandma can use Linux or not? As long as enough geeks are using Linux to keep the platform viable, this geek will be happy, and perfectly content.
I've been making this argument for a while. I don't care about "Linux on the Desktop". Linux on the server, and Linux on my desktop is all I care about.
I use Windows for some tasks. I use Linux for others (including all of my multimedia needs, as it happens). I don't want Linux to become a replacement for Windows -- I already have one of those. My Dad doesn't need Linux -- Windows does everything he needs.
You can argue the cost issue, or the monopolistic practices, etc, but realistically most people don't care about that. Most people, given a choice, would choose Windows, even if it meant higher cost and having to "activate" their installation. Even if Linux were free, worked out of the box, and could open most MS Office docs -- it wouldn't matter.
So, let's keep Linux for ourselves. Those who can't figure out MPlayer, the command-line, X configuration, etc -- don't need Linux. They don't want Linux.
If you look for reasons to be unhappy with ANYTHING, you'll find them. Why not focus on what's good and what needs to be improved?
The thing is, he does make some good points. For example, why does everyone need to reinvent the GUI wheel (as if we didn't have enough widget sets and window managers to deal with on *nix)? Why does everything have to be skinable?
I use MPlayer extensively -- but I don't touch the GUI, I have a text-based front-end for it. When it comes to playing video files, scaling, utilizing my ATI's TV-Out, etc -- MPlayer kicks all sorts of ass.
However, it's such a common trend these days to make everything skinable, and to create one's own interface standards. That's one of the things I hate most about WMP for Windows (that, and it periodically just stops functioning).
It's one thing I hate about Mozilla (why can't they use the native menus and widgets?) -- though I use Mozilla exclusively, I still feel a lot of time was wasted implementing their own text box (that still doesn't work quite right), menus, etc...
While I personally use MPlayer, I can't say I'd recommend it to someone who doesn't know how to compile software (using a specific gcc version no less), figure out the appropriate command-line options, etc. Tried to walk a semi-linux-literate person through it, and he still has no working MPlayer. As for the GUI, I also wouldn't recommend it, for most of the reasons noted in Jamie's rant.
Cars are the worst. I once opened a friends car ( same make, model as mine ) with my keys. I think the car manufactuers must only have 50 or so lock variations.
General Motors for the longest time only had some 15 ignition keys, and 15 door keys (back when the two still used separate keys). I think the idea was that for any two cars, the chances of both keys being the same were pretty slim (1 in 15*15).
I had a GM car with a broken trunk lock. I headed down to the junk yard, with my own door/trunk key in hand, and within about 20 junk cars I found a trunk lock mechanism that fit my existing key.
That, and most people assume that keys are completely unique. People who don't know, assume, and usually error on the side that makes them feel safer (ignorance is bliss I suppose).
I only learned this by having worked for a used car dealer; prior to that I was under the same assumption (and of course GM was the *last* manufacturer to still use separate keys for the door and ignition -- and it was only because they outsourced each from different companies).
AFAIK they don't even offer a hydrahead adapter for the one DVI port to split to two (doubt its possible without a proprietary output like the Radeon VE's).
I'm not sure what that last part means (VE?)... but I have a PNY ti4600, using the DVI/VGA adaptor that came with a Radeon card (to drive two analog monitors). Doesn't seem there was anything proprietary there, and I was pretty sure that the analog-compatibility for DVI connectors was standardized. It was an assumption, but it worked.
No less, I agree that they should put two DVI ports on them, and supply at least one adaptor. One day I'd like to go all LCD (or Plasma by then, but digital anyway). I'd hate to have to run one analog (or buy another card).
And maybe the DVI/VGA adaptors should be in the form of a short cable (the current ones add about 3" to the required-space behind the PC, and it really is a lot of weight on the connector)...
What I wonder is why just not put all the transistors, the chip and the ram...on the other side of the circuitboard! No-one looses a pci slot that way.
That would certainly look funky. Then again, I still think of PCI/AGP cards as "upside-down"...
I believe that extending the size to that side of the card would be considered "out of spec", and some motherboards would have a problem with that. My Aptiva board for example has the CPU clip/thing (Slot-1) very close to the AGP card, so in that box at least this wouldn't work.
That's how I get my dual monitor setup; geforce in the agp, old pci gfx card in the 1st pci slot (some cards still complain if they're not in the first slot).
First, I've never had a PCI video card complain/care about which slot it's in (at least not in the last 7 or 8 years). Second, I'm sure the FX supports dual outputs like the ti4600 I'm currently using on two 17" monitors does (that's the one thing that sold me; they don't readily advertise this, but it'll drive two at once easily, both accelerated, and either one can run your full-screen games).
Connecting two analog monitors simply involves getting an adaptor, and the digital output becomes a second analog one. Takes some trickery in the driver to get it to function "properly" (so Windows sees it as two separate cards -- the only option that I can stand), but I've had no problems since ditching my two Voodoo3's for the ti4600.
Anyway, I don't like the fan setup myself either. But where I used to care about precious PCI slots, I don't anymore. Between on-board components, dual-output AGP cards, and USB-this and USB-that, I have some 4 PCI slots available in my main PC... so I'm willing to live with the two-slot deal.
Windows has far too many kernel dependancies (if that's the right term) for this to happen. Think about this: how do you implement DirectX (as an example) in Linux without serious kernel hacking? I doubt something this low-level -- something that requires cooperation of all sound/video/input drivers and many internel kernel hooks -- could be done with a module.
Someone else pointed out that all hardware drivers would have to be rewritten. Filename/path conventions (backslash != forward slash), not to mention the underlying filesystem, has to change. Filesystem attributes (ACLs, etc) have to be implemented.
Then you have the multi-thread capabilities. I don't know where Linux is at on that currently, but I don't honestly think it's up there with Windows, or at minimum we're talking serious differences in implementation.
And what of applications? The strong-hold Microsoft has on the PC market lies primarily in a) hardware/driver availability, and b) software availability.
Even if you s/Linux/BSD/, the above all still applies.
And seriously -- is the Windows 2000/XP core bad enough to warrant replacement? I don't think it is, personally. The vast majority of the problems I have with Windows is the applications on top of it (IIS, MSIE, Outlook, etc). The OS itself is pretty solid, honestly, as long as you have decent hardware (and drivers). Yes, there is TONS of room for improvement, but that doesn't warrant dumping the entire core and starting with something new...
So no, won't ever happen, and not because of pride or anything else -- it won't happen because it's not necessary, and would be a very bad decision, both technically and from a business point of view.
Apple was a completely different situation. For one, they control the hardware, so compatibility and drivers weren't an issue. I don't know much about the previous Mac-OS versions, so I really don't know if it was technically necessary or not, but in the end it seemed to have been a good decision (it sure made me suddenly crave a Mac, something I thought would never happen).
In my opinion the article (and author) is a bit uninformed. He had some of the tech terms right, and sounds reasonably intelligent, sure, but I don't feel he understands the underlying issues. Sounds more like an attempt to jump on the "MS sucks, Linux Rocks" bandwagon, by pointing out some far-fetched "wouldn't it be ironic?" scenerio...
Is it just me or does Diffie's statement, in a generalised form, kind of nullify the usefulness of asymmetric crypto? Or maybe I've missed the point...
I won't say you've missed the point, but there is a difference. When you distribute a binary-only (for example) and secret algorithym, it's easy enough for one to reverse engineer that code. Obviously something in your PC understands how the code works, and it's only a matter of time and patience before someone, somewhere, figures it out.
With a "private" key, OTOH, you never give anyone that key. It's "secret", yes, but in a different way. There is nothing given to the users that can easily lead to the private key (without millions of CPU-years anyway).
Since the algo is known, and public, and heavily tested, the probabilities of it being cracked are slim enough to be considered secure. Much moreso than the probability of someone figuring out your secret (but not public/private key-based) algo.
...may not know anything about why open source is good.
Anything that helps convince my crypto-less clients to use GnuPG [gnupg.org] is very, very helpful.
One can obtain the same security with closed-source applications that also happen to be based on the same open PGP standard.
In other words, open source != open standards. I don't see this argument pushing open source at all, really. The author simply draws a parallel between OSS and open standards, though the reasons for each being "open" are, generally, different. There are some similarities of course, but the point is, open standards are quite often used in closed-source applications. SSL, PGP, and many other crypto standards are found in proprietary applications.
It is a great argument for why the user should be using open standards, but does nothing to push open source.
It's like someone at CNET said, "Give us 1,000 words on why OSS is good."
I'm not sure open algorithyms == open source. Many implementations of open standards (SSL, PGP, etc) are in fact closed-source, for their own reasons. Sure, the crypto functions are based on public standards, but that doesn't mean they are in any way supporting open source.
Granted, some of the same principals apply (which is likely why he mentioned OSS vs Closed Source first); things like "fix the vulnerabilities instead of hiding them", or "let's all work together and agree on a standard, then perfect it". But in the end, the concept applies equally to closed-source applications that happen to use an open standard for a specific function.
All in all, he doesn't really bring any conclusions about whether OSS is better than the alternative; instead, he draws a parallel to crypto standards, which are, generally, open for very different.
In order to get my few dollars, I have to give out all my personal info, social security number, mother's maiden name, etc, etc?
I know exageration is rampant on Slashdot... but allow me to point out that it only asks for your name, address, email, and the last four digits of your SSN. Nowhere do I see any mention of Mother's maiden name.
The information is very basic, and the last four digits of the SSN is a good way to verify identity should it be necessary (eg, you fill the form out 100 times with different info).
Still, if it lets me get out of repairing folks' computers, it might be worth it.
I'm sure you mean this jokingly, but consider that you can still repair your friend's car, or cut his hair, without a license. You only have to have a license if you want to do so as a business.
Of course, after reading your comment, I'm going to start telling people that anyway. Most people would just look at you and say "oh."
Slashdot Mirror
This guy says that according to USENET archives, the Voodoo 3 was available in 1995? umm no
I was wondering about that myself. I just recently retired my two Voodoo3 3000s, and when I got them in 1998 they were top-of-the-line.
And, the Voodoo with TV-Out was the 3500, not the 3000 that he mentions.
Hell, in 1995 I believe 3D cards were of the "pass-thru cable" variety -- I don't think any 2D/3D combo cards were even out yet. The original Voodoo might have been out, but certainly not the Voodoo3...
And I don't believe TV-Out was easily available except through an expensive "scan converter"...
Anyway, much of what he says is conflicting even with the other things he says, and then there are a few technical and chronological problems.
I won't say it's bullshit, but I am pretty skeptical (not to mention X-Box -- I don't think people called a PC a "box" back then, and he has no real reasoning for having come up with the name...)
The whole reason the GPL was created was to create software which saw computer users as a community of citizens assisting one another. not a consummers of software services. That is it was designed to encourage the free sharing of information in a communal fashion. TCPA/Palladium is designed to encourage the restriction of information to the appropriate parties.
I'm not sure I follow your argument. So SSH is bad? SSL and PGP are bad?
That's what security and privacy is all about -- keeping others out. I don't want anyone sniffing my sessions when I'm working on the server, so I use SSH (to connect from one GPL Linux box to another, no less).
I don't think the GPL is about *everything* being open and free. While I don't fully agree with much of the GPL, I do know that the GPL doesn't restrict using secure, encrypted protocols to keep sensitive information private. If it did, that'd just be one more thing I didn't agree with in the GPL.
Or perhaps I'm missing your point?
Think about third-party hardware crypto cards/modules. To me, TCPA is just that, but on-board, and with more hooks to ensure that the operating environment is secure (or at least is in a known state). I don't think it matters what OS is being used at all -- just that it hasn't been comprimised.
The availability of GPL drivers does not change the fact that this is an enabling technology for DRM and not much else.
I still don't see this. Can you explain how TCPA hardware enables DRM? How would you implement a DRM scheme using the TCPA hardware?
TCPA isn't about that, really, and I don't see why you think that it is. I have explained this a few times already here, so I'll just link to one of my other comments.
My personal view (an oversimplification which may not be accurate) is that DRM and TCPA are mostly mutually exclusive ideas, and that Palladium is a union of the two.
I'm not sure I'd say mutually exclusive. It's more like DRM and security are similar, but different issues. Different in that security is about not trusting the outside world, where DRM is about not trusting the user.
Both problems can be solved with similar technologies (public/private key pairs, secure, hardware-based key storage, etc). But since the goals are different the overlap isn't that big (DRM would require physical tamper-proofing as well as NO user access to the chip's functions).
Palladium is in fact a union of the two, however. Personally I think Palladium's only intention was for DRM, and the "trusted computing" thing was an idea stolen from someone else (possibly the TCPA?) for the sole purpose of marketing Palladium as a Good Thing, and thus added to the Palladium spec.
I just hope more people will read either these whitepapers, or the actual spec if they don't trust IBM, and really understand the issues. I have no problem with informed arguments; I can't stand when people put together entire websites of uninformed garbage.
> It's one thing I hate about Mozilla (why can't they use the native menus and widgets?)
:)
Because they wouldn't be able to comply with CSS.
A couple people have corrected me on this, and I now understand. As I said, I do use Mozilla pretty much exclusively, and lately most of my previous gripes with Mozilla's widgets have gone away. The text box IS much better, and the menus work okay under multiple monitor systems (it had issues back in... geez, M12 I think it was. Moz has sure come a long way)
It does seem that the web will sorta need its own toolkit, and with this in mind, Mozilla's approach is pretty decent. For MSIE to update widgets, it has to update the OS widgets (which it *does* do from time to time; this is why so many programs that have nothing to do with the web require a certain IE version to be installed).
So in short, I'm convinced, I agree, and I like Mozilla even more now
But this spec also allows it from what I got out of the paper.
Funny, I got this from the paper:
The TCPA chip does not and cannot control execution!
Which means it will NOT prevent any operating system from booting. It will prevent an operating system environment from decrypting data with the chip if it's not the OS that was used when the data was encrypted -- but that works in both (all) directions.
Plus, of course the features offered by the chip can be disabled in the BIOS.
I can easily envision them integrating it into their WMP 9 technology and preventing all those without TCPA access to the media.
TCPA isn't needed for this, and in fact doesn't really do much to help this type of DRM. How can you encode files on your machine, that require a chip on my motherboard -- well, to do what, exactly?
---
Imagine a cracker breaks into your machine one way or another. He can currently find your PGP key, your SSH keys, etc, very easily.
Now imagine if those keys were instead generated and stored on a special chip on the motherboard. The chip itself handles the decryption, so the key never needs to leave the chip. Even further, if something changed in the environment (specific things that might indicate a virus, worm, or other breach), the chip will not decrypt the data.
Wouldn't that be pretty damned secure? Well, basically that is TCPA.
TCPA is not particularly well suited to DRM applications, as this was not its intent.
Maybe the OS will encode all recorded music with your public key so it's unplayable on any other machine? Who knows, the possibilites really are limitless.
Why does an OS need TCPA to do this? In fact, IIRC Windows Media Player does something like this now, by default even. TCPA doesn't enable this (or more correctly, absense of TCPA doesn't make this impossible).
TCPA is basically this:
- Generates key pairs (a fast DSP)
- Stores key pairs
- Performs encryption/decryption, only if everything is okay
The "everything is okay" part simply means that the BIOS hasn't been messed with, and the OS is in a known state. Yes, this will prevent (say) using Linux to decrypt data that you encrypted while in Windows -- but it also goes the other way (data encrypted under Linux can't be decrypted under Windows). That's the beauty of it; an attacker can't just pop a boot disk in and try to read your data.
I think the confusion is that the term "Trusted Computing" sounds a lot like what we all heard about Palladium -- but it is NOT the same thing. Palladium asks for a lot more than TCPA, and at the present Palladium isn't designed for TCPA. They want (and have patents on) their own hardware implemented, as well as CPU hacks, and other junk.
TCPA isn't even a part of the Palladium picture.
actually, the reason for that statement is to disclaim any bias the author may have against DRM.
/. crowd specifically), so his including that tries to show early on that this is not a pro-DRM issue. His intent is to show that TCPA is NOT DRM, and he further implies that if it were he wouldn't be pushing for TCPA (by showing his dislike for DRM).
:)
I have to disagree. We seem to have taken two different interpretations, but the author in fact did state that he is against DRM, and in one of the papers he specifically says:
My personal opinion (not speaking for IBM) is that
DRM is stupid, because it can never be effective[6,7], and it takes away existing rights of the consumer. But
this is not the place for that debate.
But I believe this document was targeted at the Linux community (perhaps even the
My response was probably more long-winded than it needed to be... but hopefully it makes sense
It's unfortionate to see White Papers, which in my opinion, should present fact, be so biased.
I agree that the whitepapers seemed to use the phraze "I personally" a bit too much (one calls DRM "stupid"!) -- but to me it seems like they wanted to quickly put something together to help inform the Linux community (and possibly the Slashdot community in particular) of what TCPA is all about.
I'm glad they released something to help curb all the negative FUD that I keep seeing. It still doesn't seem to be helping much, since over half the comments here are anti-TCPA FUD themselves (and most of the "facts" I'm seeing in this story's comments are in fact addressed in the rebuttal document linked in the story).
"We're all fucked."
I'm not entirely sure if this is sarcastic, serious, or what, but in any case, could you elaborate? Do you have an actual opinion on this, or is that all you wanted to say?
If you mean it seriously, and you mean to imply that the TCPA is inherently a bad thing, you obviously didn't read the whitepaper (and thus aren't well suited to present us with a "summary"). I think with IBM on board with this, we (Linux users specifically, other "alternate OS" users as well) should feel a lot better about this. Hell, we already have GPL drivers for Linux TCPA applications...
Good to see??? umm... I hope your joking, cause otherwise, you have NO FUCKING CLUE WHAT YOU'RE TALKING ABOUT!!!
.sig link to notcpa.org, I guess you're not a supporter of the TCPA.
I'm honestly not sure what you mean here, but from your
So tell me -- did you read the whitepapers mentioned in the article? Or are you simply going by the FUD presented at notcpa.org?
Seriously, whether you are for or against the TCPA, read the white-papers IBM put together. Note that it has nothing to do with DRM or Palladium, and the author of one of the papers says "DRM is stupid, but that's another paper".
Or go read the specifications yourself.
In short:
1) The TCPA is NOT Palladium
2) It does NOT protect against physical tampering (thus not being well suited for DRM usage)
3) It doesn't use any cert authority or "code signing" or anything like that. This again is not Palladium, and this is not the XBox.
It really is about helping to protect you against crackers or viruses/worms from obtaining your private keys (be it SSH, SSL, PGP, or whatever future application comes up).
And IMO it is good to see IBM on-board. They've already written GPL drivers for Linux, and are showing massive support from the very beginning -- something you rarely see with *any* new specification or proposed standards. Any Linux user should be glad IBM is on-board as well.
Would it damage your geek-manliness if your OS of choice was actually easy to use?
You misinterpreted my post. I think it's fine if developers work toward making Linux easy to use. I'm just not one who really cares if Linux is accepted on the desktop by the average person. Linux works for me (I run with and without X, depending on the purpose of the particular machine).
It seems like any time someone (rather, some company) starts to focus on "Linux on the Desktop", it fails. Sometimes miserably, and sometimes the effort takes away from other aspects of the distro.
RedHat 8.0 is perty when you boot it up, and a lot of nice things happened. It worked on my laptop out-of-the-box and required zero X configuration on my part. I was quite impressed with the installation procedure, and that everything but the Winmodem worked right away.
But on the command-line side, I don't see much of anything changed from 7.x. The transition from 5.x to 6.x provided a lot of nice additions, and 7.x added more (2.4 kernel, journaling file system by default, etc). 8.x looks (from the console) like 7.x (minus any mp3 utilities). It seems that each release focuses more and more on the desktop side of things...
Anyway, my point is this: push for Linux on the desktop, or don't -- it doesn't make a difference to me. I'm not against it, but I'm not specifically hoping for it either. I like Linux for what it is already great for -- servers, embeded applications, etc. But again, I'm not against it either -- it's not an elitist (or "geek-manliness") issue at all.
Why must we fight this "battle"? Who cares if Grandma can use Linux or not? As long as enough geeks are using Linux to keep the platform viable, this geek will be happy, and perfectly content.
I've been making this argument for a while. I don't care about "Linux on the Desktop". Linux on the server, and Linux on my desktop is all I care about.
I use Windows for some tasks. I use Linux for others (including all of my multimedia needs, as it happens). I don't want Linux to become a replacement for Windows -- I already have one of those. My Dad doesn't need Linux -- Windows does everything he needs.
You can argue the cost issue, or the monopolistic practices, etc, but realistically most people don't care about that. Most people, given a choice, would choose Windows, even if it meant higher cost and having to "activate" their installation. Even if Linux were free, worked out of the box, and could open most MS Office docs -- it wouldn't matter.
So, let's keep Linux for ourselves. Those who can't figure out MPlayer, the command-line, X configuration, etc -- don't need Linux. They don't want Linux.
If you look for reasons to be unhappy with ANYTHING, you'll find them. Why not focus on what's good and what needs to be improved?
The thing is, he does make some good points. For example, why does everyone need to reinvent the GUI wheel (as if we didn't have enough widget sets and window managers to deal with on *nix)? Why does everything have to be skinable?
I use MPlayer extensively -- but I don't touch the GUI, I have a text-based front-end for it. When it comes to playing video files, scaling, utilizing my ATI's TV-Out, etc -- MPlayer kicks all sorts of ass.
However, it's such a common trend these days to make everything skinable, and to create one's own interface standards. That's one of the things I hate most about WMP for Windows (that, and it periodically just stops functioning).
It's one thing I hate about Mozilla (why can't they use the native menus and widgets?) -- though I use Mozilla exclusively, I still feel a lot of time was wasted implementing their own text box (that still doesn't work quite right), menus, etc...
While I personally use MPlayer, I can't say I'd recommend it to someone who doesn't know how to compile software (using a specific gcc version no less), figure out the appropriate command-line options, etc. Tried to walk a semi-linux-literate person through it, and he still has no working MPlayer. As for the GUI, I also wouldn't recommend it, for most of the reasons noted in Jamie's rant.
Cars are the worst. I once opened a friends car ( same make, model as mine ) with my keys. I think the car manufactuers must only have 50 or so lock variations.
General Motors for the longest time only had some 15 ignition keys, and 15 door keys (back when the two still used separate keys). I think the idea was that for any two cars, the chances of both keys being the same were pretty slim (1 in 15*15).
I had a GM car with a broken trunk lock. I headed down to the junk yard, with my own door/trunk key in hand, and within about 20 junk cars I found a trunk lock mechanism that fit my existing key.
That, and most people assume that keys are completely unique. People who don't know, assume, and usually error on the side that makes them feel safer (ignorance is bliss I suppose).
I only learned this by having worked for a used car dealer; prior to that I was under the same assumption (and of course GM was the *last* manufacturer to still use separate keys for the door and ignition -- and it was only because they outsourced each from different companies).
AFAIK they don't even offer a hydrahead adapter for the one DVI port to split to two (doubt its possible without a proprietary output like the Radeon VE's).
I'm not sure what that last part means (VE?)... but I have a PNY ti4600, using the DVI/VGA adaptor that came with a Radeon card (to drive two analog monitors). Doesn't seem there was anything proprietary there, and I was pretty sure that the analog-compatibility for DVI connectors was standardized. It was an assumption, but it worked.
No less, I agree that they should put two DVI ports on them, and supply at least one adaptor. One day I'd like to go all LCD (or Plasma by then, but digital anyway). I'd hate to have to run one analog (or buy another card).
And maybe the DVI/VGA adaptors should be in the form of a short cable (the current ones add about 3" to the required-space behind the PC, and it really is a lot of weight on the connector)...
What I wonder is why just not put all the transistors, the chip and the ram...on the other side of the circuitboard! No-one looses a pci slot that way.
That would certainly look funky. Then again, I still think of PCI/AGP cards as "upside-down"...
I believe that extending the size to that side of the card would be considered "out of spec", and some motherboards would have a problem with that. My Aptiva board for example has the CPU clip/thing (Slot-1) very close to the AGP card, so in that box at least this wouldn't work.
That's how I get my dual monitor setup; geforce in the agp, old pci gfx card in the 1st pci slot (some cards still complain if they're not in the first slot).
First, I've never had a PCI video card complain/care about which slot it's in (at least not in the last 7 or 8 years). Second, I'm sure the FX supports dual outputs like the ti4600 I'm currently using on two 17" monitors does (that's the one thing that sold me; they don't readily advertise this, but it'll drive two at once easily, both accelerated, and either one can run your full-screen games).
Connecting two analog monitors simply involves getting an adaptor, and the digital output becomes a second analog one. Takes some trickery in the driver to get it to function "properly" (so Windows sees it as two separate cards -- the only option that I can stand), but I've had no problems since ditching my two Voodoo3's for the ti4600.
Anyway, I don't like the fan setup myself either. But where I used to care about precious PCI slots, I don't anymore. Between on-board components, dual-output AGP cards, and USB-this and USB-that, I have some 4 PCI slots available in my main PC... so I'm willing to live with the two-slot deal.
Windows has far too many kernel dependancies (if that's the right term) for this to happen. Think about this: how do you implement DirectX (as an example) in Linux without serious kernel hacking? I doubt something this low-level -- something that requires cooperation of all sound/video/input drivers and many internel kernel hooks -- could be done with a module.
Someone else pointed out that all hardware drivers would have to be rewritten. Filename/path conventions (backslash != forward slash), not to mention the underlying filesystem, has to change. Filesystem attributes (ACLs, etc) have to be implemented.
Then you have the multi-thread capabilities. I don't know where Linux is at on that currently, but I don't honestly think it's up there with Windows, or at minimum we're talking serious differences in implementation.
And what of applications? The strong-hold Microsoft has on the PC market lies primarily in a) hardware/driver availability, and b) software availability.
Even if you s/Linux/BSD/, the above all still applies.
And seriously -- is the Windows 2000/XP core bad enough to warrant replacement? I don't think it is, personally. The vast majority of the problems I have with Windows is the applications on top of it (IIS, MSIE, Outlook, etc). The OS itself is pretty solid, honestly, as long as you have decent hardware (and drivers). Yes, there is TONS of room for improvement, but that doesn't warrant dumping the entire core and starting with something new...
So no, won't ever happen, and not because of pride or anything else -- it won't happen because it's not necessary, and would be a very bad decision, both technically and from a business point of view.
Apple was a completely different situation. For one, they control the hardware, so compatibility and drivers weren't an issue. I don't know much about the previous Mac-OS versions, so I really don't know if it was technically necessary or not, but in the end it seemed to have been a good decision (it sure made me suddenly crave a Mac, something I thought would never happen).
In my opinion the article (and author) is a bit uninformed. He had some of the tech terms right, and sounds reasonably intelligent, sure, but I don't feel he understands the underlying issues. Sounds more like an attempt to jump on the "MS sucks, Linux Rocks" bandwagon, by pointing out some far-fetched "wouldn't it be ironic?" scenerio...
Is it just me or does Diffie's statement, in a generalised form, kind of nullify the usefulness of asymmetric crypto? Or maybe I've missed the point...
I won't say you've missed the point, but there is a difference. When you distribute a binary-only (for example) and secret algorithym, it's easy enough for one to reverse engineer that code. Obviously something in your PC understands how the code works, and it's only a matter of time and patience before someone, somewhere, figures it out.
With a "private" key, OTOH, you never give anyone that key. It's "secret", yes, but in a different way. There is nothing given to the users that can easily lead to the private key (without millions of CPU-years anyway).
Since the algo is known, and public, and heavily tested, the probabilities of it being cracked are slim enough to be considered secure. Much moreso than the probability of someone figuring out your secret (but not public/private key-based) algo.
...may not know anything about why open source is good.
Anything that helps convince my crypto-less clients to use GnuPG [gnupg.org] is very, very helpful.
One can obtain the same security with closed-source applications that also happen to be based on the same open PGP standard.
In other words, open source != open standards. I don't see this argument pushing open source at all, really. The author simply draws a parallel between OSS and open standards, though the reasons for each being "open" are, generally, different. There are some similarities of course, but the point is, open standards are quite often used in closed-source applications. SSL, PGP, and many other crypto standards are found in proprietary applications.
It is a great argument for why the user should be using open standards, but does nothing to push open source.
It's like someone at CNET said, "Give us 1,000 words on why OSS is good."
I'm not sure open algorithyms == open source. Many implementations of open standards (SSL, PGP, etc) are in fact closed-source, for their own reasons. Sure, the crypto functions are based on public standards, but that doesn't mean they are in any way supporting open source.
Granted, some of the same principals apply (which is likely why he mentioned OSS vs Closed Source first); things like "fix the vulnerabilities instead of hiding them", or "let's all work together and agree on a standard, then perfect it". But in the end, the concept applies equally to closed-source applications that happen to use an open standard for a specific function.
All in all, he doesn't really bring any conclusions about whether OSS is better than the alternative; instead, he draws a parallel to crypto standards, which are, generally, open for very different.
In order to get my few dollars, I have to give out all my personal info, social security number, mother's maiden name, etc, etc?
I know exageration is rampant on Slashdot... but allow me to point out that it only asks for your name, address, email, and the last four digits of your SSN. Nowhere do I see any mention of Mother's maiden name.
The information is very basic, and the last four digits of the SSN is a good way to verify identity should it be necessary (eg, you fill the form out 100 times with different info).
Still, if it lets me get out of repairing folks' computers, it might be worth it.
I'm sure you mean this jokingly, but consider that you can still repair your friend's car, or cut his hair, without a license. You only have to have a license if you want to do so as a business.
Of course, after reading your comment, I'm going to start telling people that anyway. Most people would just look at you and say "oh."