1993 年，游戏开发公司 id Software 发行了一款第一人称射击游戏 《 毁灭战士 DOOM 》，游戏一经发行迅速爆火。在今天看来，《毁灭战士》可谓有史以来最具影响力的游戏之一。

《毁灭战士》发行之后的第十年（2003 年），记者 大卫·库什纳 David Kushner 出版了一本关于 id Software 的书，书名为《 Doom 启示录 Masters of Doom 》，后被奉为记录毁灭战士创作史的典范读物。几年前我曾读过这本书，如今内容已记得不太真切了，但是书中有一个关于 id Software 首席程序员 约翰·卡马克 John Carmack 的故事，我印象特别深刻。这里只对故事做粗略描述（具体情节请往下阅读）。实际上，早在《毁灭战士》开发前期，卡马克就发现自己为这款游戏编写的 3D 渲染器在渲染某些关卡时慢得像爬一样。对于《毁灭战士》这一对动感和速度有着相当高要求的射击游戏来说，这是一个非常严重的问题。意识到了这一问题的严重性，卡马克需要一个更加有效的渲染算法，于是他开始阅读相关论文。最后，他实现了一种叫做“ 二叉空间分割 binary space partitioning （BSP）”的技术，极大地提升了《毁灭战士》游戏引擎的运行速度，而这项技术此前从未用于电子游戏当中。

一直以来，我对这个故事的印象十分深刻。卡马克将学术前沿研究运用于电子游戏之中，我觉得这正是他之所以成为传奇人物的原因。无论从哪个角度来看，卡马克都应该是电子游戏行业中人尽皆知的典型的天才程序员，只不过上面这个故事是我最先能够想到的理由。

显而易见，“二叉空间分割”这个术语听起来就是难度相当高的课题，能够自行阅读论文并将其付诸实施实属不易，所以这个故事给我留下了深刻的印象。我一直认为卡马克的做法十分具有创见性，不过由于我既不懂二叉空间分割到底是怎样的一项技术，也不晓得这项技术在当时究竟有多么革新，所以我也并不确定自己的观点是否正确。如果按照从 霍默·辛普森 Homer Simpson （LCTT 译注：《辛普森一家人》中的那个老爹）到 阿尔伯特·爱因斯坦 Albert Einstein 的顺序为天才列出一套级别体系，那么卡马克将二叉空间分割技术运用于《毁灭战士》的做法究竟属于什么级别的天才之举呢？

同时，我也在想，二叉空间分割这个概念最初是从哪儿来的，又是怎样吸引到卡马克的？因此，本篇文章不仅仅会讲述约翰·卡马克和《毁灭战士》的故事，也会探讨二叉空间分割树（BSP 树）数据结构的发展历史。有意思的是，BSP 树和计算机科学领域其他许多技术一样，最初都起源于军事研究领域。

没错，《毁灭战士》的第一关卡 E1M1 就受到了美国空军的启发。

VSD 难题

BSP 树是计算机图形领域最具挑战性难题的解决方案之一。举个例子，为了渲染出三维场景，渲染器必须能够区分在一个特定角度下的可见物体和不可见物体。如果渲染时间比较充足，这一要求也算不上大问题；但是就理想情况来说，实时游戏引擎在 1 秒内至少需要完成 30 次区分任务。

这一问题有时被称为 可见面检测 visible surface determination （VSD）问题。后来与卡马克合作开发《 雷神之锤 Quake 》（id Software 继《毁灭战士》之后开发的游戏）的程序员 迈克尔·亚伯拉什 Michael Abrash ，在自己的著作《 图形程序开发人员指南 Graphics Programming Black Book 》 中写道：

我想探讨一下在我看来 3D 中最棘手的一个问题：可见面检测问题（在每个像素点上绘制合适的表面）以及与之密切相关的隐面消除问题（迅速去除不可见的多边形，用于加快可见表面检测速度）。简略起见，我将在下文采用缩写 VSD 来表示可见面检测和隐面消除。

为什么我会认为 VSD 是 3D 中最棘手的问题呢？尽管纹理映射等光栅化问题更让人感兴趣而且也更重要，但是相对而言，它们是范围相对有限的任务。随着 3D 加速器的出现，它们逐渐被转移到硬件中。同时，它们只随着屏幕分辨率的增加而增加，而分辨率的增加是相对温和的。

相反，VSD 却像是一个无底洞，目前应对方案也有很多。但实际上，在采用简单的方法处理 VSD 时，其性能会直接受到场景复杂程度的影响，而场景的复杂程度通常会以平方级或立方级的形式增大。所以在渲染过程中，VSD 很快就会成为制约因素。 ^[1]

亚伯拉什是在上个世纪九十年代末写的关于 VSD 问题的这些困难，这是在《毁灭战士》之后数年，这款游戏证明了普通人盼望着能用自家电脑玩很吃图形配置的游戏。九十年代早期，id Software 成立后发行了一些游戏。尽管当时的计算机还只是用来处理文字与表格或者执行其他任务，未尝想过要在上面运行游戏，id Software 必须对发行的游戏进行编程，使其能在计算机上流畅运行。为了实现这一飞跃，尤其是为了能让在《毁灭战士》之前 id Software 发行的少数 3D 游戏在电脑上运行，id Software 必须做出革新。在这些游戏中，所有的关卡在设计时都受到了一定限制，以便更容易解决 VSD 问题。

例如，在《毁灭战士》之前，id Software 发行了《 德军总部 3D 版 Wolfenstein 3D 版 》，该游戏的每一个关卡都是由与坐标轴平齐的墙壁组成。换言之，在《德军总部 3D 版》的游戏画面里，你看到的只有南北方向或者东西方向的墙壁。在游戏中，墙壁与墙壁之间有着固定的间隔，所有过道的宽度或是一个方格，或是两个方格等等，但绝不会出现 2.5 个方格。如此一来，尽管 id Software 团队只能设计出外观十分相似的关卡，但这也让卡马克为 《德军总部 3D 版》 编写渲染器的工作简单了不少。

通过将屏幕上的光线“齐射”入虚拟游戏世界，《德军总部 3D 版》的渲染器解决了 VSD 问题。通常来说，使用光线的渲染器叫做“光线投射”渲染器。这种渲染器的速度一般较慢，因为解决内部的 VSD 问题涉及到在光线和游戏中的物体之间找到第一个交点，这通常需要进行大量的计算。但在 《德军总部 3D 版》，由于所有的墙壁都与网格平齐，所以光线与墙壁相交的位置只能在网格线上。如此一来，渲染器只需逐个检查这些交点即可。如果渲染器先从离玩家视角最近的交点开始检查，接着检查下一个最近的交点，以此类推，最后遇到第一面墙壁时停止检查。这样，VSD 问题便轻而易举地得到了解决。光线从每一个像素点向前投射，与画面物体接触时停止，这一方法是可行的。因为从 CPU 资源来看，投射的成本很低。事实上，由于每面墙壁高度相同，因此针对同列的像素点，投射的光线只需一条。

尽管当时还没有专业的图形显卡，《德军总部 3D 版》凭借这一取巧之法得以在配置较低的个人电脑上正常运行起来。然而，这个办法并不适用于《毁灭战士》。因为 id Software 为这款新游戏增添了许多新元素 —— 倾斜的墙面、楼梯以及高低不一的天花板。光线投射的办法自然也就不好用了，于是卡马克编写出了一个新的渲染器。《德军总部 3D 版》的渲染器关注的是图像，将光线投射到屏幕像素表示的列上，而 《毁灭战士》 关注的则是物体。换句话说，《毁灭战士》 的渲染器会记录游戏场景中的所有物体，继而将其投射到屏幕当中；而非记录屏幕上的像素点，判断每个像素点的颜色。

对于强调物体的渲染器来说，可以使用 Z 缓冲区来解决 VSD 问题，比较简单。每次将物体投射到屏幕上时，需要对每个用于绘制的像素点进行检查。如果你想绘制出的物体的部分和已经绘制在目标像素点上的物体相比更加靠近玩家，可以将其覆盖。否则，必须保持像素不变。尽管办法很简单，但是 Z 缓冲区对内存的要求较高，而且渲染器可能仍然要花费大量的 CPU 资源来投射玩家永远不会看到的水平几何体。

在 20 世纪 90 年代，使用 Z 缓冲区的方法还存在着其他缺陷：IBM 兼容机（PC）搭载的是一种叫 VGA 的显示适配器系统，在这类电脑上，将图像写入帧缓冲区的成本非常之高。因此，在只会以后被覆盖的像素上绘制花费的时间拖慢了渲染器的性能。

考虑到将图像写入帧缓冲区的成本非常之高，理想的渲染器需要首先绘制离玩家最近的物体，接着是比较近的物体，以此类推，直到屏幕上每个像素点都写入了信息。这时，渲染器会停止运行，大幅缩短远处不可见物体的渲染时间。这种由近及远对物体进行排序的方法也可以解决 VSD 问题。那么问题又来了：什么才是玩家可以看到的？

