让我们翻过一页页 Linux 的新闻报道，你会发现其中对一些冷门的 Linux 发行版的报道数量却出乎预料的多。像 Elementary OS 和 Solus 这样的新发行版因其华丽的界面而被大家所关注，而搭载 MATE 桌面环境的那些系统则因其简洁性而被广泛报道。

感谢像《黑客军团》这样的电视节目，我完全可以预料到关于 Kali Linux 系统的报道很快就会增加。

尽管有很多关于 Linux 系统的报道，然而有一个被广泛使用的 Linux 发行版几乎被大家完全遗忘了：Arch Linux 系统！

关于 Arch 的新闻报道很少的原因有很多，不仅仅是因为它很难安装，而且你还得能在命令行下娴熟地完成各种配置以使其正常运行。更糟糕的是，以大多数的用户的观点来看，其困难是设计之初就没有考虑过其复杂的安装过程会令无数的菜鸟们望而却步。

这的确很遗憾，在我看来，实际上一旦安装完成后，Arch 比我用过的其它 Linux 发行版易用得多。

确实如此，Arch 的安装过程很让人蛋疼。有些发行版的安装过程只需要点击“安装”后就可以放手地去干其它事了。Arch 相对来说要花费更多的时间和精力去完成手动分区、手动挂载、生成 fstab 文件等。但是从 Arch 的安装过程中，我们学到很多。它掀开帷幕，让我们弄明白很多背后的东西。事实上，这层掩盖底层细节的帷幕已经彻底消失了，在 Arch 的世界里，你就是帷幕背后的主宰。

除了大家所熟知的难于安装外，Arch 甚至没有自己默认的桌面环境，虽然这有些让人难以理解，但是 Arch 也因其可定制化而被广泛推崇。你可以自行决定在 Arch 的基础软件包上安装的任何东西。

虽然你可以视之为无限可定制性，但也可以说它完全没有定制化。比如，不像 Ubuntu 系统那样，Arch 中几乎没有修改过或是定制开发过的软件包。Arch 的开发者从始至终都使用的是上游开发者提供的软件包。对于部分用户来说，这种情况非常棒。比如，你可以使用“纯粹”的 GNOME 桌面环境。但是，在某些情况下，定制的补丁可以解决一些上游开发者没有处理的很多的缺陷。

由于 Arch 缺乏一些默认的应用程序和桌面系统，以至于很难形成一致的看法——或者根本不会有什么真正的看法，因为我安装的毫无疑问和你安装的不会一样。我可能选择安装最小化安装配置 Openbox、tint2 和 dmenu，你可能却是使用了最新版的 GNOME 桌面系统。我们都在使用 Arch，但我们的体验却是大相径庭。对于任何发行版来说也有这种情况，但是其它大多数的 Linux 系统都至少有个默认的桌面环境。

然而对 Arch 的看法还是由很多共性的元素的。比如说，我使用 Arch 系统的主要原因是因为它是一个滚动更新的发行版。这意味着两件事情。首先，Arch 会尽可能的使用最新的内核，只要它们可用，被认为稳定就行。这就意味着我可以在 Arch 系统里测试一些在其它 Linux 发行版中难于测试的东西。滚动版另外一个最大的好处就是所有软件更新就绪就会被即时发布出来。这不仅意味着软件包更新速度更快，而且意味着不会出现破坏掉系统的大规模更新。

很多用户因为 Arch 是一个滚动发行版认为它不太稳定。但是在我使用了 9 个多月之后，我并不赞同这种观点。

然而，我从未因为一次升级系统而搞坏过任何东西。我确实有过回滚，因为系统启动分区 /boot 没有挂载，但是后来我发现那完全是自己操作上的失误，我更新后而忘记写入改变。一些暴露出来的缺陷（比如我关于戴尔 XPS 笔记本触摸板又出现以前解决过的问题）很快被修复，并且更新速度要比其它非滚动发行版快得多。总的来说，我认为 Arch 滚动更新的发布模式比其它我在用的发行版要稳定得多。唯一一点我要强调的是查阅维基上的资料，多关注你要更新的内容。

我怀疑 Arch 之所以没那么受欢迎，主要原因就是你必须要随时小心你的操作。盲目的更新 Arch 系统是极其危险的。但是任何一个发行版的更新都有风险，你只是认为它没有风险而已——因为你别无选择。

