Slashdot Mirror
Why Coding Is Insecure
Stuart of Wapping writes "Even patches are not safe, especially if they come from a closed background (maybe) - An interesting article on why coding, is naturally insecure, from SecurityFocus."
← Back to Stories (view on slashdot.org)
The root of the problem lies in the fact that the program/product has to be released by a deadline. Causing common sense and good coding practise to be thrown out the window due to the fact that you'll lose you job if you don't do it.
Deadlines are normally imposed by companies trying to earn a living through the development of software.
Then it would be a good idea to think that the Open Source community, not faced with deadlines, would be able to code the programs in a more ideal situation, leading to code that has a higher degree of elegance and security than code developed by companies attempting to make money from it.
Then you have the flip side of that, where the software may perpetually never reach a state of stableness since it is contunually in flux. But, how you view this state is totally dependant on your point of view.
At least the code in flux has a higher chance of adapting to it's environment and thus surviving over the slower to adapt Closed Source code.
The article is surely right about their comment about the throw-away mentality with assignment. But there are exceptions: at my University there is a so called "Software Engineering" degree, where the emphasis is on good code with good documentation and many test-cases. Correct code only amounts to 50% of the final mark; the other half comes from documentation, comments, testcases and how well you followed the style-guide. I quite like it, because the assumption is that basically all software in todays world simply sucks.
-- The plural of 'anecdote' is not 'data'.
Often the designer doesn't consider the bigger picture, how this piece fits it. It can be as simple as not requiring verification on input.
Coders if rushed, inexperienced, or simple bad (like rafts of people who suddenly became "programmers" in 1998-2000 when demand was extemely high, even though the only had a couple classes and were really english, anthropology, history, or other majors, just to fill positions) will fail to see the lapses left by designers and build porous code.
Lack of review or review that so anal it's focus is spelling errors in prompts or whether there's enough documentation lines, but fails to identify where secure practices are not followed. Well, don't get me started. ;)
Last, Q/A, everyone knows Microsoft's Q/A is called ship it out and let customer support pick up the bug reports and then sometimes charge the people reporting for the fix. Q/A is often the first department cut in layoffs, because management underestimates its importance. To bad, like the Enron execs, they won't take a cut themselves to save the product and the company. Good Q/A needs to ask the unthought of questions, what happens if I do this instead of what's expected?
Perhaps somewhere in the evoltion if IT that has lowered programmers from the status of mystical wizards to grunt code jokeys, management will recognize that code, even new products, aren't just some big patch and give it the attention and personnel it really deserves.
A feeling of having made the same mistake before: Deja Foobar
Security Focus is redirecting to google. Which has a cache of the page, please use that instead.
w C: www.securityfocus.com/infocus/1541+&hl=en
http://www.google.com/search?q=cache:M13ch6-wvb
Strange but this article, albeit raising some intersting issues, seems to focus on excusing Microsoft flaws in developpement.
The article states that security holes are inherent to developement. That's OK, but what about their frequency ? Have a look at, let's say, Apache vs IIS
The question isn't if the code has security flaws. It certainly has. The point is the methods you use to avoid it. I think OpenSource has a way of resolving sercurities issues. OS has an army of benevolent geeks at his disposal. Competent people that know how to write a patch or at least submit a bug report.
On the other hand, MS only proposed a bug report interface with the recent XP.Sorry but, a Bill Gates company-wide memo to write better code is a PR operation, not a method.
To have any hope of writing secure software, a programmer first has to be aware that a problem exists. Aware of issues like safely handling user input and securely transporting data (and when it's appropriate and when it's pointless).
Once a programmer is aware of the existance of these issues he can start learning about all of the technical problems of writing secure code. In a UNIX environment, it's things like not exposing unnecessary parts of the filesystem to external users, and not blindly writing to files in /tmp, and not trusting your PATH or your IFS in privileged scripts.
Forget focus, we need education.
Suddenly design and coding style are thrown out the window in favor of down and dirty "do what works, we'll fix it later" coding. Initially some of the more idealistic (and typically youthful) coders feel that this sort of programming is wrong; this feeling usually passes quickly under the tutelage of the more experienced team members.
When code has to be done before a certain deadline (usually yesterday), this kind of shit always happens. I happen to be one of those idealistic (youthful) coders, and cringe thinking about what sometimes goes into released software. Is it any wonder why there are so many bugs in software? There is never even time to design, let alone test.
Why does this happen? No one really has perfected the art of accurately estimating projects. So you end up taking a quick look at the project's complexity, compare it to something you did before, and tell them how long that previous project took. Then when you give sales/management the time estimate (which is usually bogus anyway), they just ignore it and continue on with their own schedule.
Then you have sales/marketing types who consider software to be "magical." They don't have a clue how it's designed, written, and tested. All they see is something in a box that they have to sell. So when they ask for more features (as if you simply add them like you add flour to a recipe), and an engineer tells them that rushing it out may lead to security holes, etc. etc. they blank stare.
Where I work there are people, people who're responsible for an important part in a project, who can't understand why returning pointers to variables on the stack (from functions in c/c++) is bad. When this happened to one guy, he blamed the library he was using (an in-house library we're currently developing). When a colleague checked out the code he was horrified that the guy did just that, returned a pointer to this local variable.
But how do you differentiate between good and bad programmers? First of all I think a good programmers have to really enjoy programming. When I went to college (software development degree), I coded a lot of stuff in my spare time (I'm not saying that I'm a particulary good programmer, but at least I'm better than some of the other guys at work :). Not everyone does that, some hardly complete their programming assignments. This means that after some years of college, they will get their degree but they can't write a good program. But they will still get a job.
When writing software, especially in C, C++, you have to have a good knowledge of how stuff actually works. How virtual functions work, the difference between the stack and the heap, what happends when objects get out of scope and stuff like that. This stuff may be a boring part of the programming course, but it is actually very important. One problem is that in some places people don't learn C or C++ at all, only Java, and thus they don't need to learn most of this stuff. (Although they maybe have to learn a lot of java-specific stuff, such as how the garbage collector works etc).
The problem, as I see it, isn't that there are too many inexperienced programmers, just too few of the good ones. Another problem is the tool. Many projects is written in C or C++, which pretty much allows you to do everything. It is possible to write robust programs in C++. If I should manage a large C++ project, one of the first thing I would to is to ban almost all use of pointers and C-style arrays. Smart pointers with reference counting, array-classes with optional boundschecking and things like that. Why use char* when you can use std::string (or your own string class). Another solution is to not use C/C++ at all, but in many cases this is just not an option. And I think that C++ is a really powerful language, which with a tiny bit of effort by the programmer(s) can be a robust language, even for "newbies".
"Well, duh."
In my opinion, the article is extremely badly written. Also, it is nonsense, as is easily proven by giving a link to another operating system:
Open BSD: Four years without a remote hole in the default install!
If the Open BSD team can make a secure operating system as volunteers, Microsoft, with a reported $33 billion in the bank, could take one of those billions and clean up their code.
Microsoft's security problems come partly from feeling that they don't have to care, apparently.
Also, maybe there is some secret U.S. government surveillance agency that requires that Microsoft operating systems not be secure. For years the U.S. government tried to prevent cryptography. For example, see these notes from the Center for Democracy and Technology: An overview of Clinton Administration Encryption Policy Initiatives. The notes say, "The long-standing goal of every major encryption plan by the [U.S. government] has been to guarantee government access to all encrypted communications and stored data."
It is not impossible that software insecurity is secret U.S. government policy. The U.S. government is involved in many hidden activities, as this collection of links and explanation shows: What should be the Response to Violence?
Bush's education improvements were
All code attacks are nothing but an attempt by people to maintain illusions of superiority: "I must be a better programmer than Linus Torvalds because I can sabotage his work." It is the vandal throwing paint on an existing painting and saying "See I am an artist too". No, if you were a better programmer than Torvalds you would have written a better kernel than he wrote.
People become 'elite crackers' because it is much easier to do destructive things than constructive things; buildings are much easier to tear down than to build in the first place. Because of the asymmetry of the effort involved they get the illusion that they are superior to the people whose code they are cracking.
There is a lot of frustration in youth; the discovery that there are people who have done
much better work than you have ever done - or will ever do - leads to an illusion of inferiority. People attempt to counter that illusion with an illusion of superiority. Not everyone can be as good a coder as Alan Cox - I know I am not even vaguely in his league - but that doesn't make me feel inferior; just different. Nor does being a better coder than most people make me feel superior to them; just different.
Knowing and understanding your limitations and weaknesses is just as important in life as knowing your abilities and strengths. Most people try to hide their limitations and weaknesses from hemselves rather than exploring them, and that is a serious error; you can only do that by lying to yourself. Lying to yourself - when you don't even have a clue that is what you are doing - is a miserable way to go through life.
Hey, they used to be. Look at all those old cathedrals that were built long before anyone knew how to analyze structures.
They just learnt from what stayed up...
caused by the C libraries poor implementation of strings, and by the lack of any runtime bounds checking?
The argument that these things slow down code too much doesn't make much sense, considering that we have to do the runtime bounds checking ourself, everytime, and that we occasionally make mistakes.
I think that it is time we drop all insecure functions from the standard C library and replace the library with a bounds checking version that also was more complete and consistent.
It would also be interesting to have a taint flag on the standard C compiler like the perl compiler has to detect when people are using user input as format strings and the like, without cleaning the input first.
-- Never make a general statement.
This is what well designed OO projects are supposed to be like. The key is then make the infrastructure between the components secure. When that communication/whatever is secure, then each component is the aformentioned "little program" that does "one task". I think one of the biggest problems is the amount of hybrid OO/traditional programs our there.
Consider, however, software engineering. The platform you use, the language you speak, the tools you employ -- they all evolve over short time scales. None have had a century or more of Darwinian pressure applied. No one expects them to work, fully. The liability for failure rests with the company or person using the software, not with the company or person writing it. We haven't had the time to develop the technical or social methods for preventing bad software and reinforcing good software.
How many computer programmer professional societies require rigorou entrance exams and periodic proof of competency?
This will continue until the costs are brought back to the companies that write insecure code. This can happen through government regulation -- the creation of a "software building code" -- or through the dead hand of Adam Smith -- companies start to avoid purchasing insecure software.
The greatest sign that this sort of sea change might be a-coming? The fact that Microsoft feels there is enough market interest to attempt, at the very least, to jump onboard a PR train.
The Mongrel Dogs Who Teach
This article says nothing whatsoever about why coding is naturally insecure. It says that Microsoft is unable to write secure code. Well, duh!
Actually, coding is not inherently insecure. There are a couple of good counter examples (qmail and djbdns, for example).
Microsoft's code is insecure because this way customers can be made more dependent on them. And each time they download a patch, they get a big Microsoft logo in their face. Talk to a PR specialist if you don't see why this is good for them. Besides, there is no incentive to make bug-free code. Nowadays customers are so used to broken code that they actually believe that it can't be any different.
After considering policies like the one below, it is not difficult to imagine that there may be a U.S. government agency that wants Microsoft software to be insecure.
Page obtained as a result of the Freedom of Information Act.
It says, "I am here as a special envoy appointed by the president and reporting to the special Deputies Committee of the NSC."
"Our goal is a world in which key recovery encryption systems are the dominant form of technology in the commercial market."
At the time, there was no public discussion that the U.S. government was doing this.
Bush's education improvements were
Note that "local" is NOT "remote".
It is assumed that you can trust your own staff more than you can trust all the hackers on the entire Internet.
Bush's education improvements were
There are only three causes of insecure code:
1. Developers' ignorance.
2. Developers' stupidity.
3. Selling underdeveloped software.
Contrary to the popular belief, there indeed is no God.
Your argument that you have to do your own bounds checking, every time, is wrong. If you have a good grasp of the C language, you should be able to code perfectly secure programs that only perform bounds-checking on external (e.g. user-input) strings.
C is a lot like X: the people who criticise it are exactly the people who don't understand it. If you want bounds-checking, use bounds-checking. If you want garbage collection, use garbage collection. If you want the specific warnings that you've mentioned, use lint. ALL OF THESE TOOLS ALREADY EXIST AND ARE IN COMMON USE. It's alright if you're ignorant of these tools, but for heaven's sakes don't blame the C language for them.
I am also one of those young, idealistic coders. I work in a team of seven people, with two senior developers, four junior (including me) and a project management type who works with the two team leaders and handles a lot of the paperwork and client contact.
I have always maintained that "quality is free", and for two years on this project, I have been proving it. I now get assigned far more than my fair share of the more challenging/high risk tasks, because they know I'll get it done, and it'll work in the end (or at least if it doesn't -- hey, no-one's perfect :-) -- it'll be easy to fix).
The old-timers, after making the usual comments about "can't do it that way in the real world, son" or "that's just not what happens", are slowly but surely coming around to acknowledging that actually, you can. I recently had a performance review, in which my manager recorded three things I think are really important here. First, I am prepared to look critically at multiple designs and pick the one that works best for the task at hand. Secondly, I do test things thoroughly. Thirdly, I do generate rather more than my fair share of the output from the team. I don't think these facts are independent.
Of course, I'm blessed with immediate management who are smart enough to let me get on with it. Sometimes they raise concerns about what I'm doing, particularly where I prefer a strategy that on the face of it looks like a bigger risk but in reality is likely to pay off much more. After all, it's their job to raise those concerns, and mine to address them. But generally, if I have a good argument in favour of my choice, they leave me be. I'm sure they still mumble things about "can't do it that way" under their breath occasionally, but the results are clear for all to see.
I think I am living proof of the fact that quality is free. Well, actually, it pays refunds... "Best practices" are called that for a reason, and it never ceases to amaze me how few people in business get it, and how much money is wasted as a direct result. Hey, if I can do it, there's no reason other people can't. All it takes is management with a couple of brain cells to rub together.
There is always time to design properly and test. Good design, implementation and testing takes a lot less time than bad design, botched implementation and rushed testing. You just have to have enough faith to do it, and resist the management bull that is short-termism. If you can do that and get the results for long enough, then you'll establish a level of credibility that commands the respect of your superiors, and you've won.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You might want to investigate functional programming languages, such as ML and Haskell, then. They do have a very different approach, one that is much more easily proven to be correct. It also has several other demonstrated advantages, including very much faster development and shorter code to achieve the same results as traditional programming methodologies, in several case studies/competitions. Try looking at the ICFP programming contests for the past few years for some very interesting reading. (A quick Google search will turn up all the homepages straight away.)
The big thing holding them back right now isn't technical merit, it's lack of "critical mass". Most managers and senior development types simply don't do enough homework to know about these things and the potential advantages they can offer. But if you're programming purely for recreational reasons, there's no reason you can't play with the best toys. Free compilers and libraries are available for many of these languages. Happy coding...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I do some beta testing for various sorts of projects. I have a reputation as "the tester who can break anything", for good reason: I often do the unexpected (ie. whatever came into my head at the moment) and thus expose hitherto unknown bugs.
More often than not, the response from the coder is "You aren't supposed to do that!" not "Ooops, I need to fix that."
Yeah, that's real useful if the idea is to produce a stable product that users can't break just by doing random things.
~REZ~ #43301. Who'd fake being me anyway?
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
Thomas Galvin
Developers who are more inclined to write secure code seem to come from a background that involves administering free UNIX systems in the mid-90s. This is when we started seeing an explosion in the number of nodes attached to the internet 24/7, most of them running a freenix. We were first to bear security problem onslaughts that everyone now deals with today. A sneak preview.
We had to deal with release after agonizingly insecure release from Berkeley, Washington University, Carnegie Mellon. Deal with urgent "security patches" that simply add bounds checking to strcpy, and praying to god that we get our bugtraq email before the script kiddies have figured out how to uncripple the exploit code.
Servers being attacked just because one user was running an IRC bot in a channel some teenage punk wanted to take over. ISPs being knocked off the net just for running an IRC server. Spammers, denial of service attacks, buffer overflow exploits, rootkits, social engineering, man-in-the-middle attack, password sniffing, brute force cracks, .
Developers who lived through this find that the rest of the world (ie, the people starting to do serious stuff on the internet today) are blissfully unprepared for the security onslaught. More NT servers are connected now than ever, ASPs are coming to the harsh reality that they have 40,000 lines of insecure trash running their web site, home users completely unaware that their broadband "always-on" connection really means "always-vulnerable".
The only common traits we share are cynicism. Cynicism for all developers, all companies, all users, everyone. Hundreds of security holes being introduced every second. Every gadget you buy, every shopping cart you push, your comb could have a buffer overflow, careful! that milk might be sour!, oh no! quiet or the cake won't rise!!! they're crawling all over my skin--get them off get them off, use the ice pick use the ice pick!!$%*)!@!!
If you as a programmer don't see the world that way, don't expect to write anything but insecure garbage. But don't worry, you'll learn your lesson just as we all did. And don't be mad at us if we laugh, because we're laughing with you.
Incidently, I saw a neat mock-up of a GUI wrapper for this sort of interface - you were able to drag and drop linking symbols from the menu bar to other windows in order to create "links" between the programs. While it was really need within the limited demo I saw, I don't think it ever went anywhere :(
The argument that these things slow down code too much doesn't make much sense, considering that we have to do the runtime bounds checking ourself, everytime, and that we occasionally make mistakes
It's a stupid argument. If you profile all of the programs on freshmeat, 95% of them will be bound by interactive user input, or disk, or network, or memory, not CPU.
Unless you have a specific need or die-hard preference, most programs today should be written in a high level language. If you even have CPU bottlenecks, you can rewrite the hotspots in a lower level language--kind of like how people used to optimize portions of C code by rewriting it in assembly.
I suggest Python. ;)
The iptables connection tracking security flaw was a major flaw.
Code is art until you release it. Then, it's poor engineering.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
If consider that all the cathedrals you see today are the ones that didnt fall down, you will realise that the gap betwen software and cathedrals is smaller than you think.
Also, butressing was a mid-project refactoring on a few of them, as their sibling projects started to fall down as they got above a certain size.
Finally, cathedrals were a projects lasting a few hundred years with fairly stable requirements 'watertight building to worship a deity"; I dream of s/w projects that stable.
-
The bridge is designed, in considerable detail, by a small team of experienced people, long before any construction begins. The team includes experts in diverse disciplines. New approaches are subjected to extremely expensive testing in the form of computer analysis, physical models, etc. There are no "start up" bridge design companies staffed by college dropouts.
-
While hundreds of workers may be involved in the actual construction, very few are doing things that can by themselves render the bridge unsafe. By comparison, almost any programmer on the team can render the entire program insecure by failing to test an input adequately at runtime.
-
Critical bridge components are tested to a degree (and can be tested to that degree) rarely seen in the software world. What's the equivalent of x-raying a large sample of the welded joints?
Just for the sake of argument, I would assert that most shrink-wrap software and the downloadable equivalents are built using standards no better than those of the home craftsman building a bookcase. And like the bookcase, that software works just fine, most of the time, until someone pushes at it the wrong way. However, if we built bridges and skyscrapers the way that craftsmen build bookscases...If people built houses the way programmers wrote programs, the first woodpecker would destroy all the housing, but they would have been created for free by copying the first house, and would be restored from backups almost instantly.
The only solution is to have a wide variety of software, so that any particular fault only affects a small number of users. Yes, you pay for that in interoperability and support costs, but the alternative, an operating system monoculture, will be getting more and more vulnerable and unreliable over time.
Exactly. If I'm not "supposed" to do something the coder didn't happen to think of in advance (and who can think of every use a program will be put to?) make it a "can't happen", don't just tell me "Don't do that". That's not very useful in the real world -- are you going to track down and tell EVERY user "don't do that"?? :)
~REZ~ #43301. Who'd fake being me anyway?
Yep -- "should" doesn't cut it when the software is out in the wide world and random users are doing random things with it. You can't ass|u|me the user has a clue what you INTENDED to happen. He only knows what DOES happen.
:)
I've also found that a lot of coders get barn-blind -- ie. after working on a project for a good long while, they get so they can only see THEIR way of using the software. IMO part of a good tester's job is to keep the coder aware that their notions of how it "should" be used don't ship with the software.
And the coder can't control stuff like -- "I clicked HERE, and it broke." "What did you click THERE for? You're not supposed to do that." "I didn't mean to, but I had bad aim with the mouse." Likewise silly stuff like typoes and "Oops, didn't mean to hit ENTER yet!"
~REZ~ #43301. Who'd fake being me anyway?
The end-user is not an idiot, so let's booby-trap everything to prove how smart we all are. NOT.
There's a big difference between "shouldn't" and "never will". There's a big difference between "should never happen" and "can never happen". Even the things that "can never happen" sometimes happen.
I get the feeling that a lot of code is "pretty good" assuming that everybody else is perfect. When everybody is doing that, seems like you've got a recipe for instant disaster.
A program should work correctly for correct input.
A program should never go beserk on any incorrect input.
Just wait until programming is nothing more than dragging pictures around and connecting them and you never see a line of code.
When the hackers/crackers get ahold of the results..... Or is that what we're seeing with the Microsoft wormage?
I agree that they need a better slogan, but they have done something impressive, which is go through the code looking for security problems, or just iffy code.
The OpenBSD team thinks that security is at the top of importance, and I agree. There needs to be some other name for operating systems that are not secure. Maybe framis. Microsoft Framis XP.
If an OS is not secure, it is just a toy.
Bush's education improvements were
The processing I do involves receiving, processing and transmiting millions of messages containing patient data, billing, and lab reports everyday. In near real time. To and from 50 systems on multiple 100Mb ethernet cards. If I used a scripting language to do all the processing it would take a week to do a days worth of messages. At peak times, even with heavily optimized C we can still run 5 to 10 minutes behind in passing messages between systems.
And the disk is _not_ the bottleneck, it has 20 disks that are mirrored and stripped (hardware RAID 10) using multiple controllers, so it has no problem keeping up with the quad processor IBM. We easily read and write data at about 160MB a second. If anything a lot of the receiving systems are the bottleneck.
All the main routines are in C. They are wired together using ksh, perl and tcl scripts. And before you ask, we pretty much know what tasks can be scripted and what tasks need C from about 50 years of in house experience with a team of 10 programmers at this particular task.
We also already have the libraries we need. Libraries that are tried and true with years of testing and experience on the 20 different systems that we fully support.
Hardly _blindly_ selecting C.
-- Never make a general statement.
I dislike the phrasiology "C is inherently unsafe". I think what you're getting at is a fair criticism, but it is the combination of C's performance-over-safety ethos and programmers'/managers' laziness that is the killer, not the language alone.
C++ can be a much safer language (in typical conditions) than C. If nothing else, the tools for abstraction it provides are far more powerful. Perhaps the most relevant example is tying resource acquisition and release together by using constructors/destructors to do it, so that resource release is often automatic, with no scope for the programmer to forget it.
And this in spite of the fact that good practices produce better code faster, and consequently make more money. <sigh> Perhaps even worse, a lot of managers and senior developers don't do enough homework. As a result, they wouldn't know a truly powerful programming language/idiom if it stared them in the face.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I haven't used python, what is it's speed like compared to C?
Python is an extremely expressive, runtime evaluated language. As such, it's probably about 4x slower than perl in cpu bound operations.
People still develop cpu-intensive applications using Python though, even games. The graphics routines/physics are implemented in C, how it all comes together is where Python shines.
I wonder how much cheaper it would be for MS to fix things before they go out the door vs. the service pack downloads.
I've misplaced SP2 for W2K a few times, downloaded it between 5 and 10 times. That's 500megs to a gig, and that's just me.
More exactly, it appears that (at least on the Gothic cathedrals), they waited for cracks to appear in the masonry, then reinforced as indicated. One bit of "reinforcement" is rather interesting. Good stonework is quite strong in compression, and an arch subject only to gravitational loading is quite definitely in compression. However, when the wind blows and tries to push the building sideways, the flying buttresses on the upwind side could have wound up in tension (being pulled apart), where the strength is zero. So they put gargoyles on top of the buttresses, adding just enough weight to keep them in compression.
The problem, as I see it, isn't that there are too many inexperienced programmers, just too few of the good ones.
Sorry, this is a rant. It bugs me to hear people say this.
There are plenty of good, experienced programmers. They just have a hard time getting hired, because they are older than 25. When you interview them, what they talk about are good, solid development strategies, such as proving programs. This is different from and far less impressive than a spew of hot new buzzwords.
So you have some idiots who don't understand the basics of stacks. OK. Someone hired them instead of a 40-year-old like me who has grokked stacks since his and/or her teens. The reason they made this hiring decision is that's who they wanted to hire.
Even worse, they're going to keep on hiring these idiots, because people have been so beaten into submission to accept bugs that they hardly notice the difference between a well designed and badly designed piece of code.
Exercise: how many OpenBSD security flaws exist (or have existed) where the weakness was exploited before the team fixed it? What has the severity of the flaw been compared to flaws that have been found in other systems>
There are no programs called ftp, httpd or smtp. FTP, SMTP and HTTP are protocols for which there are many implementations; rarely does a protocol have a bug. Implementations of these protocols may have bugs. So it makes sense to talk of Apache or Sendmail having a bug, but not httpd since there's no such thing.If one particular OS distribution -- one of the *BSDs or a Linux distribution -- runs BIND as root, and another runs it as a user with no privileges except to read files in one particular part of the filesystem, then a flaw in BIND is obviously much more severe in the former than in the latter.
With OpenBSD, when you run BIND you're not just running BIND version 4, you're running a version of BIND 4 that has been audited by the OpenBSD team for flaws. (This is why OpenBSD is still using BIND4 and will continue to do so for a while: the code has been audited, and it works perfectly well providing DNS. Why "upgrade" when the old version isn't missing anything you need?)
All the code that is part of a standard OpenBSD install has been audited. If Apache is found to have a bug, it is not necessarily true that Apache on OpenBSD has a bug. And unfortunately bug fixes that the OpenBSD team makes in standard daemons don't always get accepted into the mainstream code for it.
Unlimited growth == Cancer.
I sympathise to an extent, because although I am (just) under 25, I still see people who are good getting passed over in favour of people with high buzzword counts. I've also seen the results several times, and it's never pretty.
On the other hand, I really don't think that, as a proportion, there are that many good programmers out there, of any age. I just don't see any evidence for it. Notice that most of the dumb decisions being made (including recruiting buzzword specialists) are made by older people, either senior developers or those who've moved into project management. Furthermore, most of them are a direct result of that older person feeling qualified to make a decision when in fact they are not, through ignorance, prejudice or whatever.
To give a concrete example, most of the reason we have such bad C++ programming in the world is that older programmers who have used C for decades think that they are somehow qualified to comment on (or program in) C++. As a result, we have a fabulously powerful language being used to write incredibly bad code all over the place. Most of the criticism directed at C++, particularly on boards like this, is unfounded, but the perceived weaknesses are there because people haven't done their homework. This is just my own pet peeve, which I see every day, but is a definite argument against your claim that there are plenty of good older programmers out there. I'd rather have a 25-year-old whose C++/OO knowledge was current than a 45-year-old whose knowledge was based on a decade of programming C until five years ago, but who thought it was still current and thought he could do OO as well, because it's just "a variation on the theme". It's amazing how many "old and wise C++ experts" don't know what a template is, and I'm sure entirely coincidental that C doesn't have the concept and it wasn't in "Learn OO in Five Seconds".
It's certainly true that there are good older programmers, and that they are better than good younger programmers, simply because they have wider experience to draw upon. But IME, they really are pretty few and far between. At the same time, you have to remember that the field levels out a lot once you've been in the business for more than, say, five years, however old you are. Knowledge dates fast in this industry, and the relevance of older experience drops away until it's really only the domain-specific experience and general business acumen that are still useful, IMHO.
I've never liked age discrimination, at either end of the spectrum. I believe in rewarding genuine merit alone, and in my experience, those who do so make a better job of things. But to claim that plenty of the older programmers are being passed over in favour of younger types purely because of discrimination/buzzwordism is Just Plain Wrong. A lot of those older programmers still think they're good, but their knowledge is so far out of date that it's simply not as valuable as the enthusiasm and recent knowledge of the younger competition.
It's a hard thing to learn what you're truly worth, and that "N years of experience" and "respect your elders" don't always cut it. On the other hand, looking purely on objective merit, I see relatively few programmers who can get the job done properly in the first place, and most of them are pretty young. That's always going to make it look as if older programmers are being discriminated against, but actually, there's a much simpler explanation a lot of the time.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Ada was developed for military use as a coding standard. Its syntax is so strict that the code works often. But...uh...it doesn't matter. You can still screw up.
Similarly, people speak English badly every day.
Mod me down and I will become more powerful than you can possibly imagine!