在一个炎热的下午我代表 Linux 中国开源社区参加了 6 月 28 日的红帽媒体开放日。以下内容摘录自该活动，有删节。

本次参加红帽开放日的主要官方人员如题图，从左到右分别是：

• Fedora 社区工程师 Adam Samalik
• 红帽资深高级云技术官 Thomas Cameron
• ManageIQ 社区负责人 Carol Chen
• 社区活动经理 Jennifer Madriaga
• Fedora 社区负责人 Brian Exelbierd
• CoreOS 及 Prometheus 社区软件工程师 Max Leonard Inden

以下是问题摘录：

问题 1

记者：我想问各位社区成员一个问题，大家本身是社区的负责人或者工程师，同时又有红帽的背景，你们怎么把技术能量转换成价值贡献给社区，又怎么将社区开源的服务能力转化给红帽？

Thomas Cameron：这个问题非常好，其实对我们来说这并不是两边。我们想的首先是这个技术先提供给社区，然后社区进一步的开发完善，最后成为供企业可以使用的技术或者软件，开源是红帽的 DNA，对我们来说最重要的一件事是使这些软件取得成功，因此在我们的工作是就某个软件进行研究，或者推动在某个软件上增加什么新的功能的时候，或者要求红帽提供更多的资源。我们想的目的都是一样的，就是先把技术放进社区，然后在这个基础上进一步的开发创新，最终拿出来供企业使用。

问题 2

记者：比较一下十年前的开源社区跟今天的开源社区的用户差别，十年前的开源社区是极客在参与这个项目，现在再去社区里看一下，有一些用户级的，他可能遇到使用上的麻烦，可能到社区找一些答案，我们这个产品可能在场景应用当中遇到一些特殊的问题和麻烦，这个时候能不能向这些应用者，向被迫进入社区的人介绍一下咱们的沟通机制和反馈机制是怎么样的？另外一个我看到咱们这个众筹项目正在进行中，不同的项目的沟通机制是什么样的，能不能给用户一个介绍？

Brian Exelbierd：这个问题，涉及到沟通的机制，对任何一个项目来说沟通发生在多个不同的层次上，以 Fedora 社区为例，我们的这些核心贡献者、开发建造软件并且把它们提供出来的开发者，他们在 IRC 里进行沟通交流，但是大量的用户沟通的地点在自己感兴趣的场景或者内容不同发生在不同的地点，有些特别专注于游戏或者某个特定场景，他们都有论坛和交流地点，我们也会提醒我们的人要去不同的地点才能了解到更多用户的反馈意见。

下个问题也是令人兴奋的问题，因为 Fedora 的发布会涉及到很多不同的技术，从最开始社区发展起来的时候，我们就在不同的技术小组间建立了很强的反馈和交流机制，我们在进行测试的时候也会对所有的要素进行测试，比如我们会和 CentOS、OpenCI 这样的项目进行联系看看在哪些点上可以实现很好的集成，在哪些点上可能存在问题，这也是不同项目组之间进行沟通的方式。

Max Leonard Inden：我也想补充一个观点，我们每个项目的沟通方式都是不一样的，但是各个项目之间仍然存在着非常密切的沟通，而且我们大家的态度是一样的：所有的沟通都是受欢迎的，没有人会因为在不合适的地点问了问题而受到责难，我们会欢迎你充分的参与进来，提出问题，这是非常重要的一点。

红帽技术人员：再补充一点，关于您提到的现在的普通用户参与社区比十年前多多了，今天的科技更复杂，解决方案也更复杂，我们上游社区的项目同样更复杂，用户也在试图参与进来，第二，对于开发者而言，他使用的最主要的沟通方式是代码和编码，因为代码是他们的共同语言，虽然有人发布了代码，那么就有人从代码的角度看一看应该怎么对他检查，漏洞怎么进行修改，所以代码对于全世界的开发者来说都是同样的语言。

问题 3

记者：红帽愿意帮助我们设立站点下载 ISO 和文件么？当我在用一个红帽的帐户登录网站的时候，我去下载镜像，点按纽会发现有一个衔接，由于我们国家到美国的网速非常慢，整个镜像下载不下来，我们的工作没法进展，我们的解决方案是租一个美国的 VPS，从 VPS 再下载到本地还是会超时，第二个解决方案是再租一个香港 VPS，把这个从美国的拉到香港 VPS，再从香港拉到本地这个时候发现中间这一块又特别慢，想知道红帽有没有相对的解决方案？

Thomas Cameron：我非常理解您的这种沮丧的情绪，而且我们也感觉这样非常麻烦。但是特别坦率的说，这个问题的解决方案涉及到方方面面，它同时是法律问题，监管问题，涉及到条约等各种各样的问题，而我们在座的人没有一个人适合回答这样的问题，因为我们不是相关问题的专家，但是鉴于您有红帽的帐户，我建议您联系一个帐户经理，他会想办法帮您找解决方案，因为我们不想使您得到非常坏的体验，也不想麻烦您建立多个 VPS 的去解决，但是这个问题的最终解决还是需要律师法律团队和网络的工程团队，我们没办法回答，谢谢。

问题 4

记者：在 Fedora 社区有不同的区域划分，相互之间的差异化红帽是怎么解决的，在中国的本地化进程是怎样落地的，人员参与和贡献分别是多少？

