I suspect many OSes ask you to reboot only because that is a good way to ensure the new versions actually get loaded. What's the point of updating the system with a bug or security fix if you still keep running the old, vulnerable or broken binaries?

In all likelihood these occasions where Ubuntu suggests you to reboot only happen whenever there's a kernel update. Next time take a look at what packages are being updated and I bet a couple of them will be named "linux-image-something-something". Regular updates don't require any reboot at all.

I'm sure they are only the kernel related ones, yet those types are quite frequent on my system (once a week or so?? version 14.04.LTS)

Hmmm not sure ensurance is required. Consider if Glibc was updated, a new library is made, then the link is updated, then all programs using the old library still run fine (active as of that moment) but new processes get the new library. As long as the API is working there's no reason to require a reboot, unless some function really really really needed a fix.

Other non-base OS programs can be updated at any time, probably similarly. The only reason to require a reboot is a kernel update, or the running software (server?) is incompatible with a previous version. API differences, configuration differences, or hooks for address locations that changed and the whole thing needs to be replaced at once.

Windows 10 rebooted my computer without asking while playing a competitive multiplayer game. So clearly it's worse than ever before. (there is a setting, btw, to disable its rebootyfulness)

I use the "check for updates, but let me choose whether to install them" option. This way, I can decide which ones, and when to allow my Windows to update. This prevents it from screwing anything else I might be using the computer for...gaming, working, surfing ect.

The clever way would be to automatically restart the services that are using an updated library. With no need for user input at all, and of course absolutely no need to restart the whole system.

That’s exactly what my Debian does thanks to needrestart. It prompts for a reboot (but does not enforce it in any way) only if the kernel has been updated.

Just for an example with my server running a Debian Sid, I have a dozen of daily updates, and still it has not been rebooted last month (and did not need it). There’s absolutely zero service on it using an outdated library.

What really irks me is: iTunes *update* requires a reboot. Really iTunes? A reboot?

Two main reasons really. One is that it is important when security updates are installed that all applications affected by them end up using the security updates immediately. This is a problem because applications are already running on a running system, so if the libraries that an application uses get updated on-disk, the in-memory copy the app is actively using already will be the old insecure version. Whether they are desktop apps, background apps or system level apps they all need to be restarted cleanly in order to switch to using the new libraries and possibly other system files that just got security updates. Otherwise the system or the applications running may still be in a vulnerable state even though the updates are installed. The easiest way to ensure this happens is to require a reboot. From a technical perspective, the reboot may not be absolutely necessary if the person running the computer knew exactly which running applications needed restarting and had the knowledge and skill to restart them all. Since that's generally not going to be the case with the average computer user, and it wouldn't work for all updates anyway - again the easy solution is to require a reboot to ensure all apps are restarted and using the new code. In some cases this reboot is not strictly necessary as such but may be forced by Microsoft as the simplest way to guarantee updates are applied.

The second reason is more mandatory though and has to do with how file locking is done in Windows. One of the lead developers of the Samba project, Jeremy Allison once wrote a nice whitepaper on the complexity of reliable file locking in cross platform software development and how insane it was. Essentially, unlike a system like Linux where files are not locked by default when opened, apparently Windows APIs do lock files by default when opened even if the program doesn't particularly need them locked, and it is up to the app developer to tell Windows to not lock the files. This is the opposite of how it is in Linux and UNIX systems. As a result, most programmers tend to use the defaults which results in files being opened and locked making them unable to be replaced while they are being used. It is basically a poor design decision made by Microsoft a long time ago which can not be changed now without breaking tonnes of programs that now rely on that default behaviour that do need file locking. Since open files can't be replaced while open, the files need to be closed, and that often means the applications that open those files must be closed too. Security updates often affect critical operating system components that can't be shut down on the running system without causing a cascade of problems to other running programs and so the only safe way to replace open files without causing system instability or other problems is to schedule the files to be updated at shutdown or reboot, then reboot the system and let the files get updated and the system come back up.

Windows will most likely always have this limitation because fixing it now would mean breaking programming assumptions that go back 2 decades or more in Windows and wreaking havoc on software compatibility.

It's really too bad Microsoft designed it this way as it causes users no end of annoying problems, like being unable to move, delete or rename a file that is currently in use. In Linux you can move, delete, rename files and directories whenever with pretty much complete free reign whether they are in use or not and everything just works exactly like one would want it too.

So in a nutshell, Windows updates will always need to reboot so long as they affect files that may be open and require system shutdown to resolve, or to which there is no reliable way to install the update while the system is running without creating a problem or a potential problem. Some updates don't hit this issue of course and don't require a reboot but such updates are rare cases in Windows for sure. :)

Turn off auto-updates and do it yourself manually at your own discretion. I've never had that feature turned on. I check for updates at least once a week, and have never run into any issues (and feel it saves memory not having such features turned on.) Also, it's really not unreasonable for the system to need a restart once critical files are updated.

I was going to ask about that, as Windows 10 also suddenly rebooted for me without asking (or if it had had some system tray balloon stating this, I had missed it). I first thought Windows crashed "gracefully" or something (shutting down, not just crashing), but it became apparent it was related to Windows 10 updates.

One good thing though was that it apparently waited until a download was finished. I was just downloading something from the internets, and right after that finished, Windows 10 shut down and rebooted itself.

I'd wish it would ask me, though. Maybe there is some setting somewhere...

There is a setting. It's under the "Security & Updates" settings.

P.S. Unfortunately, there's no way to change when it downloads on a wired connection. The downloads are set to full-bandwidth-sucking.
If you have a wireless connection, you can make it a "metered" connection and then it will ask you if you want to download.

On Win10 Pro, you have the option of automatic installations or "Notify to schedule restart". It's under the advanced options of "Check for Updates", but it should work on both wired and wireless connections, without the need for a metered one. Not sure if Win10 Home also has that setting though.

That's the install. The download happens whenever it wants.