ged at jubileegroup
Nov 7, 2009, 3:53 AM
Post #8 of 9
(274 views)
Permalink
|
|
Re: [Fwd: [sanesecurity] x86_64 users: possible malformed database problems]
[In reply to]
|
|
Hi there,
On Fri, 6 Nov 2009 Nathan Gibbs wrote:
> Cut these guys some slack.
> They can't do everything.
This isn't about cutting slack, or for that matter pointing fingers.
It's about contributing. I'm contributing. Sometimes people don't
want to hear what needs to be said. That can be painful all round,
believe me.
> Thats the beauty of Open Source.
Let's just say I'm familiar with the concept and leave it at that.
We don't want you to get your foot completely stuck. :)
> ... report that its broken. If possible Where is it broken, why is
> it borken, and how it might be fixed.
That's exactly what I'm doing here. Unfortunately my message is not
one which people often want to hear. They want to hear what a great
job they do, not how they could improve on how they're doing things by
doing things for which they really have little sympathy. There isn't
some piece of code somewhere that has to be tweaked. If it were so it
would be great, they'd just go off and tweak it and all would be well.
But it isn't like that. The issue here is that if there is any system
which is supposed to prevent problems of the sort that we see so often
in releases of ClamAV, then demonstrably it isn't working.
My contention is that there is no system, and that's what needs to be
fixed. But as I don't employ the developers, all I can do is point to
some of the benefits of using modern (i.e. developed in the past fifty
years or so) quality systems. We no longer have to promise that the
architect will be executed if his building falls down. But there are
still people in governments talking about penalty clauses in software
procurement contracts because they don't know any better. Sorry, any
better way to get the systems delivered on time, under budget and with
acceptable levels of faults and performance.
Quality systems can and do result in improvements of a couple of
orders of magnitude in fault density in software (measured for example
in coding errors per 1000 lines of code). The user's experience will
inevitably improve as a result - and let's not forget that one coding
error can easily cost several hours of the time of each of thousands
of the code's users - but in addition, the developers will be able to
get on with their developing instead of spending large chunks of time
tracking down the faults which they themselves put there because they
didn't have some kind of system.
Obviously I don't claim that all errors can be eliminated, but I have
seen the results of using and failing to use quality systems and the
differences can be stunning. It's no exaggeration to say that the
cost savings in industry are phenomenal. I've seen manufacturing cost
reduced by more than 60% and reliability improved by 500% as a result
of proper quality control procedures being applied. I've also had to
fly to thirty of the United States to replace four 10 cent components
in a couple of hundred examples of a fifty-thousand dollar product
because the quality control procedures were ignored. The cost to one
company of ignoring a few simple quality procedures which would have
found the problem at the sub-assembly manufacturing stage was tens of
thousands of dollars in repair bills and very much more than that in
loss of customer goodwill. The cost of finding and fixing the problem
if the procedures had been followed would have been a few dollars.
This is a natural result of the logarithmic relationship between the
cost per fix and the stage in the product's life at which the fix is
applied. It doesn't really matter what the product is, and despite
what you're thinking right now it is _very_ relevant to software, if
the software is built in anything like a modular fashion as probably
it should be.
Here's an example of an implementation of some of the ideas:
http://www.praxis-his.com/news/sparkGPL.asp
But you don't have to implement the whole thing as an automated
toolset, a lot of it can be paper-based or some other manual method
such as just writing in a comment at the top of every function what
the expected inputs and outputs are, then making sure (by inspection
or by test procedures in the code itself, and preferably both) that
those are indeed the things that happen in practice.
As I said in my first post, quality systems are fundamentally about
documentation. We all know what a popular subject that is. :( One
aspect of the documentation in this case would be writing down how to
prevent these things from happening. That's the first problem. If
you can't do that then you're in real trouble, it probably means that
you don't know _why_ the things are happening. But at least now you
know what the real problem is. It has little to do with the code.
It will take time and a little effort, but once it's done, then all
you have to do is what you wrote down you would do. That just takes
discipline. Admittedly this is another relatively unpopular concept
in the programming community. :)
There are very many places to start looking at quality systems, but
as we are in the very early stages I suggest that background reading
about the issues would be more appropriate than diving into projects
developed using modified ADA.
Here's one document which covers many of the issues:
http://satc.gsfc.nasa.gov/assure/agbsec3.txt
It's written in fairly general terms, and at first sight it can be a
bit daunting. But what appears at first to be onerous, confusing and
even irrelevant can in fact be a great saver of labour, and when you
begin to understand where it's 'coming from', as they say in the USA,
it will all start to make sense.
There are many more sources of information about software quality
assurance on the Web, but the first step must be to recognize that
there is a problem to be solved. When that is done, the developers
are in a position to apply the techniques needed to solve it.
<footnote>
Here in England we used to see "Made in Japan" on the base of lots of
cheap, tacky, plastic products. The phrase became almost synonymous
with mass-produced, poor quality products. About the time that I was
born, the Japanese government passed a law which forced all Japanese
manufacturers to work to the new 'quality systems'. The rest, as they
say, is history. For most of my childhood I was immersed in a culture
which held that "Made in Britain" meant "Good", while "Made in Japan"
meant "Rubbish". In my teens, I began to wonder why my British made
motor-cycle leaked more oil and broke down more often than my friend's
Yamaha. Later, I wondered why the Japanese seemed to be able to bring
new products to market so much faster than the British, and sell them
cheaper, and in such large volumes. None of the British motor-cycle
manufacturers could compete with the Japanese onslaught and every one
of them went bankrupt. The few motor-car manufacturers here which did
survive, if they can be said to have survived, have only done so by
getting huge handouts from the tax payer. Our consumer electronics
industry all but disappeared and the term "Made in Japan" is no longer
something which provokes derision. All this was the direct result of
the implementation of quality systems - elsewhere. It's the stuff of
industrial revolutions, like when they moved from horses to steam, or
from armies of clerks with their quill pens, to computers. And it's
really rather easy to do, and cheaper, and quicker, than not doing it.
</footnote>
--
73,
Ged.
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
|
signature.asc
