在 GitHub 和 GitLab 上，不断有来自世界各地的开源应用程序和工具涌现。其中有全新的应用程序，也有针对现有各种被广泛使用的 Linux 程序的替代方案。在本文档中，我会介绍一些针对 top 工具（也就是命令行任务管理器程序）的替代方案。

top 工具的替代方案

在本文中，将会介绍以下 6 种 top 工具的替代方案：

1. Htop
2. Vtop
3. Gtop
4. Gotop
5. Ptop
6. Hegemon

如果后续有更多类似的工具，原作者会在原文进行更新。如果你对此有兴趣，可以持续关注。

Htop

htop 是一个流行的开源跨平台交互式进程管理器，也是我最喜欢的系统活动监控工具。htop 是对原版 top 工具的扩展。它最初只是用于 Linux 系统，后来开发者们不断为其添加对其它类 Unix 操作系统的支持，包括 FreeBSD 和 Mac OS。htop 还是一个自由开源软件，它基于 ncurses 并按照 GPLv2 发布。

和原版的 top 工具相比，htop 工具有这些优势：

• htop 比 top 启动更快
• htop 支持横向滚动和纵向滚动浏览进程列表，以便看到所有的进程和完整的命令行
• 在 top 工具中进行杀死进程、更改进程优先级这些操作时，需要输入进程 ID，而在 htop 工具中则不需要输入
• 在 htop 中可以同时杀死多个进程
• 在 top 中每次输入一个未预设的键都要等待一段时间，尤其是在多个键组成转义字符串的时候就更麻烦了

在很多 Linux 发行版的默认软件仓库中，都带有了 htop。

在基于 Arch 的操作系统中则可以执行以下命令来安装 htop：

$ sudo pacman -S htop

在基于 Debian 的操作系统使用以下命令：

$ sudo apt install htop

在使用 RPM 软件管理的操作系统使用以下命令：

$ sudo dnf install htop

或者

$ sudo yum install htop

在 openSUSE 系统中：

$ sudo zypper in htop

用法

不带任何参数执行 htop 时，会显示如下画面：

$ htop

从图上可以看出，htop 会在界面顶部显示内存、交换空间、任务总数、系统平均负载、系统正常运行时间这些常用指标，在下方则和 top 一样显示进程列表，并且将进程的 ID、用户、进程优先级、进程 nice 值、虚拟内存使用情况、CPU 使用情况、内存使用情况等信息以多列显示出来。如果你想详细了解这些数据的含义，可以在这里阅读参考。

和 top 不同的是，htop 支持对不同的操作使用专有的按键。以下列出一些用于与 htop 交互的快捷键：

