点评一下王垠的新博文: Oberon 操作系统:一个被忽略的珍宝
2013-03-08 16:31:26
原文链接:
http://blog.sina.com.cn/s/blog_5d90e82f0101iq0n.html
主要是针对文中所说的各种特性,分别做一注解
王垠这篇文章也相当不错,他不在于说了什么好,什么坏,而是在于说好坏的时候展现出了很不一样的视野和水平,这比具体观点要重要得多,至少他看到了很多人根本看不到或者根本觉得不值一提的一些东西,而这些东西非常重要.
我不是要说这个系统也不怎么样,恰恰相反,这样的系统才是正确的方向,
也是为了解答这样的疑惑,既然都说得这么好,那么为什么用的人会这么少呢?
不需要为这些系统愤愤不平,认为软件业界都不识货,越先进的越没人理,不是这样,真正的原因是这些设计中的软肋,甚至是命门,阻碍了这样的系统在市场中成功.
1 这种系统里面的程序间通信不使用无结构的字符串,而是使用带有类型和结构的数据。在这样的系统里面,“程序”的概念基本上完全消失。系统由一个个的“函数”组成,每个函数都可以调用另外一个函数,通过参数传递数据。每个函数都可以并发执行。
点评: 这种让程序的界限消失,让所有函数都暴露出来,首先命名空间的冲突是个很大的问题,其次是效率.其实,之所以要有应用程序的概念,是模块化解耦合的需要,在应用程序内部的交互很多很复杂,但应用程序与外界的交互相对较少.其次,是省略上下文的需要,当你操作一个程序时,就进入了这个程序的上下文,无需再额外加上标识.真正的解决办法是保留概念,但换一种构造方法.
2 由于参数是一个数据结构,而不是字符串,这避免了程序间通信繁琐的“编码”和“解码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理特定类型的数据,这使得像 “OLE 嵌入”这样的机制变得及其简单。
点评: 数据结构依然难以承担传达信息的作用,unix之所以使用字符串,一个原因应该在于字符串是去类型化的,做到了最大程度的松耦合,一旦在交互中引入类型,事情往往变得复杂起来,有时候复杂到失控.
3 所有函数由同一种先进的高级程序语言写成,所以函数间的调用完全不需要“翻译”。
点评: 底层统一,让操作系统成为某个单一语言的运行时,这都是很高明的思想,但"翻译"问题依然是存在的,因为不同的知识领域会发展出不同的DSL,但如果这些DSL都是由同一种高级语言构造而来,互相兼容就变得轻松许多.
4 由于这种语言不允许应用程序使用“指针运算”,应用程序不可能产生 segfault 一类愚蠢的错误。由于没有指针运算,系统不再需要现代处理器提供的“内存映射”机制,以及 TLB。这使得内存访问效率大幅提高。而且简化了处理器的设计。
点评: 这是一个错误,也可以说是一个命门,正是这样的设计让类似的系统在市场中毫无竞争力.这个命门就是效率,不对用户提供指针操作和按地址访问,根本无法做到高的效率.这不会因为硬件性能的提升而缓解,而是一直存在,也将永远存在下去.事实上,已经至少有一个语言做到了通过比haskell还强的类型系统,在提供指针操作的同时保证指针操作的正确性,错误的操作不会通过类型检查.
5 操作系统使用与应用程序相同的高级语言写成(可能需要支持一些“特权操作”),至于“系统调用”,只不过是调用另外一个函数。
点评: 系统和应用的关系不是这么简单,系统调用不仅仅是调用另外一些函数的问题,系统如何对应用隐藏自己的实现,在FOP方法中是通过所谓的遮罩来实现的.
6 操作系统的“shell”,不过是一个这种高级语言的 REPL。用户可以在终端输入各种函数调用,从而启动进程的运行。
点评: 也不是那么简单,当然文章都不可能说得太详细,放过.
7 系统不需要 SQL,不需要关系式数据库。所有的数据都作为“对象”,保存在一个分布式的数据空间。
点评: 很难说这点是错是对,但"对象"思维是错的.
8 系统不需要“文件系统”。所有的数据,包括“进程上下文”自动被“版本控制”,在合适的时候作为对象同步到磁盘。所以即使在机器掉电的情况,绝大部分的数据和进程能够在电源恢复后自动继续运行。
点评: 这个是精华.但问题是依然在用对象,也是用"事物"来思考,而不是以关系的方式来思考.既然提到了版本控制,对用户来说,操作系统完全可以把从安装开始,一直到当前的所有状态都保存下来,任何时候都可以把这台电脑的所有操作过程从头到尾播放一遍.
9 程序员和用户完全不需要知道“数据库”或者“文件系统”的存在。程序假设自己拥有无穷大的空间,可以任意的构造数据。
点评: 这是对的,很多细节需要对用户透明.用FOP的话来说,用户只需要管逻辑关系.
10 为了减少数据的移动,系统根据数据的位置,选择: 1)迁移数据,或者 2)迁移处理数据的“进程”。程序员不需要使用 MapReduce,Hadoop 等,就能进行大规模并行计算。
这个操作系统是如此的“一致”,以至于所有的用户和程序员,只需要学会一种很简单的程序语言。
点评: 前面这句太具体,属于具体优化策略,放过.但后面那句是不对的,原因在于存在DSL.
主要是针对文中所说的各种特性,分别做一注解
王垠这篇文章也相当不错,他不在于说了什么好,什么坏,而是在于说好坏的时候展现出了很不一样的视野和水平,这比具体观点要重要得多,至少他看到了很多人根本看不到或者根本觉得不值一提的一些东西,而这些东西非常重要.
我不是要说这个系统也不怎么样,恰恰相反,这样的系统才是正确的方向,
也是为了解答这样的疑惑,既然都说得这么好,那么为什么用的人会这么少呢?
不需要为这些系统愤愤不平,认为软件业界都不识货,越先进的越没人理,不是这样,真正的原因是这些设计中的软肋,甚至是命门,阻碍了这样的系统在市场中成功.
1 这种系统里面的程序间通信不使用无结构的字符串,而是使用带有类型和结构的数据。在这样的系统里面,“程序”的概念基本上完全消失。系统由一个个的“函数”组成,每个函数都可以调用另外一个函数,通过参数传递数据。每个函数都可以并发执行。
点评: 这种让程序的界限消失,让所有函数都暴露出来,首先命名空间的冲突是个很大的问题,其次是效率.其实,之所以要有应用程序的概念,是模块化解耦合的需要,在应用程序内部的交互很多很复杂,但应用程序与外界的交互相对较少.其次,是省略上下文的需要,当你操作一个程序时,就进入了这个程序的上下文,无需再额外加上标识.真正的解决办法是保留概念,但换一种构造方法.
2 由于参数是一个数据结构,而不是字符串,这避免了程序间通信繁琐的“编码”和“解码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理特定类型的数据,这使得像 “OLE 嵌入”这样的机制变得及其简单。
点评: 数据结构依然难以承担传达信息的作用,unix之所以使用字符串,一个原因应该在于字符串是去类型化的,做到了最大程度的松耦合,一旦在交互中引入类型,事情往往变得复杂起来,有时候复杂到失控.
3 所有函数由同一种先进的高级程序语言写成,所以函数间的调用完全不需要“翻译”。
点评: 底层统一,让操作系统成为某个单一语言的运行时,这都是很高明的思想,但"翻译"问题依然是存在的,因为不同的知识领域会发展出不同的DSL,但如果这些DSL都是由同一种高级语言构造而来,互相兼容就变得轻松许多.
4 由于这种语言不允许应用程序使用“指针运算”,应用程序不可能产生 segfault 一类愚蠢的错误。由于没有指针运算,系统不再需要现代处理器提供的“内存映射”机制,以及 TLB。这使得内存访问效率大幅提高。而且简化了处理器的设计。
点评: 这是一个错误,也可以说是一个命门,正是这样的设计让类似的系统在市场中毫无竞争力.这个命门就是效率,不对用户提供指针操作和按地址访问,根本无法做到高的效率.这不会因为硬件性能的提升而缓解,而是一直存在,也将永远存在下去.事实上,已经至少有一个语言做到了通过比haskell还强的类型系统,在提供指针操作的同时保证指针操作的正确性,错误的操作不会通过类型检查.
5 操作系统使用与应用程序相同的高级语言写成(可能需要支持一些“特权操作”),至于“系统调用”,只不过是调用另外一个函数。
点评: 系统和应用的关系不是这么简单,系统调用不仅仅是调用另外一些函数的问题,系统如何对应用隐藏自己的实现,在FOP方法中是通过所谓的遮罩来实现的.
6 操作系统的“shell”,不过是一个这种高级语言的 REPL。用户可以在终端输入各种函数调用,从而启动进程的运行。
点评: 也不是那么简单,当然文章都不可能说得太详细,放过.
7 系统不需要 SQL,不需要关系式数据库。所有的数据都作为“对象”,保存在一个分布式的数据空间。
点评: 很难说这点是错是对,但"对象"思维是错的.
8 系统不需要“文件系统”。所有的数据,包括“进程上下文”自动被“版本控制”,在合适的时候作为对象同步到磁盘。所以即使在机器掉电的情况,绝大部分的数据和进程能够在电源恢复后自动继续运行。
点评: 这个是精华.但问题是依然在用对象,也是用"事物"来思考,而不是以关系的方式来思考.既然提到了版本控制,对用户来说,操作系统完全可以把从安装开始,一直到当前的所有状态都保存下来,任何时候都可以把这台电脑的所有操作过程从头到尾播放一遍.
9 程序员和用户完全不需要知道“数据库”或者“文件系统”的存在。程序假设自己拥有无穷大的空间,可以任意的构造数据。
点评: 这是对的,很多细节需要对用户透明.用FOP的话来说,用户只需要管逻辑关系.
10 为了减少数据的移动,系统根据数据的位置,选择: 1)迁移数据,或者 2)迁移处理数据的“进程”。程序员不需要使用 MapReduce,Hadoop 等,就能进行大规模并行计算。
这个操作系统是如此的“一致”,以至于所有的用户和程序员,只需要学会一种很简单的程序语言。
点评: 前面这句太具体,属于具体优化策略,放过.但后面那句是不对的,原因在于存在DSL.
转载于:https://blog.51cto.com/584250550/1243912
10 为了减少数据的移动,系统根据数据的位置,选择: 1)迁移数据,或者 2)迁移处理数据的“进程”。
.迁移处理数据的“进程”才是王道
"进程"(代码)和"数据"无法区分,所以两个是一回事
正是持有你这个观点才选2的,2比较符合你这个定义,1的话普遍的定义仅仅是个数据字段
嗯
所以,他说的"并行"通过迁移"进程"确实可以简单实现,可以实现一个不需要干涉(但可干涉)的“平行时空”,这样一来那个“时空”(运行时)里不需要预先知道将会接收到什么具体的“物质”。1的话,很明显指向典型的RPC,需要预先定义好“面包机”、“咖啡炉”、“绞肉机”等等任何可能要用到的工具。
> 我来回应