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

就如大家所知，5 月 6 日，微软宣布了新的 Windows 命令行界面 —— Windows Terminal。 无论这一产品本身如何、它的未来将去向何方，至少，它在这两天吸足了眼球。技术媒体争相复制黏贴相关通稿，大量人群涌入项目的 Github 仓库，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 里一条条的报错，和这霸道的官方要求，我仰天大喊：

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

原文观点

今日 Linux 中国发布了一篇文章 《大家都在点赞 Windows Terminal，我决定给你泼一盆冷水》 。该文主要观点引用如下：

• 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 便是我工作学习的地方。

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

大多数 Linux 文件系统在引导时挂载，并在系统运行时保持挂载状态。对于已在 fstab 中配置的任何远程文件系统也是如此。但是，有时你可能希望仅按需挂载远程文件系统。例如，通过减少网络带宽使用来提高性能，或出于安全原因隐藏或混淆某些目录。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 选题：lujun9972 译者：geekpi 校对：wxy

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

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

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

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

来源：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

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

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/

这里需要了解一下 终端 terminal 和 shell 的区别：

在命令行中，shell 提供了访问操作系统内核功能的途径，比如说我们所熟悉的 bash、zsh，都是不同的 shell；而终端则为 shell 提供视觉界面（窗口），比如我们所熟悉的 iTerm2、Linux 桌面上的终端工具等。甚至于我们在 VSCode 中所使用的命令行，也是某种意义上的终端。

我们在 Windows 下所使用的 CMD、Powershell 既然是一个终端，也是一个 Shell，还是同名的脚本系统。

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

为什么 Windows Terminal 不是救世主？

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

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

但是，如果仅仅是一个终端，其实开源社区早已有更多的解决方案，比如 cmder、ConEmu、Hyper 等等，这些 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

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

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

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

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

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

红帽企业 Linux 8 还包括了红帽企业 Linux 系统角色 （ System Role ） ，它可以自动完成许多关于在生产中管理和配置 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 的推出也与 红帽通用基础映像 （ Red Hat Universal Base Image ） 的普遍可用性相吻合，红帽通用基础映像是一个源自红帽企业 Linux 的用户空间映像，用于构建经过红帽认证的 Linux 容器。使用它构建的应用程序可以在任何地方运行。