2017年9月

目录

  • break -- 在指定的行或函数处设置断点,缩写为 b
  • info breakpoints -- 打印未删除的所有断点,观察点和捕获点的列表,缩写为 i b
  • disable -- 禁用断点,缩写为 dis
  • enable -- 启用断点
  • clear -- 清除指定行或函数处的断点
  • delete -- 删除断点,缩写为 d
  • tbreak -- 设置临时断点,参数同 break,但在程序第一次停住后会被自动删除
  • watch -- 为表达式(或变量)设置观察点,当表达式(或变量)的值有变化时,暂停程序执行
  • step -- 单步跟踪,如果有函数调用,会进入该函数,缩写为 s
  • reverse-step -- 反向单步跟踪,如果有函数调用,会进入该函数
  • next -- 单步跟踪,如果有函数调用,不会进入该函数,缩写为 n
  • reverse-next -- 反向单步跟踪,如果有函数调用,不会进入该函数
  • return -- 使选定的栈帧返回到其调用者
  • finish -- 执行直到选择的栈帧返回,缩写为 fin
  • until -- 执行直到达到当前栈帧中当前行后的某一行(用于跳过循环、递归函数调用),缩写为 u
  • continue -- 恢复程序执行,缩写为 c
  • print -- 打印表达式 EXP 的值,缩写为 p
  • x -- 查看内存
  • display -- 每次程序停止时打印表达式 EXP 的值(自动显示)
  • info display -- 打印早先设置为自动显示的表达式列表
  • disable display -- 禁用自动显示
  • enable display -- 启用自动显示
  • undisplay -- 删除自动显示项
  • help -- 打印命令列表(带参数时查找命令的帮助),缩写为 h
  • attach -- 挂接到已在运行的进程来调试
  • run -- 启动被调试的程序,缩写为 r
  • backtrace -- 查看程序调用栈的信息,缩写为 bt
  • ptype -- 打印类型 TYPE 的定义

break

使用 break 命令(缩写 b)来设置断点。

用法:

  • break 当不带参数时,在所选栈帧中执行的下一条指令处设置断点。
  • break <function-name> 在函数体入口处打断点,在 C++ 中可以使用 class::functionfunction(type, ...) 格式来指定函数名。
  • break <line-number> 在当前源码文件指定行的开始处打断点。
  • break -N break +N 在当前源码行前面或后面的 N 行开始处打断点,N 为正整数。
  • break <filename:linenum> 在源码文件 filenamelinenum 行处打断点。
  • break <filename:function> 在源码文件 filenamefunction 函数入口处打断点。
  • break <address> 在程序指令的地址处打断点。
  • break ... if <cond> 设置条件断点,... 代表上述参数之一(或无参数),cond 为条件表达式,仅在 cond 值非零时暂停程序执行。

详见官方文档

info breakpoints

查看断点,观察点和捕获点的列表。

用法:

  • info breakpoints [list...]
  • info break [list...]
  • list... 用来指定若干个断点的编号(可省略),可以是 21-32 5 等。

disable

禁用一些断点。参数是用空格分隔的断点编号。要禁用所有断点,不加参数。

禁用的断点不会被忘记,但直到重新启用才有效。

用法:

  • disable [breakpoints] [list...]
  • breakpointsdisable 的子命令(可省略),list...info breakpoints 中的描述。

详见官方文档

enable

启用一些断点。给出断点编号(以空格分隔)作为参数。没有参数时,所有断点被启用。

用法:

  • enable [breakpoints] [list...] 启用指定的断点(或所有定义的断点)。
  • enable [breakpoints] once list... 临时启用指定的断点。GDB 在停止您的程序后立即禁用这些断点。
  • enable [breakpoints] delete list... 使指定的断点启用一次,然后删除。一旦您的程序停止,GDB 就会删除这些断点。等效于用 tbreak 设置的断点。

breakpointsdisable 中的描述。

详见官方文档

clear

在指定行或函数处清除断点。参数可以是行号,函数名称或 * 跟一个地址。

