Hacker News Reader

Comment by KingMachiavelli | Hacker News Reader

In addition to taking hours, the Windows update is terrible opaque. Between the 'old' update & new update interfaces, the time spent 'looking for updates' can range from a minute to over an hour which means it's obviously doing more than just querying a server for available updates. During the 'installing' updates phase, the percent complete will stall & jump at random intervals without any indication of why it suddently went from 15% done to 25% done.

And at the end of this long and ardouous process, you only have an updated OS and still have to manually (or use a tool like Chocolatey) update your non-MS software.

It baffles me that this as considered acceptable considering these issues are still present even in domain environments with local WSUS servers.

View on HN

I'm not entirely sure about this (someone please correct me if I'm wrong), but it seems to me that on Windows the problem is fundamentally harder than on Linux. On Windows, you can (or at least could on Windows 7, where this time spent was particularly awful -- though I think you can still uninstall individual updates) pick and choose which updates you install (and uninstall). The sheer number of combinations of updates installed is exponentially more than anybody can test, yet that flexibility is given to you. On Linux you don't seem to have this kind of flexibility as far as I can tell. Now, precisely what computation has to occur that's so much more work in Windows than on Linux is unclear to me, but it does seem like Windows has to solve a fundamentally harder problem.

All the Linux package managers I've used (admittedly, not that many) allow you to choose which updates to install. It's only dependencies that should be upgraded together, I suppose.

But dependencies is exactly what I mean though. You can randomly uninstall an update to a common dependency on Windows. While keeping a later update that patches the same libraries installed. (!) I don't really get how they handle it (probably SxS magic), but somehow they do, whereas on Linux you can't do this.

Distributions based around static-linking rather than dynamic would allow doing this though, correct?

Or NixOS and Guix that allow you incredibly fine-grained control through configuration? (Pinning multiple versions down to particular hashes.)

Ah, right, that makes sense.

> On Linux you don't seem to have this kind of flexibility as far as I can tell.

I don't think that's true at all. I choose when my kernel gets updated, and which dkms modules I want to update (as some of them are a bit... bleeding edge). I choose which of my apps needs an update.

I can choose just security, or even 'just do this particular security update for this particular program'.

To clarify what dataflow is talking about, two Windows hotfix updates to the same component can be installed indepedently, or one can be installed and the other not.

This ability does not exist in Linux package managers since they deal with packages - there is only one newer package to install, and installing that new package replaces the entire existing package. Hotfixes work by applying patches to the affected components' files, which is why they can be independent of other hotfixes applied to the same components.

Hotfixes are also grouped into larger updates, the largest of which is a service pack. (You released N hotfixes over the last month and expect everyone to apply them in the future. There's no point making every user in the future download N updates where one batched up one would suffice.) So when Windows Update has to answer the question "Is this new update required or is it already installed via a previous update?" it has to do a bit of gymnastics to figure out the answer.

So both approaches have their pros and cons. The hotfix method means you can get targeted fixes with no feature updates and smaller chance of regressions, at the cost of being more complex to solve than "if server's version > installed version, download and overwrite".

For example, consider that users of component Foo discover that it crashes when it tries to access the internet with BarCorp FireWall 2019 installed. There might be a hotfix released that fixes Foo to not crash.

Since it only affects Foo users that are also BFW users, it might happen that the hotfix happens to break Foo users who have QuuxCorp Internet Optimizer installed instead. The testing might not have caught it since the primary purpose of the testing was to ensure that the issue is fixed for BFW users, with minimal sanity testing that it doesn't break non-BFW users.

So QIO users can mitigate themselves by uninstalling the hotfix. They didn't need it anyway. Eventually another hotfix may be released that supersedes the first one and is tested for both BFW and QIO, and this latter hotfix will eventually be bundled up into a general Foo update.

All this happens independently of another Foo hotfix released after the BFW one, to fix the issue where it crashes when you open a .txt that's actually a .bmp.

The equivalent with Linux packages would be to have .1, .2, .3 package releases, but QIO users can't can't keep the changes in .3 and remove the changes in .2.

Some distros allow give you some flexability. RHEL as AppStream which allows you to pin particular sotfware to a specific version while upgrading the rest of the system.

The equivilent of Windows SxS would be like running everything in it's own docker container. Assuming each one was updated concurrently & they used a shared package cache this could still be quite fast compared to Windows.

Even accounting for Window's 'impressive' ability to let you install any combination of updates/hotfixes. It's basic software engineering that the common case should be fast and considering that in 99.99% of Windows instances are going to have all of the updates installed, it's very apparent that the Windows update system & SxS were pooly designed and is an major area at Microsoft suffering from brain drain. I feel the most likely case is that no one currently at Microsoft (and still working as a programmer as many of the old talent are either retired or upper executives) understands it enough to fix the issue.

AppStream still replaces entire packages. It does not work like the hotfixes that I described.

WinSxS is not about hotfixes either, but for having different versions of components simultaneously installed.

Neither of these are relevant to the point of this subthread.

Thanks so much for elaborating on this! :)

Reply on news.ycombinator.com