无忧启动论坛

标题: 收集微内核操作系统的资料 [打印本页]

作者: 不点    时间: 2019-11-29 10:41
标题: 收集微内核操作系统的资料
2019 年很热闹。首先,外部世界很热闹,华为宣称自研微内核的操作系统——鸿蒙,并“开源”。我个人的内心也很热闹,即,碰巧对 Linux 内核产生了不信任(此处谈及“不信任”,应该朝着“严重”的方向去理解)。但不幸的是,这两个热闹是两张皮,扯不到一块来。说明白点:Linux 不值得信任,鸿蒙亦然,即,鸿蒙并不能填补由 Linux 的失信所造成的信任真空。此处不谈 Linux 为何不值得信任,若要了解我的想法,请在我的其他帖子中搜索来龙去脉。

好了,对鸿蒙的不信任,是源于对鸿蒙的预判。虽然鸿蒙宣称“开源”,但经过仔细分析,我发现这个“开源”是“靠不住”的。说明白点,鸿蒙对公众开源的可能性很低(您理解为“不可能”也行,因为世上没有绝对的不可能,都是相对的,所以,“不可能”也就粗略地等同于“可能性很低”)。像谷歌安卓那样的“半开源”,我都不认可它的“开源”属性,更何况其他一些所谓“开源”模式甚至都只能给“合作伙伴”共享,普通人根本就不能获得源代码。在我看来,“让读不让改”都不算“开源”,更何况连“读”都不给,这要是能算是“开源”的话,那也太侮辱“开源”这个概念了吧?至于说我为何“预判”鸿蒙的开源“靠不住”,我也不想解释。预判是我作出的,我解释给别人,也不一定能说服谁。有兴趣者,可以研究我最近的一些帖子。再者,那些“贸易战”以及“谁打压谁”,似乎与我的关系比较遥远,就顾不上了,不予涉及。

言归正传。本帖所说的“开源”,是指对公众开源,公众可以免费获得源代码,并且也能够自由地、不受约束地修改源代码。此处“不受约束”,是指在遵守“对修改后的源码进行开源”的前提下,不受其他约束(比如还得给某公司上税,或者还得经某公司同意,等等,五花八门)。其他那些五花八门的开源,都是“受限”开源(有时也说成“假开源”)。“受限开源”的实际例子有很多,此处不列举。不同的开源协议,保护的是不同人群的利益。“受限”开源,虽然广义上也算是开源,但在接下来的讨论中不把它当作“开源”来对待——不管它算不算开源,它没保护我的利益,我对它不感兴趣。

好的,Linux 失信,鸿蒙无信。生活还得继续。所以,要寻找其他操作系统了。

从哪一类 OS 开始找起呢?就从“微内核”的 OS 入手吧。

以上是“开宗明义”,作为“开场白”。

作者: 不点    时间: 2019-11-29 11:19
先看看 minix3:

http://www.minix3.org/

优点是比较成熟,与 NetBSD 的应用程序兼容。


缺点是 CPU 目前只支持 x86 和 ARM,而且都是 32 位的,不支持 64 位。开发也近乎停止了。

作者: 2013olly    时间: 2019-11-29 11:36
是否可以简单理解为,“开源”指gpl,或者gpl兼容的其他协议(如lgpl,bsd,apache等)的开源?
作者: 不点    时间: 2019-11-29 12:02
2013olly 发表于 2019-11-29 11:36
是否可以简单理解为,“开源”指gpl,或者gpl兼容的其他协议(如lgpl,bsd,apache等)的开源?

olly 大人您好。个人浅见,任何概念,都不能精确定义。人类所理解的概念,都是模糊的。用“稀里糊涂”的概念去解释另一个“稀里糊涂”的概念,这大概就叫做定义。

所以,概念的理解会不同。比如说,有广义和狭义之分。广义上能叫做“开源”的,狭义上就不一定能叫做“开源”了。而什么是“广义”、什么是“狭义”,这又是模糊的,不同的人有不同的理解。

总之,模糊的定义是可以的。精确、严密的定义是没有的。甚至就连“精确”、“严密”的概念本身,都是模糊的、不严密的,以及没法定义的。“说”者是“稀里糊涂”地“说”,“听”者是“稀里糊涂”地“听”。论坛上的争论、交流,都是如此。

作者: addaadda    时间: 2019-11-29 12:51
卡巴斯基有一个防火墙设备用的定制os,看规格比较强
作者: hkkitlee    时间: 2019-11-29 12:59
為何不点大師對linux內核不信任呢?

那大師的x86是用什麼操作系統?
我是用linux的。
Bsd / Linux / Windows / MacOS「黑蘋果」 還有什麼選擇?
作者: 2013olly    时间: 2019-11-29 13:10
不点 发表于 2019-11-29 12:02
olly 大人您好。个人浅见,任何概念,都不能精确定义。人类所理解的概念,都是模糊的。用“稀里糊涂”的 ...

额,我不是什么大人的,我现在连开发都基本没做过,只能仰望开源软件的开发人员的说...
作者: liujun2000    时间: 2019-11-29 13:27
只能支持 确实没有这个方面的研究 纯支持
作者: ster1357A    时间: 2019-11-29 15:57
楼主是想自己开发微内核系统
作者: 不点    时间: 2019-11-29 17:35
ster1357A 发表于 2019-11-29 15:57
楼主是想自己开发微内核系统

谢谢朋友来捧场。不瞒您说,咱也是个外行,没能力开发内核,其实连看懂都难。只不过想看看别人开发的操作系统,看看热闹罢了。至于说开发,就让那些年轻、有朝气、有能力的人去开发吧。
作者: 不点    时间: 2019-11-29 17:49
hkkitlee 发表于 2019-11-29 12:59
為何不点大師對linux內核不信任呢?

那大師的x86是用什麼操作系統?

感谢您的抬举;感谢您关注话题。

简单说,我发现 Linux 的宏内核里面,塞入了很多可疑代码。对 Linux 的维护者产生了不信任。抱歉,这里不深入谈论这个问题,如果实在感兴趣,您可以找以往的帖子。

另一个问题很容易回答。虽然不信任 Linux,但目前没有替代品,没有太多的选择余地,只好继续使用 Linux。这个问题与 Windows 的情况也可以进行类比:虽然不信任 Windows,但目前没有过多的替代品可以选择,于是有时候不得不继续使用 Windows。

作者: gnuxwy    时间: 2019-11-29 21:14
呃,尛内核么。。。

除了minix,还有一个开发了三十年,号称软件工程的最佳反例---GNU的 hurd 啊 !

hurd现在的版本氏0.9了,也不知再过十年,能否发布能用于生产系统的可靠1.0版本的hurd尛内核。。。

其实物联网时代,会给不少新系统内核机会的。
因为既不同于服务噐与PC领域,也不同于手板系统,物联网氏个新领域,也没多少终端用户依赖性。

同样,不只氏软件,硬件领域也能在物联网时代搞搞百花齐放,百家争鸣。。。


作者: wintoflash    时间: 2019-11-29 21:30
本帖最后由 wintoflash 于 2019-11-29 21:35 编辑

https://github.com/HelenOS/helenos我第一次见到这玩意是在7,8年前,没想到现在还活着,还支持x86_64和IA64了。。。

作者: 不点    时间: 2019-11-29 21:52
好的,再来看看 GNU Hurd:

https://www.gnu.org/software/hurd/

维基百科上说,它支持 IA32 和 i686,也就等于说,不支持 64 位。当然,也不支持 ARM 等其它架构。最新的发布是 2016 年,也处于停顿状态,缺乏吸引力。

另一个叫做 Debian/GNU Hurd 的发行版:

https://www.debian.org/ports/hurd/

同样也只支持 i686,不支持 64 位。像这样的情况,感觉是缺少人手,缺乏活力。



作者: gnuxwy    时间: 2019-11-29 22:50
应是最佳范例吧。

确实氏‘反例’,而不氏范例!
因为hurd开发了三十年,仍然不够成熟,至今不敢用于生产环境,所以至今版本号只氏0.9而已。。。

主要原因氏 RMS 的内核设计要求目标太高,实现太困难。所以三十年的开发期间多次变动,重新开发。

hurd的开发当然缺人,但不氏缺普通程序员,而氏缺超一流水准的开源程序员。
除非接下来十年内,hurd内核开发领域出现几个超级软件天才,才有可能将hurd搞成功。。。

支持32位和64位不氏关键问题,如果某个尛内核设计得非常好,原则上氏很容易移植到64位,甚至128位的cpu上面去运行的。。。

问题在于,优异的性能,良好的架构,平台移植性、维护性、扩展性,等等各方面,要解决的问题太多。
如果 minux 和 hurd 或 其他内核如果解决不了这些问题,那么在广阔的物联网领域仍然没戏。。。






作者: gnuxwy    时间: 2019-11-29 23:00
win2flash老大提的那个helenOS也氏一个尛内核,看它的github页面,有它的特别之处吧。。。
也不知道它能否在物联网领域找到自己的生存空间。。。

作者: wintoflash    时间: 2019-11-30 14:20
cckp 发表于 2019-11-30 13:35
http://kolibrios.org
19 nov 2019

kolibrios是宏内核的吧
作者: 不点    时间: 2019-12-1 00:23
HelenOS 支持的 CPU 较多:x86 的 32 位 和 64 位都支持。ARM 和 PowerPC 只支持 32 位。还支持 MIPS、SPARC。好像有人能让 HelenOS 支持 RISC-V,但官方还未支持 RISC-V。

HelenOS 不是 Unix 类的操作系统。因此,应用软件生态的建立,可能是个问题。

作者: 不点    时间: 2019-12-1 00:54
Google 的 Fuchsia 支持 ARM64 和 x86-64。与 Unix 的兼容性是未知的。所支持的 CPU 不多,尤其是不支持 RISC-V。
作者: 不点    时间: 2019-12-1 02:27
RT-Thread:“小而美” 的国产物联网操作系统
http://baijiahao.baidu.com/s?id=1651527495908474571&wfr=spider&for=pc
动点科技 2019-11-29 上海创言信息科技有限公司

随着物联网产业的迅猛发展,物联网设备的种类和数量也随之增长。据前瞻产业研究院发布的《2018-2023 年中国物联网行业报告》初估算,2017 年全球物联网设备数量达到 84 亿,2020 年将达到 204 亿。


物联网设备分布在各个不同的领域,功能各不相同,这对操作系统提出了巨大的挑战。而国产物联网操作系统 RT-Thread 依靠其 “小而美” 的特性贴合了当前物联网的需求。


据悉,RT-Thread 是由睿赛德科技开发的物联网操作系统。2006 年,RT-Thread 以开源的形式在社区发布,经过十几年的发展,在 AI、无线连接、工业车载、安防、电力能源、智能穿戴等各个热点领域都有应用,是国内以开源、中立、社区化发展起来的一款实时操作系统。其高可靠性、超低功耗、高可伸缩性和中间组件丰富易用等特性满足了物联网市场的需求,目前装机量超 2 亿台,被广泛应用于智能家居及安防、工业、穿戴、智慧城市等行业领域。


相比其他操作系统,RT-Thread 的主打特性是 “小而美”。对此,RT-Thread 创始人熊谱翔解释说,RT-Thread 的体积小,最小资源占用 1.2KB RAM 和 2.5KB flash,另外,它的 “小” 还体现在易裁减的特性,可以做到当客户需要一个适用的操作系统的时候,轻松地进行裁减,适应到需要的场景,不占用过多的资源。


而 “美” 则是指 RT-Thread 优化了使用和开发体验,增加了小程序、SMP 多核调度、PSA 安全支持等多项实用的新功能,使得 RT-Thread 系统能实现灵活极简的应用开发,能扩展至众多高性能、高安全的应用领域。


目前涉足物联网领域的大科技公司,比如华为的 LiteOS、三星的 Node.js、阿里的 AliOS Things、谷歌的 Android Things,依赖各自企业的服务和硬件,大多作为维护自身行业地位的工具。


随着开源模式被广泛接受,基于开源开发模式开放的技术更能赢得开发者的青睐。
因此,熊谱翔非常强调围绕 RT-Thread 建构的生态。熊谱翔表示,“在政治经济环境复杂多变的背景下,国产操作系统受到了更大的关注,而 RT-Thread 始终坚持社区化和中立的定位。”


RT-Thread 在 2006 年进行了社区开源,目前 RT-Thread 的开发者数量将近十万人。熊谱翔认为:“操作系统最重要的是生态,RT-Thread 非常注重社区生态建设,我们关注开发者,以开发者为中心。” 为了让开源社区生态不断壮大,睿赛德科技开展了嵌入式软件人才计划,促使开发者考取能力认证,进行 OS 知识培训,为企业提供人才服务。他们还与高校合作,开展大学计划,支持老师写书、教材和开课;并资助实验室和 IoT 项目开发;举行大学生竞赛、高校雄鹰计划等。


