[生活]Mac OS X是什么

[生活]Mac OS X是什么 Mac OS X是什么 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，导入了其中。