unikernel 实质上是一个缩减的操作系统，它可以与应用程序结合成为一个 unikernel 程序，它通常在虚拟机中运行。下载《开放云指南》了解更多。

当涉及到操作系统、容器技术和 unikernel，趋势是朝着微型化发展。什么是 unikernel？unikernel 实质上是一个缩减的操作系统（特指 “unikernel”），它可以与应用程序结合成为一个 unikernel 程序, 它通常在虚拟机中运行。它们有时被称为库操作系统，因为它包含了使应用程序能够将硬件和网络协议与一组访问控制和网络层隔离的策略相结合使用的库。

在讨论云计算和 Linux 时容器常常会被提及，而 unikernel 也在做一些变革。容器和 unikernel 都不是新事物。在 20 世纪 90 年代就有类似 unikernel 的系统，如 Exokernel，而如今流行的 unikernel 系统则有 MirageOS 和 OSv。 Unikernel 程序可以独立使用并在异构环境中部署。它们可以促进专业化和隔离化服务，并被广泛用于在微服务架构中开发应用程序。

作为 unikernel 如何引起关注的一个例子，你可以看看 Docker 收购了基于 Cambridge 的 Unikernel 系统，并且已在许多情况下在使用 unikernel。

unikernel，就像容器技术一样, 它剥离了非必需的的部分，因此它们对应用程序的稳定性、可用性以及安全性有非常积极的影响。在开源领域，它们也吸引了许多顶级，最具创造力的开发人员。

Linux 基金会最近宣布发布了其 2016 年度报告开放云指南：当前趋势和开源项目指南。这份第三年度的报告全面介绍了开放云计算的状况，并包含了一节关于 unikernel 的内容。你现在可以下载该报告。它汇总并分析研究、描述了容器、unikernel 的发展趋势，已经它们如何重塑云计算的。该报告提供了对当今开放云环境中心的各类项目的描述和链接。

在本系列文章中，我们将按类别分析指南中提到的项目，为整体类别的演变提供了额外的见解。下面, 你将看到几个重要 unikernel 项目的列表及其影响，以及它们的 GitHub 仓库的链接, 这些都是从开放云指南中收集到的：

ClickOS

ClickOS 是 NEC 的高性能虚拟化软件中间件平台，用于构建于 MiniOS/MirageOS 之上网络功能虚拟化（NFV）

• ClickOS 的 GitHub

Clive

Clive 是用 Go 编写的一个操作系统，旨在工作于分布式和云计算环境中。

HaLVM

Haskell 轻量级虚拟机（HaLVM）是 Glasgow Haskell 编译器工具包的移植，它使开发人员能够编写可以直接在 Xen 虚拟机管理程序上运行的高级轻量级虚拟机。

• HaLVM 的 GitHub

IncludeOS

IncludeOS 是在云中运行 C++ 服务的 unikernel 操作系统。它提供了一个引导加载程序、标准库以及运行服务的构建和部署系统。在 VirtualBox 或 QEMU 中进行测试，并在 OpenStack 上部署服务。

• IncludeOS 的 GitHub

Ling

Ling 是一个用于构建超级可扩展云的 Erlang 平台，可直接运行在 Xen 虚拟机管理程序之上。它只运行三个外部库 （没有 OpenSSL），并且文件系统是只读的，以避免大多数攻击。

• Ling 的 GitHub

MirageOS

MirageOS 是在 Linux 基金会的 Xen 项目下孵化的库操作系统。它使用 OCaml 语言构建的 unikernel 可以用于各种云计算和移动平台上安全的高性能网络应用。代码可以在诸如 Linux 或 MacOS X 等普通的操作系统上开发，然后编译成在 Xen 虚拟机管理程序下运行的完全独立的专用 Unikernel。

• MirageOS 的 GitHub

OSv

OSv 是 Cloudius Systems 为云设计的开源操作系统。它支持用 Java、Ruby（通过 JRuby）、JavaScript（通过 Rhino 和 Nashorn）、Scala 等编写程序。它运行在 VMware、VirtualBox、KVM 和 Xen 虚拟机管理程序上。

• OSV 的 GitHub

Rumprun

Rumprun 是一个可用于生产环境的 unikernel，它使用 rump 内核提供的驱动程序，添加了 libc 和应用程序环境，并提供了一个工具链，用于将现有的 POSIX-y 程序构建为 Rumprun unikernel。它适用于 KVM 和 Xen 虚拟机管理程序和裸机，并支持用 C、C ++、Erlang、Go、Java、JavaScript（Node.js）、Python、Ruby、Rust 等编写的程序。

• Rumprun 的 GitHub

Runtime.js

Runtime.js 是用于在云上运行 JavaScript 的开源库操作系统（unikernel），它可以与应用程序捆绑在一起，并部署为轻量级和不可变的 VM 镜像。它基于 V8 JavaScript 引擎，并使用受 Node.js 启发的事件驱动和非阻塞 I/O 模型。KVM 是唯一支持的虚拟机管理程序。

• Runtime.js 的 GitHub

UNIK

Unik 是 EMC 推出的工具，可以将应用程序源编译为 unikernel（轻量级可引导磁盘镜像）而不是二进制文件。它允许应用程序在各种云提供商、嵌入式设备（IoT） 以及开发人员的笔记本或工作站上安全地部署，资源占用很少。它支持多种 unikernel 类型、处理器架构、管理程序和编排工具，包括 Cloud Foundry、Docker 和 Kubernetes。Unik 的 GitHub

（题图：Pixabay）

via: https://www.linux.com/news/open-cloud-report/2016/guide-open-cloud-age-unikernel