Brian Exelbierd：我非得站起来回答您的第二个问题不可，因为要给您看一下我穿的体恤，这个体恤是 Fedora 本地化的主题，这是我们第 26 次发布 Fedora 版本的时候做的，主要目的是为了感谢全世界各地为 Fedora 本地化做出贡献的人们，因为确实有很多人都参与进来了，里面有一个泡泡写的是汉语。

我现在回答您问题的第一部分，您讲的非常对，我们 Fedora 是分区域的这个主要是有两个原因，首先是过去为了行政管理的便利做出的安排，因为这样分成不同的区域之后就可以更为容易的，相当于在本地做决定，而且资金的流动也更便利一些，随着全球化的发展，这个重要性降低了。还有第二个原因，您刚才提到差异化，差异性是无处不在的，我们希望在对话的时候，彼此的对话能在一个更适合的地方发生，因而在不同的国家和社区进行对话时所产生的决议有效，毕竟不同区域在文化上是有敏感性的。

回答您的第二个问题，您问到中国有多少贡献者，和他们在在这个社区中多活跃，对这样的问题，我们的回答永远是不够多，因为我们希望任何地方的贡献者都能够更多一些，希望他们更活跃的参与社区的活动。在中国我们也面临这样的挑战，因为中国的这些软件工程师或者相关可能的爱好者，他们本身的工作时间是非常长的，会加很长的班，通勤时间也非常长。这样他们就没有太多的精力投入开源社区的活动，此外中国社会不太重视让学生参与开源活动，大部分学生更专注于把考分弄的更高一点。我们在中国一直希望寻找对开源感兴趣的人，鼓励他们参与进来。不管你面临什么样的用户和场景，我们希望都是有人能够和你进行交流提供帮助的，所以我们非常鼓励大家的参与。

再补充一点，我们的开源社区是非常具有全球性的社区，因此绝不会在中国天然的有哪些情况就使得中国人为社区做贡献特别难，不会有这些情况，比如我本人经常在晚上九点和社区的成员进行交流，因为这个对大部分社区成员来说是最合适的时间。对不少中国人来讲，中国的时区和美国时区差异特别大，但是这一点不会阻止开源社区的交流。

问题 5

记者：我想问一个跟开源和闭源有关的问题，从软件开发的角度来讲，开源比闭源好，因为闭源一年更新的速度比较慢，而开源的广泛性和活跃性远远大于闭源，但是从商业角度来讲，开源还是不太成功的，以红帽为例，现在红帽每年的营收跟微软和闭源的软件厂商来讲远远不在一个级别上，从商业的角度讲，开源不那么成熟，作为开源社区的大拿来讲，吸引你们进入开源的热情是你们对技术的偏好，还是你们坚信开源技术未来在商业上有很大的潜质，什么支撑你们在开源领域里努力？

Thomas Cameron：在商业上我们已经比那些闭源的软件厂商要成功了。如果仔细的看一下红帽的财报跟他每年的增长，我们每年平均增长都在 20% 以上，所以从增速的角度来看，我们比所有的闭源软件开发公司做的都要好，所以从商业模式上已经证明了开源可以做的很好。关于为什么我个人会在开源中，这个回答非常简单，因为在这个世界上没有任何其他一个我所知道的行业能够让一个国家、或者一个村子里的人看到代码，并且利用手上的电脑开展相关的工作，没有任何一个其他的行业像开源社区一样把自己知道的一切都告诉别人，而在这个过程中我还拿到一份薪酬，当然我不能代表别人说话，我自己而言我觉得我是全世界最幸运的人，一方面我能够每天都在玩这些最酷的技术，同时还把我所知道的一切告诉任何感兴趣想学习的人，在这个过程中还能拿到工资。

给大家看一下大臂上的刺青，我觉得几乎没有那个闭源公司的员工会把自己公司的logo刻到自己的身上，但是我这样做了。大概五年前，闭源和开源软件公司之间的冲突还是非常显著的，但是今天我们可以看到所有的闭源软件公司都在采用开源的方法，他们也在发布大量的开源的代码，也就是说他们都看到了开源的模式，协作，为他人提供服务，以及做一切人人们生活变的更好的事情，这个模式是被大家认可的，这个时代是非常不可思议的，著名厂商包括IBM，微软，甲骨文等等，他们都在做开源的事情。

Jennifer Madriaga：我也补充一下，强调一下我们开源的核心是协作，在开源的社区里面，你会发现很多竞争对手同时也是合作的伙伴，我们和 IBM 是很好的伙伴，和微软是很好的伙伴，是 AWS、谷歌都是非常好的伙伴。重要的是没有他们的参与，没有我们的参与，这个行业就不可能取得这么大的成功。我经常到各个社区去，在这个过程中会和其他的组织进行交流，其中不少会被媒体描述为我们的竞争对手。我们也不仅仅和这些公司打交道，我们还和很多大学，非盈利机构进行沟通，这个社区是多样的，而且有大量的互动。开源社区伟大的一点是他特别促进创新，有这样的一个机构，CERN，欧洲原子能组织，他们的每一个软件都是开源的，他们在用 CoreOS、Fedora、Ceph 等，还有 NASA，也使用了大量的开源软件，其实他们是最早发明了 OpenStack，之后在社区得以进一步开发。行业的未来是开源，很多公司为什么用开源，因为他们知道只有用了开源才能保持自己的敏捷性，而且他们也知道自己是没有办法预测未来的，但是如果他们不与时俱进，那么这个公司可能将来就死路一条。