目前,RT-Thread 主要通过为企业用户提供技术服务、定制开发、技术授权、硬件销售、软件分成等方式盈利。


谈及下一代 RT-Thread 的技术发展,RT-Thread 创始人兼 CEO 熊谱翔表示,将从四个方向发展:


下一代 RT-Thread 将采用混合式微内核架构的模式,这样的架构具备内核小、启动快、功耗低、应用隔离、安全性高等的优点;采用轻型小巧的音视频框架,能对网络音视频进行优化,支持多种格式和流媒体协议。采用集成 AI 平台的轻型 AI 框架,支持异构处理器,集成本地语音识别、关键词唤醒、打断等功能;采用图形化集成开发环境,为更好地服务开发者,RT-Thread 提供了图形化、云端一体的集成开发环境,让开发者方便快捷地开发应用。据熊谱翔透露,这个产品将在 12 月 21 号正式发布,以免费开源的形式提供给开发者。


谈及未来的市场策略,熊谱翔的期望是在 2023 年完成 RT-Thread 装机量 20 亿台,其中联网终端占比 50% 以上;实现国内 IoT 终端市场份额 30%(年出货)左右,并在国外也具备一定知名度,让 RT-Thread 成为未来主流 IoT OS 之一。


随着物联网设备的连接越发广泛,RT-Thread 这样一款高性能、易裁剪的实时操作系统,会是整个物联网生态中重要的一环。


据了解,2019 年 11 月,RT-Thread 获得了近亿元人民币的 B 轮融资,由 GGV 纪源资本领投,君联资本追投。2018 年 6 月,完成数百万美元 A 轮投资,投资方为君联资本,2017 年获得华强聚丰和弛星创投近千万元天使轮投资。



作者: 不点    时间: 2019-12-1 02:39
本帖最后由 不点 于 2019-12-1 03:47 编辑

RT-Thread 支持主流芯片架构:ARM Cortex-M, MIPS, X86, Xtensa, C-Sky, RISC-V

但目前好像还不支持 64 位。

刚才的消息中提到,下一代的 RT-Thread 将采用微内核。

另一个问题:Unix 兼容性不知是什么情况。


目前 RT-Thread 官网公布的合作伙伴有如下 20 个:


                        
        

作者: 不点    时间: 2019-12-1 12:48
物联网操作系统亿元融资诞生
RT-Thread 一出好戏刚开始

http://m.elecfans.com/article/1122270.html

张慧娟  2019-11-26
                                                                                                                                                                                                                                                                                                        
墨记


今日,物联网操作系统提供商 RT-Thread(睿赛德科技)正式宣布,获得近亿元人民币的 B 轮融资本轮融资由 GGV 纪源资本领投,上一轮投资方君联资本追投,Skillnet/上海赛哲作为本轮融资的独家财务顾问。

迄今为止,睿赛德科技总计完成三轮融资,前两轮分别是:2017 年由深圳华秋(华强聚丰)、驰星创投;2018年,获得君联资本 A 轮投资。

RT-Thread 是一个集实时操作系统(RTOS)内核中间件组件开发者社区于一体的技术平台,也是一个组件完整丰富、高度可伸缩、简易开发、超低功耗、高安全性的物联网操作系统。它具备物联网操作系统平台需要的所有关键组件,包括 GUI、网络协议栈、安全传输、低功耗组件等。

GGV 纪源资本是一家专注于全球早、中期企业的风险投资公司,管理共 13 支基金,累计 62 亿美元的资产。曾投资过阿里巴巴、滴滴出行、去哪儿、Airbnb、满帮集团、今日头条、小红书、小鹏汽车等近 300 家公司。目前为止,GGV 纪源资本投资的公司中有 60 家独角兽企业,37 家已经成功上市,并有 68 个并购项目。


为什么投RT-Thread?




GGV 纪源资本投资副总裁罗超表示,RT-Thread 定位于“小而美的物联网操作系统”,这是吸引他们投资的主要原因,因为这是未来的方向所在。“小”代表着可伸缩、易裁剪,和需求刚好符合,不多不少,直接匹配使用场景,这对未来的 IoT 操作系统是非常重要的能力,针对五花八门的应用,它都可以做到“小而美”。

另外他们看重 RT-Thread 在嵌入式开源社区的生态建设。“在这个生态领域,RT-Thread 如果说是第二,应该没有人说自己是第一”。罗超表示,“这是他们多年在开源社区积累下的基础和口碑,广泛的用户基础,决定了 RT-Thread 在开源社区将来所能达到的规模。”

“投资就是投方向、投团队。我和 RT-Thread 团队第一次见面就有惺惺相惜的感觉。RT-Thread 的创业班底很特别,都是长期活跃在技术论坛的志愿者大拿,他们共同奠定了早期的基础。当公司正式成立的时候,他们放弃了原来的高薪职位,从全国各地加入公司,颇有些振臂一呼、天下响应的感觉,这是一支凝聚力极强且打不死的团队。” 罗超说道。

经过 13 年的发展,RT-Thread 累积装机量超过 2 亿台,嵌入式开源社区活跃度行业第一,拥有开发者人数近十万,成为国人自主开发、国内最成熟稳定和装机量最大的开源 RTOS,被广泛应用于智能家居及安防、工业、穿戴、智慧城市等众多行业领域。

熊大和他的创业故事

熊谱翔,睿赛德创始人、CEO,RT-Thread 的第一行代码、第一个内核版本,都是他一行行亲手敲出来的。熊谱翔身上不时闪现出一种“反差萌”:谈起技术时像所有的理工男一样,专注、笃定;说起公司经营时,又是一种轻车熟路的自信。这是多年的职业经历赋予他的特质。他的创业故事更像是对代码痴迷之余的意外收获。

第一次见面,他的自我介绍是:你好,我是熊大。事实上,在《熊出没》播出前,他作为技术大拿已经被论坛坛友们尊称为“熊大”了,那是中国程序员开源社区中最受欢迎的 RTOS 之一。

熊谱翔在开源软件领域的经历可以追溯到大学时,这个数学天才刚一接触到 Linux 就被迷上了,他认为这是“一种简单优雅到让人感动的软件代码”。大学四年的业余时间,几乎都献给了 Linux。

毕业后,熊谱翔加入阿尔卡特担任工程师,后来曾在 Marvell 等多家通信企业、半导体企业任职。工作之余,他还是喜欢逛技术论坛,解答或者和大家一起探讨技术问题。

也就是那时,他发现了一个新方向:市面上缺少一种真正小尺寸、开源,并且符合 Linux 简约代码风格的嵌入式实时操作系统。2005 年,他开始着手这项工作;2006 年,以开源、社区化的方式发布了 RTOS 第一版内核,取名 RT-Thread,实时线程的意思。

它的出现,不仅解决了开发者的需求,也引发了很多共鸣。来自各大 IT 公司的程序员,陆续加入这一开发行列,在本职工作之余进行编码、调试,贡献着各自的力量。直至 2015 年,他们中的骨干力量,从各自的公司辞职,和熊谱翔一起全职运营 RT-Thread。

物联网操作系统,是一个长期被低估的默默无闻的领域。过去 5~10 年间,中国的高科技产业开始高速发展,诞生了一批以 BAT 为代表的互联网明星企业。事实上,所有的高科技行业,都离不开底层芯片、操作系统的迭代发展。难能可贵的是他们从业余时间的投入开始,一坚持就是十几年,凭的就是这份对技术的热情,和不为外界所动的坚持。

物联网盛宴才刚开始,大厂并非通吃

在 AI、5G 的推波助澜前,物联网在国内经历了很长一段不温不火的时期。当时,业界的着手点主要在消费级产品,与智能家居相关度很大。而事实证明,这其中有些场景是刚需,有些则不是。

2018 年是一个比较明显的转折点,物联网向 to B 领域的渗透开始大规模发生,不论是楼宇、工厂还是物流,这些重型的第二产业的整个环节几乎都与物联网有交叉。

为什么会出现这种情况?罗超的观点很有趣,他认为物联网与传统产业的结合,就像一道数学命题:小明、小红从 A、B 两点各自出发、相向而行,忽然有一天找到交点相遇了。

因为传统工业设备比较落后,当进行现代化改造时,一个巨大的痛点浮出水面:数据的获取成为突出问题,更无从谈基于数据的管理。怎么办?最初工厂开始逐个项目去定制、开发,但是,这对时间、金钱投入都是巨大的挑战。

小明、小红相遇的前提是存在的:一边需求很旺,一边技术相称。物联网的价值主要体现在:能在传统机械化和现代智能化的运作方式之间建立一个新的管道,即信息化。只有把信息化和数据化先做好,才有可能实现未来的智能化。就像七八十年代的一句话“要想富先修路”,物联网就是这条通往未来的公路。通过软件+硬件+大数据结合的方式,把这条公路修好是当务之急,未来才能赋能中国百业发展。

那么,为什么需要专门的物联网操作系统?它能发挥出什么样的价值?

就像在桌面机时代占据霸主地位的 Windows 系统,却不能在手机上成为标配,而是形成了以 iOS 和 Android 为主的两大阵营。一个最基本的原因就是 Windows 对于手机来说太“重”了,手机这种对空间、能耗都更严格的应用,需要一个更小、更轻便的操作系统。

物联网现在面临的是同样的问题。第一,小到电灯,大到工厂的机械臂,都需要芯片实现控制、数据传输等,所需算力无需太高、内存不需太大,但是对功耗要求很严苛;第二,物联网时代的应用场景更丰富、功能更为多样化,导致了需求的分散,各种接入设备之间的通信协议种类繁多,设备规格差异大,因此操作系统也需做到尽可能灵活,且占用运行资源、功耗要低

物联网操作系统终于迎来了发展史上的黄金时期,不过,现在正处于大浪淘沙的阶段。

RT-Thread 并不是这个领域唯一的玩家。国内外科技巨头早已注意到了这个大蛋糕。早在 2014 年,Intel 收购的 Wind River 就发布了 VxWorks 7;同年,ARM 推出 mbed OS;后来,微软在 Win 10 基础上发布了 Windows 10 IoT Core。与此同时,国内开源系统也纷纷发布,以阿里的 Yun OS、华为的 LiteOS、腾讯的 TencentOS tiny 等为主要代表。

大公司有技术、有资金、有生态,像 RT-Thread 这样的小公司优势何在?

大公司和小公司的玩法会有不同。大公司首先会构建自己的生态体系,其操作系统一定会优先满足自己生态中的场景和设备。就算是开源的,操作系统作为底层的接口非常敏感,小公司是否愿意进入他的生态中?大公司之间是否会采用对方的操作系统?这都是很大的疑问。正因如此,像 RT-Thread 这样独立的、第三方操作系统的价值就体现出来了。

这一点可以手机时代的 Android 系统为佐证。当 A 厂不敢用 B 厂,B 厂也不敢用 C 厂,最后发现还是用最开源的、最中立的操作系统为好,这从经济投入、稳定性都是最佳选择。

物联网时代也将延续这样的发展轨迹。“RT-Thread 在整个 RTOS 的大背景下,价值会越来越凸显出来”,罗超说道。

物联网操作系统需要资本和生态支持

目前,RT-Thread 拥有良好的软件生态,支持市面上所有主流的编译工具如 GCC、Keil、IAR 等,工具链完善、友好,支持各类标准接口,如 POSIX、CMSIS、C++ 应用环境、Java Script 执行环境等,方便开发者移植各类应用程序。商用支持所有主流 MCU 架构,如 ARM Cortex-M/R/A, MIPS, X86, Xtensa, C-Sky, RISC-V,几乎支持市场上所有主流的 MCU 和 Wi-Fi 芯片。目前,已与 8 家主流芯片商、6 家知名终端商、2 家大运营商、3 家云服商形成了稳定的合作关系。

有了新一轮资本的加持后,RT-Thread 将继续扩张研发团队,开发优化新一代微内核操作系统及其相关软件和工具。同时,公司将投入更多资源,加大 RT-Thread 生态社区的建设力度,如社区运营、能力认证、大学计划等,构筑更高的生态壁垒。深圳华秋作为创投资方之一,其旗下的电子发烧友网将依托强大的产业链资源继续助力 RT-Thread 生态建设。

针对未来的竞争格局,熊谱翔表示,物联网软件生态的繁荣将由 AIoT 操作系统逐渐主导。在这一过程中,物联网操作系统平台将会逐渐收敛到 2~3 家。

RT-Thread 将向中高端 AIoT 应用领域持续拓展。近年来,通过加快版本迭代更新的速度,实现了如 AT 组件、脚本开发环境的优化支持,以及通常只有 Linux 这种大型 OS 才支持的 SMP 多核调度等。

