分类 观点 下的文章

为防止感染新冠病毒的乘客登机,欧洲飞机制造商,空中客车公司正在研究能够识别病毒的物联网传感器。

一家开发传感器来探测飞机上和机场中的爆炸物和其他化学物品的生物技术公司正在和空中客车合作,一同开发一种可以检测已经感染新冠病毒乘客的传感器。

Koniku 的创始人兼首席执行管 Osh Agabi 在一篇博文中说,总部位于加州的 Konibu 公司和空中客车(Airbus)公司从 2017 年就开始合作共同开发能够探测出不同化学物质的非接触式设备。

他们希望通过识别从呼吸或者汗液中的气味来判断是否感染新冠病毒,因为这些气味可能是新冠病毒中化学物质的标记。“大多数感染和疾病都会或多或少的改变我们呼吸和汗液里的化学成分,也就会产生不同的气味,” Agabi 写道。“如果我们检测到这些气味,我们就可以检测是否存在感染。”

这两家公司希望能够识别这种新冠病毒的特异性标记,并且能找到一种可以检测这些标记的物联网(IoT)传感器,这些传感器配备有通过基因工程改造过的受体,从而对病毒进行探测。“那些受体会过滤空气中的分子,并且当它们接触到已经提前被编程检测的存在威胁或危险的分子化合物的时候,就会产生一个信号,”他写道。

他说,乘客将通过走过一个装有传感器的封闭通道来进行筛选。“通过对构成这些受体细胞中的 DNA 进行编程,使其对出现在感染者呼吸或者汗液中的化合物作出反应,我们相信,我们将能够迅速且可靠地筛查新冠病毒,并且确定一个人是否已经被感染,”他写道。

其他类型的非接触检测器已经在使用中了,包括 皮肤温度升高 elevated-skin-temperature (EST)摄像头。

意大利的最主要的机场 Leonardo da Vinci 购置了三个热成像头盔来发现发烧的人。机场已经配备了固定的热感应扫描仪,并且订购了更多的这种设备。根据当地媒体 Fiumicino Online 的报道,被发现潜在发烧的乘客被会要求做进一步的医学检查。

位于中国深圳制造这种头盔的 KC Wearable 公司表示,这种头盔可以由员工佩戴,并且可以与乘客保持一定的距离。

制造热感应摄像头的 FLIR Systems 公司在其本月的财报中表示,对 EST 系统的需求正在持续增加。

“尽管这些热感应摄像头不能检测或者诊断任何医疗状况,但这些摄像头可以作为识别皮肤温度升高的有效工具。”报告说。

FLIR 公司 CEO Jim Cannon 在本月的收入电话会议上表示,“许多公司都在寻求在他们的设施中安装这种技术,以便解除 就地避难 shelter-in-place 法令”。根据路透社报道,通用汽车就是其中之一。


via: https://www.networkworld.com/article/3543318/how-iot-will-rescue-aviation.html

作者:Patrick Nelson 选题:lujun9972 译者:Yufei-Yan 校对:wxy

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

JavaScript、Ruby 和 Java 是间接依赖中存在缺陷最多的生态系统。

开源项目中的绝大多数安全漏洞都存在于间接依赖关系中,而不是存在于直接加载的组件之中。

“汇总所有生态系统的数字后,我们发现间接依赖中存在的漏洞数量是直接依赖的三倍以上。”Snyk 的应用安全顾问 Alyssa Miller 在接受讨论 Snyk 的《2020 年开源安全状况报告》的采访时说。

该报告研究了漏洞如何影响 JavaScript(npm)、Ruby(RubyGems)、Java(MavenCentral)、PHP(Packagist)和Python(PyPI)生态系统。

Snyk 表示,项目内部加载的主要组件所依赖的依赖库,受到了 86% 的 JavaScript 安全漏洞、81% 的 Ruby 漏洞和 74% 的 Java 漏洞的影响。

Snyk 认为,公司在扫描他们的主要依赖项是否存在安全问题时,如果不能探索其完整依赖树的多个层次,会导致发布或最终运行容易受到不可预见的缺陷影响的产品。

但是,虽然安全缺陷在 JavaScript、Ruby 和 Java 中普遍存在,但在 PHP 和 Python 中却不是这样,绝大多数缺陷都存在于直接依赖关系(主要组件)中。当然,这是有原因的。

“老实说,我发现这更多取决于生态系统内部本身的开发方法。”Miller 说。“尤其是 Java 和 Node.js 项目,似乎比其他生态系统更重地利用了依赖性。特别是,当你看到 Node.js 生态系统的庞大规模时,从其他包构建或利用关键功能的包是非常正常的。”