Adam Samalik：假如你是一个喜欢编代码的人，或者公司让程序员编写代码，如果你在社区里发布过你的代码，并且让其他人为这个代码做出贡献，你立刻会意识到开源的重要性或者价值。拿 Kubernetes 举个例子，它最早是谷歌拿出来的，一开始非常简单，但是大家都看到它的前景，现在有好多公司在为 Kubernetes 做出贡献，Kubernetes 本身也变的更为庞大，而且是非常棒的，但是在开源社区会发生这些事情，你把代码拿出来不是损失了自己的代码，有更多人会对你帮助，会有更多的贡献。

Carol Chen：谈到关系，在去年我们与阿里巴巴建立了伙伴关系，我希望并且认为肯定有更多的中国本地的伙伴关系发展起来。其实看一看 LC3 大会就知道了，有那么多大大小小的本地公司他们都在做开源，而且非常愿意分享自己用开源的经验，所以我想在这方面我们可以真实的看到这个趋势。关于个人的动机，我非常喜欢技术，我喜欢和别人分享东西，我也喜欢给别人参与这些非常酷的项目的机会，我也希望生活能够过的好，而参与开源给了我这一切。

某男：我补充一句关于创新和开源的关系，我们的 CEO 发布了一本新书《开放式创新》，现在我们看到在当今世界上人们面临的问题越来越复杂，对于这些复杂的问题一个公司单独没有办法解决，我们需要很多公司很多人合作，所以开源的平台会是非常重要的，这么多人和企业都可以一起寻找解决方案，所以开源在将来肯定会非常重要的推动创新。

Brian Exelbierd：我要讲的故事跟他们都不一样，我不知道一开始加入开源社区的动机是不是像我的同事那么纯净。 我就记得当时在大学里的朋友来找我，他当时拿着最初的 Linux 的某个版本，我们当时用软盘的复制工具复制了 64 个软盘，当时是希望能用这个东西让我非常糟糕的电脑转的更快一点。

当时我这个同学就说，欧洲有这么一个人在干这个事情，你知道我们都是美国人，住在美国也不太关心，不知道他在欧洲哪儿，但是现在我住在欧洲，知道那些地方在哪儿。当时有一个特别自私的想法，就是想让我的电脑快一点，我也做出了我的第一个贡献，因为我想让这个程序运行得有点差别，想改一下。所以最初这个动机帮助我逐步进入开源社区，当时我还是一个大学生，所以写的代码不太好，当时有代码的审阅人员，他们会看代码给你各种建议帮助你改进，这样逐步的参与动机，自私程度降低了，而更多的希望我能够也做出点贡献，也给其他人提供一些帮助。我们最早的时候有 GRP 系统，厂商根本不问我们用的怎么样，但是在开源社区情况完全不一样，我们跟企业用户沟通，他们会直接说出这个软件存在什么问题，并且他会告诉你我们应该怎么改进。

Max Leonard Inden：我为什么我参加了开源社区，我的同事们讲的非常好，从我的角度来讲是开源让我能够到这儿，让我在大会上发言，并且公开谈论我自己感兴趣的东西，而且能听别人谈。

听了大家的提问和回答，本人有如下感受：

• 开源在中国需要更多的非程序员的贡献者，来在艺术、营销、文档三个方面做出更多的贡献。
• 文化始终是大于代码的（Culture is bigger than code）。
• 开源本身是跨越了国界、地域、文化，让我们把资源更高效的利用起来让人们的生活更美好（OpenSource making people's life better）。

用 Click、Docopt 和 Fire 库写你自己的命令行应用。

有时对于某项工作来说一个命令行工具就足以胜任。命令行工具是一种从你的 shell 或者终端之类的地方交互或运行的程序。Git 和 Curl 就是两个你也许已经很熟悉的命令行工具。

当你有一小段代码需要在一行中执行多次或者经常性地被执行，命令行工具就会很有用。Django 开发者执行 ./manage.py runserver 命令来启动他们的网络服务器；Docker 开发者执行 docker-compose up 来启动他们的容器。你想要写一个命令行工具的原因可能和你一开始想写代码的原因有很大不同。

对于这个月的 Python 专栏，我们有 3 个库想介绍给希望为自己编写命令行工具的 Python 使用者。

Click

Click 是我们最爱的用来开发命令行工具的 Python 包。其：

• 有一个富含例子的出色文档
• 包含说明如何将命令行工具打包成一个更加易于执行的 Python 应用程序
• 自动生成实用的帮助文本
• 使你能够叠加使用可选和必要参数，甚至是 多个命令
• 有一个 Django 版本（ django-click ）用来编写管理命令

Click 使用 @click.command() 去声明一个函数作为命令，同时可以指定必要和可选参数。

# hello.py
import click 

@click.command()
@click.option('--name', default='', help='Your name')
def say_hello(name):
    click.echo("Hello {}!".format(name))

if __name__ == '__main__':
    say_hello()

