You can't maneauver using only a solar sail, but you also can't maneauver using only a boat. It requires energy to maneauver, and in the case of a small sailboat, YOU provide that energy. As for propulsion, a combination of gravity and solar wind/photons provides that, either towards a star (gravity,) away from it (photons,) or somewhere in between(a calculated combination of the two, just like sailing.)
The thing you have to realize is that in modern processors, what few execution units exist are starved already. Adding more doesn't really make that much difference. The performance problems come from the caches, and we already build the fastest L1 caches we can for the single processor case.
While your statement "I can get so many FP and integer units on chip; what's the best way I can feed instructions from any number of threads to maximize their usage?" is mostly correct, it really doesn't fully recognize just how hard the processor works to feed instructions into those execution units. A more accurate description would be: "I can get so many transistors on a chip; what's the best way I can maximize the number of instructions executed (amount of work done), by any number of threads, on those transistors?" Currently the best way is to have a few execution units, and a LOT of cache.
Getting back to your original point, in general, a processor is any number of threads that share an L1 cache. Whether that processor shares execution units with another one is really irrelevent, and probably wouldn't offer the performance benefits necessary to make the added complexity worth it.
There are designs for which this wouldn't apply, but they would be "throughput computing" designs with big, slow L1 caches that have *dismal* uniprocessor performance. With poor uniprocessor performance the "work done" per instruction executed starts to go down, so these designs have their own set of problems.
You're misuderstanding what the verifiedvoting people seem to advocate. They advocate a piece of paper that the voter verifies BEFORE putting it in the ballot box. The idea is that we have decades of experience securing paper ballots in ballot boxes, so if the voter can verify that their paper ballot is correct, they've verified that their vote is correct.
This is not the same as advocating a receipt that the voter takes home with them and later uses to verify their vote was counted correctly. As you correctly realized, this makes vote coersion possible, and was already realized to be a BAD IDEA. That doesn't keep some people from advocating it anyway.
While I agree with most of your points, I have some comments.
As for infringed copyrighted music, there are plenty of Slashdotters (geeks) who said "go after the downloaders" and are content to see them go under.
This almost seemed to be the overriding sentiment until the RIAA started actually going after illegal downloaders. I haven't understood the seeming outrage of the reaction since then. Maybe it goes along with your arguments about the high penalties.
As for copyright, us geeks are paranoid. I doubt many people here would have problems with a copyright flag for TV or radio broadcasts (other then correctly assuming that (1) they will require new purchases of hardware and (2) they will be cracked rather quickly).
I disagree with this one. I most assurredly do NOT like a copyright flag for TV and radio broadcasts. I LIKE my VCR. I LIKE being able to dub clips from shows I tape off the TV for use in class projects, etc, or for storage to view later. I fear that the addition of a broadcast flag will interfere with my ability to do this.
What I wouldn't object to is a watermark that simply allowed identification of my VCR as the creator of any given recording, preferrably based on a flag that identified whether the source was copyrighted or not. This would allow tracking down and/or conviction of criminals after-the-fact, but wouldn't infringe on my ability to do make fair-use recordings. I'm a little less clear in the case of a camcorder, hence the source material caveat above.
My SATA drivers came on a CD-ROM that came with the motherboard. The only way that XP install would accept drivers was from a floppy. I had to use a Knoppix CD that I had lying around to copy the drivers off of the CD-ROM onto a spare floppy and then boot off the XP CD.
Now that a lot of PC manufacturers don't even include a floppy drive, it's time for Windows to be able to read new drivers off a CD-ROM, not just a floppy.
Years pass. Linux gains 20% desktop market share. Duke Nukem Forever is released for Mac and Lintel. You fish out an old computer from your closet; you want to install a Linux (kernel 3.0; compiled with gcc 3.5; with glibc 2.somethingelse; and a GNU/Darwin directory layout) to turn into a streaming virtual reality server for your apartment. Guess what's the probability of your closed-source driver still working?
This is a LINUX failing, not a proprietary driver failing. Linux should have a set of interfaces that DON'T CHANGE, that basic hardware drivers can be written to.
I'm not the first person to express this complaint, and it's something that really needs to be fixed for linux to get vendor-supported drivers.
GREG
You obviously have misunderstood those who call science a religion. The claims that science is a religion are based on the assumptions it DOES make, not those it doesn't (for instance, those who believe in science do NOT believe that scientists are infallible.)
The basic religious beliefs of science are:
We can learn about the universe by observing it.
The operation of the universe can be explained through physical laws.
Those laws are unchanging from the past to the present, and will not change in the future.
Any deviation of observed behavior from those laws is due to a flaw in the laws, and not some outside entity.
(More modern claim, see God, Dice, Universe, Einstein) Anything totally unpredictable is the result of inherent randomness in the universe, and not some outside entity.
1-3 are the fundamental beliefs of the "religion" of science. 4 probably was added in the days of Galileo, and 5 was added during the last 150 years with the development of quantum theory.
While the beliefs of science may not be unreasonable, they still represent the fundamental belief system within which science operates. There is nothing about existence that requires the universe to act within the confines of the scientific belief system. For instance, solipsism does just as complete a job of explaining the universe as science does, but without resorting to a belief that we can learn about the universe by observing it.
Ahh, but the war in the Pacific actually supports his point.
In WW2, the Pacific war was won by the atomic bomb, which prevented the bloodbath (read: additional draft) that would have resulted from an invasion of japan. If the US is in a war that they NEED to win, and are so undermanned that they NEED to institute a draft, it's time to prepare to use nuclear weapons. Otherwise, we're not really in a war we need to win, and we should move troops from where they aren't needed to where they are.
The only possible exception is an invasion of our own soil, but even then, I doubt that there would be much trouble getting enough volunteers, and there would still be circumstances where use of nuclear weapons would be appropriate.
In other words, nuclear weapons are the trump card. If backed into a corner, we should use them, or else why have them? Fighting a war that is so bad that we need to reinstitute the draft is a pretty good example of being backed into such a corner.
We have nuclear weapons. Don't mess with us. We ARE "willing to do what it takes to win."
Actually, linux 2.2.XX and even 2.0.XX are still supported and still receive security fixes.
This isn't to say that it's reasonable to expect a commercial company to support software indefinitely, but one of the benefits of open source is that you CAN find/hire someone to support your old software and backport bugfixes as appropriate.
One of the nice things about MS is that they DO backport bugfixes to old software. Patches are almost always provided for free for all supported versions of Windows. Windows is supported for an established number of years (5, I believe) and at that point the user is reasonably expected to upgrade.
The Linux kernel has a better reputation than MS, but there are plenty of companies that have worse reputations. Even Redhat only supports its products for about 3 years before expecting an upgrade.
Additionally, they should be required to disclose their audio and video formats. If they are truly a part of the system, then this information is needed for interoperability. Let's hope we get open file formats, and not RealPlayer rubbish being forced down our throats in addition to WMP!
There's an interesting idea. They can have it one of two ways:
Distribute Windows without media player, or
Disclose ALL interfaces to media player. This includes adequate documentation of all file formats, etc. that would allow a competing implementation.
It helps if for #2 above all patents would have to be offerred under terms that would allow open source implementations of those interfaces. Losing the patent rights seems like a reasonable punishment for illegal monopolistic practices.
Then you need a smarter client. A flash-only device with all the smarts of a Palm III won't do. Device drivers alone would take too much storage.
It could use a remote filesystem on the server, but then it still probably needs a faster processor since the client will be running a numbe r of communication apps.
The point is to make these things CHEAP, DUMB terminals, possibly with a few small apps that they could run on the side, but only for the purpose of keeping the data around long enough to send it to the server once the server is back within range.
The problem is not with the transport protocol for the USB cable, the problem is deciding whether the server or the tablet is going to handle interation with the USB DEVICE. This is a much harder problem and would either require a much more complicated client (if the client handles talking to the device) or some form of new protocol (if the server talks to the device.)
For an external keyboard, it probably makes sense for the tablet to handle the interaction, as it's a pretty simple one anyways. For something more complicated like a digital camera, the server is really better suited, but this would require a new protocol to allow the server to control the tablet's USB ports. Something real-time like a CD burner (or maybe even a webcam) would be a no-go either way; try explaining that to customers.
Building a new protocol isn't a show-stopper, but it increases development costs considerably, and would probably hurt reliability. This is why adding USB ports isn't a clear benefit.
In such an example you are generally looking at a bunch of computers all owned by the company. As I said, directing your own computer not to accept alteration commands from others has absolutely nothing to do with DRM.
What you misunderstand is protecting data on computers that a company owns from malicious employees requires EXACTLY the same technology that protecting music from copying by malicious consumers requires. In both cases the threat model is valuable data in a hostile computing environment where that data is to be isolated in certain ways (for instance preventing copying.) Since in the general case copying is just one of the "rights" that a company might want to control, DRM is an appropriate name for the associated technologies.
To a certain extent, companies have been doing this for years with file permissions and the like. The problem with file permissions, though, is that there are certain threats that they don't protect against very well. For instance, a user copying information that they legitimately have access to and sending it to someone who doesn't have legitimate access is quite easy to do with a system employing only file permissions.
DRM technologies close a lot of the open holes in security, if used correctly. For instance, the problem above could be alleviated by only giving a few trusted users the authority to control read access to a file, and by allowing no users authority to copy a file to another location with different permissions. Furthermore, DRM technologies protect against the threat of untrusted operating systems or untrusted software accessing the data. These are real threats in corporate data security just as much as they are threats to allowing copying of music.
When you get into non-disclosure and cooperative agreements between companies, the advantages of DRM become even more clear. In order to prevent company B from releasing important internal information about company A to third parties, apppropriate DRM can be applied by company A to such information before transmitting it to company B. This is still a reasonable use of DRM by corporations, but is also the EXACT same threat environment faced by the music industry. The only difference is that in the corporate case both companies benefit since they each have their internal data protected from the other.
In the end, it's clear that corporations have a legitimate interest in developing DRM technologies to keep internal documents safe, even though for the average consumer these technologies can cause a great deal of trouble for very little benefit. I agree that there are probably fair-use implications to DRM technologies, but these are conveniently side-stepped if all content is licensed and not purchased, which is where we seem to be heading.
The fallacy in this type of argument is that the phrase is usually used correctly
I doubt that. I honestly doubt MOST people have been exposed to enough logic to even be able to understand the true meaning of "begs the question" without some effort.
I suspect this more realistically approaches being philosophy jargon. However, since philosophy is in the humanities, its jargon is considered to be the "correct" definition, and everyone else is wrong.
But this is the first I've heard of discover, so it's unlikely that I (or anyone else like me) would have installed it.
Something as basic as hardware auto-detection should really be available (at least as an option) in the default install. I'm glad to hear that this is getting fixed.
No, bochs folks see the need, but they have serious manpower issues. We've fixed a lot of the low-hanging fruit, and getting into nitty-gritty CPU optimizations (read: host-specific, JIT-type stuff) will take a lot of work, and will probably break things in the meantime. I've put a little work into studying this lately, but am nowhere near done.
Also, yes, the bochs folks do consider keeping the debugging options working at any performance cost a major priority, but that's different from the opportunity to optimize some normal user code.
Legally, if Linksys is violating the license (this is actually a little blurry since keeping the code inside a hardware product could be deemed "internal use" and not "distribution") then they they should still be required to give out the source code to the original firmware even if they provide patches. However, the FSF tends to be VERY forgiving in cases like this, and in the past has typically accepted removing the code in all future products as sufficient.
There are two big ways that this differs from the SCO situation.
First, SCO is threatening to sue Linux customers. The FSF isn't threatening Linksys' customers, just Linksys themselves, the ones who created the breach-of-contract.
Second (and more importantly,) SCO is refusing to release the source code that they claim is infringing, thus not making a good-faith effort to mitigate damages after they discovered the breach. The FSF is being very clear about what they think Linksys has done and how they want the problem rectified.
Yes, but CPUs can make having a top-level virtualization layer easier. PowerPC is a good example. For the most part it's designed from the ground up with virtualization in mind. It can run with a top-level manager (sort of like Xen), any number of partitioning-aware OSes, and then any number of programs within those partitions that may or may not be aware of the upper-level virtualization layers (like Mac-on-Linux or VMWare.)
While consumer PowerPC machines drop the top-level manager used in servers, they still have a lot of virtualization available fairly easily.
x86 is a different beast altogether. It leaks knowledge of the fact that an OS is running in a virtual machine all over the place. It's actually quite difficult to design a CPU virtualization environment on x86 because you have to design in lots of special cases to hide the fact that code is really running in user mode.
Of course the device virtualization is still difficult, but hardware can help make high-performance CPU virtualization easier.
Undeniable proof is VERY bad in most cases. It's an important aspect of society that we have things that are inherently unprovable.
The prototypical example is voting. It's an important part of the voting system that you cannot prove to someone else that you voted for a certain candidate. This prevents people from being able to buy elections.
It's simply not enough to only have the OPTION not to prove something, you must have the INABILITY to prove it. If some unscrupulous person says "I'll torture and kill your family if you don't show me proof that you voted for my candidate," then you really don't have the option not to prove it to them, do you? The only way to make sure you have an option not to prove something is to have an inability to prove it.
While in most cases refusing TCPA attestation won't cause someone to kill your family, saying "At most you may be requested to prove something in return for being offered something that you value," fails to realize the value of data accessable by and stored on some computers. While the average home user can usually weather the loss of all data stored on their computer (as witness the lack of backup procedures for most home computers,) most banks can't. If their data is sufficiently locked inside a TCPA computer that only one software program can access it, then they have NO CHOICE but to continue using that program. We can argue about whether or not they should have chosen that program in the first place, but that's beside the point once they're locked in.
Furthermore, even for the home user there may in the future be sufficiently valuable information online and locked behind TCPA attestation requirements that it makes the user feel like they don't have a choice. It's hard to know what kinds of things will be made available online in the future, or the software restrictions that will be placed on those. Some people would rather not let the genie out of the bottle, as it were.
Since adding remote attestation creates an architecture that allows or even encourages an awful lot of remote software restrictions and vendor lock-in, the case needs to be made that the benefits outweigh the disadvantages. The EFF document does a pretty good job of enumerating the trade-offs. While it clearly has a slant towards preferring not to have remote attestation, I tend to agree with their reasoning.
Unfortunately, the general public will just use whatever Microsoft force-feeds them by default unless they're scared silly like they were around the Pentium 3 Chip ID, and even then they would have just taken it if Intel hadn't removed the feature. Most people don't know and don't care about the implications of hardware like this, so their choice is being taken away without their knowledge whatsoever.
The important thing that it provides is secure key storage. You can store cryptographic keys in a way that they can only be accessed on the owner's computer, and only be transferred to another computer by (I believe) their owner.
Also, these keys never have to be available in cleartext on the system, another protection against broken cryptographic programs or memory protection.
Slashdot Mirror
You can't maneauver using only a solar sail, but you also can't maneauver using only a boat. It requires energy to maneauver, and in the case of a small sailboat, YOU provide that energy. As for propulsion, a combination of gravity and solar wind/photons provides that, either towards a star (gravity,) away from it (photons,) or somewhere in between(a calculated combination of the two, just like sailing.)
How do you stop at the other end? It's obvious with Orion or a normal solar sail, but where does the energy come from with a laser pumped solar sail?
The thing you have to realize is that in modern processors, what few execution units exist are starved already. Adding more doesn't really make that much difference. The performance problems come from the caches, and we already build the fastest L1 caches we can for the single processor case.
While your statement "I can get so many FP and integer units on chip; what's the best way I can feed instructions from any number of threads to maximize their usage?" is mostly correct, it really doesn't fully recognize just how hard the processor works to feed instructions into those execution units. A more accurate description would be: "I can get so many transistors on a chip; what's the best way I can maximize the number of instructions executed (amount of work done), by any number of threads, on those transistors?" Currently the best way is to have a few execution units, and a LOT of cache.
Getting back to your original point, in general, a processor is any number of threads that share an L1 cache. Whether that processor shares execution units with another one is really irrelevent, and probably wouldn't offer the performance benefits necessary to make the added complexity worth it.
There are designs for which this wouldn't apply, but they would be "throughput computing" designs with big, slow L1 caches that have *dismal* uniprocessor performance. With poor uniprocessor performance the "work done" per instruction executed starts to go down, so these designs have their own set of problems.
You're misuderstanding what the verifiedvoting people seem to advocate. They advocate a piece of paper that the voter verifies BEFORE putting it in the ballot box. The idea is that we have decades of experience securing paper ballots in ballot boxes, so if the voter can verify that their paper ballot is correct, they've verified that their vote is correct.
This is not the same as advocating a receipt that the voter takes home with them and later uses to verify their vote was counted correctly. As you correctly realized, this makes vote coersion possible, and was already realized to be a BAD IDEA. That doesn't keep some people from advocating it anyway.
"partimage -z 0 -d save /dev/hda5 /dev/null"?
So would this work with (for instance) "dd if=/dev/hda5 of=/dev/null" if the disk you're interested in cacheing is /dev/hda5, and is already mounted?
What I wouldn't object to is a watermark that simply allowed identification of my VCR as the creator of any given recording, preferrably based on a flag that identified whether the source was copyrighted or not. This would allow tracking down and/or conviction of criminals after-the-fact, but wouldn't infringe on my ability to do make fair-use recordings. I'm a little less clear in the case of a camcorder, hence the source material caveat above.
Okay, how's this:
My SATA drivers came on a CD-ROM that came with the motherboard. The only way that XP install would accept drivers was from a floppy. I had to use a Knoppix CD that I had lying around to copy the drivers off of the CD-ROM onto a spare floppy and then boot off the XP CD.
Now that a lot of PC manufacturers don't even include a floppy drive, it's time for Windows to be able to read new drivers off a CD-ROM, not just a floppy.
The basic religious beliefs of science are:
- We can learn about the universe by observing it.
- The operation of the universe can be explained through physical laws.
- Those laws are unchanging from the past to the present, and will not change in the future.
- Any deviation of observed behavior from those laws is due to a flaw in the laws, and not some outside entity.
- (More modern claim, see God, Dice, Universe, Einstein) Anything totally unpredictable is the result of inherent randomness in the universe, and not some outside entity.
1-3 are the fundamental beliefs of the "religion" of science. 4 probably was added in the days of Galileo, and 5 was added during the last 150 years with the development of quantum theory.While the beliefs of science may not be unreasonable, they still represent the fundamental belief system within which science operates. There is nothing about existence that requires the universe to act within the confines of the scientific belief system. For instance, solipsism does just as complete a job of explaining the universe as science does, but without resorting to a belief that we can learn about the universe by observing it.
Ahh, but the war in the Pacific actually supports his point.
In WW2, the Pacific war was won by the atomic bomb, which prevented the bloodbath (read: additional draft) that would have resulted from an invasion of japan. If the US is in a war that they NEED to win, and are so undermanned that they NEED to institute a draft, it's time to prepare to use nuclear weapons. Otherwise, we're not really in a war we need to win, and we should move troops from where they aren't needed to where they are.
The only possible exception is an invasion of our own soil, but even then, I doubt that there would be much trouble getting enough volunteers, and there would still be circumstances where use of nuclear weapons would be appropriate.
In other words, nuclear weapons are the trump card. If backed into a corner, we should use them, or else why have them? Fighting a war that is so bad that we need to reinstitute the draft is a pretty good example of being backed into such a corner.
We have nuclear weapons. Don't mess with us. We ARE "willing to do what it takes to win."
Actually, linux 2.2.XX and even 2.0.XX are still supported and still receive security fixes.
This isn't to say that it's reasonable to expect a commercial company to support software indefinitely, but one of the benefits of open source is that you CAN find/hire someone to support your old software and backport bugfixes as appropriate.
One of the nice things about MS is that they DO backport bugfixes to old software. Patches are almost always provided for free for all supported versions of Windows. Windows is supported for an established number of years (5, I believe) and at that point the user is reasonably expected to upgrade.
The Linux kernel has a better reputation than MS, but there are plenty of companies that have worse reputations. Even Redhat only supports its products for about 3 years before expecting an upgrade.
- Distribute Windows without media player, or
- Disclose ALL interfaces to media player. This includes adequate documentation of all file formats, etc. that would allow a competing implementation.
It helps if for #2 above all patents would have to be offerred under terms that would allow open source implementations of those interfaces. Losing the patent rights seems like a reasonable punishment for illegal monopolistic practices.Just to be picky: that sudo command won't work.
/etc/hosts >> /hosts.txt <ENTER>
/bin/sh <ENTER> /etc/hosts >> /hosts.txt <ENTER>
if you meant:
sudo cat
type password
Then this won't work, since the shell redirect is running in the shell of the non-admin user. However, if you meant:
sudo
type password
cat
Then it would work.
Then you need a smarter client. A flash-only device with all the smarts of a Palm III won't do. Device drivers alone would take too much storage.
It could use a remote filesystem on the server, but then it still probably needs a faster processor since the client will be running a numbe r of communication apps.
The point is to make these things CHEAP, DUMB terminals, possibly with a few small apps that they could run on the side, but only for the purpose of keeping the data around long enough to send it to the server once the server is back within range.
The problem is not with the transport protocol for the USB cable, the problem is deciding whether the server or the tablet is going to handle interation with the USB DEVICE. This is a much harder problem and would either require a much more complicated client (if the client handles talking to the device) or some form of new protocol (if the server talks to the device.)
For an external keyboard, it probably makes sense for the tablet to handle the interaction, as it's a pretty simple one anyways. For something more complicated like a digital camera, the server is really better suited, but this would require a new protocol to allow the server to control the tablet's USB ports. Something real-time like a CD burner (or maybe even a webcam) would be a no-go either way; try explaining that to customers.
Building a new protocol isn't a show-stopper, but it increases development costs considerably, and would probably hurt reliability. This is why adding USB ports isn't a clear benefit.
To a certain extent, companies have been doing this for years with file permissions and the like. The problem with file permissions, though, is that there are certain threats that they don't protect against very well. For instance, a user copying information that they legitimately have access to and sending it to someone who doesn't have legitimate access is quite easy to do with a system employing only file permissions.
DRM technologies close a lot of the open holes in security, if used correctly. For instance, the problem above could be alleviated by only giving a few trusted users the authority to control read access to a file, and by allowing no users authority to copy a file to another location with different permissions. Furthermore, DRM technologies protect against the threat of untrusted operating systems or untrusted software accessing the data. These are real threats in corporate data security just as much as they are threats to allowing copying of music.
When you get into non-disclosure and cooperative agreements between companies, the advantages of DRM become even more clear. In order to prevent company B from releasing important internal information about company A to third parties, apppropriate DRM can be applied by company A to such information before transmitting it to company B. This is still a reasonable use of DRM by corporations, but is also the EXACT same threat environment faced by the music industry. The only difference is that in the corporate case both companies benefit since they each have their internal data protected from the other.
In the end, it's clear that corporations have a legitimate interest in developing DRM technologies to keep internal documents safe, even though for the average consumer these technologies can cause a great deal of trouble for very little benefit. I agree that there are probably fair-use implications to DRM technologies, but these are conveniently side-stepped if all content is licensed and not purchased, which is where we seem to be heading.
I suspect this more realistically approaches being philosophy jargon. However, since philosophy is in the humanities, its jargon is considered to be the "correct" definition, and everyone else is wrong.
But this is the first I've heard of discover, so it's unlikely that I (or anyone else like me) would have installed it.
Something as basic as hardware auto-detection should really be available (at least as an option) in the default install. I'm glad to hear that this is getting fixed.
No, bochs folks see the need, but they have serious manpower issues. We've fixed a lot of the low-hanging fruit, and getting into nitty-gritty CPU optimizations (read: host-specific, JIT-type stuff) will take a lot of work, and will probably break things in the meantime. I've put a little work into studying this lately, but am nowhere near done.
Also, yes, the bochs folks do consider keeping the debugging options working at any performance cost a major priority, but that's different from the opportunity to optimize some normal user code.
Legally, if Linksys is violating the license (this is actually a little blurry since keeping the code inside a hardware product could be deemed "internal use" and not "distribution") then they they should still be required to give out the source code to the original firmware even if they provide patches. However, the FSF tends to be VERY forgiving in cases like this, and in the past has typically accepted removing the code in all future products as sufficient.
There are two big ways that this differs from the SCO situation.
First, SCO is threatening to sue Linux customers. The FSF isn't threatening Linksys' customers, just Linksys themselves, the ones who created the breach-of-contract.
Second (and more importantly,) SCO is refusing to release the source code that they claim is infringing, thus not making a good-faith effort to mitigate damages after they discovered the breach. The FSF is being very clear about what they think Linksys has done and how they want the problem rectified.
Yes, but CPUs can make having a top-level virtualization layer easier. PowerPC is a good example. For the most part it's designed from the ground up with virtualization in mind. It can run with a top-level manager (sort of like Xen), any number of partitioning-aware OSes, and then any number of programs within those partitions that may or may not be aware of the upper-level virtualization layers (like Mac-on-Linux or VMWare.)
While consumer PowerPC machines drop the top-level manager used in servers, they still have a lot of virtualization available fairly easily.
x86 is a different beast altogether. It leaks knowledge of the fact that an OS is running in a virtual machine all over the place. It's actually quite difficult to design a CPU virtualization environment on x86 because you have to design in lots of special cases to hide the fact that code is really running in user mode.
Of course the device virtualization is still difficult, but hardware can help make high-performance CPU virtualization easier.
Undeniable proof is VERY bad in most cases. It's an important aspect of society that we have things that are inherently unprovable.
The prototypical example is voting. It's an important part of the voting system that you cannot prove to someone else that you voted for a certain candidate. This prevents people from being able to buy elections.
It's simply not enough to only have the OPTION not to prove something, you must have the INABILITY to prove it. If some unscrupulous person says "I'll torture and kill your family if you don't show me proof that you voted for my candidate," then you really don't have the option not to prove it to them, do you? The only way to make sure you have an option not to prove something is to have an inability to prove it.
While in most cases refusing TCPA attestation won't cause someone to kill your family, saying "At most you may be requested to prove something in return for being offered something that you value," fails to realize the value of data accessable by and stored on some computers. While the average home user can usually weather the loss of all data stored on their computer (as witness the lack of backup procedures for most home computers,) most banks can't. If their data is sufficiently locked inside a TCPA computer that only one software program can access it, then they have NO CHOICE but to continue using that program. We can argue about whether or not they should have chosen that program in the first place, but that's beside the point once they're locked in.
Furthermore, even for the home user there may in the future be sufficiently valuable information online and locked behind TCPA attestation requirements that it makes the user feel like they don't have a choice. It's hard to know what kinds of things will be made available online in the future, or the software restrictions that will be placed on those. Some people would rather not let the genie out of the bottle, as it were.
Since adding remote attestation creates an architecture that allows or even encourages an awful lot of remote software restrictions and vendor lock-in, the case needs to be made that the benefits outweigh the disadvantages. The EFF document does a pretty good job of enumerating the trade-offs. While it clearly has a slant towards preferring not to have remote attestation, I tend to agree with their reasoning.
Unfortunately, the general public will just use whatever Microsoft force-feeds them by default unless they're scared silly like they were around the Pentium 3 Chip ID, and even then they would have just taken it if Intel hadn't removed the feature. Most people don't know and don't care about the implications of hardware like this, so their choice is being taken away without their knowledge whatsoever.
Didn't read the document, did you?
The important thing that it provides is secure key storage. You can store cryptographic keys in a way that they can only be accessed on the owner's computer, and only be transferred to another computer by (I believe) their owner.
Also, these keys never have to be available in cleartext on the system, another protection against broken cryptographic programs or memory protection.
Not in non-ascii character sets where the numerals aren't in a contiguous 0123456789 block.
Or does atoi() get to assume ascii?