技术委员会的改变

在过去的 2020 年年尾，技术委员会经历了第一次增改选，团队的规模从7人增加到17人。这次变动的根本原因是社区快速发展，需要一个更大的领域间合作讨论平台。这次新增的技术委员会委员中，既有各家厂商的资深从业者，也有社区里广受尊敬的“老神仙”，还有华为公司在各个领域的专家。如果说共同点的话，这些伙伴们在 2020 都深度参与了 openEuler 社区的运作，也对openEuler的发展贡献良多。

卞乃猛 bian_naimeng@hoperun.com [@biannm]
陈祺德 dillon.chen@turbolinux.com.cn [@dillon_chen]
冯健 jian.feng@i-soft.com.cn [@hostfj]
郭寒军 guohanjun@huawei.com [@hanjun-guo]
侯健 houjian@kylinos.cn [@hjimmy]
胡欣蔚 huxinwei@huawei.com [@shinwell_hu]
姜振华 zhenhua.jiang@huawei.com [@Ronnie_Jiang]
刘金刚 liujingang09@huawei.com [@liujingang09]
李永强 liyongqiang10@huawei.com [@charlie_li]
马全一 eli@patch.sh [@genedna]
石勇 shiyong@kylinos.com.cn [@stonefly]
王建民 jianmin@iscas.ac.cn [@jianminw]
王志钢 wangzhigang17@huawei.com [@cellfaint]
魏伟 weiwei64@huawei.com [@wweiandrew]
吴峰光 wufengguang@huawei.com [@wu_fengguang]
熊伟 xiongwei888@huawei.com [@myeuler]
叶青龙 yeqinglong@uniontech.com [@yeqinglong01]

大家基于不同的背景和出发点，分享共同的愿景。希望在2021年里，通过各位小伙伴的共同努力，把 openEuler 社区运作的更好。

1月新成立的 SIG

到1月底，openEuler 社区已经有了 77 个 SIG，我们借助一张图来更直观的展示下。新增的SIG用红色的星号做了标记。

其中，Container SIG 改名为 Cloud Native SIG。经过多方协调，新的SIG负责的范围扩大了。包括 OKD SIG 中维护的基础软件包也已经并入了 Cloud Native SIG。相应的，Kubernetes SIG更名为 KuberSphere SIG，后续会更加聚焦。openEuler 的公众号近期也会有专文阐释,欢迎大家关注。

Cloud Native SIG是一个非常重要的SIG，它承载了openEuler云原生的重要工作，也是未来openEuler 21.09的核心特性之一。希望该SIG能将openEuler带入到激动人心的云原生时代。

新成立的Compliance SIG是由开源软件专家高琨 (@king-gao)所发起，也得到了麒麟信安和润和的积极响应。这个SIG的目标是帮助快速发展的 openEuler 社区满足合规要求，包括社区中片段引用代码带来的版权风险，不同开源软件组件的License自动化识别，以及对License之前潜在冲突的提前分析。我们也希望Compliance SIG能够为国内的软件合规做出样板，同时能够积累出一系列软件工具，为行业提供公共的能力服务。

朱家法(@wl1587)和吕修任(@lllxxxrrr)在 openEuler 中发起了面向嵌入式场景的 Embedded SIG。这个SIG主要关注将 openEuler 中的开源组件，通过裁剪定制，形成更加适合嵌入式环境中使用的版本。这也是社区走向多样化的必经之路。我们也希望通过Embedded SIG将openEuler社区打造成端、边、云一体化的基础设施平台，同时真正实现整个架构设计的“榫卯”化。

OPS SIG则是社区已经酝酿了很久的SIG，内核热替换等关键技术，将通过这个SIG的工作，进入 openEuler 社区和版本。在21.03这个即将发布的版本中，大家将会见到这个期待已久的新特性的正式亮相。

除了这些之外，1月最意外的，还要算袁德俊老师(@yuandj)申请的 minzuchess （民族棋）这个SIG。袁老师一直致力于推广人工智能与中国非遗文化传承的结合。这次在社区申请成立的SIG，也是希望通过共性技术沉淀，让青少年可以参与到多民族多游戏样本的开发中来。之前没有想到过 openEuler 社区还会和青少年教育，民族文化传承等建立联系。要感谢袁老师和这个SIG的导师王建民(@jianminw)，让我们看到了 openEuler 跨界的可能。随着开源文化在国内的逐步推广和深入人心，我们相信这样的跨界还会发生。

20.03 LTS SP1 发布

2020 年 12 月的最后一周，openEuler 20.03 LTS 的第一个 SP 版本发布了。这个版本中对操作系统内核、虚拟化，JDK 等领域都做了一定的增强，修复了306个已知的安全漏洞，更重要的是集成了社区伙伴们贡献的 UKUI 桌面，DDE 桌面，Pacemaker + Corosync 高可靠集群软件等解决方案。

围绕第一个SP版本的发布，Release Management SIG和社区合作伙伴对于 openEuler LTS 的维护策略有非常多的讨论，技术委员会也看到不少下游的用户希望能够就维护策略做进一步的讨论。

对于 openEuler 的维护策略的讨论，本质上是社区需要给合作伙伴和用户对未来的一个明确预期。而从技术委员会的角度，我觉得更重要的是先对 “LTS” 有个统一的认识。

忒休斯之船

古希腊作家普鲁塔克讲过这样一个传说，忒休斯回雅典时乘坐的30桨船被雅典人作为纪念碑保留下来，随着时间流逝，木材腐朽，而雅典人会用新的木头来替代。最后，船上每一根木头都被换过了。那这艘船，还是原来的忒休斯之船吗？

