Are programming challenges applicable to the real world? Of course not. Ninety-five percent of the real world isn't applicable to the real world; how do you expect anything in academia to be more than five percent applicable, if the Real World is only five percent applicable?
Stop viewing everything you do in college as preparation for the Real World. The Real World is out there, and no matter how well-prepared you think you are from college, once you get out here you'll realize that you don't know jack. That's okay. What you should be learning in college is how to learn, quickly and accurately. Do programming competitions help show future employers you can think on your feet and apply new knowledges quickly to old problems? Maybe. But like I just said, stop viewing everything you do in college as preparation for the Real World.
Sometimes, you want to do things just because they're fun. With a little camraderie, espirit de corps and good code-fu, programming challenges can be a hell of a lot of fun.
The only regret I have about college is that I took some things too seriously, because I was sure they were all about the Real World, and didn't take things seriously enough, because I was sure they were wastes of time. I passed on an ACM Challenge one year because I wanted to study more for a class I was in. Now, seven years later, I don't even remember what that class was.
I do remember the ACM Challenges I participated in, though. And I wish I'd participated in more of them.
If I recall my college Behavioral Psych courses correctly, the human eye maxes out at about 7 million different hues--considerably less than the 16 million shades of 24-bit color.
... A heavily-loaded dual P3/800, 1G RAM, which was at the time doing other number-crunching in the background.
If you think the C version is faster, I must suspect that you're the one falsifying scores--because you've got at least two extra pointer invocations which the C++ code doesn't, due to its aggressive inlining.
Insofar as what sort those two sort functions actually use--according to spec, qsort() is always a quicksort. The STL sort()... who cares? Implementation detail. I believe it's a tuned mergesort, but I could be wrong--the spec says it's O(n logn) for the best- and average cases, O(n**2) in an extremely unlikely worst-case.
If you need a better worst-case, stable_sort() is available. Guaranteed worst case of O(n logn logn) and best-case of O(n logn) for any system that's got RAM to spare.
Of course, you could've found this out for yourself if you'd bothered to spend 30 seconds checking out a spec.
... how nasty pointer errors can be in C. I wrote that purely off the top of my head, and didn't ever bother to think that the return x < y should be return *x < *y instead.
Simple error to make; anyone who's written more than 100 lines of C has likely done the exact same thing, more often than they'd care to remember.
On the other hand, the C++ code works just fine, and exactly as intended.
I've been using C++ since 1989. I'm still learning more about C++ today.
It always amazes me at how people who acknowledge they don't know C++/STL (as you said, "I have never used it") know so much more about it than those of us who've been using it since the mid-90s, and who still discover more neat things about it on a continuing basis.
That said: C++ makes it easier to produce bloatware.
Two answers:
Yeah, so?
Name me one advance in computer science that doesn't also carry with it the possibility of using the advance stupidly. Yes, if you deliberately do stupid things with C++, you'll get code bloat. But if you make the language impossible to do stupid things in, you'll also make it impossible to do clever hacks in the language. If I want a language like that, I'll use Java, thanks.
Have you seen what that `bloat' does?
Most of the time when people blame code bloat they're really blaming templates. Tell you what: look at the vector template and find out just how brilliantly sweet it is. Now hand-code it in C, such that it gives you the exact same level of sweetness, speed, and safety. Dollars to donuts says your C code is more bloated.
... and it has the added disadvantage of objects.
Spoken like someone who never made it past the introduction of Stroustrup's The C++ Programming Language. Repeat after me: C++ is not an object-oriented language. C++ never was an object-oriented language. C++ never will be an object-oriented language. C++ supports OOP, but that doesn't make it an OOPL. C++ is, more precisely, a multiparadigm language. You want generic programming? C++ has the tools. You want functional programming? C++ has the tools (awkwardly, but they're there). You want OOP? C++ has the tools. You want procedural/imperative programming? C++ has the tools.
Whatever you want, C++ has the tools.
Hey, at least its not Java which forces OOP on you instead of giving you an option
My harsh words about Java (above) were, as I hope the Java community will understand, meant as a gentle jab from one diehard C++ hacker--not as a misinformed flame like you're spewing here. Of course Java gives you an option. If you don't want OOP, don't use Java. Use Ada95 or Python instead, both of which support non-OOP paradigms and which can compile down to Java bytecodes. Java, like Smalltalk, is a purely OO language. Saying that Java sucks because it forces you to write OO code is... well, really foolish. Java doesn't force you to write OO code; you force yourself to write OO code by committing to Java as a platform. Java is a tool in the toolbox. A hammer doesn't force you to treat everything like a nail; but if you choose to pick up the hammer, the only person to blame is you if you needed to pick up the screwdriver instead.
I can't really talk about the STL
... Why not? Your utter ignorance didn't stop you from talking about C++ or Java.
... but from the coders I do know who have used it
... And are these coders competent craftsmen, skilled in the ways of the STL? Or are they incompetent two-bit fly-by-nighters?
it is a sad sad mechanism for making your code slower and harder to debug and your executables larger
Bullshit. Look at the following code:
/* C version: sorting random 1M-element array */
int compare(const void* first, const void *second) {
int *x = (int*) first;
int *y = (int*) second;
return x < y; }
int main(void) {
int array[1048576];
qsort(array, 1048576, sizeof(int), compare);
return 0; }
// C++ version
int main(void) {
int array[1048576];
sort(array, array+ 1048576);
return 0; }
[rjhansen@numbers cpp]$ time./c_version
real 0m1.034s user 0m0.960s sys 0m0.070s
[rjhansen@numbers cpp]$ time./cpp_version
real 0m0.719s user 0m0.720s sys 0m0.010s
... Want to repeat that bit again about how STL causes your code to run slower and be harder to debug?
You obviously have no idea how old (or new) my mobo is. Yes, it supports 4x AGP. Yes, it supports everything you mentioned. Please check out the specs for the Apollo dual-proc mobos before you tell me what is, or isn't, the problem. Yes, I have RTFM. Yes, I have looked at my BIOS settings. Yes, the problems still persist.
Yes, I did take it back for a replacement. Replacement does the exact same things. It's not a "weird BIOS issue", given that in the pursuit of solving this problem I've disabled just about everything that could be doing it--disabled AGP 4x, gone from 256M window to 16M, etc. Problem still persists.
I've got a dual-proc P3/800 on my desk right now, a half-gig of RAM on an Apollo mobo. It has a single PCI card (a 3Com 905B Cyclone) and a GeForce 4 on the AGP slot. Now, what's my problem?
Everything about the damn GeForce.
First, it was having constant conflicts with Something-Or-Other during POST--I'd get a really annoying system beep and no video output, period. Yanked my SoundBlaster AWE32 and presto, it boots. Weird. Why was the GeForce 4 conflicting with my SB?
Now it works reasonably well, except that I'm forced to use my on-board AC97 audio (which sounds like ass, and esd really doesn't like it). Reasonably well, except for the occasional spontaneous reboot... which occurs for reasons I haven't been able to track down yet.
In Win2000 it's the same story--except that when I connect to the 'Net via my external modem (COM1), I'll randomly get a BSOD or a spontaneous reboot.
Why in the billion names of JR "Bob" Dobbs the GeForce 4 causes so many hardware conflicts, I have absolutely no idea.
When it's running, though, it's a pretty sweet board.
By comparison, my last card was a Voodoo3. Nice, simple AGP card; I plugged it in, it worked, never conflicted with anything.
I meant to say that this is the standard functional formulation of the problem.
I still disagree with you.:) Most of the time when I want to write functional code, I write it in Scheme--so whenever I write functional code I have a very strong knee-jerk reaction to doing things with tail recursion, which is the standard way of doing it in Scheme.;)
I will grant that the two-liner I wrote was not the most obviously Pythonish in style, though. Just please keep in mind where I come from, functionally speaking.
The correct functional formulation of this problem is
Please find me where the code I posted is either incorrect (i.e., fails to give a correct result) or less than functional.:) I wrote it the way I wrote it because it's a terse, tail-recursive two-liner--admittedly, the tail recursion isn't the conventional Python style, but the fact that it's tail recursive is immediately evident. The code was meant to demonstrate the ease with which you can do functional programming in Python, not as a "you should do functional programming just like this".
The reduce version is considerably slower than either of the two recursive versions, by the by, probably due to the time it takes for import to execute.
The recursive version, for n = 998: real 0m0.079s user 0m0.060s sys 0m0.020s
The reduce version, for n = 998: real 0m0.108s user 0m0.060s sys 0m0.020s
The syntax is clean and easy for us mere humans to read. For instance, compare the two following bits of code (one in C++, the other in Python): #include <iostream>
using std::cout; using std::endl;
int main(int argc, char *argv[]) {
unsigned long int fact = 1, x = 1;
for (x = 1 ; x < 6 ; x++) fact *= x;
cout << x-- << " factorial = " << fact << endl;
return fact; }
... So far it's pretty obvious to C++ programmers what you're doing, but to anyone who doesn't know C++, even an example this simple borders on meaningless gibberish. What does "#include" mean? What do those `::'s mean in the using statement? What's cout and why do I care? What's char *argv[], and why do some people write it as char **argv?
The Python version of this same program, though, is beautifully simple to read: def factorial(num):
fact = 1
for x in range(1, num + 1):
fact = fact * x
print fact
return fact
if __name__=='__main__':
factorial(5)
The Python code, while similar in lines of code, is enormously clearer. If you're willing to write functional Python code, it's even better: def factorial(num, passfwd):
if num == 0: print passfwd
else: factorial(num - 1, passfwd * num)
if __name__=='__main__':
factorial(5, 1)
Multiparadigmatic.
As a C++ coder, you're familiar with C++'s Every Paradigm And The Kitchen Sink approach. C++ lets you use generic programming, procedural programming, OO programming--whatever you need to get the job done. Python is the exact same. The OO syntax is clean, terse and readable; operator overloading is straightforward; and as my above example shows, functional programming is easy within Python.
Unlike some other interpreted languages (coughcoughJavacough) which coerce you into solving every problem via their One True Way (OO, usually), Python lets you solve problems the way you want to solve them.
Crossplatform.
Python might not run everywhere, but it runs everywhere I'm interested in being. It's possible to write crossplatform code with C/C++ (especially if you write code intelligently), but there are enough hardware gotchas to make crossplatform code difficult.
Fun.
Python is just plain fun.:)
Extensible and Embeddable.
Python can easily be extended via C/C++ code, and it can easily be embedded within C/C++ code as a scripting language. This can often make for extremely impressive rapid application development; write the app in Python, then profile it and widen out the bottlenecks by writing them in native code. Doing this, I've managed to get performance approaching that of native code without anywhere near the headaches of writing the entire thing in native code.
Lots of libraries.
Much like Perl, the available libraries for Python are mind-boggling. Check 'em out.:)
Easy GUI programming.
PyQt, PyKDE, PyGTK, PyGNOME, and a Win32 Python modules are all actively maintained. There are even Python GUI libraries for BeOS.
... I use C++ a fair bit, and I love the language. C++ is probably my favorite "mainstream" language, even if it does have a learning curve like the Matterhorn. But even though I love C++, I love Python just as much.
Python is not a replacement for C/C++. It wasn't meant to be, either. But as an adjunct to C/C++, Python is magnificent.:)
So the keys are generated using a pseudo-random number generator, which makes them quite guessable.
Not necessarily. ANSI X9.17 is both a specification for a PRNG and a family of PRNGs. The ANSI X9.17 generators I've used (and coded) in the past have passed every test for statistical randomness I've thrown at them, for datasets ranging from 16 bytes to 16Mb.
We do have good PRNGs. The biggest problem is that people don't use them, instead trusting in their own "proprietary and special" PRNG.
Ummmm... comparing asymmetric encryption to symmetric encryption (of which a one-time pad is a subset) with key-lengths is like comparing apples to oranges.
This much is right.
In asymmetric encryption, your security is in your keyspace... every bit doubles the time to search the keyspace.
This much is nowhere near right. According to our best estimates at the present time, it'll take on the order of 2**80 operations to factor out RSA-1024. It'll take on the order of 2**128 operations to factor out RSA-3072.
Adding two thousand bits doesn't increase the difficulty by 2**2048... only 2**48. Asymmetric crypto does not double in difficulty with each added bit.
In symmetric encryption, security is all about the keys; symmetric encryption is so easy to do that you can try millions of keys a second, as opposed to thousands or hundreds, so you HAVE to have a big keyspace.
This is not correct. In fact, it's downright astonishingly wrong. The problem is you're assuming symmetric and conventional, non-ECC asymmetric keyspaces are both flat (they're not). But if they were flat, then asymmetric crypto would have a keyspace multiple orders of magnitude larger. Which is the opposite of what you're asserting here.
Conventional, non-ECC asymmetric keys are so huge because most of the keys are weak. Let's compare DES to RSA. Is 0xFA810DD0 a legitimate 64-bit DES key? Yes. (Note: DES only uses 56 of those bits for key material; the other 8 are used for parity.) Is 0xFA810DD0 a legitimate 64-bit RSA key? No. Why? Because 0xFA810DD0 is an even number, which makes it much, much easier to factor.
Conventional, non-ECC asymmetric keyspaces are so huge partially (not exclusively) because most of the keys in that keyspace are unusable. Symmetric keyspaces are so small partially (not exclusively) because most of the keys in that keyspace are usable.
A keyspace in which all (or the overwhelming majority of) keys possess equal strength is called a "flat" keyspace. A keyspace in which some keys are stronger or weaker is... well, non-flat.
But, most symmetric encryption algorithms allow you to get it partly right; if the key is partly right, you get a partly decoded message, so the search algorithm is linear instead of exponential.
This is so wrong that it staggers the imagination. Claude Shannon established some principles back in the 1940s which still guide cipher development today. One of these is called the avalanche effect. The idea behind the avalanche effect is that a single one-bit error, anywhere in the enciphering/deciphering process, will affect the output of half the bits in the entire e/d process.
Go ahead. Use Blowfish with a 40-bit key. (There are lots of Blowfish implementations out there; if you want one, email me and I'll send you one.) Encrypt it with one 40-bit key, and then decrypt it with a key that's only one bit different. You'll get absolute, total, gibberish. You'll get gibberish because Blowfish is a well-designed cipher and avalanches properly.
But wait--it gets even worse. Only a chump runs a cipher in electronic codebook mode. Usually, ciphers are run in a block-chaining mode, where every subsequent block gets XORed with the prior block. So if you have a one-bit error in your process, that will affect half the bits of the block... which then create errors in half the bits of the next block... which avalanche... which propagate their error forwards, on and on and on... etcetera.
You get the idea.
(All of the above information can be found in either Bruce Schneier's Applied Cryptography, 2nd Ed or Menezes, Oorschot and Vanstone's Handbook of Applied Cryptography.)
May want to learn about 2.96 before you bash it.
on
Linux Tuning Tricks?
·
· Score: 2
GCC 2.96-RH fails with C code in one and only one condition: when it's not ANSI-conformant C. GCC 2.96-RH is much more restrictive than GCC 2.95.
GCC 2.96-RH is worlds better than 2.95 when it comes to generating C++ code. With GCC 2.96-RH and STLport-4.5.3, I was happy as a clam. GCC 2.95's C++ support was anemic, nonstandards-compliant, and just generally sucked for any sort of very serious usage.
When I was recompiling tons of applications to work with GCC 2.96-RH, every "compiler error" that I found--every single one--was the result of a programmer doing something that wasn't ANSI/ISO and made an assumption that "well, since GCC 2.95 didn't complain about this, it's okay." I don't blame GCC 2.96-RH for being more standards-conformant; I blame developers for playing fast and loose with the language spec.
Re:so, you people want to build a gun eh?
on
Homemade Gauss Gun
·
· Score: 1, Flamebait
400km of thin copper wire is an awful lot. Try, "the width of northern Missouri".
Wall sockets are either 110V or 220V (sometimes listed as 120V/240V). Nowhere near five thousand. Not even in Europe, where they use much higher voltages, is a wall socket five thousand volts.
With a muzzle velocity of 2000m/s and a muzzle of only 3m, you can be damn sure that the payload would shatter and deform under the hundreds of thousands of G-forces.
You're also neglecting the fact that at 2000m/s, air has the consistency of concrete. The payload wouldn't even get out of the muzzle. It would explode in the muzzle, you'd get a burst barrel, and you'd have 400km of fragmented copper wire bouncing around and killing anyone who was standing too close.
At 2km/s, the concrete wall wouldn't just be breached. It would explode. Everyone around would be dead. There would also be liquified metal (from the payload) spraying everywhere, setting fires.
The sheer amount of energy required to launch a payload at 2km/s from such a short barrel would require a current far in excess of anything THIN copper wire could bear. Not only would the barrel burst and copper go flying everywhere, the copper would be molten.
The next time you decide to spin a totally BS yarn, please at least check to make sure the physics works.
Yes, I'm sure it's better than (especially) C and C++, but nothing compares to the module system of SML.
This may be the source of some of our disagreement; you're an academic, and I'm in the trenches.:) I can't talk intelligently about SML, seeing as how I've never used it (although if you could point me towards a compiler and a good learning reference, I'd like to look at it). What I can talk intelligently about is how utterly miserable C is for large-scale software projects.
Given that most large-scale software projects now are written in C, or a similarly low-level language, I consider pretty much any sane language choice that moves us to a higher level of abstraction to be a Good Thing. Whether we use LISP, Scheme, Python, C++, Java--I don't care all that much, really, as long as it's a step up from C.
So from my perspective, Python is a brilliant choice for software development. Manna from heaven, even.:) But I do acknowledge that there are probably more elegant and clean languages than Python.
I dunno what parentheses have to do with elegance, but I can tell you that LISP is not "as good as it gets" as far as elegant functional languages go.
Actually, I was using LISP as an example of a functional language in which the syntax of the language (the Lots of Idiotic Stupid Parenthesis) wind up to some degree hobbling the utility of the language. Once I get a function working in LISP, the first thing I do is go through it and remove as many parenthesis as I can in the hopes of improving readability and maintainability.
Continuances, continuations, collectors, whatever you want to call them this week.:) Diehard Schemers and LISPers tend to call them collectors, after the way they're called in The Little LISPer and The Little Schemer, other people call them continuations, and in Python I've seen them called continuances. Go figure.:)
I wouldn't be anywhere near so quick to decry Python as "just" a scripting language, by the by. I've found that with a little care I can get Python's speed to just about equal native code. I write the entire app in Python, then profile the code to see the bottlenecks. I open the bottlenecks up algorithmically when I can, and if they're still performance limiters I implement them in C++. I've been very pleased with the results so far.
Insofar as "its semantics... make it harder to develop large programs", I can only believe you've never used Python for a large program. Compared to C or C++, Python is a gift from above.
I have a very warm spot in my heart for Scheme. But I don't feel the biggest advantage of functional programming languages comes from speed of execution (although it competes with C/C++), or from elegance (LISP = Lots of Idiotic Stupid Parenthesis), or from scalability. The big strength of functional programming comes from the way it forces you to think about the problem--it forces you to think about the problem in an extremely formal way, as opposed to the ad-hockery that passes for C. There tend to be a lot fewer bugs in my Scheme code than my C++ code, and hence tend to be a lot more reliable. Mostly, I think, because of the impressed formalism.
Learn it in Python. Really. Python 2.2 offers a whole host of lovely functional-programming features. Continuances, even.:)
I prefer to write functional code in LISP or Scheme, but I won't sneer at someone who uses Python functionally. It might lessen the learning curve for you, let you experiment around with functional programming, and then use what you learn there in Scheme, LISP or Ocaml.
The version I heard was that for a particularly esoteric set of multiple inheritances, GCC would produce incorrect code. I haven't verified this myself, though, so I can't contradict you at all.
GCC 3.0 may have been out for almost a year, but keep in mind that 3.0 is only almost usable. When I tried 3.0, soon after it was released, my average compile time increased by a factor of five. Compiles that used to be able to be done over a lunch break now had to be postponed until the end of the day and run overnight.
Add into that the fact that GCC 3.0 broke multiple inheritance (ask the KDE people how they liked that--you can't build KDE with GCC 3.0), and GCC 3.0 was never a realistic option.
There's a reason why not one single distro ships with 3.0 as its default compiler.
G++'s STL blows. It's so substandard that it borders on the unusable. Take the vector<> as an example. One of the big wins with vector<> is that it can be used as a bounds-checked array. All you have to do is use the appropriate method--or derive a class off of vector<> and override operator[] appropriately--and stack smashes are a thing of the past.
Whoops. G++'s STL doesn't support the vector.at() method, which is necessary for bounds-checking.
There are all sorts of substandard crap in the standard G++ STL. It's gotten to the point where I've flat-out given up on G++'s STL, and am using STLport 4.5.3 instead.
If you want to improve my C++ experience, pay attention to the STL.
There's a sort of implicit warranty whenever you sell something: namely, you're warranting that it's useful for a particular purpose (said purpose being one that you, the seller, reasonably believe the buyer intends). If I sell you a car and I neglect to tell you that it'll blow up spectacularly if you happen to turn the engine over before fastening your seatbelt, well, that car's not fit to drive--hence, I (the seller) am in a whole stewpot full of trouble.
When you purchase software, there's an automatic warranty involved. Namely, that the software doesn't suck. That it's not going to be an open invitation to haX0rs. That using it isn't going to expose you to enormous risk, unless the seller has first advised you of specific enormous risk and you choose to buy it anyway.
When you license software... well, that's not a sale, is it? And hence, the legal protections that you get when you buy things don't apply to you. I can count on one hand and have fingers leftover all the times I've seen shoddy software be held accountable in court.
So this push to software-liability law is more of a push to make software a sold good, not a licensed one. The theory being, if I plunk down $200 for Windows XP, it shouldn't have a UPnP back-door in it. Software-liability laws would permit affected users to sue manufacturers to recover lost damages.
However, common law says that if you pay a nickel for something and it breaks, you can't make twenty million bucks off a lawsuit over it. Twenty bucks, maybe, twenty million, no way. There is an implicit limitation on the assumption of risk, and this implicit limitation is related to the price paid.
If I pay Red Hat $50 for Red Hat Linux and there's a horrible bug that makes my Linux box an inviting target for 1337 haX0rz, then Red Hat's liability is a factor of the $50 I paid them.
If I pay you $0 for a piece of GPLed software you wrote, and there's a horrible bug, your liability is a factor of the $0 I paid you.
Err... wait. I didn't pay you. I got something for nothing--I literally received a good at no price whatsoever above the price of media. The courts would not look favorably upon me suing you for $20 million because you gave me something, for free, out of the goodness of your heart, and made it clear to me that it was a work in progress and might not work as I expect it to.
Simply put, WinPT's UI is not up to the level that corporate customers expect. I expect that, provided WinPT development keeps going and doesn't stall, in a year or eighteen months it'll be comparable to the PGP UI. But for right now it just isn't there.
If you think polish doesn't matter, I suggest you search the Web for "Why Johnny Can't Encrypt", which is a usability study of PGP. Even with a modern, well-polished UI, PGP's usability by average users is awful. Really terrible.
If it doesn't integrate seamlessly with the OS, people won't use it. It doesn't matter how simple or gentle the learning curve is; people will just choose to not learn instead.
5% of computer users are geeks, and that may be optimistic. The remaining 95% are the Real Users. Live in fear and terror of them.:)
For the time being, GnuPG has one enormous shortcoming in the corporate world. Namely, it's possible for individual users to send traffic that the corporation itself can't eavesdrop on. This may sound like a nonissue, or even an offensive one, but the fact is that if you're sending communications on the company dime, using company equipment, the company does have a right to make sure you're not sending corporate secrets to the competition.
The parameters of how they may exercise this right are matters of considerable debate. E.g., must the company give notice that communications are being monitored? Must the company stop monitoring if it's an email or a phone call to your spouse? Etc. There's a lot of room for debate on that issue, but the basic fact remains that corporations need some way to make sure their secrets aren't being sent out to their big competitors.
In the crypto world, there are two major ways of doing this. One is key escrow (a technology which appears to have finally died the ignominious death it deserved). The other is the Additional Decryption Key (ADK). The difference between the two of them is that the ADK is a request to encrypt to an additional (corporate-controlled) key, and escrow requires the private key be held by some "trusted party", just in case.
Escrow technology is a big can of worms, and ADKs are smaller cans of worms. They're unsuitable for private users because they wind up being security risks. And, in fact, PGP's most critical vulnerability since the 2.6.x days came from an ADK bug.
However, corporations view the risks of not having ADKs to be much greater than the risks of having ADKs.
Corporations demand either escrow or ADK. GnuPG supports neither, and Werner Koch has said that GnuPG will never support them. He has his reasons for saying that, and his reasoning is pretty sound. But, then again, so is the corporate logic for insisting on escrow/ADKs.
Moreover, GnuPG doesn't have any pretty GUIs. WinPT is making a good attempt for Win32, and GNU has their own (apparently stalled) GTK+ front-end, but neither one is anywhere near done. In any business setting, 95% of the people will be stark raving terrified of the prospect of using a command-line app. For this 95%, PGP is the only option. There simply isn't anything else.
This is sort of a shame, given that NAI's reputation for being an attentive, responsive vendor is... well, pretty pathetic. But for time being, NAI--and PGP--is the only game in town on the corporate front.
For me, personally, I use GnuPG and love it. I wholeheartedly recommend people use it. But I simply can't see it taking off in the enterprise for the reasons listed above.
Slashdot Mirror
Are programming challenges applicable to the real world? Of course not. Ninety-five percent of the real world isn't applicable to the real world; how do you expect anything in academia to be more than five percent applicable, if the Real World is only five percent applicable?
Stop viewing everything you do in college as preparation for the Real World. The Real World is out there, and no matter how well-prepared you think you are from college, once you get out here you'll realize that you don't know jack. That's okay. What you should be learning in college is how to learn, quickly and accurately. Do programming competitions help show future employers you can think on your feet and apply new knowledges quickly to old problems? Maybe. But like I just said, stop viewing everything you do in college as preparation for the Real World.
Sometimes, you want to do things just because they're fun. With a little camraderie, espirit de corps and good code-fu, programming challenges can be a hell of a lot of fun.
The only regret I have about college is that I took some things too seriously, because I was sure they were all about the Real World, and didn't take things seriously enough, because I was sure they were wastes of time. I passed on an ACM Challenge one year because I wanted to study more for a class I was in. Now, seven years later, I don't even remember what that class was.
I do remember the ACM Challenges I participated in, though. And I wish I'd participated in more of them.
If I recall my college Behavioral Psych courses correctly, the human eye maxes out at about 7 million different hues--considerably less than the 16 million shades of 24-bit color.
:)
Sorry.
What are you on?
... A heavily-loaded dual P3/800, 1G RAM, which was at the time doing other number-crunching in the background.
If you think the C version is faster, I must suspect that you're the one falsifying scores--because you've got at least two extra pointer invocations which the C++ code doesn't, due to its aggressive inlining.
Insofar as what sort those two sort functions actually use--according to spec, qsort() is always a quicksort. The STL sort()... who cares? Implementation detail. I believe it's a tuned mergesort, but I could be wrong--the spec says it's O(n logn) for the best- and average cases, O(n**2) in an extremely unlikely worst-case.
If you need a better worst-case, stable_sort() is available. Guaranteed worst case of O(n logn logn) and best-case of O(n logn) for any system that's got RAM to spare.
Of course, you could've found this out for yourself if you'd bothered to spend 30 seconds checking out a spec.
... how nasty pointer errors can be in C. I wrote that purely off the top of my head, and didn't ever bother to think that the return x < y should be return *x < *y instead.
Simple error to make; anyone who's written more than 100 lines of C has likely done the exact same thing, more often than they'd care to remember.
On the other hand, the C++ code works just fine, and exactly as intended.
It always amazes me at how people who acknowledge they don't know C++/STL (as you said, "I have never used it") know so much more about it than those of us who've been using it since the mid-90s, and who still discover more neat things about it on a continuing basis.
That said: C++ makes it easier to produce bloatware.
Two answers:
Name me one advance in computer science that doesn't also carry with it the possibility of using the advance stupidly. Yes, if you deliberately do stupid things with C++, you'll get code bloat. But if you make the language impossible to do stupid things in, you'll also make it impossible to do clever hacks in the language. If I want a language like that, I'll use Java, thanks.
Most of the time when people blame code bloat they're really blaming templates. Tell you what: look at the vector template and find out just how brilliantly sweet it is. Now hand-code it in C, such that it gives you the exact same level of sweetness, speed, and safety. Dollars to donuts says your C code is more bloated.
Spoken like someone who never made it past the introduction of Stroustrup's The C++ Programming Language. Repeat after me: C++ is not an object-oriented language. C++ never was an object-oriented language. C++ never will be an object-oriented language. C++ supports OOP, but that doesn't make it an OOPL. C++ is, more precisely, a multiparadigm language. You want generic programming? C++ has the tools. You want functional programming? C++ has the tools (awkwardly, but they're there). You want OOP? C++ has the tools. You want procedural/imperative programming? C++ has the tools.
Whatever you want, C++ has the tools.
Hey, at least its not Java which forces OOP on you instead of giving you an option
My harsh words about Java (above) were, as I hope the Java community will understand, meant as a gentle jab from one diehard C++ hacker--not as a misinformed flame like you're spewing here. Of course Java gives you an option. If you don't want OOP, don't use Java. Use Ada95 or Python instead, both of which support non-OOP paradigms and which can compile down to Java bytecodes. Java, like Smalltalk, is a purely OO language. Saying that Java sucks because it forces you to write OO code is... well, really foolish. Java doesn't force you to write OO code; you force yourself to write OO code by committing to Java as a platform. Java is a tool in the toolbox. A hammer doesn't force you to treat everything like a nail; but if you choose to pick up the hammer, the only person to blame is you if you needed to pick up the screwdriver instead.
I can't really talk about the STL
... Why not? Your utter ignorance didn't stop you from talking about C++ or Java.
... And are these coders competent craftsmen, skilled in the ways of the STL? Or are they incompetent two-bit fly-by-nighters?
it is a sad sad mechanism for making your code slower and harder to debug and your executables larger
Bullshit. Look at the following code:
int compare(const void* first, const void *second)
{
int *x = (int*) first;
int *y = (int*) second;
return x < y;
}
int main(void)
{
int array[1048576];
qsort(array, 1048576, sizeof(int), compare);
return 0;
}
int main(void)
{
int array[1048576];
sort(array, array+ 1048576);
return 0;
}
[rjhansen@numbers cpp]$ time
real 0m1.034s
user 0m0.960s
sys 0m0.070s
[rjhansen@numbers cpp]$ time
real 0m0.719s
user 0m0.720s
sys 0m0.010s
... Want to repeat that bit again about how STL causes your code to run slower and be harder to debug?
You obviously have no idea how old (or new) my mobo is. Yes, it supports 4x AGP. Yes, it supports everything you mentioned. Please check out the specs for the Apollo dual-proc mobos before you tell me what is, or isn't, the problem. Yes, I have RTFM. Yes, I have looked at my BIOS settings. Yes, the problems still persist.
Yes, I did take it back for a replacement. Replacement does the exact same things. It's not a "weird BIOS issue", given that in the pursuit of solving this problem I've disabled just about everything that could be doing it--disabled AGP 4x, gone from 256M window to 16M, etc. Problem still persists.
I've got a dual-proc P3/800 on my desk right now, a half-gig of RAM on an Apollo mobo. It has a single PCI card (a 3Com 905B Cyclone) and a GeForce 4 on the AGP slot. Now, what's my problem?
Everything about the damn GeForce.
First, it was having constant conflicts with Something-Or-Other during POST--I'd get a really annoying system beep and no video output, period. Yanked my SoundBlaster AWE32 and presto, it boots. Weird. Why was the GeForce 4 conflicting with my SB?
Now it works reasonably well, except that I'm forced to use my on-board AC97 audio (which sounds like ass, and esd really doesn't like it). Reasonably well, except for the occasional spontaneous reboot... which occurs for reasons I haven't been able to track down yet.
In Win2000 it's the same story--except that when I connect to the 'Net via my external modem (COM1), I'll randomly get a BSOD or a spontaneous reboot.
Why in the billion names of JR "Bob" Dobbs the GeForce 4 causes so many hardware conflicts, I have absolutely no idea.
When it's running, though, it's a pretty sweet board.
By comparison, my last card was a Voodoo3. Nice, simple AGP card; I plugged it in, it worked, never conflicted with anything.
I meant to say that this is the standard functional formulation of the problem.
:) Most of the time when I want to write functional code, I write it in Scheme--so whenever I write functional code I have a very strong knee-jerk reaction to doing things with tail recursion, which is the standard way of doing it in Scheme. ;)
:)
I still disagree with you.
I will grant that the two-liner I wrote was not the most obviously Pythonish in style, though. Just please keep in mind where I come from, functionally speaking.
Python doesn't optimise the tail recursion away
Feh. It should. Tail recursion is elegant.
The correct functional formulation of this problem is
:) I wrote it the way I wrote it because it's a terse, tail-recursive two-liner--admittedly, the tail recursion isn't the conventional Python style, but the fact that it's tail recursive is immediately evident. The code was meant to demonstrate the ease with which you can do functional programming in Python, not as a "you should do functional programming just like this".
Please find me where the code I posted is either incorrect (i.e., fails to give a correct result) or less than functional.
The reduce version is considerably slower than either of the two recursive versions, by the by, probably due to the time it takes for import to execute.
The recursive version, for n = 998:
real 0m0.079s
user 0m0.060s
sys 0m0.020s
The reduce version, for n = 998:
real 0m0.108s
user 0m0.060s
sys 0m0.020s
The syntax is clean and easy for us mere humans to read. For instance, compare the two following bits of code (one in C++, the other in Python):
#include <iostream>
using std::cout;
using std::endl;
int main(int argc, char *argv[])
{
unsigned long int fact = 1, x = 1;
for (x = 1 ; x < 6 ; x++) fact *= x;
cout << x-- << " factorial = " << fact << endl;
return fact;
}
... So far it's pretty obvious to C++ programmers what you're doing, but to anyone who doesn't know C++, even an example this simple borders on meaningless gibberish. What does "#include" mean? What do those `::'s mean in the using statement? What's cout and why do I care? What's char *argv[], and why do some people write it as char **argv?
The Python version of this same program, though, is beautifully simple to read:
def factorial(num):
fact = 1
for x in range(1, num + 1):
fact = fact * x
print fact
return fact
if __name__=='__main__':
factorial(5)
The Python code, while similar in lines of code, is enormously clearer. If you're willing to write functional Python code, it's even better:
def factorial(num, passfwd):
if num == 0: print passfwd
else: factorial(num - 1, passfwd * num)
if __name__=='__main__':
factorial(5, 1)
As a C++ coder, you're familiar with C++'s Every Paradigm And The Kitchen Sink approach. C++ lets you use generic programming, procedural programming, OO programming--whatever you need to get the job done. Python is the exact same. The OO syntax is clean, terse and readable; operator overloading is straightforward; and as my above example shows, functional programming is easy within Python.
Unlike some other interpreted languages (coughcoughJavacough) which coerce you into solving every problem via their One True Way (OO, usually), Python lets you solve problems the way you want to solve them.
Python might not run everywhere, but it runs everywhere I'm interested in being. It's possible to write crossplatform code with C/C++ (especially if you write code intelligently), but there are enough hardware gotchas to make crossplatform code difficult.
Python is just plain fun.
Python can easily be extended via C/C++ code, and it can easily be embedded within C/C++ code as a scripting language. This can often make for extremely impressive rapid application development; write the app in Python, then profile it and widen out the bottlenecks by writing them in native code. Doing this, I've managed to get performance approaching that of native code without anywhere near the headaches of writing the entire thing in native code.
Much like Perl, the available libraries for Python are mind-boggling. Check 'em out.
PyQt, PyKDE, PyGTK, PyGNOME, and a Win32 Python modules are all actively maintained. There are even Python GUI libraries for BeOS.
... I use C++ a fair bit, and I love the language. C++ is probably my favorite "mainstream" language, even if it does have a learning curve like the Matterhorn. But even though I love C++, I love Python just as much.
Python is not a replacement for C/C++. It wasn't meant to be, either. But as an adjunct to C/C++, Python is magnificent.
The NFS doesn't care how big or how small the factors are--it just finds them. If 113 is a factor, the NFS will find it. :)
So the keys are generated using a pseudo-random number generator, which makes them quite guessable.
Not necessarily. ANSI X9.17 is both a specification for a PRNG and a family of PRNGs. The ANSI X9.17 generators I've used (and coded) in the past have passed every test for statistical randomness I've thrown at them, for datasets ranging from 16 bytes to 16Mb.
We do have good PRNGs. The biggest problem is that people don't use them, instead trusting in their own "proprietary and special" PRNG.
Ummmm... comparing asymmetric encryption to symmetric encryption (of which a one-time pad is a subset) with key-lengths is like comparing apples to oranges.
This much is right.
In asymmetric encryption, your security is in your keyspace... every bit doubles the time to search the keyspace.
This much is nowhere near right. According to our best estimates at the present time, it'll take on the order of 2**80 operations to factor out RSA-1024. It'll take on the order of 2**128 operations to factor out RSA-3072.
Adding two thousand bits doesn't increase the difficulty by 2**2048... only 2**48. Asymmetric crypto does not double in difficulty with each added bit.
In symmetric encryption, security is all about the keys; symmetric encryption is so easy to do that you can try millions of keys a second, as opposed to thousands or hundreds, so you HAVE to have a big keyspace.
This is not correct. In fact, it's downright astonishingly wrong. The problem is you're assuming symmetric and conventional, non-ECC asymmetric keyspaces are both flat (they're not). But if they were flat, then asymmetric crypto would have a keyspace multiple orders of magnitude larger. Which is the opposite of what you're asserting here.
Conventional, non-ECC asymmetric keys are so huge because most of the keys are weak. Let's compare DES to RSA. Is 0xFA810DD0 a legitimate 64-bit DES key? Yes. (Note: DES only uses 56 of those bits for key material; the other 8 are used for parity.) Is 0xFA810DD0 a legitimate 64-bit RSA key? No. Why? Because 0xFA810DD0 is an even number, which makes it much, much easier to factor.
Conventional, non-ECC asymmetric keyspaces are so huge partially (not exclusively) because most of the keys in that keyspace are unusable. Symmetric keyspaces are so small partially (not exclusively) because most of the keys in that keyspace are usable.
A keyspace in which all (or the overwhelming majority of) keys possess equal strength is called a "flat" keyspace. A keyspace in which some keys are stronger or weaker is... well, non-flat.
But, most symmetric encryption algorithms allow you to get it partly right; if the key is partly right, you get a partly decoded message, so the search algorithm is linear instead of exponential.
This is so wrong that it staggers the imagination. Claude Shannon established some principles back in the 1940s which still guide cipher development today. One of these is called the avalanche effect. The idea behind the avalanche effect is that a single one-bit error, anywhere in the enciphering/deciphering process, will affect the output of half the bits in the entire e/d process.
Go ahead. Use Blowfish with a 40-bit key. (There are lots of Blowfish implementations out there; if you want one, email me and I'll send you one.) Encrypt it with one 40-bit key, and then decrypt it with a key that's only one bit different. You'll get absolute, total, gibberish. You'll get gibberish because Blowfish is a well-designed cipher and avalanches properly.
But wait--it gets even worse. Only a chump runs a cipher in electronic codebook mode. Usually, ciphers are run in a block-chaining mode, where every subsequent block gets XORed with the prior block. So if you have a one-bit error in your process, that will affect half the bits of the block... which then create errors in half the bits of the next block... which avalanche... which propagate their error forwards, on and on and on... etcetera.
You get the idea.
(All of the above information can be found in either Bruce Schneier's Applied Cryptography, 2nd Ed or Menezes, Oorschot and Vanstone's Handbook of Applied Cryptography.)
GCC 2.96-RH fails with C code in one and only one condition: when it's not ANSI-conformant C. GCC 2.96-RH is much more restrictive than GCC 2.95.
GCC 2.96-RH is worlds better than 2.95 when it comes to generating C++ code. With GCC 2.96-RH and STLport-4.5.3, I was happy as a clam. GCC 2.95's C++ support was anemic, nonstandards-compliant, and just generally sucked for any sort of very serious usage.
When I was recompiling tons of applications to work with GCC 2.96-RH, every "compiler error" that I found-- every single one --was the result of a programmer doing something that wasn't ANSI/ISO and made an assumption that "well, since GCC 2.95 didn't complain about this, it's okay." I don't blame GCC 2.96-RH for being more standards-conformant; I blame developers for playing fast and loose with the language spec.
400km of thin copper wire is an awful lot. Try, "the width of northern Missouri".
Wall sockets are either 110V or 220V (sometimes listed as 120V/240V). Nowhere near five thousand. Not even in Europe, where they use much higher voltages, is a wall socket five thousand volts.
With a muzzle velocity of 2000m/s and a muzzle of only 3m, you can be damn sure that the payload would shatter and deform under the hundreds of thousands of G-forces.
You're also neglecting the fact that at 2000m/s, air has the consistency of concrete. The payload wouldn't even get out of the muzzle. It would explode in the muzzle, you'd get a burst barrel, and you'd have 400km of fragmented copper wire bouncing around and killing anyone who was standing too close.
At 2km/s, the concrete wall wouldn't just be breached. It would explode. Everyone around would be dead. There would also be liquified metal (from the payload) spraying everywhere, setting fires.
The sheer amount of energy required to launch a payload at 2km/s from such a short barrel would require a current far in excess of anything THIN copper wire could bear. Not only would the barrel burst and copper go flying everywhere, the copper would be molten.
The next time you decide to spin a totally BS yarn, please at least check to make sure the physics works.
Yes, I'm sure it's better than (especially) C and C++, but nothing compares to the module system of SML.
:) I can't talk intelligently about SML, seeing as how I've never used it (although if you could point me towards a compiler and a good learning reference, I'd like to look at it). What I can talk intelligently about is how utterly miserable C is for large-scale software projects.
:) But I do acknowledge that there are probably more elegant and clean languages than Python.
This may be the source of some of our disagreement; you're an academic, and I'm in the trenches.
Given that most large-scale software projects now are written in C, or a similarly low-level language, I consider pretty much any sane language choice that moves us to a higher level of abstraction to be a Good Thing. Whether we use LISP, Scheme, Python, C++, Java--I don't care all that much, really, as long as it's a step up from C.
So from my perspective, Python is a brilliant choice for software development. Manna from heaven, even.
I dunno what parentheses have to do with elegance, but I can tell you that LISP is not "as good as it gets" as far as elegant functional languages go.
Actually, I was using LISP as an example of a functional language in which the syntax of the language (the Lots of Idiotic Stupid Parenthesis) wind up to some degree hobbling the utility of the language. Once I get a function working in LISP, the first thing I do is go through it and remove as many parenthesis as I can in the hopes of improving readability and maintainability.
Continuances, continuations, collectors, whatever you want to call them this week. :) Diehard Schemers and LISPers tend to call them collectors, after the way they're called in The Little LISPer and The Little Schemer, other people call them continuations, and in Python I've seen them called continuances. Go figure. :)
... make it harder to develop large programs", I can only believe you've never used Python for a large program. Compared to C or C++, Python is a gift from above.
I wouldn't be anywhere near so quick to decry Python as "just" a scripting language, by the by. I've found that with a little care I can get Python's speed to just about equal native code. I write the entire app in Python, then profile the code to see the bottlenecks. I open the bottlenecks up algorithmically when I can, and if they're still performance limiters I implement them in C++. I've been very pleased with the results so far.
Insofar as "its semantics
I have a very warm spot in my heart for Scheme. But I don't feel the biggest advantage of functional programming languages comes from speed of execution (although it competes with C/C++), or from elegance (LISP = Lots of Idiotic Stupid Parenthesis), or from scalability. The big strength of functional programming comes from the way it forces you to think about the problem--it forces you to think about the problem in an extremely formal way, as opposed to the ad-hockery that passes for C. There tend to be a lot fewer bugs in my Scheme code than my C++ code, and hence tend to be a lot more reliable. Mostly, I think, because of the impressed formalism.
Learn it in Python. Really. Python 2.2 offers a whole host of lovely functional-programming features. Continuances, even. :)
I prefer to write functional code in LISP or Scheme, but I won't sneer at someone who uses Python functionally. It might lessen the learning curve for you, let you experiment around with functional programming, and then use what you learn there in Scheme, LISP or Ocaml.
The version I heard was that for a particularly esoteric set of multiple inheritances, GCC would produce incorrect code. I haven't verified this myself, though, so I can't contradict you at all.
GCC 3.0 may have been out for almost a year, but keep in mind that 3.0 is only almost usable. When I tried 3.0, soon after it was released, my average compile time increased by a factor of five. Compiles that used to be able to be done over a lunch break now had to be postponed until the end of the day and run overnight.
Add into that the fact that GCC 3.0 broke multiple inheritance (ask the KDE people how they liked that--you can't build KDE with GCC 3.0), and GCC 3.0 was never a realistic option.
There's a reason why not one single distro ships with 3.0 as its default compiler.
STL. STL. STL. And I'll say it again, STL.
G++'s STL blows. It's so substandard that it borders on the unusable. Take the vector<> as an example. One of the big wins with vector<> is that it can be used as a bounds-checked array. All you have to do is use the appropriate method--or derive a class off of vector<> and override operator[] appropriately--and stack smashes are a thing of the past.
Whoops. G++'s STL doesn't support the vector.at() method, which is necessary for bounds-checking.
There are all sorts of substandard crap in the standard G++ STL. It's gotten to the point where I've flat-out given up on G++'s STL, and am using STLport 4.5.3 instead.
If you want to improve my C++ experience, pay attention to the STL.
There's a sort of implicit warranty whenever you sell something: namely, you're warranting that it's useful for a particular purpose (said purpose being one that you, the seller, reasonably believe the buyer intends). If I sell you a car and I neglect to tell you that it'll blow up spectacularly if you happen to turn the engine over before fastening your seatbelt, well, that car's not fit to drive--hence, I (the seller) am in a whole stewpot full of trouble.
When you purchase software, there's an automatic warranty involved. Namely, that the software doesn't suck. That it's not going to be an open invitation to haX0rs. That using it isn't going to expose you to enormous risk, unless the seller has first advised you of specific enormous risk and you choose to buy it anyway.
When you license software... well, that's not a sale, is it? And hence, the legal protections that you get when you buy things don't apply to you. I can count on one hand and have fingers leftover all the times I've seen shoddy software be held accountable in court.
So this push to software-liability law is more of a push to make software a sold good, not a licensed one. The theory being, if I plunk down $200 for Windows XP, it shouldn't have a UPnP back-door in it. Software-liability laws would permit affected users to sue manufacturers to recover lost damages.
However, common law says that if you pay a nickel for something and it breaks, you can't make twenty million bucks off a lawsuit over it. Twenty bucks, maybe, twenty million, no way. There is an implicit limitation on the assumption of risk, and this implicit limitation is related to the price paid.
If I pay Red Hat $50 for Red Hat Linux and there's a horrible bug that makes my Linux box an inviting target for 1337 haX0rz, then Red Hat's liability is a factor of the $50 I paid them.
If I pay you $0 for a piece of GPLed software you wrote, and there's a horrible bug, your liability is a factor of the $0 I paid you.
Err... wait. I didn't pay you. I got something for nothing--I literally received a good at no price whatsoever above the price of media. The courts would not look favorably upon me suing you for $20 million because you gave me something, for free, out of the goodness of your heart, and made it clear to me that it was a work in progress and might not work as I expect it to.
Polish.
:)
Simply put, WinPT's UI is not up to the level that corporate customers expect. I expect that, provided WinPT development keeps going and doesn't stall, in a year or eighteen months it'll be comparable to the PGP UI. But for right now it just isn't there.
If you think polish doesn't matter, I suggest you search the Web for "Why Johnny Can't Encrypt", which is a usability study of PGP. Even with a modern, well-polished UI, PGP's usability by average users is awful. Really terrible.
If it doesn't integrate seamlessly with the OS, people won't use it. It doesn't matter how simple or gentle the learning curve is; people will just choose to not learn instead.
5% of computer users are geeks, and that may be optimistic. The remaining 95% are the Real Users. Live in fear and terror of them.
For the time being, GnuPG has one enormous shortcoming in the corporate world. Namely, it's possible for individual users to send traffic that the corporation itself can't eavesdrop on. This may sound like a nonissue, or even an offensive one, but the fact is that if you're sending communications on the company dime, using company equipment, the company does have a right to make sure you're not sending corporate secrets to the competition.
... well, pretty pathetic. But for time being, NAI--and PGP--is the only game in town on the corporate front.
The parameters of how they may exercise this right are matters of considerable debate. E.g., must the company give notice that communications are being monitored? Must the company stop monitoring if it's an email or a phone call to your spouse? Etc. There's a lot of room for debate on that issue, but the basic fact remains that corporations need some way to make sure their secrets aren't being sent out to their big competitors.
In the crypto world, there are two major ways of doing this. One is key escrow (a technology which appears to have finally died the ignominious death it deserved). The other is the Additional Decryption Key (ADK). The difference between the two of them is that the ADK is a request to encrypt to an additional (corporate-controlled) key, and escrow requires the private key be held by some "trusted party", just in case.
Escrow technology is a big can of worms, and ADKs are smaller cans of worms. They're unsuitable for private users because they wind up being security risks. And, in fact, PGP's most critical vulnerability since the 2.6.x days came from an ADK bug.
However, corporations view the risks of not having ADKs to be much greater than the risks of having ADKs.
Corporations demand either escrow or ADK. GnuPG supports neither, and Werner Koch has said that GnuPG will never support them. He has his reasons for saying that, and his reasoning is pretty sound. But, then again, so is the corporate logic for insisting on escrow/ADKs.
Moreover, GnuPG doesn't have any pretty GUIs. WinPT is making a good attempt for Win32, and GNU has their own (apparently stalled) GTK+ front-end, but neither one is anywhere near done. In any business setting, 95% of the people will be stark raving terrified of the prospect of using a command-line app. For this 95%, PGP is the only option. There simply isn't anything else.
This is sort of a shame, given that NAI's reputation for being an attentive, responsive vendor is
For me, personally, I use GnuPG and love it. I wholeheartedly recommend people use it. But I simply can't see it taking off in the enterprise for the reasons listed above.