微内核是面向未来的新一代架构,RT-Thread 经过充分验证评估后在今年年初开始推进。对于未来的 AIoT 产业所需的低资源占用、高安全等特性,它能够在性能与成本间实现更好的平衡,整体能力也将大幅提升。

此外,还有增加音视频框架的支持、集成 AI 平台、实现端云一体的图形化 IDE 等,都是 RT-Thread 下一代操作系统的亮点。


预计到 2023 年,RT-Thread 将达到 20 亿台装机量,其中联网终端占比 50%,年出货实现国内物联网终端市场份额 30% 以上。

在中高端应用上被越来越多的用户所青睐,正成为最受欢迎的实时操作系统——熊谱翔认为,一切仅仅是开始。在国际环境复杂多变的大背景下,国产操作系统还将迎来更大的发展机遇,特别是 RT-Thread 坚持社区化和中立的发展战略和定位,坚信“无生态不 OS”的理念,各个行业的重量级合作伙伴不断增加,软硬件生态持续优化,社区扩张呈加速态势。RT-Thread在 RTOS 应用拓展、社区运营和商业模式上的探索和创新在世界范围内都具有开创性,将会给行业带来深远的影响。


                                                        
                                       





作者: wintoflash    时间: 2019-12-1 12:55
本帖最后由 wintoflash 于 2019-12-1 12:57 编辑

我现在看这些吹牛逼的文章就反感。宣传的牛逼吹得越响,用于开发的投入就越少。
https://github.com/RT-Thread/rt-thread
这个好像不是面向桌面的OS,

作者: 不点    时间: 2019-12-1 15:45
wintoflash 发表于 2019-12-1 12:55
我现在看这些吹牛逼的文章就反感。宣传的牛逼吹得越响,用于开发的投入就越少。
https://github.com/RT-Th ...

不知 wintoflash 有没有心仪的一款 os 推荐一下?
作者: 不点    时间: 2019-12-1 17:19
找到了 RT-Thread GUI 的信息,先转贴知乎上 2018 年的文章:

https://zhuanlan.zhihu.com/p/45431187

RT-Thread 三探——LCD 驱动移植(使用GUI  Engine)
何处不江南专注于编程的嵌入式工程师

继网络之后又一个比较重要的功能--GUI

对于 RT-Thread 使用的 GUI 我还没有什么概念,本文只是针对 LCD 驱动部分的移植,并使用 GUI 运行本身提供的 demo 样例。

当然还是和 ETH 一样,在 STM32F4xx-HAL 的 BSP 中是没有 LCD 的驱动文件的,还是从 STM32F429 BSP 中复制过来,在此基础上移植就好啦。

移植步骤:

在此可以稍微介绍下 RTT 基本的结构,RTT 这个系统主要由下面几个部分组成:

1、最重要的实时内核
2、shell
3、一些常用库(Lwip,文件系统,AT Command)
4、一些中间层(如设备抽象,SAL)
5、一些不那么常用的软件库(各种软件package,如图像识别,GUI,iot支持,数据库等)

这次要使用的 GUI 就在 package 的 system packages 中。

关于 RTT 整个系统的理解,我也会在领会了之后在文章中慢慢写出来供大家探讨。那么先,回到移植上来:

1、首先在 env 中使用 menuconfig,开启 GUI Engine。






然后保存退出,别忘了在 env 中使用 pkgs --update 更新软件包,然后重新生成 mdk5 的工程。

接下来就是在 STM32F429 的 BSP 中找到 drv_lcd.c .h 文件,复制到 STM32F4xx-HAL,Driver 文件夹中,并添加到 mdk 工程中,如下图:




该驱动主要需要根据不同的接线更改几个部分:

一、将 FMC 修改为 FSMC。因为 STM32F429 外设是 FMC,而 STM32F407 的外设是 FSMC,这个地方需要首先修改。




二、修改 FSMC 相关引脚,因为引脚复用关系,所以有可能使用的 FSMC 引脚与 STM32F429 使用的不相同,这个部分需要根据原理图修改。



三、修改 LCD RAM 的地址,以及 NAND Section 的选择。根据接线的不同,修改这些参数。




四、修改背光控制引脚。根据原理图,初始化背光控制引脚,并打开背光。



还有一点可能是一个小 BUG,在源文件中,使用宏

INIT_BOARD_EXPORT(rt_hw_lcd_init);

将初始化代码添加到自动初始化中,但是这种初始化会使得 lcd 在串口初始化之前就被初始化,初始化无论是否打开 DEBUG 宏,内部的调试都无法输出。解决这个问题可以使用如下宏

INIT_APP_EXPORT(rt_hw_lcd_init);

将初始化导入到 APP 之前的阶段,这样就可以输出调试信息了。

接下来导入一个 GUI 的 demo 程序。


  1. struct rtgui_win *main_win;
  2. rt_bool_t dc_event_handler(struct rtgui_object *object, rtgui_event_t *event);

  3. static void rt_gui_demo_entry(void *parameter)
  4. {   
  5.     struct rtgui_app *app;
  6.         //struct rtgui_dc *dc;
  7.    
  8.     DEBUG_PRINTF("gui demo entry\n");
  9.         
  10.         /* create gui app */
  11.     app = rtgui_app_create("gui_demo");
  12.     if (app == RT_NULL)
  13.     {
  14.         DEBUG_PRINTF("rtgui_app_create faild\n");
  15.         return;        
  16.     }
  17.    
  18.         /* create main window */
  19.         main_win = rtgui_mainwin_create(RT_NULL, "UiWindow", RTGUI_WIN_STYLE_NO_TITLE | RTGUI_WIN_STYLE_NO_BORDER);
  20.     if (main_win == RT_NULL)
  21.     {
  22.         DEBUG_PRINTF("main_win is null\n");
  23.         rtgui_app_destroy(app);
  24.         return;
  25.     }
  26.         
  27.         rtgui_object_set_event_handler(RTGUI_OBJECT(main_win), dc_event_handler);
  28.         
  29.     DEBUG_PRINTF("rtgui_win_show\n");
  30.         rtgui_win_show(main_win, RT_FALSE);
  31.    
  32.     DEBUG_PRINTF("rtgui_app_run\n");
  33.         rtgui_app_run(app);
  34.    
  35.     DEBUG_PRINTF("rtgui_win_destroy\n");
  36.         rtgui_win_destroy(main_win);
  37.    
  38.     DEBUG_PRINTF("rtgui_app_destroy\n");
  39.         rtgui_app_destroy(app);        
  40. }

  41. rt_bool_t dc_event_handler(struct rtgui_object *object, rtgui_event_t *event)
  42. {
  43.     struct rtgui_widget *widget = RTGUI_WIDGET(object);

  44.     if (event->type == RTGUI_EVENT_PAINT)
  45.     {
  46.         struct rtgui_dc *dc;
  47.         rtgui_rect_t rect;
  48.                
  49.                 rt_kprintf("\r\n RTGUI_EVENT_PAINT \r\n");
  50.                 rtgui_win_event_handler(RTGUI_OBJECT(widget), event);
  51.         
  52.         rtgui_widget_get_rect(widget, &rect);
  53.         DEBUG_PRINTF("widget react x1: %d, y1: %d, x2: %d, y2: %d\r\n",
  54.                                 rect.x1, rect.y1, rect.x2, rect.y2);

  55.                 dc = rtgui_dc_begin_drawing(widget);
  56.                 if(dc == RT_NULL)
  57.                 {
  58.                         DEBUG_PRINTF("\r\n dc is null \r\n");
  59.                         return RT_FALSE;
  60.                 }

  61.                 rtgui_dc_draw_line(dc,0,0,240,320);
  62.                 rtgui_dc_draw_line(dc,0,320,240,0);
  63.         //rtgui_dc_draw_text(dc, __DATE__, &rect);
  64.         rtgui_dc_draw_text_stroke(dc, __DATE__, &rect, HIGH_LIGHT, BLUE);
  65.         
  66.         rect.y1 += 20;
  67.         rect.y2 += 20;
  68.         rtgui_dc_draw_text_stroke(dc, __TIME__, &rect, HIGH_LIGHT, BLACK);
  69.         
  70.         
  71.                 rtgui_dc_end_drawing(dc, RT_TRUE);
  72.     }
  73.         return RT_FALSE;
  74. }

  75. int rt_gui_demo_init(void)
  76. {
  77.     rt_thread_t tid;
  78.     tid = rt_thread_create("mygui",
  79.         rt_gui_demo_entry, RT_NULL,
  80.         2048, 25, 10);

  81.     if (tid != RT_NULL)
  82.         rt_thread_startup(tid);
  83.    
  84.     return 0;
  85. }
复制代码


移植工作到此也就基本结束了,接下来就没有最期待的 Shell 环节了(。。。)毕竟是移植 GUI,直接看屏幕也就 OK 啦,拍照留念。



编辑于 2018-09-27




作者: 不点    时间: 2019-12-1 17:43
关于 GUI,在 csdn 上能找到很多文章,比如下面这两篇:

2014 年:【RT-Thread】——GUI 服务器 https://blog.csdn.net/liaoxu02/article/details/36180779

2017 年:RT-Thread 学习笔记(四)——添加 RTGUI 组件 https://blog.csdn.net/skawu/article/details/78507468

这也说明,GUI 的问题很早就有研究了。

作者: wintoflash    时间: 2019-12-1 18:18
不点 发表于 2019-12-1 15:45
不知 wintoflash 有没有心仪的一款 os 推荐一下?

除了Linux,我还真不知道有其他"能用"的开源操作系统。
我在三个月前完全放弃Windows,使用的Linux发行版是Manjaro。
作者: 不点    时间: 2019-12-4 22:58
wintoflash 发表于 2019-12-1 18:18
除了Linux,我还真不知道有其他"能用"的开源操作系统。
我在三个月前完全放弃Windows,使用的Linux发行 ...

嗯,确实。我们也不能寄希望于某个系统能够“一步登天”。Linux 发展了快 30 年,还没冲破 Windows 的天(甚至可能连地都没拱出来)。有“不同”即可,不能过多强求。哪怕是纯粹打酱油,用看戏的态度来对待这些新生的操作系统,也都是合情合理的。当初有好多人(包括我)对待 Linux,就是“观望”的态度。就拿我来说,直到现在,我对 Linux 的命令都很陌生,只会用一些简单的,如 ls,cat,vi 之类。从这个意义上来说,如果某个新系统能有命令行可用,我可能就分不清它比 Linux 是强还是弱,因为我对 Linux 一样是不了解的。由于实际上我对 Linux 的认识是一张白纸,那么我对 Linux 也就没有很强的依赖感。无论学 Linux 还是学某个新系统,都是一样的困难。当然了,万事万物是普遍联系的,如果新系统没人写教程,那也会影响我对它的学习。如果缺乏傻瓜化桌面应用,那也会影响我的学习。
作者: gnuxwy    时间: 2019-12-4 23:25
除了Linux,我还真不知道有其他"能用"的开源操作系统。
我在三个月前完全放弃Windows,使用的Linux发行版是Manjaro。


屮觉得只有没有三个依赖的情况下才能完全放弃windows:
1、不依赖各种复杂windows游戏;
2、不依赖各种行业windows应用软件;
3、不依赖各种只有windows驱动的专门硬件;

屮年纪大了,能够不怎么玩游戏了,但氏2,3的依赖不可能去除,虽然屮用windows的时侯很少。

开源桌面系统,除了Gnux之外,其实还有freeBSD、netBSD、Minix发行版。
不过它们相比Gnux系统,硬件支持更差,配套可用软件也更少些,使用体验还比不上Gnux。。。





作者: wintoflash    时间: 2019-12-5 09:45
gnuxwy 发表于 2019-12-4 23:25
屮觉得只有没有三个依赖的情况下才能完全放弃windows:
1、不依赖各种复杂windows游戏;
2、不依赖各 ...

1、不依赖各种复杂windows游戏;

我常玩的Steam游戏都有Linux版本。
2、不依赖各种行业windows应用软件

我用的相关软件也有Linux版本。
3、不依赖各种只有windows驱动的专门硬件;

没有。
我换成Linux是因为Win10更新之后各种驱动都出现了问题,根本没法用。
之前用Windows也是主要用它的WSL环境,更新之后WSL经常出问题。
作者: gnuxwy    时间: 2019-12-9 20:46
我常玩的Steam游戏都有Linux版本。
我用的相关软件也有Linux版本。
没有。
我换成Linux是因为Win10更新之后各种驱动都出现了问题,根本没法用。
之前用Windows也是主要用它的WSL环境,更新之后WSL经常出问题。


W大牛比。。。竟然具备条件能完全放弃windows,屮氏做不到。。。

屮去W大的签名网址瞧了瞧,产品很丰富啊,而且还看到‘鲁班lub’也列于产品当中!
这引起了屮的回忆!

