Lately, OSX, or more specifically its kernel, has had a lot of attention. Benchmarks made by AnandTech have shown that OSX’ kernel has some serious performance issues. As a result, some have uttered the idea Apple might replace the kernel of the MacOS with another kernel– Linux seems, to them, the most viable option. Secondly, there have been speculations that Apple is closing the x86 version of its kernel. Note: Sunday Eve Column.
I will first try to explain to you why Apple will never use the Linux kernel as the base of the MacOS (‘never’ as in the period Steve Jobs is in charge of the company). The arguments supporting this claim boil down to two main points: control and the GPL.
The most important of these three is the first one. Apple is a company that longs to control as much of the user experience as possible. Apple believes that control is the only way to ensure a seamless experience to its users. Whether or not you agree with this point of view is a personal matter. Personally, I see the benefits (I like using my iBook with the MacOS), but I also see the downsides (I also really like using my Inspiron 6000 with either Windows or Linux).
Anyway, Linux simply does not fit into this. The point of Linux, and most, if not all, other open source projects is to actually remove the kind of control Apple believes is necessary to ensure a seamless user experience. Linux is about handing over the control to the user, instead of letting a company decide what is good for the user. Again, whether or not you agree with this is besides the point; personally I can again see the positive as well as the negative aspects of this approach. The point, however, is this: if Apple were to switch to Linux, it would hand over a portion of control to a community it cannot steer. If Apple’s business practices since His Steveness’ Second Coming are anything to go by, we will not see this happening.
A second, more practical problem is the GPL. The GPL has been put in place to ensure that nobody can take the Linux kernel, close the source, and claim it his or her own. However, the GPL also has what is often referred to as “the GPL’s viral nature”: anything that is derived from a GPL’d piece of software must itself become GPL too. This is a roadblock for Apple: this might mean they have to open source key parts of their operating system, because they depend on specific functions of the kernel. This brings us back to the control issue again.
Another problem related to the GPL is the driver issue. Recently, there has been much hubbub about Kororaa bundling the binary nVIDIA and Ati drivers on their Xgl live CD. The problem boiled down to this: can those drivers be considered derivative works, or not? In other words, can they be bundled alongside and built to the kernel? Some say they cannot, some say they can; not even Linus himself can give a conclusive answer. The result? My third point: legal repercussions. Like I said in my previous column, the GPL has some legal gray areas, and as such, poses a possible legal problem to Apple– and especially, to Apple’s shareholders. Shareholders do not like legal gray areas.
In summary, Apple will not ‘switch’ (pun not intended, actually) to the Linux kernel. While technically Linux might be very well suited to power the MacOS, its philosophy and license are incompatible with Apple’s.
—
This week also saw speculations from an InfoWorld editor that Apple is closing down the x86 version of its MacOS kernel. Apple was quick to reply to the speculation, emphasizing that this is mere speculation, and that we should not confuse speculation with fact.
If we look at how the facts stand today, said InfoWorld editor has a very reasonable point. The sources to the x86 version of Apple’s kernel are as closed as Microsoft’s; and it has been that way ever since the release of Apple’s first Intel-powered Macintosh. In other words, Apple’s x86 kernel is simply closed-source at this point. From Apple’s reply one cannot draw any conclusions as to what will happen to the source code in the future.
I personally do not care either way. The BSD license allows this, so Apple is doing nothing wrong. However, I do think Apple should try to clear this issue up as soon as possible; they advertise the open-source nature of the OS’s ‘Unix-based core’, while in fact this is not true (at least, for the x86 version). They should get their act together, and make a conclusive statement.
–Thom Holwerda
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
The analysis that concluded that Mac OS X has performance problems was flawed.
http://ridiculousfish.com/blog/archives/2005/06/03/mystery/
http://ridiculousfish.com/blog/archives/2006/05/16/36
The idea that there is no Darwin Intel kernel anymore is also flawed.
http://opendarwin.org/pipermail/darwinbuild/2006-February/000278.ht…
Edited 2006-05-21 22:24
Those blog entries are largely worthless:
# They claim that making a new thread is called “forking”. No, it’s not. Calling fork() is forking, and fork() makes processes, not threads.
That’s not true. The article did make some, somewhat, confusing references to processes as a “thread of control.” However, this isn’t a fallacious way to describe it either.
What they actually said was:
The Unix process/thread creation is called “forking” as a copy of the calling process is made.
This is a correct description of fork().
fork() creates a child process that differs from the parent process only in its PID and PPID, –taken from GNU’s man page on fork.
I admittedly stopped reading there because it was obvious the author has a bias against the other authors causing him to incorrectly read their results. In other words: If he could read that bit about fork wrong I doubt he could understand any of their more complex arguments.
The second article was interesting. However, the realities of the default allocator Apple has chosen to use for OS X are real and valid; and they are an issue. The article has serious merit for finding a good explanation and showing its advantages though.
The Unix process/thread creation is called “forking” as a copy of the calling process is made.
This is a correct description of fork().
I know of nobody who uses fork for thread creation. Processes and threads are substantially different (otherwise why bother?). The Anandtech article benchmarks fork in order to explain poor thread creation. This does not stand to reason, as the standard way of creating threads on Mac OS X is pthread_create. Yes, Apple uses POSIX threads, which practically all *nix systems use, so to be ignorant of that fact severely casts doubts on the credibility on anyone who uses fork to create “threads”.
I know of nobody who uses fork for thread creation.
The use of fork for thread creation dates back to the early 60s. Scheme still calls it’s thread creation operations “fork-thread”.
Basically, there are two models for generating separate thread-of-control elements in a program. Those in which an existing thread-of-control is duplicated in part and returned to twice are usually called “forking” schemes, while those in which a thread-of-control object is created and activated are used so seldom any more I can’t recall what they’re called.
We tried to accomodate both in pthreads.
Yea, they shouldn’t have used that to benchmark thread creation as it’s a whole lot more than creating a thread (although it is technically creating a new thread, inside a new process).
Anyway, I don’t know of any benchmark for thread creation speed. You might try running a single pthread program to benchmark between the two; or suggest it to anandtech.
I still believe it may have a strong correlation. Explaining why processes take longer to create on OS X would be a good start in really debunking their method.
The analysis that concluded that Mac OS X has performance problems was flawed.
http://ridiculousfish.com/blog/archives/2005/06/03/mystery/