容器构建有两大趋势：使用基本镜像和从头开始构建。每个都有工程上的权衡。

有人说 Linux 发行版不再与容器有关。像 distroless 和 scratch 容器等可替代的方法，似乎是风靡一时。看来，我们在考虑和做出技术决策时，更多的是基于时尚感和即时的情感满足，而不是考虑我们选择的次要影响。我们应该问这样的问题：这些选择将如何影响未来六个月的维护？工程权衡是什么？这种范式转换如何影响我们的大规模构建系统？

这真让人沮丧。如果我们忘记了工程是一个零和游戏，有可衡量的利弊权衡，有不同方法的成本和收益 —— 这样对我们自己不利，对雇主不利，对最终维护我们的代码的同事不利。最后，我们对所有的维护人员（向维护人员致敬！ ）都是一种伤害，因为我们不欣赏他们所做的工作。

理解问题所在

为了理解这个问题，我们必须首先研究为什么我们使用 Linux 发行版。我将把原因分为两大类：内核和其他包。编译内核实际上相当容易。Slackware 和 Gentoo（ 我的小心脏还是有点害怕）教会了我们这一点。

另一方面，对于一个可用的 Linux 系统需要打包大量的开发软件和应用软件，这可能会让人望而生畏。此外，确保数百万个程序包可以一起安装和工作的唯一方法是使用旧的范例：即编译它并将它作为一个工件（即 Linux 发行版）一起发布。那么，为什么 Linux 发行版要将内核和所有包一起编译呢？很简单：确保事情协调一致。

首先，我们来谈谈内核。内核很特别。在没有编译好的内核的情况下引导 Linux 系统有点困难。它是 Linux 操作系统的核心，也是我们在系统启动时首先依赖的。内核在编译时有很多不同的配置选项，这些选项会对硬件和软件如何在一个内核上运行产生巨大影响。这方面中的第二个问题是，系统软件（如编译器 、C 库和解释器）必须针对内核中内置的选项进行调优。Gentoo 的维基以一种发自内心的方式教我们这一点，它把每个人都变成了一个微型的开发版维护者。

令人尴尬的是（因为我在过去五年里一直在使用容器），我必须承认我最近才编译过内核。我必须让嵌套的 KVM 在 RHEL7 上工作，这样我才能在笔记本电脑上的 KVM 虚拟机中运行 OpenShift on OpenStack 虚拟机，以及我的 Container Development Kit（CDK）。我只想说，当时我在一个全新的 4.X 内核上启动了 RHEL7。和任何优秀的系统管理员一样，我有点担心自己错过了一些重要的配置选项和补丁。当然，我也的确错过了一些东西。比如睡眠模式无法正常工作，我的扩展底座无法正常工作，还有许多其他小的随机错误。但它在我的笔记本电脑上的一个 KVM 虚拟机上，对于 OpenStack 上的 OpenShift 的实时演示来说已经足够好了。来吧，这很有趣，对吧？但我离题了……

现在，我们来谈谈其他的软件包。虽然内核和相关的系统软件可能很难编译，但从工作负载的角度来看，更大的问题是编译成千上万的包，以提供一个可用的 Linux 系统。每个软件包都需要专业知识。有些软件只需要运行三个命令：./configure、make 和 make install。另一些则需要大量的专业知识，从在 etc 中添加用户和配置特定的默认值到运行安装后脚本和添加 systemd 单元文件。对于任何一个人来说，调试好你可能用得到的成千上万种不同软件所需要的一套技能都是令人望而生畏的。但是，如果你想要一个可以随时尝试新软件的可用系统，你必须学会如何编译和安装新软件，然后才能开始学习使用它。这就是没有 Linux 发行版的 Linux。当你放弃使用 Linux 发行版时，那么你就得自己编译软件。

