Signal 是一款智能手机上的安全开源聊天应用。它还提供了适用于 Linux、Windows 和 macOS 的独立桌面应用。在本文中，我们来看看它的功能和可用性。

对于关注隐私的人来说，Signal 是 WhatsApp（和 Telegram）的绝佳替代品

Signal 是一款关注隐私的开源应用。像爱德华·斯诺登这样的隐私权倡导者建议使用它。

它可能没有 Telegram 或 WhatsApp 这么多的功能。但是，如果你想在交流时增强隐私，这是一个可靠的开源方案。

你可以在智能手机（iOS/Android）上安装，也可以在 Linux、Windows 和 macOS 上安装。

Signal 的功能

注意： 某些功能是智能手机特有的。你可能无法在桌面应用上看到所有功能。

另请注意，目前，Signal 需要电话号码才能注册。如果你不想公开自己的私人电话号码，则可以使用 Google 语音或类似服务。

正如我已经提到的，这是为增强你的隐私而量身定制的。因此，用户体验可能不是你见过“最佳”的。但是，从隐私/安全角度考虑，我认为这是一个不错的选择。

消失的消息

你可以为对话中的消息设置一个计时器，以便根据它自动删除消息。

本质上，对话中的任何人都可以激活此功能。因此，你可以控制对话中的消息时保留还是消失。

用作默认短信应用

如果你想在短信中使用开源应用，那么只需进入 Signal 的设置，并将其设置为短信和彩信的默认设置。

屏幕安全

有一个巧妙的功能可以阻止应用内截图，它就是“屏幕安全”。

如果你开启它，那么你将无法为应用中的任何对话截图。你可以从应用设置中找到启用或禁用它的选项。

它可能并不是对所有人有用，但你可以尝试一下。

安全数字

如果你想与朋友一起验证加密的安全性，只需点击个人资料并向下滚动找到“查看安全数字”。

你可以扫描验证或者看一眼并标记为已验证。

锁定消息

如果你使用了锁（密码/指纹）来保护应用，那么即使你的设备已解锁，你也无法在通知中看到消息。

因此，当 Signal 处于锁定状态收到通知时，你会注意到通知的内容为 “Locked Message”，这对于注重隐私的用户来说是一个加分项。

其它功能

如你所期待的聊天应用，你可以使用几个标签，并且可以根据需要创建一个组。但是，你无法管理你的组，你只能添加成员和更改群头像。

此外，Signal 还为其应用支持生物识别。

在 Ubuntu/Linux 上安装 Signal

不幸的是，你无法在你的 Linux 发行版上找到 .deb 或者 .AppImage。因此，你需要根据官方安装说明在终端上安装。

在终端中输入以下内容：

curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add -
echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | sudo tee -a /etc/apt/sources.list.d/signal-xenial.list
sudo apt update && sudo apt install signal-desktop

只需在终端中一个接一个地复制并粘贴命令。

Download Signal for Other Devices

我对 Signal 的想法

我已经使用 Signal 有几年了，它的功能已经得到了改善。但是，我仍然认为可以改善用户体验。

在隐私方面，（在我看来）这绝对是我们已有软件的一个很好的替代方案。你可以尝试一下，看看它的使用效果如何。

如果你想尝试一下它，也可以看看它的 GitHub 页面以获取最新的开发和 beta 版本。

与 WhatsApp 甚至 Linux 上的 Telegram 相比，Signal 可能不是流行的聊天应用。但是，你可以自己尝试一下，并鼓励你的朋友使用它。

你尝试过了吗？在下面的评论中，让我知道你对 “Signal” 的看法。

via: https://itsfoss.com/signal-messaging-app/

作者：Ankush Das 选题：lujun9972 译者：geekpi 校对：wxy

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

这份礼物指南使你轻松完成节日礼物的采购，它们可给婴儿、儿童、青少年及年龄更大的人们带来创造和创新能力。

还在纠结这个假期给年轻人买什么礼物？这是我精选的开源礼物，这些礼物将激发未来的创意和灵感。

蜂鸟机器人套件

年龄：8 岁 - 成人

这是什么：蜂鸟机器人套件是一套完整的机器人套件，带有微控制器、电机、LED 和传感器。机器人的大脑具有特殊的端口，小手可以轻松地将其连接到机器人的组件上。蜂鸟套件并没有身体，而是鼓励用户自己创建一个。

为什么我喜欢它：蜂鸟可以使用多种编程语言 —— 从可视化编程（BirdBlox、MakeCode、Snap）到代码编程（Python 和 Java）—— 可以随着用户编码技能的提高而可扩展。所有组件均与你在电子商店中找到的组件完全相同，没有像其他机器人套件那样被塑料所遮盖。这使机器人的内部工作不再神秘，并在你需要时易于采购更多零件。

由于没有固定组装项目，因此蜂鸟是发挥创造力的完美机器人。

蜂鸟具有开源的软件和固件。它适用于 Linux、Windows、Mac、Chromebook、Android 和 iOS。

费用：起价为 99 美元。

Makey Makey 经典版

年龄： 6岁 - 成人

这是什么： Makey Makey 经典版可将任何导电物体（从棉花糖到你的朋友）变成计算机钥匙。

你可以使用鳄鱼夹将 Makey Makey 连接到你选择的导电物体上。然后，通过同时触摸两个导电物体来闭合接地和任何触发键之间的电路。Makey Makey 是一种安全的方法，可以安全地在家中探索电力，同时创造与计算机进行交互的有趣方式。