Arch 的哲学理念是我支持它的另外一个最主要的原因。我认为 Arch 最吸引用户的一点就是：“（Arch）面向的是专业的 Linux 用户，或者是有 DIY 精神，愿意查资料并解决问题的人”。

随着 Linux 进一步纳入主流，开发者们更需要顺利地渡过每一个艰难的技术领域。那些晦涩难懂的专有软件方面的经验恰恰能反映出用户高深的技术能力。

尽管在这个时代听起来有些怪怪的，但是事实上我们很多人更愿意自己动手装配一些东西。在这种情形下，Arch 将会是Linux DIY 用户的终极圣地。

via: http://www.theregister.co.uk/2016/11/02/arch_linux_taster/

作者：Scott Gilbertson 译者：rusking 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

信不信由你,Windows XP 上个月市场份额上升

最近几个月 Windows XP 市场表现

微软自 2014 年 4 月停止了对 Windows XP 的支持，即便如此，已存在 15 年的 Windows XP 仍然在全世界很多地方使用着。而且，最近，Windows XP 的市场份额还在上升。

从 NetMarketShare 提供的统计看， 2016 年 11 月显示 Windows XP 不但不在下降，反而还在上升。考虑到该系统已不再被支持，这个现象是令人惊讶和担忧的。

现在， Windows 7 以 47.17% 的市场占有率成为市场的领导者，紧跟其后的是 Windows 10，23.72%。15 年前发行的 Windows XP 为第三常用桌面操作系统，8.63%，甚至要高于 Windows 8.1， 8.01%。

Windows XP 今年初市场占有率为 11.42%，然后逐渐降到 7 月份 9.78%。之后开始上升，8月到达 10.34% 后又开始下降。11 月市场再次抬头，根据之前的市场表现，预计从 12 月之后 Windows XP 可能会失去部分市场份额。

谁还在使用 Windows XP? 你可能好奇，既然从 2014 年之后不再提供更新和安全补丁，现在什么人还在使用 Windows XP 呢？答案很简单： 政府部门以及一些不想更换新电脑的老硬件电脑主人。 大多情况下，仍在使用 Windows XP 的政府和组织之所以延迟升级到新系统，是因为需要更换硬件以及兼容性问题，之前为 Windows XP 开发的关键应用也需要移植到新操作系统。

仍旧运行 Windows XP 将用户和他们的数据置于某些风险之下，而且现在它的市场份额仍在增长绝对不是什么好消息。

开源的 Xen 4.8 Hypervisor 发布

2016 年 12 月 6日, Linux 基金会主持的 Xen 项目宣布发布 Xen 4.8 hypervisor，它是强大的虚拟化开源工业标准。

距离 Xen 4.7 系列发布已过去 5 个多月，开发组继续改进软件，增加新功能。Xen 4.8 是最新的稳定版本，重点在高级嵌入式使用用例并增强了对基于 ARMv8-A 的服务器的支持。

Xen 4.8 hypervisor 的大的改进包括开始支持 ARM server Live Patching，也就是说，允许用户无需重启即可应用安全补丁， 支持带有 MSI 能力的 GICv2m 中断控制器，以及 包含特定缓存需求的 mmio-sram 和 IO 内存区。

Ubuntu Linux 上 KDE Frameworks 5 发布 Snap 格式

KDE Frameworks 5 发布 Snap 格式的软件包，KDE 开发人员可以用它来开发 KDE 应用。

KDE 社区开发者 Harald Sitter 最近一直在致力于做一个共享版的 KDE Frameworks Snap, 使 Ubuntu 和其他 GNU/Linux 发布版本的 KDE 应用打包更加简单。

在最近博客中，他说到，他成功将 KDE 应用捆绑为 Snap，以使它们尽可能小。Snap 和 Flatpak 二进制包过大，对大多数用户来说都是一个问题。为了让多数人接受 Snaps 和 Flatpaks，它们必须足够小。感谢 Harald Sitter 的辛苦工作， 现在 Ubuntu Store 有一个 KDE Frameworks 5 contect Snap 可以使用，主要思想是通过共享一个公用库和其他跨平台的内容，使应用本身尽可能小。例如， KCalc 就只有 312 KB。

具体请参见 Harald Sitter 的完整博文。

Canonical 和 System76 继续增强 Ubuntu Linux 对 Unity7 HiDPI 支持