作者：SAM DEAN 译者：geekpi 校对：wxy

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

CoreOS，一款最新的 Linux 发行版本，支持自动升级内核软件，提供各集群间配置的完全控制。

关于使用哪个版本的 Linux 服务器系统的争论，常常是以这样的话题开始的：

你是喜欢基于 Red Hat Enterprise Linux （RHEL） 的 CentOS 或者 Fedora，还是基于 Debian 的 Ubuntu，抑或 SUSE 呢？

但是现在，一款名叫 CoreOS 容器 Linux 的 Linux 发行版加入了这场“圣战”。这个最近在 Linode 服务器上提供的 CoreOS，和它的老前辈比起来，它使用了完全不同的实现方法。

你可能会感到不解，这里有这么多成熟的 Linux 发行版本，为什么要选择用 CoreOS ？借用 Linux 主干分支的维护者，也是 CoreOS 顾问的 Greg Kroah-Hartman 先生的一句话：

CoreOS 可以控制发行版的升级（基于 ChromeOS 代码），并结合了 Docker 和潜在的核对/修复功能，这意味着不用停止或者重启你的相关进程，就可以在线升级。测试版本已经支持此功能，这是史无前例的。

当 Greg Kroah-Hartman 做出这段评价时，CoreOS 还处于 α 测试阶段，当时也许就是在硅谷的一个车库当中，开发团队正在紧锣密鼓地开发此产品，但 CoreOS 不像最开始的苹果或者惠普，其在过去的四年当中一直稳步发展。

当我参加在旧金山举办的 2017 CoreOS 大会时，CoreOS 已经支持谷歌云、IBM、AWS 和微软的相关服务。现在有超过 1000 位开发人员参与到这个项目中，并为能够成为这个伟大产品的一员而感到高兴。

究其原因，CoreOS 从开始就是为容器而设计的轻量级 Linux 发行版，其起初是作为一个 Docker 平台，随着时间的推移， CoreOS 在容器方面走出了自己的道路，除了 Docker 之外，它也支持它自己的容器 rkt （读作 rocket ）。

不像大多数其他的 Linux 发行版，CoreOS 没有包管理器，取而代之的是通过 Google ChromeOS 的页面自动进行软件升级，这样能提高在集群上运行的机器/容器的安全性和可靠性。不用通过系统管理员的干涉，操作系统升级组件和安全补丁可以定期推送到 CoreOS 容器。

你可以通过 CoreUpdate 和它的 Web 界面上来修改推送周期，这样你就可以控制你的机器何时更新，以及更新以多快的速度滚动分发到你的集群上。

CoreOS 通过一种叫做 etcd 的分布式配置服务来进行升级，etcd 是一种基于 YAML 的开源的分布式哈希存储系统，它可以为 Linux 集群容器提供配置共享和服务发现等功能。

此服务运行在集群上的每一台服务器上，当其中一台服务器需要下线升级时，它会发起领袖选举，以便服务器更新时整个Linux 系统和容器化的应用可以继续运行。

对于集群管理，CoreOS 之前采用的是 fleet 方法，这将 etcd 和 systemd 结合到分布式初始化系统中。虽然 fleet 仍然在使用，但 CoreOS 已经将 etcd 加入到 Kubernetes 容器编排系统构成了一个更加强有力的管理工具。

CoreOS 也可以让你定制其它的操作系统相关规范，比如用 cloud-config 的方式管理网络配置、用户账号和 systemd 单元等。

综上所述，CoreOS 可以不断地自行升级到最新版本，能让你获得从单独系统到集群等各种场景的完全控制。如 CoreOS 宣称的，你再也不用为了改变一个单独的配置而在每一台机器上运行 Chef 了。

假如说你想进一步的扩展你的 DevOps 控制，CoreOS 能够轻松地帮助你部署 Kubernetes。

CoreOS 从一开始就是构建来易于部署、管理和运行容器的。当然，其它的 Linux　发行版，比如 RedHat 家族的原子项目也可以达到类似的效果，但是对于那些发行版而言是以附加组件的方式出现的，而 CoreOS 从它诞生的第一天就是为容器而设计的。

当前容器和 Docker 已经逐渐成为商业系统的主流，如果在可预见的未来中你要在工作中使用容器，你应该考虑下 CoreOS，不管你的系统是在裸机硬件上、虚拟机还是云上。

如果有任何关于 CoreOS 的观点或者问题，还请在评论栏中留言。如果你觉得这篇博客还算有用的话，还请分享一下~

关于博主：Steven J. Vaughan-Nichols 是一位经验丰富的 IT 记者，许多网站中都刊登有他的文章，包括 ZDNet.com、PC Magazine、InfoWorld、ComputerWorld、Linux Today 和 eWEEK 等。他拥有丰富的 IT 知识 - 而且他曾参加过智力竞赛节目 Jeopardy ！他的相关观点都是自身思考的结果，并不代表 Linode 公司，我们对他做出的贡献致以最真诚的感谢。如果想知道他更多的信息，可以关注他的 Twitter @sjvn。

via: https://medium.com/linode-cube/the-what-why-and-wow-behind-the-coreos-container-linux-fa7ceae5593c

作者：Steven J. Vaughan-Nichols 译者：吴霄/toyijiu 校对：wxy

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

投身开源软件的人，多是有情怀的理想主义者，期望通过无私的努力，让世界更美好。这是原本专注于专利问题的笔者，偶然被牵入到开源研究项目后，对他们所产生的第一印像。

