对<王垠:一种新的操作系统设计>一文的批评(2)
十年前的你和十年前的我
对于之前的文章,我很高兴你能看到,并且在你的博客中对之前的文章做了相应的修订和扩充(虽然我觉得这只是这些观点变得越来越离谱)!
你觉得这是十年前你的思想(言外之意是这些言论是陈旧的,迂腐的,你想的比任何人都高远),但是要说经历,或许我完全跟你相反, 总的来说:我觉得你或许是从实用主义成长为理想主义,而我,则从理想主义退化成实用主义!
如果要给自己贴标签,我觉得是一个Java程序员,过去很长一段时间里我习惯用Java的思维去思考问题,对于底层的实际的东西总是充满不屑;
几年前,在我完全不了解"计算机是怎么一回事儿"的时候,就开始幻想你文章写的那些不切实际的东西! 我甚至跟朋友讨论过如何将Java虚拟机改"装成一个操作系统",我的想法是面向用户的,是面向如何让用户更简单的跟计算机交流的,我认为Java程序员不需要负责底层东西,比如在分布式环境下,程序员不需要关心计算被具体安排到哪些节点运行,不需要知道在哪个地方存储,何时被同步到外存,不需要出现错误之后手动恢复...,不需要担心除业务之外的任何问题!环境提供这样的能力,就像进程调度一样,任务被在合适的时间的指派到空闲的节点,数据自动的被同步到合适的存储....
冠冕堂皇的总结一下其核心"哲学"是:我们是主人,计算机是仆人,只需要对他下命令;我们是上帝,可以简单的控制一切!
这是我犯过的错误,所以看到你的"11条设计"就特别有感触,在别人身上看到自己人性的弱点与之前犯过的错误,让我感到恐惧与不适,于是我决定给你写第一封邮件!向你说明至少在目前环境下有些问题的解决在于计算机理论的革新,在现有的情镜下讨论这些问题是没有意义的!
我粗略的看了一下你关于"计算机语言"的几篇文章和论述,我觉得还不错,但也都只是停留在表层,用到的也只是你所谓教科书上的"陈词滥调",没有实际你所谓的哲学层次的升华,我看的是你的博客,我没看过你的论文,甚至没看过你的英文博客,所以我原谅你了,但是,关于操作系统的那一片,让我有种"不食人间烟火"的感觉,觉得这不是一个懂操作系统的人写出来的!至少这不是一个搞了多年学术的人写的文章(当然,我不知道你是否搞过学术研究,我只是那么觉得!)至少至少..任何一个严谨的学者或者将自己标榜为学者的人都不会拿这样一篇文章管他称为一种"设计"的!
事实上在此之前,我并没有听过你的大名,后来在社区中听到你在10年写了几篇关于Linux的文章引起了很大的反响,我对L&(or)W的争论并不感兴趣!对"工具",我不会融入个人情感!我认为习惯用什么就用什么,适合用什么就用什么,喜欢用什么就用什么!当然如果别人愿意或者需要我也会乐意推荐给他!
但我对此(引起轰动这个事件)是有看法的,我觉得"这个社会缺乏包容!"!幸福的西朝鲜49年以后,"美"这个概念就被政治化了!革掉一切非主流的命是这个社会的常规思维!
在这个世界上会有很多奇奇怪怪的人,他们的奇奇怪怪的想法不被人认可和接受甚至受到打压.多元化的世界才是一个美丽的世界,思想和观念的碰撞才会创造新的价值!疯不疯是相对,在"疯子"眼里,他或许有自己的一套世界观,在他眼里是合理的,别人看不透是因为他没有达到这个境界!(尼采就是个疯子,或许他一开始就是个疯子!)
所以,首先我并不否定你的任何观点,我相信以及我也承认我对操作系统的观点是非常狭隘和陈旧的!
我不是个宿命论者,我觉得一切事情都可能发生(包括以上我也提过我曾和你有一样理想主义的想法!)!我没对任何东西做出任何评价,不对任何人喜欢或者厌恶的事情品头论足是一种美德! 但就技术水平而言,我认为是一个可以探讨的范畴!
就这两篇文章而言:我跟你讨论的是你设计的"可行性"!我希望你在现实的基础上给出一个明确的指导或解决问题的方案!而不是天花乱坠的描述美好的愿景!然后将它视为一种设计洋洋得意!
刚开始我准备对你的11条设计逐一批判,找出他们不切实际的地方!后来我觉得这11条设计中有很多思想和概念是重合的,所以我总结了一下,虽然不是很完全(也不知对你观点的总结是否到位),但这七条内容几乎应该囊括了大多数你提出的概念!
由于没有太多的时间,我决定找出几个点来简单论述(之前的文章就是这样来的)!而这第二篇文章是之前观点的简单补充(虽然我觉得还是罗里吧嗦,没有把问题讲到点上!),然后提出几个实际需要解决的问题!
如果可能,在之后的第三篇中,我将会跟你讨论"上帝语言"的可行性和我在构建一种编程语言的过程中碰到的实际问题和困难!然后会对你提出的11条操作系统的设计逐一提出批判和疑问!
当然其中逻辑和某些概念上有意或者无意的错误和混淆,希望得到谅解!
@Brin想写程序 对我说:"计算机语言就是完美的操作系统这句话没问题。 如果你从代数系统，群，图灵机，机器码，汇编，操作系统，计算机语言，数据库。一路看上来就明白了。"
而我认为:问题不在于操作系统概念的的定义,而是在于哪些问题需要在什么层次解决!比如:计算机硬件负责提供基本计算能力和存储等资源;操作系统负责管理他们;而某种计算机语言负责提供相对友好的用户接口,用户程序负责解决实际问题!(这是一个严谨合理且禁得起考验的层次分类!界定操作系统的边界,分清楚操作系统应该做什么,不应该做什么是首要解决的问题,而不是为了其他原因必须迂腐的给操作系统下一个定义!!)
在我看来有些概念不应该是操作系统要考虑的,更不是计算机硬件要考虑的!
进程和函数续
把这两个概念放在一起论述让我自己感觉有点尴尬和好笑,其实我的论述主要是这一点:去除"进程"这个概念,你必须要用另外一种机制代替它!
数学意义上的"函数"是个一一对应的概念:y=f(x),给定X的值,Y就一定.然而计算机语言意义上的函数却不是,他可以是一对多的关系(多数情况下还是上下文相关的), y的值并不固定,可以简单的将它分为(可以细分):
不受环境影响和不影响环境的数学意义上的函数:
int fun(int x){return x+1;}影响环境或者受环境影响(或者两者都是)的函数:
操作了"静态"或者"环境变量"或者"某些共享数据"的函数和一些随机函数(受到环境中随机数发生器的影响)就是这种;
于是我们是否可以这么认为:计算机语意下的函数在不同时间调用,产生的结果是不可预料(或者说随机的)?
把计算机意义的"函数"转化成数学意义的函数
如果是这样的论述,我觉得时间这个维度就必须被考虑进去;
把这个函数变成一个数学上一一对应的函数应该是这样: y=f(x,time)
time表示时间对函数的影响,其中time固定,环境就固定,如果保证x的值固定,得到的输出y必然也是固定的,于是在数学意义上他是个简单的二元函数;
进程简单的利用时间分片和某种优先级机制(比如固定优先级,竞争...)进行调度,我们只需要简单的在外面同步进程就能让time参数固定,或者按照我们的预料,这样就能"保证y是预料之中的"!
去掉了"进程,任务"和调度机制,让time随机,事情就变得不可预料;为此,必须使用另外一种机制保证time的确定性;
我的问题是:在你的设计中,这种机制是什么?如何控制time对函数的影响?是让用户自己同步设置time的值?你所谓的微小函数之间是如何并行运行的?如果在无限计算能力的CPU上,微小函数执行不需要时间的假设下,这或许是可行的!如果让所有的函数都串行执行变成早期的单任务系统,"或许"也是可行的!
注:以上论述或许有些啰嗦,也或许还是没有阐述明白!现有的进程机制并不是最完美,但是在没有最完美的方案之前,次完美的方案就是最完美的!我觉得如果你解决了这样的问题才有资格说你超越了Unix哲学!
结构化参数问题与可行性的怀疑
结构化参数有必然的好处,但是其"适用性"将得到很多限制,不同语言之间的调用必然存在"调用规约"的问题,不同系统之间必然存在"编码解码","协议"和"加密",的需求,甚至不同机型存在"大端序-小端序"这样的历史问题也需要系统进行容恰;在保证上帝语言的前提下某些问题或许可以得到解决,但毕竟存在诸多历史限制,(历史问题也是需要解决问题的)!
多数现代系统都选用了"不解释,不争辩,忽略"的粗暴手法,其思想是"系统不负责这些问题的处理,你有需要你自己实现解码编码的过程,你可以把数据解析成任何东西赋予任何语意"!无语意的二进制数据是最能满足的需求的,具体对二进制数据的解析,是用户程序的事情,也应该是用户程序的事情,系统包办的可能性为0!
现实中结构化数据传递的方法:
现实中结构化数据的传递方案其核心思想归纳一下无非就是 "元数据"和"规约"(我认为元数据和规约的本质和思想是一样的,所以在此不做区别!)我们可以认为某种编码规范是元数据(规约),某种格式是元数据,数据库表的定义是元数据,类型的定义是一种元数据等等;
其核心流程也无非是根据"规约限制"和"元数据"对序列化后的数据进行"重新构建"!
这样的方法适用在任何场景的前提是"元数据"是可计算的!元数据是可以的递归定义或者通俗的说是"可用算法描述的"! 我感性的认为"元数据"并不是一个递归集合,他的形式取决于他出现的场景!取决于创造他的人的心情!取决于政治和商业利益!
对于以上论述我的结论是:除非你给出元数据是一个递归集合的证明,或者抛弃使用元数据另辟蹊径找寻另一种方案(比如,使用一种可计算的超元数据作为规范去描述数据!)再或者你用人工智能让计算机自己就能理解数据的定义,不需要任何东西去描述数据!否则普世的结构化方案不存在的!
通用化方案必然存在诸多限制和性能损耗:受限于物理硬件和传输,结构化的数据在不同的节点传输数据的时候需要将结构化的数据序列化,举个例子(不知道是否合适):比如使用Java RMI的远程过程调用,对象被序列化,然后传输,然后反序列化; 首先对象之间的依赖关系在内存中构成一个图,这必然存在很多回环(对象相互引用的问题,直观的问题是造成程序死循环),确实是有办法检测这些环的,但是无疑是有性能消耗的!像这样的问题这在操作系统级别上是不可以忍受的(至少我认为是)!将解析交给用户的好处是,用户自己按照需求指定"最优方案"!
我一向这么认为:通用的必然不是最好的!这个世界上必然不会存在一条定理适用于任何场景(对于计算机而言,越底层的东西越应该具体化)!