有无数的文章、讨论、以及很多社区喋喋不休地比较 Docker、Kubernetes 和 Mesos。如果你只是听信了只言片语，你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。你可能还相信从他们中选出一个如宗教信仰般神圣——真正的信徒会忠于他们的信仰，而且会烧死那些敢于考虑替代方案的异教徒。

那都是废话。

虽然所有这三种技术都使得使用容器来部署、管理和伸缩应用成为可能，但实际上它们各自解决了不同的问题，并且根植于迥异的上下文环境中。事实上，这三种被广泛采用的工具链，都是有差别的。

让我们重新审视每个项目的原始任务、技术架构，以及它们是如何相互补充和交互的，而不是纠结于比较这些快速迭代的技术之间重叠的特性。

让我们从 Docker 开始……

Docker 公司，始于名为 dotCloud 的平台即服务（PaaS）供应商。dotCloud 团队发现，在许多应用和客户之间管理依赖和二进制文件时需要付出大量的工作。因此他们将 Linux 的 cgroups 和 namespace 的一些功能合并成一个单一且易于使用的软件包，以便于应用程序可以一致地运行在任何基础设施上。这个软件包就是所谓的 Docker 镜像，它提供了如下的功能：

• 将应用程序和依赖库封装在一个软件包（即 Docker 镜像）中，因此应用可以被一致地部署在各个环境上；
• 提供类似 Git 的语义，例如 docker push，docker commit 等命令让应用开发者可以快速接受这门新的技术，并将其融入到现有的工作流中；
• 定义 Docker 镜像为不可变的层，支持不可变的基础设施。新提交的变更被分别保存为只读层，让复用镜像和追踪变更记录变得十分简单。层还通过只传输更新而不是整个镜像来节省磁盘空间和网络流量；
• 通过实例化不可变的镜像和读写层来运行 Docker 容器，读写层可以临时地存储运行时变更，从而轻松部署和扩展应用程序的多个实例。

Docker 变得越来越受欢迎，开发者们开始从在笔记本电脑上运行容器转而在生产环境中运行容器。跨多个机器之间协调这些容器需要额外的工具，这称之为 容器编排 container orchestration 。有趣的是，第一个支持 Docker 镜像的容器编排工具（2014 年 6月）是 Apache Mesos 的 Marathon（后面会有详细介绍) 。那年，Docker 的创始人兼首席技术官 Solomon Hykes 将 Mesos 推荐为“生产集群的黄金标准”。不久之后，除了 Mesos 的 Marathon 之外，还出现了许多的容器编排技术：Nomad、Kubernetes，不出所料还有 Docker Swarm （它如今是 Docker 引擎的一部分）。

随着 Docker 开始商业化其开源的文件格式（LCTT 译注：指 Docker 镜像的 dockerfile 文件格式），该公司还开始引入工具来完善其核心的 Docker 文件格式和运行时引擎，包括：

• 为公开存储 Docker 镜像的而生的 Docker hub；
• 存储私有镜像的 Docker 仓库（Docker registry）；
• Docker cloud，用于构建和运行容器的管理性服务；
• Docker 数据中心作为一种商业产品体现了许多 Docker 技术；

来源: www.docker.com

Docker 将软件及其依赖关系封装在一个软件包中的洞察力改变了软件行业的游戏规则，正如 mp3 的出现重塑了音乐行业一般。Docker 文件格式成为行业标准，领先的容器技术供应商（包括 Docker、Google、Pivotal、Mesosphere 等) 组建了 云计算基金会 Cloud Native Computing Foundation (CNCF) 和 开放容器推进联盟 Open Container Initiative (OCI)。如今，CNCF 和 OCI 旨在确保容器技术之间的互操性和标准化接口，并确保使用任何工具构建的任何 Docker 容器都可以在任何运行时或基础架构上运行。

进入 Kubernetes

Google 很早就认识到了 Docker 的潜力，并试图在 Google Cloud Platform （GCP）上提供容器编排“即服务”。 Google 在容器方面拥有丰富的经验（是他们在 Linux 中引入了 cgroups），但现有的内部容器和 Borg 等分布式计算工具直接与其基础架构相耦合。所以，Google 没有使用原有系统的任何代码，而是从头开始设计 Kubernetes （K8S）来编排 Docker 容器。 Kubernetes 于 2015 年 2 月发布，其目标和考虑如下：

• 为应用程序开发人员提供编排 Docker 容器的强大工具，而无需与底层基础设施交互；
• 提供标准部署接口和原语，以实现云端一致的应用部署体验和 API;
• 基于模块化 API 核心，允许供应商围绕 Kubernetes 的核心技术集成其系统。