• F1、h、?：进入帮助界面。
• F2、Shift+s：进入设置界面。在设置界面中可以配置仪表板界面顶部显示哪些数据，以及设置颜色方案、显示列、显示顺序等等多种参数。
• F3、/：在进程列表中进行搜索。
• F4、\：进入筛选模式。输入一个字符串，筛选出包含这个字符串的进程。进入筛选模式后再按一次 F4 或者 ESC 可以退出筛选模式。
• F5、t：切换默认显示模式和树型显示模式，在树型显示模式下按 + 可以查看子树。
• F6、<、>：依次按照进程 ID、用户、进程优先级、进程 nice 值、CPU 使用率、内存使用率排序显示。
• F7、]：提高所选进程的优先级。
• F8、[：降低所选进程的优先级。
• F9、k：杀死所选进程。可以用 ↑ / ↓ 键选择不同的进程并按 F9 杀死进程。
• F10、q： 退出 htop

以上这些快捷键都在 htop 界面底部显示。

需要注意的是，这其中有一些快捷键可能会与已有的快捷键发生冲突。例如按 F2 之后可能没有进入 htop 的设置界面，而是开始了对终端窗口的重命名。在这种情况下，你可能要更改一下快捷键的设置。

除了以上列出的快捷键以外，还有一些带有其它功能的快捷键，例如：

• u 可以选择显示某个用户的进程。
• Shift+m 可以按照内存使用量对进程列表排序。
• Shift+p 可以按照 CPU 使用量对进程列表排序。
• Shit+t 可以按照进程启动时间对进程列表排序。
• CTRL+l 刷新界面。

htop 的所有功能都可以在启动后通过快捷键来调用，而不需要在启动的时候带上某个参数。当然，htop 也支持带参数启动。

例如按照以下方式启动 htop 就可以只显示某个用户的进程：

$ htop -u <username>

更改界面自动刷新的时间间隔：

$ htop -d 10

看，htop 确实比 top 好用多了。

想了解 htop 的更多细节，可以查阅它的手册页面：

$ man htop

也可以查看它的项目主页 和 GitHub 仓库。

Vtop

vtop 是 top 工具的另一个替代方案。它是一个使用 NodeJS 编写的、自由开源的命令行界面系统活动监视器，并使用 MIT 许可证发布。vtop 通过使用 unicode 中的盲文字符来绘制 CPU 和内存使用情况的可视化图表。

在安装 vtop 之前，需要先安装 NodeJS。如果还没有安装 NodeJS，可以按照这个教程进行安装。

NodeJS 安装完毕之后，执行以下命令安装 vtop：

$ npm install -g vtop

安装好 vtop 就可以执行以下命令开始监控了。

$ vtop

显示界面如下：

如上图所示，vtop 界面和 top、htop 都有所不同，它将不同的内容分别以多个框的布局显示。另外在界面底部也展示了用于与 vtop 交互的所有快捷键。

vtop 有这些快捷键：

• dd ：杀死一个进程。
• ↑、k：向上移动。
• ↓、j：向下移动。
• ←、h ：放大图表。
• →、l：缩小图表。
• g ：跳转到进程列表顶部。
• Shift+g ：跳转到进程列表底部。
• c ：以 CPU 使用量对进程排序。
• m ：以内存使用量对进程排序。

想要了解更多关于 vtop 的细节，可以查阅它的项目主页或者 GitHub 仓库。

Gtop

gtop 和 vtop 一样，都是一个使用 NodeJS 编写、在 MIT 许可下发布的系统活动监视器。

执行以下命令安装 gtop：

$ npm install gtop -g

然后执行以下命令启动：

$ gtop

显示界面如下：

gtop 有一个优点，就是它会以不同的颜色来显示不同的模块，这种表现形式非常清晰明了。

主要的快捷键包括：

• p：按照进程 ID 对进程排序。
• c：按照 CPU 使用量对进程排序。
• m：按照内存使用量对进程排序。
• q、Ctrl+c：退出。

想要了解更多关于 gtop 的细节，可以查阅它的 GitHub 仓库。

Gotop

gotop 也是一个完全自由和开源的图表式系统活动监视器。顾名思义，它是在受到 gtop 和 vtop 的启发之后用 Go 语言编写的，因此也不再对其展开过多的赘述了。如果你有兴趣了解这个项目，可以阅读《gotop：又一个图表式系统活动监视器》这篇文章。

Ptop

有些人对 NodeJS 和 Go 语言的项目可能不太感冒。如果你也是其中之一，你可以试一下使用 Python 编写的 ptop。它同样是一个自由开源的、在 MIT 许可下发布的系统活动监视器。

ptop 同时兼容 Python2.x 和 Python3.x，因此可以使用 Python 的软件包管理器 pip 轻松安装。如果你没有安装 pip，也可以参考这个教程进行安装。

安装 pip 之后，执行以下命令就可以安装 ptop：

$ pip install ptop

又或者按照以下方式通过源代码安装：

$ git clone https://github.com/darxtrix/ptop
$ cd ptop/
$ pip install -r requirements.txt # install requirements
$ sudo python setup.py install

如果需要对 ptop 进行更新，可以这样操作：

$ pip install --upgrade ptop

即使你不执行更新，ptop 也会在第一次启动的时候提示你是否需要更新到最新的版本。

现在可以看一下启动 ptop 后的界面。

$ ptop

就像下面这样：

ptop 的快捷键包括以下这些：

• Ctrl+k：杀死一个进程。
• Ctrl+n：按照内存使用量对进程排序。
• Ctrl+t：按照进程启动时间对进程排序。
• Ctrl+r：重置所有数据。
• Ctrl+f：对进程进行筛选，输入进程的名称就能够筛选出符合条件的进程。
• Ctrl+l：查看所选进程的详细信息。
• g：跳转到进程列表顶部。
• Ctrl+q：退出。

ptop 还支持更改显示主题。如果你想让 ptop 更好看，可以选择你喜欢的主题。可用的主题包括以下这些：

• colorful
• elegant
• simple
• dark
• light

如果需要更换主题（例如更换到 colorful 主题），可以执行以下命令：

$ ptop -t colorful

使用 -h 参数可以查看帮助页面：

$ ptop -h

想要了解更多关于 ptop 的细节，可以查阅它的 GitHub 仓库。

Hegemon

hegemon 是一个使用 Rust 编写的系统活动监视器，如果你对 Rust 感兴趣，也可以了解一下。我们最近有一篇关于 hegemon 的文章，想要详细了解的读者不妨阅读。

总结

以上就是关于 top 工具的 6 个替代方案。我并不会说它们比 top 更好或者可以完全替代 top，但多了解一些类似的工具总是好的。你有使用过这些工具吗？哪个是你最喜欢的？欢迎在评论区留言。

via: https://www.ostechnix.com/some-alternatives-to-top-command-line-utility-you-might-want-to-know/

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

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

一个学生对现代教育并不那么悲观的观点。

最近有些人和我说现代教育会是什么样子，我回答说：就像过去一百年一样。我们为什么会对我们的教育体系保持悲观态度呢？

这不是一个悲观的观点，而是一个务实的观点。任何花时间在学校的人都会有同样的感觉，我们对教导年轻人的方式固执地抵制变革。随着美国学校开始新的一年，大多数学生回到了桌子排成一排排的教室。教学环境主要以教师为中心，学生的进步由卡内基单位和 A-F 评分来衡量，而合作通常被认为是作弊。

我们从哪能够找到证据指出这种工业化模式正在产生所预想的结果？每个孩子都得到个人关注，以培养对学习的热爱，并发展出当今创新经济中茁壮成长所需的技能，我们很可能对现状非常满意。 但是，任何真实客观地看待当前的指标都表明要从基本开始改变。

但我的观点并非悲观。 事实上，非常乐观。

尽管我们可以很容易的阐述现代教育的问题所在，但我也知道一个例子，教育利益相关者愿意走出那些舒适的环境，并挑战这个对变革无动于衷的体系。教师要与同龄人进行更多的合作，并采取更多方式公开透明的对原型创意进行展示，从而为学生带来真正的创新 —— 而不是通过技术重新包装传统方法。管理员通过以社区为中心，基于项目的学习，实现更深入、更紧密的学习实际的应用程序 —— 不仅仅是在孤立的教室中“做项目”。 父母们想把学习的快乐回归到学校的文化，这些文化因强调考试而受到损害。

所有文化变革向来都不容易，特别是在面对任何考试成绩下降（无论统计意义如何重要）都面临政治反弹的环境中，因此人们不愿意承担风险。 那么为什么我乐观地认为我们正在接近一个临界点，我们所需要的变化确实可以克服长期挫败它们的惯性呢？

因为在我们的现代时代，社会中还有其他东西在以前没有出现过：开放的精神，由数字技术催化。

想一想：如果你需要为即将到来的法国旅行学习基本的法语，你该怎么办？ 您可以在当地社区学院注册一门课程或者从图书馆借书，但很有可能，您会用免费在线视频并了解旅行所需的基本知识。人类历史上从未有过免费的按需学习。事实上，人们可以参加麻省理工学院关于“应用数学的专题：线性代数和变异微积分的免费在线课程。报名参加吧！

为什么麻省理工学院、斯坦福大学和哈佛大学等学校提供免费课程？ 为什么人们和公司愿意公开分享曾经严格控制的知识产权？为什么全球各地的人们都愿意花时间，无偿地帮助公民科学项目呢？

David Price 在他那本很棒的书《开放：我们将如何在未来工作和学习》中，清楚地描述了非正式的社交学习如何成为新的学习规范，尤其是习惯于能够及时获取他们需要的知识学习的年轻人。通过一系列案例研究，Price 清楚地描绘了当传统制度不适应这种新现实并因此变得越来越不相关时会发生什么。这是缺失的元素，它能让众包产生积极的颠覆性的影响。

Price 指出（以及人们现在对基层的要求）正是一场开放的运动，人们认识到开放式合作和自由交换思想已经破坏了从音乐到软件再到出版的生态系统。 而且，除了任何自上而下推动的“改革”之外，这种对开放性的期望有可能从根本上改变长期以来一直抵制变革的教育体系。事实上，开放精神的标志之一是，它期望知识的透明和公平民主化，造福所有人。那么，对于这样一种精神而言，还有什么生态系统能比试图让年轻人做好准备，继承这个世界、让这个世界变得更好呢？

当然，也有另一种悲观的声音说，我早期关于教育未来的预测可能确实是短期未来的教育状况。但我也非常乐观地认为，这种说法将被证明是错误的。 我知道我和许多其他志趣相投的教育工作者每天都在努力证明这是错误的。 当我们开始帮助我们的学校转变为开放式组织 —— 从过时的传统模式过渡到更开放、灵活，响应每个学生和他们服务的社区需要的时候，你会加入我吗？

这是适合现代时代的真正教育模式。

via: https://opensource.com/open-organization/18/9/modern-education-open-education

作者：Ben Owens 选题：lujun9972 译者：hkurj 校对：wxy

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

今天，我碰巧分享一个受密码保护的 PDF 文件给我的一个朋友。我知道这个 PDF 文件的密码，但是我不想透露密码。作为代替，我只想移除密码并发送文件给他。我开始在因特网上查找一些简单的方法来从 PDF 文件中移除密码保护。在快速 google 搜索后，在 Linux 中，我带来四种方法来从一个 PDF 文件中移除密码。有趣的事是，在几年以前我已经做过这事情但是我忘记了。如果你想知道，如何在 Linux 中从一个 PDF 文件移除密码，继续读！它是不难的。

在Linux中从一个PDF文件中移除密码

方法 1 – 使用 Qpdf

Qpdf 是一个 PDF 转换软件，它被用于加密和解密 PDF 文件，转换 PDF 文件到其他等效的 PDF 文件。 Qpdf 在大多数 Linux 发行版中的默认存储库中是可用的，所以你可以使用默认的软件包安装它。

例如，Qpdf 可以被安装在 Arch Linux 和它的衍生版，使用 pacman ，像下面显示。

$ sudo pacman -S qpdf

在 Debian、Ubuntu、Linux Mint 上：

$ sudo apt-get install qpdf

现在，让我们使用 qpdf 从一个 pdf 文件移除密码。

我有一个受密码保护的 PDF 文件，名为 secure.pdf。每当我打开这个文件时，它提示我输入密码来显示它的内容。

我知道上面 PDF 文件的密码。然而，我不想与任何人共享密码。所以，我将要做的事是简单地移除 PDF 文件的密码，使用 Qpdf 功能带有下面的命令。

$ qpdf --password='123456' --decrypt secure.pdf output.pdf

相当简单，不是吗？是的，它是！这里，123456 是 secure.pdf 文件的密码。用你自己的密码替换。

方法 2 – 使用 Pdftk

Pdftk 是另一个用于操作 PDF 文件的好软件。 Pdftk 可以做几乎所有的 PDF 操作，例如：

• 加密和解密 PDF 文件。
• 合并 PDF 文档。
• 整理 PDF 页扫描。
• 拆分 PDF 页。
• 旋转 PDF 文件或页。
• 用 X/FDF 数据 填充 PDF 表单，和/或摧毁表单。
• 从 PDF 表单中生成 PDF数据模板。
• 应用一个背景水印，或一个前景印记。
• 报告 PDF 度量标准、书签和元数据。
• 添加/更新 PDF 书签或元数据。
• 附加文件到 PDF 页，或 PDF 文档。
• 解包 PDF 附件。
• 拆解一个 PDF 文件到单页中。
• 压缩和解压缩页流。
• 修复破损的 PDF 文件。

Pddftk 在 AUR 中是可用的，所以你可以在 Arch Linux 和它的衍生版上使用任意 AUR 帮助程序安装它。

使用 Pacaur：

$ pacaur -S pdftk

使用 Packer：

$ packer -S pdftk

使用 Trizen：

$ trizen -S pdftk

使用 Yay：

$ yay -S pdftk

使用 Yaourt：

$ yaourt -S pdftk

在 Debian、Ubuntu、Linux Mint 上，运行：

$ sudo apt-get instal pdftk

在 CentOS、Fedora、Red Hat 上：

首先，安装 EPEL 仓库：

$ sudo yum install epel-release

或

$ sudo dnf install epel-release

然后，安装 PDFtk 应用程序，使用命令：

$ sudo yum install pdftk

或者

$ sudo dnf install pdftk

一旦 pdftk 安装，你可以从一个 PDF 文档移除密码，使用命令：

$ pdftk secure.pdf input_pw 123456 output output.pdf

用你正确的密码替换 123456。这个命令解密 secure.pdf 文件，并创建一个相同的名为 output.pdf 的无密码保护的文件。

参阅：

• How To Merge PDF Files In Command Line On Linux
• How To Split or Extract Particular Pages From A PDF File

方法 3 – 使用 Poppler

Poppler 是一个基于 xpdf-3.0 代码库的 PDF 渲染库。它包含下列用于操作 PDF 文档的命令行功能集。

• pdfdetach – 列出或提取嵌入的文件。
• pdffonts – 字体分析器。
• pdfimages – 图片提取器。
• pdfinfo – 文档信息。
• pdfseparate – 页提取工具。
• pdfsig – 核查数字签名。
• pdftocairo – PDF 到 PNG/JPEG/PDF/PS/EPS/SVG 转换器，使用 Cairo 。
• pdftohtml – PDF 到 HTML 转换器。
• pdftoppm – PDF 到 PPM/PNG/JPEG 图片转换器。
• pdftops – PDF 到 PostScript (PS) 转换器。
• pdftotext – 文本提取。
• pdfunite – 文档合并工具。

因这个指南的目的，我们仅使用 pdftops 功能。

在基于 Arch Linux 的发行版上，安装 Poppler，运行：

$ sudo pacman -S poppler

在 Debian、Ubuntu、Linux Mint 上：

$ sudo apt-get install poppler-utils

在 RHEL、CentOS、Fedora 上：

$ sudo yum install poppler-utils

一旦 Poppler 安装，运行下列命令来解密密码保护的 PDF 文件，并创建一个新的相同的名为 output.pdf 的文件。

$ pdftops -upw 123456 secure.pdf output.pdf

再一次，用你的 pdf 密码替换 123456 。

正如你在上面方法中可能注意到，我们仅转换密码保护的名为 secure.pdf 的 PDF 文件到另一个相同的名为 output.pdf 的 PDF 文件。技术上讲，我们并没有真的从源文件中移除密码，作为代替，我们解密它，并保存它为另一个相同的没有密码保护的 PDF 文件。

方法 4 – 打印到一个文件

这是在所有上面方法中的最简单的方法。你可以使用你存在的 PDF 查看器，例如 Atril 文档查看器、Evince 等等，并打印密码保护的 PDF 文件到另一个文件。

在你的 PDF 查看器应用程序中打开密码保护的文件。转到 “File - > Print” 。并在你选择的某个位置保存 PDF 文件。

于是，这是全部。希望这是有用的。你知道/使用一些其它方法来从从 PDF 文件中移除密码保护吗？在下面的评价区让我们知道。

更多好东西来了。敬请期待！

谢谢！

via: https://www.ostechnix.com/how-to-remove-password-from-a-pdf-file-in-linux/

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

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

如果你正在寻找一种简便的方法去格式化 Markdown 文本，那么这些编辑器可能会满足你的需求。

我的文章、散文、博客等等基本上都是在文本编辑器上使用 Markdown 写作的。当然，我不是唯一使用 Markdown 写作的人。不仅仅无数的人在使用 Markdown，而且也产生了许多服务于 Markdown 的工具。

谁能想到由 John Gruber 和之后的 Aaron Schwartz 创造的一种格式化网页文档的简便的方法如此的受欢迎呢？

我的大多数协作都是在文本编辑器上进行，我能理解为什么 Markdown 编辑器会如此受欢迎 —— 可以快速格式化，可以轻便的将文档转换为其他的格式，可以实时预览。

如果你想用 Markdown 和寻找一个专用的 Markdown 编辑器，那么这里有四个开源编辑器可能会让你写作更加轻松。

Ghostwriter

在我使用过的或试过的 Markdown 编辑器中 Ghostwriter 能排进前三。我已经使用或试了不少。

作为一个编辑器，Ghostwriter 就像一个画布，你可以手动进行编辑和添加格式。如果你不想这么做或者只想学习 Markdown 或者不知道如何添加，你可以从 Ghostwriter 的格式化菜单中选择你想要的格式。

一般的，它只有一个基本的格式：列表、字符格式化和缩进。所以你必须手动的添加标题、代码。而且它有一个有趣的任务列表选项，很多人都在用 Markdown 去创造任务列表，这个功能可以让你更加容易去创造和维护任务列表。

Ghostwriter 区别于其他的 Markdown 编辑器的是它有更多的导出选项。你可以选择你想使用的 Markdown 编译器，包括 Sundown、Pandoc 或 Discount。只需要点击两次，你可以轻松的将你写的内容转换为 HTML5、ODT、EPUB、LaTeX、PDF 或 Word 文档。

Abricotine

如果喜欢简洁的 Markdown 编辑器，你会爱上 Abricotine。但是不要让它的简单性欺骗了你；Abricotine 包含了很多强大的功能。

与其他的编辑器一样，你可以手动格式化文档或使用它的格式化菜单或插入菜单。Abricotine 有一个插入 GitHub 式 Markdown 表格的菜单。它预装了 16 个表样式，你可以在你需要的地方添加行或列。如果这个表看起来有点复杂，你可以使用 Ctrl+Shift+B 去使它看起来更整洁优美。

Abricotine 可以自动显示图片、连接和数学公式。当然你也可以关闭这些选项。可惜的是，这个编辑器只能导出为 HTML 格式。

Mark Text

像 Abricotine 一样，Mark Text 也是一个简洁的 Markdown 编辑器。它有一些你可能没有预料到但能够很好的处理 Markdown 文档的功能。

Mark Text 有点奇怪，它没有菜单或工具条。你需要点击编辑器左上角的弹出式菜单得到命令和功能。它就是让你专注于你的内容。

虽然当你添加内容后，可以在预览区实时看到你所写的内容，但它仍然是一个半所见即所得的编辑器。Mark Text 支持 GitHub 式 Markdown 格式，所以你可以添加表和语法高亮的代码块。在缺省的预览中，编辑器会显示你文档的所有图片。

与 Ghostwriter 相比，你只能将你的文档保存为 HTML 或 PDF 格式。这个输出看起来也不是很糟糕。

Remarkable

Remarkable 复杂性介乎于 Ghostwriter 和 Abricotine 或 Mark Text 之间。它有一个带点现代风格的双栏界面。它有一些有用的特点。

你注意到的第一件事是它受到 Material Design 启发的界面外观。它不是每一个人都能习惯的，老实说：我花费了很多时间去适应它。一旦你适应了，它使用起来很简单。

你可以在工具条和菜单上快速访问格式化功能。你可以使用内置的 11 种 CSS 样式或你自己创造的去定制预览框的样式。

Remarkable 的导出选项是有限的 —— 你只能导出为 HTML 或 PDF 格式文件。然而你可以复制整个文档或挑选一部分作为 HTML，粘贴到另一个文档或编辑器中。

你有最喜爱的 Markdown 编辑器吗？为什么不在评论区分享它呢？

via: https://opensource.com/article/18/11/markdown-editors

作者：Scott Nesbitt 选题：lujun9972 译者：lxfminions 校对：wxy

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

GitHub 网站发布于 2008 年。如果你的软件工程师职业生涯跟我一样，也是晚于此时间的话，Git 可能是你用过的唯一版本控制软件。虽然其陡峭的学习曲线和不直观地用户界面时常会遭人抱怨，但不可否认的是，Git 已经成为学习版本控制的每个人的选择。Stack Overflow 2015 年进行的开发者调查显示，69.3% 的被调查者在使用 Git，几乎是排名第二的 Subversion 版本控制系统使用者数量的两倍。 ¹ 2015 年之后，也许是因为 Git 太受欢迎了，大家对此话题不再感兴趣，所以 Stack Overflow 停止了关于开发人员使用的版本控制系统的问卷调查。

GitHub 的发布时间距离 Git 自身发布时间很近。2005 年，Linus Torvalds 发布了 Git 的首个版本。现在的年经一代开发者可能很难想象“版本控制软件”一词所代表的世界并不仅仅只有 Git，虽然这样的世界诞生的时间并不长。除了 Git 外，还有很多可供选择。那时，开源开发者较喜欢 Subversion，企业和视频游戏公司使用 Perforce （到如今有些仍在用），而 Linux 内核项目依赖于名为 BitKeeper 的版本控制系统。

其中一些系统，特别是 BitKeeper，会让年经一代的 Git 用户感觉很熟悉，上手也很快，但大多数相差很大。除了 BitKeeper，Git 之前的版本控制系统都是以不同的架构模型为基础运行的。《Version Control By Example》一书的作者 Eric Sink 在他的书中对版本控制进行了分类，按其说法，Git 属于第三代版本控制系统，而大多数 Git 的前身，即流行于二十世纪九零年代和二十一世纪早期的系统，都属于第二代版本控制系统。 ² 第三代版本控制系统是分布式的，第二代是集中式。你们以前大概都听过 Git 被描述为一款“分布式”版本控制系统。我一直都不明白分布式/集中式之间的区别，随后自己亲自安装了一款第二代的集中式版本控件系统，并做了相关实验，至少明白了一些。

我安装的版本系统是 CVS。CVS，即 “ 并发版本系统 Concurrent Versions System ” 的缩写，是最初的第二代版本控制系统。大约十年间，它是最为流行的版本控制系统，直到 2000 年被 Subversion 所取代。即便如此，Subversion 被认为是 “更好的 CVS”，这更进一步突出了 CVS 在二十世纪九零年代的主导地位。

CVS 最早是由一位名叫 Dick Grune 的荷兰科学家在 1986 年开发的，当时有一个编译器项目，他正在寻找一种能与其学生合作的方法。 ³ CVS 最初仅仅只是一个包装了 RCS（ 修订控制系统 Revision Control System ) 的 Shell 脚本集合，Grune 想改进这个第一代的版本控制系统。 RCS 是按悲观锁模式工作的，这意味着两个程序员不可以同时处理同一个文件。需要编辑一个文件话，首先得向 RCS 系统请求一个排它锁，锁定此文件直到完成编辑，如果你想编辑的文件有人正在编辑，你就必须等待。CVS 在 RCS 基础上改进，并把悲观锁模型替换成乐观锁模型，迎来了第二代版本控制系统的时代。现在，程序员可以同时编辑同一个文件、合并编辑部分，随后解决合并冲突问题。（后来接管 CVS 项目的工程师 Brian Berliner 于 1990 年撰写了一篇非常易读的关于 CVS 创新的 论文。）