最初，卡马克打算依靠《毁灭战士》的关卡布局来解决 VSD 问题。首先用渲染器绘制出玩家目前所在房间的墙壁，之后玩家冲进隔壁房间，再绘制出隔壁房间的墙壁。由于每个房间互不遮挡，这一办法也能解决 VSD 问题。而互相遮挡的房间可以分割成若干互不遮挡的“区域”。在 YouTube 上的一个 视频 中，Bisqwit 展示了自己制作出来的使用了相同算法的渲染器。可以看到，如果以超慢的速度运行，便能一睹渲染的具体过程。这一算法同样运用到了《毁灭公爵 3D 版》当中，这款游戏在 《毁灭战士》 推出三年之后发行，当时 CPU 的性能也更加强大了。1993 年，尽管在硬件上已经可以运行游戏了，但是使用这一算法的《毁灭战士》渲染器在复杂的层级结构上依旧表现吃力，尤其是在房间分割出来的各部分相互嵌套的情况下。不巧的是，这类层级结构正是构造环形楼梯等物体的唯一办法。沿着环形楼梯走下去，直到走入已经绘制好的区域，由于这其中涉及多次循环下降运动，导致游戏引擎的运行速度大幅降低。

在 id Software 团队意识到《毁灭战士》游戏引擎的速度可能过慢时，公司还面临着其他任务：将《德军总部 3D 版》移植到超级任天堂游戏机（简称“超任”）上。那时，超任的性能比 IBM 兼容机还要差。结果表明，尽管光线投射渲染器非常简单，但是想要在超任上快速运行是不可能的。于是，卡马克着手研究更为高效的算法。事实上，也正是为了顺利将《德军总部》移植到超任，卡马克首次研究了二叉空间分割技术，并将其付诸应用。由于《德军总部 3D 版》的墙壁与坐标轴平齐，所以二叉空间分割技术应用起来也比较简单直接；但是《毁灭战士》的情况则比较复杂。不过，卡马克发现，二叉空间分割树同样可以用来解决《毁灭战士》速度过慢的问题。

二叉空间分割

二叉空间分割 binary space partitioning （BSP）会提前将 3D 场景分割为若干部分，使 VSD 问题易于解决。讲到这里，你需要先了解一下为什么分割场景可以奏效：如果你在场景上画条线（对应三维空间里的一个平面），你就可以指出玩家或者摄像机视角在这条线的哪一侧，在这条线另一侧的物体无法遮挡玩家所在一侧的物体。如果多次重复这一操作，该三维场景最终会被分割为多个区域，这并不是对原始场景的改进，只是现在你知道了更多关于场景的不同部分会如何相互阻挡。

首次阐述上述三维场景分割的是美国空军的研究员，他们曾尝试向美国空军证明计算机图形已经非常先进，可以应用到飞行模拟器领域。1969 年，他们将研究发现发表在一份题为《计算机生成图像在图形仿真中的应用研究》的报告中。该报告的总结部分指出，计算机图形可用于训练飞行员，但也警告说，其实际应用可能会受制于 VSD 问题：

实时图像处理需要解决的一个关键问题就是优先级问题，或称隐藏线问题。在我们平时用眼睛观察外界时，大自然替我们轻易地解决了这一问题：不透明物体上的一个点，掩盖了同一视觉方向上、且距离较远的所有其它物体。但在计算机中，这项任务却非常困难。图像处理需要解决的优先级问题，随着环境复杂程度的增加，计算量会呈指数级增长，随即就会超过绘制物体透视图所需的计算负载。 ^[2]

他们在报告中提出了一项基于构造“遮挡矩阵”的方案，这一方案据说早些时候曾被应用于 NASA 的项目当中。研究员指出，平面将场景一分为二，可用来解决平面两侧物体之间存在的“任何优先级问题”。通常情况下，可能需要明确将这些平面添加到场景中，但对某些几何体，只需借助你已经拥有的几何体的表面即可。他们举了一个例子，如下图：p ₁、p ₂ 以及 p ₃ 是三个不同的平面，如果摄像机视角位于其中一个平面的前方，即“正”面，p _i 的值就等于 1。这种矩阵展示出基于三个不同平面和摄像机视角位置的三个物体之间的关系 —— 如果物体 a _i 遮挡了物体 a _j，那么 a _ij 在此矩阵中的数值等于 1。

研究人员指出，这种矩阵可以应用到硬件中，对每一帧进行重新评估。该矩阵基本上可以用作大型的开关，或者一种预置的 Z 缓冲区。在绘制给定的物体时，如果在物体所在列上得出数值 1，并且所在行已经在绘制中，那么物体被遮挡的部分就不会绘制出来。

不过，该矩阵方法的主要缺点在于，为了在场景中表示出 n 个物体，你需要一个尺寸为 n ² 的矩阵。于是，研究人员们继续深入，探究将遮挡矩阵表示为“优先级列表”的可行性，该列表的尺寸是 n，可确定物体绘制的顺序。他们随即发现，诸如上图此类场景根本无法确定顺序（因为它存在循环阻塞的现象）。因此，他们花了很多时间来阐明“合适”与“不合适”场景之间的数学区别。最后，他们得出了一个结论：至少对于“合适的”场景下，优先级列表是可以制作出来的；而对场景设计师来说，避免设计出“不合适”的场景也不是一件难事。但是，他们并没有说明如何生成该列表。可以说，这份 1969 年的研究的首要贡献在于提出了：至少，在 理论上，可以采用平面分割的方法，对场景中的物体进行渲染排序。

直到 1980 年，一份题为《基于优先级树结构的可见表面生成》的论文提出了解决该问题的具体算法。在这份论文中，作者 亨利·福克斯 Henry Fuchs 、 泽维·凯德姆 Zvi Kedem 以及 布鲁斯·内勒 Bruce Naylor 介绍了 BSP 树。他们指出，这种新的数据结构“可以替代十年前首次使用，但由于一些问题未得到广泛发展的方案”（即前文 1969 年美国空军相关研究中的方案）。 ^[3] BSP 树一经生成，即可用于确定场景中物体的优先级顺序。

三人在论文中对 BSP 树的工作原理给出了相当可读的解释。但在本文，我将尝试使用更加通俗的语言，介绍给大家。

首先，在场景中选定一个多边形，将该多边形所在的平面作为分割平面。同时，该多边形充当树的根节点。场景中剩下的多边形会分散在分割平面的两侧。位于分割表面“前方”或者与分割平面相交后位于“前”半部分的多边形落在了根节点左侧的左子树上；位于分割表面“后方”或者与分割平面相交后位于“后”半部分的多边形落在了右子树上。接着，递归重复这一过程：在左子树和右子树上各选定一个多边形，作为各自空间新的分割平面，继而二分出来更多的子空间和子树。等到全部的多边形均选定之后，二叉空间分割也就结束了。

假设你想由后向前将场景中的几何图形进行渲染。（这就是所谓的“ 画家算法 painter's algorithm ”。因为在绘制时，距离摄像机较远的多边形会被距离摄像机较近的多边形所覆盖，借此正确进行渲染任务。）如果想要实现这一算法，必须按顺序遍历 BSP 树，左右子树的渲染顺序由摄像机视角与节点所在分割平面的位置关系决定的。因此，针对树上的每个节点，首先渲染距离分割平面较“远”一侧的所有多边形，接着是位于平面上的多边形，最后是距离平面较“近”一侧的所有多边形 —— “远”与“近”相对于摄像机视角而言。根据前文，距离分割平面较远一侧的多边形无法遮挡近侧的物体，所以这种方法可以解决 VSD 问题。

下图表示一个简单的二维场景的 BSP 树的构造与遍历过程。在二维中，分割平面变成了分割线，但就基本原理而言，与复杂的三维场景并无二致。

第一步：根分割线落在 D 墙上，将剩下的几何图形分为两组。

第二步：继续分割位于 D 墙两侧的空间。C 墙是其中一侧的唯一一堵墙壁，因此无需再分。另一侧，B 墙形成新的分割平面。因为 A 墙与新的分割平面相交，所以必须将其分割为两堵墙。

第三步：参照右上方视角，由后向前对墙壁进行排序，对执行画家算法很有帮助。这就是树的顺序遍历过程。

福克斯、凯德姆以及内勒多次强调了 BSP 树的优势：它只需构建一次。可能有些难以置信，但实际上无论摄像机视角位于何处，同一棵 BSP 树都可以用来渲染一个场景。只要场景中的多边形没有移动，BSP 树就不会失效。因此，BSP 树在实时渲染任务中非常实用 —— 构建树时的所有艰巨任务都可以在渲染工作开展之前完成。

同时，三人也提到了一项需要进一步深入研究的问题：究竟怎样才能构建出一棵 “高质量的” BSP 树？BSP 树的质量取决于用作分割平面的多边形的选择。我在前文跳过了这一问题，不过如果用作分割平面的多边形与其他多边形相交，那么为了让 BSP 算法发挥作用，必须将相交的多边形一分为二，这样两部分就可以分在不同的空间。但是如果这种现象反复出现，BSP 树的构建势必会大幅增加场景中多边形的数量。

内勒后来在其 1993 年的论文《构建高质量的分割树》中提及这一问题。卡马克的同事，id Software 的共同创始人 约翰·罗梅洛 John Romero 指出，这篇论文是卡马克在《毁灭战士》中引入 BSP 树时读到的论文之一。 ^[4]