2016 年 3 月，Google 将 Kubernetes 捐赠给了 CNCF，并且直到今天仍然是该项目的主要贡献者（其次是Redhat，CoreOS 等）。

来源: wikipedia

Kubernetes 对应用程序开发人员非常有吸引力，因为它减轻了对基础架构和运营团队的依赖程度。供应商也喜欢 Kubernetes，因为它提供了一个容易的方式来拥抱容器化运动，并为客户部署自己的 Kubernetes（这仍然是一个值得重视的挑战）提供商业解决方案。 Kubernetes 也是有吸引力的，因为它是 CNCF 旗下的开源项目，与 Docker Swarm 相反，Docker Swarm 尽管是开源的，但是被 Docker 公司紧紧地掌控着。

Kubernetes 的核心优势是为应用程序开发人员提供了用于编排无状态 Docker 容器的强大工具。 虽然有多个扩大项目范围的提议，以提供更多的功能（例如分析和有状态数据服务），但这些提议仍处于非常早期的阶段，它们能取得多大的成功还有待观察。

Apache Mesos

Apache Mesos 始于 加州大学伯克利分校 UC Berkeley 的下一代容器集群管理器项目，并应用了从云计算级别的分布式基础架构（如 Google 的 Borg 和 Facebook 的 Tupperware）中习得的经验和教训。 虽然 Borg 和 Tupperware 具有单一的架构，并且是与物理基础架构紧密结合的闭源专有技术，但 Mesos 推出了一种模块化架构，一种开源的开发方法，旨在完全独立于基础架构。Mesos 迅速被 Twitter、Apple（Siri 中）、Yelp、Uber、Netflix 和许多领先的技术公司采用，支持从微服务、大数据和实时分析到弹性扩展的一切。

作为集群管理器，Mesos 被设计用来解决一系列不同的挑战：

• 将数据中心资源抽象为单个池来简化资源分配，同时在私有云或公有云中提供一致的应用和运维体验；
• 在相同的基础架构上协调多个工作负载，如分析、无状态微服务、分布式数据服务和传统应用程序，以提高利用率，降低成本和台面空间;
• 为应用程序特定的任务（如部署、自我修复、扩展和升级），自动执行第二天的操作；提供高度可用的容错基础设施；
• 提供持久的可扩展性来运行新的应用程序和技术，而无需修改集群管理器或其上构建的任何现有应用程序；
• 弹性扩展可以将应用程序和底层基础设施从少量扩展到数十到数万个节点。

Mesos 独有的独立管理各种工作负载的能力 —— 包括 Java 这样的传统应用程序、无状态 Docker 微服务、批处理作业、实时分析和有状态的分布式数据服务。Mesos 广泛的工作负载覆盖来自于其两级架构，从而实现了“应用感知”调度。通过将应用程序特定的操作逻辑封装在“Mesos 框架”（类似于操作中的运行手册）中来实现应用程序感知调度。资源管理器 Mesos Master 提供了这些框架基础架构的部分，同时保持隔离。这种方法允许每个工作负载都有自己的专门构建的应用程序调度程序，可以了解其部署、扩展和升级的特定操作要求。应用程序调度程序也是独立开发、管理和更新的，这让 Mesos 拥有高度可扩展的能力，支持新的工作负载或随着时间的推移而增加更多的操作功能。

举一个团队如何管理应用软件升级的例子。无状态应用程序可以从“蓝/绿”部署方案中受益；当新版本的应用运行起来时，原先旧版本的软件依然还正常运转着，然后当旧应用被销毁时流量将会切换到新的应用上。但是升级数据工作负载例如 HDFS 或者 Cassandra 要求节点停机一次，此时需要持久化本地数据卷以防止数据丢失，并且按照特定的顺序执行原位升级，在升级之前和升级完成之后，都要在每一个节点类型上执行特定的检查和命令。任何这些步骤都是应用程序或服务特定的，甚至可能是版本特定的。这让使用常规容器编排调度程序来管理数据服务变得非常困难。

Mesos 以每一个工作负载所需的特定方式管理各种工作负载，使得许多公司将 Mesos 作为一个统一的平台，将微服务和数据服务结合在一起。数据密集型应用程序的通用参考架构是 “SMACK 家族”（LCTT 译注：SMACK 即 Spark、Mesos、Akka、Cassandra、Kafka)。

是时候搞清楚这些了