用法:

  • clear 当不带参数时,清除所选栈帧在执行的源码行中的所有断点。
  • clear <function>, clear <filename:function> 删除在命名函数的入口处设置的任何断点。
  • clear <linenum>, clear <filename:linenum> 删除在指定的文件指定的行号的代码中设置的任何断点。
  • clear <address> 清除指定程序指令的地址处的断点。

详见官方文档

delete

删除一些断点或自动显示表达式。参数是用空格分隔的断点编号。要删除所有断点,不加参数。

用法: delete [breakpoints] [list...]

详见官方文档

tbreak

设置临时断点。参数形式同 break 一样。

除了断点是临时的之外,其他同 break 一样,所以在命中时会被删除。

详见官方文档

watch

为表达式设置观察点。

用法: watch [-l|-location] <expr> 每当一个表达式的值改变时,观察点就会暂停程序执行。

如果给出了 -l 或者 -location,则它会对 expr 求值并观察它所指向的内存。例如,watch *(int *)0x12345678 将在指定的地址处观察一个 4 字节的区域(假设 int 占用 4 个字节)。

详见官方文档

step

单步执行程序,直到到达不同的源码行。

用法: step [N] 参数 N 表示执行 N 次(或由于另一个原因直到程序停止)。

警告:如果当控制在没有调试信息的情况下编译的函数中使用 step 命令,则执行将继续进行,直到控制到达具有调试信息的函数。 同样,它不会进入没有调试信息编译的函数。

要执行没有调试信息的函数,请使用 stepi 命令,详见后文。

详见官方文档

reverse-step

反向单步执行程序,直到到达另一个源码行的开头。

用法: reverse-step [N] 参数 N 表示执行 N 次(或由于另一个原因直到程序停止)。

详见官方文档

next

单步执行程序,执行完子程序调用。

用法: next [N]

step 不同,如果当前的源代码行调用子程序,则此命令不会进入子程序,而是将其视为单个源代码行,继续执行。

详见官方文档

reverse-next

反向步进程序,执行完子程序调用。

用法: reverse-next [N]

如果要执行的源代码行调用子程序,则此命令不会进入子程序,调用被视为一个指令。

参数 N 表示执行 N 次(或由于另一个原因直到程序停止)。

详见官方文档

return

您可以使用 return 命令取消函数调用的执行。如果你给出一个表达式参数,它的值被用作函数的返回值。

用法: return <expression>expression 的值作为函数的返回值并使函数直接返回。

详见官方文档

finish

执行直到选定的栈帧返回。

用法: finish 返回后,返回的值将被打印并放入到值历史记录中。

详见官方文档

until

执行直到程序到达当前栈帧中当前行之后(与 break 命令相同的参数)的源码行。此命令用于通过一个多次的循环,以避免单步执行。

用法:until <location>u <location> 继续运行程序,直到达到指定的位置,或者当前栈帧返回。

详见官方文档

continue

在信号或断点之后,继续运行被调试的程序。

用法: continue [N] 如果从断点开始,可以使用数字 N 作为参数,这意味着将该断点的忽略计数设置为 N - 1(以便断点在第 N 次到达之前不会中断)。如果启用了非停止模式(使用 show non-stop 查看),则仅继续当前线程,否则程序中的所有线程都将继续。

详见官方文档

print

求值并打印表达式 EXP 的值。可访问的变量是所选栈帧的词法环境,以及范围为全局或整个文件的所有变量。

用法:

  • print [expr]print /f [expr] expr 是一个(在源代码语言中的)表达式。

默认情况下,expr 的值以适合其数据类型的格式打印;您可以通过指定 /f 来选择不同的格式,其中 f 是一个指定格式的字母;详见输出格式

如果省略 expr,GDB 再次显示最后一个值。

要以每行一个成员带缩进的格式打印结构体变量请使用命令 set print pretty on,取消则使用命令 set print pretty off

可使用命令 show print 查看所有打印的设置。

详见官方文档

x

检查内存。

用法: x/nfu <addr>x <addr> nfu 都是可选参数,用于指定要显示的内存以及如何格式化。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 个内存值。

详见官方文档

display

每次程序暂停时,打印表达式 EXP 的值。

