知乎

因为Linus可以把这些乱七八糟的东西全都一个人写了,一遍写对了,还能稳定跑起来无bug

而我们这些渣渣做不到,只能依靠保护模式来防止几百个工程师写出来的那一坨垃圾动不动蓝屏,自己弱却去质疑天才的做法,和明知自己弱还要模仿天才的做法,都是认不清现实的表现

工程这个东西是很有意思的

我们说科学是掌握规律,技术是利用规律克服大自然的限制,而工程,却是利用技术来克服人自身的限制

技术告诉你,造个金字塔,把石头垒成四棱锥就行了

如果你是个力大无穷的巨人,或者是个能意念移物的魔法师,你就啪啪啪把石头搬过来堆起来就完事了

但我们是凡人,我们力量很小,我们很弱,所以我们需要滚木,需要滑轮,需要绳索来帮忙,做了许多额外的麻烦事情,只为了克服我们肉体的自身限制

体力上有限制,智力上同样有限制,软件工程很大程度上就是解决我们人类智力上限制的问题

软件工程师在面对不知所谓的kernel dump的时候会无助,会哭泣

在面对无休止的接口变动的时候会歇斯底里,面对改一行代码系统就全挂的窘境束手无策

所以我们需要微内核、微服务这样的框架来约束系统,降低系统的复杂性,让我们所有犯的错误都能保持在可控的范围内,让因为我们的愚笨而写出的有bug的代码也能勉勉强强运行起来而不是分分钟crash,哪怕这些方法额外增加了许多工作量、还降低了效率

但是,总是有超人存在的,我们人要造一个纪念碑,设计一堆方案,superman会说,哈?这个事情,不是只要我去把那个石头举起来,然后飞过来,放在这里不就好了嘛?

体力上差距这么大的超人也许不存在,但智力上差距这么大的超人却是存在的,所以要记住工程方法只是为了拯救我们这些凡人,对于超人来说,他们是不需要这些的,他们要做的仅仅是“搬起来,放下去”而已


Minix为了尽可能兼容更多的硬件设备,做到更加全面的兼容性,在实现上尽量避免利用单一某种处理器的新特性,这也是导致其效率不高的原因之一

而Linux则认为操作系统只需要对用户态程序保持统一的API即可保证兼容性,底层硬件的驱动等支持可以扩充,并且工作量不大

在编写Linux的开始阶段,仅支持在当时使用人数占多数的i386架构,但在内存管理,网络等模块上实现均优于Minix,因此取得了大量用户的支持,并最终流行

所以归根到底,决定一款产品是否成功的要素不仅仅取决于它的设计,也在于它的实现

很有意思的是,计算机领域往往经过完善设计的产品最终结果都是失败了,像UNIX赢了Multics,设计很好的Lisp并没有C语言流行, 又像同设计OSI的愿景最后由TCP/IP协议完成。这篇Worse is Better就是说的这个道理:Worse Is Better


linux kernel在发展过程中,形成了自己的工程方法论,注定无法向微内核方向演化

kernel 重视更动,强调不断翻新,轻视特征和实现的稳定性

例如,没有固定的api,甚至源代码级的固定api也不允许存在

内核内部子系统接口变动是家常便饭。提倡厂商将驱动合入内核以便于跟上变动,跟不上变动的子系统和驱动被kernel维护者抛弃被认为是很正常的

想想看,如果子系统必须要随着同版本的整个系统一起编译,谁还愿意设计成分离地址空间和通过ipc 通讯的工作模式

总的说来,kernel 开发的思想是将软件系统看做动态变化的生物,而非完美设计的机器。争取通过日常工作流程,自然地发现问题,清理陈疴

微内核思想来自学术界,想象的操作系统各部分能够分隔清楚,接口定义良好,这和获得很大成功的kernel实践经验格格不入

最后,linux kernel 很成功,没有改变基本模式的动力