《毁灭战士》中的 BSP 树

别忘了，卡马克首次为《毁灭战士》设计渲染器时，通过让渲染器渲染玩家所在房间之外的临近房间，试图为关卡几何图形建立一套渲染顺序。对此，BSP 树是个不错的选择，因为在玩家进入之前的房间（区域）时，BSP 树能够避免让渲染器重复劳动，从而节省 CPU 资源。

实际上，“将 BSP 树引入《毁灭战士》”意味着将 BSP 树生成器引入《毁灭战士》的关卡编辑器中。当完成一个《毁灭战士》的关卡的制作时，BSP 树就会在关卡几何图形的基础上生成。根据程序员 法比安·桑格勒德 Fabien Sanglard 的说法，在原版《毁灭战士》中，一个关卡的 BSP 树生成时间需要 8 秒，全部关卡合计共需 11 分钟 ^[5] 。之所以生成时间较长，部分原因在于卡马克所用的 BSP 生成算法，该算法尝试使用各种启发式方法找出 “高质量” BSP 树。在运行时，8 秒的延时可能让人无法接受；但是离线等 8 秒，时间并不算长，尤其是考虑到 BSP 树提升了渲染器的性能。为每个关卡生成的 BSP 树将在游戏启动时作为关卡数据载入。

卡马克对 1980 年论文中提出的 BSP 树算法进行了改造，因为在《毁灭战士》开始运行时，当前关卡的 BSP 树就会读取到内存中，渲染器通过 BSP 树由前向后绘制物体，而非由后向前进行绘制。福克斯三人在那篇论文中演示了 BSP 树可用于执行由后向前的画家算法，但是画家算法会造成许多重复的绘制任务，对于 IBM 兼容机来说负担较大。因此，《毁灭战士》的渲染器换了个方向，首先绘制距离玩家较近的图形，之后再绘制离玩家较远的。这种反向排序很容易通过 BSP 树来实现，因为你可以在树的每个节点都进行反向遍历。为了避免绘制出来的远处图形遮挡到近处的图形，《毁灭战士》的渲染器使用了一种隐式 Z 缓冲区，这种缓冲区不仅具备普通 Z 缓冲区的优势，而且对内存的要求也较低。这种 Z 缓冲区有两组数组，一组记录水平方向的遮挡关系，另两组记录自屏幕顶部和底部的垂直方向的遮挡关系。《毁灭战士》的渲染器就算不使用实际的 Z 缓冲区也无伤大雅，因为从技术上来看它并不是真正的 3D 游戏。BSP 树数据结构的成本虽然不高，但却能够起作用，其原因在于《毁灭战士》不会发生以下问题：水平方向的遮挡数组能够发挥作用，是因为该游戏中没有倾斜的墙体；垂直方向的遮挡数组能够发挥作用，是因为该游戏不存在有着一上一下两扇窗户的墙体。

剩下比较棘手的问题是如何将《毁灭战士》中处于运动中的角色融入到借助 BSP 树绘制的静止的关卡几何图形中。该游戏中的敌人不可能纳入 BSP 树之中，因为他们会移动，而 BSP 树只对静止的几何形状起作用。所以渲染器首先绘制静止的关卡几何图形，同时与另一个内存使用效率较高的数据结构协作，记录屏幕上分割出来用于绘制的区域。之后，渲染器按照由后往前的顺序绘制敌人，并消除被屏幕上的区域遮挡住的敌人。这一过程与使用 BSP 树进行渲染相比，效果稍差一些。但是由于关卡中能看到的敌人的数量少于几何图形的数量，所以速度并不是一个严重的问题。

将 BSP 树应用到《毁灭战士》中可谓一大成功。卡马克能够想到 BSP 树是解决 VSD 问题的最佳方案，无疑非常高明。但是这可以称得上是天才之举吗？

桑格勒德在其关于《毁灭战士》游戏引擎的书中引用了罗梅洛的话：内勒的论文《构建高质量的分割树》主要讲述使用 BSP 树消除 3D 模型的背面。 ^[6] 根据罗梅洛所言，卡马克认为这种算法对《毁灭战士》依然有效，所以他放手一试，将 BSP 技术应用到了该游戏中。不过这话说得有些奉承的意味 —— 意在暗示卡马克在别人仍然使用 BSP 树渲染静止的场景时，发现该技术可以用于实时游戏领域。在《Doom 启示录》中也有给卡马克戴高帽的故事。该书作者库什纳认为，卡马克在阅读内勒的论文之后，问了自己，“如果使用 BSP 技术创造一整个虚拟世界，而不仅仅是一张 3D 图像，会怎么样呢？” ^[7] 。

这些“片面之词”忽视了 BSP 树的发展历史。当美国空军研究人员开始意识到场景分割可能会加快渲染任务的时候，他们就对提升 实时 渲染的速度产生了兴趣，毕竟他们当时试图创建一个飞行模拟器。1980 年，同样的案例再次出现在了福克斯等人的论文中，他们探讨了 BSP 树如何应用于飞行模拟器中，帮助飞行员进行训练：飞行员用它来反复练习将飞机降至同一空港。由于空港的地形不会发生改变，BSP 树只需生成一次，即可一劳永逸。很明显，他们考虑的是实时模拟。在论文的引言部分，福克斯等人还谈到实时图形系统必须在至少 1/30 秒内生成一张图像，由此激励了他们的研究。

因此，卡马克不是第一个想到在实时图形模拟中应用 BSP 树的人。诚然，设想与付诸实践是两码事。但是即使在实施的过程中，卡马克受到的帮助与指导可比人们想象的要多得多。至少是到这篇文章写成之时，BSP 树的 维基百科词条 页面显示，卡马克参考了 1991 年 陈 Chen 和 戈登 Gordon 的一篇论文，以及 1990 年的一本教材《计算机图形学：原理及实践》。尽管该页面并未提供引用信息，但可信度没什么问题。陈和戈登的论文介绍了运用 BSP 树由前向后的渲染方法，这种方法与《毁灭战士》中用到的方法基本一致，还包括了我称之为“隐式 Z 缓冲区”的数据结构，可用于防止远处的图形在绘制时遮挡近处的图形。《计算机图形学：原理及实践》详细介绍了 BSP 树，以及一些构建并展示 BSP 树的伪代码（非常感谢我大学的图书馆，让我能够一睹这本教材 1990 年的版本）。因为这本书是计算机图形学的经典之作，所以卡马克很可能也有一本。

然而，卡马克发现自己遇到一个新问题：如何让第一人称射击游戏在一台 CPU 甚至都无法进行浮点操作的电脑上运行呢？通过调查研究，他证明了 BSP 树的数据结构非常适用于实时电子游戏渲染。尽管 BSP 树早已提出，而且到了卡马克的时代，相关理论已经非常成熟了，但我始终认为，卡马克的做法可谓惊人之壮举。也许，得到人们称誉的应该是整个《毁灭战士》的游戏引擎，它的确非常精致。我在前文也提及过，但是桑格勒德的《 游戏引擎黑皮书：毁灭战士 Game Engine Black Book: DOOM 》 很好地讲解了这款游戏引擎的非凡之处，以及这些优势相互契合之法。要明白，VSD 问题只是卡马克在编写《毁灭战士》游戏引擎时需要解决的诸多问题之一。不得不说，面对不为大多数程序员所知的复杂的数据结构，卡马克能够查阅相关文献，将其付诸实践，仅此一点就足以说明其技术之精湛、匠心之独到。

如果你喜欢这篇文章，欢迎关注推特 @TwoBitHistory，也可通过 RSS feed 订阅，获取最新文章（每四周更新一篇）。

1. Michael Abrash, “Michael Abrash’s Graphics Programming Black Book,” James Gregory, accessed November 6, 2019, http://www.jagregory.com/abrash-black-book/#chapter-64-quakes-visible-surface-determination. ↩︎
2. R. Schumacher, B. Brand, M. Gilliland, W. Sharp, “Study for Applying Computer-Generated Images to Visual Simulation,” Air Force Human Resources Laboratory, December 1969, accessed on November 6, 2019, https://apps.dtic.mil/dtic/tr/fulltext/u2/700375.pdf. ↩︎
3. Henry Fuchs, Zvi Kedem, Bruce Naylor, “On Visible Surface Generation By A Priori Tree Structures,” ACM SIGGRAPH Computer Graphics, July 1980. ↩︎
4. Fabien Sanglard, Game Engine Black Book: DOOM (CreateSpace Independent Publishing Platform, 2018), 200. ↩︎
5. Sanglard, 206. ↩︎
6. Sanglard, 200. ↩︎
7. David Kushner, Masters of Doom (Random House Trade Paperbacks, 2004), 142. ↩︎

via: https://twobithistory.org/2019/11/06/doom-bsp.html

作者：Two-Bit History 选题：lujun9972 译者：aREversez 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在中国，有各种节日，有各种情人节。

最早是从西方传来的所谓公历 2.14 的“情人节”，后来又有了 3.14 的“白色情人节”。然后，人们觉得这些节的洋味太重，何不把中国的农历七夕当成中国传统的情人节呢？而随着二次元一代，谐音梗也开始流行，不知道是谁滥觞，5.20 也被当成了一种情人节，因为谐音是“我爱您”。