然而，即使专利人也有专利情怀，现实世界中开源与专利的碰撞依然难免丑陋。这要求投身开源的理想主义者必须比一般人更加坚强和执着，才可能推进他们的美好理想。以下，笔者从伸向开源情怀的专利咸猪手这一角度，来提示一下开源人所要面对的现实、承受的考验。

引子

相信社区里的人对此事并不陌生：一名开源软件作者发出求救的呼声，指出知名公司将他的开源软件 XXL-JOB 申请成了专利。

按照开源中国博客文章，XXL-JOB 作者于 2017 年 6 月在他人提醒之后，发现他的作品 XXL-JOB 被他人申请了中国专利（CN201610843823.X）。依照开源中国的另一篇博客文章，XXL-JOB 作者委托开源中国与专利申请人进行交涉，作者的基本诉求包括：申请人撤回专利申请并发布声明加以澄清。开源中国与作者进一步希望，如，申请人从事实和技术角度加以澄清，并提出如果专利授权，应声明其与有关开源项目的关系，并“无偿开源”等。

开源软件遭遇专利咸猪手

我们暂且将之称为开源软件遭遇专利咸猪手吧！应当说，此事件很典型，无论在国内还是国外都不是孤立性事件。事情的根本在于：开源软件的开发者仅对自己智力劳动成果的知识产权做了很少的保留，将软件基本开放、贡献给公众无偿使用。而开发者的无私奉献却被一些人窃取或搭便车谋利：包括但不限于通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分，或是针对某些典型应用场景设下埋伏，迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

开源软件开发者的情怀在于：多少相信，免费获取和利用知识是人的权利。投身开源的人，对售卖知识的知识产权制度多少有些敌意。不得不承认，我们当今的知识产权制度并不完美，最典型的就是专利海盗现象，它给技术进步和产业发展，尤其是软件产业发展带来了巨大的负面冲击。从某种意义上讲，开源软件的产生，就是一种打破目前知识产权制度对软件行业过度禁锢的积极尝试，而且发展势头良好。

而现实世界比较复杂。从开放的眼光看，存在即为合理，开源软件所遭遇的海盗式专利咸猪手，并非一无是处。因为目前不完美的知识产权制度仍是当下最为现实的解决方案。对于智力成果给予专有保护的必要性和积极意义是毋庸质疑的。知识产权专有保护的着力点主要在限制商业应用；而对于利用知识、技术进行学习和研发，则采取支持、鼓励的态度。

专利咸猪手的法理依据是这样的：

• 在前人智力成果的基础上再进行创造性改进是每个人的权利，是利于社会进步的，即使前人智力成果也受知识产权保护。
• 创造性改进的成果也是智慧成果，可以申请成专利，它的知识产权属于做出创造性改进的人，也就是专利发明人。

应再强调，这里的发明人不应将前人的成果纳入自己的权利保护范围，仅可以就自己做出的改进部分主张权利。相信有情怀的开源人和专利人都不会反对以上两条。

而以下这两个问题，大家可以充分探讨和质疑：仅就 XXL-JOB 专利事件，专利是将 XXL-JOB 的已有技术也纳入了保护范围？还是仅对 XXL-JOB 的改进部分要求进行保护？

如果情况属于前者，该专利将不符合法定授权条件，不应获得授权。如果情况属于后者，第三方发明人获得专利保护则是完全正当的。

现实的狗血在于，想回答清楚这个问题：专利是否将 XXL-JOB 的已有技术纳入了保护范围，是技术上很复杂，成本非常高的问题。负责任地回答这个问题，需要进行非常专业的技术和法律分析，而得出的结论还不能是定论。没错，这个专业分析的成本几千元起，花几万元可能也不奇怪，即专业性强，还成本高，而且没有定论，这一点是肯定的。

为什么没有定论？简单讲，经过司法程序认定，例如，在产生了生效判决的情况下，才有司法定论。请注意，是生效判决，指不被后续司法救济程序推翻的判决。通常，有了司法定论可能还平息不了学术争议，但司法定论是现实中管事的。而要得到司法定论，成本就更高了。

这是开源作者必然会面对的局面，并且常常让人感觉悲哀无助，因为专业性问题可以先放其次，高成本是谁都难以轻易承担的。

还就 XXL-JOB 专利事件而言，即使专利说明书中包括了 XXL-JOB 的技术内容，也不能简单得出专利要求将 XXL-JOB 的已有技术内容纳入了保护范围的结论。技术改进中涉及原有技术的内容是正当的、不可避免的。专利申请人是否不恰当地将 XXL-JOB 的已有技术内容纳入了保护范围，各方各有观点，但尚无定论，第一个要正式面对和回答这一问题的就是专利局的专利审查员。

专利审查员的工作受技术条件、现实条件的制约，也并不能解决全部问题。很多问题只能留待以后产生争议时，由后续准司法和司法程序解决。这又回到了前面所提及的：问题分析专业性强，成本高。

开源作者未完结的悲哀无助

开源作者所受的悲哀无助还没有完。使问题更为加剧的是恶意利用制度和程序而产生的问题。简单而言，就是专利海盗式的操作。既然问题难有定论，就拦不住有人在商业利益的驱动之下，百折不挠地努力尝试打各种擦边球，而且总会有所收获。他们中的急先锋便是各类专利海盗。专利海盗充分利用了复杂的程序、高专业性、高成本形成的高门槛。专利，经过专业性的包装等手法，会给专利审查增加很高的技术难度，有可能将开源软件中的已有技术改头换面包装成改进过的新技术，变相纳入私有保护范围，从而混水摸鱼得偿所愿：例如通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分，或是针对某些典型应用场景设下埋伏，迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