2016 年 12 月 5 日,Canonical的 Michael Hall 宣布，System76 在与 Canonical 合作，正在共同致力于提升 Ubuntu Linux 对 HiDPI 的支持。

最近几周以来，Ubuntu 和 System76 的开发人员一直在努力合作，以对 Ubuntu Linux 的 Unity 7 用户界面增强 HiDPI 支持，现在他们已经有一些补丁，目前我们还不知道哪些 Ubuntu 版本将接受这些补丁，不过估计至少应该在 Ubuntu 16.04 LTS (Xenial Xerus) 和 Ubuntu 16.10 (Yakkety Yak)中可用。

Devuan GNU/Linux 继续推动不带 Systemd 的 Debian 的发展

Devuan GNU/Linux 1.0.0 新的开发版本 Beta 2， 也是第一个稳定版本, 在 2016 年 11 月的最后一天发布。

“做了一些重要的修复和更新，我们继续提供不带 systemd 的 Debian，并宣布发布 Devuan Jessie Beta2。” 邮件列表中写道。

Devuan 开发人员同时指出，Devuan GNU/Linux 1.0.0 的开发周期会在 2017 年继续，先是 RC 版本，之后预计几周后发布最终版本。好消息是 Devuan GNU/Linux 1.0.0 正式版将在 2017 初发布。

脚本是存储在一个文件的一系列命令。在终端上输入一个个命令，按顺序执行的方法太弱了，使用脚本，系统中的用户可以在一个文件中存储所有命令，反复调用该文件多次重新执行命令。

在学习脚本或写脚本的初期阶段，我们通常从写小脚本或者几行命令的短脚本开始，调试这样的脚本时我们通常无非就是通过观察它们的输出来确保其正常工作。

然而，当我们开始写非常长或上千行命令的高级脚本，例如改变系统设置的脚本，在网络上执行关键备份 等等，我们会意识到仅仅看脚本输出是不足以在脚本中找到 Bug 的！

因此，在 Linux 系列中这篇介绍 Shell 脚本调试， 我们将看看如何启用 Shell 脚本调试，然后在之后的系列中解释不同的 Shell 脚本调试模式以及如何使用它们。

如何开始写一个脚本

一个脚本与其它文件的区别是它的首行，它包含 #! （She-Bang - 释伴：定义文件类型）和路径名（解释器路径），通知系统该文件是一个命令集合，将被指定程序(解释器)解释。

下面是不同类型脚本 首行 示例：

#!/bin/sh          [sh 脚本]
#!/bin/bash        [bash 脚本] 
#!/usr/bin/perl    [perl 程序]
#!/bin/awk -f      [awk 脚本]   

注意：如果脚本仅包含一组标准系统命令，没有任何内部 Shell 指令，首行或 #! 可以去掉。

如何在 Linux 操作系统执行 Shell 脚本

调用一个脚本脚本的常规语法是：

$ 脚本名  参数1 ... 参数N

另一种可能的形式是明确指定将执行这个脚本的 Shell，如下：

$ shell 脚本名  参数1 ... 参数N

示例：

$ /bin/bash   参数1 ... 参数N     [bash 脚本]
$ /bin/ksh   参数1 ... 参数N      [ksh 脚本]
$ /bin/sh   参数1 ... 参数N       [sh 脚本]

对于没有 #! 作为首行，仅包含基础系统命令的脚本，示例如下：

### 脚本仅包含标准系统命令
cd /home/$USER
mkdir tmp
echo "tmp directory created under /home/$USER"

使它可执行并运行，如下：

$ chmod +x  脚本名
$ ./脚本名 

启用 Shell 脚本调试模式的方法

下面是主要的 Shell 脚本调试选项：

• -v （verbose 的简称） - 告诉 Shell 读取脚本时显示所有行，激活详细模式。
• -n （noexec 或 no ecxecution 简称） - 指示 Shell 读取所有命令然而不执行它们，这个选项激活语法检查模式。
• -x （xtrace 或 execution trace 简称） - 告诉 Shell 在终端显示所有执行的命令和它们的参数。 这个选项是启用 Shell 跟踪模式。

1、 改变 Shell 脚本首行

第一个机制是改变 Shell 脚本首行，如下，这会启动脚本调试。

#!/bin/sh 选项

其中， 选项可以是上面提到的一个或多个调试选项。

2、 调用 Shell 调试选项

第二个是使用如下调试选项启动 Shell，这个方法也会打开整个脚本调试。

$ shell 选项   参数1 ... 参数N