@click.option() 修饰器声明了一个 可选参数 ，而 @click.argument() 修饰器声明了一个 必要参数。你可以通过叠加修饰器来组合可选和必要参数。echo() 方法将结果打印到控制台。

$ python hello.py --name='Lacey'
Hello Lacey!

Docopt

Docopt 是一个命令行工具的解析器，类似于命令行工具的 Markdown。如果你喜欢流畅地编写应用文档，在本文推荐的库中 Docopt 有着最好的格式化帮助文本。它不是我们最爱的命令行工具开发包的原因是它的文档犹如把人扔进深渊，使你开始使用时会有一些小困难。然而，它仍是一个轻量级的、广受欢迎的库，特别是当一个漂亮的说明文档对你来说很重要的时候。

Docopt 对于如何格式化文章开头的 docstring 是很特别的。在工具名称后面的 docsring 中，顶部元素必须是 Usage: 并且需要列出你希望命令被调用的方式（比如：自身调用，使用参数等等）。Usage: 需要包含 help 和 version 参数。

docstring 中的第二个元素是 Options:，对于在 Usages: 中提及的可选项和参数，它应当提供更多的信息。你的 docstring 的内容变成了你帮助文本的内容。

"""HELLO CLI

Usage:
    hello.py
    hello.py <name>
    hello.py -h|--help
    hello.py -v|--version

Options:
    <name>  Optional name argument.
    -h --help  Show this screen.
    -v --version  Show version.
"""

from docopt import docopt

def say_hello(name):
    return("Hello {}!".format(name))


if __name__ == '__main__':
    arguments = docopt(__doc__, version='DEMO 1.0')
    if arguments['<name>']:
        print(say_hello(arguments['<name>']))
    else:
        print(arguments)

在最基本的层面，Docopt 被设计用来返回你的参数键值对。如果我不指定上述的 name 调用上面的命令，我会得到一个字典的返回值：

$ python hello.py
{'--help': False,
 '--version': False,
 '<name>': None}

这里可看到我没有输入 help 和 version 标记并且 name 参数是 None。

但是如果我带着一个 name 参数调用，say_hello 函数就会执行了。

$ python hello.py Jeff
Hello Jeff!

Docopt 允许同时指定必要和可选参数，且各自有着不同的语法约定。必要参数需要在 ALLCAPS 和 <carets> 中展示，而可选参数需要单双横杠显示，就像 --like。更多内容可以阅读 Docopt 有关 patterns 的文档。

Fire

Fire 是谷歌的一个命令行工具开发库。尤其令人喜欢的是当你的命令需要更多复杂参数或者处理 Python 对象时，它会聪明地尝试解析你的参数类型。

Fire 的 文档 包括了海量的样例，但是我希望这些文档能被更好地组织。Fire 能够处理 同一个文件中的多条命令、使用 对象 的方法作为命令和 分组 命令。

它的弱点在于输出到控制台的文档。命令行中的 docstring 不会出现在帮助文本中，并且帮助文本也不一定标识出参数。

import fire


def say_hello(name=''):
    return 'Hello {}!'.format(name)


if __name__ == '__main__':
    fire.Fire()

参数是必要还是可选取决于你是否在函数或者方法定义中为其指定了一个默认值。要调用命令，你必须指定文件名和函数名，比较类似 Click 的语法：

$ python hello.py say_hello Rikki
Hello Rikki!

你还可以像标记一样传参，比如 --name=Rikki。

额外赠送：打包！

Click 包含了使用 setuptools 打包 命令行工具的使用说明（强烈推荐按照说明操作）。

要打包我们第一个例子中的命令行工具，将以下内容加到你的 setup.py 文件里：

from setuptools import setup

setup(
    name='hello',
    version='0.1',
    py_modules=['hello'],
    install_requires=[
        'Click',
    ],
    entry_points='''
        [console_scripts]
        hello=hello:say_hello
    ''',
)

任何你看见 hello 的地方，使用你自己的模块名称替换掉，但是要记得忽略 .py 后缀名。将 say_hello 替换成你的函数名称。

然后，执行 pip install --editable 来使你的命令在命令行中可用。

现在你可以调用你的命令，就像这样：

$ hello --name='Jeff'
Hello Jeff!

通过打包你的命令，你可以省掉在控制台键入 python hello.py --name='Jeff' 这种额外的步骤以减少键盘敲击。这些指令也很可能可在我们提到的其他库中使用。

via: https://opensource.com/article/18/5/3-python-command-line-tools

作者：Jeff Triplett，Lacey Williams Hensche 选题：lujun9972 译者：hoppipolla- 校对：wxy

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

足球始终在我们身边。即使我们国家的队伍已经出局（LCTT 译注：显然这不是指我们国家，因为我们根本没有入局……），我还是想知道球赛比分。目前， 国际足联世界杯是世界上最大的足球锦标赛，2018 届是由俄罗斯主办的。每届世界杯都有一些足球强国未能取得参赛资格（LCTT 译注：我要吐槽么？）。意大利和荷兰就无缘本次世界杯。但是即使在未参加比赛的国家，追踪关注最新比分也成为了一种仪式。我希望能及时了解这个世界级的重大赛事最新比分的变化，而不用去搜索不同的网站。