从这个意义上来讲，CVS 与 Git 并无差异，因为 Git 也是运行于乐观锁模式的，但也仅仅只有此点相似。实际上，Linus Torvalds 开发 Git 时，他的一个指导原则是 WWCVSND，即 “ CVS 不能做的 What Would CVS Not Do ”。每当他做决策时，他都会力争选择那些在 CVS 设计里没有使用的功能选项。 ⁴ 所以即使 CVS 要早于 Git 十多年，但它对 Git 的影响是反面的。

我非常喜欢折腾 CVS。我认为要弄明白为什么 Git 的分布式特性是对以前的版本控制系统的极大改善的话，除了折腾 CVS 外，没有更好的办法。因此，我邀请你跟我一起来一段激动人心的旅程，并在接下来的十分钟内了解下这个近十年来无人使用的软件。（可以看看文末“修正”部分）

CVS 入门

CVS 的安装教程可以在其 项目主页 上找到。MacOS 系统的话，可以使用 Homebrew 安装。

由于 CVS 是集中式的，所以它有客户端和服务端之区分，这种模式 Git 是没有的。两端分别有不同的可执行文件，其区别不太明显。但要开始使用 CVS 的话，即使只在你的本地机器上使用，也必须设置 CVS 的服务后端。

CVS 的后端，即所有代码的中央存储区，被叫做 存储库 repository 。在 Git 中每一个项目都有一个存储库，而 CVS 中一个存储库就包含所有的项目。尽管有办法保证一次只能访问一个项目，但一个中央存储库包含所有东西是改变不了的。

