XPost: alt.comp.os.windows-11, comp.os.linux.advocacy
On Fri, 11/1/2024 9:41 PM, Joel wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 1 Nov 2024 04:26:27 -0400, Paul wrote:
And installing this stuff, is still not super-automated. It's like
pulling teeth, getting all the bits and pieces done properly.
That’s why they say, Windows is a great OS -- if your time is worth
nothing.
Just try updating either supported version with a spinning disk, see
how far it gets in how long. They'd say you can retrofit an aging PC
with a SATA SSD, yeah great, even that would probably be damn slow on pre-SATA III systems. Just a farce. The bloat of current Win10 is
only marginally less than 11. Winblows does indeed blow.
The thing is, you don't understand *why* it blows.
The story starts, roughly somewhere between Win2K and WinXP era.
They have a package management scheme. The same package management
is used today, as in WinXP era. A package could be as little, as a single DLL. It's not all LibreOffice-sized packages.
The scheme has a scaling problem. It requires calculation of supersedence. Which is, that a new update, replaces certain old updates. Or, that
a new update, needs a certain Servicing Stack Update or other pre-requisites. Each "package" is about three lines of text. The Windows 11 updates are traceable all the way back to WinXP. The WSUSSCN2.cab file is somewhere
between 1GB and 2GB of compressed three line text chunks. This is a lot of data to
digest. In the WinXP era, the file was 5MB in size. it's now 200x to 400x larger.
In the Windows 7 era, IT people complained to Microsoft, that a 2GB machine used to calculate updates several times a day. The calculation of the updates, used up all the RAM on the computer. The call center staff using the machines, could not do their jobs, because the machine was out of RAM each time a
package calculation (Check for Updates) was being done behind their backs.
Later on, they tried to bandaid the situation, by using "Jumbo Updates".
Other computer ecosystems have used Jumbo Updates too. But any time the packaging scheme seems to have changed, it's just a re-packaging of the
broken system, hoping to make it less broken (A Jumbo Update has a thousand packages inside, each one needing a calculation to prove correctness).
The Jumbo Updates are called "Cumulative", but sometimes you find that
three of them must install, not just one update, so they aren't exactly Cumulative either.
But the dependency calculator is very reliable. It just goes "exponential"
when computing what updates are required. The calculation was going exponential back in WinXP era. A middle manager promised at the time "we will absolutely fix this before the end of support for WinXP". Which was of course,
absolute bullshit. Nothing got fixed. The same scheme is underneath
the Windows 11 OS right now. The same exponential behaviors are still
present. You can see them in Task Manager.
Microsoft actually fitted *data structure compression*, so when the
dependency calculations are being done, there was a space time tradeoff,
by using less RAM, but requiring decompression of structures during
the processing. This is the change that allowed Windows 7 2GB laptops
to work at 10AM in the morning -- it was the compression that made it
work again. That's one of the few changes to Windows Update, which
was an actual technical improvement. There is some variation of this
idea, going on today, but because nobody discusses this stuff any more,
I don't know what the consumption pattern represents (it's kinda a sawtooth now).
The latest change, is a Delta Update scheme, which is similar to the
Mozilla .mar method of updating Firefox. Instead of downloading an
entire executable, you can instead download a binary patch and patch
the existing executable, then verify the hash is correct. But this has
no bearing on the cursed calculation. It's more creamy Ranch Dressing
to hide the brokenness.
But at its heart, the "exponential" behavior, the expanding those
three lines of text for each package and package version, that
hasn't changed. A SHA2 protects the integrity of the file, and
that takes the place of the SHA1 used in the WinXP era.
Is it slow ? Hell, yes, it's slow. The disk light does not flash
when it is "thinking". It's CPU bound. A faster CPU can make it go
faster, by a little bit.
Using an SSD of the SATA type, even if it is SATA II, has the
advantage of reduced seek time. This still affords some improvement
in a Windows Update calculation. But for the times where it is
compute bound and railed on one core, at this point, the storage
is no longer the issue. There may also be a requirement that the
calculation be a single thread of execution. Your 128 core CPU makes
no difference to the problem.
The Microsoft staff and even I, dream of using a different scheme for
package management. It's an area devoid of ideas. We're stuck with it.
If you prune the supersedence tree, that helps reduce the calculation time. Repetitive updates such as KB890830, those have a huge tree. Internet Explorer had a huge tree (many sub-versions). They smashed Internet Explorer,
they removed it, they damaged it on the older OSes, but part of this
is also a tip of the hat to the package tree. Removing it so it no longer
needs updates, shaves some of the exponential time off.
What if the product had fewer packages ? Hah! Like that's going to happen.
Look at the WinSxS (Windows Side By Side) directory, count the files,
that's a measure of how many update-able packages are in there. And every kernel
change can undoubtedly be traced all the way back to Win2K. The windows
kernel is one of the things with a huge tree tied to it.
If you are using Vista SP2, you go to Windows Update, you click the
Check For Updates, that operation never comes back. The exponential
behavior was so bad, it basically could not do updates any more.
The guys at WSUSOffline understood which items contributed to this,
and they could sort the order of package installation, to stop
the behavior so the process could gain traction again. But once the
signing change from SHA1 to SHA2 happened, I think that borked Vista
for good. Today, I don't think you can install Vista and patch it
Some of the others, are still patchable, slow, but they eventually
patch.
Good features: Never makes a mistake. Delete state info, it still
correctly figures out what needs updating.
Bad features: The algorithm is O(fuck). It's exponential. In the
case of Vista, the calculation never finishes.
When Windows Update is healthy, an update check
*cannot take less than three minutes*. That's the best
case behavior observed. That is the baseline. Everything
else is measured with respect to the three minute case.
https://tech.slashdot.org/story/13/12/16/1959259/exponential-algorithm-in-windows-update-slowing-xp-machines
Microsoft Windows
Exponential Algorithm In Windows Update Slowing XP Machines
Posted by samzenpus on Monday December 16, 2013 @05:57PM from the no-pep-in-your-step dept.
jones_supa writes
"An interesting bug regarding update dependency calculation has been found in Windows XP.
By design, machines using Windows Update retrieve patch information from Microsoft's update
servers (or possibly WSUS in a company setting). That patch information contains information
about each patch: what software it applies to and, critically, what historic patch or patches
the current patch supersedes. Unfortunately, the Windows Update client components used an
algorithm with exponential scaling when processing these lists. Each additional superseded
patch would double the time taken to process the list. With the operating system now very old,
those lists have grown long, sometimes to 40 or more items. On a new machine, that processing
appeared to be almost instantaneous. It is now very slow. After starting the system,
svchost.exe is chewing up the entire processor, sometimes for an hour or more at a time.
Wait long enough after booting and the machine will eventually return to normalcy.
Microsoft thought that it had this problem fixed in November's Patch Tuesday update <=== Microsoft *knows* it cannot fix...
after it culled the supersedence lists. That update didn't appear to fix the problem.
The company thought that its December update would also provide a solution, with even <=== The notion it was trying, is bullshit
more aggressive culling. That didn't seem to help either. For one reason or another,
Microsoft's test scenarios for the patches didn't reflect the experience of real Windows XP machines. <=== <cough> Hah!
"
Paul
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
