<https://www.youtube.com/watch?v=27Sjkh-MMtU>

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 23 Jan 2026 18:50:39 GMT, CrudeSausage wrote:

<https://www.youtube.com/watch?v=27Sjkh-MMtU>

Fake film scratches. Does anyone really like those?

--
Mark Lloyd
http://notstupid.us/

"Think not that I am come to send peace on earth; I came not to send
peace, but a sword." -- Jesus, Matthew 10:34

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 1/23/2026 1:50 PM, CrudeSausage wrote:

<https://www.youtube.com/watch?v=27Sjkh-MMtU>

************* Audio transcript so you don't have to watch the video at the top of this page ***************

00:00:00 But wait, it turns out that shut down in Windows 10 doesn't actually mean shut down. Is this just another example of computer companies not trusting us to operate our own stuff? December 2025, a Reddit post goes viral. 340,000 upvotes in 18 hours. The title, I just want to turn off my computer. The
user describes clicking shut down at 11 p.m. Windows 11 says, "Installing updates, 0% complete. 3 hours later at 2:00 a.m., still installing, 47% complete. He has to be up for work at 6:00 a.m. He can't force shutdown or the

00:00:43 update corrupts. He can't unplug it safely. He just sits there waiting, watching a progress bar that moves slower than Evolution. At
4:30 a.m., the computer finally shuts down. 5 and 1/2 hours to turn off a computer. The comments explode with similar stories. Took me 4 hours last
week. I missed my flight because Windows wouldn't shut down. Lost client presentation because forced update restarted during render. Microsoft's response: silence. And users are done waiting. They're switching

00:01:13 operating systems. buying Macs, installing Linux, anything to
escape the prison of a computer that won't turn off when you tell it to. The forced updates that hijack computers, Windows 10 let you delay updates,
not indefinitely, but you had some control. Schedule them. Choose when to install. Windows 11 remove that control. Updates install when Microsoft decides, not when you decide. You click shut down. Windows changes it to
update and shut down. You don't get a choice. The button you clicked doesn't exist anymore. Microsoft

00:01:46 decided your computer needs updating right now. Your schedule doesn't matter. The update process is hostile. No accurate time estimates. Says installing updates. This might take several minutes. Translation: Could
be 20 minutes. Could be 4 hours. You won't know until it's done. Can't
do anything except watch. Can't use the computer. Can't safely turn it
off. You're trapped. held hostage by an operating system that thinks it
knows better than you when your computer should be

00:02:13 available. Thomas Bradley runs a small architecture firm in
Chicago. Eight workstations running Windows 11. Friday evening, 6:00
p.m. Employees trying to go home. Click shut down. All eight computers start installing updates simultaneously. Nobody told them updates were coming. Nobody asked if now was a good time. Microsoft decided progress bars crawl. 700
p.m. still updating. 7:30 p.m. One computer finished. 7 still going. 8:00
p.m. Four done. Four stuck at various percentages. One employee has

00:02:48 dinner reservations at 8:30. Can't leave. Can't abandon a computer mid-update. Finally, at 8:45 p.m., some all computers finish. His employees missed their Friday evening plans because Windows decided 6:00 p.m. on
Friday was update time. He told me the next Monday he started researching, switching to Linux. The forced updates cost his company 20 hours of employee time waiting for computers to finish updating. That's $800 in wasted labor watching progress bars. He's not switching because Linux is better. He's

00:03:20 switching because Windows is unusable. The restarts that destroyed work. Forced restarts are worse than forced updates. At least with Shutdown, you chose to turn off the computer. Forced restarts happen while you're working. Windows decides your computer needs to restart for updates. Gives
you a notification. If you don't see it within 15 minutes, Windows restarts anyway. Whatever you're doing gets closed, work gets lost, applications crash, and Windows acts like it did you a favor by keeping your

00:03:50 computer secure. Rebecca Martinez is a PhD student at UC
Berkeley. She's analyzing genomic data, running computational models that take 8 to 12 hours. She starts a model at 900 a.m. Goes to class. Comes back at 5:00 p.m. to check progress. Computers at the login screen. Restarted. The model didn't finish. She lost 8 hours of computation. Has to start over. She checks Windows update history. Update installed at 2:47 p.m. Computer restarted. She was in class, couldn't see the notification. Windows restarted

00:04:28 her computer in the middle of critical research. She's not an
isolated case. The EI/ Windows 11 subreddit has a weekly mega thread just
for forced restart destroyed my work stories. Video editors losing hours of rendering. Programmers losing code compilations. 3D artists losing complex simulations. Data scientists losing analysis runs. All because Windows
decided updates were more important than user work. One user calculated the damage. He's a freelance video editor. Forced restart killed an

00:05:03 overnight render. 14 hours lost. He bills $85 per hour. That restart cost him $1,190 in loss productivity. He can't bill his client for Windows, destroying his work. He absorbs the loss. He switched to Da Vinci Resolve on Linux the next week. Said if his OS is going to cost him thousands in lost work. He's getting an OS he controls. The update loop that traps users. Some users face something worse than long updates. Infinite update loops. Computer installs updates. Restarts. Says configuring updates.

00:05:40 Please don't turn off your computer. Gets to 100%. Restarts
again. Says installing updates. 0% complete. Same update again. Gets to
100%. Restarts. Preparing to configure Windows. Restarts. Configuring
updates. The loop continues for hours, sometimes days. Michael Torres
in Houston experienced this Thursday morning. Started his computer
for work. Update loop began. 9:00 a.m. Thursday to 2:00 p.m. Friday. 29
hours. Computer cycling through updates repeatedly. Same screens over and
over. He finally forced shutdown by

00:06:18 holding the power button. Booted into recovery mode, rolled
back the update. Computer worked again, but the update automatically tried installing again that night. Loop started again. He disconnected his Ethernet cable, disabled Wi-Fi, blocked Microsoft update servers in his router. The
only way to stop the loop was preventing Windows from accessing updates entirely. He's not alone. Microsoft support forums have hundreds of threads about update loops. Users stuck for days. Microsoft's official solution,
run troubleshooters,

00:06:49 try recovery mode, reinstall Windows. No acknowledgement that their update system is broken. No fix, just workarounds that require technical knowledge most users don't have. So, computers stay trapped in loops,
unusable for days, and Microsoft acts like this is normal. But even when Windows shuts down successfully, it's not really off. Windows 11 uses fast startup by default. Sounds good. Makes boots faster. What it actually does
is hibernate instead of shutting down. Saves system state to

00:07:20 disk. Next boot loads that state instead of starting
fresh. Technically, your computer never fully shuts down unless you disable fast startup in hidden power settings. Why does this matter? Because hibernation state can get corrupted, causes crashes, causes performance
issues, causes problems that full shutdowns would prevent, and users don't
know it's happening. They click shut down thinking the computer turns off. It doesn't. It hibernates and pretends it shut down. Full restart is different

00:07:49 from shutdown. Restart actually turns the computer off and
back on. Shutdown with fast startup just hibernates. This confuses troubleshooting. Tech support says try restarting your computer. Users
shut down and turn back on. Doesn't fix the problem because shutdown isn't actually restarting. They need to choose restart specifically or disable fast startup which requires knowing it exists and finding it in advanced power settings. Most users never open. Aaron Mitchell is a tech support worker for a

