微软希望Windows Update能够管理所有应用程序

176 条评论 | |

微软正逐步向任何需要更新的第三方应用程序开放Windows更新功能。这家软件巨头现已允许开发者注册参与其所谓的“Windows更新协调平台”的私人预览版，该平台将使Windows更新未来能够支持任何应用程序或驱动程序的更新。该平台主要针对企业应用程序，但也将向任何应用程序或管理工具开放。

目前，Windows 更新主要用于更新 Windows 的核心组件，以及设备的关键驱动程序，甚至安装一些第三方管理应用程序用于外设。微软产品经理安吉·陈（Angie Chen）解释道：“我们正在构建一个统一的、智能的更新协调平台，该平台能够支持任何更新（应用程序、驱动程序等）与 Windows 更新协同进行。”

目前，Windows 上的大多数应用程序都是独立更新的，使用开发者自行创建的更新机制。微软的新 Windows 更新协调平台将允许应用程序开发者利用基于用户活动、电池状态甚至可持续能源时机的计划更新。元素周期表

开发者还将能够直接接入原生 Windows 更新通知，并在 Windows 更新的应用程序更新历史记录部分中列出。微软将支持 MSIX/APPX 打包应用程序，甚至一些自定义 Win32 应用程序。任何参与Windows更新协调器的应用程序都将自动获得底层Windows更新平台的未来改进。

微软过去曾试图说服开发者将应用程序列在微软商店中，由商店处理更新，或开发者继续使用自己的更新机制。尽管Windows上的商店在近年来有了很大改进，但仍有一些应用程序缺失，且企业更倾向于独立更新自己的业务应用程序。

微软的 Windows 包管理器也曾试图解决 Windows 系统中应用程序安装和更新的相关问题，但目前该工具主要被高级用户和开发者使用，尚未成为广泛采用的应用程序安装与管理方式。

将更多应用更新整合到Windows更新中对各类应用而言确实有意义，值得关注的是，此举是否主要被企业采用，还是像Adobe这样的大型开发者会转而使用Windows更新系统，而非继续使用后台运行的独立安装程序。

你也许感兴趣的：

