Re:What is an example that can't run in parallel?
on
Forget Moore's Law?
·
· Score: 1
But you will not get MD5 of the original.
Very true. But that may not matter. It may not be necessary to MD5 of 1 billion bytes. In fact, this is a consideration for future system designs. When designing a system, such as a digital signature, make sure the design is the MD5 of the MD5's of 1K blocks. (for instnace)
Re:What is an example that can't run in parallel?
on
Forget Moore's Law?
·
· Score: 1
Anything running simple operations on large datasets (where the time to send data to parallel systems would be greater than the time to do the calculations) e.g. resizing an image
That all depends on the size of the image. Actually, a function of total processing time to communications time. If I'm resizing a 1 billion x 1 billion pixel image, doing it in parallel might be faster by farming it out into smaller (overlapping) chunks.
Another (marginal) benefit is that a faster processor can run non-parallel programs without reprogramming, so single workstation packages don't need to be totally re-coded.
True. Only because the predominant programming is sequential.
I think that eventually everyone will have multiple processors. It will start with two or four. Then go from there. Just like we started with 256 bytes of memory, and some people went hog wild and bought those expensive 4K boards for their Altair. When hardware routinely has multiple processors, every parallelizable problem will tend to be written to exploit the capability of the hardware. Just as now, if you write a multi threadded Java program, it is easy to exploit an SMP box. You just write with the mindset that there are "one or more threads". You first check some system toolkit to see how many processors you have, and then throw some multiple of that many threads at it. Or maybe I don't care how many processors. I just divide the work into 100x100 pixel units to be rendered, and throw them at how ever many thread consumers will take them. When most languages / libraries, make it just as trivially easy to create threds, I think we'll see a lot more of this.
So while your statement is true today, it is only true because most programs aren't parallelized. Your statement could someday actually be false.
Daydreaming.....
Now, if only Java would easily allow you to create threads that did NOT have shared memory, where the JVM could make the thread a seperate process so that Mosix could migrate it to a different box....
I really don't know about Word and Excel since I never use either of them.
But I can assure you that there are database applications that definitely use this approach quite successfully. Records are of uniform length. So are b-tree index nodes. I know the approach to be used as far back as the very earliest fileservers in microcomputers.
Your suggestion of using PKI only helps a bit. The discussions of OTPs suggests that you don't trust mathematical cyphers.
The OTP is to prevent reading of the message by Eve. And is proovably unbreakable for that purpose. PKI is to ensure authenticity of the message. Using OTP does not weaken PKI. Using PKI does not weaken OTP.
The "known plaintexts" you suggest, such as standard header stuff, like "login:", cannot be replaced without arousing suspicion.
Merely knowing that the message will contain "water purification plant" and "Munich" will not do anything. Any bits in the message could be the result of XOR'ing "Munich" with part of the one time pad.
So I don't see any weakness of a OTP with a MITM, especially if digital signatures are used. In fact, the "signature" could consist of a standard message trailer that consists of: MD5( body-of-message ) XOR more-bits-of-OTP. Now we're not even using PKI. Just more OTP. Now you can't replace "login:" with some other six characters, because the MD5 won't match.
Re:What is an example that can't run in parallel?
on
Forget Moore's Law?
·
· Score: 1
Seriously, realtime 3d graphics/games will not scale well on a cluster. This is where having a tremendously powerful processing unit (whether it be on the video card or motherboard) will be better than many less powerful processors.
You make a good point. Given current technology and bandwidth. But still....
Forget about "real-time" for a moment. It is known that rendering farms are faster than sequential rendering. Each node can either work on a different complete frame, or multiple nodes work on portions of one frame. Let's examine the latter case.
Now if multiple processing elements ganging up onto one frame is faster, then why? Because the compute time for a frame is significantly greater than the communications time between nodes to set up and distribute the computation.
Now let's move back to real time.
It would seem that within one single video card, of a hypothetical design, a super dooper customized set of chips with high speed interconnect busses could provide a parallelized advantage over a single processor.
If you accept this, then it would seem, in principal, that with high enough bandwidth and low enough latencies, a cluster could provide an advantage in real-time. In this case, we're talking about "soft" real-time. As long as the frames come at a high enough rate, who cares. We're of course, talking hypothetical interconnect technology.
But your original point is good. Certianly with what we think of today as "networks" and "clusters", real time 3d graphics is not suitable. But I would suggest that no supercomputer is. Just dedicated hardware. Similar to another poster in this thread who mentioned MD5 as a non parallelizable, and I mentioned dedicated hardware with internal parallelization.
Yes. There are plenty of applications that exploit this capability.
A long time ago, in a galaxy far, far away, before the dark times, that is, before MS SQL Server, there were multi user applications. Multiple workstations, each locally running a copy of the application, could open the same data file on the server. Because they could, through the API, request certian byte range portions of the file be "locked" from other users who had the file open, they could effectively do sophisticated multi user operations without a database server. (Database servers were things for mainframes.)
There are still programs that can do this. For instance. Microsoft Visual FoxPro. If you use FoxPro's native database (not an ODBC to some other database), then you need nothing more than a shared folder on a fileserver that supports locking. Too bad that SMB isn't suitable. This effectively cuts out some vertical market applications written in tools such as Visual FoxPro from using a shared Samba server. "Sorry, Mr. Customer, to run this specialized package, you'll need an NT server, a Novell server or an AppleShare server."
Don't think these are merely "legacy" applications either.
How many modern software programs allow concurrent editing of a document by multiple people? (where the applications cooperate in modifications to the data structures of the document and don't clibber each other) Excel? Word?
Re:What is an example that can't run in parallel?
on
Forget Moore's Law?
·
· Score: 1
MD5 depends on (among other things) being non-parallelizable for its security
An excellent example.
Wouldn't a dedicated hardware implementation be ideal for this instead of a general purpose vector processor?
It's been awhile since I looked at the algorithm, but isn't there some internal parallelism that a dedicated chip could exploit to build a fast dedicated hardware implementation of this sequential process?
Re:What is an example that can't run in parallel?
on
Forget Moore's Law?
·
· Score: 3, Informative
the standard search algorithm for chess play is something called minimax search with alpha-beta pruning.
This algorithm is something I'm familiar with. (Not chess, but other toy games in LISP, like Tic Tac Toe, Checkers, and Reversi, all of which I've implemented using a generic minimax-alphabeta subroutine I wrote.) (All just for fun, of course.)
If you have a bunch of parallel nodes, you throw all of the leaf nodes at it in parallel. As soon as leaf board scores start comming in, you min or max them up the tree. You may be able to alpha-beta prune off entire subtrees. Yes, at higher levels, the process is still sequential. But many boards' scores at the leaf nodes need computed, and could be done in parallel. Yes, you may alpha-beta prune off a subtree that has already had some of your processors thrown at it's leaf nodes -- you abort those computations and re-assign those processors to the leaf nodes that come after the subtree that just got pruned off.
Am I missing anything important here? It seems like you could still significantly benefit from massive parallel processing. If you have enough processors, the alpha-beta pruning itself might not even be necessary. After all the alpha-beta pruning is just an optmization so that sequential processing doesn't have to examine subtrees that wouldn't end up affecting the outcome. But let's say, each board can have 10 possible moves made by each player. I want to look 4 moves ahead. This is 10,000 leaf boards to score. If I have more than 10,000 processors, why even bother to alpha-beta prune? Now, if I end up needing to examine 1 million boards (more realistic perhaps) and I can do them 10,000 at a time, I still may end up being able to take advantage of some alpha-beta pruning. And 10,000 boards examined at once, sequentially, is still faster than 1 at a time.
Vector processors wouldn't be any more helpful here (would they?) than massively parallel?
Of course, whether a mere 10,000 processors constitutes massively parallel or not is a matter of interpretation. Some people say a 4-way SMP is massively parallel. I suppose it depends on your definition of "massively".
I understand the known plaintext idea you're suggesting. I just don't see what is gained.
Yes, I know the first text is: "Welcome to SuSE Linux 8.1[LF]Login:".
Knowing this only reveals the first part of the one time pad. So what? That part is now known but is never used again.
Okay, so you have a MITM. The MITM can send a different plaintext for the part of the pad he knows. But that part of the pad is expected to be used to say "Welcome to SuSE Linux 8.1". If I don't see that first, I am suspicious.
Finally, every message might be digitally signed. Now the MITM cannot forge the signature.
So in summary: (1) the MITM can learn the OTP for a useless part of the message, and the OTP will never be used again. (2) the receipient can tell that messages are not genuine.
Is there something here I'm missing?
Re:What is an example that can't run in parallel?
on
Forget Moore's Law?
·
· Score: 1
Something that requires a previous computation can't be run in parallel. Like calculationg a fibonacci sequence
That's a good example. But it doesn't seem, to me, to be a practical example. Perhaps I just don't know of the practical uses of fibonacci numbers large enough to require supercomputer type power. But your point is good. I could parallelize the generation of large prime numbers, but not fibonacci. (What about factorials?) But besides the theoretical point, is there a practical problem?
if you are going to record the key on a cd and deliver it by hand (which you would have to do for each message, since it is a one time pad ) you might as well deliver the message your self.
Ah, but the one time pad can be delivered by courier sometime PRIOR to when you need to send a message by electronic means.
Double-oh-seven, your mission is to deliver this briefcase, handcuffed to your wrist, to our embassy in Ongabonga. They will be able to detach the briefcase once you arrive. Any attempt to open the briefcase will result in a huge, well, let's just say you wouldn't want to be there.
A deficiency of one-time-pad is a man-in-the-middle with plaintext known.
If you know the entire plaintext, which you suggest the MITM does, then what is the point? To forge a different plaintext from Alice to Bob?
Three words: Digital Signatures
Alice simply MD5 hashes her plaintext, encrypts the MD5 value using private key, and appends to message. Bob verifies that received plaintext (after decoding) when MD5 hashed, equals the public key decrypted hash Alice attached. The MITM can't forge that.
I suppose you could frequency block the 60 Hz, and let very high frequencies pass -- forming the basis for a receiver. I don't know the technique for "injecting" the high frequency onto a line with power. I suppose that if your "packet" is very brief compared to the length of a 60 Hz sine wave, during the injection of your packet you can think of the voltage on the line as pure DC that is gradually rising or falling. Block DC from flowing back into your driver circuit, and but let your high frequency AC pass through. Of course, the view that what is on the powerline is DC only is correct until the end of the current half-cycle of the 60 Hz. So you need to then disconnect your DC blocking (I think otherwise known as a capacitor in series?) but it's been too many years since I got hold of an HP25, became fascinated with software, and have since forgotten which end of a soldering iron to pick up.
What is an example that can't run in parallel?
on
Forget Moore's Law?
·
· Score: 3, Interesting
I'm not disputing that they exist. But I'm drawing a blank. Can someone please give an example of a computing task that CANNOT be subdivided into smaller tasks and run in parallel on many processing elements? The kind of task that requires an ever faster single processor.
I tend to be a believer that massively parallel machines are the (eventual) future. e.g. just as we would brag about how many K, and then eventually megabytes our memory was, or how big our hard di_k was, or how many megahertz, I think that in the future shoppers will compare: "Oh, the machine at Worst Buy has 128K processors, while the machine at Circus Shitty has only 64K processors!"
I don't know how this particular technology works. But think about how X10 works.
The power goes through a sine wave cycle 60 times each second. That means there are 120 times each second where there is a zero crossing. That is, no voltage on the wires. Just dry wires. Now widen this period of time from zero milliseconds to some positive number of milliseconds, and you now have a definite time period where the voltage on the lines is less than X. (Where X is some small desired voltage.) During this time, you can transmit a high frequency signal on these dry wires.
I know that is a vague description. It was many (like 14) years ago when I read the specs on how X10 works on the power line.
There are no doubt other techniques. So why would anyone be skeptical of the mere capability to send high bandwidth information over power lines?
i believe the policy is there b/c the stores don't want you to buy the product, install the product, and then return the opened product. they would have a very hard time selling any software at all.
They are just going to have to get used to it. I can buy a book at Borders and then return it. (Even after reading some or all of it! Horrors!)
Any other type of merchandise can usually be returned right away, with receipt. A software product should be no different. Nor a music CD.
It won't change the EULA's at all, but you'll at least be able to read it before you buy it.
So instead of foisting the responsibility to accept returns onto the retailers, the manufacturers are going to force the retailers to install microfilm readers like in the library?
Drunkenness increases the likelihood of all kinds of mistakes and misery
I agree. But a good number of the examples you cite are limited to modern times.
Certianly AIDS appears to be a modern problem. (Not that it might not have existed, but never seemed to be an epidemic.)
As for unplanned pregnancies, before about 1960'ish, and especially a couple thousand years ago, sex was viewed very differently because of the risk of pregnancy. I suspect that the stigmas attached to sex and alcohol might have actually reversed in some senses.
Yes, I agree, having drunk troops might be bad for military effectiveness.
It is certainly not only an NT teaching
I know that. My observation is that there is no universal proscription against drinking, as in one of your links. In Proverbs 31:4-7 the effect (also in one of your links) on one who sits in judgement, but also interestingly, it says in [6] to "Give strong drink to him who is ready to perish.... and [7] Let him drink and forget his poverty and remember his misery no more." (definitely suggesting drinking past the legal limit:-)
My reply was simply that I think we are way to hung up on the whole "wine" thing in this story. In fact, as I read it, every single thing that Jesus did in his ministry was to cause people to believe. The water to wine actually did this.
Whatever you, I or anyone else might think of drinking, the fact is that people have, do, and will drink. (And do all kinds of other behaviors.) It's just the human condition. An ugly one. Not the Star Trek "we can save ourselves" utopia.
I have only read bits of Matthew Henry, but but the words you quoted seem to suggest that wine is just another thing for man to enjoy. Which probably means that like anything discussed on slashdot, can be abused.
The Bible lays out in very unflattering terms the flaws of its characters. The whole point running through it, imho, is that man cannot save himself by behaving good [not getting drunk, etc.].
The whole theme is the salvation of man, not a primary focus on how to behave. But on how to believe.
The very fact that we read a story like the 'water to wine' and are hung up on the incidental details is very telling of how we think that certian behavior is what God requires rather than belief. I frequently find myself thinking that how I behave is what is most important.
Back to the subject, I personally can't imagine that getting intoxicated to the point of imparing judgement wouldn't be a common thing. Esp. at a wedding. Most people just aren't that uptight. I can't imagine that some people at the wedding, partying might not drink sufficiently that they would impair their judgement. Even acting significantly stilly or embarrasing themselves later. (Not necessarily falling down puking drunk.) Of course, this then is a matter of perspective. Perhaps this is "drinking to merriment" rather than being drunk. Of course, perhaps it might have been common at weddings for some people to be just plain drunk by the time they left. I don't really know. You might be right about "merriment" vs. "drunk". I wouldn't know where to draw the line.
We should have learned our lesson about corporate espionage the first time. But now that history has repeated itself, within only a few days, I guess we didn't learn our lesson the first time here on Slashdot.
How many times will we have to have faulty motherboards and other consumer electronic items before we learn our lessons abotu corporate espionage?
One other thing I might point out, in general. I've heard some people argue that the "wine" in new testament times was more like "grape juice". I disagree. They didn't have Welch's modern preservation techniques. When they had grape juice, you can believe that it turned into wine and that they knew the difference between "wine" and "grape juice" and could use the correct terminology. Humans didn't suddenly become "smart" or have some dramatic evolution of our brains just because we developed integrated circuit lithography.
Drinking to merriment is not drinking to intoxication.
I disagree. I suspect there wasn't a huge distinction. I'm not a student of history, so I may be all wet here. But it seems logical that when you don't have automobiles or other dangerous machinery that there might not be the same social stigma with drinking.
I know there is a new testament teaching about drunkenness.
But back to this wedding. Hey's it's a party, a wedding. Be happy. People drink. In fact, one of the points about bringing out the best wine first and the really cheap stuff later is that the guests are too drunk to notice. But the "water to wine" was the "good stuff" and raised the question of why the good stuff was being saved to last. (because they had run out of wine, and Jesus turned water to wine.)
Just my opinion, but I think the 20th century church is way too uptight.
Turning the water to wine being the first miracle, and it had a good result. The chief result: his disciples put their faith in him. (At end of the story.) Everyone gets so hung up about the fact that alcohol was involved. He seemed reluctant to do it at first, but his mother said "do whatever he tells you", sort of persuading him, and he did it.
Slashdot Mirror
But you will not get MD5 of the original.
Very true. But that may not matter. It may not be necessary to MD5 of 1 billion bytes. In fact, this is a consideration for future system designs. When designing a system, such as a digital signature, make sure the design is the MD5 of the MD5's of 1K blocks. (for instnace)
Insightful +1
Anything running simple operations on large datasets (where the time to send data to parallel systems would be greater than the time to do the calculations) e.g. resizing an image
That all depends on the size of the image. Actually, a function of total processing time to communications time. If I'm resizing a 1 billion x 1 billion pixel image, doing it in parallel might be faster by farming it out into smaller (overlapping) chunks.
Another (marginal) benefit is that a faster processor can run non-parallel programs without reprogramming, so single workstation packages don't need to be totally re-coded.
True. Only because the predominant programming is sequential.
I think that eventually everyone will have multiple processors. It will start with two or four. Then go from there. Just like we started with 256 bytes of memory, and some people went hog wild and bought those expensive 4K boards for their Altair. When hardware routinely has multiple processors, every parallelizable problem will tend to be written to exploit the capability of the hardware. Just as now, if you write a multi threadded Java program, it is easy to exploit an SMP box. You just write with the mindset that there are "one or more threads". You first check some system toolkit to see how many processors you have, and then throw some multiple of that many threads at it. Or maybe I don't care how many processors. I just divide the work into 100x100 pixel units to be rendered, and throw them at how ever many thread consumers will take them. When most languages / libraries, make it just as trivially easy to create threds, I think we'll see a lot more of this.
So while your statement is true today, it is only true because most programs aren't parallelized. Your statement could someday actually be false.
Daydreaming.....
Now, if only Java would easily allow you to create threads that did NOT have shared memory, where the JVM could make the thread a seperate process so that Mosix could migrate it to a different box....
I really don't know about Word and Excel since I never use either of them.
But I can assure you that there are database applications that definitely use this approach quite successfully. Records are of uniform length. So are b-tree index nodes. I know the approach to be used as far back as the very earliest fileservers in microcomputers.
Your suggestion of using PKI only helps a bit. The discussions of OTPs suggests that you don't trust mathematical cyphers.
The OTP is to prevent reading of the message by Eve. And is proovably unbreakable for that purpose. PKI is to ensure authenticity of the message. Using OTP does not weaken PKI. Using PKI does not weaken OTP.
The "known plaintexts" you suggest, such as standard header stuff, like "login:", cannot be replaced without arousing suspicion.
Merely knowing that the message will contain "water purification plant" and "Munich" will not do anything. Any bits in the message could be the result of XOR'ing "Munich" with part of the one time pad.
So I don't see any weakness of a OTP with a MITM, especially if digital signatures are used. In fact, the "signature" could consist of a standard message trailer that consists of: MD5( body-of-message ) XOR more-bits-of-OTP. Now we're not even using PKI. Just more OTP. Now you can't replace "login:" with some other six characters, because the MD5 won't match.
Seriously, realtime 3d graphics/games will not scale well on a cluster. This is where having a tremendously powerful processing unit (whether it be on the video card or motherboard) will be better than many less powerful processors.
You make a good point. Given current technology and bandwidth. But still....
Forget about "real-time" for a moment. It is known that rendering farms are faster than sequential rendering. Each node can either work on a different complete frame, or multiple nodes work on portions of one frame. Let's examine the latter case.
Now if multiple processing elements ganging up onto one frame is faster, then why? Because the compute time for a frame is significantly greater than the communications time between nodes to set up and distribute the computation.
Now let's move back to real time.
It would seem that within one single video card, of a hypothetical design, a super dooper customized set of chips with high speed interconnect busses could provide a parallelized advantage over a single processor.
If you accept this, then it would seem, in principal, that with high enough bandwidth and low enough latencies, a cluster could provide an advantage in real-time. In this case, we're talking about "soft" real-time. As long as the frames come at a high enough rate, who cares. We're of course, talking hypothetical interconnect technology.
But your original point is good. Certianly with what we think of today as "networks" and "clusters", real time 3d graphics is not suitable. But I would suggest that no supercomputer is. Just dedicated hardware. Similar to another poster in this thread who mentioned MD5 as a non parallelizable, and I mentioned dedicated hardware with internal parallelization.
Is File Locking critical?
Yes. There are plenty of applications that exploit this capability.
A long time ago, in a galaxy far, far away, before the dark times, that is, before MS SQL Server, there were multi user applications. Multiple workstations, each locally running a copy of the application, could open the same data file on the server. Because they could, through the API, request certian byte range portions of the file be "locked" from other users who had the file open, they could effectively do sophisticated multi user operations without a database server. (Database servers were things for mainframes.)
There are still programs that can do this. For instance. Microsoft Visual FoxPro. If you use FoxPro's native database (not an ODBC to some other database), then you need nothing more than a shared folder on a fileserver that supports locking. Too bad that SMB isn't suitable. This effectively cuts out some vertical market applications written in tools such as Visual FoxPro from using a shared Samba server. "Sorry, Mr. Customer, to run this specialized package, you'll need an NT server, a Novell server or an AppleShare server."
Don't think these are merely "legacy" applications either.
How many modern software programs allow concurrent editing of a document by multiple people? (where the applications cooperate in modifications to the data structures of the document and don't clibber each other) Excel? Word?
MD5 depends on (among other things) being non-parallelizable for its security
An excellent example.
Wouldn't a dedicated hardware implementation be ideal for this instead of a general purpose vector processor?
It's been awhile since I looked at the algorithm, but isn't there some internal parallelism that a dedicated chip could exploit to build a fast dedicated hardware implementation of this sequential process?
the standard search algorithm for chess play is something called minimax search with alpha-beta pruning.
This algorithm is something I'm familiar with. (Not chess, but other toy games in LISP, like Tic Tac Toe, Checkers, and Reversi, all of which I've implemented using a generic minimax-alphabeta subroutine I wrote.) (All just for fun, of course.)
If you have a bunch of parallel nodes, you throw all of the leaf nodes at it in parallel. As soon as leaf board scores start comming in, you min or max them up the tree. You may be able to alpha-beta prune off entire subtrees. Yes, at higher levels, the process is still sequential. But many boards' scores at the leaf nodes need computed, and could be done in parallel. Yes, you may alpha-beta prune off a subtree that has already had some of your processors thrown at it's leaf nodes -- you abort those computations and re-assign those processors to the leaf nodes that come after the subtree that just got pruned off.
Am I missing anything important here? It seems like you could still significantly benefit from massive parallel processing. If you have enough processors, the alpha-beta pruning itself might not even be necessary. After all the alpha-beta pruning is just an optmization so that sequential processing doesn't have to examine subtrees that wouldn't end up affecting the outcome. But let's say, each board can have 10 possible moves made by each player. I want to look 4 moves ahead. This is 10,000 leaf boards to score. If I have more than 10,000 processors, why even bother to alpha-beta prune? Now, if I end up needing to examine 1 million boards (more realistic perhaps) and I can do them 10,000 at a time, I still may end up being able to take advantage of some alpha-beta pruning. And 10,000 boards examined at once, sequentially, is still faster than 1 at a time.
Vector processors wouldn't be any more helpful here (would they?) than massively parallel?
Of course, whether a mere 10,000 processors constitutes massively parallel or not is a matter of interpretation. Some people say a 4-way SMP is massively parallel. I suppose it depends on your definition of "massively".
I understand the known plaintext idea you're suggesting. I just don't see what is gained.
Yes, I know the first text is: "Welcome to SuSE Linux 8.1[LF]Login:".
Knowing this only reveals the first part of the one time pad. So what? That part is now known but is never used again.
Okay, so you have a MITM. The MITM can send a different plaintext for the part of the pad he knows. But that part of the pad is expected to be used to say "Welcome to SuSE Linux 8.1". If I don't see that first, I am suspicious.
Finally, every message might be digitally signed. Now the MITM cannot forge the signature.
So in summary: (1) the MITM can learn the OTP for a useless part of the message, and the OTP will never be used again. (2) the receipient can tell that messages are not genuine.
Is there something here I'm missing?
Something that requires a previous computation can't be run in parallel. Like calculationg a fibonacci sequence
That's a good example. But it doesn't seem, to me, to be a practical example. Perhaps I just don't know of the practical uses of fibonacci numbers large enough to require supercomputer type power. But your point is good. I could parallelize the generation of large prime numbers, but not fibonacci. (What about factorials?) But besides the theoretical point, is there a practical problem?
What effect does the load have on the frequency? I can see an excess load causing the voltage to drop, but not the frequency?
In certian countries, isn't mere posession of a one time pad enough to get you shot?
if you are going to record the key on a cd and deliver it by hand (which you would have to do for each message, since it is a one time pad ) you might as well deliver the message your self.
Ah, but the one time pad can be delivered by courier sometime PRIOR to when you need to send a message by electronic means.
Double-oh-seven, your mission is to deliver this briefcase, handcuffed to your wrist, to our embassy in Ongabonga. They will be able to detach the briefcase once you arrive. Any attempt to open the briefcase will result in a huge, well, let's just say you wouldn't want to be there.
A deficiency of one-time-pad is a man-in-the-middle with plaintext known.
If you know the entire plaintext, which you suggest the MITM does, then what is the point? To forge a different plaintext from Alice to Bob?
Three words: Digital Signatures
Alice simply MD5 hashes her plaintext, encrypts the MD5 value using private key, and appends to message. Bob verifies that received plaintext (after decoding) when MD5 hashed, equals the public key decrypted hash Alice attached. The MITM can't forge that.
Like I said, I'm sure other techniques exist.
I suppose you could frequency block the 60 Hz, and let very high frequencies pass -- forming the basis for a receiver. I don't know the technique for "injecting" the high frequency onto a line with power. I suppose that if your "packet" is very brief compared to the length of a 60 Hz sine wave, during the injection of your packet you can think of the voltage on the line as pure DC that is gradually rising or falling. Block DC from flowing back into your driver circuit, and but let your high frequency AC pass through. Of course, the view that what is on the powerline is DC only is correct until the end of the current half-cycle of the 60 Hz. So you need to then disconnect your DC blocking (I think otherwise known as a capacitor in series?) but it's been too many years since I got hold of an HP25, became fascinated with software, and have since forgotten which end of a soldering iron to pick up.
I'm not disputing that they exist. But I'm drawing a blank. Can someone please give an example of a computing task that CANNOT be subdivided into smaller tasks and run in parallel on many processing elements? The kind of task that requires an ever faster single processor.
I tend to be a believer that massively parallel machines are the (eventual) future. e.g. just as we would brag about how many K, and then eventually megabytes our memory was, or how big our hard di_k was, or how many megahertz, I think that in the future shoppers will compare: "Oh, the machine at Worst Buy has 128K processors, while the machine at Circus Shitty has only 64K processors!"
I'd think it was a total crock
I don't know how this particular technology works. But think about how X10 works.
The power goes through a sine wave cycle 60 times each second. That means there are 120 times each second where there is a zero crossing. That is, no voltage on the wires. Just dry wires. Now widen this period of time from zero milliseconds to some positive number of milliseconds, and you now have a definite time period where the voltage on the lines is less than X. (Where X is some small desired voltage.) During this time, you can transmit a high frequency signal on these dry wires.
I know that is a vague description. It was many (like 14) years ago when I read the specs on how X10 works on the power line.
There are no doubt other techniques. So why would anyone be skeptical of the mere capability to send high bandwidth information over power lines?
So the universe won't be wiped out by a big crunch.
What a relief. I was worried.
The universe will be wiped out by the heat death of the universe instead.
(Or am I incorrect in my understanding?)
i believe the policy is there b/c the stores don't want you to buy the product, install the product, and then return the opened product. they would have a very hard time selling any software at all.
They are just going to have to get used to it. I can buy a book at Borders and then return it. (Even after reading some or all of it! Horrors!)
Any other type of merchandise can usually be returned right away, with receipt. A software product should be no different. Nor a music CD.
It won't change the EULA's at all, but you'll at least be able to read it before you buy it.
So instead of foisting the responsibility to accept returns onto the retailers, the manufacturers are going to force the retailers to install microfilm readers like in the library?
Drunkenness increases the likelihood of all kinds of mistakes and misery
:-)
I agree. But a good number of the examples you cite are limited to modern times.
Certianly AIDS appears to be a modern problem. (Not that it might not have existed, but never seemed to be an epidemic.)
As for unplanned pregnancies, before about 1960'ish, and especially a couple thousand years ago, sex was viewed very differently because of the risk of pregnancy. I suspect that the stigmas attached to sex and alcohol might have actually reversed in some senses.
Yes, I agree, having drunk troops might be bad for military effectiveness.
It is certainly not only an NT teaching
I know that. My observation is that there is no universal proscription against drinking, as in one of your links. In Proverbs 31:4-7 the effect (also in one of your links) on one who sits in judgement, but also interestingly, it says in [6] to "Give strong drink to him who is ready to perish.... and [7] Let him drink and forget his poverty and remember his misery no more." (definitely suggesting drinking past the legal limit
My reply was simply that I think we are way to hung up on the whole "wine" thing in this story. In fact, as I read it, every single thing that Jesus did in his ministry was to cause people to believe. The water to wine actually did this.
Whatever you, I or anyone else might think of drinking, the fact is that people have, do, and will drink. (And do all kinds of other behaviors.) It's just the human condition. An ugly one. Not the Star Trek "we can save ourselves" utopia.
I have only read bits of Matthew Henry, but but the words you quoted seem to suggest that wine is just another thing for man to enjoy. Which probably means that like anything discussed on slashdot, can be abused.
The Bible lays out in very unflattering terms the flaws of its characters. The whole point running through it, imho, is that man cannot save himself by behaving good [not getting drunk, etc.]. The whole theme is the salvation of man, not a primary focus on how to behave. But on how to believe.
The very fact that we read a story like the 'water to wine' and are hung up on the incidental details is very telling of how we think that certian behavior is what God requires rather than belief. I frequently find myself thinking that how I behave is what is most important.
Back to the subject, I personally can't imagine that getting intoxicated to the point of imparing judgement wouldn't be a common thing. Esp. at a wedding. Most people just aren't that uptight. I can't imagine that some people at the wedding, partying might not drink sufficiently that they would impair their judgement. Even acting significantly stilly or embarrasing themselves later. (Not necessarily falling down puking drunk.) Of course, this then is a matter of perspective. Perhaps this is "drinking to merriment" rather than being drunk. Of course, perhaps it might have been common at weddings for some people to be just plain drunk by the time they left. I don't really know. You might be right about "merriment" vs. "drunk". I wouldn't know where to draw the line.
Fool me once, shame on me. ....
We should have learned our lesson about corporate espionage the first time. But now that history has repeated itself, within only a few days, I guess we didn't learn our lesson the first time here on Slashdot.
How many times will we have to have faulty motherboards and other consumer electronic items before we learn our lessons abotu corporate espionage?
Are we learning yet?
One other thing I might point out, in general. I've heard some people argue that the "wine" in new testament times was more like "grape juice". I disagree. They didn't have Welch's modern preservation techniques. When they had grape juice, you can believe that it turned into wine and that they knew the difference between "wine" and "grape juice" and could use the correct terminology. Humans didn't suddenly become "smart" or have some dramatic evolution of our brains just because we developed integrated circuit lithography.
Drinking to merriment is not drinking to intoxication.
I disagree. I suspect there wasn't a huge distinction. I'm not a student of history, so I may be all wet here. But it seems logical that when you don't have automobiles or other dangerous machinery that there might not be the same social stigma with drinking.
I know there is a new testament teaching about drunkenness.
But back to this wedding. Hey's it's a party, a wedding. Be happy. People drink. In fact, one of the points about bringing out the best wine first and the really cheap stuff later is that the guests are too drunk to notice. But the "water to wine" was the "good stuff" and raised the question of why the good stuff was being saved to last. (because they had run out of wine, and Jesus turned water to wine.)
Just my opinion, but I think the 20th century church is way too uptight.
Turning the water to wine being the first miracle, and it had a good result. The chief result: his disciples put their faith in him. (At end of the story.) Everyone gets so hung up about the fact that alcohol was involved. He seemed reluctant to do it at first, but his mother said "do whatever he tells you", sort of persuading him, and he did it.