3 ms·

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

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.
- KingMachiavelli 7y ago
  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.
  - Arnavion 7y ago
    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.
mehrdadn 7y ago
Thanks so much for elaborating on this! :)

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.

KingMachiavelli 7y ago
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.
- Arnavion 7y ago
  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.

mehrdadn 7y ago

Thanks so much for elaborating on this! :)