00:08:20 small business. He gets 5 to 10 calls weekly from users saying,
"I restarted my computer like you said. It didn't fix the problem." He has
to explain they need to choose restart, not shut down, or hold shift while clicking shutdown to bypass fast startup. Users get frustrated. Why is shutting down different from restarting? Why doesn't shut down actually shut down? He doesn't have good answers. Because there aren't good answers. Windows made shutdown complicated for speed benefits that

00:08:49 aren't worth the confusion. Windows 11's aggressive update behavior exists because it's designed for enterprise IT departments. Corporate environments want mandatory updates. Ensure all computers stay
patched. Security takes priority over user convenience. That makes sense
in managed corporate environments. It makes no sense for home users who own their computers and should control them. But Microsoft applies the same update philosophy to everyone. Home users get treated like corporate employees whose

00:09:20 IT department doesn't trust them. You're not the administrator
of your own computer. Microsoft is. They decide when updates install, when restarts happen, what settings are allowed. You're a user with restricted permissions on hardware you bought. Sarah Johnson bought a computer for
her home office. Works from home as an accountant. Her computer, her desk,
her electricity bill, but she can't control when it updates. can't control
when it restarts. Can't prevent updates from breaking her workflow.

00:09:47 Microsoft treats her like an employee they manage, not a customer
they serve. She resents it. She's not working for Microsoft. She's a
customer. But Windows 11 doesn't respect that relationship. This fundamental disrespect is why users are leaving. It's not really about updates taking
too long. It's about control. Whose computer is it? You paid for it. You
own the hardware. But Microsoft acts like they own it. They control what software runs on it, when it updates, when it shuts down, what

00:10:16 data it collects. You're allowed to use it only under Microsoft's terms. And users are realizing that's not acceptable. Where this ends,
January 2026, Microsoft finally addresses complaints in a blog post. They're exploring options to give users more control over updates. Translation:
Nothing changes. They've been exploring options since Windows 10. The update system gets more aggressive with every version. Words mean nothing without action. And Microsoft's actions show they have no intention of returning

00:10:49 control to users. So users are taking control themselves. Switching
to operating systems where shutdown actually shuts down, where updates happen when you choose, where forced restarts don't exist. Linux distributions give users complete control. Updates install only when you approve them. Nothing installs automatically. Nothing restarts without permission. It's your computer. You control it. What a concept. Mac users don't face forced
restarts. MacOSS prompts for updates. Doesn't install

00:11:20 without permission. Doesn't restart without confirmation. Apple respects that users control their computers. Windows doesn't. That difference is driving platform switches at accelerating rates. The irony is Microsoft created this problem trying to solve another problem. Too many users never updated Windows 10, left computers vulnerable. Microsoft's solution was removing choice entirely, force updates on everyone. But the cure is worse than the disease. Yes, forced updates ensure security patches and stall. But they

00:11:53 also make computers unusable during updates, destroy work with forced restarts, break drivers and settings. The security benefit isn't worth the productivity cost. Better solution? Make updates less disruptive. Install in background without requiring restarts. Apply updates during idle time. Never restart without explicit user permission. Never take longer than 5 minutes
to shut down. Respect that users need computers to work, not spend hours updating. But that would require Microsoft prioritizing user experience

00:12:26 over corporate IT convenience. They won't do that. Enterprise pays
the bills. Home users are just data sources. If this frustrated you because
you face the same problems, share it. Because Microsoft won't acknowledge
that users are angry about update behavior. They'll keep claiming they're improving user experience while forcing updates at inconvenient times. But users know better. They're the ones who lost work to forced restarts, who missed appointments because computers wouldn't

00:12:53 shut down, who wasted hours watching update progress bars. They
know Windows update system is hostile to users and they're choosing
operating systems that respect their time and work. That's what's really happening. Windows is losing users because it won't let them shut down their own computers. It sounds absurd, but it's true. And Microsoft refuses to
fix it. So users are fixing it themselves by switching platforms permanently.

************* End: Audio transcript so you don't have to watch it ***************

I tried running one of the peoples names and details in the video
in Google, and got no hits.

Next.

Paul

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:

00:05:03 overnight render. 14 hours lost. He bills $85 per hour.
That restart cost him $1,190 in loss productivity. He can't bill his
client for Windows, destroying his work. He absorbs the loss. He
switched to Da Vinci Resolve on Linux the next week.

Just one thing, though: Da Vinci Resolve requires a GPU, and as you
may have heard, GPUs are getting a bit expensive and hard-to-obtain
lately.

So moving to proprietary software on an open-source platform is only a
partial solution; you are still going to get bitten by product
limitations at some point.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 1/24/2026 2:02 AM, Lawrence D?Oliveiro wrote:

On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:

00:05:03 overnight render. 14 hours lost. He bills $85 per hour.
That restart cost him $1,190 in loss productivity. He can't bill his
client for Windows, destroying his work. He absorbs the loss. He
switched to Da Vinci Resolve on Linux the next week.

Just one thing, though: Da Vinci Resolve requires a GPU, and as you
may have heard, GPUs are getting a bit expensive and hard-to-obtain
lately.

So moving to proprietary software on an open-source platform is only a partial solution; you are still going to get bitten by product
limitations at some point.

You can use InControl, check your winver.exe and set InControl
to match, so that no Upgrades come in unannounced. That's on the
assumption an Upgrade could come in. While an Upgrade (25H2) is supposed
to require a button click, there are cases that suggest such
a limitation is not present. This fixes that. I'm using this
right now.

https://www.grc.com/incontrol.htm

*******

There is a Pause Updates button in the Windows Updates panel
that you can use. That could help with your patch planning.

I would Pause Updates a few days before Patch Tuesday, and
set the duration so it is approaching closer to the end of the
month. But this still requires attention to detail on the
part of the user, to carry out the patches by taking the
Pause off, on a weekend when the machine is not busy.

I would agree the situation is far from ideal, and the controls
suck ass. And talking to Microsoft and providing feedback
is just a waste of your time. None of the feedback has ever
factored into a better interface for this. "Hours Of Usage" ???
Get Outta Here (tm). They have such a concept in the OS,
but where is the "user manual for what this affects".

There was a little joke of a program, which automatically went
in on an hourly basis and changed that setting, in an attempt
to prevent the OS from ever doing updates. I doubt such an
approach works today.

Some of the claims in the video, were valid back in 2015-2016 or so.
I started a week-long Image Composite Editor run one day, and
only four hours after starting, a notification appeared saying the
machine was going to reboot no later than X. And I had to abort
the run, and clear the dumpster so I could use my machine. I have
experienced this, but the design has been changed many times since then.
For example, I no longer see random machine starting at night to
sneak in updates. That no longer seems to happen. We used to get
machines waking, where the machine apparently did not know why
it had been awakened. Whatever was waking it up, did not follow through.

That's what makes preparing a good video so hard. You have a lot
of obsolete claims to dismiss (as "maybe they fixed that"), and
then new claims about how it works today. Does every session
advance the same way ? No! How am I going to write a summary
when there are 100 different behaviors ? This also makes it
hard to answer these charges, or even develop a comprehensive
plan with a guarantee of success. I do not think the situation
is as bad as claimed, but I've only got three machines getting
regular updates so what do I know.