关键是，你必须将所有内容构建在一起，以确保它能够以任何合理的可靠性级别协同工作，而且构建一个可用的包群需要大量的知识。这是任何一个开发人员或系统管理员都无法合理地学习和保留的知识。我描述的每个问题都适用于你的 容器主机（内核和系统软件）和 容器镜像（系统软件和所有其他包）——请注意：在容器镜像中还包含有编译器 、C 库、解释器和 JVM。

解决方案

所以你也看到了，其实使用 Linux 发行版就是解决方案。别再看了，给离你最近的软件包维护者（再次向维护人员致敬！）发张电子卡吧（等等，我是不是把我的年龄告诉别人了？）。不过说真的，这些人做了大量的工作，这真的是被低估了。Kubernetes、Istio、Prometheus，还有 Knative：我在看着你们。你们的时代要来了，到时候你们会进入维护模式，被过度使用，被低估。大约七到十年后，我将再次写这篇文章，可能是关于 Kubernetes 的。

容器构建的首要原则

从零开始构建和从基础镜像构建之间存在权衡。

从基础镜像构建

从基础镜像构建的优点是，大多数构建操作只不过是安装或更新包。它依赖于 Linux 发行版中包维护人员所做的大量工作。它还有一个优点，即六个月甚至十年后的修补事件（使用 RHEL）是运维/系统管理员事件 （yum update），而不是开发人员事件（这需要通过代码找出某些函数参数不再工作的原因）。

你想想，应用程序代码依赖于许多库，从 JSON mung 库到对象关系映射器。与 Linux 内核和 Glibc 不同，这些类型的库很少改变 API 兼容性。这意味着三年后你的修补事件可能会变成代码更改事件，而不是 yum 更新事件。因此让他自己深入下去吧。开发人员，如果安全团队找不到防火墙黑客来阻止攻击，你将在凌晨 2 点收到短信。

从基础镜像构建不是完美的；还有一些缺点，比如所有被拖入的依赖项的大小。这几乎总是会使容器镜像比从头开始构建的镜像更大。另一个缺点是你并不总是能够访问最新的上游代码。这可能会让开发人员感到沮丧，尤其是当你只想使用依赖项中的一部分功能时，但是你仍然不得不将你根本用不着的东西一起打包带走，因为上游的维护人员一直在改变这个库。

如果你是一个 web 开发人员，正在对我翻白眼，我有一个词可以形容你：DevOps。那意味着你带着寻呼机，我的朋友。

Scratch 构建

Scratch 构建的优点是镜像非常小。当你不依赖容器中的 Linux 发行版时，你有很多控制权，这意味着你可以根据需要定制所有内容。这是一个最佳模型，在某些用例中是很有效的。另一个优势是你可以访问最新的软件包。你不必等待 Linux 发行版更新任何内容。是你自己在控制，所以你可以自行选择什么时候去费功夫纳入新的软件。

记住，控制一切都是有代价的。通常，更新到具有新特性的新库会拖如不必要的 API 更改，这意味着修复代码中的不兼容（换句话说，这就像给牦牛剪毛）。在凌晨 2 点应用程序不起作用的时候给牦牛剪毛是不好玩的。幸运的是，使用容器，你可以在下一个工作日回滚并给牦牛剪毛，但它仍会占用你为业务提供新价值、为应用程序提供新功能的时间。欢迎来到系统管理员的生活。

好吧，也就是说，有些时候，Scratch 构建是有意义的。我完全承认，静态编译的 Golang 程序和 C 程序是 scratch/distorless 构建的两个不错的候选程序。对于这些类型的程序，每个容器构建都是一个编译事件。三年后你仍然需要担心 API 的损坏，但是如果你是一个 Golang 商店，你应该有能力随着时间的推移修复问题。

结论

基本上，Linux 发行版做了大量工作来节省你在常规 Linux 系统或容器上的时间。维护人员所拥有的知识是巨大的，而且没有得到真正的赞赏。容器的采用使得问题更加严重，因为它被进一步抽象了。

