Image Image Image ImageImage
Creative Services for
Roughly Drafted
Daniel Eran

Image Image

Unraveling The Mac OS X Linux Kernel Myth: Part 4
According to proponents of this myth, Apple will, could, or should shortly replace Mac OS X's kernel with Linux. They're wrong; here's why.

Page 1 | 2 | 3 | 4

Technical Differences

Linux lacks functionality
required by Mac OS X. Among other things, Apple's needs for things like realtime media support and sophisticated driver flexibility and power management are all radically different than Linux'. Should Apple compromise the needs of media professionals and end users in order to adopt today's Linux, or radically alter Linux until it closer matches what Apple actually needs?

As I noted earlier, by the time Apple added enough features to Linux to make it suitable for Mac OS X, it wouldn't be Linux anymore, but rather a proprietary fork of Linux that nobody else used. This makes no sense.

When Apple decided that NeXT's existing Driver Kit wouldn't support the kinds of features they needed in Mac OS X, they designed the new IO Kit. It simplifies driver development by handling device drivers as objects in families of inherited behavior. In many cases, manufacturers don't have to write specific drivers at all; when they do, they don't have to build the whole enchilada.

Kernel Extensions and Network Kernel Extensions are dynamically loaded when needed, and can take advantage of sophisticated power management, among many other features. Drivers in Linux can be built as loadable kernel modules, but don't offer anything approaching the same feature sets.

Apple offers the IO Kit as open source, but Linux is unlikely to adopt it for the same political and philosophical reasons why Apple can't use much from Linux' kernel.

Linux lacks the freedom to make major, innovative architectural changes. Apple has demonstrated the capacity to make sweeping changes over the past five years with Mac OS X largely through the their unique freedom to do anything they want throughout the core os; they answer to no one but their own users and developers.

Linux kernel developers have to be far more conservative simply because they are beholden to the far wider scope of applications demanded of Linux, and the entrenched habits of its user base. Linux could never decree the adoption of something new like launchd. Even simple efforts to create standards for Linux distributions have failed due to infighting among various interests in the Linux community.

Linux is radically different. Apple would have to rewrite a lot of the core services in Mac OS X because they map to specifics of the existing kernel or conventions related to it.

For example, Apple would have to build custom support for Mach-O application binaries under Linux or migrate to ELF. Mach-O would sidetrack any imagined gains of Linux compatibility; while ELF would destroy the whole idea of Universal Binaries and require developers to face yet another entire recompile and rerelease of all their applications.

Apple would have to abandon major enhancements they have made to the XNU kernel, such as the IO Kit, and instead demand developers rerelease all their drivers, or other kernel extensions, as primitive Linux LKMs that were harder to build and less functional.

They would have to retrofit Linux to support their own unique and complex needs for supporting a variety of threading models. They would have to trade off the excellent and mature BSD networking stack for Linux' merely functional one, and either drop or rewrite their NKE architecture inside Linux against its entirely different networking code.

Linux lacks Mach, the much maligned competitive advantage in XNU. This entire myth rests on the idea that Mach is inherently flawed, asthmatic old crap that needs to be replaced. This simply isn't the case.

There are advantages related to running Mach under the hood, despite the overstated failure the industry tends to relate with Mach due to the implosion of IBM's Workplace OS, the GNU/HURD kernel, and Apple's own TaligentOS and NuKernel projects, all of which were tied to Mach as a microkernel, which involves running an OS in the userland outside the kernel.

Continued: Much ado about Mach


More Journal Entries | More Tech Articles | Get Tech Support | My Resume | Links | Contact RoughlyDrafted

Articles Copyright © 2006 Daniel Eran. All rights reserved.
Suggestions and comments welcome. Contact RoughlyDrafted.

Read more about:
Click one of the links above to display related articles on this page.