回忆录：与 Warner Losh（@imp）的访谈
作者：TOM JONES
译者：Canvis-Me & ChatGPT
TJ: 请问你能告诉我们，在 FreeBSD 项目启动前的 80 年代末 90 年代初，你都在做些什么吗？
WL: 在 80 年代末，我正在新墨西哥矿业技术学院攻读计算机科学和数学学位。我们有一台配备了一两兆字节 RAM 的 Vax 11750，为计算机科学系提供支持，能同时服务 20 或 30 个用户。大约在这个时候，我们还获得了 18 到 20 台 SUN 工作站。我们当时正从运行 TOPS-20 的旧 DEC System 20 系统过渡，因此这时大多数校园都在使用 Unix。
大学毕业后，我在 The Wollongong Group 工作，为他们的 TCP 产品提供技术支持。当我加入时，我并不知道 The Wollongong Group 与 Unix 有关，或者我没有完全意识到这一点的重要性。第一个 Unix 移植是在澳大利亚的 Wollongong 大学完成的，而这家公司购买了该移植的权利。
我在那里工作，为 VMS TCP/IP（他们的产品）提供技术支持，并没有意识到自己错过了结识一些早期 Unix 参与者的机会。
之后，我加入了 Solbourne Computer Inc.，这家公司生产 Sparc Station 和 Sparc 兼容服务器，运行他们版本的 SunOS。大约在这个时候，我开始参与到开源项目中。为了开发工作，我购买了一台 PC，并在上面运行 Linux，因为当时还没有 FreeBSD 的发行版，而补丁包也难以获取。它们宣传不到位，所以我并不知晓。
当时有一场关于使用哪种图形界面的战争。Jordan Hubbard 联系了我，因为他正在使用相同的图形工具包。我们开发了可以同时呈现两种风格的工具包，这样你就可以编写一次软件，随处运行，生活会很美好——这是理论上的设想。Jordan 是那个工具包的用户之一。
有一天，他联系我说：“哦，顺便说一下，我正在尝试启动一个名为 FreeBSD 的操作系统。你应该为它移植。”
我说：“怎么安装？”他说：“好吧，给 Rod Grimes 寄张光盘，或者最好是直接买张光盘，我会寄给 Rod Grimes，他会将其安装在你的机器上，然后寄给你，你就可以运行 FreeBSD 了。”这是在 1.0 版本之前。
在那段时间，我也向 tcsh 等项目贡献补丁。我会发现错误，然后修复它们，发送补丁和 tarball readme 文件。甚至在开始 FreeBSD 工作之前，我就已经在做开源工作了。
TJ: 我问过其他人是如何接触到 FreeBSD 的，但我想你是 Jordan 直接推销的结果。
WL: Jordan 想做与我相同的事情。他想在他的 FreeBSD 机器上运行这个工具包和 GUI 构建器，供公司使用。让我做移植符合他的最大利益，这也是他招募我的方式。从那时起，我一直在使用 FreeBSD。
TJ: 那么，在你开始使用 FreeBSD 之后，你是如何跟进散落各处的对话的？
WL: 这么说——勾起了一些旧的记忆——我想一些对话可能被发布到 Usenet 上。我相信我的雇主确实有一些访问权限。当时我们肯定不在互联网上，但我们可以连接到 Usenet。
这就是我保持了解 FreeBSD 进展并有机会在线上争论的方式。这是我长期以来一直具有的特质。我现在更善于为了争辩而争辩。我试图表达观点。
早期有很多论战，其中一些讨论了一些好的观点，另一些则是你能想象到的最疯狂、最愚蠢的细枝末节。
TJ: 你认为在项目早期是什么让你参与到技术方面的工作中的呢？
WL: 早期，我做了一些初始的警告清理工作——当我们刚开始时，有数千个警告。我认为我做的最重要的事情是承担起 PC 卡的维护者角色，并使 CardBus 在 FreeBSD 上正常运行。那时这些都是新兴技术，非常重要——大约在 3.x 时期。
在早期，发布相当频繁。我认为是在项目开始的一两三年后，我得到了第一台笔记本电脑并开始从事这项工作。那可能是我对项目的第一次重大贡献。在那之前，我做了一些规模较小的事情，主要是清理和修复我在使用 FreeBSD 时遇到的问题。
TJ: 你知道 FreeBSD 1.0 和 FreeBSD 2.0 之间发生的变革背后的背景吗？
WL: 我对发生的变革和背后的情况了解一些，但我并没有直接参与其中。我对那场官司知之甚多。当时我了解到了它，后来我也详细研究了它。简而言之：伯克利发布了剥离所有 AT&T 代码的 4.x 版本，称为 Net2。Bill Jolitz 拿到这个版本，创建了 386BSD，然后与其他人一起创建了名为 BSDI 的公司。所以，有免费版本和商业版本，而 Bill Jolitz 在自由世界中消失了。
Jordan Hubbard、Nate Williams 和其他一些人参与了创建系统的多个不同补丁。他们发布了 FreeBSD 1.0 和 1.1。AT&T 对 BSDI 使用 1-800-ITS-UNIX 电话号码感到不满，认为涉及商标侵权，因此起诉了 BSDI。这演变成了一场关于商业机密和版权等方面的激烈斗争。
很多判决都不利于 AT&T，所以他们了结了那场官司，并在自由社区强加了一项和解，基本上是 FreeBSD——FreeBSD 的核心成员——同意不再基于 Net2 发布任何版本，而是从伯克利的 4.4 Lite 发布版本。伯克利对所有内容进行了清理，获得了 AT&T 的认可，但仍然有一些遗漏的部分。
当时参与 FreeBSD 的所有人都获取了新的源代码，获取了我们为 386 编写的驱动程序，以及我们被允许使用的为 386 编写和修改的代码。我们重写了一些——大约半打——系统中缺失的文件。
FreeBSD 这样做，NetBSD 在那个时候也经历了类似的过程。这是 BSD 之间一些底层内容不同的原因之一。每个项目都在独自重写，因为那时两个项目已经分开，FreeBSD 专注于 x86 并提升其性能，而 NetBSD 则专注于可移植性。
因此，不同的感受和非常强烈的个性差异，阻碍了有效的合作——这可能是描述当时发生的所有争论和论战的委婉说法。这场变革发生在几周或几个月的时间里。
你可以回去看看当我们转向 Git 时的早期历史。历史一直延伸到 2.0 但没有更远，因为很难拉入 1.x 的历史，而且两者之间有断裂。
你可以在 Git 中看到事情发展得很快——人们在快速而猛烈地提交。David Greenman 参与其中，Jordan 也参与其中，Rod Grimes，我认为甚至 Poul-Henning Kamp 这时也参与了，推动了这一切的发生。
TJ: 你能告诉我你如何更多地参与到项目的组织中的吗？
WL: 项目早期的问题是它围绕着 Jordan 和核心团队。人们在核心团队中来来去去，但成员都是内部自行挑选，越来越多的开发人员对此不满。
我们觉得核心团队没有很好地代表项目。项目中负责 Ports 工作的各个部分缺乏足够的代表。Jordan 编写了 bsd.port.mk，Satoshi Asami 接手了这个工作，而 Jordan 是核心团队成员，但并没有很多其他 Ports 的代表。
因此——无论是对是错——人们开始感觉核心团队是精英主义机构。核心团队那时沟通很糟糕，决策也很糟糕，现在可能更糟，他们的运作流程根本没有明确定义。
我们想到了一个主意，让核心团队成为选举产生的机构——Poul-Henning Kamp、Wes Peters 和我。我们聚在一起编写了一套简单的章程。我们决定项目的基本原则是：项目建立在信任之上，你必须信任核心团队，否则一切都会崩溃。
章程简洁而简单：这是如何选举核心团队的，他们是什么样的，他们主导着整个项目。事后看来，需要有一个制定和更新章程的程序。这有一些问题——核心团队太大了。最初我们以为，哦，是的，我们将让核心团队变得庞大，任何人都可以独立行动。冗余性将给世界各地的人提供参与的机会。但核心团队一经当选，他们就开始说每个人都必须参与事务。随着每个人都参与其中，决策变得困难而缓慢，而这从未真正在核心团队之间发生过改变。
我们致力解决的很多问题仍然存在，而且在某些方面，至今仍然存在。章程难以修改。我们应不时对其微调，但根本不可能改变它们。
我组织了一次选举，我们前往旧金山参加 BSDCon，那是新核心团队首次亮相的场合。旧的核心团队在那里，我们做了交接。这也是我第一次与人们面对面见面的时候。我之前与每个人都是在线交往的，到了这个时候，项目已经有五到十年的历史了。
很多人有着非常强烈的兴趣，而现在也有更多的商业兴趣。也许是时候制定一些新章程或修改章程以改善现状了。无论何时发生，都将是一场有趣的讨论。这不是会不会发生的问题，而是何时发生的问题。
TJ: 你在整个项目的历史中都曾在核心团队担任过职务。在此期间，项目发生了怎样的变化？
WL: 在最早的日子里，是“嘿，看到问题就解决”，效果参差不齐。很多问题得到了解决，很多事情也完成了，但它是一种非常孤狼式的方式。有时一个人做某事，只有他一个人在做。但如果两个人在同一个领域工作，有时它运作良好，有时它会导致很多冲突。一些人因为冲突和纷争离开了项目，从这个角度来看，项目并未从中受益。随着时间的推移，更合作的态度逐渐形成。
项目在采用不同工具方面发生了变化。人们忘记了 FreeBSD 是第一个使用 Clang 作为编译器的项目。我们是 Clang 的早期采用者，这对我们非常有益。我们在早期就领先于 Linux，让一切跑起来，构建和使用 Clang。项目正从“是的，尽管去做吧，像个牛仔一样”逐渐转变为“我们会先与人沟通”。
在过去五到十年中，更广泛的审查文化正在发展。如果你回顾一下项目，事情从一开始就经过审查。我们已经从最初只有大约 5% 的提交经过审查，变成可能一半以上的提交经过审查。这更多是一个协作的过程。它涉及到人与人之间关系的建立。你不能只是说：“嘿，审查一下。”你需要培养一批审查者。为了让人们审查你的东西，你必须审查其他人的东西。
这需要时间发展和成熟，过去五到十年里，它一直以更高的强度在发展。特别是自从我们引入了 Phabricator 以来，它允许更多的人提交审核。有些事情用它可以做得更好，有些事情它做得很糟糕。对于准备就绪的较小变更，它非常好。较大的变更可能会更具挑战性。
我们遇到了一些公关问题，比如围绕 WireGuard 等的问题，因为我们作为一个项目没有培养出良好的审查文化。但自那时以来，我们的审查文化已经变得好多了。获取审查变得更容易了。人们正在开发额外的工具，以使提交审查和管理审查更加容易。
我们正在探索实现 CI 的方式。我们作为一个项目已经做了多年的 CI，但它都是事后的，你提交东西，然后找出问题所在。我们正努力将其从事后修复转变为事前预防。
在常规 CI 模型中使用大型系统运行所有测试通常存在一些挑战。你编译所有测试项，运行所有测试，并在所有环境中进行，这需要 10 到 15 分钟，但嘿，为了保持系统正常运行，这是值得的。
如果你在所有环境中运行所有测试和所有构建的排列组合，那将需要几个世纪。因此，你必须为 FreeBSD 取子集，这一直是项目面临的挑战。
有一些正在进行的努力，试图让这一切变得更好，试图让事情更顺利，试图改善情况，而这其中也有一些成长的阵痛。整个项目在其整个生命周期中都是这样。
我们过去做得不好的事情，现在我们做得很好，还有一些过去我们做得不好但我们知道需要改变的事情，我们正在摸索着解决它们。然后有一些事情我们很幸运，从未做得很差。我们设法为早期分发相关工作制定了像 CTM 和 CVSup 这样的出色解决方案，在项目处于那个糟糕的拨号世界时，这些方案是最先进的。
我们不断更新我们的工具——有时很快——有时不那么快。
我们迁移到 Git 可能有点晚，但项目更愿意专注于代码。人们想做新的内核工作。他们想优化缓冲区缓存，使其以更高效的方式流式输出，或者预测工作，以更好地利用空闲时间，或者解决有关虚拟网络或 Jail 等的有趣问题。
没有人想做源代码管理的乏味细节。有很多人有着非常强烈的意见，其中一些观点非常坚定，有些人绝对百分之百确信他们是对的——但他们却不做任何实际工作。因此，他们不是在实际实施它——他们坚称自己曾在过去任职的公司做过这件事，他们知道这是唯一正确的方法。嗯，当 10 个人有 10 种唯一正确的方法时，取得进展就变得困难了。
这并没有倾听项目的独特需求。当然，有很多事情是普遍的，但这个项目有点像有机体。你越是告诉人们按照这种唯一正确的方式去做，越是灌输进去，你失去的人就越多。
如果你的问题是关于项目多年来是如何发展的，我的回答是我们已经成长了很多。有几个阶段，我们做了一些很酷的事情，人们采纳了它，人们发展了它，它就定型了。然后人们推翻那些定型的东西，做新的事情或一堆新的事情，然后不得不再次推翻那些定型的东西，因为它们成了阻碍。我相信，该项目是在不断适应环境的过程中成长起来的。
TJ: FreeBSD 持久的传承是什么？
WL: FreeBSD 在许多领域激发了创新。FreeBSD 在缓冲区缓存设计方面做了很多创新工作。我们在开源领域公开完成这项工作。我们是第一个，然后 NetBSD 来了，做得更好一些。然后我们看到了，我们把我们的做得更好一些。这份传承不一定是一堆代码。而是激发开发的对话和技术。
FreeBSD 是充满活力、蓬勃发展的社区，借助多元意见引发的纷争和冲突，使世界变得更美好。我们通过纷争和冲突学到了如何让 FreeBSD 更好。
有时，纷争和冲突的代价超过了好处。在其他时候，纷争和冲突较少，我们的创新速度不够快。因此，存在一个不错的中间地带，使社区保持活力，而不是永远做同样事情的呆板社区，或者相反，因纷争而无法完成任何事情并最终分崩离析的社区。
FreeBSD 的优势之一是我们学会了如何对话，为不同的立场辩护，然后等到产生胜负后，继续下一场斗争。
TOM JONES 是 FreeBSD 提交者，关注保持网络栈的高效运行。
最后更新于