From: "Rich" 

This is a multi-part message in MIME format.

------=_NextPart_000_00C9_01C46DC9.899BCE00
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   There is little point in this argument with Adam.  He should know the =
obvious points you are marking already.  I'm sure his own software is =
buggy.  This thread started because Adam was trying some more of his = spin
by using a stupid remark from the openbsd folks that they only need = one
hour to debug, diagnose, fix, test, document, and release changes = they
expect their users to be confident about.

Rich

  "Ellen K"  wrote in message =
news:0098e9.f3958a{at}harborwebs.com...
  I don't know why I'm bothering to answer, but the reason bugs will =
surface in
  real use is that no matter how brilliant the testers are, they will =
not think
  of everything.

  > From: Adam Flinton 
  > Ellen K. wrote:
  >> Don't be ridiculous.   Of course you test, you test everything you =
can
  >> think of and then some.   And then there will still be bugs in the
  >> initial release.
  >>=20
  > & following your assertion, in the subsequent release & the one =
after
  > that etc.etc.etc.etc.
  > Why do you think that simple useage will bring all bugs to the =
surface?
  >> A developer who claims his or her apps never have bugs reminds me =
of the
  >> saying of my late father (a lawyer) that the lawyer who's never =
lost a
  >> case has probably never tried one.
  >>=20
  > Yup & there will thus be bugs in the system period. Not just in the
  > "initial release". I wonder how long some of these IE bugs have been
  > around but just undiscovered?
  > Adam
  >> On Sun, 18 Jul 2004 11:13:55 +0100, Adam Flinton
  >>  wrote in message
:
  >>=20
  >>=20
  >>> Ellen K. wrote:
  >>>=20
  >>>> Oh please.
  >>>>=20
  >>>> No matter how much you test, there will still be bugs in the =
initial
  >>>> release.
  >>>>=20
  >>>=20
  >>> In which case there will always be bugs in every release so why =
bother
  >>> to test?
  >>>=20
  >>> Adam
  >>>=20
  >>>=20
  >>>> On Thu, 15 Jul 2004 18:11:36 +0100, Adam Flinton
  >>>>  wrote in message =
:
  >>>>=20
  >>>>=20
  >>>>=20
  >>>>> Rich wrote:
  >>>>>=20
  >>>>>=20
  >>>>>=20
  >>>>>> It may not be economical if testing is simply
not something =
that
  >>>>>> these folks care about.  The actual change is a
tiny part of =
releasing
  >>>>>> an update.
  >>>>>>=20
  >>>>>=20
  >>>>> Indeed. MS have to be masters of major updates as
they have to =
do it all
  >>>>> the time.
  >>>>>=20
  >>>>> However wrt testing the best time & place to do
that is before =
it
  >>>>> becomes part of the product & not after it's
been released which =
is what
  >>>>> the openbsd people tend towards vs the marketing