请注意，我们尚未对 Apache Mesos 的容器编排有任何描述。所以为什么人们会自动地将 Mesos 和容器编排联系起来呢？容器编排是可以在 Mesos 的模块化架构上运行的工作负载的一个例子，它是通过一个专门的编排“框架”来完成的，这个框架就 Marathon，一个构建于 Mesos 之上的工具。 Marathon 最初是为了在 cgroup 容器中编排应用归档（如 JAR、tarball、ZIP 文件）而开发的，是 2014 年最先支持 Docker 容器的编排工具之一。

所以当人们将 Docker 和 Kubernetes 与 Mesos 进行比较时，他们实际上是将 Kubernetes 和 Docker Swarm 与在 Mesos 上运行的 Marathon 进行比较。

为什么搞清楚这一点很重要？ 因为 Mesos 坦率地讲并不在乎它上面运行了什么。 Mesos 可以在共享的基础设施上弹性地为 Java 应用服务器提供集群服务、Docker 容器编排、Jenkins 持续集成任务、Apache Spark 分析、Apache Kafka 流，以及更多其他的服务。Mesos 甚至可以运行 Kubernetes 或者其他的容器编排工具，即使公共的集成目前还不可用。

来源: Apache Mesos 2016 调查问卷

Mesos 的另一个考虑因素（也是为什么它对许多企业架构师来说如此有吸引力）是运行关键任务工作负载的成熟度。 Mesos 已经在大规模生产环境下（成千上万台服务器）运行了超过 7 年的时间，这就是为什么它比市场上许多其他的容器技术更具有生产上的可行性和扩展上的可靠性。

我所说的这些什么意思？

总而言之，所有这三种技术都与 Docker 容器有关，可以让你在容器编排上实现应用程序的可移植性和扩展性。那么你在它们之间如何选择呢？ 归根到底是为工作选择合适的工具（也可能是为不同的工作选择不同的工具）。如果您是一个应用开发人员，正在寻找现代化的方式来构建和打包你的应用程序，或者想加速你的微服务计划，Docker 容器和开发工具就是最好的选择。

如果你们是一个开发人员或者 DevOps 的团队，并希望构建一个专门用于 Docker 容器编排的系统，而且愿意花时间折腾集成解决方案与底层基础设施（或依靠公共云基础架构，如 Google 容器引擎（GCE）或 Azure 容器服务（ACS）），Kubernetes 是一个可以考虑的好技术。

如果你们想要建立一个运行多个关键任务工作负载的可靠平台，包括 Docker 容器、传统应用程序（例如 Java）和分布式数据服务（例如 Spark、Kafka、Cassandra、Elastic），并希望所有这些可依移植到云端提供商或者数据中心，那么 Mesos（或我们自己的 Mesos 发行版，Mesosphere DC/OS）更适合你们的需求。

无论您选择什么，您都将拥抱一套可以更有效地利用服务器资源的工具，简化应用程序的可移植性，并提高开发人员的敏捷性。你的选择真的不会有错。

via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/

作者：Amr Abdelrazik 译者：rieonke 校对：wxy

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

这是游客投稿的本系列两篇中的第一篇；作者：Dominik Nowak，Husarion 的 CEO

过去十年，我们见证了 IT 行业的许多突破。可以说对消费者最有意义的一个方面是智能手机和移动开发的普及。接下来的大事件是什么，现在智能手机是如此常见，我们天天对着它，是不是有点无聊吗？所以，我们猜是：机器人。

众所周知，许多生产线完全由机器人运行。但在消费者和服务方面，还没有看到巨大的突破。我们认为这是一个可达性和降低开发人员进入的门槛的问题。只需要有好的、简单的工具来快速做出原型和开发机器人。为了测试新的想法并赋予工程师们更多能力，以便他们可以解决许多人类仍然面临的问题，那些比在应用中的点按一下更棘手的问题。

构建机器人是一个具有挑战性的任务，Husarion 团队正在努力使其更容易。Husarion 是一家从事于机器人快速开发平台的机器人公司。该公司的产品是 CORE2 机器人控制器和用于管理所有基于 CORE2 的机器人的云平台。CORE2 是第二代 Husarion 机器人控制器，它可在这里找到。

CORE2 结合了实时微控制器板和运行 Ubuntu 的单板计算机。Ubuntu 是最受欢迎的 Linux 发行版，不仅适用于桌面，还适用于物联网和 机器人程序中的嵌入式硬件。

CORE2 控制器有两种配置。第一款是采用 ESP32 Wi-Fi 模块的，专用于需要低功耗和实时、安全遥控的机器人应用。第二款，称为 CORE2-ROS，基本上是将两块板子集成到了一起：

• 使用实时操作系统（RTOS）的实时微控制器并集成电机、编码器和传感器接口的电路板
• 带有 ROS（Robot Operating System）包的运行 Linux 的单板计算机（SBC）和其他软件工具。

