3 ms·

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 migh

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.

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.