由于 Linux 和 Mac OS X 是基于 *Nix 的系统，因此许多命令可以在两个平台上运行。但是，某些命令可能在两个平台上都没有，比如 pbcopy 和 pbpast。这些命令仅在 Mac OS X 平台上可用。pbcopy 命令将标准输入复制到剪贴板。然后，你可以在任何地方使用 pbpaste 命令粘贴剪贴板内容。当然，上述命令可能有一些 Linux 替代品，例如 xclip。 xclip 与 pbcopy 完全相同。但是，从 Mac OS 切换到 Linux 的发行版的人将会找不到这两个命令，不过仍然想使用它们。别担心！这个简短的教程描述了如何在 Linux 上使用 pbcopy 和 pbpaste 命令。

安装 xclip / xsel

就像我已经说过的那样，Linux 中没有 pbcopy 和 pbpaste 命令。但是，我们可以通过 shell 别名使用 xclip 和/或 xsel 命令复制 pbcopy 和 pbpaste 命令的功能。xclip 和 xsel 包存在于大多数 Linux 发行版的默认存储库中。请注意，你无需安装这两个程序。只需安装上述任何一个程序即可。

要在 Arch Linux 及其衍生产版上安装它们，请运行：

$ sudo pacman xclip xsel

在 Fedora 上：

$ sudo dnf xclip xsel

在 Debian、Ubuntu、Linux Mint 上：

$ sudo apt install xclip xsel

安装后，你需要为 pbcopy 和 pbpaste 命令创建别名。为此，请编辑 ~/.bashrc：

$ vi ~/.bashrc

如果要使用 xclip，请粘贴以下行：

alias pbcopy='xclip -selection clipboard'
alias pbpaste='xclip -selection clipboard -o'

如果要使用 xsel，请在 ~/.bashrc 中粘贴以下行。

alias pbcopy='xsel --clipboard --input'
alias pbpaste='xsel --clipboard --output'

保存并关闭文件。

接下来，运行以下命令以更新 ~/.bashrc 中的更改。

$ source ~/.bashrc

ZSH 用户将上述行粘贴到 ~/.zshrc 中。

在 Linux 上使用 pbcopy 和 pbpaste 命令

让我们看一些例子。

pbcopy 命令将文本从 stdin 复制到剪贴板缓冲区。例如，看看下面的例子。

$ echo "Welcome To OSTechNix!" | pbcopy

上面的命令会将文本 “Welcome to OSTechNix” 复制到剪贴板中。你可以稍后访问此内容并使用如下所示的 pbpaste 命令将其粘贴到任何位置。

$ echo `pbpaste`
Welcome To OSTechNix!

以下是一些其他例子。

我有一个名为 file.txt 的文件，其中包含以下内容。

$ cat file.txt
Welcome To OSTechNix!

你可以直接将文件内容复制到剪贴板中，如下所示。

$ pbcopy < file.txt

现在，只要你用其他文件的内容更新了剪切板，那么剪切板中的内容就可用了。

要从剪贴板检索内容，只需输入：

$ pbpaste
Welcome To OSTechNix!

你还可以使用管道字符将任何 Linux 命令的输出发送到剪贴板。看看下面的例子。

$ ps aux | pbcopy

现在，输入 pbpaste 命令以显示剪贴板中 ps aux 命令的输出。

$ pbpaste

使用 pbcopy 和 pbpaste 命令可以做更多的事情。我希望你现在对这些命令有一个基本的想法。

就是这些了。还有更好的东西。敬请关注！

干杯!

via: https://www.ostechnix.com/how-to-use-pbcopy-and-pbpaste-commands-on-linux/

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

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

用简洁而优雅的 Git 命令撤销仓库中的改变。

使用 Git 工作时其中一个鲜为人知（和没有意识到）的方面就是，如何轻松地返回到你以前的位置 —— 也就是说，在仓库中如何很容易地去撤销那怕是重大的变更。在本文中，我们将带你了解如何去重置、恢复和完全回到以前的状态，做到这些只需要几个简单而优雅的 Git 命令。

重置

我们从 Git 的 reset 命令开始。确实，你应该能够认为它就是一个 “回滚” —— 它将你本地环境返回到之前的提交。这里的 “本地环境” 一词，我们指的是你的本地仓库、暂存区以及工作目录。

先看一下图 1。在这里我们有一个在 Git 中表示一系列提交的示意图。在 Git 中一个分支简单来说就是一个命名的、指向一个特定的提交的可移动指针。在这里，我们的 master 分支是指向链中最新提交的一个指针。

图 1：有仓库、暂存区、和工作目录的本地环境

如果看一下我们的 master 分支是什么，可以看一下到目前为止我们产生的提交链。

$ git log --oneline
b764644 File with three lines
7c709f0 File with two lines
9ef9173 File with one line

如果我们想回滚到前一个提交会发生什么呢？很简单 —— 我们只需要移动分支指针即可。Git 提供了为我们做这个动作的 reset 命令。例如，如果我们重置 master 为当前提交回退两个提交的位置，我们可以使用如下之一的方法：

$ git reset 9ef9173

（使用一个绝对的提交 SHA1 值 9ef9173）