“实时”电路板做底层工作。它包含高效的 STM32F4 系列微控制器，非常适用于驱动电机、读码器、与传感器通信，并控制整个机电或机器人系统。在大多数应用中，CPU 负载不超过几个百分点，实时操作由基于 RTOS 的专用编程框架支持。我们还保证与 Arduino 库的兼容性。大多数任务都在微控制器外设中处理，如定时器、通信接口、ADC 等，它具有中断和 DMA 通道的强大支持。简而言之，对于具有其他任务的单板计算机来说，这不是一项任务。

另一方面，很显然，现代先进的机器人程序不能仅仅基于微控制器，原因如下：

• 自动机器人需要大量的处理能力来执行导航、图像和声音识别、移动等等，
• 编写先进的软件需要标准化才能有效 - SBC 在行业中越来越受欢迎，而对于为 SBC 编写的软件也是如此，这与 PC 电脑非常相似
• SBC 每年都变得越来越便宜 – Husarion 认为，结合这两个世界在机器人技术方面是非常有益的。

CORE2-ROS 控制器有两种配置：Raspberry Pi 3 或 ASUS Tinker Board。CORE-ROS 运行于 Ubuntu、Husarion 开发和管理工具以及 ROS 软件包上。

下篇文章将介绍为何 Husarion 决定使用 Ubuntu 。

via: https://insights.ubuntu.com/2017/07/12/robot-development-made-easy-with-husarion-core2-ros-running-ubuntu/

作者：Dominik Nowak 译者：geekpi 校对：wxy

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

网络和系统管理工作工资高、岗位多。

我们为秩序而战，而服务器大叔则需要你成为系统管理员。

这是个很好的机会，因为你已经管理过你有的那些系统，你本可以不需酬劳地管理那些日逐一日地运行的系统。但还是有一些面试官，愿意拿一笔很不错的薪水来找一些人去管理他们的系统。目前，系统和网络管理的失业率几乎为零，但是美国劳工统计局估计到 2024 年该领域将持续 9% 的增长。

你可能会问，自动化运维怎么样？大概你已经听一些系统管理员说过，他们打算如何来自动化他们所有的工作，或者，他们如何在一个 shell 脚本里自动化完成他们前任者的工作。你听过的有多少成功的？自动化了某个任务，就会有更多的东西需要自动化。

如果你参加过系统管理者会议或观看过他们的视频，你会发现这是一个需要新鲜血液的领域。不仅仅是明显的缺少年轻人，而且相当地性别和种族不平等。虽然有点儿跑题，但是多样性已经被证明可以提高系统管理员非常感兴趣的自我恢复力、解决问题的能力，创新力和决策力。

我要成为一名系统管理员吗？

有人要你，但是你要做系统管理工作吗？如果你生活在一个第一世界国家，每年 70,000 美元的收入看上去是一个可以感到幸福的标准收入，或者说至少减少了大部分的与钱相关的压力。系统和网络管理员的中位年度收入是 80,000 美元，很容易达标，尽管明显有些人赚的更少或更多。

你曾经免费做过一些系统管理工作吗？我们大多数人都多多少少地管理一些设备，但是那并不代表你喜欢管理它。如果你曾经在你家的网络中添加了一些服务器，你就是一个备选的系统管理员。你想要为自己的孩子添加一个“我的世界”的游戏服务器么，所以你用树莓派搭建了一个？也许是时候来考虑通过做这样的工作来获取报酬了。

作为一份需要全面知识的工作，系统管理工作有很大的跨度。各种行业和各种规模的公司都需要系统管理员。大多数的位于市区里的公司需要一些现场上班的人员，但是远程办公也有很大的可能性。

每个人都是免费地用开源软件工作，但是，作为系统管理员，你也可以计酬工作。系统管理员经常把对开源项目做贡献、支持开源供应商、使用各种各样的有趣而强大的开源软件为他们日常工作的一部分。

最后，谈一下社区。以我多年的经验来看，找到一个欢迎新人的、鼓励参与的、气氛友好的、彼此帮助的社区是非常难的。系统管理员给人的刻板印象就是性情乖戾，但是我感觉现在这只不过是个过时的笑话。现在大多数的系统管理员积极地回应各种形式的有建设性的反馈，尤其是欢迎新手。我们总是能敏锐的察觉到各种各样的入门级问题，并且热心于解决它们。我们是一个有深度的、兴趣广泛的社区。问一下一个系统管理员在工作之余都干了些什么，你肯定会感到吃惊。

那么，我要从哪儿开始？

