unix是按照进程组织作业的，因为起初人们使用计算机系统就是要分时处理各个作业，那时并没有现在的各种复杂且多样化的应用，也不需要什么进程间的通信，甚至不需要复杂IO，进程的传统一直沿用至今，极端的Eric在《unix编程艺术》中大肆鼓吹小进程的妙用，鼓吹unix的优良传统，此人的极端源自于他对unix的酷爱，源自于他对unix的深入理解，而我们要想从肤浅层次去理解这件事，那就不是很容易了，看看unix的内核，简单的说，看看linux的内核，我们能说些什么呢，linux在内核中尽量的避开了进程，除了kthread是真正的进程(其实更确切说是一个task_struct)，别的几乎没有什么和用户空间进程相互隔离的概念，也许是linux对自己很自信吧，内核中几乎总是在统一的地址空间进行处理的，所有的进程公用内核页表，中断没有线程化，在任意上下文运行，甚至尽可能不让软中断线程话，进程调度没有真正的调度体，而是在当前的上下文简单调用schedule，最值得关注的是内存管理，没有实现每进程的工作集，linux使用全局工作集，尽可能让物理内存被全部占用，只看眼前却不怎么关注将来，linux是比unix更极端的实用主义者，起码在内存使用上，虽然也简单使用一点预读算法之类的...最根本的，linux的内核和unix一样，不是基于对象的微内核，而是大内核。
看看windows，虽然我们以为它的内核是杂糅的，但是虽然它不是基于进程的，但是更进一步，它是基于对象的，对象之间可以基于接口互相通信，并且对象之间遵循严格的访问控制规则，linux内核一旦被侵入，那么入侵者可以毫不费力的获得一切权力，windows内核一旦被侵入，在硬件意义比如x86的意义上，入侵者也是可以为所欲为，然而因为有严格的对象间访问限制，你需要付出更多时间和精力，除非你是一个顶级hacker，最关键的，windows使用了每进程的工作集，这也许是windows对自己进程调度算法的不太信任吧。这个意义上，windows才是真正基于小对象的，进程对于它来讲都是很大的对象了，起码还有线程，windows虽然在对待进程线程这个问题上没有像linux那样实现嵌套组织方式(task_struct的组合模式)，起码实现了一个包含的设计模式。
看看windows，虽然我们以为它的内核是杂糅的，但是虽然它不是基于进程的，但是更进一步，它是基于对象的，对象之间可以基于接口互相通信，并且对象之间遵循严格的访问控制规则，linux内核一旦被侵入，那么入侵者可以毫不费力的获得一切权力，windows内核一旦被侵入，在硬件意义比如x86的意义上，入侵者也是可以为所欲为，然而因为有严格的对象间访问限制，你需要付出更多时间和精力，除非你是一个顶级hacker，最关键的，windows使用了每进程的工作集，这也许是windows对自己进程调度算法的不太信任吧。这个意义上，windows才是真正基于小对象的，进程对于它来讲都是很大的对象了，起码还有线程，windows虽然在对待进程线程这个问题上没有像linux那样实现嵌套组织方式(task_struct的组合模式)，起码实现了一个包含的设计模式。
以上言语似乎不伦不类，我到底褒谁贬谁呢，其实我还是喜欢unix传统的，说实在的，我理解的unix的进程传统和Eric是一样的，这可不是自夸，进程传统是提供给用户的，而不是内核的实现方式，实现分离进程的内核是需要付出代价的，付出的代价开销必然要损害用户空间的性能，因此linux并不在内核特别在意进程或者对象，这确实可以带来效率的提升，举一个简单的例子，在内存置换算法中，如果是windows的基于进程工作集的算法，那么必然要涉及一系列的预测算法，比如预测哪个进程是活跃进程等等，那么如果预测失误，就会导致很大的内存被浪费，而unix/linux中并没有这么复杂的算法，它尽可能使用所有的内存，然后根据用户的短期行为进行置换行为的微调，即使对某一个进程暂时不公平，那么也不会造成内存的浪费。最重要的不是一个操作系统内核怎么实现，而是它提供给用户基于什么的用户接口。
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1271992
