回忆录：与 Warner Losh（@imp）的访谈
作者：TOM JONES
译者：Canvis-Me & ChatGPT
TJ: 请问你能告诉我们在 FreeBSD 项目启动的 80 年代末 90 年代初，你都在做些什么吗？
WL: 在 80 年代末，我正在新墨西哥矿业技术学院攻读计算机科学和数学学位。我们有一台配备了一两兆字节 RAM 的 Vax 11750，为计算机科学系提供支持，能同时服务 20 或 30 个用户。大约在这个时候，我们还获得了 18 到 20 台 SUN 工作站。我们当时正在从旧的 DEC System 20 运行 TOPS-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 电话号码感到不满，因为这涉及到商标侵权，他们起诉了他们。这演变成了一场关于商业机密和版权等方面的激烈斗争。
很多判决都不利于 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 提交者。
最后更新于