But if Windows had anything like ZFS, they could apply updates on a fork of a dataset and then reboot very quickly into that dataset. That is the right way to do updates in general, at the price of always having to reboot, but you can do a mix of in-place updates when those don't require reboots and any races are safe, and ZFS-style updates otherwise.
I should point out that this is not actually a blocker, if somebody at windows actually gave a fuck they could abuse winsxs to do blue/green symlinks to get around the file lock issue. Meaning the update could happen in the background and take effect next boot without anything needing to happen at boot time. Most could be done by just restarting the proper system service.
Its just microsoft has decided not to give a fuck. Rather then work on why people want to deferrer and delay updates, they have decided... well, whats that meme? "no its the kids who are wrong".
Quite frankly I find the Linux/Unix-style behaviour of being able to delete/overwrite an in-use file a bit disconcerting, but that might just be because I'm more used to the Windows way.
As for the time, I have no idea. A lot of it’s sitting there doing SFA looking at task manager.
Windows installs and reinstalls take hours more often than not -- just logging in for the first time on an up-to-date Win10 laptop recently took 10 minutes to "personalize" it for me ... and this was on an SSD. I used to have curiosity about how they made it so bad, but these days I've placed anything windows under a SEP field.
I also note that Macs often require update reboots too, which suggests there is more to this.
Some Linux updates also require a reboot on some distributions. Less frequently than Windows, but still there.
But I've never had an issue where something wouldn't work between the end of an update and a reboot, where that does happen on Windows. Furthermore, it has happened to me that after a kernel upgrade (on a system that did require a reboot to make it take effect), I took a couple of weeks before reboot (running long simulations), in which case I was able to apply yet another kernel upgrade or two; but you only ever need one reboot to make the latest-and-greatest take effect.
On Windows, you accumulate reboots if you wait (which requires constantly rejecting the "shall I reboot now" prompts) so you may need many; and I've sometimes needed several reboots even though I didn't delay anything.
The implementation is (IMO) really interesting from a programming perspective (https://www.kernel.org/doc/html/latest/livepatch/livepatch.h...).
Of course, one key difference here is the system never tricks you into rebooting, and rebooting for an update takes just as long as rebooting any other time, so mostly (pending additional work, as usual :b) it's invisible.
I seem to recall Microsoft exploring similar to ostree with some Windows version somewhere, so I'd be curious to see how theirs behaves.
AFAIK the only time this is the case is an update of something that can only be reloaded to get the updated version by rebooting--the most common case being the kernel.
I've been on my work Windows 10 PC for 60+hrs this week, and about the same each of the past four weeks, and five to six days out of seven the past couple years.
And never had it force-update.
You can bet the moment I took this computer home (I won't, but humour me) and tried to watch a movie it would force-update, crash, refuse to boot, and need a full reinstall.
kpatch:
But they naively schedule those minutes immediately after I've logged in, so the CPU and network is pegged and the disk thrashed while I'm sitting there cursing.
If I've logged in, it's to do a task. Not to wait for unattended-upgrades.py to finish its task before graciously handing the computer back to me.
Even waiting 10 minutes after login before checking for updates would be more tolerable.
With desktops, I can tell people that they are supposed to leave their computers on 24/7 but most normal people will use their laptop and shut the lid when done. That’s what they do with phones and iPads and that’s what they expect from their laptops.
That being said, I sincerely detest automatic reboots. It doesn’t affect me anymore because I have an ssd now but an operating system that reboots the computer without explicit approval from the user is trash. There is no excuse for this kind of nonsense.
I like Mozilla Firefox’s approach on my fedora machine. After I dnf update, Firefox refuses to open any more tabs until I close and open Firefox again. However, existing tabs continue working just fine and I can continue indefinitely before I close and open Firefox again. This is actual trust in computing. Trust your users to know best.
It's pretty frustrating, but it's still slightly better than Windows.
I had the same question, so I decided to look under the covers to see what the update process actually involves. I experienced true horror, ran away screaming, and never looked back.
There are panthers in there, lurking in the shadows.
(Assuming you run a recent Ubuntu)
(Before these arrived there were already some tool's for it, for some distros. But now everyone should be able to, unless the distro intentionally cripples the ability).
[0] https://lwn.net/Articles/619390/
All Linux/BSD systems I've used can update in minutes at the most (excluding the download time); I've long since wondered why Windows update is so much slower? Even binary diffs generally don't take that long to apply in my experience. So where is all the time spent?
Also why does it need to reboot? It is the "hard" file locking that's on Windows?