If you know the incoming KB number, you can download the item yourself
(on your timetable) and install it. But the problem with using a .msu
today from catalog.update.microsoft.com , is the things are 4GB in size,
which implies the entire OS is inside the KB. Then it takes an extra
hour for the excess materials already patched, to be purged from
the set of things really needed. That means using the .msu method
is a Not Recommended option. But I did actually use that on two
machines here, because of the slow download behavior I was seeing
for getting the updates the "normal" way (the update would pretend
to be downloading things, and the LED on the modem/router was not lit
implying the usable download rate was zero at the time)). It does not matter how you set your BITS policy or your DoSVC policy, the fucking WU
just has a mind of its own in terms of the bandwidth it is willing to
use (which could be 0 bytes per second). That's the reason I downloaded
a 4GB file and jammed that in. Worked fine. But not a
"big win for the good guys". Again, whole experience == sucked ass.

There are programs to shut it off entirely. Not tested. Not Recommended.

Paul

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 1/24/2026 2:02 AM, Lawrence D?Oliveiro wrote:

On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:

00:05:03 overnight render. 14 hours lost. He bills $85 per hour.
That restart cost him $1,190 in loss productivity. He can't bill his
client for Windows, destroying his work. He absorbs the loss. He
switched to Da Vinci Resolve on Linux the next week.

Just one thing, though: Da Vinci Resolve requires a GPU, and as you
may have heard, GPUs are getting a bit expensive and hard-to-obtain
lately.

So moving to proprietary software on an open-source platform is only a partial solution; you are still going to get bitten by product
limitations at some point.

One other thing. When running machines in non-interactive mode,
like doing a batch run on a helper machine, just unplug the
network cable for a little more privacy. There are lots of times
and scenarios through a day, where the network cable is disconnected
for fun and profit. I even bring things over on media and manually
transfer files into a machine, to achieve a given end. It's not
like the network cables stay in the machines here on a continuous
basis and I'm grinding my teeth because of some MSFT automation.

Paul

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:

On Fri, 1/23/2026 1:50 PM, CrudeSausage wrote:

<https://www.youtube.com/watch?v=27Sjkh-MMtU>

************* Audio transcript so you don't have to watch the video at
the top of this page ***************

00:00:00 But wait, it turns out that shut down in Windows 10 doesn't
actually mean shut down. Is this just another example of computer
companies not trusting us to operate our own stuff? December 2025, a
Reddit post goes viral. 340,000 upvotes in 18 hours. The title, I just
want to turn off my computer. The user describes clicking shut down at
11 p.m. Windows 11 says, "Installing updates, 0% complete. 3 hours later
at 2:00 a.m., still installing, 47%
complete. He has to be up for work at 6:00 a.m. He can't force shutdown
or the

00:00:43 update corrupts. He can't unplug it safely. He just sits there waiting, watching a progress bar that moves slower than Evolution. At
4:30 a.m., the computer finally shuts down. 5 and 1/2 hours to turn off
a computer. The comments explode with similar stories. Took me 4 hours
last week. I missed my flight because Windows wouldn't shut down. Lost
client presentation because forced update restarted during render. Microsoft's response: silence. And users are done waiting. They're
switching

00:01:13 operating systems. buying Macs, installing Linux, anything to
escape the prison of a computer that won't turn off when you tell it to.
The forced updates that hijack computers, Windows 10 let you delay
updates,
not indefinitely, but you had some control. Schedule them. Choose when
to install. Windows 11 remove that control. Updates install when
Microsoft decides, not when you decide. You click shut down. Windows
changes it to update and shut down. You don't get a choice. The button
you clicked doesn't exist anymore. Microsoft

00:01:46 decided your computer needs updating right now. Your schedule doesn't matter. The update process is hostile. No accurate time
estimates. Says installing updates. This might take several minutes. Translation: Could be 20 minutes. Could be 4 hours. You won't know until
it's done. Can't do anything except watch. Can't use the computer. Can't safely turn it off. You're trapped. held hostage by an operating system
that thinks it knows better than you when your computer should be

00:02:13 available. Thomas Bradley runs a small architecture firm in
Chicago. Eight workstations running Windows 11. Friday evening, 6:00
p.m. Employees trying to go home. Click shut down. All eight computers
start installing updates simultaneously. Nobody told them updates were coming. Nobody asked if now was a good time. Microsoft decided progress
bars crawl. 700 p.m. still updating. 7:30 p.m. One computer finished. 7
still going. 8:00 p.m. Four done. Four stuck at various percentages. One employee has

00:02:48 dinner reservations at 8:30. Can't leave. Can't abandon a
computer mid-update. Finally, at 8:45 p.m., some all computers finish.
His employees missed their Friday evening plans because Windows decided
6:00 p.m. on Friday was update time. He told me the next Monday he
started researching,
switching to Linux. The forced updates cost his company 20 hours of
employee time waiting for computers to finish updating. That's $800 in
wasted labor watching progress bars. He's not switching because Linux is better. He's

00:03:20 switching because Windows is unusable. The restarts that
destroyed work. Forced restarts are worse than forced updates. At least
with Shutdown,
you chose to turn off the computer. Forced restarts happen while you're working. Windows decides your computer needs to restart for updates.
Gives you a notification. If you don't see it within 15 minutes, Windows restarts anyway. Whatever you're doing gets closed, work gets lost, applications crash,
and Windows acts like it did you a favor by keeping your

00:03:50 computer secure. Rebecca Martinez is a PhD student at UC
Berkeley. She's analyzing genomic data, running computational models
that take 8 to 12 hours. She starts a model at 900 a.m. Goes to class.
Comes back at 5:00 p.m. to check progress. Computers at the login
screen. Restarted. The model didn't finish. She lost 8 hours of
computation. Has to start over. She checks Windows update history.
Update installed at 2:47 p.m. Computer restarted. She was in class,
couldn't see the notification. Windows restarted

00:04:28 her computer in the middle of critical research. She's not an isolated case. The EI/ Windows 11 subreddit has a weekly mega thread
just for forced restart destroyed my work stories. Video editors losing
hours of rendering. Programmers losing code compilations. 3D artists
losing complex simulations. Data scientists losing analysis runs. All
because Windows decided updates were more important than user work. One
user calculated the damage. He's a freelance video editor. Forced
restart killed an

00:05:03 overnight render. 14 hours lost. He bills $85 per hour. That
restart cost him $1,190 in loss productivity. He can't bill his client
for Windows,
destroying his work. He absorbs the loss. He switched to Da Vinci
Resolve on Linux the next week. Said if his OS is going to cost him
thousands in lost work. He's getting an OS he controls. The update loop
that traps users. Some users face something worse than long updates.
Infinite update loops. Computer installs updates. Restarts. Says
configuring updates.

00:05:40 Please don't turn off your computer. Gets to 100%. Restarts
again. Says installing updates. 0% complete. Same update again. Gets to
100%. Restarts. Preparing to configure Windows. Restarts. Configuring updates. The loop continues for hours, sometimes days. Michael Torres in Houston experienced this Thursday morning. Started his computer for
work. Update loop began. 9:00 a.m. Thursday to 2:00 p.m. Friday. 29
hours. Computer cycling through updates repeatedly. Same screens over
and over. He finally forced shutdown by

