Well, it's fundamental, but it's not unavoidable; what they've done is avoid it by not learning too much. The trick is that you can make a copy of a particle without finding out exactly the state of the old particle, because you don't know the state you copied either (oddly enough, this means that you can't then measure both and come up with better information).
This is, in fact, an example of science following what the laws of nature actually say, but finding a way that what they want to do doesn't actually violate the laws, despite the fact that a less clear understanding of nature would make it seem impossible.
The common wisdom, as I know it, is that Betamax was technologically superior, but VHS was in the right place at the right time, and ended up with the whole market. Considering just the item itself, Beta is better, but the whims of the market (the whole product, although what is important is only obvious in hindsight) are more important than the finer points of technology.
Of course, the wisdom imagines a semi-mythical time when neither technology was developed into a product; people don't wish that 1-hour tapes had won the market, they wish that Beta encoding had won, either by being marketted more effectively, or even simply by being used in VHS recorders. The real question is not why consumers buy technologically inferior but more suitable products, it's why more suitable products are made with inferior technology; the answer is that the wrong company owns the wrong technology.
It is in your best interest if it means more people will accept your digital signature instead of a forgable handwritten one, or if you're ever accepting signatures. But there's no way that someone could actually tell whether you're using a Fritz chip (since these don't have any keys set at the factory) unless they can inspect the computer; you could, in fact, simulate the whole thing in software with unprotected keys.
Intuitive deisgn of anything that people will need to change in the future is more important than anything else, because anything you do efficiently but confusingly now will get changed in the future to be broken. If a future programmer can understand your code easily, it can then be optimized if it turns out to be too slow. And good design often turned out to be both efficient and intuitive; it tends to be free of the junk that both makes things confusing and slow.
For that matter, how fast do you want the testing infrastructure to run?
I recently set up windows under win4lin, and it was not obvious in several cases whether something was the same drive or not. Admittedly, some of this was that the "local hard drive" contained NFS stuff handled by the underlying linux, but half of the time I couldn't tell what drive (as far as Windows was concerned) I was looking at.
This generation of chess programs are actually basing thier play not exclusively on the code, but also on a database of games played by various people, so it's not exclusively the programmer, but also involves what the program can learn from historical play (In fact, current programs can attempt to play like specific human players).
So the programmer is actually writing a program to learn how to play chess well from looking at good play, so the program can surpass the programmer not only in execution of the play but also in understanding of chess, since the programmer is not only not as good at applying the learning methods, but hasn't looked at all of those games.
They have no way of determining whether They should trust the application or environment. The TPCA chip only enables the owner, who has examined the system and then sealed the key, to verify that the system remains the same.
That is to say, the DRM application can't tell whether it's running in a VM or not; it can only tell that it is running in the same system that it was installed in, which may not be trusted by Them, although it is trusted by the owner.
Now, once the user has installed some software and sealed a key, the content provider can then send them a file which may only be read by that software on that system. But that system (or that software) is chosen by the owner of the computer, and could expose the file to other applications and so forth. If the owner has chosen a system which will not permit other access to the decrypted file, DRM will work, but the owner need not do so, and the provider cannot determine whether the owner did, since there is no root of the provider's trust in the system.
(They would have a root of trust, and be able to do DRM, if they knew the public key for a private key sealed under a system they trust, e.g., at the factory; but that's rather complicated and unlikely)
Of course, the Microsoft plan has a number of additional features which would actually prevent this. But the Microsoft plan requires addition hardware, and may not even support the TPCA chip (since they want to use their version with the other features).
If you want to deny having signed something, you should not, in fact, sign it. A properly-designed signature system should prevent people from denying they signed things they actually signed. Alternatively, you could sign it with some key you can publish, if you want to simultaneously leak the key for deniablity (although there's not much point in anyone accepting your signature in that case).
Each of your computer keys is restricted to that computer; what you want is a shared mail key. You then distribute it to the different computers by encrypting it for each computer and sending it there. Security is maintained because you never store or transfer it entirely unencrypted, and you store it encrypted only for machines you control.
Either that, or you set up your home computer to decrypt messages and encrypt them for your work machine to read them at work.
Each private key proves something; private keys in TPCA chips prove that the machine is thewhat you expect.
But it doesn't facilitate DRM at all; the private key never leaves the chip, and it isn't set until the user sets it. This makes it useless to anyone *except* the user; the MPAA doesn't have the key or even the chip. The user, at least, has the chip.
Public key cryptography works best if the user can apply the key, but cannot leak the key no matter what.
It would be rather different if the private key on the device was known to some content provider, but this setup couldn't be used for DRM even if you tried to. The closest thing would be a content provider giving you a file that only you could read; but you can still do whatever you want with it once you read it.
'cam', being a local variable on the stack, isn't visible to any other thread. It's theoretically possible that cam->ops might change, although I'd guess that nothing would modify such a field.
Actually, it looks to be more like an incomplete cleanup of worse code; the original could have failed to copy the value into a local and needed the second check. But then the lock acquisition could break, and the second check fails to drop the lock. So somebody fixes it by replacing the heap copy with a stack copy, and forgets to remove the second check.
Alternatively, it could have been written by a programmer who's taken Parallel programming 101 but doesn't understand the thread model used in the kernel...
The problem is that they're currently out of favor; banding together just makes them an easier target. When a substantial portion of consumers think "RIAA members use my money to prevent me from listening to music. My interests would be served by not paying them anything, and there's nothing forcing me to. But I should support the independant labels", it becomes bad for business to be a part of the RIAA or anything that looks like it.
Furthermore, the record companies are relying less on RIAA legal enforcement (which takes so long that there are two generations of alternatives before the target is shut down) and more on technological measures bought from third parties. They don't have to worry about copyrights expiring as long as the MPAA and Disney are around. There's therefore nobody they can effectively sue, nothing they need to lobby for themselves, and having an organization makes them more obviously offensive.
Furthermore, you can just stick on your site an explanation of why you don't have a Verisign certificate (which would prove that you're trusted by a large company who's got no reason to trust you and has been indicted for fraud anyway). Tell the users they have to determine for themselves whether the site is trustworthy, and a certificate is worthless unless the site has used it to establish a good reputation. Mention that they have to particularly watch our for sites with CA-signed certificates, because their browser won't tell them that the certificate is new.
Actually, I think a lot of people care about the difference between arcade and NES; the NES was out at a time when there was a big difference in favor of the arcade, and most NES games based on arcade games are pale imitations of the originals, even when they aren't totally different things.
Purify and valgrind (an open-source memory debugger) are debuggers; I just wish that valgrind had the features of ddd and would show you the contents of memory (or had gdb-like features, so ddd could connect to it). In particular, it would be really helpful for finding memory leaks where you're still holding references but will never drop them (a problem that occurs even in garbage-collected languages like Java).
But it's really great to be able to debug UMRs, FMRs, and FMWs, which generally cause rare unpredictable behaviour or crashes at a random location later in the program (usually in malloc). I just wish there were also checks for "this pointer, which started out pointing to this chunk of memory, now points to a location in a different chunk of memory due to arithmatic not involving the two addresses", which would catch buffer overflows. I recently fixed about a dozen memory leaks and UMRs in a few evenings in a large program with a straightforward application of valgrind.
I also think there's a lot of progress in static debuggers, which are more similar to the pen and paper method, but without the programmer's possibly incorrect expectations. Of course, the program (the Stanford checker) hasn't yet been released to the public, but they say they will eventually.
If the only people you meet are outsiders like yourself, it will still have the same abandoned feeling; but I think it would work best if small groups of people would enter each world together, and then they wouldn't meet anyone else who didn't go in with them. Considering how much time people spent playing Myst with other people looking over their shoulders and suggesting things, having a group of players going through the game together actually makes a lot of sense.
Hmm... if it had support for gestures, you could actually respond to "asl??" in ASL...
For that matter, wouldn't most people with jobs that involve calling people prefer to only call people who don't hate getting called? Telemarketting involves calling a few people who like to buy things over the phone, a few people who could be convinced to buy things if pressured, and a ton of people who get upset if they get called. The first group won't get on a DNC list, the second mostly won't bother, and the third generally will. Net result: fewer sales, but higher yield. And it's more pleasent for the people who're making the calls. I don't think telemarketers have to worry about losing their jobs, either, since there are a whole lot of phone numbers to call.
Right, it would only work for one packet each way, which would be fine for images, HEAD requests, and so forth. A lot of what HTTP does doesn't rely of streams. If you need to know whether your packet arrived (e.g., a POST), you must use TCP. If a response doesn't arrive, you should use TCP (UDP might not be supported by the server, or the network is dropping packets).
So HTTP/UDP would be useful for cases where order doesn't matter, duplicates don't matter, and retransmission is simple (I still don't have anything for this URL, better ask again, maybe trying TCP).
Leave the heavy lifting to TCP, but if there's anything that's not heavy lifting, it's most of HTTP.
The developer has generally not been expecting any money out of it. Most developers writing OSS do so because the existance of the resulting software is worth the effort, because the effort is fun or good practice or because the resulting software is useful to the developer. Other developers are paid to write OSS, because the existance of the resulting software is worth their salary to somebody.
In fact, most OSS developers avoid getting paid for it. Getting paid for it means you have to deal with credit cards, shipping money, cashing checks, and so forth. Personally, I get direct deposit from work and deal with cash that people hand to me; otherwise, it's more trouble than it's really worth. If you're getting money, you need the infrastructure to handle it, and that infrastructure costs money; if your software doesn't get popular, you'll actually *lose* money, and trying to make your software popular increases the potential costs.
Which makes you wonder: if you can do well enough without guaranteed delivery that a broken TCP is faster under common loads than a working one, why not use UDP? If UDP is good for anything, it's good for stateless, repeatable, brief request/response pairs, which is most of the traffic on the web.
Ideally, web servers would support using UDP and clients would attempt UDP and fall back to TCP if UDP seems to be unreliable (it's easy to tell if you're getting the whole thing, since you know the length of the page from the headers). The reason not to use UDP is that you can't be sure what happened if you don't get a complete response, but it doesn't matter for GET/HEAD requests (POST you do care, otherwise you might submit a form twice): if you don't get a complete response, you want to try again, and a new request isn't different from resending the dropped packet.
That's how X currently supports anti-aliasing, transparency, etc. But Xext doesn't let you modify the core protocol functions; it won't let you put 8 bits of transparency in an XColor and then set it as a window background, or add fields to GCs. Instead, the extension has to use its own versions of things, which ends up being pretty awkward.
The problem is that the fixes for them are extensions, which means that the core protocol ends up essentially dead, and everybody uses something different. Personally, I think that once these issues have been dealt with, it's time for X12: ditch the stuff that's no longer useful (all the color allocation stuff...), replace the core protocol functions with XRender-based ones, drop the old font stuff, bump the version number, and support X11 clients in compatibility mode. The people who started using the extensions can simplify the code, and the people who didn't can get better results in a straightforward fashion.
Different people have different learning styles; personally I think I do best reading the book and sleeping during classes (that way I get handouts and announcements, and wake up and see the board on occasion). Furthermore, there are often a number of people taking classes because there aren't placement tests; they don't have to absorb anything at all, they just have to demonstrate that they already knew the material when the test happens.
The thing that really makes college worthwhile is the facilities, the other students, and the course staff outside of lecture; a dry lecture (or even an interesting one that just isn't very interactive) might as well be a video.
Slashdot Mirror
Well, it's fundamental, but it's not unavoidable; what they've done is avoid it by not learning too much. The trick is that you can make a copy of a particle without finding out exactly the state of the old particle, because you don't know the state you copied either (oddly enough, this means that you can't then measure both and come up with better information).
This is, in fact, an example of science following what the laws of nature actually say, but finding a way that what they want to do doesn't actually violate the laws, despite the fact that a less clear understanding of nature would make it seem impossible.
The common wisdom, as I know it, is that Betamax was technologically superior, but VHS was in the right place at the right time, and ended up with the whole market. Considering just the item itself, Beta is better, but the whims of the market (the whole product, although what is important is only obvious in hindsight) are more important than the finer points of technology.
Of course, the wisdom imagines a semi-mythical time when neither technology was developed into a product; people don't wish that 1-hour tapes had won the market, they wish that Beta encoding had won, either by being marketted more effectively, or even simply by being used in VHS recorders. The real question is not why consumers buy technologically inferior but more suitable products, it's why more suitable products are made with inferior technology; the answer is that the wrong company owns the wrong technology.
It is in your best interest if it means more people will accept your digital signature instead of a forgable handwritten one, or if you're ever accepting signatures. But there's no way that someone could actually tell whether you're using a Fritz chip (since these don't have any keys set at the factory) unless they can inspect the computer; you could, in fact, simulate the whole thing in software with unprotected keys.
Intuitive deisgn of anything that people will need to change in the future is more important than anything else, because anything you do efficiently but confusingly now will get changed in the future to be broken. If a future programmer can understand your code easily, it can then be optimized if it turns out to be too slow. And good design often turned out to be both efficient and intuitive; it tends to be free of the junk that both makes things confusing and slow.
For that matter, how fast do you want the testing infrastructure to run?
I recently set up windows under win4lin, and it was not obvious in several cases whether something was the same drive or not. Admittedly, some of this was that the "local hard drive" contained NFS stuff handled by the underlying linux, but half of the time I couldn't tell what drive (as far as Windows was concerned) I was looking at.
This generation of chess programs are actually basing thier play not exclusively on the code, but also on a database of games played by various people, so it's not exclusively the programmer, but also involves what the program can learn from historical play (In fact, current programs can attempt to play like specific human players).
So the programmer is actually writing a program to learn how to play chess well from looking at good play, so the program can surpass the programmer not only in execution of the play but also in understanding of chess, since the programmer is not only not as good at applying the learning methods, but hasn't looked at all of those games.
They have no way of determining whether They should trust the application or environment. The TPCA chip only enables the owner, who has examined the system and then sealed the key, to verify that the system remains the same.
That is to say, the DRM application can't tell whether it's running in a VM or not; it can only tell that it is running in the same system that it was installed in, which may not be trusted by Them, although it is trusted by the owner.
Now, once the user has installed some software and sealed a key, the content provider can then send them a file which may only be read by that software on that system. But that system (or that software) is chosen by the owner of the computer, and could expose the file to other applications and so forth. If the owner has chosen a system which will not permit other access to the decrypted file, DRM will work, but the owner need not do so, and the provider cannot determine whether the owner did, since there is no root of the provider's trust in the system.
(They would have a root of trust, and be able to do DRM, if they knew the public key for a private key sealed under a system they trust, e.g., at the factory; but that's rather complicated and unlikely)
Of course, the Microsoft plan has a number of additional features which would actually prevent this. But the Microsoft plan requires addition hardware, and may not even support the TPCA chip (since they want to use their version with the other features).
If you want to deny having signed something, you should not, in fact, sign it. A properly-designed signature system should prevent people from denying they signed things they actually signed. Alternatively, you could sign it with some key you can publish, if you want to simultaneously leak the key for deniablity (although there's not much point in anyone accepting your signature in that case).
Each of your computer keys is restricted to that computer; what you want is a shared mail key. You then distribute it to the different computers by encrypting it for each computer and sending it there. Security is maintained because you never store or transfer it entirely unencrypted, and you store it encrypted only for machines you control.
Either that, or you set up your home computer to decrypt messages and encrypt them for your work machine to read them at work.
Each private key proves something; private keys in TPCA chips prove that the machine is thewhat you expect.
Really, if they're going to release a 322-page specification with that requirement, they're in for trouble.
But it doesn't facilitate DRM at all; the private key never leaves the chip, and it isn't set until the user sets it. This makes it useless to anyone *except* the user; the MPAA doesn't have the key or even the chip. The user, at least, has the chip.
Public key cryptography works best if the user can apply the key, but cannot leak the key no matter what.
It would be rather different if the private key on the device was known to some content provider, but this setup couldn't be used for DRM even if you tried to. The closest thing would be a content provider giving you a file that only you could read; but you can still do whatever you want with it once you read it.
'cam', being a local variable on the stack, isn't visible to any other thread. It's theoretically possible that cam->ops might change, although I'd guess that nothing would modify such a field.
Actually, it looks to be more like an incomplete cleanup of worse code; the original could have failed to copy the value into a local and needed the second check. But then the lock acquisition could break, and the second check fails to drop the lock. So somebody fixes it by replacing the heap copy with a stack copy, and forgets to remove the second check.
Alternatively, it could have been written by a programmer who's taken Parallel programming 101 but doesn't understand the thread model used in the kernel...
The problem is that they're currently out of favor; banding together just makes them an easier target. When a substantial portion of consumers think "RIAA members use my money to prevent me from listening to music. My interests would be served by not paying them anything, and there's nothing forcing me to. But I should support the independant labels", it becomes bad for business to be a part of the RIAA or anything that looks like it.
Furthermore, the record companies are relying less on RIAA legal enforcement (which takes so long that there are two generations of alternatives before the target is shut down) and more on technological measures bought from third parties. They don't have to worry about copyrights expiring as long as the MPAA and Disney are around. There's therefore nobody they can effectively sue, nothing they need to lobby for themselves, and having an organization makes them more obviously offensive.
Furthermore, you can just stick on your site an explanation of why you don't have a Verisign certificate (which would prove that you're trusted by a large company who's got no reason to trust you and has been indicted for fraud anyway). Tell the users they have to determine for themselves whether the site is trustworthy, and a certificate is worthless unless the site has used it to establish a good reputation. Mention that they have to particularly watch our for sites with CA-signed certificates, because their browser won't tell them that the certificate is new.
Actually, I think a lot of people care about the difference between arcade and NES; the NES was out at a time when there was a big difference in favor of the arcade, and most NES games based on arcade games are pale imitations of the originals, even when they aren't totally different things.
Purify and valgrind (an open-source memory debugger) are debuggers; I just wish that valgrind had the features of ddd and would show you the contents of memory (or had gdb-like features, so ddd could connect to it). In particular, it would be really helpful for finding memory leaks where you're still holding references but will never drop them (a problem that occurs even in garbage-collected languages like Java).
But it's really great to be able to debug UMRs, FMRs, and FMWs, which generally cause rare unpredictable behaviour or crashes at a random location later in the program (usually in malloc). I just wish there were also checks for "this pointer, which started out pointing to this chunk of memory, now points to a location in a different chunk of memory due to arithmatic not involving the two addresses", which would catch buffer overflows. I recently fixed about a dozen memory leaks and UMRs in a few evenings in a large program with a straightforward application of valgrind.
I also think there's a lot of progress in static debuggers, which are more similar to the pen and paper method, but without the programmer's possibly incorrect expectations. Of course, the program (the Stanford checker) hasn't yet been released to the public, but they say they will eventually.
If the only people you meet are outsiders like yourself, it will still have the same abandoned feeling; but I think it would work best if small groups of people would enter each world together, and then they wouldn't meet anyone else who didn't go in with them. Considering how much time people spent playing Myst with other people looking over their shoulders and suggesting things, having a group of players going through the game together actually makes a lot of sense.
Hmm... if it had support for gestures, you could actually respond to "asl??" in ASL...
For that matter, wouldn't most people with jobs that involve calling people prefer to only call people who don't hate getting called? Telemarketting involves calling a few people who like to buy things over the phone, a few people who could be convinced to buy things if pressured, and a ton of people who get upset if they get called. The first group won't get on a DNC list, the second mostly won't bother, and the third generally will. Net result: fewer sales, but higher yield. And it's more pleasent for the people who're making the calls. I don't think telemarketers have to worry about losing their jobs, either, since there are a whole lot of phone numbers to call.
Right, it would only work for one packet each way, which would be fine for images, HEAD requests, and so forth. A lot of what HTTP does doesn't rely of streams. If you need to know whether your packet arrived (e.g., a POST), you must use TCP. If a response doesn't arrive, you should use TCP (UDP might not be supported by the server, or the network is dropping packets).
So HTTP/UDP would be useful for cases where order doesn't matter, duplicates don't matter, and retransmission is simple (I still don't have anything for this URL, better ask again, maybe trying TCP).
Leave the heavy lifting to TCP, but if there's anything that's not heavy lifting, it's most of HTTP.
The developer has generally not been expecting any money out of it. Most developers writing OSS do so because the existance of the resulting software is worth the effort, because the effort is fun or good practice or because the resulting software is useful to the developer. Other developers are paid to write OSS, because the existance of the resulting software is worth their salary to somebody.
In fact, most OSS developers avoid getting paid for it. Getting paid for it means you have to deal with credit cards, shipping money, cashing checks, and so forth. Personally, I get direct deposit from work and deal with cash that people hand to me; otherwise, it's more trouble than it's really worth. If you're getting money, you need the infrastructure to handle it, and that infrastructure costs money; if your software doesn't get popular, you'll actually *lose* money, and trying to make your software popular increases the potential costs.
Which makes you wonder: if you can do well enough without guaranteed delivery that a broken TCP is faster under common loads than a working one, why not use UDP? If UDP is good for anything, it's good for stateless, repeatable, brief request/response pairs, which is most of the traffic on the web.
Ideally, web servers would support using UDP and clients would attempt UDP and fall back to TCP if UDP seems to be unreliable (it's easy to tell if you're getting the whole thing, since you know the length of the page from the headers). The reason not to use UDP is that you can't be sure what happened if you don't get a complete response, but it doesn't matter for GET/HEAD requests (POST you do care, otherwise you might submit a form twice): if you don't get a complete response, you want to try again, and a new request isn't different from resending the dropped packet.
My high school computer teacher found once that he's messed up the capitalization of LoopsEx, which he was showing to the class.
That's how X currently supports anti-aliasing, transparency, etc. But Xext doesn't let you modify the core protocol functions; it won't let you put 8 bits of transparency in an XColor and then set it as a window background, or add fields to GCs. Instead, the extension has to use its own versions of things, which ends up being pretty awkward.
The problem is that the fixes for them are extensions, which means that the core protocol ends up essentially dead, and everybody uses something different. Personally, I think that once these issues have been dealt with, it's time for X12: ditch the stuff that's no longer useful (all the color allocation stuff...), replace the core protocol functions with XRender-based ones, drop the old font stuff, bump the version number, and support X11 clients in compatibility mode. The people who started using the extensions can simplify the code, and the people who didn't can get better results in a straightforward fashion.
Different people have different learning styles; personally I think I do best reading the book and sleeping during classes (that way I get handouts and announcements, and wake up and see the board on occasion). Furthermore, there are often a number of people taking classes because there aren't placement tests; they don't have to absorb anything at all, they just have to demonstrate that they already knew the material when the test happens.
The thing that really makes college worthwhile is the facilities, the other students, and the course staff outside of lecture; a dry lecture (or even an interesting one that just isn't very interactive) might as well be a video.