通过容器主机，Linux 发行版可以让你访问广泛的硬件生态系统，从微型 ARM 系统到 128 核 CPU x86 巨型机箱，再到云服务商的虚拟机。他们提供可工作的容器引擎和开箱即用的容器运行时环境，所以你只需启动你的容器，让其他人担心事情的进展。

对于容器镜像，Linux 发行版为你的项目提供了对大量软件的轻松访问。即使你从头开始构建，你也可能会看到一个包维护人员是如何构建和运送东西的 —— 一个好的艺术家是一个好的偷学者，所以不要低估这项工作的价值。

所以，感谢 Fedora、RHEL（Frantisek，你是我的英雄 ）、Debian、Gentoo 和其他 Linux 发行版的所有维护人员。我很感激你所做的工作，尽管我是个“容器工人”

via: https://opensource.com/article/19/2/linux-distributions-still-matter-containers

作者：Scott McCarty 选题：lujun9972 译者：Chao-zhi 校对：wxy

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

LCTT 的 CI 已经在 Travis CI 上运转了多年，一致保持着良好的使用体验。自 2019 年 Github 推出了自家的 CI 工具 Github Action 后，我们就在考虑将 CI 从 Travis-CI 迁移到 Github，以降低维护和沟通的成本，并借助于 GitHub Action Marketplace 实现更强的功能。

最近，因为 TravisCI 屡屡部署出错，而我们的账户因为使用的较多，已经超出了免费使用的限制，以此为契机，将 CI 从 Travis CI 迁移到 GitHub Action。

项目介绍

Translate Project 是 LCTT 翻译组的主要协作项目，几百位译者通过 GitHub 进行围绕开源、Linux、软件工程等领域的文章翻译，从 2013 年来，累计了大量的提交，致使项目下有非常多的文件。

Translate Project 借助于 CI 帮助译者对基本的文章格式和拉取请求进行检查；并定时执行命令，以进行所有的申请检查，对于超时未完成翻译的工作进行回收；对于文章的状态进行标记，生成相应的徽章。

迁移思路

Travis CI 和 Github Action 在使用方面，其实总体差异不会太大，都是基于 YAML 文件格式来编写配置文件。不过，和 Travis CI 不同的是，Github Action 支持多个不同的配置文件，因此，你可以根据不同的场景，设定不同的配置文件，降低单个配置的文件的复杂度。

此外，由于我们的脚本中依赖了一些 Travis CI 的环境变量，也需要将其替换为 Github Action 中的相应环境变量，从而确保脚本可以运转。

改造实践

1. 分析之前的 CI 流程

我们在 TravisCI 上的 CI 配置文件如图：

总体可以分为三块：

1. 命令区：说明了安装阶段和执行阶段的操作有哪些
2. 条件区：指定了这个配置文件在哪些条件下会生效
3. 部署区：写明了构建产物如何进行部署

在命令区中，有预置的安装过程和后续的执行过程。在安装过程中，安装了一些依赖，并将当前的 pages 资源克隆到本地，以继承上一次构建生成的资料。

在条件区则指明了仅作用于 master 分支。

在部署区便是将前面命令区的执行结果进行部署。

在实际的执行过程中，还会根据环境变量不同，决定是否要执行特定的命令，这部分在后续的改造过程中，就可以调整部署，拆分到不同的文件中。

2. 直接套用配置文件

在完成了基本的分析后，就可以建立新的 Action 配置文件了。由于基本的语法很类似，对于其中的不少内容可以进行直接套用。

比如，我们的配置文件在直接套用后，结果如下

直接套用的文件已经可以直接运行，不过，这里有很多不满足需要的地方，所以需要做一些修改。

3. 恢复 Travis CI 的环境变量

由于我们使用的 Badge 等生成脚本并非我所编写，所以在这一次的迁移中，并不打算对齐进行调整，以避免出现故障。而脚本中依赖了一些变量，需要将其重新设置出来。