用法: display <expr>, display/fmt <expr>display/fmt <addr> fmt 用于指定显示格式。像 print 命令里的 /f 一样。

对于格式 is,或者包括单位大小或单位数量,将表达式 addr 添加为每次程序停止时要检查的内存地址。

详见官方文档

info display

打印自动显示的表达式列表,每个表达式都带有项目编号,但不显示其值。

包括被禁用的表达式和不能立即显示的表达式(当前不可用的自动变量)。

undisplay

取消某些表达式在程序暂停时的自动显示。参数是表达式的编号(使用 info display 查询编号)。不带参数表示取消所有自动显示表达式。

delete display 具有与此命令相同的效果。

disable display

禁用某些表达式在程序暂停时的自动显示。禁用的显示项目不会被自动打印,但不会被忘记。 它可能稍后再次被启用。

参数是表达式的编号(使用 info display 查询编号)。不带参数表示禁用所有自动显示表达式。

enable display

启用某些表达式在程序暂停时的自动显示。

参数是重新显示的表达式的编号(使用 info display 查询编号)。不带参数表示启用所有自动显示表达式。

help

打印命令列表。

您可以使用不带参数的 help(缩写为 h)来显示命令的类别名的简短列表。

使用 help <class> 您可以获取该类中的各个命令的列表。使用 help <command> 显示如何使用该命令。

详见官方文档

attach

挂接到 GDB 之外的进程或文件。该命令可以将进程 ID 或设备文件作为参数。

对于进程 ID,您必须具有向进程发送信号的权限,并且必须具有与调试器相同的有效的 uid。

用法: attach <process-id> GDB 在安排调试指定的进程之后做的第一件事是暂停该进程。

无论是通过 attach 命令挂接的进程还是通过 run 命令启动的进程,您都可以使用的 GDB 命令来检查和修改挂接的进程。

详见官方文档

run

启动被调试的程序。

可以直接指定参数,也可以用 set args 设置(启动所需的)参数。

例如: run arg1 arg2 ... 等效于

set args arg1 arg2 ...
run

还允许使用 ><>> 进行输入和输出重定向。

详见官方文档

backtrace

打印整体栈帧信息。

  • bt 打印整体栈帧信息,每个栈帧一行。
  • bt n 类似于上,但只打印最内层的 n 个栈帧。
  • bt -n 类似于上,但只打印最外层的 n 个栈帧。
  • bt full n 类似于 bt n,还打印局部变量的值。

whereinfo stack(缩写 info s) 是 backtrace 的别名。调用栈信息类似如下:

(gdb) where
#0  vconn_stream_run (vconn=0x99e5e38) at lib/vconn-stream.c:232
#1  0x080ed68a in vconn_run (vconn=0x99e5e38) at lib/vconn.c:276
#2  0x080dc6c8 in rconn_run (rc=0x99dbbe0) at lib/rconn.c:513
#3  0x08077b83 in ofconn_run (ofconn=0x99e8070, handle_openflow=0x805e274 <handle_openflow>) at ofproto/connmgr.c:1234
#4  0x08075f92 in connmgr_run (mgr=0x99dc878, handle_openflow=0x805e274 <handle_openflow>) at ofproto/connmgr.c:286
#5  0x08057d58 in ofproto_run (p=0x99d9ba0) at ofproto/ofproto.c:1159
#6  0x0804f96b in bridge_run () at vswitchd/bridge.c:2248
#7  0x08054168 in main (argc=4, argv=0xbf8333e4) at vswitchd/ovs-vswitchd.c:125

详见官方文档

ptype

打印类型 TYPE 的定义。

用法: ptype[/FLAGS] TYPE-NAME | EXPRESSION

参数可以是由 typedef 定义的类型名, 或者 struct STRUCT-TAG 或者 class CLASS-NAME 或者 union UNION-TAG 或者 enum ENUM-TAG

根据所选的栈帧的词法上下文来查找该名字。

类似的命令是 whatis,区别在于 whatis 不展开由 typedef 定义的数据类型,而 ptype 会展开,举例如下:

/* 类型声明与变量定义 */
typedef double real_t;
struct complex {
    real_t real;
    double imag;
};
typedef struct complex complex_t;