driven cycle in
  >>>>> evidence wrt MSOS'es.
  >>>>>=20
  >>>>> Adam
  >>>>>=20
  >>>>>=20
  >>>>>=20
  >>>>>=20
  >>>>>=20
  >>>>>=20
  >>>>>> Rich
  >>>>>>=20
  >>>>>>=20
  >>>>>> "John Beamish"  wrote in message
  >>>>>> news:40f69bc7{at}w3.nls.net...
  >>>>>> (I'm not running Linux.)
  >>>>>>=20
  >>>>>> I find that statement "economical with the
truth".  Assume that =
you
  > know
  >>>>>> which module to go to.  Check it out, make the
change, check it =
in,
  >>>>>> recompile it, do regression testing (assume the
change works =
and
  > doesn't
  >>>>>> break anything), update module documentation,
update changelog, =
update
  >>>>>> bugtracking.   In any serious environment,
that's a day's work =
-- not
  > an
  >>>>>> hour.
  >>>>>>=20
  >>>>>> What happens next?  Are Linux users expected to d/l the =
recompiled
  >>>>>> module or
  >>>>>> is there a process to compare the previous
version with the new
  >>>>>> version and
  >>>>>> generate some kind of hex patch which gets
downloaded and =
applied?
  >>>>>> Or what?
  >>>>>>=20
  >>>>>> Thanks.
  >>>>>>=20
  >>>>>> "Adam Flinton" >>>>> >
wrote in message
  >>>>>>=20
  >>>>>> > Security information moves very fast in
cracker circles. On =
the
  > other
  >>>>>> > hand, our experience is that coding and
releasing of proper =
security
  >>>>>> > fixes typically requires about an hour of
work -- very fast =
fix
  >>>>>> > turnaround is possible. Thus we think that
full disclosure =
helps the
  >>>>>> > people who really care about security."
  >>>>>> >
  >>>>>> >
  >>>>>> > etc.
  >>>>>> >
  >>>>>> > Adam
  >>>>>>=20
  >>>>=20
  >>>>=20
  >>
------=_NextPart_000_00C9_01C46DC9.899BCE00
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








   There is
little point in =
this argument=20
with Adam.  He should know the obvious points you
are marking=20 already.  I'm sure his own software is
buggy.  This thread = started=20
because Adam was trying some more of his spin by using a stupid remark = from the=20
openbsd folks that they only need one hour to debug, diagnose, fix, = test,=20
document, and release changes they expect their users to be confident=20
about.
 
Rich
 

  "Ellen K" <Ellen.K{at}harborwebs.com>">mailto:Ellen.K{at}harborwebs.com">Ellen.K{at}harborwebs.com>
=
wrote in=20
  message news:0098e9.f3958a{at}harborwebs.=
com...I=20
  don't know why I'm bothering to answer, but the reason bugs will =
surface=20
  inreal use is that no matter how brilliant the testers are, they =
will not=20
  thinkof everything.> From: Adam
Flinton <adam_NO_{at}_SPAM_softfab.com=">mailto:adam_NO_{at}_SPAM_softfab.com">adam_NO_{at}_SPAM_softfab.com=
>>=20
  Ellen K. wrote:>> Don't be
ridiculous.   Of course =
you=20
  test, you test everything you can>> think of and then=20
  some.   And then there will still be bugs in
the>> =
initial=20
  release.>> > & following
your assertion, in the=20
  subsequent release & the one after> that =
etc.etc.etc.etc.>=20
  Why do you think that simple useage will bring all bugs to the=20
  surface?>> A developer who claims his or her apps
never have =
bugs=20
  reminds me of the>> saying of my late father (a
lawyer) that =
the=20
  lawyer who's never lost a>> case has probably
never tried=20
  one.>> > Yup & there
will thus be bugs in the =
system=20
  period. Not just in the> "initial release". I
wonder how long =
some of=20
  these IE bugs have been> around but just
undiscovered?>=20
  Adam>> On Sun, 18 Jul 2004 11:13:55 +0100, Adam =
Flinton>>=20
  <adam{at}NOSPAM_softfab.com>=20">mailto:adam{at}NOSPAM_softfab.com">adam{at}NOSPAM_softfab.com>=20
  wrote in message <40fa4c09{at}w3.nls.net>:>&=">mailto:40fa4c09{at}w3.nls.net">40fa4c09{at}w3.nls.net>:>&=
gt;=20
  >> >>> Ellen K.
wrote:>>>=20
  >>>> Oh
please.>>>> =
>>>> No=20
  matter how much you test, there will still be bugs in the=20
  initial>>>>
release.>>>> =
>>>=20
  >>> In which case there will always be
bugs in every =
release so=20
  why bother>>> to
test?>>>
>>>=20
  Adam>>> >>>
>>>> On Thu, 15 =
Jul 2004=20
  18:11:36 +0100, Adam Flinton>>>>
<adam_NO_{at}_SPAM_softfab.com=">mailto:adam_NO_{at}_SPAM_softfab.com">adam_NO_{at}_SPAM_softfab.com=
>=20
  wrote in message <40f6b951{at}w3.nls.net>:>&=">mailto:40f6b951{at}w3.nls.net">40f6b951{at}w3.nls.net>:>&=
gt;>>=20
  >>>>
>>>>
>>>>> =
Rich=20
  wrote:>>>>>
>>>>>=20
  >>>>>
>>>>>> It may not be =
economical=20
  if testing is simply not something
that>>>>>> =
these=20
  folks care about.  The actual change is a tiny part of=20
  releasing>>>>>> an =
update.>>>>>>=20
  >>>>>
>>>>> Indeed. MS have to =
be=20
  masters of major updates as they have to do it =
all>>>>> the=20
  time.>>>>>
>>>>> However wrt =
testing the=20
  best time & place to do that is before
it>>>>> =
becomes=20
  part of the product & not after it's been released which is=20
  what>>>>> the openbsd people
tend towards vs the =
marketing=20
  driven cycle in>>>>> evidence wrt=20
  MSOS'es.>>>>>
>>>>>=20
  Adam>>>>>
>>>>> =
>>>>>=20
  >>>>>
>>>>> =
>>>>>=20
  >>>>>>
Rich>>>>>>=20
  >>>>>>
>>>>>> "John =
Beamish"=20
  <JLBeamish AT hotmail DOT com> wrote in=20
  message>>>>>> news:40f69bc7{at}w3.nls.net...>=
>>>>>=20
  (I'm not running
Linux.)>>>>>>=20
  >>>>>> I find that
statement "economical with =
the=20
  truth".  Assume that you>
know>>>>>> =
which=20
  module to go to.  Check it out, make the change, check it=20
  in,>>>>>> recompile
it, do regression testing =
(assume=20
  the change works and>
doesn't>>>>>> break =

  anything), update module documentation, update changelog,=20
  update>>>>>>
bugtracking.   In any =
serious=20
  environment, that's a day's work -- not> =
an>>>>>>=20
  hour.>>>>>>
>>>>>> What =
happens=20
  next?  Are Linux users expected to d/l the=20
  recompiled>>>>>> module =
or>>>>>>=20
  is there a process to compare the previous version with the=20
  new>>>>>> version =
and>>>>>>=20
  generate some kind of hex patch which gets downloaded and=20
  applied?>>>>>> Or =
what?>>>>>>=20
  >>>>>>
Thanks.>>>>>>=20
  >>>>>> "Adam
Flinton" <adam_NO_{at}_SPAM_softfab.com=">mailto:adam_NO_{at}_SPAM_softfab.com">adam_NO_{at}_SPAM_softfab.com=
>>>>>>=20
  <mailto:adam_NO_{at}_SPAM_softfab.=">mailto:adam_NO_{at}_SPAM_softfab.com">mailto:adam_NO_{at}_SPAM_softfab.=
com>>=20
  wrote in message>>>>>> =
>>>>>> >=20
  Security information moves very fast in cracker circles. On =
the>=20
  other>>>>>> >
hand, our experience is that =
coding and=20
  releasing of proper
security>>>>>> >
fixes =
typically=20
  requires about an hour of work -- very fast =
fix>>>>>>=20
  > turnaround is possible. Thus we think that full disclosure helps=20
  the>>>>>> >
people who really care about=20
  security.">>>>>> =
>>>>>>>=20
  >>>>>>>
> etc.>>>>>> =

  >>>>>>>
> Adam>>>>>> =

  >>>>
>>>>=20
>>

------=_NextPart_000_00C9_01C46DC9.899BCE00--

--- BBBS/NT v4.01 Flag-5