请问下W大,以前在ubuntu中文论坛用billbear这个账号玩过么?
屮最早知道 lub 就氏在 ubuntu 中文论坛得知的。。。 当然,近两年屮用debian要多些。。。




作者: 不点    时间: 2019-12-10 19:26
rt-thread 的 License 从 GPL 改为 Apache,引起我对授权协议的思考。

首先,每个协议都有它的特点,没有绝对的好坏之分,只有不同角度的不同倾向性。

多年来我都倾向于 GPL。但 Linux 内核存在的问题,让我对 GPL 也不那么迷信了。

我认识到,一个开源协议,它本身的优劣可能并不重要;重要的是,由什么人来维护软件。就是说,协议本身可能是很好的,但维护者出了问题,软件就会出问题。这跟该软件采用何种开源协议,已经没有太大关系了。

一个像 Apache 那样更加开放的协议,可能是比较好的。

GPL 保护弱者,是想让弱者能够投入开发。但是,在现实社会中,弱者太弱,没有硬件话语权,容易被强者扫荡。GPL 在保护弱者的时候,无形之中也会伤害强者。这就会引来强者的敌视(“毒瘤”说,大家都记得吧)。强者掌握硬件生产权,弱者手无寸铁,无法保护 GPL 软件。GPL 的短板显现。

像 Apache 之类的协议,它并不特别保护弱者。也因此,它引来的“敌视”就不太严重。不过,虽然强者的敌视减少了,但来自弱者的敌视却可能增加了。

然而,软件不能靠吃瓜的门外汉来推动,还得靠生产者来推动。所以,弱者的敌视,可以忽略不计。基于这样的考虑(也即在这样的前提之下),那么 Apache 之类的协议,比 GPL 更好。

作者: 不点    时间: 2019-12-10 21:35
谈罢了授权协议,再来说说 CPU。

最近一直在说“生产者”,而 CPU 就是“生产者”生产出来的。所以,无论 CPU 是啥,对于最终的瓜子们来说,都是“大眼瞪小眼”,或者说,八杆子打不着。无论 CPU 是先进还是落后,它距离最终的瓜子用户都很遥远,那是生产者的事,即使瓜子们想管,也管不着。

结论就是:不用区分 CPU 架构的好坏。哪个电脑你买得起、哪个电脑便宜、哪个电脑性能好、哪个厂家你信得过,你就买哪个。

作者: wintoflash    时间: 2019-12-10 21:42
gnuxwy 发表于 2019-12-9 20:46
W大牛比。。。竟然具备条件能完全放弃windows,屮氏做不到。。。

屮去W大的签名网址瞧 ...

那个是备份.
是修改过的用于Debian的版本.

作者: 不点    时间: 2019-12-10 23:36
本帖最后由 不点 于 2019-12-10 23:37 编辑

Redox 操作系统


https://redox-os.org

一个用 Rust 编写的类 Unix 操作系统,旨在将 Rust 的创新引入现代微内核和全套应用程序中。在保持适度的 Linux API 兼容性的同时,Redox 不怕丢掉 POSIX 的缺点。


这句比较有吸引力:保持适度的 Linux API 兼容性。


我想,推而广之,任何一个微内核的操作系统,都有可能在其上增加一个 Linux 兼容层。




作者: 不点    时间: 2019-12-11 10:44
gnuxwy 发表于 2019-11-29 22:50
确实氏‘反例’,而不氏范例!
因为hurd开发了三十年,仍然不够成熟,至今不敢用于生产环境,所以至今版 ...
优异的性能,良好的架构,平台移植性、维护性、扩展性

确实,这些都很重要。


目前有没有哪个 OS 比较接近这个目标?

作者: 不点    时间: 2019-12-11 11:30
好的,前面已经谈到了,作为瓜子用户,无力左右 CPU、主板等硬件架构。然而,利益这个东西,对谁都是存在的,瓜子用户同样有利益诉求。有硬件生产权的众多公司,它们会推出各自的软件方案。瓜子用户不太容易推出自己的软件方案,因为自己的方案,即便是最优秀的,但没有硬件来保驾护航,仍是非常脆弱,朝不保夕。不过,瓜子们可以选择(或倾向于)某个生产者推出的软件方案。谁对瓜子们有利,瓜子们就会选择谁。一个方案聚集的瓜子用户多了,这个方案成功的砝码也就增加了。所以,方案制定者也会(或多或少地)考虑“吸引瓜子用户”这个因素。
作者: sghihor    时间: 2019-12-11 13:26
本帖最后由 sghihor 于 2019-12-11 17:46 编辑

刚发现还有一个非LINUX内核的操作系统。Haiku。
https://www.haiku-os.org/(operating_system)


对了无意间看到下面这段话,
Ubuntu founder Mark Shuttleworth has likened ACPI to Trojan horses.[33] He has described proprietary firmware (ACPI-related or any other firmware) as a security risk, saying that "firmware on your device is the NSA's best friend" and calling firmware (ACPI or non-ACPI) "a Trojan horse of monumental proportions". He has pointed out that low quality, closed source firmware is a major threat to system security:[8] "Your biggest mistake is to assume that the NSA is the only institution abusing this position of trust — in fact, it's reasonable to assume that all firmware is a cesspool of insecurity, courtesy of incompetence of the highest degree from manufacturers, and competence of the highest degree from a very wide range of such agencies".

As a solution to this problem, he has called for declarative firmware (ACPI or non-ACPI).[8] Firmware should be open-source so that the code can be checked and verified. Firmware should be declarative, meaning that it should describe "hardware linkage and dependencies" and should not include executable code.


大概翻译如下:
乌班图创始人 把ACPI,比作木马。
觉得专有固件(与ACPI相关的固件其他任何固件)可能有安全风险。说‘设备上的固件是NSA的最好朋友’,
他指出,低质量的封闭源固件是对系统安全性的主要威胁.

为了解决这个问题,他要求使用声明性固件(ACPI或非ACPI)。固件应该是开源的,以便可以检查和验证代码。固件应该是声明性的,这意味着它应该描述“硬件链接和依赖性”,并且不应包括可执行代码。



作者: 不点    时间: 2019-12-11 18:49
本帖最后由 不点 于 2019-12-16 15:03 编辑

微内核简介

https://blog.csdn.net/juS3Ve/article/details/99618889

什么是微内核


微内核设计的基本思想是简化内核功能,在内核之外的用户态尽可能多地实现系统服务,同时加入相互之间的安全保护。内核只提供最基础的服务,比如进程调度,进程通信(IPC)等。其中进程通信是作为连接应用与用户态系统服务的桥梁。


下图是宏内核与微内核的对比示意图



上图左侧表示宏内核的架构,宏内核系统相关的服务基本都是放于内核态内核中,例如文件系统,设备驱动,虚拟内存管理,网络协议栈等;而微内核,则把更多的系统服务(例如文件系统,POSIX服务,网络协议栈,甚至外设驱动)放到用户态应用,形成一个个服务,等待其他应用的请求。

而后来,为了在宏内核与微内核之间扬长避短,也发展出了中间的混合内核的形态,部分服务也会放置于内核中。上图右侧表示即是混合内核的架构。

其实微内核与混合内核,混合内核与宏内核之间并无十分明确的界限,一般情况下把最多只具备 IPC(进程通信),进程调度,内存管理功能的内核称为微内核,把包含所有系统服务的内核称为宏内核,有少部分系统服务在用户态或者比微内核多一些系统服务的内核称为混合内核。


微内核的发展历史

微内核这个概念从提出开始就在不断地发展、完善进步之中,到目前为止可以分为三代。

第一代微内核:从无到有

第一代微内核的主要代表是 Mach,该系统由卡内基-梅隆大学的 Avie Tevanian 和 Richard Rashid 主导开发。在 Mach 刚刚开始设计时,UNIX 的发展正如日中天,所以 Mach 在设计时的一大目标就是兼容 UNIX,但是与 UNIX 不同的是 Mach 尝试使用微内核架构去设计。Mach 以 IPC 作为所有系统服务与内核交换数据的基础机制,充分运用 IPC,虚拟内存,多进程等特性将冗余的系统服务移出内核作为进程运行。


1986 年,经过两年的开发,第一版的 Mach 发布后的第二年,Mach 就发布了第 2 版,不过由于时间仓促,加之没有足够的人手与资金,所以此时 Mach 内核并不提供完全的系统服务。为了支撑系统上层运行,这一版的内核包含了大量 4.3 版本的 BSD 系统 (UNIX 的一个分支) 代码提供系统服务,并且 BSD 系统服务运行在内核状态,这导致 Mach 内核的代码体积甚至大于常规 UNIX 内核。第一版和第二版的 Mach 主要做了如下工作:1. 验证了微内核的可行性;2. 在多处理器计算机上进行移植验证了微内核在多处理器计算机上的运行;3. 最后为了提高 IPC 的效率,Mach 使用共享内存机制来完成 IPC。而 Mach 的共享内存机制是在虚拟内存技术的支持下实现的,只有需要对内存进行写入时才进行复制。这么一处理比每次都复制一遍内存节省了内存使用同时又加快了 IPC 机制的处理时间,这个改进称为写时复制,并且在如今的通用操作系统如 Linux 中常常用到。


经过测试,Mach 2.5 的效率最多比 UNIX 少 25%,考虑到 Mach 带来的可靠性、可拓展性、安全性,这个损失尚可以接受。当然此时 Mach 内核还不算完全的微内核。而考虑到微内核可以更高效地利用多处理器计算机的处理器核心资源,人们期待着等 Mach 把系统服务都搬到内核之外后可以把运行效率损失降下来。同时 Mach 在微内核方面小小的尝试迅速吸引了大批公司与组织的注意,开放软件基金会 (Open Software Foundation, OSF) 宣布下一代系统 OSF/1 将基于 Mach 的内核, NeXT STEP 也将使用 Mach 2.5, 甚至 IBM 也打算利用 Mach 构建 Workplace OS。苹果公司这个时候也出手了,苹果公司也从此基于 Mach 2.5 打造其操作系统内核 XNU。XNU的构成如下图所示,Mach 作为内核的内环,外环右侧是苹果的驱动框架(I/O Kit),外环左侧是 BSD 的系统服务代码提供 UNIX 兼容的服务层,这三者共同协作向上层提供完整的系统服务。XNU 广泛地使用在苹果公司的 OSX、iOS 等系统中。

这个时候由于 UNIX 系统广泛使用带来的商业利益,此时 BSD 系统开发者与 UNIX 的拥有者 AT&T 陷入了法律大战,Mach 使用的 BSD 相关代码有了法律风险。提升性能的期望和规避法律风险的需求推动着 Mach 3.0 的开发,Mach 3.0 的开发目标主要是为了替换 BSD 系统服务,同时尽量多地将系统服务放到内核之外去运行,成为名副其实的微内核设计。经过众多开发者 3 年的努力,Mach 3.0 于 1990 年发布,但是由于在系统服务之间完全使用 IPC 通信,而不是像宏内核那样直接进行函数调用,即便在多处理器机器上运行,其性能损失也惨重,Mach 3.0 最多比 UNIX 损失 67% 运行效率,这导致 Mach 3.0 及其代表的第一代微内核设计被看衰。此后断断续续有在 Mach 的基础上对性能进行提升的尝试,但是均不太理想。至此 Mach 成为了微内核第一代先驱者。

第二代微内核:解决性能问题

第二代微内核的主要代表是 L3 和 L4,以及 QNX 系统使用的 Neutrino 内核。前面第一代的微内核 Mach 由于效率问题虽然失败了,但是微内核的理念并没有被放弃,德国的计算机科学家 Jochen Liedtke 认为 Mach 的 IPC 效率低下的原因就是因为 IPC 部分不够精简,于是他开发了 L3 和 L4 微内核,对 IPC 部分进行了很彻底的精简:1. 内核的 IPC 机制只是单纯地传递信息,诸如安全权限检查这类的代码都省略掉,省略掉的功能全部由用户进程自己处理。如此一来 IPC 功能部分的代码执行时间大大缩短;2. IPC 不使用内存传递消息,而使用寄存器传递消息,同时限制 IPC 每次传递的信息长度,这样省去了对内存的访问时间。L4 微内核的 IPC 速度经过测试要比 Mach 快 20 倍,这个令人惊讶的优化效果吸引了众多的目光,使微内核的研究重新火热起来。后面 L4 内核又发展出了很多相关系统,比如 Pistachio,L4/MIPS,与 Fiasco 等等,这些内核组成了 L4 的大家族。



第二代微内核的代表除了有 L4 内核,也还有其他微内核比如 Exokernel,Rambler,不过商业上最成功的则是目前黑莓公司旗下的 QNX 系统所使用的 Neutrino 内核(QNX,1980年时最早以 QUICK UNIX 诞生;2004 年 QNX 被 Harman 国际收购;2010 年被黑莓收购 Harman 国际下的 QNX 资产),QNX 主要为高可靠领域提供解决方案,比如交通,能源,医疗,航天航空等。