“询问任何 Node.js 开发人员,他们都可能会遇到这样的事,即在 npm 试图拉取所有必要的依赖关系时,等待很长时间才能打开一个项目,”Miller 补充说。“我们最喜欢的一个例子是一个 80 行的 Java 应用程序,指定了 7 个依赖关系。然而,当你走完整个依赖树时,你会发现有 59 个子依赖,突然间,80 行代码变成了 74 万行。”

“正如我们喜欢给它起的绰号,这种‘陌生人的危险’,是一些重大安全漏洞的根本原因,也是造成软件供应链安全复杂化的关键原因,”Miller说。

少量的缺陷会造成了巨大的影响

但 Snyk 团队并不只是看这些缺陷在开源生态系统中的位置,还看它们是什么类型的缺陷。

另一个有趣的发现是,2019 年发现的大部分新安全漏洞都是跨站脚本(XSS)缺陷,尽管数量很多,但这些缺陷只影响了一小部分实际运行的项目。

相反,在去年发现的所有缺陷中,有二十几个原型污染缺陷的影响最大,影响了超过 11.5 万个不同的开源项目,可能还有更多的私有项目也受影响。其中,jQuery 和 LoDash 的原型污染缺陷影响最大,因为这些框架是目前应用最广泛的 JavaScript 开发工具集。

但是,Snyk 团队在报告中还指出了另一个不寻常的地方,即“恶意软件包”被列为他们去年在项目中发现的第二大最常见的安全问题类型。这指的是故意出于恶意创建的开放源代码库,或者是开发人员帐户被黑并且代码中毒的库。

根据 Snyk 的说法,去年,被黑的或恶意的软件包是开源生态系统中第二大最常见的安全问题来源。“这些绝大多数(超过 87%)来自 npm (JavaScript)软件包,” Miller 说。

去年的安全问题不那么严重,但也不值得庆祝

此外,Snyk 还指出,他们在所扫描的所有五个生态系统中发现的缺陷数量下降了 20%。

“很难确定(它们因为什么下降),”Miller 说。“以我这种永久安全怀疑论者来说,这可能只是自然的退潮和流动的一部分。然而,在乐观的一面,我们确实看到了社区的一些关键变化,这可能意味着这不仅仅是这一年的异常值。”

“例如,我们看到所报告的跨站点脚本(XSS)漏洞比任何其他漏洞类型都多,它们只影响了我们当年扫描的总项目中的一小部分。这表明,XSS 可能不会影响到使用率更高因而更成熟的项目,这意味着人们可能更多关注安全编码技术方面。”

“此外,我们的调查显示,整个社区的态度开始将软件安全视为开发团队和安全团队(甚至在某种程度上是运营团队)之间的共同责任,”Miller 说。

“这种合作的改善无疑可以帮助推动围绕安全代码和安全使用开源包的更好的意识和战术措施。”

“我在安全领域工作了 15 年,我当然还没有准备好宣布某一年是事情出现转机的标志,但你可以认为这是一个趋势,我们将继续观察,看看未来几个月和整个 2020 年的情况如何。”

关于开源社区总体安全状况的其他见解,Snyk 的完整报告可在这里下载


via: https://www.zdnet.com/article/more-than-75-of-all-vulnerabilities-reside-in-indirect-dependencies/

作者:Catalin Cimpanu 译者:wxy 校对: wxy

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

正如我们向读者承诺的那样,我们将对 Ubuntu 20.04 LTS 版本的所有主要特色版进行评测。在这个续篇中,我们将对 Ubuntu Budgie 进行评测。

顾名思义,Ubuntu Budgie 是使用 Budgie 桌面环境Ubuntu 官方特色版。这个版本是 Ubuntu 家族中较新的一位成员。Ubuntu Budgie 的第一个版本是 16.04,它在 17.04 版本时被接受为官方特色版。

他们的目标是“结合 Budgie 界面的简洁和优雅,以生产具有现代范式的面向桌面的传统发行版。”

Ubuntu Budgie 20.04 评测:哪些改变了,哪些没有!

自 18.04 LTS 发布以来,Ubuntu Budgie 有了令人惊讶的更新和改进:

  • 苹果风格的新菜单
  • 默认采用基于 Budgie 的网络管理小程序
  • 新的 Window Shuffler 允许你通过快捷键平铺应用程序
  • 快速切换桌面布局的新工具
  • 支持 4k 分辨率
  • 新的默认应用程序:GNOME Firmware 和 Drawing
  • 现在已经为 20.04 重构了向后移植包
  • 默认浏览器是火狐
  • 默认使用 Catfish 搜索文件和文本
  • 在 Budgie 中集成了 Nemo 文件管理器
  • 由于错误,系统托盘小程序被移除了
  • 默认情况下,事件警报声被禁用
  • 修复了键盘快捷键神秘失踪的问题
  • 更好的锁屏样式
  • 由于社区的需求,文件应用 Nautilus 已被 Nemo 取代
  • Plank 坞站现在已经切换到屏幕底部,是透明的,并且默认有弹跳动画
  • 快速笔记和热角小程序已从 Python 移植到 Vala,以提高速度
  • Celluloid 取代了 MPV
  • 更新了 GNOME 的依赖性