实际上，以这种方式做事的，不仅止是专利海盗，背后和之后还有大批正当公司，因为有商业利益驱动。有可能有些激进，但这属于合理利用法律制度和程序。这个问题，至少目前还看不到根本性的解决办法。

开源软件遭遇专利咸猪手，说开了，就是被摘了桃子。实际上，专利高手，充分利用制度和程序，合理合法地何止是摘开源软件的桃子，谁的桃子都摘。这已经属于商业经营活动中的正常专利风险，任谁都避不干净。

白话总结

如果以简单直白的方式总结一下的话：任何人都有权利对开源软件中的技术方案加以改进然后去申请专利，如果做得专业老道，有可能用这些专利卡住开源软件的脖子。这种做法合理合法，其中手段高超的，还会被圈里人称赞为：专利布局水平很高!

笔者忍不住要插一句：当年我们都不懂知识产权时，外国人没少这么搞我们。现在，我们也已经有一些高手可以这么去搞外国人了。这是有钱才玩得起的昂贵的游戏。一旦搞起来，谈不上对内对外，外国人和我们对内自然也免不了一样搞法。没办法，这就是西方人设计的知识产权制度骨子里的东西。

这是开源作者必然面对的局面，很多时候除了想开些，除了以很高的成本对簿公堂，没有现实的解决办法。笔者有把世界描写得太过黑暗吗？

我看到，投身开源软件的有情怀的理想主义者，有一些在这些黑暗和不公的打击之下，愤而退出了开源事业。笔者非常理解他们。我还看到，更多的人无视这些打击，以不变的情怀和理想，在这条道路上继续栉风沐雨，砥砺前行。笔者非常敬佩他们。人间正道是沧桑。

开源软件开发者这边的故事讲完了，而开源用户应当如何面对这些问题呢？希望以后有机会与大家讨论。

（题图：legalraasta.com）

作者：李可，江湖人称“可哥”，老牌专利代理人，集慧智佳知识产权咨询公司的知识产权高级咨询师。70 后文艺理工男，属牛，性子慢但踏实稳妥。

这篇帖子是有关 在 Ubuntu Core 开发 ROS 原型到成品 系列的补充，用来回答我收到的一个问题： “我想做一个工厂镜像，但我不想使我的 snap 公开” 当然，这个问题和回答都不只是针对于机器人技术。在这篇帖子中，我将会通过两种方法来回答这个问题。