前几天，我的朋友 Paulus Wren 跟我说，有位内核开发者在 Linux 内核邮件列表中向 Linus Torvalds 请求，将刚刚准备进位到 6.0 的版本号在 5.20 上停留一次，他认为这是一个在中国宣传 Linux 的好机会。就在前几天，Linus Torvalds 刚刚在邮件列表中 宣布 了 Linux 5.19 正式发布，并通告下一个版本准备“进位”到 6.0 了。

说起来 Linux 内核的版本号，比较有意思的是从 3.0 开始主版本号就没有什么特别的意义，只是当次版本号太大时，Linus 觉得过大的数字会让他困扰，因此就“进位”到主版本号了。比如，2.6.39 之后就是 3.0，3.19 之后就是 4.0，4.20 之后就是 5.0（之所以没有在 4.19 就开始进位，也许是 Linus 忘记了）。所以，按照这种不严格的 20 进制，该进位了。

这位名叫 Zhang Boyang（让我们称他为“张同学”）的内核开发者在内核邮件列表中向 Linus Torvalds 发起倡议：

您能不能考虑使用 5.20 作为下一个 Linux 版本号，而不是 6.0。“5.20” 这个数字在中文中是一个文字游戏，代表 “我爱您”，所以 “Linux 5.20” 在中文中可以被读作 “我爱 Linux”。

他认为，这可以引起一些广泛传播，可以宣传 Linux。这个 消息 传播到国内后，褒贬不一，有人认为这是一件有趣的事情，可以向更多不了解 Linux 的人宣传 Linux；也有人认为，这事太无聊了。

但是这封邮件并未带来什么影响，可能是它发出的时间恰逢周末，也没有得到 Linus Torvalds 的回复。

眼看过去了一周，合并窗口接近关闭了，看来修改版本号这件事希望渺茫，张同学 再次发出 了他的倡议，请 Linus Torvalds 考虑给该版本一个命名：

您能不能考虑将下一个 Linux 版本（5.20 或 6.0）命名为 “I love linux”？……即使下一个内核版本号是 6.0，我想对于讲中文的人和不讲中文的人来说，表达我们对 Linux 内核的爱可能都是一个好主意。

而历史上，Linux 内核的一些版本有特别的名称，比如 Linux 5.17 就被命名为 “Superb Owl”（“超级碗”的一个文字游戏）。

这一次，他的邮件得到了六位中国的 Linux 内核开发者的支持。但是，依旧没有得到 Linus 和其它国家开发者的回应。

在大家的回应中，有人对 5.20 这个节日做了进一步解释，以及表达了一个并不浪漫的已婚男人对各种情人节的紧张，并表示这样的 520 挺好，不需要专门准备礼物。也有人表示，这是内核列表里面一次较大规模的“文化输出”，就像我们对美国人的“超级碗”无感一样，外国人对我们的 520可能也没什么感受。

原本，我以为，这件事就此作罢了。不料 Linus Torvalds 在昨天发布 Linux 6.0-rc1 时，专门提到了这件事，他说，

如果你愿意，你可以继续叫它 “Linux 5.20”。

并且，Linus Torvalds 在这份公告里面再次重申了，主版本号变化并不代表有根本性的变化，他早就摒弃了“主版本号是有意义的”的说法了，而采用分层的版本号只是为了使版本号容易记忆而已。

老王觉得，张同学这件事办的很好，诸位在内核邮件列表回复的同学也很给力。说到底，我们对 Linux 就是一种热爱，为什么不借着各种可能的机会来宣传它呢？虽然，Linux 越来越用在各种严肃的场合，但是 Linux，乃至开源，其本底一直是一种极客文化，“Just for Fun”，所以，为什么不呢？虽然，由于文化差异，没有得到太多的回应，但是我们的“文化输出”才能让世界对我们有更多的亲近。

那么，你的看法呢？

另外，你认为这样的版本号有趣吗？你会向你的爱人（如果不是计算机的话）讲这个故事吗？为了这个有爱的版本号，你是否会为 Linux 内核或更广泛的 Linux 做些什么吗（比如去修个 Bug，让你的痕迹留在 Linux 5.20 中）？

（题图修改自：ninchanese.com）

近日，CentOS 社区委员会成员 Brian Exelbierd 和 Thomas Oulevey，以及 Linux 中国开源社区创始人王兴宇，跨越多个时区，远程进行了一场对话，讨论了 CentOS 社区和操作系统领域的创新与发展趋势。

开源朗读者：淮晋阳

主持人：王兴宇，Linux 中国开源社区创始人

Brian Exelbierd，开源布道师，社区和开发者业务策略师

Thomas Oulevey，CentOS 社区委员会成员

注：Thomas 和 Brian 都是 CentOS 社区委员会成员。此外，Thomas 在欧洲核子研究组（CERN）工作，是控制组的系统工程师，更多请见他在 CentOS 社区官网上的 简历。

现场翻译：璐璐，文字翻译：家驹，文字整理：老王

以下是本次访问内容：

Thomas：大家好，我叫 Thomas，我从 2012 年左右就在 CentOS 社区工作，从基础架构相关的工作开始，后来负责组织CentOS Dojo（译者注：CentOS Dojos 是一个为期一天，或偶尔为 2 天的活动，它将 CentOS 社区的人们聚集在一起，讨论系统管理、最佳实践和新兴技术），致力于帮助人们更好地融入社区，创造良好的氛围，让大家可以更开心的从事社区相关的工作。好，现在交给 Brian。

Brian：大家好，我叫 Brian，我参与社区的经历和 Thomas 差不多。我很积极地投入到企业级 Linux 社区的工作已经有六七年时间，在那之前我更多的是企业级 Linux 的被动使用者，作为社区贡献者偶尔也对企业 Linux 社区有些贡献。事实上现在我是在红帽工作，我负责 RHEL 的业务战略，但今天我出现在这里，是因为我的另一个身份是 CentOS 社区董事会的红帽联络员。同时，我也参与过大量的社区工作，包括做过 Fedora 社区架构师，积极地参与过 Fedora 项目以及 CentOS项目的很多活动。

王兴宇：两位好，各位参加会议的朋友你们好。首先非常感谢红帽公司搭建这个渠道，让我们 Linux 中国可以和 CentOS 社区的负责人进行面对面沟通，也非常感谢翻译璐璐做全程翻译，辛苦了。我是 Linux 中国开源社区的创始人王兴宇，从业互联网二十余年，曾经担任过中国电信的高级专家，这些年主要从事开源文化和开源技术的公益推广。

今天主要沟通的内容是关于后 CentOS 时代的一些话题。CentOS 停止维护，而以 CentOS Stream 替代的这两年来我们称之为“后 CentOS 时代”，这件事对开源服务器操作系统市场影响很大，业界和用户也存在一些误解和迷茫的地方，这也是我今天请两位来一起沟通的主要原因。以下是我们的一些提问，请两位发表你们的见解。

首先，我们来回顾一下两年前的历史背景。历史上 CentOS 和红帽的关系如何？CentOS 在红帽的产品线中的定位什么样？请两位帮忙回答一下。

Brian：我来回答一下这个问题，CentOS 项目，从红帽的角度来看，和我们有一个非常有趣的历史渊源。众所周知，大概 7 年前，我们收购了 CentOS 这个品牌，雇佣了 CentOS 项目的工程师，这就是红帽和 CentOS 项目的关系。我们这么做的目的是提供一个平台给某些特定的高级开发（比如虚拟化）、运行于操作系统之上的其它工具等组件开发，我们希望借此鼓励这些项目（虚拟化、其它工具）能够以开源项目的方式健康发展。

随着时间的推移，事情逐渐发生了一些变化，就像这个世界也在不断演进和发展一样，我们逐渐意识到那些上层项目越来越依赖于底层操作系统的变化。我们发现 CentOS 正好可以作为这个底层操作系统，是一个可以孵化其他项目的很好的地方。借此，我们可以在做 RHEL 开发的同时，也去做 RHEL 之上其他组件（虚拟化、工具等）的开发，与广大社区开发者一起，每个人都可以促进底层操作系统与上层组件的协调发展。这就是我们发展 CentOS 项目，并大概在 3 年前提出 CentOS Stream 的原因。

关于第二个问题，红帽对待 CentOS，始终保持着“一臂”的距离，这就意味着，红帽不去控制 CentOS 所做的事情，除非遇到一些挑战，比如法律相关的风险，我们只是为 CentOS 提供更多的资源，我们也不认为 CentOS 就是红帽产品线的一部分。从红帽产品线的视角来看，CentOS 不是红帽的产品，红帽不提供对 CentOS 的支持，我们不对 CentOS 提供保证，我们也不对 CentOS 使能。也就是说，CentOS 确实对红帽的产品很重要，因为我们所做的所有工作都是基于开源的代码库，所以我们需要这个项目，来产品化这部分代码。所以你可以看到，我们的 RHEL 就是基于 CentOS Stream 而制作出来的。

王兴宇：如上所述，CentOS 关闭或者说 CentOS 停止服务支持的这个决定，应该是 CentOS 社区自己做出来的。我想知道是什么原因促使 CentOS 社区做出来关闭 CentOS，并且发展出来 CentOS Stream 这样一个决定的？

