第一节 “自主”操作系统——为什么及如何
引言
近一个月是个多事之秋（2012年9月），IT 和互联网领域也不平静。阿里云操作系统受到谷歌的打压，华为任正非提出要开发自己的操作系统，中兴也宣布今年第四季度将发布自己的操作系统。一时间，微博上有关自主操作系统的讨论如火如荼。这样的讨论，就如同“月经贴”一样，每隔一段时间就要火一次。但大部分讨论其实讨论不到点子上，就如同“瞎子摸象”一般，大家基本上只是站在自己的立场，基于自己的经验在判断孰是孰非。这样的讨论效率低下，本人认为有必要写一篇科普性的文章，从政治、技术、工程、法律等几个方面给“自主”操作系统来一个比较清晰的定义，并尝试给出一些技术、工程等方面的建议。
作者的资格
为了说明本人有足够的资格来写这篇文章，给大家介绍一下本人的经历。本人码农出身，1993到1998年期间主要在微软平台上做程序开发，曾编写过 DOS、Win32、MFC 程序，期间涉及 C/C++ 语言，SQL 数据库、网站后台等。从 1998 年底开始专注于 Linux 和嵌入式系统。主要作品为 MiniGUI。在创办飞漫软件的近十年时间里，作为企业创始人和研发负责人，组织研发团队持续开发 MiniGUI，开发了多个版本的嵌入式浏览器产品，也曾和美国公司合作，开发过类似 Android 这样的移动操作系统，还将 Android 运行在了 MeeGO 上（也就是国际上有点名气的 ACL，飞漫是主要开发者）。除了丰富的软件开发、管理经验之外，本人还编写过几本操作系统相关的书籍，不过比较老了，比较出名的是本人主持翻译的《Linux 设备驱动程序》第二版、第三版。有这些经历和相关经验做基础，我相信本文所述将是比较客观和完备的。希望本文对政策制定者、大型企业的决策者、自主操作系统的开发管理者，以及一般的码农们或多或少有一些帮助。
限制和定义
操作系统的类型很多，粗粗算起来，从小到大，有针对嵌入式系统的实时操作系统，比如 VxWorks、Nucleus 等；有现在大家熟知的针对移动终端的 Android、iOS、Windows Phone 等；有 Windows、Ubuntu Linux 等针对 PC 的操作系统；还有针对服务器的操作系统，比如 Windows NT 等。
从技术上讲，操作系统的概念可大可小。小的话，一个内核就可以称为一个操作系统，比如 Linux 内核、BSD 内核、Minix 内核等；大的话，则通常指的是整个软件平台，比如 Android、iOS、Windows Phone，有时还会将软件商店、开发社区等包含在内，从而外延到整个生态系统。
本文所指“操作系统”，以及大家近期讨论的操作系统，其实基本上被限制在移动终端领域当中，就是指能够和 Android、iOS、Windows Phone 等相提并论的操作系统，主要用于智能手机、平板电脑，而不是实时操作系统、操作系统内核或者服务器操作系统——准确讲，应该是指一个针对智能手机和/或平板电脑的软件平台以及对应的生态系统。不过，我们当前还是把它称为“操作系统（OS）”吧。
到底要不要“自主”操作系统
对此问题，不同的人有不同看法，但其实都很偏颇。码农，尤其是喜欢 Google 的码农，通常会说，Android 是完全开源的，没有必要重复造轮子；企业决策者或者政策制定者，则往往会认为必须有自主的操作系统。其实两者都有道理，但两者都没有看到事物的本质。
“自主”操作系统的不必要性
在谈“自主”操作系统的必要性之前，笔者先谈谈“自主”操作系统的不必要性。
在开源软件大行其道的今天，操作系统不再那么神秘，任何有足够财力的企业，依赖现有的开源软件，都可以比较容易地推出一个能够运行的操作系统。出于此观点，很多人认为有 Android 这样的开源操作系统，就没有必要再开发一个自己的操作系统了，到底谁拥有开源操作系统的知识产权，是无所谓的事情。
这个说法是有一定道理的。
从法律（指开源软件许可证）和技术上讲，就算 Google 不打算开源新的 Android 版本，不允许某些厂商使用 Android，我们一样可以在已经开源的 Android 之上继续发展自己的 Android 系统——只要遵循已经开源的 Android 的许可证约束即可，而 Android 系统主要使用的开源软件许可证有 GPL（Linux 内核）、LGPL（各种运行时函数库）、Apache（Dalvik 虚拟机及 Java 类库），其实是非常宽松的。
这个说法的不足之处在于，未考虑到可能的专利（软件相关的专利通常和实现无关，就是说，你重写一段代码，并不表示你可以规避对应的专利），以及是否有能力自行发展 Android 的问题。
前者非常要害。谷歌在开发 Android，尤其是 Dalvik 虚拟机以及 Java 类库的过程中，肯定积累了大量专利，而这些专利是凌驾于软件的著作权和许可证之上的。也就是说，如果你基于现有的 Android 派生了一个分支，要想将运行有这个 Android 派生版本的软件放到自己的手机里边销售，谷歌马上可以拿出专利大棒来限制你。当前，谷歌尚未拿出专利大棒来限制各种派生于 Android 的系统。拿阿里云 OS 和谷歌最近的争论当中来看，谷歌也只是说阿里云 OS 导致 Android 不兼容。但一旦有厂商真的使用了阿里云 OS，谷歌马上就会拿出专利大棒，这将毫无疑问。
至于有没有能力来自行发展 Android 的问题，在中国有大量码农基数的基础上，只要有源代码，就可以在短时间内组织团队自行发展 Android。
“自主”操作系统的必要性
强调需要“自主”操作系统的主要有两类人：政府中的政策制定者以及大型企业的决策者。
对政策制定者来讲，面向未来由中美两国主导的国际环境，作为两极世界中的中国，有没有自主的芯片、有没有自主的操作系统，关系到两个层面的东西，一个是国家安全，一个是面子。在这样的认识下，“核高基”的出现自然而然，其目的是支持国内企业发展核心电子器件、高端通用芯片及基础软件产品。我们暂且不谈核高基项目在实施过程中存在的制度性问题，它表明的国家是在战略上的一种布局，是一种国家意志，涉及到政治领域。
作为企业决策者，没有自主的操作系统，他将在很多方面受制于人。就拿阿里云和谷歌的争议事件来看，宏碁受到了来自谷歌的压力，然后就乖乖投降了。这里边有两个值得思考的地方：
既然 Android 这么好，为什么宏碁还要和阿里 OS 合作？后者肯定没有 Android 成熟啊。
为什么谷歌一施压，宏碁就放弃了和阿里 OS 的合作呢？显然，宏碁有动机选择另一个 OS 给自己的智能手机，可能的原因无外乎两种：阿里给钱了或者宏碁不希望被谷歌控制；另外，宏碁又那么容易地被谷歌搞定，说明谷歌能带给宏碁的利益远远大于阿里。
另外联想到微软向 Android 厂商收取专利许可费的事情，像宏碁这样的厂商，肯定也会被微软勒索，也包括中兴、华为等国际化的 Android 手机厂商，无一例外。对企业决策者来讲，这很难受——给别人做嫁衣啊，有时候还两头受气！所以，小的厂商需要投靠大树来庇护自己（大多数乖乖就范于谷歌或微软），大的厂商就要考虑是不是开发一个“自主”的操作系统来抗衡了。
这样的思路下，华为、中兴等大的智能手机厂商，开发“自主”操作系统的动机非常强。
像阿里这样的公司，开发OS，其目的是要复制 Google 的商业模式，加上阿里 OS 又没有撇清和 Android 的关系，受到 Google 的打压就在情理之中了。
“自主”应强调在“有效知识产权保护下的自己主导”
根据上面的分析，看来我们还真的需要有“自主”的操作系统。但是，“自主”到底是自主什么呢？
在功能手机和实时嵌入式系统领域，我们不是没有“自主”的操作系统，比如 MTK 或者展讯的操作系统，以及诸如早期的 Hopen、道系统等。在通用操作系统领域，国家也长期支持了诸如麒麟操作系统、红旗 Linux、中标 Linux、新华 Linux 等多家本土操作系统厂商。但市场表明，国家支持的这些操作系统都将消亡或者正在消亡。
本人认为，国家支持下进行“自主”操作系统的开发有合理之处，毕竟开发操作系统是一件比较困难的事情。但是，这里边有一个重要的误区和制度设计上的错误，就是只强调了“自有知识产权”，而没有强调“自己主导”。
在强调“自由知识产权”的情况下，政府对受资助企业的“自主”操作系统进行考核时，大部分情况下考核的是企业有没有获得对应的知识产权，就是软件的著作权和/或对应的专利，而并没有考核能否主导一个产业链。就如同 Google 那样可以控制这个产业链一样，受资助的企业，能不能做到让别人用了你的操作系统，就没法不继续用？在这样的思路下，政府需要在更长的周期内，考核受资助企业的市场份额是否有扩大，是否建立了良好的生态系统，让使用者、开发者欲罢不能，而不是简单的著作权证书和专利数量，或者是否达到了一个给定的出货量（因为出货量是可以作假的）。
也就是说，我们应该重新定义“自主”这两个字，从“自有知识产权”向“有效知识产权保护下的自己主导”转移。
为什么这里强调“有效知识产权”呢？这是因为，在开源软件成为趋势的情况下，构建一个自己的操作系统，可以使用很多已有的开源软件，我们没有必要所有代码都自己编写，而且越底层的代码就越没有必要自己重写一遍。这如同一只桃子，好吃的是果肉，而不是果核。像内核、基础库、常用运行时函数库等等，都不必自己重新开发。而且这么做几乎没有任何潜在的法律问题，当然，前提是你要告诉大家你用了哪些开源软件，而且你也尊重了这些开源软件的许可证。这样下来，一个操作系统的软件著作权已经不再重要，重要的是相关的专利、自己独有的创新以及围绕操作系统建立起来的生态系统。
“自主”操作系统应该具备的特征
那么，“自主”操作系统应该张什么样？要回答这个问题，我们先看看假的“自主”操作系统张什么样。所谓假的“自主”操作系统，就是那些号称“自主”操作系统，但其实：
只是在已有的开源操作系统之上加了一层皮。比如各种基于 Android 的第三方 ROM，比如 MIUI、Flemy 等。这种操作系统仅仅在 UI/UE 上做了一些工作，就如同一个人换了一身衣服那样，实质上这个人不会因为换了一身衣服而从张三改叫成李四。
修改了已有开源操作系统的内部代码，做了一些优化或者去掉了别人的一些东西，添加了一些自己的内容。比如阿里 OS 就属于这种，或者哪些号称深度定制的 Android 系统也属此类。这种做法如同整容，的确动了些刀子，甚至改变了性别，但人还是那人，改了名字或性别也还是那人。
这么类比下来，读者应该就知道了，真的“自主”操作系统，必须要有自己的灵魂，只有这样，不管换什么衣服、是不是经过了整容，那人还是那人；通俗一点讲，只有换了脑袋的才能是一个全新的个体。
那么在操作系统当中，什么东西是灵魂？这个问题回答起来蛮难的。我们先看看哪些东西肯定不属于灵魂：
无法形成有效知识产权的软件组件，或者说，满世界有很多（开源的）实现的软件组件。比如内核、基础函数库、网络协议、图形库、浏览器引擎等等。这些东西可以看成是形成一个智能动物（比如“人”）的骨架或者躯体、甚至心脏，但远远算不上脑袋或者灵魂。这也是为什么笔者主张在“自主”操作系统中要尽量使用现有的成熟开源软件，而且不建议再行发明此类轮子的原因。
要知道哪些东西是灵魂，我们分析下 Google 在和阿里 OS 争论的过程中主要维护的是什么东西：
Google 的说法：阿里 OS 采用了 Android 的虚拟机和 Framework，但又不兼容 Android，破坏了 Android 的生态系统。这个说法可能还不是 Google 打压阿里 OS 的最关键原因，但起码说出了他们的担忧：阿里 OS 是想借 Android 打造自己的一个生态系统！另外，Google 对那些只换衣服的 Android 系统采取听之任之的态度，和他们一贯以来标榜的“只要兼容，我们欢迎”的态度一致——也就是说，这些系统没有从根本上动摇 Google 的生态系统。
所以，真正的“自主”操作系统的灵魂，就是那个背后的、无形的生态系统，一个看似开放但其实封闭的生态系统。一旦加入这个生态系统，你就很难下来——正所谓“上了贼船下不来”。
这就是我的回答：一个真正“自主”的操作系统，必须建立自己的生态系统，一个开放的，但在某种程度上又封闭的生态系统。 操作系统生态系统？这名词大家说了很多年了，一个生态系统具体应该是什么样子？笔者从如下几个方面解释一下：
技术层面。操作系统必须通过某种技术将自己和其他的操作系统区隔开来。比如 Android 采用 Java 语言，但使用了不同于 Sun（现在是 Oracle） JDK 的 API；iOS 采用了 Object C 语言，为应用程序提供的接口和框架甚至有别于苹果自己的 Mac OS X；Windows Phone 采用了 C# 语言，在 .Net 框架下进行开发。为什么这些操作系统不使用 C/C++ 这类语言呢，C/C++ 尤其是 C 可是这些操作系统内核的编程语言啊！？这里有如下几个原因：
操作系统开发者不希望普通的应用程序通过使用比较低级的编程语言来控制系统或设备，毕竟操作系统是给智能手机、平板电脑这种消费类的电子设备使用的。
通过采用更加高级的语言来简化编程和开发人员的学习难度。
通过对看起来非常复杂的框架的持续演进，达到牵着开发者和厂商鼻子走的效果。
便于形成依附于某个操作系统的独有的开发者社区和文化。
法律层面。操作系统必须通过创建自己的有效知识产权体系来保护自己。前面已经说过，越底层的软件组件越没有市场价值（码农们可能不喜欢听这话，但现实就是这样的）。通过建立全新的、包裹在底层操作系统之上的框架、编程接口、编程语言等基础设施，操作系统开发商才有可能建立起有别于他人的有效的知识产权保护体系。也就是说，如果连框架、编程语言、编程接口等都抄袭他人（就算是开源的、许可证允许的），那永远也无法形成一个可以有效保护自己的知识产权体系。
市场层面。通过和上下游企业的合作，建立某种联盟或者许可、授权机制，让操作系统的用户（芯片厂商、手机厂商、平板厂商）能够从中获益。比如 Android 开放联盟，做的就是这个事情。
开发者社区。一个好的操作系统之生态系统，要充分照顾开发者的利益，具体有如下几点：
要有好的开发工具，便于开发者学习、开发和调试软件。
要有好的文档或者教程，帮助开发者迅速掌握相关开发技巧。
最重要的，要能够让开发者赚到钱。
看到这里，相信大家都会意识到：这也太难了吧！的确，这非常难，这也是为什么 Moblin、MeeGo、Bada、WebOS 等操作系统相继失败，而到目前，只有 iOS、Android、Windows Phone 这三种操作系统的原因。
但是，世上无难事只怕有心人。接下来我告诉你如何搭建一个真正的“自主”操作系统。
如何开发“自主”操作系统
开发“自主”操作系统的两种目的和策略
开发“自主”操作系统的主要目的有两种：一种是想再造一个类似 Android、iOS 的操作系统，并作为其竞争者；一种仅仅是为了在商务谈判和合作中获得一个比较好的筹码。当然，还有一种目的就是骗取政府的财政支持，对这类不良目的，不属本文讨论范围。 我们先猜度一下国内外这几年出现的一些“自主”操作系统，其目的是什么：
中国移动通过博思通讯开发的 OMS。本质上 OMS 是 Android 的一个派生系统。很明显，中国移动开发 OMS 的目的属于前一种。中国移动希望利用自己强大的市场地位来左右手机供应商的 OS 选择，并建立起类似苹果那样的全封闭的平台和生态系统。可惜的是，OMS 并没有取得预期效果，在来自联通、电信的强大市场压力下，中国移动不得不允许 TD 手机使用正统的 Android 系统；OMS 也正在被市场淡忘。这里有个比较有意思的现象，Google 从来没有公开质疑过 OMS 系统，阿里 OS 的做法和 OMS 类似，却遭到了打压。这里有两个原因，一个是中国移动的市场地位摆在那里（加上还是巨型国企），Google 不敢轻举妄动，另外一个是 OMS 采用的是 Android 早期版本，那时候 Android 的市场地位还没有这么强。
中国联通所谓的 UniPlus。可惜的是，UniPlus 似乎从来没有面过世，也许中国联通只是放了一个烟雾弹而已。要是真开发，目的自然应该和中国移动的 OMS 类似。
Firefox OS。这是 Mozilla 公司推出的纯粹基于 HTML5/CSS3/JavaScript 等网页前端开发技术推出的操作系统，和 HP 收购自 Palm 的 webOS 有类似的软件架构。HP 收购了 webOS 之后的半年，即宣告放弃 webOS，而 Mozilla 却希望通过类似技术的 Firefox OS 成为 Android 的竞争者。一会儿我们分析下为什么 Firefox OS 要比 webOS 有更强一些的生命力。
华为提出要开发的“自主”操作系统。作为一个智者，任正非不可能不知道一个真正“自主”的操作系统应该是什么样子的。华为就算再有钱，再有人才，短时间内也是搞不定一个“自主”操作系统的（如前所述，主要是建立对应的生态系统太难了）。这么说来，华为开发“自主”操作系统，其目的其实就是做一个备胎，以便在和 Android、Windows Phone 等合作时能够有一个可以讨价还价的砝码。也就是说，华为并不是真的要做“自主”的操作系统；或者这么说，支持团队去做，做成 Android 那样最好，做不成 Android 那样，如果真有一天打起架来可以凑合用也行。
阿里 OS。马云同志的野心很大，他做阿里 OS，就是要复制 Google 在移动互联网的商业模式，进而在移动互联网领域推广阿里体系的服务和内容。可惜的是，马云貌似不太懂技术，也没个明白人给他做参谋，结果被人害了，花了钱还被人捏住了七寸。最新的传言，说阿里 OS 要换将，继续再投个 2 亿搞。马云同志啊，光有钱是不行的，你身边还得有个把技术大牛帮你把关、出谋划策才行啊。
好，面对这两种开发“自主”操作系统的目的，应该有什么样的策略呢？其实策略很简单，不管你是真心还是假意，都应该按照本文第 3 章给出的“自主”操作系统之特征进行开发，除此之外，别无他法。任何期望找捷径的方法，都不可能获得成功。这里所说的找捷径的方法具体有： * 给 Android 整容。如 OMS、阿里 OS。 * 忽略操作系统之生态系统的重要性，在 Linux 或其他开源操作系统内核、系统库等基础上包裹一个简单的框架而形成的操作系统。这种操作系统，其复杂度和 Linux 发行版相当，离本人定义的真正“自主”操作系统还差十万八千里。读者可能会问，这样的系统做备胎不是还行吗？为什么也得按照真做那样开发呢？你要知道的是，对手也不是傻子，人家看你的架势，就知道你不是真做——你起码得拉出真做的架势来，人家才能怕你啊！
顺便谈谈我对基于浏览器技术的 web 操作系统之看法。
理论上讲，浏览器可以做很多事情，甚至可以替代 PC 机上的通用操作系统。但是，最新的浏览器技术（HTML5/CSS3等），还存在一些技术上的问题。主要的问题有如下两个：
浏览器主要采用的 JavaScript 编程语言，本质上是一种难于管理（源代码保护、无法进行有效的软件架构设计、难于调试等等）的编程语言，同时内存消耗巨大，性能不佳。最新的说法是，Facebook 创始人直言全面采用 HTML5 的策略是个失误，正在向操作系统的原生应用转移。也就是说，JavaScript 语言难以承载一个良性发展的生态系统。
因为许多原因（主要是利益和政治因素），HTML5 相关的标准有分裂的迹象，同时进展缓慢。
HTML5 技术作为原生应用的一种补充，可以起到很好的作用，但是，如果要想在浏览器技术上建立一个真正可以和 Android 等竞争的操作系统，恐怕还需要很长的时间（技术上必须有突破）。要不然，Google 现在主推的应该是 ChromeOS，而不是 Android。
现在回答刚才提到的问题：“为什么 FirefoxOS 可以比 webOS 的生命力更加长久些呢？”主要的原因是，FirefoxOS 是开源的，有比较强大的企业在主导其发展，作为一个脱胎于开源基金会的企业（Mozilla公司），也能获得合作伙伴的一些好感；相反，因为 webOS 是封闭，HP 又没有能力像苹果那样打造一个完全封闭的平台和生态系统，所以最终的命运是被人抛弃了。虽然后来 webOS 也走上了开源的道路，但大势已去，HP 不亲自带头搞，光靠开源社区是搞不成的。
技术层面上的考虑
假定你是一名“自主”操作系统项目的技术管理者，你第一步要考虑的问题是什么？许多人的回答可能是：先选操作系统内核、基础库什么的。其实错了，第一步要考虑的应该是你打算选择什么编程语言作为原生应用的编程语言。
世界上的编程语言有很多种，有些语言贴近机器，比如汇编语言、C语言，有些语言贴近人，比如 Basic、Java，还有些语言用于特定领域，比如网页服务器端使用的 PHP，有些适合做不同软件之间的粘合剂，比如 Perl、Python。本文第 3 章已经解释了编程语言以及围绕编程语言形成的运行环境、框架是将操作系统区隔于其他操作系统的主要技术特征。因此，我们必须慎重选择一种编程语言。而且一旦选定了一种编程语言，“自主”操作系统在开发者看来长什么样，其实就基本上定了。
选择编程语言要考虑如下因素：
这种编程语言是否易于学习和掌握？是否有庞大的开发者在使用它？
这种编程语言是否具有高级语言的基本特征，比如，支持面向对象编程？
这种编程语言是否是编译执行的？
这种编程语言是否利于保护开发者的知识产权？
这种编程语言是否有完整的工具链支持？
这种编程语言是否有集成开发环境的支持？
这种编程语言是否易于保护整个操作系统不会被恶意代码轻易破坏？
如此等等。
其实很多读者看到这里，都会想到 Java 语言。是的，Java 语言或其派生语言如 C# 是构架“自主”操作系统的最佳编程语言。可惜，已经被 Android 和 Windows Phone 给捷足先登了。
如此一来，你可以考虑重新设计一门类似 Java 的语言，也可以通过其他手段，让你使用 Java 语言构建的操作系统有别于其他操作系统。比如，构建自己的虚拟机，如 Android 使用的 Dalvik 那样（Dalvik 和 Oracle 的 JDK 标准虚拟机有很大不同，从而让 Oracle 还挺难告赢 Google 的）；你也可以用 Dalvik，但让类库、运行环境和 Android 不同（这样做的法律风险要大一些）。总之，你需要有自己的创新，全部抄袭是不行的。
确定了编程语言，接下来的工作其实就比较直接了，从上而下设计就是了。主要有：
定义和实现提供给原生应用程序的基础 API 和/或虚拟机。
在应用程序基础 API、标准 C/C++ 函数库和相关组件（通常都是开源软件）的基础上构建操作系统的运行环境和框架。主要涉及系统服务、模块之间的通讯机制，包括图形界面、浏览器引擎、OpenGL ES 支持接口等等。
同时选择操作系统内核，通常也就是 Linux，要与众不同，用 BSD 也行。
搞定集成开发环境和模拟器，让开发者可以在 PC 机上为你的操作系统开发应用程序。
让你的操作系统运行在真实硬件上，为开发者提供应用样例和文档。
持续迭代，让你的“自主”操作系统不停往前发展。
上面的第一点和第二点，是“自主”操作系统有别于其他操作系统，且支撑你可以和其他人竞争的关键点。往下的东西都不是构成“自主”操作系统真正竞争力的东西。
这么看来，其实也挺简单的。不是吗？貌似有钱、有个把技术上的明白人就能做到。技术上没问题了，市场、法律等方面的事情，请专业人员帮忙，中国这类人才还是蛮多的，缺的，其实还是技术人员以及懂系统工程和软件开发的管理人员。
快速搭建一个“自主”操作系统
这里给大家介绍笔者早先和美国一家公司合作，尝试搭建的一个操作系统，其实在当年这些东西的基础上，搭建出来一个有别于 Android 的开源“自主”操作系统还是非常快的。
这个系统使用了 Linux 内核和标准的 C/C++ 函数库，以及一些和 Android 体系结构类似的 C/C++ 运行库，使用了笔者公司的开源软件 MiniGUI、WebKit 浏览器核心引擎等等。基础的东西就这些。之上是开源的 Kaffe JVM（后来改成了 Cacao JVM），和符合 J2SE 规范的类库实现，再往上就是运行环境和框架了。参见附件图。
可惜的是，真正具有核心价值的运行环境和框架，是美国合作方自己开发的，我手里没有源代码。相信读者也能明白，美国合作方掌握的才是精华。
如果要在这套系统基础之上快速开发一个“自主”的操作系统，我们需要：
重新定义类库，也就是基础 API，让我们的系统从灵魂上有别于其他系统。必要的话，优化或替代开源的虚拟机（淘宝最近开源了一个 JDK 虚拟机，不过是针对 J2EE 的）。
全新设计和实现适合于智能手机的运行环境、框架。
全新设计基本的智能手机应用软件。
开发模拟器，并集成到 Eclipse 集成开发环境中。
还有，这个系统是 2006 年开发的，我们还需要将底层的内核、基础函数库等更新到比较新的版本。
要做的工作还是蛮多的，但这个系统在 2007 年的时候，就已经可以运行在主频在200M Hz 左右的手机上了。
当然，这个系统离本人定义的真正“自主”的操作系统还有很大的距离。但是，起码技术上的方向是基本正确的，要知道，这个系统几乎是和 Android 同时发起的。后来在 2007 年，Google 宣布开源 Android 后，美国合作方敏锐感觉到了 Android 将是未来的趋势，就直接转向了 Android 平台，项目也就终止了。
给相关人员的建议
给政策制定者
这里所说“政策制定者”主要指的是“核高基”等政府资助项目的决策人。其实前面已经说过了，这里重申一下：
政府需要在更长的周期内（至少五年），考核受资助企业的市场份额是否有扩大，是否建立了良好的生态系统，让使用者、开发者欲罢不能，而不是简单的著作权证书和专利数量，或者是否达到了一个给定的出货量（因为出货量是可以作假的）。也就是说，我们应该重新定义“自主”这两个字，从“自有知识产权”向“有效知识产权保护下的自己主导”转移；在知识产权方面，要强调有效专利数量，而不是著作权；甚至应该要求受资助企业按某种许可证条款开放源代码。
政策制定者甚至可以参照本文 3 章给出的“自主”操作系统之定义，将整个“自主”操作系统的研发和推广分为三个部分：
科研类，两到三年为周期，以研究新的编程语言及其相关设施（如虚拟机及其优化技术）为主。
工程类，两到三年为周期，围绕指定的编程语言发展外围工具链（编译器、调试器）、开发工具、运行环境、框架等。
法律类，半年到一年为周期，研究和分析采纳已有编程语言面临的知识产权风险，如何规避等等。
政策制定者切忌急功近利，要按照客观规律办事，将科研类的课题交给研究机构，将工程类以及市场推广等方面的课题交给企业，将法律类的课题交给大专院校。只有这样，才能首先让方法正确，方法上正确，加上合理的考核制度，才能让钱产生真正的效益。
在花钱方面，在一盘大棋下的统一部署下，初期让多一些的企业或机构参与，一年一验收，逐步淘汰那些不合格的，最后剩下来一、两个企业就好。十亿美金，外加企业自筹部分，我看基本够了。
给大型企业决策者
有意开发“自主”操作系统的大型企业决策者首先要明白，开发“自主”操作系统是一个长期、艰巨的系统工程。甚至，你需要准备一大笔钱来和已有的巨头打官司（微软赔付给 Sun几十亿美金之后，才让自己的 C# 和 .Net 平台成为“干净”的语言和平台）。
另外，如前所述，不管是真心还是假意，都要拿出十足的架势来真做，而且，对内、对外都要强调这点。要知道，你期望得100分，下属大多数情况下只能给你 80 分；你期望得 1000 分，下属也许就可以给你500分。这样才能超出决策者自己的预期，才能收到更好的效果。
给“自主”操作系统的技术负责人
这事儿如果恰好让你负责，那简直是，怎么说呢，是个“扬名立万”的机会啊！你要知道的是，这事儿和制造“两弹一星”差不多。 首先你要掂量掂量，你有没有这个本事。所谓“没有金刚钻，不揽瓷器活”，说的就是这个道理。有兴趣的也别来找我，我做点小项目可以，真要我负责，我没这个本事。
另外一方面，你要是违背知识分子的良知，帮助一些不良人员骗取国家的资助款项，就更不应该了。这可是要被人戳脊梁骨的；有没有钱拿永远是小事，昧了自己的良心可是大事。
工程上的建议
在具体的研发实施过程当中，开发负责人必须特别注意工程方面的问题：
先做什么、后做什么，或者那些可以并行做。
不同的软件模块，应采取不同的软件开发管理模型。API 设计、框架等的开发，适合采用瀑布法模型；应用软件或者小型模块的开发，适合采用敏捷开发模型。但整个系统，应要不停迭代，所以版本控制非常重要。
特别要注意代码的质量控制以及文档的全面、完备、简洁和逻辑性。
第二节 有关智能操作系统的讨论
智能操作系统开发倡议
以智能手机为代表的智能设备为移动互联网的发展奠定了坚实基础，但我们未能抓住智能手机发展的大好时机，智能设备上的关键系统软件——操作系统——仍然被老美把持。即使 Android 是开源的，但我们所做的事情，除了换几个皮肤、加固一下安全之外，仍然未能掌握核心技术，也无法打造完整的围绕操作系统的生态系统。
现在，除了智能手机之外的智能可穿戴式设备、智能机器人以及其他所有可冠以智能两字的设备成为下一个移动互联网、互联网+、物联网或者车联网的发展方向。同时，Android Wear 不再开源，这将带给我们发展自主操作系统的绝佳机会。
与此同时，国内的软件工程师水平也有了长足进步，主动参与开源运动的国内软件工程师越来越多，具备了一定的实力可以和海外的工程师一较高下。国内的风险投资快速发展，越来越多的风险投资商开始关注并投入到纯技术的创新项目中。
在这天时地利人和之际，本人发起此项倡议，征集三到五名国内的顶级系统软件高手，面向全球市场开发智能设备操作系统。
下一代智能操作系统设想
为了吸引国内高手共同参与讨论。博主先抛出了一个下一代智能操作系统的设想。
下一代智能操作系统的思路是这样的。首先，这个操作系统是传统通用操作系统的一个封装，而不是要替代现有的传统、通用操作系统，以下先简称为 NGSOS（Next Generation Smart Operating System）。NGSOS 主要有两个特征：一个是统一的开发语言，另外一个是一次开发完成然后可运行在所有的现有操作系统之上。在 NGSOS 上，不同的设备或节点承担不同的角色，可以划分为客户端、服务器端和中继端。这些节点之间通过类似 DDP 的协议和 IM 协议同步和传输数据并进行各自的展现或处理。比如在智能手表上，主要负责收集数据然后发给智能手机，智能手机再发给云端服务器进行处理。这种情况下，智能手表是客户端，云端是服务器，智能手机是中继端。
一种实现思路是这样的：将现有的浏览器功能做扩充（同时要移除不必要的兼容性包袱），使用 JavaScript 或 CoffeScript 为主要编程语言，通过扩展的 API 访问设备资源，使用类似 Meteor 的方式实现客户端和服务器端的数据交互（需要 WebSocket 支持），另外通过即时通讯机制，提供数据流的访问和处理许可机制。这样，浏览器将化身为 NGSOS 的操作系统外壳。在设备端，该浏览器运行在 LXC（Linux 容器）中，用来增强安全性，并限制应用的设备资源访问能力。在服务器端，主要的服务由 Node.JS 提供，但还可以通过即时通讯机制扩展后台服务器的处理能力，用来接入 PHP、Python 等语言开发的服务器处理软件。在中继端（智能手机）中，通过运行定制的浏览器来参与处理或展现相关数据，应用的开发过程将和普通的 WebApp 一致，通过 PhoneGap 等的支持封装成原生应用运行在 Android 和 iOS 上。
当然，也可以从头设计一门新的编程语言，最好是支持编译执行，同时支持解释运行，然后使用包/类接口来扩展各种各样的功能。
这样在智能设备端，人们可以使用 Linux 或者 RTOS 来开发自己的框架应用，而其他的应用，尤其是可下载的应用，则基于 NGSOS 来开发。RTOS 或者 Linux 上的原生 APP，主要用来开发框架和系统应用，尤其是那些和底层设备直接打交道的应用。
鉴于 JavaScript 语言的的诸多问题，最终引入一种新语言是必要的。但一种可行的技术路线是 JavaScript 和新语言并行开发，前者是个保障，后者面向将来。
下一代智能操作系统设想之进一步细化
我的操作系统概念
从上面的评论可见，大家对下一代操作系统的期望有所不同，站在不同的角度会得到不同的结论。
现代操作系统的概念，在上个世纪七十年代末由贝尔实验室的两位图灵奖获得者通过 UNIX 获得广泛认同。在其后很长一段时间内，操作系统被认为是管理计算机硬件资源的主要软件层。操作系统将 CPU、RAM、存储、网络、外设等硬件对象抽象为一系列可编程的对象；其中包括进程、文件、文件系统、虚拟内存、用户账号、虚拟字符（块）设备、套接字等等。从那时起到现在，操作系统的基本概念没有太大变化，为今天互联网的形成起到了重要的奠基作用。
那么下一代的操作系统会是什么样？要回答这个问题，我们需要看当前传统操作系统走到了那一步。笔者愚见：传统操作系统基本上没有啥可继续深入做的了，也就是说，相关技术已经发展到了极致。有兴趣的读者可以看看上一小节（“自主”操作系统——为什么及如何），其中讨论的就是传统的操作系统。
我所提的下一代智能操作系统，是构建于传统操作系统之上的分布式、“虚拟”操作系统。我们可以将传统操作系统看成是单机操作系统，它们运行在实实在在或者被虚拟化的计算机之上，管理这个计算机的硬件资源。所以，我们在扮演不同计算机角色的系统上使用各种操作系统和不同的编程语言、平台或框架进行开发。比如，在 PC 上，针对 Windows .Net 平台，使用 C++ 或者 C# 编程；在智能手机上，针对 Android 使用 Java 语言编程或针对 iOS 使用 Objective-C 或者 Swift 编程；在服务器上，针对 Linux 使用 PHP、Python 等语言编程等等。
于是，我们的软件工程师要学会和理解的东西越来越多，相关的技术也越来越复杂。在这种情况下，人们开始寻求可能的统一解决方案。在我的设想中提到的 Meteor 则是其中的一个典型。
当前，Meteor 针对 Web 应用的开发提供了两个最为关键的特性：
前后端统一编程语言为 JavaScript。也就是说，后端和前端使用同一种编程语言，并且被组织到了一起，可以交叉重复利用。这在当前流行的 PHP 后端开发技术中是难以做到的。
通过动态数据交换协议（DDP），将前端数据操作和后端数据操作无缝连接了起来，从而抹平了前端和后端的代码差异。
这两个关键特性使 Meteor 如日中天，成为美国硅谷 YC 孵化器的明星创业项目。当然，值得一提的是，Meteor 技术利用了很多已经趋于成熟的其他开源项目，比如后端的 Node.js、MongoDB、前端的 jQuery 等等，而且目前仅针对 Web 应用。Meteor 所做的工作可以简化为如下要点：针对上述关键特性整合了大量现有的开源软件和技术。
如果我们结合传统操作系统的概念以及 Meteor 项目所带来的新思路，我们可以做如下思考：
我们能否跳出单机概念，将整个互联网看成是下一代操作系统主要面对的“硬件”资源？
我们能否将互联网上运行的服务、应用、带宽、数据流等像传统操作系统那样做进一步抽象，进而设计出一种新的操作系统？
答案是肯定的，尽管我们尚没有开发出这个系统。但从技术的发展来讲，任何全新技术的出现都需要相关技术有一定的积累基础，然后在更高的层次上进行抽象，提出一套自洽和完备的架构出来。这个架构就是下一代操作系统的雏形，然后充分利用现有的技术积累，尤其是开源软件，将其实现出来，并持续迭代。
如此，下一代智能操作系统的概念基本上就清晰了，要点如下：
下一代智能操作系统将面向互联网业务，运行在各种可能的单机操作系统之上。
单机操作系统将作为类似驱动程序那样的作用而存在于下一代智能操作系统中。
下一代智能操作系统通过抽象互联网业务的硬件实体，隐藏单机操作系统所提供给我们的各种细节，从而让开发者可以在更高的层面、更接近业务的层面上设计软件、开发软件。
下一代智能操作系统有可能通过单个编程语言来开发所有单机操作系统上的应用或业务组件。
如果按照这个思路设计下一代智能操作系统，这个系统将不再是一种框架，而的确就是一个实实在在的操作系统。
下一代智能操作系统之架构初探
那么下一代智能操作系统如何做抽象呢？笔者这里先给出一个典型的应用场景。
设想现在互联网、物联网、智能设备的发展趋势，就拿智能手表为例。智能手表为代表的智能设备将在很长一个时间内作为智能手机的伴侣存在。智能手表展示时间、天气以及来自智能手机的提醒等等，并采集一些健康相关的数据交给智能手机做更好的展示和分析。智能手机可进一步将这些数据传输到云端服务器做处理，然后通过大数据、深度学习等高大上的计算，提供给用户一些健康建议，更好完成一些健康和生活习惯方面的建议。如此等等。
在这样的场景中，我们发现智能手表这类智能设备是受限的计算设备，屏幕小、功耗要求高等等。受限于硬件发展，这种形态可能会存在较长一段时间。有些智能家居设备可能连屏幕都没有，只是在那里默默采集数据默默控制家里的开关、温度和湿度等等。但无论如何，这些设备要和其他具有更强计算能力的设备互联，比如智能手机和云端服务器。因此，互联网化将是我们所讨论的这种业务的最本质特征。
为了描述方便，我们可以将所有参与此种业务的计算机软件一个明确的分类：服务器、客户端和微客户端，分别对应于服务器端应用、智能手机上运行的应用以及在智能手表上运行的应用。
这样，下一代智能操作系统将跨这三类应用，在各自设备上的传统操作系统支撑下运行。
在这样一个场景下，我们可以将某些东西做如下抽象：
容器。容器对应于传统操作系统上的进程概念。每个容器是一个完成特定应用任务的进程组。
数据流。数据流对应于传统操作系统上的文件或管道概念。容器接收、处理数据并产生数据。
存储。存储对应于传统操作系统上的文件系统概念，将提供直接基于 SQL 或者 NoSQL 数据库的存储抽象机制，应用无需处理文件及文件系统。
容器名。容器名对应传统操作系统上的文件名或套接字概念。容器之间通过符合某种规范的名称来找到对方或多方，建立信任关系后可互相发送数据。
数据处理驱动器。数据处理驱动器对应于传统操作系统上的驱动程序概念，本质上就是其他的传统操作系统实例。这些传统操作系统实例通过互联网协议连接到我们的下一代智能操作系统上，获取数据并通过 Java、PHP、Python 等语言进行数据的分析和处理，然后再反馈给其他容器。
这就是下一代智能操作系统的雏形。要我画个图吗？等我有空的时候补上吧，大家先脑补一下。
一些设计和实现细节
为了让大家对我所描述的下一代智能操作系统有个更具体的理解，这里给出一些设计细节供参考。
在设想中，我们提到将下一代智能操作系统建立在改造后的浏览器之上。但关键点并不是浏览器的 HTML5/CSS 渲染技术，而是建立在 WebSocket 或者传统 IM 机制上的消息机制。
通过 WebSocket 和 IM 机制，我们的容器名称将变成我们所熟知的微信号、QQ号等东西。当然，要区分不同的应用以及同一账号的不同设备。这样，我们的容器名将是：
<somebody>@<domain>/<device>
熟悉 XMPP 协议的人肯定知道这个名称是怎么来的。
类似针对文件的操作，在下一代智能操作系统中，我们通过上面的容器名来建立容器之间的连接，然后就可以通过 IM 机制互相传递消息了。用消息可以做什么？你可以实现请求和应答机制，也可以做数据收集，还可以做其他很多事情。就如同现在微信的公众号所做的事情那样。
当然，怎么发现连入同一个业务的其他容器呢？这就需要一个目录服务，提供类似文件系统遍历那样的机制。然后通过添加好友、同意请求等机制建立信任关系（这就是 Apple Watch 和 iOS 设备配对的过程）。当然，我们还可以通过 OTR（off-the-record，免记录）机制给建立连接的容器的通讯做加密处理。这点很重要，因为智能设备上的数据对使用者来讲，将是非常敏感的。
另外，我们还可以对同一个业务中的容器建立群组关系，或者订阅关系。嗯哼，是不是看到微信提供的各种服务的影子了？这就是腾讯为什么提出“微信连接万物”这个口号的原因。只是，当我们的下一代智能操作系统开发出来之后，你自己就可以连接万物，而你自己的数据将出现在自己信任的容器里边，不会跑到腾讯的服务器里边。
对运算能力比较弱的智能设备怎么办？其实问题不在我们一定要使用浏览器，而是要提供上面的抽象机制，这些抽象机制最终会演变成 API 槽，传统的操作系统需要实现这些槽，进而就可以将我们的容器运行在下一代智能操作系统中了。
那要是运行在已有的智能手机操作系统上，我们打算怎么办？其实我们也许不需要自己扩展一个浏览器。我们只需要提供一个服务，这个服务提供本地的 WebSocket 端口，并接收来自智能手表的数据，然后由浏览器中运行的 WebApp 连到这个 WebSocket 上就可以了。
为下一代智能操作系统开发一门新的编程语言
如前所述，为下一代智能操作系统开发一门专门的编程语言是可行的。这门编程语言不是如 C 那样的低层编程语言，而应该如 JavaScript 或者其他脚本语言那样，易学易用，同时是面向下一代智能操作系统抽象对象的编程语言。
但是，从工程的角度来讲，一门新的编程语言要变得成熟而被广泛接受，需要很长的时间。所以，务实一些的话，我们应该选择 JavaScript 或者 CoffeScript 来开发下一代智能操作系统，同时并行开发我们的专门编程语言。等成熟后再推广给开发者。
如此，大事可成也！
国内操作系统大PK
今天（3月24日），博主建的“下一代智能操作系统开发讨论”微信群，迎来了 DJYOS 等操作系统的主要开发者。这样，除了 COS、TVOS、YunOS 等国字头的操作系统没有代表参与本群讨论之外，基本上所有由说中文的开发者主导开发的操作系统都参与了相关讨论。
国内操作系统大阅兵
我们先看看国内都有哪些操作系统。注意：以下排名不分先后；来自操作系统的官方介绍用词经本人编辑并稍作修改，以求客观中立。
SylixOS。SylixOS 是目前国内功能最为完整的实时内核通用操作系统，全球第三个支持多核实时调度的 RTOS，性能与 VxWorks 相当，同时内核还提供了丰富的外设与文件系统类型支持。SylixOS 符合 IEEE1003/IEC9945/POSIX 规范，实时性方面符合 POSIX 1003.1b 规范。由于 SylixOS 接口的标准符合性，使之可以支持 GNU/Linux 上的多数应用程序，其中包括 Qt、MySQL 及 Apache 等。SylixOS 同时提供 VxWorks 软件兼容层，其中实现了 VxWorks 6+ 80% 的接口。SylixOS 不仅仅提供 C/C++ 编程，同时也支持 Python 等其他编程语言，开发者可通过完整的集成开发环境与虚拟机实现应用软件的开发。目前，SylixOS 主要支持 ARM v4-v8 体系架构，对 IA32 的支持由清华大学贡献，未来计划支持 PowerPC 和 MIPS 架构。
RT-Thread。RT-Thread 是国内曝光率最高的开源嵌入式实时操作系统（GPL v2+ 许可证），曾获国内开源项目评选奖项。RT-Thread 专注于小型嵌入式设备，麻雀虽小五脏俱全，在一个极低的尺寸上包含了硬实时内核、轻型的虚拟文件系统、完整的 lwIP TCP/IP 协议栈移植、相对完善的设备驱动框架（包括 USB host/device stack）、兼容度很高的 POSIX 接口和 ANSI C 运行环境等。RT-Thread 支持包括 ARM Cortex-M/R/A、IA32、MIPS、PowerPC、NIOS-II、Blackfin 等在内的多种架构，能够支持多种编译器和开发工具。RT-Thread 的商业支持由上海睿赛德提供，并针对一些特定领域提供超低功耗、高性能、高可靠性的技术方案。RT-Thread 目前除了用于工控等实时要求高的系统之外，也为新兴的智能可穿戴试设备提供超低功耗方案。社区上也有多轴飞行器等爱好者的优秀作品基于 RT-Thread 开发。
DJYOS。DJYOS（都江堰操作系统）是一种开源 RTOS，遵循 BSD 许可证发布，目前主要应用在工控领域，近期目标是替代 VxWorks。创始人期望通过开源社区合作模式打造一款通用操作系统，在不远的将来替代 Android 等智能操作系统。DJYOS 目前由自动化领域的专业公司（深瑞）主持开发。作为 RTOS，DJYOS 的调度实现机制有些特点，内核采用事件驱动模型开发，但仅提供基于 ANSI C 的开发环境，包括一些私有的 API。据主要开发者描述，DJYOS 可以不修改任何代码而支持 64 位处理器架构，并且在容错方面有自己的特长，可以在系统崩溃重启期间和启动关机过程中响应中断，还提供有优化的内存分配机制等。DJYOS 当前提供对 ARM 和 PowerPC 架构的支持。
Elastos。Elastos 是面向智能设备的通用操作系统。Elastos 内部使用了 CAR 技术（其作用类似微软的 WinRT），然后通过 CAR 技术来提供针对不同编程语言的接口层。Elastos 的目标是，将自有的构件技术结合主流的操作系统技术，研发具有先进系统架构，并不断发展自有特色的智能终端操作系统，以推动操作系统、构件技术以及编程语言的发展。目前，Elastos 提供了 Java 的 Android 兼容接口，同时还提供了一套 C++ 的 Android 兼容 API 接口。
Deepin Linux。Deepin（深度）Linux 是一款面向桌面的通用操作系统，属于 Linux 发行版范畴。深度 Linux 的最大特点是重写了许多 Linux 桌面上的常见应用软件，以求提高 Linux 发行版作为桌面操作系统的产品化程度，使之可以在一定程度上媲美 Windows 系统。
元心操作系统（抱歉没找到官网）。元心操作系统的主要开发者也介绍了元心操作系统的情况。目前，元心操作系统提供 Linux+Qt+WebApp 的混合模式，用户可以使用 Qt 开发应用，也可以开发 HTML5 的 WebApp。据主要开发者描述，元心操作系统在某款智能手表中表现良好。元心操作系统可能是这里唯一一个国字头操作系统了。
上面这几个操作系统基本上可以说是国内正在活跃开发的操作系统之典型范例了，代表了不同的产品思路。读者在接下来的描述中会看到非常有意思的争论。
不过在给大家介绍高手们过招的细节之前，我先吐槽一下这些操作系统的官网。当然，大家可以一一点开来看看就知道我要吐槽什么了：
所有的官网都还停留在 Web 1.0 时代，更不要说兼容移动端了！当然，Elastos 的官网有点 Web 2.0 的影子，可是很不稳定。据说是把服务器放在了公司里边，所以周末的时候会关机。听到这个，我的这个汗啊，那是止不住的流！
高手过招，最嫌爹妈只给生了两只手
周二（3月24日）傍晚，就有关操作系统的定位讨论到了白热化阶段。说实话，混乱了好一阵子，谁也无法说服谁。其中主要的议题集中在 Elastos 兼容 Android 这一特性上。
Elastos 开发者认为，通过兼容 Android 才能充分利用 Android 生态中已有的应用。比如，Elastos 推向市场时，我们就可以说所有的 Android 应用都可以运行在 Elastos 上，重新编译都不要。然后，等到有一定地位了，开发者尝到用 Elastos 的甜头了，告诉他说，其实你的应用跑在 Elastos 上而不是 Android 上，怎么样，比谷歌的 Android 好吧。然后，Elastos 最终抢占 Android 的份额，厂商纷纷找 Elastos 合作，开发者开始使用 Elastos 提供的其他 API（C++ 的，性能更好）。最终，Elastos 踢掉谷歌，成为智能手机操作系统的新霸主，制定规则并赚取商业利益。
对这一模式，高手的看法明显分成了两派：
必须兼容派：兼容是必须，不兼容没戏唱。
兼容无用派：兼容是死路一条。
当然，还有一派认为应该是看情况确定。这个按下不表，将来再说。
我们先分析 Elastos 路线中的逻辑问题。注意，我们经常看到一些洗脑的话（俗称“心灵鸡汤”），里边有“所以”或者“然后”两个字，很多人就以为后面的结论是自然得出来的，是符合逻辑的，少有人去仔细分析其实“所以”或者“然后”两个字之前根本就没有靠得住的论据。
在博主看来，Elastos 路线中存在如下几个重要的逻辑硬伤：
当你推出 Elastos 并以兼容 Android 为卖点时，用户（这里指开发者）可能接受了，也许是因为 Elastos 的性能要比谷歌的 Android 好一些，或者谷歌的 Android 尚不支持用户选择的硬件平台，或者你会给用户钱（如同阿里 YunOS 干的那样）。反正最后用户用了你的系统。但注意，用户用 Elastos 的根本原因是 Elastos 兼容 Android。所以，用户会继续用 Java 的 Android 接口来开发他的应用。因为兼容是 Elastos 的卖点，而且 Java 的 Elastos 应用还可以跑在谷歌的 Android 上，那为什么要用 Elastos 的 C++ 接口？在这种情况下，Elastos 号称的其他好处，恐怕没有几个用户会真心实意地尝试，而且 Elastos 的实现一旦有不兼容的地方，或者 Android 升级带来了接口变化，用户肯定会首先要求 Elastos 修改系统，使之 100% 兼容。其结果就是，在用户眼里，Elastos 就是 Android，充其量就是个优化或者适合特定硬件平台的 Android 实现。Elastos 里边的 CAR 技术，对操作系统的实现有意义，但对用户没有意义。
这个路线没有考虑到兼容一个良性发展的生态系统之操作系统（Android）的最大风险：Android 自身的升级和优化。毋庸置疑，Android 现在正处在一个良性发展的生态系统中，Android 自身的更新速度非常快。Elastos 选择兼容 Android，也要不停兼容 Android 的升级版本。这其中的难度将是巨大的。说白了，Elastos 的路线做了一个非常大胆的假定：Android 将停滞不前。这样的一个假定下得出的结论是靠不住的。
也就是说，Elastos 路线中的第一步可以跨出去，但接下来发生的事情是不太可能按照自己设想的路线前进的。
经过两派的唇枪舌战，两派谁也未能说服谁。Elastos 开发者最后的陈述如下：
手机市场很大，哪怕我们仅占一点点市场份额，也会很大。执着是我们的理念。
兼容之争在第二天继续
兼容之争在周三（3月25日）继续，毕竟我们没有得到一个大部分人都认同的结论。不过，Elastos 的总架构师陈榕博士在周三凌晨阐述了一下 Elastos 的设计理念：
兼容 Android 应用就没有前途吗？Elastos 用 C++/CAR 重新实现了 Android 框架，主要是为了实现分布式系统。俗称为“家庭云”。设想同样是跑 Skype，用户如果能动态切换摄像头，如果能在移动终端跑云盘程序，家庭云跑程序后把屏幕刷到远程终端上，或者每个应用跑在独立的虚拟沙箱里，输入法之类跑在另外沙箱里。同样跑个安卓应用，是否可以不局限于本地孤立的硬件计算机上？
云盘是否可以代替网站？移动终端上的 Elastos 是否可以是二进制代码的浏览器？硬件计算机与网络组成的家庭云上面，是否可以跑许多软件或者硬件的虚拟机和物理机？而虚拟机操作系统完全没有网络编程接口，仍然可以实现所有 SaaS 的能力？
之前说我没看懂，其实是我错了，向大家道歉。我从手机上把陈总的观点逐字输入后，我大致明白了：Elastos 终极要实现的目标貌似和我所提的下一代智能操作系统是一样的。只是我们的路线不一样：我是希望建立在现有的传统操作系统之上，充分利用现有的资源；Elastos 是要整个重写传统的操作系统。
再回过头来看兼容问题。博主本人是兼容无用派，所以我对 Elastos 的看法是：
Elastos 操作系统的设计理念很先进，未来也看起来很美好，但却陷在了兼容 Android 的泥潭中无法自拔，动弹不得。Elastos 的路线需要反思。
我为什么认为兼容是无用的呢？先给大家打个比方：
某个人把 Android 的内核从 Linux 换成了 BSD，那 Android 还是 Android 吗？几乎所有人针对这个问题的答案是肯定的。那么，如果把 Android 的虚拟机换成自己的实现（阿里 YunOS 最初就是这个路线），还是 Android 吗？大部分人针对这个问题的答案还是肯定的。这个问题继续演进；如果把 Android 里边所有的东西都换了，但还是提供 Android 一样的 API，一样的框架，一样的系统应用，一样的界面效果，那还是 Android 吗？笔者的回答仍然是肯定，读者您呢？
博主认为，一个操作系统区别于另外一个操作系统，最本质的部分就是 API。这点在博主本人的其他文章中有过多次阐述。只有 API 是操作系统的 DNA，其他的都不是。
有关兼容这个问题，兼容无用派的很多群友还提到如下事实：iOS 替代功能机没有选择兼容，Android 通过谷歌占得巨大市场份额，没有选择兼容，那么为什么我们做操作系统首先想到的就是兼容呢？
可能 Elastos 工程师的回答比较引人深思：
我们曾尝试推广自己设计的 API，但发现根本没有人用，我们自己也不用。
Elastos 工程师甚至怀疑我们自己是否有能力设计一套自己的框架和 API。
理性的分析结论
周三（3月25日）上午，兼容之争终于落下了帷幕。在此之前，博主需要阐明两个概念：
复制或模仿。偏市场的人员通常会使用这个两个词。
兼容。偏技术的人更多使用这个词。
这两个术语在市场人员和技术人员共同参与讨论问题的时候会出现很大的混乱。技术人员认为说复制、模仿就是技术层面的兼容；而市场人员听到技术人员说兼容以为谈的是复制或模仿。这里需要分清楚：复制或者模仿是产品层面的，而兼容是技术层面的。
在接下来的讨论中，博主兼群主使用了问答式方法来主持讨论。
第一个问题是：为什么人们会想到兼容其它系统？这是由于，市场上某个系统已经有大面积的市场份额，大家想兼容他，就是利用人家形成的生态系统。
第二个问题是：复制/模仿和兼容的区别是什么？复制/模仿和兼容不是一个层面上的东西。Android 模仿/复制 iOS，但搞的不是兼容。这就是区别。
第三个问题是：如果我们要做智能手表操作系统，有没有必要复制/模仿 Android Wear，有没有必要兼容 Android Wear。就兼容这个子问题，其答案可采纳群友的话：
没必要，因为 Android Wear 也是不够成熟。
对是否有必要复制/模仿 Android Wear 的问题，同样引用群友的话：
当我们对功能和特性感到迷茫和纠结的时候，看看 Android Wear 或 Apple Watch。
结合博主针对 Elastos 的分析，我们基本上可以就兼容问题盖棺定论了：
按照必须兼容派的观点讲，是否兼容要看对方是否已经形成了一个良性发展的生态，就是是否已经有众多的开发者为那个系统写应用；然而，当这个系统已经形成了良性发展生态的时候，博主认为已经没有机会了（具体分析见上个小节）——兼容也是白搭。
其实，兼容就是个悖论，嘿嘿嘿...
一些注解
为了避免不必要的误解，这个小节把我们正在讨论的概念做一些限定，并就博主的观点做一些必要的阐明。
这里所谈的兼容，是特指用新的实现去兼容某个其他已有的操作系统接口。比如重新实现 Android API 和框架，重新实现 Win32 API 等。
有时候，操作系统会提到符合某些标准规范，比如 *NIX 相关的 POSIX 标准。这种情况下，我们称之为标准符合性，而不是兼容。符合某个标准的英文表达为 conform to XXX，兼容某个接口的英文表达为 compatible to XXX。有时候，符合某个标准，在中文里边也会表达为兼容某个标准。为了避免误解，还是遵从这里的建议用法为好。
另外，之前提到，对兼容的看法还有第三个派别，可以称为中间派。中间派的看法是这样的：
除了兼容与不兼容两派外，我觉得还有第三派：从不兼容到兼容，无非区分存量市场还是增量市场。在增量市场，兼容代价这么高，为什么要兼容？在存量市场，只能到别人的池子捞鱼，必须兼容，但这种兼容是手段，不是目的，所以较好的策略是有选择的去兼容，选主流一个版本兼容，如果捞够鱼了就撤，没捞够就再跟几个版本。在智能可穿戴式市场应先弃兼容，后续若拓展到其它领域（如TV），有条件地考虑兼容。
最后，博主还需要说明一下的是，虽然在本文中博主以 Elastos 为例批评了兼容派的错误路线。但博主从未否定 Elastos 使用构件技术来构造操作系统的思想，而这一思想是 Elastos 开发者引以为豪的“精髓”。
再回到智能操作系统上
就兼容的讨论基本落下帷幕之后，群众的讨论进一步深入下去了，主要议题集中在：
我们是否有能力为新的智能操作系统设计一套 API？
智能操作系统应该长成什么模样？
为避免扩大议题范围，我们将这两个议题限定在以智能手表为代表的智能可穿戴式设备上。
操作系统 API 的设计挑战
博主之前曾提到 API（包括用于表达 API 的编程语言以及 API 之下的框架结构）是操作系统的 DNA。显然，API 的设计是非常讲究的，有群友甚至说到：
API 的设计是哲学问题，需要大神才能搞定（大意）。
这话虽然有点夸张，但的确说明了 API 设计的难度。博主认为，设计 API 的工程师，必定要
有较强的数学功底，从而有非常好的归纳和抽象能力；
对计算机系统、互联网相关协议的深入理解，知悉 API 设计可能给编程带来的好处或者副作用；
深入理解用于描述 API 之编程语言的优势和劣势；
丰富的开发经验，知道优秀的 API 是如何设计的；
...
遗憾的是，从高手们交流的情况来看，大家对提供一套好的 API 没有太大的信心。博主也记得在十多年前，我主持开发的 MiniGUI 之 API 也曾遭批评。
那么，这种情况下，我们应该采取哪种方法或者路径（方法论）来设计 API？这里博主给出几个建议：
模仿已有的成熟软件之 API 设计。
分清模块或组件，降低或取消模块及组件之间的耦合关系。
抽象模块或组件的功能，设计 API 的同时使用 API 给出典型示例，看其设计的合理性。也可以引入草案、试用、修改、成熟的一个迭代机制。
API 的修订，必须充分考虑向前兼容性。
从历史上看，优秀的 API 设计也不是一开始就是那样，大部分都有一个演进过程。这和操作系统的编程语言、框架都有关系。博主相信，只有真正做起来了，一切才有可能；怕是没有用的，也不必妄自菲薄。
智能操作系统需求
来自市场人员的需求描述：
我们简单做个类比，PC 领域，DOS-Windows 3.1-Windows 95。当 Windows 95 出现以后，PC 才拥有一点智能，互联网因此磅礴成长。我所认为的是，当前的嵌入式系统解决方案相对来讲，还是比 DOS 低，我们在寻找一个穿戴设备的 Windows 95。 我们内心希望有一个智能一些的操作系统出现，只有操作系统有了智能，这个物联网啥的才有机会智能。
要理解这个需求的背景，需要知道国内开发智能手表的两种方法：
为了提高待机时间，往往选择比较低端的处理器，然后因为处理能力的限制，运行在 uC/OS-II 等的 RTOS 上，使用 uC/GUI 开发图形界面，然后通过蓝牙将数据传输到智能手机上做进一步展示和分析。
君正为代表的芯片厂商直接使用 Android 系统，进行裁剪后运行在自己的芯片上，并向设备厂商以 Turnkey 方案进行推广。
这两个方案都遇到了问题。前者的问题是编程困难，互联能力弱，智能化不够，和 Apple Watch 差距太大；后者的问题是系统臃肿，可用性较低（这也是谷歌为什么单独推出 Android Wear 的原因）。
另外，上述需求隐含了一个重要的智能需求：互联网化。也就是说，只有一个设备可以接入互联网，并和其他设备互联互通，才能称为智能设备，运行其上的操作系统才能称为智能操作系统。注意：这里的“智能”一词，来自于英文的 smart 这个单词，而不是 intelligent。
来自智能设备开发商的需求描述：
期望有个新的操作系统。第一：继承，在单个节点核心部分可能改动不大。第二：满足新的需求，智能、互联、分布式、云端服务。第三：透明，隐藏传统操作系统的很多概念，甚至大部分概念。
来自操作系统开发者的需求描述：
去中心化的自组网功能应该是下一代OS的重要组成部分，现在的移动操作系统，离开了云几乎就完蛋了，自身就是个传感器收集器而已，智能还比较远。
操作系统的理论都可以高大上，但是从实用角度上说，工程化实现和成本不得不考虑，现在什么都丢到云上，云瘫痪了不考虑吗？云的数据泄漏不考虑吗？本群题目太大，但是饭要一口一口吃，什么是最重要的，最急迫的，性价比最合适的，这个讨论才有意义。
我觉得下一代智能OS，应该多考虑智能部分，不是仅停留在对智能设备的支持上，而是在应用支持，资源调度，安全管理等方面更加智能化。未来的OS是要支持机器人联网的啊。
...
所以我觉得下一代的系统应该是内核紧耦合而上层松耦合，并且可以和具体环境动态平衡的系统，包括自组网，云策略等等。不在乎一定要用某种系统，而在于实现和效率。
以后的芯片更加快，带宽更大，能耗更低，很多现在的问题都不是问题了，所以不能完全按照我们这些老家伙的经验来看未来的系统。
来自应用开发者的需求描述：
对于俺们来说，支持多操作系统的应用开发恐怕更实际些。
从来自高手的需求描述来看，我们大致可以勾画出新的智能操作系统之大概模样：
互联能力。新的智能操作系统要能够连入互联网，也能够通过蓝牙、WiFi 直连等技术手段和其他智能设备互联。
安装和运行第三方应用的能力。这一点和第一点一起，形成了智能操作系统和嵌入式操作系统的本质区别。
能够和现有其他操作系统（Android 和 iOS）在应用层面上实现交互，而无需修改这些操作系统的内核或者系统程序，避免重新构造这些操作系统。
在我们新的智能操作系统以及已有的 Android、iOS 等系统上，可以用一种编程语言，一种模式来编程；甚至云端开发也被统一到一个框架中，这样应用的开发就会非常方便。
有好用的开发环境（包括 IDE 和虚拟运行环境）。
接下来，为了让讨论更加有目的性，博主将尝试给出一个更加详细的下一代智能操作系统的工程建议。在此之前，我们根据群友提供的资料，看一看 Apple Watch 中的操作系统如何和 iOS 设备交互：
Apple Watch 的 UI 框架来自于 iOS 的 UIKit，但做了一些修改以适应 Apple Watch 的屏幕。这对开发人员来说开发 UI 的效率会比较高。其他的非 UI 类库，我目前还没有发现 Apple Watch 应用不能用的 iOS 非 UI 接口。但因为功耗限制和其他原因，目前 Apple Watch 应用还是需要以 iOS 扩展的方式运行在 iPhone 上。
Apple Watch 和 iPhone 的通信可分为两层。底层是物理链路层的通信，包括 WiFi、蓝牙等；高层是应用层的通信。高层的通信在 iOS 上运行的 WatchKit 和 Apple Watch 上运行的 WatchKit 之间进行。（博主注：类似远程过程调用，RPC 机制）。
下一代智能操作系统的技术路线
本节将阐述博主所提出的下一代智能操作系统的合理技术路线，也就是从工程角度上讲，如何确保一步步迭代达到我们最初的设想目标。
开源趋势
周四（3月26日），“下一代智能操作系统开发讨论”群迎来了诸多活跃在开源领域的大侠，比如苏哲、陈皓（@左耳朵耗子）、梁昌泰（@挨弹腿踢梁昌泰）等。值得一提的是，苏哲、梁昌泰以及这个群里边的陶品、谢巍、陈昊等都是 AKA 组织的早期成员。
苏哲和程强为大家介绍了 JavaScript 相关的一些前沿技术，整理在这里供大家参考：
asm.js。asm.js 这个项目是 Mozilla 在几年前发起的开源项目，其目标是将所有由其他编程语言开发的代码翻译成 JavaScript 而在浏览器中执行（相当于把 JavaScript 作为浏览器的汇编语言使用，所以称为 asm.js）。asm.js 本质上是一个 JavaScript 语言子集，可被“离奇”优化。最新的测试结果声称其性能已经非常接近原生代码。如果这个项目成功了，那恐怕浏览器真的就变成了操作系统，我们将来就是为浏览器编程了。
React。这是 Facebook 基于 React.js 库开发的，可帮助开发者用 JavaScript 语言开发 iOS 和 Android 上的原生（Native）应用。注意是原生应用而不是通过浏览器来执行最终的应用代码。React 已经用于生产环境——Facebook Groups 的 iOS 版本就是基于它开发的。有关 React 的中文介绍可参阅刘江的这篇译文。
Ractive.js。Ractive.js 是一种模板驱动的 UI 库，但不像其他库（这里应该是针对其他的 JavaScript 前端技术，比如 Angular.js 等而言的）生成笨拙的 HTML，它会默认将模板转换成面向交互式应用的蓝图（Ractive.js is a template-driven UI library, but unlike other tools that generate inert HTML, it transforms your templates into blueprints for apps that are interactive by default)。其主要特点有：更漂亮的数据绑定声明语法；更好的事件处理机制；灵活及高效的动画和过渡效果。
总体来讲，围绕 HTML5/JavaScript 的业界最前沿趋势有两个。一个是通过 JS 开发原生应用（直接运行在 Android 或者 iOS 上），一个是通过 JS 开发 WebApp（运行在浏览器里边或者浏览器壳里边）。前者的代表是 Facebook 的 React 以及 Google 的 Singular（因为众所周知的原因，未找到更多介绍资料）；后者的代表是 Meteor 以及 Ractive.js 以及 Angular.js 等。asm.js 则更加激进一些，也许某一天能改变整个 Web 世界。
但不管如何，看起来 JavaScript 的发展势头不可挡。
技术路线之建议
要实现下一代智能操作系统，首先要遵循如下几个基本原则：
循序渐进，逐步迭代。博主提出的下一代智能操作系统之设想无法一蹴而就，必须结合市场需求循序渐进，逐步迭代。但有一个远期的宏观目标是必须的，否则容易走错方向。
开源和利用已有开源技术。为发展下一代智能操作系统，必须利用已有的开源技术，这些开源技术使用了不同的开源许可证，为了兼容这些不同的许可证，GPL 许可证可能是最佳选择。
工程实践和前瞻性开发结合。为下一代智能操作系统发展一种新的编程语言是有必要和有意义的，因此，整个项目应该划分成为工程项目和科研项目两类。工程项目的参与主体是企业，科研项目的参与主体是开源社区和科研机构。
国际化。该项目必须通过 GitHub、StackOverFlow 等成为国际化项目。
在以上原则指导下，一种可行的技术路线如下：
第一阶段
第一阶段的目标是要在 2015 年年底或 2016 年初，开发完成针对低端和高端两款智能手表的从手表、手机到后端的完整系统，并初步形成下一代智能操作系统的雏形，并可供第三方为智能手表开发应用：
以 JavaScript 为统一开发语言。
以 Linux 和国内主持开发的某个 RTOS 为内核（笔者推荐 RT-Thread 或 SylixOS），分别针对高端智能设备和低端智能设备发展针对智能设备的传统操作系统。注意，除了内核之外，要定义两种配置（profile）下的不同框架及 API。后者是前者的子集。
以 Meteor 为基础原型做进一步的扩展（主要集中在建立于 WebSocket 之上的数据流及通讯机制），主要目标是实现跨平台应用开发和前后端统一的应用开发，这主要涉及 Android 和 iOS 两个平台。
智能设备上的传统操作系统，需同时考虑互联网以及 P2P 通讯环境（蓝牙、WiFi 直连）下的底层通讯机制，并整合到 Meteor 的扩展中。
智能设备上的传统操作系统，要分别针对低端和高端智能设备发展 JS 扩展，前者不运行完整浏览器，后者可运行完整浏览器或者 React 技术支撑下的原生应用开发。
第二阶段
第二阶段的主要目标是形成针对下一代智能操作系统的第一个版本，确定 API，提供可用的 SDK 及开发工具，发展应用商店，建立生态系统雏形。这一阶段的开发会更多关注云端的容器实现上，这对形成良好的生态系统获得利润有重要作用。也是下一代智能操作系统分布式特征的主要指标。
预期达成目标的时间点为 2016 年底。
第三阶段
进一步发展生态，开始提供新的编程语言，进一步发展整个生态系统，并将其扩展到其他领域。
对编程语言的要求如下：
新语言应该针对下一代智能操作系统的抽象模型做专门设计。
该语言应该可以被编译或者翻译成 JavaScript 以便在浏览器中运行。
该语言应可直接编译成机器码运行在比较低端的智能设备上。
CSE 语言作者陈强针对下一代智能操作系统的编程语言撰写了一篇博客，有兴趣的读者可以参阅："为NGSOS智能操作系统设计编程语言"。
合作共赢
鉴于该项目的复杂程度，该项目需多方合作才能达到目标，其中的主要合作方有：
领导该项目的实体企业。
传统操作系统厂商（这里主要指实时操作系统厂商）。
开源社区。高校等科研机构通过开源社区参与。
如何平衡这些参与方的诉求以及商业目标，需要具有极高水平的规划师，这方面还是交给商业运营高手吧。
结语
经过近一周的高手间的讨论和交流，我们基本确定了一个较为清晰的可操作技术路线。本篇博客也将结束（必要的修订还会继续），接下来该是实战了。但高手们的交流并未停止。欢迎其他有兴趣的群友撰写每日的交流总结，以供其他不在群里的人了解我们交流的成果。
第三节 三谈智能操作系统
2012年，借着阿里云操作系统被谷歌打压的事件，我写了有关操作系统的第一篇文章：《“自主”操作系统——为什么及如何》（见本文末尾原文链接）。2015年，是我比较闲的时候，曾试图发起一个下一代智能操作系统的开源项目，撰写了有关操作系统的第二篇文章：《有关智能操作系统的讨论》。转眼三年过去了，作为中美贸易战的一部分，针对中国著名的通讯企业中兴通讯，美国商务部下达了一份禁令，禁止美国企业向中兴通讯提供任何产品和服务。一夜之间，有关中国高科技产业缺芯少魂的文章再一次刷遍了朋友圈。
昨天（2018年4月25日）的最新消息，美国司法部开始调查华为……
我不懂芯片的设计和制造，但作为软件行业从业者，就中国高科技产品里边的魂（操作系统），我还是可以继续说道说道的。所以有了这第三篇文章：《三谈操作系统》。
写这篇文章之前，我把六年前、三年前的第一、二篇文章又拿出来读了读。有些说法已经过时，但核心观点还是正确的。这里先总结一下，以便让大家不必再费心费力读这两篇文章，亦可对我的想法有个了解。
前情提要
在第一篇文章里边，我重新定义了“自主”的含义。提出“自主”是“有效知识产权保护下的自己主导”而不是“自有知识产权”。后来很多人都提“自主可控”，最初的说法大概来自这篇文章。
在第一篇文章中，我批判了什么样的操作系统不是自主的操作系统，指出自主操作系统必须建立自己的生态系统，并且详细从技术层面阐述了如何开发一个自主的操作系统。其要点是：用一个特别的编程语言发展自己的 API（应用程序编程接口）。
六年过去了，很多人仍然不能理解我第一篇文章中提到的思路，仍然在走一些错误的路线。
三年前，在撰写第二篇文章之时，国内顶尖的高手们通过我组织的“下一代智能操作系统”微信群讨论过有关操作系统的方法论，强烈批判了做 Android 兼容操作系统的思路。比如阿里的 YunOS、科泰的Elastos 等。三年过去了，阿里的YunOS 改名叫AliOS，转做车联网了，是不是兼容 Android 不重要，也不必要了；Elastos 趁着区块链的热潮成功 ICO 了，兼容 Android 的初心改成了支持 Dapp。
作为旁观者，我不得不感叹：人们所犯的错误里边的大部分，也许就是这种常识性错误。人们有时候所说的“执着”，大概就是“明知不可为而为之”的胆量吧。
操作系统的概念
操作系统是非常基础的系统软件，它支撑所有的应用程序执行。但操作系统以及相关术语的不规范使用，经常会给我们带来一些认知上的混乱，比如，所有人都知道Linux 是一个操作系统，但基于Linux 的Android 也被称为操作系统。
目前大家公认的操作系统定义，应该和百度百科给出的一样：
操作系统（Operating System，简称OS）是管理和控制计算机硬件与软件资源的计算机程序，是直接运行在“裸机”上的最基本的系统软件，任何其他软件都必须在操作系统的支持下才能运行。
但这个定义需要做些调整。
我认为，运行在特定硬件运算平台之上，为上层应用程序提供了完备、自洽的程序接口，方便开发人员利用各种硬件资源开发应用程序的系统软件，就可以称为“操作系统”。
在上面这个定义里边，我强调如下两个概念：
操作系统必须提供完备、自洽的程序接口；
操作系统首要服务于开发人员（软件工程师）。
百度百科给出的操作系统定义，其实应该属于另一个术语“内核（Kernel）”。比如 Linux 操作系统，本质上是 Linux 内核外加一些基础的函数库、工具等形成的。基于此原因，自由软件基金会的 Richard Stallman 就一直强调应该把 Linux 操作系统称为“GNU/Linux”操作系统，因为配合 Linux 内核工作的基础库和工具，是由自由软件基金会组织开发的，这个项目的名称是 GNU。
一个操作系统的内核，会通过特定的手段提供一些接口，但这些接口相对原始，对开发者并不友好，而且不同的操作系统可能会提供不同的接口。后来大家想到一个办法，通过对原始接口做进一步的封装，可以让开发者不管用哪个内核，都可以使用统一的接口来编写应用程序。为满足这个需求，出现了 POSIX 标准。目前大部分的操作系统都遵循 POSIX 标准为应用程序提供接口。
但是，基于 POSIX 标准的操作系统接口仍然比较底层，对程序员的要求较高，一般需要使用较为低级的计算机编程语言（常见的如C语言）来开发应用程序。而后来出现的图形用户界面，由于各个操作系统厂家的实现差异太大，并没有形成统一的标准，这就导致了很多操作系统，就算针对同一种领域，比如同为桌面电脑操作系统的 Windows 和 MacOS，在接口上也存在着巨大的差异。
而操作系统提供给应用程序的编程接口，其实是围绕操作系统形成的生态体系之护城河。
何为操作系统的生态
在各种谈及中国高科技领域缺芯少魂的文章中，90% 都会提到中国做芯片也好，做操作系统也罢，均需要巨大的资金和人力投入，而且很难打破已有的成功芯片或者操作系统通过长时间的市场营销打造出来的生态系统之铜墙铁壁。但何为芯片或者操作系统的生态，鲜有文章可以阐明。
本文不打算谈芯片的生态系统，这里谈谈操作系统的生态系统。
就我来看，操作系统的生态系统实际上就是围绕操作系统对外提供的接口形成的。也就是说，不同的操作系统，本质区别就在于其接口不同。不同的接口，意味着不同的操作系统。或者说，接口就是操作系统的基因。甚至在智能手机时代，不同的操作系统提供了不同的编程语言。比如 Android，其接口在 Java 编程语言基础上建立，而 iOS，早期使用 Objective-C 编程语言，近两年切换到了对开发者更加友好的Swift 编程语言。显然，使用不同的编程语言，操作系统的接口肯定会更加不同。再比如，桌面操作系统的两大霸主 Windows 和 MacOS，所提供的接口几乎没有重叠之处。
显然，美国人很清楚，打造一个操作系统，从一开始就要考虑赋予这个操作系统以不同的基因，并围绕这个基因打造生态系统。
特定操作系统的生态系统，说白了是由围绕这个操作系统的开发者构成的。有的开发者开发应用，有的开发者开发工具，大家协调配合，热闹起来，事儿就成了一半。显然，有更多的开发者，这个生态系统就会更加强大。缺少了开发者，操作系统将是一潭死水，无法持续发展。当然，一个生态系统要良性发展，生态系统中的各方都需要获得利益：操作系统厂商要赚钱，而开发者也要赚钱。
这就是为什么我在前文中，强调操作系统的首要用户是开发者的原因。也是为什么我极力反对搞兼容（比如兼容 Android）操作系统的原因——就算你做了一个更好的 Android，也是在为谷歌的 Android 生态系统添砖加瓦。
一切还要看市场基础
生态系统是表象，而市场基础才是根本。假如没有市场基础，开发者就不会为某个操作系统开发应用，缺少了开发者的操作系统，自然无法长久。
拿 Linux 举个例子。为什么 Linux 成了全世界最流行的操作系统内核？最根本的原因是 Linux 的出现恰逢其时（有市场基础），其次是 Linux 使用 GPL 许可证保持了开源和免费，而第三个原因是 Linux 借它的内部接口形成了自己的生态系统。
作为内核，Linux 向上层提供了符合 POSIX 标准的接口，而向下为硬件外设提供了统一的驱动程序接口。正是因为 Linux 为硬件提供了统一和稳定的驱动程序接口，使得 Linux 成为硬件生产商开发计算机硬件外设时的首选，这让 Linux 内核中存在着大量的各类驱动程序，进而聚拢了大量的内核开发者，而这反过来又促进了 Linux 内核的广泛应用。
这也可以解释，为什么国产的那些各种各样的 Linux 发行版，除了政府或者极少的行业客户之外，在民用市场几乎没有任何建树，更谈不上取代 Windows 了。其表面原因是，除了操作系统厂商之外，没有开发者为这个操作系统开发应用，也就无法形成良性的生态系统。但从根子上讲，这是由于市场需求疲软造成的——Windows 的市场地位不可撼动，而开发者无法通过开发这些操作系统上的应用软件赚到钱。或者，换句话说，国产的那些针对桌面的 Linux 发行版，是不可能围绕政府“自主可控”的口号创建一个生态系统的——没有这个市场基础。
所以，做一个操作系统，最根本是要有市场基础。在有确定的市场基础之前提下，一定要赋予这个操作系统以独特的基因（接口），并围绕这个基因打造这个操作系统的护城河——生态系统。如此才有成功的可能。
国产操作系统是否还有机会
看过梁宁那篇《关于国产芯片和操作系统的一些往事》的读者一定知道，几十年来，倪光南院士一直在奔走呼吁，希望政府牵头、大企业支持一同打造自主可控的国产CPU和操作系统。
不说芯片，就操作系统来讲，我不太认同让政府牵头的做法。如前所述，一个新操作系统的发展一定要有市场基础，没有市场基础，我的接口生态论是不成立的。目前，在服务器、桌面、智能手机领域，美国巨头没有给我们留下任何市场机会。所以，我认为国内那些林林总总的国产桌面操作系统（包括国产智能手机操作系统），是没有任何机会的，顶多就是赚点政府的钱。
但国产操作系统仍然有机会，但机会一定来自新的市场。
以通用操作系统为例。新的操作系统，往往在计算机的设备形态，尤其是交互方式发生变化时出现。比如个人电脑上最初运行的DOS，有了图形终端和鼠标后出现了Windows系统；而智能手机的出现催生了iOS和Android系统，对应的交互方式从鼠标变成了触摸屏。
所以我认为，当计算机的形态（比如人机交互方式）发生重要变化时，才会给新的操作系统带来发展机遇。或者反过来讲，新的操作系统要为新的计算机形态，尤其是新的交互方式进行设计才有发展壮大的机会。其中深层次的原因是计算机形态（如交互形态）的变化，会使得操作系统的软件栈发生变化，进而会催生出新的应用编程接口。如前所述，应用编程接口则是操作系统赖以构建自己的生态系统的护城河。
所以国产的操作系统要想在竞争中胜出，就必须先他人一步去为新的计算机形态做准备。那么，新的计算机形态会是什么样的？其实不同于服务器、桌面和智能手机的计算机设备在近几年越来越多，比如智能音箱、智能门锁为代表的智能硬件，工业机器人，物联网，车载系统等等，而且随着各行各业信息化的发展，会有更多不同于传统计算机形态的产品出现（最具革命性特征的应该是量子计算机），而这就是国产操作系统的机会所在。
再次强调，针对服务器、桌面和智能手机的通用操作系统领域，国产操作系统不会有任何机会。如果您还在持续投入，那最好尽早放弃。
国内正在开发的几个典型操作系统
除了那些吃政府饭的操作系统之外，国内一直有几批人在针对不同的领域开发自己的操作系统。在第二篇文章里边，我对比了几个国产的原创操作系统，接下来看看这些操作系统的现状。那些原来做操作系统，后来项目整个儿转移到区块链，搞ICO 的，比如 Elastos、Ruff等等，人家已经进入了另一个世界（币圈），这里就不赘述了。
LiteOS
作为贯彻任正非 2012 实验室讲话精神的产物，华为在 2015 年推出了LiteOS 操作系统。LiteOS 面向物联网，本质上属于一种 RTOS（实时操作系统），增加了物联网相关协议的支持，整合了一些云端服务。目前正在做大力推广。
LiteOS 是华为第一次做操作系统，这个操作系统未来怎么样，不好说。但从旁人看来，LiteOS 和华为的体量有那么一点儿不匹配。毕竟 RTOS 这个东西，全世界前前后后出现过太多了，据说光开源的 RTOS就有两千多个，还有完全开源免费的，比如 FreeRTOS。LiteOS 的独特性到底在哪里？如何迎合开发者？还需要华为仔细思考。
AliOS
“2017年9月27日，阿里巴巴发布全新的AliOS品牌及口号，面向汽车、IoT终端、IoT芯片和工业领域研发物联网操作系统，并整合原YunOS移动端业务。”这是阿里巴巴对 AliOS 的官方定义。
从原来的 YunOS 转向 AliOS，是阿里巴巴在操作系统领域的一个重要变化。这说明了一点：原来兼容Android 为目标的 YunOS 彻底失败。从我的判断看，AliOS 一下子要支持汽车、IoT 终端、IoT芯片、工业等这么多领域，有点勉为其难。从其市场动作看，AliOS 最关心的还是车载，也就是车联网。
SylixOS
SylixOS 属于传统 RTOS 范畴，主要市场目标是替代VxWorks 这个老牌的嵌入式实时操作系统。SylixOS在这几年取得了比较大的发展。2015 年的时候，大概十几个人的团队，目前已经一百人了，而且还在很多二线城市设立了分公司。SylixOS 的发展得益于军工、航空、航天等领域的自主可控需求，通过来自军工和行业客户的各种开发和定制项目，养活一个二百人的团队都是可能的。
RT-Thread
RT-Thread 的团队，去年拿到了“近千万”风险投资，算是国内基础软件领域不多的几个成功融资的项目。这个操作系统发展历史较长，最早的定位是一个实时嵌入式操作系统（RTOS），后来定位为物联网操作系统，是LiteOS 的竞争对手。和 LiteOS 相比较，这个操作系统的开发者基础要好一些，毕竟问世时间长很多。
RT-Thread 团队的问题在于，如何围绕这个操作系统构建自己的生态系统和商业模式。
DJYOS
DJYOS（DJY 是“都江堰”的拼音首字母缩写）是一款主要应用于单片机的操作系统。以前，单片机的开发非常原始，而 DJYOS 则为单片机应用提供了一个独特的操作系统，使得单片机上的开发变得容易起来，同时还能兼顾非常好的实时性要求。
OPENTHOS
OPENTHOS是个很有意思的操作系统。这个操作系统的目的是为传统的电脑（台式机或者笔记本等大屏终端设备）打造一款桌面操作系统。和大家都知道的红旗 Linux、中标 Linux 等不同，OPENTHOS 在大家都熟悉的 Android 系统基础之上进行开发。
2016年（也许是 2015年，反正是冬天），清华陈渝老师找我讨论过这个操作系统。按我的观点，这个项目当然是没有多大价值的，技术上、工程上都没有价值，最终会浪费大家的精力和时间。两年间，OPENTHOS 保持了开源，而且在持续发布新版本，但我仍然不看好这个系统。假定有政府或者行业的市场基础，先不说生态系统的问题，一个现实的问题是：你能跟得上 Android 的演进速度？
一般人不太明白我上面这个简单问题的深层次内涵。这里简单解释一下。Android 是谷歌控制下的智能手机操作系统，现在大部分人每天都在用。虽说 Android 是开源的，但开放的源代码不一定是最新的；另外，Android 版本之间的 API 差异很大。应用开发者为 Android 开发应用，都会跟着 Android 最新的版本走，首要目标是支持好智能手机上运行的 Android 版本。这就为 OPENTHOS 上面可以跑 Android应用埋下了一个重要的隐患。实际上，所有号称可以兼容 Android 的系统，最后都失败了，YunOS 如此，Elastos 亦如此，OPENTHOS 也不会例外，更何况 OPENTHOS 还试图同时兼容 Linux 上的原生应用程序。
LMOS 和 HOT-POT
这几年，民间也有高手在独立开发操作系统（内核），其中比较活跃的有LMOS 和HOT-POT。
LMOS 由彭东独立开发，主要支持 x86 架构，近期开源了支持ARM 架构的 LMOSEM。
HOT-POT 正在由谢宝友独立开发，目标是实现一款工业级的服务器操作系统，尚未正式面世。据谢宝友介绍，HOT-POT 还在起步阶段，这是作者“一份20年的情怀，也许还有一份淡淡的无奈，或者还有一点点不切实际的幻想”。
对这类个人发起的内核项目，除了口头上的支持之外，我没有其他任何异议。毕竟 Linux 最初也只是Linus 的个人爱好而已，没想到最后变成了全世界最牛的操作系统内核。不过我本人仍然有一些建议给他们：
不要重复前人走过的道路，要做，就做前人没做过的事情，走前人没走过的道路。比如最近RISC V 架构很火，有精力有愿望有情怀的独立开发者，能否针对 RISC V 架构设计一个全新的操作系统内核？
结语
很明显，中兴被禁运的事件将为国产芯片、操作系统等基础软件的发展带来契机。我本人祝贺还活着的操作系统从业者，尤其是仍然坚持自主操作系统理想的创业者。
然而，契机只是契机，能否借机发展壮大，实现人生理想，进而为国争光，则是另外一回事儿。
六年间我写的这三篇文章，苦口婆心地解释何为“自主”操作系统，何为操作系统生态，如何构建操作系统，其实都是纸上谈兵而已。现在，我们需要行动起来，去实践这一方法论。希望这些文字，能够对国内操作系统的从业者有所帮助。然而，我最希望的是，这是我最后一次撰写操作系统方法论的文章。
第四节 四谈操作系统之国产七宗罪
在《三谈操作系统》一文中，我说“但愿这是最后一篇谈论如何做操作系统的文章”。两个月过去了，看业界的反应，我感觉那三篇文章算是白写了。相反，我朋友圈近日又出现了新一轮为国产操作系统摇旗呐喊的转发。所以，我不得不再次披挂上阵，奋指疾敲，试图敲醒那些被假象蒙蔽了双眼的堂吉诃德们。
首先声明：笔者并不反对要有国产的、自主的、可控的操作系统，但我们要做自己的操作系统，必须尊重市场规律，必须放眼未来，在正确的操作系统开发方法论基础上去迭代和演进。我们已经失去了太多，不能一错再错。
本文所说国产操作系统，特指国产桌面操作系统。
国产操作系统嚷嚷了二十年，我们得到了什么？
这个问题有点敏感，会动很多人的奶酪。但这个问题不得不谈，因为在错误的方向上，我们不仅仅浪费了大量的资金，还浪费了二十年时光，而参与其中的为数不少的年轻工程师，把青春献给了这个“事业”。他们或彷徨，或失望，然时光如梭，黑发已成白头。
2000年左右，中国突然冒出来一批打着国产操作系统旗帜的公司，其中笔者曾供职过的中科红旗最为出名。后来，陆陆续续又出现了中标、普华、中科方德等公司。简单统计下，大概有二十多个公司先后以开发国产操作系统为业务开展经营活动。这些公司，有些已经折戟沉沙退出历史舞台，比如Bluepoint Linux、Turbo Linux 等；有些苟延残喘、艰难存活，如中科红旗，几年前的员工讨薪事件以及该公司和中科方德之间的恩怨，一度成为人们茶余饭后的笑谈；其他公司能坚持到现在还没有关门或者改行的，就已经是很不错的结果了。根据最新的统计，目前这个圈子（我不太愿意把这个圈子称为“行业”）里边仍然有八家公司。比较有意思的是，后来这个市场还出现了几个民营的软件公司，最为出名的是武汉的深度科技以及广西的一铭科技。
这么多公司搞出来的以 Linux 为基础的国产操作系统，其实就是桌面操作系统，其主要的目标市场是政府以及一些要害部门或者国企的办公使用，用来替换掉微软的 Windows。普通消费者和一般的企事业单位，根本就没有需求去使用基于 Linux 的桌面操作系统。一来，现在买电脑都预装了正版的操作系统；二来，盗版的成本仍然很低；三来，国产操作系统上没有那么多可以用的应用程序或者游戏可以满足普通消费者或者一般企事业单位的需求。
但其实，政府或者要害部门的办公使用的市场并不大，就算我们按照一年一百万台的装机量计算，500元一台的正版授权费，整个市场的容量也就是五亿，十家公司分，每家几千万元的收入，这点收入，连一百人规模的研发团队都养不起。再说，我上面估计的市场容量还是夸大的，政府并不敢大规模全部用国产操作系统来替代 Windows。真实的情况要除以 10，也就是说，差不多十家国产操作系统公司在分一个并不大的蛋糕，最后每家的真实年收入也就几百万，撑死一千万到头。
既然如此，为什么还有这么多公司前仆后继投入到这个行业？这其实很容易理解，这些公司主要靠政府的财政补贴或者扶持资金活着。
一开始，一些有强烈操作系统情结的老专家认为中国需要一个自己的操作系统，所以游说政府，说用别人的操作系统不安全，我们要用自己的操作系统，政府信了。然后就通过各种手段给这些公司输血，比如“核高基”项目，比如各种强制性的政府采购。于是，有背景的公司就很容易拿到国家撒的钱。但是，钱来得太容易就会有问题。这些公司没有几个是真心实意做操作系统的，勉强通过验收就行。这样一来，二十年过去了，国家该花的钱花了，该出的政策出了，没有一家公司从竞争中胜出，没有一家公司可以站出来跟 Windows 拼一拼市场。如此做的结果就是，这些公司基本都成了向政府要奶吃的巨婴公司。
如果是国资背景的公司，或者打着“中科”名号的公司参与这个行业，我是可以理解的，但我实在不明白为什么有那么几个民营公司也要进入这个市场？毕竟时间一长，这种圈子可能会滋生一个复杂的、有中国特色的利益链条。我们怎么能指望在这样一个利益链条上，出现可以让民营公司生存的土壤？
上个月，武汉深度科技的 CTO 王勇离职，在这个圈子里边引起了一些波澜。深度科技是个纯民营公司，一直在做 Deepin Linux 发行版，有一定的用户量，但坚持八年，并没有达到他们理想的目标。虽然王勇的离职有各种传说，但我认为八年的付出，并没有带来预期的效果（公司层面也好，个人层面也好，都是），这才是王勇离开的本质原因。
可以这么说，二十年间，我们在桌面操作系统领域并没有多少建树，用“裹足不前”来评价算是客气的了。
那么，国产桌面操作系统的问题到底出在哪里？
国产桌面操作系统七宗罪
1）错误的赛道，错误的方法
最根本的原因是找错了赛道。
国产桌面操作系统这个需求并不存在。因为桌面操作系统的霸主早在20年前就已经有了定论，微软 Windows 的地位无人撼动。就算在美国，也没有公司或个人说我要创业做个操作系统来替代Windows，因为这是不可能的事情，如果你拿这个故事去找风险投资，没人会愿意出钱支持的。在我们国家，这个需求是因为一些老专家的个人情结，硬生生给创造出来的。如前所述，国产桌面操作系统对应的市场有，但不大，不值得花这么大的人力财力去开发一个所谓“自主可控”的国产桌面操作系统。
再谈谈方法问题。如果真的想要为政府专门做一个“安全”的操作系统，我们有很多种办法，比如：政府可以组织科研机构开发一个自己的加密文件系统，然后和操作系统供应商谈判，要求他们支持这个加密文件系统；类似地，我们可以将政府的涉密电脑，通过专有的私有网络连接在一起，或者使用私有的加密传输协议等等。
现实情况是，政府并没有采取类似的方法。相反，我们国产的操作系统，也并没有在解决安全方面有多少的研究和建树。比如，iOS 在设计之初，为了提高系统的整体安全性，就让各种应用运行在自己的沙盒里边；试问国内的桌面操作系统，有哪个做了类似的设计？实际情况是，国产操作系统使用的仍旧是 Linux + X Window 这种三十年前的系统架构，而大量的开发力量被安排在了美化界面、硬件兼容性等脏活、累活上。
2）堂吉诃德式专家
现在仍然为国产操作系统奔走呼吁的老专家们，大多在上个世纪80、90年代时达到了人生的顶峰。他们经历了微软从小到大，从 DOS 发展到 Windows，然后一骑绝尘，把其他软件公司一一打倒的整个过程。与此同时，中国的软件公司居然没有一个发展起来的。这未免让这些老专家们耿耿于怀，于是，要有国产的操作系统，就成了他们余生的追求。
市场已经变化，他们看不见。Intel 的战略，从联合微软转向了支持开源的 Linux，从 Wintel 联盟转向了 Lintel 联盟。而他们还将 Wintel 联盟作为他们的假想敌。
国产操作系统厂商的研发水平，他们不愿意深究。大量粗制滥造的国产桌面操作系统，仅仅做了几个设备驱动程序，做了一些本地化工作，抄了几个 Windows 或者 macOS 的界面，就觉得“国产桌面操作系统的发展喜人，达到可以用了的水平”。真实的情况是，几乎所有的国产桌面操作系统，都会在交付到用户手上时，要么被扔到一边应付检查，要么被卸载用盗版 Windows 替代。
类似地，专家们利用自己的话语权奔走呼吁，带来的竞争恶果和人力资源浪费，他们视而不见；技术在发展，操作系统的竞争战场早就变化，他们仍然痴心不改……
这和臆想自己带着千军万马，身披钢盔铁甲，手握坚盾长矛，把风车当成情敌去战斗的堂吉诃德有何区别？
3）刻舟求剑
如前所述，当我们还在苦苦发展国产桌面操作系统的时候，操作系统的主战场已经发生变化。2007年，苹果公司和谷歌公司，先后推出了 iOS 和 Android 系统，全面布局移动操作系统领域，等我们回过神来，发现我们又一次落后。那个时候，我们的老专家和巨婴企业们还在为了国产桌面操作系统那点“市场”在努力。而他们一直视为对手的微软，其战略也早已经从桌面转向了云计算和人工智能。
我很佩服他们二十年来的痴心不改，但在笔者看来，他们的行为无异于刻舟求剑。
4）扭曲的市场和竞争关系
政府非市场的补贴行为，助长了这个圈子的歪风邪气，大量华而不实、粗制滥造的项目存在，其目的就是为了获得政府的补助资金。因为利益分配不均，某些企业之间甚至出现互相撕逼的情形。最终的结果是，钱花出去了，政府也好，整个产业也好，并没有得到想要的东西。
5）FUD
FUD，是Fear、Uncertainty、Doubt 的简写，分别是害怕、不确定和怀疑的意思。他们充分利用了“自主可控不一定安全，但不自主可控一定不安全”这句话，大量散播 FUD，让没有多少实际价值的国产桌面操作系统以高达千元的单台装机许可费卖给了某些部门，这个价格，甚至超过了Windows 10 的零售价！
另外，他们为了忽悠政府，还把桌面操作系统称为“通用操作系统”，好像做出来之后在哪儿都能用一样。看看，稍不留意，就会丢进这个圈子设下的圈套里边。其实，压根就没有什么通用操作系统！
他们还放大桌面操作系统的目标市场，希望所有普通消费者和一般的企事业单位都能使用国产的桌面操作系统。现实是，消费者绝对不会因为政府的一句话而改变自己的选择，而这个圈子所能影响的范围，只有政府或者一些要害部门。他们夸大市场的唯一目的，就是忽悠政府加大投入。
6）几乎无任何核心技术积累
2018年，深度 CTO 王勇的离职事件爆出时，我曾问过深度的工程师：“这八年来，你们发展了什么核心技术？”他们回答：“桌面”。我又问：“桌面是拿什么开发的，内核是 Linux，基础设施是 X Window，框架是 Gtk 或者 Qt，这其中哪个是你们发展的？”对方无语。
可悲的是，笔者之前提到的这前前后后二十多家国产操作系统厂商，没有一家以发展生态为目标，扎扎实实积累自己的核心技术的。他们要么使劲模仿Windows，要么通过 WINE 这样的模拟器兼容 Windows，要么兼容 Android……
甚至连他们自己提出的安全问题，也没有哪个厂商提出来一个好的解决方案。
7）阻碍了中国基础软件产业的发展
2000年之时，Android、iOS 还没出现，Linux 刚刚传播到中国，如果方向正确、方法得当，十年后，我们还可能在某个方面跟美国一较高下。但国家大量的补助被花在不切实际的“通用”操作系统之上，大量人力、物力被浪费在毫无价值的项目之上。于此同时，我们的专家并未给我们指出一条更加正确的道路。
可以这么说，过去的 20 年，是国产基础软件“遗失的”二十年，国产桌面操作系统这个圈子起了很大的反作用。想想就知，我们压根就不应该寄希望于“刻舟求剑的堂吉诃德们”！
那些现在还在忽悠政府要不惜血本发展国产通用操作系统，且要求政府“允许大面积”失败的人，应该被“关进笼子”面壁反省。
新的操作系统仍有机会，但不在桌面上，也不在智能手机上
下面谈谈新操作系统的机会。
新的操作系统，往往在计算机应用到新的市场领域时出现。比如，原来计算机主要用在军队、科研等领域，后来出现了巨大的个人电脑市场，而这个市场让微软通过 MS-DOS 赚到了第一桶金，之后微软顺理成章地开发了Windows 系统并最终成为桌面电脑操作系统的霸主。后来，计算机结合通讯技术应用到了移动通讯领域，出现了面向消费者的智能手机，而这一新的市场催生了 iOS 和Android 操作系统。再比如，互联网的兴盛给 Linux 以发展机遇，使其成为了互联网时代名副其实的服务器端操作系统之王。
历史的规律总结起来大致如此（当然这里省略掉了市场竞争，提到的基本只是最后胜出的操作系统）。从技术上讲，出现这一规律的深层次的原因是，当计算机技术应用到新的市场领域时，计算机系统的交互形态或者计算环境会发生相应的变化以适应这个市场的需求，这会使得操作系统的软件栈发生变化（一般是往上层堆叠），会催生出新的应用编程接口，而应用编程接口则是操作系统赖以构建生态系统的护城河。
所以，新的操作系统要想在竞争中胜出，就必须先他人一步去为新的计算机应用领域做准备。
其实，对这几年计算机技术的发展稍有了解的人都会明白，计算机正在快速应用到各个领域。看看这两年层出不穷的新名词或者新缩写就知道了：AI、VR、大数据、物联网、工业互联网、智能机器人、边缘计算、区块链……
这些技术的出现，将带来人机交互方式的巨大变化：人们将通过更加复杂的方式感知计算机的输出，如语音、全息、裸眼三维等，而计算机可通过更加综合的方式获得来自人类的输入，比如语音、手势、表情、脑电波等。同时，计算机的计算环境也会发生重大变化：除了使用互联网/移动互联网、无线网络、云计算等基础设施之外，还会催生出自组网、标准化的人工智能服务接口等新的网络形态或计算环境。
新的操作系统要面向这些新的应用领域及计算形态进行设计，如果我们恰好有个好的设计被大家看好，被很多开发者采纳，那新的操作系统就可能在市场竞争中胜出。反过来讲，假如在某个市场领域中，没有玩家做操作系统，那只能说明这个市场太小，不值得花功夫做一个操作系统。
物联网就是一个足够大的市场，或许会成为下一个比肩个人电脑或者智能手机的大市场，巨头们已经进入并布局这个市场领域。2015年间，微软、谷歌、华为等大公司纷纷发布了自己的物联网操作系统，显然是看到了上面所说的趋势并积极布局以抢占先机。
然而，三年过去了，华为的 liteOS 也好，谷歌的Android Things/Brillio 也好，微软的 homeOS也罢，都未有大的发展。这未免会让大家产生怀疑：物联网市场是否还不成熟？物联网市场是否会真的有那么大？
笔者看来，造成这种情况的原因有一部分原因是因为物联网的碎片化：物联网的产品庞杂，应用范围太广，几乎无法标准化描述。比如，有的物联网设备只有一个蓝牙芯片，而有的配有WiFi、NBIoT 甚至 4G；有的物联网设备强调低成本，内存有限，只能运行简单的 RTOS，而有的带有可触摸显示屏，运行的是复杂的 Linux 系统。如此等等，这给开发其上的操作系统带来了难度。
除此之外，笔者认为还有一个原因，就是这些巨头的布局仍然没有抓住本质。面对物联网应用，我们不能按照以前针对个人电脑、智能手机那样去设计操作系统，而需要从更高的层面去提炼物联网应用领域中的需求，要面对这些需求重新设计操作系统。
注：摘自魏永明博客，原文地址XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXt/zh/blog/weiyongming ，有删节。