Vim 编辑器是很好的 Rust 应用开发环境。

Rust 语言旨在以 C++ 开发人员熟悉的方式实现具有安全并发性和高内存性能的系统编程。它也是 Stack Overflow 的 2019 年开发人员调查中最受欢迎的编程语言之一。

文本编辑器和集成开发环境（IDE）工具使编写 Rust 代码更加轻松快捷。有很多编辑器可供选择，但是我相信 Vim 编辑器非常适合作为 Rust IDE。在本文中，我将说明如何为 Rust 应用开发设置 Vim。

安装 Vim

Vim 是 Linux 和 Unix 中最常用的命令行文本编辑器之一。最新版本（在编写本文时）是 8.2，它在使用方式上提供了前所未有的灵活性。

Vim 的下载页面提供了多种二进制或软件包形式安装。例如，如果使用 macOS，那么可以安装 MacVim 项目，然后通过安装 Vim 插件 扩展 Vim 的功能。

要设置 Rust 进行开发，请下载 Rustup，这是一个方便的 Rust 安装器工具，并在你的终端上运行以下命令（如果你使用 macOS、Linux 或任何其他类 Unix 系统）：

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

在提示中选择安装选项。然后，你将看到如下输出：

stable installed - rustc 1.43.1 (8d69840ab 2020-05-04)

Rust is installed now. Great!

To get started you need Cargo's bin directory ($HOME/.cargo/bin) in your PATH
environment variable. Next time you log in this will be done
automatically.

To configure your current shell run source $HOME/.cargo/env

语法高亮

Vim 能让你通过 .vimrc 文件配置你的运行时环境。要启用语法高亮，请打开 .vimrc 文件（如果不存在就创建一个）：

$ vim ~/.vimrc

在 .vimrc 中添加以下内容并保存：

filetype plugin indent on
syntax on

第一行同时打开检测、插件和缩进配置。第二行启用语法高亮。这些功能将帮助你在 Rust 中管理开发流程。在 Vim 的帮助文件中了解更多信息。

在 Vim 中创建一个 Rust 应用

要使用 Vim 创建一个新的 Rust HelloWorld 应用（hello.rs），请输入：

$ vim hello.rs

输入以下 Rust 代码在控制台中打印 Hello World!：

fn main() {
    println!("Hello World");
}

它看起来应该像这样：

没有语法高亮的样子如下：

你是否注意到 Vim 自动缩进和组织代码？那是因为你在 .vimrc 文件中输入了第一行。

很好！接下来，你将使用 Rust 的包管理器 Cargo 构建此应用。

Cargo 集成

Cargo 使创建应用更加容易。要查看操作方法，请创建一个基于 Cargo 的 HelloWorld 应用。如果你尚未在 Linux 或 macOS 系统上安装 Cargo，请输入：

$ curl https://sh.rustup.rs -sSf | sh

然后使用 Cargo 创建包：

$ cargo new my_hello_world

如果查看目录结构，你会看到 Cargo 自动生成一些源码和目录。如果你安装了 tree，请运行它查看目录结构：

$ tree my_hello_world
my_hello_world
├── Cargo.toml
└── src
    └── main.rs

1 directory, 2 files

在 Vim 中打开 main.rs 源码文件：

$ vim my_hello_world/src/main.rs

它与你在上面手动创建的 HelloWorld 示例中的代码相同。用 Rust with Vim 代替 World：

 fn main() {
      println!("Hello, Rust with Vim");
 }

使用 :wq 保存更改并退出 Vim。

编译你的应用

现在你可以使用 cargo build 编译你的第一个 Rust 应用：

$ cd my_hello_world
$ cargo build

你的终端输出将类似于以下内容：

   Compiling my_hello_world v0.1.0 (/Users/danieloh/cloud-native-app-dev/rust/my_hello_world)

    Finished dev [unoptimized + debuginfo] target(s) in 0.60s

你可能会看到一条警告消息，因为你重用了示例包名 my_hello_world，但现在可以忽略它。

运行应用：

$ target/debug/my_hello_world
Hello, Rust with Vim!

你也可以使用 cargo run 一次构建和运行应用：