00:06:18 holding the power button. Booted into recovery mode, rolled
back the update. Computer worked again, but the update automatically
tried installing again that night. Loop started again. He disconnected
his Ethernet cable, disabled Wi-Fi, blocked Microsoft update servers in
his router. The only way to stop the loop was preventing Windows from accessing updates entirely. He's not alone. Microsoft support forums
have hundreds of threads about update loops. Users stuck for days. Microsoft's official solution,
run troubleshooters,

00:06:49 try recovery mode, reinstall Windows. No acknowledgement that
their update system is broken. No fix, just workarounds that require technical knowledge most users don't have. So, computers stay trapped in loops,
unusable for days, and Microsoft acts like this is normal. But even when Windows shuts down successfully, it's not really off. Windows 11 uses
fast startup by default. Sounds good. Makes boots faster. What it
actually does is hibernate instead of shutting down. Saves system state
to

00:07:20 disk. Next boot loads that state instead of starting fresh. Technically, your computer never fully shuts down unless you disable
fast startup in hidden power settings. Why does this matter? Because hibernation state can get corrupted, causes crashes, causes performance issues, causes problems that full shutdowns would prevent, and users
don't know it's happening. They click shut down thinking the computer
turns off. It doesn't. It hibernates and pretends it shut down. Full
restart is different

00:07:49 from shutdown. Restart actually turns the computer off and back
on. Shutdown with fast startup just hibernates. This confuses troubleshooting. Tech support says try restarting your computer. Users
shut down and turn back on. Doesn't fix the problem because shutdown
isn't actually restarting. They need to choose restart specifically or disable fast startup which requires knowing it exists and finding it in advanced power settings. Most users never open. Aaron Mitchell is a tech support worker for a

00:08:20 small business. He gets 5 to 10 calls weekly from users saying,
"I restarted my computer like you said. It didn't fix the problem." He
has to explain they need to choose restart, not shut down, or hold shift while clicking shutdown to bypass fast startup. Users get frustrated.
Why is shutting down different from restarting? Why doesn't shut down actually shut down? He doesn't have good answers. Because there aren't
good answers. Windows made shutdown complicated for speed benefits that

00:08:49 aren't worth the confusion. Windows 11's aggressive update
behavior exists because it's designed for enterprise IT departments. Corporate environments want mandatory updates. Ensure all computers stay patched. Security takes priority over user convenience. That makes sense
in managed corporate environments. It makes no sense for home users who
own their computers and should control them. But Microsoft applies the
same update philosophy to everyone. Home users get treated like
corporate employees whose

00:09:20 IT department doesn't trust them. You're not the administrator
of your own computer. Microsoft is. They decide when updates install,
when restarts happen, what settings are allowed. You're a user with restricted permissions on hardware you bought. Sarah Johnson bought a computer for her home office. Works from home as an accountant. Her
computer, her desk,
her electricity bill, but she can't control when it updates. can't
control when it restarts. Can't prevent updates from breaking her
workflow.

00:09:47 Microsoft treats her like an employee they manage, not a
customer they serve. She resents it. She's not working for Microsoft.
She's a customer. But Windows 11 doesn't respect that relationship. This fundamental disrespect is why users are leaving. It's not really about updates taking too long. It's about control. Whose computer is it? You
paid for it. You own the hardware. But Microsoft acts like they own it.
They control what software runs on it, when it updates, when it shuts
down, what

00:10:16 data it collects. You're allowed to use it only under
Microsoft's terms. And users are realizing that's not acceptable. Where
this ends,
January 2026, Microsoft finally addresses complaints in a blog post.
They're exploring options to give users more control over updates. Translation:
Nothing changes. They've been exploring options since Windows 10. The
update system gets more aggressive with every version. Words mean
nothing without action. And Microsoft's actions show they have no
intention of returning

00:10:49 control to users. So users are taking control themselves.
Switching to operating systems where shutdown actually shuts down, where updates happen when you choose, where forced restarts don't exist. Linux distributions give users complete control. Updates install only when you approve them. Nothing installs automatically. Nothing restarts without permission. It's your computer. You control it. What a concept. Mac
users don't face forced restarts. MacOSS prompts for updates. Doesn't
install

00:11:20 without permission. Doesn't restart without confirmation. Apple respects that users control their computers. Windows doesn't. That
difference is driving platform switches at accelerating rates. The irony
is Microsoft created this problem trying to solve another problem. Too
many users never updated Windows 10, left computers vulnerable.
Microsoft's solution was removing choice entirely, force updates on
everyone. But the cure is worse than the disease. Yes, forced updates
ensure security patches and stall. But they

00:11:53 also make computers unusable during updates, destroy work with forced restarts, break drivers and settings. The security benefit isn't
worth the productivity cost. Better solution? Make updates less
disruptive. Install in background without requiring restarts. Apply
updates during idle time. Never restart without explicit user
permission. Never take longer than 5 minutes to shut down. Respect that
users need computers to work, not spend hours updating. But that would require Microsoft prioritizing user experience

00:12:26 over corporate IT convenience. They won't do that. Enterprise
pays the bills. Home users are just data sources. If this frustrated you because you face the same problems, share it. Because Microsoft won't acknowledge that users are angry about update behavior. They'll keep
claiming they're improving user experience while forcing updates at inconvenient times. But users know better. They're the ones who lost
work to forced restarts, who missed appointments because computers
wouldn't

00:12:53 shut down, who wasted hours watching update progress bars. They
know Windows update system is hostile to users and they're choosing
operating systems that respect their time and work. That's what's really happening. Windows is losing users because it won't let them shut down
their own computers. It sounds absurd, but it's true. And Microsoft
refuses to fix it. So users are fixing it themselves by switching
platforms permanently.

************* End: Audio transcript so you don't have to watch it ***************

I tried running one of the peoples names and details in the video in
Google, and got no hits.

Next.

Paul

You're going to tell me that you've never had an update take hours to complete? I've used every Windows since 3 and kept my systems extremely
clean. Even under perfect conditions, Microsoft requires a ridiculous
amount of time to update systems on many occasions, and even then there is
no guarantee that your machine will be bootable once they complete. If
you're suggesting this never happens, you're just lying.


--
CrudeSausage
John 14:6
Isaiah 48:16
Pop_OS!

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

CrudeSausage <crude@sausa.ge> wrote:

<https://www.youtube.com/watch?v=27Sjkh-MMtU>

I can't be bothered to watch the whole video or/and read the whole
audio transcript, but it strikes me as quite a bit of hoopla, for an OS (Windows 11) which already exists for well over *four years!

Yes, it's changed behaviour (from Windows 10) and can be annoying, but
if this "I can't use my computer!" 'problem' happens to you after the
first monthly updates, you haven't been paying much attention.