开始之前，你需要了解一些制作 Ubuntu Core 镜像的背景知识，如果你已经看过 在 Ubuntu Core 开发 ROS 原型到成品[3 系列文章（具体是第 5 部分），你就已经有了需要的背景知识，如果没有看过的话，可以查看有关 制作你的 Ubuntu Core 镜像 的教程。

如果你已经了解了最新的情况，并且当我说 “模型定义” 或者 “模型断言” 时知道我在谈论什么，那就让我们开始通过不同的方法使用私有 sanps 来制作 Ubuntu Core 镜像吧。

方法 1： 不要上传你的 snap 到商店

这是最简单的方法了。首先看一下这个有关模型定义的例子——amd64-model.json：

{
    "type": "model",
    "series": "16",
    "model": "custom-amd64",
    "architecture": "amd64",
    "gadget": "pc",
    "kernel": "pc-kernel",
    "authority-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "brand-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "timestamp": "2017-06-23T21:03:24+00:00",
    "required-snaps": ["kyrofa-test-snap"]
}

让我们将它转换成模型断言：

$ cat amd64-model.json | snap sign -k my-key-name > amd64.model
You need a passphrase to unlock the secret key for
user: "my-key-name"
4096-bit RSA key, ID 0B79B865, created 2016-01-01
...

获得模型断言：amd64.model 后，如果你现在就把它交给 ubuntu-image 使用，你将会碰钉子：

$ sudo ubuntu-image -c stable amd64.model 
Fetching core
Fetching pc-kernel
Fetching pc
Fetching kyrofa-test-snap
error: cannot find snap "kyrofa-test-snap": snap not found
COMMAND FAILED: snap prepare-image --channel=stable amd64.model /tmp/tmp6p453gk9/unpack

实际上商店中并没有名为 kyrofa-test-snap 的 snap。这里需要重点说明的是：模型定义（以及转换后的断言）只包含了一系列的 snap 的名字。如果你在本地有个那个名字的 snap，即使它没有存在于商店中，你也可以通过 --extra-snaps 选项告诉 ubuntu-image 在断言中匹配这个名字来使用它：

$ sudo ubuntu-image -c stable \
         --extra-snaps /path/to/kyrofa-test-snap_0.1_amd64.snap \
         amd64.model
Fetching core
Fetching pc-kernel
Fetching pc
Copying "/path/to/kyrofa-test-snap_0.1_amd64.snap" (kyrofa-test-snap)
kyrofa-test-snap already prepared, skipping
WARNING: "kyrofa-test-snap" were installed from local snaps
disconnected from a store and cannot be refreshed subsequently!
Partition size/offset need to be a multiple of sector size (512).
The size/offset will be rounded up to the nearest sector.

现在，在 snap 并没有上传到商店的情况下，你已经获得一个预装了私有 snap 的 Ubuntu Core 镜像（名为 pc.img）。但是这样做有一个很大的问题，ubuntu-image 会提示一个警告：不通过连接商店预装 snap 意味着你没有办法在烧录了这些镜像的设备上更新它。你只能通过制作新的镜像并重新烧录到设备的方式来更新它。

方法 2： 使用品牌商店

当你注册了一个商店账号并访问 dashboard.snapcraft.io 时，你其实是在标准的 Ubuntu 商店中查看你的 snap。如果你是在系统中新安装的 snapd，默认会从这个商店下载。虽然你可以在 Ubuntu 商店中发布私有的 snap，但是你不能将它们预装到镜像中，因为只有你（以及你添加的合作者）才有权限去使用它。在这种情况下制作镜像的唯一方式就是公开发布你的 snap，然而这并不符合这篇帖子的目的。

对于这种用例，我们有所谓的 品牌商店。品牌商店仍然托管在 Ubuntu 商店里，但是它们是针对于某一特定公司或设备的一个定制的、专门的版本。品牌商店可以继承或者不继承标准的 Ubuntu 商店，品牌商店也可以选择开放给所有的开发者或者将其限制在一个特定的组内（保持私有正是我们想要的）。

请注意，这是一个付费功能。你需要 申请一个品牌商店。请求通过后，你将可以通过访问用户名下的 “stores you can access” 看到你的新商店。

在那里你可以看到多个有权使用的商店。最少的情况下也会有两个：标准的 Ubuntu 商店以及你的新的品牌商店。选择品牌商店（红框），进去后记录下你的商店 ID（蓝框）：等下你将会用到它。

在品牌商店里注册名字或者上传 snap 和标准的商店使用的方法是一样的，只是它们现在是上传到你的品牌商店而不是标准的那个。如果你将品牌商店放在 unlisted 里面，那么这些 snap 对外部用户是不可见。但是这里需要注意的是第一次上传 snap 的时候需要通过 web 界面来操作。在那之后，你可以继续像往常一样使用 Snapcraft 来操作。

那么这些是如何改变的呢？我的 “kyrofal-store” 从 Ubuntu 商店继承了 snap，并且还包含一个发布在稳定通道中的 “kyrofa-bran-test-snap” 。这个 snap 在 Ubuntu 商店里是使用不了的，如果你去搜索它，你是找不到的：

$ snap find kyrofa-branded
The search "kyrofa-branded" returned 0 snaps

但是使用我们前面记录的商店 ID，我们可以创建一个从品牌商店而不是 Ubuntu 商店下载 snap 的模型断言。我们只需要将 “store” 键添加到 JSON 文件中，就像这样：

{
    "type": "model",
    "series": "16",
    "model": "custom-amd64",
    "architecture": "amd64",
    "gadget": "pc",
    "kernel": "pc-kernel",
    "authority-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "brand-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "timestamp": "2017-06-23T21:03:24+00:00",
    "required-snaps": ["kyrofa-branded-test-snap"],
    "store": "ky<secret>ek"
}

使用方法 1 中的方式对它签名，然后我们就可以像这样很简单的制作一个预装有我们品牌商店私有 snap 的 Ubuntu Core 镜像：

$ sudo ubuntu-image -c stable amd64.model
Fetching core
Fetching pc-kernel
Fetching pc
Fetching kyrofa-branded-test-snap
Partition size/offset need to be a multiple of sector size (512).
The size/offset will be rounded up to the nearest sector.

现在，和方法 1 的最后一样，你获得了一个为工厂准备的 pc.img。并且使用这种方法制作的镜像中的所有 snap 都从商店下载的，这意味着它们将能像平常一样自动更新。

结论

到目前为止，做这个只有两种方法。当我开始写这篇帖子的时候，我想过可能还有第三种（将 snap 设置为私有然后使用它制作镜像），但最后证明是不行的。

另外，我们也收到很多内部部署或者企业商店的请求，虽然这样的产品还没有公布，但是商店团队正在从事这项工作。一旦可用，我将会写一篇有关它的文章。

希望能帮助到您！

关于作者

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

via: https://insights.ubuntu.com/2017/07/11/ubuntu-core-making-a-factory-image-with-private-snaps/

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

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

Linux 中高效的备份拷贝命令

在 Linux 上能使用鼠标点来点去的图形化界面是一件很美妙的事……但是如果你喜欢的开发交互环境和编译器是终端窗口、Bash 和 Vim，那你应该像我一样经常和终端打交道。

即使是不经常使用终端的人，如果对终端环境深入了解也能获益良多。举个例子—— cp 命令，据 维基百科) 的解释，cp （意即 copy）命令是第一个版本的 Unix 系统的一部分。连同一组其它的命令 ls、mv、cd、pwd、mkdir、vi、sh、sed 和 awk ，还有提到的 cp 都是我在 1984 年接触 System V Unix 系统时所学习的命令之一。cp 命令最常见的用法是制作文件副本。像这样：

cp sourcefile destfile

在终端中执行此命令，上述命令将名为 sourcefile 的文件复制到名为 destfile 的文件中。如果在执行命令之前 destfile 文件不存在，那将会创建此文件，如果已经存在，那就会覆盖此文件。

这个命令我不知道自己用了多少次了（我也不想知道），但是我知道在我编写测试代码的时候，我经常用，为了保留当前正常的版本，而且又能继续修改，我会输入这个命令：

cp test1.py test1.bak

在过去的30多年里，我使用了无数次这个命令。另外，当我决定编写我的第二个版本的测试程序时，我会输入这个命令：

cp test1.py test2.py

这样就完成了修改程序的第一步。

我通常很少查看 cp 命令的参考文档，但是当我在备份我的图片文件夹的时候（在 GUI 环境下使用 “file” 应用），我开始思考“在 cp 命令中是否有个参数支持只复制新文件或者是修改过的文件。”果然，真的有！

高效用法 1：更新你的文件夹

