Vimwiki 和 GitLab 是记录笔记的强大组合。

用 vi 来管理 wiki 来记录你的笔记，这听起来不像是一个符合常规的主意，但当你的日常工作都会用到 vi , 那它是有意义的。

作为一个软件开发人员，使用同编码一样的工具来写笔记会更加简单。我想将我的笔记变成一种编辑器命令，无论我在哪里，都能够用管理我代码的方法来管理我的笔记。这便是我创建一个基于 vi 的环境来搭建我自己的知识库的原因。简单概括起来，我在笔记本电脑上用 vi 插件 Viwiki 来本地管理我的 wiki。用 Git 来进行版本控制（以保留一个中心化的更新版本），并用 GitLab 来进行在线修改（例如在我的手机上）。

为什么用 wiki 来进行笔记保存是有意义

我尝试过许多不同的工具来持续的记录我的笔记，笔记里保存着我的灵感以及需要记住的任务安排。这包括线下的笔记本 （没错，纸质的）、特殊的记录笔记的软件，以及思维导图软件。

但每种方案都有不好一面，没有一个能够满足我所有的需求。例如思维导图，能够很好的形象化你的想法（因而得名），但是这种工具的搜索功能很差（和纸质笔记本一样）。此外，当一段时间过去，思维导图会变得很难阅读，所以思维导图不适合长时间保存的笔记。

我为一个合作项目配置了 DokuWiki，我发现这个 wiki 模型符合了我大多数的需求。在 wiki 上，你能够创建一个笔记（和你在文本编辑器中所作的一样），并在笔记间创建链接。如果一个链接指向一个不存在的页面（你想让本页面添加一条还没有创建的信息）， wiki 会为你建立这个页面。这个特性使得 wiki 很好的适应了那些需要快速写下心中所想的人的需求，而仍将你的笔记保持在能够容易浏览和搜索关键字的页面结构中。

这看起来很有希望，并且配置 DokuWiki 也很容易，但我发现只是为了记个笔记而配置整个 wiki 需要花费太多工作。在一番搜索后，我发现了 Vimwiki，这是一个我想要的 vi 插件。因为我每天使用 vi，记录笔记就行编辑代码一样。甚至在 vimwiki 创建一个页面比 Dokuwiki 更简单。你只需要对光标下的单词按下回车键就行。如果没有文件是这个名字，vimwiki 会为你创建一个。

为了更一步的实现用每天都会使用的工具来做笔记的计划，我不仅用这个我最爱的 IDE 来写笔记，而且用 Git 和 GitLab —— 我最爱的代码管理工具 —— 在我的各个机器间分发我的笔记，以便我可以在线访问它们。我也是在 Gitlab 的在线 markdown 工具上用 markdown 语法来写的这篇文章。

配置 vimwiki

用你已有的插件管理工具来安装 vimwiki 很简单，只需要添加 vimwiki/vimwiki 到你的插件。对于我的喜爱的插件管理器 Vundle 来说，你只需要在 /.vimrc 中添加 plugin vimwiki/vimwiki 这一行，然后执行 :source ~/.vimrc | PluginInstall 就行。

下面是我的文件 .vimrc 的一部分，展示了一些 vimwiki 配置。你能在 vimwiki 页面学到更多的配置和使用的的信息。

let wiki_1 = {}
let wiki_1.path = '~/vimwiki_work_md/'
let wiki_1.syntax = 'markdown'
let wiki_1.ext = '.md'

let wiki_2 = {}
let wiki_2.path = '~/vimwiki_personal_md/'
let wiki_2.syntax = 'markdown'
let wiki_2.ext = '.md'

let g:vimwiki_list = [wiki_1, wiki_2]
let g:vimwiki_ext2syntax = {'.md': 'markdown', '.markdown': 'markdown', '.mdown': 'markdown'}

如你在上述配置中所见，我的配置还有一个优点。你能简单的区分个人和工作相关的笔记，而不用切换笔记软件。我想让我的个人笔记可以随时随地访问，而不想我的工作笔记同步到我私人的 GitLab 和计算机中。在 vimwiki 这样配置要比我试过的其他软件都要简单。

这个配置告诉 vimwiki 有两个不同 Wiki，都使用 markdown 语法（再一次，因为我的日常工作中天天都在用 markdown 语法）。我也告诉 Vimwiki 在哪个文件夹存储 wiki 页面。

如果你进入存储 wiki 页面的文件夹，你会找到你的 wiki 的普通的 markdown 页面文件，而没有其他特殊的 Vimwiki 相关内容，这使得很容易的初始化 Git 仓库和同步你的 wiki 到中心仓库。

同步你的 wiki 到 GitLab

这一步检出一个 GitLab 项目到本地的 VimWiki 文件夹，这步操作和你操作任何 GitHub 的仓库相同，只不过因为我更喜欢保存我的笔记到我的私人 GitLab 仓库，所以我运行了一个 GitLab 实例用于我个人的项目。

GitLab 的 wiki 功能可以用来为你的项目创建 wiki 页面。这些 wiki 就是 Git 仓库本身。它们使用 markdown 语法，你懂得。

只需要初始化你需要的 wiki ，让它与你为笔记而创建的项目的 wiki 同步即可。

cd ~/vimwiki_personal_md/
git init
git remote add origin [email protected]:your_user/vimwiki_personal_md.wiki
git add .
git commit -m "Initial commit"
git push -u origin master

在 GitLab 创建一个新的项目后，你就可以从页面上复制这些步骤的代码。唯一的改变是仓库地址结尾是 .wiki（而不是 .git）。 这会告诉 Git 克隆 wiki 仓库而不是项目本身。

就是这样！现在你能够通过 Git 来管理你的笔记，通过 GitLab wiki 用户界面来修改笔记。

你可能（像我一样）不想手动的为每个添加到笔记本的笔记创建一个提交。为了解决这个问题，我使用了 Vim 插件 chazy/dirsetting。我添加一个 .vimaddr 文件，已经下面的内容：

:cd %:p:h
silent! !git pull > /dev/null
:e!
autocmd! BufWritePost * silent! !git add .;git commit -m "vim autocommit" > /dev/null; git push > /dev/null&

每当我打开 Wiki 文件按下 :w 发布我的修改时，它就会更新到最新的版本。这样做会使你的本地文件与中心仓库保持同步。如果你有合并冲突，通常你需要解决它们。

目前，这就是以我的知识来互动的方法，我很喜欢这方法；请告诉我你对于这个方法的想法，可以在评论区分享你如何追踪笔记的方法。

via: https://opensource.com/article/18/6/vimwiki-gitlab-notes

作者：Manuel Dewald 选题：lujun9972 译者：octopus 校对：wxy

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

学习密码学背后的基本概念，主要是保密性、完整性和身份认证。

安全通信正快速成为当今互联网的规范。从 2018 年 7 月起，Google Chrome 将对全部使用 HTTP 传输（而不是 HTTPS 传输）的站点开始显示“不安全”警告。虽然密码学已经逐渐变广为人知，但其本身并没有变得更容易理解。Let's Encrypt 设计并实现了一套令人惊叹的解决方案，可以提供免费安全证书和周期性续签；但如果不了解底层概念和缺陷，你也不过是加入了类似“ 货物崇拜 cargo cult ”的技术崇拜的程序员大军。

安全通信的特性

密码学最直观明显的目标是 保密性 confidentiality ： 消息 message 传输过程中不会被窥探内容。为了保密性，我们对消息进行加密：对于给定消息，我们结合一个 密钥 key 生成一个无意义的乱码，只有通过相同的密钥逆转加密过程（即解密过程）才能将其转换为可读的消息。假设我们有两个朋友 Alice 和 Bob，以及他们的 八卦 nosy 邻居 Eve。Alice 加密类似 "Eve 很讨厌" 的消息，将其发送给 Bob，期间不用担心 Eve 会窥探到这条消息的内容。

对于真正的安全通信，保密性是不够的。假如 Eve 收集了足够多 Alice 和 Bob 之间的消息，发现单词 “Eve” 被加密为 "Xyzzy"。除此之外，Eve 还知道 Alice 和 Bob 正在准备一个派对，Alice 会将访客名单发送给 Bob。如果 Eve 拦截了消息并将 “Xyzzy” 加到访客列表的末尾，那么她已经成功的破坏了这个派对。因此，Alice 和 Bob 需要他们之间的通信可以提供 完整性 integrity ：消息应该不会被篡改。

而且我们还有一个问题有待解决。假如 Eve 观察到 Bob 打开了标记为“来自 Alice”的信封，信封中包含一条来自 Alice 的消息“再买一加仑冰淇淋”。Eve 看到 Bob 外出，回家时带着冰淇淋，这样虽然 Eve 并不知道消息的完整内容，但她对消息有了大致的了解。Bob 将上述消息丢弃，但 Eve 找出了它并在下一周中的每一天都向 Bob 的邮箱中投递一封标记为“来自 Alice”的信封，内容拷贝自之前 Bob 丢弃的那封信。这样到了派对的时候，冰淇淋严重超量；派对当晚结束后，Bob 分发剩余的冰淇淋，Eve 带着免费的冰淇淋回到家。消息是加密的，完整性也没问题，但 Bob 被误导了，没有认出发信人的真实身份。 身份认证 Authentication 这个特性用于保证你正在通信的人的确是其声称的那样。

信息安全还有其它特性，但保密性、完整性和身份验证是你必须了解的三大特性。

加密和加密算法

加密都包含哪些部分呢？首先，需要一条消息，我们称之为 明文 plaintext 。接着，需要对明文做一些格式上的初始化，以便用于后续的加密过程（例如，假如我们使用 分组加密算法 block cipher ，需要在明文尾部填充使其达到特定长度）。下一步，需要一个保密的比特序列，我们称之为 密钥 key 。然后，基于私钥，使用一种加密算法将明文转换为 密文 ciphertext 。密文看上去像是随机噪声，只有通过相同的加密算法和相同的密钥（在后面提到的非对称加密算法情况下，是另一个数学上相关的密钥）才能恢复为明文。

（LCTT 译注：cipher 一般被翻译为密码，但其具体表达的意思是加密算法，这里采用加密算法的翻译）

加密算法使用密钥加密明文。考虑到希望能够解密密文，我们用到的加密算法也必须是 可逆的 reversible 。作为简单示例，我们可以使用 XOR。该算子可逆，而且逆算子就是本身（P ^ K = C; C ^ K = P），故可同时用于加密和解密。该算子的平凡应用可以是 一次性密码本 one-time pad ，不过一般而言并不可行。但可以将 XOR 与一个基于单个密钥生成 任意随机数据流 arbitrary stream of random data 的函数结合起来。现代加密算法 AES 和 Chacha20 就是这么设计的。

