5 ms·

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 r

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.

mehrdadn 7y ago
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.
- Vinnl 7y ago
  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.
  - mehrdadn 7y ago
    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.
    - shakna 7y ago
      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.)
    - Vinnl 7y ago
      Ah, right, that makes sense.
- shakna 7y ago
  > 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'.
- Arnavion 7y ago
  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".
  - Arnavion 7y ago
    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.
    - 7y ago

mehrdadn 7y ago

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.

Vinnl 7y ago
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.
- mehrdadn 7y ago
  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.
  - shakna 7y ago
    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.)
  - Vinnl 7y ago
    Ah, right, that makes sense.
shakna 7y ago
> 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'.
Arnavion 7y ago
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".
- Arnavion 7y ago
  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.
  - 7y ago