比如说在我的电脑上有一个存放各种文件的文件夹，另外我要不时的往里面添加一些新文件，而且我会不时地修改一些文件，例如我手机里下载的照片或者是音乐。

假设我收集的这些文件对我而言都很有价值，我有时候会想做个拷贝，就像是“快照”一样将文件保存在其它媒体。当然目前有很多程序都支持备份，但是我想更为精确的将目录结构复制到可移动设备中，方便于我经常使用这些离线设备或者连接到其它电脑上。

cp 命令提供了一个易如反掌的方法。例子如下：

在我的 Pictures 文件夹下，我有这样一个文件夹名字为 Misc。为了方便说明，我把文件拷贝到 USB 存储设备上。让我们开始吧！

me@desktop:~/Pictures$ cp -r Misc /media/clh/4388-D5FE
me@desktop:~/Pictures$

上面的命令是我从按照终端窗口中完整复制下来的。对于有些人来说不是很适应这种环境，在我们输入命令或者执行命令之前，需要注意的是 me@mydesktop:~/Pictures 这个前缀，me 这个是当前用户，mydesktop 这是电脑名称，~/Pictures 这个是当前工作目录，是 /home/me/Pictures 完整路径的缩写。

我输入这个命令 cp -r Misc /media/clh/4388-D5FE 并执行后 ，拷贝 Misc 目录下所有文件（这个 -r 参数，全称 “recursive”，递归处理，意思为本目录下所有文件及子目录一起处理）到我的 USB 设备的挂载目录 /media/clh/4388-D5FE。

执行命令后回到之前的提示，大多数命令继承了 Unix 的特性，在命令执行后，如果没有任何异常什么都不显示，在任务结束之前不会显示像 “execution succeeded” 这样的提示消息。如果想获取更多的反馈，就使用 -v 参数让执行结果更详细。

下图中是我的 USB 设备中刚刚拷贝过来的文件夹 Misc ，里面总共有 9 张图片。

假设我要在原始拷贝路径下 ~/Pictures/Misc 下添加一些新文件，就像这样：

现在我想只拷贝新的文件到我的存储设备上，我就使用 cp 的“更新”和“详细”选项。

me@desktop:~/Pictures$ cp -r -u -v Misc /media/clh/4388-D5FE
'Misc/asunder.png' -> '/media/clh/4388-D5FE/Misc/asunder.png'
'Misc/editing tags guayadeque.png' -> '/media/clh/4388-D5FE/Misc/editing tags guayadeque.png'
'Misc/misc on usb.png' -> '/media/clh/4388-D5FE/Misc/misc on usb.png'
me@desktop:~/Pictures$

上面的第一行中是 cp 命令和具体的参数（-r 是“递归”， -u 是“更新”，-v 是“详细”）。接下来的三行显示被复制文件的信息，最后一行显示命令行提示符。

通常来说，参数 -r 也可用更详细的风格 --recursive。但是以简短的方式，也可以这么连用 -ruv。

高效用法 2：版本备份

回到一开始的例子中，我在开发的时候定期给我的代码版本进行备份。然后我找到了另一种更好用的 cp 参数。

假设我正在编写一个非常有用的 Python 程序，作为一个喜欢不断修改代码的开发者，我会在一开始编写一个程序简单版本，然后不停的往里面添加各种功能直到它能成功的运行起来。比方说我的第一个版本就是用 Python 程序打印出 “hello world”。这只有一行代码的程序就像这样：

print 'hello world'

然后我将这个代码保存成文件命名为 test1.py。我可以这么运行它：

me@desktop:~/Test$ python test1.py
hello world
me@desktop:~/Test$

现在程序可以运行了，我想在添加新的内容之前进行备份。我决定使用带编号的备份选项，如下：

clh@vancouver:~/Test$ cp --force --backup=numbered test1.py test1.py
clh@vancouver:~/Test$ ls
test1.py  test1.py.~1~
clh@vancouver:~/Test$ 

所以，上面的做法是什么意思呢？

第一，这个 --backup=numbered 参数意思为“我要做个备份，而且是带编号的连续备份”。所以一个备份就是 1 号，第二个就是 2 号，等等。

第二，如果源文件和目标文件名字是一样的。通常我们使用 cp 命令去拷贝成自己，会得到这样的报错信息：

cp: 'test1.py' and 'test1.py' are the same file

在特殊情况下，如果我们想备份的源文件和目标文件名字相同，我们使用 --force 参数。

第三，我使用 ls （意即 “list”）命令来显示现在目录下的文件，名字为 test1.py 的是原始文件，名字为 test1.py.~1~ 的是备份文件

假如现在我要加上第二个功能，在程序里加上另一行代码，可以打印 “Kilroy was here.”。现在程序文件 test1.py 的内容如下：

print 'hello world'
print 'Kilroy was here'

看到 Python 编程多么简单了吗？不管怎样，如果我再次执行备份的步骤，结果如下：

clh@vancouver:~/Test$ cp --force --backup=numbered test1.py test1.py
clh@vancouver:~/Test$ ls
test1.py test1.py.~1~ test1.py.~2~
clh@vancouver:~/Test$

现在我有有两个备份文件： test1.py.~1~ 包含了一行代码的程序，和 test1.py.~2~ 包含两行代码的程序。

这个很好用的功能，我考虑做个 shell 函数让它变得更简单。

最后总结

第一，Linux 手册页，它在大多数桌面和服务器发行版都默认安装了，它提供了更为详细的使用方法和例子，对于 cp 命令，在终端中输入如下命令：

man cp

