I used to always think like that and try to come up with these excuses.

Until I read the story about how Steve Jobs was mad about the fact that Mac was slow to start and asked teams to fix it. Surprise, they fixed it.

And it's not like nobody could say anything at Microsoft. Someone on HN posted this email (originally from a different website):

https://www.techemails.com/p/bill-gates-tries-to-install-mov...

However, my guess is that this email got nowhere, because the experience of using Windows isn't so different decades later.

What this means is that 1) Microsoft is first and foremost a business oriented company, and what matters to them most is feature set, compatibility, support etc. As long as things mostly work, it's fine. Usability is at the bottom of the list. 2) Windows is just not important to Microsoft any more.

I bet that Satya Nadella has grumbles about bugs and ads in Windows 11, and likely has run into this specific bug first hand. But when he decides that "ads revenue trumps everything" and "these are just small bugs that don't really matter", he immediately forgets about it all.

I've been supporting MS as a career for 30+ years, so trust me, I understand that.. and it's a common excuse. But I don't accept it.

New priorities get funding and promotions, so everyone abandons unglamorous but critical work.

Conway's law would say so.

That's actually a key point to make. To generalize, people don't install operating systems. They buy a device with some sort of operating system on it.

Well, as it happened, when I was part of a company that released software, we prioritized high-visibility bugs that users complained about often.

This is a high-visibility bug that users complain about often.

Full-disk encryption, as useful as it is, also makes this a royal pain. Updates can't be performed unattended, because each restart done during the updates requires providing the password before continuing.

You can set grub to select the lastly selected menu entry.

This is why I love OpenSUSE, when you update your system it will let you know when updated files that certain processes are using were touched and you can then decide if you want to restart them.

Suse systems in general are just so much nicer to administer than RedHat or Debian/Ubuntu ones (imo of course).

KDE sometimes borks after big Qt or KDE updates. I just logout and login.

This what it said on the tin since forever for Linux systems, and it doesn't hurt.

There is no such partial or mixed exe problem from paging.

It doesn't matter if it was paged out, virtual memory is still just memory.

Paging out & restoring some memory doesn't know or care where the contents originally came from. It doesn't have an optimization that goes "Oh this chunk of memory is an executable file. I can skip writing this out to the swap file, and later when I need to restore it I can just read the original file instead of swap."

For files that a program opens, an open handle is an open handle. The entire file is available in whatever state it was at the time the handle was opened, modulo whatever changes this specific handle has made.

If a program closes and re-opens handles, then it always knew that the entire world could have changed between those 2 opens. Same if it opens non-exclusive. If it opens without exclusive or closes & reopens, then it's ok for the data to change between each access.

There are problems during updates, but they are much higher level and safer than that. Open file handles are open file handles, and currenly loaded exes are consistent and sane until they close. All the problems are in the higher level domains of processes interacting with each other.

> So you need to hot patch the running binaries. I don't really remember why it's not done in practice even though it's technically possible, I seem to remember the conclusion was that clustering (in whatever form) was the solution for high availability, rather than trying to keep a single machine running.

Most systems are technically capable of hot patching (if your exe file is mmaped, and you change the backing file, Bob's your uncle, unless your OS is no fun; which is why unix install pattern is unlink and replace rather than in-place updares). But most executables are not built to be hot patched, especially not without coordination.

Hot patching lets you make changes to your live environment with tremendous speed, but it also has risk of changing your live environment to an offline environment with tremendous speed. I'm a proponent of hot patching, and would love to be able to hot load all the things, but it has requirements and tradeoffs and most software isn't built for it, and that's probably the right decision for most things.

> Windows locks files when they're in use, so that you cannot overwrite them. Linux doesn't do this.

Linux does do this (try overwriting or truncating a binary executable while it's running and you'll get -ETXTBSY).

The difference is that Linux allows you to delete (unlink) a running executable. This will not free the on-disk space occupied by that executable (so anything you write to disk in the immediate future will not overwrite the executable, and it can continue executing even if not all of the executable has been paged in) until all references to its inode are freed (e.g. the program exits and there are no other hardlinks to it).

Then you can install a new version of the executable with the same name (since a file by that name no longer exists). This is what install(1) does.

MOVEFILE_DELAY_UNTIL_REBOOT is sort of the real trick, because it's processed by the Windows equivalent of PID 0 (ssms), which processes these pending operations before actually starting any other userspace stuff (which would invariably load things like kernel32.dll etc.)

Windows NT was always capable of what Microsoft calls “POSIX delete semantics” (the POSIX compatibility layer was in the design doc since before the name change from “NT OS/2”), but some years ago the default for the Win32 call DeleteFile actually changed to take advantage of that (causing some breakage in applications, but apparently not a lot of it).