Github Action 提供了一些方法，可以让你手动设置环境变量。你可以在你的构建的步骤中，加入如下代码，从而在构建环境中设定 TRAVIS_BRANCH 和 TRAVIS_EVENT_TYPE 环境变量，确保你可以使用这个环境变量。

 - name: Set ENV variables
        run: |
 echo "::set-env name=TRAVIS\_BRANCH::${TRAVIS\_BRANCH:-$(echo $GITHUB\_REF | awk 'BEGIN { FS = "/" } ; { print $3 }')}" 
 echo "::set-env name=TRAVIS\_EVENT\_TYPE::$(if [ "schedule" == "${{ github.event\_name }}" ]; then echo "cron"; else echo "${{ github.event\_name }}"; fi)"

此外，由于 set-env 这个方法相对比较危险，你还需要在环境变量中，开启危险函数的执行。

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      ACTIONS\_ALLOW\_UNSECURE\_COMMANDS: true

4. 拆分配置文件

Github Action 和 TravisCI 不同的一点是你可以将你的 CI 文件拆分成多个文件，从而降低每一个单独的配置文件的复杂度。

根据前面对于流程的分析，可以将我们的 CI 流程拆分成三个部分：

1. 生成 badge 文件，应当跟随每一次提交进行
2. 生成 status 文件，执行时间较长，可以定期执行
3. 根据拉取请求内容进行整理，做核验

则将我们的配置文件拆分成三个不同的文件：

也得益于拆分开，则在 checker 中就可以免于安装一些必要的依赖，从而精简 CI 流程，提升 CI 的执行时间。

5. 测试 CI 的运行情况

在完成了配置文件的编写和拆分后，就可以进行本地的执行测试。Github Action 写完了，难免要执行一下，确保整个流程是正常的。

这个时候你可以安装工具（https://github.com/nektos/act），来在本地执行 Action ，从而确认你的代码执行是正确的。

如果你是 macOS ，只需要执行 brew install act 就可以安装 act 工具，来完成 act 的安装。

安装完成 act ，就可以通过执行 act 命令来在本地执行 Action ，比如，执行 act pull_request 来触发 GitHub 的拉取请求事件

通过本地测试后，再将你的配置文件推送到 GitHub 上，进行生产环境的测试即可。

6. 移除 Travis-CI

通过上述的一些步骤，我们完成了从 Travis CI 到 GitHub Action 的迁移，此时，就可以移除项目根目录中的 .travis.yml 文件，彻底关闭 Travis CI。

7. 替换环境变量

在完成了基本的迁移后，需要对代码中的一些历史问题进行修复。在第三步中，我们对于 Travis-CI 的环境变量进行替换，但长期维护的项目应当尽量将这些未标注上下文的信息替换为有文档标注的，因此，我们需要将其替换。

替换环境变量主要依赖 Github 官方的环境变量说明，你可以参考官方文档。

简化后，配置文件从之前的 27 行，减少至 17 行，变得更加的精简、易懂。

name: LCTT Article Checker

on:
  pull_request:
    branches: [master]
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      PULL_REQUEST_ID: ${{ github.event.number }}
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: "checkout master branch & return to pull request branch"
        run: CURRENT=$(echo ${{github.ref}} |  sed "s|refs/|refs/remotes/|") && git checkout master && git checkout $CURRENT
      - name: run check
        run: sh ./scripts/check.sh;

8. 修改 GitHub 的分支保护条件

为了确保修改符合标准，我们限制了新的拉取请求必须通过 CI 检查，才能合并进入 master 分支，因此，也需要修改相应的分支保护规则，确保设定相应的保护。

一些注意事项

1. 环境变量不同

如果你依赖了环境变量，则需要进行相应的修改。或者可以像我一样，先通过 set-env 来让本地拥有临时的环境变量，后续再逐步进行迁移。