要在本地创建存储库的话，请运行 init 命令。你可以像如下所示在家目录创建，也可以在你本地的任何地方创建。

$ cvs -d ~/sandbox init

CVS 允许你将选项传递给 cvs 命令本身或 init 子命令。出现在 cvs 命令之后的选项默认是全局的，而出现在子命令之后的是子命令特有选项。上面所示例子中，-d 标志是全局选项。在这儿是告诉 CVS 我们想要创建存储库路径在哪里，但一般 -d 标志指的是我们想要使用的且已经存在的存储库位置。一直使用 -d 标志很单调乏味，所以可以设置 CVSROOT 环境变量来代替。

因为我们只是在本地操作，所以仅仅使用 -d 参考来传递路径就可以，但也可以包含个主机名。

此命令在你的家目录创建了一个名叫 sandbox 的目录。 如果你列出 sandbox 内容，会发现下面包含有名为 CVSROOT 的目录。请不要把此目录与我们的环境变量混淆，它保存存储库的管理文件。

恭喜！ 你刚刚创建了第一个 CVS 存储库。

检入代码

假设你决定留存下自己喜欢的颜色清单。因为你是一个有艺术倾向但很健忘的人，所以你键入颜色列表清单，并保存到一个叫 favorites.txt 的文件中：

blue
orange
green

