整体上很优雅的 Xfce 桌面所具备的足够轻巧和快速的特性能够让它很容易都知道如何做好一件事。

由于某些原因（也包括好奇），几周前我开始使用 Xfce 作为我的 Linux 桌面。促使我更换 Linux 桌面环境的原因之一是桌面相关的守护进程占据了我的性能非常强大的主工作站的绝大部分 CPU 资源和 I/O 带宽。当然，有些不稳定性可能是因为我删除了提供这些守护进程的 RPM 包。然而，事实是在我删除这些 RPM 包之前，KDE 就已经很不稳定了而且还导致了一系列其他方面的性能和稳定性问题。所以我需要换一个桌面来避免这些问题。

在回顾了我为 Linux 桌面所写的一系列文章后我才意识到我忽略了 Xfce。这篇文章也是力图能够纠正弥补这个疏忽。我非常喜欢 Xfce 也很享受它所带给我超乎预期的快速、轻量的体验。

作为研究的一部分，我有尝试过在 Google 上查询 Xfce 对应什么意思。有个历史参考是它对应着 “XForms Common Environment”，但 Xfce 早已不在使用 XForms 工具。几年前，我找到另一个参考是 “Xtra fine computing environment” 而且我也很喜欢这个解释。我将会用它作为 Xfce 的全称（尽管再也找不到这个参考页面）。

推荐 Xfce 的 8 个理由

1、轻量级架构

Xfce 相对于其他的桌面如 KDE 和 GNOME，不管是内存还是 CPU 的占用率都非常小。在我的系统中，组成 Xfce 桌面的程序仅占用了少量内存就构成一个如此强大的桌面。超低的 CPU 占用率也是 Xfce 桌面的一个特点。了解到 Xfce 内存占用特别低后，我对它的 CPU 占用率也非常低这个特性自然而言也就不感到奇怪了。

2、简洁

Xfce 桌面很简单，就像绒毛整洁的动物让人一目了然、赏心悦目。基础的桌面有两个面板和一条在左边垂直的图标行。面板 0 在底部，并由一些基础的应用启动程序和能访问到系统里对应程序的图标组成。面板 1 在顶部，由一个应用程序启动器和一个能够允许用户在多个工作区之间来回切换的工作区切换器组成。面板可以通过补充项自定义修改，比如增加个新的应用启动器或者更改它们的宽高。

桌面左侧的图标对应是家目录和垃圾桶。它也可以显示其他的图标，如完整的文件系统目录树和已连接上系统的可插拔的任意 USB 存储设备。这些图标可以用来挂载和卸载设备，也可以用来打开默认的文件管理器。如果你愿意，它们都可以被隐藏，同时文件系统、垃圾箱、家目录对应的图标都可以逐个控制管理。所有的可移动设备也可以被隐藏或作为一个组显示。

3、文件管理

作为 Xfce 的默认文件管理器 Thunar，它很简单，既易于使用和配置也非常容易学习。尽管它并不像其他的文件管理器比如 Konqueror 或者 Dolphin 那样效果华丽，但它很强大也很快。Thunar 并不能在一个窗口里面打开多个面板，但它提供了选项卡来支持多个目录的同时打开。Thunar 也有一个非常漂亮的侧边栏，其上同样的图标就像桌面那样能够显示完整的文件系统目录树和所有已连接的 USB 存储设备。设备能够被挂载和卸载，可移动媒介如 CD 也能够被弹出。Thunar 也可以使用类似 Ark 这种帮助软件来在你点击归档文件的时候打开它们。比如 ZIP、TAR、RPM 这种归档文件都可以被浏览也可以从中复制单个文件。

Xfce 桌面及 Thunar 和 Xfce 下的终端模拟器。

在我的文件管理器系列文章中，我已经使用体验过很多不同的文件管理器软件，我不得不说 Thunar 的简单易用让你无法不喜欢上它。它可以让你通过使用侧边栏来很容易地浏览文件系统。

4、稳定

Xfce 桌面非常稳定。新版本的发布周期似乎是三年，但也会根据需要发布相关更新。最新的版本是于 2015 年 2 月发布的 4.12。在使用 KDE 遇到一系列问题后，稳如磐石的 Xfce 桌面环境显得让人格外放心。在我使用 Xfce 的过程中，它从来没有崩溃过，也不会产生额外的守护进程占据过多的系统资源。这正是我想要的：它安安静静地工作，不会给你带来额外的困扰。

5、优雅

Xfce 简单优雅。在我的今年秋天将面世的新书《系统管理员的 Linux 哲学》中我谈到了关于简单的一系列好处，包括简单事实上也是优雅的诸多标志之一。很明确能够确定的就是 Xfce 及相关组件程序的开发者和维护者也是极力推崇简单至上。这种简单特性很可能也是 Xfce 如此稳定的主要原因，但它也给用户带来了一个整洁的桌面外观，一个反应灵敏的操作界面，一个会让人感觉很自然也很易用的导航结构，而且 Xfce 整体上的优雅特性也会让用户的使用过程中充满愉悦感。