如果你被说服了，首先有个好消息。与许多技术类职业相比，从不是直接相关的四年制学历转为系统管理员是可能的。事实上，全世界有四年本科学历的系统管理员相对较少，所以不用太担心这个。对于现在的白领工作，学历确实有用，而且越相关越好。与其他的技术类职业相比，这儿有一个很自然的入门级别的职位：技术支持。

对系统管理工作的候选人来说有个坏消息是真的，在技术类领域（甚至非技术类领域）：雇主在寻找有多年经验的和有高学历的人，即便是在入门级别的岗位上。雇主是刻薄的，雇主不会花钱给你培训。不过稍嫌安慰的是，这些问题在人才市场上是非常普遍的，所以不管你找什么工作都得面对这种问题。

系统管理工作可以作为其他 IT 领域的起点。比如：网络管理、数据库管理、网站可靠性工程师（SRE），再远一些的也有，软件工程师、质量保证（QA）、IT 管理。

系统管理工作的具体情况，包括其刻板的印象和一些明显的方面以及不明显的方面，是未来我们的文章的主题。我们也会涵盖这个领域可能会改变的重要方面，提供一些方法来评估和比较系统管理职位，以及在面试中问到的一些重要问题。

如果你对加入这个领域有兴趣，可以考虑加入专业系统管理者联盟（LOPSA），我在这个组织任董事会成员。会员资格是你负担得起的（可能由您的雇主负责），而学生免费。成为 LOPSA 会员，是找到同行们和与有各种经验、各种行业和工作环境中的人员讨论职业生涯的绝佳方式。

（题图 : Jason Baker, CC BY-SA 4.0）

作者简介：

Paul English - 他是 PreOS 安全公司的首席执行官，也是专业系统管理员联盟的董事会成员，该专业系统管理员联盟是一个非营利性专业协会，从 2015 年至今致力于提升系统管理工作实践。 Paul 在 1998 年获得了伍斯特理工学院的计算机学士学位。自 1996 年以来，Paul 一直是 UNIX 和 Linux 系统管理员和许多场合冠以 IT 之名的那个人。最近他在管理一些系统管理员。

via: https://opensource.com/article/17/7/why-become-sysadmin

作者：Paul English 译者：sugarfillet 校对：wxy

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

窗口管理器 window manager 负责管理打开窗口的大小、布置以及其它相关的方面。

我喜欢极简。如果可能，我会尽量在一个终端下运行所有需要的程序。这避免了一些浮夸的特效占用我的资源或者分散我的注意力。而且，无论怎么调整窗口大小和位置却依旧无法使它们完美地对齐，这也让我感到厌烦。

出于对极简化的追求，我喜欢上了 Xfce 并且把它作为我主要的 Linux 桌面环境好几年了。直到后来我看了 Bryan Lunduke 关于他所使用的名为 Awesome 的窗口管理器的视频。Awesome 为用户整齐地布置好他们的窗口，看起来就是我想要的效果。但在我尝试之后却发现我难以把它配置成我喜欢的样子。于是我继续搜寻，发现了 xmonad，然而我遇到了同样的问题。xmonad 可以良好运作但为了把它配置成我理想中的样子我却不得不先通过 Haskell 语言这关。（LCTT 译注： AwesomeWM 使用 lua 语言作为配置语言，而 xmonad 使用 Haskell 语言）

几年后，我无意间发现了 suckless.org 和他们的窗口管理器 dwm。

简而言之，一个窗口管理器，例如 KDE，Gnome 或者 Xfce，包括了许多部件，其中除了窗口管理器还有其它应用程序。窗口管理器负责管理打开窗口的大小、布置（以及其它窗口相关的方面）。不同的桌面环境使用不同的窗口管理器，KDE 使用 KWin，Gnome 2 使用 Metacity， Gnome 3 使用 Mutter， 以及 Xfce 使用 Xfwm。当然，你可以方便地替换这些桌面环境的默认窗口管理器。我已经把我的窗口管理器替换成 dwm，下面我说说我喜欢 dwm 的理因。

动态窗口管理

与 Awesome 及 xmonad 一样，dwm 的杀手锏是它能利用屏幕的所有空间为你自动排布好窗口。当然，在现在的大多数桌面环境中，你也可以设置相应的快捷键把你的窗口放置在屏幕的上下左右或者是全屏，但是有了 dwm 我们就不需要考虑这么多了。

dwm 把屏幕分为主区域和栈区域。它包含三种布局：平铺，单片镜（monocle）和浮动。平铺模式是我最常使用的，它把一个主要的窗口放置在主区域来获取最大关注力，而将其余窗口平铺在栈区域中。在单片镜模式中，所有窗口都会被最大化，你可以在它们之间相互切换。浮动模式允许你自由调整窗口大小（就像在大多数窗口管理器下那样），这在你使用像 Gimp 这类需要自定义窗口大小的应用时更为方便。

