PC-BSD PBI，是什么原因让它报废的？

Question

PC-BSD 团队面临的最终导致他们废弃 PBI 并返回端口的详细的具体技术/组织原因是什么？

是因为编译和打包困难吗？是因为他们创建的硬链接有问题吗？还是因为收集依赖项并一起编译的工作量很大？

我很好奇为什么创建软件的同一个团队（比如GNUCash）花时间和精力为 Windows 提供一个独立的版本，而 *NIX 留给编译器/安装程序。

我不是在问为什么端口和库是好的（简单的安全升级，...）。我也不是询问软件包与 Windows 的偏好或意见，只是导致废弃 PBI 的技术原因。我特别问为什么PBI（0install，NixOS）的路线在技术上不可行或被广泛采用。

Answer 1

PBI 文件格式在 PC-BSD 上停止使用实际上有 3 个充分的理由：

1. PBI 格式的创建是为了为 FreeBSD 提供打包格式（在pkg之前不存在“真正的”包系统- 只有 ports 集合）。

   一旦pkg最终在 FreeBSD 本身内开发/实现（9.2/10.0？），几乎没有理由维持竞争格式，因为与辅助包格式相比，更多的人会为修复“官方”FreeBSD pkg 做出贡献。

2. PBI 文件格式是 PC-BSD 上用户问题的第一大原因。

   大多数 PC-BSD 用户都是前 Linux 用户，他们并不理解独立/受限应用程序范围的概念 - 因此，当应用程序“A”无法找到/启动应用程序“B”时（因为“A”正在运行）受限容器）他们假设应用程序/系统出现故障。与此同时，所有各种基于 Linux 的应用程序都在稳步走向与系统集成（远离独立应用程序的概念），因此越来越多的应用程序根本无法在受限环境中运行。当我们决定从 PBI 切换到 pkg 时，FreeBSD 上只有大约 200 个应用程序可以在受限制的 PBI 容器中成功打包/运行，而通过切换到标准化pkg系统，我们可以立即访问所有 23000 多个包在 FreeBSD 上。这也减少了开发人员的开销，因为整个 FreeBSD 社区将测试/修复应用程序，而不是让（两个）PC-BSD 开发人员也尝试维护所有内容的单独版本。

3. 技术问题

   除了一般的容器系统和由此施加的限制/约束之外，还有一些其他技术错误促使我们放弃整个文件格式：

   • 加载时间

     启动 PBI 大约需要 30-45 秒，而 pkg 大约需要 2 秒。这主要是由于初始化容器并加载容器内的库。

   • 应用编译

     PBI 需要使用与正常情况不同的运行时前缀（应用程序应该支持）进行编译，但应用程序本身通常具有硬编码路径/设置，这会阻止应用程序实际正确构建/运行。这也意味着，当我们在构建应用程序时遇到问题时，我们永远无法从应用程序开发人员或 FreeBSD 搬运工那里获得任何支持，因为我们使用了不同的构建设置。

   • 开发者维护

     正如我之前提到的，PBI 系统的维护工作极其繁重。构建应用程序时，构建系统总是会遇到奇怪的故障（由于运行时前缀的更改），然后当应用程序构建时，开发人员必须手动加载/测试它以确保它实际启动（捕获内置的）在路径问题中），然后应用程序的元信息也需要更新/维护（我们现在仍然保留这些额外信息 - 但将其视为 pkg 系统的附加信息覆盖）。因此，这不仅需要两个人维护大量工作，而且最终应用程序本身几乎无法运行，因为它们没有像大多数 Linux 应用程序的设计那样集成到基本系统环境中。

请注意，虽然 PBI 文件格式已从 PC-BSD 中删除，但我们仍然致力于应用程序划分。相反，我们一直专注于使用预先存在的 FreeBSD 子系统（例如监狱框架）来确保可靠/安全的运行时容器，而用户安装的“标准”应用程序将像在其他操作系统上一样正常/可靠地运行。