国产操作系统问题
最近和几个朋友吃饭，谈起国产操作系统应该怎么做的问题。我这个人，写程序写惯了，啥东西都喜欢建逻辑，这是我处理信息的方式，所以把一些想法串起来，整理在这里。这不表示我提出什么结论了，就好像我以前谈过「道纪」的概念，这仅仅是一个「道纪」，不是结论。
很多时候，你问我一个问题，我在进行逻辑推演前，我都没有结论的，完成推演以后，我才会有结论，但这个结论不一定就是我写出来的那个结论。正如以前说过，逻辑是是超越真实的存在，是一个动态的真实。这就是道纪。
首先我收缩一下范围，我不在乎某个操作系统是谁做的这个名。如果都可以用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一类的软硬体整合解决方案，而且初期核心软体必须通过投资或者合作开发的方式直接集成
- 换掉几批架构师后培养出来的架构能力
关于最后一点，感觉必须直接开源运作才有可能真正做成，原因是开源运作才会保证一代死掉后，有其他人可以在某个基础上试著接著上。（第二点保证即使操作系统开源运作，但商业企业仍能盈利）
除此之外，我暂时想不出还有什么可行的解决方案。
推荐阅读：
