.. Kenneth Lee 版权所有 2019-2020
:Authors: Kenneth Lee :Version: 1.0
国产操作系统问题
最近和几个朋友吃饭，谈起国产操作系统应该怎么做的问题。我这个人，写程序写惯了， 啥东西都喜欢建逻辑，这是我处理信息的方式，所以把一些想法串起来，整理在这里。这 不表示我提出什么结论了，就好像我以前谈过“道纪”的概念，这仅仅是一个“道纪”，不是 结论。
很多时候，你问我一个问题，我在进行逻辑推演前，我都没有结论的，完成推演以后，我 才会有结论，但这个结论不一定就是我写出来的那个结论。正如以前说过，逻辑是是超越 真实的存在，是一个动态的真实。这就是道纪。
首先我收缩一下范围，我不在乎某个操作系统是谁做的这个名。如果都可以用Windows，都 可以用Android什么的，就算他们不是国产的，我都不觉得这是需要解决的问题。我们要解 决问题，不是要求名。
比如，Android的AOSP，这本来就是开源的，根据GPL和Apache协议，提供者无权拒绝你使 用这个源代码，所以，如果你仅仅觉得代码不是你自己写的，就想着要自己重新写一个， 这是神经病，我不讨论这种类型的问题。
还听有人说过自己写的才不会被别人留下漏洞，这个同样没有意义，漏洞是逻辑破绽，写 好的逻辑你都找不出破绽，你自己从头写一个你就能避免逻辑破绽？这个理论不过脑子。
所以，我们需要国产OS的核心问题不是这个名的问题，不是人家有，我也要有。软件和硬 件不一样。软件拷贝是没有成本的，人家做好一辆汽车，我要自己做一辆才能拥有这个汽 车。软件不需要，软件拷贝了就能用，不需要消耗钢材橡胶和汽油。
这里涉及软件一个普通人无法理解的特点，是我们很多人对自研操作系统的问题建不出有 效逻辑的原因。这个特点是：软件是一个动态的，组件可换的存在。
这句话说出来很容易理解，很多人以为自己了解，但其实你不理解。很多人讨论软件研发 的时候，常常询问“技术沙盘”是什么。比如，做一个操作系统吧，投资人问：“操作系统的 技术沙盘是什么样的？”——听起来挺合理的。部分软皮蛇架构师就开始列了：
BIOS，SecureFireware，调度器，驱动框架，IPC，中断管理，设备管理，文件，libc，调 试器，工具链……
这感觉就好像开地图一样，打开一个点，打个Mark，再打开一个点，再打个Mark，或者标 记“完成30%”。还整个颜色，开始是灰的，超过30%变黄，超过80%的就变成绿色，等整个沙 盘都变成绿色的了，就认为“我们拥有了自研的操作系统”了。
这完全是外行。
因为你忘了前面那个前提了：软件是一个动态的，组件可换的存在。
所有你提到的这些部件，它们都没有完成度一说，一直是一个动态变化的过程。也没有某 个东西必须存在一说，你的操作系统可以一直缺很多东西，但用于某个数据库节点，只要 你把数据库支持好，它就可以是100%的完成度。而且你要不断投入人力，保证你这个操作 系统能支持一个市场最优的数据库，这个操作系统就是成功的，否则就算你打通了所有所 谓沙盘组件100%的完成度，这个东西都是个垃圾。
这样我们就能理解“国产操作系统”的真正需求是什么驱动的：比如你使用AOSP，后面真的 和Google交恶了，Google决定不给你下个版本了，你真正的问题是：你不能维持你的发展 了。
有人可能觉得“不能维持就不能维持呗，用点旧的也没有啥的”。我不知道各位跑过俄罗斯 没有？俄罗斯机场过关是我见过最慢的通关关口了。我注意了一下，其实关员也没有特别 怠工，他们是等那个扫描和识别系统等太久了。我大概去了解了一下原因，据说是由于西 方国家禁运，他们这部分设备全部是自研的，自研完成后也没有别的竞争驱动了，就一直 这么用着，这个技术就迅速出现代差了，有和没有就没有多大区别了。
技术这东西，不是说你有就够了的。苏俄堂堂科技大国，沦落到卖资源为生。技术竞争的 失败，后果是很难看的。
所以，操作系统研发，不是一个有无的问题，而是一个如何维持的问题。你基于某个Linux 发行版，乃至BSD发行版，直接做一个，再通过强制使用来浇灌市场，这不是不可以。但没 有竞争，这个东西会开始停滞，然后拖慢你生态上的所有技术发展。比如你做一个“飞龙 Linux”，要求QQ，Office就要支持这个平台，国家给补贴。研发这个Linux的那个组织钱都 拿到了，哪里有兴趣给你升级？然后QQ拿到你的补贴，给你移植了一个版本，后面升级， 怎么升？——还用说吗？当然是升级给最新Windows那个版本了，哪有空给你升飞龙那个版本 啊，那个版本自己的Bug都不修，还指望通过它优化用户体验？
我们需要这样来理解研发操作系统是怎么回事，才能发现问题的关键在什么地方，如果你 拿着技术沙盘这种煞笔玩意儿，就不要指望搞明白为什么钱都扔水里了。
实际上，很多所谓的操作系统研发企业，我能一眼看出它是真的还是假的，就是你去查它 的生命周期计划就可以了。它一个版本打算维护多少年？下一个版本的研发怎么切换上来 ？如果它没有这样的计划，基本上意味着它就没有想过持续维护这摊子事呢，这种东西你 想构成生态？这是缘木求鱼。
对于生命周期管理，这就涉及软件构架的问题了。软件构架这个词语说出来很高大上，其 实大部分时间，它解决的是个非常直接的问题：怎么把多个发展的逻辑综合到一段代码中 。
你一开始写一段代码，比如说搜索吧：建一颗平衡二叉树，处理增删找，三个函数提供API ，搞定。这段代码写起来没有什么难度。
好了，现在我是在多核里面做的，多个线程同时可以访问这个增删找，这段代码的压力就 大了，因为你要上锁来保证多个核同时来增删找，互相不能冲突，锁密了性能低，疏了接 口受限。
好，你解决这个问题了，然后新需求决定发现这段代码需要持久化，也就是说，这个数据 结构，在特定场景下，需要被写入到磁盘，在部分时候需要从磁盘中恢复，而且在这个写 入和恢复的过程中，我还需要继续增删找。这样，相同的流程中必须加上和持久化流程互 斥的代码了。
然后我需要在10种硬件上都能跑，他们的原子操作行为是不一样的。所以，你的锁操作在 不同平台上使用的上锁方法不同。
然后这些硬件的endian也是不一样的，你进行持久化的过程中需要对不同的情况进行处理
然后Cache Flush的方法是不一样的……
你看，本来很简单的一段代码，只不过落地的时候面对不同的情形，同一段代码就会面对 无数的问题。本来简单的三个语句，每个上面都要加上一个if，if里面可能要调一个函数 。这个复杂度会复杂到你无法忍受。
而且他们会互相冲突，增加记录的时候需要上锁，但上锁的时候不能做Cache Flush，否则 他们自相矛盾了。
到复杂度高到你无法忍受的时候，你就只能对整个算法拉分支：比如 BigEndianLocklessBalanceTreeV1，LittleEndianHeavyLockBalanceTreeV2.2。
但你拉了分支，上层使用你的模块就需要加一堆的if，else。用你不同的库。所以我们说 架构设计是一门艺术。你手上并没有严谨的逻辑来进行决策，它不是个“已知记录，记录长 度，key，求记录value”这种问题，你看着自己有无限的自由，最后被自己的选择绑住所有 的自由度。
作为一种常见的工程实践，我们会同时维护“构架分支”和“战地分支”，“构架分支”承担所 有的复杂度，但性能不高，功能受限。因为他要尽量保护逻辑的生存能力。让核心的增删 找在最多的场合里面可以用。而战地分支用于在具体的用用场合中“落地”，当我们进行落 地的时候，如果被落地的场合没有多核，我们就可以不上锁，场合就是Little Endian的我 们可以不做字节序转换，没有Cache Flush需求的可以不做这个操作。这样，我们可以保证 性能的情况下，把其他优化逻辑加上去。但很明显战地分支的生存能力是非常受限的。
架构师是在构架分支和战地分支上平衡的人，他既要保证代码的生存能力，也要保证应用 时的竞争力，才能保证这个东西可以生存下去。对于操作系统，能否生存下去，构架操纵 能力是第一要素。每种具体的技术都能搞定，搞定以后是否把未来的所有改进都堵死了， 这才是关键问题。
国内企业最大的问题，在长期的竞争中，一直把时间放在了战地分支上，对如何维护构架 分支一无所知。他们以为他们落地在自己手机中，或者云服务器上的Android和Linux比“主 线”更“先进”，却没有注意到，他们只是在消耗构架分支为他们建立的发展优势。如果你需 要自己维持一个分支，很快就会掉入自相矛盾的逻辑陷阱中了。
这个问题非常难解决，因为我们无法评估一个架构分支的架构好不好的，这个东西性能最 低，功能最差，所有人都吃它的好处，却自以为自己比它好。没有强力的资源和环境支持 ，很难活下去。
稍微说远一点。架构分支控制是个非常复杂和困难的问题。是那种典型的“努力也不能解决 问题”的问题类型。很多人开始做自己的分支的时候，喜欢说，我从一个上游分支里面做 Deviation。比如，他们会宣称“我兼容CentOS”。但你这样想，完全兼容CentOS的发行版， 只有CentOS本身。所以，只要你拉了分支，响应了独立的需求，你就不可能兼容CentOS。 就算你仅仅是在里面加了一个应用，你已经导致了“新的应用不能和你加的应用名称、位置 冲突”这个不兼容了。更大的问题是我们前面说的：软件是个动态的，组件可换的存在。 CentOS是动态升级的，每个星期都有安全补丁。那么你的分支也要支持这个同步吗？如果 你支持，基本上你自己的Deviation就很难有自己的响应能力了。作为这个系统的使用者或 者应用开发者，根本不会在意你的Deviation了，他们将在意的是CentOS的发展（相应地你 也失去了前面说的，对方不给你供货时或者你和对方有技术分歧的时候，你自己的发展能 力）。如果你不支持——难道CentOS的升级是吃饱了撑的？你失去了这个升级能力，你这也 不是“兼容CentOS”了。所以，你不要指望谈需求的时候谈你的Deviation，谈兼容的时候谈 你的同步升级。这两者仍是自相矛盾的逻辑。
好了，我们完成问题的理解，知道困难在哪里了。现在看看可以如何突破。操作系统是个 生态问题，没有人用操作系统是为了用操作系统本身的，都是为了用上面的应用，而应用 愿意适配到这个操作系统上，要素是：
这个操作系统有足够的用户量
这个操作系统有足够好的开发环境（不好用也就罢了，但你别连功能都没有啊）
这个操作系统能发展下去（不会发展两三个版本就自相矛盾运作不下去了）
这样，自研国产操作系统的基本要求就出来了：
必然基于现有的开源系统来改，最多替换其中部分关键部件（否则维持不住Toptip的竞争）
由大型商业企业提供类似手机或者ChromeBook一类的软硬件整合解决方案，而且初期核 心软件必须通过投资或者合作开发的方式直接集成
换掉几批架构师后培养出来的架构能力
关于最后一点，感觉必须直接开源运作才有可能真正做成，原因是开源运作才会保证一代 死掉后，有其他人可以在某个基础上试着接着上。（第二点保证即使操作系统开源运作， 但商业企业仍能盈利）
除此之外，我暂时想不出还有什么可行的解决方案。