或：

$ git reset current~2

（在 “current” 标签之前，使用一个相对值 -2）

图 2 展示了操作的结果。在这之后，如果我们在当前分支（master）上运行一个 git log 命令，我们将看到只有一个提交。

$ git log --oneline

9ef9173 File with one line

图 2：在 reset 之后

git reset 命令也包含使用一些选项，可以让你最终满意的提交内容去更新本地环境的其它部分。这些选项包括：hard 在仓库中去重置指向的提交，用提交的内容去填充工作目录，并重置暂存区；soft 仅重置仓库中的指针；而 mixed（默认值）将重置指针和暂存区。

这些选项在特定情况下非常有用，比如，git reset --hard <commit sha1 | reference> 这个命令将覆盖本地任何未提交的更改。实际上，它重置了（清除掉）暂存区，并用你重置的提交内容去覆盖了工作区中的内容。在你使用 hard 选项之前，一定要确保这是你真正地想要做的操作，因为这个命令会覆盖掉任何未提交的更改。

恢复

git revert 命令的实际结果类似于 reset，但它的方法不同。reset 命令（默认）是在链中向后移动分支的指针去“撤销”更改，revert 命令是在链中添加一个新的提交去“取消”更改。再次查看图 1 可以非常轻松地看到这种影响。如果我们在链中的每个提交中向文件添加一行，一种方法是使用 reset 使那个提交返回到仅有两行的那个版本，如：git reset HEAD~1。

另一个方法是添加一个新的提交去删除第三行，以使最终结束变成两行的版本 —— 实际效果也是取消了那个更改。使用一个 git revert 命令可以实现上述目的，比如：

$ git revert HEAD

因为它添加了一个新的提交，Git 将提示如下的提交信息：

Revert "File with three lines"

This reverts commit b764644bad524b804577684bf74e7bca3117f554.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#       modified:   file1.txt
#

图 3（在下面）展示了 revert 操作完成后的结果。

如果我们现在运行一个 git log 命令，我们将看到前面的提交之前的一个新提交。

$ git log --oneline
11b7712 Revert "File with three lines"
b764644 File with three lines
7c709f0 File with two lines
9ef9173 File with one line

这里是工作目录中这个文件当前的内容：

$ cat <filename>
Line 1
Line 2

图 3 revert 操作之后

恢复或重置如何选择？

为什么要优先选择 revert 而不是 reset 操作？如果你已经将你的提交链推送到远程仓库（其它人可以已经拉取了你的代码并开始工作），一个 revert 操作是让他们去获得更改的非常友好的方式。这是因为 Git 工作流可以非常好地在分支的末端添加提交，但是当有人 reset 分支指针之后，一组提交将再也看不见了，这可能会是一个挑战。

当我们以这种方式使用 Git 工作时，我们的基本规则之一是：在你的本地仓库中使用这种方式去更改还没有推送的代码是可以的。如果提交已经推送到了远程仓库，并且可能其它人已经使用它来工作了，那么应该避免这些重写提交历史的更改。

总之，如果你想回滚、撤销或者重写其它人已经在使用的一个提交链的历史，当你的同事试图将他们的更改合并到他们拉取的原始链上时，他们可能需要做更多的工作。如果你必须对已经推送并被其他人正在使用的代码做更改，在你做更改之前必须要与他们沟通，让他们先合并他们的更改。然后在这个侵入操作没有需要合并的内容之后，他们再拉取最新的副本。

你可能注意到了，在我们做了 reset 操作之后，原始的提交链仍然在那个位置。我们移动了指针，然后 reset 代码回到前一个提交，但它并没有删除任何提交。换句话说就是，只要我们知道我们所指向的原始提交，我们能够通过简单的返回到分支的原始链的头部来“恢复”指针到前面的位置：

git reset <sha1 of commit>

当提交被替换之后，我们在 Git 中做的大量其它操作也会发生类似的事情。新提交被创建，有关的指针被移动到一个新的链，但是老的提交链仍然存在。

变基

现在我们来看一个分支变基。假设我们有两个分支：master 和 feature，提交链如下图 4 所示。master 的提交链是 C4->C2->C1->C0 和 feature 的提交链是 C5->C3->C2->C1->C0。

图 4：master 和 feature 分支的提交链

如果我们在分支中看它的提交记录，它们看起来应该像下面的这样。（为了易于理解，C 表示提交信息）

$ git log --oneline master
6a92e7a C4
259bf36 C2
f33ae68 C1
5043e79 C0

$ git log --oneline feature
79768b8 C5
000f9ae C3
259bf36 C2
f33ae68 C1
5043e79 C0

我告诉人们在 Git 中，可以将 rebase 认为是 “将历史合并”。从本质上来说，Git 将一个分支中的每个不同提交尝试“重放”到另一个分支中。

因此，我们使用基本的 Git 命令，可以变基一个 feature 分支进入到 master 中，并将它拼入到 C4 中（比如，将它插入到 feature 的链中）。操作命令如下：

$ git checkout feature
$ git rebase master

First, rewinding head to replay your work on top of it...
Applying: C3
Applying: C5

完成以后，我们的提交链将变成如下图 5 的样子。

