Tom Yager Oversells Open Kernel Issues
Macworld UK has published an op-ed piece on Apple's decision to no longer publish the source to the Intel version of the Mac OS X kernel. I find Tom Yager's response to this somewhat unrealistic:Mac developers and power users no longer have the freedom to alter, rebuild, and replace the OS X kernel from source code.
[...] Apple's retreat to a proprietary kernel means that all users must accept a fixed level of performance. The default OS X kernels are built for broad compatibility rather than breakneck speed and throughput.
Now I might be in the dark here, but I really don't think people are compiling their own Mac OS X kernels for anything but the novelty of it. Compiling custom kernels makes a lot more sense in the Linux or BSD worlds, but the entire point of Mac OS X is you don't have varying bits and pieces of system software lying around.
Imagine this scenario. You've created some sort of custom kernel using the 10.4.6 source. Then, on a Thursday in early summer, 10.4.7 is released. Now what do you do? Download the source, merge your changes, rebuild and redeploy?
How often do you do this? Every new release? What about security updates that affect the kernel? This strikes me as bizarre for a Mac OS X environment, and we haven't even talked about potential compatibility issues, yet.
The author continues:
Even if I don't need to hack the kernel, knowing that I can affords me a level of self-sufficiency and insulation from vendors' whims that fixed system software, such as Windows, does not.
I think the value of this is largely imagined. Unlike Linux, Mac OS X isn't primarily defined through the kernel. If Apple decides to take the kernel in a different direction than the author wants, how is having the source going to help that? Unless you plan to go without the higher level services, it really doesn't.
The xnu source is and always has been interesting for three reasons: hobbyists looking for a good time, community bug fixing, and help in developing drivers. I don't know how many bugs the community fixed (though I suspect very few), and I don't know if one still needs kernel code to write drivers with the newer APIs.
The reality is that Mac OS X simply is not Linux. Compiling and maintaining your own kernel doesn't make nearly as much sense. If you're going to make the case for an open kernel, at least use practical issues. The "we want to hack our kernel for no reason" bit isn't enough to trump increased protection from pirates.
I think the real issue at stake here is that Linux culture has created an emotional attachment to the idea of an open kernel. The list of people that make actual practical use of xnu source is very, very short. Having the source to CoreFoundation is much more useful to the average developer.
Tom Yager Oversells Open Kernel Issues
Posted May 17, 2006 — 8 comments below
Posted May 17, 2006 — 8 comments below
Daniel Lyons — May 17, 06 1260
In my Linux second life I find that taking things out of the kernel mostly improves speed of booting, not using. To achieve notable performance improvements you usually have to try out different patches, and there are several "leading" patched distributions, like Con Kolivas', which give you small but somewhat noticeable improvements.
MJ — May 17, 06 1261
*sigh*
Chris — May 17, 06 1262
Aside from that, the potential loss here for Mac users is incalcuable. Look at the Linux kernel, and the thriving development community around it. Interesting new features get added, considered, beat into shape. Performance gets tuned. Bugs get squashed quickly. Entire subsystems get replaced with better ones (sometimes).
Look at Safari. It's thriving as a fully accesible open-source project, where the app itself isn't actually opensource, but the foundation library which implements most of the functionality _is_. It's true that the pool of WebKit developers to draw from is wider, and the barrier to entry lower, but it's also a function of the stark difference in attitude of the development teams -- Safari's leadership "gets it." xnu's hasn't and doesn't (and now probably can't, since it's likely locked down from the top).
Apple has thrown away a golden opportunity to open the kernel up and make kernel development more accesible to developers outside of Apple. There is a huge set of developers who would be happy to contribute, but Apple never really committed to making the kernel accessible as open source. The first thing Apple should have done six years ago was to make the kernel compile with just the normal devtools installed. But they just threw it out there unmodified. Apple employees working in their spare time eventually fixed this, years later and eons too late.
Scott Stevenson — May 17, 06 1263
Mea culpa, then. It's a legitimate need. That said, kernel source is just treating a symptom of inadquate docs, not the real issue.
Aside from that, the potential loss here for Mac users is incalcuable. Look at the Linux kernel, and the thriving development community around it. Interesting new features get added, considered, beat into shape. Performance gets tuned. Bugs get squashed quickly.
My entire point with this post is that Mac OS X and Linux are different beasts. Just because you have an open source kernel doesn't mean you get the same sort of contributions that Linux does. The license is just mechanism.
Darwin has been out for, what, six years? How many kernel improvements have come from the community versus paid Apple employees? If the community was having a significant impact, I'd think Apple would find a way to keep the source out there.
The Linux community was born from the unix hacker community. I'd wajor most linux users know you can get the source to the kernel. How many Mac users have even heard of Darwin or xnu?
It's true that the pool of WebKit developers to draw from is wider, and the barrier to entry lower
I think this is the reason for the difference. Not only are the results a lot more tangible for the average Mac developer, but the material is a lot easier to deal with.
Joshua — May 17, 06 1264
Alastair Tse — May 17, 06 1266
I have a few thoughts about today's hoo-ha about the x86 source disappearing that I haven't really organised properly. As I'm pretty sure tomorrow morning I have to explain to the many Mac non-believers at work what it means.
The kernel source available is quite important for anyone who wants to do some innovative stuff at the system level. Not all innovation happens above libc, for instance psuedo file systems like webdav, etc. If you look at the sample code for creating new file systems provided by apple developer's site, it is barely working. In fact, you actually have to go into the kernel source to find some examples of sane FS implementations. I'm sure there are numerous other examples. As long as the API's are well documented and all the quirks are demonstrated by GOOD sample code, then I wouldn't think it is much of an issue.
More importantly, the PPC sources are still there, and if Apple continues to update them for 10.5, then I think that would be useful for a large portion of the driver writing community.
It sucks to be a hobbyist tinkerer like me, but for serious developers and commercial developers, they'd probably have different avenues of getting driver coding support.
Tom Bradford — May 19, 06 1281
At that point, it only matters that you don't have the i386 code in very odd scenarios, but otherwise should be sufficiently happy with the ppc code base for purposes of exploring the kernel, or using the kernel as a base for driver development.
While having the option for building one's own kernel, how often does anyone really do it? In using Linux for over ten years, I think I compiled a custom kernel only once, and it was because I was having a sound card problem before the time of kernel loadable modules. With the current design of xnu (and most UNIX-like kernels for that matter), the need to rebuild a kernel is minimal if not completely without necessity.
jonnie savell — Aug 10, 06 1556
I imagine that Tom's ranting had something to do with this.
I saw Tom right before the Keynote.
I wish I had thanked him for having pushed Apple in the right direction.