一般情况下，在你的桌面环境下你可以使用不同的工作空间（workspace）来分类你的窗口，把相近的应用程序放置在计划好的工作空间中。在工作时，我会使用一个工作空间来进行工作，同时使用另一个工作空间来浏览网页。dwm 有一个相似的功能叫标签。你可以使用标签给窗口分组，当你选中一个标签时，就能显示具有相应标签的窗口。

高效

dwm 能让你的计算机尽量地节省电量。Xfce 和其它轻量桌面环境在较旧或者较低性能的机器上很受欢迎，但是相比于 Xfce，dwm 在登录后只使用了它们 1/3 的资源（在我的例子中）。当我在使用一台 1 GB 内存的 Eee PC （LCTT 译注：华硕生产的一款上网本，已停产）时，占用 660 MB 和 230MB 的差别就很大了。这让我有足够的内存空间运行我的编辑器和浏览器。

极简

通常，我让我的应用程序彼此相邻：作为主窗口的终端（通常运行着 Vim）、用来查阅邮件的浏览器，和另外一个用来查阅资料或者打开 Trello 的浏览器窗口。对于临时的网页浏览，我会在另一个工作空间或者说是另一个 标签 中开启一个 Chromium 窗口。

来自作者的屏幕截图。

在标准的桌面环境下，通常会有一或两个面板占据着屏幕上下或者两侧的空间。我尝试过使用自动隐藏功能，但当光标太靠近边缘导致面板弹出造成的不便实在让我很厌烦。你也可以把它们设置得更小，但我还是更喜欢 dwm 的极简状态栏。

速度

评判速度时，我比较看重 dwm 在登录后的加载速度和启动程序的速度。如果使用更快、更新的计算机，你可能不会在意这些细节，但是对我来说，不同的桌面环境和窗口管理器会有明显的差距。我实在不想连这种简单的操作也要等待，它们应该一下子就完成。另外，使用键盘快捷键来启动程序比起用鼠标或者触控板要快一些，而且我不想让双手离开键盘。

小结

即便如此，我也不会向新手用户推荐 dwm。研究如何配置它需要耗费一些时间（除非你对你的发行版提供的默认配置感到满意）。我发现要让一些你想要的补丁正常工作可能会有点棘手，而且相应的社区也比较小（其 IRC 频道明确表示不提供补丁的手把手帮助）。所以，为了得到你想要的效果，你得有些付出才行。不过，这也是值得的。

而且你看，它就像 Awesome 一样 awesome。

（题图：cinderwick.ca）

作者简介：

Jimmy Sjölund - 他是 Telia Company 的高级 IT 服务经理，关注团队开发、探索敏捷工作流和精益工作流的创新导师，以及可视化方向爱好者。他同时也是一名开源布道者，先前从事于 Ubuntu Studio 和 Plume Creator。

via: https://opensource.com/article/17/7/top-4-reasons-i-use-dwm-linux-window-manager

作者：Jimmy Sjölund 译者：haoqixu 校对：wxy

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

或许你正在考虑（或正在进行）将机器人使用开源软件推向市场。这个机器人是基于 linux 构建的。也许你正在使用机器人操作系统（ROS）或任务导向操作套件（MOOS），或者是另外一个可以帮助你简化开发过程的开源中间件。当开发接近实用化，对回报的期望开始给你带来一些压力。你可能会被问到“我们的产品什么时候可以开始销售？”，这时你将面临重要的抉择。

你可以做下面两件事之一：

1. 对现有的产品开始出货
2. 回过头去，把产品化当做一个全新的问题来解决，并处理新的问题

不需要看很远，就可以找到采用方式（1）的例子。事实上，在物联网设备市场上，到处都是这样的设备。由于急于将设备推向市场，这些可以在设备中找到硬编码证书、开发密钥、各种安全漏洞和没有更新方式的产品并不少见。

想想 Mirai 僵尸网络，通过该僵尸网络发起的流量超过 1Tbps 的分布式拒绝服务攻击（DDos），导致一些互联网上最大的网站停止服务。这个僵尸网络主要由物联网设备组成。这种攻破设备的防御机制进而控制设备所开发的僵尸程序，是采用了超级酷的黑魔法在一个没有窗户的实验室（或地下基地）开发的吗？不是，默认（通常是硬编码）证书而已。这些设备的制造商是否快速反应并发布所有这些设备的更新，以确保设备的安全？不，很多制造商根本没有更新方法。他们召回设备而不是发布更新。

不要急于将产品推向市场，而是退后一步。只要多思考几点，就可以使你自己和你所在公司避免痛苦。

