Open Source == Faster bug fixes

solar writes "SecurityPortal.com is running a comparsion between RedHat, Microsoft, and Sun Microsystems on the response time between software bugs being found and patch releases. Find out if open-source is the champion bug squasher we all believe it to be. " Interesting bit.

Comments

Slashdot Readers: The UNIX Philosophy

[Anonymous Coward]

I think I'd like to point Slashdot readers to a wonderful book: The UNIX Philosophy by Mike Gancarz. This book explains the tenets and values that traditional UNIX programmers have held. It goes on to list the 9 most primary tenets:

1. Small Is Beautiful
   • Software Engineering Made Easy
   • Small programs are easy to understand
   • Small programs are easy to maintain
   • Small programs consume fewer system resources
   • Small programs are easier to combine with other tools
2. Make Each Program Do One Thing Well
   • By focusing on a single task, a program can eliminate much extraneous code that often results in excess overhead, unnecessary complexity, and lack of flexibility.
3. Build a Prototype As Soon As Possible
   • The fact is, everyone is on a learning curve
   • Even the masters know that changes are inevitable
   • Why do you think they call it "software"?
   • Prototyping is a learning process
   • Early prototyping reduces risk
4. Choose Portability over Efficiency
   • Next ----'s hardware will run faster (fill in "quarter", "year", whatever)
   • Don't spend too much time making a program run faster
   • The most efficient way is rarely portable
   • Portable software also reduces the need for user training
   • Good programs never die--they are ported to new hardware platforms
5. Store Numerical Data in Flat ASCII Files
   • ASCII text is a common interchange format
   • ASCII text is easily read and edited
   • ASCII data files simplify the use of UNIX text tools
   • Increased portability overcomes lack of speed
   • The lack of speed is overcome by next year's machine
6. Use Software Leverage to Your Advantage
   • Good programmers write code; great programmers "borrow" good code
   • Avoid the not-invented-here syndrome (i.e. don't reinvent the wheel just because you didn't invent it first!)
   • Allow other people to use your code to leverage their own work
   • Automate everything
7. Use Shell Scripts to Increase Leverage and Portability
   • Shell scripts give you awesome leverage
   • Shell scripts leverage your time, too
   • Shell scripts are more portable than C
   • Resist the desire to rewrite shell scripts in C
8. Avoid Captive User Interfaces
   • CUIs assume that the user is human
   • CUI command parsers are often big and ugly to write
   • CUIs tend to adopt a "big is beautiful" approach
   • Programs having CUIs are hard to combine with other programs
   • CUIs do not scale well
   • Most important, CUIs do not take advantage of software leverage
9. Make Every Program a Filter
   • Every program written since the dawn of computing is a filter (it takes input data, and processes it somehow to possibly produce output)
   • Programs do not create data--people do
   • Computers convert data from one form to another

As you probably guessed, Open Source _pushes_ Tenet 6 to the forefront. Let others use your code!

Along with those primary, religiously-followed tenets, 10 lesser tenets are typically followed:

1. Allow the user to tailor the environment (Yeah! This is seen plenty in Unix user interfaces)
2. Make operating system kernels small and lightweight (OK, so Linux doesn't go to any extreme with this one...)
3. Use lower case and keep it short (well-known and practiced throughout; lowercase is easier to read)
4. Save trees (Why print out programs when you have less, gless, lynx, etc?)
5. Silence is golden (make program output good enough for humans to understand, but terse enough for other programs to use!)
6. Think parallel ("There is an old joke in the computer world that goes something like: if one woman can have a baby in nine months, does that mean that nine women can have a baby in one month?")
7. The sum of the parts is greater than the whole (use small tools to build big projects!)
8. Look for the 90 percent solution (don't exhaust yourself making it work in every nitpick situation)
9. Worse is better (think VHS vs. Beta; VHS sucks but it won!)
10. Think hierarchically

The book also mentions something very important: The Three Systems of Man. Software goes through the First system, the "innovative" cycle where one or only a few develop something revolutionary, to the Second system, where committees are formed for the software so more people can feel they're worth something contributing to the idea, and the Third system, where experts who left the scene during the 2nd stage come back to implement the idea, now that the obvious solution for it is well-known and has been walked many times.

CREDITS: This posting contains lots of quotations from, of course, the book: The UNIX Philosophy by Mike Gancarz, Copyright 1995 Butterworth-Heinemann. ISBN 1-55558-123-4 ... about $19.95. Well worth the money.

You people are ruthless! We're working on it!

[Kurt Gray]

Disclaimer: I work at Andover.Net.

People calm down. We have our best perl coders here slaving over the Slash release. Patrick, Rob, and Pater are trying to convert their undocumented code and database schema into something that can be installed on other machines besides this one. The Slash code really is hardcoded in many ways and they are trying to unhardcode it for you now now. But they very much appreciate your flames so please keep 'em coming. =)

Re:Open Source doesn't always == faster bug fixes

[finkployd]

there seems to be a rather vocal fundamentalist open source community here on /.

Yeah, I've noticed that too. It's funny, you get the same kind of thing on Freshmeat.net, with all these open source programs for download. Strange stuff.

These people generally cite certain prime examples to support their arguments.

And we all know THAT is a really dumb way to support arguements. Better to just yell and scream.

Although Linux is a stable and it's security holes are filled quickly,

This seems to be in direct contention with your subject.

I don't think that there are any hugely successful pieces of open source software

This one is way too easy. I'm starting to think this whole post is sarcastic and you actually support linux. Either way, find a more popular web server than Apache (suprise, open source). Seems PERL is pretty open, as is sendmail. I'm not sure what you mean by a monopoly when refering to the latter.

I don't work for free, I have to pay bills. Infact, I'm quite happy to be paid a lot of money for what I do.

Hey, we are all happy for you, now when are you going to get to the part about "Open Source doesn't always == faster bug fixes", or was this just a clever way to repeat the tired "open source cannot make money" monologue?

Finkployd


Bill Gates: "Innovation"

Speed != Quality

[Rombuu]

Sure, open source can get bug fixes out there faster... but its not like for most open source projects anyone is going out and regression testing the fixes against anything to make sure nothing else is broken by the fix, etc...

As far as speed goes, big deal... give me a fix that works.

Re:Open Source!=Redhat

[bero-rh]

Redhat is kinda slow at getting out the official fix. For example, the linux kernel is at 2.2.14 but Redhat has not put out a official rmp yet even though 2.2.14 contains a bunch of fixes

Red Hat has actually released several 2.2.14 RPMs in Raw Hide, our more experimental version. If you want to be on the bleeding edge, use that.

Also, check the source RPM for Red Hat's 2.2.13 kernel - it already contains a number of the fixes that later made it into the official 2.2.14 kernel.

We don't put out errata RPMs for every minor bug (misspelled man pages and such); this stuff gets fixed in Raw Hide and then makes it into the next release.

Errata RPMs are released only when they fix a MAJOR bug, such as a security problem (such as the bind update currently available) or a real functionality problem (such as the lynx update).
Releasing them for every minor problem, or every base version update, would be a bad idea because it would be very hard to keep track of everything. (And of course it would lead to "You need to update 1500 packages before Red Hat Linux works well" FUD from Microsoft and other people who don't care to check what an update does before writing flames).

Re:RedHat's response time

[bero-rh]

The fact that we're reading your message shows we're paying attention to the community. ;)
The thing that slows Red Hat errata down is called Quality Assurance. Bugfixed packages don't leave Red Hat without having run at least a couple of tests to verify

• the new package actually fixes the problem
  
• the package still does what it is supposed to do
  
• it doesn't introduce any new similar problems
  

I'd rather delay a package for a day than having to release yet another security update for the same package the next day...

Bumblebees flying AND:Poor research

[dpilot]

The assumption was that bee wings act like airplane wings. Uner those assumptions, a bee would not be able to fly. Somewhat more recently it was shown that bee wings do not work the same as airplane (or ornithoper) wings. Aside from the flapping thing, there's a basic modal difference.

Airplane and ornithopter (and bird?) wings work on laminar airflow. Try 'too hard' to fly, and you get turbulence above the wing. In other words, a stall.

The bee has a different method of dealing with this. Rather than prevent turbulence, the bee wing uses turbulence, and has a machanism for continually spinning the turbulent vortices off of the wing. In this flight mode, a given size wing has much as 50X more effective lift than in laminar mode.

I'm not sure we can apply this to the whole Linux vs Microsoft thing, other than to say that a new modality changes the whole landscape. But I guess that's what Open Source is all about. In this case, we're the bee.