6、终端仿真程序

Xfce4 的终端仿真程序非常强大，而且和其他很多终端仿真程序一样可以允许你使用多个选项卡来让多个终端在一个单独窗口里共存。尽管它与 Tilix、Terminator、Konsole 这种终端仿真程序比起来相对简陋，但它也能很好的完成工作。选项卡的名字可以更改，而且选项卡也可以通过拖放或者工具栏的箭头图标或者菜单栏的选项重新排列。我特别喜欢 Xfce 的终端仿真程序的一点就是不管你连接了多少主机，相对应的选项卡都会显示对应的主机名，比如，从 host1=>host2=>host3=>host4，会准确地在选项卡显示了 “host4”。但其他的终端仿真程序最多也就显示 “host2”。

至于这个终端仿真程序功能和外观的其他方面都可以根据你的需要很容易配置成你想要的。当然同 Xfce 的其他组件一样，这款终端仿真程序占用了系统资源的很少一部分。

7、可配置性

Xfce 能够配置的范围极大。虽然 Xfce 桌面的可配置性比不上 KDE，但依旧远超 GNOME，而且比它更容易配置。比如，我发现设置管理器是 Xfce 配置一切的入口。虽然每个配置程序都可以单独使用，但是设置管理器把他们都放在一个窗口里以便快速访问。关于 Xfce 桌面很多重要的部分都可以通过配置来满足我的需求。

8、模块化

Xfce 是由一系列单个的项目组成的整体，而且在你的 Linux 桌面发行版中也未必安装了 Xfce 的所有组件。Xfce 项目 的主页列出了主要的项目，所以你可以根据需要安装你想安装的附加组件。比如在我的 Fedora 28 workstation 版本上我安装的 Xfce 组时就没有 Xfce 项目 主页最下面的说明的一些程序。

这里还有个关于 Xfce 的 文档页面 和 一个被称为 Xfce 超值项目 的 wiki 列举了其他的 Xfce 相关的项目，它们为 Xfce 的面板及 Thunar 提供了很多不错的应用程序、精美的插图、好用的插件。

总结

整体上很优雅的 Xfce 桌面所具备的足够轻巧和快速的特性能够让它很容易都知道如何做好一件事。它的轻量级的结构也节省了大量的 CPU 和内存资源。这也使得 Xfce 非常适合那种由于硬件有限而无法分配给桌面太多资源的旧主机。然而，Xfce 又是足够的灵活和强大的，能够满足高级用户的需要。

我知道，更换到一个新的 Linux 桌面环境需要你自己按照你想要的做些对应的自定义设置：比如面板上显示你最爱用的程序对应的启动器，设置下你最喜欢的桌面背景壁纸等一系列工作。这些年来我已经在切换到新桌面环境或更新旧桌面环境折腾很多次了。这需要时间也需要耐心。

我觉得切换 Linux 的桌面环境就像我在工作中换个办公工位或者办公室一样。别人把我的东西装箱从旧办公室搬到新办公室，然后我在我的新办公室里组装连接好我的电脑，打开箱子再把里面的东西放在合适的位置。而切换到 Xfce 桌面大概就是我做过的最简单省事容易的桌面环境更换了。

via: https://opensource.com/article/18/6/xfce-desktop

作者：David Both 选题：lujun9972 译者：WangYueScream 校对：wxy

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

70 后的老程序员已经对层出不穷的编程语言感到了厌烦，虽然这已经距离上一个编程语言出现已经十年了。

虽然老程序员依旧很潮——扎着马尾，穿着花裤子——但是不能掩饰其秃顶和肥胖的腰身。

IT 行业，是一个日新月异的行业，老程序员们如何跟上时代呢？十年，快吗？

via: http://turnoff.us/geek/oh-the-70s/

作者：Daniel Stori 译者 & 校对：wxy 校对 & 合成：wxy

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

这是一个听起来几乎不可能的事情……我甚至有点后悔将它发到网上，因为它在一个会议上成了一则著名的酒后故事。这个故事略有改动，以保护故事中的人物，以及忽略了一些无关的细节使之更有趣一些。

几年前，当我接到统计系主任的电话时，我正在从事维护校园电子邮件系统的工作。

“我们从部门发送电子邮件时遇到了问题。”

“有什么问题？” 我问。

“我们不能发送超过 500 英里的邮件，”主任解释说。

“咳咳”，我被我喝的拿铁呛了一口，“您再说一遍？”

“我们不能发送距这里超过 500 英里的邮件，”他重复道。 “实际上，更远一点，是 520 英里，但不能更远了。”

“嗯......电子邮件真的不会这样，通常，”我说，试着让我的声音听起来不那么慌乱。我不能和一个系主任说话时显得慌乱，即使是一个像统计系这样的相对没钱的院系。 “是什么让你觉得你不能发送邮件超过 500 英里？”

