Linus Torvalds所说的便携性是什么意思？[关闭]

41

在与安德鲁·塔南鲍姆（Andrew Tanenbaum）就微内核与单片操作系统体系结构进行的辩论中，莱纳斯·托瓦尔兹（Linus Torvalds）说，

可移植性适用于无法编写新程序的人。

他是什么意思？

portability quotations

— ykombinator
source

8

从“过去”时代撤出这些“辩论”（烈酒大战）时，请注意所读内容。考虑到因为Linux对Linus的内心非常珍惜，所以在这些讨论中可能会激起很多情绪。因此，您可能会发现很多言论只是出于厚脸皮或惹恼某人。

— 韦恩·考特斯

现在，在我们的元讨论站点上正在讨论这种类型的问题。

1

推荐阅读：讨论此$ {blog}

— 2014年

82

正如莱纳斯（Linus）在辩论中所写的那样，这是面无表情的（即不要太当真）。

然后，他继续解释说，虽然可移植性是件好事，但这也是一个权衡。不可移植的代码可以简单得多。也就是说，与其使代码完全可移植，不如使它足够简单和可移植（“坚持可移植的API”），然后如果需要移植，请根据需要重写。使代码完美地可移植也可以看作是过早优化的一种形式-弊大于利。

当然，如果您不能编写新程序并且必须坚持原始程序，那是不可能的:)

— 乔纳斯·普拉卡（Joonas Pulakka）
source

20

同意过早的优化。

— Mark Gibaud

4

+1莱纳斯（Linus）以其幽默的舌头而著称，但有些人对他所说的话太认真了。

— Spoike 2011年

12

我认为这意味着每个程序都应该针对其所运行的硬件和操作系统专门编写。

我认为他所驱动的是，可以在多个平台上运行的通用代码比专门为一个平台量身定制的代码效率低下或更容易出错。但是，这确实意味着，当您像这样进行开发时，必须维护多个不同的代码行。

— ChrisF
source

我认为这是正是他的意思

— Chani

9

早在最初编写Linux时，它就使用了仅在i386 CPU上可用的功能，这在当时是相当新的且昂贵的。

这正是linux的作用：它使用的386功能子集比其他内核似乎要大。当然，这使内核无法移植，但也使/ much /设计更为简单。可以接受的折衷方案，首先使linux成为可能。

进入21世纪以来，使i386独树一帜的功能已完全成为主流，使Linux变得非常轻便。

— 安多玛
source

2

“……已完全成为主流，使Linux变得非常轻便”，并证明当时的Linux可移植性还为时过早。

2

@罗杰：我真的不能同意。这些功能已成为主流-但是从那时起，CPU增加了更多功能，其中许多Linux要么被完全忽略，要么仅使用很少，要么必须进行大量（且痛苦地）重写才能合理使用。与此同时，莱纳斯也至少有一些观点：一些作品相当好，现在（甚至非可移植）次的东西，被谈论多年，但从未完成（如GNU HURD）。

— 杰里·科芬

@Jerry-听起来像是我以前工作过的地方的研究项目：“您现在应该放弃。我正在努力的工作将使您所做的一切过时”。那是20年前。仍然没有看到奇妙的新东西离开研究实验室。

— quick_now 2011年

@Roger，可移植性不是优化。

7

作为从事过许多Java工作并每周经历“一次编写，到处调试”现象的人，多年以来，我可以与之充分联系。

Java可能是一个温和的例子。我什至无法开始想象人们会尝试如何尝试使用一种语言/工具包中的可移植代码库，而该语言/工具包甚至都不是可移植的。

目前，我们正在研究为移动设备编写精简版产品之一的想法。我已经对如何为J2ME和Android制作可移植版本进行了一些研究-尝试共享尽可能多的代码库（显然本身不能完全“便携”，但这是类似的哲学）。这是一场噩梦。

是的，有时候，能够为特定工作使用特定工具进行思考（并做）真的很好。即针对一个单一的整体平台/环境自由开发。并且只需为每个脚本编写单独的干净版本。

— 鲍比表
source

5

尽管有些人认为/对待可移植性，遵循标准等在道义上是高级的，或按其要求行事，但这实际上归结为经济学。