示例：

$ /bin/bash 选项   参数1 ... 参数N

3、 使用 Shell 内置命令 set

第三个方法是使用内置命令 set 去调试一个给定的 Shell 脚本部分，如一个函数。这个机制是重要的，因为它让我们可以去调试任何一段 Shell 脚本。

我们可以如下使用 set 命令打开调试模式，其中选项是之前提到的所有调试选项。

$ set 选项 

启用调试模式：

$ set -选项

禁用调试模式：

$ set +选项

此外，如果我们在 Shell 脚本不同部分启用了几个调试模式，我们可以一次禁用所有调试模式，如下：

$ set -

关于启用 Shell 脚本调试模式，先讲这些。正如我们看到的，我们可以调试一整个 Shell 脚本或者特定部分脚本。

在此系列下面的两篇文章中，我们会举例介绍如何使用 Shell 脚本调试选项，进一步了解 详细 （ verbose ） 、 语法检查 （ syntax checking ） 、 跟踪 （ tracing ） 调试模式。

更重要的是，关于这个指南，欢迎通过下面评论提出任何问题或反馈。

via: http://www.tecmint.com/enable-shell-debug-mode-linux/

作者：Aaron Kili 译者：imxieke 校对：jasminepeng

本文由 LCTT 组织编译，Linux中国 荣誉推出

简介：这篇详细的指南将向你展示如何在 Linux 和 Windows 之间共享 Steam 的游戏文件以节省下载的总用时和下载的数据量。我们将展示给你它是怎样为我们节约了 83% 的数据下载量。

假如你决心成为一名 Linux 平台上的玩家，并且在 Steam 上拥有同时支持 Linux 和 Windows 平台的游戏，或者基于同样的原因，拥有双重启动的系统，则你可以考虑看看这篇文章。

我们中的许多玩家都拥有双重启动的 Linux 和 Windows。有些人只拥有 Linux 系统，但同时拥有当前还没有被 Linux 平台上的 Steam 支持的游戏。所以我们同时保留这两个系统以便我们可以在忽略平台的前提下玩我们喜爱的游戏。

幸运的是 Linux 游戏社区应运而生，越来越多在 Windows 平台上受欢迎的 Steam 游戏也发布在 Linux 平台上的 Steam 中。

我们中的许多人喜欢备份我们的 Steam 游戏，使得我们不再苦苦等待游戏下载完成。这些游戏很大程度上是 Windows 平台下的 Steam 游戏。

现在，很多游戏也已经登陆了 Linux 平台上的 Steam，例如 奇异人生 （ Life is Strange ） 、 古墓丽影 2013 （ Tomb Raider 2013 ） 、 中土世界：魔多阴影 （ Shadow of Mordor ） 、 幽浮：未知敌人 （ XCOM: Enemy Unknown ） 、幽浮 2、 与日赛跑 （ Race The Sun ） 、 公路救赎 （ Road Redemption ） 、 燥热 （ SUPERHOT ） 等等，并且这份名单一直在增长。甚至还有 杀出重围：人类分裂 （ Deus Ex: Mankind Divided ） 和 疯狂的麦克斯 （ Mad Max ） ！！！在一些游戏的 Windows 版发布之后，现在我们不必再等候多年，而只需等待几月左右，便可以听到类似的消息了，这可是大新闻啊！

下面的实验性方法将向你展示如何使用你现存的任何平台上游戏文件来在 Steam 上恢复游戏的大部分数据。对于某些游戏，它们在两个平台下有很多相似的文件，利用下面例子中的方法，将减少你在享受这些游戏之前的漫长的等待时间。

在下面的方法中，我们将一步一步地尝试利用 Steam 自身的备份与恢复功能或者以手工的方式来达到我们的目的。当涉及到这些方法的时候，我们也将向你展示这两个平台上游戏文件的相同和不同之处，以便你也可以探索并做出你自己的调整。

下面的方法中，我们将使用 Ubuntu 14.04 LTS 和 Windows 10 来执行备份与恢复 Steam 的测试。

1、Steam 自身的备份与恢复

当我们尝试使用 Windows 平台上 Steam 中《 燥热 （ SUPERHOT ） 》这个游戏的备份（这些加密文件是 .csd 格式）时，Linux 平台上的 Steam 不能识别这些文件，并重新开始下载整个游戏了！甚至在做了验证性检验后，仍然有很大一部分文件不能被 Steam 识别出来。我们在 Windows 上也做了类似的操作，但结果是一样的！

