Linuxeden 开源社区 --
WPS Office for Linux 项目中止 计划开源 Linux 代码
Android 之父宣布将开源 Ambient OS 智能家居平台
The post 每日文章精选 2017 06 01 appeared first on Linuxeden开源社区.
http://ift.tt/2rueIVj2017年6月1日星期四
【漏洞公告】CVE-2017-1000367:Sudo 本地提权漏洞
Linuxeden 开源社区 --
2017 年 5 月 30 日, 国外安全研究人员发现 Linux 环节下，可以通过 sudo 实现本地提权漏洞，漏洞编号为 CVE-2017-1000367，该漏洞几乎影响了所有 Linux 系统。具体详情如下:
漏洞编号:
CVE-2017-1000367
漏洞名称:
Sudo 本地提权漏洞
官方评级:
高危
漏洞描述:
当确定 tty 时，Sudo 没有正确解析/ proc / [pid] / stat 的内容，本地攻击者可能会使用此方法来覆盖文件系统上的任何文件，从而绕过预期权限或获取 root shell。
漏洞利用条件和方式:
本地利用
漏洞影响范围:
Sudo 1.8.6p7 到 1.8.20
Red Hat Enterprise Linux 6 (sudo)
Red Hat Enterprise Linux 7 (sudo)
Red Hat Enterprise Linux Server (v. 5 ELS) (sudo)
Debian wheezy
Debian jessie
Debian stretch
Debian sid
Ubuntu 17.04
Ubuntu 16.10
Ubuntu 16.04 LTS
Ubuntu 14.04 LTS
SUSE Linux Enterprise Software Development Kit 12-SP2
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2
SUSE Linux Enterprise Server 12-SP2
SUSE Linux Enterprise Desktop 12-SP2
OpenSuse
漏洞检测:
可以使用以下命令查看 sudo 版本:
sudo -V
漏洞修复建议 (或缓解措施):
目前阿里云官方软件源已经同步更新，可以通过以下命令更新补丁:
Ubuntu/Debian:
sudo apt-get update & sudo apt-get upgrade
CentOS/RHEL:
yum update
yum update sudo
注：升级 kernel 可能会导致服务器无法启动，建议您在升级补丁时排除内核升级
打开/etc/yum.conf ，输入：
# vi /etc/yum.conf
在 [main] 段中，下添加一行，如下：
exclude= kernel* //这里假设是排除内核升级
The post 【漏洞公告】CVE-2017-1000367:Sudo 本地提权漏洞 appeared first on Linuxeden开源社区.
http://ift.tt/2roVEG8软件能将现有的 SDR 视频转变成 HDR
Linuxeden 开源社区 --
法国研究机构 Bcom 的研究人员 开发出软件 能将现有的 SDR（标准动态范围）视频转变成 HDR（高动态范围）视频。这意味着软件可以将过去 80 多年制作的彩色视频内容放宽动态范围，增加明亮度和对比度，增加同屏展示的颜色数量。Bcom 的 SDR-to-HDR 技术实时运行在基于 FPGA 的特定设备上，价格大约在数千英镑。如果使用 PC 软件，则需要十分昂贵的显卡，转换时间也比较长，1 分钟的 SDR 视频片段需要大约 3 到 10 分钟时间转换。你不能为旧的视频增加更多细节，但你现在可以增加明亮度和颜色。
转自 http://ift.tt/2rtjT87
The post 软件能将现有的 SDR 视频转变成 HDR appeared first on Linuxeden开源社区.
http://ift.tt/2rXPkI8还要等？Java 9 或推迟至 9 月 21 日发布！
Linuxeden 开源社区 --
甲骨文 Java 平台首席架构师 Mark Reinhold 建议“调整 Java 的发布日期，以适应通过 JCP 流程所需的额外时间”。可能是延至八周后（即 9 月 21 日）。
根据甲骨文 Java 平台首席架构师 Mark Reinhold 的说法，Java 9 可能会推迟到 2017 年 9 月 21 日发布。
Reinhold 写给 OpenJDK 的邮件 上说，即使 Java 社区程序执行委员会 (JCP EC) 决定投票不批准将 JSR 传递到下一阶段，也不意味着它会永久失效“。这只意味着欧盟提出了一些希望 JSR 376 专家组（EG）解决的问题。JCP 规则只给予 EG 三十天的时间来解决所有的问题（截至 6 月 7 日），而第二次 EC 投票的修订规范将不能迟于 6 月 26 日前提交。
在五月份举行的一系列 电话会议 之后，Reinhold 建议“努力在 6 月 22 日发布候选版本，但将 GA 日期从 7 月 27 日推迟八个星期至 9 月 21 日，以适应通过 JCP 流程所需的额外时间。“
To be specific, I propose that we move the GA date out by eight weeks, from 27 July to 21 September.
如果在 6 月 6 日 23:00 之前没有提出其他反对意见，或者如果提高和满意答复，那么根据 JEP 2.0 进程建议，这将是 JDK 9 的新时间表。
转自 http://ift.tt/2spjbpt
The post 还要等？Java 9 或推迟至 9 月 21 日发布！ appeared first on Linuxeden开源社区.
http://ift.tt/2rY2DZ22017年5月31日星期三
经典的 Fork 炸弹解析
Linuxeden 开源社区 --
原文出处： saymagic
Jaromil 在 2002 年设计了最为精简的一个 Linux Fork 炸弹，整个代码只有 13 个字符，在 shell 中运行后几秒后系统就会宕机：
|
1
|
:(){:|:&};:
|
这样看起来不是很好理解，我们可以更改下格式：
|
1
2
3
4
5
|
:()
{
:|:&
};
:
|
更好理解一点的话就是这样:
|
1
2
3
4
5
|
bomb()
{
bomb|bomb&
};
bomb
|
因为 shell 中函数可以省略 function 关键字，所以上面的十三个字符是功能是定义一个函数与调用这个函数，函数的名称为 :，主要的核心代码是 :|:&，可以看出这是一个函数本身的递归调用，通过 & 实现在后台开启新进程运行，通过管道实现进程呈几何形式增长，最后再通过 : 来调用函数引爆炸弹。因此，几秒钟系统就会因为处理不过来太多的进程而死机，解决的唯一办法就是重启。
Bomb 一下
秉着不作不死的心态，我们也来运行一下，于是我将矛头指向云主机，，我使用了国内的一个 2G 内存的云主机，首先在本地开启两个终端，在一个终端连接云主机后运行炸弹，秒后再尝试用另外一个终端登录，效果可以看下面 Gif 图：
看，运行一段时间后直接报出了 -bash: fork: Cannot allocate memory，说明内存不足了。并且我在二号终端上尝试连接也没有任何反应。因为是虚拟的云主机，所以我只能通过主机服务商的后台来给主机断电重启。然后才能重新登录：
炸弹危害
Fork 炸弹带来的后果就是耗尽服务器资源，使服务器不能正常的对外提供服务，也就是常说的 DoS(Denial of Service)。与传统 1v1、通过不断向服务器发送请求造成服务器崩溃不同，Fork 炸弹有种坐山观虎斗，不费一兵一卒斩敌人于马下的感觉。更吓人的是这个函数是不需要 root 权限就可以运行的。看到网上有帖子说某些人将个性签名改为 Fork 炸弹，结果果真有好奇之人中枪，试想如果中枪的人是在公司服务器上运行的话，oh，！
预防方式
当然，Fork 炸弹没有那么可怕，用其它语言也可以分分钟写出来一个，例如，python 版：
|
1
2
3
|
import os
while True:
os.fork()
|
Fork 炸弹的本质无非就是靠创建进程来抢占系统资源，在 Linux 中，我们可以通过 ulimit 命令来限制用户的某些行为，运行 ulimit -a 可以查看我们能做哪些限制：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
ubuntu@10–10–57–151:~$ ulimit –a
core file size (blocks, –c) 0
data seg size (kbytes, –d) unlimited
scheduling priority (–e) 0
file size (blocks, –f) unlimited
pending signals (–i) 7782
max locked memory (kbytes, –l) 64
max memory size (kbytes, –m) unlimited
open files (–n) 1024
pipe size (512 bytes, –p) 8
POSIX message queues (bytes, –q) 819200
real–time priority (–r) 0
stack size (kbytes, –s) 8192
cpu time (seconds, –t) unlimited
max user processes (–u) 7782
virtual memory (kbytes, –v) unlimited
file locks (–x) unlimited
|
可以看到，-u 参数可以限制用户创建进程数，因此，我们可以使用 ulimit -u 20 来允许用户最多创建 20 个进程。这样就可以预防 bomb 炸弹。但这样是不彻底的，关闭终端后这个命令就失效了。我们可以通过修改 /etc/security/limits.conf 文件来进行更深层次的预防，在文件里添加如下一行（ubuntu 需更换为你的用户名）：
|
1
|
ubuntu – nproc 20
|
这样，退出后重新登录，就会发现最大进程数已经更改为 20 了，
这个时候我们再次运行炸弹就不会报内存不足了，而是提示 -bash: fork: retry: No child processes，说明 Linux 限制了炸弹创建进程。
参考
转自 http://ift.tt/2qzgNfn
The post 经典的 Fork 炸弹解析 appeared first on Linuxeden开源社区.
http://ift.tt/2rlXx6d如何进行人力再造：指导即服务
Linuxeden 开源社区 --
作者 ，译者 王强
关键点
- 我们所处的行业中，每五年就会有半数员工被新毕业生取代。他们带来了源源不断的能量，但也不够成熟老练
- 这使得我们处于一种“持续缺乏经验”的状态
- 人力再造方法引入了小组指导和嵌入教练，可作为解决以上问题的一种手段
- “师友拥抱（Mentorship Hug）”是一种非正式、非庆祝、非课程的互动活动，专为新人举办
- 在组织中提供专业智慧时， “指导即服务”是一项持续内容
引言
正如我在 之前的一篇同名文章 中所提到的，人力再造是组织“坚持追求健康”精神的体现，落实在五种行动分支上。它们分别是指导与教练、领导力再造、团队充能、管理者意识与主动监控。
所以如果你读过之前那篇文章，并有兴趣了解更多内容，本文正对你的胃口。
本文中我们会探讨一些具体的做法。本文的主题是指导与教练分支，着重研究指导部分。该主题可总结为“指导即服务”，缩写为 MRaaS。
能量与纪律的悖论
业界权威之一，Robert C. Martin（Uncle Bob）给出了一项估计，指出程序员的数量每五年会翻番，（主要）来自于教育系统的新 CS 和 EE 毕业生成批涌入需求旺盛的开发市场。这条经验定律听起来没什么问题，其内涵很像是 晶体管行业几十年前就有的戈登摩尔定律 。这里我推荐读者观看 Martin 的演讲 ，其中提出了关于业内人员成熟度的很多见解。于是，在这一可谓人类当今文明基石的行业中，我们的平均经验水平一直都和新手几乎相当，只是比新手略强！这一事实的影响有利有弊：好处在于我们得到了庞大的、源源不断的能量、心流（flow）和极致专注（hyperfocus）。而弊端则如业内前辈所看到的一样，新人的自我管理能力与个性约束变得一团糟。我个人并不同意“一团糟”理论，我认为这种现象是代际视角的正常差异，正是节奏与文化显著不同的生态系统塑造了这种差异。事实上我们（作为行业前辈）的职责正是要帮扶新人，平滑、优雅地将他们塑造为专业人员。那么，问题在哪儿呢？
有时要教导这一大帮未成熟员工的资源不够用，这时问题就来了。特别是当团队和领导要面对沉重压力，需要尽快完成任务计划时，帮助新人、使他们“技术上具备生产力”（但并非团队急需）的余力就会非常紧张。Martin 的那段演讲很好地描述了这一现象：我们发现自身处于持续“缺乏经验”的状态中。
那么该做些什么？
这里的要点是，指导是一种单对单的长时间引导过程。这种手段花费高昂，不太可能应用到全部日常工作环境中。同时，虽然教练是基于团队实施的，它也需要很好地适应日常工作环境和场景，以免打断和浪费团队的工作时间。为实现指导与教练的目标，我们先来以人力再造的视角研究一些更加务实的模型。
在人力再造背景下指导与教练
关于指导的实用模型，我推荐“小组指导”。其中一位导师对接一组学员，指导一个特定主题并安排一系列会话，直到取得预期的效果。这里可以参考 ATD（人才发展协会）的一篇概述论文 获取这一概念的更多细节。
在教练领域，我使用的是“嵌入式团队教练”，有时也称作一线经理教练。这种教练角色是高效率领导者职责的一部分。首先要在组织中建设一个出色的领导力基础，然后要让领导者知道怎样去教练，而非单纯地提意见，当然还要根据员工的绩效和发展意愿来设置教练主题。
这里的另一个角色是从指导和教练相关的模型中自然产生的，那就是小组指导流程中的“协调人”。事实上协调人当然是由领导者担任的。他们与团队一同寻找（而不是为团队寻找）哪些主题应该包含进指导服务中。他们安排和协调指导服务的会话，并有权评估效果、影响团队成员。
师友拥抱
那么首先，怎样让这些新人步入职场呢？怎样向他们表明我们想要为他们提供指导，从而帮助他们取得事业成功呢？
简单明了地说：使用“师友拥抱”！PRE（人力再造的缩写）应该以这种方式开头。
每个组织都有一些欢迎新人的方法，让新人能愉快地融入团队。这通常是由人资部门负责的事项。此外还有类似“培训会议”或“培训日”的活动，用来让新人了解职场生活的具体内容。
但是师友拥抱并不属于这两个环节。它可以被安排在培训日里（例如半天时间），但最好是单独分出一整天的时间。如果新人还没在项目中承担重任，这一活动就不会耗费太多资源。如果团队的多种开发岗位乃至团队领导层来了不少于三名新成员，那么找上级或人资部门安排师友拥抱并不困难，更高级别的领导层则有自己的一套流程。师友拥抱的时间越接近迎新日越好。
不管是作为培训日的一部分或者是独立的一天（这样更好），师友拥抱都不该是一种庆祝氛围浓厚的迎新会。它应该成为“专业的会谈”，用来填补前辈与新人之间的鸿沟。
我个人经历而言，只要师友拥抱活动由合适的人选主办、有正确的形式，那么参与其中的感觉就非常棒。我定义“正确”的标准来自于我经历许多活动后总结的经验，之后我会谈到这部分。
现在我们来谈谈“拥抱”的一些细节。
首先定义职业和任务
第一部分的目标是让新人明白一种职业的本质：职业的含义是什么？它对从业者有何要求？人们该期待这一职位给自己的事业带来什么好处？
首先为拥抱日挑选一位领导者。他应该有丰富的经验，足以打动新人。找一位具备某些领导特长的前辈，她或他必须认同这种教导菜鸟新人的工作，并为新人提出某种“宣言”，宣言的目标是在这个知识快速革新（不仅限于我们的行业）的年代进行高效的软件开发。
接下来是议程和内容。列出你们的需求，但有一项内容永远要排在最前面，那就是“ 知识时代软件开发的视角 ”。以上链接是一个示例。这实际是我对 Techstamina 的愿景，是我对以人员为中心的软件开发环境给出的提案。
向新人提一些问题是一种开启谈话的不错方式，诸如：
- 如今一辆汽车中有多大数量级的代码？（出自 Martin 的演讲）
- 杂货店与飞机设计有什么共同点？（答案：很简单，就是软件！）
那么，经过半小时或更久的生动讨论探讨软件的用途与其对当下人类文明的重要性，可以保证大家都会意识到开发者工作的真正意义，视野也会开始变得更加广阔。
到了这一步，经过对职业意义的真诚探讨，我们应该已经指出了开发工作的本质。开发者应该是“匠人”，要让新人心中烙下“工匠技艺”的生动概念。我个人是这一概念的支持者之一，我们的开发活动应该符合这一理念。多年前一些业界前辈引领了一场工匠精神与实用主义的风潮，我从中获益良多。
拥抱日之后的多数主题是可选内容。我会给出一些个人选项，它们符合我所处环境的很多需要，如果读者愿意可以参考。另外再推荐三份重要的资料，肯定会给你们一些启迪：
- 《程序员的职业素养》，Robert C. Martin 著，和《程序员修炼之道》，Andrew Hunt 与 David Thomas 合著。
- 《Peopleware: Productive Projects and Teams》，Tom Demarco 和 Tim Lister 合著.
- 《程序员修炼之道》这一本偏技术方向，但也有关于编程中的实用主义的意义与价值的很好的介绍。
- 最后别忘了前文提到的 Uncle Bob 的演讲，真的打动人心。
以软件开发者的角色生活并发光发热
那么，看过软件在当今人类生活中的重大意义，明白软件的作用不仅局限于商业领域后，一个新的问题是：招来的这帮新人可谓 21 世纪的令人担忧的一代，那么还需要讲些什么来帮助他们面对充满挑战的职业生涯？
一如我之前所提到的，我会概述我“偏爱”的 7 个重要主题，并在每个主题前给出一些要点和提示。
-
我们在软件开发生涯中面临的挑战
要打动他们，首先你得了解他们！
于是，我们的第一个主题会列举一系列干扰我们工作的挑战，之后的主题则会研究抵消它们负面影响的策略。这些挑战分别是：
- 工作压力。
- 软件质量。
- 厌倦感。
- 脑力合作之谜：脑力工作者很容易反对别人的意见，还可能导致争吵。该怎样用认知工作来解决这一几乎每天都会遇到的问题？就我而言，我认为这是会拖慢团队进程的“摩擦”的源头之一，下面的幻灯片例 1 就此概念阐述了更多内容。
幻灯片例 1
- 自我实现谜题：人们辞职的真正原因是什么？为什么相比其他行业，我们对待自己的工作更浮躁不安？
接下来的主题会讨论面对并超越这些挑战的技巧。
幻灯片例 2
-
专业水准的基础
这个主题具体描绘“成熟”的专业特质，并展示成为受欢迎的内行的好处。主题最后给出规划成功职业生涯的通行模式。上文的幻灯片例 2 描绘了一种成为成熟的专业人员的三层式模型。第二层中的“Values”实际上指的是实用的价值观，我们在工作中需要这些价值观来达到实在、可持续的成功状态。我认为我们需要的关键价值观有：守信、负责、适应并接受他人（团队精神的基础）。接下来是向周围同事表现自己的能力。第三层的“表现能力（presentability）”指的是人们如何感受自己的存在、与他人有效沟通，尤其是表达反对意见的能力。
幻灯片例 3
-
理解并克服过重的工作压力
这里我引入与职业生涯相关的这一概念，讲一些应对它的方法。首先介绍一些“适应”这种压力的方法，之后的一些技巧会帮助我们克服压力，从压力对头脑、身体与心灵的负面影响中恢复过来。实际上，人资团队应该安排传授减压技巧的课程，帮助员工应对压力。就我来说，我会介绍相关的方法并解释为何我们应该花时间了解它们。幻灯片 4 是这一主题的介绍。
幻灯片例 4
-
软件质量
首先，我们要为程序员创造一种与缺陷战斗的文化。我曾使用上面的幻灯片做辅助，用缺陷率指标来解释“接近完美”的含义。“接近完美”指的是应该尽量减少验收问题的数量与影响，且在软件支持周期“终结”之前消灭缺陷以实现稳定的运行。接下来谈谈软件质量的其他知名的属性。这部分内容的剩余部分讲一下解决成本与质量间必然冲突的方法，以及帮助程序员自然地维持高质量输出的一些好习惯。
-
协同合作的秘密
我们应该以能量的视角进行团队合作：团队合作是团队成员、组织甚至客户的能量来源。这一主题旨在重新定义团队合作，将其视为一种途径，使成员在最富挑战的环境中表现、学习、承担压力并产出高质量的成果，同时乐在其中。
-
挑战性职业中厌倦感的真相
如果你像我一样留意过所谓“Y 世代”的概念，你应该会注意到年轻人不愿长时间重复同一种任务。这是不成熟的表现，需要我们及时纠正并解决。怎样在工作中寻找自我实现，是需要组织中团队和领导共同合作解决的问题。这一主题以自我实现的角度告诉开发者，我们的工作与成就价值非凡，应该得到足够的奖励以消除工作中的任何厌倦感。
-
编程之谜
本质上来说，不光是写代码，任何需求注意力的活动，诸如通顺地理解并表达需求、完美的设计、撰写优雅易读的代码、设计完善的测试平台……都有助于开发优秀的软件。这一主题触及了心流的心理层面，并探讨怎样应用心流产出最佳成果。
到这一步，热情洋溢的导师应该已经为真正有需要的年轻人送上了热情的师友拥抱，但他们的感受可能更多是无意识的。应该让新人深深体会到，他们来这里是要开始一项长久的事业，同时身心得到安宁。
重要的是精神
师友拥抱只是个名字。要让活动走上正轨，它需要的是温情和非正式的氛围，而非僵硬的课程形式。我从过往的经验中总结了一些行之有效的技巧：
- 活动中，应该在房间里放一些零食、咖啡和软饮料提供给大家。讨论时也可以吃点零食。如果活动比较长，还可以准备工作午餐、披萨或一些三明治。
- 开始一个主题的讨论时先问参与者一些引人深思的问题。比如说问大家关于质量的看法，请他们想一些工作中产生压力的场景，问他们会如何应对，等等。要是主持人能用苏格拉底法（又称诘问法）引导讨论就最好了，这样导师会引导人们领悟真相，而不是自己在那里背书。
- 可以的话来点幽默。幻灯片中可以插入一些技术漫画增进效果。
- 以启发式问题的形式做一些小测验，从而引发思考。问题要有趣，不要咄咄逼人。给答对的参与者一些小奖品。当多年后你再碰上某人，她或他拿出当初活动中你奖励的钥匙链时，你就会知道这种做法的确起效了。
- 表现得像他们的同事，表达对开发者同僚的尊敬，不要强调等级区分。
- 给大家分发一些纪要，上面列举一些活动中总结的要点。问问他们还想加上些什么，有没有人想为你写的东西补充些内容。
最后，尽可即兴发挥，让大家留下一个热情的第一印象。
可持续的指导
拥抱日只是组织为成员提供的持续服务的开始，这种服务旨在逐渐塑造成员的专业特质。以下要点介绍怎样以服务的形式，基于学员的实际需求和绩效进行持续指导。
- “指导即服务”（MRaaS）需要中间人提出需要处理的问题。这里中间人主要由领导，尤其是与团队成员直接互动的团队领导来担任。领导的角色不该超越前文所提到的“协调人”范畴。领导与团队成员讨论各种问题，看看大家是否愿意（也可能是需要）将问题纳入指导流程。还有些情况下，需要一对一模式探讨特定问题的学员会直接与导师对接。两种情况我之前都见识并实践过。这里的重点在于将接受服务的学员要有需求服务的自觉，并同意得到服务。领导依旧在导师和团队学员间充当协调人的角色，且做好这一工作即可。
- 所有人都会遇到的问题可以在组织而非团队层面进行处理。然而当它涉及工作细节的问题时，这种做法并不是最佳选择。“团队被共同召集产生的亲密感”有其难以忽略的价值。组织层面的会议会在其他场景下有更好的表现，之后我会简单提及。
- 实践中有时爆发的问题，其本质与软件领域关联不大。尤其是软技能方面这种情况很多。这类问题可能需要外部主题专家来进行指导。这类主题与之前的 PRE 中指导与教练部分不同，更近似于“培训”，不会有太多内行人之间的会话。
- 你可能注意到了，本文多数内容都指向了小组指导而非教练。事实上指导部分依靠教练来寻找有意义的主题，同时教练活动作为一种接近日常进行的领导工作，在之后谈到实施 PRE 的领导层再造与行动部分时会重点介绍。
好了，以上就是组织实践中开始并持续指导的方法。之后就要面对一些难点了。
还有，完全不要悲观！
这又是从何说起？
事实上，当鼓励人们接受指导时，不管是在开始的活动或之后的会议中，通常遇到的首要问题是“工作时间”。不过我个人经验来看，做好以下措施这就不会是个问题：
- 领导恰当而热心的规划。领导是协调者，他们知道何时才是规划活动的最佳时机。比如说，我会在迎新会上进行师友拥抱活动。有些情况下内容多到一次或一天的活动也讲不完。我们的应对方式是先举办简化的活动，然后一起进行多轮讨论，逐个探讨各个主题的细节。灵活行事！
- 内部导师的时间安排。组织内部的成员可以成为导师，而热爱这项工作的人会为相关活动空出自己的时间。对经验丰富，足以让新人茁壮成长的前辈来说，这项任务能得到自我实现和满足。
总结
人力再造的第一部分：与服务关联的指导与教练，或称 MRaaS 的内容就此结束。在领导层部分可能更多地介绍教练。在这个知识时代，软件开发实践的价值不断增长，我希望能提供相关的个人经验。请时刻记住不要把指导当作是正式的企业培训。它按需实施、花费不大，在职场中更加生动亲切。
关于作者
查看英文原文：People Re-Engineering How-To’s: Mentoring As A Service
转自 http://ift.tt/2sp4enD
The post 如何进行人力再造：指导即服务 appeared first on Linuxeden开源社区.
http://ift.tt/2rqrK6f
订阅：
博文 (Atom)