图 5：rebase 命令完成后的提交链

接着，我们看一下提交历史，它应该变成如下的样子。

$ git log --oneline master
6a92e7a C4
259bf36 C2
f33ae68 C1
5043e79 C0

$ git log --oneline feature
c4533a5 C5
64f2047 C3
6a92e7a C4
259bf36 C2
f33ae68 C1
5043e79 C0

注意那个 C3' 和 C5'— 在 master 分支上已处于提交链的“顶部”，由于产生了更改而创建了新提交。但是也要注意的是，rebase 后“原始的” C3 和 C5 仍然在那里 — 只是再没有一个分支指向它们而已。

如果我们做了这个变基，然后确定这不是我们想要的结果，希望去撤销它，我们可以做下面示例所做的操作：

$ git reset 79768b8

由于这个简单的变更，现在我们的分支将重新指向到做 rebase 操作之前一模一样的位置 —— 完全等效于撤销操作（图 6）。

图 6：撤销 rebase 操作之后

如果你想不起来之前一个操作指向的一个分支上提交了什么内容怎么办？幸运的是，Git 命令依然可以帮助你。用这种方式可以修改大多数操作的指针，Git 会记住你的原始提交。事实上，它是在 .git 仓库目录下，将它保存为一个特定的名为 ORIG_HEAD 的文件中。在它被修改之前，那个路径是一个包含了大多数最新引用的文件。如果我们 cat 这个文件，我们可以看到它的内容。

$ cat .git/ORIG_HEAD
79768b891f47ce06f13456a7e222536ee47ad2fe

我们可以使用 reset 命令，正如前面所述，它返回指向到原始的链。然后它的历史将是如下的这样：

$ git log --oneline feature
79768b8 C5
000f9ae C3
259bf36 C2
f33ae68 C1
5043e79 C0

在 reflog 中是获取这些信息的另外一个地方。reflog 是你本地仓库中相关切换或更改的详细描述清单。你可以使用 git reflog 命令去查看它的内容：

$ git reflog
79768b8 HEAD@{0}: reset: moving to 79768b
c4533a5 HEAD@{1}: rebase finished: returning to refs/heads/feature
c4533a5 HEAD@{2}: rebase: C5
64f2047 HEAD@{3}: rebase: C3
6a92e7a HEAD@{4}: rebase: checkout master
79768b8 HEAD@{5}: checkout: moving from feature to feature
79768b8 HEAD@{6}: commit: C5
000f9ae HEAD@{7}: checkout: moving from master to feature
6a92e7a HEAD@{8}: commit: C4
259bf36 HEAD@{9}: checkout: moving from feature to master
000f9ae HEAD@{10}: commit: C3
259bf36 HEAD@{11}: checkout: moving from master to feature
259bf36 HEAD@{12}: commit: C2
f33ae68 HEAD@{13}: commit: C1
5043e79 HEAD@{14}: commit (initial): C0

你可以使用日志中列出的、你看到的相关命名格式，去重置任何一个东西：

$ git reset HEAD@{1}

一旦你理解了当“修改”链的操作发生后，Git 是如何跟踪原始提交链的基本原理，那么在 Git 中做一些更改将不再是那么可怕的事。这就是强大的 Git 的核心能力之一：能够很快速、很容易地尝试任何事情，并且如果不成功就撤销它们。

via: https://opensource.com/article/18/6/git-reset-revert-rebase-commands

作者：Brent Laster 选题：lujun9972 译者：qhwdw 校对：wxy

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

设计 Web 程序时，安全性是一个主要问题。我不是在谈论 DDoS 保护、使用强密码或两步验证。我说的是对网络程序的最大威胁。它被称为 CSRF, 是 Cross Site Request Forgery （跨站请求伪造）的缩写。

什么是 CSRF？

首先，CSRF 是 Cross Site Request Forgery 的缩写。它通常发音为 “sea-surf”，也经常被称为 XSRF。CSRF 是一种攻击类型，在受害者不知情的情况下，在受害者登录的 Web 程序上执行各种操作。这些行为可以是任何事情，从简单地点赞或评论社交媒体帖子到向人们发送垃圾消息，甚至从受害者的银行账户转移资金。

CSRF 如何工作？

CSRF 攻击尝试利用所有浏览器上的一个简单的常见漏洞。每次我们对网站进行身份验证或登录时，会话 cookie 都会存储在浏览器中。因此，每当我们向网站提出请求时，这些 cookie 就会自动发送到服务器，服务器通过匹配与服务器记录一起发送的 cookie 来识别我们。这样就知道是我们了。

这意味着我将在知情或不知情的情况下发出请求。由于 cookie 也被发送并且它们将匹配服务器上的记录，服务器认为我在发出该请求。 ​ CSRF 攻击通常以链接的形式出现。我们可以在其他网站上点击它们或通过电子邮件接收它们。单击这些链接时，会向服务器发出不需要的请求。正如我之前所说，服务器认为我们发出了请求并对其进行了身份验证。

一个真实世界的例子

