# 在 Linux 中如何使用 iotop 和 iostat 监控磁盘 I/O 活动？

你知道在 Linux 中我们使用什么工具检修和监控实时的磁盘活动吗？如果 [Linux 系统性能](https://www.2daygeek.com/category/monitoring-tools/)变慢，我们会用 [top 命令](https://www.2daygeek.com/linux-top-command-linux-system-performance-monitoring-tool/) 来查看系统性能。它被用来检查是什么进程在服务器上占有如此高的使用率，对于大多数 Linux 系统管理员来说很常见，现实世界中被 Linux 系统管理员广泛采用。

如果在进程输出中你没有看到很大的不同，你仍然有选择查看其他东西。我会建议你在 `top` 输出中检查 `wa` 状态，因为大多数时间里服务器性能由于在硬盘上的高 I/O 读和写降低了性能。如果它很高或者波动，很可能就是它造成的。因此，我们需要检查硬盘上的 I/O 活动。

我们可以在 Linux 中使用 `iotop` 和 `iostat` 命令监控所有的磁盘和文件系统的磁盘 I/O 统计。

### 什么是 iotop？

`iotop` 是一个类似 `top` 的工具，用来显示实时的磁盘活动。

`iotop` 监控 Linux 内核输出的 I/O 使用信息，并且显示一个系统中进程或线程的当前 I/O 使用情况。

它显示每个进程/线程读写 I/O 带宽。它同样显示当等待换入和等待 I/O 的线程/进程花费的时间的百分比。

`Total DISK READ` 和 `Total DISK WRITE` 的值一方面表示了进程和内核线程之间的总的读写带宽，另一方面也表示内核块设备子系统的。

`Actual DISK READ` 和 `Actual DISK WRITE` 的值表示在内核块设备子系统和下面硬件（HDD、SSD 等等）对应的实际磁盘 I/O 带宽。

### 如何在 Linux 中安装 iotop ？

我们可以轻松在包管理器的帮助下安装，因为该软件包在所有的 Linux 发行版仓库中都可以获得。

对于 Fedora 系统，使用 [DNF 命令](https://www.2daygeek.com/dnf-command-examples-manage-packages-fedora-system/) 来安装 `iotop`。

```
$ sudo dnf install iotop
```

对于 Debian/Ubuntu 系统，使用 [API-GET 命令](https://www.2daygeek.com/apt-get-apt-cache-command-examples-manage-packages-debian-ubuntu-systems/) 或者 [APT 命令](https://www.2daygeek.com/apt-command-examples-manage-packages-debian-ubuntu-systems/) 来安装 `iotop`。

```
$ sudo apt install iotop
```

对于基于 Arch Linux 的系统，使用 [Pacman Command](https://www.2daygeek.com/pacman-command-examples-manage-packages-arch-linux-system/) 来安装 `iotop`。

```
$ sudo pacman -S iotop
```

对于 RHEL/CentOS 的系统，使用 [YUM Command](https://www.2daygeek.com/yum-command-examples-manage-packages-rhel-centos-systems/) 来安装 `iotop`。

```
$ sudo yum install iotop
```

对于使用 openSUSE Leap 的系统，使用 [Zypper Command](https://www.2daygeek.com/zypper-command-examples-manage-packages-opensuse-system/) 来安装 `iotop`。

```
$ sudo zypper install iotop
```

### 在 Linux 中如何使用 iotop 命令来监控磁盘 I/O 活动/统计？

`iotop` 命令有很多参数来检查关于磁盘 I/O 的变化：

```
# iotop
```

如果你想检查那个进程实际在做 I/O，那么运行 `iotop` 命令加上 `-o` 或者 `--only` 参数。

```
# iotop --only
```

细节：

* `IO`：它显示每个进程的 I/O 利用率，包含磁盘和交换。
* `SWAPIN`： 它只显示每个进程的交换使用率。

### 什么是 iostat？

`iostat` 被用来报告中央处理单元（CPU）的统计和设备与分区的输出/输出的统计。

`iostat` 命令通过观察与它们平均传输率相关的设备活跃时间来监控系统输入/输出设备负载。

`iostat` 命令生成的报告可以被用来改变系统配置来更好的平衡物理磁盘之间的输入/输出负载。

所有的统计都在 `iostat` 命令每次运行时被报告。该报告包含一个 CPU 头部，后面是一行 CPU 统计。

在多处理器系统中，CPU 统计被计算为系统层面的所有处理器的平均值。设备头行后紧跟显示每个配置的设备一行的统计。

`iostat` 命令生成两种类型的报告，CPU 利用率报告和设备利用率报告。

### 在 Linux 中怎样安装 iostat？

`iostat` 工具是 `sysstat` 包的一部分，所以我们可以轻松地在包管理器地帮助下安装，因为在所有的 Linux 发行版的仓库都是可以获得的。

对于 Fedora 系统，使用 [DNF Command](https://www.2daygeek.com/dnf-command-examples-manage-packages-fedora-system/) 来安装 `sysstat`。

```
$ sudo dnf install sysstat
```

对于 Debian/Ubuntu 系统，使用 [APT-GET Command](https://www.2daygeek.com/apt-get-apt-cache-command-examples-manage-packages-debian-ubuntu-systems/) 或者 [APT Command](https://www.2daygeek.com/apt-command-examples-manage-packages-debian-ubuntu-systems/) 来安装 `sysstat`。

```
$ sudo apt install sysstat
```

对于基于 Arch Linux 的系统，使用 [Pacman Command](https://www.2daygeek.com/pacman-command-examples-manage-packages-arch-linux-system/) 来安装 `sysstat`。

```
$ sudo pacman -S sysstat
```

对于 RHEL/CentOS 系统，使用 [YUM Command](https://www.2daygeek.com/yum-command-examples-manage-packages-rhel-centos-systems/) 来安装 `sysstat`。

```
$ sudo yum install sysstat
```

对于 openSUSE Leap 系统，使用 [Zypper Command](https://www.2daygeek.com/zypper-command-examples-manage-packages-opensuse-system/) 来安装 `sysstat`。

```
$ sudo zypper install sysstat
```

### 在 Linux 中如何使用 sysstat 命令监控磁盘 I/O 活动/统计？

在 `iostat` 命令中有很多参数来检查关于 I/O 和 CPU 的变化统计信息。

不加参数运行 `iostat` 命令会看到完整的系统统计。

```
# iostat

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.45    0.02   16.47    0.12    0.00   53.94

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1           6.68       126.95       124.97         0.00   58420014   57507206          0
sda               0.18         6.77        80.24         0.00    3115036   36924764          0
loop0             0.00         0.00         0.00         0.00       2160          0          0
loop1             0.00         0.00         0.00         0.00       1093          0          0
loop2             0.00         0.00         0.00         0.00       1077          0          0
```

运行 `iostat` 命令加上 `-d` 参数查看所有设备的 I/O 统计。

```
# iostat -d

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1           6.68       126.95       124.97         0.00   58420030   57509090          0
sda               0.18         6.77        80.24         0.00    3115292   36924764          0
loop0             0.00         0.00         0.00         0.00       2160          0          0
loop1             0.00         0.00         0.00         0.00       1093          0          0
loop2             0.00         0.00         0.00         0.00       1077          0          0
```

运行 `iostat` 命令加上 `-p` 参数查看所有的设备和分区的 I/O 统计。

```
# iostat -p

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.42    0.02   16.45    0.12    0.00   53.99

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1           6.68       126.94       124.96         0.00   58420062   57512278          0
nvme0n1p1         6.40       124.46       118.36         0.00   57279753   54474898          0
nvme0n1p2         0.27         2.47         6.60         0.00    1138069    3037380          0
sda               0.18         6.77        80.23         0.00    3116060   36924764          0
sda1              0.00         0.01         0.00         0.00       3224          0          0
sda2              0.18         6.76        80.23         0.00    3111508   36924764          0
loop0             0.00         0.00         0.00         0.00       2160          0          0
loop1             0.00         0.00         0.00         0.00       1093          0          0
loop2             0.00         0.00         0.00         0.00       1077          0          0
```

运行 `iostat` 命令加上 `-x` 参数显示所有设备的详细的 I/O 统计信息。

```
# iostat -x

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.41    0.02   16.45    0.12    0.00   54.00

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz  aqu-sz  %util
nvme0n1          2.45    126.93     0.60  19.74    0.40    51.74    4.23    124.96     5.12  54.76    3.16    29.54    0.00      0.00     0.00   0.00    0.00     0.00    0.31  30.28
sda              0.06      6.77     0.00   0.00    8.34   119.20    0.12     80.23    19.94  99.40   31.84   670.73    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.13
loop0            0.00      0.00     0.00   0.00    0.08    19.64    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.00
loop1            0.00      0.00     0.00   0.00    0.40    12.86    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.00
loop2            0.00      0.00     0.00   0.00    0.38    19.58    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.00
```

运行 `iostat` 命令加上 `-d [设备名]` 参数查看具体设备和它的分区的 I/O 统计信息。

```
# iostat -p [Device_Name]

# iostat -p sda

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.38    0.02   16.43    0.12    0.00   54.05

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
sda               0.18         6.77        80.21         0.00    3117468   36924764          0
sda2              0.18         6.76        80.21         0.00    3112916   36924764          0
sda1              0.00         0.01         0.00         0.00       3224          0          0
```

运行 `iostat` 命令加上 `-m` 参数以 MB 为单位而不是 KB 查看所有设备的统计。默认以 KB 显示输出。

```
# iostat -m

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.36    0.02   16.41    0.12    0.00   54.09

Device             tps    MB_read/s    MB_wrtn/s    MB_dscd/s    MB_read    MB_wrtn    MB_dscd
nvme0n1           6.68         0.12         0.12         0.00      57050      56176          0
sda               0.18         0.01         0.08         0.00       3045      36059          0
loop0             0.00         0.00         0.00         0.00          2          0          0
loop1             0.00         0.00         0.00         0.00          1          0          0
loop2             0.00         0.00         0.00         0.00          1          0          0
```

运行 `iostat` 命令使用特定的间隔使用如下的格式。在这个例子中，我们打算以 5 秒捕获的间隔捕获两个报告。

```
# iostat [Interval] [Number Of Reports]

# iostat 5 2

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.35    0.02   16.41    0.12    0.00   54.10

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1           6.68       126.89       124.95         0.00   58420116   57525344          0
sda               0.18         6.77        80.20         0.00    3118492   36924764          0
loop0             0.00         0.00         0.00         0.00       2160          0          0
loop1             0.00         0.00         0.00         0.00       1093          0          0
loop2             0.00         0.00         0.00         0.00       1077          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.71    0.00    2.51    0.05    0.00   93.73

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1          19.00         0.20       311.40         0.00          1       1557          0
sda               0.20        25.60         0.00         0.00        128          0          0
loop0             0.00         0.00         0.00         0.00          0          0          0
loop1             0.00         0.00         0.00         0.00          0          0          0
loop2             0.00         0.00         0.00         0.00          0          0          0
```

运行 `iostat` 命令与 `-N` 参数来查看 LVM 磁盘 I/O 统计报告。

```
# iostat -N

Linux 4.15.0-47-generic (Ubuntu18.2daygeek.com)     Thursday 18 April 2019  _x86_64_    (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.38    0.07    0.18    0.26    0.00   99.12

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               3.60        57.07        69.06     968729    1172340
sdb               0.02         0.33         0.00       5680          0
sdc               0.01         0.12         0.00       2108          0
2g-2gvol1         0.00         0.07         0.00       1204          0
```

运行 `nfsiostat` 命令来查看 Network File System（NFS）的 I/O 统计。

```
# nfsiostat
```

---

via: <https://www.2daygeek.com/check-monitor-disk-io-in-linux-using-iotop-iostat-command/>

作者：[Magesh Maruthamuthu](https://www.2daygeek.com/author/magesh/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[warmfrog](https://github.com/warmfrog) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


关于 /dev/urandom 的流言终结

Summary: 有很多关于 /dev/urandom 和 /dev/random 的流言在坊间不断流传。然而流言终究是流言。

# 关于 /dev/urandom 的流言终结

有很多关于 `/dev/urandom` 和 `/dev/random` 的流言在坊间不断流传。然而流言终究是流言。

>
> 本篇文章里针对的都是近来的 Linux 操作系统，其它类 Unix 操作系统不在讨论范围内。
>
>
>

**`/dev/urandom` 不安全。加密用途必须使用 `/dev/random`**

*事实*：`/dev/urandom` 才是类 Unix 操作系统下推荐的加密种子。

**`/dev/urandom` 是<ruby> 伪随机数生成器 <rt>  pseudo random number generator </rt></ruby>（PRND），而 `/dev/random` 是“真”随机数生成器。**

*事实*：它们两者本质上用的是同一种 CSPRNG （一种密码学伪随机数生成器）。它们之间细微的差别和“真”“不真”随机完全无关。（参见：“Linux 随机数生成器的构架”一节）

**`/dev/random` 在任何情况下都是密码学应用更好地选择。即便 `/dev/urandom` 也同样安全，我们还是不应该用它。**

*事实*：`/dev/random` 有个很恶心人的问题：它是阻塞的。（参见：“阻塞有什么问题？”一节）（LCTT 译注：意味着请求都得逐个执行，等待前一个请求完成）

**但阻塞不是好事吗！`/dev/random` 只会给出电脑收集的信息熵足以支持的随机量。`/dev/urandom` 在用完了所有熵的情况下还会不断吐出不安全的随机数给你。**

*事实*：这是误解。就算我们不去考虑应用层面后续对随机种子的用法，“用完信息熵池”这个概念本身就不存在。仅仅 256 位的熵就足以生成计算上安全的随机数很长、很长的一段时间了。（参见：“那熵池快空了的情况呢？”一节）

问题的关键还在后头：`/dev/random` 怎么知道有系统会*多少*可用的信息熵？接着看！

**但密码学家老是讨论重新选种子（re-seeding）。这难道不和上一条冲突吗？**

*事实*：你说的也没错！某种程度上吧。确实，随机数生成器一直在使用系统信息熵的状态重新选种。但这么做（一部分）是因为别的原因。（参见：“重新选种”一节）

这样说吧，我没有说引入新的信息熵是坏的。更多的熵肯定更好。我只是说在熵池低的时候阻塞是没必要的。

**好，就算你说的都对，但是 `/dev/(u)random` 的 man 页面和你说的也不一样啊！到底有没有专家同意你说的这堆啊？**

*事实*：其实 man 页面和我说的不冲突。它看似好像在说 `/dev/urandom` 对密码学用途来说不安全，但如果你真的理解这堆密码学术语你就知道它说的并不是这个意思。（参见：“random 和 urandom 的 man 页面”一节）

man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也没问题，但绝对不是说必要的），但它也推荐在大多数“一般”的密码学应用下使用 `/dev/urandom` 。

虽然诉诸权威一般来说不是好事，但在密码学这么严肃的事情上，和专家统一意见是很有必要的。

所以说呢，还确实有一些*专家*和我的一件事一致的：`/dev/urandom` 就应该是类 UNIX 操作系统下密码学应用的首选。显然的，是他们的观点说服了我而不是反过来的。（参见：“正道”一节）

---

难以相信吗？觉得我肯定错了？读下去看我能不能说服你。

我尝试不讲太高深的东西，但是有两点内容必须先提一下才能让我们接着论证观点。

首当其冲的，*什么是随机性*，或者更准确地：我们在探讨什么样的随机性？（参见：“真随机”一节）

另外一点很重要的是，我*没有尝试以说教的态度*对你们写这段话。我写这篇文章是为了日后可以在讨论起的时候指给别人看。比 140 字长（LCTT 译注：推特长度）。这样我就不用一遍遍重复我的观点了。能把论点磨炼成一篇文章本身就很有助于将来的讨论。（参见：“你是在说我笨？！”一节）

并且我非常乐意听到不一样的观点。但我只是认为单单地说 `/dev/urandom` 坏是不够的。你得能指出到底有什么问题，并且剖析它们。

### 你是在说我笨？！

绝对没有！

事实上我自己也相信了 “`/dev/urandom` 是不安全的” 好些年。这几乎不是我们的错，因为那么德高望重的人在 Usenet、论坛、推特上跟我们重复这个观点。甚至*连 man 手册*都似是而非地说着。我们当年怎么可能鄙视诸如“信息熵太低了”这种看上去就很让人信服的观点呢？（参见：“random 和 urandom 的 man 页面”一节）

整个流言之所以如此广为流传不是因为人们太蠢，而是因为但凡有点关于信息熵和密码学概念的人都会觉得这个说法很有道理。直觉似乎都在告诉我们这流言讲的很有道理。很不幸直觉在密码学里通常不管用，这次也一样。

### 真随机

随机数是“真正随机”是什么意思？

我不想搞的太复杂以至于变成哲学范畴的东西。这种讨论很容易走偏因为对于随机模型大家见仁见智，讨论很快变得毫无意义。

在我看来“真随机”的“试金石”是量子效应。一个光子穿过或不穿过一个半透镜。或者观察一个放射性粒子衰变。这类东西是现实世界最接近真随机的东西。当然，有些人也不相信这类过程是真随机的，或者这个世界根本不存在任何随机性。这个就百家争鸣了，我也不好多说什么了。

密码学家一般都会通过不去讨论什么是“真随机”来避免这种哲学辩论。他们更关心的是<ruby> 不可预测性 <rt>  unpredictability </rt></ruby>。只要没有*任何*方法能猜出下一个随机数就可以了。所以当你以密码学应用为前提讨论一个随机数好不好的时候，在我看来这才是最重要的。

无论如何，我不怎么关心“哲学上安全”的随机数，这也包括别人嘴里的“真”随机数。

### 两种安全，一种有用

但就让我们退一步说，你有了一个“真”随机变量。你下一步做什么呢？

你把它们打印出来然后挂在墙上来展示量子宇宙的美与和谐？牛逼！我支持你。

但是等等，你说你要*用*它们？做密码学用途？额，那这就废了，因为这事情就有点复杂了。

事情是这样的，你的真随机、量子力学加护的随机数即将被用进不理想的现实世界算法里去。

因为我们使用的几乎所有的算法都并不是<ruby> 信息论安全性 <rt>  information-theoretic security </rt></ruby>的。它们“只能”提供**计算意义上的安全**。我能想到为数不多的例外就只有 Shamir 密钥分享和<ruby> 一次性密码本 <rt>  One-time pad </rt></ruby>（OTP）算法。并且就算前者是名副其实的（如果你实际打算用的话），后者则毫无可行性可言。

但所有那些大名鼎鼎的密码学算法，AES、RSA、Diffie-Hellman、椭圆曲线，还有所有那些加密软件包，OpenSSL、GnuTLS、Keyczar、你的操作系统的加密 API，都仅仅是计算意义上安全的。

那区别是什么呢？信息论安全的算法肯定是安全的，绝对是，其它那些的算法都可能在理论上被拥有无限计算力的穷举破解。我们依然愉快地使用它们是因为全世界的计算机加起来都不可能在宇宙年龄的时间里破解，至少现在是这样。而这就是我们文章里说的“不安全”。

除非哪个聪明的家伙破解了算法本身 —— 在只需要更少量计算力、在今天可实现的计算力的情况下。这也是每个密码学家梦寐以求的圣杯：破解 AES 本身、破解 RSA 本身等等。

所以现在我们来到了更底层的东西：随机数生成器，你坚持要“真随机”而不是“伪随机”。但是没过一会儿你的真随机数就被喂进了你极为鄙视的伪随机算法里了！

真相是，如果我们最先进的哈希算法被破解了，或者最先进的分组加密算法被破解了，你得到的这些“哲学上不安全”的随机数甚至无所谓了，因为反正你也没有安全的应用方法了。

所以把计算性上安全的随机数喂给你的仅仅是计算性上安全的算法就可以了，换而言之，用 `/dev/urandom`。

### Linux 随机数生成器的构架

#### 一种错误的看法

你对内核的随机数生成器的理解很可能是像这样的：

“真正的随机性”，尽管可能有点瑕疵，进入操作系统然后它的熵立刻被加入内部熵计数器。然后经过“矫偏”和“漂白”之后它进入内核的熵池，然后 `/dev/random` 和 `/dev/urandom` 从里面生成随机数。

“真”随机数生成器，`/dev/random`，直接从池里选出随机数，如果熵计数器表示能满足需要的数字大小，那就吐出数字并且减少熵计数。如果不够的话，它会阻塞程序直至有足够的熵进入系统。

这里很重要一环是 `/dev/random` 几乎只是仅经过必要的“漂白”后就直接把那些进入系统的随机性吐了出来，不经扭曲。

而对 `/dev/urandom` 来说，事情是一样的。除了当没有足够的熵的时候，它不会阻塞，而会从一直在运行的伪随机数生成器（当然，是密码学安全的，CSPRNG）里吐出“低质量”的随机数。这个 CSPRNG 只会用“真随机数”生成种子一次（或者好几次，这不重要），但你不能特别相信它。

在这种对随机数生成的理解下，很多人会觉得在 Linux 下尽量避免 `/dev/urandom` 看上去有那么点道理。

因为要么你有足够多的熵，你会相当于用了 `/dev/random`。要么没有，那你就会从几乎没有高熵输入的 CSPRNG 那里得到一个低质量的随机数。

看上去很邪恶是吧？很不幸的是这种看法是完全错误的。实际上，随机数生成器的构架更像是下面这样的。

#### 更好地简化

##### Linux 4.8 之前

你看到最大的区别了吗？CSPRNG 并不是和随机数生成器一起跑的，它在 `/dev/urandom` 需要输出但熵不够的时候进行填充。CSPRNG 是整个随机数生成过程的内部组件之一。从来就没有什么 `/dev/random` 直接从池里输出纯纯的随机性。每个随机源的输入都在 CSPRNG 里充分混合和散列过了，这一切都发生在实际变成一个随机数，被 `/dev/urandom` 或者 `/dev/random` 吐出去之前。

另外一个重要的区别是这里没有熵计数器的任何事情，只有预估。一个源给你的熵的量并不是什么很明确能直接得到的数字。你得预估它。注意，如果你太乐观地预估了它，那 `/dev/random` 最重要的特性——只给出熵允许的随机量——就荡然无存了。很不幸的，预估熵的量是很困难的。

>
> 这是个很粗糙的简化。实际上不仅有一个，而是三个熵池。一个主池，另一个给 `/dev/random`，还有一个给 `/dev/urandom`，后两者依靠从主池里获取熵。这三个池都有各自的熵计数器，但二级池（后两个）的计数器基本都在 0 附近，而“新鲜”的熵总在需要的时候从主池流过来。同时还有好多混合和回流进系统在同时进行。整个过程对于这篇文档来说都过于复杂了，我们跳过。
>
>
>

Linux 内核只使用事件的到达时间来预估熵的量。根据模型，它通过多项式插值来预估实际的到达时间有多“出乎意料”。这种多项式插值的方法到底是不是好的预估熵量的方法本身就是个问题。同时硬件情况会不会以某种特定的方式影响到达时间也是个问题。而所有硬件的取样率也是个问题，因为这基本上就直接决定了随机数到达时间的颗粒度。

说到最后，至少现在看来，内核的熵预估还是不错的。这也意味着它比较保守。有些人会具体地讨论它有多好，这都超出我的脑容量了。就算这样，如果你坚持不想在没有足够多的熵的情况下吐出随机数，那你看到这里可能还会有一丝紧张。我睡的就很香了，因为我不关心熵预估什么的。

最后要明确一下：`/dev/random` 和 `/dev/urandom` 都是被同一个 CSPRNG 饲喂的。只有它们在用完各自熵池（根据某种预估标准）的时候，它们的行为会不同：`/dev/random` 阻塞，`/dev/urandom` 不阻塞。

##### Linux 4.8 以后

在 Linux 4.8 里，`/dev/random` 和 `/dev/urandom` 的等价性被放弃了。现在 `/dev/urandom` 的输出不来自于熵池，而是直接从 CSPRNG 来。

*我们很快会理解*为什么这不是一个安全问题。（参见：“CSPRNG 没问题”一节）

### 阻塞有什么问题？

你有没有需要等着 `/dev/random` 来吐随机数？比如在虚拟机里生成一个 PGP 密钥？或者访问一个在生成会话密钥的网站？

这些都是问题。阻塞本质上会降低可用性。换而言之你的系统不干你让它干的事情。不用我说，这是不好的。要是它不干活你干嘛搭建它呢？

>
> 我在工厂自动化里做过和安全相关的系统。猜猜看安全系统失效的主要原因是什么？操作问题。就这么简单。很多安全措施的流程让工人恼火了。比如时间太长，或者太不方便。你要知道人很会找捷径来“解决”问题。
>
>
>

但其实有个更深刻的问题：人们不喜欢被打断。它们会找一些绕过的方法，把一些诡异的东西接在一起仅仅因为这样能用。一般人根本不知道什么密码学什么乱七八糟的，至少正常的人是这样吧。

为什么不禁止调用 `random()`？为什么不随便在论坛上找个人告诉你用写奇异的 ioctl 来增加熵计数器呢？为什么不干脆就把 SSL 加密给关了算了呢？

到头来如果东西太难用的话，你的用户就会被迫开始做一些降低系统安全性的事情——你甚至不知道它们会做些什么。

我们很容易会忽视可用性之类的重要性。毕竟安全第一对吧？所以比起牺牲安全，不可用、难用、不方便都是次要的？

这种二元对立的想法是错的。阻塞不一定就安全了。正如我们看到的，`/dev/urandom` 直接从 CSPRNG 里给你一样好的随机数。用它不好吗！

### CSPRNG 没问题

现在情况听上去很惨淡。如果连高质量的 `/dev/random` 都是从一个 CSPRNG 里来的，我们怎么敢在高安全性的需求上使用它呢？

实际上，“看上去随机”是现存大多数密码学基础组件的基本要求。如果你观察一个密码学哈希的输出，它一定得和随机的字符串不可区分，密码学家才会认可这个算法。如果你生成一个分组加密，它的输出（在你不知道密钥的情况下）也必须和随机数据不可区分才行。

如果任何人能比暴力穷举要更有效地破解一个加密，比如它利用了某些 CSPRNG 伪随机的弱点，那这就又是老一套了：一切都废了，也别谈后面的了。分组加密、哈希，一切都是基于某个数学算法，比如 CSPRNG。所以别害怕，到头来都一样。

### 那熵池快空了的情况呢？

毫无影响。

加密算法的根基建立在攻击者不能预测输出上，只要最一开始有足够的随机性（熵）就行了。“足够”的下限可以是 256 位，不需要更多了。

介于我们一直在很随意的使用“熵”这个概念，我用“位”来量化随机性希望读者不要太在意细节。像我们之前讨论的那样，内核的随机数生成器甚至没法精确地知道进入系统的熵的量。只有一个预估。而且这个预估的准确性到底怎么样也没人知道。

### 重新选种

但如果熵这么不重要，为什么还要有新的熵一直被收进随机数生成器里呢？

>
> djb [提到](http://blog.cr.yp.to/20140205-entropy.html) 太多的熵甚至可能会起到反效果。
>
>
>

首先，一般不会这样。如果你有很多随机性可以拿来用，用就对了！

但随机数生成器时不时要重新选种还有别的原因：

想象一下如果有个攻击者获取了你随机数生成器的所有内部状态。这是最坏的情况了，本质上你的一切都暴露给攻击者了。

你已经凉了，因为攻击者可以计算出所有未来会被输出的随机数了。

但是，如果不断有新的熵被混进系统，那内部状态会再一次变得随机起来。所以随机数生成器被设计成这样有些“自愈”能力。

但这是在给内部状态引入新的熵，这和阻塞输出没有任何关系。

### random 和 urandom 的 man 页面

这两个 man 页面在吓唬程序员方面很有建树：

>
> 从 `/dev/urandom` 读取数据不会因为需要更多熵而阻塞。这样的结果是，如果熵池里没有足够多的熵，取决于驱动使用的算法，返回的数值在理论上有被密码学攻击的可能性。发动这样攻击的步骤并没有出现在任何公开文献当中，但这样的攻击从理论上讲是可能存在的。如果你的应用担心这类情况，你应该使用 `/dev/random`。
>
>
>
> >
> > 实际上已经有 `/dev/random` 和 `/dev/urandom` 的 Linux 内核 man 页面的更新版本。不幸的是，随便一个网络搜索出现我在结果顶部的仍然是旧的、有缺陷的版本。此外，许多 Linux 发行版仍在发布旧的 man 页面。所以不幸的是，这一节需要在这篇文章中保留更长的时间。我很期待删除这一节！
> >
> >
> >
>
>
>

没有“公开的文献”描述，但是 NSA 的小卖部里肯定卖这种攻击手段是吧？如果你真的真的很担心（你应该很担心），那就用 `/dev/random` 然后所有问题都没了？

然而事实是，可能某个什么情报局有这种攻击，或者某个什么邪恶黑客组织找到了方法。但如果我们就直接假设这种攻击一定存在也是不合理的。

而且就算你想给自己一个安心，我要给你泼个冷水：AES、SHA-3 或者其它什么常见的加密算法也没有“公开文献记述”的攻击手段。难道你也不用这几个加密算法了？这显然是可笑的。

我们在回到 man 页面说：“使用 `/dev/random`”。我们已经知道了，虽然 `/dev/urandom` 不阻塞，但是它的随机数和 `/dev/random` 都是从同一个 CSPRNG 里来的。

如果你真的需要信息论安全性的随机数（你不需要的，相信我），那才有可能成为唯一一个你需要等足够熵进入 CSPRNG 的理由。而且你也不能用 `/dev/random`。

man 页面有毒，就这样。但至少它还稍稍挽回了一下自己：

>
> 如果你不确定该用 `/dev/random` 还是 `/dev/urandom` ，那你可能应该用后者。通常来说，除了需要长期使用的 GPG/SSL/SSH 密钥以外，你总该使用`/dev/urandom` 。
>
>
>
> >
> > 该手册页的[当前更新版本](http://man7.org/linux/man-pages/man4/random.4.html)毫不含糊地说：
> >
> >
> > `/dev/random` 接口被认为是遗留接口，并且 `/dev/urandom` 在所有用例中都是首选和足够的，除了在启动早期需要随机性的应用程序；对于这些应用程序，必须替代使用 `getrandom(2)`，因为它将阻塞，直到熵池初始化完成。
> >
> >
> >
>
>
>

行。我觉得没必要，但如果你真的要用 `/dev/random` 来生成 “长期使用的密钥”，用就是了也没人拦着！你可能需要等几秒钟或者敲几下键盘来增加熵，但这没什么问题。

但求求你们，不要就因为“你想更安全点”就让连个邮件服务器要挂起半天。

### 正道

本篇文章里的观点显然在互联网上是“小众”的。但如果问一个真正的密码学家，你很难找到一个认同阻塞 `/dev/random` 的人。

比如我们看看 [Daniel Bernstein](http://www.mail-archive.com/cryptography@randombit.net/msg04763.html)（即著名的 djb）的看法：

>
> 我们密码学家对这种胡乱迷信行为表示不负责。你想想，写 `/dev/random` man 页面的人好像同时相信：
>
>
> * (1) 我们不知道如何用一个 256 位长的 `/dev/random` 的输出来生成一个无限长的随机密钥串流（这是我们需要 `/dev/urandom` 吐出来的），但与此同时
> * (2) 我们却知道怎么用单个密钥来加密一条消息（这是 SSL，PGP 之类干的事情）
>
>
> 对密码学家来说这甚至都不好笑了
>
>
>

或者 [Thomas Pornin](http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939) 的看法，他也是我在 stackexchange 上见过最乐于助人的一位：

>
> 简单来说，是的。展开说，答案还是一样。`/dev/urandom` 生成的数据可以说和真随机完全无法区分，至少在现有科技水平下。使用比 `/dev/urandom` “更好的“随机性毫无意义，除非你在使用极为罕见的“信息论安全”的加密算法。这肯定不是你的情况，不然你早就说了。
>
>
> urandom 的 man 页面多多少少有些误导人，或者干脆可以说是错的——特别是当它说 `/dev/urandom` 会“用完熵”以及 “`/dev/random` 是更好的”那几句话；
>
>
>

或者 [Thomas Ptacek](http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/) 的看法，他不设计密码算法或者密码学系统，但他是一家名声在外的安全咨询公司的创始人，这家公司负责很多渗透和破解烂密码学算法的测试：

>
> 用 urandom。用 urandom。用 urandom。用 urandom。用 urandom。
>
>
>

### 没有完美

`/dev/urandom` 不是完美的，问题分两层：

在 Linux 上，不像 FreeBSD，`/dev/urandom` 永远不阻塞。记得安全性取决于某个最一开始决定的随机性？种子？

Linux 的 `/dev/urandom` 会很乐意给你吐点不怎么随机的随机数，甚至在内核有机会收集一丁点熵之前。什么时候有这种情况？当你系统刚刚启动的时候。

FreeBSD 的行为更正确点：`/dev/random` 和 `/dev/urandom` 是一样的，在系统启动的时候 `/dev/random` 会阻塞到有足够的熵为止，然后它们都再也不阻塞了。

>
> 与此同时 Linux 实行了一个新的<ruby> 系统调用 <rt>  syscall </rt></ruby>，最早由 OpenBSD 引入叫 `getentrypy(2)`，在 Linux 下这个叫 `getrandom(2)`。这个系统调用有着上述正确的行为：阻塞到有足够的熵为止，然后再也不阻塞了。当然，这是个系统调用，而不是一个字节设备（LCTT 译注：不在 `/dev/` 下），所以它在 shell 或者别的脚本语言里没那么容易获取。这个系统调用 自 Linux 3.17 起存在。
>
>
>

在 Linux 上其实这个问题不太大，因为 Linux 发行版会在启动的过程中保存一点随机数（这发生在已经有一些熵之后，因为启动程序不会在按下电源的一瞬间就开始运行）到一个种子文件中，以便系统下次启动的时候读取。所以每次启动的时候系统都会从上一次会话里带一点随机性过来。

显然这比不上在关机脚本里写入一些随机种子，因为这样的显然就有更多熵可以操作了。但这样做显而易见的好处就是它不用关心系统是不是正确关机了，比如可能你系统崩溃了。

而且这种做法在你真正第一次启动系统的时候也没法帮你随机，不过好在 Linux 系统安装程序一般会保存一个种子文件，所以基本上问题不大。

虚拟机是另外一层问题。因为用户喜欢克隆它们，或者恢复到某个之前的状态。这种情况下那个种子文件就帮不到你了。

但解决方案依然和用 `/dev/random` 没关系，而是你应该正确的给每个克隆或者恢复的镜像重新生成种子文件。

### 太长不看

别问，问就是用 `/dev/urandom` !

---

via: <https://www.2uo.de/myths-about-urandom/>

作者：[Thomas Hühn](https://www.2uo.de/) 译者：[Moelf](https://github.com/Moelf) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


在树莓派上安装 Ubuntu MATE

Summary: 这篇快速指南告诉你如何在树莓派设备上安装 Ubuntu MATE。

学习来了

请问软件更新器在哪可以找到

没有显示器怎么办 还能安装吗？

接电视的hdmi

这篇快速指南告诉你如何在树莓派设备上安装 Ubuntu MATE。

# 在树莓派上安装 Ubuntu MATE

>
> 这篇快速指南告诉你如何在树莓派设备上安装 Ubuntu MATE。
>
>
>

[树莓派](https://www.raspberrypi.org/) 是目前最流行的单板机并且是创客首选的板子。[Raspbian](https://www.raspberrypi.org/downloads/) 是基于 Debian 的树莓派官方操作系统。它是轻量级的，内置了教育工具和能在大部分场景下完成工作的工具。

[安装 Raspbian](https://itsfoss.com/tutorial-how-to-install-raspberry-pi-os-raspbian-wheezy/) 安装同样简单，但是与 [Debian](https://www.debian.org/) 随同带来的问题是慢的升级周期和旧的软件包。

在树莓派上运行 Ubuntu 可以给你带来一个更丰富的体验和最新的软件。当在你的树莓派上运行 Ubuntu 时我们有几个选择。

1. [Ubuntu MATE](https://ubuntu-mate.org/) ：Ubuntu MATE 是仅有的原生支持树莓派且包含一个完整的桌面环境的发行版。
2. [Ubuntu Server 18.04](https://wiki.ubuntu.com/ARM/RaspberryPi#Recovering_a_system_using_the_generic_kernel) + 手动安装一个桌面环境。
3. 使用 [Ubuntu Pi Flavor Maker](https://ubuntu-pi-flavour-maker.org/download/) 社区构建的镜像，这些镜像只支持树莓派 2B 和 3B 的变种，并且**不能**更新到最新的 LTS 发布版。

第一个选择安装是最简单和快速的，而第二个选择给了你自由选择安装桌面环境的机会。我推荐选择前两个中的任一个。

这里是一些磁盘镜像下载链接。在这篇文章里我只会提及 Ubuntu MATE 的安装。

### 在树莓派上安装 Ubuntu MATE

去 Ubuntu MATE 的下载页面获取推荐的镜像。

试验性的 ARM64 版本只应在你需要在树莓派服务器上运行像 MongoDB 这样的 64 位应用时使用。

* [下载为树莓派准备的 Ubuntu MATE](https://ubuntu-mate.org/download/)

#### 第 1 步：设置 SD 卡

镜像文件一旦下载完成后需要解压。你可以简单的右击来提取它。

也可以使用下面命令做同样的事。

```
xz -d ubuntu-mate***.img.xz
```

如果你在 Windows 上你可以使用 [7-zip](https://www.7-zip.org/download.html) 替代。

安装 [Balena Etcher](https://www.balena.io/etcher/)，我们将使用这个工具将镜像写入 SD 卡。确保你的 SD 卡有至少 8 GB 的容量。

启动 Etcher，选择镜像文件和 SD 卡。

一旦进度完成 SD 卡就准备好了。

#### 第 2 步：设置树莓派

你可能已经知道你需要一些外设才能使用树莓派，例如鼠标、键盘、HDMI 线等等。你同样可以[不用键盘和鼠标安装树莓派](https://linuxhandbook.com/raspberry-pi-headless-setup/)，但是这篇指南不是那样。

* 插入一个鼠标和一个键盘。
* 连接 HDMI 线缆。
* 插入 SD 卡 到 SD 卡槽。

插入电源线给它供电。确保你有一个好的电源供应（5V、3A 至少）。一个不好的电源供应可能降低性能。

#### Ubuntu MATE 安装

一旦你给树莓派供电，你将遇到非常熟悉的 Ubuntu 安装过程。在这里的安装过程相当直接。

选择你的 WiFi 网络并且在网络连接中输入密码。

在设置了键盘布局、时区和用户凭证后，在几分钟后你将被带到登录界面。瞧！你快要完成了。

一旦登录，第一件事你应该做的是[更新 Ubuntu](https://itsfoss.com/update-ubuntu/)。你应该使用下列命令。

```
sudo apt update
sudo apt upgrade
```

你同样可以使用软件更新器。

一旦更新完成安装你就可以开始了。你可以根据你的需要继续安装树莓派平台为 GPIO 和其他 I/O 准备的特定软件包。

是什么让你考虑在 Raspberry 上安装 Ubuntu，你对 Raspbian 的体验如何呢？请在下方评论来让我知道。

---

via: <https://itsfoss.com/ubuntu-mate-raspberry-pi/>

作者：[Chinmay](https://itsfoss.com/author/chinmay/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[warmfrog](https://github.com/warmfrog) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


每日安全资讯：几大 Git 平台仓库被劫，黑客欲勒索比特币

Summary: 好消息是，发现黑客实际上没有删除，仅仅是改变了 Git 提交标头，这意味着在某些情况下可以恢复代码提交。

# 每日安全资讯：几大 Git 平台仓库被劫，黑客欲勒索比特币

数百名开发人员的 Git 仓库被黑客删除，取而代之的是赎金要求。攻击于 5 月 3 日开始，包括 GitHub、Bitbucket 和 GitLab在内的代码托管平台都受到了影响。 目前已知的情况是，黑客从受害者的 Git 仓库中删除了所有源代码和最近提交的 Repo，只留下了 0.1 比特币（约 ¥3850）的赎金票据。

黑客声称所有源码都已经下载并存储在他们的一台服务器上，并且给受害者十天时间支付赎金，否则，他们会公开代码。

>
> 想要恢复丢失的代码并避免泄露：请将 0.1 比特币（BTC）发送至我们的比特币地址 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA，并将您的 Git 登录信息和付款证明发送至 admin@gitsbackup.com。如果您不确定我们是否有您的数据，请与我们联系，我们将向您发送证明，您的代码已下载并备份在我们的服务器上。如果我们在接下来的 10 天内没有收到付款，我们将公开代码或以其他方式使用。
>
>
>

在 GitHub 上搜索可发现已有 391 个仓库受影响，这些仓库的代码和提交信息均被一个名为 “gitbackup” 的账号删除。

尽管如此，BitcoinAbuse 平台显示，该比特币地址目前还未收到赎金。

一名用户指出 GitHub 在发现攻击后暂停帐户并进行调查：“GitHub 昨晚在他们调查时暂停了我的帐户，希望今天能听到他们的消息，我可能很幸运。”

据 ZDNet 的报道，好消息是，在深入挖掘受害者的案例后，StackExchange 安全论坛的成员发现黑客实际上没有删除，仅仅是改变了 Git 提交标头，这意味着在某些情况下可以恢复代码提交。

最新消息，GitLab 的安全总监 Kathy Wang 告诉 BleepingComputer：

>
> 我们根据 Stefan Gabos 昨天提交的赎金票据确定了消息来源，并立即开始调查此问题。我们已确定受影响的用户帐户，并且已通知所有这些用户。根据调查结果，我们有充分证据表明，受损帐户的帐户密码以明文形式存储在相关存储库的部署中。我们强烈建议使用密码管理工具以更安全的方式存储密码，并尽可能启用双因素身份验证，这两种方法都可以防止出现此问题。
>
>
>

目前，平台和用户都在努力解决问题，此处正在持续讨论可能的解决方案。

来源：开源中国

### 更多资讯

##### 黑客轻松接管 29 个僵尸网络 只因运营者太菜

ZDNet 网站报导，安全专家一次性接管了 29 个僵尸网络，原理十分简单，利用了运营者技术“太菜”的方法。在采访中，安全专家 Subby 介绍了他接管的这 29 个僵尸网络，他指出其实这些僵尸网络都比较小，最初的机器人数量显示总计将近 40000，但在删除重复数据后，实际数量仅为 25000，这样的数据对于一个单独的 IoT 僵尸网络来说都是很小的，更不用说是 29 个的总和了。

来源： 开源中国

详情： <http://t.cn/EoPirDH>

##### 德国警方查封全球第二大暗网黑市 Wall Street Market

据外媒 Techspot 报道，近日警方已查封全球第二大暗网黑市。德国当局领导的这项努力导致三名嫌疑人被捕，这是近两年调查的结果。警方还没收了超过 55 万欧元现金以及多辆车、电脑，数据存储和“ 6 位数的加密货币比特币和门罗币”。另外两名嫌疑人在美国被捕，被描述为“销售致幻毒品最多的供应商”。

来源： cnBeta.COM
详情： <http://t.cn/EoPiF9c>

##### 何时能不被黑客鱼肉？D-Link 智能摄像头又出事了

近些年来各家厂商把“智能”摄像头市场做的是风生水起，许多消费者也想靠这些大眼睛来守护一方平安。对普通人来说，这些智能化的摄像头确实相当方便，只需连上网络，你就能在千里之外获取自己需要的画面。不过，在你享受方便之余又很容易掉入陷阱，因为安全漏洞背后藏着的坏人太可怕了。

来源： 雷锋网
详情： <http://t.cn/EoP67yZ>

##### Mozilla 曝出大乌龙 证书过期导致全球 Firefox 用户无法使用扩展

今天早上 Mozilla 和全球的 Firefox 用户开了个不大不小的玩笑，许多人一大早起来打开浏览器发现所有的扩展都无法使用，就连手机版也是如此。重装 Firefox 或者重装所有的插件都无济于事，在 Bugzilla 上提交的报告中我们了解到，这是由于 Mozilla 的官方证书没有及时续期所致。

来源： cnBeta.COM
详情： <http://t.cn/EoP6b8B>

（信息来源于网络，安华金和搜集整理）


DomTerm：一款为 Linux 打造的终端模拟器

# DomTerm：一款为 Linux 打造的终端模拟器

>
> 了解一下 DomTerm，这是一款终端模拟器和复用器，带有 HTML 图形和其它不多见的功能。
>
>
>

[DomTerm](http://domterm.org/) 是一款现代化的终端模拟器，它使用浏览器引擎作为 “GUI 工具包”。这就支持了一些相关的特性，例如可嵌入图像和链接、HTML 富文本以及可折叠（显示/隐藏）命令。除此以外，它看起来感觉就像一个功能完整、独立的终端模拟器，有着出色 xterm 兼容性（包括鼠标处理和 24 位色）和恰当的 “装饰” （菜单）。另外它内置支持了会话管理和副窗口（如同 `tmux` 和 `GNU Screen` 中一样）、基本输入编辑（如在 `readline` 中）以及分页（如在 `less` 中）。

*图 1: DomTerminal 终端模拟器。*

在以下部分我们将看一看这些特性。我们将假设你已经安装好了 `domterm` （如果你需要获取并构建 Dormterm 请跳到本文最后）。开始之前先让我们概览一下这项技术。

### 前端 vs. 后端

DomTerm 大部分是用 JavaScript 写的，它运行在一个浏览器引擎中。它可以是像例如 Chrome 或者 Firefox 一样的桌面浏览器（见图 3），也可以是一个内嵌的浏览器。使用一个通用的网页浏览器没有问题，但是用户体验却不够好（因为菜单是为通用的网页浏览而不是为了终端模拟器所打造)，并且其安全模型也会妨碍使用。因此使用内嵌的浏览器更好一些。

目前以下这些是支持的：

* qdomterm，使用了 Qt 工具包 和 QtWebEngine
* 一个内嵌的 [Electron](https://electronjs.org/)（见图 1）
* atom-domterm 以 [Atom 文本编辑器](https://atom.io/)（同样基于 Electron）包的形式运行 DomTerm，并和 Atom 面板系统集成在一起（见图 2）
* 一个为 JavaFX 的 WebEngine 包装器，这对 Java 编程十分有用（见图 4）
* 之前前端使用 [Firefox-XUL](https://en.wikipedia.org/wiki/XUL) 作为首选，但是 Mozilla 已经终止了 XUL

*图 2：在 Atom 编辑器中的 DomTerm 终端面板。*

目前，Electron 前端可能是最佳选择，紧随其后的是 Qt 前端。如果你使用 Atom，atom-domterm 也工作得相当不错。

后端服务器是用 C 写的。它管理着伪终端（PTY）和会话。它同样也是一个为前端提供 Javascript 和其它文件的 HTTP 服务器。`domterm` 命令启动终端任务和执行其它请求。如果没有服务器在运行，domterm 就会自己来服务。后端与服务器之间的通讯通常是用 WebSockets（在服务器端是[libwebsockets](https://libwebsockets.org/)）完成的。然而，JavaFX 的嵌入既不用 Websockets 也不用 DomTerm 服务器。相反 Java 应用直接通过 Java-Javascript 桥接进行通讯。

### 一个稳健的可兼容 xterm 的终端模拟器

DomTerm 看上去感觉像一个现代的终端模拟器。它处理鼠标事件、24 位色、Unicode、倍宽字符（CJK）以及输入方式。DomTerm 在 [vttest 测试套件](http://invisible-island.net/vttest/) 上工作地十分出色。

其不同寻常的特性包括：

**展示/隐藏按钮（“折叠”）：** 小三角（如上图 2）是隐藏/展示相应输出的按钮。仅需在[提示符](http://domterm.org/Shell-prompts.html)中添加特定的[转义字符](http://domterm.org/Wire-byte-protocol.html)就可以创建按钮。

**对于 readline 和类似输入编辑器的鼠标点击支持：** 如果你点击输入区域（黄色），DomTerm 会向应用发送正确的方向键按键序列。（可以通过提示符中的转义字符启用这一特性，你也可以通过 `Alt+点击` 强制使用。）

**用 CSS 样式化终端：** 这通常是在 `~/.domterm/settings.ini` 里完成的，保存时会自动重载。例如在图 2 中，设置了终端专用的背景色。

### 一个更好的 REPL 控制台

一个经典的终端模拟器基于长方形的字符单元格工作的。这在 REPL（命令行）上没问题，但是并不理想。这里有些通常在终端模拟器中不常见的 REPL 很有用的 DomTerm 特性：

**一个能“打印”图片、图形、数学公式或者一组可点击的链接的命令：** 应用可以发送包含几乎任何 HTML 的转义字符。（HTML 会被剔除部分，以移除 JavaScript 和其它危险特性。）

图 3 显示了来自 [gnuplot](http://www.gnuplot.info/) 会话的一个片段。Gnuplot（2.1 或者跟高版本）支持 DormTerm 作为终端类型。图形输出被转换成 [SVG 图片](https://developer.mozilla.org/en-US/docs/Web/SVG)，然后被打印到终端。我的博客帖子[在 DormTerm 上的 Gnuplot 展示](http://per.bothner.com/blog/2016/gnuplot-in-domterm/)在这方面提供了更多信息。

*图 3：Gnuplot 截图。*

[Kawa](https://www.gnu.org/software/kawa/) 语言有一个创建并转换[几何图像值](https://www.gnu.org/software/kawa/Composable-pictures.html)的库。如果你将这样的图片值打印到 DomTerm 终端，图片就会被转换成 SVG 形式并嵌入进输出中。

*图 4：Kawa 中可计算的几何形状。*

**富文本输出：** 有着 HTML 样式的帮助信息更加便于阅读，看上去也更漂亮。图片 1 的下面面板展示 `dormterm help` 的输出。（如果没在 DomTerm 下运行的话输出的是普通文本。）注意自带的分页器中的 `PAUSED` 消息。

**包括可点击链接的错误消息：** DomTerm 可以识别语法 `filename:line:column` 并将其转化成一个能在可定制文本编辑器中打开文件并定位到行的链接。（这适用于相对路径的文件名，如果你用 `PROMPT_COMMAND` 或类似的跟踪目录。）

编译器可以侦测到它在 DomTerm 下运行，并直接用转义字符发出文件链接。这比依赖 DomTerm 的样式匹配要稳健得多，因为它可以处理空格和其他字符并且无需依赖目录追踪。在图 4 中，你可以看到来自 [Kawa Compiler](https://www.gnu.org/software/kawa/) 的错误消息。悬停在文件位置上会使其出现下划线，`file:` URL 出现在 `atom-domterm` 消息栏（窗口底部）中。（当不用 atom-domterm 时，这样的消息会在一个浮层的框中显示，如图 1 中所看到的 `PAUSED` 消息所示。）

点击链接时的动作是可以配置的。默认对于带有 `#position` 后缀的 `file:` 链接的动作是在文本编辑器中打开那个文件。

**结构化内部表示：**以下内容均以内部节点结构表示：命令、提示符、输入行、正常和错误输出、标签，如果“另存为 HTML”，则保留结构。HTML 文件与 XML 兼容，因此你可以使用 XML 工具搜索或转换输出。命令 `domterm view-saved` 会以一种启用命令折叠（显示/隐藏按钮处于活动状态）和重新调整窗口大小的方式打开保存的 HTML 文件。

**内建的 Lisp 样式优美打印：** 你可以在输出中包括优美打印指令（比如，grouping），这样断行会根据窗口大小调整而重新计算。查看我的文章 [DomTerm 中的动态优美打印](http://per.bothner.com/blog/2017/dynamic-prettyprinting/)以更深入探讨。

**基本的内建行编辑**，带着历史记录（像 GNU readline 一样）： 这使用浏览器自带的编辑器，因此它有着优秀的鼠标和选择处理机制。你可以在正常字符模式（大多数输入的字符被指接送向进程）；或者行模式（通常的字符是直接插入的，而控制字符导致编辑操作，回车键会向进程发送被编辑行）之间转换。默认的是自动模式，根据 PTY 是在原始模式还是终端模式中，DomTerm 在字符模式与行模式间转换。

**自带的分页器**（类似简化版的 `less`）：键盘快捷键控制滚动。在“页模式”中，输出在每个新的屏幕（或者单独的行，如果你想一行行地向前移）后暂停；页模式对于用户输入简单智能，因此（如果你想的话）你无需阻碍交互式程序就可以运行它。

### 多路复用和会话

**标签和平铺：** 你不仅可以创建多个终端标签，也可以平铺它们。你可以要么使用鼠标或键盘快捷键来创建或者切换面板和标签。它们可以用鼠标重新排列并调整大小。这是通过 [GoldenLayout](https://golden-layout.com/) JavaScript 库实现的。图 1 展示了一个有着两个面板的窗口。上面的有两个标签，一个运行 [Midnight Commander](https://midnight-commander.org/)；底下的面板以 HTML 形式展示了 `dormterm help` 输出。然而相反在 Atom 中我们使用其自带的可拖拽的面板和标签。你可以在图 2 中看到这个。

**分离或重接会话：** 与 `tmux` 和 GNU `screen` 类似，DomTerm 支持会话安排。你甚至可以给同样的会话接上多个窗口或面板。这支持多用户会话分享和远程链接。（为了安全，同一个服务器的所有会话都需要能够读取 Unix 域接口和一个包含随机密钥的本地文件。当我们有了良好、安全的远程链接，这个限制将会有所放松。）

**domterm 命令** 类似与 `tmux` 和 GNU `screen`，它有多个选项可以用于控制或者打开单个或多个会话的服务器。主要的差别在于，如果它没在 DomTerm 下运行，`dormterm` 命令会创建一个新的顶层窗口，而不是在现有的终端中运行。

与 `tmux` 和 `git` 类似，`dormterm` 命令有许多子命令。一些子命令创建窗口或者会话。另一些（例如“打印”一张图片）仅在现有的 DormTerm 会话下起作用。

命令 `domterm browse` 打开一个窗口或者面板以浏览一个指定的 URL，例如浏览文档的时候。

### 获取并安装 DomTerm

DomTerm 可以从其 [Github 仓库](https://github.com/PerBothner/DomTerm)获取。目前没有提前构建好的包，但是有[详细指导](http://domterm.org/Downloading-and-building.html)。所有的前提条件在 Fedora 27 上都有，这使得其特别容易被搭建。

---

via: <https://opensource.com/article/18/1/introduction-domterm-terminal-emulator>

作者：[Per Bothner](https://opensource.com/users/perbothner) 译者：[tomjlw](https://github.com/tomjlw) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


如何安装和配置 Chrony 作为 NTP 客户端？

# 如何安装和配置 Chrony 作为 NTP 客户端？

<img src="content_image/album_201905_06_145607nayfax0vxc3vy73o.jpg" alt="" title="">

NTP 服务器和 NTP 客户端可以让我们通过网络来同步时钟。之前，我们已经撰写了一篇关于 [NTP 服务器和 NTP 客户端的安装与配置](/article-10811-1.html) 的文章。

如果你想看这些内容，点击上述的 URL 访问。

### Chrony 客户端

Chrony 是 NTP 客户端的替代品。它能以更精确的时间和更快的速度同步时钟，并且它对于那些不是全天候在线的系统非常有用。

chronyd 更小、更节能，它占用更少的内存且仅当需要时它才唤醒 CPU。即使网络拥塞较长时间，它也能很好地运行。它支持 Linux 上的硬件时间戳，允许在本地网络进行极其准确的同步。

它提供下列两个服务。

* `chronyc`：Chrony 的命令行接口。
* `chronyd`：Chrony 守护进程服务。

### 如何在 Linux 上安装和配置 Chrony？

由于安装包在大多数发行版的官方仓库中可用，因此直接使用包管理器去安装它。

对于 Fedora 系统，使用 [DNF 命令](https://www.2daygeek.com/dnf-command-examples-manage-packages-fedora-system/) 去安装 chrony。

```
$ sudo dnf install chrony
```

对于 Debian/Ubuntu 系统，使用 [APT-GET 命令](https://www.2daygeek.com/apt-get-apt-cache-command-examples-manage-packages-debian-ubuntu-systems/) 或者 [APT 命令](https://www.2daygeek.com/apt-command-examples-manage-packages-debian-ubuntu-systems/) 去安装 chrony。

```
$ sudo apt install chrony
```

对基于 Arch Linux 的系统，使用 [Pacman 命令](https://www.2daygeek.com/pacman-command-examples-manage-packages-arch-linux-system/) 去安装 chrony。

```
$ sudo pacman -S chrony
```

对于 RHEL/CentOS 系统，使用 [YUM 命令](https://www.2daygeek.com/yum-command-examples-manage-packages-rhel-centos-systems/) 去安装 chrony。

```
$ sudo yum install chrony
```

对于 openSUSE Leap 系统，使用 [Zypper 命令](https://www.2daygeek.com/zypper-command-examples-manage-packages-opensuse-system/) 去安装 chrony。

```
$ sudo zypper install chrony
```

在这篇文章中，我们将使用下列设置去测试。

* NTP 服务器：主机名：CentOS7.2daygeek.com，IP：192.168.1.5，OS：CentOS 7
* Chrony 客户端：主机名：Ubuntu18.2daygeek.com，IP：192.168.1.3，OS：Ubuntu 18.04

服务器的安装请访问 [在 Linux 上安装和配置 NTP 服务器](/article-10811-1.html) 的 URL。

我已经在 CentOS7.2daygeek.com 这台主机上安装和配置了 NTP 服务器，因此，将其附加到所有的客户端机器上。此外，还包括其他所需信息。

`chrony.conf` 文件的位置根据你的发行版不同而不同。

对基于 RHEL 的系统，它位于 `/etc/chrony.conf`。

对基于 Debian 的系统，它位于 `/etc/chrony/chrony.conf`。

```
# vi /etc/chrony/chrony.conf

server CentOS7.2daygeek.com prefer iburst
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
maxupdateskew 100.0
makestep 1 3
cmdallow 192.168.1.0/24
```

更新配置后需要重启 Chrony 服务。

对于 sysvinit 系统。基于 RHEL 的系统需要去运行 `chronyd` 而不是 `chrony`。

```
# service chronyd restart
# chkconfig chronyd on
```

对于 systemctl 系统。 基于 RHEL 的系统需要去运行 `chronyd` 而不是 `chrony`。

```
# systemctl restart chronyd
# systemctl enable chronyd
```

使用像 `tacking`、`sources` 和 `sourcestats` 这样的子命令去检查 chrony 的同步细节。

去检查 chrony 的追踪状态。

```
# chronyc tracking
Reference ID    : C0A80105 (CentOS7.2daygeek.com)
Stratum         : 3
Ref time (UTC)  : Thu Mar 28 05:57:27 2019
System time     : 0.000002545 seconds slow of NTP time
Last offset     : +0.001194361 seconds
RMS offset      : 0.001194361 seconds
Frequency       : 1.650 ppm fast
Residual freq   : +184.101 ppm
Skew            : 2.962 ppm
Root delay      : 0.107966967 seconds
Root dispersion : 1.060455322 seconds
Update interval : 2.0 seconds
Leap status     : Normal
```

运行 `sources` 命令去显示当前时间源的信息。

```
# chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* CentOS7.2daygeek.com          2   6    17    62    +36us[+1230us] +/- 1111ms
```

`sourcestats` 命令显示有关 chronyd 当前正在检查的每个源的漂移率和偏移估计过程的信息。

```
# chronyc sourcestats
210 Number of sources = 1
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
CentOS7.2daygeek.com        5   3    71    -97.314     78.754   -469us   441us
```

当 chronyd 配置为 NTP 客户端或对等端时，你就能通过 `chronyc ntpdata` 命令向每一个 NTP 源发送/接收时间戳模式和交错模式的报告。

```
# chronyc ntpdata

Remote address  : 192.168.1.5 (C0A80105)
Remote port     : 123
Local address   : 192.168.1.3 (C0A80103)
Leap status     : Normal
Version         : 4
Mode            : Server
Stratum         : 2
Poll interval   : 6 (64 seconds)
Precision       : -23 (0.000000119 seconds)
Root delay      : 0.108994 seconds
Root dispersion : 0.076523 seconds
Reference ID    : 85F3EEF4 ()
Reference time  : Thu Mar 28 06:43:35 2019
Offset          : +0.000160221 seconds
Peer delay      : 0.000664478 seconds
Peer dispersion : 0.000000178 seconds
Response time   : 0.000243252 seconds
Jitter asymmetry: +0.00
NTP tests       : 111 111 1111
Interleaved     : No
Authenticated   : No
TX timestamping : Kernel
RX timestamping : Kernel
Total TX        : 46
Total RX        : 46
Total valid RX  : 46
```

最后运行 `date` 命令。

```
# date
Thu Mar 28 03:08:11 CDT 2019
```

为了立即跟进系统时钟，绕过任何正在进行的缓步调整，请以 root 身份运行以下命令（以手动调整系统时钟）。

```
# chronyc makestep
```

---

via: <https://www.2daygeek.com/configure-ntp-client-using-chrony-in-linux/>

作者：[Magesh Maruthamuthu](https://www.2daygeek.com/author/magesh/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[arrowfeng](https://github.com/arrowfeng) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


每日安全资讯：国家互联网应急中心开通勒索病毒免费查询服务

# 每日安全资讯：国家互联网应急中心开通勒索病毒免费查询服务

从国家互联网应急中心获悉，为了有效控制 WannaCry 勒索病毒的传播感染，国家互联网应急中心近日开通了该病毒感染数据免费查询服务。2017 年 5 月 12 日，WannaCry 勒索病毒利用 Windows SMB（“永恒之蓝”）漏洞在全球快速传播，造成全球计算机大范围感染。

<img src="content_image/album_201905_06_151140a9tai7et4te4r9ig.jpg" alt="" title="">

国家互联网应急中心介绍说，为实时掌握 WannaCry 勒索病毒及其变种在我国的传播感染情况，国家互联网应急中心持续开展针对该病毒的监测工作。根据分析，WannaCry 勒索病毒成功感染计算机并运行后，首先会主动连接一个开关域名。如果与开关域名通信成功，该病毒将不运行勒索行为，但病毒文件仍驻留在被感染计算机中；如果通信失败，该病毒将运行勒索行为加密计算机中的文件，并继续向局域网或互联网上的其他计算机传播。

据悉，截至 2019 年 4 月 9 日，国家互联网应急中心监测发现我国境内疑似感染 WannaCry 勒索病毒的计算机数量超过 30 万台，仍有大量的计算机未安装“永恒之蓝”漏洞补丁和杀毒软件。我国计算机感染 WannaCry 勒索病毒疫情依然比较严峻。

为了有效控制 WannaCry 勒索病毒的传播感染，国家互联网应急中心开通了该病毒感染数据免费查询服务。查询说明如下：

1、WannaCry 勒索病毒暂只能感染 Windows 操作系统，请用户在 Windows 操作系统上的浏览器中输入查询地址打开查询页面进行查询，查询地址为：h ttp://wanna-check.cert.org.cn。

2、若提示 IP 地址承载的计算机受到感染，建议使用 WannaCry 勒索病毒专杀工具进行查杀，并及时修复相关漏洞。

3、如果使用宽带拨号上网或手机上网，由于 IP 地址经常变化，会导致查询结果不准确，仅供参考。

来源：快科技

### 更多资讯

##### 中消协等发智能锁试验报告：半数存指纹识别安全风险

中国消费者协会、四川省保护消费者权益委员会、 深圳市消费者委员会、佛山市消费者委会今天联合发布智能门锁比较试验报告，29 款样品中，48.3% 的样品密码开启安全存在风险，50% 的样品指纹识别开启安全存在风险，85.7% 的样品信息识别卡开启安存在风险。

来源： 央视新闻客户端

详情： <http://t.cn/EoLwr4r>

##### 如何让过期证书事故不再发生

证书过期是一种常见的问题，但其影响面却可能极其广泛。此类事故频繁发生是因为安装和更新证书是一个乏味的手动过程。证书过期的现象已经有了改善，Let’s Encrypt 和 SSLMate 等 CA 开始提供证书自动更新的方法。

来源： solidot.org

详情： <http://t.cn/EoLwsEt>

##### 男子购买“教程”掌握点餐软件漏洞 边消费边退代金券大肆实施盗窃

如今，各大餐饮行业手机自助点餐软件兴起，特别是在快餐行业中，大大缓解了排队点餐的尴尬。但是由于软件程序中难免存在漏洞，也成为滋生犯罪的土壤。近日，徐汇区检察院对一起利用手机自助点餐软件漏洞，盗窃某知名快餐公司钱款的被告人钟某某提起公诉。

来源： 新民晚报

详情： <http://t.cn/EoLAw0A>

##### 中国一智能城市监控系统数据库被发现没有密码保护

智能城市设计旨在让居民生活更轻松，但如果它的监控系统数据泄露？John Wethington 报告一个智能城市数据库没有密码保护可以直接通过浏览器访问。

来源：solidot.org

详情： <http://t.cn/EoLAb4Q>

（信息来源于网络，安华金和搜集整理）


比容器快 10-20 倍的 unikernel 应用

Summary: unikernel 是一种用于在云基础架构上部署应用程序的更小、更快、更安全的方式。使用 NanoVMs OPS，任何人都可以将 Linux 应用程序作为 unikernel 运行而无需额外编码。它们通常比容器快 10 到 20 倍。

# 比容器快 10-20 倍的 unikernel 应用

unikernel 是一种用于在云基础架构上部署应用程序的更小、更快、更安全的方式。使用 NanoVMs OPS，任何人都可以将 Linux 应用程序作为 unikernel 运行而无需额外编码。

<img src="content_image/album_201905_06_153635h8eokokeouud06kk.jpg" alt="Marcho Verch \(CC BY 2.0\)" title="Marcho Verch \(CC BY 2.0\)">

随着 unikernel 的出现，构建和部署轻量级应用变得更容易、更可靠。虽然功能有限，但 unikernal 在速度和安全性方面有许多优势。

### 什么是 unikernel?

unikernel 是一种非常特殊的<ruby> 单一地址空间 <rt>  single-address-space </rt></ruby>的机器镜像，类似于已经主导大批互联网的云应用，但它们相当小并且是单一用途的。它们很轻，只提供所需的资源。它们加载速度非常快，而且安全性更高 —— 攻击面非常有限。单个可执行文件中包含所需的所有驱动、I/O 例程和支持库。其最终生成的虚拟镜像可以无需其它部分就可以引导和运行。它们通常比容器快 10 到 20 倍。

潜在的攻击者无法进入 shell 并获得控制权，因为它没有 shell。他们无法获取系统的 `/etc/passwd`或 `/etc/shadow` 文件，因为这些文件不存在。创建一个 unikernel 就像应用将自己变成操作系统。使用 unikernel，应用和操作系统将成为一个单一的实体。你忽略了不需要的东西，从而消除了漏洞并大幅提高性能。

简而言之，unikernel：

* 提供更高的安全性（例如，shell 破解代码无用武之地）
* 比标准云应用占用更小空间
* 经过高度优化
* 启动非常快

### unikernel 有什么缺点吗？

unikernel 的唯一严重缺点是你必须构建它们。对于许多开发人员来说，这是一个巨大的进步。由于应用的底层特性，将应用简化为所需的内容然后生成紧凑、平稳运行的应用可能很复杂。在过去，你几乎必须是系统开发人员或底层程序员才能生成它们。

### 这是怎么改变的？

最近（2019 年 3 月 24 日）[NanoVMs](https://nanovms.com/) 宣布了一个将任何 Linux 应用加载为 unikernel 的工具。使用 NanoVMs OPS，任何人都可以将 Linux 应用作为 unikernel 运行而无需额外编码。该应用还可以更快、更安全地运行，并且成本和开销更低。

### 什么是 NanoVMs OPS？

NanoVMs 是给开发人员的 unikernel 工具。它能让你运行各种企业级软件，但仍然可以非常严格地控制它的运行。

使用 OPS 的其他好处包括：

* 无需经验或知识，开发人员就可以构建 unikernel。
* 该工具可在笔记本电脑上本地构建和运行 unikernel。
* 无需创建帐户，只需下载并一个命令即可执行 OPS。

NanoVMs 的介绍可以在 [Youtube 上的 NanoVMs 视频](https://www.youtube.com/watch?v=VHWDGhuxHPM) 上找到。你还可以查看该公司的 [LinkedIn 页面](https://www.linkedin.com/company/nanovms/)并在[此处](https://nanovms.com/security)阅读有关 NanoVMs 安全性的信息。

还有有关如何[入门](https://nanovms.gitbook.io/ops/getting_started)的一些信息。

---

via: <https://www.networkworld.com/article/3387299/how-to-quickly-deploy-run-linux-applications-as-unikernels.html>

作者：[Sandra Henry-Stocker](https://www.networkworld.com/author/Sandra-Henry_Stocker/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


12 个可替代树莓派的单板机

Summary: 正在寻找树莓派的替代品？这里有一些单板机可以满足你的 DIY 渴求。

翻译读起来怪怪的，像机翻的感觉

这么多里咋还没有BeagleBone呢？

Lattle panda：？？？？？？？？？？

正在寻找树莓派的替代品？这里有一些单板机可以满足你的 DIY 渴求。

# 12 个可替代树莓派的单板机

>
> 正在寻找树莓派的替代品？这里有一些单板机可以满足你的 DIY 渴求。
>
>
>

树莓派是当前最流行的单板机。你可以在你的 DIY 项目中使用它，或者用它作为一个成本效益高的系统来学习编代码，或者为了你的便利，利用一个[流媒体软件](https://itsfoss.com/best-linux-media-server/)运行在上面作为流媒体设备。

你可以使用树莓派做很多事，但它不是各种极客的最终解决方案。一些人可能在寻找更便宜的开发板，一些可能在寻找更强大的。

无论是哪种情况，我们都有很多原因需要树莓派的替代品。因此，在这片文章里，我们将讨论最好的 12 个我们认为能够替代树莓派的单板机。

### 满足你 DIY 渴望的树莓派替代品

这个列表没有特定的顺序排名。链接的一部分是赞助链接。请阅读我们的[赞助政策](https://itsfoss.com/affiliate-policy/)。

#### 1、Onion Omega2+

只要 $13，Omega2+ 是这里你可以找到的最便宜的 IoT 单板机设备。它运行 LEDE（Linux 嵌入式开发环境）Linux 系统 —— 这是一个基于 [OpenWRT](https://openwrt.org/) 的发行版。

由于运行一个自定义 Linux 系统，它的组成元件、花费和灵活性使它完美适合几乎所有类型的 IoT 应用。

你可以在[亚马逊商城的 Onion Omega 套件](https://amzn.to/2Xj8pkn)或者从他们的网站下单，可能会收取额外的邮费。

**关键参数：**

* MT7688 SoC
* 2.4 GHz IEEE 802.11 b/g/n WiFi
* 128 MB DDR2 RAM
* 32 MB on-board flash storage
* MicroSD Slot
* USB 2.0
* 12 GPIO Pins

[查看官网](https://onion.io/store/omega2p/)

#### 2、NVIDIA Jetson Nano Developer Kit

这是来自 NVIDIA 的只要 **$99** 的非常独特和有趣的树莓派替代品。是的，它不是每个人都能充分利用的设备 —— 只为特定的一组极客或者开发者而生。

NVIDIA 使用下面的用例解释它：

>
> NVIDIA® Jetson Nano™ Developer Kit 是一个小的、强大的计算机，可以让你并行运行多个神经网络的应用像图像分类、对象侦察、图像分段、语音处理。全部在一个易于使用的、运行功率只有 5 瓦特的平台上。
>
>
> nvidia
>
>
>

因此，基本上，如果你正在研究 AI 或者深度学习，你可以充分利用开发设备。如果你很好奇，该设备的产品计算模块将在 2019 年 7 月到来。

**关键参数：**

* CPU: Quad-core ARM A57 @ 1.43 GHz
* GPU: 128-core Maxwell
* RAM: 4 GB 64-bit LPDDR4 25.6 GB/s
* Display: HDMI 2.0
* 4 x USB 3.0 and eDP 1.4

[查看官网](https://developer.nvidia.com/embedded/buy/jetson-nano-devkit)

#### 3、ASUS Tinker Board S

ASUS Tinker Board S 不是大多数人可负担得起的树莓派的替换设备 （**$82**，[亚马逊商城](https://amzn.to/2XfkOFT))，但是它是一个强大的替代品。它的特点是它有你通常可以发现与标准树莓派 3 一样的 40 针脚的连接器，但是提供了强大的处理器和 GPU。同样的，Tinker Board S 的大小恰巧和标准的树莓派3 一样大。

这个板子的主要亮点是 16 GB [eMMC](https://en.wikipedia.org/wiki/MultiMediaCard) （用外行术语说，它的板上有一个类似 SSD 的存储单元使它工作时运行的更快。） 的存在。

**关键参数：**

* Rockchip Quad-Core RK3288 processor
* 2 GB DDR3 RAM
* Integrated Graphics Processor
* ARM® Mali™-T764 GPU
* 16 GB eMMC
* MicroSD Card Slot
* 802.11 b/g/n, Bluetooth V4.0 + EDR
* USB 2.0
* 28 GPIO pins
* HDMI Interface

[查看网站](https://www.asus.com/in/Single-Board-Computer/Tinker-Board-S/)

#### 4、ClockworkPi

如果你正在想方设法组装一个模块化的复古的游戏控制台，Clockwork Pi 可能就是你需要的，它通常是 [GameShell Kit](https://itsfoss.com/gameshell-console/) 的一部分。然而，你可以 使用 $49 单独购买板子。

它紧凑的大小、WiFi 连接性和 micro HDMI 端口的存在使它成为许多方面的选择。

**关键参数：**

* Allwinner R16-J Quad-core Cortex-A7 CPU @1.2GHz
* Mali-400 MP2 GPU
* RAM: 1GB DDR3
* WiFi & Bluetooth v4.0
* Micro HDMI output
* MicroSD Card Slot

[查看官网](https://www.clockworkpi.com/product-page/cpi-v3-1)

#### 5、Arduino Mega 2560

如果你正在研究机器人项目或者你想要一个 3D 打印机 —— Arduino Mega 2560 将是树莓派的便利的替代品。不像树莓派，它是基于微控制器而不是微处理器的。

在他们的[官网](https://store.arduino.cc/usa/mega-2560-r3)，你需要花费 $38.50，或者在[在亚马逊商城是 $33](https://amzn.to/2KCi041)。

**关键参数：**

* Microcontroller: ATmega2560
* Clock Speed: 16 MHz
* Digital I/O Pins: 54
* Analog Input Pins: 16
* Flash Memory: 256 KB of which 8 KB used by bootloader

[查看官网](https://store.arduino.cc/usa/mega-2560-r3)

#### 6、Rock64 Media Board

用与你可能想要的树莓派 3 B+ 相同的价格，你将在 Rock64 Media Board 上获得更快的处理器和双倍的内存。除此之外，如果你想要 1 GB RAM 版的，它提供了一个比树莓派更便宜的替代品，花费更少，只要 $10 。

不像树莓派，它没有无线连接支持，但是 USB 3.0 和 HDMI 2.0 的存在使它与众不同，如果它对你很重要的话。

**关键参数：**

* Rockchip RK3328 Quad-Core ARM Cortex A53 64-Bit Processor
* Supports up to 4GB 1600MHz LPDDR3 RAM
* eMMC module socket
* MicroSD Card slot
* USB 3.0
* HDMI 2.0

[查看官网](https://www.pine64.org/?product=rock64-media-board-computer)

#### 7、Odroid-XU4

Odroid-XU4 是一个完美的树莓派的替代品，如果你有能够稍微提高预算的空间（$80-$100 甚至更低，取决于存储的容量）。

它确实是一个强大的替代品并且体积更小。支持 eMMC 和 USB 3.0 使它工作起来更快。

**关键参数：**

* Samsung Exynos 5422 Octa ARM Cortex™-A15 Quad 2Ghz and Cortex™-A7 Quad 1.3GHz CPUs
* 2Gbyte LPDDR3 RAM
* GPU: Mali-T628 MP6
* USB 3.0
* HDMI 1.4a
* eMMC 5.0 module socket
* MicroSD Card Slot

[查看官网](https://www.hardkernel.com/shop/odroid-xu4-special-price/)

#### 8、PocketBeagle

它是一个难以置信的小的单板机 —— 几乎和树莓派Zero 相似。然而它的价格相当于完整大小的树莓派 3。主要的亮点是你可以用它作为一个 USB 便携式信息终端，并且进入 Linux 命令行工作。

**关键参数：**

* Processor: Octavo Systems OSD3358 1GHz ARM® Cortex-A8
* RAM: 512 MB DDR3
* 72 expansion pin headers
* microUSB
* USB 2.0

[查看官网](https://beagleboard.org/p/products/pocketbeagle)

#### 9、Le Potato

由 [Libre Computer](https://libre.computer/) 出品的 Le Potato，其型号是 AML-S905X-CC。它需要花费你 [$45](https://amzn.to/2DpG3xl)。

如果你花费的比树莓派更多的钱，你就能得到双倍内存和 HDMI 2.0 接口，这可能是一个完美的选择。尽管，你还是不能找到嵌入的无线连接。

**关键参数：**

* Amlogic S905X SoC
* 2GB DDR3 SDRAM
* USB 2.0
* HDMI 2.0
* microUSB
* MicroSD Card Slot
* eMMC Interface

[查看官网](https://libre.computer/products/boards/aml-s905x-cc/)

#### 10、Banana Pi M64

它自带了 8G 的 eMMC —— 这是替代树莓派的主要亮点。因此，它需要花费 $60。

HDMI 接口的存在使它胜任 4K。除此之外，Banana Pi 提供了更多种类的开源单板机作为树莓派的替代。

**关键参数：**

* 1.2 Ghz Quad-Core ARM Cortex A53 64-Bit Processor-R18
* 2GB DDR3 SDRAM
* 8 GB eMMC
* WiFi & Bluetooth
* USB 2.0
* HDMI

[查看官网](http://www.banana-pi.org/m64.html)

#### 11、Orange Pi Zero

Orange Pi Zero 相对于树莓派来说难以置信的便宜。你可以在 Aliexpress 或者亚马逊上以最多 $10 就能够获得。如果[稍微多花点，你能够获得 512 MB RAM](https://amzn.to/2IlI81g)。

如果这还不够，你可以花费大概 $25 获得更好的配置，比如 Orange Pi 3。

**关键参数：**

* H2 Quad-core Cortex-A7
* Mali400MP2 GPU
* RAM: Up to 512 MB
* TF Card support
* WiFi
* USB 2.0

[查看官网](http://www.orangepi.org/orangepizero/index.html)

#### 12、VIM 2 SBC by Khadas

由 Khadas 出品的 VIM 2 是最新的单板机，因此你能够在板上得到蓝牙 5.0 支持。它的价格范围[从 $99 的基础款到上限 $140](https://amzn.to/2UDvrFE)。

基础款包含 2 GB RAM、16 GB eMMC 和蓝牙 4.1。然而，Pro/Max 版包含蓝牙 5.0，更多的内存，更多的 eMMC 存储。

**关键参数：**

* Amlogic S912 1.5GHz 64-bit Octa-Core CPU
* T820MP3 GPU
* Up to 3 GB DDR4 RAM
* Up to 64 GB eMMC
* Bluetooth 5.0 (Pro/Max)
* Bluetooth 4.1 (Basic)
* HDMI 2.0a
* WiFi

### 总结

我们知道有很多不同种类的单板机电脑。一些比树莓派更好 —— 它的一些小规格的版本有更便宜的价格。同样的，像 Jetson Nano 这样的单板机已经被裁剪用于特定用途。因此，取决于你需要什么 —— 你应该检查一下单板机的配置。

如果你知道比上述提到的更好的东西，请随意在下方评论来让我们知道。

---

via: <https://itsfoss.com/raspberry-pi-alternatives/>

作者：[Ankush Das](https://itsfoss.com/author/ankush/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[warmfrog](https://github.com/warmfrog) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


ping 多台服务器并在类似 top 的界面中显示

Summary: 它会一次 ping 多台服务器，并在类似 top 的终端 UI 中显示结果。

它会一次 ping 多台服务器，并在类似 top 的终端 UI 中显示结果。

# ping 多台服务器并在类似 top 的界面中显示

不久前，我们写了篇关于 [fping](https://www.ostechnix.com/ping-multiple-hosts-linux/) 的文章，该程序能使我们能够同时 ping 多台主机。与传统的 `ping` 不同，`fping` 不会等待一台主机的超时。它使用循环法，这表示它将 ICMP Echo 请求发送到一台主机，然后转到另一台主机，最后一次显示哪些主机开启或关闭。今天，我们将讨论一个名为 `pingtop` 的类似程序。顾名思义，它会一次 ping 多台服务器，并在类似 `top` 的终端 UI 中显示结果。它是用 Python 写的自由开源程序。

### 安装 pingtop

可以使用 `pip` 安装 `pingtop`，`pip` 是一个软件包管理器，用于安装用 Python 开发的程序。确保已在 Linux 中安装了 Python 3.7.x 和 pip。

要在 Linux 上安装 `pip`，请参阅以下链接。

* [如何使用 pip 管理 Python 包](/article-10110-1.html)

安装 `pip` 后，运行以下命令安装 `pingtop`：

```
$ pip install pingtop
```

现在让我们继续使用 `pingtop` ping 多个系统。

### ping 多台服务器并在类似 top 的终端 UI 中显示

要 ping 多个主机/系统，请运行：

```
$ pingtop ostechnix.com google.com facebook.com twitter.com
```

现在，你将在一个漂亮的类似 `top` 的终端 UI 中看到结果，如下所示。

*使用 pingtop ping 多台服务器*

建议阅读：

* [一些你可能想知道的替代 “top” 命令的程序](https://www.ostechnix.com/some-alternatives-to-top-command-line-utility-you-might-want-to-know/)

我个人目前没有使用 pingtop 的情况。但我喜欢在这个在文本界面中展示 ping 命令输出的想法。试试看它，也许有帮助。

就是这些了。还有更多好东西。敬请期待！干杯！

资源：

* [pingtop GitHub 仓库](https://github.com/laixintao/pingtop)

---

via: <https://www.ostechnix.com/ping-multiple-servers-and-show-the-output-in-top-like-text-ui/>

作者：[sk](https://www.ostechnix.com/author/sk/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


每日安全资讯：黑客集团内部是如何运作的？他们也有 CEO 和项目经理

# 每日安全资讯：黑客集团内部是如何运作的？他们也有 CEO 和项目经理

网络犯罪组织会为了争夺客户而相互竞争，会花重金招募最优秀的项目经理，甚至会寻找合适的人才来担任类似于首席执行官的角色，在规范管理人员配置和攻击事务之外负责如何帮助牟取更多的资金。来自IBM和谷歌的安全研究人员描述了网络犯罪组织内部是如何运作的，并且称它们经常会公司化运作。

IBM Security 威胁情报主管 Caleb Barlow 表示：“我们观察到他们也有比较严明的纪律，在办公时间里很活跃，他们也会在周末休息，他们也会定时工作，他们也会休假。它们会以公司化进行运作，会有一个老板全权管理所有攻击行为。它们就像是你雇佣装修公司一样，它们有着很多的分包商，就像是水电工、木工和油漆工一样，它们也和你一样正常上下班。”

Barlow 表示了解恶意黑客如何构建和运营其业务非常重要，而公司化可以更好地掌握他们正在攻击的任务。虽然并非所有网络犯罪组织都完全相同，但大体结构应该是这样的：领导者，例如 CEO，会监督整个组织的更广泛目标。而他或者她会雇佣和领导诸多“项目经理”，而每个项目经理负责每次网络攻击的不同部分。

恶意软件的攻击者可能首先购买或创建有针对性的攻击工具，以窃取集团所需的确切信息。另一位攻击者可能会发送欺诈性电子邮件，将恶意软件发送给目标公司。一旦软件成功交付，第三位攻击者可能会努力扩大集团在目标公司内的访问权限，并寻求可以在暗网上进行销售的相关信息。

IBM 还提供了一张信息图，展示了从犯罪集团的角度，如何发起为期 120 天针对一家财富 500 强公司的真实案例。负责 IBM X-Force 业务安全事件响应的 Christopher Scott 表示称在这种情况下，对财富 500 强企业的攻击意味着窃取和破坏数据，不同的颜色大致代表不同的工作职能。

<img src="content_image/album_201905_07_110643e88plaw67xe8elzr.jpg" alt="" title="">

在图形的左侧，专门破坏公司网络的攻击者以自己的方式进入业务以获得立足点。其他“项目经理”通过窃取他们的凭证来破坏各种员工帐户，并使用这些帐户执行该计划中的不同任务，从访问敏感区域或收集信息。时间线上的差距代表了黑客停止进行某些活动的时期，因此他们不会将公司用来检测犯罪活动的传感器干扰。

在 120 天周期尾声的时候，以鲜红色为代表的黑客专家最终画上句号，使用不同的恶意代码来破坏公司的各种数据。隶属于 Alphabet 集团“Other Bet”下方，专门从事网络安全的 Chronicle 公司研究主任 Juan Andres Guerrero-Saade 解释称：“如果我是一名优秀的开发人员，那么我会选择创建勒索软件并将其出售，或者将其像那些提供 software-as-a-service 的公司一样作为服务出售。然后我会不断维护这款恶意软件，如果你找到受害者并让他们受到感染支付赎金，那么我将收取 10％ 或 20％ 的分成。”

来源：cnBeta.COM

### 更多资讯

##### Mozilla 修复附加组件问题 同时警告用户不要尝试“可疑的解决方法”

Mozilla 今天推出了 Firefox 66.0.4，解决了因为证书问题导致的附加组件无法在 Firefox 浏览器中工作的问题。周五，过期的安全证书令全球的 Firefox 用户感到困惑，因为扩展被禁用并变得无法使用。Mozilla 现在发布了一个浏览器更新，并且“正在积极努力解决剩下的问题”。

来源： cnBeta.COM

详情： <http://t.cn/EotsFEc>

##### 爱彼迎民宿路由器暗藏摄像头：官方回应已移除房源

5 月 5 日下午，有媒体报道称，在山东青岛一家爱彼迎（Airbnb）的民宿中，住客在无线路由器内发现了隐藏的摄像头和存储卡，拍摄方向正对卧室。5 日晚间，爱彼迎公关人员对此正式回应称，爱彼迎十分重视隐私保护，对任何侵犯隐私的行为都秉持零容忍态度，目前平台方已经永久性移除涉事房源。

来源： 快科技

详情： <http://t.cn/Eocv7vE>

##### 来电显示暗藏黑色利益链 你的号码被“标注”了吗？

2015 年 8 月的一天，刘子倩用打车软件叫了一辆车，刚刚上车，他就被司机识破了身份。原来，司机手机上的一款来电号码识别软件，把刘子倩的身份信息标注为“记者”。当刘子倩拨通司机电话时，他的身份信息就已经泄露了。

来源： 法制日报
详情： <http://t.cn/Eocvwx0>

##### 北京将实现水电气热大数据共享，严防数据丢失、泄露

《北京市公共数据管理办法》日前面向公众开征意见。记者获悉，北京将建设市、区两级大数据管理平台，目前已有11.5亿条数据在市级大数据管理平台汇聚。未来，对于无条件共享的数据，数据需求单位可通过市区两级大数据平台直接获取；对于有条件共享的数据，数据需求单位应根据提供单位的授权获取共享数据。

来源： 北京日报

详情： <http://t.cn/EocvLOR>

（信息来源于网络，安华金和搜集整理）


Linux 下的进程间通信：共享存储

Summary: 学习在 Linux 中进程是如何与其他进程进行同步的。

讲解的不错

来自美国的 Internet Explorer 11.0|Windows 7 用户

很好，但要是 python 代码理解会更容易些

python没有c快呀，底层谁用解释语言呀

来自223.104.186.141的 MIUI Browser 10.8|Android 用户

学习在 Linux 中进程是如何与其他进程进行同步的。

# Linux 下的进程间通信：共享存储

>
> 学习在 Linux 中进程是如何与其他进程进行同步的。
>
>
>

<img src="content_image/album_201905_07_122555by525iisnxnckyry.jpg" alt="" title="">

本篇是 Linux 下[进程间通信](https://en.wikipedia.org/wiki/Inter-process_communication)（IPC）系列的第一篇文章。这个系列将使用 C 语言代码示例来阐明以下 IPC 机制：

* 共享文件
* 共享内存（使用信号量）
* 管道（命名的或非命名的管道）
* 消息队列
* 套接字
* 信号

在聚焦上面提到的共享文件和共享内存这两个机制之前，这篇文章将带你回顾一些核心的概念。

### 核心概念

*进程*是运行着的程序，每个进程都有着它自己的地址空间，这些空间由进程被允许访问的内存地址组成。进程有一个或多个执行*线程*，而线程是一系列执行指令的集合：*单线程*进程就只有一个线程，而*多线程*的进程则有多个线程。一个进程中的线程共享各种资源，特别是地址空间。另外，一个进程中的线程可以直接通过共享内存来进行通信，尽管某些现代语言（例如 Go）鼓励一种更有序的方式，例如使用线程安全的通道。当然对于不同的进程，默认情况下，它们**不**能共享内存。

有多种方法启动之后要进行通信的进程，下面所举的例子中主要使用了下面的两种方法：

* 一个终端被用来启动一个进程，另外一个不同的终端被用来启动另一个。
* 在一个进程（父进程）中调用系统函数 `fork`，以此生发另一个进程（子进程）。

第一个例子采用了上面使用终端的方法。这些[代码示例](http://condor.depaul.edu/mkalin)的 ZIP 压缩包可以从我的网站下载到。

### 共享文件

程序员对文件访问应该都已经很熟识了，包括许多坑（不存在的文件、文件权限损坏等等），这些问题困扰着程序对文件的使用。尽管如此，共享文件可能是最为基础的 IPC 机制了。考虑一下下面这样一个相对简单的例子，其中一个进程（生产者 `producer`）创建和写入一个文件，然后另一个进程（消费者 `consumer`）从这个相同的文件中进行读取：

```
          writes +-----------+ reads
producer-------->| disk file |<-------consumer
                 +-----------+
```

在使用这个 IPC 机制时最明显的挑战是*竞争条件*可能会发生：生产者和消费者可能恰好在同一时间访问该文件，从而使得输出结果不确定。为了避免竞争条件的发生，该文件在处于*读*或*写*状态时必须以某种方式处于被锁状态，从而阻止在*写*操作执行时和其他操作的冲突。在标准系统库中与锁相关的 API 可以被总结如下：

* 生产者应该在写入文件时获得一个文件的排斥锁。一个*排斥*锁最多被一个进程所拥有。这样就可以排除掉竞争条件的发生，因为在锁被释放之前没有其他的进程可以访问这个文件。
* 消费者应该在从文件中读取内容时得到至少一个共享锁。多个*读取者*可以同时保有一个*共享*锁，但是没有*写入者*可以获取到文件内容，甚至在当只有一个*读取者*保有一个共享锁时。

共享锁可以提升效率。假如一个进程只是读入一个文件的内容，而不去改变它的内容，就没有什么原因阻止其他进程来做同样的事。但如果需要写入内容，则很显然需要文件有排斥锁。

标准的 I/O 库中包含一个名为 `fcntl` 的实用函数，它可以被用来检查或者操作一个文件上的排斥锁和共享锁。该函数通过一个*文件描述符*（一个在进程中的非负整数值）来标记一个文件（在不同的进程中不同的文件描述符可能标记同一个物理文件）。对于文件的锁定， Linux 提供了名为 `flock` 的库函数，它是 `fcntl` 的一个精简包装。第一个例子中使用 `fcntl` 函数来暴露这些 API 细节。

#### 示例 1. 生产者程序

```
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

#define FileName "data.dat"
#define DataString "Now is the winter of our discontent\nMade glorious summer by this sun of York\n"

void report_and_exit(const char* msg) {
  perror(msg);
  exit(-1); /* EXIT_FAILURE */
}

int main() {
  struct flock lock;
  lock.l_type = F_WRLCK;    /* read/write (exclusive versus shared) lock */
  lock.l_whence = SEEK_SET; /* base for seek offsets */
  lock.l_start = 0;         /* 1st byte in file */
  lock.l_len = 0;           /* 0 here means 'until EOF' */
  lock.l_pid = getpid();    /* process id */

  int fd; /* file descriptor to identify a file within a process */
  if ((fd = open(FileName, O_RDWR | O_CREAT, 0666)) < 0)  /* -1 signals an error */
    report_and_exit("open failed...");

  if (fcntl(fd, F_SETLK, &lock) < 0) /** F_SETLK doesn't block, F_SETLKW does **/
    report_and_exit("fcntl failed to get lock...");
  else {
    write(fd, DataString, strlen(DataString)); /* populate data file */
    fprintf(stderr, "Process %d has written to data file...\n", lock.l_pid);
  }

  /* Now release the lock explicitly. */
  lock.l_type = F_UNLCK;
  if (fcntl(fd, F_SETLK, &lock) < 0)
    report_and_exit("explicit unlocking failed...");

  close(fd); /* close the file: would unlock if needed */
  return 0;  /* terminating the process would unlock as well */
}

```

上面生产者程序的主要步骤可以总结如下：

* 这个程序首先声明了一个类型为 `struct flock` 的变量，它代表一个锁，并对它的 5 个域做了初始化。第一个初始化

```
lock.l_type = F_WRLCK; /* exclusive lock */
```

使得这个锁为排斥锁（read-write）而不是一个共享锁（read-only）。假如生产者获得了这个锁，则其他的进程将不能够对文件做读或者写操作，直到生产者释放了这个锁，或者显式地调用 `fcntl`，又或者隐式地关闭这个文件。（当进程终止时，所有被它打开的文件都会被自动关闭，从而释放了锁）
* 上面的程序接着初始化其他的域。主要的效果是*整个*文件都将被锁上。但是，有关锁的 API 允许特别指定的字节被上锁。例如，假如文件包含多个文本记录，则单个记录（或者甚至一个记录的一部分）可以被锁，而其余部分不被锁。
* 第一次调用 `fcntl`

```
if (fcntl(fd, F_SETLK, &lock) < 0)
```

尝试排斥性地将文件锁住，并检查调用是否成功。一般来说， `fcntl` 函数返回 `-1` （因此小于 0）意味着失败。第二个参数 `F_SETLK` 意味着 `fcntl` 的调用*不是*堵塞的；函数立即做返回，要么获得锁，要么显示失败了。假如替换地使用 `F_SETLKW`（末尾的 `W` 代指*等待*），那么对 `fcntl` 的调用将是阻塞的，直到有可能获得锁的时候。在调用 `fcntl` 函数时，它的第一个参数 `fd` 指的是文件描述符，第二个参数指定了将要采取的动作（在这个例子中，`F_SETLK` 指代设置锁），第三个参数为锁结构的地址（在本例中，指的是 `&lock`）。
* 假如生产者获得了锁，这个程序将向文件写入两个文本记录。
* 在向文件写入内容后，生产者改变锁结构中的 `l_type` 域为 `unlock` 值：

```
lock.l_type = F_UNLCK;
```

并调用 `fcntl` 来执行解锁操作。最后程序关闭了文件并退出。

#### 示例 2. 消费者程序

```
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

#define FileName "data.dat"

void report_and_exit(const char* msg) {
  perror(msg);
  exit(-1); /* EXIT_FAILURE */
}

int main() {
  struct flock lock;
  lock.l_type = F_WRLCK;    /* read/write (exclusive) lock */
  lock.l_whence = SEEK_SET; /* base for seek offsets */
  lock.l_start = 0;         /* 1st byte in file */
  lock.l_len = 0;           /* 0 here means 'until EOF' */
  lock.l_pid = getpid();    /* process id */

  int fd; /* file descriptor to identify a file within a process */
  if ((fd = open(FileName, O_RDONLY)) < 0)  /* -1 signals an error */
    report_and_exit("open to read failed...");

  /* If the file is write-locked, we can't continue. */
  fcntl(fd, F_GETLK, &lock); /* sets lock.l_type to F_UNLCK if no write lock */
  if (lock.l_type != F_UNLCK)
    report_and_exit("file is still write locked...");

  lock.l_type = F_RDLCK; /* prevents any writing during the reading */
  if (fcntl(fd, F_SETLK, &lock) < 0)
    report_and_exit("can't get a read-only lock...");

  /* Read the bytes (they happen to be ASCII codes) one at a time. */
  int c; /* buffer for read bytes */
  while (read(fd, &c, 1) > 0)    /* 0 signals EOF */
    write(STDOUT_FILENO, &c, 1); /* write one byte to the standard output */

  /* Release the lock explicitly. */
  lock.l_type = F_UNLCK;
  if (fcntl(fd, F_SETLK, &lock) < 0)
    report_and_exit("explicit unlocking failed...");

  close(fd);
  return 0;
}
```

相比于锁的 API，消费者程序会相对复杂一点儿。特别的，消费者程序首先检查文件是否被排斥性的被锁，然后才尝试去获得一个共享锁。相关的代码为：

```
lock.l_type = F_WRLCK;
...
fcntl(fd, F_GETLK, &lock); /* sets lock.l_type to F_UNLCK if no write lock */
if (lock.l_type != F_UNLCK)
  report_and_exit("file is still write locked...");
```

在 `fcntl` 调用中的 `F_GETLK` 操作指定检查一个锁，在本例中，上面代码的声明中给了一个 `F_WRLCK` 的排斥锁。假如特指的锁不存在，那么 `fcntl` 调用将会自动地改变锁类型域为 `F_UNLCK` 以此来显示当前的状态。假如文件是排斥性地被锁，那么消费者将会终止。（一个更健壮的程序版本或许应该让消费者*睡*会儿，然后再尝试几次。）

假如当前文件没有被锁，那么消费者将尝试获取一个共享（read-only）锁（`F_RDLCK`）。为了缩短程序，`fcntl` 中的 `F_GETLK` 调用可以丢弃，因为假如其他进程已经保有一个读写锁，`F_RDLCK` 的调用就可能会失败。重新调用一个只读锁能够阻止其他进程向文件进行写的操作，但可以允许其他进程对文件进行读取。简而言之，共享锁可以被多个进程所保有。在获取了一个共享锁后，消费者程序将立即从文件中读取字节数据，然后在标准输出中打印这些字节的内容，接着释放锁，关闭文件并终止。

下面的 `%` 为命令行提示符，下面展示的是从相同终端开启这两个程序的输出：

```
% ./producer
Process 29255 has written to data file...

% ./consumer
Now is the winter of our discontent
Made glorious summer by this sun of York
```

在本次的代码示例中，通过 IPC 传输的数据是文本：它们来自莎士比亚的戏剧《理查三世》中的两行台词。然而，共享文件的内容还可以是纷繁复杂的，任意的字节数据（例如一个电影）都可以，这使得文件共享变成了一个非常灵活的 IPC 机制。但它的缺点是文件获取速度较慢，因为文件的获取涉及到读或者写。同往常一样，编程总是伴随着折中。下面的例子将通过共享内存来做 IPC，而不是通过共享文件，在性能上相应的有极大的提升。

### 共享内存

对于共享内存，Linux 系统提供了两类不同的 API：传统的 System V API 和更新一点的 POSIX API。在单个应用中，这些 API 不能混用。但是，POSIX 方式的一个坏处是它的特性仍在发展中，并且依赖于安装的内核版本，这非常影响代码的可移植性。例如，默认情况下，POSIX API 用*内存映射文件*来实现共享内存：对于一个共享的内存段，系统为相应的内容维护一个*备份文件*。在 POSIX 规范下共享内存可以被配置为不需要备份文件，但这可能会影响可移植性。我的例子中使用的是带有备份文件的 POSIX API，这既结合了内存获取的速度优势，又获得了文件存储的持久性。

下面的共享内存例子中包含两个程序，分别名为 `memwriter` 和 `memreader`，并使用*信号量*来调整它们对共享内存的获取。在任何时候当共享内存进入一个*写入者*场景时，无论是多进程还是多线程，都有遇到基于内存的竞争条件的风险，所以，需要引入信号量来协调（同步）对共享内存的获取。

`memwriter` 程序应当在它自己所处的终端首先启动，然后 `memreader` 程序才可以在它自己所处的终端启动（在接着的十几秒内）。`memreader` 的输出如下：

```
This is the way the world ends...
```

在每个源程序的最上方注释部分都解释了在编译它们时需要添加的链接参数。

首先让我们复习一下信号量是如何作为一个同步机制工作的。一般的信号量也被叫做一个*计数信号量*，因为带有一个可以增加的值（通常初始化为 0）。考虑一家租用自行车的商店，在它的库存中有 100 辆自行车，还有一个供职员用于租赁的程序。每当一辆自行车被租出去，信号量就增加 1；当一辆自行车被还回来，信号量就减 1。在信号量的值为 100 之前都还可以进行租赁业务，但如果等于 100 时，就必须停止业务，直到至少有一辆自行车被还回来，从而信号量减为 99。

*二元信号量*是一个特例，它只有两个值：0 和 1。在这种情况下，信号量的表现为*互斥量*（一个互斥的构造）。下面的共享内存示例将把信号量用作互斥量。当信号量的值为 0 时，只有 `memwriter` 可以获取共享内存，在写操作完成后，这个进程将增加信号量的值，从而允许 `memreader` 来读取共享内存。

#### 示例 3. memwriter 进程的源程序

```
/** Compilation: gcc -o memwriter memwriter.c -lrt -lpthread **/
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <semaphore.h>
#include <string.h>
#include "shmem.h"

void report_and_exit(const char* msg) {
  perror(msg);
  exit(-1);
}

int main() {
  int fd = shm_open(BackingFile,      /* name from smem.h */
                    O_RDWR | O_CREAT, /* read/write, create if needed */
                    AccessPerms);     /* access permissions (0644) */
  if (fd < 0) report_and_exit("Can't open shared mem segment...");

  ftruncate(fd, ByteSize); /* get the bytes */

  caddr_t memptr = mmap(NULL,       /* let system pick where to put segment */
                        ByteSize,   /* how many bytes */
                        PROT_READ | PROT_WRITE, /* access protections */
                        MAP_SHARED, /* mapping visible to other processes */
                        fd,         /* file descriptor */
                        0);         /* offset: start at 1st byte */
  if ((caddr_t) -1  == memptr) report_and_exit("Can't get segment...");

  fprintf(stderr, "shared mem address: %p [0..%d]\n", memptr, ByteSize - 1);
  fprintf(stderr, "backing file:       /dev/shm%s\n", BackingFile );

  /* semaphore code to lock the shared mem */
  sem_t* semptr = sem_open(SemaphoreName, /* name */
                           O_CREAT,       /* create the semaphore */
                           AccessPerms,   /* protection perms */
                           0);            /* initial value */
  if (semptr == (void*) -1) report_and_exit("sem_open");

  strcpy(memptr, MemContents); /* copy some ASCII bytes to the segment */

  /* increment the semaphore so that memreader can read */
  if (sem_post(semptr) < 0) report_and_exit("sem_post");

  sleep(12); /* give reader a chance */

  /* clean up */
  munmap(memptr, ByteSize); /* unmap the storage */
  close(fd);
  sem_close(semptr);
  shm_unlink(BackingFile); /* unlink from the backing file */
  return 0;
}
```

下面是 `memwriter` 和 `memreader` 程序如何通过共享内存来通信的一个总结：

* 上面展示的 `memwriter` 程序调用 `shm_open` 函数来得到作为系统协调共享内存的备份文件的文件描述符。此时，并没有内存被分配。接下来调用的是令人误解的名为 `ftruncate` 的函数

```
ftruncate(fd, ByteSize); /* get the bytes */
```

它将分配 `ByteSize` 字节的内存，在该情况下，一般为大小适中的 512 字节。`memwriter` 和 `memreader` 程序都只从共享内存中获取数据，而不是从备份文件。系统将负责共享内存和备份文件之间数据的同步。
* 接着 `memwriter` 调用 `mmap` 函数：

```
caddr_t memptr = mmap(NULL, /* let system pick where to put segment */
                  ByteSize, /* how many bytes */
                  PROT_READ | PROT_WRITE, /* access protections */
                  MAP_SHARED, /* mapping visible to other processes */
                  fd, /* file descriptor */
                  0); /* offset: start at 1st byte */
```

来获得共享内存的指针。（`memreader` 也做一次类似的调用。） 指针类型 `caddr_t` 以 `c` 开头，它代表 `calloc`，而这是动态初始化分配的内存为 0 的一个系统函数。`memwriter` 通过库函数 `strcpy`（字符串复制）来获取后续*写*操作的 `memptr`。
* 到现在为止，`memwriter` 已经准备好进行写操作了，但首先它要创建一个信号量来确保共享内存的排斥性。假如 `memwriter` 正在执行写操作而同时 `memreader` 在执行读操作，则有可能出现竞争条件。假如调用 `sem_open` 成功了：

```
sem_t* semptr = sem_open(SemaphoreName, /* name */
                     O_CREAT, /* create the semaphore */
                     AccessPerms, /* protection perms */
                     0); /* initial value */
```

那么，接着写操作便可以执行。上面的 `SemaphoreName`（任意一个唯一的非空名称）用来在 `memwriter` 和 `memreader` 识别信号量。初始值 0 将会传递给信号量的创建者，在这个例子中指的是 `memwriter` 赋予它执行*写*操作的权利。
* 在写操作完成后，`memwriter* 通过调用`sem\_post` 函数将信号量的值增加到 1：

```
if (sem_post(semptr) < 0) ..
```

增加信号了将释放互斥锁，使得 `memreader` 可以执行它的*读*操作。为了更好地测量，`memwriter` 也将从它自己的地址空间中取消映射，

```
munmap(memptr, ByteSize); /* unmap the storage *
```

这将使得 `memwriter` 不能进一步地访问共享内存。

#### 示例 4. memreader 进程的源代码

```
/** Compilation: gcc -o memreader memreader.c -lrt -lpthread **/
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <semaphore.h>
#include <string.h>
#include "shmem.h"

void report_and_exit(const char* msg) {
  perror(msg);
  exit(-1);
}

int main() {
  int fd = shm_open(BackingFile, O_RDWR, AccessPerms);  /* empty to begin */
  if (fd < 0) report_and_exit("Can't get file descriptor...");

  /* get a pointer to memory */
  caddr_t memptr = mmap(NULL,       /* let system pick where to put segment */
                        ByteSize,   /* how many bytes */
                        PROT_READ | PROT_WRITE, /* access protections */
                        MAP_SHARED, /* mapping visible to other processes */
                        fd,         /* file descriptor */
                        0);         /* offset: start at 1st byte */
  if ((caddr_t) -1 == memptr) report_and_exit("Can't access segment...");

  /* create a semaphore for mutual exclusion */
  sem_t* semptr = sem_open(SemaphoreName, /* name */
                           O_CREAT,       /* create the semaphore */
                           AccessPerms,   /* protection perms */
                           0);            /* initial value */
  if (semptr == (void*) -1) report_and_exit("sem_open");

  /* use semaphore as a mutex (lock) by waiting for writer to increment it */
  if (!sem_wait(semptr)) { /* wait until semaphore != 0 */
    int i;
    for (i = 0; i < strlen(MemContents); i++)
      write(STDOUT_FILENO, memptr + i, 1); /* one byte at a time */
    sem_post(semptr);
  }

  /* cleanup */
  munmap(memptr, ByteSize);
  close(fd);
  sem_close(semptr);
  unlink(BackingFile);
  return 0;
}
```

`memwriter` 和 `memreader` 程序中，共享内存的主要着重点都在 `shm_open` 和 `mmap` 函数上：在成功时，第一个调用返回一个备份文件的文件描述符，而第二个调用则使用这个文件描述符从共享内存段中获取一个指针。它们对 `shm_open` 的调用都很相似，除了 `memwriter` 程序创建共享内存，而 `memreader 只获取这个已经创建的内存：

```
int fd = shm_open(BackingFile, O_RDWR | O_CREAT, AccessPerms); /* memwriter */
int fd = shm_open(BackingFile, O_RDWR, AccessPerms); /* memreader */
```

有了文件描述符，接着对 `mmap` 的调用就是类似的了：

```
caddr_t memptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
```

`mmap` 的第一个参数为 `NULL`，这意味着让系统自己决定在虚拟内存地址的哪个地方分配内存，当然也可以指定一个地址（但很有技巧性）。`MAP_SHARED` 标志着被分配的内存在进程中是共享的，最后一个参数（在这个例子中为 0 ） 意味着共享内存的偏移量应该为第一个字节。`size` 参数特别指定了将要分配的字节数目（在这个例子中是 512）；另外的保护参数（`AccessPerms`）暗示着共享内存是可读可写的。

当 `memwriter` 程序执行成功后，系统将创建并维护备份文件，在我的系统中，该文件为 `/dev/shm/shMemEx`，其中的 `shMemEx` 是我为共享存储命名的（在头文件 `shmem.h` 中给定）。在当前版本的 `memwriter` 和 `memreader` 程序中，下面的语句

```
shm_unlink(BackingFile); /* removes backing file */
```

将会移除备份文件。假如没有 `unlink` 这个语句，则备份文件在程序终止后仍然持久地保存着。

`memreader` 和 `memwriter` 一样，在调用 `sem_open` 函数时，通过信号量的名字来获取信号量。但 `memreader` 随后将进入等待状态，直到 `memwriter` 将初始值为 0 的信号量的值增加。

```
if (!sem_wait(semptr)) { /* wait until semaphore != 0 */
```

一旦等待结束，`memreader` 将从共享内存中读取 ASCII 数据，然后做些清理工作并终止。

共享内存 API 包括显式地同步共享内存段和备份文件。在这次的示例中，这些操作都被省略了，以免文章显得杂乱，好让我们专注于内存共享和信号量的代码。

即便在信号量代码被移除的情况下，`memwriter` 和 `memreader` 程序很大几率也能够正常执行而不会引入竞争条件：`memwriter` 创建了共享内存段，然后立即向它写入；`memreader` 不能访问共享内存，直到共享内存段被创建好。然而，当一个*写操作*处于混合状态时，最佳实践需要共享内存被同步。信号量 API 足够重要，值得在代码示例中着重强调。

### 总结

上面共享文件和共享内存的例子展示了进程是怎样通过*共享存储*来进行通信的，前者通过文件而后者通过内存块。这两种方法的 API 相对来说都很直接。这两种方法有什么共同的缺点吗？现代的应用经常需要处理流数据，而且是非常大规模的数据流。共享文件或者共享内存的方法都不能很好地处理大规模的流数据。按照类型使用管道会更加合适一些。所以这个系列的第二部分将会介绍管道和消息队列，同样的，我们将使用 C 语言写的代码示例来辅助讲解。

---

via: <https://opensource.com/article/19/4/interprocess-communication-linux-storage>

作者：[Marty Kalin](https://opensource.com/users/mkalindepauledu) 选题：[lujun9972](https://github.com/lujun9972) 译者：[FSSlc](https://github.com/FSSlc) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


红帽发布企业版 Linux（RHEL） 8.0

Summary: 红帽 今天宣布，其企业 Linux （RHEL）发布了最新版本 8.0。“对于在任何环境中运行的任何工作负载，红帽企业 Linux 8 提供一种企业级 Linux 的体验，以满足不断发展的企业的独特技术需求。”

# 红帽发布企业版 Linux（RHEL） 8.0

红帽 [今日宣布](https://www.redhat.com/en/about/press-releases/red-hat-enterprise-linux-8-every-enterprise-every-cloud-every-workload)，其[企业 Linux （RHEL）](https://www.redhat.com/en/enterprise-linux-8)发布了最新版本 8.0。“对于在任何环境中运行的任何工作负载，红帽企业 Linux 8 提供一种企业级 Linux 的体验，以满足不断发展的企业的独特技术需求。”

红帽企业 Linux 总裁兼总经理 Stefanie Chiras 说：“跨越整个混合云，这个世界领先的企业 Linux 平台为 IT 组织提供了一剂催化剂，它不仅能够应对当今的挑战，还能做更多的事情。它为他们提供了创建自己未来的基础和工具，无论他们想要什么。”

红帽企业 Linux 8 是针对混合云时代重新设计的操作系统，旨在支持从企业数据中心到多个公共云的工作负载和操作。随着混合云和多云部署的重要性不断增长，操作系统也必须不断发展。根据 [IDC 2018 年 9 月的一份报告](https://www.idc.com/getdoc.jsp?containerId=US44305818)，70％ 的客户已经部署了多云环境，当今典型 IT 产品组合中 64％ 的应用程序都基于云环境，无论是公有云还是私有云。

红帽企业 Linux 一直被认为是应用程序最稳定、最安全的基础设施。但是，在过去很难获得开发人员想要的最新语言和框架，而不会影响稳定性。红帽企业 Linux 8 引入了<ruby> 应用程序流 <rp>  （ </rp> <rt>  Application Streams </rt> <rp>  ） </rp></ruby> ——在此流中会经常更新快速变化的语言、框架和开发人员工具，而不会影响红帽企业 Linux 作为企业基准的核心资源。这样可以在单一的企业级操作系统中实现更快的开发人员创新和生产稳定性。

红帽企业 Linux 8 抽象出了红帽企业 Linux Web 控制台背后的粒度系统管理员任务的许多深层复杂性。该控制台提供直观、一致的图形界面，用于管理和监控红帽企业 Linux 系统，从虚拟机的运行状况到整体系统性能。为了进一步提高易用性，红帽企业 Linux 支持就地升级，为用户将红帽企业 Linux 7 实例转换为红帽企业 Linux 8 系统提供了更加简化、高效和及时的途径。

红帽企业 Linux 8 还包括了红帽企业 Linux <ruby> 系统角色 <rp>  （ </rp> <rt>  System Role </rt> <rp>  ） </rp></ruby>，它可以自动完成许多关于在生产中管理和配置 Linux 的更复杂任务。系统角色由 Red Hat Ansible Automation 提供支持，它是预先配置的 Ansible 模块，支持现成的自动化工作流程，用于处理常见的复杂系统管理员任务。这种自动化使新系统管理员更容易采用 Linux，并有助于消除导致常见配置问题的人为错误。

为了增强安全性，红帽企业 Linux 8 支持 OpenSSL 1.1.1 和 TLS 1.3 加密标准。这提供了对加密保护中最强大的最新标准的访问，这些标准可以通过单个命令在系统范围内实现，从而限制了对特定于应用程序的策略和调优的需求。

从红帽 OpenShift 4 和即将推出的红帽 OpenStack Platform 15，红帽企业 Linux 8 构成了红帽整个混合云产品组合的基础。同样基于红帽企业 Linux 8 构建的是即将推出的红帽企业 Linux CoreOS 系统旨在托管 Red Hat OpenShift 部署。

红帽企业 Linux 8 的推出也与<ruby>   红帽通用基础映像  <rp>  （ </rp> <rt>  Red Hat Universal Base Image </rt> <rp>  ） </rp></ruby>的普遍可用性相吻合，红帽通用基础映像是一个源自红帽企业 Linux 的用户空间映像，用于构建经过红帽认证的 Linux 容器。使用它构建的应用程序可以在任何地方运行。


大家都在点赞 Windows Terminal，我决定给你泼一盆冷水

Summary: 在我看到一时间出现的很多文章，都视 Windows Terminal 为 Windows 下命令行体验的救世主之后，我觉得，是时候泼一盆冷水降降温了。

好酸啊

来自四川成都的 Chrome Mobile 74.0|Android 8.1 用户

这种垃圾文章还好意思说自己是windows开发？ 路边摊学的吧？ ps用的还不是最新版本。这么牛你咋不上天呢？

哈哈，虽然我是做运维的，但其实我是微软阵营的，哈哈，怎么说呢，有吐槽才有进步嘛，哈哈，很显示这个作者是linux阵营的，所以，难免会有泼冷水的作法，哈哈

完全没看出来哪里酸了。

这是什么屁话，水平跟用的软件版本有关系吗？？？

来自湖北武汉武汉大学测绘学院的 Firefox 66.0|Windows 10 用户

你们这定位显示的太6了

部分赞同文章的观点。微信那边吵的太激烈了，我就不掺和了。在这边留言希望作者能看到。

1. 官方的terminal确实没有什么太值得说道的，很多叫好的人也许只是没分清terminal和shell的区别，不过有理由相信官方出的兼容性会更好，并且有持续更新；

2. powershell和cmd共同存在的问题，支持的字体限制很大(参考 知乎/question/36344262/answer/67191917)，unicode字符支持不足。据说新的terminal里这些问题都已经解决，具体要等待实际使用后才能知道；

3. cmd语法确实反人类，但powershell有可取之处，比如通过管道传递的是对象，可以轻松筛

如果直接支持bash不知道有没有知识产权的问题。

我装完试了一下,只是感觉更漂亮了点,然并卵,吹得很好,看最后发布能是个什么样,因为现在没有wsl2配合使用.windows terminal本身就应该当成linuxshell来使用才值的夸,目前看不到

win7不能用差评。

powershell5.0开始支持对象, 现在的6.2跟之前的3, 4比起来有很多新特性.

wsl上次更新是2017年，可以看出来wsl2也只是重新开坑。

拜托微软把上个坑填上啊

来自湖北武汉武汉大学测绘学院的 Microsoft Edge 17.17134|Windows 10 用户

槽点太多了。。。

> 它也只是一个终端而已，而不是一个更加好用的 Shell

本来就是终端啊，他也没说自己是 Shell 啊，要不然怎么叫 Windows Terminal

> 这种第三方就可以做好的事情，微软官方的进入不过是在现有的命令行生态下提供更多的一种选择，而不是真正的问题解决方案。

你要是用过这些个第三方终端就知道他们的问题很多，并没有解决之前的 cmd.exe 以及 powershell.exe 的痛点，他们只是好看而已，真的只是好看而已

> Windows 用户所吐槽的命令行不好用不在于其表面，而在于其没有一个足够好用的 Shell

并不是所有的用户都认

看一下我的坐标,你这坐标显示应该是拿到user-agent和client IP吧

文章论点，较高，很有预见性，点赞

我的定位呢

查看坐标~

不认同博主的“干脆提供 Bash”的观点。Powershell 很好用。

虽然 pwsh 体验上，距离 linux 工具链还有差距。但是 pwsh 生态也在逐渐建立。比如最常用的 posh-git。还有比较 geek 的 oh-my-posh。

微软提供的 pwsh 现在底子给的挺好了。能不能用好，我觉得还是看用的人。

就算 Powershell 不好用。我也不能认同“直接拿某某软件替代”，这种想法。因为按照这个想法，那干脆用 linux 好了。为什么要用 Windows 呢

另外再补充一下，wt 真的完爆 cmder 和 hyper

定位

定位

一看你对 PowerShell  发的牢骚就知道你一定不了解 PowerShell

定位

windows的bat脚本和Unix的sh脚本，我相信他们都能完成在各自系统下的应有的功能。我是个半桶水，不能全面的了解。但就目前来说，我还是对Unix的shell更熟悉些。除了脚本之外，以上的应用终端，无非就是调用系统的脚本命令、可执行文件，界面上的美化，功能上的扩展，这个扩展并不是脚本功能上的扩展。所以Windows Terminal的定位很清晰，就是打造一个这样的一个终端，而不是从底层扩展脚本的功能

只想有个一站式体验的terminal

wt如何自定义aws或者putty等等

一看这个标题就是典型的蹭热度，首先Powershell和bash等完全就是两种设计理念。linux簇拥者们天天吹着命令简介好输入，但是想没想过记起来难记？而Powershell则完全采用另一种做法，所有命令由动词和名词组成，记起来非常好记。输入虽然麻烦一点，但是同样可以使用自动补全来加速，最关键的是Powershell命令一看就能打开明白这是干啥的。当然你要说Powershell管道传递的都是对象，加剧了耦合性，和现有的linux工具水土不服，这我倒是完全同意。最后一点就是我相信吹wt的大部分都是吹它的好用，而不是什么新的shell之类的。虽然大部分windo

之前一直用的cmder，自从wt出来以后，好像就再没打开过了

看到楼主脸被打肿了我就放心了

强烈赞同PowerShell就是个反人类的东西，为了不同而不同

# 大家都在点赞 Windows Terminal，我决定给你泼一盆冷水

Windows Terminal 发布以后，立刻引爆了整个技术圈，各种社交媒体上纷纷传播着它的消息，它开源的 GitHub 仓库的星标数一路飙升，迅速成为当日 GitHub 趋势榜的首名，甚至连它 issue 区都挤满了人——以至于项目运营团队紧急出场管理。不过，在我观看了相关的资料和视频以后，感觉并没有那么令人兴奋。

在我看到一时间出现的很多文章，**都视 Windows Terminal 为 Windows 下命令行体验的救世主之后**，我觉得，是时候泼一盆冷水降降温了。

*Windows Terminal 项目下的讨论*

### Windows Terminal 是什么？

在泼冷水之前，我想先来介绍一下 Windows Terminal 是什么，以方便你理解我的观点：**Windows Terminal 是一个套在 Windows 操作系统原本的 CMD、Powershell、Windows Subsystem for Linux（WSL）之上的一个界面更加漂亮、功能更加强大的终端工具。**严格来说，**它是套在 CMD 、Powershell 之上的一个终端。**

*Powershell on Windows Terminal。图片来源：<https://devblogs.microsoft.com/commandline/introducing-windows-terminal/>*

>
> 这里需要了解一下<ruby> 终端 <rt>  terminal </rt></ruby>和 shell 的区别：
>
>
> 在命令行中，shell 提供了访问操作系统内核功能的途径，比如说我们所熟悉的 bash、zsh，都是不同的 shell；而终端则为 shell 提供视觉界面（窗口），比如我们所熟悉的 iTerm2、Linux 桌面上的终端工具等。甚至于我们在 VSCode 中所使用的命令行，也是某种意义上的终端。
>
>
> 我们在 Windows 下所使用的 CMD、Powershell 既然是一个终端，也是一个 Shell，还是同名的脚本系统。
>
>
>

但是，**它也只是一个终端而已，而不是一个更加好用的 Shell**。

### 为什么 Windows Terminal 不是救世主？

作为一个终端，Windows Terminal 无疑是合格的，它提供了非常强大的功能，来自微软的强大工程能力也让它能够吸引更多的眼球。

*Cmder 效果图。图片来源：Cmder 官网*

但是，如果仅仅是一个终端，其实开源社区早已有更多的解决方案，比如 [cmder](https://cmder.net/)、[ConEmu](https://conemu.github.io/)、[Hyper](https://hyper.is/) 等等，这些 Terminal 也足够好看和好用。

*ConEmu效果图。图片来源：ConEmu 官网*

**这种第三方就可以做好的事情，微软官方的进入不过是在现有的命令行生态下提供更多的一种选择，而不是真正的问题解决方案。**

### 当我们吐槽 Windows 命令行时，我们在吐槽什么？

那么我们是对什么不满意呢？**Windows 用户所吐槽的命令行不好用不在于其表面，而在于其没有一个足够好用的 Shell。** Windows 下的两个命令行界面都各有自己的问题，CMD 因为时间久远，很多功能不齐全。而 Power Shell 虽然功能强大，但不合理的命令语法，大量冗长的、驼峰式命名的命令和参数使得用户的命令操作极为不便，体验极差。如果没有一个足够好用的 Shell ，无论换了多少外面的终端，无非是披了一个闪闪发光的、半透明的漂亮外衣罢了。

对于开发者们来说，真正希望 Windows 做的，不是一个更漂亮的终端。漂亮的终端只能让他们一时新鲜，但是如果希望开发者们真正感觉到 Windows 命令行好用，就需要提供一个更加强大的 Shell，帮助开发者能够用上 Unix 式的命令行工具。

### Windows Terminal + Windows Subsystem for Linux ？

在 Microsoft Build 2019 大会上，除了 Windows Terminal 以外，还发布了 Windows Subsystem for Linux 2（WSL2）。新一代的 WSL 相比于上一代，提供了完整的 Linux 内核，将会提供更好的系统支持。看起来，Windows Terminal 和 WSL 的结合，已经非常完美了，但作为一个 Shell 来用的话，又显的过于笨重。

WSL 2 所提供的，不过是一个更加简单、更加易用的 Windows 下的虚拟机，你不再需要安装 Virtual Box、VMWare 而已，一个 Windows Subsystem for Linux 就可以满足开发者的大部分需求。

但是，这并不能解决问题，这治标不治本的选择。**WSL 无论做的再怎么好，无法摆脱它只是一个运行于 Windows 系统中附属的子系统**。无论 WSL 做的再好，本质上并没有比虚拟机做的更多。

### 作为一个开发者，我认为什么才是微软真正应该做的？

*Windows Love Linux。图片来源：<https://cloudblogs.microsoft.com/windowsserver/2015/05/06/microsoft-loves-linux/>*

作为 Windows 系统的开发者，微软真正的价值显然不是做一个终端那么简单。**作为生态的打造者，微软真正可以做好的是，打造一个能够在体验和生态上与 Unix Shell 一致的 Shell，或者是干脆提供 Bash、Zsh 等常用 Shell 的原生支持**（WSL 虽然支持 Bash、Zsh等，但依然是需要先进入 WSL 才能使用，但你可以畅想一下，如果 CMD 变成了 Bash，会是什么样的呢？)。这些事情是第三方开发者所无法做的更好的，只有生态的构建者在一开始就将一个体验良好的 Shell 放置在系统的核心，无需开发者自行安装、配置，才能够让开发者真正拥有一个好的命令行体验。如果微软能提供一个足够好用的 Shell，我相信类似于 Windows Terminal 这样的应用，会如雨后春笋一般，从开源社区中源源不断的冒出来。

### 总结

对于广大使用 Windows 开发的用户来说，一个闪闪发亮的、现代化的、功能强大的终端固然很好，但好的终端只不过是锦上添花之举，而一个强大好用的 Shell 才是真正能够雪中送炭的东西，只有一个足够好用的 Shell，才能成为 Windows 命令行世界的救世主。而这，才是真正值得微软花费大量的时间、精力去做的。

### 延展阅读

* Introducing Windows Terminal：<https://devblogs.microsoft.com/commandline/introducing-windows-terminal/>
* Announcing WSL 2：<https://devblogs.microsoft.com/commandline/announcing-wsl-2/>
* Windows 下有哪些替代 CMD 的命令行工具？：<https://www.zhihu.com/question/19739424>


每日安全资讯：计算机科学家设计无法被黑的处理器芯片架构

# 每日安全资讯：计算机科学家设计无法被黑的处理器芯片架构

密歇根大学的计算机科学家设计出一种新的处理器架构，能主动抵御未来威胁，事实上让现有的 bug 和补丁安全模式过时。被称为 MORPHEUS 的芯片通过每秒 20 次加密和随机重编关键数据比特来阻止潜在的攻击，远快于人类黑客能做出反应的速度，比最快的电子黑客技术快数千倍。

密歇根大学教授 Todd Austin 称，今天一个接一个消除 bug 的方法是一种失败的博弈，只要有新的代码，总会出现新的 bug 和安全漏洞。

通过使用 MORPHEUS，即使黑客发现了一个 bug，利用 bug 所需的信息会在 50 毫秒后消失，它可能是最接近不会被黑的安全系统。

<img src="content_image/album_201905_08_114023cuj6nexn6jm39jqf.jpg" alt="" title="">

来源：solidot.org

### 更多资讯

##### 加拿大边境服务局因旅客拒绝披露密码而扣押其手机和笔记本电脑

加拿大边境服务局被指因律师拒绝披露密码而扣押其手机和笔记本电脑。这位叫 Nick Wright 的加拿大律师于 4 月 10 日乘飞机在多伦多的 Pearson 机场入境，他被要求接受额外的检查，边境服务局没有给出检查的理由。

来源： solidot.org
详情： <http://t.cn/EoavJhT>

##### 黑客攻击 GitHub 仅获 2.95 美元 买咖啡都不够

据此前报道，日前有黑客攻击 Github，删除了 Git 代码库中一些用户的源代码以及近期的更新，并留下勒索留言，要求受害者支付 0.1 比特币的赎金。攻击者的确收到了赎金，然而收到的比特币甚至还不够在美国买一杯咖啡。

来源： 新浪财经

详情： <http://t.cn/EoavSwv>

##### 网信办征求意见：App 这些行为属违法违规收集个人信息

各有关单位及专家：落实《关于开展 App 违法违规收集使用个人信息专项治理的公告》，App 专项治理工作组在中央网信办、工信部、公安部、市场监管总局指导下，开展了 App 违法违规收集使用个人信息安全评估，发现一些 App 存在强制授权、过度索权、超范围收集个人信息等问题。

来源： 网信中国

详情： <http://t.cn/EoavCY0>

##### 网易邮箱回应大量账号被叫卖：仅涉及邮箱地址，已报案

7 日下午消息，针对媒体报道的“大量网易邮箱账号遭公开叫卖”，网易邮箱在其官方微博上发表声明称， 经查，报道中提及的违法行为，仅涉及邮箱地址，不涉及用户敏感信息，并已第一时间向公安机关报案。今日早些时候，人民创投报道称，在某交流平台，有人公开叫卖网易邮箱账号，百万邮箱售价仅 50 元。卖家自称可向这些邮箱发送营销信息，并展示了据说包含有百万个邮箱账号的文件。经测试，仅有 6 个邮箱发送失败。

来源： 新浪科技
详情： <http://t.cn/EoavOso>

（信息来源于网络，安华金和搜集整理）


如何使用 autofs 挂载 NFS 共享

Summary: 给你的网络文件系统（NFS）配置一个基本的自动挂载功能。

给你的网络文件系统（NFS）配置一个基本的自动挂载功能。

# 如何使用 autofs 挂载 NFS 共享

>
> 给你的网络文件系统（NFS）配置一个基本的自动挂载功能。
>
>
>

<img src="content_image/album_201905_08_115328rva7kqw9wqh2qees.jpg" alt="" title="">

大多数 Linux 文件系统在引导时挂载，并在系统运行时保持挂载状态。对于已在 `fstab` 中配置的任何远程文件系统也是如此。但是，有时你可能希望仅按需挂载远程文件系统。例如，通过减少网络带宽使用来提高性能，或出于安全原因隐藏或混淆某些目录。[autofs](https://wiki.archlinux.org/index.php/autofs) 软件包提供此功能。在本文中，我将介绍如何配置基本的自动挂载。

首先做点假设：假设有台 NFS 服务器 `tree.mydatacenter.net` 已经启动并运行。另外假设一个名为 `ourfiles` 的数据目录还有供 Carl 和 Sarah 使用的用户目录，它们都由服务器共享。

一些最佳实践可以使工作更好：服务器上的用户和任何客户端工作站上的帐号有相同的用户 ID。此外，你的工作站和服务器应有相同的域名。检查相关配置文件应该确认。

```
alan@workstation1:~$ sudo getent passwd carl sarah
[sudo] password for alan:
carl:x:1020:1020:Carl,,,:/home/carl:/bin/bash
sarah:x:1021:1021:Sarah,,,:/home/sarah:/bin/bash

alan@workstation1:~$ sudo getent hosts
127.0.0.1       localhost
127.0.1.1       workstation1.mydatacenter.net workstation1
10.10.1.5       tree.mydatacenter.net tree
```

如你所见，客户端工作站和 NFS 服务器都在 `hosts` 文件中配置。我假设这是一个基本的家庭甚至小型办公室网络，可能缺乏适合的内部域名服务（即 DNS）。

### 安装软件包

你只需要安装两个软件包：用于 NFS 客户端的 `nfs-common` 和提供自动挂载的 `autofs`。

```
alan@workstation1:~$ sudo apt-get install nfs-common autofs
```

你可以验证 autofs 相关的文件是否已放在 `/etc` 目录中：

```
alan@workstation1:~$ cd /etc; ll auto*
-rw-r--r-- 1 root root 12596 Nov 19  2015 autofs.conf
-rw-r--r-- 1 root root   857 Mar 10  2017 auto.master
-rw-r--r-- 1 root root   708 Jul  6  2017 auto.misc
-rwxr-xr-x 1 root root  1039 Nov 19  2015 auto.net*
-rwxr-xr-x 1 root root  2191 Nov 19  2015 auto.smb*
alan@workstation1:/etc$
```

### 配置 autofs

现在你需要编辑其中几个文件并添加 `auto.home` 文件。首先，将以下两行添加到文件 `auto.master` 中：

```
/mnt/tree  /etc/auto.misc
/home/tree  /etc/auto.home
```

每行以挂载 NFS 共享的目录开头。继续创建这些目录：

```
alan@workstation1:/etc$ sudo mkdir /mnt/tree /home/tree
```

接下来，将以下行添加到文件 `auto.misc`：

```
ourfiles        -fstype=nfs     tree:/share/ourfiles
```

该行表示 autofs 将挂载 `auto.master` 文件中匹配 `auto.misc` 的 `ourfiles` 共享。如上所示，这些文件将在 `/mnt/tree/ourfiles` 目录中。

第三步，使用以下行创建文件 `auto.home`：

```
*               -fstype=nfs     tree:/home/&
```

该行表示 autofs 将挂载 `auto.master` 文件中匹配 `auto.home` 的用户共享。在这种情况下，Carl 和 Sarah 的文件将分别在目录 `/home/tree/carl` 或 `/home/tree/sarah`中。星号 `*`（称为通配符）使每个用户的共享可以在登录时自动挂载。`＆` 符号也可以作为表示服务器端用户目录的通配符。它们的主目录会相应地根据 `passwd` 文件映射。如果你更喜欢本地主目录，则无需执行此操作。相反，用户可以将其用作特定文件的简单远程存储。

最后，重启 `autofs` 守护进程，以便识别并加载这些配置的更改。

```
alan@workstation1:/etc$ sudo service autofs restart
```

### 测试 autofs

如果更改文件 `auto.master` 中的列出目录，并运行 `ls` 命令，那么不会立即看到任何内容。例如，切换到目录 `/mnt/tree`。首先，`ls` 的输出不会显示任何内容，但在运行 `cd ourfiles` 之后，将自动挂载 `ourfiles` 共享目录。 `cd` 命令也将被执行，你将进入新挂载的目录中。

```
carl@workstation1:~$ cd /mnt/tree
carl@workstation1:/mnt/tree$ ls
carl@workstation1:/mnt/tree$ cd ourfiles
carl@workstation1:/mnt/tree/ourfiles$
```

为了进一步确认正常工作，`mount` 命令会显示已挂载共享的细节。

```
carl@workstation1:~$ mount

tree:/mnt/share/ourfiles on /mnt/tree/ourfiles type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.1.22,local_lock=none,addr=10.10.1.5)

```

对于 Carl 和 Sarah，`/home/tree` 目录工作方式相同。

我发现在我的文件管理器中添加这些目录的书签很有用，可以用来快速访问。

---

via: <https://opensource.com/article/18/6/using-autofs-mount-nfs-shares>

作者：[Alan Formy-Duval](https://opensource.com/users/alanfdoss) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


原文作者提到了一个非常直白的论点，市面上已有cmder，conemu这类工具，它们可以实现后台调用cmd或ps或bash，并且发展多年，诸如字体，主题，多Tab更是不在话下。微软这个可能做的更好，但是无疑属于yet another one类型。而cmd自身的硬伤在conemu主页上有明确介绍，ps的不足原文也写的中肯，那种驼峰写法用来写几百行大脚本固然无碍，但是只是做个简单的grep，rm不觉得太麻烦了吗。微软应该在革新cmd上使劲，而不是做一个市面已有的东西。而这个文章对此完全忽略了。

来自223.104.210.124的 Chrome Mobile 74.0|Android 用户

已经有的就不能做了？何况windows现在内置的就有cmd，powershell，wsl，做一个自带的统一的现代化terminal难道不是顺理成章吗？为什么不革新cmd，这个就更搞笑，powershell就是为了革cmd搞出来的。至于你说什么grep，你怕是不知道grep根本不是shell的功能，而且grep --color也一样很麻烦，alias了解一下？驼峰什么的powershell可以自动补全的，bash/dash要是那么好也不会有zsh（ohmyzsh）fish，还有一些新兴的带自动补全的terminal了。

是的WSL2听介绍很不错

conemu也不完美，yet another one并非没有意义啊。

powershell也有alias，并没有那么难用的。shell的风格更多只是风格问题。

对于cmd微软现在更看重兼容性，发展还得看ps和wsl啊。具体可以去看微软命令行组的博客。

来自上海上海交通大学的 Chrome Mobile 69.0|Android 8.1 用户

微软官方不建议在powershell脚本中使用alias，比如应该使用Get-Content而不是cat取文件内容。不过现在编辑器加上插件，或者IDE用来写ps脚本应该都可以自动补全了，这个问题不大。

原文章虽然很激进，但实际想表达的应该是，这个本来早就该有的yet another one，现在才有，还受到了大家的热捧，相比起来，其他正在create new one的项目，关注度却不足。当然，可以说是原作者比较酸了，不过这个项目确实没有那么“激动人心”，类比起来就是，本该修建地铁的城市，却坚持十几年只开通公交线路，现在突然推出了双层公交，却被市民争相叫好，实际更需要的是修建地铁啊。

这篇文章的论述就有点偏了，WSL和Windows Terminal是两个项目，虽然有关联，但是收到热烈追捧的是teminal项目，WSL2反而关注度没那么高。

打通WSL和Windows环境远不止能在bash里执行exe文件这么简单，比如要写一个文件处理脚本，就要涉及WSL如何访问宿主的文件系统，文件编码如何转换。当然，这些微软都做了不少工作了，以后支持会越来越好。

比起写这些windows terminal到底值不值得被追捧的"撕逼"文章，我觉得这个时候出一篇介绍shell和terminal联系和区别的文章，就很好了，也不会引来争议。为了丰富内容，建议（同时也是我个人期望）可以加入shell，terminal，terminal emulator，console，tty，bash/zsh等概念的辨析和关系解释，最好还能包括这些词在历史上的意思和发展（比如早期的电传打字机），最好还能加上字体，terminfo，inputrc等相关文件的介绍和作用解释。我曾经研究过一些资料，但是被其他工作打断了，一直没有继续下去，如果贵站能出一篇相关的文章就最好不过了。<br />
（我在原文章发表了这个评论，不知道为啥被吞了一半?，只好在这里再发表一份。）

# 对《大家都在点赞 Windows Terminal，我决定给你泼一盆冷水》一文的商榷

<img src="content_image/album_201905_08_184905be6c46zcbs6vv43n.png" alt="" title="">

### 原文观点

今日 Linux 中国发布了一篇文章 《[大家都在点赞 Windows Terminal，我决定给你泼一盆冷水](/article-10828-1.html)》 。该文主要观点引用如下：

* Windows Terminal 是一个套在 Windows 操作系统原本的 CMD、Powershell、Windows Subsystem for Linux（WSL）之上的一个界面更加漂亮、功能更加强大的终端工具。严格来说，它是套在 CMD 、Powershell 之上的一个终端。
* 它也只是一个终端而已，而不是一个更加好用的 Shell。
* Windows 用户所吐槽的命令行不好用不在于其表面，而在于其没有一个足够好用的 Shell。
* 看起来，Windows Terminal 和 WSL 的结合，已经非常完美了，但作为一个 Shell 来用的话，又显的过于笨重。
* WSL 无论做的再怎么好，无法摆脱它只是一个运行于 Windows 系统中附属的子系统。无论 WSL 做的再好，本质上并没有比虚拟机做的更多。
* 作为生态的打造者，微软真正可以做好的是，打造一个能够在体验和生态上与 Unix Shell 一致的 Shell，或者是干脆提供 Bash、Zsh 等常用 Shell 的原生支持（WSL 虽然支持 Bash、Zsh等，但依然是需要先进入 WSL 才能使用，但你可以畅想一下，如果 CMD 变成了 Bash，会是什么样的呢？)。
* 对于广大使用 Windows 开发的用户来说，一个闪闪发亮的、现代化的、功能强大的终端固然很好，但好的终端只不过是锦上添花之举，而一个强大好用的 Shell 才是真正能够雪中送炭的东西，只有一个足够好用的 Shell，才能成为 Windows 命令行世界的救世主。

关于原文更完整的观点，请参阅原文。这里针对原文观点和表达一些不同意见的商榷。

### Terminal 与 Shell

诚如原文所说，Windows Terminal 其实是一个窗口而已，真正执行的是里面的软件，但是 Windows Terminal 并不如原文说的那么一无是处。众所周知 CMD、PowerShell 默认进入以后是没有标签的，想要使用多个只能多开窗口，管理起来不如够方便，而且配色也是影响使用者快速定位问题的一个重要指标。而这次的 Windows Terminal 不但解决这些问题，还能够支持 emoji，可大大提升在里面所运行的程序的使用体验。

再来说说什么是 shell ？一个 shell 是提供用户与操作系统交互的界面/入口，当我们在命令行中输入各种命令时，其实就是在执行一个应用程序，shell 将这些程序送往内核进行执行，所以最终还是要归到内核的系统调用，此外广义上的 shell 其实还包括了图形界面。

让我们来看看第一个点：

>
> * Windows Terminal 是一个套在 Windows 操作系统原本的 CMD、Powershell、Windows Subsystem for Linux（WSL）之上的一个界面更加漂亮、功能更加强大的终端工具。严格来说，它是套在 CMD 、Powershell 之上的一个终端。
>
>
>

Windows Terminal 准确来说就是一个支持配色的更加现代的终端入口，也不能说是嵌套什么 CMD、PowerShell、WSL，你想怎么使用它取决于你想进入什么样的命令行解释器。举个 Linux 下的例子就是我可以在 `konsole` 下使用 fish、zsh、bash 等 shell 解释器。

### 更好用的 shell？

>
> * 它也只是一个终端而已，而不是一个更加好用的 Shell。
> * Windows 用户所吐槽的命令行不好用不在于其表面，而在于其没有一个足够好用的 Shell。
> * 看起来，Windows Terminal 和 WSL 的结合，已经非常完美了，但作为一个 Shell 来用的话，又显的过于笨重。
>
>
>

关于这里，我觉得原文作者忽视了 Shell 与 Terminal 的区别。Shell 作为一个命令解释器，必然有自己的语法。而 Linux 生态系统中已经很好用的 shell 就有 fish、zsh、bash 等，但是这些语法也不是所有都兼容的，而且一个好用的 shell 一般只是用户感觉上的东西，没有很明确的指标。Windows 用户在有了 WSL 之后可以使用任何 Linux 已经有的 shell 解释器，这其实已经足够解决问题了，毕竟这些工具的改进是为了吸引 Linux 平台上的开发者，而不是为了一个毫无经验的小白准备的。

此外，原文作者提到的 Windows Terminal 与 WSL（搭载完整内核） 结合作为 shell 使用的话，无异于高射炮打蚊子。这点我也是强烈反对的，首先 shell 只是一个命令解释器，它其实不负责命令的执行，最终所有的程序都要传递给系统调用，如果底层的系统调用不支持，那么该 shell 脚本也是无法执行的（内核不会有反应、或者报错），所以你要使用 shell，那么必须要求有底层内核的支持，这不是什么高射炮打不打蚊子的事，而是你必须要知道其实 shell 它自己本身就是个解释器，没有别的特异功能而已。

一个更好用的 shell 也许是值得吸引人的，但是其实 shell 的语法也不见得多好用，很多反人类的，只是我们已经学习接受了这种语法所以认可它。另一个方面是历史问题，要想你写的脚本一次编写处处执行，那么最好就是 bash 兼容了，否则别人为了执行你的特殊语法，还要装一个能读懂你的 shell 语法的解释器。

### wsl 与虚拟机？

>
> * WSL 无论做的再怎么好，无法摆脱它只是一个运行于 Windows 系统中附属的子系统。无论 WSL 做的再好，本质上并没有比虚拟机做的更多。
>
>
>

我其实觉得这句话没有道理，为什么这样说呢，确实 WSL 不会比虚拟机做的更多，因为你虚拟机安装的是一个完整的操作系统，但是 WSL 优势是什么？

WSL 的优势就是不需要虚拟机，你便可以使用大部分 Linux 的生态，这是向开发人员示好。而且 WSL 不需要长期运行一个虚拟机，在 WSL1 的时候，你实际执行应用 WSL 会把系统调用转成 NT 系统调用。而 WSL2 将包含完整 Linux 内核，还将支持 Docker（此处无法得知它具体的实现，不做推测）。WSL1 的限制很多，使用起来不是特别方便，这个有使用过的朋友应该很有体会，但是 WSL2 既然能运行 Docker，那么有了 Docker 我就有了一切。

### 生态体验？

>
> * 作为生态的打造者，微软真正可以做好的是，打造一个能够在体验和生态上与 Unix Shell 一致的 Shell，或者是干脆提供 Bash、Zsh 等常用 Shell 的原生支持（WSL 虽然支持 Bash、Zsh等，但依然是需要先进入 WSL 才能使用，但你可以畅想一下，如果 CMD 变成了 Bash，会是什么样的呢？)。
> * 对于广大使用 Windows 开发的用户来说，一个闪闪发亮的、现代化的、功能强大的终端固然很好，但好的终端只不过是锦上添花之举，而一个强大好用的 Shell 才是真正能够雪中送炭的东西，只有一个足够好用的 Shell，才能成为 Windows 命令行世界的救世主。
>
>
>

这两个观点也是不攻自破的，我既然可以使用 WSL，那么我本身就拥有了 Linux 的生态。如果是希望写 bat 批处理而能有 bash、zsh 的这些体验，那么确实是需要一个新的 shell 满足 Unix Shell 语法，再来解释 Windows 下的命令行，可是这其实也是不需要的。因为本人发现在 WSL 里面执行一个 exe 程序是完全可行的，因此可以用这种 shell 语法去编写我的脚本，oh nice！！体验非常统一啊有没有？

```
locez@Lenovo-PC~> pycharm64.exe  ### 会启动我的 pycharm
locez@Lenovo-PC~> git.exe | xargs echo
```

### 我的观点

我本人认为，微软的这些拥抱 Linux 的举措，其实就是在吸引 Linux 上的开发者而已，开发者想要的工具，如果能够在 Windows 下就能直接使用，那对我们这些开发人员来说无外乎是喜报。工具多一个总不是坏事，但是如果它真的值得使用，那么用户一定会增加，这就是需要微软来做的事情了。我本人是双系统用户，在打游戏娱乐方面我一定会使用 Windows，做开发写代码我会切换到 Linux，曾经写一个很小的软件也是如此。但是后来 WSL 出现了，简单的脚本我可以在 Windows 下就直接完成并且提交，不需要重启系统，然后继续玩我的游戏，美滋滋。

另外就是 Windows Terminal 与 WSL2 的出现会解放我现在系统上的一些工具，例如 git bash、gpg4win 等。如果 WSL2 真的有完整的系统调用，那么我现有的 Windows 上的开发环境便不再需要，专注于游戏娱乐，但是一进 WSL 便是我工作学习的地方。


关于 Windows Terminal，人民群众都在聊些什么？

Summary: 无论这一产品本身如何、它的未来将去向何方，至少，它在这两天吸足了眼球。

Prerequisites 微软翻译为先决条件，不是翻译前提条件。

注意：这篇文章没什么实际意义……<br />
哈哈！

有意思，脑洞真大。

无论这一产品本身如何、它的未来将去向何方，至少，它在这两天吸足了眼球。

# 关于 Windows Terminal，人民群众都在聊些什么？

/\*注意：这篇文章没什么实际意义……\*/

就如大家所知，5 月 6 日，微软宣布了新的 Windows 命令行界面 —— Windows Terminal。 无论这一产品本身如何、它的未来将去向何方，至少，它在这两天吸足了眼球。技术媒体争相复制黏贴相关通稿，大量人群涌入[项目的 Github 仓库](https://github.com/microsoft/Terminal)，2 天内点出超过 20000 星标 —— 并于今日成功跃居 Github 趋势榜榜首。

在项目宣布、仓库开放的这两天中，截止至发稿时，已经发生了 20 次提交，新增的 issue 有 121 条 —— 这个数字仍然以相当高的速度增长。截止至发稿时间，这些 issue 中有 72 条未被关闭，但剩余的 49 条（主要是问题之类）已经得到处理。作为对比，同样是微软的开源项目，具有接近 50000 星标的 TypeScript 在七天内总共有新 issue 75 条，这个数字比 Terminal 的 121 条少了三分之一。人群的涌入并不是 issue 数量极多的唯一原因：事实上，这个项目目前还处于 alpha 测试的早期阶段，问题多多在所难免。在目前开放的 issue 中，大部分是 bug 报告，其次是特性请求；我们可以注意到，bug 报告以界面 bug 为主（字体渲染问题，颜色问题，等等），而特性请求大多与交互方式相关。

*界面 bug：“输入emoji会导致光标位置异常”*

许多的提问已经被关闭，但似乎新的问题正不断冒出；最常见的几个问题分别是：

* “我该如何编译这个项目？”（包括各种变体，比如 VS 报错，编译失败等等）
* “是否有官方的二进制文件放出？”
* “为什么我打开编译好的程序，它看起来却和旧的界面差不多？”

*(项目组把编译指南放在了明显位置)*

在部分吃瓜群众面对 VS 枯坐时，另一些吃瓜群众决定打开他们的脑洞。已关闭的 issue 中包含了一些特别的提问：提出者想要知道能不能在 Linux / MacOS 中使用这个项目，但被项目组人员告知目前没有将它登陆其他平台的打算。

*“功能请求： Linux 支持。拜托了。”*

目前，许多网友对这一项目表示了惊喜和看好。尽管现在到处可以见到“吹爆”式的评论，但如果谈起人民群众，当然不能错过一支永远期待着微软出洋相的互联网力量（当然我们很“惊喜”地发现很多吐槽是中文的）：

*评论总结：巨硬辣鸡！（破音）*

也少不了奇葩：

*（看看下面的 emoji 就能够感受到这条 issue 给广大群众的快乐）*

**

*（我觉得你应该跟开发 LOL 的公司聊聊）*

*（我真不想承认我看得懂你的文字）*

**

*（而这就是在捣乱了）*

现场一度极其热闹，以至于项目管理方出手干预之后才避免成了瓜地。

如果没有自己试着接触过讨论对象，参加讨论时恐怕难免会有一种云玩家般的心虚感。笔者用亲身经历告诉你，别看讨论热火朝天，想要用上这尚在a测的新终端，事实上并不是那么容易的：无论是自行编译项目还是用现在网上第三方编译的安装包安装，你都需要……嗯，系统更新。

*“前提条件：你需要 Windows 1903 或以上版本以运行 Windows Terminal.”*

看着 VS 里一条条的报错，和这霸道的官方要求，我仰天大喊：

“我看这破软，是药丸呐！”


Python 的加密库入门

Summary: 加密你的数据并使其免受攻击者的攻击。

加密你的数据并使其免受攻击者的攻击。

# Python 的加密库入门

>
> 加密你的数据并使其免受攻击者的攻击。
>
>
>

<img src="content_image/album_201905_09_102717p0zgyiygeyyizy7g.jpg" alt="" title="">

密码学俱乐部的第一条规则是：永远不要自己*发明*密码系统。密码学俱乐部的第二条规则是：永远不要自己*实现*密码系统：在现实世界中，在*实现*以及设计密码系统阶段都找到过许多漏洞。

Python 中的一个有用的基本加密库就叫做 [cryptography](https://cryptography.io/en/latest/)。它既是一个“安全”方面的基础库，也是一个“危险”层。“危险”层需要更加小心和相关的知识，并且使用它很容易出现安全漏洞。在这篇介绍性文章中，我们不会涵盖“危险”层中的任何内容！

cryptography 库中最有用的高级安全功能是一种 Fernet 实现。Fernet 是一种遵循最佳实践的加密缓冲区的标准。它不适用于非常大的文件，如千兆字节以上的文件，因为它要求你一次加载要加密或解密的内容到内存缓冲区中。

Fernet 支持<ruby> 对称 <rt>  symmetric </rt></ruby>（即<ruby> 密钥 <rt>  secret key </rt></ruby>）加密方式\*：加密和解密使用相同的密钥，因此必须保持安全。

生成密钥很简单：

```
>>> k = fernet.Fernet.generate_key()
>>> type(k)
<class 'bytes'>
```

这些字节可以写入有适当权限的文件，最好是在安全的机器上。

有了密钥后，加密也很容易：

```
>>> frn = fernet.Fernet(k)
>>> encrypted = frn.encrypt(b"x marks the spot")
>>> encrypted[:10]
b'gAAAAABb1'
```

如果在你的机器上加密，你会看到略微不同的值。不仅因为（我希望）你生成了和我不同的密钥，而且因为 Fernet 将要加密的值与一些随机生成的缓冲区连接起来。这是我之前提到的“最佳实践”之一：它将阻止对手分辨哪些加密值是相同的，这有时是攻击的重要部分。

解密同样简单：

```
>>> frn = fernet.Fernet(k)
>>> frn.decrypt(encrypted)
b'x marks the spot'
```

请注意，这仅加密和解密*字节串*。为了加密和解密*文本串*，通常需要对它们使用 [UTF-8](https://en.wikipedia.org/wiki/UTF-8) 进行编码和解码。

20 世纪中期密码学最有趣的进展之一是<ruby> 公钥 <rt>  public key </rt></ruby>加密。它可以在发布加密密钥的同时而让*解密密钥*保持保密。例如，它可用于保存服务器使用的 API 密钥：服务器是唯一可以访问解密密钥的一方，但是任何人都可以保存公共加密密钥。

虽然 cryptography 没有任何支持公钥加密的*安全*功能，但 [PyNaCl](https://pynacl.readthedocs.io/en/stable/) 库有。PyNaCl 封装并提供了一些很好的方法来使用 Daniel J. Bernstein 发明的 [NaCl](https://nacl.cr.yp.to/) 加密系统。

NaCl 始终同时<ruby> 加密 <rt>  encrypt </rt></ruby>和<ruby> 签名 <rt>  sign </rt></ruby>或者同时<ruby> 解密 <rt>  decrypt </rt></ruby>和<ruby> 验证签名 <rt>  verify signature </rt></ruby>。这是一种防止<ruby> 基于可伸缩性 <rt>  malleability-based </rt></ruby>的攻击的方法，其中攻击者会修改加密值。

加密是使用公钥完成的，而签名是使用密钥完成的：

```
>>> from nacl.public import PrivateKey, PublicKey, Box
>>> source = PrivateKey.generate()
>>> with open("target.pubkey", "rb") as fpin:
... target_public_key = PublicKey(fpin.read())
>>> enc_box = Box(source, target_public_key)
>>> result = enc_box.encrypt(b"x marks the spot")
>>> result[:4]
b'\xe2\x1c0\xa4'
```

解密颠倒了角色：它需要私钥进行解密，需要公钥验证签名：

```
>>> from nacl.public import PrivateKey, PublicKey, Box
>>> with open("source.pubkey", "rb") as fpin:
... source_public_key = PublicKey(fpin.read())
>>> with open("target.private_key", "rb") as fpin:
... target = PrivateKey(fpin.read())
>>> dec_box = Box(target, source_public_key)
>>> dec_box.decrypt(result)
b'x marks the spot'
```

最后，[PocketProtector](https://github.com/SimpleLegal/pocket_protector/blob/master/USER_GUIDE.md) 库构建在 PyNaCl 之上，包含完整的密钥管理方案。

---

via: <https://opensource.com/article/19/4/cryptography-python>

作者：[Moshe Zadka](https://opensource.com/users/moshez) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


为何 DevOps 是如今最重要的技术策略

Summary: 消除一些关于 DevOps 的疑惑。

消除一些关于 DevOps 的疑惑。

# 为何 DevOps 是如今最重要的技术策略

>
> 消除一些关于 DevOps 的疑惑。
>
>
>

很多人初学 [DevOps](https://opensource.com/resources/devops) 时，看到它其中一个结果就问这个是如何得来的。其实理解这部分 Devops 的怎样实现并不重要，重要的是——理解（使用） DevOps 策略的原因——这是做一个行业的领导者还是追随者的差别。

你可能会听过些 Devops 的难以置信的成果，例如生产环境非常有弹性，就算是有个“<ruby>   癫狂的猴子  <rt>  Chaos Monkey </rt></ruby>）跳来跳去将不知道哪个插头随便拔下，每天仍可以处理数千个发布。这是令人印象深刻的，但就其本身而言，这是一个 DevOps 的证据不足的案例，其本质上会被一个[反例](https://en.wikipedia.org/wiki/Burden_of_proof_(philosophy)#Proving_a_negative)困扰：DevOps 环境有弹性是因为严重的故障还没有被观测到。

有很多关于 DevOps 的疑惑，并且许多人还在尝试弄清楚它的意义。下面是来自我 LinkedIn Feed 中的某个人的一个案例：

>
> 最近我参加一些 #DevOps 的交流会，那里一些演讲人好像在倡导 #敏捷开发是 DevOps 的子集。不知为何，我的理解恰恰相反。
>
>
> 能听一下你们的想法吗？你认为敏捷开发和 DevOps 之间是什么关系呢？
>
>
> 1. DevOps 是敏捷开发的子集
> 2. 敏捷开发是 DevOps 的子集
> 3. DevOps 是敏捷开发的扩展，从敏捷开发结束的地方开始
> 4. DevOps 是敏捷开发的新版本
>
>
>

科技行业的专业人士在那篇 LinkedIn 的帖子上表达了各种各样的答案，你会怎样回复呢？

### DevOps 源于精益和敏捷

如果我们从亨利福特的战略和丰田生产系统对福特车型的改进（的历史）开始， DevOps 就更有意义了。精益制造就诞生在那段历史中，人们对精益制作进行了良好的研究。James P. Womack 和 Daniel T. Jones 将精益思维（[Lean Thinking](https://www.amazon.com/dp/B0048WQDIO/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)）提炼为五个原则：

1. 指明客户所需的价值
2. 确定提供该价值的每个产品的价值流，并对当前提供该价值所需的所有浪费步骤提起挑战
3. 使产品通过剩余的增值步骤持续流动
4. 在可以连续流动的所有步骤之间引入拉力
5. 管理要尽善尽美，以便为客户服务所需的步骤数量和时间以及信息量持续下降

精益致力于持续消除浪费并增加客户的价值流动。这很容易识别并明白精益的核心原则：单一流。我们可以做一些游戏去了解为何同一时间移动单个比批量移动要快得多。其中的两个游戏是[硬币游戏](https://youtu.be/5t6GhcvKB8o?t=54)和[飞机游戏](https://www.shmula.com/paper-airplane-game-pull-systems-push-systems/8280/)。在硬币游戏中，如果一批 20 个硬币到顾客手中要用 2 分钟，顾客等 2 分钟后能拿到整批硬币。如果一次只移动一个硬币，顾客会在 5 秒内得到第一枚硬币，并会持续获得硬币，直到在大约 25 秒后第 20 个硬币到达。（LCTT 译注：有相关的视频的）

这是巨大的不同，但是不是生活中的所有事都像硬币游戏那样简单并可预测的。这就是敏捷的出现的原因。我们当然看到了高效绩敏捷团队的精益原则，但这些团队需要的不仅仅是精益去做他们要做的事。

为了能够处理典型的软件开发任务的不可预见性和变化，敏捷开发的方法论会将重点放在意识、审议、决策和行动上，以便在不断变化的现实中调整。例如，敏捷框架（如 srcum）通过每日站立会议和冲刺评审会议等仪式提高意识。如果 scrum 团队意识到新的事实，框架允许并鼓励他们在必要时及时调整路线。

要使团队做出这些类型的决策，他们需要高度信任的环境中的自我组织能力。以这种方式工作的高效绩敏捷团队在不断调整的同时实现快速的价值流，消除错误方向上的浪费。

### 最佳批量大小

要了解 DevOps 在软件开发中的强大功能，这会帮助我们理解批处理大小的经济学。请考虑以下来自Donald Reinertsen 的[产品开发流程原则](https://www.amazon.com/dp/B00K7OWG7O/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)的U曲线优化示例：

这可以类比杂货店购物来解释。假设你需要买一些鸡蛋，而你住的地方离商店只有 30 分钟的路程。买一个鸡蛋（图中最左边）意味着每次要花 30 分钟的路程，这就是你的*交易成本*。*持有成本*可能是鸡蛋变质和在你的冰箱中持续地占用空间。*总成本*是*交易成本*加上你的*持有成本*。这个 U 型曲线解释了为什么对大部分人来说，一次买一打鸡蛋是他们的*最佳批量大小*。如果你就住在商店的旁边，步行到那里不会花费你任何的时候，你可能每次只会买一小盒鸡蛋，以此来节省冰箱的空间并享受新鲜的鸡蛋。

这 U 型优化曲线可以说明为什么在成功的敏捷转换中生产力会显著提高。考虑敏捷转换对组织决策的影响。在传统的分级组织中，决策权是集中的。这会导致较少的人做更大的决策。敏捷方法论会有效地降低组织决策中的交易成本，方法是将决策分散到最被人熟知的认识和信息的位置：跨越高度信任，自组织的敏捷团队。

下面的动画演示了降低事务成本后，最佳批量大小是如何向左移动。在更频繁地做出更快的决策方面，你不能低估组织的价值。

### DevOps 适合哪些地方

自动化是 DevOps 最知名的事情之一。前面的插图非常详细地展示了自动化的价值。通过自动化，我们将交易成本降低到接近于零，实质上是可以免费进行测试和部署。这使我们可以利用越来越小的批量工作。较小批量的工作更容易理解、提交、测试、审查和知道何时能完成。这些较小的批量大小也包含较少的差异和风险，使其更易于部署，如果出现问题，可以进行故障排除和恢复。通过自动化与扎实的敏捷实践相结合，我们可以使我们的功能开发非常接近单件流程，从而快速、持续地为客户提供价值。

更传统地说，DevOps 被理解为一种打破开发团队和运营团队之间混乱局面的方法。在这个模型中，开发团队开发新的功能，而运营团队则保持系统的稳定和平稳运行。摩擦的发生是因为开发过程中的新功能将更改引入到系统中，从而增加了停机的风险，运营团队并不认为要对此负责，但无论如何都必须处理这一问题。DevOps 不仅仅尝试让人们一起工作，更重要的是尝试在复杂的环境中安全地进行更频繁的更改。

我们可以看看 [Ron Westrum](https://en.wikipedia.org/wiki/Ron_Westrum) 在有关复杂组织中实现安全性的研究。在研究为什么有些组织比其他组织更安全时，他发现组织的文化可以预测其安全性。他确定了三种文化：病态的、官僚主义的和生产式的。他发现病态的可以预测其安全性较低，而生产式文化被预测为更安全（例如，在他的主要研究领域中，飞机坠毁或意外住院死亡的数量要少得多）。

高效的 DevOps 团队通过精益和敏捷的实践实现了一种生成性文化，这表明速度和安全性是互补的，或者说是同一个问题的两个方面。通过将决策和功能的最佳批量大小减少到非常小，DevOps 实现了更快的信息流和价值，同时消除了浪费并降低了风险。

与 Westrum 的研究一致，在提高安全性和可靠性的同时，变化也很容易发生。当一个敏捷的 DevOps 团队被信任做出自己的决定时，我们将获得 DevOps 目前最为人所知的工具和技术：自动化和持续交付。通过这种自动化，交易成本比以往任何时候都进一步降低，并且实现了近乎单一的精益流程，每天创造数千个决策和发布的潜力，正如我们在高效绩的 DevOps 组织中看到的那样

### 流动、反馈、学习

DevOps 并不止于此。我们主要讨论了 DevOps 实现了革命性的流程，但通过类似的努力可以进一步放大精益和敏捷实践，从而实现更快的反馈循环和更快的学习。在[DevOps手册](https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002/ref=sr_1_3?keywords=DevOps+handbook&qid=1553197361&s=books&sr=1-3) 中，作者除了详细解释快速流程外， DevOps 如何在整个价值流中实现遥测，从而获得快速且持续的反馈。此外，利用[精益求精的突破](https://en.wikipedia.org/wiki/Kaizen)和 scrum 的[回顾](https://www.scrum.org/resources/what-is-a-sprint-retrospective)，高效的 DevOps 团队将不断推动学习和持续改进深入到他们的组织的基础，实现软件产品开发行业的精益制造革命。

### 从 DevOps 评估开始

利用 DevOps 的第一步是，经过大量研究或在 DevOps 顾问和教练的帮助下，对高效绩 DevOps 团队中始终存在的一系列维度进行评估。评估应确定需要改进的薄弱或不存在的团队规范。对评估的结果进行评估，以找到具有高成功机会的快速获胜焦点领域，从而产生高影响力的改进。快速获胜非常重要，能让团队获取解决更具挑战性领域所需的动力。团队应该产生可以快速尝试的想法，并开始关注 DevOps 转型。

一段时间后，团队应重新评估相同的维度，以衡量改进并确立新的高影响力重点领域，并再次采纳团队的新想法。一位好的教练将根据需要进行咨询、培训、指导和支持，直到团队拥有自己的持续改进方案，并通过不断地重新评估、试验和学习，在所有维度上实现近乎一致。

在本文的[第二部分](https://opensource.com/article/19/3/where-drupal-community-stands-devops-adoption)中，我们将查看 Drupal 社区中 DevOps 调查的结果，并了解最有可能找到快速获胜的位置。

---

via: <https://opensource.com/article/19/3/devops-most-important-tech-strategy>

作者：[Kelly Albrecht](https://opensource.com/users/ksalbrecht/users/brentaaronreed/users/wpschaub/users/wpschaub/users/ksalbrecht) 选题：[lujun9972](https://github.com/lujun9972) 译者：[zgj1024](https://github.com/zgj1024) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


每日安全资讯：美中情局分享暗网加密链接 网友吐槽：原来是这样监视我们

# 每日安全资讯：美中情局分享暗网加密链接 网友吐槽：原来是这样监视我们

美国中央情报局（CIA）最近一改“神秘”形象，开始在社交网站上“抖机灵”。两周前，中情局在 Instagram 上发布一张“猜谜”照片，吸了一波流量，没想到7日却因在推特上分享的暗网链接“翻了车”。

“来洋葱网络（Tor network）找我们呀！”5 月 7 日，中情局一连在推特上发布了 4 条加密链接相关推文。中情局公布了其在洋葱网络的网址链接，承诺网友可以匿名通过该平台上向政府“提供信息”。

*推特截图*

中情局在推文中写到：“情报收集任务存在着安全、匿名、不可追踪等特点，洋葱网络也刚好具有同样特性。中情局信息一应俱全，如果想获得相关内容，请点击下方链接。”

*推特截图*

中情局此举也让网友感到疑惑：洋葱网络到底是不是间谍工具？推特上网友回复似乎不完全符合中情局的意。有网友断然拒绝：不用，谢谢！另有评论称：“原来中情局就是这么监视美国民众的。”

更有网友认为，中情局使用加密网络与罪犯和恐怖分子使用的是一样的，被讽刺称“肯定不会让人失望”。（海外网 张琪）

来源：cnBeta.COM

### 更多资讯

##### FBI 查获并捣毁暗网索引和新闻网站 Deep Dot Web

据外媒报道，美国 FBI 日前已查获暗网索引和新闻网站 Deep Dot Web。该网站的暗网现已被撤下，取而代之的是一个通知。根据通知了解到，FBI 联合电脑犯罪调查人员和欧洲执法部门并在接到搜查令后查封了该网站。

来源： 海外网
详情： <http://t.cn/EoO361X>

##### 除 bug 务尽 Mozilla 再次更新 Firefox 以修复扩展被禁用的相关问题

上周末，Mozilla 意外地在桌面和 Android 上安装的 Firefox 浏览器上禁用了许多用户的附加组件，引发一阵混乱，一天后， Mozilla 推出 Firefox 66.0.4，许多问题就得到了解决，但事实上公司承认仍有一大批用户存在一些遗留问题，他们通常需要等待很长时间才会恢复正常，而使用今天新发布的 Firefox 66.0.5，就可以有立竿见影的疗效。

来源： cnBeta.COM

详情： <http://t.cn/EoO3o8m>

##### 大连警方破获一起侵犯公民个人信息案 查获个人信息近亿条

大连警方近日成功破获一起侵犯公民个人信息案，抓获犯罪嫌疑人 1 名，查获公民个人信息数量近亿条。

来源： 新华网

详情： <http://t.cn/EoO3NYO>

（信息来源于网络，安华金和搜集整理）


为何《贡献者许可协议》不利于开源社区？

Summary: 开源社区中很少有法律话题像《贡献者许可协议》一样具有争议性。

开源社区中很少有法律话题像《贡献者许可协议》一样具有争议性。

# 为何《贡献者许可协议》不利于开源社区？

>
> 开源社区中很少有法律话题像《贡献者许可协议》一样具有争议性。
>
>
>

开源社区中很少有法律话题像《[贡献者许可协议](https://opensource.com/article/18/3/cla-vs-dco-whats-difference)》（CLA）一样具有争议性。除非你算上《[Fedora 项目贡献者协议](https://opensource.com/law/10/6/new-contributor-agreement-fedora)》（我一直被视为非 CLA）的特殊历史案例，或者像 [Karl Fogel](https://www.red-bean.com/kfogel/) 一样，将《[开发者原创证书](https://developercertificate.org/)》（DCO）归类为[一种 CLA](https://producingoss.com/en/contributor-agreements.html#developer-certificate-of-origin)。目前红帽公司在其维护的项目中没有使用 CLA。

过去情况并非如此。红帽公司最早的项目遵循我称之为<ruby> “入站=出站” <rp>  （ </rp> <rt>  inbound=outbound </rt> <rp>  ） </rp></ruby>的传统做法，其中对项目的贡献仅根据项目的开源许可协议提供，不需要执行外部非自由和开源许可协议。但在 21 世纪初，红帽公司开始尝试使用贡献者协议。Fedora 开始要求贡献者签署基于广泛采用的 [Apache ICLA](https://www.apache.org/licenses/icla.pdf) 制定的 CLA，而自由软件基金会衍生的版权转让协议和一对定制的 CLA 分别继承自 Cygnus 和 JBoss 的收购。我们甚至采取了[一些措施](https://www.freeipa.org/page/Why_CLA%3F)，在快速增长的红帽公司主导项目中采用 Apache 风格的 CLA。

这种情况已经结束，很大程度上是因为我们红帽公司法律团队成员听到并理解了红帽工程师和更广泛的技术社区提出的担忧和异议。我们继续成为一些人称之为反 CLA 运动的事实上的领导者，特别是我们[反对 Project Harmony](https://opensource.com/law/11/7/trouble-harmony-part-1) 以及我们[努力](https://wiki.openstack.org/wiki/OpenStackAndItsCLA)让 OpenStack 用 DCO 取代其 CLA。（我们[不情愿地](https://opensource.com/article/19/1/cla-proliferation)签署可容忍的不符合实际需要的上游项目 CLA）

### 为什么 CLA 存在问题

我们不使用 CLA 的选择反映了我们作为一个真正的开源公司的价值观，它在自由软件运动中有着深厚的根源。多年来，许多开源社区已经解释了为什么 CLA 以及类似的版权分配机制对于开源来说是一个糟糕的政策。

其中一个原因是繁文缛节问题。通常情况下，开源开发的特点是<ruby> 无障碍 <rp>  （ </rp> <rt>  frictionless </rt> <rp>  ） </rp></ruby>贡献，这可以通过“入站=出站”来实现，而不需要进行进一步的法律仪式或流程。这使得新贡献者相对容易参与项目，允许贡献者社区更有效的增长并推动上游的技术创新。无障碍贡献是开源开发针对专有替代品享有优势的关键部分。但是，CLA 否定了无障碍的贡献。在贡献被接受之前签署不寻常的法律协议会造成官僚主义障碍，从而减缓发展并阻碍参与。尽管采用 CLA 的项目越来越多地使用自动化手段，但这种成本仍然存在。

CLA 还会导致项目参与者之间的法律权力不对称，这也阻碍了项目周边主要贡献者和用户社区的增长。使用 Apache 风格的 CLA，领导项目的公司或组织获得其他贡献者无法获得的特殊权利，而其他贡献者必须承担项目负责人免除的某些法律义务（除了繁文缛节负担）。在<ruby> 左版 <rp>  （ </rp> <rt>  copyleft </rt> <rp>  ） </rp></ruby>项目中，不对称问题最为严重，即使出站许可协议是宽松的，它也存在。

在评估支持和反对 CLA 的论据时，请记住，今天与过去一样，任何产品中的绝大多数开源代码都源于遵循“入站=出站”实践的项目。相对较少数量的项目使用 CLA 会对所有其他项目造成附带损害，因为它表明，由于某些原因，开源许可协议不足以处理流入项目的贡献。

### CLA 的案例

由于 CLA 仍然是少数人的做法，并且源自外部开源社区文化，我认为 CLA 的支持者应该解释清楚为什么它们相对于其成本是必要或有益的。我怀疑大多数使用 CLA 的公司只是在没有经过严格审查的情况下模仿同行公司的行为。肤浅的来说，对于那些倾向于采用更复杂的手续、纸张和流程而不管业务成本如何的风险规避律师而言，CLA 是正常的。尽管如此，一些支持 CLA 的论据往往是先进的，值得考虑。

**易于<ruby> 再许可 <rp>  （ </rp> <rt>  relicensing </rt> <rp>  ） </rp></ruby>**：如果管理得当，Apache 风格的 CLA 可以根据管理员的选择，为其提供有效的无限权力来进行分许可。这种做法有时被认为是可取的，因为可能需要依据一些其他开源许可协议再许可该项目。但是，回顾一些涉及大量贡献者的项目（所有这些项目都是在没有使用 CLA 的情况下取得成功）的重要再许可活动的历史案例，易于再许可的价值被夸大了。再许可变得困难很有好处，因为它会让项目产生稳定的法律期望，并鼓励项目在进行重大法律政策变更之前咨询其贡献者社区。在任何情况下，大多数“入站=出站”开源项目在其生命周期中从不尝试再许可，而对于少数这样做的项目来说，再许可将相对轻松，因为通常需要去联系的过去的贡献者的数量不会很大。

**原创追踪**：有的人声称 CLA 使项目能够严格跟踪具有一定法律效益的贡献的来源。目前尚不清楚在这方面使用 CLA 所取得的成就是因为通过保留 Git 提交历史这样的非 CLA 手段无法更好地处理。DCO 似乎更适合跟踪贡献，因为它通常在每个提交的基础上使用，而 CLA 是每个贡献者签署一次，并且在行政上与代码贡献分开。此外，原创跟踪通常被描述为对公众有益，但我知道项目无法对 CLA 接受记录提供透明的随时可行的公开访问。

**许可撤销**：一些 CLA 支持者警告说可能有一天，贡献者可能会试图撤销过去授予的许可。如果关注的范围是大量没有供职公司的具有判断力的个人贡献者，则不清楚为什么 Apache 风格的 CLA 与使用开源许可协议相比提供了更有意义的保护。而且，正如在讨论开源法律政策时提出的许多法律风险一样，这似乎是一种幻想的风险。多年来，我只听说过少数声称的许可撤销尝试活动，所有这些都在贡献者面临社区压力而退步时得到迅速解决。

**未经授权的员工贡献**：这是许可撤销问题的一个特例，最近已成为 CLA 倡导者共同提出的观点。当员工为上游项目提供贡献时，通常雇主拥有项目给予许可的版权和专利，并且只有某些管理人员有权授予此类许可。假设一名员工在未经雇主批准的情况下向项目提供了专有代码，雇主后来发现这一点并要求删除该项贡献或起诉该项目的用户。通过使用类似 [Apache CCLA](https://www.apache.org/licenses/cla-corporate.txt) 及其陈述和签名要求的材料，加上一些适当的审查程序以确定 CCLA 签名者可能被授权签署（我怀疑大多数使用 CLA 的公司没有采取任何有意义的措施），可以将这种未经授权的贡献风险最小化。

基于常识和共同经验，我认为，在今天的几乎所有案例中，员工的贡献都是在雇主的实际或建设性知识基础上和同意下完成的。如果围绕开源软件存在高度诉讼风险，也许应该更加重视这种风险，但开源项目引发的诉讼仍然非常罕见。

更重要的是，我不知道任何针对“入站=出站”项目的非源自涉嫌开源许可协议违规的版权或专利侵权指控因使用CLA而被阻止的案例。特别是，当指出未经授权的贡献风险时，CLA 支持者经常引用专利风险，但 Apache 风格的 CLA 中的专利许可授权的设计范围非常狭窄。此外，企业对开源项目的贡献通常很少，规模较小（因此很容易更换），并且随着时间的推移可能会被丢弃。

### 备选方案

如果您的公司没有对反 CLA 案例买账并且对简单使用“入站=出站”感到不舒服，那么还有其他方法可以替代非对称且管理上繁琐的 Apache 风格的 CLA 要求。使用 DCO 作为“入站=出站”的补充至少消除了厌恶风险的 CLA 倡导者的一些担忧。如果必须使用真正的 CLA，则无需使 用Apach e模式（更不用说它的[怪异衍生物](https://opensource.com/article/19/1/cla-proliferation)）。考虑“[Eclipse 贡献者协议](https://www.eclipse.org/legal/ECA.php)”的非规范核心（基本上是包含在 CLA 内的 DCO），或者<ruby> 软件自由保护协会 <rp>  （ </rp> <rt>  Software Freedom Conservancy </rt> <rp>  ） </rp></ruby>的 [Selenium CLA](https://docs.google.com/forms/d/e/1FAIpQLSd2FsN12NzjCs450ZmJzkJNulmRC8r8l8NYwVW5KWNX7XDiUw/viewform?hl=en_US&formkey=dFFjXzBzM1VwekFlOWFWMjFFRjJMRFE6MQ#gid=0)，它仅仅是对“入站=出站”贡献策略进行仪式化。

---

作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。

译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。