You're a fool and a slave. Why don't you just get on about sucking the cocks of your corporate overlords while they pound you in your ass. You're so stupid, you don't even realize you are not "Free". It has nothing to do with "Free" as in price. Everything to do with "Free" as in Freedom. You don't even own your phone or the data on it you douche-bag. Your masters do. But, you won't believe it, because you are too goddamn stupid. All you know is it tastes sweet, looks shiny, and smells like flowers. If they coat their cock in sugar, scent it with jasmine, and polish it with chrome, you will drink their spooge like a good little slave. Jack-Ass!
If you are in the 49% or 25% or 10% or whatever that don't have h.264 by default you're screwed. But, what do you care. You only care about yourself, not society as whole. You're a selfish fucking son-of-a-bitch like most people. You could give two shits about anyone else in the world. Well, I don't give a shit about you. In fact, why don't you just fucking die!
The Supreme Court just ruled that corporations are now free to spend unlimited amounts of money in support of or against the election of any official or issue they choose. You've heard it before, but, here goes: Welcome to our new CORPORATE OVERLORDS!
And before you say, well, we can all use our free speech rights to counteract that, I say, don't forget that most (like 80% to 90%) of people are sheep who will just go, "OOOH, Shiny! It's good. Shove it in my pie-hole!"
Why? Because every 64-Bit CPU I've ever used always had more than twice as much L2 cache as 32-bit Systems. In other words, the hardware manufacturers/designers have already accounted for that.
Not an insult, but, I think you're failing to see the Forest for the Trees. How about this, instead of sites needing to add Gordon (or something like it of the next-generation) to their site, if you could install an Add-On in Firefox (or other browsers) that was a Simple JS library that would replace Flash tags with SVG "Stages" and use Gordon to provide the conversion from SWF to SVG/JS/CSS/DOM/SMIL/etc. Think Greasmonkey and Gordon put together for example, but, in a better more integrated way.
Remember, this is just a prototype and proof-of-concept at this point, but, if with a little imagination, it presents a clear way forward.
What part of, "Gordon, or technology like it, can then be used for legacy Flash support," did you miss?
BTW, condolences on the whole Novell thing. I definitely recall how it was obvious that Win95/98 did everything in its power to break Novell and force any sane person to *have* to move to NT/AD.
Your unconditional faith in entrenched players is astounding. Also, the ending question about completely supplanting doesn't mean what most people seem to think it means. The point isn't that Gordon can replace Flash using SVG/HTML5, it is that soon, it appears, that SVG/HTML5/JS will be able to replace all the funtionality of Flash. Gordon, or technology like it, will just allow legacy Flash content without requiring a Flash Plug-In.
I'm really amazed how short-sighted a lot of the comments on this are.
"There's no practical advantage to using XHTML over HTML." - that's not a complaint, it's a fact
Here, I'm afraid to say, you show your ignorance (that is not an insult - I'm using "ignorance" in the way it was meant to be used, that is, "You are IGNORANT [i.e. are not aware] of the facts") of the purpose of XHTML. It is not just adding some extra slashes and having to close your tags. It has NOTHING to do with data. What it allows, is embedding of other WELL-DEFINED XML namespaces. For example: SVG, MathML, SMIL, etc.
You are wrong even though you think you are right. The question is, what are the odds that "if 1 is heads, the other one is also" - not what are the odd that both will be heads.
The latter corresponds to the analysis given. The former (the question asked does not). In the actual question, the first two possibilities are either ruled out, because you've already stated that the first coin is 1, or, you are allowing for either coin to be one, then what are the odds of the other to be one as follows:
0 - 0 = Ruled out by the given
0 - 1 and 1 - 0 -....
Woops! Never mind. I was reading the question incorrectly. I read "if one is heads" as "if the first is heads". Need to work on my readin comprehension, not my odds skilzzz.
And do you know anything about email? Or the purpose of encryption?
Yes. Yes.
But, apparently, you are quite confused! You should probably re-think your statements before you speak. You show yourself to be misinformed and ignorant.
I send something to someone to read. They can read it. It can't be read by someone else until the intended recipient gets it and decrypts it. What the recipient does after that has NOTHING to do with encryption (nor can it). If you think otherwise, you really are misinformed. What your are advocating in DRM (Digital Restrictions Management) which is "Defective By Design" and doesn't actually achieve the purpose you are seeking (keeping intended recipient from doing with something you sent them what you don't want done). I'm sorry, but, no sane person is going to every grant you such control.
3 Modes:
1. Non-encrypted - no need to warn, not claiming to be secure (No Lock Shown/No Yellow URL Bar)
2. Signed-Certificate - claiming to be secure, lock-shown, yellow-url bar shown - verification exists that the traffice is in fact encrypted by domain owner (exluding difficult and unlikely MITM)
3. Un-Signed Certificate - claiming to be secure, but, no verification exists that traffice is in-fact encrypted by domain owner.
If you can't understand the difference, then you need to REALLY think about the problem for a moment instead of just shooting off your mouth.
You never used iBCS under Linux I take it? I used to use it extensively to run SCO, and other Unix binaries, on Linux (back in the 2.1/2.2 Kernel Days -- maybe even earlier) and it worked GREAT! I ran many proprietary, binary-only, serious applications on Linux that were only for other Unixes.
1. i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etc
There is nothing for Verisign to pass on. They only have your public key. You keep your private key private. Look into how Public Key Cryptography works before you worry about non-existent problems
2. i could create keys without firefox complaining like two year old about them
Again, your lack of understanding is astounding. Firefox complains because it has no way of verifying that your generated Public Key is actuall from who is says it is (You). Firefox must be able to get a copy of your public key from a "Trusted" source in order to verify your key. There are 3 possibilities: 1) Register your Public Key with a "Trusted" Key Service (i.e. Verisign), 2) Register your own key signing authority with a "Trusted" service (i.e. Verisign) and then register your public key (Cert) with your own key registrar, 3) Install a copy of your public key (cert) into the pre-trusted keys in Firefox (provide an installer for your end users).
You DON'T need to send your public key to someone securely. That's why it's called PUBLIC KEY!
Allow me to explain. Public Key Cryptogrpahy uses 2 VERY LARGE prime numbers as keys. One is your Public Key, which ANYONE CAN KNOW. Give it out freely. Publish anywhere. Paint it on your forehead. Doesn't matter. The other is your Private Key. This you keep PRIVATE! NO ONE, not even your most trusted friends and allies, should or needs to know your private key.
Now, you can use your key-set in two ways: 1) You encrypt a message to someone in particular by using THEIR PUBLIC KEY and YOUR PRIVATE KEY. You send them the encrypted message (and you can even send them a copy of YOUR PUBLIC KEY at the same time if they don't already have it). They decrypt the message you sent them using YOUR PUBLIC KEY and THEIR PRIVATE KEY. At know time does either party let any other party know their PRIVATE KEY. Anyone else who has your Public Key will be unable to decrypt the message (in a reasonable amount of compute time) without access to the PRIVATE KEY of the recipient (who you sent the message to). 2) You generate a second Public/Private Key-Pair (in addition to your normal key-pair). You encrypte a message (or digest thereof) using your REAL PRIVATE KEY and the generated extra PUBLIC KEY from the generated pair. You send the message and encrypted digest along with the generated PRIVATE/PUBLIC KEY PAIR (NOT YOUR REAL PRIVATE KEY THOUGH). The recipient should already have a copy of your public key gotten through offline channels. The recipient uses your REAL PUBLIC KEY plus the generated PRIVATE KEY included with the message plus the encrypted digest to verify that you are indeed the sender. This method is used to verify that the sender is the correct person that matches up with the Public Key I KNOW for a fact I received from that sender previously.
So, method 1 allows encryptiion/decryption of the message and verification that no one has intercepted the message and decrypted it (and, if you have the receiver has a copy of the senders public key already, it verifies the sender as well). Method 2 simply verifies that the sender is, in fact, the sender whose public key the receiver already has a copy of without encrypting the message.
The important point is that nowhere does any party ever give out their real PRIVATE KEY to anyone else.
Another important point: Most of the time Public Key Cryptography is only used in order to encrypt and transmit a Private Key (like an AES key) for a Non-Public Key Cryptography cryptographic method because PKC is computationally intensive whereas private key schemes are require much less computational overhead. So, in effect, we exchange Public Keys, then one party sends the other party an encrypted message containing only the key for a non-public-key crypto method. Then, the two parties begin comunicating using the non-PKC algorithm using the key exchanged via PKC.
Slashdot Mirror
Most people are STUPID!
"I've go mine, get yours" is your only talking point.
You're a fool and a slave. Why don't you just get on about sucking the cocks of your corporate overlords while they pound you in your ass. You're so stupid, you don't even realize you are not "Free". It has nothing to do with "Free" as in price. Everything to do with "Free" as in Freedom. You don't even own your phone or the data on it you douche-bag. Your masters do. But, you won't believe it, because you are too goddamn stupid. All you know is it tastes sweet, looks shiny, and smells like flowers. If they coat their cock in sugar, scent it with jasmine, and polish it with chrome, you will drink their spooge like a good little slave. Jack-Ass!
Nothing you said contradicts a single word of what I said. In fact, you just made my point.
You're aware that there is a Patent on the "Method", not on the specific software implementation right? Right?
This is precisely on-topic. No, I guess not. Why? Because you're in the 80 - 90%. Fucking Douche-Bag!
If you are in the 49% or 25% or 10% or whatever that don't have h.264 by default you're screwed. But, what do you care. You only care about yourself, not society as whole. You're a selfish fucking son-of-a-bitch like most people. You could give two shits about anyone else in the world. Well, I don't give a shit about you. In fact, why don't you just fucking die!
15% of a $ -100.00 increase is: You owe me $ 15.00 you scmuck! I like it.
Well put my friend! Well put!
The Supreme Court just ruled that corporations are now free to spend unlimited amounts of money in support of or against the election of any official or issue they choose. You've heard it before, but, here goes: Welcome to our new CORPORATE OVERLORDS!
And before you say, well, we can all use our free speech rights to counteract that, I say, don't forget that most (like 80% to 90%) of people are sheep who will just go, "OOOH, Shiny! It's good. Shove it in my pie-hole!"
Why? Because every 64-Bit CPU I've ever used always had more than twice as much L2 cache as 32-bit Systems. In other words, the hardware manufacturers/designers have already accounted for that.
Not an insult, but, I think you're failing to see the Forest for the Trees. How about this, instead of sites needing to add Gordon (or something like it of the next-generation) to their site, if you could install an Add-On in Firefox (or other browsers) that was a Simple JS library that would replace Flash tags with SVG "Stages" and use Gordon to provide the conversion from SWF to SVG/JS/CSS/DOM/SMIL/etc. Think Greasmonkey and Gordon put together for example, but, in a better more integrated way.
Remember, this is just a prototype and proof-of-concept at this point, but, if with a little imagination, it presents a clear way forward.
What part of, "Gordon, or technology like it, can then be used for legacy Flash support," did you miss?
BTW, condolences on the whole Novell thing. I definitely recall how it was obvious that Win95/98 did everything in its power to break Novell and force any sane person to *have* to move to NT/AD.
Your unconditional faith in entrenched players is astounding. Also, the ending question about completely supplanting doesn't mean what most people seem to think it means. The point isn't that Gordon can replace Flash using SVG/HTML5, it is that soon, it appears, that SVG/HTML5/JS will be able to replace all the funtionality of Flash. Gordon, or technology like it, will just allow legacy Flash content without requiring a Flash Plug-In.
I'm really amazed how short-sighted a lot of the comments on this are.
Where is the production version of IE that supports HTML 5 reasonably well? Oh, it doesn't exist does it?
"There's no practical advantage to using XHTML over HTML." - that's not a complaint, it's a fact
Here, I'm afraid to say, you show your ignorance (that is not an insult - I'm using "ignorance" in the way it was meant to be used, that is, "You are IGNORANT [i.e. are not aware] of the facts") of the purpose of XHTML. It is not just adding some extra slashes and having to close your tags. It has NOTHING to do with data. What it allows, is embedding of other WELL-DEFINED XML namespaces. For example: SVG, MathML, SMIL, etc.
You are wrong even though you think you are right. The question is, what are the odds that "if 1 is heads, the other one is also" - not what are the odd that both will be heads.
The latter corresponds to the analysis given. The former (the question asked does not). In the actual question, the first two possibilities are either ruled out, because you've already stated that the first coin is 1, or, you are allowing for either coin to be one, then what are the odds of the other to be one as follows: 0 - 0 = Ruled out by the given 0 - 1 and 1 - 0 - ....
Woops! Never mind. I was reading the question incorrectly. I read "if one is heads" as "if the first is heads". Need to work on my readin comprehension, not my odds skilzzz.
And do you know anything about email? Or the purpose of encryption?
Yes. Yes.
But, apparently, you are quite confused! You should probably re-think your statements before you speak. You show yourself to be misinformed and ignorant.
I send something to someone to read. They can read it. It can't be read by someone else until the intended recipient gets it and decrypts it. What the recipient does after that has NOTHING to do with encryption (nor can it). If you think otherwise, you really are misinformed. What your are advocating in DRM (Digital Restrictions Management) which is "Defective By Design" and doesn't actually achieve the purpose you are seeking (keeping intended recipient from doing with something you sent them what you don't want done). I'm sorry, but, no sane person is going to every grant you such control.
3 Modes:
1. Non-encrypted - no need to warn, not claiming to be secure (No Lock Shown/No Yellow URL Bar)
2. Signed-Certificate - claiming to be secure, lock-shown, yellow-url bar shown - verification exists that the traffice is in fact encrypted by domain owner (exluding difficult and unlikely MITM)
3. Un-Signed Certificate - claiming to be secure, but, no verification exists that traffice is in-fact encrypted by domain owner.
If you can't understand the difference, then you need to REALLY think about the problem for a moment instead of just shooting off your mouth.
So why didn't you setup a proxy for the imaging server and serve them up yourself via HTTPS?
Already answered...
Since the group that served up images didn't care at all about encryption and wouldn't budge, the initiative was scrapped.
You never used iBCS under Linux I take it? I used to use it extensively to run SCO, and other Unix binaries, on Linux (back in the 2.1/2.2 Kernel Days -- maybe even earlier) and it worked GREAT! I ran many proprietary, binary-only, serious applications on Linux that were only for other Unixes.
I'd be pro if
1. i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etc
There is nothing for Verisign to pass on. They only have your public key. You keep your private key private. Look into how Public Key Cryptography works before you worry about non-existent problems
2. i could create keys without firefox complaining like two year old about them
Again, your lack of understanding is astounding. Firefox complains because it has no way of verifying that your generated Public Key is actuall from who is says it is (You). Firefox must be able to get a copy of your public key from a "Trusted" source in order to verify your key. There are 3 possibilities: 1) Register your Public Key with a "Trusted" Key Service (i.e. Verisign), 2) Register your own key signing authority with a "Trusted" service (i.e. Verisign) and then register your public key (Cert) with your own key registrar, 3) Install a copy of your public key (cert) into the pre-trusted keys in Firefox (provide an installer for your end users).
You DON'T need to send your public key to someone securely. That's why it's called PUBLIC KEY!
Allow me to explain. Public Key Cryptogrpahy uses 2 VERY LARGE prime numbers as keys. One is your Public Key, which ANYONE CAN KNOW. Give it out freely. Publish anywhere. Paint it on your forehead. Doesn't matter. The other is your Private Key. This you keep PRIVATE! NO ONE, not even your most trusted friends and allies, should or needs to know your private key.
Now, you can use your key-set in two ways: 1) You encrypt a message to someone in particular by using THEIR PUBLIC KEY and YOUR PRIVATE KEY. You send them the encrypted message (and you can even send them a copy of YOUR PUBLIC KEY at the same time if they don't already have it). They decrypt the message you sent them using YOUR PUBLIC KEY and THEIR PRIVATE KEY. At know time does either party let any other party know their PRIVATE KEY. Anyone else who has your Public Key will be unable to decrypt the message (in a reasonable amount of compute time) without access to the PRIVATE KEY of the recipient (who you sent the message to). 2) You generate a second Public/Private Key-Pair (in addition to your normal key-pair). You encrypte a message (or digest thereof) using your REAL PRIVATE KEY and the generated extra PUBLIC KEY from the generated pair. You send the message and encrypted digest along with the generated PRIVATE/PUBLIC KEY PAIR (NOT YOUR REAL PRIVATE KEY THOUGH). The recipient should already have a copy of your public key gotten through offline channels. The recipient uses your REAL PUBLIC KEY plus the generated PRIVATE KEY included with the message plus the encrypted digest to verify that you are indeed the sender. This method is used to verify that the sender is the correct person that matches up with the Public Key I KNOW for a fact I received from that sender previously.
So, method 1 allows encryptiion/decryption of the message and verification that no one has intercepted the message and decrypted it (and, if you have the receiver has a copy of the senders public key already, it verifies the sender as well). Method 2 simply verifies that the sender is, in fact, the sender whose public key the receiver already has a copy of without encrypting the message.
The important point is that nowhere does any party ever give out their real PRIVATE KEY to anyone else.
Another important point: Most of the time Public Key Cryptography is only used in order to encrypt and transmit a Private Key (like an AES key) for a Non-Public Key Cryptography cryptographic method because PKC is computationally intensive whereas private key schemes are require much less computational overhead. So, in effect, we exchange Public Keys, then one party sends the other party an encrypted message containing only the key for a non-public-key crypto method. Then, the two parties begin comunicating using the non-PKC algorithm using the key exchanged via PKC.
WHOOSH!