我们看两个例子：从用户态软件的角度，CentOS 在 7 系列生命周期中，用户态软件的变化：

版本	软件总数	新增	删除	版本更新	同版本二进制不兼容	完全未变化
7.0	2481	NA	NA	NA	NA	NA
7.1	2523	43	1	167	228	2085
7.2	2587	68	4	323	303	1893
7.3	2640	54	1	219	334	2033
7.4	2682	60	18	413	242	1967
7.5	2743	61	0	214	283	2185

基本上来说，每个小版本升级，大约有 20%~30% 的用户态软件会发生变化。这里有一些是因为版本的更新，有一些版本未变但是因为二进制不兼容而做了重新构建。

而对于系统最基本的内核来说，虽然版本号未变化，但内核的接口也是在不断演进的，还是用CentOS 作为例子：

	内核接口总数	8.0 -> 8.1 KABI变化	8.1 -> 8.2 KABI变化	8.0 -> 8.2 KABI变化
数量	18903	6324	5755	7963
比例	100%	33.4%	30.4%	42.1%

从CentOS 8发布到现在，已经有超过 40% 的内核接口二进制不再兼容。

这是不是和传统中“长期稳定版本”一成不变的印象不太一样呢？

像 openEuler 这样集成了大量的开源软件，每个软件自己的演进节奏，兼容性保持和版本维护策略，都是不一样的。我们的挑战，就是把零散不同的演进节奏，兼容性保持和版本维护策略，整合而形成一个统一的策略。

像一条忒休斯之船，无时无刻不在变化，但又不让人觉得有变化。

openEuler 维护策略发展方向

openEuler 社区在2020年就软件包的管理策略有过长时间的讨论，最新版本归档在这里：

https://gitee.com/openeuler/community/blob/master/zh/technical-committee/governance/software-management.md

其中明确提到，对LTS软件版本生命周期内的软件选型要求，以及软件升级时要关注的差异分析要求。

与之相对应的，openEuler 也在 CI 中设立了兼容性检查的门禁，每一次提交，都会触发系统自动对ABI的变化进行检查。比如：https://gitee.com/src-openeuler/poppler/pulls/10 中，我们看到 check_abi 被自动执行，并且结果也能直观看到。当一个软件本身的兼容性变化被检查到时，相应所有依赖这个软件的组件，都会被触发做相应的修改。

但从社区到用户场景，还有很大的鸿沟需要越过。

在当前的用户场景中，软件兼容性大部分情况下都只是一个抽象的概念，这使得软件变更的影响像个混沌系统。太平洋西岸的蝴蝶扇动翅膀，可能会造成太平洋东岸的飓风。

我们就遇到过这样的情况，因为一个内核接口的变更，造成 NVIDIA 驱动必须随之升级，而驱动的升级又要求上层的 CUDA 版本升级，新的 CUDA 必须使用新的 TensorRT。最终，新版本的 TensorRT 上线，因为新旧版本之间的计算精度差异，造成用户场景下当前使用的 AI 算法和模型统统失效。

从操作系统角度，通过内核，驱动，函数库，中间件的联动升级，实现了内部兼容性问题解决的闭环。但当场景延伸到用户场景时，兼容性还是出现了失控。

所以从长期来看，我认为维护策略的核心是识别用户场景中真正的兼容性要求。建议 Release Management SIG在沟通讨论时重点关注这一点，技术委员会也会从工具和方法论角度给出支持。

小结

为了openEuler 21.03 创新版本，最近社区多了很多新的贡献者。也有很多贡献者，因为 openEuler 在建仓提交管理上的要求，感觉深受折磨。我想借这个机会稍微说明下。

1月18日的一个新闻曾经引起了很多人的注意，Flash停更造成大连铁路系统瘫痪。乍看起来，个别单位对软件生命周期管理不重视而造成事故，这种情况只是个例；开源开放的操作系统，关注的人多，高灯下亮，应该没有个问题。但从2020年的实际分析来看，不仅不是高灯下亮，反而是灯下黑。在广泛使用的开源操作系统里，类似的问题并不鲜见。比如 libdb 数据库，早在2012年就已经从开源转闭源，而有些重要的基础工具依然在坚持引用闭源之前的最后一个版本；而开发人员弃坑，软件本身却依然被广泛依赖的场景更是随处可见。为什么这个问题没有得到社区的关注？一个间接的佐证来自对最近的 sudo 高危安全漏洞 CVE-2021-3156的分析。在 Y Combinator的讨论贴中，有从业者表示：

“All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested…As long as this type of thing continues, our tools will remain at a very low level of safety, reliability, and correctness.”

换言之，Linux用户态的大多数软件不是没有安全问题，而是测试不足没有发现。

一方面是软件上游社区停止维护，另一方面是测试不足没有发现问题，后者掩盖了前者的存在。而对一些操作系统发行版的盲目信赖，让很多人选择性地忽视了后者。

openEuler 认为必须通过透明有效的开发管理和测试来提升社区整体的安全，可靠和正确性。这条路当然是要艰难得多，但想到 openEuler 会越来越多被用在国计民生等关键场景中，社区中的伙伴们也都有了一份责任感和使命感。

艾尔帕西诺在"闻香识女人"里有段著名的台词，我常常拿来勉励自己。

“Now l have come to the crossroads in my life. l always knew what the right path was. Without exception, l knew, but l never took it. You know why? lt was too damn hard.”

在此感谢大家和 openEuler 一起选择 “对” 的道路。

from openEuler TC