我们把加密和解密使用同一个密钥的加密算法称为 对称加密算法 symmetric cipher 。对称加密算法分为 流加密算法 stream ciphers 和分组加密算法两类。流加密算法依次对明文中的每个比特或字节进行加密。例如，我们上面提到的 XOR 加密算法就是一个流加密算法。流加密算法适用于明文长度未知的情形，例如数据从管道或 socket 传入。RC4 是最为人知的流加密算法，但在多种不同的攻击面前比较脆弱，以至于最新版本 （1.3）的 TLS （“HTTPS” 中的 “S”）已经不再支持该加密算法。Efforts 正着手创建新的加密算法，候选算法 ChaCha20 已经被 TLS 支持。

分组加密算法对固定长度的分组，使用固定长度的密钥加密。在分组加密算法领域，排行第一的是 先进加密标准 Advanced Encryption Standard （AES），使用的分组长度为 128 比特。分组包含的数据并不多，因而分组加密算法包含一个工作模式，用于描述如何对任意长度的明文执行分组加密。最简单的工作模式是 电子密码本 Electronic Code Book （ECB），将明文按分组大小划分成多个分组（在必要情况下，填充最后一个分组），使用密钥独立的加密各个分组。

这里我们留意到一个问题：如果相同的分组在明文中出现多次（例如互联网流量中的 GET / HTTP/1.1 词组），由于我们使用相同的密钥加密分组，我们会得到相同的加密结果。我们的安全通信中会出现一种 模式规律 pattern ，容易受到攻击。

因此还有很多高级的工作模式，例如 密码分组链接 Cipher Block Chaining （CBC），其中每个分组的明文在加密前会与前一个分组的密文进行 XOR 操作，而第一个分组的明文与一个随机数构成的初始化向量进行 XOR 操作。还有其它一些工作模式，在安全性和执行速度方面各有优缺点。甚至还有 Counter (CTR) 这种工作模式，可以将分组加密算法转换为流加密算法。

除了对称加密算法，还有 非对称加密算法 asymmetric ciphers ，也被称为 公钥密码学 public-key cryptography 。这类加密算法使用两个密钥：一个 公钥 public key ，一个 私钥 private key 。公钥和私钥在数学上有一定关联，但可以区分二者。经过公钥加密的密文只能通过私钥解密，经过私钥加密的密文可以通过公钥解密。公钥可以大范围分发出去，但私钥必须对外不可见。如果你希望和一个给定的人通信，你可以使用对方的公钥加密消息，这样只有他们的私钥可以解密出消息。在非对称加密算法领域，目前 RSA) 最具有影响力。

非对称加密算法最主要的缺陷是，它们是 计算密集型 computationally expensive 的。那么使用对称加密算法可以让身份验证更快吗？如果你只与一个人共享密钥，答案是肯定的。但这种方式很快就会失效。假如一群人希望使用对称加密算法进行两两通信，如果对每对成员通信都采用单独的密钥，一个 20 人的群体将有 190 对成员通信，即每个成员要维护 19 个密钥并确认其安全性。如果使用非对称加密算法，每个成员仅需确保自己的私钥安全并维护一个公钥列表即可。

非对称加密算法也有加密数据长度限制。类似于分组加密算法，你需要将长消息进行划分。但实际应用中，非对称加密算法通常用于建立 机密 confidential 、 已认证 authenticated 的 通道 channel ，利用该通道交换对称加密算法的共享密钥。考虑到速度优势，对称加密算法用于后续的通信。TLS 就是严格按照这种方式运行的。

基础

安全通信的核心在于随机数。随机数用于生成密钥并为 确定性过程 deterministic processes 提供不可预测性。如果我们使用的密钥是可预测的，那我们从一开始就可能受到攻击。计算机被设计成按固定规则操作，因此生成随机数是比较困难的。计算机可以收集鼠标移动或 键盘计时 keyboard timings 这类随机数据。但收集随机性（也叫 信息熵 entropy ）需要花费不少时间，而且涉及额外处理以确保 均匀分布 uniform distribution 。甚至可以使用专用硬件，例如 熔岩灯 lava lamps 墙等。一般而言，一旦有了一个真正的随机数值，我们可以将其用作 种子 seed ，使用 密码安全的伪随机数生成器 cryptographically secure pseudorandom number generator 生成随机数。使用相同的种子，同一个随机数生成器生成的随机数序列保持不变，但重要的是随机数序列是无规律的。在 Linux 内核中，/dev/random 和 /dev/urandom 工作方式如下：从多个来源收集信息熵，进行 无偏处理 remove biases ，生成种子，然后生成随机数，该随机数可用于 RSA 密钥生成等。

其它密码学组件

我们已经实现了保密性，但还没有考虑完整性和身份验证。对于后两者，我们需要使用一些额外的技术。

首先是 密码散列函数 crytographic hash function ，该函数接受任意长度的输入并给出固定长度的输出（一般称为 摘要 digest ）。如果我们找到两条消息，其摘要相同，我们称之为 碰撞 collision ，对应的散列函数就不适合用于密码学。这里需要强调一下“找到”：考虑到消息的条数是无限的而摘要的长度是固定的，那么总是会存在碰撞；但如果无需海量的计算资源，我们总是能找到发生碰撞的消息对，那就令人比较担心了。更严重的情况是，对于每一个给定的消息，都能找到与之碰撞的另一条消息。

另外，哈希函数必须是 单向的 one-way ：给定一个摘要，反向计算对应的消息在计算上不可行。相应的，这类条件被称为 碰撞阻力 collision resistance 、 第二原象抗性 second preimage resistance 和 原象抗性 preimage resistance 。如果满足这些条件，摘要可以用作消息的指纹。理论上不存在具有相同指纹的两个人，而且你无法使用指纹反向找到其对应的人。

如果我们同时发送消息及其摘要，接收者可以使用相同的哈希函数独立计算摘要。如果两个摘要相同，可以认为消息没有被篡改。考虑到 SHA-1 已经变得有些过时，目前最流行的密码散列函数是 SHA-256。

散列函数看起来不错，但如果有人可以同时篡改消息及其摘要，那么消息发送仍然是不安全的。我们需要将哈希与加密算法结合起来。在对称加密算法领域，我们有 消息认证码 message authentication codes （MAC）技术。MAC 有多种形式，但 哈希消息认证码 hash message authentication codes （HMAC） 这类是基于哈希的。HMAC 使用哈希函数 H 处理密钥 K、消息 M，公式为 H(K + H(K + M))，其中 + 代表 连接 concatenation 。公式的独特之处并不在本文讨论范围内，大致来说与保护 HMAC 自身的完整性有关。发送加密消息的同时也发送 MAC。Eve 可以任意篡改消息，但一旦 Bob 独立计算 MAC 并与接收到的 MAC 做比较，就会发现消息已经被篡改。

在非对称加密算法领域，我们有 数字签名 digital signatures 技术。如果使用 RSA，使用公钥加密的内容只能通过私钥解密，反过来也是如此；这种机制可用于创建一种签名。如果只有我持有私钥并用其加密文档，那么只有我的公钥可以用于解密，那么大家潜在的承认文档是我写的：这是一种身份验证。事实上，我们无需加密整个文档。如果生成文档的摘要，只要对这个指纹加密即可。对摘要签名比对整个文档签名要快得多，而且可以解决非对称加密存在的消息长度限制问题。接收者解密出摘要信息，独立计算消息的摘要并进行比对，可以确保消息的完整性。对于不同的非对称加密算法，数字签名的方法也各不相同；但核心都是使用公钥来检验已有签名。

汇总

现在，我们已经有了全部的主体组件，可以用其实现一个我们期待的、具有全部三个特性的 体系 system 。Alice 选取一个保密的对称加密密钥并使用 Bob 的公钥进行加密。接着，她对得到的密文进行哈希并使用其私钥对摘要进行签名。Bob 接收到密文和签名，一方面独立计算密文的摘要，另一方面使用 Alice 的公钥解密签名中的摘要；如果两个摘要相同，他可以确信对称加密密钥没有被篡改且通过了身份验证。Bob 使用私钥解密密文得到对称加密密钥，接着使用该密钥及 HMAC 与 Alice 进行保密通信，这样每一条消息的完整性都得到保障。但该体系没有办法抵御消息重放攻击（我们在 Eve 造成的冰淇淋灾难中见过这种攻击）。要解决重放攻击，我们需要使用某种类型的“ 握手 handshake ”建立随机、短期的 会话标识符 session identifier 。

密码学的世界博大精深，我希望这篇文章能让你对密码学的核心目标及其组件有一个大致的了解。这些概念为你打下坚实的基础，让你可以继续深入学习。

感谢 Hubert Kario、Florian Weimer 和 Mike Bursell 在本文写作过程中提供的帮助。

via: https://opensource.com/article/18/5/cryptography-pki

作者：Alex Wood 选题：lujun9972 译者：pinewall 校对：wxy

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

了解如何在 Linux 中暂时禁用 iptables 防火墙来进行故障排除。还要学习如何保存策略以及如何在启用防火墙时恢复它们。

有时你需要关闭 iptables 防火墙来做一些连接故障排除，然后你需要重新打开它。在执行此操作时，你还需要保存所有防火墙策略。在本文中，我们将引导你了解如何保存防火墙策略以及如何禁用/启用 iptables 防火墙。有关 iptables 防火墙和策略的更多详细信息请阅读我们的文章。

保存 iptables 策略

临时禁用 iptables 防火墙的第一步是保存现有的防火墙规则/策略。iptables-save 命令列出你可以保存到服务器中的所有现有策略。

root@kerneltalks # # iptables-save
# Generated by iptables-save v1.4.21 on Tue Jun 19 09:54:36 2018
*nat
:PREROUTING ACCEPT [1:52]
:INPUT ACCEPT [1:52]
:OUTPUT ACCEPT [15:1140]
:POSTROUTING ACCEPT [15:1140]
:DOCKER - [0:0]
---- output trucated----

root@kerneltalks # iptables-save > /root/firewall_rules.backup

因此，iptables-save 是可以用来备份 iptables 策略的命令。

停止/禁用 iptables 防火墙

对于较老的 Linux 内核，你可以选择使用 service iptables stop 停止 iptables 服务，但是如果你在用新内核，则只需清除所有策略并允许所有流量通过防火墙。这和你停止防火墙效果一样。

使用下面的命令列表来做到这一点。

root@kerneltalks # iptables -F
root@kerneltalks # iptables -X
root@kerneltalks # iptables -P INPUT ACCEPT
root@kerneltalks # iptables -P OUTPUT ACCEPT
root@kerneltalks # iptables -P FORWARD ACCEPT