“这不是我认为的，”主任有点急躁地回答道。 “我们首先注意到了这种情况是几天前。”

“你等了几天？” 我打断他，带点颤音说道。 “这段时间你一直你不能发送电子邮件？”

“我们可以发送电子邮件。只是不超过 ——”

“—— 500 英里，我知道，”我接过他的话，“我知道了。但为什么没有你早点打电话呢？”

“好吧，我们没有收集到足够的数据来确定发生了什么，直到现在。”没错，这是统计系的主任。“不管怎么说，我请了一位地理统计学家研究它 ——”

“地理统计学家……”

“—— 是的，她制作了一张地图，显示了我们发送电子邮件能够达到的半径略超过 500 英里。在那个半径范围内有零星的几个无法到达的目的地，但我们永远不能发送比这半径更远的电子邮件。”

“我明白了，”我说，把头埋在我的手中。 “这是什么时候开始的？几天前，你说过，但是那时你的系统做了什么改变？”

“嗯，服务顾问来给我们的服务器打了补丁，并重新启动了它。但我打电话给他，他说他没有碰过邮件系统。”

“好的，让我来看看，我稍后会给你回电话，”我说。我简直觉得我在做梦，这不是愚人节。我试着回想是不是有人恶作剧报复我。

我登录了他们系的服务器，并发送了一些测试邮件。在北卡罗来纳州的 三角研究园 （ Research Triangle Park ） ，我自己的帐户的测试邮件顺利投递。发往里士满、亚特兰大和华盛顿的也是如此。发往普林斯顿（400 英里）的另一个邮件也正常。

但后来我尝试向孟菲斯（600 英里）发送电子邮件，失败了。波士顿，失败了。底特律，也失败了。我拿出了我的地址簿，开始试图缩小它的范围。纽约（420 英里）成功，但普罗维登斯（580 英里）失败了。

我开始怀疑自己是不是疯了。我试过给住在北卡罗来纳州的朋友发电子邮件，但他的 ISP 在西雅图。谢天谢地，它失败了。如果问题与收件人的地理位置有关，而不是他的邮件服务器，我想我要哭了。

已经确定！虽然令人难以置信，但所报告的问题是真实的、可重复的，我看了一下 sendmail.cf 文件。它看起来很正常。事实上，它看起来很熟悉。

我把它与我主目录中的 sendmail.cf 做了个对比。它没有被改过 —— 这是我写的 sendmail.cf。 而且我相当确定我没有启用某种 “FAIL_MAIL_OVER_500_MILES” 选项。我不知所措，我 telnet 到 SMTP 端口。 服务器愉快地回复了 SunOS sendmail 的横幅消息。

等一下……一个 SunOS sendmail 的横幅消息？当时，即使 Sendmail 8 已经相当成熟，Sun 公司在其操作系统中装的仍然是 Sendmail 5。作为一名优秀的系统管理员，我已经对 Sendmail 8 进行了标准化。并且作为一名优秀的系统管理员，我编写了一个 sendmail.cf，它使用了 Sendmail 8 中提供的很长的、具有自我描述意义的选项和变量，而不是 Sendmail 5 中使用的那种神秘的标点符号式配置选项。

这个细节一下子又回到了起点，我再次被我现在已经冷掉了的拿铁咖啡渣呛了。 当服务顾问“对服务器打补丁”时，他显然升级了 SunOS 的版本，并且这样做降级了 Sendmail。这次升级会将 sendmail.cf 单独留下，即使它现在是错误的版本。

事实上，Sendmail 5 —— 至少是 Sun 所带的版本，是有一些调整的 —— 它可以处理 Sendmail 8 的 sendmail.cf，因为大多数规则在那时保持不变。但新的长配置选项 —— 它被视为垃圾，并跳过。 并且 sendmail 二进制文件编译时没有针对其中大多数设置默认值，因此，在 sendmail.cf 文件中找不到合适的配置，它们被设置为 0。

被设置为 0 的配置之一是连接到远程 SMTP 服务器的超时选项。 一些实验证明，在具有典型负载的特定机器上，0 超时将在稍微超过 3 毫秒的时间内中止连接调用。

当时我们校园网络的一个奇怪的特点是它是 100％ 交换的。传出的数据包不会出现路由器延迟，直到命中 POP 服务器并到达远端的路由器。因此，连接到附近网络上的轻负载的远程主机的时间实际上主要取决于到目的地的光速的速度，而不是偶然的路由器延迟。

这让我有点晕，我在我的 shell 中输入：

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979

“500 英里，或者稍微多一点点。”

UCloud 技术副总裁杨镭首谈 UCloudStack、保护客户隐私、回馈开源社区背后的故事和挑战。

日前，Linux 中国社区的老王参加了 UCloud 用户大会，并有幸和 UCloud 技术副总裁杨镭进行了面谈。以下将我们谈话中一些内容分享给大家。

