From: "Rich" 

This is a multi-part message in MIME format.

------=_NextPart_000_0057_01C46A5A.8E484B80
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   Nice try at spin.  Now, how much of the one hour of work claimed in =
your quote is testing the product being changed and compatibility with =
applications and other software that make use of it?  Please don't again =
make the silly claim that they tested the bug fix before they released =
there product with the bug so that no further testing is required.

Rich

  "Adam Flinton"  wrote in message =
news:40f6b951{at}w3.nls.net...
  Rich wrote:

  >    It may not be economical if testing is simply not something that=20
  > these folks care about.  The actual change is a tiny part of =
releasing=20
  > an update.
  > =20

  Indeed. MS have to be masters of major updates as they have to do it =
all=20
  the time.

  However wrt testing the best time & place to do that is before it=20
  becomes part of the product & not after it's been released which is =
what=20
  the openbsd people tend towards vs the marketing driven cycle in=20
  evidence wrt MSOS'es.

  Adam




  > 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?=20
  >     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
  >
------=_NextPart_000_0057_01C46A5A.8E484B80
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








   Nice try
at spin.  =
Now, how much=20
of the one hour of work claimed in your quote is testing the product = being=20
changed and compatibility with applications and other software that make = use of=20
it?  Please don't again make the silly claim that they
tested = the bug=20
fix before they released there product with the bug so that no further = testing=20
is required.
 
Rich
 

  "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 news:40f6b951{at}w3.nls.net...Ri=
ch=20
  wrote:>    It may
not be economical if =
testing is=20
  simply not something that > these folks care
about.  The =
actual=20
  change is a tiny part of releasing > an
update.> =20
  Indeed. MS have to be masters of major updates as
they have to =
do it=20
  all the time.However wrt testing the best
time & place =
to do=20
  that is before it becomes part of the product & not after it's =
been=20
  released which is what the openbsd people tend towards vs the =
marketing=20
  driven cycle in evidence wrt =
MSOS'es.Adam>=20
  Rich>  >
>     "John =
Beamish"=20
  <JLBeamish AT hotmail DOT com> wrote in=20
  message>     news:40f69bc7{at}w3.nls.net...>=
    =20
  (I'm not running Linux.)>
>     I =
find that=20
  statement "economical with the truth".  Assume that you=20
  know>     which
module to go to.  =
Check it=20
  out, make the change, check it
in,>     =
recompile=20
  it, do regression testing (assume the change works and=20
  doesn't>     break
anything), update module =

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

------=_NextPart_000_0057_01C46A5A.8E484B80--

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