这里 –

• -F：删除所有策略链
• -X：删除用户定义的链
• -P INPUT/OUTPUT/FORWARD ：接受指定的流量

完成后，检查当前的防火墙策略。它应该看起来像下面这样接受所有流量（和禁用/停止防火墙一样）

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

恢复防火墙策略

故障排除后，你想要重新打开 iptables 的所有配置。你需要先从我们在第一步中执行的备份中恢复策略。

root@kerneltalks # iptables-restore </root/firewall_rules.backup

启动 iptables 防火墙

然后启动 iptables 服务，以防止你在上一步中使用 service iptables start 停止了它。如果你已经停止服务，那么只有恢复策略才能有用。检查所有策略是否恢复到 iptables 配置中：

#  iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
-----output truncated-----

就是这些了！你已成功禁用并启用了防火墙，而不会丢失你的策略规则。

via: https://kerneltalks.com/howto/how-to-disable-iptables-firewall-temporarily/

作者：kerneltalks 选题：lujun9972 译者：geekpi 校对：wxy

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

一些实际的加速 Ubuntu Linux 的技巧。 这里的技巧对于大多数版本的 Ubuntu 是有效的，也可以应用于 Linux Mint 以及其他的基于 Ubuntu 的发行版。

也许你经历过使用 Ubuntu 一段时间后系统开始运行缓慢的情况。 在这篇文章里，我们将看到几项调整以及使 Ubuntu 运行更快的窍门。

在我们了解如何提升 Ubuntu 的总体系统表现之前，首先让我们思考为什么系统逐渐变慢。这个问题可能有很多原因。也许你有一台只有基础配置的简陋的电脑；也许你安装了一些在启动时即耗尽资源的应用。事实上原因无穷无尽。

这里我列出一些能够帮助你稍微加速 Ubuntu 的小调整。也有一些你能够采用以获取一个更流畅、有所提升的系统表现的经验。你可以选择遵循全部或部分的建议。将各项调整一点一点的结合就能给你一个更流畅、更迅捷快速的 Ubuntu。

使 Ubuntu 更快的技巧

我在一个较老版本的 Ubuntu 上使用了这些调整，但是我相信其他的 Ubuntu 版本以及其他的例如 Linux Mint、 Elementary OS Luna 等基 Ubuntu 的 Linux 版本也是同样适用的。

1、 减少默认的 grub 载入时间

Grub 给你 10 秒的时间以让你在多系统启动项或恢复模式之间改变。对我而言，它是多余的。它也意味着你将不得不坐在电脑旁，敲下回车键以尽可能快的启动进入 Ubuntu。这花了一点时间，不是吗？ 第一个技巧便是改变这个启动时间。如果你使用图形工具更舒适，阅读这篇文章来使用 Grub 定制器改变 grub 时间以及启动顺序。

如果更倾向于命令行，你可以简单地使用以下的命令来打开 grub 配置：

sudo gedit /etc/default/grub &

并且将 GRUB_TIMEOUT=10 改为 GRUB_TIMEOUT=2。这将改变启动时间为 2 秒。最好不要将这里改为 0，因为这样你将会失去在操作系统及恢复选项之间切换的机会。一旦你更改了 grub 配置，使用以下命令来使更改生效：

sudo update-grub

2、 管理开机启动的应用

渐渐地你开始安装各种应用。 如果你是我们的老读者, 你也许从 App of the week 系列安装了许多应用。

这些应用中的一些在每次开机时都会启动，当然资源运行这些应用也会陷入繁忙。结果：一台电脑因为每次启动时的持续时间而变得缓慢。进入 Unity Dash 寻找 “Startup Applications”：

在这里，看看哪些应用在开机时被载入。现在考虑在你每次启动 Ubuntu 时是否有不需要启动的应用。尽管移除它们：

但是要是你不想从启动里移除它们怎么办？举个例子，如果你安装了 Ubuntu 最好的指示器程序之一， 你将想要它们在每次开机时自动地启动。

这里你所能做的就是延迟一些程序的启动时间。这样你将能够释放开机启动时的资源，并且一段时间后你的应用将被自动启动。在上一张图片里点击 Edit 并使用 sleep 选项来更改运行命令。

例如，如果你想要延迟 Dropbox 指示器的运行，我们指定时间 20 秒，你只需要在已有的命令里像这样加入一个命令：

sleep 20;

所以，命令 dropbox start -i 变为 sleep 20; drobox start -i 。这意味着现在 Dropbox 将延迟 20 秒启动。你可以通过相似的方法来改变另一个开机启动应用的启动时间。

3、 安装 preload 来加速应用载入时间：

Preload 是一个后台运行的守护进程，它分析用户行为和频繁运行的应用。打开终端，使用如下的命令来安装 preload：

sudo apt-get install preload

安装后，重启你的电脑就不用管它了。它将在后台工作。阅读更多关于preload

4、 选择最好的软件更新镜像

验证你更新软件是否正在使用最好的镜像是很好的做法。Ubuntu 的软件仓库镜像跨过全球，使用离你最近的一个是相当明智的。随着从服务器获取包的时间减少，这将形成更快的系统更新。

在 “Software & Updates->Ubuntu Software tab->Download From” 里选择 “Other” 紧接着点击 “Select Best Server”：

它将运行测试来告知你那个是最好的镜像。正常地，最好的镜像已经被设置，但是我说过，验证它没什么坏处。并且，如果仓库缓存的最近的镜像没有频繁更新的话，这将引起获取更新时的一些延迟。这对于网速相对慢的人们是有用的。你可以使用这些技巧来加速 Ubuntu 的 wifi。

5、 为了更快的更新，使用 apt-fast 而不是 apt-get

apt-fast 是 apt-get 的一个 shell 脚本包装器，通过从多连接同时下载包来提升更新及包下载速度。 如果你经常使用终端以及 apt-get 来安装和更新包，你也许会想要试一试 apt-fast。使用下面的命令来通过官方 PPA 安装 apt-fast：

sudo add-apt-repository ppa:apt-fast/stable
sudo apt-get update
sudo apt-get install apt-fast

6、 从 apt-get 更新移除语言相关的 ign

你曾经注意过 sudo apt-get 更新的输出吗？其中有三种行，hit、ign 和 get。 你可以在这里阅读它们的意义。如果你看到 IGN 行，你会发现它们中的大多数都与语言翻译有关。如果你使用所有的英文应用及包，你将完全不需要英文向英文的包数据库的翻译。

如果你从 apt-get 制止语言相关的更新，它将略微地增加 apt-get 的更新速度。为了那样，打开如下的文件：

sudo gedit /etc/apt/apt.conf.d/00aptitude

然后在文件末尾添加如下行：

Acquire::Languages "none";

7、 减少过热

现在过热是电脑普遍的问题。一台过热的电脑运行相当缓慢。当你的 CPU 风扇转得像 尤塞恩·博尔特 一样快，打开一个程序将花费很长的时间。有两个工具你可以用来减少过热，使 Ubuntu 获得更好的系统表现，即 TLP 和 CPUFREQ。

在终端里使用以下命令来安装 TLP：

sudo add-apt-repository ppa:linrunner/tlp
sudo apt-get update
sudo apt-get install tlp tlp-rdw
sudo tlp start

安装完 TLP 后你不需要做任何事。它在后台工作。

使用如下命令来安装 CPUFREQ 指示器：

sudo apt-get install indicator-cpufreq

重启你的电脑并使用 Powersave 模式：

8、 调整 LibreOffice 来使它更快

如果你是频繁使用 office 产品的用户，那么你会想要稍微调整默认的 LibreOffice 使它更快。这里你将调整内存选项。打开 Open LibreOffice，进入 “Tools->Options”。在那里，从左边的侧栏选择“Memory”并启用 “Systray Quickstarter” 以及增加内存分配。

你可以阅读更多关于如何提速 LibreOffice 的细节。

9、 使用轻量级的桌面环境 (如果你可以)

如果你选择安装默认的 Unity of GNOME 桌面环境, 你也许会选择一个轻量级的桌面环境像 Xfce 或 LXDE。

这些桌面环境使用更少的内存，消耗更少的 CPU。它们也自带轻量应用集来更深入地帮助更快地使用 Ubuntu。你可以参考这篇详细指南来学习如何在 Ubuntu 上安装 Xfce。

当然，桌面也许没有 Unity 或 GNOME 看起来现代化。那是你必须做出的妥协。

10、 使用不同应用的更轻量可选

这不仅仅是建议和喜好。一些默认的或者流行的应用是耗资源的且可能不适合低端的电脑。你能做的就是使用这些应用的一些替代品。例如，使用 AppGrid 而不是 Ubuntu 软件中心。使用 Gdebi 来安装包。使用 AbiWord 而不是 LibreOffice Writer 等。

可以断定这些技巧的汇总使 Ubuntu 14.04，16.04 以及其他版本更快。我确定这些技巧会提供一个总体上更好的系统表现。

对于加速 Ubuntu 你也有妙计吗？这些技巧也帮到你了吗？分享你的观点。 问题，建议总是受欢迎的。请在评论区里提出来。

via: https://itsfoss.com/speed-up-ubuntu-1310/

作者：Abhishek Prakash 选题：lujun9972 译者：darsh8 校对：wxy

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

编程语言对软件质量的影响是什么？这个问题在很长一段时间内成为一个引起了大量辩论的主题。在这项研究中，我们从 GitHub 上收集了大量的数据（728 个项目，6300 万行源代码，29000 位作者，150 万个提交，17 种编程语言），尝试在这个问题上提供一些实证。这个还算比较大的样本数量允许我们去使用一个混合的方法，结合多种可视化的回归模型和文本分析，去研究语言特性的影响，比如，在软件质量上，静态与动态类型和允许混淆与不允许混淆的类型。通过从不同的方法作三角测量研究（LCTT 译注：一种测量研究的方法），并且去控制引起混淆的因素，比如，团队大小、项目大小和项目历史，我们的报告显示，语言设计确实（对很多方面）有很大的影响，但是，在软件质量方面，语言的影响是非常有限的。最明显的似乎是，不允许混淆的类型比允许混淆的类型要稍微好一些，并且，在函数式语言中，静态类型也比动态类型好一些。值得注意的是，这些由语言设计所引起的轻微影响，绝大多数是由过程因素所主导的，比如，项目大小、团队大小和提交数量。但是，我们需要提示读者，即便是这些不起眼的轻微影响，也是由其它的无形的过程因素所造成的，例如，对某些函数类型、以及不允许类型混淆的静态语言的偏爱。

1 序言

