Mac OS X Kernel Source Now Closed 663
littleghoti writes "Macworld is reporting that "Thanks to pirates, or rather the fear of them, the Intel edition of Apple's OS X is now a proprietary operating system."
Mac developers and power users no longer have the freedom to alter, rebuild, and replace the OS X kernel from source code."
Extremely old, and misleading, news (Score:5, Informative)
Also, "Mac OS X" has ALWAYS been proprietary. It's sensationalistic and shoddy journalism to say that "Mac OS X is now closed". Mac OS X has ALWAYS been closed. It's Darwin that has been open. And "Darwin" is more than a bootable OS: Darwin is Apple's open source strategy AND an OS; but the usefulness has always come from the open source components of the OS, not the usefulness of Darwin as an OS itself. Darwin's usefulness as an OS is, shall we say, "limited" at best, and always has been.
This has been beaten to death on the darwin-dev list, and there is no new information. Apple has taken no new recent action whatsoever, and in fact, the most recent action is that it has opened up more source code in the x86 tree, not less. Indeed, all of the traditional Darwin source with the notable exception of the kernel itself:
The thing that's not open in the x86 tree is xnu (the kernel), and it's not possible to create a fully bootable binary x86 Darwin OS, as it is for PPC. In the Darwin/OpenDarwin community, this has been discussed for months.
In fact, this article by Rob Braun (formerly of Apple, and a member of the OpenDarwin core team) was published in February 2006: http://ezine.daemonnews.org/200602/apple.html [daemonnews.org]. This was then covered on slashdot, to which Rob issued this response: http://www.opendarwin.org/~bbraun/slashdot_respons e.html [opendarwin.org]. These two discussions cover the issues very well.
I predict, however, that this Macworld UK article will be seen as "new news", and will be picked up by the tech outlets, and trumpeted, exactly as the headline hopes, as "Apple closes down OS X", even though the source for pretty much everything (except the kernel and drivers) is still available. In other words, everything that a normal person needs Darwin sources for is available. In 5 years, I can think of ONE instance where I looked to the kernel source for confirmation of something, and that was only for *confirmation*, and only because it was convenient - not because I needed to rebuild the kernel. I know of no other non-developer/programmer Mac OS X adminisrators/system engineers/enterprise users who have ever had any reason to rebuild the kernel or any drivers.
If the kernel and driver source were available, it would, however, be used for one purpose: to churn out hacks to get OS X to run on non-Apple hardware in a much faster and higher-quality way than has been possible to date. Will OS X be hacked anyway to run on non-Apple hardware, and will it continue to be, regardless? Yes. If people are willing to replace enough of the OS with the ugliness they're using to get it to work, absolutely. But it will continue to be ugly. Releasing kernel and driver source for the current iterations of OS X on x86 will only make their jobs infinitely easier, while brining little to no benefit to conventional users, power users, and administrators of OS X.
I'm sure people will find a way to make a huge deal about this, though, even though a huge deal has already been made about it in various forums, including slashdot and other tech news outlets, and on several of Apple's mailing lists.
I'd like to point out that this was my initial reaction: http://listserv.cuny.edu/Scripts/wa.exe?A2=ind0602 &L=macenterprise&T=0&P=58970 [cuny.edu]
Since then, Apple has posted all of the APSL sources, and it was just a legitimate, honest delay. The PPC and x86 trees are at virtual parity with the sole exception of the kernel and drivers. So I'd submit that "Apple closes down OS X" is highly inaccurate for two reasons:
- Most of OS X was never "open" to begin with; if he wants to say "Darwin", great, but I suppose "Apple closes down Darwin" wouldn't be as sensationalistic and guaranteed to get as many page v
Comment removed (Score:2, Informative)
source availability (Score:2, Informative)
Sigh.
Alas.
Re:Great news! (Score:5, Informative)
The state of Darwin x86 hasn't changed since the day the Intel-based Macs shipped.
In fact, Apple's only action since then has been to release MORE source; APSL sources that correspond to the entire PPC Darwin tree with the exception of the kernel.
This has been discussed for MONTHS in other forums, has already been covered by slashdot, and has been beaten to death on Apple's mailing lists.
Darwin x86 *as an OS* is dead. The actual part of the Darwin strategy people cared about, i.e., the Darwin OS *components* being open, and all of the projects (like WebKit), etc., are all open, alive, and well on x86 and PPC. Apple releases parity Darwin source releases with each Mac OS X release.
See for yourself:
http://www.opensource.apple.com/darwinsource/ [apple.com]
The only item of note not present is one thing: xnu (the kernel).
All of Apple's open source projects, all of the APSL-licensed projects - which Apple is under zero obligation to continue releasing - and all of the GPL-licensed projects (of course) are still there.
So, in sum, paint this as some kind of bad news if you want, but if anything, it's OLD news, and actually, the pieces of Darwin people actually care about and use - indeed, both of the things you allude to in your post - are still alive and well on x86.
The only thing you can't do is make a bootable Darwin OS for x86 any more. And if you can explain to me why anyone would want to do that for any useful purpose, well, I'm all ears.
Re:Extremely old, and misleading, news (Score:2, Informative)
Yes, it was covered on slashdot at the time, [slashdot.org] so you're not telling us anything we don't know.
Perhaps the fact that the vast majority of the comments were "It's a mistake! Apple's not closing Darwin at all!!!" is what led to this being covered again?
- All of the things that are open in Darwin PPC are still open in Darwin x86, with the exception of the kernel and drivers. He doesn't explain what this means to even sophisticated OS X users and administrators in his article; namely, that it means nothing.
Perhaps you missed this part of the article:Sounds pretty useful to sophisticated OS X users to me!
Please note that I would indeed like Apple to actually *announce* major shifts in strategy like this, instead of just thinking it can do it silently.
Me too - then we wouldn't have to get stories like this posted five times on
Re:BSD vs GPL (Score:1, Informative)
Apple continues to make available the BSD userland and tool chain [apple.com] for each point release of Mac OS X via releasing the related Darwin source tree (both PowerPC and Intel).
Also Apple has many active open source projects using BSD, LGPL, and their own APSL that they either wholly developed or have greatly enhanced.
Apple WebKit [apple.com] && Offical WebKit [opendarwin.org]
Darwin Streaming Server [apple.com]
Re:Extremely old, and misleading, news (Score:4, Informative)
I use a Mac for my research because it is a great desktop and it has a unixy feeling (I say feeling because it is still a headache to get some programs installed/compiled which are a breeze in any other of the more traditional flavors; especially with the Intel transition, there are some things that do not compile).
But besides that, I have to say, it's been proven with hard facts and my own experience that MacOSX is not an efficient OS. I don't know why they would even want to spend time hacking the kernel, or use MacOSX for a massive grid. Use Linux, FreeBSD or anything else more efficient, and hack it to improve it even further.
I am not trying to give an excuse for Apple, but it is just clear that Scientific computing is not the forte os MacOSX, even though Apple might market it as a strong point.
Re:This fucking pisses me off .. (Score:5, Informative)
Thumbing through the XNU source, all the assembler and C sources for the Intel platform is still there
GPL vs BSD (Score:3, Informative)
Re:BSD vs GPL (Score:5, Informative)
Of course drivers for devices only found on PowerPC aren't available in the x86 source tree (which makes sense). Also drivers for x86 hardware isn't available nor has it been stated by Apple if they will or will not be made available (for all we know Apple could be waiting for the unification coming in 10.5).
The only real loss to developers is not having IOKit from the x86 source tree however the IOKit available from the PowerPC tree is likely nearly the same if not the same (it contains some ifdefs for x86, etc.).
Slows down driver development (Score:5, Informative)
Some drivers can be made in user space, but a lot of drivers need to be coded in kernel space. When OS X first came out years and years ago, the procedures for writing drivers was horrid. Even today, it's still easy when writing drivers to make a coding error and get a kernel panic. Each kernel panic has a bunch of stuff in the log that allows developers to trace back the problem that caused the kernel to crash.
On PowerPC, the source code for the underlying drivers is available. This is invaluable since not only do you have the point in your code where you have a crash, but you can also figure out what IOKit or the kernel was trying to do that caused the crash. Being able to see exactly how the driver family is using your device is very helpful in figuring out either how to work around your bug or how you can remove it.
With the Intel OS X drivers, however, there is no source. You can't look back and see what the kernel is trying to do that caused your driver to soil itself. This makes debugging a pain in the neck since now, instead of being able to try and figure it out for yourself, you need to get Apple involved if you need more information. Having the PowerPC source isn't sufficient since the drivers are different between x86 and PowerPC. Case in point: right now I'm developing a USB audio device that works just fine on PowerPC but the moment you plug it into an Intel based Mac the OS kernel panics. I suspect a div by zero in the x86 driver, but I can't verify that since I can't see the source. Instead I have to rely on Apple to tell me what to fix.
Thankfully starting with Tiger a number of the more obscure kernel interfaces are actually a bit more abstracted for dlils and the like for which in the past reading kernel code and other drivers was almost the only documentation. That's still no reason for getting rid of the sources.
Although this lack of source is no new development, it really doesn't affect end users. The only people really building custom kernels for running OS X are the XPostFacto [macsales.com] guys for running OS X on legacy hardware or PowerPC accelerators, and they never needed x86 code anyway. It affects hardware developers like myself and can make debugging a pain in the neck, especially if you don't have any of those paid-for ADC tech support incidents left.
ed
Re:Who cares, really? (Score:3, Informative)
Re:TPM (Score:5, Informative)
Apparently, at least some of the shipped Intel Macs contain TPM modules [masternewmedia.org]. Unless anyone can find evidence to the contrary, it's probably reasonable to assume they all have them...
Re:Extremely old, and misleading, news (Score:4, Informative)
The much lauded Viginia Tech supercomputer uses a hacked kernel... the memory management was completely replaced.
Are you serious? (Score:3, Informative)
That question has been asked and answered several times [google.com]
Re:TPM (Score:3, Informative)
Re:Legality? (Score:3, Informative)
Re:Short version (was:Duh!) (Score:5, Informative)
In reality they use the software to drive the hardware sales. But they're not a software company.
Re:Extremely old, and misleading, news (Score:4, Informative)
Btw, its kernel, not kernal.
Sure. Kazushige Goto hacked the memory management system on OS X to get it to perform better for high performance computing.
People hack Linux kernels all the time for specific needs or tweaks.
This is why we like open source so much. It empowers us to make things work instead of passively putting up with closed source's inefficiencies or bugs.
Re:This is speculation. (Score:3, Informative)
BSD used to be just a bunch of tools (Score:3, Informative)
If there is demand then somebody will make an open source kernel to run instead, which would only get you the tools... Just use FreeBSD and port the few tools that are different over there.
Unless they replace MS, I don't see anybody trying to make a kernel when its easier to port the few useful parts to other OS.
Re:Great news! (Score:4, Informative)
Which is something anyone who has ever worked professionally with open source components of OS X is aware of -- that Apple's marketing of their commitment to open source is exactly that, marketing, and goes only skin deep. None of this is to fault those who are working on it, but the fact that all of the open source releases were after the fact, repackaged, as well as Apple's bug tracking (radar) being strictly internal, never inspired a lot of confidence. For a long time, different parts of the OS were being released in different ways which helped a lot adding to the confusion.
"in the enterprise community, one we found out that the rest of the sources would continue to be released on x86 as normal, the kernel being gone was barely a blip on our radar."
So what else could Apple do at this point that would barely show up on your radar? Let's say they start going nuts with itunes drm, and start locking down everything itunes depends on. Oh well, you never needed to recompile the C library anyway, right?
Aside: I actually *did* need to recompile Apple's C library back in the OS X 10.0 days as their loginwindow had no extension API and I was working at a site that used Kerberos for logins, so I patched crypt(2) and used magic values in the passwd db. This never made it into production as 10.1 was released shortly thereafter but we were using a patched, hacked-together loginwindow plugin after that for about a year before the API was opened up in 10.2. Now I hear loginwindow itself is encrypted or obfuscated in some way to depend on the TPM as a deterrent to pirates, as it is considered a "core component" of the OS. It's only a hop skip and a jump from there to the chaos currently going on in the Windows world where Microsoft is making everyone rewrite their GINAs to a new API for Vista.
Re:Great news! (Score:3, Informative)
Fact: For the PPC platform this hasn't change.
Fact: The ability to compile the OS X kernel for x86, aka xnu, is no longer available.
My question is, and I have yet to hear an answer, is why have they done this? "Nobody does this anyway" is not a good excuse. I personally compile my own xnu kernels on PPC and x86.
The only thing you can't do is make a bootable Darwin OS for x86 any more. And if you can explain to me why anyone would want to do that for any useful purpose, well, I'm all ears.
One obvious reason is so that you can run OSX on non-apple hardward.
Re:WTF?!? (Score:2, Informative)
That said, theres nothing stopping the end user from doing such a thing, as indicated by the existence of many drivers and libraries on my system of proprietary things cracked and laid bare for all. The illegality of that aside, it CAN be done.
Think this is "closed", you've been sheltered! (Score:4, Informative)
What, unbundling the documentation tools and the compilers and even the man pages, and selling them back to you for outrageous prices?
No?
Most Unix developers are accustomed to having access to the source code for the system;
Even when I was at Berkeley working on 4BSD that wasn't true. Only the CSRG guys had access to that source, everyone else was stuck with (if they were lucky) photocopies of the Lyons book.
Having access to the source code of the kernel is useful for understanding how the system works,
Yep, and you still have that. You don't have the x86-specific stuff, but you have everything else. And there just isn't that huge a difference between systems... hell, I was debugging Digital UNIX kernel problems by referring to the FreeBSD sources in the '90s, and the differences between XNU PPC and XNU x86 are trivial by comparison.
As a FreeBSD user, closed-source Unix just doesn't make sense to me
Then stick with FreeBSD.
As a former FreeBSD committer and 386BSD patchkit maintainer, I'll continue to use the best tools I have available: Mac OS X on the desktop and FreeBSD in the server room.