Microsoft is starting to open Windows Update up to any third-party app

Historical context: why Windows is “late” here

• Several commenters note Windows has lacked a clean, unified install/update/uninstall story compared to what users perceive on macOS or Linux.
• Others push back: Windows has had Windows Installer (MSI) for ~25 years and MSIX for over a decade, plus the Microsoft Store with automatic updates; the problem is complexity, poor tooling, and inconsistent adoption.
• DOS and early Windows culture (“anything goes” directories, vendor‑supplied installers, no enforced conventions) made retrofitting a strict package framework hard, especially under strong backward‑compatibility guarantees.
• Corporate environments often rely on MSI + Group Policy or custom packaging; some say this mostly works, others still find themselves repackaging apps.

*Comparisons to macOS, Linux, and BSD

• macOS: perceived as simpler (drag‑and‑drop apps, consistent installers, Sparkle auto‑updater), though others point out many apps still ship custom installers, background updaters, and lack proper uninstallers.
• Linux/*BSD: praised for unified package managers (apt, dnf, pacman, ports) and repo-based updates; some call this “unparalleled”.
• Critiques of Linux: no clear separation of “core OS” vs add‑ons (everything is just packages in /usr), easy to break systems by removing the wrong thing, and hard to revert to a pristine baseline.
• Some note protections like “protected packages” in rpm/dnf and argue what is “core” varies per user.

Existing Windows package/update tools

• Microsoft Store provides auto-updated apps but historically came with capability and policy limitations; more recently supports classic Win32/MSIX with minimal sandboxing.
• WinGet is seen as very late, still CLI‑centric, and weaker than Linux package managers; others are happy with it and note it can use multiple sources, including the Store.
• Third‑party tools:
  • Scoop, Chocolatey: provide more uniform install locations and behaviors.
  • UniGetUI: frequently recommended GUI front‑end for WinGet/Scoop/Chocolatey and other managers; praised but flagged as a single‑maintainer risk.
• MSIX is highlighted as technically strong (delta updates, background updates, clean uninstall, AppContainer sandboxing, admin‑less installs), but tooling is awkward and Windows 10 bugs make direct use painful without intermediaries.

Pros and cons of routing third‑party updates through Windows Update

• Enthusiasm:
  • Users are tired of each app running its own updater service and welcome a central, pausable, policy‑driven system.
  • Could make auto‑updating safer and more consistent for non‑technical users; enterprises can still stage updates via domain tooling.
• Concerns:
  • Windows Update’s reputation for slowness, fragility, and surprise reboots makes some wary of it becoming a “single point of failure”.
  • Fear of dark patterns or forced feature/monetization updates (e.g., turning perpetual licenses into subscriptions).
  • Skepticism that Microsoft will adequately test or roll back third‑party updates; comparisons to CrowdStrike‑style failures arise, with no clear consensus that this approach mitigates them.
  • Some users prefer minimal OS involvement, disabling Windows Update entirely because “update” has become synonymous with disruption.

Security, platform strategy, and lock‑down debates

• Some argue Microsoft should emulate Apple: first‑party hardware, locked‑down app distribution, mandated TPM/Secure Boot to improve security.
• Others counter:
  • Windows’ appeal is partly its openness; Apple‑style lock‑down would face market and antitrust resistance and upset OEM partners.
  • Microsoft is now “services‑first”; tight vertical integration may not fit its business incentives.
• Secure Boot and TPM requirements (Windows 11) are cited as partial attempts at lock‑down that already triggered strong backlash.
• Several commenters express broad distrust of Microsoft’s motives, suspecting more control and telemetry over installed software rather than pure user benefit.