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 子系统(例如监狱框架)来确保可靠/安全的运行时容器,而用户安装的“标准”应用程序将像在其他操作系统上一样正常/可靠地运行。