杨镭，UCloud 技术副总裁。全面负责 UCloud 产品研发和产品运营工作，有超过十年 IT & 互联网行业从业经验，在网络领域拥有丰富的经验和深刻的理解。

为什么专门开发了 UCloudStack？

今天的大会上面您提出一个针对私有云的 UCloudStack，是否可以给我们详细介绍一下为什么在有了生态很成熟的 OpenStack 的情况下，UCloud 还投入了巨大的资源去研发UCloudStack？

杨镭：

我们在 OpenStack 上做的还比较早的，当时我们的认知就是公有云是公有云，而私有云 OpenStack 做的比较好。但实际上，通过不断的时间验证，我们发现 OpenStack 有一个比较大的问题，就是过于复杂。

回到用户对私有云需求来讲，用户实际上关注的还是能不能解决他的需求，而不是说要不要用 OpenStack。所以，我们考虑到，既然已经有了多年的云计算的开发和运维经验，如果从头开始做一个自己的私有云产品，是不是会做的更好？

我们做了 16 个月就做出来了这个产品，在完成核心产品之后，整体的代码量还是很少的。代码量是相对来讲是衡量一个项目复杂性的很好的指标。我们根据自己这么多年来的经验做下来，我们发现这个事情并没有那么的难，而且，现在这个时候，在做这个产品的时候认知就和几年前不太一样，我们会比以前想的成熟很多。我们相信做出来的东西会比 OpenStack 更轻量、更好用，这是我们做这个产品的一个主要的想法。

其实现在真正能自己独立用 OpenStack 产品的公司一般都有一个一定规模研发的团队，至少十个人。但是云计算这个市场的人才竞争还是蛮厉害的，一个公司很难有这样一群比较好的人去做这个事情，所以它的门槛会很高。如果说公司的目标只是为了有一个私有云，那么这样研发投入的必要性是打问号的。这些企业的目标和我们云服务商的目标不一样，它的云只是一个工具，不像我们的云是我们本身的一个产品。所以这时实际上企业往往会考虑说怎么能把这个私有云更好的建起来，很快、很稳定的用起来，在成本上比较合理。所以在我们的这个产品上，我们最重要的一个点确实就是在轻量上。

假如你对 OpenStack 需要做一些改动，是牵一发而动全身的，为了做某个功能可能要改造底层的东西，这个时候整个过程在研发上来讲就太“重”了，所以我们如果从零开始做，其实我们的底层就是可控的。我们在第一次推出的时候，我们总的代码量才八九万行，而 OpenStack 所有项目代码量加起来有几千万行，这之间的复杂性灵活性是完全不能比拟的，这是它的一个轻的主要原因。

另外一个，因为我们做这个产品的目的性会比做一个开源的社区项目更明确一点，比如说我们做产品的路线很不一样。当我们的核心产品完成以后，我们做的一个比较大的改变是和传统的网络打通，我们 UCloudStack 部署完了以后和传统的网络做很大的打通，这点和开源社区项目的目标不一样，它要让这个东西更加通用。这在产品的改变选择的路径差别特别大。这个时候看用户要什么，往往用户要的东西更贴近它想要的，这里面也是一个很大差异点。

今天本来想放一段视频，那段视频是当时在富士康的办公园区里面拍的，当时是下午四点钟进入机房到晚上十点种整个私有云的交付就完成了。而且当中大概有 2-3 个小时是因为机房的一些问题影响了整个的进度，如果看到那个视频就会真正感觉到它很轻，但一般而言 OpenStack 部署起来时间会更长，比如说好几天的时间，它的底层太复杂了。

我们一直认同的一点是说，开源软件比较适合做一个组件，比如说一个数据库、一个操作系统、一个很垂直的部分。但是云实际上不是一个垂直的组件，而是很多组件组成在一起的一个体系。如果你去用开源软件做组件的方式去做云，这其实不是特别的理想。

为什么将客户隐私保护拔高到这样的高度？

今天上午大会上您提到一个隐私的产品，禁止一些 API 采集用户数据，来保护用户的隐私，这方面能够详细谈谈吗？

杨镭：

这个我需要澄清一下，我们说的是禁止我们的云平台收集我们客户的信息，而不是说我们禁止了客户收集他的用户信息。因为我们是给企业提供服务的，企业本身给他的终端用户提供服务，我们控制的是我们和企业之间数据的隐私问题。比如说它的使用习惯是什么，或者它业务的模型是什么，我们在控制这个。

因为我们自己是做云服务的，我们的技术工程师在管理我们云业务的时候，实际上是有可能看到用户的数据。比如说你是一个电商公司，假设你的数据库如果没有进行加密，技术人员是可以看到这个数据的。目前来讲绝大多数的厂商，靠的还是流程和制度，靠的不是技术手段保护。什么叫技术手段，就是说我想看却看不到，因为是加密的。你只有拿到相应的解密密钥才能去看。我们说的数据保护更多的是这方面。

