Bugs are bad, they are not job security (Was: spam)

[Brian Densmore]

My point exactly. You have bugs in the OS, then you add the bugs in the
driver and then bugs in the application on top of it all. Linux has many
bugs, much of this can be attributed to having to reverse engineer someone
else's proprietary code (but not all). Yes, as systems get larger and more
complex you see more errors, because no one bothered to fix the bugs when
the code was a manageable size. I could write perfect code right now for an
MP3 player that wouldn't work on half of all systems because other coders
wrote crappy drivers, and OS'es.

Best Regards,
Brian

Brian Densmore <mailto:DensmoreB at ctbsonline.com>  

 
Associate 
Computech Business Solutions <http://www.ctbsonline.com>  
voice: (816) 880-0988
fax: (816) 880-0998
:-{)> 

> -----Original Message-----
> From: Bradley Miller [mailto:bradmiller at dslonramp.com]
> Sent: Thursday, February 22, 2001 2:34 PM
> To: kclug at kclug.org
> Subject: RE: Bugs are bad, they are not job security (Was: spam)
> 
> 
> At 01:06 PM 2/22/01 -0600, Brian Densmore wrote:
> > Bugs are not inevitable in
> >code, any more than it is inevitable that Ford will make a 
> car without
> >brakes! That 80% would have better projects to work on and 
> companies would
> >be more profitable and technology would advance faster. In 
> other words it
> >would cause a technological boom, that would spur the need 
> for even more
> >consultants. Reliability has a lot to do with corporate hesitation to
> >implement. The mentality would not be "Wait until the third 
> bug fix."; it
> >would be "We need that to beat our competitor!".
> 
> Ah yes, but as time goes on what is acceptable and what 
> isn't?   People are
> griping because you can make a car shift into another gear 
> without having
> your foot on the brake.  Cars have been that way for ?? years 
> and now we
> have to have interlocks to keep stupid people from leaving 
> their kids in
> cars to accidently run over them?  (Here's Darwinism at it's 
> best, but a
> little after the fact if the kid is running over the parent.  
> *Sigh* )   
> 
> That's why I point to the problems with supporting things -- 
> how do you
> know if it's a Microsoft issue or what?   I had generic 
> NE2000 cards in a
> PC and would get random errors, and other problems under 
> Win98.  I switched
> to a different manufacturer and my problems went away.   Was 
> it Microsoft?
> Was it the drivers?  Or was it the 3rd rate generic card?   
> Who knows?   I
> put the same cards in Linux and couldn't get a peep out them. 
>  (Likewise
> I've bought name brand ones and had similar issues . . . )   
> 
> Sometime, at some point, I believe that there might be issues 
> with Linux
> and open source products, trying to run on as broad of applications as
> Windows does.   Will it be because of bugs -- and how do you 
> track them
> down across ??? libraries?   I don't think bugs should be used for job
> security, but I also believe that the more complex the 
> system, the more
> variables and unknowns you introduce to the equation and 
> thus, the bugs
> will be there.  Macs have bugs, but you can just attribute it 
> down to a
> wacky software package or other weird happening . . .you don't have to
> worry that "Billy Bob's Used Computer Crap Emporium" had a 
> sale on $2 NIC
> cards that may or may not run inside an errector set from 
> h*ll computer. 
> 
> -- Bradley Miller
> 
> 
> 
> 
> majordomo at kclug.org
>