2. Action 运行依赖要注意安全

Action 执行过程中会有两个部分。Action 本身流程依赖于 master 分支，但执行过程中调用的脚本是根据源决定的，因此，从安全角度来看，你应当尽可能将所有的流程放在 Action 中，而不是放在你的源码目录中。

3. 如何触发 CI 的拉取请求检查？

在进行拉取请求测试的时候，需要不断触发不同的提交 ，你可以通过执行 git commit --allow-empty -m "Trigger notification" && git push 来触发一个空白的提交， 推送到 Github 后，就可以再次触发拉取请求的构建，提升构建的效率。

总结

通过对 TravisCI 的流程整理、代码修改等流程，我们将之前的 Travis-CI 迁移至速度更快、性能更好的 GitHub Action ，一方面可以优化我们的工作流，另一方面，也让我们的代码更加简洁明了。

对于还在使用 Travis CI 的项目来说，也可以考虑迁移到 GitHub Action 中，来优化自己的工作流。

参考阅读

• https://mauricius.dev/run-and-debug-github-actions-locally/
• https://jeffrafter.com/working-with-github-actions/
• https://developer.okta.com/blog/2020/05/18/travis-ci-to-github-actions

使用 ceph-ansible 安装 Ceph 存储，并将其部署在树莓派集群中。

Ceph 是一个开源软件存储平台，它在统一的存储集群中提供对象、块和文件系统存储。我第一次使用 Ceph 是在 OpenStack 中集成它的时候。一开始，我很困惑，既然存储设备广泛存在，为什么要使用 Ceph。但在使用了三年多之后，这个平台的稳定性和完整性一再证明了它的价值。

本文将告诉你如何使用 ceph-ansible（Ceph 官方支持的 Ansible playbook）安装 Ceph，并将其部署在树莓派集群中。

材料：

1. 树莓派 4B 4GB 型号四台。
2. 四张 32GB 的 microSD 卡（用于启动操作系统）
3. 四个树莓派外壳，带风扇和散热片（非常重要）
4. 四个树莓派充电器
5. 6 个 32GB U 盘（用于 Ceph OSD 节点）

架构：

关于配置：

• 前端和后端网络都在同一个子网中
• Ceph Monitor 软件使用 4GB 内存的树莓派 4B。
• Ceph OSD 节点使用相同的树莓派型号，但有两个 U 盘用于 OSD 磁盘

使用 ceph-ansible 部署 Ceph

使用 Ceph 的 Ansible 仓库可以让部署变得顺畅简单

1、复制 ssh 密钥到所有服务器

我在所有的服务器上都有一个名为 cephadmin 的共同用户（在此背景下，每个树莓派都是一台服务器）。cephadmin 用户配置了无密码的 sudo，以方便工作。

使用 ssh-keygen 生成密钥后，使用 ssh-copy-id 部署所有密钥。

我使用了一个 Bash for 循环，因为我使用的是一致并递增的主机名：

$ for i in {0..3}; \
  do ssh-copy-id cephadmin@rpi4b4-$i; \
done

你需要每个接受并输入密码，但你可以用 expect 来自动完成。

2、克隆 ceph-ansible 并安装依赖

安装 Git 来克隆仓库：

$ sudo yum install git -y

克隆 ceph-ansible 仓库：

$ git clone https://github.com/ceph/ceph-ansible.git
$ cd ceph-ansible/

我使用的是 CentOS 7 的 AArch64 构建，所以在继续之前，我必须安装一些所需的包。

首先安装 Python pip：

$ sudo yum install python3-pip -y

接着是 ceph-ansible 需要的包：

$ sudo yum install python3-devel libffi-devel openssl-devel -y

最后，ceph-ansible 需要的依赖：

$ pip3 install -r requirements.txt --user

我收到了这个错误：

