You're still not making sense. You're saying it's more secure to have one copy of the decryption key (on each player), and one copy of the encryption key (at the factory) so that it's harder to get ahold of the decryption keys? But if someone has access to the encryption keys at the factory, they almost certainly have access to the unencrypted movies, so what's the deal?
Ok, in the public-key case why would the encryption keys (the ones used to create the DVDs) become known? It's much more likely that the decryption keys (the ones housed on all the DVD players) would become known. Face it, your argument doesn't make any sense.
Why would a public key encryption algorithm be easier in this case? It would seem only harder, by requiring more complicated/faster decrypt hardware And it wouldn't make any difference in security (other than the key length related factors), since they're trying to restrict playback (decryption).
Man, that sucks. I'm in computer science, so the stuff I ship is all mass-produced and replaceable, although time is still an issue. But for life sciences and other areas where your samples are pretty much irreplacable, it might be worth looking into setting up a trusted network of peers who will courier eachothers' parcels when traveling to conferences, etc.
That's not entirely true. There are visualization supercomputers dedicated to displaying the immense data that results from detailed physical system simulations.
Yeah, the thing I really hate about the cameras is that THEY SEE YOU (i.e. the operators see you), but YOU DON'T SEE THEM. It feels totally unfair, like you're placed in a police examing room while anyone who pleases can watch you through a two-way mirror without being seen -- just for walking down the street.
See equation 18 at MathWorld for an expression of the analytic continuation to the complex plane. Sure, it's expressed as an infinite series, but who says there has to be a simple closed-form definition (I don't know if there is one).
People like to liken Apple products to BMW or Mercedes, but maybe it's more like Ferrari. Expensive, looking cool, but requires a lot of maintenance...
...whereas BMW and Mercedes are just expensive and require a lot of maintenance. I tell you what. Just get a 10 year old Toyota and forget about it.
But AMD's 286, 386, and possibly 486 were based on designs licensed from Intel. I believe at least some versions of the 286 were microarchitecturally identical (AMD as a second source of parts for Intel).
It looks to me that the real issue here is that the class-level interface in C++ is too weak. If you could specify object interaction policies (often called "synchronizers"), you could formally encode the constraint that the value returned by back() must not be used after a push_back() (or pop_back(), etc.). After all, this kind of thing is already specified informally in the documentation.
I'm guessing the way it would have to work on traditional x86 is to use separate code and data segments, and never map a page as both writeable (in the data segment) and readable (thus executable) in the code segment. Since traditionally the current OSs do not distinguish between virtual addresses in the code and data spaces (i.e. ds:addr and cs:addr map the same page), the only way to do this would be to have two totally separate regions of virtual address space for code and data, with physical pages that should be both readable and executable mapped to both. This would require re-architecting the address space layout used by current kernels.
To say that SMT is "IBM's version of HyperThreading" is backwards-speak. Simultaneous MultiThreading (SMT) is actually a generic term for any technique which multiplexes threads on a single CPU core by allowing any thread to use any available resource during any clock cycle. HyperThreading (nee Jackson Technology) is Intel's name for their implementation of SMT -- see http://www.intel.com/technology/hyperthread/.
From my description of SMT, you might conclude that it is able to make the fullest use of CPU core resources of any multithreading approach. Then why are some benchmarks slower with HyperThreading enabled? I have three ideas. First of all, since OSes tend to treat a single CPU with hyperthreading like a dual-CPU system, they may schedule lower-priority processes on one of the threads, resulting in less total CPU time available for the main benchmark process. Secondly, there is some overhead to multiplexing all of these resources amongst two threads, so perhaps Intel had to "tone down" superscalar operation or memory queues to meet clock timing when in HyperThreading mode (I know this is vague). Thirdly, perhaps in ostensibly non-HyperThreaded mode the second thread is actually used for speculative execution, and hence slightly boosts the performance of a benchmark.
Wow, so the best bang for your video editing buck causes GUI crashes, and won't export anything to analog tape?
No, not "and," but "or". So you just switch between the two drivers as necessary (pretty insignificant compared to the time to export to tape -- you don't need to reboot or anything like that).
Thanks for reminding me once again why I use OS X (read: NOT LINUX).
Remember that not everyone is rich enough to be able to afford a Macintosh. The AMD/Linux system is especially great for kids who are just learning about this stuff.
As for the "huge library", that's one of Java's strengths! The fact that the core distribution provides so much functionality makes writing and deploying code much easier. No need to choose between writing your own support libraries, or using someone else's and hoping that the target machines have it installed
That would be true if it weren't for the facts that (1) Java's standard libraries include all kinds of special-purpose classes/packages but lack very basic things like a Priority Queue (correct me if I'm wrong -- I couldn't find one), and (2) there are a lot of methods which handle the same kind of data but have incompatible signatures (e.g. accepting int vs. Integer), which greatly reduces synergy in the system (compare this to something like Mathematica where a lot of effort is spent to make functions interoperable via a common notion of expression trees).
Hmm, this should be possible using XChangeWindowAttributes and possibly some grabs to listen for events on windows created by other applications. How would another application detect creation of new windows (other than the window manager for toplevels)? I think that's just part of the issue of detecting and logging "events" created in the X server by the clients, e.g. a request to draw a line doesn't create an event in a client, but you could say it does in the server. An X11 proxy might be possible, but that could make the GUI less reliable and slower, and overall seems like a hack.
"Multiple clients can select input on the same window. Their event masks are maintained separately. When an event is generated, it is reported to all interested clients. However, only one client at a time can select for SubstructureRedirectMask, ResizeRedirectMask, and ButtonPressMask. If a client attempts to select any of these event masks and some other client has already selected one, a BadAccess error results. There is only one do-not-propagate-mask for a window, not one per client."
Slashdot Mirror
You're still not making sense. You're saying it's more secure to have one copy of the decryption key (on each player), and one copy of the encryption key (at the factory) so that it's harder to get ahold of the decryption keys? But if someone has access to the encryption keys at the factory, they almost certainly have access to the unencrypted movies, so what's the deal?
Ok, in the public-key case why would the encryption keys (the ones used to create the DVDs) become known? It's much more likely that the decryption keys (the ones housed on all the DVD players) would become known. Face it, your argument doesn't make any sense.
Why would a public key encryption algorithm be easier in this case? It would seem only harder, by requiring more complicated/faster decrypt hardware And it wouldn't make any difference in security (other than the key length related factors), since they're trying to restrict playback (decryption).
Man, that sucks. I'm in computer science, so the stuff I ship is all mass-produced and replaceable, although time is still an issue. But for life sciences and other areas where your samples are pretty much irreplacable, it might be worth looking into setting up a trusted network of peers who will courier eachothers' parcels when traveling to conferences, etc.
Although distributed in a limited sense, it's better defined as a fault-tolerant cluster file system.
AFS is for distributed computing, GFS is for fault-tolerant cluster computing, similar to SGI's CXFS. Calling it a "global file system" is a misnomer.
Why can't the zombie program just connect to the website and enable port 25? Many people probably have their browsers remembering their passwords.
That's not entirely true. There are visualization supercomputers dedicated to displaying the immense data that results from detailed physical system simulations.
Yeah, the thing I really hate about the cameras is that THEY SEE YOU (i.e. the operators see you), but YOU DON'T SEE THEM. It feels totally unfair, like you're placed in a police examing room while anyone who pleases can watch you through a two-way mirror without being seen -- just for walking down the street.
See equation 18 at MathWorld for an expression of the analytic continuation to the complex plane. Sure, it's expressed as an infinite series, but who says there has to be a simple closed-form definition (I don't know if there is one).
Women = Good
Counterstrike = Bad
I don't see your point. Those equations look fine, although personally I don't do either of the left hand sides.
right hand or left?
But AMD's 286, 386, and possibly 486 were based on designs licensed from Intel. I believe at least some versions of the 286 were microarchitecturally identical (AMD as a second source of parts for Intel).
It looks to me that the real issue here is that the class-level interface in C++ is too weak. If you could specify object interaction policies (often called "synchronizers"), you could formally encode the constraint that the value returned by back() must not be used after a push_back() (or pop_back(), etc.). After all, this kind of thing is already specified informally in the documentation.
I'm guessing the way it would have to work on traditional x86 is to use separate code and data segments, and never map a page as both writeable (in the data segment) and readable (thus executable) in the code segment. Since traditionally the current OSs do not distinguish between virtual addresses in the code and data spaces (i.e. ds:addr and cs:addr map the same page), the only way to do this would be to have two totally separate regions of virtual address space for code and data, with physical pages that should be both readable and executable mapped to both. This would require re-architecting the address space layout used by current kernels.
Ah, that's it, cache sharing. There you go, that nicely fleshes out problem #2.
From my description of SMT, you might conclude that it is able to make the fullest use of CPU core resources of any multithreading approach. Then why are some benchmarks slower with HyperThreading enabled? I have three ideas. First of all, since OSes tend to treat a single CPU with hyperthreading like a dual-CPU system, they may schedule lower-priority processes on one of the threads, resulting in less total CPU time available for the main benchmark process. Secondly, there is some overhead to multiplexing all of these resources amongst two threads, so perhaps Intel had to "tone down" superscalar operation or memory queues to meet clock timing when in HyperThreading mode (I know this is vague). Thirdly, perhaps in ostensibly non-HyperThreaded mode the second thread is actually used for speculative execution, and hence slightly boosts the performance of a benchmark.
Wow, so the best bang for your video editing buck causes GUI crashes, and won't export anything to analog tape?
No, not "and," but "or". So you just switch between the two drivers as necessary (pretty insignificant compared to the time to export to tape -- you don't need to reboot or anything like that).
Thanks for reminding me once again why I use OS X (read: NOT LINUX).
Remember that not everyone is rich enough to be able to afford a Macintosh. The AMD/Linux system is especially great for kids who are just learning about this stuff.
Price isn't the argument. Vendor restrictions on what you can do with the software is.
That would be true if it weren't for the facts that (1) Java's standard libraries include all kinds of special-purpose classes/packages but lack very basic things like a Priority Queue (correct me if I'm wrong -- I couldn't find one), and (2) there are a lot of methods which handle the same kind of data but have incompatible signatures (e.g. accepting int vs. Integer), which greatly reduces synergy in the system (compare this to something like Mathematica where a lot of effort is spent to make functions interoperable via a common notion of expression trees).
Ok, I guess you're right.
Damn you, Roydd. Should've known you were signed in on my computer.
Never mind. XTRAP --> XTEST, Android (as mentioned elsewhere).
"Multiple clients can select input on the same window. Their event masks are maintained separately. When an event is generated, it is reported to all interested clients. However, only one client at a time can select for SubstructureRedirectMask, ResizeRedirectMask, and ButtonPressMask. If a client attempts to select any of these event masks and some other client has already selected one, a BadAccess error results. There is only one do-not-propagate-mask for a window, not one per client."