现在到了我们用某些手工的方法来共享 Windows 和 Linux 上的 Steam 游戏的时刻了！

2、手工方法

首先，让我们先看看 Linux 下这些游戏文件所处的位置（用户目录在 /home 中）：

这是 Linux 平台上 Steam 游戏的默认安装位置。 .local 和 .steam 目录默认情况下是不可见的，你必须将它们显现出来。我们将推荐使用一个自定义的 Steam 安装位置以便更容易地处理这些文件。这里 SUPERHOT.x86_64 是 Linux 下原生的可执行文件，与 Windows 中的 .exe 文件类似。

下图展示的位置包含我们需要的大部分文件（在 Windows 和 Linux 平台上相同）：

下面我们来看看这些 .acf 格式的文件。appmanifest_322500.acf 便是那个我们需要的文件。编辑并调整这个文件有助于 Steam 识别在 common 这个目录下现存的非加密的原始文件备份：

为了确认这个文件是一样的，用编辑器打开这个文件并检查它。我们越多地了解这个文件越好。这个链接是来自 Steam 论坛上的一个帖子，它展示了这个文件的主要意义。它类似于下面这样：

“AppState”
{
“appid”        “322500”
“Universe”        “1”
“name”        “SUPERHOT”
“StateFlags”        “4”
“installdir”        “SUPERHOT”
“LastUpdated”        “1474466631”
“UpdateResult”        “0”
“SizeOnDisk”        “4156100762”
“buildid”        “1234395”
“LastOwner”       “<SteamID>”
“BytesToDownload”        “909578688”
“BytesDownloaded”        “909578688”
“AutoUpdateBehavior”        “0”
“UserConfig”
{
“Language”        “english”
}
“MountedDepots”
{
“322503”        “1943012315434556837”
}
}

在 Linux 平台上卸载游戏后我们再进行测试。现在让我们看看在 Windows 10 上相同的游戏安装目录里包含哪些内容：

我们复制了 SUPERHOT 目录和 .acf 格式的清单文件（这个文件在 Windows 的 Steam 上格式是一样的）。在复制 .acf 文件和游戏目录到 Linux 中 Steam 它们对应的位置时，我们需要确保 Steam 没有在后台运行。

在转移完成之后，我们运行 Steam 并看到了这个：

所以下图显示只需要有 235.5 MB 的文件需要下载，而不是整个 867.4 MB，这意味着超过 70% 的文件已经被 Steam 识别了:) ！相对来说，节省了一笔大量的时间开销。当然不同的游戏可能有所不同，但对于那些网速居于平均水平或以下的玩家来说，这种方法绝对值得一试，尤其是考虑到当前那些 40-50 GB 大小的重量级游戏。

我们还进行了其他几种尝试：

• 我们尝试使用 Linux 下原有的清单文件（.acf）和来自 Windows 的手工备份文件，但结果是 Steam 重新开始下载游戏。
• 我们看到当我们将 SUPERHOT_Data 这个目录中的 SH_Data 更换为 Windows 中的对应目录时，同上面的一样，也重新开始下载整个游戏。

理解清单目录的一个尝试

清单目录绝对可以被进一步地被编辑和修改以此来改善上面的结果，使得 Steam 检测出尽可能多的文件。

在 Github 上有一个项目，包含一个可以生成这些清单文件的 python 脚本。任何 Steam 游戏的 AppID 可以从SteamDB 上获取到。知晓了游戏的 ID 号后，你便可以用你喜爱的编辑器以下面的格式创建你自己的清单文件 appmanifest_<AppID>.acf。在上面手工方法中，我们可以看到 SUPERHOT 这个游戏的 AppID 是 322500，所以对应的清单文件名应该是 appmanifest_322500.acf。

下面以我们知晓的信息来尝试对该文件进行一些解释：

“AppState”                                   // 应用（游戏）的状态
“appid”        “322500”                    // 游戏的 AppID
“Universe”        “1”
“name”        “SUPERHOT”                   // 游戏的名称
“StateFlags”        “4”
“installdir”        “SUPERHOT”             // 安装目录的名称
“LastUpdated”        “1474466631”
“UpdateResult”        “0”
“SizeOnDisk”        “4156100762”
“buildid”        “1234395”
“LastOwner”        “<SteamID>”             // 唯一的帐号拥有者的 <SteamID> 
“BytesToDownload”        “909578688”       // 将这个数字除以 1073741824(1024 x 1024 x 1024) 便可以计算出还需要下载的数据大小，以 GB 记。
“BytesDownloaded”        “909578688”       // 已下载数据的大小， 以 Bytes 记。
“AutoUpdateBehavior”        “0”            // 当这个设为 0 时，该游戏将自动升级。