再比如说我们的云主机最终跑在 SSD 硬盘上，如果你去机房里把硬盘直接拔插走，而没有加密的话，一定是能读到里面的数据。从长远来看，这是不能出任何问题的，哪怕是一两次。像某互联网公司出了几次乘客的安全事件以后，事情影响就非常恶劣。回到做云服务，我们的责任一样重大。我们如果只是一家公司，也许我有的只是很特定的一些数据，但是作为做云服务的公司，我们上面的客户不是我们能决定的，要看客户自己做什么业务，所以我们上面有几十万，甚至几百万的数据，这是一个非常长远、需要很认真对待的事情。所以我们把这一点放到了一个很高的、甚至于到我们企业文化和价值观的角度。

作为一个工程师来讲，首先我们要有价值观，这是第一点，但是也要从技术上保证，所以我们未来会在这方面投入很多的技术研发工作，来实现比如说我们自己的技术工程师没有任何可能能看到我们客户数据。这里面实际上是有很多的技术工作要做的。

在我们刚刚做云的前两年，那时候如果去对数据做加密，就会严重影响到性能。这个时候你很难两者兼得，但是随着这几年的技术的演进，很多的加密算法被逐渐的优化以后，基本能做到做了加密也不怎么会影响性能。所以现在这个时代，是一个非常好的时机，是一个你应该要去做这件事的时机。

整个这个事情大概我们是这样看的。除了数据的加密，包括用户有时候会输入给我们很多数据，他在做一些操作需要提供身份信息，比如说现在网络安全法要求用户使用要做实名认证，也就是说他的身份证会上传到我们这儿，这些数据其实是一个很隐私的数据。这件信息的泄露是一次都不能发生的，所以我们如果回到最根本的来说，我们怎么样尊重我们的用户？这个事情其实比一些产品功能更重要。

我们不希望出了事故以后我们再做一些补救的工作，那时候即使你是真的去做，你的用户也已经受到了很大的伤害。

另外一个层面，我今天没有提到，因为云计算的公司，我们特别需要最顶尖的技术人才，我们这么多年来在吸引最顶尖的人才上我们逐渐意识到靠的不是钱、待遇，或者是一些职位。最优秀的顶尖技术人才，看的是你公司的理念和价值观，比如说谷歌、苹果他们有非常多的几十年的行业人才在里面，为什么？他们做的工作就是数据安全性、隐私就这方面的工作。所以我们也是在商业的进化过程中，我们发现要做一家几十年的公司，不是靠一两年的财报，而是靠这些背后的东西，这是我们很真实的一个自己成长的过程。

对开源社区的回馈

我们非常关注 UCloud 在采用开源软件方面的情况，云服务商的很多基础设施都是基于开源软件的。目前UCloud在开源方面对上游社区的贡献情况怎么样？

杨镭：

我们目前在开源方面目前做的工作还不多。但是为什么不多？不是我们不想做，而是因为我们处在一个技术竞争特别激烈的行业里面，你的产品实际上卖的都是技术。我们的技术人员这么多年来其实一直不太够用，所以我们绝大多数的精力是在做我们自己不得不做的事情，比如说今天说的网络架构的透明升级，这个事情实际上把我们的核心人员的精力全部消耗掉了。为了这些升级，我们要跟客户沟通好这个事情让客户放心我们才能做，这也是为什么我们会做 29 个月的原因，其中有 9 个月是跟客户沟通的过程中。我们的人并不是很多，我们对自己产品的要求还是蛮高的，在这两个因素影响下，我们也很难拆出精力来更多的主动回馈社区。

但是这一点上我们想法是很明确的，只要我们现在有精力就会回馈社区。比如说这次做的 25G 的网卡，这个解决了一个核心障碍，我们把这个东西交给上游，但是从整个公司来讲这块投的人员和精力还不是很多。像我们开源的命令行工具，我们和 Hashicorp 做的整合，这些我们全部开源了，但是这些还远远不够。其实开源，也是想让用户知道你的代码到底怎么写的，只是说这里面是一个精力问题，不是意愿问题。

我们在 2013 年做了一个内核模块，是可以把 SSD 盘加速 100 多倍，由于一些原因，我们的代码是针对某些特定场景的。同时在代码的规范上也做了一点牺牲，如果要开源，相当于要额外增加 30% 的工作量。但是我们现在一直在想，就像今天举的例子，把很多东西开源，尽量的变成工具化，而不是放在 UCloud 的内部一个产品，只是我们精力不太够。

最近 Redis、Kafka、ES 这样的软件都在许可件上改了自己原来的开源许可证，针对云服务商提出了特别的条款。比如说云服务商用 Redis给客户提供服务，但是很少对 Redis 进行社区回馈，所以云服务商需要额外采购商业许可证，您怎么看这个事情，UCloud 怎么面对这个情况？

