View Single Post
  #31  
Old March 17th 19, 10:39 PM posted to alt.comp.os.windows-10
VanguardLH[_2_]
external usenet poster
 
Posts: 10,881
Default I just had a radical idea

Char Jackson wrote:

Thanks for the detailed reply. As for the possibility of corrupt updates
being shared within the LAN, I assume each update package is signed so
that a host knows if it can be trusted. However, if MS isn't taking
advantage of the other hosts on the LAN in this way, then I might as
well just disable the whole thing.


The scary part, even omitting the possibility of malicious tampering, is
that updates are not delivered whole from host to host using WUDO.
Instead pieces of the update file are delivered and the pieces can come
from different hosts through different routes. It was bad enough when
you'd get an update (in whole) from Microsoft's WSUS server and had
problems getting it installed. With WUDO, rebuilding the update file
from pieces adds another potential instability, and you haven't a clue
from where the bad update piece originated. The piecemeal approach is
to permit resume of the update retrieval (from multiple sending hosts).

https://www.deviousweb.com/2015/08/0...-optimization/
"WUDO works a lot like bittorrent. Your computer is used as part of a
global peer-to-peer network to allow the distributed delivery of
software updates with each person distributing a little bit of the files
across multiple computers and helping everyone download updates more
quickly."
https://thehackernews.com/2015/08/wi...10-update.html
"our computer running Windows 10 is used as part of a peer-to-peer
network to deliver software updates faster to others, each person
distributing a little bit of the files across multiple computers and
helping everyone download updates quickly."

So, to speed up the download, the P2P client (WUDO) grabs pieces of the
file across multiple hosts while retrieving them in parallel streams
over the network to rebuild them locally. I'd rather get one complete
file and from a known source (Microsoft's WSUS server). There also seem
to be a plethora of conditions that will prevent the use of WUDO, so
your host ends up using WSUS instead.

https://cmma.org/cmma-blog/the-pros-...-optimization/
"No control over content"

That point concerns me. While WUDO builds a local cache for P2P
distribution of the update (in pieces), it seems it will add more to the
local cache for a host than the updates only needed by that particular
host.

BITS was a known network traffic manager, plus any process can utilize
BITS to manage their downloads, like updates to a program and not just
for Windows (I've yet, however, to see anyone other than Microsoft using
it, but then I'm not knowledgeable about the inner workings of all
software regarding their updates). WUDO doesn't use BITS, and why users
have been reporting their network getting choked by WUDO. With the
problems with WUDO choking your network, its efficiency and parallelism
is lost with slow delivery. All because Microsoft, as with everything
Windows 10, thinks your computer is their property, so they're going to
steal a portion of your PC to use as their distributed server farm.

I don't run any variant of Bittorrent or its ilk on my hosts. I
certainly don't want a variant from Microsoft. I'd rather schedule a
run of WSUSoffline which connects to *Microsoft's* WSUS server. It
definitely impacts the usability of the host where it runs and generates
lots of traffic (and why I schedule it), and I can tote or FTP its
update store to my other hosts over my local network WHEN *I* choose.
Just as with Windows 10 updates not being under your control of when and
preparing for the update(s) (by closing all your work and saving a
backup image since System Restore has proven unreliable), I don't want
some other backgrounded update distribution scheme employed to
distribute updates to other hosts when I'm not going to apply them there
anyway at the time of piecemeal delivery (I disable the BITS and WU
services to enforce when *I* want to do the updates).

More FM (****ing magic) to go wrong, harder to troubleshoot, doesn't
save on network bandwidth (since even in paralleled piecemeal fashion
the entire file still has to get sent) and isn't as well backgrounded as
BITS, and all under the guise of getting you the updates quicker (which
I've yet to see any benchmarking to prove so) but is really to offline
some of the update network off Microsoft's servers.
Ads