为了把事情看得更深入，想象一下你已登录银行的网站。并在 yourbank.com/transfer 上填写表格。你将接收者的帐号填写为 1234，填入金额 5,000 并单击提交按钮。现在，我们将有一个 yourbank.com/transfer/send?to=1234&amount=5000 的请求。因此服务器将根据请求进行操作并转账。现在想象一下你在另一个网站上，然后点击一个链接，用黑客的帐号作为参数打开上面的 URL。这笔钱现在会转账给黑客，服务器认为你做了交易。即使你没有。

CSRF 防护

CSRF 防护非常容易实现。它通常将一个称为 CSRF 令牌的令牌发送到网页。每次发出新请求时，都会发送并验证此令牌。因此，向服务器发出的恶意请求将通过 cookie 身份验证，但 CSRF 验证会失败。大多数 Web 框架为防止 CSRF 攻击提供了开箱即用的支持，而 CSRF 攻击现在并不像以前那样常见。

总结

CSRF 攻击在 10 年前是一件大事，但如今我们看不到太多。过去，Youtube、纽约时报和 Netflix 等知名网站都容易受到 CSRF 的攻击。然而，CSRF 攻击的普遍性和发生率最近有减少。尽管如此，CSRF 攻击仍然是一种威胁，重要的是，你要保护自己的网站或程序免受攻击。

via: http://www.linuxandubuntu.com/home/understanding-csrf-cross-site-request-forgery

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

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

经过这些年，比特币社区已经发生了非常大的变化；社区成员从闭着眼睛都能讲解 梅克尔树 的技术迷们，变成了被一夜爆富欲望驱使的投机者和由一些连什么是梅克尔树都不懂的人所领导的企图寻求 10 亿美元估值的区块链初创公司。随着时间的流逝，围绕比特币和其它加密货币形成了一股热潮，他们认为比特币和其它加密货币远比实际的更重要；他们相信常见的货币（法定货币）正在成为过去，而加密货币将从根本上改变世界经济。

每一年他们的队伍都在壮大，而他们对加密货币的看法也在变得更加宏伟，那怕是对该技术的新奇的用法而使它陷入了困境。虽然我坚信设计优良的加密货币可以使金钱的跨境流动更容易，并且在大规模通胀的领域提供一个更稳定的选择，但现实情况是，我们并没有做到这些。实际上，正是价值的巨大不稳定性才使得投机者赚钱。那些宣扬美元和欧元即将死去的人，已经完全抛弃了对现实世界客观公正的看法。

一点点背景 …

比特币发行那天，我读了它的白皮书 —— 它使用有趣的 梅克尔树 去创建一个公共账簿和一个非常合理的共识协议 —— 由于它新颖的特性引起了密码学领域中许多人的注意。在白皮书发布后的几年里，比特币变得非常有价值，并由此吸引了许多人将它视为是一种投资，和那些认为它将改变一切的忠实追随者（和发声者）。这篇文章将讨论的正是后者。

昨天（2018/6/20），有人在推特上发布了一个最近的比特币区块的哈希，下面成千上万的推文和其它讨论让我相信，比特币已经跨越界线进入了真正的邪教领域。

一切都源于 Mark Wilcox 的这个推文：

#00000000000000000021e800c1e8df51b22c1588e5a624bea17e9faa34b2dc4a

— Mark Wilcox (@mwilcox) June 19, 2018

张贴的这个值是 比特币 #528249 号区块 的哈希值。前导零是挖矿过程的结果；挖掘一个区块就是把区块内容与一个 现时数 nonce （和其它数据）组合起来，然后做哈希运算，并且它至少有一定数量的前导零才能被验证为有效区块。如果它不是正确的数字，你可以更换现时数再试。重复这个过程直到哈希值的前导零数量是正确的数字之后，你就有了一个有效的区块。让人们感到很兴奋的部分是接下来的 21e800。

一些人说这是一个有意义的编号，挖掘出这个区块的人实际上的难度远远超出当前所看到的，不仅要调整前导零的数量，还要匹配接下来的 24 位 —— 它要求非常强大的计算能力。如果有人能够以蛮力去实现它，这将表明有些事情很严重，比如，在计算或密码学方面的重大突破。

你一定会有疑问，为什么 21e800 如此重要 —— 一个你问了肯定会后悔的问题。有人说它是参考了 E8 理论（一个广受批评的提出标准场理论的论文），或是表示总共存在 2,100,000,000 枚比特币（21 x 10^8 就是 2,100,000,000）。还有其它说法，因为太疯狂了而没有办法写出来。另一个重要的事实是，在前导零后面有 21e8 的区块平均每年被挖掘出一次 —— 这些从来没有人认为是很重要的。

这就引出了有趣的地方：关于这是如何发生的理论。

• 一台量子计算机，它能以某种方式用不可思议的速度做哈希运算。尽管在量子计算机的理论中还没有迹象表明它能够做这件事。哈希是量子计算机认为安全的东西之一。
• 时间旅行。是的，真的有人这么说，有人从未来穿梭回到现在去挖掘这个区块。我认为这种说法太荒谬了，都懒得去解释它为什么是错误的。
• 中本聪回来了。尽管事实上他的私钥没有任何活动，一些人从理论上认为他回来了，他能做一些没人能做的事情。这些理论是无法解释他如何做到的。