杨镭：

目前来看，我觉得确实云服务商对社区的回馈是偏少的，所以说我觉得 Kafka 和 Redis 在这个事情上他们是有一定的道理。但这个事情也不能单方面的看待，因为实际上云厂商在推出 Kafka、Redis、ES 产品时，其实也帮这些开源软件做了很多的推广。Redis 比较简单，Kafka 或者是 ES，其实还是一个蛮复杂的软件。云厂商将这些组件加入平台后，把最复杂的地方把简化了，用户甚至连性能维护都不用考虑，另一个维度来看相当于推广了 Kafka。我认为云厂商或者是以此谋利的厂商，他应该做足够的回馈，不管你是以钱的方式，还是以研发的方式，我觉得是应该回馈的。

和杨镭的沟通当中，我们还谈到了许多其他问题，这里限于篇幅就不展开叙述了。从上面的谈话当中，我们能感受到 UCloud 做为一家新兴发展起来的初创公司，无论是在技术还是企业价值观方面，逐渐形成了自己独有的优势。其实作为 UCloud 多年的老朋友，这次参加这个大会，让我意外的是，原来我对他们的了解还所知甚少；也为他们在隐私保护、技术研发等方面默默做的工作而吃惊。希望这些技术人可以秉持初心，真正做出一个好用、值得用的产品来。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。

Red Hat 的 2018 女性开源社区奖获得者 Dana Lewis 的故事。

Dana Lewis 被评选为开源社区 2018 年度最佳女性！下面是开源怎样改善了她的健康的故事。

Dana 患有 I 型糖尿病，但当时市面上流通的药品和医疗设备都对她无效。她用来管理血糖的动态血糖监测（CGM）报警器的声音太小了，根本叫不醒熟睡的她，产品这样的设计无法保证她每天睡眠时间的生命安全。

“我和生产厂家见了一面商议提出意见，厂家的回复是‘我们产品的音量已经足够大了，很少有人叫不醒’，我被告知‘这不是普遍问题，我们正在改进，请期待我们的新产品。’听到这些时我真的很挫败，但我从没想象过我能做出什么改变，毕竟那是通过了 FDA 标准的医疗设备，不是我们能随意改变的。”

面临着这些阻碍，Dana 想着如果她能把自己的数据从设备里导出，就可以设置手机闹铃来叫醒自己。在 2013 年末，她看到的一条推特解决了她的疑问。那条推特的作者是一位糖尿病患儿的家长，他把动态血糖监测仪进行了逆向工程，这样就可以导出孩子的血糖数据进行远程监控了。

她意识到如果对方愿意把过程分享给她，她也可以用那些代码做一个自己的响亮的血糖监测仪了。

“我并不知道向别人要源代码是件稀松平常的事，那是我第一次接触开源。”

那个系统演化成一个响亮闹钟的代码，她也可以把代码在网页上分享给别人。和她的丈夫 Scott Leibrand 一起，她逐步向闹铃添加属性，最终形成了一个算法，这个算法不仅能监测实时血糖水平，还能主动预测未来血糖波动。

随着 Dana 与开源糖尿病患者社区的接触越来越深，她认识了 Ben West，他花了很多年才研究出与 Dana 使用的胰岛素泵沟通数据的方法，与血糖监测仪不同，胰岛素泵不是简单的报告血糖，它是个单独的设备，要按人体需要持续推注胰岛素，比血糖监测仪要复杂得多。

“老路行不通了，我们说‘哦，如果我们能用这段代码和胰岛素泵沟通，就像我们之前用算法和血糖监测仪沟通实时数据那样，我们就能获取两个设备的实时数据，创建一个闭路系统。’”

我们得到的是一个自制人工胰腺系统 (DIY APS)。

这个系统可以使用算法处理胰岛素泵和血糖监测仪的数据，来预测患者血糖水平，据此调整胰岛素的注射量，从而保持患者的血糖稳定。这个人工胰岛素系统取代了从前患者每日多次对胰岛素注射量的计算和调整，减轻了糖尿病患者的负担。

“正因为我们使用的是开源软件，在做出这个系统之后我们就把成果开源化了，这样可以造福更多的人。”开源人工胰腺系统 (OpenAPS) 由此诞生。

OpenAPS 社区已经拥有超过 600 名用户，大家都提供了各种各样的自制“闭路”系统代码。OpenAPS 贡献者们聚集到了 #WeAreNotWaiting 话题之下，以表达患者群体不该干等着医疗保健工厂制造出真正有效便捷产品的理念。

“你可以选择等待未来的商业解决方案，这无可厚非，选择等待是你的自由。等待可以是一种选择，但不能是无法改变的现状。对我来说，开源在医疗保健方面做出的这个举动让等待变成了一种选择。你可以选择不自行解决，你可以选择等待商业解决方案，但如果你不想等了，你无需再等。现在你有很多选择，开源社区的人们已经解决了很多问题。”