如果你很喜欢命令行，那么有更好的方法用一个小型命令行程序追踪最新的世界杯比分和排名。让我们看一看最热门的可用的球赛趋势分析程序之一，它叫作 football-cli。

football-cli 不是一个开创性的应用程序。这几年，有许多命令行工具可以让你了解到最新的球赛比分和赛事排名。例如，我是 soccer-cli （Python 写的）和 App-football （Perl 写的）的重度用户。但我总是在寻找新的趋势分析应用，而 football-cli 在某些方面脱颖而出。

football-cli 是 JavaScript 开发的，由 Manraj Singh 编写，它是开源的软件。基于 MIT 许可证发布，用 npm（JavaScript 包管理器）安装十分简单。那么，让我们直接行动吧！

该应用程序提供了命令以获取过去及现在的赛事得分、查看联赛和球队之前和将要进行的赛事。它也会显示某一特定联赛的排名。有一条指令可以列出程序所支持的不同赛事。我们不妨从最后一个条指令开始。

在 shell 提示符下：

luke@ganges:~$ football lists

世界杯被列在最下方，我错过了昨天的比赛，所以为了了解比分，我在 shell 提示下输入：

luke@ganges:~$ football scores

现在，我想看看目前的世界杯小组排名。很简单：

luke@ganges:~$ football standings -l WC

下面是输出的一个片段：

你们当中眼尖的可能会注意到这里有一个错误。比如比利时看上去领先于 G 组，但这是不正确的，比利时和英格兰（截稿前）在得分上打平。在这种情况下，纪律好的队伍排名更高。英格兰收到两张黄牌，而比利时收到三张，因此，英格兰应当名列榜首。

假设我想知道利物浦 90 天前英超联赛的结果，那么:

luke@ganges:~$ football fixtures -l PL -d 90 -t "Liverpool"

我发现这个程序非常方便。它用一种清晰、整洁而有吸引力的方式显示分数和排名。当欧洲联赛再次开始时，它就更有用了。（事实上 2018-19 冠军联赛已经在进行中）！

这几个示例让大家对 football-cli 的实用性有了更深的体会。想要了解更多，请转至开发者的 GitHub 页面。足球 ＋ 命令行 ＝ football-cli。

如同许多类似的工具一样，该软件从 football-data.org 获取相关数据。这项服务以机器可读的方式为所有欧洲主要联赛提供数据，包括比赛、球队、球员、结果等等。所有这些信息都是以 JOSN 形式通过一个易于使用的 RESTful API 提供的。

via: https://www.linuxlinks.com/football-cli-world-cup-football-on-the-command-line/

作者：Luke Baker 选题：lujun9972 译者：ZenMoore 校对：wxy

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

两个开发团队的一天

几个月以前，我与一些人讨论过关于公共云服务成本与传统专用基础设施价格比较的话题。为给你提供一些见解，我们来跟踪一下一个企业中的两个开发团队  —  并比较他们构建类似服务的方式。

第一个团队将使用传统的专用基础设施来部署他们的应用，而第二个团队将使用 AWS 提供的公共云服务。

这两个团队被要求为一家全球化企业开发一个新的服务，该企业目前为全球数百万消费者提供服务。要开发的这项新服务需要满足以下基本需求：

1. 能够随时扩展以满足弹性需求
2. 具备应对数据中心故障的弹性
3. 确保数据安全以及数据受到保护
4. 为排错提供深入的调试功能
5. 项目必须能迅速分发
6. 服务构建和维护的性价比要高

就新服务来说，这看起来是非常标准的需求 — 从本质上看传统专用基础设备上没有什么东西可以超越公共云了。

1 — 扩展以满足客户需求

当说到可扩展性时，这个新服务需要去满足客户变化无常的需求。我们构建的服务不可以拒绝任何请求，以防让公司遭受损失或者声誉受到影响。

传统团队

使用的是专用基础设施，架构体系的计算能力需要与峰值数据需求相匹配。对于负载变化无常的服务来说，大量昂贵的计算能力在低利用率时被浪费掉。

这是一种很浪费的方法  —  并且大量的资本支出会侵蚀掉你的利润。另外，这些未充分利用的庞大的服务器资源的维护也是一项很大的运营成本。这是一项你无法忽略的成本  —  我不得不再强调一下，为支持一个单一服务去维护一机柜的服务器是多么的浪费时间和金钱。

云团队

使用的是基于云的自动伸缩解决方案，应用会按需要进行自动扩展和收缩。也就是说你只需要支付你所消费的计算资源的费用。

一个架构良好的基于云的应用可以实现无缝地伸缩 —  并且还是自动进行的。开发团队只需要定义好自动伸缩的资源组即可，即当你的应用 CPU 利用率达到某个高位、或者每秒有多大请求数时启动多少实例，并且你可以根据你的意愿去定制这些规则。

2 — 应对故障的弹性

当说到弹性时，将托管服务的基础设施放在同一个房间里并不是一个好的选择。如果你的应用托管在一个单一的数据中心  —  （不是如果）发生某些失败时（LCTT 译注：指坍塌、地震、洪灾等），你的所有的东西都被埋了。

传统团队

满足这种基本需求的标准解决方案是，为实现局部弹性建立至少两个服务器  —  在地理上冗余的数据中心之间实施秒级复制。