You are linking against OpenSSL 1.0.2, which is no longer supported by the OpenSSL project.
To use this version of cryptography you need to upgrade to a newer version of OpenSSL. For
this version only you can also set the environment variable
CRYPTOGRAPHY_ALLOW_OPENSSL_102 to allow OpenSSL 1.0.2.

这可能与架构有关，因为我无法在 CentOS 7 虚拟机中复现该错误。

部署时，将 CRYPTOGRAPHY_ALLOW_OPENSSL_102 导出为 True，这样 Ansible 就可以运行了。

$ export CRYPTOGRAPHY_ALLOW_OPENSSL_102=True

3、配置 ceph-ansible 进行部署

现在你可以使用 ceph-ansible 部署 Ceph 了。

复制 site.yml.sample 到 site.yml：

$ mv site.yml.sample site.yml

在 group_vars 目录下创建 all.yml：

$ cat << EOF >> group_vars/all.yml
ceph_origin: repository
ceph_repository: community
ceph_repository_type: cdn
ceph_stable_release: nautilus
monitor_interface: wlan0
public_network: "192.168.100.0/24"
cluster_network: "192.168.100.0/24"
dashboard_enabled: false
configure_firewall: false
EOF

在 group_vars 目录下创建 osds.yml：

$ cat << EOF >> group_vars/all.yml
osd_scenario: collocated
devices:
 - /dev/sda
 - /dev/sdb
EOF

创建一个 inventory 文件：

$ cat << EOF >> inventory
[mons]
rpi4b4-0

[osds]
rpi4b4-1
rpi4b4-2
rpi4b4-3
EOF

在写这篇文章的时候，ceph-ansible 仓库里有一个 bug（根据这个 bug 工单）。你可以通过编辑角色的第 85 行和第 86 行来减轻这个 bug。

    - (wait_for_all_osds_up.stdout | from_json)["osdmap"]["num_osds"] | int > 0
    - (wait_for_all_osds_up.stdout | from_json)["osdmap"]["num_osds"] == (wait_for_all_osds_up.stdout | from_json)["osdmap"]["num_up_osds"]

4、部署 Ceph

用你的 inventory 文件运行 Ansible 剧本：

$ ansible-playbook -i inventory site.yml

15-20 分钟后，你应该看到这个结果：

下面的步骤

之前，我在另一个树莓派集群中手动部署了一个 OpenStack 集群。我希望能将其与这个集群整合在一起。我也在研究用 TripleO 部署。

树莓派、Ansible 和 OpenStack 的可能性是无穷的。开始做你自己的实验，并在评论中告诉我结果如何。

via: https://opensource.com/article/21/1/ceph-raspberry-pi

作者：AJ Canlas 选题：lujun9972 译者：geekpi 校对：wxy

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

FED 编辑器让我可以轻松有效地对我的 FreeDOS 项目进行编码。学习如何充分利用这个灵活的 Linux、Windows 和 DOS 编辑器。

当我不在我的 Linux 桌面上工作的时候，我通常是在为一个旧版的 16 位系统写代码。FreeDOS 是一个开源的 DOS 兼容操作系统，你可以用它来玩经典的 DOS 游戏，运行旧版的商业软件，或者开发嵌入式系统。任何在 MS-DOS 上运行的程序在 FreeDOS 上也应该可以运行。

我是和 DOS 一起长大的。我家的第一台个人电脑是一台 Apple II 兼容机，但我们最终升级到了一台运行 DOS 的 IBM PC。从 1980 年代早期到 1993 年我发现 Linux 这段时间，我做了十多年的 DOS 用户。

Linux 和开源软件所提供的自由度给我留下了深刻的印象。所以当微软在 1994 年宣布 DOS 的终结，以及即将推出的 Windows 95 时，我决定编写自己的开源 DOS。这就是 FreeDOS 的开始。

这么多年过去了，我还在继续研究 FreeDOS。它是一个很好的业余兴趣系统，在这里我可以运行我最喜欢的 DOS 应用和游戏。是的，我仍然在为 FreeDOS 写代码。

