High Plains Thumper wrote:
> Rex Ballard wrote:
>
> > The reality of software development is that mistakes will be made.
> > Whether it's a 1 microsecond window for a race condition between
> > multiple threads in a server, or a pointer corruption error in a video
> > driver.
> >
> > Linux has bugs.
> > Windows has bugs.
> > OSS has bugs.
> > Microsoft has bugs.
>
> Most bugs are nothing more than overlooked coding errors and omissions.
I'll add to the list - code that needs to deal with situations the
programmer didn't anticipate. This could be indirectly implied by your
statement but I'll go ahead and spell it out anyway.
> Minicomputer software has bugs.
As do the microprocessors themselves. At one time Intel had a
"bug-list" on their website with the bugs in the various
models/steppings of their processors. It's not surprising given that
modern day processors are 'programmed' and ultimately the software
that's written is translated to the masks which are used to manufacture
the chips.
> In the late '80s, I discovered a missing
> line of code that updated the pointer to the link list for data output
> queues on our structural test software at McDonnell Douglas. Test would
> run for several weeks, then a acquisition software task would mysteriously
> crash. After a restart, it would continue solid for several weeks until
> next crash (sound familiar with NT4?).
>
> After the patch, software was more robust.
>
> It is why my supervisor then would not purchase the latest OS software
> release for OS/32. He waited until the major rounds of software patching
> had occurred, usually about a year later.
Many large IT organizations feel the same way. They don't just upgrade
on a whim. They have large complicated systems that simply 'must work.'
Unless a patch addresses a very specific problem for them most shops
simply won't install it.
About 2-3 years ago I went down to Connecticut to visit a customer
(huge Insurance Co.) and they still had software running on NT4
servers. We were seeing some strange issues with this Java component
and the JVM they had was ancient. It was actually a custom "1-of" JVM
that Sun wrote for them. They wanted some specific bugs fixed but they
didn't want to upgrade their JVM to a newer version. Sun fixed the bugs
they asked for and released a special JVM just for them.
Bottom line is that in many places if something already works, they
won't risk "fixing it" by installing patches/updates for no reason.
Security wise... these systems are already locked down behind monitored
firewalls so it's not an issue.
> > Microsoft however, can generate substantial amounts of revenue by not
> > fixing known bugs until the next release. After all, if you liked it
> > too much, you might not buy the upgrade.
>
> Given the track record, IMHO, this statement seems on target. It minimises
> overhead expenses. Bug fixed in next release is a bad computer security
> model but driving forces seem to be stock prices.
>
> > Linux/OSS on the other hand has to deliver the bug fixes as quickly as
> > possible, because if they don't their competitors will, and they will
> > lose customers to the competition.
> >
> > Competition is such a wonderful thing.
>
> You assume too much. Implying such would indicate that with a lack of
> competition, OSS/Linux would be no better than the alternatives. IMHO,
> there is better quality control in the process. Software is released when
> there is reasonable assurance that it is solid enough for the user
> community to implement. There is no pressure from stock holders to release
> prematurely.
>
> Debian has a strong security model, by retaining the older more stable
> version. For most, a slightly older version is not a detriment as it has
> most patches applied.
>
> Following this security model is a good strategy in any IT department. They
> don't need a mail server, data base management server, web server or
> process control server go bonkers on them at a critical moment.
>
> --
> HPT
|
|