complex_t var;
real_t *real_pointer_var;

这两个命令给出了如下输出:

(gdb) whatis var
type = complex_t
(gdb) ptype var
type = struct complex {
    real_t real;
    double imag;
}
(gdb) whatis complex_t
type = struct complex
(gdb) whatis struct complex
type = struct complex
(gdb) ptype struct complex
type = struct complex {
    real_t real;
    double imag;
}
(gdb) whatis real_pointer_var
type = real_t *
(gdb) ptype real_pointer_var
type = double *

详见官方文档


参考资料


译者:robot527 校对:mudongliangwxy

开源项目 EdgeX Foundry 旨在开发一个标准化的互操作物联网边缘计算框架。

4 月份时, Linux 基金组织启动了一个开源项目 EdgeX Foundry ,用于为物联网边缘计算开发一个标准化互操作框架。 就在最近, EdgeX Foundry 又宣布新增了 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 物联网中间件框架之上,其中包括十几个微服务和超过 12.5 万行代码。在 FUSE 合并了类同项目 AllJoyn-compliant IoTX 之后,Linux 基金会协同 Dell 创立了 EdgeX Foundry ,后者是由 EdgeX Foundry 现有成员 Two Bulls 和 Beechwood 发起的项目。

EdgeX Foundry 将创造一个互操作性的、即插即用组件的物联网边缘计算的生态系统。开源的 EdgeX 栈将协调各种传感器网络协议与多种云平台及分析平台。该框架旨在充分挖掘横跨边缘计算、安全、系统管理和服务等模块间的互操作性代码。

对于项目成员及其客户来说,其关键的好处是在于能将各种预先认证的软件集成到许多 IoT 网关和智能边缘设备上。 在 Linux.com 的一次采访中,IoT Impact LABS 的首席工程师 Dan Mahoney 说:“现实中,EdgeX Foundry 降低了我们在部署多供应商解决方案时所面对的挑战。”