第三代微内核:主要重视安全问题等

在前面两代的基础上,第三代微内核蓬勃发展,许许多多微内核都被开发出来,主要代表有:seL4, Fiasco.OC, NOVA 等。本来第一代微内核的设计隔离了使内核安全性降低的系统服务,让系统服务漏洞不会影响内核,进而提高了内核安全性,可以说是关上了破坏系统的门, 但是第二代系统却又给攻击者开了个窗户;由于第二代微内核在内核中省去了关于安全性检查等步骤,把所有关于安全检查功能的实现都交给系统服务自己去实现,这导致系统服务的通信接口直接暴露给用户态,任何进程都可能无限制地请求系统服务,系统服务不得不花费额外的代价来区分请求是否合法,容易造成拒绝服务攻击。比如正常的文件服务应该是从虚拟文件系统服务->文件系统服务->磁盘驱动服务这个流程来完成的,但是如果攻击者如果绕过虚拟文件系统服务,直接无限制地请求攻击者本身没有权限访问的文件系统服务,使文件系统服务长期处于满载状态,让其他进程无法通过正常的虚拟文件系统得到文件系统服务。为了增强安全性,且不过分影响性能,人们开始研发第三代微内核。


seL4 是在第二代内核 L4 的基础上发展而来的。seL4 不仅仅继承了 L4 内核家族的高性能特性,还具备基于端点 (endpoint) 的 IPC 机制。这种 IPC 机制最大的特点是使用了能力空间的概念,进程在使用 IPC 请求系统服务时必须具备相对应的能力,进程持有不可伪造的令牌来表示拥有请求某种服务的能力。令牌可以被复制,可以被转移,还可以通过 IPC 进行传输。令牌其实是一个指向存在于内核空间内核对象的指针,所以普通进程并不能修改自身以及其他进程的权限分配,但是内核可以对令牌指定的权限进行控制,从而保证了用户态不能绕过能力空间这个机制对系统服务造成滥用。


seL4 还是第一个完全通过形式化验证的内核,通俗说形式化验证就是在数学软件的帮助下使用数学语言自动化地推导检查系统的每一个运行状态。seL4 形式化验证相关论文。

其他的微内核系统:Fuchsia,Minix

Fuchsia 是 Google 开发的一款全新操作系统,试图覆盖手机,平板,甚至笔记本等一系列领域。Google 为该系统配备了 Vulkan 图形接口,3D 桌面渲染 Scenic,Flutter 应用开发框架,还有一个称为 zircon 的微内核。zircon 内核是从高通平台的一个 Bootloader 项目 Little Kernel 发展而来。zircon 内核属于微内核设计,只提供 IPC,进程管理,地址空间管理功能。zircon 区别于以进程或者以文件为核心的设计,zircon 是以内存为核心来设计的,内存在 zircon 中是以对象的方式存在,可以通过 channel 通信机制传递虚拟内存对象(Virtual memory object)的句柄,进程拿到句柄后可以把这块内存映射到自己的空间。


Minix 系统则由荷兰阿姆斯特丹的 Vrije 大学的 Andrew S. Tanenbaum 教授所开发。该系统最大的特点是可以故障隔离,自动重启失败的服务。Minix 使用分层设计,最底层的微内核提供中断处理,进程管理,进程通信等服务,中间层提供轮回服务 (Reincarnation Server),这一层运行在内核态;文件服务,进程管理,X 图形服务以及驱动等,这一层运行在用户态;最上层为用户进程。其中轮回服务负责在中间层的服务出现崩溃时重启这些服务,从而保证服务的自我修复。Minix 由于其自我修复特性被英特尔管理引擎(ME)所选用,该管理引擎主要负责管理英特尔芯片的内部模块。

微内核的优缺点

优点

    系统服务模块化,可移植性高;
    内核安全性提高(模块内部的 bug 不影响内核稳定,将黑客利用软件漏洞造成的破坏限制在单个模块内部);
    可以多套系统服务共存,相当于同时运行多种操作系统;
    稳定统一的接口(可以独立维护私有驱动以及服务,不需要跟内核源码绑定);
    在商业上,微内核可以避免代码受到一些开源协议的影响,比如 GPL 协议。
    内核精简,可以进行形式化验证,利用数学证明内核的安全性;
    数学可证明的实时性;
    非常适合多处理器系统设计,在多处理器核心计算机上,互相依赖的系统服务可以同时运行;

缺点


    通过进程通信的方式交换数据或者调用系统服务,而不是使用系统调用,造成额外的操作系统开销。
    使用一些频繁使用的系统服务时,比如网络收发数据,造成的进程上下文切换对操作系统来说也是一个负担。
    由于系统服务高度模块化,系统服务之间存在大量的内存复制。
    对互相之间存在复杂调用关系的系统服务,难以设计通信接口。
    系统服务与内核在地址空间上分离,造成代码局部性差,降低了 cache 命中率。



4.png (251.73 KB, 下载次数: 61)

4.png

3.png (79.82 KB, 下载次数: 73)

3.png

2.png (43.73 KB, 下载次数: 75)

2.png

作者: wintoflash    时间: 2019-12-11 19:17
sghihor 发表于 2019-12-11 13:26
刚发现还有一个非LINUX内核的操作系统。Haiku。
https://www.haiku-os.org/(operating_system)

兄弟,跑题了。Haiku是混合内核的。
作者: 江南一根葱    时间: 2019-12-11 19:48
楼主居然说不是开源的,明明**是
富强民主文明和谐
自由平等公正法治
爱国敬业诚信友善

作者: wintoflash    时间: 2019-12-12 10:10
seL4
https://sel4.systems/
https://github.com/seL4/seL4
另外前几天偶然看到一个兼容Linux的
https://github.com/managarm/managarm
作者: sghihor    时间: 2019-12-12 15:08
本帖最后由 sghihor 于 2019-12-12 15:16 编辑
sghihor 发表于 2019-12-11 13:26
刚发现还有一个非LINUX内核的操作系统。Haiku。
https://www.haiku-os.org/(operating_system)


想表达的意思是,假如理想化状态就是
【不用固件】【或者用开源的固件】,启动。
这样安全风险小一点,不然内核再干净,固件层面也控制不了啊,
研究coreboot之类的。是不是,除了自由精神,也有一点儿这方面的原因。

作者: 不点    时间: 2019-12-12 22:09
只有一个选择是最好了。这么多选择,光是去选择、评判,恐怕都要多长几根白发了。
作者: 不点    时间: 2019-12-13 20:36
这么多微内核系统,需要某种准则来筛选。

单纯从技术上,是很难筛选的。微软等垄断性的大公司,有钱、有技术,他们的产品,即使起步晚几年,也有可能后来居上。所以,技术不是考量的指标。

如果说要考虑非技术指标,那基本上就是在说“信任度”了,即,谁更值得信任。

作者: 不点    时间: 2019-12-14 09:59
再来嚼一嚼授权协议问题。GPL 保护了没有生产权的普通百姓的利益,但是却或多或少地伤害了具有生产权的各种大小公司的利益,引来了或多或少的敌视。像 Apache 那样更加开放的协议,容易被生产者支持:小生产者可能完全没有敌意,甚至是全心地、大力地支持;大生产者可能会有敌意,但也不像对 GPL 的敌意那么大。

我印象中,关于 GPL 和 BSD 协议的选择取向问题,十多年前争论得很凶,双方互骂得很厉害。我那时自然要站在 GPL 的阵营里面。

但认识是不断深入的,材料是不断增加的,知识是不断积累的,情况是不断变化的。

1、GPL 保护了没有生产权的人群。这股力量固然不小,可是却处于底层,没有话语权,不能成大器。一旦某个个体或集团成了大器,当他有了话语权之后,身份摇身一变,就成了生产者,就脱离底层百姓的身份了,那他也就不属于 GPL 保护的对象了,他也很自然地逐渐对 GPL 萌生敌意。GPL 保护的对象很脆弱,GPL 的处境很尴尬。

2、被 GPL 保护的 Linux 内核,却被谷歌巧妙地用于 Android 的底层系统。谷歌窃取了众多 GPL 贡献者的成果,而且这一窃取行为是完全合法的!Android 相当于运行在 Linux 内核之上的一个应用层的程序。这个应用层的程序不必遵循 GPL,因此,完全合法。而谷歌在 Android 这个应用程序之内打造全新的接口系统,自成一体,而且故意与 GNU/Linux 现有的应用环境不兼容,形成软件壁垒,构建垄断帝国。可见,授权限制很严厉的 GPL,并不能真正保护普通贡献者的利益,照样能够被大公司钻空子,并最终伤害 GPL 的社区利益。GPL 的作用十分尴尬。这样的 GPL 与 BSD 和 Apache 又有多少差别呢?BSD 以及 Apache 协议的效果,不正是这样的吗?所以,GPL 在此例中的表现,并不比 BSD 和 Apache 强。换句话说,众目睽睽之下,有人“开脑洞”、公开地拿  GPL 当 BSD 和 Apache 使,你眼巴巴地看着,干瞪眼,没招。

3、Linux 是一个重要的 GPL 应用案例。这个案例不可避免地被敌对的垄断势力盯上。敌对势力对 Linux 的各个环节和关口,都打入楔子。谁给 Linux 基金会交会费?谁能控制和操纵 Linux 的开发?kernel、GCC、bash、dash、bin-utils 等等都被大公司或明或暗操纵控制,各个主要发行版更是有 n 多的破坏者在里面捣乱。新的发行版藏污纳垢更多,还没有 10 年前、20 年前的发行版来得安全。这样的 Linux 还能代表 GPL 所保护的那群吃瓜人的利益吗?GPL 名存实亡,其名分和地位很尴尬。

综上,GPL 过于理想化,在现实社会中很难达到那样理想的境地,GPL 在现实中会被扭曲。不如寻求更加贴合目前现实的其它解决方案。


作者: 不点    时间: 2019-12-16 11:35
前面谈到了选择微内核 OS 要考虑的因素 —— 信任度。


“信任度”包括的范围也很广。譬如说,谷歌开发的操作系统,虽然我对它不曾有了解,但我知道 node.js 以及 Chrome 浏览器是谷歌的。这两个东西是用来构建跨平台应用的,也就是说,不同的平台有着统一的接口,是保护投资的一个很好的方案。因此,在这方面,对谷歌是信任的。


如果一个公司推出了微内核解决方案,但后续的推动力很小,发展很缓慢,那么,这样的公司以及它的微内核 OS,就丧失信任度。


另外,如果对于兼容性没有考虑,或者考虑得不多,那么,这样的方案,也不能保护投资,因而也同样会丧失信任度。



作者: 不点    时间: 2019-12-16 17:01
就像 wintoflash 所说,在 Linux 之外,难以见到一个真正“能用”的开源操作系统。

好的,既然如此,把讨论的范围放宽,不限于“微内核”,任何结构的开源内核都可以讨论。

聚焦“能用”——看看哪个非 Linux 的开源 OS 的“可用度”最大。

所谓“可用度”,由各位自己定义。您认为可用度高,那就是高。

作者: 不点    时间: 2019-12-17 12:16
搜到 google fuchsia os 的图片,不知有没有人试试这个 OS?






作者: wintoflash    时间: 2019-12-17 15:05
不点 发表于 2019-12-17 12:16
搜到 google fuchsia os 的图片,不知有没有人试试这个 OS?

图二应为Windows 10,不是 Fuchsia去年的时候想试试,结果发现源码太大了,10多个GB,编译要占用60GB以上的空间。
而且整个编译过程需要有稳定的外网连接。



作者: 不点    时间: 2019-12-17 22:29
wintoflash 发表于 2019-12-17 15:05
图二应为Windows 10,不是 Fuchsia去年的时候想试试,结果发现源码太大了,10多个GB,编译要占用60GB以上 ...

谢谢。请问,以您的观点和视角,google 的 fuchsia,其开发更新的频度如何?您对其开发进展的速度,有没有信心?
作者: wintoflash    时间: 2019-12-18 13:15
不点 发表于 2019-12-17 22:29
谢谢。请问,以您的观点和视角,google 的 fuchsia,其开发更新的频度如何?您对其开发进展的速度,有没 ...

抱歉,我对 fuchsia 不感兴趣,因为对 google 非常不信任。
目前 fuchsia 是托管在 google 自家的平台上。以前还托管在 github 上的时候也没怎么留意,google 从 github 删库跑路后,就更不想看了。
当时尝试编译也是受人所托。
不过从源码的体积上来看,变化还是比较大的。

作者: 不点    时间: 2019-12-18 14:28
wintoflash 发表于 2019-12-18 13:15
抱歉,我对 fuchsia 不感兴趣,因为对 google 非常不信任。
目前 fuchsia 是托管在 google 自家的平台上 ...