definitely not yellow

我们也假设你把文件保存到一个叫 colors 的目录中。现在你想要把喜欢的颜色列表清单置于版本控制之下，因为从现在起的五十年间你会回顾下，随着时间的推移自己的品味怎么变化，这件事很有意思。

为此，你必须将你的目录导入为新的 CVS 项目。可以使用 import 命令：

$ cvs -d ~/sandbox import -m "" colors colors initial
N colors/favorites.txt

No conflicts created by this import

这里我们再次使用 -d 标志来指定存储库的位置，其余的参数是传输给 import 子命令的。必须要提供一条消息，但这儿没必要，所以留空。下一个参数 colors，指定了存储库中新目录的名字，这儿给的名字跟检入的目录名称一致。最后的两个参数分别指定了 “vendor” 标签和 “release” 标签。我们稍后就会谈论标签。

我们刚将 colors 项目拉入 CVS 存储库。将代码引入 CVS 有很多种不同的方法，但这是 《Pragmatic Version Control Using CVS》 一书所推荐方法，这是一本关于 CVS 的程序员实用指导书籍。使用这种方法有点尴尬的就是你得重新 检出 check out 工作项目，即使已经存在有 colors 此项目了。不要使用该目录，首先删除它，然后从 CVS 中检出刚才的版本，如下示：