因此，总的来说（按我的理解）中本聪，为了知道和计算他做的事情，根据现代科学，他可能是以下之一：

A) 使用了一台量子计算机 B) 来自未来 C) 两者都是

— Crypto Randy Marsh REKT June 21, 2018

如果你觉得所有的这一切听起来像 命理学 numerology ，不止你一个人是这样想的。

所有围绕有特殊意义的区块哈希的讨论，也引发了对在某种程度上比较有趣的东西的讨论。比特币的创世区块，它是第一个比特币区块，有一个不寻常的属性：早期的比特币要求哈希值的前 32 位 bit 是零；而创始区块的前导零有 43 位。因为产生创世区块的代码从未发布过，不知道它是如何产生的，也不知道是用什么类型的硬件产生的。中本聪有学术背景，因此可能他有比那个时候大学中常见设备更强大的计算能力。从这一点上说，只是对古怪的创世区块的历史有点好奇，仅此而已。

关于哈希运算的简单题外话

这种喧嚣始于比特币区块的哈希运算；因此理解哈希是什么很重要，并且要理解一个非常重要的属性，哈希是单向加密函数，它能够基于给定的数据创建一个伪随机输出。

这意味着什么呢？基于本文讨论的目的，对于每个给定的输入你将得到一个随机的输出。随机数有时看起来很有趣，很简单，因为它是随机的结果，并且人类大脑可以很容易从任何东西中找到顺序。当你从随机数据中开始查看顺序时，你就会发现有趣的事情 —— 这些东西毫无意义，因为它们只是简单地随机数。当人们把重要的意义归属到随机数据上时，它将告诉你很多这些参与者观念相关的东西，而不是数据本身。

币之邪教

首先，我们来定义一组术语：

• 邪教 Cult ：一个宗教崇拜和直接向一个特定的人或物虔诚的体系。
• 宗教 Religion ：有人认为是至高无上的追求或兴趣。

币之邪教 Cult of the Coin 有许多圣人，或许没有人比 中本聪 Satoshi Nakamoto 更伟大，他是比特币创始者（们）的假名。（对他的）狂热拥戴，要归因于他的能力和理解力远超过一般的研究人员，认为他的远见卓视无人能比，他影响了世界新经济的秩序。当将中本聪的神秘本质和未知的真实身份结合起来时，狂热的追随着们将中本聪视为一个真正值得尊敬的人物。

当然，除了追随其他圣人的追捧者之外，毫无疑问这些追捧者认为自己是正确的。任何对他们的圣人的批评都被认为也是对他们的批评。例如，那些追捧 EOS 的人，可能会视中本聪为一个开发了失败项目的黑客，而对 EOS 那怕是最轻微的批评，他们也会作出激烈的反应，之所以反应如此强烈，仅仅是因为攻击了他们心目中的神。那些追捧 IOTA 的人的反应也一样；还有更多这样的例子。

这些追随者在讨论问题时已经失去了理性和客观，他们的狂热遮盖了他们的视野。任何对这些项目和项目背后的人的讨论，如果不是溢美之词，必然以某种程序的刻薄言辞结束，对于一个技术的讨论那种做法是毫无道理的。

这很危险，原因很多：

• 开发者 & 研究者对缺陷视而不见。由于追捧者的大量赞美，这些参与开发的人对自己的能力的看法开始膨胀，并将一些批评看作是无端的攻击 —— 因为他们认为自己是不可能错的。
• 真正的问题是被攻击。技术问题不再被看作是需要去解决的问题和改进的机会，他们认为是来自那些想去破坏项目的人的攻击。
• 物以类聚，人以币分。追随者们通常会结盟到一起，而圣人仅有一个。承认其它项目的优越，意味着认同自己项目的缺陷或不足，而这是他们不愿意做的事情。
• 阻止真实的进步。进化是很残酷的，死亡是必然会有的，项目可能失败，也要承认这些失败的原因。如果忽视失败的教训，如果不允许那些应该去死亡的事情发生，进步就会停止。

许多围绕加密货币和相关区块链项目的讨论已经开始变得越来越”有毒“，善意的人想在不受攻击的情况下进行技术性讨论越来越不可能。随着对真正缺陷的讨论，那些在其它环境中注定要失败的缺陷，在没有做任何的事实分析的情况下即刻被判定为异端已经成为了惯例，善意的人参与其中的代价变得极其昂贵。至少有些人已经意识到极其严重的安全漏洞，由于高“毒性”的环境，他们选择保持沉默。

曾经被好奇、学习和改进的期望、创意可行性所驱动的东西，现在被盲目的贪婪、宗教般的狂热、自以为是和自我膨胀所驱动。

我对受这种狂热激励的项目的未来不抱太多的希望，而它持续地传播，可能会损害多年来在这个领域中真正的研究者。这些技术项目中，一些项目成功了，一些项目失败了 —— 这就是技术演进的方式。设计这些系统的人，就和你我一样都有缺点，同样这些项目也有缺陷。有些项目非常适合某些使用场景而不适合其它场景，有些项目不适合任何使用场景，没有一个项目适合所有使用场景。关于这些项目的讨论应该关注于技术方面，这样做是为了让这一研究领域得以发展；在这些项目中掺杂宗教般狂热必将损害所有人。