为什么我喜欢它： Makey Makey 可以与 Scratch 开发的视频游戏搭配使用，以创建独特的控制器，使用户进一步沉浸在游戏中。从用卫生纸卷和铝箔制成的工具到互动艺术和故事，可能性是无限的。它可以在具有 USB 端口的 Linux、Windows 和 Mac 计算机上使用。

费用： 49.95 美金

Arduino Uno

年龄： 10 岁 - 成人

这是什么： Arduino 是随同电子套件购买的微控制器，也可以单独购买，它们具有多种版本，而我最喜欢 Arduino Uno。你可以根据需要从任何电子商店购买其他组件，例如 LED、电机和传感器。

为什么我喜欢它： Arduino Uno 的文档很完善，因此创客们很容易在线上找到教程。Arduino 可以实现从简单到复杂的各种电子项目。Arduino 具有开源的固件和硬件。它适用于 Linux、Mac 和 Windows。

费用： 主板的起价为 22.00 美元。总成本取决于项目和技能水平。

DIY 创客套件

年龄：8 岁 - 成人

这是什么：当今许多创客、发明家和程序员都是从鼓捣碰巧出现在身边东西开始的。你可以快速前往最近的电子产品商店，为家里的年轻人创建一套出色的创客工具包。这是我的创客工具包中的内容：

• 护目镜
• 锤子
• 钉子和螺丝
• 碎木
• 螺丝起子
• 电线
• LED
• 压电蜂鸣器
• 马达
• 带引线的 AA 电池组
• 剪线钳
• 纸板
• 美纹纸胶带
• 废布
• 纽扣
• 线程
• 针
• 拉链
• 钩子
• 一个很酷的工具盒，用来存放所有东西

我为什么喜欢它：还记得小时候，你把父母带回家的空纸箱变成了宇宙飞船、房屋或超级计算机吗？这就是为大孩子们准备的 DIY 创客工具包。

原始的组件使孩子们可以尝试并运用他们的想象力。DIY 创客工具包可以完全针对接收者定制。可以放入一些接受这份礼品的人可能从未想到过用之发挥创意的某些组件，例如为下水道提供一些 LED 或木工结构。

费用：不等

启发式游戏篮

年龄： 8 个月至 5 岁

这是什么：启发式游戏篮充满了由天然、无毒材料制成的有趣物品，可供婴幼儿使用其五种感官进行探索。这是一种开放式、自娱自乐的游戏。其想法是，成年人将监督（但不指导）儿童使用篮子及其物品半小时，然后将篮子拿走，等下一次再玩。

创建带有常见家用物品的可爱游戏篮很容易。尝试包括质地、声音、气味、形状和重量各不相同的物品。这里有一些想法可以帮助您入门。

• 漏勺或脊状柳条篮可容纳所有物品
• 木勺子
• 金属打蛋器和汤匙
• 板刷
• 海绵
• 小型鸡蛋纸箱
• 纸板管
• 小擀面杖
• 带纹理的毛巾
• 岩石
• 手铃
• 钩针桌巾
• 带盖的小铁罐 游戏篮中不应包括任何容易破碎的东西或足够小到可以装入纸巾卷的东西，因为它们有窒息危险，应将所有物品彻底清洁后再交给孩子。

我为什么喜欢它：游戏篮非常适合感官发育，并可以帮助幼儿提出问题和探索周围的世界。这是培养创客思维方式的重要组成部分！

很容易获得适合这个游戏篮的物品。你可能已经在家中或附近的二手商店里找到了很多有趣的物品。幼儿使用游戏篮的方式与婴儿不同。随着孩子们开始模仿成人生活并通过他们的游戏讲故事，这些物品将随孩子一起成长。

费用：不等

《Hello Ruby》

年龄：5-8 岁

这是什么： 《Hello Ruby：编码历险记》是 Linda Liukas 的插图书，通过有趣的故事讲述了一个遇到各种问题和朋友（每个都用一个码代表）的女孩，向孩子们介绍了编程概念。Liukas 还有其他副标题为《互联网探险》和《计算机内的旅程》的《Hello Ruby》系列书籍，而《编码历险记》已以 20 多种语言出版。

为什么我喜欢它：作者在书中附带了许多免费、有趣和无障碍的活动，可以从 Hello Ruby 网站下载和打印这些活动。这些活动教授编码概念、还涉及艺术表达、沟通、甚至时间安排。

费用：精装书的标价为 17.99 美元，但你可以通过本地或在线书店以较低的价格买到这本书。

《编程少女：学会编程和改变世界》

年龄：10 岁 - 成人

内容是什么：由《编程少女》的创始人 Reshma Saujani 撰写，《编程少女：学会编程和改变世界》为年轻女孩（以及男孩）提供了科技领域的实用信息。它涵盖了广泛的主题，包括编程语言、用例、术语和词汇、职业选择以及技术行业人士的个人简介和访谈。

为什么我喜欢它：本书以讲述了大多数面向成年人的网站都没有的技术故事。这些技术涉及许多学科，对于年轻人来说，重要的是要了解他们可以使用它来解决现实世界中的问题并有所作为。

成本：精装书的标价为 17.99 美元，平装书的标价为 10.99 美元，但你可以通过本地或在线书店以更低的价格找到。

via: https://opensource.com/article/19/11/maker-gifts-kids

作者：Jess Weichler 选题：lujun9972 译者：wxy 校对：wxy

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

今年，准备好，用出色的 Ansible 自动化技能装备自己的技能包吧。

今年我关注了大量关于 Ansible 的文章，以下这些内容都值得每个人学习，无论是否是 Ansible 的新手。