谢谢 wintoflash 答复了我的疑问,并对信任度有了明确表示。我前面的问题主要集中在“开发进度”上,您的答复,让我在这方面对 Fuchsia 有了信任,或者说有了信心,既然看到它的进展还是挺快的。我希望能找到它编译好的测试版,来体验一下。不知有没有人知道哪里有编译好的版本。
作者: wintoflash    时间: 2019-12-18 15:22
不点 发表于 2019-12-18 14:28
谢谢 wintoflash 答复了我的疑问,并对信任度有了明确表示。我前面的问题主要集中在“开发进度”上,您的 ...

fuchsia中文社区(非官方)(https://fuchsia-china.com/)提供的代码镜像里面有个虚拟机文件下载 https://mirrors.sirung.org/fuchsia/

里面应该是Ubuntu以及编译好的fuchsia。至于怎么运行,似乎没有明确的说明。

作者: 不点    时间: 2019-12-18 16:48
谢谢 wintoflash 提供链接。有 18 G,解压后可能更大。先留着,等以后有空间了再下载。
作者: gnuxwy    时间: 2019-12-22 21:25
谢谢 wintoflash 提供链接。有 18 G,解压后可能更大。

天哪,google的fushia居然如此之大!
反正屮氏没兴趣去试了,屮和W大差不多,对Google信任度不高。。。

还氏等以后不点先试,然后再瞧不点大师的测试结果就行了。。。


作者: 不点    时间: 2019-12-23 03:41
gnuxwy 发表于 2019-12-22 21:25
天哪,google的fushia居然如此之大!
反正屮氏没兴趣去试了,屮和W大差不多,对Google信任度不高 ...

在下向来都是空想家和空谈家,从来不擅长实践的说。如果要等我,短则数月,长则数年,甚至遥遥无期也!

说不定哪天,你们几位想通了某个道理,抢先进行实践。

google 在 Android 上确实是作恶,故意制造与 Linux 的不兼容性。但它推行 nodejs,则有正面的意义,无论对它自己,还是对大家,都是有好处的。当然了,任何事情都有例外的,nodejs 对微软不一定有好处(确切地说,对垄断者不好,因为垄断者不希望与别人兼容,垄断者不希望自己的垄断优势被打破)。

前面我已经说过,指望华为支持 Linux,也是没啥盼头的。稍微有点实力的公司,都会把 Linux 看成敌人。例外情况是不多的。

那结论就是:不要对任何公司抱有那样的希望(即,“真心”地支持 Linux 以及开源)。

如果一个公司能够大力推进一个相对开放的平台,并且这个平台能够被大家接受,那就是一个进步。也就是说,只要能够“改良”微软的封闭源码体系,那就是进步。不可以追求“一步到位”,天上不能掉馅饼,世上哪有那么好的事情?以前的论述已经很彻底了,这就不多说了。

也许谷歌的系统不如 Linux 安全。Linux 虽然比较安全,但却被巨鳄们仇视——巨鳄们掌握硬件生产权——这就注定了 Linux 难成气候。谷歌的系统会对谷歌有利,对大众可能就不像 Linux 那样对大众有利了。但是,谷歌会强力推进自己的系统,它肯定不会像对待 Linux 那样对自己的 fuchsia 进行强力的封杀。只要 fuchsia 在开源方面能比 Windows 好那么一点点,那就是进步。

不光是 fuchsia,其它任何一个开源系统,都是进步的。

这里可能就需要各位自己进行对比和选择了。比如,大概有如下这些因素需要考虑:系统开发推进的速度怎样?系统的开放程度高不高?系统的兼容性好不好?系统的安全是如何保障的?系统保护谁的安全(关键是:能保护最终用户“我”的安全吗)?



作者: verycd8    时间: 2019-12-23 10:39
不点 发表于 2019-12-23 03:41
在下向来都是空想家和空谈家,从来不擅长实践的说。如果要等我,短则数月,长则数年,甚至遥遥无期也!
...

不点大师,请教一个问题,ARM版本的linux,没有initrd.gz引导文件,弄不清楚其中的引导过程
假如想自己添加initrd.gz,应该怎样修改?
或者说原来的引导过程怎样的?这样要说清楚比较难,就是想知道启动内核之后引导那个文件的。
有initrd.gz文件的比较好懂,没有的,不知道从那开始引导了
搜索了很久没找到答案
作者: 不点    时间: 2019-12-23 12:28
verycd8 发表于 2019-12-23 10:39
不点大师,请教一个问题,ARM版本的linux,没有initrd.gz引导文件,弄不清楚其中的引导过程
假如想自己 ...

实在抱歉,对不住您对我的信任。我对 x86 的套路还算有点了解,而对于 ARM,则严重缺乏认知。

x86 有 grub4dos 以及 grub2,基本都是很熟的套路了。然而,ARM 的 uboot 之类,我还没接触,不懂它的启动技术,因此也不知道它如何加载 kernel 以及 initrd。

我目前使用的 ARM 设备,都是人家制作好的系统,我没有任何更改。我也不知道人家是怎么启动 Linux 系统的。

我也有打算去研究一下 uboot 或者较新的 barebox 启动软件,但苦于没有太多时间能静下来学习。

作者: verycd8    时间: 2019-12-23 13:53
不点 发表于 2019-12-23 12:28
实在抱歉,对不住您对我的信任。我对 x86 的套路还算有点了解,而对于 ARM,则严重缺乏认知。

x86 有  ...

谢谢回复,我是菜鸟,弄不清楚ARM版的构造,不知道引导是先读取那文件,想修改无从改起。
不知道ARM的系统为什么做得这样占容量,集成的软件还少,你用过那个版本的ARM linux稳定?
用香橙派板子的linux,做得太差了,动不动就死机,浏览个网页都不稳定。
郁闷啊,容量还大,集成的软件还少,安装完连基本的中文环境都未弄好,其实我的要求不高,能和电脑上的veket集成常用软件就可以的了,才500M啊,常用到的都集成好了,浏览网页同时打开几十个都没问题,到底是香橙派没做好呢,或者是其他的开发板都这样的?
你用的开发板,你试着打开几十个标签看能稳定吗?
到底是驱动的问题,或者是ARM架构未成熟的原因呢?质量太差了啊
作者: verycd8    时间: 2019-12-23 13:54
不点 发表于 2019-12-23 12:28
实在抱歉,对不住您对我的信任。我对 x86 的套路还算有点了解,而对于 ARM,则严重缺乏认知。

x86 有  ...

香橙派的开发板倒是不贵,400元,就是系统做得太差了,总感觉国内的硬件开发跟上来了,但系统软环境跟不上节拍啊,连基本的正常使用都谈不上呢
作者: 不点    时间: 2019-12-23 14:44
我对 ARM 也在失望ing之中。目前还没有一个 ARM 硬件商值得我信任。粗略来说,跟您的感觉差不多。

x86 架构,垄断控制得太厉害,没有购买欲。ARM 也不是省油的灯,购买欲逐渐消退到原点了。

粗略感觉,最近一两年内,持币观望是上策。

作者: 不点    时间: 2019-12-23 17:01
fuchsia 中国网站倒计时发布该操作系统,大约在明年 4 月初。
作者: gnuxwy    时间: 2019-12-24 18:21
fuchsia 中国网站倒计时发布该操作系统,大约在明年 4 月初。

呃,虽然屮没兴趣抢先测试Google的fushia,不过那时即使不点大师还没来得及测试,肯定也会有许多人做详细测试的。。。

作者: verycd8    时间: 2019-12-24 21:34
不点 发表于 2019-12-23 17:01
fuchsia 中国网站倒计时发布该操作系统,大约在明年 4 月初。

华为也有一个呀 LiteOS呀。
作者: atoms    时间: 2020-1-4 13:08
有很多人站在华为的视角解读鸿蒙~总之说了一大堆~还有个词叫宏内核
华为说鸿蒙是微内核,但又说可以软件跨内核通道调用这个有点悬~
以前看了个新闻跨芯片的,可以像乐高那样多板卡互插调用芯片的~记不清英文名了
那段时间还会联想起黑客界那个解卫星通讯的老故事了~还有光纤硬解数据的事
芯片硬通信跨平台的权限~安全~速度优先级都是最高的,这里面就有无线标准专利垄断
后来有了网络,wifi就疯了,以后要有5G了,全部的电子设备都得跟着一起疯
所以乱局就来,有效管理的口号人工智能ic就成了各个厂商血刃之地了
以前的个人电脑pc都是芯片主板显卡硬盘单机效率最高,通过服务器进行软件交互数据处理已经远远跟不上发展需要了
这几年都大论生态~从逻辑学上来说也就是硬件对硬件~软件对软件~硬件对软件之间的事
微内核的定义方泛上来说都认可有一点是信息的植入,最早有intel的芯片序列号植入事件
所谓的解释权一般就是官方的,公认的,非官的
自从微IC的集群蜂窝计算~也就是B币带出的资本芯片运算过剩的产物~一系列的事之后
IC的生态也成了大家都要站出来解决的问题,以前都在西方在定标准,掌握最终解释权
国内现在还在搞芯片研发,还没有标准,也就是指令集~内存调用存储优先级~芯片的占用级~
再下级就是引导器~编译器~编程语言~软件层面的
从纯粹意义上说,植入rom或任何隐藏信息及调用通道的IC都不是纯意义的开源ic
自从有了板卡刷bios的解密各种玩法~
闭源植入IC就成了硬件厂商最先要考虑的事
所以未来,官办的~各类公司~闭源IC将是主流,这个会是常态,
在B站看了一些巨佬对现在社会解读且解释的根本在西方的资本文化
不知道以后会不会有众筹式非赢利的有固定标准的联盟微电子科学组织出现
如果出现的太晚,只能说整体的知识集累量与体系还不够~
作者: 不点    时间: 2020-1-4 14:06
嗯,这让我想到,开源就是一场欺骗。至少可以说,开源的成果被大公司利用了(掠夺了)从而让开源的表现,就像是一场欺骗。开源是放水养鱼。鱼养肥了,就该捕捞了。生产商的硬件就是鱼网。开源软件就是鱼。用硬件手段,想在任何时候打压开源,都可以随时打压。在不值得打压的时候,就要放水养了。你是一条鱼,随便你在水里翻腾,都跑不掉。最终还是会被逮住,宰杀掉。所以,像 GPL 那样严厉的开源协议,没什么卵用。在放水养鱼的生产商面前,GPL 一文不值。想用你就随便用你(谷歌不就是用 Linux 内核作为安卓的底层嘛),不想用你就随便打压你(谷歌、微软不都是在打压 Linux 嘛)。所以,根本不用对这个开源协议或那个开源协议区分得太清楚,或者对其中某个开源协议耿耿于怀。它们都一样,都是大公司的棋子、玩物。大公司随便耍,而一个吃瓜者只能被人家耍。人家放水让你玩的时候,你是可以玩的。人家收网的时候,你就玩不成了——不仅玩不成了,恐怕你还要被吃掉了。
作者: 不点    时间: 2020-1-4 22:19
开源还是闭源,都是一样的结果。为什么这么说?因为,一个公司选择了开源,是想放水养鱼。选择闭源,则是撒网捕鱼。都是对公司有利,公司才去干的。开源不是无条件的,开源的目的是等待“撒网捕鱼”的时机。Linux 这么好,但各大公司都要打压。然而各大公司也都在搞“开源”—— 现成的 Linux 不用,而推出自己的一套又一套新的开源系统,这是为什么?大概只能这么解释:因为 Linux 对公司不利,所以公司不可以支持 Linux。光是 Google 和 Intel,都已经弄出了好几个开源系统。有些公司开源开得积极,它们是迫切地需要放水养鱼。有些公司开源开得三心二意的,它们并不迫切地需要放水养鱼。各自的选择,都有其理由。
作者: wintoflash    时间: 2020-1-6 08:44
cckp 发表于 2020-1-4 22:26
近日,华为操作系统 openEuler 正式开放源代码、镜像及开发测试环境。华为表示,作为项目主要筹备方,将会 ...


Linux 内核。。。
用了 Linux 内核,也不能闭源啊。




作者: 不点    时间: 2020-1-6 10:22
本帖最后由 不点 于 2020-1-6 10:36 编辑
wintoflash 发表于 2020-1-6 08:44
Linux 内核。。。
用了 Linux 内核,也不能闭源啊。

这些公司,里面的人才也很多,估计不会犯低级错误。公司有可能钻法律空子,但它会注意规避法律风险。它应该有法律顾问,以及与法律相关的部门。

对 Linux 内核,应该会是开源的。但操作系统的概念,有时候不是指内核,而是指一个类似于发行版的东西。而后者就没必要开源了。只需将其中的 kernel 部分(以及其他必须开源的部分)开源即可。


android 就是使用了 Linux 内核。android 开源,但却被谷歌控制。android 没有遵循 GPL 协议而开源。我的理解:就算是 android 要改成闭源的,也完全没问题。它只需要把 Linux 内核部分进行开源即可。


最近我认识到,授权协议的问题,不那么重要。对于像 google 这样擅长钻空子的公司来说,再严厉的授权协议也挡不住它使用巧妙的方法来规避风险。开源就是被公司利用的,根本就保护不了代码的贡献者以及广大群众的利益。


作者: 2013olly    时间: 2020-1-6 13:49
wintoflash 发表于 2020-1-6 08:44
Linux 内核。。。
用了 Linux 内核,也不能闭源啊。

gpl2许可的限制太弱了

别的不说,公布源码(源码里可能加入一些自己的广告后门啥的),但是自己的硬件添加签名验证,不是官方编译的内核拒绝启动,移除了自己加料后重新编译的内核不让用。这样做完全不违背gpl,但是却可以使开源的意义几乎彻底丧失。

gpl3就是在使用开源软件的硬件方面也进行了些限制,具体的了解不是很多
作者: 2013olly    时间: 2020-1-6 13:55
不点 发表于 2020-1-6 10:22
这些公司,里面的人才也很多,估计不会犯低级错误。公司有可能钻法律空子,但它会注意规避法律风险。它应 ...

被利用也应该比起完全不给代码好得多吧。

授权协议更严格,或许也无法彻底杜绝钻空子,但是相比完全闭源,至少给普通人的会多上一些
作者: 不点    时间: 2020-1-6 17:13
2013olly 发表于 2020-1-6 13:55
被利用也应该比起完全不给代码好得多吧。

授权协议更严格,或许也无法彻底杜绝钻空子,但是相比完全闭 ...

我不这么看。我看问题的角度,是从代码贡献者的原初目的来看的。代码贡献者希望代码被用于公众利益,而不是个别公司的私有利益。然而,钻空子的公司,却把代码通过一些手段、合法地用于公司的私有利益。它甚至反过来再打压原来属于 GPL 范畴的 Linux 操作系统,更进一步地伤害公众利益。像 Android 那样,开源或不开源,那是公司自己的事。它选择开源是为了它自己(放水养鱼),它选择闭源也是为了它自己(撒网捕鱼)——都是它自己的利益,与公众利益完全无关——而这个“公众利益”,恰恰是 GPL 代码原始贡献者希望成全的,因而,公司的行为也就违背了原始贡献者的意愿。公司挪用了公众利益而为其私有利益服务,从某个角度来看,这是一种抢劫或欺骗。而且,只要代码开源,无论采用什么协议,都是一样要被掠夺、被抢劫、被欺骗,根本就没法保证什么,没法保护公众利益。也因此之故,我也就不怎么再费劲地去区分各种不同的开源协议了。
作者: wintoflash    时间: 2020-1-9 09:50
本帖最后由 wintoflash 于 2020-1-9 09:59 编辑

https://github.com/SerenityOS/serenity
Graphical Unix-like operating system for x86 computers.
应该是宏内核的。
我上个月的时候编译测试了一下,bash 的源码按它的教程直接交叉编译之后放这个OS里面就能用。


作者: 不点    时间: 2020-1-9 12:05
本帖最后由 不点 于 2020-1-9 14:38 编辑
2013olly 发表于 2020-1-6 13:49
gpl2许可的限制太弱了

别的不说,公布源码(源码里可能加入一些自己的广告后门啥的),但是自己的硬件 ...
别的不说,公布源码(源码里可能加入一些自己的广告后门啥的),但是自己的硬件添加签名验证,不是官方编译的内核拒绝启动,移除了自己加料后重新编译的内核不让用。这样做完全不违背gpl,但是却可以使开源的意义几乎彻底丧失。

说得到位,抓住了本质。


GPL3 是更严厉的协议,我也没工夫研究它,它大致也就是想解决 GPL2 被巧妙用于私有利益的问题。但是,我认为,法网越密,漏洞越多。法律总是有漏洞的,总是可以被钻空子的。一个强势的公司,它即使打擦边球违背了什么法律条文,它也不一定能够受到惩处。判官可以受到贿赂,判决的结果,可以对它有利。要知道人类的语言都是模糊的。因此,法律也是模糊的。这就要看判官是谁了。黑的能说成白的,鹿都可以说成马。因此,我认为,GPL3 解决不了问题,甚至任何一个协议都解决不了问题。更可能的是,公司可以完全在原有协议的框架下,用巧妙的手段来掠夺。刚才说了,法律是模糊的(甚至可说,世上就没有严密的东西),因此,漏洞多得很。光是利用这些漏洞,就足以达到合法掠夺的目的,根本不用冒险去打擦边球。

好了,我已经说清楚了,任何开源协议都无法阻止公司把代码用于私有利益。

因此,我的结论就是,开源协议在客观上都具有“欺骗性”。此处要澄清,开源协议的原始提倡者可能不是骗人的。这里说的是,在现实世界的环境下,开源协议保护不了公众利益,它总是可以被掠夺、被抢劫、被盗取的。

公众从开源代码上也能获得一定的好处。但是,由于公众是不生产硬件的,最终的话语权只在生产者手上掌握着。也就是说,开源最终的受益者是公司,是生产者。公众获得的那点好处,在生产者看来,那都是小菜一碟,微不足道,是可控的。公司想让你了解一点东西,就放水养鱼。公司不想让你知道什么秘密的时候,就要对你开刀下手了。这主动权完全在生产者手上掌握着。所以,公众不要被骗了。开源最终“拐着弯”是为生产者服务的。


家里养几只鸡,或几头猪。你会喂饱它们。但你最终会杀掉它们,或卖给别人,让别人杀掉它们。在它们被杀掉之前,它们的日子可能还过得很不错,有吃有喝。


软件开源也是如此。拿到源代码的人高兴得不得了,就像鸡或猪见到食物了那样。但是,这是在厂商可控框架下的开源。厂商不会告诉你,它何时要封闭起来宰杀你。三十年前,厂商很开放,态度很友好。三十年后,厂商要从硬件底层推倒重来。当然,推倒重来的前提,是对厂商有利。厂商在三十年前没说三十年后要宰杀你,这不等于说厂商三十年后跟以前一样永远不宰杀你。就像你养鸡或养猪一样,基本可以确定,总是要宰掉的。厂商开源也是同样的道理,不管是三十年还是五十年,最后总有那么一天,是要宰掉你过年的。你蹦得越欢、跳得越高,厂商就越是对你感兴趣,会优先拿你开刀问斩。




作者: 不点    时间: 2020-1-11 20:19
wintoflash 发表于 2020-1-9 09:50
https://github.com/SerenityOS/serenity
Graphical Unix-like operating system for x86 computers.
应 ...

这个系统的发展速度是惊人的。才一年时间,就能这么完善。不知它是否支持 EFI。另外,在真实机的情况下,对于各种板卡、以及触摸板之类的外设支持得怎么样。

还有一个重要的问题,这种系统开发得好、进步得快,固然是好事,已经很不容易了;但是,如果这系统是由“别人”在开发而不是硬件生产者“自己”开发,则这样的系统,是没有安全保障的。说明白点,生产者有可能封杀这个系统。在开发的早期,还没有成什么气候的情况,是不会遭到封杀的。但在已经成熟、有一定威慑力的情况下,就可能被“连锅端”了。相比之下,由生产者(或者垄断控制者)开发的系统,就没有这个问题。当然了,垄断控制者开发出来的系统,容易让人产生不信任,这是另外一个问题。

作者: linuxdisk    时间: 2020-2-1 21:03
楼主有没有最新进展,看都是理论居多,实际可供下载的使用的有没有整理?
作者: 一笑笑    时间: 2020-2-23 10:49
关注,喜欢微系统
作者: gs358906    时间: 2020-3-18 11:38
跟着大家学习下
作者: 不点    时间: 2020-5-9 11:46
今天搜到这样一个 OS 概念设计:

https://github.com/wm4/dingleberry-os

作者对 “微内核” 颇有微词。不过感觉讲得很有道理,值得了解一下。我目前没有什么鉴别能力,无法作出判断。综合正反两方面的观点,得出的才会是比较全面的结论。

作者: 王少笑    时间: 2020-9-3 10:37
感谢分享!看看了解。
作者: hexj68    时间: 2020-9-7 21:20
微内核操作系统现在新出的有那些?
作者: 不点    时间: 2020-10-19 17:50
wintoflash 发表于 2019-11-29 21:30
https://github.com/HelenOS/helenos我第一次见到这玩意是在7,8年前,没想到现在还活着,还支持x86_64和IA ...

今天看了 helenOS 主页上的介绍,初步感觉很不错。我想知道 helenOS 是不是多用户的系统,不知 wintoflash 能否答复一下。也希望更进一步介绍一下这个系统。
作者: xbmc    时间: 2020-10-19 18:22
不点 发表于 2020-10-19 17:50
今天看了 helenOS 主页上的介绍,初步感觉很不错。我想知道 helenOS 是不是多用户的系统,不知 wintoflas ...

"HelenOS is a single user operating system, even though there has been some experimental work done on multiuser support."
作者: 不点    时间: 2020-10-19 18:47
xbmc 发表于 2020-10-19 18:22
"HelenOS is a single user operating system, even though there has been some experimental work done ...

十分感谢!
作者: 不点    时间: 2020-10-20 07:43


linux 是当今最成熟的开源操作系统。然而,在 linux 之外,新系统也在不断涌现,一些旧系统也在不断发展。这里面有个哲学、逻辑学问题。什么样的系统才是好系统?

有些系统,是某公司开发的。既然是公司开发的,这就带着公司的利益了,谁能否认这个?肯定不能否认。那就很自然地,失去了安全性。说得哲学一点,是对大众而言,失去了安全性,而对该公司自己,则是确保了安全性。

linux 当初就是个人开发的,代表的是大众利益,这才被公司之外的大众爱好者支持。无论是谷歌还是华为,或者其他任何一个公司,也无论生产出多么华丽的系统,其性质,跟微软没什么差别。为什么?因为都是公司啊!都代表着公司自己的利益。那么,难道说,公司就不可能像某个个人一样生产出代表大众利益的操作系统吗?从逻辑上讲,当然存在这种可能性。但现实中,这种可能性就很小了,可以粗略地认为不存在这样的可能性。

接下来就有这样一个问题:一个公司难道不应该为着公司的利益而努力吗?

当然,是应该的。但是,如果伤害了大众的利益,那就过分了。胳膊伸得太长,过网击球,是犯规动作。保护自己是对的,但伤害他人是要遭到抵抗的。

公司知道这些问题吗?当然知道,他们又不是傻子。他们就是想圈地,圈粉,期望能够像某种宗教一样,引来很多追随者。追随者多了,公司就赢了。

公司肯定有圈粉的能力。如果一个公司毫无圈粉能力,它就没资格做一个公司了,倒闭了,消失了,不存在了。

好的,被圈进去的人,就好比是信徒了,如果用个贬义词,那就是被洗脑了。而没被圈进去的人,还是自由身。

公司用它自己的高超技术,当然可以圈很多粉丝。人都是趋利的,都想去占别人的便宜。公司就是放水养鱼。在公司的诱饵面前,很多人都经受不住诱惑。刚开始,只有诱饵,没有鱼钩。后来某一天,就可能时不时地带上鱼钩了,甚至关起门来,一网打尽。

linux 当初确实是干净的,距离公司很远。但是,后来,可就变了。以前已经说过,庞大的 linux 内核,已经被偷偷地污染和占领。

宏内核本身不是一个错误,有人论述,宏内核比微内核好。当然也有人说微内核比宏内核好。不纠缠这些。但里面塞入间谍代码,这就是个错误了。

不管是什么内核,都不可以塞入间谍代码。包罗万象的宏内核,公司们以增加功能为理由,塞入不易察觉的木马,这就是不可接受的了。能看到这一点,并不容易,尤其是对于一个技术平平的人来说。我还没被洗脑,或者至少说,我没被彻底洗脑。技术只要有一点点就行,再加上头脑中有较强的敏锐度即可。

rwx 这种权限设置,被人后来用 ACL 扩充、强化。有两种可能性。其一,rwx 确实不够用,需要扩充,需要引入 acl 机制。其二,rwx 凑合着够用,只是在若干极端情况下显露出某些不方便之处,但某公司就夸大这种所谓缺点,而给内核打所谓的补丁,目的是塞入木马。

我倾向于认为是后者。

作者: tjlf0    时间: 2020-10-20 09:04
向各位大佬学习!
作者: 不点    时间: 2020-10-20 11:45
Linux 属于 UNIX 家族。UNIX 讲究 “简单即美”。


然而,rwx 融入文件系统,并不合乎 “简单即美” 的逻辑。权限管理,和文件管理,是两件不同的事情,应该分开处理,才符合 “简单即美” 的逻辑。


UNIX 是较早出现的,DOS、Windows 是后来出现的。然而,最早普及开来的,是 DOS、Windows。再后来,UNIX 的新成员 Linux 出来了,在应用层面,几乎看不到与 DOS、Windows 有什么差距,甚至有时会比 DOS、Windows 更好。在服务器方面,Windows 也并非没有市场,只不过 Linux 开源、免费罢了。Windows 同样具有多用户的功能特性。Linux 与 Windows,两者在应用层,差别越来越模糊,或者说,差别在逐渐消失。


那么,我就思考了这样一个问题:Windows 没有 rwx 权限,照样是 “什么活都能干” 呐!包括多用户的管理功能,也都没有缺少啊!这是否暗示:多用户管理,不需要用文件系统中的 rwx 来实现?就是说,没有文件系统中 rwx 的设置(包括 suid,guid 等逻辑位的设置),照样可以实现多用户管理。


好的,世上没有绝对的真理。以上的思考和论述,又一次佐证了这一点。要破除迷信,破除成见,敢于开拓,敢于创新。


假如 Linux 不要求文件系统必须具有 rwx 权限位设置的话,一个附带的好处是,Linux 可以自由地安装在 Windows 的 D: 盘或 E: 盘之类的盘上(作为 root 文件系统,即,根文件系统),而依旧保持 FAT32 或 exFAT 或 NTFS 文件系统,这就更有利于普及 Linux 了。当然,这仅仅是个想法,至于说能否实施、如何实施,那是技术问题。


下一个问题,DOS、Windows 先普及开来,然后,Linux 作为 UNIX 的一个代表,跟上来了,而且,富有成效,跟 Windows 可以媲美。于是,就很自然地提出这样一个问题:这种情况,难道只有 UNIX 才行吗?换成别的 “非 UNIX” 的系统,就一定不行吗?就一定不能像 Windows 那样成功吗?



没人证明。既然没人证明,那就是:有可能行,也有可能不行。


所以说,没有绝对的真理。我们还是应该破除迷信,消除成见。一切皆有可能。不要把自己禁锢起来,要敢于想象,不要让自己的思维溺死在漩涡里面!


就是说,像 HelenOS 之类的 “非 UNIX” 系统,照样有成功的可能性!决不是 “一点可能性都没有” !那就要看每个系统各自的发展状况了。



作者: 王少笑    时间: 2020-10-21 14:42
不点大师说得有道理!
作者: wintoflash    时间: 2020-10-25 20:14
Genode OS Framework https://genode.org/
我关注这个项目很长时间了。它本身不能算是一个 OS,而是一个框架,实现了类似 "兼容层" 的东西。
它有一套自己的API,带一套独特的GUI,可以跑各种软件,而它本身可以在很多微内核上运行。
支持的微内核有 NOVA, seL4, Muen等。也支持 Linux,甚至还可以不用这些内核,直接裸机上跑。
根据用的不同内核,支持 ARM, IA32, amd64, ppc 等架构。
由于它实现了一套兼容层,所以驱动问题还是比较好解决的,编译的时候可以选择集成 Linux, FreeBSD 的驱动。

Genode OS 在设计上主要是用来搞虚拟化的,可以跑 VirtualBox。

作者: 不点    时间: 2020-10-26 11:41
抱歉,我又想谈哲学。

Genode 反映的就是一种哲学。Genode 是先发明一个套子,然后再去装东西。先有理论,然后再按照理论,作为模板,去生成一个个的个体。这种方法,大致叫做 “演绎”,与 “归纳” 的方法是相反的。

从哲学、逻辑学上讲,归纳和演绎都是必要的,没什么好不好的。

然而,在现实中,我对演绎法,有某种说不清楚的抵触,也许是我比较反感动不动就制造规范,这些规范,大多都是利益集团或垄断控制者制造的,用来捆绑(或束缚)软件开发者们的。规范形成之后的某一天,他们不是维护规范,而是要抛弃规范,甚至是故意破坏规范,只要他们觉得那样做对他们有利。

本人没有技术,因此不谈技术。本人就想提醒那些有技术的开发者们,要有自己的头脑,要有自己的分析,不要被别人洗脑,不要上了贼船,不要掉进人家设置的陷阱。

西方通常是讲求个性自由,发挥个人的优势。比如,莫扎特、贝多芬;比如牛顿,爱因斯坦。也就是说,西方一般都是采用归纳法的,由个体发展到整体。有句话说,只有民族的,才能是世界的。这也是在讲归纳法。

而如果一上来突然就来个理论,那么这个理论,就可能是个紧箍咒了。

在 IT 技术领域,很多东西都打上利益的烙印,其实技术本身并未成熟,并未形成理论。在这种情况下,通常是由利益而决定着必须采用演绎法,而不是归纳法。如果不是由于利益,而是由于技术的发展逐步形成成熟的理论,那倒是可以很自然地会用演绎法来指导实践。但 IT 技术领域,通常都是利益决定一切的。因此,一个没有防备的人,尽管你可能很聪明,但也很容易被洗脑,是 “大概率” 会被洗脑。


作者: 不点    时间: 2020-10-27 10:30
因此,我最近比较倾向于那些所谓 “多元化” 、“碎片化” 的操作系统。

合久必分,分久必合。

过去的二十年,虽然有一些 “分化”,但那并不彻底,而且很短暂,需要进一步分化。

那些分化了的若干个系统,最后都在朝着有利于几个巨头的统一而变化。这些巨头之间,已经达成某种妥协,就像原先的一个垄断巨头那样。就是说,多个垄断巨头,官官相护,最终的效果,就很像是原来的某一个垄断巨头的情况。

因此,那种分化,不够彻底,不能促进技术的进步。

也因此,需要进一步的分化,达到碎片化的程度,让任何一个公司也无法控制软件规范。只有脱离了控制,才有百花齐放。不经过百花齐放这个阶段,就意味着垄断控制的继续,就意味着不能解放生产力,以及不能充分释放创造的力量。

作者: 剑客行    时间: 2020-10-28 11:00
碎片化的操作系统?
linux够碎片化了,但是软件兼容是个问题了。
作者: 不点    时间: 2020-10-28 11:24
剑客行 发表于 2020-10-28 11:00
碎片化的操作系统?
linux够碎片化了,但是软件兼容是个问题了。

碎片化就可能没法保证兼容。当然,也不一定就完全排斥兼容性。

这只是一种想法,一种思路。需要有人去做才行。

思路本身,仅仅提供一种可能性。不认同的人,当然不需要去做任何工作。

作者: wintoflash    时间: 2020-10-30 18:36
不点 发表于 2020-10-26 11:41
抱歉,我又想谈哲学。

Genode 反映的就是一种哲学。Genode 是先发明一个套子,然后再去装东西。先有理论 ...

并不完全认同。这是一个 "鸡生蛋还是蛋生鸡" 的问题。
当然是先有了 linux kernel, NOVA, L4 这些 OS kernel,后来才有了 Genode。NOVA 早就死了,现在基本上都是 Genode 的开发者在维护,他们想把它弄成啥样当然是他们的自由。
而如果一上来突然就来个理论,那么这个理论,就可能是个紧箍咒了。

UEFI 才是这种东西。但是 UEFI 也不完全是从空中楼阁开始的。

我是做科研的,从历史上来说很少有完全凭空出现的一套理论。一般那些一开口就说自己发现了一套 “拳打相对论 脚踢量子力学” 的理论的人,不是疯子就是骗子。
作者: 不点    时间: 2021-4-16 06:59
时至 2021 年 4 月中旬,发现 helenOS 已经偷偷地支持了 riscv64。
https://github.com/HelenOS/helenos/tree/master/kernel/arch/riscv64/src

作者: 王少笑    时间: 2021-4-16 12:08
关注着微内核
作者: wintoflash    时间: 2021-4-16 13:15

SylixOS
https://www.sylixos.com/
实时操作系统
支持 x86 (amd64), ARM, ARM64, MIPS, RISC-V 等
GPLv3 许可
看内核设计,应该是宏内核。(我不是专业的,仅供参考)

LK (Little Kernel)
https://github.com/littlekernel/lk
微内核
支持 x86 (amd64), ARM, ARM64, MIPS, RISC-V 等
开源
fuchisa 在最初就参考了 LK 的一些设计。
目前主要在 android 手机上作为 bootloader 使用。

Miray Symobi
https://www.miray.de/products/rtos/symobi.html
主要用于 IoT 领域
商业 闭源
支持 x86 (amd64), ARM, PowerPC
我前段时间用了 Miray 的硬盘克隆工具 (https://www.miray.de/products/applications/hdclone.html),还以为是基于 Linux 的。
后来仔细看了一下,结果发现用的是他们自己研发的系统。在我的机器上,蓝牙、Wifi 竟然都能正常使用。
我看到它的文档里面提到自己的操作系统用了一些 GPL 协议的组件,于是我向他们公司发了封邮件,要求他们提供这一部分的源代码。
结果过了两天,他们真的把这部分源代码发给我了。



作者: 不点    时间: 2021-4-16 16:49
目前我并不太过于追求微内核里面的 “微”。说实在话,“微” 这个概念、词汇,与人类的其他概念、词汇一样,是模糊的。所以,没有绝对的“微”,只有相对的。

只要像 “小孩子上学” 一样,分出层次,分出“年级”,逻辑性强,具有艺术性、合理性、又比较优美,那就 OK。不必要纠结它是否属于严格的 “微内核”。

目前我似乎觉得 HelenOS 就比较理想。有时间了再学习其他几个 OS。

作者: 不点    时间: 2021-4-22 07:00
本帖最后由 不点 于 2021-4-22 18:00 编辑

今天又想到了一个方面的重要问题,害怕丢手就忘,赶紧写出来。

操作系统不是孤立的。

但凡操作系统,它都是与硬件相联系的,或者说,与硬件绑定的。不存在脱离硬件的操作系统。抽象的操作系统概念,当然是存在的。但是,实现出来的操作系统实例,则肯定是与硬件绑定的(可以与多种不同架构的硬件绑定),是配合硬件的,也或者说是服务于硬件的。

操作系统依托硬件这个根基而存在。

没有硬件,就没有操作系统。

好的,这里已经把主次弄清楚了,硬件是“主”,操作系统(软件)是“次”。

“主”,就是“主控”,是“控制按钮”。这里已经浮现出“恶意”一词了。

在恶意的控制按钮之下,任何开源的操作系统,都没有太大意义。恶意控制按钮,它跟你的开源操作系统是敌对的关系。你想服务好它的硬件,那对不起,它不配合你,专门让你服务不起来。偶尔,在某种前提下,它会让你的开源操作系统苟延残喘,但到了该宰杀你的时候,就毫不留情了。

就是说,恶意的硬件制造商,它只适合自己生产操作系统以及应用软件。那些跟它没有利益绑定关系的开源作者们,不该为它生产操作系统以及应用软件。

好的,那么,谁是恶意的硬件制造商?这个问题暂不讨论。但可以先从哲学的角度来说明。恶意是相对的。一个制造商,有时候,它的恶意,表现得很明显,有时候,没有表现出恶意。换一种说法,不可能完全没有恶意,也不可能完全都是恶意。

如何判断某个制造商是不是恶意?不要问别人,你自己是判官。你要是连这都判断不出来的的话,那你还有能力生产操作系统吗?八成玄了吧。


这里顺便说说,有的人很认真,他懂得挑我的哲学毛病(或逻辑学漏洞)。他注意到,我经常讲,xxx 是相对的,xxx 是模糊的,世上没有绝对的东西。他反问我:你这句话能这么肯定,那么这句话本身是绝对的吧?


好的,世上没有绝对的东西,世上没有清晰的概念。此类言论或判断,都是相对的,也都是模糊的。人类没有任何一个概念是清晰的。全都是经验的。你经验到的概念,你了解;你未曾经验到的东西,你连了解都不会有。东南西北,上下左右,是非好歹,等等,全都是经验。上述说的这一堆话,全都是模糊的,不可以去“追本溯源”、企图“弄个明明白白”;如果非要去追的话,追来追去,其结果,在一大堆模糊概念中兜圈子,形成无限循环,不会有什么清晰的认识。这里没有自相矛盾之说。一堆含糊不清的概念,只能得出含糊不清的认识,没有什么自相矛盾。试图把含糊的东西清晰化,这才产生自相矛盾。假如你本来就知道这在本质上都是含糊的,不可能绝对化、清晰化,那你也就不会遇到自相矛盾了。著名的数理逻辑悖论,其根源也就在于企图把所有的概念进行绝对的清晰化,于是大自然就给出一个无法解决的悖论予以惩戒,或者说,间接地告诉了你,绝对清晰化的努力是要失败的。









欢迎光临 无忧启动论坛 (http://bbs.wuyou.net/) Powered by Discuz! X3.3