在展示应用程序时,Windows 和 Mac 主要谈论功能。另一方面,Linux 应用程序有更多关于使用什么语言编写它(和附带的库)而不是功能的详细信息。这是为什么?
我可以理解 GTK+ 与 QT 之间的区别仅仅因为桌面集成要求而有所不同,但是 C 与 C++ 与 Python 与汇编与等等?真的吗?
例如:foo 是一个用 C/GTK+ 编写的简单的废话。
tsh*_*ang 21
我认为传统的 Linux 用户(一个真正自己安装系统的极客修补匠)确实关心这些信息(这个工具背后的技术是什么?)。例如,我也是那些极客中的一员,他们会避免安装和使用软件包,因为它使用了一些我不喜欢的技术。当然,有些人称这种行为为宗教。傻不是吗?
无论如何,我可以想到两个原因:
打包者也与那些 Linux 用户一样令人讨厌(如果不是更多),因此他们发现添加此类信息是个好主意。
我认为当这些包装商在他们的包装描述中添加此类信息时,他们很可能将其作为某种形式的促销。它有时有效(它对我有用过好几次)。
这当然只是猜测。
use*_*own 10
延伸到jasonwryans 的回答:
如果你说出它是用什么语言编写的,那么接收它的人就可以估计提供补丁、获得一些见解或扩展程序的难度。
当然,这仅在您是程序员时才有意义。
你在哪里看到的总结?在存储库中,还是在 .deb 或 .rpm 之类的包中?
如果您从源代码构建它,这些信息可能有助于确定您是否必须安装其他东西(编译器、库、构建工具)。
dmc*_*ten 10
这可能部分是历史性的。即使在不那么遥远的过去,个别系统管理员通常会构建和安装在其系统上运行的所有内容。
关于用于实现工具的语言和库的注释向管理员提供了有关该过程将为他们的系统进行多少工作的提示。
在这个无处不在和影响深远的包管理工具的时代,这有点不合时宜,但 unix 文化在不丢弃似乎有效的东西的意义上是保守的,所以习惯消亡还需要一段时间。
Unix,以及现在的 LInux 和 BSD,总是有一个非常破碎的软件基础,而且在最近的过去存在一个更加多样化的硬件基础。重要的是要知道某些软件在您系统上的解释器中运行,或者您可以编译源代码。如果您没有 Common Lisp 解释器、Tcl 解释器或任何解释器,您就不想费心下载源代码,结果却发现无法运行它。
对某事物所用语言的描述可以避免浪费大量时间。
| 归档时间: |
|
| 查看次数: |
858 次 |
| 最近记录: |