我最喜欢的 DOS 编程编辑器是 FED 编辑器。FED 是一个极简的文本编辑器，没有太多的视觉效果。这种精简的方法帮助我充分利用了 DOS 中标准的 80x25 屏幕。当编辑一个文件时，FED 会在屏幕底部显示一行状态行，让你在剩下的 24 行来编写你的代码。FED 还支持彩色语法高亮显示，以不同的颜色显示代码的不同部分，使你更容易发现错别字，以免它们变成错误。

用 FED 写一个纸牌游戏

当你需要菜单时，按下键盘上的 Alt 键，FED 就会在最上面一行显示一个菜单。FED 也支持键盘快捷键，但要注意默认值。例如，Ctrl-C 会关闭文件，Ctrl-V 会改变视图。如果你不喜欢这些默认键，你可以在 Config 菜单中更改键位映射。

按下 Alt 键弹出菜单

如果你不喜欢默认的白底黑字显示，你可以在 Config 菜单下更改颜色。我更喜欢蓝底白字的正文，关键词用亮白色，注释用亮蓝色，特殊字符用青色，数字用绿色。FED 可以很容易地设置你想要的颜色。

我在 DOS 上编程时喜欢的颜色

FED 也是一个折叠式文本编辑器，这意味着它可以折叠或展开我的部分代码，以便我可以看到更多的文件。在函数名上按下 Ctrl-F，FED 会折叠整个函数。折叠在其他代码上也可以使用。我也使用折叠来隐藏 for 和 while 循环或其他流程控制，如 if 和 switch 块。

折叠函数可以让你看到更多的文件

Shawn Hargreaves 从 1994 年至 2004 年编写并维护 FED。Robert Riebisch 从那时起就开始维护 FED。FED 在 GNU GPL 许可下发布，支持 DOS、Linux 和 Windows。

你可以在 https://www.bttr-software.de/products/fed/ 下载 FED。

via: https://opensource.com/article/21/1/fed-editor

作者：Jim Hall 选题：lujun9972 译者：geekpi 校对：wxy

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

无论你在 Python 编程过程中处于什么阶段，这些 Python 热门文章将会对你有很大帮助。

2019 年是 Python 的好年景。根据 GitHub 和 Stack Overflow 的受欢迎资源程度来看，它正在成为全球第二大流行语言。（LCTT 译注：原文发表于 2019 年底，但是这里提及的文章并没有过时。）

“在我们的调查中，Python 作为增长最快的程序设计语言，在程序设计语言中排名再次上升，今年排在 Java 之前，成为第二大最受欢迎的程序设计语言（仅次于 Rust ）。”

— Stack Overflow Insights

同样，Python 的读者人数呈跳跃式激增。以下是按主题分组的 2019 年以来最热门的 Python 文章，供你仔细阅读。

为什么选择 Python ？

在众多的程序设计语言中，是什么使 Python 成为首选呢？从文章的阅读量来看，那就是因为它的灵活性。正如 Jigyasa Grover 解释的那样，Python 开发人员可以使用 多种范例，包括 Seth Kenlon 教程所展示的流行的 面向对象程序设计。

如果你是 Python 的长期用户，并且正在寻找 Python 为什么是完美的程序设计语言的高级例子，那么可以看 Moshe Zadka 的 喜欢 Python 的 5 大理由。如果这还不够的话，你也可以使用功能强大的工具来尝试，无需编写大量代码，例如 Parul Pandey 关于 图像处理 的教程。

配置 Python

随着 Python 的受欢迎程度不断提高，使用它的人越来越多。这些新手中的许多人都是在 Mac 操作系统上进行的，并且正在使用 Moshe 和我写的 Python3 配置向导。