If you set your 'Active hours' (which indeed sometimes are set to
strange times) and flip the 'Notify me when a restart is required to
finish updating' switch to On, the system will *not* Restart by itself,
so you will not have the dreaded "I can't use my computer!" 'problem'.
Period. (And, as said, you can 'Pause updates' (for upto 5 weeks), but
that of course requires planning, which might not always be possible or
not enter the 'victim''s mind.)

But yes, an inexperienced user on an unmanaged system will probably
get hirself in trouble at some stage. News at ten!

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

CrudeSausage <crude@sausa.ge> wrote:

On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:

[Audio transcript deleted.]

You're going to tell me that you've never had an update take hours to complete?

Indeed, I never had that. We're talking Windows 11 here, which mostly
uses modern hardware (because of TPM and stuff) and probably SSDs.

I've used every Windows since 3 and kept my systems extremely
clean. Even under perfect conditions, Microsoft requires a ridiculous
amount of time to update systems on many occasions,

'Even' a complete 'repair install' shouldn't take much more than an
hour, including the download time when the system is still up/usable.

and even then there is
no guarantee that your machine will be bootable once they complete. If you're suggesting this never happens, you're just lying.

Yes, it does happen. Does it happen that often? I don't think so. It
never happened to me, from Windows 1.0 all the way through 11.

BTW, many of the horror scenarios seem to involve laptops (not
desktops) - why bother to mention such 'details'? :-( -, which should
not be Shut down or Restart-ed nilly willy, but just let/put to sleep
(or hibernate).

And the case with 8 workstations/employees shutting down at the end of
the day, same story: Unmanaged systems/procedures will get you into
trouble. News at ten.

Bottom line: Technology requires management/time. Don't spend it and
sooner or later it will spend it for you.

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 24 Jan 2026 16:26:01 GMT, Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:

[Audio transcript deleted.]

You're going to tell me that you've never had an update take hours to
complete?

Indeed, I never had that. We're talking Windows 11 here, which mostly
uses modern hardware (because of TPM and stuff) and probably SSDs.

I've been using SSDs since 2009 and NVMes since 2015 and I've constantly
faced that issue, even on hardware that was maintained regularly. Why do
you insist on lying?

I've used every Windows since 3 and kept my systems extremely
clean. Even under perfect conditions, Microsoft requires a ridiculous
amount of time to update systems on many occasions,

'Even' a complete 'repair install' shouldn't take much more than an
hour, including the download time when the system is still up/usable.

If anything, it should take less. However, one has to wonder how broken
the operating system is if "repair installs" are a normalized process.
Even MacOS doesn't require them.

< snip >



--
CrudeSausage
John 14:6
Isaiah 48:16
Pop_OS!

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

CrudeSausage <crude@sausa.ge> wrote:

On 24 Jan 2026 16:26:01 GMT, Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:

[Audio transcript deleted.]

You're going to tell me that you've never had an update take hours to
complete?

Indeed, I never had that. We're talking Windows 11 here, which mostly uses modern hardware (because of TPM and stuff) and probably SSDs.

I've been using SSDs since 2009 and NVMes since 2015 and I've constantly faced that issue, even on hardware that was maintained regularly. Why do
you insist on lying?

"lying"!? Bye, bye!

[...]

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 24 Jan 2026 04:22:54 -0500, Paul wrote:

Some of the claims in the video, were valid back in 2015-2016 or so.

But there are still people stuck on those old versions of Windows, who
can?t move off for one reason or another, aren?t there? So those claims
still apply to a surprisingly large section of the Windows installed base.

There are programs to shut it off entirely. Not tested. Not
Recommended.

This is why they say, Windows is a great OS -- if your time is worth
nothing.

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 24 Jan 2026 20:22:46 GMT, Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

On 24 Jan 2026 16:26:01 GMT, Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:

[Audio transcript deleted.]

You're going to tell me that you've never had an update take hours
to complete?

Indeed, I never had that. We're talking Windows 11 here, which
mostly
uses modern hardware (because of TPM and stuff) and probably SSDs.

I've been using SSDs since 2009 and NVMes since 2015 and I've
constantly faced that issue, even on hardware that was maintained
regularly. Why do you insist on lying?

"lying"!? Bye, bye!

[...]

I assure you that I'll be spending my night in a corner, crying my eyes
out.



--
CrudeSausage
John 14:6
Isaiah 48:16
Pop_OS!

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 1/24/2026 6:41 PM, CrudeSausage wrote:

On 24 Jan 2026 20:22:46 GMT, Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

On 24 Jan 2026 16:26:01 GMT, Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:

[Audio transcript deleted.]

You're going to tell me that you've never had an update take hours
to complete?

Indeed, I never had that. We're talking Windows 11 here, which
mostly
uses modern hardware (because of TPM and stuff) and probably SSDs.

I've been using SSDs since 2009 and NVMes since 2015 and I've
constantly faced that issue, even on hardware that was maintained
regularly. Why do you insist on lying?

"lying"!? Bye, bye!

[...]

I assure you that I'll be spending my night in a corner, crying my eyes out.

We can only go by what we see here.

There are best practices to follow, and if people don't
follow them, they "get a surprise".

Around 2015-2016, I started what I thought would be a one week
long compute run (Image Composite Editor ~70 images). Four hours
into the run, a notification popped up indicating I must restart
the computer within some number of hours (which happened to not be
a week). I had to stop what I was doing, lose four hours work,
and start all over again. But there are things I can do today,
to prevent that from happening. Just the setting in Windows Update,
to delay updates, is enough.

There are things you can do, to make WU worse.

1) Switch from your SSD to HDD (Test Machine uses HDD for Win11...
it's what I've got for the purpose of using it, can't afford more SSDs) .
2) Download the 4GB version of a Cumulative Update, instead of using
the much smaller version that comes in through Windows Update.
It takes time for the software to whittle away at the 4GB thing
(a line at a time), until the bits that remain are determined as
being suited to your custom installation and its current operating state.
Just the order, or the timing of the installation of certain things,
affect what happens on a Cumulative much later.

While a WU is being installed, these may offer a slight speed advantage.

1) services.msc Switch off SysMain (aka SuperFetch) as it is "mostly pointless".
2) Bring up the Security interface, switch off Real Time protection.
3) Open Task Manager, kill the SearchIndexer.exe process

Those are examples of activities that reduce the I/O level enough, that
Windows Update gets some bandwidth. When Windows Update adds 200,000 files
to the C: drive, this makes the SearchIndexer.exe go crazy with work.

If your processor has extra L3 cache, an update can install faster.
The reason we know this, is a 5GHz processor runs much much faster
than a 3.4GHz processor, and via clock rate alone, it's not apparent
where the gain comes from. We know that a piece of code written
in WinXP era, runs and sucks the life out of WU, and it is compute
bound. It would be my guess, that a little extra L3 on the processor
in question, is helping. Most of the stuff that Microsoft does,
is single-threaded, and the WU supersedence calculation is no
exception.

There is a theory that doing a "Rebase" on the OS, will speed
up future WU activity. But it appears that the argument is
likely neutered, and doesn't do anything. For example, if a new
W11 DVD was issued, and it was "ahead" of the base release
(26100 or 26200), maybe that would be of a slight advantage
to you (makes any security update run slightly faster).

The 26H1 listed here, will only install on certain hardware
and it's not likely for X86. 26H2 is likely to be more general.

https://en.wikipedia.org/wiki/Windows_11_version_history

On the Big Machine, I can have updates that take 2-5 minutes.
Not the sloggingly slow show on the Test Machine. And it is not
like the extra cores make a difference. The cache on the Big Machine
is not all that good, the incoming X3D would be better (two
cache dies that sit on top of two CPU dies for a total of three cache segments).

