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.
Post a Comment
Member since:
2006-05-21
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
Member since:2005-06-29
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.
Member since:2005-07-07
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".
Member since:2006-02-15
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.
Member since:2005-06-29
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.
Member since:2005-07-06
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
And a few postings on a few specific issues (and dubious ones at that, on forking amongst others) on a blog proves otherwise? The hard figures as to Mac OS X's generally poor performance in a variety of scenarios are there. The question as to why is a slightly more complex matter to explain.
The idea that there is no Darwin Intel kernel anymore is also flawed.
Really? That mail posting says nothing. The other mail posting quoted elsewhere only seems to confirm what others have said. They will continue to release PPC kernel sources for as long as they last (no mention of the Intel sources at all), and it carefully skipped around by saying 'non-kernel Intel sources'. That's a pretty decent confirmation in my book, unless of course, Apple confirms otherwise.
Booting PPC sources was never the point.
Edited 2006-05-22 14:31
Member since:
2006-04-04
I don't think anyone serious ever thought that Apple would move to a GPL kernel. Even with being able to close all the Aqua stuff in userland, the GPL carries way too much baggage for Apple. It's more than just the viral effect. It's also that the GPL can be interpreted in different ways - thus, the problem with "derivative works". That's why many companies won't touch anything GPL (including LGPL, GPL+exceptions) with a ten foot pole.
However, I still think there is an opportunity for someone with resources and technical manpower to put a OSX like desktop operating system on top of the linux kernel. I'm not sure either Gnome or KDE slapped on top of various distros will ever gain that much market share. That's fine for tech geeks, but others want something different.
Member since:2006-01-10
I'm not sure either Gnome or KDE slapped on top of various distros will ever gain that much market share. That's fine for tech geeks, but others want something different.
Yeah, considering Gnome or KDE (Gnome especially) is so very technical and hard to use.... oh wait, that's sarcasm. Have you used Gnome or KDE lately? Hell, from what I've used of Mac OS X, it almost looks like some of the UI decisions were directly ripped form GNOME. (Compare the Networking tools. Besides the order they are listed in, they are almost the exact same!)
Member since:2006-04-04
Yeah, considering Gnome or KDE (Gnome especially) is so very technical and hard to use.... oh wait, that's sarcasm.
My comment had nothing to do with the usability of KDE or Gnome. I was talking about some geeks not worrying about market share - while others with interests in various projects do.
But there's a point to be made about developing a desktop operating system as a whole (from an organizational standpoint), and not relying on various upstream/downstream parties putting it together.
Member since:2005-10-02
Member since:
2006-05-21
Member since:2005-06-29
Member since:2006-01-15
Member since:2005-10-02
Member since:2006-01-15
In this case, even if Apple removes access to the parts of the code they are modifying, this is more freedom for everybody without taking any freedom from anybody else.
Please remember that the original code that Apple forked from is still available and will always be available for anyone to use. All Apple can do is restrict access to the bits they add/change.
Member since:2005-10-02
Member since:2006-02-11
There is a developer package in mac installation cd, contains developer tools including documentation. You can view it online on http://developer.apple.com/. There is GPL implementation of Cocoa called GNUStep, but compared to Cocoa it's just plain suck.
Member since:2005-10-02
I'm perfectly aware of GNUstep. What do you think I'm running in exactly this moment? 
GNUstep doesn't suck from a technical point of view, but one must remember that it is far from finished.
Cocoa contains proprietary extensions to OpenStep API, and these I'd like to see the documentation for.
Member since:
2005-11-05
Member since:2005-07-06
Member since:2005-07-08
On what grounds did you decide to not read TFA?
Thom issued every reason why Apple is not going to use the Linux kernel as their replacement for their current solution. That snippet of text you quoted should've included the first portion of the sentence, which stated that "some have uttered" (obviously meaning various 3rd parties!!!) that Apple might replace their current BSD kernel with the Linux kernel.
Thom did not allude to Apple wanting to do it.
Member since:2006-02-11
Member since:2005-07-13
Yes, Linux is, for them, the most viable option to get OSX Aqua GUI for free, by injecting the GPL virus infected Linux kernel to OSX.
*sigh*
A GPL kernel does not necessitate a GPL userspace. Would make it very difficult for that multi-billion dollar industry that has sprung up around linux to exist, since most of the commercial products from companies like IBM or Oracle are closed and proprietary.
Apple was happy enough to embrace the GPL when they needed to lift khtml for Safari. I don't see anyone demanding they hand over the source for OS X in return.
edit: typo
Edited 2006-05-22 05:14
Member since:2005-07-06
KHTM is LGPL not GPL , its two different license.
http://en.wikipedia.org/wiki/KHTML
Member since:2006-02-11
Member since:2005-12-14
Member since:2006-05-18
Member since:
2005-07-15
It's really just getting boring, the whole "Linux + something = Magic Fairy Dust" articles. It's good for a fight, and it's good for people that want a Linux-based monoculture, but for normal or intelligent people? Just lots of hot air.
I know a ton of unixy people that use OS-X. Not one of them is running a custom kernel. Why would they? The only thing I've seen of note was a hacked kernel that let you run an ibook with the lid closed...
Please, prove me wrong and show me a nice repository of people talking about the cool things they do to xnu... I'm still all on PPC, so maybe I'm missing out.
Member since:
2006-01-05
Member since:
2005-07-10
Never say never! No one knows the future.
But I would bet 100 USD, that Apple will not switch to the Linux kernel on their desktop system (not in the near future. Server is another beast). Why should they? They will probably not sell much more units because of a Linux kernel and Thom has absolutly right: Apple likes control (what comercial company does not like control in one way or the other?).
Member since:2005-06-29
Member since:
2005-07-08
Mac OSX switching to the Linux kernel is almost a non sequitur in the context of the argument given, as no part of the cited criticisms of Darwin or Mac OSX would be directly addressed by the change. So, let's just chalk that one up as pandering for page hits.
The issues regarding the ability to compile custom kernels for Darwin, however, are worth some discussion. I don't know much about Darwin, XNU, or the Mach microkernel, and therefore I'm not sure how (or if) users may select or remove support for various hardware or software features. However, most UNIX-like systems have some notion of kernel extensions or modules that may be loaded, if not dynamically, when the kernel is loaded into memory.
If this is the case for MacOSX/Darwin/XNU, then I don't understand what the huge stink is over compiling a custom kernel. It seems to me that the needs of most power users and system administrators are met by configuring which kernel extensions and/or device drivers are loaded. Since the system is based on a layered design with a microkernel at the heart, there must not be a significant benefit to slimming kernelspace.
With this in mind, I think that moving to Linux would be a step backwards from Darwin. As much as I enjoy running Linux and rolling my own kernels, there's no way to slim it down to the size of a maximally configured Mach microkernel, probably even if you remove the virtual memory manager (possible with 2.6.x). As much as dynamic module management on Linux has improved with initrd, coldplug, hotplug, and udev, there are still issues when using a fully modular kernel. For example, my ACPI modules (battery, button, etc.) never load automagically, so I compile them statically. Further, while Darwin has some nested wrappers for things like threading, Linux has some even crazier code paths for things like context switching, where execution passes in and out of arch-specific code a few times.
If Apple or its developer community really feels pressure to move away from Darwin (for some reason I fail to realize), they might as well choose a system with a more modern, aggressive design than Linux. I'd much rather see Mac OSX based on L4, MINIX3, or Dragonfly, all of which are open source.
Member since:
2005-07-10
I don't know anyone (and I know a bunch of Mac OS X users) careing about the underlaying kernel. Mac OS X is just the best OS on earth to them. If it would be a Linux kernel or the current kernel or another kernel... they don't care as long as the system works. That's it. I have never heard of any one of them switching the kernel or compiling a custom made kernel. And some of them (I would say 50%) are absolutly in the position/knowledge to do so. But they don't do it and probably will never do.
Member since:
2005-07-20
Linux would be a bad idea for 2 reasons. Firstly, its GPL - which isn't always a bad thing however with proprietary software it is (please no GPL, BSD wars - its been covered too many times)
Secondly, linux goes by the philosophy of get it working on every peice of hardware right away and worry about performance and stability later.
Personally I think they should just take FreeBSD as a whole, make their graphical and window servers for it, and add their obj-c layer to it. Scrap the XNU/Mach stuff - just go FreeBSD + Apple's GUI and hardware. Just my opinion though.
Member since:
2005-11-09
I don't believe in the control argument. Please correct me if I am wrong but Apple can do what ever they want to the Linux kernel if they make a fork as long as they make these changes GPL. They have as much control as with anything BSD. Obviously the GPL can be a problem for a company, but it doesn’t limit their control if they did adopt the Linux kernel.
Edited 2006-05-22 00:30
Member since:2005-07-20
Member since:
2005-11-15
A lot of your argument is invalidated by the fact that the Linux and Darwin kernel architectures are the same. Darwin/XNU is not microkernel-based; the only part of the kernel that is dynamically loadable is drivers, just like Linux. Honestly, I can't think of any part of Darwin/XNU that I would choose to remove anyway.
Member since:2005-07-08
"A lot of your argument is invalidated by the fact that the Linux and Darwin kernel architectures are the same. Darwin/XNU is not microkernel-based; the only part of the kernel that is dynamically loadable is drivers, just like Linux."
Darwin is based on the Mach microkernel, but now that I've read more about it, the POSIX layer, proc, vmm, and fs are loaded in kernelspace along with Mach. So it is a hybrid kernel.
Unlike Linux, though, many (most?) device drivers are loaded into userspace and use microkernel-style message passing to request access to kernel interfaces and data structures. So, for example, Darwin has a stable device driver interface specified by its message dictionary and lacks the ABI problems that plague binary Linux drivers.
So, for what it's worth, Darwin/XNU and Linux are more similar than I originally thought, but switching to Linux would still be a small step backward in terms of architectural sophistication (plus the stability, reliability, and debugability that should theoretically go along with that).
Thanks for correcting me
Member since:
2005-06-29
I don't think Apple would ever use Linux as their kernel...
...But in the a parallel reality that it might happen, Apple would probably fork the main tree and add to "their" kernel a stable interface. The kernel would probably get more and more different from the main tree as time passes, but Apple would back-port everything they want/need into their tree.
The thing is, so many developers want a stable kernel interface, but Linux kernel developers don't want to spend their time doing this. Reasons may vary... from the open source nature of the development to the political GPL 'defense'....
The other thing is, this kernel with stable interface would rise many interest from developers looking for those... with hardware developers in the first place of the line...
Actually, it's not very different from the KHTML/WebCore history...
Member since:2006-01-15
Why? The GPL is fine for programmers who don't want to allow thier code to be forked into closed source derivitives.
If the new GPL doesn't serve those folks needs they'll either use the old GPL or they'll roll thier own license.
Besides, if the GPL is altered to be largely identical to the BSD license then one of them is redundant.
Member since:
2005-07-06
>Some of their proprietary, closed source, stuff would have to then be GPLd wouldn't it?<
actually, most likely not because the origional work did not origionate from or derive from gpl code, they simply would have to make a gpl compatability layer to interface with the particular piece of software with the kernel.
That aside, linux as the OSX kernel....... in my mind is ridiculous.
I love linux and it has it's place. The OSX kernel is not that place.
Member since:
2006-05-22
I am surprised nobody mentioned opensolaris (www.opensolaris.org) as a viable kernel alternative for Mac OS X x86. The CDDL license would protect any Apple derivative work while providing an enterprise class unix kernel used in the largest data centers of this world.
I do admit that the PPC port is required and that the effort is probably not worth it, at least for the next coming years, while Apple support PPC.
Member since:
2005-07-06
The problem boiled down to this: can those drivers be considered derivative works, or not?
*Sigh* No, that's not the issue. The problem boils down to: does Linux + proprietary drivers constitute a derivative work of Linux or is it "mere aggregation"?
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
Member since:2005-06-29
Member since:
2006-01-04
GPL is not an issue here. Apple already uses {L,}GPL products such as khtml and kjs, GCC ( important one.. ) and samba.
Plus, you can load binary blobs into the linux kernel, as Linus explicitly said.
So please, Thom, stop your stupid GPL FUD, this is a technical issue, not a licencing one.
Thanks.
Member since:2005-06-29
Member since:2006-01-04
Member since:2005-06-29
He didn't say that. He said that if they are written without Linux in mind than that implies they aren't a derivative work.
You've twisted that to be that they are not derivative if and only if they weren't written with Linux in mind.
If he's said what you're saying I'd love to see it because I've read his discussions about it and he didn't say iff.
Member since:
2005-07-15
Seriously, anyone? Buehler?
If we're going to argue about it, I'd love to see at least one person here pissed off because they cannot do something they used to be able to do (build their own kernel).
Thom, how about a nice news story where you track down people doing this and wow us with neat Xnu tricks?
Member since:
2005-11-21
People are just not getting the multiple layers that go into OS X that will be Apple only layers. Let's not forget the dichotomy between Linus and the history between Apple Engineering and him.
To put it bluntly: Apple will never use Linux and what they add to XNU for Leopard will most certainly copied.