这些文章值得大家标记为书签，或者设置个计划任务（亦或者是设置一个 Tower/AWX 任务），用来提醒自己常读常新。

如果你是 Ansible 的新手，那么就从这些文章开始着手吧：

• 《Ansible 快速入门指南》拥有一些对新手非常有用的信息，同时还介绍了一些更高级的话题。
• 《你需要知道的 10 个 Ansible 模块》和《5 个 Ansible 运维任务》（译文）这两篇文章有每一位 Ansible 管理员都应该熟悉并认真研习的一些最基础的 Ansible 功能。
• 《如何使用 Ansible 记录流程》这篇文章是对一些额外话题的纵览，我猜你一定会感到很有趣。

剩余的这些文章包含了更多高级的话题，比如 Windows 管理、测试、硬件、云和容器，甚至包括了一个案例研究，如何管理那些对技术有兴趣的孩子的需求。

我希望你能像我一样好好享受 Ansible 带来的乐趣。不要停止学习哦！

1. 《Ansible 如何为我的家庭带来和平》这个异想天开的案例，你能看到如何利用 Ansible 为孩子们快速部署一个新的笔记本（或者重装旧笔记本）
2. Taz Brown 和 Abner Malivert 的《适用于 Windows 管理员的 Ansible》：你知道 Ansible 也可以管理 Windows 的节点吗？这篇文章以部署一个 IIS 为案例，阐述了基础的 Ansible 服务器和 Windows 客户端的安装。
3. Shashank Hegde 的《你需要知道的 10 个 Ansible 模块》是个学习你最应该知道的那些最常见、最基础的 Ansible 模块的好文章。运行命令、安装软件包和操作文件是许多有用的自动化工作的基础。
4. Marco Bravo 的《如何使用 Ansible 记录流程》：Ansible 的 YAML 文件易于阅读，因此它们可以被用于记录完成任务所需的手动步骤。这一特性可以帮助你调试与扩展，这令工作变得异常轻松。同时，这篇文章还包含关于测试和分析等 Ansible 相关主题的指导。
5. Clement Verna 的《使用 Testinfra 和 Ansible 验证服务器状态》（译文）：测试环节是任何一个 CI/CD DevOps 流程不可或缺的一部分。所以为什么不把测试 Ansible 的运行结果也纳入其中呢？这个测试架构 Testinfra 的入门级文章可以帮助你检查配置结果。
6. Mark Phillips 的《Ansible 硬件起步》：这个世界并不是完全已经被容器和虚拟机所占据。许多系统管理员仍然需要管理众多硬件资源。通过 Ansible 与一点 PXE、DHCP 以及其他技巧的结合，你可以创建一个方便的管理框架使硬件易于启动和运行。
7. Jairo da Silva Junior 的《你需要了解的关于 Ansible 模块的知识》：模块给 Ansible 带来了巨大的潜力，已经有许多模块可以拿来利用。但如果没有你所需的模块，那你可以尝试给自己打造一个。看看这篇文章吧，它能让你了解如何从零开始打造自己所需的模块。
8. Mark Phillips 的《5 个 Ansible 运维任务》（译文）：这是另一个有关于如何使用 Ansible 来管理常见的系统操作任务的文章。这里描述了一系列可以取代命令行操作的 Tower（或 AWX）的案例。
9. Chris Short 的《Ansible 快速入门指南》是个可以下载的 PDF 文档。它可以作为一本随时拿来翻阅的手册。这篇文章的开头有助于初学者入门。同时，还包括了一些其他的研究领域，比如模块测试、系统管理任务和针对 K8S 对象的管理。
10. Mark Phillips 的《Ansible 参考指南，带有 Ansible Tower 和 GitHub 的 CI/CD，等等》：这是一篇每月进行总结更新的文章，充满了有趣的链接。话题包括了 Ansible 的基础内容、管理 Netapp 的 E 系列存储产品、调试、打补丁包和其他一些相关内容。文章中还包括了一些视频以及一些聚会的链接。请查看详情。

如果你也有一些你喜爱的 Ansible 文章，那请留言告诉我们吧。

via: https://opensource.com/article/19/12/ansible-resources

作者：James Farrell 选题：lujun9972 译者：BrunoJu 校对：wxy

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

以及，对 2019 年最受欢迎的 Kubernetes 文章的回顾。

你是怎么追踪一个广受欢迎的项目（如 Kubernetes）的发展轨迹？你是怎么了解它发展到什么程度了？如果你在为这个项目作贡献或加入了特殊兴趣组（SIG），可能你会在潜移默化中了解到它的发展轨迹，但如果你的全日工作不涉及到为 Kubernetes 作贡献，那么你可能需要一点关于未来的预测来帮助你了解。对于一个诸如 Kubernetes 的快速发展的项目，年末是回顾过去的一年和展望新的一年的最好时机。

今年，Kubernetes 取得了很大的进展。除了去查看源码、文档、会议笔记，你也可以去浏览博客。为了深入了解，我在 Opensource.com 上找到了 Kubernetes 排名前十的文章。通过这些文章，我们能了解开发者们更喜欢读和写哪些话题的文章。我们开始吧！

• 为什么数据科学家喜欢Kubernetes
• Kubernetes 机密信息和 ConfigMap 简介
• 怎样在 Kubernetes 上运行 PostgreSQL（译文）
• 为什么说 Kubernetes 是一辆翻斗车（译文）
• 安全扫描你的 DevOps 流程
• 在 Kubernetes 上部署 InfluxDB 和 Grafana 以收集 Twitter 统计信息
• 使用 Kubernetes 操作器扩展 PostgreSQL
• 使用 Kubernetes 控制器减少系统管理员的工作量
• 将 Kubernetes 带到裸金属边缘计算
• 为什么你不必担心 Kubernetes

