> 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/20191112-wang-luo-xu-ni-hua/an-interview-with-kirk-mckusick.md). # Kirk McKusick 访谈 作者：Allan Jude 和 Benedict Reuschling FreeBSD 期刊编辑委员会认为，BSD Now 系列中一些精彩访谈或许会让读者感兴趣，因为它们反映了访谈进行时技术的状态。这里我们转录并节选了 2018 年 Allan Jude 和 Benedict Reuschling 对 Kirk McKusick 的访谈。 *** **Benedict**：本期 BSD Now 节目里我们其实也算享受了一下假期，所以从架子上挑了些内容。早在 BSDCan 2018，我们就坐下来和 Kirk McKusick 谈了很多话题，从 BSD 和 Unix 早期岁月，到他正在持续做的 UFS 工作，再到 FreeBSD 治理，等等。今天我们请到了 Kirk McKusick，他是 FreeBSD 项目最早的 committer 之一，也是加州大学伯克利分校 BSD 项目的负责人。欢迎。我们首先想知道的是，你是怎么和 Unix、BSD 结缘的。 **Kirk**：我和 Bill Joy 同办公室。最初那是 Bill Joy 的项目。不可能不被卷进去，因为只有四张桌子、四个人。整个办公室共用一部电话，电话响了时如果我正好在附近，我就接起来递给 Bill，因为 99% 的电话都是找 Bill 的。既然如此，别人还接它干嘛？ **Benedict**：你早期参与 BSD 时，有想过它会变成今天这样吗？ **Kirk**：完全没想过。我向来不擅长预测未来。当时对我来说，这只是 Bill 手里的一些程序，你没法待在 Bill 身边而不被吸进去做事。他会说：“哦，你能不能帮我做这么一件小事？”举例来说，我们有个 Pascal 编译器，先编译成字节码，再由解释器执行，而那个解释器是用汇编写成的。 后来我们有了一台 VAX，Bill 说：“你能不能把这个 Pascal 解释器移植到 VAX 上？PDP-11 上有 MOVE 指令，VAX 上也有 MOVE 指令。简单转换一下就行。”哈哈。三个星期后，总算折腾出了点东西。但他总能把每件事说得那么简单那么轻松，我们也就这么做了。 发布方式就是 Bill 到处分发磁带。他去各种会议宣传 BSD，人们听得热血沸腾，都想要最新的 BSD 发行版。代码也会回流，就这样越滚越大。当时它就像一个大软件项目。很多人写程序，相互传阅，最终成就了它们今天的样子。我绝没料到会变成今天这样。 **Allan**：是的。 **Benedict**：或许这反而激励了其他人贡献，因为在他的演讲上他们别无他法可逃？ **Kirk**：是啊，关键是 Bill 会出去和人聊天：你在做什么，吧啦吧啦。早期的 EX 编辑器源自伦敦玛丽女王学院 George Coulouris 教授写的 EM 编辑器。Bill 的态度一向是：既然能用别人已经做好的更好的东西，何必自己再发明一个好东西？于是他会找别人做的成果，再略加修饰，变成自己想要的。 其实不是 Bill，是 Keith Bostic 常说：把功劳记给别人，你能为这世界做的好事没有尽头。特别是当我们试图重写 AT\&T 的程序时，他会让别人写 CAT、LS 之类的工具，贡献到伯克利，他把对方的名字到处写上，十有八九自己又把里面 80% 重写一遍。 **Benedict**：（笑）好的。 **Allan**：嗯，这很大程度上也是 BSD 哲学的一部分——把功劳记下来才是关键。 **Kirk**：没错，而且这么做——正如 Keith 在 AT\&T 为代码原创性争吵时所说——他总能说，要怪我也能找到别人，你去和某某谈吧，那是他写的！ **Allan**：那些文件里真有大量历史。 **Kirk**：是的。 **Allan**：你看任何一个文件有多少人改动过，你会惊叹，哇！ **Kirk**：是的，有些文件真的很惊人。有个文件我以为是我写的。我去看了一下，发现自己大概只写了四五行，可能还是版权声明里的几行。 **Benedict**：而且这些程序里有人们倾注的精心维护，让它们继续在你的硬件上、你的环境里、你的文件格式下还能用。 **Allan**：是的。像 RISC-V 这种全新架构，也能在稍加点拨之下运行所有这些老代码。 **Kirk**：是的，正是如此。精心喂养是系统能存活的关键。当然，新东西、令人兴奋的东西才能吸引关注。 文档很重要，但对大多数程序员而言并不令人兴奋。我记得许多年前有人来找我：“我对 FreeBSD 感兴趣。我只是个写文档的，不会写代码，我能做什么？”我说：“巧了，我们正好有一堆 man 手册。” **Benedict**：我们等你很久了。 **Kirk**：是的，我觉得文档是 FreeBSD 成功的很大一部分原因。而文档之所以成功，是因为我们没有这种森严的等级。 **Benedict**：是的。 **Kirk**：只要你是 committer，你就有同样的投票权选 core，不管你提交的是文档、源码、Ports 还是系统管理脚本。 **Allan**：甚至可以进 core team。 **Benedict**：是的。 **Allan**：不只是源码 committer 才有资格参选。 **Kirk**：对。大家都认识到 FreeBSD 项目里重要的不仅是代码。 **Benedict**：是啊，而且如果人们的工作得到认可，往往会做更多。文档写手会变成 Ports committer 或源码 committer，两边都做。 **Allan**：我就是这样被吸进来的。2013 年在来这儿的火车上写了些笔记，2014 年成了文档 committer，2015 年成了源码 committer，2016 年进了 core team。 **Kirk**：是的，正是如此！ **Benedict**：特别是在这次会议上，我们也物色到了新人，嗯，这家伙可能是个不错的源码 committer 人选，或者给他点权限试试。 **Kirk**：FreeBSD 相对 Linux 的一个优势，是我们懂得要不断吸纳新人。Linux 顶层的人正在老化，看这种更替会如何进行将很有意思。 Linus Torvalds 退休时，谁会上去？怎么上？ **Benedict**：是的，系统越长大，要维护的代码越多，一个人或一小群人根本做不过来。当然也有人离开。每个人都有自己的人生，但只要进来的人比离开的人多，项目就还健康。 **Kirk**：BSD 有一段时间，我休假两周，问题就没人修得了。我的目标是，万一哪天我被公交车撞了，BSD 还能继续运转。 **Benedict**：是的，项目还在。 **Kirk**：我早就不是关键齿轮了。 **Allan**：这就引出下一个问题：你认为 FreeBSD 项目过去 25 年最大的成就是什么？ **Kirk**：嗯，这就是我那场治理演讲的内容，对吧？我认为我们演化出了一套能让项目持续推进、吸纳新人、并让这些人脱颖而出的体系。多年前有人做过一项研究，是 MIT 和法国图卢兹大学搞经济学的人做的。他们就是研究源码提交日志，看谁说了算。 如果你看 Linux，一直是 Linus Torvalds 和他一群副手，相当固定——贯穿 Linux 整个生命周期。所以他们只有一种领导层。大多数开源项目在五年内就会沉寂——沉寂的定义是一年内没有提交。通常是项目的创始人离开。偶尔能完成一次领导层更替，但之后就垮了。只有少数几个项目——Apache、FreeBSD 以及另一个——完成了三次或以上成功的领导层更替。算上伯克利时期的 BSD，我们已经是第五代了。所以 FreeBSD 经历了四次领导层更替。 **Allan**：或者说你能数 FreeBSD 的 core team 数目？ **Kirk**：看看 core team 的人。Jordan Hubbard 时代。Robert Watson 时代。如今这帮人。有人曾经主导，如今很多人还在周围晃悠，但已经不真正主导了。 **Benedict**：但能力——领导层更替是有的—— **Kirk**：对。 **Benedict**：——以及之后能继续成功运转。 **Kirk**：committer 群体持续演化，25 年来平均和中位 committer 年龄仍低于 40 岁，虽然有所上升。从 30 出头起步，现在快 40 了，大概 40 了。如果我把 60 岁以上的 committer 都砍掉，平均年龄大概降到 38。我们只需要把这些老家伙踢走。大概有 12 个。 **Benedict**：我想这也是项目生命力的考验。他们也丢了一些人，或者一些人对项目未来能否活下去失去了信心？但只要新人进来看到它还在运转，就会从这里继续下去。 **Kirk**：对。还有一件事我不确定算不算成就，但 FreeBSD 代码库的进步更稳。Linux Foundation 很自豪一年里给 Linux 内核加了一百万行代码。 在我看来那是一场彻头彻尾的灾难。多并不等于好。Windows 学到了这个教训——当它长到五千万行代码时，再也无法稳定它。即便资源雄厚，也做不到。 **Allan**：是的，活动部件太多。臃肿。 **Kirk**：对，修 bug——这么多行代码，你根本——永远修不到稳定的程度。Linux 仅内核就有两千万行。FreeBSD 内核不到两百万行，整个 FreeBSD 发行版今天是一千六百万行。但那包含内核、命令和基本系统的库。 **Benedict**：那么，25 年后的今天，项目变成什么样让你最意外？ **Kirk**：它还在这里，而且大获成功。开源软件项目的半衰期是五年，我们已经活过了五个生命周期。如果把伯克利时期的 BSD 也算上，从 1978 年到现在，整整 40 年。我在 Usenix FAST 大会做过一次演讲。他们让我做主题演讲，主题是 30 年来 Fast File System（UFS）的演化。我开场说：要是 30 年前你告诉我，30 年后我会就这套软件做主题演讲，我会怀疑你嗑了什么药。 软件的半衰期比项目还短。多数软件的寿命是三到五年。UFS 至今还在跑，相当罕见。我随手拿了一个 1982 年的 UFS 文件系统镜像——那是我建的第一个 UFS，我把它存成镜像——居然能在今天的 UFS 实现上读写。虽然它对一些柱面表映射的东西有点不爽，但能用。 **Benedict**：是的，那里有一些变化。 **Kirk**：另一个有意思的问题是，更现代的 Zettabyte File System（ZFS）会不会取代 UFS？答案是不会，因为它们解决不同问题。资源充裕、文件系统巨大时，用 ZFS 是理所当然。但在嵌入式系统上，你不会用 ZFS，你跑不动它。你需要 UFS，它短小精悍。 **Allan**：是的，我们正进入一个拥有数十亿更多微小设备的时代，它们都需要文件系统。 **Kirk**：是的，那不会是 ZFS。 **Allan**：是的，我猜你也没预料到 UFS 会有数十亿安装量，或者数十亿卷。 **Kirk**：是的，没预料到。 **Allan**：我觉得没人想过会有十亿台计算机。 **Benedict**：而且你会想用经过这么长时间验证的可靠方案，而不是用刚起步的新开发。当然新东西总会出现，但既然有 UFS 这种久经考验的现成货，用它显然比从零开始好。 **Allan**：嗯，UFS 也并非一成不变，对吧？它有维护，在现在的 SSD 上也工作得很好。 **Kirk**：UFS 需要精心喂养。我刚到伯克利时，并不理解这个概念。 **Benedict**：你得回去看看，是的。 **Kirk**：好在 Rick Macklin 做了大量 NFS 早期工作，从那以后基本也是他在精心维护。David Greenman 最早负责 VM 系统，后来 Alan Cox 把它带到了你百万年也想不到的地步。Jeff Roberson 现在做很多 UFS 的工作。 所以我可以坐在一边说：哦！你应该试试这么做。 **Allan**：是的，是的。 **Benedict**：所以历史又重演了。 **Kirk**：是的。做“老人家”挺好玩的。你可以光出主意，不用干活。 **Allan**：你看着项目发生，享受所有乐趣。 **Benedict**：是的，享受劳动果实。 **Allan**：是的，压力也小。 **Kirk**：有人问我什么时候竞选 core？哈哈。不，绝不！在伯克利我干过 10 年。我服过役了。 **Allan**：是的。回头看，你最难忘的 FreeBSD 相关记忆是什么？ **Kirk**：哦！最难忘的 FreeBSD 记忆？有这么多可以选。看到 SMP 终于发布——好吧，不只是 FreeBSD 5 里发布，而是终于在 FreeBSD 6 里能用。我的多数记忆都是 BSDCan 这样的会议，BSDCan 起初是临时凑起来的，我去那儿感觉，哇，能看到所有老朋友。 **Benedict**：是的，破纪录。 **Kirk**：还有 EuroBSD 之类。它起初是 EUUG，后来分叉成几个组，最终成了 BSD 会议。他们能搬来搬去的模式很棒。亚洲一开始也搬，但问题是每次都要从零开始，所以会有办得不好的会议，因为他们真不知道自己在做什么。 欧洲一群人创建了 NUUG Foundation，管理会议场地承诺、注册后勤和资金。这就是会议能在城市间搬动的原因，组织者只需专注于本国后勤和拼凑议程。 总在一个地方，就没有本地吸引力。比如在东京，我大概只能每四五年教一次课，因为得积累足够的新学员。但在欧洲，我可以每年都教，因为换个国家就有一大堆新的本地人想上。这就行得通。 **Benedict**：我喜欢看到 commit 邮件背后的人脸，喜欢社区建设、与人见面。 **Allan**：每次收到他们的邮件，你脑子里都是他们的声音在读。 **Kirk**：是的。 **Allan**：这在沟通上差别很大，因为模糊的话也往往往好的方向去理解。 **Benedict**：是的，你前面提到 SMP 工作，你对项目有没有最钟爱的里程碑？ **Kirk**：对我有意思的里程碑是把 soft updates 弄进系统，还有我直接或间接参与的一些技术工作最让我难忘。 但那主要是因为我直接参与了它们。 **Allan**：我知道 64 位 inode 号——这搞了挺久。 **Kirk**：是的，但那个最后成了，因为我找到了那个最固执的人，把他拉了进来。他一参与进来，就不固执了，把事情做成了。我觉得有意思的地方又回到了人际，你认识一个人，能搞清楚他怎样最高效。 **Allan**：是的，或者你怎么让信息从他的角度讲得通。 **Kirk**：或者有时是说服别人，他们的观点是对的。他们可能不太会表达。而做“老人家”的一个缺点是，我说什么都对，即使完全是胡扯。所以，我尽量不说完全是胡扯的话，但我会经常找那些在社区里待得不够久、想法没法被人听到的人，给推一把。 **Allan**：给论据加点分量？ **Kirk**：对。我说你应该认真听听 Allan 在说什么，他有些好主意，这么做才对，大家会说，哦，对，我之前没真想过。然后他们来找你、和你交流，一旦交流起来，你很擅长说明自己的想法为什么好，事情就启动了。 所以，很多时候我就在这些会议上走来走去和人聊天，听到好主意，心里记下要和他们多接触，把他们和社区联系得更紧一些。特别是非 committer。 **Allan**：是的。 **Kirk**：有个人给我发了一个六年前的 bug 报告，没人真在意，我就去看源码控制里都有谁。报 bug 的人附了能用的补丁，而且一直为新系统更新。我说，放进去吧。就放进去了。就是这种小事，我的一封邮件能让好事情发生。我喜欢利用这一点。其实如今我贡献的更多是这些，而不是代码。 **Allan**：对。 **Benedict**：我们谈了项目本身、社区以及社区选出的 core team。还有你参与的 FreeBSD 基金会。它在某些方面也是项目健康的关键吗？ **Kirk**：无疑是。看看 FreeBSD 项目是怎么起步的。最早的发行由 Walnut Creek CD-ROM 完成。他们付钱给首批开发者，让他们全职做这件事，这是巨大进步，但不可持续，因为我们需要更多基础设施和网络连接。 又有点幸运地，我们靠上了 Yahoo。他们什么都用 FreeBSD，机器齐全。他们提供我们的基础设施，持续了——我不确定——十多年。 **Allan**：我觉得现在还在用。 **Kirk**：某种程度上还在。 **Benedict**：当然。 **Kirk**：但问题是，Yahoo 哪天决定换 Linux 怎么办——他们正在换。 **Benedict**：或者换盒子，或者其他什么。 **Kirk**：是的，……whatever。突然我们的基础设施就没了。Justin Gibbs 把这看作了问题。他意识到 FreeBSD 项目需要某种方式资助至少基本的基础设施。于是他创办了 FreeBSD 基金会，过了五到八年才有足够收入考虑基础设施之类的基本东西，事实上我们最近四五年才完全切过去。过程很慢。但 Yahoo 今天消失了，我们也没事。 项目通过 GitHub 或 Apache Foundation 这类组织获取基础设施的方式有很多。FreeBSD 项目设立了自己的基金会。有自己的基金会而不是挂在 Apache 下面，我们对事情如何运作有更多控制权，这有好有坏。但总体上，FreeBSD 基金会是重要的基石。 我想项目最大的担心是 FreeBSD 基金会想接管。至今 FreeBSD 基金会一直努力把自己定位为受项目目标驱动，而不是驱动项目。但 FreeBSD 基金会重要，非常重要。 **Allan**：是的，同时 FreeBSD 基金会和 core 通常也是能贡献最多的人。两边都从同一批人里挑，所以重合在所难免。 **Benedict**：对。或者要社区足够信任，才会说，好，那个人该做我的声音、我的代表。 **Kirk**：所以我想，Linux 是恐龙，FreeBSD 是哺乳动物。陨石砸下来，哺乳动物接管。但我甚至不确定我真希望那一天到来，因为如果我们成了主导，那我们就该走下坡路了。 **Benedict**：是的，所以总保持低调，但在大池塘里和其他人一起游。 **Allan**：而且，FreeBSD 要完蛋的传言夸大其词了。部分原因是 FreeBSD 的使用方式人们不知道、注意不到它在那儿，甚至 FreeBSD 项目自己都不总能知道 FreeBSD 被用了多少、怎么被用。 **Kirk**：是的，FreeBSD 基金会收到一些意外捐款，来自我们完全不知道在用 FreeBSD 的公司。我们会想，他们为什么捐款？所以第一件事就是和捐款方说，我们想把你列到 FreeBSD 用户名单上。有几个说，哦，不不不，绝对不行。我们用 FreeBSD 这件事是商业机密。他们不想宣传。 **Allan**：是的。 **Kirk**：还有些公司其实在用，但对外宣称是 Linux 阵营。他们不想失去 Linux 阵营的形象。但事情就是这样。 **Allan**：那么，你认为 FreeBSD 未来会走向何方？ **Kirk**：嗯，这又回到刚才那个。我觉得它根基很牢。我觉得我们不能想当然。公司会失败、会没落。Yahoo 长期是我们的金字招牌，现在不那么亮了。部分原因是他们不再是清一色的 FreeBSD 阵营，也因为他们在商业上势头减弱。 所以我们要持续出去布道，吸纳新公司、新人。但我认为我们做得相当成功。我觉得我们要进更多大学，正在尝试，也有一些成绩。我其实对 Philip Paeps 的努力很感兴趣。他去非洲、亚洲和各种你平时不太会想到的地方开会。FreeBSD 在那里用得不少。Philip 在到处布道 FreeBSD。 **Benedict**：那挺有意思。 **Allan**：让我想起 90 年代中后期，几乎每家 ISP 都用 FreeBSD，因为那是搭建可靠拨号服务器最便宜的方式。我们看到一些发展中国家，FreeBSD 又是答案了。我们只要做对的事抓住机遇。 **Allan**：因为 Linux 还没进入这些市场，我们抢先进去，就没必要换。 **Benedict**：从操作系统角度看，它是 UNIX，演化了几十年，能适应不同系统、不同环境、不同架构。 **Allan**：是的，或者容器这个概念其实是 FreeBSD 上发明的，虽然它在别处发扬光大。问题部分在于——我们有时有个坏习惯，做到 90% 就差最后一点，没把它产品化。 **Kirk**：是的，俗话说，先驱中箭，后来者得地。 **Allan**：是的。 **Kirk**：不幸的是，我们做先驱太多。 **Allan**：是的。 **Kirk**：但我觉得我们要在未来成功，有些事很重要。我们要有容器方案，要能跑在云上。我们能在 EC2 上——一等公民，在 EC2、Azure 等上——这很重要。 另外要吹响自己的号角。Android 大家都说——哦，Android 全是 Linux。是，它是 Linux 操作系统，但上面几乎整个用户层都是 BSD，因为 GPL 不适合用户层程序。GPL 设计上就迫使包含其代码的应用开源源码。 我们在很多不为所知的地方。我觉得我们要多推一推让人们知道。 **Allan**：是的，但你说对了，大学这块我们要更努力推，才能接触到下一代人。 **Kirk**：对，年轻人有个好处，喜欢和父母不一样。如今他们的父母是 Linux。 **Benedict**：是的！而且要给他们正确的工程技能，教他们怎么调试，或者其他有用的技能，不局限于这一个领域，还能用到很多其他领域。 **Allan**：嗯，所以我觉得 Teach BSD 项目对大学层面很重要——不是在玩具操作系统环境里学计算机科学概念，而是用一个能在真实计算机上跑、做真实工作的真实操作系统，这很重要。 **Kirk**：是的，那种玩具操作系统慢慢淡出了。但他们大多在学 Linux。可 Linux 如今太庞大复杂，很难理清头绪，而 BSD 的体量还能让你理解。 **Allan**：同时它更可观测。我们有合适的工具能真正看到内部部件运转。 **Kirk**：是的。 **Allan**：有些机器是角落里吵闹的大黑盒，但你看不见里面在干啥。 **Kirk**：是的，像 DTrace 在 FreeBSD 上就比 Linux 上先进得多。今天我看了 DWatch 那场演讲，是 DTrace 的精彩封装，让大众也能用。你甚至不必理解 DTrace 在干什么。 **Allan**：难的是想出该问的问题，而不是找答案。我们有很多工具找答案。但得由你决定问题是什么。 **Kirk**：对，但问题是 DTrace 有点像回答问题的汇编语言。好吧，我有这个问题。但我要写一个 100 行的程序才能回答。而 DWatch 这种是，嗯，我有这个问题，10 行代码，我就能得到图形化答案。 **Benedict**：这对年轻人也有吸引力，他们喜欢更花哨的东西，比如颜色和动画。 **Kirk**：所以我很激动看到这类东西，因为我觉得——这又能吸引更广的人群。 **Benedict**：好。 **Allan**：是的。 **Benedict**：那么，谢谢你接受访谈，希望未来 25 年再见。或者希望比那更早！ **Kirk**：好，嗯，五分钟也行，没问题。 --- # 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/20191112-wang-luo-xu-ni-hua/an-interview-with-kirk-mckusick.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.