开发团队需要一个负载均衡解决方案，以便于在发生饱和或者故障等事件时将流量转向到另一个节点  —  并且还要确保镜像节点之间，整个栈是持续完全同步的。

云团队

在 AWS 全球 50 个地区中，他们都提供多个可用区。每个区域由多个容错数据中心组成  —  通过自动故障切换功能，AWS 可以将服务无缝地转移到该地区的其它区中。

在一个 CloudFormation 模板中定义你的基础设施即代码，确保你的基础设施在自动伸缩事件中跨区保持一致 — 而对于流量的流向管理，AWS 负载均衡服务仅需要做很少的配置即可。

3 — 安全和数据保护

安全是一个组织中任何一个系统的基本要求。我想你肯定不想成为那些不幸遭遇安全问题的公司之一的。

传统团队

为保证运行他们服务的基础服务器安全，他们不得不持续投入成本。这意味着将需要投资一个团队，以监视和识别安全威胁，并用来自不同数据源的跨多个供应商解决方案打上补丁。

云团队

使用公共云并不能免除来自安全方面的责任。云团队仍然需要提高警惕，但是并不需要去担心为底层基础设施打补丁的问题。AWS 将积极地对付各种零日漏洞 — 最近的一次是 Spectre 和 Meltdown。

利用来自 AWS 的身份管理和加密安全服务，可以让云团队专注于他们的应用 —  而不是无差别的安全管理。使用 CloudTrail 对 API 到 AWS 服务的调用做全面审计，可以实现透明地监视。

4 — 监视和日志

任何基础设施和部署为服务的应用都需要严密监视实时数据。团队应该有一个可以访问的仪表板，当超过指标阈值时仪表板会显示警报，并能够在排错时提供与事件相关的日志。

传统团队

对于传统基础设施，将不得不在跨不同供应商和“雪花状”的解决方案上配置监视和报告解决方案。配置这些“见鬼的”解决方案将花费你大量的时间和精力 —  并且能够正确地实现你的目的是相当困难的。

对于大多数部署在专用基础设施上的应用来说，为了搞清楚你的应用为什么崩溃，你可以通过搜索保存在你的服务器文件系统上的日志文件来找到答案。为此你的团队需要通过 SSH 进入服务器，导航到日志文件所在的目录，然后浪费大量的时间，通过 grep 在成百上千的日志文件中寻找。如果你在一个横跨 60 台服务器上部署的应用中这么做  —  我能负责任地告诉你，这是一个极差的解决方案。

云团队

利用原生的 AWS 服务，如 CloudWatch 和 CloudTrail，来做云应用程序的监视是非常容易。不需要很多的配置，开发团队就可以监视部署的服务上的各种指标  —  问题的排除过程也不再是个恶梦了。

对于传统的基础设施，团队需要构建自己的解决方案，配置他们的 REST API 或者服务去推送日志到一个聚合器。而得到这个“开箱即用”的解决方案将对生产力有极大的提升。

5 — 加速开发进程

现在的商业环境中，快速上市的能力越来越重要。由于实施的延误所失去的机会成本，可能成为影响最终利润的一个主要因素。

传统团队

对于大多数组织，他们需要在新项目所需要的硬件采购、配置和部署上花费很长的时间 — 并且由于预测能力差，提前获得的额外的性能将造成大量的浪费。

而且还有可能的是，传统的开发团队在无数的“筒仓”中穿梭以及在移交创建的服务上花费数月的时间。项目的每一步都会在数据库、系统、安全、以及网络管理方面需要一个独立工作。

云团队

而云团队开发新特性时，拥有大量的随时可投入生产系统的服务套件供你使用。这是开发者的天堂。每个 AWS 服务一般都有非常好的文档并且可以通过你选择的语言以编程的方式去访问。

使用新的云架构，例如无服务器，开发团队可以在最小化冲突的前提下构建和部署一个可扩展的解决方案。比如，只需要几天时间就可以建立一个 Imgur 的无服务器克隆，它具有图像识别的特性，内置一个产品级的监视/日志解决方案，并且它的弹性极好。

如何建立一个 Imgur 的无服务器克隆

如果必须要我亲自去设计弹性和可伸缩性，我可以向你保证，我会陷在这个项目的开发里 — 而且最终的产品将远不如目前的这个好。

从我实践的情况来看，使用无服务器架构的交付时间远小于在大多数公司中提供硬件所花费的时间。我只是简单地将一系列 AWS 服务与 Lambda 功能 — 以及 ta-da 耦合到一起而已！我只专注于开发解决方案，而无差别的可伸缩性和弹性是由 AWS 为我处理的。

关于云计算成本的结论

就弹性而言，云计算团队的按需扩展是当之无愧的赢家 — 因为他们仅为需要的计算能力埋单。而不需要为维护和底层的物理基础设施打补丁付出相应的资源。

云计算也为开发团队提供一个可使用多个可用区的弹性架构、为每个服务构建的安全特性、持续的日志和监视工具、随用随付的服务、以及低成本的加速分发实践。

大多数情况下，云计算的成本要远低于为你的应用运行所需要的购买、支持、维护和设计的按需基础架构的成本 —  并且云计算的麻烦事更少。