在 Linux 基金会仍然将其 AllSeen Alliance 项目下的 AllJoyn 规范合并到 IoTivity 标准的情况下,为什么会发起了另外一个物联网标准化项目(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 (OCF)和 Linux 基金组织共同发起的 IoTivity 项目发布了 IoTivity 1.3,该版本增加了与其曾经的对手 AllJoyn spec 的纽带,也增加了对于 OCF 的 UPnP 设备发现标准的接口。 预计在 IoTivity 2.0 中, 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 提供了一个开源的面向物联网的项目 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 的智能声控以及录像分析等几个智能家居系统集成了边缘计算分析技术。 这减轻了云服务平台的计算负荷,但同时也带来了安全、隐私,以及由于供应商中断或延迟问题引起的服务中断问题。

对于工业物联网网关,延迟问题成为首要的问题。因此,在物联网网关方面出现了一些类似于云服务功能的扩展。 其中一个解决方案是,为了安全将一些云服务上的安全保障应用借助容器如 RIOS 与 Ubuntu 内核快照机制等方式集成到嵌入式设备。 另一种方案是,开发 IoT 生态系统,迁移云功能到边缘计算上。上个月,Amazon 为基于 linux 的网关发布了实现 AWS Greengrass 物联网协议栈的 AWS lambda。 该软件能够使 AWS 计算、消息路由、数据缓存和同步能力在诸如物联网网关等联网设备上完成。

分析能力是 EdgeX Foundry 发展路线上的一个关键功能要点。 发起成员之一 Cloud Foundry 其旨在集成其主要的工业应用平台到边缘设备。 另一个新成员 Parallel Machines 则计划利用 EdgeX 将 AI 带到边缘设备。

EdgeX Foundry 仍然在项目早期, 软件仍然在 α 阶段,其成员在上个月(六月份)才刚刚进行了第一次全体成员大会。同时该项目已经为新开发者准备了一些初始训练课程,另外从这里也能获取更多的信息。


via: https://www.linux.com/blog/2017/7/iot-framework-edge-computing-gains-ground

作者: ERIC BROWN 译者:penghuster 校对:wxy

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

不断变化的社会和文化条件正促使着开放的领导。

 title=

领导力就是力量。更具体地说,领导力是影响他人行动的力量。 关于领导力的神话不仅可以让人联想到人类浪漫的一面而且还有人类境况险恶的一面。 我们最终决定如何领导才能决定其真正的本质。

现代许多对领导力的理解都是在战争中诞生的,在那里,领导力意味着熟练地执行命令和控制思想。 在现代商业的大部分时间里,我们都是以一个到达权力顶峰的伟大的男人或女人作为领导,并通过地位来发挥力量的。 这种传统的通过等级和报告关系的领导方式严重依赖于正式的权威。 这些结构中的权威通过垂直层次结构向下流动,并沿命令链的形式存在。

然而,在 20 世纪后期,一些东西开始改变。 新技术打开了全球化的大门,从而使团队更加分散。 我们投入人力资本的方式开始转变,永远地改变了人们之间的沟通方式。组织内部的人开始感觉得到了责任感,他们要求对自己的成功(和失败)拥有归属感。 领导者不再是权力的唯一拥有者。 21世纪的领导者带领 21 世纪的组织开始了解授权、协作、责任和清晰的沟通是一种新型权力的本质。 这些新领导人开始分享权力——他们无保留地信任他们的追随者。

随着组织继续变得更加开放,即使是没有“领导力”头衔的人也会感到有责任推动变革。 这些组织消除了等级制度的枷锁,让工人们以他们认为合适的方式去工作。 历史暴露了 20 世纪领导人倾向通过单边决策和单向信息流来扼杀敏捷性。 但是,新世纪的领导者却是确定一个组织,让由它授权的若干个体来完成一些事情。 重点是权力赋予若干个体——坦率地说,一个领导者不能在任何时候出现在所有的地方,做出所有的决定。

因此,领导人也开始变得开放。

控制

当旧式领导人专注于指挥和控制的地位权力时,一个开放的领导者通过新形式的组织管理方式、新技术和其他减少摩擦的方式,将组织控制权放在了其它人身上,这样可以更有效的方式实现集体行动的方式。 这些领导者了解信任的力量,相信追随者总是会表现出主动性、参与性和独立性。 而这种新的领导方式需要在战术上有所转变——从告诉人们如何去做,到向他们展示如何去做,并在路上指导他们。开放的领导人很快就发现,领导力不是影响我们发挥进步的力量,而是我们在组织成员中分配的力量和信心。 21 世纪的领导者专注于社区和对他人的教化。最后,开放的领导者并不是专注于自我,而是无私的。

交流

20 世纪的领导者人组织并控制整个组织的信息的流动。 然而,开放的领导者试图通过与团队成员共享信息和背景(以及权力)来组织一个组织。 这些领导人摧毁了领地,谦逊前行,分享着前所未有的力量。 集体赋权和参与的协作创造了灵活性,分担责任,所有权,尤其是幸福。 当一个组织的成员被授权做他们的工作时,他们比等级层次的同事更快乐(因而更有生产力)。

信任

开放的领导者接受不确定性,相信他们的追随者在正确的时间做正确的事情。 他们拥有比传统对手,有更高的吸引人力资本效率的能力。 再说一次:他们不会像命令和控制的微观管理者那样运作。 提高透明度,而不是暗箱操作,他们尽可能的把决策和行动放在公开场合,解释决策的基础,并假设员工对组织内的情况有高度的把握。开放领导者的操作的前提是,如果没有他们的持续干预,该组织的人力资本就更有能力取得成功。

自治权

在 20 世纪具有强大指挥和控制力的领导者专注于某些权力的时候,一个开放的领导者更多地关注组织内个人的实际活动。 当领导者专注于个人时,他们就能够更好地训练和指导团队成员。 从这个角度来看,一个开放的领导者关注的是与组织的愿景和使命一致的行为和行动。最后,一个开放的领导者被看作是团队中的一员,而不是团队的领导者。 这并不意味着领导人放弃了权力的地位,而是低估了这一点,以分享权力,并通过自主创造成果赋予个人权力。

赋权

开放的领导人把重点放在授予组织成员的权力上。 在这个过程中承认领导者在组织人力资本中的技能、能力和信任,从而为整个团队带来了积极的动力和意愿。 最终,赋权就是帮助追随者相信他们自己的能力。 那些相信自己拥有个人权力的追随者更有可能采取主动行动、制定和实现更高的目标,并在困难的环境下坚持下去。 最终,开放组织的概念是关于包容性,每个人都是属于自己的,个性和不同的观点对于成功是至关重要的。 一个开放的组织及其开放的领导者提供了一种社区的感觉,而成员则受到组织的使命或目的的驱动。 这会产生一种比个人更大的归属感。 个性创造了成员之间的幸福和工作满意度。 反过来,又实现了更高的效率和成功。

我们都应该为 21 世纪领导人所要求的开放性而努力。 这需要自我反省,好奇心,尤其是它正在进行的改变。 通过新的态度和习惯,我们逐渐发现了一个真正的开放领导者,并且希望我们在适应 21 世纪的领导风格的同时,也开始采纳这些理念。

是的,领导力就是力量。我们如何利用这种权力决定了我们组织的成败。 那些滥用权力的人不会持久,但那些分享权力和庆祝他人的人会更持久。 通过阅读 这本书,你可以在开放组织及其领导的持续对话中开始发挥重要作用。 在本卷的结论中,您将找到与开放组织社区联系的额外资源和机会,以便您也可以与我们聊天、思考和成长。 欢迎来到谈话——欢光临!

这篇文章最初是作为《开放组织领导手册》的引言出现的,它现在可以从 Opensource.com 中可获得

( 题图: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 译者:TimeBear 校对:wxy

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

就在几个小时前,Facebook 宣布,将在下周发布的 React 16 会以 MIT 许可证重新授权,以应对社区对之前的 BSD + 专利许可模式的不安。

Facebook 负责 React 和 GraphQL 等产品的产品架构组工程总监 Adam Wolff 写道:

“下周,我们将以 MIT 许可证对我们的开源项目 React、Jest、Flow 和 Immutable.js 重新进行许可。我们重新许可这些项目是因为 React 是广泛的互联网开源软件生态的基石,我们并不想因非技术原因而阻碍其前行的道路。”

React.js 是 Facebook 推出的一个用来构建用户界面的 JavaScript 库,起源于 Facebook 的内部项目,用来架设 Instagram 的网站。

  • 2013 年 5 月,Facebook 将 React.js 开源
  • 2016 年 7 月,React.js 开源许可协议中的附加专利条款引发争议。
  • 2016 年 11 月,Facebook 发布官方问答,对附加专利条款进行澄清。
  • 2017 年 7 月,Apache 基金会禁止使用遵循 BSD 许可证 + 专利开源协议的 JAR 包。

在 Apache 基金会将 React 这样的采用 BSD 许可证 + 专利条款的软件列入“X 类别”之后,社区再次引发了对此问题强烈关注,并导致很多大型的互联网公司开始绸缪放弃和替换 React——尤其是在 WordPress 宣布将重写其软件,剥离对 React 的依赖之后达到了顶峰。而国内的互联网公司,如百度、阿里,也纷纷有传言将追随这一动作,弃用 React。

迫于这种压力,Facebook 决定对 React 等开源项目放弃其原有的 BSD 许可证 + 专利条款的许可模式,虽然他们认为“BSD 许可证 + 专利条款为项目的用户提供了一些好处”,但是他们也“承认没能说服社区接受这一许可模式”。

在感受到这一许可证的不确定性风险之后,许多团队开始选择替代性的产品。Facebook 对此感到抱歉,对 React 重新许可虽然不一定能赢得这些团队回心转意,但是还是“希望将这扇门继续打开”。

这一转变自然也会引起人们对 Facebook 其它的开源项目的质疑,因为目前 Facebook 许多流行的开源项目都采用的是 BSD 许可 + 专利条款方式。但是他们会“重新评估这些项目的许可证,而每个项目的情况有所不同,替换许可证取决于各种因素”。下周,除了 React 之外,Facebook 也将对 Jest、Flow 和 Immutable.js 等开源项目进行重新许可。

这一许可证的变化将随着下周即将发布的 React 16 一起更新。React 16 已经开发了一年,内部进行完全重写,解锁了强大的功能,让每个人都可以用它来构建大规模的用户界面。

Adam Wolff 表示,将许可证的讨论放到后面,无论大家用不用 React ,希望它都可以给开发者以灵感,毕竟,我们最关心的是:交付伟大的产品。

让我们继续几周前在 CentOS 7.2 中开始的工作。 在本指南中,我们学习了如何初始化以及启动 Docker 1.12 中内置的原生的集群以及编排功能。但是我们只有 管理者 manager 节点还没有其它 工作者 worker 节点。今天我们会展开讲述这个。

我将向你展示如何将不对称节点添加到 Sawrm 中,比如一个与 CentOS 相邻的 Fedora 24,它们都将加入到集群中,还有相关很棒的负载均衡等等。当然这并不是轻而易举的,我们会遇到一些障碍,所以它应该是非常有趣的。

Teaser

先决条件

在将其它节点成功加入 Swarm 之前,我们需要做几件事情。理想情况下,所有节点都应该运行相同版本的 Docker,为了支持原生的编排功能,它的版本至少应该为 1.12。像 CentOS 一样,Fedora 内置的仓库没有最新的构建版本,所以你需要手动构建,或者使用 Docker 仓库手动添加和安装正确的版本,并修复一些依赖冲突。我已经向你展示了如何在 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 上需要帮助,请阅读我的介绍指南网络教程

7vwdxioopmmfp3amlm0ulimcu   \_ websky.11   my-apache2:latest
localhost.localdomain   Shutdown   Rejected 7 minutes ago
"No such image: my-apache2:lat&"

现在开始

现在我们有一台启动了 CentOS 机器,并成功地创建了容器。你可以使用主机端口连接到该服务,这一切都看起来很好。目前,你的 Swarm 只有 管理者 manager

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 节点上创建了一个新的服务。也许这是最好的选择。

Scale service

Service ls

Services ls, more

New service

在新的 工作者 worker 节点上完整创建新的服务。

过了一段时间,两个容器之间的现有服务有一些重新分配,但这需要一些时间。新服务工作正常。这只是一个前期观察,所以我现在不能说更多。现在是开始探索和调整的新起点。

Service distributed

负载均衡过了一会工作了。

总结

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 译者:geekpi 校对:wxy

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

在上个月旧金山 Twitter 总部举办的 WomenWhoCode Connect 活动中参会者了解到,就像组织会形成技术债务一样,如果他们不相应地计划,也会形成一个名为“安全债务”的东西。

甲骨文首席安全官 Mary Ann DavidsonWomenWhoCodeZassmin Montes de Oca 在一个面对开发人员的安全性的主题谈话中强调,安全性已经成为软件开发过程中每步的重要组成部分,

在过去,除银行外,安全性几乎被所有人忽视。但安全性比以往任何时候都更重要,因为现在有这么多接入点。我们已经进入物联网的时代,窃贼可以通过劫持你的冰箱而了解到你不在家的情况。

Davidson 负责 Oracle 的保障,“我们确保为建立的一切构建安全性,无论是内部部署产品、云服务,甚至是设备,我们在客户的网站建立有支持小组并报告数据给我们,帮助我们做诊断 - 每件事情都必须对其进行安全保护。”

AirBnB 的 Keziah Plattner 在分组会议中回应了这个看法。她说:“大多数开发者并不认为安全是他们的工作,但这必须改变。”

她分享了工程师的四项基本安全原则。首先,安全债务是昂贵的。现在有很多人在谈论技术债务,她认为这些谈话应该也包括安全债务。

Plattner 说:“历史上这个看法是‘我们会稍后考虑安全’”。当公司抓住软件效率和增长的唾手可得的成果时,他们忽视了安全性,但最初的不安全设计可能在未来几年会引发问题。

她说,很难为现有的脆弱系统增加安全性。即使你知道安全漏洞在哪里,并且有进行更改的时间和资源的预算,重新设计一个安全系统也是耗时和困难的。

她说,所以这就是关键,从一开始就建立安全性。将安全性视为技术债务的一部分以避免这个问题,并涵盖所有可能性。

根据 Plattner 说的,最重要的是难以让人们改变行为。没有人会自愿改变,她说,即使你指出新的行为更安全。他们也只不过是点点头而已。

Davidson 说,工程师们需要开始考虑他们的代码如何被攻击,并从这个角度进行设计。她说她只有两个规则。第一个从不信任任何未验证的数据;规则二参见规则一。

她笑着说:“人们一直这样做。他们说:‘我的客户端给我发送数据,所以没有问题’。千万不要……”。

Plattner说,安全的第二个关键是“永远不信任用户”。

Davidson 以另外一种说法表示:“我的工作是做专业的偏执狂。”她一直担心有人或许无意中会破坏她的系统。这不是学术性的考虑,最近已经有通过 IoT 设备的拒绝服务攻击。

Little Bobby Tables

Plattner 说:“如果你安全计划的一部分是信任用户做正确的事情,那么无论你有什么其他安全措施,你系统本质上是不安全的。”

她解释说,重要的是要净化所有的用户输入,如 XKCD 漫画中的那样,一位妈妈干掉整个学校的数据库——因为她的儿子的中间名是 “DropTable Students”(LCTT 译注:看不懂的点这里)。

所以净化所有的用户输入。你一定检查一下。

她展示了一个 JavaScript 开发者在开源软件中使用 eval 的例子。她警告说:“一个好的基本规则是‘从不使用 eval()’”。 eval() 函数会执行 JavaScript 代码。“如果你这样做,你正在向任意用户开放你的系统。”

Davidson 警告说,她甚至偏执到将文档中的示例代码的安全测试也包括在内。她笑着说:“我们都知道没有人会去复制示例代码”。她强调指出,任何代码都应进行安全检查。

Plattner 的第三个建议:要使安全容易实施。她建议采取阻力最小的道路。

对外,使用户 默认采用 option out 安全措施而不是 可选采用 option in ,或者更好使其成为强制性的措施。她说,改变人们的行为是科技中最难的问题。一旦用户习惯以非安全的方式使用你的产品,让他们改进会变得非常困难。

在公司内部,她建议制定安全标准,因此这不是个别开发人员需要考虑的内容。例如,将数据加密作为服务,这样工程师可以只需要调用服务就可以加密或解密数据。

她说,确保公司注重安全环境。在让整个公司切换到好的安全习惯。

你的安全短板决定了你的安全水准,所以重要的是每个人都有良好的个人安全习惯,并具有良好的企业安全环境。

在 Oracle,他们已经全面覆盖安全的各个环节。Davidson 表示,她厌倦了向没有安全培训的大学毕业的工程师解释安全性,所以她写了 Oracle 的第一个编码标准,现在已经有数百个页面之多以及很多贡献者,还有一些课程是强制性的。它们具有符合安全要求的度量标准。这些课程不仅适用于工程师,也适用于文档作者。她说:“这是一种文化。”

没有提及密码的关于安全性的讨论怎么能是安全的?Plattner 说:“每个人都应该使用一个好的密码管理器,在工作中应该是强制性的,还有双重身份验证。”

她说,基本的密码原则应该是每个工程师日常生活的一部分。密码中最重要的是它们的长度和熵(使按键的集合尽可能地随机)。强健的密码熵检查器对此非常有用。她建议使用 Dropbox 开源的熵检查器 zxcvbn

Plattner 说,另一个诀窍是在验证用户输入时使用一些故意减慢速度的算法,如 bcrypt。慢速并不困扰大多数合法用户,但会让那些试图强行进行密码尝试的黑客难受。

Davidson 说:“所有这些都为那些想要进入技术安全领域的人提供了工作安全保障,我们在各种地方放了各种代码,这就产生了系统性风险。只要我们继续在技术领域做有趣的事情,我不认为任何人不想要在安全中工作。”


via: https://thenewstack.io/security-engineers-problem/

作者:TC Currie 译者:geekpi 校对:wxy

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