[注意：这种行为有许多例子可以引用，但是为了保护那些因批评项目而成为被攻击目标的人，我选择尽可能少的列出这种例子。我看到许多我很尊敬的人、许多我认为是朋友的人成为这种恶毒攻击的受害者 —— 我不想引起人们对这些攻击的注意和重新引起对他们的攻击。]

（题图：news.bitcoin.com）

关于作者：

我是一个资深应用安全顾问、研究员和具有超过 15 年的经验的软件开发者。我主要关注的是应用程序安全、安全通信和加密, 虽然我经常由于无聊而去研究新的领域。我通常会写了一些关于我的研究和安全、开发和软件设计，和我当前吸引了我注意力的爱好的文章。

via: https://adamcaudill.com/2018/06/21/bitcoin-is-a-cult/

作者：Adam Caudill 选题：lujun9972 译者：qhwdw 校对：wxy

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

Fio（Flexible I/O Tester） 是一款由 Jens Axboe 开发的用于测评和压力/硬件验证的自由开源的软件。

它支持 19 种不同类型的 I/O 引擎 (sync、mmap、libaio、posixaio、SG v3、splice、null、network、 syslet、guasi、solarisaio，以及更多)， I/O 优先级（针对较新的 Linux 内核），I/O 速度，fork 的任务或线程任务等等。它能够在块设备和文件上工作。

Fio 接受一种非常简单易于理解的文本格式的任务描述。软件默认包含了几个示例任务文件。 Fio 展示了所有类型的 I/O 性能信息，包括完整的 IO 延迟和百分比。

它被广泛的应用在非常多的地方，包括测评、QA，以及验证用途。它支持 Linux 、FreeBSD 、NetBSD、 OpenBSD、 OS X、 OpenSolaris、 AIX、 HP-UX、 Android 以及 Windows。

在这个教程，我们将使用 Ubuntu 16 ，你需要拥有这台电脑的 sudo 或 root 权限。我们将完整的进行安装和 Fio 的使用。

使用源码安装 Fio

我们要去克隆 GitHub 上的仓库。安装所需的依赖，然后我们将会从源码构建应用。首先，确保我们安装了 Git 。

sudo apt-get install git

CentOS 用户可以执行下述命令：

sudo yum install git

现在，我们切换到 /opt 目录，并从 Github 上克隆仓库：

cd /opt
git clone https://github.com/axboe/fio

你应该会看到下面这样的输出：

Cloning into 'fio'...
remote: Counting objects: 24819, done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 24819 (delta 39), reused 62 (delta 32), pack-reused 24743
Receiving objects: 100% (24819/24819), 16.07 MiB | 0 bytes/s, done.
Resolving deltas: 100% (16251/16251), done.
Checking connectivity... done.

现在，我们通过在 /opt 目录下输入下方的命令切换到 Fio 的代码目录：

cd fio

最后，我们可以使用下面的命令来使用 make 从源码构建软件：

# ./configure
# make
# make install

在 Ubuntu 上安装 Fio

对于 Ubuntu 和 Debian 来说， Fio 已经在主仓库内。你可以很容易的使用类似 yum 和 apt-get 的标准包管理器来安装 Fio。

对于 Ubuntu 和 Debian ，你只需要简单的执行下述命令：

sudo apt-get install fio

对于 CentOS/Redhat 你只需要简单执行下述命令。

在 CentOS ，你可能在你能安装 Fio 前需要去安装 EPEL 仓库到你的系统中。你可以通过执行下述命令来安装它：

sudo yum install epel-release -y

你可以执行下述命令来安装 Fio：

sudo yum install fio -y

使用 Fio 进行磁盘性能测试

现在 Fio 已经安装到了你的系统中。现在是时候看一些如何使用 Fio 的例子了。我们将进行随机写、读和读写测试。

执行随机写测试

执行下面的命令来开始。这个命令将要同一时间执行两个进程，写入共计 4GB（ 4 个任务 x 512MB = 2GB） 文件：

sudo fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=512M --numjobs=2 --runtime=240 --group_reporting

...
fio-2.2.10
Starting 2 processes

randwrite: (groupid=0, jobs=2): err= 0: pid=7271: Sat Aug 5 13:28:44 2017
 write: io=1024.0MB, bw=2485.5MB/s, iops=636271, runt= 412msec
 slat (usec): min=1, max=268, avg= 1.79, stdev= 1.01
 clat (usec): min=0, max=13, avg= 0.20, stdev= 0.40
 lat (usec): min=1, max=268, avg= 2.03, stdev= 1.01
 clat percentiles (usec):
 | 1.00th=[ 0], 5.00th=[ 0], 10.00th=[ 0], 20.00th=[ 0],
 | 30.00th=[ 0], 40.00th=[ 0], 50.00th=[ 0], 60.00th=[ 0],
 | 70.00th=[ 0], 80.00th=[ 1], 90.00th=[ 1], 95.00th=[ 1],
 | 99.00th=[ 1], 99.50th=[ 1], 99.90th=[ 1], 99.95th=[ 1],
 | 99.99th=[ 1]
 lat (usec) : 2=99.99%, 4=0.01%, 10=0.01%, 20=0.01%
 cpu : usr=15.14%, sys=84.00%, ctx=8, majf=0, minf=26
 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
 submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 issued : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
 latency : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
 WRITE: io=1024.0MB, aggrb=2485.5MB/s, minb=2485.5MB/s, maxb=2485.5MB/s, mint=412msec, maxt=412msec