通过利用云计算，我们可以更少的先期投入而使业务快速开展。整体而言，当你开发和部署业务服务时，云计算的经济性可以让你的工作更赞。

也有一些云计算比传统基础设施更昂贵的例子，一些情况是在周末忘记关闭运行的一些极其昂贵的测试机器。

Dropbox 在决定推出自己的基础设施并减少对 AWS 服务的依赖之后，在两年的时间内节省近 7500 万美元的费用，Dropbox…——www.geekwire.com

即便如此，这样的案例仍然是非常少见的。更不用说当初 Dropbox 也是从 AWS 上开始它的业务的  —  并且当它的业务达到一个临界点时，才决定离开这个平台。即便到现在，他们也已经进入到云计算的领域了，并且还在 AWS 和 GCP 上保留了 40% 的基础设施。

将云服务与基于单一“成本”指标（LCTT 译注：此处的“成本”仅指物理基础设施的购置成本）的传统基础设施比较的想法是极其幼稚的  —  公然无视云为开发团队和你的业务带来的一些主要的优势。

在极少数的情况下，云服务比传统基础设施产生更多的绝对成本  —  但它在开发团队的生产力、速度和创新方面仍然贡献着更好的价值。

客户才不在乎你的数据中心呢

我非常乐意倾听你在云中开发的真实成本相关的经验和反馈！请在下面的评论区、Twitter @Elliot\_F 上、或者直接在 LinkedIn 上联系我。

via: https://read.acloud.guru/the-true-cost-of-cloud-a-comparison-of-two-development-teams-edc77d3dc6dc

作者：Elliot Forbes 译者：qhwdw 校对：wxy

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

Whiskey Lake U 系列和 Amber Lake Y 系列的酷睿芯片将会在今年秋季开始出现在超过 70 款笔记本以及 2 合 1 机型中。

根据最近的台北国际电脑展 (Computex 2018) 以及最近其它的消息，处理器成为科技新闻圈中最前沿的话题。Intel 发布了一些公告涉及从新的酷睿处理器到延长电池续航的尖端技术。与此同时，AMD 亮相了第二代 32 核心的高端游戏处理器线程撕裂者（Threadripper）以及一些适合嵌入式的新型号锐龙 Ryzen 处理器。

以上是对 Intel 和 AMD 主要公布产品的快速浏览，针对那些对嵌入式 Linux 开发者最感兴趣的处理器。

Intel 最新的第八代 CPU 家族

在四月份，Intel 已经宣布量产 10nm 制程的 Cannon Lake 系列酷睿处理器将会延期到 2019 年，这件事引起了人们对摩尔定律最终走上正轨的议论。然而，在 Intel 的 Computex 展区 中有着众多让人欣慰的消息。Intel 展示了两款节能的第八代 14nm 酷睿家族产品，同时也是 Intel 首款 5GHz 的设计。

Whiskey Lake U 系列和 Amber Lake Y 系列的酷睿芯片将会在今年秋季开始出现在超过 70 款笔记本以及 2 合 1 机型中。Intel 表示，这些芯片相较于第七代的 Kaby Lake 酷睿系列处理器会带来两倍的性能提升。新的产品家族将会相比于目前出现的搭载 Coffee Lake 芯片的产品更加节能 。

Whiskey Lake 和 Amber Lake 两者将会配备 Intel 高性能千兆 WiFi (Intel 9560 AC)，该网卡同样出现在 Gemini Lake 架构的奔腾银牌和赛扬处理器，随之出现在 Apollo Lake 一代。千兆 WiFi 本质上就是 Intel 将 2×2 MU-MIMO 和 160MHz 信道技术与 802.11ac 结合。

Intel 的 Whiskey Lake 将作为第七代和第八代 Skylake U 系列处理器的继任者，它们现在已经流行于嵌入式设备。Intel 透漏了少量细节，但是 Whiskey Lake 想必将会提供同样的，相对较低的 15W TDP。这与 Coffee Lake U 系列芯片 也很像，它将会被用于四核以及 Kaby Lake 和 Skylake U 系列的双核芯片。

PC World 报导称，Amber Lake Y 系列芯片主要目标定位是 2 合 1 机型。就像双核的 Kaby Lake Y 系列 芯片，Amber Lake 将会支持 4.5W TDP。

为了庆祝 Intel 即将到来的 50 周年庆典， 同样也是作为世界上第一款 8086 处理器的 40 周年庆典，Intel 将启动一个限量版，带有一个时钟频率 4GHz 的第八代 酷睿 i7-8086K CPU。 这款 64 位限量版产品将会是第一块拥有 5GHz, 单核睿频加速，并且是首款带有集成显卡的 6 核，12 线程处理器。Intel 将会于 6 月 7 日开始 赠送 8086 块超频酷睿 i7-8086K 芯片。

Intel 也展示了计划于今年年底启动新的高端 Core X 系列拥有高核心和线程数。AnandTech 预测 可能会使用类似于 Xeon 的 Cascade Lake 架构。今年晚些时候，Intel 将会公布新的酷睿 S系列型号，AnandTech 预测它可能会是八核心的 Coffee Lake 芯片。