I've only seen Microsoft software rail the entire computer, just once.
Windows Defender disassembled a 7ZIP with a libarchive with
multithreaded decompression of a large .7z . I have not seen
a repeat of this activity, and I cannot tell you whether
that was removed from the Windows version of libarchive or not.
Normally, libarchive does not exhibit such a feature (which is
why I use an installed copy of Igor Pavlov 7ZIP instead to
unpack such files). Most of the time, an 8C 16T processor,
the OS might use 3 cores worth. It's not exactly in a rush.
But the OS can manage to busy-out a HDD without too much trouble
(making it seek all over the place reading 2KB files). Even if
they used their own System Read cache, we could make WU that
ran fast on a HDD. But they won't do that, and they Read Uncached
for almost everything they do. The System Read cache is virtually
worthless.

Paul

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Sat, 24 Jan 2026 04:22:54 -0500, Paul wrote:

Some of the claims in the video, were valid back in 2015-2016 or so.

But there are still people stuck on those old versions of Windows, who
can?t move off for one reason or another, aren?t there? So those claims
still apply to a surprisingly large section of the Windows installed base.

But these people did not learn how to prevent their (Windows Update
timing) 'problems' in those ten years, exactly *why*!?

There are programs to shut it off entirely. Not tested. Not
Recommended.

This is why they say, Windows is a great OS -- if your time is worth
nothing.

s/they/I/

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

You're going to tell me that you've never had an update take hours to
complete?

Indeed, I never had that. We're talking Windows 11 here, which mostly
uses modern hardware (because of TPM and stuff) and probably SSDs.

I've not seen it on Win11, but I know that earlier versions (can't
remember if it was 7 or 10 or both) had a problem that could cause
updates to take hours. There were a couple of individual updates that
could be done first, to "fix" this problem.


--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 1/25/2026 4:48 PM, chrisv wrote:

Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

You're going to tell me that you've never had an update take hours to
complete?

Indeed, I never had that. We're talking Windows 11 here, which mostly
uses modern hardware (because of TPM and stuff) and probably SSDs.

I've not seen it on Win11, but I know that earlier versions (can't
remember if it was 7 or 10 or both) had a problem that could cause
updates to take hours. There were a couple of individual updates that
could be done first, to "fix" this problem.

The suoersedence calculation done by the Windows Update stack,
is a compute bound activity, in which, the longer the OS exist and
things are patched, the longer it takes to figure out whether an incoming package should be used, and something else purged.

At one point, Vista SP2 was in such bad shape, the calculation
could run for *days*. Today, if you install Vista SP2, you will
notice it never completes (you are never shown a list of updates
that you could install). And that is because the signing of
WSUSSCN2.cab is now SHA2 and that Vista stack only knows about
SHA1 for signing.

When Windows switched to "Cumulative" this and that, the jumbo update
style, the calculation NEVER stopped doing what it was doing in the
WinXP era. You're dealing with a 2GB WSUSSCN2.cab file which is
analyzed *three sentences* at a time. It's a huge huge data
processing thing. Patches only contain a tiny portion of that file
(relevant bits). But the Microsoft Baseline Security Analyzer,
it checked the entire file, in order to compute what security
patches were missing (it did not handle Optional ones).

IT administrators will tell you that "some of the wheel spin could
have been stopped if Microsoft curated the repo better". The Administrators would manually operate their own WSUS servers, knowing what order
to install things, to stop the insanity.

This also led to the WSUSOffline project, having several levels
of script for tipping Windows Update upright. One of the things done
after collecting certs early on, is a set of five updates that
prune Internet Explorer and kernel file and gdi-something-or-other.
These were executables that got changed every month, and they are
responsible for a lot of the calculation delay.

On Windows 7, on corporate machines having 2GB of RAM (the call
center machines), the Windows Update calculation was running every
hour or two, to "see if there were incoming updates". The updates
are not "sent" to you, the need of them is "calculated". Well, when
the process to do that would start, it was *consuming all RAM*
on the 2GB machines :-) Leading to corporate staff not being able
to do anything. An emergency patch went out, which *compressed*
the blasted data structure. What this does, is trade calculation
execution time, versus memory footprint. IT Admins were quite
thankful that this came out, as the machines could now be used
by staff (even if one core was railed doing that background stuff).

If you prune the supersedence tree, by patching the naughty bits
first, then the other patches can finish a lot faster.

With the invention of Cumulatives and the bundling of
Cumulative and Servicing Stack Update into one file, we
have the worst of all possible worlds. Now, you cannot
craft install sequences to prune anything, and you
are depending on the curation skills of Microsoft staff.

The process can be accelerated by:

1) CPU speed, to the expected extent.
2) Memory bandwidth, typical acceleration coming from
a processor with a larger L3.
3) Some sort of magical cleaning process for your WinSxS
side by side tree. There are a thousand packages at least
in that tree, and the scanning for updates, involves that
tree. If you're doing this on a HDD, then shame on you :-)
I purposely run one machine here on an HDD, for modeling
purposes (to reproduce user observations of trouble).

The option to "ReBase" the OS, seems to be disconnected and
does not do anything. That's an attempt to remove some history
so the calculation runs faster.

As a user, if you lack the skills (or the interest) in fixing
your C: contents, you can do a Repair Install, using a DVD
of the same version as your winver.exe tells you is present.
If it says 26100.1234, then you would use a 26100 DVD. You
have the option of disconnecting the network cable while
doing that, or leaving the network cable connected.
(I prefer disconnection, for better control over proceedings.)

The Repair Install will do some of the patching, before the
desktop appears again. Repair Install is a relatively
low-friction way of dealing with complex issues outside your
pay scale. Since some packages have "side effects" like
fiddling something in UEFI, some packages still have to
run on their own. There will be incoming patches to install
the 2023 item in UEFI, this year, before the signing on
something expires (affects Secure Boot only).

The Migration Logic was recently changed on Windows. Migration
was simplified, to a scary extent. This can shave an hour
off the Repair Install time, on those pesky machines with
their HDDs. The Migration logic used to study each installed
application like a forensics researcher. Today it just gives
the App a little slap and sends it on its way (registry entries
and all). That's just my subjective guess as to why that happens
so fast.

It takes willful ignorance, to reduce these computers to puddles
of goo. If you're receiving notifications that problems exist,
you're supposed to do *something*, not give the provider company
the finger so your "story of disaster" can be more impressive.

It's a lot like the kids that jump up and down in the
elevator at the mall, until they break part of it. If the
car plunged to the basement, the news would be full of
"elevator company takes unnecessary risks, some of our
finest youth killed". When in fact, it is willful stupidity
that will kill those people. The elevators in question, were
reduced from examples of moderate quality elevators,
to those puddles of goo. Now, the elevator pushes its own
buttons. And so on.

Windows Update has a Pause button. It's not ideal, but
for the complainers, it does allow them to schedule
downtime to better fit their workflow. And I don't
like Windows Update, any more than anyone else. It does
not have princely behavior, and is not a shining beacon
of how to do it.

Paul

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 25 Jan 2026 18:34:26 -0500, Paul wrote:

The [Windows Update] process can be accelerated by:

