[arp242]

> The computer decided to spend an hour doing updates instead

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?

[cryptonector]

In-place OS updates can be racy. Some updates require rebooting because they involve kernel changes that can't be applied to a running kernel. Then there's the WIN32 mandatory file locks issues, which prevent updates / replacement of files that apps are using.

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.

[MrStonedOne]

> Then there's the WIN32 mandatory file locks issues, which prevent updates / replacement of files that apps are using.

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".

[userbinator]

Even in the Win9x days, you could always rename a binary that was in use and copy the new one in its place, at which point newly spawned processes will use the new one while old processes continue to be unaffected.

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.

[m0xte]

Reboot is definitely the file locking. One of the worst architectural choices that they made.

As for the time, I have no idea. A lot of it’s sitting there doing SFA looking at task manager.

[freeone3000]

Big updates are secretly reinstalls of windows, where everything is dropped back in. Big, slow hard drives make this take longer.

[beagle3]

A complete reinstall of a modern Ubuntu on a spinning HDD takes less than 30 minutes in my experience (often less than 15).

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.

[maccard]

My last windows install was about 30 minutes from boot to actually on desktop (very frustratingly interactive though, blocking the last 10 minutes behind that personalizing dialog)

[kl4m]

And then there's the updates

[ToFab123]

Not really, if you download a fresh installation media from Microsoft

[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

[luckman212]

What's "SFA" (sorry for not knowing)

[justinclift]

In Australian lingo at least, from that context it means "Sweet F__k All". aka "not doing anything useful"

[dingaling]

> All Linux/BSD systems I've used can update in minutes at the most

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.

[eyegor]

Which distros have that problem? I generally stick to arch or centos, neither of which has tried to kneecap me at login time. Of course, both are fairly manual for updates unless you set up cron jobs to schedule them for you.

[dx87]

I use Ubuntu, and I've never had that problem. It usually checks for updates at boot, but doesn't actually download them until you manually approve it.

[mcny]

Laptop computers and hard disks are a big source of frustration. Either one is a hassle but combined they become a mess.

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.

[nitrogen]

I'm currently using Kubuntu, and sometimes the jobs that run at bootup hang the login screen and even prevent the TTY gettys (i.e. ctrl-alt-f2) from starting at all. In those cases I alt-sysrq-u and reset. Haven't determined whether it's fstrim, unattended-upgrades, a search indexer, or something else, because alt-sysrq-t is disabled in Ubuntu kernels and I can't start a task manager if I can't log in.

It's pretty frustrating, but it's still slightly better than Windows.

[jiggawatts]

> So where is all the time spent?

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.

[tbodt]

Tell me more.

[panpanna]

Now compare that to Linux where even the kernel can be updated without a reboot...

(Assuming you run a recent Ubuntu)

[eyegor]

Huh? The one thing you generally can't update is the kernel since it's the foundation of every other process. I haven't used ubuntu in several years, have things changed drastically?

[shakna]

There were three large patches that were integrated into the Linux kernel in version 4.0 (2014) that make it so that you can live patch the kernel easily. [0][1][2]

(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/

[1] https://lwn.net/Articles/622936/

[2] https://lwn.net/Articles/634649/

[innocenat]

Only if you register for Canonical Livepatch Service. Standard Ubuntu still requires reboot.

[m4rtink]

They do kexec ? (And no, ksplice/kpatch, if they are using that is not booting a new kernel.) I would be kinda worried about long term system state in that case...

[Dylan16807]

I'm confused by your question. Kexec is a reboot, at least as currently implemented, and that comment does not claim that it's "booting a new kernel".

[rcxdude]

Only partially: you can apply some bugfix and securit patches, but straight upgrades to a new kernel version still requires a reboot.