安装 Python 之后，接下来就是决定利用什么工具编写代码。关于文本编辑器和集成开发环境（IDE），有很多选择，但是读者似乎更喜欢图形界面，在有关该主题的文章中，Stephan Avenwedde 的关于 Pythonic 和我关于 JupyterLab 的文章的读者最多。

在对程序设计语言充满信心的途径上，开发人员将不得不面对众多选择，来管理程序设计语言的版本和项目依赖。幸运的是，László Kiss Kollár 的文章 Python 包管理 让其变得更加容易。

当你准备好配置一个具有所有功能的 IDE，以最大限度地利用这门语言时，请一定尝试一下 linter Black，如 Moshe 说的，保持代码的清洁。

小结

无论你处在 Python 程序设计的哪个阶段，这些热门 Python 文章都将为你提供帮助。如果没有至少一次对测试重要性的认可，我无法对此进行总结，为此，Moshe 提供了另一篇 关于 tox 的好文章。

via: https://opensource.com/article/19/12/learn-python

作者：Matthew Broberg 选题：lujun9972 译者：stevenzdg988 校对：wxy

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

简化你的敏捷工作流程，提高你的工作效率。

生产力应用确实可以让你的工作流程变得更加轻松。在本文中，我将分享一些我用来简化工作流程、提高整体生产力的开源应用。本文中所有的生产力应用都是免费的 Linux 生产力应用。

Tomboy/Gnote

Tomboy 是一款可以在 Linux、Windows 和 macOS 上使用的简单记事本应用。它是 GNU LGPLv2 下许可的开源软件。

Tomboy 使用起来非常简单。你写下一张纸条，选择是否将它贴在桌面上，完成后就可以删除它。

它（以及它的克隆版 Gnote）是一个很好的快速记笔记的小程序。很多时候，当我在做某件事情的时候，会有一些想法或思路想要回忆。Tomboy 可以让我快速创建一个笔记，在我忘记之前把我的想法记下来。然后我就可以把这些想法转移到一个更长久的地方。

Joplin

Joplin 是一个开源的记事和待办事项应用。它是跨平台的，可以在 Linux、Windows、macOS、iOS 和 Android 上使用，并且采用 MIT 许可开源。

它可以使用 Dropbox、OneDrive、Nextcloud 等云同步服务进行同步。它很容易安装，可能就在你的 Linux 仓库里。当你在桌面上安装它时，它一个应用中实际包含了两个：你会得到一个标准的图形用户界面 （GUI），或者打开一个终端，在那里使用 Joplin。

桌面版有一个非常漂亮的界面。笔记被组织在笔记本中，这基本上使它们成为你的手册页。而且因为笔记是 Markdown 格式的，所以它们会被渲染，你可以实时编辑它们。我喜欢使用 Markdown，因为它让我写笔记的速度很快。你也可以导出或导入 Joplin 笔记。

Evolution

Evolution 是一款开源的个人信息管理应用，它与 Outlook 非常相似，但我认为更适合我使用。它具有电子邮件、工作、笔记、链接、日历和地址簿功能。它是 LGPL 和其他许可证下的开源软件。

我在运行 Fedora 的台式电脑上使用它。它的效率很高，绝对能帮助我度过繁忙的一天。它让我能够使用 Linux 开展业务；我还能要求什么呢？

要在 Fedora 中使用它，打开一个终端并输入以下命令：

sudo dnf remove evolution
sudo dnf update
sudo dnf install evolution
sudo dnf install evolution-ews

我的常用工具

这些工具是我的主力军，我已经依赖了一段时间。使用它们超越了它们的基本功能，使我更有效率、更有效果、更有生产力。作为一名技术产品经理和敏捷专家，我很自豪，我仍然使用 Linux 和其他开源软件，即使我工作的公司不这样做。

本文原载于 Course Hero，经授权转载。

via: https://opensource.com/article/21/1/open-source-productivity-apps

作者：Taz Brown 选题：lujun9972 译者：geekpi 校对：wxy

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