|
||
|
|
||
| Wed, 27 Aug 2003 |
|
||
|
ZDNet is carrying a story which brings up an old topic -- should venders be legally responsible for their products. Many of us in the IT field spend hundreds of hours every year performing maintenance on systems due to problems that exist in software we purchased. That could easily increase to thousands of hours if one of those problems is somehow exploited by a worm, and we have to clean it up. Instead of putting the burden on us, the purchasers of a product, should we put the burden on the vender to get it right the first time, or be legally responsible? The story uses the example of a civil engineer. A mistake by a civil engineer is often career ending. Maybe if more time and thought went into programs, along with the added legal pressure, software would be higher quality. The counter argument, of course, is that programming is a complex task. There are an incredible amount of variables (no pun intended) to deal with when creating lines of code. Not the least of which is the fact that what we design software for today may not be what people choose to use it for tomorrow. Often existing software solutions have to be warped to handle new variations of a problem. Two things that come to mind here are Sendmail and BIND, each of which seems to carry an unfortunate track regord of lax security. Neither of these packages, though, were initially built to handle the security issues that exist on the Internet today. Additionally, the Internet is expanding at an incredible rate, and people are demanding more and more from the software they use. But there are a finite amount of people in the world able to work on this software, security and features always seem to be lagging behind. Or are they? There are other projects, such Postfix and and Djbdns, which have particularly good security track records. So what's the difference? Postfix and Djbdns are newer, and have been designed from the ground up with today's Internet in mind. This doesn't mean they lack features either, Postfix is incredibly feature rich, and has been shown to peform much better than alternatives. Djbdns's point isn't features, and was meant to be simple. But there are other DNS alternatives available that are security concious and contain the features people want. Perhaps this means that the answer to software problems is a redesign cycle. Maybe the Internet moves faster than we can keep up with, and that all software needs to have it's core, the foundation it's built on, re-examined on a set cycle. The problem with this is that little details, the kinds that cause security concerns in the first place, can easily be overlooked in this fashion. It's the same thing that happens when we write papers or books, and the reason an author needs someone other than himself to proofread his work. This has the potential for angering Joel On Software enthusiasts, but perhaps software needs to be rebuilt regularly from the ground up to be able to handle the evolving needs of people. Who's to say that in 7 years, Postfix won't have similar security problems that Sendmail has now? Maybe new technologies will exist then, unlike anything the Postfix authors possibly could have dreampt up. Adding to Posfix the ability to handle these new technolies may cause the developers the need to "hack" these features in, as Postfix wasn't designed for that sort of work. With enough hacks, things start to get overlooked. What if every five years, software were rebuilt? One of the big problems here is that it's an incredible endeavor. Software which has been around for awhile might take an enourmous amount of time to rebuild, as seen with Mozilla. Then again, let's compare Mozilla to Internet Explorer. Which would you rather use? Internet Explorer, even the newer versions of it, seem to have a variety of flaws which allow websites to have complete control of your computer. I don't think there are many, if any at all, flaws like this in Mozilla. So, in this browser instance, we've solved numerous security issues and built a better core, while sacrificing a period of time where there were no updates at all to the software. Perhaps a small amount of developers could continue to maintain the original product, while the remainder of the team builds the new one. It's my feeling that, even with Mozilla's being built from scratch, that it by far outdoes Internet Explorer today, in everything. Features, security, flexibility, and extendability are all superior. Was it worth it? Many complained about the delay in Mozilla's 1.0 release, that it took so long before a usable release was available. This reminds me of the many delayed gratification studies: "When considering how to productively harness your feelings, practice some emotional self-control and delay gratification, Kilgore advises. Stanford University researchers tested children's impulse control by placing a marshmallow in front of them and telling them that they would receive a second one if the first remained when the adult leading the group, who needed to leave the room, returned." "The longitudinal study found that, overall, the children who delayed gratification and did not eat the marshmallow were more successful later in life, as measured by a range of factors including happiness, income and job satisfaction, than those children who ate the marshmallow." www.umich.edu/~urecord/9900/May22_00/15.htmAre we so much into the now that we can't wait for something better later? It could very well mean the difference between secure, flexible software and insecure software with hacked-in features that causes many hours and dollars in maintenance simply to prevent worms and virii from breaching the system. "The significant problems we face cannot be solved at the same level of thinking we were at when we created them."
- Albert Einstein (1879-1955) |
||
| /Blog/Computers/News | Permanent Link | Comments (2) | ||
|
|
||
|
||
|
This is, well, one of those things you just have to see to appreciate :-) As Darren said, I'm not sure if this is satire or not. Hmmm. |
||
| /Blog/Humor | Permanent Link | Comments (0) | ||
|
|
||
|
Also, be sure to check out the OpenThought Web Application Environment |
|
Copyright 2003 Eric Andreychek |