OpenAPS 社区由糖尿病患者、患者家属，还有想要合理利用这项技术的人们。在社区的帮助下，Dana 学会了很多种贡献开源项目的方式。她发现许多从 Facebook 或 Gitter 上过来的非技术贡献者也对 OpenAPS 做出了很大贡献。

“贡献有很多方式，我们要认识到各种方式的贡献都是平等的。它们一般涉及不同的兴趣领域和技能组合，只有把这些综合起来，才能做成社区的项目。”

她亲身经历过，所以知道自己的贡献不被社区的其他成员认可是怎样难过的感受。对于人们习惯把女性的贡献打折的这一现象，她也不回避。在她的 2014 年博客 和 反思 文章中她初次写到在入围开源年度最佳人物时所遭受到的区别待遇，这些待遇让她意识到身为女性的不同。

在她最初的博客中，她写道了自己和丈夫 Scott 同为开源社区成员，遭受到的区别待遇。他们都注意到，Dana 总是被提出一些细枝末节的要求，但 Scott 就不会。而 Scott 总被问道一些技术性问题，即使他向他们推荐 Dana，人们也更倾向于问身为男性的 Scott。大家都或多或少经历过这些行为，Dana 的博文在社区里引起了广泛的讨论。

“人们更愿意认为项目是‘Scott 发起的’而非‘Dana 和 Scott 一起发起的’。”这让我感受到千刀万剐般的痛苦和挫败，我写了博客把这个现象提到明面上，我说，‘看看这些行为，我知道你们有些是故意的，有些是无意的，但如果我们的社区想要得到多元化参与者的支持，想要发展壮大，我们就要规范自己的行为，有不妥之处也不要回避，直接摊开来交流。”值得赞扬的是，社区里的大部分成员都加入进来，认真地讨论这个问题。他们都说，‘好的，我知道有哪里需要改了，如果我再无意识这样做时提醒我一下。’这就是我们社区形成的风气。”

她还说如果没有 Scott 这位社区里活跃开发者的支持，还有社区里其他女性贡献者的鼓励，她可能就半途而废了。

“我想如果我就放弃努力了，可能开源世界里糖尿病患者们的现状会有很大不同。我知道别人不幸的遭遇，他们在开源社区中感受不到认同感和自身价值，最终离开了开源。我希望我们可以继续这种讨论，大家都能意识到如果我们不故意打击贡献者，我们可以变得更加温暖，成员们也能感受到认同感，大家的付出也能得到相应的认可。

OpenAPS 社区的交流和分享给我们提供了一个很好的例子，它说明非技术性的贡献者对于整个社区的成功都是至关重要的。Dana 在现实社会中的关系和交流经历对她为开源社区做出的宣传有着很大的贡献。她为社区在 DIYPS 博客 上写了很多篇文章，她还在 TEDx Talk 做过一场演讲, 在 开源大会 （OSCON） 上也演讲过很多次，诸如此类的还有很多。

“不是每个项目都像 OpenAPS 一样，对患者有那么大的影响，甚至成为患者中间的主流项目。糖尿病社区在项目的沟通中真的做了很多贡献，引来了很多糖尿病患者，也让需要帮助的人们知道了我们的存在。”

Dana 现在的目标是帮助其他疾病的患者社区创建项目。她尤其想要把社区成员们学到的工具和技术和其他的患者社区分享，特别是那些想要把项目进一步提升，进行深入研究，或者想和公司合作的社区。

“我听说很多参与项目的患者都听过这样的话，‘你应该申请个专利；你应该拿它开个公司；你应该成立个非营利组织。’但这些都是大事，它们太耗时间了，不仅占据你的工作时间，甚至强行改变你的专业领域。我这样的人并不想做那样的事，我们更倾向于把精力放在壮大其他项目上，以此帮助更多的人。”

在此之后，她开始寻找其他不那么占用时间的任务，比如给小孩们写一本书。Dana 在 2017 年进行了这项挑战，她写了本书给侄子侄女，讲解他们婶婶的糖尿病设备是怎样工作的。在她侄女问她“胳膊上的东西是什么”（那是她的血糖监测仪）时，她意识到她不知道怎么和一个小孩子解释糖尿病患者是什么，所以写了《卡罗琳的机器人亲戚》这本书。

“我想用我侄子侄女那个年纪的语言和他们交流，毕竟不同年龄的人说话方式也不同。我当时想，‘真希望有本这方面的儿童读物，那我为什么不自己写一本呢？’”

她写了书在亚马逊上出版，因为她想把开源的价值分享给更多的人。她还开了一个名为“自己在亚马逊上出书”的博客，希望大家也可以把自己的经历写进书里出版。

像《卡罗琳的机器人亲戚》这本书还有开源社区年度最佳女性这样的奖项都说明生活中包括开源在内的不同领域中，还有很多人的工作等待着大众的认知。