例如，你的软件如何更新？你必须能回答这个问题。你的软件不是完美的。只要几个星期你就会发现，当你在加利福尼亚使用自主的高机动性多用途轮式车辆（HMMWV）时，它把小灌木识别为一棵橡树。或者你不小心在软件中包含了你的 SSH 密钥。

基础操作系统如何更新？也许这仍然是你的产品的一部分，也是你回答上一个问题的答案。但也许你使用的操作系统来自于另外一个供应商。你如何从供应商那里得到更新并提供给客户？这就是安全漏洞真正让你头痛的地方：从来不更新的内核，或者严重过时的 openssl。

当你解决了更新问题，在更新过程出现问题时，机器人怎么恢复？我的示例是对前面问题的一个常见解决方案：自动安全更新。对于服务器和台式机以及显然是计算机的东西来说，这是一个很好的做法，因为大多数人意识到有一个可接受的方法来关闭它，而不是按住电源按钮 5 秒钟。机器人系统（以及大多数物联网系统）有一个问题，有时它们根本不被认为是计算机。如果您的机器人表现奇怪，有可能会被强制关闭。如果你的机器人行为奇怪是因为它正在快速安装一个内核更新，那么，现在你就有一个安装了半个内核的机器人镇纸了。你需要能够处理这种情况。

最后，你的工厂流程是什么？你如何安装 Linux，ROS（或者你使用的中间件），以及你要安装在设备上的你自己的东西？小的工厂可能会手工操作，但这种方法不成规模，也容易出错。其他厂商可能会制作一个定制化的初始发行版 ISO，但这是个不小的任务，在更新软件时也不容易维护。还有一些厂商会使用 Chef 或者有陡峭学习曲线的自动化工具，不久你就会意识到，你把大量的工程精力投入到了本来应该很简单的工作中。

所有这些问题都很重要。针对这些问题，如果你发现自己没有任何明确的答案，你应该加入我们的网络研讨会，在研讨会上我们讨论如何使用开放源代码构建一个商业化机器人。我们会帮助你思考这些问题，并可以回答你更多问题。

作者简介：

Kyle 是 Snapcraft 团队的一员，也是 Canonical 公司的常驻机器人专家，他专注于 snaps 和 snap 开发实践，以及 snaps 和 Ubuntu Core 的机器人技术实现。

via: https://insights.ubuntu.com/2017/07/18/things-to-consider-when-building-a-robot-with-open-source/

作者：Kyle Fazzari 译者：SunWave 校对：wxy

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

不久之前我看到了 RedMonk 的 Stephen O'Grady 发了一个关于开源协议的有趣的推特，那个推特里面有这张图。

这张图片显示了从 2010 到 2017 年间各种开源协议之间的使用率的变化。在这张图片里，显然 GPL 2.0 —— 最纯净的 copyleft 协议之一 —— 的使用率降低了一多半。该图表表明，开源项目中 MIT 协议和 Apache 协议开始受欢迎。GPL 3.0 的使用率也有所上涨。

这些意味着什么？

为什么 GPL 2.0 的使用率跌的这么多但是 GPL 3.0 仅仅是涨了一丁点？为什么 MIT 协议和 Apache 协议的使用率涨了那么多?

当然，有很多原因可以解释这件事情，但是我想这是因为商业开源项目的增多，以及商业社会对于 GPL 协议的担心导致的，我们细细掰扯。

GPL 协议与商业社会

我知道我要说的可能会激怒一些 GPL 粉，所以在你们开始喷之前，我想说明的是：我支持 GPL，我也是 GPL 粉丝。

我写过的所有软件都使用的是 GPL 协议，我也是一直是积极出资支持 自由软件基金会 以及 软件自由保护组织 以及他们的工作的，我支持使用 GPL 协议。我在这说的无关 GPL 的合法性或者 GPL 的巨大价值 —— 毫无疑问这是一个好协议 —— 我在这要说的是业内对于这个协议的看法。

大概四年之前，我参加了一个叫做 开源智库 Open Source Think Tank 的峰会。这个峰会是一个私人小型峰会，每年都会把各大开源企业的管理人员请到加利福尼亚的酒庄。这个峰会聚焦于建立关系、构建联盟，找到并解决行业问题。

在这个峰会上，有一个分组研究，在其中，与会者被分成小组，被要求给一个真实存在的核心的开源技术推荐一个开源协议。每个小组都给出了回应。不到十分之一的小组推荐了宽容许可证，没有人推荐 GPL 许可证。

我看到了开源行业对于 Apache 协议以及 MIT 协议的逐步认可，但是他们却对花时间理解、接受和熟悉 GPL 这件事高高挂起。