Ubuntu Budgie 现在随附了 Budgie 桌面环境的最新版本(10.5.1)。改进包括:

  • 在 Budgie 桌面设置中新增 Raven 部分
  • Raven 通知可以分组,通知可以关闭
  • 重新打造了图标任务列表
  • 能够设置虚拟桌面的数量

Ubuntu Budgie 自带了大量的 Budgie 小程序 applet 微应用 min-app 。它们可以通过 Ubuntu Budgie “欢迎”应用来安装。

  • WeatherShow:显示未来五天的天气预报,每 3 小时更新一次
  • Wallstreet:一个可以循环展示你的图像文件夹中的壁纸工具
  • Visual-space:一个紧凑的工作区切换器
  • Dropby:这个小程序可让你在面板上快速管理 U 盘
  • Kangaroo:从面板上快速浏览文件夹
  • 垃圾桶小程序:管理你的垃圾桶
  • Fuzzyclock:以模糊的方式显示时间
  • 工作区秒表:允许你跟踪在每个工作区花费的时间

完整的变更和更新列表,请访问变更日志

系统要求

Ubuntu Budgie 20.04 更新了系统要求

  • 4GB 或以上的内存
  • 64 位的 Intel 和 AMD 处理器
  • 在 CSM 模式下启动的 UEFI 电脑
  • 基于英特尔的现代苹果电脑

如你所见,Budgie 并不是一个真正的轻量级选择。

安装的应用

Ubuntu Budgie 中默认包含了以下有用的应用程序:

  • AisleRiot Solitaire
  • Geary
  • Catfish 搜索工具
  • Cheese 网络摄像头工具
  • GNOME Drawing
  • GNOME 2048
  • GNOME Mahjongg
  • GNOME Mines
  • GNOME Sudoku
  • Gthumb
  • LibreOffice
  • Maps
  • Rhythmbox
  • Tilix
  • Ubuntu Budgie 欢迎应用
  • Evince 文档查看器
  • Plank
  • Celluloid

安装

起初,我无法让 Ubuntu Budgie 进入 即用 live 环境来安装它。结果发现 Ubuntu Budgie 试图通过 EFI 来启动,我从 Ubuntu Budgie 论坛得到了解决方案。

当出现紫色的闪屏时,我必须按下 ESC 键并选择 legacy。之后,它就如常启动了,安装也没有问题了。我只在 Ubuntu Budgie 上遇到过这个问题。我下载并尝试了 Ubuntu MATE 20.04 ISO,但没有遇到类似的问题。

Ubuntu Budgie 20.04 的体验

除了这个安装上的小问题,我使用 Ubuntu Budgie 的体验非常愉快。自 Ikey 第一次创建 Budgie 桌面以来,Budgie 桌面已经进步了很多,并且已经成为一个非常成熟的选择。Ubuntu Budgie 的目标是“生产一个面向桌面的传统发行版”。它确实做到了极致。他们所做的所有改变都在不断地为他们的产品增添更多的光彩。

总的来说,Ubuntu Budgie 是一个非常漂亮的发行版。从默认的主题到壁纸选择,你可以看出他们付出了很多努力,视觉体验非常吸引人。

需要注意的是,Ubuntu Budgie 并不适合低配置的系统。我在戴尔 Latitude D630 上运行它。在没有打开任何应用程序的情况下,它使用了大约 700MB 的内存。

在 Ubuntu Budgie 中,让我喜欢的部分超乎我的预期,其中一个部分是 Tilix 终端模拟器。Tilix 允许你在右侧或下方添加终端窗口。它有很多很多功能,我简直爱死了它,我打算在我的其他 Linux 系统上也安装它。

关于 Ubuntu Budgie 20.04 的最后感想

Ubuntu Budgie 是众多官方版本中一个很受欢迎的新版本。Budgie 给人的感觉非常流畅和精致。它不会让你觉得碍手碍脚,而是帮你完成工作。

如果你厌倦了当前的桌面环境,想体验一下新的东西,不妨来看看。如果你对当前的环境感到满意,那么就试试 Ubuntu Budgie 的即用 DVD。你可能会喜欢上它。

你是否已经尝试过 Ubuntu 20.04 Budgie?你对它的使用体验如何?如果没有用过,你现在使用的是哪个版本的 Ubuntu 20.04?


via: https://itsfoss.com/ubuntu-budgie-20-04-review/

作者:John Paul 选题:lujun9972 译者:wxy 校对:wxy

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

我所参与的开源项目遵循的是一种这样的理念,我把它描述为 “先讨论,再编码”。我认为一般来说这是开发软件的好方法,我想花一点时间来谈谈这种方法的好处。

避免伤害感情