Thomas：好，我会从 CentOS 社区的角度回答一下这个问题。我大概三年前加入 CentOS 董事会，当时大家在讨论如何提高对 CentOS 社区的参与度问题，如何给用户更好的使用体验，当时提出来很多提议，最后大家认为 CentOS Stream 是我们在未来的一个正确的努力方向，通过这种模式可以提高 CentOS 的社区参与度。CentOS Stream 的模式对社区版的企业级操作系统发展（译注：CentOS 是 Community Enterprise OS 的缩写）也至关重要。总体来讲，之所以会做出这样一个决定，就是想要改善社区的参与度。谢谢。

王兴宇：那么，我想知道，在做这样决定的时候，社区内部有没有反对意见？最大的反对意见是怎么样的？你们怎么平衡这样的反对意见的？

Brian：我来先回答一下，等一下 Thomas 再来补充一下。首先，我们了解一下 CentOS 社区的治理模式对回答这个问题很重要。CentOS 的治理模式和很多其他开源项目的运作模式有所不同。CentOS 有一个治理委员会（董事会），这个治理委员会需要每个人都对一个新的决策达成共识才可以，只是大多数人同意，有少部分人反对，是不行的。这个共识可以是 Yes，也可以是 No，甚至可以是中立的意见，都没问题，但是强调的一点是这个决议必须是董事会一致的共识。我本人当时也是在对话的房间当中的。

其实另外一个我想说的就是，我们在整个的对话沟通的环节当中，不会去探索董事会中的每一个个人的意见，总之我们最后要听的是董事会作为一个整体它的一个一致性决议是什么样的。另外我想说的就是，现在这个董事会其实还在进行提名，也就是说任何人对这个职位都是可以来申请的，只要你觉得你合适，你现在就可以申请。好，交给 Thomas。

Thomas：我也再说两句，我们的整个社区其实唯一有一个目的，也就是说，希望 CentOS Stream 的社区变得越来越开放，越来越好，真的实现我们完全意义上的开源的模式，所以在这样开放的讨论当中，包括开发者的讨论当中当然有一些人会有不同意见，这是很正常的事情。但是就像 Brian 刚刚说的，我们的目的是所有的董事会成员必须要达成一致意见，这个一致意见必须是对于整个社区未来有更好的或者说最佳的用户体验，所以我认为实际上这是非常重要的一点，我们也是从长期的角度来希望 CentOS Stream 代替了 CentOS Linux 以后，在未来可以让所有人都能够感到满意。

我们的使用者是非常、非常多的，而且每年我们也会开一些会议，不管这个会议是面对面的还是网上的。如果是面对面的，我们还会交换一些各地的美食，总之这是一个非常有意思的社区，也是非常好的一群人，可以在一起工作。至少截止到目前来看，我们觉得 CentOS Stream 这个模式是比之前更好了，有更多的人愿意向社区做出贡献，所以我们开的这个会议也都是完全透明的，如果你感兴趣的话，其实在 Youtube 上能看到我们讨论的是什么，以及如果大家感兴趣的话，非常乐意你们可以跟我们接洽，参与我们的讨论，我们也非常愿意把你纳入到这个社区当中的一员。谢谢。

王兴宇：我们看到在后 CentOS 时代，整个开源操作系统市场格局已经发生很大变化。在这种情况下，对于 CentOS，对于 RHEL 的产品迭代有没有影响？目前来说，把 CentOS 换成 Stream 以后，是否社区对 Stream 的贡献更多？RHEL 是否因此变得更好？

Thomas：好的，我先从社区的角度回答一下。再强调一下，因为我不是红帽的员工，所以从社区的角度讲一下。举个例子吧，CentOS Stream 9 是 RHEL 9 的上游，通过 CentOS Stream，你可以直接参与到 RHEL 的开发当中。比如，你可以通过 Bugzilla 提交问题，你也可以提交补丁。那么是不是你的补丁未经测试就可以加入到 CentOS Stream 里呢？不是的！与你一起工作的还有很多红帽的开发者，他们会和你一起检查代码，你写的补丁也要通过 RHEL 的测试流程，红帽会去看你的补丁是否满足 RHEL 的质量要求，而最终决定是否被加入到 CentOS Stream 里。但整个流程更开放了，你可以参与所有的讨论，通过 CentOS Stream，你可以直接参与对 RHEL 发展方向的讨论，你在 Stream 里所看到的就是即将发布的 RHEL。

Brian：Thomas 回答的非常好，我在这里想补充的是，从红帽的角度来看，最让我们激动的并不是对 Stream 的贡献。很多的贡献往往以这样的形式出现：观察红帽工程师所做的，然后提出建议 —— 你是不是需要考虑这个方面？我告诉你你的这个代码改动可能有这些潜在的问题，等等。而是我们看到 CentOS Stream 里有非常强有力的 SIG（特别兴趣小组），通过“特别兴趣小组”形成了 CentOS 项目的生态。特别兴趣小组的人们会提出很多想法，这些想法提出的初衷并不一定和 RHEL 相关，更多的是与社区参与者自己相关，或者说他们希望 RHEL 变成的样子。红帽也是以第三方观察者的身份去看这些想法如何在社区中酝酿、孵化，最终一些好的想法就会在 RHEL 的大版本中落地。

王兴宇：我们之前一直在宣传 Stream 这个模式会让社区更容易参与到 Stream 的贡献之中，我现在想进一步问，我们 CentOS Linux 8 去年底停止服务以后，Stream 出现以来，社区对 Stream 的贡献是不是更多了？从你们的管理层来说，有没有这样的一个数据或者图表可以证明这些东西？

Brian：我来回答一下，您说的这个数据如果是从统计学的角度来说，这种数据是很难拿到的，因为很多时候大家为了虚荣心（想要一些好看的数据），比如说浏览量、下载数据，但我觉得这些数据并不是您想要的。我看这个问题从两方面来看，一是贡献量的衡量，我们现在其实能够实实在在的看到越来越多的公司、个人都在直接的参与到对社区的贡献当中，这些贡献要么最终被收录到 RHEL 的代码当中，要么这些讨论依然保留在 SIG 里面。

另一方面，就是这种贡献的可能性，不是说讨论 Stream 出现以来是不是贡献量更多的问题，而是说，Stream 出现之前，你是没办法去贡献的。有了 Stream，才有了对 CentOS 项目贡献进而影响到 RHEL 的可能性。所以这不是“是不是更多”的问题，而是“从无到有”的问题。

要知道，之前对于 CentOS 项目贡献，只有两个途径：

第一个途径，就是你的代码先被上游社区接受，然后被 Fedora 集成，然后被 RHEL 集成，最后出现在 CentOS 里，这是一个漫长的路径，而且不是对 CentOS 贡献；

第二个途径，就是你必须是红帽的客户或合作伙伴，那么在打造 RHEL 的过程中，你的这个想法对于你的公司和红帽，都是一个高优先级的事情，那么会被优先加到 RHEL 里，然后出现在CentOS里。

有了 Stream，实际上是有了第三个途径，就是你通过 CentOS 社区，通过 Stream 项目直接把你的贡献集成到 RHEL 里。

关于数据，其实你可以去看一下 GitLab，CentOS Stream 的代码日志都在那里。对于 CentOS Stream 8 来说，因为是处在 CentOS Linux 模式到 CentOS Stream 的模式转变的过程当中，你会发现所有的贡献基本都来源于红帽。但对于 CentOS Stream 9 来说，你可以通过 Git 日志看到所有的贡献（CentOS Stream 9 的代码提交日志和 RHEL 9 的代码提交日志是同一个）。对于每一个贡献，你可以去查看代码的修改轨迹、社区的讨论，Bugzilla 上的讨论，这是我对于如何获取关于社区贡献的数据的一点看法。

王兴宇：去年 CentOS Linux 8 停止更新以后，红帽或者 CentOS 接到的最多反馈是什么？你们做了哪些回应？

Brian：好的，我先来回答一下，然后我鼓励 Thomas 也再来回答一下。因为大家知道我是在红帽工作，那么我所听到的和 Thomas 从社区的角度听到的可能有所不同。确实有一些人的反馈是“你们怎么敢这样做？这让我很愤怒。”那么我们的回应是，“当你冷静下来，考虑一下 Fedora Linux 的价值主张的时候，考虑一下 CentOS Stream 价值主张的时候，我们是不是可以讨论一下 RHEL，或者很多其他的 Linux 发行版，看看如何选择一个合适的 Linux 发行版。”（译注：此处的 Brian 的意思可能是客户应该选择合适的发行版 —— 如果 CentOS Stream 不能满足期望时。）

RHEL 和它的衍生版如 CentOS 有很多用户。我们的客户和我们讨论的通常是 RHEL，事实上我们没有通过 CentOS 服务我们的客户，因为我们的产品是 RHEL。我们收到的客户反馈也通常是如何去影响 RHEL 的小版本发布，影响 RHEL 的小版本发布简直太难了，是不是在小版本发布时可以更多的听取广大用户的声音？我们有些客户，想尽早知道我们是如何在下一个小版本中修复 Bug 的，这样他就可以早一点将他的系统和红帽的操作系统做持续集成，而不必等到 RHEL 的下一个发布。