$ cvs -d ~/sandbox co colors
cvs checkout: Updating colors
U colors/favorites.txt

这个过程会创建一个新的目录，也叫做 colors。此目录里会发现你的源文件 favorites.txt，还有一个叫 CVS 的目录。这个 CVS 目录基本上与每个 Git 存储库的 .git 目录等价。

做出改动

准备旅行。

和 Git 一样，CVS 也有 status 命令：

$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt     Status: Up-to-date

   Working revision:    1.1.1.1 2018-07-06 19:27:54 -0400
   Repository revision: 1.1.1.1 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
   Commit Identifier:   fD7GYxt035GNg8JA
   Sticky Tag:      (none)
   Sticky Date:     (none)
   Sticky Options:  (none)

到这儿事情开始陌生起来了。CVS 没有提交对象这一概念。如上示，有一个叫 “ 提交标识符 Commit Identifier ” 的东西，但这可能是一个较新版本的标识，在 2003 年出版的《Pragmatic Version Control Using CVS》一书中并没有提到 “提交标识符” 这个概念。 （CVS 的最新版本于 2008 年发布的。 ⁵ ）

在 Git 中，我们所谈论某文件版本其实是在谈论如 commit 45de392 相关的东西，而 CVS 中文件是独立版本化的。文件的第一个版本为 1.1 版本，下一个是 1.2 版本，依此类推。涉及分支时，会在后面添加扩展数字。因此你会看到如上所示的 1.1.1.1 的内容，这就是示例的版本号，即使我们没有创建分支，似乎默认的会给加上。

一个项目中会有很多的文件和很多次的提交，如果你运行 cvs log 命令（等同于 git log），会看到每个文件提交历史信息。同一个项目中，有可能一个文件处于 1.2 版本，一个文件处于 1.14 版本。

继续，我们对 1.1 版本的 favorites.txt 文件做些修改（LCTT 译注：原文此处示例有误）：

blue
orange
green
cyan

definitely not yellow

修改完成，就可以运行 cvs diff 来看看 CVS 发生了什么：

$ cvs diff
cvs diff: Diffing .
Index: favorites.txt
===================================================================
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 favorites.txt
3a4
> cyan

CVS 识别出我们我在文件中添加了一个包含颜色 “cyan” 的新行。（实际上，它说我们已经对 “RCS” 文件进行了更改；你可以看到，CVS 底层使用的还是 RCS。） 此差异指的是当前工作目录中的 favorites.txt 副本与存储库中 1.1.1.1 版本的文件之间的差异。

为了更新存储库中的版本，我们必须提交更改。Git 中，这个操作要好几个步骤。首先，暂存此修改，使其在索引中出现，然后提交此修改，最后，为了使此修改让其他人可见，我们必须把此提交推送到源存储库中。

而 CVS 中，只需要运行 cvs commit 命令就搞定一切。CVS 会汇集它所找到的变化，然后把它们放到存储库中：

$ cvs commit -m "Add cyan to favorites."
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v <-- favorites.txt
new revision: 1.2; previous revision: 1.1

我已经习惯了 Git，所以这种操作会让我感到十分恐惧。因为没有变更暂存区的机制，工作目录下任何你动过的东西都会一股脑给提交到公共存储库中。你有过因为不爽，私下里重写了某个同事不佳的函数实现，但仅仅只是自我宣泄一下并不想让他知道的时候吗？如果不小心提交上去了，就太糟糕了，他会认为你是个混蛋。在推送它们之前，你也不能对提交进行编辑，因为提交就是推送。还是你愿意花费 40 分钟的时间来反复运行 git rebase -i 命令，以使得本地提交历史记录跟数学证明一样清晰严谨？很遗憾，CVS 里不支持，结果就是，大家都会看到你没有先写测试用例。

不过，到现在我终于理解了为什么那么多人都觉得 Git 没必要搞那么复杂。对那些早已经习惯直接 cvs commit 的人来说，进行暂存变更和推送变更操作确实是毫无意义的差事。

人们常谈论 Git 是一个 “分布式” 系统，其中分布式与非分布式的主要区别为：在 CVS 中，无法进行本地提交。提交操作就是向中央存储库提交代码，所以没有网络连接，就无法执行操作，你本地的那些只是你的工作目录而已；在 Git 中，会有一个完完全全的本地存储库，所以即使断网了也可以无间断执行提交操作。你还可以编辑那些提交、回退、分支，并选择你所要的东西，没有任何人会知道他们必须知道的之外的东西。

因为提交是个大事，所以 CVS 用户很少做提交。提交会包含很多的内容修改，就像如今我们能在一个含有十次提交的拉取请求中看到的一样多。特别是在提交触发了 CI 构建和自动测试程序时如此。

现在我们运行 cvs status，会看到产生了文件的新版本：

$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt     Status: Up-to-date

   Working revision:    1.2 2018-07-06 21:18:59 -0400
   Repository revision: 1.2 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
   Commit Identifier:   pQx5ooyNk90wW8JA
   Sticky Tag:      (none)
   Sticky Date:     (none)
   Sticky Options:  (none)

合并

如上所述，在 CVS 中，你可以同时编辑其他人正在编辑的文件。这是 CVS 对 RCS 的重大改进。当需要将更改的部分重新组合在一起时会发生什么？

假设你邀请了一些朋友来将他们喜欢的颜色添加到你的列表中。在他们添加的时候，你确定了不再喜欢绿色，然后把它从列表中删除。

当你提交更新的时候，会发现 CVS 报出了个问题：