编写可移植代码在使代码可移植方面付出了很多努力，并且（通常）具有某些并非在所有目标设备上都可用的功能。

当/如果您关心新的体系结构时，非便携式代码在移植代码方面会付出一定的代价，并且（通常）会覆盖一些在原始目标上不可用（或不可用）的功能。

最重要的限定条件是“何时/如果您关心新架构”。编写可移植的代码需要付出努力的前期在希望的是能够使用新的/不同的架构，代码很少或根本没有努力最终回报的。不可移植的代码使您可以延迟在移植上的投资，直到（至少合理地）确定确实需要移植到某个特定目标为止。

如果您预先确定要移植到许多目标，那么通常值得预先投资以最大程度地减少长期移植成本。如果您不确定需要移植多少代码，那么编写不可移植的代码可以最大程度地减少前期成本，从而延迟甚至完全避免使代码可移植的成本。

我认为值得一提的是，我所说的“便携式”和“非便携式”好像两者之间有明确的区分。实际上，事实并非如此-可移植性是一个连续的过程，从完全不可移植（例如，汇编代码）到高度可移植（例如，Info-zip）以及介于两者之间的任何地方。

— 杰里·科芬
source

4

Tanenbaum指出，许多Linux是采用非模块化方式编写的，以利用386 CPU（当时的最新技术），而不是使CPU交互成为组件，因此非常容易互换。Tanenbaum本质上认为，内核是如此单一并且绑定到386 CPU的事实使得很难做到这一点，

将Linux本身移植到另一个CPU平台（显然不正确，AMD64，PowerPC等）
将为linux x86编写的程序移植到另一个CPU架构（同样不正确）

linux阵营提出了几点，其中包括：

Linux提供了多线程文件系统作为设计的一部分
微内核虽然有趣且直观，但性能却不是很好
便携式API的遵守使可移植性问题比阻止程序更多或微不足道。

— 阿纳托利G
source

1

现在继续讨论……在辩论之时，可移植性是一个更大的问题。AMD64和PPC诞生了很多年。

— Matt Olenik

1

您是绝对正确的-但是，包括Linus在内的其他人则指出，这与Tanenbaum所关注的并没有那么大的关注

— Anatoly G

微内核性能不好？这将使使用它们的我们感到震惊。

— 我的正确观点

我不认为微内核不能很好地工作-我使用Mach（OsX），而且效果很好。但是，Linus确实提到了这一点。

— Anatoly G

3

如果要编写可移植的代码，则必须编写可移植的代码。

那是什么意思

设计必须反映目的。例如，如果语言是C，则对其进行设计，以使最少的代码行数需要更改才能起作用。这通常意味着将显示与计算分开，这始终是一种好的设计理念（MVC）。只要您可以使用一个好的编译器，大多数C代码都可以在任何地方编译。利用它并尽可能多地编写通用代码。

顺便说一句，此答案仅适用于申请。OS和嵌入式完全是另一种动物。

— 迈克尔·K
source

2

照原样解释此陈述。

在Linus的另一篇引文中，他说：“ C ++试图解决所有错误的问题。C++ 解决的事情是琐碎的事情，几乎是对C的纯粹语法扩展，而不是解决一些真正的深层问题”。

同样在他的传记中，“ Just For Fun” linus在引用微内核时说，对于复杂性为'n'的问题，如果将问题划分为'1 / n'唯一部分，那么开发这种系统的总复杂性将成为“ n！” 这本身就是一个足以不尝试这种事情的因素，并且从这样一个复杂的系统中提取效率将非常困难。

— 潘卡多哈雷
source

2

您必须考虑以下事实：在这些辩论中，Linux是非常新的，并且在很大程度上仅是386操作系统。我想如果您今天问莱纳斯，他会有不同的看法。也许不如Tannenbaums极端，但他可能会点头，说他在某些事情上是对的。

Linus和其他内核开发人员为使Linux具有可移植性而经历了很多痛苦，但是再说一次，如果Linus必须首先使它具有可移植性，那么Linux可能永远不会存在。

— 埃里克·冯肯布施
source

2

这意味着可以编写出色程序的人员不需要具有可移植性，因为它们可以从头开始工作。

希望将其他程序（可移植性）“导入”当前程序的天才程序员很少。

— 汤
source