“UserConfig”                                 // 用户的配置信息
{
“Language”        “english”
}
“MountedDepots”                              //  这个部分大多与游戏的 DLC 相关。
{
“322503”        “1943012315434556837”
}
}

通过计算下载的数据的大小，你可以将它与 Steam 展现的信息进行比较并进行更多的调整。

假如你知道更多关于清单文件或者手工方式中另外可以改进的方法，请在评论中分享给大家。我们打算去发现更多的关于这些文件格式的信息，当前在官方的 Valve 开发者社区 或者 Steam 论坛 上我们还没有发现完整的文档。

至少现在为止，这些便是我们知道的在 Linux 和 Windows 之间分享 Steam 游戏的最好方法了。

via: https://itsfoss.com/share-steam-files-linux-windows/

作者：Avimanyu Bandyopadhyay 译者：FSSlc 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

我们使用 Linux 是因为它比其他操作系统更实用，还是其他更高级的理由呢？

运行 Linux 的最吸引人的事情之一就是它所提供的自由。 Linux 社区之间的分野在于我们如何看待这种自由。

对一些人来说，使用 Linux 可以享受到不受供应商限制或避免高昂的软件成本的自由。大多数人会称这个是一个实用性的考虑。而其它用户会告诉你，他们享受的是自由软件的自由。那就意味着拥护支持 自由软件运动 Free Software Movement 的 Linux 发行版，完全避免专有软件和所有相关的东西。

在这篇文章中，我将带你比较这两种自由的区别，以及它们如何影响 Linux 的使用。

专有的问题

大多数 Linux 用户有一个共同点，就是他们尽量避免使用专有软件。对像我这样的实用主义的爱好者来说，这意味着我能够控制我的软件支出，以及避免过度依赖特定供应商。当然，我不是一个程序员……所以我对安装软件的调整是十分微小的。但也有一些个别情况，对应用程序的小调整就意味着它要么能工作，要么不能。

还有一些 Linux 爱好者，倾向于避开专有软件，因为他们觉得使用它们是不道德的。通常这里主要的问题是使用专有软件会剥夺或者干脆阻碍你的个人自由。像这些用户更喜欢使用 Linux 发行版和软件来支持 自由软件理念 。虽然它与开源的概念相似并经常直接与之混淆，但它们之间还是有些差异的 。

因此，问题就在这里：像我这样的用户往往将便利性置于纯粹的软件自由的理念之上。不要误会我的意思，像我这样的人喜欢使用符合自由软件理念的软件，但我们也更有可能做出让步（使用专有软件），以完成特定的任务。

这两种类型的 Linux 爱好者都喜欢使用非专有软件的解决方案。但是，自由软件倡导者根本不会去使用专有软件，而实用主义用户会选择具有最佳性能的工具。这意味着，在有些情况下，这些用户会在他们的非专有操作系统上运行专有应用或代码。

最终，这两种类型的用户都喜欢使用 Linux 所提供的非专有解决方案。但是，我们这样做的原因往往会有所不同。有人认为那些不支持自由软件的人是无知的。我不同意这种看法，我认为它是实用方便性的问题。那些喜欢实用方便性的用户根本不关心他们软件的政治问题。

实用方便性

当你问起绝大多数的人为什么使用他们现在的操作系统，回答通常都集中于实用方便性。方便性可能体现在“它是我一直使用的系统”，乃至于“它运行了我需要的软件”。 其他人可能进一步解释说，软件对他们使用操作系统的偏好影响不大，而是对操作系统的熟悉程度的问题，最后，还有一些特殊的“商业考虑”或硬件兼容性等问题也导致我们使用这个操作系统而不是另一个。

这可能会让你们中许多人很惊讶，不过如今我运行桌面 Linux 最大的一个原因是由于我熟悉它。即使我能为别人提供 Windows 和 OS X 的支持，实际上我使用这些操作系统时感觉相当沮丧，因为它们根本就不是我习惯的用法。也因此我对那些 Linux 新手表示同情，因为我太懂得踏入陌生的领域是怎样的让人恼火了。我的观点是这样的 —— 熟悉具有价值，而且熟悉加强了实用方便性。