$ cvs commit -m "Remove green"
cvs commit: Examining .
cvs commit: Up-to-date check failed for `favorites.txt'
cvs [commit aborted]: correct above errors first!

这看起来像是朋友们首先提交了他们的变化。所以你的 favorites.txt 文件版本没有更新到存储库中的最新版本。此时运行 cvs status 就可以看到，本地的 favorites.txt 文件副本有一些本地变更且是 1.2 版本的，而存储库上的版本号是 1.3，如下示：

$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt     Status: Needs Merge

   Working revision:    1.2 2018-07-07 10:42:43 -0400
   Repository revision: 1.3 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
   Commit Identifier:   2oZ6n0G13bDaldJA
   Sticky Tag:      (none)
   Sticky Date:     (none)
   Sticky Options:  (none)

你可以运行 cvs diff 来了解 1.2 版本与 1.3 版本的确切差异：

$ cvs diff -r HEAD favorites.txt
Index: favorites.txt
===================================================================
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.3
diff -r1.3 favorites.txt
3d2
< green
7,10d5
<
< pink
< hot pink
< bubblegum pink

看来我们的朋友是真的喜欢粉红色，但好在他们编辑的是此文件的不同部分，所以很容易地合并此修改。跟 git pull 类似，只要运行 cvs update 命令，CVS 就可以为我们做合并操作，如下示：

$ cvs update
cvs update: Updating .
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.2
retrieving revision 1.3
Merging differences between 1.2 and 1.3 into favorites.txt
M favorites.txt

此时查看 favorites.txt 文件内容的话，你会发现你的朋友对文件所做的更改已经包含进去了，你的修改也在里面。现在你可以自由的提交文件了，如下示：

$ cvs commit
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v <-- favorites.txt
new revision: 1.4; previous revision: 1.3

最终的结果就跟在 Git 中运行 git pull --rebase 一样。你的修改是添加在你朋友的修改之后的，所以没有 “合并提交” 这操作。

某些时候，对同一文件的修改可能导致冲突。例如，如果你的朋友把 “green” 修改成 “olive”，同时你完全删除 “green”，就会出现冲突。CVS 早期的时候，正是这种情况导致人们担心 CVS 不安全，而 RCS 的悲观锁机制可以确保此情况永不会发生。但 CVS 提供了一个安全保障机制，可以确保不会自动的覆盖任何人的修改。因此，当运行 cvs update 的时候，你必须告诉 CVS 想要保留哪些修改才能继续下一步操作。CVS 会标记文件的所有变更，这跟 Git 检测到合并冲突时所做的方式一样，然后，你必须手工编辑文件，选择需要保留的变更进行合并。

这儿需要注意的有趣事情就是在进行提交之前必须修复并合并冲突。这是 CVS 集中式特性的另一个结果。而在 Git 里，在推送本地的提交内容之前，你都不用担心合并冲突问题。

标记与分支

由于 CVS 没有易于寻址的提交对象，因此对变更集合进行分组的唯一方法就是对于特定的工作目录状态打个标记。

创建一个标记是很容易的：

$ cvs tag VERSION_1_0
cvs tag: Tagging .
T favorites.txt

稍后，运行 cvs update 命令并把标签传输给 -r 标志就可以把文件恢复到此状态，如下示：

$ cvs update -r VERSION_1_0
cvs update: Updating .
U favorites.txt

因为你需要一个标记来回退到早期的工作目录状态，所以 CVS 鼓励创建大量的抢先标记。例如，在重大的重构之前，你可以创建一个 BEFORE_REFACTOR_01 标记，如果重构出错，就可以使用此标记回退。你如果想生成整个项目的差异文件的话，也可以使用标记。基本上，如今我们惯常使用提交的哈希值完成的事情都必须在 CVS 中提前计划，因为你必须首先有个标签才行。

可以在 CVS 中创建分支。分支只是一种特殊的标记，如下示：

$ cvs rtag -b TRY_EXPERIMENTAL_THING colors
cvs rtag: Tagging colors

这命令仅仅只是创建了分支（每个人都这样觉得吧），所以还需要使用 cvs update 命令来切换分支，如下示：

$ cvs update -r TRY_EXPERIMENTAL_THING

上面的命令就会把你的当前工作目录切换到新的分支，但《Pragmatic Version Control Using CVS》一书实际上是建议创建一个新的目录来房子你的新分支。估计，其作者发现在 CVS 里切换目录要比切换分支来得更简单吧。

此书也建议不要从现有分支创建分支，而只在主线分支（Git 中被叫做 master）上创建分支。一般来说，分支在 CVS 中主认为是 “高级” 技能。而在 Git 中，你几乎可以任性创建新分支，但 CVS 中要在真正需要的时候才能创建，比如发布项目。

稍后可以使用 cvs update 和 -j 标志将分支合并回主线：

$ cvs update -j TRY_EXPERIMENTAL_THING

感谢历史上的贡献者

2007 年，Linus Torvalds 在 Google 进行了一场关于 Git 的 演讲。当时 Git 是很新的东西，整场演讲基本上都是在说服满屋子都持有怀疑态度的程序员们：尽管 Git 是如此的与众不同，也应该使用 Git。如果没有看过这个视频的话，我强烈建议你去看看。Linus 是个有趣的演讲者，即使他有些傲慢。他非常出色地解释了为什么分布式的版本控制系统要比集中式的优秀。他的很多评论是直接针对 CVS 的。

Git 是一个 相当复杂的工具。学习起来是一个令人沮丧的经历，但也不断的给我惊喜：Git 还能做这样的事情。相比之下，CVS 简单明了，但是，许多我们认为理所当然的操作都做不了。想要对 Git 的强大功能和灵活性有全新的认识的话，就回过头来用用 CVS 吧，这是种很好的学习方式。这很好的诠释了为什么理解软件的开发历史可以让人受益匪浅。重拾过期淘汰的工具可以让我们理解今天所使用的工具后面所隐藏的哲理。

如果你喜欢此博文的话，每两周会有一次更新！请在 Twitter 上关注 @TwoBitHistory 或都通过 RSS feed 订阅，新博文出来会有通知。

修正

有人告诉我，有很多组织企业，特别是像做医疗设备软件等这种规避风险类的企业，仍在使用 CVS。这些企业中的程序员通过使用一些小技巧来解决 CVS 的限制，例如为几乎每个更改创建一个新分支以避免直接提交给 HEAD。 （感谢 Michael Kohne 指出这一点。）

（题图：plasticscm）

via: https://twobithistory.org/2018/07/07/cvs.html

作者：Two-Bit History 选题：lujun9972 译者：runningwater 校对：wxy

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

1. “2015 Developer Survey,” Stack Overflow, accessed July 7, 2018, https://insights.stackoverflow.com/survey/2015#tech-sourcecontrol. ↩
2. Eric Sink, “A History of Version Control,” Version Control By Example, 2011, accessed July 7, 2018, https://ericsink.com/vcbe/html/history_of_version_control.html. ↩
3. Dick Grune, “Concurrent Versions System CVS,” dickgrune.com, accessed July 7, 2018, https://dickgrune.com/Programs/CVS.orig/#History. ↩
4. “Tech Talk: Linus Torvalds on Git,” YouTube, May 14, 2007, accessed July 7, 2018, https://www.youtube.com/watch?v=4XpnKHJAok8. ↩
5. “Concurrent Versions System - News,” Savannah, accessed July 7, 2018, http://savannah.nongnu.org/news/?group=cvs. ↩

为什么在工程中混合角色对用户更好的三个原因。

大多数开源社区没有很多正式的角色。当然，也有一些固定人员帮助处理系统管理员任务、测试、编写文档以及翻译或开发代码。但开源社区的人员通常在不同的角色之间流动，往往同时履行几个角色的职责。

相反，大多数传统公司的团队成员都定义了角色，例如，负责文档、技术支持、质量检验和其他领域。

为什么开源社区采取共享角色的方法，更重要的是，这种协作方式如何影响产品和客户？

Nextcloud 采用了这种社区式的混合角色的做法，我们看到了我们的客户和用户受益颇多。

1、更好的产品测试

每个测试人员都会说测试是一项困难的工作。你需要了解工程师开发的产品，并且需要设计测试案例、执行测试案例并将结果返回给开发人员。完成该过程后，开发人员将进行更改，然后重复该过程，根据需要来回进行多次，直到任务完成。

在社区中，贡献者通常会对他们开发的项目负责，因此他们会对这些项目进行广泛的测试和记录，然后再将其交给用户。贴近项目的用户通常会与开发人员协作，帮助测试、翻译和编写文档。这将创建一个更紧密、更快的反馈循环，从而加快开发速度并提高质量。

当开发人员不断面对他们的工作结果时，会鼓励他们以最大限度地减少测试和调试的方式去书写。自动化测试是开发中的一个重要元素，反馈循环可以确保正确地完成操作：开发人员主观能动的来实现自动化 —— 而不过于简化也不过于复杂。当然，他们可能希望别人做更多的测试或自动化的测试，但当测试是正确的选择时，他们就会这样做。此外，他们还审查对方的代码，因为他们知道问题往往会在以后让他们付出代价。

因此，虽然我不认为放弃专用测试人员更好，但在没有社区志愿者进行测试的项目中，测试人员应该是开发人员，并密切嵌入到开发团队中。结果如何？客户得到的产品是由 100% 有动机的人测试和开发的，以确保它是稳定和可靠的。

2、开发和客户需求之间的密切协作

要使产品开发与客户需求保持一致是非常困难的。每个客户都有自己独特的需求，有长期和短期的因素需要考虑 —— 当然，作为一家公司，你对你的发展方向有想法。你如何整合所有这些想法和愿景？

公司通常会创建与工程和产品开发分开的角色，如产品管理、支持、质量检测等。这背后的想法是，人们在专攻的时候做得最好，工程师不应该为测试或支持等 “简单” 的任务而烦恼。

实际上，这种角色分离是一项削减成本的措施。它使管理层能够进行微观管理，并更能掌握全局，因为他们可以简单地进行产品管理，例如，确定路线图项目的优先次序。（它还创建了更多的会议！）

另一方面，在社区，“决定权在工作者手上”。开发人员通常也是用户（或由用户支付报酬），因此他们自然地与用户的需求保持一致。当用户帮助进行测试时（如上所述），开发人员会不断地与他们合作，因此双方都完全了解什么是可行的，什么是需要的。

这种开放的合作方式使用户和项目紧密协作。在没有管理层干涉和指手画脚的情况下，用户最迫切的需求可以迅速得到满足，因为工程师已经非常了解这些需求。

在 nextcloud 中，客户永远不需要解释两次，也不需要依靠初级支持团队成员将问题准确地传达给工程师。我们的工程师根据客户的实际需求不断调整他们的优先级。同时，基于对客户的深入了解，合作制定长期目标。

3、最佳支持

与专有的或 开放源核心 open core 的供应商不同，开源供应商有强大的动力提供尽可能最好的支持：这是与其他公司在其生态系统中的关键区别。

为什么项目背后的推动者（比如 Collabora 在 LibreOffice 背后，The Qt Company 在 Qt 背后，或者 Red Hat 在 RHEL 背后）是客户支持的最佳来源呢？

当然是直接接触工程师。这些公司并不阻断来自工程团队的支持，而是为客户提供了获得工程师专业知识的机会。这有助于确保客户始终尽快获得最佳答案。虽然一些工程师可能比其他人在支持上花费更多的时间，但整个工程团队在客户成功方面发挥着作用。专有供应商可能会为客户提供一个专门的现场工程师，费用相当高，但一个开源公司，如 OpenNMS 可以在您的支持合同中提供相同级别的服务，即使您不是财富 500 强客户也是如此。

还有一个好处，那就是与测试和客户协作有关：共享角色可确保工程师每天处理客户问题和愿望，从而促使他们快速解决最常见的问题。他们还倾向于构建额外的工具和功能，以满足客户预期。

简单地说，将质量检测、支持、产品管理和其他工程角色合并为一个团队，可确保优秀开发人员的三大优点 —— 从简、精益求精、高度自我要求 laziness，impatience，and hubris —— 与客户紧密保持一致。

via: https://opensource.com/article/18/8/mixing-roles-engineering

作者：Jos Poortvliet 选题：lujun9972 译者：lixinyuxx 校对：wxy

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