0 引言
前两天，前工信部部长苗圩在全球新能源与智能汽车供应链创新大会上提到，疫情以来，“缺芯”对汽车供应链的严重冲击已经让车企深刻意识到该问题的严重性，但相比“缺芯”，“少魂”的问题更易被忽视。苗圩指出，操作系统是比芯片更加迫切和致命的问题，是决定汽车智能化、网联化胜负的关键。他表示，“现在全球智能汽车发展格局没有定，留给我们的时间窗口大概是三年，最多是五年时间，我们要增强紧迫感，通过三年的努力打造一个自主可控的、开源开放的，最好是免费的操作系统，形成在中国市场上的产业发展生态。”
苗圩前部长还提到，操作系统领域是赢家通吃的领域，只有第一、第二，没有第三、第四。也就是说，苗圩前部长希望我们通过三年的努力打造出的车载操作系统，能够在全世界舞台上取得第一、第二的市场位置。
解读苗圩前部长的这番话，说明高层将操作系统的重要性提到了和芯片一样重要的位置。对此，我们操作系统领域的从业者倍感欣慰，倍受受鼓舞。
但是，因为我们花了二十年时间，前仆后继，尝试打造自主可控的通用桌面操作系统，却并没有达到世界领先、遍地开花的预期目标，而仅仅在非常狭窄的特定市场领域中达到了“能用”的程度。鉴于此，很多人对我们能否在三到五年内打造一款自主可控且全球领先的操作系统，或者目标降低一点，自主可控且全球领先的车载操作系统，是抱有怀疑态度的。
这不难理解，毕竟说实话，在操作系统这个领域，不管是桌面操作系统还是嵌入式、服务器、云计算或者物联网操作系统，我们从没有实现过类似的目标。
这个目标的确很难，就自主可控这个子目标，我们还可以编个瞎话糊弄糊弄，但全球领先，不是第一就是第二，只能用市场份额来说话，是做不了假的。
但万事没有绝对，我们也不是一点点成功的可能性也没有。我写这篇文章的目的，便是要论证一下，我们如何做才能达到这一目标。
1 桌面系统的前车之鉴
有关 Linux 桌面系统不得劲的问题，我曾在《Linux 桌面为啥不得劲》以及《没有自主的编程语言便没有自主的操作系统——HVML 背后的思考》两篇文章中做过分析，感兴趣的读者可以点击阅读。这里简单总结一下我的观点，并补充一些新的观点：
第一，不论是国外还是国内，Linux 桌面系统都没有发展好，其深层次的原因非常清晰：产品上模仿，技术上跟随。要么模仿 Windows、macOS 的人机交互界面，要么复制其上的应用软件，甚至做兼容层来兼容 Windows 或者 Android 的应用。这导致 Linux 桌面系统无法打造自己的差异化竞争优势，也无法发展出自己的技术特色和产品特色。
第二，为了满足特定的需求，Linux 桌面操作系统厂商不愿意做长期的研发投入，从不在编程语言、开发工具、大型应用软件等方面投入，总希望利用已有的开源软件以及上游社区走捷径。但事实表明，除了由微软、谷歌、苹果等大型科技企业主导开发的应用软件，如 VSCode、Chroumium、WebKit 之外，由基金会主持的大型应用软件，都存在大量问题，作为产品只能说将将达到及格的水平。典型的如 GNOME、LibreOffice、GIMP 等。
如果更进一步深挖其中的缘由，这和许多早期的重量级开源项目，最初的出发点是为了替代同类商业软件有关。比如 GNU 项目之于 Unix 系统，LibreOffice 之于 Microsoft Office，GIMP 之于 PhotoShop 等等。东施效颦，这导致后来很多开源开发者以重写商业软件为乐，比如全世界多达上千种的各种开源实时操作系统内核就是这么产生的，还有层出不穷，彼此间看不出多大差异的各类 Linux 发行版也是在这种思路下产生的。这当然造就了开源世界的繁荣，但也隐藏着一个重要的问题：开源开发者更看重实现而非设计，大量的开源作品缺乏技术上的创新，更不用说产品上的创新了。
另一个缘由，和开源开发者过度推崇黑客精神有关。举个例子，针对软件包依赖性问题以及兼容性问题，近几年就发展出了一些基于容器技术的应用打包及分发机制，比如 flatpak，其基本思路便是将应用软件所需要的所有依赖函数库全部打包到一起，而不依赖于操作系统本身提供的那些函数库，从而解决软件的依赖性问题。但采用这种技术带来另外一个问题：软件包动不动就上 GB 规模，这显然带来了巨大的分发成本。于是，这些新技术在解决旧问题的同时制造了新问题。
因此，就算 Linux 桌面系统在技术上在不停进步，比如底层窗口系统从 X Window 发展到 Wayland，GNONE 从 2.0 发展到 4.0 等等，但和普通用户之间的距离并没有发生实质性的改变。在炫技、模仿、重实现而非设计的黑客精神主导之下，Linux 桌面系统始终未能改变高高在上的姿态，在没有赢得普通用户喜爱的同时，还让大量的普通开发者望而却步。
这就是 Linux 桌面系统二十年来不得劲的主要原因，而国产的自主桌面系统，本质上就是 Linux 桌面系统，更难摆脱上面所说的这些问题。
业界知名专家小神仙，今天在朋友圈发了一篇长文，分析“通用Linux桌面在全球范围内无成功先例”的原因，提到有三个派别：
第一是自主派。他们认为必须打造围绕国产操作系统的生态，所以坚定地走应用兼容适配的问题。对此，小神仙质疑道：回头再来看国产化替代的底层逻辑，假设我们全面完成了国产化替代，结果是：从原来的 Wintel 架构全面过渡到“三到四种处理器架构 + 至少两个品牌的操作系统及每个操作系统的多个版本。在没有统一标准的应用开发工具、应用框架标准情况下，这种情况带来的碎片化问题，如何解决？
第二是合作派。他们认为客户端用 Windows，加上服务器或云端的 Linux 是最佳实践，并为之付出努力。对此，小神仙点评道：尽管这是目前市场的主流模式，但显然无法得到政策层面的全面认可。
第三是未来派。他们认为上面这两种模式都是陈旧的，要做自主操作系统，必须实现跨代发展。数据是核心，是最重要的生产资料；用新基建的思路，将数据中心、SaaS 服务、客户端无关的网络化以及 Web 化应用生态整合在一起，才可能制胜未来。把数据集中以实现更安全、更高效的处理模式，通过 Web 前端技术实现应用开发的标准和生态的统一，把问题缩小到浏览器，这样，客户端用什么操作系统就不再重要了。对此，小神仙质疑道：听起来似乎很美好，但真要实现这一点，代价似乎很大，时间似乎很长，所以，中间必然要有足够长的过渡态。
小神仙是我们这个行业少有的具有深度思考能力的人。显然，他看到了问题所在。就这个话题，他感慨道：桌面的问题，困扰了我们这个圈子的好几代技术人，百思不得其解。路漫漫其修远，我们还有那么多时间吗？总感觉到了瓶颈了，通用架构很长时间没有任何创新发展，大家能做的都是模式创新，似乎要换代了，又不知道下一个代在哪。没有新的计算架构或交互模式的驱动，这个代怎么换呢？桌面端有不少中间件（应用框架），但没有一个中间件（应用框架）成为主流，能够为开发者贡献价值，让开发者有所获得个人甚至有时候会怀疑：这个问题到底是不是一个技术问题？能不能找到技术解？
对此，我评论道：自顶向下，从编程语言入手，或许是条道路。
小神仙回道：似乎是最艰难的模式，大家不敢走也不想走。但私以为这是最核心的东西，无法回避，早晚要解决。这个问题不解决，话语权和主动权就永远在别人手里。
我回复道：人间正道是沧桑啊！到了今天，这条道不走已经不行了。
2 凡是走捷径的，最后都会失败
小神仙还提到用移动终端系统来解决“桌面替代”是不是可以成为一个选项。他说，华为在几年前为了支持电视等大屏投屏，在“安卓”上增加了 PC 模式，增加了多窗口、任务栏等安卓本来没有的元素，以适应大屏体验。在做平板的时候增加了同一 App 的多窗口支持等等。小神仙说，如果将使用开源的免费的安卓作为我们桌面系统的底座，理论上我们就可以获得广大的用户基础，优秀的应用生态，统一的应用框架以及开发工具，等等。
但是，将开源免费的安卓嫁接到桌面系统或者其他已有的操作系统上，这件事情十年前就有人做了。我们总以为在一个系统上提供了安卓的兼容能力，就可以将全世界近千万的 App 跑在这个系统上，从而就可以借助别人的生态构建我自己的生态，然后呢，我们就可以弯道超车了。但事实证明，这条道走不通。因为，安卓的生态不在我们的把控下——谷歌研发新版本的安卓的时候，会问你要保留哪个接口，增加哪个接口吗？你做的增强，安卓会收纳吗？安卓开发者会跟随谷歌的步伐还是你的步伐？
我观点很鲜明：不管什么派，凡是走捷径的，最后都会失败。不做基础性、原创性研发工作，总想着整合开源软件，或者提供个兼容层来兼容 Windows 应用或者 Android 应用，这些做法都是懒惰的、走捷径的做法。
很简单的道理：一个系统兼容安卓，你要么是在给安卓的生态添砖加瓦，要么还得不到谷歌的认同，你的努力终将白费。再说了，你把安卓嫁接到你的操作系统上，那这个市场份额是安卓的还是你的呢？
再强调一遍：所有想弯道超车的走捷径的，最后都会失败。只有踏踏实实做产品，做创新性的基础研发工作，才有成功的可能。
3 确定一个可量化的目标
我们再回到正题，谈谈三年发展出全球领先的自主操作系统的可行性。
先确定目标。
首先，这个目标必须是可量化的，自主可控显然就不是一个可量化的目标。作为一个基础软件产品，领导们确定目标的时候，必须强调可量化的目标：全球第一或者第二的市场占有率。这个目标达到了，自然就是自主可控的，一定就有自己的生态——这些子目标还用说吗？
也就是说，千万不能把“自主可控”确定为我们发展自主操作系统的目标。君不见，用了那么多的开源软件，内核不是我们的，基础库不是我们的，开发工具不是我们的，编程语言不是我们的，应用框架不是我们的，仍然被我们粉饰为“自主可控”的操作系统吗？
如果没有市占率这个唯一的量化目标，大家就会变着法走捷径，就会重蹈桌面系统的覆辙。因此，三年后，全球市场份额达到 20% 以上，五年后达到 35% 以上，是领导制定各项政策的唯一衡量标准。
4 纲举目张，找到那个纲
不管是桌面操作系统还是车载操作系统，千头万绪，怎么做是个问题，从哪里入手更是问题的关键。
在《没有自主的编程语言便没有自主的操作系统——HVML 背后的思考》一文中，我提到两个主要观点：
第一，操作系统的首要用户是开发者。只要把开发者伺候好了，让开发者可以用更低的投入、更高的开发效率赚到更多的钱，才可能获得更多开发者，也可能让我们的操作系统占领更多的市场份额。
第二，编程语言以及围绕这个编程语言的应用框架，是一个操作系统的灵魂和基因（具体论述，可参阅我在 2018 年发表的《三谈操作系统》一文）。为了伺候好开发者，我们就必须开发更好的编程语言、应用框架和开发工具。
重视开发者，优先为开发者服务，是所有基础软件的生存之道。其道理不言而喻：一款基础软件，不论是操作系统还是数据库，要获得大规模的应用，就离不开开发者，而基础软件的开发者本身，纵有七十二变，也不可能把全世界的应用需求都给满足了。
如果我们简单回顾一下成功操作系统的发展，就可以得出这些操作系统一开始就不遗余力地为服务开发者而努力。比如微软，从 Windows 3.0 开始，就为降低 Windows 上的应用开发门槛在努力，比如 Visual C++、Visual Basic 以及后来的 Visual Studio，再后来，有了 C# 编程语言和 .Net 应用框架。苹果和谷歌围绕各自操作系统所走的道路也类似。发展到今天，我们可以看到几乎所有成功的操作系统都有自己专属的一种编程语言以及围绕这个编程语言打造的独特的应用框架。
而如果你对市场上流行的编程语言以及开发工具有所了解的话，就很容易明白我们的现状：在编程语言、应用框架和开发工具方面，我们几乎没有任何拿得出手的建树。说到这里，你大概也能明白，为什么我们国家开发不出来世界一流的操作系统的根本原因。
纲举目张，编程语言便是发展世界一流操作系统的那个纲！
5 举国体制能否缩短研发周期？
在前天召开的中央深化改革委员会第二十七次会议上，审议通过了《关于健全社会主义市场经济条件下关键核心技术攻关新型举国体制的意见》。最高领导人强调，要发挥我国社会主义制度能够集中力量办大事的显著优势，强化党和国家对重大科技创新的领导，充分发挥市场机制作用，围绕国家战略需求，优化配置创新资源，强化国家战略科技力量，大幅提升科技攻关体系化能力，在若干重要领域形成竞争优势、赢得战略主动。
我认为在这样的政策春风指引下，举国体制打造一个世界一流的操作系统，是有可能的。
对此，我朋友叶总的观点很有代表性：要长期迭代，就需要足够的预算和决心，做到这点倒不难，举国体制下可以完成。但每一个参与建设的软件工程师的品质和品味能否到相当的水准，我怀疑。那么由一群非顶级品质和品位建筑工人造的楼，不可能是第一或第二的。如苗部长所言，人类只需要第一、第二的操作系统，排第三的，就是慢慢地走向没落，举国体制也不能举国填一个无底洞。
叶总的评论提到了我们的一个重要短板：人才。前面谈到，在编程语言、应用框架和开发工具方面，我们几乎没有任何建树，相应地，能够参与到相关研发工作当中的人才也是屈指可数的。因此，如果举国体制能够解决人才问题，我认为这个事情就成功了一半。
因此，如何在社会主义市场经济条件下，利用新型举国体制解决人才问题，是我们能否达成这个目标的政策关键。这里有几个约束条件：
第一，操作系统的研发本质上是一个大型软件工程，必须要有成建制的团队，架构师、产品经理、研发经理等核心人员要保持稳定，管理方面要学习国外的先进经验。
第二，利用好开源协作模式，但要避免采用类似国外基金会的低效管理机制和决策机制，要市场化聘用人员和管理人员。
以上，供有为者参考。
6 了解下我们围绕自主编程语言所做的工作
HVML 是 Hybrid Virtual Markup Language 的缩写，是由笔者提出并设计的一款通用、易学的编程语言。从第一次提出到发布 HVML 1.0，在两年的时间，我们实现了从 0 到 1 的突破：
-
2020 年 5 月，笔者有了设计一款与众不同的编程语言的想法，后于 2020 年 7 月提出了 HVML 编程语言并公开了第一份规范草案。
-
2021 年 7 月，我们成立了一个攻坚团队并正式开始了 HVML 解释器（PurC）的开发。
-
2021 年 12 月 27 日，第一个 HVML 程序成功运行，标志着 HVML 的正式诞生。
-
2022 年 3 月 11 日，HVML 解释器完成和渲染器的对接，标志着 HVML 解释器和渲染器通讯协议 PURCMC 的诞生。
-
2022 年 5 月 30 日，我们完成了 HVML 图形渲染器 xGUI Pro 的初步版本。
-
2022 年 7 月 31 日，HVML 1.0 解释器 PurC、渲染器 xGUI Pro 趋于稳定，我们公开了 HVML 相关的所有源代码仓库（或软件包）。
-
HVML 使用标记来定义程序的结构和控制流，这大大提高了程序的可读性，同时大幅降低了学习难度。
-
HVML 使用具有动态功能的扩展 JSON 来定义数据，隐藏了底层系统，而且使其成为粘合不同系统组件的理想胶水。
-
HVML 引入了数据驱动的编程模型，这让开发人员更多地地关注数据的生成和处理，而不是程序的控制流。
-
HVML 是动态的；开发人员不仅可以从远程数据源获取数据、模板和程序片段，还可以删除已有的变量。
-
HVML 使用独有的方式来支持协程、线程、闭包等等这些现代编程语言必备的特性。
-
HVML 非常灵活；开发人员可以使用 HVML 编写简单的脚本工具，也可以使用它来开发复杂的 GUI 应用程序，甚至可以用 HVML 开发服务器软件。
-
HVML 的运行飞快；HVML 解释器使用简单高效的栈式虚拟机，不使用任何垃圾收集器。
-
HVML 通过预定义变量重新定义了系统底层的模块和接口，从而屏蔽了不同操作系统或软件平台之间的差异。
-
相比常见的脚本语言，HVML 具有更高的抽象级别；使用 HVML，开发者可以用更少的代码完成更多的工作。
欢迎访问 HVML 解释器 PurC 的仓库。