[jimnotgym]

My impression, as an enterprise user is that Windows updates require reboots less frequently than they used to.

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.

[beagle3]

Some linux updates require a reboot for a kernel update to take effect; Many modern ones, if properly configured, can update the kernels without rebooting (e.g. Ubuntu, RedHat and Oracle all have that as a paid option for businesses, Ubuntu also free for personal or oss use).

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.

[rcxdude]

Live kernel patching is limited though: it can update most functions and some datastructures, but not all. This is great for bugfixes and security patches but can't deal with larger updates. If you're trying to keep on the latest version you need to reboot at some point.

[Reelin]

> can update the kernels without rebooting

The implementation is (IMO) really interesting from a programming perspective (https://www.kernel.org/doc/html/latest/livepatch/livepatch.h...).

[dylan-m]

Some distributions are switching to a more aggressive "reboot for any system update" model, with the system built on ostree or something of the sort. For instance, Ubuntu Core, Fedora Silverblue, or Endless OS. The update is downloaded and committed to disk (in a big, git-like repo for the latter two), but you need to boot into it. Your running system is untouched. This comes with the bonus that rollback is seamless: you choose an older commit from grub and it just works.

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.

[pdonis]

> Some Linux updates also require a reboot on some distributions.

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.

[TheSpiceIsLife]

Windows 10 Pro user at work, mixed MacOS / Windows / Lubuntu at home.

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.

[nitrogen]

Maybe your employer is running their own update server with their own update policies? If only at-home pro users could do that.

[jimnotgym]

Well short of running your own home server and AD, you can join it to Azure AD and try Intune? Haven't used Intune to control patching myself yet.

[jimnotgym]

Actually domain joined Windows machines tend to keep their state when they can't see their domain controller. You would probably find, depending on config, that updates stop all together.

[TheSpiceIsLife]

Ah, I see. I’ll check.

[brian_herman__]

you can get something like ksplice/kpatch for kernel reboots for security and other issues and not reboot https://en.m.wikipedia.org/wiki/Ksplice

https://ksplice.oracle.com/

kpatch:

https://access.redhat.com/articles/2475321