首先，我要指明这些文章中有 5 篇是关于 Kubernetes 工作负载的扩展以及它们可以运行在什么场景。这些工作负载涵盖数据科学、PostgreSQL、InfluxDB、Grafana（不仅仅监控集群本身）和边缘计算。从历史角度看，Kubernetes 和容器都是在虚拟机上运行的，尤其是运行在由云提供的基础设施上时。抛开对于 Kubernetes 的兴趣因素，这也表明了终端用户们极度希望在裸机上安装 Kubernetes（参照 用 OpenShift 在裸机环境运行 Kubernetes）。

其次，也有很多开发者希望了解操作相关的知识以及 Kubernetes 的最佳实践。从 Kubernetes 操作器 到 Kubernetes 控制器，从 机密信息 到 ConfigMaps，开发者和运维人员都希望能找到简化部署和管理工作的最佳实践。我们经常纠结在怎么去修改配置文件或别人会怎么配置，而不去回头想想这些配置是怎么让应用部署运转的（不是怎么安装，也不是怎么运行 Kubernetes）。

最后，人们似乎对入门教程真的感兴趣。事实上，构建 Kubernetes 所需了解的信息太多了，以至于让人们望而却步，也使他们走了错误的路。流行度高的文章中有几篇讲述了为什么你需要了解用 Kubernetes 运行应用程序，而不仅仅是安装它。就像最佳实践类的文章一样，人们也通常不会回头分析在入门时他们应该在什么地方花费时间。我一直秉持的理念是，把有限的时间和金钱投入到如何使用某项技术上，而不是如何构建它。

2020 年对 Kubernetes 的 5 个预测

回顾了 2019 年的相关主题，这些主题告诉我们 2020 年将如何发展？结合这些文章中的观点，加上我自己的看法，我来分享下我对于 2020 年以及未来发展趋势的想法：

1. 工作负载扩展。我会关注高性能计算、AI/ML 以及使用操作器的有状态工作负载。
2. 更多的生产中的最佳实践，尤其是跟一些成熟的标准相关的，像 PCI、HIPAA、NIST 等等。
3. 提升免 root 和更安全的运行时类（如 gVisor、Kata Containers 等等）的安全性。
4. 在部署和开发者们共享应用时，把 Kubernetes 清单的更好的规范标准作为部署的核心要素。如 podman 生成 kube、podman 运行 kube，还有多合一 Kubernetes 环境，如 CodeReady Containers (CRC)
5. 一个前所未有的网络、存储和专业硬件（如 GPU 等等）供应商的生态系统，为 Kubernetes 提供 BoB（LCTT 译注：best of breed，单项最佳品牌）解决方案（在自由软件中，我们相信开放的生态系统好过垂直整合的解决方案）。

期待 Kubernetes 在新的一年里再创辉煌！

via: https://opensource.com/article/20/1/kubernetes-2020

作者：Scott McCarty 选题：lujun9972 译者：lxbwolf 校对：wxy

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

使用 useradd 命令来添加用户（并且根据需要修改账号）。

任何计算机系统中，添加用户都是最重要的事之一；本文着重介绍如何在 Linux 系统中添加用户。

正式开始之前，我先提三个概念。首先，跟大多数操作系统一样，Linux 用户也需要一个账号才能登录。本文只介绍本地账号，不涉及网络账号，如 LDAP。其次，每个账号都有一个名字（username）和一个对应的数字（用户 ID）。最后，每个用户通常都在一个组内，每个组都有一个名字和一个组 ID。

你可能已经想到了，Linux 提供了添加用户的命令行工具，就是 useradd 命令。有些版本也叫 adduser。为了方便使用，很多发行版上这个命令是一个指向 useradd 命令的符号链接。

$ file `which adduser`
/usr/sbin/adduser: symbolic link to useradd

来看一下 useradd。

注意：本文描述的默认环境是 Red Hat Enterprise Linux 8.0。你可能会发现本文描述的这些文件和某些默认值与某些 Linux 发行版或其他 Unix 操作系统（FreeBSD 或 Solaris）偶尔会有差异。

默认处理

useradd 的基本用法相当简单：提供一个用户名就可以添加一个用户。

$ sudo useradd sonny

在本例中，useradd 命令创建了一个名为 sonny 的账号。此命令同时创建了一个同名的组，sonny 被放进了这个组，这个组也是 sonny 账号的主组。命令执行时，根据配置文件 /etc/default/useradd 和 /etc/login.defs 中的不同设置，也会有其他的参数，如语言和 shell。对于一个私人系统或微小的单服务商业环境，这些参数已经足够了。

上面两个文件控制 useradd 的处理，用户的信息保存在 /etc 目录下的一些其他文件中，关于这些信息的讲解会贯穿全文。

自定义处理

当管理员需要更好地控制账号时，可以使用命令行来自定义，如指定一个用户的 ID。

用户和组 ID

默认情况下，useradd 试图使用相同的用户 ID（UID）和主组 ID（GID），但也不完全是。虽然 UID 与 GID 相同不是必须的，但如果相同，会更方便管理员管理。

下面的场景就是一个 GID 与 UID 不同的例子。现在我添加另一账号，名为 Timmy。通过使用 getent 命令来比较 sonny 和 timmy 两个账号，显示两个用户和对应的主组。

$ getent passwd sonny timmy
sonny:x:1001:1002:Sonny:/home/sonny:/bin/bash
timmy:x:1002:1003::/home/timmy:/bin/bash