Intel 也表示第一款疾速傲腾 SSD —— 一个 M.2 接口产品被称作 905P —— 终于可用了。今年来迟的是 Intel XMM 800 系列调制解调器，它支持 Sprint 的 5G 蜂窝技术。Intel 表示 可用于 PC 的 5G 将会在 2019 年出现。

Intel 承诺笔记本全天候的电池寿命

另一则消息，Intel 表示将会尽快启动一项 Intel 低功耗显示技术，它将会为笔记本设备提供一整天的电池续航。合作开发伙伴 Sharp 和 Innolux 正在使用这项技术在 2018 年晚期开始生产 1W 显示面板，这能节省 LCD 一半的电量消耗。

AMD 继续翻身

在展会中，AMD 亮相了第二代拥有 32 核 64 线程的线程撕裂者（Threadripper） CPU。为了走在 Intel 尚未命名的 28 核怪兽之前，这款高端游戏处理器将会在第三季度推出。根据 Engadget 的消息，新的线程撕裂者同样采用了被用在锐龙 Ryzen 芯片的 12nm Zen+ 架构。

WCCFTech 报导，AMD 也表示它选自 7nm Vega Instinct GPU（为拥有 32GB 昂贵的 HBM2 显存而不是 GDDR5X 或 GDDR6 的显卡而设计）。这款 Vega Instinct 将提供相比现今 14nm Vega GPU 高出 35% 的性能和两倍的功效效率。新的渲染能力将会帮助它同 Nvidia 启用 CUDA 技术的 GPU 在光线追踪中竞争。

一些新的 Ryzen 2000 系列处理器近期出现在一个 ASRock CPU 聊天室，它将拥有比主流的 Ryzen 芯片更低的功耗。AnandTech 详细介绍了，2.8GHz，8 核心，16 线程的 Ryzen 7 2700E 和 3.4GHz/3.9GHz，六核，12 线程 Ryzen 5 2600E 都将拥有 45W TDP。这比 12-54W TDP 的 Ryzen Embedded V1000 处理器更高，但低于 65W 甚至更高的主流 Ryzen 芯片。新的 Ryzen-E 型号是针对 SFF (外形小巧，small form factor) 和无风扇系统。

在 开源峰会 + 欧洲嵌入式 Linux 会议 加入我们，关于 Linux，云，容器，AI，社区等 100 多场会议，爱丁堡，英国，2018 年 10 月 22-24 日。

via: https://www.linux.com/blog/2018/6/intel-amd-and-arm-reveal-new-processor-designs

作者：Eric Brown 选题：lujun9972 译者：softpaopao 校对：wxy

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

如果有什么我讨厌的东西，那就是当我知道我可以自动化它们时，但我手动进行了操作。只有我有这种情况么？我觉得不是。

尽管如此，他们每天都有数千名使用 GitHub 的开发人员一遍又一遍地做同样的事情：他们点击这个按钮：

这没有任何意义。

不要误解我的意思。合并拉取请求是有意义的。只是每次点击这个该死的按钮是没有意义的。

这样做没有意义因为世界上的每个开发团队在合并拉取请求之前都有一个已知的先决条件列表。这些要求几乎总是相同的，而且这些要求也是如此：

• 是否通过测试？
• 文档是否更新了？
• 这是否遵循我们的代码风格指南？
• 是否有若干位开发人员对此进行审查？

随着此列表变长，合并过程变得更容易出错。 “糟糕，在没有足够的开发人员审查补丁时 John 就点了合并按钮。” 要发出警报么？

在我的团队中，我们就像外面的每一支队伍。我们知道我们将一些代码合并到我们仓库的标准是什么。这就是为什么我们建立一个持续集成系统，每次有人创建一个拉取请求时运行我们的测试。我们还要求代码在获得批准之前由团队的 2 名成员进行审查。

当这些条件全部设定好时，我希望代码被合并。

而不用点击一个按钮。

这正是启动 Mergify 的原因。

Mergify 是一个为你按下合并按钮的服务。你可以在仓库的 .mergify.yml 中定义规则，当规则满足时，Mergify 将合并该请求。

无需按任何按钮。

随机抽取一个请求，就像这样：

这来自一个小型项目，没有很多持续集成服务，只有 Travis。在这个拉取请求中，一切都是绿色的：其中一个所有者审查了代码，并且测试通过。因此，该代码应该被合并：但是它还在那里挂起这，等待某人有一天按下合并按钮。

使用 Mergify 后，你只需将 .mergify.yml 放在仓库的根目录即可：

rules:
  default:
    protection:
      required_status_checks:
        contexts:
          - continuous-integration/travis-ci
      required_pull_request_reviews:
        required_approving_review_count: 1

通过这样的配置，Mergify 可以实现所需的限制，即 Travis 通过，并且至少有一个项目成员审阅了代码。只要这些条件是肯定的，拉取请求就会自动合并。

我们将 Mergify 构建为 一个对开源项目免费的服务。提供服务的引擎也是开源的。

现在去尝试它，不要让这些拉取请求再挂起哪怕一秒钟。合并它们！

如果你有任何问题，请随时在下面向我们提问或写下评论！并且敬请期待 - 因为 Mergify 还提供了其他一些我迫不及待想要介绍的功能！

via: https://julien.danjou.info/stop-merging-your-pull-request-manually/

作者：Julien Danjou 选题：lujun9972 译者：geekpi 校对：wxy

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