对于那些想学习如何使用这些命令，但不清楚如何使用的用户应该首先看一下这些说明，然后我建议创建一个测试目录和文件来尝试使用命令和选项。

第二，兴趣是最好的老师。在你最喜欢的搜索引擎中搜索 “linux shell tutorial”，你会获得很多有趣和有用的资源。

第三，你是不是在想，“为什么我要用这么麻烦的方法，图形化界面中有相同的功能，只用点击几下岂不是更简单？”，关于这个问题我有两个理由。首先，在我们工作中需要中断其他工作流程以及大量使用点击动作时，点击动作可就不简单了。其次，如果我们要完成流水线般的重复性工作，通过使用 shell 脚本和 shell 函数以及 shell 重命名等功能就能很轻松的实现。

你还知道关于 cp 命令其他更棒的使用方式吗？请在留言中积极回复哦～

（题图：stonemaiergames.com）

作者简介：

Chris Hermansen - 1978 年毕业于英国哥伦比亚大学后一直从事计算机相关职业，我从 2005 年开始一直使用 Linux、Solaris、SunOS，在那之前我就是 Unix 系统管理员了，在技术方面，我的大量的职业生涯都是在做数据分析，尤其是空间数据分析，我有大量的编程经验与数据分析经验，熟练使用 awk、Python、PostgreSQL、PostGIS 和 Groovy。

via: https://opensource.com/article/17/7/two-great-uses-cp-command

作者：Chris Hermansen 译者：bigdimple 校对：wxy

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

关于 React.js 的开源许可证从去年 7 月份争议到现在，Apache 基金会终于确认了立场，反对使用 React.js 和 Facebook 其他使用此许可证（BSD+Patents licensed）的流行软件。

最近，随着开源运动不断壮大，这边 LC3 大会刚过去不久，人们的热情还是未曾消去，那边 Apache 和 Facebook 又搅动着整个社区。

作为本次事件焦点的 Facebook Patents license 已经不是第一次出风头了，时不时成为人们讨论的主题。

上一次挑动大众神经是在 2016 年 7 月，Facebook 给 React 应用的开源许可协议是，在 BSD3-clause 协议基础上加上旨在保护 Facebook 自身的扩展协议。而这一次依然是围绕 Facebook Patents license 展开，简单梳理此次事件：

• 2017 年 4 月，Apache Cassandra 项目正考虑增加 RocksDB 作为存储引擎，但考虑到专利授权的问题，Jeff Jirsa 向 Apache 法律社区寻求意见。
• 2017 年 6 月，Apache 法律社区开始讨论 Facebook Patents license 协议专利授权的不对称性问题，且该协议与Apache Software License（即 Apache 2.0 等）不兼容。
• 2017 年 7 月 15 日，Apache Software Foundation（以下简称 ASF）主管兼法律事务副主席 Chris Mattmann 正式发表声明称：Facebook BSD+Patents license（以下简称 FB+PL）已经正式被列入 “CategoryX” 列表，因此 Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码；而已经发布的代码，涉及 FB+PL 许可证的，需要在 8 月 31 号前完成替换。

这一结论一出场便自带光环，引起了整个社区的关注，包括国内著名社交论坛知乎。当然，其对 Apache 项目自身的影响不比外界的关注度低。

如，虽然 Facebook 已于本月 17 号将 RocksDB 许可证更新为 Apache 2.0 和 GPLv2 双许可，但更大的问题是 React 也是基于 FB+PL 开源，Apache 的 CouchDB 项目、Apache Superset 项目等都依赖于 React，但是要让其开发人员在一个月内摆脱对 React 的依赖似乎也不是一件简单的事情。

到底是什么原因让 ASF 对 Facebook 的 FB+PL 许可协议下禁止令？要回答这个问题，需要先分析一下 FB+PL 许可协议。

众所周知，Facebook 也算是开源社区的中坚力量，截至目前已经发布了很多开源软件技术，包括使用广泛的 React.JS 框架和键值数据库 RocksDB。

不过，Facebook 没有像其他社区一样，自定义自己的开源许可证，也没有仅采用现存的开源许可证，而是采用 “BSD+Patents license” 许可证组合授权其大部分项目，该协议组合也被称为 FB+PL 组合。

其中，BSD 是指 BSD3-clause license，是被 OSI 和 FSF 都认可的开源软件许可证，也是被业界称为“宽松型”的开源许可证。

正是这个“宽松型”的 BSD 许可证附加了专利条款的开源许可协议，已经被 ASF 列为 “Category X”，杜绝了任何以 FB+PL 授权的软件进入 Apache 项目中的可能性，等于 FB+PL 已被 Apache 明确打入冷宫。

FB+PL 协议中，BSD3-clause license 本身没有问题，问题自然就出在 Facebook Patents license，即 Facebook 开源软件组合协议 FB+PL 中的附加专利许可条款。

以下是 Facebook Patents license 条款内容：

Additional Grant of Patent Rights Version 2