先讨论你想做的改变最重要的原因是避免伤害感情。我经常看到一个贡献者闭门造车地提交了一个 PR,却发现他的努力工作被拒绝了。这可能有一堆原因:PR 太大了,PR 没有遵循本地风格,PR 修复了一个对项目不重要的问题或者最近间接修复了的问题,等等。

这些问题的根本原因都是缺乏沟通。“先讨论,再编码” 理念的目标不是阻碍你或给你带来挫折,而是确保一个功能第一次就能正确落地,而不至于产生大量的维护债务。无论是改动的作者,还是审查者,当一个改动突然出现时,并暗示说 “好吧,我已经做完了,你要做的就是合并它,对吧?”,先讨论可以让他们不必背负伤害感情的情绪负担。

讨论应该如何进行?

每一个新功能或错误修复都应该在工作开始前与项目的维护者讨论。私下试验是可以的,但不要在没有讨论之前就发送修改。

对于简单的改动,“讨论” 的定义可以只是 GitHub 议题中的一个设计草图。如果你的 PR 修复了一个 bug,你应该链接到它修复的 bug。如果没有,你应该先提出一个 bug,等待维护者确认后再发送 PR。这可能看起来有点落后 —— 谁不希望一个 bug 被修复呢 —— 但考虑到这个 bug 可能是对软件工作方式的误解,也可能是一个更大问题的症状,这需要进一步调查。

对于比较复杂的改动,尤其是功能请求,我建议在发送代码之前,先分发一份设计文档并达成一致。这不一定是一个完整的文档,发一个议题,带个草图可能就足够了,但关键是在用代码搞定之前,先用文字达成一致。

在任何情况下,你都不应该继续发送你的代码,直到维护者同意你的方法是他们所满意的。拉取请求是日常生活,而不仅仅是为了赶着过节。

代码审查,而不是由委员会设计

代码审查不是争论设计的地方。这有两个原因。首先,大多数代码审查工具都不适合长长的评论会话,GitHub 的 PR 界面在这方面非常糟糕,Gerrit 比较好,但很少有管理员团队会维护 Gerrit 实例。更重要的是,在代码审查阶段就出现了分歧,说明大家对如何实现这个变化并没有达成一致。


讨论你想写的代码,然后再写你所讨论的代码。请不要反其道而行之。


via: https://dave.cheney.net/2019/02/18/talk-then-code

作者:Dave Cheney 选题:lujun9972 译者:wxy 校对:wxy

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

推出于 2011 年的 GNOME 3,其 GNOME Shell 迎来了社区的赞扬的同时,也招致了一些人的反对。很多用户和开发者都很喜欢原来的 GNOME 界面,以至于有几个小组复刻了它,其中的一个小组 —— Linux Mint 团队创建了 Cinnamon 桌面环境)。

Cinnamon 桌面成为了 Linux Mint 的标志型产品。多年来,Cinnamon 一直是 Linux Mint 的代名词。在过去的几年里,随着 Cinnamon 的普及,这种情况略有改变。现在其他发行版也开始提供 Cinnamon 桌面环境,Manjaro 就是这样一个例子。

几个月前,我们向大家介绍了一个新 Ubuntu 变体,它提供了开箱即用的 Cinnamon 桌面体验,今天就让我们来深入了解一下 Ubuntu Cinnamon Remix

为什么是 Ubuntu Cinnamon Remix 而不是 Linux Mint?

的确,Linux Mint 是基于 Ubuntu 的,很多 Linux Mint 的用户都会有这样的疑问:既然 Linux Mint 已经如此成熟,而且用户体验也大致相同,那么换成 Ubuntu 有什么意义吗?

Ubuntu Cinnamon Remix 与 Linux Mint 有很多小的区别,但有一个关键的区别是 Linux 爱好者不能忽视的。

Linux Mint 是基于 “LTS”(长期支持)版本的 Ubuntu,这意味着它一直落后于 Canonical 的 6 个月的更新节奏。Ubuntu Cinnamon Remix 则可以得益于较新的内核以及其他 6 个月周期内的功能升级和较新的软件。

另一个关键的区别是,Ubuntu Cinnamon Remix 将 “继承” Snap 支持,而 Linux Mint 则拥抱 FlatPak。Ubuntu Cinnamon Remix 使用 Ubuntu 软件中心而不是 Mint 软件管理器。

我是 Cinnamon 的忠实粉丝,所以我选择了评测这款 Ubuntu 和 Cinnamon 的混合版,在这里我分享一下我的体验。

体验 Ubuntu Cinnamon Remix

只要有机会,我总会提到 Calamares 安装程序有多快,感谢 Ubuntu Cinnamon Remix 团队如此选择。

新安装的 Ubuntu Cinnamon Remix 会消耗大约 750 MB 的内存。这与 Linux Mint Cinnamon 非常相似。

