在展示应用程序时，Windows 和 Mac 主要谈论功能。另一方面，Linux 应用程序有更多关于使用什么语言编写它（以及附带的库）的详细信息，而不是功能。这是为什么？
我可以理解知道 GTK+ 与 QT 之间的差异只是因为桌面集成要求而产生差异，但是 C、C++、Python、汇编、等等？真的吗？
例如： foo 是用 C/GTK+ 编写的简单的 blah blah。
答案1
我认为传统的Linux用户（一个真正自己安装系统的极客修补匠）确实关心这些信息（这个工具背后的技术是什么？）。我也是那些极客之一，例如，我会避免安装和使用某个软件包，只是因为它使用了一些我不喜欢的技术。当然，有些人将这种行为称为宗教。很傻不是吗？
无论如何，我可以想到两个原因：
打包者也和那些 Linux 用户一样极客（如果不是更极客的话），所以他们发现添加此类信息是个好主意。
我认为当这些包装商将此类信息放在他们的包装描述中时，他们很可能将其作为某种形式的促销。它有时会起作用（它对我有用过好几次）。
当然这只是一个猜测。
答案2
我的感觉是它与四个软件自由中的第二个:
研究程序如何工作并对其进行更改以使其按照您的意愿运行的自由（自由 1）。获得源代码是实现这一点的先决条件。
公开语言（或其他技术特性）支持人们的选择能力，并鼓励精通这些语言的人参与项目。
答案3
这可能有部分历史原因。即使在不久的过去，个人系统管理员也通常会构建和安装在其系统上运行的所有内容。
关于使用什么语言和库来实现工具的注释可以向管理员提示该过程将需要完成多少工作他们的系统。
在这个包管理工具无处不在且影响深远的时代，这有点不合时宜，但 Unix 文化是保守的，不会丢弃看起来有效的东西，所以这种习惯还需要一段时间才能消失。
答案4
Unix，以及现在的 LInux 和 BSD，一直都有一个非常破碎的软件基础，而在最近的过去存在着更加多样化的硬件基础。重要的是要知道某些软件在您系统上的解释器中运行，或者您可以编译源代码。如果您没有 Common Lisp 解释器，或 Tcl 解释器或任何解释器，您不想费心下载源代码，却发现无法运行它。
对某些东西使用的语言进行描述可以避免浪费大量时间。