当然，早期我们也听到另一种声音，就是现在在我的桌子上就有一台 Linux 服务器，我一直使用的是 CentOS Linux，那么现在我该怎么办？那么，我们的回答是，您可以使用免费的 RHEL 的个人开发者版本，我们不是试图要您付费，也不是想借此扩大市场占有率，我们的目的只有一个，就是促进开源社区的发展。诚然，开源社区发展好了对我们的产品也有益，但出发点还是促进开源社区的发展。对您来说，我们给你提供了一个选择：这就是免费的 RHEL（个人开发者版本），正好适用于你的这种使用场景。

Thomas：接下来我从社区的角度回答一下。开始的时候我们确实也听到一些抱怨或担忧的声音，比如红帽是不是从源头上杀死了制作 CentOS 的可能性。关于这点我要澄清的是，任何人都可以按照 CentOS Linux 的做法制作 CentOS Linux，有一些人已经这样去做了。有些人已经和我们取得了联系，并且获得了我们的帮助。这其实是大家的自由，我们不去也没有办法阻止人们去做他们想做的事情，相反，我们也欢迎大家一起到 CentOS 社区上来讨论，给我们反馈，这些都是很好的。

另一点，就是关于 CentOS Stream 的稳定性。我自己的话，之前大量的使用了 CentOS Linux，我是把 CentOS Linux 用在了开发测试环境上。从我的经验来看，CentOS Stream 是稳定的。CentOS 是一个社区项目，其实你有充分的自由去决定 CentOS 用在什么场景上，这可能和你的公司的决策也有关系。

王兴宇：在做出 CentOS 停止服务这个决定之前，你们是否预料到如今会出现多个替代品。这些替代品既有像 Rocky Linux、Alma Linux 这样的 CentOS 的原位替代品，也有像中国的 openEuler、AnolisOS 这样的非原位替代品，但是从某种意义上可以取代原有 CentOS 市场占有的一些发行版。你对这两类发行版有什么看法？

Thomas：好的，我先来回答一下，像您刚才提到的这些，坦白讲我并不是对每一个发行版都特别清楚。它们如果是 RHEL 的衍生版的话，如果愿意和我们取得联系，我们很乐意提供帮助。我们是开放的，我们是开源的，开源社区就应该这样，所以从我的角度来说，我并不想从竞争者或者市场占有率这样的角度去看其他一些产品，没有关系的。以前 RHEL 是怎么制作的，你可能要和红帽签了 NDA 才可以看到，现在你连 NDA 都不用签，你可以通过 CentOS Stream 看到非常具体、非常细节的操作。现在一切都是开放的，所以实际说现在比起十年前如果有人想要打造一个我们的替代品，相当于更容易、更简单了，但我们一点也不怕这个，我觉得这是别人的自由、别人的权利，而且我们也非常希望看到这样一个发展的态势。

Brian：我也来说两句，从红帽的角度来讲，我们对于有其他的一些替代品我们没有任何看法。其实这就是开源的本质。作为一个以开源开放模式制作企业软件的公司，我们深知任何人都可以拿到这个代码做他们想做的事情，这是很 Cool 的。我们希望的是，如果你拿到这个代码，你去添加了新的功能或修复了 Bug，你也像其他人一样，将你的改动回馈到社区里去。我不喜欢看到的是有一些人拿了这个代码以后他自己做了一些事，比如创新或者解决了一些问题，但是他一点都不想着曾经受益于的这个社区，这个是我不喜欢看到的。因为我觉得，尤其是当你发现了有一个 Bug，你发现了怎么给它打补丁，你发现了一个解决问题的方法，绝对不要把这个当一个秘密一样藏着掖着，一定要想着开放的告诉别人，因为你是从一个开源的社区拿到这些代码的，这个对我来讲非常重要。

从红帽的角度，我还想强调两点：

一是，我们在制作 RHEL 这个产品的时候，我们更多考虑的是我们客户群他们有什么样的特殊需求、特殊场景需要满足，解决他们的问题。如果我在做一个操作系统的选型，我会去首先测试它是否可以满足我的应用场景。可能操作系统提供的很多功能都不是我需要的，我关注的是我需要的功能它是否可以提供。那么 RHEL 就是以这样的思路去开发的一个操作系统 —— 心怀用户。

二是，开源软件公司为客户提供的价值不仅仅是代码本身，更多的是位于代码之上的东西。因为代码是开源的，任何人都可以获取这个代码并使用它。所以我想鼓励人们去思考，当你在选择一个操作系统的时候，你最看重的它的价值是什么。因为在源代码之上有很多价值，比如解决问题的能力、服务能力。你提到很多版本像 Rocky Linux、Alma Linux、openEuler 等等，Rocky Linux 是在 CentOS 项目刚刚提出变更时就出现了，像 Thomas 所说的，我们鼓励在开源领域的任何创新。

还有说到市场占有率，市场占有率实际上做衡量很困难。当然红帽我们有一些我们内部数据，但是在外部的数据，就比如说我知道 IDC 对于市场上的 Linux 的发行版的市场占有率做过一些调查，但是他们做的调查很多时候是用代理的方式来进行衡量。这个我觉得就会有一些挑战，什么样的挑战呢？就是说你很难去衡量这个不付费的发行版是一个什么样的程度，在这种情况下，你可能拿到的数据就像我刚才说的，通过代理它不是一个最最真实的市场占有率的数据。另外还有像我们 Fedora 这个项目当中的一些数据，这个包含了一些终端用户的自愿参与。既然是自愿参与，所以很多时候这个数据你也不能够拿到真正可以展示实质情况的数据，这是我对市场占有率的看法，谢谢。

王兴宇：前面 Brian 也分享过关于如何在产品环境中使用 Stream，我想知道，如果企业在自己的产品环境中要应用 Stream 作为他的基础操作系统，您这边有什么最佳实践可以分享给大家？

Thomas：好的，我先来回答一下，因为我们确实在我们的环境中使用了 CentOS Stream。我们首先要评估我们想要做的事情，特别是在一个大的公司里面，每个部门可能诉求都不尽相同。在我们的评估中，我倒是没有看到 CentOS Linux 和 CentOS Stream 的表现有什么不一样。对很多企业来说，你可能要使用一致的操作系统，满足安全要求，稳定性要求，这些在我看来，CentOS Stream 和 CentOS Linux 是一样的。对于用户来说，你可能有些特殊的工作负载，有特殊的工作流程，那么，你需要做好测试，确保操作系统能够满足你的要求。

王兴宇：作为这次的采访方，我们 Linux 中国是一家中国的开源社区，所以我想知道中国的开源社区或者中国的 CentOS 的用户对于 CentOS Stream 的参与程度怎么样？从 CentOS 社区来说，是不是对中国的开源社区增加一些关注或者支持，可以让中国的开源开发者更多参与到 CentOS 社区的建设中？

Brian：好的，您刚才说的对于中国社区增加一些关注，对的，我百分之一万，双脚双手赞同。确实，因为曾经我本人以前的工作，作为 Fedora 社区的架构师，当时我就是在想说，如何能够提高两个地区的参与度：一个是南美，还有一个就是亚洲。那么在亚洲，尤其我们指的就是中国。因为我们知道，在中国有很多的 IT 的人才和精英，而且我们知道他们特别感兴趣，但我们就是不知道到底怎么样可以让他们参与到我们的这个社区的环境当中来？所以其实在这里，我也希望老王能给我们一些建议。因为我们毕竟是在中国外部的，很多时候我们的视角，不能够非常的贴合中国发生的事情。

比如说，我就举一个简单的例子，社区的这些开发者有时候要开会，对吧？你比如说我住的这个地方，我开会、通勤只需要二十分钟，不过这二十分钟对我来讲都是很长很长的时间。但是我知道，在中国，你说不定赶到晚高峰的时候，光回家就得用两个小时。我都难以想象这两个小时，因为二十分钟的通勤时间对我来讲都是已经很长很长了。那么在这种情况下，可能就会发现中国的有一些社区的参加者，他可能就不太愿意去参加这种社区的活动或者会议。所以在这方面，我也是特别希望老王可以告诉我们，我们应该怎么做，我们确实是希望能够给中国的社区增加关注，但是很多时候这个外国人的视角不会像你们这么准确。

Thomas：好的，那我也再加一句，我们刚才也一直在表达，我们一直都是开放的，我们希望有更多的人加入。尤其是更多来自中国的。我们刚才也说了，管理委员会，或者说管理层，现在不是正在提名候选人吗？所以说，老王，如果您或者是在座的各位，如果知道谁在这个方面做的特别好，因为我们可能不知道谁在这方面的工作特别优秀，你们也可以给我们来说能够提名谁，我们都非常愿意，只要这个人是愿意给社区进行分享，回馈社区。我们每个月还会有一些报告来统计谁做了一些什么事儿，无论如何，我们的目标就是希望能够有更多的贡献者，尤其是来自中国社区的贡献者。因为这样我们可以把这个生态系统打造的越来越完善。所以，非常非常开放。如果您有一些提名候选人的想法，欢迎告诉我们。