美丽的 Kimmo 主题和橙色调的 Ubuntu 壁纸也给我留下了深刻的印象,看来这是一个非常细致的努力的结果。

足够让你开始的工具

和其他 Ubuntu 发行版一样,Ubuntu Cinnamon Remix 也包含了一些重要的生产力工具,下面是其中一些:

  • 火狐浏览器
  • Thunderbird - 电子邮件客户端
  • LibreOffice套件
  • Celluloid - 多媒体播放器
  • GIMP - 图像处理软件
  • Synaptic 软件包管理器
  • Gnome 软件中心
  • Gparted - 分区管理器

使用 Ubuntu Cinnamon Remix 作为我的主要平台已经有几天了,它满足了我的高期望。Ubuntu 稳定如磐石,速度非常快,在日常工作中我没有遇到任何问题。

给 Linux Mint 爱好者的 Ubuntu

你是否热衷于 Ubuntu Cinnamon,却习惯了 Linux Mint 主题?点击下面的内容,看看如何获得一个完整的 Linux Mint 主题包,以及如何配置它来保持 Ubuntu 的传统。

给 Ubuntu Cinnamon Remix 以真正的 Mint 感受:

首先你必须下载并解压以下内容,通过终端很容易完成。

获取 Linux Mint-X 图标包:

wget http://packages.linuxmint.com/pool/main/m/mint-x-icons/mint-x-icons_1.5.5_all.deb

获取 Linux Mint-Y 图标包:

wget http://packages.linuxmint.com/pool/main/m/mint-y-icons/mint-y-icons_1.3.9_all.deb

获取 Linux Mint 主题:

wget http://packages.linuxmint.com/pool/main/m/mint-themes/mint-themes_1.8.4_all.deb

安装下载的软件包:

sudo dpkg -i ./mint-x-icons_1.5.5_all.deb ./mint-y-icons_1.3.9_all.deb ./mint-themes_1.8.4_all.deb

完成后,点击左下角的菜单按钮,输入 “themes”。你也可以在系统设置中找到“主题”功能。

打开后更换 kimmo 图标和主题,如下图所示。Linux Mint 默认的“绿色”是普通的 Mint-Y,而橙色是 Ubuntu 的最佳选择。

为 Cinnamon 迷们准备的美食

让我们承认吧,审美很重要。Cinnamon 拥有简洁优雅的外观、易于阅读的字体和漂亮的色彩对比主题。Cinnamon 提供了一个整洁的桌面,只需进入系统设置下的桌面菜单,即可轻松配置桌面图标。你也可以选择桌面图标只显示在主显示器上、只显示在副显示器上,或者同时显示在两个显示器上。这也适用于超过两台显示器的设置。

桌面组件和小程序是一种小型的、单一用途的应用程序,可以分别添加到你的桌面或面板上。在众多的应用程序中,最常用的是 CPU 或资源监控器、天气小程序、便签和日历。

Cinnamon 控制中心集中提供许多桌面配置选项。通过访问 “主题” 部分,你可以选择桌面基本方案和图标、窗口边框、鼠标指针和控件外观。字体对桌面的整体外观有很大的影响,而 Cinnamon 让改变字体比以往任何时候都要容易。

Cinnamon 控制中心配置对新用户来说也足够简单,相比之下,KDE Plasma 会因为大量的配置选项而导致新用户感到困惑。

Cinnamon 面板包含用于启动程序的菜单、基本的系统托盘和应用程序选择器。面板的配置很简单,添加新的程序启动器只需在主菜单中找到你要添加的程序,右击图标,选择 “添加到面板” 即可。你也可以将启动程序图标添加到桌面,以及 Cinnamon 的 “收藏夹” 启动栏中。如果你不喜欢面板上图标的顺序,只需在面板栏上点击右键,进入面板的 “编辑” 模式,重新排列图标即可。

结论

无论你是决定给你的桌面 “加点料”,还是考虑从 Windows 迁移到 Linux,Cinnamon 社区都为你制作了大量的香料。

传统而又优雅,可定制而又简单,Ubuntu Cinnamon Remix 是一个有趣的项目,前途无量,对于喜欢 Ubuntu 的 Cinnamon 桌面爱好者来说,这可能是一个不二之选。

你觉得 Ubuntu Cinnamon Remix 怎么样?你已经使用过它了吗?


via: https://itsfoss.com/ubuntu-cinnamon-remix-review/

作者:Dimitrios Savvopoulos 选题:lujun9972 译者:wxy 校对:wxy

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

导读:本文介绍了开源项目 KubeSphere 背后的故事,以及由它引发的对开源软件发展的思考。

从一个开源项目的数据说起

作为一家主要关注于开源的技术社区,我们每年都会对以中国贡献者为主的开源项目进行一次分析。而随着云计算的发展,我们对由云计算公司发起和推动的开源项目愈加重视,在研究分析过程中,我们发现了一个开源项目的数据表现亮眼,这引起了我们对这个项目背后团队的兴趣。

