Um, no. A 1024-bit key will take 6 to 7 million months to do with TWINKLE (that 500,000 years for y'all without calculators in your skulls), according to RSA Labs.
You're forgetting that vector processors are scads better at array-crunching that scalar (or even super-scalar) Alphas. The dual alpha could *do* it, but it would take much much longer. What's the vector length that Crays can deal with? I'd guess the alpha would be at *least* at factor of 32 slower; I wouldn't be surprised if the cray had 128-element vectors (==alpha 128 time slower).
I'd be willing to give him slack on the.doc thang if he pleads guilty to using a human editor. My experience is that it's real hard to find an editor who won't microsoft-up your text files when you send it to them to peruse. I had a WSJ guy send me a three-line question as a.doc attachment to an email---argh! Kudos to my Salon editors for respecting my.txt, although it *did* return to me with suspicious microsoft-isms...
Can I just take this back? Seems the glibc 2.0 problems are due to linker/loader problems (from reading Bugzilla) and it seems that getting the 2.0 linker to co-exist with the 2.1 linker may not be easy...
It was the result of a contest. The contest directors failed to enforce the constraint that the icon needed to fit within the mozilla color limitations. A vote was taken, and the winner looked *awful* when rendered in mozilla. I submitted a color-fixed version that looked better, but pr'ly i didn't yell loud enough, 'cuz no one took it.
Re:I think you're confusing shared with static
on
Mozilla M9 Released
·
· Score: 1
If two dlls with the same (or overlapping) base address are loaded the the later one will rebase itself. You take a (slight) performance hit while the things are remapped.
So, then the windows DLLs *are* position independent, no? Which brings us back to the first question -- why are the linux binaries larger, and do symbol tables have *anything* to do with it?
Re:I think you're confusing shared with static
on
Mozilla M9 Released
·
· Score: 1
First, it would make no sense to have a "shared" lib that only one application could use. That's static.
No, that's Microsoft. From the above posts, it seems "shared" libraries on MS platforms have a fixed base address, set at build time. So you can "share" all you want... until some two DLLs you need decide they want the same piece of virtual address space. Then all hell breaks loose.
At least this is my impression from reading the above. I don't touch MS stuff, so I wouldn't know, really.
Yes, but as soon as some/. reader notices the GPL-mandated disclaimer, an article goes up saying "WOW! FooBar systems is running LINUX!!!" and then the tech press --- which increasingly uses/. to do its homework for them --- obligingly follows up with a "mainstream" article some short time later. The press releases aren't required, but the current dynamics make press inevitable.
Right, but this is a far cry from claiming that the NSA can do factorizations in seconds.
It comes down to your own personal security criteria, but I'd rather trust a problem that bright people have worked on for centuries (factorization) than one which involves newer (and thus less well-understood) math. That's my personal take.
If Linux really does unite the unix world by simply replacing all others, I very much doubt that regular users of HP-UX, Digital Unix (erm..), IRIX, AIX, Solaris etc will see this as an improvement.
I agree. The best company-adoption-of-Linux story so far has got to be SGI, who's promised to port the groovy IRIX features to Linux. Iff this happens, then IRIX users might not feel they've been downgraded... but this is a big iff.
Even if there is only a few unices, hopefully there will always be many mail transport agents, mail readers, servers and such to limit the spread of a monoculture virus. Microsoft has seriously weakened its defenses by monopolizing its application market: everyone not only uses Windows OS, but reads mail with Outlook, distributes mail using Exchange, serves pages with IIS, etc.
Apache's dominance on the web is potentially a Bad Thing, for the same reasons.
I've read some very convincing papers asserting that various kernel critical paths (and in particular the system call mechanism) are much faster in Linux than in the AT&T-derived unices.
Of course, it may well be that the libraries and userland are faster on *BSD for what you're trying to do. Or it could be that the papers I read lie. I'm rather curious to know which it is.
I'd say the reason why the "bulk of the interest is in Linux" *is* in fact (at least partly) due to the GPL. The GPL means that companies who adopt linux have to be very public about it, because the GPL requires them to make their source & changes publically available. In contrast, a company could be running a *BSD kernel in their shiny embedded box and no one need know.
And market adoption is driven by "what the other guys are doing." Because the GPL forces publicity, it creates its own fad, and thus its own momentum. Not a technical reason, but a sheer dynamics quirk. A particularly successful meme.
PGP and friends do rely on hard mathematical problems. Factoring large numbers is a problem that has been studied for hundred of years. Algorithm improvements *have* taken place. Factoring a 512-bit number used to be unthinkable; now it is (just barely) possible. 4096-bit numbers are many many orders of magnitude more difficult. So it is possible to extrapolate from the current rate of algorithm improvement and an estimate on how far ahead of "the rest of us" the NSA is to get an idea of how secure PGP is. Give the NSA ten years advance, and 4096 bit keys are still safe for a couple of decades (at least!).
And, no, it is *extremely* unlikely the NSA would *ever* be able to factor 4096-bit numbers in *seconds*. Admittedly no one's been able to prove a lower time bound on the integer factorization method, but this problem *has* been studied for centuries. Quantum computing *could* change the paradigm, but the amount of precision one needs for 4096 bits is quite daunting.
And the "near primes" that PGP uses have an astronomically small chance of being non-prime. Basically, the parameters of the algorithm are chosen so that it's about as likely that a person can randomly guess the symmetric key. And generally if the number is non-prime, PGP encryption just plain won't work. Which means that *no one* is able to decrypt your messages (not even you) --- a situation that would be quite obvious if by some miracle it occurred.
Please read http://www-users.informatik.rwth-aachen.de/~send erek/certify/secret-key.protection.html for more information.
No, the reason why Netscape/Mozilla is having such a hard time is because the source code is an impenetrable jungle, and its far from obvious how to make constructive contributions to it.
I downloaded the code and got as far as adding an "about:cananian" redirector, then drowned.
The core source code was never meant for community development, and the code was released to the community before it was usable.
This wasn't a respect issue until E-Trade forced it to be. Red Hat said "the little guys are important, we'd like to reward them." E-Trade disagreed. Holy war ensued to ensure that Red Hat was able to do what they wanted to do in the first place.
Everyone sees this as a "we want money" thing. What we want is the opportunity to act according to our value system in the "real world". Although companies *may* give up the community as soon as they enter Wall Street, when a company (such as Red Hat) attempts to maintain its community orientation it is our responsibility as community members to support them -- or to call them on hypocrisy, if necessary. I have no problem with Corel (for example) keeping their money to themselves. But when an effort to benefit the community goes awry, we have a responsibility to make the faults known, so that future gift-givers don't make the same mistakes.
If you had a generous relative who'd been sending all your Christmas gifts to your next door neighbors by mistake, wouldn't you point out the error? Doesn't mean I'll complain if they don't give me a present next year. It's a *gift*.
OK, since Suck dissed my article as griping for my 30 pieces of silver, I guess I better respond.
As those inside know, it's not about money. It's about respect. We want the world-at-large to notice and adopt the *community values* that linux--and thus Red Hat--embodies. Thus, it was very important that the little guys not be shut out by E-Trade, because this movement is all about the little guys. This is a battle, and we can't stand to lose the ground.
Unfortunately, some of my rant was poorly-written and easily-misconstrued to be whining for my piece of the pie. I tried to be clearer in my follow-up piece; maybe I was successful. But Suck's way off track, here. The Red Hat IPO rewarded *precisely* the developers who Suck claimed would get ignored: the little guys who hacked some obscure feature of a random network driver or some such. It included them *because* we fought for it, and indeed that is the whole reason I pressed Salon to publish an article on the E-Trade fiasco in the first place.
We're trying to preserve a community here. Sometimes we collide with the financial world, but ultimately it's the *community* that's important. Suck just doesn't get it.
Slashdot Mirror
Don't forget that your OTP has to be generated with a perfectly-random source. That's not a trivial constraint.
Um, no. A 1024-bit key will take 6 to 7 million months to do with TWINKLE (that 500,000 years for y'all without calculators in your skulls), according to RSA Labs.
You're forgetting that vector processors are scads better at array-crunching that scalar (or even super-scalar) Alphas. The dual alpha could *do* it, but it would take much much longer. What's the vector length that Crays can deal with? I'd guess the alpha would be at *least* at factor of 32 slower; I wouldn't be surprised if the cray had 128-element vectors (==alpha 128 time slower).
I'd be willing to give him slack on the .doc thang if he pleads guilty to using a human editor. My experience is that it's real hard to find an editor who won't microsoft-up your text files when you send it to them to peruse. I had a WSJ guy send me a three-line question as a .doc attachment to an email---argh! Kudos to my Salon editors for respecting my .txt, although it *did* return to me with suspicious microsoft-isms...
Can I just take this back? Seems the glibc 2.0 problems are due to linker/loader problems (from reading Bugzilla) and it seems that getting the 2.0 linker to co-exist with the 2.1 linker may not be easy...
It was the result of a contest. The contest directors failed to enforce the constraint that the icon needed to fit within the mozilla color limitations. A vote was taken, and the winner looked *awful* when rendered in mozilla. I submitted a color-fixed version that looked better, but pr'ly i didn't yell loud enough, 'cuz no one took it.
So, then the windows DLLs *are* position independent, no? Which brings us back to the first question -- why are the linux binaries larger, and do symbol tables have *anything* to do with it?
No, that's Microsoft. From the above posts, it seems "shared" libraries on MS platforms have a fixed base address, set at build time. So you can "share" all you want... until some two DLLs you need decide they want the same piece of virtual address space. Then all hell breaks loose.
At least this is my impression from reading the above. I don't touch MS stuff, so I wouldn't know, really.
Yo, duh -- install glib 2.1 *in addition to* your current libraries. You can have more than one C library, y'know...
Yes, but as soon as some /. reader notices the GPL-mandated disclaimer, an article goes up saying "WOW! FooBar systems is running LINUX!!!" and then the tech press --- which increasingly uses /. to do its homework for them --- obligingly follows up with a "mainstream" article some short time later. The press releases aren't required, but the current dynamics make press inevitable.
I think that change must be facilitated if the improvements are going to push the boundaries of the possible. Easy changes aren't as interesting.
We agree to disagree. That's fine.
Right, but this is a far cry from claiming that the NSA can do factorizations in seconds.
It comes down to your own personal security criteria, but I'd rather trust a problem that bright people have worked on for centuries (factorization) than one which involves newer (and thus less well-understood) math. That's my personal take.
I agree. The best company-adoption-of-Linux story so far has got to be SGI, who's promised to port the groovy IRIX features to Linux. Iff this happens, then IRIX users might not feel they've been downgraded... but this is a big iff.
Even if there is only a few unices, hopefully there will always be many mail transport agents, mail readers, servers and such to limit the spread of a monoculture virus. Microsoft has seriously weakened its defenses by monopolizing its application market: everyone not only uses Windows OS, but reads mail with Outlook, distributes mail using Exchange, serves pages with IIS, etc.
Apache's dominance on the web is potentially a Bad Thing, for the same reasons.
Can you say more about what the benchmarks were?
I've read some very convincing papers asserting that various kernel critical paths (and in particular the system call mechanism) are much faster in Linux than in the AT&T-derived unices.
Of course, it may well be that the libraries and userland are faster on *BSD for what you're trying to do. Or it could be that the papers I read lie. I'm rather curious to know which it is.
I'd say the reason why the "bulk of the interest is in Linux" *is* in fact (at least partly) due to the GPL. The GPL means that companies who adopt linux have to be very public about it, because the GPL requires them to make their source & changes publically available. In contrast, a company could be running a *BSD kernel in their shiny embedded box and no one need know.
And market adoption is driven by "what the other guys are doing." Because the GPL forces publicity, it creates its own fad, and thus its own momentum. Not a technical reason, but a sheer dynamics quirk. A particularly successful meme.
I'm sorry, I'd call both of the linux.
For the same reason that linux running WINE is still linux.
Userland may change. The kernel remains the same.
Yes, I admit it. The pace of Linux development far outstrips that of *BSD development.
I consider that a *good* thing. You may disagree.
Let me see if I can improve your explanation.
d erek/certify/secret-key.protection.html
PGP and friends do rely on hard mathematical problems. Factoring large numbers is a problem that has been studied for hundred of years. Algorithm improvements *have* taken place. Factoring a 512-bit number used to be unthinkable; now it is (just barely) possible. 4096-bit numbers are many many orders of magnitude more difficult. So it is possible to extrapolate from the current rate of algorithm improvement and an estimate on how far ahead of "the rest of us" the NSA is to get an idea of how secure PGP is. Give the NSA ten years advance, and 4096 bit keys are still safe for a couple of decades (at least!).
And, no, it is *extremely* unlikely the NSA would *ever* be able to factor 4096-bit numbers in *seconds*. Admittedly no one's been able to prove a lower time bound on the integer factorization method, but this problem *has* been studied for centuries. Quantum computing *could* change the paradigm, but the amount of precision one needs for 4096 bits is quite daunting.
And the "near primes" that PGP uses have an astronomically small chance of being non-prime. Basically, the parameters of the algorithm are chosen so that it's about as likely that a person can randomly guess the symmetric key. And generally if the number is non-prime, PGP encryption just plain won't work. Which means that *no one* is able to decrypt your messages (not even you) --- a situation that would be quite obvious if by some miracle it occurred.
Please read
http://www-users.informatik.rwth-aachen.de/~sen
for more information.
No, the reason why Netscape/Mozilla is having such a hard time is because the source code is an impenetrable jungle, and its far from obvious how to make constructive contributions to it.
I downloaded the code and got as far as adding an "about:cananian" redirector, then drowned.
The core source code was never meant for community development, and the code was released to the community before it was usable.
Let me try again.
This wasn't a respect issue until E-Trade forced it to be. Red Hat said "the little guys are important, we'd like to reward them." E-Trade disagreed. Holy war ensued to ensure that Red Hat was able to do what they wanted to do in the first place.
Everyone sees this as a "we want money" thing. What we want is the opportunity to act according to our value system in the "real world". Although companies *may* give up the community as soon as they enter Wall Street, when a company (such as Red Hat) attempts to maintain its community orientation it is our responsibility as community members to support them -- or to call them on hypocrisy, if necessary. I have no problem with Corel (for example) keeping their money to themselves. But when an effort to benefit the community goes awry, we have a responsibility to make the faults known, so that future gift-givers don't make the same mistakes.
If you had a generous relative who'd been sending all your Christmas gifts to your next door neighbors by mistake, wouldn't you point out the error? Doesn't mean I'll complain if they don't give me a present next year. It's a *gift*.
As those inside know, it's not about money. It's about respect. We want the world-at-large to notice and adopt the *community values* that linux--and thus Red Hat--embodies. Thus, it was very important that the little guys not be shut out by E-Trade, because this movement is all about the little guys. This is a battle, and we can't stand to lose the ground.
Unfortunately, some of my rant was poorly-written and easily-misconstrued to be whining for my piece of the pie. I tried to be clearer in my follow-up piece; maybe I was successful. But Suck's way off track, here. The Red Hat IPO rewarded *precisely* the developers who Suck claimed would get ignored: the little guys who hacked some obscure feature of a random network driver or some such. It included them *because* we fought for it, and indeed that is the whole reason I pressed Salon to publish an article on the E-Trade fiasco in the first place.
We're trying to preserve a community here. Sometimes we collide with the financial world, but ultimately it's the *community* that's important. Suck just doesn't get it.
The paper gives a very complete description of the machine if you read carefully and think a bit.
Can you remember the name of the play? I'd
like to try to find & read it...
In particular, check out Rijndael. A real sweet algorithm: fast, secure, portable. A very very nice design.
And completely developed outside the US.