Seems like Jonathan Ives would be a pretty good fit for the keynotes at least. He's got a decently strong reality distortion field, if not as strong as Jobs'. I don't know if they'd want him as CEO or if they'd rather keep him as head of design, though.
Code Green Networks provides scanners that detect and block certain documents from going across your network. Of course, they won't stop an intelligent and determined corporate spy, but that's a much harder problem.
Haha, OK. I'm sorry for saying that you don't know what you're talking about with the vulnerability assessment... good to know you're not just a Slashdot troll.
Implementations are interesting if they use new techniques.
Ehhhh, perhaps in other cases. Compact Javascript and G4 assembly however aren't examples of a cryptographers particular prowess.
Meh, it's a quals paper. Should be sort of interesting, though... I'm not aware of anyone using a vector permute unit to do subfield arithmetic in constant time before.
The identity schemes are published in FOCS and Asiacrypt.
No it can't. You still need a way to get the packets to the man in the middle, and a way to get the packets where they don't belong.
Of course. It's just that this is 6-7 orders of magnitude easier than breaking RSA, even against a relatively hard target.
Secondly, DNSSEC uses the RSA key for a long time, and clients can get lots of signings to launch offline attacks.
Signings shouldn't help the attacker unless your hash is broken... it probably takes a worse break than the current ones against MD5 and SHA1, as well.
All other things being equal, that answers mmell's question: Why is RSA safer for bank transactions than for DNSSEC?
All other things are not equal, though, and that's the point. The banks don't care as much about performance, and they can upgrade much more easily than DNSSEC if RSA-1024 falls.
How the hell can anyone be as fucking numb as you are to these two very simple things and still "be a cryptographer"?
Basically, cryptographers tend to assume that the attacker can easily do things that in the real world might be feasible. So when you design a protocol, you usually assume either a secure channel, an eavesdropper, or an attacker who controls the entire network. For building an internet protocol, you usually assume that last one...
I call shenanigans! If you're actually paid to design cryptosystems, let me know which ones so I can avoid them.
You probably want to avoid them anyway... I'm a grad student so I don't design very practical stuff (yet...):
An anonymous identity-based scheme which doesn't use bilinear pairings, but too slow to be useful in practice... the prototype version takes about 3 seconds to encrypt on my 3-year-old Athlon64x2. I need a really clever number theorist to speed this one up.
A purely theoretical scheme... first provably secure yadda yadda yadda under the yadda yadda assumption.
A fast, powerful but slightly edgy identity-based scheme... might be useful someday.
The fastest, most compact Javascript implementation of AES and SHA. Not useful unless you're Google.
The fastest implementation of AES for the PowerPC G4 (because of its permute unit). Might end up being the fastest software implementation at all, clock for clock... too bad nobody uses the G4.
Point taken: you could put the software on the server, but that's no good if the server is malicious.
But really, in looking for a technological solution, you're assuming that some baseline of technology will be around in 10 or 20 years, even if not in common use. So you can probably stick the source for GPG on a disk and use that disk to read the data.
You don't have any idea what you're talking about, do you? Or else I have been trolled. Or both. Blah, someone is wrong on the internet.
The fundamental design goal of a good cryptosystem is that it should never be the weak link, at least when used within the specified parameters. If people believe that it can be the weak link, they stop using it and go to something else. This has not been done with RSA, so think twice before saying that RSA is easy to break.
In order to break your bank transactions, someone not only needs to break RSA, they also need to break TCP, and quickly, I might add.
TCP is not a security mechanism. It can act as a defense in depth, but that's all.
Without TCP, RSA becomes significantly weaker, no longer requiring a billion dollar machine to break very small messages- if you're trying to spoof an IP address, you only need to attack four bytes; a differential attack could special case keys for less still.
Nobody uses RSA as written in a popular science crypto book. In real life, RSA is used either with padding or, more commonly, as a KEM, and so it is not vulnerable to attacks on short messages.
TCP is rarely broken; people rarely have their POP3 passwords sniffed, and rarely have those connections hijacked, and in the absence of a lan-based attack, the practical probability becomes almost nil.
At this moment, people's BT routers are replacing ads on their web pages, and you're telling me that "TCP is rarely broken". Even if you weren't utterly wrong, rarely just isn't good enough. When was the last time you saw a 1024-bit RSA key broken? The only time I've seen it is with that Debian crypto bug... and if we're counting software bugs, you should see the sequence numbers some OS's generate even today.
You're comparing an attack which you might theoretically be able to perform with a billion-ish-dollar machine that nobody (secret agencies excluded) has ever attempted to build, and an attack that gets run a hundred times a day by each of thousands of $30 routers. Imagine the report at the NSA: "Sir, Project XERCES broke the key in six weeks at an amortized cost of $50 million, but the trouble is, we can't seem to tap his cable modem."
Breaking TCP is hard because not only do you have to break the sequence numbers, you also need to break route filters, and possibly more; Part of HTTPS's practical security comes from the fact that breaking HTTP's unintentional security is hard as is- a single short-lived message over a dozen messages, spanning a second, is much harder to break than a RSA-signed DNS packet, which might be valid for days- or even weeks.
As is common for crypto protocols, if the RSA key in HTTPS is broken, a man in the middle can mess with the protocol in real time. Failing that, I don't know of any attack against the HTTPS protocol. There are still ways to "break HTTPS": you can hope the user clicks through a cert warning, or you can muck with cookies, XSS, malware, and other attacks on the browser.
LAN-based attacks (hacking a router, spoofing ARP, sniffing wireless, splicing cables) are impractical for most attacks; we generally only see them for extremely targetted attacks. It seems reckless and naive to optimize for this case, when DNSSEC only seems able to do it by making the practical and likely attacks easier.
DNSSEC and DNSCurve are cryptosystems. They are designed never to be the weak link.
And I'm not sure what you mean by "breaking TCP"...
Breaking TCP presently requires guessing sequence numbers reliably or a MITM attack. Both are extremely uncommon outside of LANs.
This isn't true... the best known attacks against RSA are just to factor the modulus.
What isn't true? Breaking RSA is easier than breaking RSA and TCP? (note "also" in my original phrasing)
Breaking TCP requires hacking a router, spoofing ARP, bribing a tech, sniffing a wireless network, presenting a warrant or splicing a cable somewhere, and that's if you don't have weak TCP sequence numbers. Breaking RSA-1024 requires sinking a billion dollars into a crypto machine. One of these provides an insignificant level of security compared to the other one, such that it is barely worth mentioning.
You all talk about encrypting, but did you ever think about the key? What if you loose your key? Maybe in the future you will use another key and forget about the one you used for achiving. And when you need the data......where did you put that key?
You can write the key down and put it in your wallet or a safe, use a key you will remember, put hints on the server, or whatever. Ultimately, you need to retain some token (either a physical token or information) which will allow you to access the data, and a key is about as small and easy-to-protect a token as you could ask for.
It's a security-convenience trade-off. It's inconvenient for me to type all my passwords every time I load up my system, so I store the less important ones (email, but not banking) in the system keychain, which is encrypted with my login password.
In doing so, I open myself up to some vulnerabilities. One is that someone could steal my computer, break the login keychain (should take only 2^50 time or so... haha), and recover my passwords. Another is that someone could sneak into my room while I'm logged in and steal all my passwords... but if they were to install a keylogger, they could get them all anyway.
But these risks are minor for me compared to saving me 10 seconds every time I open a password-protected service.
Encryption only works because brute forcing the scheme on current hardware is ridiculously time consuming. Encrypting with today's standards does not protect against future advances in computing power.
Actually, future increases in computing power are about the one thing modern crypto can protect against. There is not enough energy in the galaxy to brute-force a 256-bit symmetric key:
...brute force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space."
--Bruce Schneier
Ah, but what if someone builds a quantum computer? Well, it turns out that in that case, they might be able to brute force your key, and it might only take enough energy to boil the oceans dry, instead of all the energy in the Milky Way. So if you're worried about that, encrypt it 3 times (not just twice... someone able to store a quantum bit of memory on every atom in the earth might be able to boil the oceans to decrypt it...)
Seriously. While modern crypto cannot protect you against new developments in mathematics or physics, bugs, side channels, malware, torture, telepathy, theology or blind luck, it can protect you against increases in computing power if you choose the right key size.
Same goes for authentication, by the way... if you MAC all the data, it should be secure against tampering forever, if not longer, with high probability. [Longer than forever, because the MAC may not contain enough information to brute-force the key.]
Curve is very well understood, and its security is twenty years old at this point. Curve is much faster than RSA, and in something like DNS, slowness can turn into denial-of-service attacks. Futhermore, Curve can guarantee only exponential time solutions exist, where RSA has been broken in sub-exponential time.
Technically, while cryptographers have not found sub-exponential attacks on elliptic curves, they are not guaranteed not to exist. The point, though, is that with existing attacks (which, as you mentioned, are 20 years old), 255-bit ECC is believed to be considerably more secure than 1024-bit RSA... in fact, it should be comparable to 4096-bit RSA. The signatures are considerably shorter. 255-bit ECC is probably slower than 1024-bit RSA for verifies, however.
Funny thing - if RSA1024 is more than enough to secure my bank transactions, why wouldn't I trust it with my DNS queries?
Excellent question.
Because not only does someone have to break RSA to break your bank transactions, someone also has to break TCP, which is actually much harder, and requires a monstrous amount of computer power and bandwidth available at sub-msec speeds. With DNS, breaking TCP isn't a requirement, because DNS doesn't use TCP.
This isn't true... the best known attacks against RSA are just to factor the modulus. Once you'd done this, you could easily break bank transactions in real time. And I'm not sure what you mean by "breaking TCP"...
The real reason is that when cryptographers decide that 1024-bit RSA isn't enough (soon, by Bernstein's reckoning), the banks will go to more bits or another cipher. They can do this, because people don't mind a delay of several milliseconds while they run RSA on their bank's website, and they can deal with an extra half-KB for session setup. They can get new ciphers rolled out to browsers, and degrade to RSA for browsers that haven't implemented them. These problems are considerably worse for DNS servers and routers.
On the other hand, with DNSSEC, we're talking about using RSA in a new standard; its performance and size are already problematic at the current strength, and will get cubically worse at greater strengths.
You misunderstand. What I mean is that marketing statements (other than puffery...) should be things that an average, rational member of your target audience would agree to be true. "Running" an OS that Microsoft (or someone else?) calls Vista isn't enough: it has to be the Vista your target audience expects. If most shoppers think Vista == Aero (because that's what MS advertises), you need to support Aero unless you say otherwise. Similarly, if you're marketing to large businesses, "Vista capable" should mean that it runs Vista Pro, with the features that MS claims for Vista Pro.
Otherwise, the sticker is completely vacuous. What's the minimum level of support? A stripped-down GUI with no sound or wireless? A text console? The bootloader?
In the case of Ubuntu, if you put "Ubuntu capable" on a laptop, then yes, it has to run X. I'd be pretty pissed if someone sold me a laptop, told me that Ubuntu runs on it, but they only meant in a text console, and oh the network card and sound don't work either. And it panics on boot unless you set acpi=ht.
On the other hand, if you put "Ubuntu capable" on a Soekris box with no video out, it should be clear to your target audience that you mean Ubuntu Server and that X is not supported.
Disclaimer: "should" above is not a legal term, nor is it RFC 2119 compliant.
But Vista Basic IS a version of Vista. If that machine can boot and run Vista basic than it is a vista capable system, this lawsuit should be thrown out.
Bullshit. By that reasoning, Microsoft could rename DOS 5 "Vista Old School" and then any 386 or higher would be "Vista Capable".
i find it even more insulting to think that even if there is a god, why doesn't he show himself? and how do these religious people know for a fact that what they are praying to, really is that god?
Myself, I don't understand the answer to this question.
A Christian friend of mine (whom I respect highly, btw) says that God showing himself would take away our free will. We would have only an instant to decide whether we're for him or against him. A decision made that suddenly wouldn't be very free (in the sense of a rational decision with all options viable), and if we chose "against" it would be nearly impossible to reverse the decision. Instead, then, God chooses to reveal himself slowly, in a way that He chooses, to make our decision more free and/or to influence it for the best (but I'm not sure how these are compatible...).
As for how people know that the God they are praying to is really who they think... it's supposed to be a conversation. They know who they're talking to because he's talking to them, and working in their lives.
And even if there is a god, then why doesn't he interfere ? is he incapable ? or not willing ? in both cases he loses the right to be prayed to.
I think the Christian understanding is that he does intervene, but not always in the obvious way, and certainly not always by answering the exact request. I think I've seen this happen even in my own life, but it's so difficult to be sure...
"(A) is 10% quicker than (B)" means time(A) = 0.9 * time(B), and not time(B) = 1.1 * time(A).
You're just repeating the mistake.
Honestly, I was sort of being a prick. "(A) is 10% quicker than (B)" is ambiguous, and I can't find a reference on the internet for its usage... it doesn't appear to be in, say, the CMS at all. So really, for large percentages or high degrees of precision, where it actually matters, you should avoid that construction. That is, of course, unless you and the people you're communicating with have an agreement on what it means.
However, I made a pretty good argument for why it should mean that time(B) = 1.1*time(A). And I that in certain contexts, you'd have to agree with me. For instance, the obligatory car analogy: if car A is 10% quicker than car B, that pretty clearly means its average speed is 10% greater, which means that car B takes 10% more time to complete a given course. You, on the other hand, have just repeated your claim that I'm wrong, with no argument or citation to back it up.
Of course, if you want to say that "(A) completes 10% quicker than (B)", you'd have an argument. Or maybe you have a reference for your reading? Or some reason other than that you said so?
(A) being 10% quicker than (B) is not the same as (B) taking 10% longer than (A).
Yes it is. (A) being 10% quicker than (B) means that its quickness, i.e. the number of things it accomplishes in a unit of time, is 10% greater. That is, ops(A) / time(A) = 1.1 * ops(B) / time(B). If they perform the same number of ops, the ops cancel; clearing the denominators, this comes out to time(B) = 1.1 * time(A), i.e. (B) takes 10% longer than (A).
This has been your Daily Slashdot Math Lesson (TM).
They said they thought it was a compiler bug. But I think they're wrong. It would be a pretty severe compiler bug to give ~50% performance drop in both Java- and C-based benchmarks. But you'd expect almost exactly 50% performance drop in I/O-bound benchmarks if the CPU and FSB were throttled to half speed...
You wouldn't want a game to follow scientifically realistic principles. For one thing doing so would involve including the possibility that it would go off on a tangent and fail.
Actually, I think you could do it in an RTS, though you'd still have the standard RTS "everything but walking and fighting happens a zillion times faster" effect. The game would give randomized characteristics to your new units based on the ones you already have (natural variation with "inheritance"), and the higher a unit's level, the more likely its traits would be to pass on. Then depending on your play style, various traits would be more or less emphasized. For example, if you did a lot of hit-and-run fighting, your guys would get faster on average over time, and if you hold the line your guys would have more hit points, and so on.
You'd have to make interesting trade-offs. Like using guys with characteristics you don't like as cannon fodder. (Hmm, so maybe there would be some political problems with this game...)
Of course, real evolutionary biology doesn't have many RTS-style battles. Also, since you're guiding the game, it would be sort of like ID-style "directed evolution". Still, the principles would be similar.
Somewhere along the line, you've missed the point...
You missed the point. The entire point of my post was to correct the parent's false statement: that you need the disc in the drive to play. You don't. I still don't condone their use of DRM. In fact, their DRM prevents the game from working properly, so I'm returning it to the store.
Slashdot Mirror
Yes, actually. Live, once, plus once in that commercial. Seemed convincing enough. Plus he has a nice accent.
Seems like Jonathan Ives would be a pretty good fit for the keynotes at least. He's got a decently strong reality distortion field, if not as strong as Jobs'. I don't know if they'd want him as CEO or if they'd rather keep him as head of design, though.
Code Green Networks provides scanners that detect and block certain documents from going across your network. Of course, they won't stop an intelligent and determined corporate spy, but that's a much harder problem.
Haha, OK. I'm sorry for saying that you don't know what you're talking about with the vulnerability assessment... good to know you're not just a Slashdot troll.
Ehhhh, perhaps in other cases. Compact Javascript and G4 assembly however aren't examples of a cryptographers particular prowess.
Meh, it's a quals paper. Should be sort of interesting, though... I'm not aware of anyone using a vector permute unit to do subfield arithmetic in constant time before.
Well that's helpful.
Oh, you actually want to read them? I thought you just wanted me to prove my cred. They're posted on my website.
Implementations are uninteresting. Where are these identity schemes published?
Implementations are interesting if they use new techniques. The identity schemes are published in FOCS and Asiacrypt.
No it can't. You still need a way to get the packets to the man in the middle, and a way to get the packets where they don't belong.
Of course. It's just that this is 6-7 orders of magnitude easier than breaking RSA, even against a relatively hard target.
Secondly, DNSSEC uses the RSA key for a long time, and clients can get lots of signings to launch offline attacks.
Signings shouldn't help the attacker unless your hash is broken... it probably takes a worse break than the current ones against MD5 and SHA1, as well.
All other things being equal, that answers mmell's question: Why is RSA safer for bank transactions than for DNSSEC?
All other things are not equal, though, and that's the point. The banks don't care as much about performance, and they can upgrade much more easily than DNSSEC if RSA-1024 falls.
How the hell can anyone be as fucking numb as you are to these two very simple things and still "be a cryptographer"?
Basically, cryptographers tend to assume that the attacker can easily do things that in the real world might be feasible. So when you design a protocol, you usually assume either a secure channel, an eavesdropper, or an attacker who controls the entire network. For building an internet protocol, you usually assume that last one...
I call shenanigans! If you're actually paid to design cryptosystems, let me know which ones so I can avoid them.
You probably want to avoid them anyway... I'm a grad student so I don't design very practical stuff (yet...):
Point taken: you could put the software on the server, but that's no good if the server is malicious.
But really, in looking for a technological solution, you're assuming that some baseline of technology will be around in 10 or 20 years, even if not in common use. So you can probably stick the source for GPG on a disk and use that disk to read the data.
You don't have any idea what you're talking about, do you? Or else I have been trolled. Or both. Blah, someone is wrong on the internet.
The fundamental design goal of a good cryptosystem is that it should never be the weak link, at least when used within the specified parameters. If people believe that it can be the weak link, they stop using it and go to something else. This has not been done with RSA, so think twice before saying that RSA is easy to break.
In order to break your bank transactions, someone not only needs to break RSA, they also need to break TCP, and quickly, I might add.
TCP is not a security mechanism. It can act as a defense in depth, but that's all.
Without TCP, RSA becomes significantly weaker, no longer requiring a billion dollar machine to break very small messages- if you're trying to spoof an IP address, you only need to attack four bytes; a differential attack could special case keys for less still.
Nobody uses RSA as written in a popular science crypto book. In real life, RSA is used either with padding or, more commonly, as a KEM, and so it is not vulnerable to attacks on short messages.
TCP is rarely broken; people rarely have their POP3 passwords sniffed, and rarely have those connections hijacked, and in the absence of a lan-based attack, the practical probability becomes almost nil.
At this moment, people's BT routers are replacing ads on their web pages, and you're telling me that "TCP is rarely broken". Even if you weren't utterly wrong, rarely just isn't good enough. When was the last time you saw a 1024-bit RSA key broken? The only time I've seen it is with that Debian crypto bug... and if we're counting software bugs, you should see the sequence numbers some OS's generate even today.
You're comparing an attack which you might theoretically be able to perform with a billion-ish-dollar machine that nobody (secret agencies excluded) has ever attempted to build, and an attack that gets run a hundred times a day by each of thousands of $30 routers. Imagine the report at the NSA: "Sir, Project XERCES broke the key in six weeks at an amortized cost of $50 million, but the trouble is, we can't seem to tap his cable modem."
Breaking TCP is hard because not only do you have to break the sequence numbers, you also need to break route filters, and possibly more; Part of HTTPS's practical security comes from the fact that breaking HTTP's unintentional security is hard as is- a single short-lived message over a dozen messages, spanning a second, is much harder to break than a RSA-signed DNS packet, which might be valid for days- or even weeks.
As is common for crypto protocols, if the RSA key in HTTPS is broken, a man in the middle can mess with the protocol in real time. Failing that, I don't know of any attack against the HTTPS protocol. There are still ways to "break HTTPS": you can hope the user clicks through a cert warning, or you can muck with cookies, XSS, malware, and other attacks on the browser.
LAN-based attacks (hacking a router, spoofing ARP, sniffing wireless, splicing cables) are impractical for most attacks; we generally only see them for extremely targetted attacks. It seems reckless and naive to optimize for this case, when DNSSEC only seems able to do it by making the practical and likely attacks easier.
DNSSEC and DNSCurve are cryptosystems. They are designed never to be the weak link.
Breaking TCP presently requires guessing sequence numbers reliably or a MITM attack. Both are extremely uncommon outside of LANs.
What isn't true? Breaking RSA is easier than breaking RSA and TCP? (note "also" in my original phrasing)
Breaking TCP requires hacking a router, spoofing ARP, bribing a tech, sniffing a wireless network, presenting a warrant or splicing a cable somewhere, and that's if you don't have weak TCP sequence numbers. Breaking RSA-1024 requires sinking a billion dollars into a crypto machine. One of these provides an insignificant level of security compared to the other one, such that it is barely worth mentioning.
You all talk about encrypting, but did you ever think about the key? What if you loose your key? Maybe in the future you will use another key and forget about the one you used for achiving. And when you need the data......where did you put that key?
You can write the key down and put it in your wallet or a safe, use a key you will remember, put hints on the server, or whatever. Ultimately, you need to retain some token (either a physical token or information) which will allow you to access the data, and a key is about as small and easy-to-protect a token as you could ask for.
It's a security-convenience trade-off. It's inconvenient for me to type all my passwords every time I load up my system, so I store the less important ones (email, but not banking) in the system keychain, which is encrypted with my login password.
In doing so, I open myself up to some vulnerabilities. One is that someone could steal my computer, break the login keychain (should take only 2^50 time or so... haha), and recover my passwords. Another is that someone could sneak into my room while I'm logged in and steal all my passwords... but if they were to install a keylogger, they could get them all anyway.
But these risks are minor for me compared to saving me 10 seconds every time I open a password-protected service.
Encryption only works because brute forcing the scheme on current hardware is ridiculously time consuming. Encrypting with today's standards does not protect against future advances in computing power.
Actually, future increases in computing power are about the one thing modern crypto can protect against. There is not enough energy in the galaxy to brute-force a 256-bit symmetric key:
...brute force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space."
--Bruce Schneier
Ah, but what if someone builds a quantum computer? Well, it turns out that in that case, they might be able to brute force your key, and it might only take enough energy to boil the oceans dry, instead of all the energy in the Milky Way. So if you're worried about that, encrypt it 3 times (not just twice... someone able to store a quantum bit of memory on every atom in the earth might be able to boil the oceans to decrypt it...)
Seriously. While modern crypto cannot protect you against new developments in mathematics or physics, bugs, side channels, malware, torture, telepathy, theology or blind luck, it can protect you against increases in computing power if you choose the right key size.
Same goes for authentication, by the way... if you MAC all the data, it should be secure against tampering forever, if not longer, with high probability. [Longer than forever, because the MAC may not contain enough information to brute-force the key.]
Curve is very well understood, and its security is twenty years old at this point. Curve is much faster than RSA, and in something like DNS, slowness can turn into denial-of-service attacks. Futhermore, Curve can guarantee only exponential time solutions exist, where RSA has been broken in sub-exponential time.
Technically, while cryptographers have not found sub-exponential attacks on elliptic curves, they are not guaranteed not to exist. The point, though, is that with existing attacks (which, as you mentioned, are 20 years old), 255-bit ECC is believed to be considerably more secure than 1024-bit RSA... in fact, it should be comparable to 4096-bit RSA. The signatures are considerably shorter. 255-bit ECC is probably slower than 1024-bit RSA for verifies, however.
Excellent question.
Because not only does someone have to break RSA to break your bank transactions, someone also has to break TCP, which is actually much harder, and requires a monstrous amount of computer power and bandwidth available at sub-msec speeds. With DNS, breaking TCP isn't a requirement, because DNS doesn't use TCP.
This isn't true... the best known attacks against RSA are just to factor the modulus. Once you'd done this, you could easily break bank transactions in real time. And I'm not sure what you mean by "breaking TCP"...
The real reason is that when cryptographers decide that 1024-bit RSA isn't enough (soon, by Bernstein's reckoning), the banks will go to more bits or another cipher. They can do this, because people don't mind a delay of several milliseconds while they run RSA on their bank's website, and they can deal with an extra half-KB for session setup. They can get new ciphers rolled out to browsers, and degrade to RSA for browsers that haven't implemented them. These problems are considerably worse for DNS servers and routers.
On the other hand, with DNSSEC, we're talking about using RSA in a new standard; its performance and size are already problematic at the current strength, and will get cubically worse at greater strengths.
And yes, I am a cryptographer.
Point taken, but he did also implement the heuristic, usage message, etc as part of the 60 lines.
You misunderstand. What I mean is that marketing statements (other than puffery...) should be things that an average, rational member of your target audience would agree to be true. "Running" an OS that Microsoft (or someone else?) calls Vista isn't enough: it has to be the Vista your target audience expects. If most shoppers think Vista == Aero (because that's what MS advertises), you need to support Aero unless you say otherwise. Similarly, if you're marketing to large businesses, "Vista capable" should mean that it runs Vista Pro, with the features that MS claims for Vista Pro.
Otherwise, the sticker is completely vacuous. What's the minimum level of support? A stripped-down GUI with no sound or wireless? A text console? The bootloader?
In the case of Ubuntu, if you put "Ubuntu capable" on a laptop, then yes, it has to run X. I'd be pretty pissed if someone sold me a laptop, told me that Ubuntu runs on it, but they only meant in a text console, and oh the network card and sound don't work either. And it panics on boot unless you set acpi=ht.
On the other hand, if you put "Ubuntu capable" on a Soekris box with no video out, it should be clear to your target audience that you mean Ubuntu Server and that X is not supported.
Disclaimer: "should" above is not a legal term, nor is it RFC 2119 compliant.
But Vista Basic IS a version of Vista. If that machine can boot and run Vista basic than it is a vista capable system, this lawsuit should be thrown out.
Bullshit. By that reasoning, Microsoft could rename DOS 5 "Vista Old School" and then any 386 or higher would be "Vista Capable".
How do you just jump in the middle of someone's connection?
There are a number of ways to do it. You can:
There are probably a few other ways to do it, but that's all off the top of my head.
i find it even more insulting to think that even if there is a god, why doesn't he show himself? and how do these religious people know for a fact that what they are praying to, really is that god?
Myself, I don't understand the answer to this question.
A Christian friend of mine (whom I respect highly, btw) says that God showing himself would take away our free will. We would have only an instant to decide whether we're for him or against him. A decision made that suddenly wouldn't be very free (in the sense of a rational decision with all options viable), and if we chose "against" it would be nearly impossible to reverse the decision. Instead, then, God chooses to reveal himself slowly, in a way that He chooses, to make our decision more free and/or to influence it for the best (but I'm not sure how these are compatible...).
As for how people know that the God they are praying to is really who they think... it's supposed to be a conversation. They know who they're talking to because he's talking to them, and working in their lives.
And even if there is a god, then why doesn't he interfere ? is he incapable ? or not willing ? in both cases he loses the right to be prayed to.
I think the Christian understanding is that he does intervene, but not always in the obvious way, and certainly not always by answering the exact request. I think I've seen this happen even in my own life, but it's so difficult to be sure...
Interestingly, in both Hebrew and Greek, the word for wind is the same as the word for spirit. So in some sense, the wind instruments are next...
"(A) is 10% quicker than (B)" means time(A) = 0.9 * time(B), and not time(B) = 1.1 * time(A).
You're just repeating the mistake.
Honestly, I was sort of being a prick. "(A) is 10% quicker than (B)" is ambiguous, and I can't find a reference on the internet for its usage... it doesn't appear to be in, say, the CMS at all. So really, for large percentages or high degrees of precision, where it actually matters, you should avoid that construction. That is, of course, unless you and the people you're communicating with have an agreement on what it means.
However, I made a pretty good argument for why it should mean that time(B) = 1.1*time(A). And I that in certain contexts, you'd have to agree with me. For instance, the obligatory car analogy: if car A is 10% quicker than car B, that pretty clearly means its average speed is 10% greater, which means that car B takes 10% more time to complete a given course. You, on the other hand, have just repeated your claim that I'm wrong, with no argument or citation to back it up.
Of course, if you want to say that "(A) completes 10% quicker than (B)", you'd have an argument. Or maybe you have a reference for your reading? Or some reason other than that you said so?
Or maybe I have been trolled?
(A) being 10% quicker than (B) is not the same as (B) taking 10% longer than (A).
Yes it is. (A) being 10% quicker than (B) means that its quickness, i.e. the number of things it accomplishes in a unit of time, is 10% greater. That is, ops(A) / time(A) = 1.1 * ops(B) / time(B). If they perform the same number of ops, the ops cancel; clearing the denominators, this comes out to time(B) = 1.1 * time(A), i.e. (B) takes 10% longer than (A).
This has been your Daily Slashdot Math Lesson (TM).
They said they thought it was a compiler bug. But I think they're wrong. It would be a pretty severe compiler bug to give ~50% performance drop in both Java- and C-based benchmarks. But you'd expect almost exactly 50% performance drop in I/O-bound benchmarks if the CPU and FSB were throttled to half speed...
You wouldn't want a game to follow scientifically realistic principles. For one thing doing so would involve including the possibility that it would go off on a tangent and fail.
Actually, I think you could do it in an RTS, though you'd still have the standard RTS "everything but walking and fighting happens a zillion times faster" effect. The game would give randomized characteristics to your new units based on the ones you already have (natural variation with "inheritance"), and the higher a unit's level, the more likely its traits would be to pass on. Then depending on your play style, various traits would be more or less emphasized. For example, if you did a lot of hit-and-run fighting, your guys would get faster on average over time, and if you hold the line your guys would have more hit points, and so on.
You'd have to make interesting trade-offs. Like using guys with characteristics you don't like as cannon fodder. (Hmm, so maybe there would be some political problems with this game...)
Of course, real evolutionary biology doesn't have many RTS-style battles. Also, since you're guiding the game, it would be sort of like ID-style "directed evolution". Still, the principles would be similar.
Somewhere along the line, you've missed the point...
You missed the point. The entire point of my post was to correct the parent's false statement: that you need the disc in the drive to play. You don't. I still don't condone their use of DRM. In fact, their DRM prevents the game from working properly, so I'm returning it to the store.