图 1 KubeSphere Grank 指标图

这个项目就是 KubeSphere。和其他同类项目相比,KubeSphere 项目的启动时间不算早,2018 年初才启动。但从启动开始,社区的活跃度就屡创新高。从上面的 Grank 指标图可以看出,其在 2019 年度的整体活跃度(红色线)相当高,并在今年有继续提升的趋势。而其平均活跃度指数 6.89 可以排入 Grank 服务端分类榜的前三十。

刚好,这个项目背后的负责人我们也很熟悉,之前曾经在《穿山甲专访》栏目中接受过采访——周小四(人称“四爷”),如果你感兴趣,也可以看看之前的采访文章

如今一年过去了,为了了解现在 KubeSphere 项目有什么新的变化,我又和他约时间,再次聊聊 KubeSphere 的发展和下一步的计划,得到一些新的发现和体悟。

KubeSphere:“青云”之路

谈起 KubeSphere ,容我先简单介绍一下背景。

随着云计算技术的发展,容器编排技术 Kubernetes 已经成为云服务商们的角逐重点。按照 Kubernetes 的理念,它定义的是一套标准、一个生态规范,因此,各个生存于其间的云服务商纷纷基于 Kubernetes 推出了各自的发行版和相关的生态软件。

这其中既有 Rancher、OpenShift 这样复杂完备的的企业级平台,也有 minikube、k3s 这样简单易用的实验型工具。而今天我们提到的主角 KubeSphere就是一款开源的企业级 Kubernetes 发行版,与其外延的其它组件组成了一个完备的容器生态体系。

事实上,我们可以看到,几乎所有的主流云服务商都开发了 Kubernetes 引擎(KE),比如说 TKE、RKE、AKE 等等,并以此作为其基于容器的云服务基础。当然,这些软件作为开源软件生态的一分子,都或早或晚进行了开源。

而作为青云QingCloud QKE 服务的引擎,KubeSphere 也是其中的佼佼者,并且,值得注意的是,KubeSphere 从一开始就选择了开源,并以开源作为其产品迭代发展的模式。

相比 Kubernetes 领域的其它厂商,KubeSphere 的进入时机不算早,因此,在这种情况下仍能推动决策立项,应该压力不小。周小四和我说,他们当时深入调研和分析了企业的市场需求,发现在该领域尚存在较大的产品空隙。固然,Kubernetes 为企业级容器应用揭晓了新的篇章,但广泛的企业用户在如何用好 Kubernetes 层面,需要突破较多的技术门槛和业务适配的阻碍。因此,他认为,在该领域仍大有可为,这一建议也得到青云QingCloud 的大力支持。

而另外一方面,作为一家国内主流的企业级云服务商,青云QingCloud 也一直在密切跟进 Kubernetes 领域的技术发展和产品形态。所谓磨刀不误砍柴功,正是这一年多提前付出的预研投入,让周小四及其团队在2018 年初开始 KubeSphere 的研发时,就能迅速发布经过了精心设计的 KubeSphere,并于半年后在青云QingCloud IaaS 基础设施之上推出了 QKE——KubeSphere on QingCloud 容器服务。

图 2 KubeSphere 路线图

倏忽间过去了两年,KubeSphere 也即将迭代到 3.0,对于它发展至今,并取得今天的成绩,周小四认为主要得益于以下原因:

  • 天时:站在 Kubernetes 的肩膀上,处于容器技术的大时代;
  • 地利:开源为它赋予了成长为参天大树的土壤;
  • 人和:来自团队和社区贡献者对容器技术的深刻理解、对用户需求的精准把握和在产品设计上的匠心独运。

KubeSphere 的天时

扑面而来的云原生时代,是机遇也是挑战。这里,我们看到了 Docker 公司如荧惑一样迅速升起又快速淡去,我们也看到了谷歌力推的 Kubernetes 从天下三分到一统容器编排领域,真正揭开了云原生时代的大幕。

并不是每个身处大潮之中的都是弄潮儿。说实话,这些年我看过很多云计算领域的企业或因押错注而不得不更弦易辙,或因产品没有足够的独特优势而泯然众人。对于一家国内主流的企业级云服务商,青云QingCloud 不仅一早看好 Kubernetes,又没有匆匆下场,更在局势渐明时能决然重兵压上,其实我是有些佩服和羡慕的。

在和周小四的对话中,他说,在潜心研究了 Kubernetes 生态一年后,青云QingCloud 才正式立项,并由他带队开发运营 KubeSphere 容器平台。谈话间,生性乐观的周小四并没有表现出曾经面对的困难和压力,但是如果易位而处,我能感受到他的那种魄力和信心。

KubeSphere 的地利

那么,KubeSphere 的地利是什么?是开源。

