> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20230910-port-yu-ruan-jian-bao/recollections-an-interview-with-warner-losh-imp.md).
# 回忆录：与 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 提交者，关注保持网络栈的高效运行。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://freebsd-journal-cn.bsdcn.org/20230910-port-yu-ruan-jian-bao/recollections-an-interview-with-warner-losh-imp.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.