新的 Ports 提交者：oel Bodenmann (jbo@freebsd.org)
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
采访者：TOM JONES
TJ： 你好，Joel，欢迎你加入 FreeBSD 项目。你能为我介绍一下你自己以及你喜欢从事的技术项目吗？
JBO： 我是一名电子工程师，主要从事嵌入式系统。通常，我喜欢处理被设计用来执行特定任务的系统，而非通用计算。
TJ： FreeBSD 并不以嵌入式系统开发著称，你尝试过在 FreeBSD 上进行工作和项目吗？
JBO： 我不敢苟同。我之所以选择 FreeBSD，正是为了将其用作嵌入式系统开发平台。虽然在过去几年，“嵌入式”世界发生了巨变，但我通常处理的嵌入式系统是资源相对较低、实时性强的系统（即基于微控制器的系统典型设备，CPU 速度 < 120MHz；RAM < 128kB）。因此，这些系统并非直接设计用于运行 FreeBSD；而且实际上，也不会运行什么 Linux（亦不符合要求）。
你仍然需要一台（桌面）主机系统进行实际的开发，以及周围的支持基础设施。我经常参与的上述嵌入式项目，从首次会议到部署产品可能要花几年的时间。我对作为开发平台的 Linux 一个不满是，Linux 生态系统始终处于不断动荡的状态。你在基于 Linux 的系统上配置的开发工作流程和环境，仅仅几个月后，就被迫更新，这就需要重新验证所有的工作流程。
FreeBSD 以其稳定性和连贯性而闻名。FreeBSD 不会因为旧的系统/组件“不够好”而回炉再造新的系统/组件，而是努力使这些系统和工具具有可维护性和可扩展性，从而大大减少了开发系统管理的开销。
对于某些项目，我的确需要一个非微控制器系统，微控制器系统与之通信（即长期数据记录，编排等）。在这种情况下，FreeBSD 具有等同的优势：你设置和验证系统一次。然后，在接下来的几年里，只需执行几次较小的维护任务，而对于基于 Linux 的系统来说，我从来不知道第二天会遇到什么情况。
粗略总结，基本上是，我喜欢把时间花在实际开发和工程上，而不是因为底层的 init 系统、音频子系统、虚拟化和最流行的容器系统（或类似系统）在两年内不断变更而一直在更新、调试和重新验证我的开发平台。这么说，FreeBSD 符合所有要求。自从我将所有服务器、网络基础设施和工作站迁到 FreeBSD 后，我从来没有怀疑过，在第二天进入办公室后，我的开发基础设施是否仍然可以正常启动和工作。FreeBSD 非常可靠。
TJ： 你是否已经在 ports 中有了特定的关注领域？
JBO： 到目前为止，我主要致力于处理“伸手就能解决的东西”，这样做的想法是让我熟悉 ports 系统的基础知识以及工作流程和基础设施。与此同时，这也释放了更有经验的 ports 提交者的资源，让他们可以将精力专注于更复杂的事务。
随着我熟悉程度的增加，我希望在接下来的一年里承担涉及很广的任务，比如更新拥有许多使用者的 ports 库。
因此，我对你的问题的回答是：不，我尽我所能地帮助。我毫不怀疑，随着经验的丰富，我很快就会找到一些更复杂的工作要做：🙂:
TJ： ports 非常庞大，许多小工具就可以完成繁重的工作。到目前为止，你做过的一些容易实现的 port 是什么？你有什么建议可以帮助其他人找到容易实现的 Port 和更容易的第一个 port 吗？
JBO： 就我个人而言，迄今为止，我认为有两种容易实现的目标情境：
PR，这些补丁已经获得维护者的批准，并将补丁更新到新的上游次要版本的 port。在这里，我建议刚开始时避开那些涉及大量用户的“基础” port，以减少触发大规模故障的风险。我的理由是简单的上游次要版本的升级几乎不会出错，并且维护者倾向于小心地避免破坏他们的 port，并且他们已经具有经验，知道要特别注意他们的上游相关事项。
引入新的 port 的 PR。这些 PR 往往是“低优先级”，因此压力相对较小，不必急于将它们落地。此外，我认为这是了解 ports 框架提供的各种不同系统和机制的绝佳途径，这些我可能之前尚未接触过。
截至目前，我所做的工作：我有意尝试触及各个领域的各种 port。我不专注于特定类别或类型的 port。相反，我尝试处理一些我知道依赖于我尚未使用过的东西的 port 的 PR。这是熟悉各种 Mk/Uses/* 脚本的绝佳方式。
TJ： 当你展望 FreeBSD 的未来时，从维护者的角度来看，你认为项目的主要优先事项应该是什么？
JBO： 我认为使 FreeBSD 对各种用户如此具有吸引力的重要原因之一是我们通常遵循更传统的原则。FreeBSD 项目倾向于采取“稳扎稳打”的方式，而不是不断跳上最新的炒作列车不断重新造轮子。当然，这种方法也有缺点。例如，ports 框架可能缺少一些被现代标准视为“基本”的功能，例如子包，可选的推荐安装等。但我认为，正是因为这些事情不被匆忙对待，我们最终得到了一款更稳定和易于维护的系统。
因此，与其回答你的问题并给出需要完成的具体步骤和目标清单，我强烈建议忠于这种方法。最终会证明任何美好的事情都会发生，但通常会以一种非强制的方式发生，以便进行适当的设计、实施和测试，从而有效利用我们有限的人力。
只要不急于求成，不强求进展，就能规避很多子弹。在我看来，“慢就是顺，顺就是快”这句话在这儿适用。
TOM JONES 是一名致力于保持网络堆栈快速运行的 FreeBSD 提交者。