有一个强大而完善的团队,确实可以打造一款好产品,有可能取得一时之胜。但是,时代如汤汤大河,如今开源已经成为数字世界的血脉,触达和营养了各种互联网技术的急速发展。

在21世纪的第二个十年间,连微软都已经摇身一变,成为了世界上最大的开源企业之一,可以说,开源已经成为了一种时髦的技术文化,它从一种软件分发和开发模式,变成一种可以以之为脉络的商业模式。但是,开源到底只是一种时髦文化、用来迎合大众和媒体的流行词,还是可以赖之生存和发展的一种机制呢?

在这方面,我们看到了企业在开源领域的众生相,略举几例:

  • 买椟还珠式开源:有的公司是只是希望贴上开源的标签,并不真正了解开源对公司的实质价值,也无从将开源的好处和公司的发展机制相结合,空耗人力与财力,甚至没能给开源世界带来什么贡献。
  • 叶公好龙式开源,有的公司的开源成为了技术部门的 KPI 工具,他们并不真正依赖开源来提升软件质量和改善软件的业务生态,甚至害怕开源伤害到公司以专有代码建立起来的业务护城河;
  • 竭泽而渔式开源,还有的公司对待开源则是奉行“拿来主义”,只有索取和利用,而不对开源软件和开源社区做出适当的回哺,甚至倒逼一些开源软件纷纷修改其许可证,避免被吸血。

而作为 KubeSphere 项目的负责人,周小四认为青云QingCloud 是真正把开源做为一条切实可行的发展路线的

周小四认为,虽然目前开源领域看起来热闹非凡,但是真正可以称之为成功的、健康的、可复制的开源模式尚寥寥无几,失败者并不鲜见。而青云QingCloud 作为一家主流的企业级云服务商,根植于云技术之上,已经找到了一个切实可行的开源模式。周小四说,“公司(青云QingCloud)给予了强有力的支持,希望 KubeSphere 可以走出一条新的开源模式路线来,真正践行开源的思想和路径。”

KubeSphere 的人和

说完了天时、地利,让我们再来看看 KubeSphere 成功背后的人和。

对于一位资深的技术专家来说,精通云计算技术并能跟上全球云时代的技术浪潮,并不算最难的挑战,难的在于可以站在技术之外看到用户需求、用户体验和产品运营之道。

在对话中,周小四和我说,他很幸运,“总是能在对的时候找到对的人”,因此 KubeSphere 的各个细节才处理得很好。这里他专门提到了 KubeSphere “特别易用的前端界面”和“丰富完备的中英文文档”,并特别庆幸每次总能找到最好的伙伴们来做这一切。当然,这些都是建立在精心设计的架构和底层 API 之上的,只是想必这部分是周小四亲自操刀的,但他并没有专门提及。

而我想,在这样的一个团队中,有这样的一位领头羊,也是一种幸运吧。

图 3 KubeSphere and Friends

开源是如何为 KubeSphere 添砖加瓦的

缘何开源可以为 KubeSphere 提供助力呢?这是由开源模式本身的优势所决定的。

或许有些人直觉上会感到意外,开源本身并不会因代码的公开,导致该软件及软件背后的企业或组织丧失竞争力。事实上,几乎不存在一段极其精妙的代码可以形成长久的优势,更重要的是,在软件的发展过程中的工程能力才是真正的竞争力,这一点,其实和开源与否并无直接的联系。

那么既然开源对竞争力并无负面影响,是否有正面的影响呢?

有的。

首先,无论是什么软件,其必然要满足各种不同场景需求,才能与时俱进,不断发展下去,而该软件的团队和决策者往往并不能照顾到(或遇到)各种场景,也不一定总是能做出最佳选择。但是在开源模式下,由于代码是公开的,总会有层出不穷的用户场景,这些意料之内或之外的场景和需求,极大地刺激了开源软件的生命力。

其次,通过开源极大地降低了用户接触门槛,因为用户可以近乎无成本地接触和使用这些开源软件,并在满足场景需求和形成知识领域之后,还会进一步的扩散该软件的传播范围,而这本质上是对用户和市场的争夺。

最后,通过开源,软件的参与者就不仅仅是内部团队了。不限于对代码的贡献,任何提出错误反馈、功能需求,甚至寻求帮助的用户,都能加速代码的迭代和发展。一个快速迭代的软件,其活力远不是闭门造车所能比拟的。

而在 KubeSphere 中,对于以上几点的践行,实实在在地收获到了成绩。

KubeSphere 的开源成绩

从 KubeSphere 的 GitHub 仓库的活跃度看,来自青云QingCloud 和社区贡献者的提交、 议题 issue 都非常活跃。周小四还说,“我们的项目的 星标 Star 数现在有三千多,有人分析过,星标的质量很高,它们来自于全世界各地。”这意味着,KubeSphere 已经取得了社区的一定认可。而且,社区用户也在主动地自发向更多的人去推荐 KubeSphere,提到这一点,周小四的振奋之情让我感同身受。

