面试的时候我竟然回答没有关系，收到了鄙视，不过应该的，谁要我瞎蒙呢。
所以做人要实诚，知道归知道，不知道归不知道。乱说就不好了
受教，受教。
Article is provided courtesy of Addison-Wesley Professional
OS X is often misunderstood, regarded as a pretty version of FreeBSD, a microkernel, and various other things. In this article, David Chisnall, author of Cocoa Programming Developer"s Handbook, looks at what is really at the core of Apple"s operating system and where it came from.
Mac OS X常被误解，被看作是标致版的FreeBSD，微内核，以及其他各种不同的东西。这篇文章介绍了大卫·奇斯纳尔——《Cocoa编程开发者手册》一书的作者，是如何看待苹果操作系统的核心到底是什么，以及它是由何而生的。
I"ve read lots of claims about Mac OS X. It"s a
Linux distribution (my personal favorite), it"s just FreeBSD with a pretty window manager, it"s Mach with a BSD userland, it"s just something copied from NeXT. All of these contain some grains of truth, but none of them is really accurate. In this article, I"m going to take a look at exactly what OS X is and try to clear up some of the misconceptions about it.
我看过很多关于Mac OS X的陈述。它是一个
Linux发行版（我个人喜欢的），它只是一个带有漂亮窗口管理器的FreeBSD，它是Mach系统与BSD非内核部分的结合，它只是从NeXT复制而来。所有这些陈述都包含了一定的事实，但是没有一个是完全准确的。在这篇文章里，我将会带领大家认识一下Mac OS X究竟是什么，同时会努力澄清一些关于它的错误观念。
Part of the confusion comes from the varying terminology used to describe bits of the system. People often talk of Darwin as if it were a kernel, an analog of
Linux. In fact, Darwin is closer to being an analog of a member of the BSD family; it"s a complete system including a kernel, XNU, and a set of userland applications. On top of this are the various proprietary systems that combine to form OS X.
这些困惑一部分是源于描述系统所用的不同术语。人们经常谈论Darwin，好像它是系统内核，与
Linux类似。事实上，Darwin更加近似于BSD家族成员中的一员；它是一个完整的系统，包括一个XNU内核， 以及一套外围程序（userland）。在这之上，则是各种不同的专有系统，组合在一起构成了Mac OS X。
A Mach-O System
一个Mach-O系统
In the "80s, a team at Carnegie Mellon University began working on a next-generation UNIX system. Traditional UNIX systems, like the 4.2BSD system that they were using at the time, had a single process for the kernel. Everything that the kernel is responsible for was part of a single binary, with no protection between the various parts. The goal of Mach was to separate out all of the bits and provide a mechanism for joining them together.
在上世纪80年代，卡耐基梅隆大学的一个小组开始着手研究下一代UNIX系统。传统的UNIX系统，比如当时他们使用的BSD4.2版，一个内核只有一个进程。内核所负责的每一个事物都是二进制的一部分，在各个部分之间没有保护。Mach的目标是将所有这些数据分离开，并且提供一种机制可以将其运用到所有这些数据中去。
A full discussion of this philosophy and its advantages and disadvantages would take up much more space than I have for this article, so I"ll simplify things somewhat. The microkernel approach, taken by Mach, was not a great success. In the end, they had a version of the BSD kernel running as a process on top of their microkernel and calling down to Mach instead of executing privileged instructions.
对于这一做法的见解，优势以及劣势的全部讨论，将会比我这篇文章长得多，所以让我来简化一下。Mach所使用的微内核的方法，并没有获得很大的成功。最后，他们使用了某一版本的BSD内核，作为进程运行在他们的微内核上层，调用Mach，而不是运行特权指令。
This had some advantages. One was that every user on a powerful system could have his or her own, completely isolated, BSD kernel and userland. Effectively, it was an early form of paravirtualization.
这是有一些优点的。优点之一是，强大的系统上的每一个用户，都可以拥有他/她自己的，完全独立的，BSD内核和应用（userland）。
It also had some major disadvantages. The biggest of these was speed. On a modern system, there are some trades between speed and scalability. A modern laptop has two to four cores, and a desktop may have 16. Cheap servers are starting to have huge numbers, just as high-end servers have for a decade or so. Back in the "80s, however, when Mach was created, single-processor machines were the norm. On a modern SMP system, if you split your code up into separate processes, then you get some overhead from their communication and some speed increase from running them in parallel.
同时，它也有一些主要的缺点。最大的缺点之一就是速度。对于一个现代系统来说，人们会在速度和可扩展性上做一些平衡。一台现代笔记本电脑，有两到四个核心，而台式机则可能会有16个。便宜的服务器开始拥有巨量的核心，如同那些十年前已经拥有巨多数量核心的高端服务器。然而，回到上世纪80年代，当Mach创建时，单处理器机器是标准。在一个现代的对称多处理系统上，如果你将你的代码分割成独立的进程，那么你会看到，进程间的数据交换会占用额外的资源，同时，进程间的平行运行也会使得速度有所加快。
Mach just got the slowdown. To make matters worse, it got a lot of this slowdown. In Mach, there was only one form of interprocess communication: message passing. This is a very clean abstraction, but Mach managed to pick exactly the wrong way of implementing it. Every Mach message send required checking the sending and receiving port access rights and some complex memory mapping operations, which resulted in a Mach message send being much slower than a system call. On Mach-based UNIX systems, a UNIX system call meant sending a message from the userspace process to the BSD process, which may then send more messages to other processes, and then waiting for the reply.
而Mach则仅仅使得速度下降了。更糟糕的是，它使得速度大幅的下降了。在Mach里，进程间的通信只有一种形式：消息传递。这是一个整洁的抽象概念，然而Mach选择了恰好完全相反的方法来施行。每一条Mach消息发送都需要检查接受端口和发送端口的访问权限，以及一些复杂的内存映射操作，这使得一条Mach消息的发送变得比系统调用还慢。在基于Mach的UNIX系统上，一个UNIX系统调用意味着从用户空间进程发送一条消息到BSD进程，这将导致发送更多的消息至其他进程，然后等待响应。
The XNU kernel uses Mach at the core. This is one of the things that everybody knows about OS X, but it"s quite misleading. Unlike most other Mach-based operating systems, such as GNU HURD (which, contrary to popular belief, does exist), XNU implements UNIX system calls in the same way as a BSD system. You set some registers and issue a system call instruction (or an interrupt) and have the kernel code called directly from the trap handler. You can see this quite easily in Activity Monitor. The vim process that I am using to write this has, so far, issued 64K UNIX system calls, but only 88 Mach system calls and has sent and received less than 200 Mach messages.
XNU内核使用Mach作为核心。这是OS X人所共知的事情之一，但是这却具有相当的误导性。不同于大部分基于Mach的操作系统，比如GNU HURD（与人们以为的恰恰相反，它的确存在），XNU采用与BSD系统相同的方式来实行UNIX系统调用。你可以设置一些寄存器，并发出一个系统调用指令（或中断），并由陷阱处理程序直接调用内核代码。你可以很容易的从活动监视器中看到这些。我正在使用的VIM编辑器的进程，到目前为止，发送了64K的UNIX系统调用，但只有发送了88个Mach系统调用，并且，发送和接受的Mach消息少于200条。
So what does XNU use Mach for? The simplest answer is as an abstraction layer, along the lines of the Windows HAL, but this doesn"t tell the entire story. The closest analog in a modern system is the nanokernel in the Symbian microkernel. Mach is responsible for managing the CPU and memory and for providing some basic abstractions to the top of the kernel, such as tasks and threads.
那么XNU使用Mach做什么呢？最简单的答案是，做为一个抽象层。好像Windows的硬件抽象层，但这并不是全部。在现代系统里与之最接近的类似物是塞班内核里的nano内核(nanokernel)。Mach负责管理CPU和内存，以及为内核的上部提供一些基本的抽象概念，比如任务和线程。
The BSD part of the kernel calls down to the Mach part, but can call these functions directly, not requiring a Mach message. This means that most of the disadvantages of Mach are eliminated. So are Mach messages still used? Wave the mouse over an application while inspecting it and Activity Monitor, and you get an immediate answer: Yes.
内核的BSD部分可以调用内核的Mach部分，是直接调用这些功能，而不需要通过Mach消息。这意味着Mach的大部分缺点都被消除了。那么Mach消息仍被使用吗？把鼠标移到某一程序上，并同时观察它和活动监视器，你立刻会得到答案：是的。
Mach messages are used for a lot of things in OS X, not least of which is the delivery of events from the user. Other processes are also free to use Mach-level IPC. This has some advantages—for example, the fact that it"s easy to check the other party in Mach communication, which can be useful when implementing things like the Keychain, which rely on the ability to permit communication based on the program making the request.
在OS X里Mach消息被用于很多地方，不仅仅是传递用户事件。其他进程也可以自由的使用Mach层面的进程间数据交换(IPC)。这有一些优点，比如，使得检查在Mach通信里的其他部分变得容易了，这对于运行一些如钥匙串(Keychain)的程序会很有用，它依赖于基于程序请求而允许通信的能力。
The BSD Layer
BSD层
Atop Mach sits a modified BSD kernel. Back in the NeXT days, this was based on 4BSD. Now it is based on FreeBSD, and code flows both to and from this project on a fairly regular basis. You may have noticed that OS X advertised fine-grained kernel locking in 10.4, shortly after the same feature appeared in stable releases of FreeBSD. FreeBSD is also the source of Darwin"s libc, the library that implements the core features required by the POSIX and C language specifications, among other things.
在Mach的上面是经过修改的BSD内核。回到NeXT的年代，这是建立在BSD第4版的基础上的。现在，它基于FreeBSD，这个项目也比较定期的接受其他的代码，贡献自己的代码。你可能已经注意到，在FreeBSD稳定版发布后不久，OS X宣传它在10.4中封入了纹理细密的内核，这一相同的特性也出现在FreeBSD稳定版中。FreeBSD也是Darwin库（libc）的来源，该库用以实现移动操作系统接口（POSIX）和C语言规范所需的核心特性。
If you do any relatively low-level programming on OS X, you can find lots of things that look familiar from FreeBSD. The most obvious of these is the kqueue() interface. This provides a unified mechanism for waiting for events from the kernel. These events can be things like timers, signals, data ready for reading on a file descriptor, and so on. On OS X, they also include Mach port status changes. A typical Mac OS X application spends most of its time in the kevent() system call, waiting for an event from the kernel to wake it up.
如果你在OS X上从事任何比较底层的编程工作，你会发现，有很多事物看起来和FreeBSD很相似。最明显的就是kqueue()接口。该接口为等待从内核来的事件提供了一个统一的方法。这些事件可以是诸如计时器，信号，文件描述符上预备读取的数据，等等。它们也包括Mach端口状态的变化。一个典型的Mac OS X应用程序的大部分时间在用在kevent()系统调用上，等待从内核来的事件来唤醒它。
The BSD layer provides most of the operating system services that the Mach layer does not. Mach provides a few basic abstractions: ports, messages, tasks, threads, and memory objects. A task is a collection of threads and access rights to memory objects and ports. It corresponds roughly with a UNIX process, and a Mach thread corresponds roughly with a POSIX thread. Part of the responsibility of the BSD layer in the XNU kernel is making this rough mapping concrete. The process tables are maintained by the modified FreeBSD kernel, as are the filesystem and network stacks, UNIX-style IPC, and quite a few other things.
BSD层提供了大部分Mach层没有提供的操作系统服务。Mach提供一些基本的抽象概念：端口，消息，任务，线程，以及存储对象。任务是存储对象和端口的线程和访问权限的集合。它大致相当于UNIX的进程，Mach线程与移动操作系统接口（POSIX）线程相似。在XNU内核中，BSD层的一部分责任就是将这些进行粗略的实体映射。进程表是由修改过的BSD内核维护的，同样由BSD内核维护的还有文件系统，网络堆栈，UNIX形式的进程间数据交换（IPC），以及很多其他东西。
You can do a lot on OS X without getting down to the Mach layer. Some calls, like fork() or pthread_create(), are partially handled down there. fork() in particular is quite complex. This call needs to mark the address space as copy-on-write by manipulating the relevant Mach memory objects, create a new Mach task for the copied objects, and create a new Mach thread with a copy of the original thread"s stack. Back up in the BSD layer, it also needs to create new entries in the process table, copy any file descriptors that the process has open, and so on.
你可以在OS X上做很多事而不需要深入到Mach层。一些调用，比如fork()或者pthread_create()，则需要部分的在Mach层上处理。fork()尤其复杂。该调用需要通过操作相关的Mach存储对象来将地址空间标记为copy-on-write，然后为副本对象创建一个新的Mach任务，并且创建一个新Mach线程和原始线程堆栈的副本。回到BSD层中，它同样需要在进程表中创建新条目，复制进程所打开的所有文件描述符，以及其他事务。
Because the Mach layer is responsible for threads, it is also responsible for scheduling. This means that the new FreeBSD scheduler is not present in OS X.
因为Mach层负责线程，所以它也同样负责排程。这意味着新的FreebSD的排程器并未出现在OS X中。
Drivers
驱动
The majority of code in most modern kernels is found in device drivers. In OS X, somewhat unusually, these are written in a dialect of C++, embedded C++, which omits many of the features of C++ that cause runtime overhead. Interestingly, the older DriverKit framework from OPENSTEP used Objective-C, a dynamic language with (generally speaking) more overhead than C++ for drivers, but on computers an order of magnitude faster Apple chose to go with a dialect of C++. It"s unclear why they made this change; possibly they found that most drivers didn"t use the features of Objective-C, or possibly they just wanted to move the Objective-C runtime out of the kernel.
在现代内核中，大部分代码出现在设备驱动中。在OS X中，则有一些不同寻常，它们是用C++的一个分支，embedded C++写成的，embedded C++省略了很多C++中引起运行负荷的特性。有趣的是，OPENSTEP的老驱动程序工具套件框架使用的是Objective-C，这是一个（一般而言）对于驱动来说，比C++更加会增加负荷的动态语言，然而在计算机上快一个数量级的苹果却选择使用C++的一个分支。我们不清楚他们为什么做出这样的改变，可能是因为他们发现大部分驱动用不到Objective-C的特性，也可能仅仅是因为他们不想让Objective-C在内核上运行。
IOKit, the framework used for writing device drivers, provides a hierarchy of C++ classes for various different generic devices and allows drivers to be written by subclassing them.
IO工具套件是一个用于编写设备驱动的框架，为各种不同的通用设备提供了C++类的等级划分，允许通过将驱动子类化来修改它们。
Initialization and Startup
初始化和启动
The most noticeably unique userland feature of Darwin is launchd. This is an Apache-licensed replacement for init, cron, and inetd on other UNIX-like systems. It is the first process to be started by the kernel and can run tasks in response to network activity, timers, or when required by others.
Darwin里最引人注目的奇特用户态（userland）的特性就是launchd。这是一个Apache授权的，用以代替其他类似UNIX系统上的init，cron和inetd。它是内核启用的第一个进程，可以对网络活动，计时器，或者其他进程的请求作出反应，运行任务。
One thing that you will notice about launchd is that it uses property lists for configuration. NeXT property lists were a simple ASCII format, and Apple has added binary and XML representations. Most system tools on OS X use the Core Foundation framework, which provides (among other things) support for reading and writing files in this format. They have the advantage that they are quite easy to edit by hand, but are also easy to parse. The use of property lists throughout OS X is one of the reasons why the GUI integrates so well with the rest of the system; it is trivial to write a Cocoa program to manipulate a property list that is used to control daemons. On contrast, most other UNIX-like systems have userland daemons that all have their own configuration formats. You will see on OS X that things like Apache and Samba, which are ported from other platforms, lack the tight integration with the GUI that native daemons provide.
你会注意到，launchd使用了属性列表做配置。NeXT的属性列表是简单的ASCII格式。苹果公司加入了二进制和XML的表示。OS X上的大部分系统工具使用了核心基础（Core Foundation）结构，它能够提供该格式的读写支持。它们有优势，它们可以很容易的进行手工修改，但同时也很容易被解析。贯穿在OS X里的属性表是图形用户界面很好地整合在系统里的原因之一。写一个Cocoa程序来操作属性列表，控制守护进程，这并不重要。恰恰相反，大部分其他UNIX类的系统都有用户态（userland）的守护进程，它们都有自己的配置格式。你可以在OS X里看到诸如Apche和Samba，这些从其他平台导入的东西，并不像原生的守护进程提供的那样与图形用户界面紧密整合。
The rest of the userland is a strange hybrid of FreeBSD, OPENSTEP, and GNU utilities. Some, such as ditto, date back to the NeXT era, although most have been updated. Others, such as du, df, ls, and most of the standard userland come from FreeBSD, but have been slightly modified by Apple. Most of the development related tools come from the GNU project. Make is GNU Make and cc and c99 are both GCC, although it seems likely that these will be replaced by Clang at some point in the future. In recent versions of OS X, the default shell is GNU bash, familiar to most
Linux users, rather than the C shell more familiar to FreeBSD users.
剩余的用户态（userland）是一个奇怪的混合体，有FreeBSD，OPENSTEP，和GNU的工具。一些，比如ditto，是NeXT时代的，虽然大部分已经更新过了。还有一些，比如du，df，ls，以及大部分的标准的用户态，来自于FreeBSD，但是被苹果公司略微的修改过。大部分的开发相关的工具来自于GNU项目。Make是GNU的Make，cc和c99都属于GCC，虽然这些看起来会在将来的某一时刻被Clang所替代。在最近的OS X版本中，默认的壳（shell）是GNU bash，为大多数
Linux用户所熟悉，超过了FreeBSD用户对C壳（shell）的熟悉程度。
Quartz Is Not X11 (But It Could Be)
Quartz不是X11（但它可以是）
When OS X was first released, there was a long post by one of the Quartz developers on Slashdot explaining why they chose not to use X11. The argument was quite long, but it basically boiled down to this fact: To get the features that they wanted, they"d have had to implement so many extensions that they"d basically be running an entirely new windowing system anyway, just using X extensions to communicate with it instead of their own system. Now, all of those extra extensions exist and are well-supported by X.org, so the decision might be somewhat different. That hasn"t stopped Google from implementing its own display system with Android. The saying about those who fail to understand UNIX being condemned to reinvent it poorly is even truer when it comes to X11.
当OS X首次亮相时，一位Quartz的开发者在Slashdot上发表一篇很长的文章，解释为什么他们不选择使用X11。该争论非常长，但是基本上它归结于这个事实：为了获得他们想要的特性，他们将不得不实施非常多的扩展，以至于他们宁愿运行一个基本上全新的窗口系统，而不是仅仅使用X扩展来做通讯以代替他们自己的系统。现在所有这些额外的扩展都依然存在，并且获得X.org的良好支持，所以决策可能会有所不同。这并没有阻止Google公司在Android上开发自己的显示系统。那些错误理解UNIX的人因为对UNIX的不良改造而受到谴责，这一现象对于X11来说更加真实。
There are architectural similarities between Quartz and X11. More, in fact, than between Quartz and its predecessors at Apple and NeXT: QuickDraw and Display PostScript. QuickDraw, found on the old MacOS Classic systems, was a very simple design. One process mediated access to the display, allocating regions to other processes, and the other processes drew into these directly. The obvious disadvantage to this was that all processes had access to the frame buffer, so could corrupt the display easily and synchronizing drawing between applications was very difficult.
Quartz和X11在结构上有相似性。而且，事实上，比Quartz和它在苹果和NeXT的前身：QuickDraw和Display PostScript，更加相似。QuickDraw，建立在老MacOS的经典系统上，是一个非常简单的设计。一个进程协调显示访问，将不同的区域分配给其他进程，其他进程直接绘画出图像。这一设计明显的缺点是所有的进程都能访问帧缓冲，所以很容易导致显示问题，而且在不同应用程序间的同步绘图十分困难。 Display PostScript worked in a very different way. Processes on old NeXT systems sent PostScript programs to the display server, which then ran them. This had its own problems, such as the fact that the display server effectively needed to be a complex multitasking virtual machine to prevent programs from taking over all of the display"s time. Display PostScript则采用非常不同的设计。旧NeXT系统上的进程把PostScript程序发送给显示服务器，然后运行它们。这也有它们自己的问题，比如显示服务器必须是复杂的多任务虚拟机，来阻止程序占据所有的显示时间。
The design of Quartz is conceptually much simpler. Just as a filesystem virtualizes the disk by providing virtual disks (files) to applications, Quartz virtualizes the screen by providing virtual frame buffers (windows) to applications. I should mention that Apple"s documentation often calls this part of Quartz the “Quartz Compositor” or simply the “Window Server,” and includes a few other things (including Core Animation) in the Quartz brand. The window server provides a region of shared memory to clients for drawing and then composites this into the frame buffer (on the GPU). It"s a little bit more complicated than that, because this buffer is now an OpenGL texture and can be the result of rendering OpenGL graphics to the texture or compositing other textures together.
Quartz的设计理念则简单些。如同文件系统为应用程序提供虚拟磁盘（文件）来虚拟化磁盘一样，Quartz为应用程序提供虚拟帧缓冲来虚拟化显示屏。需要指出的是，在苹果文档内常常把Quartz的这部分称为“Quartz合成器（Quartz Compositor）”或者简称为“窗口服务器（Windows Server）”，同时在Quartz内也包含了其他一些东西（包括Core Animation）。窗口服务器为客户提供了一块共用内存区域用来绘图，然后（用GPU）将其混合为帧缓冲。实际情况要比这要比这复杂一些，因为该缓冲现在是OpenGL纹理，也可以是OpenGL图形渲染结果的纹理，或者是其他纹理混合在一起的结果。
So what advantages did Quartz have over X11? Over a modern X11 system, none, and several disadvantages that come from tying the policy into the window server. These days, the window server is implemented on top of OpenGL, and the 2D drawing is handled either in software or by sending OpenGL commands to the window server, exactly as would happen with X11. Unlike X11, the policy for compositing and managing windows is implemented entirely in the window server. With X11, this is handled by a separate processes (or two; the window manager and compositing manager, which are sometimes combined into a compositing window manager), and so you can use the same mechanisms on a handheld device or a multi-monitor workstation, just with different policies.
那么Quartz有什么超过X11的优点吗？对于现代的X11系统来说，没有，而且还有一些源于将策略合并至窗口服务器处理所导致的不足。现在，窗口服务器是在OpenGL的上层运行的，而2D绘图则由软件或者向窗口服务器发送OpenGL命令来处理，完全和X11一样。与X11不同的是，用于合成和管理窗口的策略完全是在窗口服务器中实行的。而对于X11而言，这是由单独的一个进程来处理的（或者是两个进程，窗口管理器和合成管理器，这两者常会合并为合成窗口管理器），所以你就可以在手持设备或者多显示器工作站上使用相同的方法，仅仅只有策略不同。
Many improvements have been made over the kind of X11 implementation that was present when Quartz was introduced. Back then, X didn"t have any kind of compositing model. There was no sensible support for buffering. Applications each had a region of the display reserved on their behalf, as with QuickDraw, but drew into it with commands sent from the client. If one window covered another, then the data from the lower window was lost and needed redrawing later. Font rendering was a mess. Quartz fixed all of these and provided much of the inspiration from the later X extensions which served a similar purpose.
自从Quartz推出以来，X11在运行上有了很多改进。回到Quartz刚推出时，X没有任何合成模型。没有对缓冲的合理支持。每一个应用程序都有为它们自己预留的一块显示区域，就好象QuickDraw一样，不同的是，Quartz是接受从客户端发送的命令来绘图。如果某个窗口盖住了另外一个，那么那个被盖住的窗口数据就会丢失，需要在之后重绘。字体渲染也很乱。Quartz修复了所有这些问题，并且为之后的X扩展提供了大量灵感，那些扩展也有着相似的用途。
In terms of current capabilities, Quartz and a recent version of X.org are similar. The difference is that X.org has a cleaner separation of policy and mechanism, and maintains backwards compatibility with applications dating back to the mid 1980s. Because the communication layer between the Quartz frameworks and the window server are private, it would be quite easy to replace them with X.org (although this wouldn"t gain Apple much), and X.org itself has been ported to run on top of Quartz in the form of Apple"s X11.app. At the time of its creation, Quartz was clearly superior to X.org. Now they are roughly equivalent in terms of features, and Quartz is closely integrated with other parts of the system.
就目前的性能而言，Quartz和最近的X.org版本是相似的。不同之处在于，X.org对于策略和方法有一个更加清楚的区分，同时保持了对1980年代中期以来的应用程序的兼容。由于在Quartz的框架和窗口管理器之间的通讯层是私有的，所以它很容易用X.org来替换。（虽然这不会从苹果公司获益多少），而且X.org本身也被导入至Quartz的上层，以Apple X11程序的形式运行。当Quartz刚被创造出时，它大大地超越过X.org。而现在，它们在很多特性上基本相当，而Quartz更紧密的与系统的其他部分整合。
OS X is not FreeBSD
OS X不是FreeBSD
Lots of parts of OS X come from FreeBSD, from the top half of the kernel up into the userland. The lower parts come from Mach and a lot, such as the virtual memory subsystem and scheduler, have been heavily reworked in recent versions.
OS X的许多部分都来自于FreeBSD，从内核顶部到用户态（userland）。较底层的部分则来自于Mach，并且许多诸如虚拟内存子系统和排程器的部分，都在最近的版本中被大量重写了。
It"s almost as much of a mistake to say that OS X is not FreeBSD as it is to say that it is FreeBSD. From the perspective of a userspace programmer, it is very difficult to tell the two apart. Aside from the presence of Mach ports on Darwin, the two are remarkably similar. The Mach layer at the bottom of the kernel is visible in userspace, but not directly used by most developers outside Apple. Indeed, their documentation recommends against relying on its presence, so it may vanish altogether in a future version.
认为OS X不是FreeBSD几乎就如同认为OS X是FreeBSD一样错误。从一个用户应用层的程序编写者的角度来看，这两者很难区分。除了Darwin上还存在的Mach端口，这两者相当的相似。内核底层的Mach层对于用户空间层（userspace）来说是可见的，但是却不能被大部分非苹果公司的开发者直接运用。实际上，苹果公司的文档推荐不要依赖于它的存在，所以在将来，它有可能完全消失。
The best way to think of OS X is as a close relative of FreeBSD. It shares a lot of code and is very similar to develop for. It"s no accident that FreeBSD was the first platform that had libdispatch, the core of Apple"s Grand Central, ported to it.
把OS X看作是FreeBSD的近亲是看待OS X的最佳方式。它分享了大量代码，同时开发上也非常相似。FreeBSD是第一个拥有libdispatch的平台，这并非巧合，苹果的Grand Central，导入了其中。
Linux 操作系统是UNIX 操作系统的一种系统。它诞生于1991 年的10 月5 日（这是第一次正式向外公布的时间）。以后借助于Internet 网络，并经过全世界各地计算机爱好者的共同努力下，现已成为今天世界上使用最多的一种UNIX 类操作系统，并且使用人数还在迅猛增长。 Linux 操作系统的诞生、发展和成长过程始终依赖着以下五个重要支柱：UNIX 操作系统、MINIX 操作系统、GNU 计划、POSIX 标准和Internet 网络。
