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

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

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

答案1

Rufus 开发人员在这里。这是在我们的常见问题解答中回答,但进一步阐述一下:

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

总而言之,多重启动并不糟糕,而且从长远来看可能会有效很难,因为光盘启动和 USB 磁盘启动是完全不同的两种东西,通常使用完全不兼容的方法,很难很好地协同工作(再次感谢 Ventoy 找到了一种让它不那么糟糕的方法)。所以我们估计成本/收益比太高,而且(虽然这当然是一个有根据的猜测,你可以不同意)除非某人是系统管理员,否则他们很可能会浪费更多时间来维护多启动 USB,而不是简单地为他们现在需要使用的映像重新创建单启动 USB。因此,我们认为花时间在 Rufus 中实现多启动并不是一个好的投资。

相关内容