王兴宇：好的，很抱歉，我可能提不出来太多的见解，只是简单的有几个建议。我也一直非常关注 CentOS 社区和国内的开源社区的情况。所以我对于 CentOS 如何在国内发展，有一点点思考：

首先，CentOS 在中国还是有非常多的受众和认知度的。几乎在中国国内传播 Linux 的文章，都会拿 CentOS 作为蓝本。而这一点跟国外比较差异大，国外拿 Ubuntu 作为蓝本比较多一些。

其次是，国内确实存在这样的情况，无论是我们的社区文化还有语言，其实造成中国的 CentOS 的爱好者，或者贡献者，很难跟国际的 CentOS 社区直接对接起来，这种情况下，确实存在一定的阻碍。所以我有几个建议：

1、建议 CentOS 国际社区可以支持中国的 CentOS 本地化社区的建设。包括像一些本地化的翻译这种类似的工作可以做起来。

2、国内的一些线上、线下的社区活动希望可以得到国际社区的支持。

3、CentOS 发生的一些事情，比如说社区的一些动态，或者社区的一些倡议、决策，可以及时的传达给中国本地的社区。这方面其实在我们国内，无论是交流平台，交流习惯，比如说国外用 Facebook、Telegram、Twitter 比较多一些，国内几乎这些是不可用的，我们反而用的微信、QQ 会比较多一些。而邮件列表这种比较传统的模式，其实说实话，在中国并不太像国外那么受欢迎。所以说，在这种情况下，一些适应本地化的改造是可以适当做一些的。

我觉得通过这样的一些工作，可以有力的发掘出来中国的一些开源爱好者和贡献者，参与到整个 CentOS 社区之中。这样的话，无论是对中国的 CentOS 社区建设，还是对整个国际化的社区建设都是有好处的。以上是一些不成熟的想法，仅供参考。

Thomas：非常感谢老王。的确，我特别理解刚才您说的本地化，包括语言的一些障碍，确实可能阻止了中国社区跟国际社区的一些对接和交流。因为我本人英语也不是我的母语，所以我能够理解您说的语言障碍。尤其是对于一个人可能感觉自己好渺小，要对这样的一个这么大的国际社区做一些贡献，可能一开始都会有点害怕。但其实这也没关系，包括就在我日常的工作当中，有的时候你会发现有一个人说法语，然后一会儿又切换成英语，很多时候一开始你会觉得有点别扭，但实际上也没关系，参与多了，你就会觉得这挺好的。

如果中国这边有一些开发者，或者贡献者，如果想要对社区做出一些贡献，甚至都可以直接跟我联系，给我写电子邮件，都没有问题。哪怕我本人不能和你进行这样的对话，我会把你对接到我心里认为的最合适的那个人。包括在本地化、在翻译方面，确实我们要做出更好的一些决定，因为翻译确实特别特别的重要，我们确实也不认识中文为母语的人，所以可能在这方面有点问题。但是没关系，我只是鼓励大家都可以对社区做出贡献，哪怕一开始只是一小步都没有关系，如果有什么问题可以直接与我取得联系。

Brian：好的，我也是同意刚才您说的语言障碍，确实翻译很重要，确实语言障碍可能有一些时候会对我们有一些影响。但是，我也想强调一点，在 CentOS 这个社区当中，它还是跟其他的一些社区有区别的，最大的特点是我们的很多工作是异步的。这不像你参加其他的一些国际会议，你需要实时做出反应，你有时候开其他会议你会发现好多英语为母语的人在那儿吵的特别热闹，轰轰烈烈，然后他们要做决定，要举手表决的时候，你都没听清楚他们在说什么，对吧？但是我们的 CentOS 社区其实不存在这种情况。另外，CentOS 这个社区是非常非常包容的，也是非常欢迎新成员的，任何可以作出贡献的人，我们都很欢迎。所以只要大家再多一点点的勇气，手拉手一定可以把这个问题解决的非常好。

王兴宇：好的，正好说起来翻译，我这边在 Linux 中国旗下有一个叫 LCTT SIG 的翻译组织，已经运行了九年，所以在这方面多少有一些经验。将来我们可以建立这样一个平台或者渠道，沟通双方障碍的一个需求和共识。其次，我们本身也有一些核心成员，甚至有一位成员今天也在会议里，她在英国留学，也可以参与到我们这个平台里，使国际社区可以在中国更好的落地，形成一个中国的 CentOS 分社区。

Thomas：刚才您说的这两个建议，一个是已经运行九年的翻译组织，还有一个就是您也有一些核心成员今天也参会，毕业于英国。这些我希望能够落实到文字上，因为我们的董事会成员，比如说他要讨论一些什么，一定是要有一个文字的东西来讨论的。所以这些都是非常好的想法，但是请花 5 分钟，如果能够把这些关于本地化、翻译等等的平台写下来，这样我们管理层就比较好讨论。

王兴宇：好的。接下来是最后一个问题了，我想了解一下，关于 Fedora、Stream，还有 RHEL 未来的发展计划是什么？两位可以给我们展示一下你们的路线图吗？

Brian：好的，关于 Fedora、CentOS Stream、RHEL 的未来发展计划，我想从两个维度来回答。一个是社交组织的维度，另一个是代码的维度。

从社会组织的维度：

1. Fedora：主题是如何提高对 Fedora 的贡献，如何使得社区更多样化；
2. CentOS Stream：和 Fedora 差不多，提高社区贡献和使社区更多样化，另外就是发展 SIG（特殊兴趣小组），充分发挥 SIG 的作用；
3. RHEL：进一步繁荣包括社区、合作伙伴、客户的 RHEL 生态

从代码的维度：

Fedora：

• 集成上游社区最新最好的代码，功能最丰富，做业界的引领者；
• 面向特定的场景，做特色的发行版，如 Fedora IoT 就是面向物联网场景的 Fedora 操作系统。

CentOS Stream：

• RHEL 稳定可靠的持续交付版，用户可以提前看到即将发布的 RHEL 版本；
• 基于稳定的代码基础，通过社区发展 SIG，在特定领域创新。

RHEL：

• 我们面向客户的销售团队有很多关于产品的介绍，但我今天不是来为产品做广告的。我相信红帽大中华区的同事们可以给您很好的支持。

以下本场访谈其它与会者的问答环节：

Q1：从 CentOS Linux 转移到 CentOS Stream 之后，对于社区的支持工作发生了什么样的变化呢？

Thomas：好的。回答这个问题，我觉得一点都没改变。现在如果你遇到一些问题，你还可以跟我们一起来解决这个问题，可以得到最好的解决的方案，所以对我本人来讲，我觉得根本没有区别，但唯一一个我觉得好的地方就是说现在有了 CentOS Stream，你也有机会来提供这个补丁了。

之前，你是没办法直接对 RHEL 提供补丁的。但现在，你提供这个补丁，然后工程师、社区都可以进行非常开放的讨论，可以讨论这个补丁是不是应该用在下一个的版本发布当中。所以我觉得这是非常好的一点。总结来说，CentOS Stream 使得 RHEL 的开发流程更加开放了，而且我也非常鼓励大家可以做出很多的贡献。对社区的贡献越早，你贡献的影响可能就会越大。所以，从长期的角度来讲，我觉得这是一个非常好的变化。除此之外，没有任何大的区别。

Q2：很多开源社区发展到现在，虽然写代码的人多了，但维护人员却在减少，那 CentOS 社区如何保证优秀的代码能被看到，并集成到产品当中呢？

Brian：好的，您提的这个关于维护人员减少的问题，开源项目的维护确实是个大的话题。因为对于写代码的人来说，你可能一年花一个小时的时间为这个项目写了一段代码，然后就跑掉了；但是对于维护者来说，他要一直维护着这段代码。所以对于开源项目的维护来说，当您提交一个补丁时，维护者说 Yes，意味着他将永远替你维护这段代码。维护者说 No，不是说彻底把你否定了，你明天、后天依然可以提交。这未必是说明你的补丁不好，不优秀，也许是维护者不完全明白你的意图，或者你的改动太大、涉及的面过于宽泛，因此，在这个时候，就需要和维护者有一个很好的沟通。

对于 CentOS Stream 项目来说，和其他开源社区不一样的是，维护人员没在减少，因为红帽有很多工程师是 CentOS Stream 的维护者，红帽会确保 CentOS 社区有足够的维护者使得优秀的代码不被遗漏，这不意味着每一个补丁都一定会被说 Yes（被接受），而是我们有足够的人手工作于 CentOS 社区可以去说 Yes。另外就是社区里优秀的维护人员，我们也会去雇佣他，让他有足够的时间陪家人、休假，免于奔波等后顾之忧，这样也可以更安心的做好开源项目的维护工作。作为开发者，你可能是自愿的从事开源项目的开发，或者你的组织在做这样的工作。我们也可以对第三方组织提供支持。开源不仅仅是指它的源代码，而是整个社区，整个社区我们都要支持。

（本次访谈到此结束）

开源是一个具有挑战性的概念。许多人认为，开源意味着可以任意的使用软件，并且可以免费下载。这实际上取决于你如何被许可 —— 开发者分享代码时使用的许可证决定了它。开源软件可以是收费的，也可以限制你如何去使用它，在极少数情况下，甚至让你陷入法律纠纷。