"Software" means the React software distributed by Facebook, Inc.

Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software
("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable
(subject to the termination provision below) license under any Necessary
Claims, to make, have made, use, sell, offer to sell, import, and otherwise
transfer the Software. For avoidance of doubt, no license is granted under
Facebook's rights in any patent claims that are infringed by (i) modifications
to the Software made by you or any third party or (ii) the Software in
combination with any software or other technology.

The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion: (i) against Facebook or any of its subsidiaries or corporate
affiliates, (ii) against any party if such Patent Assertion arises in whole or
in part from any software, technology, product or service of Facebook or any of
its subsidiaries or corporate affiliates, or (iii) against any party relating
to the Software. Notwithstanding the foregoing, if Facebook or any of its
subsidiaries or corporate affiliates files a lawsuit alleging patent
infringement against you in the first instance, and you respond by filing a
patent infringement counterclaim in that lawsuit against that party that is
unrelated to the Software, the license granted hereunder will not terminate
under section (i) of this paragraph due to such counterclaim.

A "Necessary Claim" is a claim of a patent owned by Facebook that is
necessarily infringed by the Software standing alone.

A "Patent Assertion" is any lawsuit or other action alleging direct, indirect,
or contributory infringement or inducement to infringe any patent, including a
cross-claim or counterclaim.

就是以上这段不算长的附加专利授权条款，让不少开发者甚至开源社区组织顾虑重重。

对开源运动有了解的人可能都知道，开源社区对专利非常敏感，甚至有开源大佬和前辈毫不掩饰对软件专利的厌恶和痛恨。更甚者，国外有专门的反软件专利组织，但毕竟专利制度是很多国家的法律制度，不可能受某个人或某一个群体的人的意见而转移。

因此，开源社区能做的就是改变自己以及影响自己可以影响的人，所以不少开源软件许可证都有针对专利的规范条款。

不过，对于 Facebook 附加专利许可协议，开源圈内人士从一开始都不是特别待见。甚至一些反对软件专利的人认为 FB+PL 协议关于专利的授权，拥有这样的专利授权比没有这样的授权更糟糕。

究其原因，从以上 Facebook Additional Grant of Patent Rights（附加专利授权条款）可以看出，该协议是一个单边优惠协议，授予人和被授予人的权利不平衡。

简单说就是基于 FB+PL 授权的软件使用者以及基于 FB+PL 开发衍生代码的开发者，与 Facebook 的权利不平衡。一旦被许可人对 Facebook 及其子公司甚至关联公司提出直接的或间接专利诉讼，无论该诉讼是与所涉及项目有关还是无关，亦或是硬件专利诉讼，甚至是 Facebook 主动提出的专利诉讼而被告者进行的专利反诉，该协议授予用户的专利权利即刻自动终止。

另外，2015 年 4 月 10 以前，Facebook Additional Grant of Patent Rights 第一版中，针对 Facebook 任何形式的诉讼，包括反诉、以及与专利无关的诉讼，都会导致基于该协议的专利授权自动终止。后来由于社区人员对该条款争议较大， Facebook 进行了修改，也即是目前的第二版。

值得一提的是，在众多的开源许可证中，有专利权利终止以及许可证权利终止条款的许可证并不少见，例如，Apache2.0 以及GPLv2/v3 都有关于权利终止的条款约束。之所以 FB+PL 会有如此强烈的反应关键有两点：

1. FB+PL 专利终止条款过于宽泛；
2. FB+PL 专利条款使得被授予者与 Facebook 之间的权利不平衡。

从另一个层面上讲，Facebook 附加专利授权条款的存在也不是全无道理，毕竟开源软件无时无刻不在承受着来自软件专利的威胁。尽管这些年软件专利没有成功将开源运动送入坟墓，反而使其不断壮大，而开源社区对专利的排斥和恐惧却已深入骨髓。

Facebook 作为开源领域一员猛将，并且已经开源了大量的代码和技术，将所有可能导致侵权的专利技术授权给用户。另一方面，为了自身防护的原因，想办法建立一种自保的机制也在情理之中，毕竟谁都不想成为被鱼肉被屠宰的一方。

整体来讲，Facebook 附加专利授权条款是一个带有严格的惩罚性措施的协议，其严厉性特别表现在其第一版，虽然在第二版中，将诉讼范围限定于专利诉讼，但在许多人看来其范围依然是过大。

Facebook 附加专利授权条款有一种过激的表现，但是如果你能想象一个刚刚崭露头角的少年，还未有可观的积蓄（专利），在群狼环嗣，个个武装到牙齿的对手面前，那种本能的警惕，也许会对 Facebook 多少有点理解。

毕竟，即便 Facebook 附加专利授权条款在严格，对于个人开发者，以及不喜欢搞专利诉讼的组织来说，大家彼此相安无事，也不失为一件好事。

就我个人来讲，我对 Facebook 之于开源的真诚性是认可的。

目前，虽然“ 开源软件 （ Open Source Software ） ”和“ 自由软件 （ Free Software ） ”两种哲学理念还存在分歧，但很多社区以及组织包括像 Facebook 这样自我保护略显偏激的组织，都是开源/自由软件理念真诚的践行者。还有一部分像微软一样“从良”的，也为开源做了不少贡献，像这种老牌的商业公司背负了太多的包袱，一下子转身可能性不大。

当然，浑水摸鱼以及投机的分子也肯定不少。不过，开源是软件开发的未来趋势和必然走向，开源理念不仅避免了重复开发中时间、人力和资金了浪费，更是智力共享、集体智慧的完美实践。

因此，虽然目前开源运动还存在着种种的冲突和矛盾，但就像所有的新生事物一样，从萌芽到成长再到成熟都会有一个过程，而在这个过程中磕磕绊绊在所难免。

整体上说，这次 Apache 对 Facebook 附加专利授权条款下禁止令，只是开源运动在一件小事，而开源的生命力正是在这种碰撞、冲突和磨合中逐渐显现，慢慢成熟。

（题图：react-etc.net）

作者简介：付钦伟，专利代理人、专利咨询师，任职于集慧智佳知识产权咨询公司。研究生选专业“误入歧途”，进入高大上的知识产权领域，目前从事专利咨询分析工作，励志为中国知识产权事业抛头颅、洒热血。