现在，如果我们把它和一个自由软件倡导者的需求来比较，你会发现这种人都愿意学习新的甚至更具挑战性的东西，以避免使用非自由软件。对这种用户，我最赞赏的地方，就是他们坚定的采取少数人选择的道路来坚持他们的原则，在我看来，这是十分值得赞赏的。

自由的价值

我不羡慕那些自由软件倡导者的一个地方，就是根据 自由软件基金会 Free Software Foundation 规定的标准，为实现其自由，他们要始终使用 Linux 发行版和硬件而付出的额外工作。这意味着 Linux 内核需要摆脱专有的驱动支持，而且硬件不需要任何专有代码。当然不是不可能的，但确实很难。

一个自由软件倡导者可以达到的最好的情况是硬件是“自由兼容”的。有些供应商，可以满足这一需求，但大多提供的硬件依赖于 Linux 兼容的专有固件。实用主义用户对自由软件倡导者来说是个搅局者。

那么这一切意味着的是，倡导者必须比实用主义的 Linux 爱好者，更加警惕。这本身并不一定是坏事，但如果是打算跳入自由软件的阵营那就要考虑下了。比较而言，实用主义的用户可以不假思索地使用与 Linux 兼容的任何软件或硬件。我不知道你是怎么想的，但在我眼中这样更轻松一点。

定义自由软件

这一部分可能会让一部分人不高兴，因为我不相信自由软件只有一种。从我的立场，我认为真正的自由是能够在一个特定情况下在所有可用的数据里，用最适合这个人生活方式的方法来解决。

对我来说，我更喜欢使用能满足我所有需求的 Linux 桌面，这包括使用非专有软件和专有软件。尽管有人认为专有软件限制了我的个人自由，但我必须反驳这一点，因为我有优先使用它的自由，即选择的自由。

或许，这也就是为什么我更认同 开源软件 Open Source Software 的理想，而不是坚持 自由软件运动 Free Software movement 的理念。我更愿意和这样的人群在一起，他们不会花时间告诉我，我使用对我最适合的方式却是错误的。根据我的经验，这些开源的人群仅仅是感兴趣去分享自由软件的优点，不带有自由软件的理想主义的激情。

我觉得自由软件的概念很棒。而且对那些需要活跃在软件政治，并向大众指出使用专有软件的缺陷的人来说，我认为 Linux ( GNU/Linux ) 行动是一个不错的选择。而像我这样的实用主义用户可能从自由软件的支持者转向，如本文中所说。

当我介绍 Linux 的桌面时，我富有激情地分享它的实际优点。如果我成功地让他们享受这一经历，我鼓励用户自己去发现自由软件的观点。但我发现大多数人使用 Linux 并不是因为他们想拥抱自由软件，而仅仅是他们想要最好的用户体验。也许只有我是这样的观点，很难说。

你怎么认为呢？你是一个自由软件倡导者吗？也许你倾向于在桌面 Linux 发行版中使用专有软件/代码？那么评论和分享您的 Linux 桌面体验吧！

via: http://www.datamation.com/open-source/linux-practicality-vs-activism.html

作者：Matt Hartley 译者：joVoV 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

软件工具通常情况下会提供多个功能以供选择，但是如你所知的，不是所有的功能都能被每个人用到的。公正地讲，这并不是设计上的错误，因为每个用户都会有自己的需求，他们只在他们的领域内使用该工具。然而，深入了解你所使用的工具也是很有益处的，因为你永远不知道它的某个功能会在什么时候派上用场，从而节省下你宝贵的时间。

举一个例子：编译器。一个优秀的编程语言编译器总是会提供极多的选项，但是用户一般只知道和使用其中很有限的一部分功能。更具体点来说，比如你是 C 语言开发人员，并将 Linux 作为你的开发平台，那么你很有可能会用到 gcc 编译器，这个编译器提供了 (几乎) 数不清的命令行选项列表。

你知道，你可以让 gcc 保存每个编译阶段的输出吗？你知道用于生成警告的 -Wall 选项，它并不会包含一些特殊的警告吗？gcc 的很多命令行选项都不会经常用到，但是它们在某些特定的情况下会变得非常有用，例如，当你在调试代码的时候。

