近日,我提出的物联网操作系统 HybridOS 终于走出了第一步:HybridOS 代码仓库已在 GitHub 上创建,官网(http://hybrid.)也已上线。目前,我将我的思路整理为若干文档放到了代码仓库中。 HybridOS 的仓库地址如下: https://github.com/VincentWei/hybridos/ 欢迎各位造访。虽然其中还没有什么代码,但还是可以清晰地看出 HybridOS 的一些设计思路。 本文向大家介绍 HybridOS 一些关键特性的需求来源和创新之处,也就是 HybridOS 为什么要这样设计,和其他操作系统的本质区别是什么。 HybridOS 的官方定义HybridOS 一句话定义:
用中文表述为:
HybridOS 的长定义:
用中文表述为:
HybridOS 的关键特性HybridOS 是我在《三谈操作系统:操作系统方法论》一文中提出的操作系统开发方法论的实践。该方法论的要点如下:
另外,任何新产品的设计都要解决一两个痛点问题(也就是需求)。在《五谈操作系统:为物联网设计》一文中,我指出了物联网开发目前最大的问题:开发者要面临复杂的软件栈和协议栈。这导致一系列问题,如团队的配置高,产品的开发周期长,开发成本高等等。因此,我认为任何一个面向物联网的操作系统,必须首先通过缩短软件的开发周期来解决软件的开发成本问题。 因此,围绕上述方法论要点以及我们要解决的需求痛点,HybridOS 的设计强调了下述的三个关键特性。 为 IoT 应用特制的软件栈在《五谈操作系统:为物联网设计》一文中,我提出了一个观点:IoT 设备在很大程度上更像一台传统的服务器。比如很多情况下,我们会通过标准的HTTP 协议来访问设备中的文件或者操控设备。但目前流行的 HTTP 服务器,比如 Apache、Nginx 等,都是为云端的HTTP 服务设计的,主要考虑的是大并发情况下的性能。在IoT 设备中,提供 HTTP 服务的软件则通常不需要考虑大并发的问题,但必须考虑资源受限以及安全性问题。因此,这类软件在设计上就必须有和传统的服务器软件有不同之处。要把握IoT 设备中的 HTTP 服务器软件的设计关键,就需要深刻理解其关键需求: 首先,在 IoT 设备中运行 Apache 这样大型的 HTTP 服务器软件是不切实际的。 其次,让开发者从头设计和开发一个哪怕很简单的 HTTP 服务器也是不切实际的。 最后,即使我们使用一些开源的小型 HTTP 服务器(如 libhttpd)实现,为其开发后端的具体请求响应代码也是令人头疼的。 因此,在 HybridOS 的设计中,我们提出了一个新的服务器软件设计思路,即将特定协议的处理和请求的响应隔离开来。HybridOS 的 HTTP 服务器,处理 HTTP 协议的实现细节,扮演请求分发者的角色,根据某个特定的规则,将给定的请求通过某个进程间通讯机制分发给某个事先准备好的应用或者服务,而应用和服务,则处理请求并返回响应数据。当然,Apache 等的服务器软件也差不多是这么干的,但 HybridOS 的实现会更进一步。 这样,IoT 应用的开发者不需要了解HTTP 服务器的具体实现和协议细节,只需要按照接口规范开发自己的请求响应代码即可。类似地,我们可以实现 WebSocket 服务器、CoAP 服务器。甚至我们还可以将应用的请求和响应接口做进一步抽象,不管这些请求是通过HTTP、CoAP、WebSocket 还是 MQTT 来的,应用都可以使用同一个接口来应对。这将大大降低应用的开发难度。 兼顾设备和客户端 App 开发的全新应用框架我在《五谈操作系统:为物联网设计》一文中指出,IoT 应用的开发者不可避免地要开发一些运行在智能手机、平板电脑甚至桌面电脑上的App。由于不同客户端上的操作系统和编程语言及接口不同,所以目前这些客户端应用的开发成本居高不下。因此,在 HybridOS 的设计中,我们提出了一个全新的应用开发框架。这个框架的特点如下:
实质上,HVML 也一样可以用于其他场景,比如开发针对跨桌面操作系统的应用。目前,我们要开发一款可以运行在 Windows 和 macOS 上的应用,要么使用类似 Qt 这样的跨平台 C++ 库,要么使用 Electron 这样的 Node.js + Chromimun 的解决方案。前者对开发者的要求高,而后者的体积大、性能差。 因此,从上面这个应用场景看, HVML 也许可以成为国产自主可控桌面操作系统的一个重要技术突破口。 专用于 IoT 的云计算服务以及安全性实现IoT 应用天生要和云计算打交道。但目前在智能手机上常见的云计算服务,却无法从云计算市场上直接获得,比如固件升级、App 升级、设备验证、客户端身份验证等等。 这些我们在智能手机上常见的云服务,是相关厂商多年积累的结果,但对IoT 应用开发者来讲,如果要从头搭建这些服务,将成为一场噩梦。因此,HybridOS 将通过开放的接口来实现这些基础的功能,提供给 HybridOS 开发者使用。当然,这也有助于创建 HybridOS 的商业模式。 另外,HybridOS 还将提出一个全新的物联网应用安全性框架。关于 HybridOS 安全性设计的介绍,我们将在后面的文章中专门讲述。 常见问题和解答为什么不弄个初步的版本再发布? 章文嵩博士曾说过:真正的开源应该是过程开源。我很欣赏这句话。比如国内很多大公司搞的开源项目,都是自己业务中比较边边角角的某个东西,偶尔拿出来开源一下,但往往开源之后就没了下文。HybridOS 要改变这个做法,从一开始就开源发展,为的就是让大家可以知道一个开源项目是如何一步步走向成熟的。当然,也可能半途而废。 为什么文档要用英文编写? 没办法,英文仍然是全世界计算机科学和工程领域的第一语言。用英文编写文档,将来翻译成中文也相对简单。而如果用中文写,将来翻译成英文会成为一个很大的问题。 因此,参与 HybridOS 的开发者,需要有比较好的英文写作能力。但这是可以练出来的。写多了就成套路了。即使不那么地道,但别人能看懂就好了。 HybridOS 未来会采取什么样的商业模式? 现在谈这个还为时尚早,等我们达到第一阶段的设计目标,再来讨论这个问题不迟。但大概率会采用类似 MiniGUI 的双许可证商业模式。所以,我们将使用 GPL/AGPL 等较为严厉的许可证发布代码。这可以为将来基于 HybridOS 建立合理的商业模式打下基础。 大概何时能够看到 HybridOS 的第一个版本? 大约在冬季,明年。其实,上面提及的很多思路,在飞漫软件过去开发 MiniGUI、mDophin 以及智能硬件等产品的过程中已有一些积累。所以,我们会在上面提到的仓库中陆续发布一些 HybridOS 组件的源代码。 个人如何参与 HybridOS 的开发? 任何人都可以参与到 HybridOS 的开发中。简单到修正一个拼写错误,复杂到承担某个模块的开发任务。简单的参与,大家可以通过 GitHub 提 pull request,而一些重要的开发任务,飞漫会和开发者签订合同并按约支付开发费用。有兴趣的开发者可以看看我们的架构设计,如果恰好有自己擅长且感兴趣的开发任务,可通过 GitHub 上公开的邮箱地址(github@)和我们联系。 企业如何参与 HybridOS 的开发? 我们欢迎企业参与HybridOS 的开发,参与方式可以有:
有兴趣参与 HybridOS 开发的企业,请致信 github@,我们会及时回复,商讨可能的合作形式和机会。对基础软件商业模式感兴趣的话,可阅读《六谈操作系统:构建商业模式》。 为什么不成立 HybridOS 的基金会? 一方面,我不熟悉基金会的运作机制,国内也没有啥成功先例可以参考,而目前也没有精力去搞基金会。如果有人或者有企业想赞助 HybridOS 的开发,可以直接把钱付给飞漫软件(点击文末的原文链接)。对此类赞助资金,飞漫软件会全部支付给参与 HybridOS 研发的非飞漫软件全职员工。从财务上讲,和基金会比起来,此种形式的赞助也就是多了点增值税吧。 当然,目前正在使用 MiniGUI 的客户,积极支付 MiniGUI 的商业使用许可费给飞漫软件,也有助于 HybridOS 的发展。 |
|
来自: kaller_cui > 《操作系统》