共有 176 条讨论

  1. Windows 系统中仍存在一种情况：Chrome 的更新会使用一个特殊服务来绕过权限提升问题，而 Spotify 以及许多其他应用程序也会出于相同原因将文件安装在 AppData 目录中。此外，许多卸载程序无法正常工作，导致文件和其他内容残留系统中。MSI 要求使用旧密钥进行“链式签名”以永久签名新密钥，但当维护更新超过十年时，这并不容易实现。希望他们能彻底清理这些问题！

    回复

    1. 它们安装在AppData目录中是为了绕过IT管理员的阻碍。除非系统管理员具备仅基于白名单进行操作的技术条件（而并非所有人都具备——这非常昂贵），否则可以肯定至少部分用户会非法安装Spotify等应用。

      这就是为什么IT各层级与用户之间建立良好的合作关系至关重要。客户服务应放在首位，技术其次。如果用户信任你作为IT管理员，他们会在下载此类AppData安装程序前先咨询你，以免引发严重问题。

      回复

    2. 供参考，Chrome使用开源的Omaha安装程序和更新，而其他提到的程序使用Squirrel。两者都可能存在于用户的AppData中（但Squirrel是唯一一个可以这样做的，因为其设计理念是允许用户在无需管理员权限的情况下自行安装）。

      回复

      1. 你确定其他应用程序使用Squirrel吗？在维护者决定放弃多个库（包括Squirrel）后，我以为它已经被放弃了？

        回复

        1. Squirrel已经放弃多年，但仍然被使用，通常是那些不知道它已经被放弃的人。如果你使用Electron工具链，它就是默认选择，这就是原因。它还存在严重的设计问题，比如它会破坏Windows网络，因为它会用数十个独立的Chrome副本填充用户的漫游主目录，这些副本随后会被备份、在登录时复制等。管理员讨厌它，因为这种设计的目的就是绕过他们管理部署的能力，尽管当事情出错时，他们仍然会受到责备，当然。

          有一种更好的方法，我在此帖子中毫不掩饰地自我推广（因为这完全符合主题）——我的公司开发了一款工具，可以分发自我更新的 Electron 应用程序，而且它不仅没有被放弃，还拥有许多非常有用的功能，例如能够从 Linux CI 工作者构建并上传签名的更新包（使用微软在此处推广的技术），而无需 Windows 许可证。

          https://hydraulic.dev/

          它还支持在启动时强制更新，这对客户端与服务器协议经常变更的应用程序非常有用。并且它与企业Windows部署兼容。用户可以本地安装应用程序而无需管理员权限，但应用程序会安装到c:Program Files

          回复

          1. 这很棒，但请记住，AppData 目录中的安装很可能是功能设计而非漏洞。

            换个角度思考：如果应用程序安装在 AppData 目录中，它们可能绕过 IT 部门和其他企业官僚机构，在组织内部获得立足点。这在技术和商业实践上都绝对是恶意的，但它确实有效。

            回复

            1. 这可能在很久以前是正确的，但如今Windows通过AppLocker等工具，可以轻松对用户主目录中的可执行文件进行黑白名单管理。同时，MSIX子系统允许用户在无需管理员权限的情况下，安全地将应用程序安装到c:Program Files目录外。

              因此，Electron 曾经可能是一个不错的增长黑客策略，但现在它遇到障碍的可能性与否（至少在任何现代 Windows 网络中，IT 部门处于活跃状态的情况下）是相当的。

              回复

      2. 它曾经使用 Omaha。他们最近重写了它，Chrome 现在使用一个完全在其自有代码库中维护的安装程序框架。它在概念上类似，但经过了清理。

        回复

        1. 由于 Chrome 分支 Edge 现已成为 Windows 系统的一部分，该更新程序已可在所有 Windows 机器上运行（例如 MicrosoftEdgeUpdateTaskMachineUA 计划任务）。

          他们甚至没有使用 Windows 更新进行该操作。

          回复

          1. 能否强制 Edge 通过 Windows 更新进行更新？他们有用于下载的组策略对象（GPOs），但我并未在其中看到类似设置。

            回复

    3. 对于残留文件的问题，从安装程序的角度来看，对于那些拥有根/管理员权限的非容器化应用程序，这难道不是一个难以解决的问题吗？

      因为它们可以随时创建并写入任意目录。而任何卸载程序（无论是应用程序提供的还是微软提供的）都可能遗漏这些文件，因为它们并未重建完整的程序控制流程。

      回复

      1. 这就是我们发明发行版（Linux及其衍生系统）的原因：统一的包管理器、共同的实践规范和共享代码，以避免每个人都做自己的（有时是错误的）事情。

        回复

        1. 现在我们还拥有Flatpak、Snap等技术，基于“统一包管理器”架构。

          回复

      2. 为什么在安装过程中无法追踪它们的写入位置？甚至有应用程序可以做到这一点。对于以管理员身份运行的应用程序，确实更难实现，但至少在安装过程中，这种设计虽然不完美，但仍然可以添加？

        回复

      3. 是的。UWP/MSIX+AppContainer 解决了这个问题，但本质上对应用程序和安装程序的功能施加了限制。

        回复

    4. 它们不会安装到AppData目录以规避权限提升。它们并非在隐藏。微软已建议将应用程序安装到AppData目录近十年之久。或许现在已超过十年。这是当前安装应用程序的标准方式，只要这些应用程序无需提升权限即可运行。

      回复

      1. 关于应用程序的多用户共享呢？我以为这是主要优势（至少应用程序安装程序一直强调这是区别所在）

        回复

        1. 那又怎样？你必须将应用程序安装到非用户目录，才能让多个用户使用该应用程序。

          回复

    5. 公平地说，许多GNU/Linux包也会留下垃圾文件。

      回复

      1. 你期望包清单中未包含的文件会被包卸载工具清理吗？

        这让我感到惊讶，我以为用户会认为包卸载只意味着卸载包本身。

        回复

        1. 是的，如果安装时有脚本生成文件，卸载时也应有脚本删除这些文件。

          大多数情况下并没有这样的脚本。

          回复

          1. 这并非人们在包卸载时通常的预期，至少从我的理解来看是这样。

            在卸载时，如何划分配置文件、用户创建的文档、网络共享目录中的配置文件等界限？

            我认为你并非不合理，也许我们需要根据用户需求提供更好的清理方案。

            这意味着需要追踪文件的创建者并进行适当标记，并在卸载时使用此列表。

            回复

  2. 我一直好奇为什么Windows从未像MacOS从一开始就拥有统一的安装、更新和卸载框架。这似乎是一个显而易见的缺失，却从未得到解决。

    即使现在，企业客户仍需自行打包软件以管理其应用程序集群。

    我的猜测是，微软从一开始就鼓励应用程序共享 DLL，为了保持向后兼容性，微软从未强制要求使用 MSI 或成熟的软件管理框架。

    回复

    1. Mac OS 从一开始就没有这样的框架。当然，许多应用程序可以通过将文件拖放到应用程序文件夹来安装。然而，许多应用程序需要运行安装程序，这些安装程序通常需要管理员权限来安装系统范围的支持文件。其中一些应用程序有自己的更新程序，设置为在启动时运行。过去，许多应用程序会将扩展和控制面板安装到系统文件夹中，这需要重新启动。

      最后，这些应用程序中许多都没有卸载程序。你必须在系统中四处寻找以删除它们安装的所有内容，包括首选项文件和缓存文件，以防万一你以后想重新安装而不会遇到问题。

      回复

      1. 这迫使人们使用诸如https://freemacsoft.net/appcleaner/（无任何关联）

        回复

      2. 这样的程序。从一开始就应该只支持拖放操作。我乐意切换到一个干净且一致的Linux/BSD发行版。

        回复

        1. 大多数Linux发行版不这样做，这对我来说是一个巨大的卖点。在早期Linux时代，软件分发是一场噩梦，但如今主流发行版的包管理体验无与伦比。我更喜欢使用终端管理包，而不是一些笨重的图形界面，而且我无需离开终端即可发现新包或移除旧包。

          回复

          1. 根据我的经验，Linux发行版包管理体验的主要弱点在于它们未能区分核心系统功能与附加软件。毕竟，Linux发行版本质上就是一堆软件包的集合。每个软件包都会安装到全局的`/usr`目录中，而包管理器对第三方软件包和系统软件包一视同仁。这相当于在Windows系统中，所有软件都安装到Windows文件夹中，或者你可以通过“添加/删除程序”卸载ntoskrnl。这会导致多个问题：

            1. 系统意外损坏的情况时有发生。用户因依赖项规范或依赖项解决程序存在缺陷而意外卸载桌面环境的案例屡见不鲜。难道不应该建立一个核心系统包和文件的白名单，确保在常规包交易过程中这些关键组件绝不能被修改或删除吗？大约一年前，Fedora 还出现过一个 bug，由于 Google Chrome RPM 的 GPG 签名密钥存在问题，导致系统更新受阻，除非手动覆盖包管理器交易以跳过损坏的包。想象一下，如果 Chrome 导致 Windows 更新失败，或者一个配置错误的 Homebrew 包阻塞了 MacOS 更新。

            2. 随着时间推移，系统容易积累冗余文件，因为系统默认不会跟踪我添加的软件与基础系统之间的差异。我可以手动在文本文件中维护列表，但列表中包的依赖关系如何处理？包卸载后在`/etc`目录中留下的配置文件又该如何处理？我希望有一种简单的方法，可以将系统恢复到出厂状态，而无需仔细检查 `dpkg -l` 的每一行（可能有数百或数千行）。在 MacOS 上使用 Homebrew，我只需删除 `/opt/homebrew` 目录即可。

            回复

            1. > 很容易不小心破坏系统

              rpm/yum/dnf 实际上为此提供了一个名为“受保护包”的机制，这些包无法在调用方未执行特定操作的情况下被卸载。发行版会谨慎使用此功能，仅在可能导致系统损坏的场景下启用。有时你需要卸载桌面环境（DE）。

              回复

            2. 对你而言的核心组件可能是他人的附加组件。

              回复

          2. AppImages仍然相当常见，而它们几乎在乞求一个拖放界面

            回复

          3. 公平。但类似的功能可以通过一个终端友好的打包系统实现——一个目录，一个位置，用于所有与应用程序相关的内容。我更看重的是每个应用程序的明确位置，而不是拖放功能。

            回复

        2. 如果安装过程中需要回答一些会改变安装方向的设置问题呢？例如，某些安装会提供可选择放弃的功能以节省空间。

          回复

          1. 好问题。这将是一个难以解决的问题。

            回复

        3. Fedora-Gnome 拥有一个相当不错的软件目录，支持一键安装和集中管理更新。我肯定有几件事是因为不想麻烦通过 dnf 安装而没有做，但这是我的日常使用系统，没有问题。

          回复

    2. 微软的第一款流行操作系统是 MS-DOS，因此早期版本的 Windows 在第三方软件方面基本上就像 DOS 一样：

      – 除了供应商提供的 INSTALL.COM 或 INSTALL.EXE 之外，没有安装程序的概念。

      – 安装程序通常只是将文件复制到一个新的根目录子目录中，该子目录可在安装程序中选择（如果存在的话）。有时你不得不自己创建子目录并手动复制所有文件。

      – 应用程序的所有操作都在该子目录中进行，包括运行可执行文件、读取数据、写入数据，以及经常保存文档。这与UNIX传统中将可执行文件放在/bin目录，读写数据放在/etc或/var目录，并设置适当权限的做法大不相同。

      其他有趣的内容：

      – 除了IO.SYS和MS-DOS.SYS这两个文件必须位于磁盘的第一个和第二个“inode”（以便引导加载程序能找到它们），以及CONFIG.SYS和AUTOEXEC.BAT必须位于根目录下的某个位置外，MS-DOS内核对其他文件的位置完全不关心。即使COMMAND.COM也可以放在任何位置——你只需通过CONFIG.SYS中的COMSPEC=设置告知MS-DOS其位置。因此所有DOS外部命令都可以放在任何位置（只要AUTOEXEC.BAT中包含PATH命令即可访问），尽管我认为MS-DOS安装程序通常会将它们放在DOS或MSDOS目录下，这可能已成为事实上的标准。

      因此……DOS，作为Windows的前身——它是一个无拘无束的环境。

      当Windows开始流行（3.x版本是其起飞的版本）时，上述方式通常是用户在MS-DOS环境下使用程序的方式。这就是为什么程序倾向于将所有内容都放在其“C:Program Files”文件夹中。

      我不确定微软何时开发了复杂且过度设计的.MSI系统，但它在1993年Windows NT发布时并不存在，我认为在Windows 95发布时它甚至还不存在。即使微软在Windows NT/95首次发布时就正确实现了.MSI系统，仍存在大量现有程序未采用该系统且短期内不会采用。因此微软不得不继续支持DOS时代遗留的混乱局面和使用习惯。

      回复

      1. C:Program Files 是 Windows 95 的东西，Windows 3.x 时代还没有 VFAT，甚至不支持显示长文件名。我不记得在 Win 3.1 中程序会被放在哪里……

        我记得那些全屏的 setup.exe 程序，背景是蓝色的……

        回复

        1. 我记得在我的老 DOS/Win3.11 机器上，我通过只将“小型”应用程序安装到 C:BIN，而将大型程序安装到 C:APPS 来保持一些秩序。我希望尽可能少地使用顶级文件夹。有时需要花些功夫，但否则就会一片混乱。

          每次看到别人把所有程序都安装在顶级文件夹，或者有时安装在C:WINDOWS或其他随机位置时，我都会感到不适。

          如果今天让我重新来过，我会采取不同的做法：将专门用于对计算机本身进行操作的程序安装在C:UTILS，其他所有程序安装在C:APPS。

          回复

        2. 如果我以后要制作Windows安装程序，我会手动添加那个全屏蓝色背景，以怀念过去。

          回复

      2. 而且，除了微软之外，其他人其实也没有安装程序。

        回复

    3. 专业的软件供应商通常会通过组策略对象（GPOs）提供MSI包用于企业部署。我记得过去十年左右的时间里，我从未需要自己打包过任何东西。可能需要阅读一些文档来调整安装参数。

      但我同意，这本可以做得更好。

      回复

      1. 此外，WinGet直到新冠疫情高峰期才真正被人们发现其存在。目前仍有大量软件在其中无法正确安装。

        回复

    4. 这是一个极其复杂的问题，考虑到驱动程序、系统扩展、共享库版本等问题，而且在无法依赖互联网连接的情况下，解决起来更加困难。

      然后，一旦你构建了它，你需要说服软件供应商使用你的安装机制，并希望他们相信高管不会将此作为未来索取租金的筹码。

      回复

    5. > 我一直好奇为什么Windows从未像MacOS从一开始就拥有统一的安装、更新和卸载框架。这似乎是一个显而易见的缺失，却从未得到解决。

      当我切换到macOS时，我感到震惊。我无法相信与Windows相比，典型的安装体验有多么出色。只需将下载的文件拖放到一个文件夹中。无需运行一些定制的安装向导。即使应用程序需要运行某些内容进行安装，它几乎总是相同的（可能是系统提供的）安装流程。

      回复

      1. 我第一次遇到如此简单的设计是在Acorn Archimedes（RiscOS）上：一个“应用程序”是一个以感叹号开头的文件夹。它可以自定义图标。如果你有硬盘的奢侈，你可以直接将应用程序的副本从分发它的软盘上拖放到硬盘上。

        回复

    6. 它已经有一个名为MSIX的格式超过十年了，请参阅我在此处的另一条评论：

      https://news.ycombinator.com/item?id=44118703

      很少有人使用它，因为Windows上几乎没有新的开发活动，即使是微软本身也是如此。 everyone either uses portable frameworks and inherits the defaults, which aren’t MSIX, or has legacy systems they developed from before MSIX got good.

      回复

    7. 微软的软件环境比Mac的要大得多、复杂得多？因此创建管理它的工具要困难得多？

      回复

    8. 它已经实现了，这被称为微软应用商店。来自该商店的应用程序会由系统自动更新。

      回复

      1. 从这一公告的字里行间可以看出，这似乎是一个计划，旨在将MSIX/APPX和Windows包的机制与应用商店的政策脱钩。

        WinUI3（如果有人愿意使用它，包括微软）已经以这种方式分发其库依赖项，作为商店包。

        回复

        1. >(如果有人愿意使用它，包括微软)

          我认为这是问题的重要部分，在微软提供的应用程序范围内，它们的分发、安装和管理方式各不相同。Office会使用它吗？Visual Studio、Teams以及各种Windows组件呢？如果微软自己承诺使用它，展示它在各种用例中都能正常工作，并且做得很好，那会更有趣。

          回复

          1. Office 始终是 Windows 更新（或在品牌变更的年份中称为 Microsoft 更新）中的特殊案例，无论您是否安装了 Office，这一情况自 Windows 更新的早期阶段便已存在。Windows 更新最初在 Office 97 时代以“Office 更新”的形式出现，随后在 Windows 98 中成为 Windows 的默认组件，据我所记得的情况是这样的。（互联网上似乎没有 Office 97“Office 更新”工具的图片，所以要么是我的记忆模糊，要么是它确实存在时间太短，以至于互联网和维基百科都已忘记它。） 在Windows 8和10中，微软曾尝试将Office更新转移到应用商店，并在Office团队决定对应用商店感到厌倦并回归“家”——Windows更新（或微软更新，如果你坚持的话）——时，这一尝试基本成功。

            如果 Office 不再是 Windows 更新中的特殊案例，更多应用程序可以使用它，那将很有趣。许多第三方驱动程序已经开始更多地使用它，而这在之前也似乎是一个特殊案例。将其作为任何第三方平台开放似乎是迟早的事。

            （Visual Studio 也是一个有趣的案例，因为其中一部分一直通过 Windows 更新进行安全更新，但更多部分并未通过这种方式更新。最初的界限是“由Windows组件拥有”与“由Visual Studio拥有组件”，但这些界限已变得模糊，尤其在.NET 5+时代，Windows不再拥有.NET的任何部分，但Windows更新仍提供关键安全补丁。）

            回复

        2. 多年来，你一直可以将MSIX用于MS Store之外。

          回复

          1. 此外，应用商店的“政策”多年来已大幅放宽，允许普通Win32应用程序以与其他安装方式相同的沙箱级别运行。

            回复

      2. 这是否意味着对软件功能存在限制？

        回复

        1. 近年来并没有。MSIX自更名以来，几乎支持MSI的全部功能（只是通过XML直接指定，而非使用过时的Microsoft JET数据库文件格式，且采用现代ZIP格式替代了过时的Windows CAB存档格式），而经典风格的Win32应用程序的安装沙箱限制与直接安装MSI文件时相同，而非MSIX安装。

          回复

        2. 与 Mac 类似，但限制条件当然不同

          回复

    9. macOS 其实没有。有 App Store，成功程度不一。其他大多数应用则使用 Sparkle 框架，这是一个第三方库。

      我惊讶于像 Sparkle 这样的框架在 Windows 上尚未站稳脚跟。

      回复

      1. 关于 Sparkle——情况相同。Sparkle 几乎是自我更新框架的理想典范；它在该平台上近二十年（！！）一直是无可争议的标准，这绝非偶然。

        回复

        1. 作为用户，我讨厌Sparkle。至少，我讨厌Sparkle的默认模式，你必须点击“安装更新”，然后等待更新下载，然后验证，然后等待更新解压，然后等待应用重新启动。太慢了。当我打开一个应用时，我希望立即使用它。我更希望应用在后台更新；如果不行，至少给我一个按钮，让我在继续使用旧版本应用的同时手动启动后台更新。

          回复

          1. Sparkle 很久以前就提供了这个功能，但默认设置仍然要求你在第一次使用时同意后台更新。开发者可以关闭该设置，让应用在运行时静默更新。

            回复

    10. Windows 缺少许多显而易见的功能。例如，应该有一个简单菜单来控制右键菜单中显示的项目及其顺序。

      回复

      2. 通过阅读微软资深工程师Raymond Chen的《The Old New Thing》博客，我认为原因相当直白：

        用户可能因误操作导致菜单“损坏”且不知如何修复，而从用户角度看，Windows因此“损坏”便是Windows的责任。

        此类问题确实会带来支持负担，而这是一种昂贵的权衡。因此，与其将其作为内置功能，用户需要通过修改注册表或使用第三方程序来实现。

        至少，这是微软在内部提出添加此类功能时会考虑的理由（而此类建议确实存在）

        回复

        1. 看来你对这个话题很了解，所以我来问你另一个显而易见却缺失的功能：为什么从来没有提供过自动展开任务栏以显示打开窗口数量的选项？显然，如果你打开了三个窗口，你需要单行任务栏；如果你打开了十二个窗口，你需要双行任务栏。然而，如果你想使用双行任务栏，你必须手动解锁它，然后手动展开它。

          回复

    11. 真正的创新者是FreeBSD，甚至在Linux之前。

      在90年代中期，FreeBSD用户可以使用FreeBSD管理的代码和工具构建整个操作系统和应用程序。

      后来，像Debian这样的系统在这一点上有所改进，但FreeBSD是第一个。

      回复

      1. 我感觉90年代我使用过的几乎每个发行版都支持ef托管和构建。即使是早期的Red Hat也具备从ARC RPM构建每个包的能力。

        除非我误解了你所说的“构建”是什么意思。

        回复

    12. macOS 拥有图形化的 App Store，但没有通过命令行进行更新的便捷方式。存在第三方项目 mas[1]，但其功能受限于苹果公司不断更新的 API。

      [1] https://github.com/mas-cli/mas

      回复

      1. 命令行作为概念并非用户管理更新工具的必要条件。

        经典的 Macintosh 系统根本没有面向用户的命令行界面。

        回复

    13. Windows 直到 2018 年左右才拥有一个相对稳定的官方包管理系统（WinGet），而该系统直到 COVID 期间才有了控制器 GUI（UniGetGUI），因为有人在家中终于编写了一个。

      回复

    14. 嗯？？？它已经有了25年了：https://en.m.wikipedia.org/wiki/Windows_Installer

      回复

      1. MSI确实有效，但它是一个极其复杂的文件格式，而用于构建MSI安装程序的工具也从未真正出色。因此才有了InstallShield等工具。

        回复

        1. InstallShield比Windows Installer早了大约十年。

          回复

          1. 不过有趣的是，尽管MSI格式出现了，但InstallShield解决的问题并没有太大变化。

            回复

          2. 你说得对，我把MSI和.CAB混淆了，后者是在软盘时代使用的。

            回复

            1. CAB是一种类似ZIP的格式。MSI很有趣，因为它在底层使用CAB文件。但它也是微软JET引擎的数据库格式，是Windows注册表的古老前身，同时也是当时Office Access格式的 contemporaneous/counterpart。

              将MSI与MSIX进行比较非常有趣，因为MSIX使用ZIP/XML而非CAB/奇怪的JET数据库文件。

              回复

  3. 我在所有机器上都禁用了 Windows 10 更新。至少一年没有更新过，一切运行顺畅。微软已经毁了“更新”这个词，把它变成了一个脏词。

    我不明白纳德拉为什么这么讨厌 Windows。

    回复

    1. 我猜想有些人会因为安全问题而拒绝安装Windows更新，感到震惊。

      但对大多数家庭用户来说，这并不是什么大问题。我猜想99%的家庭用户都位于NAT之后，而位于NAT之后意味着外部攻击者无法直接连接到你的机器并执行远程利用（例如EternalBlue）。唯一可能被入侵的方式是感染木马，而这种情况下Windows更新也无法拯救你。顶多意味着木马在提升权限至管理员/系统级时会稍显困难，但木马无需管理员权限即可对你的文档文件夹实施勒索软件攻击或将你的设备加入僵尸网络。

      只要你的浏览器保持最新，就不会有问题。

      回复

      1. 几个月前（可能是一年前）的情况并非如此，当时JavaScript有效负载可以通过攻击局域网中的IP地址加载，从而向数百万物联网设备发送HTTP(S)请求，这些设备随后会获得原始套接字支持。

        攻击默认网关以访问网页管理面板等。

        我找到了Windows更新的解决方案。只需不使用Windows即可。微软不可信。

        回复

        1. 这怎么是Windows的问题？看起来像是浏览器问题，除非我误解了这些JavaScript有效负载的来源。

          回复

      2. 根据我的经验，大多数“不要更新Windows”的讨论都来自于像Windows 98/ME和Linux这样的单一内核系统，其中一次更新可能会改变或破坏大量看似随机的东西。过去25年来，这对于99%的台式电脑来说都不相关（不包括Mac设备）。

        回复

        1. > 其中一次更新可能会改变或破坏大量看似随机的东西

          这一直是微软的问题：测试工作由用户来完成。但在Win 7之前，他们似乎会为某个版本（如2000、XP、7）发布最新的服务包，主要修复漏洞。如今在Win 10和11中，安全更新与新功能捆绑发布，漏洞可能数月得不到修复，甚至永远不会修复。从质量角度看，微软的组织架构已然失效。

          回复

          1. 是的，但混合/微内核架构通过进一步隔离和分区所有组件，仍能提供令人惊讶的防护能力。

            回复

      3. 完全正确。我甚至没有安装杀毒软件，并且完全禁用了Windows Defender，因为它太烦人了，而系统运行得非常顺畅。我使用的是LTSC版本。

        回复

        1. 遗憾的是，这只是个案。我一生中也做过许多冒险的事情，每次都安然无恙。这并不能证明这些行为不冒险，也无法证明我的结果可重复。

          不过，我也讨厌Windows更新，尤其是Windows处理更新的方式。LTSC也是我避免部分更新的方式，尤其是那些所谓的“功能”更新。如果有人能管理激活服务器，或者我可以指向我的服务器，我也会推荐LTSC。

          回复

          1. 有什么风险？我不会下载随机可执行文件并执行它们。自2019年以来，我一直未使用Windows Defender且未出现问题。如果你不玩愚蠢的游戏，就不会得到愚蠢的奖品。

            回复

            1. 数据可能包含恶意软件，如JPEG、PNG或文档文件。浏览器并非完全独立运行，某些功能依赖系统组件，例如视频解码。

              保护你的，我认为，除了你无疑良好的习惯外，是群体免疫。几乎所有其他Windows用户都安装了杀毒软件，因此恶意软件作者不愿利用那些会被杀毒软件检测到的漏洞。微软为所有人提供Defender的政策提高了门槛，基本上就是这样。

              回复

  4. 这有道理，因为所有Linux包管理器都采用相同的方法。不过，Windows Update与其他替代方案（如Chocolatey、Scoop或WinGet）相比，功能过于基础。

    回复

    1. 我感到惭愧的是，我这么晚才得知WinGet的存在。直到我从多年使用Ubuntu作为日常系统回归后，才通过搜索“Windows包管理器”发现了它。

      回复

      1. 别太尴尬，WinGet 才 5 岁，不过是 Scoop 和 Choco 的替代品。

        它只是一个工具，会从微软的中央 GitHub 仓库获取安装清单并执行。和 brew 或 chocolatey 一样。作为第三方“包管理器”还行，但作为官方系统工具感觉有点弱。

        此外，如果我没记错的话，它仅作为命令行工具提供，这使得它对95%的Windows用户以及开发者来说几乎毫无用处。

        这个工具确实有用，但它远非Linux包管理器的替代品。

        回复

        1. > 此外，如果我没记错的话，它仅作为命令行工具提供，这使得它对95%的Windows用户以及开发者分发软件而言几乎毫无用处。

          在我那个年代，这会被视为留给用户自行解决的练习，于是便诞生了一位新晋初级开发者来构建前端界面。

          回复

            1. 它很酷，我经常使用。但请记住，这又是一个一人开源项目，随时可能停止维护。

              如果你有能力在经济上支持他们或以某种方式贡献代码，请这样做。

              回复

              1. 完全跑题了，但我刚看了你的个人简介。你能列出你提到的几个设计博客吗？

                回复

                1. 哈哈，我写这个已经差不多半年前了！我指的是像Dribbble、Deviantart等网站，那时候它们还不需要到处注册账号。

                  开发者通常不是最好的用户体验专家，他们可能会写出优秀的代码，但界面中到处都是菜单和单选按钮，而用户体验专家也不一定是开发者。当时我注意到两者之间存在脱节，所以我想鼓励大家在中间找到平衡点。

                  但，再次强调，那是在新冠疫情封锁前几个月。我认为这条建议仍然适用，但随着科技行业裁员潮的到来，我认为我们的领域最近整体上变得非常迷茫。我们似乎将太多自我认同建立在日常工作中，而当人们被裁员或解雇时，显然失去了这些认同。

                  （我真的应该更新一下2025年的个人简介，现在我已经恢复了定期更新。）

                  回复

            2. 本周我对Command Palette内置的winget UI以及新PowerToy“Sherlock/Spotlight”搜索工具印象深刻。

              回复

        2. > 它只是一个工具，用于从微软中央GitHub仓库获取安装清单并执行。

          Winget 仓库确实包含大量有用的安装清单，但它不仅仅是一个从该仓库获取清单的工具。（此外，它并非直接从 GitHub 获取数据，尽管 GitHub 是数据的权威来源，但中间有一个轻量级的 REST 服务，负责大量缓存和 DDoS 管理等功能。） Winget 默认也会安装 Windows 应用商店应用。它还支持配置，因此你可以添加自己的安装清单仓库（例如本地私有源）。

          回复

        3. scoop、Choco 和 winget 都有很大不同。winget 与 Choco 最为相似，因为它更倾向于直接运行常规安装程序。不过，winget 会保留已安装包的状态，而 Choco 则使用与“添加/删除程序”相同的数据源（msstore/appx 和注册表中的“uninstall”组）。scoop 则完全独立，它会将所有内容安装在自己的前缀下并管理自己的状态。

          回复

          1. >winget 使用与“添加/删除程序”相同的数据源（msstore/appx 和注册表中的“uninstall”组）。

            我发现这种行为非常令人烦恼。我主要使用 Chocolatey，因此偶尔当某个包严重过时或从仓库中缺失时，我会出于方便而改用 Winget。这意味着 Winget 会不断尝试更新或管理 Chocolatey 包，据我所知，目前没有简单的方法来阻止这种行为。

            回复

            1. 关于 Chocolatey，据我所知，其注册表仍主要由社区成员维护。这在网络安全背景下并非最佳选择，且部分企业可能对未经授权分发其安装文件的行为持有许可限制。

              因此，WinGet作为微软拥有和运营的替代方案，这些公司可能会觉得更安心。

              回复

      2. 我更喜欢Scoop而不是WinGet。Scoop将大多数包安装到一个特定文件夹中，并设置了shims/链接。它还具有统一的安装/更新方法。

        WinGet基本上只是下载安装程序并运行它们，无法正确跟踪已安装的应用程序，也无法始终更新它们。

        回复

        1. > 无法正确跟踪已安装的应用程序，也无法始终更新它们。

          为什么？我使用它多年，从未遇到过一次更新所有应用程序的问题。

          回复

          1. 这取决于应用程序本身。

            对于通过 WinGet 安装但自带更新机制的应用程序，情况会变得复杂。如果该自更新机制未正确调整注册表中的相关设置，WinGet 将认为应用程序仍处于初始版本。

            例如，Obsidian 就是这种情况。

            回复

      3. 我为微软在实现WinGet上花费了如此长时间感到尴尬。它仍然有很多不足之处，但我想，如果你习惯了PowerShell，那么奇怪的以句点分隔的驼峰式包名称可能与你当前的日常使用习惯相符。对于来自apt/yum/brew的人来说，即使是最基本的包也必须搜索以确认其名称的语法，这几乎对用户不友好。

        回复

          1. 他们“窃取”（脑残？）了想法和部分实现思路，但代码完全独立。Winget是用非常Windows风格的C++实现的，而appget是C#。

            回复

            1. “脑残”是个糟糕的词汇，你应该停止使用它。

              回复

    2. 而且它似乎运行得相当缓慢。我甚至无法想象它需要更新多达 10 倍的组件，或许数据量也增加 10 倍。

      回复

      1. Windows 更新的缓慢更多是设计特性而非 bug。底层的背景智能传输服务（BITS）依然是一项很酷的技术，尽管自任何网页浏览器允许将低优先级下载任务发送给它，或 RSS 阅读器基于它构建以来，已经过去了很久。（这两者都曾存在且很酷，尤其是在拨号时代，带宽稀缺且连接不稳定。） 它设计上优先处理用户当前需求而非待处理下载，会根据 CPU 活动、带宽使用、下载配额、电池状态、预计运行时间以及现在诸如预计能源混合比例等因素进行自我限速。（当能源更清洁时为何不下载大文件？）它确实会在你不在意时更快下载，这就是它的设计初衷。

        回复

      2. 许多Linux包管理器（如DNF或APT）的关键特性在于，仓库仅是一个静态网站。服务器无需计算机器当前状态与理想状态之间的差异——这一计算在客户端完成。

        当然，这会对包可见性及其他政策实施造成一定限制——你无法轻松将特定用户组限制为仓库的子集。

        回复

  5. 感谢这个帖子引发的思考，我刚刚发现了UniGetUI，这东西真是太酷了。从现在起，我控制的任何Windows系统都会安装这个工具。

    > 该项目的核心目标是为Windows 10和11系统中最常见的命令行包管理器（如WinGet、Scoop、Chocolatey、Pip、Npm、.NET Tool、PowerShell Gallery等）打造直观的图形用户界面（查看包管理器兼容性表格）！借助这款应用，您可以轻松下载、安装、更新和卸载支持的包管理器上发布的任何软件——以及更多功能！

    https://github.com/marticliment/UniGetUI – 16.2k 星级

    回复

    1. 它很不错，但也是那些臭名昭著的个人开源项目之一。如果可以的话，尽量不要在 IT 环境中使用它。

      如果你能向这个人捐款，那就去做吧。

      回复

    2. 这真的很棒。我之前不知道这个项目，感谢分享！

      回复

  7. 我越是觉得微软不想做的事情，我就越觉得舒服。安全更新？API 更改？当然可以。但我最开心的时候，就是 Windows 只是运行应用程序，让我在屏幕上拖动它们。

    回复

    1. 微软的恶意软件更新已经足够糟糕，它们被强制捆绑在微软的安全更新中。我不确定是否想将其他人的恶意更新也捆绑在一起。

      回复

  8. 这意味着7zip更新现在需要20分钟，并且需要重新启动计算机？

    回复

    1. 不一定。Windows Update推送的许多更新并不需要重启。7zip可以轻松配置为以这种方式运行。

      回复

  9. 我最近发现了Unget（https://github.com/marticliment/UniGetUI）并对其工作方式感到非常满意。

    回复

  10. 这是否意味着现在第三方应用程序也将被允许重启“我的”计算机？

    回复

    1. 不，它没有重启！你看，所有浏览器窗口都打开着，而且几乎都在同一个位置。上下文？那是什么？它一直都是这个样子。你疯了。

      回复

      1. 哈哈！做得不错。

        不确定为什么会被标记，但做这件事的人真该羞愧。

        回复

        1. 如今当微软员工真不容易。没有目标，没有自豪感，到处都是挫折。

          回复

  11. 这是一个糟糕的主意。一旦Windows更新服务出现故障（而它确实有很长的故障历史），这将导致一个巨大的单点故障：https://trends.google.com/trends/explore?date=all&q=Windows%…

    回复

    1. 如果它成为唯一的更新方式，那确实是个问题，但它不会成为唯一的应用程序更新方式。

      回复

  12. 我经常想，为什么微软不效仿苹果，在硬件和软件上全面转型。

    你只能从微软获得Windows笔记本电脑和台式机，但它们非常安全（类似于苹果实现的水平）。

    其他所有设备都需要Windows专业版许可证（并进行严格验证）。

    我相当确定这将极大提升Windows的安全性。

    回复

    1. 因为微软不再是一家软件公司，也从未是一家硬件公司。他们现在是以服务为先的公司。

      他们的大部分收入来自与企业签订的有利可图的支持合同、Azure、Active Directory + Office 企业套件等。

      他们的大部分收入来自消费者，通过在Windows中嵌入“促销”（广告）以及Office 365。这是服务。Windows几乎没有为他们带来任何收入。

      更不用说，他们考虑将Xbox开放给Steam，并提供在iOS和Linux上运行Game Pass的官方教程，这表明他们不在乎你使用哪种操作系统或设备，只要你订阅了他们的服务。

      在这样的环境下，垂直整合策略毫无意义。你希望你的服务能在尽可能多的平台上运行，而不是招致合作伙伴的反对和阻碍。

      此外，他们没有手机平台来吸引用户进入整个硬件生态系统。即使对于苹果来说，Mac + iPad + AirPod的利润也远不及iPhone的利润。

      回复

    2. 我认为这是竞争/市场细分的问题。人们选择微软部分原因在于其生态系统不像苹果那样严格限制用户。

      如果他们想用苹果的策略与苹果竞争，可能会面临一场败局。

      回复

      1. 我以前也这么认为，直到我开始用Mac作为日常主力机。在搭载原生Bash、相对成熟的包管理器以及与设备无缝集成的机器上进行开发，体验要比微软那令人烦躁的冗余代码、莫名其妙的崩溃以及糟糕的程序管理（我们不称它们为“包”，因为它们往往会泄露到系统各处，且卸载效果参差不齐）好得多。

        回复

        1. > 一个相对成熟的包管理器

          什么包管理器？在macOS上安装东西仍然是一团糟，要么是需要自己移动的应用程序的磁盘映像，要么是.pkg文件，要么是App Store。

          这个问题如此严重，以至于我会在新Mac上首先安装Brew。

          回复

          1. > 什么包管理器？

            他们很可能指的是Homebrew。坦白说，它让macOS勉强能用。术语糟糕，Ruby语言也没帮上忙。没有Homebrew的macOS简直无法忍受。

            回复

        2. 公司会因库比蒂诺某人发火而立即放弃向后兼容性。

          微软的向后兼容性为他们带来了巨大的市场份额，但也让他们陷入了困境。包管理器只有在存在某些限制时才能正常工作，但我曾在 2017 年遇到过将 .ini 文件放入 C:WindowsSystem32 的软件。

          回复

        3. 开发者并不是唯一使用 Windows 的人。在 Windows 环境中，软件安装的用户体验比在 Unix 环境中更好且更受控制。

          回复

          1. > 软件安装的用户体验在Windows环境中比在Unix环境中更好且更受控制

            Unix：pkg-add、apt、rpm等。Windows：InstallShield、Teams的“隐蔽、后门式”安装程序、Office的“烦人”安装程序等。基本上：Windows上的每个程序都有自己的安装程序。

            回复

    3. Windows S模式大致如此，它基本上只允许你从商店安装沙盒应用。但许多Windows安全公告（以及据我所记得的大多数浏览器沙盒逃逸）实际上来自随安装附带的、附加到特权Windows服务上的随机半成品功能，所以我不知道这能有多大帮助。Windows架构从未在限制攻击面方面做得很好。

      回复

    4. 参见兄弟评论，但还想补充一点——他们曾在 Windows 11 的 TPM 要求上尝试过类似做法，结果用户们气得要命，拒绝安装。（我认为这完全合理。）我认为全面转换不会得到 Windows 用户的认可。

      回复

      1. 有一个场景我认为可能有意义，那就是Xbox。他们显然对这些系统的安全性足够自信，因为其核心设计就是作为受限的游戏终端（据我所知与AMD在服务器安全方面的研究有关），因此添加一个受限的“桌面模式”似乎可行。他们需要确保这不会启用任何新的越狱方式，以免任何模式比他们预期的更具实用性。如果他们希望用户直接从商店购买/订阅Office，他们不希望LibreOffice正常运行。

        在疫情期间，由于供需失衡， everyone 纷纷转向远程办公，我曾想过是否可以将廉价的S系列Xbox重新定位为廉价的桌面电脑。这本质上是将原先“Xbox作为特洛伊木马”的理念逆转，不再通过游戏主机将Windows引入客厅，而是将其引入家庭办公室。

        回复

    5. 这不是微软的硬件；OEM厂商才是真正的限制因素。英特尔也是如此。市场在抵制垂直整合方面表现得相当有效，即使这是一种不安定的平衡。

      此外，反垄断监管机构绝对会反对这种做法。

      回复

    6. >我经常想，为什么微软不效仿苹果，在硬件和软件上全面整合。

      我认为他们尝试过安全启动，但来自Linux用户的反对以及对反垄断的担忧阻止了他们（至少目前是这样）。

      如果他们这样做，硬件厂商可能会担心市场分裂，导致Linux用户流向其他厂商。虽然人数不多，但仍会造成收入损失。我知道我绝不会购买微软专属设备。智能手机被锁定已经够糟糕了，至少我还可以忽略手机。

      回复

      1. 我从未理解为何有人将安全启动视为开启技术农奴制时代的标志。从几乎一开始，他们就签署了红帽的启动补丁，这使得安全启动完全无法用于锁定用户使用Windows。我认为这从未是他们的计划，除非你相信所有大型科技公司都原则上反对“通用计算机”这一说法。Linux在桌面市场对微软而言并非可量化的威胁，且微软缺乏足够影响力迫使OEM厂商停止销售Linux服务器。

        回复

        1. 因为IBM/RHEL向微软支付密钥（启动加载程序）费用。此外，在Linux/BSD系统中，启动过程开始后会加载自身微代码。

          就Linux而言，安全启动本质上是对用户的敲诈。

          回复

          1. 我猜红帽不得不付钱让补丁签名的原因是“我胡编乱造的”，但即使这是真的，我也不会为IBM的子公司花钱给我提供免费服务而哭泣。而且这一切都忽略了一个事实，即我从未遇到过不允许你设置自己密钥的x86主板。

            回复

    7. > 我经常想，为什么微软不效仿苹果在硬件和软件上全面整合。

      他们之所以比苹果更普遍，其中一个原因就是他们没有这么做。

      回复

    8. 他们尝试过几次——Windows RT、Windows S模式……后者至少还在使用。

      回复

      1. 是的，他们试图重新发明已经存在的东西，结果失败了（当然）。

        他们应该直接复制苹果的做法，因为这是经过验证的策略。而且也证明这不是垄断（至少在美国是这样），所以这是一个安全的策略。

        如果能有像MacBook一样安全的消费级Windows笔记本电脑就好了，因为微软可以强制要求TPM的存在，并在认为必要时停止硬件支持（因为它是消费级Windows笔记本电脑的唯一制造商）。

        回复

        1. 问题是，当OPENSTEP被宣布为Mac OS的编程系统时，比尔·盖茨在被问及微软是否会为其开发应用时回答：“为它开发？我才不干。”——有人怀疑这就是为什么Carbon/Cocoa被称为Blue Box/Yellow Box。

          回复

    9. 在某种程度上，他们似乎尝试过AI PC……尽管并非严格由微软生产，但AI PC对硬件的最低要求更高。

      似乎没人关心，我预计AI PC最终会以75%的折扣出售。

      回复

    10. > 我经常想，为什么微软不效仿苹果，在硬件和软件上全面整合。

      说实话，我有点理解他们为什么不想这么做。几年前我买了一台Surface Pro 8，这可能是近年来我使用过的最糟糕的计算硬件。即使是像热管理这样基本的功能，在运行Windows时也糟糕透顶。在上面运行Linux系统体验稍好一些，但感觉他们连自己的硬件都无法做好，我原本以为同一家公司生产的硬件和操作系统结合会带来更好的体验，但事实并非如此。

      回复

      1. > 我原本以为同一家公司生产的硬件和操作系统结合会带来更好的体验，但事实并非如此。

        他们的软件也是如此。似乎每个团队都在独立工作。由于这种情况，他们基本上无法发布一个“发行版”。我好奇他们需要多少个版本才能实现像Windows 3x及后续版本（从NT4到Win 7）那样统一的界面和体验。

        回复

  13. 和其他网友一样，我认为这种变化远远落后于时代，但不是因为别人早就做到了；而是因为作为一个地地道道的Win32 API/Petzold追随者，在我看来，桌面应用的时代至少在十年前就已经结束了。这里或那里安装的少数应用程序已被手机应用和浏览器所取代。以我为例，我倾向于安装更多实用工具而非其他类型的程序，但这并非微软的有效商业案例。那么他们的目标受众是谁？

    回复

    1. > 这里或那里安装的少数应用程序已被手机应用和浏览器所取代

      在企业环境中，这种情况很少见。我同意一些CAD供应商在开发程序时忽视了核心功能，转而使用Web工具包（因为谁需要内存和速度来进行计算，当你可以将资源分配给用户界面时），但目前这种情况还很少见。

      回复

  15. > 微软过去曾试图说服开发者将应用程序上架到微软应用商店

    > 微软的Windows包管理器也曾试图解决Windows系统中应用程序安装和更新的问题

    第N次尝试是否能成功？

    回复

    1. > 微软的Windows包管理器也曾试图解决Windows系统中应用程序安装和更新的问题

      > 但这并非一种广泛用于安装和管理应用程序的方式，仅限于高级用户和开发者。

      第N次忽视现有方案，转而构建另一个系统。

      回复

      1. 我的意思是，微软想要创建一个第一方包管理器并不奇怪。他们肯定研究过现有方案，如Chocolatey等。[0]

        我认为他们以官方方式支持所有非Windows应用商店应用的更新实际上是一个明智的举措。毕竟，有太多软件永远不会成为Windows应用商店应用。此外，这种官方系统相比之前已有的系统，由于拥有更完善的基础设施，因此包含了更多可靠的恶意软件检测等功能。这也有助于说服开发者转向使用与官方包管理工具兼容的安装/更新库。

        目前，我强烈建议大家通过winget安装大多数Windows软件，如果winget未收录该软件，则可通过Chocolatey安装。

        [0] https://en.wikipedia.org/wiki/Windows_Package_Manager#Histor…

        回复

      2. Windows/Microsoft Installer 套件有人用吗？

        回复

  16. 这是一个有点奇怪的公告。这件事其实很久以前就发生了。他们提到的 MSIX 引擎使用了与 Windows Update 相同的许多技术，因此具有许多相同的功能。我怀疑他们指的是添加一些 API，以帮助非 Chrome、非 MSIX 应用程序从中受益。

    MSIX 是一个有趣的工具。我的公司销售一款名为 Conveyor [1] 的工具，它可以从任何平台（包括 macOS 和 Linux）创建这些包，只需为使用 Electron、Flutter 或 JVM 等运行时的应用程序提供一个简单的配置文件（开源项目免费）。我们做了大量工作来让MSIX更好地工作并更易于使用，因为开箱即用的MSIX相当原始，特别是Windows 10中存在许多微软从未修复的漏洞，因为他们认为这些漏洞已到生命周期结束（EOL）。Conveyor会生成一个仅500KB的安装程序EXE，通过调用MSIX包管理器API完成安装，同时绕过这些漏洞。

    MSIX还提供以下功能：

    • 类似 Chrome 的定期后台静默更新，即使应用未运行时也能进行。

    • 增量块级增量更新。

    • 增量块级下载和安装，即 Windows 可基于文件块哈希值复用一个应用的部分内容来安装另一个应用。当应用共享相同运行时环境时，安装速度极快！

    • 这些安装/更新还可以从局域网中的其他机器拉取块！

    • 声明式安装和操作系统控制的卸载。对用户 AppData 目录的写入被虚拟化，因此卸载可以干净地进行。

    • 包可以无需管理员权限进行安装，无需将内容写入用户的 home 目录。Windows 会运行一个提升权限的服务来为您完成安装。

    • 如果您使用MSIX格式分发应用程序，可以对其进行沙箱化。

    • EXE文件可以自动添加到用户的系统路径中，无需重新启动终端或shell。MacOS无法做到这一点！

    • Windows管理员可以轻松部署和管理这些应用程序。

    • 它们经过加密签名，其完整性由操作系统保护，因此恶意软件无法篡改二进制文件（除非它成功提升到根权限）。

    • 虽然您无法使用常规的 ZIP 工具创建它们，但可以使用 ZIP 工具解压它们。

    Conveyor 还添加了一些其他功能，例如支持类似网页的“启动时立即更新”功能，以及一个简单的 Electron/JVM 控制 API，以便强制用户更新。

    总体而言，这是一个相当不错的功能集，与 Electron 使用的 Squirrel 相比具有显著优势。然而，我绝对不建议您直接尝试使用 MSIX。微软的工具使用起来相当笨拙，且其政策仅支持完全更新至最新版本的 Win11 设备（且仅限于 Windows 系统），这意味着您无法通过 MSIX 直接分发应用程序，除非通过像 Conveyor 这样致力于使其正常工作的中间件。否则您将遇到大量莫名其妙的错误和安装失败，伴随着神秘的错误代码。我们已经为您克服了这些困难，让您无需再经历这些麻烦。

    [1] https://hydraulic.dev/

    回复

    1. 从某种程度上说，这似乎是将“商店更新”重新品牌化为“Windows 更新”，并进一步整合这两个相似但相关的系统界面。将所有用户体验集中在一起似乎是个好主意。

      回复

  17. 迟到总比不到好。我希望所有（糟糕的）更新服务都能消失。在一个可以根据需要暂停更新的集中管理更新系统中，却被过时的设计打断，这毫无意义。

    回复

  18. 既然是微软，我敢打赌这只是因为他们想要对谁安装了什么有更细致的控制和可见性。

    回复

  19. 发现了UniGetUI，它在调用WinGet、Scoop和其他许多工具时表现出色，还支持忽略列表！Windows永远无法达到这种定制化程度。

    回复

  20. 请不要这样做。他们最终会使用一些黑暗模式来强制更新我不想要的软件。微软不可信。

    回复

  21. 这是否能缓解类似Crowdstrike的场景？比如，是否能让回滚损坏的内核问题变得更容易？

    回复

    1. 我认为不会，这只是通过一个中央位置推送更新。如果更新有问题并导致内核 panic，无论更新来自何处，问题依然存在。

      微软不会在通过中央更新功能推送更新前自行测试这些更新

      回复

      1. 当然，但Windows更新难道没有与系统恢复功能集成，以便你可以启动到恢复模式并恢复到更新前的备份吗？

        回复

  22. 我一直希望实现这一点。我曾参与开发一款银行应用，其内部部署的解决方案糟糕透顶。业务线应用在微软应用商店中并不合适。但我的最终结论是，我更倾向于将网络应用部署到IaaS，因为部署更简单且兼容性通常是已知量。在远程服务器和桌面上调试安装程序或桌面应用的问题是一件麻烦事，我尽量避免。

    回复

  23. 我真的希望他们不要搞砸了，我一直在部署计划的Winget任务，而且大部分时候都正常工作。

    回复

  24. 客户需要这个吗？……不过微软可能并不在意。

    对于家庭用户，我认为这可能是个好主意，因为很大一部分用户不会及时更新安全补丁，但对于企业工作流程的破坏性影响又该如何考虑？

    一些企业故意不升级某些软件包，因为这会导致系统故障。在订阅经济模式下，一次性推送所有更新似乎有道理，但这可能迅速演变成订阅地狱：企业推送更新后，你原有的Photoshop授权版本会被强制转换为Creative Cloud。

    这个想法本身不坏，但我对现代软件公司能否以让客户满意的方式管理这一点缺乏信心。

    回复

    1. 这对企业来说不会是太大问题，因为人们明白企业更新方式不同。如果你使用域控制器，你很可能以分阶段和受控的方式在公司内部部署更新。

      回复

  25. 未完成软件的文化越来越主流，涉及操作系统级基础设施和夸张的流行术语部门。

    与此同时，OneDrive 文件重命名功能是否终于能无故障运行？是否有关于此问题的更新待处理？这只是我每天遇到的众多问题之一，这些问题在操作系统层面被自豪地展示出来，却在拖慢我的工作并分散我的注意力。

    …或者当我说“更新并关机”时，最终真的关机，而不是重启并让风扇整晚运转（我以为可怜的机器已经关机了，正如…所建议的）？

    回复

  27. 这是一个前瞻性的概念。好奇其他操作系统何时会效仿。哦，等等。

    回复

    1. 直到在 Linux 上玩游戏变得足够好，以至于 protondb.com 成为一个完全不需要的网站，我才会使用 Windows。

      或者，有一种方法可以让我的 GPU 在 Linux 主机操作系统和 Windows 虚拟机之间共享，这样我就可以将 Linux 作为日常操作系统，同时在 Windows 虚拟机中运行那些在 Linux 上无法运行的游戏。

      回复

    2. 是的，根据 Statcounter 的数据，大约 71% 的桌面用户。

      回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注