所以在本文中，我们会介绍这样的几个选项，提供所有必要的细节，并通过简单易懂的例子来解释它们。

但是在开始前，请注意本文中所有的例子所使用的环境：基于 Ubuntu 16.04 LTS 操作系统，gcc 版本为 5.4.0。

在每个编译阶段查看中间代码的输出

你知道在通过 gcc 编译 c 语言代码的时候大体上共分为四个阶段吗？分别为预处理 -> 编译 -> 汇编 -> 链接。在每个阶段之后，gcc 都会产生一个将移交给下一个阶段的临时输出文件。但是生成的都是临时文件，因此我们并不能看到它们——我们所看到的只是我们发起编译命令，然后它生成的我们可以直接运行的二进制文件或可执行文件。

但是比如说在预处理阶段，如果调试时需要查看代码是如何进行处理的，你要怎么做呢？好消息是 gcc 编译器提供了相应的命令行选项，你可以在标准编译命令中使用这些选项获得原本被编译器删除的中间文件。我们所说的选项就是-save-temps。

以下是 gcc 手册中对该选项的介绍：

永久存储临时的中间文件，将它们放在当前的文件夹下并根据源文件名称为其命名。因此，用 -c -save-temps 命令编译 foo.c 文件时会生成 foo.i foo.s 和 foo.o 文件。即使现在编译器大多使用的是集成的预处理器，这命令也会生成预处理输出文件 foo.i。

当与 -x 命令行选项结合使用时，-save-temps 命令会避免覆写与中间文件有着相同扩展名的输入源文件。相应的中间文件可以通过在使用 -save-temps 命令之前重命名源文件获得。

以下是怎样使用这个选项的例子：

gcc -Wall -save-temps test.c -o test-exec

下图为该命令的执行结果，验证其确实产生了中间文件：

因此，在截图中你所看到的 test.i、test.s、 test.o 文件都是由 -save-temps 选项产生的。这些文件分别对应于预处理、编译和链接阶段。

让你的代码可调试和可分析

你可以使用专有的工具调试和分析代码。如 gdb 就是专用于调试的工具，而 gprof 则是热门的分析工具。但你知道 gcc 特定的命令行选项也可以让你的代码可调试和可分析吗？

让我们开始调试之路吧！为了能在代码调试中使用 gdb，你需要在编译代码的时候使用 gcc 编译器提供的 -g 选项。这个选项让 gcc 生成 gdb 需要的调试信息从而能成功地调试程序。

如果你想要使用此选项，建议您详细阅读 gcc 手册提供的有关此选项的详细信息——在某些情况下，其中的一些内容可能是至关重要的。 例如，以下是从手册页中摘录的内容：

GCC 允许在使用 -g 选项的时候配合使用 -O 选项。优化代码采用的便捷方式有时可能会产生意想不到的结果：某些你声明的变量可能不复存在；控制流可能会突然跳转到你未曾预期的位置；一些语句也许不会执行，因为它们已经把常量结果计算了或值已经被保存；一些语句可能会在不同地方执行，因为它们已经被移出循环。

然而优化的输出也是可以调试的。这就使得让优化器可以合理地优化或许有 bug 的代码。

不只是 gdb，使用 -g 选项编译代码，还可以开启使用 Valgrind 内存检测工具，从而完全发挥出该选项的潜力。或许还有一些人不知道，mencheck 工具被程序员们用来检测代码中是否存在内存泄露。你可以在这里参见这个工具的用法。

继续往下，为了能够在代码分析中使用 gprof 工具，你需要使用 -pg 命令行选项来编译代码。这会让 gcc 生成额外的代码来写入分析信息，gprof 工具需要这些信息来进行代码分析。gcc 手册 中提到：当编译你需要数据的源文件时，你必须使用这个选项，当然链接时也需要使用它。为了能了解 gprof 分析代码时具体是如何工作的，你可以转到我们的网站专用教程进行了解。

注意：-g 和 -pg 选项的用法类似于上一节中使用 -save-temps 选项的方式。

结论

我相信除了 gcc 的专业人士，都可以在这篇文章中得到了一些启发。尝试一下这些选项，然后观察它们是如何工作的。同时，请期待本教程系列的下一部分，我们将会讨论更多有趣和有用的 gcc 命令行选项。

via: https://www.howtoforge.com/tutorial/uncommon-but-useful-gcc-command-line-options/

作者：Ansh 译者：dongdongmian 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出