在给定的编程语言是否是“适合这个工作的正确工具”的讨论期间，紧接着又发生了多种辩论。虽然一些辩论出现了带有宗教般狂热的色彩，但是大部分人都一致认为，编程语言的选择能够对编码过程和由此生成的结果都有影响。

主张强静态类型的人，倾向于认为静态方法能够在早期捕获到缺陷；他们认为，一点点的预防胜过大量的矫正。动态类型拥护者主张，保守的静态类型检查无论怎样都是非常浪费开发者资源的，并且，最好是依赖强动态类型检查来捕获错误类型。然而，这些辩论，大多数都是“纸上谈兵”，只靠“传说中”的证据去支持。

这些“传说”也许并不是没有道理的；考虑到影响软件工程结果的大量其它因素，获取这种经验性的证据支持是一项极具挑战性的任务，比如，代码质量、语言特征，以及应用领域。比如软件质量，考虑到它有大量的众所周知的影响因素，比如，代码数量， ⁶ 团队大小， ² 和年龄/熟练程度。 ⁹

受控实验是检验语言选择在面对如此令人气馁的混淆影响时的一种方法，然而，由于成本的原因，这种研究通常会引入一种它们自己的混淆，也就是说，限制了范围。在这种研究中，完整的任务是必须要受限制的，并且不能去模拟 真实的世界 中的开发。这里有几个最近的这种大学本科生使用的研究，或者，通过一个实验因素去比较静态或动态类型的语言。 ^{7 ， 12 ， 15}

幸运的是，现在我们可以基于大量的真实世界中的软件项目去研究这些问题。GitHub 包含了多种语言的大量的项目，并且在大小、年龄、和开发者数量上有很大的差别。每个项目的仓库都提供一个详细的记录，包含贡献历史、项目大小、作者身份以及缺陷修复。然后，我们使用多种工具去研究语言特性对缺陷发生的影响。对我们的研究方法的最佳描述应该是“混合方法”，或者是三角测量法； ⁵ 我们使用文本分析、聚簇和可视化去证实和支持量化回归研究的结果。这个以经验为根据的方法，帮助我们去了解编程语言对软件质量的具体影响，因为，他们是被开发者非正式使用的。

2 方法

我们的方法是软件工程中典型的大范围观察研究法。我们首先大量的使用自动化方法，从几种数据源采集数据。然后使用预构建的统计分析模型对数据进行过滤和清洗。过滤器的选择是由一系列的因素共同驱动的，这些因素包括我们研究的问题的本质、数据质量和认为最适合这项统计分析研究的数据。尤其是，GitHub 包含了由大量的编程语言所写的非常多的项目。对于这项研究，我们花费大量的精力专注于收集那些用大多数的主流编程语言写的流行项目的数据。我们选择合适的方法来评估计数数据上的影响因素。

2.1 数据收集

我们选择了 GitHub 上的排名前 19 的编程语言。剔除了 CSS、Shell 脚本、和 Vim 脚本，因为它们不是通用的编程语言。我们包含了 Typescript，它是 JavaScript 的超集。然后，对每个被研究的编程语言，我们检索出以它为主要编程语言的前 50 个项目。我们总共分析了 17 种不同的语言，共计 850 个项目。

我们的编程语言和项目的数据是从 GitHub Archive 中提取的，这是一个记录所有活跃的公共 GitHub 项目的数据库。它记录了 18 种不同的 GitHub 事件，包括新提交、fork 事件、PR（拉取请求）、开发者信息和以每小时为基础的所有开源 GitHub 项目的问题跟踪。打包后的数据上传到 Google BigQuery 提供的交互式数据分析接口上。

识别编程语言排名榜单

我们基于它们的主要编程语言分类合计项目。然后，我们选择大多数的项目进行进一步分析，如 表 1 所示。一个项目可能使用多种编程语言；将它确定成单一的编程语言是很困难的。Github Archive 保存的信息是从 GitHub Linguist 上采集的，它使用项目仓库中源文件的扩展名来确定项目的发布语言是什么。源文件中使用数量最多的编程语言被确定为这个项目的 主要编程语言。

表 1 每个编程语言排名前三的项目

检索流行的项目

对于每个选定的编程语言，我们先根据项目所使用的主要编程语言来选出项目，然后根据每个项目的相关 星 的数量排出项目的流行度。 星 的数量表示了有多少人主动表达对这个项目感兴趣，并且它是流行度的一个合适的代表指标。因此，在 C 语言中排名前三的项目是 linux、git、php-src；而对于 C++，它们则是 node-webkit、phantomjs、mongo ；对于 Java，它们则是 storm、elasticsearch、ActionBarSherlock 。每个编程语言，我们各选了 50 个项目。

为确保每个项目有足够长的开发历史，我们剔除了少于 28 个提交的项目（28 是候选项目的第一个四分位值数）。这样我们还剩下 728 个项目。表 1 展示了每个编程语言的前三个项目。

检索项目演进历史

对于 728 个项目中的每一个项目，我们下载了它们的非合并提交、提交记录、作者数据、作者使用 git 的名字。我们从每个文件的添加和删除的行数中计算代码改动和每个提交的修改文件数量。我们以每个提交中修改的文件的扩展名所代表的编程语言，来检索出所使用的编程语言（一个提交可能有多个编程语言标签）。对于每个提交，我们通过它的提交日期减去这个项目的第一个提交的日期，来计算它的 提交年龄 。我们也计算其它的项目相关的统计数据，包括项目的最大提交年龄和开发者总数，用于我们的回归分析模型的控制变量，它在第三节中会讨论到。我们通过在提交记录中搜索与错误相关的关键字，比如，error、bug、fix、issue、mistake、incorrect、fault、defect、flaw，来识别 bug 修复提交。这一点与以前的研究类似。 ¹⁸

表 2 汇总了我们的数据集。因为一个项目可能使用多个编程语言，表的第二列展示了使用某种编程语言的项目的总数量。我们进一步排除了项目中该编程语言少于 20 个提交的那些编程语言。因为 20 是每个编程语言的每个项目的提交总数的第一个四分位值。例如，我们在 C 语言中共找到 220 项目的提交数量多于 20 个。这确保了每个“编程语言 – 项目”对有足够的活跃度。

表 2 研究主题

总而言之，我们研究了最近 18 年以来，用了 17 种编程语言开发的，总共 728 个项目。总共包括了 29,000 个不同的开发者，157 万个提交，和 564,625 个 bug 修复提交。

2.2 语言分类

我们基于影响语言质量的几种编程语言特性定义了语言类别， ^{7 ， 8 ， 12} ，如 表 3 所示。

编程范式 Programming Paradigm 表示项目是以命令方式、脚本方式、还是函数语言所写的。在本文的下面部分，我们分别使用 命令 procedural 和 脚本 scripting 这两个术语去代表命令方式和脚本方式。

表 3. 语言分类的不同类型

类型检查 Type Checking 代表静态或者动态类型。在静态类型语言中，在编译时进行类型检查，并且变量名是绑定到一个值和一个类型的。另外，（包含变量的）表达式是根据运行时，它们可能产生的值所符合的类型来分类的。在动态类型语言中，类型检查发生在运行时。因此，在动态类型语言中，它可能出现在同一个程序中，一个变量名可能会绑定到不同类型的对象上的情形。

隐式类型转换 Implicit Type Conversion 允许一个类型为 T1 的操作数，作为另一个不同的类型 T2 来访问，而无需进行显式的类型转换。这样的隐式类型转换在一些情况下可能会带来类型混淆，尤其是当它表示一个明确的 T1 类型的操作数时，把它再作为另一个不同的 T2 类型的情况下。因为，并不是所有的隐式类型转换都会立即出现问题，通过我们识别出的允许进行隐式类型转换的所有编程语言中，可能发生隐式类型转换混淆的例子来展示我们的定义。例如，在像 Perl、 JavaScript、CoffeeScript 这样的编程语言中，一个字符和一个数字相加是允许的（比如，"5" + 2 结果是 "52"）。但是在 Php 中，相同的操作，结果是 7。像这种操作在一些编程语言中是不允许的，比如 Java 和 Python，因为，它们不允许隐式转换。在强数据类型的 C 和 C++ 中，这种操作的结果是不可预料的，例如，int x; float y; y=3.5; x=y；是合法的 C 代码，并且对于 x 和 y 其结果是不同的值，具体是哪一个值，取决于含义，这可能在后面会产生问题。 ^a 在 Objective-C 中，数据类型 id 是一个通用对象指针，它可以被用于任何数据类型的对象，而不管分类是什么。 ^{b 像这种通用数据类型提供了很好的灵活性，它可能导致隐式的类型转换，并且也会出现不可预料的结果。 c} 因此，我们根据它的编译器是否 允许 或者 不允许 如上所述的隐式类型转换，对编程语言进行分类；而不允许隐式类型转换的编程语言，会显式检测类型混淆，并报告类型不匹配的错误。

不允许隐式类型转换的编程语言，使用一个类型判断算法，比如，Hindley ¹⁰ 和 Milner， ¹⁷ 或者，在运行时上使用一个动态类型检查器，可以在一个编译器（比如，使用 Java）中判断静态类型的结果。相比之下，一个类型混淆可能会悄无声息地发生，因为，它可能因为没有检测到，也可能是没有报告出来。无论是哪种方式，允许隐式类型转换在提供了灵活性的同时，最终也可能会出现很难确定原因的错误。为了简单起见，我们将用 隐含 implicit 代表允许隐式类型转换的编程语言，而不允许隐式类型转换的语言，我们用 明确 explicit 代表。

内存分类 Memory Class 表示是否要求开发者去管理内存。尽管 Objective-C 遵循了一个混合模式，我们仍将它放在非管理的分类中来对待，因为，我们在它的代码库中观察到很多的内存错误，在第 3 节的 RQ4 中会讨论到。

请注意，我们之所以使用这种方式对编程语言来分类和研究，是因为，这种方式在一个“真实的世界”中被大量的开发人员非正式使用。例如，TypeScript 被有意地分到静态编程语言的分类中，它不允许隐式类型转换。然而，在实践中，我们注意到，开发者经常（有 50% 的变量，并且跨 TypeScript —— 在我们的数据集中使用的项目）使用 any 类型，这是一个笼统的联合类型，并且，因此在实践中，TypeScript 允许动态地、隐式类型转换。为减少混淆，我们从我们的编程语言分类和相关的模型中排除了 TypeScript（查看 表 3 和 7）。

2.3 识别项目领域

我们基于编程语言的特性和功能，使用一个自动加手动的混合技术，将研究的项目分类到不同的领域。在 GitHub 上，项目使用 project descriptions 和 README 文件来描述它们的特性。我们使用一种文档主题生成模型（Latent Dirichlet Allocation，缩写为：LDA） ³ 去分析这些文本。提供一组文档给它，LDA 将生成不同的关键字，然后来识别可能的主题。对于每个文档，LDA 也估算每个主题分配的文档的概率。