图 4 KubeSphere 星标增长图

从上图的星标增长趋势来看,KubeSphere 的用户关注度在持续地自然增高。

在我们对开源项目的评判当中(Grank 模型),有两个重要的维度:

  • 项目活跃度:通过项目的提交、拉取请求、贡献者等数据的变化幅度计算得来的一个指标;
  • 项目健康度:通过项目的社区化程度来判断项目的健康发展程度。

从文章开始部分的图 1 可以看到,KubeSphere 的活跃度能维持在较高水准上。尤其是经过了最近几个月的全球性疫情之后,KubeSphere 的项目活跃度再次取得了新高。如果维持这个发展态势,KubeSphere 的变化将日新月异。

社区化

而 KubeSphere 项目的健康度,我们可以从图 1中看出,来自社区的代码贡献者的比例并不算很高,这对于一个由企业主导推动的开源项目来说,属于正常水准。但在代码贡献者之外,据周小四称,目前 KubeSphere 的社区活跃度还是很不错的,从社区支持的多个交流平台,如国内用户惯用的论坛、微信群,到国际用户惯用的 Slack、邮件列表等,都有很多活跃的贡献者和用户。而另一方面,KubeSphere 的独立下载量已经达上万次,周小四表示,他的目标是这个数量将来可以进一步提升到十万、百万级别。

目前的贡献者除了青云QingCloud,还有来自本来生活、中通、VNG 等海内外多家企业,并且还有不少社区的独立开发者希望能够更多地参与到 KubeSphere 的直接贡献当中。但是从目前看起来,晋升为 KubeSphere 的核心开发成员的外部贡献者占比还不够高,主要还是来自于青云周小四说,他们还在着手丰富 KubeSphere 贡献者生态,主要努力方向在以下两个方面:

  • 一方面,在如何降低贡献者的贡献门槛方面,比如文档、代码规范、贡献流程方面不断地改进和完善;
  • 另一方面,由于 KubeSphere 本身迭代速度较快,新的功能不断推出、原有功能不断改善,在高歌猛进的同时,一些需要夯实的基础性工作,比如国际化、教程、bug修复和用户需求管理方面继续加大投入更多的人力。

周小四说,他希望 KubeSphere 是属于社区的开源项目—— 这一点,从项目本身的 GitHub 仓库放在 KubeSphere 组织下可见初心。对此,周小四也设定了一个评判标准,什么时候 KubeSphere 社区的技术委员会(TOC)里面,除了青云QingCloud 的人员以外,还有其它公司或社区的成员,才叫真正的成功

图 5 KubeSphere 社区组织图

对于一个开源项目的发展,周小四有着清晰的认知,从最初的产品设计,到进一步成熟迎来更多用户,再到社区成员参与贡献并走到更高的社区决策层面,都标志开源社区的开放性和健康发展。

图 6 GitHub 数据

生态化

作为云原生领域的生态软件,KubeSphere 坚持完全开源和开放的迭代思路,联合多个企业与开源社区,共同打造了以 KubeSphere 容器平台为核心的开源项目。

除了集成主流的开源组件如 Jenkins、Istio、Prometheus 等,还围绕 KubeSphere 开源了 Porter、OpenPitrix、KubeKey、Kube-events、Fluent-bit Operator、Notification Manager、CSI 插件等 80 余个开源项目,甚至 Porter——面向裸金属环境的 Kubernetes 开源负载均衡器这样优秀的子项目已经进入了 CNCF 云原生全景图。

国际化

但是,KubeSphere 并没有满足于当前的发展,而是更积极地谋求国际化发展。周小四说,得益于该项目在发展之初就以国际化为目标,其文档、社区交流,除了立足于中国本土的中文环境之外,国际化是在创立之初就从头贯彻的。甚至,他还专门招聘有国际化社区运营经验的人员来负责全球社区建设和运营。

然而这些努力并没有白费,他发现最近几个月以来,KubeSphere 的国外下载量已经超过了国内的下载量,其贡献者中也不乏来自于中国以外各个国家和地区的技术爱好者和用户。甚至还有国外的公司主动联系他们,希望共同合作建立欧洲市场和社区,并提供相关的本地化工作。

周小四说,对于 KubeSphere 来说,开源的属性为其带来了天然的全球化属性,但让 KubeSphere 真正的成为一个全球化项目,正是他寄予期望的目标之一。

结语

有人说,一叶而知秋,我们讲开源讲了这么多年,也从心里认可和推行开源思想,但是只有我们真正在具体的项目中践行开源的理念,

我也希望读者可以从这样一个具体的项目中,观察和吸收到开源模式的精粹,我觉得,是时候在你的下一个,不,现在手里的这个项目开始,落地开源思维了。你说呢?

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

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