From: "Rich" 

This is a multi-part message in MIME format.

------=_NextPart_000_01CA_01C2C90C.3DB24900
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   I see no problem tracking the versions of files in updates.

Rich

  "Geo."  wrote in message =
news:3e3a5bd1$1{at}w3.nls.net...
  my point was that part of the problem with the patch method used by =
windows
  update is that even MS can't track what is the current versions of =
each and
  every file included in the distribution. The recent post describing
  sqlserver patches shows this problem well.

  if instead of patching, they were trying to keep a distribution up to =
date I
  believe it would greatly simplify things. It would at least eliminate =
one
  patch overwriting later versions of the files it includes.

  I suppose if they just had one patch and kept it up to date instead of
  releasing separate patches, that might also work but that wouldn't =
help
  eliminate all the old install CD's that contain exploitable code =
because
  there is nothing to replace them with. I was trying to address both =
these
  problems.

  Geo.

  "Rich"  wrote in message news:3e39fd75{at}w3.nls.net...
     No.  It has never been an issue.  What isn't trivial using Windows
  Update, Office Update, or similar, the IT folks will take care of if I =
wish.

  Rich

    "Geo."  wrote in message =
news:3e39f157$1{at}w3.nls.net...
    Ok I get it, you were talking about internal MS network stuff. But =
even
    there you have to deal with the array of different hotfixes instead =
of
  just
    a comprehensive once a month update process.

    Geo.

    "Rich"  wrote in message news:3e38c348$1{at}w3.nls.net...
       I don't know.  Maybe.  In any case, that's not copy protection.  =
My
    installs are almost always from the network and don't require me to =
keep
    track of keys.

    Rich




------=_NextPart_000_01CA_01C2C90C.3DB24900
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








   I see no
problem tracking =
the versions=20
of files in updates.
 
Rich
 

  "Geo." <georger{at}nls.net>">mailto:georger{at}nls.net">georger{at}nls.net>
wrote=20
  in message news:3e3a5bd1$1{at}w3.nls.net...my=20
  point was that part of the problem with the patch method used by=20
  windowsupdate is that even MS can't track what is the current =
versions of=20
  each andevery file included in the distribution. The recent post=20
  describingsqlserver patches shows this problem
well.if =
instead of=20
  patching, they were trying to keep a distribution up to date =
Ibelieve it=20
  would greatly simplify things. It would at least eliminate =
onepatch=20
  overwriting later versions of the files it includes.I suppose =
if they=20
  just had one patch and kept it up to date instead ofreleasing =
separate=20
  patches, that might also work but that wouldn't helpeliminate all =
the old=20
  install CD's that contain exploitable code becausethere is nothing =
to=20
  replace them with. I was trying to address both=20
 
theseproblems.Geo."Rich"
<{at}> wrote in =
message news:3e39fd75{at}w3.nls.net...&nbs=
p; =20
  No.  It has never been an issue.  What isn't trivial using=20
  WindowsUpdate, Office Update, or similar, the IT folks will take =
care of=20
  if I wish.Rich 
"Geo." <georger{at}nls.net>">mailto:georger{at}nls.net">georger{at}nls.net>
wrote in =
message news:3e39f157$1{at}w3.nls.net...=
 =20
  Ok I get it, you were talking about internal MS network stuff. But=20
  even  there you have to deal with the array of different =
hotfixes=20
  instead ofjust  a comprehensive once a month update=20
  process.  Geo. 
"Rich" <{at}> wrote in =
message news:3e38c348$1{at}w3.nls.net...=
    =20
  I don't know.  Maybe.  In any case, that's not copy=20
  protection.  My  installs are almost always from the =
network and=20
  don't require me to keep  track of
keys. =20
 
Rich

------=_NextPart_000_01CA_01C2C90C.3DB24900--

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