我们检测到 30 个不同的领域（换句话说，就是主题），并且评估了每个项目从属于每个领域的概率。因为，这些自动检测的领域包含了几个具体项目的关键字，例如，facebook，很难去界定它的底层的常用功能。为了给每个领域分配一个有意义的名字，我们手动检查了 30 个与项目名字无关的用于识别领域的领域识别关键字。我们手动重命名了所有的 30 个自动检测的领域，并且找出了以下六个领域的大多数的项目：应用程序、数据库、代码分析、中间件、库，和框架。我们也找出了不符合以上任何一个领域的一些项目，因此，我们把这个领域笼统地标记为 其它 。随后，我们研究组的另一名成员检查和确认了这种项目领域分类的方式。表 4 汇总了这个过程识别到的领域结果。

表 4 领域特征

2.4 bug 分类

尽管修复软件 bug 时，开发者经常会在提交日志中留下关于这个 bug 的原始的重要信息；例如，为什么会产生 bug，以及怎么去修复 bug。我们利用很多信息去分类 bug，与 Tan 的 et al 类似。 ^{13 ， 24}

首先，我们基于 bug 的 原因 Cause 和 影响 Impact 进行分类。\_ 原因 \_ 进一步分解为不相关的错误子类：算法方面的、并发方面的、内存方面的、普通编程错误，和未知的。bug 的 影响 也分成四个不相关的子类：安全、性能、失败、和其它的未知类。因此，每个 bug 修复提交也包含原因和影响的类型。表 5 展示了描述的每个 bug 分类。这个类别分别在两个阶段中被执行：

表 5 bug 分类和在整个数据集中的描述

(1) 关键字搜索 我们随机选择了 10% 的 bug 修复信息，并且使用一个基于关键字的搜索技术去对它们进行自动化分类，作为可能的 bug 类型。我们对这两种类型（原因和影响）分别使用这个注释。我们选择了一个限定的关键字和习惯用语集，如 表 5 所展示的。像这种限定的关键字和习惯用语集可以帮我们降低误报。

(2) 监督分类 我们使用前面步骤中的有注释的 bug 修复日志作为训练数据，为监督学习分类技术，通过测试数据来矫正，去对剩余的 bug 修复信息进行分类。我们首先转换每个 bug 修复信息为一个词袋（LCTT 译注：bag-of-words，一种信息检索模型）。然后，删除在所有的 bug 修复信息中仅出现过一次的词。这样减少了具体项目的关键字。我们也使用标准的自然语言处理技术来解决这个问题。最终，我们使用支持向量机（LCTT 译注：Support Vector Machine，缩写为 SVM，在机器学习领域中，一种有监督的学习算法）去对测试数据进行分类。

为精确评估 bug 分类器，我们手动注释了 180 个随机选择的 bug 修复，平均分布在所有的分类中。然后，我们比较手动注释的数据集在自动分类器中的结果。最终处理后的，表现出的精确度是可接受的，性能方面的精确度最低，是 70%，并发错误方面的精确度最高，是 100%，平均是 84%。再次运行，精确度从低到高是 69% 到 91%，平均精确度还是 84%。

我们的 bug 分类的结果展示在 表 5 中。大多数缺陷的原因都与普通编程错误相关。这个结果并不意外，因为，在这个分类中涉及了大量的编程错误，比如，类型错误、输入错误、编写错误、等等。我们的技术并不能将在任何（原因或影响）分类中占比为 1.4% 的 bug 修复信息再次进行分类；我们将它归类为未知。

2.5 统计方法

我们使用回归模型对软件项目相关的其它因素中的有缺陷的提交数量进行了建模。所有的模型使用 负二项回归 negative binomial regression （缩写为 NBR）（LCTT 译注：一种回归分析模型） 去对项目属性计数进行建模，比如，提交数量。NBR 是一个广义的线性模型，用于对非负整数进行响应建模。 ⁴

在我们的模型中，我们对每个项目的编程语言，控制几个可能影响最终结果的因素。因此，在我们的回归分析中，每个（语言/项目）对是一个行，并且可以视为来自流行的开源项目中的样本。我们依据变量计数进行对象转换，以使变量保持稳定，并且提升了模型的适用度。 ⁴ 我们通过使用 AIC 和 Vuong 对非嵌套模型的测试比较来验证它们。

去检查那些过度的多重共线性（LCTT 译注：多重共线性是指，在线性回归模型中解释变量之间由于存在精确相关关系或高度相关关系而使模型估计失真或难以估计准确。）并不是一个问题，我们在所有的模型中使用一个保守的最大值 5，去计算每个依赖的变量的膨胀因子的方差。 ⁴ 我们通过对每个模型的残差和杠杆图进行视觉检查来移除高杠杆点，找出库克距离（LCTT 译注：一个统计学术语，用于诊断回归分析中是否存在异常数据）的分离值和最大值。

我们利用 效果 ，或者 差异 ，编码到我们的研究中，以提高编程语言回归系数的表现。 ⁴ 加权的效果代码允许我们将每种编程语言与所有编程语言的效果进行比较，同时弥补了跨项目使用编程语言的不均匀性。 ²³ 去测试两种变量因素之间的联系，我们使用一个独立的卡方检验（LCTT 译注：Chi-square，一种统计学上的假设检验方法）测试。 ¹⁴ 在证实一个依赖之后，我们使用 Cramer 的 V，它是与一个 r × c 等价的正常数据的 phi(φ) 系数，去建立一个效果数据。

3 结果

我们从简单明了的问题开始，它非常直接地解决了人们坚信的一些核心问题，即：

问题 1：一些编程语言相比其它语言来说更易于出现缺陷吗？

我们使用了回归分析模型，去比较每个编程语言对所有编程语言缺陷数量平均值的影响，以及对缺陷修复提交的影响（查看 表 6）。

表 6. 一些语言的缺陷要少于其它语言

我们包括了一些变量，作为对明确影响反应的控制因子。项目 年龄 age 也包括在内，因为，越老的项目生成的缺陷修复数量越大。 提交 commits 数量也会对项目反应有轻微的影响。另外，从事该项目的 开发人员 dev 的数量和项目的原始 大小 size ，都会随着项目的活跃而增长。

上述模型中估算系数的大小和符号（LCTT 译注：指 “+”或者“-”）与结果的预测因子有关。初始的四种变量是控制变量，并且，我们对这些变量对最终结果的影响不感兴趣，只是说它们都是积极的和有意义的。语言变量是指示变量，是每个项目的变化因子，该因子将每种编程语言与所有项目的编程语言的加权平均值进行比较。编程语言系数可以大体上分为三类。第一类是，那些在统计学上无关紧要的系数，并且在建模过程中这些系数不能从 0 中区分出来。这些编程语言的表现与平均值相似，或者它们也可能有更大的方差。剩余的系数是非常明显的，要么是正的，要么是负的。对于那些正的系数，我们猜测可能与这个编程语言有大量的缺陷修复相关。这些语言包括 C、C++、Objective-C、Php，以及 Python。所有的有一个负的系数的编程语言，比如 Clojure、Haskell、Ruby，和 Scala，暗示这些语言的缺陷修复提交可能小于平均值。

应该注意的是，虽然，从统计学的角度观察到编程语言与缺陷之间有明显的联系，但是，大家不要过高估计编程语言对于缺陷的影响，因为，这种影响效应是非常小的。异常分析的结果显示，这种影响小于总异常的 1%。

我们可以这样去理解模型的系数，它代表一个预测因子在所有其它预测因子保持不变的情况下，这个预测因子一个 单位 unit 的变化，所反应出的预期的响应的对数变化；换句话说，对于一个系数 β _i ，在 β _i 中一个单位的变化，产生一个预期的 e ^{β _i} 响应的变化。对于可变因子，这个预期的变化是与所有编程语言的平均值进行比较。因此，如果对于一定数量的提交，用一个处于平均值的编程语言开发的特定项目有四个缺陷提交，那么，如果选择使用 C++ 来开发，意味着我们预计应该有一个额外的（LCTT 译注：相对于平均值 4，多 1 个）缺陷提交，因为 e ^0.18 × 4 = 4.79。对于相同的项目，如果选择使用 Haskell 来开发，意味着我们预计应该少一个（LCTT 译注：同上，相对于平均值 4）缺陷提交。因为， e ^−0.26 × 4 = 3.08。预测的精确度取决于剩余的其它因子都保持不变，除了那些微不足道的项目之外，所有的这些都是一个极具挑战性的命题。所有观察性研究都面临类似的局限性；我们将在第 5 节中详细解决这些事情。

结论 1：一些编程语言相比其它编程语言有更高的缺陷相关度，不过，影响非常小。

在这篇文章的剩余部分，我们会在基本结论的基础上详细阐述，通过考虑不同种类的应用程序、缺陷、和编程语言，可以进一步深入了解编程语言和缺陷倾向之间的关系。

软件 bug 通常落进两种宽泛的分类中：

1. 特定领域的 bug ：特定于项目功能，并且不依赖于底层编程语言。
2. 普通 bug ：大多数的普通 bug 是天生的，并且与项目功能无关，比如，输入错误，并发错误、等等。

因此，在一个项目中，应用程序领域和编程语言相互作用可能会影响缺陷的数量，这一结论被认为是合理的。因为一些编程语言被认为在一些任务上相比其它语言表现更突出，例如，C 对于低级别的（底层）工作，或者，Java 对于用户应用程序，对于编程语言的一个不合适的选择，可能会带来更多的缺陷。为研究这种情况，我们将理想化地忽略领域特定的 bug，因为，普通 bug 更依赖于编程语言的特性。但是，因为一个领域特定的 bug 也可能出现在一个普通的编程错误中，这两者是很难区分的。一个可能的变通办法是在控制领域的同时去研究编程语言。从统计的角度来看，虽然，使用 17 种编程语言跨 7 个领域，在给定的样本数量中，理解大量的术语将是一个极大的挑战。

鉴于这种情况，我们首先考虑在一个项目中测试领域和编程语言使用之间的依赖关系，独立使用一个 卡方检验 Chi-square 测试。在 119 个单元中，是 46 个，也就是说是 39%，它在我们设定的保守值 5 以上，它太高了。这个数字不能超过 20%，应该低于 5。 ¹⁴ 我们在这里包含了完整有值； ^d 但是，通过 Cramer 的 V 测试的值是 0.191，是低相关度的，表明任何编程语言和领域之间的相关度是非常小的，并且，在回归模型中包含领域并不会产生有意义的结果。

