> For the complete documentation index, see [llms.txt](https://blog.wh2099.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blog.wh2099.com/linux/linux-30-zhou-nian.md).

# Linux 30 周年

## 开源社区

### 如何成功

> 这是一个很难回答的问题，因为**我真的不知道成功的关键是什么**。虽然 Linux 非常成功，Git 也站稳了脚跟，但我很难说二者成功的深层次原因究竟是什么。天时、地利、人和都非常重要。对于 Linux 和 Git 来说，最重要的是这两个项目恰好满足了很多人的需求，或者是因为很多人都有这样的需求，但我是唯一一个站出来创建了这样的项目，并取得了成功的人？我个人更倾向于后者，**选择很重要，运气也很重要**。
>
> 另一方面，我觉得对于开源维护者而言，确实需要一些**务实的精神和思想，这很重要**。

### 转折点

> 最大的转折点是当我意识到真有人在使用它，并对它感兴趣时，它开始有了自己的生命。

### 激励

> **金钱其实并不是一个很好的激励方式**，因为它并不能将人们团结在一起。我认为，真正能够起到激励作用的是：**人们参与到一个共同的项目中来，并真正感觉到自己可以成为这个项目的全面合作伙伴**。

### 放权

> 很多人都会觉得“放权”很难。其实早年间有人给我发送补丁，但我并没有直接使用，我会阅读他们的代码，搞清楚他们想要什么，然后自己重新写代码。然而事实证明，我这样做并没有什么用，因为我很懒，所以决定在阅读并理解补丁后直接使用。因此，我眷恋权力的日子很快就过去了。**信任他们，不要对他们进行过多的微管理。**
>
> 因此，将项目委托给别人也不是一个大问题（当然我知道有些项目情况大不同），归根结底，部分原因是**我们的维护模型不需要某种绝对的信任**，因此情况就简单了许多。
>
> 另外，**沟通技巧非常重要**。**我出生于一个新闻记者家庭，读书和写作是每个人都喜欢的事情**。虽然英语是我的第三语言，但是当我建立 Linux 项目的时候，已经可以熟练地使用英语交流了。总的来说，大部分时间里，我都是在一边工作一边学习。再说一次，Linux 的成功不是一蹴而就。我们经过了三十年的努力，这个项目才有了如今大不同的局面。

### 许可证（GPLv2）

> 我 100% 地相信许可证是 Linux（以及 Git）成功的重要组成部分。我始终坚信要让大家都知道自己具有平等的权利且没有人在许可方面享有特权，这对所有人来说都是一件好事。
>
> 我认为 GPLv2 能够实现 **“所有人都在相同规则下工作”** 与 **“要求人们回馈社区”** 的完美平衡，大家都受同样的规则约束，非常公平公正。
>
> 同样，你的投入也会得到相应的回报。你可以当项目的“旁观者”，但也就失去了项目的控制权；也可以只把 Linux 当做一个基本的操作系统；但如果你有特殊要求，那么能对项目产生真正影响的唯一方法就是参与进来。
>
> 在这种情况下，包括我在内的所有人都要保持诚实。任何人都可以对项目进行分叉，走自己的路，然后接管自己的 Linux 版本维护。我的特别仅仅在于人们相信我能把工作做好，而这本就是理所当然的事情。
>
> “任何人都可以维护自己的版本”这一点让一些人对 GPLv2 产生了怀疑，但我认为这是一种优势。正是这一点保护 Linux 逃过了分裂的结局：每个人都可以完成自己的项目分支。事实上，这也是“Git”的核心设计原则之一——存储库的每个克隆都是自己的小分支，开发者（或公司）要想真正完成项目开发的话，则需要从中分叉出去。
>
> 所以**分叉本身不是问题，只要你能把好的部分合并回来即可**，这就是 GPLv2 的意义所在。要保障大家具备进行分叉并实现个人项目的权利，但与此同时，也要保证当分叉成功时，大家也有权利能再次将其融合回来。
>
> 另一个问题是，大家都想拥有能够支持项目生产的工具，与此同时，心态也一定要强大。将分叉融合回来的障碍，不仅是许可证，还有“Bad Blood”的问题。如果两个分叉从根本上就非常对立的话，那么要想将它们融合是非常困难的——并不是因为许可证或技术原因，而是由于分叉过于尖锐对立。同样，我认为 Linux 很好地避免了这一点，主要是因为我们一直认为分叉是一件非常正常且自然的事情；当其证明了自身的成功后，自然也要合并回来。
>
> 虽然这个答案或许有些跑题，但我认为这一点非常重要——我从未后悔过自己的许可证选择，因为**我真心认为 GPLv2 是 Linux 能够取得成功的重要原因**。

## 内核开发

### 引以为傲

> 个人认为是 **VFS（虚拟文件系统）层，尤其是路径名查找和我们的 VM 代码**。前者是因为 Linux 在做基础任务时表现确实非常优秀（在操作系统中查找文件名就是操作系统中的基础核心操作）。后者主要是因为我们支持 20 多种架构，但仍使用基本统一的 VM 层，我认为这一点非常了不起。但与此同时，这很大程度上取决于“更注重内核的哪一部分”。**我个人在 VM 和 VFS 领域的参与更多，因此自然也会选择这两方面的内容。**

### 版本发布

> 几十年来，我们推出过许多不同的版本方案以及多个开发模式，但 3.0 版本最终确定了我们一直以来使用的模式。它真正实现了 **“基于时间，版本号只是数字，不依附于任何功能”** 的说法。在 2.6 版本中，就具备合并窗口的“基于时间”的概念，因此这并不稀奇，但 3.0 是“最后一片拼图”。
>
> 我们有随机编号方案（主要是在 1.0 之前），其规则是：**小数点后奇数表示开发内核，偶数表示稳定的生产内核**。在 2.6 中，我们开始做基于时间的发布模式。但仍然存在“何时增加主版本号”的问题。而 3.0 的正式出现表示，**主版本号并没有什么特殊意义**，只是为了尽量简化数字，不要让它太长太繁琐。

### 内核重构

> \*\*我们真的非常擅长完全重写，所以如果有不尽如人意的地方也早就被重写了。\*\*我们也有很多“兼容”层，但一般无伤大雅。而且尚不清楚如果重写的话，那些兼容层是否会真的消失——它们是对旧二进制文件的向后兼容（通常是对旧体系结构的向后兼容性，例如在 x86-64 上运行 32 位 x86 应用程序）。我认为向后兼容是非常重要的，所以希望即使在重写时也要保持这种兼容性。
>
> 显然，很多东西都不是“最优选”，都有改进的空间，确实有一些没人关心和清理的遗留驱动，并可能会被利用来做一些坏事，但重点是“没人关心”。所以当问题出现时，我们想要去积极主动解决根源问题——“没人关心”。因此多年来，**当架构维护不再具有意义时，我们就会直接放弃整个架构支持**。
>
> 不过，**重写的唯一主要原因是——整个架构已经没意义了**，但却还有一些用例。最有可能的情况是，一些小型嵌入式系统并不需要 Linux 提供的东西，而且其硬件空间很小，它需要的是比 Linux 更小、更简单的东西。因为 Linux 已经成长了很多。现在，即使是小硬件（比如手机等）也比当初开发 Linux 时使用的机器功能强大得多。

### Rust

> 还需要再观察。\*\*我不认为 Rust 会接管内核，但是做单独的驱动程序（或整个驱动子系统）还是有可能的，或许还能做文件系统。\*\*所以它 **不是要“取代 C 语言”，而是“在适当的地方增强 C”** 。
>
> 特别是驱动程序约占实际内核代码的一半，所以空间非常大，但我不认为有人真的会用 Rust 全盘重写现有的驱动程序。绝大多数人都会“用 Rust 做新的驱动程序，在适当的地方重写几个驱动程序”。
>
> 但现在更多的人仍处于“试着玩玩”的阶段。**要指出优点很容易，但其背后存在着复杂性，所以我更愿意持观望态度，看看其承诺的优点是否真的能实现。**

## Git

### 诞生

> **我并不想创建新的源码控制系统，Git 的诞生完全是出于需要。并不是我觉得源代码控制很有意思，而是因为我完全看不上当时市面上大多数源代码控制系统，包括在 Linux 开发模型中运行得很好的 BitKeeper 也无法满足我的需求了。**

### **移交**

> 相比之下，我做 Linux 已经有三十多年（加上研究的时间)，并且一直在对其进行维护，但我从未想过要长期维护 Git。**我喜欢使用 Git，而且我认为它是目前市面上最好的 SCM，但这不是我的热情和兴趣所在**，因此，我一直希望由别人来替我维护 SCM。
>
> 至于 Junio，他是最早加入 Git 开发队伍的人之一。他在我公开了第一版 Git（非常粗糙的一版）后的几天内便完成了首次改动。所以 **Junio 实际上从 Git 诞生之初就已经是我们中的一员了**。
>
> 但之所以把项目交给 Junio，并不只是因为他“来得早”。在维护了 Git 几个月后，真正让我决定邀请 Junio 担任维护者的因素，是一个比较抽象的概念——**“好品味”**。编程依赖的也是各种细枝末节和每日的繁重工作，偶尔也会需要所谓的“灵感”，即“好品味”，**它能干净、漂亮，甚至是完美地解决问题**。编程是为了解决技术问题，但如何解决这些问题，以及如何思考也是非常重要的。随着时间的推移，你会清楚地认识到：有些人就是有那种“好品味”，能够做出“正确的”选择。
>
> 而 Junio 就具备这种“好品味”。
>
> 每次提到 Git，我都会尽量讲得非常清楚，虽然确实是我提出并设计了 Git 的核心思想，但 **Git 这十五年来，我只有在第一年亲自参与了项目工作，Junio 一直都是一名优秀的维护者，是他让 Git 有了今天的成就**。
>
> 找到并信任具备“好品味”的人——这不仅仅是 Git 的故事，也是 Linux 的历史。与 Git 不同的是，Linux 是一个我仍积极亲自参与维护的项目；但与 Gi t 相同的是，它也是一个有很多人参与的项目。**我认为 Linux 的一大成功之处就在于有数百名的维护者，他们都具备难以言表的“好品味” ，齐心协力共同维护内核。**