$ getent group sonny timmy
sonny:x:1002:
timmy:x:1003:

不幸的是，两者的 UID 和 GID 都不相同。因为默认的处理是，创建用户时，把下一个可用的 UID 赋给用户，然后把同一个数字作为主组 ID 赋给它。然而，当要使用的组 ID 已经被使用时，就再把下一个可用的 GID 赋给它。为了弄清细节，我猜想 1001 这个 GID 已经被使用了，用一个命令确认了一下。

$ getent group 1001
book:x:1001:alan

book 的 ID 是 1001，因此新创建的用户的 GID 都有偏移量 1。这就是为什么系统管理员在用户创建过程中需要多设置一些值的一个实例。为了解决这个问题，我必须先确定下一个可用的 UID 和 GID 是否相同。确定下一个可用值时，可以使用 getent group 和 getent passwd 命令，通过 -u 参数传递要确认的值。

$ sudo useradd -u 1004 bobby

$ getent passwd bobby; getent group bobby
bobby:x:1004:1004::/home/bobby:/bin/bash
bobby:x:1004:

另一个需要指定 ID 的场景是，通过 NFS 访问远程系统上的文件时。对于一个给定的用户，当 NFS 所有客户端和服务系统的 ID 都一样时，管理员更容易控制。在我的文章 使用 autofs 挂载 NFS 中有详细介绍。

更多自定义

一些其他的指定用户信息的参数也用得比较频繁。这里是一些你会经常用到的参数的概括例子。

注释

注释选项是通过 -c 参数指定的一个解释文本字段，可以提供一段简短的描述或其他信息。

$ sudo useradd -c "Bailey is cool" bailey
$ getent passwd bailey
bailey:x:1011:1011:Bailey is cool:/home/bailey:/bin/bash

组

一个用户可以被指定一个主组和多个次组。-g 参数指定主组名称或 GID。如果不指定，useradd 会以用户名创建一个主组（前面演示过）。-G（大写）参数用一个逗号分隔的组列表来指定此用户所属的组，这些组就是次组。

$ sudo useradd -G tgroup,fgroup,libvirt milly
$ id milly
uid=1012(milly) gid=1012(milly) groups=1012(milly),981(libvirt),4000(fgroup),3000(tgroup)

家目录

useradd 的默认处理是，在 /home 目录下创建用户的家目录。然而，下面的参数可以改写家目录的基础目录。-b 设置另一个可以创建家目录的基础目录。例如指定 /home2 而不是 /home。

$ sudo useradd -b /home2 vicky
$ getent passwd vicky
vicky:x:1013:1013::/home2/vicky:/bin/bash

-d 参数可以指定一个与用户名不同的家目录。

$ sudo useradd -d /home/ben jerry
$ getent passwd jerry
jerry:x:1014:1014::/home/ben:/bin/bash

目录模板

指定 -k 参数会在创建新用户时，复制 /etc/skel 目录下的所有文件到用户的家目录中。这些文件通常是 shell 配置文件，当然也可以是系统管理员想在新建用户时使用的任何文件。

Shell

-s 参数可以指定 shell。如果不指定，则使用默认的 shell。例如，下面的例子中 ，配置文件中定义的 shell 是 bash，但 wally 这个用户指定的是 zsh。

SHELL=/bin/bash

$ sudo useradd -s /usr/bin/zsh wally
$ getent passwd wally
wally:x:1004:1004::/home/wally:/usr/bin/zsh

安全

安全是用户管理的重中之重，因此 useradd 命令也提供了很多关于安全的选项。可以使用 -e 参数，以 YYYY-MM-DD 的格式指定一个用户的过期时间。

$ sudo useradd -e 20191231 sammy
$ sudo getent shadow sammy
sammy:!!:18171:0:99999:7::20191231:

当密码过期时，账号也会自动失效。-f 参数指定密码过期后经过几天账号失效。如果设为 0，则立即失效。

$ sudo useradd -f 30 willy
$ sudo getent shadow willy
willy:!!:18171:0:99999:7:30::

实例

生产环境中，创建一个用户账号时会用到多个参数。例如，我要创建一个 Perry 账号，可能会用下面的命令：

$ sudo useradd -u 1020 -c "Perry Example" \
-G tgroup -b /home2 \
-s /usr/bin/zsh \
-e 20201201 -f 5 perry

查看前面的内容来理解每个选项。用下面的命令确认结果：

$ getent passwd perry; getent group perry; getent shadow perry; id perry
perry:x:1020:1020:Perry Example:/home2/perry:/usr/bin/zsh
perry:x:1020:
perry:!!:18171:0:99999:7:5:20201201:
uid=1020(perry) gid=1020(perry) groups=1020(perry),3000(tgroup)

一点小建议

useradd 命令是所有 Unix（不仅仅是 Linux）系统管理员都必知必会的命令。由于用户创建不能出错，需要第一次就正确，所以理解它的每一个选项很重要。这意味着你需要有一套深思熟虑的命名约定，包括为整个企业环境而不仅仅是一个单系统预留一个专用的 UID/GID 范围，尤其是你为一个成长中的组织工作时。

via: https://opensource.com/article/19/10/linux-useradd-command

作者：Alan Formy-Duval 选题：lujun9972 译者：lxbwolf 校对：wxy

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

Linux 中国曾在 2018 年末参与了开源社发布的《2018 中国开源年度报告》的《数据篇 - Grank 篇》的撰写，并为此提出和开源了 Grank 模型。