Fedora 项目最近决定拒绝所有使用 知识共享 Creative Commons “公共领域专用” CC0 许可证的代码，以避免这种情况的出现。CC0 将从新提交代码中准许使用的许可证列表中剔除，但是，像艺术品一类的贡献仍被允许所以它，甚至可能在个案的情况下对当前的软件包进行逐一的处理。

如果 Fedora 反对一个软件许可证，通常不会成为新闻。事实上，在那么多的许可证当中，该项目拒绝了许多许可证。这种情况的意外之处在于，CC0 最初被认为是一个有效的许可证，现在只是由于更大的自由及开源（FOSS）社区内的观点转变而被重新分类。

CC0 是因为什么让 Fedora 决定停止支持它，这又是否意味着你不能在你自己的项目中使用它呢？

这一段描述让最熟悉知识共享及其许可系列的人惊讶的是，Fedora 最初批准了 CC0 的软件。毕竟，知识共享从一开始的目标是为艺术作品提供一系列明确的许可证。该组织的使命和许可证的要求在其名称“知识共享”中就有所体现。

为了“克服分享信息和创造力的法律障碍”，提供一个自由的框架来为人们组织分享如音乐、医学或教育材料的资源，知识共享组织的前身—— 开放内容项目 Open Content Project ，于 2001 年成立。然而，软件从来不是它的组成要素。为什么呢？因为那时，如 MIT、GPL 一类的重要的软件许可证已经出现了十几年。

很明显，如果一家公司不遗余力地警告你他们制造的东西不适合某种特定用途，你也许应该相信他们。知识共享的 FAQ 列出了一些反对在软件上使用他们的许可证的令人信服的论据，但对于像 Fedora 项目这样的用户来说，其中一个问题特别突出：专利权。

鉴于 CC0 许可证是为公共领域的作品准备的，而且通过使用它，创作者明确地“放弃了他或她在版权法下对作品的所有权利”，这似乎矛盾的。但是，问题在于，版权法并不适用于专利。事实上，仔细审视许可证的完整措辞后可以发现，它在一个令人担忧的部分解决了这个问题，该部分内容如下：“宣告者拥有的任何商标或专利权都没有被本文本放弃、抛弃、交出、租赁或以其他方式修改。”

换言之，即使被 CC0 许可的东西的作者可能愿意放弃对它的权力，但他们仍然可以自由的为它申请专利。更糟糕的是，他们仍然保留着以他们认为合适的方式使用该专利的能力。

理论上来说，这意味着最初在 CC0 下提供的源代码的人在发布了代码之后，他们可能会在之后断言任何使用该代码的人侵犯了他们的专利，并要求支付专利费。

这显然会让像 Fedora 这样的项目担忧。考虑一下这样的情形：CC0 许可的代码进入到一个系统的核心，然后被提供给数以百万计的用户。突然间，不知道从哪里冒出来的原创作者，声称侵犯了专利权，并要求付款。红帽或 Fedora 的律师可以驳倒这种说法么？也许吧。那么，为了查明真相而使用 CC0 代码值得么？不值得。

要着重提到的是，这完全不是一个新问题。实际上，早在 2012 年，专利条款就阻止了开源倡议（OSI）许可证的审查委员会，他们无法最终确定 CC0 是否真正符合他们对开源许可证的定义。委员会未能达成一致意见，因为其成员认为将此类条款纳入软件许可将创造一个危险的先例。考虑到 Fedora 动荡的历史，它最初接受 CC0 的决定着实让人费解。

via: https://www.opensourceforu.com/2022/08/what-made-fedora-choose-to-use-cc0-licensed-code-as-the-boot/

作者：Laveesh Kocher 选题：lkxed 译者：yjacks 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

我们经常交替使用人工智能（AI）、机器学习（ML）和深度学习（DL）这些术语，尽管我们几乎每天都阅读或听到它们。本文解释了这些技术是如何演变的以及它们有何不同。

人工智能 Artificial Intelligence （AI）、 机器学习 Machine Learning （ML）和 深度学习 Deep Learning （DL）通常可以互换使用。但是，它们并不完全相同。人工智能是最广泛的概念，它赋予机器模仿人类行为的能力。机器学习是将人工智能应用到系统或机器中，帮助其自我学习和不断改进。最后，深度学习使用复杂的算法和深度神经网络来重复训练特定的模型或模式。

让我们看看每个术语的演变和历程，以更好地理解人工智能、机器学习和深度学习实际指的是什么。

人工智能

自过去 70 多年以来，人工智能已经取得了长足的进步。无论我们是否知道，也不管喜欢与否，，它已经渗透到了我们生活的方方面面。在过去十年中，机器学习和深度学习的进步已经在各种规模的行业和组织中创造了人工智能热潮。云服务提供商通过开发免费的开源服务和提供新的场景进一步推动的这种势头。

人工智能可能是自 1956 年以来最受关注的概念。到 2015 年，GPU 的广泛使用使并行处理更快、更强大、更便宜。而愈加廉价的存储可以大规模地存储大数据（从纯文本到图像、映射等）。这产生了对数据分析的需求，它被更普遍地称为 数据科学 data science ，导致机器学习发展为实现人工智能的方法。

机器学习

机器学习是使用算法来处理、学习和理解或预测可用数据的模式。最近，软件开发的低代码和无代码概念被用作机器学习中的自学习过程，它给出了完成特定任务的特定指令。通过使用数据和算法对机器进行“训练”，使其能够学习如何执行任务，更重要的是，将学习应用到不断发展的过程中。

机器学习是在开发者社区专注于 AI 时发展起来的，然后发展了算法决策树学习、逻辑编程、聚类、并行处理和强化学习。这些都是朝着正确方向迈出的良好一步，但不足以解决世界感兴趣的场景。

深度学习

深度学习是神经网络和机器学习的进化，是人工智能社区的创意。它学习了人类思维在特定场景中的工作方式，然后在这项工作上比人类做得更好！例如，IBM 的 Watson 与自己下国际象棋，并在游戏中取得了很大进步，最终击败了世界冠军。谷歌的 AlphaGo 也学会了如何玩围棋游戏，一遍又一遍地玩它以提高自己，并成为冠军。

人工智能、机器学习和深度学习正在不断发展。参与数据科学的每个人都希望推进这些概念以改善我们的日常生活。而开源社区、私营企业、科学家和政府机构都在为此共同努力。

总而言之，虽然 AI 有助于创建智能机器，但机器学习有助于构建 AI 驱动的应用。深度学习是机器学习的一个子集。它通过利用复杂算法处理大量数据来训练特定模型。由于狭义 AI 极难开发，机器学习正在通过刚性计算解决这一领域的机遇。至少对于实现通用 AI，深度学习有助于将 AI 和机器学习结合在一起。

via: https://www.opensourceforu.com/2022/08/ai-ml-and-dl-whats-the-difference/

作者：Bala Kalavala 选题：lkxed 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Equalify 是一个为了让互联网更易于使用的开源项目。

无障碍访问 Accessibility 是一把促进社会更加开放的的钥匙。

我们在网上学习，我们在网上花钱，也在网上吵吵嚷嚷。更重要的是，我们在网上获取的信息激励我们创造一个更好的世界。当我们忽视无障碍访问的要求时，出生时失去光明，或在战争中失去四肢的人们都将只能被阻挡在他人可以享受的网上信息之外。

我们必须确保每个人都有通往开放互联网的通道，而我正在通过开发 Equalify，为实现这一目标而努力。

什么是 Equalify?

Equalify 是“无障碍访问平台”。

这个平台允许使用者们对数以千计的网站进行多种无障碍访问的扫描。通过使用我们的最新版本，用户还可以过滤无数的警告，创建一个对他们来说有意义的统计仪表盘。

这个项目才刚刚开始。Equalify 的目的是开源像 SiteImprove 这样的昂贵服务所提供的各种收费服务。有了更好的工具，我们可以确保互联网更容易访问、我们的社会更开放。

如何判断网站的无障碍访问？

W3C 的网络无障碍访问组织发布了《网络内容无障碍访问指南（WCAG）》，为无障碍访问设定了标准。Equalify 和包括美国联邦政府在内的其它机构，都使用 WCAG 来定义网站的无障碍访问。我们扫描的的网站越多，我们就越能了解 WCAG 标准的不足和潜力。

如何使用 Equalify?

花点时间查看一下我们的 GitHub，这样你能更多的了解这个产品。README 提供了如何开始支持和使用 Equalify 的分步教程。

我们的目标

我们的最终目标是让开放的互联网更易于使用。根据 The WebAIM Million 的数据，96.8% 的网站主页不满足 WCAG 标准。随着越来越多的人们开发和使用 Equalify，我们将与有障碍的页面斗争。每个人都应该有平等的机会进入开放的互联网。在我们朝着为所有人建设一个更强大、更开放的社会而努力时，Equalify 也正在朝着这个目标努力。

via: https://opensource.com/article/22/6/equalify-open-internet-accessibility

作者：Blake Bertuccelli 选题：lkxed 译者：yjacks 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出