diff --git a/published/20170202 Why we need open leaders more than ever.md b/published/20170202 Why we need open leaders more than ever.md
new file mode 100644
index 0000000000..7a917f6f1c
--- /dev/null
+++ b/published/20170202 Why we need open leaders more than ever.md
@@ -0,0 +1,73 @@
+为什么我们比以往更需要开放的领导人
+============================================================
+
+> 不断变化的社会和文化条件正促使着开放的领导。
+
+
+
+
+领导力就是力量。更具体地说，领导力是影响他人行动的力量。 关于领导力的神话不仅可以让人联想到人类浪漫的一面而且还有人类境况险恶的一面。 我们最终决定如何领导才能决定其真正的本质。
+
+现代许多对领导力的理解都是在战争中诞生的，在那里，领导力意味着熟练地执行命令和控制思想。 在现代商业的大部分时间里，我们都是以一个到达权力顶峰的伟大的男人或女人作为领导，并通过地位来发挥力量的。 这种传统的通过等级和报告关系的领导方式严重依赖于正式的权威。 这些结构中的权威通过垂直层次结构向下流动，并沿命令链的形式存在。
+
+然而，在 20 世纪后期，一些东西开始改变。 新技术打开了全球化的大门，从而使团队更加分散。 我们投入人力资本的方式开始转变，永远地改变了人们之间的沟通方式。组织内部的人开始感觉得到了责任感，他们要求对自己的成功(和失败)拥有归属感。 领导者不再是权力的唯一拥有者。 21世纪的领导者带领 21 世纪的组织开始了解授权、协作、责任和清晰的沟通是一种新型权力的本质。 这些新领导人开始分享权力——他们无保留地信任他们的追随者。
+
+随着组织继续变得更加开放，即使是没有“领导力”头衔的人也会感到有责任推动变革。 这些组织消除了等级制度的枷锁，让工人们以他们认为合适的方式去工作。 历史暴露了 20 世纪领导人倾向通过单边决策和单向信息流来扼杀敏捷性。 但是，新世纪的领导者却是确定一个组织，让由它授权的若干个体来完成一些事情。 重点是权力赋予若干个体——坦率地说，一个领导者不能在任何时候出现在所有的地方，做出所有的决定。
+
+因此，领导人也开始变得开放。
+
+### 控制
+
+当旧式领导人专注于指挥和控制的地位权力时，一个开放的领导者通过新形式的组织管理方式、新技术和其他减少摩擦的方式，将组织控制权放在了其它人身上，这样可以更有效的方式实现集体行动的方式。 这些领导者了解信任的力量，相信追随者总是会表现出主动性、参与性和独立性。 而这种新的领导方式需要在战术上有所转变——从告诉人们如何去做，到向他们展示如何去做，并在路上指导他们。开放的领导人很快就发现，领导力不是影响我们发挥进步的力量，而是我们在组织成员中分配的力量和信心。 21 世纪的领导者专注于社区和对他人的教化。最后，开放的领导者并不是专注于自我，而是无私的。
+
+### 交流
+
+20 世纪的领导者人组织并控制整个组织的信息的流动。 然而，开放的领导者试图通过与团队成员共享信息和背景（以及权力）来组织一个组织。 这些领导人摧毁了领地，谦逊前行，分享着前所未有的力量。 集体赋权和参与的协作创造了灵活性，分担责任，所有权，尤其是幸福。 当一个组织的成员被授权做他们的工作时，他们比等级层次的同事更快乐（因而更有生产力）。
+
+### 信任
+
+开放的领导者接受不确定性，相信他们的追随者在正确的时间做正确的事情。 他们拥有比传统对手，有更高的吸引人力资本效率的能力。 再说一次：他们不会像命令和控制的微观管理者那样运作。 提高透明度，而不是暗箱操作，他们尽可能的把决策和行动放在公开场合，解释决策的基础，并假设员工对组织内的情况有高度的把握。开放领导者的操作的前提是，如果没有他们的持续干预，该组织的人力资本就更有能力取得成功。
+
+### 自治权
+
+在 20 世纪具有强大指挥和控制力的领导者专注于某些权力的时候，一个开放的领导者更多地关注组织内个人的实际活动。 当领导者专注于个人时，他们就能够更好地训练和指导团队成员。 从这个角度来看，一个开放的领导者关注的是与组织的愿景和使命一致的行为和行动。最后，一个开放的领导者被看作是团队中的一员，而不是团队的领导者。 这并不意味着领导人放弃了权力的地位，而是低估了这一点，以分享权力，并通过自主创造成果赋予个人权力。
+
+### 赋权
+
+开放的领导人把重点放在授予组织成员的权力上。 在这个过程中承认领导者在组织人力资本中的技能、能力和信任，从而为整个团队带来了积极的动力和意愿。 最终，赋权就是帮助追随者相信他们自己的能力。 那些相信自己拥有个人权力的追随者更有可能采取主动行动、制定和实现更高的目标，并在困难的环境下坚持下去。 最终，开放组织的概念是关于包容性，每个人都是属于自己的，个性和不同的观点对于成功是至关重要的。 一个开放的组织及其开放的领导者提供了一种社区的感觉，而成员则受到组织的使命或目的的驱动。 这会产生一种比个人更大的归属感。 个性创造了成员之间的幸福和工作满意度。 反过来，又实现了更高的效率和成功。
+
+我们都应该为 21 世纪领导人所要求的开放性而努力。 这需要自我反省，好奇心，尤其是它正在进行的改变。 通过新的态度和习惯，我们逐渐发现了一个真正的开放领导者，并且希望我们在适应 21 世纪的领导风格的同时，也开始采纳这些理念。
+
+是的，领导力就是力量。我们如何利用这种权力决定了我们组织的成败。 那些滥用权力的人不会持久，但那些分享权力和庆祝他人的人会更持久。 通过阅读 [这本书][7]，你可以在开放组织及其领导的持续对话中开始发挥重要作用。 在[本卷][8]的结论中，您将找到与开放组织社区联系的额外资源和机会，以便您也可以与我们聊天、思考和成长。 欢迎来到谈话——欢光临！
+
+_这篇文章最初是作为《开放组织领导手册》的引言出现的，它现在可以[从 Opensource.com 中可获得][5]。_
+
+（ Image by : opensource.com）
+
+--------------------------------------------------------------------------------
+
+作者简介：
+
+Philip A Foster - Dr. Philip A. Foster 是一名领导/商业教练兼顾问兼兼职教授。 他是企业运营、组织发展、展望和战略领导层的著名思想领袖。 Dr. Foster 通过设计和实施战略、战略预见和规划来促进变革。
+
+--------------------------------------------------------------------------------
+
+via: https://opensource.com/open-organization/17/2/need-open-leaders-more-ever
+
+作者：[Philip A Foster][a]
+译者：[TimeBear](https://github.com/TimeBear)
+校对：[wxy](https://github.com/wxy)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
+
+[a]:https://opensource.com/users/maximumchange
+[1]:https://opensource.com/open-organization/resources/leaders-manual?src=too_resource_menu
+[2]:https://opensource.com/open-organization/resources/field-guide?src=too_resource_menu
+[3]:https://opensource.com/open-organization/resources/open-org-definition?src=too_resource_menu
+[4]:https://opensource.com/open-organization/resources/open-decision-framework?src=too_resource_menu
+[5]:https://opensource.com/open-organization/resources/leaders-manual
+[6]:https://opensource.com/open-organization/17/2/need-open-leaders-more-ever?rate=c_9hT0EKbdXcTGRl-YW0QgW60NsRwO2a4RaplUKfvXs
+[7]:https://opensource.com/open-organization/resources/leaders-manual
+[8]:https://opensource.com/open-organization/resources/leaders-manual
+[9]:https://opensource.com/user/15497/feed
+[10]:https://opensource.com/users/maximumchange
diff --git a/published/20170211 Docker swarm mode - Adding worker nodes tutorial.md b/published/20170211 Docker swarm mode - Adding worker nodes tutorial.md
new file mode 100644
index 0000000000..e8a8db4729
--- /dev/null
+++ b/published/20170211 Docker swarm mode - Adding worker nodes tutorial.md
@@ -0,0 +1,151 @@
+Docker 引擎的 Swarm 模式：添加工作者节点教程
+================
+
+让我们继续几周前在 CentOS 7.2 中开始的工作。 在本[指南][1]中，我们学习了如何初始化以及启动 Docker 1.12 中内置的原生的集群以及编排功能。但是我们只有管理者（manager）节点还没有其它工作者（worker）节点。今天我们会展开讲述这个。
+
+我将向你展示如何将不对称节点添加到 Sawrm 中，比如一个与 CentOS 相邻的 [Fedora 24][2]，它们都将加入到集群中，还有相关很棒的负载均衡等等。当然这并不是轻而易举的，我们会遇到一些障碍，所以它应该是非常有趣的。
+
+
+
+### 先决条件
+
+在将其它节点成功加入 Swarm 之前，我们需要做几件事情。理想情况下，所有节点都应该运行相同版本的 Docker，为了支持原生的编排功能，它的版本至少应该为 1.12。像 CentOS 一样，Fedora 内置的仓库没有最新的构建版本，所以你需要手动构建，或者使用 Docker 仓库手动[添加和安装][3]正确的版本，并修复一些依赖冲突。我已经向你展示了如何在 CentOS 中操作，经过是相同的。
+
+此外，所有节点都需要能够相互通信。这就需要有正确的路由和防火墙规则，这样管理者（manager）和工作者（worker）节点才能互相通信。否则，你无法将节点加入 Swarm 中。最简单的解决方法是临时清除防火墙规则 （`iptables -F`），但这可能会损害你的安全。请确保你完全了解你正在做什么，并为你的节点和端口创建正确的规则。
+
+> Error response from daemon: Timeout was reached before node was joined. The attempt to join the swarm will continue in the background. Use the "docker info" command to see the current swarm status of your node.
+
+> 守护进程的错误响应：节点加入之前已超时。尝试加入 Swarm 的请求将在后台继续进行。使用 “docker info” 命令查看节点的当前 Swarm 状态。
+
+你需要在主机上提供相同的 Docker 镜像。在上一个教程中我们创建了一个 Apache 映像，你需要在你的工作者（worker）节点上执行相同操作，或者分发已创建的镜像。如果你不这样做，你会遇到错误。如果你在设置 Docker 上需要帮助，请阅读我的[介绍指南][4]和[网络教程][5]。
+
+```
+7vwdxioopmmfp3amlm0ulimcu \_ websky.11 my-apache2:latest
+localhost.localdomain Shutdown Rejected 7 minutes ago
+"No such image: my-apache2:lat&"
+```
+
+### 现在开始
+
+现在我们有一台启动了 CentOS 机器，并成功地创建了容器。你可以使用主机端口连接到该服务，这一切都看起来很好。目前，你的 Swarm 只有管理者（manager）。
+
+
+
+### 加入工作者（worker）
+
+要添加新的节点，你需要使用 `join` 命令。但是你首先必须提供令牌、IP 地址和端口，以便工作者（woker）节点能正确地对 Swarm 管理器进行身份验证。接着（在 Fedora 上）执行：
+
+```
+[root@localhost ~]# docker swarm join-token worker
+To add a worker to this swarm, run the following command:
+
+docker swarm join \
+--token SWMTKN-1-0xvojvlza90nrbihu6gfu3qm34ari7lwnza ... \
+192.168.2.100:2377
+```
+
+如果你不修复防火墙和路由规则，你会得到超时错误。如果你已经加入了 Swarm，重复 `join` 命令会收到错误：
+
+```
+Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.
+```
+
+如果有疑问，你可以离开 Swarm，然后重试：
+
+```
+[root@localhost ~]# docker swarm leave
+Node left the swarm.
+
+docker swarm join --token
+SWMTKN-1-0xvojvlza90nrbihu6gfu3qnza4 ... 192.168.2.100:2377
+This node joined a swarm as a worker.
+```
+
+在工作者（worker）节点中，你可以使用 `docker info` 来检查状态：
+
+```
+Swarm: active
+NodeID: 2i27v3ce9qs2aq33nofaon20k
+Is Manager: false
+Node Address: 192.168.2.103
+
+Likewise, on the manager:
+
+Swarm: active
+NodeID: cneayene32jsb0t2inwfg5t5q
+Is Manager: true
+ClusterID: 8degfhtsi7xxucvi6dxvlx1n4
+Managers: 1
+Nodes: 3
+Orchestration:
+Task History Retention Limit: 5
+Raft:
+Snapshot Interval: 10000
+Heartbeat Tick: 1
+Election Tick: 3
+Dispatcher:
+Heartbeat Period: 5 seconds
+CA Configuration:
+Expiry Duration: 3 months
+Node Address: 192.168.2.100
+```
+
+### 创建或缩放服务
+
+现在，我们需要看下 Docker 是否以及如何在节点间分发容器。我的测试展示了一个在非常轻的负载下相当简单的平衡算法。试了一两次之后，即使在我尝试缩放并更新之后，Docker 也没有将运行的服务重新分配给新的 worker。同样，有一次，它在工作者（worker）节点上创建了一个新的服务。也许这是最好的选择。
+
+
+
+
+
+
+
+
+
+*在新的工作者（worker）节点上完整创建新的服务。*
+
+过了一段时间，两个容器之间的现有服务有一些重新分配，但这需要一些时间。新服务工作正常。这只是一个前期观察，所以我现在不能说更多。现在是开始探索和调整的新起点。
+
+
+
+*负载均衡过了一会工作了。*
+
+### 总结
+
+Docker 是一只灵巧的小野兽，它仍在继续长大，变得更复杂、更强大，当然也更优雅。它被一个大企业吃掉只是一个时间问题。当它带来了原生的编排功能时，Swarm 模式运行得很好，但是它不只是几个容器而已，而是充分利用了其算法和可扩展性。
+
+我的教程展示了如何将 Fedora 节点添加到由 CentOS 运行的群集中，并且两者能并行工作。关于负载平衡还有一些问题，但这是我将在以后的文章中探讨的。总而言之，我希望这是一个值得记住的一课。我们已经解决了在尝试设置 Swarm 时可能遇到的一些先决条件和常见问题，同时我们启动了一堆容器，我们甚至简要介绍了如何缩放和分发服务。要记住，这只是一个开始。
+
+干杯。
+
+--------------------------------------------------------------------------------
+
+作者简介：
+
+我是 Igor Ljubuncic。现在大约 38 岁，已婚但还没有孩子。我现在在一个大胆创新的云科技公司做首席工程师。直到大约 2015 年初时，我还在一个全世界最大的 IT 公司之一中做系统架构工程师，和一个工程计算团队开发新的基于 Linux 的解决方案，优化内核以及攻克 Linux 的问题。在那之前，我是一个为高性能计算环境设计创新解决方案的团队的技术领导。还有一些其他花哨的头衔，包括系统专家、系统程序员等等。所有这些都曾是我的爱好，但从 2008 年开始成为了我的付费工作。还有什么比这更令人满意的呢？
+
+从 2004 年到 2008 年间，我曾通过作为医学影像行业的物理学家来糊口。我的工作专长集中在解决问题和算法开发。为此，我广泛地使用了 Matlab，主要用于信号和图像处理。另外，我得到了几个主要的工程方法学的认证，包括 MEDIC 六西格玛绿带、试验设计以及统计工程学。
+
+我也开始写书，包括奇幻类和 Linux 上的技术性工作。彼此交融。
+
+要查看我开源项目、出版物和专利的完整列表，请滚动到下面。
+
+有关我的奖项，提名和 IT 相关认证的完整列表，请稍等一下。
+
+-------------
+
+
+via: http://www.dedoimedo.com/computers/docker-swarm-adding-worker-nodes.html
+
+作者：[Igor Ljubuncic][a]
+译者：[geekpi](https://github.com/geekpi)
+校对：[wxy](https://github.com/wxy)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
+
+[a]:http://www.dedoimedo.com/faq.html
+[1]:https://linux.cn/article-8888-1.html
+[2]:http://www.dedoimedo.com/computers/fedora-24-gnome.html
+[3]:http://www.dedoimedo.com/computers/docker-centos-upgrade-latest.html
+[4]:http://www.dedoimedo.com/computers/docker-guide.html
+[5]:http://www.dedoimedo.com/computers/docker-networking.html
diff --git a/published/20170517 Security Debt is an Engineers Problem.md b/published/20170517 Security Debt is an Engineers Problem.md
new file mode 100644
index 0000000000..f12c8e0267
--- /dev/null
+++ b/published/20170517 Security Debt is an Engineers Problem.md
@@ -0,0 +1,106 @@
+安全债务是工程师的问题
+============================================================
+
+
+
+
+>Keziah Plattner of AirBnBSecurity.
+
+在上个月旧金山 Twitter 总部举办的 [WomenWhoCode Connect][5] 活动中参会者了解到，就像组织会形成技术债务一样，如果他们不相应地计划，也会形成一个名为“安全债务”的东西。
+
+甲骨文首席安全官 [Mary Ann Davidson][6] 与 [WomenWhoCode][8] 的 [Zassmin Montes de Oca][7] 在一个面对开发人员的安全性的主题谈话中强调，安全性已经成为软件开发过程中每步的重要组成部分，
+
+在过去，除银行外，安全性几乎被所有人忽视。但安全性比以往任何时候都更重要，因为现在有这么多接入点。我们已经进入[物联网][9]的时代，窃贼可以通过劫持你的冰箱而了解到你不在家的情况。
+
+Davidson 负责 Oracle 的保障，“我们确保为建立的一切构建安全性，无论是内部部署产品、云服务，甚至是设备，我们在客户的网站建立有支持小组并报告数据给我们，帮助我们做诊断 - 每件事情都必须对其进行安全保护。”
+
+
+
+*Plattner 与 #WWCConnect 人群交谈*
+
+AirBnB 的 [Keziah Plattner][10] 在分组会议中回应了这个看法。她说：“大多数开发者并不认为安全是他们的工作，但这必须改变。”
+
+她分享了工程师的四项基本安全原则。首先，安全债务是昂贵的。现在有很多人在谈论[技术债务][11]，她认为这些谈话应该也包括安全债务。
+
+Plattner 说：“历史上这个看法是‘我们会稍后考虑安全’”。当公司抓住软件效率和增长的唾手可得的成果时，他们忽视了安全性，但最初的不安全设计可能在未来几年会引发问题。
+
+她说，很难为现有的脆弱系统增加安全性。即使你知道安全漏洞在哪里，并且有进行更改的时间和资源的预算，重新设计一个安全系统也是耗时和困难的。
+
+她说，所以这就是关键，从一开始就建立安全性。将安全性视为技术债务的一部分以避免这个问题，并涵盖所有可能性。
+
+根据 Plattner 说的，最重要的是难以让人们改变行为。没有人会自愿改变，她说，即使你指出新的行为更安全。他们也只不过是点点头而已。
+
+Davidson 说，工程师们需要开始考虑他们的代码如何被攻击，并从这个角度进行设计。她说她只有两个规则。第一个从不信任任何未验证的数据；规则二参见规则一。
+
+她笑着说：“人们一直这样做。他们说：‘我的客户端给我发送数据，所以没有问题’。千万不要……”。
+
+Plattner说，安全的第二个关键是“永远不信任用户”。
+
+Davidson 以另外一种说法表示：“我的工作是做专业的偏执狂。”她一直担心有人或许无意中会破坏她的系统。这不是学术性的考虑，最近已经有通过 IoT 设备的拒绝服务攻击。
+
+### Little Bobby Tables
+
+Plattner 说：“如果你安全计划的一部分是信任用户做正确的事情，那么无论你有什么其他安全措施，你系统本质上是不安全的。”
+
+她解释说，重要的是要净化所有的用户输入，如 [XKCD 漫画][12]中的那样，一位妈妈干掉整个学校的数据库——因为她的儿子的中间名是 “DropTable Students”（LCTT 译注：看不懂的[点这里][17]）。
+
+
+
+所以净化所有的用户输入。你一定检查一下。
+
+她展示了一个 JavaScript 开发者在开源软件中使用 eval 的例子。她警告说：“一个好的基本规则是‘从不使用 eval()’”。 [eval()] [13] 函数会执行 JavaScript 代码。“如果你这样做，你正在向任意用户开放你的系统。”
+
+Davidson 警告说，她甚至偏执到将文档中的示例代码的安全测试也包括在内。她笑着说：“我们都知道没有人会去复制示例代码”。她强调指出，任何代码都应进行安全检查。
+
+
+
+*让它容易*
+
+Plattner 的第三个建议：要使安全容易实施。她建议采取阻力最小的道路。
+
+对外，使用户默认采用安全措施而不是可选采用，或者更好使其成为强制性的措施。她说，改变人们的行为是科技中最难的问题。一旦用户习惯以非安全的方式使用你的产品，让他们改进会变得非常困难。
+
+在公司内部，她建议制定安全标准，因此这不是个别开发人员需要考虑的内容。例如，将数据加密作为服务，这样工程师可以只需要调用服务就可以加密或解密数据。
+
+她说，确保公司注重安全环境。在让整个公司切换到好的安全习惯。
+
+你的最薄弱的环节决定了你的安全水准，所以重要的是每个人都有良好的个人安全习惯，并具有良好的企业安全环境。
+
+在 Oracle，他们已经全面覆盖安全的各个环节。Davidson 表示，她厌倦了向没有安全培训的大学毕业的工程师解释安全性，所以她写了 Oracle 的第一个编码标准，现在已经有数百个页面之多以及很多贡献者，还有一些课程是强制性的。它们具有符合安全要求的度量标准。这些课程不仅适用于工程师，也适用于文档作者。她说：“这是一种文化。”
+
+没有提及密码的关于安全性的讨论怎么能是安全的？Plattner 说：“每个人都应该使用一个好的密码管理器，在工作中应该是强制性的，还有双重身份验证。”
+
+她说，基本的密码原则应该是每个工程师日常生活的一部分。密码中最重要的是它们的长度和熵（使按键的集合尽可能地随机）。强健的密码熵检查器对此非常有用。她建议使用 Dropbox 开源的熵检查器 [zxcvbn][14]。
+
+Plattner 说，另一个诀窍是在验证用户输入时使用一些故意减慢速度的算法，如 [bcrypt][15]。慢速并不困扰大多数合法用户，但会让那些试图强行进行密码尝试的黑客难受。
+
+Davidson 说：“所有这些都为那些想要进入技术安全领域的人提供了工作安全保障，我们在各种地方放了各种代码，这就产生了系统性风险。只要我们继续在技术领域做有趣的事情，我不认为任何人不想要在安全中工作。”
+
+--------------------------------------------------------------------------------
+
+via: https://thenewstack.io/security-engineers-problem/
+
+作者：[TC Currie][a]
+译者：[geekpi](https://github.com/geekpi)
+校对：[wxy](https://github.com/wxy)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
+
+[a]:https://thenewstack.io/author/tc/
+[1]:http://twitter.com/share?url=https://thenewstack.io/security-engineers-problem/&text=Security+Debt+is+an+Engineer%E2%80%99s+Problem+
+[2]:http://www.facebook.com/sharer.php?u=https://thenewstack.io/security-engineers-problem/
+[3]:http://www.linkedin.com/shareArticle?mini=true&url=https://thenewstack.io/security-engineers-problem/
+[4]:https://thenewstack.io/security-engineers-problem/#disqus_thread
+[5]:http://connect2017.womenwhocode.com/
+[6]:https://www.linkedin.com/in/mary-ann-davidson-235ba/
+[7]:https://www.linkedin.com/in/zassmin/
+[8]:https://www.womenwhocode.com/
+[9]:https://www.thenewstack.io/tag/Internet-of-Things
+[10]:https://twitter.com/ittskeziah
+[11]:https://martinfowler.com/bliki/TechnicalDebt.html
+[12]:https://xkcd.com/327/
+[13]:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval
+[14]:https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/
+[15]:https://en.wikipedia.org/wiki/Bcrypt
+[16]:https://thenewstack.io/author/tc/
+[17]:https://www.explainxkcd.com/wiki/index.php/Little_Bobby_Tables
\ No newline at end of file
diff --git a/translated/tech/20170619 Writing a Linux Debugger Part 7 Source-level breakpoints.md b/published/20170619 Writing a Linux Debugger Part 7 Source-level breakpoints.md
similarity index 83%
rename from translated/tech/20170619 Writing a Linux Debugger Part 7 Source-level breakpoints.md
rename to published/20170619 Writing a Linux Debugger Part 7 Source-level breakpoints.md
index 203ee389e6..1272df6a6b 100644
--- a/translated/tech/20170619 Writing a Linux Debugger Part 7 Source-level breakpoints.md
+++ b/published/20170619 Writing a Linux Debugger Part 7 Source-level breakpoints.md
@@ -1,45 +1,32 @@
-开发一个 Linux 调试器（七）：源码层断点
+开发一个 Linux 调试器（七）：源码级断点
============================================================
-在内存地址上设置断点是可以的，但它没有提供最方便用户的工具。我们希望能够在源代码行和函数入口地址上设置断点，以便我们可以在与代码相同的抽象级中别进行调试。
+在内存地址上设置断点虽然不错，但它并没有提供最方便用户的工具。我们希望能够在源代码行和函数入口地址上设置断点，以便我们可以在与代码相同的抽象级别中进行调试。
-这篇文章将会添加源码层断点到我们的调试器中。通过所有我们已经支持的，这比起最初听起来容易得多。我们还将添加一个命令来获取符号的类型和地址，这对于定位代码或数据以及理解链接概念非常有用。
-
-* * *
+这篇文章将会添加源码级断点到我们的调试器中。通过所有我们已经支持的功能，这要比起最初听起来容易得多。我们还将添加一个命令来获取符号的类型和地址，这对于定位代码或数据以及理解链接概念非常有用。
### 系列索引
随着后面文章的发布，这些链接会逐渐生效。
1. [准备环境][1]
-
2. [断点][2]
-
3. [寄存器和内存][3]
-
4. [Elves 和 dwarves][4]
-
5. [源码和信号][5]
-
-6. [源码层逐步执行][6]
-
-7. [源码层断点][7]
-
+6. [源码级逐步执行][6]
+7. [源码级断点][7]
8. [调用栈][8]
-
9. 读取变量
-
10. 之后步骤
-* * *
-
### 断点
-### DWARF
+#### DWARF
-[Elves 和 dwarves][9] 这篇文章，描述了 DWARF 调试信息是如何工作的，以及如何用它来将机器码映射到高层源码中。回想一下，DWARF 包含函数的地址范围和一个允许你在抽象层之间转换代码位置的行表。我们将使用这些功能来实现我们的断点。
+[Elves 和 dwarves][4] 这篇文章，描述了 DWARF 调试信息是如何工作的，以及如何用它来将机器码映射到高层源码中。回想一下，DWARF 包含了函数的地址范围和一个允许你在抽象层之间转换代码位置的行表。我们将使用这些功能来实现我们的断点。
-### 函数入口
+#### 函数入口
如果你考虑重载、成员函数等等，那么在函数名上设置断点可能有点复杂，但是我们将遍历所有的编译单元，并搜索与我们正在寻找的名称匹配的函数。DWARF 信息如下所示：
@@ -85,13 +72,13 @@ void debugger::set_breakpoint_at_function(const std::string& name) {
}
```
-这代码看起来有点奇怪的唯一一点是 `++entry`。 问题是函数的 `DW_AT_low_pc` 不指向该函数的用户代码的起始地址，它指向 prologue 的开始。编译器通常会输出一个函数的 prologue 和 epilogue，它们用于执行保存和恢复堆栈、操作堆栈指针等。这对我们来说不是很有用，所以我们将入口行加一来获取用户代码的第一行而不是 prologue。DWARF 行表实际上具有一些功能，用于将入口标记为函数 prologue 之后的第一行，但并不是所有编译器都输出该函数，因此我采用了原始的方法。
+这代码看起来有点奇怪的唯一一点是 `++entry`。 问题是函数的 `DW_AT_low_pc` 不指向该函数的用户代码的起始地址，它指向 prologue 的开始。编译器通常会输出一个函数的 prologue 和 epilogue，它们用于执行保存和恢复堆栈、操作堆栈指针等。这对我们来说不是很有用，所以我们将入口行加一来获取用户代码的第一行而不是 prologue。DWARF 行表实际上具有一些功能，用于将入口标记为函数 prologue 之后的第一行，但并不是所有编译器都输出它，因此我采用了原始的方法。
-### 源码行
+#### 源码行
要在高层源码行上设置一个断点，我们要将这个行号转换成 DWARF 中的一个地址。我们将遍历编译单元，寻找一个名称与给定文件匹配的编译单元，然后查找与给定行对应的入口。
-DWARF 看山去有点像这样：
+DWARF 看上去有点像这样：
```
.debug_line: line number info for a single cu
@@ -119,7 +106,7 @@ IS=val ISA number, DI=val discriminator value
```
-所以如果我们想要在 `ab.cpp` 的第五行设置一个断点，我们查找与行 (`0x004004e3`) 相关的入口并设置一个断点。
+所以如果我们想要在 `ab.cpp` 的第五行设置一个断点，我们将查找与行 (`0x004004e3`) 相关的入口并设置一个断点。
```
void debugger::set_breakpoint_at_source_line(const std::string& file, unsigned line) {
@@ -138,13 +125,11 @@ void debugger::set_breakpoint_at_source_line(const std::string& file, unsigned l
}
```
-我这里的 `is_suffix` hack，这样你可以为 `a/b/c.cpp` 输入 `c.cpp`。当然你应该使用大小写敏感路径处理库或者其他东西。我很懒。`entry.is_stmt` 是检查行表入口是否被标记为一个语句的开头，这是由编译器根据它认为是断点的最佳目标的地址设置的。
-
-* * *
+我这里做了 `is_suffix` hack，这样你可以输入 `c.cpp` 代表 `a/b/c.cpp` 。当然你实际上应该使用大小写敏感路径处理库或者其它东西，但是我比较懒。`entry.is_stmt` 是检查行表入口是否被标记为一个语句的开头，这是由编译器根据它认为是断点的最佳目标的地址设置的。
### 符号查找
-当我们在对象文件层时，符号是王者。函数用符号命名，全局变量用符号命名，得到一个符号，我们得到一个符号，每个人都得到一个符号。 在给定的对象文件中，一些符号可能引用其他对象文件或共享库，链接器将从符号引用创建一个可执行程序。
+当我们在对象文件层时，符号是王者。函数用符号命名，全局变量用符号命名，你得到一个符号，我们得到一个符号，每个人都得到一个符号。 在给定的对象文件中，一些符号可能引用其他对象文件或共享库，链接器将从符号引用创建一个可执行程序。
可以在正确命名的符号表中查找符号，它存储在二进制文件的 ELF 部分中。幸运的是，`libelfin` 有一个不错的接口来做这件事，所以我们不需要自己处理所有的 ELF 的事情。为了让你知道我们在处理什么，下面是一个二进制文件的 `.symtab` 部分的转储，它由 `readelf` 生成：
@@ -222,7 +207,7 @@ Num: Value Size Type Bind Vis Ndx Name
你可以在对象文件中看到用于设置环境的很多符号，最后还可以看到 `main` 符号。
-我们对符号的类型、名称和值（地址）感兴趣。我们有一个 `symbol_type` 类型的枚举，并使用一个 `std::string` 作为名称，`std::uintptr_t` 作为地址：
+我们对符号的类型、名称和值（地址）感兴趣。我们有一个该类型的 `symbol_type` 枚举，并使用一个 `std::string` 作为名称，`std::uintptr_t` 作为地址：
```
enum class symbol_type {
@@ -265,7 +250,7 @@ symbol_type to_symbol_type(elf::stt sym) {
};
```
-最后我们要查找符号。为了说明的目的，我循环查找符号表的 ELF 部分，然后收集我在其中找到的任意符号到 `std::vector` 中。更智能的实现将建立从名称到符号的映射，这样你只需要查看一次数据就行了。
+最后我们要查找符号。为了说明的目的，我循环查找符号表的 ELF 部分，然后收集我在其中找到的任意符号到 `std::vector` 中。更智能的实现可以建立从名称到符号的映射，这样你只需要查看一次数据就行了。
```
std::vector debugger::lookup_symbol(const std::string& name) {
@@ -287,16 +272,12 @@ std::vector debugger::lookup_symbol(const std::string& name) {
}
```
-* * *
-
### 添加命令
一如往常，我们需要添加一些更多的命令来向用户暴露功能。对于断点，我使用 GDB 风格的接口，其中断点类型是通过你传递的参数推断的，而不用要求显式切换：
* `0x` -> 断点地址
-
* `:` -> 断点行号
-
* `` -> 断点函数名
```
@@ -326,11 +307,9 @@ else if(is_prefix(command, "symbol")) {
}
```
-* * *
-
### 测试一下
-在一个简单的二进制文件上启动调试器，并设置源代码级别的断点。在一些 `foo` 上设置一个断点，看到我的调试器停在它上面是我这个项目最有价值的时刻之一。
+在一个简单的二进制文件上启动调试器，并设置源代码级别的断点。在一些 `foo` 函数上设置一个断点，看到我的调试器停在它上面是我这个项目最有价值的时刻之一。
符号查找可以通过在程序中添加一些函数或全局变量并查找它们的名称来进行测试。请注意，如果你正在编译 C++ 代码，你还需要考虑[名称重整][10]。
@@ -342,19 +321,19 @@ else if(is_prefix(command, "symbol")) {
via: https://blog.tartanllama.xyz/c++/2017/06/19/writing-a-linux-debugger-source-break/
-作者：[Simon Brand ][a]
+作者：[Simon Brand][a]
译者：[geekpi](https://github.com/geekpi)
-校对：[校对者ID](https://github.com/校对者ID)
+校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://twitter.com/TartanLlama
-[1]:https://blog.tartanllama.xyz/c++/2017/03/21/writing-a-linux-debugger-setup/
-[2]:https://blog.tartanllama.xyz/c++/2017/03/24/writing-a-linux-debugger-breakpoints/
-[3]:https://blog.tartanllama.xyz/c++/2017/03/31/writing-a-linux-debugger-registers/
-[4]:https://blog.tartanllama.xyz/c++/2017/04/05/writing-a-linux-debugger-elf-dwarf/
-[5]:https://blog.tartanllama.xyz/c++/2017/04/24/writing-a-linux-debugger-source-signal/
-[6]:https://blog.tartanllama.xyz/c++/2017/05/06/writing-a-linux-debugger-dwarf-step/
+[1]:https://linux.cn/article-8626-1.html
+[2]:https://linux.cn/article-8645-1.html
+[3]:https://linux.cn/article-8663-1.html
+[4]:https://linux.cn/article-8719-1.html
+[5]:https://linux.cn/article-8812-1.html
+[6]:https://linux.cn/article-8813-1.html
[7]:https://blog.tartanllama.xyz/c++/2017/06/19/writing-a-linux-debugger-source-break/
[8]:https://blog.tartanllama.xyz/c++/2017/06/24/writing-a-linux-debugger-unwinding/
[9]:https://blog.tartanllama.xyz/c++/2017/04/05/writing-a-linux-debugger-elf-dwarf/
diff --git a/published/20170724 IoT Framework for Edge Computing Gains Ground.md b/published/20170724 IoT Framework for Edge Computing Gains Ground.md
new file mode 100644
index 0000000000..da5c17a41e
--- /dev/null
+++ b/published/20170724 IoT Framework for Edge Computing Gains Ground.md
@@ -0,0 +1,58 @@
+IoT 边缘计算框架的新进展
+---
+
+
+
+> 开源项目 EdgeX Foundry 旨在开发一个标准化的互操作物联网边缘计算框架。
+
+4 月份时， Linux 基金组织[启动](http://linuxgizmos.com/open-source-group-focuses-on-industrial-iot-gateway-middleware/)了一个开源项目 [EdgeX Foundry](https://www.edgexfoundry.org/) ，用于为物联网边缘计算开发一个标准化互操作框架。 就在最近， EdgeX Foundry 又[宣布](https://www.edgexfoundry.org/announcement/2017/07/17/edgex-foundry-builds-momentum-for-a-iot-interoperability-and-a-unified-marketplace-with-eight-new-members/)新增了 8 个成员，其总成员达到 58 位。
+
+这些新成员是 Absolute、IoT Impact LABS、inwinStack、Parallel Machines、Queen's University Belfast、RIOT、Toshiba Digital Solutions Corporation 和 Tulip Interfaces。 其原有成员包括 AMD、Analog Devices、Canonical/Ubuntu、Cloud Foundry、Dell、Linaro、Mocana、NetFoundry、 Opto 22、RFMicron 和 VMWare 等其他公司或组织。
+
+EdgeX Foundry 项目构建于戴尔早期的基于 Apache2.0 协议的 [FUSE](https://medium.com/@gigastacey/dell-plans-an-open-source-iot-stack-3dde43f24feb) 物联网中间件框架之上，其中包括十几个微服务和超过 12.5 万行代码。在 FUSE 合并了类同项目 AllJoyn-compliant IoTX 之后，Linux 基金会协同 Dell 创立了 EdgeX Foundry ，后者是由 EdgeX Foundry 现有成员 Two Bulls 和 Beechwood 发起的项目。
+
+EdgeX Foundry 将创造一个互操作性的、即插即用组件的物联网边缘计算的生态系统。开源的 EdgeX 栈将协调各种传感器网络协议与多种云平台及分析平台。该框架旨在充分挖掘横跨边缘计算、安全、系统管理和服务等模块间的互操作性代码。
+
+对于项目成员及其客户来说，其关键的好处是在于能将各种预先认证的软件集成到许多 IoT 网关和智能边缘设备上。 在 Linux.com 的一次采访中，[IoT Impact LABS](https://iotimpactlabs.com/) 的首席工程师 Dan Mahoney 说：“现实中，EdgeX Foundry 降低了我们在部署多供应商解决方案时所面对的挑战。”
+
+在 Linux 基金会仍然将其 AllSeen Alliance 项目下的 AllJoyn 规范合并到 [IoTivity](https://www.linux.com/news/how-iotivity-and-alljoyn-could-combine) 标准的情况下，为什么会发起了另外一个物联网标准化项目（EdgeX Foundry） 呢？ 原因之一，EdgeX Foundry 不同于 IoTivity，IoTivity 主要解决工业物联网问题，而 EdgeX Foundry 旨在解决消费级和工业级物联网全部的问题。 更具体来说， EdgeX Foundry 旨在成为网关和智能终端的通用中间件。 EdgeX Foundry 与 IoTivity 的另一个不同在于，前者希望借助预认证的终端塑造一种新产品，后者更多解决现存产品之间的互操作性。
+
+Linux 基金会 IoT 高级总监 Philip DesAutels 说：“IoTivity 提供实现设备之间无缝连接的协议， 而 EdgeX Foundry 提供了一个边缘计算框架。EdgeX Foundry 能够兼容如 IoTivity、 BacNet、 EtherCat 等任何协议设备，从而实现集成多协议通信系统的通用边缘计算框架，该项目的目标是为构建互操作组件的生态系统的过程中，降低不确定性，缩短市场化时间，更好地产生规模效应。”
+
+上个月, 由 [Open Connectivity Foundation](https://openconnectivity.org/developer/specifications/international-standards) （OCF）和 Linux 基金组织共同发起的 IoTivity 项目发布了 [IoTivity 1.3](https://wiki.iotivity.org/release_note_1.3.0)，该版本增加了与其曾经的对手 AllJoyn spec 的纽带，也增加了对于 OCF 的 UPnP 设备发现标准的接口。 预计在 [IoTivity 2.0](https://www.linux.com/news/iotivity-20-whats-store) 中， IoTivity 和 AllJoyn 将会更进一步深入集成。
+
+DesAutels 告诉 linux.com，IoTivity 和 EdgeX 是“高度互补的”，其“原因是 EdgeX Foundry 项目的几个成员也是 IoTivity 或 OCF 的成员，如此更强化了 IoTivity 和 EdgeX 的合作关系。”
+
+尽管 IoTivity 和 EdgeX 都宣称是跨平台的，包括在 CPU 架构和 OS 方面，但是二者还是存在一定区别。 IoTivity 最初是基于 Linux 平台设计，兼容 Ubuntu、Tizen 和 Android 等 Linux 系列 OS，后来逐步扩展到 Windows 和 iOS 操作系统。与之对应的 EdgeX 设计之初就是基于跨平台的理念，其完美兼容于各种 CPU 架构，支持 Linux, Windows 和 Mac OS 等操作系统， 未来还将兼容于实时操作系统（RTOS）。”
+
+EdgeX 的新成员 [RIOT](https://riot-os.org/) 提供了一个开源的面向物联网的项目 RIOT RTOS。RIOT 的主要维护者 Thomas Eichinger 在一次表彰讲话中说：“由于 RIOT 初衷就是致力于解决 linux 不太适应的问题， 故对于 RIOT 社区来说，参加和支持类似于 EdgeX Foundry 等边缘计算的开源组织的积极性是自然而然的。”
+
+### 传感器集成的简化
+
+IoT Impact LABS （即 Impact LABS 或直接称为 LABS）是另一个 EdgeX 新成员。 该公司推出了一个独特的业务模式，旨在帮助中小企业度过物联网解决方案的试用阶段。该公司的大部分客户，其中包括几个 EdgeX Foundry 的项目成员，是致力于建设智慧城市、基础设施再利用、提高食品安全，以及解决社会面临的自然资源缺乏的挑战。
+
+Dan Mahoney 说：“在 LABS 我们花费了很多时间来调和试点客户的解决方案之间的差异性。 EdgeX Foundry 可以最小化部署边缘软件系统的工作量，从而使我们能够更快更好地部署高质量的解决方案。”
+
+该框架在涉及多个供应商、多种类型传感器的场景尤其凸显优势。“Edgex Foundry 将为我们提供快速构建可以控制所有部署的传感器的网关的能力。” Mahoney 补充说到。传感器制造商将借助 EdgeX SDK 烧写应用层协议驱动到边缘设备，该协议能够兼容多供应商和解决方案。
+
+### 边缘分析能力的构建
+
+当我们问到， Mahoney 的公司希望见到 EdgeX Foundry 怎样的发展时，他说：“我们喜见乐闻的一个目标是有更多有效的工业协议成为设备服务，这是一个更清晰的边缘计算实现之路。”
+
+在工业物联网和消费级物联网中边缘计算都呈现增长趋势。 在后者，我们已经看到如 Alexa 的智能声控以及录像分析等几个智能家居系统[集成了边缘计算分析](https://www.linux.com/news/smart-linux-home-hubs-mix-iot-ai)技术。 这减轻了云服务平台的计算负荷，但同时也带来了安全、隐私，以及由于供应商中断或延迟问题引起的服务中断问题。
+
+对于工业物联网网关，延迟问题成为首要的问题。因此，在物联网网关方面出现了一些类似于云服务功能的扩展。 其中一个解决方案是，为了安全将一些云服务上的安全保障应用借助容器如 [RIOS 与 Ubuntu 内核快照机制](https://www.linux.com/news/future-iot-containers-aim-solve-security-crisis)等方式集成到嵌入式设备。 另一种方案是，开发 IoT 生态系统，迁移云功能到边缘计算上。上个月，Amazon 为基于 linux 的网关发布了实现 [AWS Greengrass](http://linuxgizmos.com/amazon-releases-aws-greengrass-for-local-iot-processing-on-linux-devices/) 物联网协议栈的 AWS lambda。 该软件能够使 AWS 计算、消息路由、数据缓存和同步能力在诸如物联网网关等联网设备上完成。
+
+分析能力是 EdgeX Foundry 发展路线上的一个关键功能要点。 发起成员之一 Cloud Foundry 其旨在集成其主要的工业应用平台到边缘设备。 另一个新成员 [Parallel Machines](https://www.parallelmachines.com/) 则计划利用 EdgeX 将 AI 带到边缘设备。
+
+EdgeX Foundry 仍然在项目早期， 软件仍然在 α 阶段，其成员在上个月（六月份）才刚刚进行了第一次全体成员大会。同时该项目已经为新开发者准备了一些初始训练课程，另外从[这里](https://wiki.edgexfoundry.org/)也能获取更多的信息。
+
+----
+
+via: [https://www.linux.com/blog/2017/7/iot-framework-edge-computing-gains-ground](https://www.linux.com/blog/2017/7/iot-framework-edge-computing-gains-ground)
+
+作者： [ERIC BROWN](https://www.linux.com/users/ericstephenbrown)
+译者：[penghuster](https://github.com/penghuster)
+校对：[wxy](https://github.com/wxy)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
diff --git a/translated/tech/GDB-common-commands.md b/published/GDB-common-commands.md
similarity index 75%
rename from translated/tech/GDB-common-commands.md
rename to published/GDB-common-commands.md
index b6b90309f1..3876b010b1 100644
--- a/translated/tech/GDB-common-commands.md
+++ b/published/GDB-common-commands.md
@@ -1,6 +1,7 @@
-# 常用的 GDB 命令中文释义
+常用 GDB 命令中文速览
+============
-## 目录
+### 目录
- [break](#break) -- 在指定的行或函数处设置断点，缩写为 `b`
- [info breakpoints](#info-breakpoints) -- 打印未删除的所有断点，观察点和捕获点的列表，缩写为 `i b`
@@ -33,10 +34,12 @@
------
-## break
+### break
使用 `break` 命令（缩写 `b`）来设置断点。
+用法：
+
- `break` 当不带参数时，在所选栈帧中执行的下一条指令处设置断点。
- `break ` 在函数体入口处打断点，在 C++ 中可以使用 `class::function` 或 `function(type, ...)` 格式来指定函数名。
- `break ` 在当前源码文件指定行的开始处打断点。
@@ -48,40 +51,49 @@
详见[官方文档][1]。
-## info breakpoints
+### info breakpoints
-查看断点，观察点和捕获点的列表。用法：
-`info breakpoints [list…]`
-`info break [list…]`
-`list…` 用来指定若干个断点的编号（可省略），可以是 `2`， `1-3`， `2 5` 等。
+查看断点，观察点和捕获点的列表。
-## disable
+用法：
+
+- `info breakpoints [list...]`
+- `info break [list...]`
+- `list...` 用来指定若干个断点的编号（可省略），可以是 `2`， `1-3`， `2 5` 等。
+
+### disable
禁用一些断点。参数是用空格分隔的断点编号。要禁用所有断点，不加参数。
禁用的断点不会被忘记，但直到重新启用才有效。
-用法： `disable [breakpoints] [list…]`
-`breakpoints` 是 `disable` 的子命令（可省略），`list…` 同 `info breakpoints` 中的描述。
+用法：
+
+- `disable [breakpoints] [list...]`
+- `breakpoints` 是 `disable` 的子命令（可省略），`list...` 同 `info breakpoints` 中的描述。
详见[官方文档][2]。
-## enable
+### enable
启用一些断点。给出断点编号（以空格分隔）作为参数。没有参数时，所有断点被启用。
-- `enable [breakpoints] [list…]` 启用指定的断点（或所有定义的断点）。
-- `enable [breakpoints] once list…` 临时启用指定的断点。GDB 在停止您的程序后立即禁用这些断点。
-- `enable [breakpoints] delete list…` 使指定的断点启用一次，然后删除。一旦您的程序停止，GDB 就会删除这些断点。等效于用 `tbreak` 设置的断点。
+用法：
+
+- `enable [breakpoints] [list...]` 启用指定的断点（或所有定义的断点）。
+- `enable [breakpoints] once list...` 临时启用指定的断点。GDB 在停止您的程序后立即禁用这些断点。
+- `enable [breakpoints] delete list...` 使指定的断点启用一次，然后删除。一旦您的程序停止，GDB 就会删除这些断点。等效于用 `tbreak` 设置的断点。
`breakpoints` 同 `disable` 中的描述。
详见[官方文档][2]。
-## clear
+### clear
在指定行或函数处清除断点。参数可以是行号，函数名称或 `*` 跟一个地址。
+用法：
+
- `clear` 当不带参数时，清除所选栈帧在执行的源码行中的所有断点。
- `clear `, `clear ` 删除在命名函数的入口处设置的任何断点。
- `clear `, `clear ` 删除在指定的文件指定的行号的代码中设置的任何断点。
@@ -89,198 +101,206 @@
详见[官方文档][3]。
-## delete
+### delete
删除一些断点或自动显示表达式。参数是用空格分隔的断点编号。要删除所有断点，不加参数。
-用法： `delete [breakpoints] [list…]`
+用法： `delete [breakpoints] [list...]`
详见[官方文档][3]。
-## tbreak
+### tbreak
设置临时断点。参数形式同 `break` 一样。
+
除了断点是临时的之外，其他同 `break` 一样，所以在命中时会被删除。
详见[官方文档][1]。
-## watch
+### watch
为表达式设置观察点。
-用法： `watch [-l|-location] `
-每当一个表达式的值改变时，观察点就会暂停程序执行。
-如果给出了 `-l` 或者 `-location`，则它会对 `expr` 求值并观察它所指向的内存。
-例如，`watch *(int *)0x12345678` 将在指定的地址处观察一个 4 字节的区域（假设 int 占用 4 个字节）。
+用法： `watch [-l|-location] ` 每当一个表达式的值改变时，观察点就会暂停程序执行。
+
+如果给出了 `-l` 或者 `-location`，则它会对 `expr` 求值并观察它所指向的内存。例如，`watch *(int *)0x12345678` 将在指定的地址处观察一个 4 字节的区域（假设 int 占用 4 个字节）。
详见[官方文档][4]。
-## step
+### step
单步执行程序，直到到达不同的源码行。
-用法： `step [N]`
-参数 `N` 表示执行 N 次（或由于另一个原因直到程序停止）。
+用法： `step [N]` 参数 `N` 表示执行 N 次（或由于另一个原因直到程序停止）。
+
警告：如果当控制在没有调试信息的情况下编译的函数中使用 `step` 命令，则执行将继续进行，直到控制到达具有调试信息的函数。 同样，它不会进入没有调试信息编译的函数。
+
要执行没有调试信息的函数，请使用 `stepi` 命令，详见后文。
详见[官方文档][5]。
-## reverse-step
+### reverse-step
反向单步执行程序，直到到达另一个源码行的开头。
-用法： `reverse-step [N]`
-参数 `N` 表示执行 N 次（或由于另一个原因直到程序停止）。
+用法： `reverse-step [N]` 参数 `N` 表示执行 N 次（或由于另一个原因直到程序停止）。
详见[官方文档][6]。
-## next
+### next
单步执行程序，执行完子程序调用。
用法： `next [N]`
+
与 `step` 不同，如果当前的源代码行调用子程序，则此命令不会进入子程序，而是将其视为单个源代码行，继续执行。
详见[官方文档][5]。
-## reverse-next
+### reverse-next
反向步进程序，执行完子程序调用。
用法： `reverse-next [N]`
+
如果要执行的源代码行调用子程序，则此命令不会进入子程序，调用被视为一个指令。
+
参数 `N` 表示执行 N 次（或由于另一个原因直到程序停止）。
详见[官方文档][6]。
-## return
+### return
-您可以使用 `return` 命令取消函数调用的执行。
+您可以使用 `return` 命令取消函数调用的执行。如果你给出一个表达式参数，它的值被用作函数的返回值。
-如果你给出一个表达式参数，它的值被用作函数的返回值。
-`return ` 将 `expression` 的值作为函数的返回值并使函数直接返回。
+用法： `return ` 将 `expression` 的值作为函数的返回值并使函数直接返回。
详见[官方文档][7]。
-## finish
+### finish
执行直到选定的栈帧返回。
-用法： `finish`
-返回后，返回的值将被打印并放入到值历史记录中。
+用法： `finish` 返回后，返回的值将被打印并放入到值历史记录中。
详见[官方文档][5]。
-## until
+### until
-执行直到程序到达当前栈帧中当前行之后（与 [break](#break) 命令相同的参数）的源码行。
-此命令用于通过一个多次的循环，以避免单步执行。
-`until ` 或 `u ` 继续运行程序，直到达到指定的位置，或者当前栈帧返回。
+执行直到程序到达当前栈帧中当前行之后（与 [break](#break) 命令相同的参数）的源码行。此命令用于通过一个多次的循环，以避免单步执行。
+
+用法：`until ` 或 `u ` 继续运行程序，直到达到指定的位置，或者当前栈帧返回。
详见[官方文档][5]。
-## continue
+### continue
在信号或断点之后，继续运行被调试的程序。
-用法： `continue [N]`
-如果从断点开始，可以使用数字 `N` 作为参数，这意味着将该断点的忽略计数设置为 `N - 1`(以便断点在第 N 次到达之前不会中断)。
-如果启用了非停止模式（使用 `show non-stop` 查看），则仅继续当前线程，否则程序中的所有线程都将继续。
+用法： `continue [N]` 如果从断点开始，可以使用数字 `N` 作为参数，这意味着将该断点的忽略计数设置为 `N - 1`(以便断点在第 N 次到达之前不会中断)。如果启用了非停止模式（使用 `show non-stop` 查看），则仅继续当前线程，否则程序中的所有线程都将继续。
详见[官方文档][5]。
-## print
+### print
-求值并打印表达式 EXP 的值。
-可访问的变量是所选栈帧的词法环境，以及范围为全局或整个文件的所有变量。
+求值并打印表达式 EXP 的值。可访问的变量是所选栈帧的词法环境，以及范围为全局或整个文件的所有变量。
+
+用法：
+
+- `print [expr]` 或 `print /f [expr]` `expr` 是一个（在源代码语言中的）表达式。
-用法： `print [expr]` 或 `print /f [expr]`
-`expr` 是一个（在源代码语言中的）表达式。
默认情况下，`expr` 的值以适合其数据类型的格式打印；您可以通过指定 `/f` 来选择不同的格式，其中 `f` 是一个指定格式的字母；详见[输出格式][9]。
+
如果省略 `expr`，GDB 再次显示最后一个值。
+
要以每行一个成员带缩进的格式打印结构体变量请使用命令 `set print pretty on`，取消则使用命令 `set print pretty off`。
+
可使用命令 `show print` 查看所有打印的设置。
详见[官方文档][8]。
-## x
+### x
检查内存。
-用法： `x/nfu ` 或 `x `
-`n`, `f`, 和 `u` 都是可选参数，用于指定要显示的内存以及如何格式化。
-`addr` 是要开始显示内存的地址的表达式。
+用法： `x/nfu ` 或 `x ` `n`、`f` 和 `u` 都是可选参数，用于指定要显示的内存以及如何格式化。`addr` 是要开始显示内存的地址的表达式。
+
`n` 重复次数（默认值是 1），指定要显示多少个单位（由 `u` 指定）的内存值。
+
`f` 显示格式（初始默认值是 `x`），显示格式是 `print('x'，'d'，'u'，'o'，'t'，'a'，'c'，'f'，'s')` 使用的格式之一，再加 `i`（机器指令）。
+
`u` 单位大小，`b` 表示单字节，`h` 表示双字节，`w` 表示四字节，`g` 表示八字节。
+
例如：
+
`x/3uh 0x54320` 表示从地址 0x54320 开始以无符号十进制整数的格式，双字节为单位来显示 3 个内存值。
+
`x/16xb 0x7f95b7d18870` 表示从地址 0x7f95b7d18870 开始以十六进制整数的格式，单字节为单位显示 16 个内存值。
详见[官方文档][10]。
-## display
+### display
每次程序暂停时，打印表达式 EXP 的值。
-用法： `display `, `display/fmt ` 或 `display/fmt `
-`fmt` 用于指定显示格式。像 [print](#print) 命令里的 `/f` 一样。
+用法： `display `, `display/fmt ` 或 `display/fmt ` `fmt` 用于指定显示格式。像 [print](#print) 命令里的 `/f` 一样。
+
对于格式 `i` 或 `s`，或者包括单位大小或单位数量，将表达式 `addr` 添加为每次程序停止时要检查的内存地址。
详见[官方文档][11]。
-## info display
+### info display
打印自动显示的表达式列表，每个表达式都带有项目编号，但不显示其值。
+
包括被禁用的表达式和不能立即显示的表达式（当前不可用的自动变量）。
-## undisplay
+### undisplay
+
+取消某些表达式在程序暂停时的自动显示。参数是表达式的编号（使用 `info display` 查询编号）。不带参数表示取消所有自动显示表达式。
-取消某些表达式在程序暂停时的自动显示。
-参数是表达式的编号（使用 `info display` 查询编号）。
-不带参数表示取消所有自动显示表达式。
`delete display` 具有与此命令相同的效果。
-## disable display
+### disable display
-禁用某些表达式在程序暂停时的自动显示。
-禁用的显示项目不会被自动打印，但不会被忘记。 它可能稍后再次被启用。
-参数是表达式的编号（使用 `info display` 查询编号）。
-不带参数表示禁用所有自动显示表达式。
+禁用某些表达式在程序暂停时的自动显示。禁用的显示项目不会被自动打印，但不会被忘记。 它可能稍后再次被启用。
-## enable display
+参数是表达式的编号（使用 `info display` 查询编号）。不带参数表示禁用所有自动显示表达式。
+
+### enable display
启用某些表达式在程序暂停时的自动显示。
-参数是重新显示的表达式的编号（使用 `info display` 查询编号）。
-不带参数表示启用所有自动显示表达式。
-## help
+参数是重新显示的表达式的编号（使用 `info display` 查询编号）。不带参数表示启用所有自动显示表达式。
+
+### help
打印命令列表。
+
您可以使用不带参数的 `help`（缩写为 `h`）来显示命令的类别名的简短列表。
-使用 `help ` 您可以获取该类中的各个命令的列表。
-使用 `help ` 显示如何使用该命令。
+使用 `help ` 您可以获取该类中的各个命令的列表。使用 `help ` 显示如何使用该命令。
详见[官方文档][12]。
-## attach
+### attach
+
+挂接到 GDB 之外的进程或文件。该命令可以将进程 ID 或设备文件作为参数。
-挂接到 GDB 之外的进程或文件。
-该命令可以将进程 ID 或设备文件作为参数。
对于进程 ID，您必须具有向进程发送信号的权限，并且必须具有与调试器相同的有效的 uid。
-用法： `attach `
-GDB 在安排调试指定的进程之后做的第一件事是暂停该进程。
+用法： `attach ` GDB 在安排调试指定的进程之后做的第一件事是暂停该进程。
+
无论是通过 `attach` 命令挂接的进程还是通过 `run` 命令启动的进程，您都可以使用的 GDB 命令来检查和修改挂接的进程。
详见[官方文档][13]。
-## run
+### run
启动被调试的程序。
+
可以直接指定参数，也可以用 [set args][15] 设置（启动所需的）参数。
+
例如： `run arg1 arg2 ...` 等效于
```
@@ -288,11 +308,11 @@ set args arg1 arg2 ...
run
```
-还允许使用 `>`, `<`, 或 `>>` 进行输入和输出重定向。
+还允许使用 `>`、 `<` 或 `>>` 进行输入和输出重定向。
详见[官方文档][14]。
-## backtrace
+### backtrace
打印整体栈帧信息。
@@ -317,13 +337,16 @@ run
详见[官方文档][16]。
-## ptype
+### ptype
打印类型 TYPE 的定义。
用法： `ptype[/FLAGS] TYPE-NAME | EXPRESSION`
+
参数可以是由 `typedef` 定义的类型名， 或者 `struct STRUCT-TAG` 或者 `class CLASS-NAME` 或者 `union UNION-TAG` 或者 `enum ENUM-TAG`。
+
根据所选的栈帧的词法上下文来查找该名字。
+
类似的命令是 `whatis`，区别在于 `whatis` 不展开由 `typedef` 定义的数据类型，而 `ptype` 会展开，举例如下：
```
@@ -368,13 +391,14 @@ type = double *
------
-## 参考资料
+### 参考资料
- [Debugging with GDB](https://sourceware.org/gdb/current/onlinedocs/gdb/)
------
-翻译者：[robot527](https://github.com/robot527)
+译者：[robot527](https://github.com/robot527)
+校对：[mudongliang](https://github.com/mudongliang)， [wxy](https://github.com/wxy)
[1]: https://sourceware.org/gdb/current/onlinedocs/gdb/Set-Breaks.html
[2]: https://sourceware.org/gdb/current/onlinedocs/gdb/Disabling.html
diff --git a/sources/talk/20170202 Why we need open leaders more than ever.md b/sources/talk/20170202 Why we need open leaders more than ever.md
deleted file mode 100644
index 276d951ea6..0000000000
--- a/sources/talk/20170202 Why we need open leaders more than ever.md
+++ /dev/null
@@ -1,82 +0,0 @@
-Translating by TimeBear
-Why we need open leaders more than ever
-============================================================
-
-### Changing social and cultural conditions are giving rise to open leadership.
-
-Posted 02 Feb 2017[Philip A Foster][10][Feed][9]13[up][6]
- 
->Image by : opensource.com
-
-Leadership is power. More specifically, leadership is the power to influence the actions of others. The mythology of leadership can certainly conjure images of not only the romantic but also the sinister side of the human condition. How we ultimately decide to engage in leadership determines its true nature.
-
-Many modern understandings of leadership are born out of warfare, where leadership is the skillful execution of command-and-control thinking. For most of the modern era of business, then, we engaged leadership as some great man or woman arriving at the pinnacle of power and exerting this power through position. Such traditional leadership relies heavily on formal lines of authority through hierarchies and reporting relationships. Authority in these structures flows down through the vertical hierarchy and exists along formal lines in the chain of command.
-
->Open leaders quickly discover that leadership is not about the power we exert to influence progress, but the power and confidence we distribute among the members of the organization.
-
-However, in the late 20th century, something began to change. New technologies opened doors to globalism and thus more dispersed teams. The way we engaged human capital began to shift, forever changing the way people communicate with each other. People inside organizations began to feel empowered, and they demanded a sense of ownership of their successes (and failures). Leaders were no longer the sole owners of power. The 21st century leader leading the 21st century organization began to understand empowerment, collaboration, accountability, and clear communication were the essence of a new kind of power. These new leaders began _sharing_ that power—and they implicitly trusted their followers.
-
-As organizations continue becoming more open, even individuals without "leadership" titles feel empowered to drive change. These organizations remove the chains of hierarchy and untether workers to do their jobs in the ways they best see fit. History has exposed 20th century leaders' tendencies to strangle agility through unilateral decision-making and unidirectional information flows. But the new century's leader best defines an organization by the number of individuals it empowers to get something done. There's power in numbers—and, frankly, one leader cannot be in all places at all times, making all the decisions.
-
-So leaders are becoming open, too.
-
-### Control
-
-Where the leaders of old are focused on command-and-control positional power, an open leader cedes organizational control to others via new forms of organizational governance, new technologies, and other means of reducing friction, thereby enabling collective action in a more efficient manner. These leaders understand the power of trust, and believe followers will always show initiative, engagement, and independence. And this new brand of leadership requires a shift in tactics—from _telling people what to do_ to _showing them what to do_ and _coaching them along the way_. Open leaders quickly discover that leadership is not about the power we exert to influence progress, but the power and confidence we _distribute_ among the members of the organization. The 21stcentury leader is focused on community and the edification of others. In the end, the open leader is not focused on self but is selfless.
-
-### Communication
-
-The 20th century leader hordes and controls the flow of information throughout the organization. The open leader, however, seeks to engage an organization by sharing information and context (as well as authority) with members of a team. These leaders destroy fiefdoms, walk humbly, and share power like never before. The collective empowerment and engaged collaboration they inspire create agility, shared responsibility, ownership—and, above all, happiness. When members of an organization are empowered to do their jobs, they're happier (and thus more productive) than their hierarchical counterparts.
-
-### Trust
-
-Open leaders embrace uncertainty and trust their followers to do the right thing at the right time. They possess an ability to engage human capital at a higher level of efficiency than their traditional counterparts. Again: They don't operate as command-and-control micromanagers. Elevating transparency, they don't operate in hiding, and they do their best to keep decisions and actions out in the open, explaining the basis on which decisions get made and assuming employees have a high level grasp of situations within the organization. Open leaders operate from the premise that the organization's human capital is more than capable of achieving success without their constant intervention.
-
-### Autonomy
-
-Where the powerful command-and-control 20th century leader is focused on some _position_ of power, an open leader is more interested in the actual _role_ an individual plays within the organization. When a leader is focused on an _individual_, they're better able to coach and mentor members of a team. From this perspective, an open leader is focused on modeling behaviors and actions that are congruent with the organization's vision and mission. In the end, an open leader is very much seen as a member of the team rather than the _head_ of the team. This does not mean the leader abdicates a position of authority, but rather understates it in an effort to share power and empower individuals through autonomy to create results.
-
-### Empowerment
-
-Open leaders are focused on granting authority to members of an organization. This process acknowledges the skills, abilities, and trust the leader has in the organization's human capital, and thereby creates positive motivation and willingness for the entire team to take risks. Empowerment, in the end, is about helping followers believe in their own abilities. Followers who believe that they have personal power are more likely to undertake initiatives, set and achieve higher goals, and persist in the face of difficult circumstances. Ultimately the concept of an open organization is about inclusivity, where everyone belongs and individuality and differing opinions are essential to success. An open organization and its open leaders offer a sense of community, and members are motivated by the organization's mission or purpose. This creates a sense of belonging to something bigger than the individual. Individuality creates happiness and job satisfaction among its members. In turn, higher degrees of efficiency and success are achieved.
-
->More Open Organization Resources
-
-* [Download the Open Organization Leaders Manual][1]
-* [Download the Open Organization Field Guide][2]
-* [What is an Open Organization?][3]
-* [What is an Open Decision?][4]
-
-We should all strive for the openness the 21st century leader requires. This requires self-examination, curiosity—and, above all, it's ongoing process of change. Through new attitudes and habits, we move toward the discovery of what an open leader really _is _and _does,_ and hopefully we begin to take on those ideals as we adapt our leadership styles to the 21st century.
-
-Yes, leadership is power. How we use that power determines the success or failure of our organizations. Those who abuse power don't last, but those who share power and celebrate others do. By reading [this book][7], you are beginning to play an important role in the ongoing conversation of the open organization and its leadership. And at the conclusion of [this volume][8], you'll find additional resources and opportunities to connect with the open organization community, so that you too can chat, think, and grow with us. Welcome to the conversation—welcome to the journey!
-
-_This article originally appeared as the introduction to _The Open Organization Leaders Manual_, now [available from Opensource.com][5]._
-
---------------------------------------------------------------------------------
-
-译者简介：
-
-Philip A Foster - Dr. Philip A. Foster is a leadership/business coach and consultant and Adjunct Professor. He is a noted Thought Leader in Business Operations, Organizational Development, Foresight and Strategic Leadership. Dr. Foster facilitates change through the design and implementation of strategies, strategic foresight, and planning.
-
---------------------------------------------------------------------------------
-
-via: https://opensource.com/open-organization/17/2/need-open-leaders-more-ever
-
-作者：[Philip A Foster][a]
-译者：[译者ID](https://github.com/译者ID)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
-
-[a]:https://opensource.com/users/maximumchange
-[1]:https://opensource.com/open-organization/resources/leaders-manual?src=too_resource_menu
-[2]:https://opensource.com/open-organization/resources/field-guide?src=too_resource_menu
-[3]:https://opensource.com/open-organization/resources/open-org-definition?src=too_resource_menu
-[4]:https://opensource.com/open-organization/resources/open-decision-framework?src=too_resource_menu
-[5]:https://opensource.com/open-organization/resources/leaders-manual
-[6]:https://opensource.com/open-organization/17/2/need-open-leaders-more-ever?rate=c_9hT0EKbdXcTGRl-YW0QgW60NsRwO2a4RaplUKfvXs
-[7]:https://opensource.com/open-organization/resources/leaders-manual
-[8]:https://opensource.com/open-organization/resources/leaders-manual
-[9]:https://opensource.com/user/15497/feed
-[10]:https://opensource.com/users/maximumchange
diff --git a/sources/talk/20170602 Why working openly is hard when you just want to get stuff done.md b/sources/talk/20170602 Why working openly is hard when you just want to get stuff done.md
deleted file mode 100644
index e2925d58bc..0000000000
--- a/sources/talk/20170602 Why working openly is hard when you just want to get stuff done.md
+++ /dev/null
@@ -1,122 +0,0 @@
-translating by @explosic4
-
-Why working openly is hard when you just want to get stuff done
-============================================================
-
-### Learn how to create a book using the Open Decision Framework.
-
-
-
->Image by : opensource.com
-
-Three letters guide the way I work: GSD—get stuff done. Over the years, I've managed to blend concepts like feedback loops (from lean methodologies) and iterative improvement (from Agile) into my everyday work habits so I can better GSD (if I can use that as a verb). This means being extremely efficient with my time: outlining clear, discrete goals; checking completed items off a master list; and advancing projects forward iteratively and constantly. But can someone still GSD while defaulting to open? Or is this when getting stuff done comes to a grinding halt? Most would assume the worst, but I found that's not necessarily the case.
-
-Working in the open and using guidance from the [Open Decision Framework][6] can get projects off to a slower start. But during a recent project, we made the decision—right at the beginning—to work openly and collaborate with our community.
-
-Open Organization resources
-
-* [Download the Open Organization Guide to IT Culture Change][1]
-
-* [Download the Open Organization Leaders Manual][2]
-
-* [What is an Open Organization?][3]
-
-* [What is an Open Decision?][4]
-
-It was the best decision we could have made.
-
-Let's take a look at a few unexpected consequences from this experience and see how we can incorporate a GSD mentality into the Open Decision Framework.
-
-### Building community
-
-In November 2014, I undertook a new project: build a community around the concepts in _The Open Organization_ , a forthcoming (at the time) book by Red Hat CEO Jim Whitehurst. I thought, "Cool, that sounds like a challenge—I'm in!" Then [impostor syndrome][7] set in. I started thinking: "What in the world are we going to do, and what would success look like?"
-
- _Spoiler alert_ . At the end of the book, Jim recommends that readers visit Opensource.com to continue the conversation about openness and management in the 21st century. So, in May 2015, my team launched a new section of the site dedicated to those ideas. We planned to engage in some storytelling, just like we always do at Opensource.com—this time around the ideas and concepts in the book. Since then, we've published new articles every week, hosted an online book club complete with Twitter chats, and turned _The Open Organization_ into [a book series][8].
-
-We produced the first three installments of our book series in-house, releasing one every six months. When we finished one, we'd announce it to the community. Then we'd get to work on the next one, and the cycle would continue.
-
-Working this way, we saw great success. Nearly 3,000 people have registered to receive the [latest book in the series][9], _The Open Organization Leaders Manual_ . And we've maintained our six-month cadence, which means the next book would coincide with the second anniversary of the book.
-
-Behind the scenes, our process for creating the books is fairly straightforward: We collect our best-of-best stories about particular aspects of working openly, organize them into a compelling narrative, recruit writers to fill some gaps, typeset everything with open tools, collaborate with designers on a cover, and release. Working like this allows us to stay on our own timeline—GSD, full steam ahead. By the [third book][10], we seemed to have perfected the process.
-
-That all changed when we began planning the latest volume in _Open Organization_ series, one focused on the intersection of open organizations and IT culture. I proposed using the Open Decision Framework because I wanted this book to be proof that working openly produced better results, even though I knew it would completely change our approach to the work. In spite of a fairly aggressive timeline (about two-and-a-half months), we decided to try it.
-
-### Creating a book with the Open Decision Framework
-
-The Open Decision Framework lists four phases that constitute the open decision-making process. Here's what we did during each (and how it worked out).
-
-### 1\. Ideation
-
-First, we drafted a document outlining a tentative vision for the project. We needed something we could begin sharing with potential "customers" (in our case, potential stakeholders and authors). Then we scheduled interviews with source matter experts we thought would be interested in the project—people who would give us raw, honest feedback about it. Enthusiasm and guidance from those experts validated our idea and gave us the feedback we needed to move forward. If we hadn't gotten that validation, we'd have gone back to our proposal and made a decision on where to pivot and start over.
-
-### 2\. Planning and research
-
-With validation after several interviews, we prepared to [announce the project publically on Opensource.com][11]. At the same time, we [launched the project on GitHub][12], offering a description, prospective timeline, and set of constraints. The project announcement was so well-received that all remaining holes in our proposed table of contents were filled within 72 hours. In addition (and more importantly), readers proposed ideas for chapters that _weren't _ already in the table of contents—things they thought might enhance the vision we'd initially sketched.
-
-We experienced Linus' Law firsthand: "With more eyes, all _typos_ are shallow."
-
-Looking back, I get the sense that working openly on Phases 1 and 2 really didn't negatively impacted our ability to GSD. In fact, working this way had a huge upside: identifying and filling content gaps. We didn't just fill them; we filled them _rapidly_ and with chapter ideas, we never would have considered on our own. This didn't necessarily involve more work—just work of a different type. We found ourselves asking people in our limited network to write chapters, then managing incoming requests, setting context, and pointing people in the right direction.
-
-### 3\. Design, development, and testing
-
-This point in the project was all about project management, cat herding, and maintaining expectations. We were on a deadline, and we communicated that early and often. We also used a tactic of creating a list of contributors and stakeholders and keeping them updated and informed along the entire journey, particularly at milestones we'd identified on GitHub.
-
-Eventually, our book needed a title. We gathered lots of feedback on what the title should be, and more importantly what it _shouldn't_ be. We [opened an issue][13] as one way of gathering feedback, then openly shared that my team would be making the final decision. When we were ready to announce the final title, my colleague Bryan Behrenshausen did a great job [sharing the context for the decision][14]. People seemed to be happy with it—even if they didn't agree with where we landed with the final title.
-
-Book "testing" involved extensive [proofreading][15]. The community really stepped up to answer this "help wanted" request. We received approximately 80 comments on the GitHub issue outlining the proofing process (not to mention numerous additional interactions from others via email and other feedback channels).
-
-With respect to getting things done: In this phase, we experienced [Linus' Law][16] firsthand: "With more eyes, all _typos_ are shallow." Had we used the internalized method we'd used for our three previous book projects, the entire burden of proofing would have fallen on our shoulders (as it did for those books!). Instead, community members graciously helped us carry the burden of proofing, and our work shifted from proofing itself (though we still did plenty of that) to managing all the change requests coming in. This was a much-welcomed change for our team and a chance for the community to participate. We certainly would have finished the proofing faster if we'd done it ourselves, but working on this in the open undeniably allowed us to catch a greater number of errors in advance of our deadline.
-
-### 4\. Launch
-
-And here we are, on the cusp of launching the final (or is it just the first?) version of the book.
-
-Following the Open Decision Framework was key to the success of the Guide to IT Culture Change.
-
-Our approach to launch consists of two phases. First, in keeping with our public project timeline, we quietly soft-launched the book days ago so our community of contributors could help us test the [download form][17]. The second phase begins right now, with the final, formal announcement of the book's [general availability][18]. Of course, we'll continue accepting additional feedback post-launch, as is the open source way.
-
-### Achievement unlocked
-
-Following the Open Decision Framework was key to the success of the _Guide to IT Culture Change_ . By working with our customers and stakeholders, sharing our constraints, and being transparent with the work, we exceeded even our own expectations for the book project.
-
-I was definitely pleased with the collaboration, feedback, and activity we experienced throughout the entire project. And although the feeling of anxiety about not getting stuff done as quickly as I'd liked loomed over me for a time, I soon realized that opening up the process actually allowed us to get _more_ done than we would have otherwise. That should be evident based on some of the outcomes I outlined above.
-
-So perhaps I should reconsider my GSD mentality and expand it to GMD: Get **more** done—and, in this case, with better results.
-
---------------------------------------------------------------------------------
-
-作者简介：
-
-Jason Hibbets - Jason Hibbets is a senior community evangelist in Corporate Marketing at Red Hat where he is a community manager for Opensource.com. He has been with Red Hat since 2003 and is the author of The foundation for an open source city. Prior roles include senior marketing specialist, project manager, Red Hat Knowledgebase maintainer, and support engineer. Follow him on Twitter:
-
------------
-
-via: https://opensource.com/open-organization/17/6/working-open-and-gsd
-
-作者：[Jason Hibbets ][a]
-译者：[译者ID](https://github.com/译者ID)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
-
-[a]:https://opensource.com/users/jhibbets
-[1]:https://opensource.com/open-organization/resources/culture-change?src=too_resource_menu
-[2]:https://opensource.com/open-organization/resources/leaders-manual?src=too_resource_menu
-[3]:https://opensource.com/open-organization/resources/open-org-definition?src=too_resource_menu
-[4]:https://opensource.com/open-organization/resources/open-decision-framework?src=too_resource_menu
-[5]:https://opensource.com/open-organization/17/6/working-open-and-gsd?rate=ZgpGc0D07SjGkTOf708lnNqbF_HvkhXTXeSzRKMhvVM
-[6]:https://opensource.com/open-organization/resources/open-decision-framework
-[7]:https://opensource.com/open-organization/17/5/team-impostor-syndrome
-[8]:https://opensource.com/open-organization/resources
-[9]:https://opensource.com/open-organization/resources/leaders-manual
-[10]:https://opensource.com/open-organization/resources/leaders-manual
-[11]:https://opensource.com/open-organization/17/3/announcing-it-culture-book
-[12]:https://github.com/open-organization-ambassadors/open-org-it-culture
-[13]:https://github.com/open-organization-ambassadors/open-org-it-culture/issues/20
-[14]:https://github.com/open-organization-ambassadors/open-org-it-culture/issues/20#issuecomment-297970303
-[15]:https://github.com/open-organization-ambassadors/open-org-it-culture/issues/29
-[16]:https://en.wikipedia.org/wiki/Linus%27s_Law
-[17]:https://opensource.com/open-organization/resources/culture-change
-[18]:https://opensource.com/open-organization/resources/culture-change
-[19]:https://opensource.com/user/10530/feed
-[20]:https://opensource.com/users/jhibbets
diff --git a/translated/talk/20170517 Security Debt is an Engineers Problem.md b/translated/talk/20170517 Security Debt is an Engineers Problem.md
deleted file mode 100644
index 5f7182d535..0000000000
--- a/translated/talk/20170517 Security Debt is an Engineers Problem.md
+++ /dev/null
@@ -1,103 +0,0 @@
-安全债务是工程师的问题
-============================================================
-
-
-
-
->Keziah Plattner of AirBnBSecurity.
-
-参加者上月在旧金山 Twitter 总部举办的 [WomenWhoCode Connect][5] 活动中了解到，就像组织会建立技术债务一样，如果他们不相应地计划，也会建立一个名为“安全债务”的东西，。
-
-安全性已经成为软件开发过程中每步的重要组成部分，甲骨文首席安全官，[Mary Ann Davidson][6]强调，在 [WomenWhoCode][8] 就 [Zassmin Montes de Oca][7] 开发人员的安全性进行了主旨演讲。
-
-在过去，除银行外，安全性几乎被所有人忽视。但安全性比以往任何时候都更重要，因为现在有这么多接入点。我们已经进入[物联网][9]的时代，窃贼可以劫持你的冰箱而看到你不在家。
-
-戴维森负责 Oracle 的保障，“我们确保为建立的一切构建安全性，无论是内部部署产品、云服务，甚至是设备，我们有支持小组建立在客户的网站并报告数据给我们，帮助我们做诊断 - 每件事情都必须对其进行安全保护。
-
-
-
-Plattner 与 #WWCConnect 人群交谈
-
-AirBnB 的 [Keziah Plattner][10] 在分组会议中回应了这个情绪。她说：“大多数开发商并不认为安全是他们的工作，但这必须改变。”
-
-她分享了工程师的四项基本安全原则。首先，安全债务是昂贵的。现在有很多谈论[技术债务][11]，她认为这些谈话应该也包括安全债务。
-
-Plattner 说：“这个历史态度是‘我们会稍后考虑安全’”。当公司抓住软件效率和增长的唾手可得的成果时，他们忽视了安全性，但最初的不安全设计可能在未来几年会引起问题。
-
-她说，很难为现有的脆弱系统增加安全性。即使你知道安全漏洞在哪里，并且已经预算了时间和资源进行更改，重新设计一个安全系统是耗时和困难的。
-
-她说，所以这是关键，从一开始就建立安全性。将安全性视为技术债务的一部分以避免这个问题。并涵盖所有可能性。
-
-根据 Plattner 说的，最重要的是难以让人们改变行为。没有人会自愿改变，她说，即使你指出新的行为更安全。我们都点点头。
-
-Davidson 说，工程师们需要开始考虑他们的代码如何被攻击，并从这个角度进行设计。她说她只有两个规则。第一个从不信任任何未验证的数据，规则二见规则一。
-
-她笑着说：“人们一直这样做。他们说：‘我的客户端给我发送数据，所以没有问题’， 不。。。”。
-
-Plattner说，安全的第二个关键是“永远不信任用户”。
-
-Davidson 说道：“我的工作是做专业的偏执狂。”她一直担心有人甚至无意中会破坏她的系统。这不是学术性的，最近有通过 IoT 设备的拒绝服务攻击。
-
-### Little Bobby Tables
-
-Plattner 说：“如果你安全计划的一部分是信任用户做正确的事情，那么无论你有什么其他安全措施，你系统本质上是不安全的。”
-
-她解释说，重要的是要清理所有的用户输入，如[ XKCD 漫画][12]中的那样，因为她的儿子的中间名是 “DropTable Students”，妈妈擦掉整个学校的数据库。
-
-所以清理所有的用户输入。检查。
-
-她展示了一个 JavaScript 开发者在开源中使用 eval 的例子。她警告说：“一个好的基本规则是‘从不使用 eval()’”。 [eval()] [13]函数会计算 JavaScript 代码。“如果你这样做，你正在向随机用户开放你的系统。”
-
-Davidson 警告说，她甚至将文档中的示例代码也包括在内。她笑着说：“因为我们都知道没有人复制示例代码”。她强调指出，任何代码都应进行安全检查。
-
-
-
-让它容易
-
-Plattner 的建议三：要使安全容易。她建议采取阻力最小的道路。
-
-对外，使用户选择选择安全而不是退出，或者更好使其成为强制性的。她说，改变人们的行为是科技中最难的问题。一旦用户习惯以非安全的方式使用你的产品，将来会变得非常困难。
-
-在公司内部，她建议制定标准化安全性的工具，因此这不是个别开发人员需要考虑的内容。例如，将数据加密为服务，这样工程师可以仅调用服务来加密或解密数据。
-
-她说，确保公司注重安全环境。在公司内切换到好的安全习惯。
-
-作为最薄弱的环节，只有你是安全，所以重要的是每个人都有良好的个人安全习惯，并具有良好的企业安全环境。
-
-在 Oracle，他们已经覆盖了。Davidson 表示，她厌倦了向没有安全培训的大学毕业的工程师解释安全性，所以她在 Oracle 写了第一个编码标准。现在有数百个页面以及很多贡献者，还有一些是强制性的课程。它们具有符合安全要求的度量标准。这些课程不仅适用于工程师，也适用于文档作者。她说：“这是一种文化。”
-
-没有提及密码的关于安全性的讨论将会是安全的？Plattner 说：“每个人都应该使用一个好的密码管理器，但在工作中应该是强制性的，还有双重身份验证。”
-
-她说，基本的密码原则应该是每个工程师清醒生活的一部分。密码中最重要的是它们的长度和熵 - 使按键的集合尽可能地随机。强健的密码熵检查器对此非常有用。她建议使用 Dropbox 开源熵检查器 [zxcvbn][14]。
-
-Plattner说，另一个诀窍是在验证用户输入时使用一些故意减慢速度的如 [bcrypt][15]。慢速并不困扰大多数合法用户，但会惹恼试图强行进行密码尝试的黑客。
-
-Davidson 说：“所有这些都为那些想要进入技术安全领域的人提供了工作安全保障，我们正在增加更多的代码，这就产生了系统性风险。只要我们继续在技术领域做有趣的事情, 我不认为任何人会没有一分安全工作。”
-
---------------------------------------------------------------------------------
-
-via: https://thenewstack.io/security-engineers-problem/
-
-作者：[TC Currie][a]
-译者：[geekpi](https://github.com/geekpi)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
-
-[a]:https://thenewstack.io/author/tc/
-[1]:http://twitter.com/share?url=https://thenewstack.io/security-engineers-problem/&text=Security+Debt+is+an+Engineer%E2%80%99s+Problem+
-[2]:http://www.facebook.com/sharer.php?u=https://thenewstack.io/security-engineers-problem/
-[3]:http://www.linkedin.com/shareArticle?mini=true&url=https://thenewstack.io/security-engineers-problem/
-[4]:https://thenewstack.io/security-engineers-problem/#disqus_thread
-[5]:http://connect2017.womenwhocode.com/
-[6]:https://www.linkedin.com/in/mary-ann-davidson-235ba/
-[7]:https://www.linkedin.com/in/zassmin/
-[8]:https://www.womenwhocode.com/
-[9]:https://www.thenewstack.io/tag/Internet-of-Things
-[10]:https://twitter.com/ittskeziah
-[11]:https://martinfowler.com/bliki/TechnicalDebt.html
-[12]:https://xkcd.com/327/
-[13]:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval
-[14]:https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/
-[15]:https://en.wikipedia.org/wiki/Bcrypt
-[16]:https://thenewstack.io/author/tc/
diff --git a/translated/talk/20170602 Why working openly is hard when you just want to get stuff done.md b/translated/talk/20170602 Why working openly is hard when you just want to get stuff done.md
new file mode 100644
index 0000000000..f6cb33fe9e
--- /dev/null
+++ b/translated/talk/20170602 Why working openly is hard when you just want to get stuff done.md
@@ -0,0 +1,118 @@
+当你只想将事情搞定时，为什么开放式工作这么难？
+============================================================
+
+### 学习使用开放式决策框架来写一本书
+
+
+>图片来源 : opensource.com
+
+GSD（get stuff done 的缩写，即搞定）指导着我的工作方式。数年来，我将各种方法论融入我日常工作的习惯中，包括精益方法的反馈循环，和敏捷开发的迭代优化，以此来更好地 GSD（如果把 GSD 当作动词的话）。这意味着我必须非常有效地利用我的时间：列出清晰，各自独立的目标；标记已完成的项目；用迭代的方式地持续推进项目进度。但是当我们默认使用开放的时仍然能够 GSD 吗？又或者 GSD 的方法完全行不通呢？大多数人都认为这会导致糟糕的状况，但我发现事实并不一定这样。
+
+在开放的环境中工作，遵循[开放式决策框架][6]中的指导，会让项目起步变慢。但是在最近的一个项目中，我们作出了一个决定，一个从开始就正确的决定：以开放的方式工作，并与我们的社群一起合作。
+
+关于开放式组织的资料
+
+* [下载《开放式组织 IT 文化变革指南》][1]
+* [下载《开放式组织领袖手册》][2]
+* [什么是开放式组织][3]
+* [什么是开放决策][4]
+
+这是我们能做的最好的决定。
+
+我们来看看这次经历带来的意想不到的结果，再看看我们如何将 GSD 思想融入开放式组织框架。
+
+### 建立社区
+
+2014 年 10 月，我接手了一个新的项目：当时红帽的 CEO Jim Whitehurst 即将推出一本新书《开放式组织》，我要根据书中提出的概念，建立一个社区。“太棒了，这听起来是一个挑战，我加入了！”我这样想。但不久，[冒牌者综合征][7]便出现了，我又开始想：“我们究竟要做什么呢？怎样才算成功呢？”
+
+让我剧透一下，在这本书的结尾处，Jim 鼓励读者访问 Opensource.com，继续探讨 21 世纪的开放和管理。所以，在 2015 年 5 月，我们的团队在网站上建立了一个新的板块来讨论这些想法。我们计划讲一些故事，就像我们在 Opensource.com 上常做的那样，只不过这次围绕着书中的观点与概念。之后，我们每周都发布新的文章，在 Twitter 上举办了一个在线的读书俱乐部，还将《开放式组织》打造成了系列书籍。
+
+我们内部独自完成了该系列书籍的前三期，每隔六个月发布一期。每完成一期，我们就向社区发布。然后我们继续完成下一期的工作，如此循环下去。
+
+这种工作方式，让我们看到了很大的成功。近 3000 人订阅了[该系列的新书][9]，《开放式组织领袖手册》。我们用 6 个月的周期来完成这个项目，这样新书的发行日正好是前书的两周年纪念日。
+
+在这样的背景下，我们完成这本书的方式是简单直接的：针对开放工作这个主题，我们收集了最好的故事，并将它们组织起来形成文章，招募作者填补一些内容上的空白，使用开源工具调整字体样式，与设计师一起完成封面，最终发布这本书。这样的工作方式使得我们能按照自己的时间线（GSD）全速前进。到[第三本书][10]时，我们的工作流已经基本完善了。
+
+然而这一切在我们计划开始《开放式组织》的最后一本书时改变了，这本书将重点放在开放式组织和 IT 文化的交融上。我提议使用开放式决策框架来完成这本书，因为我想通过这本书证明开放式的工作方法能得到更好的结果，尽管我知道这可能会完全改变我们的工作方式。时间非常紧张（只有两个半月），但我们还是决定试一试。
+
+### 用开放式决策框架来完成一本书
+
+开放式决策框架列出了组成开放决策制定过程的 4 个阶段。下面是我们在每个阶段中的工作情况（以及开放是如何帮助完成工作的）。
+
+### 1\. 构思
+
+我们首先写了一份草稿，罗列了对项目设想的愿景。我们需要拿出东西来和潜在的“顾客”分享（在这个例子中，“顾客”指潜在的利益相关者和作者）。然后我们约了一些领域专家面谈，这些专家能够给我们直接的诚实的意见。这些专家表现出的热情与他们提供的指导验证了我们的想法，同时提出了反馈意见使我们能继续向前。如果我们没有得到这些验证，我们会退回到我们最初的想法，再决定从哪里重新开始。
+
+### 2\. 计划与研究
+
+经过几次面谈，我们准备在 [Opensource.com 上公布这个项目][11]。同时，我们在 [Github 上也公布了这个项目][12], 提供了项目描述，预计的时间线，并阐明了我们所受的约束。这次公布得到了很好的效果，我们最初计划的目录中欠缺了一些内容，在项目公布之后的 72 小时内就被补充完整了。另外（也是更重要的），读者针对一些章节，提出了本不在我们计划中的想法，但是读者觉得这些想法能够补充我们最初设想的版本。
+
+我们体会到了 [Linus 法则][16]： "With more eyes, all _typos_ are shallow."
+
+回顾过去，我觉得在项目的第一和第二个阶段，开放项目并不会影响我们搞定项目的能力。事实上，这样工作有一个很大的好处：发现并填补内容的空缺。我们不只是填补了空缺，我们是迅速地就填补了空缺，并且还是用我们自己从未考虑过的点子。这并不一定要求我们做更多的工作，只是改变了我们的工作方式。我们动用有限的人脉，邀请别人来写作，再组织收到的内容，设置上下文，将人们导向正确的方向。
+
+### 3\. 设计，开发和测试
+
+项目的这个阶段完全围绕项目管理，管理一些像猫一样特立独行的人，并处理项目的预期。我们有明确的截止时间，我们提前沟通，频繁沟通。我们还使用了一个战略：列出了贡献者和利益相关者，在项目的整个过程中向他们告知项目的进度，尤其是我们在 Github 上标出的里程碑。
+
+最后，我们的书需要一个名字。我们收集了许多反馈，指出书名应该是什么，更重要的反馈指出了书名不应该是什么。我们通过 [Github 上的 issue][13] 收集反馈意见，并公开表示我们的团队将作最后的决定。当我们准备宣布最后的书名时，我的同事 Bryan Behrenshausen 做了很好的工作，[分享了我们作出决定的过程][14]。人们似乎对此感到高兴——即使他们不同意我们最后的书名。
+
+书的“测试”阶段需要大量的[校对][15]。社区成员真的参与到回答这个“求助”贴中来。我们在 GitHub issue 上收到了大约 80 条意见，汇报校对工作的进度（更不用说通过电子邮件和其他反馈渠道获得的许多额外的反馈）。
+
+关于搞定任务：在这个阶段，我们亲身体会了 [Linus 法则][16]："With more eyes, all _typos_ are shallow." 如果我们像前三本书一样自己独立完成，那么整个校对的负担就会落在我们的肩上（就像这些书一样）！相反，社区成员慷慨地帮我们承担了校对的重担，我们的工作从自己校对（尽管我们仍然做了很多工作）转向管理所有的 change requests。对我们团队来说，这是一个受大家欢迎的改变；对社区来说，这是一个参与的机会。如果我们自己做的话，我们肯定能更快地完成校对，但是在开放的情况下，我们在截止日期之前发现了更多的错误，这一点毋庸置疑。
+
+### 4\. Launch
+
+### 4\. 发布
+
+好了，我们现在推出了这本书的最终版本。（或者只是第一版？）
+
+遵循开放决策框架是《IT 文化变革指南》成功的关键。
+
+我们把发布分为两个阶段。首先，根据我们的公开的项目时间表，在最终日期之前的几天，我们安静地推出了这本书，以便让我们的社区贡献者帮助我们测试[下载表格][17]。第二阶段也就是现在，这本书的[通用版][18]的正式公布。当然，我们在发布后的仍然接受反馈，开源方式也正是如此。
+
+### 成就解锁
+
+遵循开放式决策框架是《IT 文化变革指南》成功的关键。通过与客户和利益相关者的合作，分享我们的制约因素，工作透明化，我们甚至超出了自己对图书项目的期望。
+
+我对整个项目中的合作，反馈和活动感到非常满意。虽然有一段时间内没有像我想要的那样快速完成任务，这让我有一种焦虑感，但我很快就意识到，开放这个过程实际上让我们能完成更多的事情。基于上面我的概述这一点显而易见。
+
+所以也许我应该重新考虑我的 GSD 心态，并将其扩展到 GMD：Get **more** done，搞定**更多**工作，并且就这个例子说，取得更好的结果。
+
+--------------------------------------------------------------------------------
+
+作者简介：
+
+Jason Hibbets - Jason Hibbets 是 Red Hat 企业营销中的高级社区传播者，也是 Opensource.com 的社区经理。 他自2003年以来一直在 Red Hat，并且是开源城市基金会的创立者。之前的职位包括高级营销专员，项目经理，Red Hat 知识库维护人员和支持工程师。
+
+-----------
+
+via: https://opensource.com/open-organization/17/6/working-open-and-gsd
+
+作者：[Jason Hibbets ][a]
+译者：[explosic4](https://github.com/explosic4)
+校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
+
+[a]:https://opensource.com/users/jhibbets
+[1]:https://opensource.com/open-organization/resources/culture-change?src=too_resource_menu
+[2]:https://opensource.com/open-organization/resources/leaders-manual?src=too_resource_menu
+[3]:https://opensource.com/open-organization/resources/open-org-definition?src=too_resource_menu
+[4]:https://opensource.com/open-organization/resources/open-decision-framework?src=too_resource_menu
+[5]:https://opensource.com/open-organization/17/6/working-open-and-gsd?rate=ZgpGc0D07SjGkTOf708lnNqbF_HvkhXTXeSzRKMhvVM
+[6]:https://opensource.com/open-organization/resources/open-decision-framework
+[7]:https://opensource.com/open-organization/17/5/team-impostor-syndrome
+[8]:https://opensource.com/open-organization/resources
+[9]:https://opensource.com/open-organization/resources/leaders-manual
+[10]:https://opensource.com/open-organization/resources/leaders-manual
+[11]:https://opensource.com/open-organization/17/3/announcing-it-culture-book
+[12]:https://github.com/open-organization-ambassadors/open-org-it-culture
+[13]:https://github.com/open-organization-ambassadors/open-org-it-culture/issues/20
+[14]:https://github.com/open-organization-ambassadors/open-org-it-culture/issues/20#issuecomment-297970303
+[15]:https://github.com/open-organization-ambassadors/open-org-it-culture/issues/29
+[16]:https://en.wikipedia.org/wiki/Linus%27s_Law
+[17]:https://opensource.com/open-organization/resources/culture-change
+[18]:https://opensource.com/open-organization/resources/culture-change
+[19]:https://opensource.com/user/10530/feed
+[20]:https://opensource.com/users/jhibbets
diff --git a/translated/tech/20170211 Docker swarm mode - Adding worker nodes tutorial.md b/translated/tech/20170211 Docker swarm mode - Adding worker nodes tutorial.md
deleted file mode 100644
index 224390f63e..0000000000
--- a/translated/tech/20170211 Docker swarm mode - Adding worker nodes tutorial.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Docker Sawrm 模式 - 添加 worker 节点教程
-
-让我们继续几周前在 CentOS 7.2 中开始的工作。 在本[指南][1]中，我们学习了如何初始化以及启动 Docker 1.12 中内置的本地集群以及编排功能。但是我们只有管理节点还没有其他 worker 节点。今天我们会展开这个。
-
-我将向你展示如何将不对称节点添加到 Sawrm 中，也就是 [Fedora 24][2] 将与 CentOS 相邻，它们都将加入到集群中，还有相关很棒的负载均衡等等。当然这并不是微不足道的，我们会遇到一些障碍，所以它应该是非常有趣的。
-
- 
-
-### 先决条件
-
-在将其他节点成功加入 Swarm 之前，我们需要做几件事情。理想情况下，所有节点都应该运行相同版本的 Docker，为了支持本地编排，它的版本至少应该为 1.12。像 CentOS 一样，Fedora 内置的仓库没有最新的构建，所以你需要手动或者使用 Docker 仓库手动[添加并安装][3]正确的版本，并修复一些依赖冲突。我已经向你展示了如何在 CentOS 中操作，练习是相同的。
-
-此外，所有节点都需要能够相互通信。这就需要有正确的路由和防火墙规则，这样管理和 worker 节点才能互相通信。否则，你无法将节点加入 Swarm 中。最简单的解决方法是临时刷新防火墙规则 （iptables -F），但这可能会损害你的安全。请确保你完全了解你正在做什么，并为你的节点和端口创建正确的规则。
-
-守护进程的错误响应：节点加入之前已超时。尝试加入 Swarm 的请求将在后台继续进行。使用 “docker info” 命令查看节点的当前 Swarm 状态。
-
-你需要在主机上提供相同的 Docker 镜像。在上一个教程中我们创建了一个 Apache 映像，你需要在你的 worker 节点上执行相同操作，或者分发创建的镜像。如果你不这样做，你会遇到错误。如果你在设置 Docker 上需要帮助，请阅读我的[介绍指南][4]和[网络教程][5]。
-
-```
-7vwdxioopmmfp3amlm0ulimcu \_ websky.11 my-apache2:latest
-localhost.localdomain Shutdown Rejected 7 minutes ago
-"No such image: my-apache2:lat&"
-```
-
-### 现在开始
-
-现在我们有一台 CentOS 机器并启动了，并成功创建了容器。你可以使用主机端口连接到服务，这一切都看起来很好。目前，你的 Swarm 只有管理节点。
-
- 
-
-### 加入 workers
-
-要添加新的节点，你需要使用 join 命令。但是你首先必须提供令牌、IP 地址和端口，以便 woker 节点能正确地对 Swarm 管理器进行身份验证。接着执行（在 Fedora 上）：
-
-```
-[root@localhost ~]# docker swarm join-token worker
-要将 worker 添加大这个 Swarm 中，运行下面的命令：
-
-docker swarm join \
---token SWMTKN-1-0xvojvlza90nrbihu6gfu3qm34ari7lwnza ... \
-192.168.2.100:2377
-```
-
-如果你不修复防火墙和路由规则，你会得到超时错误。如果你已经加入了 Swarm，重复 join 命令会收到错误：
-
-```
-Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.
-```
-
-如果有疑问，你可以离开 Swarm，然后重试：
-
-```
-[root@localhost ~]# docker swarm leave
-Node left the swarm.
-
-docker swarm join --token
-SWMTKN-1-0xvojvlza90nrbihu6gfu3qnza4 ... 192.168.2.100:2377
-This node joined a swarm as a worker.
-```
-
-在 worker 节点中，你可以使用 “docker info” 来检查状态：
-
-```
-Swarm: active
-NodeID: 2i27v3ce9qs2aq33nofaon20k
-Is Manager: false
-Node Address: 192.168.2.103
-
-Likewise, on the manager:
-
-Swarm: active
-NodeID: cneayene32jsb0t2inwfg5t5q
-Is Manager: true
-ClusterID: 8degfhtsi7xxucvi6dxvlx1n4
-Managers: 1
-Nodes: 3
-Orchestration:
-Task History Retention Limit: 5
-Raft:
-Snapshot Interval: 10000
-Heartbeat Tick: 1
-Election Tick: 3
-Dispatcher:
-Heartbeat Period: 5 seconds
-CA Configuration:
-Expiry Duration: 3 months
-Node Address: 192.168.2.100
-```
-
-### 创建或缩放服务
-
-现在，我们需要看下 Docker 是否以及如何在节点间分发容器。我的测试展示了一个在非常轻的负载下相当简单的平衡算法。试了一两次之后，即使在我尝试缩放并更新之后，Docker 也没有将运行的服务重新分配给新的 worker。同样，有一次，它在 worker 节点上创建了一个新的服务。也许这是最好的选择。
-
- 
-
- 
-
- 
-
- 
-
-在新的 worker 节点上创建完整新的服务。
-
-过了一段时间，两个容器之间的现有服务有一些重新分配，但这需要一些时间。新服务工作正常。这只是一个前期观察，所以我现在不能说更多。现在是开始探索和调整的新起点。
-
- 
-
-负载均衡过了一会工作了。
-
-### 总结
-
-Docker 是一只灵巧的小野兽，它只会继续扩大，更复杂，更强大，当然也更优雅。它被一个大企业吃掉只是一个时间问题。当它涉及本地编排时，Swarm 模式运行得很好，但是它不仅仅需要几个容器来充分利用其算法和可扩展性。
-
-我的教程展示了如何将 Fedora 节点添加到由 CentOS 运行的群集中，并且两者能并行工作。关于负载平衡还有一些问题，但这是我将在以后的文章中探讨的。总而言之，我希望这是一个值得记住的教训。我们已经解决了在尝试设置 Swarm 时可能遇到的一些先决条件和常见问题，同时我们启动了一堆容器，我们甚至简要介绍了如何缩放和分发服务。要记住，这只是一个开始。
-
-干杯。
-
-
---------------------------------------------------------------------------------
-
-作者简介：
-
-我是 Igor Ljubuncic。现在大约 38 岁，已婚但还没有孩子。我现在在一个大胆创新的云科技公司做首席工程师。直到大约 2015 年初，我还在一个全世界最大的 IT 公司之一中做系统架构工程师，和一个工程计算团队开发新的基于 Linux 的解决方案，优化内核以及攻克 Linux 的问题。在那之前，我是一个为高性能计算环境设计创新解决方案的团队的技术领导。还有一些其他花哨的头衔，包括系统专家、系统程序员等等。所有这些都曾是我的爱好，但从 2008 年开始成为了我的付费工作。还有什么比这更令人满意的呢？
-
-从 2004 年到 2008 年间，我曾通过作为医学影像行业的物理学家来糊口。我的工作专长集中在解决问题和算法开发。为此，我广泛地使用了 Matlab，主要用于信号和图像处理。另外，我得到了几个主要的工程方法学的认证，包括 MEDIC 六西格玛绿带、试验设计以及统计工程学。
-
-我也开始写书，包括奇幻类和 Linux 上的技术性工作。彼此交融。
-
-要查看我开源项目、出版物和专利的完整列表，请滚动到下面。
-
-有关我的奖项，提名和 IT 相关认证的完整列表，请稍等一下。
-
--------------
-
-
-via: http://www.dedoimedo.com/computers/docker-swarm-adding-worker-nodes.html
-
-作者：[Igor Ljubuncic][a]
-译者：[geekpi](https://github.com/geekpi)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
-
-[a]:http://www.dedoimedo.com/faq.html
-[1]:http://www.dedoimedo.com/computers/docker-swarm-intro.html
-[2]:http://www.dedoimedo.com/computers/fedora-24-gnome.html
-[3]:http://www.dedoimedo.com/computers/docker-centos-upgrade-latest.html
-[4]:http://www.dedoimedo.com/computers/docker-guide.html
-[5]:http://www.dedoimedo.com/computers/docker-networking.html
diff --git a/translated/tech/20170724 IoT Framework for Edge Computing Gains Ground.md b/translated/tech/20170724 IoT Framework for Edge Computing Gains Ground.md
deleted file mode 100644
index 4c0390c65d..0000000000
--- a/translated/tech/20170724 IoT Framework for Edge Computing Gains Ground.md
+++ /dev/null
@@ -1,51 +0,0 @@
-#IoT边缘计算框架的新进展
----
-
-
-开源项目 EdgeX Foundry 旨在开发一个标准化的互操作物联网边缘计算框架.[使用权限获取](https://www.linux.com/licenses/category/used-permission).
-
-在4月, Linux 基金组织[启动](http://linuxgizmos.com/open-source-group-focuses-on-industrial-iot-gateway-middleware/)了开发一个标准化互操作物联网边缘计算框架的开源项目[EdgeX Foundry](https://www.edgexfoundry.org/). 就在最近, EdgeX Foundry 又[宣布](https://www.edgexfoundry.org/announcement/2017/07/17/edgex-foundry-builds-momentum-for-a-iot-interoperability-and-a-unified-marketplace-with-eight-new-members/)新增 8 个成员, 其总成员达到 58.
-
-这些新成员是 Absolute, IoT Impact LABS, inwinStack, Parallel Machines, Queen's University Belfast, RIOT, Toshiba Digital Solutions Corporation, 和 Tulip Interfaces. 其原有成员包括 AMD, Analog Devices, Canonical/Ubuntu, Cloud Foundry, Dell, Linaro, Mocana, NetFoundry, Opto 22, RFMicron 和 VMWare 等其他公司或组织.
-
-戴尔贡献出其基于 Apache2.0 协议的[FUSE](https://medium.com/@gigastacey/dell-plans-an-open-source-iot-stack-3dde43f24feb)框架源码作为 EdgeX Foundry 项目的种子，其中包括十几个微服务和超过 12.5 万行代码. Linux 基金会和 Dell 将合并 FUSE 和 AllJoyn-compliant IoTX 项目, 后者是由现有 EdgeX Foundry 成员 Two Bulls 和 Beechwood 发起的与 FUSE 相似的一个项目. 待合并完成 Linux 基金组织将正式宣布启动 EdgeX Foundry 项目.
-
-EdgeX Foundry 将创造一个互操作性的, 即插即用的物联网边缘计算组件生态系统. 开源 EdgeX 栈将协调多样的传感器网络与后台数据处理云平台间的消息协议. 该框架旨在充分挖掘横跨边缘计算, 安全, 系统管理和微服务等模块间的通用代码.
-
-对于项目成员及其客户来说, 其关注焦点在于借助于 IoT 网关和智能边缘设备,预认证的软件可方便集成的可能性. 在 Linux.com 的一次采访中, [IoT Impact LABS](https://iotimpactlabs.com/) 的首席工程师, Dan Mahoney 说:"现实中, EdgeX Foundry 降低我们在部署囊括多供应商解决方案时所面对的挑战."
-
-Linux 基金组织,在将 AllSeen Alliance 的 AllJoyn 项目合并到 [IoTivity](https://www.linux.com/news/how-iotivity-and-alljoyn-could-combine) 的情况下, 为什么Linux基金组织发起了另外一个物联网标准化项目 (EdgeX Foundry)? 原因之一, EdgeX Foundry 不同于 IoTivity, IoTivity 主要解决工业物联网问题, 而 EdgeX Foundry 旨在一站解决消费级和工业级物联网全部的问题. 更具体来说, EdgeX Foundry 旨在成为网关和智能终端的通用中间件. EdgeX Foundry 与 IoTivity 的另一个不同在于, 前者希望借助预连接的终端塑造一种新产品, 后者更多解决现存产品之间的互操作性.
-
-Linux 基金会 IoT 高级总监 Philip DesAutels 说:"IoTivity 提供实现设备之间无缝连接的协议, 而 EdgeX Foundry 提供了一个边缘计算框架. EdgeX Foundry 能够兼容如 IoTivity, BacNet, EtherCat 等任何协议设备, 从而实现集成多协议通信系统的通用边缘计算框架, 该项目的目标是为构建互操作组件的生态系统的过程中, 降低不确定性, 缩短市场化时间, 更好地产生规模效应."
-
-上个月, 由 [Open Connectivity Foundation](https://openconnectivity.org/developer/specifications/international-standards) (OCF) 和 Linux 基金组织共同发起的 IoTivity项目发布了 [IoTivity 1.3](https://wiki.iotivity.org/release_note_1.3.0), 该版本增加 了与其曾经的对手 AllJoyn spec 的纽带, 也增加了对于 OCF 的 UPnP 设备的接口. 预计在 [IoTivity 2.0](https://www.linux.com/news/iotivity-20-whats-store) 中, IoTivity 和 AllJoyn 将会更进一步深入集成.
-
-DesAutels 告诉 linux.com, IoTivity 和 EdgeX 是高度互补的, 其原因是 EdgeX 项目和IoTivity 项目有好几个共同成员, 如此更强化了 IoTivity 和 EdgeX 的互补关系.
-
-尽管 IoTivity 和 EdgeX 都宣称是跨平台,包括 CPU 架构和 OS, 但是二者还是存在一定区别. IoTivity 最初是基于 Linux 平台设计, 兼容 Ubuntu, Tizen 和 Android 等 Linux 系列 OS, 后来逐步扩展到 Windows 和 IOS 操作系统. 与之对应的 EdgeX 设计之初就是基于跨平台的理念, 其完美兼容于各种 CPU 架构, 以及 Linux, Windows 和 Mac OS 等操作系统. 未来还将兼容于实时操作系统(RTOSes).
-
-EdgeX 的新成员 [RIOT](https://riot-os.org/) 提供了一个开源项目 RIOT RTOS. RIOT 的主要维护者 Thomas Eichinger 在一次重要报告时说:"由于 RIOT 初衷就是致力于解决 linux 不太适应的问题, 故对于 RIOT 社区来说,参加和支持类似于 EdgeX Foundry 等与 Linux 互补性社区的积极性是自然而然的."
-
-##传感器集成的简化
-IoT Impact LABS (也叫aka impact LABS 或直接称为 LABS) 是另一个 EdgeX 新成员. 该公司推出了一个独特的业务, 旨在帮助中小企业度过物联网解决方案的试用阶段. 该公司的大部分客户, 其中包括几个 EdgeX Foundry 的项目成员, 是致力于建设智慧城市, 基础设施再利用, 提高食品安全, 以及解决会社面临的自然资源缺乏的挑战.
-
-Dan Mahoney 说:"在 LABS 我们花费了很多时间来调和试点客户的解决方案之间的差异性. EdgeX Foundry 可以最小化部署边缘软件系统的工作量,从而使我们能够更快更好地部署高质量的解决方案."
-
-该框架在涉及多个供应商, 多种类型传感器的场景尤其凸显优势. "Edgex Foundry 将为我们提供快速构建网关的能力, 以及快速部署传感器的能力." Mahoney 补充说到. 传感器制造商将借助 EdgeX SDK 烧写应用层协议驱动到边缘设备, 该协议能够兼容多供应商和解决方案.
-
-##边缘分析能力的构建
-当我们问到, Mahoney 的公司想要见到 EdgeX Foundry 怎样的发展时, 他说:"我们喜见乐闻的一个目标是有更多有效的工业协议作为设备服务出现, 一个更清晰的边缘计算实现路径."
-
-在工业物联网和消费级物联网中边缘计算都呈现增长趋势. 在后者, 我们已经看到如 Alexa 的智能声控以及录像分析等几个智能家居系统集成了边缘计算分析技术. 这减轻了云服务平台的计算负荷, 但同时也带来了安全, 隐私, 以及由于政策和供应商中断引起的服务中断问题.
-
-对于工业物联网网关, 隐私问题成为首要的问题. 因此, 在物联网网关方面出现了一些类似于云服务功能的扩展. 其中一个解决方案是, 为了安全将一些云服务上的安全保障应用借助容器如 [RIOS 与 Ubuntu 内核快照机制](https://www.linux.com/news/future-iot-containers-aim-solve-security-crisis)等方式集成到嵌入式设备. 另一种方案是, 开发 IoT 系统迁移云功能到边缘. 上个月, Amazon 为基于 linux 的网关发布了实现 [AWS Greengrass](http://linuxgizmos.com/amazon-releases-aws-greengrass-for-local-iot-processing-on-linux-devices/) 物联网协议栈的 AWS lambda. 该软件能够使计算, 消息路由, 数据收集和同步能力在边缘设备上完成,如物联网网关.
-
-分析能力是 EdgeX Foundry 的一个关键功能要点. 发起成员 Cloud Foundry 是旨在集成其主要的工业应用平台到边缘设备. 另一个新成员 [Parallel Machines](https://www.parallelmachines.com/) 计划利用EdgeX将AI带到边缘设备.
-
-EdgeX Foundry 仍然在项目早期, 软件仍然在 α 阶段, 其成员在上个月才刚刚进行了第一次全体成员大会. 同时项目已经为新开发者准备了一些初始训练课程, 另外从[这里](https://wiki.edgexfoundry.org/)也能获取更多的信息.
-
-原文连接: [https://www.linux.com/blog/2017/7/iot-framework-edge-computing-gains-ground](https://www.linux.com/blog/2017/7/iot-framework-edge-computing-gains-ground)
-
-作者： [ERIC BROWN](https://www.linux.com/users/ericstephenbrown) 译者：penghuster 校对：校对者ID
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出