为什么 Rufus 没有成为多负载创建工具？

Question

为什么 Rufus 没有添加对将可启动映像添加到 USB 且无需随后重新格式化的支持，例如 Windows1、Windows2... 或 Windows1、Linux1...？为什么 Rufus 没有成为多负载创建工具？

Answer 1

鲁弗斯开发在这里。我们的常见问题解答中对此进行了解答，但需要进一步详细说明：

1. 因为，尽管多重启动的支持者通常坚持认为，绝大多数创建可启动驱动器的人只会启动一次特定映像，并且永远不需要再次使用它（特别是现在，任何超过 6 个月的 ISO 都可能被删除）过时的）。因此，实际上少数高级用户或真正的系统管理员可能需要一个 512 GB USB 驱动器，其中包含各种 ISO，“以防万一”。
2. 然而，Rufus 实际上并不是为系统管理员/高级用户开发的，而是为需要立即启动特定 ISO 来安装特定操作系统的临时用户而设计的，一旦完成，可能会重新格式化驱动器一些其他目的。因此，我非常愿意将有限的开发时间投入到确保这种特定用法有效，并且效果良好。将多重引导加入到混合中要么会降低体验，要么，正如我相信 Ventoy 开发人员所发现的那样，需要大量的连续时间投资，以确保对实用程序进行微调，以便多重引导方法可以支持此类 ISO。
3. 说到Ventoy（这可能就是您正在寻找的东西，我们总是很乐意将寻找多重启动实用程序的人们引向 Ventoy），虽然我们认为他们支持多重启动的方法非常漂亮，但我们担心的问题之一是这需要将内容注入到原始 ISO 数据中，而我们在设计 Rufus 时绝不会更改 ISO 内容（一个小例外是一些 GRUB/Syslinux 配置文件，以适应 FAT32 的限制，但如果发行版维护者正确地完成他们的工作，这不需要）。因此，我们担心的是，如果 Microsoft 或 Linux 发行版维护者开始验证正在执行的引导内容的信任链，Ventoy 用于提供多重引导的方法（对于 Windows，需要替换Windows\System32\winpeshl.exe为非 Microsoft 生成的可执行文件）将立即被淘汰。正如您应该知道的那样，肯定会推动操作系统为启动过程添加更广泛的验证和信任。现在，这并不是说我们设想这种情况很快就会发生，特别是因为微软很可能拥有大量企业客户，他们依赖于为其安装过程注入自定义可执行文件的能力。但我们不禁担心，任何需要注入才能发挥作用的东西都可能会被操作系统制造商一时兴起而废弃，而当您一开始就不需要注入时，这个问题就不太可能发生，像 Rufus 这样的非多重启动实用程序则不会。但是，请不要将此声明误解为对 Ventoy 的贬低，因为坦率地说，Ventoy 的创建者应该得到很多赞誉，因为他发现了一种很棒的通用方法来添加对读取 ISO 内容的支持，即使这不会我改变了对多重启动的立场，我有点希望我自己也能想到像这样聪明的东西。

总而言之，不糟糕且可能长期有效的多重引导是很难的，因为光学引导和 USB 磁盘引导是完全不同的野兽，通常使用广泛不兼容的方法，很难很好地协同工作（并且，再次感谢 Ventoy 找到了一种让它不那么糟糕的方法）。因此，我们估计成本/收益比太高，而且（尽管这当然是一个有根据的猜测，您可以自由地不同意），除非某人是系统管理员，否则他们很可能会浪费更多时间尝试维护多重启动 USB，而不是简单地为他们现在需要使用的映像重新创建单个启动 USB。因此，我们认为花时间在 Rufus 中实现多重引导并不是一项好的投资。