1) CPU speed, to the expected extent.
2) Memory bandwidth, typical acceleration coming from a processor
with a larger L3.
3) Some sort of magical cleaning process for your WinSxS side by
side tree. ...

What it seems to me you are saying, is that a lot of the need for
newer, faster hardware for running Windows, is just to speed up the
*UPDATE PROCESS*?

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 26 Jan 2026 01:46:33 -0000 (UTC), Lawrence D?Oliveiro wrote:

On Sun, 25 Jan 2026 18:34:26 -0500, Paul wrote:

The [Windows Update] process can be accelerated by:

1) CPU speed, to the expected extent.
2) Memory bandwidth, typical acceleration coming from a processor
with a larger L3.
3) Some sort of magical cleaning process for your WinSxS side by
side tree. ...

What it seems to me you are saying, is that a lot of the need for newer, faster hardware for running Windows, is just to speed up the *UPDATE PROCESS*?

I have to agree here. Linux will update quickly whether I am running the latest processor or a computer from 2007. Since most of the applications
being run aren't requiring you to compile them, the only thing determining
how long it takes is the speed of your Internet connection (and the
Ethernet or wifi chip connecting to it).

--
CrudeSausage
John 14:6
Isaiah 48:16
Pop_OS!

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 1/25/2026 8:46 PM, Lawrence D?Oliveiro wrote:

On Sun, 25 Jan 2026 18:34:26 -0500, Paul wrote:

The [Windows Update] process can be accelerated by:

1) CPU speed, to the expected extent.
2) Memory bandwidth, typical acceleration coming from a processor
with a larger L3.
3) Some sort of magical cleaning process for your WinSxS side by
side tree. ...

What it seems to me you are saying, is that a lot of the need for
newer, faster hardware for running Windows, is just to speed up the
*UPDATE PROCESS*?

The update process has always had the same issue.

As time passes and the record of packages grows in
size, this increases the computational load.

That's partially why the load scales with time.

It's kinda like how much effort you have to put in today,
to earn yourself a Bitcoin. It's a lot more effort than when
Bitcoin first came out.

The effort to correct it, only has to proceed with respect
to the speed of the "average current hardware". They are
not curating the repo in such a way, that a WinXP era
E8400 runs this with blazing speed.

The update process is good, in that *it never makes mistakes*.

The update process is bad, in that *it is unbounded*.

Can it be rewritten ? My conclusion is that the answer is No.

And unlike when a database question comes up, and every dev tuned
into the thread replies with "I could write that", I have not
heard anyone with the chops to do it, volunteering to fix it.

In a sense, rather than being the 3rd version of the Win11 kernel,
it is the 87th instance of the WinXP kernel. There is some detail
where the release control goes way way back. And when they haven't
put the effort into curating it, on a given month, that is when
the performance will be variable and head towards the slow side.

This is probably a topic, where the AI could write us a description
of how it works.

****************************************************************

When you put too much information in the question, the answer
tends to blend too much of the question, into the answer. Still,
for the flavor, we can ask...

********************* CoPilot Question ************************

In Windows 11, the Windows Update process is sometimes slow to
complete a Cumulative Update.

What is the computation that is carried out during a Windows update, doing ?

It seems to consider each tiny package in WinSxS, one by one, and work out whether an incoming patch supersedes something already on disk. There is mention of WSUSSCN2.cab as a controlling master file for the process.

Could you describe that process of computation for me ?

It seems to work faster with extra L3 cache, as if the process
is slightly memory bandwidth dependent.

********************* CoPilot Answer ************************

Windows Update looks deceptively simple on the surface - *download patch, install patch*
but under the hood it performs a surprisingly heavy, metadata-driven computation. What
you?re noticing about WinSxS, supersedence checks, and cache sensitivity is absolutely real. Let?s unpack what?s going on in a way that matches how the servicing stack actually behaves.

---

# What Windows Update *Actually Computes* During a Cumulative Update

A Cumulative Update (CU) is not a monolithic patch. It?s a
**bundle of thousands of component updates**, each targeting specific files, manifests,
and registry entries. Windows uses the **Component-Based Servicing (CBS)** engine to
determine exactly what must be installed, replaced, or skipped.

The computation is essentially a **large dependency-resolution and
supersedence graph traversal**.

---

# Key Structures Involved

## **1. WinSxS Store**
This is the canonical database of:
- Component manifests (`*.manifest`)
- Component payloads (`*.mum`)
- Versioned side-by-side assemblies
- Supersedence metadata

Each component has:
- A unique identity (name, version, culture, processor arch)
- A version chain
- A supersedence chain
- A payload footprint

The store can contain **tens of thousands** of components.

---

## **2. The Servicing Stack (CBS + TrustedInstaller)**
This is the engine that:
- Reads

On Sun, 1/25/2026 9:40 PM, CrudeSausage wrote:

On Mon, 26 Jan 2026 01:46:33 -0000 (UTC), Lawrence D?Oliveiro wrote:

On Sun, 25 Jan 2026 18:34:26 -0500, Paul wrote:

The [Windows Update] process can be accelerated by:

1) CPU speed, to the expected extent.
2) Memory bandwidth, typical acceleration coming from a processor
with a larger L3.
3) Some sort of magical cleaning process for your WinSxS side by
side tree. ...

What it seems to me you are saying, is that a lot of the need for newer,
faster hardware for running Windows, is just to speed up the *UPDATE
PROCESS*?

I have to agree here. Linux will update quickly whether I am running the latest processor or a computer from 2007. Since most of the applications being run aren't requiring you to compile them, the only thing determining how long it takes is the speed of your Internet connection (and the
Ethernet or wifi chip connecting to it).

I hate to be a party poop, but there have been cases of part of the installation process being slower than necessary. The code that
updates the manual pages, it had some weird behavior when run in
a virtual machine, that did not match the behavior in a physical
install of Linux. Somebody had a bad case of paranoia, when they
started sensing what Ring their code was running in. Presumably, there
was some concern based on an exploit being done while manual pages
were being processed.

But such delays are not even remotely close to the Windows dependency calculations.

You will also find Linux distros that have a "spring in their step",
and aren't quite as lethargic as some of their buttery colleagues.
But nobody in the Linux world cares about this. While I have
a test I can run, to highlight this, my "court case" is not
strong enough for me to go on a "name and shame" campaign.
If anyone is concerned about this, they aren't saying much.

Paul


--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 25 Jan 2026 21:42:23 -0500, Paul wrote:

On Sun, 1/25/2026 8:46 PM, Lawrence D?Oliveiro wrote:

On Sun, 25 Jan 2026 18:34:26 -0500, Paul wrote:

The [Windows Update] process can be accelerated by:

1) CPU speed, to the expected extent.
2) Memory bandwidth, typical acceleration coming from a processor
with a larger L3.
3) Some sort of magical cleaning process for your WinSxS side by
side tree. ...

What it seems to me you are saying, is that a lot of the need for
newer, faster hardware for running Windows, is just to speed up the
*UPDATE PROCESS*?

The update process has always had the same issue.

As time passes and the record of packages grows in size, this increases
the computational load.

That's partially why the load scales with time.

It's kinda like how much effort you have to put in today,
to earn yourself a Bitcoin. It's a lot more effort than when Bitcoin
first came out.