“社区越多元，事情越好办。”

via: https://opensource.com/article/18/5/dana-lewis-women-open-source-community-award-winner-2018

作者：Taylor Greene 选题：lujun9972 译者：Valoniakim 校对：wxy

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

让一名非工程师来解释为什么你不必成为一位开发者或运维就能爱上 DevOps。

我从未做过开发或运维的工作 —— 那怎么我在写一篇关于 DevOps 的文章？我一直都对计算机和技术有兴趣。我还对社群、心理学以及帮助他人充满热情。当我第一次听到 DevOps 时，这个概念激起了我的兴趣，因为它看起来融合了很多我感兴趣的东西，即便我是不写代码的。

我的第一台电脑是 TRS-80，我喜欢在上面编写 BASIC 程序。我只上过两门我的高中开设的计算机编程课程。若干年后，我创办了一家计算机公司。我定制邮件标签和信纸，并建立了一个数据库来存储地址。

问题是我并不能从写代码中获得享受。我想要教育和帮助人们，我没法将写代码看作这样的一个机会。是的，技术可以帮助人们并改变生活，但是写代码没有点燃我的热情。我需要对我的工作感到兴奋并做我喜欢的事情。

我发现我爱 DevOps。对我而言，DevOps 指的是：

• 文化，而不是代码
• 过程，而不是结果
• 建立一个所有人可以持续提升的环境
• 沟通与合作，而不是独立工作

归根结底，DevOps 是指成为社区工作的一部分，实现共同的目标。DevOps 融合了心理学、社群、技术。DevOps 不是一个职位名称，它是一种生活和工作的哲学。

找到我的社群

快四年前，我在西雅图参加了我的第一个 DevOps 日 会议。我感觉我找到了我的社群。我觉得受到了欢迎和接受，尽管我从事营销工作而且没有计算机科学文凭。我可以从心理学和技术中寻找乐趣。

在 DevOps 日，我学到了 DevOps“三步工作法” —— 流动、反馈、持续实验和学习 —— 以及新（对我而言）的概念，如 Kaizen（改善）和 Kaikaku（改革）。随着我的学习深入，我发现我在说这样的话，“我是这样做的！我都不知道这样做还有个名字！”

Kaizen（改善）是持续改进和学习的实践。小的量变积累随着时间的推移可以引起质变。我发现它和卡罗尔·德韦克的成长型思维的想法很相似。人们不是生来就是专家。在某方面拥有经验需要花费时间、练习，以及常常还有失败。承认增量的改善对确保我们不会放弃是很有必要的。

另一方面，Kaikaku（改革）的概念是指，长时间的小的改变有时不能起作用，你需要做一些完全的或破坏性的改变。在没有找到下份工作前就辞职或移居新城市就足够有破坏性 —— 是的，两者我都做过。但这些彻底的改变收获巨大。如果我没有辞职并休息一段时间，我也许不会接触到 DevOps。等我决定继续工作的时候，我一直听到 DevOps，我开始研究它。这引导我参加了我的第一个 DevOps 日，从那里我开始看到我的所有热情开始聚集。从那时起，我已经参加了五次 DevOps 日活动，并且定期撰写关于 DevOps 话题的文章。

将三步工作法用到工作中

改变是困难的，学习新事物可以听起来很吓人。DevOps 的三步工作法提供了一个管理改变的框架。比如：信息流动是怎样的？是什么驱动着你做出改变？一旦你认为一个改变是必需的，你如何获得这个改变是否正确的反馈？你如何知道你在取得进展？反馈是必要的，并且应该包含积极和有建设性的要素。困难的地方在于保证建设性的要素不要重于积极要素。

对我而言，第三步 —— 持续实验和学习 —— 是 DevOps 最重要的部分。有一个可以自由地实验和冒险的环境，人们可以获得意想不到的结果。有时这些结果是好的，有时不是太好 —— 但这没事。创建一个可以接受失败结果的环境可以鼓励人们冒险。我们都应该力争定期的持续实验和学习。

DevOps 的三步工作法提供了一个尝试，获得反馈，以及从错误中获取经验的方法。几年前，我的儿子告诉我，“我从来就没想做到最好，因为那样我就没法从我的错误中学到东西了。”我们都会犯错，从中获得经验帮助我们成长和改善。如果我们的文化不支持尝试和学习，我们就不会愿意去犯错。

成为社区的一部分

我已经在技术领域工作了超过 20 年，直到我发现 DevOps 社区前，我还经常感觉自己是个外行。如果你像我一样——对技术充满热情，但不是工程和运维那方面——你仍然可以成为 DevOps 的一部分，即便你从事的是销售、营销、产品营销、技术写作、支持或其他工作。DevOps 是属于所有人的。

via: https://opensource.com/article/18/11/how-non-engineer-got-devops

作者：Dawn Parych 选题：lujun9972 译者：alim0x 校对：wxy

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