The gist of this (even excluding the harm done to non-American participants) is that law is being made without the benefit of the full set of protections written into the US constitution[...]
Well, since the treaty-making process is spelled out in the constitution, this isn't the case.
In short, making law via treaties is a loophole entirely unanticipated by the Constitution, and an amendment (or Supreme Court ruling) is needed to abolish it.
Treaties do not make law...in essence, they are little more than Gentlemen's Agreements between countries. In this case, if congress passes no laws to enforce this treaty within our borders, all it is good for is wiping your bottom.
Would they still be complaining though, when someone organized a few skilled coders and find some serious holes in Windows that haven't surfaced yet, and send a fix to MS to include in a patch? I wouldn't think so.
They would be when that patch ws released under the GPL..."you can fix this bug, but you have to realease all your code for free...and if you fix it yourself, and it looks like our code...."
Just how, *how* are you going to find a geek that is impartial?
They don't need an impartial reviewer, even if that is what they claimed in the article. Courts seek truth through combat, even if the weapons are verbal, not physical. Each side gets people to say that their version of the truth is "The Truth(tm)", and then do their best to discredit the other side. This will be no different; the states will get Microsoft-hateing geeks to say "look, this can be taken out of the code, and so can this, and so can..." and Microsoft will get MS-loving geeks to say "no, it can't, because..."
Sounds good in practice, but too many developers when put in this situation, will trap an Exception and throw it away. Making code sitting on top, not aware of what happened, which can make debugging a biatch.
Yeah, that happes from time to time, but at least you know that the code you are calling isn't throwing an excpetion...
I spent a few hours some time ago trying to figure out why our code was dying in the middle of a particular function, only to realize that an exception was being thrown by a class a few layers down, and no one had bothered to update the throw() spec. At least if it was in java I could have looked at the top class and seen an empty catch(){}
Also, how will a run time exception screw things up and make it hard to debug? Thats what a stack trace is for.
RuntimeExceptions don't have to be declared or caught; such as ArrayIndexOutOfBoundsException or DivideByZeroException.
The way Java deals with it, you should be aware of any and all errors that you will need to handle.
I agree, but it should not be crammed down your throat at compile time.
Yes, it absolutly should. One of Java's goals was to make it hard for a programmer to screw up. Not telling someone that a function you wrote is throwing the exception that is crashing your code is a nice way to crew up. These things are prety easy to keep track of in small, one man projexts, but as complexity grows, the fact that you have to actually declare that something is being thrown saves lots of headaches. In fact, I would be surprised if most style guides and coding standards people use here don't requiere the same in C++; ours do.
I think this is much better than having tons of confusion over similar method names with grossly different semantics, figuring out which parent class a virtual method is tied to, dealing with virtual vs non-virtual inheritance, and the tons of other things that make deciding through inspection who exactly implements the bar() method on your class foo next to impossible without having 4 monitors.
Make every function virtual, which Java already does, and force a class to 1) implement a function itself, or 2) specify which parent to call from if an identical function is found in 2 or more parents. No more triangle problem.
"The only point that didn't made sense in this summary was the one about "source code being useless"
It would have been better, perhaps, to say "for most users, source code is useless."
I remember when I was first getting started, and I head about Open Source. "Hey, cool, I can teach myself to write a word processor!" The truth, though, was that I couldn't. The code to any non-trivial program is going to be very hard to follow if you don't have someone walking you through it, or loads of time to work it through. And that's if you're a programmer. If you aren't, all the source code is good for is taking up space on your hard drive.
Personally, I find it interesting that BSI is going after DAoC, calling Mythic a "software giant," while ignoring the more established compettion in EverQuest producer Sony, Asheron's Call producer Microsoft, and Ultima Online producer Electronic Arts. Mythic's only product at this time is Dark Age of Camelot, which was released last October."
Mythic doesn't have the money/lawyers to throw at the case that the others do...so it will be easier to win a precedent-setting case against them, and then go after the others.
IMHO, there are three chief reasons code is vulnerable.
Time. The article was right about this one. If you look through our source code, you can see a definate difference between the "we've got all the time in the world, so follow the style guide to the letter, comment everything, and desk check it all before you send it to test" code and the "beta is due on Monday, so tell you girlfriend to have a nice weekend, and could you get some Code Red on the way in, we're going to be here a while" code.
When you are trying to get code done fast, one is much more prone to looking only at the stated goal of the code (i.e. it takes file X, converts it to format Y, and sends it to machine Z) and ignoring things like modularity and security. One tends to be much more concerned with "how do I get this to work" than "how can some one get this to break".
Ignorance. I don't know a whole lot about buffer overflows, or gaining root when I shouldn't have it, etc. I've got a book on it (which I'm sure my sys admin would love to see sitting on my desk), but the fact of the matter is that most colleges don't doa whole lot of teching in this area; what people know about security holes is usually because they hack around (either on their system or someone elses), or they got hacked. The industry would be a lot better off if schools were teaching woul-be programmers what people will try to do to their systems, and how to avoid it.
Over Reliance on the OS. At least in Microsoft's case, I beilieve they are trying to do too many things at the OS level, which means a security flaw that effects one program can often be opened up to exploit all programs. Take, for example, the registry. If one program's.ini file get's nabed, it probably isn't as big a deal as if the entire system registry gets nabed.
Windows 2000 seems to work pretty well. If anything, IIS needs more of Microsoft's attention. At least in the security department.
So far, I've had pretty good luck with WinXP, but I would never deploy it in an environment where security was an issue. The same holds true for IIS. I have been looking over a proposal the last couple of days that suggests WinNT because of it's "integrated security features." I think my first task will be to run a search and replace for "WinNT" and "Solaris."
I have only had XP crash on me a couple of times, and I really do consider it the best job Microsoft has ever done. Still, I look on it as a home OS...it's quick, it's easy, my Java programs run on it, and I got tired of playing with Linux a while ago. But for a workstation or server? *nix, without question.
I actually have seen a few programs in which there were more compiler errors than lines, but they were, of course, quite short.
Heck, I've written a few of those, back in the day...
The point of the article is that if you have a large, slow Java application, you can compile to run natively on a given platform to increase it's speed and reduce the disk and memory requirements
Well, yes and no. There are some very slick Vms out there, and some very lazy compilers, though in most cases, you are correct, native code will execute faster than interpreted code.
The disk requierments, though, can in the long run be larger for native code apps. The VMs have a lot of common tools (i.e. all of the java.* classes) available for any app that needs them. If you plan to compile to native code, you hav to link these in. You can save space by only linking in the libraries you need, but will still end up loosing space when you start installing mulitple applications that all include the SWING packages.
I have been a bog fan of Java for some time, but the need for a VM held me back from a full-out endorsement for some time...it seemed like I was writing toy code because I needed another program to do anything with it, and I didn't like leaving all of those class files laying around. I have gotten over a lot of this, especially once I learned how to make an executable JAR file, and considering the widespread use of DLLs. Plus, I realy like being able to work on my text editor on my home WinXP box, and take it in and use it on our Sun achines.
Still, I'm downloading one of those compilers right now. Why? Because native Java would just be neat. I probably won't even use it that much, but it will be nice to see that it can be done.
I don't at all believe that most any student would graduate with a "productive" knowledge of C++, for example, based solely on their educational experiences. There just isn't enough depth to class projects. Additional work experience (internships, etc.) could give them this experience...
Or sitting in front of their computer until 3am, bucause they almost have it...that's what separates those of us who are doing what we love and those of us who love the money they thnk they will be making.
An undergraduate should come out of school with a solid grasp of Pascal, Forth, Scheme, and MIX or SICTOY.
Interviewer: So what can you do?
Interviewee: Well, I am great at scheme, and I know some Pascal.
Interviewer: What about C++? Java? C?
Interviewee: uh....
Interviewer: Well, thanks for dropping in...
That's a great way to waste $30 grand.
An undergraduate should come out with a set of logical problem solving techniques, familiarity with data structures and algorithms, and a working knowledge of C++, java, SQL, HTML, maybe some perl, UNIX, and Windows. If you have a CS degree and don't have these tools, you are ill suited for darn near any job that degree should prepare you for.
Theory can be a very edifying thing...but when I go to work, it's still mostly for loops and function calls.
/*Bob Jones, Tom Smith, and Sally Struthers helped me with this section of code*/
I post most of my school code on the web, and GPL it. If people can learn from it, bully for them. All my professor asks is the above coment, so he knows what came from where.
There is a balance between teaching codeing skill and problem solving skill...it's a question that I can't easily answer other than to say "in this situation, I would..." There is a marked difference between looking at someone's source code and using it to help sooth your algorithmic or syntax woes, and copying and pasting.
I don't know...do you got to college for grades or to get an education.
The grades I recieve are supposed to reflect my ability with a given subject matter. This is why I do not like grading on a curve; if I do high quality work, I expect high quality grades.
If you put one exceptional programmer in a class with beginning students, he will naturally recieve high grades, curve or no curve, but if you put him in a class with other exceptional programmers, he may not. This is not fair, nor is it logical. Good work does not become less so because others have shown the ability to also do good work.
Slashdot Mirror
The gist of this (even excluding the harm done to non-American participants) is that law is being made without the benefit of the full set of protections written into the US constitution[...]
Well, since the treaty-making process is spelled out in the constitution, this isn't the case.
In short, making law via treaties is a loophole entirely unanticipated by the Constitution, and an amendment (or Supreme Court ruling) is needed to abolish it.
Treaties do not make law...in essence, they are little more than Gentlemen's Agreements between countries. In this case, if congress passes no laws to enforce this treaty within our borders, all it is good for is wiping your bottom.
Would they still be complaining though, when someone organized a few skilled coders and find some serious holes in Windows that haven't surfaced yet, and send a fix to MS to include in a patch? I wouldn't think so.
They would be when that patch ws released under the GPL..."you can fix this bug, but you have to realease all your code for free...and if you fix it yourself, and it looks like our code...."
Congradulations!
Just how, *how* are you going to find a geek that is impartial?
They don't need an impartial reviewer, even if that is what they claimed in the article. Courts seek truth through combat, even if the weapons are verbal, not physical. Each side gets people to say that their version of the truth is "The Truth(tm)", and then do their best to discredit the other side. This will be no different; the states will get Microsoft-hateing geeks to say "look, this can be taken out of the code, and so can this, and so can..." and Microsoft will get MS-loving geeks to say "no, it can't, because..."
Sounds good in practice, but too many developers when put in this situation, will trap an Exception and throw it away. Making code sitting on top, not aware of what happened, which can make debugging a biatch.
Yeah, that happes from time to time, but at least you know that the code you are calling isn't throwing an excpetion...
I spent a few hours some time ago trying to figure out why our code was dying in the middle of a particular function, only to realize that an exception was being thrown by a class a few layers down, and no one had bothered to update the throw() spec. At least if it was in java I could have looked at the top class and seen an empty catch(){}
Also, how will a run time exception screw things up and make it hard to debug? Thats what a stack trace is for.
RuntimeExceptions don't have to be declared or caught; such as ArrayIndexOutOfBoundsException or DivideByZeroException.
The way Java deals with it, you should be aware of any and all errors that you will need to handle.
I agree, but it should not be crammed down your throat at compile time.
Yes, it absolutly should. One of Java's goals was to make it hard for a programmer to screw up. Not telling someone that a function you wrote is throwing the exception that is crashing your code is a nice way to crew up. These things are prety easy to keep track of in small, one man projexts, but as complexity grows, the fact that you have to actually declare that something is being thrown saves lots of headaches. In fact, I would be surprised if most style guides and coding standards people use here don't requiere the same in C++; ours do.
I think this is much better than having tons of confusion over similar method names with grossly different semantics, figuring out which parent class a virtual method is tied to, dealing with virtual vs non-virtual inheritance, and the tons of other things that make deciding through inspection who exactly implements the bar() method on your class foo next to impossible without having 4 monitors.
Make every function virtual, which Java already does, and force a class to 1) implement a function itself, or 2) specify which parent to call from if an identical function is found in 2 or more parents. No more triangle problem.
"The only point that didn't made sense in this summary was the one about "source code being useless"
It would have been better, perhaps, to say "for most users, source code is useless."
I remember when I was first getting started, and I head about Open Source. "Hey, cool, I can teach myself to write a word processor!" The truth, though, was that I couldn't. The code to any non-trivial program is going to be very hard to follow if you don't have someone walking you through it, or loads of time to work it through. And that's if you're a programmer. If you aren't, all the source code is good for is taking up space on your hard drive.
Personally, I find it interesting that BSI is going after DAoC, calling Mythic a "software giant," while ignoring the more established compettion in EverQuest producer Sony, Asheron's Call producer Microsoft, and Ultima Online producer Electronic Arts. Mythic's only product at this time is Dark Age of Camelot, which was released last October."
Mythic doesn't have the money/lawyers to throw at the case that the others do...so it will be easier to win a precedent-setting case against them, and then go after the others.
IMHO, there are three chief reasons code is vulnerable.
.ini file get's nabed, it probably isn't as big a deal as if the entire system registry gets nabed.
Time. The article was right about this one. If you look through our source code, you can see a definate difference between the "we've got all the time in the world, so follow the style guide to the letter, comment everything, and desk check it all before you send it to test" code and the "beta is due on Monday, so tell you girlfriend to have a nice weekend, and could you get some Code Red on the way in, we're going to be here a while" code.
When you are trying to get code done fast, one is much more prone to looking only at the stated goal of the code (i.e. it takes file X, converts it to format Y, and sends it to machine Z) and ignoring things like modularity and security. One tends to be much more concerned with "how do I get this to work" than "how can some one get this to break".
Ignorance. I don't know a whole lot about buffer overflows, or gaining root when I shouldn't have it, etc. I've got a book on it (which I'm sure my sys admin would love to see sitting on my desk), but the fact of the matter is that most colleges don't doa whole lot of teching in this area; what people know about security holes is usually because they hack around (either on their system or someone elses), or they got hacked. The industry would be a lot better off if schools were teaching woul-be programmers what people will try to do to their systems, and how to avoid it.
Over Reliance on the OS. At least in Microsoft's case, I beilieve they are trying to do too many things at the OS level, which means a security flaw that effects one program can often be opened up to exploit all programs. Take, for example, the registry. If one program's
Yes, and that's why we have C#.
;-)
I was going to learn C#....so I opened up one of my Java programs, and replaces all the "String"s with "string".
Yes. I was kidding.
fair enough.
Windows 2000 seems to work pretty well. If anything, IIS needs more of Microsoft's attention. At least in the security department.
So far, I've had pretty good luck with WinXP, but I would never deploy it in an environment where security was an issue. The same holds true for IIS. I have been looking over a proposal the last couple of days that suggests WinNT because of it's "integrated security features." I think my first task will be to run a search and replace for "WinNT" and "Solaris."
I have only had XP crash on me a couple of times, and I really do consider it the best job Microsoft has ever done. Still, I look on it as a home OS...it's quick, it's easy, my Java programs run on it, and I got tired of playing with Linux a while ago. But for a workstation or server? *nix, without question.
I actually have seen a few programs in which there were more compiler errors than lines, but they were, of course, quite short.
Heck, I've written a few of those, back in the day...
Being conservative, there is about 1 bug per line of code in, say, Windows 2000.
Are you kidding? You couldn't get one bug per line if you tried, at least if you wanted the thing to comile.
Yeah, it's MS' fault you either get hit with a 6 month old bug or open .exe or .vbs attachments.
No, but it is there fault that there browser opens it automatically, and that VBS has no security checks in place.
It's a pretty cool idea, but CPUs don't supply some features that make Java (and other interpreted languages) so cool.
I've had this discussion with a lot of people...
"You can't do [xyz] in C, but you can in [language of choice]."
"Really? What do you think the [language of choice] interpreter is written in?"
The point of the article is that if you have a large, slow Java application, you can compile to run natively on a given platform to increase it's speed and reduce the disk and memory requirements
Well, yes and no. There are some very slick Vms out there, and some very lazy compilers, though in most cases, you are correct, native code will execute faster than interpreted code.
The disk requierments, though, can in the long run be larger for native code apps. The VMs have a lot of common tools (i.e. all of the java.* classes) available for any app that needs them. If you plan to compile to native code, you hav to link these in. You can save space by only linking in the libraries you need, but will still end up loosing space when you start installing mulitple applications that all include the SWING packages.
I have been a bog fan of Java for some time, but the need for a VM held me back from a full-out endorsement for some time...it seemed like I was writing toy code because I needed another program to do anything with it, and I didn't like leaving all of those class files laying around. I have gotten over a lot of this, especially once I learned how to make an executable JAR file, and considering the widespread use of DLLs. Plus, I realy like being able to work on my text editor on my home WinXP box, and take it in and use it on our Sun achines.
Still, I'm downloading one of those compilers right now. Why? Because native Java would just be neat. I probably won't even use it that much, but it will be nice to see that it can be done.
I don't at all believe that most any student would graduate with a "productive" knowledge of C++, for example, based solely on their educational experiences. There just isn't enough depth to class projects. Additional work experience (internships, etc.) could give them this experience...
Or sitting in front of their computer until 3am, bucause they almost have it...that's what separates those of us who are doing what we love and those of us who love the money they thnk they will be making.
An undergraduate should come out of school with a solid grasp of Pascal, Forth, Scheme, and MIX or SICTOY.
Interviewer: So what can you do?
Interviewee: Well, I am great at scheme, and I know some Pascal.
Interviewer: What about C++? Java? C?
Interviewee: uh....
Interviewer: Well, thanks for dropping in...
That's a great way to waste $30 grand.
An undergraduate should come out with a set of logical problem solving techniques, familiarity with data structures and algorithms, and a working knowledge of C++, java, SQL, HTML, maybe some perl, UNIX, and Windows. If you have a CS degree and don't have these tools, you are ill suited for darn near any job that degree should prepare you for.
Theory can be a very edifying thing...but when I go to work, it's still mostly for loops and function calls.
/*Bob Jones, Tom Smith, and Sally Struthers helped me with this section of code*/ I post most of my school code on the web, and GPL it. If people can learn from it, bully for them. All my professor asks is the above coment, so he knows what came from where. There is a balance between teaching codeing skill and problem solving skill...it's a question that I can't easily answer other than to say "in this situation, I would..." There is a marked difference between looking at someone's source code and using it to help sooth your algorithmic or syntax woes, and copying and pasting.
I don't know...do you got to college for grades or to get an education. The grades I recieve are supposed to reflect my ability with a given subject matter. This is why I do not like grading on a curve; if I do high quality work, I expect high quality grades. If you put one exceptional programmer in a class with beginning students, he will naturally recieve high grades, curve or no curve, but if you put him in a class with other exceptional programmers, he may not. This is not fair, nor is it logical. Good work does not become less so because others have shown the ability to also do good work.