$ cargo run
 
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/my_hello_world`
Hello, Rust with Vim!!

恭喜！你在本地的 Vim 编辑器中设置了 Rust IDE，开发了第一个 Rust 应用，并使用 Cargo 包管理器工具构建、测试和运行了它。如果你想学习其他 Cargo 命令，请运行 cargo help。

via: https://opensource.com/article/20/7/vim-rust-ide

作者：Daniel Oh 选题：lujun9972 译者：geekpi 校对：wxy

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

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客第一季（4）：DevOps，拆掉那堵墙的音频脚本。

当应用开发的争斗暂告一段落，横亘在开发者与运维之间的那堵墙开始崩塌。在墙彻底倒塌的时候，墙两边的人都应该学会如何合作，彼此变得亲密无间。

不过到底什么是 DevOps？开发者一方的嘉宾，包括来自微软的 Scott Hanselman 和 Cindy Sridharan（即 @copyconstruct），他们从开发者的角度认为 DevOps 是一种惯实践。而来自运维一方的成员则他们一直在努力捍卫的东西。双方依然存在差异，不过因为 DevOps 的诞生，大家的合作效率会比之前更上一层楼。这集节目讲述了这种方法的诞生对于大家有多重要。

Saron Yitbarek： 请你想象这样一堵墙：这堵墙从你目之所及的最右侧延伸到最左侧。墙比你高，你无法看见墙背后。你知道墙的另一侧有很多很多人，但你不清楚他们是否和你一样，不清楚他们是敌是友。

00:00:30 - Gordon Haff： 开发者创造代码，然后把代码扔过墙丢给运维，之后发生的问题都是运维的责任了。

Richard Henshall： 他们随心所欲，并不真正关心服务质量。

Sandra Henry-Stocker： 墙这两面的人几乎做着相反的工作 —— 一方做出改变，另一方尽可能抵制那些改变。

Richard Henshall： 但对于他们到底想共同达成什么，却没有在同一幅蓝图中规划过。

00:01:00 - Saron Yitbarek： 我是 Saron Yitbarek，这里是《代码英雄》，由红帽公司推出的原创播客栏目。第四期，我们的标题是《DevOps，拆掉那堵墙》。

是的，数十年来，IT 界划分为各种角色。一边是开发者，他们要尽可能快地去创造更多变化。然后另一边是运维团队，他们要去阻止太多改变发生。与此同时，代码在没有充分共鸣和沟通的条件下，被盲目扔过两方之间的墙。怎样才能拆掉这堵墙呢？这需要一个重大的转变。

00:01:30 - Saron Yitbarek： 开源运动震撼了整个战场。上一期，我们看到了新的敏捷方法论，它重视不间断的迭代改进，而这种对速度的要求将迫使我们改变彼此的工作方式。一群彼此孤立的人工作的速度是有极限的，而这个极限是一个问题，因为……

00:02:00 - Richard Henshall： 因为都是为了更快的将产品推向市场、提高敏捷性、更多的迭代，而不是长期而大量的工作。

Saron Yitbarek： Richard Henshall 是 Ansible 的一位产品经理。

Richard Henshall： 是的。还记得你以前下单购买服务器，四个月后到货。所有东西都整合在一起，所以整个堆栈是一个整体，要花几年时间来设计和建造那些东西。现在这种情况已经不存在了，对于很多组织来说，这种方法已经……已经寿终正寝，偶尔拿过来试试，然后放弃它。

00:02:30 - Saron Yitbarek： 如今，像亚马逊这样的公司每分钟都会部署几次新的代码。想象一下，用按部就班的瀑布式工作流，简直不可能完成这些工作。所以为了继续快速完成工作，那些关于稳定性、安全性、可靠性的顾虑都会被运维丢到一边不管。

00:03:00 - Saron Yitbarek： 同时，开发者也没有意识到他们的责任是创造真实环境可用的代码。开发者对稳定性和安全性毫无兴趣，但这些恰恰是我们需要解决的问题。所以，我们最终会有很多无谓的修改，在双方之间来来回回。

想象一下过度分工会如何拖慢公司效率，但开发法者很少被鼓励思考除代码之外的其他事务。

Sandra Henry-Stocker： 他们的目录规模只会越来越臃肿，但他们从不清理。除非已经无法工作才不得不清理。

00:03:30 - Saron Yitbarek： Sandra Henry-Stocker 是位退休的系统管理员，为 IDG 杂志撰稿。

Sandra Henry-Stocker： 我过去经常劝说别人，说，“嘿，你看，你用了这么多的磁盘空间。是不是有什么东西你可以整理一下，这样我们就有更多的存储空间来运行了 —— 因为服务器上的存储空间快用完了。”是的，我们经常经历这些事。

Saron Yitbarek： 归根结底，这是一个心态问题。这种开发者和运维之间的态度分裂，一方不必去理解另一方的担忧。好吧，在过去这还没太大问题，但随着开发速度成为一种重要的优势，这种分裂的文化急需改进。孤立在自己的工作圈子里，效率太低了。

Jonah Horowitz 在 Stripe 的可靠性工程团队工作。他描述了即使开发人员和运维人员想一起工作，他们也无法做到。因为从某种意义上说，他们被安排在对立的团队中。

00:04:30 - Jonah Horowitz： 运维团队经常以正常运行时间和可靠性来衡量，而提高正常运行时间的最大方法之一，就是减少系统的变化量。当然，发布新功能就是在改变系统，而做产品工作的软件工程师有动力去尽快发布尽可能多的功能。所以，当开发和运维的职责不同时，他们自然有了冲突。

00:05:00 - Saron Yitbarek： 开发者致力于新建功能，运营致力于维持运行，两者目标相互矛盾。但就像我说的，由于对速度的需求越来越大，对快速迭代发布的需求越来越大，开发和运维之间的脱节已经到了一个临界点，必须要有所改变。

00:05:30 - Saron Yitbarek： 在 2009 年左右，将开发和运维分开的那堵墙看起来像是监狱的墙。我们需要的是一种新的方法论，它能使开发和运维之间的隔阂顺畅过度，让双方以更快、更整体化的方式工作。

视频平台 Small Town Heroes 的首席技术官 Patrick Debois 为想要拆掉这堵墙的人发起了一场会议。他把这个的脑洞叫做 DevOps Days（开发运维日）。为了便利，他将其缩短为 DevOps，于是这场改革就有了名字。

00:06:00 - Saron Yitbarek： 不过名字并不代表改革的一步，我们知道为什么我们需要 DevOps，但究竟该如何做？我们应该如何将开发和运维结合起来而不引发战争？幸运的是，我有 Scott Hanselman 来指导我。Scott 是微软 .NET 和 ASP.NET 的首席项目经理。

所以，Scott，我认识你确实有几年了，但感觉还是相见恨晚啊。

00:06:30 - Scott Hanselman： 我也是，相见恨晚哈。

Saron Yitbarek： 我想和你聊聊你如何成为一个开发者，和 DevOps 这些年的变化。觉得如何？

Scott Hanselman： 嗯，听上去挺有意思。

00:07:00 - Saron Yitbarek： 好的。我认为究竟什么是 DevOps 是一个好的开场问题。你会怎么定义它呢？

Scott Hanselman： 在 2008 年，维基百科有个关于 DevOps 的定义确实很棒。它说，这是一套“惯例”，目的是在保证质量的前提下，缩短提交变更和变更投入生产之间的时间。所以，如果你想想，假如今天是周二，我检查了一些代码，而这些代码将在 6 月的版本中上线。这就很糟糕了，因为这不是持续集成，而是一年几次的集成。

00:07:30 - Scott Hanselman： 如果你有一个健康的 DevOps 体系，如果你已经有“ 设置 - 上线 set - up ”的惯例，那么你就可以不断地将代码集成到生产中去。那么，你能做什么？你可以定义、创造怎样是最佳“惯例”，这将决定你能否成功。所以，我在周二检查的一些代码，周四就上线了。那么现在，为了保证高质量，最重要的事情就会是 —— 谨慎上线。

00:08:00 - Saron Yitbarek： 这个定义真的很有趣呢，是个“惯例”。但我觉得当我听人们谈论 DevOps 时，它具体一点。他们谈论它就像它是一个角色、一个工作、一个职位或一个头衔。你觉得这与它是一套“惯例”的观点是否有冲突？

Scott Hanselman： 我认为，当一套新的方法或一个新的流行语出现时，人们喜欢把它加在名片上。我不是不尊重那些正在收听这个播客，并且感到被我冒犯、正骂骂咧咧把名片掏出来看的人们。虽然，他们现在可能正要怒盖笔电、退出这个播客。

00:08:30 - Scott Hanselman： 有一个帖子写得非常好，作者是 Brian Guthrie，他是一个脑力劳动者，在 SoundCloud 工作。他是一个超级聪明的人，几天前他在 Twitter 上的帖子中说到 DevOps。他说 DevOps 就是一套惯例，不是一个工作头衔、不是一个软件工具、不是一个你安装的东西、也不是一个团队的名字。

00:09:00 - Scott Hanselman： 他的原话是：“DevOps 不是神奇的‘企业万能药’”。如果你没有好的惯例，如果你没有良好的习惯，你就没有 DevOps。所以，这更多的是一种心态，而不是摆出一个工作头衔，然后“我们要雇佣一个 DevOps 工程师，然后我们要把这些神奇的 DevOps 工程师撒到组织中。虽然整个组织没有意志力，也没有信奉 DevOps 的想法。” 所以，如果你认为 DevOps 是一个工具或者是用来安装的东西，那么你就完全理解错了。

00:09:30 - Saron Yitbarek： 好吧，让我们回到过去，在 DevOps 这个名词出现之前，在我们往名片上写 DevOps 或者把它作为一套“惯例”来讨论之前。在 10 年前，你会如何描述开发者和那些运维人员之间的关系？

Scott Hanselman： 那是相当的水火不容。举个例子，运维控制着生产，但开发人员从来没有接近过生产。我们站在一堵不透明的墙的两侧。我们在开发部的时候，尽可能地去做一些看起来像生产环境能用的东西，但实际上从来没有……从来没有像样的产品。

00:10:00 - Scott Hanselman： 我们有相当多问题。我们的开发环境从各个方面来说都不像生产环境，所以你不可避免地会遇到那些 “嘿，它在生产环境中的工作方式和在开发环境中的不同” 的问题。然后，从开发到投入生产之间的间距是几周几周的长久间隔，所以你的大脑甚至不在正确的频道上。比如说，我在一月份的时候就在研究这个功能，现在四月份才刚刚上线，那么当 bug 不可避免地出现的时候，要等到六月份才能修复，我甚至不记得我们之前在干嘛。

所以运维团队的人，他们的工作是……他们的工作几乎就是有意识地让我们慢下来。好像他们的存在是为了让开发人员更慢，然后他们还觉得我们随时会让生产环境崩坏。

00:11:00 - Saron Yitbarek： 那么为什么会这样呢？是对开发者想要做什么和他们做了什么不了解？还是信任问题？为什么会有这么大的冲突？

Scott Hanselman： 我觉得你已经回答了，而且回答得很到位。你说的很对，确实是信任的问题。我觉得开发人员认为他们是特殊的，或者某些方面比 IT 人员更优越，而 IT 人员认为开发人员不尊重生产。

00:11:30 - Scott Hanselman： 我认为这种文化的产生，一部分来源于高层。他们认为我们是不同的组织，并且我们的目标也不同。我认为软件业正在走向成熟，因为我们都意识到，无论业务是什么，我们写软件都是为了推动业务发展。

所以现在有种 “我们都在往正确的方向推进” 的感觉，就像他们说的，“专注一件产品并做到极致”。但这是需要绝对的信任，可 DevOps 工程师不信任产品工程师来部署代码，对吧？

00:12:00 - Scott Hanselman： 但 DevOps 工程师传统上并不写代码，所以他们并不了解什么被修改了。所以他们对于在各个层面的人都缺乏信任。没有人理解部署过程，人们只信任自己，他们的心态……举个例子，就像“我只信任自己的工作。我不能相信 Saron 的工作，她甚至不知道她在干些什么。我会做完所有的事情。”

00:12:30 - Scott Hanselman： 所以如果没有人真正理解这个系统，那么 全栈工程师 full stack engineer 的概念就是一个神话。但是现在，我们开始将一整个组织称之为全栈。我们已经有了 全产品所有权 full product ownership 这样的名词，敏捷方法论也出现了，也就是说每个人都应该拥有产品。社区对于软件所有权和对于代码的想法都慢慢发生了变化，这种改变带来了一个充满信任的环境。

00:13:00 - Saron Yitbarek： 我是 Saron Yitbarek，你现在收听的是《代码英雄》，来自红帽公司的一档原创播客栏目。所以，要想让 DevOps 发挥出它的潜力，我们就需要双方都有更多的信任，这就意味着要有更多的沟通。回到 Richard Henshall 身上，他认为双方的共情是 DevOps 的基石 。

00:13:30 - Richard Henshall： 一些 DevOps 的从业者，一群真正优秀的从业者，都参与过这两种角色。我认为这才是真正的力量所在 —— 当人们真正做过了两种角色，而不是只看到其中一种。所以，你不该保持孤立，你实际上……你应该去和双方都一起工作一段时间。我想这才是让人恢复同理心的方法。

Saron Yitbarek： 现在，这不仅仅是为了温情的沟通。Richard Henshall 所描述的是行业重点的转向 —— Scott 刚刚提到过。

00:14:00 - Saron Yitbarek： 一个关于 持续集成 continuous integration （CI）的观点。软件不仅要以小批量快速编写和发布，还要以小批量进行快速测试。这意味着，开发人员需要即时反馈他们正在编写的代码在现实世界中的表现。

随着上市时间从几个月缩短到几天，再到几个小时，我们四处寻找一套新的工具，可以将任何可以自动化的元素自动化。

00:14:30 - Gordon Haff： 你需要一个全新的生态系统和工具，来最有效地进行 DevOps。

Saron Yitbarek： Gordon Haff 是一位红帽公司高级工程师。

Gordon Haff： 我们看到有很多巨大的、DevOps 可以利用的新种集合工具和平台，它们都诞生于开源。

Saron Yitbarek： Gordon 是对的。新的集合工具是很庞大，关于开源这点他说的也对。在一个严格的专有系统中，自动化工具是不可能发展的。

00:15:00 - Gordon Haff： 其中有很多监控工具，Prometheus 是其中一个常见的工具。它开始引起很多人兴趣，用于编排服务的 STO 也出自这里。

Saron Yitbarek： GitHub 让你跟踪变化，PagerDuty 管理数字业务，NFS 可以跨网络挂载文件系统，Jenkins 让你自动测试你的构建。

00:15:30 - Saron Yitbarek： 这么多工具，这么多自动化流程。最终的结果是，开发人员可以将他们的变更直接推送到生产现场，自动创建构造，实行经过严格管理的编译与针对性的自动测试。Sandra Henry-Stocker 描述了这是怎样的变化。

Sandra Henry-Stocker： 所以，我可以把我正在工作编写的东西快速部署。我可以只在一个系统上，通过命令行控制许多系统，而不是必须在在很多不同的系统上工作，也不用学习就可以利用网络，将代码部署到其他机器上。

00:16:00 - Sandra Henry-Stocker： 现在，在计算机系统中进行改动更容易了。坐在一个地方，就能实行一切操作。

Saron Yitbarek： 自动化工具已经解决了速度问题。但我不希望我们只赞美工具，而忽略了实际的方法论，文化的转变。Scott Hanselman 和我谈到了这个微妙的界限。

00:16:30 - Saron Yitbarek： 你在这次谈话开始时说，DevOps 是一套惯例，是一种心态，是一种思维方式。听起来，我们创造的工具是我们应该思考和操作方式的具体代码实现。

Scott Hanselman： 我喜欢这句话，你真是个天才。没错，我们以前让产品开发在 Word 文档中写下这些代码是如何工作的。他们写的是规范，对吧？这些文档过期了吗？

00:17:00 - Saron Yitbarek： 没错。（答非所问）

Scott Hanselman： 哈？

Saron Yitbarek： 好吧，我只是很高兴 Scott 刚才说我是天才。但我也确实认为，这些工具几乎是我们文化转变的象征。它们鼓励我们拓宽我们的角色定义。我们开发者已经被迫，至少偶尔关注代码的运行。这样一来，开发和运维的主要职责就部分统一了。事实上，DevOps 的兴起告诉我们的是，在一个速度不断提升的世界里，没有人能够保持孤岛状态。

00:17:30 - Saron Yitbarek： Jonah Horowitz 曾在湾区多家公司工作，包括 Quantcast 和 Netflix。他说即使是世界上一些最大的公司，也从这个角度重新塑造了他们的文化。

Jonah Horowitz： 我们在文化上得到了整个公司的认同，就像，“这就是我们要部署软件的方式，我们将以小批量的方式进行部署，我们将使用这些程序帮助部署。” 如果 DevOps 只是被运营团队所驱动，我不认为它可以……我不认为它可以成功。

00:18:00 - Jonah Horowitz： 这必须成为公司的管理层和领导层所认同的东西才能发挥作用，而这件事很大程度上，意味着一种文化转变。

Saron Yitbarek： 当 MacKenzie 对 800 名 CIO 和 IT 高管进行调查时，80% 的人表示，他们正在规划让自己的一部分下属组织实施 DevOps，超过一半的人计划到 2020 年，在全公司范围内实施。高管们意识到，自动化工具可以提升交付速度。

00:18:30 - Saron Yitbarek： 这些人过去也是这样的人，他们习惯于让一个货板先到达数据中心，然后在新机器上线之前让它在那里放上整整一个月。不过在今天，如果你等待的时间超过 10 分钟，就说明你做错了什么。随着竞争对手的速度增加，没有人能够承受得起落后。

00:19:00 - Saron Yitbarek： 我可以想象，运维团队一定很紧张，因为他们把所有的工具都交给开发人员。运维团队习惯了做成年人，而现在叫他们把车钥匙交给一贯的孩子 —— 开发人员？呀，我想我们开发人员正在学习，如何在不破坏东西的前提下快速移动。但随着 DevOps 革命的尘埃落定，变化最大的可能是运维团队。

00:19:30 - Saron Yitbarek： DevOps 是否真的威胁到了运维的存在？开发是否在用它闪亮的新工具来吃掉运维？Cindy Sridharan 是一位开发者，她写了一篇长篇调查文章来讨论这些问题。在你的文章和博客中，你提到运维人员对事情这样的发展并不一定满意。到底发生了什么？你会说什么？

Cindy Sridharan： 这么说吧，DevOps 的理想是责任共享。开发者和运维将有，就像你知道的，更多的是五五分成，以真正确保软件的整体交付。

00:20:00 - Cindy Sridharan： 我认为很多运维工程师的不快乐源于这样一个事实，那就是这些改变都没有实际功效。他们仍然是总被鸡蛋挑骨头的人，他们仍然是总做苦力工作的那些人，他们还是那些主要肩负着实际运行应用的责任的人，而开发者不一定要做得足够好。

Saron Yitbarek： 这个问题在未来几年将至关重要。DevOps 的作用到底有多大？随着我们的自动化进程，运维的作用是会被削弱，还是会发生转变？

00:20:30 - Saron Yitbarek： 但是我们要记住，DevOps 不仅仅是工具和新技术的应用。这种方法论实际上是在塑造技术，反过来技术也在塑造方法论，这样就有了一个神奇的反馈循环。文化造就了工具，而工具又强化了文化。

00:22:00 - Saron Yitbarek： 最后，我们在节目开头描述的那堵墙，也就是把开发和运维划分开来的那堵墙，我甚至不知道五年后“把你的代码扔过墙”的比喻对一个开发者来说是否有意义，如果五年后大家都听不懂这个比喻，那真是一件大好事。不过目前为止的访谈很有价值，我听到了很多新的故事。

现在说话的是云架构师 Richard Henshall。

Richard Henshall： 我觉得 DevOps 开始让人们意识到对方关心的是什么，我看到了更多对彼此的理解。

00:23:00 - Saron Yitbarek： 现在是系统管理员 Jonah Horowitz。

00:23:00 - Jonah Horowitz： 我认为你需要很棒的技巧来写出真正好的软件，我在与我合作过最棒的开发者身上看到了一件事，那就是他们真的，他们贡献了关于的软件工程新技巧，或者说他们推动了软件开发这个行业的发展。

Saron Yitbarek： 最后一个是系统管理员 Sandra Henry-Stocker。

Sandra Henry-Stocker： 我认为，开发者会变得更加精明、更加谨慎。他们始终要提升自己的技能，我知道这需要很多辛苦的学习。

00:23:30 - Saron Yitbarek： DevOps 是个爱的结晶。原来，在那堵墙的另一边还有一些朋友，很高兴认识你们。所以，坦白一下，我以前总觉得 DevOps 很无聊，就是一堆硬核的自动化脚本和扩展问题。我的抵触情绪有一部分是出于它的实践难度。作为开发者，我每周都要面对一些新出来的工具，一些新的框架。DevOps 一直是那些可怕的、快速变化的一部分。但现在，尤其是听了这些故事之后，我明白了。

00:24:00 - Saron Yitbarek： DevOps 不仅仅是其工具。它是教导我们如何合作，更快地构建更好的产品的方法。

好消息是，随着为你我这样的开发者准备的新平台出现，我们的工作变得更好、更快、更能适应不同的环境，我的业务圈也可以不断扩大。你会看到人们将 DevOps 扩大到安全部分，所以我们能得到 Sec DevOps。或者他们开始包含商务，那我们就得到了 Business DevOps。我们现在要辩论的话题是：对于一个开发者来说，不仅要了解如何使用这些工具，还有了解所有 DevOps 的东西是如何工作的必要吗？以及我们需要所有开发者都去了解这个新世界吗？

00:24:30 - Saron Yitbarek： 这场辩论的结果将决定未来一期《代码英雄》的内容。

你可能已经注意到，在所有关于工具和自动化的谈话中，我漏掉了一些工具。好吧，我把这些留到下一期，当所有这些 DevOps 自动化达到光速时，我们将追踪容器的崛起。

00:25:00 - Saron Yitbarek： 是的，这些都会留到第五期。

《代码英雄》是红帽公司推出的原创播客栏目。想要了解更多关于本期节目和以往节目的信息，请访问 redhat.com/commandlineheroes 。在那里，你还可以注册我们的新闻资讯。想免费获得新剧集的自动推送，请务必订阅该节目。

00:25:30 - Saron Yitbarek： 只要在苹果播客、Spotify、Google Play、CastBox 中搜索《代码英雄》，或者通过其他方式收听，并点击订阅，这样你就能在第一时间知道最新剧集。我是 Saron Yitbarek。感谢您的收听，编程不止。

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。

欢迎加入 LCRH SIG 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。

via: https://www.redhat.com/en/command-line-heroes/season-1/devops-tear-down-that-wall

作者：Red Hat 选题：bestony 译者：LikChung 校对：acyanbird

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

微软多项网络服务将逐步停止支持 IE 11

微软今天宣布，从 2021 年 8 月 17 日起，微软 365 应用和服务将停止支持 IE 11。广受欢迎的通讯工具之一 Microsoft Teams 也将从 2020 年 11 月 30 日起停止支持 IE 11。在规定日期之后，客户通过 IE 11 使用时体验将有所下降。而且在最坏的情况下，他们将无法连接到应用程序和服务。

来源：cnBeta.COM

拍一拍：连微软都放弃了的 IE，你还在用吗？

IBM 宣布 POWER10 处理器

IBM 宣布了它的下一代处理器 POWER10。IBM 早已不再自己生产芯片，POWER10 将由三星制造，采用 7 纳米工艺，是 IBM 第一款使用 7 纳米制程技术的商业处理器。IBM 在新闻稿中称，POWER10 的能效三倍于上一代的 POWER9，采用 POWER10 的系统将在明年上半年上市。

来源：solidot

拍一拍：三倍能效的提高会不会有力地推动 POWER 服务器的使用推广？

Debian GNU/Linux 诞生 27 周年

1993 年 8 月 16 日，当时还是普渡大学本科生的 Ian Murdock 发起了 Debian GNU/Linux 项目，上周日是它的 27 岁生日。

来源：solidot

拍一拍：虽然是最早的 Linux 发行版之一，不过已经度过了 27 年了，还是令人吃惊。

比特币延续涨势，创 13 个月来最高纪录

周一，比特币延续涨势，跃升至一年多来的最高水平。自今年 3 月底部以来，比特币价格已上涨逾两倍。比特币一度上涨 4.4%，至 12424 美元，为 2019 年 7 月以来的最高水平。

来源：新浪美股

拍一拍：最近区块链市场又是一片火爆，历史总是轮回的。

美国邮政早已申请基于区块链的安全投票系统专利

据爆料，美国邮政于 2020 年 2 月 7 日申请了一项“安全投票系统”的专利，该系统使用了区块链访问层。显然，这可能是美国政府欢迎区块链的最强烈信号之一。

来源：新浪财经

拍一拍：真能在美国总统选举中用上才是有力的证明和推动。

Manjaro 还是 Arch Linux？如果说 Manjaro 是基于 Arch 的，那么它和 Arch 又有什么不同呢？请在这篇比较文章中阅读 Arch 和 Manjaro 的不同之处吧。

大多数适合初学者的 Linux 发行版都是基于 Ubuntu 的。随着 Linux 用户经验的增加，一些人开始尝试使用更高级的发行版，主要是在“Arch 领域”。

这个所谓的 “Arch 领域”以两个发行版为主。Arch Linux 本身和 Manjaro。还有其他基于 Arch 的 Linux 发行版，但都没有这两个发行版受欢迎。

如果你在 Arch 和 Manjaro 之间感到困惑，那么这个比较应该能帮助你。

Manjaro 和 Arch Linux：它们有什么不同或相似之处？

我试图在各个方面比较这两种发行版。请记住，我并没有只关注差异，我还指出了它们的相似之处。

两者都是滚动发布的版本，但不是同一种类型

在 Arch 和 Manjaro 中，没有像 Ubuntu 或 Fedora 那样每隔几个月或几年就会有一次“发布”。只要保持你的 Arch 或 Manjaro 系统的更新，你将永远拥有最新版本的操作系统和软件包。你不需要像以往一样担心升级你的安装版本。

如果你打算在某个时候进行全新安装，请记住，Manjaro 和 Arch 都会定期更新它的安装 ISO。这被称为 ISO 刷新，它确保新安装的系统不必安装过去几个月中所有可用的新系统更新。

但 Arch 和 Manjaro 的滚动发布模式是有区别的。

除了社区维护的 Arch 用户软件库 Arch User Repository （AUR）之外，Manjaro 也维护着自己的独立软件库，这些软件库也包含了非 Arch 提供的软件包。那些原本由 Arch 官方软件库提供的流行软件包将首先进行彻底的测试（必要时打上补丁），然后 Manjaro 再次发布，这通常比 Arch 晚两周左右，发布到 Manjaro 自己的稳定软件库供公众使用。

适应这个测试过程的一个后果是，Manjaro 永远不会像 Arch 一样那么激进尝鲜。但这样一来，就使得 Manjaro 比 Arch 稍微稳定一些，也不容易破坏你的系统。

包管理 - Pacman 和 Pamac

Arch 和 Manjaro 都提供了基于命令行的软件包管理工具 Pacman，它是用 C 语言编写的，使用 tar 来打包应用程序。换句话说，你可以使用相同的 pacman 命令来管理两个发行版的软件包。

除了 Pacman，Manjaro 还开发了一个名为 Pamac 的 GUI 应用程序，用于在 Manjaro 上轻松安装软件。这使得使用 Manjaro 比使用 Arch 更容易。

请注意，你也可以在 Arch Linux 中从 AUR 安装 Pamac，但该工具是 Manjaro 的组成部分。

Manjaro 硬件检测工具（MHWD）

Pamac 并不是 Manjaro 团队开发的唯一帮助用户的 GUI 工具。Manjaro 还有一个专门的工具，用于检测硬件并为其推荐驱动程序。

这个硬件检测工具非常有用，可以说是 Manjaro 受到社区喜爱的主要原因之一。它使得检测、安装、使用或从一个驱动切换到另一个驱动都非常简单，让硬件兼容性成为了过去。

驱动程序支持

Manjaro 为 GPU 驱动提供了极大的支持。我们都知道多年来 Linux 在安装驱动程序（特别是 Nvidia）方面存在问题。

当安装 Manjaro 时，它给出了从开源（自由）或非开源（非自由）图形驱动安装开始的选项。当你选择“非自由”时，它会自动检测你的显卡，并为其安装最合适的驱动程序，因此 GPU 可以开箱即用。

由于有了上一节中看到的硬件检测工具，甚至在安装 Manjaro 时，安装显卡驱动会更加容易。

如果你有一个带有 Nvidia Optimus 卡（混合 GPU）的系统，它与 Manjaro 配合良好。你会有很多方式来让它工作。

在 Arch Linux 中，你必须为你的机器安装（如果你能找到）合适的驱动程序。

访问 Arch 用户软件库（AUR）

Arch 用户软件库（AUR）是一个面向基于 Arch 的 Linux 发行版用户的社区驱动的软件库。AUR 的创建是为了组织和分享来自社区的新软件包，并帮助加快流行软件包被纳入社区软件库。

大量进入官方软件库的新软件包都是从 AUR 开始的。在 AUR 中，用户能够贡献自己的软件包构建（PKGBUILD 和相关文件）。

你可以在 Arch 和 Manjaro 中使用 AUR。

桌面环境

好吧！你可以在任何 Linux 发行版上使用几乎所有的桌面环境。Arch 和 Manjaro 也不例外。

然而，一个专门的桌面风格或版本可以让用户更容易地在桌面环境里获得顺畅的体验。

默认的 Arch ISO 并不包含任何桌面环境。例如，你想在 Arch Linux 上安装 KDE，你必须在安装 Arch Linux 时或在之后下载安装它。

而 Manjaro 则为 Xfce、KDE 和 GNOME 等桌面环境提供了不同的 ISO。Manjaro 社区还维护着 MATE、Cinnamon、LXDE、LXQt、OpenBox 等桌面环境的 ISO。

安装程序

Manjaro 是基于 Arch Linux 的，它是兼容 Arch 的，但它不是 Arch。它甚至不是只有一个图形安装程序的预配置版本的 Arch。Arch 并不具备通常的舒适的开箱即用，这也是为什么大多数人喜欢更简单的东西。Manjaro 为你提供了简单的入口，但支持你成为经验丰富的用户或资深用户。

文档和支持

Arch 和 Manjaro 都有自己的维基页面和支持论坛来帮助各自的用户。

虽然 Manjaro 有一个不错的维基文档，但 Arch 维基则不可同日而语。你可以在 Arch 维基中找到关于 Arch Linux 各方面的详细信息。

目标受众

关键的区别在于 Arch 针对的是抱着自己动手的态度的用户，他们愿意阅读文档，自己解决问题。

而 Manjaro 则是针对那些没有那么多经验或者不想花时间组装操作系统的 Linux 用户。

结论

有些人经常说 Manjaro 是给那些不会安装 Arch 的人用的。但我认为这是不对的。不是每个人都想从头配置 Arch，或者没有太多时间。

Manjaro 绝对是一只野兽，但与 Arch 截然不同。快速、强大，并总是保持更新，Manjaro 提供了 Arch 操作系统的所有优点，但特别强调稳定性、用户友好性和可访问性，既适合新手，也适合有经验的用户。

Manjaro 并不像 Arch Linux 那样极简主义。在 Arch 中，你从一个空白的画布开始，手动调整每个设置。当默认的 Arch 安装完成后，你在命令行就有了一个正在运行的 Linux 实例。想要一个图形化桌面环境？那就自己来吧 —— 有很多选择。选择一个，安装，然后配置它。你可以从中学到很多东西，特别是如果你是 Linux 新手的话。你会对系统是如何组合在一起的，以及为什么要以这样的方式安装东西有很好的理解。

我希望你现在对 Arch 和 Manjaro 有了更好的理解。现在，你明白了它们是相似而不同的了吧。

我已经发表了我的看法。不要犹豫，请在评论区分享你的观点。在 Arch 和 Manjaro 之间，你更喜欢哪一个，为什么。

Abhishek Prakash 也对此文补充了内容。

via: https://itsfoss.com/manjaro-vs-arch-linux/

作者：Dimitrios Savvopoulos 选题：lujun9972 译者：wxy 校对：wxy

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

Itch 是独立数字创造者的平台，主要专注于独立游戏。它最初是一个托管、销售和下载独立视频游戏的网站。但是现在，Itch 也提供书籍、漫画、工具、棋类游戏、原声带等来自独立创造者的数字内容。

作为一名用户，你或者能够免费下载这些数字内容，或者按照创造者设定的价格下载。你所有下载和购买的东西都同步到你的账户，以便你可以在任何你想的时间内下载它们。

它有点像 Steam，但是更专注于独立开发者和创作者。

你可以从它的网站浏览 Itch ，但是 Itch 也提供了一个 开源的桌面客户端，有一些额外的优势。使用桌面客户端：

• 你可以浏览游戏和其它的内容，并下载它们到你的系统上。
• 桌面客户端会自动更新所有新功能。
• 你下载的游戏也自动更新。
• 如果你在 Itch 玩基于浏览器的游戏, 那么你可以使用 Itch 桌面客户端离线玩。

在这篇教程中，我将向你展示在 Ubuntu 或其它任何 Linux 发行版上安装 Itch 的步骤。

在 Linux 桌面上安装 Itch

Itch 提供一个名称为 itch-setup 的安装器。你可以从它的下载网页下载这个文件。

• 下载 Linux 版 Itch

这个 itch-setup 文件可以工作在任何的 Linux 发行版上，只要它已经安装有 GTK 3 （libgtk-3-0）。大多数当前的 Linux 发行版应该已经有它了。

在你下载安装文件后，在其上面右击并给予它可执行权限。

现在在这个安装文件上通过双击来运行。它将下载 Itch 的最新版本。

实际花费的时间取决于你的网速。几分钟后，你应该会看到这个屏幕，要求你登录你的 Itch 账号。

在你登录后，你可以浏览游戏和其它的内容，并下载/购买它们。

整个安装过程类似于 在 Ubuntu 上安装 Steam。

你可以在 ~/.itch 文件夹中找到 Itch 的文件。你从 Itch 下载的内容通常位于 ~/.config/itch 。补充一句，~ 意味着你的家目录。

从你的系统中移除 Itch 桌面应用程序

出于某些原因，如果你不想再使用 Itch ，你可以从你的系统中移除它。为此，麻烦的是，你需要使用终端。

打开一个终端，并使用下面的命令：

~/.itch/itch-setup --uninstall

它不会移除你的内容库。如果你想移除下载的游戏和材料，你可以手动删除 ~/.config/itch 文件夹。

rm -r ~/.config/itch

你用 Itch 吗？

Itch 是一个独立创作者的道德平台，也是这种模式的支持者。Itch 使用 “你想付多少钱就付多少钱”，买家可以支付大于或相等内容创作者设置的任何金额。

Itch 也有开放收益分享模式。创作者可以与 Itch 分享部分他们产生的收入，也可以不分享。

就我个人而言，我更喜欢像 Itch 和 Humble Bundle 这些有道德的商店。像 Humble Bundle 一样，Itch 也时不时地进行销售和捆绑销售。这有助于你节省资金，并支持独立开发者和创作者。

你使用 Itch ，还是 Humble Bundle ？你还使用哪种类似的平台？

via: https://itsfoss.com/install-itch-linux/

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

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

英伟达仅用一月时间就组装好全球第七快超算 Selene

该计算机此前在 6 月份成为了世界上速度第七快的超级计算机。在流感大流行期间，仅用了三个半星期的时间，一个跟社会保持距离的六人小组加上一个名为 Trip 的轻便机器人就把整个东西组装好了。它采用的是英伟达商用 GPU 加速 DGX SuperPOD 架构，而不是在 500 强中占主导地位的大量定制 CPU 设计。另外，这台超算在绿色 500 最节能超级计算机排行榜上排名第二。

来源：cnBeta.COM

拍一拍：说不准以后超算也可以像早年间攒机一样了。

微软上线一个开源的开源网站

微软近日上线了一个新的开源网站——网站本身既是开源的，内容也是关于开源的——来展示其如何拥抱开源，同时提供一些开源服务。从首页来看，这一开源网站的核心理念是“开放”、“协作”和“灵活”。微软在网站中陈列了自己的开源项目和服务。网站分为参与、项目、生态、招聘及博客等版块。其中，“参与”页面还会实时显示微软各个 GitHub repo 的最新动态。

来源：开源中国

拍一拍：这个事情不稀奇，只是微软开源路上的一件小事而已（已经被微软的开源新闻麻木了）。

Docker 禁止美国“实体清单”主体使用，但其开源项目不受影响

Docker 公司最新的服务条款 8 月 13 日生效。条款引起关注的地方简单来说就是，Docker 公司提供的服务，禁止美国“实体清单”上的实体使用。从条款中可以明确的是，受限制的是 Docker公司的商业软件及服务，比如 Docker Hub。EAR 管制的是没有实现公开可获取的软件源代码，也就是说，由于开源软件已公布给公众，因此一般不受 EAR 的管制。

来源：开源中国

拍一拍：虽然 Dockerhub 受限不是太大的事情，但是我最担心的是 GitHub/GitLab 的服务会不会也受限？因为虽然它们是免费使用的，但是其实是背后商业公司提供的服务。

文泉驿字体项目宣布停止接受捐款，开发工作近期将重启

文泉驿是一个开源汉字字体项目，由旅美学者房骞骞（FangQ）于 2004 年 10 月创建，集中力量解决 GNU/Linux 高质量中文字体匮乏的状况。文泉驿字体在逐渐完善后就停止了更新，最后更新时间为 2011 年 5 月份。文泉驿官网今天贴出一行短短的公告：“感谢大家对文泉驿计划的支持！目前项目不再接受捐款。我们会在最近一段时间重启文泉驿项目，和发布新版本的字体，请大家重新关注这个项目。(FangQ / 2020年7月23) ”

来源：cnBeta.COM

拍一拍：作为一个完成了历史任务的重要开源项目，是时候整装再发，迎接新的时代对开源字体的需求了。