Why? It directly results in almost every Windows update requiring a reboot to apply, compared to usually only an application restart or at most desktop logout/login on Linux.

Having to constantly reboot my computer, or risk missing important security patches, was very annoying to me on Windows.

I've never had to reboot after updating glibc in years of using Linux, as far as I can remember.

You got some moderately bad advice.

Running programs will continue to use the libc version that was on disk when they started. They won't even know glibc was upgraded. If something is broken before rebooting, it'll stay broken after.

This is not true. Different programs on the same system that interoperate and use different versions of the same shared library can absolutely cause issues.

For a trivial change to glibc, it won't cause issues. But there's a lot of shared libraries and lots of different kinds of changes in different kinds of libraries that can happen.

I still haven't nailed if it was due to a shared library update, but just the other day, after running upgrades I was unable to su or sudo / authenticate as a user until after rebooting.

It does happen, but it's pretty rare compared to Windows in my experience, where inconvenience is essentially guaranteed.

Firefox on Linux did not really enjoy being updated while running, as far as I remember; Chrome was fine with it, but only since it does some extra work to bypass the problem via its "zygote process": https://chromium.googlesource.com/chromium/src/+/main/docs/l...

Works fine with Nix and Guix since it doesn't replace JS or other shared config files in-place to perform updates

The only time I need to reboot my Linux Mint is when the Linux kernel is updated. I understand why.

I responded "This is not true" to a sibling comment about this same topic, but about "shared libraries", which is the opposite problem (multiple programs could load the same shared library and try to interact).

This is absolutely not true for Linux kernel updating. While you won't be using the new kernel before rebooting, there's 0 risk in not rebooting, because there's exactly 1 version of the kernel running on the machine -- it's loaded into memory when your computer starts.

There's of course rare exceptions, like when a dynamically linked library you just installed depends on a minimum specific version of the Linux kernel you also just installed, but this is extremely rare in Linux land, as backwards compatibility of programs with older kernels is generally a given. "We do not break userspace"

One problem not rebooting with the kernel is drivers. They aren’t all built in.

Most distros leave the current running kernel and boot into the new one next time.

Some, like Arch, overwrite the kernel on an update, so modules can’t be loaded. It is a shock the first time you plug in a USB drive and nothing happens.

Good point, thanks for the insight!