时光飞逝，如今已是 2020 年，是时候对主要发源于或活跃于中国的开源项目们进行一次年终总结了，因此我们再一次协同开源社完成了这次的 Grank 分析，并将本报告的简化版本作为《2019 年中国开源年度报告》的一部分出现。

在 2019 年报告中，我们使用和 2018 年报告相同的模型进行分析。但与 2018 年报告不同的是，在 2019 年度报告中，我们引入了大量的企业项目和个人项目，整体分析项目数达到了 1200 余个，并对参与分析的项目进行了分离，按照其所属企业、个人等不同的角度进行分类，让读者能够更加明确不同项目、企业之间的关系。

在我们看具体数据之前，先看一下我们从这些数据中得到感受。

洞察

今年在进行 Grank 数据分析的过程中，我们发现了不少有趣的变化，一年时间，如此多的变化，也值得我们思考和讨论。

洞察一：文档类活跃度可达开发类项目的 10 倍

GitHub 项目上一直都有一些文档类的项目，比如各种 Awesome 、各种电子书。我们会发现， 这些项目经常会引起开发者讨论：XXX 到底能不能算做开源项目？。 GitHub 官方的态度是明确的，文档类项目 azure-docs 出现在了 GitHub 2019 年度开发者报告中。

近两年来，我们发现越来越多的企业，开始将自己的文档放置在 GitHub 上，与整个社区共同协作，构建更好的文档。在此次分析中，我们发现腾讯云文档、阿里云文档、PingCAP 等企业文档早已开始在 GitHub 上协作

当我们真正将文档类开源项目进行数据分析后，我们会发现，文档类项目得益于其低参与成本和学习成本，在项目的活跃度层面可以获得极高的评分，同样的原因，文档类项目也获得了极高的社区化程度。文档类项目已经逐渐成为开源项目中的一个非常重要的组成部分。这样的现象值得我们思考，在开源世界，是代码重要，还是社区重要？

今年的文档类活跃项目最为亮眼的项目，莫过于来自于 腾讯云的 tencentyun/qcloud-documents，此项目的活跃度远超其他项目，总活跃度达到 685.33 ，是同类项目第二名的 5 倍，是开发类项目第一名的 10 倍。

近两年，我们看到大量的企业开始将自己的企业项目文档放在 GitHub 与社区开发者共同协作，获取来自社区开发者的贡献。大量的企业文档类项目的出现，表现出了企业对于开源价值观的认同和投入。

洞察二：企业开源治理水平差异较大

在今年的分析过程中，我们将所有参与分析的账号进行企业级别的分类。通过分类后的数据，我们可以明显看出不同企业在开源治理上的水平和成果。

今年参与分析的的项目中，阿里巴巴的 GitHub 账号有 31 个（源自其开源项目官网），而国内其他一线互联网企业百度有 12 个账号、华为有 7 个账号、腾讯有 4 个账号、美团有 3 个账号。

这些账号背后，我们看出的是各企业对于开源的态度和治理能力。显然，拥有 31 个账号的阿里巴巴在治理能力上可能会受到质疑，但 31 个账号，换来的是阿里巴巴开源的生态和声势最为浩大。而账号更少，治理能力更强的腾讯、百度、华为、美团是否就做的更好呢？也不是。这些企业的账号维护的更好，但是，其开源项目的声量、体量却难以与阿里巴巴旗下的众多项目所抗争。

对于阿里巴巴来说，面临的问题是如何教育开发者，以正式、正规、合规的方式来运营、运作开源项目，而对于其他企业，面临的问题可能是如何激励开发者去做开源项目。

洞察三：程序员亚文化兴起

亚文化一直是主流文化的一个阴影，亚文化往往不为人所知，不为广泛群众所接受。但数据不会骗人。在 2019 年的年度报告中，我们评估了一个著名的项目：komeiji-satori/Dress。这是一个在 GitHub 上拥有 16K 星标，3.2K 复刻和 198 位贡献者的项目。

这个项目的数据，让我真正意识到，亚文化或许依然替代不了主流文化，但不代表亚文化就没有自己的存在价值和空间。 Dress 项目的诞生和发展，是亚文化向主流文化发声的存在。这些我们过去忽视的亚文化，正在以自己的方式，表达观点。

洞察四： JavaScript 生态不断扩大

“能被 JavaScript 所实现的，终将被 JavaScript 所实现”，过去这只是一个梗，但是在如今这个梗在开源项目领域中，不断的变成了现实。在今年的榜单中，我们看到其中出现了大量的 JavaScript 开源项目

JavaScript 得益于其脚本语言的特性和其简单易学的语法，在近几年获得了大量的关注度和开发者。而其无需编译，在浏览器环境可以直接运行的特性，也让 JavaScript 项目在活跃度的提升上占据了优势。相比于编译一次需要花费大量时间的 C++ 、Rust 项目，显然 JavaScript 优势十足。

洞察五：服务端相关开发依然非常重要

虽然 JavaScript 占据的席位越来越多，但是我们所熟悉的传统的服务端开发、服务端中间件等领域类依然是占据了更多的席位。在今年的活跃度榜单前 100 名中，50 个项目是服务端开发，占据了所有榜单的一半份额。不仅如此，数据库中间件项目 —— TiDB 占据了非文档类项目的活跃度榜单第一名、总活跃度榜单第三名。

对于开发者来说，虽然前端开源项目的声量赫然，但服务端开发项目依然是目前开源项目的主流。对于开发者来说，如果不愿意贡献 JavaScript 相关项目，服务端中间件项目会给你更多的选择。

洞察六： 各家布局物联网