去解决这种情况的一个选择是，去移除编程语言，或者混合领域，但是，我们现有的数据没有进行完全挑选。或者，我们混合编程语言；这个选择导致一个相关但略有不同的问题。

问题 2： 哪些编程语言特性与缺陷相关？

我们按编程语言类别聚合它们，而不是考虑单独的编程语言，正如在第 2.2 节所描述的那样，然后去分析与缺陷的关系。总体上说，这些属性中的每一个都将编程语言按照在上下文中经常讨论的错误、用户辩论驱动、或者按以前工作主题来划分的。因此，单独的属性是高度相关的，我们创建了六个模型因子，将所有的单独因子综合到我们的研究中。然后，我们对六个不同的因子对缺陷数量的影响进行建模，同时控制我们在 问题 1 节中使用的模型中的相同的基本协变量（LCTT 译注：协变量是指在实验中不能被人为操纵的独立变量）。

关于使用的编程语言（在前面的 表 6中），我们使用跨所有语言类的平均反应来比较编程语言 类 。这个模型在 表 7 中表达了出来。很明显，Script-Dynamic-Explicit-Managed 类有最小的量级系数。这个系数是微不足道的，换句话说，对这个系数的 Z 校验 z-test （LCTT 译注：统计学上的一种平均值差异校验的方法） 并不能把它从 0 中区分出来。鉴于标准错误的量级，我们可以假设，在这个类别中的编程语言的行为是非常接近于所有编程语言行为的平均值。我们可以通过使用 Proc-Static-Implicit-Unmanaged 作为基本级并用于处理，或者使用基本级来虚假编码比较每个语言类，来证明这一点。在这种情况下，Script-Dynamic-Explicit-Managed 是明显不同于 p = 0.00044 的。注意，虽然我们在这是选择了不同的编码方法，影响了系数和 Z 值，这个方法和所有其它的方面都是一样的。当我们改变了编码，我们调整系数去反应我们希望生成的对比。 ⁴ 将其它类的编程语言与总体平均数进行比较，Proc-Static-Implicit-Unmanaged 类编程语言更容易引起缺陷。这意味着与其它过程类编程语言相比，隐式类型转换或者管理内存会导致更多的缺陷倾向。

表 7. 函数式语言与缺陷的关联度和其它类语言相比要低，而过程类语言则大于或接近于平均值。

在脚本类编程语言中，我们观察到类似于允许与不允许隐式类型转换的编程语言之间的关系，它们提供的一些证据表明，隐式类型转换（与显式类型转换相比）才是导致这种差异的原因，而不是内存管理。鉴于各种因素之间的相关性，我们并不能得出这个结论。但是，当它们与平均值进行比较时，作为一个组，那些不允许隐式类型转换的编程语言出现错误的倾向更低一些，而那些出现错误倾向更高的编程语言，出现错误的机率则相对更高。在函数式编程语言中静态和动态类型之间的差异也很明显。

函数式语言作为一个组展示了与平均值的很明显的差异。静态类型语言的系数要小很多，但是函数式语言类都有同样的标准错误。函数式静态编程语言出现错误的倾向要小于函数式动态编程语言，这是一个强有力的证据，尽管如此，Z 校验仅仅是检验系数是否能从 0 中区分出来。为了强化这个推论，我们使用处理编码，重新编码了上面的模型，并且观察到，Functional-Static-Explicit-Managed 编程语言类的错误倾向是明显小于 Functional-Dynamic-Explicit-Managed 编程语言类的 p = 0.034。

与编程语言和缺陷一样，编程语言类与缺陷之间关系的影响是非常小的。解释类编程语言的这种差异也是相似的，虽然很小，解释类编程语言的这种差异小于 1%。

我们现在重新回到应用领域这个问题。应用领域是否与语言类相互影响？怎么选择？例如，一个函数化编程语言，对特定的领域有一定的优势？与上面一样，对于这些因素和项目领域之间的关系做一个卡方检验，它的值是 99.05， df = 30， p = 2.622e–09，我们拒绝无意义假设，Cramer 的 V 产生的值是 0.133，表示一个弱关联。因此，虽然领域和编程语言之间有一些关联，但在这里应用领域和编程语言类之间仅仅是一个非常弱的关联。

结论 2：在编程语言类与缺陷之间有一个很小但是很明显的关系。函数式语言与过程式或者脚本式语言相比，缺陷要少。

这个结论有些不太令人满意的地方，因为，我们并没有一个强有力的证据去证明，在一个项目中编程语言或者语言类和应用领域之间的关联性。一个替代方法是，基于全部的编程语言和应用领域，忽略项目和缺陷总数，而去查看相同的数据。因为，这样不再产生不相关的样本，我们没有从统计学的角度去尝试分析它，而是使用一个描述式的、基于可视化的方法。

我们定义了 缺陷倾向 Defect Proneness 作为 bug 修复提交与每语言每领域总提交的比率。图 1 使用了一个热力图展示了应用领域与编程语言之间的相互作用，从亮到暗表示缺陷倾向在增加。我们研究了哪些编程语言因素影响了跨多种语言写的项目的缺陷修复提交。它引出了下面的研究问题：

图 1. 编程语言的缺陷倾向与应用领域之间的相互作用。对于一个给定的领域（列底部），热力图中的每个格子表示了一个编程语言的缺陷倾向（行头部）。“整体”列表示一个编程语言基于所有领域的缺陷倾向。用白色十字线标记的格子代表一个 null 值，换句话说，就是在那个格子里没有符合的提交。

问题 3： 编程语言的错误倾向是否取决于应用领域？

为了回答这个问题，我们首先在我们的回归模型中，以高杠杆点过滤掉认为是异常的项目，这种方法在这里是必要的，尽管这是一个非统计学的方法，一些关系可能影响可视化。例如，我们找到一个简单的项目，Google 的 v8，一个 JavaScript 项目，负责中间件中的所有错误。这对我们来说是一个惊喜，因为 JavaScript 通常不用于中间件。这个模式一直在其它应用领域中不停地重复着，因此，我们过滤出的项目的缺陷度都低于 10% 和高于 90%。这个结果在 图 1 中。

我们看到在这个热力图中仅有一个很小的差异，正如在问题 1 节中看到的那样，这个结果仅表示编程语言固有的错误倾向。为验证这个推论，我们测量了编程语言对每个应用领域和对全部应用领域的缺陷倾向。对于除了数据库以外的全部领域，关联性都是正向的，并且 p 值是有意义的（<0.01）。因此，关于缺陷倾向，在每个领域的语言排序与全部领域的语言排序是基本相同的。

结论 3： 应用领域和编程语言缺陷倾向之间总体上没有联系。

我们证明了不同的语言产生了大量的缺陷，并且，这个关系不仅与特定的语言相关，也适用于一般的语言类；然而，我们发现，项目类型并不能在一定程度上协调这种关系。现在，我们转变我们的注意力到反应分类上，我想去了解，编程语言与特定种类的缺陷之间有什么联系，以及这种关系怎么与我们观察到的更普通的关系去比较。我们将缺陷分为不同的类别，如 表 5 所描述的那样，然后提出以下的问题：

问题 4：编程语言与 bug 分类之间有什么关系？

我们使用了一个类似于问题 3 中所用的方法，去了解编程语言与 bug 分类之间的关系。首先，我们研究了 bug 分类和编程语言类之间的关系。一个热力图（图 2）展示了在编程语言类和 bug 类型之上的总缺陷数。去理解 bug 分类和语言之间的相互作用，我们对每个类别使用一个 NBR 回归模型。对于每个模型，我们使用了与问题 1 中相同的控制因素，以及使用加权效应编码后的语言，去预测缺陷修复提交。

图 2. bug 类别与编程语言类之间的关系。每个格子表示每语言类（行头部）每 bug 类别（列底部）的 bug 修复提交占全部 bug 修复提交的百分比。这个值是按列规范化的。

结果和编程语言的方差分析值展示在 表 8 中。每个模型的整体异常是非常小的，并且对于特定的缺陷类型，通过语言所展示的比例在大多数类别中的量级是类似的。我们解释这种关系为，编程语言对于特定的 bug 类别的影响要大于总体的影响。尽管我们结论概括了全部的类别，但是，在接下来的一节中，我们对 表 5 中反应出来的 bug 数较多的 bug 类别做进一步研究。

表 8. 虽然编程语言对缺陷的影响因缺陷类别而不同，但是，编程语言对特定的类别的影响要大于一般的类别。

编程错误 普通的编程错误占所有 bug 修复提交的 88.53% 左右，并且在所有的编程语言类中都有。因此，回归分析给出了一个与问题 1 中类似的结论（查看 表 6）。所有的编程语言都会导致这种编程错误，比如，处理错误、定义错误、输入错误、等等。

内存错误 内存错误占所有 bug 修复提交的 5.44%。热力图 图 2 证明了在 Proc-Static-Implicit-Unmanaged 类和内存错误之间存在着非常紧密的联系。非管理内存的编程语言出现内存 bug，这是预料之中的。表 8 也证明了这一点，例如，C、C++、和 Objective-C 引发了很多的内存错误。在管理内存的语言中 Java 引发了更多的内存错误，尽管它少于非管理内存的编程语言。虽然 Java 自己做内存回收，但是，它出现内存泄露一点也不奇怪，因为对象引用经常阻止内存回收。 ¹¹ 在我们的数据中，Java 的所有内存错误中，28.89% 是内存泄漏造成的。就数量而言，编程语言中内存缺陷相比其它类别的 原因 造成的影响要大很多。

并发错误 在总的 bug 修复提交中，并发错误相关的修复提交占 1.99%。热力图显示，Proc-Static-Implicit-Unmanaged 是主要的错误类型。在这种错误中，C 和 C++ 分别占 19.15% 和 7.89%，并且它们分布在各个项目中。

