PC-BSD 团队面临的具体技术/组织原因有哪些，最终导致他们放弃 PBI 并返回移植？
是因为编译和打包困难吗？是因为他们创建的硬链接有问题吗？或者是因为收集依赖项并一起编译的工作量很大？
我很好奇只是想知道为什么创建软件的同一个团队（比如说GNU现金），花时间和精力为 Windows 提供一个独立的版本，而将 *NIX 留给编译器/安装程序。
我不是在问为什么端口和库很好（简单的安全升级，...）。我也不是询问软件包与 Windows 的偏好或意见，只是询问导致废弃 PBI 的技术原因。我具体想问为什么PBI（0install，NixOS）的路线在技术上不可行或广泛采用。
答案1
PBI 文件格式在 PC-BSD 上停止使用实际上有 3 个充分的理由：
PBI 格式的创建是为了为 FreeBSD 提供打包格式（之前不存在“真正的”打包系统）包装- 仅端口集合）。
一次包装最终在 FreeBSD 本身内开发/实现（9.2/10.0？），几乎没有理由维持竞争格式，因为与辅助包格式相比，更多的人会为修复“官方”FreeBSD pkgs 做出贡献。
PBI 文件格式是 PC-BSD 上用户问题的第一大原因。
大多数 PC-BSD 用户都是前 Linux 用户，他们并不理解独立/受限应用程序范围的概念 - 因此，当应用程序“A”无法找到/启动应用程序“B”时（因为“A”正在运行）受限容器）他们假设应用程序/系统出现故障。与此同时，所有各种基于 Linux 的应用程序都在稳步走向与系统集成（远离独立应用程序的概念），因此越来越多的应用程序根本无法在受限环境中运行。当我们决定从 PBI 切换到 pkg 时，FreeBSD 上只有大约 200 个应用程序可以在受限制的 PBI 容器中成功打包/运行，而通过切换到标准化包装系统我们可以即时访问 FreeBSD 上的所有 23000 多个软件包。这也减少了开发人员的开销，因为整个 FreeBSD 社区将测试/修复应用程序，而不是让（两个）PC-BSD 开发人员也尝试维护所有内容的单独版本。
技术问题
除了一般的容器系统和由此施加的限制/约束之外，还有一些其他技术错误促使我们放弃整个文件格式：
加载时间
启动 PBI 大约需要 30-45 秒，而 pkg 大约需要 2 秒。这主要是由于初始化容器并加载容器内的库。
应用编译
PBI 需要使用与正常情况不同的运行时前缀进行编译（哪些应用程序是应该支持），但应用程序本身通常具有硬编码路径/设置，这会阻止应用程序实际构建/正常运行。这也意味着，当我们在构建应用程序时遇到问题时，我们永远无法从应用程序开发人员或 FreeBSD 搬运工那里获得任何支持，因为我们使用了不同的构建设置。
开发者维护
正如我之前提到的，PBI 系统的维护工作极其繁重。构建应用程序时（由于运行时前缀的更改），构建系统总是遇到奇怪的故障，然后当应用程序做过构建时，它必须由开发人员手动加载/测试，以确保它实际启动（捕获内置路径问题），然后应用程序的元信息也需要更新/维护（我们仍然保留现在这个额外信息 - 但将其视为 pkg 系统的附加信息覆盖）。因此，这不仅需要两个人维护大量工作，而且最终应用程序本身几乎无法运行，因为它们没有像大多数 Linux 应用程序的设计那样集成到基本系统环境中。
请注意，虽然 PBI 文件格式已从 PC-BSD 中删除，但我们仍然致力于应用程序划分。相反，我们一直专注于使用预先存在的 FreeBSD 子系统（例如监狱框架）来确保可靠/安全的运行时容器，而用户安装的“标准”应用程序将像在其他操作系统上一样正常/可靠地运行。