最近看了一篇文章<Linux 的 30 年Linus Torvalds 访谈>，linus作为嵌入式领域的技术大牛，在访谈中发表了自己的一些观点，有一些挺有参考价值的，这里挑了一些出来供大家学习参考。
原文是英文的:
https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git
https://www.tag1consulting.com/blog/interview-linus-torvalds-open-source-and-beyond-part-2
如果想看全文可以到链接处阅读。
三十年前，Linus Torvalds 是赫尔辛基大学 21 岁的学生，当时他首次发布了 Linux 内核。
他声明，"我正在做一个（免费的）操作系统（只是一个爱好，不会很大和专业......）"。三十年后，排名前500位的超级计算机都运行Linux，超过70%的智能手机也是如此，Linux显然既大又专业。
三十年来，Linus Torvalds 一直领导着 Linux 内核开发，激励了无数其他开发人员和开源项目。2005年，Linus还创建了Git来帮助管理内核开发过程，从那时起，它已成为最受欢迎的版本控制系统，受到无数开源和专有项目的信任。
1、十年后，你写了一本引人入胜的个人书，名为《只是为了好玩：一个偶然的革命者的故事》，探讨了这段历史的大部分内容。今年8月，Linux将庆祝其成立30周年！太神奇了，恭喜你！在这段旅程中，你什么时候意识到你做了什么，Linux不仅仅是"一种爱好"？
Linus Torvalds：这听起来可能有点荒谬，但这实际上很早就发生了。到91年代末（当然到92年初），Linux已经变得比我预期的要大得多。
是的，到那时可能只有几百个用户，考虑到Linux后来如何最终变得更大，这可能听起来很奇怪。但就我个人而言，在很多方面，最大的转折点是当我意识到其他人实际上正在使用并且对它感兴趣时，它开始有自己的生活。人们开始发送补丁，系统实际上开始做的比我最初真正设想的要多得多。
从这个角度来看，我真的没有从任何高期望的大计划开始。这是一个个人项目，并不是出于创建一个新操作系统的大梦想，而是从我最初只是试图学习我的新PC硬件的来龙去脉开始随意增长。
因此，当我发布第一个版本时，它实际上更像是"看看我做了什么"，当然，我希望其他人会发现它很有趣，但它不是一个真正严肃和可用的操作系统。这更像是一个概念验证，只是一个我当时已经工作了几个月的个人项目。
从那个"个人项目"到其他人使用它的东西，发送反馈（和错误报告）以及偶尔的补丁，这对我来说是一个很大的变化。
举一个非常基本的例子：最初的版权许可证是"你可以以源代码的形式分发它，但不能为了钱"。
那是因为对我来说，其中一个问题实际上是商业unix很昂贵（好吧，对于一个把所有钱都花在新PC上的穷学生来说），所以对我来说，一件非常重要的事情是源代码是可用的（这样人们就可以修补它），我希望它能向像我这样买不起替代品的人开放。
我在91年末（或者可能是92年初）将许可证更改为GPLv2，因为有些人想在软盘上将其分发给本地Unix用户组，但希望至少收回软盘的成本及其复制时间。我意识到这显然是完全合理的，重要的不是"免费"，而是"来源需要公开可用"的部分。
最终结果：人们不仅在Unix用户组会议上分发了它，而且像SLS和Slackware这样的早期软盘分发在几个月内就发生了。
与那些最初真正根本的变化相比，其他一切都是"渐进的"。当然，一些增量相当大（IBM即将上任，Oracle DB被移植，Red Hat IPO，Android在手机上变得很大），但它们仍然不如早期的"我甚至不知道的人正在使用Linux"那样具有个人革命性。
JA：你有没有后悔过你选择的许可证，或者其他人和公司从你创造的东西上赚了多少钱？
LT：绝对不是。
首先，我做得很好。我不是很有钱，但我是一个高薪的软件工程师，按照自己的时间表做我喜欢做的事情，我没有受伤。
但同样重要的是，我100%相信许可证是Linux（和Git）成功的重要组成部分。我认为，当每个参与者都知道每个人都有平等的权利，没有人在许可方面特别时，他们最终会更快乐。
有相当数量的"双重许可证"项目，其中原始所有者保留了商业许可证（"如果您向我们支付许可证费，您可以在您的专有产品中使用它"），然后另一方面，该项目也可以根据GPL之类的东西用于开源案例。
我认为围绕这种情况建立一个社区真的很难，因为开源方面总是知道它是"二等"。此外，它还导致许多公正的许可文书工作，以便特殊方始终保留其特殊权利，因此，它给项目增加了很多不便。
另一方面，我看到很多BSD（或MIT或类似机构）许可的开源项目，当它们变得足够大而具有商业重要性时就会分裂，所涉及的公司不可避免地决定将自己的部分变成专有的。
所以我认为 GPLv2 几乎是"每个人都在相同的规则下工作"的完美平衡，并且仍然需要人们回馈社区。每个人都知道，所有其他相关人员都受到相同规则的约束，因此这一切都非常公平和公正。
当然，另一部分是你也得到了你投入的东西，你可以尝试在项目上"滑行"。如果你真的只需要一个基本的操作系统，那么这也完全没问题，而Linux已经做了你想要的一切。但如果你有特殊要求，真正影响项目的唯一方法就是参与。
这让每个人都保持诚实，包括我。任何人都可以分叉项目，走自己的路，然后说"再见Linus，我正在接管我的Linux版本的维护"。
"任何人都可以维护自己的版本"让一些人担心GPLv2，但我真的认为这是一种优势，而不是弱点。有点不直观的是，我认为这实际上是导致Linux避免碎片化的原因：每个人都可以制作自己的项目分支，这没关系。事实上这是"Git"的核心设计原则之一 ----- 存储库的每个克隆都是它自己的小分支，人们（和公司）分叉自己的版本是所有开发真正完成的方式。
所以分叉不是问题，只要你能合并回好的部分，这就是 GPLv2 的用武之地。分叉和做自己事情的权利很重要，但硬币的另一面同样重要 - 当分叉被证明是成功的时，重新组合在一起。
另一个问题是，您确实希望拥有支持该工作流程的工具，但您还必须具有支持该工作流程的心态。加入分叉的一大障碍不仅是许可，还有"坏血"。如果分叉从非常敌对的原因开始，那么合并两个分叉可能非常困难 - 不是出于许可或技术原因，而是因为分叉是如此激烈。同样，我认为Linux已经避免了这一点，主要是因为我们一直认为分叉是自然的，然后当一些工作证明自己是成功的时，尝试合并回来也是非常自然的。
这个答案有点偏离了切线，但我认为这是一个重要的答案 - 我非常不后悔选择许可证，因为我真的认为GPLv2是Linux成功的重要原因。
金钱真的不是那么好的动力，它不会把人们聚集在一起。有一个共同的项目，觉得你真的可以成为这个项目的正式合作伙伴，这激励着大家。
JA：你平常的一天是怎样的？其中有多少花在编写代码上，而不是审查代码，而不是阅读和编写电子邮件？你如何平衡个人生活和工作在Linux内核上？
LT：这些天我写的代码很少，而且很长一段时间都没有写过。
当我编写代码时，最常见的情况是有一些关于某些特定问题的讨论，我进行更改并将它们作为补丁发送出去，主要作为对建议的解决方案的解释。
换句话说，我编写的大多数代码更像是"看，我们这样做怎么样"，补丁是一个非常具体的例子。人们很容易陷入一些关于如何解决某些问题的理论高级讨论中，我发现描述解决方案的最好方法通常是编写代码片段 - 也许不是全部 - 然后以这种方式使其非常具体。
因为我所有真正的工作都花在阅读和写电子邮件上。这主要是关于沟通，而不是编码。事实上，我认为这种与记者和技术博主等的沟通实际上是我工作日的一部分 - 它的优先级可能低于实际的技术讨论，但我确实花了相当多的时间在这样的事情上。
是的，我也花时间在代码审查上，但老实说，当我收到拉取请求时，通常有问题的代码应该已经被多个人审查过了。因此，虽然我仍然在看补丁，但实际上我倾向于更多地解释，以及补丁如何来到我身边的过程。对于与我共事时间最长的人，我甚至没有这样做：他们是子系统的维护者。
很多时候，我的主要工作是，成为一个收集点，并成为管理和执行发布的人。换句话说，我的工作通常更多地是关于维护过程，而不是低级代码。
JA：你的工作环境是什么样的？例如，您更喜欢没有干扰的暗室，还是有风景的房间？你倾向于默默工作，还是在听音乐时工作？您通常使用哪种硬件？您是在终端中使用 vi 还是使用花哨的 IDE 来查看代码？而且，你有首选的Linux发行版吗？
LT：我的房间并不完全"黑暗"，但我确实把桌子旁边窗户上的百叶窗关上了，因为我不想要明亮的阳光。因此，没有风景，只有一张（凌乱的）桌子，桌子上有两台4k显示器和一台功能强大的台式电脑，还有几台笔记本电脑，当我在旅途中时，可以坐在那里进行测试。
我想默默地工作。我曾经讨厌机械磁盘驱动器的滴答声 - 很高兴早已被扔进垃圾桶，因为我已经只使用SSD十多年了 - 嘈杂的CPU风扇也是不可接受的。
这一切都是在传统终端中完成的，尽管我不使用"vi"。我使用这种令人憎恶的东西叫做"micro-emacs"，它与GNU emacs完全无关，除了一些键绑定是相似的。
当我还是个小伙子的时候，我在赫尔辛基大学已经习惯了，我一直无法摆脱它，尽管我怀疑我必须尽快这样做。几年前，我为它加入了（非常有限的）utf-8支持，但它确实展示了它的年龄，并显示了所有在80年代编写的迹象，我使用的版本是自90年代中期以来一直没有维护的分叉。
因此，我的桌面环境相当简单：打开了几个文本终端，以及一个带有电子邮件的Web浏览器（以及其他几个选项卡，主要是新闻和技术站点）。我希望拥有相当多的桌面空间，因为我习惯于拥有相当大的终端窗口（100x40是我的默认起始大小），并且我有多个终端并排打开。因此，有了双4k显示器。
在我所有的机器上都使用Fedora，不是因为它一定是"首选"的，而是因为它是我习惯的。我不太关心发行版 - 对我来说，这主要是一种在机器上安装Linux并设置我所有工具的方法，这样我就可以替换内核并进行工作。
JA：内核中是否有任何不是最优的，但需要完全重写才能正确解决？换句话说，内核已经有30年的历史了，在这30年里，知识、语言和硬件发生了很大的变化：如果你现在从头开始重写它，你会改变什么？
LT：实际上，我们非常擅长在必要时完全重写一些东西，所以任何本来是一场不可减轻的灾难的事情早就被重写了。
当然，我们有相当数量的"兼容性"层，但它们通常并不可怕。目前还不清楚，如果从头开始重写，这些兼容性层是否真的会消失 - 它们与较旧的二进制文件的向后兼容性有关（并且通常与较旧的体系结构向后兼容，例如在x86-64上运行32位x86应用程序）。由于我认为向后兼容性非常重要，因此即使在重写中也要保留这些兼容性。
显然有很多事情是"不理想的"，因为任何事情都可以改进，但是你表达问题的方式，我不得不说不，那里没有什么是我鄙视的。有一些传统的驱动因素，没有人会关心到足以清理，所以他们可能会做一些糟糕的事情，但其中的关键部分是"没有人足够关心"。这不是一个问题，当它确实成为一个问题时，我们倾向于相当积极地删除真正的遗留支持，我们找不到任何关心的人。因此，多年来，我们已经摆脱了许多驱动程序，并且当维护它不再有任何意义时，我们已经摆脱了整个架构支持。
"重写"的唯一主要原因是，如果你最终有一些特例，整个结构不再有意义。最有可能的情况是一些小型嵌入式系统，它只是不想要Linux提供的所有东西，并且硬件占用空间非常小，以至于它只是想要比Linux更小，更简单的东西。
因为Linux已经成长了很多。即使是今天的小型硬件（想想手机等）也比开发Linux的原始机器更强大。
JA：用 Rust 重写至少部分内容怎么样，Rust 是一种专为性能和安全性而设计的语言？以这种方式还有改进的余地吗？你觉得像 Rust 这样的另一种语言有可能在内核中取代 C 吗？
LT：我们拭目以待。我不认为 Rust 会接管核心内核，但是在其中执行单个驱动程序（也许还有整个驱动程序子系统）听起来并非完全不可能。也许还有文件系统。因此，它不是"替换C"，而是更多的"在有意义的地方增强我们的C代码"。
当然，特别是驱动程序大约是实际内核代码的一半，所以有很大的空间，但我不认为有人真的期望用Rust大量重写现有的驱动程序，更多的是"有些人会在Rust中做新的驱动程序，并且有几个驱动程序可能会在有意义的地方重写"。
但现在，这更像是"人们正在尝试并玩它"，并没有其他意思。很容易指出优势，但肯定也有复杂性，所以我非常观望，看看承诺的优势是否真的成功了。
JA：除了你已经提到的关于减少编码，更多的沟通和领导之外，你是否需要学习一些你觉得困难的特定技能？例如，委派，成为一个更好的作家，以及其他非编码技能 - 如果是这样，你是如何学会这样做的？是动手，从书本上，还是从其他人那里得到的？这是学校里教的吗？
LT：我首先要说的是，对我来说几乎所有的过程都是渐进式的，是一种学习经历。三十年是一段很长的时间，很少有变化是非常突然的，我们做事的方式大多以一种非常"有机"的方式成长。
换句话说，这在很大程度上不是提前计划和阅读管理教科书等的结果。它大多是自己发生的，我们现在拥有的任何结构都不是来自一些写下来的组织结构图，而是来自人们简单地"找到自己的位置"。
显然有些人觉得困难的一项技能是"放弃控制"。我仍然记得早期，人们会给我发补丁，我实际上不会将它们作为补丁应用，但我会阅读它们，弄清楚人们想做什么，然后自己做。因为这就是我开始这个项目的方式，这就是我感觉更舒服的方式，这样我更了解代码。
事实证明，对我来说，这最终没什么大不了的。我很快就停止了这样做，因为我只是从根本上懒惰。我非常善于阅读补丁并理解它们的作用，然后我就应用它们。因此，我的控制狂日子很快就结束了。我认为我一直很擅长找到值得信任的人，然后这样做 - 信任他们，而不是过度具体管理他们。
因此，委派并不是一个大问题，但我知道其他项目也是如此。同样，部分原因是我们的维护者模型不需要某种绝对的信任，这确实使一切都变得容易得多。
沟通技巧非常重要。我实际上来自一个记者家庭（我的父母都是记者，我的叔叔是一个，我的祖父是一个诗人和记者），所以我在一个从很小的时候就认为阅读和写作被认为是理所当然的。虽然英语是我的第三语言，但在我开始使用Linux时，它对我来说已经是一种非常强大的语言，沟通并不是一个大问题。但我意识到，这可能是一个大问题，无论是出于个人（也许是个性）原因，还是出于语言障碍的原因。
但总的来说，大多数情况下，我确实是通过实践来学习的。再一次，请记住 - Linux没有一夜之间发生。三十年前的项目与今天的项目截然不同。