今年由于拆分出了多个子榜单，所以也能够让我们更加清楚的看到不同的企业布局。今年的物联网榜单中，我们看到了华为 2015 年开源的 LiteOS 、阿里巴巴 2017 年开源的 AliOS-Things ，一直到 2019 年的的 TencentOS-Tiny（此项目因为开源时间短，活跃度也不高，总体健康度排名在 200 名左右，故没有出现在后续的榜单中），各家企业都在积极地布局物联网领域。在 2020 年，我们预期物联网领域还能诞生出重要项目。

数据

分析方案

由于软件开发项目的迭代周期、研发难度有所不同，各种不同类型的项目放在一个榜单内评比略显不公，因此，2019 年的 Grank 报告我们将参与分析的开源项目切分为以下四个类目，开源项目在同一类目下进行对比，具体分为以下四个类目：

1. 前端类：包括 iOS、Android、Web 大前端，主要为用户可感知的内容，常见为各种类库
2. 服务端类：包括 Java、Rust、PHP、Node.js、Python，主要为常见业务后台类库和中间件
3. 工程类：不限制语言，主要为可直接交付给 C 端客户使用的项目，不作为开发工具参与到开发流程中。
4. 文档类：主要是各类型的文档项目。
5. 物联网类：面向物联网场景下的服务端应用、操作系统等应用。
6. 其他类：无法被涵盖在上述分类范围的项目

前端类分析结果

榜单情况

项目点评

ant-design/ant-design

这是一个“服务于企业级产品的设计体系”，是由蚂蚁金服体验技术部采用 React 封装的一套组件库。同时，也是去年的 Grank 评分的第一名。 Ant-Desgin 项目在整体的大方向上于去年并没有太大的区别，甚至从数据的角度上来，2019 年 Ant-Design 有更多的数据更新，保持其一贯优秀的活跃度与社区化程度。

tencent/omi

Omi是一个基于 Web Components 并支持 IE、小程序端的前端跨平台框架。

从数据上来看， Omi 项目的活跃度从 2018 年 9 月开始，有大幅度提升，并在 2019 年年初达到了数据的顶峰。在社区化程度方面，从 2019 年年中开始，其社区活跃度出现了下降的趋势，猜测可能是其在内部拥有了更大的话语钱，致使更多的企业内部开发者开始参与到 Omi 项目的开发。

elemefe/element

Element 是由饿了么前端团队开源的 Vue UI 框架。从项目活跃上看， Element 近年来的更新乏力，略显颓势。整个项目开始逐渐走向减少维护的阶段。

服务端类分析结果

榜单情况

项目点评

pingcap/tidb

TiDB 项目是 PingCAP 公司的明星项目，是一款定位于在线事务处理/在线分析处理融合型开源数据库产品。

从数据上来看，TiDB 项目近年来的活跃度不断攀升，与之成为鲜明对比的，是其项目的社区活跃度的不断下降。不过，PingCAP 是业界非常典型的开源企业，其协作模式是所有开发人员通过 GitHub 进行协作，对于合适的开发人员，PingCAP 会选择提供其职位，允许其远程办公，以这样的方式来吸收社区的优秀开源力量，其社区化程度不断下降也实属正常。毕竟，优秀的开发者都被 PingCAP 转化为正规军，也不失为一个好的方法。

apolloauto/apollo

apollo 是百度开源出来的自动驾驶解决方案，从 2017 年开源至今，已经迭代至第 5 个版本。

apache/incubator-shardingsphere

shardingsphere 是由京东数科捐赠给 Apache 的分布式数据库中间件解决方案，其中包含了 Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar 三款独立的产品。

工程类分析结果

榜单情况

项目点评

diygod/rsshub

RSSHub 是一个帮助用户将各种各样的内容转化成 RSS 的工具，今年也是他的第一次上榜，RSSHub 以 23 的活跃度积分位列榜单 12 名。

作为一个个人项目，RSSHub 可以说做的是非常棒了，而且，RSSHub 的社区化做的非常好，一直处在高位， 拥有 300 位贡献者。

ant-design/ant-design-pro-site

文档类分析结果

榜单情况

项目点评

tencentyun/qcloud-documents

此项目为腾讯云文档，一个令人惊讶的项目，拥有 543 个贡献者和 119441 个提交 ，平均更新频次为 5 分种/次，有非常惊人的高频维护，估计是腾讯云将其整个文档放置在 GitHub 上进行开放协作，同时，所有的内部合作，都需要通过 GitHub 来完成。

此项目虽然活跃度高，由于项目的贡献指南并未说明，绝大多数开发者没有明确的规范参与到项目的更新。

lctt/TranslateProject

此项目为归属 Linux 中国旗下的翻译组主仓库，该项目拥有 464 名贡献者和 47776 个提交 以及 1.5k 星标 ，平均更新频次为 2 小时，更新频次较高。

此项目拥有完善的贡献说明，对于新手开发者来说，更加的友好，对于无法参与到开发阶段的开发者，可以考虑从翻译开始。

xitu/gold-miner

此项目为掘金翻译计划的官方仓库 ，来自社区的开发者们在一个仓库 上协作，贡献自己的翻译文章，该项目拥有 417 名贡献者和 9754 个提交，以及超过 24.9K 的星标。

物联网类分析结果

榜单情况

项目点评

rt-thread/rt-thread

RT-Thread 是一个 2006 年创建的项目，十余年来专注于物联网实时操作系统。其项目自 2018 年起，开始出现明显的活跃度增加。回望 2017 、2018，物联网生态企业和产品的蓬勃发展，让开源项目也随之获得了大量的关注度，项目维护团队、社区开源爱好者的参与，让 RT-Thread 能够跑的更快。