在这几年里，这种趋势仍在蔓延。除了 Black Duck 的调查之外， 2015 年 GitHub 上的开源协议调查 也显示 MIT 是人们的首选。我还能看到，在我工作的 XPRIZE （我们为我们的 Global Learning XPRIZE 选择了开源协议），在我作为社区领导顾问的工作方面，我也能感觉到那种倾向，因为越来越多的客户觉得把他们的代码用 GPL 发布不舒服。

随着 大约 65% 的公司对开源事业做贡献 ，自从 2010 年以后显然开源行业已经引来了不少商业兴趣和投资。我相信，我之前说的那些趋势，已经表明这行业不认为 GPL 适合搞开源生意。

连接社区和公司

说真的，GPL 的没落不太让人吃惊，因为有如下原因。

首先，开源行业已经转型升级，它要在社区发展以及……你懂的……真正能赚钱的商业模型中做出均衡，这是它们要做的最重要的决策。在开源思想发展之初，人们有种误解说，“如果你搞出来了，他们就会用”，他们确实会来使用你的软件，但是在很多情况下，都是“如果你搞出来了，他们不是一定要给你钱。”

随着历史的进程，我们看到了许多公司，比如 Red Hat、Automattic、Docker、Canonical、Digital Ocean 等等等等，探索着在开源领域中赚钱的法子。他们探索过分发模式、服务模式，核心开源模式等等。现在可以确定的是，传统的商业软件赚钱的方式已经不再适用开源软件；因此，你得选择一个能够支持你的公司的经营方式的开源协议。在赚钱和免费提供你的技术之间找到平衡在很多情况下是很困难的一件事。

这就是我们看到那些变化的原因。尽管 GPL 是一个开源协议，但是它根本上是个自由软件协议，作为自由软件协议，它的管理以及支持是由自由软件基金会提供的。

我喜欢自由软件基金会的作品，但是他们已经把观点局限于软件必须 100% 绝对自由。对于自由软件基金会没有多少可以妥协的余地，甚至很多出名的开源项目（比如很多 Linux 发行版）仅仅是因为一丁点二进制固件就被认为是 “非自由” 软件。

对于商业来说，最复杂的是它不是非黑即白的，更多的时候是两者混合的灰色，很少有公司有自由软件基金会（或者类似的组织，比如软件自由保护组织）的那种纯粹的理念，因此我想那些公司也不喜欢选择和那些理念相关的协议。

我需要说明，我不是在这是说自由软件基金会以及类似的组织（比如软件自由保护组织）的错。他们有着打造完全自由的软件的目标，对于他们来说，走它们选择的路十分合理。自由软件基金会以及软件自由保护组织做了了不起的工作，我将继续支持这些组织以及为他们工作的人们。我只是觉得这种对纯粹性的高要求的一个后果就是让那些公司认为自己难以达到要求，因此，他们使用了非 GPL 的其他协议。

我怀疑 GPL 的使用是随着开源软件增长而变化的。在以前，启动（开源）项目的根本原因之一是对开放性和软件自由的伦理因素的严格关注。GPL 无疑是项目的自然选择，Debian、Ubuntu、Fedora 和 Linux 内核以及很多都是例子。

近年来，尽管我们已经看到了不再那么挑剔的一代开发者的出现，但是如果我说的过激一些，他们缺少对于自由的关注。对于他们来说开源软件是构建软件的务实、实用的一部分，而无关伦理。我想，这就是为什么我们发现 MIT 和 Apache 协议的流行的原因。

未来 ?

这对于 GPL 意味着什么？

我的猜想是 GPL 依然将是一个主要选项，但是开发者将将之视为纯粹的自由软件协议。我想对于软件的纯粹性有高要求的项目会优先选择 GPL 协议。但是对于商业软件，为了保持我们之前讨论过的那种平衡，他们不会那么做。我猜测， MIT 以及 Apache 依然会继续流行下去。

不管怎样，好消息是开源/自由软件行业确实在增长。无论使用的协议会发生怎样的变化，技术确实变得更加开放，可以接触，人人都能使用。

作者简介：

Jono Bacon - Jono Bacon 是一位领袖级的社区管理者、演讲者、作者和播客主。他是 Jono Bacon 咨询公司的创始人，提供社区战略和执行、开发者流程和其它的服务。他之前任职于 GitHub、Canonical 和 XPRIZE、OpenAdvantage 的社区总监，并为大量的组织提供咨询和顾问服务。

via: https://opensource.com/article/17/2/decline-gpl

作者：Jono Bacon 译者：name1e5s 校对：wxy

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