属于 Static-Strong-Managed 语言类的编程语言都被证实处于热力图中的暗区中，普通的静态语言相比其它语言产生更多的并发错误。在动态语言中，仅仅有 Erlang 有更多的并发错误倾向，或许与使用这种语言开发的并发应用程序非常多有关系。同样地，在 表 8 中的负的系数表明，用诸如 Ruby 和 `Php 这样的动态编程语言写的项目，并发错误要少一些。请注意，某些语言，如 JavaScript、CoffeeScript 和 TypeScript 是不支持并发的，在传统的惯例中，虽然 Php 具有有限的并发支持（取决于它的实现）。这些语言在我们的数据中引入了虚假的 0，因此，在 表 8 中这些语言的并发模型的系数，不能像其它的语言那样去解释。因为存在这些虚假的 0，所以在这个模型中所有语言的平均数非常小，它可能影响系数的大小，因此，她们给 w.r.t. 一个平均数，但是，这并不影响他们之间的相对关系，因为我们只关注它们的相对关系。

基于 bug 修复消息中高频词的文本分析表明，大多数的并发错误发生在一个条件争用、死锁、或者不正确的同步上，正如上面表中所示。遍历所有语言，条件争用是并发错误出现最多的原因，例如，在 Go 中占 92%。在 Go 中条件争用错误的改进，或许是因为使用了一个争用检测工具帮助开发者去定位争用。同步错误主要与消息传递接口（MPI）或者共享内存操作（SHM）相关。Erlang 和 Go 对线程间通讯使用 MPI ^e ，这就是为什么这两种语言没有发生任何 SHM 相关的错误的原因，比如共享锁、互斥锁等等。相比之下，为线程间通讯使用早期的 SHM 技术的语言写的项目，就可能存在锁相关的错误。

安全和其它冲突错误 在所有的 bug 修复提交中，与 冲突 Impact 错误相关的提交占了 7.33% 左右。其中，Erlang、C++、Python 与安全相关的错误要高于平均值（表 8）。Clojure 项目相关的安全错误较少（图 2）。从热力图上我们也可以看出来，静态语言一般更易于发生失败和性能错误，紧随其后的是 Functional-Dynamic-Explicit-Managed 语言，比如 Erlang。对异常结果的分析表明，编程语言与冲突失败密切相关。虽然安全错误在这个类别中是弱相关的，与残差相比，解释类语言的差异仍然比较大。

结论 4： 缺陷类型与编程语言强相关；一些缺陷类型比如内存错误和并发错误也取决于早期的语言（所使用的技术）。对于特定类别，编程语言所引起的错误比整体更多。

4. 相关工作

在编程语言比较之前做的工作分为以下三类：

(1) 受控实验

对于一个给定的任务，开发者使用不同的语言进行编程时受到监视。研究然后比较结果，比如，开发成果和代码质量。Hanenberg ⁷ 通过开发一个解析程序，对 48 位程序员监视了 27 小时，去比较了静态与动态类型。他发现这两者在代码质量方面没有显著的差异，但是，基于动态类型的语言花费了更短的开发时间。他们的研究是在一个实验室中，使用本科学生，设置了定制的语言和 IDE 来进行的。我们的研究正好相反，是一个实际的流行软件应用的研究。虽然我们只能够通过使用回归模型间接（和 事后 ）控制混杂因素，我们的优势是样本数量大，并且更真实、使用更广泛的软件。我们发现在相同的条件下，静态化类型的语言比动态化类型的语言更少出现错误倾向，并且不允许隐式类型转换的语言要好于允许隐式类型转换的语言，其对结果的影响是非常小的。这是合理的，因为样本量非常大，所以这种非常小的影响在这个研究中可以看得到。

Harrison et al. ⁸ 比较了 C++ 与 SML，一个是过程化编程语言，一个是函数化编程语言，在总的错误数量上没有找到显著的差异，不过 SML 相比 C++ 有更高的缺陷密集度。SML 在我们的数据中并没有体现出来，不过，认为函数式编程语言相比过程化编程语言更少出现缺陷。另一个重点工作是比较跨不同语言的开发工作。 ^{12 ， 20} 不过，他们并不分析编程语言的缺陷倾向。

(2) 调查

Meyerovich 和 Rabkin ¹⁶ 调查了开发者对编程语言的观点，去研究为什么一些编程语言比其它的语言更流行。他们的报告指出，非编程语言的因素影响非常大：先前的编程语言技能、可用的开源工具、以及现有的老式系统。我们的研究也证明，可利用的外部工具也影响软件质量；例如，在 Go 中的并发 bug（请查看问题 4 节内容）。

(3) 对软件仓库的挖掘

Bhattacharya 和 Neamtiu ¹ 研究了用 C 和 C++ 开发的四个项目，并且发现在 C++ 中开发的组件一般比在 C 中开发的组件更可靠。我们发现 C 和 C++ 的错误倾向要高于全部编程语言的平均值。但是，对于某些 bug 类型，像并发错误，C 的缺陷倾向要高于 C++（请查看第 3 节中的问题 4）。

5. 有效的风险

我们认为，我们的报告的结论几乎没有风险。首先，在识别 bug 修复提交方面，我们依赖的关键字是开发者经常用于表示 bug 修复的关键字。我们的选择是经过认真考虑的。在一个持续的开发过程中，我们去捕获那些开发者一直面对的问题，而不是他们报告的 bug。不过，这种选择存在过高估计的风险。我们对领域分类是为了去解释缺陷的倾向，而且，我们研究组中另外的成员验证过分类。此外，我们花费精力去对 bug 修复提交进行分类，也可能有被最初选择的关键字所污染的风险。每个项目在提交日志的描述上也不相同。为了缓解这些风险，我们像 2.4 节中描述的那样，利用手工注释评估了我们的类别。

我们判断文件所属的编程语言是基于文件的扩展名。如果使用不同的编程语言写的文件使用了我们研究的通用的编程语言文件的扩展名，这种情况下也容易出现错误倾向。为减少这种错误，我们使用一个随机样本文件集手工验证了我们的语言分类。

根据我们的数据集所显示的情形，2.2 节中的解释类编程语言，我们依据编程语言属性的主要用途作了一些假设。例如，我们将 Objective-C 分到非管理内存类型中，而不是混合类型。同样，我们将 Scala 注释为函数式编程语言，将 C# 作为过程化的编程语言，虽然，它们在设计的选择上两者都支持。 ^{19 ， 21} 在这项研究工作中，我们没有从过程化编程语言中分离出面向对象的编程语言（OOP），因为，它们没有清晰的区别，主要差异在于编程类型。我们将 C++ 分到允许隐式类型转换的类别中是因为，某些类型的内存区域可以通过使用指针操作被进行不同的处理， ²² 并且我们注意到大多数 C++ 编译器可以在编译时检测类型错误。

最后，我们将缺陷修复提交关联到编程语言属性上，它们可以反应出报告的风格或者其它开发者的属性。可用的外部工具或者 库 library 也可以影响一个相关的编程语言的 bug 数量。

6. 总结

我们对编程语言和使用进行了大规模的研究，因为它涉及到软件质量。我们使用的 Github 上的数据，具有很高的复杂性和多个维度上的差异的特性。我们的样本数量允许我们对编程语言效果以及在控制一些混杂因素的情况下，对编程语言、应用领域和缺陷类型之间的相互作用，进行一个混合方法的研究。研究数据显示，函数式语言是好于过程化语言的；不允许隐式类型转换的语言是好于允许隐式类型转换的语言的；静态类型的语言是好于动态类型的语言的；管理内存的语言是好于非管理的语言的。进一步讲，编程语言的缺陷倾向与软件应用领域并没有关联。另外，每个编程语言更多是与特定的 bug 类别有关联，而不是与全部 bug。

另一方面，即便是很大规模的数据集，它们被多种方法同时进行分割后，也变得很小且不全面。因此，随着依赖的变量越来越多，很难去回答某个变量所产生的影响有多大这种问题，尤其是在变量之间相互作用的情况下。因此，我们无法去量化编程语言在使用中的特定的效果。其它的方法，比如调查，可能对此有帮助。我们将在以后的工作中来解决这些挑战。

致谢

这个材料是在美国国家科学基金会（NSF）以及美国空军科学研究办公室（AFOSR）的授权和支持下完成的。授权号 1445079, 1247280, 1414172，1446683，FA955-11-1-0246。

参考资料

1. Bhattacharya, P., Neamtiu, I. Assessing programming language impact on development and maintenance: A study on C and C++. In Proceedings of the 33rd International Conference on Software Engineering, ICSE'11 (New York, NY USA, 2011). ACM, 171–180.
2. Bird, C., Nagappan, N., Murphy, B., Gall, H., Devanbu, P. Don't touch my code! Examining the effects of ownership on software quality. In Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering (2011). ACM, 4–14.
3. Blei, D.M. Probabilistic topic models. Commun. ACM 55 , 4 (2012), 77–84.
4. Cohen, J. Applied Multiple Regression/Correlation Analysis for the Behavioral Sciences. Lawrence Erlbaum, 2003.
5. Easterbrook, S., Singer, J., Storey, M.-A., Damian, D. Selecting empirical methods for software engineering research. In Guide to Advanced Empirical Software Engineering (2008). Springer, 285–311.
6. El Emam, K., Benlarbi, S., Goel, N., Rai, S.N. The confounding effect of class size on the validity of object-oriented metrics. IEEE Trans. Softw. Eng. 27 , 7 (2001), 630–650.
7. Hanenberg, S. An experiment about static and dynamic type systems: Doubts about the positive impact of static type systems on development time. In Proceedings of the ACM International Conference on Object Oriented Programming Systems Languages and Applications, OOPSLA'10 (New York, NY, USA, 2010). ACM, 22–35.
8. Harrison, R., Smaraweera, L., Dobie, M., Lewis, P. Comparing programming paradigms: An evaluation of functional and object-oriented programs. Softw. Eng. J. 11 , 4 (1996), 247–254.
9. Harter, D.E., Krishnan, M.S., Slaughter, S.A. Effects of process maturity on quality, cycle time, and effort in software product development. Manage. Sci. 46 4 (2000), 451–466.
10. Hindley, R. The principal type-scheme of an object in combinatory logic. Trans. Am. Math. Soc. (1969), 29–60.
11. Jump, M., McKinley, K.S. Cork: Dynamic memory leak detection for garbage-collected languages. In ACM SIGPLAN Notices , Volume 42 (2007). ACM, 31–38.
12. Kleinschmager, S., Hanenberg, S., Robbes, R., Tanter, É., Stefik, A. Do static type systems improve the maintainability of software systems? An empirical study. In 2012 IEEE 20th International Conference on Program Comprehension (ICPC) (2012). IEEE, 153–162.
13. Li, Z., Tan, L., Wang, X., Lu, S., Zhou, Y., Zhai, C. Have things changed now? An empirical study of bug characteristics in modern open source software. In ASID'06: Proceedings of the 1st Workshop on Architectural and System Support for Improving Software Dependability (October 2006).
14. Marques De Sá, J.P. Applied Statistics Using SPSS, Statistica and Matlab , 2003.
15. Mayer, C., Hanenberg, S., Robbes, R., Tanter, É., Stefik, A. An empirical study of the influence of static type systems on the usability of undocumented software. In ACM SIGPLAN Notices , Volume 47 (2012). ACM, 683–702.
16. Meyerovich, L.A., Rabkin, A.S. Empirical analysis of programming language adoption. In Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages & Applications (2013). ACM, 1–18.
17. Milner, R. A theory of type polymorphism in programming. J. Comput. Syst. Sci. 17 , 3 (1978), 348–375.
18. Mockus, A., Votta, L.G. Identifying reasons for software changes using historic databases. In ICSM'00. Proceedings of the International Conference on Software Maintenance (2000). IEEE Computer Society, 120.
19. Odersky, M., Spoon, L., Venners, B. Programming in Scala. Artima Inc, 2008.
20. Pankratius, V., Schmidt, F., Garretón, G. Combining functional and imperative programming for multicore software: An empirical study evaluating scala and java. In Proceedings of the 2012 International Conference on Software Engineering (2012). IEEE Press, 123–133.
21. Petricek, T., Skeet, J. Real World Functional Programming: With Examples in F# and C#. Manning Publications Co., 2009.
22. Pierce, B.C. Types and Programming Languages. MIT Press, 2002.
23. Posnett, D., Bird, C., Dévanbu, P. An empirical study on the influence of pattern roles on change-proneness. Emp. Softw. Eng. 16 , 3 (2011), 396–423.
24. Tan, L., Liu, C., Li, Z., Wang, X., Zhou, Y., Zhai, C. Bug characteristics in open source software. Emp. Softw. Eng. (2013).

作者

Baishakhi Ray ([email protected]), Department of Computer Science, University of Virginia, Charlottesville, VA.

Daryl Posnett ([email protected]), Department of Computer Science, University of California, Davis, CA.

Premkumar Devanbu ([email protected]), Department of Computer Science, University of California, Davis, CA.

Vladimir Filkov ([email protected]), Department of Computer Science, University of California, Davis, CA.

脚注

• a. Wikipedia's article on type conversion, https://en.wikipedia.org/wiki/Type_conversion, has more examples of unintended behavior in C.
• b. This Apple developer article describes the usage of "id" http://tinyurl.com/jkl7cby.
• c. Some examples can be found here http://dobegin.com/objc-id-type/andherehttp://tinyurl.com/hxv8kvg.
• d. Chi-squared value of 243.6 with 96 df. and p = 8.394e–15
• e. MPI does not require locking of shared resources.

via: https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/fulltext?imm_mid=0f7103&cmp=em-prog-na-na-newsltr_20171007

作者：Baishakhi Ray, Daryl Posnett, Premkumar Devanbu, Vladimir Filkov 译者：qhwdw 校对：wxy

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

以及，还有三本是给宝宝的。

在工作之余，我听说不少技术专家透露出让他们自己的孩子学习更多关于 Linux 和 开源知识的意愿，他们中有的来自高管层，有的来自普通岗位。其中一些似乎时间比较充裕，伴随其孩子一步一步成长。另一些人可能没有充足的时间让他们的孩子看到为何 Linux 和 开源如此之酷。也许他们能抽出时间，但这不一定。在这个大世界中，有太多有趣、有价值的事物。

不论是哪种方式，如果你的或你认识的孩子愿意学习使用编程和硬件，实现游戏或机器人之类东西，那么这份书单很适合你。

面向儿童 Linux 和 开源爱好者的 15 本书

《零基础学 Raspberry Pi》，作者 Carrie Anne Philbin

在对编程感兴趣的儿童和成人中，体积小小的、仅信用卡一般大的树莓派引起了强烈的反响。你台式机能做的事情它都能做，具备一定的基础编程技能后，你可以让它做更多的事情。本书操作简明、项目风趣、技能扎实，是一本儿童可用的终极编程指南。（Joshua Allen Holm 推荐，评论节选于本书的内容提要）

《Python 编程快速上手：让繁琐工作自动化》，作者 Al Sweigart

这是一本经典的编程入门书，行文足够清晰，11 岁及以上的编程爱好者都可以读懂本书并从中受益。读者很快就会投入到真实且实用的任务中，在此过程中顺便掌握了优秀的编程实践。最好的一点是，如果你愿意，你可以在互联网上阅读本书。（DB Clinton 推荐并评论）

《Scratch 游戏编程》，作者 Jon Woodcock

本书适用于 8-12 岁没有或仅有有限编程经验的儿童。作为一本直观的可视化入门书，它使用有趣的图形和易于理解的操作，教导年轻的读者如何使用 Scratch 这款流行的自由编程语言构建他们自己的编程项目。（Joshua Allen Holm 推荐，评论节选于本书的内容提要）

《用 Python 巧学数学》，作者 Amit Saha

无论你是一名学生还是教师，只要你对使用 Python 学习数学感兴趣，不妨读读本书。在逻辑上，本书带领读者一步一步地从基础到更为复杂的操作，从最开始简单的 Python shell 数字运算，到使用类似 matplotlib 这样的 Python 库实现数据可视化，读者可以很容易跟上作者的思路。本书充分调动你的好奇心，感叹 Python 与 数学结合的威力。（Don Watkins 推荐并评论）

《编程女生：学习编程，改变世界》，作者 Reshma Saujani

作者是 Girls Who Code 运动的发起人，该运动得到 Sheryl Sandberg、 Malala Yousafzai 和 John Legend 支持。本书一部分是编程介绍，一部分女生赋能，这两部分都写得很有趣。本书包括动态艺术作品、零基础的编程原理讲解以及在 Pixar 和 NASA 等公司工作的女生的真实故事。这本书形象生动，向读者展示了计算机科学在我们生活中发挥的巨大作用以及其中的趣味。（Joshua Allen Holm 推荐，评论节选于本书的内容提要）

《Python 游戏编程快速上手》，作者 Al Sweigart

本书将让你学会如何使用流行的 Python 编程语言编写计算机游戏，不要求具有编程经验！入门阶段编写 刽子手 Hangman ，猜数字， 井字游戏 Tic-Tac-Toe 这样的经典游戏，后续更进一步编写高级一些的游戏，例如文字版寻宝游戏，以及带音效和动画的 碰撞与闪避 collision-dodgoing 游戏。（Joshua Allen Holm 推荐，评论节选于本书的内容提要）

《Lauren Ipsum：关于计算机科学和一些不可思议事物的故事》，作者 Carlos Bueno

本书采用爱丽丝梦游仙境的风格，女主角 Lauren Ipsum 来到一个稍微具有魔幻色彩的世界。世界的自然法则是逻辑学和计算机科学，世界谜题只能通过学习计算机编程原理并编写代码完成。书中没有提及计算机，但其作为世界的核心存在。（DB Clinton 推荐并评论）

《Java 轻松学》，作者 Bryson Payne

Java 是全世界最流行的编程语言，但众所周知上手比较难。本书让 Java 学习不再困难，通过若干实操项目，让你马上学会构建真实可运行的应用。（Joshua Allen Holm 推荐，评论节选于本书的内容提要）

《终身幼儿园》，作者 Mitchell Resnick

幼儿园正变得越来越像学校。在本书中，学习专家 Mitchel Resnick 提出相反的看法：学校（甚至人的一生）应该更像幼儿园。要适应当今快速变化的世界，各个年龄段的人们都必须学会开创性思维和行动；想要达到这个目标，最好的方式就是更加专注于想象、创造、玩耍、分享和反馈，就像孩子在传统幼儿园中那样。基于在 MIT 媒体实验室 Media Lab 30 多年的经历， Resnick 讨论了新的技术和策略，可以让年轻人拥有开创性的学习体验。（Don Watkins 推荐，评论来自 Amazon 书评）

《趣学 Python：教孩子学编程》，作者 Jason Briggs

在本书中，Jason Briggs 将 Python 编程教学艺术提升到新的高度。我们可以很容易地将本书用作入门书，适用群体可以是教师/学生，也可以是父母/儿童。通过一步步引导的方式介绍复杂概念，让编程新手也可以成功完成，进一步激发学习欲望。本书是一本极为易读、寓教于乐但又强大的 Python 编程入门书。读者将学习基础数据结构，包括 元组 turple 、 列表 list 和 映射 map 等，学习如何创建函数、重用代码或者使用包括循环和条件语句在内的控制结构。孩子们还将学习如何创建游戏和动画，体验 Tkinter 的强大并创建高级图形。（Don Watkins 推荐并评论）

《Scratch 编程园地》，作者 Al Sweigart

Scratch 编程一般被视为一种寓教于乐的教年轻人编程的方式。在本书中，Al Sweigart 告诉我们 Scratch 是一种超出绝大多数人想象的强大编程语言。独特的风格，大师级的编写和呈现。Al 让孩子通过创造复杂图形和动画，短时间内认识到 Scratch 的强大之处。（Don Watkins 推荐并评论）

《秘密编程者》，作者 Gene Luen Yang，插图作者 Mike Holmes

Gene Luen Yang 是漫画小说超级巨星，也是一所高中的计算机编程教师。他推出了一个非常有趣的系列作品，将逻辑谜题、基础编程指令与引入入胜的解谜情节结合起来。故事发生在 Stately Academy 这所学校，其中充满有待解开的谜团。（Joshua Allen Holm 推荐，评论节选于本书的内容提要）

《想成为编程者吗？编程、视频游戏制作、机器人等职业终极指南！》，作者 Jane Bedell

酷爱编程？这本书易于理解，描绘了以编程为生的完整图景，激发你的热情，磨练你的专业技能。（Joshua Allen Holm 推荐，评论节选于本书的内容提要）

《教孩子编程》，作者 Bryson Payne

你是否在寻找一种寓教于乐的方式教你的孩子 Python 编程呢？Bryson Payne 已经写了这本大师级的书。本书通过乌龟图形打比方，引导你编写一些简单程序，为高级 Python 编程打下基础。如果你打算教年轻人编程，这本书不容错过。（Don Watkins 推荐并评论）

《图解 Kubernetes（儿童版）》，作者 Matt Butcher, 插画作者 Bailey Beougher

介绍了 Phippy 这个勇敢的 PHP 小应用及其 Kubernetes 之旅。（Chris Short 推荐，评论来自 Matt Butcher 的博客）

给宝宝的福利书

《宝宝的 CSS》、《宝宝的 Javascript》、《宝宝的 HTML》，作者 Sterling Children's

这本概念书让宝宝熟悉图形和颜色的种类，这些是互联网编程语言的基石。这本漂亮的书用富有色彩的方式介绍了编程和互联网，对于技术人士的家庭而言，本书是一份绝佳的礼物。（Chris Short 推荐，评论来自 Amazon 书评）

你是否有想要分享的适合宝宝或儿童的书呢？请在评论区留言告诉我们。

via: https://opensource.com/article/18/5/books-kids-linux-open-source

作者：Jen Wike Huger 选题：lujun9972 译者：pinewall 校对：wxy

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