liteos/LiteOS

LiteOS 是华为开源的物联网操作系统，从 2015 年发布，到 2019年结束，LiteOS 的各项数据有着明显的变化。从 2017 年的不怎么维护，到 2018 年的迅猛发展，再到 2019 年的归为平淡，从某种角度来说，LiteOS 颇具 KPI 项目的潜质。而社区化程度的低位，也会让用户去思考，这个系统是否值得我去使用？

alibaba/AliOS-Things

AliOS-Things 源自阿里巴巴，自 2017 年开源以来，项目总体来说，维护的节奏比较平稳，从初期的大幅度维护，到后期的小幅度维护。从活跃度的角度来看，是一个不错的项目，不过，社区化的变化，可能是由于 AliOS-Things 在内部的权重变重，更多的企业开发者参与到项目中来，去推进项目的进度。

其他类分析结果

榜单情况

项目点评

996icu/996.ICU

996.ICU 项目作为 2019 年现象级的一个项目，一度得到了社会和社区的广泛关注，但是由于种种原因，这个项目的消亡也很快。不胜叹息。

活跃度总榜前 100 名

致谢与反馈报告问题

由于时间有限，本次报告仅收录部分项目，如果其中存在数据错误或希望补充收录，请通过 邮件 联系我们。

如果报告撰写过程中出现文字错误等问题，你可以直接访问 GRank 仓库，提交 PR 修正。

本次数据分析所引用的企业账号的部分数据源自《InfoQ:中国互联网公司开源项目调研报告》。

附录

附录一 研究方法综述

Grank 是本报告制定的一个指数，用于综合评估一个开源项目、开源组织的健康程度。

Grank 模型介绍

我们认为，一个健康的开源项目应该体现为以下两个方面：

• 项目的活跃度趋势
• 项目的社区化（去中心化）程度

而这两个方面分别有多个因素组成：

活跃度和活跃度趋势

项目的活跃度，我们定义为项目的提交数、 拉取请求数和贡献者数（其它数据，如代码行数、文件数、提案数、复刻数、星标数，要么是权重相对低得多，要么是代表意义不够确定，此处忽略不计入模型）。

但是，对于不同的项目，其横向比较其活跃度，或有不同的活跃度形态，或不具备可比性。很难说一个项目比另外一个项目的提交数高，而拉取请求（PR）数低代表的确切含义。因此我们不认为对不同项目的这些数据进行绝对值的比较有太多的科学意义。

所以，我们认为一个项目本身的活跃度变化的趋势和幅度，会更有项目间比较的意义。

如果以三维空间来描述一个项目的活跃度，以提交数、拉取请求数、贡献者数为三维，可以确定在某个时间点某个项目的坐标，那么计算一段时间内，该坐标点的移动轨迹和速率，可以真实的反映该项目的活跃度趋势。

考虑到按周工作的作息时间的普遍影响，我们以一个工作周作为一个时间采样点，然后计算连续的几周内该坐标的移动速率。这反映了该项目的发展速度。

社区化程度

开源诞生于社区，繁荣于社区，根植于社区，虽然现在大型组织、商业公司也纷纷投身于开源生态，但是我们认为，开源项目的生命力仍然在于社区。我们并不否认机构、商业公司对开源的巨大贡献和影响力，但是如果一个开源项目变成了一家或几家大企业的私人游戏，其必然失去开源项目的生命力，它或许会在商业上取得成功，但是那个成功不是开源项目的成功模式。

因此，我们认为需要有一个评估开源项目的社区化（去中心化）程度的指标。项目（尤其是软件项目）的一个重要属性是开发人员的社区化身份，因此，我们以实际向项目贡献了代码的人员的社区化离散程度来评估项目的社区化程度。

每个参与项目开发的人员均有其身份属性，这个身份可能是企业雇佣身份，也可能是社区志愿者身份。我们通过对项目的提交中的提交者数据进行收集，然后根据开发人员的身份信息、邮件后缀等依优先级来判断其所属身份。然后对这些信息进行聚类，以一个离散评估模型来评估该数据集的离散程度。

虽然项目越中心化，其发展风险越高，但是，并不是社区化程度越高的项目就越健康，过于离散的项目也容易出现项目分裂、迭代缓慢等问题。这显然是存在一个适当的区域。

通过上述两个指数，我们可以对项目进行象限划分，以“项目活跃度”和“社区化程度”为两个象限轴。

附录二 数据采集方式、工具与时间

• 数据采集方式：基于 Github Developers API V4 进行数据抓取
• 数据采集所用工具：https://github.com/LCTT/Grank
• 数据抓取时间范围： 2017 年 1 月 1 日 ～ 2019 年 12 月 31 日

附录三 参与分析账号

企业及组织账号

百度

阿里巴巴

腾讯

华为

美团

360

小米

PingCAP

有赞

京东

字节跳动

RT-Thread

网易

滴滴出行

唯品会

武汉深之度

hyperf

微众银行

SwiftOldDriver

SwiftGGTeam

豆瓣

Linux 中国

studygolang

涛思数据

携程

去哪儿

当当

个人账号

在 Github 上关注者数大于 10000 的账号。

• 996icu
• diygod
• ruanyf
• yyx990803
• michaelliao
• daimajia
• JacksonTian
• Trinea
• phodal
• stormzhang
• cloudwu
• lifesinger
• astaxie
• onevcat
• justjavac
• breakwa11
• RubyLouvre
• hongyangAndroid
• laruence
• ibireme
• bailicangdu
• bestony