The effort to correct it, only has to proceed with respect to the speed
of the "average current hardware". They are not curating the repo in
such a way, that a WinXP era E8400 runs this with blazing speed.

The update process is good, in that *it never makes mistakes*.

People whose machines got an update only to have that same update be
offered to them after a reboot might have something to say about that.
It's the same with people who are offered an update and for whom the
update never completes and delivers some cryptic 0x4EREE error message.

The update process is bad, in that *it is unbounded*.

Can it be rewritten ? My conclusion is that the answer is No.

It needs to be; it has only gotten worse with time. My suggestion is that depending on the version a person is running, a computer decides to skip individual updates in favour of large service packs like they did back in
the day. If, for example, a person is running 21H2, the only update they should be offered is 25H2 with individual updates thereafter. Instead, it seems like they offer a ton of individual updates, then 22H2, then more individual updates, then 23H2 and so on. It increases the load on their servers and wastes the user's time. At least with Linux, if you're running something like Ubuntu 18.04 and realize that it's getting old (or it's no longer supported), you can just get the 25.04 version of the software and install on top of it without sacrificing your /home directory.

< snip AI garbage >

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

chrisv <chrisv@nospam.invalid> wrote:

Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

You're going to tell me that you've never had an update take hours to
complete?

Indeed, I never had that. We're talking Windows 11 here, which mostly
uses modern hardware (because of TPM and stuff) and probably SSDs.

I've not seen it on Win11, but I know that earlier versions (can't
remember if it was 7 or 10 or both) had a problem that could cause
updates to take hours. There were a couple of individual updates that
could be done first, to "fix" this problem.

Yes, a few hours (two?) in the *past*, on older hardware ('small' RAM,
no SSD), but most of that was *online* time, i.e. the system was still
up, but 'just' busy'. But a quick perusal of the video transcript, talks
about 7 hours of *offline* time (i.e. restarting/rebooting). *If* that
ever happened on a modern, sufficiently specced system, then something
was seriously wrong and that's by no means typical. Trying to spread it
as typical/common is just FUD, click-bait, etc..

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Sun, 25 Jan 2026 18:34:26 -0500, Paul wrote:

The [Windows Update] process can be accelerated by:

1) CPU speed, to the expected extent.
2) Memory bandwidth, typical acceleration coming from a processor
with a larger L3.
3) Some sort of magical cleaning process for your WinSxS side by
side tree. ...

What it seems to me you are saying, is that a lot of the need for
newer, faster hardware for running Windows, is just to speed up the
*UPDATE PROCESS*?

The update process is partly 'online', i.e. the system is still up
and can be used normally or is in its non active hours, and partly
'offline', i.e. restarting, doing the final installation of the
update(s) and possibly restarting another time.

The latter (offline) phase is what all the hoopla is all about. But
yes, on my medium level laptop, that takes 'forever', possibly as much
as 5 *minutes*, so you'll have to excuse me, while I'm running to the
shop to get the desperately needed "faster hardware"!

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/25/2026 8:42 PM, Paul wrote:

---snip---

# In Summary

Windows Update?s ?slow phase? is dominated by:

| Stage | What Happens | Why It is Slow |
|-------------------------|-----------------------------------------|----------------------------------|
| Manifest parsing | Load thousands of XML manifests | Many tiny files, heavy parsing |
| Supersedence evaluation | Compare each component to WinSxS | Graph traversal, pointer chasing |
| Applicability rules | Evaluate prerequisites and dependencies | Constraint solving |
| Transaction planning | Build install plan | Large metadata structures |

This is fundamentally a **metadata computation problem**, not an I/O problem.

Your observation about L3 cache is spot-on: the workload is memory-latency-bound.

********************* End: CoPilot Answer ************************

Paul

Thanks for the very interesting work to show us exactly what the process
all involves. Very informative and helpful!


--
Science Doesn?t Support Darwin. Scientists Do


--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/26/26 10:06 AM, CrudeSausage wrote:

On Sun, 25 Jan 2026 21:42:23 -0500, Paul wrote:

< snip AI garbage >

Crude as usual shows his reactionary nature.

--
Joel W. Crump

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 1/26/2026 10:22 AM, sticks wrote:

On 1/25/2026 8:42 PM, Paul wrote:

---snip---

#ÿ In Summary

Windows Update?s ?slow phase? is dominated by:

| Stageÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ | What Happensÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ | Why It is Slowÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ |
|-------------------------|-----------------------------------------|----------------------------------|
| Manifest parsingÿÿÿÿÿÿÿ | Load thousands of XML manifestsÿÿÿÿÿÿÿÿ | Many tiny files, heavy parsingÿÿ |
| Supersedence evaluation | Compare each component to WinSxSÿÿÿÿÿÿÿ | Graph traversal, pointer chasing |
| Applicability rulesÿÿÿÿ | Evaluate prerequisites and dependencies | Constraint solvingÿÿÿÿÿÿÿÿÿÿÿÿÿÿ |
| Transaction planningÿÿÿ | Build install planÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ | Large metadata structuresÿÿÿÿÿÿÿ |

This is fundamentally a **metadata computation problem**, not an I/O problem.

Your observation about L3 cache is spot-on: the workload is memory-latency-bound.

*********************ÿ End: CoPilot Answerÿ ************************

ÿÿÿ Paul

Thanks for the very interesting work to show us exactly what the process all involves.ÿ Very informative and helpful!

I just thought it was weird, that the machine with more L3,
seems to be doing updates faster. My original conclusion was
that there was cheating of some sort going on :-)

Paul



--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 1/26/2026 10:11 AM, Frank Slootweg wrote:

chrisv <chrisv@nospam.invalid> wrote:

Frank Slootweg wrote:

CrudeSausage <crude@sausa.ge> wrote:

You're going to tell me that you've never had an update take hours to >>>> complete?

Indeed, I never had that. We're talking Windows 11 here, which mostly
uses modern hardware (because of TPM and stuff) and probably SSDs.

I've not seen it on Win11, but I know that earlier versions (can't
remember if it was 7 or 10 or both) had a problem that could cause
updates to take hours. There were a couple of individual updates that
could be done first, to "fix" this problem.

Yes, a few hours (two?) in the *past*, on older hardware ('small' RAM,
no SSD), but most of that was *online* time, i.e. the system was still
up, but 'just' busy'. But a quick perusal of the video transcript, talks about 7 hours of *offline* time (i.e. restarting/rebooting). *If* that
ever happened on a modern, sufficiently specced system, then something
was seriously wrong and that's by no means typical. Trying to spread it
as typical/common is just FUD, click-bait, etc..

Typically when that happens, it's because the offline update
phase is "parked". I find that the only stimulus that makes any
difference, is unplugging the network cable. And it doesn't
happen instantly either. It might take 30 seconds before
you notice a few blinks of the disk light.

And while this is happening, you have the juggling balls on the screen.

Whether it is a deadlock in some code, or an intentional
timer-based activity, I don't really know of good ways to check.
While you can start collecting a trace with Process Monitor,
and collect a shutdown trace and a boot trace, I don't know
what you could expect to find in there. The ETW subsystem could
be shut down, at the point where the machine is not making
forward progress on the Update queued.

Paul



--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)