FreeBSD 的新面孔
最后更新于
最后更新于
原文链接：
作者：DRU LAVIGNE
本专栏旨在聚焦那些最近获得提交权限的贡献者，并将他们介绍给 FreeBSD 社区。在本期中，我们聚焦的是 Nick O'Brien，他在 3 月份获得了他的 src 权限；以及 Richard Scheffenegger，他在 4 月份获得了他的 src 权限。
Nick： 我出生，成长于华盛顿州的西雅图，但自 2017 年底以来，大部分时间都住在加利福尼亚州的圣何塞。目前，我在 Axiado 从事嵌入式软件工作，我们使用 FreeBSD 来做 RISC-V 相关的工作。
最初，我进入软件编写这个领域更多是出于需求，而不是对编写代码的直接兴趣。从小学开始，我就需要为不同的个人项目编写软件，每当遇到问题时，我都会 Google“如何……”。经过多年的杂项软件开发后，我开始意识到我真的很喜欢工程中的实际问题解决部分，并且对编写软件的实际技能越来越认真。
在计算机之外，我的一些爱好包括跑步、试图冲浪时被浪头打得七荤八素，以及弹吉他。
Richard： 我现在居住在奥地利维也纳（我的工作场所常常会把它和维吉尼亚州的维也纳搞混），这里也是我的家乡。大约 15 年前，我加入了一家网络存储公司，负责支持他们的新产品——一个缓存的 web 代理。然而，尽管我在这方面有一定的技能，我的简历却被一家专业猎头公司拒绝了。我开始了我的网络职业生涯，当时还是在学校时，使用邮件和 USENIX 网关设置了一个“联网”的 BBS（属于 TrekNet，基于 FIDOnet 技术），那时公众还不知道互联网的存在。这一切发生在 Web 出现之前。我记得当时在大学的计算机房里，Gopher 是最流行的东西。随后，我在一些小公司工作，始终与网络有关。那时，接近千禧年，我是德语国家某供应商特殊网络操作模式的专家——这是一种过早的 TRILL 先驱模式——即使是该供应商的支持人员也多次联系我。但是，我不想跑题，偶然的机会，我的简历被一个在猎头公司实习的员工发现，并且他为我把简历归档到了一个类似的职位上，除了我最初申请的职位之外。
在经过彻底的测试和多次面试后（回顾起来，我认为负责技术部分的人无法弄明白为什么我能如此快速且知识丰富地回答问题，而我的答案在当时的任何搜索引擎中都找不到完全匹配的内容），我于 2005 年开始在 Network Appliance（现在称为 NetApp）工作。那时我的办公室位于阿姆斯特丹的 EMEA 总部，我从事与我之前 IT 专业知识相关的领域工作。NetApp 是为数不多的提供专业大规模 NAS 解决方案的企业级厂商之一。大多数其他大型存储厂商则更加侧重于 SAN，因此，我最终选择 NetApp 也是一个不错的匹配。最终，我开始在公司内部担任一个覆盖 EMEA 区域的角色，并被允许选择我的主要办公室。因此，在德国工作一段时间后，我最终回到了我的家乡。
此外，由于我非常对网络感兴趣——尤其是将数据从 A 传输到 B——这项专业知识在我的雇主处理的设备中显得尤为重要，因为这些设备需要通过多种不同协议（如 NAS 和 SAN）尽可能快地提供数据，而对于 IP 部分，则通过 NFS、SMB 和 iSCSI（NVMe 也即将应用于 IP）。由于我曾受过化学培训，对复杂系统交互的良好理解也有所帮助。
在我的任职过程中，我几乎对消除 IP 协议中的所有延迟源产生了痴迷，这也使得人们在存储领域寻找不同的技术解决方案（例如 SAN 和 IB）。我记得有一次，我想说服时任 CTO 在一个更大的内部论坛上通过一篇准备好的演讲，讲述减少 IP 延迟对我们产品的好处——在与他私下简短交谈后，他同意了我的观点，而这让他感到有些不悦。
这次互动促使我积极参与了 IETF，并且我至今仍在交通领域，尤其是 TCP 方面，保持着浓厚的兴趣。短暂一段时间内，我还曾担任过（较新的）AQM 工作组的共同主席，致力于推动比 RED 更现代的队列管理机制的采用。我参与 AQM 的原因是我对显式拥塞通知（ECN）产生了浓厚的兴趣，这是一种让 TCP 在不丢包的情况下根据网络的（瞬时）能力和容量进行调整的方式。通常人们认为，大多数网络设备实现的——如果它们实现了除 drop-tail 以外的机制——在完成这一任务时都是相当不充分的。
然而，由于我们位于欧洲，距离我们的工程团队在美国和印度的办公室相当远，因此我关心的领域中我们产品的改进速度较慢。在某个时候，当我提供了另一个关于 TCP 的详细缺陷报告，来解决我观察到的一些客户在运行存储流量通过 TCP/IP 时遇到的问题时，我被告知：“一旦有 FreeBSD 补丁解决这个问题，我们就可以将其引入。”
于是，我真正开始参与 FreeBSD 项目，借助我现有的联系人并努力成为一名贡献者（提供带有测试用例的补丁，解释问题所在，并提交了一些缺陷报告），最终被接受为提交者。
Nick： 我曾在一段时间里听说过 FreeBSD，也许甚至使用过它，但直到 2018 年加入 Axiado 后，我才真正开始深入了解 FreeBSD。那时，我们开始着手解决如何让 FreeBSD 在 RISC-V 硬件上启动的问题。我喜欢为 FreeBSD 编写代码，但我也非常喜欢这个专注、紧密的社区。感觉它是一个相对较小的社区，但却在产生着不小的影响。最后，我不想错过与这么多聪明人一起工作的机会。
Nick： Kristof Provost（kp@）和 Philip Paeps（philip@）在 Axiado 做 FreeBSD 咨询工作。在与他们合作了一段时间后，并且在我与 RISC-V 社区在 Phabricator 上互动之后，他们邀请我参加了 2019 年 10 月在圣何塞英特尔举办的我的第一次开发者大会！那次经历非常棒，那真的是我第一次看到一个团队为了一个开源项目齐心协力。再过了几个月，在 Phabricator 上的互动后，他们提出了给我一个提交权限。我简直兴奋不已！
Richard： 在 IETF 会议期间，我与许多 FreeBSD 项目的提交者有所接触。进行 TCP 改进的工作通常也意味着最终要实现并部署这些改进。因此，我已经开始编写代码来改进基于我的建议的 SACK 丢失恢复，这些建议完全在 RFC6675 中得到了实现，称为“救援重传”。大部分代码被存放在私有构建中，并未广泛发布。为数据公司工作还让我接触到与许多其他供应商提供的设备和软件的接口，其中一些供应商也在他们的软件中使用了 FreeBSD 或其部分组件。我想为 FreeBSD 的其他用户贡献缺陷修复和改进——最终也能使我的雇主和这些其他供应商的共同客户受益——通过改善商业 IT 架构中仍然典型的复杂异构环境中的行为、稳定性和互操作性。在提供了大约 40 个补丁（大部分是 bug 修复和一个重要特性——DSACK——这个特性得到了其他贡献者的广泛认可）之后，我被邀请成为提交者，rgrimes@ 和 tuexen@ 成为我的导师。我仍然对能得到如此高水平的过程和技术支持，帮助我改进对项目的贡献感到敬畏。
Nick： 这真是一次非常棒的经历，但也是一个稍微奇怪的时刻，因为有很多奇怪的世界事件发生。到目前为止，我最喜欢的部分是与世界各地的 FreeBSD 开发者们互相交流想法。每个人似乎都愿意倾听，所以我觉得自己真的有了发声的机会。我也从我的同伴们身上学到了很多！
我给那些想要成为提交者的读者的建议是，要明白这并不遥不可及。你不需要被闪电击中才能成为提交者。只需从决定自己想要贡献的领域开始，关注 Phabricator 上的上游工作，联系那些已经在做这些工作的其他人，并在自己能够的地方提供帮助！当我告诉他我有兴趣成为提交者时，我记得 philip@ 说过类似的话：“这并不像你想的那么遥远。”当时，我甚至觉得这几乎不可能，但他是对的；几个月后，我真的成了提交者！我们都是一个团队，每个人都在这里提供帮助，所以要感激那些支持你的人，并尽量利用这个机会！如果你真心想成为提交者，相信我，总会有人注意到你的。
Richard： 好吧，核心的 transport@ 小组（主要处理 TCP、一部分 SCTP 和相关方面）每隔一周开一次电话会议。当我开始在 reviews.freebsd.org 上提交真正的 diff 时，我就开始参与这些会议了。这些电话会议在讨论问题和解决方案时非常有帮助，也有助于建立声誉。正如你可以想象的那样，处理像 TCP 这样重要的内容有着非常高的要求，不能引入任何回归或性能下降。话虽如此，我早期的一个提交确实有一些意外的副作用，所以我很快就学会了如何从 HEAD 撤销提交。那里的审查过程非常严格，补丁在被接受之前会进行充分讨论。简而言之，如果一个人更想了解在开源项目中工作的流程，而不是专注于学习 TCP 基础，我并不推荐他选择 TCP 堆栈作为重点领域。然而，我找到的同行和导师都非常优秀，给出了很好的反馈。算上我最初在 ECN 问题上的间接贡献，直到我成为贡献者花了约 10 年时间。就我个人而言，我的雇主一直非常支持，因为从产品的角度来看，提升网络领域的传输现状是很重要的——即使这个过程非常缓慢，以确保不会出现任何问题。但我成为提交者所花的时间是非典型的，更多的是与我贡献的领域有关。我知道一些提交者，在他们的硕士论文期间就开始间接为 FreeBSD 项目做贡献——当时他们的教授支持他们——直到今天他们仍在继续贡献。由于硕士论文通常在一年内完成，这种情况才是更常见的。
DRU LAVIGNE 是《BSD Hacks》和《The Best of FreeBSD Basics》的作者。
Richard： 很难说；我至少在过去 20 年里肯定听说过 BSD 系列。我的第一次真正接触 FreeBSD 是通过成为 的一部分。我对 TCP ECN 感兴趣，并发现 BSD 系列中的原始 ECN 实现存在一个疏漏（并且 RFC3168 中没有充分记录的行为），导致它无法按预期工作。由于 FreeBSD 深深嵌入了我雇主的某些商业产品，尤其是 ONTAP 数据管理软件，因此我越来越有兴趣改善那里的情况。特别是因为 FreeBSD 曾经缺少一些重要特性（如 DSACK），这些特性在与云系统接口时非常重要，或者其某些特性并未完全达到生产级别（例如 CUBIC）。后者对于在长距离传输中提供良好的性能至关重要。NetApp 提供的解决方案基于跨越广泛距离的同步数据复制，称为 MetroCluster，这是我的产品专长。尽管 CUBIC 已经推出了一段时间，但存储类别流量仍然有一套独特的挑战。首先，存储 IO 是非常事务化的——客户端发出非常详细的请求。此外，存储 IO 通常受应用程序限制——数据仅按应用程序能处理的速度请求，而服务器无法尽可能快速地传输大对象，因为这完全取决于 TCP 和网络的限制。这与 TCP 的典型架构使用案例（无限数据、传输速度受网络/接收方限制）大不相同，也不会出现在更以 Web 为主的环境中。