Disk stats (read/write):
 sda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%

执行随机读测试

我们将要执行一个随机读测试，我们将会尝试读取一个随机的 2GB 文件。

sudo fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=0 --size=512M --numjobs=4 --runtime=240 --group_reporting

你应该会看到下面这样的输出：

...
fio-2.2.10
Starting 4 processes
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
Jobs: 4 (f=4): [r(4)] [100.0% done] [71800KB/0KB/0KB /s] [17.1K/0/0 iops] [eta 00m:00s]
randread: (groupid=0, jobs=4): err= 0: pid=7586: Sat Aug 5 13:30:52 2017
 read : io=2048.0MB, bw=80719KB/s, iops=20179, runt= 25981msec
 slat (usec): min=72, max=10008, avg=195.79, stdev=94.72
 clat (usec): min=2, max=28811, avg=2971.96, stdev=760.33
 lat (usec): min=185, max=29080, avg=3167.96, stdev=798.91
 clat percentiles (usec):
 | 1.00th=[ 2192], 5.00th=[ 2448], 10.00th=[ 2576], 20.00th=[ 2736],
 | 30.00th=[ 2800], 40.00th=[ 2832], 50.00th=[ 2928], 60.00th=[ 3024],
 | 70.00th=[ 3120], 80.00th=[ 3184], 90.00th=[ 3248], 95.00th=[ 3312],
 | 99.00th=[ 3536], 99.50th=[ 6304], 99.90th=[15168], 99.95th=[18816],
 | 99.99th=[22912]
 bw (KB /s): min=17360, max=25144, per=25.05%, avg=20216.90, stdev=1605.65
 lat (usec) : 4=0.01%, 10=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
 lat (usec) : 1000=0.01%
 lat (msec) : 2=0.01%, 4=99.27%, 10=0.44%, 20=0.24%, 50=0.04%
 cpu : usr=1.35%, sys=5.18%, ctx=524309, majf=0, minf=98
 IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
 submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
 issued : total=r=524288/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
 latency : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
 READ: io=2048.0MB, aggrb=80718KB/s, minb=80718KB/s, maxb=80718KB/s, mint=25981msec, maxt=25981msec

Disk stats (read/write):
 sda: ios=521587/871, merge=0/1142, ticks=96664/612, in_queue=97284, util=99.85%

最后，我们想要展示一个简单的随机读-写测试来看一看 Fio 返回的输出类型。

读写性能测试

下述命令将会测试 USB Pen 驱动器 (/dev/sdc1) 的随机读写性能：

sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

下面的内容是我们从上面的命令得到的输出：

fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [m(1)] [100.0% done] [217.8MB/74452KB/0KB /s] [55.8K/18.7K/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=8475: Sat Aug 5 13:36:04 2017
 read : io=3071.7MB, bw=219374KB/s, iops=54843, runt= 14338msec
 write: io=1024.4MB, bw=73156KB/s, iops=18289, runt= 14338msec
 cpu : usr=6.78%, sys=20.81%, ctx=1007218, majf=0, minf=9
 IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
 submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
 issued : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
 latency : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
 READ: io=3071.7MB, aggrb=219374KB/s, minb=219374KB/s, maxb=219374KB/s, mint=14338msec, maxt=14338msec
 WRITE: io=1024.4MB, aggrb=73156KB/s, minb=73156KB/s, maxb=73156KB/s, mint=14338msec, maxt=14338msec

Disk stats (read/write):
 sda: ios=774141/258944, merge=1463/899, ticks=748800/150316, in_queue=900720, util=99.35%

我们希望你能喜欢这个教程并且享受接下来的内容，Fio 是一个非常有用的工具，并且我们希望你能在你下一次 Debugging 活动中使用到它。如果你喜欢这个文章，欢迎留下评论和问题。

via: https://wpmojo.com/how-to-use-fio-to-measure-disk-performance-in-linux/

作者：Alex Pearson 译者：Bestony 校对：wxy

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

欧洲核子研究组织（简称 CERN）依靠开源技术处理大型强子对撞机生成的大量数据。ATLAS（超环面仪器，如图所示）是一种探测基本粒子的通用探测器。

CERN 无需过多介绍了吧。CERN 创建了 万维网 World Wide Web （WWW）和 大型强子对撞机 Large Hadron Collider （LHC），这是世界上最大的 粒子加速器 particle accelerator ，就是通过它发现了 希格斯玻色子 Higgs boson 。负责该组织 IT 操作系统和基础架构的 Tim Bell 表示，他的团队的目标是“为全球 13000 名物理学家提供计算设施，以分析这些碰撞，了解宇宙的构成以及是如何运转的。”

CERN 正在进行硬核科学研究，尤其是大型强子对撞机，它在运行时 生成大量数据。“CERN 目前存储大约 200 PB 的数据，当加速器运行时，每月有超过 10 PB 的数据产生。这必然会给计算基础架构带来极大的挑战，包括存储大量数据，以及能够在合理的时间范围内处理数据，对于网络、存储技术和高效计算架构都是很大的压力。“Bell 说到。

Tim Bell, CERN

大型强子对撞机的运作规模和它产生的数据量带来了严峻的挑战，但 CERN 对这些问题并不陌生。CERN 成立于 1954 年，已经 60 余年了。“我们一直面临着难以解决的计算能力挑战，但我们一直在与开源社区合作解决这些问题。”Bell 说，“即使在 90 年代，当我们发明万维网时，我们也希望与人们共享，使其能够从 CERN 的研究中受益，开源是做这件事的再合适不过的工具了。”

使用 OpenStack 和 CentOS

时至今日，CERN 是 OpenStack 的深度用户，而 Bell 则是 OpenStack 基金会的董事会成员之一。不过 CERN 比 OpenStack 出现的要早，多年来，他们一直在使用各种开源技术通过 Linux 服务器提供服务。

“在过去的十年中，我们发现，与其自己解决问题，不如找到面临类似挑战的上游开源社区进行合作，然后我们一同为这些项目做出贡献，而不是一切都由自己来创造和维护。“Bell 说。

一个很好的例子是 Linux 本身。CERN 曾经是 Red Hat Enterprise Linux 的客户。其实，早在 2004 年，他们就与 Fermilab 合作一起建立了自己的 Linux 发行版，名为 Scientific Linux。最终他们意识到，因为没有修改内核，耗费时间建立自己的发行版是没有意义的，所以他们迁移到了 CentOS 上。由于 CentOS 是一个完全开源和社区驱使的项目，CERN 可以与该项目合作，并为 CentOS 的构建和分发做出贡献。

CERN 帮助 CentOS 提供基础架构，他们还组织了 CentOS DoJo 活动（LCTT 译者注：CentOS Dojo 是为期一日的活动，汇聚来自 CentOS 社群的人分享系统管理、最佳实践及新兴科技。），工程师可以汇聚在此共同改进 CentOS 的封装。

除了 OpenStack 和 CentOS 之外，CERN 还是其他开源项目的深度用户，包括用于配置管理的 Puppet、用于监控的 Grafana 和 InfluxDB，等等。

“我们与全球约 170 个实验室合作。因此，每当我们发现一个开源项目的改进之处，其他实验室便可以很容易地采纳使用。”Bell 说，“与此同时，我们也向其他项目学习。当像 eBay 和 Rackspace 这样大规模的装机量提高了解决方案的可扩展性时，我们也从中受益，也可以扩大规模。“

解决现实问题

2012 年左右，CERN 正在研究如何为大型强子对撞机扩展计算能力，但难点是人员而不是技术。CERN 雇用的员工人数是固定的。“我们必须找到一种方法来扩展计算能力，而不需要大量额外的人来管理。”Bell 说，“OpenStack 为我们提供了一个自动的 API 驱动和软件定义的基础架构。”OpenStack 还帮助 CERN 检查与服务交付相关的问题，然后使其自动化，而无需增加员工。

“我们目前在日内瓦和布达佩斯的两个数据中心运行大约 280000 个处理器核心和 7000 台服务器。我们正在使用软件定义的基础架构使一切自动化，这使我们能够在保持员工数量不变的同时继续添加更多的服务器。“Bell 说。

随着时间的推移，CERN 将面临更大的挑战。大型强子对撞机有一个到 2035 年的蓝图，包括一些重要的升级。“我们的加速器运转三到四年，然后会用 18 个月或两年的时间来升级基础架构。在这维护期间我们会做一些计算能力的规划。 ”Bell 说。CERN 还计划升级高亮度大型强子对撞机，会允许更高光度的光束。与目前的 CERN 的规模相比，升级意味着计算需求需增加约 60 倍。

“根据摩尔定律，我们可能只能满足需求的四分之一，因此我们必须找到相应的扩展计算能力和存储基础架构的方法，并找到自动化和解决方案，例如 OpenStack，将有助于此。”Bell 说。

“当我们开始使用大型强子对撞机并观察我们如何提供计算能力时，很明显我们无法将所有内容都放入 CERN 的数据中心，因此我们设计了一个分布式网格结构：位于中心的 CERN 和围绕着它的级联结构。”Bell 说，“全世界约有 12 个大型一级数据中心，然后是 150 所小型大学和实验室。他们从大型强子对撞机的数据中收集样本，以帮助物理学家理解和分析数据。”

这种结构意味着 CERN 正在进行国际合作，数百个国家正致力于分析这些数据。归结为一个基本原则，即开源不仅仅是共享代码，还包括人们之间的协作、知识共享，以实现个人、组织或公司无法单独实现的目标。这就是开源世界的希格斯玻色子。

via: https://www.linux.com/blog/2018/5/how-cern-using-linux-open-source

作者：SWAPNIL BHARTIYA 译者：jessie-pang 校对：wxy

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