While C++ may lose to C in the executable size, C++ has minimal loss to C when it comes to speed. The mantra of C++ is you don't pay for what you don't use, and most compilers do a pretty good job of living up to it.
In the early days of Objective C, its performance was piss-poor due to its habitual late binding (putting off as many decisions to run-time as possible). C++ won, in part, because its early binding made for much faster code.
If you can't write C++ code which blazes by faster than a jackrabbit on amphetamines, that's a problem with your skill, not the language.
Note that in the below code, the value of x is cast to a void pointer y (implicitly, not explicitly--bad programming form, but done here only to show it can be done without the compiler complaining; explicit casting can similarly be done), and y is cast back to an integer variable. This code is legal ANSI C++, and compiles under egcs-2.91 with -Wall -ansi -pedantic without error or warning.
Production C++ code ought to use static_cast instead of these C-style casts (enhances type safety). I'm using C-style casts here for ease of reading.
#include <iostream>
using namespace std;
int main(void)
{
int x = 123;
void *y =
int z = *(int *)y;
cout << z << endl;
}
C is a loaded gun aimed at your foot; C++ is a Gatling gun aimed at your head. Describing C as much, much more powerful than C++ isn't just wrong, it's ridiculous.
Neither one is more powerful than the other. What the hell does "power" mean in a programming language, anyway? The word has no definition in a programming context.
The only relevant question, IMO, is which is the right tool for the job?
Sometimes, the job requires procedural programming. For that, procedural C++ or C is called for. Sometimes, the job requires object-oriented programming. For that, C++ or object-oriented C is called for. Sometimes, the job requires generic programming. For that, C++ or really hoary C is called for.
C++ is probably more versatile than C, but it comes at significant cost--compilers become complex, the STL is difficult to maintain, etc.
There is no clear "more powerful" language. Use the right tool for the job.
And insofar as operator overloading in C++... I use it all the time. Where's the problem?
Warning: I am a C++ hacker, and I like it a hell of a lot.
Answer: People are using C++. Every single program in The C Programming Language is a perfectly good and valid C++ program; in fact, Bjarne Stroustrup himself recommends reading The C Programming Language as a way to improve one's C++ skills.
The advantage of C++ is that it's a hell of a toolbox. You've got hammers, screwdrivers, chisels and even a fully-functioning wood lathe (watch me turn this chunk of hoary code into a table leg!). Good programmers use the right tool for the job.
And if the right tool for the job happens to be procedural programming, C (or procedural C++) is an entirely reasonable thing to do.
The proof, as they say, is in the pudding. I can definitely associate his work with Ron Rivest, for instance. Rivest wrote RC6, an AES candidate which had 15 rounds broken. Schneier wrote Twofish, an AES candidate which has fared much better. RC6 isn't going to be selected as AES (I'll wager $20 on it), but Twofish is still in the running.
Insofar as "Bruce Schneier, by his work, is not a cryptographer (nor is he a cryptologist)"... I've got to recommend that you talk to your dealer about the purity of your rock. Strictly speaking, a cryptographer is one who develops and devises codes and ciphers. Schneier has written lots of ciphers, ranging from the lousy (MacGuffin) to the profoundly brilliant (Blowfish, and maybe Twofish).
He has also published cryptanalytic results against the major AES candidates, including (I believe) RIJNDAEL. I like RIJNDAEL. Joan Daemen (I'm misspelling the name here) is a brilliant cryptographer, responsible for a lot of extremely high-quality stuff--and if Schneier, et. al., can cryptanalize RIJNDAEL, that says something about Schneier's skill.
Insofar as Applied Cryptography being shady, I'm going to have to ask you for some verification. How is his description of Blowfish "shady"? After reading his description of Blowfish I was able to implement it, from scratch, without looking at any source code. My version passed the Blowfish compatability vectors, so apparently his description was clear and concise.
Finally there is a better crypto book out there anyways: it called the Handbook for Applied Cryptography by Vanstone et al.
Err... no. The Handbook of Applied Cryptography (notice the name), edited by Menezes, Vanstone, et. al., is a very good book. I refer to it often. However, I refer to Applied Cryptography more--why? Because I want to know the accepted way of how to do something, not a formal proof that the accepted way works. If you want to know how to encrypt the last block of a CBC mode cipher so that the cleartext is the same size as the ciphertext, Schneier tells you this in the space of a paragraph or two. The Handbook of Applied Cryptography goes into much more mathematical rigor.
This is not to say that the Handbook of Applied Cryptography is inferior: it's not. The two books are meant for different audiences who need different things, and claiming that one is superior to the other is pretty specious.
His papers are imprecise and obvious
... Are you telling me that you could have cryptanalyzed RIJNDAEL?
Seriously. Get a grip. Schneier is no demigod, that much is true; he's a human being just like anyone else, and occasionally screws it up past all recognition (just like anyone else). However, he is a hell of a lot better than I am.
My own beef with Schneier is something totally different. Schneier works as part of a team, not a solo operator. His best work has always been collaborative, with Doug Whiting, Niels Ferguson, etc. While I don't begrudge Schneier his fame--I think he's more than earned it--I do wish that people, particularly Slashdotters and the news media, would realize that Schneier may be the crypto version of Buckaroo Banzai, but--just like Buckaroo Banzai--he's nothing without his crew of Hong Kong Cavaliers and Blue Blazes Irregulars backing him up.
In response to your first question (ought there to be a unified commenting standard), the answer is a loud, resounding "no". There is no single standard for documentation; the best you can say is there ought to be a standard for applications written in C, kernel modules written in C, written in , etc., and that's not a very satisfying answer.
There are some very good guidelines to follow, though. Guidelines are different from a standard in that they only prescribe general rules and principles, without any attempt to enforce strictness--the assumption being that the programmer is smart enough to know when to deviate from the guidelines.
I'll present my own guidelines for good comment practice here:
0. ENSURE APPROPRIATENESS Writing your own code to descramble CSS is admirable, but that's not the place to include anti-MPAA screeds. Similarly, the documentation for function foo ought to talk about foo, not function bar, unless there are some states of bar which affect foo's behavior.
1. MAKE IT CONCISE When I write code, I generally write two documents; the first is the source file (with comments), and the second is the design file (in SGML). The former has concise comments; the latter is where I go into detail as to what considerations went into the design.
Nobody wants to read a thirty-line comment in a source file. If a function is so complex as to require that degree of verbosity, it's a sure bet that you've made the function too Byzantine.
2. VERSION-CONTROL YOUR COMMENTS. More times than I can count, I've been misled by comments. The original coder may have commented wonderfully, but subsequent coders made big revisions and never updated the comments or the design document. Something as simple as "Written 06 Jan 2000, last revised 01 Mar 2000" can be a great help... if your code has a datestamp of August 2000 and the last time the comments were revised was in March, that's a strong hint the comments may be out of date!
3. LEAVE BREADCRUMBS FOR FUTURE DEVELOPMENT. If in your design document (if you have one) you say, "it'd be nice if we could include foo", then leave a breadcrumb in your code saying "I think foo could fit best in here". It doesn't have to be about functionality; it can be something as simple as "let's see about cleaning this function up, it's icky and slow".
Remember that comments are not written for you; they're written for the people who come after you (who, often as not, are you--just a couple of years older). Use comments to give them hints as to where known bugs exist, where things can be fixed, where bottlenecks are and so on.
4. DON'T OVERCOMMENT Nothing annoys me quite so much as bondage-and-discipline documentation styles which require that every variable in a function be described. One-letter identifiers like i, n, j and so on do not need descriptions. If you're using them to do anything more than mere placeholding--keeping track of state for a loop, for instance--then you're using them incorrectly.
Your code ought to be clear and straightforward enough that you don't need to write reams of comments saying "the variable i stores state for foo which is passed through three levels of pointer indirection to bar".
5. USE TAGS Tags are useful because they make your comments indexable. Try arranging your bugs as BUG_WISHLIST, BUG_NORMAL and BUG_CRITICAL. Then it makes it simple to search your code to find bugs which you already know about.
This sounds worthless, but it's surprisingly handy. The more you program, the more tags you'll find. The important thing is that you keep them reasonably short and consistent.
I am an employee of Network Associates and a programmer working on PGP.
We're looking into it. I can't say much more than that at this point. As soon as more information is known, I will post it as a reply to this thread. Hopefully, you'll see some official word on it here soon.
I am an InfoSec professional, but this is not professional advice. Moreover, I really like OpenBSD, so please don't take this as a BSD flame.:)
The problem with buzzwords is that they so rarely mean what their obvious meaning is. When I see "secure by default", that tells me "I can install OpenBSD in its default install, throw Apache and my MTA-of-choice on it, and it'll still be safe". That's what secure by default suggests to me; that a clean install of the OS and the daemons you need to run your business will be secure, by default.
The problem with it is that this isn't anywhere near to the case. I've got lots of kudos for OpenBSD's large, distributed security audit. I think it's a brilliant idea, and I wouldn't mind seeing Linus say "okay, for the next six months all development is frozen and we're going to audit our codebase".
Unfortunately, security audits are not synonymous with security. (Trust me on this one.) Security is a process, not a product; it cannot be magically generated by anything, not even OpenBSD's vaunted audits. You run into Heisenberg's Catastrophe at some point--assuming that your auditing process was complete and accurate, your codebase is safe; but then you have to audit the audit process to make sure you didn't leave anything out... then you have to audit the audit of the audit... and so on.
These are the main problems with audits that I've found:
LIMITED MANPOWER. The scorn that Theo heaps on the Linux community is, in some sense, warranted. What Theo misses is that where Linux has a huge amount of manpower, mostly of limited skill, OpenBSD has a miniscule amount of manpower, mostly of fairly high skill.
The problem is that security audits are limited by manpower more than they are technical skill. A thousand coders of only amateur skill can go through code at a huge rate; it's not hard to spot unconstrained buffers (buffer overflows), pointers that never get free'd, etc. If they were only ten coders strong, it would not matter how much skill they had, they simply wouldn't have the manpower to do a thorough code review.
INCOMPLETE SECURITY AUDITS. OpenBSD's security audit means they have an extremely high-quality kernel and tools. When even ls has been audited, you know they're doing something. However, Apache, sendmail and other large programs have not been audited by the OpenBSD team. Putting an old, vulnerable version of Apache on an OpenBSD box exposes potential risk.
(Before the OpenBSD people accuse me of FUDding, let me emphasize potential. The root exploit against Apache/Linux might fail on Apache/OpenBSD, due to OpenBSD's security consciousness. The point here is not to say "Apache makes systems insecure"--it's to say that there are a lot of daemons running on modern boxen, and many of these daemons have not been audited.)
INCOMPETENT SYSTEM ADMINISTRATION. Most root exploits I've seen--regardless of operating system--have taken place due to incompetent system administrators. OpenBSD does some things right by shutting down all nonessential ports by default (as opposed to Red Hat, for instance), but these are just Band-Aid measures over the festering, necrotic wound of incompetent sysadmins.
INCONVENIENCE. One of the biggest motivations for people to bypass security precautions is that security is inconvenient. If a user bypasses a precaution, that's worse than if the precaution never existed in the first place. There's a difference between a sysadmin who says "all our passwords are secure, because we use shadow passwords and force our users to change them every month" and the sysadmin who says "I don't know if our passwords are secure, despite the precautions we take".
The former, more likely than not, has users who are so frustrated by the bondage-and-discipline security precautions that they leave their passwords on Post-It notes attached to their monitors. The latter probably has them, too, but at least isn't fooled into thinking he's safe.
OpenBSD has some very useful security precautions, yes--but the most useful precautions are those that are transparent to users (security audits, jailing daemons, etc). The more intrusive your security becomes, the greater the likelihood your own users are going to circumvent them.
LIMITED FEATURES. Remember that oftentimes security is enhanced by adding features. Adding ACLs, for instance, could be a boon to sysadmins everywhere and result in more secure boxen. Since OpenBSD's developers spend so much time auditing, though, they're significantly behind the pack when it comes to keeping current with other Unices.
... All that said, though, if I were setting up a network, all of my machines visible to the outside world (mailserver, webserver, etc.) would be running OpenBSD or Pit Bull or Trusted Solaris. Probably OpenBSD, due to the fact that I already know UNIX reasonably well and I don't need the bondage-and-discipline of Trusted Solaris (see "INCONVENIENCE" above).:)
But over-ruling the DMCA was certainly not his job.
The Supreme Court of the United States disagrees with you, as does the vast majority of Constitutional scholars in this country.
Any and every Article III Judge in the United States (and Kaplan is one) has a Constitutional duty to see that the law of the land is upheld.
The nation's highest law is the Constitution. It is therefore the required duty of all Article III judges to review laws which come before them for Constitutionality.
Judge Kaplan did so in this regard; he came to the conclusion that the DMCA's more odious provisions do not violate the First Amendment. Overruling the DMCA, if it is unconstitutional, is definitely his job...
... he just decided that source code is not worthy of Constitutional protections.
When the Supreme Court handed down a ruling that Andrew Jackson disagreed with, Jackson refused to execute the Court's order and commented: "[The Court] has made its ruling; now let it enforce it."
I'm tempted to write a letter to Judge Kaplan saying the exact same thing.
By the by--many lawyers and judges will disagree with me here, but I strongly encourage people to write letters to Judge Kaplan. Keep them polite, respectful and intelligent--trust me, you do not want to piss off a Federal judge. He will not respond to your letter, no matter how much he wants to; Federal ethics laws forbid him from responding to citizen complaints.
However, the First Amendment guarantees that we have the right to petition the Government for the redress of grievances. The First Amendment nowhere states that we can only petition our President and Representatives.
It's a kind of despair that hits with the increasing speed of the information age.
In the 1970s a fellow named Alvin Toffler predicted that, at some point, technology would advance beyond people's ability to integrate it into their day to day lives. This phenomenon was called future shock (after the name of Toffler's book) or technoshock (the name I prefer).
My parents don't suffer from technoshock, which I used to find interesting--until I realized that they know technology has left them by the wayside, they don't have a whelk's chance in a supernova of catching up, and they don't care. It's that last bit which keeps them from suffering.
Geeks and hackers don't have this luxury. If we gave up caring, we'd stop being what we are. So all we can do is grab the future by the throat and hang on for dear life.
It's hard, yeah. But take what consolation you can from the fact that everyone is in the same boat you are. I don't know a single person in the industry who doesn't find themselves overwhelmed by the rapid change of pace. Your situation is not unique.
I hope that I convey the kind of feelings that depress those of us in the early stages of learning
I've been programming in C++ for ten years, C for almost as long, UNIX for seven years. Trust me, friend; those feelings plague people no matter what their level of learning is. There isn't a single day that I come to work, look over my code and find some stupid bug, and kick myself for errors which, I tell myself, a college freshman would be bright enough to avoid.
[W]hat do you do to catch up?
... First, stop trying so hard. That's the best advice I can give anyone who's trying their best to get current with the technology curve.
You shouldn't have to try in order to get good skills. The more you try, the more you'll fail; the more you fail, the more desperate you'll become; and once you get desperate, you're not going to be much use to anyone.
Stop trying and start playing. Little kids pick up computer science faster'n you can blink, mostly because they haven't yet been brainwashed into thinking that learning has to be drudgery. Grab some code which you think is interesting; go through it to study how it works. Sooner or later you'll find something that makes you say "you know, this could be changed..."
Maybe the code is unclear; maybe there's a fencepost (off-by-one) error; maybe there's a more optimal way to solve the problem. For whatever reason, you'll find something which could be just a little better if it were changed just a little... and then change it.
One of two things will happen. Your changes will either improve the program, or it won't. If your changes improve the program, then sit back and bask in the warm glow of "I just solved a programming problem and damn I feel good". If your changes don't improve the program, don't get frustrated. This just shows that there's some subtlety here you don't understand yet.
[M]aybe it comes down to straight motivation and drive... [i]f you want it bad enough, you'll do it.
That, too. But don't forget to have fun.
I'll get it, eventually.
I've said this more times than I can count.:)
Every single time--every single time--I've managed to get it. (Admittedly, getting Motif programming took me years, but I got it.) I'm certain that Linus, Miguel de Icaza, Matthias Dallheimer and Alan Cox all say "I'll get it, eventually" a lot more often than you think they do.
Good luck. And if you need help, ask for it.
This isn't the Free Software Band-Of-Thugs. This is the Free Software Community. Communities exist for mutual help and support. So don't be afraid to ask questions, even stupid ones. But the flip side is that if someone asks you questions--even stupid ones--answer them patiently, honestly and as clearly as you can.
Warning: this is the rant of a long-time C++ hacker who hasn't looked at Objective C since he was in college.
PERFORMANCE
Objective C was, at the time it was introduced, dog slow. This was due to its "cleaner" design and the way it delayed as much as possible until run-time (both of which are, arguably, the Right Thing). C++, on the other hand, had (and still has) an extremely strict philosophy: you don't pay for what you don't use. If you don't use templates, you don't incur the overhead of them. If you don't use virtual functions, you don't incur the overhead of them. If you don't use <foo>, you don't incur <penalty of foo>.
CODE REUSE
Objective C invalidated an awful lot of existing C code. Now, Objective C's defenders will say "... it did no such thing! My program still compiles just fine under C, just as it does under Objective C!" With due respect to them, that's not the point.
One of C++'s selling points is that you can trivially call C++ from C functions. You can trivially call C from C++ functions. Mix-and-match as much as you like. Heck, you can even write C++ code in C.[*] You can't do that with Objective C. [**]
Objective C required a vast change in how programs were written (see below). C++ offered a slower, smoother slide into the world of OOP.
CONSTRAINED PARADIGM
C++ is, contrary to popular belief, not an object-oriented programming language (OOPL). Objective C is an OOPL. [+] This is another major reason why C++ won out.
C++ is equally at home with procedural programming, object-oriented programming, generic programming--heck, I've even seen functional programming done in C++ (admittedly, it was a nasty hack, but...). People who loudly trumpet C++'s object-oriented capabilities are, with all due respect, totally missing the point. Personally, I find generic programming to be much more breathtaking than OOP--but if I were to say "C++ is so cool because it's a generic programming language", I'd be missing the point.
The point is, you can use whatever paradigm you need to get the job done. The unpleasant truth of object-oriented programming is that it is not a panacea; while it does some things really well, there are other things it's lousy at. To really enjoy any benefit from Objective C, you must use an object-oriented solution, regardless of whether or not an object-oriented solution is called for.
This had the added side effect of making it very marketable to IT departments. Senior executives got to tell their bosses, "Yes, our entire IT department is working in C++ now"... and the techs got to keep on solving problems the same way they always had, and were able to take their time to slowly migrate things to C++. Management was satisfied that "we're using C++"; the techs were satisfied that "well, at least we can keep solving problems in the old C style while we come up to speed".
With C++, I'm free to use whatever solution I need, whether it's a generic solution, procedural, functional, object-oriented or what-have-you.
(Let me harp for another moment on generic programming. Damn, is it cool, and I wish more languages supported it. I think generic programming is a seriously overlooked part of programming. End the free advertisement for generic programming.)
[*] Don't forget, the first C++ compilers were really preprocessors that spat out C sourcecode. Everything you can do in C++, you can do in C... C++ just makes it a lot easier.
[**] At least, I've never had the patience to do it. I've tried a few times, but it quickly gets nontrivial.
[+] This is kind-of true. Without fully embracing OOP, you can't use any of Objective C's really cool features--you lose everything which distinguishes it from C. C++ allows you more flexibility in this regard.
... on Larry King Live, he claimed to have invented the Internet. Later on, his spokespeople claimed that he was exhausted, was speaking off-the-cuff and made an error. I'm inclined to believe him, just because it's so boneheaded of a mistake to make that I can see how it'd take someone to be falling-down tired to make it.
Spruce (here) is my preferred email client for UNIX. It's not quite as featureful as other clients, but is fairly stable.
Best of all, it supports GNU Privacy Guard. I've got a couple of minor quibbles with how it does things, but on the whole, it's my preferred email client today.
First, it's unlikely that Free Software will ever be found liable in court, due to the conspicuous disclaimers of warranty and liability which can be found with every Free Software license.
That's not the same thing as protection, though.
Remember that contracts are subservient to the civil and criminal law. It is not possible to construct a contract which violates the civil law; if such a contract exists, then the portions of it which violate civil law are null and void.
So let's say, for sake of argument, some state has a law on the books which says "for all software used in avionics, the manufacturer must provide a warranty". This is a plausible law; avionics is a life-and-death software situation, and it's entirely within the rights of a state to specify that life-and-death software be held to a higher standard.
Now let's say that an aerospace company wants to build an airplane, and decides to use a GNU tool as part of the software package. The engineering staff sees that there's a disclaimer of warranty, and sends a letter to the Free Software Foundation saying "hey, I'd like to use this software in our new plane, would you mind terribly if we did?"
Suppose the FSF says "sure, go ahead"--in writing, of course. The FSF thinks that the terms of the GPL apply; the engineer thinks that the terms of the state apply, and by giving the go-ahead, the FSF has acquiesced to this.
Now suppose that plane crashes, and lawsuits are filed. Suddenly there's a big lawsuit filed against the FSF; the aerospace company claims "we talked to them and we have this letter here permitting us to use their software; that overrides the GPL which they *thought* they were releasing it to us under, and that means the FSF *must* provide a warranty for this software".
The FSF says "But wait! This is a Washington state court, and we're from Massachussets. We weren't aware of Washington's required-warranty law, and had we been aware of it, we wouldn't have told them to go ahead--we told them `sure, go ahead', meaning under the terms of the GPL, with no warranty involved!"
Eventually, the case would go to the jury. The jury would come back with a decision, and it might not be favorable to the FSF.
This is just one hypothetical situation. There are many more you can construct. No matter what, though, it all winds up the same: in a civil trial, everything's irrelevant once the jury gets seated. If the jury is dead-set on saying that you're liable, then by God you're going to be liable whether or not you disclaimed everything.
The very short version:
Don't spend your time worrying about whether or not you can be held liable--you can. Spend your time making your software high enough quality that nobody will ever want to sue you for making a shoddy product.
Nah, it still holds together. The Oppenheimer Defense applies to just about anything. By your logic, I could come up with a way to synthesize smallpox in your basement, then take out a full-page ad in the New York Post with the instructions and a caption reading "HEY, IF YOU'RE A TERRORIST BENT ON ANNIHILATING THE WORLD, READ THIS!"
After all, an ad has a significant lawful use... to be read, right?
Basically, because he's misappropriating the term `hacker' and promulgating this distorted vision of hackers as being malcontents, ne'er-do-wells and geeks.
I once picked up a copy of 2600 just to see what the big fuss was about. When I leafed through it, I didn't find much that was, in my mind, hackish. There was an article about boxes and phreaking; about the NPA-NXX system of phone number allocation; about how to override the environmental controls of a Best Buy so to make everything a sweltering ninety-nine degrees.
Even though there's a disclaimer that says "2600 does not endorse any illegal activities", it's still an inescapable conclusion that most of the articles which appear in 2600 are written by petty criminals--extremely petty criminals.
There's hackish glory in knowing how phone numbers are allocated and how the NPA-NXX system works, or in knowing the security holes in a stock Solaris 2.7 installation, or--etcetera. Fill in the blank.
I work in information security IRL, and I know a lot of these things. Some of my best friends know a lot of these things. Sometimes, we sit down and have a couple of beers and talk about exploits, and even do penetration tests--against boxes we own, in highly controlled environments.
The typical 2600 article is written by, and for, frustrated techno-turks who have an axe to grind against society in some regard, and gets a vicarious thrill out of making a Best Buy a sweltering inferno for its customers. I don't see that there's anything commendable in that. I think people who do those things are criminals, hooligans and petty vandals--and I think those who encourage such behavior must shoulder some of the responsibility.
Is it legal to encourage that sort of behavior? Yes. That doesn't mean it's right.
The Oppenheimer defense ("I just built the damn thing, you're the one who's responsible for how you use it!") only works if (a) your creation has significant lawful use, and (b) you don't encourage irrational or illegal uses.
2600 claims that it doesn't encourage these uses. I think that a thorough reading of any issue will quickly show that their disclaimer is there strictly for legal protection, and they don't mean a damn word of it.
That's why I think Goldstein is a boil on the ass of the universe.
Every United States judge, without exception, is authorized to decide whether or not laws which come before them are Constitutional. The lowest magistrate (the lowest rung on the Federal judicial ladder) can declare laws unconstitutional (they never do this, of course--small worm, big freakin' hook, all that). District judges (the next ladder up) do it more often than magistrates do. Appellate judges are where the real judicial power is exercised; 99.9% of all judicial cases in the United States end at the appellate level.
We hear about Supreme Court decisions because the Supreme Court's jurisdiction is the entire United States, plus all of its territories and holdings. Appellate decisions only affect a few states; District and Magisterial decisions only affect the district in which they preside.
For instance, in Bernstein v. US, coming out of California District Court, District Judge Marilyn Patel declared certain portions of the ITAR/EAR to be unconstitutional. The very instant Judge Patel entered her ruling, those unconstitutional portions of ITAR/EAR were annulled--in fact, the instant she entered her ruling, those portions of ITAR/EAR were retroactively declared to have never existed. (Legally, unconstitutional laws are void "ab initio"--"from the very beginning". It's as if the laws were never passed.)
At some level of the Executive Branch, it was decided to appeal this decision. It went from a California District court to the Ninth Circuit Court of Appeals, which covers most of the West Coast. The Ninth Circuit Court of Appeals affirmed Judge Patel's ruling. Suddenly, those portions of ITAR/EAR were null and void throughout the entire Ninth Circuit.
Had the Executive Branch appealed the decision to the Supreme Court, and the Supreme Court heard the case, and the Supreme Court affirmed Judge Patel's ruling, those portions of ITAR/EAR would have become null and void throughout the entire United States, its territories and holdings.
Short answer: Precedent. Already there's caselaw from the Sixth and Ninth Circuits which holds that, in some instances, computer source code can be Constitutionally-protected speech. These cases have revolved only around cryptographic code, though; DeCSS is the first case where computer source code, without any qualifications, has been presented as warranting First Amendment protections.
If the judge rules (as I expect he will) that DeCSS possesses expressive content, a lot of the DMCA will be in jeopardy, and maybe UCITA, too. We (the hacker/geek community) will now have three different legal precedents to stand on in the event that future lawsuits are filed against us. "Don't like our programs?" we can say. "Tough luck! Free Software is Free Speech!"
This will scare the hell out of half the intellectual-property lawyers in the country, and will make the other half giggle with delight.
I don't like 2600. I think that Eric Corley/Emmanuel Goldstein is, mostly, a boil on the ass of the community. But if he gets the right to freely talk about DeCSS and how to circumvent access controls on DVDs (probably the only thing he and I will ever agree on), then I get the right to freely talk about things I find interesting which the Government would rather I didn't.
That, to me, is the most important thing which is coming out of the 2600 trial. I don't give half a damn what happens to Goldstein. I give a damn what happens to me. And if the law will protect Goldstein, how much more will it protect me?
This is the same logic Larry Flynt used in his First Amendment trial. It was good logic then, and it's good logic now.
It comes in because I feel that we all, as human beings, have a duty to treat other people with a modicum of courtesy. Sometimes this isn't possible, but as as a general moral principle, that's it.
The police officer... was being deceptive in implying that the reporter could be required to open his backpack, show ID, etc.
I didn't see any implication. I saw the police officer give a challenge (in the legal sense of the term--as in, `issued a demand'). I expect that the police officer was probably reasonably polite about this; "Please open your backpack, sir." Where's the implication? Even if it was "Open your backpack," it still wouldn't have any implication of it being nonvoluntary. "Open your backpack or else get arrested and then we'll open your backpack for you" is nonvoluntary (and, oftentimes, illegal).
If you choose to treat every police officer as if s/he is an unquestionable being whose every demand must be acquiesced to, that's your problem.
Insofar as deception go--the police are allowed to be tricky and cunning. Police are allowed to lie to suspects to elicit confessions; they're allowed to deceive suspects to get them to act in incriminating ways.
Even if you don't care if the officer sees what's in your backpack or what your name is, it's a service to society if you refuse.
Not really. Neither the law nor the Constitution permits you to withhold your name from authorities. You have the right to remain silent, you have the right to an attorney, you have the right to refrain from self-incrimination, you have the right to have a judge or magistrate approve warrants for searches of your property... but you do not have a right to refuse to give the cops your name.
Insofar as the resistance to illegal search goes, I'm in complete agreement with you. However, the search wasn't illegal. If someone shows up at a protest which is expected may turn violent wearing military load-bearing gear and acting belligerent to the cops, that's probable cause that the person may have violence in mind and as such, ought to be detained.
Police take WAY too much advantage of the average person's ignorance of the law in cases like these.
How do they take advantage of someone's ignorance? I own a 1995 Eagle Talon ESi, in very good shape and about 80,000 miles. I'm willing to sell it for $15,000, first-come first-serve.
Am I taking advantage of someone who pays me that much money, certain that they're getting a good deal? No. The Blue Book is widespread and easy to find. If you're paying $15,000 for a car which is only worth (optimistically) $10,000, that's your problem, not mine--caveat emptor.
Similarly, if you're ignorant of your rights as a citizen and you wind up not knowing enough to stand up for your rights when the police make demands of you, that's your problem, not the cops'--it's your responsibility, as a citizen, to know your own rights.
Unfortunately, the problem with Peltier's supporters is that they've never bothered to read the court transcript. (I have, after hearing Rage Against the Machine give a pro-Peltier speech. I was so moved by Peltier's plight that I rented Incident at Oglala and read the court transcript. It's amazing just how much you can learn by studying both sides of a story.)
As soon as you do, then I'll be happy to resume talking with you. Until then, you're a zealot who's looking to scream loudly about the abuses of the system.
Screaming about abuse is not the same as quietly demanding justice. Governments don't give a damn about the former; the latter sort of person scares the hell out of them.
Peltier has been in jail for murder. When you get right on down to it, Peltier was accused of common crimes and had his day in court just like anyone else. Peltier is not someone special. He is a common criminal, and is being treated like any other common criminal.
While many people believe there's a Government conspiracy to keep Peltier in prison for political reasons, I find that very hard to believe. I don't think the Government is competent enough to pull off a good conspiracy.
If you want to get arrested, nothing tells the cops "troublemaker" quite like someone whose first word to them is "fuck". In fact, for maximum get-arrestedness, make sure that about every fifth spoken word is an invective. Feel free to mix in words like "pig", "lackey", "fascist" and "thug" with the more conventional vulgarities.
Do not: "I'm sorry, Officer, if you'd like to see my bag, I'd like to see your warrant." This is too polite and subtle.
Do: "Eat penguin shit, you ass spelunker. No fucking way am I letting you pigs get in my bag without a Goddamned warrant!"
2. WHO'S DA MAN? (YOU ARE!)
Never forget who's the really cool/hip/in-charge guy. You are. And if you're feeling generous, you can bestow Magic Coolness on your buddies, too. That means that anyone who gets in your way, even for the most routine of things, is automatically Naughty In The Sight Of God, and deserves a good smiting.
Do not: "Identification? Why, sure, Officer, here's my driver's license." This actually treats the officer like he's a human being who's doing a job. Since the officer is getting in your way and is Naughty In The Sight Of God, this is a no-no.
Do: "You can have my identification when you pry it out of my COLD DEAD FINGERS! LEONARD PELTIER WAS FRAMED! YAAAAAHHHHHHHH!" Even this is not optimal. For best effect, use various profanities and insults liberally (see point 1 above).
3. ALL THE WOMEN LOVE DANGEROUS MEN.
Let's face it. Nothing turns on those lady cops quite as much as a sweaty, smelly, foul-mouthed Lothario. They want your attentions and affections. If they say otherwise, they're just playing hard to get.
Do not: "I'm just heading to the Port-A-Johns, ma'am." This is respectful, it treats her as if she's not Naughty In The Sight Of God for getting in your way, and you're missing on a perfect opportunity for police poontang.
Do: "Yeah, baby. I'm just heading to the Port-A-Johns... say. Does the little piggy wanna get porked?" Rude, crude, crass and utterly offensive to any woman within earshot. This is just about perfect.
4. REMEMBER:
No matter what, The Man is trying to get you down. The Man is trying to break you like a twig. The Man wants you dead, crushed underfoot like a snake.
Do not: "Thank you for helping me with directions, Officer." Don't thank the pigs. Everything they say is a lie.
Do: "Yeah, I'm sure you'd LIKE me to believe that the street ahead is closed! <shoves aside cop, charges forward anyway>"
* * * * *
If you do all the above diligently, you, too, can get arrested! And afterwards, you can write a self-important screed about how evil The Man is and how Naughty In The Sight Of God the Man is, and how your rude, subhuman, and utterly crass behavior is actually the culmination of two hundred years of American civilization.
OOP is not meant to be a Holy Grail, despite what many people claim. OOP is meant to be efficient, which is not the same thing as fast during run time.
Sometime, write a basic program in C which accepts input from a user (like their name, for instance) and then writes "Hello, <username>!". Make sure that it does bounds checking; that it has no arbitrary limits on how long a user's name can be; that it's well-behaved in the case of a crash; that it's this, that and the other. It takes pages and pages of code to write a simple, basic program well in C, because C is an inherently low-level language.
C++, on the other hand, simplifies all of this for you. Just do a "string username; cin >> username" and you get a boatload of functionality.
C++ is more efficient in that case, because processor time is cheap and my time is worth a hell of a lot. In that case, it's better to minimize my time rather than the processor's time. This is the way it is for most software projects, by the by; programmer time costs much more than computer time.
There are situations when this is reversed, where it's more efficient to have teams of programmers working for years on a program than it is to trust the processor to do the Right Thing at run-time. The Space Shuttle is a good example of this. The people who write code for the shuttle's flight computers use HAL/S as a development language ("High Order Assembly/Shuttle", if I recall). HAL/S is ugly. It's just about the last language I'd use for any given engineering task. But it works perfectly fine for the Shuttle, because it's more important that the programmers do their job right than it is that the language is perfect.
The cost of Shuttle programming is astronomical (pardon the pun). However, in almost 25 years of operation they've never had a single catastrophic crash (save the 1986 one, which was caused by a catastrophic failure of other systems which interrupted computer operation). Try getting that sort of uptime from a UNIX box.
Moral of the story: OOP isn't a panacea. Neither is traditional procedural programming. Saying that "OO... will NEVER surpass, or even equal traditional functional programming" just shows that you don't know OO very well.
OO isn't competing with procedural programming. It doesn't need to. The two paradigms exist completely independent of each other, and neither one of them needs to justify their existence. They just are, and wise programmers use whichever one is proper for a given application.
Alfred J. Menezes, Handbook of Applied Cryptography.
Schneier, Bruce. Applied Cryptography, Second Edition.
Kissinger, Henry. Collected writings. If you want to know crypto, you also need to know the political climate which created crypto; and when it comes to Cold War history, nobody tells it like Kissinger.
The ICSA Guide to Cryptography. Very light, but it's good for a beginner's introduction.
Kahn, David. The Codebreakers.
Bamford, James. The Puzzle Palace.
Gaily, Jean-Loup. The Data Compression Handbook (? on the name; it's been a while).
Knudson, Jonathan. Java Cryptography.
Elliote, Rusty (?). Java I/O.
Halsall, Fred. Can't think of the name for the life of me, but it's a monstrously big book about network communications. Very good stuff, even if it only has one chapter on communications security.
* The company is illegally depriving a programmer of revenue,
* The "Ask Slashdot" question is about how to ethically resolve this situation,
* And your advice is to COMMIT A FELONY?
Insurance fraud is a serious offense. It's not "Sure, the insurance company does lose but who cares about them, right?" You've just changed the illegal-deprivation-of-revenue issue from the aggrieved programmer to the insurance company.
You haven't resolved anything; in fact, you've just made it worse. The original company may be in violation of the civil law, but you're counseling that the way to ethically resolve this civil offense is to commit a criminal act?
Slashdot Mirror
While C++ may lose to C in the executable size, C++ has minimal loss to C when it comes to speed. The mantra of C++ is you don't pay for what you don't use, and most compilers do a pretty good job of living up to it.
In the early days of Objective C, its performance was piss-poor due to its habitual late binding (putting off as many decisions to run-time as possible). C++ won, in part, because its early binding made for much faster code.
If you can't write C++ code which blazes by faster than a jackrabbit on amphetamines, that's a problem with your skill, not the language.
Note that in the below code, the value of x is cast to a void pointer y (implicitly, not explicitly--bad programming form, but done here only to show it can be done without the compiler complaining; explicit casting can similarly be done), and y is cast back to an integer variable. This code is legal ANSI C++, and compiles under egcs-2.91 with -Wall -ansi -pedantic without error or warning.
Production C++ code ought to use static_cast instead of these C-style casts (enhances type safety). I'm using C-style casts here for ease of reading.
#include <iostream>
using namespace std;
int main(void)
{
int x = 123;
void *y =
int z = *(int *)y;
cout << z << endl;
}
C is a loaded gun aimed at your foot; C++ is a Gatling gun aimed at your head. Describing C as much, much more powerful than C++ isn't just wrong, it's ridiculous.
Neither one is more powerful than the other. What the hell does "power" mean in a programming language, anyway? The word has no definition in a programming context.
The only relevant question, IMO, is which is the right tool for the job?
Sometimes, the job requires procedural programming. For that, procedural C++ or C is called for. Sometimes, the job requires object-oriented programming. For that, C++ or object-oriented C is called for. Sometimes, the job requires generic programming. For that, C++ or really hoary C is called for.
C++ is probably more versatile than C, but it comes at significant cost--compilers become complex, the STL is difficult to maintain, etc.
There is no clear "more powerful" language. Use the right tool for the job.
And insofar as operator overloading in C++... I use it all the time. Where's the problem?
Warning: I am a C++ hacker, and I like it a hell of a lot.
Answer: People are using C++. Every single program in The C Programming Language is a perfectly good and valid C++ program; in fact, Bjarne Stroustrup himself recommends reading The C Programming Language as a way to improve one's C++ skills.
The advantage of C++ is that it's a hell of a toolbox. You've got hammers, screwdrivers, chisels and even a fully-functioning wood lathe (watch me turn this chunk of hoary code into a table leg!). Good programmers use the right tool for the job.
And if the right tool for the job happens to be procedural programming, C (or procedural C++) is an entirely reasonable thing to do.
The proof, as they say, is in the pudding. I can definitely associate his work with Ron Rivest, for instance. Rivest wrote RC6, an AES candidate which had 15 rounds broken. Schneier wrote Twofish, an AES candidate which has fared much better. RC6 isn't going to be selected as AES (I'll wager $20 on it), but Twofish is still in the running.
Insofar as "Bruce Schneier, by his work, is not a cryptographer (nor is he a cryptologist)"... I've got to recommend that you talk to your dealer about the purity of your rock. Strictly speaking, a cryptographer is one who develops and devises codes and ciphers. Schneier has written lots of ciphers, ranging from the lousy (MacGuffin) to the profoundly brilliant (Blowfish, and maybe Twofish).
He has also published cryptanalytic results against the major AES candidates, including (I believe) RIJNDAEL. I like RIJNDAEL. Joan Daemen (I'm misspelling the name here) is a brilliant cryptographer, responsible for a lot of extremely high-quality stuff--and if Schneier, et. al., can cryptanalize RIJNDAEL, that says something about Schneier's skill.
Insofar as Applied Cryptography being shady, I'm going to have to ask you for some verification. How is his description of Blowfish "shady"? After reading his description of Blowfish I was able to implement it, from scratch, without looking at any source code. My version passed the Blowfish compatability vectors, so apparently his description was clear and concise.
Finally there is a better crypto book out there anyways: it called the Handbook for Applied Cryptography by Vanstone et al.
Err... no. The Handbook of Applied Cryptography (notice the name), edited by Menezes, Vanstone, et. al., is a very good book. I refer to it often. However, I refer to Applied Cryptography more--why? Because I want to know the accepted way of how to do something, not a formal proof that the accepted way works. If you want to know how to encrypt the last block of a CBC mode cipher so that the cleartext is the same size as the ciphertext, Schneier tells you this in the space of a paragraph or two. The Handbook of Applied Cryptography goes into much more mathematical rigor.
This is not to say that the Handbook of Applied Cryptography is inferior: it's not. The two books are meant for different audiences who need different things, and claiming that one is superior to the other is pretty specious.
His papers are imprecise and obvious
... Are you telling me that you could have cryptanalyzed RIJNDAEL?
Seriously. Get a grip. Schneier is no demigod, that much is true; he's a human being just like anyone else, and occasionally screws it up past all recognition (just like anyone else). However, he is a hell of a lot better than I am.
My own beef with Schneier is something totally different. Schneier works as part of a team, not a solo operator. His best work has always been collaborative, with Doug Whiting, Niels Ferguson, etc. While I don't begrudge Schneier his fame--I think he's more than earned it--I do wish that people, particularly Slashdotters and the news media, would realize that Schneier may be the crypto version of Buckaroo Banzai, but--just like Buckaroo Banzai--he's nothing without his crew of Hong Kong Cavaliers and Blue Blazes Irregulars backing him up.
In response to your first question (ought there to be a unified commenting standard), the answer is a loud, resounding "no". There is no single standard for documentation; the best you can say is there ought to be a standard for applications written in C, kernel modules written in C, written in , etc., and that's not a very satisfying answer.
There are some very good guidelines to follow, though. Guidelines are different from a standard in that they only prescribe general rules and principles, without any attempt to enforce strictness--the assumption being that the programmer is smart enough to know when to deviate from the guidelines.
I'll present my own guidelines for good comment practice here:
0. ENSURE APPROPRIATENESS
Writing your own code to descramble CSS is admirable, but that's not the place to include anti-MPAA screeds. Similarly, the documentation for function foo ought to talk about foo, not function bar, unless there are some states of bar which affect foo's behavior.
1. MAKE IT CONCISE
When I write code, I generally write two documents; the first is the source file (with comments), and the second is the design file (in SGML). The former has concise comments; the latter is where I go into detail as to what considerations went into the design.
Nobody wants to read a thirty-line comment in a source file. If a function is so complex as to require that degree of verbosity, it's a sure bet that you've made the function too Byzantine.
2. VERSION-CONTROL YOUR COMMENTS.
More times than I can count, I've been misled by comments. The original coder may have commented wonderfully, but subsequent coders made big revisions and never updated the comments or the design document. Something as simple as "Written 06 Jan 2000, last revised 01 Mar 2000" can be a great help... if your code has a datestamp of August 2000 and the last time the comments were revised was in March, that's a strong hint the comments may be out of date!
3. LEAVE BREADCRUMBS FOR FUTURE DEVELOPMENT.
If in your design document (if you have one) you say, "it'd be nice if we could include foo", then leave a breadcrumb in your code saying "I think foo could fit best in here". It doesn't have to be about functionality; it can be something as simple as "let's see about cleaning this function up, it's icky and slow".
Remember that comments are not written for you; they're written for the people who come after you (who, often as not, are you--just a couple of years older). Use comments to give them hints as to where known bugs exist, where things can be fixed, where bottlenecks are and so on.
4. DON'T OVERCOMMENT
Nothing annoys me quite so much as bondage-and-discipline documentation styles which require that every variable in a function be described. One-letter identifiers like i, n, j and so on do not need descriptions. If you're using them to do anything more than mere placeholding--keeping track of state for a loop, for instance--then you're using them incorrectly.
Your code ought to be clear and straightforward enough that you don't need to write reams of comments saying "the variable i stores state for foo which is passed through three levels of pointer indirection to bar".
5. USE TAGS
Tags are useful because they make your comments indexable. Try arranging your bugs as BUG_WISHLIST, BUG_NORMAL and BUG_CRITICAL. Then it makes it simple to search your code to find bugs which you already know about.
This sounds worthless, but it's surprisingly handy. The more you program, the more tags you'll find. The important thing is that you keep them reasonably short and consistent.
I am an employee of Network Associates and a programmer working on PGP.
We're looking into it. I can't say much more than that at this point. As soon as more information is known, I will post it as a reply to this thread. Hopefully, you'll see some official word on it here soon.
-- Rob
I am an InfoSec professional, but this is not professional advice. Moreover, I really like OpenBSD, so please don't take this as a BSD flame. :)
:)
The problem with buzzwords is that they so rarely mean what their obvious meaning is. When I see "secure by default", that tells me "I can install OpenBSD in its default install, throw Apache and my MTA-of-choice on it, and it'll still be safe". That's what secure by default suggests to me; that a clean install of the OS and the daemons you need to run your business will be secure, by default.
The problem with it is that this isn't anywhere near to the case. I've got lots of kudos for OpenBSD's large, distributed security audit. I think it's a brilliant idea, and I wouldn't mind seeing Linus say "okay, for the next six months all development is frozen and we're going to audit our codebase".
Unfortunately, security audits are not synonymous with security. (Trust me on this one.) Security is a process, not a product; it cannot be magically generated by anything, not even OpenBSD's vaunted audits. You run into Heisenberg's Catastrophe at some point--assuming that your auditing process was complete and accurate, your codebase is safe; but then you have to audit the audit process to make sure you didn't leave anything out... then you have to audit the audit of the audit... and so on.
These are the main problems with audits that I've found:
LIMITED MANPOWER. The scorn that Theo heaps on the Linux community is, in some sense, warranted. What Theo misses is that where Linux has a huge amount of manpower, mostly of limited skill, OpenBSD has a miniscule amount of manpower, mostly of fairly high skill.
The problem is that security audits are limited by manpower more than they are technical skill. A thousand coders of only amateur skill can go through code at a huge rate; it's not hard to spot unconstrained buffers (buffer overflows), pointers that never get free'd, etc. If they were only ten coders strong, it would not matter how much skill they had, they simply wouldn't have the manpower to do a thorough code review.
INCOMPLETE SECURITY AUDITS. OpenBSD's security audit means they have an extremely high-quality kernel and tools. When even ls has been audited, you know they're doing something. However, Apache, sendmail and other large programs have not been audited by the OpenBSD team. Putting an old, vulnerable version of Apache on an OpenBSD box exposes potential risk.
(Before the OpenBSD people accuse me of FUDding, let me emphasize potential. The root exploit against Apache/Linux might fail on Apache/OpenBSD, due to OpenBSD's security consciousness. The point here is not to say "Apache makes systems insecure"--it's to say that there are a lot of daemons running on modern boxen, and many of these daemons have not been audited.)
INCOMPETENT SYSTEM ADMINISTRATION. Most root exploits I've seen--regardless of operating system--have taken place due to incompetent system administrators. OpenBSD does some things right by shutting down all nonessential ports by default (as opposed to Red Hat, for instance), but these are just Band-Aid measures over the festering, necrotic wound of incompetent sysadmins.
INCONVENIENCE. One of the biggest motivations for people to bypass security precautions is that security is inconvenient. If a user bypasses a precaution, that's worse than if the precaution never existed in the first place. There's a difference between a sysadmin who says "all our passwords are secure, because we use shadow passwords and force our users to change them every month" and the sysadmin who says "I don't know if our passwords are secure, despite the precautions we take".
The former, more likely than not, has users who are so frustrated by the bondage-and-discipline security precautions that they leave their passwords on Post-It notes attached to their monitors. The latter probably has them, too, but at least isn't fooled into thinking he's safe.
OpenBSD has some very useful security precautions, yes--but the most useful precautions are those that are transparent to users (security audits, jailing daemons, etc). The more intrusive your security becomes, the greater the likelihood your own users are going to circumvent them.
LIMITED FEATURES. Remember that oftentimes security is enhanced by adding features. Adding ACLs, for instance, could be a boon to sysadmins everywhere and result in more secure boxen. Since OpenBSD's developers spend so much time auditing, though, they're significantly behind the pack when it comes to keeping current with other Unices.
... All that said, though, if I were setting up a network, all of my machines visible to the outside world (mailserver, webserver, etc.) would be running OpenBSD or Pit Bull or Trusted Solaris. Probably OpenBSD, due to the fact that I already know UNIX reasonably well and I don't need the bondage-and-discipline of Trusted Solaris (see "INCONVENIENCE" above).
But over-ruling the DMCA was certainly not his job.
The Supreme Court of the United States disagrees with you, as does the vast majority of Constitutional scholars in this country.
Any and every Article III Judge in the United States (and Kaplan is one) has a Constitutional duty to see that the law of the land is upheld.
The nation's highest law is the Constitution. It is therefore the required duty of all Article III judges to review laws which come before them for Constitutionality.
Judge Kaplan did so in this regard; he came to the conclusion that the DMCA's more odious provisions do not violate the First Amendment. Overruling the DMCA, if it is unconstitutional, is definitely his job...
... he just decided that source code is not worthy of Constitutional protections.
When the Supreme Court handed down a ruling that Andrew Jackson disagreed with, Jackson refused to execute the Court's order and commented: "[The Court] has made its ruling; now let it enforce it."
I'm tempted to write a letter to Judge Kaplan saying the exact same thing.
By the by--many lawyers and judges will disagree with me here, but I strongly encourage people to write letters to Judge Kaplan. Keep them polite, respectful and intelligent--trust me, you do not want to piss off a Federal judge. He will not respond to your letter, no matter how much he wants to; Federal ethics laws forbid him from responding to citizen complaints.
However, the First Amendment guarantees that we have the right to petition the Government for the redress of grievances. The First Amendment nowhere states that we can only petition our President and Representatives.
It's a kind of despair that hits with the increasing speed of the information age.
... [i]f you want it bad enough, you'll do it.
:)
In the 1970s a fellow named Alvin Toffler predicted that, at some point, technology would advance beyond people's ability to integrate it into their day to day lives. This phenomenon was called future shock (after the name of Toffler's book) or technoshock (the name I prefer).
My parents don't suffer from technoshock, which I used to find interesting--until I realized that they know technology has left them by the wayside, they don't have a whelk's chance in a supernova of catching up, and they don't care. It's that last bit which keeps them from suffering.
Geeks and hackers don't have this luxury. If we gave up caring, we'd stop being what we are. So all we can do is grab the future by the throat and hang on for dear life.
It's hard, yeah. But take what consolation you can from the fact that everyone is in the same boat you are. I don't know a single person in the industry who doesn't find themselves overwhelmed by the rapid change of pace. Your situation is not unique.
I hope that I convey the kind of feelings that depress those of us in the early stages of learning
I've been programming in C++ for ten years, C for almost as long, UNIX for seven years. Trust me, friend; those feelings plague people no matter what their level of learning is. There isn't a single day that I come to work, look over my code and find some stupid bug, and kick myself for errors which, I tell myself, a college freshman would be bright enough to avoid.
[W]hat do you do to catch up?
... First, stop trying so hard. That's the best advice I can give anyone who's trying their best to get current with the technology curve.
You shouldn't have to try in order to get good skills. The more you try, the more you'll fail; the more you fail, the more desperate you'll become; and once you get desperate, you're not going to be much use to anyone.
Stop trying and start playing. Little kids pick up computer science faster'n you can blink, mostly because they haven't yet been brainwashed into thinking that learning has to be drudgery. Grab some code which you think is interesting; go through it to study how it works. Sooner or later you'll find something that makes you say "you know, this could be changed..."
Maybe the code is unclear; maybe there's a fencepost (off-by-one) error; maybe there's a more optimal way to solve the problem. For whatever reason, you'll find something which could be just a little better if it were changed just a little... and then change it.
One of two things will happen. Your changes will either improve the program, or it won't. If your changes improve the program, then sit back and bask in the warm glow of "I just solved a programming problem and damn I feel good". If your changes don't improve the program, don't get frustrated. This just shows that there's some subtlety here you don't understand yet.
[M]aybe it comes down to straight motivation and drive
That, too. But don't forget to have fun.
I'll get it, eventually.
I've said this more times than I can count.
Every single time--every single time--I've managed to get it. (Admittedly, getting Motif programming took me years, but I got it.) I'm certain that Linus, Miguel de Icaza, Matthias Dallheimer and Alan Cox all say "I'll get it, eventually" a lot more often than you think they do.
Good luck. And if you need help, ask for it.
This isn't the Free Software Band-Of-Thugs. This is the Free Software Community. Communities exist for mutual help and support. So don't be afraid to ask questions, even stupid ones. But the flip side is that if someone asks you questions--even stupid ones--answer them patiently, honestly and as clearly as you can.
Good luck!
Warning: this is the rant of a long-time C++ hacker who hasn't looked at Objective C since he was in college.
PERFORMANCE
Objective C was, at the time it was introduced, dog slow. This was due to its "cleaner" design and the way it delayed as much as possible until run-time (both of which are, arguably, the Right Thing). C++, on the other hand, had (and still has) an extremely strict philosophy: you don't pay for what you don't use. If you don't use templates, you don't incur the overhead of them. If you don't use virtual functions, you don't incur the overhead of them. If you don't use <foo>, you don't incur <penalty of foo>.
CODE REUSE
Objective C invalidated an awful lot of existing C code. Now, Objective C's defenders will say "... it did no such thing! My program still compiles just fine under C, just as it does under Objective C!" With due respect to them, that's not the point.
One of C++'s selling points is that you can trivially call C++ from C functions. You can trivially call C from C++ functions. Mix-and-match as much as you like. Heck, you can even write C++ code in C.[*] You can't do that with Objective C. [**]
Objective C required a vast change in how programs were written (see below). C++ offered a slower, smoother slide into the world of OOP.
CONSTRAINED PARADIGM
C++ is, contrary to popular belief, not an object-oriented programming language (OOPL). Objective C is an OOPL. [+] This is another major reason why C++ won out.
C++ is equally at home with procedural programming, object-oriented programming, generic programming--heck, I've even seen functional programming done in C++ (admittedly, it was a nasty hack, but...). People who loudly trumpet C++'s object-oriented capabilities are, with all due respect, totally missing the point. Personally, I find generic programming to be much more breathtaking than OOP--but if I were to say "C++ is so cool because it's a generic programming language", I'd be missing the point.
The point is, you can use whatever paradigm you need to get the job done. The unpleasant truth of object-oriented programming is that it is not a panacea; while it does some things really well, there are other things it's lousy at. To really enjoy any benefit from Objective C, you must use an object-oriented solution, regardless of whether or not an object-oriented solution is called for.
This had the added side effect of making it very marketable to IT departments. Senior executives got to tell their bosses, "Yes, our entire IT department is working in C++ now"... and the techs got to keep on solving problems the same way they always had, and were able to take their time to slowly migrate things to C++. Management was satisfied that "we're using C++"; the techs were satisfied that "well, at least we can keep solving problems in the old C style while we come up to speed".
With C++, I'm free to use whatever solution I need, whether it's a generic solution, procedural, functional, object-oriented or what-have-you.
(Let me harp for another moment on generic programming. Damn, is it cool, and I wish more languages supported it. I think generic programming is a seriously overlooked part of programming. End the free advertisement for generic programming.)
[*] Don't forget, the first C++ compilers were really preprocessors that spat out C sourcecode. Everything you can do in C++, you can do in C... C++ just makes it a lot easier.
[**] At least, I've never had the patience to do it. I've tried a few times, but it quickly gets nontrivial.
[+] This is kind-of true. Without fully embracing OOP, you can't use any of Objective C's really cool features--you lose everything which distinguishes it from C. C++ allows you more flexibility in this regard.
... on Larry King Live, he claimed to have invented the Internet. Later on, his spokespeople claimed that he was exhausted, was speaking off-the-cuff and made an error. I'm inclined to believe him, just because it's so boneheaded of a mistake to make that I can see how it'd take someone to be falling-down tired to make it.
Spruce (here) is my preferred email client for UNIX. It's not quite as featureful as other clients, but is fairly stable.
Best of all, it supports GNU Privacy Guard. I've got a couple of minor quibbles with how it does things, but on the whole, it's my preferred email client today.
First, it's unlikely that Free Software will ever be found liable in court, due to the conspicuous disclaimers of warranty and liability which can be found with every Free Software license.
That's not the same thing as protection, though.
Remember that contracts are subservient to the civil and criminal law. It is not possible to construct a contract which violates the civil law; if such a contract exists, then the portions of it which violate civil law are null and void.
So let's say, for sake of argument, some state has a law on the books which says "for all software used in avionics, the manufacturer must provide a warranty". This is a plausible law; avionics is a life-and-death software situation, and it's entirely within the rights of a state to specify that life-and-death software be held to a higher standard.
Now let's say that an aerospace company wants to build an airplane, and decides to use a GNU tool as part of the software package. The engineering staff sees that there's a disclaimer of warranty, and sends a letter to the Free Software Foundation saying "hey, I'd like to use this software in our new plane, would you mind terribly if we did?"
Suppose the FSF says "sure, go ahead"--in writing, of course. The FSF thinks that the terms of the GPL apply; the engineer thinks that the terms of the state apply, and by giving the go-ahead, the FSF has acquiesced to this.
Now suppose that plane crashes, and lawsuits are filed. Suddenly there's a big lawsuit filed against the FSF; the aerospace company claims "we talked to them and we have this letter here permitting us to use their software; that overrides the GPL which they *thought* they were releasing it to us under, and that means the FSF *must* provide a warranty for this software".
The FSF says "But wait! This is a Washington state court, and we're from Massachussets. We weren't aware of Washington's required-warranty law, and had we been aware of it, we wouldn't have told them to go ahead--we told them `sure, go ahead', meaning under the terms of the GPL, with no warranty involved!"
Eventually, the case would go to the jury. The jury would come back with a decision, and it might not be favorable to the FSF.
This is just one hypothetical situation. There are many more you can construct. No matter what, though, it all winds up the same: in a civil trial, everything's irrelevant once the jury gets seated. If the jury is dead-set on saying that you're liable, then by God you're going to be liable whether or not you disclaimed everything.
The very short version:
Don't spend your time worrying about whether or not you can be held liable--you can. Spend your time making your software high enough quality that nobody will ever want to sue you for making a shoddy product.
Nah, it still holds together. The Oppenheimer Defense applies to just about anything. By your logic, I could come up with a way to synthesize smallpox in your basement, then take out a full-page ad in the New York Post with the instructions and a caption reading "HEY, IF YOU'RE A TERRORIST BENT ON ANNIHILATING THE WORLD, READ THIS!"
After all, an ad has a significant lawful use... to be read, right?
Basically, because he's misappropriating the term `hacker' and promulgating this distorted vision of hackers as being malcontents, ne'er-do-wells and geeks.
I once picked up a copy of 2600 just to see what the big fuss was about. When I leafed through it, I didn't find much that was, in my mind, hackish. There was an article about boxes and phreaking; about the NPA-NXX system of phone number allocation; about how to override the environmental controls of a Best Buy so to make everything a sweltering ninety-nine degrees.
Even though there's a disclaimer that says "2600 does not endorse any illegal activities", it's still an inescapable conclusion that most of the articles which appear in 2600 are written by petty criminals--extremely petty criminals.
There's hackish glory in knowing how phone numbers are allocated and how the NPA-NXX system works, or in knowing the security holes in a stock Solaris 2.7 installation, or--etcetera. Fill in the blank.
I work in information security IRL, and I know a lot of these things. Some of my best friends know a lot of these things. Sometimes, we sit down and have a couple of beers and talk about exploits, and even do penetration tests--against boxes we own, in highly controlled environments.
The typical 2600 article is written by, and for, frustrated techno-turks who have an axe to grind against society in some regard, and gets a vicarious thrill out of making a Best Buy a sweltering inferno for its customers. I don't see that there's anything commendable in that. I think people who do those things are criminals, hooligans and petty vandals--and I think those who encourage such behavior must shoulder some of the responsibility.
Is it legal to encourage that sort of behavior? Yes. That doesn't mean it's right.
The Oppenheimer defense ("I just built the damn thing, you're the one who's responsible for how you use it!") only works if (a) your creation has significant lawful use, and (b) you don't encourage irrational or illegal uses.
2600 claims that it doesn't encourage these uses. I think that a thorough reading of any issue will quickly show that their disclaimer is there strictly for legal protection, and they don't mean a damn word of it.
That's why I think Goldstein is a boil on the ass of the universe.
</RANT>
Every United States judge, without exception, is authorized to decide whether or not laws which come before them are Constitutional. The lowest magistrate (the lowest rung on the Federal judicial ladder) can declare laws unconstitutional (they never do this, of course--small worm, big freakin' hook, all that). District judges (the next ladder up) do it more often than magistrates do. Appellate judges are where the real judicial power is exercised; 99.9% of all judicial cases in the United States end at the appellate level.
We hear about Supreme Court decisions because the Supreme Court's jurisdiction is the entire United States, plus all of its territories and holdings. Appellate decisions only affect a few states; District and Magisterial decisions only affect the district in which they preside.
For instance, in Bernstein v. US, coming out of California District Court, District Judge Marilyn Patel declared certain portions of the ITAR/EAR to be unconstitutional. The very instant Judge Patel entered her ruling, those unconstitutional portions of ITAR/EAR were annulled--in fact, the instant she entered her ruling, those portions of ITAR/EAR were retroactively declared to have never existed. (Legally, unconstitutional laws are void "ab initio"--"from the very beginning". It's as if the laws were never passed.)
At some level of the Executive Branch, it was decided to appeal this decision. It went from a California District court to the Ninth Circuit Court of Appeals, which covers most of the West Coast. The Ninth Circuit Court of Appeals affirmed Judge Patel's ruling. Suddenly, those portions of ITAR/EAR were null and void throughout the entire Ninth Circuit.
Had the Executive Branch appealed the decision to the Supreme Court, and the Supreme Court heard the case, and the Supreme Court affirmed Judge Patel's ruling, those portions of ITAR/EAR would have become null and void throughout the entire United States, its territories and holdings.
No matter what the ruling is, what could it do?
Short answer: Precedent. Already there's caselaw from the Sixth and Ninth Circuits which holds that, in some instances, computer source code can be Constitutionally-protected speech. These cases have revolved only around cryptographic code, though; DeCSS is the first case where computer source code, without any qualifications, has been presented as warranting First Amendment protections.
If the judge rules (as I expect he will) that DeCSS possesses expressive content, a lot of the DMCA will be in jeopardy, and maybe UCITA, too. We (the hacker/geek community) will now have three different legal precedents to stand on in the event that future lawsuits are filed against us. "Don't like our programs?" we can say. "Tough luck! Free Software is Free Speech!"
This will scare the hell out of half the intellectual-property lawyers in the country, and will make the other half giggle with delight.
I don't like 2600. I think that Eric Corley/Emmanuel Goldstein is, mostly, a boil on the ass of the community. But if he gets the right to freely talk about DeCSS and how to circumvent access controls on DVDs (probably the only thing he and I will ever agree on), then I get the right to freely talk about things I find interesting which the Government would rather I didn't.
That, to me, is the most important thing which is coming out of the 2600 trial. I don't give half a damn what happens to Goldstein. I give a damn what happens to me. And if the law will protect Goldstein, how much more will it protect me?
This is the same logic Larry Flynt used in his First Amendment trial. It was good logic then, and it's good logic now.
Where does "treating like a human being" come in?
... was being deceptive in implying that the reporter could be required to open his backpack, show ID, etc.
It comes in because I feel that we all, as human beings, have a duty to treat other people with a modicum of courtesy. Sometimes this isn't possible, but as as a general moral principle, that's it.
The police officer
I didn't see any implication. I saw the police officer give a challenge (in the legal sense of the term--as in, `issued a demand'). I expect that the police officer was probably reasonably polite about this; "Please open your backpack, sir." Where's the implication? Even if it was "Open your backpack," it still wouldn't have any implication of it being nonvoluntary. "Open your backpack or else get arrested and then we'll open your backpack for you" is nonvoluntary (and, oftentimes, illegal).
If you choose to treat every police officer as if s/he is an unquestionable being whose every demand must be acquiesced to, that's your problem.
Insofar as deception go--the police are allowed to be tricky and cunning. Police are allowed to lie to suspects to elicit confessions; they're allowed to deceive suspects to get them to act in incriminating ways.
Even if you don't care if the officer sees what's in your backpack or what your name is, it's a service to society if you refuse.
Not really. Neither the law nor the Constitution permits you to withhold your name from authorities. You have the right to remain silent, you have the right to an attorney, you have the right to refrain from self-incrimination, you have the right to have a judge or magistrate approve warrants for searches of your property... but you do not have a right to refuse to give the cops your name.
Insofar as the resistance to illegal search goes, I'm in complete agreement with you. However, the search wasn't illegal. If someone shows up at a protest which is expected may turn violent wearing military load-bearing gear and acting belligerent to the cops, that's probable cause that the person may have violence in mind and as such, ought to be detained.
Police take WAY too much advantage of the average person's ignorance of the law in cases like these.
How do they take advantage of someone's ignorance? I own a 1995 Eagle Talon ESi, in very good shape and about 80,000 miles. I'm willing to sell it for $15,000, first-come first-serve.
Am I taking advantage of someone who pays me that much money, certain that they're getting a good deal? No. The Blue Book is widespread and easy to find. If you're paying $15,000 for a car which is only worth (optimistically) $10,000, that's your problem, not mine--caveat emptor.
Similarly, if you're ignorant of your rights as a citizen and you wind up not knowing enough to stand up for your rights when the police make demands of you, that's your problem, not the cops'--it's your responsibility, as a citizen, to know your own rights.
Unfortunately, the problem with Peltier's supporters is that they've never bothered to read the court transcript. (I have, after hearing Rage Against the Machine give a pro-Peltier speech. I was so moved by Peltier's plight that I rented Incident at Oglala and read the court transcript. It's amazing just how much you can learn by studying both sides of a story.)
As soon as you do, then I'll be happy to resume talking with you. Until then, you're a zealot who's looking to scream loudly about the abuses of the system.
Screaming about abuse is not the same as quietly demanding justice. Governments don't give a damn about the former; the latter sort of person scares the hell out of them.
Peltier has been in jail for murder. When you get right on down to it, Peltier was accused of common crimes and had his day in court just like anyone else. Peltier is not someone special. He is a common criminal, and is being treated like any other common criminal.
While many people believe there's a Government conspiracy to keep Peltier in prison for political reasons, I find that very hard to believe. I don't think the Government is competent enough to pull off a good conspiracy.
1. R-E-S-P-E-C-T (DIS, THAT IS)
If you want to get arrested, nothing tells the cops "troublemaker" quite like someone whose first word to them is "fuck". In fact, for maximum get-arrestedness, make sure that about every fifth spoken word is an invective. Feel free to mix in words like "pig", "lackey", "fascist" and "thug" with the more conventional vulgarities.
Do not: "I'm sorry, Officer, if you'd like to see my bag, I'd like to see your warrant." This is too polite and subtle.
Do: "Eat penguin shit, you ass spelunker. No fucking way am I letting you pigs get in my bag without a Goddamned warrant!"
2. WHO'S DA MAN? (YOU ARE!)
Never forget who's the really cool/hip/in-charge guy. You are. And if you're feeling generous, you can bestow Magic Coolness on your buddies, too. That means that anyone who gets in your way, even for the most routine of things, is automatically Naughty In The Sight Of God, and deserves a good smiting.
Do not: "Identification? Why, sure, Officer, here's my driver's license." This actually treats the officer like he's a human being who's doing a job. Since the officer is getting in your way and is Naughty In The Sight Of God, this is a no-no.
Do: "You can have my identification when you pry it out of my COLD DEAD FINGERS! LEONARD PELTIER WAS FRAMED! YAAAAAHHHHHHHH!" Even this is not optimal. For best effect, use various profanities and insults liberally (see point 1 above).
3. ALL THE WOMEN LOVE DANGEROUS MEN.
Let's face it. Nothing turns on those lady cops quite as much as a sweaty, smelly, foul-mouthed Lothario. They want your attentions and affections. If they say otherwise, they're just playing hard to get.
Do not: "I'm just heading to the Port-A-Johns, ma'am." This is respectful, it treats her as if she's not Naughty In The Sight Of God for getting in your way, and you're missing on a perfect opportunity for police poontang.
Do: "Yeah, baby. I'm just heading to the Port-A-Johns... say. Does the little piggy wanna get porked?" Rude, crude, crass and utterly offensive to any woman within earshot. This is just about perfect.
4. REMEMBER:
No matter what, The Man is trying to get you down. The Man is trying to break you like a twig. The Man wants you dead, crushed underfoot like a snake.
Do not: "Thank you for helping me with directions, Officer." Don't thank the pigs. Everything they say is a lie.
Do: "Yeah, I'm sure you'd LIKE me to believe that the street ahead is closed! <shoves aside cop, charges forward anyway>"
* * * * *
If you do all the above diligently, you, too, can get arrested! And afterwards, you can write a self-important screed about how evil The Man is and how Naughty In The Sight Of God the Man is, and how your rude, subhuman, and utterly crass behavior is actually the culmination of two hundred years of American civilization.
OOP is not meant to be a Holy Grail, despite what many people claim. OOP is meant to be efficient, which is not the same thing as fast during run time.
... will NEVER surpass, or even equal traditional functional programming" just shows that you don't know OO very well.
Sometime, write a basic program in C which accepts input from a user (like their name, for instance) and then writes "Hello, <username>!". Make sure that it does bounds checking; that it has no arbitrary limits on how long a user's name can be; that it's well-behaved in the case of a crash; that it's this, that and the other. It takes pages and pages of code to write a simple, basic program well in C, because C is an inherently low-level language.
C++, on the other hand, simplifies all of this for you. Just do a "string username; cin >> username" and you get a boatload of functionality.
C++ is more efficient in that case, because processor time is cheap and my time is worth a hell of a lot. In that case, it's better to minimize my time rather than the processor's time. This is the way it is for most software projects, by the by; programmer time costs much more than computer time.
There are situations when this is reversed, where it's more efficient to have teams of programmers working for years on a program than it is to trust the processor to do the Right Thing at run-time. The Space Shuttle is a good example of this. The people who write code for the shuttle's flight computers use HAL/S as a development language ("High Order Assembly/Shuttle", if I recall). HAL/S is ugly. It's just about the last language I'd use for any given engineering task. But it works perfectly fine for the Shuttle, because it's more important that the programmers do their job right than it is that the language is perfect.
The cost of Shuttle programming is astronomical (pardon the pun). However, in almost 25 years of operation they've never had a single catastrophic crash (save the 1986 one, which was caused by a catastrophic failure of other systems which interrupted computer operation). Try getting that sort of uptime from a UNIX box.
Moral of the story: OOP isn't a panacea. Neither is traditional procedural programming. Saying that "OO
OO isn't competing with procedural programming. It doesn't need to. The two paradigms exist completely independent of each other, and neither one of them needs to justify their existence. They just are, and wise programmers use whichever one is proper for a given application.
Alfred J. Menezes, Handbook of Applied Cryptography.
Schneier, Bruce. Applied Cryptography, Second Edition.
Kissinger, Henry. Collected writings. If you want to know crypto, you also need to know the political climate which created crypto; and when it comes to Cold War history, nobody tells it like Kissinger.
The ICSA Guide to Cryptography. Very light, but it's good for a beginner's introduction.
Kahn, David. The Codebreakers.
Bamford, James. The Puzzle Palace.
Gaily, Jean-Loup. The Data Compression Handbook (? on the name; it's been a while).
Knudson, Jonathan. Java Cryptography.
Elliote, Rusty (?). Java I/O.
Halsall, Fred. Can't think of the name for the life of me, but it's a monstrously big book about network communications. Very good stuff, even if it only has one chapter on communications security.
Let me get this straight.
* The company is illegally depriving a programmer of revenue,
* The "Ask Slashdot" question is about how to ethically resolve this situation,
* And your advice is to COMMIT A FELONY?
Insurance fraud is a serious offense. It's not "Sure, the insurance company does lose but who cares about them, right?" You've just changed the illegal-deprivation-of-revenue issue from the aggrieved programmer to the insurance company.
You haven't resolved anything; in fact, you've just made it worse. The original company may be in violation of the civil law, but you're counseling that the way to ethically resolve this civil offense is to commit a criminal act?
That's just plain bad advice. Period.